PR_url,status,createdAt,closedAt,title,author_login,mergeCommitID,changedFiles,commitMessage,Reaction,reactTime,reactAuthorLogin,reactAuthorEmail https://github.com/rust-lang/rust/pull/32184,CLOSED,2016-03-10T21:22:40Z,2016-03-13T20:48:58Z,Fixup stout/stderr on Windows,ollie27,NA,NA,NA,HOORAY,2016-03-10T22:16:11Z,retep998,NA https://github.com/rust-lang/rust/pull/32212,MERGED,2016-03-12T10:33:02Z,2016-03-13T16:27:22Z,Don't allow values for codegen-units less than 1,Manishearth,5b7f8b1e5a6cf6748d9598f5b8a6d138b6ee3930,1,Merge 8e3ccd9c9bce2830581596d496e130cb43c179d0 into c21644ad162c69da7c883812be3e473c4e64c257,LAUGH,2016-03-13T08:57:01Z,pczarn,NA https://github.com/rust-lang/rust/pull/32219,MERGED,2016-03-12T22:19:52Z,2016-03-24T16:15:51Z,Make warnings of renamed and removed lints themselves lints,brson,addde1fd6f6fc16471473aaea405a8b73e8e9580,6,Make warnings of renamed and removed lints themselves lints This adds the `renamed_and_removed_lints` warning defaulting to the warning level. Fixes #31141,THUMBS_UP,2016-03-12T22:30:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-13T22:57:57Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-13T23:50:22Z,retep998,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-14T22:03:49Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-14T22:09:36Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-14T22:13:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-14T23:19:43Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-19T16:07:09Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-21T18:09:22Z,ruuda,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-21T19:10:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/32236,MERGED,2016-03-13T22:10:18Z,2016-03-16T05:38:33Z,rustc: Improve compile time of platform intrinsics,alexcrichton,dee72122a21735171f60b327405376865befb320,6,Merge 87ede2da549632de443859c8e08f0c977849d8b7 into c66d2380a810c9a2b3dbb4f93a830b101ee49cc2,THUMBS_UP,2016-03-22T08:26:53Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/32237,MERGED,2016-03-13T23:56:44Z,2016-03-17T14:52:36Z,rustbuild: Implement `make dist`,alexcrichton,d47ebcf48819561947a890b1e515f3b50eb9f3f0,6,Merge 6cc06b36c4da7f21f43d663d6c8a8ee547651cde into 3b765f44a675bb5a5c45efc9e024824aa26700e0,HOORAY,2016-03-16T00:32:17Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/32256,MERGED,2016-03-15T00:44:01Z,2016-03-19T06:59:18Z,Add intrinsics for float arithmetic with `fast` flag enabled,bluss,0d16e2e304bb0ab3036337ef993a69dabbce760f,9,Merge 2dbac1fb8ed43cbcd160855803d50a51c38b8cee into 10bdd808b5e6e23ed8dd9f281c60193a570865f9,THUMBS_UP,2017-06-06T19:27:12Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/32282,MERGED,2016-03-16T03:49:43Z,2016-03-18T18:30:37Z,Adjustments to the panic hook API,sfackler,d2db7ab9843240d87fac354464342f55e14b742c,5,Merge 50fda1eead10af900a7b7c9f07983937e66bcc3c into 235d77457d80b549dad3ac36d94f235208a1eafb,THUMBS_UP,2016-05-18T16:47:41Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32287,CLOSED,2016-03-16T14:19:41Z,2016-03-16T22:54:13Z,Introduce cache for projection,nikomatsakis,NA,NA,NA,HOORAY,2016-03-16T14:40:44Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32293,MERGED,2016-03-16T19:10:03Z,2016-03-26T03:32:35Z,Revamp symbol names for impls (and make them deterministic etc),nikomatsakis,1ea93c2a6388b7dcddf1ae89105a9f6f2e1da9f1,4,remove link-guard test,THUMBS_UP,2016-03-28T08:00:26Z,pczarn,NA https://github.com/rust-lang/rust/pull/32302,MERGED,2016-03-17T03:54:18Z,2016-03-21T07:07:40Z,Add unix socket support to the standard library,sfackler,8df6bfd81736de740c10016f61ed362b77e73da4,7,Merge c0d989ed6b4b840a290a80ec0cdbc8edbce2ee57 into 7f5c568e0ad7014eda43798fd66fb7f2b8069ff2,HOORAY,2016-03-20T18:33:43Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32316,MERGED,2016-03-17T17:19:20Z,2016-03-19T14:45:17Z,docs: `let` introduces a statement,tclfs,af1b46279aff4b27de34c75253e0cab0a5e8665e,1,Merge 79244c3a6b4478e1561a1dfa1aff035650aff3ad into b854149a48723dabdd908063ffeedbef66a27277,THUMBS_UP,2016-03-17T17:31:27Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32355,CLOSED,2016-03-19T14:18:09Z,2016-05-21T00:25:19Z,Implement Vec::splice and String::splice,SimonSapin,NA,NA,NA,THUMBS_UP,2016-03-19T14:59:01Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32355,CLOSED,2016-03-19T14:18:09Z,2016-05-21T00:25:19Z,Implement Vec::splice and String::splice,SimonSapin,NA,NA,NA,THUMBS_UP,2016-03-24T05:53:04Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32355,CLOSED,2016-03-19T14:18:09Z,2016-05-21T00:25:19Z,Implement Vec::splice and String::splice,SimonSapin,NA,NA,NA,THUMBS_UP,2016-03-30T10:47:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/32371,CLOSED,2016-03-20T10:25:36Z,2016-05-08T18:28:59Z,Add more info to an ICE message,nodakai,NA,NA,NA,THUMBS_UP,2016-03-20T16:20:59Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-21T08:49:38Z,oli-obk,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,THUMBS_UP,2016-03-21T09:30:00Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,THUMBS_UP,2016-03-21T13:53:31Z,pczarn,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-21T15:44:01Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T02:08:38Z,bstrie,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T12:33:44Z,cristicbz,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T12:53:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T13:16:14Z,vks,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T14:48:15Z,azerupi,mathieudavid@mathieudavid.org https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T16:19:25Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-22T22:36:01Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-24T05:56:19Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HOORAY,2016-03-24T05:56:25Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HOORAY,2016-03-28T19:23:16Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-28T19:23:20Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,THUMBS_UP,2016-03-28T20:32:27Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,HEART,2016-03-28T21:34:10Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32390,MERGED,2016-03-21T08:43:01Z,2016-03-23T19:33:10Z,convert 99.9% of `try!`s to `?`s,japaric,c063c5153f778893d6d7296da1c8717ed8212bec,1,add back `&` that was deleted by mistake,THUMBS_UP,2016-04-01T03:08:35Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/32410,MERGED,2016-03-21T20:03:40Z,2016-03-23T15:59:19Z,Add support for naked functions,ticki,4869417b6187e16091bfd5e45e36c999c7d0b98f,1,Add test for the feature gating of naked,THUMBS_UP,2016-03-21T20:05:08Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/32415,MERGED,2016-03-21T23:56:57Z,2016-04-05T23:54:11Z,std: Fix linking against `signal` on Android,alexcrichton,9c462b84c8e15c3b33229a2604b273fc58acf60a,4,std: Fix linking against `signal` on Android Currently the minimum supported Android version of the standard library is API level 18 (android-18). Back in those days [1] the `signal` function was just an inline wrapper around `bsd_signal` but starting in API level android-20 the `signal` symbols was introduced [2]. Finally in android-21 the API `bsd_signal` was removed [3]. Basically this means that if we want to be binary compatible with multiple Android releases (oldest being 18 and newest being 21) then we need to check for both symbols and not actually link against either. This was first discovered in rust-lang/libc#236 with a fix proposed in rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so Rust crates at large continue to be compatible with newer releases of Android and crates like the standard library that want to opt into older support can continue to do so via similar means. Closes rust-lang/libc#236 [1]: https://chromium.googlesource.com/android_tools/+/20ee6d20/ndk/platforms/android-18/arch-arm/usr/include/signal.h [2]: https://chromium.googlesource.com/android_tools/+/fbd420/ndk_experimental/platforms/android-20/arch-arm/usr/include/signal.h [3]: https://chromium.googlesource.com/android_tools/+/20ee6d/ndk/platforms/android-21/arch-arm/usr/include/signal.h,THUMBS_UP,2016-04-06T00:05:34Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32415,MERGED,2016-03-21T23:56:57Z,2016-04-05T23:54:11Z,std: Fix linking against `signal` on Android,alexcrichton,9c462b84c8e15c3b33229a2604b273fc58acf60a,4,std: Fix linking against `signal` on Android Currently the minimum supported Android version of the standard library is API level 18 (android-18). Back in those days [1] the `signal` function was just an inline wrapper around `bsd_signal` but starting in API level android-20 the `signal` symbols was introduced [2]. Finally in android-21 the API `bsd_signal` was removed [3]. Basically this means that if we want to be binary compatible with multiple Android releases (oldest being 18 and newest being 21) then we need to check for both symbols and not actually link against either. This was first discovered in rust-lang/libc#236 with a fix proposed in rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so Rust crates at large continue to be compatible with newer releases of Android and crates like the standard library that want to opt into older support can continue to do so via similar means. Closes rust-lang/libc#236 [1]: https://chromium.googlesource.com/android_tools/+/20ee6d20/ndk/platforms/android-18/arch-arm/usr/include/signal.h [2]: https://chromium.googlesource.com/android_tools/+/fbd420/ndk_experimental/platforms/android-20/arch-arm/usr/include/signal.h [3]: https://chromium.googlesource.com/android_tools/+/20ee6d/ndk/platforms/android-21/arch-arm/usr/include/signal.h,THUMBS_UP,2016-05-08T05:02:14Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/32432,MERGED,2016-03-22T18:13:30Z,2016-03-27T02:46:29Z,Flatten rustc and rustc_trans module hierarchy slightly.,eddyb,035a645e64df9e5192698c3d6c442e57c39b40b8,68,rustc_trans: move the contents of the trans module to top-level.,THUMBS_UP,2016-03-25T21:43:13Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-23T02:34:19Z,durka,NA https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-23T06:11:56Z,alexcrichton,alex@alexcrichton.com https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-23T06:17:46Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-24T12:25:14Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-29T18:29:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-29T19:53:43Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HEART,2016-03-30T01:26:03Z,bbatha,bhbatha@gmail.com https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-30T01:26:05Z,bbatha,bhbatha@gmail.com https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-31T16:58:16Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32439,MERGED,2016-03-23T02:04:53Z,2016-03-31T16:03:19Z,diagnostics: make paths to external items more visible,jseyfried,da41e583d614411c99370881c38f919c99dec448,125,Fix fallout in tests,HOORAY,2016-03-31T17:35:19Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/32456,MERGED,2016-03-23T21:10:23Z,2016-03-26T10:32:00Z,Hardcode accepting 0 as a valid str char boundary ,bluss,f621193e5ea7ac54fcd37f0e730e955fd9f61200,1,Accept 0 as a valid str char boundary Index 0 must be a valid char boundary (invariant of str that it contains valid UTF-8 data). If we check explicitly for index == 0 that removes the need to read the byte at index 0 so it avoids a trip to the string's memory and it optimizes out the slicing index' bounds check whenever it is zero. With this change the following examples all change from having a read of the byte at 0 and a branch to possibly panicing to having the bounds checking optimized away. ```rust pub fn split(s: &str) -> (&str &str) { s.split_at(0) } pub fn both(s: &str) -> &str { &s[0..s.len()] } pub fn first(s: &str) -> &str { &s[..0] } pub fn last(s: &str) -> &str { &s[0..] } ```,THUMBS_UP,2016-03-24T03:37:43Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32541,MERGED,2016-03-27T23:31:24Z,2016-03-29T10:36:55Z,Implement BufRead for Chain,troplin,f611e446624d288da7def4ad175405579c8bc310,1,Fix formatting,THUMBS_UP,2016-03-29T15:07:08Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32542,CLOSED,2016-03-28T01:50:17Z,2016-03-28T23:38:50Z,Plumb inference obligations through librustc/middle take 3/2,soltanmm,NA,NA,NA,HEART,2016-03-28T13:59:14Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/32549,MERGED,2016-03-28T13:00:29Z,2016-04-02T11:35:28Z,allow RUST_BACKTRACE=0 to act as if unset,respeccing,e1d2eda7f3ed8999853c8b4424e7a81a88f97d2a,9,"allow RUST_BACKTRACE=0 to act as if unset /# This is a combination of 16 commits. /# The first commit's message is: allow RUST_BACKTRACE=disabled to act as if unset When RUST_BACKTRACE is set to ""disabled"" then this acts as if the env. var is unset. /# This is the 2nd commit message: case insensitive ""DiSaBLeD"" RUST_BACKTRACE value previously it expected a lowercase ""disabled"" to treat the env. var as unset /# This is the 3rd commit message: RUST_BACKTRACE=0 acts as if unset previously RUST_BACKTRACE=disabled was doing the same thing /# This is the 4th commit message: RUST_BACKTRACE=0|n|no|off acts as if unset previously only RUST_BACKTRACE=0 acted as if RUST_BACKTRACE was unset Now added more options (case-insensitive): 'n' 'no' and 'off' eg. RUST_BACKTRACE=oFF /# This is the 5th commit message: DRY on the value of 2 DRY=don't repeat yourself Because having to remember to keep the two places of '2' in sync is not ideal even though this is a simple enough case. /# This is the 6th commit message: Revert ""DRY on the value of 2"" This reverts commit 95a0479d5cf72a2b2d9d21ec0bed2823ed213fef. Nevermind this DRY on 2 because we already have a RY on 1 besides the code is less readable this way... /# This is the 7th commit message: attempt to document unsetting RUST_BACKTRACE /# This is the 8th commit message: curb allocations when checking for RUST_BACKTRACE this means we don't check for case-insensitivity anymore /# This is the 9th commit message: as decided RUST_BACKTRACE=0 turns off backtrace /# This is the 10th commit message: RUST_TEST_NOCAPTURE=0 acts as if unset (that is capture is on) Any other value acts as if nocapture is enabled (that is capture is off) /# This is the 11th commit message: update other RUST_TEST_NOCAPTURE occurrences apparently only one place needs updating /# This is the 12th commit message: update RUST_BACKTRACE in man page /# This is the 13th commit message: handle an occurrence of RUST_BACKTRACE /# This is the 14th commit message: ensure consistency with new rules for backtrace /# This is the 15th commit message: a more concise comment for RUST_TEST_NOCAPTURE /# This is the 16th commit message: update RUST_TEST_NOCAPTURE in man page",THUMBS_UP,2016-04-01T17:56:24Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32570,MERGED,2016-03-29T09:57:16Z,2016-04-06T16:27:21Z,Reorganize rustc_front into rustc::hir.,eddyb,e8a8dfb056fb3654bacd6aaa6acbc4536358df23,23,rustc: retire hir::map's paths.,THUMBS_UP,2016-03-31T21:23:11Z,jseyfried,NA https://github.com/rust-lang/rust/pull/32576,MERGED,2016-03-29T15:27:20Z,2016-03-30T04:25:58Z,mk: Fix cross-host builds,alexcrichton,694d88394b824fecf90176c9d1a38631fd33d468,1,"mk: Fix cross-host builds The change in b20e748 had the unintended consequence of breaking cross-host builds as we apparently relied on the incorrect definition of this variable in the makefiles. That change however was required to get tests passing so we couldn't just revert it. This commit fixes the underlying bug by leaving the ""more correct"" definition of `LD_LIBRARY_PATH_ENV_TARGETDIR` (also fixing it with a hardcoded reference to `CFG_BUILD`) and updating the `RPATH_VAR` definition below. Turned out we already had special-casing logic for passing `--cfg stage1` during the well-we-print-this-as-stage0 build of a cross-host. That logic was just updated to pull from a different variable as opposed to relying on the definition of that variable to accommodate this. Closes #32568",THUMBS_UP,2016-03-30T13:27:55Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32581,MERGED,2016-03-29T16:46:29Z,2016-03-30T11:23:00Z,Add doc examples on pointer types,GuillaumeGomez,5b08ab50f783bc8e52655f05c98f4da19881d7f3,1,Add doc examples on pointer types,THUMBS_UP,2016-03-30T13:27:26Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2016-04-05T08:35:21Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2016-04-05T11:35:19Z,paulolieuthier,paulolieuthier@gmail.com https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2016-04-05T13:24:53Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2017-07-27T10:36:06Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2018-10-01T04:26:26Z,estebank,NA https://github.com/rust-lang/rust/pull/32586,MERGED,2016-03-29T18:45:52Z,2016-04-01T06:32:05Z,specialize ToString for str,seanmonstar,fc8cf9c5afd531e825b3ae9a57f618c149dd3893,2,specialize ToString for str,THUMBS_UP,2021-02-15T23:16:49Z,toddmath,tmatheson11186@gmail.com https://github.com/rust-lang/rust/pull/32635,MERGED,2016-03-31T03:06:25Z,2016-04-01T08:46:14Z,Make HashMap HashSet and their iterators properly covariant,gereeter,589108baf644ea44a10a7258d67da254e1e09fae,2,Test that HashMap HashSet and their iterators are properly covariant,THUMBS_UP,2016-03-31T17:20:56Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/32635,MERGED,2016-03-31T03:06:25Z,2016-04-01T08:46:14Z,Make HashMap HashSet and their iterators properly covariant,gereeter,589108baf644ea44a10a7258d67da254e1e09fae,2,Test that HashMap HashSet and their iterators are properly covariant,THUMBS_UP,2016-03-31T18:55:32Z,pczarn,NA https://github.com/rust-lang/rust/pull/32635,MERGED,2016-03-31T03:06:25Z,2016-04-01T08:46:14Z,Make HashMap HashSet and their iterators properly covariant,gereeter,589108baf644ea44a10a7258d67da254e1e09fae,2,Test that HashMap HashSet and their iterators are properly covariant,THUMBS_UP,2016-04-01T13:09:02Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32635,MERGED,2016-03-31T03:06:25Z,2016-04-01T08:46:14Z,Make HashMap HashSet and their iterators properly covariant,gereeter,589108baf644ea44a10a7258d67da254e1e09fae,2,Test that HashMap HashSet and their iterators are properly covariant,THUMBS_UP,2016-04-01T13:35:42Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32643,MERGED,2016-03-31T12:18:15Z,2016-04-01T17:49:28Z,Change Arc to use compare_exchange instead of compare_and_swap,Amanieu,9a28d4edc9375e5bf606c453d1e03a45ae8be0af,2,Change Arc to use compare_exchange instead of compare_and_swap,THUMBS_UP,2016-04-04T20:24:41Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32651,CLOSED,2016-03-31T15:12:48Z,2016-04-15T00:08:22Z,Add target_has_floating_point property and make floats optional in libcore,phil-opp,NA,NA,NA,HOORAY,2016-03-31T16:23:09Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/32651,CLOSED,2016-03-31T15:12:48Z,2016-04-15T00:08:22Z,Add target_has_floating_point property and make floats optional in libcore,phil-opp,NA,NA,NA,HOORAY,2016-03-31T20:15:21Z,carlpaten,NA https://github.com/rust-lang/rust/pull/32651,CLOSED,2016-03-31T15:12:48Z,2016-04-15T00:08:22Z,Add target_has_floating_point property and make floats optional in libcore,phil-opp,NA,NA,NA,HOORAY,2016-04-01T10:54:58Z,oli-obk,NA https://github.com/rust-lang/rust/pull/32651,CLOSED,2016-03-31T15:12:48Z,2016-04-15T00:08:22Z,Add target_has_floating_point property and make floats optional in libcore,phil-opp,NA,NA,NA,HOORAY,2016-04-05T23:15:14Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/32651,CLOSED,2016-03-31T15:12:48Z,2016-04-15T00:08:22Z,Add target_has_floating_point property and make floats optional in libcore,phil-opp,NA,NA,NA,HOORAY,2016-04-12T07:27:27Z,amandasystems,mail@amandastjerna.se https://github.com/rust-lang/rust/pull/32659,CLOSED,2016-03-31T21:57:25Z,2016-04-08T00:37:08Z,"Don't ever emit ""aborting due to previous error""",brson,NA,NA,NA,THUMBS_DOWN,2016-04-02T14:18:28Z,respeccing,NA https://github.com/rust-lang/rust/pull/32659,CLOSED,2016-03-31T21:57:25Z,2016-04-08T00:37:08Z,"Don't ever emit ""aborting due to previous error""",brson,NA,NA,NA,THUMBS_UP,2016-04-08T00:29:01Z,brson,NA https://github.com/rust-lang/rust/pull/32695,MERGED,2016-04-03T05:22:54Z,2016-04-08T13:44:27Z,Drop the default buffer size to 8K,sfackler,8128817119e479b0610685e3fc7a6ff21cde5abc,1,Drop the default buffer size to 8K The 64k capacity was picked by me a couple of years ago in the initial implementation of buffered IO adaptors: https://github.com/rust-lang/rust/pull/9091/files#diff-b131eeef531ad098b32f49695a031008R62. 64K was picked for symmetry with libuv which we no longer use. 64K is *way* larger than the default size of any other language that I can find. C C++ and Java default to 8K and Go defaults to 4K. There have been a variety of issues filed relating to this such as #31885. Closes #31885,THUMBS_UP,2016-04-04T01:11:06Z,Aatch,james@aatch.net https://github.com/rust-lang/rust/pull/32695,MERGED,2016-04-03T05:22:54Z,2016-04-08T13:44:27Z,Drop the default buffer size to 8K,sfackler,8128817119e479b0610685e3fc7a6ff21cde5abc,1,Drop the default buffer size to 8K The 64k capacity was picked by me a couple of years ago in the initial implementation of buffered IO adaptors: https://github.com/rust-lang/rust/pull/9091/files#diff-b131eeef531ad098b32f49695a031008R62. 64K was picked for symmetry with libuv which we no longer use. 64K is *way* larger than the default size of any other language that I can find. C C++ and Java default to 8K and Go defaults to 4K. There have been a variety of issues filed relating to this such as #31885. Closes #31885,THUMBS_UP,2016-04-05T13:15:47Z,bluss,NA https://github.com/rust-lang/rust/pull/32695,MERGED,2016-04-03T05:22:54Z,2016-04-08T13:44:27Z,Drop the default buffer size to 8K,sfackler,8128817119e479b0610685e3fc7a6ff21cde5abc,1,Drop the default buffer size to 8K The 64k capacity was picked by me a couple of years ago in the initial implementation of buffered IO adaptors: https://github.com/rust-lang/rust/pull/9091/files#diff-b131eeef531ad098b32f49695a031008R62. 64K was picked for symmetry with libuv which we no longer use. 64K is *way* larger than the default size of any other language that I can find. C C++ and Java default to 8K and Go defaults to 4K. There have been a variety of issues filed relating to this such as #31885. Closes #31885,THUMBS_UP,2016-04-09T02:55:52Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32695,MERGED,2016-04-03T05:22:54Z,2016-04-08T13:44:27Z,Drop the default buffer size to 8K,sfackler,8128817119e479b0610685e3fc7a6ff21cde5abc,1,Drop the default buffer size to 8K The 64k capacity was picked by me a couple of years ago in the initial implementation of buffered IO adaptors: https://github.com/rust-lang/rust/pull/9091/files#diff-b131eeef531ad098b32f49695a031008R62. 64K was picked for symmetry with libuv which we no longer use. 64K is *way* larger than the default size of any other language that I can find. C C++ and Java default to 8K and Go defaults to 4K. There have been a variety of issues filed relating to this such as #31885. Closes #31885,THUMBS_UP,2016-04-11T13:11:46Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/32695,MERGED,2016-04-03T05:22:54Z,2016-04-08T13:44:27Z,Drop the default buffer size to 8K,sfackler,8128817119e479b0610685e3fc7a6ff21cde5abc,1,Drop the default buffer size to 8K The 64k capacity was picked by me a couple of years ago in the initial implementation of buffered IO adaptors: https://github.com/rust-lang/rust/pull/9091/files#diff-b131eeef531ad098b32f49695a031008R62. 64K was picked for symmetry with libuv which we no longer use. 64K is *way* larger than the default size of any other language that I can find. C C++ and Java default to 8K and Go defaults to 4K. There have been a variety of issues filed relating to this such as #31885. Closes #31885,THUMBS_UP,2021-04-28T23:05:40Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/32699,MERGED,2016-04-03T14:17:42Z,2016-04-07T17:55:44Z,Specialize equality for [T] and comparison for [u8] to use memcmp when possible,bluss,a6c27be0b1074684ae918ab7132bbeb8f75d4f2a,1,slice: Use doc(hidden) on private traits This should avoid the trait impls showing up in rustdoc.,HOORAY,2016-04-04T20:24:33Z,tikue,NA https://github.com/rust-lang/rust/pull/32699,MERGED,2016-04-03T14:17:42Z,2016-04-07T17:55:44Z,Specialize equality for [T] and comparison for [u8] to use memcmp when possible,bluss,a6c27be0b1074684ae918ab7132bbeb8f75d4f2a,1,slice: Use doc(hidden) on private traits This should avoid the trait impls showing up in rustdoc.,HOORAY,2016-04-11T13:12:03Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/32699,MERGED,2016-04-03T14:17:42Z,2016-04-07T17:55:44Z,Specialize equality for [T] and comparison for [u8] to use memcmp when possible,bluss,a6c27be0b1074684ae918ab7132bbeb8f75d4f2a,1,slice: Use doc(hidden) on private traits This should avoid the trait impls showing up in rustdoc.,HOORAY,2016-04-11T17:50:17Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/32699,MERGED,2016-04-03T14:17:42Z,2016-04-07T17:55:44Z,Specialize equality for [T] and comparison for [u8] to use memcmp when possible,bluss,a6c27be0b1074684ae918ab7132bbeb8f75d4f2a,1,slice: Use doc(hidden) on private traits This should avoid the trait impls showing up in rustdoc.,HOORAY,2016-04-11T19:03:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32699,MERGED,2016-04-03T14:17:42Z,2016-04-07T17:55:44Z,Specialize equality for [T] and comparison for [u8] to use memcmp when possible,bluss,a6c27be0b1074684ae918ab7132bbeb8f75d4f2a,1,slice: Use doc(hidden) on private traits This should avoid the trait impls showing up in rustdoc.,HOORAY,2016-11-23T10:31:04Z,arthurprs,NA https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-04T18:45:18Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",THUMBS_UP,2016-04-04T18:49:21Z,ketsuban,twwinwood@gmail.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",THUMBS_UP,2016-04-04T18:52:22Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-04T21:55:55Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",THUMBS_UP,2016-04-04T22:28:58Z,conradkleinespel,NA https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",THUMBS_DOWN,2016-04-04T23:13:23Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-05T00:04:23Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-05T13:00:07Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-12T00:58:08Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/32731,MERGED,2016-04-04T18:30:43Z,2016-04-08T08:16:39Z,mk: Hardcode the bootstrap key for each release,alexcrichton,c822546c9ebd79a245ca171a56f452b373ab623f,2,"mk: Hardcode the bootstrap key for each release Starting with the 1.10.0 release we would like to bootstrap all compilers from the previous stable release. For example the 1.10.0 compiler should bootstrap from the literal 1.9.0 release artifacts. To do this however we need a way to enable unstable features temporarily in a stable compiler (as the released compiler is stable) but it turns out we already have a way to do that! At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY` environment variable is set to this value then the compiler is allowed to ""cheat"" and use unstable features. This method of choosing the bootstrap key however is problematic for the intention of bootstrapping from the previous release. Each time a 1.9.0 compiler is created a new bootstrap key will be selected. That means that the 1.10.0 compiler will only compile from *our* literal release artifacts. Instead distributions would like to bootstrap from their own compilers so instead we simply hardcode the bootstrap key for each release. This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release string) as the bootstrap key. Consequently all 1.9.0 compilers no matter where they are compiled will have the same bootstrap key. Additionally we won't need to keep updating this as it'll be based on the release number anyway. Once the 1.9.0 beta has been created we can update the 1.10.0 nightly sources (the `master` branch at that time) to bootstrap from that release using this hard-coded bootstrap key. We will likely just hardcode into the makefiles what the previous bootstrap key was and we'll change that whenever the stage0 compiler is updated.",HOORAY,2016-04-15T06:02:58Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T00:23:39Z,durka,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T02:20:21Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T02:23:13Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T03:07:45Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-06T03:24:39Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T03:25:55Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T06:50:42Z,alexbool,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T07:14:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T08:26:52Z,ticki,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-06T10:30:06Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T13:51:01Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-06T14:59:05Z,marijnh,marijnh@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-06T16:20:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T18:04:15Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-06T18:04:17Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-06T23:17:59Z,killercup,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T01:30:17Z,Ryman,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T01:47:47Z,jwilm,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T01:52:03Z,azerupi,mathieudavid@mathieudavid.org https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T02:26:23Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T03:06:21Z,brendanzab,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T03:54:31Z,critiqjo,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T03:58:58Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T04:05:39Z,Byron,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T04:08:14Z,ExPixel,adolphc@outlook.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T04:48:14Z,alan-andrade,alan.andradec@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T05:24:01Z,reem,jonathan.reem@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T05:24:03Z,reem,jonathan.reem@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T05:27:47Z,tcr3dr,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T05:31:06Z,ftxqxd,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T06:40:42Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T07:19:34Z,jFransham,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T07:19:47Z,jFransham,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T07:21:55Z,pczarn,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T08:06:14Z,WaDelma,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T08:24:56Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T08:34:58Z,arrdem,me@arrdem.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T09:49:24Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T09:53:46Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T10:07:44Z,Luthaf,luthaf@luthaf.fr https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T10:46:30Z,fsommar,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T10:46:31Z,fsommar,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T11:21:18Z,syndbg,anton.synd.antonov@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T12:09:37Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T12:22:14Z,kvark,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T13:25:04Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T13:35:48Z,dginev,deyan.ginev@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T13:45:26Z,polyfractal,polyfractal@elastic.co https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T13:53:46Z,samqiu,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T13:53:54Z,samqiu,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T14:25:49Z,emoon,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T14:25:53Z,emoon,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T14:42:08Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T15:05:01Z,jonathantorres,jonathantorres41@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T15:18:57Z,JIghtuse,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T15:32:45Z,overdrivenpotato,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T16:42:26Z,boblehest,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T18:24:46Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T18:26:33Z,futile,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T18:50:26Z,mernen,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T19:40:08Z,diwic,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T19:44:06Z,mrhota,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T19:44:08Z,mrhota,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T19:44:15Z,mrhota,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T19:50:04Z,matthiasbeyer,mail@beyermatthias.de https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T19:56:14Z,arathunku,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T20:12:16Z,pointlessone,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T20:12:45Z,CvX,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T20:27:26Z,yuriks,yuriks@yuriks.net https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T20:39:09Z,wienski,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T21:00:44Z,Trevoke,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T21:01:17Z,tgross,tim@0x74696d.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-07T21:06:49Z,jeanm,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-07T21:50:46Z,indiv0,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-07T21:50:48Z,indiv0,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T01:19:27Z,markstory,mark@mark-story.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-08T11:01:32Z,nielsle,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T14:02:39Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T14:17:21Z,machuga,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T18:37:04Z,TheNeikos,neikos@neikos.email https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T20:46:42Z,Valloric,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-08T21:31:31Z,felipesere,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-09T03:45:15Z,smaximov,s.b.maximov@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-11T03:32:57Z,Byron,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-20T19:31:14Z,lambda,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-20T20:48:42Z,mcarton,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-22T07:58:39Z,vendethiel,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-04-22T07:58:39Z,vendethiel,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-22T07:58:41Z,vendethiel,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-22T11:07:38Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-04-27T16:39:58Z,dawid2193487,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-04-27T16:39:59Z,dawid2193487,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-05-02T08:10:27Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-05-02T19:24:37Z,adamhjk,adam@opscode.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-05-03T04:43:56Z,tari,NA https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_UP,2016-05-03T10:08:01Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-05-06T03:51:15Z,reddraggone9,cljenkins9@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HEART,2016-05-10T05:18:18Z,mythmon,mythmon@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,THUMBS_DOWN,2016-05-12T08:58:45Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/32756,MERGED,2016-04-05T23:54:20Z,2016-05-03T04:37:21Z,Overhaul borrowck error messages and compiler error formatting generally,nikomatsakis,9355a91224a6f715b94342c074e5bac1f9e820f3,1,assert we get at least two rendered lines back,HOORAY,2016-05-30T19:32:32Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/32761,MERGED,2016-04-06T04:28:04Z,2016-04-06T23:44:08Z,"avoid ""=="" in assert! when one of the values is a bool",tshepang,922e666820fef2f5d9bd7fa450b4a45d85fdd84a,5,"avoid ""=="" in assert! when one of the values is a bool",THUMBS_UP,2016-04-06T13:53:52Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/32761,MERGED,2016-04-06T04:28:04Z,2016-04-06T23:44:08Z,"avoid ""=="" in assert! when one of the values is a bool",tshepang,922e666820fef2f5d9bd7fa450b4a45d85fdd84a,5,"avoid ""=="" in assert! when one of the values is a bool",THUMBS_UP,2016-04-06T15:21:42Z,respeccing,NA https://github.com/rust-lang/rust/pull/32767,MERGED,2016-04-06T11:09:54Z,2016-04-06T16:27:26Z,Batch up all plugin breaking changes,Manishearth,552af51ffb9f4ae08a7ee3bf27b0e8309006ca6f,235,"Rollup merge of #32570 - eddyb:tis-but-a-front r=nikomatsakis r? @nikomatsakis Conflicts: src/librustc_save_analysis/lib.rs src/libsyntax/ast_util.rs",THUMBS_UP,2016-04-07T18:53:46Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-06T20:45:38Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-06T20:46:57Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-06T20:47:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-07T20:01:24Z,mrhota,NA https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HEART,2016-04-07T20:01:30Z,mrhota,NA https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HEART,2016-04-11T23:15:04Z,bluss,NA https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-12T13:16:15Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HEART,2016-04-12T13:16:16Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-15T10:36:24Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HOORAY,2016-04-15T11:55:25Z,MovingtoMars,definitelynotliam@gmail.com https://github.com/rust-lang/rust/pull/32779,MERGED,2016-04-06T20:43:16Z,2016-04-16T03:26:23Z,Add initial version of codegen unit partitioning for incremental compilation.,michaelwoerister,e8441b6784bffde062443590f1be7d6187ec9934,23,Add initial version of codegen unit partitioning for incremental compilation.,HEART,2016-04-15T11:55:25Z,MovingtoMars,definitelynotliam@gmail.com https://github.com/rust-lang/rust/pull/32785,MERGED,2016-04-07T00:13:13Z,2016-04-16T06:34:44Z,Implement `Default` for more types in the standard library,tbu-,3df35a01e9825bbdebb986f980095e468357975f,6,Implement `Default` for more types in the standard library Also add `Hash` to `std::cmp::Ordering` and most possible traits to `fmt::Error`.,THUMBS_UP,2016-04-27T11:43:44Z,bjorn3,NA https://github.com/rust-lang/rust/pull/32787,CLOSED,2016-04-07T03:24:46Z,2016-04-07T05:37:09Z,Rollup of 11 pull requests,Manishearth,NA,NA,NA,THUMBS_UP,2016-04-07T03:34:11Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32789,MERGED,2016-04-07T04:04:58Z,2016-04-07T17:55:47Z,resolve: Avoid emitting redundant path resolution errors,jseyfried,07dac9732d65dcb1f5aefc8be46ba366fb657d08,1,Fix tidy errors,THUMBS_UP,2016-04-07T18:51:56Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32791,MERGED,2016-04-07T09:14:28Z,2016-04-28T04:52:48Z,Feature gate clean,LeoTestard,fa23d108638b7117e84c99a8d36a9dbab7b56812,2,Remove some useless code.,THUMBS_UP,2016-04-08T19:43:01Z,brson,NA https://github.com/rust-lang/rust/pull/32791,MERGED,2016-04-07T09:14:28Z,2016-04-28T04:52:48Z,Feature gate clean,LeoTestard,fa23d108638b7117e84c99a8d36a9dbab7b56812,2,Remove some useless code.,THUMBS_UP,2016-04-09T00:01:37Z,jseyfried,NA https://github.com/rust-lang/rust/pull/32794,MERGED,2016-04-07T11:47:11Z,2016-04-07T17:55:47Z,Rollup of 7 pull requests,Manishearth,b0f81a3595febee93c853d561beca12eb917df8d,23,Rollup merge of #32789 - jseyfried:fix_duplicate_resolve_errors r=eddyb resolve: Avoid emitting redundant path resolution errors This PR avoids emitting redundant path resolution errors in `resolve` (fixes #32760). r? @eddyb,THUMBS_UP,2016-04-07T18:50:52Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32803,MERGED,2016-04-07T19:47:05Z,2016-04-13T05:21:29Z,Initial implementation of debuginfo in MIR trans.,eddyb,373b6ec935fb64767d03da9a79d4614ccbb3f084,17,tests: update for MIR debuginfo.,HOORAY,2016-04-07T19:47:33Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/32803,MERGED,2016-04-07T19:47:05Z,2016-04-13T05:21:29Z,Initial implementation of debuginfo in MIR trans.,eddyb,373b6ec935fb64767d03da9a79d4614ccbb3f084,17,tests: update for MIR debuginfo.,HOORAY,2016-04-12T18:25:12Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-07T20:49:46Z,pyfisch,NA https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-07T23:45:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HEART,2016-04-07T23:45:26Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-10T07:24:16Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-11T19:10:59Z,bluss,NA https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-12T09:11:01Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/32804,MERGED,2016-04-07T20:44:28Z,2016-04-12T14:15:02Z,std: Stabilize APIs for the 1.9 release,alexcrichton,552eda70d33cead1398adfecce1a75e7a61e3daf,58,"std: Stabilize APIs for the 1.9 release This commit applies all stabilizations renamings and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long ""final comment period"" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756",HOORAY,2016-04-17T15:09:08Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32810,MERGED,2016-04-07T23:21:21Z,2016-04-08T22:36:42Z,Release notes for 1.8,brson,94a387e3260338b9b1fa748dd00000739af8790c,1,Release notes for 1.8,THUMBS_UP,2016-04-09T00:10:36Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/32810,MERGED,2016-04-07T23:21:21Z,2016-04-08T22:36:42Z,Release notes for 1.8,brson,94a387e3260338b9b1fa748dd00000739af8790c,1,Release notes for 1.8,THUMBS_UP,2016-04-11T21:39:04Z,bluss,NA https://github.com/rust-lang/rust/pull/32865,MERGED,2016-04-10T04:46:30Z,2016-04-15T01:15:47Z,Add rustbuild option to use Ninja for LLVM build,caipre,7dd0bebff406dae343b8ae1b242940284986526d,1,Remove redundant assignment,THUMBS_UP,2016-04-10T10:57:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32880,MERGED,2016-04-11T10:04:57Z,2016-04-11T13:11:44Z,Review fixes for #32878,Manishearth,69095bb02393b861c062fa80cde717e9eb7b2d29,1,Tibet does not have a space program. Peru does.,THUMBS_UP,2016-04-11T10:06:52Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-04-14T08:52:45Z,mitsuhiko,armin.ronacher@active-4.com https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-04-15T17:53:08Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-05-10T15:32:54Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-05-10T21:38:02Z,tillarnold,NA https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-05-10T22:21:17Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-07-08T06:47:27Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2016-07-08T09:43:21Z,timothyklim,NA https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2018-04-01T07:11:45Z,DylanDmitri,d.dylan.g@gmail.com https://github.com/rust-lang/rust/pull/32900,MERGED,2016-04-12T02:34:46Z,2016-05-10T04:31:58Z,rustc: Implement custom panic runtimes,alexcrichton,38e6e5d0a9681b53cb517a3af665059e83988c3d,8,"rustc: Use C++ personalities on MSVC Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of ""personality function"" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler` but they both essentially are the ""most generic"" personality functions for catching exceptions and running cleanups. That is thse two personalities will run cleanups for all exceptions unconditionally so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to ""C++ exception-like unwining""). Also note that the standard library only *catches* Rust exceptions not others like segfaults and illegal instructions. LLVM has support for another personality `__CxxFrameHandler3` which does not run cleanups for general exceptions only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself but this... Closes #33112 Closes #33116",HOORAY,2019-04-02T18:28:01Z,ianklatzco,iklatzco@gmail.com https://github.com/rust-lang/rust/pull/32937,MERGED,2016-04-13T16:01:13Z,2016-04-15T01:15:51Z,Doc fix: Do not mention next project in book/guessing-game,deepak,a40629d2c9aa2a3bed2e4edaafa2303eb4b19854,1,Doc fix: Do not mention next project in book/guessing-game The next project refers to the dining-philosophers problem https://github.com/rust-lang/rust/blob/27a1834ce522e3ec7fe4726b1661de16ee30c503/src/doc/book/dining-philosophers.md which was removed in https://github.com/rust-lang/rust/commit/0c6c34de87c899ecb8b977e7ef24510ab2a68168 so removing reference to that project from book/guessing-game,HOORAY,2016-04-13T18:54:38Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-13T17:23:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-13T18:05:38Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-13T19:10:58Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-13T20:12:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-13T20:17:07Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-14T12:50:40Z,bluss,NA https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-15T07:19:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-15T11:52:25Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-15T17:56:57Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,THUMBS_DOWN,2016-04-25T09:41:54Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2016-04-25T16:32:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/32939,MERGED,2016-04-13T16:49:36Z,2016-04-20T16:58:03Z,Compute LLVM-agnostic type layouts in rustc.,eddyb,c7d564d8c96bf538cc64a3eeca1fcc3c99569625,14,Check transmutes between types without statically known sizes.,HEART,2017-02-10T06:33:52Z,jseyfried,NA https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-04-13T20:55:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-04-13T22:01:23Z,bluss,NA https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-04-14T08:25:03Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-04-20T10:59:18Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-06-13T15:29:45Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,THUMBS_UP,2016-07-08T06:54:53Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/32942,MERGED,2016-04-13T20:47:58Z,2016-04-20T10:45:01Z,mk: Bootstrap from stable instead of snapshots,alexcrichton,02538d463a350f5c3658f7aabefca16eb599d31c,23,mk: Bootstrap from stable instead of snapshots This commit removes all infrastructure from the repository for our so-called snapshots to instead bootstrap the compiler from stable releases. Bootstrapping from a previously stable release is a long-desired feature of distros because they're not fans of downloading binary stage0 blobs from us. Additionally this makes our own CI easier as we can decommission all of the snapshot builders and start having a regular cadence to when we update the stage0 compiler. A new `src/etc/get-stage0.py` script was added which shares some code with `src/bootstrap/bootstrap.py` to read a new file `src/stage0.txt` which lists the current stage0 compiler as well as cargo that we bootstrap from. This script will download the relevant `rustc` package an unpack it into `$target/stage0` as we do today. One problem of bootstrapping from stable releases is that we're not able to compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd). To overcome this we employ two strategies: * The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt` (enabled as a result of #32731) and exported by the build system. This enables nightly features in the compiler we download. * The standard library and compiler are pinned to a specific stage0 which doesn't change so we're guaranteed that we'll continue compiling as we start from a known fixed source. The process for making a release will also need to be tweaked now to continue to cadence of bootstrapping from the previous release. This process looks like: 1. Merge `beta` to `stable` 2. Produce a new stable compiler. 3. Change `master` to bootstrap from this new stable compiler. 4. Merge `master` to `beta` 5. Produce a new beta compiler 6. Change `master` to bootstrap from this new beta compiler. Step 3 above should involve very few changes as `master` was previously bootstrapping from `beta` which is the same as `stable` at that point in time. Step 6 however is where we benefit from removing lots of `#[cfg(stage0)]` and get to use new features. This also shouldn't slow the release too much as steps 1-5 requires little work other than waiting and step 6 just needs to happen at some point during a release cycle it's not time sensitive. Closes #29555 Closes #29557,HOORAY,2016-07-09T07:47:10Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32952,MERGED,2016-04-14T14:24:46Z,2016-04-17T06:06:35Z,Get all (but one) of debuginfo tests to pass with MIR codegen.,eddyb,e2ac9895d68b7bed9a8fc3d9ce270ae0129d2b74,2,mir: place match pattern bindings in their respective arms.,HEART,2016-04-14T18:58:01Z,brson,NA https://github.com/rust-lang/rust/pull/32968,MERGED,2016-04-14T20:23:43Z,2016-04-20T21:58:25Z,doc: Update our tier support,alexcrichton,9e436491823f4067bb3018042c4c87a325b5c7b6,1,"doc: Update our tier support This modifies our listing of tiered platforms a few ways: * All lists are alphabetized based on target now * Lots of targets are moved up to ""Tier 2"" as we're gating on all these builds and official releases are provided (and installable via rustup). * A few targets now list having a compiler + cargo now as well. No more platforms have been moved up to Tier 1 at this time however. The only real candidate is ``x86_64-unknown-linux-musl` but that's not *quite* to a tier 1 level of quality just yet so let's hold off for another release or so to iron it out a bit.",THUMBS_UP,2016-04-14T23:27:59Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-15T04:09:06Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-15T07:14:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-15T09:05:58Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-15T14:40:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-16T08:25:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-17T11:05:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-17T20:31:27Z,yigal100,NA https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HEART,2016-04-18T07:28:14Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/32980,MERGED,2016-04-15T00:57:04Z,2016-04-28T10:38:13Z,Various improvements to MIR and LLVM IR Construction,Aatch,5bda576cd6b3be40f62a37e134ee7245e911fb8b,2,Factor out function call checking to a helper method The logic for checking `call` and `invoke` instructions was duplicated between them so factor it out to a helper method.,HOORAY,2016-04-19T14:31:49Z,bluss,NA https://github.com/rust-lang/rust/pull/33020,MERGED,2016-04-16T01:27:26Z,2016-04-23T07:22:22Z,port compiletest to use JSON output,nikomatsakis,10d4cda9ed3df859342a47a33223b450a86f9798,1,Fix filepath check for macro backtrace,THUMBS_UP,2016-04-16T08:27:13Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33020,MERGED,2016-04-16T01:27:26Z,2016-04-23T07:22:22Z,port compiletest to use JSON output,nikomatsakis,10d4cda9ed3df859342a47a33223b450a86f9798,1,Fix filepath check for macro backtrace,THUMBS_UP,2016-04-16T09:05:49Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/33020,MERGED,2016-04-16T01:27:26Z,2016-04-23T07:22:22Z,port compiletest to use JSON output,nikomatsakis,10d4cda9ed3df859342a47a33223b450a86f9798,1,Fix filepath check for macro backtrace,THUMBS_UP,2016-04-16T09:08:03Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/33020,MERGED,2016-04-16T01:27:26Z,2016-04-23T07:22:22Z,port compiletest to use JSON output,nikomatsakis,10d4cda9ed3df859342a47a33223b450a86f9798,1,Fix filepath check for macro backtrace,THUMBS_UP,2016-04-20T19:30:23Z,mcarton,NA https://github.com/rust-lang/rust/pull/33020,MERGED,2016-04-16T01:27:26Z,2016-04-23T07:22:22Z,port compiletest to use JSON output,nikomatsakis,10d4cda9ed3df859342a47a33223b450a86f9798,1,Fix filepath check for macro backtrace,THUMBS_UP,2016-04-24T21:39:23Z,llogiq,NA https://github.com/rust-lang/rust/pull/33064,MERGED,2016-04-18T01:12:14Z,2016-04-18T05:39:23Z,resolve: Improve performance,jseyfried,6ae80273a08c9cb0b75b8aec464f1e7d838a2bda,1,resolve: improve performance,THUMBS_UP,2016-04-18T19:10:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/33089,MERGED,2016-04-19T04:59:09Z,2016-04-22T14:01:06Z,Move def id collection and extern crate handling to before AST->HIR lowering,nrc,0be3c8c56977c1f0d875461279e00bca7b4e5ebf,3,rebasing,THUMBS_UP,2016-04-20T02:08:01Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33100,CLOSED,2016-04-19T23:20:59Z,2016-04-22T20:42:52Z,syntax: Always parse `pub ( path_start` in tuple structs as visibility,petrochenkov,NA,NA,NA,THUMBS_UP,2016-04-22T19:07:19Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33106,CLOSED,2016-04-20T11:45:59Z,2016-04-21T13:17:40Z,generate MIR for constants and statics,oli-obk,NA,NA,NA,HEART,2016-04-20T17:30:38Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33108,CLOSED,2016-04-20T14:50:35Z,2016-05-05T00:12:46Z,impl From for (),SimonSapin,NA,NA,NA,THUMBS_UP,2016-05-03T01:00:27Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/33108,CLOSED,2016-04-20T14:50:35Z,2016-05-05T00:12:46Z,impl From for (),SimonSapin,NA,NA,NA,THUMBS_DOWN,2016-05-03T02:28:10Z,brson,NA https://github.com/rust-lang/rust/pull/33108,CLOSED,2016-04-20T14:50:35Z,2016-05-05T00:12:46Z,impl From for (),SimonSapin,NA,NA,NA,THUMBS_DOWN,2016-05-03T09:12:37Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/33128,MERGED,2016-04-21T12:24:23Z,2016-05-05T18:45:21Z,Add more aliases for Unicode confusable chars,xen0n,496081c5c7bdf3afc2e444c166ee875b4f9041e5,1,add more confusable CJK square bracket aliases,HEART,2016-05-09T21:45:28Z,Havvy,NA https://github.com/rust-lang/rust/pull/33128,MERGED,2016-04-21T12:24:23Z,2016-05-05T18:45:21Z,Add more aliases for Unicode confusable chars,xen0n,496081c5c7bdf3afc2e444c166ee875b4f9041e5,1,add more confusable CJK square bracket aliases,HEART,2016-07-14T09:36:16Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HEART,2016-04-21T15:18:37Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HOORAY,2016-04-24T00:42:08Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HEART,2016-04-26T23:49:27Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HOORAY,2016-04-27T08:30:54Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HOORAY,2016-05-09T17:57:49Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/33130,MERGED,2016-04-21T13:04:45Z,2016-05-08T09:41:53Z,Implement constant support in MIR.,eddyb,3b0e27cc74d61e229aeaf0a710d3a018f7104ffc,2,trans: handle string literal reborrows.,HOORAY,2016-05-09T22:01:33Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/33135,CLOSED,2016-04-21T16:24:12Z,2016-05-04T14:36:55Z,Allow lifetimes to be passed to macros,sgrif,NA,NA,NA,HOORAY,2016-04-21T18:02:00Z,durka,NA https://github.com/rust-lang/rust/pull/33135,CLOSED,2016-04-21T16:24:12Z,2016-05-04T14:36:55Z,Allow lifetimes to be passed to macros,sgrif,NA,NA,NA,THUMBS_UP,2016-04-22T04:26:30Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/33138,MERGED,2016-04-21T20:10:55Z,2016-05-06T15:32:03Z,Short-cut `T: Sized` trait selection for ADTs,arielb1,238e4ee104179c5a6beb5bb25ffe28a3fd77bff5,4,fixes,HEART,2016-04-22T09:45:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33138,MERGED,2016-04-21T20:10:55Z,2016-05-06T15:32:03Z,Short-cut `T: Sized` trait selection for ADTs,arielb1,238e4ee104179c5a6beb5bb25ffe28a3fd77bff5,4,fixes,HEART,2016-04-22T23:09:09Z,bluss,NA https://github.com/rust-lang/rust/pull/33149,CLOSED,2016-04-22T06:23:18Z,2016-05-11T22:39:55Z,Move `::std::error` to `::core::error`,thepowersgang,NA,NA,NA,THUMBS_UP,2020-09-10T07:06:48Z,kacejot,NA https://github.com/rust-lang/rust/pull/33160,MERGED,2016-04-23T03:37:11Z,2016-04-26T07:36:15Z,show unstable status for deprecated items,euclio,c7c34fdace12fb08e1c00f16fce58abe95835bf8,2,show unstable status for deprecated items,THUMBS_UP,2016-04-24T17:32:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/33160,MERGED,2016-04-23T03:37:11Z,2016-04-26T07:36:15Z,show unstable status for deprecated items,euclio,c7c34fdace12fb08e1c00f16fce58abe95835bf8,2,show unstable status for deprecated items,THUMBS_UP,2016-04-24T20:38:16Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/33171,MERGED,2016-04-23T21:40:21Z,2016-04-28T23:48:20Z,"Some preliminary work towards making trans ""collector driven"".",michaelwoerister,0fc9f9a20080753426772eac77d4d135ccd01ab7,15,Make the codegen unit partitioner also emit item declarations.,HOORAY,2016-04-26T20:07:51Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33189,CLOSED,2016-04-25T03:39:33Z,2016-06-28T20:44:01Z,Add ARM MUSL targets,timonvo,NA,NA,NA,HEART,2016-04-25T10:57:37Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/33211,MERGED,2016-04-26T04:56:43Z,2016-04-28T19:27:35Z,std: Add compatibility with android-9,alexcrichton,c31e2e77ed955faafffe7b22859f045cc1e5deec,5,std: Add compatibility with android-9 The Gecko folks currently use Android API level 9 for their builds so they're requesting that we move back our minimum supported API level from 18 to 9. Turns out ABI-wise at least there's not that many changes we need to take care of. The `ftruncate64` API appeared in android-12 and the `log2` and `log2f` APIs appeared in android-18. We can have a simple shim for `ftruncate64` which falls back on `ftruncate` and the `log2` function can be approximated with just `ln(f) / ln(2)`. This should at least get the standard library building on API level 9 although the tests aren't quite happening there just yet. As we seem to be growing a number of Android compatibility shims they're now centralized in a common `sys::android` module.,THUMBS_UP,2016-04-26T13:08:29Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/33211,MERGED,2016-04-26T04:56:43Z,2016-04-28T19:27:35Z,std: Add compatibility with android-9,alexcrichton,c31e2e77ed955faafffe7b22859f045cc1e5deec,5,std: Add compatibility with android-9 The Gecko folks currently use Android API level 9 for their builds so they're requesting that we move back our minimum supported API level from 18 to 9. Turns out ABI-wise at least there's not that many changes we need to take care of. The `ftruncate64` API appeared in android-12 and the `log2` and `log2f` APIs appeared in android-18. We can have a simple shim for `ftruncate64` which falls back on `ftruncate` and the `log2` function can be approximated with just `ln(f) / ln(2)`. This should at least get the standard library building on API level 9 although the tests aren't quite happening there just yet. As we seem to be growing a number of Android compatibility shims they're now centralized in a common `sys::android` module.,THUMBS_UP,2016-04-28T11:04:57Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/33212,MERGED,2016-04-26T06:18:31Z,2016-04-28T17:11:53Z,Improve error message about regions of function body,bombless,93486180d99e6216941f72a1a3deff25545a181b,1,Improve error message about regions of function body,HEART,2016-04-26T08:04:08Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/33218,MERGED,2016-04-26T14:28:33Z,2016-04-28T17:11:54Z,allow InternedString to be compared to &str directly,oli-obk,6343f261f4aeacdd292bf07998ef5faf6e90d57b,2,allow InternedString to be compared to &str directly,THUMBS_UP,2016-04-26T16:32:24Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/33224,MERGED,2016-04-26T22:25:44Z,2016-05-09T23:11:54Z,std: Allow creating ExitStatus from raw values,alexcrichton,7f09b1f6a64339370440025d50d0ad4a7f239734,5,std: Allow creating ExitStatus from raw values Sometimes a process may be waited on externally from the standard library in which case it can be useful to create a raw `ExitStatus` structure to return. This commit extends the existing Unix `ExitStatusExt` extension trait and adds a new Windows-specific `ExitStatusExt` extension trait to do this. The methods are currently called `ExitStatus::from_raw`. cc #32713,THUMBS_UP,2016-04-26T22:27:56Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/33224,MERGED,2016-04-26T22:25:44Z,2016-05-09T23:11:54Z,std: Allow creating ExitStatus from raw values,alexcrichton,7f09b1f6a64339370440025d50d0ad4a7f239734,5,std: Allow creating ExitStatus from raw values Sometimes a process may be waited on externally from the standard library in which case it can be useful to create a raw `ExitStatus` structure to return. This commit extends the existing Unix `ExitStatusExt` extension trait and adds a new Windows-specific `ExitStatusExt` extension trait to do this. The methods are currently called `ExitStatus::from_raw`. cc #32713,THUMBS_UP,2016-04-26T22:28:11Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/33228,MERGED,2016-04-26T23:53:13Z,2016-05-07T01:15:41Z,Move auxiliary directories to live with the tests,nikomatsakis,707012494dcb66d55efebedbd7727469d3baa2b2,3,remove stray files in auxiliary directory,HOORAY,2016-05-05T04:32:27Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/33260,MERGED,2016-04-28T17:26:46Z,2016-05-11T19:07:11Z,add help on pattern guard,mrmiywj,201d9ed0bbf05a8cc7015165a8f36bb87ef79a60,1,add help on pattern guard fix too long column fix typo of help on pattern guard one nit fix compile fail,HOORAY,2016-05-01T08:26:18Z,arrowrowe,NA https://github.com/rust-lang/rust/pull/33260,MERGED,2016-04-28T17:26:46Z,2016-05-11T19:07:11Z,add help on pattern guard,mrmiywj,201d9ed0bbf05a8cc7015165a8f36bb87ef79a60,1,add help on pattern guard fix too long column fix typo of help on pattern guard one nit fix compile fail,HOORAY,2016-05-04T04:26:41Z,gaocegege,cegao@tensorchord.ai https://github.com/rust-lang/rust/pull/33328,MERGED,2016-05-01T22:55:54Z,2016-05-07T10:01:51Z,rustdoc: refactor rustdoc syntax highlighting for a more flexible API,nrc,25160af4b4bd2234a1adbb90579b24a0d2636aeb,1,rustdoc: refactor rustdoc syntax highlighting for a more flexible API Clients can now use the rustdoc syntax highlighter to classify tokens then use that info to put together there own HTML (or whatever) rather than just having static HTML output.,THUMBS_UP,2016-05-07T08:17:09Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/33333,MERGED,2016-05-02T05:38:43Z,2016-05-07T12:11:01Z,parser: show a helpful note on unexpected inner comment,birkenfeld,72560e14039525cf70bcf3343524790978a27475,2,parser: show a helpful note on unexpected inner comment Fixes: #30318.,HOORAY,2016-05-07T12:30:18Z,est31,NA https://github.com/rust-lang/rust/pull/33360,MERGED,2016-05-02T22:18:47Z,2016-05-09T03:07:17Z,rustbuild: Document many more parts of the build,alexcrichton,f72bfe6661b35fd012fee100c673dafd1aec15f7,19,rustbuild: Document many more parts of the build This commit expands the bootstrap build system's `README.md` as well as ensuring that all API documentation is present and up-to-date. Additionally a new `config.toml.example` file is checked in with commented out versions of all possible configuration values.,HOORAY,2016-05-02T22:29:37Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/33360,MERGED,2016-05-02T22:18:47Z,2016-05-09T03:07:17Z,rustbuild: Document many more parts of the build,alexcrichton,f72bfe6661b35fd012fee100c673dafd1aec15f7,19,rustbuild: Document many more parts of the build This commit expands the bootstrap build system's `README.md` as well as ensuring that all API documentation is present and up-to-date. Additionally a new `config.toml.example` file is checked in with commented out versions of all possible configuration values.,HOORAY,2016-05-03T07:33:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33360,MERGED,2016-05-02T22:18:47Z,2016-05-09T03:07:17Z,rustbuild: Document many more parts of the build,alexcrichton,f72bfe6661b35fd012fee100c673dafd1aec15f7,19,rustbuild: Document many more parts of the build This commit expands the bootstrap build system's `README.md` as well as ensuring that all API documentation is present and up-to-date. Additionally a new `config.toml.example` file is checked in with commented out versions of all possible configuration values.,HOORAY,2016-05-08T01:10:29Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/33360,MERGED,2016-05-02T22:18:47Z,2016-05-09T03:07:17Z,rustbuild: Document many more parts of the build,alexcrichton,f72bfe6661b35fd012fee100c673dafd1aec15f7,19,rustbuild: Document many more parts of the build This commit expands the bootstrap build system's `README.md` as well as ensuring that all API documentation is present and up-to-date. Additionally a new `config.toml.example` file is checked in with commented out versions of all possible configuration values.,HOORAY,2016-05-08T19:15:54Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/33371,MERGED,2016-05-03T11:12:20Z,2016-05-05T00:38:50Z,rustdoc: fix inserting source code spans for constant values,birkenfeld,24117f3c589dca680bdfe7e193e52e210770dc79,3,rustdoc: fix inserting source code spans for constant values This will go wrong when the constants partially result from macro expansion. Instead use the expressions and pretty-print them as Rust code. Fixes: #33302,HEART,2016-05-03T14:02:01Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/33382,MERGED,2016-05-03T17:21:00Z,2016-05-07T23:43:06Z,"rustdoc: add ""src"" links to individual impls",birkenfeld,89aa04299451baf73750c8480d14471dfced44db,1,"rustdoc: add ""src"" links to individual impls Since these impls can be scattered around quite a bit it is nice to be able to jump to the location where individual methods and trait impls are defined. Fixes: #30416",THUMBS_UP,2016-05-03T17:29:51Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33382,MERGED,2016-05-03T17:21:00Z,2016-05-07T23:43:06Z,"rustdoc: add ""src"" links to individual impls",birkenfeld,89aa04299451baf73750c8480d14471dfced44db,1,"rustdoc: add ""src"" links to individual impls Since these impls can be scattered around quite a bit it is nice to be able to jump to the location where individual methods and trait impls are defined. Fixes: #30416",THUMBS_UP,2016-05-03T21:38:28Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/33382,MERGED,2016-05-03T17:21:00Z,2016-05-07T23:43:06Z,"rustdoc: add ""src"" links to individual impls",birkenfeld,89aa04299451baf73750c8480d14471dfced44db,1,"rustdoc: add ""src"" links to individual impls Since these impls can be scattered around quite a bit it is nice to be able to jump to the location where individual methods and trait impls are defined. Fixes: #30416",THUMBS_UP,2016-05-04T13:02:06Z,retep998,NA https://github.com/rust-lang/rust/pull/33382,MERGED,2016-05-03T17:21:00Z,2016-05-07T23:43:06Z,"rustdoc: add ""src"" links to individual impls",birkenfeld,89aa04299451baf73750c8480d14471dfced44db,1,"rustdoc: add ""src"" links to individual impls Since these impls can be scattered around quite a bit it is nice to be able to jump to the location where individual methods and trait impls are defined. Fixes: #30416",THUMBS_UP,2016-05-05T15:06:29Z,durka,NA https://github.com/rust-lang/rust/pull/33382,MERGED,2016-05-03T17:21:00Z,2016-05-07T23:43:06Z,"rustdoc: add ""src"" links to individual impls",birkenfeld,89aa04299451baf73750c8480d14471dfced44db,1,"rustdoc: add ""src"" links to individual impls Since these impls can be scattered around quite a bit it is nice to be able to jump to the location where individual methods and trait impls are defined. Fixes: #30416",THUMBS_UP,2016-05-08T18:25:19Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33388,CLOSED,2016-05-03T20:21:37Z,2016-05-19T12:26:18Z,Fix for expected/found not showing in old school mode,jntrnr,NA,NA,NA,THUMBS_UP,2016-05-04T07:17:18Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HEART,2016-05-03T21:05:37Z,durka,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-03T21:46:20Z,hexsel,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_DOWN,2016-05-04T06:59:04Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-04T07:14:19Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-04T07:50:38Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-04T10:24:13Z,llogiq,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-04T20:52:15Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HEART,2016-05-04T20:52:16Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HEART,2016-05-05T15:59:53Z,est31,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HEART,2016-05-11T13:33:31Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,CONFUSED,2016-05-11T15:49:49Z,yigal100,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HEART,2016-05-12T09:26:49Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-12T09:26:51Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HOORAY,2016-05-12T21:32:17Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-16T00:02:42Z,Diggsey,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-18T09:04:18Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-18T11:46:45Z,diwic,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-18T19:44:26Z,ticki,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,HOORAY,2016-05-21T08:00:19Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-21T08:00:26Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-05-25T02:53:09Z,tikue,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-06-16T20:10:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33389,CLOSED,2016-05-03T20:35:56Z,2016-07-19T22:23:55Z,Use a Carrier trait with the `?` operator,nrc,NA,NA,NA,THUMBS_UP,2016-11-07T20:52:49Z,Congee,NA https://github.com/rust-lang/rust/pull/33401,MERGED,2016-05-04T16:50:17Z,2016-05-12T02:48:59Z,Add rustc_on_unimplemented for Index implementation on slice,GuillaumeGomez,4a3acfd9371f59368108ad5e7be28f4268ed862b,1,Update to eddyb's PR,HEART,2016-05-04T17:13:19Z,durka,NA https://github.com/rust-lang/rust/pull/33401,MERGED,2016-05-04T16:50:17Z,2016-05-12T02:48:59Z,Add rustc_on_unimplemented for Index implementation on slice,GuillaumeGomez,4a3acfd9371f59368108ad5e7be28f4268ed862b,1,Update to eddyb's PR,HOORAY,2016-05-12T03:01:38Z,durka,NA https://github.com/rust-lang/rust/pull/33420,MERGED,2016-05-05T02:10:42Z,2016-05-08T16:13:27Z,implement RFC 1521,durka,c5aa8794908425a36e71e9628a23c5d15f66c65e,1,implement RFC 1521 Adds documentation to Clone specifying that Copy types should have a trivial Clone impl. Fixes #33416.,THUMBS_UP,2016-05-05T16:30:34Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-05-05T18:19:40Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-05-05T18:20:53Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-05-13T16:03:28Z,bluss,NA https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-05-15T23:34:28Z,llogiq,NA https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-07-07T21:06:49Z,slonopotamus,marat@slonopotamus.org https://github.com/rust-lang/rust/pull/33425,MERGED,2016-05-05T04:51:56Z,2016-05-11T10:00:03Z,Split the type context into a global and a local (inference-only) one.,eddyb,42eb7032fab11aca9228d42969f471b581444c56,27,Fixup indentation after methodification.,HEART,2016-07-09T07:22:03Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33426,MERGED,2016-05-05T05:46:20Z,2016-05-08T16:13:27Z,Implement RFC 1542,sfackler,a9779df1886e18923f40cf0bb67ab72d4e4942df,7,Implement RFC 1542 cc #33417,THUMBS_UP,2016-05-06T19:20:18Z,kamalmarhubi,NA https://github.com/rust-lang/rust/pull/33426,MERGED,2016-05-05T05:46:20Z,2016-05-08T16:13:27Z,Implement RFC 1542,sfackler,a9779df1886e18923f40cf0bb67ab72d4e4942df,7,Implement RFC 1542 cc #33417,THUMBS_UP,2016-05-07T09:20:23Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/33426,MERGED,2016-05-05T05:46:20Z,2016-05-08T16:13:27Z,Implement RFC 1542,sfackler,a9779df1886e18923f40cf0bb67ab72d4e4942df,7,Implement RFC 1542 cc #33417,HOORAY,2016-05-07T09:21:02Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/33426,MERGED,2016-05-05T05:46:20Z,2016-05-08T16:13:27Z,Implement RFC 1542,sfackler,a9779df1886e18923f40cf0bb67ab72d4e4942df,7,Implement RFC 1542 cc #33417,HEART,2016-05-08T01:10:42Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/33426,MERGED,2016-05-05T05:46:20Z,2016-05-08T16:13:27Z,Implement RFC 1542,sfackler,a9779df1886e18923f40cf0bb67ab72d4e4942df,7,Implement RFC 1542 cc #33417,HEART,2016-05-09T22:25:51Z,hauleth,NA https://github.com/rust-lang/rust/pull/33437,MERGED,2016-05-05T18:25:25Z,2016-05-07T23:43:11Z,doc: Update reference with better description of target_env,brson,2912bfb2b94c302e7395e49d8683356be5b9103e,1,doc: Update reference with better description of target_env The definition of this value recently changed slightly. It no longer corresponds directly to the target triple. Also shuffled things around to make the order of cfg descriptions more logical and added text related them to the target triple. cc #33403,THUMBS_UP,2016-05-05T19:10:35Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/33438,MERGED,2016-05-05T19:13:11Z,2016-05-07T23:43:11Z,Fix some some duplicate words.,birkenfeld,26eb2bef2591ddb4cdf45d256cdcfa7c7353b0fc,11,Fix some some duplicate words.,LAUGH,2016-05-06T22:18:41Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/33443,MERGED,2016-05-05T22:25:41Z,2016-05-10T06:50:17Z,Perform name resolution before and during ast->hir lowering,jseyfried,805666a4d283b60f9f4b979b53b3d498cd876f2e,6,Fix fallout in `librustdoc` and in tests,HOORAY,2016-05-05T22:29:55Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-06T13:59:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-06T15:14:34Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-07T01:09:43Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-19T16:53:26Z,flosse,NA https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-21T17:14:18Z,pczarn,NA https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-05-23T21:45:38Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/33460,MERGED,2016-05-06T13:45:38Z,2016-06-04T08:23:07Z,Support 16-bit pointers as well as i/usize,shepmaster,bc7595c8abbf4e3b737e926d61814686e0ebda77,18,Support 16-bit pointers as well as i/usize This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust,HEART,2016-08-23T00:30:02Z,mkoloberdin,NA https://github.com/rust-lang/rust/pull/33485,CLOSED,2016-05-07T18:51:14Z,2016-05-14T10:22:44Z,resolve: Make `self` unhygienic,petrochenkov,NA,NA,NA,THUMBS_UP,2016-05-07T20:36:10Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33485,CLOSED,2016-05-07T18:51:14Z,2016-05-14T10:22:44Z,resolve: Make `self` unhygienic,petrochenkov,NA,NA,NA,THUMBS_UP,2016-05-07T21:12:20Z,tinco,mail@tinco.nl https://github.com/rust-lang/rust/pull/33485,CLOSED,2016-05-07T18:51:14Z,2016-05-14T10:22:44Z,resolve: Make `self` unhygienic,petrochenkov,NA,NA,NA,THUMBS_UP,2016-05-09T03:01:45Z,durka,NA https://github.com/rust-lang/rust/pull/33485,CLOSED,2016-05-07T18:51:14Z,2016-05-14T10:22:44Z,resolve: Make `self` unhygienic,petrochenkov,NA,NA,NA,THUMBS_UP,2016-05-09T22:51:40Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/33485,CLOSED,2016-05-07T18:51:14Z,2016-05-14T10:22:44Z,resolve: Make `self` unhygienic,petrochenkov,NA,NA,NA,THUMBS_UP,2016-05-24T13:15:12Z,joelself,NA https://github.com/rust-lang/rust/pull/33491,MERGED,2016-05-08T00:17:41Z,2016-05-17T05:35:06Z,Replace the obligation forest with a graph,arielb1,65ad935737138eb307fdd01279ba5553a047bb6c,2,change on_unimplented logic,HOORAY,2016-05-13T00:30:31Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33508,MERGED,2016-05-09T04:38:49Z,2016-05-14T01:18:58Z,trans: Always lower to `frem`,alexcrichton,96b228835ad3a9b366e572ffb4d3cebee60d0f56,2,trans: Always lower to `frem` Long ago LLVM unfortunately didn't handle the 32-bit MSVC case of `frem` where it can't be lowered to `fmodf` because that symbol doesn't exist. That was since fixed in http://reviews.llvm.org/D12099 (landed as r246615) and was released in what appears to be LLVM 3.8. Now that we're using that branch of LLVM let's remove our own hacks and help LLVM optimize a little better by giving it knowledge about what we're doing.,LAUGH,2016-05-13T00:22:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33516,CLOSED,2016-05-09T15:55:26Z,2016-07-19T04:08:30Z,"doc: add a ""primitive type reference"" page",birkenfeld,NA,NA,NA,THUMBS_UP,2016-05-25T02:50:45Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-10T19:27:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-10T20:33:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T12:54:42Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T13:38:13Z,Jake-Shadle,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T14:00:54Z,bltavares,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T14:31:00Z,bluss,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T14:58:58Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-11T18:21:39Z,killercup,NA https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-12T05:33:58Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-12T08:51:06Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-12T19:09:06Z,andrew-d,andrew@du.nham.ca https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-13T03:31:31Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/33544,MERGED,2016-05-10T19:15:07Z,2016-05-14T13:49:16Z,Only break critical edges where actually needed,dotdash,00f6513259c12af733d22398b1ea77cff67b7beb,4,"Only break critical edges where actually needed Currently to prepare for MIR trans we break _all_ critical edges although we only actually need to do this for edges originating from a call that gets translated to an invoke instruction in LLVM. This has the unfortunate effect of undoing a bunch of the things that SimplifyCfg has done. A particularly bad case arises when you have a C-like enum with N variants and a derived PartialEq implementation. In that case the match on the (&lhs &rhs) tuple gets translated into nested matches with N arms each and a basic block each resulting in N² basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks but breaking the critical edges means that we go back to N². In nickel.rs there is such an enum with roughly N=800. So we get about 640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to reduce that to the final ""disr_a == disr_b"". So before this patch we had 2.5M lines of IR with 640K basic blocks which took about about 3.6s in LLVM to get optimized and translated. After this patch we get about 650K lines with about 1.6K basic blocks and spent a little less than 0.2s in LLVM. cc #33111",HEART,2016-05-16T21:48:29Z,bstrie,NA https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-05-11T14:24:03Z,retep998,NA https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-05-17T17:17:56Z,vadimcn,NA https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-05-24T11:21:14Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-05-24T11:34:39Z,emoon,NA https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,THUMBS_UP,2016-05-24T13:02:57Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,THUMBS_UP,2016-07-07T18:57:19Z,sjmackenzie,setori88@gmail.com https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-07-07T18:57:20Z,sjmackenzie,setori88@gmail.com https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,HOORAY,2016-07-08T09:32:05Z,kstep,milezv@gmail.com https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,THUMBS_UP,2016-07-25T04:19:34Z,qinwf,NA https://github.com/rust-lang/rust/pull/33553,MERGED,2016-05-11T01:24:02Z,2016-05-20T11:34:44Z,rustc: Add a new crate type cdylib,alexcrichton,0d2c26c261671f71002af13431fbd3c9720feff2,2,Mark the metadata symbol as reachable to fix OSX not finding dylibs.,THUMBS_UP,2018-09-12T18:51:19Z,maniart,mani.art@gmail.com https://github.com/rust-lang/rust/pull/33564,CLOSED,2016-05-11T19:42:42Z,2016-05-13T17:29:11Z,core: Add `Default::replace_default(&mut self)`,cuviper,NA,NA,NA,THUMBS_UP,2016-05-11T20:47:13Z,malbarbo,NA https://github.com/rust-lang/rust/pull/33564,CLOSED,2016-05-11T19:42:42Z,2016-05-13T17:29:11Z,core: Add `Default::replace_default(&mut self)`,cuviper,NA,NA,NA,THUMBS_DOWN,2016-05-13T05:27:54Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/33564,CLOSED,2016-05-11T19:42:42Z,2016-05-13T17:29:11Z,core: Add `Default::replace_default(&mut self)`,cuviper,NA,NA,NA,THUMBS_UP,2019-04-15T09:31:38Z,y-fujii,y-fujii@mimosa-pudica.net https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-12T16:13:41Z,brson,NA https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-12T17:46:34Z,durka,NA https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-12T18:11:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-12T19:17:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-17T07:55:29Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/33593,MERGED,2016-05-12T16:11:23Z,2016-05-15T07:49:44Z,Improve derived implementations for enums with lots of fieldless variants,dotdash,0eeb14eaba04025aa8a4612e1935f04f2ca3fb6b,13,Improve derived implementations for enums with lots of fieldless variants A number of trait methods like PartialEq::eq or Hash::hash don't actually need a distinct arm for each variant because the code within the arm only depends on the number and types of the fields in the variants. We can easily exploit this fact to create less and better code for enums with multiple variants that have no fields at all the extreme case being C-like enums. For nickel.rs and its by now infamous 800 variant enum this reduces optimized compile times by 25% and non-optimized compile times by 40%. Also peak memory usage is down by almost 40% (310MB down to 190MB). To be fair most other crates don't benefit nearly as much because they don't have as huge enums. The crates in the Rust distribution that I measured saw basically no change in compile times (I only tried optimized builds) and only 1-2% reduction in peak memory usage.,HEART,2016-05-18T03:17:18Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/33607,MERGED,2016-05-12T22:32:46Z,2016-05-15T12:27:01Z,Some simple improvements to MIR pretty printing,jonas-schievink,2c7e398935fe10aa2adea453ca0a2251b3c387e8,1,Indent comments less 40 chars is still enough indentation (most common MIR statements don't take more than 40 chars) and fits more easily in 80-character terminals.,THUMBS_UP,2016-05-12T22:45:46Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33607,MERGED,2016-05-12T22:32:46Z,2016-05-15T12:27:01Z,Some simple improvements to MIR pretty printing,jonas-schievink,2c7e398935fe10aa2adea453ca0a2251b3c387e8,1,Indent comments less 40 chars is still enough indentation (most common MIR statements don't take more than 40 chars) and fits more easily in 80-character terminals.,HOORAY,2016-05-12T23:29:59Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33607,MERGED,2016-05-12T22:32:46Z,2016-05-15T12:27:01Z,Some simple improvements to MIR pretty printing,jonas-schievink,2c7e398935fe10aa2adea453ca0a2251b3c387e8,1,Indent comments less 40 chars is still enough indentation (most common MIR statements don't take more than 40 chars) and fits more easily in 80-character terminals.,HOORAY,2016-05-12T23:48:05Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33607,MERGED,2016-05-12T22:32:46Z,2016-05-15T12:27:01Z,Some simple improvements to MIR pretty printing,jonas-schievink,2c7e398935fe10aa2adea453ca0a2251b3c387e8,1,Indent comments less 40 chars is still enough indentation (most common MIR statements don't take more than 40 chars) and fits more easily in 80-character terminals.,HOORAY,2016-05-16T15:12:25Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-13T19:57:40Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T19:57:48Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-13T19:58:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:31:30Z,durka,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-13T20:36:20Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:36:24Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-05-13T20:37:34Z,hexsel,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:41:37Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:46:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:52:35Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T20:55:53Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T21:05:59Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T21:08:50Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-13T21:19:20Z,tillarnold,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T00:14:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T00:19:43Z,retep998,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-14T00:19:45Z,retep998,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-05-14T00:19:47Z,retep998,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T05:57:15Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T06:35:33Z,samlh,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T07:03:11Z,bstrie,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T07:13:21Z,alexbool,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T11:30:55Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-14T13:46:02Z,Jake-Shadle,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T16:07:17Z,bluss,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-14T18:39:08Z,gereeter,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-16T01:38:23Z,andrew-d,andrew@du.nham.ca https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-05-17T09:35:17Z,vberger,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-22T04:52:43Z,xen0n,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-23T11:17:38Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-05-25T20:29:42Z,malbarbo,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-05-30T17:37:56Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T09:35:02Z,kornholi,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T10:55:30Z,Thiez,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T11:07:42Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T13:00:41Z,gandro,gandro@gmx.net https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-05T13:25:13Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T13:25:14Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T13:53:44Z,krdln,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T14:02:19Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T15:09:18Z,alex-gulyas,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T15:14:32Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T16:43:59Z,ivan,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-05T16:53:35Z,arthurprs,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-06-05T16:53:38Z,arthurprs,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T16:53:38Z,arthurprs,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T17:31:44Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-05T17:52:52Z,CryZe,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T18:14:25Z,item4,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-06-05T20:39:01Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-05T20:39:03Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-05T23:19:01Z,josephDunne,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-06T02:54:03Z,paulolieuthier,paulolieuthier@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-06T05:32:33Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-06T10:10:30Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-06T10:47:18Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-06-06T10:47:25Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HEART,2016-06-06T11:44:13Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-06T18:00:27Z,pczarn,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-07T16:22:33Z,chpio,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2016-06-10T12:12:06Z,friedroman,NA https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,THUMBS_UP,2016-09-22T12:27:09Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/33622,MERGED,2016-05-13T19:56:45Z,2016-06-05T10:12:42Z,[MIR] non-zeroing drop,arielb1,063f8826e7addbe644e3dfd532736ce72d8990bc,1,Update LLVM Picks up the fix for PR28005,HOORAY,2020-10-31T03:46:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,HEART,2016-05-14T08:53:57Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,HEART,2016-05-14T20:35:00Z,gereeter,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,THUMBS_UP,2016-05-17T18:47:30Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,HOORAY,2016-05-17T18:47:32Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,THUMBS_UP,2021-08-14T14:08:51Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,HOORAY,2021-08-14T14:08:53Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/33628,CLOSED,2016-05-14T00:55:48Z,2016-06-12T14:39:30Z,[WIP][MIR] Generic lattice-based DF framework,nagisa,NA,NA,NA,HEART,2021-08-14T14:08:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/33642,MERGED,2016-05-14T19:10:57Z,2016-07-13T23:27:33Z,Ergonomic format_args!,xen0n,51e54e57a45d7b956e3e3390db76ea2651f5d3b3,1,syntax_ext: format: better code documentation,THUMBS_UP,2016-05-14T19:41:26Z,durka,NA https://github.com/rust-lang/rust/pull/33642,MERGED,2016-05-14T19:10:57Z,2016-07-13T23:27:33Z,Ergonomic format_args!,xen0n,51e54e57a45d7b956e3e3390db76ea2651f5d3b3,1,syntax_ext: format: better code documentation,THUMBS_UP,2016-05-14T20:10:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33642,MERGED,2016-05-14T19:10:57Z,2016-07-13T23:27:33Z,Ergonomic format_args!,xen0n,51e54e57a45d7b956e3e3390db76ea2651f5d3b3,1,syntax_ext: format: better code documentation,THUMBS_UP,2016-07-06T03:02:48Z,ottworks,NA https://github.com/rust-lang/rust/pull/33642,MERGED,2016-05-14T19:10:57Z,2016-07-13T23:27:33Z,Ergonomic format_args!,xen0n,51e54e57a45d7b956e3e3390db76ea2651f5d3b3,1,syntax_ext: format: better code documentation,THUMBS_UP,2016-07-13T19:26:23Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/33654,MERGED,2016-05-15T12:39:55Z,2016-05-18T12:04:35Z,Remove hir::Ident,petrochenkov,02a1eef6e4eb4bcc214e0e00ddc62406c8990e2d,1,Fix rebase,HOORAY,2016-05-16T05:20:07Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33654,MERGED,2016-05-15T12:39:55Z,2016-05-18T12:04:35Z,Remove hir::Ident,petrochenkov,02a1eef6e4eb4bcc214e0e00ddc62406c8990e2d,1,Fix rebase,HOORAY,2016-05-16T10:48:16Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33654,MERGED,2016-05-15T12:39:55Z,2016-05-18T12:04:35Z,Remove hir::Ident,petrochenkov,02a1eef6e4eb4bcc214e0e00ddc62406c8990e2d,1,Fix rebase,HOORAY,2016-05-18T03:18:00Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33676,MERGED,2016-05-16T22:49:09Z,2016-05-21T03:33:44Z,Reword the short diagnostic for E0509,hanna-kruppe,e575d19acc095d2aeec58176e51a9551fa2e6e88,6,Reword the short diagnostic for E0509 Saying that a type *implements* a trait is much more idiomatic than saying it *defines* the trait.,THUMBS_UP,2016-05-17T05:04:17Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33679,MERGED,2016-05-17T01:27:46Z,2016-05-21T11:46:03Z,rustdoc: Add doc snippets for trait impls with a read more link,Manishearth,9ce018bafbda6f1d8484adf4796a48e5cf9093bb,2,Update tests,THUMBS_UP,2016-05-19T16:36:26Z,tikue,NA https://github.com/rust-lang/rust/pull/33679,MERGED,2016-05-17T01:27:46Z,2016-05-21T11:46:03Z,rustdoc: Add doc snippets for trait impls with a read more link,Manishearth,9ce018bafbda6f1d8484adf4796a48e5cf9093bb,2,Update tests,THUMBS_UP,2016-05-20T18:04:01Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/33735,MERGED,2016-05-19T05:42:47Z,2016-05-23T19:22:02Z,Allow `concat_idents!` in type positions as well as in expression positions,jseyfried,e99279428223683bc149c12db712c9bca5b74cac,2,Allow `concat_idents!` in type positions as well as in expression positions,HEART,2016-05-19T05:45:12Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/33735,MERGED,2016-05-19T05:42:47Z,2016-05-23T19:22:02Z,Allow `concat_idents!` in type positions as well as in expression positions,jseyfried,e99279428223683bc149c12db712c9bca5b74cac,2,Allow `concat_idents!` in type positions as well as in expression positions,HEART,2016-05-19T08:34:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33735,MERGED,2016-05-19T05:42:47Z,2016-05-23T19:22:02Z,Allow `concat_idents!` in type positions as well as in expression positions,jseyfried,e99279428223683bc149c12db712c9bca5b74cac,2,Allow `concat_idents!` in type positions as well as in expression positions,HEART,2016-05-19T11:34:49Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/33735,MERGED,2016-05-19T05:42:47Z,2016-05-23T19:22:02Z,Allow `concat_idents!` in type positions as well as in expression positions,jseyfried,e99279428223683bc149c12db712c9bca5b74cac,2,Allow `concat_idents!` in type positions as well as in expression positions,HEART,2016-05-19T13:02:14Z,alexbool,NA https://github.com/rust-lang/rust/pull/33735,MERGED,2016-05-19T05:42:47Z,2016-05-23T19:22:02Z,Allow `concat_idents!` in type positions as well as in expression positions,jseyfried,e99279428223683bc149c12db712c9bca5b74cac,2,Allow `concat_idents!` in type positions as well as in expression positions,HEART,2016-05-19T16:48:41Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33761,CLOSED,2016-05-20T17:06:56Z,2016-05-23T15:22:53Z,Rename std::io::Read::chars to utf8_chars.,SimonSapin,NA,NA,NA,THUMBS_UP,2016-05-21T13:50:01Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33761,CLOSED,2016-05-20T17:06:56Z,2016-05-23T15:22:53Z,Rename std::io::Read::chars to utf8_chars.,SimonSapin,NA,NA,NA,THUMBS_UP,2016-05-23T01:09:53Z,ollie27,NA https://github.com/rust-lang/rust/pull/33761,CLOSED,2016-05-20T17:06:56Z,2016-05-23T15:22:53Z,Rename std::io::Read::chars to utf8_chars.,SimonSapin,NA,NA,NA,THUMBS_UP,2016-05-24T22:31:29Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33765,MERGED,2016-05-21T02:50:25Z,2016-05-22T12:11:20Z,Added a `rustdoc` shortcut for collapse/expand all,alex-ozdemir,ab09fbca234d491fbd09857eb414d2586d283c67,3,"Added a `rustdoc` shortcut for collapse/expand all Now when the user presses the ""+"" key all sections will collapse/expand. Also added a note to the help screen which describes this behavior.",THUMBS_UP,2016-05-21T13:50:44Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/33775,CLOSED,2016-05-21T19:01:04Z,2016-07-19T04:15:03Z,Add a `PanicInfo::payload_as_str(&self) -> Option<&str>` method.,SimonSapin,NA,NA,NA,THUMBS_UP,2016-05-21T19:13:25Z,sfackler,NA https://github.com/rust-lang/rust/pull/33787,MERGED,2016-05-22T07:30:14Z,2016-05-24T05:44:31Z,Add --enable-local-rebuild to bootstrap from the current release,cuviper,0ca7d3dc1ffdf97284d62960a3c2170dae5f1e43,2,bootstrap: rename Config.rebuild to .local_rebuild,THUMBS_UP,2016-05-22T08:48:11Z,MagaTailor,NA https://github.com/rust-lang/rust/pull/33801,CLOSED,2016-05-22T23:09:17Z,2016-11-09T01:23:28Z,Read::chars reform,SimonSapin,NA,NA,NA,HOORAY,2016-05-27T14:28:36Z,jwilm,NA https://github.com/rust-lang/rust/pull/33815,MERGED,2016-05-23T14:46:40Z,2016-05-27T15:08:23Z,Trait documentation clarifications,carols10cents,1e809f57a45a187a2a8c49d4d93ec64c089873ca,1,"the trait `Hash` => ""the `Hash` trait""",THUMBS_UP,2020-07-25T20:47:48Z,MaxNanasy,NA https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-05-24T08:45:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-05-24T21:42:57Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-05-25T19:15:42Z,hexsel,NA https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-06-01T03:21:01Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-06-06T18:02:13Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-06-06T19:02:19Z,arthurprs,NA https://github.com/rust-lang/rust/pull/33816,MERGED,2016-05-23T15:14:23Z,2016-06-04T20:43:44Z,Projection cache and better warnings for #32330,nikomatsakis,480d18ca311f5e0de2b6b0003f6cd0746e142652,2,kill some unused imports,HEART,2016-06-07T06:37:05Z,Havvy,NA https://github.com/rust-lang/rust/pull/33832,MERGED,2016-05-24T05:30:55Z,2016-05-28T17:24:09Z,std: Use memalign not posix_memalign on Android,alexcrichton,33dfd0fb16a71cc3c96ca28b57eccbd1e278a3ac,1,std: Use memalign not posix_memalign on Android We've gotten requests to move our Android support as far back as API level 9 where unfortunately the `posix_memalign` API wasn't implemented yet. Thankfully however the `memalign` API was and it appears to be usable with `free` on the Android platform (see comments included in commit). This should help fix some of the last few test failures when compiling against API level 9.,HOORAY,2016-06-05T20:05:41Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/33840,CLOSED,2016-05-24T14:54:41Z,2017-01-04T16:08:38Z,[WIP] Macro rules backtracking,LeoTestard,NA,NA,NA,HOORAY,2016-05-24T17:14:22Z,durka,NA https://github.com/rust-lang/rust/pull/33840,CLOSED,2016-05-24T14:54:41Z,2017-01-04T16:08:38Z,[WIP] Macro rules backtracking,LeoTestard,NA,NA,NA,HOORAY,2016-05-25T11:47:35Z,bluss,NA https://github.com/rust-lang/rust/pull/33840,CLOSED,2016-05-24T14:54:41Z,2017-01-04T16:08:38Z,[WIP] Macro rules backtracking,LeoTestard,NA,NA,NA,HOORAY,2016-07-29T21:32:29Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/33840,CLOSED,2016-05-24T14:54:41Z,2017-01-04T16:08:38Z,[WIP] Macro rules backtracking,LeoTestard,NA,NA,NA,HOORAY,2016-08-07T02:52:31Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/33845,CLOSED,2016-05-24T16:15:26Z,2016-06-19T20:29:47Z,Add @aldeka's safe and unsafe Ferris to nomicon,steveklabnik,NA,NA,NA,HOORAY,2016-05-24T16:53:08Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/33845,CLOSED,2016-05-24T16:15:26Z,2016-06-19T20:29:47Z,Add @aldeka's safe and unsafe Ferris to nomicon,steveklabnik,NA,NA,NA,HEART,2016-05-24T16:53:11Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/33845,CLOSED,2016-05-24T16:15:26Z,2016-06-19T20:29:47Z,Add @aldeka's safe and unsafe Ferris to nomicon,steveklabnik,NA,NA,NA,HEART,2016-05-24T17:08:12Z,josephDunne,NA https://github.com/rust-lang/rust/pull/33845,CLOSED,2016-05-24T16:15:26Z,2016-06-19T20:29:47Z,Add @aldeka's safe and unsafe Ferris to nomicon,steveklabnik,NA,NA,NA,LAUGH,2016-05-24T17:49:45Z,aldeka,NA https://github.com/rust-lang/rust/pull/33845,CLOSED,2016-05-24T16:15:26Z,2016-06-19T20:29:47Z,Add @aldeka's safe and unsafe Ferris to nomicon,steveklabnik,NA,NA,NA,HEART,2016-08-04T12:29:31Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33867,MERGED,2016-05-25T12:05:22Z,2016-05-30T18:02:02Z,print enum variant fields in docs,oli-obk,b0c703304204f21ab6964d4b37776e7e5015cf7b,4,print enum variant fields in docs,THUMBS_UP,2016-05-26T23:06:06Z,mcarton,NA https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-26T19:46:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-26T19:47:22Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-26T19:56:33Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-26T19:58:00Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-26T20:38:16Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/33890,MERGED,2016-05-26T19:43:45Z,2016-07-08T22:00:10Z,Drive trans from the output of the translation item collector,michaelwoerister,1c03bfe3b43c06bc439c5369a180958eb4360361,10,trans: Adjust linkage assignment so that we don't need weak linkage.,HOORAY,2016-05-27T00:12:35Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/33892,MERGED,2016-05-26T21:36:34Z,2016-06-01T13:22:01Z,core: check pointer equality when comparing byte slices,seanmonstar,6af17e69ff5a69892aff4d82b293de2ec7f5050a,1,core: check pointer equality when comparing byte slices,HOORAY,2016-05-31T17:27:19Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T12:39:16Z,killercup,NA https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T14:21:40Z,alexbool,NA https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T14:28:41Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T17:18:29Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T18:01:22Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-27T18:27:01Z,bluss,NA https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-05-29T12:44:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-06-05T16:16:32Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/33905,MERGED,2016-05-27T12:16:58Z,2016-06-05T16:07:43Z,[MIR] Implement overflow checking,eddyb,cee244d4f02df90732c9e182f3567036ac695928,2,trans: update Luqmana's patch for generalized pair handling.,HOORAY,2016-06-06T17:34:00Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/33922,MERGED,2016-05-28T04:27:11Z,2016-08-20T05:56:30Z,Specific error message for missplaced doc comments,estebank,c8498cc2c27b699436c5f3d3759695926ee0c825,12,Specific error message for missplaced doc comments Identify when documetation comments have been missplaced in the following places: * After a struct element: ```rust // file.rs: struct X { a: u8 /** document a */ } ``` ```bash $ rustc file.rs file.rs:2:11: 2:28 error: found documentation comment that doesn't document anything file.rs:2 a: u8 /** document a */ ^~~~~~~~~~~~~~~~~ file.rs:2:11: 2:28 help: doc comments must come before what they document maybe a comment was intended with `//`? ``` * As the last line of a struct: ```rust // file.rs: struct X { a: u8 /// incorrect documentation } ``` ```bash $ rustc file.rs file.rs:3:5: 3:27 error: found a documentation comment that doesn't document anything file.rs:3 /// incorrect documentation ^~~~~~~~~~~~~~~~~~~~~~ file.rs:3:5: 3:27 help: doc comments must come before what they document maybe a comment was intended with `//`? ``` * As the last line of a `fn`: ```rust // file.rs: fn main() { let x = 1; /// incorrect documentation } ``` ```bash $ rustc file.rs file.rs:3:5: 3:27 error: found a documentation comment that doesn't document anything file.rs:3 /// incorrect documentation ^~~~~~~~~~~~~~~~~~~~~~ file.rs:3:5: 3:27 help: doc comments must come before what they document maybe a comment was intended with `//`? ``` Fix #27429 #30322,HEART,2016-08-30T01:08:07Z,Havvy,NA https://github.com/rust-lang/rust/pull/33929,MERGED,2016-05-28T15:15:14Z,2016-05-30T07:15:44Z,Separate bindings from other patterns in HIR,petrochenkov,ae999e9c8f063eb62c867eafdd86729acd798044,3,Address review comments,HOORAY,2016-05-28T17:00:20Z,jseyfried,NA https://github.com/rust-lang/rust/pull/33940,MERGED,2016-05-29T05:38:24Z,2016-07-02T01:43:32Z,hashmap: use siphash-1-3 as default hasher,seanmonstar,db1b1919baba8be48d997d9f70a6a5df7e31612a,6,std: use siphash-1-3 for HashMap,THUMBS_UP,2016-07-02T01:45:08Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/33976,MERGED,2016-05-31T06:30:55Z,2016-06-22T11:22:07Z,Add custom message parameter to `assert_eq!`,komamitsu,45a63d3ff611b1412f9d811cd328b648bada5ca2,2,Add message argument to `assert_eq` macro,THUMBS_UP,2016-08-19T06:40:03Z,sunjay,NA https://github.com/rust-lang/rust/pull/33976,MERGED,2016-05-31T06:30:55Z,2016-06-22T11:22:07Z,Add custom message parameter to `assert_eq!`,komamitsu,45a63d3ff611b1412f9d811cd328b648bada5ca2,2,Add message argument to `assert_eq` macro,HOORAY,2016-08-20T02:32:13Z,caspark,NA https://github.com/rust-lang/rust/pull/33976,MERGED,2016-05-31T06:30:55Z,2016-06-22T11:22:07Z,Add custom message parameter to `assert_eq!`,komamitsu,45a63d3ff611b1412f9d811cd328b648bada5ca2,2,Add message argument to `assert_eq` macro,HOORAY,2016-08-20T15:04:35Z,Jengamon,NA https://github.com/rust-lang/rust/pull/33989,MERGED,2016-05-31T19:00:13Z,2016-06-08T23:41:07Z,[MIR] Make scopes debuginfo-specific (visibility scopes).,eddyb,0c5930ef256131f8d0e4f020a5029a89944cf250,28,mir: group span + visibility scope under a new SourceInfo type.,HEART,2016-05-31T20:35:34Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/33989,MERGED,2016-05-31T19:00:13Z,2016-06-08T23:41:07Z,[MIR] Make scopes debuginfo-specific (visibility scopes).,eddyb,0c5930ef256131f8d0e4f020a5029a89944cf250,28,mir: group span + visibility scope under a new SourceInfo type.,THUMBS_UP,2016-06-28T22:35:22Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/34000,MERGED,2016-06-01T01:51:57Z,2016-06-16T08:01:32Z,Show types of all args when missing args,estebank,1020e3036badebc56b02661666b09a62112d04ec,8,"Show types of all args when missing args When there're missing arguments in a function call present a list of all the expected types: ```rust fn main() { t(""""); } fn t(a: &str x: String) {} ``` ```bash % rustc file.rs file.rs:3:5: 2:8 error: this function takes 2 parameters but 0 parameters were supplied [E0061] file.rs:3 t(); ^~~ file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation file.rs:3:5: 2:8 note: the following parameter types were expected: &str std::string::String error: aborting due to previous error ``` Fixes #33649",HOORAY,2016-06-16T13:47:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/34000,MERGED,2016-06-01T01:51:57Z,2016-06-16T08:01:32Z,Show types of all args when missing args,estebank,1020e3036badebc56b02661666b09a62112d04ec,8,"Show types of all args when missing args When there're missing arguments in a function call present a list of all the expected types: ```rust fn main() { t(""""); } fn t(a: &str x: String) {} ``` ```bash % rustc file.rs file.rs:3:5: 2:8 error: this function takes 2 parameters but 0 parameters were supplied [E0061] file.rs:3 t(); ^~~ file.rs:3:5: 2:8 help: run `rustc --explain E0061` to see a detailed explanation file.rs:3:5: 2:8 note: the following parameter types were expected: &str std::string::String error: aborting due to previous error ``` Fixes #33649",HOORAY,2016-06-18T17:13:07Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/34005,CLOSED,2016-06-01T08:40:53Z,2016-09-22T11:45:54Z,Do not overwrite input file if it has no extension,estebank,NA,NA,NA,THUMBS_UP,2016-07-18T12:46:04Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34012,MERGED,2016-06-01T12:20:22Z,2016-06-07T13:31:42Z,rustc: add ReErased to be used by trait selection MIR and trans.,eddyb,bcec7a58485c82e69a58a8ee849a05fd8f42d5af,28,rustc: add ReErased to be used by trait selection MIR and trans.,THUMBS_UP,2016-06-01T13:48:17Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34016,MERGED,2016-06-01T15:31:39Z,2016-06-03T11:09:44Z,Use Docker for Travis,sanxiyn,b1651fb4d2c0349ccca108b8d24210d688507936,2,Use Docker for Travis,THUMBS_UP,2016-06-01T16:27:30Z,bltavares,NA https://github.com/rust-lang/rust/pull/34016,MERGED,2016-06-01T15:31:39Z,2016-06-03T11:09:44Z,Use Docker for Travis,sanxiyn,b1651fb4d2c0349ccca108b8d24210d688507936,2,Use Docker for Travis,THUMBS_UP,2016-06-02T07:05:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34016,MERGED,2016-06-01T15:31:39Z,2016-06-03T11:09:44Z,Use Docker for Travis,sanxiyn,b1651fb4d2c0349ccca108b8d24210d688507936,2,Use Docker for Travis,THUMBS_UP,2016-06-02T17:24:41Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/34016,MERGED,2016-06-01T15:31:39Z,2016-06-03T11:09:44Z,Use Docker for Travis,sanxiyn,b1651fb4d2c0349ccca108b8d24210d688507936,2,Use Docker for Travis,THUMBS_UP,2016-06-02T18:41:03Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34020,MERGED,2016-06-01T16:32:19Z,2016-06-03T22:37:05Z,Avoid repeated string concatenation in python,Stebalien,cde72b071c4a955d9e087a95cdf15398ac5edb30,1,build: avoid repeated string concatenation in python,THUMBS_UP,2016-06-01T20:08:48Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/34020,MERGED,2016-06-01T16:32:19Z,2016-06-03T22:37:05Z,Avoid repeated string concatenation in python,Stebalien,cde72b071c4a955d9e087a95cdf15398ac5edb30,1,build: avoid repeated string concatenation in python,THUMBS_UP,2016-06-01T21:35:22Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/34077,MERGED,2016-06-04T19:20:09Z,2016-06-24T06:33:38Z,upgrade thread_local! invocation syntax,durka,fc28ee256a851b4274a2f8c8f776197f81bc7f07,2,upgrade thread_local! invocation syntax Allows declaring multiple statics in one macro invocation and supports attaching attributes to the generated items.,THUMBS_UP,2016-06-04T19:20:58Z,ticki,NA https://github.com/rust-lang/rust/pull/34095,MERGED,2016-06-05T13:55:09Z,2016-06-10T01:38:55Z,Improvements to pattern resolution + some refactoring,petrochenkov,6d7b35bd98858a8095fbc205115cedf069434f7f,7,Address review comments + fix rebase,THUMBS_UP,2016-06-06T01:51:54Z,jseyfried,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-05T16:47:51Z,causal-agent,june@causal.agency https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-05T16:48:19Z,tomprogrammer,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T16:48:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-05T17:11:39Z,rexim,reximkut@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-06-05T17:12:38Z,bstrie,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T17:19:32Z,pczarn,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T17:33:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-06-05T18:08:45Z,emoon,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T18:09:00Z,tailhook,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T19:14:08Z,kaksmet,kaksmet@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-05T19:15:57Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T19:15:59Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-06-05T19:16:01Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-05T19:55:36Z,kali,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-06T02:49:41Z,paulolieuthier,paulolieuthier@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T03:54:56Z,durka,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T05:49:56Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T05:52:05Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-06T05:52:07Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T07:06:09Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T07:35:40Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T08:11:45Z,Luthaf,luthaf@luthaf.fr https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T12:32:36Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-06T13:11:45Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-06T17:35:43Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-06-06T17:35:45Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-07T11:07:58Z,kornholi,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-08T13:44:15Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-06-11T07:08:14Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-20T04:31:02Z,8573,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-29T14:10:04Z,0X1A,albcoron@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-06-29T14:19:32Z,jansol,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-06-29T14:19:34Z,jansol,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-07-13T04:59:05Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-01T19:18:42Z,vadimcn,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-01T19:18:43Z,vadimcn,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T10:46:05Z,mkpankov,work@michaelpankov.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T10:46:08Z,mkpankov,work@michaelpankov.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T10:47:29Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T12:29:29Z,Diggsey,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T12:33:43Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T12:42:41Z,palango,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T13:27:49Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T13:28:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T13:38:56Z,TheWaWaR,thewawar@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T14:21:09Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T14:21:12Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T14:21:15Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T14:26:36Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T14:37:50Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T14:48:12Z,knz,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T14:50:58Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T14:56:34Z,17cupsofcoffee,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T15:04:28Z,redaready,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T15:12:07Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T15:12:08Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T15:12:12Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T15:24:41Z,yurivish,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T15:34:51Z,Vtec234,wjnawrocki+gh@protonmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T15:36:36Z,LeDominik,dominik@wagenknecht.cc https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T16:00:04Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T16:33:40Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T16:33:41Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T16:33:47Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T16:46:26Z,alterstep,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T16:54:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T17:11:31Z,tbg,tobias.schottdorf@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T17:25:30Z,samdoiron,sam.doiron96@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T17:49:09Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T17:49:10Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T17:49:11Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T17:50:41Z,dumindu,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:05:05Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:11:18Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:12:52Z,kwaegel,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T18:25:05Z,alexw91,aweibel@amazon.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:33:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T18:44:06Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:44:07Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T18:44:08Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T18:54:08Z,hban,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T19:37:09Z,michaelrutherford,michaellogan.rutherford@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T19:37:13Z,michaelrutherford,michaellogan.rutherford@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T20:23:00Z,defyrlt,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T20:26:36Z,maghoff,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T20:41:48Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T20:43:43Z,jmacdonald,jordan@wastedintelligence.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T20:50:28Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T21:09:46Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T21:12:30Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T21:19:28Z,Valloric,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T21:20:47Z,Limeth,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T21:39:00Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-02T21:39:05Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-02T21:39:06Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-02T22:21:50Z,est31,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T00:24:11Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T02:00:36Z,codearoni,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-03T02:13:25Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T02:13:27Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T02:13:31Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T05:32:26Z,kcking,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T05:45:18Z,sklopi,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-03T05:45:21Z,sklopi,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T05:45:22Z,sklopi,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T08:08:24Z,demilich1,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T08:46:44Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T08:46:48Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-03T08:46:50Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T10:13:48Z,jhugman,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T13:07:00Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T13:28:19Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T14:34:53Z,RalfJung,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T16:09:51Z,nosideeffects,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T18:20:27Z,wilhg,william.hng@outlook.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HEART,2016-08-03T18:20:29Z,wilhg,william.hng@outlook.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-03T18:20:36Z,wilhg,william.hng@outlook.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-03T20:34:06Z,chrish42,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-04T03:09:35Z,xiaoaiwhc,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-10T05:38:06Z,xen0n,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-13T15:47:13Z,bryce-anderson,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-19T05:47:26Z,LuoZijun,luozijun.assistant@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-26T18:13:40Z,grishy,mailgrishy@gmail.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-08-28T16:48:07Z,trufae,pancake@nowsecure.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-08-28T16:48:13Z,trufae,pancake@nowsecure.com https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,THUMBS_UP,2016-09-07T18:38:47Z,Awk34,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2016-11-02T19:41:06Z,KiChjang,NA https://github.com/rust-lang/rust/pull/34096,MERGED,2016-06-05T16:32:19Z,2016-08-02T09:30:17Z,Switch to MIR-based translation by default.,eddyb,b583711ff965db3b113ad6f468f32ad6ec1330a3,1,Ignore the lang-items example in the book.,HOORAY,2020-11-21T06:58:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/34105,MERGED,2016-06-05T22:53:12Z,2016-07-01T03:08:04Z,rustdoc: Remove Derived Implementations title,ollie27,cc181040348966789413387d4f99fc81673f60c7,3,rustdoc: Remove Derived Implementations title As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.,THUMBS_UP,2016-06-05T23:52:28Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34105,MERGED,2016-06-05T22:53:12Z,2016-07-01T03:08:04Z,rustdoc: Remove Derived Implementations title,ollie27,cc181040348966789413387d4f99fc81673f60c7,3,rustdoc: Remove Derived Implementations title As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.,THUMBS_DOWN,2016-06-06T03:53:09Z,durka,NA https://github.com/rust-lang/rust/pull/34105,MERGED,2016-06-05T22:53:12Z,2016-07-01T03:08:04Z,rustdoc: Remove Derived Implementations title,ollie27,cc181040348966789413387d4f99fc81673f60c7,3,rustdoc: Remove Derived Implementations title As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.,THUMBS_UP,2016-06-06T11:04:26Z,retep998,NA https://github.com/rust-lang/rust/pull/34105,MERGED,2016-06-05T22:53:12Z,2016-07-01T03:08:04Z,rustdoc: Remove Derived Implementations title,ollie27,cc181040348966789413387d4f99fc81673f60c7,3,rustdoc: Remove Derived Implementations title As far as I know whether a trait was derived or not does not change the public API so there is no need to include this information in the docs. This title currently just adds an extra divide in the list of trait implementations which I don't think needs to be there.,THUMBS_UP,2016-06-09T05:47:43Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/34118,CLOSED,2016-06-06T17:45:56Z,2016-06-28T01:32:01Z,Implement Fn traits for Rc/Arc,Stebalien,NA,NA,NA,THUMBS_UP,2016-06-06T20:00:54Z,durka,NA https://github.com/rust-lang/rust/pull/34118,CLOSED,2016-06-06T17:45:56Z,2016-06-28T01:32:01Z,Implement Fn traits for Rc/Arc,Stebalien,NA,NA,NA,THUMBS_UP,2016-06-06T20:33:30Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34118,CLOSED,2016-06-06T17:45:56Z,2016-06-28T01:32:01Z,Implement Fn traits for Rc/Arc,Stebalien,NA,NA,NA,THUMBS_UP,2016-06-10T13:57:22Z,bluss,NA https://github.com/rust-lang/rust/pull/34134,CLOSED,2016-06-07T09:34:21Z,2016-06-08T15:36:54Z,"Fixed: conflicting spelling of ""Jon Snow""",hoodie,NA,NA,NA,LAUGH,2016-06-07T16:45:39Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34134,CLOSED,2016-06-07T09:34:21Z,2016-06-08T15:36:54Z,"Fixed: conflicting spelling of ""Jon Snow""",hoodie,NA,NA,NA,LAUGH,2016-06-08T10:48:17Z,severino32,NA https://github.com/rust-lang/rust/pull/34134,CLOSED,2016-06-07T09:34:21Z,2016-06-08T15:36:54Z,"Fixed: conflicting spelling of ""Jon Snow""",hoodie,NA,NA,NA,HEART,2016-06-08T11:52:21Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/34134,CLOSED,2016-06-07T09:34:21Z,2016-06-08T15:36:54Z,"Fixed: conflicting spelling of ""Jon Snow""",hoodie,NA,NA,NA,HEART,2016-06-08T13:09:06Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/34141,MERGED,2016-06-07T15:31:06Z,2016-06-08T00:35:49Z,trans: always use a memcpy for ABI argument/return casts.,eddyb,e252865b744568649c3ecfcf8ac02bb6f73d7fc6,6,trans: always use a memcpy for ABI argument/return casts.,HEART,2016-06-08T08:35:09Z,dotdash,NA https://github.com/rust-lang/rust/pull/34155,MERGED,2016-06-07T22:52:19Z,2016-06-21T15:43:04Z,Remove unzip() SizeHint hack,ollie27,02f9be8524ac6e9706867e2ae0abd09bee95dc53,1,Remove unzip() SizeHint hack This was using an invalid iterator so is likely to end with buggy behaviour. It also doesn't even benefit many type in std including Vec so removing it shouldn't cause any problems.,THUMBS_UP,2016-06-10T08:18:45Z,sfackler,NA https://github.com/rust-lang/rust/pull/34155,MERGED,2016-06-07T22:52:19Z,2016-06-21T15:43:04Z,Remove unzip() SizeHint hack,ollie27,02f9be8524ac6e9706867e2ae0abd09bee95dc53,1,Remove unzip() SizeHint hack This was using an invalid iterator so is likely to end with buggy behaviour. It also doesn't even benefit many type in std including Vec so removing it shouldn't cause any problems.,THUMBS_UP,2016-06-21T15:55:57Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/34155,MERGED,2016-06-07T22:52:19Z,2016-06-21T15:43:04Z,Remove unzip() SizeHint hack,ollie27,02f9be8524ac6e9706867e2ae0abd09bee95dc53,1,Remove unzip() SizeHint hack This was using an invalid iterator so is likely to end with buggy behaviour. It also doesn't even benefit many type in std including Vec so removing it shouldn't cause any problems.,HOORAY,2016-06-21T15:56:00Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/34160,MERGED,2016-06-08T12:46:45Z,2016-06-10T17:37:46Z,Fixed two little Game Of Thrones References,hoodie,92e8228813a248520a4c3cadf6457c5225502525,1,"Fixed two little Game Of Thrones References Fixed: conflicting spelling of ""Jon Snow"" Fixed: It's call ""Night's Watch""",LAUGH,2016-06-08T13:34:41Z,kennytm,NA https://github.com/rust-lang/rust/pull/34160,MERGED,2016-06-08T12:46:45Z,2016-06-10T17:37:46Z,Fixed two little Game Of Thrones References,hoodie,92e8228813a248520a4c3cadf6457c5225502525,1,"Fixed two little Game Of Thrones References Fixed: conflicting spelling of ""Jon Snow"" Fixed: It's call ""Night's Watch""",LAUGH,2016-06-08T14:23:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34160,MERGED,2016-06-08T12:46:45Z,2016-06-10T17:37:46Z,Fixed two little Game Of Thrones References,hoodie,92e8228813a248520a4c3cadf6457c5225502525,1,"Fixed two little Game Of Thrones References Fixed: conflicting spelling of ""Jon Snow"" Fixed: It's call ""Night's Watch""",HEART,2016-06-08T15:06:42Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/34160,MERGED,2016-06-08T12:46:45Z,2016-06-10T17:37:46Z,Fixed two little Game Of Thrones References,hoodie,92e8228813a248520a4c3cadf6457c5225502525,1,"Fixed two little Game Of Thrones References Fixed: conflicting spelling of ""Jon Snow"" Fixed: It's call ""Night's Watch""",LAUGH,2016-06-09T17:25:39Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/34193,MERGED,2016-06-09T23:43:32Z,2016-08-11T20:14:29Z,privacy: Substitute type aliases in private-in-public checker,petrochenkov,5d4ae4ba5a08c1161e46e0dd6b2584b664bdf335,1,Add test for recursive private alias substitution in rustdoc,THUMBS_UP,2016-06-12T21:53:16Z,jseyfried,NA https://github.com/rust-lang/rust/pull/34195,CLOSED,2016-06-10T04:08:54Z,2016-06-17T00:28:10Z,[WIP][RFC] initial support for PTX generation,japaric,NA,NA,NA,HOORAY,2016-06-10T06:10:28Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34195,CLOSED,2016-06-10T04:08:54Z,2016-06-17T00:28:10Z,[WIP][RFC] initial support for PTX generation,japaric,NA,NA,NA,HOORAY,2016-06-10T08:30:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34195,CLOSED,2016-06-10T04:08:54Z,2016-06-17T00:28:10Z,[WIP][RFC] initial support for PTX generation,japaric,NA,NA,NA,HOORAY,2016-12-21T10:45:22Z,denzp,NA https://github.com/rust-lang/rust/pull/34207,MERGED,2016-06-10T21:41:24Z,2016-06-16T05:12:34Z,Remove last traces of identifier hygiene from HIR,petrochenkov,f59afbc2143894932529a29057de25a4425ed65e,7,Remove last traces of identifier hygiene from HIR,THUMBS_UP,2016-06-14T08:08:46Z,jseyfried,NA https://github.com/rust-lang/rust/pull/34208,MERGED,2016-06-10T22:29:28Z,2016-06-11T11:24:01Z,Remove linking and intrinsics code made dead by only supporting LLVM 3.7 and up,shepmaster,448e254ca0416148b7ee8450e37dc1727fc5d530,1,All intrinsics are available in all supported LLVM versions,HEART,2016-06-11T01:08:52Z,brson,NA https://github.com/rust-lang/rust/pull/34220,MERGED,2016-06-11T13:42:20Z,2016-06-15T22:59:00Z,run rustfmt on cargotest folder in src/tools/cargotest,srinivasreddy,028073dd606206a4383193a6924e83c83ce2f8c3,1,run rustfmt on cargotest folder in src/tools/cargotest,THUMBS_DOWN,2016-06-13T14:23:48Z,LFalch,NA https://github.com/rust-lang/rust/pull/34220,MERGED,2016-06-11T13:42:20Z,2016-06-15T22:59:00Z,run rustfmt on cargotest folder in src/tools/cargotest,srinivasreddy,028073dd606206a4383193a6924e83c83ce2f8c3,1,run rustfmt on cargotest folder in src/tools/cargotest,THUMBS_DOWN,2016-08-16T01:30:11Z,jseyfried,NA https://github.com/rust-lang/rust/pull/34258,MERGED,2016-06-13T17:23:49Z,2016-07-29T13:48:03Z,book/ffi: nullable pointer cleanup,durka,29546dd06d733d065fc497902bbcecbbb06ce621,1,remove claim about searching through nested fields for the nullable type even though that is how it works,THUMBS_UP,2016-06-14T00:46:21Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/34258,MERGED,2016-06-13T17:23:49Z,2016-07-29T13:48:03Z,book/ffi: nullable pointer cleanup,durka,29546dd06d733d065fc497902bbcecbbb06ce621,1,remove claim about searching through nested fields for the nullable type even though that is how it works,THUMBS_UP,2016-06-14T01:56:11Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/34263,MERGED,2016-06-13T22:57:50Z,2016-06-15T11:44:15Z,Improve IP reserved address docs,ollie27,61043fd3c1c54f8ed7d9b4f9ecabe62d4f19e933,1,Improve IP reserved address docs - Add links to all RFCs to make it clear these are not Rust RFCs. - Correct RFC numbers to match the numbers in [RFC 6890](https://tools.ietf.org/html/rfc6890) - Clean up formatting to show addresses and ranges in parentheses like (255.255.255.255),THUMBS_UP,2016-06-14T19:06:06Z,LFalch,NA https://github.com/rust-lang/rust/pull/34265,CLOSED,2016-06-14T02:30:53Z,2016-06-14T12:00:10Z,Add Vec::retain_mut,shepmaster,NA,NA,NA,THUMBS_UP,2020-04-05T13:08:45Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/34277,MERGED,2016-06-14T21:00:10Z,2016-07-07T03:04:16Z,Add/improve num const docs,ollie27,2dcfa628768af55b07931c8717e92ddf2f70940d,2,Correct MIN_EXP docs and improve EPSILON,THUMBS_UP,2016-06-15T06:28:49Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/34277,MERGED,2016-06-14T21:00:10Z,2016-07-07T03:04:16Z,Add/improve num const docs,ollie27,2dcfa628768af55b07931c8717e92ddf2f70940d,2,Correct MIN_EXP docs and improve EPSILON,THUMBS_UP,2016-06-16T19:24:15Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/34288,CLOSED,2016-06-15T20:48:33Z,2016-06-15T21:04:48Z,RFC: Change max line length to 120,perlun,NA,NA,NA,THUMBS_DOWN,2016-06-15T21:00:49Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/34314,MERGED,2016-06-16T21:22:47Z,2016-06-18T14:20:21Z,doc: fix mis-named binding & remove not needed `mut`,tshepang,1253e82b7f14a544c3efc62f18dd2f1b6ffa4e0e,1,doc: fix mis-named binding & remove not needed `mut`,THUMBS_UP,2016-06-16T21:42:46Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34320,CLOSED,2016-06-17T07:46:21Z,2016-06-22T09:29:28Z,Pretty print error value on Result.unwrap() panic,liigo,NA,NA,NA,HEART,2016-06-17T17:10:00Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/34364,MERGED,2016-06-19T15:28:55Z,2016-06-23T17:56:47Z,Modified E0220 to show error messages for more general cases,nikhilshagri,09ffe475e70ce1b0564cf334a9eabeda008667e5,1,Modified E0220 to show error messages for more general cases,THUMBS_UP,2016-06-27T21:04:02Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/34366,MERGED,2016-06-19T17:50:08Z,2016-08-14T19:28:48Z,Produce source package in rust-installer format,Diggsey,b3908d08ee477f550dcb0e3d23305dee77e2258b,1,Fix make-tidy lock file checks,HOORAY,2016-06-27T12:54:51Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/34387,MERGED,2016-06-20T21:24:33Z,2016-06-22T14:40:22Z,rustdoc: Fix a couple of issues with src links to external crates,ollie27,ebfdd110c3ae32e91627f1d75bf089560bf98c9b,6,rustdoc: Fix a couple of issues with src links to external crates - src links/redirects to extern fn from another crate had an extra '/'. - src links to `pub use` of a crate module had an extra '/'. - src links to renamed reexports from another crate used the new name for the link but should use the original name.,THUMBS_UP,2016-06-23T10:28:14Z,reeze,reeze@php.net https://github.com/rust-lang/rust/pull/34412,MERGED,2016-06-22T14:48:37Z,2016-07-05T19:17:51Z,Add x86 intrinsics for bit manipulation (BMI 1.0 BMI 2.0 and TBM).,gnzlbg,483bec790b28d03f318b8cfbe053e284677b6be2,2,Add target_features for the bit manipulation instruction sets: BMI 1.0 BMI 2.0 and TBM.,THUMBS_UP,2016-06-23T13:23:36Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/34412,MERGED,2016-06-22T14:48:37Z,2016-07-05T19:17:51Z,Add x86 intrinsics for bit manipulation (BMI 1.0 BMI 2.0 and TBM).,gnzlbg,483bec790b28d03f318b8cfbe053e284677b6be2,2,Add target_features for the bit manipulation instruction sets: BMI 1.0 BMI 2.0 and TBM.,THUMBS_UP,2016-07-12T18:25:11Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34420,CLOSED,2016-06-23T01:36:14Z,2016-12-26T18:48:49Z,Detect double reference when applying binary op,estebank,NA,NA,NA,THUMBS_UP,2016-06-23T07:28:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34424,MERGED,2016-06-23T07:10:15Z,2016-06-28T04:45:23Z,Batch up libsyntax breaking changes,jseyfried,360dcae4197d0bf0f59d5364470e00b589d5c549,1,Update `src/rustc/Cargo.lock`,THUMBS_UP,2016-07-02T20:40:23Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/34436,MERGED,2016-06-23T21:08:45Z,2016-06-28T04:45:24Z,Allow statement-generating braced macro invocations at the end of blocks,jseyfried,8cad25199acb346bf8d6b1771f1f50dc9e59374c,3,Add `ecx.stmt_semi()` and fix issues with the pretty-printer,THUMBS_UP,2016-06-27T18:58:27Z,durka,NA https://github.com/rust-lang/rust/pull/34438,MERGED,2016-06-23T22:16:57Z,2016-06-25T16:49:01Z,Indicate how the `JoinHandle` struct is created.,frewsxcv,5e9b75e2dd440a5df2c7d90f88b2660c7581d964,1,Add examples in docs for `JoinHandle`.,THUMBS_UP,2016-06-24T07:05:48Z,retep998,NA https://github.com/rust-lang/rust/pull/34445,MERGED,2016-06-24T03:04:51Z,2016-06-25T16:49:01Z,"Renames ""lets_do_this"" macro more appropriately.",pyjarrett,0187aec8e0f7cb148c5360ab5d3953ee86394061,1,"Renames ""lets_do_this"" macro more appropriately. The macro gets used to create a mapping of identifiers to names and their associated functions. Since it creates a table of language items let's rename it in a similar manner to how vec! creates a vec.",THUMBS_DOWN,2016-08-22T21:37:29Z,durka,NA https://github.com/rust-lang/rust/pull/34445,MERGED,2016-06-24T03:04:51Z,2016-06-25T16:49:01Z,"Renames ""lets_do_this"" macro more appropriately.",pyjarrett,0187aec8e0f7cb148c5360ab5d3953ee86394061,1,"Renames ""lets_do_this"" macro more appropriately. The macro gets used to create a mapping of identifiers to names and their associated functions. Since it creates a table of language items let's rename it in a similar manner to how vec! creates a vec.",THUMBS_DOWN,2016-08-22T21:38:30Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34445,MERGED,2016-06-24T03:04:51Z,2016-06-25T16:49:01Z,"Renames ""lets_do_this"" macro more appropriately.",pyjarrett,0187aec8e0f7cb148c5360ab5d3953ee86394061,1,"Renames ""lets_do_this"" macro more appropriately. The macro gets used to create a mapping of identifiers to names and their associated functions. Since it creates a table of language items let's rename it in a similar manner to how vec! creates a vec.",THUMBS_DOWN,2020-12-13T11:08:22Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/34445,MERGED,2016-06-24T03:04:51Z,2016-06-25T16:49:01Z,"Renames ""lets_do_this"" macro more appropriately.",pyjarrett,0187aec8e0f7cb148c5360ab5d3953ee86394061,1,"Renames ""lets_do_this"" macro more appropriately. The macro gets used to create a mapping of identifiers to names and their associated functions. Since it creates a table of language items let's rename it in a similar manner to how vec! creates a vec.",THUMBS_DOWN,2021-05-25T22:12:05Z,TroyNeubauer,troyneubauer@gmail.com https://github.com/rust-lang/rust/pull/34445,MERGED,2016-06-24T03:04:51Z,2016-06-25T16:49:01Z,"Renames ""lets_do_this"" macro more appropriately.",pyjarrett,0187aec8e0f7cb148c5360ab5d3953ee86394061,1,"Renames ""lets_do_this"" macro more appropriately. The macro gets used to create a mapping of identifiers to names and their associated functions. Since it creates a table of language items let's rename it in a similar manner to how vec! creates a vec.",THUMBS_DOWN,2021-07-05T22:47:35Z,willemml,NA https://github.com/rust-lang/rust/pull/34449,CLOSED,2016-06-24T11:18:15Z,2016-06-25T12:06:55Z,Improve `syntax::ast::*` type docs (examples etc),regexident,NA,NA,NA,THUMBS_UP,2016-06-24T12:16:02Z,killercup,NA https://github.com/rust-lang/rust/pull/34456,MERGED,2016-06-24T18:55:30Z,2016-07-15T15:48:46Z,Use `ptr::{null null_mut}` instead of `0 as *{const mut}`,tbu-,81e95c18b7d4c45c7ef41b231af4ecd40543567d,12,Use `ptr::{null null_mut}` instead of `0 as *{const mut}`,THUMBS_UP,2016-06-24T20:23:09Z,retep998,NA https://github.com/rust-lang/rust/pull/34474,CLOSED,2016-06-25T20:34:24Z,2016-06-27T18:39:12Z,Automatic `Item` linkification part 0,JohnHeitmann,NA,NA,NA,HEART,2016-06-25T20:50:14Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34485,MERGED,2016-06-26T13:40:52Z,2016-07-28T21:17:56Z,Escape fewer Unicode codepoints in `Debug` impl of `str`,tbu-,3d09b4a0d58200da84fe19cd3b0003d61e5b1791,12,Rename `char::escape` to `char::escape_debug` and add tracking issue,HOORAY,2016-06-27T01:35:59Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/34485,MERGED,2016-06-26T13:40:52Z,2016-07-28T21:17:56Z,Escape fewer Unicode codepoints in `Debug` impl of `str`,tbu-,3d09b4a0d58200da84fe19cd3b0003d61e5b1791,12,Rename `char::escape` to `char::escape_debug` and add tracking issue,HEART,2016-07-31T13:48:43Z,bluss,NA https://github.com/rust-lang/rust/pull/34485,MERGED,2016-06-26T13:40:52Z,2016-07-28T21:17:56Z,Escape fewer Unicode codepoints in `Debug` impl of `str`,tbu-,3d09b4a0d58200da84fe19cd3b0003d61e5b1791,12,Rename `char::escape` to `char::escape_debug` and add tracking issue,THUMBS_UP,2016-08-03T00:40:10Z,tikue,NA https://github.com/rust-lang/rust/pull/34485,MERGED,2016-06-26T13:40:52Z,2016-07-28T21:17:56Z,Escape fewer Unicode codepoints in `Debug` impl of `str`,tbu-,3d09b4a0d58200da84fe19cd3b0003d61e5b1791,12,Rename `char::escape` to `char::escape_debug` and add tracking issue,THUMBS_UP,2016-08-03T13:09:18Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/34485,MERGED,2016-06-26T13:40:52Z,2016-07-28T21:17:56Z,Escape fewer Unicode codepoints in `Debug` impl of `str`,tbu-,3d09b4a0d58200da84fe19cd3b0003d61e5b1791,12,Rename `char::escape` to `char::escape_debug` and add tracking issue,THUMBS_UP,2018-08-04T18:44:59Z,FGFW,NA https://github.com/rust-lang/rust/pull/34530,MERGED,2016-06-28T17:12:23Z,2016-07-04T01:17:42Z,std: Stabilize APIs for the 1.11.0 release,alexcrichton,3016626c3aa4bc44807e54a8ba8b9e367ff566f5,36,std: Stabilize APIs for the 1.11.0 release Although the set of APIs being stabilized this release is relatively small the trains keep going! Listed below are the APIs in the standard library which have either transitioned from unstable to stable or those from unstable to deprecated. Stable * `BTreeMap::{append split_off}` * `BTreeSet::{append split_off}` * `Cell::get_mut` * `RefCell::get_mut` * `BinaryHeap::append` * `{f32 f64}::{to_degrees to_radians}` - libcore stabilizations mirroring past libstd stabilizations * `Iterator::sum` * `Iterator::product` Deprecated * `{f32 f64}::next_after` * `{f32 f64}::integer_decode` * `{f32 f64}::ldexp` * `{f32 f64}::frexp` * `num::One` * `num::Zero` Added APIs (all unstable) * `iter::Sum` * `iter::Product` * `iter::Step` - a few methods were added to accomodate deprecation of One/Zero Removed APIs * `From> for RangeInclusive` - everything about `RangeInclusive` is unstable Closes #27739 Closes #27752 Closes #32526 Closes #33444 Closes #34152 cc #34529 (new tracking issue),THUMBS_UP,2016-06-28T18:37:45Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-06-30T08:47:20Z,retep998,NA https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-06-30T11:08:01Z,edwardw,edward.yu.wang@gmail.com https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-06-30T17:13:18Z,erickt,erick.tryzelaar@gmail.com https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-06-30T21:24:40Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-06-30T22:05:33Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-03T10:08:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-03T11:40:50Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-03T11:43:39Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-03T23:08:58Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-08T18:29:29Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-13T22:20:26Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-07-19T16:50:46Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34570,MERGED,2016-06-30T06:25:55Z,2016-07-15T19:43:29Z,Simplify the macro hygiene algorithm,jseyfried,c1a6ff2d6b1dccd5af1c6cb9b9e67066af4c0247,1,Add labels hygiene test,THUMBS_UP,2016-08-19T16:29:53Z,reddraggone9,cljenkins9@gmail.com https://github.com/rust-lang/rust/pull/34575,MERGED,2016-06-30T14:47:45Z,2016-07-08T04:48:11Z,Introducing TokenStreams and TokenSlices for procedural macros,cgswords,754759688bd964397d09b5f689fcf8d155a8136b,1,Preliminary implementation for TokenStreams and TokenSlices including unit tests and associated operations.,HEART,2016-06-30T16:59:46Z,erickt,erick.tryzelaar@gmail.com https://github.com/rust-lang/rust/pull/34605,MERGED,2016-07-01T23:16:55Z,2016-07-02T22:14:03Z,fail obligations that depend on erroring obligations,arielb1,201cdd33df63f378ed6c7e9cf55458e1c382cd97,3,fail obligations that depend on erroring obligations Fix a bug where an obligation that depend on an erroring obligation would be regarded as successful leading to global cache pollution and random lossage. Fixes #33723. Fixes #34503.,THUMBS_UP,2016-07-02T18:37:58Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/34605,MERGED,2016-07-01T23:16:55Z,2016-07-02T22:14:03Z,fail obligations that depend on erroring obligations,arielb1,201cdd33df63f378ed6c7e9cf55458e1c382cd97,3,fail obligations that depend on erroring obligations Fix a bug where an obligation that depend on an erroring obligation would be regarded as successful leading to global cache pollution and random lossage. Fixes #33723. Fixes #34503.,THUMBS_UP,2016-07-04T05:20:36Z,zetok,NA https://github.com/rust-lang/rust/pull/34614,MERGED,2016-07-02T14:33:02Z,2016-07-03T12:03:04Z,Build: Shows total time taken to build the compiler,nikhilshagri,4dbe14005f0c45c43c3b8b081d550c5b461b2d6b,1,Build: Shows total time taken to build the compiler,THUMBS_UP,2016-07-02T15:47:02Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/34623,MERGED,2016-07-03T05:01:56Z,2016-08-31T12:52:01Z,Warn about multiple conflicting #[repr] hints,lambda-fairy,42b75a5c18463b4fef98267663fab13d265eac3e,5,Warn about multiple conflicting #[repr] hints Closes #34622,THUMBS_UP,2016-07-03T10:50:36Z,retep998,NA https://github.com/rust-lang/rust/pull/34638,MERGED,2016-07-03T23:32:42Z,2016-07-04T12:03:18Z,prefer `if let` to match with `None => {}` arm in some places,zackmdavis,d37edef9dd088d953c5e272db37686a338c31778,47,prefer `if let` to match with `None => {}` arm in some places This is a spiritual succesor to #34268/8531d581 in which we replaced a number of matches of None to the unit value with `if let` conditionals where it was judged that this made for clearer/simpler code (as would be recommended by Manishearth/rust-clippy's `single_match` lint). The same rationale applies to matches of None to the empty block.,THUMBS_UP,2016-07-04T08:38:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34644,MERGED,2016-07-04T14:39:07Z,2016-07-06T13:26:45Z,Avoid redundant downloads when bootstrapping,infinity0,933a1036ae12d728b2ccffa560154a8011a4c256,1,Tweak verbosity to hopefully better match intuitive expectations,THUMBS_UP,2016-07-04T16:07:25Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/34648,CLOSED,2016-07-04T19:12:50Z,2016-07-06T18:19:28Z,"Revert ""Revert ""Remove the return_address intrinsic.""""",eddyb,NA,NA,NA,THUMBS_UP,2016-07-04T19:14:59Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/34648,CLOSED,2016-07-04T19:12:50Z,2016-07-06T18:19:28Z,"Revert ""Revert ""Remove the return_address intrinsic.""""",eddyb,NA,NA,NA,HOORAY,2016-07-04T19:15:02Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/34648,CLOSED,2016-07-04T19:12:50Z,2016-07-06T18:19:28Z,"Revert ""Revert ""Remove the return_address intrinsic.""""",eddyb,NA,NA,NA,LAUGH,2017-04-21T17:59:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/34724,MERGED,2016-07-08T14:22:21Z,2016-07-22T08:36:27Z,Add a method to the mpsc::Receiver for producing a non-blocking iterator,mitchmindtree,05af033b7fec63638497a9780e6b323d327d1e17,1,Fix issue in receiver_try_iter test where response sender would panic instead of break from the loop,HOORAY,2016-07-29T14:24:43Z,brendanzab,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-07-11T18:54:33Z,brson,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HEART,2016-07-14T18:54:43Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-07-21T11:28:51Z,pczarn,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-07-24T15:29:24Z,Limeth,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-07-27T08:17:31Z,chpio,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HEART,2016-07-27T08:17:32Z,chpio,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,THUMBS_UP,2016-07-27T08:17:34Z,chpio,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HEART,2016-08-01T20:40:24Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,THUMBS_UP,2016-08-01T20:40:25Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-01T20:49:27Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T02:52:40Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T05:27:47Z,brendanzab,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T05:48:40Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T06:50:53Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T07:42:17Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T09:47:05Z,ashleysommer,ashleysommer@gmail.com https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T09:53:18Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-02T10:05:04Z,killercup,NA https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2016-08-03T11:17:57Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/34743,MERGED,2016-07-09T21:36:18Z,2016-08-01T15:57:34Z,LLVM upgrade,badboy,5d1d2475232d06b2a315d87481898819bb547f97,1,Upgrade LLVM once more to get a bugfix @tmiasko did some digging and discovered that https://reviews.llvm.org/D22858 may be relevant.,HOORAY,2017-05-11T22:28:26Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/34772,MERGED,2016-07-11T22:31:23Z,2016-07-13T20:27:07Z,Start cleaning up the string interner,jseyfried,060b5c5ef273a6b74ccbd10c1d4a1debfa27d9de,2,Factor the `RefCell` out of the `Interner`.,HOORAY,2016-07-12T17:21:16Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/34772,MERGED,2016-07-11T22:31:23Z,2016-07-13T20:27:07Z,Start cleaning up the string interner,jseyfried,060b5c5ef273a6b74ccbd10c1d4a1debfa27d9de,2,Factor the `RefCell` out of the `Interner`.,HOORAY,2016-07-19T15:59:22Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/34785,CLOSED,2016-07-12T17:19:32Z,2016-09-29T07:15:12Z,[RFC accepted] add wrapper for discriminant_value intrinsic,durka,NA,NA,NA,HOORAY,2016-07-12T20:12:22Z,brson,NA https://github.com/rust-lang/rust/pull/34785,CLOSED,2016-07-12T17:19:32Z,2016-09-29T07:15:12Z,[RFC accepted] add wrapper for discriminant_value intrinsic,durka,NA,NA,NA,HOORAY,2016-09-26T18:18:01Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34789,MERGED,2016-07-12T19:31:17Z,2016-07-17T10:05:15Z,Simplify librustc_errors,jntrnr,c7158a143ae639081084755038c5ce1f8c398e93,1,Remove unused import,THUMBS_UP,2016-07-12T20:40:55Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/34802,MERGED,2016-07-13T14:16:09Z,2016-08-01T22:27:01Z,Methods `Fn(Mut Once)::call(mut once)` are gated with two feature gates remove one of them,petrochenkov,a80d329b68f88da4f35a4c05337b5ae0920c20c4,96,Don't gate methods `Fn(Mut Once)::call(mut once)` with feature `unboxed_closures` They are already gated with feature `fn_traits`,THUMBS_UP,2016-07-13T15:16:17Z,durka,NA https://github.com/rust-lang/rust/pull/34802,MERGED,2016-07-13T14:16:09Z,2016-08-01T22:27:01Z,Methods `Fn(Mut Once)::call(mut once)` are gated with two feature gates remove one of them,petrochenkov,a80d329b68f88da4f35a4c05337b5ae0920c20c4,96,Don't gate methods `Fn(Mut Once)::call(mut once)` with feature `unboxed_closures` They are already gated with feature `fn_traits`,THUMBS_UP,2016-07-18T15:26:37Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34816,MERGED,2016-07-14T10:27:55Z,2016-07-16T16:31:59Z,Fix `include!()`s inside `asm!()` invocations,jseyfried,11f24a93c79a5ff5ecd2c238c603bdab30926bb3,2,Add regression test,THUMBS_UP,2016-07-15T18:54:44Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-14T19:58:29Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-14T20:35:36Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-15T06:13:26Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-15T09:51:00Z,killercup,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-15T13:54:43Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-16T11:14:10Z,3Hren,division494@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-16T22:12:14Z,arthurprs,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-26T18:24:55Z,paulolieuthier,paulolieuthier@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-26T19:07:55Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-26T19:11:32Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-07-28T01:54:35Z,tennix,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-09-06T22:32:00Z,reddraggone9,cljenkins9@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-09-28T01:38:33Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-09-28T14:00:23Z,vaartis,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2016-09-30T19:20:42Z,LFalch,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2021-12-18T17:43:34Z,CatCode79,andrea.postal@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2022-04-11T02:37:11Z,AndrielFR,andrielkogama2@gmail.com https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2022-06-01T21:08:49Z,herlon214,NA https://github.com/rust-lang/rust/pull/34828,MERGED,2016-07-14T19:53:50Z,2016-07-21T17:22:12Z,core: impl From for Option,seanmonstar,fbfee42a2f65b7a3d4acd0d9d029bb75208ac800,1,core: impl From for Option,THUMBS_UP,2022-06-02T23:37:13Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/34845,MERGED,2016-07-16T05:24:36Z,2016-08-11T08:58:53Z,Add help for target CPUs features relocation and code models.,bitshifter,05045da9fdab511f39e88335b1bc7f92ea7973ba,4,Improved checking of target's llvm_config Point llvm @bitshifter branch until PR accepted Use today's date for LLVM auto clean trigger Update LLVM submodule to point at rust-lang fork. Handle case when target is set,HEART,2016-09-21T00:05:55Z,bluss,NA https://github.com/rust-lang/rust/pull/34873,MERGED,2016-07-17T00:26:13Z,2016-07-21T08:35:58Z,mk: Stop using cmake for compiler-rt ,alexcrichton,ee6011fc71e02485f2dffcc25be64631c2008775,6,mk: Stop using cmake for compiler-rt The compiler-rt build system has been a never ending cause of pain for Rust unfortunately: * The build system is very difficult to invoke and configure to only build compiler-rt especially across platforms. * The standard build system doesn't actually do what we want not working for some of our platforms and requiring a significant number of patches on our end which are difficult to apply when updating compiler-rt. * Compiling compiler-rt requires LLVM to be compiled which... is a big dependency! This also means that over time compiler-rt is not guaranteed to build against older versions of LLVM (or newer versions) and we often want to work with multiple versions of LLVM simultaneously. The makefiles and rustbuild already know how to compile C code the code here is far from the *only* C code we're compiling. This patch jettisons all logic to work with compiler-rt's build system and just goes straight to the source. We just list all files manually (copied from compiler-rt's lib/builtins/CMakeLists.txt) and compile them into an archive. It's likely that this means we'll fail to pick up new files when we upgrade compiler-rt but that seems like a much less significant cost to pay than what we're currently paying. cc #34400 first steps towards that,THUMBS_UP,2016-08-02T07:48:42Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34880,MERGED,2016-07-17T10:11:01Z,2016-07-21T17:22:14Z,Make .enumerate() example self-explanatory,xitep,3b5d71e0cfb2d81f588a0b8929e796f3b68488e0,1,Make .enumerate() example self-explanatory,THUMBS_UP,2016-07-17T18:16:46Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34880,MERGED,2016-07-17T10:11:01Z,2016-07-21T17:22:14Z,Make .enumerate() example self-explanatory,xitep,3b5d71e0cfb2d81f588a0b8929e796f3b68488e0,1,Make .enumerate() example self-explanatory,THUMBS_UP,2016-07-18T01:16:02Z,Havvy,NA https://github.com/rust-lang/rust/pull/34897,CLOSED,2016-07-18T12:54:17Z,2016-09-09T23:00:10Z,More specific error when calling bottom,sanxiyn,NA,NA,NA,THUMBS_UP,2016-07-19T09:10:23Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-07-19T20:45:56Z,brson,NA https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-07-19T21:00:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-07-19T21:11:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-08-03T04:34:45Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-08-03T05:30:31Z,durka,NA https://github.com/rust-lang/rust/pull/34908,MERGED,2016-07-18T23:21:08Z,2016-07-28T11:14:13Z,macros: Improve `tt` matchers,jseyfried,448550223b4e80d722c18361c465a24889e37c40,1,Add regression test,HOORAY,2016-09-25T14:40:42Z,bluss,NA https://github.com/rust-lang/rust/pull/34921,MERGED,2016-07-19T13:07:32Z,2016-07-21T17:22:17Z,[CSS] Fix unwanted top margin for toggle wrapper,GuillaumeGomez,4a2116b97af2e935b359558c046034f4c3cb80a8,1,[CSS] Fix unwanted top margin for toggle wrapper,THUMBS_UP,2016-07-19T13:38:15Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34921,MERGED,2016-07-19T13:07:32Z,2016-07-21T17:22:17Z,[CSS] Fix unwanted top margin for toggle wrapper,GuillaumeGomez,4a2116b97af2e935b359558c046034f4c3cb80a8,1,[CSS] Fix unwanted top margin for toggle wrapper,HEART,2016-07-19T20:45:20Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/34925,MERGED,2016-07-19T20:26:59Z,2016-07-23T14:42:38Z,Support nested `macro_rules!`,jseyfried,485e2df1b1fbd4acde8dbc5bfbdf7fed3acc227c,1,Add regression test.,HOORAY,2016-07-23T15:27:46Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/34925,MERGED,2016-07-19T20:26:59Z,2016-07-23T14:42:38Z,Support nested `macro_rules!`,jseyfried,485e2df1b1fbd4acde8dbc5bfbdf7fed3acc227c,1,Add regression test.,HOORAY,2016-08-03T05:00:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34925,MERGED,2016-07-19T20:26:59Z,2016-07-23T14:42:38Z,Support nested `macro_rules!`,jseyfried,485e2df1b1fbd4acde8dbc5bfbdf7fed3acc227c,1,Add regression test.,HOORAY,2016-08-03T05:30:24Z,durka,NA https://github.com/rust-lang/rust/pull/34925,MERGED,2016-07-19T20:26:59Z,2016-07-23T14:42:38Z,Support nested `macro_rules!`,jseyfried,485e2df1b1fbd4acde8dbc5bfbdf7fed3acc227c,1,Add regression test.,HOORAY,2016-09-30T02:15:33Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/34944,CLOSED,2016-07-20T22:56:49Z,2016-07-26T22:56:29Z,Put `Vec` in with the rest of the collections,notriddle,NA,NA,NA,THUMBS_UP,2016-07-21T06:52:50Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:08:23Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:08:25Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:08:27Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:18:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:25:04Z,ambaxter,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:25:04Z,ambaxter,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:25:05Z,ambaxter,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:30:13Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:31:00Z,malbarbo,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:32:27Z,gabdube,gdube.475@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:33:31Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:33:50Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:33:52Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:33:54Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:44:41Z,futile,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:44:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:44:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:47:11Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:48:03Z,pczarn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:48:10Z,pczarn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:48:10Z,pczarn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:50:09Z,Ryman,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:50:09Z,CryZe,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T17:50:12Z,CryZe,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T17:50:13Z,CryZe,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T17:59:32Z,jeanm,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T18:03:39Z,Arrem,alem.zupa@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T18:29:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T18:30:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T18:32:25Z,stusmall,stuart.alan.small@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T18:54:34Z,jwilm,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T18:54:38Z,jwilm,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:03:24Z,killercup,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T19:04:51Z,Azertinv,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:04:52Z,Azertinv,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T19:04:53Z,Azertinv,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:06:28Z,shanegibbs,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T19:08:31Z,shanegibbs,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:15:36Z,msierks,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T19:26:43Z,clux,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T19:34:07Z,exul,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T19:35:46Z,Diggsey,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T19:36:41Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:37:56Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:40:16Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T19:51:44Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:11:28Z,BonsaiDen,ivo.wetzel@googlemail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T20:16:19Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:27:10Z,zmanian,zaki@manian.org https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:28:10Z,vadimcn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T20:29:20Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T20:29:30Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:29:31Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T20:32:15Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:32:15Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T20:32:16Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:41:18Z,comex,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T20:45:55Z,mkpankov,work@michaelpankov.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T20:56:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T21:17:26Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T21:36:43Z,belgum,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T21:45:22Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T21:46:02Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T21:46:03Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T21:46:03Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-21T21:55:41Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T22:06:24Z,scooterman,victor.v.carvalho@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T22:16:55Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-21T22:50:44Z,nelhage,nelhage@nelhage.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-21T22:59:01Z,winding-lines,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T00:16:01Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T00:44:46Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T01:34:01Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T01:35:52Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T01:35:54Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T01:35:55Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T01:48:51Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T02:21:23Z,alex-ozdemir,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T02:21:48Z,GGist,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T02:29:41Z,rozbb,michael@mrosenberg.pub https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T03:23:40Z,bryce-anderson,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T04:26:49Z,tikue,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T05:34:07Z,stanciua,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T06:26:16Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T06:31:03Z,shmatov,romanshmatov@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T06:31:10Z,shmatov,romanshmatov@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T06:55:11Z,rap2hpoutre,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T06:55:13Z,rap2hpoutre,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T06:55:15Z,rap2hpoutre,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T07:13:23Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T07:13:26Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T07:13:28Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T07:22:06Z,tomusdrw,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-22T08:29:33Z,fdb,frederik@debleser.be https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T08:55:07Z,gbersac,bersac_1@hotmail.fr https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T11:04:17Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T11:04:22Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T12:04:34Z,geniusisme,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-22T13:07:56Z,maciejhirsz,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T14:50:58Z,hexsel,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-22T18:44:53Z,cormac-obrien,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-23T00:15:04Z,dragostis,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-23T11:04:11Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-23T11:14:30Z,taheris,github@taheris.net https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-23T14:23:33Z,NicolasDP,nicolas@primetype.co.uk https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-23T20:26:01Z,vadimcn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-23T20:26:03Z,vadimcn,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-25T21:01:06Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-28T19:45:52Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-28T21:00:40Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-31T14:45:55Z,TheWaWaR,thewawar@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-07-31T21:08:33Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-07-31T21:08:34Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-07-31T21:08:36Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-08-03T13:08:22Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-08-03T13:30:17Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-08-03T14:56:31Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-08-05T08:07:52Z,emoon,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-08-18T19:59:56Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-08-18T20:00:07Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-08-18T21:32:41Z,l0kod,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-08-19T09:30:18Z,kirillkh,kirillkh@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-08-19T19:42:48Z,lisp-ceo,j@lisp-ceo.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-08-29T00:34:09Z,mcarton,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-09-19T15:54:19Z,Cldfire,NA https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2016-09-23T02:13:38Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2016-09-29T02:26:15Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2016-12-23T01:15:56Z,kingoflolz,wangben3@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2020-02-11T17:37:30Z,landreussi,lucasandreussi@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2021-08-05T08:21:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2021-08-05T08:21:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2021-08-05T08:21:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HEART,2021-11-16T16:15:17Z,UltiRequiem,eliaz.bobadilladev@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,HOORAY,2021-11-16T16:15:18Z,UltiRequiem,eliaz.bobadilladev@gmail.com https://github.com/rust-lang/rust/pull/34956,MERGED,2016-07-21T16:59:46Z,2016-07-29T00:17:06Z,Enable reuse of `.o` files if nothing has changed,nikomatsakis,42cd5d4ee28a1c1b3bf4f07e27b1ca5a03fd9b02,1,make it possible to track where hash diverges,THUMBS_UP,2021-11-16T16:15:19Z,UltiRequiem,eliaz.bobadilladev@gmail.com https://github.com/rust-lang/rust/pull/34988,MERGED,2016-07-23T00:25:03Z,2016-07-24T23:29:10Z,Doc example improvements for `slice::windows`.,frewsxcv,c77f8ce7c3284441a00faed6782d08eb5a78296c,1,Doc example improvements for `slice::windows`. * Modify existing example to not rely on printing to see results * Add an example demonstrating when slice is shorter than `size`,THUMBS_UP,2016-07-23T01:52:58Z,Havvy,NA https://github.com/rust-lang/rust/pull/34989,MERGED,2016-07-23T01:45:34Z,2016-07-24T23:29:15Z,Fix incorrect 'memory leak' example for `Vec::set_len`.,frewsxcv,1e0043eb6c445fb96981b6d46dae4c93af4fbda3,1,Fix incorrect 'memory leak' example for `Vec::set_len`. Example was written in https://github.com/rust-lang/rust/pull/34911 Issue was brought up in this comment: https://github.com/rust-lang/rust/commit/a005b2cd2ac679da7393e537aa05e2b7d32d36d5#commitcomment-18346958,THUMBS_UP,2016-07-23T01:53:55Z,Havvy,NA https://github.com/rust-lang/rust/pull/35020,CLOSED,2016-07-25T03:04:08Z,2016-08-03T01:55:35Z,rustdoc: simplify URLs,nrc,NA,NA,NA,HOORAY,2016-07-25T03:14:31Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/35020,CLOSED,2016-07-25T03:04:08Z,2016-08-03T01:55:35Z,rustdoc: simplify URLs,nrc,NA,NA,NA,HOORAY,2016-08-01T20:52:13Z,Havvy,NA https://github.com/rust-lang/rust/pull/35042,MERGED,2016-07-26T05:16:30Z,2016-08-05T21:42:46Z,Add Derive not possible question to Copy,Havvy,157f7c1b30698dcdb2452e687f4940550a6e6467,1,Add Derive not possible question to Copy This adds a question and answer to the Q&A section of the Copy docs. Specifically it asks the question I asked while reading the docs and gives its answer.,CONFUSED,2016-07-26T07:22:52Z,jseyfried,NA https://github.com/rust-lang/rust/pull/35042,MERGED,2016-07-26T05:16:30Z,2016-08-05T21:42:46Z,Add Derive not possible question to Copy,Havvy,157f7c1b30698dcdb2452e687f4940550a6e6467,1,Add Derive not possible question to Copy This adds a question and answer to the Q&A section of the Copy docs. Specifically it asks the question I asked while reading the docs and gives its answer.,CONFUSED,2016-07-26T18:01:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35051,MERGED,2016-07-26T20:23:51Z,2016-07-30T11:35:44Z,rustbuild: make backtraces (RUST_BACKTRACE) optional,japaric,774fbdf40deb9b257dd6aa166096fed1eeac80c2,3,keep backtraces if using the old build system,HEART,2022-01-17T00:10:08Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/35054,MERGED,2016-07-26T21:21:41Z,2016-08-02T06:42:52Z,implement `From>` and `From<&'a [char]>` for `String`,pwoolcoc,ac73335f2f5421c914fa3900567696cc6dc73d8d,1,implement `From>` and `From<&'a [char]>` for `String` Though there are ways to convert a slice or vec of chars into a string it would be nice to be able to just do `String::from(['a' 'b' 'c'])` so this PR implements `From>` and `From<&'a [char]>` for String.,HOORAY,2016-08-15T02:02:52Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/35074,MERGED,2016-07-27T17:48:24Z,2016-09-21T18:35:26Z,add debug_assert_ne + assert_ne,ashleygwilliams,3d8d55787b2c0f5b1aba01b08da13bf0d612818c,4,add assert_ne and debug_assert_ne macros,THUMBS_UP,2016-09-19T05:36:17Z,sinkuu,NA https://github.com/rust-lang/rust/pull/35074,MERGED,2016-07-27T17:48:24Z,2016-09-21T18:35:26Z,add debug_assert_ne + assert_ne,ashleygwilliams,3d8d55787b2c0f5b1aba01b08da13bf0d612818c,4,add assert_ne and debug_assert_ne macros,THUMBS_UP,2016-09-21T18:56:51Z,CryZe,NA https://github.com/rust-lang/rust/pull/35074,MERGED,2016-07-27T17:48:24Z,2016-09-21T18:35:26Z,add debug_assert_ne + assert_ne,ashleygwilliams,3d8d55787b2c0f5b1aba01b08da13bf0d612818c,4,add assert_ne and debug_assert_ne macros,THUMBS_UP,2016-09-21T21:14:24Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/35074,MERGED,2016-07-27T17:48:24Z,2016-09-21T18:35:26Z,add debug_assert_ne + assert_ne,ashleygwilliams,3d8d55787b2c0f5b1aba01b08da13bf0d612818c,4,add assert_ne and debug_assert_ne macros,THUMBS_UP,2016-09-27T20:37:38Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-28T00:48:48Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-28T11:09:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-28T14:07:46Z,oli-obk,NA https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-28T15:53:55Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-28T18:38:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-07-29T10:01:22Z,Diggsey,NA https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2016-09-21T04:42:52Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35080,MERGED,2016-07-28T00:05:33Z,2016-07-30T14:27:31Z,Rename _ to {integer} and {float} for unknown numeric types,jntrnr,ea77049cfa72358d6a2d6370a3f7a6a70d93b8e8,35,Move to {integer} and {float},HOORAY,2021-05-20T22:10:20Z,zohnannor,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:22:43Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:23:06Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T16:25:34Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:28:24Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:38:23Z,krdln,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:45:14Z,WaDelma,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:51:48Z,durka,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T16:58:54Z,cristicbz,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T16:58:57Z,cristicbz,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T17:07:21Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T17:09:07Z,Diggsey,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T17:42:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T17:47:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T18:07:56Z,shmatov,romanshmatov@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T18:20:38Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T18:33:42Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T18:43:12Z,skade,florian.gilcher@ferrous-systems.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T18:45:41Z,alexbool,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T18:45:43Z,alexbool,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T19:13:25Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T19:14:42Z,tikue,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T19:18:59Z,maksimsco,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T19:19:05Z,maksimsco,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T19:21:31Z,kylewlacy,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T19:24:16Z,ruuda,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-28T19:45:22Z,goertzenator,daniel.goertzen@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T19:56:32Z,killercup,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T20:51:56Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T21:02:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T21:24:29Z,arthurprs,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T21:31:10Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T21:46:48Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T22:53:01Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T23:20:01Z,futile,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T23:50:53Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-28T23:51:20Z,Meyermagic,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T00:28:13Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-07-29T00:37:02Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T01:24:46Z,Limeth,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T01:43:14Z,fuchsnj,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-29T01:43:15Z,fuchsnj,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-07-29T01:43:16Z,fuchsnj,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,LAUGH,2016-07-29T01:43:21Z,fuchsnj,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T01:53:35Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T03:06:21Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T03:30:50Z,ben0x539,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T05:26:54Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T06:41:30Z,lemmabit,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T06:44:50Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T07:44:15Z,imp,cyril.plisko@mountall.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T07:58:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-29T08:13:23Z,milibopp,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T08:13:27Z,milibopp,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T09:00:21Z,uasi,uasi@uasi.jp https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T09:36:25Z,sinkuu,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T09:44:48Z,norcalli,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T10:16:46Z,BourgondAries,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T11:38:32Z,aka-demik,mail4aka@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T11:58:58Z,regexident,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T12:31:51Z,azerupi,mathieudavid@mathieudavid.org https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T15:53:11Z,utkarshkukreti,utkarshkukreti@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T18:23:37Z,jethrogb,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T19:10:40Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-07-29T19:10:42Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-07-29T19:10:44Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T21:25:39Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-29T22:53:09Z,Valloric,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-07-30T02:47:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-30T03:17:27Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-30T19:54:02Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-31T12:56:45Z,friedroman,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-07-31T18:18:09Z,Byron,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-03T07:38:11Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-11T07:35:21Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-11T16:53:13Z,cbrewster,cbrewster@hey.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-11T18:37:48Z,cbrewster,cbrewster@hey.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-08-11T18:37:48Z,cbrewster,cbrewster@hey.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,LAUGH,2016-08-11T18:37:48Z,cbrewster,cbrewster@hey.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-11T18:52:29Z,sercand,sercan@otsimo.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-11T19:23:53Z,critiqjo,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-11T19:34:16Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T00:07:07Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-12T13:02:17Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-08-12T13:02:20Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T13:02:36Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T13:46:42Z,bluss,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T13:53:38Z,nathanross,nathan@nathanross.tech https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T14:08:04Z,TheNeikos,neikos@neikos.email https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-12T14:54:20Z,dpzmick,dpzmick@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T16:35:23Z,xitep,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-12T19:34:08Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-13T06:07:35Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-13T06:09:39Z,thehydroimpulse,dnfagnan@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-08-13T07:15:37Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-13T07:57:05Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-13T15:52:08Z,jwilm,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-08-13T15:52:11Z,jwilm,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-14T14:33:11Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-14T18:46:22Z,8573,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-17T02:10:23Z,jeandudey,me@jeandudey.tech https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-08-17T02:10:23Z,jeandudey,me@jeandudey.tech https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-17T02:10:26Z,jeandudey,me@jeandudey.tech https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-17T03:02:13Z,zitsen,linhehuo@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-08-20T06:26:22Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-08-20T07:38:58Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2016-09-01T03:13:28Z,SnirkImmington,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-09-02T11:25:17Z,norru,nigu.orru@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HEART,2016-09-15T10:15:36Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-10-01T13:51:23Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2016-10-11T13:30:00Z,lloydmeta,NA https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,HOORAY,2017-09-14T10:32:29Z,JJJollyjim,jamie@kwiius.com https://github.com/rust-lang/rust/pull/35091,MERGED,2016-07-28T16:21:04Z,2016-08-12T11:30:51Z,Implement `impl Trait` in return type position by anonymization.,eddyb,23f0494114a39e503a369a345847b8bc9577c216,7,test: add more extensive tests for impl Trait.,THUMBS_UP,2018-02-09T14:00:04Z,lweberk,NA https://github.com/rust-lang/rust/pull/35102,MERGED,2016-07-28T23:01:55Z,2016-11-09T16:51:24Z,Make it clear that the reference isn't normative,steveklabnik,daf2d7d63a0fe633dcbc223994849be76e230cae,1,Make it clear that the reference isn't normative Any time someone edits the reference it has to be taken very seriously since it's the closest thing we have to a specification. This commit adds language which indicates that this is not a normative document which makes it easier to make tweaks without worrying about forever harming the future of Rust by painting ourselves in a corner.,THUMBS_UP,2016-07-29T00:45:46Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/35102,MERGED,2016-07-28T23:01:55Z,2016-11-09T16:51:24Z,Make it clear that the reference isn't normative,steveklabnik,daf2d7d63a0fe633dcbc223994849be76e230cae,1,Make it clear that the reference isn't normative Any time someone edits the reference it has to be taken very seriously since it's the closest thing we have to a specification. This commit adds language which indicates that this is not a normative document which makes it easier to make tweaks without worrying about forever harming the future of Rust by painting ourselves in a corner.,THUMBS_UP,2016-07-29T09:55:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35102,MERGED,2016-07-28T23:01:55Z,2016-11-09T16:51:24Z,Make it clear that the reference isn't normative,steveklabnik,daf2d7d63a0fe633dcbc223994849be76e230cae,1,Make it clear that the reference isn't normative Any time someone edits the reference it has to be taken very seriously since it's the closest thing we have to a specification. This commit adds language which indicates that this is not a normative document which makes it easier to make tweaks without worrying about forever harming the future of Rust by painting ourselves in a corner.,THUMBS_UP,2016-10-10T17:19:58Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35124,MERGED,2016-07-29T22:57:13Z,2016-08-27T13:00:51Z,Remove style guide.,steveklabnik,57719e2d73acdda337d1f68640ab551226cbe404,1,Also remove build steps for style,THUMBS_UP,2016-07-31T17:09:15Z,est31,NA https://github.com/rust-lang/rust/pull/35124,MERGED,2016-07-29T22:57:13Z,2016-08-27T13:00:51Z,Remove style guide.,steveklabnik,57719e2d73acdda337d1f68640ab551226cbe404,1,Also remove build steps for style,THUMBS_UP,2016-08-15T22:17:21Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/35124,MERGED,2016-07-29T22:57:13Z,2016-08-27T13:00:51Z,Remove style guide.,steveklabnik,57719e2d73acdda337d1f68640ab551226cbe404,1,Also remove build steps for style,HEART,2016-08-15T22:17:25Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/35141,MERGED,2016-07-31T19:18:14Z,2016-08-01T22:27:06Z,rustc_trans: apply the debug location for the MIR Assert panic call.,eddyb,d1f341dd91f7660bd64acfbd63f4513f9a327217,1,rustc_trans: apply the debug location for the MIR Assert panic call.,THUMBS_UP,2016-08-01T07:18:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2016-08-24T08:23:04Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2016-08-24T17:45:49Z,critiqjo,NA https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2016-08-29T14:25:32Z,vinipsmaker,NA https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2017-01-12T00:37:48Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2017-09-06T15:29:38Z,derekdreery,NA https://github.com/rust-lang/rust/pull/35162,MERGED,2016-08-01T12:09:01Z,2016-08-16T11:41:31Z,Implement the `!` type,canndrew,f59f1f0914de50ffa70e3000c317a14f6d1b8605,1,Fix bug for ! in old trans,HOORAY,2021-09-22T17:56:53Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/35166,MERGED,2016-08-01T18:18:59Z,2016-08-09T21:04:58Z,Address ICEs running w/ incremental compilation and building glium,nikomatsakis,e0b82d5c3a159fabf0dae4632f294f17eacda1d0,1,fix license,HOORAY,2016-08-04T12:37:14Z,futile,NA https://github.com/rust-lang/rust/pull/35166,MERGED,2016-08-01T18:18:59Z,2016-08-09T21:04:58Z,Address ICEs running w/ incremental compilation and building glium,nikomatsakis,e0b82d5c3a159fabf0dae4632f294f17eacda1d0,1,fix license,HOORAY,2016-08-05T21:05:27Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/35166,MERGED,2016-08-01T18:18:59Z,2016-08-09T21:04:58Z,Address ICEs running w/ incremental compilation and building glium,nikomatsakis,e0b82d5c3a159fabf0dae4632f294f17eacda1d0,1,fix license,HOORAY,2016-08-09T09:27:59Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/35168,MERGED,2016-08-01T19:00:13Z,2016-08-04T13:53:27Z,[MIR] Deaggregate structs to enable further optimizations,scottcarr,06acf16cdb23dad19b9cf816a55df24d4084823c,1,reduce rightward drift add precondition comment,HOORAY,2016-08-01T19:50:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35168,MERGED,2016-08-01T19:00:13Z,2016-08-04T13:53:27Z,[MIR] Deaggregate structs to enable further optimizations,scottcarr,06acf16cdb23dad19b9cf816a55df24d4084823c,1,reduce rightward drift add precondition comment,HOORAY,2016-08-02T19:59:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35174,MERGED,2016-08-01T23:37:26Z,2016-08-03T17:53:27Z,Audit C++ types in rustllvm,arielb1,3041a97b1acef4f8549d9e297db8deaf571341f2,19,finish type-auditing rustllvm,THUMBS_UP,2016-08-01T23:52:47Z,brson,NA https://github.com/rust-lang/rust/pull/35174,MERGED,2016-08-01T23:37:26Z,2016-08-03T17:53:27Z,Audit C++ types in rustllvm,arielb1,3041a97b1acef4f8549d9e297db8deaf571341f2,19,finish type-auditing rustllvm,THUMBS_UP,2016-08-02T00:13:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35174,MERGED,2016-08-01T23:37:26Z,2016-08-03T17:53:27Z,Audit C++ types in rustllvm,arielb1,3041a97b1acef4f8549d9e297db8deaf571341f2,19,finish type-auditing rustllvm,THUMBS_UP,2016-08-02T01:59:26Z,bstrie,NA https://github.com/rust-lang/rust/pull/35174,MERGED,2016-08-01T23:37:26Z,2016-08-03T17:53:27Z,Audit C++ types in rustllvm,arielb1,3041a97b1acef4f8549d9e297db8deaf571341f2,19,finish type-auditing rustllvm,THUMBS_UP,2016-08-04T18:49:19Z,jminer,NA https://github.com/rust-lang/rust/pull/35181,MERGED,2016-08-02T12:00:26Z,2016-08-05T21:42:55Z,Add doc example for Vec,GuillaumeGomez,1fa9b8dc96f95ec5d6c95746d58e96f507ab85fd,1,Add doc example for Vec,THUMBS_UP,2016-08-02T12:26:59Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35234,MERGED,2016-08-03T00:54:07Z,2016-08-20T18:26:16Z,rustdoc: remove the `!` from macro URLs and titles,nrc,301401e568e6ed297ab0b06c5cf60d8ba8109750,2,Redirect,THUMBS_UP,2016-08-10T20:14:40Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35234,MERGED,2016-08-03T00:54:07Z,2016-08-20T18:26:16Z,rustdoc: remove the `!` from macro URLs and titles,nrc,301401e568e6ed297ab0b06c5cf60d8ba8109750,2,Redirect,THUMBS_UP,2016-08-27T00:02:52Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35392,MERGED,2016-08-05T20:10:59Z,2016-08-15T01:36:38Z,Implement From for Cell RefCell and UnsafeCell,malbarbo,1403df72c82d3c3c2c19369c5f4bb34b3e095604,1,Implement From for Cell RefCell and UnsafeCell,THUMBS_UP,2016-08-17T07:43:17Z,diwic,NA https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,HOORAY,2016-08-06T13:44:39Z,trixnz,NA https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,HOORAY,2016-08-06T13:52:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,THUMBS_UP,2016-08-07T06:27:18Z,mchesser,NA https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,HOORAY,2016-08-08T09:11:42Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,HOORAY,2016-08-16T19:50:57Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/35401,MERGED,2016-08-05T23:13:43Z,2016-08-10T02:12:56Z,Turn on new errors and json mode,jntrnr,9b510ba39a839caeef1badc77ecd2a641465b1bf,1,Update cargo SHA to latest cargo,HOORAY,2016-09-28T22:23:24Z,Parth,parth.mehrotra.cs@gmail.com https://github.com/rust-lang/rust/pull/35409,MERGED,2016-08-06T02:16:18Z,2016-08-14T22:27:20Z,[MIR] Add Storage{Live Dead} statements to emit llvm.lifetime.{start end}.,eddyb,1bb14445160329c2ca5ff9c202e791ca0098d944,2,Get rid of the .note interpretation of rustc dylib metadata.,HEART,2016-08-14T18:41:37Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35409,MERGED,2016-08-06T02:16:18Z,2016-08-14T22:27:20Z,[MIR] Add Storage{Live Dead} statements to emit llvm.lifetime.{start end}.,eddyb,1bb14445160329c2ca5ff9c202e791ca0098d944,2,Get rid of the .note interpretation of rustc dylib metadata.,HEART,2016-08-15T01:09:25Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35409,MERGED,2016-08-06T02:16:18Z,2016-08-14T22:27:20Z,[MIR] Add Storage{Live Dead} statements to emit llvm.lifetime.{start end}.,eddyb,1bb14445160329c2ca5ff9c202e791ca0098d944,2,Get rid of the .note interpretation of rustc dylib metadata.,HEART,2016-08-17T00:47:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/35414,MERGED,2016-08-06T07:12:57Z,2016-08-13T19:54:51Z,Add --test-threads option to test binaries,jupp0r,6ca90942e744f79982a9b485e2367b0ecee14527,3,Add --test-threads option to test binaries This change allows parallelism of test runs to be specified by a command line flag names --test-threads in addition to the existing environment variable RUST_TEST_THREADS. Fixes #25636.,HOORAY,2016-08-18T08:12:08Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-08-07T20:42:00Z,durka,NA https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-08-08T22:16:07Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-08-09T07:11:14Z,pocket7878,poketo7878@gmail.com https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-08-13T14:32:45Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-08-18T20:33:08Z,Idyllei,idyllei@protonmail.com https://github.com/rust-lang/rust/pull/35453,MERGED,2016-08-07T07:22:28Z,2016-08-14T10:50:55Z,macros: Make metavariables hygienic,jseyfried,95b68aa5eacac7fb6340829289871da6e517e8b0,1,Fix fallout in tests.,THUMBS_UP,2016-09-23T14:19:19Z,bluss,NA https://github.com/rust-lang/rust/pull/35456,MERGED,2016-08-07T08:00:49Z,2016-08-08T18:15:42Z,typeck: suggest (x.field)(...) to call struct fields even when x is a reference,birkenfeld,59af2ac098ae6bb927799dfec03e9bb9934ccb8f,2,typeck: suggest (x.field)(...) to call struct fields even when x is a reference Fixes: #33784,THUMBS_UP,2016-08-17T08:44:11Z,Limeth,NA https://github.com/rust-lang/rust/pull/35564,CLOSED,2016-08-10T07:12:54Z,2016-08-16T18:38:30Z,Generalize `contains` method on `SliceExt`,insaneinside,NA,NA,NA,THUMBS_UP,2016-08-10T15:10:27Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/35564,CLOSED,2016-08-10T07:12:54Z,2016-08-16T18:38:30Z,Generalize `contains` method on `SliceExt`,insaneinside,NA,NA,NA,THUMBS_UP,2016-08-10T17:54:24Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/35564,CLOSED,2016-08-10T07:12:54Z,2016-08-16T18:38:30Z,Generalize `contains` method on `SliceExt`,insaneinside,NA,NA,NA,THUMBS_UP,2016-08-11T17:11:17Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/35564,CLOSED,2016-08-10T07:12:54Z,2016-08-16T18:38:30Z,Generalize `contains` method on `SliceExt`,insaneinside,NA,NA,NA,THUMBS_UP,2016-08-11T23:46:09Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/35564,CLOSED,2016-08-10T07:12:54Z,2016-08-16T18:38:30Z,Generalize `contains` method on `SliceExt`,insaneinside,NA,NA,NA,THUMBS_UP,2016-08-12T09:32:39Z,jseyfried,NA https://github.com/rust-lang/rust/pull/35574,MERGED,2016-08-10T18:20:54Z,2016-08-15T01:36:42Z,Emscripten test fixes,badboy,60599df03b094c81923ab863c6fd616ef2c15806,6,[emscripten] Disable code paths that don't work on emscripten,THUMBS_UP,2016-08-10T19:15:52Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/35608,CLOSED,2016-08-11T22:30:47Z,2016-11-01T01:35:39Z,[MIR] Dataflow framework constant propagation and dead code elimination,nagisa,NA,NA,NA,HOORAY,2016-08-11T22:32:29Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35608,CLOSED,2016-08-11T22:30:47Z,2016-11-01T01:35:39Z,[MIR] Dataflow framework constant propagation and dead code elimination,nagisa,NA,NA,NA,HOORAY,2016-08-12T00:32:16Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/35608,CLOSED,2016-08-11T22:30:47Z,2016-11-01T01:35:39Z,[MIR] Dataflow framework constant propagation and dead code elimination,nagisa,NA,NA,NA,HOORAY,2016-08-12T02:47:04Z,kornholi,NA https://github.com/rust-lang/rust/pull/35608,CLOSED,2016-08-11T22:30:47Z,2016-11-01T01:35:39Z,[MIR] Dataflow framework constant propagation and dead code elimination,nagisa,NA,NA,NA,HOORAY,2016-08-12T12:32:16Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-12T01:57:36Z,brson,NA https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-12T02:22:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-12T04:19:54Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-12T14:18:38Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-15T10:30:17Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-16T16:07:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-17T20:40:44Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-08-27T00:05:36Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35611,MERGED,2016-08-11T23:30:56Z,2016-08-15T01:36:45Z,Improve &-ptr printing,jntrnr,42247372c6c507beed4d309ea5867579d5b65511,17,Improve &-ptr printing,HEART,2016-09-29T18:26:06Z,bluss,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,THUMBS_UP,2016-08-12T18:30:02Z,retep998,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,THUMBS_UP,2016-08-12T19:57:07Z,durka,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-12T20:59:04Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-13T13:49:10Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-15T07:25:45Z,kennytm,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-15T11:12:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-19T21:14:06Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35623,CLOSED,2016-08-12T17:31:11Z,2016-08-23T05:44:44Z,core: impl From for (),seanmonstar,NA,NA,NA,CONFUSED,2016-08-23T13:33:03Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/35647,MERGED,2016-08-13T09:44:30Z,2016-08-15T01:36:49Z,Ensure that attributes are spelled properly.,ahmedcharles,6fbff4f06a7e5b62d985c2ce28c5303bf5b8fe43,23,Ensure that attributes are spelled properly.,HEART,2016-08-13T13:55:56Z,killercup,NA https://github.com/rust-lang/rust/pull/35648,MERGED,2016-08-13T09:50:31Z,2016-08-15T01:36:49Z,Predicates haven't existed in almost 5 years.,ahmedcharles,ab00b940bb6e47e5fc59d363396fe6fc9e3245c6,1,Predicates haven't existed in almost 5 years. This test probably adds negative value other than historical amusement.,LAUGH,2016-08-13T10:02:16Z,retep998,NA https://github.com/rust-lang/rust/pull/35648,MERGED,2016-08-13T09:50:31Z,2016-08-15T01:36:49Z,Predicates haven't existed in almost 5 years.,ahmedcharles,ab00b940bb6e47e5fc59d363396fe6fc9e3245c6,1,Predicates haven't existed in almost 5 years. This test probably adds negative value other than historical amusement.,LAUGH,2016-08-13T16:10:39Z,durka,NA https://github.com/rust-lang/rust/pull/35667,MERGED,2016-08-14T17:55:23Z,2016-09-14T15:28:06Z,rustdoc: Don't add extra newlines for fully opaque structs,ollie27,8154a6bc69b42813ffda91adcefd9f277338acf3,2,rustdoc: Don't add extra newlines for fully opaque structs Changes the definition for opaque structs to look like `pub struct Vec { /* fields omitted */ }` to save space on the page. Also only use one line for empty braced structs.,HEART,2016-08-15T03:11:04Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/35667,MERGED,2016-08-14T17:55:23Z,2016-09-14T15:28:06Z,rustdoc: Don't add extra newlines for fully opaque structs,ollie27,8154a6bc69b42813ffda91adcefd9f277338acf3,2,rustdoc: Don't add extra newlines for fully opaque structs Changes the definition for opaque structs to look like `pub struct Vec { /* fields omitted */ }` to save space on the page. Also only use one line for empty braced structs.,THUMBS_UP,2016-08-15T06:27:39Z,tomjakubowski,tom@crystae.net https://github.com/rust-lang/rust/pull/35667,MERGED,2016-08-14T17:55:23Z,2016-09-14T15:28:06Z,rustdoc: Don't add extra newlines for fully opaque structs,ollie27,8154a6bc69b42813ffda91adcefd9f277338acf3,2,rustdoc: Don't add extra newlines for fully opaque structs Changes the definition for opaque structs to look like `pub struct Vec { /* fields omitted */ }` to save space on the page. Also only use one line for empty braced structs.,THUMBS_UP,2016-08-17T08:48:08Z,killercup,NA https://github.com/rust-lang/rust/pull/35667,MERGED,2016-08-14T17:55:23Z,2016-09-14T15:28:06Z,rustdoc: Don't add extra newlines for fully opaque structs,ollie27,8154a6bc69b42813ffda91adcefd9f277338acf3,2,rustdoc: Don't add extra newlines for fully opaque structs Changes the definition for opaque structs to look like `pub struct Vec { /* fields omitted */ }` to save space on the page. Also only use one line for empty braced structs.,THUMBS_UP,2016-08-17T20:07:38Z,peschkaj,NA https://github.com/rust-lang/rust/pull/35667,MERGED,2016-08-14T17:55:23Z,2016-09-14T15:28:06Z,rustdoc: Don't add extra newlines for fully opaque structs,ollie27,8154a6bc69b42813ffda91adcefd9f277338acf3,2,rustdoc: Don't add extra newlines for fully opaque structs Changes the definition for opaque structs to look like `pub struct Vec { /* fields omitted */ }` to save space on the page. Also only use one line for empty braced structs.,THUMBS_UP,2016-08-17T20:26:57Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/35679,CLOSED,2016-08-15T11:42:30Z,2016-08-15T13:36:08Z,Remove width limit for docs,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2016-08-15T11:55:27Z,sanpii,NA https://github.com/rust-lang/rust/pull/35679,CLOSED,2016-08-15T11:42:30Z,2016-08-15T13:36:08Z,Remove width limit for docs,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2016-08-17T20:27:54Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/35682,CLOSED,2016-08-15T14:19:46Z,2016-08-17T20:28:44Z,Center content of the generated docs,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2016-08-17T08:41:42Z,killercup,NA https://github.com/rust-lang/rust/pull/35682,CLOSED,2016-08-15T14:19:46Z,2016-08-17T20:28:44Z,Center content of the generated docs,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2016-08-17T20:27:40Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/35688,CLOSED,2016-08-15T18:56:02Z,2016-08-16T00:35:31Z,Update spans that live in std macros to their use sites,jntrnr,NA,NA,NA,THUMBS_UP,2016-08-15T19:00:16Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/35688,CLOSED,2016-08-15T18:56:02Z,2016-08-16T00:35:31Z,Update spans that live in std macros to their use sites,jntrnr,NA,NA,NA,THUMBS_UP,2016-08-15T19:22:37Z,alexbool,NA https://github.com/rust-lang/rust/pull/35688,CLOSED,2016-08-15T18:56:02Z,2016-08-16T00:35:31Z,Update spans that live in std macros to their use sites,jntrnr,NA,NA,NA,HOORAY,2016-08-15T22:24:20Z,durka,NA https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,THUMBS_UP,2016-08-16T00:43:34Z,hexsel,NA https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,HOORAY,2016-08-16T05:33:46Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,HOORAY,2016-08-16T08:07:49Z,killercup,NA https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,HOORAY,2016-08-17T18:28:31Z,sfackler,NA https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,THUMBS_UP,2016-08-17T19:32:49Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/35702,MERGED,2016-08-15T23:19:31Z,2016-08-18T07:15:16Z,Replace macro backtraces with labeled local uses,jntrnr,54d42cc912d1510e561a4d4274e4f821becd1736,2,Rebase. Fix mutable iteration nit.,THUMBS_UP,2016-11-13T15:59:59Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/35707,MERGED,2016-08-16T03:47:25Z,2016-08-17T20:08:24Z,Implement `Debug` for `std::vec::IntoIter`.,frewsxcv,bc52bdcedcb34e303d2a3a450b541dfbf002281e,2,Implement `Debug` for `std::vec::IntoIter`. Display all the remaining items of the iterator similar to the `Debug` implementation for `core::slice::Iter`: https://github.com/rust-lang/rust/blob/f0bab98695f0a4877daabad9a5b0ba3e66121392/src/libcore/slice.rs#L930-L937 Using the `as_slice` method that was added in: https://github.com/rust-lang/rust/pull/35447,THUMBS_UP,2016-08-16T12:51:54Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/35708,MERGED,2016-08-16T08:16:21Z,2016-08-17T20:08:24Z,RUST_NEW_ERROR_FORMAT is no more,sanxiyn,d52eb1ab0ce5a8a1c5e86b7d606c4eac5d4447ea,19,RUST_NEW_ERROR_FORMAT is no more,THUMBS_UP,2016-08-16T21:40:53Z,jntrnr,NA https://github.com/rust-lang/rust/pull/35709,MERGED,2016-08-16T08:18:22Z,2016-08-20T18:26:18Z,replace `Add` example with something more evocative of addition,matthew-piziak,dcee93a8030c3a62c5a05b45b050f90251d93af8,1,"replace Add example with something more evocative of addition Currently most of the operator traits use trivial implementation examples that only perform side effects. Honestly that might not be too bad for the sake of documentation; but anyway here's a proposal to move a slightly modified version of the module-level point-addition example into the `Add` documentation since it's more evocative of addition semantics. Part of #29365 wrap identifiers in backticks minor rephrasing fix module-level documentation to be more truthful This branch changes the example for `Add` to no longer be a ""minimum implementation that prints something to the screen"".",THUMBS_UP,2016-08-20T23:20:57Z,bluss,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2016-08-16T11:27:00Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2016-11-18T12:20:33Z,est31,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2017-01-31T14:07:00Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,HOORAY,2017-02-02T07:41:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2017-07-04T10:20:48Z,petro-rudenko,petro.rudenko@gmail.com https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2019-12-13T06:40:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,HOORAY,2019-12-13T06:40:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2020-03-24T03:58:08Z,usagi,the@usagi.network https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2020-08-20T21:05:27Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2020-12-19T03:40:09Z,ioistired,gie9ohbeixah@paperboats.net https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2021-01-17T19:42:09Z,elogic-cscts,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2021-09-22T01:57:52Z,mohsenpakzad,NA https://github.com/rust-lang/rust/pull/35712,MERGED,2016-08-16T11:14:23Z,2017-01-25T04:36:10Z,exclusive range patterns,oli-obk,98fef41d63a91759790f5bbe4ac746b5c1a670ba,3,test slice patterns with exclusive range patterns,THUMBS_UP,2022-05-18T19:22:36Z,kaanyalova,NA https://github.com/rust-lang/rust/pull/35715,CLOSED,2016-08-16T13:27:46Z,2016-10-31T20:27:15Z,impl Error for !,canndrew,NA,NA,NA,HOORAY,2016-09-06T23:34:41Z,tikue,NA https://github.com/rust-lang/rust/pull/35732,MERGED,2016-08-16T22:03:07Z,2016-08-18T15:54:17Z,Move 'doesn't live long enough' errors to labels,jntrnr,864b3efd3302c9447f4d689779efda4a7b52c294,2,Fix tidy and nits,HOORAY,2016-08-17T18:23:37Z,durka,NA https://github.com/rust-lang/rust/pull/35732,MERGED,2016-08-16T22:03:07Z,2016-08-18T15:54:17Z,Move 'doesn't live long enough' errors to labels,jntrnr,864b3efd3302c9447f4d689779efda4a7b52c294,2,Fix tidy and nits,HOORAY,2016-08-17T21:03:31Z,KiChjang,NA https://github.com/rust-lang/rust/pull/35732,MERGED,2016-08-16T22:03:07Z,2016-08-18T15:54:17Z,Move 'doesn't live long enough' errors to labels,jntrnr,864b3efd3302c9447f4d689779efda4a7b52c294,2,Fix tidy and nits,THUMBS_UP,2016-08-17T21:03:36Z,KiChjang,NA https://github.com/rust-lang/rust/pull/35732,MERGED,2016-08-16T22:03:07Z,2016-08-18T15:54:17Z,Move 'doesn't live long enough' errors to labels,jntrnr,864b3efd3302c9447f4d689779efda4a7b52c294,2,Fix tidy and nits,THUMBS_UP,2016-08-18T16:56:41Z,mhristache,NA https://github.com/rust-lang/rust/pull/35736,MERGED,2016-08-16T23:12:30Z,2016-08-18T02:48:02Z,1.11 changelog,brson,9863afe029092d421c9a3daafd6b7a718d53f1cf,1,1.11 changelog,THUMBS_UP,2016-08-16T23:19:26Z,retep998,NA https://github.com/rust-lang/rust/pull/35736,MERGED,2016-08-16T23:12:30Z,2016-08-18T02:48:02Z,1.11 changelog,brson,9863afe029092d421c9a3daafd6b7a718d53f1cf,1,1.11 changelog,HEART,2016-08-16T23:48:52Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35736,MERGED,2016-08-16T23:12:30Z,2016-08-18T02:48:02Z,1.11 changelog,brson,9863afe029092d421c9a3daafd6b7a718d53f1cf,1,1.11 changelog,HEART,2016-08-17T04:26:25Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/35755,MERGED,2016-08-17T17:13:57Z,2016-09-01T13:05:07Z,Implement std::convert traits for char,SimonSapin,f040208d533e1d6d9ee0e0408ee74e26e14d1284,5,Implement TryFrom for char For symmetry with From for u32.,THUMBS_UP,2016-09-02T00:02:33Z,mcarton,NA https://github.com/rust-lang/rust/pull/35761,MERGED,2016-08-17T19:06:27Z,2016-09-02T01:59:12Z,Cache projections in trans,nikomatsakis,00d208eea87c1cbeefb8a0a83237a71c9eea2d6c,7,remove `normalize_infer_ctxt` constructor,THUMBS_UP,2016-08-18T18:13:09Z,jroesch,NA https://github.com/rust-lang/rust/pull/35761,MERGED,2016-08-17T19:06:27Z,2016-09-02T01:59:12Z,Cache projections in trans,nikomatsakis,00d208eea87c1cbeefb8a0a83237a71c9eea2d6c,7,remove `normalize_infer_ctxt` constructor,HEART,2016-08-19T13:18:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/35761,MERGED,2016-08-17T19:06:27Z,2016-09-02T01:59:12Z,Cache projections in trans,nikomatsakis,00d208eea87c1cbeefb8a0a83237a71c9eea2d6c,7,remove `normalize_infer_ctxt` constructor,HEART,2016-09-02T02:58:17Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:14:42Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:15:45Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:15:46Z,durka,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:16:04Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:16:47Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:18:09Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:31:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T20:55:18Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T21:06:05Z,retep998,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-17T21:40:47Z,KiChjang,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T00:09:08Z,mystal,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T00:10:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T00:28:15Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T01:02:47Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T01:14:48Z,emberian,ember@lunar.town https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T01:38:34Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T02:01:06Z,kornholi,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T02:18:53Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T02:27:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T03:39:40Z,jroesch,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T03:41:39Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T04:12:09Z,jminer,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T04:22:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T05:45:57Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T06:29:53Z,wfraser,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T06:33:13Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T06:38:59Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T06:47:05Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T06:57:40Z,lifthrasiir,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T07:23:23Z,mkpankov,work@michaelpankov.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T07:25:28Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T07:27:33Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T08:28:59Z,pczarn,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T08:30:05Z,nfnty,git@nfnty.se https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T09:58:28Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T10:13:46Z,Thiez,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T10:40:16Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T12:03:26Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T12:09:24Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T13:32:07Z,vks,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T14:11:33Z,ambaxter,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T14:59:32Z,chrish42,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T15:10:31Z,jnicklas,jonas@jnicklas.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T17:01:52Z,hauleth,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T19:01:31Z,critiqjo,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T20:31:42Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T21:02:04Z,nickmccurdy,nick@nickmccurdy.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T22:07:25Z,kmcallister,mcallister.keegan@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-18T23:15:45Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-19T01:30:46Z,erincandescent,erin.shepherd@e43.eu https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-19T01:54:38Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-19T14:45:50Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-20T02:24:59Z,bb010g,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-22T17:24:54Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-23T08:41:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-23T08:42:13Z,bluss,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-24T02:54:12Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-25T05:20:52Z,xen0n,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-25T18:32:43Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-25T22:08:49Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,THUMBS_UP,2016-08-25T23:37:47Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-26T23:55:10Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-27T15:00:33Z,danilaml,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-08-31T10:27:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-09-11T02:39:43Z,renato-zannon,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-09-22T01:42:47Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-10-01T08:46:09Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-11-09T21:10:50Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-11-14T08:40:01Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,THUMBS_UP,2016-11-14T08:40:02Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/35764,MERGED,2016-08-17T20:10:28Z,2016-08-25T01:42:29Z,Remove the old AST-based backend from rustc_trans.,eddyb,25cf8001b1352fdaccdd1d71071c941f99acc2a1,19,Remove AST from metadata except for consts and const fns.,HOORAY,2016-11-21T09:31:31Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/35765,MERGED,2016-08-17T20:49:55Z,2016-08-18T11:36:50Z,Additional span info for E0053,KiChjang,31d56cb144ead0811935a09d32d7b2febc5b42de,2,Add UI test for E0053,HOORAY,2016-08-17T21:24:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/35814,MERGED,2016-08-19T00:56:55Z,2016-08-25T10:05:47Z,rustc: Don't enable NEON by default on armv7 Linux,alexcrichton,1cf510d1decf5a1a450c9c60e6dd71f402b4c307,1,rustc: Don't enable NEON by default on armv7 Linux One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target Linux distributions do not enable NEON extensions by default. This PR disables that feature by defualt but enables the `d16` feature which enables VFP3D16 that distributions do enable. Closes #35590,THUMBS_UP,2016-08-25T18:42:20Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/35814,MERGED,2016-08-19T00:56:55Z,2016-08-25T10:05:47Z,rustc: Don't enable NEON by default on armv7 Linux,alexcrichton,1cf510d1decf5a1a450c9c60e6dd71f402b4c307,1,rustc: Don't enable NEON by default on armv7 Linux One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target Linux distributions do not enable NEON extensions by default. This PR disables that feature by defualt but enables the `d16` feature which enables VFP3D16 that distributions do enable. Closes #35590,THUMBS_DOWN,2016-08-28T09:42:23Z,MagaTailor,NA https://github.com/rust-lang/rust/pull/35827,MERGED,2016-08-19T16:31:43Z,2016-08-20T18:26:25Z,replace `Not` example with something more evocative,matthew-piziak,06147ac29152877830454330c16fd82f23d050df,1,replace `Not` example with something more evocative,THUMBS_UP,2016-08-19T16:40:58Z,Havvy,NA https://github.com/rust-lang/rust/pull/35830,MERGED,2016-08-19T16:46:42Z,2016-08-20T18:26:31Z,replace `Neg` example with something more evocative of negation,matthew-piziak,c0eccb120326bc559a4cbe30ace4935d83420073,1,replace `Neg` example with something more evocative of negation,THUMBS_UP,2016-08-19T16:48:34Z,Havvy,NA https://github.com/rust-lang/rust/pull/35830,MERGED,2016-08-19T16:46:42Z,2016-08-20T18:26:31Z,replace `Neg` example with something more evocative of negation,matthew-piziak,c0eccb120326bc559a4cbe30ace4935d83420073,1,replace `Neg` example with something more evocative of negation,THUMBS_UP,2016-08-20T09:17:33Z,killercup,NA https://github.com/rust-lang/rust/pull/35833,CLOSED,2016-08-19T18:17:52Z,2016-10-06T21:40:52Z,Allow [] for macro invocation in `item` places,bossmc,NA,NA,NA,THUMBS_UP,2016-08-19T19:23:18Z,durka,NA https://github.com/rust-lang/rust/pull/35833,CLOSED,2016-08-19T18:17:52Z,2016-10-06T21:40:52Z,Allow [] for macro invocation in `item` places,bossmc,NA,NA,NA,THUMBS_UP,2016-09-27T11:23:57Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/35850,MERGED,2016-08-20T07:38:31Z,2016-08-30T13:01:45Z,Implement RFC#1559: allow all literals in attributes,SergioBenitez,8250a26b5bcea9190ac63e756c35d8a54bf9da0c,45,Implement RFC#1559: allow all literals in attributes.,HOORAY,2016-08-20T07:52:13Z,retep998,NA https://github.com/rust-lang/rust/pull/35860,MERGED,2016-08-20T18:14:48Z,2016-08-23T03:52:07Z,replace `Mul` example with something more evocative of multiplication,matthew-piziak,38f0bca8657fa330561edb4dca04efe8a898f6ea,1,replace `Mul` example with something more evocative of multiplication I may have gone a bit overboard on this one. Numbers are fun. tone down the error message,THUMBS_UP,2016-08-21T16:34:34Z,killercup,NA https://github.com/rust-lang/rust/pull/35862,MERGED,2016-08-20T19:30:48Z,2016-08-30T17:07:27Z,Clarify/fix formatting docs concerning fmt::Result/fmt::Error,Stebalien,c7d5f7e5e638775e45c4fdc64f3b91bdbfca9c28,1,Rust has type aliases not typedefs. They're the same thing but it's better to keep the terminology consistent.,THUMBS_UP,2016-08-21T03:16:25Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/35868,CLOSED,2016-08-20T23:46:59Z,2016-09-12T22:22:22Z,Add Duration::to_nanos,SimonSapin,NA,NA,NA,THUMBS_UP,2016-08-21T00:47:22Z,retep998,NA https://github.com/rust-lang/rust/pull/35871,MERGED,2016-08-21T11:38:29Z,2016-08-22T18:22:56Z,cstring: avoid excessive growth just to 0-terminate,bluss,876c02cc1ab537703c4d6f19693dd9a42b131442,1,"cstring: avoid excessive growth just to 0-terminate Based on following what happens in CString::new(""string literal""): 1. Using `Into>` a Vec is allocated with capacity exactly equal to the string's input length. 2. By `v.push(0)` the Vec is grown to twice capacity since it was full. 3. By `v.into_boxed_slice()` the Vec capacity is shrunk to fit the length again. If we use `.reserve_exact(1)` just before the push then we avoid the capacity doubling that we're going to have to shrink anyway. Growing by just 1 byte means that the step (2) is less likely to have to move the memory to a larger allocation chunk and that the step (3) does not have to reallocate.",THUMBS_UP,2016-08-21T20:51:12Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/35871,MERGED,2016-08-21T11:38:29Z,2016-08-22T18:22:56Z,cstring: avoid excessive growth just to 0-terminate,bluss,876c02cc1ab537703c4d6f19693dd9a42b131442,1,"cstring: avoid excessive growth just to 0-terminate Based on following what happens in CString::new(""string literal""): 1. Using `Into>` a Vec is allocated with capacity exactly equal to the string's input length. 2. By `v.push(0)` the Vec is grown to twice capacity since it was full. 3. By `v.into_boxed_slice()` the Vec capacity is shrunk to fit the length again. If we use `.reserve_exact(1)` just before the push then we avoid the capacity doubling that we're going to have to shrink anyway. Growing by just 1 byte means that the step (2) is less likely to have to move the memory to a larger allocation chunk and that the step (3) does not have to reallocate.",THUMBS_UP,2016-08-31T02:12:40Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/35871,MERGED,2016-08-21T11:38:29Z,2016-08-22T18:22:56Z,cstring: avoid excessive growth just to 0-terminate,bluss,876c02cc1ab537703c4d6f19693dd9a42b131442,1,"cstring: avoid excessive growth just to 0-terminate Based on following what happens in CString::new(""string literal""): 1. Using `Into>` a Vec is allocated with capacity exactly equal to the string's input length. 2. By `v.push(0)` the Vec is grown to twice capacity since it was full. 3. By `v.into_boxed_slice()` the Vec capacity is shrunk to fit the length again. If we use `.reserve_exact(1)` just before the push then we avoid the capacity doubling that we're going to have to shrink anyway. Growing by just 1 byte means that the step (2) is less likely to have to move the memory to a larger allocation chunk and that the step (3) does not have to reallocate.",THUMBS_UP,2016-08-31T10:26:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/35880,CLOSED,2016-08-21T21:02:16Z,2016-10-03T15:40:18Z,add links to interesting items in `std::ptr` documentation,matthew-piziak,NA,NA,NA,THUMBS_UP,2016-08-21T22:54:13Z,killercup,NA https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-08-22T11:23:51Z,hexsel,NA https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-08-22T18:19:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-08-22T20:00:00Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-08-23T09:25:08Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-09-02T10:01:06Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-09-06T16:27:58Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/35894,MERGED,2016-08-22T06:59:34Z,2016-09-02T05:24:41Z,Implement RFC 1560 behind `#![feature(item_like_imports)]`,jseyfried,90ce504c1c3dc014ca8e0aa91e21c46569a9d4ab,4,Address comments.,HOORAY,2016-09-06T20:34:06Z,tioover,tioover@gmail.com https://github.com/rust-lang/rust/pull/35912,MERGED,2016-08-23T00:39:05Z,2016-08-24T02:43:28Z,Update rust-installer. Fixes #35840,brson,f863ea3d16fe0362249bd2f130a0b64022ca1b10,1,Update rust-installer. Fixes #35840,THUMBS_UP,2016-08-23T00:48:37Z,Diggsey,NA https://github.com/rust-lang/rust/pull/35947,MERGED,2016-08-23T20:14:03Z,2016-08-25T15:12:05Z,Yield Err in char::decode_utf8 per Unicode like String::from_utf8_lossy,SimonSapin,46226a7a6e967eaae297c462457df8f2db148565,2,Yield Err in char::decode_utf8 per Unicode like String::from_utf8_lossy,HEART,2016-08-23T21:31:00Z,bluss,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-24T00:16:00Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-24T01:49:15Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-24T01:49:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-24T07:20:27Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-25T04:12:21Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-25T05:49:13Z,xen0n,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-25T22:19:49Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-27T02:28:18Z,achanda,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-28T16:01:36Z,arthurprs,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,THUMBS_UP,2016-08-28T18:48:29Z,achanda,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,THUMBS_UP,2016-08-31T01:49:10Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-08-31T01:49:12Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,THUMBS_UP,2016-08-31T13:54:54Z,ljedrz,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-09-02T07:33:53Z,est31,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,THUMBS_UP,2016-09-14T00:53:37Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,THUMBS_UP,2016-09-15T18:59:30Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-10-04T03:27:39Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-10-05T20:48:42Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-10-27T06:35:08Z,spinda,NA https://github.com/rust-lang/rust/pull/35954,CLOSED,2016-08-24T00:13:49Z,2016-11-21T04:43:41Z,Initial implementation of the 128-bit integers,nagisa,NA,NA,NA,HOORAY,2016-11-12T09:21:00Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T06:53:24Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T07:02:34Z,futile,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T07:07:25Z,alexbool,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HEART,2016-08-24T07:30:17Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T07:45:34Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T08:16:36Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T10:05:43Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T12:33:59Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T12:36:20Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HEART,2016-08-24T13:30:32Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-24T17:15:21Z,durka,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-25T17:23:00Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-25T22:19:00Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-27T16:25:53Z,mcarton,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-28T21:35:12Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-29T07:11:48Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-08-31T13:55:24Z,ljedrz,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-03T11:10:27Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-04T21:12:58Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-06T16:28:27Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-06T16:28:29Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-06T20:24:47Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-06T22:12:11Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-07T02:16:14Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-07T05:01:09Z,critiqjo,NA https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-07T05:49:55Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/35957,MERGED,2016-08-24T06:49:47Z,2016-09-03T10:18:56Z,rustc: Implement custom derive (macros 1.1),alexcrichton,ecc6c39e876b69496bc88ef47ff3a339662346b1,84,"rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation however not the public interface. This commit also ended up touching a lot of code related to `#[derive]` making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default they have to opt in on a granular level. * The `derive(Copy Clone)` optimization is now done through another ""obscure attribute"" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq Eq MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]",HOORAY,2016-09-22T23:33:53Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/35990,CLOSED,2016-08-25T13:55:32Z,2016-08-28T19:37:44Z,Don't allow underflow when calculating spans,sgrif,NA,NA,NA,THUMBS_UP,2016-09-02T12:35:26Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/36005,MERGED,2016-08-26T00:58:29Z,2016-08-27T13:00:58Z,Replace unnecessary uses of `TraitObject` with casts,apasel422,2b10df7f24828b09759277cc3a9c18c493c38ce0,4,Replace unnecessary uses of `TraitObject` with casts,HOORAY,2016-08-26T04:37:15Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36014,MERGED,2016-08-26T15:33:07Z,2016-08-27T13:00:58Z,Stabilize type-macros,slash3g,ee055a1ff37bb47f32ed460ca7d249d91f8cbe7d,14,Stabilize type-macros Closes #27245,HOORAY,2016-08-26T15:50:29Z,durka,NA https://github.com/rust-lang/rust/pull/36014,MERGED,2016-08-26T15:33:07Z,2016-08-27T13:00:58Z,Stabilize type-macros,slash3g,ee055a1ff37bb47f32ed460ca7d249d91f8cbe7d,14,Stabilize type-macros Closes #27245,THUMBS_UP,2016-08-27T14:39:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36014,MERGED,2016-08-26T15:33:07Z,2016-08-27T13:00:58Z,Stabilize type-macros,slash3g,ee055a1ff37bb47f32ed460ca7d249d91f8cbe7d,14,Stabilize type-macros Closes #27245,THUMBS_UP,2016-08-27T23:20:37Z,hexsel,NA https://github.com/rust-lang/rust/pull/36014,MERGED,2016-08-26T15:33:07Z,2016-08-27T13:00:58Z,Stabilize type-macros,slash3g,ee055a1ff37bb47f32ed460ca7d249d91f8cbe7d,14,Stabilize type-macros Closes #27245,HOORAY,2016-09-01T08:15:15Z,kennytm,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-08-26T17:00:51Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-08-26T22:26:54Z,retep998,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HEART,2016-08-26T22:26:57Z,retep998,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,THUMBS_UP,2016-08-26T22:26:59Z,retep998,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-09-02T02:40:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-09-03T19:31:15Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-09-03T22:53:56Z,jminer,NA https://github.com/rust-lang/rust/pull/36016,MERGED,2016-08-26T16:32:36Z,2016-09-03T18:06:59Z,Implement untagged unions (RFC 1444),petrochenkov,436cfe56534b405786816d4bbcccd11ed7571981,7,Fix type encoding/decoding for unions Fix union debuginfo test on lldb,HOORAY,2016-09-08T05:27:10Z,zhangyt26,zhangyt26@gmail.com https://github.com/rust-lang/rust/pull/36017,CLOSED,2016-08-26T16:56:28Z,2016-08-26T18:40:54Z,Disabling incremental/ich_method_call_trait_scope.rs,jntrnr,NA,NA,NA,HEART,2016-08-26T16:57:13Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36024,MERGED,2016-08-26T22:18:19Z,2016-09-02T13:16:03Z,add mips64-gnu and mips64el-gnu targets,japaric,bbf2c3c31f3dd7703f4a13724bada979a921a65f,1,update libc submodule,THUMBS_UP,2016-09-02T13:29:32Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36024,MERGED,2016-08-26T22:18:19Z,2016-09-02T13:16:03Z,add mips64-gnu and mips64el-gnu targets,japaric,bbf2c3c31f3dd7703f4a13724bada979a921a65f,1,update libc submodule,THUMBS_UP,2016-09-02T16:25:12Z,xen0n,NA https://github.com/rust-lang/rust/pull/36024,MERGED,2016-08-26T22:18:19Z,2016-09-02T13:16:03Z,add mips64-gnu and mips64el-gnu targets,japaric,bbf2c3c31f3dd7703f4a13724bada979a921a65f,1,update libc submodule,HOORAY,2016-09-02T16:25:17Z,xen0n,NA https://github.com/rust-lang/rust/pull/36027,MERGED,2016-08-27T02:12:56Z,2016-08-28T07:36:25Z,rustc_trans: don't round up the DST prefix size to its alignment.,eddyb,3e313d9528adc64042012a19cc9a700bff11f19d,5,rustc_trans: don't round up the DST prefix size to its alignment.,THUMBS_UP,2016-08-27T02:36:41Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/36028,MERGED,2016-08-27T02:16:14Z,2016-08-28T10:28:46Z,initial support for s390x,japaric,027eab2f87d8cd30949e257cb52f520077575ff2,6,"initial support for s390x A new target `s390x-unknown-linux-gnu` has been added to the compiler and can be used to build no_core/no_std Rust programs. Known limitations: - librustc_trans/cabi_s390x.rs is missing. This means no support for `extern ""C"" fn`. - No support for this arch in libc. This means std can be cross compiled for this target.",HOORAY,2016-08-28T14:56:33Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36045,MERGED,2016-08-27T16:46:51Z,2016-09-10T17:19:32Z,rustdoc: Add missing item types to page titles,ollie27,a7c671bb90ba1584d0098460ad8e417f848913f9,2,"rustdoc: Add missing item types to page titles Most pages include the item type in the title such as ""Struct std::vec::Vec"". However it is missing from the pages for foreign functions type definitions macros statics and constants. This adds them so for example instead of a title of ""std::u32::MAX"" it is ""Constant std::u32::MAX"" to match the others.",THUMBS_UP,2016-09-07T20:31:21Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36045,MERGED,2016-08-27T16:46:51Z,2016-09-10T17:19:32Z,rustdoc: Add missing item types to page titles,ollie27,a7c671bb90ba1584d0098460ad8e417f848913f9,2,"rustdoc: Add missing item types to page titles Most pages include the item type in the title such as ""Struct std::vec::Vec"". However it is missing from the pages for foreign functions type definitions macros statics and constants. This adds them so for example instead of a title of ""std::u32::MAX"" it is ""Constant std::u32::MAX"" to match the others.",THUMBS_UP,2016-09-07T20:31:53Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-08-28T05:48:05Z,samlh,NA https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-08-28T07:20:54Z,alexbool,NA https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-08-28T10:06:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-08-29T03:21:25Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-08-31T02:14:41Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-09-06T20:29:36Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-09-06T21:51:45Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-09-07T05:23:12Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/36059,MERGED,2016-08-27T23:33:57Z,2016-08-29T02:09:33Z,Improve Demangling of Rust Symbols,CryZe,121b2fe988f47996933af699d6223de8e9262df0,1,Improve Demangling of Rust Symbols This turns `..` into `::` handles some more escapes and gets rid of unwanted underscores at the beginning of path elements. ![Image of Diff](http://puu.sh/qQIN3.png),HEART,2016-09-07T05:32:30Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/36062,MERGED,2016-08-28T02:49:39Z,2016-08-29T07:49:12Z,rustbuild: smarter `git submodule`-ing,japaric,4b5007a1a25c09746307c9e8cabdc6292f969582,1,fix tidy error,THUMBS_UP,2016-09-24T13:39:52Z,MagaTailor,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-08-29T22:23:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-08-29T22:25:00Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-08-29T22:28:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-09-01T18:28:38Z,kryptan,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-09-07T08:39:00Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-09-21T13:58:25Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-09-22T19:09:40Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-09-29T17:11:20Z,bombless,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-10-23T17:51:49Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-10-24T02:28:45Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-10-25T22:32:59Z,jminer,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2016-11-26T07:26:18Z,JinShil,NA https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2018-01-02T20:57:17Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/36120,CLOSED,2016-08-29T22:18:25Z,2016-10-31T20:32:27Z,[WIP] internal lld linker,japaric,NA,NA,NA,HOORAY,2018-11-02T04:19:41Z,SamuelMarks,NA https://github.com/rust-lang/rust/pull/36151,MERGED,2016-08-30T22:54:51Z,2016-09-26T05:03:31Z,refactor to remove trans::adt and make rustc::ty::layout authoritative,ahicks92,467454b0d2577795a579968ebd7bfa3bf9753404,6,Incorporate review comments.,HEART,2016-09-13T11:50:09Z,bluss,NA https://github.com/rust-lang/rust/pull/36151,MERGED,2016-08-30T22:54:51Z,2016-09-26T05:03:31Z,refactor to remove trans::adt and make rustc::ty::layout authoritative,ahicks92,467454b0d2577795a579968ebd7bfa3bf9753404,6,Incorporate review comments.,HEART,2016-09-19T18:26:19Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/36151,MERGED,2016-08-30T22:54:51Z,2016-09-26T05:03:31Z,refactor to remove trans::adt and make rustc::ty::layout authoritative,ahicks92,467454b0d2577795a579968ebd7bfa3bf9753404,6,Incorporate review comments.,HEART,2016-09-20T19:50:10Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36151,MERGED,2016-08-30T22:54:51Z,2016-09-26T05:03:31Z,refactor to remove trans::adt and make rustc::ty::layout authoritative,ahicks92,467454b0d2577795a579968ebd7bfa3bf9753404,6,Incorporate review comments.,HEART,2016-09-28T00:01:45Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36154,MERGED,2016-08-31T00:04:45Z,2016-09-23T02:54:59Z,Adds a `ProcMacro` form of syntax extension,nrc,3863834d9c75230224e36783780d260f52e10d49,9,reviewer comments and rebasing,THUMBS_UP,2016-08-31T20:03:29Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/36171,MERGED,2016-08-31T17:05:58Z,2016-09-03T04:02:47Z,Update lifetime errors to specifically note temporaries,jntrnr,439afcd9747808fb187b0676d63af5375a677e3d,6,Update error message for lifetime of borrowed values,THUMBS_UP,2016-08-31T20:39:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36171,MERGED,2016-08-31T17:05:58Z,2016-09-03T04:02:47Z,Update lifetime errors to specifically note temporaries,jntrnr,439afcd9747808fb187b0676d63af5375a677e3d,6,Update error message for lifetime of borrowed values,HEART,2016-09-06T21:55:20Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/36171,MERGED,2016-08-31T17:05:58Z,2016-09-03T04:02:47Z,Update lifetime errors to specifically note temporaries,jntrnr,439afcd9747808fb187b0676d63af5375a677e3d,6,Update error message for lifetime of borrowed values,THUMBS_UP,2016-09-09T06:53:38Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36178,MERGED,2016-08-31T22:24:37Z,2016-09-03T04:02:47Z,Special case a few colors for Windows,jntrnr,1b0476297e6d8bee01197e507f50350a748388a2,2,Special case a few colors for Windows,THUMBS_UP,2016-08-31T23:44:39Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36178,MERGED,2016-08-31T22:24:37Z,2016-09-03T04:02:47Z,Special case a few colors for Windows,jntrnr,1b0476297e6d8bee01197e507f50350a748388a2,2,Special case a few colors for Windows,THUMBS_UP,2016-09-01T07:20:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36180,MERGED,2016-08-31T23:11:07Z,2016-09-03T04:02:47Z,Transition Travis CI to use rustbuild.,frewsxcv,3a96fe32753f0308002e18d165f52d54e5ac64cb,2,Transition Travis CI to use rustbuild.,HOORAY,2016-09-01T02:10:26Z,retep998,NA https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-08-31T23:14:29Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-09-01T11:04:50Z,hexsel,NA https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-09-13T11:38:51Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-09-20T19:37:41Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-09-21T13:26:51Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,HEART,2016-09-22T10:16:20Z,josephDunne,NA https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2016-10-29T21:32:35Z,ruuda,NA https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2017-01-15T04:59:30Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,THUMBS_UP,2020-05-31T11:05:58Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/36181,MERGED,2016-08-31T23:12:16Z,2016-09-13T22:08:17Z,core: add likely and unlikely intrinsics,seanmonstar,b778f7fa0192ac6863f3ce0ab49d9c4001bf5503,4,core: add likely and unlikely intrinsics,HEART,2020-05-31T11:05:59Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/36186,CLOSED,2016-09-01T09:54:18Z,2016-10-13T18:41:48Z,Implement `replace_with` a function similar to the one provided by the `take_mut` crate.,ticki,NA,NA,NA,THUMBS_UP,2016-09-16T14:49:51Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/36186,CLOSED,2016-09-01T09:54:18Z,2016-10-13T18:41:48Z,Implement `replace_with` a function similar to the one provided by the `take_mut` crate.,ticki,NA,NA,NA,THUMBS_UP,2021-07-12T05:24:14Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/36198,MERGED,2016-09-01T17:54:28Z,2016-09-03T04:02:48Z,test: Add a min-llvm-version directive,alexcrichton,96283fc08367ae8c3d344f2342c4ebe11d799092,7,test: Add a min-llvm-version directive We've got tests which require a particular version of LLVM to run as they're testing bug fixes. Our build system however supports multiple LLVM versions so we can't run these tests on all LLVM versions. This adds a new `min-llvm-version` directive for tests so they can opt out of being run on older versions of LLVM. This then namely applies that logic to the `issue-36023.rs` test case and... Closes #36138,THUMBS_UP,2016-09-01T17:56:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36198,MERGED,2016-09-01T17:54:28Z,2016-09-03T04:02:48Z,test: Add a min-llvm-version directive,alexcrichton,96283fc08367ae8c3d344f2342c4ebe11d799092,7,test: Add a min-llvm-version directive We've got tests which require a particular version of LLVM to run as they're testing bug fixes. Our build system however supports multiple LLVM versions so we can't run these tests on all LLVM versions. This adds a new `min-llvm-version` directive for tests so they can opt out of being run on older versions of LLVM. This then namely applies that logic to the `issue-36023.rs` test case and... Closes #36138,THUMBS_UP,2016-09-01T18:49:05Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36198,MERGED,2016-09-01T17:54:28Z,2016-09-03T04:02:48Z,test: Add a min-llvm-version directive,alexcrichton,96283fc08367ae8c3d344f2342c4ebe11d799092,7,test: Add a min-llvm-version directive We've got tests which require a particular version of LLVM to run as they're testing bug fixes. Our build system however supports multiple LLVM versions so we can't run these tests on all LLVM versions. This adds a new `min-llvm-version` directive for tests so they can opt out of being run on older versions of LLVM. This then namely applies that logic to the `issue-36023.rs` test case and... Closes #36138,THUMBS_UP,2016-09-01T19:31:26Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/36203,MERGED,2016-09-01T20:59:34Z,2016-09-05T00:14:40Z,Replace `_ _` with `..` in patterns,petrochenkov,e05e74ac831bc8438f5daeb98432a29285ed9514,107,Replace `_ _` with `..`,THUMBS_UP,2016-09-01T21:05:11Z,durka,NA https://github.com/rust-lang/rust/pull/36206,MERGED,2016-09-02T00:09:59Z,2016-10-28T20:42:24Z,Fix bad error message with `::<` in types,mcarton,f7cc6dc1eddc367f988017172d09d96ce191e5e1,2,Fix bad error message with `::<` in types,THUMBS_UP,2016-10-25T21:54:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T11:31:31Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T11:32:40Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T11:40:30Z,retep998,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T12:57:34Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T15:32:02Z,durka,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,THUMBS_UP,2016-09-02T16:28:16Z,8573,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-02T16:58:33Z,kornholi,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,CONFUSED,2016-09-03T05:13:57Z,durka,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-03T08:45:52Z,killercup,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-06T23:20:16Z,tikue,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-08T13:09:16Z,bluss,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-08T16:56:24Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-12T08:56:28Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-14T18:28:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-15T01:31:03Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-16T08:04:46Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2016-09-18T16:58:26Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/36214,MERGED,2016-09-02T11:30:02Z,2016-09-08T05:30:54Z,macros: stackless expansion,jseyfried,9ac91fa48b3eb479cccb5695395faed8f59ece8e,1,Improve `directory` computation during invocation collection.,HOORAY,2017-01-15T15:54:09Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-05T01:20:03Z,retep998,NA https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-07T02:47:25Z,durka,NA https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-08T16:24:50Z,bluss,NA https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-20T19:29:13Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-21T00:12:58Z,tikue,NA https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-24T05:06:22Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2016-09-24T05:08:28Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2017-01-31T08:45:15Z,ssokolow,NA https://github.com/rust-lang/rust/pull/36264,MERGED,2016-09-04T15:51:54Z,2016-09-13T15:07:00Z,Zero first byte of CString on drop,matklad,f9a340804c998f25691be182fc8bc40b8fc9a496,1,Add a test for CString drop,THUMBS_UP,2017-11-04T05:02:45Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/36289,MERGED,2016-09-06T01:52:38Z,2016-09-07T16:15:40Z,resolve: Suggest `use self` when import resolves,euclio,288e7caf19b415007787f47424c9e00913cb7803,2,show `self` suggestion when items are in the block,THUMBS_UP,2017-05-14T10:06:49Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/36289,MERGED,2016-09-06T01:52:38Z,2016-09-07T16:15:40Z,resolve: Suggest `use self` when import resolves,euclio,288e7caf19b415007787f47424c9e00913cb7803,2,show `self` suggestion when items are in the block,HEART,2017-05-14T10:06:51Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/36306,MERGED,2016-09-06T19:05:17Z,2016-11-04T10:38:22Z,A way to remove otherwise unused locals from MIR,nagisa,475236770fe4fd973957d734a074a54c5ac88c87,6,A way to remove otherwise unused locals from MIR Replaces the hack where a similar thing is done within trans.,THUMBS_UP,2016-11-04T12:28:55Z,alexbool,NA https://github.com/rust-lang/rust/pull/36310,MERGED,2016-09-07T00:42:37Z,2016-09-08T08:44:58Z,Removing the extraneous not_equal implementation for slices,jstnlef,a77b55d58f9b173b1e4fb96bb6935fadbfda3240,1,remove the extraneous not_equal implementation for slices.,THUMBS_UP,2016-09-08T16:59:14Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-09-08T03:12:33Z,durka,NA https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-09-08T09:33:28Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-09-08T16:55:28Z,bluss,NA https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-09-16T15:12:02Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-09-19T10:53:36Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/36334,MERGED,2016-09-07T23:18:58Z,2016-09-14T19:04:35Z,Set run button transparent instead of invisible,GuillaumeGomez,a2faf5477c46e425d02b48ec0be6eea49c694fc2,5,Set run button transparent instead of invisible,HEART,2016-10-16T12:04:11Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T02:27:44Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T02:44:55Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T05:23:23Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T07:37:36Z,killercup,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T10:03:01Z,badboy,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T14:17:32Z,leeola,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T14:29:07Z,adjivas,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T15:57:29Z,reddraggone9,cljenkins9@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T18:25:46Z,mystal,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T20:24:02Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T21:03:04Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-08T21:03:07Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-09-08T21:03:10Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-08T21:12:31Z,CryZe,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T21:12:32Z,CryZe,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T21:21:20Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-08T23:11:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-08T23:11:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-09T09:08:44Z,louisremi,lrbabe@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-09T10:09:01Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-09T14:43:10Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-11T06:40:28Z,justsml,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-12T10:30:29Z,christophehurpeau,christophe@hurpeau.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-09-12T10:38:11Z,benaryorg,github@benary.org https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-13T01:23:49Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-13T14:26:51Z,ticki,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-09-13T14:26:52Z,ticki,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-13T14:26:53Z,ticki,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-14T01:43:43Z,seanjensengrey,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-17T01:55:06Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-09-17T01:55:12Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-09-17T01:55:13Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-18T14:49:29Z,tp,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-22T20:16:05Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-09-28T20:07:44Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-09-29T03:27:25Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T07:44:27Z,Arrem,alem.zupa@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T09:07:12Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T12:26:49Z,nathanross,nathan@nathanross.tech https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T13:38:06Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T14:17:10Z,marcoms,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-01T14:17:10Z,marcoms,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T14:17:11Z,marcoms,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T17:04:21Z,LeDominik,dominik@wagenknecht.cc https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T17:25:04Z,kmcallister,mcallister.keegan@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T18:31:14Z,Valinora,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-01T18:31:25Z,Valinora,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T18:31:25Z,Valinora,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T18:37:45Z,mytrile,dimitar.kostov@protonmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T18:39:29Z,lqd,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T19:33:36Z,belst,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T19:47:27Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T20:01:37Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T20:13:32Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T20:20:18Z,adrientetar,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T21:54:41Z,spiffistan,aaa@hey.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T22:57:01Z,trishume,tris.hume@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-01T23:22:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-01T23:29:40Z,mrageh,madam@cloudbees.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T23:42:06Z,d-xo,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-01T23:42:26Z,bvssvni,bvssvni@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T00:30:34Z,g-k,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T00:56:34Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T01:12:39Z,GlenDC,contact@glendc.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T02:36:32Z,daniloisr,danilo.isr@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T03:17:32Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T03:40:28Z,ronjouch,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T03:40:30Z,ronjouch,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T03:53:50Z,brendanzab,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T05:19:48Z,mickmaccallum,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T05:31:34Z,wrmsr,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T05:32:03Z,Nebopolis,bevans@zendesk.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T05:42:32Z,dannycoates,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T06:07:19Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T06:07:22Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T06:22:41Z,Tankenstein,ukutammet@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T07:44:00Z,ryukinix,manoel_vilela@engineer.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T07:44:01Z,ryukinix,manoel_vilela@engineer.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T07:44:01Z,ryukinix,manoel_vilela@engineer.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T11:04:43Z,jakubzitny,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T11:11:23Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T12:42:03Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-02T12:42:04Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T12:42:06Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T17:34:04Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-02T19:12:03Z,Isinlor,isinlor@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-02T21:21:28Z,bancek,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-03T21:19:28Z,mike-marcacci,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-04T18:07:53Z,joaolucasl,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-04T18:07:58Z,joaolucasl,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-04T18:08:00Z,joaolucasl,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-05T22:38:50Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-10-05T23:05:17Z,Ixrec,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-10-06T15:57:46Z,vaartis,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-08T13:09:13Z,olehdevua,olehdevua@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-09T14:37:36Z,lucklove,gnu.crazier@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-10-12T12:14:08Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-11-01T11:28:54Z,burgalon,burgalon@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-11-01T11:28:56Z,burgalon,burgalon@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2016-11-03T22:05:41Z,ashleysommer,ashleysommer@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2016-11-03T22:05:45Z,ashleysommer,ashleysommer@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-11-30T18:04:29Z,fermuch,fermuch@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2016-12-13T19:15:02Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HOORAY,2017-01-05T19:24:26Z,whmountains,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2017-01-05T19:24:27Z,whmountains,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,HEART,2017-01-05T19:24:29Z,whmountains,NA https://github.com/rust-lang/rust/pull/36339,MERGED,2016-09-08T02:16:44Z,2016-10-01T06:49:03Z,Working asmjs and wasm targets,brson,afa72b5dd6b75ed4577a4e73c1525dcd58d93b51,2,Don't build any native compiler-builtin components for emscripten,THUMBS_UP,2017-03-29T15:18:53Z,M-Adoo,Adoo@outlook.com https://github.com/rust-lang/rust/pull/36340,MERGED,2016-09-08T04:06:09Z,2016-11-27T03:49:41Z,Implement RFC 1679,sfackler,5377b5e9c4270222cbbca99dae45715dd9d87d1c,7,Overload get{ _mut}{ _unchecked},THUMBS_UP,2016-10-07T00:54:57Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/36340,MERGED,2016-09-08T04:06:09Z,2016-11-27T03:49:41Z,Implement RFC 1679,sfackler,5377b5e9c4270222cbbca99dae45715dd9d87d1c,7,Overload get{ _mut}{ _unchecked},THUMBS_UP,2016-12-06T11:57:02Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/36340,MERGED,2016-09-08T04:06:09Z,2016-11-27T03:49:41Z,Implement RFC 1679,sfackler,5377b5e9c4270222cbbca99dae45715dd9d87d1c,7,Overload get{ _mut}{ _unchecked},THUMBS_UP,2016-12-12T21:35:59Z,bluss,NA https://github.com/rust-lang/rust/pull/36341,MERGED,2016-09-08T04:59:19Z,2016-10-10T18:34:15Z,Add ThreadId for comparing threads,sagebind,032bffa5b8ae6c3977884c4e10fd6ab6a5dc5ef6,1,Unlock guard before overflow panic,THUMBS_UP,2016-10-03T15:41:35Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/36357,MERGED,2016-09-09T03:35:13Z,2016-09-13T11:57:32Z,Tweak std::mem docs (#29362),kmcallister,72e103fe90f678f6c6028f17cdd9a5b825a8c5f9,2,Tweak std::mem docs Fixes #29362.,HEART,2016-09-09T04:11:58Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36366,CLOSED,2016-09-09T16:45:00Z,2016-09-12T15:26:36Z,update docstrings for `mem::update` and `mem::swap`,matthew-piziak,NA,NA,NA,THUMBS_UP,2016-09-09T17:28:12Z,durka,NA https://github.com/rust-lang/rust/pull/36369,MERGED,2016-09-09T21:31:59Z,2016-09-11T22:12:34Z,Add s390x support,uweigand,19b84088d76b8ded63cbaf12991213f4f437e689,26,"Add s390x support This adds support for building the Rust compiler and standard library for s390x-linux allowing a full cross-bootstrap sequence to complete. This includes: - Makefile/configure changes to allow native s390x builds - Full Rust compiler support for the s390x C ABI (only the non-vector ABI is supported at this point) - Port of the standard library to s390x - Update the liblibc submodule to a version including s390x support - Testsuite fixes to allow clean ""make check"" on s390x Caveats: - Resets base cpu to ""z10"" to bring support in sync with the default behaviour of other compilers on the platforms. (Usually upstream supports all older processors; a distribution build may then chose to require a more recent base version.) (Also using zEC12 causes failures in the valgrind tests since valgrind doesn't fully support this CPU yet.) - z13 vector ABI is not yet supported. To ensure compatible code generation the -vector feature is passed to LLVM. Note that this means that even when compiling for z13 no vector instructions will be used. In the future support for the vector ABI should be added (this will require common code support for different ABIs that need different data_layout strings on the same platform). - Two test cases are (temporarily) ignored on s390x to allow passing the test suite. The underlying issues still need to be fixed: * debuginfo/simd.rs fails because of incorrect debug information. This seems to be a LLVM bug (also seen with C code). * run-pass/union/union-basic.rs simply seems to be incorrect for all big-endian platforms. Signed-off-by: Ulrich Weigand ",THUMBS_UP,2016-09-11T22:18:35Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/36369,MERGED,2016-09-09T21:31:59Z,2016-09-11T22:12:34Z,Add s390x support,uweigand,19b84088d76b8ded63cbaf12991213f4f437e689,26,"Add s390x support This adds support for building the Rust compiler and standard library for s390x-linux allowing a full cross-bootstrap sequence to complete. This includes: - Makefile/configure changes to allow native s390x builds - Full Rust compiler support for the s390x C ABI (only the non-vector ABI is supported at this point) - Port of the standard library to s390x - Update the liblibc submodule to a version including s390x support - Testsuite fixes to allow clean ""make check"" on s390x Caveats: - Resets base cpu to ""z10"" to bring support in sync with the default behaviour of other compilers on the platforms. (Usually upstream supports all older processors; a distribution build may then chose to require a more recent base version.) (Also using zEC12 causes failures in the valgrind tests since valgrind doesn't fully support this CPU yet.) - z13 vector ABI is not yet supported. To ensure compatible code generation the -vector feature is passed to LLVM. Note that this means that even when compiling for z13 no vector instructions will be used. In the future support for the vector ABI should be added (this will require common code support for different ABIs that need different data_layout strings on the same platform). - Two test cases are (temporarily) ignored on s390x to allow passing the test suite. The underlying issues still need to be fixed: * debuginfo/simd.rs fails because of incorrect debug information. This seems to be a LLVM bug (also seen with C code). * run-pass/union/union-basic.rs simply seems to be incorrect for all big-endian platforms. Signed-off-by: Ulrich Weigand ",HOORAY,2016-09-13T12:33:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36371,CLOSED,2016-09-10T02:41:42Z,2016-10-20T01:57:07Z,Include type of missing trait methods in error,estebank,NA,NA,NA,HOORAY,2016-09-10T04:13:06Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T16:37:21Z,durka,NA https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T17:52:43Z,retep998,NA https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T18:07:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T18:14:22Z,alexbool,NA https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T19:55:01Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-10T19:56:10Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-11T14:21:07Z,bluss,NA https://github.com/rust-lang/rust/pull/36384,MERGED,2016-09-10T16:10:04Z,2016-09-15T16:58:32Z,Improve shallow `Clone` deriving,petrochenkov,62cb7510ac6285c93ec691198a92f910582d31a2,7,Improve `Eq` deriving,HOORAY,2016-09-11T14:42:46Z,xilec,NA https://github.com/rust-lang/rust/pull/36396,MERGED,2016-09-11T11:47:37Z,2016-09-14T19:04:37Z,Documentation of what Default does for each type,athulappadan,5798003438469313c0616270b8b285d9afbb4730,1,Doc correction: btree,THUMBS_UP,2016-09-14T21:14:07Z,mhristache,NA https://github.com/rust-lang/rust/pull/36421,MERGED,2016-09-12T18:13:53Z,2016-10-26T07:49:47Z,check target abi support,TimNN,1422ac9a8f5841aee2db18e7819cf9ccda8085d0,6,adapt tests,THUMBS_UP,2016-09-22T19:14:09Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/36424,MERGED,2016-09-12T20:17:49Z,2016-09-16T21:15:21Z,Tweak std::marker docs,kmcallister,b735c1bc7891a5a0176e544aa50c47b4d67f52b4,1,Tweak std::marker docs Fixes #29361.,THUMBS_UP,2016-09-12T21:36:11Z,durka,NA https://github.com/rust-lang/rust/pull/36424,MERGED,2016-09-12T20:17:49Z,2016-09-16T21:15:21Z,Tweak std::marker docs,kmcallister,b735c1bc7891a5a0176e544aa50c47b4d67f52b4,1,Tweak std::marker docs Fixes #29361.,THUMBS_UP,2016-09-12T23:11:38Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36424,MERGED,2016-09-12T20:17:49Z,2016-09-16T21:15:21Z,Tweak std::marker docs,kmcallister,b735c1bc7891a5a0176e544aa50c47b4d67f52b4,1,Tweak std::marker docs Fixes #29361.,HEART,2016-09-13T19:12:38Z,durka,NA https://github.com/rust-lang/rust/pull/36439,MERGED,2016-09-13T04:47:59Z,2016-09-16T03:49:05Z,rustbuild: Fix dependency tracking with new Cargo,alexcrichton,194a91b0ce12d85a6a7ae1db20b3f4aa8408b80d,2,rustbuild: Fix dependency tracking with new Cargo The recent Cargo update changed filenames which broke a lot of incremental rustbuild builds. What it thought were the output files were indeed no longer the output files! (wreaking havoc). This commit updates this to stop guessing filenames of Cargo and just manage stamp files instead.,HOORAY,2016-09-16T15:53:46Z,jntrnr,NA https://github.com/rust-lang/rust/pull/36459,MERGED,2016-09-13T20:43:13Z,2016-09-15T16:58:36Z,invoke drop glue with a ptr to (data meta),nikomatsakis,693676da4f65a14fbae2c44cd4e2a94ba0ccf6d5,1,add missing test,HEART,2016-09-13T23:24:20Z,brson,NA https://github.com/rust-lang/rust/pull/36459,MERGED,2016-09-13T20:43:13Z,2016-09-15T16:58:36Z,invoke drop glue with a ptr to (data meta),nikomatsakis,693676da4f65a14fbae2c44cd4e2a94ba0ccf6d5,1,add missing test,HEART,2016-09-14T15:55:23Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/36460,MERGED,2016-09-13T20:57:18Z,2016-09-29T10:48:06Z,map crate numbers between compilations,mikhail-m1,20c10913ffd57ceda12f5ed3980c5170686bd52c,757,Merge branch 'master' into 35123-map3,HOORAY,2016-09-13T21:05:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/36460,MERGED,2016-09-13T20:57:18Z,2016-09-29T10:48:06Z,map crate numbers between compilations,mikhail-m1,20c10913ffd57ceda12f5ed3980c5170686bd52c,757,Merge branch 'master' into 35123-map3,HOORAY,2016-09-14T06:09:12Z,mikhail-m1,NA https://github.com/rust-lang/rust/pull/36476,CLOSED,2016-09-14T14:52:40Z,2016-11-09T10:43:45Z,Check for uninhabited types in sub-patterns (#12609),canndrew,NA,NA,NA,HOORAY,2016-09-16T04:38:43Z,tikue,NA https://github.com/rust-lang/rust/pull/36482,MERGED,2016-09-14T23:03:44Z,2016-09-17T09:51:20Z,Avoid loading and parsing unconfigured non-inline modules.,jseyfried,6f0ee455023fe24cade7a8ebb0af31c2ac98548e,1,Add regression test.,HEART,2016-09-14T23:09:48Z,durka,NA https://github.com/rust-lang/rust/pull/36482,MERGED,2016-09-14T23:03:44Z,2016-09-17T09:51:20Z,Avoid loading and parsing unconfigured non-inline modules.,jseyfried,6f0ee455023fe24cade7a8ebb0af31c2ac98548e,1,Add regression test.,HEART,2016-09-14T23:52:46Z,retep998,NA https://github.com/rust-lang/rust/pull/36482,MERGED,2016-09-14T23:03:44Z,2016-09-17T09:51:20Z,Avoid loading and parsing unconfigured non-inline modules.,jseyfried,6f0ee455023fe24cade7a8ebb0af31c2ac98548e,1,Add regression test.,HEART,2016-09-15T05:35:53Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36482,MERGED,2016-09-14T23:03:44Z,2016-09-17T09:51:20Z,Avoid loading and parsing unconfigured non-inline modules.,jseyfried,6f0ee455023fe24cade7a8ebb0af31c2ac98548e,1,Add regression test.,HEART,2016-09-15T16:42:23Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/36482,MERGED,2016-09-14T23:03:44Z,2016-09-17T09:51:20Z,Avoid loading and parsing unconfigured non-inline modules.,jseyfried,6f0ee455023fe24cade7a8ebb0af31c2ac98548e,1,Add regression test.,HEART,2016-09-16T14:02:07Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/36508,MERGED,2016-09-15T22:31:02Z,2016-09-17T23:38:17Z,Up the LLVM,nagisa,d104e5bfb70f7ee3fc3e7d30e6021ae804ce87e5,3,Up the LLVM Fixes #36474,THUMBS_UP,2016-09-16T19:08:27Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36508,MERGED,2016-09-15T22:31:02Z,2016-09-17T23:38:17Z,Up the LLVM,nagisa,d104e5bfb70f7ee3fc3e7d30e6021ae804ce87e5,3,Up the LLVM Fixes #36474,THUMBS_UP,2016-09-18T18:45:50Z,bluss,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-16T14:24:39Z,retep998,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-16T16:39:57Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-17T01:07:45Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-19T05:36:32Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-19T20:31:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-20T04:46:16Z,kornholi,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-20T22:05:41Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-23T00:12:22Z,bluss,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-27T19:32:14Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-27T19:42:01Z,arthurprs,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-27T23:57:34Z,cramertj,NA https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-27T23:59:24Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36524,MERGED,2016-09-16T02:32:08Z,2016-09-21T13:05:38Z,trans: Only instantiate #[inline] functions in codegen units referencing them,michaelwoerister,cf976fe2cd92a7a4923e6a0934c8f15333b6589d,2,Adapt codegen-unit test cases to new behaviour,HEART,2016-09-28T23:19:44Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/36527,MERGED,2016-09-16T06:09:28Z,2016-09-18T11:11:59Z,Optimize the parser's last token handling.,nnethercote,8075d546069e9fc850beb846747c43e9ee55e175,1,Optimize the parser's last token handling. The parser currently makes a heap copy of the last token in four cases: identifiers paths doc comments and commas. The identifier and interpolation cases are unused and for doc comments and commas we only need to record their presence not their value. This commit consolidates the last token handling and avoids the unnecessary copies by replacing `last_token` `last_token_eof` and `last_token_interpolated` with a new field `last_token_kind`. This simplifies the parser slightly and speeds up parsing on some files by 3--4%.,THUMBS_UP,2016-09-18T02:41:39Z,jseyfried,NA https://github.com/rust-lang/rust/pull/36527,MERGED,2016-09-16T06:09:28Z,2016-09-18T11:11:59Z,Optimize the parser's last token handling.,nnethercote,8075d546069e9fc850beb846747c43e9ee55e175,1,Optimize the parser's last token handling. The parser currently makes a heap copy of the last token in four cases: identifiers paths doc comments and commas. The identifier and interpolation cases are unused and for doc comments and commas we only need to record their presence not their value. This commit consolidates the last token handling and avoids the unnecessary copies by replacing `last_token` `last_token_eof` and `last_token_interpolated` with a new field `last_token_kind`. This simplifies the parser slightly and speeds up parsing on some files by 3--4%.,THUMBS_UP,2016-09-20T18:01:23Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/36527,MERGED,2016-09-16T06:09:28Z,2016-09-18T11:11:59Z,Optimize the parser's last token handling.,nnethercote,8075d546069e9fc850beb846747c43e9ee55e175,1,Optimize the parser's last token handling. The parser currently makes a heap copy of the last token in four cases: identifiers paths doc comments and commas. The identifier and interpolation cases are unused and for doc comments and commas we only need to record their presence not their value. This commit consolidates the last token handling and avoids the unnecessary copies by replacing `last_token` `last_token_eof` and `last_token_interpolated` with a new field `last_token_kind`. This simplifies the parser slightly and speeds up parsing on some files by 3--4%.,THUMBS_UP,2016-09-20T22:13:48Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36545,MERGED,2016-09-16T21:56:48Z,2016-09-19T07:23:57Z,Remove stray println! when invoking error E0316,Cobrand,d8b2cfeae6fbc1a9d7e86c9809f27ad1200903cb,1,Remove stray println! when invoking error E0316,THUMBS_UP,2016-09-16T23:35:03Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36545,MERGED,2016-09-16T21:56:48Z,2016-09-19T07:23:57Z,Remove stray println! when invoking error E0316,Cobrand,d8b2cfeae6fbc1a9d7e86c9809f27ad1200903cb,1,Remove stray println! when invoking error E0316,THUMBS_UP,2016-09-17T06:56:53Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/36545,MERGED,2016-09-16T21:56:48Z,2016-09-19T07:23:57Z,Remove stray println! when invoking error E0316,Cobrand,d8b2cfeae6fbc1a9d7e86c9809f27ad1200903cb,1,Remove stray println! when invoking error E0316,LAUGH,2016-09-17T16:31:29Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T08:32:23Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T11:58:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T12:32:57Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T17:33:17Z,bluss,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T19:05:24Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-17T21:23:07Z,jseyfried,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-19T12:11:51Z,est31,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-19T14:03:35Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HEART,2016-09-19T14:03:46Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/36551,MERGED,2016-09-17T07:58:09Z,2016-09-22T05:40:58Z,Refactor away RBML from rustc_metadata. ,eddyb,4ac30013c3402d9349f83888a9d0903f0a68746e,4,rustc_trans: don't do on-demand drop glue instantiation.,HOORAY,2016-09-28T00:08:16Z,cramertj,NA https://github.com/rust-lang/rust/pull/36571,MERGED,2016-09-18T23:09:40Z,2016-09-22T23:33:50Z,Tweak std::rc docs,kmcallister,c316ae56e65169edacda1faace93a09cdbaa3d7f,1,Tweak std::rc docs Fixes #29372.,HEART,2016-09-18T23:44:03Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36571,MERGED,2016-09-18T23:09:40Z,2016-09-22T23:33:50Z,Tweak std::rc docs,kmcallister,c316ae56e65169edacda1faace93a09cdbaa3d7f,1,Tweak std::rc docs Fixes #29372.,THUMBS_UP,2016-09-21T18:36:54Z,cbreeden,NA https://github.com/rust-lang/rust/pull/36578,MERGED,2016-09-19T12:09:45Z,2016-09-24T04:15:02Z,Replace 'e.g.' by 'i.e.',GuillaumeGomez,313fb8fbf2bd4e99d36286474196599c5a5e6eaf,1,Replace 'e.g.' by 'i.e.',THUMBS_UP,2016-09-19T12:16:29Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,THUMBS_UP,2016-09-20T07:38:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-09-20T09:25:58Z,bluss,NA https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-09-20T14:23:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-09-20T20:46:43Z,brson,NA https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-09-21T21:04:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,THUMBS_UP,2016-09-21T21:08:29Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,THUMBS_UP,2016-10-14T06:09:51Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-10-14T06:09:52Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-10-14T13:36:09Z,crinklywrappr,crinklywrappr@pm.me https://github.com/rust-lang/rust/pull/36592,MERGED,2016-09-20T03:16:58Z,2016-09-22T13:29:32Z,Lazily allocate TypedArena's first chunk,nnethercote,80a44779f7a211e075da9ed0ff2763afa00f43dc,1,Lazily allocate TypedArena's first chunk. Currently `TypedArena` allocates its first chunk which is usually 4096 bytes as soon as it is created. If no allocations are ever made from the arena then this allocation (and the corresponding deallocation) is wasted effort. This commit changes `TypedArena` so it doesn't allocate the first chunk until the first allocation is made. This change speeds up rustc by a non-trivial amount because rustc uses `TypedArena` heavily: compilation speed (producing debug builds) on several of the rustc-benchmarks increases by 1.02--1.06x. The change should never cause a slow-down because the hot `alloc` function is unchanged. It does increase the size of `TypedArena` by one `usize` field however. The commit also fixes some out-of-date comments.,HEART,2016-11-13T05:21:48Z,hayd,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T04:03:38Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T06:27:53Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T07:34:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T08:19:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T10:32:13Z,bluss,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-20T13:26:58Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-24T00:24:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-09-26T02:02:17Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2016-10-03T16:57:27Z,mcarton,NA https://github.com/rust-lang/rust/pull/36593,CLOSED,2016-09-20T04:02:54Z,2017-01-17T16:50:05Z,[MIR] Initial implementation of inlining,Aatch,NA,NA,NA,HOORAY,2017-01-26T10:08:22Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36595,MERGED,2016-09-20T07:40:53Z,2016-11-01T07:44:54Z,hashmap: Store hashes as usize internally,bluss,13a1f21371efa5be7a7d8b26bde19fb7da5bd967,1,hashmap: Store hashes as usize internally We can't use more than usize's bits of a hash to select a bucket anyway so we only need to store that part in the table. This should be an improvement for the size of the data structure on 32-bit platforms. Smaller data means better cache utilization and hopefully better performance.,THUMBS_UP,2016-11-01T13:27:52Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36618,MERGED,2016-09-21T09:37:05Z,2016-09-22T16:50:52Z,macros: allow attribute invocations at the crate root,jseyfried,f4fa62f4f2b984ca97e7d68dbf8c2f3cf88866c5,1,Add regression test.,THUMBS_UP,2016-09-22T17:46:44Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36620,MERGED,2016-09-21T12:28:59Z,2016-09-21T17:11:58Z,Beta backports,pnkfelix,7504d2a4a2086bddefc74349b7111a20d8d20d9c,4,Merge pull request #36620 from pnkfelix/beta-next Beta backports,HEART,2016-09-21T17:11:32Z,brson,NA https://github.com/rust-lang/rust/pull/36633,MERGED,2016-09-21T19:26:49Z,2016-09-21T19:27:02Z,[beta] Add changelog for 1.12,brson,c6f7c2a72143a76547b21d187f0a8e958ff3c369,1,Merge pull request #36633 from brson/beta-next [beta] Add changelog for 1.12,HOORAY,2016-09-21T20:02:36Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36662,MERGED,2016-09-22T23:07:42Z,2016-09-27T11:05:29Z,parser: support paths in bang macro invocations (e.g. `path::to::macro!()`),jseyfried,34f4ad1b717feb604bf5818d726d3472d6aca48d,1,Add regression test.,HOORAY,2016-09-26T04:00:10Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/36662,MERGED,2016-09-22T23:07:42Z,2016-09-27T11:05:29Z,parser: support paths in bang macro invocations (e.g. `path::to::macro!()`),jseyfried,34f4ad1b717feb604bf5818d726d3472d6aca48d,1,Add regression test.,HOORAY,2017-03-09T06:49:09Z,tikue,NA https://github.com/rust-lang/rust/pull/36671,CLOSED,2016-09-23T15:06:58Z,2016-10-03T23:54:03Z,Add OsStringExt::from_wide_ptr for windows,bozaro,NA,NA,NA,THUMBS_UP,2016-09-23T19:13:50Z,retep998,NA https://github.com/rust-lang/rust/pull/36692,MERGED,2016-09-24T09:43:02Z,2016-10-14T18:58:48Z,Cache conscious hashmap table,arthurprs,c435821d164829a0d5f324c1b0366c4b1724849d,1,Cache conscious hashmap table,HOORAY,2016-10-19T18:00:50Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36692,MERGED,2016-09-24T09:43:02Z,2016-10-14T18:58:48Z,Cache conscious hashmap table,arthurprs,c435821d164829a0d5f324c1b0366c4b1724849d,1,Cache conscious hashmap table,HOORAY,2017-01-09T12:55:33Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/36695,MERGED,2016-09-24T15:54:04Z,2016-10-27T04:47:28Z,Refactor match checking to use HAIR,arielb1,3f9ebb48cf462eb72536b726e6f61bdeafa7e5ce,1,add back test for issue #6804,HOORAY,2016-10-27T08:35:46Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/36721,MERGED,2016-09-25T17:10:46Z,2016-09-27T11:05:31Z,reject macros with empty repetitions,TimNN,51ea0504578c00b6754b666032c19366a197a480,2,reject macros with empty repetitions,THUMBS_UP,2016-09-25T19:15:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/36721,MERGED,2016-09-25T17:10:46Z,2016-09-27T11:05:31Z,reject macros with empty repetitions,TimNN,51ea0504578c00b6754b666032c19366a197a480,2,reject macros with empty repetitions,THUMBS_UP,2016-09-25T21:15:55Z,bluss,NA https://github.com/rust-lang/rust/pull/36721,MERGED,2016-09-25T17:10:46Z,2016-09-27T11:05:31Z,reject macros with empty repetitions,TimNN,51ea0504578c00b6754b666032c19366a197a480,2,reject macros with empty repetitions,HOORAY,2016-09-27T11:12:10Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/36721,MERGED,2016-09-25T17:10:46Z,2016-09-27T11:05:31Z,reject macros with empty repetitions,TimNN,51ea0504578c00b6754b666032c19366a197a480,2,reject macros with empty repetitions,THUMBS_UP,2017-02-10T06:14:48Z,jseyfried,NA https://github.com/rust-lang/rust/pull/36727,MERGED,2016-09-25T22:00:27Z,2016-09-27T11:05:32Z,Haiku: Initial work at OS support,kallisti5,7c34d9c14492b54eba84b474087980e675eed521,1,Haiku: Use common thread set_name stub,HOORAY,2016-09-26T18:05:47Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36727,MERGED,2016-09-25T22:00:27Z,2016-09-27T11:05:32Z,Haiku: Initial work at OS support,kallisti5,7c34d9c14492b54eba84b474087980e675eed521,1,Haiku: Use common thread set_name stub,HOORAY,2017-01-15T09:14:14Z,mackwic,mackwic@gmail.com https://github.com/rust-lang/rust/pull/36730,MERGED,2016-09-26T00:24:32Z,2016-09-26T11:38:29Z,"Forbid user-defined macros named ""macro_rules""",jseyfried,77958d56bccd11b490afac356e6d9c11f07632bb,3,"Forbid user-defined macros named ""macro_rules"".",LAUGH,2016-09-26T01:15:09Z,retep998,NA https://github.com/rust-lang/rust/pull/36730,MERGED,2016-09-26T00:24:32Z,2016-09-26T11:38:29Z,"Forbid user-defined macros named ""macro_rules""",jseyfried,77958d56bccd11b490afac356e6d9c11f07632bb,3,"Forbid user-defined macros named ""macro_rules"".",LAUGH,2016-09-26T02:38:46Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/36730,MERGED,2016-09-26T00:24:32Z,2016-09-26T11:38:29Z,"Forbid user-defined macros named ""macro_rules""",jseyfried,77958d56bccd11b490afac356e6d9c11f07632bb,3,"Forbid user-defined macros named ""macro_rules"".",LAUGH,2016-09-26T07:59:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T03:18:55Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T06:10:44Z,bluss,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T08:47:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T09:02:00Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T10:32:01Z,arthurprs,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T13:20:49Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-09-26T18:07:36Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-10-04T23:19:24Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,THUMBS_UP,2016-10-05T03:03:04Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-10-05T20:06:47Z,WaDelma,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-10-13T19:33:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,THUMBS_UP,2016-10-14T06:14:33Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2016-10-14T13:37:08Z,crinklywrappr,crinklywrappr@pm.me https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,THUMBS_UP,2016-11-20T22:32:32Z,pczarn,NA https://github.com/rust-lang/rust/pull/36734,MERGED,2016-09-26T03:06:59Z,2016-09-26T14:53:36Z,Don't allocate during default HashSet creation.,nnethercote,4eb069c9811bc25d6ef9413de6058e5f14707816,2,Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap` by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.,HOORAY,2020-09-08T05:39:44Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/36743,MERGED,2016-09-26T16:30:25Z,2016-10-14T09:23:22Z,Add Vec::dedup_by and Vec::dedup_by_key,SimonSapin,401f1c45db5343dc0189b4f89d4160bba24facfb,1,Merge two `impl Vec` blocks. The show up separately in rustdoc. This is a separate commit to keep the previous one’s diff shorter.,HEART,2016-09-26T18:11:52Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/36743,MERGED,2016-09-26T16:30:25Z,2016-10-14T09:23:22Z,Add Vec::dedup_by and Vec::dedup_by_key,SimonSapin,401f1c45db5343dc0189b4f89d4160bba24facfb,1,Merge two `impl Vec` blocks. The show up separately in rustdoc. This is a separate commit to keep the previous one’s diff shorter.,HEART,2016-11-07T04:58:09Z,maxbeutel,NA https://github.com/rust-lang/rust/pull/36743,MERGED,2016-09-26T16:30:25Z,2016-10-14T09:23:22Z,Add Vec::dedup_by and Vec::dedup_by_key,SimonSapin,401f1c45db5343dc0189b4f89d4160bba24facfb,1,Merge two `impl Vec` blocks. The show up separately in rustdoc. This is a separate commit to keep the previous one’s diff shorter.,HEART,2017-02-09T19:03:23Z,fluxxu,NA https://github.com/rust-lang/rust/pull/36743,MERGED,2016-09-26T16:30:25Z,2016-10-14T09:23:22Z,Add Vec::dedup_by and Vec::dedup_by_key,SimonSapin,401f1c45db5343dc0189b4f89d4160bba24facfb,1,Merge two `impl Vec` blocks. The show up separately in rustdoc. This is a separate commit to keep the previous one’s diff shorter.,HEART,2017-02-14T14:24:43Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/36743,MERGED,2016-09-26T16:30:25Z,2016-10-14T09:23:22Z,Add Vec::dedup_by and Vec::dedup_by_key,SimonSapin,401f1c45db5343dc0189b4f89d4160bba24facfb,1,Merge two `impl Vec` blocks. The show up separately in rustdoc. This is a separate commit to keep the previous one’s diff shorter.,HEART,2020-07-07T21:15:45Z,lqd,NA https://github.com/rust-lang/rust/pull/36762,MERGED,2016-09-27T00:17:48Z,2016-10-12T21:42:16Z,Add two functions to check type of SockAddr,achanda,d9e64301856354cc22aaf5b92bfc6ac8b1beb50e,1,Add two functions to check type of SockAddr These can be used to determine the type of the underlying IP address,HOORAY,2016-09-28T13:01:40Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/36782,MERGED,2016-09-27T19:41:25Z,2016-09-29T01:31:18Z,rustc: Tweak expansion order of custom derive,alexcrichton,e5e7021ca5b67c17fa116a971c3204bd147a1f0d,4,rustc: Tweak expansion order of custom derive This commit alters the expansion order of custom macros-1.1 style `#[derive]` modes. Instead of left-to-right the expansion now happens in three categories each of which is internally left-to-right: * Old-style custom derive (`#[derive_Foo]`) is expanded * New-style custom derive (macros 1.1) is expanded * Built in derive modes are expanded This gives built in derive modes maximal knowledge about the struct that's being expanded and also avoids pesky issues like exposing `#[structural_match]` or `#[rustc_copy_clone_marker]`. cc #35900,HOORAY,2016-09-28T17:29:13Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/36787,MERGED,2016-09-27T20:19:04Z,2016-09-29T10:48:12Z,Avoid re-export errors in the generated test harness,jseyfried,28393be8df89dec9f78ec8bcbd73e399c6021098,1,Add regression test.,THUMBS_UP,2016-09-28T22:43:34Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/36794,MERGED,2016-09-28T02:38:30Z,2016-09-29T10:48:13Z,add a panic-strategy field to the target specification,japaric,8a46e78e64dee2c85ba097081ddff027322e93d3,1,fix librustc test: panic is Option now,THUMBS_UP,2016-09-28T18:34:55Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/36798,MERGED,2016-09-28T11:58:38Z,2016-10-04T15:29:48Z,"Improve error message and snippet for ""did you mean `x`""",gavinb,99aae9b834604788b58da8eac9156cc3715426e1,22,"Improve error message and snippet for ""did you mean `x`"" - Fixes #36164 - Part of #35233 - handles unknown fields - uses UI-style tests - update all related tests (cfail ui incremental)",THUMBS_UP,2016-10-14T17:35:01Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36807,MERGED,2016-09-28T19:01:23Z,2016-10-03T04:51:16Z,Restrict where in the tree platform-specific cfgs may be mentioned,brson,4d76ac84922bec9ea790c1394f6959ad399d7aa1,11,Move platform-specific arg handling to sys::args,HOORAY,2016-10-17T21:37:04Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/36822,MERGED,2016-09-29T04:09:23Z,2016-09-30T14:35:15Z,Resolve the callee type in check_call before autoderef,Aatch,ec2e05194f02fea51ad19de3498b9f6818166f1c,2,Resolve the callee type in check_call before autoderef If the callee type is an associated type then it needs to be normalized before trying to deref it. This matches the behaviour of `check_method_call` for autoderef behaviour in calls. Fixes #36786,HEART,2016-09-30T16:59:18Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/36825,MERGED,2016-09-29T09:38:40Z,2016-10-11T11:27:02Z,add println!() macro with out any arguments,sbwtw,7d6227a9b34670fe235d6c35416e8ab643c1341c,3,add println!() macro with out any arguments,THUMBS_UP,2016-10-02T20:46:54Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/36825,MERGED,2016-09-29T09:38:40Z,2016-10-11T11:27:02Z,add println!() macro with out any arguments,sbwtw,7d6227a9b34670fe235d6c35416e8ab643c1341c,3,add println!() macro with out any arguments,THUMBS_UP,2016-12-22T20:45:34Z,mmun,im.mmun@gmail.com https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-09-30T00:42:38Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-09-30T00:52:34Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-09-30T02:43:41Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-09-30T09:35:29Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-10-04T05:09:47Z,jseyfried,NA https://github.com/rust-lang/rust/pull/36843,MERGED,2016-09-29T22:51:34Z,2016-11-08T14:44:50Z,Stabilize `..` in tuple (struct) patterns,petrochenkov,74bb5945635b5aaacd238632932baaa294694ce3,33,Stabilize `..` in tuple (struct) patterns,THUMBS_UP,2016-11-15T21:35:32Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/36874,MERGED,2016-09-30T21:16:14Z,2016-10-04T18:53:13Z,add Thumbs to the compiler,japaric,6136069609f40e2436d810d4a35433d42266fadc,58,change max_atomic_width type from u64 to Option to better express the idea that omitting this field defaults this value to target_pointer_width,THUMBS_UP,2017-02-03T19:02:28Z,voteblake,NA https://github.com/rust-lang/rust/pull/36894,MERGED,2016-10-01T14:08:52Z,2016-10-27T14:19:22Z,Make sufficiently old or low-impact compatibility lints deny-by-default,petrochenkov,2a852110400c3eccb57edfbd2047fd53e7de9947,9,Make sufficiently old or low-impact compatibility lints deny-by-default,HEART,2016-10-17T18:31:42Z,brson,NA https://github.com/rust-lang/rust/pull/36903,MERGED,2016-10-02T01:22:22Z,2016-10-04T15:29:50Z,Minor librustdoc cleanup and refactoring.,frewsxcv,35d214afe6af62d1532135875e73b3218b85fbf0,4,Remove redundant 'Variant' in variant names stop reexporting.,HEART,2016-10-02T09:19:02Z,bluss,NA https://github.com/rust-lang/rust/pull/36903,MERGED,2016-10-02T01:22:22Z,2016-10-04T15:29:50Z,Minor librustdoc cleanup and refactoring.,frewsxcv,35d214afe6af62d1532135875e73b3218b85fbf0,4,Remove redundant 'Variant' in variant names stop reexporting.,HEART,2016-10-02T10:03:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/36903,MERGED,2016-10-02T01:22:22Z,2016-10-04T15:29:50Z,Minor librustdoc cleanup and refactoring.,frewsxcv,35d214afe6af62d1532135875e73b3218b85fbf0,4,Remove redundant 'Variant' in variant names stop reexporting.,HEART,2016-10-02T21:20:19Z,jseyfried,NA https://github.com/rust-lang/rust/pull/36917,MERGED,2016-10-03T01:18:34Z,2016-10-04T15:29:50Z,Speed up `plug_leaks`,nnethercote,3779971dbb397ff8b1668c379812b903a6a907ec,3,Optimize plug_leaks some more. This commit avoids the `resolve_type_vars_if_possible` call in `plug_leaks` when `skol_map` is empty which is the common case. It also changes the signature of `plug_leaks` slightly to avoid the need for a `clone` of `value`. These changes give speed-ups of up a few percent on some of the rustc-benchmarks.,HEART,2016-10-04T01:42:09Z,brson,NA https://github.com/rust-lang/rust/pull/36917,MERGED,2016-10-03T01:18:34Z,2016-10-04T15:29:50Z,Speed up `plug_leaks`,nnethercote,3779971dbb397ff8b1668c379812b903a6a907ec,3,Optimize plug_leaks some more. This commit avoids the `resolve_type_vars_if_possible` call in `plug_leaks` when `skol_map` is empty which is the common case. It also changes the signature of `plug_leaks` slightly to avoid the need for a `clone` of `value`. These changes give speed-ups of up a few percent on some of the rustc-benchmarks.,HEART,2016-10-14T06:12:15Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/36931,CLOSED,2016-10-03T16:13:31Z,2016-10-17T18:31:12Z,add a fastpath to match_impl for the non-HRTB case,arielb1,NA,NA,NA,HOORAY,2016-10-03T23:37:57Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/36931,CLOSED,2016-10-03T16:13:31Z,2016-10-17T18:31:12Z,add a fastpath to match_impl for the non-HRTB case,arielb1,NA,NA,NA,HOORAY,2016-10-04T13:05:30Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36962,MERGED,2016-10-04T16:27:53Z,2016-10-06T23:31:36Z,Emit more assumptions in trans,arielb1,45fe3a1a2ab2671bb9f726941eda6c2899eb6dff,3,emit an assume that cast-from enums are in range Fixes #36955.,HEART,2016-10-04T18:22:02Z,bluss,NA https://github.com/rust-lang/rust/pull/36992,CLOSED,2016-10-06T03:36:12Z,2016-11-10T20:58:03Z,move to the WIP Rust port of compiler-rt,japaric,NA,NA,NA,HOORAY,2016-10-07T13:58:29Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/36992,CLOSED,2016-10-06T03:36:12Z,2016-11-10T20:58:03Z,move to the WIP Rust port of compiler-rt,japaric,NA,NA,NA,HOORAY,2016-11-03T03:15:15Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/36993,MERGED,2016-10-06T03:59:27Z,2016-11-03T05:58:03Z,Optimize ObligationForest's NodeState handling.,nnethercote,7b33f7e3e77794e8a44d07d97bc7b62ab9f79981,1,Optimize ObligationForest's NodeState handling. This commit partially inlines two functions `find_cycles_from_node` and `mark_as_waiting_from` at two call sites in order to avoid function unnecessary function calls on hot paths. It also fully inlines and removes `is_popped`. These changes speeds up rustc-benchmarks/inflate-0.1.0 by about 2% when doing debug builds with a stage1 compiler.,THUMBS_UP,2016-11-08T04:35:53Z,brson,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,THUMBS_UP,2016-10-06T08:43:11Z,msjyoo,michael@yoo.id.au https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-06T18:00:26Z,durka,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-07T18:59:01Z,sfackler,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,THUMBS_UP,2016-10-07T22:15:10Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-07T22:15:11Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-07T22:22:26Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-09T06:09:09Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-10T16:38:06Z,compressed,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-18T18:34:49Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-19T01:43:12Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-19T05:03:32Z,bstrie,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-19T07:12:42Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2016-10-19T09:05:43Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,THUMBS_UP,2016-12-04T15:42:45Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,THUMBS_UP,2016-12-09T15:00:18Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/36995,MERGED,2016-10-06T05:55:18Z,2016-10-13T01:32:50Z,stabilise ? attributes on stmts deprecate Reflect,nrc,79b5177378097ee39e595517ca76132b3a3dc0eb,1,Review changes,HOORAY,2018-05-25T00:32:30Z,hcpl,NA https://github.com/rust-lang/rust/pull/37003,MERGED,2016-10-06T16:10:33Z,2016-10-07T14:58:37Z,Remove underline when run button hovered,GuillaumeGomez,4b402dbe690dd00f567542ca9e41042826a168b5,1,Remove underline when run button hovered,THUMBS_UP,2016-10-06T16:16:48Z,durka,NA https://github.com/rust-lang/rust/pull/37003,MERGED,2016-10-06T16:10:33Z,2016-10-07T14:58:37Z,Remove underline when run button hovered,GuillaumeGomez,4b402dbe690dd00f567542ca9e41042826a168b5,1,Remove underline when run button hovered,THUMBS_UP,2016-10-06T17:18:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,HOORAY,2016-10-08T00:33:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,HOORAY,2016-10-08T02:51:51Z,durka,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-10-08T06:26:08Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-10-08T13:11:36Z,MoSal,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,HOORAY,2016-10-08T13:30:35Z,mcarton,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-10-08T19:08:17Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-10-14T04:49:59Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-10-21T21:14:43Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,HOORAY,2016-10-21T21:14:44Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,HOORAY,2016-11-03T06:39:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-11-03T17:17:39Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2016-11-05T19:41:53Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/37035,MERGED,2016-10-08T00:32:52Z,2016-10-28T05:02:36Z,Support `Self` in struct expressions and patterns,petrochenkov,8a38928b44e26d4d7b9bdacb207a85878058cac8,8,Address comments + Fix rebase,THUMBS_UP,2017-03-17T03:14:02Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/37041,MERGED,2016-10-08T14:26:31Z,2016-10-09T02:35:59Z,Use less `size_t` casts in libstd since it's now defined as `usize`,tbu-,717d2ddca7a11088716193453378b65c04995021,8,Use less `size_t` casts in libstd since it's now defined as `usize`,THUMBS_UP,2016-10-08T15:25:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37050,MERGED,2016-10-09T04:17:33Z,2016-10-13T01:32:52Z,librustdoc refactoring and cleanup.,frewsxcv,e4f066fe8b189d1459580d41b792347ba5c371ef,1,Remove unnecessary `pub` function classifier.,THUMBS_UP,2016-10-09T09:15:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37054,MERGED,2016-10-09T10:07:49Z,2016-11-02T15:44:40Z,Add `then` and `then_with` for ordering.,rednum,655effedf25e2039d283b839429bf2f42b7012a4,1501,"Merge branch 'master' of https://github.com/rust-lang/rust Conflicts: src/libcoretest/lib.rs",HOORAY,2016-10-09T16:55:00Z,killercup,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-10-10T03:26:57Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-10-10T06:57:07Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-10-10T10:47:52Z,mcarton,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",LAUGH,2016-10-11T06:19:29Z,durka,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-10-11T06:25:09Z,sfackler,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-11-03T14:36:50Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2016-11-13T13:35:59Z,bluss,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-01-03T21:19:10Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-01-10T09:48:12Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-01-10T09:50:18Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-01-31T14:08:46Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",LAUGH,2017-01-31T17:24:41Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-01-31T18:31:19Z,tikue,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-02-01T03:14:08Z,jminer,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-02-02T15:39:18Z,causal-agent,june@causal.agency https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",LAUGH,2017-02-17T06:38:43Z,kennytm,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",THUMBS_UP,2017-03-06T17:03:47Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",LAUGH,2017-03-07T14:02:10Z,lawliet89,NA https://github.com/rust-lang/rust/pull/37057,MERGED,2016-10-09T17:36:58Z,2017-01-28T00:40:31Z,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions",brson,a2735c02493d816835a19249dd258e0c678530d0,7,"rustc: Remove all ""consider using an explicit lifetime parameter"" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.",LAUGH,2017-03-14T08:58:30Z,isurakka,iiro.surakka@gmail.com https://github.com/rust-lang/rust/pull/37059,MERGED,2016-10-09T18:09:59Z,2016-11-02T06:50:07Z,Remove TypeOrigin::RangeExpression,jfirebaugh,16a979c106caddf665f74122d807086129e93bed,1,Remove TypeOrigin::RangeExpression This variant became unused in #30884.,THUMBS_UP,2016-10-09T18:30:02Z,durka,NA https://github.com/rust-lang/rust/pull/37059,MERGED,2016-10-09T18:09:59Z,2016-11-02T06:50:07Z,Remove TypeOrigin::RangeExpression,jfirebaugh,16a979c106caddf665f74122d807086129e93bed,1,Remove TypeOrigin::RangeExpression This variant became unused in #30884.,THUMBS_UP,2016-10-09T18:45:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37064,MERGED,2016-10-09T23:19:47Z,2016-10-13T01:32:53Z,Avoid allocations in `Decoder::read_str`.,nnethercote,b043e11de2eb2c60f7bfec5e15960f537b229e20,6,Avoid allocations in `Decoder::read_str`. `opaque::Decoder::read_str` is very hot within `rustc` due to its use in the reading of crate metadata and it currently returns a `String`. This commit changes it to instead return a `Cow` which avoids a heap allocation. This change reduces the number of calls to `malloc` by almost 10% in some benchmarks. This is a [breaking-change] to libserialize.,THUMBS_UP,2016-10-14T06:11:41Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/37064,MERGED,2016-10-09T23:19:47Z,2016-10-13T01:32:53Z,Avoid allocations in `Decoder::read_str`.,nnethercote,b043e11de2eb2c60f7bfec5e15960f537b229e20,6,Avoid allocations in `Decoder::read_str`. `opaque::Decoder::read_str` is very hot within `rustc` due to its use in the reading of crate metadata and it currently returns a `String`. This commit changes it to instead return a `Cow` which avoids a heap allocation. This change reduces the number of calls to `malloc` by almost 10% in some benchmarks. This is a [breaking-change] to libserialize.,THUMBS_UP,2016-10-14T19:04:06Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37094,MERGED,2016-10-11T17:52:02Z,2016-10-15T13:09:01Z,Specialize Vec::extend to Vec::extend_from_slice,fhartwig,63ee8d0bbc9911ee121ed4af4f7e81cbd600d8b1,1,Specialize Vec::extend to Vec::extend_from_slice,THUMBS_UP,2016-10-11T18:36:59Z,mcarton,NA https://github.com/rust-lang/rust/pull/37098,MERGED,2016-10-11T21:48:53Z,2016-10-16T06:51:59Z,rustdoc: Improve playground run buttons,ollie27,0b2746c8db6fc11965b1b6fd1d8536309a0d98b6,15,rustdoc: Improve playground run buttons The main change is to stop using javascript to generate the URLs and use rustdoc instead. This also adds run buttons to the error index examples.,THUMBS_UP,2016-10-12T02:34:48Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37100,MERGED,2016-10-12T02:22:36Z,2016-10-15T16:32:12Z,Change Substs to type alias for Slice for interning,anp,48b3dd11f59f48819031206ee2b3ab98ceae1550,1,Adding FIXME for noop Substs::params.,HOORAY,2016-10-12T02:38:22Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37111,MERGED,2016-10-12T10:52:45Z,2016-10-26T00:54:19Z,Disallow Unsized Enums,TimNN,db032578a436df5974be8bf9404b26d7661008e3,1,add new test case,THUMBS_UP,2016-10-12T14:55:46Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37112,MERGED,2016-10-12T15:02:01Z,2016-10-17T21:06:53Z,Fix ICE: inject bitcast if types mismatch for invokes/calls/stores,pnkfelix,05626546081394f4ba0c9d916c35e48cc29d2af6,2,Some tests to check that lifetime parametric fn's do not trip up LLVM.,HEART,2016-10-12T17:20:32Z,brson,NA https://github.com/rust-lang/rust/pull/37117,MERGED,2016-10-12T16:53:15Z,2016-10-19T09:53:23Z,`#[may_dangle]` attribute,pnkfelix,10a58ac49b7529e39fc2ad823204853f3538d90b,1,Incorporate review feedback: code formatting fixes expand a comment.,THUMBS_UP,2016-10-25T23:05:38Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/37127,MERGED,2016-10-12T21:02:38Z,2016-11-21T14:08:48Z,Stabilize RFC 1560,jseyfried,649bcd409aed38b20f871e0d215e2c06124a7572,25,Fix fallout in tests.,THUMBS_UP,2016-10-25T06:35:13Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/37127,MERGED,2016-10-12T21:02:38Z,2016-11-21T14:08:48Z,Stabilize RFC 1560,jseyfried,649bcd409aed38b20f871e0d215e2c06124a7572,25,Fix fallout in tests.,HOORAY,2016-11-12T12:25:28Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2016-10-12T23:56:03Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2016-10-13T08:42:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2016-10-14T03:57:53Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2016-11-10T08:30:31Z,ticki,NA https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2020-09-10T07:07:30Z,kacejot,NA https://github.com/rust-lang/rust/pull/37133,CLOSED,2016-10-12T23:41:51Z,2016-11-28T21:53:45Z,"Port libstd to ""no operating system"" target",jethrogb,NA,NA,NA,THUMBS_UP,2020-11-14T00:44:10Z,kevinaboos,NA https://github.com/rust-lang/rust/pull/37152,MERGED,2016-10-13T20:45:18Z,2016-10-16T02:49:19Z,add a per-param-env cache to `impls_bound`,arielb1,a61d85b2fe5ebc25bcc54c7a9e6ce3b98ce00b7c,5,add a per-param-env cache to `impls_bound` There used to be only a global cache which led to uncached calls to trait selection when there were type parameters. I'm running a check that there are no adverse performance effects. Fixes #37106 (drop elaboration times are now ~half of borrow checking so might still be worthy of optimization but not critical).,HEART,2016-10-14T10:31:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37152,MERGED,2016-10-13T20:45:18Z,2016-10-16T02:49:19Z,add a per-param-env cache to `impls_bound`,arielb1,a61d85b2fe5ebc25bcc54c7a9e6ce3b98ce00b7c,5,add a per-param-env cache to `impls_bound` There used to be only a global cache which led to uncached calls to trait selection when there were type parameters. I'm running a check that there are no adverse performance effects. Fixes #37106 (drop elaboration times are now ~half of borrow checking so might still be worthy of optimization but not critical).,HEART,2016-10-14T18:22:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-10-15T15:54:33Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-10-15T17:24:10Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-10-15T17:28:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-10-15T23:41:11Z,bluss,NA https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-10-16T08:38:00Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-11-11T11:34:19Z,sinkuu,NA https://github.com/rust-lang/rust/pull/37190,MERGED,2016-10-15T15:51:45Z,2016-11-12T12:15:36Z,rustdoc: add line breaks to where clauses a la rustfmt,QuietMisdreavus,61cc8700dfcecde9e7de132356f3c32eb01b147e,2,rustdoc: make Method/WhereClause wrappers use usize for indents,THUMBS_UP,2016-11-27T22:57:43Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/37191,MERGED,2016-10-15T18:09:01Z,2016-10-31T22:26:19Z,"introing one-time diagnostics: only emit ""lint level defined here"" once",zackmdavis,ef6a07221d66bff1ef8edac4f9ffc39013abf256,4,deduplicate one-time diagnostics on lint ID as well as span and message Some lint-level attributes (like `bad-style` or more dramatically `warnings`) can affect more than one lint; it seems fairer to point out the attribute once for each distinct lint affected. Also a UI test is added. This remains in the matter of #24690.,HOORAY,2016-10-15T18:22:48Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37191,MERGED,2016-10-15T18:09:01Z,2016-10-31T22:26:19Z,"introing one-time diagnostics: only emit ""lint level defined here"" once",zackmdavis,ef6a07221d66bff1ef8edac4f9ffc39013abf256,4,deduplicate one-time diagnostics on lint ID as well as span and message Some lint-level attributes (like `bad-style` or more dramatically `warnings`) can affect more than one lint; it seems fairer to point out the attribute once for each distinct lint affected. Also a UI test is added. This remains in the matter of #24690.,HOORAY,2016-10-17T08:26:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/37191,MERGED,2016-10-15T18:09:01Z,2016-10-31T22:26:19Z,"introing one-time diagnostics: only emit ""lint level defined here"" once",zackmdavis,ef6a07221d66bff1ef8edac4f9ffc39013abf256,4,deduplicate one-time diagnostics on lint ID as well as span and message Some lint-level attributes (like `bad-style` or more dramatically `warnings`) can affect more than one lint; it seems fairer to point out the attribute once for each distinct lint affected. Also a UI test is added. This remains in the matter of #24690.,HOORAY,2016-11-01T13:48:19Z,sinkuu,NA https://github.com/rust-lang/rust/pull/37192,MERGED,2016-10-15T18:13:03Z,2016-11-08T23:29:53Z,Add `{into from}_raw` to Rc and Arc,cristicbz,651cf58f2e906fa6d333013891adca5074440bea,4,Add `{into from}_raw` to Rc and Arc,THUMBS_UP,2016-10-15T20:21:28Z,est31,NA https://github.com/rust-lang/rust/pull/37192,MERGED,2016-10-15T18:13:03Z,2016-11-08T23:29:53Z,Add `{into from}_raw` to Rc and Arc,cristicbz,651cf58f2e906fa6d333013891adca5074440bea,4,Add `{into from}_raw` to Rc and Arc,THUMBS_UP,2016-10-16T10:24:41Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/37192,MERGED,2016-10-15T18:13:03Z,2016-11-08T23:29:53Z,Add `{into from}_raw` to Rc and Arc,cristicbz,651cf58f2e906fa6d333013891adca5074440bea,4,Add `{into from}_raw` to Rc and Arc,THUMBS_UP,2016-10-29T16:26:20Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/37200,MERGED,2016-10-15T23:00:18Z,2016-10-18T05:28:06Z,include LLVM version in `--version --verbose`,zackmdavis,06123d3afe0fe6e24863f0043d4d2e28bed482da,1,include LLVM version in `--version --verbose` This is in the matter of #28405.,THUMBS_UP,2016-10-16T02:09:20Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37208,MERGED,2016-10-16T08:11:47Z,2016-10-19T09:53:28Z,macros: fix partially consumed tokens in macro matchers,jseyfried,95a9e2a724019c11c9b69a45e7953f8ba1225df9,1,Add regression test.,THUMBS_UP,2016-10-17T20:27:55Z,durka,NA https://github.com/rust-lang/rust/pull/37213,MERGED,2016-10-16T11:16:03Z,2016-10-19T16:52:58Z,macros: improve `$crate`,jseyfried,8b0c292a728c113aaf1f27f079aae6a28110c587,13,Improve `$crate`.,HOORAY,2016-10-17T19:23:08Z,durka,NA https://github.com/rust-lang/rust/pull/37213,MERGED,2016-10-16T11:16:03Z,2016-10-19T16:52:58Z,macros: improve `$crate`,jseyfried,8b0c292a728c113aaf1f27f079aae6a28110c587,13,Improve `$crate`.,HOORAY,2016-10-26T18:09:56Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37215,MERGED,2016-10-16T13:17:19Z,2016-10-18T05:28:07Z,Update comment in Vec::dedup_by,flodiebold,187ddf30b08c8c38beae0f92b339d6b5fbd437c3,1,Update comment in Vec::dedup_by,THUMBS_UP,2016-10-16T14:49:33Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2016-10-17T04:48:20Z,bluss,NA https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2016-10-17T07:53:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2016-10-17T09:06:42Z,arthurprs,NA https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2016-10-17T14:25:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,THUMBS_UP,2016-11-10T18:38:17Z,mhristache,NA https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2016-11-15T21:47:21Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,THUMBS_UP,2016-11-15T21:47:21Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2017-01-25T01:50:24Z,matematikaadit,matematika.adit@gmail.com https://github.com/rust-lang/rust/pull/37229,MERGED,2016-10-17T04:21:14Z,2016-11-09T23:13:41Z,Replace FNV with a faster hash function.,nnethercote,00e48affde2d349e3b3bfbd3d0f6afb5d76282a7,91,Replace FnvHasher use with FxHasher. This speeds up compilation by 3--6% across most of rustc-benchmarks.,HEART,2017-01-25T11:26:43Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/37233,MERGED,2016-10-17T16:29:46Z,2016-10-19T09:53:31Z,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints,michaelwoerister,d07523c716cd384b257baca48046db1264aab7f6,14,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints.,THUMBS_UP,2016-10-17T17:01:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37233,MERGED,2016-10-17T16:29:46Z,2016-10-19T09:53:31Z,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints,michaelwoerister,d07523c716cd384b257baca48046db1264aab7f6,14,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints.,THUMBS_UP,2016-10-17T19:35:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37233,MERGED,2016-10-17T16:29:46Z,2016-10-19T09:53:31Z,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints,michaelwoerister,d07523c716cd384b257baca48046db1264aab7f6,14,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints.,THUMBS_UP,2016-10-18T10:07:23Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/37233,MERGED,2016-10-17T16:29:46Z,2016-10-19T09:53:31Z,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints,michaelwoerister,d07523c716cd384b257baca48046db1264aab7f6,14,ICH: Use 128-bit Blake2b hash instead of 64-bit SipHash for incr. comp. fingerprints.,THUMBS_UP,2016-10-26T18:06:12Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37241,MERGED,2016-10-18T02:38:12Z,2016-10-20T05:05:21Z,prefer `if let` to match with `None => { }` arm in some places,zackmdavis,1e7cd5edcca6598720e6a6cb7b7a2c103018028d,11,prefer `if let` to match with `None => { }` arm in some places In #34268 (8531d581) we replaced matches of None to the unit value `()` with `if let`s in places where it was deemed that this made the code unambiguously clearer and more idiomatic. In #34638 (d37edef9) we did the same for matches of None to the empty block `{}`. A casual observer upon seeing these commits fly by might suppose that the matter was then settled that no further pull requests on this utterly trivial point of style could or would be made. Unless ... It turns out that sometimes people write the empty block with a space in between the braces. Who knew?,THUMBS_UP,2016-10-18T07:56:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37241,MERGED,2016-10-18T02:38:12Z,2016-10-20T05:05:21Z,prefer `if let` to match with `None => { }` arm in some places,zackmdavis,1e7cd5edcca6598720e6a6cb7b7a2c103018028d,11,prefer `if let` to match with `None => { }` arm in some places In #34268 (8531d581) we replaced matches of None to the unit value `()` with `if let`s in places where it was deemed that this made the code unambiguously clearer and more idiomatic. In #34638 (d37edef9) we did the same for matches of None to the empty block `{}`. A casual observer upon seeing these commits fly by might suppose that the matter was then settled that no further pull requests on this utterly trivial point of style could or would be made. Unless ... It turns out that sometimes people write the empty block with a space in between the braces. Who knew?,LAUGH,2016-10-19T11:13:16Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/37241,MERGED,2016-10-18T02:38:12Z,2016-10-20T05:05:21Z,prefer `if let` to match with `None => { }` arm in some places,zackmdavis,1e7cd5edcca6598720e6a6cb7b7a2c103018028d,11,prefer `if let` to match with `None => { }` arm in some places In #34268 (8531d581) we replaced matches of None to the unit value `()` with `if let`s in places where it was deemed that this made the code unambiguously clearer and more idiomatic. In #34638 (d37edef9) we did the same for matches of None to the empty block `{}`. A casual observer upon seeing these commits fly by might suppose that the matter was then settled that no further pull requests on this utterly trivial point of style could or would be made. Unless ... It turns out that sometimes people write the empty block with a space in between the braces. Who knew?,LAUGH,2016-10-19T16:59:05Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/37243,CLOSED,2016-10-18T03:21:55Z,2016-11-10T21:07:04Z,Code cleanup in check_match.rs,jfirebaugh,NA,NA,NA,HEART,2016-10-18T03:23:36Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/37243,CLOSED,2016-10-18T03:21:55Z,2016-11-10T21:07:04Z,Code cleanup in check_match.rs,jfirebaugh,NA,NA,NA,HOORAY,2016-10-18T03:30:26Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37298,MERGED,2016-10-20T04:02:09Z,2016-10-22T16:45:31Z,Use a faster `deflate` setting,nnethercote,94771a177ba133bfadd0ffba55d82e7e3989ea06,1,Use fast decompression in `deflate_bytes`. This commit changes the parameters of `deflate` to do faster lower-quality compression. For the compression of LLVM bytecode -- which is the main use of `deflate_bytes` -- it makes compression almost twice as fast while the size of the compressed files is only ~2% worse.,HOORAY,2016-10-20T04:28:30Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37298,MERGED,2016-10-20T04:02:09Z,2016-10-22T16:45:31Z,Use a faster `deflate` setting,nnethercote,94771a177ba133bfadd0ffba55d82e7e3989ea06,1,Use fast decompression in `deflate_bytes`. This commit changes the parameters of `deflate` to do faster lower-quality compression. For the compression of LLVM bytecode -- which is the main use of `deflate_bytes` -- it makes compression almost twice as fast while the size of the compressed files is only ~2% worse.,HOORAY,2016-10-20T04:59:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37298,MERGED,2016-10-20T04:02:09Z,2016-10-22T16:45:31Z,Use a faster `deflate` setting,nnethercote,94771a177ba133bfadd0ffba55d82e7e3989ea06,1,Use fast decompression in `deflate_bytes`. This commit changes the parameters of `deflate` to do faster lower-quality compression. For the compression of LLVM bytecode -- which is the main use of `deflate_bytes` -- it makes compression almost twice as fast while the size of the compressed files is only ~2% worse.,HOORAY,2016-10-20T06:56:16Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/37298,MERGED,2016-10-20T04:02:09Z,2016-10-22T16:45:31Z,Use a faster `deflate` setting,nnethercote,94771a177ba133bfadd0ffba55d82e7e3989ea06,1,Use fast decompression in `deflate_bytes`. This commit changes the parameters of `deflate` to do faster lower-quality compression. For the compression of LLVM bytecode -- which is the main use of `deflate_bytes` -- it makes compression almost twice as fast while the size of the compressed files is only ~2% worse.,HOORAY,2016-10-20T07:35:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37306,MERGED,2016-10-20T13:15:08Z,2016-11-04T21:14:52Z,Add Iterator trait TrustedLen to enable better FromIterator / Extend,bluss,f0e6b90790da2203f04fa44ee3ed8f24dcc5f4dc,7,Link the tracking issue for TrustedLen,HEART,2016-10-20T23:05:18Z,gabomgp,gabomgp@gmail.com https://github.com/rust-lang/rust/pull/37313,MERGED,2016-10-20T22:35:16Z,2016-10-24T23:47:46Z,Add Fuchsia support,raphlinus,cea61408c335826a0e3fcd781ac5d05ae5ad432e,2,Update libc submodule with corresponding fuchsia changes Also trim os::fuchsia::raw architectures.,THUMBS_UP,2016-10-21T01:14:46Z,est31,NA https://github.com/rust-lang/rust/pull/37315,MERGED,2016-10-20T22:52:50Z,2016-10-26T21:58:23Z,Implement Iterator::fold for .chain() .cloned() .map() and the VecDeque iterators.,bluss,a16626fc422f9fdcd1d02f56b628f764d5282261,2,iter: Implement .fold() for .chain() Chain can do something interesting here where it passes on the fold into its inner iterators. The lets the underlying iterator's custom fold() be used and skips the regular chain logic in next.,THUMBS_UP,2016-10-21T14:34:49Z,cristicbz,NA https://github.com/rust-lang/rust/pull/37315,MERGED,2016-10-20T22:52:50Z,2016-10-26T21:58:23Z,Implement Iterator::fold for .chain() .cloned() .map() and the VecDeque iterators.,bluss,a16626fc422f9fdcd1d02f56b628f764d5282261,2,iter: Implement .fold() for .chain() Chain can do something interesting here where it passes on the fold into its inner iterators. The lets the underlying iterator's custom fold() be used and skips the regular chain logic in next.,THUMBS_UP,2016-11-06T12:00:32Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37315,MERGED,2016-10-20T22:52:50Z,2016-10-26T21:58:23Z,Implement Iterator::fold for .chain() .cloned() .map() and the VecDeque iterators.,bluss,a16626fc422f9fdcd1d02f56b628f764d5282261,2,iter: Implement .fold() for .chain() Chain can do something interesting here where it passes on the fold into its inner iterators. The lets the underlying iterator's custom fold() be used and skips the regular chain logic in next.,THUMBS_UP,2019-02-27T16:12:30Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/37324,MERGED,2016-10-21T14:14:19Z,2016-10-25T03:08:34Z,Improve E0277 help message,GuillaumeGomez,1fadd868cd4fbb16d9d9a7d07fa02997b50194f5,11,Improve E0277 help message,HEART,2016-10-24T21:28:23Z,estebank,NA https://github.com/rust-lang/rust/pull/37359,CLOSED,2016-10-23T00:28:37Z,2016-11-15T15:40:58Z,Fix backtraces on Windows/GNU,petrochenkov,NA,NA,NA,HEART,2016-10-25T02:11:17Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,HOORAY,2016-10-23T12:40:30Z,est31,NA https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,HEART,2016-10-23T12:40:32Z,est31,NA https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,THUMBS_UP,2016-10-24T13:23:15Z,kvark,NA https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,THUMBS_UP,2016-10-26T01:34:42Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,HOORAY,2016-10-26T01:34:43Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/37361,MERGED,2016-10-23T05:32:32Z,2016-10-26T04:50:08Z,Fix `$crate`-related regressions,jseyfried,0d30325286d01a5689735b1599173ba32a796aa4,2,Avoid false positive `unused_extern_crates`.,HEART,2016-10-26T01:34:44Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-10-23T21:55:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-10-23T23:01:12Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-10-24T00:40:52Z,retep998,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,HOORAY,2016-10-24T00:40:55Z,retep998,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-10-24T07:46:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-10-24T21:46:05Z,parched,NA https://github.com/rust-lang/rust/pull/37367,MERGED,2016-10-23T21:48:43Z,2016-10-29T00:02:10Z,Support `use *;` and `use ::*;`.,jseyfried,4a9364868949a5390d85d26af4d6562bc4a18fb3,2,Support `use *;` and `use ::*;`.,THUMBS_UP,2016-11-03T22:53:43Z,19h,int@sig.dev https://github.com/rust-lang/rust/pull/37369,MERGED,2016-10-24T00:43:39Z,2016-11-29T22:03:13Z,Show multiline spans in full if short enough,estebank,b7982bbbe0a002272b86ed2f7f7902b2c3471087,7,review comments,HEART,2016-11-11T05:24:16Z,brson,NA https://github.com/rust-lang/rust/pull/37369,MERGED,2016-10-24T00:43:39Z,2016-11-29T22:03:13Z,Show multiline spans in full if short enough,estebank,b7982bbbe0a002272b86ed2f7f7902b2c3471087,7,review comments,HEART,2016-12-07T20:41:24Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/37378,MERGED,2016-10-24T18:36:26Z,2016-10-29T15:54:38Z,Prohibit patterns in trait methods without bodies,petrochenkov,4ca11ce196d07206852a265d6a0546569de88912,1,Update cargo sha for cargotest,THUMBS_UP,2016-10-24T21:16:35Z,jseyfried,NA https://github.com/rust-lang/rust/pull/37388,CLOSED,2016-10-25T00:05:45Z,2016-11-29T21:35:23Z,Start of implementation of proposal for E0308,GuillaumeGomez,NA,NA,NA,HEART,2016-10-30T05:32:29Z,estebank,NA https://github.com/rust-lang/rust/pull/37388,CLOSED,2016-10-25T00:05:45Z,2016-11-29T21:35:23Z,Start of implementation of proposal for E0308,GuillaumeGomez,NA,NA,NA,HEART,2016-11-10T10:09:25Z,killercup,NA https://github.com/rust-lang/rust/pull/37392,MERGED,2016-10-25T02:36:12Z,2016-10-30T13:51:38Z,Disable jemalloc on aarch64/powerpc,alexcrichton,de80670f7487f5db26e3929f7f2f464345859b49,12,Disable jemalloc on aarch64/powerpc Sounds like jemalloc is broken on systems which differ in page size than the host it was compiled on (unless an option was passed). This unfortunately reduces the portability of binaries created and can often make Rust segfault by default. For now let's patch over this by disabling jemalloc until we can figure out a better solution. Closes #36994 Closes #37320 cc jemalloc/jemalloc#467,THUMBS_UP,2016-10-25T16:42:29Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/37400,MERGED,2016-10-25T15:14:55Z,2016-10-30T07:01:31Z,[1/n] Move the MIR map into the type context.,eddyb,e34792b181ab6af0221c0fb35940b1cc5dc476e1,26,rustc: move the MIR map into TyCtxt.,THUMBS_UP,2017-01-18T05:45:43Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/37412,MERGED,2016-10-26T00:18:05Z,2016-11-10T05:26:22Z,[6/n] rustc: transition HIR function bodies from Block to Expr.,eddyb,8e9106c531c559bf923de93cccbeb0fa0a47451f,2,tests: fix fallout in pretty-printing output exact-match tests.,THUMBS_UP,2016-10-26T15:43:57Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37423,CLOSED,2016-10-27T00:16:10Z,2016-11-15T15:51:43Z,Implement conversion traits for usize/isize together with a portability lint,petrochenkov,NA,NA,NA,THUMBS_UP,2018-04-05T00:32:44Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-23T21:11:37Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-24T03:47:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-24T21:23:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-28T15:11:29Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-29T02:32:58Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-11-30T10:20:45Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-12-01T21:22:51Z,tiffany352,tiffany@tiffnix.com https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2016-12-18T12:06:17Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2017-01-02T06:46:42Z,cbreeden,NA https://github.com/rust-lang/rust/pull/37429,MERGED,2016-10-27T04:14:02Z,2016-12-18T11:16:50Z,struct field reordering and optimization,ahicks92,ff59474ed356d69d75447af79278bdd28db16710,1,flock needs repr(C),HOORAY,2017-04-15T22:14:09Z,CAFxX,cafxx@strayorange.com https://github.com/rust-lang/rust/pull/37430,MERGED,2016-10-27T04:39:03Z,2016-10-28T20:42:35Z,"Add semicolon to ""Maybe a missing `extern crate foo`"" message",robinst,de5172ce5f41cc915829bd4ebc8409c42d936808,4,"Add semicolon to ""Maybe a missing `extern crate foo`"" message I had it a couple of times that I was missing the ""extern crate"" line after I introduced a new dependency. So I copied the text from the message and inserted it into the beginning of my code only to find the compiler complaining that I was missing the semicolon. (I forgot to add it after the text that I had pasted.) There's a similar message which does include the semicolon namely ""help: you can import it into scope: `use foo::Bar;`"". I think the two messages should be consistent so this change adds it for ""extern crate"".",THUMBS_UP,2016-10-27T07:22:10Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/37445,MERGED,2016-10-28T04:35:10Z,2016-10-30T20:37:08Z,Shrink Expr_::ExprInlineAsm.,nnethercote,a920e355ea837a950b484b5791051337cd371f5d,2,Shrink Expr_::ExprInlineAsm. On 64-bit this reduces the size of `Expr_` from 144 to 64 bytes and reduces the size of `Expr` from 176 to 96 bytes.,HEART,2016-10-31T23:57:29Z,brson,NA https://github.com/rust-lang/rust/pull/37445,MERGED,2016-10-28T04:35:10Z,2016-10-30T20:37:08Z,Shrink Expr_::ExprInlineAsm.,nnethercote,a920e355ea837a950b484b5791051337cd371f5d,2,Shrink Expr_::ExprInlineAsm. On 64-bit this reduces the size of `Expr_` from 144 to 64 bytes and reduces the size of `Expr` from 176 to 96 bytes.,THUMBS_UP,2016-11-04T15:04:30Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37445,MERGED,2016-10-28T04:35:10Z,2016-10-30T20:37:08Z,Shrink Expr_::ExprInlineAsm.,nnethercote,a920e355ea837a950b484b5791051337cd371f5d,2,Shrink Expr_::ExprInlineAsm. On 64-bit this reduces the size of `Expr_` from 144 to 64 bytes and reduces the size of `Expr` from 176 to 96 bytes.,THUMBS_UP,2016-12-22T20:55:33Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,THUMBS_UP,2016-10-29T00:47:05Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,THUMBS_UP,2016-10-29T02:20:48Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,HOORAY,2016-11-11T05:27:02Z,brson,NA https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,HOORAY,2016-11-11T06:09:21Z,sinkuu,NA https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,HOORAY,2017-01-11T10:44:19Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,HOORAY,2017-01-24T23:12:43Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37456,MERGED,2016-10-28T21:21:23Z,2016-11-11T21:05:39Z,Group unused import warnings per import list,estebank,a820d99eb28fcc144c97fc3d152b272d85f6e280,7,Group unused import warnings per path list Given a file ```rust use std::collections::{BinaryHeap BTreeMap BTreeSet}; fn main() {} ``` Show a single warning instead of three for each unused import: ```nocode warning: unused imports #[warn(unused_imports)] on by default --> foo.rs:1:24 | 1 | use std::collections::{BinaryHeap BTreeMap BTreeSet}; | ^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ``` Include support for lints pointing at `MultilineSpan`s instead of just `Span`s.,THUMBS_UP,2017-02-03T00:02:23Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/37459,MERGED,2016-10-28T22:28:50Z,2016-10-31T00:01:38Z,Fix ICE when attempting to print closure generics,Mark-Simulacrum,bdb399db010c05a18f5c6622c9ba1cbed37a214e,3,Fix ICE when attempting to get closure generics.,HEART,2016-10-30T17:28:59Z,arielb1,NA https://github.com/rust-lang/rust/pull/37476,CLOSED,2016-10-29T23:34:56Z,2016-10-31T10:23:59Z,Removed most instances of vec!(..) and replaced them with vec![..]s,iirelu,NA,NA,NA,THUMBS_UP,2016-10-29T23:37:55Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37476,CLOSED,2016-10-29T23:34:56Z,2016-10-31T10:23:59Z,Removed most instances of vec!(..) and replaced them with vec![..]s,iirelu,NA,NA,NA,THUMBS_UP,2016-10-29T23:44:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37476,CLOSED,2016-10-29T23:34:56Z,2016-10-31T10:23:59Z,Removed most instances of vec!(..) and replaced them with vec![..]s,iirelu,NA,NA,NA,THUMBS_UP,2016-10-29T23:52:11Z,erincandescent,erin.shepherd@e43.eu https://github.com/rust-lang/rust/pull/37476,CLOSED,2016-10-29T23:34:56Z,2016-10-31T10:23:59Z,Removed most instances of vec!(..) and replaced them with vec![..]s,iirelu,NA,NA,NA,THUMBS_UP,2016-10-30T00:36:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37476,CLOSED,2016-10-29T23:34:56Z,2016-10-31T10:23:59Z,Removed most instances of vec!(..) and replaced them with vec![..]s,iirelu,NA,NA,NA,THUMBS_UP,2016-10-30T01:18:53Z,retep998,NA https://github.com/rust-lang/rust/pull/37485,MERGED,2016-10-30T14:24:23Z,2016-11-02T06:50:13Z,"Don't mention ""*"" dependency version in guessing game example",xfix,9cc98612d70cb2dca1d1f5782648f434645fc7d6,1,"Don't mention ""*"" dependency version in guessing game example It's a bad practice as far [RFC 1241] is concerned and introducing it in early tutorial may as well make it feel legitimate. [RFC 1241]: https://github.com/rust-lang/rfcs/blob/master/text/1241-no-wildcard-deps.md",THUMBS_UP,2016-10-30T14:28:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37485,MERGED,2016-10-30T14:24:23Z,2016-11-02T06:50:13Z,"Don't mention ""*"" dependency version in guessing game example",xfix,9cc98612d70cb2dca1d1f5782648f434645fc7d6,1,"Don't mention ""*"" dependency version in guessing game example It's a bad practice as far [RFC 1241] is concerned and introducing it in early tutorial may as well make it feel legitimate. [RFC 1241]: https://github.com/rust-lang/rfcs/blob/master/text/1241-no-wildcard-deps.md",THUMBS_UP,2016-10-30T17:23:20Z,killercup,NA https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-11-01T02:27:23Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-11-16T14:01:25Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-11-23T09:42:09Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-11-30T13:43:31Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-11-30T19:18:35Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37487,MERGED,2016-10-30T19:33:56Z,2016-11-23T03:54:15Z,Implement the `loop_break_value` feature.,goffrie,9d42549df40464899dda11fc9509f511046fb4c6,35,Implement the `loop_break_value` feature. This implements RFC 1624 tracking issue #37339. - `FnCtxt` (in typeck) gets a stack of `LoopCtxt`s which store the currently deduced type of that loop the desired type and a list of break expressions currently seen. `loop` loops get a fresh type variable as their initial type (this logic is stolen from that for arrays). `while` loops get `()`. - `break {expr}` looks up the broken loop and unifies the type of `expr` with the type of the loop. - `break` with no expr unifies the loop's type with `()`. - When building MIR `loop` loops no longer construct a `()` value at termination of the loop; rather the `break` expression assigns the result of the loop. `while` loops are unchanged. - `break` respects contexts in which expressions may not end with braced blocks. That is `while break { break-value } { while-body }` is illegal; this preserves backwards compatibility. - The RFC did not make it clear but I chose to make `break ()` inside of a `while` loop illegal just in case we wanted to do anything with that design space in the future. This is my first time dealing with this part of rustc so I'm sure there's plenty of problems to pick on here ^_^,HOORAY,2016-12-01T07:06:04Z,libreoscar,NA https://github.com/rust-lang/rust/pull/37493,CLOSED,2016-10-31T04:56:40Z,2017-01-05T17:42:48Z,Show span for trait that doesn't implement Copy,estebank,NA,NA,NA,HEART,2016-11-11T04:08:53Z,brson,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-01T20:17:17Z,durka,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",HOORAY,2016-11-01T20:17:20Z,durka,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",HOORAY,2016-11-01T20:39:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-01T21:25:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",HOORAY,2016-11-01T21:37:05Z,retep998,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-02T00:14:04Z,bluss,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",HOORAY,2016-11-02T11:32:07Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",HOORAY,2016-11-02T13:35:53Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-02T13:35:54Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-03T05:36:21Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37521,MERGED,2016-11-01T20:09:58Z,2016-11-06T09:52:26Z,rustbuild: Rewrite user-facing interface,alexcrichton,a270b8014cbd3af6e03f7f808a2fea1e9f22ed88,17,"rustbuild: Rewrite user-facing interface This commit is a rewrite of the user-facing interface to the rustbuild build system. The intention here is to make it much easier to compile/test the project without having to remember weird rule names and such. An overall view of the new interface is: # build everything ./x.py build # document everyting ./x.py doc # test everything ./x.py test # test libstd ./x.py test src/libstd # build libcore stage0 ./x.py build src/libcore --stage 0 # run stage1 run-pass tests ./x.py test src/test/run-pass --stage 1 The `src/bootstrap/bootstrap.py` script is now aliased as a top-level `x.py` script. This `x` was chosen to be both short and easily tab-completable (no collisions in that namespace!). The build system now accepts a ""subcommand"" of what to do next the main ones being build/doc/test. Each subcommand then receives an optional list of arguments. These arguments are paths in the source repo of what to work with. That is if you want to test a directory you just pass that directory as an argument. The purpose of this rewrite is to do away with all of the arcane renames like ""rpass"" is the ""run-pass"" suite ""cfail"" is the ""compile-fail"" suite etc. By simply working with directories and files it's much more intuitive of how to run a test (just pass it as an argument). The rustbuild step/dependency management was also rewritten along the way to make this easy to work with and define but that's largely just a refactoring of what was there before. The *intention* is that this support is extended for arbitrary files (e.g. `src/test/run-pass/my-test-case.rs`) but that isn't quite implemented just yet. Instead directories work for now but we can follow up with stricter path filtering logic to plumb through all the arguments.",THUMBS_UP,2016-11-09T09:49:31Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37524,MERGED,2016-11-01T22:15:53Z,2016-11-09T23:13:46Z,Vendor all rustbuild dependencies in this repo,alexcrichton,31a8638e5e716bec90f4398a57c58fb34e492667,17,rustbuild: Tweak for vendored dependencies A few changes are included here: * The `winapi` and `url` dependencies were dropped. The source code for these projects is pretty weighty and we're about to vendor them so let's not commit to that intake just yet. If necessary we can vendor them later but for now it shouldn't be necessary. * The `--frozen` flag is now always passed to Cargo obviating the need for tidy's `cargo_lock` check. * Tidy was updated to not check the vendor directory Closes #34687,THUMBS_DOWN,2016-11-02T03:00:59Z,retep998,NA https://github.com/rust-lang/rust/pull/37524,MERGED,2016-11-01T22:15:53Z,2016-11-09T23:13:46Z,Vendor all rustbuild dependencies in this repo,alexcrichton,31a8638e5e716bec90f4398a57c58fb34e492667,17,rustbuild: Tweak for vendored dependencies A few changes are included here: * The `winapi` and `url` dependencies were dropped. The source code for these projects is pretty weighty and we're about to vendor them so let's not commit to that intake just yet. If necessary we can vendor them later but for now it shouldn't be necessary. * The `--frozen` flag is now always passed to Cargo obviating the need for tidy's `cargo_lock` check. * Tidy was updated to not check the vendor directory Closes #34687,THUMBS_DOWN,2016-11-04T06:10:09Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37524,MERGED,2016-11-01T22:15:53Z,2016-11-09T23:13:46Z,Vendor all rustbuild dependencies in this repo,alexcrichton,31a8638e5e716bec90f4398a57c58fb34e492667,17,rustbuild: Tweak for vendored dependencies A few changes are included here: * The `winapi` and `url` dependencies were dropped. The source code for these projects is pretty weighty and we're about to vendor them so let's not commit to that intake just yet. If necessary we can vendor them later but for now it shouldn't be necessary. * The `--frozen` flag is now always passed to Cargo obviating the need for tidy's `cargo_lock` check. * Tidy was updated to not check the vendor directory Closes #34687,THUMBS_DOWN,2016-11-08T17:40:59Z,est31,NA https://github.com/rust-lang/rust/pull/37524,MERGED,2016-11-01T22:15:53Z,2016-11-09T23:13:46Z,Vendor all rustbuild dependencies in this repo,alexcrichton,31a8638e5e716bec90f4398a57c58fb34e492667,17,rustbuild: Tweak for vendored dependencies A few changes are included here: * The `winapi` and `url` dependencies were dropped. The source code for these projects is pretty weighty and we're about to vendor them so let's not commit to that intake just yet. If necessary we can vendor them later but for now it shouldn't be necessary. * The `--frozen` flag is now always passed to Cargo obviating the need for tidy's `cargo_lock` check. * Tidy was updated to not check the vendor directory Closes #34687,THUMBS_UP,2016-11-08T19:51:53Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37540,MERGED,2016-11-02T19:09:43Z,2016-11-03T00:46:55Z,Rollup of 10 pull requests,jntrnr,0befab23435fe6490ae2de30378f9bc834fcc1a8,1,Rollup merge of #37523 - d-unseductable:deref_mut_lifetimes r=bluss Elide lifetimes in DerefMut documentation - Elide lifetimes to increase the readability of `DerefMut` examples,THUMBS_UP,2016-11-03T12:55:29Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37541,MERGED,2016-11-02T22:12:57Z,2016-11-03T10:11:45Z,Use impl obligations as initial environment for specialization,nikomatsakis,b4f910d9004f09620ef5b1aff5d676c1dab7d42f,1,just use full-normalization when for the impl trait ref This seems better because I want to avoid the situation where unresolved inference variables make it into the environment. On the other hand I am not 100% sure that this is correct. My assumption was that the WF check should ensure that this normalization can succeed. But it occurs to me that the WF checks may need to make use of the `specializes` predicate themselves and hence we may have a kind of cycle here (this is a bigger problem with spec in any case that we need to resolve). On the other hand this should just cause extra errors I think so it seems like a safe thing to attempt. Certainly all tests pass.,THUMBS_UP,2016-11-02T23:32:35Z,jroesch,NA https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2016-11-04T05:08:32Z,est31,NA https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2016-11-16T20:39:16Z,joerg-krause,NA https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2016-11-23T22:00:48Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",HOORAY,2016-11-23T22:00:51Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2017-06-20T11:10:25Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2017-07-24T22:03:58Z,jseyfried,NA https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",THUMBS_UP,2017-11-05T14:39:37Z,johnsheleg,NA https://github.com/rust-lang/rust/pull/37545,MERGED,2016-11-03T00:42:39Z,2016-11-16T19:47:22Z,rustc: Implement #[link(cfg(..))] and crt-static,alexcrichton,06242ff15d2b510689a99c33aa2495da11a75fad,31,"rustc: Implement #[link(cfg(..))] and crt-static This commit is an implementation of [RFC 1721] which adds a new target feature to the compiler `crt-static` which can be used to select how the C runtime for a target is linked. Most targets dynamically linke the C runtime by default with the notable exception of some of the musl targets. [RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md This commit first adds the new target-feature `crt-static`. If enabled then the `cfg(target_feature = ""crt-static"")` will be available. Targets like musl will have this enabled by default. This feature can be controlled through the standard target-feature interface `-C target-feature=+crt-static` or `-C target-feature=-crt-static`. Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the `crt-static` semantics we want with libc. The exact behavior of this attribute is a little squishy but it's intended to be a forever-unstable implementation detail of the liblibc crate. Specifically the `#[link(cfg(..))]` annotation means that the `#[link]` directive is only active in a compilation unit if that `cfg` value is satisfied. For example when compiling an rlib these directives are just encoded and ignored for dylibs and all staticlibs are continued to be put into the rlib as usual. When placing that rlib into a staticlib executable or dylib however the `cfg` is evaluated *as if it were defined in the final artifact* and the library is decided to be linked or not. Essentially what'll happen is: * On MSVC with `-C target-feature=-crt-static` the `msvcrt.lib` library will be linked to. * On MSVC with `-C target-feature=+crt-static` the `libcmt.lib` library will be linked to. * On musl with `-C target-feature=-crt-static` the object files in liblibc.rlib are removed and `-lc` is passed instead. * On musl with `-C target-feature=+crt-static` the object files in liblibc.rlib are used and `-lc` is not passed. This commit does **not** include an update to the liblibc module to implement these changes. I plan to do that just after the 1.14.0 beta release is cut to ensure we get ample time to test this feature. cc #37406",HOORAY,2019-02-08T22:10:24Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/37583,MERGED,2016-11-04T15:43:35Z,2016-11-06T09:52:31Z,Add `-Z hir-stats` for collecting statistics on HIR and AST,michaelwoerister,94e655eca6909fdca6f346e04abdcec8b8cc6e25,5,Add -Zhir-stats for collecting statistics on HIR and AST,THUMBS_UP,2016-11-04T18:29:36Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37583,MERGED,2016-11-04T15:43:35Z,2016-11-06T09:52:31Z,Add `-Z hir-stats` for collecting statistics on HIR and AST,michaelwoerister,94e655eca6909fdca6f346e04abdcec8b8cc6e25,5,Add -Zhir-stats for collecting statistics on HIR and AST,HEART,2016-11-08T04:05:22Z,brson,NA https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HOORAY,2016-11-04T18:18:55Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,THUMBS_UP,2016-11-04T18:18:57Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HEART,2016-11-04T18:19:00Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,THUMBS_UP,2016-11-05T12:16:30Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HOORAY,2016-11-05T12:16:33Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HOORAY,2016-11-08T09:36:12Z,alexbool,NA https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,THUMBS_UP,2016-11-08T09:36:12Z,alexbool,NA https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HEART,2016-11-08T09:36:13Z,alexbool,NA https://github.com/rust-lang/rust/pull/37584,MERGED,2016-11-04T16:51:23Z,2016-11-12T12:15:40Z,Move all Linux/OSX CI infastructure to Travis,alexcrichton,008cc2d999012780514abc5b0c7510e648b0728c,24,Move all Linux/OSX CI infastructure to Travis This commit configures our `.travis.yml` to test the full suite of tests we have on Buildbot right now. A whole mess of docker images are added to the `src/ci` directory which represent all the build environments for each configuration. Each of these environments is then configured in `.travis.yml` to run on the auto branch. Note that the full matrix of tests aren't intended to be run on all PRs. Instead we continue to run only one entry in the matrix forcing all others to finish quickly. Only the `auto` branch should run the full matrix of builds. Also note that the infrastructure hasn't quite been allocated yet to the rust-lang/rust repository so everything is disabled for now except for the one build that happens on PRs. Once that infrastructure is allocated though we can enable this and let it fly! Notable modifications from the current test suite today: * Android tests are run in rustbuild instead of the makefiles for whatever reason I couldn't get the makefiles to work on Travis. * A debuginfo test was updated to work with the current version of the Android NDK. * Some dependencies in `mk/tests.mk` were fixed to allow running tests in parallel.,HEART,2016-11-11T04:24:55Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37585,MERGED,2016-11-04T17:55:32Z,2016-11-06T09:52:31Z,Change `Into> for String` and `Into for PathBuf` to From,leoyvens,3e4bd8843829284a62af22687ee415a66c8207cc,2,Change Into> for String and Into for PathBuf to From impls,THUMBS_UP,2016-11-04T19:21:02Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/37585,MERGED,2016-11-04T17:55:32Z,2016-11-06T09:52:31Z,Change `Into> for String` and `Into for PathBuf` to From,leoyvens,3e4bd8843829284a62af22687ee415a66c8207cc,2,Change Into> for String and Into for PathBuf to From impls,THUMBS_UP,2016-11-05T22:53:29Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37586,MERGED,2016-11-04T18:08:58Z,2016-11-06T09:52:31Z,fix #37559: update compiler-rt,TimNN,a6cf77704f407f26a181af9cfd7c838ea6270312,1,fix #37559: update compiler-rt,HEART,2016-11-04T22:28:30Z,brson,NA https://github.com/rust-lang/rust/pull/37600,MERGED,2016-11-05T04:28:04Z,2016-11-12T12:15:40Z,Add changelog for 1.13.0,brson,0f817a0dd9b4715ee5df2ae5146a2527ab4f45fc,1,Add release notes for 1.13.0,HOORAY,2016-11-06T18:47:52Z,estebank,NA https://github.com/rust-lang/rust/pull/37600,MERGED,2016-11-05T04:28:04Z,2016-11-12T12:15:40Z,Add changelog for 1.13.0,brson,0f817a0dd9b4715ee5df2ae5146a2527ab4f45fc,1,Add release notes for 1.13.0,HOORAY,2016-11-10T19:05:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-06T09:42:27Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-06T11:31:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-06T14:24:46Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-06T14:52:18Z,killercup,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2016-11-06T22:26:35Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-06T23:14:26Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-07T07:10:29Z,xen0n,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-07T15:12:30Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2016-11-07T18:38:14Z,est31,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-07T19:38:26Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-08T23:55:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2016-11-09T00:01:23Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-09T00:01:24Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2016-11-11T00:34:24Z,brson,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2017-01-24T23:10:54Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2017-01-24T23:11:47Z,causal-agent,june@causal.agency https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2017-01-25T02:20:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2017-01-25T02:20:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2017-01-25T11:36:29Z,ConnyOnny,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,HEART,2017-01-25T16:06:00Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2017-01-26T13:02:51Z,hoodie,NA https://github.com/rust-lang/rust/pull/37613,MERGED,2016-11-06T09:02:30Z,2016-11-12T12:15:41Z,Add foreign formatting directive detection.,DanielKeep,455723c638b0e9db34d427a82bc13f95b75a304d,6,Add foreign formatting directive detection. This teaches `format_args!` how to interpret format printf- and shell-style format directives. This is used in cases where there are unused formatting arguments and the reason for that *might* be because the programmer is trying to use the wrong kind of formatting string. This was prompted by an issue encountered by simulacrum on the #rust IRC channel. In short: although `println!` told them that they weren't using all of the conversion arguments the problem was in using printf-syle directives rather than ones `println!` would undertand. Where possible `format_args!` will tell the programmer what they should use instead. For example it will suggest replacing `%05d` with `{:0>5}` or `%2$.*3$s` with `{1:.3$}`. Even if it cannot suggest a replacement it will explicitly note that Rust does not support that style of directive and direct the user to the `std::fmt` documentation.,THUMBS_UP,2017-02-02T07:52:55Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/37615,MERGED,2016-11-06T12:10:23Z,2016-11-12T12:15:41Z,Add support for ARMv5TE architecture,atilag,365ea800bdb95ed91ac92697e5820ef4a5d7104f,1,Set max_atomic_width to 0 because there's no atomic instructions on ARMv5,THUMBS_UP,2016-11-11T05:54:19Z,brson,NA https://github.com/rust-lang/rust/pull/37615,MERGED,2016-11-06T12:10:23Z,2016-11-12T12:15:41Z,Add support for ARMv5TE architecture,atilag,365ea800bdb95ed91ac92697e5820ef4a5d7104f,1,Set max_atomic_width to 0 because there's no atomic instructions on ARMv5,THUMBS_UP,2016-11-29T22:36:47Z,joerg-krause,NA https://github.com/rust-lang/rust/pull/37660,MERGED,2016-11-09T02:08:18Z,2016-11-18T04:56:07Z,Separate impl items from the parent impl,nikomatsakis,c938007f90711d6acc8b55e15a5e3cf7cc147e91,1,add test for hashing trait impls,HOORAY,2016-11-09T15:12:19Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37660,MERGED,2016-11-09T02:08:18Z,2016-11-18T04:56:07Z,Separate impl items from the parent impl,nikomatsakis,c938007f90711d6acc8b55e15a5e3cf7cc147e91,1,add test for hashing trait impls,HOORAY,2016-11-18T15:36:50Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/37672,MERGED,2016-11-09T19:06:02Z,2016-11-15T12:42:32Z,enable the MSP430 LLVM backend,japaric,80ca1e1251b634b8b9831aa999f3f7435ccfdd16,1,don't build an object file for emit=asm llvm-ir,HOORAY,2016-11-09T19:48:23Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37672,MERGED,2016-11-09T19:06:02Z,2016-11-15T12:42:32Z,enable the MSP430 LLVM backend,japaric,80ca1e1251b634b8b9831aa999f3f7435ccfdd16,1,don't build an object file for emit=asm llvm-ir,HOORAY,2016-11-09T20:21:58Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37672,MERGED,2016-11-09T19:06:02Z,2016-11-15T12:42:32Z,enable the MSP430 LLVM backend,japaric,80ca1e1251b634b8b9831aa999f3f7435ccfdd16,1,don't build an object file for emit=asm llvm-ir,HOORAY,2016-11-09T23:39:43Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/37672,MERGED,2016-11-09T19:06:02Z,2016-11-15T12:42:32Z,enable the MSP430 LLVM backend,japaric,80ca1e1251b634b8b9831aa999f3f7435ccfdd16,1,don't build an object file for emit=asm llvm-ir,HOORAY,2016-11-10T17:55:26Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HEART,2016-11-10T15:08:33Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HOORAY,2016-11-11T03:08:46Z,brson,NA https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HEART,2016-11-15T16:02:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HEART,2016-12-07T10:04:42Z,Havvy,NA https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HOORAY,2016-12-07T13:20:00Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/37676,MERGED,2016-11-09T21:50:50Z,2016-11-28T13:03:47Z,[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions.,eddyb,372c6df564616dd461b82def5d75428940ca04ae,5,rustc_typeck: don't record associated type resolutions.,HOORAY,2016-12-07T21:48:30Z,Thiez,NA https://github.com/rust-lang/rust/pull/37681,MERGED,2016-11-10T05:30:48Z,2016-11-23T07:21:48Z,add --crate-type metadata,nrc,af1b19555ce636788c19dba979b57536792d90e9,11,Rebasing and review changes,HOORAY,2016-11-17T22:37:18Z,msiglreith,NA https://github.com/rust-lang/rust/pull/37688,MERGED,2016-11-10T12:20:15Z,2016-11-12T12:15:43Z,[8/n] rustc: clean up lookup_item_type and remove TypeScheme.,eddyb,3f9eba1c7c31edd58b65d22bfad07c5e269e3af6,61,rustc: clean up lookup_item_type and remove TypeScheme.,HEART,2016-11-10T15:08:16Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37688,MERGED,2016-11-10T12:20:15Z,2016-11-12T12:15:43Z,[8/n] rustc: clean up lookup_item_type and remove TypeScheme.,eddyb,3f9eba1c7c31edd58b65d22bfad07c5e269e3af6,61,rustc: clean up lookup_item_type and remove TypeScheme.,HEART,2016-11-10T16:19:26Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/37695,MERGED,2016-11-10T20:54:13Z,2016-11-12T12:15:44Z,On fmt string with unescaped `{` note how to escape,estebank,3c17abc4d955080baa410e9b697bf5be37b0d079,4,"On fmt string with unescaped `{` note how to escape On cases of malformed format strings where a `{` hasn't been properly escaped like `println!(""{"");` present a note explaining how to escape the `{` char.",THUMBS_UP,2016-11-10T21:27:49Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37699,MERGED,2016-11-11T00:22:46Z,2016-11-12T12:15:45Z,std: Derive `Default` for `Duration`.,alexcrichton,30502b820519ab63c1007f2cb615322301a9ce3d,1,std: Derive `Default` for `Duration`. Discussed in #37546 the libs team reached the conclusion that a default zero duration seems like a reasonable implementation of the `Default` trait. Closes #37546,THUMBS_UP,2016-11-11T01:33:33Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37699,MERGED,2016-11-11T00:22:46Z,2016-11-12T12:15:45Z,std: Derive `Default` for `Duration`.,alexcrichton,30502b820519ab63c1007f2cb615322301a9ce3d,1,std: Derive `Default` for `Duration`. Discussed in #37546 the libs team reached the conclusion that a default zero duration seems like a reasonable implementation of the `Default` trait. Closes #37546,THUMBS_UP,2016-11-14T16:59:25Z,luser,NA https://github.com/rust-lang/rust/pull/37701,MERGED,2016-11-11T01:22:17Z,2016-11-14T03:46:38Z,Macro parser performance improvements and refactoring,Mark-Simulacrum,2189f573caf93e389a56aefe0aeaa027feafd281,1,Remove extra level of nesting.,HOORAY,2016-11-11T03:07:05Z,brson,NA https://github.com/rust-lang/rust/pull/37701,MERGED,2016-11-11T01:22:17Z,2016-11-14T03:46:38Z,Macro parser performance improvements and refactoring,Mark-Simulacrum,2189f573caf93e389a56aefe0aeaa027feafd281,1,Remove extra level of nesting.,HOORAY,2016-11-11T13:03:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37701,MERGED,2016-11-11T01:22:17Z,2016-11-14T03:46:38Z,Macro parser performance improvements and refactoring,Mark-Simulacrum,2189f573caf93e389a56aefe0aeaa027feafd281,1,Remove extra level of nesting.,HOORAY,2016-11-13T04:51:35Z,jseyfried,NA https://github.com/rust-lang/rust/pull/37701,MERGED,2016-11-11T01:22:17Z,2016-11-14T03:46:38Z,Macro parser performance improvements and refactoring,Mark-Simulacrum,2189f573caf93e389a56aefe0aeaa027feafd281,1,Remove extra level of nesting.,HOORAY,2016-11-25T03:54:19Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T03:54:32Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T04:03:46Z,RobertWHurst,robertwhurst@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T08:37:28Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T08:48:28Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T08:51:53Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T11:20:26Z,dawid2193487,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T15:39:13Z,est31,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,HOORAY,2016-11-11T17:32:41Z,NilSet,thomas.a.levy@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T18:15:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,HOORAY,2016-11-11T18:15:03Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,HOORAY,2016-11-11T19:39:53Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,HOORAY,2016-11-11T19:39:53Z,StefanoD,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-11T22:37:38Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-12T05:25:58Z,bungcip,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,HOORAY,2016-11-12T07:32:40Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-12T07:32:42Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-11-25T18:35:05Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-12-01T04:37:50Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2016-12-19T07:37:41Z,rhysd,NA https://github.com/rust-lang/rust/pull/37702,MERGED,2016-11-11T03:43:55Z,2016-12-15T09:26:26Z,Redox Support Preview,jackpot51,3e15dc108c66891da04aa8c3f77162746fab4277,56,Merge branch 'master' into redox,THUMBS_UP,2019-04-10T17:05:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/37703,CLOSED,2016-11-11T04:27:42Z,2017-01-03T16:33:12Z,[RFC] Add flag for Unicode based Frontend support,estebank,NA,NA,NA,HEART,2016-11-11T06:34:29Z,brson,NA https://github.com/rust-lang/rust/pull/37703,CLOSED,2016-11-11T04:27:42Z,2017-01-03T16:33:12Z,[RFC] Add flag for Unicode based Frontend support,estebank,NA,NA,NA,HEART,2016-11-11T13:02:56Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37709,MERGED,2016-11-11T11:58:51Z,2016-11-12T12:15:46Z,vec: Write the .extend() specialization in cleaner style,bluss,5058e58676bd6c3af63fc4e35a327c07fce2a276,1,vec: Write the .extend() specialization in cleaner style As far as possible use regular `default fn` specialization in favour of ad-hoc conditionals.,THUMBS_UP,2016-11-11T13:28:58Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37714,MERGED,2016-11-11T16:23:46Z,2016-11-15T15:58:16Z,rustc: Flag all builtins functions as hidden,alexcrichton,88b46460fa1483b3283b7f1e37c7abd033610a68,3,rustc: Flag all builtins functions as hidden When compiling compiler-rt you typically compile with `-fvisibility=hidden` which to ensure that all symbols are hidden in shared objects and don't show up in symbol tables. This is important for these intrinsics being linked in every crate to ensure that we're not unnecessarily bloating the public ABI of Rust crates. This should help allow the compiler-builtins project with Rust-defined builtins start landing in-tree as well.,THUMBS_UP,2016-11-11T16:26:28Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/37714,MERGED,2016-11-11T16:23:46Z,2016-11-15T15:58:16Z,rustc: Flag all builtins functions as hidden,alexcrichton,88b46460fa1483b3283b7f1e37c7abd033610a68,3,rustc: Flag all builtins functions as hidden When compiling compiler-rt you typically compile with `-fvisibility=hidden` which to ensure that all symbols are hidden in shared objects and don't show up in symbol tables. This is important for these intrinsics being linked in every crate to ensure that we're not unnecessarily bloating the public ABI of Rust crates. This should help allow the compiler-builtins project with Rust-defined builtins start landing in-tree as well.,THUMBS_UP,2016-11-16T09:13:06Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37729,CLOSED,2016-11-12T07:45:45Z,2017-04-01T22:52:26Z,Less unused argument spew,DanielKeep,NA,NA,NA,HEART,2016-12-05T23:56:12Z,estebank,NA https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-12T11:56:49Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-12T12:21:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-12T13:47:47Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-12T17:57:13Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-15T19:47:20Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-17T15:17:43Z,sinkuu,NA https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-17T20:08:44Z,bluss,NA https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2016-11-18T00:40:54Z,jminer,NA https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2018-04-28T16:09:55Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/37732,MERGED,2016-11-12T10:41:33Z,2016-11-17T18:57:12Z,Support `use`ing externally defined macros behind `#![feature(use_extern_macros)]`,jseyfried,6cb33a089fc4727bc070899f57aab3be1b215785,2,Cleanup formatting.,HOORAY,2018-05-22T19:13:15Z,hcpl,NA https://github.com/rust-lang/rust/pull/37742,MERGED,2016-11-13T01:19:14Z,2016-11-15T20:15:51Z,Add llvm debuginfo configure option,mrhota,d3574b8dc756c5bd5dd2d7b8053c0de15b902691,3,Make LLVM debuginfo option names consistent,HEART,2016-11-13T02:26:32Z,nnethercote,NA https://github.com/rust-lang/rust/pull/37742,MERGED,2016-11-13T01:19:14Z,2016-11-15T20:15:51Z,Add llvm debuginfo configure option,mrhota,d3574b8dc756c5bd5dd2d7b8053c0de15b902691,3,Make LLVM debuginfo option names consistent,HEART,2016-11-13T05:33:12Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37749,MERGED,2016-11-13T10:29:19Z,2016-11-18T19:45:57Z,Improvements to the #[should_panic] feature,keeperofdakeys,fb5ccf80fe83653018794562bfc105d6914384ae,3,Warn when a #[should_panic] test has an unexpected message,THUMBS_UP,2016-11-13T17:04:49Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37753,MERGED,2016-11-13T17:04:40Z,2016-11-13T21:09:32Z,Fix empty lifetime list or one with trailing comma being rejected,est31,34f33ec789297716995045f7067aeb4d77947d89,2,Fix empty lifetime list or one with trailing comma being rejected Fixes #37733,THUMBS_UP,2016-11-13T17:55:58Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37758,MERGED,2016-11-13T23:57:25Z,2016-11-16T04:43:58Z,do not use deprecated text for unstable docs,euclio,30f75e396a82d9c84372d14708822d68f7cd36b3,4,do not use deprecated text for unstable docs,HEART,2016-11-15T04:00:50Z,brson,NA https://github.com/rust-lang/rust/pull/37758,MERGED,2016-11-13T23:57:25Z,2016-11-16T04:43:58Z,do not use deprecated text for unstable docs,euclio,30f75e396a82d9c84372d14708822d68f7cd36b3,4,do not use deprecated text for unstable docs,THUMBS_UP,2016-11-16T09:10:00Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37763,MERGED,2016-11-14T06:11:44Z,2016-11-18T13:03:07Z,rustdoc: add cli argument `--playground-url`,liigo,dc3859d73e77a34b1a61fd4f23d18651bf515b80,2,rustdoc: add cli argument `--playground-url`,THUMBS_UP,2017-02-03T14:42:51Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/37763,MERGED,2016-11-14T06:11:44Z,2016-11-18T13:03:07Z,rustdoc: add cli argument `--playground-url`,liigo,dc3859d73e77a34b1a61fd4f23d18651bf515b80,2,rustdoc: add cli argument `--playground-url`,HEART,2017-02-03T14:42:56Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/37763,MERGED,2016-11-14T06:11:44Z,2016-11-18T13:03:07Z,rustdoc: add cli argument `--playground-url`,liigo,dc3859d73e77a34b1a61fd4f23d18651bf515b80,2,rustdoc: add cli argument `--playground-url`,THUMBS_UP,2017-11-30T22:04:59Z,isislovecruft,isis@patternsinthevoid.net https://github.com/rust-lang/rust/pull/37764,MERGED,2016-11-14T06:12:20Z,2016-11-16T09:18:02Z,Remove `scope_auxiliary`.,nnethercote,d7755701ad62f2b0764f9c86b77d65e59b7c5e6f,7,Remove `scope_auxiliary`. This reduces the peak RSS for a cut-down version of the program in #36799 by 10% from 951MB to 856MB.,HEART,2016-11-15T03:53:04Z,brson,NA https://github.com/rust-lang/rust/pull/37764,MERGED,2016-11-14T06:12:20Z,2016-11-16T09:18:02Z,Remove `scope_auxiliary`.,nnethercote,d7755701ad62f2b0764f9c86b77d65e59b7c5e6f,7,Remove `scope_auxiliary`. This reduces the peak RSS for a cut-down version of the program in #36799 by 10% from 951MB to 856MB.,HEART,2016-11-15T04:13:05Z,jseyfried,NA https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2016-11-17T22:46:05Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2016-11-19T02:52:36Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2017-05-12T17:57:40Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2017-05-15T12:54:21Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2019-09-04T02:49:12Z,liushooter,NA https://github.com/rust-lang/rust/pull/37770,MERGED,2016-11-14T16:13:59Z,2016-11-24T17:56:14Z,Add debug flag `-Z print-type-sizes` for instrumention type/variant sizes,pnkfelix,75825fe1df47866e1821d8b09f4c75930b6e57c1,15,Tests of `-Z print-type-sizes` functionality. Note that the tests have been updated to initialize the local variables; originally it was enough just to declare them. Back when I started this the `layout_cache` contained entries even just for types that had been declared but not initialized. Apparently things have changed in the interim so that if I want one of those layouts to be computed I need to actually initialize the value. (Incidentally this shows a weakness in the strategy of just walking the `layout_cache`; the original strategy of using a MIR visitor would probably have exhibited more robustness in terms of consistent output but it had other weaknesses so I chose not to reimplement it. At least not yet.) ---- Also I have updated tests to avoid target-specific alignments.,HOORAY,2020-08-26T14:50:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/37772,MERGED,2016-11-14T17:38:21Z,2016-11-17T22:16:34Z,add test for #37765,durka,8e70a50a8a1c2d4bc9f02b27634c6d71952bf03f,1,add test for #37765,HEART,2016-11-15T03:51:48Z,brson,NA https://github.com/rust-lang/rust/pull/37773,MERGED,2016-11-14T18:30:16Z,2016-11-16T13:06:37Z,rustdoc: Fix some local inlining issues,ollie27,6fe7786db6d44449127600cf69838cb246db810b,6,rustdoc: Fix some local inlining issues * Only inline public items when inlining glob imports. * Never inline while in a private module or a child of a private module. * Never inline impls. This allowed the removal of a workaround in the rendering code.,HEART,2016-11-15T03:13:34Z,brson,NA https://github.com/rust-lang/rust/pull/37774,MERGED,2016-11-14T20:52:13Z,2016-11-16T16:25:44Z,Update top-level path doc examples to show results.,frewsxcv,af1aa1bccf8029a1db1aaddfc6b8c54ea3dff927,1,Update top-level path doc examples to show results.,HEART,2016-11-15T03:43:38Z,brson,NA https://github.com/rust-lang/rust/pull/37789,MERGED,2016-11-15T21:28:15Z,2016-12-02T04:39:29Z,limit the length of types in monomorphization,arielb1,242cd7ebe295d44c7b612e2e1da8b83412d31f49,9,limit the length of types in monomorphization This adds the new insta-stable `#![type_size_limit]` crate attribute to control the limit and is obviously a [breaking-change] fixable by that.,THUMBS_UP,2016-12-10T04:39:03Z,bombless,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-16T05:34:09Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-16T09:13:09Z,arthurprs,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-16T12:19:44Z,alexbool,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-16T13:20:34Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-18T10:58:58Z,FlorentBecker,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-22T11:17:59Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-28T21:33:33Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-29T02:29:35Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-11-29T18:02:44Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2016-12-07T14:45:24Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/37791,MERGED,2016-11-16T00:33:13Z,2016-11-29T01:54:47Z,Support `?Sized` in where clauses,petrochenkov,7d15250b0e5180137f5055b2e4333d5aac6579fe,6,Support `?Sized` in where clauses,HOORAY,2017-02-02T19:00:09Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37802,CLOSED,2016-11-16T18:05:35Z,2017-02-03T05:34:47Z,move to the WIP Rust port of compiler-rt,japaric,NA,NA,NA,HOORAY,2016-11-16T18:54:08Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37802,CLOSED,2016-11-16T18:05:35Z,2017-02-03T05:34:47Z,move to the WIP Rust port of compiler-rt,japaric,NA,NA,NA,HOORAY,2016-11-16T19:54:40Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37815,MERGED,2016-11-16T23:00:27Z,2016-11-16T23:02:48Z,Backport #37691 to beta,alexcrichton,087dd4a811143ebc57263650a593a8318ece66ac,1,Merge pull request #37815 from alexcrichton/beta-next Backport #37691 to beta,THUMBS_UP,2016-11-16T23:02:57Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-11-16T23:22:54Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-16T23:22:57Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-16T23:26:30Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-11-16T23:26:52Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-16T23:26:53Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-11-16T23:27:03Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-16T23:38:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-11-16T23:38:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T02:07:21Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T03:23:50Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T06:44:54Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T08:27:58Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-11-17T08:57:31Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T10:22:00Z,xen0n,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T13:47:54Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-17T21:02:59Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-11-29T22:49:57Z,bluss,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-07T13:01:28Z,palango,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-07T16:37:48Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-12-14T01:05:59Z,adnanademovic,adnanademovic100@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T01:06:05Z,adnanademovic,adnanademovic100@gmail.com https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T04:09:46Z,tikue,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T05:56:02Z,huwsun,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-12-14T05:56:07Z,huwsun,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T07:36:19Z,adaszko,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T18:18:12Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2016-12-14T21:44:37Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2016-12-14T21:44:38Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2017-01-10T22:09:30Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2017-02-02T19:21:34Z,CvX,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2017-02-02T21:29:43Z,cactorium,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2017-02-03T06:20:53Z,creativcoder,NA https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2017-02-03T09:25:49Z,jansegre,jan@hathor.network https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HEART,2017-02-03T09:25:53Z,jansegre,jan@hathor.network https://github.com/rust-lang/rust/pull/37817,MERGED,2016-11-16T23:20:45Z,2016-12-07T16:27:46Z,mk: Switch rustbuild to the default build system ,alexcrichton,0e272de69f4a9c889e5f1a024a88b3e1f60cb6c5,29,mk: Switch rustbuild to the default build system This commit switches the default build system for Rust from the makefiles to rustbuild. The rustbuild build system has been in development for almost a year now and has become quite mature over time. This commit is an implementation of the proposal on [internals] which slates deletion of the makefiles on 2016-01-02. [internals]: https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368 This commit also updates various documentation in `README.md` `CONTRIBUTING.md` `src/bootstrap/README.md` and throughout the source code of rustbuild itself. Closes #37858,HOORAY,2017-03-06T17:03:56Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/37836,MERGED,2016-11-17T18:17:26Z,2016-11-23T17:16:27Z,Clarify the reference's status.,steveklabnik,c5e6dfc4f9ba04b906ceef2a4512d19bf079d8d0,1,Clarify the reference's status. The former wording only gave part of the picture we want to be crystal clear about this.,THUMBS_UP,2016-11-21T16:58:53Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/37855,MERGED,2016-11-18T13:48:10Z,2016-11-20T13:26:12Z,Fix `fmt::Debug` for strings e.g. for Chinese characters,tbu-,d0bb7e194639e270f69059fb440ed7b14d525abd,3,Fix `fmt::Debug` for strings e.g. for Chinese characters The problem occured due to lines like ``` 3400;;Lo;0;L;;;;;N;;;;; 4DB5;;Lo;0;L;;;;;N;;;;; ``` in `UnicodeData.txt` which the script previously interpreted as two characters although it represents the whole range. Fixes #34318.,HEART,2016-11-18T16:38:04Z,sinkuu,NA https://github.com/rust-lang/rust/pull/37855,MERGED,2016-11-18T13:48:10Z,2016-11-20T13:26:12Z,Fix `fmt::Debug` for strings e.g. for Chinese characters,tbu-,d0bb7e194639e270f69059fb440ed7b14d525abd,3,Fix `fmt::Debug` for strings e.g. for Chinese characters The problem occured due to lines like ``` 3400;;Lo;0;L;;;;;N;;;;; 4DB5;;Lo;0;L;;;;;N;;;;; ``` in `UnicodeData.txt` which the script previously interpreted as two characters although it represents the whole range. Fixes #34318.,HEART,2017-02-16T12:17:08Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/37855,MERGED,2016-11-18T13:48:10Z,2016-11-20T13:26:12Z,Fix `fmt::Debug` for strings e.g. for Chinese characters,tbu-,d0bb7e194639e270f69059fb440ed7b14d525abd,3,Fix `fmt::Debug` for strings e.g. for Chinese characters The problem occured due to lines like ``` 3400;;Lo;0;L;;;;;N;;;;; 4DB5;;Lo;0;L;;;;;N;;;;; ``` in `UnicodeData.txt` which the script previously interpreted as two characters although it represents the whole range. Fixes #34318.,HEART,2021-04-19T14:15:29Z,bczhc,bczhc0@126.com https://github.com/rust-lang/rust/pull/37857,MERGED,2016-11-18T16:14:04Z,2016-12-04T06:11:39Z,[LLVM 4.0] Handle new DIFlags enum,shepmaster,757a9cea3f106483901deab928ad4688d098be3c,1,[LLVM 4.0] Support new DIFlags enum,THUMBS_UP,2016-11-18T16:54:47Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37860,MERGED,2016-11-18T16:22:35Z,2017-04-27T05:14:56Z,#37653 support `default impl` for specialization,giannicic,b48eb5e0be2a6e06d9629f770288c46f7bcb326c,7, support `default impl` for specialization `[default] [unsafe] impl` and typecheck,HOORAY,2016-11-28T15:23:09Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37860,MERGED,2016-11-18T16:22:35Z,2017-04-27T05:14:56Z,#37653 support `default impl` for specialization,giannicic,b48eb5e0be2a6e06d9629f770288c46f7bcb326c,7, support `default impl` for specialization `[default] [unsafe] impl` and typecheck,HOORAY,2017-05-03T10:52:41Z,arthurprs,NA https://github.com/rust-lang/rust/pull/37860,MERGED,2016-11-18T16:22:35Z,2017-04-27T05:14:56Z,#37653 support `default impl` for specialization,giannicic,b48eb5e0be2a6e06d9629f770288c46f7bcb326c,7, support `default impl` for specialization `[default] [unsafe] impl` and typecheck,HOORAY,2017-05-03T20:05:59Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/37861,MERGED,2016-11-18T16:22:42Z,2016-11-20T16:36:31Z,[LLVM 4.0] Update AlwaysInliner pass header and constructor,shepmaster,acc9efa5280a41cc040370e0b55a752baeb8b551,1,[LLVM 4.0] Update AlwaysInliner pass header and constructor,THUMBS_UP,2016-11-18T16:42:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37862,MERGED,2016-11-18T16:25:23Z,2016-11-20T23:06:58Z,[LLVM 4.0] Set EH personality when resuming stack unwinding,shepmaster,84415ea1f2a450b0e8896696b8da4accc21b8ef5,1,[LLVM 4.0] Set EH personality when resuming stack unwinding To resume stack unwinding the LLVM `resume` instruction must be used. In order to use this instruction the calling function must have an exception handling personality set. LLVM 4.0 adds a new IR validation check to ensure a personality is always set in these cases. This was introduced in [r277360](https://reviews.llvm.org/rL277360).,THUMBS_UP,2016-11-18T16:42:26Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HOORAY,2016-11-20T00:04:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HOORAY,2016-11-20T15:23:09Z,alexbool,NA https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HEART,2016-11-25T13:47:51Z,fhartwig,florian.j.hartwig@gmail.com https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HEART,2016-11-25T14:06:38Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HOORAY,2016-11-26T01:08:31Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HEART,2016-11-30T08:13:12Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/37888,MERGED,2016-11-19T23:12:53Z,2016-11-21T02:31:53Z,Improve .chars().count(),bluss,5a3aa2f73cbb08c6e41418c5378791fa24a66146,2,str: Improve .chars().count() Use a simpler loop to count the `char` of a string: count the number of non-continuation bytes. Use `count += ` which the compiler understands well and can apply loop optimizations to.,HEART,2018-02-06T23:26:42Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/37890,MERGED,2016-11-20T01:52:36Z,2016-11-24T09:37:52Z,"rustdoc: separate test collection from the main ""clean""-ing pipeline.",eddyb,4be778633073cb3b4a036b8ecc469b2892f12367,6,rustdoc: we can now assume DocContext always has a TyCtxt.,HOORAY,2016-11-20T12:05:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37890,MERGED,2016-11-20T01:52:36Z,2016-11-24T09:37:52Z,"rustdoc: separate test collection from the main ""clean""-ing pipeline.",eddyb,4be778633073cb3b4a036b8ecc469b2892f12367,6,rustdoc: we can now assume DocContext always has a TyCtxt.,HOORAY,2016-12-09T17:54:10Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-21T18:30:59Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-21T19:47:22Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-21T20:38:34Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-21T22:52:36Z,achanda,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-25T02:47:59Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-25T05:37:58Z,ollie27,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-26T17:25:39Z,arthurprs,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-26T23:28:55Z,DirkyJerky,geoffreyiy1@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-11-28T22:47:40Z,HalosGhost,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-11-28T22:47:44Z,HalosGhost,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-11-30T07:27:52Z,achanda,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T01:31:52Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T03:42:56Z,kingoflolz,wangben3@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T03:56:12Z,dpzmick,dpzmick@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-04T04:41:54Z,mjhea0,michael@mherman.org https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T08:01:12Z,nsteenv,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T08:03:43Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T08:31:41Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T09:03:41Z,AnthonyMeehan,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T09:37:42Z,piotr-yuxuan,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-04T09:55:50Z,maierfelix,xilefmai@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T12:32:37Z,mpartel,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T14:14:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-04T17:21:08Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T17:21:19Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-04T20:45:02Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-05T01:21:57Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-05T01:21:58Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-05T07:16:15Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-05T07:16:17Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-05T09:06:04Z,guillaumeguerin,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-05T09:06:08Z,guillaumeguerin,NA https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-08T21:05:22Z,ebfull,ewillbefull@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-08T21:05:24Z,ebfull,ewillbefull@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,THUMBS_UP,2016-12-15T04:55:43Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/37900,CLOSED,2016-11-20T18:43:47Z,2016-12-15T21:55:20Z,i128 and u128 support,est31,NA,NA,NA,HOORAY,2016-12-15T04:55:44Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/37912,MERGED,2016-11-21T11:37:09Z,2016-11-21T20:37:30Z,Restore compatibility with LLVM 3.7 and 3.8,sanxiyn,c45f3dee1010cc15c259f536f736396a5a5f585d,3,Restore compatibility with LLVM 3.7 and 3.8,THUMBS_UP,2016-11-21T11:40:40Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/37912,MERGED,2016-11-21T11:37:09Z,2016-11-21T20:37:30Z,Restore compatibility with LLVM 3.7 and 3.8,sanxiyn,c45f3dee1010cc15c259f536f736396a5a5f585d,3,Restore compatibility with LLVM 3.7 and 3.8,THUMBS_UP,2016-11-21T14:00:17Z,xen0n,NA https://github.com/rust-lang/rust/pull/37912,MERGED,2016-11-21T11:37:09Z,2016-11-21T20:37:30Z,Restore compatibility with LLVM 3.7 and 3.8,sanxiyn,c45f3dee1010cc15c259f536f736396a5a5f585d,3,Restore compatibility with LLVM 3.7 and 3.8,THUMBS_UP,2016-11-21T14:45:03Z,giannicic,gianni.ciccarelli@gmail.com https://github.com/rust-lang/rust/pull/37912,MERGED,2016-11-21T11:37:09Z,2016-11-21T20:37:30Z,Restore compatibility with LLVM 3.7 and 3.8,sanxiyn,c45f3dee1010cc15c259f536f736396a5a5f585d,3,Restore compatibility with LLVM 3.7 and 3.8,THUMBS_UP,2016-11-21T17:44:44Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/37918,MERGED,2016-11-21T18:17:13Z,2016-11-29T18:53:51Z,Separate function bodies from their signatures in HIR,flodiebold,593b2736598f3e08bb7636615e52e1f76a2f2da5,1,librustdoc: Fix compilation after visitor change,HOORAY,2016-11-21T18:55:50Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/37918,MERGED,2016-11-21T18:17:13Z,2016-11-29T18:53:51Z,Separate function bodies from their signatures in HIR,flodiebold,593b2736598f3e08bb7636615e52e1f76a2f2da5,1,librustdoc: Fix compilation after visitor change,HOORAY,2016-11-21T19:33:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/37918,MERGED,2016-11-21T18:17:13Z,2016-11-29T18:53:51Z,Separate function bodies from their signatures in HIR,flodiebold,593b2736598f3e08bb7636615e52e1f76a2f2da5,1,librustdoc: Fix compilation after visitor change,HOORAY,2016-11-21T20:21:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37918,MERGED,2016-11-21T18:17:13Z,2016-11-29T18:53:51Z,Separate function bodies from their signatures in HIR,flodiebold,593b2736598f3e08bb7636615e52e1f76a2f2da5,1,librustdoc: Fix compilation after visitor change,HOORAY,2017-02-04T00:14:40Z,kingoflolz,wangben3@gmail.com https://github.com/rust-lang/rust/pull/37936,MERGED,2016-11-22T20:14:12Z,2016-12-02T11:31:00Z,Fuchsia support for std::process via liblaunchpad.,tedsta,e1b752b2a1bea9c05e89e52632f2f87ee9777062,5,std::process fuchsia support cleanup,THUMBS_UP,2016-11-29T21:17:22Z,brson,NA https://github.com/rust-lang/rust/pull/37951,MERGED,2016-11-23T01:55:53Z,2016-11-25T00:38:56Z,macros: improve resolution performance,jseyfried,cbe478766cb1cafed8341de2e7fffd3b1f104e70,2,macros: improve performance of legacy name resolution.,HEART,2016-11-23T07:48:28Z,retep998,NA https://github.com/rust-lang/rust/pull/37951,MERGED,2016-11-23T01:55:53Z,2016-11-25T00:38:56Z,macros: improve resolution performance,jseyfried,cbe478766cb1cafed8341de2e7fffd3b1f104e70,2,macros: improve performance of legacy name resolution.,HEART,2016-11-23T14:16:32Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37956,MERGED,2016-11-23T11:28:50Z,2016-12-25T00:36:36Z,book: replace example I do not understand,tshepang,d8ee0745f734231edb16441776a60c33dae317c2,1,book: replace example I do not understand,CONFUSED,2016-12-08T06:51:22Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/37973,MERGED,2016-11-24T00:22:08Z,2016-12-06T14:11:52Z,Implement RFC 1717,vadimcn,7d05d1e7f0add9e5151d48d51d92b6fb5885e257,3,Consider only libs that aren't excluded by #[link(cfg=...)],HEART,2016-11-28T22:14:30Z,PJB3005,pieterjan.briers@gmail.com https://github.com/rust-lang/rust/pull/37973,MERGED,2016-11-24T00:22:08Z,2016-12-06T14:11:52Z,Implement RFC 1717,vadimcn,7d05d1e7f0add9e5151d48d51d92b6fb5885e257,3,Consider only libs that aren't excluded by #[link(cfg=...)],HEART,2016-11-29T05:45:40Z,retep998,NA https://github.com/rust-lang/rust/pull/37973,MERGED,2016-11-24T00:22:08Z,2016-12-06T14:11:52Z,Implement RFC 1717,vadimcn,7d05d1e7f0add9e5151d48d51d92b6fb5885e257,3,Consider only libs that aren't excluded by #[link(cfg=...)],HEART,2016-12-02T21:13:39Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/37973,MERGED,2016-11-24T00:22:08Z,2016-12-06T14:11:52Z,Implement RFC 1717,vadimcn,7d05d1e7f0add9e5151d48d51d92b6fb5885e257,3,Consider only libs that aren't excluded by #[link(cfg=...)],HEART,2017-01-07T02:42:09Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/37977,CLOSED,2016-11-24T08:10:11Z,2016-11-24T22:51:18Z,Don't use length in Slice::hash().,nnethercote,NA,NA,NA,HOORAY,2016-11-24T17:27:16Z,arthurprs,NA https://github.com/rust-lang/rust/pull/37994,MERGED,2016-11-25T08:33:23Z,2016-12-06T17:33:28Z,Don't apply msvc link opts for non-opt build,upsuper,257f643ee327252a4cd6dba25f64ac3768adcb45,2,Disable ICF opt of MSVC for non-opt build,THUMBS_UP,2016-11-25T10:44:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,THUMBS_UP,2016-11-25T19:02:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,THUMBS_UP,2016-11-26T07:39:42Z,vvasyliev,NA https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2016-11-26T08:24:57Z,killercup,NA https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2016-11-26T17:23:36Z,arthurprs,NA https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2016-11-27T20:32:30Z,bluss,NA https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2016-11-28T23:00:32Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2017-03-15T04:07:56Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38006,MERGED,2016-11-25T18:58:06Z,2016-12-21T02:48:43Z,Implement `fmt::Debug` for all structures in libstd.,frewsxcv,86fc63e62ddc0a271210b8cc7cc2a6de6874b8f8,31,Implement `fmt::Debug` for all structures in libstd. Part of https://github.com/rust-lang/rust/issues/31869. Also turn on the `missing_debug_implementations` lint at the crate level.,HEART,2017-03-23T21:56:42Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/38034,CLOSED,2016-11-27T19:14:36Z,2016-12-01T05:32:06Z,Optimize signed integer saturating_mul,xfix,NA,NA,NA,THUMBS_UP,2016-11-27T21:35:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38041,CLOSED,2016-11-28T02:28:27Z,2016-12-13T12:03:31Z,impl Sum/Product for more types to avoid overflow/panic,liigo,NA,NA,NA,THUMBS_UP,2016-11-28T03:35:31Z,retep998,NA https://github.com/rust-lang/rust/pull/38041,CLOSED,2016-11-28T02:28:27Z,2016-12-13T12:03:31Z,impl Sum/Product for more types to avoid overflow/panic,liigo,NA,NA,NA,THUMBS_UP,2016-11-28T14:33:05Z,alexbool,NA https://github.com/rust-lang/rust/pull/38056,MERGED,2016-11-28T18:59:25Z,2016-12-03T10:59:09Z,Add String::split_off.,clarfonthey,cbf734f9abe06d240db086f55a0bd4387b77eb94,3,Add String::split_off.,HOORAY,2016-11-29T19:09:14Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38057,MERGED,2016-11-28T19:56:37Z,2016-12-12T03:35:10Z,Display better error messages for E0282,KiChjang,d24028b5a83f9bbad6eca2d276ad7c0f625f6f01,2,Add UI test for missing type parameter,HOORAY,2016-11-28T23:22:27Z,estebank,NA https://github.com/rust-lang/rust/pull/38057,MERGED,2016-11-28T19:56:37Z,2016-12-12T03:35:10Z,Display better error messages for E0282,KiChjang,d24028b5a83f9bbad6eca2d276ad7c0f625f6f01,2,Add UI test for missing type parameter,HOORAY,2016-11-30T19:27:02Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/38057,MERGED,2016-11-28T19:56:37Z,2016-12-12T03:35:10Z,Display better error messages for E0282,KiChjang,d24028b5a83f9bbad6eca2d276ad7c0f625f6f01,2,Add UI test for missing type parameter,HOORAY,2016-12-12T00:24:33Z,sinkuu,NA https://github.com/rust-lang/rust/pull/38065,MERGED,2016-11-29T02:00:40Z,2016-12-04T00:15:20Z,Show `Trait` instead of `` in E0323,estebank,4226930ddf54c4567b2eacc226d4eb897277afab,2,Show `Trait` instead of `` in E0323 For a given file ``` trait Foo { fn bar(&self); } pub struct FooConstForMethod; impl Foo for FooConstForMethod { const bar: u64 = 1; } ``` show ``` error[E0323]: item `bar` is an associated const which doesn't match its trait `Foo` ``` instead of ``` error[E0323]: item `bar` is an associated const which doesn't match its trait `` ```,THUMBS_UP,2016-11-29T08:22:49Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HOORAY,2016-11-29T04:07:56Z,estebank,NA https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HEART,2016-11-29T07:48:05Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HOORAY,2016-11-29T09:37:16Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HEART,2016-11-29T09:37:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",THUMBS_UP,2016-11-29T17:23:35Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HEART,2016-11-29T19:29:05Z,killercup,NA https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",HEART,2016-11-30T09:58:10Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",THUMBS_UP,2017-01-11T06:05:13Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/38066,MERGED,2016-11-29T03:14:58Z,2017-01-04T01:50:43Z,Use more specific panic message for &str slicing errors,bluss,d83fff3b3b9dd0fd6eef862e97f883d171367041,3,"Use more specific panic message for &str slicing errors Separate out of bounds errors from character boundary errors and print more details for character boundary errors. Example: &""abcαβγ""[..4] thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'",THUMBS_UP,2017-01-11T23:20:38Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/38069,MERGED,2016-11-29T07:21:31Z,2017-01-06T02:19:16Z,Fix handling of empty types in patterns.,canndrew,275c19d5b6a0f5eceb93e60ee314e73909a12faf,1,fix doc test for E0001,HEART,2016-12-01T08:46:29Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/38069,MERGED,2016-11-29T07:21:31Z,2017-01-06T02:19:16Z,Fix handling of empty types in patterns.,canndrew,275c19d5b6a0f5eceb93e60ee314e73909a12faf,1,fix doc test for E0001,HOORAY,2017-01-07T01:17:25Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/38072,MERGED,2016-11-29T15:00:34Z,2016-12-19T23:46:06Z,add preliminary support for incremental compilation to rustbuild.py,nikomatsakis,83453bc673ab110a70c214c6c2bce8355ca8cf1a,7,add and document `--incremental` flag along with misc other changes For example: - we now support `-vv` to get very verbose output. - RUSTFLAGS is respected by `x.py` - better error messages for some cases,HOORAY,2016-11-29T22:00:28Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/38079,MERGED,2016-11-30T00:03:16Z,2016-12-03T20:54:11Z,"Add new #[target_feature = ""...""] attribute.",BurntSushi,80ef1dbf2d51d2f2fd039d98a9150d2614e775b0,5,"Add new #[target_feature = ""...""] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = ""+sse4.2""] fn foo() { ... } In particular use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt popcnt and sse4a. Namely lzcnt and popcnt have their own CPUID bits but were introduced with SSE4.",THUMBS_UP,2016-12-02T10:49:47Z,ruuda,NA https://github.com/rust-lang/rust/pull/38079,MERGED,2016-11-30T00:03:16Z,2016-12-03T20:54:11Z,"Add new #[target_feature = ""...""] attribute.",BurntSushi,80ef1dbf2d51d2f2fd039d98a9150d2614e775b0,5,"Add new #[target_feature = ""...""] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = ""+sse4.2""] fn foo() { ... } In particular use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt popcnt and sse4a. Namely lzcnt and popcnt have their own CPUID bits but were introduced with SSE4.",THUMBS_UP,2016-12-03T18:01:45Z,retep998,NA https://github.com/rust-lang/rust/pull/38079,MERGED,2016-11-30T00:03:16Z,2016-12-03T20:54:11Z,"Add new #[target_feature = ""...""] attribute.",BurntSushi,80ef1dbf2d51d2f2fd039d98a9150d2614e775b0,5,"Add new #[target_feature = ""...""] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = ""+sse4.2""] fn foo() { ... } In particular use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt popcnt and sse4a. Namely lzcnt and popcnt have their own CPUID bits but were introduced with SSE4.",THUMBS_UP,2016-12-07T14:40:39Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/38079,MERGED,2016-11-30T00:03:16Z,2016-12-03T20:54:11Z,"Add new #[target_feature = ""...""] attribute.",BurntSushi,80ef1dbf2d51d2f2fd039d98a9150d2614e775b0,5,"Add new #[target_feature = ""...""] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = ""+sse4.2""] fn foo() { ... } In particular use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt popcnt and sse4a. Namely lzcnt and popcnt have their own CPUID bits but were introduced with SSE4.",THUMBS_UP,2016-12-08T07:17:10Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38079,MERGED,2016-11-30T00:03:16Z,2016-12-03T20:54:11Z,"Add new #[target_feature = ""...""] attribute.",BurntSushi,80ef1dbf2d51d2f2fd039d98a9150d2614e775b0,5,"Add new #[target_feature = ""...""] attribute. This commit adds a new attribute that instructs the compiler to emit target specific code for a single function. For example the following function is permitted to use instructions that are part of SSE 4.2: #[target_feature = ""+sse4.2""] fn foo() { ... } In particular use of this attribute does not require setting the -C target-feature or -C target-cpu options on rustc. This attribute does not have any protections built into it. For example nothing stops one from calling the above `foo` function on hosts without SSE 4.2 support. Doing so may result in a SIGILL. This commit also expands the target feature whitelist to include lzcnt popcnt and sse4a. Namely lzcnt and popcnt have their own CPUID bits but were introduced with SSE4.",THUMBS_UP,2018-12-04T22:01:49Z,bluss,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HEART,2016-11-30T09:57:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HEART,2016-11-30T13:15:27Z,bluss,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HEART,2016-11-30T13:42:17Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HOORAY,2016-11-30T20:36:20Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HEART,2016-12-01T16:25:20Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HOORAY,2016-12-02T11:27:07Z,theduke,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HOORAY,2016-12-07T17:45:14Z,tikue,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HEART,2016-12-10T05:19:46Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/38082,MERGED,2016-11-30T02:19:37Z,2016-12-04T15:57:12Z,macros: support invocation paths (e.g. `foo::bar!()`) behind `#![feature(use_extern_macros)]`,jseyfried,ff621ec70eac9c687d0154df5405600669041ab3,5,Add tests.,HOORAY,2016-12-10T05:19:47Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/38099,MERGED,2016-12-01T01:02:59Z,2016-12-21T10:38:14Z,Cast suggestions,GuillaumeGomez,28e2c6aff90b8afef7722c825b381fc24172ac6b,1,Update ui test stderr,HEART,2016-12-01T15:39:19Z,killercup,NA https://github.com/rust-lang/rust/pull/38103,MERGED,2016-12-01T06:11:33Z,2017-02-05T04:00:28Z,note individual lint name in messages set via lint group attribute,zackmdavis,72af42e8974f521e3fed753feac3d0638ad61025,7,note wording: lint implied by lint group not lint group implies lint,HEART,2016-12-01T09:27:22Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38103,MERGED,2016-12-01T06:11:33Z,2017-02-05T04:00:28Z,note individual lint name in messages set via lint group attribute,zackmdavis,72af42e8974f521e3fed753feac3d0638ad61025,7,note wording: lint implied by lint group not lint group implies lint,HEART,2016-12-01T15:39:05Z,killercup,NA https://github.com/rust-lang/rust/pull/38131,MERGED,2016-12-02T17:22:23Z,2016-12-21T02:48:44Z,Add From<[u16; 8]> to Ipv6Addr,clarfonthey,5049ad22ec3fff948ed6e568336e055402b5a246,1,From<[u16; 8]> for Ipv6Addr.,THUMBS_UP,2016-12-02T20:20:56Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38131,MERGED,2016-12-02T17:22:23Z,2016-12-21T02:48:44Z,Add From<[u16; 8]> to Ipv6Addr,clarfonthey,5049ad22ec3fff948ed6e568336e055402b5a246,1,From<[u16; 8]> for Ipv6Addr.,THUMBS_UP,2016-12-09T13:19:19Z,achanda,NA https://github.com/rust-lang/rust/pull/38131,MERGED,2016-12-02T17:22:23Z,2016-12-21T02:48:44Z,Add From<[u16; 8]> to Ipv6Addr,clarfonthey,5049ad22ec3fff948ed6e568336e055402b5a246,1,From<[u16; 8]> for Ipv6Addr.,THUMBS_UP,2016-12-27T07:31:29Z,valarauca,NA https://github.com/rust-lang/rust/pull/38140,MERGED,2016-12-03T02:03:48Z,2016-12-19T04:39:13Z,Require `#[proc_macro_derive]` functions to be `pub`,jseyfried,16052546f78572b7fae060f4b7c454acd0ff5e5e,3,Require `#[proc_macro_derive]` functions to be `pub`.,THUMBS_UP,2016-12-03T02:11:28Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/38140,MERGED,2016-12-03T02:03:48Z,2016-12-19T04:39:13Z,Require `#[proc_macro_derive]` functions to be `pub`,jseyfried,16052546f78572b7fae060f4b7c454acd0ff5e5e,3,Require `#[proc_macro_derive]` functions to be `pub`.,THUMBS_UP,2016-12-06T22:27:54Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/38146,MERGED,2016-12-03T18:56:05Z,2016-12-08T11:23:42Z,fix objc ABI in std::env::args,kali,a1882ca769ed82fa16a06f113f386fa48366c331,1,fix objc ABI in std::env::args,THUMBS_UP,2016-12-03T20:14:56Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/38146,MERGED,2016-12-03T18:56:05Z,2016-12-08T11:23:42Z,fix objc ABI in std::env::args,kali,a1882ca769ed82fa16a06f113f386fa48366c331,1,fix objc ABI in std::env::args,THUMBS_UP,2016-12-04T14:45:59Z,nicolas-cherel,NA https://github.com/rust-lang/rust/pull/38146,MERGED,2016-12-03T18:56:05Z,2016-12-08T11:23:42Z,fix objc ABI in std::env::args,kali,a1882ca769ed82fa16a06f113f386fa48366c331,1,fix objc ABI in std::env::args,THUMBS_UP,2022-06-16T02:33:46Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/38154,MERGED,2016-12-04T12:24:02Z,2016-12-26T16:14:36Z,More systematic error reporting in path resolution,petrochenkov,09aba18e109d7246e3b61c6642747139ee116c48,127,More systematic error reporting in path resolution,HEART,2016-12-05T01:12:44Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38154,MERGED,2016-12-04T12:24:02Z,2016-12-26T16:14:36Z,More systematic error reporting in path resolution,petrochenkov,09aba18e109d7246e3b61c6642747139ee116c48,127,More systematic error reporting in path resolution,HEART,2016-12-05T12:32:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38154,MERGED,2016-12-04T12:24:02Z,2016-12-26T16:14:36Z,More systematic error reporting in path resolution,petrochenkov,09aba18e109d7246e3b61c6642747139ee116c48,127,More systematic error reporting in path resolution,HEART,2016-12-07T13:20:43Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38154,MERGED,2016-12-04T12:24:02Z,2016-12-26T16:14:36Z,More systematic error reporting in path resolution,petrochenkov,09aba18e109d7246e3b61c6642747139ee116c48,127,More systematic error reporting in path resolution,HEART,2017-03-16T19:10:41Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38163,MERGED,2016-12-04T20:56:57Z,2016-12-07T23:01:10Z,reference: fix definition of :tt,durka,dbfcdd45c607762ee8371494ce8a6326086a9596,1,"reference: fix definition of :tt The reference says that $x:tt matches ""either side of the `=>` in macro_rules` which is technically true but completely uninformative. This changes that bullet point to what the book says (a single token or sequence of token trees inside brackets).",THUMBS_UP,2016-12-04T23:09:04Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2016-12-04T23:25:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2016-12-05T07:13:20Z,estebank,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2016-12-05T18:05:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2016-12-30T01:12:34Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2016-12-30T04:29:13Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-01-07T14:08:08Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-01-10T07:51:51Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-01-23T20:29:56Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-02-27T19:37:59Z,binarycrusader,shawn@binarycrusader.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-02-28T13:14:15Z,malbarbo,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-04T00:34:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-04T09:03:11Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-04T20:58:14Z,quodlibetor,quodlibetor@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T06:47:33Z,delacian,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T07:03:44Z,devonhollowood,devonhollowood@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HOORAY,2017-03-08T07:42:16Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T08:27:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T08:32:46Z,mcarton,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T09:32:08Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T09:32:19Z,Machtan,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T12:01:30Z,arthurprs,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HOORAY,2017-03-08T13:19:04Z,potocpav,pavelpotocek@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T14:45:40Z,adaszko,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HOORAY,2017-03-08T16:18:57Z,achanda,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T17:49:43Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T18:08:31Z,Limeth,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T18:16:43Z,crazymerlyn,ankitgoel616@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T18:37:10Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T20:36:39Z,chrish42,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-08T21:24:24Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T02:09:11Z,Ralith,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T06:20:27Z,sunjay,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T08:57:49Z,hoodie,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T12:12:44Z,fuine,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T13:30:06Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-09T15:50:34Z,tioover,tioover@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-03-10T04:17:27Z,friedroman,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HOORAY,2017-04-01T01:42:53Z,jplatte,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-04-12T16:16:43Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HOORAY,2017-04-12T16:16:44Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-04-23T20:39:26Z,anowell,anowell@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-06-08T18:46:01Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-06-09T18:12:11Z,heyLu,lu@papill0n.org https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2017-12-09T20:03:20Z,najamelan,NA https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2020-10-08T13:49:15Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/38165,MERGED,2016-12-04T21:51:37Z,2017-02-27T19:36:03Z,Improve backtrace formating while panicking.,Yamakaky,6398b2078d92c583c4c7eb76312d474042a2c68f,1,This test is too hard to maintain cross-platform,HEART,2020-10-08T18:22:54Z,Tom1380,zacktommy1118@gmail.com https://github.com/rust-lang/rust/pull/38185,MERGED,2016-12-05T23:00:43Z,2016-12-15T12:27:30Z,libtest: add --list option to list tests and benchmarks,jsgf,516d105c0b1c2cbe8a9cd8de6c12236c913b99a3,2,libtest: add --list option to list tests and benchmarks This option lists all the tests and benchmarks a binary provides. By default the listing is sent to stdout but if --logfile is also specified it is written there. If filters are specified they're applied before the output is emitted.,THUMBS_UP,2016-12-05T23:24:13Z,durka,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-06T15:16:46Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-06T15:57:56Z,killercup,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-06T16:35:18Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-06T16:46:41Z,alexbool,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-06T16:48:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-06T17:04:39Z,sfackler,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-06T17:14:25Z,bluss,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-06T17:56:54Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-06T19:17:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-06T19:17:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-06T19:17:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-06T19:46:14Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-06T19:56:11Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-06T19:56:11Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-07T00:37:19Z,sinkuu,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-07T05:33:22Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-07T09:09:04Z,arthurprs,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-07T09:43:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-07T14:02:02Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-07T16:48:09Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-07T20:39:39Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-08T07:25:30Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-09T14:38:58Z,vjeranc,vjeran@crnjak.xyz https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-09T16:29:24Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-09T20:00:33Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-10T20:00:03Z,nuzelac,uzelac.nino@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-10T22:01:45Z,mariokostelac,mario.kostelac@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-13T23:39:24Z,jdub,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T01:57:15Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T03:11:37Z,nullobject,hello@joshbassett.info https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T03:44:08Z,mbarnett,matt@sixtyodd.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T04:01:23Z,FreeFull,jazz2rulez@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T04:09:58Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T04:09:58Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T04:10:02Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T04:26:31Z,tikue,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T06:03:59Z,andrewsuzuki,andrew.b.suzuki@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T06:04:25Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T06:52:52Z,hayd,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T07:11:50Z,kingoflolz,wangben3@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T07:43:02Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T08:25:59Z,mlaskus,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T08:31:32Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T08:52:22Z,nfnty,git@nfnty.se https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T08:56:51Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T08:56:52Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T09:53:21Z,regexident,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T09:59:37Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T09:59:38Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T10:04:43Z,critiqjo,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T10:04:52Z,critiqjo,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T10:21:40Z,musaffa,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T10:22:28Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T10:23:24Z,Thog,contact@mary.zone https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T10:23:25Z,Thog,contact@mary.zone https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T10:23:29Z,Thog,contact@mary.zone https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T12:42:44Z,mo,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T12:42:45Z,mo,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T12:42:47Z,mo,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T12:53:06Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T12:53:07Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T12:53:08Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T13:21:00Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T13:22:54Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T14:05:28Z,DonSheddow,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T14:53:43Z,0x647262,drb@wishalloy.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T14:53:45Z,0x647262,drb@wishalloy.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T14:53:52Z,0x647262,drb@wishalloy.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T14:56:33Z,emk,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:07:13Z,stewartjarod,jarod@jarod.is https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T15:07:18Z,stewartjarod,jarod@jarod.is https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:07:19Z,stewartjarod,jarod@jarod.is https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:09:30Z,javierhonduco,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T15:09:30Z,javierhonduco,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:09:31Z,javierhonduco,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T15:27:21Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:31:09Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T15:31:10Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:31:10Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:31:12Z,jprafael,me@jprafael.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T15:31:41Z,freeman,michel.rasschaert@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:32:13Z,aloisdg,aloisdegouvello@live.fr https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:35:18Z,lujomon,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:47:07Z,mdamien,damien@dam.io https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T15:48:50Z,ye,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:54:57Z,mourner,agafonkin@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:55:17Z,Eibx,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T15:56:11Z,andersonfreitas,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:06:59Z,hrnn,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:08:56Z,jeenalee,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:09:10Z,vladikoff,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:13:54Z,mrecachinas,m.recachinas@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T16:13:56Z,mrecachinas,m.recachinas@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T16:16:03Z,mrecachinas,m.recachinas@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:21:46Z,terciodemelo,github@tercio.com.br https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:22:38Z,fitzgen,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:23:14Z,rishiloyola,rishiloyola98245@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:24:41Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:27:06Z,krzkaczor,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T16:29:42Z,souvik1997,souvik@souvik.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T16:38:12Z,fasouto,fabio@fabiosouto.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:39:24Z,dpbriggs,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T16:39:28Z,dpbriggs,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T16:44:16Z,Awk34,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T16:56:28Z,mxck,mmxckk@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T16:56:29Z,mxck,mmxckk@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T16:56:32Z,mxck,mmxckk@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:01:49Z,orlandotv,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:02:55Z,ankitpokhrel,oss@ankit.pl https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:03:32Z,JadenGeller,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:04:06Z,techaddict,sandeep@techaddict.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:14:42Z,debris,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:16:28Z,edran,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:16:39Z,liusiqi43,me@siqi.fr https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T17:16:40Z,liusiqi43,me@siqi.fr https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:16:43Z,liusiqi43,me@siqi.fr https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:22:41Z,ndbroadbent,git@ndbroadbent.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:22:44Z,ndbroadbent,git@ndbroadbent.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T17:22:45Z,ndbroadbent,git@ndbroadbent.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T17:23:05Z,cpeterso,cpeterson@mozilla.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T17:25:12Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T17:28:35Z,moki,morozov.kirill.moki@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:46:18Z,sindresorhus,sindresorhus@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T17:57:44Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T18:04:02Z,Cldfire,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T18:09:39Z,Cldfire,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T18:29:00Z,bshlgrs,bshlegeris@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T18:29:01Z,bshlgrs,bshlegeris@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T18:29:02Z,bshlgrs,bshlegeris@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T18:31:52Z,nahtnam,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T18:51:15Z,zmanian,zaki@manian.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T18:51:22Z,zmanian,zaki@manian.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T20:16:06Z,yuttie,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T20:16:37Z,yuttie,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T20:26:38Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T20:26:39Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T20:26:42Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T21:20:21Z,danielobrien,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T21:39:04Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T21:39:06Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T21:39:07Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T22:09:52Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T22:09:52Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T22:09:53Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T22:31:37Z,hlian,hi@haolian.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T22:43:38Z,johnp,johannespfrang@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-14T22:43:41Z,johnp,johannespfrang@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T22:43:45Z,johnp,johannespfrang@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T23:04:10Z,Paul-E,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T23:10:59Z,aaronabramov,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-14T23:29:20Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-14T23:55:31Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T00:21:20Z,muminoff,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T00:48:39Z,wting,io at williamting.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T02:02:38Z,Rahul-Raviprasad,rahul.raviprasad@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T02:27:17Z,wong2,wonderfuly@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T02:38:02Z,SteVwonder,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T04:04:06Z,alexkehayias,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-15T04:06:07Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-15T04:09:52Z,max-sixty,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T06:24:40Z,mklf,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-15T07:50:23Z,blaidlee,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-15T10:09:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T12:54:02Z,hastebrot,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T14:05:24Z,m13m,maqbool@maqbool.net https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-15T16:24:03Z,cuonglm,cuong.manhle.vn@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-16T23:50:20Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-16T23:50:21Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2016-12-16T23:50:22Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2016-12-20T07:23:19Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2016-12-21T09:48:25Z,markuskobler,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-01T21:09:50Z,Enet4,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-01T21:49:42Z,radare,pancake@nopcode.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-02-01T21:49:43Z,radare,pancake@nopcode.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-01T21:49:44Z,radare,pancake@nopcode.org https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-01T22:22:34Z,oleavr,oleavr@nowsecure.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-02-01T22:22:35Z,oleavr,oleavr@nowsecure.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-01T22:22:35Z,oleavr,oleavr@nowsecure.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-02-02T21:10:42Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-02T21:15:01Z,greyblake,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-02T21:15:02Z,greyblake,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-02-02T21:15:02Z,greyblake,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-03T04:00:30Z,giangstrider,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-03T08:16:10Z,jaseemabid,jaseemabid@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-02-03T10:22:57Z,jtepe,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-03T15:37:58Z,kaznovac,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-02-08T20:58:14Z,nosideeffects,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-04-05T21:24:03Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-04-05T21:24:09Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-04-05T21:24:10Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-04-09T08:49:08Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-04-09T08:49:11Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-04-09T08:49:13Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-06-06T14:34:13Z,PerfectLaugh,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-06-06T14:34:14Z,PerfectLaugh,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-06-06T14:34:17Z,PerfectLaugh,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2017-06-21T10:29:54Z,positiveblue,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-06-21T10:29:55Z,positiveblue,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-08-07T08:28:34Z,WarpspeedSCP,warpspeedscp@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-08-07T08:28:42Z,WarpspeedSCP,warpspeedscp@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-11-23T15:11:39Z,progaddict,ryndin.as@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2017-12-13T04:16:32Z,aj-jaswanth,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2017-12-13T04:16:34Z,aj-jaswanth,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2018-07-01T21:42:51Z,kwilczynski,kw@linux.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2018-07-01T23:07:28Z,lwouis,lwouis@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2018-07-02T06:11:09Z,wilk,wilk3ert@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2018-07-02T06:11:10Z,wilk,wilk3ert@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2018-07-02T06:11:11Z,wilk,wilk3ert@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2018-11-14T19:18:23Z,eemj,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2019-04-30T03:26:26Z,YodaEmbedding,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-04-03T19:11:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2020-04-03T19:11:15Z,Virgiel,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2020-04-03T19:11:16Z,Virgiel,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-04-03T22:22:37Z,Phridge,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-04-04T08:28:43Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-04-04T08:44:09Z,SteveHere,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2020-04-05T13:34:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2020-04-05T13:34:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-04-17T04:54:29Z,jon-chuang,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-05-07T22:44:27Z,GopherJ,cocathecafe@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-05-31T01:02:50Z,Avi-D-coder,avi.the.coder@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-07-10T11:39:15Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2020-11-10T10:10:26Z,chrisprobst,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2020-11-10T10:10:26Z,chrisprobst,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2020-11-10T10:10:27Z,chrisprobst,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2021-01-14T22:26:51Z,sjackman,sjackman@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HOORAY,2021-01-14T22:26:52Z,sjackman,sjackman@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,HEART,2021-01-14T22:26:53Z,sjackman,sjackman@gmail.com https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2022-03-06T05:45:21Z,QMHTMY,NA https://github.com/rust-lang/rust/pull/38192,MERGED,2016-12-06T12:19:30Z,2016-12-09T12:47:41Z,Implement a faster sort algorithm,NA,NA,NA,NA,THUMBS_UP,2022-03-16T22:27:11Z,alichraghi,NA https://github.com/rust-lang/rust/pull/38217,MERGED,2016-12-07T10:06:37Z,2016-12-10T07:30:45Z,add a -Z flag to guarantee that MIR is generated for all functions,oli-obk,d74d15345cab54860a6e8cf19021372665ce0577,4,move the check for instantiation from metadata encoding to the actual decision site before it was assumed that anything that had a MIR was fair game for local instatiation,THUMBS_UP,2016-12-07T19:43:32Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38225,MERGED,2016-12-07T17:44:09Z,2016-12-07T23:01:14Z,Update book/ffi to use catch_unwind,Cobrand,614b74c24bb80e17230e58a74ef5a4725972f84a,1,Update book/ffi to use catch_unwind r? @GuillaumeGomez The doc mentioned to spawn a new thread instead of using catch_unwind which has been the recommended way to catch panics for foreign function interfaces for a few releases now.,THUMBS_UP,2016-12-07T20:07:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38274,MERGED,2016-12-10T00:12:09Z,2016-12-27T02:13:17Z,Ctrl-Z returns from Stdin.read() when reading from the console on Windows,elahn,f9bca00469f4e6826c79638a5058c838ab4c1925,2,Ctrl-Z returns from Stdin.read() when reading from the console on Windows. Fixes #19914. Fixes read() read_to_string() read_to_end() etc.,HOORAY,2016-12-27T14:42:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/38295,MERGED,2016-12-11T09:30:56Z,2016-12-14T20:35:18Z,[LLVM 4.0] Update LLVM global variable debug info API for 4.0,dylanmckay,e080804f72fe937ed36cd6656f5f119959529945,1,Update LLVM global variable debug info API for 4.0 This teaches Rust about an LLVM 4.0 API change for creating debug info for global variables. This change was made in upstream LLVM patch https://reviews.llvm.org/D20147 This is almost 1:1 copy of how clang did it in http://reviews.llvm.org/D20415,THUMBS_UP,2016-12-14T20:43:32Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38297,MERGED,2016-12-11T11:26:44Z,2016-12-25T00:36:38Z,Advertise Vec in LinkedList docs,matklad,71de148649bd9d2548b55e5d52bd0c8b38ffec44,1,Advertise Vec in LinkedList docs,THUMBS_UP,2016-12-11T12:14:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38302,MERGED,2016-12-11T17:42:15Z,2016-12-21T13:59:19Z,Cleanup old trans,Mark-Simulacrum,0013d4cdf61a61abab79789c9ad5320bd1e2d56a,1,Fix rebase errors.,HEART,2016-12-11T18:15:04Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38302,MERGED,2016-12-11T17:42:15Z,2016-12-21T13:59:19Z,Cleanup old trans,Mark-Simulacrum,0013d4cdf61a61abab79789c9ad5320bd1e2d56a,1,Fix rebase errors.,HEART,2016-12-11T19:02:53Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38302,MERGED,2016-12-11T17:42:15Z,2016-12-21T13:59:19Z,Cleanup old trans,Mark-Simulacrum,0013d4cdf61a61abab79789c9ad5320bd1e2d56a,1,Fix rebase errors.,HEART,2016-12-11T19:15:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/38302,MERGED,2016-12-11T17:42:15Z,2016-12-21T13:59:19Z,Cleanup old trans,Mark-Simulacrum,0013d4cdf61a61abab79789c9ad5320bd1e2d56a,1,Fix rebase errors.,HEART,2016-12-20T14:40:49Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/38302,MERGED,2016-12-11T17:42:15Z,2016-12-21T13:59:19Z,Cleanup old trans,Mark-Simulacrum,0013d4cdf61a61abab79789c9ad5320bd1e2d56a,1,Fix rebase errors.,HEART,2016-12-21T03:48:44Z,est31,NA https://github.com/rust-lang/rust/pull/38304,MERGED,2016-12-11T17:54:32Z,2017-01-06T19:22:41Z,Deprecate TcpListener::set_only_v6,sfackler,eb5e9ab145b8d7c0ecb9a0658b58238f1af6b01e,1,Deprecate TcpListener::set_only_v6 This was supposed to have been removed in #33124 but snuck through :(,THUMBS_UP,2016-12-11T19:56:54Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38327,MERGED,2016-12-12T20:36:07Z,2017-01-07T10:59:25Z,Impl From for IpAddr.,Yamakaky,2d365c6b7ae0ed76d85e6dccaccc5782728e5d0b,2,Impl From for IpAddr and SocketAddr. Fixes https://github.com/rust-lang/rfcs/issues/1816.,THUMBS_UP,2016-12-12T21:50:14Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/38327,MERGED,2016-12-12T20:36:07Z,2017-01-07T10:59:25Z,Impl From for IpAddr.,Yamakaky,2d365c6b7ae0ed76d85e6dccaccc5782728e5d0b,2,Impl From for IpAddr and SocketAddr. Fixes https://github.com/rust-lang/rfcs/issues/1816.,THUMBS_UP,2016-12-14T23:29:13Z,achanda,NA https://github.com/rust-lang/rust/pull/38327,MERGED,2016-12-12T20:36:07Z,2017-01-07T10:59:25Z,Impl From for IpAddr.,Yamakaky,2d365c6b7ae0ed76d85e6dccaccc5782728e5d0b,2,Impl From for IpAddr and SocketAddr. Fixes https://github.com/rust-lang/rfcs/issues/1816.,THUMBS_UP,2017-01-11T23:23:34Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/38331,MERGED,2016-12-12T22:41:58Z,2016-12-15T18:09:02Z,rustbuild: Add cli option --keep-stage,bluss,0e01427bba6e4f5ceef4531d239c5bbc6c5d8082,1,rustbuild: Add small description of --keep-stage,THUMBS_UP,2016-12-12T22:46:04Z,est31,NA https://github.com/rust-lang/rust/pull/38331,MERGED,2016-12-12T22:41:58Z,2016-12-15T18:09:02Z,rustbuild: Add cli option --keep-stage,bluss,0e01427bba6e4f5ceef4531d239c5bbc6c5d8082,1,rustbuild: Add small description of --keep-stage,HEART,2016-12-12T22:50:27Z,est31,NA https://github.com/rust-lang/rust/pull/38331,MERGED,2016-12-12T22:41:58Z,2016-12-15T18:09:02Z,rustbuild: Add cli option --keep-stage,bluss,0e01427bba6e4f5ceef4531d239c5bbc6c5d8082,1,rustbuild: Add small description of --keep-stage,THUMBS_UP,2016-12-15T03:57:46Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HOORAY,2016-12-13T09:43:59Z,bluss,NA https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",THUMBS_UP,2016-12-13T15:48:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HEART,2016-12-13T16:21:45Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",THUMBS_UP,2016-12-13T20:48:33Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HEART,2016-12-13T22:17:35Z,estebank,NA https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HOORAY,2016-12-13T22:53:17Z,mzji,NA https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HOORAY,2016-12-14T10:34:18Z,dsvensson,dsvensson@gmail.com https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",THUMBS_UP,2016-12-14T17:27:18Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HOORAY,2016-12-14T17:27:19Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/38340,MERGED,2016-12-13T08:17:33Z,2016-12-14T14:35:47Z,Fix travis builds,alexcrichton,5e991e0afb403fab6edfac096ecd5bb0190449ad,12,"Fix travis builds After reading some articles [1] [2] yesterday about Docker and the ""init"" process I got to thinking about the problems that we've been seeing on Travis. The basic problem is that a Linux system may need an ""init"" process to work properly when processes become zombies. Docker by default doesn't handle this and the root process typically isn't an init process so this can occasionally cause quite a few problems. We've been seeing spurious errors on Travis inside containers which look like OOM and such but my guess is that zombie processes were being reparented to the top-level shell. The shell didn't expect the zombies and then behaved very strangely. This commit fixes these problems by using Yelp's ""dumb-init"" program [2] as the init process in all of our containers. This ensures that there's a valid init ready to reap children when they're reparented which our test suite apparently generates a bunch of throughout the tests and such. [1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ [2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html",HEART,2016-12-14T17:27:19Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/38351,MERGED,2016-12-13T16:41:50Z,2016-12-14T17:36:07Z,Document --test-args for rustbuild,sanxiyn,8ed52ed27d87ed4f17217e3daac49a858a2daa1f,3,Document --test-args for rustbuild,THUMBS_UP,2016-12-13T16:59:02Z,est31,NA https://github.com/rust-lang/rust/pull/38359,MERGED,2016-12-14T01:28:58Z,2016-12-16T10:26:23Z,rustbuild: Add sccache support,alexcrichton,96a5fc76dcce1bd6669a9e288721ee6aad521096,21,rustbuild: Add sccache support This commit adds support for sccache a ccache-like compiler which works on MSVC and stores results into an S3 bucket. This also switches over all Travis and AppVeyor automation to using sccache to ensure a shared and unified cache over time which can be shared across builders. The support for sccache manifests as a new `--enable-sccache` option which instructs us to configure LLVM differently to use a 'sccache' binary instead of a 'ccache' binary. All docker images for Travis builds are updated to download Mozilla's tooltool builds of sccache onto various containers and systems. Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of our ccache goodies.,HOORAY,2016-12-16T14:46:24Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/38366,CLOSED,2016-12-14T17:52:03Z,2016-12-16T00:09:21Z,Redox x86_64 target support,jackpot51,NA,NA,NA,HEART,2016-12-14T18:00:51Z,est31,NA https://github.com/rust-lang/rust/pull/38366,CLOSED,2016-12-14T17:52:03Z,2016-12-16T00:09:21Z,Redox x86_64 target support,jackpot51,NA,NA,NA,HOORAY,2016-12-14T18:31:53Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38368,MERGED,2016-12-14T19:00:33Z,2017-02-16T23:22:12Z,Adaptive hashmap implementation,arthurprs,57940d063c26ccabc7038f2fe9cf23faf9ee1ab6,1,Resize hashmap when long probes are detected,HEART,2017-02-22T18:21:21Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38369,MERGED,2016-12-14T20:42:24Z,2016-12-18T22:06:34Z,Library stabilizations/deprecations for 1.15 release,aturon,9a5cef4de51c1c90fb2d05b0c7e6feb9cf0224d6,16,Address fallout,THUMBS_UP,2016-12-14T23:11:03Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/38369,MERGED,2016-12-14T20:42:24Z,2016-12-18T22:06:34Z,Library stabilizations/deprecations for 1.15 release,aturon,9a5cef4de51c1c90fb2d05b0c7e6feb9cf0224d6,16,Address fallout,THUMBS_UP,2016-12-15T11:41:06Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38369,MERGED,2016-12-14T20:42:24Z,2016-12-18T22:06:34Z,Library stabilizations/deprecations for 1.15 release,aturon,9a5cef4de51c1c90fb2d05b0c7e6feb9cf0224d6,16,Address fallout,HOORAY,2016-12-17T04:01:26Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/38369,MERGED,2016-12-14T20:42:24Z,2016-12-18T22:06:34Z,Library stabilizations/deprecations for 1.15 release,aturon,9a5cef4de51c1c90fb2d05b0c7e6feb9cf0224d6,16,Address fallout,HOORAY,2016-12-21T09:31:51Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/38369,MERGED,2016-12-14T20:42:24Z,2016-12-18T22:06:34Z,Library stabilizations/deprecations for 1.15 release,aturon,9a5cef4de51c1c90fb2d05b0c7e6feb9cf0224d6,16,Address fallout,HOORAY,2017-01-29T18:53:36Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/38375,MERGED,2016-12-14T23:19:49Z,2016-12-15T06:23:18Z,Fix regression in resolution of primitive types,petrochenkov,0157e6c0588902967c9606e31fefebfd0cf5d7fd,2,Fix regression in resolution of primitive types,THUMBS_UP,2016-12-22T03:27:39Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38375,MERGED,2016-12-14T23:19:49Z,2016-12-15T06:23:18Z,Fix regression in resolution of primitive types,petrochenkov,0157e6c0588902967c9606e31fefebfd0cf5d7fd,2,Fix regression in resolution of primitive types,HOORAY,2016-12-22T03:27:41Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38401,MERGED,2016-12-15T23:38:33Z,2016-12-23T11:56:45Z,Redox Cross Compilation,jackpot51,4dcb86767111149bcd233d6ac5c782d345d1e10b,1,Convert fam to Symbol,THUMBS_UP,2016-12-28T02:35:09Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/38401,MERGED,2016-12-15T23:38:33Z,2016-12-23T11:56:45Z,Redox Cross Compilation,jackpot51,4dcb86767111149bcd233d6ac5c782d345d1e10b,1,Convert fam to Symbol,HOORAY,2016-12-28T02:35:14Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/38401,MERGED,2016-12-15T23:38:33Z,2016-12-23T11:56:45Z,Redox Cross Compilation,jackpot51,4dcb86767111149bcd233d6ac5c782d345d1e10b,1,Convert fam to Symbol,THUMBS_UP,2017-03-20T17:29:41Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/38401,MERGED,2016-12-15T23:38:33Z,2016-12-23T11:56:45Z,Redox Cross Compilation,jackpot51,4dcb86767111149bcd233d6ac5c782d345d1e10b,1,Convert fam to Symbol,HOORAY,2020-07-19T22:48:35Z,aaronjanse,aaron@ajanse.me https://github.com/rust-lang/rust/pull/38414,MERGED,2016-12-16T20:05:24Z,2017-01-04T19:26:10Z,Rustdoc: disambiguate Implementors when the type name is not unique,estebank,346a44211087a36de91877545ea28e9af501db6c,2,use same param name across methods,THUMBS_UP,2016-12-16T20:08:14Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38414,MERGED,2016-12-16T20:05:24Z,2017-01-04T19:26:10Z,Rustdoc: disambiguate Implementors when the type name is not unique,estebank,346a44211087a36de91877545ea28e9af501db6c,2,use same param name across methods,HEART,2016-12-16T23:09:51Z,bluss,NA https://github.com/rust-lang/rust/pull/38414,MERGED,2016-12-16T20:05:24Z,2017-01-04T19:26:10Z,Rustdoc: disambiguate Implementors when the type name is not unique,estebank,346a44211087a36de91877545ea28e9af501db6c,2,use same param name across methods,HEART,2017-01-18T15:31:20Z,quodlibetor,quodlibetor@gmail.com https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",HEART,2016-12-17T04:00:35Z,retep998,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",THUMBS_UP,2016-12-17T04:00:37Z,retep998,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",THUMBS_UP,2016-12-17T04:02:53Z,mzji,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",HOORAY,2016-12-17T04:02:59Z,mzji,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",THUMBS_UP,2016-12-22T12:06:27Z,Jascha-N,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",HOORAY,2017-01-20T05:44:02Z,retep998,NA https://github.com/rust-lang/rust/pull/38426,MERGED,2016-12-17T03:53:18Z,2017-02-04T23:54:37Z,"Implement kind=""static-nobundle"" (RFC 1717)",vadimcn,7504897e6b4b1121191bc6612bcbcce1f70f5f06,8,"Don't link ""nobundle"" libs which had already been included in upstream crate.",THUMBS_UP,2018-06-16T02:47:19Z,rivy,NA https://github.com/rust-lang/rust/pull/38451,MERGED,2016-12-18T11:35:48Z,2016-12-21T02:48:51Z,adaptation to rustbuild for openbsd,semarie,2c39ee12a99f9548a5e379e8bcea4f7923028fee,1,OpenBSD has two stdc++ libraries: use the newer stdc++ is from base and is an old library (GCC 4.2) estdc++ is from ports and is a recent library (GCC 4.9 currently) as LLVM requires the newer version use it if under OpenBSD.,HEART,2017-01-21T05:27:22Z,estebank,NA https://github.com/rust-lang/rust/pull/38465,MERGED,2016-12-19T04:51:37Z,2017-01-19T21:14:33Z,calling convention for MSP430 interrupts,japaric,e928c7584769fe4d445862d05928486e49d5b505,1,add cfail test for the new feature gate,HOORAY,2017-01-20T06:11:35Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/38469,MERGED,2016-12-19T15:56:41Z,2017-01-07T13:02:27Z,Allow `writeln!` without arguments in symmetry with `println!`,tbu-,a0b346a34936c6ed88ad9680069c0300b0c068d8,2,Allow `writeln!` without arguments in symmetry with `println!`,THUMBS_UP,2016-12-19T22:16:35Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-20T10:34:09Z,achanda,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-20T10:35:01Z,achanda,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-20T17:37:04Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-20T17:37:05Z,matthew-piziak,matthew.piziak@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-21T01:42:23Z,bheesham,me@bheesham.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-21T01:42:24Z,bheesham,me@bheesham.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-21T13:33:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-21T13:33:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-21T20:40:57Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-23T23:50:05Z,Nudin,michi4@schoenitzer.de https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-25T21:22:10Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2016-12-28T16:34:38Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-28T22:41:45Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2016-12-31T21:23:42Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2017-01-01T05:16:10Z,ncaq,ncaq@ncaq.net https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2017-01-01T14:00:26Z,Limeth,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2017-01-01T18:47:48Z,adjivas,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2017-01-02T11:13:42Z,quarkcool,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2017-01-06T04:18:06Z,green-coder,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2017-01-06T08:51:58Z,nalply,NA https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2017-01-19T01:11:11Z,alexcrichton,alex@alexcrichton.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,THUMBS_UP,2020-10-15T03:59:14Z,aaronfranke,arnfranke@yahoo.com https://github.com/rust-lang/rust/pull/38482,MERGED,2016-12-20T01:22:45Z,2016-12-31T21:00:42Z,i128 and u128 support,est31,29e01af6a68817a12c1fc5fa04c483d2200c3cbb,2,Fix iabs and add some more tests,HOORAY,2020-10-15T03:59:15Z,aaronfranke,arnfranke@yahoo.com https://github.com/rust-lang/rust/pull/38496,MERGED,2016-12-20T17:39:19Z,2016-12-21T02:48:54Z,rustbuild: Deny and fix warnings,alexcrichton,57cf2ab31cb443721d0481ac5989dfdd17a1a251,4,rustbuild: Deny and fix warnings Turned out this lint uncovered an actual bug! Closes #38484,HEART,2016-12-20T18:19:24Z,est31,NA https://github.com/rust-lang/rust/pull/38506,MERGED,2016-12-21T02:53:19Z,2016-12-21T06:46:34Z,mk: Fix compile with makefiles,alexcrichton,839b6961b0e4c5ee3803e23b46788ac414944aee,3,mk: Fix compile with makefiles A tweak was made to dependencies in #38451 but the makefiles weren't updated to accompany this. Instead of trying to integerate the `build_helper` crate into the makefiles (which currently isn't present) this commit takes the approach of just duplicating the required logic which should be small enough for now.,HEART,2017-01-21T05:27:27Z,estebank,NA https://github.com/rust-lang/rust/pull/38533,MERGED,2016-12-22T06:09:45Z,2016-12-23T21:36:54Z,Allow legacy custom derive authors to disable warnings in downstream crates,jseyfried,c12fc66a9d643a6942d0bf4175d1a046e8d808de,7,Allow legacy custom derive authors to disable warnings in downstream crates.,HOORAY,2016-12-22T06:10:51Z,SergioBenitez,NA https://github.com/rust-lang/rust/pull/38533,MERGED,2016-12-22T06:09:45Z,2016-12-23T21:36:54Z,Allow legacy custom derive authors to disable warnings in downstream crates,jseyfried,c12fc66a9d643a6942d0bf4175d1a046e8d808de,7,Allow legacy custom derive authors to disable warnings in downstream crates.,THUMBS_UP,2016-12-23T21:01:08Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38536,MERGED,2016-12-22T08:06:37Z,2016-12-26T13:32:05Z,Fix fs tests on Windows systems with non-english locales.,retep998,23cfcddd775e5e4b3888033b65d90a0f6c4c3506,1,Fix fs tests on Windows systems with non-english locales.,THUMBS_UP,2016-12-22T08:17:53Z,est31,NA https://github.com/rust-lang/rust/pull/38542,MERGED,2016-12-22T12:26:38Z,2016-12-26T20:09:58Z,Fix fastcall not applying inreg attributes to arguments,YaLTeR,5e2cea9a4e270544d48ee7634ef3a7b6f67163a4,2,Cleaned up the code and added tests.,THUMBS_UP,2016-12-22T19:48:46Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/38551,MERGED,2016-12-22T17:26:43Z,2017-01-07T15:03:13Z,Implement placement-in protocol for `Vec`,aidanhs,75fe66e349d8ec4393562a775ce457c61bf9e11b,4,Implement placement-in protocol for `Vec`,THUMBS_UP,2016-12-22T17:40:25Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/38551,MERGED,2016-12-22T17:26:43Z,2017-01-07T15:03:13Z,Implement placement-in protocol for `Vec`,aidanhs,75fe66e349d8ec4393562a775ce457c61bf9e11b,4,Implement placement-in protocol for `Vec`,THUMBS_UP,2016-12-22T17:51:33Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38551,MERGED,2016-12-22T17:26:43Z,2017-01-07T15:03:13Z,Implement placement-in protocol for `Vec`,aidanhs,75fe66e349d8ec4393562a775ce457c61bf9e11b,4,Implement placement-in protocol for `Vec`,THUMBS_UP,2016-12-22T17:54:03Z,alexbool,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-22T22:09:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-23T00:55:31Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T00:58:25Z,TheMarketka,marketa@lisova.cz https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-23T00:58:26Z,TheMarketka,marketa@lisova.cz https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T01:01:02Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-23T01:28:44Z,Cldfire,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T05:32:42Z,abronan,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-23T05:32:45Z,abronan,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-23T05:56:40Z,mystal,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T09:54:25Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T11:08:38Z,regexident,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-23T18:50:14Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2016-12-25T14:19:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2016-12-25T14:35:26Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2017-01-04T20:21:28Z,vbarrielle,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2017-01-04T20:55:10Z,Diggsey,NA https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HOORAY,2017-01-05T04:39:46Z,iblis17,iblis.dif01@nctu.edu.tw https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2017-01-05T04:39:47Z,iblis17,iblis.dif01@nctu.edu.tw https://github.com/rust-lang/rust/pull/38559,MERGED,2016-12-22T21:33:53Z,2016-12-30T09:39:52Z,PTX support take 2,japaric,aac5ff76649a2257e2c04f1d44cf11e999a39442,1,fix ui test,HEART,2017-01-05T09:57:33Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/38562,MERGED,2016-12-22T22:34:50Z,2016-12-23T06:22:46Z,Delete the llvm submodule lockfile when configuring on the bots,brson,7d428b71dec973d6f53e16d18af7e2751321aafe,1,Delete the llvm submodule lockfile when configuring on the bots This should fix the periodic error that .git/modules/src/llvm/index.lock exists on the mac slaves.,THUMBS_UP,2016-12-22T22:42:06Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38566,MERGED,2016-12-23T02:29:43Z,2016-12-25T17:41:09Z,Fix bug in import resolution,jseyfried,31d9cc3833a30b0cd4c1554102402af68eebeeef,3,Fix import resolution bug and fold all idents in the AST.,HOORAY,2016-12-23T04:19:52Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T11:34:08Z,est31,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T12:27:20Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T13:17:20Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T14:33:16Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T15:02:34Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T15:24:45Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T22:17:11Z,bluss,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-23T23:28:18Z,achanda,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-24T01:23:31Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_UP,2016-12-24T07:22:56Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-24T08:30:53Z,hban,NA https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-25T11:10:00Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,CONFUSED,2016-12-25T13:55:30Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/38573,CLOSED,2016-12-23T11:24:21Z,2017-01-05T05:51:40Z,Implement Add for Vec,michaelsproul,NA,NA,NA,THUMBS_DOWN,2016-12-27T12:50:07Z,troplin,NA https://github.com/rust-lang/rust/pull/38577,MERGED,2016-12-23T16:44:16Z,2016-12-27T17:05:17Z,Add Debug to OpenOptions and DirBuilder,jackpot51,9f9489b976b137cbff65b11f4e0a55199c4a1970,1,Cloexec when creating directories,THUMBS_UP,2016-12-23T19:32:12Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38580,MERGED,2016-12-23T20:11:49Z,2017-01-11T01:32:35Z,Implement `iter::Sum` and `iter::Product` for `Result`,shepmaster,23715d344de0377624be95b48830582594aed7ff,2,Implement `iter::Sum` and `iter::Product` for `Result` This introduces a private iterator adapter `ResultShunt` which allows treating an iterator of `Result` as an iterator of `T`.,THUMBS_UP,2017-01-10T13:25:02Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/38580,MERGED,2016-12-23T20:11:49Z,2017-01-11T01:32:35Z,Implement `iter::Sum` and `iter::Product` for `Result`,shepmaster,23715d344de0377624be95b48830582594aed7ff,2,Implement `iter::Sum` and `iter::Product` for `Result` This introduces a private iterator adapter `ResultShunt` which allows treating an iterator of `Result` as an iterator of `T`.,THUMBS_UP,2017-02-22T16:14:14Z,Enet4,NA https://github.com/rust-lang/rust/pull/38583,CLOSED,2016-12-23T23:02:23Z,2017-01-17T21:22:41Z,[WIP] rustbuild: Build jemalloc and libbacktrace only once,petrochenkov,NA,NA,NA,THUMBS_UP,2016-12-24T00:54:42Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38601,MERGED,2016-12-25T17:10:22Z,2016-12-31T02:51:14Z,Partial fix for #38489.,schulzch,14994ac6b67cdaff1692f836e3495a75f4f7d71b,1,Use cfg!() to get type checking everywhere.,HEART,2016-12-30T23:23:34Z,brson,NA https://github.com/rust-lang/rust/pull/38608,CLOSED,2016-12-26T02:42:53Z,2017-06-01T15:57:23Z,Build instruction profiler runtime as part of compiler-rt,whitequark,NA,NA,NA,HOORAY,2017-05-01T09:30:35Z,kennytm,NA https://github.com/rust-lang/rust/pull/38608,CLOSED,2016-12-26T02:42:53Z,2017-06-01T15:57:23Z,Build instruction profiler runtime as part of compiler-rt,whitequark,NA,NA,NA,HOORAY,2017-05-02T03:40:53Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38608,CLOSED,2016-12-26T02:42:53Z,2017-06-01T15:57:23Z,Build instruction profiler runtime as part of compiler-rt,whitequark,NA,NA,NA,HOORAY,2017-05-23T15:37:03Z,deweerdt,NA https://github.com/rust-lang/rust/pull/38617,MERGED,2016-12-26T18:47:32Z,2017-01-28T05:18:56Z,Detect double reference when applying binary op,pnkfelix,b8669dff556a03ca37b39cbb81be65c94d24defe,3,Ensure type is copyable before emitting note suggesting adding manual deref. drive-by: fix merge conflict; fix test expected error output post rebase.,HOORAY,2016-12-26T19:17:54Z,estebank,NA https://github.com/rust-lang/rust/pull/38617,MERGED,2016-12-26T18:47:32Z,2017-01-28T05:18:56Z,Detect double reference when applying binary op,pnkfelix,b8669dff556a03ca37b39cbb81be65c94d24defe,3,Ensure type is copyable before emitting note suggesting adding manual deref. drive-by: fix merge conflict; fix test expected error output post rebase.,HOORAY,2017-01-31T17:23:53Z,Havvy,NA https://github.com/rust-lang/rust/pull/38628,MERGED,2016-12-27T01:27:01Z,2016-12-30T09:39:55Z,And suddenly a german word :O,kellerkindt,20abf050e7f5698cd1012de00295ec805143735a,1,"And suddenly a german word :O ""verboten"" is german for ""forbidden""",THUMBS_DOWN,2016-12-27T20:21:59Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/38628,MERGED,2016-12-27T01:27:01Z,2016-12-30T09:39:55Z,And suddenly a german word :O,kellerkindt,20abf050e7f5698cd1012de00295ec805143735a,1,"And suddenly a german word :O ""verboten"" is german for ""forbidden""",THUMBS_DOWN,2016-12-30T14:14:13Z,ClaireNeveu,NA https://github.com/rust-lang/rust/pull/38628,MERGED,2016-12-27T01:27:01Z,2016-12-30T09:39:55Z,And suddenly a german word :O,kellerkindt,20abf050e7f5698cd1012de00295ec805143735a,1,"And suddenly a german word :O ""verboten"" is german for ""forbidden""",LAUGH,2017-12-31T10:04:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2016-12-27T21:38:23Z,brson,NA https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2016-12-28T22:57:17Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2017-01-02T15:01:59Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2017-01-04T20:33:49Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2017-01-05T17:11:12Z,coreh,NA https://github.com/rust-lang/rust/pull/38631,MERGED,2016-12-27T06:54:43Z,2016-12-30T09:39:55Z,rustbuild: Compile rustc twice not thrice,alexcrichton,7046fea5be39110f4d4354b7fe5466903f606d8e,10,rustbuild: Compile rustc twice not thrice This commit switches the rustbuild build system to compiling the compiler twice for a normal bootstrap rather than the historical three times. Rust is a bootstrapped language which means that a previous version of the compiler is used to build the next version of the compiler. Over time however we change many parts of compiler artifacts such as the metadata format symbol names etc. These changes make artifacts from one compiler incompatible from another compiler. Consequently if a compiler wants to be able to use some artifacts then it itself must have compiled the artifacts. Historically the rustc build system has achieved this by compiling the compiler three times: * An older compiler (stage0) is downloaded to kick off the chain. * This compiler now compiles a new compiler (stage1) * The stage1 compiler then compiles another compiler (stage2) * Finally the stage2 compiler needs libraries to link against so it compiles all the libraries again. This entire process amounts in compiling the compiler three times. Additionally this process always guarantees that the Rust source tree can compile itself because the stage2 compiler (created by a freshly created compiler) would successfully compile itself again. This property ensuring Rust can compile itself is quite important! In general though this third compilation is not required for general purpose development on the compiler. The third compiler (stage2) can reuse the libraries that were created during the second compile. In other words the second compilation can produce both a compiler and the libraries that compiler will use. These artifacts *must* be compatible due to the way plugins work today anyway and they were created by the same source code so they *should* be compatible as well. So given all that this commit switches the default build process to only compile the compiler three times avoiding this third compilation by copying artifacts from the previous one. Along the way a new entry in the Travis matrix was also added to ensure that our full bootstrap can succeed. This entry does not run tests though as it should not be necessary. To restore the old behavior of a full bootstrap (three compiles) you can either pass: ./configure --enable-full-bootstrap or if you're using config.toml: [build] full-bootstrap = true Overall this will hopefully be an easy 33% win in build times of the compiler. If we do 33% less work we should be 33% faster! This in turn should affect cycle times and such on Travis and AppVeyor positively as well as making it easier to work on the compiler itself.,HOORAY,2017-01-06T22:44:30Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/38639,MERGED,2016-12-27T18:12:13Z,2016-12-28T20:09:06Z,rustbuild: Hotfix to unbreak nightly,xen0n,cf894535069f67a1192ae7999ae2a82ba31b4877,1,rustbuild: fix host-only rules ignoring targets in dist steps `arr` is the actual list of targets participating in steps construction but due to #38468 the hosts array now consists of only the build triple for the `dist` steps hence all non-build-triple targets are lost for the host-only rules. Fix this by using the original non-shadowed hosts array in `arr` calculation. This should unbreak the nightly packaging process. Fixes #38637.,THUMBS_UP,2016-12-27T19:10:02Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/38639,MERGED,2016-12-27T18:12:13Z,2016-12-28T20:09:06Z,rustbuild: Hotfix to unbreak nightly,xen0n,cf894535069f67a1192ae7999ae2a82ba31b4877,1,rustbuild: fix host-only rules ignoring targets in dist steps `arr` is the actual list of targets participating in steps construction but due to #38468 the hosts array now consists of only the build triple for the `dist` steps hence all non-build-triple targets are lost for the host-only rules. Fix this by using the original non-shadowed hosts array in `arr` calculation. This should unbreak the nightly packaging process. Fixes #38637.,HEART,2016-12-27T21:25:45Z,brson,NA https://github.com/rust-lang/rust/pull/38648,MERGED,2016-12-28T09:29:48Z,2017-01-22T19:12:16Z,libstd: replace all `try!` with `?` in documentation examples,utkarshkukreti,19724d34d2b223f940363cc07aa83a8a530f8093,1,libstd: mention `?` operator instead of removing `try!` macro reference,THUMBS_DOWN,2016-12-28T19:26:10Z,est31,NA https://github.com/rust-lang/rust/pull/38648,MERGED,2016-12-28T09:29:48Z,2017-01-22T19:12:16Z,libstd: replace all `try!` with `?` in documentation examples,utkarshkukreti,19724d34d2b223f940363cc07aa83a8a530f8093,1,libstd: mention `?` operator instead of removing `try!` macro reference,HEART,2016-12-29T08:50:37Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38648,MERGED,2016-12-28T09:29:48Z,2017-01-22T19:12:16Z,libstd: replace all `try!` with `?` in documentation examples,utkarshkukreti,19724d34d2b223f940363cc07aa83a8a530f8093,1,libstd: mention `?` operator instead of removing `try!` macro reference,HEART,2017-01-30T00:21:27Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38654,MERGED,2016-12-28T17:20:47Z,2017-01-12T10:28:58Z,rustbuild: Implement DESTDIR support,alexcrichton,16f8372e0895107ce594ffb111732e48ee35fe86,4,rustbuild: Implement DESTDIR support This commit primarily starts supporting the `DESTDIR` environment variable like the old build system. Along the way this brings `config.toml` up to date with support in `config.mk` with install options supported. Closes #38441,THUMBS_UP,2016-12-29T15:55:48Z,Randl,zheltonozhskiy@gmail.com https://github.com/rust-lang/rust/pull/38654,MERGED,2016-12-28T17:20:47Z,2017-01-12T10:28:58Z,rustbuild: Implement DESTDIR support,alexcrichton,16f8372e0895107ce594ffb111732e48ee35fe86,4,rustbuild: Implement DESTDIR support This commit primarily starts supporting the `DESTDIR` environment variable like the old build system. Along the way this brings `config.toml` up to date with support in `config.mk` with install options supported. Closes #38441,THUMBS_UP,2016-12-29T15:58:11Z,vaartis,NA https://github.com/rust-lang/rust/pull/38655,MERGED,2016-12-28T17:29:59Z,2016-12-30T09:39:57Z,travis: Use `&&` intead of `;`,alexcrichton,88429dc5751fa134b87a78977ce938c61900f059,1,travis: Use `&&` intead of `;` Show errors sooner and try not to hide them behind lots of other walls of text.,HEART,2016-12-28T21:35:27Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/38655,MERGED,2016-12-28T17:29:59Z,2016-12-30T09:39:57Z,travis: Use `&&` intead of `;`,alexcrichton,88429dc5751fa134b87a78977ce938c61900f059,1,travis: Use `&&` intead of `;` Show errors sooner and try not to hide them behind lots of other walls of text.,THUMBS_UP,2016-12-29T04:02:12Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/38655,MERGED,2016-12-28T17:29:59Z,2016-12-30T09:39:57Z,travis: Use `&&` intead of `;`,alexcrichton,88429dc5751fa134b87a78977ce938c61900f059,1,travis: Use `&&` intead of `;` Show errors sooner and try not to hide them behind lots of other walls of text.,THUMBS_UP,2016-12-30T17:40:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38670,MERGED,2016-12-29T01:49:52Z,2017-01-04T16:31:57Z,Fix transmute:: where T requires a bigger alignment than U,dotdash,71a11a0b102b0ba92895cdc4cff4ac7e78d9a12c,11,Fix transmute:: where T requires a bigger alignment than U For transmute:: we simply pointercast the destination from a U pointer to a T pointer without providing any alignment information thus LLVM assumes that the destination is aligned to hold a value of type T which is not necessarily true. This can lead to LLVM emitting machine instructions that assume said alignment and thus cause aborts. To fix this we need to provide the actual alignment to store_operand() and in turn to store() so they can set the proper alignment information on the stores and LLVM can emit the proper machine instructions. Fixes #32947,THUMBS_UP,2017-01-11T07:26:12Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38670,MERGED,2016-12-29T01:49:52Z,2017-01-04T16:31:57Z,Fix transmute:: where T requires a bigger alignment than U,dotdash,71a11a0b102b0ba92895cdc4cff4ac7e78d9a12c,11,Fix transmute:: where T requires a bigger alignment than U For transmute:: we simply pointercast the destination from a U pointer to a T pointer without providing any alignment information thus LLVM assumes that the destination is aligned to hold a value of type T which is not necessarily true. This can lead to LLVM emitting machine instructions that assume said alignment and thus cause aborts. To fix this we need to provide the actual alignment to store_operand() and in turn to store() so they can set the proper alignment information on the stores and LLVM can emit the proper machine instructions. Fixes #32947,THUMBS_UP,2017-01-11T19:22:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38675,MERGED,2016-12-29T14:17:48Z,2017-01-13T02:55:53Z,More jemalloc fixes,infinity0,cadebc7571074e4c17cef267d7269e91fd12ccf8,2,Disable jemalloc tests on platforms where it is disabled (closes #38612) See also #37392,HEART,2016-12-30T22:43:30Z,brson,NA https://github.com/rust-lang/rust/pull/38679,MERGED,2016-12-29T17:49:13Z,2017-01-08T10:19:07Z,Remove not(stage0) from deny(warnings),alexcrichton,9b0b5b45dbd268aba0a79453f506bfe00bb57042,47,Remove not(stage0) from deny(warnings) Historically this was done to accommodate bugs in lints but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.,HEART,2016-12-29T20:38:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38679,MERGED,2016-12-29T17:49:13Z,2017-01-08T10:19:07Z,Remove not(stage0) from deny(warnings),alexcrichton,9b0b5b45dbd268aba0a79453f506bfe00bb57042,47,Remove not(stage0) from deny(warnings) Historically this was done to accommodate bugs in lints but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.,HEART,2016-12-30T01:20:34Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38679,MERGED,2016-12-29T17:49:13Z,2017-01-08T10:19:07Z,Remove not(stage0) from deny(warnings),alexcrichton,9b0b5b45dbd268aba0a79453f506bfe00bb57042,47,Remove not(stage0) from deny(warnings) Historically this was done to accommodate bugs in lints but there hasn't been a bug in a lint since this feature was added which the warnings affected. Let's completely purge warnings from all our stages by denying warnings in all stages. This will also assist in tracking down `stage0` code to be removed whenever we're updating the bootstrap compiler.,THUMBS_UP,2016-12-30T01:20:38Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2016-12-30T14:47:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2016-12-30T17:08:43Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-03T15:53:35Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-05T20:00:53Z,skade,florian.gilcher@ferrous-systems.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-05T20:31:20Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-05T20:34:16Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-01-05T20:34:19Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-05T20:35:04Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-01-06T03:38:51Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-06T03:38:51Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-01-06T03:38:54Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-06T09:09:25Z,samlh,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-01-09T23:57:12Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-10T15:59:27Z,vks,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-16T11:39:04Z,arthurprs,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-01-27T21:35:21Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-01-27T21:35:22Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-01-27T21:35:24Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-07T12:51:22Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T04:53:42Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T16:05:02Z,jbendig,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T16:39:47Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T16:45:23Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-09T17:50:56Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-09T17:52:38Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T19:24:32Z,Vtec234,wjnawrocki+gh@protonmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-09T19:29:28Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T22:40:29Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-09T22:40:38Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-09T22:40:39Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-09T23:56:47Z,hauleth,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-09T23:56:48Z,hauleth,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-09T23:56:48Z,hauleth,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-11T20:46:39Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-12T05:46:29Z,Cyberunner23,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-13T21:06:47Z,AndiDog,andreas.sommer87@googlemail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-14T02:37:37Z,jminer,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-14T08:31:48Z,kingoflolz,wangben3@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-14T09:15:39Z,genodeftest,dev@genodeftest.de https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-14T11:19:13Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-14T11:19:13Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-15T09:45:03Z,kstep,milezv@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-15T10:05:13Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-16T06:25:39Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-16T08:08:33Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-16T08:08:34Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-16T08:08:34Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-16T14:22:28Z,bluss,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-18T23:49:07Z,grossws,grossws@apache.org https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-21T07:02:14Z,abronan,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-23T00:23:20Z,anga,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-28T03:07:49Z,g-k,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-28T08:22:45Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-02-28T10:35:23Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-02-28T10:35:24Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-02-28T10:35:25Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-03-08T21:36:17Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-03-08T21:36:19Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-03-08T21:36:23Z,jetm,javier.tia@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-04-22T19:43:54Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-04-22T21:41:46Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-07-02T14:08:06Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-07-02T14:08:10Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-07-02T14:08:12Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2017-07-15T21:22:23Z,bogdad,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-07-26T16:33:53Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2017-08-15T11:56:21Z,clux,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2017-12-23T00:39:12Z,lght,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2018-01-10T10:25:17Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2018-03-26T06:22:45Z,scurest,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2018-05-10T14:35:46Z,dmitry-timofeev,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2018-05-10T14:35:47Z,dmitry-timofeev,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2018-05-19T14:16:14Z,frol,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2018-05-19T14:16:15Z,frol,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HOORAY,2018-05-19T14:16:16Z,frol,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2019-03-04T11:43:29Z,uuhan,xuminhui189@gmail.com https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,THUMBS_UP,2020-12-30T00:59:43Z,comicfans,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2021-03-11T17:22:15Z,koutheir,NA https://github.com/rust-lang/rust/pull/38699,MERGED,2016-12-30T04:30:11Z,2017-02-09T08:54:20Z,LeakSanitizer ThreadSanitizer AddressSanitizer and MemorySanitizer support,japaric,e180dd541a8ae48e4aaf8934765f67955932252f,1,sanitizer-dylib: only run where std for x86_64-linux is available,HEART,2022-07-01T17:32:11Z,Be-ing,NA https://github.com/rust-lang/rust/pull/38701,MERGED,2016-12-30T12:53:38Z,2016-12-31T00:50:34Z,Making code style consistent for src/rustllvm (#38688),karpinski,72ebc02f13eeb7328d199d7d5ccaee4e5ff03b3e,3,Switching from NULL to nullptr in src/rustllvm.,HOORAY,2016-12-30T14:13:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38708,MERGED,2016-12-30T17:42:05Z,2017-01-01T00:27:21Z,Gate on distcheck on Travis,alexcrichton,4781eb315b7bcf11682d68aafac2ce4739bfe166,6,"travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a ""distcheck"" which basically means that we create a tarball extract that tarball and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691",HOORAY,2016-12-30T19:06:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38708,MERGED,2016-12-30T17:42:05Z,2017-01-01T00:27:21Z,Gate on distcheck on Travis,alexcrichton,4781eb315b7bcf11682d68aafac2ce4739bfe166,6,"travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a ""distcheck"" which basically means that we create a tarball extract that tarball and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691",HOORAY,2016-12-30T19:09:07Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38708,MERGED,2016-12-30T17:42:05Z,2017-01-01T00:27:21Z,Gate on distcheck on Travis,alexcrichton,4781eb315b7bcf11682d68aafac2ce4739bfe166,6,"travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a ""distcheck"" which basically means that we create a tarball extract that tarball and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691",HOORAY,2016-12-31T07:48:26Z,alexbool,NA https://github.com/rust-lang/rust/pull/38708,MERGED,2016-12-30T17:42:05Z,2017-01-01T00:27:21Z,Gate on distcheck on Travis,alexcrichton,4781eb315b7bcf11682d68aafac2ce4739bfe166,6,"travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a ""distcheck"" which basically means that we create a tarball extract that tarball and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691",HOORAY,2016-12-31T17:18:51Z,xen0n,NA https://github.com/rust-lang/rust/pull/38708,MERGED,2016-12-30T17:42:05Z,2017-01-01T00:27:21Z,Gate on distcheck on Travis,alexcrichton,4781eb315b7bcf11682d68aafac2ce4739bfe166,6,"travis: Add a distcheck target This commit adds a new entry to the Travis matrix which performs a ""distcheck"" which basically means that we create a tarball extract that tarball and then build/test inside there. This ensures that the tarballs we produce are actually able to be built/tested! Along the way this also updates the rustbuild distcheck definition to propagate the configure args from the top-level invocation. Closes #38691",HOORAY,2016-12-31T23:47:45Z,dvc94ch,david@craven.ch https://github.com/rust-lang/rust/pull/38709,MERGED,2016-12-30T17:58:27Z,2016-12-31T14:41:52Z,cargotest: Add xsv to tested crates,alexcrichton,73b708a72fdf1b3beeab42cc66d6fa891b8c5f24,1,cargotest: Add xsv to tested crates This was intended to land in #37149 but I ended up backing it out to land the rollup (#38697) last night as I was itching to do so. This morning though xsv has been fixed now (BurntSushi/xsv#53) so we should be able to add it!,HEART,2016-12-30T18:22:32Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38711,MERGED,2016-12-30T19:15:12Z,2017-01-01T09:56:08Z,Add links to methods on all slice iterator struct docs,causal-agent,8d88bbc4e8aa533096fb890349fa43a381206cc7,1,Add links to methods on all slice iterator struct docs,HEART,2016-12-31T18:29:28Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38725,CLOSED,2016-12-31T00:28:30Z,2017-01-16T19:23:01Z,[WIP] Bump allocator for rustc,mattico,NA,NA,NA,HEART,2017-01-08T05:08:30Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38731,MERGED,2016-12-31T04:08:44Z,2017-01-05T06:00:40Z,rustbuild: Quickly `dist` cross-host compilers,alexcrichton,1a040b36cb5c748b1e5f0ea0a97f7ec5a51ee48d,9,rustbuild: Quickly `dist` cross-host compilers This commit optimizes the compile time for creating tarballs of cross-host compilers and as a proof of concept adds two to the standard Travis matrix. Much of this commit is further refactoring and refining of the `step.rs` definitions along with the interpretation of `--target` and `--host` flags. This has gotten confusing enough that I've also added a small test suite to `src/bootstrap/step.rs` to ensure what we're doing works and doesn't regress. After this commit when you execute: ./x.py dist --host $MY_HOST --target $MY_HOST the build system will compile two compilers. The first is for the build platform and the second is for the host platform. This second compiler is then packaged up and placed into `build/dist` and is ready to go. With a fully cached LLVM and docker image I was able to create a cross-host compiler in around 20 minutes locally. Eventually we plan to add a whole litany of cross-host entries to the Travis matrix but for now we're just adding a few before we eat up all the extra capacity. cc #38531,HOORAY,2016-12-31T12:17:00Z,xen0n,NA https://github.com/rust-lang/rust/pull/38733,MERGED,2016-12-31T05:20:33Z,2017-01-07T21:28:29Z,Add PeekMut::pop,sfackler,54dc533494bba8256dcd7c54597fb1d42ef070ab,1,Add a tracking issue,HEART,2016-12-31T13:00:41Z,bluss,NA https://github.com/rust-lang/rust/pull/38737,MERGED,2016-12-31T06:44:47Z,2016-12-31T18:54:19Z,Fix panic when using a macros 1.1 custom derive on a struct containing a macro invocation,keeperofdakeys,e9b5839918a1e36ef923a88f71c67da2d9f7b9e1,3,Style fixes,HEART,2016-12-31T09:21:56Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/38748,MERGED,2017-01-01T01:44:53Z,2017-01-13T05:41:24Z,travis: Start uploading artifacts on commits,alexcrichton,318767266fece7b0c3f2965d6664b80b7aaa1613,19,travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489,HEART,2017-01-02T17:32:11Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/38748,MERGED,2017-01-01T01:44:53Z,2017-01-13T05:41:24Z,travis: Start uploading artifacts on commits,alexcrichton,318767266fece7b0c3f2965d6664b80b7aaa1613,19,travis: Start uploading artifacts on commits This commit starts adding the infrastructure for uploading release artifacts from AppVeyor/Travis on each commit. The idea is that eventually we'll upload a full release to AppVeyor/Travis in accordance with plans [outlined earlier]. Right now this configures Travis/Appveyor to upload all tarballs in the `dist` directory and various images are updated to actually produce tarballs in these directories. These are nowhere near ready to be actual release artifacts but this should allow us to play around with it and test it out. Once this commit lands we should start seeing artifacts uploaded on each commit. [outlined earlier]: https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489,HEART,2017-01-13T08:38:33Z,xen0n,NA https://github.com/rust-lang/rust/pull/38753,MERGED,2017-01-01T09:35:19Z,2017-01-01T18:42:21Z,Add pretty printing of unions in debuggers,philipc,1765a3fd30b12e8647e79f9caf873c800df42bf9,3,Add pretty printing of unions in debuggers Fixes #37479,THUMBS_UP,2017-01-01T19:45:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38779,MERGED,2017-01-02T18:21:33Z,2017-01-12T16:45:34Z,Do not run outer setup part of benchmarks multiple times to fix issue 20142,Craig-Macomber,7cb20408a42e976005f0e803c6ed0115a520d453,2,do not run outter part of benchmarks multimple times to fix issue 20142,HEART,2017-06-29T18:02:24Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-01-03T16:19:24Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-01-11T03:02:37Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-01-11T13:07:26Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-01-11T19:34:05Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-01-12T02:02:19Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38781,MERGED,2017-01-02T18:41:11Z,2017-01-07T23:32:33Z,Reduce the size of static data in std_unicode::tables,SimonSapin,3b208d2dac15237a46eb82c03bcc70a2b1165d20,3,Reduce the size of static data in std_unicode::tables. `BoolTrie` works well for sets of code points spread out through most of Unicode’s range but is uses a lot of space for sets with few mostly low code points. This switches a few of its instances to a similar but simpler trie data structure. ## Before `size_of::()` is 1552 which is added to `table.r3.len() * 8 + t.r5.len() + t.r6.len() * 8`: * `Cc_table`: 1632 * `White_Space_table`: 1656 * `Pattern_White_Space_table`: 1640 * Total: 4928 bytes ## After `size_of::()` is 32 which is added to `t.r1.len() + t.r2.len() * 8`: * `Cc_table`: 51 * `White_Space_table`: 273 * `Pattern_White_Space_table`: 193 * Total: 517 bytes ## Difference Every Rust program with `std` statically linked should be about 4 KB smaller.,THUMBS_UP,2017-03-16T19:25:59Z,jminer,NA https://github.com/rust-lang/rust/pull/38782,MERGED,2017-01-02T20:50:24Z,2017-01-03T04:23:42Z,Reword 'stupid' and 'crazy' in docs.,clarfonthey,8ffc3e779020808e2437389e0aa559d9b028b061,5,Reword 'stupid' and 'crazy' in docs.,THUMBS_UP,2017-01-02T22:17:35Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/38782,MERGED,2017-01-02T20:50:24Z,2017-01-03T04:23:42Z,Reword 'stupid' and 'crazy' in docs.,clarfonthey,8ffc3e779020808e2437389e0aa559d9b028b061,5,Reword 'stupid' and 'crazy' in docs.,THUMBS_UP,2017-01-03T01:12:45Z,8573,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:20:14Z,killercup,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:26:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:29:11Z,sgrif,sage@sagetheprogrammer.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:31:10Z,zsiciarz,zbigniew@siciarz.net https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:38:11Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:46:43Z,CryZe,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:50:42Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:53:21Z,kcking,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T22:57:18Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:29:37Z,jplatte,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:31:49Z,nettok,pyalec@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:37:44Z,dginev,deyan.ginev@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:42:06Z,achanda,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:47:32Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-02T23:53:23Z,SkylerLipthay,sl@skylerlipthay.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T01:05:56Z,mernen,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T01:09:22Z,Yamakaky,yamakaky@yamaworld.fr https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T01:57:19Z,est31,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T02:24:34Z,chrish42,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T02:33:59Z,purpleposeidon,purpleposeidon@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T02:49:10Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T03:27:13Z,nstott,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T03:34:34Z,Gudahtt,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T03:56:50Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T04:24:44Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T04:24:48Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T04:38:39Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T05:00:57Z,nettok,pyalec@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T05:50:56Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T06:17:51Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T08:38:33Z,exul,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T08:43:10Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T08:43:10Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T08:52:11Z,brendanzab,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",THUMBS_DOWN,2017-01-03T09:14:33Z,retep998,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T09:15:17Z,yanns,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T09:23:37Z,LFalch,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T09:23:38Z,LFalch,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T09:34:21Z,TechPriest,yaminogakusei@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T10:11:36Z,mcarton,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T10:25:43Z,adnanademovic,adnanademovic100@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T10:28:16Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T11:19:35Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T12:20:26Z,NfNitLoop,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T12:51:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T12:56:39Z,jeandudey,me@jeandudey.tech https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T14:48:46Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T14:48:48Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T15:36:42Z,regexident,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T16:22:37Z,kbknapp,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T16:43:02Z,xen0n,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T18:55:16Z,adamhjk,adam@opscode.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T20:04:48Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T20:52:55Z,plietar,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-03T20:52:56Z,plietar,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-03T22:39:16Z,Arrem,alem.zupa@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",THUMBS_DOWN,2017-01-04T06:26:04Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-04T06:31:03Z,niconii,nicole@nicole.moe https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-04T15:39:43Z,dojiong,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",THUMBS_UP,2017-01-04T22:26:10Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-04T22:26:12Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HEART,2017-01-04T22:26:12Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-11T01:40:09Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2017-01-11T09:11:26Z,johansigfrids,NA https://github.com/rust-lang/rust/pull/38783,MERGED,2017-01-02T21:45:33Z,2017-01-04T22:08:13Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,045f8f69293fae924ee4998439ec0e34f98320be,65,"rustc: Stabilize the `proc_macro` feature This commit stabilizes the `proc_macro` and `proc_macro_lib` features in the compiler to stabilize the ""Macros 1.1"" feature of the language. Many more details can be found on the tracking issue #35900. Closes #35900",HOORAY,2018-03-24T01:42:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/38792,MERGED,2017-01-03T02:15:41Z,2017-01-06T21:23:32Z,proc macros 1.1: improve diagnostics,jseyfried,fd532a160822d58ae28d81c8396e2d1f0b691e09,2,Add regression test.,HEART,2017-01-03T18:48:28Z,brson,NA https://github.com/rust-lang/rust/pull/38809,MERGED,2017-01-03T22:18:22Z,2017-01-04T03:51:41Z,rustbuild: Fix a few rebuilding issues,alexcrichton,3ab778b4afc1c11e48dd8b1f82c5dca9c897bcba,1,"rustbuild: Update where we look for mtime changes Recent versions of Cargo lift less output up into the ""main"" directory so let's look more inside the `deps` folder for changes to propagate differences. Closes #38744 Closes #38746",HEART,2017-01-03T22:43:37Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38809,MERGED,2017-01-03T22:18:22Z,2017-01-04T03:51:41Z,rustbuild: Fix a few rebuilding issues,alexcrichton,3ab778b4afc1c11e48dd8b1f82c5dca9c897bcba,1,"rustbuild: Update where we look for mtime changes Recent versions of Cargo lift less output up into the ""main"" directory so let's look more inside the `deps` folder for changes to propagate differences. Closes #38744 Closes #38746",HEART,2017-01-03T23:07:17Z,est31,NA https://github.com/rust-lang/rust/pull/38809,MERGED,2017-01-03T22:18:22Z,2017-01-04T03:51:41Z,rustbuild: Fix a few rebuilding issues,alexcrichton,3ab778b4afc1c11e48dd8b1f82c5dca9c897bcba,1,"rustbuild: Update where we look for mtime changes Recent versions of Cargo lift less output up into the ""main"" directory so let's look more inside the `deps` folder for changes to propagate differences. Closes #38744 Closes #38746",HEART,2017-01-04T00:35:04Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/38809,MERGED,2017-01-03T22:18:22Z,2017-01-04T03:51:41Z,rustbuild: Fix a few rebuilding issues,alexcrichton,3ab778b4afc1c11e48dd8b1f82c5dca9c897bcba,1,"rustbuild: Update where we look for mtime changes Recent versions of Cargo lift less output up into the ""main"" directory so let's look more inside the `deps` folder for changes to propagate differences. Closes #38744 Closes #38746",HEART,2017-01-04T02:07:47Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/38813,MERGED,2017-01-04T02:27:59Z,2017-01-08T13:40:24Z,[11/n] Separate ty::Tables into one per each body.,eddyb,cde0a7e7e01f64caed45e97ff958821d9247959e,17,rustc: store ty::Tables separately for each body (except closures').,HOORAY,2017-01-04T21:58:08Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/38814,MERGED,2017-01-04T04:45:14Z,2017-01-12T22:52:05Z,syntax: enable attributes and cfg on struct fields,Ralith,7972c1905beb9d1169475f42231b25d0bc9e83e6,12,syntax: struct field attributes and cfg,THUMBS_UP,2017-01-08T00:59:22Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38814,MERGED,2017-01-04T04:45:14Z,2017-01-12T22:52:05Z,syntax: enable attributes and cfg on struct fields,Ralith,7972c1905beb9d1169475f42231b25d0bc9e83e6,12,syntax: struct field attributes and cfg,THUMBS_UP,2017-01-19T15:35:48Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/38814,MERGED,2017-01-04T04:45:14Z,2017-01-12T22:52:05Z,syntax: enable attributes and cfg on struct fields,Ralith,7972c1905beb9d1169475f42231b25d0bc9e83e6,12,syntax: struct field attributes and cfg,THUMBS_UP,2017-01-23T20:18:00Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/38816,MERGED,2017-01-04T06:35:07Z,2017-01-10T16:36:47Z,Add more docs for CoerceUnsized and Unsize,Manishearth,07e844f95fb7894281c08f65f2d127a568525142,3,Add more docs for CoerceUnsized and Unsize,THUMBS_UP,2017-01-04T07:33:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/38816,MERGED,2017-01-04T06:35:07Z,2017-01-10T16:36:47Z,Add more docs for CoerceUnsized and Unsize,Manishearth,07e844f95fb7894281c08f65f2d127a568525142,3,Add more docs for CoerceUnsized and Unsize,THUMBS_UP,2017-01-04T09:23:19Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/38816,MERGED,2017-01-04T06:35:07Z,2017-01-10T16:36:47Z,Add more docs for CoerceUnsized and Unsize,Manishearth,07e844f95fb7894281c08f65f2d127a568525142,3,Add more docs for CoerceUnsized and Unsize,HEART,2017-01-04T20:50:07Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/38825,CLOSED,2017-01-04T16:00:50Z,2017-02-15T10:58:07Z,rustdoc: Add an attribute to ignore collecting tests per-item.,emilio,NA,NA,NA,THUMBS_UP,2017-01-04T16:05:39Z,daschl,NA https://github.com/rust-lang/rust/pull/38825,CLOSED,2017-01-04T16:00:50Z,2017-02-15T10:58:07Z,rustdoc: Add an attribute to ignore collecting tests per-item.,emilio,NA,NA,NA,THUMBS_UP,2017-01-11T13:14:13Z,fitzgen,NA https://github.com/rust-lang/rust/pull/38835,MERGED,2017-01-04T23:46:31Z,2017-01-07T02:01:32Z,std: Don't pass overlapped handles to processes,alexcrichton,5148918db606689abea8f971ceb6c5bec4c0ba52,4,"std: Don't pass overlapped handles to processes This commit fixes a mistake introduced in #31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes however are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust however the stdio handles are always locked and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles which means that Rust programs typically ""just work"". Conversely though this commit fixes the test case included which exhibits behavior that other programs Rust spawns may attempt to execute. Namely the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes #38811",HOORAY,2017-01-04T23:53:34Z,dherman,NA https://github.com/rust-lang/rust/pull/38835,MERGED,2017-01-04T23:46:31Z,2017-01-07T02:01:32Z,std: Don't pass overlapped handles to processes,alexcrichton,5148918db606689abea8f971ceb6c5bec4c0ba52,4,"std: Don't pass overlapped handles to processes This commit fixes a mistake introduced in #31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes however are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust however the stdio handles are always locked and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles which means that Rust programs typically ""just work"". Conversely though this commit fixes the test case included which exhibits behavior that other programs Rust spawns may attempt to execute. Namely the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes #38811",HOORAY,2017-01-04T23:56:07Z,est31,NA https://github.com/rust-lang/rust/pull/38835,MERGED,2017-01-04T23:46:31Z,2017-01-07T02:01:32Z,std: Don't pass overlapped handles to processes,alexcrichton,5148918db606689abea8f971ceb6c5bec4c0ba52,4,"std: Don't pass overlapped handles to processes This commit fixes a mistake introduced in #31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes however are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust however the stdio handles are always locked and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles which means that Rust programs typically ""just work"". Conversely though this commit fixes the test case included which exhibits behavior that other programs Rust spawns may attempt to execute. Namely the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes #38811",HOORAY,2017-01-11T17:15:41Z,Diggsey,NA https://github.com/rust-lang/rust/pull/38837,MERGED,2017-01-05T01:21:13Z,2017-01-08T17:47:52Z,Allow projections to be promoted to constants in MIR.,eddyb,8f84e955e006dd9e116f69eaba6efbbcd2e3ca8a,3,Allow projections to be promoted to constants in MIR.,HOORAY,2017-01-05T01:23:07Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/38837,MERGED,2017-01-05T01:21:13Z,2017-01-08T17:47:52Z,Allow projections to be promoted to constants in MIR.,eddyb,8f84e955e006dd9e116f69eaba6efbbcd2e3ca8a,3,Allow projections to be promoted to constants in MIR.,HOORAY,2017-01-05T02:55:22Z,est31,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HOORAY,2017-01-17T14:52:55Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HOORAY,2017-01-17T18:04:08Z,rushmorem,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HEART,2017-01-17T21:04:16Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HOORAY,2017-01-21T03:34:14Z,cbreeden,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HOORAY,2017-01-25T09:42:55Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",THUMBS_UP,2017-02-15T05:42:02Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38842,MERGED,2017-01-05T05:19:39Z,2017-01-21T03:25:47Z,Implement `#[proc_macro_attribute]`,abonander,04ecee158c2c56f4a6d81ad17ac3547848ec1e4c,3,"Move ""completed feature gate checking"" pass to after ""name resolution"" pass so proc-macro-attribute feature gate check can use resolve",HOORAY,2017-03-07T22:35:31Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/38847,MERGED,2017-01-05T14:24:39Z,2017-01-31T08:44:08Z,travis: Gate on some minimal support for incremental compilation.,michaelwoerister,d292e1229f1e7cc882e550d3ecc0e152720a0ab5,1,compiletest: Clear RUSTFLAGS env-var for run-make tests.,HEART,2017-01-05T14:44:22Z,est31,NA https://github.com/rust-lang/rust/pull/38847,MERGED,2017-01-05T14:24:39Z,2017-01-31T08:44:08Z,travis: Gate on some minimal support for incremental compilation.,michaelwoerister,d292e1229f1e7cc882e550d3ecc0e152720a0ab5,1,compiletest: Clear RUSTFLAGS env-var for run-make tests.,HOORAY,2017-01-05T14:44:26Z,est31,NA https://github.com/rust-lang/rust/pull/38847,MERGED,2017-01-05T14:24:39Z,2017-01-31T08:44:08Z,travis: Gate on some minimal support for incremental compilation.,michaelwoerister,d292e1229f1e7cc882e550d3ecc0e152720a0ab5,1,compiletest: Clear RUSTFLAGS env-var for run-make tests.,HOORAY,2017-01-10T07:56:16Z,oli-obk,NA https://github.com/rust-lang/rust/pull/38853,MERGED,2017-01-05T19:18:41Z,2017-01-08T19:50:35Z,rustbuild: Don't build target compilers in stage0,alexcrichton,be5e322f040b2b8e29173fc054a3b40f75ab311a,1,rustbuild: Don't build target compilers in stage0 The `doc-book` and `doc-nomicon` steps accidentally depended on a rustbook compiled by a cross-compiled compiler which isn't necessary. Be sure to set the `host` on these dependency edges to the build compiler to ensure that we're always using a tool compiled for the host platform. This was discovered trawling the build logs for the new dist bots and discovering that they're building one too many compilers in stage0.,HEART,2017-01-05T19:24:23Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/38853,MERGED,2017-01-05T19:18:41Z,2017-01-08T19:50:35Z,rustbuild: Don't build target compilers in stage0,alexcrichton,be5e322f040b2b8e29173fc054a3b40f75ab311a,1,rustbuild: Don't build target compilers in stage0 The `doc-book` and `doc-nomicon` steps accidentally depended on a rustbook compiled by a cross-compiled compiler which isn't necessary. Be sure to set the `host` on these dependency edges to the build compiler to ensure that we're always using a tool compiled for the host platform. This was discovered trawling the build logs for the new dist bots and discovering that they're building one too many compilers in stage0.,HEART,2017-01-05T19:25:41Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/38853,MERGED,2017-01-05T19:18:41Z,2017-01-08T19:50:35Z,rustbuild: Don't build target compilers in stage0,alexcrichton,be5e322f040b2b8e29173fc054a3b40f75ab311a,1,rustbuild: Don't build target compilers in stage0 The `doc-book` and `doc-nomicon` steps accidentally depended on a rustbook compiled by a cross-compiled compiler which isn't necessary. Be sure to set the `host` on these dependency edges to the build compiler to ensure that we're always using a tool compiled for the host platform. This was discovered trawling the build logs for the new dist bots and discovering that they're building one too many compilers in stage0.,HEART,2017-01-06T14:01:11Z,xen0n,NA https://github.com/rust-lang/rust/pull/38870,CLOSED,2017-01-06T09:29:05Z,2017-01-19T19:09:54Z,Set the expected align for byval arguments,nagisa,NA,NA,NA,HOORAY,2017-01-06T10:06:41Z,est31,NA https://github.com/rust-lang/rust/pull/38890,MERGED,2017-01-06T21:18:21Z,2017-01-13T19:12:17Z,"resolve: Do not use ""resolve""/""resolution"" in error messages",petrochenkov,2092682191f104c7764eba23d4317f4b7f98a100,93,"resolve: Do not use ""resolve""/""resolution"" in error messages",THUMBS_UP,2017-01-06T23:45:13Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38896,CLOSED,2017-01-06T23:53:04Z,2017-01-09T21:22:36Z,Stabilize `-Zincremental` as `-Cincremental`,nikomatsakis,NA,NA,NA,HOORAY,2017-01-07T00:13:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/38896,CLOSED,2017-01-06T23:53:04Z,2017-01-09T21:22:36Z,Stabilize `-Zincremental` as `-Cincremental`,nikomatsakis,NA,NA,NA,HOORAY,2017-01-07T02:05:37Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/38896,CLOSED,2017-01-06T23:53:04Z,2017-01-09T21:22:36Z,Stabilize `-Zincremental` as `-Cincremental`,nikomatsakis,NA,NA,NA,HOORAY,2017-01-07T14:46:07Z,alexbool,NA https://github.com/rust-lang/rust/pull/38896,CLOSED,2017-01-06T23:53:04Z,2017-01-09T21:22:36Z,Stabilize `-Zincremental` as `-Cincremental`,nikomatsakis,NA,NA,NA,HOORAY,2017-01-07T18:45:52Z,plietar,NA https://github.com/rust-lang/rust/pull/38896,CLOSED,2017-01-06T23:53:04Z,2017-01-09T21:22:36Z,Stabilize `-Zincremental` as `-Cincremental`,nikomatsakis,NA,NA,NA,HOORAY,2017-01-07T19:40:19Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38927,MERGED,2017-01-08T17:01:48Z,2017-01-14T11:02:55Z,resolve: Levenshtein-based suggestions for non-import paths,petrochenkov,589bd649d2c56f5c526f6fde3bfac85efb5f3a4d,4,resolve: Levenshtein-based suggestions for non-import paths,HEART,2017-01-08T18:57:02Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/38927,MERGED,2017-01-08T17:01:48Z,2017-01-14T11:02:55Z,resolve: Levenshtein-based suggestions for non-import paths,petrochenkov,589bd649d2c56f5c526f6fde3bfac85efb5f3a4d,4,resolve: Levenshtein-based suggestions for non-import paths,HEART,2017-01-11T01:12:00Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38927,MERGED,2017-01-08T17:01:48Z,2017-01-14T11:02:55Z,resolve: Levenshtein-based suggestions for non-import paths,petrochenkov,589bd649d2c56f5c526f6fde3bfac85efb5f3a4d,4,resolve: Levenshtein-based suggestions for non-import paths,HEART,2017-03-16T19:09:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38927,MERGED,2017-01-08T17:01:48Z,2017-01-14T11:02:55Z,resolve: Levenshtein-based suggestions for non-import paths,petrochenkov,589bd649d2c56f5c526f6fde3bfac85efb5f3a4d,4,resolve: Levenshtein-based suggestions for non-import paths,HEART,2017-03-16T21:42:56Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38932,MERGED,2017-01-08T21:56:34Z,2017-02-02T07:39:05Z,Privatize constructors of tuple structs with private fields,petrochenkov,d38a8ad488047b8acdeed44bb7c67dc776324624,6,Improve diagnostics for inaccessible constructors,THUMBS_UP,2017-01-11T04:21:55Z,jseyfried,NA https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2017-01-10T20:23:09Z,est31,NA https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2017-01-12T01:53:44Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2017-01-24T10:20:04Z,petro-rudenko,petro.rudenko@gmail.com https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2017-01-24T17:22:10Z,Diggsey,NA https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2017-02-07T18:18:22Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/38959,MERGED,2017-01-10T12:51:52Z,2017-02-05T16:56:58Z,Add 128-bit atomics,Amanieu,9903975003276cc42a1ed5f21eee292b7c62c331,2,Add 128-bit atomics,HEART,2018-07-26T08:09:41Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-10T21:24:29Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-10T21:41:57Z,est31,NA https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-10T21:46:26Z,fsouza,NA https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-10T22:46:34Z,killercup,NA https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-10T22:58:34Z,bluss,NA https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-11T00:56:59Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HOORAY,2017-01-11T15:26:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-24T23:35:25Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-26T05:57:31Z,alanhoff,alanhoffmeister@gmail.com https://github.com/rust-lang/rust/pull/38966,MERGED,2017-01-10T20:40:04Z,2017-01-21T03:25:48Z,1.15 release notes,brson,a0a4af139dcac3c1629e5853d72df27616a00d2a,1,1.15 release notes,HEART,2017-01-29T08:57:07Z,bluejekyll,NA https://github.com/rust-lang/rust/pull/38984,MERGED,2017-01-11T04:33:39Z,2017-01-11T15:45:05Z,rustbuild: Don't enable debuginfo in rustc,alexcrichton,099e7cb120ad2cf7c85609ec58ef6a1ac7a56b1d,4,"rustbuild: Don't enable debuginfo in rustc In #37280 we enabled line number debugging information in release artifacts primarily to close out #36452 where debugging information was critical for MSVC builds of Rust to be useful in production. This commit however apparently had some unfortunate side effects. Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any compiler error would take a very long time for the compiler to exit. The cause of the problem here was somewhat deep: * For all compiler errors the compiler will `panic!` with a known value. This tears down the main compiler thread and allows cleaning up all the various resources. By default however this panic output is suppressed for ""normal"" compiler errors. * When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a backtrace. * The libbacktrace library hits a pathological case where it spends a very long time in its custom allocation function `backtrace_alloc` because the compiler has so much debugging information. More information about this can be found in #29293 with a summary at the end of #37477. To solve this problem this commit simply removes debuginfo from the compiler but not from the standard library. This should allow us to keep #36452 closed while also closing #37477. I've measured the difference to be orders of magnitude faster than it was before so we should see a much quicker time-to-exit after a compile error when `RUST_BACKTRACE=1` is set. Closes #37477 Closes #37571",THUMBS_UP,2017-01-11T16:44:45Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/39010,CLOSED,2017-01-12T08:51:28Z,2017-01-14T07:07:28Z,refactor RangeArgument,oli-obk,NA,NA,NA,HOORAY,2017-01-12T17:12:08Z,durka,NA https://github.com/rust-lang/rust/pull/39026,MERGED,2017-01-13T01:28:17Z,2017-01-15T02:31:58Z,rustbuild: Actually don't build stage0 target rustc,alexcrichton,2c5ae529941d61e005d2e5a153ebc74600e38a78,1,rustbuild: Actually don't build stage0 target rustc This was attempted in #38853 but erroneously forgot one more case of where the compiler was compiled. This commit fixes that up and adds a test to ensure this doesn't sneak back in.,HEART,2017-01-13T08:37:36Z,xen0n,NA https://github.com/rust-lang/rust/pull/39026,MERGED,2017-01-13T01:28:17Z,2017-01-15T02:31:58Z,rustbuild: Actually don't build stage0 target rustc,alexcrichton,2c5ae529941d61e005d2e5a153ebc74600e38a78,1,rustbuild: Actually don't build stage0 target rustc This was attempted in #38853 but erroneously forgot one more case of where the compiler was compiled. This commit fixes that up and adds a test to ensure this doesn't sneak back in.,THUMBS_UP,2017-01-13T08:37:48Z,xen0n,NA https://github.com/rust-lang/rust/pull/39048,MERGED,2017-01-13T23:17:41Z,2017-01-24T03:33:36Z,impl ToSocketAddrs for String,lambda,a5f2f36ebdad455cbff8d6cb1b2647698299020a,1,"impl ToSocketAddrs for String `ToSocketAddrs` is implemented for a number of different types including `(IpAddr u16)` `&str` and various others for the convenience of being able to run things like `TcpListener::bind(""10.11.12.13:1415"")`. However because this is a generic parameter with a trait bound if you have a `String` you cannot pass it in either directly as `TcpListener::bind(string)` or the `TcpListener::bind(&string)` as you might expect due to deref coercion; you have to use `TcpListener::bind(&*string)` which is noisy and hard to discover (though #39029 suggests better error messages to make it more discoverable). Rather than making people stumble over this just implement `ToSocketAddrs` for `String`.",THUMBS_UP,2017-01-13T23:31:23Z,achanda,NA https://github.com/rust-lang/rust/pull/39048,MERGED,2017-01-13T23:17:41Z,2017-01-24T03:33:36Z,impl ToSocketAddrs for String,lambda,a5f2f36ebdad455cbff8d6cb1b2647698299020a,1,"impl ToSocketAddrs for String `ToSocketAddrs` is implemented for a number of different types including `(IpAddr u16)` `&str` and various others for the convenience of being able to run things like `TcpListener::bind(""10.11.12.13:1415"")`. However because this is a generic parameter with a trait bound if you have a `String` you cannot pass it in either directly as `TcpListener::bind(string)` or the `TcpListener::bind(&string)` as you might expect due to deref coercion; you have to use `TcpListener::bind(&*string)` which is noisy and hard to discover (though #39029 suggests better error messages to make it more discoverable). Rather than making people stumble over this just implement `ToSocketAddrs` for `String`.",THUMBS_DOWN,2017-01-14T17:02:45Z,EdorianDark,NA https://github.com/rust-lang/rust/pull/39060,MERGED,2017-01-14T09:59:24Z,2017-01-22T06:40:55Z,Improve unused `extern crate` and unused `#[macro_use]` warnings,jseyfried,191abc42642c29f589a34e7f6cdebd081c373138,29,Remove unused `extern crate`s.,THUMBS_UP,2017-01-15T02:23:40Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/39075,MERGED,2017-01-15T07:49:50Z,2017-01-26T12:22:29Z,Remove Reflect,est31,af46d69b8a3d553a4d33e0c9d296b845c404e499,8,"Remove Reflect * Remove the Reflect trait * Remove the ""reflect"" lang feature",HEART,2017-01-15T17:20:16Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39076,MERGED,2017-01-15T09:55:11Z,2017-01-16T15:23:56Z,rustdoc: Give primitive types stability attributes,ollie27,f48f3d7584a95152de60f7e493eae3381aae2ed7,2,rustdoc: Give primitive types stability attributes This is especially important for i128/u128 to make it clear they are unstable in the docs.,HEART,2017-01-16T08:42:14Z,est31,NA https://github.com/rust-lang/rust/pull/39096,CLOSED,2017-01-16T10:11:18Z,2017-02-06T22:06:14Z,[WIP] Document field init shorthand,NA,NA,NA,NA,THUMBS_UP,2017-01-16T10:35:30Z,Havvy,NA https://github.com/rust-lang/rust/pull/39096,CLOSED,2017-01-16T10:11:18Z,2017-02-06T22:06:14Z,[WIP] Document field init shorthand,NA,NA,NA,NA,HEART,2017-01-16T23:46:04Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/39118,MERGED,2017-01-17T05:22:41Z,2017-01-21T03:25:51Z,Refactor the parser to consume token trees,jseyfried,0b9e26f390403aa95620d3b813f046732b371fb1,2,Fix fallout in `rustdoc`.,HEART,2017-01-17T16:09:45Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/39120,MERGED,2017-01-17T07:44:28Z,2017-01-21T03:25:51Z,travis: Get an emscripten builder online,alexcrichton,e8f9d2d43a190074d52a0df40725ebd2c0fb0a9e,25,travis: Get an emscripten builder online This commit adds a new entry to the Travis matrix which will execute emscripten test suites. Along the way it updates a few bits of the test suite to continue passing on emscripten such as: * Ignoring i128/u128 tests as they're presumably just not working (didn't investigate as to why) * Disabling a few process tests (not working on emscripten) * Ignore some num tests in libstd (#39119) * Fix some warnings when compiling,HOORAY,2017-01-19T09:36:43Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/39120,MERGED,2017-01-17T07:44:28Z,2017-01-21T03:25:51Z,travis: Get an emscripten builder online,alexcrichton,e8f9d2d43a190074d52a0df40725ebd2c0fb0a9e,25,travis: Get an emscripten builder online This commit adds a new entry to the Travis matrix which will execute emscripten test suites. Along the way it updates a few bits of the test suite to continue passing on emscripten such as: * Ignoring i128/u128 tests as they're presumably just not working (didn't investigate as to why) * Disabling a few process tests (not working on emscripten) * Ignore some num tests in libstd (#39119) * Fix some warnings when compiling,HOORAY,2017-01-19T21:30:31Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/39142,MERGED,2017-01-17T23:32:56Z,2017-01-21T03:25:53Z,run rustdoc tests in the same sort of thread rustc runs in,nikomatsakis,d25f066c07a88a5eeff1e3e8799a12ffe844e959,2,run rustdoc tests in the same sort of thread rustc runs in,THUMBS_UP,2017-01-26T15:17:59Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/39151,MERGED,2017-01-18T07:08:19Z,2017-01-19T18:31:46Z,Feature gate `&Void`'s uninhabitedness.,canndrew,2c6bc186100df68ba6dc7e7388e3708af7ba1539,3,Feature gate `&Void`'s uninhabitedness. References to empty types are only considered empty if feature(never_type) is enabled.,LAUGH,2017-01-18T07:14:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39151,MERGED,2017-01-18T07:08:19Z,2017-01-19T18:31:46Z,Feature gate `&Void`'s uninhabitedness.,canndrew,2c6bc186100df68ba6dc7e7388e3708af7ba1539,3,Feature gate `&Void`'s uninhabitedness. References to empty types are only considered empty if feature(never_type) is enabled.,LAUGH,2017-01-25T00:44:23Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/39151,MERGED,2017-01-18T07:08:19Z,2017-01-19T18:31:46Z,Feature gate `&Void`'s uninhabitedness.,canndrew,2c6bc186100df68ba6dc7e7388e3708af7ba1539,3,Feature gate `&Void`'s uninhabitedness. References to empty types are only considered empty if feature(never_type) is enabled.,LAUGH,2018-08-14T07:55:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/39157,MERGED,2017-01-18T16:30:43Z,2017-01-21T03:25:53Z,Add regression test for debuginfo + LTO,michaelwoerister,deeba3443e186628fca98e7b74a0ac0616c5fa2d,4,Add regression test for debuginfo + LTO,HOORAY,2017-01-21T23:37:28Z,alevy,NA https://github.com/rust-lang/rust/pull/39157,MERGED,2017-01-18T16:30:43Z,2017-01-21T03:25:53Z,Add regression test for debuginfo + LTO,michaelwoerister,deeba3443e186628fca98e7b74a0ac0616c5fa2d,4,Add regression test for debuginfo + LTO,HEART,2017-01-21T23:37:30Z,alevy,NA https://github.com/rust-lang/rust/pull/39157,MERGED,2017-01-18T16:30:43Z,2017-01-21T03:25:53Z,Add regression test for debuginfo + LTO,michaelwoerister,deeba3443e186628fca98e7b74a0ac0616c5fa2d,4,Add regression test for debuginfo + LTO,THUMBS_UP,2017-01-21T23:37:32Z,alevy,NA https://github.com/rust-lang/rust/pull/39200,MERGED,2017-01-20T03:33:31Z,2017-01-24T01:11:30Z,Docs for atomic orderings: link to the 'nomicon article for further reading,DirkyJerky,c0a5b99f01df01341500d4c23a724bddb029a9cb,1,Revert previous commit,THUMBS_UP,2017-01-20T05:59:33Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/39203,MERGED,2017-01-20T08:41:06Z,2017-01-21T19:09:27Z,Document that `Metadata` can be obtained from `symlink_metadata`,ranma42,780371107dd0bc1a880d14f1f4ebe9c5bfe627fd,1,Document that `Metadata` can be obtained from `symlink_metadata`,HEART,2017-01-20T12:14:03Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/39222,MERGED,2017-01-21T14:37:46Z,2017-01-24T17:56:25Z,Force backline on all where in docs,GuillaumeGomez,cbfc8fe3eb3f54b3ad89b87db75092acbed9926b,1,Force backline on all where in docs,THUMBS_UP,2017-01-21T14:48:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39222,MERGED,2017-01-21T14:37:46Z,2017-01-24T17:56:25Z,Force backline on all where in docs,GuillaumeGomez,cbfc8fe3eb3f54b3ad89b87db75092acbed9926b,1,Force backline on all where in docs,THUMBS_UP,2017-01-21T16:24:46Z,est31,NA https://github.com/rust-lang/rust/pull/39222,MERGED,2017-01-21T14:37:46Z,2017-01-24T17:56:25Z,Force backline on all where in docs,GuillaumeGomez,cbfc8fe3eb3f54b3ad89b87db75092acbed9926b,1,Force backline on all where in docs,THUMBS_UP,2017-01-21T16:39:40Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/39222,MERGED,2017-01-21T14:37:46Z,2017-01-24T17:56:25Z,Force backline on all where in docs,GuillaumeGomez,cbfc8fe3eb3f54b3ad89b87db75092acbed9926b,1,Force backline on all where in docs,THUMBS_UP,2017-01-22T20:26:01Z,jntrnr,NA https://github.com/rust-lang/rust/pull/39230,MERGED,2017-01-21T20:34:59Z,2017-01-31T02:32:03Z,Refactoring TyBox -> TyAdt,petrochenkov,93e3f634b096129227c3863b76a1f303716122f4,1,Fix debuginfo scope issue with `Box`,HOORAY,2017-01-21T20:45:25Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39230,MERGED,2017-01-21T20:34:59Z,2017-01-31T02:32:03Z,Refactoring TyBox -> TyAdt,petrochenkov,93e3f634b096129227c3863b76a1f303716122f4,1,Fix debuginfo scope issue with `Box`,HOORAY,2017-01-21T20:48:40Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/39230,MERGED,2017-01-21T20:34:59Z,2017-01-31T02:32:03Z,Refactoring TyBox -> TyAdt,petrochenkov,93e3f634b096129227c3863b76a1f303716122f4,1,Fix debuginfo scope issue with `Box`,HOORAY,2017-01-23T11:59:28Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39230,MERGED,2017-01-21T20:34:59Z,2017-01-31T02:32:03Z,Refactoring TyBox -> TyAdt,petrochenkov,93e3f634b096129227c3863b76a1f303716122f4,1,Fix debuginfo scope issue with `Box`,HOORAY,2017-01-31T09:34:27Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/39230,MERGED,2017-01-21T20:34:59Z,2017-01-31T02:32:03Z,Refactoring TyBox -> TyAdt,petrochenkov,93e3f634b096129227c3863b76a1f303716122f4,1,Fix debuginfo scope issue with `Box`,HOORAY,2017-02-09T00:33:21Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/39231,CLOSED,2017-01-21T20:47:49Z,2017-04-01T22:54:14Z,Detect missing `;` on methods with return type `()`,estebank,NA,NA,NA,THUMBS_UP,2017-03-29T16:20:18Z,zmanian,zaki@manian.org https://github.com/rust-lang/rust/pull/39234,MERGED,2017-01-21T23:01:57Z,2017-01-28T23:14:30Z,Make backtraces work on Windows GNU targets again.,segevfiner,ab21314c3fbf093c92123abee62101d15846c1e2,2,Disable backtrace tests on i686-pc-windows-gnu since it's broken by FPO,HOORAY,2017-01-22T05:43:12Z,retep998,NA https://github.com/rust-lang/rust/pull/39234,MERGED,2017-01-21T23:01:57Z,2017-01-28T23:14:30Z,Make backtraces work on Windows GNU targets again.,segevfiner,ab21314c3fbf093c92123abee62101d15846c1e2,2,Disable backtrace tests on i686-pc-windows-gnu since it's broken by FPO,HOORAY,2017-01-22T08:08:40Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/39251,MERGED,2017-01-23T04:19:48Z,2017-01-25T20:16:06Z,Remove a FIXME in core/hash tests,wesleywiser,91a478ec3451f5e45f099218efb05a77bd632d86,1,Remove a FIXME in core/hash tests,HEART,2017-01-23T12:10:57Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/39251,MERGED,2017-01-23T04:19:48Z,2017-01-25T20:16:06Z,Remove a FIXME in core/hash tests,wesleywiser,91a478ec3451f5e45f099218efb05a77bd632d86,1,Remove a FIXME in core/hash tests,HEART,2017-01-23T14:32:01Z,est31,NA https://github.com/rust-lang/rust/pull/39265,MERGED,2017-01-23T23:44:42Z,2017-02-09T14:25:05Z,Stabilize static lifetime in statics,est31,f8b6108deba112dcbff621635e00d5800cb425d3,7,Stabilize static in const Closes #35897.,HOORAY,2017-01-24T22:08:39Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/39265,MERGED,2017-01-23T23:44:42Z,2017-02-09T14:25:05Z,Stabilize static lifetime in statics,est31,f8b6108deba112dcbff621635e00d5800cb425d3,7,Stabilize static in const Closes #35897.,HOORAY,2017-01-29T17:48:04Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/39265,MERGED,2017-01-23T23:44:42Z,2017-02-09T14:25:05Z,Stabilize static lifetime in statics,est31,f8b6108deba112dcbff621635e00d5800cb425d3,7,Stabilize static in const Closes #35897.,HOORAY,2017-02-15T05:33:10Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/39271,MERGED,2017-01-24T17:23:36Z,2017-04-18T13:47:45Z,Add functions to safely transmute float to int,est31,0c148153f4de0c32206582ed9b51346f9769f10c,2,Add float_bits_conv to unstable book,THUMBS_UP,2017-03-19T00:01:57Z,causal-agent,june@causal.agency https://github.com/rust-lang/rust/pull/39271,MERGED,2017-01-24T17:23:36Z,2017-04-18T13:47:45Z,Add functions to safely transmute float to int,est31,0c148153f4de0c32206582ed9b51346f9769f10c,2,Add float_bits_conv to unstable book,THUMBS_UP,2017-04-03T21:35:17Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/39271,MERGED,2017-01-24T17:23:36Z,2017-04-18T13:47:45Z,Add functions to safely transmute float to int,est31,0c148153f4de0c32206582ed9b51346f9769f10c,2,Add float_bits_conv to unstable book,THUMBS_UP,2017-04-16T17:40:45Z,sean3z,seanwragg@gmail.com https://github.com/rust-lang/rust/pull/39271,MERGED,2017-01-24T17:23:36Z,2017-04-18T13:47:45Z,Add functions to safely transmute float to int,est31,0c148153f4de0c32206582ed9b51346f9769f10c,2,Add float_bits_conv to unstable book,THUMBS_UP,2017-04-26T08:42:08Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/39271,MERGED,2017-01-24T17:23:36Z,2017-04-18T13:47:45Z,Add functions to safely transmute float to int,est31,0c148153f4de0c32206582ed9b51346f9769f10c,2,Add float_bits_conv to unstable book,THUMBS_UP,2020-09-11T21:14:59Z,indolering,NA https://github.com/rust-lang/rust/pull/39277,MERGED,2017-01-24T21:17:56Z,2017-01-25T08:57:07Z,Update Fuchsia support for std::process. ,tedsta,bbe419ff30a7a39289cb6f897522af5896afc1f9,2,Updated Fuchsia support for std::process. Adds support for try_wait. Misc. updates to reflect changes in Magenta,HEART,2017-01-24T22:25:09Z,est31,NA https://github.com/rust-lang/rust/pull/39300,CLOSED,2017-01-25T19:16:13Z,2017-04-01T22:55:57Z,Highlight code in `rustc --explain` (WIP),estebank,NA,NA,NA,HEART,2017-01-25T20:11:53Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/39300,CLOSED,2017-01-25T19:16:13Z,2017-04-01T22:55:57Z,Highlight code in `rustc --explain` (WIP),estebank,NA,NA,NA,HEART,2017-01-25T20:29:07Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/39300,CLOSED,2017-01-25T19:16:13Z,2017-04-01T22:55:57Z,Highlight code in `rustc --explain` (WIP),estebank,NA,NA,NA,HEART,2017-01-25T20:58:48Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/39300,CLOSED,2017-01-25T19:16:13Z,2017-04-01T22:55:57Z,Highlight code in `rustc --explain` (WIP),estebank,NA,NA,NA,HEART,2019-09-27T17:52:21Z,codingCoffee,shenoy.ameya@gmail.com https://github.com/rust-lang/rust/pull/39307,MERGED,2017-01-26T00:43:16Z,2017-01-28T05:19:02Z,std: Stabilize APIs for the 1.16.0 release,alexcrichton,671b1c1d895c54903a10555196b789ebd5ff2c90,18,std: Stabilize APIs for the 1.16.0 release This commit applies the stabilization/deprecations of the 1.16.0 release as tracked by the rust-lang/rust issue tracker and the final-comment-period tag. The following APIs were stabilized: * `VecDeque::truncate` * `VecDeque::resize` * `String::insert_str` * `Duration::checked_{add sub div mul}` * `str::replacen` * `SocketAddr::is_ipv{4 6}` * `IpAddr::is_ipv{4 6}` * `str::repeat` * `Vec::dedup_by` * `Vec::dedup_by_key` * `Result::unwrap_or_default` * `<*const T>::wrapping_offset` * `<*mut T>::wrapping_offset` * `CommandExt::creation_flags` (on Windows) * `File::set_permissions` * `String::split_off` The following APIs were deprecated * `EnumSet` - replaced with other ecosystem abstractions long since unstable Closes #27788 Closes #35553 Closes #35774 Closes #36436 Closes #36949 Closes #37079 Closes #37087 Closes #37516 Closes #37827 Closes #37916 Closes #37966 Closes #38080,THUMBS_UP,2017-01-27T01:55:31Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/39307,MERGED,2017-01-26T00:43:16Z,2017-01-28T05:19:02Z,std: Stabilize APIs for the 1.16.0 release,alexcrichton,671b1c1d895c54903a10555196b789ebd5ff2c90,18,std: Stabilize APIs for the 1.16.0 release This commit applies the stabilization/deprecations of the 1.16.0 release as tracked by the rust-lang/rust issue tracker and the final-comment-period tag. The following APIs were stabilized: * `VecDeque::truncate` * `VecDeque::resize` * `String::insert_str` * `Duration::checked_{add sub div mul}` * `str::replacen` * `SocketAddr::is_ipv{4 6}` * `IpAddr::is_ipv{4 6}` * `str::repeat` * `Vec::dedup_by` * `Vec::dedup_by_key` * `Result::unwrap_or_default` * `<*const T>::wrapping_offset` * `<*mut T>::wrapping_offset` * `CommandExt::creation_flags` (on Windows) * `File::set_permissions` * `String::split_off` The following APIs were deprecated * `EnumSet` - replaced with other ecosystem abstractions long since unstable Closes #27788 Closes #35553 Closes #35774 Closes #36436 Closes #36949 Closes #37079 Closes #37087 Closes #37516 Closes #37827 Closes #37916 Closes #37966 Closes #38080,THUMBS_UP,2017-02-02T14:50:41Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/39309,MERGED,2017-01-26T02:03:34Z,2017-01-26T17:42:11Z,Rename tcx.map to the far more descriptive tcx.hir.,eddyb,1ff3641623ce5f83cba30c2d2f039dbd49c4b4b8,22,rustc: don't call the HIR AST.,THUMBS_UP,2017-01-26T03:23:41Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39314,MERGED,2017-01-26T10:12:11Z,2017-01-28T05:19:03Z,Rewrite the first sentence in slice::sort,NA,NA,NA,NA,THUMBS_UP,2017-01-26T15:29:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/39324,MERGED,2017-01-26T21:12:22Z,2017-02-08T02:49:28Z,Ipv6Addr <-> u128,clarfonthey,8b2e334e0e3d3324307c22d37c6620b479eff0f7,2,Ipv6Addr <-> u128,HEART,2017-01-26T21:17:53Z,est31,NA https://github.com/rust-lang/rust/pull/39324,MERGED,2017-01-26T21:12:22Z,2017-02-08T02:49:28Z,Ipv6Addr <-> u128,clarfonthey,8b2e334e0e3d3324307c22d37c6620b479eff0f7,2,Ipv6Addr <-> u128,HEART,2017-01-27T01:52:46Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/39324,MERGED,2017-01-26T21:12:22Z,2017-02-08T02:49:28Z,Ipv6Addr <-> u128,clarfonthey,8b2e334e0e3d3324307c22d37c6620b479eff0f7,2,Ipv6Addr <-> u128,HEART,2017-01-27T09:23:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39324,MERGED,2017-01-26T21:12:22Z,2017-02-08T02:49:28Z,Ipv6Addr <-> u128,clarfonthey,8b2e334e0e3d3324307c22d37c6620b479eff0f7,2,Ipv6Addr <-> u128,HEART,2017-01-27T23:35:06Z,achanda,NA https://github.com/rust-lang/rust/pull/39332,MERGED,2017-01-27T02:42:43Z,2017-01-28T05:19:04Z,Fix another endianness issue in i128 trans,nagisa,b8036b69086c6a43c86a20f0ac5e0bbc2d03fb9d,1,Fix another endian-ness issue in i128 trans Apparently LLVMArbitraryPrecisionInteger demands integers to be in low-endian 64-bytes rather than host-endian 64-bytes. This is weird and obviously not documented. Also fixed now. And rustc now works a teeny bit more on big endians.,HEART,2017-01-27T03:06:59Z,est31,NA https://github.com/rust-lang/rust/pull/39356,MERGED,2017-01-28T01:37:33Z,2017-02-03T22:55:33Z,Use `String::with_capacity` in `format!`,krdln,0267529681e2fac6ef4560afe7d8d439d04e6303,387,Merge remote-tracking branch 'upstream/master' into format-with-capacity,THUMBS_UP,2017-01-28T10:42:13Z,killercup,NA https://github.com/rust-lang/rust/pull/39356,MERGED,2017-01-28T01:37:33Z,2017-02-03T22:55:33Z,Use `String::with_capacity` in `format!`,krdln,0267529681e2fac6ef4560afe7d8d439d04e6303,387,Merge remote-tracking branch 'upstream/master' into format-with-capacity,THUMBS_UP,2017-01-28T21:26:19Z,fhartwig,florian.j.hartwig@gmail.com https://github.com/rust-lang/rust/pull/39356,MERGED,2017-01-28T01:37:33Z,2017-02-03T22:55:33Z,Use `String::with_capacity` in `format!`,krdln,0267529681e2fac6ef4560afe7d8d439d04e6303,387,Merge remote-tracking branch 'upstream/master' into format-with-capacity,HEART,2017-01-29T17:46:25Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/39356,MERGED,2017-01-28T01:37:33Z,2017-02-03T22:55:33Z,Use `String::with_capacity` in `format!`,krdln,0267529681e2fac6ef4560afe7d8d439d04e6303,387,Merge remote-tracking branch 'upstream/master' into format-with-capacity,THUMBS_UP,2017-02-16T12:01:29Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/39356,MERGED,2017-01-28T01:37:33Z,2017-02-03T22:55:33Z,Use `String::with_capacity` in `format!`,krdln,0267529681e2fac6ef4560afe7d8d439d04e6303,387,Merge remote-tracking branch 'upstream/master' into format-with-capacity,THUMBS_UP,2017-04-26T17:11:47Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/39361,MERGED,2017-01-28T14:41:35Z,2017-02-08T06:37:43Z,Improve error message for uninferrable types #38812,cengizIO,3fa28cb206604fddf67a29e7cbd3a8b22da1edc2,25,Add a new ui test and update existing ones,HOORAY,2017-01-29T21:35:48Z,estebank,NA https://github.com/rust-lang/rust/pull/39382,MERGED,2017-01-29T05:27:13Z,2017-01-30T00:18:04Z,travis: move IBM backwards in time,cuviper,cb47d9ffc3a4fcd66e38b9065bcb9a9487dea3fc,1,Fix the powerpc64 PATH,THUMBS_UP,2017-02-15T08:06:40Z,amboar,andrew@aj.id.au https://github.com/rust-lang/rust/pull/39382,MERGED,2017-01-29T05:27:13Z,2017-01-30T00:18:04Z,travis: move IBM backwards in time,cuviper,cb47d9ffc3a4fcd66e38b9065bcb9a9487dea3fc,1,Fix the powerpc64 PATH,THUMBS_UP,2017-02-16T18:02:04Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/39391,CLOSED,2017-01-29T11:40:21Z,2017-02-01T10:30:22Z,[WIP] Expand `#[derive(..)]`s in the InvocationCollector,keeperofdakeys,NA,NA,NA,HOORAY,2017-01-29T11:41:32Z,jseyfried,NA https://github.com/rust-lang/rust/pull/39400,MERGED,2017-01-29T22:16:05Z,2017-02-08T06:37:45Z,Add support for test suites emulated in QEMU,alexcrichton,1747ce25ad122e1b330eeb1eaf4e2d67f10b355d,23,Add support for test suites emulated in QEMU This commit adds support to the build system to execute test suites that cannot run natively but can instead run inside of a QEMU emulator. A proof-of-concept builder was added for the `arm-unknown-linux-gnueabihf` target to show off how this might work. In general the architecture is to have a server running inside of the emulator which a local client connects to. The protocol between the server/client supports compiling tests on the host and running them on the target inside the emulator. Closes #33114,HEART,2017-01-31T14:18:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39400,MERGED,2017-01-29T22:16:05Z,2017-02-08T06:37:45Z,Add support for test suites emulated in QEMU,alexcrichton,1747ce25ad122e1b330eeb1eaf4e2d67f10b355d,23,Add support for test suites emulated in QEMU This commit adds support to the build system to execute test suites that cannot run natively but can instead run inside of a QEMU emulator. A proof-of-concept builder was added for the `arm-unknown-linux-gnueabihf` target to show off how this might work. In general the architecture is to have a server running inside of the emulator which a local client connects to. The protocol between the server/client supports compiling tests on the host and running them on the target inside the emulator. Closes #33114,HEART,2017-05-11T12:30:43Z,malbarbo,NA https://github.com/rust-lang/rust/pull/39400,MERGED,2017-01-29T22:16:05Z,2017-02-08T06:37:45Z,Add support for test suites emulated in QEMU,alexcrichton,1747ce25ad122e1b330eeb1eaf4e2d67f10b355d,23,Add support for test suites emulated in QEMU This commit adds support to the build system to execute test suites that cannot run natively but can instead run inside of a QEMU emulator. A proof-of-concept builder was added for the `arm-unknown-linux-gnueabihf` target to show off how this might work. In general the architecture is to have a server running inside of the emulator which a local client connects to. The protocol between the server/client supports compiling tests on the host and running them on the target inside the emulator. Closes #33114,HEART,2017-11-08T14:49:21Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/39408,MERGED,2017-01-30T13:35:26Z,2017-02-05T19:33:57Z,Fix TryFrom for i128/u128,ollie27,a2de6e22858a02cfcf6bfc18ff40ebb163ebb07c,2,Fix TryFrom for i128/u128 Another case of `as` cast silent truncation being error prone. This also adds a few missing TryFrom tests to libcoretest.,THUMBS_UP,2017-02-07T19:09:23Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HEART,2017-01-30T17:21:45Z,est31,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-01-30T17:21:54Z,est31,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-01-30T18:59:16Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-01-31T10:12:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-01-31T11:57:58Z,arthurprs,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HEART,2017-01-31T11:57:59Z,arthurprs,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-01-31T22:10:31Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-02-02T15:23:56Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-06-29T18:23:34Z,tux3,NA https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HOORAY,2017-07-18T00:14:14Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39409,MERGED,2017-01-30T14:17:33Z,2017-06-19T15:23:37Z,MIR EndRegion Statements (was MIR dataflow for Borrows),pnkfelix,11f4968bd7372ed3986ff7d83fb14218ef0f2f20,1,Revised comment explaining my addition of case for `TerminatorKind::Resume`. Also I removed the `continue;` statement. I don't think it makes a difference whether its there or not but having it there confuses things when the actual goal was to side-step the assertion in the default case.,HEART,2017-08-21T20:49:49Z,cengizIO,NA https://github.com/rust-lang/rust/pull/39416,MERGED,2017-01-31T00:05:59Z,2017-02-03T00:48:02Z,rustdoc: mark FFI functions with unsafety icon,tspiteri,fe324cea6490fc6e7ce16fb5209fde57cfa1b94f,1,rustdoc: mark ffi functions with unsafety icon,THUMBS_UP,2017-01-31T11:10:12Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T21:51:23Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T21:51:28Z,sfackler,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T21:55:31Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T21:58:49Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T22:07:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T22:08:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-01-31T22:17:25Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T01:52:12Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-01T01:52:14Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-01T01:52:19Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T02:14:34Z,xen0n,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T03:23:24Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T04:00:54Z,retep998,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T10:28:57Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T10:47:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-01T12:24:58Z,achanda,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T13:51:01Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T15:31:02Z,killercup,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-01T17:14:41Z,alexbool,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T17:14:42Z,alexbool,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T20:08:58Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-01T23:12:46Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-01T23:12:46Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-01T23:12:47Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-02T18:53:32Z,yigal100,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-02T19:01:27Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-02T19:35:09Z,est31,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-02T19:35:10Z,est31,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-02T19:35:28Z,est31,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-02T19:58:53Z,robinro,robin@rroth.de https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-02T20:49:26Z,JrSchild,joram.ruitenschild@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-02T21:03:37Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-02T21:56:08Z,Diggsey,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_DOWN,2017-02-02T21:58:55Z,Conan-Kudo,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_DOWN,2017-02-02T22:58:27Z,tjkirch,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-03T00:20:31Z,rajsite,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-03T00:55:11Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-03T00:55:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-03T00:55:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-03T04:55:30Z,critiqjo,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-03T04:55:51Z,critiqjo,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-03T09:28:27Z,jansegre,jan@hathor.network https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-03T09:28:28Z,jansegre,jan@hathor.network https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-03T10:15:19Z,jtepe,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-03T10:15:22Z,jtepe,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-03T10:15:24Z,jtepe,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-03T20:06:38Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-03T22:56:28Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-03T22:56:29Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-03T22:56:30Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-04T09:28:59Z,tpimh,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-05T01:23:04Z,cristicbz,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-05T22:40:13Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-06T10:29:34Z,Sharez,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-06T10:29:39Z,Sharez,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-06T14:40:59Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-06T14:41:07Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-06T14:41:09Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-06T15:31:25Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-06T15:31:25Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-06T15:31:26Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-07T07:25:39Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T07:01:09Z,king6cong,king6cong@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T07:01:15Z,king6cong,king6cong@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-08T07:01:20Z,king6cong,king6cong@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T09:54:21Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T15:49:01Z,iovxw,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T16:05:53Z,onur,onur@onur.im https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T16:17:48Z,s3rvac,s3rvac@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T16:18:21Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T17:03:03Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T17:19:39Z,Henning-K,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T17:19:41Z,Henning-K,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T17:25:12Z,jwilm,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T17:45:10Z,cevn,sdhar@pm.me https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T17:50:12Z,fsck,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T17:54:20Z,rustyrazorblade,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T18:13:06Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T18:26:12Z,emilhf,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T18:28:27Z,ihrwein,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T18:40:18Z,ambaxter,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T18:44:57Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T18:45:00Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T18:56:48Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T18:56:50Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-08T18:56:52Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T19:39:01Z,kwaegel,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T20:01:34Z,zen0wu,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T20:08:21Z,TheNeikos,neikos@neikos.email https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T20:42:22Z,lucazulian,contact@lucazulian.it https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T21:13:53Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T22:16:50Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T23:27:29Z,tikue,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-08T23:36:29Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T23:36:30Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-08T23:36:31Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-08T23:57:16Z,xrl,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-09T00:38:26Z,lawliet89,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-09T02:29:45Z,vermiculus,code@seanallred.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T04:41:37Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-09T05:49:43Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-09T05:49:44Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T07:12:44Z,vmchale,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-09T07:16:03Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T07:16:05Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-09T07:16:09Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-09T10:07:57Z,levex,lev@boilerplate.co https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T12:07:25Z,knightbat,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T13:44:47Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-09T14:18:26Z,AlexanderEkdahl,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-09T15:15:01Z,m0rl,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-09T15:53:45Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-10T06:46:13Z,J-F-Liu,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-15T09:54:47Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-15T11:55:22Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-15T19:06:57Z,ChristianBeilschmidt,christian.beilschmidt@geoengine.de https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-15T20:02:28Z,cyplo,cyplo@cyplo.net https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-16T00:21:32Z,minikomi,nerdfunk@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-16T00:32:16Z,reneklacan,rene@klacan.sk https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-16T00:32:31Z,reneklacan,rene@klacan.sk https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-16T00:32:33Z,reneklacan,rene@klacan.sk https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-16T08:10:03Z,ccyang314,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-02-16T21:19:49Z,whymarrh,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-16T21:19:51Z,whymarrh,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2017-02-17T13:35:18Z,teozkr,teo@nullable.se https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-02-22T11:12:18Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-04-27T17:42:23Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-27T17:50:34Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-04-27T17:50:35Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-27T17:51:49Z,gchp,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-28T03:21:59Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-04-28T03:22:00Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-28T08:03:39Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-28T17:19:16Z,Songbird0,chaacygg@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-04-29T12:40:00Z,syusui-s,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-04-30T17:49:22Z,TheWaWaR,thewawar@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-09-17T18:39:19Z,christianpv,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2017-12-23T11:49:51Z,veekxt,veekxt@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2017-12-23T11:49:55Z,veekxt,veekxt@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2018-09-07T01:15:42Z,msal4,msal4@outlook.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2019-10-29T14:57:04Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2020-05-15T15:19:14Z,sanrodari,sanrodari@gmail.com https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,THUMBS_UP,2020-10-23T10:02:20Z,nasso,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HEART,2020-10-23T10:02:21Z,nasso,NA https://github.com/rust-lang/rust/pull/39431,MERGED,2017-01-31T21:51:05Z,2017-02-08T06:37:45Z,Delete the makefile build system,alexcrichton,c8e0d04878f38e8a91e7a6196fb18878da208887,5,compiletest: Add caching of test results Don't re-run tests in compiletest if all the inputs haven't changed manage stamp files in the output directory.,HOORAY,2020-10-23T10:02:27Z,nasso,NA https://github.com/rust-lang/rust/pull/39458,CLOSED,2017-02-02T09:54:00Z,2017-04-01T22:56:53Z,Distinguish guesses from suggestions,oli-obk,NA,NA,NA,HOORAY,2017-02-02T11:07:51Z,killercup,NA https://github.com/rust-lang/rust/pull/39458,CLOSED,2017-02-02T09:54:00Z,2017-04-01T22:56:53Z,Distinguish guesses from suggestions,oli-obk,NA,NA,NA,HEART,2017-02-02T20:21:59Z,mcarton,NA https://github.com/rust-lang/rust/pull/39463,MERGED,2017-02-02T18:26:01Z,2017-02-04T01:31:35Z,Bump version upgrade bootstrap,alexcrichton,626e754473da96a670c917b9cbefd1c1ea888a9c,65,Bump version upgrade bootstrap This commit updates the version number to 1.17.0 as we're not on that version of the nightly compiler and at the same time this updates src/stage0.txt to bootstrap from freshly minted beta compiler and beta Cargo.,HEART,2017-02-02T19:14:45Z,est31,NA https://github.com/rust-lang/rust/pull/39466,MERGED,2017-02-02T19:28:04Z,2017-02-03T03:23:39Z,std: Fix IntoIter::as_mut_slice's signature,alexcrichton,80f7db63b6e658468f181d602767c8da412459d2,1,std: Fix IntoIter::as_mut_slice's signature This was intended to require `&mut self` not `&self` otherwise it's unsound! Closes #39465,THUMBS_UP,2017-02-02T21:08:24Z,beatgammit,jameson.little@pm.me https://github.com/rust-lang/rust/pull/39466,MERGED,2017-02-02T19:28:04Z,2017-02-03T03:23:39Z,std: Fix IntoIter::as_mut_slice's signature,alexcrichton,80f7db63b6e658468f181d602767c8da412459d2,1,std: Fix IntoIter::as_mut_slice's signature This was intended to require `&mut self` not `&self` otherwise it's unsound! Closes #39465,THUMBS_UP,2017-02-03T11:33:48Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/39466,MERGED,2017-02-02T19:28:04Z,2017-02-03T03:23:39Z,std: Fix IntoIter::as_mut_slice's signature,alexcrichton,80f7db63b6e658468f181d602767c8da412459d2,1,std: Fix IntoIter::as_mut_slice's signature This was intended to require `&mut self` not `&self` otherwise it's unsound! Closes #39465,THUMBS_UP,2017-02-03T13:24:14Z,bluss,NA https://github.com/rust-lang/rust/pull/39466,MERGED,2017-02-02T19:28:04Z,2017-02-03T03:23:39Z,std: Fix IntoIter::as_mut_slice's signature,alexcrichton,80f7db63b6e658468f181d602767c8da412459d2,1,std: Fix IntoIter::as_mut_slice's signature This was intended to require `&mut self` not `&self` otherwise it's unsound! Closes #39465,THUMBS_UP,2017-02-03T16:59:04Z,ambaxter,NA https://github.com/rust-lang/rust/pull/39477,MERGED,2017-02-03T01:45:28Z,2017-02-05T16:57:05Z,Add a name for the parameter to `TryFrom::try_from`.,jimmycuadra,2add6ac14a29d5d828f4da01ee0a09db0f472975,1,Add a name for the parameter to `TryFrom::try_from`. Although signatures with anonymous parameters may not be deprecated or removed at this point the team seems to agree that the ability to have an anonymous parameter is unfortunate historical baggage and that we shouldn't create new code that uses it. Context: https://github.com/rust-lang/rust/issues/33417#issuecomment-276933861,THUMBS_UP,2017-02-03T23:40:50Z,Ixrec,NA https://github.com/rust-lang/rust/pull/39490,MERGED,2017-02-03T16:15:22Z,2017-02-11T02:29:40Z,Add Emscripten-specific linker,RReverser,f35b598bbf3bb86f70c731b8ef981beada052a08,1,Disable memory init file until further notice It's support is currently too buggy in both Rust tests and Cargo.,HEART,2017-02-03T17:23:24Z,est31,NA https://github.com/rust-lang/rust/pull/39490,MERGED,2017-02-03T16:15:22Z,2017-02-11T02:29:40Z,Add Emscripten-specific linker,RReverser,f35b598bbf3bb86f70c731b8ef981beada052a08,1,Disable memory init file until further notice It's support is currently too buggy in both Rust tests and Cargo.,HEART,2017-02-03T21:05:03Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39490,MERGED,2017-02-03T16:15:22Z,2017-02-11T02:29:40Z,Add Emscripten-specific linker,RReverser,f35b598bbf3bb86f70c731b8ef981beada052a08,1,Disable memory init file until further notice It's support is currently too buggy in both Rust tests and Cargo.,HEART,2017-02-12T17:04:28Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/39491,MERGED,2017-02-03T17:01:57Z,2017-02-05T22:10:48Z,Support aarch64-unknown-freebsd,dumbbell,f6c6b31d26b5b08fbd1df907e37c5c02c7d71f90,2,`aarch64` CPU type is called `arm64` on FreeBSD,HOORAY,2017-04-05T12:41:00Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/39530,MERGED,2017-02-04T10:55:50Z,2017-02-05T22:10:51Z,ignore more gdb versions with buggy rust support,TimNN,112a5a00e839bfb3dbdaa9166afe595163248174,10,ignore more gdb versions with buggy rust support,HEART,2017-02-06T09:35:28Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39538,MERGED,2017-02-04T15:40:29Z,2017-02-05T22:10:51Z,Slightly optimize slice::sort,NA,NA,NA,NA,THUMBS_UP,2017-02-07T18:18:04Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39538,MERGED,2017-02-04T15:40:29Z,2017-02-05T22:10:51Z,Slightly optimize slice::sort,NA,NA,NA,NA,THUMBS_UP,2017-02-07T22:15:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/39538,MERGED,2017-02-04T15:40:29Z,2017-02-05T22:10:51Z,Slightly optimize slice::sort,NA,NA,NA,NA,HOORAY,2017-02-07T22:52:04Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/39554,MERGED,2017-02-05T07:01:07Z,2017-02-12T06:11:49Z,improve error message when two-arg assert_eq! receives a trailing comma,zackmdavis,65435e14febd9d8aa1d40a19cd1adb427263c48e,5,"improve error message when two-arg assert_eq! receives a trailing comma Previously `assert_eq!(left right )` (respectively `assert_ne!(left right )`; note the trailing comma) would result in a confusing ""requires at least a format string argument"" error. In reality a format string is optional but the trailing comma puts us into the ""match a token tree of zero or more tokens"" branch of the macro (in order to support the optional format string) and passing the empty token tree into `format_args!` results in the confusing error. If instead we match a token tree of one or more tokens we get a much more sensible ""unexpected end of macro invocation"" error. While we're here fix up a stray space before a comma in the match guards. Resolves #39369.",HEART,2017-02-11T23:56:48Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/39578,MERGED,2017-02-06T08:33:46Z,2017-02-17T18:17:48Z,Fix for bootstrapping on NixOS,canndrew,5e324bdc91415ae222becf362f68ffdebf3ec804,1,Style fixups,HEART,2017-02-11T01:06:43Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39589,MERGED,2017-02-06T18:15:51Z,2017-02-09T08:54:24Z,rustdoc: Improve impl disambiguation,ollie27,05eef36fa5ff9235ea8124a6396c7973015b4b8b,3,rustdoc: Improve impl disambiguation * Don't disambiguate if there are multiple impls for the same type. * Disambiguate for impls of &Foo and &mut Foo. * Don't try to disambiguate generic types.,THUMBS_UP,2017-02-07T01:34:08Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39593,MERGED,2017-02-06T20:06:59Z,2017-02-08T06:37:49Z,Re-write the doc index page,steveklabnik,78dd2ec2c28e8238770d1a04a419b8193a7567c1,1,review nits,HEART,2017-02-06T20:11:24Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/39593,MERGED,2017-02-06T20:06:59Z,2017-02-08T06:37:49Z,Re-write the doc index page,steveklabnik,78dd2ec2c28e8238770d1a04a419b8193a7567c1,1,review nits,HOORAY,2017-02-06T20:12:41Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/39602,MERGED,2017-02-06T23:50:18Z,2017-02-09T17:09:53Z,Fix ICE when accessing mutably an immutable enum,estebank,df73bc9c9d550c2517edc3cf49164d9e93c5b152,3,Fix ICE when accessing mutably an immutable enum,HEART,2017-02-07T00:16:42Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39602,MERGED,2017-02-06T23:50:18Z,2017-02-09T17:09:53Z,Fix ICE when accessing mutably an immutable enum,estebank,df73bc9c9d550c2517edc3cf49164d9e93c5b152,3,Fix ICE when accessing mutably an immutable enum,HEART,2017-02-07T00:29:10Z,drbawb,NA https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HOORAY,2017-02-13T11:09:00Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HEART,2017-02-13T11:09:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HOORAY,2017-02-13T11:10:13Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HEART,2017-02-13T11:10:14Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HEART,2017-02-15T18:18:25Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HEART,2017-03-08T21:33:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HOORAY,2017-03-08T21:33:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39628,MERGED,2017-02-07T22:08:02Z,2017-03-20T20:59:57Z,Translate shims using MIR,arielb1,5dc8548050514b0781af7b21a4706552da18dd50,2,update LLVM pick up a fix to LLVM PR29151.,HEART,2017-03-29T18:03:16Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39633,MERGED,2017-02-08T00:24:01Z,2017-02-15T03:49:22Z,Port books to mdbook,steveklabnik,cacb3bc9c741a7d41a1085af850cd3ff852307f5,1,fix up linkchecker 1. skip png files 2. skip fragments for the book and nomicon as these are added by JS 3. Actually print the filename for errors,HOORAY,2017-02-08T02:07:28Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/39633,MERGED,2017-02-08T00:24:01Z,2017-02-15T03:49:22Z,Port books to mdbook,steveklabnik,cacb3bc9c741a7d41a1085af850cd3ff852307f5,1,fix up linkchecker 1. skip png files 2. skip fragments for the book and nomicon as these are added by JS 3. Actually print the filename for errors,HOORAY,2017-02-08T15:04:50Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/39633,MERGED,2017-02-08T00:24:01Z,2017-02-15T03:49:22Z,Port books to mdbook,steveklabnik,cacb3bc9c741a7d41a1085af850cd3ff852307f5,1,fix up linkchecker 1. skip png files 2. skip fragments for the book and nomicon as these are added by JS 3. Actually print the filename for errors,HOORAY,2017-02-08T22:20:43Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/39633,MERGED,2017-02-08T00:24:01Z,2017-02-15T03:49:22Z,Port books to mdbook,steveklabnik,cacb3bc9c741a7d41a1085af850cd3ff852307f5,1,fix up linkchecker 1. skip png files 2. skip fragments for the book and nomicon as these are added by JS 3. Actually print the filename for errors,HOORAY,2017-02-09T04:17:45Z,brson,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-08T18:11:48Z,arthurprs,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-08T18:20:15Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-08T18:43:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-08T19:55:12Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-08T23:40:06Z,Ixrec,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-09T07:40:12Z,oli-obk,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-09T09:53:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-10T08:42:31Z,alexbool,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-11T20:03:15Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-12T11:49:52Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-12T13:56:02Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-13T06:04:48Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-15T17:32:33Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-02-21T11:44:27Z,bluss,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-03-05T09:57:20Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/39648,MERGED,2017-02-08T17:35:18Z,2017-03-11T10:29:10Z,[MIR] Implement Inlining,Aatch,3eb26d1f2bd9bd8d2c8f72d624d45f94bfe39695,1,Only run inlining if mir opts are enabled,HOORAY,2017-03-15T06:03:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/39655,MERGED,2017-02-08T22:07:18Z,2017-03-02T20:10:42Z,suggest doubling recursion limit in more situations,durka,6e259dc77870d278a37bbc42bcbc5fad64b75930,4,note -> help,HEART,2017-02-09T01:27:08Z,bluss,NA https://github.com/rust-lang/rust/pull/39659,MERGED,2017-02-08T22:46:39Z,2017-02-15T01:22:18Z,Add equivalents of C's functions to AsciiExt.,zackw,162240c744fa415602dcd56f08895b9583037717,1,Add feature annotations to the doctests for ascii_ctype.,HEART,2017-02-08T23:28:09Z,fitzgen,NA https://github.com/rust-lang/rust/pull/39659,MERGED,2017-02-08T22:46:39Z,2017-02-15T01:22:18Z,Add equivalents of C's functions to AsciiExt.,zackw,162240c744fa415602dcd56f08895b9583037717,1,Add feature annotations to the doctests for ascii_ctype.,THUMBS_UP,2017-02-23T09:52:06Z,aldanor,NA https://github.com/rust-lang/rust/pull/39682,MERGED,2017-02-09T11:18:02Z,2017-02-10T00:41:28Z,Fix unsafe unaligned loads in test.,solson,2589f4a7511ab04a3325b0372cd2ae174940c6c8,1,Fix indentation in test.,THUMBS_UP,2017-02-09T12:02:20Z,retep998,NA https://github.com/rust-lang/rust/pull/39682,MERGED,2017-02-09T11:18:02Z,2017-02-10T00:41:28Z,Fix unsafe unaligned loads in test.,solson,2589f4a7511ab04a3325b0372cd2ae174940c6c8,1,Fix indentation in test.,HEART,2017-02-09T22:03:06Z,bluss,NA https://github.com/rust-lang/rust/pull/39697,MERGED,2017-02-09T17:51:18Z,2017-02-12T20:53:10Z,Add the item type to the tooltip,notriddle,bc4ad1a2c9fb4a9f9f4793e0b62404f3e6150132,1,Add the short type to inline links too,HEART,2017-02-09T18:06:08Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/39697,MERGED,2017-02-09T17:51:18Z,2017-02-12T20:53:10Z,Add the item type to the tooltip,notriddle,bc4ad1a2c9fb4a9f9f4793e0b62404f3e6150132,1,Add the short type to inline links too,HEART,2017-02-09T18:12:14Z,fitzgen,NA https://github.com/rust-lang/rust/pull/39697,MERGED,2017-02-09T17:51:18Z,2017-02-12T20:53:10Z,Add the item type to the tooltip,notriddle,bc4ad1a2c9fb4a9f9f4793e0b62404f3e6150132,1,Add the short type to inline links too,HEART,2017-02-09T23:25:26Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39702,CLOSED,2017-02-09T19:19:58Z,2017-03-06T21:47:27Z,Allow `foo.rs` to be parent to `foo/bar.rs`,withoutboats,NA,NA,NA,THUMBS_UP,2017-02-09T19:33:20Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/39702,CLOSED,2017-02-09T19:19:58Z,2017-03-06T21:47:27Z,Allow `foo.rs` to be parent to `foo/bar.rs`,withoutboats,NA,NA,NA,THUMBS_UP,2017-02-10T07:59:13Z,jseyfried,NA https://github.com/rust-lang/rust/pull/39702,CLOSED,2017-02-09T19:19:58Z,2017-03-06T21:47:27Z,Allow `foo.rs` to be parent to `foo/bar.rs`,withoutboats,NA,NA,NA,THUMBS_UP,2017-02-28T22:14:07Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/39702,CLOSED,2017-02-09T19:19:58Z,2017-03-06T21:47:27Z,Allow `foo.rs` to be parent to `foo/bar.rs`,withoutboats,NA,NA,NA,THUMBS_UP,2018-10-28T07:17:43Z,takanuva,NA https://github.com/rust-lang/rust/pull/39705,MERGED,2017-02-09T21:41:24Z,2017-02-10T07:26:45Z,name anonymous fn parameters in libcore traits,tspiteri,e626a6807c44d097996b0f32a4e03b105837f9da,3,name anonymous fn parameters in libcore traits,HOORAY,2017-02-10T02:30:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/39705,MERGED,2017-02-09T21:41:24Z,2017-02-10T07:26:45Z,name anonymous fn parameters in libcore traits,tspiteri,e626a6807c44d097996b0f32a4e03b105837f9da,3,name anonymous fn parameters in libcore traits,HEART,2017-02-10T10:17:00Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/39713,MERGED,2017-02-10T01:59:26Z,2017-03-08T12:17:14Z,"Clean up ""pattern doesn't bind x"" messages",estebank,3ffa4b52404d9a6aff7390d44336f85166235ff5,1,Use `BTreeSet` instead of `FxHashSet`,THUMBS_UP,2017-02-14T22:16:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39713,MERGED,2017-02-10T01:59:26Z,2017-03-08T12:17:14Z,"Clean up ""pattern doesn't bind x"" messages",estebank,3ffa4b52404d9a6aff7390d44336f85166235ff5,1,Use `BTreeSet` instead of `FxHashSet`,THUMBS_UP,2017-03-05T15:56:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39713,MERGED,2017-02-10T01:59:26Z,2017-03-08T12:17:14Z,"Clean up ""pattern doesn't bind x"" messages",estebank,3ffa4b52404d9a6aff7390d44336f85166235ff5,1,Use `BTreeSet` instead of `FxHashSet`,THUMBS_UP,2017-03-08T09:32:51Z,bombless,NA https://github.com/rust-lang/rust/pull/39716,MERGED,2017-02-10T09:08:58Z,2017-02-13T23:30:41Z,Add `swap` method for `Cell`,F001,a5e8bbf32b32ed7d3b06149fdfa0977c0ec0a22e,1,Add `swap` method for `Cell`,HEART,2017-02-22T10:28:02Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,HEART,2017-02-11T01:16:09Z,est31,NA https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,HOORAY,2017-02-11T01:16:12Z,est31,NA https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,THUMBS_UP,2017-02-11T01:16:13Z,est31,NA https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,HOORAY,2017-02-11T04:43:47Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,THUMBS_UP,2017-02-13T01:45:51Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,HOORAY,2017-02-13T01:45:52Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,HEART,2017-02-13T01:45:53Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39728,MERGED,2017-02-10T21:40:46Z,2017-02-14T09:37:42Z,Automate vendoring by invoking cargo-vendor when building src dist tarballs.,eddyb,d29f0bc8fa166117e62b1fa2969dd31f415fd887,27,Automatically vendor Cargo deps when building the source tarballs.,THUMBS_UP,2017-04-29T01:30:14Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/39740,MERGED,2017-02-11T12:19:52Z,2017-02-12T20:53:11Z,rustdoc: Only include a stability span if needed.,jimmycuadra,1fa9dbc00e8d5eff8f698097afb112c142bb8da0,1,Use functional transformations on the option instead of matching.,THUMBS_UP,2017-02-11T13:33:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39740,MERGED,2017-02-11T12:19:52Z,2017-02-12T20:53:11Z,rustdoc: Only include a stability span if needed.,jimmycuadra,1fa9dbc00e8d5eff8f698097afb112c142bb8da0,1,Use functional transformations on the option instead of matching.,THUMBS_UP,2017-02-11T13:49:01Z,est31,NA https://github.com/rust-lang/rust/pull/39740,MERGED,2017-02-11T12:19:52Z,2017-02-12T20:53:11Z,rustdoc: Only include a stability span if needed.,jimmycuadra,1fa9dbc00e8d5eff8f698097afb112c142bb8da0,1,Use functional transformations on the option instead of matching.,THUMBS_UP,2017-02-11T16:22:47Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39740,MERGED,2017-02-11T12:19:52Z,2017-02-12T20:53:11Z,rustdoc: Only include a stability span if needed.,jimmycuadra,1fa9dbc00e8d5eff8f698097afb112c142bb8da0,1,Use functional transformations on the option instead of matching.,THUMBS_UP,2017-02-12T01:54:24Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39754,MERGED,2017-02-12T01:51:56Z,2017-02-15T01:22:19Z,travis: Add builders without assertions,alexcrichton,0340ddeb3bcfcd0cfe6a0c4745293ecf2b733dac,4,"travis: Add builders without assertions This commit adds three new builders one OSX one Linux and one MSVC which will produce ""nightlies"" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels however do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.",HEART,2017-02-12T03:56:45Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/39754,MERGED,2017-02-12T01:51:56Z,2017-02-15T01:22:19Z,travis: Add builders without assertions,alexcrichton,0340ddeb3bcfcd0cfe6a0c4745293ecf2b733dac,4,"travis: Add builders without assertions This commit adds three new builders one OSX one Linux and one MSVC which will produce ""nightlies"" with LLVM assertions disabled. Currently all nightly releases have LLVM assertions enabled to catch bugs before they reach the beta/stable channels. The beta/stable channels however do not have LLVM assertions enabled. Unfortunately though projects like Servo are stuck on nightlies for the near future at least and are also suffering very long compile times. The purpose of this commit is to provide artifacts to these projects which are not distributed through normal channels (e.g. rustup) but are provided for developers to use locally if need be. Logistically these builds will all be uploaded to `rustc-builds-alt` instead of the `rustc-builds` folder of the `rust-lang-ci` bucket. These builds will stay there forever (until cleaned out if necessary) and there are no plans to integrate this with rustup and/or the official release process.",HOORAY,2017-02-13T16:55:31Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/39757,CLOSED,2017-02-12T02:19:57Z,2017-02-17T13:55:06Z,Document return value of zero-size/zero-heap pointer types.,frewsxcv,NA,NA,NA,THUMBS_UP,2017-02-12T02:21:42Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/39760,MERGED,2017-02-12T04:43:11Z,2017-02-12T20:53:12Z,Improve grammar on field init docs,shepmaster,037ef0bbc88742187e6059a846f027bb99884267,2,Improve grammar on field init docs,THUMBS_UP,2017-02-12T06:19:09Z,est31,NA https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-12T12:11:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-12T17:57:41Z,kylewlacy,NA https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-13T02:51:02Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-15T02:03:26Z,theduke,NA https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-16T15:34:34Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-16T18:24:46Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-16T19:05:57Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-16T22:06:47Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-17T12:19:26Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/39761,MERGED,2017-02-12T06:17:59Z,2017-02-16T05:52:48Z,Stabilize field init shorthand,est31,aebd94fd3c151212723906fb0445f0153917abac,11,Stabilize field init shorthand Closes #37340.,HOORAY,2017-02-23T23:13:59Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/39765,MERGED,2017-02-12T14:20:29Z,2017-02-21T23:46:22Z,File not found for module error,GuillaumeGomez,b6818be41dea90e53344f84770f5e0faaacee4a8,2,Add long error explanations,THUMBS_UP,2017-02-12T15:51:53Z,frgtn,NA https://github.com/rust-lang/rust/pull/39770,MERGED,2017-02-12T19:32:33Z,2017-03-12T08:08:59Z,Delete more swaths of the configure script,alexcrichton,f8ca805422db8ff5c5112526db0794603b259577,3,configure: Remove --build detection This commit removes detection of CFG_OSTYPE and CFG_CPUTYPE from the configure script which means that the default value of `--build` is no longer present in the configure script. All this logic is now available in rustbuild itself so there's no need to duplicate it.,THUMBS_UP,2017-02-12T19:40:31Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39770,MERGED,2017-02-12T19:32:33Z,2017-03-12T08:08:59Z,Delete more swaths of the configure script,alexcrichton,f8ca805422db8ff5c5112526db0794603b259577,3,configure: Remove --build detection This commit removes detection of CFG_OSTYPE and CFG_CPUTYPE from the configure script which means that the default value of `--build` is no longer present in the configure script. All this logic is now available in rustbuild itself so there's no need to duplicate it.,THUMBS_UP,2017-03-15T04:17:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39793,MERGED,2017-02-13T19:32:54Z,2017-02-16T08:18:26Z,Allow more Cell methods for non-Copy types,RalfJung,044ed10fee3351da2315d5d8e26949929ad918ce,1,Remove Copy bound from some Cell trait impls Contributes to #39264,HOORAY,2017-02-13T19:39:46Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39793,MERGED,2017-02-13T19:32:54Z,2017-02-16T08:18:26Z,Allow more Cell methods for non-Copy types,RalfJung,044ed10fee3351da2315d5d8e26949929ad918ce,1,Remove Copy bound from some Cell trait impls Contributes to #39264,THUMBS_UP,2017-02-13T19:39:49Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-14T23:12:37Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T00:48:26Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T01:46:57Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T03:06:39Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T03:12:56Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T03:20:27Z,causal-agent,june@causal.agency https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T10:25:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",THUMBS_UP,2017-02-15T10:25:37Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HOORAY,2017-02-15T10:25:41Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-02-15T16:13:58Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HOORAY,2017-03-08T06:31:41Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-03-08T08:32:39Z,jdub,NA https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-03-26T19:05:28Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-03-27T01:36:05Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2017-07-27T12:30:39Z,TengenJulian,NA https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2018-02-24T01:01:11Z,Techno-coder,NA https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",THUMBS_UP,2018-03-28T11:29:27Z,jzck,jack@0x5.be https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2018-03-28T11:29:28Z,jzck,jack@0x5.be https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HOORAY,2018-03-28T11:29:30Z,jzck,jack@0x5.be https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2019-01-19T12:51:18Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HOORAY,2019-01-19T12:51:21Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",THUMBS_UP,2019-01-19T12:51:21Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2021-02-02T01:44:20Z,rafikk,r@rafiksalama.com https://github.com/rust-lang/rust/pull/39832,MERGED,2017-02-14T23:06:08Z,2017-03-02T22:15:44Z,Add support for the x86-interrupt calling convention,phil-opp,b44805875e3d2e7ac42052cf90d3d7dade90567c,7,"Add support for x86-interrupt calling convention Tracking issue: https://github.com/rust-lang/rust/issues/40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern ""x86-interrupt"" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern ""x86-interrupt"" fn page_fault_handler(stack_frame: &ExceptionStackFrame error_code: u64) {…} ``` for exceptions that push an error code (e.g. page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html",HEART,2021-11-14T08:48:51Z,Prasanna19971124,NA https://github.com/rust-lang/rust/pull/39837,MERGED,2017-02-15T04:12:58Z,2017-02-18T00:32:35Z,rustc: Link statically to the MSVCRT,alexcrichton,c02c44db724ddf63e6d5a3725dd5cd7f8c344052,3,rustc: Link statically to the MSVCRT This commit changes all MSVC rustc binaries to be compiled with `-C target-feature=+crt-static` to link statically against the MSVCRT instead of dynamically (as it does today). This also necessitates compiling LLVM in a different fashion ensuring it's compiled with `/MT` instead of `/MD`. cc #37406,HOORAY,2017-02-15T04:32:48Z,retep998,NA https://github.com/rust-lang/rust/pull/39843,MERGED,2017-02-15T10:43:36Z,2017-02-16T08:18:28Z,Vec LinkedList VecDeque String and Option NatVis visualizations,AndrewGaspar,a8b7b28babdb49387eb56626b8359d7295515775,2,Vec LinkedList VecDeque String and Option NatVis visualizations,THUMBS_UP,2017-02-15T11:18:35Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/39843,MERGED,2017-02-15T10:43:36Z,2017-02-16T08:18:28Z,Vec LinkedList VecDeque String and Option NatVis visualizations,AndrewGaspar,a8b7b28babdb49387eb56626b8359d7295515775,2,Vec LinkedList VecDeque String and Option NatVis visualizations,THUMBS_UP,2017-02-15T22:11:01Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/39843,MERGED,2017-02-15T10:43:36Z,2017-02-16T08:18:28Z,Vec LinkedList VecDeque String and Option NatVis visualizations,AndrewGaspar,a8b7b28babdb49387eb56626b8359d7295515775,2,Vec LinkedList VecDeque String and Option NatVis visualizations,THUMBS_UP,2017-03-25T19:54:18Z,hban,NA https://github.com/rust-lang/rust/pull/39843,MERGED,2017-02-15T10:43:36Z,2017-02-16T08:18:28Z,Vec LinkedList VecDeque String and Option NatVis visualizations,AndrewGaspar,a8b7b28babdb49387eb56626b8359d7295515775,2,Vec LinkedList VecDeque String and Option NatVis visualizations,THUMBS_UP,2017-05-23T06:31:48Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/39845,MERGED,2017-02-15T12:03:13Z,2017-02-25T03:10:30Z,Add Documentation for Custom Attributes and Error Reporting in Procedural Macros,JDemler,198208be0e818d99e42281568a2eec305175c6c9,1,Fixed some small issues,THUMBS_UP,2017-02-22T13:35:21Z,fengcen,fengcen.love@gmail.com https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,HEART,2017-02-16T19:05:44Z,est31,NA https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,THUMBS_UP,2017-02-16T19:39:10Z,durka,NA https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,THUMBS_UP,2017-02-16T20:37:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,HEART,2017-02-16T20:37:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,THUMBS_UP,2017-02-17T00:16:33Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,THUMBS_UP,2017-02-17T07:43:27Z,binarycrusader,shawn@binarycrusader.com https://github.com/rust-lang/rust/pull/39888,MERGED,2017-02-16T19:02:53Z,2017-02-25T15:00:34Z,[rustbuild] add a way to run command after failure,nagisa,0e45a5ed3f79338656b19a41172d3a7761586ebc,3,[rustbuild] add a way to run command after failure This is a simple way to workaround the debugging issues caused by the rustc wrapper used in the bootstrap process. Namely it uses some obscure environment variables and you can’t just copy the failed command and run it in the shell or debugger to examine the failure more closely. With `--on-fail` its possible to run an arbitrary command within exactly the same environment under which rustc failed. Theres’s multiple ways to use this new flag: $ python x.py build --stage=1 --on-fail=env would print a list of environment variables and the failed command so a few copy-pastes and you now can run the same rust in your shell outside the bootstrap system. $ python x.py build --stage=1 --on-fail=bash Is a more useful variation of the command above in that it launches a whole shell with environment already in place! All that’s left to do is copy-paste the command just above the shell prompt! Fixes #38686 Fixes #38221,HEART,2017-02-17T20:57:04Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39905,MERGED,2017-02-17T07:01:48Z,2017-02-25T15:00:35Z,Properly display note/expected details,estebank,038a166e092ab5497dcb8e6785949a954d692cfd,6,Properly display note/expected details,HEART,2017-02-17T09:54:00Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/39905,MERGED,2017-02-17T07:01:48Z,2017-02-25T15:00:35Z,Properly display note/expected details,estebank,038a166e092ab5497dcb8e6785949a954d692cfd,6,Properly display note/expected details,HEART,2017-02-17T10:45:09Z,est31,NA https://github.com/rust-lang/rust/pull/39905,MERGED,2017-02-17T07:01:48Z,2017-02-25T15:00:35Z,Properly display note/expected details,estebank,038a166e092ab5497dcb8e6785949a954d692cfd,6,Properly display note/expected details,HEART,2017-02-17T18:51:29Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39906,CLOSED,2017-02-17T07:51:31Z,2017-03-03T21:42:23Z,[WIP] Simplify mismatched types by removing same subtypes,estebank,NA,NA,NA,THUMBS_UP,2017-02-17T15:26:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/39906,CLOSED,2017-02-17T07:51:31Z,2017-03-03T21:42:23Z,[WIP] Simplify mismatched types by removing same subtypes,estebank,NA,NA,NA,THUMBS_UP,2017-02-17T16:55:22Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/39906,CLOSED,2017-02-17T07:51:31Z,2017-03-03T21:42:23Z,[WIP] Simplify mismatched types by removing same subtypes,estebank,NA,NA,NA,HEART,2017-02-17T18:58:02Z,seppo0010,NA https://github.com/rust-lang/rust/pull/39906,CLOSED,2017-02-17T07:51:31Z,2017-03-03T21:42:23Z,[WIP] Simplify mismatched types by removing same subtypes,estebank,NA,NA,NA,THUMBS_UP,2017-02-18T01:13:04Z,cramertj,NA https://github.com/rust-lang/rust/pull/39906,CLOSED,2017-02-17T07:51:31Z,2017-03-03T21:42:23Z,[WIP] Simplify mismatched types by removing same subtypes,estebank,NA,NA,NA,HEART,2017-02-23T09:57:36Z,juleskers,NA https://github.com/rust-lang/rust/pull/39918,MERGED,2017-02-17T21:58:33Z,2017-03-11T08:25:31Z,travis: Fuchsia builder,petrhosek,9a8461104e1520c7194f8b4589262c9e292c6988,6,travis: Fuchsia builder This change introduces a Dockerfile and script which builds a complete Fuchsia toolchain which can be used to build Rust distribution for Fuchsia. We only support cross-compiling at the moment hence only setting the target.,HEART,2017-02-18T09:32:07Z,est31,NA https://github.com/rust-lang/rust/pull/39918,MERGED,2017-02-17T21:58:33Z,2017-03-11T08:25:31Z,travis: Fuchsia builder,petrhosek,9a8461104e1520c7194f8b4589262c9e292c6988,6,travis: Fuchsia builder This change introduces a Dockerfile and script which builds a complete Fuchsia toolchain which can be used to build Rust distribution for Fuchsia. We only support cross-compiling at the moment hence only setting the target.,HEART,2017-02-25T01:24:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/39939,MERGED,2017-02-18T21:37:14Z,2017-02-19T21:04:17Z,Fix two ICEs in path resolution,petrochenkov,8c7d0077ab51a076d79ff8e91d7845e745f90b21,2,Avoid ICE in Self::Assoc in impl headers,HOORAY,2017-02-19T21:35:22Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/39944,MERGED,2017-02-18T23:33:05Z,2017-03-01T10:03:54Z,Improve associated constant rendering in rustdoc,GuillaumeGomez,bd704baaf1cb632011c215245779cc5605d5fd4c,3,Update tests accordingly,THUMBS_UP,2017-02-19T14:17:42Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/39976,MERGED,2017-02-20T14:40:58Z,2017-02-20T21:31:23Z,Reenable linkchecker for books,steveklabnik,010a28de7cf767c1131b771b139b03a47c3fd418,2,Update mdBook version This brings in a needed bugfix.,HOORAY,2017-02-20T15:41:31Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/39986,CLOSED,2017-02-20T20:55:53Z,2017-02-28T15:35:50Z,Publish docs for the proc_macro crate,SimonSapin,NA,NA,NA,THUMBS_UP,2017-02-20T21:39:01Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,THUMBS_UP,2017-02-20T22:25:57Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,THUMBS_UP,2017-02-25T13:00:07Z,est31,NA https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,THUMBS_UP,2017-02-26T09:52:59Z,Alexander--,NA https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,THUMBS_UP,2017-04-11T21:30:06Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,CONFUSED,2017-04-12T08:02:06Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,CONFUSED,2017-04-12T09:48:54Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/39987,MERGED,2017-02-20T21:13:44Z,2017-04-07T07:22:12Z,#[used] attribute,japaric,98037ca43d4d96f93e73e1eb3df8e64372d8f929,1,don't pass -C to nm the nm in our macOS bots don't support that flag and it's not really required,THUMBS_UP,2017-04-13T11:04:37Z,koutheir,NA https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-02-21T13:43:35Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-02-25T17:39:49Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-02-27T11:10:38Z,llogiq,NA https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-03-01T05:30:47Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-03-01T09:31:15Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-03-01T13:10:49Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-03-01T18:06:59Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-03-02T23:48:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/39995,MERGED,2017-02-21T08:48:28Z,2017-02-25T15:00:38Z,Set metadata for vtable-related loads,Aatch,d80cf80b16660289ebc9765940d02b36ef1032b6,1,Update codegen test with new attributes,HOORAY,2017-04-26T05:03:11Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/39999,MERGED,2017-02-21T12:30:29Z,2017-04-22T14:17:35Z,Implementation of repr struct alignment RFC 1358.,bitshifter,946f8e6a59242a8112c6983d1336fef54bc55b9a,1,Use primitive align for tagged enum fill. Hopefully will fix assert on ARM where vector types are being used as the fill type for enums containing repr aligned types greater than the largest possible native type thus don't match the Layout's alignment and triggers an assert.,HOORAY,2017-02-21T17:05:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-21T18:41:42Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-21T18:41:44Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,THUMBS_UP,2017-02-21T18:41:46Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-21T18:44:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-21T18:51:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-21T20:48:26Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-21T21:15:00Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-21T23:18:27Z,est31,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,THUMBS_UP,2017-02-21T23:18:29Z,est31,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-21T23:18:31Z,est31,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-21T23:35:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-21T23:59:00Z,estebank,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T00:06:50Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T01:30:49Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-22T03:08:48Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T03:08:49Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T09:58:52Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T16:25:17Z,bluss,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T18:44:29Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-22T18:44:35Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T20:04:26Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T21:48:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-22T23:54:47Z,flodiebold,flodiebold@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-02-25T10:47:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-25T10:47:11Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,THUMBS_UP,2017-02-26T11:14:21Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-02-28T13:26:21Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-03-02T13:49:24Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HEART,2017-03-08T08:29:39Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-03-08T08:46:21Z,Havvy,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-03-11T07:05:04Z,bstrie,NA https://github.com/rust-lang/rust/pull/40008,MERGED,2017-02-21T18:31:06Z,2017-02-28T10:00:35Z,[12/12] On-demand type-checking const-evaluation MIR building & const-qualification.,eddyb,f702b20dfd22990a326af9221cb3ed9b389c8307,2,rustc_save_analysis: don't pollute the codemap with fake files.,HOORAY,2017-03-29T18:08:59Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-02-21T22:22:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HEART,2017-02-21T22:22:28Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-02-21T22:48:29Z,binarycrusader,shawn@binarycrusader.com https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,THUMBS_UP,2017-02-22T07:55:03Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-02-22T20:07:04Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-03-02T08:43:11Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-03-11T13:02:47Z,tpimh,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,THUMBS_UP,2017-04-07T20:34:01Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HEART,2017-04-07T20:34:09Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,THUMBS_UP,2017-04-11T09:47:32Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-04-11T09:47:33Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HEART,2017-04-11T09:47:33Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2017-04-25T10:21:08Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2018-01-02T09:46:53Z,smalleel,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,THUMBS_UP,2018-01-24T22:06:58Z,berkus,NA https://github.com/rust-lang/rust/pull/40018,MERGED,2017-02-21T22:14:54Z,2017-04-10T20:54:55Z,#NAME?,japaric,e192fb3d892f04e90a78378bd772cc003304a887,1,explain why we have a fake cfail test,HOORAY,2018-03-23T23:33:44Z,mcandre,NA https://github.com/rust-lang/rust/pull/40019,MERGED,2017-02-21T22:23:13Z,2017-02-25T15:00:39Z,travis: Compile a more compatible libc.a for musl,alexcrichton,9a08f40349c3c3182845b31b1d7a26b7af5245a3,2,travis: Move -mrelax-relocations to Docker config This doesn't belong in rustbuild itself and now that we have only rustbuild we can move this out of the build system.,HOORAY,2017-02-21T23:19:35Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/40025,MERGED,2017-02-22T02:20:43Z,2017-02-25T15:00:40Z,Implement non-capturing closure to fn coercion,est31,77f131da1afcaf5582259e7a15048105fea9591d,6,"Review changes * use more convenient mk_substs function * remove type annotations * use map_bound one level farther outside * style improvements",HOORAY,2017-02-24T11:53:02Z,retep998,NA https://github.com/rust-lang/rust/pull/40025,MERGED,2017-02-22T02:20:43Z,2017-02-25T15:00:40Z,Implement non-capturing closure to fn coercion,est31,77f131da1afcaf5582259e7a15048105fea9591d,6,"Review changes * use more convenient mk_substs function * remove type annotations * use map_bound one level farther outside * style improvements",HOORAY,2017-03-01T05:08:45Z,tikue,NA https://github.com/rust-lang/rust/pull/40025,MERGED,2017-02-22T02:20:43Z,2017-02-25T15:00:40Z,Implement non-capturing closure to fn coercion,est31,77f131da1afcaf5582259e7a15048105fea9591d,6,"Review changes * use more convenient mk_substs function * remove type annotations * use map_bound one level farther outside * style improvements",HOORAY,2017-03-01T17:44:51Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/40025,MERGED,2017-02-22T02:20:43Z,2017-02-25T15:00:40Z,Implement non-capturing closure to fn coercion,est31,77f131da1afcaf5582259e7a15048105fea9591d,6,"Review changes * use more convenient mk_substs function * remove type annotations * use map_bound one level farther outside * style improvements",HOORAY,2021-07-27T18:23:13Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/40027,MERGED,2017-02-22T07:42:57Z,2017-02-25T15:00:40Z,Stabilize static_recursion,cramertj,802a826a57eb84ac24dccc936d6398890efbcab8,8,Stabilize static_recursion,THUMBS_UP,2017-04-26T01:30:12Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/40076,CLOSED,2017-02-24T13:42:31Z,2017-03-14T21:43:12Z,Make list of native artifacts to link more compact.,SimonSapin,NA,NA,NA,THUMBS_UP,2017-02-24T14:25:59Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/40076,CLOSED,2017-02-24T13:42:31Z,2017-03-14T21:43:12Z,Make list of native artifacts to link more compact.,SimonSapin,NA,NA,NA,THUMBS_UP,2017-02-25T08:08:27Z,retep998,NA https://github.com/rust-lang/rust/pull/40076,CLOSED,2017-02-24T13:42:31Z,2017-03-14T21:43:12Z,Make list of native artifacts to link more compact.,SimonSapin,NA,NA,NA,THUMBS_UP,2017-07-10T15:24:03Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/40091,MERGED,2017-02-25T12:13:44Z,2017-02-25T15:00:43Z,Rollup of 28 pull requests,eddyb,207c76306037776c0e72456d5a0497e430c6753c,1,Rollup merge of #40086 - danobi:move-compiler_tests r=brson Move COMPILER_TESTS.md out of the root directory See #39896. r? @brson,HOORAY,2017-02-25T15:09:58Z,pitdicker,NA https://github.com/rust-lang/rust/pull/40091,MERGED,2017-02-25T12:13:44Z,2017-02-25T15:00:43Z,Rollup of 28 pull requests,eddyb,207c76306037776c0e72456d5a0497e430c6753c,1,Rollup merge of #40086 - danobi:move-compiler_tests r=brson Move COMPILER_TESTS.md out of the root directory See #39896. r? @brson,HOORAY,2017-02-25T19:39:23Z,cramertj,NA https://github.com/rust-lang/rust/pull/40097,CLOSED,2017-02-25T21:20:39Z,2017-04-14T19:10:35Z,Implement RFC 1268,sgrif,NA,NA,NA,HOORAY,2017-03-08T01:35:02Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/40104,MERGED,2017-02-26T01:08:58Z,2017-03-02T22:15:47Z,[MIR] Rvalue::ty infallible + remove TypedConstVal,nagisa,21c61336bb9e327b90f4cb8e87a948be40eeafe5,8,Remove the TypedConstVal Replace it with ConstUsize instead which is more appropriate; we are not using the rest of the TypedConstVal anyway,THUMBS_UP,2017-02-26T01:10:33Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/40104,MERGED,2017-02-26T01:08:58Z,2017-03-02T22:15:47Z,[MIR] Rvalue::ty infallible + remove TypedConstVal,nagisa,21c61336bb9e327b90f4cb8e87a948be40eeafe5,8,Remove the TypedConstVal Replace it with ConstUsize instead which is more appropriate; we are not using the rest of the TypedConstVal anyway,THUMBS_UP,2017-02-26T11:45:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40111,MERGED,2017-02-26T04:21:57Z,2017-02-26T15:15:31Z,Attempt to fix nightly manifests,alexcrichton,5ed6765fd419e50f88de0323fc8328568ed55ab0,1,build-manifest: Remove old to_hex function This was actually just generating invalid hashes for the `rust` component.,THUMBS_UP,2017-02-26T04:35:56Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/40111,MERGED,2017-02-26T04:21:57Z,2017-02-26T15:15:31Z,Attempt to fix nightly manifests,alexcrichton,5ed6765fd419e50f88de0323fc8328568ed55ab0,1,build-manifest: Remove old to_hex function This was actually just generating invalid hashes for the `rust` component.,THUMBS_UP,2017-02-26T05:09:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/40111,MERGED,2017-02-26T04:21:57Z,2017-02-26T15:15:31Z,Attempt to fix nightly manifests,alexcrichton,5ed6765fd419e50f88de0323fc8328568ed55ab0,1,build-manifest: Remove old to_hex function This was actually just generating invalid hashes for the `rust` component.,THUMBS_UP,2017-02-26T09:48:30Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/40111,MERGED,2017-02-26T04:21:57Z,2017-02-26T15:15:31Z,Attempt to fix nightly manifests,alexcrichton,5ed6765fd419e50f88de0323fc8328568ed55ab0,1,build-manifest: Remove old to_hex function This was actually just generating invalid hashes for the `rust` component.,THUMBS_UP,2017-02-26T14:12:23Z,magikid,chris@christopherjones.us https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-04-06T18:11:43Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2017-04-06T18:11:46Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-04-08T13:17:56Z,Shizmob,hi@shiz.me https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-04-17T21:33:05Z,clux,NA https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-04-25T11:12:34Z,LunNova,github@lunnova.dev https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-04-25T13:15:43Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-06-05T16:43:00Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2017-06-05T16:43:02Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-06-13T10:37:27Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2017-06-13T10:37:29Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-07-25T17:03:55Z,Others,NA https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-08-11T02:56:48Z,mcandre,NA https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2017-08-15T12:31:59Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2017-09-15T09:32:34Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2019-01-29T19:30:02Z,Cogitri,oss@cogitri.dev https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2019-02-08T09:07:02Z,yanana,NA https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2019-08-04T11:00:28Z,camelmasa,camelmasa@gmail.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,HEART,2019-08-04T11:00:28Z,camelmasa,camelmasa@gmail.com https://github.com/rust-lang/rust/pull/40113,MERGED,2017-02-26T06:50:46Z,2017-08-23T11:19:01Z,Support dynamically-linked and/or native musl targets,smaeul,e6cd9413718a51e9ce3207cdf4efad6319a34327,2,Update ignored tests for dynamic musl Now that musl supports dynamic libraries (although not by default) enable the tests that now pass. Additional currently-ignored tests will pass if rustc is built with crt_static=false in config.toml.,THUMBS_UP,2022-05-03T14:14:11Z,ThePotatoChronicler,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-27T16:23:05Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-27T16:24:52Z,dsvensson,dsvensson@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-02-27T17:03:47Z,simon-i1-h,shimon@postfixnotation.org https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-27T17:52:26Z,est31,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-28T04:07:55Z,Ralith,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-02-28T08:28:51Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-02-28T11:36:09Z,Jascha-N,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-28T11:36:11Z,Jascha-N,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-02-28T13:33:54Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-02-28T17:36:37Z,alexbool,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-02-28T17:36:37Z,alexbool,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-01T05:49:01Z,amboar,andrew@aj.id.au https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-03-01T22:16:39Z,brian-dawn,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-03-03T12:50:45Z,Randl,zheltonozhskiy@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-06T11:06:10Z,jplatte,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-06T12:01:23Z,MaxDesiatov,max@desiatov.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-03-08T03:16:47Z,spiccinini,spiccinini@altermundi.net https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-14T02:03:33Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-03-14T02:03:36Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-14T14:22:48Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-03-14T14:22:50Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-18T09:18:36Z,mbakhoff,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-03-20T12:29:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-02T08:57:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-18T09:10:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-18T20:54:12Z,leinlawun,leinlawun@leinlawun.org https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-23T18:22:45Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-24T17:18:58Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T01:32:35Z,jacobrosenthal,jacobrosenthal@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T01:39:54Z,vadimcn,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T01:39:58Z,vadimcn,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T01:40:07Z,vadimcn,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T02:21:32Z,lawliet89,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T02:37:15Z,ambaxter,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T02:37:17Z,ambaxter,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T02:37:18Z,ambaxter,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T03:29:58Z,vmchale,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T06:13:12Z,LnL7,daiderd@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T06:15:36Z,Koka,koka58@yandex.ru https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T06:15:37Z,Koka,koka58@yandex.ru https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T06:15:38Z,Koka,koka58@yandex.ru https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T06:34:04Z,dvberkel,daan.v.berkel.1980@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T06:37:51Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T06:37:57Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T06:38:13Z,redstrike,tung@vn2rap.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T06:40:16Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T06:57:32Z,brother,brother@bsnet.se https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T07:00:30Z,zliang-min,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T07:57:34Z,timgluz,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T08:06:54Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T08:06:55Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T08:06:57Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T08:11:42Z,dlight,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T08:25:14Z,repax,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T08:45:01Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T08:47:01Z,007lva,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T09:26:15Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T09:26:16Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T10:27:06Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T12:54:52Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T13:50:31Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T14:03:13Z,Nateowami,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T14:13:21Z,jinmingjian,jin.phd@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T15:03:40Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T15:55:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T16:52:00Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T16:52:01Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-25T16:52:01Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T16:59:01Z,xiaods,xiaods@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-25T18:13:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T18:45:03Z,orthecreedence,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-25T22:54:58Z,fluxxu,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-26T01:19:14Z,draivin,ian.orn@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-26T05:33:09Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-26T11:15:44Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-26T11:15:47Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-04-26T11:15:47Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HOORAY,2017-04-26T17:04:49Z,Virtlink,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-04-26T17:04:51Z,Virtlink,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-05-03T11:11:39Z,bjorn3,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-05-04T13:33:32Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,THUMBS_UP,2017-05-09T19:52:28Z,pavlo-v-chernykh,NA https://github.com/rust-lang/rust/pull/40123,MERGED,2017-02-27T15:09:35Z,2017-04-25T01:21:33Z,LLVM 4.0 Upgrade,TimNN,899427765760068163c811fbe9e02ff953638698,2,FIN: windows-gnu: statically link gcc_s pthread with llvm,HEART,2017-05-14T05:11:11Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/40141,CLOSED,2017-02-28T08:54:26Z,2017-04-01T22:40:14Z,suppress log of test run that actually tests nothing,king6cong,NA,NA,NA,THUMBS_UP,2017-02-28T20:46:53Z,durka,NA https://github.com/rust-lang/rust/pull/40166,MERGED,2017-03-01T00:09:25Z,2017-03-02T22:15:50Z,Allow types passed to [] to coerce like .index(),aidanhs,c58fff2bb76b055c8276551d54a99aea997c34ed,2,Allow types passed to [] to coerce like .index() Fixes #40085,THUMBS_UP,2017-03-01T01:52:36Z,est31,NA https://github.com/rust-lang/rust/pull/40202,MERGED,2017-03-02T06:47:00Z,2017-03-04T08:10:58Z,syntax: integrate `TokenStream`,jseyfried,0d554139ad7a54bbd59a5166cc3e9ff7842c5266,7,Fix fallout in unit tests.,THUMBS_UP,2017-03-02T08:02:14Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/40220,MERGED,2017-03-03T00:16:12Z,2017-03-12T01:08:50Z,syntax: add `ast::ItemKind::MacroDef` simplify hygiene info,jseyfried,8c98996934658631308e8fb4069d2db68ff44927,13,Avoid using `Mark` and `Invocation` for macro defs.,THUMBS_UP,2017-03-03T02:26:43Z,keeperofdakeys,NA https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-03T03:11:38Z,brson,NA https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-03T06:39:15Z,canndrew,shum@canndrew.org https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-03T09:35:38Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-03T10:00:32Z,cramertj,NA https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-03T13:32:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HOORAY,2017-03-07T23:09:57Z,brson,NA https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HOORAY,2017-03-08T03:13:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HEART,2017-03-23T17:50:56Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40224,MERGED,2017-03-03T02:19:13Z,2017-03-30T16:54:32Z,change the strategy for diverging types,nikomatsakis,2414222b17f45e33d68582dd5ebe0083ed27b8cc,1,remove comments that were tripping up pretty printer,HOORAY,2017-03-23T17:50:57Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40229,MERGED,2017-03-03T09:54:24Z,2017-03-21T19:34:56Z,Implement `?` in catch expressions,cramertj,1f43731772d7ec70cade48faf4af2b1a88375bfd,5,Add more catch-related CFG and lifetime tests and fix CFG bug,THUMBS_UP,2017-03-03T10:07:21Z,est31,NA https://github.com/rust-lang/rust/pull/40229,MERGED,2017-03-03T09:54:24Z,2017-03-21T19:34:56Z,Implement `?` in catch expressions,cramertj,1f43731772d7ec70cade48faf4af2b1a88375bfd,5,Add more catch-related CFG and lifetime tests and fix CFG bug,THUMBS_UP,2017-03-03T21:12:00Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/40229,MERGED,2017-03-03T09:54:24Z,2017-03-21T19:34:56Z,Implement `?` in catch expressions,cramertj,1f43731772d7ec70cade48faf4af2b1a88375bfd,5,Add more catch-related CFG and lifetime tests and fix CFG bug,HOORAY,2017-03-06T13:24:00Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/40236,MERGED,2017-03-03T15:27:27Z,2017-03-04T21:29:14Z,rustbuild: A few tweaks,petrochenkov,428f063fcdc35e048ff79d059a8963334ba2281c,9,Automate timestamp creation and build skipping for native libraries Add comments,HOORAY,2017-03-03T17:39:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40237,MERGED,2017-03-03T15:29:17Z,2017-03-09T10:41:23Z,Reduce size overhead of adaptative hashmap,arthurprs,3273003912272b3e9e44c535ba785bae980348bb,2,Reduce size overhead of adaptative hashmap Exposes a boolean flag in RawTable and use it instead of a bool field in HashMap. Fixes: #40042,HOORAY,2017-03-09T14:15:36Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/40237,MERGED,2017-03-03T15:29:17Z,2017-03-09T10:41:23Z,Reduce size overhead of adaptative hashmap,arthurprs,3273003912272b3e9e44c535ba785bae980348bb,2,Reduce size overhead of adaptative hashmap Exposes a boolean flag in RawTable and use it instead of a bool field in HashMap. Fixes: #40042,HOORAY,2017-05-26T06:07:56Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/40239,MERGED,2017-03-03T17:24:42Z,2017-03-11T08:25:34Z,Remove ability for plugins to register a MIR pass,nagisa,4ca9c97ace17ca0232bf6f83c06a8a8245614de5,4,"Remove ability for plugins to register a MIR pass In recent months there have been a few different people investigating how to make a plugin that registers a MIR-pass – one that isn’t intended to be eventually merged into rustc proper. The interface to register MIR passes was added primarily for miri (& later was found to make prototyping of rustc-proper MIR passes a tiny bit faster). Since miri does not use this interface anymore it seems like a good time to remove this ""feature"". For prototyping purposes a similar interface can be added by developers themselves in their custom rustc build.",THUMBS_UP,2017-03-04T01:02:59Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40258,MERGED,2017-03-04T13:31:53Z,2017-03-09T10:41:24Z,Fix description of closure coercion feature,est31,b55f1e5342a948b546ad61b437ede6096ffee613,1,Fix description of closure coercion feature,LAUGH,2017-03-04T13:36:13Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-04T19:09:34Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-04T20:10:35Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-06T16:54:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-08T03:19:11Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-15T06:02:01Z,gurry,NA https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-15T09:43:53Z,jplatte,NA https://github.com/rust-lang/rust/pull/40265,MERGED,2017-03-04T18:59:09Z,2017-03-09T10:41:25Z,Improve the style of the sidebar in rustdoc output,wesleywiser,2bb2a2975f25e8ba7a372898e7e112f1cec5db01,2,Improve the style of the sidebar in rustdoc output Makes the sidebar a light grey and highlights the currently viewed item in the sidebar more prominently. All visual design credit goes to @johnwhelchel (#37856),HEART,2017-03-23T08:34:58Z,jminer,NA https://github.com/rust-lang/rust/pull/40277,MERGED,2017-03-05T15:17:28Z,2017-03-11T08:25:35Z,rustbuild: expose LLVM_PARALLEL_LINK_JOBS,hanna-kruppe,58ff4f67e3a1d099d3c4cb8ccb554ee9fd0a16cd,3,rustbuild: expose LLVM_PARALLEL_LINK_JOBS This allows limiting the number of linker jobs to avoid swapping when linking LLVM with debug info.,THUMBS_UP,2017-03-05T15:53:32Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/40285,MERGED,2017-03-06T00:20:04Z,2017-03-06T05:52:43Z,Fix ICE: don't use `struct_variant` on enums,estebank,ad06fc718b7236f988dcc7481d5b9e0447a9760e,3,Fix ICE: don't use `struct_variant` on enums Fix #40221 and add unittest.,THUMBS_UP,2017-03-11T11:44:28Z,passy,NA https://github.com/rust-lang/rust/pull/40287,MERGED,2017-03-06T03:05:59Z,2017-03-11T08:25:36Z,Fix incorrect span label formatting,estebank,7b0dd7bdb80768684195f0175d2feecaefd1f2ac,3,Fix incorrect span label formatting,THUMBS_UP,2017-03-06T05:52:54Z,durka,NA https://github.com/rust-lang/rust/pull/40297,MERGED,2017-03-06T15:47:47Z,2017-03-11T08:25:36Z,Don't put Cargo into the rustc workspace,alexcrichton,c65996ea3b7e1f59c19ece2381e5d687892c98de,9,Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to the top directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace.,THUMBS_UP,2017-03-06T21:06:01Z,cengizIO,NA https://github.com/rust-lang/rust/pull/40297,MERGED,2017-03-06T15:47:47Z,2017-03-11T08:25:36Z,Don't put Cargo into the rustc workspace,alexcrichton,c65996ea3b7e1f59c19ece2381e5d687892c98de,9,Don't put Cargo into the rustc workspace This causes problems when first cloning and bootstrapping the repository unfortunately so let's ensure that Cargo sticks around in its own workspace. Because Cargo is a submodule it's not available by default on the inital clone of the rust-lang/rust repository. Normally it's the responsibility of the rustbuild to take care of this but unfortunately to build rustbuild itself we need to resolve the workspace conflicts. To deal with this we'll just have to ensure that all submodules are in their own workspace which sort of makes sense anyway as updates to dependencies as bugfixes to Cargo should go to rust-lang/cargo instead of rust-lang/rust. In any case this commit removes Cargo from the global workspace which should resolve the issues that we've been seeing. To actually perform this the `cargo` submodule has been moved to the top directory to ensure it's outside the scope of `src/Cargo.toml` as a workspace.,THUMBS_UP,2017-03-07T02:08:30Z,est31,NA https://github.com/rust-lang/rust/pull/40312,MERGED,2017-03-07T05:10:03Z,2017-03-21T19:34:57Z,Papercut,jdhorwitz,e2b4824b886d6a809bcd29f901c5bf62ab56f727,1,Removed RustFMT changes,HEART,2017-03-07T15:27:45Z,killercup,NA https://github.com/rust-lang/rust/pull/40332,MERGED,2017-03-07T21:41:14Z,2017-03-21T19:34:57Z,Extract book into a submodule,steveklabnik,96d35947c36bba6c6545c06768b5358c0f8bf3dc,1,fix trailing whitespace,HEART,2017-03-07T21:45:12Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-03-08T18:12:44Z,killercup,NA https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-03-12T22:48:09Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-03-17T17:26:33Z,mitaa,mitaa.ceb@gmail.com https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-04-01T04:23:32Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-04-05T08:37:45Z,kennytm,NA https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-04-05T18:15:04Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-04-09T11:35:26Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/40338,MERGED,2017-03-08T00:02:06Z,2017-03-29T09:49:04Z,Replace hoedown with pull in rustdoc,GuillaumeGomez,a7c6d3e16a71fc0dcce4c9be09d031d746f84a69,1,Improve function naming,HOORAY,2017-04-24T17:27:29Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,HOORAY,2017-03-08T06:24:12Z,cgswords,cameronswords@gmail.com https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,HOORAY,2017-03-08T11:11:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,HOORAY,2017-03-11T04:13:01Z,tikue,NA https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,HOORAY,2017-03-22T08:02:41Z,plietar,NA https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,HOORAY,2017-08-04T10:57:55Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/40346,MERGED,2017-03-08T02:55:23Z,2017-03-19T13:57:21Z,`TokenStream`-based attributes paths in attribute and derive macro invocations,jseyfried,85e02bdbfcfd0e38def7656a8295a5260640fd4a,6,Add tests.,THUMBS_DOWN,2018-06-20T21:39:59Z,Undin,a.pendryak@yandex.ru https://github.com/rust-lang/rust/pull/40347,MERGED,2017-03-08T04:43:21Z,2017-03-26T08:10:00Z,Remove internal liblog,alexcrichton,e341d603fe7c35ce174bd2e54e47ed6941ea4b03,38,"Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature) and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild feature(staged_api rustc_private))] #![cfg_attr(rustbuild unstable(feature = ""rustc_private"" issue = ""27812""))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).",HOORAY,2017-03-08T15:48:14Z,durka,NA https://github.com/rust-lang/rust/pull/40347,MERGED,2017-03-08T04:43:21Z,2017-03-26T08:10:00Z,Remove internal liblog,alexcrichton,e341d603fe7c35ce174bd2e54e47ed6941ea4b03,38,"Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature) and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild feature(staged_api rustc_private))] #![cfg_attr(rustbuild unstable(feature = ""rustc_private"" issue = ""27812""))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).",HOORAY,2017-03-27T06:59:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40347,MERGED,2017-03-08T04:43:21Z,2017-03-26T08:10:00Z,Remove internal liblog,alexcrichton,e341d603fe7c35ce174bd2e54e47ed6941ea4b03,38,"Remove internal liblog This commit deletes the internal liblog in favor of the implementation that lives on crates.io. Similarly it's also setting a convention for adding crates to the compiler. The main restriction right now is that we want compiler implementation details to be unreachable from normal Rust code (e.g. requires a feature) and by default everything in the sysroot is reachable via `extern crate`. The proposal here is to require that crates pulled in have these lines in their `src/lib.rs`: #![cfg_attr(rustbuild feature(staged_api rustc_private))] #![cfg_attr(rustbuild unstable(feature = ""rustc_private"" issue = ""27812""))] This'll mean that by default they're not using these attributes but when compiled as part of the compiler they do a few things: * Mark themselves as entirely unstable via the `staged_api` feature and the `#![unstable]` attribute. * Allow usage of other unstable crates via `feature(rustc_private)` which is required if the crate relies on any other crates to compile (other than std).",HOORAY,2017-03-31T07:13:56Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/40367,MERGED,2017-03-08T18:26:15Z,2017-04-13T14:22:27Z,Improve the LLVM IR we generate for trivial functions especially #[naked] ones.,eddyb,9b5c577dbd45ff3b11f9d7aab6990cc1ee9194fb,3,rustc_trans: avoid a separate entry BB if START_BLOCK has no backedges.,THUMBS_UP,2017-03-08T18:37:54Z,edef1c,NA https://github.com/rust-lang/rust/pull/40369,MERGED,2017-03-08T19:27:00Z,2017-03-12T19:24:29Z,Give spans to individual path segments in AST,petrochenkov,ffdcf7486656119328c3c6c1efef408abba3139f,6,resolve: Use path segment spans in smart_resolve_path,THUMBS_UP,2017-03-08T19:47:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40369,MERGED,2017-03-08T19:27:00Z,2017-03-12T19:24:29Z,Give spans to individual path segments in AST,petrochenkov,ffdcf7486656119328c3c6c1efef408abba3139f,6,resolve: Use path segment spans in smart_resolve_path,THUMBS_UP,2017-03-08T19:48:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/40369,MERGED,2017-03-08T19:27:00Z,2017-03-12T19:24:29Z,Give spans to individual path segments in AST,petrochenkov,ffdcf7486656119328c3c6c1efef408abba3139f,6,resolve: Use path segment spans in smart_resolve_path,HOORAY,2017-03-13T01:45:39Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-03-09T03:36:46Z,est31,NA https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-03-09T15:45:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-03-10T00:30:30Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-04-16T04:15:49Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-04-16T10:53:39Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,THUMBS_UP,2017-04-19T22:21:38Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/40377,MERGED,2017-03-09T02:40:15Z,2017-04-12T03:58:39Z,Implement optimization fuel and re-enable struct field reordering,ahicks92,e18c59fd48a8387767d44fdd4d36208dfd33f762,3,Fix some nits,HEART,2017-06-28T16:13:28Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/40409,MERGED,2017-03-10T04:42:20Z,2017-04-16T22:24:38Z,Specialize Vec::from_elem to use calloc,mbrubeck,aad2062073f46f28c6d1269463cc6c19df1e0199,2,Specialize Vec::from_elem for other numeric types,THUMBS_UP,2017-03-14T20:54:58Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40409,MERGED,2017-03-10T04:42:20Z,2017-04-16T22:24:38Z,Specialize Vec::from_elem to use calloc,mbrubeck,aad2062073f46f28c6d1269463cc6c19df1e0199,2,Specialize Vec::from_elem for other numeric types,THUMBS_UP,2017-03-24T17:04:09Z,luser,NA https://github.com/rust-lang/rust/pull/40409,MERGED,2017-03-10T04:42:20Z,2017-04-16T22:24:38Z,Specialize Vec::from_elem to use calloc,mbrubeck,aad2062073f46f28c6d1269463cc6c19df1e0199,2,Specialize Vec::from_elem for other numeric types,THUMBS_UP,2017-04-19T19:08:13Z,StefanoD,NA https://github.com/rust-lang/rust/pull/40422,MERGED,2017-03-10T17:14:41Z,2017-03-11T03:03:18Z,rustc: Support auto-retry linking on a segfault,alexcrichton,993eae1816525e5cf855e448363098edd5935276,2,rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler `RUSTC_RETRY_LINKER_ON_SEGFAULT` which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.,LAUGH,2017-03-10T17:32:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40422,MERGED,2017-03-10T17:14:41Z,2017-03-11T03:03:18Z,rustc: Support auto-retry linking on a segfault,alexcrichton,993eae1816525e5cf855e448363098edd5935276,2,rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler `RUSTC_RETRY_LINKER_ON_SEGFAULT` which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.,THUMBS_UP,2017-03-10T17:32:26Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40422,MERGED,2017-03-10T17:14:41Z,2017-03-11T03:03:18Z,rustc: Support auto-retry linking on a segfault,alexcrichton,993eae1816525e5cf855e448363098edd5935276,2,rustc: Support auto-retry linking on a segfault This is a last-ditch attempt to help our pain with dealing with #38878 on the bots. A new environment variable is added to the compiler `RUSTC_RETRY_LINKER_ON_SEGFAULT` which will instruct the compiler to automatically retry the final linker invocation if it looks like the linker segfaulted (up to 2 extra times). Unfortunately there have been no successful attempts to debug #38878. The only information seems to be that the linker (e.g. `ld` on OSX) is segfaulting somewhere in some thread pool implementation. This appears to be spurious as failed PRs will later merge. The hope is that this helps the queue keep moving without clogging and delaying PRs due to #38878.,HEART,2017-03-10T21:05:50Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/40448,MERGED,2017-03-12T03:00:08Z,2017-03-13T05:58:14Z,rustbuild: Fix compiler docs,ollie27,0e0bac914c9324a8ac72769810aaff00d758f0d7,1,rustbuild: Fix tests Use the same step names as the actual build.,HOORAY,2017-03-13T06:12:50Z,bjorn3,NA https://github.com/rust-lang/rust/pull/40450,MERGED,2017-03-12T05:22:48Z,2017-03-12T22:00:04Z,Update Cargo to fix nightly channel,alexcrichton,b5798a9be80a239b54b69a6a750a8aeeaadbf1fc,4,Update Cargo to fix nightly channel This commit updates Cargo with rust-lang/cargo#3820 which includes a fix for rust-lang/cargo#3819. At the same time this also slightly tweaks how rustbuild builds cargo to ensure that all the build information (including git info and such) makes its way into the binary. Closes rust-lang/cargo#3820,THUMBS_UP,2017-03-12T20:19:04Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/40450,MERGED,2017-03-12T05:22:48Z,2017-03-12T22:00:04Z,Update Cargo to fix nightly channel,alexcrichton,b5798a9be80a239b54b69a6a750a8aeeaadbf1fc,4,Update Cargo to fix nightly channel This commit updates Cargo with rust-lang/cargo#3820 which includes a fix for rust-lang/cargo#3819. At the same time this also slightly tweaks how rustbuild builds cargo to ensure that all the build information (including git info and such) makes its way into the binary. Closes rust-lang/cargo#3820,THUMBS_UP,2017-03-13T06:43:29Z,saleemrashid,dev@saleemrashid.com https://github.com/rust-lang/rust/pull/40454,MERGED,2017-03-12T13:33:49Z,2017-06-11T18:56:24Z,speed up mem::swap,djzin,83f1f118e56320667c04a522e05f09a9f4abb6ff,1,hack around bug in emscripten,HOORAY,2017-06-14T19:46:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/40454,MERGED,2017-03-12T13:33:49Z,2017-06-11T18:56:24Z,speed up mem::swap,djzin,83f1f118e56320667c04a522e05f09a9f4abb6ff,1,hack around bug in emscripten,HOORAY,2017-06-15T16:19:11Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/40456,MERGED,2017-03-12T18:08:11Z,2017-03-17T20:18:52Z,Remove function invokation parens from documentation links.,frewsxcv,e7b0f2badf7c3393f1b36339b121054d05353442,42,Remove function invokation parens from documentation links. This was never established as a convention we should follow in the 'More API Documentation Conventions' RFC: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md,HEART,2017-03-12T21:19:22Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/40500,MERGED,2017-03-14T02:19:48Z,2017-03-17T20:18:55Z,Point out correct turbofish usage on `Foo>`,estebank,e3b8550a601ca920284f91ceff30a29340832fe7,3,Point out correct turbofish usage on `Foo>` Whenever we parse a chain of binary operations as long as the first operation is `<` and the subsequent operations are either `>` or `<` present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case.,HEART,2017-03-14T09:57:21Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/40500,MERGED,2017-03-14T02:19:48Z,2017-03-17T20:18:55Z,Point out correct turbofish usage on `Foo>`,estebank,e3b8550a601ca920284f91ceff30a29340832fe7,3,Point out correct turbofish usage on `Foo>` Whenever we parse a chain of binary operations as long as the first operation is `<` and the subsequent operations are either `>` or `<` present the following diagnostic help: use `::<...>` instead of `<...>` if you meant to specify type arguments This will lead to spurious recommendations on situations like `2 < 3 < 4` but should be clear from context that the help doesn't apply in that case.,HEART,2017-03-14T18:47:45Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/40532,MERGED,2017-03-14T22:35:56Z,2017-03-20T11:20:15Z,macros: improve the `TokenStream` quoter,jseyfried,ce616a7d6ad838aacd080b47566c15e82ad8dd6d,8,Improve the `TokenStream` quoter.,HOORAY,2017-03-15T03:51:14Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/40538,MERGED,2017-03-15T05:15:47Z,2017-03-19T07:06:48Z,Library stabilizations for 1.17,aturon,1241a88fa9ddf5e645d1e6e93e04c435bbf15cd4,7,Minor fixups to fix tidy errors,HOORAY,2017-03-19T08:10:21Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/40541,CLOSED,2017-03-15T06:26:02Z,2017-04-10T04:01:01Z,fixed some clippy warnings in libcollections,llogiq,NA,NA,NA,HEART,2017-03-15T19:01:28Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40542,MERGED,2017-03-15T08:33:55Z,2017-03-23T06:31:15Z,Correctly get source for metatdata-only crate type,abonander,8a6ef505750152cf9034dfe26858b241221a3400,4,Regression test for rust-lang/rust#40535,HOORAY,2017-03-18T04:43:42Z,estebank,NA https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-03-15T23:27:28Z,retep998,NA https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-03-16T17:27:39Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-03-19T22:36:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-04T18:36:35Z,bluss,NA https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-05T07:51:05Z,pczarn,NA https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-11T18:59:30Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-11T22:03:20Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-11T22:59:33Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-12T15:04:47Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-04-12T17:29:13Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40561,MERGED,2017-03-15T22:37:10Z,2017-04-06T03:20:20Z,Simplify HashMap Bucket interface,arthurprs,f07ebd609796226e672737e502525fbbf5e27940,2,Simplify HashMap Bucket interface * Store capacity_mask instead of capacity * Move bucket index into RawBucket * Bucket index is now always within [0..table_capacity) * Clone RawTable using RawBucket * Simplify iterators by moving logic into RawBuckets * Make retain aware of the number of elements,HOORAY,2017-08-31T03:00:41Z,overvenus,NA https://github.com/rust-lang/rust/pull/40565,MERGED,2017-03-16T02:23:16Z,2017-04-11T01:25:29Z,Explicit help message for binop type mismatch,estebank,be8787dfe564cf315a9343a84724130da322e805,8,Explicit help message for binop type missmatch When trying to do a binary operation with missing implementation for example `1 + Some(2)` provide an explicit help message: ``` note: no implementation for `{integer} + std::option::Option<{integer}>` ``` Use `rustc_on_unimplemented` for the suggestions. Move cfail test to ui.,THUMBS_UP,2017-03-17T12:55:37Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/40567,MERGED,2017-03-16T04:14:39Z,2017-03-25T02:06:21Z,Fix for #39596: sort Trait2 before Trait10.,clarfonthey,c09083c3d1b077df9adf3d6b4048677a15ba666e,1,Fix for #39596: sort Trait1 before Trait2.,HEART,2017-03-25T20:16:48Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/40581,MERGED,2017-03-16T20:15:07Z,2017-03-20T11:20:18Z,[LLVM 4.0] Add missing debuginfo metadata to globals,TimNN,95bd7f2e013ad79d857ac54b42b362b36ae8806d,1,add missing global metadata,HEART,2017-03-16T20:27:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40581,MERGED,2017-03-16T20:15:07Z,2017-03-20T11:20:18Z,[LLVM 4.0] Add missing debuginfo metadata to globals,TimNN,95bd7f2e013ad79d857ac54b42b362b36ae8806d,1,add missing global metadata,HEART,2017-03-16T21:04:12Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40581,MERGED,2017-03-16T20:15:07Z,2017-03-20T11:20:18Z,[LLVM 4.0] Add missing debuginfo metadata to globals,TimNN,95bd7f2e013ad79d857ac54b42b362b36ae8806d,1,add missing global metadata,THUMBS_UP,2017-03-16T21:04:17Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40581,MERGED,2017-03-16T20:15:07Z,2017-03-20T11:20:18Z,[LLVM 4.0] Add missing debuginfo metadata to globals,TimNN,95bd7f2e013ad79d857ac54b42b362b36ae8806d,1,add missing global metadata,THUMBS_UP,2017-03-20T12:31:59Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40581,MERGED,2017-03-16T20:15:07Z,2017-03-20T11:20:18Z,[LLVM 4.0] Add missing debuginfo metadata to globals,TimNN,95bd7f2e013ad79d857ac54b42b362b36ae8806d,1,add missing global metadata,THUMBS_UP,2017-03-20T13:58:09Z,ranma42,NA https://github.com/rust-lang/rust/pull/40597,MERGED,2017-03-17T09:41:24Z,2017-03-30T09:25:15Z,macros: improve `Span`'s expansion information,jseyfried,8fde04b4a295792249d4a01f87a9f66143aa7c83,9,Improve `Path` spans.,HEART,2017-03-30T09:34:16Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-18T12:11:31Z,killercup,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-18T13:49:25Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-29T11:18:45Z,StefanoD,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-29T17:55:21Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-29T19:26:24Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2017-03-30T10:45:53Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2019-01-23T10:49:40Z,frol,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2020-04-04T02:04:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2020-04-05T13:36:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/40601,MERGED,2017-03-17T15:02:48Z,2017-03-21T22:21:26Z,Implement feature sort_unstable,NA,NA,NA,NA,HEART,2020-04-27T16:57:49Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/40617,MERGED,2017-03-17T21:54:57Z,2017-03-23T06:31:18Z,Update gcc used for dist-x86-linux builds,TimNN,88d5645fb861354f46d507f8d5764e79ae099519,2,dist-x86-linux: ugrade gcc to 4.8.5,THUMBS_UP,2017-03-21T22:55:39Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HOORAY,2017-03-17T23:15:33Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HEART,2017-03-17T23:15:34Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HEART,2017-03-18T00:05:27Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HOORAY,2017-03-19T21:04:27Z,estebank,NA https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HEART,2017-03-21T12:36:46Z,MrOutput,r.cepeda@linux.com https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HOORAY,2017-03-21T12:36:48Z,MrOutput,r.cepeda@linux.com https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HOORAY,2017-03-31T06:23:28Z,radix,NA https://github.com/rust-lang/rust/pull/40620,MERGED,2017-03-17T23:15:08Z,2017-03-31T05:50:32Z,Replace hardcoded forward slash with path::MAIN_SEPARATOR,laumann,b3763862280946cab09cbedc4ad5626ebd95a5b2,4,Replace hardcoded forward slash with path::MAIN_SEPARATOR Fixes #40149,HEART,2017-03-31T06:23:32Z,radix,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-03-19T23:48:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-03-20T00:02:53Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-03-20T06:43:43Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-03-20T08:07:35Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-03-20T18:21:53Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-09T22:25:04Z,dsprenkels,daan@dsprenkels.com https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-11T22:58:36Z,Diggsey,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-12T06:17:38Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-12T07:28:05Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-12T17:17:00Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40658,MERGED,2017-03-19T23:44:11Z,2017-04-09T15:30:18Z,Use ty::layout for ABI computation instead of LLVM types.,eddyb,f0636b61c7f84962a609e831760db9d77f4f5e14,22,rustc_trans: use ty::layout for ABI computation instead of LLVM types.,HOORAY,2017-04-12T18:17:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/40694,MERGED,2017-03-21T04:37:22Z,2017-03-31T18:40:30Z,Sync all unstable features with Unstable Book; add tidy lint. ,frewsxcv,eef2a9598b9a149d45d440efe0580604b5726527,10,Sync all unstable features with Unstable Book; add tidy lint. Add a tidy lint that checks for... * Unstable Book sections with no corresponding SUMMARY.md links * unstable features that don't have Unstable Book sections * Unstable Book sections that don't have corresponding unstable features,HEART,2017-03-21T13:06:31Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/40694,MERGED,2017-03-21T04:37:22Z,2017-03-31T18:40:30Z,Sync all unstable features with Unstable Book; add tidy lint. ,frewsxcv,eef2a9598b9a149d45d440efe0580604b5726527,10,Sync all unstable features with Unstable Book; add tidy lint. Add a tidy lint that checks for... * Unstable Book sections with no corresponding SUMMARY.md links * unstable features that don't have Unstable Book sections * Unstable Book sections that don't have corresponding unstable features,HEART,2017-03-21T20:11:56Z,mrhota,NA https://github.com/rust-lang/rust/pull/40694,MERGED,2017-03-21T04:37:22Z,2017-03-31T18:40:30Z,Sync all unstable features with Unstable Book; add tidy lint. ,frewsxcv,eef2a9598b9a149d45d440efe0580604b5726527,10,Sync all unstable features with Unstable Book; add tidy lint. Add a tidy lint that checks for... * Unstable Book sections with no corresponding SUMMARY.md links * unstable features that don't have Unstable Book sections * Unstable Book sections that don't have corresponding unstable features,HEART,2017-03-22T18:51:51Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40719,CLOSED,2017-03-21T22:53:44Z,2017-05-21T01:23:31Z,Tiny update to rustdoc CSS,icefoxen,NA,NA,NA,THUMBS_UP,2017-03-22T03:06:12Z,estebank,NA https://github.com/rust-lang/rust/pull/40719,CLOSED,2017-03-21T22:53:44Z,2017-05-21T01:23:31Z,Tiny update to rustdoc CSS,icefoxen,NA,NA,NA,THUMBS_UP,2017-03-22T14:35:34Z,mrhota,NA https://github.com/rust-lang/rust/pull/40719,CLOSED,2017-03-21T22:53:44Z,2017-05-21T01:23:31Z,Tiny update to rustdoc CSS,icefoxen,NA,NA,NA,THUMBS_DOWN,2017-04-24T21:32:31Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/40720,MERGED,2017-03-21T23:13:14Z,2017-03-29T17:59:53Z,Added core::cmp::Reverse for sort_by_key reverse sorting,mitsuhiko,5d3695362f795a45947e92c77f910dcacba575ea,1,Updated tracking issue for cmp::Reverse,THUMBS_UP,2017-03-23T07:03:02Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/40720,MERGED,2017-03-21T23:13:14Z,2017-03-29T17:59:53Z,Added core::cmp::Reverse for sort_by_key reverse sorting,mitsuhiko,5d3695362f795a45947e92c77f910dcacba575ea,1,Updated tracking issue for cmp::Reverse,THUMBS_UP,2017-03-29T10:54:40Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/40720,MERGED,2017-03-21T23:13:14Z,2017-03-29T17:59:53Z,Added core::cmp::Reverse for sort_by_key reverse sorting,mitsuhiko,5d3695362f795a45947e92c77f910dcacba575ea,1,Updated tracking issue for cmp::Reverse,HEART,2017-04-05T12:02:15Z,Taneb,NA https://github.com/rust-lang/rust/pull/40731,MERGED,2017-03-22T08:01:48Z,2017-03-29T06:29:57Z,Specialize Vec::from_iter for vec::IntoIter,sfackler,dae66e000a974dd3bea7ae10b8827a5ece2b941e,2,Specialize Vec::from_iter for vec::IntoIter It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.,THUMBS_UP,2017-03-22T10:11:50Z,malbarbo,NA https://github.com/rust-lang/rust/pull/40731,MERGED,2017-03-22T08:01:48Z,2017-03-29T06:29:57Z,Specialize Vec::from_iter for vec::IntoIter,sfackler,dae66e000a974dd3bea7ae10b8827a5ece2b941e,2,Specialize Vec::from_iter for vec::IntoIter It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.,THUMBS_UP,2017-03-22T17:48:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40731,MERGED,2017-03-22T08:01:48Z,2017-03-29T06:29:57Z,Specialize Vec::from_iter for vec::IntoIter,sfackler,dae66e000a974dd3bea7ae10b8827a5ece2b941e,2,Specialize Vec::from_iter for vec::IntoIter It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.,HOORAY,2017-03-27T23:22:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/40731,MERGED,2017-03-22T08:01:48Z,2017-03-29T06:29:57Z,Specialize Vec::from_iter for vec::IntoIter,sfackler,dae66e000a974dd3bea7ae10b8827a5ece2b941e,2,Specialize Vec::from_iter for vec::IntoIter It's fairly common to expose an API which takes an `IntoIterator` and immediately collects that into a vector. It's also common to buffer a bunch of items into a vector and then pass that into one of these APIs. If the iterator hasn't been advanced we can make this `from_iter` simply reassemble the original `Vec` with no actual iteration or reallocation.,HOORAY,2017-04-05T00:20:10Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/40734,MERGED,2017-03-22T12:48:56Z,2017-03-26T16:35:24Z,Add warning for use of lifetime parameter with 'static bound,adamransom,e7949d0013bb8b45c884b173ca22c20e6899d612,2,Warn when using a `'static` lifetime bound Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling even though it could be considered valid. However it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly in place of the lifetime parameter.,THUMBS_UP,2017-03-29T09:17:29Z,Havvy,NA https://github.com/rust-lang/rust/pull/40737,MERGED,2017-03-22T16:41:51Z,2017-03-31T13:50:14Z,Checked slicing for strings,nagisa,53a36923f12d6c9b7ef9cb0fe73cda50385b1f70,3,Fix the tests,HEART,2017-03-31T00:17:12Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/40737,MERGED,2017-03-22T16:41:51Z,2017-03-31T13:50:14Z,Checked slicing for strings,nagisa,53a36923f12d6c9b7ef9cb0fe73cda50385b1f70,3,Fix the tests,HEART,2017-03-31T14:40:41Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/40751,MERGED,2017-03-23T03:34:08Z,2017-03-29T00:09:37Z,save-analysis: allow clients to get data directly without writing to a file.,nrc,3ec61ea921a0090e97d3ec6a306561c8c6bacc91,4,save-analysis: allow clients to get data directly without writing to a file,THUMBS_UP,2017-03-24T07:33:40Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/40771,MERGED,2017-03-23T19:30:15Z,2017-03-26T16:35:26Z,on-demandify privacy and access levels,nikomatsakis,a9f6babcda1479f4e5566d1aadbf9a0d99aa3182,10,convert privacy access levels into a query,THUMBS_UP,2017-03-23T20:56:58Z,cramertj,NA https://github.com/rust-lang/rust/pull/40775,MERGED,2017-03-23T22:17:50Z,2017-04-08T11:47:53Z,Suggest using enum when a variant is used as a type,estebank,2b2eeda0831401935a45c70667cf4c3eaedafe7d,3,Move tests from ui to cfail,HOORAY,2017-04-12T07:31:06Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/40775,MERGED,2017-03-23T22:17:50Z,2017-04-08T11:47:53Z,Suggest using enum when a variant is used as a type,estebank,2b2eeda0831401935a45c70667cf4c3eaedafe7d,3,Move tests from ui to cfail,HOORAY,2017-04-12T17:31:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40776,CLOSED,2017-03-23T22:32:10Z,2017-04-24T15:09:40Z,Add an option to run rustbuild on low priority on Windows,Zoxc,NA,NA,NA,LAUGH,2017-03-23T22:47:29Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/40776,CLOSED,2017-03-23T22:32:10Z,2017-04-24T15:09:40Z,Add an option to run rustbuild on low priority on Windows,Zoxc,NA,NA,NA,THUMBS_UP,2017-03-23T23:19:37Z,retep998,NA https://github.com/rust-lang/rust/pull/40776,CLOSED,2017-03-23T22:32:10Z,2017-04-24T15:09:40Z,Add an option to run rustbuild on low priority on Windows,Zoxc,NA,NA,NA,LAUGH,2017-03-24T02:59:13Z,est31,NA https://github.com/rust-lang/rust/pull/40776,CLOSED,2017-03-23T22:32:10Z,2017-04-24T15:09:40Z,Add an option to run rustbuild on low priority on Windows,Zoxc,NA,NA,NA,THUMBS_UP,2017-03-24T06:21:00Z,hban,NA https://github.com/rust-lang/rust/pull/40779,MERGED,2017-03-23T23:27:40Z,2017-03-24T23:46:55Z,update LLVM with fix for PR32379,arielb1,bd52ff1cc3ff9ecce129d20ed56c61ec0b0c5653,4,update LLVM with fix for PR32379 Fixes #40593.,HOORAY,2017-03-23T23:43:01Z,krdln,NA https://github.com/rust-lang/rust/pull/40780,MERGED,2017-03-24T00:03:51Z,2017-03-30T00:09:24Z,Attempt to cache git modules,aidanhs,96e174febdd9e0f3624b59e8411332b3e46eb97b,1,Minor tweaks to retry utility,HOORAY,2017-03-24T01:57:53Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40790,MERGED,2017-03-24T05:09:40Z,2017-03-25T02:06:28Z,Unnecessary iteration in BTreeMap::drop,stepancheg,f97b3f08cde6dff89c8c236fce2479725d7f909e,1,Unnecessary iteration in BTreeMap::drop `IntoIter::drop` already iterates.,THUMBS_UP,2017-03-24T07:30:57Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-03-25T21:41:21Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-03-29T11:17:55Z,StefanoD,NA https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-03-29T14:39:37Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-03-30T13:16:21Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,THUMBS_UP,2017-03-30T14:29:39Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-04-03T20:55:07Z,bluss,NA https://github.com/rust-lang/rust/pull/40807,MERGED,2017-03-24T23:35:22Z,2017-03-26T16:35:27Z,Optimize insertion sort,NA,NA,NA,NA,HOORAY,2017-05-12T15:06:27Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/40820,MERGED,2017-03-25T10:53:20Z,2017-03-26T16:35:29Z,Fix typo in dec2flt/algorithm.rs,irfanhudda,5d9d652e0f746d7db9542f95115d5820fefeedaa,1,Fix typo in dec2flt/algorithm.rs,THUMBS_UP,2017-03-25T12:54:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/40838,MERGED,2017-03-26T15:51:01Z,2017-03-29T06:30:01Z,Improve std::net docs,chordowl,b8cbc5d46af4b15bfeca324aa37d8c2ca054e58e,3,"Addressed requested changes for PR #40838 * Fixed spelling ToSocketAddr -> ToSocketAddrs in module docs (which also fixes a link) * Added missing ""when"" before ""interacting"" in module docs * Changed SocketAddr's top-level docs to explicitly state what socket addresses consist of making them more consistent with SocketAddrV4's and SocketAddrV6's docs * Changed ""in C"" -> ""in C's `netinet/in.h`"" * Changed wording in is_ipv4/is_ipv6 methods to "" `false` otherwise"" * Add missing closing ` ``` ` in Ipv6Addr's examples * Removed ""Errors"" section in ToSocketAddrs' to_socket_addrs method as it was rather redundant",HEART,2017-03-26T16:32:15Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/40838,MERGED,2017-03-26T15:51:01Z,2017-03-29T06:30:01Z,Improve std::net docs,chordowl,b8cbc5d46af4b15bfeca324aa37d8c2ca054e58e,3,"Addressed requested changes for PR #40838 * Fixed spelling ToSocketAddr -> ToSocketAddrs in module docs (which also fixes a link) * Added missing ""when"" before ""interacting"" in module docs * Changed SocketAddr's top-level docs to explicitly state what socket addresses consist of making them more consistent with SocketAddrV4's and SocketAddrV6's docs * Changed ""in C"" -> ""in C's `netinet/in.h`"" * Changed wording in is_ipv4/is_ipv6 methods to "" `false` otherwise"" * Add missing closing ` ``` ` in Ipv6Addr's examples * Removed ""Errors"" section in ToSocketAddrs' to_socket_addrs method as it was rather redundant",THUMBS_UP,2017-03-27T13:45:43Z,achanda,NA https://github.com/rust-lang/rust/pull/40838,MERGED,2017-03-26T15:51:01Z,2017-03-29T06:30:01Z,Improve std::net docs,chordowl,b8cbc5d46af4b15bfeca324aa37d8c2ca054e58e,3,"Addressed requested changes for PR #40838 * Fixed spelling ToSocketAddr -> ToSocketAddrs in module docs (which also fixes a link) * Added missing ""when"" before ""interacting"" in module docs * Changed SocketAddr's top-level docs to explicitly state what socket addresses consist of making them more consistent with SocketAddrV4's and SocketAddrV6's docs * Changed ""in C"" -> ""in C's `netinet/in.h`"" * Changed wording in is_ipv4/is_ipv6 methods to "" `false` otherwise"" * Add missing closing ` ``` ` in Ipv6Addr's examples * Removed ""Errors"" section in ToSocketAddrs' to_socket_addrs method as it was rather redundant",THUMBS_UP,2017-03-28T05:19:58Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/40841,MERGED,2017-03-26T17:00:18Z,2017-03-29T17:59:57Z,borrowck: consolidate `mut` suggestions,arielb1,39011f8590b69d5ee9037c4ac9b863a516ae2e1e,5,fix handling of `self`,HOORAY,2017-03-26T17:50:04Z,estebank,NA https://github.com/rust-lang/rust/pull/40841,MERGED,2017-03-26T17:00:18Z,2017-03-29T17:59:57Z,borrowck: consolidate `mut` suggestions,arielb1,39011f8590b69d5ee9037c4ac9b863a516ae2e1e,5,fix handling of `self`,HOORAY,2017-03-27T01:44:56Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-03-27T01:13:18Z,est31,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T01:15:54Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T01:35:49Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T01:39:59Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T02:08:18Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T07:49:32Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T08:13:58Z,killercup,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T11:18:38Z,alexbool,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-03-27T11:18:39Z,alexbool,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-27T23:09:22Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-03-27T23:09:26Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-03-28T05:33:41Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-28T09:03:24Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-03-28T22:39:37Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-03-31T07:34:22Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-04-01T03:49:22Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-04-09T23:57:50Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-04-10T21:30:29Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-05T22:08:37Z,cramertj,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-08T14:04:48Z,SamWhited,sam@samwhited.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-10T00:07:36Z,tikue,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-10T03:39:01Z,kmcallister,mcallister.keegan@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-13T17:49:40Z,rushmorem,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-13T17:49:40Z,rushmorem,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-15T01:20:44Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-15T04:44:59Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-22T01:33:09Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-22T01:36:37Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-22T07:16:54Z,DaseinPhaos,luxko@qq.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-29T09:35:11Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-30T23:37:10Z,Cldfire,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-30T23:59:15Z,chrish42,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T00:45:39Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T04:12:37Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-31T05:15:52Z,UtherII,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T05:33:35Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-31T06:20:54Z,kpp,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T06:20:55Z,kpp,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T07:53:16Z,huwsun,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-31T07:53:22Z,huwsun,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T09:38:48Z,UtherII,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T14:38:43Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-31T17:31:46Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T17:45:39Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T19:11:00Z,jan-hudec,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-05-31T20:59:56Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-05-31T20:59:58Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-06-01T22:16:04Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-06-01T22:16:05Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-06-03T13:21:09Z,Ixrec,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-06-12T14:22:47Z,unship,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-06-25T04:27:56Z,Boscop,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2017-06-25T04:27:56Z,Boscop,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-10-17T23:35:27Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-12-21T04:06:02Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2017-12-27T02:54:44Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-01-13T14:17:02Z,bash,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-02-21T20:17:59Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2018-02-21T20:18:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-02-21T21:13:37Z,boopathi,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2018-03-19T20:17:53Z,Gedweb,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-04-16T05:50:32Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-04-25T07:04:27Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-05-22T18:28:05Z,hcpl,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-10-07T21:16:51Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2018-10-07T21:16:53Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2018-10-08T01:53:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2019-05-26T21:31:17Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2019-08-27T06:52:59Z,argv-minus-one,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2021-02-01T17:32:27Z,lukechu10,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2021-03-20T11:50:51Z,toiglak,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2021-03-22T20:16:01Z,lukechu10,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2021-09-10T16:39:20Z,ogxd,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HEART,2022-05-06T00:21:52Z,zohnannor,NA https://github.com/rust-lang/rust/pull/40847,MERGED,2017-03-27T00:53:08Z,2017-05-26T01:10:15Z,Initial implementation of declarative macros 2.0,jseyfried,dc34ea092976ab9a87e68f1b255b4afbe31a9475,1,Fix merge conflicts.,HOORAY,2022-05-06T00:21:53Z,zohnannor,NA https://github.com/rust-lang/rust/pull/40851,MERGED,2017-03-27T12:07:04Z,2017-05-02T03:26:39Z,Minimize single span suggestions into a label,oli-obk,d64af4a627532c978ed2682de0e9411aa3a83e75,7,Rebase and address comments,THUMBS_UP,2017-03-27T22:28:26Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40851,MERGED,2017-03-27T12:07:04Z,2017-05-02T03:26:39Z,Minimize single span suggestions into a label,oli-obk,d64af4a627532c978ed2682de0e9411aa3a83e75,7,Rebase and address comments,THUMBS_UP,2017-03-29T06:35:20Z,estebank,NA https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,THUMBS_UP,2017-03-29T16:46:48Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,HEART,2017-04-02T00:07:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,HEART,2017-04-17T11:58:15Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,HEART,2017-05-07T16:08:11Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,HEART,2017-05-10T16:28:56Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/40857,MERGED,2017-03-27T16:43:32Z,2017-05-07T16:20:15Z,Point at fields that make the type recursive,estebank,a4fc9251920260e1b0b3dff71c8da8b3af2c5453,9,Move logic to `is_representable` instead of climbing HIR,HEART,2017-05-10T19:04:44Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2017-03-27T22:22:07Z,retep998,NA https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2017-03-27T22:43:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2017-03-28T07:19:27Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2017-06-08T17:07:44Z,gabdube,gdube.475@gmail.com https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2018-07-09T07:12:49Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/40870,MERGED,2017-03-27T21:16:35Z,2017-04-05T19:47:50Z,rustc: Stabilize the `#![windows_subsystem]` attribute,alexcrichton,34cf28826f380fde33fedf377c1540e12d3b13a0,7,rustc: Stabilize the `#![windows_subsystem]` attribute This commit stabilizes the `#![windows_subsystem]` attribute which is a conservative exposure of the `/SUBSYSTEM` linker flag on Widnows platforms. This is useful for creating applications as well as console programs. Closes #37499,HOORAY,2021-07-27T10:51:48Z,Lintkey,Lintkey@outlook.com https://github.com/rust-lang/rust/pull/40897,MERGED,2017-03-29T11:22:35Z,2017-03-29T18:00:00Z,Fix typo in libcore/char.rs,irfanhudda,3783c44eac713028969ac3cbdad6f30a3dbbbf97,1,Fix typo in libcore/char.rs,HEART,2017-03-29T11:25:31Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/40914,CLOSED,2017-03-29T22:29:50Z,2017-07-11T10:51:01Z,Update LLVM to pull in patch that removes extraneous null check.,luqmana,NA,NA,NA,HEART,2017-03-30T14:42:18Z,bluss,NA https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-03-31T12:44:24Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2017-03-31T23:08:53Z,est31,NA https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-04-02T17:46:45Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-04-02T18:14:16Z,SiegeLord,NA https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-04-03T21:01:41Z,jntrnr,NA https://github.com/rust-lang/rust/pull/40938,CLOSED,2017-03-31T02:12:43Z,2017-04-04T16:06:43Z,Add notifications when rust build ends,GuillaumeGomez,NA,NA,NA,CONFUSED,2017-04-03T21:30:11Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,THUMBS_UP,2017-03-31T08:04:29Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,THUMBS_UP,2017-03-31T15:13:53Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-03-31T18:59:57Z,tikue,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-04-02T08:17:24Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HEART,2017-04-02T08:17:30Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-04-09T23:49:06Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-04-11T10:06:48Z,kennytm,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-05-01T04:01:06Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-05-05T22:05:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-05-10T14:11:33Z,oli-obk,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-05-15T01:16:06Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-05-22T23:26:20Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-07-04T16:20:25Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2017-07-17T18:26:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,THUMBS_UP,2017-12-28T15:29:45Z,fluxxu,NA https://github.com/rust-lang/rust/pull/40939,MERGED,2017-03-31T05:09:57Z,2017-07-06T00:15:56Z,proc_macro: implement `TokenTree` `TokenKind` hygienic `quote!` and other API,jseyfried,78fdbfc4008b52bcce201fd589ed84d2abb0419d,1,rustbuild: Only -Zsave-analysis for libstd Don't pass the flag when we're compiling the compiler or other related tools,HOORAY,2018-05-22T00:03:35Z,hcpl,NA https://github.com/rust-lang/rust/pull/40971,MERGED,2017-03-31T20:29:27Z,2017-04-07T15:25:55Z,Use 64 bits emulator to run android tests,malbarbo,113b3b46a77222fe898b0a6678af451f29a7acc4,2,Use 64 bits emulator to run android tests Also install headless jre instead of the full jre.,THUMBS_UP,2017-04-07T14:04:34Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/40976,MERGED,2017-03-31T23:20:50Z,2017-04-07T01:27:27Z,Don't warn about `char` comparisons in constexprs,matthewjasper,2060266c1691f11a3c204ead056fe2e7a8c20e3b,2,Don't warn about `char` comparisons in constexprs,HEART,2017-04-03T02:25:45Z,bluss,NA https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2017-04-01T08:35:16Z,harpocrates,alec.theriault@gmail.com https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2017-04-01T10:25:20Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2017-04-01T11:13:32Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2017-04-01T15:56:20Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,HEART,2017-04-01T20:34:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,HEART,2017-04-06T21:26:06Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2017-04-06T21:26:07Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,HEART,2017-04-11T14:28:56Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/40989,MERGED,2017-04-01T08:15:32Z,2017-07-19T03:06:20Z,Unify rules about commas in match arms and semicolons in expressions,matklad,e3d052f30af80e58289065bb3d7520e0e7be1ee8,1,Ignore pretty-test,THUMBS_UP,2018-11-25T17:46:44Z,hcpl,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-01T23:25:50Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-01T23:42:49Z,sfackler,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-02T02:49:23Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-02T02:55:21Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-02T09:26:51Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-03T13:43:19Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-04-20T14:37:00Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-05-05T21:52:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-08-28T17:14:37Z,alygin,alygin@gmail.com https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-09-01T20:16:35Z,pitdicker,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2017-09-05T01:14:25Z,delacian,NA https://github.com/rust-lang/rust/pull/41005,CLOSED,2017-04-01T22:20:24Z,2017-05-16T15:28:14Z,Move Rc and Arc to 32-bit reference counts,Gankra,NA,NA,NA,THUMBS_UP,2021-06-16T15:41:23Z,Quant1um,NA https://github.com/rust-lang/rust/pull/41011,MERGED,2017-04-02T05:19:33Z,2017-04-06T08:35:05Z,Overhaul Bootstrap (x.py) Command-Line-Parsing & Help Output,CleanCut,ea2bfae8694221c92857a0b3dd96f63a8a255db2,1,Branch arms need to match the return value even if it's not being assigned to anything,THUMBS_UP,2017-04-02T07:49:36Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/41012,MERGED,2017-04-02T05:57:40Z,2017-04-17T20:33:45Z,:vis matcher for macro_rules,durka,cfa51f226f8190f74bcd3f8275ae05b9d76d59c4,1,satisfy completely useless tidy check,THUMBS_UP,2017-04-02T07:03:34Z,jseyfried,NA https://github.com/rust-lang/rust/pull/41012,MERGED,2017-04-02T05:57:40Z,2017-04-17T20:33:45Z,:vis matcher for macro_rules,durka,cfa51f226f8190f74bcd3f8275ae05b9d76d59c4,1,satisfy completely useless tidy check,THUMBS_UP,2017-04-02T09:01:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/41012,MERGED,2017-04-02T05:57:40Z,2017-04-17T20:33:45Z,:vis matcher for macro_rules,durka,cfa51f226f8190f74bcd3f8275ae05b9d76d59c4,1,satisfy completely useless tidy check,HOORAY,2017-04-03T19:38:06Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/41024,CLOSED,2017-04-02T21:08:26Z,2017-04-21T15:21:06Z,Implement MIR pass to lower intrinsics,aochagavia,NA,NA,NA,HEART,2017-04-06T08:53:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/41029,CLOSED,2017-04-03T05:57:07Z,2017-05-04T18:26:13Z,macros: expand items before their `#[derive]`s,jseyfried,NA,NA,NA,THUMBS_UP,2017-04-05T23:02:53Z,keeperofdakeys,NA https://github.com/rust-lang/rust/pull/41037,MERGED,2017-04-03T14:56:33Z,2017-04-06T08:35:06Z,Move libXtest into libX/tests,NA,NA,NA,NA,THUMBS_UP,2017-04-03T17:33:34Z,malbarbo,NA https://github.com/rust-lang/rust/pull/41052,MERGED,2017-04-04T01:53:26Z,2017-04-06T03:20:29Z,Make 'overlapping_inherent_impls' lint a hard error,topecongiro,db60b0b374ef4999e3c960a7230b18bcddf82ea0,2,Move 'coherence-overlapping-inherent-impl-trait' test to ui,THUMBS_UP,2017-04-04T10:13:09Z,estebank,NA https://github.com/rust-lang/rust/pull/41055,MERGED,2017-04-04T06:24:36Z,2017-04-08T16:25:38Z,Fixed ICEs with pattern matching in const expression,ryan-scott-dev,c9932b395ada3c367aea5e79645c10657262ea6f,1,Changes based on PR feedback,HEART,2017-04-04T17:51:06Z,brson,NA https://github.com/rust-lang/rust/pull/41084,MERGED,2017-04-05T15:33:23Z,2017-04-09T20:11:10Z,rustdoc: update formatting of fn signatures and where clauses to match style rfcs,QuietMisdreavus,8dd4c44ef6c851afcc9651c9b32df005e35d0d1d,1196,merge with master to pick up pulldown switch,THUMBS_UP,2017-04-05T16:44:47Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/41087,MERGED,2017-04-05T16:53:11Z,2017-04-12T16:05:31Z,Use proper span for tuple index parsed as float,estebank,44e414c4770ff0800c375ddbb8e0f46ee00bcab1,3,Use proper span for tuple index parsed as float Fix diagnostic suggestion from: ```rust help: try parenthesizing the first index | (1 (2 3)).((1 (2 3)).1).1; ``` to the correct: ```rust help: try parenthesizing the first index | ((1 (2 3)).1).1; ```,THUMBS_UP,2017-04-30T03:48:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/41120,MERGED,2017-04-06T18:46:00Z,2017-04-07T18:16:01Z,Remove some CStr transmutes.,clarfonthey,9ffb54568c1d52bfee0162dd75b2c415cbf6fce4,1,Remove some CStr transmutes.,HEART,2017-04-06T20:28:29Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/41141,MERGED,2017-04-07T14:37:04Z,2017-04-12T16:05:32Z,ICH: Replace old transitive metadata hashing with direct hashing approach.,michaelwoerister,ca2dce9b48e65ae2b286fbd10e459536ecccb2d8,27,ICH: Replace old transitive metadata hashing with direct hashing approach. Instead of collecting all potential inputs to some metadata entry and hashing those we directly hash the values we are storing in metadata. This is more accurate and doesn't suffer from quadratic blow-up when many entries have the same dependencies.,HOORAY,2017-04-07T22:02:26Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41168,MERGED,2017-04-08T20:47:51Z,2017-04-11T11:29:02Z,Fix jemalloc support for musl,Shizmob,536011d929ecbd1170baf34e09580e567c971f95,2,Fix jemalloc support for musl Just like DragonFlyBSD using the same symbols as the system allocator will result in a segmentation fault at runtime due to allocator mismatches. As such prefix the jemalloc symbols instead.,THUMBS_UP,2017-04-08T20:48:45Z,jirutka,jakub@jirutka.cz https://github.com/rust-lang/rust/pull/41168,MERGED,2017-04-08T20:47:51Z,2017-04-11T11:29:02Z,Fix jemalloc support for musl,Shizmob,536011d929ecbd1170baf34e09580e567c971f95,2,Fix jemalloc support for musl Just like DragonFlyBSD using the same symbols as the system allocator will result in a segmentation fault at runtime due to allocator mismatches. As such prefix the jemalloc symbols instead.,THUMBS_UP,2017-04-15T19:02:12Z,mkoloberdin,NA https://github.com/rust-lang/rust/pull/41172,MERGED,2017-04-09T16:10:47Z,2017-04-15T01:53:35Z,Fix rustdoc infinitely recursing when an external crate reexports itself,Aaron1011,63a291febac3ba2cb48787fed24388c2817ef4a2,3,Fix rustdoc infinitely recursing when an external crate reexports itself Previously rustdoc's LibEmbargoVisitor unconditionally visited the child modules of an external crate. If a module re-exported its parent via 'pub use super::*' rustdoc would re-walk the parent leading to infinite recursion. This commit makes LibEmbargoVisitor store already visited modules in an FxHashSet ensuring that each module is only walked once. Fixes #40936,THUMBS_UP,2017-04-10T13:00:42Z,flanfly,NA https://github.com/rust-lang/rust/pull/41174,MERGED,2017-04-09T23:31:48Z,2017-04-11T08:33:48Z,Point at only one char on `Span::next_point`,estebank,4c80170782c168e5aae848b2911c16921e5a2f58,4,Point at only one char on `Span::next_point` Avoid pointing at two chars so the diagnostic output doesn't display a multiline span when starting beyond a line end.,HEART,2017-04-11T09:12:14Z,est31,NA https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-05-17T14:10:40Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-05-17T22:07:54Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-05-18T17:47:56Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-05-24T00:24:40Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-05-24T22:26:08Z,Armavica,armavica@ulminfo.fr https://github.com/rust-lang/rust/pull/41192,MERGED,2017-04-10T17:07:44Z,2017-05-11T09:39:38Z,Add `eprint!` and `eprintln!` macros to the prelude.,zackw,72588a2b2a1af655b81fcd3c1c467707d9c237c2,1,Skip print-stdout-eprint-stderr test on emscripten,HOORAY,2017-07-20T21:42:12Z,teddywing,NA https://github.com/rust-lang/rust/pull/41204,MERGED,2017-04-10T21:15:48Z,2017-04-12T03:58:48Z,Fixes incorrect formatting in array's documentation.,remexre,b9d662a00026390aa7b7b5706d3c800e4d6e6fdb,1,Fixes incorrect formatting in array's documentation.,HEART,2017-04-10T21:17:28Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/41204,MERGED,2017-04-10T21:15:48Z,2017-04-12T03:58:48Z,Fixes incorrect formatting in array's documentation.,remexre,b9d662a00026390aa7b7b5706d3c800e4d6e6fdb,1,Fixes incorrect formatting in array's documentation.,HEART,2017-04-10T21:20:40Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/41227,MERGED,2017-04-11T19:00:18Z,2017-04-13T23:01:18Z,rustbuild: Fix recompilation of stage0 tools dir,alexcrichton,2a3355920777956d537db7a0f4c278a280af9abb,2,"rustbuild: Fix recompilation of stage0 tools dir This commit knocks out a longstanding FIXME in rustbuild which should correctly recompile stage0 compiletest and such whenever libstd itself changes. The solution implemented here was to implement a notion of ""order only"" dependencies and then add a new dependency stage for clearing out the tools dir using order-only deps to ensure that it happens correctly. The dependency drawing for tools is a bit wonky now but I think this'll get the job done. Closes #39396",HOORAY,2017-04-13T20:30:12Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41227,MERGED,2017-04-11T19:00:18Z,2017-04-13T23:01:18Z,rustbuild: Fix recompilation of stage0 tools dir,alexcrichton,2a3355920777956d537db7a0f4c278a280af9abb,2,"rustbuild: Fix recompilation of stage0 tools dir This commit knocks out a longstanding FIXME in rustbuild which should correctly recompile stage0 compiletest and such whenever libstd itself changes. The solution implemented here was to implement a notion of ""order only"" dependencies and then add a new dependency stage for clearing out the tools dir using order-only deps to ensure that it happens correctly. The dependency drawing for tools is a bit wonky now but I think this'll get the job done. Closes #39396",HOORAY,2017-04-13T23:04:11Z,est31,NA https://github.com/rust-lang/rust/pull/41227,MERGED,2017-04-11T19:00:18Z,2017-04-13T23:01:18Z,rustbuild: Fix recompilation of stage0 tools dir,alexcrichton,2a3355920777956d537db7a0f4c278a280af9abb,2,"rustbuild: Fix recompilation of stage0 tools dir This commit knocks out a longstanding FIXME in rustbuild which should correctly recompile stage0 compiletest and such whenever libstd itself changes. The solution implemented here was to implement a notion of ""order only"" dependencies and then add a new dependency stage for clearing out the tools dir using order-only deps to ensure that it happens correctly. The dependency drawing for tools is a bit wonky now but I think this'll get the job done. Closes #39396",HOORAY,2017-04-13T23:05:11Z,ranma42,NA https://github.com/rust-lang/rust/pull/41250,MERGED,2017-04-12T16:19:33Z,2017-04-13T20:21:24Z,Fix invalid 128-bit division on 32-bit target (#41228),kennytm,71a9e106690627e657a466938e578608d8bcd04a,3,Fixed invalid 128-bit division on 32-bit target. Fixed issue #41228. Added test cases to cover all special-cased branches of udivmodti4.,THUMBS_UP,2017-04-12T16:42:44Z,est31,NA https://github.com/rust-lang/rust/pull/41250,MERGED,2017-04-12T16:19:33Z,2017-04-13T20:21:24Z,Fix invalid 128-bit division on 32-bit target (#41228),kennytm,71a9e106690627e657a466938e578608d8bcd04a,3,Fixed invalid 128-bit division on 32-bit target. Fixed issue #41228. Added test cases to cover all special-cased branches of udivmodti4.,THUMBS_UP,2017-04-19T18:58:18Z,StefanoD,NA https://github.com/rust-lang/rust/pull/41250,MERGED,2017-04-12T16:19:33Z,2017-04-13T20:21:24Z,Fix invalid 128-bit division on 32-bit target (#41228),kennytm,71a9e106690627e657a466938e578608d8bcd04a,3,Fixed invalid 128-bit division on 32-bit target. Fixed issue #41228. Added test cases to cover all special-cased branches of udivmodti4.,THUMBS_UP,2017-04-20T17:41:50Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/41258,MERGED,2017-04-12T21:13:09Z,2017-04-26T08:45:49Z,More methods for str boxes. (reduce Box<[u8]> ↔ Box transmutes),clarfonthey,c66c6e96978cd81130587e9f4d1fa52dc1b183d6,8,More methods for str boxes.,HEART,2017-05-03T12:28:35Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/41267,MERGED,2017-04-13T05:30:14Z,2017-04-13T11:47:43Z,travis: Enable rust-analysis package for more targets,alexcrichton,cdedecb7baa55a7e9c1aa78d5d7313b94e3e84b1,6,travis: Enable rust-analysis package for more targets This commit enables the `rust-analysis` package to be produced for all targets that are part of the `dist-*` suite of docker images on Travis. Currently these packages are showing up with `available = false` in the `channel-rust-nightly.toml` manifest where we'd prefer to have them show up for all targets. Unfortunately rustup isn't handling the `available = false` section well right now so this should also inadvertently fix the nightly regression.,THUMBS_UP,2017-04-13T10:44:43Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/41267,MERGED,2017-04-13T05:30:14Z,2017-04-13T11:47:43Z,travis: Enable rust-analysis package for more targets,alexcrichton,cdedecb7baa55a7e9c1aa78d5d7313b94e3e84b1,6,travis: Enable rust-analysis package for more targets This commit enables the `rust-analysis` package to be produced for all targets that are part of the `dist-*` suite of docker images on Travis. Currently these packages are showing up with `available = false` in the `channel-rust-nightly.toml` manifest where we'd prefer to have them show up for all targets. Unfortunately rustup isn't handling the `available = false` section well right now so this should also inadvertently fix the nightly regression.,THUMBS_UP,2017-04-13T21:37:33Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/41268,MERGED,2017-04-13T10:11:43Z,2017-05-04T18:46:22Z,Run non-native tests on real device,mmatyas,b194def3a24e5d95c3f8eb7667b24e1237d823d3,4,Add remote device testing support,THUMBS_UP,2017-04-13T12:25:36Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/41280,MERGED,2017-04-13T19:18:42Z,2017-04-17T20:33:49Z,rustdoc: add a list of headings to the sidebar,QuietMisdreavus,27bfbd56f08ab64122a79cb84446a27b99099590,2,rustdoc: add a list of headings to the sidebar,HOORAY,2017-04-13T19:22:33Z,chordowl,NA https://github.com/rust-lang/rust/pull/41280,MERGED,2017-04-13T19:18:42Z,2017-04-17T20:33:49Z,rustdoc: add a list of headings to the sidebar,QuietMisdreavus,27bfbd56f08ab64122a79cb84446a27b99099590,2,rustdoc: add a list of headings to the sidebar,HOORAY,2017-04-13T19:31:16Z,blt,brian@troutwine.us https://github.com/rust-lang/rust/pull/41280,MERGED,2017-04-13T19:18:42Z,2017-04-17T20:33:49Z,rustdoc: add a list of headings to the sidebar,QuietMisdreavus,27bfbd56f08ab64122a79cb84446a27b99099590,2,rustdoc: add a list of headings to the sidebar,THUMBS_UP,2017-04-13T19:38:42Z,radix,NA https://github.com/rust-lang/rust/pull/41280,MERGED,2017-04-13T19:18:42Z,2017-04-17T20:33:49Z,rustdoc: add a list of headings to the sidebar,QuietMisdreavus,27bfbd56f08ab64122a79cb84446a27b99099590,2,rustdoc: add a list of headings to the sidebar,HOORAY,2017-04-13T21:03:06Z,Cldfire,NA https://github.com/rust-lang/rust/pull/41282,MERGED,2017-04-13T20:02:30Z,2017-04-18T00:55:37Z,libsyntax/parse: fix missing kind error reporting,arielb1,d648c10e5bc313af758951c1e6f8ae4782712627,9,libsyntax/parse: improve associated item error reporting Fixes #41161. Fixes #41239.,THUMBS_UP,2017-04-13T23:09:58Z,estebank,NA https://github.com/rust-lang/rust/pull/41282,MERGED,2017-04-13T20:02:30Z,2017-04-18T00:55:37Z,libsyntax/parse: fix missing kind error reporting,arielb1,d648c10e5bc313af758951c1e6f8ae4782712627,9,libsyntax/parse: improve associated item error reporting Fixes #41161. Fixes #41239.,THUMBS_UP,2017-04-16T02:10:54Z,fungos,fungos@gmail.com https://github.com/rust-lang/rust/pull/41290,MERGED,2017-04-13T23:24:12Z,2017-04-17T20:33:49Z,Hoedown big comeback!,GuillaumeGomez,bee02913207ec24913ca4eeb007b402146ed1532,1,Add hoedown COPYRIGHT back,LAUGH,2017-04-13T23:25:51Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/41290,MERGED,2017-04-13T23:24:12Z,2017-04-17T20:33:49Z,Hoedown big comeback!,GuillaumeGomez,bee02913207ec24913ca4eeb007b402146ed1532,1,Add hoedown COPYRIGHT back,HEART,2017-04-13T23:25:59Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/41290,MERGED,2017-04-13T23:24:12Z,2017-04-17T20:33:49Z,Hoedown big comeback!,GuillaumeGomez,bee02913207ec24913ca4eeb007b402146ed1532,1,Add hoedown COPYRIGHT back,LAUGH,2017-04-13T23:38:07Z,Cldfire,NA https://github.com/rust-lang/rust/pull/41290,MERGED,2017-04-13T23:24:12Z,2017-04-17T20:33:49Z,Hoedown big comeback!,GuillaumeGomez,bee02913207ec24913ca4eeb007b402146ed1532,1,Add hoedown COPYRIGHT back,LAUGH,2017-04-15T09:59:45Z,estebank,NA https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-14T23:59:33Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-15T02:30:14Z,est31,NA https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-16T13:49:20Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-18T04:44:49Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-18T21:04:04Z,estebank,NA https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-04-29T09:49:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/41307,MERGED,2017-04-14T23:23:17Z,2017-05-06T01:46:40Z,Remove jquery dependency,GuillaumeGomez,6f4c12e2107ec1f3f283552e81afcfe6307f13eb,6,Remove jquery dependency,HOORAY,2017-05-05T21:50:45Z,cramertj,NA https://github.com/rust-lang/rust/pull/41325,MERGED,2017-04-15T21:14:22Z,2017-04-19T11:07:20Z,Ban registering obligations during InferCtxt snapshots.,eddyb,cd64ff943889b1cda1029a4a0d906d934a47abeb,2,rustc_typeck: fix binops needing more type informations to coerce.,HOORAY,2017-04-15T21:16:37Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,HEART,2017-04-20T02:56:29Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,HEART,2017-04-20T22:18:49Z,bluss,NA https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,HOORAY,2017-05-05T23:30:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,THUMBS_UP,2017-05-30T14:30:39Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,THUMBS_UP,2022-01-18T20:22:01Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,HEART,2022-01-18T20:22:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/41336,CLOSED,2017-04-17T08:14:47Z,2017-06-07T17:06:11Z,Allow T op= &T for built-in numeric types T,Migi,NA,NA,NA,HOORAY,2022-01-18T20:22:04Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/41365,MERGED,2017-04-18T14:17:57Z,2017-04-20T01:52:15Z,[beta] Fix link to book repo,steveklabnik,1605636d4db083d0438af5b6e4986ee44150dac0,1,Fix link to book repo,THUMBS_UP,2017-04-18T17:49:15Z,ScottAbbey,NA https://github.com/rust-lang/rust/pull/41391,MERGED,2017-04-19T05:45:46Z,2017-04-20T04:36:11Z,remove disclaimer from bootstrap/README.md,durka,d6b8d9f75d7ad5ab6f1e198db992f10d4ce5fad5,1,remove disclaimer from bootstrap/README.md,THUMBS_UP,2017-04-19T06:28:01Z,retep998,NA https://github.com/rust-lang/rust/pull/41391,MERGED,2017-04-19T05:45:46Z,2017-04-20T04:36:11Z,remove disclaimer from bootstrap/README.md,durka,d6b8d9f75d7ad5ab6f1e198db992f10d4ce5fad5,1,remove disclaimer from bootstrap/README.md,LAUGH,2017-04-19T06:28:04Z,retep998,NA https://github.com/rust-lang/rust/pull/41391,MERGED,2017-04-19T05:45:46Z,2017-04-20T04:36:11Z,remove disclaimer from bootstrap/README.md,durka,d6b8d9f75d7ad5ab6f1e198db992f10d4ce5fad5,1,remove disclaimer from bootstrap/README.md,LAUGH,2017-04-19T18:35:19Z,kennytm,NA https://github.com/rust-lang/rust/pull/41405,MERGED,2017-04-19T22:32:05Z,2017-04-22T06:12:20Z,Fix line display for hoedown,GuillaumeGomez,a65461005a496f0713e5422647b46f53eee34feb,3,Fix line display for hoedown,HEART,2017-04-20T00:14:29Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/41405,MERGED,2017-04-19T22:32:05Z,2017-04-22T06:12:20Z,Fix line display for hoedown,GuillaumeGomez,a65461005a496f0713e5422647b46f53eee34feb,3,Fix line display for hoedown,HOORAY,2017-04-20T01:53:15Z,kennytm,NA https://github.com/rust-lang/rust/pull/41409,CLOSED,2017-04-19T23:42:36Z,2017-05-18T23:29:36Z,Allow linking JS libraries to Emscripten target,RReverser,NA,NA,NA,THUMBS_UP,2017-05-14T22:04:28Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/41409,CLOSED,2017-04-19T23:42:36Z,2017-05-18T23:29:36Z,Allow linking JS libraries to Emscripten target,RReverser,NA,NA,NA,THUMBS_UP,2017-05-15T11:57:52Z,chpio,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T12:42:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T14:13:02Z,est31,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T14:46:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HEART,2017-04-20T15:24:31Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T16:00:25Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T16:33:54Z,chordowl,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HEART,2017-04-20T16:47:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-20T16:47:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HEART,2017-04-20T18:26:49Z,killercup,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-22T12:49:44Z,delacian,NA https://github.com/rust-lang/rust/pull/41410,CLOSED,2017-04-20T00:21:35Z,2017-04-22T18:03:31Z,Performance audit Spring 2017,arielb1,NA,NA,NA,HOORAY,2017-04-22T13:01:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/41437,MERGED,2017-04-21T01:27:59Z,2017-04-23T04:33:56Z,Remove items that are unstable and deprecated,cuviper,13d2534fd3040520622a2b2a262ed9e7079c9fd8,1,Remove unused import.,HOORAY,2017-04-26T21:09:10Z,bstrie,NA https://github.com/rust-lang/rust/pull/41439,MERGED,2017-04-21T06:29:44Z,2017-05-19T20:41:25Z,Stabilize step_by by adding it to Iterator (issue #27741),ivandardi,49555172016d3ca59b8ece596e28578741d8d076,1,Add entry to the Unstable Book,THUMBS_UP,2017-05-24T05:54:10Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/41447,MERGED,2017-04-21T14:18:49Z,2017-04-27T19:46:16Z,appveyor: Use Ninja/sccache on MSVC,alexcrichton,2e72bcb9347aa1bafe63c4a64a824ac091babfd8,39,appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.,HOORAY,2017-04-21T16:46:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41447,MERGED,2017-04-21T14:18:49Z,2017-04-27T19:46:16Z,appveyor: Use Ninja/sccache on MSVC,alexcrichton,2e72bcb9347aa1bafe63c4a64a824ac091babfd8,39,appveyor: Use Ninja/sccache on MSVC Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.,HOORAY,2017-04-23T03:22:39Z,est31,NA https://github.com/rust-lang/rust/pull/41463,MERGED,2017-04-22T08:15:54Z,2017-04-26T06:16:21Z,Add internal accessor methods to io::{Chain Take}.,SergioBenitez,c168d8bb07392ca6c5e30c2cde1458c9e32bf03b,1,Add cautions to io::get_mut method documentation.,HOORAY,2017-05-17T15:01:51Z,docbrown,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-04-26T12:09:42Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-04-26T14:42:28Z,CvX,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-04-26T19:40:02Z,killercup,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-04-26T21:57:07Z,MortimerGoro,mortimergoro@gmail.com https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-04-26T23:32:19Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-04-27T13:01:14Z,shardings,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-04-27T13:02:53Z,shardings,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-04-29T11:43:33Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-04-30T22:56:07Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-05-12T15:01:13Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-06-04T04:23:22Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-06-08T18:36:44Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HEART,2017-06-08T20:40:15Z,binary132,NA https://github.com/rust-lang/rust/pull/41469,MERGED,2017-04-22T18:04:28Z,2017-04-22T22:25:56Z,Performance audit Spring 2017,arielb1,a660ad84b3c27de5c0abfb683fb178ba4e4ca87e,1,bail out of selection when there are multiple surviving candidates In some cases (e.g. <[int-var] as Add<[int-var]>>) selection can turn up a large number of candidates. Bailing out early avoids O(n^2) performance. This improves item-type checking time by quite a bit resulting in ~2% of total time-to-typeck.,HOORAY,2017-06-29T10:30:10Z,kirugan,NA https://github.com/rust-lang/rust/pull/41476,MERGED,2017-04-23T06:25:38Z,2017-05-17T06:49:10Z,Document the `proc_macro` feature in the Unstable Book,abonander,e616d12cbbe2b38ab3d683233e716104ca56d388,1,Document the `proc_macro` feature in the Unstable Book,THUMBS_UP,2017-04-23T06:52:04Z,jseyfried,NA https://github.com/rust-lang/rust/pull/41485,MERGED,2017-04-23T19:28:05Z,2017-04-23T22:47:37Z,cache dtorck constraints on ADTs,arielb1,d3476f4b7694b8453cf52268880057a9df938089,8,cache ADT dtorck results This avoids visiting the fields of all structs multiple times improving item-bodies checking time by 10% (!).,HEART,2017-04-23T20:08:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/41488,MERGED,2017-04-23T22:39:41Z,2017-05-02T12:11:56Z,Clean up callable type mismatch errors,estebank,b10e2933d939a8412b1358c235f39cb87ae1a450,8,Move `cfail` tests to `ui`,HEART,2017-04-24T04:17:54Z,durka,NA https://github.com/rust-lang/rust/pull/41488,MERGED,2017-04-23T22:39:41Z,2017-05-02T12:11:56Z,Clean up callable type mismatch errors,estebank,b10e2933d939a8412b1358c235f39cb87ae1a450,8,Move `cfail` tests to `ui`,HEART,2017-04-24T08:03:06Z,killercup,NA https://github.com/rust-lang/rust/pull/41488,MERGED,2017-04-23T22:39:41Z,2017-05-02T12:11:56Z,Clean up callable type mismatch errors,estebank,b10e2933d939a8412b1358c235f39cb87ae1a450,8,Move `cfail` tests to `ui`,HEART,2017-04-24T14:10:45Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41488,MERGED,2017-04-23T22:39:41Z,2017-05-02T12:11:56Z,Clean up callable type mismatch errors,estebank,b10e2933d939a8412b1358c235f39cb87ae1a450,8,Move `cfail` tests to `ui`,HEART,2017-04-24T20:47:47Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41488,MERGED,2017-04-23T22:39:41Z,2017-05-02T12:11:56Z,Clean up callable type mismatch errors,estebank,b10e2933d939a8412b1358c235f39cb87ae1a450,8,Move `cfail` tests to `ui`,HEART,2017-05-01T10:05:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/41493,MERGED,2017-04-24T04:51:07Z,2017-04-27T02:48:22Z,Step::replace_one should put a one not a zero (Issue #41492),scottmcm,f8c6436173f9ccbe79eaf021161f26b601eef026,3,Step::replace_one should put a one not a zero (Issue #41492) Turns out all six of these impls are incorrect.,LAUGH,2017-04-25T23:38:22Z,kennytm,NA https://github.com/rust-lang/rust/pull/41493,MERGED,2017-04-24T04:51:07Z,2017-04-27T02:48:22Z,Step::replace_one should put a one not a zero (Issue #41492),scottmcm,f8c6436173f9ccbe79eaf021161f26b601eef026,3,Step::replace_one should put a one not a zero (Issue #41492) Turns out all six of these impls are incorrect.,LAUGH,2017-05-03T20:35:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/41505,MERGED,2017-04-24T15:46:57Z,2017-04-24T21:43:49Z,[stable] Prepare the 1.17.0 release,alexcrichton,980cf05cdf1d21c9b68e0eb1bd20af58f6a0518a,2,Prepare the 1.17.0 release * Update channel we're building * Update the cargo submodule to the tip of the `rust-1.17.0` branch,HOORAY,2017-04-24T18:48:47Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/41505,MERGED,2017-04-24T15:46:57Z,2017-04-24T21:43:49Z,[stable] Prepare the 1.17.0 release,alexcrichton,980cf05cdf1d21c9b68e0eb1bd20af58f6a0518a,2,Prepare the 1.17.0 release * Update channel we're building * Update the cargo submodule to the tip of the `rust-1.17.0` branch,HOORAY,2017-04-24T19:33:54Z,Cldfire,NA https://github.com/rust-lang/rust/pull/41523,MERGED,2017-04-25T03:33:27Z,2017-04-28T03:18:21Z,Point at variable moved by closure,estebank,1ca1483113936b0f23b612f82bb84881435c483b,7,Point at variable moved by closure,HEART,2017-04-25T11:31:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/41523,MERGED,2017-04-25T03:33:27Z,2017-04-28T03:18:21Z,Point at variable moved by closure,estebank,1ca1483113936b0f23b612f82bb84881435c483b,7,Point at variable moved by closure,HEART,2017-04-27T11:08:12Z,arielb1,NA https://github.com/rust-lang/rust/pull/41523,MERGED,2017-04-25T03:33:27Z,2017-04-28T03:18:21Z,Point at variable moved by closure,estebank,1ca1483113936b0f23b612f82bb84881435c483b,7,Point at variable moved by closure,HEART,2017-04-27T17:46:47Z,durka,NA https://github.com/rust-lang/rust/pull/41523,MERGED,2017-04-25T03:33:27Z,2017-04-28T03:18:21Z,Point at variable moved by closure,estebank,1ca1483113936b0f23b612f82bb84881435c483b,7,Point at variable moved by closure,HEART,2017-04-29T12:37:16Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/41523,MERGED,2017-04-25T03:33:27Z,2017-04-28T03:18:21Z,Point at variable moved by closure,estebank,1ca1483113936b0f23b612f82bb84881435c483b,7,Point at variable moved by closure,HEART,2017-05-06T10:41:44Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/41524,MERGED,2017-04-25T05:10:17Z,2017-04-27T02:48:24Z,Add Hexagon support,michaelwu,22eb3c69b913091b8e363803dab973a2a8230736,2,Enable building the LLVM Hexagon target,HOORAY,2017-04-25T09:30:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,HOORAY,2017-04-25T23:46:55Z,sfackler,NA https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,HOORAY,2017-04-26T02:14:20Z,est31,NA https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,HOORAY,2017-04-26T07:08:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,HEART,2017-04-26T08:09:59Z,mzji,NA https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,THUMBS_UP,2017-04-26T08:10:22Z,mzji,NA https://github.com/rust-lang/rust/pull/41546,CLOSED,2017-04-25T23:45:09Z,2017-04-28T16:04:59Z,Shrink the rust-src component,cuviper,NA,NA,NA,HOORAY,2017-04-26T19:02:07Z,hban,NA https://github.com/rust-lang/rust/pull/41547,MERGED,2017-04-26T00:19:37Z,2017-05-02T14:56:17Z,Fix error message for mismatched types,alexeyzab,c741bc80320e18093a328fd36955a2d1bfae689b,2,Fix error message label,THUMBS_UP,2017-04-26T00:21:27Z,estebank,NA https://github.com/rust-lang/rust/pull/41548,MERGED,2017-04-26T01:04:41Z,2017-05-10T02:32:17Z,Update release notes for 1.17,brson,8e97693b2cbcaeb745643ee1b37058e8dde2efa1,1,Update release notes for 1.17,THUMBS_UP,2017-04-26T01:28:38Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/41548,MERGED,2017-04-26T01:04:41Z,2017-05-10T02:32:17Z,Update release notes for 1.17,brson,8e97693b2cbcaeb745643ee1b37058e8dde2efa1,1,Update release notes for 1.17,HEART,2017-04-26T10:53:20Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/41556,MERGED,2017-04-26T14:17:24Z,2017-04-28T03:18:23Z,LLVM: Update submodule to fix incorrect codegen on MSP430.,pftbest,ec5588b4bc4e90016ac3539f28102460f6f5fc5c,2,Update LLVM to fix incorrect codegen on MSP430. The bug was reported by @akovaski here: https://github.com/rust-embedded/rfcs/issues/20#issuecomment-296482148,THUMBS_UP,2017-04-29T15:52:55Z,akovaski,NA https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-04-26T21:27:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-04-26T23:19:35Z,Diggsey,NA https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-04-26T23:22:53Z,est31,NA https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-04-27T00:36:22Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HEART,2017-05-03T12:24:55Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-05-03T16:54:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/41563,MERGED,2017-04-26T20:40:13Z,2017-04-27T00:04:17Z,Make sure openssl compiles with only one core,aidanhs,367e90775beb90e3795209dab29b428b639521cf,1,Make sure openssl compiles with only one core Fixes #40417,HOORAY,2017-05-03T20:32:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/41565,MERGED,2017-04-26T21:35:54Z,2017-05-16T08:14:38Z,Make only rustc_trans depend on rustc_llvm,hanna-kruppe,04a16ff5acaaccf6332f706f090442f0ab9b0f95,1,Fix run-make/llvm-pass,THUMBS_UP,2017-05-02T11:18:49Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/41565,MERGED,2017-04-26T21:35:54Z,2017-05-16T08:14:38Z,Make only rustc_trans depend on rustc_llvm,hanna-kruppe,04a16ff5acaaccf6332f706f090442f0ab9b0f95,1,Fix run-make/llvm-pass,THUMBS_UP,2017-05-10T10:25:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/41575,MERGED,2017-04-27T06:00:34Z,2017-04-28T18:53:37Z,travis: Parallelize tests on Android,alexcrichton,7bc2cbf5db3e20e6f97494b70b2a1d65ac2e61fc,14,travis: Parallelize tests on Android Currently our slowest test suite on android run-pass takes over 5 times longer than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed add overhead but not 5x for this kind of workload. One of the slowest parts of the Android process is that *compilation* happens serially. Tests themselves need to run single-threaded on the emulator (due to how the test harness works) and this forces the compiles themselves to be single threaded. Now Travis gives us more than one core per machine so it'd be much better if we could take advantage of them! The emulator itself is still fundamentally single-threaded but we should see a nice speedup by sending binaries for it to run much more quickly. It turns out that we've already got all the tools to do this in-tree. The qemu-test-{server client} that are in use for the ARM Linux testing are a perfect match for the Android emulator. This commit migrates the custom adb management code in compiletest/rustbuild to the same qemu-test-{server client} implementation that ARM Linux uses. This allows us to lift the parallelism restriction on the compiletest test suites namely run-pass. Consequently although we'll still basically run the tests themselves in single threaded mode we'll be able to compile all of them in parallel keeping the pipeline much more full and using more cores for the work at hand. Additionally the architecture here should be a bit speedier as it should have less overhead than adb which is a whole new process on both the host and the emulator! Locally on an 8 core machine I've seen the run-pass test suite speed up from taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a drastic speedup on Travis but I'm hoping this change can place the Android tests well below 2 hours instead of just above 2 hours. Because the client/server here are now repurposed for more than just QEMU they've been renamed to `remote-test-{server client}`. Note that this PR does not currently modify how debuginfo tests are executed on Android. While parallelizable it wouldn't be quite as easy so that's left to another day. Thankfully that test suite is much smaller than the run-pass test suite. As a final fix I discovered that the ARM and Android test suites were actually running all library unit tests (e.g. stdtest coretest etc) twice. I've corrected that to only run tests once which should also give a nice boost in overall cycle time here.,HOORAY,2017-04-27T12:32:39Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41575,MERGED,2017-04-27T06:00:34Z,2017-04-28T18:53:37Z,travis: Parallelize tests on Android,alexcrichton,7bc2cbf5db3e20e6f97494b70b2a1d65ac2e61fc,14,travis: Parallelize tests on Android Currently our slowest test suite on android run-pass takes over 5 times longer than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed add overhead but not 5x for this kind of workload. One of the slowest parts of the Android process is that *compilation* happens serially. Tests themselves need to run single-threaded on the emulator (due to how the test harness works) and this forces the compiles themselves to be single threaded. Now Travis gives us more than one core per machine so it'd be much better if we could take advantage of them! The emulator itself is still fundamentally single-threaded but we should see a nice speedup by sending binaries for it to run much more quickly. It turns out that we've already got all the tools to do this in-tree. The qemu-test-{server client} that are in use for the ARM Linux testing are a perfect match for the Android emulator. This commit migrates the custom adb management code in compiletest/rustbuild to the same qemu-test-{server client} implementation that ARM Linux uses. This allows us to lift the parallelism restriction on the compiletest test suites namely run-pass. Consequently although we'll still basically run the tests themselves in single threaded mode we'll be able to compile all of them in parallel keeping the pipeline much more full and using more cores for the work at hand. Additionally the architecture here should be a bit speedier as it should have less overhead than adb which is a whole new process on both the host and the emulator! Locally on an 8 core machine I've seen the run-pass test suite speed up from taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a drastic speedup on Travis but I'm hoping this change can place the Android tests well below 2 hours instead of just above 2 hours. Because the client/server here are now repurposed for more than just QEMU they've been renamed to `remote-test-{server client}`. Note that this PR does not currently modify how debuginfo tests are executed on Android. While parallelizable it wouldn't be quite as easy so that's left to another day. Thankfully that test suite is much smaller than the run-pass test suite. As a final fix I discovered that the ARM and Android test suites were actually running all library unit tests (e.g. stdtest coretest etc) twice. I've corrected that to only run tests once which should also give a nice boost in overall cycle time here.,HOORAY,2017-04-27T14:31:12Z,malbarbo,NA https://github.com/rust-lang/rust/pull/41575,MERGED,2017-04-27T06:00:34Z,2017-04-28T18:53:37Z,travis: Parallelize tests on Android,alexcrichton,7bc2cbf5db3e20e6f97494b70b2a1d65ac2e61fc,14,travis: Parallelize tests on Android Currently our slowest test suite on android run-pass takes over 5 times longer than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed add overhead but not 5x for this kind of workload. One of the slowest parts of the Android process is that *compilation* happens serially. Tests themselves need to run single-threaded on the emulator (due to how the test harness works) and this forces the compiles themselves to be single threaded. Now Travis gives us more than one core per machine so it'd be much better if we could take advantage of them! The emulator itself is still fundamentally single-threaded but we should see a nice speedup by sending binaries for it to run much more quickly. It turns out that we've already got all the tools to do this in-tree. The qemu-test-{server client} that are in use for the ARM Linux testing are a perfect match for the Android emulator. This commit migrates the custom adb management code in compiletest/rustbuild to the same qemu-test-{server client} implementation that ARM Linux uses. This allows us to lift the parallelism restriction on the compiletest test suites namely run-pass. Consequently although we'll still basically run the tests themselves in single threaded mode we'll be able to compile all of them in parallel keeping the pipeline much more full and using more cores for the work at hand. Additionally the architecture here should be a bit speedier as it should have less overhead than adb which is a whole new process on both the host and the emulator! Locally on an 8 core machine I've seen the run-pass test suite speed up from taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a drastic speedup on Travis but I'm hoping this change can place the Android tests well below 2 hours instead of just above 2 hours. Because the client/server here are now repurposed for more than just QEMU they've been renamed to `remote-test-{server client}`. Note that this PR does not currently modify how debuginfo tests are executed on Android. While parallelizable it wouldn't be quite as easy so that's left to another day. Thankfully that test suite is much smaller than the run-pass test suite. As a final fix I discovered that the ARM and Android test suites were actually running all library unit tests (e.g. stdtest coretest etc) twice. I've corrected that to only run tests once which should also give a nice boost in overall cycle time here.,HOORAY,2017-04-27T22:30:17Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/41582,MERGED,2017-04-27T17:03:44Z,2017-05-06T01:46:43Z,Reload nameserver information on lookup failure,jonhoo,68ae6173fea7411a5d9e5bde6624f5606caf8fe8,4,Reload nameserver information on lookup failure As discussed in #41570 UNIX systems often cache the contents of /etc/resolv.conf which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd this should not be necessary but not all systems run nscd. Introduces an std linkage dependency on libresolv on macOS/iOS (which also makes it necessary to update run-make/tools.mk). Fixes #41570. Depends on rust-lang/libc#585.,THUMBS_UP,2017-05-03T17:01:24Z,achanda,NA https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2017-05-10T17:35:55Z,StefanoD,NA https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2017-05-10T18:18:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2017-06-11T08:27:05Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2017-06-14T15:48:05Z,tikue,NA https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2017-06-17T05:55:01Z,tioover,tioover@gmail.com https://github.com/rust-lang/rust/pull/41624,MERGED,2017-04-29T07:49:41Z,2017-05-03T03:24:43Z,MutexGuard may be Sync only if T is Sync,RalfJung,23522f6cabf9fc5803411c3dec4a90c56cc3dab2,1,need to pick a new feature name,HOORAY,2021-08-17T05:23:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/41637,MERGED,2017-04-29T20:18:58Z,2017-04-30T07:46:59Z,Don't ever warn about #[used] items being dead code.,eddyb,c054b2a761404e0057d678f4c04445505e287309,2,Don't ever warn about #[used] items being dead code.,HEART,2017-04-29T22:20:25Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/41637,MERGED,2017-04-29T20:18:58Z,2017-04-30T07:46:59Z,Don't ever warn about #[used] items being dead code.,eddyb,c054b2a761404e0057d678f4c04445505e287309,2,Don't ever warn about #[used] items being dead code.,HEART,2017-05-03T20:41:28Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/41661,MERGED,2017-04-30T20:17:19Z,2017-05-02T17:48:35Z,Under MinGW x.py fails to run with UnboundLocalError.,barik,04e4d426a169a26d498bf22d2c2d01bc7b14fbcd,2,Rename os variable in bootstrap.py to avoid shadowing os module.,LAUGH,2017-04-30T20:26:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41661,MERGED,2017-04-30T20:17:19Z,2017-05-02T17:48:35Z,Under MinGW x.py fails to run with UnboundLocalError.,barik,04e4d426a169a26d498bf22d2c2d01bc7b14fbcd,2,Rename os variable in bootstrap.py to avoid shadowing os module.,LAUGH,2017-05-02T12:24:55Z,kennytm,NA https://github.com/rust-lang/rust/pull/41670,MERGED,2017-05-01T08:25:15Z,2017-06-02T10:17:39Z,Add an in-place rotate method for slices to libcore,scottmcm,094d61f079e5f06930e002da18f92dde5827154f,4,Stop returning k from [T]::rotate,THUMBS_UP,2017-05-01T08:51:26Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/41670,MERGED,2017-05-01T08:25:15Z,2017-06-02T10:17:39Z,Add an in-place rotate method for slices to libcore,scottmcm,094d61f079e5f06930e002da18f92dde5827154f,4,Stop returning k from [T]::rotate,THUMBS_UP,2017-12-16T08:56:46Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/41670,MERGED,2017-05-01T08:25:15Z,2017-06-02T10:17:39Z,Add an in-place rotate method for slices to libcore,scottmcm,094d61f079e5f06930e002da18f92dde5827154f,4,Stop returning k from [T]::rotate,HEART,2019-08-21T17:34:42Z,bluss,NA https://github.com/rust-lang/rust/pull/41676,MERGED,2017-05-01T17:50:46Z,2017-05-07T05:23:32Z,Increase macro recursion limit to 1024,sirideain,3008f53c95aeb4d5d6e4d9258a427e1372be63c7,1,Increase macro recursion limit to 1024 Fixes #22552,HOORAY,2017-05-03T23:14:48Z,durka,NA https://github.com/rust-lang/rust/pull/41692,MERGED,2017-05-02T03:23:28Z,2017-05-02T17:48:38Z,Add a lint to disallow anonymous parameters,est31,6cc765dcad14e305f892398d16e270b480eb435b,3,Add a lint to disallow anonymous parameters,HOORAY,2017-05-02T04:51:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/41693,MERGED,2017-05-02T03:57:41Z,2017-05-02T17:48:38Z,Removal pass for anonymous parameters,est31,14bbd0a5a3722bdcb4c5f36d81097e1fb992add3,2,Address review,HEART,2017-05-02T04:49:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/41693,MERGED,2017-05-02T03:57:41Z,2017-05-02T17:48:38Z,Removal pass for anonymous parameters,est31,14bbd0a5a3722bdcb4c5f36d81097e1fb992add3,2,Address review,HEART,2017-05-02T14:43:46Z,malbarbo,NA https://github.com/rust-lang/rust/pull/41722,MERGED,2017-05-03T08:29:02Z,2017-05-06T01:46:46Z,Suggest `!` for bitwise negation when encountering a `~`,F001,a9d3b3498e20a926d5b1662eb576d7db230ca110,3,Suggest `!` for bitwise negation when encountering a `~`,HEART,2017-05-03T21:48:32Z,estebank,NA https://github.com/rust-lang/rust/pull/41722,MERGED,2017-05-03T08:29:02Z,2017-05-06T01:46:46Z,Suggest `!` for bitwise negation when encountering a `~`,F001,a9d3b3498e20a926d5b1662eb576d7db230ca110,3,Suggest `!` for bitwise negation when encountering a `~`,HEART,2017-05-10T09:02:10Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/41722,MERGED,2017-05-03T08:29:02Z,2017-05-06T01:46:46Z,Suggest `!` for bitwise negation when encountering a `~`,F001,a9d3b3498e20a926d5b1662eb576d7db230ca110,3,Suggest `!` for bitwise negation when encountering a `~`,HEART,2017-05-10T12:46:08Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/41722,MERGED,2017-05-03T08:29:02Z,2017-05-06T01:46:46Z,Suggest `!` for bitwise negation when encountering a `~`,F001,a9d3b3498e20a926d5b1662eb576d7db230ca110,3,Suggest `!` for bitwise negation when encountering a `~`,HEART,2017-05-10T18:47:15Z,BonsaiDen,ivo.wetzel@googlemail.com https://github.com/rust-lang/rust/pull/41729,MERGED,2017-05-03T17:57:55Z,2017-05-08T01:21:40Z,Delete features which are easily removed in libsyntax,strega-nil,0be875827fe64412f6c0eedc8f775f57137e7c55,6,fix the easy features in libsyntax,THUMBS_UP,2017-05-04T05:38:05Z,kennytm,NA https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-05-03T23:25:29Z,estebank,NA https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-05-04T13:09:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-05-04T18:22:43Z,alexbool,NA https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-05-05T00:25:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-05-05T17:51:08Z,hban,NA https://github.com/rust-lang/rust/pull/41736,CLOSED,2017-05-03T23:18:39Z,2017-05-06T13:34:05Z,Implement named threads on Windows,jsheard,NA,NA,NA,HEART,2017-10-07T00:08:00Z,Boscop,NA https://github.com/rust-lang/rust/pull/41745,MERGED,2017-05-04T12:19:54Z,2017-05-08T14:45:16Z,"Remove need for &format!(...) or &&"""" dances in `span_label` calls",oli-obk,dd87eabd83296baa4c2214d2cf3aeef24f753ba7,56,"Remove need for &format!(...) or &&"""" dances in `span_label` calls",THUMBS_UP,2017-05-04T12:44:45Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/41745,MERGED,2017-05-04T12:19:54Z,2017-05-08T14:45:16Z,"Remove need for &format!(...) or &&"""" dances in `span_label` calls",oli-obk,dd87eabd83296baa4c2214d2cf3aeef24f753ba7,56,"Remove need for &format!(...) or &&"""" dances in `span_label` calls",THUMBS_UP,2017-05-08T17:38:51Z,estebank,NA https://github.com/rust-lang/rust/pull/41751,MERGED,2017-05-04T16:38:45Z,2017-05-05T03:56:42Z,rustc: Forbid `-Z` flags on stable/beta channels,alexcrichton,ccbcc720a679ae76155a8ef4779a080a954a5957,1,rustc: Forbid `-Z` flags on stable/beta channels First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make their way to the stable channel (or unstable options). After a year of warnings we've seen one of the main use cases `-Z no-trans` stabilized as `cargo check`. Otherwise while other use cases remain the sentiment is that now's the time to start forbidding `-Z` by default on stable/beta. Closes #31847,THUMBS_DOWN,2017-05-04T17:18:19Z,durka,NA https://github.com/rust-lang/rust/pull/41751,MERGED,2017-05-04T16:38:45Z,2017-05-05T03:56:42Z,rustc: Forbid `-Z` flags on stable/beta channels,alexcrichton,ccbcc720a679ae76155a8ef4779a080a954a5957,1,rustc: Forbid `-Z` flags on stable/beta channels First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make their way to the stable channel (or unstable options). After a year of warnings we've seen one of the main use cases `-Z no-trans` stabilized as `cargo check`. Otherwise while other use cases remain the sentiment is that now's the time to start forbidding `-Z` by default on stable/beta. Closes #31847,THUMBS_DOWN,2017-05-10T17:57:09Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/41751,MERGED,2017-05-04T16:38:45Z,2017-05-05T03:56:42Z,rustc: Forbid `-Z` flags on stable/beta channels,alexcrichton,ccbcc720a679ae76155a8ef4779a080a954a5957,1,rustc: Forbid `-Z` flags on stable/beta channels First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make their way to the stable channel (or unstable options). After a year of warnings we've seen one of the main use cases `-Z no-trans` stabilized as `cargo check`. Otherwise while other use cases remain the sentiment is that now's the time to start forbidding `-Z` by default on stable/beta. Closes #31847,THUMBS_DOWN,2017-05-10T20:28:46Z,jethrogb,NA https://github.com/rust-lang/rust/pull/41751,MERGED,2017-05-04T16:38:45Z,2017-05-05T03:56:42Z,rustc: Forbid `-Z` flags on stable/beta channels,alexcrichton,ccbcc720a679ae76155a8ef4779a080a954a5957,1,rustc: Forbid `-Z` flags on stable/beta channels First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make their way to the stable channel (or unstable options). After a year of warnings we've seen one of the main use cases `-Z no-trans` stabilized as `cargo check`. Otherwise while other use cases remain the sentiment is that now's the time to start forbidding `-Z` by default on stable/beta. Closes #31847,THUMBS_DOWN,2017-07-20T17:14:56Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/41751,MERGED,2017-05-04T16:38:45Z,2017-05-05T03:56:42Z,rustc: Forbid `-Z` flags on stable/beta channels,alexcrichton,ccbcc720a679ae76155a8ef4779a080a954a5957,1,rustc: Forbid `-Z` flags on stable/beta channels First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make their way to the stable channel (or unstable options). After a year of warnings we've seen one of the main use cases `-Z no-trans` stabilized as `cargo check`. Otherwise while other use cases remain the sentiment is that now's the time to start forbidding `-Z` by default on stable/beta. Closes #31847,THUMBS_DOWN,2020-10-25T11:55:20Z,l29ah,zl29ah@gmail.com https://github.com/rust-lang/rust/pull/41754,MERGED,2017-05-04T17:25:57Z,2017-05-05T06:25:41Z,kill some unused fields in TyCtxt,nikomatsakis,0f6d4ac88dfd2ea086a49e9991a67b36902de7c0,1,kill some unused fields in TyCtxt,HOORAY,2017-05-04T17:30:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2017-05-05T21:40:19Z,cramertj,NA https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2017-05-09T23:33:57Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2017-05-17T11:50:28Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2017-05-17T19:46:34Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2017-05-17T23:49:29Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2018-10-12T14:12:39Z,hcpl,NA https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2018-12-05T02:19:15Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/41764,MERGED,2017-05-05T03:45:17Z,2017-05-10T11:37:30Z,Make [u8]::reverse() 5x faster,scottmcm,da91361d2a8ea86a42cbe2a23a7ff816cc5500af,2,Add reverse benchmarks for u128 [u8;3] and Simd<[f64;4]> None of these are affected by e8fad325fe.,THUMBS_UP,2018-12-05T02:33:27Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/41765,MERGED,2017-05-05T07:09:27Z,2017-05-05T20:44:23Z,Update rust-installer to fix rust-lang-nursery/rustup.rs#1092,brson,f59931dc176aafcf6f05dff27f7015c0a61d73d4,1,Update rust-installer to fix rust-lang-nursery/rustup.rs#1092,THUMBS_UP,2017-05-05T07:17:31Z,ranma42,NA https://github.com/rust-lang/rust/pull/41769,MERGED,2017-05-05T14:04:32Z,2017-05-05T23:20:41Z,std: Prevent deadlocks in doctests on Windows,alexcrichton,94e4b459efa3e75c190aeb50da88a02661b3d214,1,std: Prevent deadlocks in doctests on Windows Windows historically has problems with threads panicking and the main thread exiting at the same time typically causing deadlocks. In the past (#25824) we've joined on threads but this just prevents running the test for now to avoid tampering with the example.,LAUGH,2017-05-05T14:49:58Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/41769,MERGED,2017-05-05T14:04:32Z,2017-05-05T23:20:41Z,std: Prevent deadlocks in doctests on Windows,alexcrichton,94e4b459efa3e75c190aeb50da88a02661b3d214,1,std: Prevent deadlocks in doctests on Windows Windows historically has problems with threads panicking and the main thread exiting at the same time typically causing deadlocks. In the past (#25824) we've joined on threads but this just prevents running the test for now to avoid tampering with the example.,LAUGH,2017-05-05T17:46:48Z,skade,florian.gilcher@ferrous-systems.com https://github.com/rust-lang/rust/pull/41769,MERGED,2017-05-05T14:04:32Z,2017-05-05T23:20:41Z,std: Prevent deadlocks in doctests on Windows,alexcrichton,94e4b459efa3e75c190aeb50da88a02661b3d214,1,std: Prevent deadlocks in doctests on Windows Windows historically has problems with threads panicking and the main thread exiting at the same time typically causing deadlocks. In the past (#25824) we've joined on threads but this just prevents running the test for now to avoid tampering with the example.,LAUGH,2017-05-06T19:39:40Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/41787,MERGED,2017-05-06T14:49:30Z,2017-05-07T00:40:53Z,Fix definitions of ULONG_PTR,jsheard,db8be04e49f32d36270e87b71b74c4b71764647e,3,Fix definitions of ULONG_PTR,THUMBS_UP,2017-05-06T19:52:08Z,retep998,NA https://github.com/rust-lang/rust/pull/41787,MERGED,2017-05-06T14:49:30Z,2017-05-07T00:40:53Z,Fix definitions of ULONG_PTR,jsheard,db8be04e49f32d36270e87b71b74c4b71764647e,3,Fix definitions of ULONG_PTR,THUMBS_UP,2017-05-10T07:52:45Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/41787,MERGED,2017-05-06T14:49:30Z,2017-05-07T00:40:53Z,Fix definitions of ULONG_PTR,jsheard,db8be04e49f32d36270e87b71b74c4b71764647e,3,Fix definitions of ULONG_PTR,THUMBS_UP,2017-05-10T10:30:45Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/41809,MERGED,2017-05-07T14:06:42Z,2017-05-10T20:02:15Z,[DOC] Improve the thread::park and thread::unpark documentation,gamazeps,afe74c3900aa00373a0d5edd2bd433870822c40a,1,Fix link,THUMBS_UP,2017-05-07T17:03:00Z,kennytm,NA https://github.com/rust-lang/rust/pull/41818,MERGED,2017-05-07T19:41:24Z,2017-05-08T07:47:16Z,Add support for Hexagon v60 HVX intrinsics,michaelwu,cc4efd1370e2be49abfda9cf90db4523f1043805,4,Add support for Hexagon v60 HVX intrinsics,HEART,2017-05-07T19:54:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41840,MERGED,2017-05-08T21:54:54Z,2017-06-16T12:18:47Z,Suppress trait errors that are implied by other errors,arielb1,7b9519a5d47879c37f0ac6871cee2e1cb8eca1cc,23,"suppress trait errors that are implied by other errors Instead of suppressing only trait errors that are ""exact duplicates"" display only the ""most high-level"" error when there are multiple trait errors with the same span that imply each-other. e.g. when there are both `[closure]: Fn` and `[closure]: FnOnce` omit displaying the `[closure]: FnOnce` bound.",THUMBS_UP,2017-05-08T22:07:26Z,estebank,NA https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HEART,2017-05-09T03:40:24Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HOORAY,2017-05-09T03:40:26Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HOORAY,2017-05-09T12:11:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HEART,2017-05-09T12:14:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HOORAY,2017-05-09T12:15:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HOORAY,2017-05-10T14:14:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/41847,MERGED,2017-05-09T03:38:27Z,2017-05-13T07:47:19Z,rustc: Add a new `-Z force-unstable-if-unmarked` flag,alexcrichton,ab54f4b226639558ff46ea1f3e3f504aacef562d,34,rustc: Remove #![unstable] annotation These are now no longer necessary with `-Z force-unstable-if-unmarked`,HOORAY,2017-05-13T05:42:17Z,est31,NA https://github.com/rust-lang/rust/pull/41889,MERGED,2017-05-10T16:27:32Z,2017-05-11T09:39:48Z,Remove debug message,est31,a06f9a66dff42965a47e9c8d99b059707347b998,1,Remove debug message,LAUGH,2017-05-10T18:38:14Z,oli-obk,NA https://github.com/rust-lang/rust/pull/41889,MERGED,2017-05-10T16:27:32Z,2017-05-11T09:39:48Z,Remove debug message,est31,a06f9a66dff42965a47e9c8d99b059707347b998,1,Remove debug message,LAUGH,2017-05-14T13:08:20Z,dbrgn,NA https://github.com/rust-lang/rust/pull/41889,MERGED,2017-05-10T16:27:32Z,2017-05-11T09:39:48Z,Remove debug message,est31,a06f9a66dff42965a47e9c8d99b059707347b998,1,Remove debug message,LAUGH,2017-05-17T23:16:49Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/41904,MERGED,2017-05-11T04:19:20Z,2017-05-22T00:51:25Z,Stabilize library features for 1.18.0,sfackler,7c2cd93b2bf3c84b97ea798617105a6f85529d23,12,Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648,HEART,2017-05-11T04:21:02Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/41904,MERGED,2017-05-11T04:19:20Z,2017-05-22T00:51:25Z,Stabilize library features for 1.18.0,sfackler,7c2cd93b2bf3c84b97ea798617105a6f85529d23,12,Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648,HEART,2017-05-11T05:15:05Z,est31,NA https://github.com/rust-lang/rust/pull/41904,MERGED,2017-05-11T04:19:20Z,2017-05-22T00:51:25Z,Stabilize library features for 1.18.0,sfackler,7c2cd93b2bf3c84b97ea798617105a6f85529d23,12,Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648,HEART,2017-05-11T06:36:30Z,kennytm,NA https://github.com/rust-lang/rust/pull/41904,MERGED,2017-05-11T04:19:20Z,2017-05-22T00:51:25Z,Stabilize library features for 1.18.0,sfackler,7c2cd93b2bf3c84b97ea798617105a6f85529d23,12,Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648,HEART,2017-05-11T07:59:16Z,arthurprs,NA https://github.com/rust-lang/rust/pull/41904,MERGED,2017-05-11T04:19:20Z,2017-05-22T00:51:25Z,Stabilize library features for 1.18.0,sfackler,7c2cd93b2bf3c84b97ea798617105a6f85529d23,12,Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648,HEART,2017-05-11T08:30:19Z,killercup,NA https://github.com/rust-lang/rust/pull/41907,MERGED,2017-05-11T09:00:51Z,2017-05-17T01:57:54Z,Add lint for unused macros,est31,6dbd706906d922ae5606eb5654dd804095ffc8c8,1,put option_try macro def under #[cfg(unix)],THUMBS_UP,2017-05-21T15:32:45Z,mcarton,NA https://github.com/rust-lang/rust/pull/41934,MERGED,2017-05-12T06:39:42Z,2017-05-13T13:59:31Z,Remove unused macros from the codebase,est31,80891f6e4725efc72c27e4f224123ec292fdd7d4,9,Remove some unused macros from the rust codebase Removes unused macros from: * libcore * libcollections The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff when the char_range_at_reverse function was been removed. * librustc_errors Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979 and 11dc974a38fd533aa692cea213305056cd3a6902. * libsyntax_ext * librustc_trans Also put the otry macro in back/msvc/mod.rs under the same cfg argument as the places that use it.,HEART,2017-05-12T09:42:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41934,MERGED,2017-05-12T06:39:42Z,2017-05-13T13:59:31Z,Remove unused macros from the codebase,est31,80891f6e4725efc72c27e4f224123ec292fdd7d4,9,Remove some unused macros from the rust codebase Removes unused macros from: * libcore * libcollections The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff when the char_range_at_reverse function was been removed. * librustc_errors Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979 and 11dc974a38fd533aa692cea213305056cd3a6902. * libsyntax_ext * librustc_trans Also put the otry macro in back/msvc/mod.rs under the same cfg argument as the places that use it.,HEART,2017-05-12T12:54:03Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/41934,MERGED,2017-05-12T06:39:42Z,2017-05-13T13:59:31Z,Remove unused macros from the codebase,est31,80891f6e4725efc72c27e4f224123ec292fdd7d4,9,Remove some unused macros from the rust codebase Removes unused macros from: * libcore * libcollections The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff when the char_range_at_reverse function was been removed. * librustc_errors Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979 and 11dc974a38fd533aa692cea213305056cd3a6902. * libsyntax_ext * librustc_trans Also put the otry macro in back/msvc/mod.rs under the same cfg argument as the places that use it.,THUMBS_UP,2017-05-17T16:12:22Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/41934,MERGED,2017-05-12T06:39:42Z,2017-05-13T13:59:31Z,Remove unused macros from the codebase,est31,80891f6e4725efc72c27e4f224123ec292fdd7d4,9,Remove some unused macros from the rust codebase Removes unused macros from: * libcore * libcollections The last use of these two macros was removed in commit b64c9d56700e2c41207166fe8709711ff02488ff when the char_range_at_reverse function was been removed. * librustc_errors Their last use was removed by commits 2f2c3e178325dc1837badcd7573c2c0905fab979 and 11dc974a38fd533aa692cea213305056cd3a6902. * libsyntax_ext * librustc_trans Also put the otry macro in back/msvc/mod.rs under the same cfg argument as the places that use it.,HEART,2017-05-18T01:00:15Z,tikue,NA https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HEART,2017-05-12T17:29:38Z,brson,NA https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HOORAY,2017-05-13T14:05:33Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HOORAY,2017-05-13T21:32:53Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HOORAY,2017-05-14T13:28:16Z,arthurprs,NA https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HOORAY,2017-05-30T17:28:19Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/41953,MERGED,2017-05-12T14:40:36Z,2017-06-03T06:13:08Z,Updated releases notes for 1.18,XAMPPRocky,02c0d3ce3ddf89b7ec16519b44493d77a4d7ba5d,1,Updated releases notes for 1.18,HOORAY,2017-06-03T12:04:03Z,XAMPPRocky,NA https://github.com/rust-lang/rust/pull/41957,MERGED,2017-05-12T18:14:43Z,2017-05-17T04:21:13Z,Fix some clippy warnings in libsyntax,llogiq,282b40249e158376fcc4682879be40fb80c4e36f,1,(hopefully) fix pprust error,HEART,2017-05-12T18:34:23Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41957,MERGED,2017-05-12T18:14:43Z,2017-05-17T04:21:13Z,Fix some clippy warnings in libsyntax,llogiq,282b40249e158376fcc4682879be40fb80c4e36f,1,(hopefully) fix pprust error,HEART,2017-05-15T17:01:48Z,mcarton,NA https://github.com/rust-lang/rust/pull/41957,MERGED,2017-05-12T18:14:43Z,2017-05-17T04:21:13Z,Fix some clippy warnings in libsyntax,llogiq,282b40249e158376fcc4682879be40fb80c4e36f,1,(hopefully) fix pprust error,HEART,2017-05-16T06:14:41Z,bombless,NA https://github.com/rust-lang/rust/pull/41971,MERGED,2017-05-13T14:02:47Z,2017-05-19T23:38:38Z,add -Z pre-link-arg{ s} to rustc,japaric,94d2c43300148d5c0ea8c93cedb94151953dcf83,2,add -Z pre-link-arg{ s} to rustc This commit adds two unstable flags to `rustc`: `-Z pre-link-arg` and `-Z pre-link-args`. These are the counterpart of the existing `-C link-arg{ s}` flags and can be used to pass extra arguments at the *beginning* of the linker invocation before the Rust object files are passed.,THUMBS_UP,2017-05-25T07:56:16Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/41973,CLOSED,2017-05-13T15:43:42Z,2017-05-13T16:56:59Z,Pass static crt to llvm cmake configuration,liranringel,NA,NA,NA,HEART,2017-05-13T15:44:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/41978,MERGED,2017-05-13T18:08:22Z,2017-05-14T18:38:40Z,Update the Cargo submodule,alexcrichton,d0a6af37e78b53f84cece2b4d6499536b8627748,1,Update the Cargo submodule Brings some nice updates like faster index clones/updates retries on 500 from crates.io etc.,THUMBS_UP,2017-05-14T00:43:15Z,svercl,NA https://github.com/rust-lang/rust/pull/42001,MERGED,2017-05-15T00:06:24Z,2017-05-16T23:27:55Z,"rustdoc: Display `extern ""C"" fn` instead of `extern fn`",ollie27,93f78bc45e4d4a68038f8d2cf34187d14cb5f918,5,"rustdoc: Display `extern ""C"" fn` instead of `extern fn`",THUMBS_UP,2017-05-15T03:43:21Z,retep998,NA https://github.com/rust-lang/rust/pull/42015,MERGED,2017-05-15T19:03:08Z,2017-05-23T09:55:48Z,remove interior mutability of type-flags,nikomatsakis,83641a9b6d2a622f5705ab76152cffb41d60fa3a,1,fix `atomic_lock_free` test case,HOORAY,2017-05-15T19:16:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42015,MERGED,2017-05-15T19:03:08Z,2017-05-23T09:55:48Z,remove interior mutability of type-flags,nikomatsakis,83641a9b6d2a622f5705ab76152cffb41d60fa3a,1,fix `atomic_lock_free` test case,HEART,2017-05-15T19:16:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42015,MERGED,2017-05-15T19:03:08Z,2017-05-23T09:55:48Z,remove interior mutability of type-flags,nikomatsakis,83641a9b6d2a622f5705ab76152cffb41d60fa3a,1,fix `atomic_lock_free` test case,HOORAY,2017-05-15T19:19:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42015,MERGED,2017-05-15T19:03:08Z,2017-05-23T09:55:48Z,remove interior mutability of type-flags,nikomatsakis,83641a9b6d2a622f5705ab76152cffb41d60fa3a,1,fix `atomic_lock_free` test case,HEART,2017-05-15T19:19:05Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42015,MERGED,2017-05-15T19:03:08Z,2017-05-23T09:55:48Z,remove interior mutability of type-flags,nikomatsakis,83641a9b6d2a622f5705ab76152cffb41d60fa3a,1,fix `atomic_lock_free` test case,HOORAY,2017-05-15T23:34:07Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42016,MERGED,2017-05-15T20:16:24Z,2017-05-23T07:14:48Z,Stabilize the loop_break_value feature,pietroalbini,93c1f2472bd627955e44970de075c2e90f246501,12,Stabilize the loop_break_value feature,HOORAY,2017-05-16T19:24:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42016,MERGED,2017-05-15T20:16:24Z,2017-05-23T07:14:48Z,Stabilize the loop_break_value feature,pietroalbini,93c1f2472bd627955e44970de075c2e90f246501,12,Stabilize the loop_break_value feature,HOORAY,2017-05-17T11:21:16Z,dhardy,github1@dhardy.name https://github.com/rust-lang/rust/pull/42016,MERGED,2017-05-15T20:16:24Z,2017-05-23T07:14:48Z,Stabilize the loop_break_value feature,pietroalbini,93c1f2472bd627955e44970de075c2e90f246501,12,Stabilize the loop_break_value feature,HOORAY,2017-05-31T00:05:32Z,KeenS,NA https://github.com/rust-lang/rust/pull/42016,MERGED,2017-05-15T20:16:24Z,2017-05-23T07:14:48Z,Stabilize the loop_break_value feature,pietroalbini,93c1f2472bd627955e44970de075c2e90f246501,12,Stabilize the loop_break_value feature,HOORAY,2017-05-31T02:06:45Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/42016,MERGED,2017-05-15T20:16:24Z,2017-05-23T07:14:48Z,Stabilize the loop_break_value feature,pietroalbini,93c1f2472bd627955e44970de075c2e90f246501,12,Stabilize the loop_break_value feature,HOORAY,2017-06-07T14:27:57Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42027,MERGED,2017-05-16T07:39:25Z,2017-06-09T06:26:51Z,Document direct implementations on type aliases.,mjkillough,2da350168df9dc51806fc72040a1022d45431879,3,Document direct implementations on type aliases. This improves #32077 but is not a complete fix. For a type alias `type NewType = AliasedType` it will include any `impl NewType` and `impl Trait for NewType` blocks in the documentation for `NewType`. A complete fix would include the implementations from the aliased type in the type alias' documentation so that users have a complete picture of methods that are available on the alias. However to do this properly would require a fix for #14072 as the alias may affect the type parameters of the type alias making the documentation difficult to understand. (That is for `type Result = std::result::Result<() ()>` we would ideally show documentation for `impl Result<() ()>` rather than generic documentation for `impl Result`). I think this improvement is worthwhile as it exposes implementations which are not currently documented by rustdoc. The documentation for the implementations on the aliased type are still accessible by clicking through to the docs for that type. (Although perhaps it's now less obvious to the user that they should click-through to get there).,HEART,2017-05-16T19:38:44Z,Ralith,NA https://github.com/rust-lang/rust/pull/42027,MERGED,2017-05-16T07:39:25Z,2017-06-09T06:26:51Z,Document direct implementations on type aliases.,mjkillough,2da350168df9dc51806fc72040a1022d45431879,3,Document direct implementations on type aliases. This improves #32077 but is not a complete fix. For a type alias `type NewType = AliasedType` it will include any `impl NewType` and `impl Trait for NewType` blocks in the documentation for `NewType`. A complete fix would include the implementations from the aliased type in the type alias' documentation so that users have a complete picture of methods that are available on the alias. However to do this properly would require a fix for #14072 as the alias may affect the type parameters of the type alias making the documentation difficult to understand. (That is for `type Result = std::result::Result<() ()>` we would ideally show documentation for `impl Result<() ()>` rather than generic documentation for `impl Result`). I think this improvement is worthwhile as it exposes implementations which are not currently documented by rustdoc. The documentation for the implementations on the aliased type are still accessible by clicking through to the docs for that type. (Although perhaps it's now less obvious to the user that they should click-through to get there).,HEART,2017-08-02T11:47:23Z,bluss,NA https://github.com/rust-lang/rust/pull/42027,MERGED,2017-05-16T07:39:25Z,2017-06-09T06:26:51Z,Document direct implementations on type aliases.,mjkillough,2da350168df9dc51806fc72040a1022d45431879,3,Document direct implementations on type aliases. This improves #32077 but is not a complete fix. For a type alias `type NewType = AliasedType` it will include any `impl NewType` and `impl Trait for NewType` blocks in the documentation for `NewType`. A complete fix would include the implementations from the aliased type in the type alias' documentation so that users have a complete picture of methods that are available on the alias. However to do this properly would require a fix for #14072 as the alias may affect the type parameters of the type alias making the documentation difficult to understand. (That is for `type Result = std::result::Result<() ()>` we would ideally show documentation for `impl Result<() ()>` rather than generic documentation for `impl Result`). I think this improvement is worthwhile as it exposes implementations which are not currently documented by rustdoc. The documentation for the implementations on the aliased type are still accessible by clicking through to the docs for that type. (Although perhaps it's now less obvious to the user that they should click-through to get there).,HEART,2020-03-03T22:33:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-16T14:16:12Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-16T16:36:45Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-17T19:24:09Z,kennytm,NA https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-19T05:53:32Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-24T09:55:53Z,stephanbuys,hello@stephanbuys.com https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HOORAY,2017-05-24T22:22:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HEART,2017-05-25T07:58:11Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HEART,2017-06-03T17:17:36Z,pzol,NA https://github.com/rust-lang/rust/pull/42037,MERGED,2017-05-16T13:59:35Z,2017-05-19T23:38:40Z,Minor optimisation of the string operations,nagisa,41debc365e398b95742d9e6910705495e93c0ec6,3,Try to optimise char patterns,HEART,2017-07-24T20:21:07Z,achedeuzot,NA https://github.com/rust-lang/rust/pull/42055,MERGED,2017-05-17T12:11:35Z,2017-05-18T12:27:18Z,Enable cross-crate incremental compilation by default.,michaelwoerister,1b8df3d7fb1f575ed12c13a79455af6c7de05632,10,Enable cross-crate incremental compilation by default.,HOORAY,2017-05-17T14:02:28Z,kennytm,NA https://github.com/rust-lang/rust/pull/42055,MERGED,2017-05-17T12:11:35Z,2017-05-18T12:27:18Z,Enable cross-crate incremental compilation by default.,michaelwoerister,1b8df3d7fb1f575ed12c13a79455af6c7de05632,10,Enable cross-crate incremental compilation by default.,HOORAY,2017-05-25T07:38:51Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2017-05-17T21:41:17Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,THUMBS_UP,2017-05-17T21:41:22Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-05-17T21:41:26Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2017-05-17T21:41:28Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,THUMBS_UP,2017-05-17T22:20:37Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-05-17T22:20:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2017-05-17T22:20:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2017-05-17T22:20:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-05-18T03:14:45Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-05-18T16:43:13Z,projektir,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2017-05-18T16:43:17Z,ben0x539,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2017-05-20T14:16:10Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-09-13T18:26:56Z,erincandescent,erin.shepherd@e43.eu https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-09-13T20:52:20Z,nightpool,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2017-09-14T07:01:13Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2017-10-30T13:23:36Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-10-30T13:23:52Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2017-12-30T19:36:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2018-01-01T17:25:41Z,0x0ade,nuda1998@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2018-03-05T21:06:58Z,neonmoe,jens@neon.moe https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2018-03-05T21:06:58Z,neonmoe,jens@neon.moe https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2018-03-12T18:50:32Z,0x0ade,nuda1998@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2019-07-23T14:57:23Z,cybik,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2020-02-21T05:25:01Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,THUMBS_UP,2021-03-03T17:56:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-03-03T17:56:01Z,GrayJack,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2021-03-03T17:56:08Z,GrayJack,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2021-03-03T17:56:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-03-03T18:31:51Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-03-06T10:20:17Z,eopb,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-06-09T17:18:45Z,g-w1,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2021-06-09T17:18:46Z,g-w1,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HEART,2021-06-09T17:18:47Z,g-w1,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-06-18T05:23:59Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,HOORAY,2021-06-18T05:29:05Z,glitzflitz,ameynarkhede03@gmail.com https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2021-12-04T02:48:57Z,craftablescience,NA https://github.com/rust-lang/rust/pull/42069,MERGED,2017-05-17T21:28:21Z,2017-05-20T23:27:16Z,Add an option to run rustbuild on low priority on Windows and Unix,QuietMisdreavus,dd0855d44b61a979983ae329eb84d1928b5f7eb7,1,fix casting of PRIO_PGRP,LAUGH,2022-04-13T02:13:01Z,emilyskidsister,jocelyn@nettek.ca https://github.com/rust-lang/rust/pull/42070,MERGED,2017-05-17T21:49:52Z,2017-05-19T23:38:43Z,misc doc improvements for std::env,tshepang,b9552963d1269ac6008dceda3c2cca65a2d746dc,1,misc doc improvements for std::env,THUMBS_UP,2017-05-18T10:48:10Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/42076,MERGED,2017-05-18T03:37:39Z,2017-06-21T04:14:50Z,Clearer Error Message for Duplicate Definition,alex-ozdemir,a82890e67ba01057b95d7e2f910ae91226505a87,36,Clearer Error Message for Duplicate Definition Clearer use of the error message and span labels to communicate duplicaiton defitions/imports. New error format: ``` error[E0428]: the name `Foo` is defined twice --> example.rs:2:1 | 1 | trait Foo { } | ------------- previous definition of the trait `Foo` here 2 | struct Foo { } | ^^^^^^^^^^^^^^ `Foo` redefined here = note: `Foo` must be defined only once in the type namespace of this module error: aborting due to previous error ```,THUMBS_UP,2017-05-22T18:32:44Z,estebank,NA https://github.com/rust-lang/rust/pull/42080,MERGED,2017-05-18T07:40:14Z,2017-05-19T23:38:44Z,Fix regression introduced by jQuery removal,pravic,1eb6639508ce6874e4d5dbdb02dbb6111565d902,1,Make documentation works again by removing two unnecessary ES6 pieces.,THUMBS_UP,2017-05-18T08:33:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/42080,MERGED,2017-05-18T07:40:14Z,2017-05-19T23:38:44Z,Fix regression introduced by jQuery removal,pravic,1eb6639508ce6874e4d5dbdb02dbb6111565d902,1,Make documentation works again by removing two unnecessary ES6 pieces.,THUMBS_UP,2017-05-18T11:44:56Z,jplatte,NA https://github.com/rust-lang/rust/pull/42088,CLOSED,2017-05-18T18:16:32Z,2017-06-03T19:42:33Z,implement feature gate bind_by_move_pattern_guards,andjo403,NA,NA,NA,HEART,2017-05-18T18:38:09Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42088,CLOSED,2017-05-18T18:16:32Z,2017-06-03T19:42:33Z,implement feature gate bind_by_move_pattern_guards,andjo403,NA,NA,NA,HEART,2017-05-18T19:06:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42103,MERGED,2017-05-19T18:47:20Z,2017-05-27T20:35:33Z,trace_macro: Show both the macro call and its expansion. #42072.,jorendorff,f8b66a001d74946565ee2e7df58afc9918455da1,2,trace_macro: Show both the macro call and its expansion. #42072.,HEART,2017-05-19T18:54:41Z,durka,NA https://github.com/rust-lang/rust/pull/42103,MERGED,2017-05-19T18:47:20Z,2017-05-27T20:35:33Z,trace_macro: Show both the macro call and its expansion. #42072.,jorendorff,f8b66a001d74946565ee2e7df58afc9918455da1,2,trace_macro: Show both the macro call and its expansion. #42072.,HEART,2017-05-19T22:54:24Z,estebank,NA https://github.com/rust-lang/rust/pull/42124,MERGED,2017-05-20T16:53:34Z,2017-05-21T01:53:28Z,update rust-installer,Keruspe,24a8cbc7932d5fa6ed1a2cdee04a42e800afeb55,1,update rust-installer This fixes the default value for sysconfdir Signed-off-by: Marc-Antoine Perennou ,HEART,2017-05-29T19:36:19Z,Ralith,NA https://github.com/rust-lang/rust/pull/42125,MERGED,2017-05-20T17:03:02Z,2017-07-07T03:43:09Z,Check types for privacy,petrochenkov,a27f8cf8a36f3d69267ed25602504144fab1d896,5,Address review comments Fix regressions after rebase,HOORAY,2017-05-20T19:14:49Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42125,MERGED,2017-05-20T17:03:02Z,2017-07-07T03:43:09Z,Check types for privacy,petrochenkov,a27f8cf8a36f3d69267ed25602504144fab1d896,5,Address review comments Fix regressions after rebase,HOORAY,2017-05-20T22:15:21Z,jseyfried,NA https://github.com/rust-lang/rust/pull/42128,MERGED,2017-05-20T19:35:08Z,2017-06-02T15:01:56Z,Improve Travis CI log (travis_fold colors),kennytm,6ac0787ff349dd6df81bb84e673b1b4881f9e856,3,ci: Further tone down the test verbosity. When `--quiet` is passed to rustbuild suppress rustdoc test output unless failure. Added a `--quiet` flag to `tidy` which suppresses the features table. The actual `--quiet` flag is enabled in #42354. Since details of failed tests will still be printed and the name of slow tests taking >60 to runtime will also be printed the debugging difficulty caused by information loss should be minimal; but it is very worthwhile to keep the log under 10000 lines on Travis CI so that common errors can be spotted without reading the raw log.,HEART,2017-05-20T21:28:48Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42128,MERGED,2017-05-20T19:35:08Z,2017-06-02T15:01:56Z,Improve Travis CI log (travis_fold colors),kennytm,6ac0787ff349dd6df81bb84e673b1b4881f9e856,3,ci: Further tone down the test verbosity. When `--quiet` is passed to rustbuild suppress rustdoc test output unless failure. Added a `--quiet` flag to `tidy` which suppresses the features table. The actual `--quiet` flag is enabled in #42354. Since details of failed tests will still be printed and the name of slow tests taking >60 to runtime will also be printed the debugging difficulty caused by information loss should be minimal; but it is very worthwhile to keep the log under 10000 lines on Travis CI so that common errors can be spotted without reading the raw log.,HEART,2017-05-21T00:05:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42128,MERGED,2017-05-20T19:35:08Z,2017-06-02T15:01:56Z,Improve Travis CI log (travis_fold colors),kennytm,6ac0787ff349dd6df81bb84e673b1b4881f9e856,3,ci: Further tone down the test verbosity. When `--quiet` is passed to rustbuild suppress rustdoc test output unless failure. Added a `--quiet` flag to `tidy` which suppresses the features table. The actual `--quiet` flag is enabled in #42354. Since details of failed tests will still be printed and the name of slow tests taking >60 to runtime will also be printed the debugging difficulty caused by information loss should be minimal; but it is very worthwhile to keep the log under 10000 lines on Travis CI so that common errors can be spotted without reading the raw log.,HEART,2017-05-21T11:56:35Z,killercup,NA https://github.com/rust-lang/rust/pull/42128,MERGED,2017-05-20T19:35:08Z,2017-06-02T15:01:56Z,Improve Travis CI log (travis_fold colors),kennytm,6ac0787ff349dd6df81bb84e673b1b4881f9e856,3,ci: Further tone down the test verbosity. When `--quiet` is passed to rustbuild suppress rustdoc test output unless failure. Added a `--quiet` flag to `tidy` which suppresses the features table. The actual `--quiet` flag is enabled in #42354. Since details of failed tests will still be printed and the name of slow tests taking >60 to runtime will also be printed the debugging difficulty caused by information loss should be minimal; but it is very worthwhile to keep the log under 10000 lines on Travis CI so that common errors can be spotted without reading the raw log.,HEART,2017-05-21T18:37:26Z,est31,NA https://github.com/rust-lang/rust/pull/42128,MERGED,2017-05-20T19:35:08Z,2017-06-02T15:01:56Z,Improve Travis CI log (travis_fold colors),kennytm,6ac0787ff349dd6df81bb84e673b1b4881f9e856,3,ci: Further tone down the test verbosity. When `--quiet` is passed to rustbuild suppress rustdoc test output unless failure. Added a `--quiet` flag to `tidy` which suppresses the features table. The actual `--quiet` flag is enabled in #42354. Since details of failed tests will still be printed and the name of slow tests taking >60 to runtime will also be printed the debugging difficulty caused by information loss should be minimal; but it is very worthwhile to keep the log under 10000 lines on Travis CI so that common errors can be spotted without reading the raw log.,HEART,2017-06-01T16:32:00Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42133,MERGED,2017-05-21T07:22:07Z,2017-06-07T04:24:21Z,Add conversions from File and Child* handles to Stdio,cuviper,9debe91675222782e08fbb15bb6359a05bf85131,6,Add conversions from File and Child* handles to Stdio `Stdio` now implements `From` `From` `From` and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.,HEART,2017-05-23T08:49:20Z,juleskers,NA https://github.com/rust-lang/rust/pull/42133,MERGED,2017-05-21T07:22:07Z,2017-06-07T04:24:21Z,Add conversions from File and Child* handles to Stdio,cuviper,9debe91675222782e08fbb15bb6359a05bf85131,6,Add conversions from File and Child* handles to Stdio `Stdio` now implements `From` `From` `From` and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.,HEART,2017-08-27T14:37:09Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/42133,MERGED,2017-05-21T07:22:07Z,2017-06-07T04:24:21Z,Add conversions from File and Child* handles to Stdio,cuviper,9debe91675222782e08fbb15bb6359a05bf85131,6,Add conversions from File and Child* handles to Stdio `Stdio` now implements `From` `From` `From` and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.,HEART,2019-11-25T10:15:49Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42133,MERGED,2017-05-21T07:22:07Z,2017-06-07T04:24:21Z,Add conversions from File and Child* handles to Stdio,cuviper,9debe91675222782e08fbb15bb6359a05bf85131,6,Add conversions from File and Child* handles to Stdio `Stdio` now implements `From` `From` `From` and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.,HEART,2020-01-11T23:47:07Z,binarycrusader,shawn@binarycrusader.com https://github.com/rust-lang/rust/pull/42133,MERGED,2017-05-21T07:22:07Z,2017-06-07T04:24:21Z,Add conversions from File and Child* handles to Stdio,cuviper,9debe91675222782e08fbb15bb6359a05bf85131,6,Add conversions from File and Child* handles to Stdio `Stdio` now implements `From` `From` `From` and `From`. The `Command::stdin`/`stdout`/`stderr` methods now take any type that implements `Into`. This makes it much easier to write shell-like command chains piping to one another and redirecting to and from files. Otherwise one would need to use the unsafe and OS-specific `from_raw_fd` or `from_raw_handle`.,HEART,2021-08-25T05:34:45Z,jonringer,NA https://github.com/rust-lang/rust/pull/42134,MERGED,2017-05-21T08:50:16Z,2017-05-25T04:38:43Z,Make RangeInclusive just a two-field struct,scottmcm,7eaca60f3b3b783ffa1e80ccf91e820f9436b3a3,3,Return a correct size_hint for degenerate inclusive ranges Fixes https://github.com/rust-lang/rust/issues/42135 Found while fixing run-pass/range_inclusive test failure.,HOORAY,2017-05-21T09:12:07Z,kennytm,NA https://github.com/rust-lang/rust/pull/42134,MERGED,2017-05-21T08:50:16Z,2017-05-25T04:38:43Z,Make RangeInclusive just a two-field struct,scottmcm,7eaca60f3b3b783ffa1e80ccf91e820f9436b3a3,3,Return a correct size_hint for degenerate inclusive ranges Fixes https://github.com/rust-lang/rust/issues/42135 Found while fixing run-pass/range_inclusive test failure.,THUMBS_UP,2017-05-22T16:57:12Z,durka,NA https://github.com/rust-lang/rust/pull/42134,MERGED,2017-05-21T08:50:16Z,2017-05-25T04:38:43Z,Make RangeInclusive just a two-field struct,scottmcm,7eaca60f3b3b783ffa1e80ccf91e820f9436b3a3,3,Return a correct size_hint for degenerate inclusive ranges Fixes https://github.com/rust-lang/rust/issues/42135 Found while fixing run-pass/range_inclusive test failure.,HOORAY,2017-06-07T22:29:27Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42136,MERGED,2017-05-21T13:39:50Z,2017-06-01T07:44:14Z,Turn sufficiently old compatibility lints into hard errors,petrochenkov,26d5c0e20cbdd27af12a756ddfb1758d0888aad3,4,Turn `invalid_type_param_default` into a lint again,HEART,2017-05-21T17:29:58Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42136,MERGED,2017-05-21T13:39:50Z,2017-06-01T07:44:14Z,Turn sufficiently old compatibility lints into hard errors,petrochenkov,26d5c0e20cbdd27af12a756ddfb1758d0888aad3,4,Turn `invalid_type_param_default` into a lint again,HEART,2017-05-21T18:33:56Z,est31,NA https://github.com/rust-lang/rust/pull/42146,MERGED,2017-05-22T02:16:13Z,2017-07-17T07:59:56Z,More Rust/RLS integration,nrc,04415dc64c5af86957b4e3b45e124108c93263c4,6,Run RLS tests,HOORAY,2017-05-22T06:21:54Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/42146,MERGED,2017-05-22T02:16:13Z,2017-07-17T07:59:56Z,More Rust/RLS integration,nrc,04415dc64c5af86957b4e3b45e124108c93263c4,6,Run RLS tests,HOORAY,2017-07-12T01:33:29Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/42149,MERGED,2017-05-22T07:33:08Z,2017-05-25T04:38:45Z,libstd/sync/mpsc: relicense under rust license,dvyukov,0b85b64d6b70b100f6222a96ff2337c302b386f1,2,libstd/sync/mpsc: relicense under rust license These files are licensed under a different license than the rest of the codebase. This causes potential issues and inconveniences. Relicense these files under the standard license. I hold original copyright on that code. Fixes #36556,HOORAY,2017-05-23T11:35:49Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/42149,MERGED,2017-05-22T07:33:08Z,2017-05-25T04:38:45Z,libstd/sync/mpsc: relicense under rust license,dvyukov,0b85b64d6b70b100f6222a96ff2337c302b386f1,2,libstd/sync/mpsc: relicense under rust license These files are licensed under a different license than the rest of the codebase. This causes potential issues and inconveniences. Relicense these files under the standard license. I hold original copyright on that code. Fixes #36556,HOORAY,2017-05-23T11:46:48Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/42149,MERGED,2017-05-22T07:33:08Z,2017-05-25T04:38:45Z,libstd/sync/mpsc: relicense under rust license,dvyukov,0b85b64d6b70b100f6222a96ff2337c302b386f1,2,libstd/sync/mpsc: relicense under rust license These files are licensed under a different license than the rest of the codebase. This causes potential issues and inconveniences. Relicense these files under the standard license. I hold original copyright on that code. Fixes #36556,HOORAY,2021-09-13T20:39:00Z,rrbutani,NA https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-05-22T18:15:19Z,alexbool,NA https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-05-22T18:17:46Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-05-23T11:22:53Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-05-27T23:02:55Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-06-14T11:39:08Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-06-14T18:11:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-06-14T19:40:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-06-14T23:15:06Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2017-06-26T10:57:13Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/42155,MERGED,2017-05-22T17:26:10Z,2017-06-11T21:11:34Z,core: allow messages in unimplemented!() macro,seanmonstar,f51771939ba5b36ec89b9f0b51c2cbda51164676,1,core: allow messages in unimplemented!() macro,THUMBS_UP,2018-03-24T04:00:17Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/42159,MERGED,2017-05-22T23:03:49Z,2017-05-25T04:38:46Z,Document drop more.,Havvy,b41b2947d56ce8be0b927d59d766a23271b9dd37,1,Suggested changes by birkenfeld,THUMBS_UP,2017-05-23T01:45:36Z,ScottAbbey,NA https://github.com/rust-lang/rust/pull/42192,MERGED,2017-05-24T15:48:41Z,2017-05-29T19:31:16Z,incr.comp.: Remove DepGraph::write() and its callers,michaelwoerister,c150301a5bae96c504c7b957d6b929a1ed1ba6fb,4,Remove DepGraph::write() and its callers.,HOORAY,2017-05-24T16:07:03Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42192,MERGED,2017-05-24T15:48:41Z,2017-05-29T19:31:16Z,incr.comp.: Remove DepGraph::write() and its callers,michaelwoerister,c150301a5bae96c504c7b957d6b929a1ed1ba6fb,4,Remove DepGraph::write() and its callers.,HOORAY,2017-05-27T19:20:50Z,cramertj,NA https://github.com/rust-lang/rust/pull/42207,MERGED,2017-05-24T23:17:22Z,2017-05-28T12:01:16Z,Remove all instances of fragment_infos and fragment sets,Nashenas88,a563f350b0122da51a507037956858639b2aa106,11,Remove irrelevant tests and unused testing attribute,HEART,2017-05-24T23:49:55Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42207,MERGED,2017-05-24T23:17:22Z,2017-05-28T12:01:16Z,Remove all instances of fragment_infos and fragment sets,Nashenas88,a563f350b0122da51a507037956858639b2aa106,11,Remove irrelevant tests and unused testing attribute,HEART,2017-05-25T12:01:01Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42214,MERGED,2017-05-25T01:58:31Z,2017-05-29T21:56:05Z,rust-src: include everything needed to compile libstd with jemalloc,RalfJung,6620c4b0789834cf4befd47e6ed6e5a3dc224f07,1,rust-src: include everything needed to compile libstd with jemalloc,THUMBS_UP,2017-05-25T03:16:29Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/42214,MERGED,2017-05-25T01:58:31Z,2017-05-29T21:56:05Z,rust-src: include everything needed to compile libstd with jemalloc,RalfJung,6620c4b0789834cf4befd47e6ed6e5a3dc224f07,1,rust-src: include everything needed to compile libstd with jemalloc,THUMBS_UP,2017-05-27T14:13:13Z,alexbool,NA https://github.com/rust-lang/rust/pull/42215,MERGED,2017-05-25T02:51:04Z,2017-05-26T18:12:05Z,Remove superfluous `;;` sequences,callahad,94b074f581d9b6ba4ca8a40a1a52a17a8e532a3f,4,Remove superfluous `;;` sequences,LAUGH,2017-05-25T02:54:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42215,MERGED,2017-05-25T02:51:04Z,2017-05-26T18:12:05Z,Remove superfluous `;;` sequences,callahad,94b074f581d9b6ba4ca8a40a1a52a17a8e532a3f,4,Remove superfluous `;;` sequences,LAUGH,2017-05-25T03:19:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/42219,MERGED,2017-05-25T13:58:14Z,2017-06-29T11:13:40Z,add `allow_fail` test attribute,pwoolcoc,4154f895d388b1a8634a95ff76892419bebe9cc3,1,only show allowed failure count if there are allowed failures,CONFUSED,2017-05-26T15:55:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/42219,MERGED,2017-05-25T13:58:14Z,2017-06-29T11:13:40Z,add `allow_fail` test attribute,pwoolcoc,4154f895d388b1a8634a95ff76892419bebe9cc3,1,only show allowed failure count if there are allowed failures,THUMBS_UP,2017-05-28T18:41:01Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/42219,MERGED,2017-05-25T13:58:14Z,2017-06-29T11:13:40Z,add `allow_fail` test attribute,pwoolcoc,4154f895d388b1a8634a95ff76892419bebe9cc3,1,only show allowed failure count if there are allowed failures,THUMBS_UP,2019-03-04T04:44:30Z,jmeggitt,NA https://github.com/rust-lang/rust/pull/42219,MERGED,2017-05-25T13:58:14Z,2017-06-29T11:13:40Z,add `allow_fail` test attribute,pwoolcoc,4154f895d388b1a8634a95ff76892419bebe9cc3,1,only show allowed failure count if there are allowed failures,THUMBS_UP,2020-09-12T07:03:42Z,aminya,aminyahyaabadi74@gmail.com https://github.com/rust-lang/rust/pull/42224,MERGED,2017-05-25T18:48:52Z,2017-05-26T18:12:06Z,Remove stray lockfile,brson,435e1cec9e63ee9651a0c082b050b5c49da96c10,1,Remove stray lockfile,LAUGH,2017-05-26T15:59:52Z,kennytm,NA https://github.com/rust-lang/rust/pull/42225,MERGED,2017-05-25T18:56:07Z,2017-06-03T01:09:23Z,Support VS 2017,brson,da100fe0bb7ba77dbcc346018068dbfdba053f6b,14,Support VS 2017 Fixes #38584,HEART,2017-05-27T10:49:12Z,Giacom,NA https://github.com/rust-lang/rust/pull/42225,MERGED,2017-05-25T18:56:07Z,2017-06-03T01:09:23Z,Support VS 2017,brson,da100fe0bb7ba77dbcc346018068dbfdba053f6b,14,Support VS 2017 Fixes #38584,HOORAY,2017-06-02T04:31:02Z,steveatinfincia,steve@infincia.com https://github.com/rust-lang/rust/pull/42225,MERGED,2017-05-25T18:56:07Z,2017-06-03T01:09:23Z,Support VS 2017,brson,da100fe0bb7ba77dbcc346018068dbfdba053f6b,14,Support VS 2017 Fixes #38584,HEART,2017-06-02T14:19:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42225,MERGED,2017-05-25T18:56:07Z,2017-06-03T01:09:23Z,Support VS 2017,brson,da100fe0bb7ba77dbcc346018068dbfdba053f6b,14,Support VS 2017 Fixes #38584,HOORAY,2017-06-02T14:19:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42225,MERGED,2017-05-25T18:56:07Z,2017-06-03T01:09:23Z,Support VS 2017,brson,da100fe0bb7ba77dbcc346018068dbfdba053f6b,14,Support VS 2017 Fixes #38584,HOORAY,2017-06-07T18:12:49Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-26T15:46:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-26T15:47:07Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-26T15:49:00Z,kennytm,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-26T16:01:15Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-26T16:34:55Z,est31,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-27T06:47:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-27T13:13:44Z,killercup,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-05-28T12:42:58Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-06-06T14:54:43Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-06-14T19:28:53Z,Havvy,NA https://github.com/rust-lang/rust/pull/42247,MERGED,2017-05-26T15:45:27Z,2017-06-06T17:42:20Z,add playbot jokes to run-pass test,durka,9d67dfec129ccdad10437e304caa5d910dc71593,1,tidy is an unnecessary roadblock to contributions,LAUGH,2017-06-15T01:51:47Z,lifthrasiir,NA https://github.com/rust-lang/rust/pull/42260,MERGED,2017-05-27T15:18:22Z,2017-05-28T12:01:19Z,Docs: impls of PartialEq/PartialOrd/Ord must agree,NA,NA,NA,NA,HOORAY,2017-05-27T16:52:46Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/42263,MERGED,2017-05-27T17:23:19Z,2017-06-01T10:10:01Z,rustbuild: Fix copying duplicate crates into the sysroot,alexcrichton,2dab1e21509c4ffa8f1ea93d4a70c5a33cc6fe1d,2,"rustbuild: Fix copying duplicate crates into the sysroot After compiling a project (e.g. libstd libtest or librustc) rustbuild needs to copy over all artifacts into the sysroot of the compiler it's assembling. Unfortunately rustbuild doesn't know precisely what files to copy! Today it has a heuristic where it just looks at the most recent version of all files that look like rlibs/dylibs and copies those over. This unfortunately leads to bugs with different versions of the same craet as seen in #42261. This commit updates rustbuild's strategy of copying artifacts to work off the list of artifacts produced by `cargo build --message-format=json`. The build system will now parse json messages coming out of Cargo to watch for files being generated and then it'll only copy over those precise files. Note that there's still a bit of weird logic where Cargo prints that it's creating `libstd.rlib` where we actually want `libstd-xxxxx.rlib` so we still do a bit of ""most recent file"" probing for those. This commit should take care of the crates.io dependency issues however as they're all copied over precisely. Closes #42261",HEART,2017-05-27T18:09:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42265,MERGED,2017-05-27T18:26:38Z,2017-06-04T11:17:54Z,Change for-loop desugar to not borrow the iterator during the loop,Zoxc,cfdbff7c125cbdd5a2b75e526717413718d16111,9,Change for-loop desugar to not borrow the iterator during the loop,HOORAY,2017-06-07T10:24:59Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/42265,MERGED,2017-05-27T18:26:38Z,2017-06-04T11:17:54Z,Change for-loop desugar to not borrow the iterator during the loop,Zoxc,cfdbff7c125cbdd5a2b75e526717413718d16111,9,Change for-loop desugar to not borrow the iterator during the loop,THUMBS_UP,2017-06-07T14:23:45Z,bestouff,NA https://github.com/rust-lang/rust/pull/42270,CLOSED,2017-05-27T21:41:00Z,2017-07-25T23:08:56Z,Fix wrong report on closure args mismatch when a ref is expected but not found,Emilgardis,NA,NA,NA,THUMBS_UP,2017-05-27T22:47:43Z,mcarton,NA https://github.com/rust-lang/rust/pull/42270,CLOSED,2017-05-27T21:41:00Z,2017-07-25T23:08:56Z,Fix wrong report on closure args mismatch when a ref is expected but not found,Emilgardis,NA,NA,NA,THUMBS_UP,2017-05-29T19:00:27Z,rbalicki2,NA https://github.com/rust-lang/rust/pull/42270,CLOSED,2017-05-27T21:41:00Z,2017-07-25T23:08:56Z,Fix wrong report on closure args mismatch when a ref is expected but not found,Emilgardis,NA,NA,NA,THUMBS_UP,2017-06-01T22:58:19Z,estebank,NA https://github.com/rust-lang/rust/pull/42275,MERGED,2017-05-28T02:50:58Z,2017-06-01T07:44:18Z,Lower `?` to `Try` instead of `Carrier`,scottmcm,3119e634e178d8acaed4a2d4a9d52e3b76ae79cf,1,Add some try_trait ramblings to the unstable book,HOORAY,2017-05-30T17:47:26Z,kennytm,NA https://github.com/rust-lang/rust/pull/42275,MERGED,2017-05-28T02:50:58Z,2017-06-01T07:44:18Z,Lower `?` to `Try` instead of `Carrier`,scottmcm,3119e634e178d8acaed4a2d4a9d52e3b76ae79cf,1,Add some try_trait ramblings to the unstable book,HOORAY,2017-06-01T01:34:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/42275,MERGED,2017-05-28T02:50:58Z,2017-06-01T07:44:18Z,Lower `?` to `Try` instead of `Carrier`,scottmcm,3119e634e178d8acaed4a2d4a9d52e3b76ae79cf,1,Add some try_trait ramblings to the unstable book,HOORAY,2017-06-08T11:24:48Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/42278,MERGED,2017-05-28T09:28:32Z,2017-06-09T23:19:54Z,Fix GDB pretty-printer for tuples and pointers,gentoo90,63076ddbb8e9856e9996adb49fc0a67a29ca697b,2,Add compat_str() which works with unicode in both Python 2 and 3 GDB can be built with Python 2 or with Python 3,HEART,2017-05-30T16:17:30Z,sfackler,NA https://github.com/rust-lang/rust/pull/42278,MERGED,2017-05-28T09:28:32Z,2017-06-09T23:19:54Z,Fix GDB pretty-printer for tuples and pointers,gentoo90,63076ddbb8e9856e9996adb49fc0a67a29ca697b,2,Add compat_str() which works with unicode in both Python 2 and 3 GDB can be built with Python 2 or with Python 3,HEART,2017-06-06T01:35:08Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-05-30T15:16:57Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-05-30T16:06:08Z,alexbool,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-05-30T16:19:36Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HEART,2017-05-30T16:19:45Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HEART,2017-05-30T23:48:30Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-05-31T00:33:26Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-05-31T14:05:23Z,xen0n,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-06-01T07:19:13Z,gereeter,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-06-05T23:46:51Z,joshlf,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-06-06T12:31:46Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-06-16T04:23:39Z,cramertj,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HEART,2017-06-16T04:23:40Z,cramertj,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2017-06-21T18:24:16Z,csssuf,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HEART,2017-06-28T07:58:05Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2019-02-10T03:30:29Z,tesuji,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HOORAY,2021-09-09T14:12:44Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,HEART,2021-09-09T14:12:45Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/42313,MERGED,2017-05-30T14:49:43Z,2017-06-20T07:22:20Z,Allocator integration,pnkfelix,55a629d496f9393dff5c3a8d4511bf2686bf365b,1,Ignore a spuriously failing test on asmjs Other tests are already ignored for missing `rust_begin_unwind` let's add another.,THUMBS_UP,2021-09-09T14:13:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/42314,MERGED,2017-05-30T15:52:03Z,2017-06-01T07:44:20Z,ARMv5 needs +strict-align,jannic,4450807ead1c5f9a5f8d44ffee6ed0f968c68c34,1,ARMv5 needs +strict-align Without that flag LLVM generates unaligned memory access instructions which are not allowed on ARMv5. For example the 'hello world' example from `cargo --new` failed with: ``` $ ./hello Hello world! thread 'main' panicked at 'assertion failed: end <= len' src/libcollections/vec.rs:1113 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` I traced this error back to the following assembler code in `BufWriter::flush_buf`: ``` 6f44: e28d0018 add r0 sp #24 [...] 6f54: e280b005 add fp r0 #5 [...] 7018: e5cd001c strb r0 [sp #28] 701c: e1a0082a lsr r0 sl #16 7020: 03a01001 moveq r1 #1 7024: e5cb0002 strb r0 [fp #2] 7028: e1cba0b0 strh sl [fp] ``` Note that `fp` points to `sp + 29` so the three `str*`-instructions should fill up a 32bit - value at `sp + 28` which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp` so the upper bits of `n` won't get cleared leading to the assertion failure in Vec::drain. With `+strict-align` the code works as expected.,HEART,2017-05-30T16:21:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42315,MERGED,2017-05-30T16:16:26Z,2017-05-31T23:53:22Z,RangeFrom should have an infinite size_hint,scottmcm,265dce66b6b1181f4b955032b742c702c753f6c8,3,RangeFrom should have an infinite size_hint This makes the size_hint from things like `take` more precise.,THUMBS_UP,2017-05-30T16:51:51Z,kennytm,NA https://github.com/rust-lang/rust/pull/42335,MERGED,2017-05-31T15:28:16Z,2017-06-03T01:09:26Z,Don't byteswap Fingerprints when encoding,jcowgill,edefcb2946c3eb94e8f43ce3a979b4a876d8e11a,1,Don't byteswap Fingerprints when encoding Byteswapping Fingerprints when encoding is unnessesary and breaks if the Fingerprint is later decoded on a machine with different endianness to the one it was encoded on. Fix by removing the Encodable and Decodable implementations and use the ones derived from RustcEncodable and RustcDecodable. Fixes #42239,HEART,2017-05-31T16:34:55Z,est31,NA https://github.com/rust-lang/rust/pull/42335,MERGED,2017-05-31T15:28:16Z,2017-06-03T01:09:26Z,Don't byteswap Fingerprints when encoding,jcowgill,edefcb2946c3eb94e8f43ce3a979b4a876d8e11a,1,Don't byteswap Fingerprints when encoding Byteswapping Fingerprints when encoding is unnessesary and breaks if the Fingerprint is later decoded on a machine with different endianness to the one it was encoded on. Fix by removing the Encodable and Decodable implementations and use the ones derived from RustcEncodable and RustcDecodable. Fixes #42239,HEART,2017-06-01T08:31:14Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/42354,MERGED,2017-06-01T15:56:59Z,2017-06-03T08:33:10Z,Reduce verbosity of build logs,Mark-Simulacrum,3447aa764ac9626aba6de0179289fb41ddb31543,2,Quiet tests on PR tests,HOORAY,2017-06-01T16:01:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42354,MERGED,2017-06-01T15:56:59Z,2017-06-03T08:33:10Z,Reduce verbosity of build logs,Mark-Simulacrum,3447aa764ac9626aba6de0179289fb41ddb31543,2,Quiet tests on PR tests,HOORAY,2017-06-01T22:47:45Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42362,MERGED,2017-06-01T22:05:14Z,2017-06-04T23:35:26Z,Show trait method signature when impl differs,estebank,e324919ec57954adaa49884e5894bc7d615d413e,6,Show trait method signature when impl differs When the trait's span is available it is already being used add a `note` for the cases where the span isn't available: ``` error[E0053]: method `fmt` has an incompatible type for trait --> $DIR/trait_type.rs:17:4 | 17 | fn fmt(&self x: &str) -> () { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability | = note: expected type `fn(&MyType &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` found type `fn(&MyType &str)` error[E0050]: method `fmt` has 1 parameter but the declaration in trait `std::fmt::Display::fmt` has 2 --> $DIR/trait_type.rs:21:11 | 21 | fn fmt(&self) -> () { } | ^^^^^ expected 2 parameters found 1 | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0186]: method `fmt` has a `&self` declaration in the trait but not in the impl --> $DIR/trait_type.rs:25:4 | 25 | fn fmt() -> () { } | ^^^^^^^^^^^^^^^^^^ expected `&self` in impl | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0046]: not all trait items implemented missing: `fmt` --> $DIR/trait_type.rs:28:1 | 28 | impl std::fmt::Display for MyType4 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `fmt` in implementation | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` ```,THUMBS_UP,2017-06-01T22:12:31Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42362,MERGED,2017-06-01T22:05:14Z,2017-06-04T23:35:26Z,Show trait method signature when impl differs,estebank,e324919ec57954adaa49884e5894bc7d615d413e,6,Show trait method signature when impl differs When the trait's span is available it is already being used add a `note` for the cases where the span isn't available: ``` error[E0053]: method `fmt` has an incompatible type for trait --> $DIR/trait_type.rs:17:4 | 17 | fn fmt(&self x: &str) -> () { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability | = note: expected type `fn(&MyType &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` found type `fn(&MyType &str)` error[E0050]: method `fmt` has 1 parameter but the declaration in trait `std::fmt::Display::fmt` has 2 --> $DIR/trait_type.rs:21:11 | 21 | fn fmt(&self) -> () { } | ^^^^^ expected 2 parameters found 1 | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0186]: method `fmt` has a `&self` declaration in the trait but not in the impl --> $DIR/trait_type.rs:25:4 | 25 | fn fmt() -> () { } | ^^^^^^^^^^^^^^^^^^ expected `&self` in impl | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0046]: not all trait items implemented missing: `fmt` --> $DIR/trait_type.rs:28:1 | 28 | impl std::fmt::Display for MyType4 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `fmt` in implementation | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` ```,HEART,2017-06-02T11:12:50Z,killercup,NA https://github.com/rust-lang/rust/pull/42362,MERGED,2017-06-01T22:05:14Z,2017-06-04T23:35:26Z,Show trait method signature when impl differs,estebank,e324919ec57954adaa49884e5894bc7d615d413e,6,Show trait method signature when impl differs When the trait's span is available it is already being used add a `note` for the cases where the span isn't available: ``` error[E0053]: method `fmt` has an incompatible type for trait --> $DIR/trait_type.rs:17:4 | 17 | fn fmt(&self x: &str) -> () { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability | = note: expected type `fn(&MyType &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` found type `fn(&MyType &str)` error[E0050]: method `fmt` has 1 parameter but the declaration in trait `std::fmt::Display::fmt` has 2 --> $DIR/trait_type.rs:21:11 | 21 | fn fmt(&self) -> () { } | ^^^^^ expected 2 parameters found 1 | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0186]: method `fmt` has a `&self` declaration in the trait but not in the impl --> $DIR/trait_type.rs:25:4 | 25 | fn fmt() -> () { } | ^^^^^^^^^^^^^^^^^^ expected `&self` in impl | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` error[E0046]: not all trait items implemented missing: `fmt` --> $DIR/trait_type.rs:28:1 | 28 | impl std::fmt::Display for MyType4 {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `fmt` in implementation | = note: `fmt` from trait: `fn(&Self &mut std::fmt::Formatter<'_>) -> std::result::Result<() std::fmt::Error>` ```,THUMBS_UP,2017-06-02T17:12:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42409,MERGED,2017-06-03T16:19:21Z,2017-06-07T06:38:47Z,Better docs,bjorn3,949b2a3f847292a12172a67c9be3cc3b73f2d5c0,1,Update mod.rs,HEART,2017-06-03T19:01:18Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42419,MERGED,2017-06-04T04:43:23Z,2017-06-12T06:19:16Z,"Explicate what ""Rc"" and ""Arc"" stand for.",ucarion,1af0cb165065ebca5296a7b5841ebec9bfb40476,2,Use single quotes and doc the Rc struct itself.,THUMBS_UP,2017-06-04T18:27:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42428,MERGED,2017-06-04T18:18:59Z,2017-06-14T02:56:32Z,Add overflow checking for `str::get` with inclusive ranges,scottmcm,808a08a363591abf754fafd93ec3f44c686486ec,3,Add overflow checking for str::get with inclusive ranges Fixes #42401,THUMBS_UP,2017-06-14T19:59:58Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42433,MERGED,2017-06-04T19:56:58Z,2017-06-14T11:17:41Z,Build instruction profiler runtime as part of compiler-rt,marco-c,5c084fd8edd986d8a4bd9ff37b303f8777623a56,1,Add libprofiler_builtins to the list of paths for the rust-src component,HOORAY,2017-06-10T15:26:40Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42443,MERGED,2017-06-05T10:42:08Z,2017-06-08T11:05:18Z,Better closure error message,tommyip,345b8332bde78dca7664b1b1b4f4a7284bd70a6d,3,Cover all cases in closure errors,HEART,2017-06-08T16:23:35Z,estebank,NA https://github.com/rust-lang/rust/pull/42443,MERGED,2017-06-05T10:42:08Z,2017-06-08T11:05:18Z,Better closure error message,tommyip,345b8332bde78dca7664b1b1b4f4a7284bd70a6d,3,Cover all cases in closure errors,HEART,2017-06-08T18:54:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42443,MERGED,2017-06-05T10:42:08Z,2017-06-08T11:05:18Z,Better closure error message,tommyip,345b8332bde78dca7664b1b1b4f4a7284bd70a6d,3,Cover all cases in closure errors,HEART,2017-06-08T19:21:55Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/42456,CLOSED,2017-06-05T21:45:34Z,2017-06-30T22:25:31Z,Add `cast` function to primitive integers,alexcrichton,NA,NA,NA,HOORAY,2017-06-11T14:03:59Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/42456,CLOSED,2017-06-05T21:45:34Z,2017-06-30T22:25:31Z,Add `cast` function to primitive integers,alexcrichton,NA,NA,NA,HOORAY,2017-06-11T16:04:05Z,mcarton,NA https://github.com/rust-lang/rust/pull/42471,MERGED,2017-06-06T04:14:26Z,2017-06-13T08:54:34Z,save-analysis: signatures for everything!,nrc,ffd83fdf7deacc8f985dab0d44bfe1e2becf6543,1,Update RLS again,HEART,2017-06-08T21:15:28Z,brson,NA https://github.com/rust-lang/rust/pull/42487,MERGED,2017-06-06T18:36:40Z,2017-06-08T22:21:40Z,std: Avoid panics in rust_eh_personality,alexcrichton,52805d233b59503cdfe58ee21e894ed6bb3b1da9,3,std: Avoid panics in rust_eh_personality This commit removes a few calls to panic and/or assert in `rust_eh_personality`. This function definitely can't itself panic (that'd probably segfault or do something else weird) and I was also noticing that a `pub extern fn foo() {}` cdylib was abnormally large. Turns out all that size was the panicking machinery brought in by the personality function! The change here is to return a `Result` internally so we can bubble up the fatal error eventually translating to the appropriate error code for the libunwind ABI.,HEART,2017-06-08T21:14:05Z,brson,NA https://github.com/rust-lang/rust/pull/42487,MERGED,2017-06-06T18:36:40Z,2017-06-08T22:21:40Z,std: Avoid panics in rust_eh_personality,alexcrichton,52805d233b59503cdfe58ee21e894ed6bb3b1da9,3,std: Avoid panics in rust_eh_personality This commit removes a few calls to panic and/or assert in `rust_eh_personality`. This function definitely can't itself panic (that'd probably segfault or do something else weird) and I was also noticing that a `pub extern fn foo() {}` cdylib was abnormally large. Turns out all that size was the panicking machinery brought in by the personality function! The change here is to return a `Result` internally so we can bubble up the fatal error eventually translating to the appropriate error code for the libunwind ABI.,HEART,2017-06-14T18:24:04Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HOORAY,2017-06-07T03:14:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HOORAY,2017-06-07T03:54:31Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HOORAY,2017-06-07T05:41:58Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HOORAY,2017-06-08T19:09:58Z,est31,NA https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HEART,2017-06-08T21:13:51Z,brson,NA https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HOORAY,2017-06-14T03:16:44Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42495,MERGED,2017-06-07T02:45:19Z,2017-06-20T09:44:46Z,Bump to 1.20.0 and update stage0 compiler,alexcrichton,be7ebdd512e8b4de29c0e0cf5aabf486e988867b,47,Bump version and stage0 compiler,HEART,2017-06-14T03:16:45Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42496,MERGED,2017-06-07T03:03:24Z,2017-06-14T02:56:33Z,Add max and min to Ord,Razaekel,a32ffc679702e3ae307c7fc20873c9e970a8894c,1,Alias std::cmp::max/min to Ord::max/min,HEART,2017-06-07T03:15:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42496,MERGED,2017-06-07T03:03:24Z,2017-06-14T02:56:33Z,Add max and min to Ord,Razaekel,a32ffc679702e3ae307c7fc20873c9e970a8894c,1,Alias std::cmp::max/min to Ord::max/min,HEART,2017-06-09T08:40:27Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/42496,MERGED,2017-06-07T03:03:24Z,2017-06-14T02:56:33Z,Add max and min to Ord,Razaekel,a32ffc679702e3ae307c7fc20873c9e970a8894c,1,Alias std::cmp::max/min to Ord::max/min,HEART,2017-06-13T10:57:23Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/42496,MERGED,2017-06-07T03:03:24Z,2017-06-14T02:56:33Z,Add max and min to Ord,Razaekel,a32ffc679702e3ae307c7fc20873c9e970a8894c,1,Alias std::cmp::max/min to Ord::max/min,HEART,2017-06-14T09:54:29Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/42497,MERGED,2017-06-07T04:32:08Z,2017-06-08T06:02:13Z,Replace some matches with try.,qnighy,ab72611d8f664684dbd5dd2efe6fd7edff53ee5d,3,Replace some matches with try.,THUMBS_UP,2017-06-07T04:47:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42497,MERGED,2017-06-07T04:32:08Z,2017-06-08T06:02:13Z,Replace some matches with try.,qnighy,ab72611d8f664684dbd5dd2efe6fd7edff53ee5d,3,Replace some matches with try.,THUMBS_UP,2017-06-07T06:42:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42510,MERGED,2017-06-07T16:25:04Z,2017-06-08T06:02:14Z,Update step_by docs to say iterator instead of range,mbrubeck,b6193f3c005e52e93b00d2d69eea96b4b91d002b,1,Update docs to say iterator instead of range,THUMBS_UP,2017-06-07T17:02:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42521,MERGED,2017-06-08T01:32:23Z,2017-06-09T12:49:58Z,std: Handle ENOSYS when calling `pipe2`,alexcrichton,44e6406f9a29e03280f4e16434c06e1d0abfaffc,1,std: Handle ENOSYS when calling `pipe2` Should help fix an accidental regression from #39386.,HEART,2017-06-08T21:13:42Z,brson,NA https://github.com/rust-lang/rust/pull/42525,MERGED,2017-06-08T03:29:53Z,2017-06-09T18:17:12Z,[beta] Update rls/cargo submodules,alexcrichton,8128639a4793b3febcd2b4b4b44de02dfc78949e,3,[beta] Update rls/cargo submodules This updates the cargo submodule to the latest tip of Cargo along with an accompanying update to the `rls` submodule to keep it compiling.,HEART,2017-06-08T21:12:40Z,brson,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-08T06:35:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HEART,2017-06-08T10:10:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-08T10:10:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-08T14:28:00Z,oli-obk,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-09T18:35:48Z,Cldfire,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-10T04:52:22Z,MoSal,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-10T22:59:20Z,Flat,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-18T10:47:29Z,autrilla,adrianutrilla@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-21T20:27:02Z,Ploppz,3rlendhl@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-06-28T15:40:18Z,pshc,paul@paulcollier.ca https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-07-22T07:48:52Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-07-24T13:03:08Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-08-29T08:14:52Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-09-25T21:34:32Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HEART,2017-10-01T23:47:42Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-04T00:10:00Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-04T04:10:58Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HEART,2017-10-04T06:57:30Z,AdamRzepka,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-04T14:03:08Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-04T16:09:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-04T20:53:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-05T00:36:44Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-10-06T08:25:32Z,hoodie,NA https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HEART,2017-11-22T14:05:39Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-11-22T14:05:42Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-11-23T08:24:43Z,gavento,gavento@gmail.com https://github.com/rust-lang/rust/pull/42526,MERGED,2017-06-08T03:58:32Z,2017-09-30T01:31:44Z,Impl Try for Option,huntiep,e30d92bb2d885629b51a5511b58109c94a1c56da,2,Add UI tests,HOORAY,2017-11-29T07:51:12Z,airtoxin,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-06-08T12:34:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T12:50:43Z,oberien,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T13:14:14Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-06-08T13:22:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T13:22:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T13:33:33Z,qnighy,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T14:28:18Z,est31,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-06-08T14:28:19Z,est31,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-06-08T14:28:21Z,est31,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T14:58:33Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T17:10:26Z,killercup,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T17:13:11Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-08T18:43:15Z,jseyfried,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-06-09T13:08:57Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-09T21:45:14Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-10T03:46:19Z,mr4x,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-10T14:59:38Z,meh,meh@schizofreni.co https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-06-14T11:35:20Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-14T11:46:32Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-14T12:56:34Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-14T13:34:46Z,alteous,david@harvey-macaulay.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-14T17:53:02Z,nosideeffects,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-14T19:41:59Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-06-14T23:13:15Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-06-15T06:56:58Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-06-15T09:44:36Z,tux3,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-07-25T18:25:52Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-08-28T20:11:14Z,mati865,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-08-31T16:36:12Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HEART,2017-08-31T19:27:16Z,weima,weima.gm@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-08-31T19:27:19Z,weima,weima.gm@gmail.com https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-09-01T11:21:56Z,adyomin,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,HOORAY,2017-09-01T11:21:59Z,adyomin,NA https://github.com/rust-lang/rust/pull/42533,MERGED,2017-06-08T12:25:25Z,2017-06-10T09:11:48Z,Speed up expansion,Mark-Simulacrum,3d9ebf2916f96c6934a84a5abc2067145e062e75,4,Speed up expansion. This reduces duplication thereby increasing expansion speed.,THUMBS_UP,2017-09-20T01:05:34Z,leovailati,leovailati@gmail.com https://github.com/rust-lang/rust/pull/42537,MERGED,2017-06-08T16:39:28Z,2017-06-12T13:59:47Z,incr.comp.: Make DepNode `Copy` and valid across compilation sessions,michaelwoerister,fdff2d3588451c49adca5d92f551af94e920f0e8,1,Add some documentation to the dep_node module.,HEART,2017-06-08T17:02:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42537,MERGED,2017-06-08T16:39:28Z,2017-06-12T13:59:47Z,incr.comp.: Make DepNode `Copy` and valid across compilation sessions,michaelwoerister,fdff2d3588451c49adca5d92f551af94e920f0e8,1,Add some documentation to the dep_node module.,HEART,2017-06-10T01:35:06Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42540,MERGED,2017-06-08T16:46:22Z,2017-06-10T06:50:10Z,[beta] Bootstrap from release artifacts,alexcrichton,12b9d861f1aa668d1fb7c3e4f0eef8265b186428,1,[beta] Bootstrap from release artifacts Switch to prod now that the release happened,HEART,2017-06-08T21:12:32Z,brson,NA https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-06-08T18:12:33Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-06-08T18:38:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,THUMBS_UP,2017-06-08T20:34:49Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,THUMBS_UP,2017-06-09T08:36:59Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-06-09T08:37:00Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-06-14T06:23:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,THUMBS_UP,2017-06-29T14:45:54Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,THUMBS_UP,2017-06-29T23:19:57Z,friedroman,NA https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-07-18T10:04:28Z,dwijnand,dale.wijnand@gmail.com https://github.com/rust-lang/rust/pull/42541,MERGED,2017-06-08T17:43:21Z,2017-06-24T14:43:05Z,assert_eq failure message easier to read,gilescope,940d5ca3d05ff23767a94b764b6b3658a435ac37,1,Adding training commer to be more consistent with prior format.,HEART,2017-12-25T20:54:45Z,lpil,louis@lpil.uk https://github.com/rust-lang/rust/pull/42551,MERGED,2017-06-08T20:49:37Z,2017-06-10T01:41:07Z,doc: a more complete explanation and a better example,tshepang,c288864ed0b83f58183a9ddc53d02d36eac29287,1,doc: a more complete explanation and a better example,HEART,2017-06-08T21:10:51Z,brson,NA https://github.com/rust-lang/rust/pull/42556,MERGED,2017-06-09T05:26:05Z,2017-06-10T11:23:55Z,Get LLVM to stop generating dead assembly in next_power_of_two,scottmcm,6d86f0c018b57fcb9ca12c801939130b7f8e441e,1,Use ctlz_nonzero to improve ASM from next_power_of_two,HOORAY,2017-06-15T16:21:24Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/42563,MERGED,2017-06-09T14:32:05Z,2017-06-10T21:35:42Z,Disentangle InferCtxt MemCategorizationContext and ExprUseVisitor.,eddyb,fc5c31c48cf19757ebf4b750efa34e7cb5f995e3,19,rustc: make the comon case of tcx.infer_ctxt(()) nicer.,HOORAY,2017-06-09T14:38:26Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/42563,MERGED,2017-06-09T14:32:05Z,2017-06-10T21:35:42Z,Disentangle InferCtxt MemCategorizationContext and ExprUseVisitor.,eddyb,fc5c31c48cf19757ebf4b750efa34e7cb5f995e3,19,rustc: make the comon case of tcx.infer_ctxt(()) nicer.,HOORAY,2017-06-09T18:36:07Z,mcarton,NA https://github.com/rust-lang/rust/pull/42565,MERGED,2017-06-09T17:29:54Z,2017-08-24T02:32:28Z,Implement From<&[T]> and others for Arc/Rc (RFC 1845),murarth,8e0d01b432b0683d13429dcce907a2b38f30b9f6,3,Implement `From<&[T]>` and others for `Arc`/`Rc` Implements RFC 1845 adding implementations of: * `From<&[T]>` for `Rc<[T]>` * `From<&str>` for `Rc` * `From` for `Rc` * `From>` for `Rc` * `From>` for `Rc<[T]>` * and likewise for `Arc<_>` Also removes now-obsolete internal methods `Rc::__from_array` and `Rc::__from_str` replacing their use with `Rc::from`.,THUMBS_UP,2017-07-11T01:01:00Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-09T21:24:00Z,brson,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-09T21:38:37Z,est31,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-09T22:28:01Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-09T22:39:17Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-10T04:25:18Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-10T09:48:06Z,kennytm,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-11T01:26:11Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-13T16:35:42Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-13T18:58:32Z,chpio,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-13T18:58:32Z,chpio,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-17T09:01:41Z,pshc,paul@paulcollier.ca https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-21T01:52:29Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-21T01:52:29Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-06-23T01:42:30Z,amilajack,amilajack@gmail.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HEART,2017-06-23T01:42:31Z,amilajack,amilajack@gmail.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-07-01T01:56:20Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-08-30T15:36:37Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-08-31T02:21:19Z,kurosame,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-08-31T06:51:23Z,Demayl,NA https://github.com/rust-lang/rust/pull/42571,MERGED,2017-06-09T21:11:35Z,2017-06-20T12:24:51Z,Enable wasm LLVM backend,tlively,a1981a64a22024bbda98cf1b76b7c751fb1dcddb,7,Add target to use LLVM wasm backend The new target is wasm32-experimental-emscripten. Adds a new configuration option to opt in to building experimental LLVM backends such as the WebAssembly backend. The target name was chosen to be similar to the existing wasm32-unknown-emscripten target so that the build and tests would work with minimal other code changes. When/if the new target replaces the old target simply renaming it should just work.,HOORAY,2017-10-09T22:51:20Z,romankurakin,mail@kurakindev.com https://github.com/rust-lang/rust/pull/42578,MERGED,2017-06-10T03:33:56Z,2017-06-16T05:43:46Z,Learn to parse `a as usize < b`,estebank,ad260ffc884477686e8f6f52c97a417bf99e2f19,10,Review comments - generate error instead of warning - remove `RewindPoint` and just keep a copy of `Parser` to rewind state. - `dont_parse_generics: bool` -> `parse_generics: bool` - remove `eat_lt` - move error handling code to separate method,HEART,2017-06-10T09:03:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/42578,MERGED,2017-06-10T03:33:56Z,2017-06-16T05:43:46Z,Learn to parse `a as usize < b`,estebank,ad260ffc884477686e8f6f52c97a417bf99e2f19,10,Review comments - generate error instead of warning - remove `RewindPoint` and just keep a copy of `Parser` to rewind state. - `dont_parse_generics: bool` -> `parse_generics: bool` - remove `eat_lt` - move error handling code to separate method,HEART,2017-06-10T14:40:38Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/42578,MERGED,2017-06-10T03:33:56Z,2017-06-16T05:43:46Z,Learn to parse `a as usize < b`,estebank,ad260ffc884477686e8f6f52c97a417bf99e2f19,10,Review comments - generate error instead of warning - remove `RewindPoint` and just keep a copy of `Parser` to rewind state. - `dont_parse_generics: bool` -> `parse_generics: bool` - remove `eat_lt` - move error handling code to separate method,HEART,2017-06-10T19:49:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/42578,MERGED,2017-06-10T03:33:56Z,2017-06-16T05:43:46Z,Learn to parse `a as usize < b`,estebank,ad260ffc884477686e8f6f52c97a417bf99e2f19,10,Review comments - generate error instead of warning - remove `RewindPoint` and just keep a copy of `Parser` to rewind state. - `dont_parse_generics: bool` -> `parse_generics: bool` - remove `eat_lt` - move error handling code to separate method,HEART,2018-01-25T11:32:59Z,Enet4,NA https://github.com/rust-lang/rust/pull/42588,MERGED,2017-06-11T02:45:55Z,2017-08-27T12:53:47Z,Make unused-extern-crate warn-by-default,ishitatsuyuki,a91bdf4ad558b3cf7b2a0230df15d83a6a686397,1,Update Cargo submodule,THUMBS_UP,2017-08-30T23:07:08Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/42588,MERGED,2017-06-11T02:45:55Z,2017-08-27T12:53:47Z,Make unused-extern-crate warn-by-default,ishitatsuyuki,a91bdf4ad558b3cf7b2a0230df15d83a6a686397,1,Update Cargo submodule,HOORAY,2017-08-31T08:16:20Z,cristicbz,NA https://github.com/rust-lang/rust/pull/42593,MERGED,2017-06-11T13:27:42Z,2017-06-18T15:09:02Z,Implement lazy loading of external crates' sources.,ibabushkin,bd4fe454050fa6ac8c74bc1ee70e0b4b909d245e,4,External spans: Added a test for #38875. A bug has been discovered and fixed in the process.,THUMBS_UP,2017-06-11T22:40:45Z,jseyfried,NA https://github.com/rust-lang/rust/pull/42620,MERGED,2017-06-13T00:47:10Z,2017-06-21T18:22:05Z,Add compile_error!,wesleywiser,2bec12f03695792998dbbb79bcee02ecfe0cf8f1,1,Add compile_error!() to the unsable book,HOORAY,2017-06-29T14:48:42Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42620,MERGED,2017-06-13T00:47:10Z,2017-06-21T18:22:05Z,Add compile_error!,wesleywiser,2bec12f03695792998dbbb79bcee02ecfe0cf8f1,1,Add compile_error!() to the unsable book,HOORAY,2017-06-29T16:40:58Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/42631,MERGED,2017-06-13T14:04:25Z,2017-06-16T10:08:10Z,Add a travis builder for wasm32-unknown-emscripten,malbarbo,9da77b3ec5dd99c50629005480323e6684957409,3,Disable wasm32 image,HOORAY,2017-06-13T14:14:31Z,est31,NA https://github.com/rust-lang/rust/pull/42637,CLOSED,2017-06-13T19:38:51Z,2017-08-01T20:54:01Z,Add String::parse_into.,clarfonthey,NA,NA,NA,CONFUSED,2017-07-19T17:54:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42649,MERGED,2017-06-13T23:28:28Z,2017-06-17T19:29:14Z,Report error for assignment in `if` condition,estebank,da78b4d88e1ba4598428a92a6c8d5f9c399fede0,5,Review comments - exhaustive match - rename method to `check_expr_meets_expectation_or_error` - formatting - add `delay_span_bug` - add test,HEART,2017-06-21T14:38:52Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/42649,MERGED,2017-06-13T23:28:28Z,2017-06-17T19:29:14Z,Report error for assignment in `if` condition,estebank,da78b4d88e1ba4598428a92a6c8d5f9c399fede0,5,Review comments - exhaustive match - rename method to `check_expr_meets_expectation_or_error` - formatting - add `delay_span_bug` - add test,HEART,2017-06-21T18:39:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42649,MERGED,2017-06-13T23:28:28Z,2017-06-17T19:29:14Z,Report error for assignment in `if` condition,estebank,da78b4d88e1ba4598428a92a6c8d5f9c399fede0,5,Review comments - exhaustive match - rename method to `check_expr_meets_expectation_or_error` - formatting - add `delay_span_bug` - add test,HEART,2017-06-22T01:44:16Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/42649,MERGED,2017-06-13T23:28:28Z,2017-06-17T19:29:14Z,Report error for assignment in `if` condition,estebank,da78b4d88e1ba4598428a92a6c8d5f9c399fede0,5,Review comments - exhaustive match - rename method to `check_expr_meets_expectation_or_error` - formatting - add `delay_span_bug` - add test,HEART,2017-06-24T13:52:21Z,hoodie,NA https://github.com/rust-lang/rust/pull/42659,MERGED,2017-06-14T18:56:01Z,2017-06-17T13:32:24Z,Issue 42545 type inference regression,nikomatsakis,9fec4093df1b31a3d63100922136e7bfb53c0d26,3,register the obligations from `wf::implied_bounds` Fixes #42552. Fixes #42545.,HOORAY,2017-06-14T20:18:48Z,kennytm,NA https://github.com/rust-lang/rust/pull/42660,MERGED,2017-06-14T19:49:26Z,2017-06-17T09:28:59Z,update book with redirect fixes,steveklabnik,15ace49d2e082a6e4e54deff2b436a2fc120637d,1,update book with redirect fixes Fixes #42632,HEART,2017-06-14T19:53:30Z,carols10cents,NA https://github.com/rust-lang/rust/pull/42661,MERGED,2017-06-14T19:52:44Z,2017-06-18T17:29:55Z,[beta] update book with redirect fixes,steveklabnik,cba129b6f8ffcd0634099d66a28e691b696ffb5f,1,update book with redirect fixes Backport of #42660,THUMBS_UP,2017-06-17T11:11:30Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/42664,MERGED,2017-06-14T22:34:12Z,2017-06-21T08:44:40Z,Remove in-tree flate/getopts crates,alexcrichton,5c3d0e6de3ed0d3506cb70737b348ea2113c70d8,14,Switch to the crates.io `getopts` crate This commit deletes the in-tree `getopts` crate in favor of the crates.io-based `getopts` crate. The main difference here is with a new builder-style API but otherwise everything else remains relatively standard.,THUMBS_UP,2017-06-14T22:43:01Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42664,MERGED,2017-06-14T22:34:12Z,2017-06-21T08:44:40Z,Remove in-tree flate/getopts crates,alexcrichton,5c3d0e6de3ed0d3506cb70737b348ea2113c70d8,14,Switch to the crates.io `getopts` crate This commit deletes the in-tree `getopts` crate in favor of the crates.io-based `getopts` crate. The main difference here is with a new builder-style API but otherwise everything else remains relatively standard.,HEART,2017-06-14T22:58:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42664,MERGED,2017-06-14T22:34:12Z,2017-06-21T08:44:40Z,Remove in-tree flate/getopts crates,alexcrichton,5c3d0e6de3ed0d3506cb70737b348ea2113c70d8,14,Switch to the crates.io `getopts` crate This commit deletes the in-tree `getopts` crate in favor of the crates.io-based `getopts` crate. The main difference here is with a new builder-style API but otherwise everything else remains relatively standard.,THUMBS_UP,2017-06-14T22:58:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42664,MERGED,2017-06-14T22:34:12Z,2017-06-21T08:44:40Z,Remove in-tree flate/getopts crates,alexcrichton,5c3d0e6de3ed0d3506cb70737b348ea2113c70d8,14,Switch to the crates.io `getopts` crate This commit deletes the in-tree `getopts` crate in favor of the crates.io-based `getopts` crate. The main difference here is with a new builder-style API but otherwise everything else remains relatively standard.,HOORAY,2017-06-15T19:53:56Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42664,MERGED,2017-06-14T22:34:12Z,2017-06-21T08:44:40Z,Remove in-tree flate/getopts crates,alexcrichton,5c3d0e6de3ed0d3506cb70737b348ea2113c70d8,14,Switch to the crates.io `getopts` crate This commit deletes the in-tree `getopts` crate in favor of the crates.io-based `getopts` crate. The main difference here is with a new builder-style API but otherwise everything else remains relatively standard.,THUMBS_UP,2017-06-16T15:36:50Z,est31,NA https://github.com/rust-lang/rust/pull/42669,MERGED,2017-06-15T06:52:00Z,2017-07-01T00:34:16Z,Adding diagnostic code 0621 for lifetime errors with one named one anonymous lifetime parameter,gaurikholkar,37a88f478dd80404b7b8c3890db96f5850ecd7bf,1,rename compile-fail test,HOORAY,2017-06-15T08:56:33Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HEART,2017-06-15T20:46:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HEART,2017-06-16T09:19:19Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HEART,2017-06-16T11:34:02Z,killercup,NA https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HEART,2017-06-21T13:58:02Z,est31,NA https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HOORAY,2017-06-29T14:47:26Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42682,MERGED,2017-06-15T18:40:35Z,2017-06-22T02:56:20Z,Integrate jobserver support to parallel codegen,alexcrichton,201f06988fb77c9865b0ddc60a8d7b5701c6dbbe,19,Integrate jobserver support to parallel codegen This commit integrates the `jobserver` crate into the compiler. The crate was previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose here is to two-fold: * Primarily the compiler can cooperate with Cargo on parallelism. When you run `cargo build -j4` then this'll make sure that the entire build process between Cargo/rustc won't use more than 4 cores whereas today you'd get 4 rustc instances which may all try to spawn lots of threads. * Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver. This means that if you call cargo/rustc from `make` or another jobserver-compatible implementation it'll use foreign parallelism settings instead of creating new ones locally. As the number of parallel codegen instances in the compiler continues to grow over time with the advent of incremental compilation it's expected that this'll become more of a problem so this is intended to nip concurrent concerns in the bud by having all the tools to cooperate! Note that while rustc has support for itself creating a jobserver it's far more likely that rustc will always use the jobserver configured by Cargo. Cargo today will now set a jobserver unconditionally for rustc to use.,HEART,2017-10-10T22:20:34Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2017-06-20T19:20:25Z,durka,NA https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2017-06-27T23:18:20Z,est31,NA https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2017-06-28T15:07:04Z,blakepettersson,NA https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2017-07-06T11:46:00Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,THUMBS_UP,2017-07-06T11:46:03Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2017-12-01T21:06:54Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2019-01-06T20:32:54Z,Emerentius,NA https://github.com/rust-lang/rust/pull/42684,CLOSED,2017-06-15T19:52:44Z,2017-07-10T20:20:11Z,Add ‘#[serial]’ tests (v2),shivjm,NA,NA,NA,HEART,2021-09-07T12:39:11Z,relique,NA https://github.com/rust-lang/rust/pull/42687,MERGED,2017-06-15T21:05:11Z,2017-06-24T07:04:22Z,rustc: Enable #[thread_local] for Windows,alexcrichton,06540cb205545e5e7e509933af27142ca35eae17,7,rustc: Enable #[thread_local] for Windows I think LLVM has had support for quite some time now for this we just never got around to testing it out and binding it. We've had some trouble landing this in the past I believe but it's time to try again! This commit flags the `#[thread_local]` attribute as being available for Windows targets and adds an implementation of `register_dtor` in the `thread::local` module to ensure we can destroy these keys. The same functionality is implemented in clang via a function called `__tlregdtor` (presumably provided in some Windows runtime somewhere) but this function unfortunately does not take a data pointer (just a thunk) which means we can't easily call it. For now destructors are just run in the same way the Linux fallback is implemented which is just keeping track via a single OS-based TLS key.,THUMBS_UP,2017-06-29T14:58:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42705,MERGED,2017-06-16T18:05:03Z,2017-06-17T09:29:01Z,Introduce tidy lint to check for inconsistent tracking issues,est31,c6afde6c46d167c9c75389b887f1d2498aeef3e4,11,Introduce tidy lint to check for inconsistent tracking issues This commit * Refactors the collect_lib_features function to work in a non-checking mode (no bad pointer needed and list of lang features). * Introduces checking whether unstable/stable tags for a given feature have inconsistent tracking issues. * Fixes such inconsistencies throughout the codebase.,HEART,2017-06-16T19:03:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/42723,MERGED,2017-06-17T20:16:31Z,2017-06-18T19:45:48Z,Add `_` to the list of keywords,strega-nil,723772fc556506d5357273e7f84b677e7c62bc96,1,Add `_` to the list of keywords also make sure the keyword table is correctly spaced,THUMBS_UP,2017-06-17T20:25:42Z,est31,NA https://github.com/rust-lang/rust/pull/42723,MERGED,2017-06-17T20:16:31Z,2017-06-18T19:45:48Z,Add `_` to the list of keywords,strega-nil,723772fc556506d5357273e7f84b677e7c62bc96,1,Add `_` to the list of keywords also make sure the keyword table is correctly spaced,THUMBS_UP,2017-06-17T20:43:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42724,MERGED,2017-06-17T23:00:56Z,2017-06-24T09:32:30Z,Add tests for a few issues.,Mark-Simulacrum,2346169f999043a1e9b46e6e5206a82c970f1c21,12,Add tests for a few issues.,HEART,2017-06-17T23:42:23Z,est31,NA https://github.com/rust-lang/rust/pull/42724,MERGED,2017-06-17T23:00:56Z,2017-06-24T09:32:30Z,Add tests for a few issues.,Mark-Simulacrum,2346169f999043a1e9b46e6e5206a82c970f1c21,12,Add tests for a few issues.,HEART,2017-06-18T13:35:39Z,killercup,NA https://github.com/rust-lang/rust/pull/42724,MERGED,2017-06-17T23:00:56Z,2017-06-24T09:32:30Z,Add tests for a few issues.,Mark-Simulacrum,2346169f999043a1e9b46e6e5206a82c970f1c21,12,Add tests for a few issues.,HEART,2017-06-23T20:44:48Z,brson,NA https://github.com/rust-lang/rust/pull/42724,MERGED,2017-06-17T23:00:56Z,2017-06-24T09:32:30Z,Add tests for a few issues.,Mark-Simulacrum,2346169f999043a1e9b46e6e5206a82c970f1c21,12,Add tests for a few issues.,HEART,2017-06-23T22:04:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HOORAY,2017-06-18T02:28:38Z,est31,NA https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HEART,2017-06-18T02:28:40Z,est31,NA https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HOORAY,2017-06-18T09:48:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HOORAY,2017-06-18T21:29:55Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HOORAY,2017-06-20T15:22:51Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HEART,2017-06-20T15:22:58Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HOORAY,2017-06-21T17:36:02Z,csssuf,NA https://github.com/rust-lang/rust/pull/42727,MERGED,2017-06-18T01:53:19Z,2017-07-06T02:34:27Z,rustc: Implement the #[global_allocator] attribute,alexcrichton,695dee063bcd40f154bb27b7beafcb3d4dd775ac,115,rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented allowing much more freedom in terms of how this feature is implemented. cc #27389,HEART,2017-08-09T21:34:34Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42728,MERGED,2017-06-18T06:38:56Z,2017-06-21T00:06:09Z,resolve: fix perf bug,jseyfried,3c1af32abbee806abb0fa16cddfbb268e5816fd8,1,resolve: fix perf bug.,HOORAY,2017-06-18T13:15:14Z,retep998,NA https://github.com/rust-lang/rust/pull/42728,MERGED,2017-06-18T06:38:56Z,2017-06-21T00:06:09Z,resolve: fix perf bug,jseyfried,3c1af32abbee806abb0fa16cddfbb268e5816fd8,1,resolve: fix perf bug.,THUMBS_UP,2017-06-29T14:46:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42740,MERGED,2017-06-18T17:21:40Z,2017-06-19T03:42:37Z,Backport fixes to LLVM 4.0 ARM codegen bugs,arielb1,207951b1699e426829296721adf668117294a580,2,Backport fixes to LLVM 4.0 ARM codegen bugs So ARM had quite a few codegen bugs on LLVM 4.0 which are fixed on LLVM trunk. This backports 5 of them: r297871 - ARM: avoid clobbering register in v6 jump-table expansion. - fixes rust-lang/rust#42248 r294949 - [Thumb-1] TBB generation: spot redefinitions of index r295816 - [ARM] Fix constant islands pass. r300870 - [Thumb-1] Fix corner cases for compressed jump tables r302650 - [IfConversion] Add missing check in IfConversion/canFallThroughTo - unblocks rust-lang/rust#39409,HOORAY,2017-06-19T04:33:23Z,alevy,NA https://github.com/rust-lang/rust/pull/42750,MERGED,2017-06-19T14:03:49Z,2017-06-21T12:28:56Z,Update LLVM to pick StackColoring improvement,arielb1,4f1da874b860655c2054481821f6b99cfe6ff250,3,Update LLVM to pick StackColoring improvement Fixes #40883.,HEART,2017-06-19T15:20:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42750,MERGED,2017-06-19T14:03:49Z,2017-06-21T12:28:56Z,Update LLVM to pick StackColoring improvement,arielb1,4f1da874b860655c2054481821f6b99cfe6ff250,3,Update LLVM to pick StackColoring improvement Fixes #40883.,HEART,2017-06-19T20:43:05Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/42750,MERGED,2017-06-19T14:03:49Z,2017-06-21T12:28:56Z,Update LLVM to pick StackColoring improvement,arielb1,4f1da874b860655c2054481821f6b99cfe6ff250,3,Update LLVM to pick StackColoring improvement Fixes #40883.,HEART,2017-06-21T19:00:21Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/42751,MERGED,2017-06-19T15:47:30Z,2017-06-21T15:27:10Z,Memoize types in `is_representable` to avoid exponential worst-case,arielb1,ae8545bd146659f6ed4b063166e382da623bc6f8,2,Memoize types in `is_representable` to avoid exponential worst-case I could have made representability a cached query but that would have been added complexity for not much benefit - outside of the exponential worst-case this pass is fast enough already. Fixes #42747.,HEART,2017-06-19T16:07:31Z,estebank,NA https://github.com/rust-lang/rust/pull/42751,MERGED,2017-06-19T15:47:30Z,2017-06-21T15:27:10Z,Memoize types in `is_representable` to avoid exponential worst-case,arielb1,ae8545bd146659f6ed4b063166e382da623bc6f8,2,Memoize types in `is_representable` to avoid exponential worst-case I could have made representability a cached query but that would have been added complexity for not much benefit - outside of the exponential worst-case this pass is fast enough already. Fixes #42747.,HEART,2017-06-19T16:09:49Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42751,MERGED,2017-06-19T15:47:30Z,2017-06-21T15:27:10Z,Memoize types in `is_representable` to avoid exponential worst-case,arielb1,ae8545bd146659f6ed4b063166e382da623bc6f8,2,Memoize types in `is_representable` to avoid exponential worst-case I could have made representability a cached query but that would have been added complexity for not much benefit - outside of the exponential worst-case this pass is fast enough already. Fixes #42747.,HEART,2017-06-19T16:15:45Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/42751,MERGED,2017-06-19T15:47:30Z,2017-06-21T15:27:10Z,Memoize types in `is_representable` to avoid exponential worst-case,arielb1,ae8545bd146659f6ed4b063166e382da623bc6f8,2,Memoize types in `is_representable` to avoid exponential worst-case I could have made representability a cached query but that would have been added complexity for not much benefit - outside of the exponential worst-case this pass is fast enough already. Fixes #42747.,HEART,2017-06-19T18:17:52Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42751,MERGED,2017-06-19T15:47:30Z,2017-06-21T15:27:10Z,Memoize types in `is_representable` to avoid exponential worst-case,arielb1,ae8545bd146659f6ed4b063166e382da623bc6f8,2,Memoize types in `is_representable` to avoid exponential worst-case I could have made representability a cached query but that would have been added complexity for not much benefit - outside of the exponential worst-case this pass is fast enough already. Fixes #42747.,HEART,2017-06-20T10:35:39Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/42752,CLOSED,2017-06-19T15:54:45Z,2017-06-27T16:23:32Z,Support compiling rustc without LLVM,bjorn3,NA,NA,NA,HEART,2017-06-19T16:50:45Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42752,CLOSED,2017-06-19T15:54:45Z,2017-06-27T16:23:32Z,Support compiling rustc without LLVM,bjorn3,NA,NA,NA,HEART,2017-06-20T09:44:47Z,est31,NA https://github.com/rust-lang/rust/pull/42752,CLOSED,2017-06-19T15:54:45Z,2017-06-27T16:23:32Z,Support compiling rustc without LLVM,bjorn3,NA,NA,NA,HEART,2017-06-20T10:49:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/42756,MERGED,2017-06-19T19:45:39Z,2017-06-21T00:06:11Z,Show type name for unused_must_use lint,sanxiyn,05540bf08b067a6894937b3601cc2c66804615a6,2,Show type name for unused_must_use lint,HOORAY,2017-06-21T00:25:29Z,jethrogb,NA https://github.com/rust-lang/rust/pull/42766,MERGED,2017-06-20T06:56:18Z,2017-06-21T18:22:10Z,Update rls-data version,nrc,f2340a01461f9d6f9a6593d5290f1fc68f5139f1,1,Update RLS submod,HEART,2017-06-20T21:44:21Z,brson,NA https://github.com/rust-lang/rust/pull/42768,CLOSED,2017-06-20T09:51:20Z,2017-06-30T07:39:48Z,build more tools as part of `./x.py build`,Keruspe,NA,NA,NA,THUMBS_DOWN,2017-06-22T20:28:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/42769,CLOSED,2017-06-20T09:55:49Z,2017-07-04T15:09:12Z,incr.comp.: Introduce the concept of anonymous DepNodes and use them for trait selection,michaelwoerister,NA,NA,NA,HOORAY,2017-06-20T18:13:48Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42771,MERGED,2017-06-20T12:11:21Z,2017-06-22T00:32:52Z,mark calls in the unwind path as !noinline,arielb1,0b937989599392d42de0a792a91fa7bc0bc53f92,2,mark calls in the unwind path as !noinline The unwind path is always cold so that should not have bad performance implications. This avoids catastrophic exponential inlining and also decreases the size of librustc.so by 1.5% (OTOH the size of `libstd.so` increased by 0.5% for some reason). Fixes #41696.,HEART,2017-06-20T15:28:43Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/42777,MERGED,2017-06-20T18:19:16Z,2017-06-23T16:16:00Z,"Remove most ""```ignore"" doc tests.",kennytm,9addd3ba657e0d37c3fa5296262474db91d26d8f,1,"Added a tidy check to disallow ""```ignore"" and ""```rust ignore"".",HEART,2017-06-20T20:29:29Z,killercup,NA https://github.com/rust-lang/rust/pull/42777,MERGED,2017-06-20T18:19:16Z,2017-06-23T16:16:00Z,"Remove most ""```ignore"" doc tests.",kennytm,9addd3ba657e0d37c3fa5296262474db91d26d8f,1,"Added a tidy check to disallow ""```ignore"" and ""```rust ignore"".",HEART,2017-06-21T00:03:48Z,estebank,NA https://github.com/rust-lang/rust/pull/42777,MERGED,2017-06-20T18:19:16Z,2017-06-23T16:16:00Z,"Remove most ""```ignore"" doc tests.",kennytm,9addd3ba657e0d37c3fa5296262474db91d26d8f,1,"Added a tidy check to disallow ""```ignore"" and ""```rust ignore"".",HEART,2017-06-21T00:07:51Z,sinkuu,NA https://github.com/rust-lang/rust/pull/42777,MERGED,2017-06-20T18:19:16Z,2017-06-23T16:16:00Z,"Remove most ""```ignore"" doc tests.",kennytm,9addd3ba657e0d37c3fa5296262474db91d26d8f,1,"Added a tidy check to disallow ""```ignore"" and ""```rust ignore"".",HEART,2017-06-22T06:14:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42777,MERGED,2017-06-20T18:19:16Z,2017-06-23T16:16:00Z,"Remove most ""```ignore"" doc tests.",kennytm,9addd3ba657e0d37c3fa5296262474db91d26d8f,1,"Added a tidy check to disallow ""```ignore"" and ""```rust ignore"".",HEART,2017-06-22T22:27:54Z,brson,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-21T00:06:00Z,estebank,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-21T04:24:59Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-21T09:23:42Z,alexbool,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-21T23:19:12Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-22T02:45:22Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-23T17:13:41Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-26T06:31:35Z,Stebalien,steven@stebalien.com https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-27T17:30:43Z,bluss,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-06-29T01:49:54Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-07-05T13:15:10Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-07-05T15:58:58Z,Scetch,me@scet.ch https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-07-05T18:35:48Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-07-06T16:42:51Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2017-07-29T20:53:24Z,raindev,andrew@raindev.io https://github.com/rust-lang/rust/pull/42782,MERGED,2017-06-20T22:39:04Z,2017-06-30T11:42:11Z,Add `Iterator::for_each`,cuviper,e72ee6e4ad0511aaf533a492382b84dfa712393f,1,Use a little more compelling example of `for_each`,THUMBS_UP,2019-02-11T03:38:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42806,MERGED,2017-06-21T17:17:12Z,2017-06-22T15:25:12Z,rustbuild: Fix compiler docs yet again,ollie27,ae1dc2a6f902cea5b6e833497b11d8860acabfd9,3,rustbuild: Fix compiler docs yet again Add support for `-Z force-unstable-if-unmarked` to rustdoc.,THUMBS_UP,2017-06-21T17:21:56Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HEART,2017-06-21T21:26:43Z,est31,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-06-21T23:23:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-06-21T23:49:55Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-06-22T00:58:10Z,durka,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HEART,2017-07-06T21:52:24Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HEART,2017-07-12T14:58:36Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-12T14:58:37Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-12T16:40:53Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-12T17:39:35Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-12T21:47:37Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-13T04:47:02Z,michaelwu,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-17T18:48:51Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-07-25T19:42:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HOORAY,2017-08-29T07:46:03Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/42809,MERGED,2017-06-21T19:32:19Z,2017-07-07T21:15:33Z,remove associated_consts feature gate,seanmonstar,74b2d693589add69cf03588ae0eb336c1be7d52b,87,remove associated_consts feature gate,HEART,2017-08-29T07:46:07Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T02:52:26Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T05:58:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T06:57:30Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T08:24:22Z,est31,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T09:15:08Z,Keruspe,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T11:33:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T16:05:52Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T17:49:48Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T18:38:29Z,lqd,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-06-22T18:44:46Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T18:55:39Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-22T19:10:57Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-06-25T17:14:26Z,iamcodemaker,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-25T17:14:26Z,iamcodemaker,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-06-26T16:22:57Z,GrahamBest,grahambest3867@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-06-26T16:22:57Z,GrahamBest,grahambest3867@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-06-27T19:23:31Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-05T10:42:25Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-07-05T10:42:27Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-06T01:08:51Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-06T15:56:13Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-07T21:55:14Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-07-07T21:55:31Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-07-08T12:55:52Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-08T15:50:59Z,johnthagen,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-10T05:11:13Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-07-10T05:11:14Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-12T13:58:35Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-07-12T17:33:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2017-07-24T05:16:56Z,vmchale,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-09-02T01:45:43Z,mister-walter,mist3rwalter@gmail.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2017-09-06T06:16:23Z,SplittyDev,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2018-04-16T08:54:20Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HOORAY,2018-05-29T10:08:29Z,xerz-one,NA https://github.com/rust-lang/rust/pull/42816,MERGED,2017-06-22T01:38:52Z,2017-07-06T19:51:37Z,rustc: Implement stack probes for x86,alexcrichton,5dbd97de3d825c6898df62baca33ff1f57cb77eb,32,rustc: Implement stack probes for x86 This commit implements stack probes on x86/x86_64 using the freshly landed support upstream in LLVM. The purpose of stack probes here are to guarantee a segfault on stack overflow rather than having a chance of running over the guard page already present on all threads by accident. At this time there's no support for any other architecture because LLVM itself does not have support for other architectures.,HEART,2020-07-06T03:37:19Z,jjyr,jjyruby@gmail.com https://github.com/rust-lang/rust/pull/42837,MERGED,2017-06-22T20:12:34Z,2017-07-19T00:35:35Z,Update docs on Error struct. #29355,rthomas,aca6cd052d51a16f09b1e9a6051a746d0ff2ce85,1,Update docs on Error struct. #29355 This adds a pretty contrived example of the usage of fmt::Error. I am very open to suggestions for a better one. I have also highlighted the fmt::Error vs std::error::Error. r? @steveklabnik,THUMBS_UP,2017-07-16T20:41:17Z,Others,NA https://github.com/rust-lang/rust/pull/42850,MERGED,2017-06-23T04:45:22Z,2017-06-28T22:43:11Z,Detect missing `;` on methods with return type `()`,estebank,7dad2958be59801881fb3db7544de423420dabd0,3,Review comments - Fix typo - Add docstring - Remove spurious test output file,HOORAY,2017-06-23T06:39:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/42850,MERGED,2017-06-23T04:45:22Z,2017-06-28T22:43:11Z,Detect missing `;` on methods with return type `()`,estebank,7dad2958be59801881fb3db7544de423420dabd0,3,Review comments - Fix typo - Add docstring - Remove spurious test output file,HOORAY,2017-06-23T12:07:17Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42850,MERGED,2017-06-23T04:45:22Z,2017-06-28T22:43:11Z,Detect missing `;` on methods with return type `()`,estebank,7dad2958be59801881fb3db7544de423420dabd0,3,Review comments - Fix typo - Add docstring - Remove spurious test output file,THUMBS_UP,2017-06-28T17:06:47Z,Fleshgrinder,NA https://github.com/rust-lang/rust/pull/42850,MERGED,2017-06-23T04:45:22Z,2017-06-28T22:43:11Z,Detect missing `;` on methods with return type `()`,estebank,7dad2958be59801881fb3db7544de423420dabd0,3,Review comments - Fix typo - Add docstring - Remove spurious test output file,THUMBS_UP,2017-07-05T18:40:18Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T14:54:36Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T14:59:09Z,kennytm,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:00:51Z,malbarbo,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:01:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:11:30Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:11:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:53:15Z,alexbool,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T15:58:11Z,cramertj,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T16:13:27Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T16:24:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T16:33:00Z,ranma42,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T16:38:10Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T17:35:00Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T17:41:40Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T17:43:19Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T17:45:11Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T17:46:49Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T19:23:11Z,jonthn,jonthn+github@pinacea.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T19:56:03Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-23T23:04:51Z,retep998,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-24T03:41:07Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-24T06:16:03Z,toshipp,toshiq2@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-26T07:15:23Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-26T22:12:27Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-28T20:16:36Z,alevy,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-06-29T06:19:44Z,topaxi,damian.senn@topaxi.codes https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-03T02:33:18Z,durka,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-07T19:39:17Z,zmarcantel,zmarcantel@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-13T22:57:39Z,fafhrd91,fafhrd91@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T00:19:30Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T01:19:40Z,delacian,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T03:29:48Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T06:29:59Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T11:19:12Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T14:11:16Z,gabdube,gdube.475@gmail.com https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-26T16:51:26Z,plietar,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-07-27T15:47:49Z,bluss,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2017-08-14T15:13:51Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2018-04-14T17:45:27Z,hcpl,NA https://github.com/rust-lang/rust/pull/42859,MERGED,2017-06-23T14:52:09Z,2017-07-19T20:12:54Z,Implement const fn {size align}_of.,eddyb,148718b4f32b46a96e339be92102697ad58b170b,8,Implement const fn {size align}_of.,HOORAY,2022-01-23T22:57:21Z,AaronRecord,aaronjrecord@gmail.com https://github.com/rust-lang/rust/pull/42883,CLOSED,2017-06-24T15:21:43Z,2017-08-08T09:36:30Z,Rewrite mpsc::shared,stepancheg,NA,NA,NA,HOORAY,2021-09-13T14:17:13Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/42894,MERGED,2017-06-25T12:56:39Z,2017-07-08T04:22:46Z,Make sufficiently old or low-impact compatibility lints deny-by-default,petrochenkov,9196f874e4003bf766288c82ee857a7fa2588d8a,4,Make `patterns_in_fns_without_body` warn-by-default again Fix some tests on Linux,THUMBS_UP,2017-06-26T14:43:37Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/42899,MERGED,2017-06-25T17:55:00Z,2017-07-06T04:50:27Z,Switch to rust-lang-nursery/compiler-builtins,alexcrichton,7e6c9f363501c49d3a1f666d85d41891f50890b8,25,Switch to rust-lang-nursery/compiler-builtins This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.,HOORAY,2017-06-25T18:07:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42899,MERGED,2017-06-25T17:55:00Z,2017-07-06T04:50:27Z,Switch to rust-lang-nursery/compiler-builtins,alexcrichton,7e6c9f363501c49d3a1f666d85d41891f50890b8,25,Switch to rust-lang-nursery/compiler-builtins This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.,HOORAY,2017-06-26T06:13:57Z,est31,NA https://github.com/rust-lang/rust/pull/42899,MERGED,2017-06-25T17:55:00Z,2017-07-06T04:50:27Z,Switch to rust-lang-nursery/compiler-builtins,alexcrichton,7e6c9f363501c49d3a1f666d85d41891f50890b8,25,Switch to rust-lang-nursery/compiler-builtins This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.,HOORAY,2017-06-26T15:25:05Z,kennytm,NA https://github.com/rust-lang/rust/pull/42899,MERGED,2017-06-25T17:55:00Z,2017-07-06T04:50:27Z,Switch to rust-lang-nursery/compiler-builtins,alexcrichton,7e6c9f363501c49d3a1f666d85d41891f50890b8,25,Switch to rust-lang-nursery/compiler-builtins This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.,HOORAY,2017-07-06T00:30:47Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/42899,MERGED,2017-06-25T17:55:00Z,2017-07-06T04:50:27Z,Switch to rust-lang-nursery/compiler-builtins,alexcrichton,7e6c9f363501c49d3a1f666d85d41891f50890b8,25,Switch to rust-lang-nursery/compiler-builtins This commit migrates the in-tree `libcompiler_builtins` to the upstream version at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version has a number of intrinsics written in Rust and serves as an in-progress rewrite of compiler-rt into Rust. Additionally it also contains all the existing intrinsics defined in `libcompiler_builtins` for 128-bit integers. It's been the intention since the beginning to make this transition but previously it just lacked the manpower to get done. As this PR likely shows it wasn't a trivial integration! Some highlight changes are: * The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes across platforms and also some refactorings to make the intrinsics easier to read. The additional testing added there also fixed a number of integration issues when pulling the repository into this tree. * LTO with the compiler-builtins crate was fixed to link in the entire crate after the LTO process as these intrinsics are excluded from LTO. * Treatment of hidden symbols was updated as previously the `#![compiler_builtins]` crate would mark all symbol *imports* as hidden whereas it was only intended to mark *exports* as hidden.,HOORAY,2017-07-06T15:56:02Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/42900,MERGED,2017-06-25T17:59:22Z,2017-06-29T22:31:13Z,Stop disabling fill in jemalloc,sfackler,8aa39ad3d8a104b4676186df959cc4b248495381,1,Stop disabling fill in jemalloc The underlying bug has been fixed for over 2 years!,LAUGH,2017-07-05T09:44:56Z,Stargateur,NA https://github.com/rust-lang/rust/pull/42905,MERGED,2017-06-25T21:27:00Z,2017-06-27T07:30:00Z,Reword OsStr docs to clarify that utf8 may contain nulls,casey,0d985c9e8760da77b0df8920465700728e2da4f1,1,Reword OsStr docs to clarify that utf8 may contain nulls,THUMBS_UP,2017-06-26T00:17:36Z,Ixrec,NA https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2017-06-26T18:24:19Z,durka,NA https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2017-07-11T08:17:51Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2017-07-19T21:32:37Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2017-07-20T12:34:14Z,CasualX,NA https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2017-10-09T23:22:28Z,bluss,NA https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2018-04-08T05:25:44Z,hcpl,NA https://github.com/rust-lang/rust/pull/42913,MERGED,2017-06-26T15:52:01Z,2017-07-11T06:26:39Z,Only match a fragment specifier if it starts with certain tokens.,kennytm,600800480a750978a5ed6d29188056e950ae2075,4,Only match a fragment specifier the if it starts with certain tokens. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.,HEART,2018-10-26T18:49:05Z,estebank,NA https://github.com/rust-lang/rust/pull/42919,MERGED,2017-06-26T23:14:37Z,2017-06-29T11:13:50Z,make lint on-by-default/implied-by messages appear only once,zackmdavis,32b8579b6826091e11ea6d90a2d64f4975894032,5,make lint on-by-default/implied-by messages appear only once From review discussion on #38103 (https://github.com/rust-lang/rust/pull/38103#discussion_r94845060).,LAUGH,2017-06-28T20:55:07Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/42924,MERGED,2017-06-27T09:04:21Z,2017-06-30T06:18:03Z,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.,pnkfelix,13cd022060316146474915664a9e019906a2c79a,13,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate. Turn `elaborate_drops` and `rustc_peek` implementations into MIR passes that also live in `rustc_mir` crate. Rewire things so `rustc_driver` uses the `ElaborateDrops` from `rustc_mir` crate.,THUMBS_UP,2017-06-27T13:47:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42924,MERGED,2017-06-27T09:04:21Z,2017-06-30T06:18:03Z,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.,pnkfelix,13cd022060316146474915664a9e019906a2c79a,13,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate. Turn `elaborate_drops` and `rustc_peek` implementations into MIR passes that also live in `rustc_mir` crate. Rewire things so `rustc_driver` uses the `ElaborateDrops` from `rustc_mir` crate.,HOORAY,2017-07-05T15:28:54Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42924,MERGED,2017-06-27T09:04:21Z,2017-06-30T06:18:03Z,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.,pnkfelix,13cd022060316146474915664a9e019906a2c79a,13,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate. Turn `elaborate_drops` and `rustc_peek` implementations into MIR passes that also live in `rustc_mir` crate. Rewire things so `rustc_driver` uses the `ElaborateDrops` from `rustc_mir` crate.,THUMBS_UP,2017-07-05T18:33:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42924,MERGED,2017-06-27T09:04:21Z,2017-06-30T06:18:03Z,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.,pnkfelix,13cd022060316146474915664a9e019906a2c79a,13,Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate. Turn `elaborate_drops` and `rustc_peek` implementations into MIR passes that also live in `rustc_mir` crate. Rewire things so `rustc_driver` uses the `ElaborateDrops` from `rustc_mir` crate.,THUMBS_UP,2017-07-10T08:04:33Z,torpak,arne@gtnw.de https://github.com/rust-lang/rust/pull/42925,MERGED,2017-06-27T10:10:53Z,2017-07-01T00:34:21Z,Document possible `io::ErrorKind`s of `fs::open`,tbu-,2783d0f7dac17f764c6580a04877e6813be574d2,1,Add links to the `ErrorKind` variants in errors of `open`,HEART,2017-06-27T14:04:07Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/42930,MERGED,2017-06-27T15:12:40Z,2017-06-30T09:15:27Z,Rebase LLVM on top of LLVM 4.0.1,arielb1,0e6eecb4e5bd2a9c308617f5e0c3cdf43124a601,2,Rebase LLVM on top of LLVM 4.0.1 Fixes #42893.,HEART,2017-06-27T17:21:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42955,MERGED,2017-06-28T20:27:05Z,2017-06-29T11:13:53Z,Document that `/` works as separator on Windows,matklad,40dec0984ed2040532ac763f104b3bbbc13f514a,1,Document that `/` works as separator on Windows,THUMBS_UP,2017-06-28T21:11:48Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/42955,MERGED,2017-06-28T20:27:05Z,2017-06-29T11:13:53Z,Document that `/` works as separator on Windows,matklad,40dec0984ed2040532ac763f104b3bbbc13f514a,1,Document that `/` works as separator on Windows,THUMBS_UP,2017-06-28T21:32:35Z,Fleshgrinder,NA https://github.com/rust-lang/rust/pull/42957,MERGED,2017-06-28T22:02:49Z,2017-07-01T00:34:22Z,Add E0619 error explanation,GuillaumeGomez,162b5a347590a7dbc77d3281595b1bfaba98e3b1,4,Fix error codes mixup,LAUGH,2017-06-28T22:35:56Z,cramertj,NA https://github.com/rust-lang/rust/pull/42959,MERGED,2017-06-28T23:22:42Z,2017-07-26T23:40:49Z,"Make the ""main"" constructors of NonZero/Shared/Unique return Option",SimonSapin,0d1864b8cf9585e6133aa3da2b06b29cbfb791bd,1,Remove unnecessary unsafe in test/ui/print_type_sizes/nullable.rs,HOORAY,2017-06-29T05:04:14Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/42959,MERGED,2017-06-28T23:22:42Z,2017-07-26T23:40:49Z,"Make the ""main"" constructors of NonZero/Shared/Unique return Option",SimonSapin,0d1864b8cf9585e6133aa3da2b06b29cbfb791bd,1,Remove unnecessary unsafe in test/ui/print_type_sizes/nullable.rs,HOORAY,2017-07-02T06:33:54Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/42959,MERGED,2017-06-28T23:22:42Z,2017-07-26T23:40:49Z,"Make the ""main"" constructors of NonZero/Shared/Unique return Option",SimonSapin,0d1864b8cf9585e6133aa3da2b06b29cbfb791bd,1,Remove unnecessary unsafe in test/ui/print_type_sizes/nullable.rs,HOORAY,2017-07-11T15:12:21Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/42969,MERGED,2017-06-29T16:49:33Z,2017-06-30T22:15:06Z,mem_categorization: handle type-based paths in variant patterns,arielb1,1ea6813a61960dc89ceea95fe1cf7d3129aa8687,3,mem_categorization: handle type-based paths in variant patterns These can't be used in correct programs but must be handled in order to prevent ICEs. Fixes #42880.,THUMBS_UP,2017-06-29T23:19:42Z,estebank,NA https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-06-29T20:13:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-06-30T10:55:02Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-06-30T20:43:40Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-07-05T15:28:22Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-07-05T18:31:31Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/42971,MERGED,2017-06-29T18:33:18Z,2017-07-01T08:12:55Z,When writing LLVM IR output demangled fn name in comments,stepancheg,b62bdaafe038b8933fac5df5fa0fa5ddbaf176b7,6,"When writing LLVM IR output demangled fn name in comments `--emit=llvm-ir` looks like this now: ``` ; as core::ops::index::IndexMut>::index_mut ; Function Attrs: inlinehint uwtable define internal { i8* i64 } @""_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E""(%""alloc::vec::Vec""* dereferenceable(24)) unnamed_addr #0 { start: ... ``` cc https://github.com/integer32llc/rust-playground/issues/15",HEART,2017-07-06T10:51:32Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/42999,MERGED,2017-06-30T23:31:45Z,2017-07-03T19:34:00Z,[libstd_unicode] Upgrade to Unicode 10.0.0,behnam,a6994d7f3aed68f6a200fa6c48484924c4109c0b,1,[libstd_unicode] Upgrade to Unicode 10.0.0,THUMBS_UP,2017-08-31T19:15:11Z,arturparkhisenko,NA https://github.com/rust-lang/rust/pull/43001,MERGED,2017-07-01T00:13:09Z,2017-07-06T07:49:54Z,Add `rustc_on_unimplemented` message to `std::ops::Try`,estebank,d71caadee22f5a6cd1b16a8c6978efd4135707d0,3,Add `rustc_on_unimplemented` message to `std::ops::Try`,HOORAY,2017-07-12T12:05:48Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/43001,MERGED,2017-07-01T00:13:09Z,2017-07-06T07:49:54Z,Add `rustc_on_unimplemented` message to `std::ops::Try`,estebank,d71caadee22f5a6cd1b16a8c6978efd4135707d0,3,Add `rustc_on_unimplemented` message to `std::ops::Try`,HOORAY,2017-07-17T18:28:45Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-02T00:40:56Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-02T10:09:39Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-02T22:56:13Z,cramertj,NA https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-05T18:30:48Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-12T02:51:44Z,xilec,NA https://github.com/rust-lang/rust/pull/43010,MERGED,2017-07-02T00:15:05Z,2017-07-03T02:10:00Z,Stabilize feature sort_unstable,NA,NA,NA,NA,HOORAY,2017-07-21T00:24:12Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/43015,MERGED,2017-07-02T13:15:58Z,2017-07-02T15:40:35Z,report the total number of errors on compilation failure,arielb1,fb7ab9e43da3727e1c58faf9451857968270dc77,61,"report the total number of errors on compilation failure Prior to this PR when we aborted because a ""critical pass"" failed we displayed the number of errors from that critical pass. While that's the number of errors that caused compilation to abort in *that place* that's not what people really want to know. Instead always report the total number of errors and don't bother to track the number of errors from the last pass that failed. This changes the compiler driver API to handle errors more smoothly and therefore is a compiler-api-[breaking-change]. Fixes #42793.",HOORAY,2017-07-02T14:53:52Z,est31,NA https://github.com/rust-lang/rust/pull/43015,MERGED,2017-07-02T13:15:58Z,2017-07-02T15:40:35Z,report the total number of errors on compilation failure,arielb1,fb7ab9e43da3727e1c58faf9451857968270dc77,61,"report the total number of errors on compilation failure Prior to this PR when we aborted because a ""critical pass"" failed we displayed the number of errors from that critical pass. While that's the number of errors that caused compilation to abort in *that place* that's not what people really want to know. Instead always report the total number of errors and don't bother to track the number of errors from the last pass that failed. This changes the compiler driver API to handle errors more smoothly and therefore is a compiler-api-[breaking-change]. Fixes #42793.",HOORAY,2017-07-05T18:41:00Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-02T20:27:24Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-02T21:22:42Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-02T22:53:59Z,cramertj,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-02T23:31:09Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T00:21:52Z,fuine,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T07:11:32Z,mcarton,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T07:45:26Z,mzji,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T09:54:29Z,est31,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T13:51:44Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T15:58:49Z,simon-i1-h,shimon@postfixnotation.org https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T19:05:12Z,portal-chan,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-03T21:42:56Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-06T11:19:43Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-06T12:29:19Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-06T19:30:32Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-06T22:52:10Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-10T15:05:16Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-07-30T05:08:26Z,Cobrand,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-08-14T19:40:31Z,bluss,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-08-23T12:55:58Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-08-28T21:26:44Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-08-29T18:54:39Z,mr4x,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-09-06T17:05:00Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/43017,MERGED,2017-07-02T20:20:03Z,2017-09-16T19:54:57Z,Individualize feature gates for const fn invocation,durka,332c38cd70e372f56356e02b18b88919fcb58a66,2,bump rls,HOORAY,2017-10-29T11:27:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43026,MERGED,2017-07-03T14:44:53Z,2017-07-14T12:21:50Z,[LLVM] Avoid losing the !nonnull attribute in SROA,arielb1,ecf62e4cdcbe9fe59e2e1280739d15953cc0e500,3,[LLVM] Avoid losing the !nonnull attribute in SROA This still does not work on 32-bit archs because of an LLVM limitation but this is only an optimization so let's push it on 64-bit only for now. Fixes #37945,THUMBS_UP,2017-07-12T22:38:22Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43043,MERGED,2017-07-03T23:53:24Z,2017-07-04T18:26:55Z,Add a stability marker for core::cmp::Reverse.0,sfackler,dcd7c5f4e8356c786923f86dc544aff03fba29bb,1,Add a stability marker for core::cmp::Reverse.0 Closes #43027,THUMBS_UP,2017-07-04T02:13:43Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/43055,MERGED,2017-07-04T18:27:05Z,2017-07-17T03:03:31Z,Stabilize float_bits_conv for Rust 1.20,est31,010dea13eebfe0a7e2dce580d75f0f84325ed327,3,Stabilize float_bits_conv,THUMBS_UP,2017-07-04T18:57:38Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/43055,MERGED,2017-07-04T18:27:05Z,2017-07-17T03:03:31Z,Stabilize float_bits_conv for Rust 1.20,est31,010dea13eebfe0a7e2dce580d75f0f84325ed327,3,Stabilize float_bits_conv,HOORAY,2017-07-04T20:48:10Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43059,MERGED,2017-07-04T21:20:46Z,2017-07-22T20:55:35Z,Rework Rustbuild to an eagerly compiling approach,Mark-Simulacrum,1c118231adaa941899773420b21bc6b55ca3014f,2,Make distcheck work again.,HOORAY,2017-07-04T23:10:26Z,est31,NA https://github.com/rust-lang/rust/pull/43059,MERGED,2017-07-04T21:20:46Z,2017-07-22T20:55:35Z,Rework Rustbuild to an eagerly compiling approach,Mark-Simulacrum,1c118231adaa941899773420b21bc6b55ca3014f,2,Make distcheck work again.,HOORAY,2017-07-22T20:58:25Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43059,MERGED,2017-07-04T21:20:46Z,2017-07-22T20:55:35Z,Rework Rustbuild to an eagerly compiling approach,Mark-Simulacrum,1c118231adaa941899773420b21bc6b55ca3014f,2,Make distcheck work again.,HEART,2017-07-23T05:28:08Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43060,MERGED,2017-07-04T23:43:58Z,2017-07-07T12:54:54Z,syntax: Apply `x as usize < y` recovery to type ascription as well,petrochenkov,4323877e9202aa7a7fc2742d4863300e9abed17b,5,syntax: Apply recovery for casts to type ascription Fix spans add some comments,THUMBS_UP,2017-07-05T17:35:17Z,estebank,NA https://github.com/rust-lang/rust/pull/43062,MERGED,2017-07-05T06:47:58Z,2017-07-07T06:01:38Z,Implement TcpStream::connect_timeout,sfackler,8c92da3c518111b28f0b5fb297ab719bf353cdc6,6,"Implement TcpStream::connect_timeout This breaks the ""single syscall rule"" but it's really annoying to hand write and is pretty foundational.",HOORAY,2017-07-05T10:45:00Z,achanda,NA https://github.com/rust-lang/rust/pull/43062,MERGED,2017-07-05T06:47:58Z,2017-07-07T06:01:38Z,Implement TcpStream::connect_timeout,sfackler,8c92da3c518111b28f0b5fb297ab719bf353cdc6,6,"Implement TcpStream::connect_timeout This breaks the ""single syscall rule"" but it's really annoying to hand write and is pretty foundational.",HOORAY,2017-07-05T18:37:55Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/43067,MERGED,2017-07-05T14:33:18Z,2017-09-05T01:51:04Z,Compact display of static lib dependencies,kornelski,2354089ece7d03f997caf8a9f6ad99d235c8dacb,1,Minor compilation fix,THUMBS_UP,2017-07-05T14:35:52Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/43067,MERGED,2017-07-05T14:33:18Z,2017-09-05T01:51:04Z,Compact display of static lib dependencies,kornelski,2354089ece7d03f997caf8a9f6ad99d235c8dacb,1,Minor compilation fix,THUMBS_UP,2017-07-10T15:25:51Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/43067,MERGED,2017-07-05T14:33:18Z,2017-09-05T01:51:04Z,Compact display of static lib dependencies,kornelski,2354089ece7d03f997caf8a9f6ad99d235c8dacb,1,Minor compilation fix,HOORAY,2017-09-05T09:15:05Z,florianjacob,NA https://github.com/rust-lang/rust/pull/43072,MERGED,2017-07-05T19:25:37Z,2017-07-08T06:37:31Z,Skip the main thread's manual stack guard on Linux,cuviper,be509b3387aebb453b09a4942cf902c7d05a0f1e,1,"Skip the main thread's manual stack guard on Linux Linux doesn't allocate the whole stack right away and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard then the kernel starts enforcing a rather large gap above that rendering much of the possible stack space useless. Instead we'll just note where we expect rlimit to start faulting so our handler can report ""stack overflow"" and trust that the kernel's own stack guard will work. Fixes #43052.",HOORAY,2017-07-12T20:22:46Z,theduke,NA https://github.com/rust-lang/rust/pull/43074,MERGED,2017-07-05T20:56:56Z,2017-07-15T17:18:47Z,Forward more Iterator methods,SimonSapin,2007987099309e05c08d65e6a0e722c5ec1d0653,1,Forward more Iterator methods for iter::Rev `position` could not be implemented because calling `rposition` on the inner iterator would require more trait bounds.,HEART,2017-07-12T17:58:02Z,brson,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-05T21:42:22Z,kennytm,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-05T22:08:31Z,est31,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-05T22:09:00Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T01:42:07Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T04:58:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T08:33:03Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T11:26:56Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T15:55:29Z,killercup,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T16:30:51Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T21:15:08Z,kornholi,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-06T22:27:37Z,cramertj,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-08T13:01:26Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-08T18:01:37Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-09T07:50:36Z,stshine,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-09T09:00:29Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-09T17:36:46Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-09T20:46:31Z,mcarton,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-10T14:47:23Z,apasel422,apaseltiner@google.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-11T08:31:14Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-11T19:18:08Z,achanda,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-12T13:20:13Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-12T15:05:09Z,chpio,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-12T16:08:17Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-12T17:45:48Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-13T06:55:13Z,davll,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-13T20:18:34Z,ihrwein,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-14T00:38:50Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-14T00:38:54Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-15T01:35:37Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-15T04:53:13Z,zhuozhongcao,zhuozhongcao@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-15T10:04:40Z,ihrwein,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-15T14:17:00Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-15T18:33:58Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-16T03:45:11Z,Korvox,mel@nie.rs https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-16T03:45:16Z,Korvox,mel@nie.rs https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-16T14:11:11Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-16T14:11:12Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-17T14:59:29Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-17T14:59:29Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-19T07:42:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-07-25T04:47:45Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-07-31T10:39:13Z,manfredbrandl,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-01T05:06:32Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-02T00:52:56Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-03T10:53:06Z,yasammez,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-06T11:34:11Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-06T11:34:13Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-06T11:34:16Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-06T16:08:54Z,bash,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-06T18:57:36Z,rushmorem,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-06T18:57:41Z,rushmorem,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-07T23:13:37Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-08T08:30:41Z,futursolo,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-08T16:11:35Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-08T16:11:37Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-08T16:11:41Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-11T20:32:27Z,triptec,andreas@devil.se https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-11T20:32:31Z,triptec,andreas@devil.se https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-11T20:32:33Z,triptec,andreas@devil.se https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-14T11:17:55Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-16T11:14:50Z,FillZpp,fillzpp.pub@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-17T05:17:10Z,imkow,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-17T05:17:13Z,imkow,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-17T05:17:14Z,imkow,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-20T23:26:41Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-21T06:32:41Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-24T19:19:04Z,bluss,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-24T22:21:53Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-24T23:19:00Z,ashleysommer,ashleysommer@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-24T23:19:00Z,ashleysommer,ashleysommer@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-25T03:14:01Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-25T03:14:05Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-25T18:07:40Z,wenjin21,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-25T18:07:48Z,wenjin21,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-25T20:25:53Z,fluxxu,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-27T20:25:48Z,olivedae,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-28T19:36:13Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T19:36:13Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-28T19:36:13Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T22:04:57Z,xer0x,drew666@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T22:08:38Z,d-haxton,haxton.dc@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T22:29:51Z,dimfeld,daniel@imfeld.dev https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-28T22:49:22Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T22:49:23Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-28T22:49:26Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T22:51:36Z,phsilva,ph.silva@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-28T22:59:52Z,psl8,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T23:15:41Z,jtescher,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-28T23:15:44Z,jtescher,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-28T23:34:41Z,boehm-s,steven.boehm.dev@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-28T23:39:50Z,fungos,fungos@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T00:21:45Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T00:31:00Z,muminoff,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T00:34:03Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T01:03:24Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T01:13:10Z,coreh,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T01:29:23Z,QuantumGhost,obelisk.reg+git@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T01:29:25Z,QuantumGhost,obelisk.reg+git@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T01:54:47Z,cssivision,cssivision@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T03:18:20Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T03:39:58Z,newlife,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T03:46:31Z,as-com,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T04:09:29Z,histrio,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T04:47:56Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T05:59:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T06:53:45Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T06:53:48Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T07:01:43Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T07:01:45Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T07:01:46Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T07:38:00Z,Redrield,redrield@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T07:49:27Z,ennis,alex.bleron@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T09:03:15Z,SirHamlet,SirGamlet@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T09:06:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T09:58:37Z,Hammster,mail@hans-koch.me https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T10:08:16Z,aheart,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T10:40:28Z,repax,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T10:40:38Z,repax,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T11:04:38Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T11:04:40Z,JoeyAcc,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T12:29:43Z,ambaxter,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T12:29:44Z,ambaxter,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T12:29:46Z,ambaxter,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T12:45:56Z,zkbpkp,d.s.kolesnichenko@yandex.ru https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T12:45:57Z,zkbpkp,d.s.kolesnichenko@yandex.ru https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T12:46:00Z,zkbpkp,d.s.kolesnichenko@yandex.ru https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T13:15:04Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T13:46:12Z,azdle,patrick@psbarrett.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T14:40:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T18:05:53Z,NawfelBgh,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-29T21:20:51Z,aaronstgeorge-wf,aaron.stgeorge@workiva.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-29T22:07:50Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-29T23:38:15Z,futoase,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T00:29:40Z,thehydroimpulse,dnfagnan@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T00:29:41Z,thehydroimpulse,dnfagnan@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T02:40:47Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T02:40:48Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T02:40:49Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T02:58:47Z,huwsun,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T02:58:49Z,huwsun,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T02:58:51Z,huwsun,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T03:14:42Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T05:17:44Z,kenkoooo,kenkou.n@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T06:02:28Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T06:26:57Z,niconegoto,niconegoto@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T07:58:01Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T08:58:58Z,arunlakshman,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T11:09:56Z,creativcoder,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T11:19:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T11:19:36Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T14:07:47Z,gavinb,gavinb@antonym.org https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T14:12:47Z,sireliah,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T14:12:49Z,sireliah,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T14:12:50Z,sireliah,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T18:34:02Z,ruabmbua,roland.rucky@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T18:52:58Z,estin,tatarkin.evg@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T19:42:32Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T19:42:33Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T19:42:34Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-08-30T22:49:53Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-30T22:49:56Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-30T22:49:58Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-31T04:52:50Z,adekau,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-31T08:21:42Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-08-31T08:21:43Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-31T09:05:49Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-08-31T14:31:01Z,bryce-anderson,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-01T01:29:03Z,vincascm,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-02T12:07:57Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-09-02T14:36:02Z,raviqqe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-02T14:36:02Z,raviqqe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-09-02T14:36:03Z,raviqqe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-09-04T01:51:34Z,lynnux,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-04T01:51:56Z,lynnux,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-04T15:42:40Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-09-06T11:30:27Z,legokichi,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-09-11T04:48:57Z,gurry,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-11T04:48:59Z,gurry,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-12T01:20:22Z,tioover,tioover@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-09-13T02:42:19Z,intellild,intellild@outlook.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-09-13T02:42:20Z,intellild,intellild@outlook.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-09-13T02:42:22Z,intellild,intellild@outlook.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-09-19T23:33:11Z,hammett,hammett at gmail https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-10-21T14:10:36Z,vldm,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-11-28T11:53:00Z,daleione,guoyunlei@live.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2017-12-10T14:19:14Z,motss,contact@motss.app https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-12-10T14:19:14Z,motss,contact@motss.app https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2017-12-10T14:19:15Z,motss,contact@motss.app https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2017-12-21T20:10:47Z,wrmsr,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-01-03T09:02:26Z,Hellzed,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-01-06T20:39:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-01-08T18:33:06Z,JesseWright,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-01-08T18:33:07Z,JesseWright,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-01-31T21:08:31Z,fiws,me@fiws.net https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-01-31T21:08:32Z,fiws,me@fiws.net https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-02-08T18:57:42Z,halwa,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-02-20T16:37:32Z,dailypips,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-02-20T17:47:05Z,tjkirch,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-02-21T17:35:53Z,tathanhdinh,tathanhdinh@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-03-30T20:39:08Z,mbhavya,bhavyaaha@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-05-25T18:27:56Z,newswim,danminshew@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-05-25T18:27:56Z,newswim,danminshew@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-05-25T18:27:57Z,newswim,danminshew@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-06-15T00:50:35Z,silverlyra,lyra@hey.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-08-07T08:58:50Z,balta2ar,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-09-03T08:33:29Z,yetone,yetoneful@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-11-02T15:53:39Z,sidcool1234,sidd.kulk@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-11-02T15:53:42Z,sidcool1234,sidd.kulk@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2018-12-30T20:09:28Z,codedynamite,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2018-12-30T20:09:29Z,codedynamite,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2018-12-30T20:09:30Z,codedynamite,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2019-01-14T21:00:22Z,you-think-you-are-special,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2019-01-14T21:00:23Z,you-think-you-are-special,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2019-01-14T21:00:24Z,you-think-you-are-special,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2019-05-26T15:01:43Z,taiki-e,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2019-05-26T15:01:44Z,taiki-e,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2019-05-26T15:01:47Z,taiki-e,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2020-05-29T14:50:38Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2020-05-29T14:50:39Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2020-05-29T14:50:41Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,ROCKET,2020-05-29T14:50:43Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2021-04-14T09:15:47Z,Type1J,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2021-04-14T09:15:48Z,Type1J,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2021-04-14T09:15:48Z,Type1J,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,ROCKET,2021-04-14T09:15:49Z,Type1J,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2021-05-30T18:33:17Z,yakuri354,yakuri2006@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2021-05-30T18:33:18Z,yakuri354,yakuri2006@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2021-05-30T18:33:20Z,yakuri354,yakuri2006@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,ROCKET,2021-05-30T18:33:21Z,yakuri354,yakuri2006@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2021-09-08T13:50:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2021-09-08T13:50:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2021-09-08T13:50:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,THUMBS_UP,2021-12-22T23:08:29Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HOORAY,2021-12-22T23:08:37Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,HEART,2021-12-22T23:08:53Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/43076,MERGED,2017-07-05T21:22:31Z,2017-08-28T19:24:30Z,Generator support,Zoxc,a996d5eec70ba6733e23f2e56e762f58e60bb4ff,2,Tweak rls submodule again,ROCKET,2021-12-22T23:09:14Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/43083,MERGED,2017-07-06T07:05:56Z,2017-07-12T00:49:57Z,compilertest (UI test): Support custom normalization.,kennytm,34209b0eaaa41dd5630772c59e5d3f03624caed5,2,Merge ui/README.md into COMPILER_TESTS.md and describe how custom UI normalization works.,HOORAY,2017-07-06T17:50:29Z,estebank,NA https://github.com/rust-lang/rust/pull/43083,MERGED,2017-07-06T07:05:56Z,2017-07-12T00:49:57Z,compilertest (UI test): Support custom normalization.,kennytm,34209b0eaaa41dd5630772c59e5d3f03624caed5,2,Merge ui/README.md into COMPILER_TESTS.md and describe how custom UI normalization works.,THUMBS_UP,2017-07-06T19:05:20Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-06T13:24:43Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-06T13:36:25Z,retep998,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-06T13:43:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-06T13:57:48Z,durka,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-06T21:03:58Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-08T18:55:15Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/43086,CLOSED,2017-07-06T13:12:57Z,2017-07-24T14:32:22Z,Stabilize the inclusive_range lib feature,est31,NA,NA,NA,THUMBS_UP,2017-07-15T07:42:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43096,MERGED,2017-07-06T21:35:53Z,2017-07-23T23:26:21Z,Point at `:` when using it instead of `;`,estebank,e39bcecf79a6951f528b12b47ea671f9b0328bb3,3,Handle type ascription cases with a method call instead of a type,THUMBS_UP,2017-07-26T14:30:08Z,polachok,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-07-07T14:04:25Z,est31,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T14:04:27Z,est31,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-07-07T14:11:43Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T14:11:53Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T14:27:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T15:31:43Z,kennytm,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T16:06:40Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-07T20:58:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-07-07T20:58:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-08T05:43:57Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-08T10:10:29Z,Ixrec,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-09T02:34:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-07-09T09:03:04Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-09T09:03:05Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-10T22:35:53Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-07-17T01:07:41Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-07-17T01:07:42Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-08-01T02:53:54Z,tikue,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-08-05T10:19:30Z,wenjin21,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-08-23T06:45:08Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-08-24T03:48:35Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HOORAY,2017-08-24T07:19:50Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43108,MERGED,2017-07-07T13:57:51Z,2017-08-16T18:25:05Z,MIR borrow check (under debug flag),pnkfelix,8738a087ffc25f621237ca944538ef0f9b476fbc,1,Moved mir-borrowck pass down to where comments say it should be. Added two fixmes: The `SimplifyBranches` pass cannot stay where it is and `BorrowckMir` should be a query not a pass. But I am going to leave those changes to a future PR.,HEART,2017-08-24T07:19:51Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43116,MERGED,2017-07-08T04:12:19Z,2017-07-11T20:34:40Z,Update compiler_builtins submodule for probestack fix,alexcrichton,b8b4f5698d2ce29bfc3b0e68cede78c0423be303,1,Update compiler_builtins submodule for probestack fix Closes #43102,HEART,2017-07-08T12:23:51Z,est31,NA https://github.com/rust-lang/rust/pull/43116,MERGED,2017-07-08T04:12:19Z,2017-07-11T20:34:40Z,Update compiler_builtins submodule for probestack fix,alexcrichton,b8b4f5698d2ce29bfc3b0e68cede78c0423be303,1,Update compiler_builtins submodule for probestack fix Closes #43102,HOORAY,2017-07-08T12:23:53Z,est31,NA https://github.com/rust-lang/rust/pull/43127,CLOSED,2017-07-08T20:10:23Z,2017-07-27T23:53:14Z,Redesign the std::iter::Step trait tweak related iterator impls for ranges,SimonSapin,NA,NA,NA,HEART,2017-07-12T17:57:58Z,brson,NA https://github.com/rust-lang/rust/pull/43127,CLOSED,2017-07-08T20:10:23Z,2017-07-27T23:53:14Z,Redesign the std::iter::Step trait tweak related iterator impls for ranges,SimonSapin,NA,NA,NA,HEART,2017-07-15T23:30:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43130,MERGED,2017-07-08T22:40:59Z,2017-07-09T20:09:44Z,Add spacing between trait functions,GuillaumeGomez,12dccbde41963a7307e52ac237f27251244ddf6f,2,Add spacing between trait functions,THUMBS_UP,2017-07-09T01:28:54Z,est31,NA https://github.com/rust-lang/rust/pull/43130,MERGED,2017-07-08T22:40:59Z,2017-07-09T20:09:44Z,Add spacing between trait functions,GuillaumeGomez,12dccbde41963a7307e52ac237f27251244ddf6f,2,Add spacing between trait functions,HEART,2017-07-09T01:28:56Z,est31,NA https://github.com/rust-lang/rust/pull/43145,MERGED,2017-07-10T14:30:29Z,2017-07-15T17:18:48Z,fail in case nothing to run was found,GuillaumeGomez,0cf8f85275a969fe1d24c1700515659d09038ae3,1,fail in case nothing to run was found,HEART,2017-07-16T02:58:37Z,Havvy,NA https://github.com/rust-lang/rust/pull/43147,MERGED,2017-07-10T16:05:36Z,2017-07-11T10:07:39Z,Use similar compression settings as before updating to use flate2,oyvindln,37f56a2ab1e4811d2fbbc91befba2d139828ed13,4,Use similar compression settings as before updating to use flate2 Fixes #42879,HOORAY,2017-07-10T16:25:53Z,kennytm,NA https://github.com/rust-lang/rust/pull/43152,MERGED,2017-07-10T17:47:30Z,2017-07-10T21:05:23Z,Test src/doc once more,Mark-Simulacrum,50799265ca7f1d33d52a3f99337a4da83a190f5a,5,Test src/doc once more,HEART,2017-07-10T18:04:34Z,brson,NA https://github.com/rust-lang/rust/pull/43167,MERGED,2017-07-11T12:05:53Z,2017-07-14T05:21:00Z,"Enable profiler on ""alternate"" builds",SimonSapin,a148f5ba24a363a5df181fe228754690e09620f1,2,"Enable profiler on ""alternate"" builds This hopefully fixes #42967 and #43085.",HEART,2017-07-12T17:57:55Z,brson,NA https://github.com/rust-lang/rust/pull/43168,MERGED,2017-07-11T12:40:51Z,2017-07-19T05:39:17Z,Slew of builtin-attribute gating tests,pnkfelix,39b8aaf26fbde1ebcf4f5a3ed9af89305743087e,13,Slew of feature gating tests for issue #43106.,LAUGH,2017-07-12T02:16:10Z,retep998,NA https://github.com/rust-lang/rust/pull/43168,MERGED,2017-07-11T12:40:51Z,2017-07-19T05:39:17Z,Slew of builtin-attribute gating tests,pnkfelix,39b8aaf26fbde1ebcf4f5a3ed9af89305743087e,13,Slew of feature gating tests for issue #43106.,LAUGH,2017-07-12T02:23:28Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43168,MERGED,2017-07-11T12:40:51Z,2017-07-19T05:39:17Z,Slew of builtin-attribute gating tests,pnkfelix,39b8aaf26fbde1ebcf4f5a3ed9af89305743087e,13,Slew of feature gating tests for issue #43106.,LAUGH,2017-07-12T07:28:53Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43168,MERGED,2017-07-11T12:40:51Z,2017-07-19T05:39:17Z,Slew of builtin-attribute gating tests,pnkfelix,39b8aaf26fbde1ebcf4f5a3ed9af89305743087e,13,Slew of feature gating tests for issue #43106.,LAUGH,2017-07-12T14:05:13Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-12T04:00:39Z,est31,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-12T04:50:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-12T07:33:16Z,killercup,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-16T18:42:12Z,Others,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-18T21:42:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-07-19T23:33:39Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-08-29T02:44:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,HEART,2017-09-01T02:36:37Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-09-01T20:49:21Z,iamnotacake,NA https://github.com/rust-lang/rust/pull/43178,MERGED,2017-07-12T03:57:29Z,2017-07-19T23:40:08Z,suggest one-argument enum variant to fix type mismatch when applicable,zackmdavis,80c603fc6589aaf70df7c142723eef9a1d28aec5,3,path not name in sole-argument variant type mismatch suggestion We want the suggested replacement (which IDE tooling and such might offer to automatically swap in) to like actually be correct: suggesting `MyVariant(x)` when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing but Rust is supposed to be the future of computing: we're better than better than nothing. As an exceptional case we excise the prelude path preferring to suggest `Some` or `Ok` rather than `std::prelude::v1::Some` and `std::prelude::v2::Ok`. (It's not worth the effort to future-proof against hypothetical preludes v2 v3 &c.: we trust our successors to grep—excuse me ripgrep—for that.) Also don't make this preëmpt the existing probe-for-return-type suggestions despite their being looked unfavorably upon at least in this situation (https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody Schafer pointed out that that's a separate issue (https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229). This is in the matter of #42764.,THUMBS_UP,2017-10-13T14:34:55Z,SnirkImmington,NA https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HEART,2017-07-12T16:04:46Z,est31,NA https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HEART,2017-07-12T16:11:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HOORAY,2017-07-12T16:12:34Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HEART,2017-07-13T10:14:08Z,arielb1,NA https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HEART,2017-07-14T11:09:36Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43183,MERGED,2017-07-12T15:44:16Z,2017-07-21T04:49:03Z,trans: Internalize symbols without relying on LLVM,michaelwoerister,f6e5416a2f98685870ca6912beea42c00a446802,1,trans: Make the collector search const fn invocations.,HEART,2017-07-15T02:33:57Z,brson,NA https://github.com/rust-lang/rust/pull/43184,MERGED,2017-07-12T16:08:25Z,2017-07-15T04:47:15Z,integrate anon dep nodes into trait selection,nikomatsakis,4f030d04f499f650e54ef947799fe6cef20fb380,6,integrate anon dep nodes into trait selection,HEART,2017-07-12T17:50:30Z,brson,NA https://github.com/rust-lang/rust/pull/43185,MERGED,2017-07-12T16:14:58Z,2017-07-15T08:36:40Z,support pub(restricted) in thread_local! (round 2),durka,f9f4707469c2bc44ba3d643c805c8f3f62db7bd5,1,let #[allow_internal_unstable] cover :vis,THUMBS_UP,2017-07-13T21:14:59Z,jseyfried,NA https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,HEART,2017-07-12T20:03:16Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,HEART,2017-07-13T00:15:51Z,jseyfried,NA https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,HEART,2017-07-13T00:50:15Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,HEART,2017-07-13T13:54:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,THUMBS_UP,2017-07-21T07:35:36Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/43192,CLOSED,2017-07-12T18:47:59Z,2017-08-19T11:28:28Z,librustc_*: Use `pub(crate)` instead of `pub` and remove dead code,petrochenkov,NA,NA,NA,THUMBS_UP,2017-07-26T23:57:30Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43199,CLOSED,2017-07-13T00:40:06Z,2017-07-13T19:32:05Z,[beta] Remove rls from the workspace and extended builds,cuviper,NA,NA,NA,HEART,2017-07-13T00:47:07Z,brson,NA https://github.com/rust-lang/rust/pull/43199,CLOSED,2017-07-13T00:40:06Z,2017-07-13T19:32:05Z,[beta] Remove rls from the workspace and extended builds,cuviper,NA,NA,NA,HEART,2017-07-13T02:05:23Z,est31,NA https://github.com/rust-lang/rust/pull/43199,CLOSED,2017-07-13T00:40:06Z,2017-07-13T19:32:05Z,[beta] Remove rls from the workspace and extended builds,cuviper,NA,NA,NA,HEART,2017-07-13T02:11:51Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43220,CLOSED,2017-07-13T18:06:23Z,2017-07-30T13:02:24Z,Add TryFrom implementation for bool f32 and f64,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-07-13T18:38:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/43220,CLOSED,2017-07-13T18:06:23Z,2017-07-30T13:02:24Z,Add TryFrom implementation for bool f32 and f64,GuillaumeGomez,NA,NA,NA,CONFUSED,2017-07-13T20:26:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43220,CLOSED,2017-07-13T18:06:23Z,2017-07-30T13:02:24Z,Add TryFrom implementation for bool f32 and f64,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2017-07-13T20:29:30Z,ollie27,NA https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,HEART,2017-07-14T19:48:29Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,HEART,2017-07-19T09:23:19Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,HEART,2017-07-19T20:36:03Z,NotKyon,NA https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,HEART,2017-07-29T09:23:53Z,sinclairzx81,NA https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,HEART,2017-08-16T14:33:45Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,THUMBS_DOWN,2017-08-22T07:40:22Z,krk,keremkat@gmail.com https://github.com/rust-lang/rust/pull/43221,MERGED,2017-07-13T18:16:48Z,2017-07-28T12:55:13Z,Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str *T and [T].,MaulingMonkey,90a7cac8c8b1f4ee55c18e4ea21a8834a586c967,2,*.natvis: Use s8 postfixes to correctly interpret rust strings as UTF-8.,THUMBS_UP,2017-08-22T07:40:24Z,krk,keremkat@gmail.com https://github.com/rust-lang/rust/pull/43222,MERGED,2017-07-13T18:24:29Z,2017-07-15T17:18:51Z,windows::fs::symlink_dir: fix example to actually use symlink_dir,RalfJung,03f22fdf5e290618d2055d48881e31439a6b74ec,1,windows::fs::symlink_dir: fix example to actually use symlink_dir,LAUGH,2017-07-14T00:58:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/43222,MERGED,2017-07-13T18:24:29Z,2017-07-15T17:18:51Z,windows::fs::symlink_dir: fix example to actually use symlink_dir,RalfJung,03f22fdf5e290618d2055d48881e31439a6b74ec,1,windows::fs::symlink_dir: fix example to actually use symlink_dir,LAUGH,2017-07-14T19:56:37Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/43224,MERGED,2017-07-13T21:10:30Z,2017-07-15T21:36:47Z,macros: fix regression involving identifiers in `macro_rules!` patterns.,jseyfried,b5c5a0c3fd91e2f3a61e26bf5a00297a6e2b3366,2,Fix regression involving identifiers in `macro_rules!` patterns.,THUMBS_UP,2017-07-13T21:30:43Z,est31,NA https://github.com/rust-lang/rust/pull/43224,MERGED,2017-07-13T21:10:30Z,2017-07-15T21:36:47Z,macros: fix regression involving identifiers in `macro_rules!` patterns.,jseyfried,b5c5a0c3fd91e2f3a61e26bf5a00297a6e2b3366,2,Fix regression involving identifiers in `macro_rules!` patterns.,LAUGH,2017-07-13T21:59:28Z,kennytm,NA https://github.com/rust-lang/rust/pull/43224,MERGED,2017-07-13T21:10:30Z,2017-07-15T21:36:47Z,macros: fix regression involving identifiers in `macro_rules!` patterns.,jseyfried,b5c5a0c3fd91e2f3a61e26bf5a00297a6e2b3366,2,Fix regression involving identifiers in `macro_rules!` patterns.,THUMBS_UP,2017-07-14T05:12:22Z,durka,NA https://github.com/rust-lang/rust/pull/43228,MERGED,2017-07-14T02:08:27Z,2017-07-15T17:18:52Z,Fix backtrace on Redox,jackpot51,5757e0561975b40f81a739feb73abdc377eeda3a,2,Fix backtrace on Redox,THUMBS_UP,2017-07-14T18:44:10Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/43230,MERGED,2017-07-14T05:33:04Z,2017-07-28T23:21:07Z,Implement tokenization for some items in proc_macro,alexcrichton,4886ec86651a5eaae1ddc834a941842904a5db61,10,syntax: Capture a `TokenStream` when parsing items This is then later used by `proc_macro` to generate a new `proc_macro::TokenTree` which preserves span information. Unfortunately this isn't a bullet-proof approach as it doesn't handle the case when there's still other attributes on the item especially inner attributes. Despite this the intention here is to solve the primary use case for procedural attributes attached to functions as outer attributes likely bare. In this situation we should be able to now yield a lossless stream of tokens to preserve span information.,THUMBS_UP,2017-07-24T12:02:49Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/43245,MERGED,2017-07-15T02:02:50Z,2017-08-16T01:16:36Z,Add Vec::drain_filter,Gankra,1af42261e142c20c1aed30732ad77bf3560318a1,3,Add Vec::drain_filter,THUMBS_UP,2017-07-16T17:05:54Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/43245,MERGED,2017-07-15T02:02:50Z,2017-08-16T01:16:36Z,Add Vec::drain_filter,Gankra,1af42261e142c20c1aed30732ad77bf3560318a1,3,Add Vec::drain_filter,THUMBS_UP,2017-07-18T18:17:24Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43245,MERGED,2017-07-15T02:02:50Z,2017-08-16T01:16:36Z,Add Vec::drain_filter,Gankra,1af42261e142c20c1aed30732ad77bf3560318a1,3,Add Vec::drain_filter,THUMBS_UP,2017-11-12T14:59:43Z,ktff,NA https://github.com/rust-lang/rust/pull/43248,MERGED,2017-07-15T06:39:14Z,2017-07-25T03:22:36Z,improve the TryFrom implementations,llogiq,72ef15e0df7cc1a794d79559a3da79321eec7bfb,2,improve the TryFrom implementations This removes the need for a 128 bit storage by making use of the fact that there can be either no over/underflow either one or both and each time the target type suffices to hold the limit for comparison. The downside is that the code looks a bit more complex. This test code included in this commit is from @oyvindln 's PR. They also greatly helped fixing a number of errors I made along the way. Thanks a lot!,THUMBS_UP,2017-07-24T21:02:38Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,THUMBS_UP,2017-07-15T13:53:44Z,est31,NA https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,THUMBS_UP,2017-07-15T14:11:28Z,kennytm,NA https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,THUMBS_UP,2017-07-15T14:17:30Z,retep998,NA https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,THUMBS_UP,2017-07-15T17:02:30Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,HEART,2017-07-15T22:59:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43252,MERGED,2017-07-15T13:44:08Z,2017-07-16T12:43:07Z,Document default values for primitive types,vbrandl,caf125f414cc7bcdacdbfeab5c3b62eba772c8a3,1,Rephrase the doc string,THUMBS_UP,2017-07-16T10:21:07Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/43256,MERGED,2017-07-15T20:23:35Z,2017-07-23T11:55:07Z,Improve panic docs for Instant::duration_since,Others,c458627230bef878c86b133e0687614bcf64df56,1,Improve panic docs for Instant::duration_since The docs for Instant::duration_since has a confusing section on panicking. It's much more clear without the second two sentences of description.,THUMBS_UP,2017-07-16T04:43:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/43290,MERGED,2017-07-17T16:09:58Z,2017-07-19T00:35:43Z,libstd: remove redundant & from &Path::new(...),nodakai,2e8859ce4e97df8e2b1372e20efe4f8676c0f178,4,libstd: remove redundant & from &Path::new(...) fn Path::new(s: &S) -> &Path Signed-off-by: NODA Kai ,HEART,2017-07-17T17:48:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43292,MERGED,2017-07-17T17:53:00Z,2017-07-19T00:35:43Z,"Workaround ""Quasi-quoting is inefficient"" warning in incremental rustbuild introduced in #43252.",kennytm,2d6c10f6f40d98d9e67008496704ff3b4c23b799,1,"Fix ""Quasi-quoting is inefficient"" warning in incremental rustbuild. After #43252 is merged building stage0 libcore with -i (--incremental) flag will cause 17 ""Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)"" warnings as in #40946. Fixing the warning in #40946 will take 12 weeks from now to make into the next stage0 so it is quicker to workaround it in libcore instead.",HOORAY,2017-07-18T08:33:10Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43292,MERGED,2017-07-17T17:53:00Z,2017-07-19T00:35:43Z,"Workaround ""Quasi-quoting is inefficient"" warning in incremental rustbuild introduced in #43252.",kennytm,2d6c10f6f40d98d9e67008496704ff3b4c23b799,1,"Fix ""Quasi-quoting is inefficient"" warning in incremental rustbuild. After #43252 is merged building stage0 libcore with -i (--incremental) flag will cause 17 ""Quasi-quoting might make incremental compilation very inefficient: NtExpr(..)"" warnings as in #40946. Fixing the warning in #40946 will take 12 weeks from now to make into the next stage0 so it is quicker to workaround it in libcore instead.",HEART,2017-07-18T08:33:12Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43310,MERGED,2017-07-18T09:33:01Z,2017-07-19T00:35:45Z,Fix erroneous reference to Arc instead of Rc in rc::Weak documentation,lynn,de7decc0559e6cab05cfe007f9c53e065b7094d9,1,Fix erroneous reference to Arc instead of Rc,THUMBS_UP,2017-07-22T02:54:28Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/43314,MERGED,2017-07-18T14:43:32Z,2017-07-19T00:35:45Z,travis: Switch `curl -s` to `curl -f`,alexcrichton,8340f74eb71bdc9b1fd9e456eee27a7e034f8805,8,travis: Switch `curl -s` to `curl -f` I seem to have been a little too tired when I fixed up the container scripts applying the wrong flag!,LAUGH,2017-07-18T17:11:15Z,kennytm,NA https://github.com/rust-lang/rust/pull/43315,MERGED,2017-07-18T14:47:40Z,2017-07-19T00:35:46Z,float_bits_conv made it into 1.20,est31,ffefc9aa1ca6383f722ec1cbf722da42ffdb8108,2,float_bits_conv made it into 1.20,LAUGH,2017-07-18T17:08:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/43320,MERGED,2017-07-18T21:32:11Z,2017-07-25T18:45:42Z,Bump master to 1.21.0,alexcrichton,9010567dcc0aba772525841aee67c030ea3450c6,34,Bump master to 1.21.0 This commit bumps the master branch's version to 1.21.0 and also updates the bootstrap compiler from the freshly minted beta release.,THUMBS_UP,2017-07-19T02:44:37Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,HEART,2017-07-20T00:25:29Z,estebank,NA https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,HOORAY,2017-07-23T20:01:54Z,timClicks,paperless@timmcnamara.co.nz https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,HOORAY,2017-07-26T03:33:48Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,HEART,2017-07-26T03:53:15Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,THUMBS_UP,2017-07-26T06:51:23Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,THUMBS_UP,2017-07-26T14:53:48Z,shivjm,NA https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,THUMBS_UP,2017-07-26T23:57:53Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43323,MERGED,2017-07-19T02:13:16Z,2017-07-22T07:04:58Z,Less verbose output for unused arguments ,perryprog,5c10db3f948cefa9bd665bfc422d46a47839deab,2,More tests,HOORAY,2017-08-01T01:51:30Z,perryprog,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-19T18:56:46Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-19T19:13:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-19T19:17:11Z,cramertj,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-19T20:08:38Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HEART,2017-07-19T21:28:56Z,Ixrec,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-20T03:38:26Z,est31,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HEART,2017-07-20T03:38:28Z,est31,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-20T06:48:08Z,mzji,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HEART,2017-07-20T06:48:10Z,mzji,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-20T09:09:04Z,killercup,NA https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HEART,2017-07-20T11:45:22Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-20T15:15:22Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HOORAY,2017-07-20T19:59:45Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43340,CLOSED,2017-07-19T18:04:59Z,2017-07-24T08:10:07Z,Merge miri into librustc_mir,oli-obk,NA,NA,NA,HEART,2017-07-21T09:17:03Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/43345,MERGED,2017-07-19T21:17:21Z,2017-08-24T19:09:17Z,Profile queries,matthewhammer,43335aec22327ef542088263dd7353accda40517,6,-Z profile-query-and-key separate from -Z profile-query; query key is string option,HEART,2017-07-20T14:03:52Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-07-20T01:35:49Z,durka,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-07-20T09:06:07Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-07-20T11:03:22Z,retep998,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-07-20T14:29:04Z,alexbool,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-08-05T01:58:26Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-08-09T18:31:07Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-08-14T18:46:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-08-31T02:43:10Z,jminer,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-09-21T02:02:14Z,behnam,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-10-03T22:42:07Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HEART,2017-10-05T15:56:03Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2017-10-12T16:24:01Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43348,MERGED,2017-07-20T00:46:55Z,2017-08-13T05:24:51Z,Expose all OS-specific modules in libstd doc.,kennytm,3093bb85f94e6f3c4707674c8b70c28ecfbf3bf9,2,Fix error during cross-platform documentation.,HOORAY,2019-08-07T13:48:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/43351,CLOSED,2017-07-20T03:42:57Z,2017-08-03T18:45:20Z,For small types just swap directly,scottmcm,NA,NA,NA,THUMBS_UP,2017-07-20T12:22:31Z,oyvindln,NA https://github.com/rust-lang/rust/pull/43351,CLOSED,2017-07-20T03:42:57Z,2017-08-03T18:45:20Z,For small types just swap directly,scottmcm,NA,NA,NA,THUMBS_UP,2017-07-20T13:10:24Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43367,MERGED,2017-07-20T18:17:06Z,2017-07-22T18:27:36Z,std: Cut down #[inline] annotations where not necessary,alexcrichton,53d8b1d0515f53d138f0b9c3067540d8c5708415,10,"std: Cut down #[inline] annotations where not necessary This PR cuts down on a large number of `#[inline(always)]` and `#[inline]` annotations in libcore for various core functions. The `#[inline(always)]` annotation is almost never needed and is detrimental to debug build times as it forces LLVM to perform inlining when it otherwise wouldn't need to in debug builds. Additionally `#[inline]` is an unnecessary annoation on almost all generic functions because the function will already be monomorphized into other codegen units and otherwise rarely needs the extra ""help"" from us to tell LLVM to inline something. Overall this PR cut the compile time of a [microbenchmark][1] by 30% from 1s to 0.7s. [1]: https://gist.github.com/alexcrichton/a7d70319a45aa60cf36a6a7bf540dd3a",THUMBS_UP,2017-07-21T05:18:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43387,MERGED,2017-07-21T13:39:23Z,2017-07-23T04:25:49Z,Update Rust LLVM bindings for LLVM 5.0,TimNN,38e40ce50653b8164915b8142e883c5a57b33e7b,1,Relax a codegen test to be compatible with LLVM 5.0,HEART,2017-07-21T21:12:01Z,tlively,NA https://github.com/rust-lang/rust/pull/43387,MERGED,2017-07-21T13:39:23Z,2017-07-23T04:25:49Z,Update Rust LLVM bindings for LLVM 5.0,TimNN,38e40ce50653b8164915b8142e883c5a57b33e7b,1,Relax a codegen test to be compatible with LLVM 5.0,HEART,2017-07-22T11:24:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43387,MERGED,2017-07-21T13:39:23Z,2017-07-23T04:25:49Z,Update Rust LLVM bindings for LLVM 5.0,TimNN,38e40ce50653b8164915b8142e883c5a57b33e7b,1,Relax a codegen test to be compatible with LLVM 5.0,HEART,2017-07-26T07:29:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43387,MERGED,2017-07-21T13:39:23Z,2017-07-23T04:25:49Z,Update Rust LLVM bindings for LLVM 5.0,TimNN,38e40ce50653b8164915b8142e883c5a57b33e7b,1,Relax a codegen test to be compatible with LLVM 5.0,HEART,2017-07-28T10:59:59Z,petro-rudenko,petro.rudenko@gmail.com https://github.com/rust-lang/rust/pull/43397,MERGED,2017-07-21T23:18:19Z,2017-08-06T21:23:33Z,Don't warn on unused field on union,GuillaumeGomez,f94157eb616d18655809ea60af870e1888476c9a,3,Handle type aliases as well,THUMBS_UP,2017-07-23T15:01:19Z,sanpii,NA https://github.com/rust-lang/rust/pull/43399,MERGED,2017-07-21T23:41:24Z,2017-07-31T23:20:58Z,default binding modes: add pat_binding_modes,tbg,8f67f1efaf792a0c3ef629e1e62e53eba7365a1c,1,add comments from arielb1,THUMBS_UP,2017-07-23T13:54:25Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/43401,MERGED,2017-07-22T01:10:26Z,2017-07-24T22:58:11Z,"Correct the spelling of ""homogeneous""",cuviper,5c6ccdc37c88ce77306646703a1ada166e998c40,7,"Correct the spelling of ""homogeneous""",LAUGH,2017-07-30T14:06:02Z,kennytm,NA https://github.com/rust-lang/rust/pull/43403,MERGED,2017-07-22T07:23:20Z,2017-08-04T10:13:57Z,Add MIR Validate statement,RalfJung,7d8dc7a979975ab6d8aab29cfa0b69e8a64f1280,4,also release-validate return value before a call,HEART,2017-07-22T07:54:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43406,MERGED,2017-07-22T09:24:46Z,2017-07-23T06:56:01Z,Add missing `!: Clone` impl,canndrew,c0fa16afc9f306a9d2af44f2e0adb7b2b714700a,1,Add !: Clone impl,LAUGH,2017-07-22T20:22:40Z,durka,NA https://github.com/rust-lang/rust/pull/43406,MERGED,2017-07-22T09:24:46Z,2017-07-23T06:56:01Z,Add missing `!: Clone` impl,canndrew,c0fa16afc9f306a9d2af44f2e0adb7b2b714700a,1,Add !: Clone impl,LAUGH,2017-07-23T19:20:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43406,MERGED,2017-07-22T09:24:46Z,2017-07-23T06:56:01Z,Add missing `!: Clone` impl,canndrew,c0fa16afc9f306a9d2af44f2e0adb7b2b714700a,1,Add !: Clone impl,LAUGH,2017-07-26T02:38:28Z,dlight,NA https://github.com/rust-lang/rust/pull/43406,MERGED,2017-07-22T09:24:46Z,2017-07-23T06:56:01Z,Add missing `!: Clone` impl,canndrew,c0fa16afc9f306a9d2af44f2e0adb7b2b714700a,1,Add !: Clone impl,LAUGH,2017-07-26T16:38:45Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-23T15:05:57Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-23T17:17:48Z,est31,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HEART,2017-07-23T17:17:56Z,est31,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-24T08:12:35Z,killercup,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-24T10:09:53Z,adaszko,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-24T19:46:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-24T21:53:16Z,durka,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-26T02:09:43Z,Others,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-07-27T15:28:53Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HEART,2017-07-27T15:28:54Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HEART,2017-08-02T00:45:37Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-08-02T14:12:13Z,camjackson,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HEART,2017-08-02T19:04:32Z,pchickey,pat@moreproductive.org https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-08-09T17:13:01Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-08-18T08:21:50Z,arshiamufti,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HEART,2017-08-27T03:50:04Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-08-27T03:50:05Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-08-30T08:39:46Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-09-02T16:01:17Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43422,CLOSED,2017-07-23T08:21:22Z,2017-08-31T14:29:40Z,Add libbacktrace support for Apple platforms,JohnColanduoni,NA,NA,NA,HOORAY,2017-10-12T15:07:29Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43426,MERGED,2017-07-23T13:52:37Z,2017-09-06T03:12:08Z,Add hints when intercrate ambiguity causes overlap.,qnighy,37c9a60a7d24d5b8c51f647e8c39e48965cd2b82,2,factor out helper method,HOORAY,2017-07-23T14:51:00Z,Ixrec,NA https://github.com/rust-lang/rust/pull/43426,MERGED,2017-07-23T13:52:37Z,2017-09-06T03:12:08Z,Add hints when intercrate ambiguity causes overlap.,qnighy,37c9a60a7d24d5b8c51f647e8c39e48965cd2b82,2,factor out helper method,HEART,2017-09-06T00:36:57Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/43443,MERGED,2017-07-23T22:03:15Z,2017-07-27T22:21:57Z,Improve checking of conflicting packed and align representation hints on structs and unions.,bitshifter,5cccd6a9eeea380af4f8150b7afcdc9f15332abc,3,Apply packed and align restrictions to unions.,THUMBS_UP,2017-08-02T00:52:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43444,CLOSED,2017-07-23T22:19:41Z,2017-08-22T22:06:59Z,Fix android backtraces,roblabla,NA,NA,NA,HOORAY,2017-07-23T23:04:17Z,est31,NA https://github.com/rust-lang/rust/pull/43444,CLOSED,2017-07-23T22:19:41Z,2017-08-22T22:06:59Z,Fix android backtraces,roblabla,NA,NA,NA,HEART,2017-07-23T23:04:19Z,est31,NA https://github.com/rust-lang/rust/pull/43444,CLOSED,2017-07-23T22:19:41Z,2017-08-22T22:06:59Z,Fix android backtraces,roblabla,NA,NA,NA,HEART,2017-07-24T06:33:14Z,estebank,NA https://github.com/rust-lang/rust/pull/43445,MERGED,2017-07-23T23:13:53Z,2017-07-27T04:25:44Z,rustdoc: make major section headers self-links,zackmdavis,09fc36e3b5ca245d31f9dbddeb41006ac457273e,1,rustdoc: make major section headers self-links The sidebar already has links to these h2's ids but for convenience the h2 itself should also be a link (retaining its present appearance). This should address most of #24484.,THUMBS_UP,2017-07-24T16:42:01Z,mcarton,NA https://github.com/rust-lang/rust/pull/43445,MERGED,2017-07-23T23:13:53Z,2017-07-27T04:25:44Z,rustdoc: make major section headers self-links,zackmdavis,09fc36e3b5ca245d31f9dbddeb41006ac457273e,1,rustdoc: make major section headers self-links The sidebar already has links to these h2's ids but for convenience the h2 itself should also be a link (retaining its present appearance). This should address most of #24484.,THUMBS_UP,2017-07-26T11:25:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/43447,MERGED,2017-07-24T02:41:46Z,2017-07-26T23:40:56Z,Point at path segment on module not found,estebank,552ff07758545173c94fa260e5266ec07cd0bbde,18,Point at path segment on module not found Point at the correct path segment on a import statement where a module doesn't exist. New output: ```rust error[E0432]: unresolved import `std::bar` --> :1:10 | 1 | use std::bar::{foo1 foo2}; | ^^^ Could not find `bar` in `std` ``` instead of: ```rust error[E0432]: unresolved import `std::bar::foo1` --> :1:16 | 1 | use std::bar::{foo1 foo2}; | ^^^^ Could not find `bar` in `std` error[E0432]: unresolved import `std::bar::foo2` --> :1:22 | 1 | use std::bar::{foo1 foo2}; | ^^^^ Could not find `bar` in `std` ```,HEART,2017-08-02T08:00:24Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/43459,MERGED,2017-07-24T21:48:31Z,2017-08-04T04:36:01Z,Implement AsRawFd for Stdin Stdout and Stderr,ids1024,64e426e8e9fff27a7dc0a1bdf297bf5fd3f10b15,1,Fix AsRawHandle,THUMBS_UP,2017-07-25T00:14:24Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/43459,MERGED,2017-07-24T21:48:31Z,2017-08-04T04:36:01Z,Implement AsRawFd for Stdin Stdout and Stderr,ids1024,64e426e8e9fff27a7dc0a1bdf297bf5fd3f10b15,1,Fix AsRawHandle,THUMBS_UP,2017-08-09T16:15:33Z,kylewlacy,NA https://github.com/rust-lang/rust/pull/43465,MERGED,2017-07-25T03:25:14Z,2017-07-26T23:40:59Z,Add tests for issues with the E-needstest label,topecongiro,04aa5c1c76d516c065e3d3626887090cd05ded82,8,Add tests for issues with the E-needstest label,HEART,2017-07-25T07:30:45Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43465,MERGED,2017-07-25T03:25:14Z,2017-07-26T23:40:59Z,Add tests for issues with the E-needstest label,topecongiro,04aa5c1c76d516c065e3d3626887090cd05ded82,8,Add tests for issues with the E-needstest label,HEART,2017-07-25T08:20:19Z,killercup,NA https://github.com/rust-lang/rust/pull/43465,MERGED,2017-07-25T03:25:14Z,2017-07-26T23:40:59Z,Add tests for issues with the E-needstest label,topecongiro,04aa5c1c76d516c065e3d3626887090cd05ded82,8,Add tests for issues with the E-needstest label,HEART,2017-07-25T18:05:22Z,mcarton,NA https://github.com/rust-lang/rust/pull/43482,MERGED,2017-07-25T22:21:48Z,2017-07-27T19:48:21Z,Compile rustdoc on-demand,Mark-Simulacrum,9ee877bbe6300b987dc29f90b192de7a6e258bcf,3,Correct a few run.host invocations where run.target is intended.,HOORAY,2017-07-25T22:26:37Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/43482,MERGED,2017-07-25T22:21:48Z,2017-07-27T19:48:21Z,Compile rustdoc on-demand,Mark-Simulacrum,9ee877bbe6300b987dc29f90b192de7a6e258bcf,3,Correct a few run.host invocations where run.target is intended.,HEART,2017-07-25T22:26:38Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/43482,MERGED,2017-07-25T22:21:48Z,2017-07-27T19:48:21Z,Compile rustdoc on-demand,Mark-Simulacrum,9ee877bbe6300b987dc29f90b192de7a6e258bcf,3,Correct a few run.host invocations where run.target is intended.,HEART,2017-07-26T08:16:39Z,ollie27,NA https://github.com/rust-lang/rust/pull/43482,MERGED,2017-07-25T22:21:48Z,2017-07-27T19:48:21Z,Compile rustdoc on-demand,Mark-Simulacrum,9ee877bbe6300b987dc29f90b192de7a6e258bcf,3,Correct a few run.host invocations where run.target is intended.,HEART,2017-07-27T21:22:28Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43482,MERGED,2017-07-25T22:21:48Z,2017-07-27T19:48:21Z,Compile rustdoc on-demand,Mark-Simulacrum,9ee877bbe6300b987dc29f90b192de7a6e258bcf,3,Correct a few run.host invocations where run.target is intended.,HOORAY,2017-07-27T21:22:33Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43488,MERGED,2017-07-26T14:46:00Z,2017-08-06T10:25:56Z,Optimize initialization of arrays using repeat expressions,Florob,11d6312abd614fca3970902f137225e0437d0a09,1,codegen tests: Check type of `len` argument to `llvm.memset.*` based on the exact intrinsic used,HOORAY,2017-07-26T15:21:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/43488,MERGED,2017-07-26T14:46:00Z,2017-08-06T10:25:56Z,Optimize initialization of arrays using repeat expressions,Florob,11d6312abd614fca3970902f137225e0437d0a09,1,codegen tests: Check type of `len` argument to `llvm.memset.*` based on the exact intrinsic used,HOORAY,2017-07-27T19:18:44Z,epinna,NA https://github.com/rust-lang/rust/pull/43488,MERGED,2017-07-26T14:46:00Z,2017-08-06T10:25:56Z,Optimize initialization of arrays using repeat expressions,Florob,11d6312abd614fca3970902f137225e0437d0a09,1,codegen tests: Check type of `len` argument to `llvm.memset.*` based on the exact intrinsic used,HOORAY,2017-08-04T16:18:57Z,killercup,NA https://github.com/rust-lang/rust/pull/43498,MERGED,2017-07-26T23:49:35Z,2017-07-27T17:08:07Z,Copyright/license headers,joshtriplett,f1de27fe6b73a8463fb49d4d2c88a24fa7031b82,1,"COPYRIGHT: Provide a better explanation of Rust copyrights Avoid implying that any copyrights have been assigned to a separate entity (such as ""The Rust Project Developers"") Rust contributors retain their copyrights and do not assign them to anyone by contributing. Remove the inaccurate notice and provide a clear explanation. Avoid stating that all files contain copyright notices and/or license notices and especially avoid suggesting that the license terms only apply to files marked as such. In the process this also drops a separate notice that implies only some copyrights are retained by contributors (suggesting that others are not).",LAUGH,2017-07-26T22:49:11Z,durka,NA https://github.com/rust-lang/rust/pull/43498,MERGED,2017-07-26T23:49:35Z,2017-07-27T17:08:07Z,Copyright/license headers,joshtriplett,f1de27fe6b73a8463fb49d4d2c88a24fa7031b82,1,"COPYRIGHT: Provide a better explanation of Rust copyrights Avoid implying that any copyrights have been assigned to a separate entity (such as ""The Rust Project Developers"") Rust contributors retain their copyrights and do not assign them to anyone by contributing. Remove the inaccurate notice and provide a clear explanation. Avoid stating that all files contain copyright notices and/or license notices and especially avoid suggesting that the license terms only apply to files marked as such. In the process this also drops a separate notice that implies only some copyrights are retained by contributors (suggesting that others are not).",THUMBS_UP,2017-07-26T22:50:56Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-27T16:05:10Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-27T16:12:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-07-27T17:14:18Z,kennytm,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-07-27T17:28:19Z,est31,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-27T17:28:25Z,est31,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-27T17:43:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-07-27T17:43:45Z,cramertj,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-27T18:04:11Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-07-27T18:04:11Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-07-27T23:16:36Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-07-30T04:27:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-08-01T13:29:18Z,bjorn3,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-08-09T17:58:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-08-09T17:58:26Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-08-10T11:36:18Z,HongxuChen,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-08-11T15:52:14Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-08-28T23:20:03Z,djg,dan.glastonbury@gmail.com https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-10-10T19:22:48Z,JesseWright,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-10-10T19:22:49Z,JesseWright,NA https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2017-10-12T16:24:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2017-10-12T16:24:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HOORAY,2018-03-24T04:57:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43506,MERGED,2017-07-27T15:52:24Z,2017-08-01T19:59:57Z,Run translation and LLVM in parallel when compiling with multiple CGUs,michaelwoerister,6468cad977d4c81d30ba000633eaa43bc18591f9,1,async-llvm(29): Adapt run-make/llvm-phase test case to LLVM module not being available in memory.,HEART,2018-03-24T04:57:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-27T18:48:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-27T18:51:52Z,durka,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-27T19:28:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-27T19:38:12Z,oyvindln,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-27T20:09:22Z,malbarbo,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,THUMBS_UP,2017-07-28T11:05:58Z,killercup,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,HEART,2017-07-29T10:01:44Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,HEART,2017-08-02T08:08:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,HOORAY,2017-08-02T12:04:29Z,shivjm,NA https://github.com/rust-lang/rust/pull/43509,MERGED,2017-07-27T18:30:01Z,2017-07-30T04:02:09Z,rustdoc: add [src] links to associated functions inside an impl block,QuietMisdreavus,c9bdd518eb64c0072dae0df01ce67fedf728adb4,2,add [src] links to associated functions inside an impl block,HEART,2017-08-02T21:15:30Z,maghoff,NA https://github.com/rust-lang/rust/pull/43515,MERGED,2017-07-28T00:33:09Z,2017-07-30T20:19:57Z,"rustdoc: print associated types in traits ""implementors"" section",QuietMisdreavus,612081a78d136c7ad0b63dd3454ceb727d0e69c5,1,"print associated types in traits ""implementors"" section",THUMBS_UP,2017-07-28T04:35:12Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/43515,MERGED,2017-07-28T00:33:09Z,2017-07-30T20:19:57Z,"rustdoc: print associated types in traits ""implementors"" section",QuietMisdreavus,612081a78d136c7ad0b63dd3454ceb727d0e69c5,1,"print associated types in traits ""implementors"" section",THUMBS_UP,2017-07-29T16:13:52Z,kennytm,NA https://github.com/rust-lang/rust/pull/43515,MERGED,2017-07-28T00:33:09Z,2017-07-30T20:19:57Z,"rustdoc: print associated types in traits ""implementors"" section",QuietMisdreavus,612081a78d136c7ad0b63dd3454ceb727d0e69c5,1,"print associated types in traits ""implementors"" section",THUMBS_UP,2017-08-02T12:05:52Z,shivjm,NA https://github.com/rust-lang/rust/pull/43515,MERGED,2017-07-28T00:33:09Z,2017-07-30T20:19:57Z,"rustdoc: print associated types in traits ""implementors"" section",QuietMisdreavus,612081a78d136c7ad0b63dd3454ceb727d0e69c5,1,"print associated types in traits ""implementors"" section",THUMBS_UP,2017-08-07T05:40:21Z,Havvy,NA https://github.com/rust-lang/rust/pull/43515,MERGED,2017-07-28T00:33:09Z,2017-07-30T20:19:57Z,"rustdoc: print associated types in traits ""implementors"" section",QuietMisdreavus,612081a78d136c7ad0b63dd3454ceb727d0e69c5,1,"print associated types in traits ""implementors"" section",THUMBS_UP,2017-08-07T11:09:29Z,mjkillough,michaeljkillough@gmail.com https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-07-28T15:05:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-07-28T15:22:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-07-28T16:25:44Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-07-28T19:42:02Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-07-28T21:11:54Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-08-01T11:08:15Z,mjkillough,michaeljkillough@gmail.com https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HOORAY,2017-08-10T21:22:44Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43522,MERGED,2017-07-28T14:15:55Z,2017-08-10T13:50:48Z,rustc: Rearchitect lints to be emitted more eagerly,alexcrichton,0374e6aab7ef60b523872556ae4aca33c59fbfc9,84,"rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more ""eager"" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases one set of ""early"" lints run on the `syntax::ast` and a ""late"" set of lints run on the HIR. This commit moves the ""early"" lints to running as late as possible in compilation just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before maintaining context of the current lint level as it walks the tree. Post-HIR however linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite.",HEART,2017-08-10T21:23:09Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43528,CLOSED,2017-07-28T20:24:11Z,2017-08-04T22:13:59Z,Build rustdoc only at the topmost stage.,Mark-Simulacrum,NA,NA,NA,HEART,2017-07-28T20:27:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43528,CLOSED,2017-07-28T20:24:11Z,2017-08-04T22:13:59Z,Build rustdoc only at the topmost stage.,Mark-Simulacrum,NA,NA,NA,HEART,2017-07-29T19:30:13Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43540,MERGED,2017-07-29T12:12:26Z,2017-08-22T01:34:54Z,syntax: Relax path grammar,petrochenkov,804459bdca28010137990220e617a6b6cbab18d0,3,Issue warnings for unnecessary path disambiguators,THUMBS_UP,2017-07-30T02:47:00Z,durka,NA https://github.com/rust-lang/rust/pull/43547,MERGED,2017-07-29T20:09:37Z,2017-08-01T01:44:34Z,borrowck: skip CFG construction when there is nothing to propagate,arielb1,83eb264273fe7ace01b2100c116daa36f06920b8,2,borrowck: skip CFG construction when there is nothing to propagate CFG construction takes a large amount of time and memory especially for large constants. If such a constant contains no actions on lvalues it can't have borrowck problems and can be ignored by it. This removes the 4.9GB borrowck peak from #36799. It seems that HIR had grown by 300MB and MIR had grown by 500MB from the last massif collection and that remains to be investigated but this at least shaves the borrowck peak.,LAUGH,2017-07-29T22:16:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43547,MERGED,2017-07-29T20:09:37Z,2017-08-01T01:44:34Z,borrowck: skip CFG construction when there is nothing to propagate,arielb1,83eb264273fe7ace01b2100c116daa36f06920b8,2,borrowck: skip CFG construction when there is nothing to propagate CFG construction takes a large amount of time and memory especially for large constants. If such a constant contains no actions on lvalues it can't have borrowck problems and can be ignored by it. This removes the 4.9GB borrowck peak from #36799. It seems that HIR had grown by 300MB and MIR had grown by 500MB from the last massif collection and that remains to be investigated but this at least shaves the borrowck peak.,LAUGH,2017-08-09T17:54:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43549,MERGED,2017-07-29T20:40:17Z,2017-07-30T04:02:12Z,rustbuild: Enable building LLVM,alexcrichton,ad1f19479c05ed4eeaaba8f207a61e3d48b0a0b7,2,rustbuild: Enable building LLVM I use this from time to time debugging LLVM builds useful to have!,HEART,2017-07-30T10:44:25Z,arielb1,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T07:36:05Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T11:13:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T13:56:03Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T14:57:07Z,est31,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T16:20:44Z,plietar,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T18:40:05Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-30T22:21:41Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-31T01:56:23Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-07-31T08:25:29Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-01T16:06:04Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-02T14:56:22Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-09T12:42:45Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-09T16:32:23Z,coder543,coder543@gmail.com https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-09T17:46:48Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-12T23:12:42Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-08-16T18:59:04Z,Cldfire,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2017-10-11T23:40:10Z,hcpl,NA https://github.com/rust-lang/rust/pull/43554,MERGED,2017-07-30T07:27:31Z,2017-08-05T15:41:38Z,APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.,eddyb,c457b26e33ccd83da9055acb19f6099e4a353a12,5,rustc_trans: do not pass floating-point values to LLVM through FFI.,HEART,2018-07-30T20:59:50Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,THUMBS_UP,2017-07-30T15:21:30Z,est31,NA https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,THUMBS_UP,2017-07-30T16:47:25Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,THUMBS_UP,2017-07-30T18:26:41Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,THUMBS_UP,2017-07-31T15:28:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,THUMBS_UP,2017-08-01T07:48:57Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/43558,MERGED,2017-07-30T13:12:18Z,2017-08-07T21:05:20Z,Union const colors,GuillaumeGomez,00b362e332219e14c6516df622b0749be77b2ff9,1,Fix invalid background highlights and add missing colors,HEART,2017-08-04T13:48:42Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/43560,MERGED,2017-07-30T20:08:46Z,2017-08-01T10:49:40Z,add docs for references as a primitive,QuietMisdreavus,a2d55146938972d7eecc19f9315f86d7ecb8f94b,3,add docs for references as a primitive,HOORAY,2017-07-31T14:56:21Z,chordowl,NA https://github.com/rust-lang/rust/pull/43568,MERGED,2017-07-31T14:44:51Z,2017-08-01T17:21:13Z,trans::mir::constant - fix assignment error recovery,arielb1,93db1f9923d23c905c5cd8e7c50c5927c7c72a24,3,trans::mir::constant - fix assignment error recovery We used to not store anything when the RHS of an assignment returned an error which caused ICEs downstream. Fixes #43197.,HEART,2017-08-09T17:57:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43576,MERGED,2017-07-31T23:28:24Z,2017-08-02T01:13:05Z,rustc_mir: don't build unused unwind cleanup blocks,arielb1,ce0ca763808f4b5d153aaa2787ea253286b449ef,1,pacify the merciless tidy,HEART,2017-08-01T09:27:14Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43576,MERGED,2017-07-31T23:28:24Z,2017-08-02T01:13:05Z,rustc_mir: don't build unused unwind cleanup blocks,arielb1,ce0ca763808f4b5d153aaa2787ea253286b449ef,1,pacify the merciless tidy,HEART,2017-08-09T17:57:12Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43577,MERGED,2017-07-31T23:56:32Z,2017-08-04T20:06:16Z,Link LLVM tools dynamically,cuviper,6c46f4f11cdd56fcd12c86d121259c738b7a8376,1,Use LLVM_LINK_LLVM_DYLIB only on linux-gnu and apple-darwin,HEART,2017-08-01T09:02:37Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43577,MERGED,2017-07-31T23:56:32Z,2017-08-04T20:06:16Z,Link LLVM tools dynamically,cuviper,6c46f4f11cdd56fcd12c86d121259c738b7a8376,1,Use LLVM_LINK_LLVM_DYLIB only on linux-gnu and apple-darwin,HEART,2017-08-01T09:17:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43577,MERGED,2017-07-31T23:56:32Z,2017-08-04T20:06:16Z,Link LLVM tools dynamically,cuviper,6c46f4f11cdd56fcd12c86d121259c738b7a8376,1,Use LLVM_LINK_LLVM_DYLIB only on linux-gnu and apple-darwin,HEART,2017-08-01T17:09:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43581,MERGED,2017-08-01T01:42:22Z,2017-08-02T05:56:11Z,rustc: Inline bitwise modification operators,alexcrichton,dd371a2069e84bf58702cb4c760681ee9c8aa874,1,rustc: Inline bitwise modification operators These need to be inlined across crates to avoid showing up as one-instruction functions in profiles! In the benchmark from #43578 this decreased the translation item collection step from 30s to 23s and looks like it also allowed vectorization elsewhere of the operations!,LAUGH,2017-08-01T10:35:17Z,kennytm,NA https://github.com/rust-lang/rust/pull/43581,MERGED,2017-08-01T01:42:22Z,2017-08-02T05:56:11Z,rustc: Inline bitwise modification operators,alexcrichton,dd371a2069e84bf58702cb4c760681ee9c8aa874,1,rustc: Inline bitwise modification operators These need to be inlined across crates to avoid showing up as one-instruction functions in profiles! In the benchmark from #43578 this decreased the translation item collection step from 30s to 23s and looks like it also allowed vectorization elsewhere of the operations!,LAUGH,2017-08-09T18:02:41Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43581,MERGED,2017-08-01T01:42:22Z,2017-08-02T05:56:11Z,rustc: Inline bitwise modification operators,alexcrichton,dd371a2069e84bf58702cb4c760681ee9c8aa874,1,rustc: Inline bitwise modification operators These need to be inlined across crates to avoid showing up as one-instruction functions in profiles! In the benchmark from #43578 this decreased the translation item collection step from 30s to 23s and looks like it also allowed vectorization elsewhere of the operations!,LAUGH,2017-08-09T20:45:45Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43582,MERGED,2017-08-01T02:12:09Z,2017-08-10T11:20:22Z,Fixed mutable vars being marked used when they weren't,ivanbakel,8f78d453ded152e95d66f113d24287f12c680a15,1,Updated cargo submodule to fix compile error,HEART,2017-08-01T09:00:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43582,MERGED,2017-08-01T02:12:09Z,2017-08-10T11:20:22Z,Fixed mutable vars being marked used when they weren't,ivanbakel,8f78d453ded152e95d66f113d24287f12c680a15,1,Updated cargo submodule to fix compile error,HEART,2017-08-01T09:14:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-01T13:14:48Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-01T14:15:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-01T15:20:59Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-01T16:59:11Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-02T10:32:57Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43584,MERGED,2017-08-01T11:51:45Z,2017-08-02T08:21:58Z,Fix quadratic performance with lots of use statements,arielb1,70478ca5c83513beb91cce78ae57ade70849fca4,1,rustc::hir::map::definitions - fix O(n^2) when disambiguating Instead of finding the next free disambiguator by incrementing it until you find a place store the next available disambiguator in an hash-map. This avoids O(n^2) performance when lots of items have the same un-disambiguated `DefPathData` - e.g. all `use` items have `DefPathData::Misc`.,HEART,2017-08-02T21:34:53Z,jseyfried,NA https://github.com/rust-lang/rust/pull/43595,MERGED,2017-08-01T17:48:05Z,2017-08-09T04:03:57Z,Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization.,oyvindln,4bb9a8b4ac27b48fb7989ef2900ec12a0face475,1,Add an overflow check in the Iter::next() impl for Range<_> This helps with vectorization in some cases such as (0..u16::MAX).collect::>() as LLVM is able to change the loop condition to use equality instead of less than,THUMBS_UP,2017-08-03T02:13:03Z,Lokathor,NA https://github.com/rust-lang/rust/pull/43598,MERGED,2017-08-01T20:30:37Z,2017-08-02T05:56:13Z,Derive `Hash` on `AssociatedKind`.,ibabushkin,1b831cf54e441aa0c5d20a344f4c9f75d01d2538,1,Derive `Hash` on `AssociatedKind`. This is a trivial change useful in downstream code poking in rustc's innards.,CONFUSED,2017-08-01T20:43:55Z,kennytm,NA https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,THUMBS_UP,2017-08-02T22:41:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,THUMBS_UP,2017-08-02T22:58:03Z,trishume,tris.hume@gmail.com https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,HOORAY,2017-08-04T18:32:59Z,trishume,tris.hume@gmail.com https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,HOORAY,2017-08-04T18:49:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,HOORAY,2017-08-05T10:53:23Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/43600,MERGED,2017-08-01T21:32:52Z,2017-08-04T17:36:22Z,Add a more precise error message for issue #35976,scalexm,e7e620d0cc4ca1a971d8381a65e64efd5b66e489,2,Rename `ConfirmResult` fields,HOORAY,2017-08-22T23:39:10Z,smangelsdorf,s.mangelsdorf@gmail.com https://github.com/rust-lang/rust/pull/43604,MERGED,2017-08-02T01:59:52Z,2017-10-06T23:21:28Z,Improvements to `proc_macro::Span` API,abonander,7be36d2a6d8855c4ca8ef7ae469f9aac8bf6e63b,4,`proc_macro::Span` API improvements,THUMBS_UP,2017-09-07T08:51:30Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/43604,MERGED,2017-08-02T01:59:52Z,2017-10-06T23:21:28Z,Improvements to `proc_macro::Span` API,abonander,7be36d2a6d8855c4ca8ef7ae469f9aac8bf6e63b,4,`proc_macro::Span` API improvements,THUMBS_UP,2017-09-26T20:20:20Z,jseyfried,NA https://github.com/rust-lang/rust/pull/43604,MERGED,2017-08-02T01:59:52Z,2017-10-06T23:21:28Z,Improvements to `proc_macro::Span` API,abonander,7be36d2a6d8855c4ca8ef7ae469f9aac8bf6e63b,4,`proc_macro::Span` API improvements,THUMBS_UP,2017-12-30T08:32:17Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/43612,MERGED,2017-08-02T10:07:41Z,2017-08-02T13:40:47Z,incr.comp.: Properly incorporate symbol linkage and visibility into CGU hash.,michaelwoerister,b2c3a413b955ac89be06367f4db7706cbd88dc9c,2,incr.comp.: Properly incorporate symbol linkage and visibility into CGU hash.,HEART,2017-08-02T10:17:13Z,ranma42,NA https://github.com/rust-lang/rust/pull/43622,MERGED,2017-08-03T04:15:12Z,2017-08-03T14:21:42Z,extend config.toml doc for debug-assertions,RalfJung,62f179b36e6d890a56837d52b992bb7ad220ad27,1,extend config.toml doc,THUMBS_UP,2017-08-03T08:33:18Z,kennytm,NA https://github.com/rust-lang/rust/pull/43624,CLOSED,2017-08-03T09:10:53Z,2017-08-28T12:36:29Z,Add Cargo.lock merge driver,ishitatsuyuki,NA,NA,NA,CONFUSED,2017-08-03T13:24:55Z,kennytm,NA https://github.com/rust-lang/rust/pull/43628,MERGED,2017-08-03T14:34:26Z,2017-09-18T04:22:38Z,Run the miri test suite on the aux builder and travis,oli-obk,01555b1da1bb0fb289b1c971a046b315c751c861,2,Rebase fallout,THUMBS_UP,2017-08-14T12:59:46Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43628,MERGED,2017-08-03T14:34:26Z,2017-09-18T04:22:38Z,Run the miri test suite on the aux builder and travis,oli-obk,01555b1da1bb0fb289b1c971a046b315c751c861,2,Rebase fallout,THUMBS_UP,2017-08-19T11:03:06Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/43630,MERGED,2017-08-03T17:11:37Z,2017-08-13T07:50:40Z,Rustbuild cleanups/fixes and improvements,Mark-Simulacrum,01641c70331d704fdab05914f21921e453ae61bb,1,Build rustdoc with the native build triple,HOORAY,2017-08-03T17:13:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/43651,MERGED,2017-08-05T00:21:09Z,2017-08-16T04:00:26Z,Fix ICE with elided lifetimes in return type of foreign functions,petrochenkov,7704762604a8bf4504a06e8c9713bc7c158d362a,2,Use usual lifetime elision rules for foreign functions,HOORAY,2017-08-06T18:42:11Z,estebank,NA https://github.com/rust-lang/rust/pull/43689,MERGED,2017-08-05T17:34:32Z,2017-08-05T22:10:21Z,Fix typo in coerce_forced_unit docstring,edaniels,3bf1ba7987829fab555a767c77883d123ded729b,1,Fix typo in coerce_forced_unit docstring,LAUGH,2017-08-05T19:13:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-05T20:16:16Z,durka,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-05T22:25:49Z,bluss,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-06T20:53:47Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-08-06T20:54:06Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-06T21:32:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-08-06T21:32:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-11T20:35:01Z,Majora320,majora320@gmail.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-08-11T20:35:02Z,Majora320,majora320@gmail.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-20T21:50:27Z,alvitawa,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-22T04:27:49Z,retep998,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-22T06:00:58Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-22T11:43:01Z,arielb1,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-08-30T23:17:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-09-03T08:18:13Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-09-03T08:18:14Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-10-05T15:14:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-10-12T16:27:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-10-12T23:12:19Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2017-11-15T16:29:01Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2017-12-03T19:57:06Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HEART,2018-04-09T15:53:38Z,hcpl,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2019-01-04T14:34:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/43690,MERGED,2017-08-05T17:48:06Z,2017-08-22T04:02:48Z,Generate builtin impls for `Clone`,scalexm,d58b40e16b9466ba4e049fe0dae8b8d08df1d44d,2,Use an helper struct,HOORAY,2019-11-07T05:30:18Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/43700,MERGED,2017-08-06T17:15:32Z,2017-08-25T15:34:44Z,Adding E0623 for structs,gaurikholkar,2cd13189ce328af88b61393cd567b6eb3db9ca2b,1,build fixes,HEART,2017-09-12T22:00:24Z,krdln,NA https://github.com/rust-lang/rust/pull/43709,MERGED,2017-08-07T04:43:25Z,2017-08-07T12:35:24Z,de-orphan extended information,zackmdavis,75b7a6f1a662dab0752d189ab635580a21b06e42,1,comment out record of now-unused error code E0563 The sole appearance of this code was deleted in 6383de15; the existing practice in these cases seems to be to comment out its mention in `register_diagnostics!`.,HOORAY,2017-08-07T08:13:30Z,kennytm,NA https://github.com/rust-lang/rust/pull/43709,MERGED,2017-08-07T04:43:25Z,2017-08-07T12:35:24Z,de-orphan extended information,zackmdavis,75b7a6f1a662dab0752d189ab635580a21b06e42,1,comment out record of now-unused error code E0563 The sole appearance of this code was deleted in 6383de15; the existing practice in these cases seems to be to comment out its mention in `register_diagnostics!`.,HOORAY,2017-08-16T17:57:47Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43709,MERGED,2017-08-07T04:43:25Z,2017-08-07T12:35:24Z,de-orphan extended information,zackmdavis,75b7a6f1a662dab0752d189ab635580a21b06e42,1,comment out record of now-unused error code E0563 The sole appearance of this code was deleted in 6383de15; the existing practice in these cases seems to be to comment out its mention in `register_diagnostics!`.,HOORAY,2017-08-17T19:18:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43713,MERGED,2017-08-07T13:03:37Z,2017-08-07T18:19:16Z,rustc::middle::dataflow - visit the CFG in RPO,arielb1,4e3a0b636fffdf9d514420681dc60ecbca221f42,3,rustc::middle::dataflow - visit the CFG in RPO We used to propagate bits in node-id order which sometimes caused an excessive number of iterations especially when macros were present. As everyone knows visiting the CFG in RPO bounds the number of iterators by 1 plus the depth of the most deeply nested loop (times the height of the lattice which is 1). Fixes #43704.,HEART,2017-08-07T14:03:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43715,MERGED,2017-08-07T15:39:04Z,2017-08-11T12:09:49Z,Stop using URL shortener in docs,ollie27,49310a9d4dfea8b5b23e9a69c2d78c0dfa6d2851,1,Stop using URL shortener in docs tidy will no longer complain about long lines containing links so there is no reason to use a URL shortener here.,THUMBS_UP,2017-08-08T21:56:45Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43716,MERGED,2017-08-07T15:45:16Z,2017-09-12T04:14:08Z,Accept underscores in unicode escapes,MaloJaffre,d4e0e5228111cd47294342a60b5f8af44c65e206,8,Accept underscores in unicode escapes Fixes #43692.,HEART,2017-08-07T17:22:05Z,behnam,NA https://github.com/rust-lang/rust/pull/43716,MERGED,2017-08-07T15:45:16Z,2017-09-12T04:14:08Z,Accept underscores in unicode escapes,MaloJaffre,d4e0e5228111cd47294342a60b5f8af44c65e206,8,Accept underscores in unicode escapes Fixes #43692.,THUMBS_UP,2017-08-15T12:37:48Z,mcarton,NA https://github.com/rust-lang/rust/pull/43716,MERGED,2017-08-07T15:45:16Z,2017-09-12T04:14:08Z,Accept underscores in unicode escapes,MaloJaffre,d4e0e5228111cd47294342a60b5f8af44c65e206,8,Accept underscores in unicode escapes Fixes #43692.,HEART,2017-08-17T07:04:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/43716,MERGED,2017-08-07T15:45:16Z,2017-09-12T04:14:08Z,Accept underscores in unicode escapes,MaloJaffre,d4e0e5228111cd47294342a60b5f8af44c65e206,8,Accept underscores in unicode escapes Fixes #43692.,THUMBS_UP,2017-10-29T11:26:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43716,MERGED,2017-08-07T15:45:16Z,2017-09-12T04:14:08Z,Accept underscores in unicode escapes,MaloJaffre,d4e0e5228111cd47294342a60b5f8af44c65e206,8,Accept underscores in unicode escapes Fixes #43692.,HEART,2017-10-29T11:26:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/43723,MERGED,2017-08-07T22:10:13Z,2017-08-08T14:39:36Z,make `for_all_relevant_impls` O(1) again,arielb1,453ad8122c975dc82f6090f0c755d38932ccefc5,10,make `for_all_relevant_impls` O(1) again A change in #41911 had made `for_all_relevant_impls` do a linear scan over all impls instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixes #43141 completely but I want better measurements in order to be sure. As a perf patch please don't roll this up.,HOORAY,2017-08-08T12:43:28Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/43723,MERGED,2017-08-07T22:10:13Z,2017-08-08T14:39:36Z,make `for_all_relevant_impls` O(1) again,arielb1,453ad8122c975dc82f6090f0c755d38932ccefc5,10,make `for_all_relevant_impls` O(1) again A change in #41911 had made `for_all_relevant_impls` do a linear scan over all impls instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixes #43141 completely but I want better measurements in order to be sure. As a perf patch please don't roll this up.,HOORAY,2017-08-16T22:00:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43724,MERGED,2017-08-07T22:18:14Z,2017-08-12T22:09:39Z,Improve std::ops docs,chordowl,6bdba82ba18fe69ac448f81b10bbbc7d0c10bce1,6,std::ops docs: incorporated changes suggested in review * fixed link typos and copy-paster errors * rewrote Fn* explanations * `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as well) * fixed up some links * s/MutDeref/DerefMut * removed remaining superfluous `fn main()`s * fixed some minor phrasings and factual errors and inaccuracies std::ops docs: Fix phrasing and factual errors/inaccuracies,HEART,2017-08-12T19:06:43Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-09T10:57:51Z,killercup,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-09T11:54:51Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-09T12:25:04Z,jplatte,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-09T15:29:54Z,gamazeps,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-11T21:16:13Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-16T13:31:39Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-16T16:37:49Z,yurivish,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-16T22:13:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-17T08:07:28Z,milibopp,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-18T07:44:44Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2017-08-20T06:01:39Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2019-12-26T14:39:16Z,95th,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2020-02-24T01:24:03Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/43745,MERGED,2017-08-08T16:35:53Z,2017-08-11T09:38:04Z,Type-check `break value;` even outside of `loop {}`.,kennytm,3cb23a714f2b7adbf1eee697fb6471c4dd733f04,3,Type-check `break value;` even outside of `loop {}`. Fix #43162 fix #43727.,HEART,2021-12-13T20:31:21Z,kawaemon,me@kawaemon.dev https://github.com/rust-lang/rust/pull/43746,MERGED,2017-08-08T16:55:52Z,2017-08-12T14:24:49Z,Check #[thread_local] statics correctly in the compiler.,eddyb,92892d3beb2ab858c6e73df0cf732d2c6f83a4aa,12,Check #[thread_local] statics correctly in the compiler.,HEART,2017-08-08T17:56:34Z,est31,NA https://github.com/rust-lang/rust/pull/43746,MERGED,2017-08-08T16:55:52Z,2017-08-12T14:24:49Z,Check #[thread_local] statics correctly in the compiler.,eddyb,92892d3beb2ab858c6e73df0cf732d2c6f83a4aa,12,Check #[thread_local] statics correctly in the compiler.,HOORAY,2017-08-08T22:27:02Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43746,MERGED,2017-08-08T16:55:52Z,2017-08-12T14:24:49Z,Check #[thread_local] statics correctly in the compiler.,eddyb,92892d3beb2ab858c6e73df0cf732d2c6f83a4aa,12,Check #[thread_local] statics correctly in the compiler.,HOORAY,2017-08-09T22:15:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/43746,MERGED,2017-08-08T16:55:52Z,2017-08-12T14:24:49Z,Check #[thread_local] statics correctly in the compiler.,eddyb,92892d3beb2ab858c6e73df0cf732d2c6f83a4aa,12,Check #[thread_local] statics correctly in the compiler.,HEART,2018-12-11T14:56:18Z,hellosiyan,NA https://github.com/rust-lang/rust/pull/43746,MERGED,2017-08-08T16:55:52Z,2017-08-12T14:24:49Z,Check #[thread_local] statics correctly in the compiler.,eddyb,92892d3beb2ab858c6e73df0cf732d2c6f83a4aa,12,Check #[thread_local] statics correctly in the compiler.,HEART,2020-10-04T12:35:17Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,LAUGH,2017-08-09T07:19:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,LAUGH,2017-08-09T08:22:00Z,chordowl,NA https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,LAUGH,2017-08-09T17:57:37Z,estebank,NA https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,HOORAY,2017-08-09T19:35:39Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,LAUGH,2017-08-20T05:09:13Z,Havvy,NA https://github.com/rust-lang/rust/pull/43752,MERGED,2017-08-09T00:51:35Z,2017-08-11T12:09:52Z,Add IRC's `!union union` as a test addresses #43553,arshiamufti,0f924b86c496bf4224fc5f84b7ce40c93bb2c7a9,1,add test,HOORAY,2017-08-20T05:09:14Z,Havvy,NA https://github.com/rust-lang/rust/pull/43761,CLOSED,2017-08-09T13:40:30Z,2017-09-11T14:40:57Z,WIP implement a machine readable print-type-info API,Gankra,NA,NA,NA,HEART,2017-08-09T20:42:25Z,est31,NA https://github.com/rust-lang/rust/pull/43786,MERGED,2017-08-10T14:02:42Z,2017-08-25T05:22:31Z,Elaborate trait obligations when typechecking impls,scalexm,68fd322a957480db16f1ab0af9915056adbe07b1,1,Change to `Elaborate::None` inside `compute_projection`,THUMBS_UP,2017-08-10T19:07:00Z,behnam,NA https://github.com/rust-lang/rust/pull/43791,MERGED,2017-08-10T21:15:43Z,2017-08-11T12:09:55Z,File docs,GuillaumeGomez,972d67cec1fc0aeafebcc60ffcdf4dea0eadff8c,1,Add missing links for Error docs,HEART,2017-08-10T21:54:29Z,chordowl,NA https://github.com/rust-lang/rust/pull/43793,MERGED,2017-08-10T22:15:38Z,2017-08-11T12:09:56Z,Fix broken links in Arc documentation,j-browne,4b80d598c5a87a1b069814c8be744709a1efc460,1,Fix broken links in Arc documentation,HEART,2017-08-10T22:18:19Z,chordowl,NA https://github.com/rust-lang/rust/pull/43802,CLOSED,2017-08-11T11:41:34Z,2017-08-11T13:55:20Z,Rollup of 19 pull requests,MaloJaffre,NA,NA,NA,CONFUSED,2017-08-11T11:48:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/43813,MERGED,2017-08-11T21:12:42Z,2017-08-13T10:22:52Z,Fix unused_result lint triggering when a function returns `()` `!` or an empty enum,pengowen123,eeb748aa12a3bb7f6bbd1205385fa0a0adbef90c,2,Don't trigger unused_result on functions returning empty enums,THUMBS_UP,2017-08-12T04:06:36Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/43813,MERGED,2017-08-11T21:12:42Z,2017-08-13T10:22:52Z,Fix unused_result lint triggering when a function returns `()` `!` or an empty enum,pengowen123,eeb748aa12a3bb7f6bbd1205385fa0a0adbef90c,2,Don't trigger unused_result on functions returning empty enums,THUMBS_UP,2017-08-16T16:33:25Z,jwgarber,NA https://github.com/rust-lang/rust/pull/43814,MERGED,2017-08-11T21:43:31Z,2017-08-13T12:57:09Z,Fix some typos,Eijebong,3ab86fbab281ca059731c31fa2aee5d9afc7e6dc,53,Fix some typos,HOORAY,2017-08-12T00:12:54Z,chordowl,NA https://github.com/rust-lang/rust/pull/43814,MERGED,2017-08-11T21:43:31Z,2017-08-13T12:57:09Z,Fix some typos,Eijebong,3ab86fbab281ca059731c31fa2aee5d9afc7e6dc,53,Fix some typos,LAUGH,2017-08-12T08:22:22Z,kennytm,NA https://github.com/rust-lang/rust/pull/43814,MERGED,2017-08-11T21:43:31Z,2017-08-13T12:57:09Z,Fix some typos,Eijebong,3ab86fbab281ca059731c31fa2aee5d9afc7e6dc,53,Fix some typos,HOORAY,2017-08-16T20:59:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/43817,CLOSED,2017-08-12T00:39:46Z,2017-08-12T07:48:27Z,[gitignore] Add compiler-rt and rust-installer,behnam,NA,NA,NA,THUMBS_DOWN,2017-08-12T06:10:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/43820,MERGED,2017-08-12T05:25:24Z,2017-08-12T19:18:47Z,Move config.toml.example to the root dir,sfackler,1126a85e87629f7ec37fc6c4fde43419f4b9947f,5,Move config.toml.example to the root dir It's way more discoverable here.,THUMBS_UP,2017-08-12T11:02:00Z,retep998,NA https://github.com/rust-lang/rust/pull/43820,MERGED,2017-08-12T05:25:24Z,2017-08-12T19:18:47Z,Move config.toml.example to the root dir,sfackler,1126a85e87629f7ec37fc6c4fde43419f4b9947f,5,Move config.toml.example to the root dir It's way more discoverable here.,HOORAY,2017-08-12T11:02:02Z,retep998,NA https://github.com/rust-lang/rust/pull/43820,MERGED,2017-08-12T05:25:24Z,2017-08-12T19:18:47Z,Move config.toml.example to the root dir,sfackler,1126a85e87629f7ec37fc6c4fde43419f4b9947f,5,Move config.toml.example to the root dir It's way more discoverable here.,THUMBS_UP,2017-08-12T11:34:08Z,est31,NA https://github.com/rust-lang/rust/pull/43820,MERGED,2017-08-12T05:25:24Z,2017-08-12T19:18:47Z,Move config.toml.example to the root dir,sfackler,1126a85e87629f7ec37fc6c4fde43419f4b9947f,5,Move config.toml.example to the root dir It's way more discoverable here.,HEART,2017-08-12T11:34:11Z,est31,NA https://github.com/rust-lang/rust/pull/43823,MERGED,2017-08-12T11:46:16Z,2017-08-12T16:48:40Z,Update GitHub pull request documentation link,tchajed,a746129bdb50186994c6f62769ff043bb58f6fd7,1,Update GitHub pull request documentation link,HEART,2017-08-12T12:19:41Z,chordowl,NA https://github.com/rust-lang/rust/pull/43830,MERGED,2017-08-12T22:35:51Z,2017-08-23T06:06:28Z,std: Respect formatting flags for str-like OsStr,alexcrichton,742ca0caf25813ee30b70d9e29ab3eacb0076302,4,"std: Respect formatting flags for str-like OsStr Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy` but this was updated in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the ""common case"" where where `OsStr`-like ""thing"" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags) but this should solve the regression for all ""real world"" use cases of paths and such. The door's also still open for handling these flags in the future! Closes #43765",THUMBS_UP,2017-08-13T03:56:22Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/43830,MERGED,2017-08-12T22:35:51Z,2017-08-23T06:06:28Z,std: Respect formatting flags for str-like OsStr,alexcrichton,742ca0caf25813ee30b70d9e29ab3eacb0076302,4,"std: Respect formatting flags for str-like OsStr Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy` but this was updated in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the ""common case"" where where `OsStr`-like ""thing"" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags) but this should solve the regression for all ""real world"" use cases of paths and such. The door's also still open for handling these flags in the future! Closes #43765",THUMBS_UP,2017-08-16T00:09:34Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/43833,MERGED,2017-08-13T02:24:36Z,2017-08-13T12:57:11Z,Fix TcpStream::connect_timeout tracking issue number,dtolnay,aea61e6005dabf3a5c85dbb4fda33544c7808f16,1,Fix TcpStream::connect_timeout tracking issue number,LAUGH,2017-08-13T08:12:11Z,kennytm,NA https://github.com/rust-lang/rust/pull/43847,CLOSED,2017-08-13T16:16:43Z,2017-11-13T16:38:59Z,Add expansion info to crate metadata,ibabushkin,NA,NA,NA,THUMBS_UP,2017-08-14T17:27:10Z,jseyfried,NA https://github.com/rust-lang/rust/pull/43849,MERGED,2017-08-13T18:04:22Z,2017-09-06T14:14:19Z,"rustdoc: add new ""Implementations on Foreign Types"" section to traits",QuietMisdreavus,a9f0f6df94c4d08fe300b6e06941aea9c7324530,1,"add ""Implementations on Foreign Types"" to the sidebar",THUMBS_UP,2017-08-13T18:09:08Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/43849,MERGED,2017-08-13T18:04:22Z,2017-09-06T14:14:19Z,"rustdoc: add new ""Implementations on Foreign Types"" section to traits",QuietMisdreavus,a9f0f6df94c4d08fe300b6e06941aea9c7324530,1,"add ""Implementations on Foreign Types"" to the sidebar",THUMBS_UP,2017-08-13T18:32:08Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/43849,MERGED,2017-08-13T18:04:22Z,2017-09-06T14:14:19Z,"rustdoc: add new ""Implementations on Foreign Types"" section to traits",QuietMisdreavus,a9f0f6df94c4d08fe300b6e06941aea9c7324530,1,"add ""Implementations on Foreign Types"" to the sidebar",CONFUSED,2017-08-13T18:44:10Z,kennytm,NA https://github.com/rust-lang/rust/pull/43849,MERGED,2017-08-13T18:04:22Z,2017-09-06T14:14:19Z,"rustdoc: add new ""Implementations on Foreign Types"" section to traits",QuietMisdreavus,a9f0f6df94c4d08fe300b6e06941aea9c7324530,1,"add ""Implementations on Foreign Types"" to the sidebar",HEART,2017-08-13T23:35:11Z,chordowl,NA https://github.com/rust-lang/rust/pull/43854,MERGED,2017-08-13T21:59:45Z,2017-08-22T07:13:21Z,Point out missing if conditional,estebank,f06323337dd0cf748e8a0ca49d91dac2eae6b4a9,4,Verify that an `if` condition block returns a value,HEART,2017-08-31T08:22:10Z,cristicbz,NA https://github.com/rust-lang/rust/pull/43863,MERGED,2017-08-14T17:59:40Z,2017-08-15T10:12:35Z,Ship the rustdoc book,steveklabnik,2c6cf22a30bf09eb5183b1326e6c74347df72f77,3,Remove plugins chapter we don't want to support plugins,HOORAY,2017-08-24T11:26:50Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/43863,MERGED,2017-08-14T17:59:40Z,2017-08-15T10:12:35Z,Ship the rustdoc book,steveklabnik,2c6cf22a30bf09eb5183b1326e6c74347df72f77,3,Remove plugins chapter we don't want to support plugins,HEART,2017-08-24T11:26:52Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/43863,MERGED,2017-08-14T17:59:40Z,2017-08-15T10:12:35Z,Ship the rustdoc book,steveklabnik,2c6cf22a30bf09eb5183b1326e6c74347df72f77,3,Remove plugins chapter we don't want to support plugins,THUMBS_UP,2017-08-24T11:26:54Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/43873,CLOSED,2017-08-15T03:23:13Z,2017-08-15T16:20:00Z,rustbuild: Set ignore-git based on `channel`,alexcrichton,NA,NA,NA,HEART,2017-08-15T07:29:23Z,est31,NA https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-08-15T15:28:30Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-08-16T07:49:46Z,mcarton,NA https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-08-17T18:44:16Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-09-07T07:58:15Z,cristicbz,NA https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-09-07T18:12:02Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/43886,MERGED,2017-08-15T15:13:50Z,2017-09-02T19:46:56Z,Add clippy as a submodule,oli-obk,20f1e6809e302e0a6353ccf744916b47a1f2535c,1,Require adding clippy's path to the `x.py` invocation,HOORAY,2017-09-08T08:04:56Z,hoodie,NA https://github.com/rust-lang/rust/pull/43890,CLOSED,2017-08-15T19:44:45Z,2017-08-22T20:38:58Z,add try_reserve and try_reserve_exact to Vec,Gankra,NA,NA,NA,HEART,2017-08-15T19:47:50Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/43895,MERGED,2017-08-16T01:42:59Z,2017-08-30T18:35:00Z,make ignore-git true by default when channel is dev,JeremySorensen,4f591a47d5c165785a8715f39fc6474c4e33a57f,1,fix option for RUST_CONFIGURE_ARGS to be rust.ignore-git=false,THUMBS_UP,2017-08-16T10:09:14Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/43911,MERGED,2017-08-16T20:12:33Z,2017-08-20T09:39:19Z,Update jemalloc to 4.5.0,arthurprs,519cf15ea6bcc72bc574f34f69690e16b2e548bb,2,Update jemalloc to 4.5.0,THUMBS_UP,2017-08-17T17:26:27Z,RalfJung,NA https://github.com/rust-lang/rust/pull/43928,MERGED,2017-08-17T09:02:08Z,2017-08-17T19:54:06Z,Fixed typo in RefCell::get_mut,anthonyclays,fa346fc5d661d39fd7806b13b55a3d6f6ed33cb1,1,Fixed typo in RefCell::get_mut,THUMBS_UP,2017-08-17T12:41:22Z,chordowl,NA https://github.com/rust-lang/rust/pull/43928,MERGED,2017-08-17T09:02:08Z,2017-08-17T19:54:06Z,Fixed typo in RefCell::get_mut,anthonyclays,fa346fc5d661d39fd7806b13b55a3d6f6ed33cb1,1,Fixed typo in RefCell::get_mut,THUMBS_UP,2017-08-17T13:52:32Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/43928,MERGED,2017-08-17T09:02:08Z,2017-08-17T19:54:06Z,Fixed typo in RefCell::get_mut,anthonyclays,fa346fc5d661d39fd7806b13b55a3d6f6ed33cb1,1,Fixed typo in RefCell::get_mut,THUMBS_UP,2017-08-17T14:00:56Z,Cldfire,NA https://github.com/rust-lang/rust/pull/43929,MERGED,2017-08-17T09:15:56Z,2017-08-21T07:46:19Z,Improve placement of `use` suggestions,oli-obk,8f563226942570490ca77ea5ebfcc19fb3cf4089,2,Add an additional empty line between the suggested `use` and the next item,HOORAY,2017-08-17T17:26:23Z,kennytm,NA https://github.com/rust-lang/rust/pull/43929,MERGED,2017-08-17T09:15:56Z,2017-08-21T07:46:19Z,Improve placement of `use` suggestions,oli-obk,8f563226942570490ca77ea5ebfcc19fb3cf4089,2,Add an additional empty line between the suggested `use` and the next item,HOORAY,2017-08-21T04:47:24Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/43929,MERGED,2017-08-17T09:15:56Z,2017-08-21T07:46:19Z,Improve placement of `use` suggestions,oli-obk,8f563226942570490ca77ea5ebfcc19fb3cf4089,2,Add an additional empty line between the suggested `use` and the next item,HOORAY,2017-08-31T17:28:17Z,RalfJung,NA https://github.com/rust-lang/rust/pull/43930,MERGED,2017-08-17T09:47:10Z,2017-08-17T19:54:06Z,Fix ES5 regression with shorthand names.,pravic,cb4a2d5078684bd8d7461e530754fd135ce27761,1,Fix ES5 regression with shorthand names. Reverts 1b6c9605e4.,LAUGH,2017-08-17T09:47:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/43930,MERGED,2017-08-17T09:47:10Z,2017-08-17T19:54:06Z,Fix ES5 regression with shorthand names.,pravic,cb4a2d5078684bd8d7461e530754fd135ce27761,1,Fix ES5 regression with shorthand names. Reverts 1b6c9605e4.,THUMBS_UP,2017-08-17T09:48:33Z,kennytm,NA https://github.com/rust-lang/rust/pull/43930,MERGED,2017-08-17T09:47:10Z,2017-08-17T19:54:06Z,Fix ES5 regression with shorthand names.,pravic,cb4a2d5078684bd8d7461e530754fd135ce27761,1,Fix ES5 regression with shorthand names. Reverts 1b6c9605e4.,LAUGH,2017-08-17T13:16:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/43950,MERGED,2017-08-17T20:59:55Z,2017-08-20T04:50:33Z,Add x86_64-unknown-redox to build manifest target list,jackpot51,2fdade4c2a7ce63130645b608d081ce277107555,1,Add x86_64-unknown-redox to build manifest target list,THUMBS_UP,2017-08-18T20:01:58Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/43968,MERGED,2017-08-18T00:11:18Z,2017-08-30T13:56:59Z,Make fields of `Span` private,petrochenkov,a0c32641fd8bff11b657bfb87d9ade5487d336ae,1,Make fields of `Span` public again This helps to avoid landing changes to rustc and rustfmt in one step,HEART,2017-08-18T06:25:16Z,estebank,NA https://github.com/rust-lang/rust/pull/43979,MERGED,2017-08-18T17:43:33Z,2017-08-26T17:48:37Z,Add links for impls,Jouan,4729f22f8b3cc9faaf147909c6fbec3f9e434d4c,1,Fixed changes to .in-band CSS :target will specifically override .in-band background,THUMBS_UP,2017-08-19T21:29:29Z,mcarton,NA https://github.com/rust-lang/rust/pull/43986,MERGED,2017-08-19T11:27:51Z,2017-08-21T10:42:47Z,rustc: Remove some dead code,petrochenkov,de4dbe5789d1a4f11c50aa891f9c9cad13860370,59,rustc: Remove some dead code,HEART,2017-08-19T12:12:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43990,MERGED,2017-08-19T20:43:16Z,2017-08-19T23:54:05Z,librustc_typeck: store a DefId rather than a Name,tamird,ceeb399cead1659989470c757bd0fa93cb95826e,4,librustc_typeck: store a DefId rather than a Name,THUMBS_UP,2017-08-19T20:49:35Z,tbg,tobias.schottdorf@gmail.com https://github.com/rust-lang/rust/pull/43994,MERGED,2017-08-19T23:54:43Z,2017-08-26T01:29:01Z,*: remove crate_{name type} attributes,tamird,b3f50caee0e2f2f4d44e1c83bf73a112c2a398b1,49,*: remove crate_{name type} attributes Fixes #41701.,HEART,2017-08-19T23:59:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/43994,MERGED,2017-08-19T23:54:43Z,2017-08-26T01:29:01Z,*: remove crate_{name type} attributes,tamird,b3f50caee0e2f2f4d44e1c83bf73a112c2a398b1,49,*: remove crate_{name type} attributes Fixes #41701.,THUMBS_UP,2017-08-23T02:50:10Z,tbg,tobias.schottdorf@gmail.com https://github.com/rust-lang/rust/pull/44003,MERGED,2017-08-20T21:21:20Z,2017-08-22T11:15:23Z,Add PartialEq/Eq impls to proc_macro::{Spacing Delimiter},LukasKalbertodt,4ba242b7e0197f91c131c7ba7c160e7318aced04,1,Add PartialEq/Eq impls to proc_macro::{Spacing Delimiter} I don't see a reason why those two types shouldn't be tested for equality.,THUMBS_UP,2017-08-21T20:21:14Z,jseyfried,NA https://github.com/rust-lang/rust/pull/44042,MERGED,2017-08-22T18:01:59Z,2017-11-05T14:18:20Z,Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later,LukasKalbertodt,ea55596d5bc29708232a0bb232bf35d5e2e6cbce,1,Relax #[deny(warnings)] in some crate for cargotest Otherwise changes to the compiler are unable to introduce new warnings: some crates tested by cargotest deny all warnings and thus the CI build fails. Thanks SimonSapin for the patch!,THUMBS_UP,2017-11-04T05:53:37Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/44042,MERGED,2017-08-22T18:01:59Z,2017-11-05T14:18:20Z,Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later,LukasKalbertodt,ea55596d5bc29708232a0bb232bf35d5e2e6cbce,1,Relax #[deny(warnings)] in some crate for cargotest Otherwise changes to the compiler are unable to introduce new warnings: some crates tested by cargotest deny all warnings and thus the CI build fails. Thanks SimonSapin for the patch!,THUMBS_UP,2017-11-06T08:33:52Z,behnam,NA https://github.com/rust-lang/rust/pull/44051,MERGED,2017-08-22T23:49:14Z,2017-08-25T00:04:19Z,Speed up APFloat division by using short division for small divisors.,eddyb,b9c69ec3c3a318b8279ec69b3548e0dfdd462038,1,Speed up APFloat division by using short division for small divisors.,HEART,2017-08-22T23:53:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44051,MERGED,2017-08-22T23:49:14Z,2017-08-25T00:04:19Z,Speed up APFloat division by using short division for small divisors.,eddyb,b9c69ec3c3a318b8279ec69b3548e0dfdd462038,1,Speed up APFloat division by using short division for small divisors.,HEART,2017-08-30T23:07:44Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44053,MERGED,2017-08-23T02:43:09Z,2017-08-25T20:11:36Z,appveyor: Use InnoSetup from our mirror,alexcrichton,4d7dfc140733c462f4b20ca7a23013af100e4786,1,appveyor: Use InnoSetup from our mirror Chocolatey has been pretty flaky so let's not rely on it. Closes #43985,THUMBS_UP,2017-08-23T08:57:04Z,kennytm,NA https://github.com/rust-lang/rust/pull/44070,MERGED,2017-08-24T13:43:31Z,2017-08-25T02:43:28Z,Do not assume libunwind.a is available on musl,smaeul,dbcaf6c80aeb5be4fe09f157febc47bc52710616,1,Do not assume libunwind.a is available,THUMBS_UP,2017-08-25T09:33:08Z,clux,NA https://github.com/rust-lang/rust/pull/44084,MERGED,2017-08-25T17:12:17Z,2017-08-26T23:11:51Z,rustbuild: Automatically enable Ninja on MSVC,alexcrichton,e13f02eb2e188a3d8c2a5f7ba20823a85ab14307,1,"rustbuild: Automatically enable Ninja on MSVC Discovered in #43767 it turns out the default MSBuild generator in CMake for whatever reason isn't supporting many of the configuration options we give to LLVM. To improve the contributor experience automatically enable Ninja if we find it to ensure that ""flavorful"" configurations of LLVM work by default in more situations. Closes #43767",HOORAY,2017-08-25T18:39:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44086,MERGED,2017-08-25T17:35:52Z,2017-08-26T17:48:41Z,Allow `htmldocck.py` to run using Python 3,kennytm,6a721317ff0621a97690dc573ced88274d860e84,1,Allow htmldocck to run using Python 3.,HOORAY,2017-08-25T17:52:05Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/44086,MERGED,2017-08-25T17:35:52Z,2017-08-26T17:48:41Z,Allow `htmldocck.py` to run using Python 3,kennytm,6a721317ff0621a97690dc573ced88274d860e84,1,Allow htmldocck to run using Python 3.,HOORAY,2017-08-25T18:30:52Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/44086,MERGED,2017-08-25T17:35:52Z,2017-08-26T17:48:41Z,Allow `htmldocck.py` to run using Python 3,kennytm,6a721317ff0621a97690dc573ced88274d860e84,1,Allow htmldocck to run using Python 3.,HOORAY,2017-08-26T15:28:36Z,mcarton,NA https://github.com/rust-lang/rust/pull/44086,MERGED,2017-08-25T17:35:52Z,2017-08-26T17:48:41Z,Allow `htmldocck.py` to run using Python 3,kennytm,6a721317ff0621a97690dc573ced88274d860e84,1,Allow htmldocck to run using Python 3.,HOORAY,2017-08-26T18:50:44Z,projektir,NA https://github.com/rust-lang/rust/pull/44088,MERGED,2017-08-25T18:48:03Z,2017-09-17T16:29:28Z,"Fix ""new trace_macros doesn't work if there's an error during expansion""",bjorn3,0a2c95b6eb4ef40be166cc690bf2f4f00e37d7c5,1,Fix test,HEART,2017-09-17T18:32:55Z,estebank,NA https://github.com/rust-lang/rust/pull/44089,MERGED,2017-08-25T20:35:15Z,2017-08-31T03:54:09Z,rustc: Fix proc_macro expansions on trait methods,alexcrichton,ce322eedff7d665ed3e5ea142ac6bb40d6a72c66,3,rustc: Fix proc_macro expansions on trait methods This commit fixes procedural macro attributes being attached to trait methods ensuring that they get resolved and expanded as other procedural macro attributes. The bug here was that `current_module` on the resolver was accidentally set to be a trait when it's otherwise only ever expecting a `mod`/block module. The actual fix here came from @jseyfried I'm just helping to land it in the compiler! Closes #42493,THUMBS_UP,2017-08-29T00:48:55Z,jseyfried,NA https://github.com/rust-lang/rust/pull/44094,MERGED,2017-08-26T03:29:06Z,2017-09-07T06:52:10Z,rustc: Attempt to handle super long linker invocations,alexcrichton,ed938f08a949cb487f7513d4f22f92355a40d2f3,7,rustc: Attempt to handle super long linker invocations This commit adds logic to the compiler to attempt to handle super long linker invocations by falling back to the `@`-file syntax if the invoked command is too large. Each OS has a limit on how many arguments and how large the arguments can be when spawning a new process and linkers tend to be one of those programs that can hit the limit! The logic implemented here is to unconditionally attempt to spawn a linker and then if it fails to spawn with an error from the OS that indicates the command line is too big we attempt a fallback. The fallback is roughly the same for all linkers where an argument pointing to a file prepended with `@` is passed. This file then contains all the various arguments that we want to pass to the linker. Closes #41190,HOORAY,2017-09-01T20:28:20Z,retep998,NA https://github.com/rust-lang/rust/pull/44094,MERGED,2017-08-26T03:29:06Z,2017-09-07T06:52:10Z,rustc: Attempt to handle super long linker invocations,alexcrichton,ed938f08a949cb487f7513d4f22f92355a40d2f3,7,rustc: Attempt to handle super long linker invocations This commit adds logic to the compiler to attempt to handle super long linker invocations by falling back to the `@`-file syntax if the invoked command is too large. Each OS has a limit on how many arguments and how large the arguments can be when spawning a new process and linkers tend to be one of those programs that can hit the limit! The logic implemented here is to unconditionally attempt to spawn a linker and then if it fails to spawn with an error from the OS that indicates the command line is too big we attempt a fallback. The fallback is roughly the same for all linkers where an argument pointing to a file prepended with `@` is passed. This file then contains all the various arguments that we want to pass to the linker. Closes #41190,THUMBS_UP,2017-09-01T20:28:22Z,retep998,NA https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HOORAY,2017-08-26T22:16:23Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HEART,2017-08-26T22:16:25Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HEART,2017-08-26T22:35:40Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HOORAY,2017-08-27T15:43:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HEART,2017-08-27T15:43:59Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HOORAY,2017-08-28T01:41:56Z,retep998,NA https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,THUMBS_UP,2017-08-28T01:41:59Z,retep998,NA https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HOORAY,2017-08-28T03:58:59Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HEART,2017-08-28T03:59:01Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/44107,MERGED,2017-08-26T22:08:09Z,2017-08-28T08:47:55Z,rustbuild: Rewrite the configure script in Python,alexcrichton,a9b0a7ba935c79b45effcc2f55eb056bd087d9a4,8,rustbuild: Rewrite the configure script in Python This commit rewrites our ancient `./configure` script from shell into Python. The impetus for this change is to remove `config.mk` which is just a vestige of the old makefile build system at this point. Instead all configuration is now solely done through `config.toml`. The python script allows us to more flexibly program (aka we can use loops easily) and create a `config.toml` which is based off `config.toml.example`. This way we can preserve comments and munge various values as we see fit. It is intended that the configure script here is a drop-in replacement for the previous configure script no functional change is intended. Also note that the rationale for this is also because our build system requires Python so having a python script a bit earlier shouldn't cause too many problems. Closes #40730,HEART,2017-09-08T22:16:34Z,bluss,NA https://github.com/rust-lang/rust/pull/44108,MERGED,2017-08-26T22:14:37Z,2017-09-03T00:51:51Z,Implement RFC 1925,mattico,22ca03bde660e9bca0fbf23b5ab228441d39ab6f,1,Fix unstable book example,THUMBS_UP,2017-09-06T22:28:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44116,MERGED,2017-08-27T17:33:59Z,2017-08-31T03:54:10Z,Update the libc submodule,alexcrichton,e5b123cba250b02e2cd8fad0c0bd6bb519e051d2,5,Update the libc submodule Brings in a few fixes for wasm/asmjs,HOORAY,2017-08-27T19:35:59Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HEART,2017-08-28T11:08:50Z,est31,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HOORAY,2017-08-28T11:08:53Z,est31,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HEART,2017-08-28T12:23:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HOORAY,2017-08-28T15:35:58Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HOORAY,2017-08-28T18:42:03Z,jseyfried,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HEART,2017-08-29T19:02:12Z,plietar,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HOORAY,2017-08-29T22:16:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HEART,2017-08-29T22:16:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HEART,2017-09-18T13:24:22Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/44125,MERGED,2017-08-28T10:06:40Z,2017-08-31T03:54:10Z,Initial diagnostic API for proc-macros.,SergioBenitez,8be132e9d76232feb2376de9edcbb34fe3ac99ac,9,Initial diagnostic API for proc-macros. This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros allowing for proc-macro authors to emit warning error note and help messages just like the compiler does.,HOORAY,2020-04-19T15:59:40Z,msrd0,NA https://github.com/rust-lang/rust/pull/44134,MERGED,2017-08-28T19:31:10Z,2017-08-30T00:24:06Z,Fail ./x.py on invalid command,vorner,6fc35de5e88bb4035fa2a2be28b09d01fc8ebd53,1,Fail ./x.py on invalid command Make the ./x.py script fail when run with an invalid command like: ./x.py nonsense This helps in case of chaining multiple runs eg.: ./x.py biuld && ./x.py test,THUMBS_UP,2017-08-28T21:40:28Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44138,MERGED,2017-08-28T23:33:35Z,2017-10-18T21:02:29Z,Deprecate several flags in rustdoc,steveklabnik,045ce183cc6f34ec8315b2a99d22b9563c714a08,3,modify tests to use new flag,THUMBS_UP,2017-09-24T13:19:46Z,bjorn3,NA https://github.com/rust-lang/rust/pull/44142,MERGED,2017-08-29T01:34:40Z,2017-09-08T14:42:10Z,Migrate a slew of metadata methods to queries,alexcrichton,fd0aa647f3abaf6667dcde5b44e673e172c8a63b,16,rustc: Remove `CrateStore::crates` as a method This commit moves the `crates` method to a query and then migrates all callers to use a query instead of the now-renamed `crates_untracked` method where possible. Closes #41417,HEART,2017-09-04T14:12:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44148,MERGED,2017-08-29T09:47:39Z,2017-08-31T08:52:05Z,[beta] Track closure signatures & kinds in freshened types,arielb1,b2a46613c1ade97a35f6b5259fbbb9f1ca1ffaca,2,Track closure signatures & kinds in freshened types This allows caching closure signatures and kinds in the normal selection and evaluation caches and fixes the exponential worst-case in @remram44's example which is a part of #43787. This improvement is complenentary to #43999 - they fix different cases.,HOORAY,2017-08-29T19:21:58Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/44154,MERGED,2017-08-29T14:49:52Z,2017-09-01T19:20:04Z,Bump to 1.22.0 and update boostrap compiler,alexcrichton,271c63c18925725a9451c3e769e327f5c5a1167c,1,Update git2-rs to fix cross compiles,HOORAY,2017-08-29T15:28:56Z,est31,NA https://github.com/rust-lang/rust/pull/44154,MERGED,2017-08-29T14:49:52Z,2017-09-01T19:20:04Z,Bump to 1.22.0 and update boostrap compiler,alexcrichton,271c63c18925725a9451c3e769e327f5c5a1167c,1,Update git2-rs to fix cross compiles,HOORAY,2017-08-30T18:12:59Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44154,MERGED,2017-08-29T14:49:52Z,2017-09-01T19:20:04Z,Bump to 1.22.0 and update boostrap compiler,alexcrichton,271c63c18925725a9451c3e769e327f5c5a1167c,1,Update git2-rs to fix cross compiles,HOORAY,2017-09-01T06:07:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44167,MERGED,2017-08-29T21:24:03Z,2017-11-12T23:31:57Z,Improve SubSupConflict with a named and an anonymous lifetime parameter #42701,cengizIO,f53fc572978b7a544bedeb819aa656f0aef96e11,1,update project-fn-test-invariant test,HEART,2017-10-10T06:52:05Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44167,MERGED,2017-08-29T21:24:03Z,2017-11-12T23:31:57Z,Improve SubSupConflict with a named and an anonymous lifetime parameter #42701,cengizIO,f53fc572978b7a544bedeb819aa656f0aef96e11,1,update project-fn-test-invariant test,HOORAY,2017-11-13T14:51:55Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44174,MERGED,2017-08-30T05:22:31Z,2017-09-30T01:31:45Z,Add blanket TryFrom impl when From is implemented.,jimmycuadra,27d95d3645761252caf42c77fc53b76b4278520a,1,Fix more TryFrom impls for integers.,HOORAY,2017-10-04T20:52:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44174,MERGED,2017-08-30T05:22:31Z,2017-09-30T01:31:45Z,Add blanket TryFrom impl when From is implemented.,jimmycuadra,27d95d3645761252caf42c77fc53b76b4278520a,1,Fix more TryFrom impls for integers.,CONFUSED,2018-01-09T08:01:24Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/44174,MERGED,2017-08-30T05:22:31Z,2017-09-30T01:31:45Z,Add blanket TryFrom impl when From is implemented.,jimmycuadra,27d95d3645761252caf42c77fc53b76b4278520a,1,Fix more TryFrom impls for integers.,CONFUSED,2022-02-27T21:18:20Z,max-sixty,NA https://github.com/rust-lang/rust/pull/44204,MERGED,2017-08-31T01:46:09Z,2017-09-01T04:49:28Z,RLS on beta,nrc,80a77b642066a967c5f06e4803871d65dcb91d82,1,Rename the rls component to rls-preview on beta/stable,HOORAY,2017-09-01T05:00:30Z,protomors,protomors@gmail.com https://github.com/rust-lang/rust/pull/44207,CLOSED,2017-08-31T02:53:07Z,2017-09-01T08:28:20Z,add `fn` to syntax of rustc::ty::maps::define_maps,durka,NA,NA,NA,HOORAY,2017-08-31T06:48:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-09-03T09:35:22Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-09-04T03:46:50Z,nelsonjchen,nelson@mindflakes.com https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-09-13T21:55:43Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-09-13T22:42:51Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-10-29T11:29:34Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-20T12:09:23Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-21T06:06:53Z,emoon,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-21T16:54:26Z,carols10cents,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-23T00:40:06Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-23T05:04:37Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-23T11:45:54Z,mattgathu,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-29T18:57:42Z,estebank,NA https://github.com/rust-lang/rust/pull/44251,MERGED,2017-09-01T19:47:28Z,2017-09-09T21:08:24Z,Add libbacktrace support for Apple platforms (resubmitted),kennytm,aa6bd117bbe05930476b4aec1001fff77ce66348,1,Fix missing line numbers on i686.,HOORAY,2017-11-29T20:47:07Z,donhcd,NA https://github.com/rust-lang/rust/pull/44261,MERGED,2017-09-02T04:36:05Z,2017-09-03T21:32:40Z,rustc: Flag {i u}128 as unsafe for FFI,alexcrichton,549dd105273a5141003b6054c6f496f62e059cfb,2,rustc: Flag {i u}128 as unsafe for FFI These don't appear to have a stable ABI as noted in #41799 and the work in compiler-builtins definitely seems to be confirming it!,THUMBS_UP,2017-09-02T05:46:18Z,kennytm,NA https://github.com/rust-lang/rust/pull/44261,MERGED,2017-09-02T04:36:05Z,2017-09-03T21:32:40Z,rustc: Flag {i u}128 as unsafe for FFI,alexcrichton,549dd105273a5141003b6054c6f496f62e059cfb,2,rustc: Flag {i u}128 as unsafe for FFI These don't appear to have a stable ABI as noted in #41799 and the work in compiler-builtins definitely seems to be confirming it!,HEART,2017-09-02T21:33:56Z,est31,NA https://github.com/rust-lang/rust/pull/44261,MERGED,2017-09-02T04:36:05Z,2017-09-03T21:32:40Z,rustc: Flag {i u}128 as unsafe for FFI,alexcrichton,549dd105273a5141003b6054c6f496f62e059cfb,2,rustc: Flag {i u}128 as unsafe for FFI These don't appear to have a stable ABI as noted in #41799 and the work in compiler-builtins definitely seems to be confirming it!,THUMBS_UP,2017-09-07T06:59:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44262,MERGED,2017-09-02T05:30:51Z,2017-09-10T15:32:24Z,rustc: Separately feature gate repr(i128),alexcrichton,51a478c90b31c1b2248a1d24fa933c570048593c,3,rustc: Separately feature gate repr(i128) Brought up during the discussion of #35118 the support for this is still somewhat buggy and so stabilization likely wants to be considered independently of the type itself.,HEART,2017-09-02T21:34:03Z,est31,NA https://github.com/rust-lang/rust/pull/44262,MERGED,2017-09-02T05:30:51Z,2017-09-10T15:32:24Z,rustc: Separately feature gate repr(i128),alexcrichton,51a478c90b31c1b2248a1d24fa933c570048593c,3,rustc: Separately feature gate repr(i128) Brought up during the discussion of #35118 the support for this is still somewhat buggy and so stabilization likely wants to be considered independently of the type itself.,HOORAY,2017-09-04T21:00:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44263,MERGED,2017-09-02T06:00:48Z,2017-09-04T00:03:51Z,stabilize mem::discriminant (closes #24263),durka,d51643498142b2b33cdad02f4f9dcfe627d52a83,5,stabilize mem::discriminant (closes #24263),HOORAY,2017-09-02T15:29:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HEART,2017-09-02T16:51:10Z,est31,NA https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HOORAY,2017-09-02T17:36:41Z,kennytm,NA https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HEART,2017-09-02T21:37:24Z,mcarton,NA https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HOORAY,2017-09-08T20:08:02Z,bvssvni,bvssvni@gmail.com https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HOORAY,2017-09-12T09:40:05Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HEART,2017-09-12T09:40:06Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44275,MERGED,2017-09-02T16:46:48Z,2017-09-12T06:49:50Z,Evaluate fixed-length array length expressions lazily.,eddyb,57ebd28fdb69d7cc4df3de343664e6698a4b55f0,8,rustc: use ConstVal::Unevaluated instead of mir::Literal::Item.,HEART,2017-09-20T14:06:28Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/44278,MERGED,2017-09-02T21:57:23Z,2017-09-28T22:53:06Z,Allow replacing HashMap entries,Binero,d3de465dc85638a6a77298638ebbbfab04b1844d,1,Addressed @BurntSuchi's remarks regarding Entry::replace,THUMBS_UP,2017-10-03T22:05:24Z,artemshein,NA https://github.com/rust-lang/rust/pull/44278,MERGED,2017-09-02T21:57:23Z,2017-09-28T22:53:06Z,Allow replacing HashMap entries,Binero,d3de465dc85638a6a77298638ebbbfab04b1844d,1,Addressed @BurntSuchi's remarks regarding Entry::replace,THUMBS_UP,2020-01-14T22:26:05Z,CGMossa,NA https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_DOWN,2017-09-03T13:39:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_UP,2017-09-04T20:53:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_UP,2017-09-09T20:34:51Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_UP,2017-09-11T18:31:35Z,bluss,NA https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_UP,2017-09-13T14:12:15Z,Migi,michieldemuynck@gmail.com https://github.com/rust-lang/rust/pull/44287,CLOSED,2017-09-03T13:16:32Z,2017-09-30T15:02:53Z,Allow T op= &T for built-in numeric types T v2,Eh2406,NA,NA,NA,THUMBS_UP,2019-08-12T08:09:49Z,OnlyLys,NA https://github.com/rust-lang/rust/pull/44295,MERGED,2017-09-03T18:57:18Z,2017-10-28T16:15:18Z,Implement RFC 1861: Extern types,plietar,1e9e3191ab01ad16e8a839efeea5cac2999140af,5,Move type_has_metadata to trans_utils,HOORAY,2017-09-04T16:57:09Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44295,MERGED,2017-09-03T18:57:18Z,2017-10-28T16:15:18Z,Implement RFC 1861: Extern types,plietar,1e9e3191ab01ad16e8a839efeea5cac2999140af,5,Move type_has_metadata to trans_utils,HEART,2017-10-28T13:29:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44295,MERGED,2017-09-03T18:57:18Z,2017-10-28T16:15:18Z,Implement RFC 1861: Extern types,plietar,1e9e3191ab01ad16e8a839efeea5cac2999140af,5,Move type_has_metadata to trans_utils,THUMBS_UP,2017-10-31T23:57:00Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/44295,MERGED,2017-09-03T18:57:18Z,2017-10-28T16:15:18Z,Implement RFC 1861: Extern types,plietar,1e9e3191ab01ad16e8a839efeea5cac2999140af,5,Move type_has_metadata to trans_utils,HEART,2018-12-10T10:51:49Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/44297,MERGED,2017-09-03T19:36:45Z,2017-09-26T02:44:53Z,Add suggestions for misspelled method names,laumann,4963394f86719f3315239a900e557982a829adae,5,Change Levensthein-based method to a single suggestion The convention for suggesting close matches is to provide at most one match (the closest one). Change the suggestions for misspelt method names to obey that.,THUMBS_UP,2017-10-04T15:17:24Z,dgilman,NA https://github.com/rust-lang/rust/pull/44297,MERGED,2017-09-03T19:36:45Z,2017-09-26T02:44:53Z,Add suggestions for misspelled method names,laumann,4963394f86719f3315239a900e557982a829adae,5,Change Levensthein-based method to a single suggestion The convention for suggesting close matches is to provide at most one match (the closest one). Change the suggestions for misspelt method names to obey that.,THUMBS_UP,2017-10-04T21:05:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44303,MERGED,2017-09-03T23:14:41Z,2017-09-07T04:07:25Z,impl Debug for SplitWhitespace.,clarfonthey,4260e4395e5a7a1de4c64d81c7fd0157eac45ad3,1,impl Debug for SplitWhitespace.,THUMBS_UP,2017-09-14T15:00:36Z,passy,NA https://github.com/rust-lang/rust/pull/44303,MERGED,2017-09-03T23:14:41Z,2017-09-07T04:07:25Z,impl Debug for SplitWhitespace.,clarfonthey,4260e4395e5a7a1de4c64d81c7fd0157eac45ad3,1,impl Debug for SplitWhitespace.,THUMBS_UP,2017-11-24T09:27:23Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/44312,MERGED,2017-09-04T10:32:00Z,2017-09-10T12:49:01Z,Use rvalue promotion to 'static instead of static items.,eddyb,10f66bd6e494c5b329f6b21b31e388e0ed3d69c1,6,Use rvalue promotion to 'static instead of static items.,THUMBS_UP,2017-09-04T10:35:23Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44312,MERGED,2017-09-04T10:32:00Z,2017-09-10T12:49:01Z,Use rvalue promotion to 'static instead of static items.,eddyb,10f66bd6e494c5b329f6b21b31e388e0ed3d69c1,6,Use rvalue promotion to 'static instead of static items.,HEART,2017-09-04T10:35:25Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44312,MERGED,2017-09-04T10:32:00Z,2017-09-10T12:49:01Z,Use rvalue promotion to 'static instead of static items.,eddyb,10f66bd6e494c5b329f6b21b31e388e0ed3d69c1,6,Use rvalue promotion to 'static instead of static items.,HOORAY,2017-09-04T11:38:58Z,kennytm,NA https://github.com/rust-lang/rust/pull/44312,MERGED,2017-09-04T10:32:00Z,2017-09-10T12:49:01Z,Use rvalue promotion to 'static instead of static items.,eddyb,10f66bd6e494c5b329f6b21b31e388e0ed3d69c1,6,Use rvalue promotion to 'static instead of static items.,HOORAY,2017-09-04T12:48:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44312,MERGED,2017-09-04T10:32:00Z,2017-09-10T12:49:01Z,Use rvalue promotion to 'static instead of static items.,eddyb,10f66bd6e494c5b329f6b21b31e388e0ed3d69c1,6,Use rvalue promotion to 'static instead of static items.,HEART,2017-09-04T23:48:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44319,MERGED,2017-09-04T20:46:34Z,2017-09-07T04:07:27Z,Improve DefIndex formatting to be more semantic,est31,76fae7197bd8182cba166422e8888148f3474575,3,Fix tests,HEART,2017-09-04T20:52:05Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44319,MERGED,2017-09-04T20:46:34Z,2017-09-07T04:07:27Z,Improve DefIndex formatting to be more semantic,est31,76fae7197bd8182cba166422e8888148f3474575,3,Fix tests,HEART,2017-09-04T20:56:21Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44319,MERGED,2017-09-04T20:46:34Z,2017-09-07T04:07:27Z,Improve DefIndex formatting to be more semantic,est31,76fae7197bd8182cba166422e8888148f3474575,3,Fix tests,HEART,2017-09-04T21:03:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44328,MERGED,2017-09-05T02:24:00Z,2017-09-07T04:07:29Z,Removed the incorrect documentation for from_str,mcomstock,7d94ca618c1627e1751dd7744e781d864c5887bb,1,Removed the incorrect documentation for from_str,THUMBS_UP,2017-09-05T19:07:35Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44350,MERGED,2017-09-05T20:26:14Z,2017-09-20T06:29:50Z,Improve how rustdoc warnings are displayed,GuillaumeGomez,7aa5367236c31961b47a54588239e009fa16117f,1,Improve how warnings are displayed,HEART,2017-09-06T13:59:07Z,killercup,NA https://github.com/rust-lang/rust/pull/44364,MERGED,2017-09-06T10:28:50Z,2017-09-18T23:46:02Z,incr.comp.: Compute fingerprint for all query results.,michaelwoerister,4961a8e2bd8a6d2144ee90b4ec568a1c5b7a3241,2,incr.comp.: Fix ICE caused by trying to hash INVALID_CRATE_NUM.,HEART,2017-09-06T13:34:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44386,MERGED,2017-09-07T07:05:50Z,2017-09-13T13:01:52Z,Fix mispositioned error indicators,est31,d58281097a3bf14fe1b199c8ba6aee00793e111e,7,Fix mispositioned error indicators Fixes #38384 Most of the Rust community uses 4 spaces for indentation but there are also tab users of Rust (including myself!). This patch fixes a bug in error printing which mispositions error indicators when near code with tabs. The code attempted to fix the issue by replacing spaces with tabs but it sadly wasn't enough as sometimes you may not print spaces but _ or ^ instead. This patch employs the reverse strategy: it replaces each tab with a space so that the number of _ and ^ and spaces in error indicators below the code snippet line up perfectly. In a study [1] preceeding this patch we could see that this strategy is also chosen by gcc version 6.3.0. Its not perfect as the output is not beautiful but its the easiest to implement. If anyone wants to improve on this be my guest! This patch is meant as improvement of the status quo not as perfect end status. It fixes the actual issue of mispositioning error indicators. [1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710,THUMBS_UP,2017-09-12T18:47:18Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/44386,MERGED,2017-09-07T07:05:50Z,2017-09-13T13:01:52Z,Fix mispositioned error indicators,est31,d58281097a3bf14fe1b199c8ba6aee00793e111e,7,Fix mispositioned error indicators Fixes #38384 Most of the Rust community uses 4 spaces for indentation but there are also tab users of Rust (including myself!). This patch fixes a bug in error printing which mispositions error indicators when near code with tabs. The code attempted to fix the issue by replacing spaces with tabs but it sadly wasn't enough as sometimes you may not print spaces but _ or ^ instead. This patch employs the reverse strategy: it replaces each tab with a space so that the number of _ and ^ and spaces in error indicators below the code snippet line up perfectly. In a study [1] preceeding this patch we could see that this strategy is also chosen by gcc version 6.3.0. Its not perfect as the output is not beautiful but its the easiest to implement. If anyone wants to improve on this be my guest! This patch is meant as improvement of the status quo not as perfect end status. It fixes the actual issue of mispositioning error indicators. [1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710,THUMBS_UP,2017-09-13T13:25:59Z,florianb,NA https://github.com/rust-lang/rust/pull/44386,MERGED,2017-09-07T07:05:50Z,2017-09-13T13:01:52Z,Fix mispositioned error indicators,est31,d58281097a3bf14fe1b199c8ba6aee00793e111e,7,Fix mispositioned error indicators Fixes #38384 Most of the Rust community uses 4 spaces for indentation but there are also tab users of Rust (including myself!). This patch fixes a bug in error printing which mispositions error indicators when near code with tabs. The code attempted to fix the issue by replacing spaces with tabs but it sadly wasn't enough as sometimes you may not print spaces but _ or ^ instead. This patch employs the reverse strategy: it replaces each tab with a space so that the number of _ and ^ and spaces in error indicators below the code snippet line up perfectly. In a study [1] preceeding this patch we could see that this strategy is also chosen by gcc version 6.3.0. Its not perfect as the output is not beautiful but its the easiest to implement. If anyone wants to improve on this be my guest! This patch is meant as improvement of the status quo not as perfect end status. It fixes the actual issue of mispositioning error indicators. [1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710,THUMBS_UP,2017-09-20T20:03:53Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44392,MERGED,2017-09-07T12:38:12Z,2017-09-21T00:35:43Z,Only consider yields coming after the expressions when computing generator interiors,Zoxc,2384dd92dc53feda1e5cebf371917787b9b3906c,1,rebase fixup,HOORAY,2017-09-08T13:59:00Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_UP,2017-09-07T20:33:08Z,chordowl,NA https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_UP,2017-09-07T20:39:03Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_UP,2017-09-07T20:41:18Z,estebank,NA https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_DOWN,2017-09-08T11:07:31Z,est31,NA https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_DOWN,2017-09-08T15:22:22Z,kennytm,NA https://github.com/rust-lang/rust/pull/44397,MERGED,2017-09-07T20:10:04Z,2017-09-17T16:29:32Z,Codeblock color,GuillaumeGomez,79f888da6810e9e38918f524b0882b8eaf40e5a1,6,Add arrow and improve display,THUMBS_UP,2017-09-11T20:29:55Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/44407,MERGED,2017-09-08T01:07:44Z,2017-09-20T14:45:42Z,Add 'native' to -C target-cpu=help,mattico,824fb3817c0cbcb3a31a705d02a77219c8331608,1,Add 'native' to -C target-cpu=help,THUMBS_UP,2017-09-08T10:01:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44407,MERGED,2017-09-08T01:07:44Z,2017-09-20T14:45:42Z,Add 'native' to -C target-cpu=help,mattico,824fb3817c0cbcb3a31a705d02a77219c8331608,1,Add 'native' to -C target-cpu=help,THUMBS_UP,2017-09-08T10:27:33Z,est31,NA https://github.com/rust-lang/rust/pull/44407,MERGED,2017-09-08T01:07:44Z,2017-09-20T14:45:42Z,Add 'native' to -C target-cpu=help,mattico,824fb3817c0cbcb3a31a705d02a77219c8331608,1,Add 'native' to -C target-cpu=help,HEART,2017-09-15T04:16:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44410,MERGED,2017-09-08T03:45:30Z,2017-09-11T12:53:30Z,Fix sanitizer tests on buggy kernels,alexcrichton,43efccee89bdfa2c5e7b47c7ca4b85f6bba36ec3,4,Fix sanitizer tests on buggy kernels Travis recently pushed an update to the Linux environments namely the kernels that we're running on. This in turn caused some of the sanitizer tests we run to fail. We also apparently weren't the first to hit these failures! Detailed in google/sanitizers#837 these tests were failing due to a specific commit in the kernel which has since been backed out but for now work around the buggy kernel that's deployed on Travis and eventually we should be able to remove these flags.,THUMBS_UP,2017-09-08T05:29:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/44413,MERGED,2017-09-08T11:11:57Z,2017-09-12T15:36:20Z,Move the man directory to a subdirectory,est31,d587558269855870229ae995cc88bd5a0ddcb87b,3,Move the man directory to a subdirectory There is no reason it should be in the top directory.,THUMBS_UP,2017-09-10T16:27:12Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/44418,MERGED,2017-09-08T14:44:08Z,2017-09-10T10:09:58Z,rustc: Remove `DepGraph` handling from rustc_metadata,alexcrichton,d724d03389706e4efc72ea3865d9c2c185003fd2,11,rustc: Remove `DepGraph` handling from rustc_metadata This should now be entirely tracked through queries so no need to have a `DepGraph` in the `CStore` object any more!,HEART,2017-09-08T15:00:23Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44418,MERGED,2017-09-08T14:44:08Z,2017-09-10T10:09:58Z,rustc: Remove `DepGraph` handling from rustc_metadata,alexcrichton,d724d03389706e4efc72ea3865d9c2c185003fd2,11,rustc: Remove `DepGraph` handling from rustc_metadata This should now be entirely tracked through queries so no need to have a `DepGraph` in the `CStore` object any more!,HEART,2017-09-09T08:42:14Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44418,MERGED,2017-09-08T14:44:08Z,2017-09-10T10:09:58Z,rustc: Remove `DepGraph` handling from rustc_metadata,alexcrichton,d724d03389706e4efc72ea3865d9c2c185003fd2,11,rustc: Remove `DepGraph` handling from rustc_metadata This should now be entirely tracked through queries so no need to have a `DepGraph` in the `CStore` object any more!,HEART,2017-09-09T16:10:46Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44440,MERGED,2017-09-08T22:58:56Z,2017-09-11T15:35:51Z,Add `TargetOptions::min_global_align` with s390x at 16-bit,cuviper,c606e97cc6fb06130b1c8e79292fc1f3c8965a0c,2,Add a test for `min_global_align`,HEART,2017-09-08T23:08:02Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44441,MERGED,2017-09-08T23:01:56Z,2017-09-18T12:03:11Z,Remove rustc_bitflags; use the bitflags crate,tamird,231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa,23,Remove rustc_bitflags; use the bitflags crate,HEART,2017-09-08T23:07:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44441,MERGED,2017-09-08T23:01:56Z,2017-09-18T12:03:11Z,Remove rustc_bitflags; use the bitflags crate,tamird,231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa,23,Remove rustc_bitflags; use the bitflags crate,HEART,2017-09-09T00:01:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/44441,MERGED,2017-09-08T23:01:56Z,2017-09-18T12:03:11Z,Remove rustc_bitflags; use the bitflags crate,tamird,231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa,23,Remove rustc_bitflags; use the bitflags crate,HEART,2017-09-09T07:47:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44441,MERGED,2017-09-08T23:01:56Z,2017-09-18T12:03:11Z,Remove rustc_bitflags; use the bitflags crate,tamird,231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa,23,Remove rustc_bitflags; use the bitflags crate,HOORAY,2017-09-10T15:49:19Z,kennytm,NA https://github.com/rust-lang/rust/pull/44441,MERGED,2017-09-08T23:01:56Z,2017-09-18T12:03:11Z,Remove rustc_bitflags; use the bitflags crate,tamird,231d9e7e5d87ed54015c22bb1a07d0f3d4c0befa,23,Remove rustc_bitflags; use the bitflags crate,HOORAY,2017-09-21T02:31:39Z,Havvy,NA https://github.com/rust-lang/rust/pull/44481,MERGED,2017-09-10T22:26:00Z,2017-10-05T05:16:44Z,Updated RELEASES.md for 1.21.0,XAMPPRocky,7ed23f1349220f02813cdce6f159fad912c07b0d,1,Update RELEASES.md,THUMBS_UP,2017-09-18T15:24:37Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T20:57:39Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-11T20:57:48Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-11T21:00:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T21:00:18Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-11T21:11:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T21:11:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T21:13:50Z,arielb1,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T22:45:35Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-11T23:09:46Z,smt923,smt923@protonmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-12T01:08:16Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T01:30:25Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T02:17:48Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T05:27:51Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-12T05:37:15Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T05:50:01Z,est31,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T16:00:25Z,tommyip,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-12T16:00:25Z,tommyip,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-12T23:14:26Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-13T20:44:12Z,estebank,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HOORAY,2017-09-18T15:47:41Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-19T04:38:05Z,xen0n,NA https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-25T22:22:25Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-26T04:06:48Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44505,MERGED,2017-09-11T20:29:32Z,2017-09-20T01:03:54Z,rework the README.md for rustc and add other readmes,nikomatsakis,638958bd1310f790b2c7b92e14d9dc423226226c,1,incorporate suggestions from arielb1,HEART,2017-09-26T07:51:57Z,tirr-c,chwo9843@gmail.com https://github.com/rust-lang/rust/pull/44522,CLOSED,2017-09-12T13:53:50Z,2017-09-16T10:56:27Z,Add compile-pass mode to compiletest,RalfJung,NA,NA,NA,THUMBS_UP,2017-09-12T14:13:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/44522,CLOSED,2017-09-12T13:53:50Z,2017-09-16T10:56:27Z,Add compile-pass mode to compiletest,RalfJung,NA,NA,NA,THUMBS_UP,2017-09-12T20:56:54Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44526,MERGED,2017-09-12T20:05:25Z,2017-09-14T12:15:22Z,Remove deprecated lang items,leoyvens,9218e444342d13088092edec90a4f889f98ecff2,1,Fix initial review,HOORAY,2017-09-20T15:14:19Z,bstrie,NA https://github.com/rust-lang/rust/pull/44529,MERGED,2017-09-12T21:28:59Z,2017-09-18T01:50:39Z,Refactor translation unit partitioning/collection as a query,alexcrichton,6d614ddc2ebc25d3987b1efc84c0c7fea00ce325,17,"rustc: Move codegen to a query This commit moves the actual code generation in the compiler behind a query keyed by a codegen unit's name. This ended up entailing quite a few internal refactorings to enable this along with a few cut corners: * The `OutputFilenames` structure is now tracked in the `TyCtxt` as it affects a whole bunch of trans and such. This is now behind a query and threaded into the construction of the `TyCtxt`. * The `TyCtxt` now has a channel ""out the back"" intended to send data to worker threads in rustc_trans. This is used as a sort of side effect of the codegen query but morally what's happening here is the return value of the query (currently unit but morally a path) is only valid once the background threads have all finished. * Dispatching work items to the codegen threads was refactored to only rely on data in `TyCtxt` which mostly just involved refactoring where data was stored moving it from the translation thread to the controller thread's `CodegenContext` or the like. * A new thread locals was introduced in trans to work around the query system. This is used in the implementation of `assert_module_sources` which looks like an artifact of the old query system and will presumably go away once red/green is up and running.",HOORAY,2017-09-15T00:02:28Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,LAUGH,2017-09-13T02:56:28Z,retep998,NA https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,LAUGH,2017-09-13T06:17:18Z,MaulingMonkey,git@maulingmonkey.com https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,LAUGH,2017-09-13T15:56:18Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,HEART,2017-09-13T15:56:20Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,THUMBS_UP,2017-09-13T15:56:23Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/44531,MERGED,2017-09-12T23:12:47Z,2017-09-17T05:19:10Z,bump gcc for bootstrap,QuietMisdreavus,81ebab6fca423973aebda9fa311c7e9b8e1c2e13,2,bump gcc for bootstrap On Windows the gcc crate would send /Wall to msvc which would cause builds to get flooded with warnings exploding compile times from one hour to more than 72! The gcc crate version 0.3.54 changes this behavior to send /W4 instead which greatly cuts down on cl.exe flooding the command prompt window with warnings.,THUMBS_UP,2017-09-15T01:18:53Z,Others,NA https://github.com/rust-lang/rust/pull/44533,MERGED,2017-09-13T04:21:16Z,2017-09-17T16:29:35Z,Add Rustfmt,nrc,368cab3b0357194f407060cd1a1d3339cf854c25,3,Reviewer changes,THUMBS_UP,2017-09-13T05:23:37Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/44533,MERGED,2017-09-13T04:21:16Z,2017-09-17T16:29:35Z,Add Rustfmt,nrc,368cab3b0357194f407060cd1a1d3339cf854c25,3,Reviewer changes,HOORAY,2017-09-13T15:02:36Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-09-14T17:29:24Z,durka,NA https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-09-14T18:27:23Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-09-18T01:59:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-09-27T16:54:15Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-10-05T15:10:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2017-11-23T11:01:07Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,HOORAY,2018-01-19T20:45:37Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/44551,MERGED,2017-09-13T20:48:54Z,2017-09-21T02:56:23Z,Implement `Copy`/`Clone` for closures,scalexm,3fa3fe01b65ec4dde20c66c6bedcd28e2f83f8b6,8,Fix ICE,THUMBS_UP,2018-01-19T20:45:39Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/44567,MERGED,2017-09-14T14:10:12Z,2017-09-17T16:29:38Z,stabilized iterator_for_each (closes #42986),budziq,b7152901ce1d3a57ecd3468a43adc20dd82fad52,3,stabilized iterator_for_each (closes #42986) updated clippy and rls as it uses the iterator_for_each,HOORAY,2017-09-14T18:14:56Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/44567,MERGED,2017-09-14T14:10:12Z,2017-09-17T16:29:38Z,stabilized iterator_for_each (closes #42986),budziq,b7152901ce1d3a57ecd3468a43adc20dd82fad52,3,stabilized iterator_for_each (closes #42986) updated clippy and rls as it uses the iterator_for_each,HOORAY,2017-09-14T19:32:49Z,Others,NA https://github.com/rust-lang/rust/pull/44567,MERGED,2017-09-14T14:10:12Z,2017-09-17T16:29:38Z,stabilized iterator_for_each (closes #42986),budziq,b7152901ce1d3a57ecd3468a43adc20dd82fad52,3,stabilized iterator_for_each (closes #42986) updated clippy and rls as it uses the iterator_for_each,HOORAY,2017-09-17T07:39:14Z,bluss,NA https://github.com/rust-lang/rust/pull/44567,MERGED,2017-09-14T14:10:12Z,2017-09-17T16:29:38Z,stabilized iterator_for_each (closes #42986),budziq,b7152901ce1d3a57ecd3468a43adc20dd82fad52,3,stabilized iterator_for_each (closes #42986) updated clippy and rls as it uses the iterator_for_each,HOORAY,2017-09-20T04:12:38Z,Korvox,mel@nie.rs https://github.com/rust-lang/rust/pull/44567,MERGED,2017-09-14T14:10:12Z,2017-09-17T16:29:38Z,stabilized iterator_for_each (closes #42986),budziq,b7152901ce1d3a57ecd3468a43adc20dd82fad52,3,stabilized iterator_for_each (closes #42986) updated clippy and rls as it uses the iterator_for_each,HEART,2017-10-12T16:28:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44569,MERGED,2017-09-14T15:24:36Z,2017-09-15T06:59:06Z,"avoid is a better word here than ""disable""",est31,168f624c7cf8ca0209b5adac19bc361549ca70a9,2,"avoid is a better word here than ""disable""",THUMBS_UP,2017-09-14T15:36:22Z,kennytm,NA https://github.com/rust-lang/rust/pull/44569,MERGED,2017-09-14T15:24:36Z,2017-09-15T06:59:06Z,"avoid is a better word here than ""disable""",est31,168f624c7cf8ca0209b5adac19bc361549ca70a9,2,"avoid is a better word here than ""disable""",THUMBS_UP,2017-09-14T16:53:52Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/44572,MERGED,2017-09-14T19:35:33Z,2017-09-15T06:59:07Z,Clarify return type of `String::from_utf16_lossy`.,frewsxcv,258ef37f8e81388a11f420411e35b427215b0754,1,Clarify return type of `String::from_utf16_lossy`. Fixes https://github.com/rust-lang/rust/issues/32874,THUMBS_UP,2017-09-14T19:39:25Z,est31,NA https://github.com/rust-lang/rust/pull/44577,MERGED,2017-09-14T21:04:41Z,2017-09-17T05:19:13Z,Customize `::fold`,cuviper,351f56a6034486c38c3b36bfbbd15a81a39ba9aa,1,Add a specific test for `FlatMap::fold`,THUMBS_UP,2017-09-20T20:11:02Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44614,MERGED,2017-09-15T21:09:00Z,2017-10-07T02:56:26Z,implement pattern-binding-modes RFC,tbg,de55b4f077a11780eb0534ef5b41fb0ff765b31d,46,implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md,THUMBS_UP,2017-09-18T01:55:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/44614,MERGED,2017-09-15T21:09:00Z,2017-10-07T02:56:26Z,implement pattern-binding-modes RFC,tbg,de55b4f077a11780eb0534ef5b41fb0ff765b31d,46,implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md,HOORAY,2017-09-18T01:55:41Z,cramertj,NA https://github.com/rust-lang/rust/pull/44614,MERGED,2017-09-15T21:09:00Z,2017-10-07T02:56:26Z,implement pattern-binding-modes RFC,tbg,de55b4f077a11780eb0534ef5b41fb0ff765b31d,46,implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md,THUMBS_UP,2017-09-18T13:24:19Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/44614,MERGED,2017-09-15T21:09:00Z,2017-10-07T02:56:26Z,implement pattern-binding-modes RFC,tbg,de55b4f077a11780eb0534ef5b41fb0ff765b31d,46,implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md,THUMBS_UP,2017-09-21T15:30:57Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/44614,MERGED,2017-09-15T21:09:00Z,2017-10-07T02:56:26Z,implement pattern-binding-modes RFC,tbg,de55b4f077a11780eb0534ef5b41fb0ff765b31d,46,implement pattern-binding-modes RFC See the [RFC] and [tracking issue]. [tracking issue]: https://github.com/rust-lang/rust/issues/42640 [RFC]: https://github.com/rust-lang/rfcs/blob/491e0af/text/2005-match-ergonomics.md,HOORAY,2017-10-08T04:46:55Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T11:38:47Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T12:12:53Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T12:31:18Z,retep998,NA https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T13:13:49Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T13:28:28Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/44631,MERGED,2017-09-16T11:36:16Z,2017-09-17T05:19:19Z,Make use of Travis's conditional jobs.,kennytm,9f763549c1b93d0118a9307f1ebe9fccbf95ae05,1,Make use of Travis's conditional jobs.,HOORAY,2017-09-16T17:18:33Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-09-16T17:26:16Z,antoyo,NA https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-09-16T17:48:03Z,est31,NA https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-09-17T01:54:50Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-10-09T13:27:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-10-12T18:02:18Z,estebank,NA https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,THUMBS_UP,2017-10-31T23:58:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HEART,2017-11-04T00:32:42Z,norru,nigu.orru@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2017-11-13T03:08:24Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HEART,2017-11-13T03:08:25Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HEART,2018-02-01T18:32:26Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/44636,MERGED,2017-09-16T17:24:55Z,2017-10-25T22:21:10Z,Add short error message-format,GuillaumeGomez,b46c014cd33c7ccb900220952128ec29ad576276,1,Set rustfmt broken while waiting for the update of their side,HOORAY,2018-02-01T18:32:29Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/44639,MERGED,2017-09-16T23:11:53Z,2017-09-17T16:29:42Z,stabilized needs_drop (fixes #41890),budziq,04855950b9d93cc9409891eb6368257299ffcfca,3,stabilized needs_drop (fixes #41890),HEART,2017-09-16T23:37:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44639,MERGED,2017-09-16T23:11:53Z,2017-09-17T16:29:42Z,stabilized needs_drop (fixes #41890),budziq,04855950b9d93cc9409891eb6368257299ffcfca,3,stabilized needs_drop (fixes #41890),HEART,2017-09-17T09:21:50Z,bluss,NA https://github.com/rust-lang/rust/pull/44642,CLOSED,2017-09-17T00:41:31Z,2017-10-19T14:46:02Z,Refer to types using the local identifier,estebank,NA,NA,NA,HEART,2017-09-18T04:01:07Z,cramertj,NA https://github.com/rust-lang/rust/pull/44642,CLOSED,2017-09-17T00:41:31Z,2017-10-19T14:46:02Z,Refer to types using the local identifier,estebank,NA,NA,NA,THUMBS_UP,2017-10-13T05:03:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/44657,MERGED,2017-09-17T16:05:50Z,2017-09-18T23:46:10Z,Replace str's transmute() calls with pointer casts,Ixrec,38fa340ba263612a6f7351d4800d6d4f57ac1cdf,1,missed a 'mut',HEART,2017-09-17T16:08:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44657,MERGED,2017-09-17T16:05:50Z,2017-09-18T23:46:10Z,Replace str's transmute() calls with pointer casts,Ixrec,38fa340ba263612a6f7351d4800d6d4f57ac1cdf,1,missed a 'mut',HEART,2017-09-18T06:30:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44657,MERGED,2017-09-17T16:05:50Z,2017-09-18T23:46:10Z,Replace str's transmute() calls with pointer casts,Ixrec,38fa340ba263612a6f7351d4800d6d4f57ac1cdf,1,missed a 'mut',HEART,2017-09-18T10:28:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44657,MERGED,2017-09-17T16:05:50Z,2017-09-18T23:46:10Z,Replace str's transmute() calls with pointer casts,Ixrec,38fa340ba263612a6f7351d4800d6d4f57ac1cdf,1,missed a 'mut',HEART,2017-09-18T15:14:01Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/44661,MERGED,2017-09-17T20:12:53Z,2017-09-18T23:46:10Z,Add more links and put the link character to the left,GuillaumeGomez,e47279f51212a749d7cfe1d38a27f10a842d97a5,2,Add more links and put the link character to the left,THUMBS_UP,2017-09-18T08:23:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/44682,MERGED,2017-09-18T20:02:50Z,2017-09-22T02:01:22Z,Add iterator method .rfold(init function); the reverse of fold,bluss,41a42263dffdfed9076029a3db973e1efad5f792,1,core: Assign tracking issue for iter_rfold,THUMBS_UP,2017-09-19T00:33:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44682,MERGED,2017-09-18T20:02:50Z,2017-09-22T02:01:22Z,Add iterator method .rfold(init function); the reverse of fold,bluss,41a42263dffdfed9076029a3db973e1efad5f792,1,core: Assign tracking issue for iter_rfold,THUMBS_UP,2017-09-27T07:58:30Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44682,MERGED,2017-09-18T20:02:50Z,2017-09-22T02:01:22Z,Add iterator method .rfold(init function); the reverse of fold,bluss,41a42263dffdfed9076029a3db973e1efad5f792,1,core: Assign tracking issue for iter_rfold,THUMBS_UP,2017-09-27T08:56:03Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/44682,MERGED,2017-09-18T20:02:50Z,2017-09-22T02:01:22Z,Add iterator method .rfold(init function); the reverse of fold,bluss,41a42263dffdfed9076029a3db973e1efad5f792,1,core: Assign tracking issue for iter_rfold,THUMBS_UP,2017-09-27T16:53:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44691,MERGED,2017-09-19T05:58:32Z,2017-09-22T17:17:40Z,Implement underscore lifetimes,cramertj,f5505d185ccb9b1d84e6d7cdab20f901a778a86c,1,Add tests for underscore lifetimes in impl headers and struct definitions,HEART,2017-09-19T07:55:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44691,MERGED,2017-09-19T05:58:32Z,2017-09-22T17:17:40Z,Implement underscore lifetimes,cramertj,f5505d185ccb9b1d84e6d7cdab20f901a778a86c,1,Add tests for underscore lifetimes in impl headers and struct definitions,HEART,2017-09-27T16:52:21Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44691,MERGED,2017-09-19T05:58:32Z,2017-09-22T17:17:40Z,Implement underscore lifetimes,cramertj,f5505d185ccb9b1d84e6d7cdab20f901a778a86c,1,Add tests for underscore lifetimes in impl headers and struct definitions,HEART,2017-10-31T15:31:04Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44691,MERGED,2017-09-19T05:58:32Z,2017-09-22T17:17:40Z,Implement underscore lifetimes,cramertj,f5505d185ccb9b1d84e6d7cdab20f901a778a86c,1,Add tests for underscore lifetimes in impl headers and struct definitions,HEART,2017-12-02T20:48:49Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/44691,MERGED,2017-09-19T05:58:32Z,2017-09-22T17:17:40Z,Implement underscore lifetimes,cramertj,f5505d185ccb9b1d84e6d7cdab20f901a778a86c,1,Add tests for underscore lifetimes in impl headers and struct definitions,HEART,2018-02-21T18:21:09Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44700,MERGED,2017-09-19T13:24:47Z,2017-09-25T05:05:21Z,Move effect-checking to MIR,arielb1,516534ffdf2d267d5706443d5bd2bd7987d7498e,1,fix test,HOORAY,2017-09-19T13:36:55Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44700,MERGED,2017-09-19T13:24:47Z,2017-09-25T05:05:21Z,Move effect-checking to MIR,arielb1,516534ffdf2d267d5706443d5bd2bd7987d7498e,1,fix test,HOORAY,2017-09-19T14:48:39Z,kennytm,NA https://github.com/rust-lang/rust/pull/44700,MERGED,2017-09-19T13:24:47Z,2017-09-25T05:05:21Z,Move effect-checking to MIR,arielb1,516534ffdf2d267d5706443d5bd2bd7987d7498e,1,fix test,HOORAY,2017-09-19T18:19:42Z,cramertj,NA https://github.com/rust-lang/rust/pull/44700,MERGED,2017-09-19T13:24:47Z,2017-09-25T05:05:21Z,Move effect-checking to MIR,arielb1,516534ffdf2d267d5706443d5bd2bd7987d7498e,1,fix test,HOORAY,2017-09-27T16:52:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HOORAY,2017-09-20T01:35:55Z,durka,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HOORAY,2017-09-20T01:37:35Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HEART,2017-09-20T02:26:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-09-20T06:52:01Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-09-20T18:52:39Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-09-21T13:19:06Z,UtherII,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-09-26T16:50:47Z,tjkirch,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HEART,2017-09-28T13:29:33Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HOORAY,2017-09-28T13:29:36Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-09-28T13:29:38Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HOORAY,2017-10-03T21:57:56Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-10-04T00:57:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-10-04T03:52:17Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_DOWN,2017-10-04T06:04:46Z,UtherII,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-10-04T09:27:52Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-10-04T13:11:55Z,Flaise,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_DOWN,2017-10-04T13:12:48Z,Flaise,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-10-04T14:55:40Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,HOORAY,2017-10-04T20:44:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_UP,2017-10-05T00:36:24Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_DOWN,2017-10-06T00:42:51Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-10-06T00:43:14Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,CONFUSED,2017-10-07T22:58:00Z,tengwar,NA https://github.com/rust-lang/rust/pull/44709,MERGED,2017-09-20T01:19:03Z,2017-09-27T18:40:08Z,Initial support for `..=` syntax,Badel2,5102309b1ff63660309dead2e39ff9a9b554799a,2,bump rustfmt,THUMBS_DOWN,2017-10-16T12:42:51Z,samoylovfp,NA https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-09-22T18:05:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-09-22T20:01:24Z,estebank,NA https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-09-29T15:50:08Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-10-04T09:08:42Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HOORAY,2017-10-04T09:08:48Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-10-05T17:06:03Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/44735,MERGED,2017-09-21T09:18:29Z,2017-09-26T09:19:16Z,Friendlier error message for closure argument type mismatch,tirr-c,1bfbfb20a181356dece4559b0974ca1fcde02bac,14,Print fn signature when there is closure argument type mismatch Fixes #42143. E0281 is totally replaced by E0631. UI tests are updated accordingly.,HEART,2017-11-27T18:53:55Z,sinkuu,NA https://github.com/rust-lang/rust/pull/44751,CLOSED,2017-09-21T18:20:53Z,2017-09-26T22:36:05Z,Added additional formatting options for slices,Gilnaa,NA,NA,NA,THUMBS_UP,2017-09-21T19:06:10Z,durka,NA https://github.com/rust-lang/rust/pull/44751,CLOSED,2017-09-21T18:20:53Z,2017-09-26T22:36:05Z,Added additional formatting options for slices,Gilnaa,NA,NA,NA,THUMBS_UP,2017-09-23T14:06:03Z,bluss,NA https://github.com/rust-lang/rust/pull/44751,CLOSED,2017-09-21T18:20:53Z,2017-09-26T22:36:05Z,Added additional formatting options for slices,Gilnaa,NA,NA,NA,CONFUSED,2017-09-24T04:51:05Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2017-09-21T21:16:27Z,Gilnaa,NA https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2017-09-24T11:40:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2017-09-24T16:19:03Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2017-09-29T05:24:50Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2017-09-29T18:05:06Z,Ralith,NA https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',HEART,2017-10-02T15:10:25Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/44764,MERGED,2017-09-21T20:50:02Z,2017-11-01T01:46:01Z,Implement TryFrom<&[T]> for &[T; N],nvzqz,4c853adce9103b8bc84cd6b0026bcdc2eed7da31,362,Merge remote-tracking branch 'upstream/master',HEART,2017-11-09T13:51:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44772,MERGED,2017-09-22T12:20:21Z,2017-09-24T07:36:08Z,incr.comp.: Add new DepGraph implementation.,michaelwoerister,89aec1eb0bbae38123ffb3e41dc9c2af62527e14,2,incr.comp.: Remove out-dated unit test and unnecessary assertion.,HOORAY,2017-09-22T12:36:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44772,MERGED,2017-09-22T12:20:21Z,2017-09-24T07:36:08Z,incr.comp.: Add new DepGraph implementation.,michaelwoerister,89aec1eb0bbae38123ffb3e41dc9c2af62527e14,2,incr.comp.: Remove out-dated unit test and unnecessary assertion.,HOORAY,2017-09-22T14:25:55Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/44772,MERGED,2017-09-22T12:20:21Z,2017-09-24T07:36:08Z,incr.comp.: Add new DepGraph implementation.,michaelwoerister,89aec1eb0bbae38123ffb3e41dc9c2af62527e14,2,incr.comp.: Remove out-dated unit test and unnecessary assertion.,HOORAY,2017-09-22T14:29:02Z,lqd,NA https://github.com/rust-lang/rust/pull/44772,MERGED,2017-09-22T12:20:21Z,2017-09-24T07:36:08Z,incr.comp.: Add new DepGraph implementation.,michaelwoerister,89aec1eb0bbae38123ffb3e41dc9c2af62527e14,2,incr.comp.: Remove out-dated unit test and unnecessary assertion.,HOORAY,2017-09-22T17:40:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/44772,MERGED,2017-09-22T12:20:21Z,2017-09-24T07:36:08Z,incr.comp.: Add new DepGraph implementation.,michaelwoerister,89aec1eb0bbae38123ffb3e41dc9c2af62527e14,2,incr.comp.: Remove out-dated unit test and unnecessary assertion.,HOORAY,2017-09-27T07:38:08Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44779,MERGED,2017-09-22T23:45:04Z,2017-09-28T06:48:40Z,Add aarch64-unknown-linux-musl target,tjkirch,f94bd36fd1f9e71c7b2e33949abc0d931cdf6f7c,7,add aarch64-unknown-linux-musl target Signed-off-by: Ben Cressey Signed-off-by: Tom Kirchner ,THUMBS_UP,2017-09-28T15:01:50Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-09-24T05:28:24Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-09-24T13:08:10Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-09-25T22:33:24Z,passy,NA https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-10-07T19:11:09Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-10-27T04:58:22Z,sunjay,NA https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-11-08T13:57:34Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2017-11-11T21:32:04Z,jseyfried,NA https://github.com/rust-lang/rust/pull/44781,MERGED,2017-09-23T01:59:57Z,2017-11-22T12:34:53Z,rustdoc: include external files in documentation (RFC 1990),QuietMisdreavus,52ee203d656f7939de65fa837eea58230151e71e,1,make with_unsugared_doc preserve is_sugared_doc,HOORAY,2020-09-16T15:22:08Z,naturallymitchell,NA https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2017-09-23T03:40:11Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2017-09-23T04:21:23Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2017-09-23T05:46:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2017-09-23T11:04:39Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HEART,2017-09-23T11:05:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,THUMBS_UP,2017-09-23T16:41:46Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2017-09-23T23:15:39Z,kornholi,NA https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,THUMBS_UP,2019-01-23T01:44:14Z,glfmn,me@glfmn.io https://github.com/rust-lang/rust/pull/44783,CLOSED,2017-09-23T03:32:13Z,2017-09-30T18:27:53Z,rustc: Enable LTO and multiple codegen units,alexcrichton,NA,NA,NA,HOORAY,2019-01-23T01:44:15Z,glfmn,me@glfmn.io https://github.com/rust-lang/rust/pull/44786,MERGED,2017-09-23T10:55:56Z,2017-09-24T11:21:39Z,Improve diagnostics when attempting to match tuple enum variant with struct pattern,thombles,def660cad5c77478c28c3d4092e8d17367050935,2,UI unit test for note when matching tuple enum with struct pattern,HEART,2017-09-24T18:51:31Z,estebank,NA https://github.com/rust-lang/rust/pull/44802,MERGED,2017-09-24T04:21:23Z,2017-09-27T04:57:41Z,Fix capacity comparison in reserve,sfackler,81bac74c2ddc6c39f3628a36966f4a56a1282d02,1,Add a run-pass-valgrind test for vecdeque issue,HEART,2017-09-24T10:04:10Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44802,MERGED,2017-09-24T04:21:23Z,2017-09-27T04:57:41Z,Fix capacity comparison in reserve,sfackler,81bac74c2ddc6c39f3628a36966f4a56a1282d02,1,Add a run-pass-valgrind test for vecdeque issue,HEART,2017-09-25T09:17:09Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/44802,MERGED,2017-09-24T04:21:23Z,2017-09-27T04:57:41Z,Fix capacity comparison in reserve,sfackler,81bac74c2ddc6c39f3628a36966f4a56a1282d02,1,Add a run-pass-valgrind test for vecdeque issue,HEART,2017-09-26T05:05:53Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/44802,MERGED,2017-09-24T04:21:23Z,2017-09-27T04:57:41Z,Fix capacity comparison in reserve,sfackler,81bac74c2ddc6c39f3628a36966f4a56a1282d02,1,Add a run-pass-valgrind test for vecdeque issue,HEART,2017-09-26T18:12:49Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/44818,MERGED,2017-09-24T22:46:53Z,2017-10-06T08:00:27Z,Improve resolution of associated types in declarative macros 2.0,petrochenkov,2d9161d1887b2bbb2586e3674710e30963b845ff,11,Improve resolution of associated types in macros 2.0,HEART,2017-09-25T07:30:46Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/44818,MERGED,2017-09-24T22:46:53Z,2017-10-06T08:00:27Z,Improve resolution of associated types in declarative macros 2.0,petrochenkov,2d9161d1887b2bbb2586e3674710e30963b845ff,11,Improve resolution of associated types in macros 2.0,HEART,2017-09-25T18:07:46Z,jseyfried,NA https://github.com/rust-lang/rust/pull/44818,MERGED,2017-09-24T22:46:53Z,2017-10-06T08:00:27Z,Improve resolution of associated types in declarative macros 2.0,petrochenkov,2d9161d1887b2bbb2586e3674710e30963b845ff,11,Improve resolution of associated types in macros 2.0,HEART,2017-09-26T04:29:57Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44825,MERGED,2017-09-25T07:06:38Z,2017-09-27T10:56:37Z,Allow unused extern crate again,dtolnay,247b58b4f4de332964ec26e265a6150d630d60d7,1,Allow unused extern crate again This is a partial revert of #42588. There is a usability concern reported in #44294 that was not considered in the discussion of the PR so I would like to back this out of 1.21. As is I think users would have a worse and more confusing experience with this lint enabled by default. We can re-enabled once there are better diagnostics or the case in #44294 does not trigger the lint.,THUMBS_UP,2017-09-25T09:47:32Z,est31,NA https://github.com/rust-lang/rust/pull/44825,MERGED,2017-09-25T07:06:38Z,2017-09-27T10:56:37Z,Allow unused extern crate again,dtolnay,247b58b4f4de332964ec26e265a6150d630d60d7,1,Allow unused extern crate again This is a partial revert of #42588. There is a usability concern reported in #44294 that was not considered in the discussion of the PR so I would like to back this out of 1.21. As is I think users would have a worse and more confusing experience with this lint enabled by default. We can re-enabled once there are better diagnostics or the case in #44294 does not trigger the lint.,THUMBS_UP,2017-10-03T21:56:22Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/44840,CLOSED,2017-09-25T15:42:27Z,2017-09-30T15:03:59Z,Improve wording for StepBy,steveklabnik,NA,NA,NA,THUMBS_DOWN,2017-09-25T17:54:11Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/44840,CLOSED,2017-09-25T15:42:27Z,2017-09-30T15:03:59Z,Improve wording for StepBy,steveklabnik,NA,NA,NA,HEART,2017-09-25T21:16:06Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/44840,CLOSED,2017-09-25T15:42:27Z,2017-09-30T15:03:59Z,Improve wording for StepBy,steveklabnik,NA,NA,NA,THUMBS_UP,2017-09-26T21:28:13Z,bluss,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T17:05:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:05:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:06:35Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:13:54Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:20:58Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T17:21:04Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:32:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T17:32:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T17:47:45Z,arthurprs,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T18:00:05Z,est31,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T18:00:06Z,est31,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T18:43:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T18:43:44Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T18:48:19Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T20:49:13Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T23:13:47Z,retep998,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-25T23:51:14Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-25T23:51:14Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-26T03:40:03Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T03:40:03Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T04:13:57Z,delacian,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T04:23:41Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T09:09:26Z,killercup,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T09:57:06Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-26T17:46:55Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-26T17:46:55Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-26T21:22:44Z,bluss,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-27T01:39:15Z,kornholi,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-27T14:38:27Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-09-29T03:47:54Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-09-30T23:11:44Z,retep998,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-10-08T20:09:20Z,Ryman,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HEART,2017-10-09T11:15:48Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-10-12T05:27:51Z,xen0n,NA https://github.com/rust-lang/rust/pull/44841,MERGED,2017-09-25T16:47:28Z,2017-10-08T00:41:02Z,rustc: Implement ThinLTO,alexcrichton,4ca1b19fde0c4fcdeba24a8e6135577e86c69f49,24,"rustc: Implement ThinLTO This commit is an implementation of LLVM's ThinLTO for consumption in rustc itself. Currently today LTO works by merging all relevant LLVM modules into one and then running optimization passes. ""Thin"" LTO operates differently by having more sharded work and allowing parallelism opportunities between optimizing codegen units. Further down the road Thin LTO also allows *incremental* LTO which should enable even faster release builds without compromising on the performance we have today. This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then also implements two forms of ThinLTO: * In one mode we'll *only* perform ThinLTO over the codegen units produced in a single compilation. That is we won't load upstream rlibs but we'll instead just perform ThinLTO amongst all codegen units produced by the compiler for the local crate. This is intended to emulate a desired end point where we have codegen units turned on by default for all crates and ThinLTO allows us to do this without performance loss. * In anther mode like full LTO today we'll optimize all upstream dependencies in ""thin"" mode. Unlike today however this LTO step is fully parallelized so should finish much more quickly. There's a good bit of comments about what the implementation is doing and where it came from but the tl;dr; is that currently most of the support here is copied from upstream LLVM. This code duplication is done for a number of reasons: * Controlling parallelism means we can use the existing jobserver support to avoid overloading machines. * We will likely want a slightly different form of incremental caching which integrates with our own incremental strategy but this is yet to be determined. * This buys us some flexibility about when/where we run ThinLTO as well as having it tailored to fit our needs for the time being. * Finally this allows us to reuse some artifacts such as our `TargetMachine` creation where all our options we used today aren't necessarily supported by upstream LLVM yet. My hope is that we can get some experience with this copy/paste in tree and then eventually upstream some work to LLVM itself to avoid the duplication while still ensuring our needs are met. Otherwise I fear that maintaining these bindings may be quite costly over the years with LLVM updates!",HOORAY,2017-10-29T20:44:08Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44847,MERGED,2017-09-25T19:05:38Z,2017-09-29T09:22:39Z,Point at signature on unused lint,estebank,9c3fa4d3ef46317dc812dbd43c8c43355dc7c726,5,Point at signature on unused lint,THUMBS_UP,2017-09-25T20:22:32Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-25T22:58:55Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-25T22:58:57Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-25T23:19:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-25T23:19:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T00:53:46Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T00:53:47Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T01:49:43Z,sunjay,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T01:49:44Z,sunjay,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T01:59:10Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T02:13:10Z,delacian,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T02:25:11Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T02:25:11Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T02:31:23Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T02:37:07Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T06:24:57Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,CONFUSED,2017-09-26T06:30:14Z,kennytm,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T08:41:54Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T09:00:01Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T09:22:30Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T09:30:00Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T09:30:09Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T09:55:06Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T09:59:26Z,cengizIO,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T13:45:22Z,arthurprs,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T15:23:16Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T15:23:20Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-26T17:34:03Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2017-09-26T19:06:05Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-27T03:36:43Z,robinst,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-09-29T03:44:45Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HOORAY,2017-10-09T13:26:12Z,RalfJung,NA https://github.com/rust-lang/rust/pull/44853,MERGED,2017-09-25T22:57:31Z,2017-09-29T12:56:34Z,rustc: Default 32 codegen units at O0,alexcrichton,9e35b797b158d2e437bfee6376f852fd87861286,6,rustc: Default 32 codegen units at O0 This commit changes the default of rustc to use 32 codegen units when compiling in debug mode typically an opt-level=0 compilation. Since their inception codegen units have matured quite a bit gaining features such as: * Parallel translation and codegen enabling codegen units to get worked on even more quickly. * Deterministic and reliable partitioning through the same infrastructure as incremental compilation. * Global rate limiting through the `jobserver` crate to avoid overloading the system. The largest benefit of codegen units has forever been faster compilation through parallel processing of modules on the LLVM side of things using all the cores available on build machines that typically have many available. Some downsides have been fixed through the features above but the major downside remaining is that using codegen units reduces opportunities for inlining and optimization. This however doesn't matter much during debug builds! In this commit the default number of codegen units for debug builds has been raised from 1 to 32. This should enable most `cargo build` compiles that are bottlenecked on translation and/or code generation to immediately see speedups through parallelization on available cores. Work is being done to *always* enable multiple codegen units (and therefore parallel codegen) but it requires #44841 at least to be landed and stabilized but stay tuned if you're interested in that aspect!,HEART,2020-01-29T15:11:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/44855,MERGED,2017-09-26T02:20:04Z,2017-10-13T20:14:41Z,Improved docs for CStr CString OsStr OsString,federicomenaquintero,5fb8e3d829e77643e9c153172fb3a67f85eebe81,1,ffi/mod.rs: Use only one space after a period ending a sentence,HOORAY,2017-09-27T05:23:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/44855,MERGED,2017-09-26T02:20:04Z,2017-10-13T20:14:41Z,Improved docs for CStr CString OsStr OsString,federicomenaquintero,5fb8e3d829e77643e9c153172fb3a67f85eebe81,1,ffi/mod.rs: Use only one space after a period ending a sentence,HOORAY,2017-10-13T20:15:04Z,Havvy,NA https://github.com/rust-lang/rust/pull/44866,MERGED,2017-09-26T16:50:16Z,2017-09-29T20:09:43Z,First step toward implementing impl Trait in argument position,mdevlamynck,838105f09b407aa6e5239ac1aa68e53846b5b712,2,Use a different error code to avoid conflicts,THUMBS_UP,2017-09-27T01:21:55Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/44877,MERGED,2017-09-27T01:22:20Z,2017-10-10T13:35:04Z,Improve raw Box conversions,nvzqz,22298b8240d40ed9b3dbdf570bccce56dfbfcd2c,1,Add unique feature in Box::from_unique docs,THUMBS_UP,2017-09-27T13:01:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44881,CLOSED,2017-09-27T06:22:09Z,2017-10-19T14:41:54Z,Warn when assigning a block that doesn't have an implicit return,estebank,NA,NA,NA,HEART,2017-09-27T06:22:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44884,MERGED,2017-09-27T11:35:20Z,2017-11-27T17:13:24Z,Make accesses to fields of packed structs unsafe,arielb1,f3b2d7f3a7b4dfcce46f3ad139717e8a9e3c9518,7,improve error messages,HEART,2017-09-27T13:00:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44884,MERGED,2017-09-27T11:35:20Z,2017-11-27T17:13:24Z,Make accesses to fields of packed structs unsafe,arielb1,f3b2d7f3a7b4dfcce46f3ad139717e8a9e3c9518,7,improve error messages,HEART,2017-12-29T20:35:23Z,RalfJung,NA https://github.com/rust-lang/rust/pull/44888,MERGED,2017-09-27T16:13:18Z,2017-10-11T18:33:40Z,Refactor fmt::Display and fmt::Debug impls in ppaux,tirr-c,84cb90f8ee080ed04512620357c1f734146df8c3,10,Fix tests,THUMBS_UP,2017-10-02T10:31:18Z,simnalamburt,NA https://github.com/rust-lang/rust/pull/44890,MERGED,2017-09-27T19:00:38Z,2017-10-04T19:14:50Z,Remove mem::transmute used in Box conversions,nvzqz,f1798d3c9ab22be8f3b6f9f60f5e027be1a02085,1,Cast inner type in OsStr::bytes The innermost type is not [u8] on all platforms but is assumed to have the same memory layout as [u8] since this conversion was done via mem::transmute before.,HEART,2017-09-27T21:43:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44890,MERGED,2017-09-27T19:00:38Z,2017-10-04T19:14:50Z,Remove mem::transmute used in Box conversions,nvzqz,f1798d3c9ab22be8f3b6f9f60f5e027be1a02085,1,Cast inner type in OsStr::bytes The innermost type is not [u8] on all platforms but is assumed to have the same memory layout as [u8] since this conversion was done via mem::transmute before.,HEART,2017-10-18T21:51:33Z,Ixrec,NA https://github.com/rust-lang/rust/pull/44895,MERGED,2017-09-28T03:01:11Z,2017-10-04T00:57:36Z,Made `fs::copy` return the length of the main stream,stephaneyfx,61c0c9e5f21f231bca1c5594c2b6616e419b86fc,2,Made `fs::copy` return the length of the main stream On Windows with the NTFS filesystem `fs::copy` would return the sum of the lengths of all streams which can be different from the length reported by `metadata` and thus confusing for users unaware of this NTFS peculiarity. This makes `fs::copy` return the same length `metadata` reports which is the value it used to return before PR #26751. Note that alternate streams are still copied; their length is just not included in the returned value. This change relies on the assumption that the stream with index 1 is always the main stream in the `CopyFileEx` callback. I could not find any official document confirming this but empirical testing has shown this to be true regardless of whether the alternate stream is created before or after the main stream. Resolves #44532,THUMBS_UP,2017-11-24T16:28:05Z,acdha,chris@improbable.org https://github.com/rust-lang/rust/pull/44900,CLOSED,2017-09-28T08:33:52Z,2017-09-30T15:04:19Z,Normalize spaces in lang attributes.,Havvy,NA,NA,NA,LAUGH,2017-09-28T09:02:23Z,kennytm,NA https://github.com/rust-lang/rust/pull/44900,CLOSED,2017-09-28T08:33:52Z,2017-09-30T15:04:19Z,Normalize spaces in lang attributes.,Havvy,NA,NA,NA,THUMBS_UP,2017-09-28T12:48:20Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T14:50:03Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T14:52:02Z,alexcrichton,alex@alexcrichton.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-28T14:52:03Z,alexcrichton,alex@alexcrichton.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:08:13Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:12:25Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T15:12:35Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:23:00Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:27:05Z,kennytm,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:27:19Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T15:27:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:29:47Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T15:29:48Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:32:35Z,est31,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:34:50Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T15:34:51Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:38:55Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:41:01Z,lqd,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T15:46:37Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T16:12:56Z,cramertj,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T16:12:57Z,cramertj,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-28T16:12:59Z,cramertj,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T16:13:47Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T16:20:38Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T16:39:04Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T16:49:29Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-28T16:49:35Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T16:49:36Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T18:34:05Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T18:47:47Z,AlexEne,alex.ene0x11@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-28T18:47:56Z,AlexEne,alex.ene0x11@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T19:07:22Z,alexcrichton,alex@alexcrichton.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T19:27:56Z,kellyjensen,kellyrayj@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T19:27:57Z,kellyjensen,kellyrayj@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T19:54:21Z,Anton-4,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T20:03:07Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T20:25:25Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T20:56:52Z,trishume,tris.hume@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T21:11:31Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T21:15:54Z,killercup,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T21:30:20Z,regexident,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-28T23:56:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-28T23:57:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-28T23:57:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T01:51:16Z,turbolent,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T02:25:11Z,alaingalvan,hi@alain.xyz https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T02:28:06Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T02:45:26Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T03:23:27Z,delacian,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T03:24:54Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T04:16:30Z,matthewhammer,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T04:16:37Z,matthewhammer,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T04:16:39Z,matthewhammer,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T04:46:17Z,samlh,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T04:53:01Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T04:58:50Z,TheWaWaR,thewawar@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T05:26:46Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T05:26:47Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T05:55:49Z,kornholi,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T06:30:40Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T06:45:59Z,discosultan,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T06:59:15Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T06:59:16Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T06:59:18Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T07:31:18Z,wunki,petar@petar.dev https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T07:53:59Z,arBmind,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T07:57:00Z,glyn,glyn.normington.work@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T07:57:04Z,glyn,glyn.normington.work@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T07:57:07Z,glyn,glyn.normington.work@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T08:22:43Z,durka,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T08:24:17Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T08:39:51Z,arthurprs,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T08:49:31Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T10:03:29Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T10:24:08Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T10:24:10Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T10:24:12Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T10:31:58Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T10:32:23Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T10:32:24Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T10:32:24Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T11:06:58Z,Flaise,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T11:16:30Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T11:16:33Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T11:16:35Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T11:19:40Z,dragostis,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T12:00:59Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T12:44:51Z,keeslinp,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T12:46:25Z,Diggsey,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T12:46:27Z,Diggsey,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T12:46:28Z,Diggsey,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T13:16:30Z,kaedroho,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T13:58:36Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T14:03:23Z,aatxe,aweiss@hey.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T14:29:11Z,Cldfire,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T14:36:32Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T15:52:10Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-29T16:29:40Z,icefoxen,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T16:53:55Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T17:38:23Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T17:52:56Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T17:57:15Z,joeytwiddle,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-29T18:09:54Z,gaurikholkar,gpkholkar27@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-29T19:05:59Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-30T00:27:30Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-30T00:27:31Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-30T00:27:32Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-09-30T02:31:44Z,hafizio,haffuza@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-30T07:35:54Z,alygin,alygin@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-30T08:53:15Z,alteous,david@harvey-macaulay.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-30T13:07:50Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-09-30T19:58:21Z,mjkillough,michaeljkillough@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-30T20:27:51Z,thelearnerofcode,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-09-30T22:44:17Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-01T01:58:25Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-01T05:37:12Z,johncf,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-01T18:53:17Z,d-xo,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-01T19:29:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-10-02T05:19:08Z,leovailati,leovailati@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-10-04T23:39:46Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-10-05T06:22:50Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-05T20:25:56Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HEART,2017-10-05T20:25:57Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,THUMBS_UP,2017-10-05T20:26:01Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-11T09:11:41Z,obust,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-12T05:32:59Z,xen0n,NA https://github.com/rust-lang/rust/pull/44901,MERGED,2017-09-28T14:48:02Z,2017-10-04T23:09:39Z,incr.comp.: Switch to red/green change tracking remove legacy system.,michaelwoerister,0454a41bec547b28526cdb511f05372c80cb7277,2,incr.comp.: Address review comments.,HOORAY,2017-10-29T21:42:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44916,CLOSED,2017-09-29T05:42:25Z,2017-12-21T19:00:10Z,Implement TryFrom for CString and CStr,nvzqz,NA,NA,NA,CONFUSED,2017-09-29T07:50:07Z,kennytm,NA https://github.com/rust-lang/rust/pull/44916,CLOSED,2017-09-29T05:42:25Z,2017-12-21T19:00:10Z,Implement TryFrom for CString and CStr,nvzqz,NA,NA,NA,HEART,2017-09-29T08:11:24Z,arthurprs,NA https://github.com/rust-lang/rust/pull/44916,CLOSED,2017-09-29T05:42:25Z,2017-12-21T19:00:10Z,Implement TryFrom for CString and CStr,nvzqz,NA,NA,NA,CONFUSED,2017-09-29T20:26:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44916,CLOSED,2017-09-29T05:42:25Z,2017-12-21T19:00:10Z,Implement TryFrom for CString and CStr,nvzqz,NA,NA,NA,HEART,2017-11-10T16:30:49Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/44920,MERGED,2017-09-29T11:33:31Z,2017-10-03T10:28:52Z, rustdoc: Render [src] links for trait implementors ,vi,acef039de84d6a98a981a1be6c23f695173d98f3,1,rustdoc: Remove cruft from the test per @GuillaumeGomez's sample but with one change.,HOORAY,2017-09-29T20:25:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/44942,MERGED,2017-09-30T08:15:41Z,2017-10-02T10:06:43Z,code suggestions for unused-mut while-true deprecated-attribute and unused-parens lints,zackmdavis,8a14022c5d31e1648bd1212a52a9f1a9ddbf3fa1,3,correct unused-parens lint suggestion to strip exact pair,HEART,2017-09-30T08:26:46Z,estebank,NA https://github.com/rust-lang/rust/pull/44942,MERGED,2017-09-30T08:15:41Z,2017-10-02T10:06:43Z,code suggestions for unused-mut while-true deprecated-attribute and unused-parens lints,zackmdavis,8a14022c5d31e1648bd1212a52a9f1a9ddbf3fa1,3,correct unused-parens lint suggestion to strip exact pair,HEART,2017-09-30T09:26:45Z,oli-obk,NA https://github.com/rust-lang/rust/pull/44942,MERGED,2017-09-30T08:15:41Z,2017-10-02T10:06:43Z,code suggestions for unused-mut while-true deprecated-attribute and unused-parens lints,zackmdavis,8a14022c5d31e1648bd1212a52a9f1a9ddbf3fa1,3,correct unused-parens lint suggestion to strip exact pair,HEART,2017-10-04T09:08:07Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/44963,MERGED,2017-10-01T19:17:22Z,2017-10-11T21:55:26Z,Improve performance of spsc_queue and stream.,JLockerman,bb7945e2fe662c86cb8e9e3a93730f20b7480dca,1,Remove Queue::new.,THUMBS_UP,2017-10-04T12:18:13Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/44963,MERGED,2017-10-01T19:17:22Z,2017-10-11T21:55:26Z,Improve performance of spsc_queue and stream.,JLockerman,bb7945e2fe662c86cb8e9e3a93730f20b7480dca,1,Remove Queue::new.,HOORAY,2017-10-18T11:35:58Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/44966,MERGED,2017-10-02T00:21:19Z,2017-10-03T04:43:05Z,make non_snake_case lint allow extern no-mangle functions,zackmdavis,b989101a558f0c2963a6a42b068c81f8b4606988,2,make non_snake_case lint allow extern no-mangle functions Resolves #31924.,THUMBS_UP,2017-10-02T14:45:47Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/44966,MERGED,2017-10-02T00:21:19Z,2017-10-03T04:43:05Z,make non_snake_case lint allow extern no-mangle functions,zackmdavis,b989101a558f0c2963a6a42b068c81f8b4606988,2,make non_snake_case lint allow extern no-mangle functions Resolves #31924.,THUMBS_UP,2017-10-03T01:01:52Z,jminer,NA https://github.com/rust-lang/rust/pull/44966,MERGED,2017-10-02T00:21:19Z,2017-10-03T04:43:05Z,make non_snake_case lint allow extern no-mangle functions,zackmdavis,b989101a558f0c2963a6a42b068c81f8b4606988,2,make non_snake_case lint allow extern no-mangle functions Resolves #31924.,THUMBS_UP,2017-10-10T18:45:08Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/44969,MERGED,2017-10-02T02:27:47Z,2017-10-12T03:40:16Z,document trait impls when the type appears in the trait's generics,QuietMisdreavus,23f5fbee45273879d185ab18b64ac2cd8c708fec,2,document trait impls when the type appears in the trait's generics,HOORAY,2017-10-02T02:43:50Z,radix,NA https://github.com/rust-lang/rust/pull/44969,MERGED,2017-10-02T02:27:47Z,2017-10-12T03:40:16Z,document trait impls when the type appears in the trait's generics,QuietMisdreavus,23f5fbee45273879d185ab18b64ac2cd8c708fec,2,document trait impls when the type appears in the trait's generics,HOORAY,2017-10-12T05:40:53Z,sinkuu,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-02T23:45:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-03T00:04:03Z,est31,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-03T00:50:41Z,estebank,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-03T18:17:18Z,bluss,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-07T06:59:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-13T03:14:47Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-13T05:21:07Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-13T12:02:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/44989,MERGED,2017-10-02T23:40:12Z,2017-10-13T01:33:38Z,let rustdoc print the crate version into docs,QuietMisdreavus,7ea286e854d88529af76ca486ed676c9fb06e8ee,2,render the rust version into std/compiler/test docs,HOORAY,2017-10-18T19:32:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-03T14:51:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-03T16:37:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-03T17:29:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-03T17:37:51Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-03T22:25:26Z,plietar,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-05T17:53:52Z,lqd,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-06T11:12:33Z,RalfJung,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-13T02:13:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-16T14:59:30Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-17T06:54:08Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-28T10:53:32Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-29T16:58:27Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-29T21:22:09Z,discosultan,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-10-30T00:07:59Z,est31,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-11-13T12:58:08Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-06T23:42:16Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-11T16:28:20Z,delacian,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-11T17:09:35Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-12T11:51:29Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-14T20:17:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-14T20:18:17Z,gmorenz,greg-morenz@droid.cafe https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-14T20:57:47Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-14T21:51:03Z,aochagavia,github@adolfo.ochagavia.xyz https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-14T23:33:50Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-16T08:48:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-17T15:41:49Z,loovjo,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2017-12-20T16:24:16Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/45002,MERGED,2017-10-03T14:45:17Z,2017-12-14T18:22:59Z,Validate miri against the HIR const evaluator,oli-obk,7a2bff7f1a253f6f3d713c153d651f4d52038be5,1,Do not produce debuginfo for tools,HOORAY,2018-03-30T22:02:06Z,mcarton,NA https://github.com/rust-lang/rust/pull/45005,MERGED,2017-10-03T16:56:12Z,2017-10-13T01:33:39Z,Inline eq_slice into str::eq,leoyvens,bb74c20a5d2594cab6d9416c2ed2cc8bd45fc956,1,Inline eq_slice into str::eq It's the only use of the function.,HEART,2017-10-05T23:06:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45005,MERGED,2017-10-03T16:56:12Z,2017-10-13T01:33:39Z,Inline eq_slice into str::eq,leoyvens,bb74c20a5d2594cab6d9416c2ed2cc8bd45fc956,1,Inline eq_slice into str::eq It's the only use of the function.,HEART,2017-10-07T09:49:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/45007,MERGED,2017-10-03T17:08:58Z,2017-10-12T20:20:30Z,Optimize comparison functions of Iterator,lezgomatt,3264c836bbbbf9d62bc088443ca844709f8746a1,1,Optimize comparison functions of Iterator Replaced matching on tuples which led to less performant code generation.,HOORAY,2017-10-18T11:46:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-04T00:15:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-04T10:16:19Z,est31,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-04T10:16:21Z,est31,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-04T17:17:47Z,lqd,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-04T18:38:27Z,arthurprs,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-04T19:50:36Z,leeoniya,leeoniya@gmail.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-04T22:23:32Z,cramertj,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-06T18:10:43Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-08T13:50:56Z,bluss,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-10T12:20:14Z,bestouff,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-10T18:01:52Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-10T18:01:53Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-10T18:01:54Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-11T06:01:30Z,torpak,arne@gtnw.de https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-11T06:01:32Z,torpak,arne@gtnw.de https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-11T06:01:33Z,torpak,arne@gtnw.de https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-12T06:38:13Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-19T13:08:53Z,kvark,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,THUMBS_UP,2017-10-19T16:50:46Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-19T16:50:47Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2017-10-19T16:50:48Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-19T18:50:02Z,Ixrec,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HOORAY,2017-10-21T03:33:38Z,delacian,NA https://github.com/rust-lang/rust/pull/45012,MERGED,2017-10-03T23:58:32Z,2017-10-08T13:01:11Z,Add -Zmutable-noalias flag,Gankra,a6dea41d64a244c8f7671dd0eeb498b015c3a712,1,Make -Cpanic=abort imply -Zmutable-noalias,HEART,2020-03-29T03:39:38Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/45031,MERGED,2017-10-04T21:55:57Z,2017-10-13T08:57:15Z,rustc: Add LLVM `nounwind` with `-C panic=abort`,alexcrichton,24cc38e3b00ff399acc99a57f92bfdef4ab8c949,5,rustc: Add LLVM `nounwind` with `-C panic=abort` This informs LLVM that functions can't unwind which while it should typically have already been inferred when necessary or otherwise not impact codegen is apparently needed on targets like ARM to avoid references to unnecessary symbols. Closes #44992,HEART,2017-10-13T09:06:53Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/45032,MERGED,2017-10-04T21:57:30Z,2017-10-13T11:34:22Z,rustc: Allow target-specific default cgus,alexcrichton,5187763cff184eda0f28fd409a4a8c6dfc57c9f9,7,rustc: Allow target-specific default cgus Some targets like msp430 and nvptx don't work with multiple codegen units right now for bugs or fundamental reasons. To expose this allow targets to express a default. Closes #45000,HEART,2017-10-13T18:01:59Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/45033,MERGED,2017-10-04T22:06:21Z,2017-10-09T02:42:38Z,rustc_trans: do not set NoCapture for anonymous lifetime &T arguments.,eddyb,ac25a4ac329a083a9693fe5d9d1600024db9b35c,1,rustc_trans: do not set NoCapture for anonymous lifetime &T arguments.,LAUGH,2017-10-04T22:28:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45039,MERGED,2017-10-05T03:14:29Z,2017-11-21T05:38:11Z,show in docs whether the return type of a function impls Iterator/Read/Write,QuietMisdreavus,6047a0365976cbf7ad2991e6d88e4adf2fc6d0f4,4,Add tooltip for important traits display,HEART,2017-10-05T03:54:37Z,est31,NA https://github.com/rust-lang/rust/pull/45039,MERGED,2017-10-05T03:14:29Z,2017-11-21T05:38:11Z,show in docs whether the return type of a function impls Iterator/Read/Write,QuietMisdreavus,6047a0365976cbf7ad2991e6d88e4adf2fc6d0f4,4,Add tooltip for important traits display,HEART,2017-10-05T12:44:59Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/45039,MERGED,2017-10-05T03:14:29Z,2017-11-21T05:38:11Z,show in docs whether the return type of a function impls Iterator/Read/Write,QuietMisdreavus,6047a0365976cbf7ad2991e6d88e4adf2fc6d0f4,4,Add tooltip for important traits display,HOORAY,2017-11-19T16:06:42Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45039,MERGED,2017-10-05T03:14:29Z,2017-11-21T05:38:11Z,show in docs whether the return type of a function impls Iterator/Read/Write,QuietMisdreavus,6047a0365976cbf7ad2991e6d88e4adf2fc6d0f4,4,Add tooltip for important traits display,HEART,2017-11-29T03:21:15Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45039,MERGED,2017-10-05T03:14:29Z,2017-11-21T05:38:11Z,show in docs whether the return type of a function impls Iterator/Read/Write,QuietMisdreavus,6047a0365976cbf7ad2991e6d88e4adf2fc6d0f4,4,Add tooltip for important traits display,HEART,2018-03-08T01:06:50Z,isislovecruft,isis@patternsinthevoid.net https://github.com/rust-lang/rust/pull/45041,MERGED,2017-10-05T03:43:58Z,2017-10-09T07:22:39Z,Remove support for the PNaCl target (le32-unknown-nacl),est31,327116a423c71754192945a319eef64947fd59df,1,Remove nacl from librustdoc,THUMBS_UP,2017-10-05T04:43:53Z,tlively,NA https://github.com/rust-lang/rust/pull/45041,MERGED,2017-10-05T03:43:58Z,2017-10-09T07:22:39Z,Remove support for the PNaCl target (le32-unknown-nacl),est31,327116a423c71754192945a319eef64947fd59df,1,Remove nacl from librustdoc,THUMBS_UP,2017-10-05T20:20:59Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-05T21:29:10Z,oyvindln,NA https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-05T22:26:44Z,cramertj,NA https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-05T23:08:45Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-10T16:21:52Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-10T20:41:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45054,MERGED,2017-10-05T21:24:35Z,2017-10-06T00:45:54Z,Faster compile times for release builds with llvm fix,andjo403,8fd3c8f769065aa102d97ddc253d7a6df2b53d7b,1,Faster compile times for release builds with llvm fix,HOORAY,2017-10-10T22:15:32Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-05T23:14:37Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-06T07:28:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-06T08:52:04Z,kennytm,NA https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-06T19:17:38Z,killercup,NA https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-09T13:26:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45055,MERGED,2017-10-05T22:55:38Z,2017-10-13T14:04:59Z,Add tabs for search for better information access,GuillaumeGomez,3a65d12df75751616d28d3d9f6e01c0dd0b898cd,3,Add tabs for search for better information access Make tabs work,HEART,2017-10-11T01:04:48Z,Boscop,NA https://github.com/rust-lang/rust/pull/45058,MERGED,2017-10-06T02:10:16Z,2017-10-08T08:21:40Z,Fix typo per #45057.,hunteke,73ca15cc2958dc5693d4b463ce48fbbe057d75f6,1,Fix typo per #45057.,HEART,2017-10-06T18:16:49Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45058,MERGED,2017-10-06T02:10:16Z,2017-10-08T08:21:40Z,Fix typo per #45057.,hunteke,73ca15cc2958dc5693d4b463ce48fbbe057d75f6,1,Fix typo per #45057.,HEART,2017-10-11T18:53:11Z,estebank,NA https://github.com/rust-lang/rust/pull/45069,MERGED,2017-10-06T16:14:59Z,2017-10-13T22:56:59Z,Better error for missing tuple pattern in args,sinkuu,f577847aa22cda4935562fe8e7c9420bcc58f148,2,Reword,THUMBS_UP,2017-10-07T12:52:37Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/45069,MERGED,2017-10-06T16:14:59Z,2017-10-13T22:56:59Z,Better error for missing tuple pattern in args,sinkuu,f577847aa22cda4935562fe8e7c9420bcc58f148,2,Reword,HEART,2017-10-09T00:17:55Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45069,MERGED,2017-10-06T16:14:59Z,2017-10-13T22:56:59Z,Better error for missing tuple pattern in args,sinkuu,f577847aa22cda4935562fe8e7c9420bcc58f148,2,Reword,HEART,2017-10-09T22:23:22Z,estebank,NA https://github.com/rust-lang/rust/pull/45069,MERGED,2017-10-06T16:14:59Z,2017-10-13T22:56:59Z,Better error for missing tuple pattern in args,sinkuu,f577847aa22cda4935562fe8e7c9420bcc58f148,2,Reword,THUMBS_UP,2017-10-12T06:39:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/45077,CLOSED,2017-10-07T03:50:05Z,2017-11-03T13:48:15Z,Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433.,jld,NA,NA,NA,HOORAY,2017-10-07T16:01:04Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/45080,MERGED,2017-10-07T09:04:13Z,2017-10-19T23:55:24Z,Issue 44986/fix windows ui path,clippered,057bc7d6506bb0208b5da782602c5cf7692d10c8,3,Fix #44968 Windows path in UI tests,HOORAY,2017-10-09T22:17:03Z,estebank,NA https://github.com/rust-lang/rust/pull/45091,MERGED,2017-10-07T17:42:31Z,2017-10-10T11:07:37Z,debuginfo-test: Fix #45086.,kennytm,07b189977d88d1de595601e7137275e4f4ccd8a2,1,debuginfo-test: Fix #45086. LLDB's output may be None instead of '' and that will cause type mismatch when normalize_whitespace() expects a string instead of None. This commit simply ensures we do pass '' even if the output is None.,THUMBS_UP,2017-10-07T20:06:48Z,k0pernicus,dev@0xc0ff33.me https://github.com/rust-lang/rust/pull/45091,MERGED,2017-10-07T17:42:31Z,2017-10-10T11:07:37Z,debuginfo-test: Fix #45086.,kennytm,07b189977d88d1de595601e7137275e4f4ccd8a2,1,debuginfo-test: Fix #45086. LLDB's output may be None instead of '' and that will cause type mismatch when normalize_whitespace() expects a string instead of None. This commit simply ensures we do pass '' even if the output is None.,THUMBS_UP,2017-10-07T20:39:52Z,jacwah,jacob@dstsrc.net https://github.com/rust-lang/rust/pull/45091,MERGED,2017-10-07T17:42:31Z,2017-10-10T11:07:37Z,debuginfo-test: Fix #45086.,kennytm,07b189977d88d1de595601e7137275e4f4ccd8a2,1,debuginfo-test: Fix #45086. LLDB's output may be None instead of '' and that will cause type mismatch when normalize_whitespace() expects a string instead of None. This commit simply ensures we do pass '' even if the output is None.,THUMBS_UP,2017-10-09T07:47:36Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45098,MERGED,2017-10-08T01:58:05Z,2017-10-18T21:02:35Z,Documenting the process for when rustfmt/rls break,sunjay,790604adad9fd02b92c59d1f937edb902a58b036,1,Updating the instructions for when a tool breaks to use the new toolstate feature,HEART,2017-10-08T06:20:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45102,MERGED,2017-10-08T09:11:29Z,2017-10-14T04:11:54Z,cleanup: rustc doesn't use an external archiver,petrochenkov,b434c84bab6bcb53f8394eb1bc133061d16f92c7,15,cleanup: rustc doesn't use an external archiver,HEART,2017-10-08T10:18:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45102,MERGED,2017-10-08T09:11:29Z,2017-10-14T04:11:54Z,cleanup: rustc doesn't use an external archiver,petrochenkov,b434c84bab6bcb53f8394eb1bc133061d16f92c7,15,cleanup: rustc doesn't use an external archiver,HEART,2017-10-08T11:02:01Z,kennytm,NA https://github.com/rust-lang/rust/pull/45104,MERGED,2017-10-08T15:32:49Z,2017-10-14T06:34:29Z,Incremental compilation auto assert (with except),vitiral,80c13ce13403e4aba7a73b765bfd8c40997f196d,6,fix review comments,THUMBS_UP,2017-10-17T13:09:08Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/45120,MERGED,2017-10-08T23:50:01Z,2017-10-10T11:07:41Z,Use identity operator `is` when comparing to None,johnthagen,d9e67038346d0b3f6509c7d881f1dc63b04cd160,1,Use identity operator `is` when comparing to None,HEART,2017-10-09T03:00:10Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45122,MERGED,2017-10-09T00:17:23Z,2017-10-13T20:14:46Z,Better compile error output when using arguments instead of types ,jean-lourenco,db91b00065181137fa4a298aeee796ff10755d20,3,output compiler message updated output message is shown in another 'help:' block line with +100 columns formatted test adjusted,HOORAY,2017-10-09T22:18:43Z,estebank,NA https://github.com/rust-lang/rust/pull/45122,MERGED,2017-10-09T00:17:23Z,2017-10-13T20:14:46Z,Better compile error output when using arguments instead of types ,jean-lourenco,db91b00065181137fa4a298aeee796ff10755d20,3,output compiler message updated output message is shown in another 'help:' block line with +100 columns formatted test adjusted,HOORAY,2017-10-13T20:45:30Z,johnnyasantoss,johnnyadsantos@gmail.com https://github.com/rust-lang/rust/pull/45125,MERGED,2017-10-09T02:11:08Z,2017-10-10T11:07:42Z,Update grammar to parse current rust syntax,bleibig,8240b872e42f066dc57ac7c59e2970f7a5456c32,3,Update grammar to parse current rust syntax,HOORAY,2017-10-09T16:20:11Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/45125,MERGED,2017-10-09T02:11:08Z,2017-10-10T11:07:42Z,Update grammar to parse current rust syntax,bleibig,8240b872e42f066dc57ac7c59e2970f7a5456c32,3,Update grammar to parse current rust syntax,HOORAY,2017-10-21T13:22:33Z,brauliobz,brauliobezerra@gmail.com https://github.com/rust-lang/rust/pull/45138,MERGED,2017-10-09T15:24:16Z,2017-10-17T03:11:58Z,Add more __future__ imports to increase compatibility with Python 3 in bootstrap,johnthagen,bd8497884c2863a10b6d67855bd90d40783ce2da,341,Merge branch 'master' into future_imports,HEART,2017-10-09T17:38:48Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45162,MERGED,2017-10-10T03:24:18Z,2017-10-14T13:47:51Z, Modify MIR testing to require consecutive lines,chrisvittal,426183c01bbaf398e8ae68bd554488af23e49dbd,25,Update README and tests for new infrastructure,HOORAY,2017-10-13T13:45:39Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/45162,MERGED,2017-10-10T03:24:18Z,2017-10-14T13:47:51Z, Modify MIR testing to require consecutive lines,chrisvittal,426183c01bbaf398e8ae68bd554488af23e49dbd,25,Update README and tests for new infrastructure,HOORAY,2017-10-14T14:02:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45162,MERGED,2017-10-10T03:24:18Z,2017-10-14T13:47:51Z, Modify MIR testing to require consecutive lines,chrisvittal,426183c01bbaf398e8ae68bd554488af23e49dbd,25,Update README and tests for new infrastructure,HOORAY,2017-12-10T16:12:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/45166,MERGED,2017-10-10T09:13:57Z,2017-10-13T01:33:46Z,Documented a few more unstable feature gates.,tinaun,d5ef9f9036743c77cbc30286a3b3b8e8185330d1,3,formatting fixes,HEART,2017-10-10T21:43:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45168,CLOSED,2017-10-10T11:58:43Z,2017-11-06T13:29:07Z,Implement Iter::drain(&mut self) with feature iterator_helper,dns2utf8,NA,NA,NA,THUMBS_DOWN,2017-10-10T16:48:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-10T15:56:49Z,lqd,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-10T16:03:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-10T17:13:50Z,cramertj,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-10T17:45:31Z,est31,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HEART,2017-10-10T21:42:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-10T22:00:50Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2017-10-11T10:55:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45175,MERGED,2017-10-10T15:11:02Z,2017-10-14T18:48:14Z,Implement `dyn Trait` syntax (RFC 2113),petrochenkov,9d373204a5e67c91953f0080d4f93ebdcdcfc402,1,Update rustfmt submodule,HOORAY,2018-04-27T22:35:19Z,JesseWright,NA https://github.com/rust-lang/rust/pull/45177,MERGED,2017-10-10T15:27:49Z,2017-10-14T21:38:23Z,Enable building clippy in CI,oli-obk,c6c47fa6c0ee0569ba1ab725904c814aa33051ca,1,Update toolstate.toml,THUMBS_UP,2017-10-13T18:28:25Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45178,MERGED,2017-10-10T16:46:36Z,2017-10-13T20:14:49Z,Better error message for comma after base struct,Badel2,72cfd209410da7f9dd09357a3361bb5b561dee33,3,Add error for comma after base struct field `let x = { ..default() } // This comma is an error`,THUMBS_UP,2017-10-13T18:27:29Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45187,MERGED,2017-10-10T21:40:02Z,2017-11-01T04:20:04Z,Improve sidebar rendering and add methods list,GuillaumeGomez,6fa521c491b365b354771213186e35c2e2e7a628,2,Fix weird bugs,THUMBS_UP,2017-10-11T09:27:57Z,nical,nical@fastmail.com https://github.com/rust-lang/rust/pull/45190,MERGED,2017-10-10T23:39:33Z,2017-10-13T01:33:48Z,Shorten some test names,petrochenkov,ca61ea2c44b22d082235c77223c3813df4c1174f,14,Shorten some test names Paths to object files generated from them were too long and caused errors,LAUGH,2017-10-11T11:01:13Z,est31,NA https://github.com/rust-lang/rust/pull/45190,MERGED,2017-10-10T23:39:33Z,2017-10-13T01:33:48Z,Shorten some test names,petrochenkov,ca61ea2c44b22d082235c77223c3813df4c1174f,14,Shorten some test names Paths to object files generated from them were too long and caused errors,LAUGH,2017-10-11T16:12:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/45198,MERGED,2017-10-11T09:01:07Z,2017-11-22T15:08:21Z,Prevent fmt::Arguments from being shared across threads,oli-obk,dc7de37d995e5922ce3b016c5cc01f5fcd326570,1,Explain the `_oibit_remover` field,THUMBS_UP,2017-10-11T16:35:59Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/45198,MERGED,2017-10-11T09:01:07Z,2017-11-22T15:08:21Z,Prevent fmt::Arguments from being shared across threads,oli-obk,dc7de37d995e5922ce3b016c5cc01f5fcd326570,1,Explain the `_oibit_remover` field,LAUGH,2017-10-15T15:56:07Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T16:53:58Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T17:35:15Z,kennytm,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T19:26:44Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T19:41:39Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T19:49:06Z,est31,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HEART,2017-10-11T19:49:08Z,est31,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T20:37:54Z,pythonesque,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T21:20:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-11T22:04:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HEART,2017-10-11T22:04:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-13T17:38:34Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HEART,2017-10-19T23:31:08Z,cramertj,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-10-19T23:31:10Z,cramertj,NA https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HOORAY,2017-11-09T14:32:38Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/45205,MERGED,2017-10-11T16:30:19Z,2017-11-08T20:00:48Z,Saturating casts between integers and floats,hanna-kruppe,ef0b99930e52ee90f9452542dd14f148bbbe13af,1,Disable u128 <-> float tests on emscripten,HEART,2020-09-11T01:08:54Z,bb010g,NA https://github.com/rust-lang/rust/pull/45212,MERGED,2017-10-11T18:09:28Z,2017-10-26T00:58:49Z,Limit the sidebar height,GuillaumeGomez,9ce41f2544706bc3fc89f134668b607b0598e453,1,Fix the sidebar height,THUMBS_DOWN,2017-10-11T18:51:32Z,est31,NA https://github.com/rust-lang/rust/pull/45212,MERGED,2017-10-11T18:09:28Z,2017-10-26T00:58:49Z,Limit the sidebar height,GuillaumeGomez,9ce41f2544706bc3fc89f134668b607b0598e453,1,Fix the sidebar height,THUMBS_DOWN,2017-10-11T20:11:49Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/45212,MERGED,2017-10-11T18:09:28Z,2017-10-26T00:58:49Z,Limit the sidebar height,GuillaumeGomez,9ce41f2544706bc3fc89f134668b607b0598e453,1,Fix the sidebar height,THUMBS_UP,2017-10-24T20:31:23Z,kennytm,NA https://github.com/rust-lang/rust/pull/45221,MERGED,2017-10-11T21:40:58Z,2017-10-13T20:14:53Z,Point at immutable outer variable,estebank,fab6a10c00ffda25ed9ec3195b28a9f6a58150a4,3,Point at immutable outer variable When attempting to mutate an immutable outer variable from a closure point at the outer variable and suggest making it mutable.,HEART,2017-10-12T21:27:56Z,killercup,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",THUMBS_UP,2017-10-18T09:22:52Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HOORAY,2017-10-18T09:22:54Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HEART,2017-10-18T09:23:44Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",THUMBS_UP,2017-10-18T10:24:33Z,est31,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HOORAY,2017-10-18T10:24:33Z,est31,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HEART,2017-10-18T10:24:34Z,est31,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HEART,2018-01-19T17:48:52Z,avalent,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HOORAY,2019-01-24T23:18:14Z,benpicco,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HOORAY,2020-04-07T07:04:47Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",THUMBS_UP,2020-11-19T02:55:10Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/45224,MERGED,2017-10-12T00:48:08Z,2017-10-15T08:40:11Z,Add x86_64-unknown-linux-gnux32 target,malbarbo,7199feea9d480d44e1f5dac9342cc9951f20e6ad,1,"Revert ""Test x86_64-unknown-linux-gnux32""",HEART,2021-04-01T20:40:46Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-12T04:58:25Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T07:06:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T08:16:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T08:25:18Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-12T08:25:19Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T09:34:18Z,est31,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-12T09:34:18Z,est31,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T10:15:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-12T10:15:55Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-12T14:52:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-12T14:52:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T07:41:50Z,mrhota,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-13T07:50:46Z,mrhota,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T09:08:12Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-13T10:55:49Z,pitdicker,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T13:07:22Z,lqd,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T13:44:18Z,arthurprs,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-13T15:34:45Z,oyvindln,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T15:34:48Z,oyvindln,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-13T15:41:15Z,cramertj,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-13T15:41:17Z,cramertj,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-13T17:29:26Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-14T09:32:38Z,bjorn3,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-17T01:33:56Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-18T22:15:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-19T10:25:28Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-19T18:03:39Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-19T21:01:55Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-25T16:18:20Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-26T03:35:20Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-26T03:35:21Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-26T04:51:40Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-10-26T04:51:50Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-30T17:32:19Z,fbernier,frankbernier@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-30T19:34:45Z,killercup,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-10-31T03:04:37Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-03T05:28:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-05T03:46:55Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-06T10:04:31Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-10T06:35:51Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-13T21:12:30Z,ia0,github@ia0.eu https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-14T14:12:46Z,RReverser,me@rreverser.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-15T23:15:02Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-15T23:30:46Z,krdln,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-16T03:22:02Z,jrasky,jyrome.112@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-16T09:09:09Z,gurry,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-16T09:09:10Z,gurry,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-16T11:09:08Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-16T20:53:33Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-16T20:53:35Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-16T23:38:31Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-16T23:38:32Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-19T16:19:45Z,killercup,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-19T16:26:23Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-19T16:26:24Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-19T16:40:41Z,Havvy,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-19T16:54:51Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T02:16:47Z,behnam,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T02:16:49Z,behnam,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T03:41:10Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T03:41:10Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T04:03:23Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T08:57:00Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T11:17:33Z,ranma42,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T22:01:48Z,portal-chan,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T22:20:22Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T22:20:23Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-20T22:31:06Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T22:31:07Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T22:31:35Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T22:31:35Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T22:38:50Z,Timidger,APragmaticPlace@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T22:47:50Z,flosse,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-20T22:59:37Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T23:03:24Z,Ralith,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-20T23:08:45Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T23:12:04Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-20T23:14:34Z,NawfelBgh,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T23:27:17Z,the-kenny,moritz@tarn-vedra.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-20T23:52:05Z,bvssvni,bvssvni@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-20T23:54:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T00:07:00Z,ssokolow,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T00:16:57Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T01:23:05Z,dkaste,darrenkaste@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T01:25:12Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T01:25:19Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T01:25:22Z,DanielKeep,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T01:42:16Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T02:26:04Z,brendanzab,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T02:57:16Z,chrish42,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T03:13:02Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T03:33:05Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T03:33:06Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T03:33:06Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T03:54:56Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T04:23:01Z,delacian,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T06:03:05Z,kornholi,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T06:03:06Z,kornholi,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T06:11:49Z,dkashitsyn,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T06:20:32Z,I60R,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T06:20:32Z,I60R,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T06:20:33Z,I60R,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T07:19:51Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T07:22:12Z,huwsun,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T07:22:17Z,huwsun,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T07:24:37Z,loovjo,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T07:26:32Z,hyunsik,hyunsik@apache.org https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T07:40:03Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T08:27:20Z,g-k,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T08:53:40Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T09:13:28Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T09:22:30Z,aheart,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T09:31:54Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T09:31:55Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T11:30:46Z,budziq,budziq@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T11:32:56Z,hauleth,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T11:32:56Z,hauleth,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T11:32:59Z,hauleth,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T11:47:45Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T11:53:06Z,gimpf,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T12:14:13Z,debris,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T14:31:51Z,Diggsey,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T15:19:44Z,tbg,tobias.schottdorf@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T15:21:32Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T15:21:34Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T15:21:35Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T15:21:42Z,knz,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-21T15:33:33Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T17:42:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T17:43:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T17:58:10Z,Phlosioneer,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-21T18:47:36Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-21T19:17:38Z,liranringel,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-22T04:09:49Z,vmchale,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-22T05:57:13Z,isaacg1,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-22T06:46:25Z,loyd,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-22T07:08:28Z,perry-birch,perrybirch@vizidrix.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-22T07:55:25Z,grizwako,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-22T20:08:35Z,debugnik,debugnik@outlook.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-22T20:08:37Z,debugnik,debugnik@outlook.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-22T20:08:38Z,debugnik,debugnik@outlook.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-23T02:19:54Z,lawliet89,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-23T04:40:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-23T21:28:08Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-24T07:29:32Z,bb010g,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-24T07:29:33Z,bb010g,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-25T22:21:39Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-27T08:39:34Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-27T14:21:36Z,yberreby,yohaiberreby@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-27T21:11:01Z,nosideeffects,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-11-28T15:55:02Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-11-28T15:55:02Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-11-28T15:55:03Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-12-04T07:02:10Z,alexbool,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-12-04T07:02:11Z,alexbool,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-12-10T18:47:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-12-10T18:47:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-12-13T23:10:22Z,Congee,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-12-22T03:19:21Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-12-24T04:43:02Z,Lokathor,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-12-24T04:48:28Z,zmt00,zmt00@protonmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-12-25T22:52:57Z,albel727,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2017-12-26T18:33:51Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2017-12-26T18:36:39Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2017-12-26T18:36:40Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-01-09T10:58:13Z,SplittyDev,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2018-01-09T10:58:14Z,SplittyDev,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-01-09T10:58:16Z,SplittyDev,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-01-27T12:55:14Z,chrisdotcode,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-03-23T08:32:32Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-03-25T17:24:49Z,frol,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-03-25T17:24:50Z,frol,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2018-03-25T17:24:50Z,frol,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-03-30T05:52:41Z,gulbanana,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-04-09T20:51:44Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-04-20T03:23:20Z,tikue,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-04-30T17:38:33Z,JesseWright,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-06-01T18:37:52Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2018-09-04T13:55:29Z,estebank,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-09-30T08:39:18Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-09-30T08:39:21Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2018-09-30T08:39:29Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2018-11-14T17:43:21Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2018-11-14T17:43:22Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2018-11-14T17:43:24Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2019-02-14T05:17:06Z,king6cong,king6cong@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2019-05-17T21:38:00Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2019-05-17T21:38:02Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2019-08-16T22:30:32Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2019-08-16T22:30:33Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2019-08-16T22:30:34Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2019-11-21T10:11:18Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2019-11-21T10:11:19Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2019-11-21T10:11:22Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2020-01-12T06:45:48Z,95th,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2020-01-12T06:45:49Z,95th,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2020-01-12T06:45:58Z,95th,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2020-03-29T22:07:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2020-05-02T17:24:29Z,elihunter173,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2020-09-10T08:53:30Z,lilydjwg,lilydjwg@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2020-10-05T05:58:04Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2021-01-05T22:43:19Z,Neo-Ciber94,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2021-01-17T15:03:25Z,coffeenotfound,jan@katzer.dev https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2021-01-17T15:03:25Z,coffeenotfound,jan@katzer.dev https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2021-01-17T15:03:25Z,coffeenotfound,jan@katzer.dev https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2021-01-29T07:58:36Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2021-07-04T14:54:52Z,chpio,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2021-12-10T08:21:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2021-12-10T08:21:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2021-12-10T08:21:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",THUMBS_UP,2022-01-13T04:57:05Z,lukechu10,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2022-01-13T04:57:05Z,lukechu10,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HEART,2022-01-13T04:57:08Z,lukechu10,NA https://github.com/rust-lang/rust/pull/45225,MERGED,2017-10-12T02:34:06Z,2017-11-20T00:33:46Z,Refactor type memory layouts and ABIs to be more general and easier to optimize.,eddyb,f9f5ab98b0aae2a5ef8e41df2277ca3a2cd6e89a,1,"Revert ""tests: Update run-make/issue-25581 to reflect how fat pointers are passed."" This reverts commit b12dcdef4fae5e3856e6911fd6cfbeedadcf3821.",HOORAY,2022-01-28T05:13:33Z,andrewarchi,andrew@aarchibald.com https://github.com/rust-lang/rust/pull/45232,MERGED,2017-10-12T07:50:28Z,2017-10-19T15:04:54Z,code suggestions for non-shorthand field pattern no-mangle lints,zackmdavis,8e6ed1203b777747bb435c7eb11272ccf252cd52,2,bolster UI test converage for lint suggestions,HEART,2017-10-12T16:58:03Z,estebank,NA https://github.com/rust-lang/rust/pull/45232,MERGED,2017-10-12T07:50:28Z,2017-10-19T15:04:54Z,code suggestions for non-shorthand field pattern no-mangle lints,zackmdavis,8e6ed1203b777747bb435c7eb11272ccf252cd52,2,bolster UI test converage for lint suggestions,HEART,2017-10-25T08:46:17Z,hoodie,NA https://github.com/rust-lang/rust/pull/45232,MERGED,2017-10-12T07:50:28Z,2017-10-19T15:04:54Z,code suggestions for non-shorthand field pattern no-mangle lints,zackmdavis,8e6ed1203b777747bb435c7eb11272ccf252cd52,2,bolster UI test converage for lint suggestions,HEART,2017-10-26T12:24:02Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/45234,CLOSED,2017-10-12T10:46:59Z,2017-10-12T13:23:47Z,Auto,majamusan,NA,NA,NA,CONFUSED,2017-10-12T12:52:09Z,kennytm,NA https://github.com/rust-lang/rust/pull/45243,MERGED,2017-10-12T19:46:55Z,2017-10-16T21:30:03Z," rustbuild: Allow setting rls/rustfmt to ""broken""",alexcrichton,5050dadfc616b090d396deed9a4652a85c5f6f04,6,"rustbuild: Allow setting rls/rustfmt to ""broken"" This commit enables configuring the RLS/rustfmt tools to the ""broken"" state and actually get it past CI. The main changes here were to update all dist-related code to handle the situation where the RLS isn't available. This in turn involved a homegrown preprocessor-like-function to edit the configuration files we pass to the various combined installer tools.",HOORAY,2017-10-14T18:51:26Z,sunjay,NA https://github.com/rust-lang/rust/pull/45257,CLOSED,2017-10-13T12:11:31Z,2017-11-11T08:17:05Z,Add CR to panic backtrace,bjorn3,NA,NA,NA,CONFUSED,2017-10-13T12:20:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/45257,CLOSED,2017-10-13T12:11:31Z,2017-11-11T08:17:05Z,Add CR to panic backtrace,bjorn3,NA,NA,NA,CONFUSED,2017-10-18T06:08:54Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/45257,CLOSED,2017-10-13T12:11:31Z,2017-11-11T08:17:05Z,Add CR to panic backtrace,bjorn3,NA,NA,NA,CONFUSED,2017-10-19T20:21:17Z,Eallaneg46,NA https://github.com/rust-lang/rust/pull/45267,MERGED,2017-10-13T23:06:15Z,2017-11-01T07:04:20Z,remove the `T: Sync` requirement for `RwLock: Send`,oconnor663,fbf6885fd3ebc28a94007ab032ef1c9f135a0b69,1,remove the `T: Sync` requirement for `RwLock: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents but `RwLock` is not one of those. This restriction was added in https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e but it's not clear why.,THUMBS_UP,2017-10-16T19:20:10Z,hniksic,hniksic@gmail.com https://github.com/rust-lang/rust/pull/45267,MERGED,2017-10-13T23:06:15Z,2017-11-01T07:04:20Z,remove the `T: Sync` requirement for `RwLock: Send`,oconnor663,fbf6885fd3ebc28a94007ab032ef1c9f135a0b69,1,remove the `T: Sync` requirement for `RwLock: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents but `RwLock` is not one of those. This restriction was added in https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e but it's not clear why.,HEART,2017-10-17T02:16:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45267,MERGED,2017-10-13T23:06:15Z,2017-11-01T07:04:20Z,remove the `T: Sync` requirement for `RwLock: Send`,oconnor663,fbf6885fd3ebc28a94007ab032ef1c9f135a0b69,1,remove the `T: Sync` requirement for `RwLock: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents but `RwLock` is not one of those. This restriction was added in https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e but it's not clear why.,HEART,2017-10-31T16:44:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45267,MERGED,2017-10-13T23:06:15Z,2017-11-01T07:04:20Z,remove the `T: Sync` requirement for `RwLock: Send`,oconnor663,fbf6885fd3ebc28a94007ab032ef1c9f135a0b69,1,remove the `T: Sync` requirement for `RwLock: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents but `RwLock` is not one of those. This restriction was added in https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e but it's not clear why.,THUMBS_UP,2017-10-31T16:44:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45267,MERGED,2017-10-13T23:06:15Z,2017-11-01T07:04:20Z,remove the `T: Sync` requirement for `RwLock: Send`,oconnor663,fbf6885fd3ebc28a94007ab032ef1c9f135a0b69,1,remove the `T: Sync` requirement for `RwLock: Send` That requirement makes sense for containers like `Arc` that don't uniquely own their contents but `RwLock` is not one of those. This restriction was added in https://github.com/rust-lang/rust/commit/380d23b5d4b9fb8f5f0ebf178590f61528b2483e but it's not clear why.,THUMBS_UP,2017-11-09T06:34:07Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/45272,CLOSED,2017-10-14T05:42:47Z,2017-10-16T21:44:49Z,[WIP] Make Arc parametric on Alloc,joshlf,NA,NA,NA,HEART,2017-10-16T16:24:30Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,THUMBS_UP,2017-10-15T13:40:33Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,THUMBS_UP,2017-10-15T14:56:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,THUMBS_UP,2017-10-15T18:07:11Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,THUMBS_UP,2017-10-16T03:56:51Z,anguslees,gus@inodes.org https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,CONFUSED,2017-10-16T06:31:58Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,THUMBS_UP,2017-10-19T17:31:31Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/45306,MERGED,2017-10-15T13:31:55Z,2017-11-02T03:36:09Z,Bring back slice::ref_slice as slice::from_ref.,whitequark,1cc88be2ebc67e1f0e7ff57c12dec45ef9abc2ae,3,De-stabilize core::slice::{from_ref from_ref_mut}.,HOORAY,2017-12-27T23:47:45Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/45307,MERGED,2017-10-15T15:00:54Z,2017-10-17T20:21:46Z,Fix typo in rustdoc book,dbrgn,b7d378a94cb5e0f01872f8ce2036357c934bf93b,1,Fix typo in rustdoc book,LAUGH,2017-10-15T15:01:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/45315,MERGED,2017-10-16T02:43:17Z,2017-10-17T20:21:48Z,"don't issue ""expected statement after outer attr."" after inner attr.",zackmdavis,696612c02f7e64b8ca5f62c4614d0cb5b20ff9b7,3,"don't issue ""expected statement after outer attr."" after inner attr. While an inner attribute here is in fact erroneous that error (""inner attribute is not permitted in this context"") successfully gets set earlier; this further admonition is nonsensical. Resolves #45296.",THUMBS_UP,2017-10-16T03:12:43Z,Havvy,NA https://github.com/rust-lang/rust/pull/45326,MERGED,2017-10-16T20:15:03Z,2017-10-18T21:02:41Z,Bump the minimum LLVM to 3.9,cuviper,6309a475f912f8237cba57458bc598c2fc8fc90b,2,Remove two obsolete min-llvm-version tests,THUMBS_UP,2017-10-16T20:22:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45326,MERGED,2017-10-16T20:15:03Z,2017-10-18T21:02:41Z,Bump the minimum LLVM to 3.9,cuviper,6309a475f912f8237cba57458bc598c2fc8fc90b,2,Remove two obsolete min-llvm-version tests,HEART,2017-10-17T02:06:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45326,MERGED,2017-10-16T20:15:03Z,2017-10-18T21:02:41Z,Bump the minimum LLVM to 3.9,cuviper,6309a475f912f8237cba57458bc598c2fc8fc90b,2,Remove two obsolete min-llvm-version tests,HEART,2017-10-18T08:38:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-10-18T22:30:55Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-10-23T12:18:22Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-08T12:44:17Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-08T18:09:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-08T18:22:43Z,Boscop,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-08T23:57:34Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-09T16:08:16Z,Vurich,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-09T16:54:53Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-09T20:11:57Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-10T12:05:33Z,frol,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-15T20:11:28Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-16T09:41:05Z,ShikChen,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-16T11:05:20Z,fhartwig,florian.j.hartwig@gmail.com https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-16T14:57:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2017-11-18T22:47:08Z,StefanoD,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2018-01-02T12:13:58Z,gurry,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2020-01-17T21:40:29Z,frankdavid,NA https://github.com/rust-lang/rust/pull/45333,MERGED,2017-10-16T23:05:50Z,2017-11-11T20:41:36Z,Improve SliceExt::binary_search performance,alkis,2ca111b6b91c578c8a2b8e610471e582b6cf2c6b,4,Improve the performance of binary_search by reducing the number of unpredictable conditional branches in the loop. In addition improve the benchmarks to test performance in l1 l2 and l3 caches on sorted arrays with or without dups. Before: ``` test slice::binary_search_l1 ... bench: 48 ns/iter (+/- 1) test slice::binary_search_l2 ... bench: 63 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 152 ns/iter (+/- 12) test slice::binary_search_l1_with_dups ... bench: 36 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 64 ns/iter (+/- 1) test slice::binary_search_l3_with_dups ... bench: 153 ns/iter (+/- 6) ``` After: ``` test slice::binary_search_l1 ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2 ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3 ... bench: 100 ns/iter (+/- 17) test slice::binary_search_l1_with_dups ... bench: 15 ns/iter (+/- 0) test slice::binary_search_l2_with_dups ... bench: 23 ns/iter (+/- 0) test slice::binary_search_l3_with_dups ... bench: 98 ns/iter (+/- 14) ```,HEART,2020-07-03T15:12:22Z,Folyd,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-17T08:08:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-17T08:08:17Z,cramertj,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-17T09:07:33Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-17T09:07:34Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-18T09:42:29Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-18T09:42:31Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-18T09:57:16Z,Geal,contact@geoffroycouprie.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-18T09:57:17Z,Geal,contact@geoffroycouprie.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-18T12:05:26Z,lqd,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-18T12:05:27Z,lqd,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2017-10-18T19:21:57Z,kornholi,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-18T19:21:57Z,kornholi,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-21T04:36:17Z,carllerche,me@carllerche.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-10-21T14:46:39Z,rozaliev,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2017-11-23T07:22:24Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2018-01-02T18:48:05Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2018-01-05T05:18:28Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2018-01-10T12:04:01Z,matprec,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2018-01-31T16:57:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,THUMBS_UP,2018-02-01T21:08:26Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2018-02-02T13:23:53Z,kdy1,kdy1997.dev@gmail.com https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HOORAY,2020-01-29T04:28:40Z,YoshiTheChinchilla,NA https://github.com/rust-lang/rust/pull/45337,MERGED,2017-10-17T05:22:04Z,2018-01-24T01:43:44Z,Immovable generators,Zoxc,55c6c88782cfcce9b593c431200dad5f05bd9125,4,Port borrows across yield check to MIR borrowck,HEART,2020-01-29T04:28:41Z,YoshiTheChinchilla,NA https://github.com/rust-lang/rust/pull/45349,MERGED,2017-10-18T01:24:22Z,2017-10-19T21:14:42Z,added examples of closures for str::find,pvdrz,2a889eb945cdae95fce33fbeb1b79093c456cadd,1,added non trivial examples of closures for str::find,HEART,2017-10-18T05:32:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45349,MERGED,2017-10-18T01:24:22Z,2017-10-19T21:14:42Z,added examples of closures for str::find,pvdrz,2a889eb945cdae95fce33fbeb1b79093c456cadd,1,added non trivial examples of closures for str::find,THUMBS_UP,2017-10-19T07:58:16Z,Freyskeyd,NA https://github.com/rust-lang/rust/pull/45355,CLOSED,2017-10-18T07:11:05Z,2017-10-18T07:14:50Z,Auto,pipili0131,NA,NA,NA,THUMBS_DOWN,2017-10-18T09:43:41Z,kennytm,NA https://github.com/rust-lang/rust/pull/45370,MERGED,2017-10-18T18:47:29Z,2017-10-21T07:04:44Z,std: Update randomness implementation on Windows,alexcrichton,55c01736cbabc8e4541b814ae8149173b8028651,2,"std: Update randomness implementation on Windows This commit updates the OS random number generator on Windows to match the upstream implementation in the `rand` crate. First proposed in rust-lang-nursery/rand#111 this implementation uses a ""private"" API of `RtlGenRandom`. Despite the [documentation][dox] indicating this is a private function its widespread use in Chromium and Firefox as well as [comments] from Microsoft internally indicates that it's highly unlikely to break. Another motivation for switching this is to also attempt to make progress on #44911. It may be the case that this function succeeds while the previous implementation may fail in ""weird"" scenarios. [dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx [comments]: https://github.com/rust-lang-nursery/rand/issues/111#issuecomment-316140155",THUMBS_UP,2017-10-19T01:31:22Z,retep998,NA https://github.com/rust-lang/rust/pull/45370,MERGED,2017-10-18T18:47:29Z,2017-10-21T07:04:44Z,std: Update randomness implementation on Windows,alexcrichton,55c01736cbabc8e4541b814ae8149173b8028651,2,"std: Update randomness implementation on Windows This commit updates the OS random number generator on Windows to match the upstream implementation in the `rand` crate. First proposed in rust-lang-nursery/rand#111 this implementation uses a ""private"" API of `RtlGenRandom`. Despite the [documentation][dox] indicating this is a private function its widespread use in Chromium and Firefox as well as [comments] from Microsoft internally indicates that it's highly unlikely to break. Another motivation for switching this is to also attempt to make progress on #44911. It may be the case that this function succeeds while the previous implementation may fail in ""weird"" scenarios. [dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx [comments]: https://github.com/rust-lang-nursery/rand/issues/111#issuecomment-316140155",THUMBS_UP,2017-10-25T14:45:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",CONFUSED,2017-10-19T14:32:58Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_DOWN,2017-10-20T16:55:33Z,kennytm,NA https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",CONFUSED,2017-10-21T05:23:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",HOORAY,2017-11-15T15:54:21Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",HOORAY,2017-11-15T23:05:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_DOWN,2017-11-16T01:27:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2017-11-16T14:58:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2017-12-26T13:48:17Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2018-01-04T16:58:26Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2018-01-15T04:48:54Z,ciphergoth,github@paul.ciphergoth.org https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2018-02-13T23:41:11Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/45379,MERGED,2017-10-19T06:15:09Z,2017-11-08T04:06:58Z,impl FromIterator<()> for (),cuviper,68d05b2a073d2679ec1621ea1ebc49b7814cf250,2,"impl FromIterator<()> for () This just collapses all unit items from an iterator into one. This is more useful when combined with higher-level abstractions like collecting to a `Result<() E>` where you only care about errors: ```rust use std::io::*; data = vec![1 2 3 4 5]; let res: Result<()> = data.iter() .map(|x| writeln!(stdout() ""{}"" x)) .collect(); assert!(res.is_ok()); ```",THUMBS_UP,2020-08-19T18:19:25Z,Ghabriel,ghabriel.nunes@gmail.com https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2017-11-01T08:28:07Z,arthurprs,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2017-11-01T10:28:07Z,delacian,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2017-11-01T15:02:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2017-11-01T18:10:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2017-11-16T23:42:09Z,jseyfried,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-01-04T18:27:57Z,StefanoD,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-01-04T19:30:29Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-01-05T20:29:54Z,aheart,NA https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-01-06T17:01:22Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-03-24T06:11:04Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45380,MERGED,2017-10-19T07:55:05Z,2017-10-26T16:58:33Z,Avoid unnecessary copies of arguments that are simple bindings,dotdash,8ad7c284d793250edffe0e85f6cc898585496283,2,Add comments to clarify function argument ownership,HOORAY,2018-12-08T17:42:29Z,frol,NA https://github.com/rust-lang/rust/pull/45393,MERGED,2017-10-19T20:27:51Z,2017-10-21T21:34:16Z,ci: Update musl with new release,alexcrichton,b1f246c12eb3a216b807c329f1756131c1f1bc1e,3,ci: Update musl with new release Apparently there's at least one CVE fixed in the new version of musl and because we're distributing it seems like a good opportunity to update! Unfortunately it looks like #38618 still hasn't been fixed.,HEART,2018-01-04T18:19:23Z,tjkirch,NA https://github.com/rust-lang/rust/pull/45394,MERGED,2017-10-19T20:53:29Z,2017-11-04T20:35:19Z,RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute,davidtwco,86c62d02eebb037faf7c0752a9c472181e5608cb,1,Ignoring pretty print for test due to #37199,HOORAY,2017-10-19T23:33:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/45394,MERGED,2017-10-19T20:53:29Z,2017-11-04T20:35:19Z,RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute,davidtwco,86c62d02eebb037faf7c0752a9c472181e5608cb,1,Ignoring pretty print for test due to #37199,HOORAY,2017-11-08T00:09:46Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/45404,MERGED,2017-10-20T07:30:58Z,2018-02-16T03:21:18Z,#37653 support `default impl` for specialization,giannicic,220bb22e1b621ad5a10a44080e3e1872d99f3e9f,8,add Self: Trait<..> inside the param_env of a default impl,HOORAY,2017-10-22T08:52:42Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/45404,MERGED,2017-10-20T07:30:58Z,2018-02-16T03:21:18Z,#37653 support `default impl` for specialization,giannicic,220bb22e1b621ad5a10a44080e3e1872d99f3e9f,8,add Self: Trait<..> inside the param_env of a default impl,THUMBS_UP,2017-10-24T15:49:02Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/45404,MERGED,2017-10-20T07:30:58Z,2018-02-16T03:21:18Z,#37653 support `default impl` for specialization,giannicic,220bb22e1b621ad5a10a44080e3e1872d99f3e9f,8,add Self: Trait<..> inside the param_env of a default impl,HOORAY,2018-01-21T08:17:36Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45404,MERGED,2017-10-20T07:30:58Z,2018-02-16T03:21:18Z,#37653 support `default impl` for specialization,giannicic,220bb22e1b621ad5a10a44080e3e1872d99f3e9f,8,add Self: Trait<..> inside the param_env of a default impl,HOORAY,2018-02-22T14:46:12Z,loovjo,NA https://github.com/rust-lang/rust/pull/45404,MERGED,2017-10-20T07:30:58Z,2018-02-16T03:21:18Z,#37653 support `default impl` for specialization,giannicic,220bb22e1b621ad5a10a44080e3e1872d99f3e9f,8,add Self: Trait<..> inside the param_env of a default impl,THUMBS_UP,2018-02-22T17:14:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45415,CLOSED,2017-10-20T15:15:53Z,2017-10-20T15:32:02Z,Update the Cargo submodule,est31,NA,NA,NA,LAUGH,2017-10-20T15:16:37Z,kennytm,NA https://github.com/rust-lang/rust/pull/45415,CLOSED,2017-10-20T15:15:53Z,2017-10-20T15:32:02Z,Update the Cargo submodule,est31,NA,NA,NA,LAUGH,2017-10-20T15:23:51Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/45418,MERGED,2017-10-20T17:11:59Z,2017-10-21T16:32:43Z,"Remove ""gender"" from code of conduct keep only ""gender identity and expression""",Manishearth,34c0de2067b132c8d68689501604d4fffbe9fba8,1,"Remove ""gender"" from code of conduct keep only ""gender identity and expression"" Mirrors https://github.com/rust-lang/rust-www/pull/954 . See that pull request for motivation.",THUMBS_UP,2017-10-21T13:29:31Z,oyvindln,NA https://github.com/rust-lang/rust/pull/45434,CLOSED,2017-10-21T16:35:37Z,2018-01-04T16:01:17Z,[vec] growth-strategy optimization,gnzlbg,NA,NA,NA,THUMBS_UP,2018-02-19T15:28:47Z,krk,keremkat@gmail.com https://github.com/rust-lang/rust/pull/45435,MERGED,2017-10-21T17:19:40Z,2017-11-01T12:16:24Z,rustc_typeck: use subtyping on the LHS of binops.,eddyb,1a7fb7dc78439a704f024609ce3dc0beb1386552,8,rustc_typeck: use subtyping on the LHS of binops.,HOORAY,2017-11-01T13:09:44Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45435,MERGED,2017-10-21T17:19:40Z,2017-11-01T12:16:24Z,rustc_typeck: use subtyping on the LHS of binops.,eddyb,1a7fb7dc78439a704f024609ce3dc0beb1386552,8,rustc_typeck: use subtyping on the LHS of binops.,HOORAY,2017-11-04T23:43:33Z,jseyfried,NA https://github.com/rust-lang/rust/pull/45452,MERGED,2017-10-22T17:24:28Z,2017-11-08T22:27:10Z,Detect `=` -> `:` typo in let bindings,estebank,9dc7abe06d2b2771b09b6dac6eef5ac83b58573f,8,Detect `=` -> `:` typo in let bindings When encountering a let binding type error attempt to parse as initializer instead. If successful it is likely just a typo: ```rust fn main() { let x: Vec::with_capacity(10); } ``` ``` error: expected type found `10` --> file.rs:3:31 | 3 | let x: Vec::with_capacity(10 20); | -- ^^ | || | |help: did you mean assign here?: `=` | while parsing the type for `x` ```,THUMBS_UP,2017-11-15T08:30:49Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/45452,MERGED,2017-10-22T17:24:28Z,2017-11-08T22:27:10Z,Detect `=` -> `:` typo in let bindings,estebank,9dc7abe06d2b2771b09b6dac6eef5ac83b58573f,8,Detect `=` -> `:` typo in let bindings When encountering a let binding type error attempt to parse as initializer instead. If successful it is likely just a typo: ```rust fn main() { let x: Vec::with_capacity(10); } ``` ``` error: expected type found `10` --> file.rs:3:31 | 3 | let x: Vec::with_capacity(10 20); | -- ^^ | || | |help: did you mean assign here?: `=` | while parsing the type for `x` ```,THUMBS_UP,2017-11-15T21:04:21Z,Ryman,NA https://github.com/rust-lang/rust/pull/45452,MERGED,2017-10-22T17:24:28Z,2017-11-08T22:27:10Z,Detect `=` -> `:` typo in let bindings,estebank,9dc7abe06d2b2771b09b6dac6eef5ac83b58573f,8,Detect `=` -> `:` typo in let bindings When encountering a let binding type error attempt to parse as initializer instead. If successful it is likely just a typo: ```rust fn main() { let x: Vec::with_capacity(10); } ``` ``` error: expected type found `10` --> file.rs:3:31 | 3 | let x: Vec::with_capacity(10 20); | -- ^^ | || | |help: did you mean assign here?: `=` | while parsing the type for `x` ```,THUMBS_UP,2017-11-20T14:34:50Z,scalar438,scalar438@gmail.com https://github.com/rust-lang/rust/pull/45452,MERGED,2017-10-22T17:24:28Z,2017-11-08T22:27:10Z,Detect `=` -> `:` typo in let bindings,estebank,9dc7abe06d2b2771b09b6dac6eef5ac83b58573f,8,Detect `=` -> `:` typo in let bindings When encountering a let binding type error attempt to parse as initializer instead. If successful it is likely just a typo: ```rust fn main() { let x: Vec::with_capacity(10); } ``` ``` error: expected type found `10` --> file.rs:3:31 | 3 | let x: Vec::with_capacity(10 20); | -- ^^ | || | |help: did you mean assign here?: `=` | while parsing the type for `x` ```,THUMBS_UP,2017-11-22T22:10:09Z,hoodie,NA https://github.com/rust-lang/rust/pull/45454,MERGED,2017-10-22T19:16:32Z,2017-11-19T19:55:21Z,Updated Release notes for 1.22.0,XAMPPRocky,e0ac8647b6acac7ea5f894e3b9d66bf1c4915087,1,Update RELEASES.md,HEART,2017-10-22T20:46:31Z,bluss,NA https://github.com/rust-lang/rust/pull/45454,MERGED,2017-10-22T19:16:32Z,2017-11-19T19:55:21Z,Updated Release notes for 1.22.0,XAMPPRocky,e0ac8647b6acac7ea5f894e3b9d66bf1c4915087,1,Update RELEASES.md,HEART,2017-10-29T11:24:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45455,MERGED,2017-10-22T20:36:32Z,2017-10-25T05:02:45Z,Improve diagnostic of E0119 with extern crate try to print the conflicting impl.,kennytm,9d050069bb2325e2644a9798ad8d6f6e97671546,16,Print the conflicting impl on E0119 with external crate.,HOORAY,2017-10-31T04:15:05Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/45461,MERGED,2017-10-23T02:18:35Z,2017-10-25T18:19:55Z,Two small enhancements to intrinsics docs,wesleywiser,3bc97bfe9a1082693488105cb540fdc10d1d38e1,1,Add link to stable version of `needs_drop` intrinsic,HEART,2017-10-23T05:14:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45472,MERGED,2017-10-23T15:04:33Z,2017-11-01T17:12:15Z,incr.comp.: Implement compiler diagnostic persistence.,michaelwoerister,6faba5bf8d19de75249280c200399d1cef9abe2b,1,Fix librustc_driver unit test after API change.,HOORAY,2017-10-23T16:45:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45472,MERGED,2017-10-23T15:04:33Z,2017-11-01T17:12:15Z,incr.comp.: Implement compiler diagnostic persistence.,michaelwoerister,6faba5bf8d19de75249280c200399d1cef9abe2b,1,Fix librustc_driver unit test after API change.,HOORAY,2017-11-09T04:38:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45473,MERGED,2017-10-23T15:48:55Z,2017-10-25T07:40:15Z,Remove dependency tracking for variance computation,SimonSapin,94edd8fa4836e42820529ab751a4bbd56b6f4b14,6,Remove dependency tracking for variance computation This custom tracking is now replaced by the red/green algorithm. Fix https://github.com/rust-lang/rust/issues/45471,HOORAY,2017-10-24T08:50:58Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45473,MERGED,2017-10-23T15:48:55Z,2017-10-25T07:40:15Z,Remove dependency tracking for variance computation,SimonSapin,94edd8fa4836e42820529ab751a4bbd56b6f4b14,6,Remove dependency tracking for variance computation This custom tracking is now replaced by the red/green algorithm. Fix https://github.com/rust-lang/rust/issues/45471,HEART,2017-10-24T08:51:00Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45484,MERGED,2017-10-24T06:40:51Z,2017-11-03T03:20:44Z,Report lint names in json diagnostics,oli-obk,6ae440e04806ef2a9d21df4ee6f9e0006db5b05f,13,Make the difference between lint codes and error codes explicit,HEART,2017-10-24T07:44:49Z,killercup,NA https://github.com/rust-lang/rust/pull/45484,MERGED,2017-10-24T06:40:51Z,2017-11-03T03:20:44Z,Report lint names in json diagnostics,oli-obk,6ae440e04806ef2a9d21df4ee6f9e0006db5b05f,13,Make the difference between lint codes and error codes explicit,HEART,2017-11-03T12:46:43Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45502,MERGED,2017-10-24T20:36:32Z,2017-10-25T18:19:59Z,Show src button and function version on mobile version,GuillaumeGomez,deef11dd26889cd8b37329cb1589d2abf89d5a04,1,Show src button and function version on mobile version,HOORAY,2017-10-24T23:14:05Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/45502,MERGED,2017-10-24T20:36:32Z,2017-10-25T18:19:59Z,Show src button and function version on mobile version,GuillaumeGomez,deef11dd26889cd8b37329cb1589d2abf89d5a04,1,Show src button and function version on mobile version,HOORAY,2017-10-25T17:35:37Z,durka,NA https://github.com/rust-lang/rust/pull/45502,MERGED,2017-10-24T20:36:32Z,2017-10-25T18:19:59Z,Show src button and function version on mobile version,GuillaumeGomez,deef11dd26889cd8b37329cb1589d2abf89d5a04,1,Show src button and function version on mobile version,HOORAY,2017-10-25T18:21:32Z,rightfold,rightfold@gmail.com https://github.com/rust-lang/rust/pull/45519,MERGED,2017-10-25T13:06:57Z,2017-10-26T20:58:20Z,Don't emit the same compiler diagnostic twice.,michaelwoerister,9736474b6c3d3ce82587745723f09aca8f987c00,1,Update ui tests for error message deduplication.,THUMBS_UP,2017-10-31T22:04:33Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45523,MERGED,2017-10-25T14:55:30Z,2017-10-27T02:19:30Z,std: Disable usage of mmap allocator in libbacktrace,alexcrichton,2f3c412c84712f2159ccf5c174ac716d19925d68,1,std: Disable usage of mmap allocator in libbacktrace This is sort of a long overdue change from the investigation in #29293 and #37477. The released binaries of rustc don't have debug information and so don't actively suffer this problem but this can hit local development of rustc and also larger programs compiled against libstd generating backtraces. The main purpose of the mmap allocator in libacktrace is to be usable from a signal handler but we don't do that so the normal allocator using malloc/free should work well for us.,HOORAY,2017-10-25T15:54:02Z,kennytm,NA https://github.com/rust-lang/rust/pull/45524,MERGED,2017-10-25T16:04:40Z,2017-10-27T04:50:15Z,std: Optimize thread park/unpark implementation,alexcrichton,6511e4675345887bd8f60bfd8296a1451a08f73c,1,"std: Optimize thread park/unpark implementation This is an adaptation of alexcrichton/futures-rs#597 for the standard library. The goal here is to avoid locking a mutex on the ""fast path"" for thread park/unpark where you're waking up a thread that isn't sleeping or otherwise trying to park a thread that's already been notified. Mutex performance varies quite a bit across platforms so this should provide a nice consistent speed boost for the fast path of these functions.",HEART,2017-10-25T16:57:29Z,arthurprs,NA https://github.com/rust-lang/rust/pull/45524,MERGED,2017-10-25T16:04:40Z,2017-10-27T04:50:15Z,std: Optimize thread park/unpark implementation,alexcrichton,6511e4675345887bd8f60bfd8296a1451a08f73c,1,"std: Optimize thread park/unpark implementation This is an adaptation of alexcrichton/futures-rs#597 for the standard library. The goal here is to avoid locking a mutex on the ""fast path"" for thread park/unpark where you're waking up a thread that isn't sleeping or otherwise trying to park a thread that's already been notified. Mutex performance varies quite a bit across platforms so this should provide a nice consistent speed boost for the fast path of these functions.",HEART,2017-10-26T12:38:21Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45524,MERGED,2017-10-25T16:04:40Z,2017-10-27T04:50:15Z,std: Optimize thread park/unpark implementation,alexcrichton,6511e4675345887bd8f60bfd8296a1451a08f73c,1,"std: Optimize thread park/unpark implementation This is an adaptation of alexcrichton/futures-rs#597 for the standard library. The goal here is to avoid locking a mutex on the ""fast path"" for thread park/unpark where you're waking up a thread that isn't sleeping or otherwise trying to park a thread that's already been notified. Mutex performance varies quite a bit across platforms so this should provide a nice consistent speed boost for the fast path of these functions.",HEART,2017-11-01T19:48:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45525,MERGED,2017-10-25T16:08:01Z,2017-12-19T04:21:00Z,Move collector to librustc_mir::monomorphize,MaikKlein,6e78b665786b3f37730d5af3363ce74ad832282d,1,Add rustc_data_structures for trans_utils/lib.rs,HEART,2017-12-01T18:35:11Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45525,MERGED,2017-10-25T16:08:01Z,2017-12-19T04:21:00Z,Move collector to librustc_mir::monomorphize,MaikKlein,6e78b665786b3f37730d5af3363ce74ad832282d,1,Add rustc_data_structures for trans_utils/lib.rs,HEART,2017-12-06T13:05:52Z,volodg,gorbenko.vova@gmail.com https://github.com/rust-lang/rust/pull/45527,CLOSED,2017-10-25T17:03:21Z,2017-11-23T23:05:23Z,Add functions core::ptr::dangling/_mut() -> *const/*mut T,bluss,NA,NA,NA,THUMBS_UP,2017-10-26T08:23:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45527,CLOSED,2017-10-25T17:03:21Z,2017-11-23T23:05:23Z,Add functions core::ptr::dangling/_mut() -> *const/*mut T,bluss,NA,NA,NA,THUMBS_UP,2017-10-26T08:38:33Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45527,CLOSED,2017-10-25T17:03:21Z,2017-11-23T23:05:23Z,Add functions core::ptr::dangling/_mut() -> *const/*mut T,bluss,NA,NA,NA,THUMBS_UP,2017-11-23T16:14:57Z,delacian,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T22:42:07Z,cramertj,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T22:42:08Z,cramertj,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T22:42:10Z,cramertj,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T22:42:39Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T22:45:43Z,Aceeri,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T22:57:04Z,Pratyush,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:05:52Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:07:03Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:15:23Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:15:44Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:15:45Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:18:59Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:19:00Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:19:01Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:24:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:24:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:24:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:26:17Z,Cldfire,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:32:23Z,dlight,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:32:24Z,dlight,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:32:24Z,dlight,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:36:21Z,CryZe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:36:22Z,CryZe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:36:22Z,CryZe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:36:56Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-25T23:39:23Z,est31,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:39:24Z,est31,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-25T23:39:25Z,est31,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:43:54Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-25T23:47:55Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:00:59Z,emberian,ember@lunar.town https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:11:13Z,coder543,coder543@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T00:11:13Z,coder543,coder543@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:16:05Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:18:53Z,durka,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:20:13Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:35:59Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:45:58Z,Ixrec,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T00:58:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T00:58:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T01:02:50Z,Flaise,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T01:39:58Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T01:44:40Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T01:44:42Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T01:44:42Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T01:50:39Z,Timidger,APragmaticPlace@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T01:54:06Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T01:57:10Z,leovailati,leovailati@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T02:07:51Z,Havvy,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T02:07:52Z,Havvy,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T02:07:54Z,Havvy,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T02:31:16Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T02:38:41Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T03:46:28Z,brendanzab,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T03:46:30Z,brendanzab,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T03:46:31Z,brendanzab,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T03:54:40Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T03:54:41Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T03:54:42Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T03:57:43Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T03:57:44Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T03:57:46Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T04:54:55Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T05:01:45Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T05:22:54Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T05:22:58Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T05:22:59Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T05:28:22Z,turnage,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T05:39:37Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T05:39:37Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T05:39:37Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T05:46:35Z,mihe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T07:04:20Z,arthurprs,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T07:10:11Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T07:17:35Z,beholdnec,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T07:18:21Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T07:38:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T07:54:25Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:15:43Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T08:16:03Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T08:16:03Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:17:57Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:22:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:29:12Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:30:08Z,hirschenberger,falco.hirschenberger@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T08:31:56Z,kindlychung,kindlychung@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T08:56:33Z,Jake-Shadle,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T09:24:37Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T09:25:37Z,tazjin,mail@tazj.in https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T10:13:57Z,Meralis40,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T10:40:21Z,matprec,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T10:42:18Z,WaDelma,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T11:04:10Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T11:05:01Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T11:05:02Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T11:08:36Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T11:08:40Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T11:09:56Z,LunNova,github@lunnova.dev https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T11:18:26Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T11:27:18Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T11:32:02Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T12:18:29Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T12:21:21Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T12:45:23Z,lqd,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T12:45:24Z,lqd,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T12:45:24Z,lqd,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T12:54:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T12:54:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T12:54:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T13:13:47Z,aqrln,alex@aqrln.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T14:00:27Z,Arrem,alem.zupa@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T14:14:55Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T15:22:51Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T15:22:52Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T15:22:53Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T15:38:10Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T15:41:38Z,HybridEidolon,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T16:15:05Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T16:22:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T16:39:42Z,chrish42,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T16:58:55Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T17:01:55Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T17:24:20Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T17:43:49Z,kornholi,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T17:43:50Z,kornholi,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T17:55:53Z,kornholi,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T18:55:23Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T18:55:24Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T18:55:26Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T20:18:35Z,matprec,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T21:52:39Z,mrhota,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T21:52:40Z,mrhota,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T21:52:40Z,mrhota,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-26T22:00:13Z,LoveBug,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-26T22:00:15Z,LoveBug,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-26T22:00:16Z,LoveBug,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-27T02:10:29Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T02:10:30Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-27T02:10:30Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T06:34:38Z,johncf,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-27T06:34:41Z,johncf,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T08:41:04Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-27T16:37:26Z,kerskuchen,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T16:37:27Z,kerskuchen,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-27T16:37:29Z,kerskuchen,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T18:43:35Z,max-frai,me@maxfrai.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-27T20:44:09Z,SHSE,shumov.ss@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-27T20:44:10Z,SHSE,shumov.ss@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-27T20:44:15Z,SHSE,shumov.ss@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-29T20:21:20Z,qezz,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-29T20:22:26Z,qezz,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-10-29T20:22:28Z,qezz,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-30T06:21:11Z,nayato,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-10-30T13:50:15Z,gulrotkake,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-30T13:51:02Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-10-30T14:06:41Z,jbayardo,julian@bayardo.info https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-01T01:53:45Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-01T03:04:04Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-01T03:04:05Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-01T03:04:06Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-01T16:55:10Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-02T02:55:56Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-02T03:58:04Z,andrewjstone,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-02T03:58:05Z,andrewjstone,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-02T03:58:06Z,andrewjstone,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-02T05:08:11Z,NathanFlurry,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-02T05:08:12Z,NathanFlurry,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-02T05:08:12Z,NathanFlurry,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-02T05:36:06Z,nicolai86,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-02T14:33:04Z,tjkirch,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-02T19:09:51Z,pmarks,pmarks@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-03T02:25:37Z,yanns,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-08T03:43:45Z,liamstask,liam@stask.net https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-08T04:50:28Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-08T07:52:27Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-08T07:59:41Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-08T08:17:22Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-08T10:20:59Z,repax,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-08T10:21:03Z,repax,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-08T14:56:26Z,Darksecond,mail@darksecond.nl https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-08T22:38:46Z,schulzch,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-09T03:52:57Z,gabrfarina,gabr.farina@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-09T06:44:03Z,Etherian,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-09T12:56:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-10T16:09:22Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-11T08:19:33Z,rekka,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-11T15:41:38Z,aseyboldt,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-15T12:47:42Z,crypto-universe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-15T12:47:45Z,crypto-universe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-15T12:47:47Z,crypto-universe,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-17T15:01:36Z,junyi,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2017-11-25T21:04:23Z,timotree3,timorcb@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2017-11-25T21:04:24Z,timotree3,timorcb@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2017-11-25T21:04:27Z,timotree3,timorcb@gmail.com https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HEART,2018-01-04T13:44:03Z,dgtony,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2018-01-04T13:44:04Z,dgtony,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2018-01-04T13:44:05Z,dgtony,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,THUMBS_UP,2018-03-13T10:51:10Z,tux3,NA https://github.com/rust-lang/rust/pull/45538,MERGED,2017-10-25T22:41:42Z,2017-11-01T21:10:10Z,enable non-lexical lifetimes in the MIR borrow checker,nikomatsakis,aae3e74e70e3b21d00142ca9175e9d806d09a2bf,3,patch mir-opt reference files,HOORAY,2018-03-13T10:51:12Z,tux3,NA https://github.com/rust-lang/rust/pull/45540,MERGED,2017-10-26T00:02:56Z,2017-10-28T23:40:40Z,Avoid repetition on “use of unstable library feature 'rustc_private'”,virgil-palanciuc,bb0049bcd21ca8c9707207de4669fadfd7362367,1,fixed tidy error,CONFUSED,2017-10-28T21:34:09Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/45569,MERGED,2017-10-27T05:57:18Z,2017-11-03T19:07:58Z,`unreachable-pub` lint (as authorized by RFC 2126),zackmdavis,085ec6d5286151fb06416965eb5ebaaf947b5ec8,6,unreachable-pub lint for `pub` items not reachable from crate root This is with deepest thanks to Vadim Petrochenkov for thorough review and resolves #45521.,LAUGH,2017-10-27T19:26:19Z,Ixrec,NA https://github.com/rust-lang/rust/pull/45569,MERGED,2017-10-27T05:57:18Z,2017-11-03T19:07:58Z,`unreachable-pub` lint (as authorized by RFC 2126),zackmdavis,085ec6d5286151fb06416965eb5ebaaf947b5ec8,6,unreachable-pub lint for `pub` items not reachable from crate root This is with deepest thanks to Vadim Petrochenkov for thorough review and resolves #45521.,HOORAY,2017-10-30T18:49:08Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/45569,MERGED,2017-10-27T05:57:18Z,2017-11-03T19:07:58Z,`unreachable-pub` lint (as authorized by RFC 2126),zackmdavis,085ec6d5286151fb06416965eb5ebaaf947b5ec8,6,unreachable-pub lint for `pub` items not reachable from crate root This is with deepest thanks to Vadim Petrochenkov for thorough review and resolves #45521.,HOORAY,2017-10-31T22:49:17Z,estebank,NA https://github.com/rust-lang/rust/pull/45569,MERGED,2017-10-27T05:57:18Z,2017-11-03T19:07:58Z,`unreachable-pub` lint (as authorized by RFC 2126),zackmdavis,085ec6d5286151fb06416965eb5ebaaf947b5ec8,6,unreachable-pub lint for `pub` items not reachable from crate root This is with deepest thanks to Vadim Petrochenkov for thorough review and resolves #45521.,LAUGH,2017-11-25T07:55:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45580,MERGED,2017-10-27T19:19:40Z,2017-10-29T02:16:35Z,ci: Upgrade Android SDK/NDK and refactor to use sdkmanager/avdmanager.,kennytm,c46b04cbdd1bdf0183b121fac18513c0609962ee,8,ci: Upgrade Android SDK/NDK and refactor to use sdkmanager/avdmanager. * SDK tools is upgraded to 27.0.0. - Refactored to use `sdkmanager`/`avdmanager` instead of the deprecated `android` tool. * The Java version used by Android SDK is downgraded to OpenJDK-8 in order to download the SDK through HTTPS. * NDK is upgrade to r15c. - Dropped support for android-9 (2.3 / Gingerbread) the minimal supported version is now android-14 (4.0 / Ice Cream Sandwich). - Changed the default Android compiler from GCC to clang. - For details of change introduced by NDK r15 see https://github.com/android-ndk/ndk/wiki/Changelog-r15.,THUMBS_UP,2017-10-27T20:14:48Z,malbarbo,NA https://github.com/rust-lang/rust/pull/45592,CLOSED,2017-10-28T11:25:29Z,2017-10-28T21:50:19Z,Re-enable rustfmt testing,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2017-10-28T13:50:51Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/45595,MERGED,2017-10-28T15:25:12Z,2017-11-17T10:12:28Z,Short-circuiting internal iteration with Iterator::try_fold & try_rfold,scottmcm,b5dba91a19571f28e644a1aa5d60a10d3dd4562b,2,CR feedback,THUMBS_UP,2020-02-12T10:20:04Z,bb010g,NA https://github.com/rust-lang/rust/pull/45597,MERGED,2017-10-28T17:51:26Z,2017-10-29T23:59:20Z,tools: Update rustfmt and re-enable testing,DSpeckhals,e3bf19d8d4d6a8263618ec6acab83d9ecabd6404,2,Update rustfmt again,THUMBS_UP,2017-10-29T19:32:59Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/45618,MERGED,2017-10-29T17:35:35Z,2017-10-30T05:08:10Z,Update cargo.,kennytm,30828c58e78e3660216d6ac6bd980e334aed37b8,1,Update cargo. Brings in rust-lang/cargo#4672 unbreaks nightly on macOS APFS.,THUMBS_UP,2017-10-29T18:00:56Z,jedisct1,NA https://github.com/rust-lang/rust/pull/45618,MERGED,2017-10-29T17:35:35Z,2017-10-30T05:08:10Z,Update cargo.,kennytm,30828c58e78e3660216d6ac6bd980e334aed37b8,1,Update cargo. Brings in rust-lang/cargo#4672 unbreaks nightly on macOS APFS.,THUMBS_UP,2017-11-12T06:50:30Z,keyganker,fy63572507@gmail.com https://github.com/rust-lang/rust/pull/45637,CLOSED,2017-10-30T20:31:42Z,2018-01-28T15:20:46Z,Ignore panic functions in backtraces. Print inlined functions on Windows,Zoxc,NA,NA,NA,THUMBS_UP,2017-10-30T21:29:17Z,cramertj,NA https://github.com/rust-lang/rust/pull/45637,CLOSED,2017-10-30T20:31:42Z,2018-01-28T15:20:46Z,Ignore panic functions in backtraces. Print inlined functions on Windows,Zoxc,NA,NA,NA,THUMBS_UP,2017-10-31T00:12:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45637,CLOSED,2017-10-30T20:31:42Z,2018-01-28T15:20:46Z,Ignore panic functions in backtraces. Print inlined functions on Windows,Zoxc,NA,NA,NA,THUMBS_UP,2018-01-28T15:29:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/45639,MERGED,2017-10-30T22:51:12Z,2017-11-04T09:31:11Z,Add a nicer error message for missing in for loop fixes #40782.,LaurentMazare,ed20f3b5c0ae32802450c77da5c94c239c3a3500,2,Remove the redundant span_label.,HEART,2017-10-30T23:33:55Z,estebank,NA https://github.com/rust-lang/rust/pull/45639,MERGED,2017-10-30T22:51:12Z,2017-11-04T09:31:11Z,Add a nicer error message for missing in for loop fixes #40782.,LaurentMazare,ed20f3b5c0ae32802450c77da5c94c239c3a3500,2,Remove the redundant span_label.,HEART,2017-10-31T21:51:19Z,Cldfire,NA https://github.com/rust-lang/rust/pull/45660,MERGED,2017-10-31T17:53:41Z,2017-11-01T09:40:35Z,Suggest renaming import if names clash,Cldfire,61396a8286cde05bea720f5738eb939cc32b8d34,2,Add UI test,HOORAY,2017-10-31T23:02:24Z,estebank,NA https://github.com/rust-lang/rust/pull/45660,MERGED,2017-10-31T17:53:41Z,2017-11-01T09:40:35Z,Suggest renaming import if names clash,Cldfire,61396a8286cde05bea720f5738eb939cc32b8d34,2,Add UI test,HEART,2017-11-01T00:44:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45660,MERGED,2017-10-31T17:53:41Z,2017-11-01T09:40:35Z,Suggest renaming import if names clash,Cldfire,61396a8286cde05bea720f5738eb939cc32b8d34,2,Add UI test,HEART,2017-11-02T23:07:47Z,bluss,NA https://github.com/rust-lang/rust/pull/45660,MERGED,2017-10-31T17:53:41Z,2017-11-01T09:40:35Z,Suggest renaming import if names clash,Cldfire,61396a8286cde05bea720f5738eb939cc32b8d34,2,Add UI test,HEART,2017-11-06T06:44:25Z,behnam,NA https://github.com/rust-lang/rust/pull/45660,MERGED,2017-10-31T17:53:41Z,2017-11-01T09:40:35Z,Suggest renaming import if names clash,Cldfire,61396a8286cde05bea720f5738eb939cc32b8d34,2,Add UI test,HEART,2017-11-08T11:37:22Z,mattgathu,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-01T19:30:26Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-01T19:37:52Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-01T19:39:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-01T19:41:50Z,carols10cents,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-01T22:52:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-02T04:04:59Z,behnam,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-02T06:50:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-02T08:07:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-22T22:04:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45692,MERGED,2017-11-01T19:25:49Z,2017-11-16T03:49:22Z, Start shipping the Cargo book,steveklabnik,3b32a3a104732004ca1b9e40a38221dd1cf3eb7f,2,link the cargo book into the bookshelf,HOORAY,2017-11-23T04:55:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45701,MERGED,2017-11-01T21:43:23Z,2017-11-21T12:33:04Z,impl Trait Lifetime Handling,cramertj,450bbc5f94ab0c015268246bc91324020b7c37fd,1,Clippy is broken,HOORAY,2017-11-01T21:55:57Z,echochamber,NA https://github.com/rust-lang/rust/pull/45701,MERGED,2017-11-01T21:43:23Z,2017-11-21T12:33:04Z,impl Trait Lifetime Handling,cramertj,450bbc5f94ab0c015268246bc91324020b7c37fd,1,Clippy is broken,THUMBS_UP,2017-11-01T21:55:59Z,echochamber,NA https://github.com/rust-lang/rust/pull/45701,MERGED,2017-11-01T21:43:23Z,2017-11-21T12:33:04Z,impl Trait Lifetime Handling,cramertj,450bbc5f94ab0c015268246bc91324020b7c37fd,1,Clippy is broken,HOORAY,2017-11-01T21:56:35Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45701,MERGED,2017-11-01T21:43:23Z,2017-11-21T12:33:04Z,impl Trait Lifetime Handling,cramertj,450bbc5f94ab0c015268246bc91324020b7c37fd,1,Clippy is broken,HOORAY,2017-11-01T23:26:35Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45701,MERGED,2017-11-01T21:43:23Z,2017-11-21T12:33:04Z,impl Trait Lifetime Handling,cramertj,450bbc5f94ab0c015268246bc91324020b7c37fd,1,Clippy is broken,HOORAY,2017-11-03T13:22:14Z,Meralis40,NA https://github.com/rust-lang/rust/pull/45710,MERGED,2017-11-02T02:18:34Z,2017-11-05T06:34:44Z,rustc: Handle some libstd symbole exports better,alexcrichton,fbf98697021173a30b84d9145df0966a23a2f9d2,7,"rustc: Handle some libstd symbole exports better Right now symbol exports particularly in a cdylib are handled by assuming that `pub extern` combined with `#[no_mangle]` means ""export this"". This isn't actually what we want for some symbols that the standard library uses to implement itself for example symbols related to allocation. Additionally other special symbols like `rust_eh_personallity` have no need to be exported from cdylib crate types (only needed in dylib crate types). This commit updates how rustc handles these special symbols by adding to the hardcoded logic of symbols like `rust_eh_personallity` but also adding a new attribute `#[rustc_std_internal_symbol]` which forces the export level to be considered the same as all other Rust functions instead of looking like a C function. The eventual goal here is to prevent functions like `__rdl_alloc` from showing up as part of a Rust cdylib as it's just an internal implementation detail. This then further allows such symbols to get gc'd by the linker when creating a cdylib.",THUMBS_UP,2017-11-10T19:11:19Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/45711,MERGED,2017-11-02T03:59:11Z,2017-11-05T01:41:10Z,Display spans correctly when there are zero-width or wide characters,tirr-c,272c2faa1d766fd4185141106959cdb58b88e6e9,14,Display spans correctly when there are non-half-width characters,THUMBS_UP,2017-11-02T05:20:21Z,est31,NA https://github.com/rust-lang/rust/pull/45711,MERGED,2017-11-02T03:59:11Z,2017-11-05T01:41:10Z,Display spans correctly when there are zero-width or wide characters,tirr-c,272c2faa1d766fd4185141106959cdb58b88e6e9,14,Display spans correctly when there are non-half-width characters,THUMBS_UP,2017-11-02T05:50:20Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45711,MERGED,2017-11-02T03:59:11Z,2017-11-05T01:41:10Z,Display spans correctly when there are zero-width or wide characters,tirr-c,272c2faa1d766fd4185141106959cdb58b88e6e9,14,Display spans correctly when there are non-half-width characters,THUMBS_UP,2017-11-02T16:46:00Z,estebank,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-02T18:49:07Z,kennytm,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-02T19:00:49Z,malbarbo,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-02T20:06:25Z,estebank,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-02T20:50:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-03T04:39:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-03T11:37:35Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HEART,2017-11-04T17:55:16Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-06T03:10:30Z,simnalamburt,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HEART,2017-11-06T03:10:31Z,simnalamburt,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HEART,2017-11-09T10:20:59Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-09T12:02:49Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-15T22:59:38Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45725,MERGED,2017-11-02T18:19:44Z,2017-11-09T20:46:50Z,Working towards a libc-less (wasm32) libstd,alexcrichton,5c3fe111d4a6e72f0461320f5166bcd6aaf2f37f,16,"std: Avoid use of `libc` in portable modules This commit removes usage of the `libc` crate in ""portable"" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.",HOORAY,2017-11-16T14:41:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45735,MERGED,2017-11-03T08:14:06Z,2017-11-08T09:43:43Z,Forbid casting to/from a pointer of unknown kind,tirr-c,99ada043b622fd6186e49b503bc19cb8eec6dcb1,4,Forbid casting to/from a pointer of unknown kind,HEART,2017-11-03T18:14:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45736,MERGED,2017-11-03T08:32:09Z,2017-11-09T06:34:59Z,Use a `Set` instead of a `Map`,oli-obk,2961937a317ac04382c1dbcdccb7f47b3c3acb27,5,Use a `Set` instead of a `Map`,HEART,2017-11-03T13:34:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45736,MERGED,2017-11-03T08:32:09Z,2017-11-09T06:34:59Z,Use a `Set` instead of a `Map`,oli-obk,2961937a317ac04382c1dbcdccb7f47b3c3acb27,5,Use a `Set` instead of a `Map`,HEART,2017-11-15T23:06:53Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45737,MERGED,2017-11-03T12:40:02Z,2017-11-06T15:19:59Z,Pretty print json in ui tests,oli-obk,6d6fb2ef97b81cd5fd39c86b881879d16ecd31c0,2,Adjust json errors to byte changes,THUMBS_UP,2017-11-03T13:57:17Z,killercup,NA https://github.com/rust-lang/rust/pull/45737,MERGED,2017-11-03T12:40:02Z,2017-11-06T15:19:59Z,Pretty print json in ui tests,oli-obk,6d6fb2ef97b81cd5fd39c86b881879d16ecd31c0,2,Adjust json errors to byte changes,THUMBS_UP,2017-11-03T15:12:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/45737,MERGED,2017-11-03T12:40:02Z,2017-11-06T15:19:59Z,Pretty print json in ui tests,oli-obk,6d6fb2ef97b81cd5fd39c86b881879d16ecd31c0,2,Adjust json errors to byte changes,THUMBS_UP,2017-11-03T17:38:07Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45741,MERGED,2017-11-03T15:40:09Z,2017-11-09T18:15:00Z,Refactor internal suggestion API,oli-obk,dfe218ac970f93aa93dc566156c2a54693110208,2,Do not highlight surrounding whitespace,HEART,2017-11-03T17:34:33Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45741,MERGED,2017-11-03T15:40:09Z,2017-11-09T18:15:00Z,Refactor internal suggestion API,oli-obk,dfe218ac970f93aa93dc566156c2a54693110208,2,Do not highlight surrounding whitespace,HEART,2017-11-03T17:39:46Z,killercup,NA https://github.com/rust-lang/rust/pull/45744,MERGED,2017-11-03T17:24:16Z,2017-11-05T04:02:03Z,[beta] ci: Fix broken link in `build-powerpc64le-toolchain.sh` ,kennytm,f065bc521e77d23da43b6ac62277838e0153bb22,1,Change powerpc64le's Centos base URL to vault.centos.org. The previous base URL at mirror.centos.org no longer provides packages for 7.3.1611. It has been moved to vault.centos.org.,THUMBS_UP,2017-11-03T17:28:41Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/45752,MERGED,2017-11-04T02:03:43Z,2018-01-31T10:54:37Z,Highlight code on diagnostics when underlined,estebank,08287c1e26c6faa18c145a8a794fdd25408217a4,8,Toggle span highlighting on `-Zteach`,THUMBS_DOWN,2017-11-05T19:26:30Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45752,MERGED,2017-11-04T02:03:43Z,2018-01-31T10:54:37Z,Highlight code on diagnostics when underlined,estebank,08287c1e26c6faa18c145a8a794fdd25408217a4,8,Toggle span highlighting on `-Zteach`,THUMBS_UP,2017-11-06T09:20:24Z,alexbool,NA https://github.com/rust-lang/rust/pull/45752,MERGED,2017-11-04T02:03:43Z,2018-01-31T10:54:37Z,Highlight code on diagnostics when underlined,estebank,08287c1e26c6faa18c145a8a794fdd25408217a4,8,Toggle span highlighting on `-Zteach`,HEART,2017-11-06T09:20:47Z,alexbool,NA https://github.com/rust-lang/rust/pull/45752,MERGED,2017-11-04T02:03:43Z,2018-01-31T10:54:37Z,Highlight code on diagnostics when underlined,estebank,08287c1e26c6faa18c145a8a794fdd25408217a4,8,Toggle span highlighting on `-Zteach`,THUMBS_UP,2017-11-15T12:48:48Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/45753,MERGED,2017-11-04T02:58:14Z,2017-11-12T18:06:50Z,Fix MIR CopyPropagation errneously propagating assignments to function args,sinkuu,114252410d72b63bda4eefa62df77727d1f1cc41,3,Separately eliminate self-assignments,HOORAY,2017-11-05T16:19:29Z,oyvindln,NA https://github.com/rust-lang/rust/pull/45753,MERGED,2017-11-04T02:58:14Z,2017-11-12T18:06:50Z,Fix MIR CopyPropagation errneously propagating assignments to function args,sinkuu,114252410d72b63bda4eefa62df77727d1f1cc41,3,Separately eliminate self-assignments,HOORAY,2017-11-15T23:19:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45760,CLOSED,2017-11-04T15:13:20Z,2017-11-08T14:41:27Z,Disable backtraces on OSX,alexcrichton,NA,NA,NA,THUMBS_UP,2017-11-08T05:47:03Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/45772,MERGED,2017-11-05T00:03:46Z,2017-11-11T12:13:54Z,Fix checking of auto trait bounds in trait objects.,leoyvens,7995f879d0c520d162d965db0ebbe403bfa2bfda,2,Remove `send` lang item. It's completely unused.,HEART,2017-11-05T00:23:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45772,MERGED,2017-11-05T00:03:46Z,2017-11-11T12:13:54Z,Fix checking of auto trait bounds in trait objects.,leoyvens,7995f879d0c520d162d965db0ebbe403bfa2bfda,2,Remove `send` lang item. It's completely unused.,HEART,2017-11-05T14:48:06Z,Ixrec,NA https://github.com/rust-lang/rust/pull/45772,MERGED,2017-11-05T00:03:46Z,2017-11-11T12:13:54Z,Fix checking of auto trait bounds in trait objects.,leoyvens,7995f879d0c520d162d965db0ebbe403bfa2bfda,2,Remove `send` lang item. It's completely unused.,HEART,2017-11-06T20:43:46Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/45775,MERGED,2017-11-05T01:27:52Z,2017-11-11T18:11:02Z,Accept interpolated patterns in trait method parameters,petrochenkov,f7b4b88840d872909a67e5f9623281e3e2165fba,4,Always report patterns more complex than `mut IDENT` as errors,THUMBS_UP,2017-11-06T17:16:18Z,durka,NA https://github.com/rust-lang/rust/pull/45775,MERGED,2017-11-05T01:27:52Z,2017-11-11T18:11:02Z,Accept interpolated patterns in trait method parameters,petrochenkov,f7b4b88840d872909a67e5f9623281e3e2165fba,4,Always report patterns more complex than `mut IDENT` as errors,THUMBS_UP,2017-11-09T21:49:24Z,jseyfried,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,HEART,2017-11-05T02:33:19Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,HEART,2017-11-05T10:56:12Z,killercup,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-05T15:39:11Z,kennytm,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-05T19:26:13Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T19:01:49Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T19:02:29Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T19:57:47Z,inejge,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T20:01:29Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T20:35:43Z,budziq,budziq@gmail.com https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-13T23:26:27Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-14T00:05:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-14T00:38:19Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-14T02:41:10Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,HEART,2017-11-14T02:41:15Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-14T06:20:02Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-15T08:21:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,CONFUSED,2017-11-15T12:48:42Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-18T09:54:46Z,bjorn3,NA https://github.com/rust-lang/rust/pull/45776,CLOSED,2017-11-05T01:34:01Z,2017-11-29T11:03:37Z,Highlight code on diagnostics when underlined,estebank,NA,NA,NA,THUMBS_UP,2017-11-19T20:15:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/45784,MERGED,2017-11-05T17:48:01Z,2017-11-07T20:55:21Z,Pretty print parens around casts on the LHS of `<`/`<<`,harpocrates,aa38a1ee5092fb81e23b0cbd215535de08ae7b28,1,Update comments in cast-lt.pp,THUMBS_UP,2017-11-05T17:55:24Z,kennytm,NA https://github.com/rust-lang/rust/pull/45784,MERGED,2017-11-05T17:48:01Z,2017-11-07T20:55:21Z,Pretty print parens around casts on the LHS of `<`/`<<`,harpocrates,aa38a1ee5092fb81e23b0cbd215535de08ae7b28,1,Update comments in cast-lt.pp,THUMBS_UP,2017-11-06T17:22:55Z,estebank,NA https://github.com/rust-lang/rust/pull/45810,MERGED,2017-11-06T18:00:50Z,2017-11-13T14:20:21Z,"Disable LLVM assertions on Nightly enable them in ""alt"" builds.",SimonSapin,7625c79f2a8947388012d0636cac914c47771eff,1,Do not silence output in run-make/sanitizer-memory,THUMBS_UP,2017-11-06T22:20:24Z,est31,NA https://github.com/rust-lang/rust/pull/45810,MERGED,2017-11-06T18:00:50Z,2017-11-13T14:20:21Z,"Disable LLVM assertions on Nightly enable them in ""alt"" builds.",SimonSapin,7625c79f2a8947388012d0636cac914c47771eff,1,Do not silence output in run-make/sanitizer-memory,THUMBS_UP,2017-11-13T14:31:35Z,delacian,NA https://github.com/rust-lang/rust/pull/45815,MERGED,2017-11-06T21:17:17Z,2017-11-14T18:47:45Z,rustdoc: tweak notes on ignore/compile_fail examples,QuietMisdreavus,02b3785f844d5c430484497d097482828eba264d,1,update codeblock-title test with new notice text,THUMBS_UP,2017-11-07T02:16:43Z,kennytm,NA https://github.com/rust-lang/rust/pull/45815,MERGED,2017-11-06T21:17:17Z,2017-11-14T18:47:45Z,rustdoc: tweak notes on ignore/compile_fail examples,QuietMisdreavus,02b3785f844d5c430484497d097482828eba264d,1,update codeblock-title test with new notice text,THUMBS_UP,2017-11-07T17:44:54Z,bluss,NA https://github.com/rust-lang/rust/pull/45820,CLOSED,2017-11-07T03:05:59Z,2017-11-08T13:01:46Z,Correctly format `extern crate` conflict resolution help,Cldfire,NA,NA,NA,HEART,2017-11-07T04:53:47Z,estebank,NA https://github.com/rust-lang/rust/pull/45820,CLOSED,2017-11-07T03:05:59Z,2017-11-08T13:01:46Z,Correctly format `extern crate` conflict resolution help,Cldfire,NA,NA,NA,HEART,2017-11-07T10:15:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45821,MERGED,2017-11-07T07:27:02Z,2017-11-14T21:20:49Z,always add an unreachable branch on matches to give more info to llvm,djzin,5b1cc1d81024a28b77d40a33b49b2d396a120b69,1,don't send block back to be marked unreachable twice,THUMBS_UP,2017-11-22T17:33:34Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45821,MERGED,2017-11-07T07:27:02Z,2017-11-14T21:20:49Z,always add an unreachable branch on matches to give more info to llvm,djzin,5b1cc1d81024a28b77d40a33b49b2d396a120b69,1,don't send block back to be marked unreachable twice,HOORAY,2018-01-31T04:14:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45825,MERGED,2017-11-07T10:55:58Z,2017-11-16T23:28:04Z,integrate MIR type-checker with NLL inference,nikomatsakis,8c109f5681c08ed70f85926a2a18f8ed98fef77c,1,infer/outlives/obligations.rs: wrap some long lines,HOORAY,2017-11-07T16:32:27Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45825,MERGED,2017-11-07T10:55:58Z,2017-11-16T23:28:04Z,integrate MIR type-checker with NLL inference,nikomatsakis,8c109f5681c08ed70f85926a2a18f8ed98fef77c,1,infer/outlives/obligations.rs: wrap some long lines,HOORAY,2017-11-08T19:48:30Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45825,MERGED,2017-11-07T10:55:58Z,2017-11-16T23:28:04Z,integrate MIR type-checker with NLL inference,nikomatsakis,8c109f5681c08ed70f85926a2a18f8ed98fef77c,1,infer/outlives/obligations.rs: wrap some long lines,HOORAY,2017-11-23T07:15:44Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/45833,CLOSED,2017-11-07T15:24:39Z,2017-11-14T06:27:28Z,Add `Iterator::enumerate_from(self first: usize)`,SimonSapin,NA,NA,NA,CONFUSED,2017-11-07T16:35:37Z,kennytm,NA https://github.com/rust-lang/rust/pull/45833,CLOSED,2017-11-07T15:24:39Z,2017-11-14T06:27:28Z,Add `Iterator::enumerate_from(self first: usize)`,SimonSapin,NA,NA,NA,CONFUSED,2017-11-07T23:19:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-11-07T16:51:19Z,jminer,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-11-07T16:52:29Z,jminer,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-11-07T17:20:40Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-11-07T21:36:38Z,killercup,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-11-10T06:11:34Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-08T18:54:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-12-08T18:54:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-08T21:04:28Z,estebank,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-09T01:21:42Z,Ralith,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-11T03:26:30Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-13T00:33:12Z,michaelfairley,michael@michaelfairley.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-12-13T00:54:52Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-12-13T02:31:26Z,lilydjwg,lilydjwg@gmail.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-13T10:59:47Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-13T14:54:21Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2017-12-15T02:27:47Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2017-12-19T15:51:23Z,stephanbuys,hello@stephanbuys.com https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2018-03-23T20:00:11Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,THUMBS_UP,2018-03-23T20:00:12Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/45837,MERGED,2017-11-07T16:43:24Z,2017-12-09T00:09:31Z,Add read read_string and write functions to std::fs,SimonSapin,c5eff5442ca963e20225c8229aff7be28f65a0a6,1,fs::{read read_string write}: add tracking issue number,HEART,2018-04-22T04:47:22Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-11-07T21:51:44Z,cramertj,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-11-08T19:29:01Z,retep998,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-11-29T19:33:42Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-01T12:21:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-02T14:11:44Z,elegaanz,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-04T09:08:56Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-05T06:05:06Z,elpiel,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T10:08:20Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T11:56:53Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T12:28:44Z,chpio,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T14:29:11Z,kgv,NA https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T16:55:22Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/45846,MERGED,2017-11-07T20:52:06Z,2017-12-01T06:06:06Z,Add nested groups in imports,pietroalbini,f7f69512c8741e81714252d481a4cf6936f2c65f,1,Mark rustfmt and rls as broken,HOORAY,2017-12-06T18:47:46Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/45848,MERGED,2017-11-07T21:44:27Z,2017-11-12T04:15:12Z,save-analysis: two fixes + rustfmt,nrc,b98290cb1f1cb22abda0dd97567d9aad95ae3078,5,save-analysis: run rustfmt,THUMBS_UP,2017-11-07T22:05:24Z,DSpeckhals,NA https://github.com/rust-lang/rust/pull/45849,MERGED,2017-11-07T21:46:11Z,2017-11-08T12:23:56Z,"Add ""-"" shortcut",GuillaumeGomez,5e116985ebbb23fa6891b7d9fe20bbd895093094,3,"Add ""-"" shortcut",THUMBS_UP,2017-11-07T21:54:14Z,raggi,jftucker@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-08T13:30:42Z,zorgiepoo,NA https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,HOORAY,2017-11-08T19:21:38Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,HOORAY,2017-11-08T19:25:19Z,estebank,NA https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,HOORAY,2017-11-08T19:56:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-08T19:56:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-10T06:09:27Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-10T12:32:07Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-10T16:05:44Z,Enet4,NA https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-15T15:47:09Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-15T18:23:48Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-15T22:00:01Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,HOORAY,2017-11-16T08:24:10Z,la10736,michele.damico@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-16T15:06:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45863,MERGED,2017-11-08T09:31:28Z,2017-11-10T11:37:32Z,Add `Option::filter()` according to RFC 2124,LukasKalbertodt,e65214441dd9b6ec4eff3821d988818ecb53abf6,1,Add `Option::filter()` according to RFC 2124,THUMBS_UP,2017-11-17T08:09:40Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/45867,MERGED,2017-11-08T11:27:55Z,2017-11-09T00:51:12Z,incr.comp.: Verify stability of incr. comp. hashes and clean up various other things.,michaelwoerister,d01b89b94827f7d818397d8b4654e93306219ec0,3,incr.comp.: Provide session to some more decoding contexts.,HEART,2017-11-08T13:31:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45867,MERGED,2017-11-08T11:27:55Z,2017-11-09T00:51:12Z,incr.comp.: Verify stability of incr. comp. hashes and clean up various other things.,michaelwoerister,d01b89b94827f7d818397d8b4654e93306219ec0,3,incr.comp.: Provide session to some more decoding contexts.,HEART,2017-11-15T20:22:09Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45867,MERGED,2017-11-08T11:27:55Z,2017-11-09T00:51:12Z,incr.comp.: Verify stability of incr. comp. hashes and clean up various other things.,michaelwoerister,d01b89b94827f7d818397d8b4654e93306219ec0,3,incr.comp.: Provide session to some more decoding contexts.,THUMBS_UP,2017-11-16T15:01:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45870,MERGED,2017-11-08T14:26:13Z,2017-11-12T09:46:13Z,Implement arbitrary_self_types,mikeyhew,77cd993fd1582680cc01ce86d07e52b2e4b34fec,4,add run-pass tests,HOORAY,2017-11-17T11:40:29Z,brendanzab,NA https://github.com/rust-lang/rust/pull/45887,MERGED,2017-11-09T11:40:00Z,2017-11-10T11:37:35Z,Allow a trailling comma in assert_eq/ne macro,xfix,6a92c0fdbddbda6fcb0c6215f64240d228e4b2f5,5,Allow a trailing comma in assert_eq/ne macro,HOORAY,2017-11-10T22:10:06Z,Screwtapello,NA https://github.com/rust-lang/rust/pull/45897,MERGED,2017-11-09T21:37:23Z,2017-11-17T01:57:26Z,Trait object debug,tromey,ae4cc6069626206b493caf6b1158d3d5d601bbc7,5,Emit debug info for trait object pointer Emit better debugging information for a trait object pointer. In particular now: * The fields are explicitly represented in the DWARF; * DWARF for the vtable itself is emitted; and * The DWARF for the vtable's type has a DW_AT_containing_type which points to the concrete type for which the vtable was emitted. This is a small DWARF extension that allows debuggers to determine the real type of the object to which a trait object points. I'll submit the gdb patch to take advantage of this new debuginfo once this lands. The vtable type is not currently complete -- it doesn't include members for the pointers it contains. This information was not needed for this feature. This addresses part 1 of #1563.,THUMBS_UP,2017-11-22T18:17:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45900,MERGED,2017-11-09T23:33:49Z,2017-11-12T12:19:29Z,Make saturating u128 -> f32 casts the default behavior,hanna-kruppe,59524410a7eb3c6afe3ac01b4257d916efe2421b,5,Make saturating u128 -> f32 casts the default behavior ... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799,THUMBS_UP,2017-11-09T23:51:30Z,est31,NA https://github.com/rust-lang/rust/pull/45900,MERGED,2017-11-09T23:33:49Z,2017-11-12T12:19:29Z,Make saturating u128 -> f32 casts the default behavior,hanna-kruppe,59524410a7eb3c6afe3ac01b4257d916efe2421b,5,Make saturating u128 -> f32 casts the default behavior ... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799,THUMBS_UP,2017-11-10T00:09:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45900,MERGED,2017-11-09T23:33:49Z,2017-11-12T12:19:29Z,Make saturating u128 -> f32 casts the default behavior,hanna-kruppe,59524410a7eb3c6afe3ac01b4257d916efe2421b,5,Make saturating u128 -> f32 casts the default behavior ... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799,THUMBS_UP,2017-11-10T00:43:28Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-11-11T07:41:26Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-11-11T10:16:14Z,sinkuu,NA https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-11-12T00:29:02Z,FaultyRAM,NA https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-11-12T03:41:08Z,kyren,kyren@kyju.org https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-11-12T14:21:45Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/45903,MERGED,2017-11-10T02:11:27Z,2017-11-13T23:36:15Z,Distribute Rustfmt,nrc,97d21e29df0ff67bd25fe563a87f5f387d291e5f,2,review changes,HOORAY,2017-12-25T17:38:15Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-10T09:06:42Z,killercup,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-10T10:12:08Z,cramertj,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-10T14:07:42Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-10T21:15:32Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-10T21:15:33Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-11T04:48:49Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-11-12T14:34:27Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-12-06T11:02:57Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2017-12-07T10:56:20Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,THUMBS_UP,2017-12-12T14:41:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HEART,2018-06-12T13:46:13Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2018-08-01T23:34:31Z,estebank,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2020-07-13T23:57:33Z,Dherse,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2021-08-03T20:34:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2021-08-04T10:07:42Z,fwcd,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,THUMBS_UP,2021-08-06T14:00:24Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HOORAY,2021-08-06T14:00:24Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/45904,MERGED,2017-11-10T04:08:52Z,2017-12-02T02:56:18Z,Generic Associated Types Parsing & Name Resolution,sunjay,9d5592b4364a7492222583a85c2d5f10cac786ad,1,Updated generic-associated-types-where stderr,HEART,2021-08-06T14:00:25Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T10:07:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T10:47:58Z,malbarbo,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T10:48:01Z,malbarbo,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T12:16:29Z,est31,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T12:16:29Z,est31,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T12:16:32Z,est31,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T12:30:38Z,yurtaev,yurtaev.egor+github@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T12:31:16Z,chpio,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T12:31:17Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T12:36:38Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T12:44:11Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T13:07:49Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T13:22:14Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T13:25:10Z,fckt,alexey@fckt.dev https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T13:25:14Z,fckt,alexey@fckt.dev https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T13:33:21Z,NikVolf,nikvolf@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T13:38:13Z,bjornwgnr,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T13:50:37Z,tlively,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T14:21:37Z,snd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T14:42:33Z,yamafaktory,yamafaktory@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T14:42:50Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T14:42:51Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T14:42:52Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T14:43:00Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T14:50:12Z,jsheard,mail@jsheard.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T14:59:11Z,krdln,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T15:02:46Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:02:46Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:02:53Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T15:12:50Z,arashm,mousavi.arash@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:12:57Z,usamec,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:13:06Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-10T15:21:21Z,pvdrz,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:21:26Z,pvdrz,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:22:19Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:22:31Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:25:19Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:29:30Z,anderejd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:29:35Z,anderejd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T15:32:16Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:33:04Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:37:04Z,repax,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:37:25Z,delacian,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T15:37:38Z,guybrush,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:40:48Z,chrish42,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:42:07Z,rajsite,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:49:08Z,rbalicki2,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T15:49:12Z,rbalicki2,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:52:44Z,azdle,patrick@psbarrett.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:52:54Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:52:57Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T15:55:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:55:08Z,djc,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T15:55:33Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:01:06Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T16:01:15Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:01:18Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:01:48Z,Havvy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T16:01:49Z,Havvy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:01:49Z,Havvy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:03:14Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:10:51Z,killercup,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:10:51Z,ssokolow,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:15:22Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:15:23Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T16:15:24Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:26:22Z,mawaldne-surge,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:41:26Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:43:38Z,grigio,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T16:47:31Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:47:33Z,brunobertoldi,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T16:51:39Z,UtherII,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T16:58:12Z,derekdreery,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T17:02:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:02:42Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:04:34Z,jntrnr,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:15:37Z,bIgBV,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:17:09Z,jmacdonald,jordan@wastedintelligence.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:27:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T17:35:19Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:35:20Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T17:36:14Z,bjfish,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T17:50:06Z,mihails-strasuns,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T17:51:34Z,seppo0010,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T17:51:35Z,seppo0010,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T17:59:23Z,jsonnull,jsonnull@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:00:12Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T18:00:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T18:00:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:04:34Z,flosse,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T18:04:37Z,flosse,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T18:04:38Z,flosse,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-10T18:04:40Z,flosse,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:07:08Z,Virtlink,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T18:23:44Z,kainino0x,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:25:24Z,17cupsofcoffee,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:26:15Z,khoerling,keith@hoerling.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T18:29:49Z,tomasdev,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:35:02Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:44:25Z,skariel,skariel@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T18:48:11Z,ofek,oss@ofek.dev https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T18:57:32Z,eholk,eric@theincredibleholk.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T19:05:52Z,Ryman,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T19:23:22Z,topaxi,damian.senn@topaxi.codes https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T19:23:22Z,topaxi,damian.senn@topaxi.codes https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T19:23:23Z,topaxi,damian.senn@topaxi.codes https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T19:25:22Z,jminer,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T19:25:25Z,jminer,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T19:37:51Z,tomhoule,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T19:37:52Z,tomhoule,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T19:37:54Z,tomhoule,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T19:46:19Z,lukas-lansky,lukas@lansky.name https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T19:55:33Z,thiagopnts,ping@thi.ag https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T19:55:34Z,thiagopnts,ping@thi.ag https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T19:55:36Z,thiagopnts,ping@thi.ag https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T20:21:39Z,eminence,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T20:36:57Z,syxolk,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T20:38:05Z,justSQL,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T20:38:07Z,justSQL,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T20:38:09Z,justSQL,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T20:43:18Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T20:44:18Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T20:52:00Z,0b01,github@rickyhan.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T20:52:04Z,0b01,github@rickyhan.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T20:59:34Z,kevinji,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:03:50Z,neoneye,simon@iroots.dk https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T21:07:01Z,lqd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T21:07:02Z,lqd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:07:03Z,lqd,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:15:14Z,IntrepidPig,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:21:04Z,discosultan,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-10T21:21:04Z,discosultan,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T21:21:05Z,discosultan,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T21:21:05Z,discosultan,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:23:07Z,cheme,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T21:43:15Z,bb010g,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:46:08Z,dmacewen,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T21:59:56Z,sethlopezme,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T21:59:58Z,sethlopezme,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T21:59:59Z,sethlopezme,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T22:04:15Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T22:04:16Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T22:25:51Z,bachp,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T22:26:24Z,danthedaniel,me@danangell.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T22:26:45Z,benceszigeti,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T22:29:01Z,lalcmellkmal,lalc@doushio.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T22:50:32Z,blakev,blakev@null.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T22:52:55Z,19870213,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-10T23:01:03Z,estebank,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-10T23:17:03Z,bigcity,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-10T23:46:42Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T00:03:37Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T00:03:39Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T00:03:40Z,jld,jld@xlerb.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T00:04:04Z,keeslinp,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T00:24:02Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T00:34:00Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T00:34:00Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T01:12:55Z,Timidger,APragmaticPlace@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T01:12:58Z,Timidger,APragmaticPlace@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T01:45:20Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T03:14:30Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T03:14:31Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T03:14:31Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-11T03:14:34Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T03:22:01Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T03:22:02Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T04:40:58Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T04:51:33Z,huwsun,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T05:29:33Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T05:57:33Z,DeerOfBlades,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T06:38:47Z,antifuchs,asf@boinkor.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T06:38:48Z,antifuchs,asf@boinkor.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T07:39:36Z,stoand,stoand@protonmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T08:32:44Z,fulmicoton,paul.masurel@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T08:32:46Z,fulmicoton,paul.masurel@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T08:57:07Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T08:57:10Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T09:31:15Z,DavidBM,bonet@hey.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T10:59:21Z,JJJollyjim,jamie@kwiius.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T11:31:11Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T12:04:31Z,chpio,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T12:28:12Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T14:33:22Z,tAq5Z6eE,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T14:54:33Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-11T14:54:33Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T14:54:34Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T14:54:35Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T15:05:19Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T15:05:20Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T15:20:27Z,shritesh,shr@ite.sh https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T16:17:36Z,xen0n,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T16:35:12Z,kimwalisch,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T16:41:24Z,johncf,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T16:41:24Z,johncf,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T16:51:13Z,taivare,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T16:51:30Z,taivare,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T18:13:36Z,xilec,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T18:13:37Z,xilec,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T18:56:16Z,vinc,v@vinc.cc https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T19:01:42Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-11T19:01:43Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-11T19:01:45Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T19:07:26Z,trox667,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-11T23:19:37Z,wmsbill,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T01:03:09Z,sercand,sercan@otsimo.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-12T01:03:10Z,sercand,sercan@otsimo.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T04:26:35Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-12T08:24:25Z,heyLu,lu@papill0n.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T11:37:17Z,awalgarg,awalgarg@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T15:02:56Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T15:51:09Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T22:09:16Z,justinrlle,justinrlle@pm.me https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-12T23:45:17Z,passy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-12T23:45:20Z,passy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-12T23:45:21Z,passy,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-13T00:55:33Z,plietar,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-13T00:55:33Z,plietar,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-13T00:55:35Z,plietar,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-13T09:26:50Z,Meralis40,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-14T00:31:03Z,maksimsco,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-14T08:16:50Z,dmitrika,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-14T12:57:13Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-14T15:21:37Z,paulopaquielli,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-14T22:18:19Z,machineloop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-14T22:18:22Z,machineloop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-14T23:25:40Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-14T23:26:22Z,mbebenita,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-14T23:26:23Z,mbebenita,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-14T23:26:23Z,mbebenita,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-15T09:47:55Z,minecrawler,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T11:07:19Z,Racum,ronaldo@racum.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-15T11:07:24Z,Racum,ronaldo@racum.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T12:16:17Z,dirvine,david.irvine@maidsafe.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-15T12:16:18Z,dirvine,david.irvine@maidsafe.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T12:38:45Z,tobbbles,hi@tobbbl.es https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T14:01:56Z,akmittal,mittalmailbox@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T17:29:55Z,Type1J,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-15T22:15:02Z,mbebenita,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-16T01:35:58Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-16T18:15:53Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-16T18:15:54Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-16T18:15:57Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-16T21:24:34Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-16T21:24:36Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-16T21:24:36Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-17T06:52:56Z,fusepilot,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-18T07:18:59Z,zolkko,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-18T08:29:24Z,M-Adoo,Adoo@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-18T10:59:31Z,buttwize,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-18T10:59:32Z,buttwize,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-18T10:59:36Z,buttwize,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-18T12:59:26Z,vinc,v@vinc.cc https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-19T17:06:14Z,Ljzn,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-19T22:55:05Z,lemmabit,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T11:12:24Z,donaldpipowitch,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T11:28:22Z,salty-horse,ori@avtalion.name https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T12:57:22Z,yanns,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T13:12:14Z,emoon,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T13:29:21Z,sdeleuze,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-20T13:30:42Z,sdeleuze,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T13:53:40Z,sokra,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T14:55:19Z,niklasad1,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T15:25:52Z,djm,mail@djm.org.uk https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T15:51:07Z,felixgirault,felix.girault@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T17:33:07Z,jmar777,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-20T17:33:10Z,jmar777,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T17:33:11Z,jmar777,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-20T17:33:12Z,jmar777,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-20T17:50:58Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T17:56:25Z,junyi,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T17:56:26Z,junyi,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T18:52:24Z,stephank,git@stephank.nl https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T19:52:00Z,choubacha,chewbacha@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T20:41:43Z,TimvanScherpenzeel,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-20T22:04:13Z,Boscop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-20T22:04:16Z,Boscop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-20T22:04:17Z,Boscop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-20T22:04:18Z,Boscop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-21T11:57:20Z,northerner,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-22T19:57:13Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-22T19:57:14Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-22T21:39:31Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-23T04:59:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-23T09:12:47Z,LeanderK,Leander.Kurscheidt@gmx.de https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-23T11:24:16Z,gngeorgiev,gngeorgiev.it@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2017-11-23T11:24:18Z,gngeorgiev,gngeorgiev.it@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-23T11:24:19Z,gngeorgiev,gngeorgiev.it@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-23T11:24:19Z,gngeorgiev,gngeorgiev.it@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-23T14:33:17Z,gabdube,gdube.475@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-24T21:45:20Z,kazcw,keziahw@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-25T08:36:52Z,fdb,frederik@debleser.be https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-26T15:03:11Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-26T15:52:21Z,lilydjwg,lilydjwg@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-26T15:52:22Z,lilydjwg,lilydjwg@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-26T18:14:30Z,danpaz,daniel.pazsoldan@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-27T02:19:31Z,uuhan,xuminhui189@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-11-27T06:41:13Z,Dessix,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-27T06:41:18Z,Dessix,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-11-27T06:41:20Z,Dessix,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-11-29T07:38:12Z,demaggus83,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-12-02T15:01:10Z,mklcp,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-02T15:01:12Z,mklcp,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-03T15:20:25Z,sderosiaux,sderosiaux@conduktor.io https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-04T04:22:58Z,glin,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-04T14:57:28Z,vladsm,vladsm@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-04T14:57:50Z,vladsm,vladsm@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-04T16:14:50Z,haikyuu,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-04T16:50:36Z,andreimc,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-04T17:33:16Z,ajnsit,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-04T17:33:21Z,ajnsit,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-05T19:52:23Z,davidrapin,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-06T18:00:13Z,shivjm,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-08T23:55:48Z,amellnik,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-09T02:26:10Z,wrmsr,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-11T02:34:36Z,sunjay,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-12T19:10:47Z,limitee,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-18T05:41:40Z,YoungLeeNENU,youngleemails@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-18T16:41:57Z,PerfectLaugh,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-18T16:42:02Z,PerfectLaugh,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-20T03:30:29Z,albizures,jose@albizures.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2017-12-24T07:05:00Z,Seadragon91,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2017-12-26T14:45:22Z,machineloop,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2017-12-29T22:23:15Z,cptaffe,cpaynetaffe@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-01-02T08:56:15Z,yangsibai,yangsibai@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-01-25T23:19:06Z,korya,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-02-05T06:45:07Z,xeqlol,xeqlol@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2018-02-05T06:45:09Z,xeqlol,xeqlol@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-02-12T23:23:18Z,patricktailor,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2018-04-01T22:19:25Z,johnthagen,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-05-08T15:12:08Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2018-05-08T15:12:12Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2018-07-17T12:47:05Z,r00ster91,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2018-07-17T12:47:06Z,r00ster91,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2018-07-17T12:47:07Z,r00ster91,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-07-17T12:47:08Z,r00ster91,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-09-07T07:49:09Z,efugier,mail@emilienfugier.net https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2018-12-18T03:13:29Z,joeyespo,joeyespo@gmail.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2019-09-16T18:30:58Z,jedmao,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2019-09-16T18:30:59Z,jedmao,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2019-09-16T18:31:00Z,jedmao,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",LAUGH,2019-09-16T18:31:01Z,jedmao,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2020-05-23T20:46:54Z,nasso,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HEART,2020-05-23T20:46:55Z,nasso,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",HOORAY,2020-05-23T20:46:55Z,nasso,NA https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2021-02-10T09:28:46Z,zlliang,zlliang96@outlook.com https://github.com/rust-lang/rust/pull/45905,MERGED,2017-11-10T09:01:06Z,2017-11-20T11:00:13Z,std: Add a new wasm32-unknown-unknown target,alexcrichton,80ff0f74b0c4a8d384160af81a1b21f53622d8af,162,"std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a ""custom linker"" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error but anything related to allocation works (aka `HashMap` `Vec` etc). * Naturally any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The ""linking"" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's ""production ready"". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the ""smallest possible wasm module"" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final ""bloat"" in vanilla rustc (again a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this particularly on the various integration points if you've got better ideas of how to approach them!",THUMBS_UP,2021-06-23T08:34:42Z,wong2,wonderfuly@gmail.com https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-10T19:07:10Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-10T19:11:54Z,cramertj,NA https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-10T19:22:42Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-10T19:38:15Z,lqd,NA https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-11T04:44:47Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-13T09:10:09Z,alexbool,NA https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-15T22:04:29Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-16T03:11:21Z,KeenS,NA https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-22T09:42:54Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-22T12:55:44Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-22T19:31:52Z,TheNeikos,neikos@neikos.email https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-22T22:40:06Z,RobertWHurst,robertwhurst@gmail.com https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-23T06:01:22Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-23T16:15:35Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-24T08:06:47Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/45918,MERGED,2017-11-10T18:58:42Z,2017-11-16T01:17:06Z,Implement `impl Trait` in argument position (RFC1951 Universal quantification),chrisvittal,4ce61b73620ade330bbafc3c6d56a0447bac2ca3,1,Change clippy to broken after hir::Ty enum change,HOORAY,2017-11-27T09:00:59Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2017-11-10T20:41:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2017-11-10T20:48:51Z,zackw,NA https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2017-11-10T20:55:23Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2017-11-14T20:36:13Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2017-11-22T17:39:47Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2017-11-22T18:18:26Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2017-11-23T04:42:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2017-11-30T20:44:44Z,bluss,NA https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2017-12-03T03:21:15Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2017-12-28T10:04:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2020-06-01T07:28:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2021-03-25T07:34:50Z,IceCodeNew,NA https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,HEART,2021-03-25T07:35:21Z,IceCodeNew,NA https://github.com/rust-lang/rust/pull/45920,MERGED,2017-11-10T20:00:30Z,2017-11-16T08:32:11Z,Enable TrapUnreachable in LLVM.,sunfishcode,ac48348db85d0ce9efdc450ab52837dcfc42a932,1,Update the compiler-builtins to latest master.,THUMBS_UP,2022-06-10T18:07:14Z,phase,j@jadon.io https://github.com/rust-lang/rust/pull/45928,CLOSED,2017-11-11T09:51:26Z,2018-01-10T06:05:00Z,Add Read::size_hint and pre-allocate in read_to_end,SimonSapin,NA,NA,NA,THUMBS_UP,2018-01-03T21:29:20Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2017-12-01T19:05:23Z,flip111,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2017-12-01T19:19:11Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2017-12-19T02:31:40Z,Librazy,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2017-12-20T18:39:31Z,Limeth,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2019-07-15T21:34:44Z,hameerabbasi,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2019-10-14T16:26:46Z,Kylebrown9,NA https://github.com/rust-lang/rust/pull/45930,MERGED,2017-11-11T12:14:06Z,2017-12-21T23:01:28Z,Generics refactoring (groundwork for const generics),jplatte,78493ed21aaeb20a8d5f7bd08f26c0c9fd496ed4,51,Add GenericParam refactor Generics in ast hir rustdoc The Generics now contain one Vec of an enum for the generic parameters rather than two separate Vec's for lifetime and type parameters. Additionally places that previously used Vec now use Vec instead.,HOORAY,2020-01-22T11:27:09Z,sshanzel,NA https://github.com/rust-lang/rust/pull/45942,MERGED,2017-11-12T12:21:48Z,2017-11-24T04:03:39Z,Add hints for the case of confusing enum with its variants,Menschenkindlein,a3686c685a10de7b56cacf998a9e7eabc622787b,1,Use for_each_child_stable in find_module,HOORAY,2017-11-12T21:26:29Z,estebank,NA https://github.com/rust-lang/rust/pull/45942,MERGED,2017-11-12T12:21:48Z,2017-11-24T04:03:39Z,Add hints for the case of confusing enum with its variants,Menschenkindlein,a3686c685a10de7b56cacf998a9e7eabc622787b,1,Use for_each_child_stable in find_module,HOORAY,2017-11-13T04:11:40Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/45942,MERGED,2017-11-12T12:21:48Z,2017-11-24T04:03:39Z,Add hints for the case of confusing enum with its variants,Menschenkindlein,a3686c685a10de7b56cacf998a9e7eabc622787b,1,Use for_each_child_stable in find_module,HOORAY,2017-11-15T23:29:15Z,Ixrec,NA https://github.com/rust-lang/rust/pull/45942,MERGED,2017-11-12T12:21:48Z,2017-11-24T04:03:39Z,Add hints for the case of confusing enum with its variants,Menschenkindlein,a3686c685a10de7b56cacf998a9e7eabc622787b,1,Use for_each_child_stable in find_module,HOORAY,2017-11-24T06:50:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/45944,MERGED,2017-11-12T16:32:11Z,2017-11-15T10:32:33Z,rustc_driver: expose a way to override query providers in CompileController.,eddyb,0ac6c3aacbf70d24a5e13b648e650dffec699952,3,rustc_driver: expose a way to override query providers in CompileController.,HOORAY,2017-11-22T14:17:57Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/45946,MERGED,2017-11-12T21:44:34Z,2017-11-24T06:29:34Z,Use multiline text for crate conflict diagnostics,estebank,5eb5e91d7b483edc903ca9c35bdd925d578f45e7,10,Use multiline text for crate conflict diagnostics,CONFUSED,2017-11-13T08:56:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/45946,MERGED,2017-11-12T21:44:34Z,2017-11-24T06:29:34Z,Use multiline text for crate conflict diagnostics,estebank,5eb5e91d7b483edc903ca9c35bdd925d578f45e7,10,Use multiline text for crate conflict diagnostics,THUMBS_UP,2017-11-13T15:54:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/45953,MERGED,2017-11-13T06:09:50Z,2017-12-06T23:42:20Z,Display `\t` in diagnostics code as four spaces,estebank,9d80e2200af22bb4532a7cc4738b22e408072ffd,5,Display `\t` in diagnostics code as four spaces,HEART,2017-11-13T06:46:23Z,tirr-c,chwo9843@gmail.com https://github.com/rust-lang/rust/pull/45953,MERGED,2017-11-13T06:09:50Z,2017-12-06T23:42:20Z,Display `\t` in diagnostics code as four spaces,estebank,9d80e2200af22bb4532a7cc4738b22e408072ffd,5,Display `\t` in diagnostics code as four spaces,HEART,2017-11-13T06:58:08Z,est31,NA https://github.com/rust-lang/rust/pull/45958,CLOSED,2017-11-13T13:59:37Z,2017-12-01T18:28:27Z,Port shell script to POSIX sh,dereckson,NA,NA,NA,THUMBS_UP,2017-11-15T23:06:08Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/45961,MERGED,2017-11-13T14:36:02Z,2017-11-14T18:47:51Z,Use #!/usr/bin/env as shebang for Bash scripts,dereckson,de8c57cb24da2685f06e80103936456a883ff203,39,Use #!/usr/bin/env as shebang for Bash scripts On some systems the bash command could be available in another directory than /bin. As such to offer an env shebang is more convenient. This make sense even for docker scripts as you can use Docker on FreeBSD or SmartOS for example.,THUMBS_UP,2017-11-13T16:27:17Z,est31,NA https://github.com/rust-lang/rust/pull/45973,MERGED,2017-11-13T23:35:14Z,2017-11-16T20:56:19Z,avoid the pprust infrastructure in macro expansion,arielb1,824b307ff7e3e93f2a5d0d864e9161c3db12acfc,1,"avoid the pprust infrastructure in macro expansion This changes macro expansion to format the path of a macro directly instead of usng the pprust infrastructure. The pprust infrastructure tries to perform line-breaking in a slow fashion which is undesired when formatting the path of a macro. This should to speed up expansion by a fair amount (I saw 20% on a profiler on `rustc_mir` and 50% of the time marked as ""expansion"" in the profiler/time-passes is actually spent loading dependencies).",HEART,2017-11-13T23:36:36Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/45973,MERGED,2017-11-13T23:35:14Z,2017-11-16T20:56:19Z,avoid the pprust infrastructure in macro expansion,arielb1,824b307ff7e3e93f2a5d0d864e9161c3db12acfc,1,"avoid the pprust infrastructure in macro expansion This changes macro expansion to format the path of a macro directly instead of usng the pprust infrastructure. The pprust infrastructure tries to perform line-breaking in a slow fashion which is undesired when formatting the path of a macro. This should to speed up expansion by a fair amount (I saw 20% on a profiler on `rustc_mir` and 50% of the time marked as ""expansion"" in the profiler/time-passes is actually spent loading dependencies).",HEART,2017-11-13T23:56:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/45973,MERGED,2017-11-13T23:35:14Z,2017-11-16T20:56:19Z,avoid the pprust infrastructure in macro expansion,arielb1,824b307ff7e3e93f2a5d0d864e9161c3db12acfc,1,"avoid the pprust infrastructure in macro expansion This changes macro expansion to format the path of a macro directly instead of usng the pprust infrastructure. The pprust infrastructure tries to perform line-breaking in a slow fashion which is undesired when formatting the path of a macro. This should to speed up expansion by a fair amount (I saw 20% on a profiler on `rustc_mir` and 50% of the time marked as ""expansion"" in the profiler/time-passes is actually spent loading dependencies).",HEART,2017-11-14T21:48:10Z,estebank,NA https://github.com/rust-lang/rust/pull/45973,MERGED,2017-11-13T23:35:14Z,2017-11-16T20:56:19Z,avoid the pprust infrastructure in macro expansion,arielb1,824b307ff7e3e93f2a5d0d864e9161c3db12acfc,1,"avoid the pprust infrastructure in macro expansion This changes macro expansion to format the path of a macro directly instead of usng the pprust infrastructure. The pprust infrastructure tries to perform line-breaking in a slow fashion which is undesired when formatting the path of a macro. This should to speed up expansion by a fair amount (I saw 20% on a profiler on `rustc_mir` and 50% of the time marked as ""expansion"" in the profiler/time-passes is actually spent loading dependencies).",HEART,2017-11-15T01:37:22Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46000,MERGED,2017-11-15T10:21:57Z,2017-11-18T11:38:15Z,Support `extern type` in rustdoc.,kennytm,2792b56a92eec4a88b2d625d4584074c3918ef6f,5,Support `extern type` in rustdoc. Fixes #45640.,HEART,2017-11-17T02:12:23Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46000,MERGED,2017-11-15T10:21:57Z,2017-11-18T11:38:15Z,Support `extern type` in rustdoc.,kennytm,2792b56a92eec4a88b2d625d4584074c3918ef6f,5,Support `extern type` in rustdoc. Fixes #45640.,HEART,2017-11-19T10:43:25Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-15T16:02:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HEART,2017-11-15T16:02:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-15T16:17:45Z,delacian,NA https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HEART,2017-11-15T17:28:28Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-15T17:28:28Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-15T18:23:06Z,sinkuu,NA https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-16T10:31:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/46004,MERGED,2017-11-15T14:49:12Z,2017-11-17T12:57:20Z,incr.comp.: Implement query result cache and use it to cache type checking tables.,michaelwoerister,0a1f6dd8a8c27caf913a16eb0a1afeaa8183b983,1,Add doc comment for LocalDefId.,HOORAY,2017-11-22T22:32:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46008,MERGED,2017-11-15T17:07:57Z,2017-11-25T02:43:53Z,rustbuild: Update LLVM and enable ThinLTO,alexcrichton,95e9609b9dade04590b7f3b9f6c3f7b02d116b3f,3,std: Flag Windows TLS dtor symbol as #[used] Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it.,HOORAY,2017-11-15T17:11:39Z,sfackler,NA https://github.com/rust-lang/rust/pull/46008,MERGED,2017-11-15T17:07:57Z,2017-11-25T02:43:53Z,rustbuild: Update LLVM and enable ThinLTO,alexcrichton,95e9609b9dade04590b7f3b9f6c3f7b02d116b3f,3,std: Flag Windows TLS dtor symbol as #[used] Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it.,HOORAY,2017-11-15T17:22:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46008,MERGED,2017-11-15T17:07:57Z,2017-11-25T02:43:53Z,rustbuild: Update LLVM and enable ThinLTO,alexcrichton,95e9609b9dade04590b7f3b9f6c3f7b02d116b3f,3,std: Flag Windows TLS dtor symbol as #[used] Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it.,HOORAY,2017-11-16T15:24:15Z,JDevlieghere,jonas@devlieghere.com https://github.com/rust-lang/rust/pull/46008,MERGED,2017-11-15T17:07:57Z,2017-11-25T02:43:53Z,rustbuild: Update LLVM and enable ThinLTO,alexcrichton,95e9609b9dade04590b7f3b9f6c3f7b02d116b3f,3,std: Flag Windows TLS dtor symbol as #[used] Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if you compiled with LTO turns out no TLS destructors would run on Windows! The `#[used]` annotation should be a more bulletproof implementation (in the face of LTO) of preserving this symbol all the way through in LLVM and ensuring it makes it all the way to the linker which will take care of it.,HOORAY,2017-11-17T02:10:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46012,MERGED,2017-11-15T20:10:30Z,2017-11-24T12:38:15Z,Make float::from_bits transmute,Gankra,439576fd7bedf741db5fb6a21c902e858d51f2a0,2,Make float::from_bits transmute (and update the documentation to reflect this). The current implementation/documentation was made to avoid sNaN because of potential safety issues implied by old/bad LLVM documentation. These issues aren't real so we can just make the implementation transmute (as permitted by the existing documentation of this method). Also the documentation didn't actually match the behaviour: it said we may change sNaNs but in fact we canonicalized *all* NaNs. Also an example in the documentation was wrong: it said we *always* change sNaNs when the documentation was explicitly written to indicate it was implementation-defined. This makes to_bits and from_bits perfectly roundtrip cross-platform except for one caveat: although the 2008 edition of IEEE-754 specifies how to interpet the signaling bit earlier editions didn't. This lead to some platforms picking the opposite interpretation so all signaling NaNs on x86/ARM are quiet on MIPS and vice-versa. NaN-boxing is a fairly important optimization while we don't even guarantee that float operations properly preserve signalingness. As such this seems like the more natural strategy to take (as opposed to trying to mangle the signaling bit on a per-platform basis). This implementation is also of course faster.,THUMBS_UP,2017-11-15T20:18:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46012,MERGED,2017-11-15T20:10:30Z,2017-11-24T12:38:15Z,Make float::from_bits transmute,Gankra,439576fd7bedf741db5fb6a21c902e858d51f2a0,2,Make float::from_bits transmute (and update the documentation to reflect this). The current implementation/documentation was made to avoid sNaN because of potential safety issues implied by old/bad LLVM documentation. These issues aren't real so we can just make the implementation transmute (as permitted by the existing documentation of this method). Also the documentation didn't actually match the behaviour: it said we may change sNaNs but in fact we canonicalized *all* NaNs. Also an example in the documentation was wrong: it said we *always* change sNaNs when the documentation was explicitly written to indicate it was implementation-defined. This makes to_bits and from_bits perfectly roundtrip cross-platform except for one caveat: although the 2008 edition of IEEE-754 specifies how to interpet the signaling bit earlier editions didn't. This lead to some platforms picking the opposite interpretation so all signaling NaNs on x86/ARM are quiet on MIPS and vice-versa. NaN-boxing is a fairly important optimization while we don't even guarantee that float operations properly preserve signalingness. As such this seems like the more natural strategy to take (as opposed to trying to mangle the signaling bit on a per-platform basis). This implementation is also of course faster.,THUMBS_UP,2017-11-15T21:31:23Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46012,MERGED,2017-11-15T20:10:30Z,2017-11-24T12:38:15Z,Make float::from_bits transmute,Gankra,439576fd7bedf741db5fb6a21c902e858d51f2a0,2,Make float::from_bits transmute (and update the documentation to reflect this). The current implementation/documentation was made to avoid sNaN because of potential safety issues implied by old/bad LLVM documentation. These issues aren't real so we can just make the implementation transmute (as permitted by the existing documentation of this method). Also the documentation didn't actually match the behaviour: it said we may change sNaNs but in fact we canonicalized *all* NaNs. Also an example in the documentation was wrong: it said we *always* change sNaNs when the documentation was explicitly written to indicate it was implementation-defined. This makes to_bits and from_bits perfectly roundtrip cross-platform except for one caveat: although the 2008 edition of IEEE-754 specifies how to interpet the signaling bit earlier editions didn't. This lead to some platforms picking the opposite interpretation so all signaling NaNs on x86/ARM are quiet on MIPS and vice-versa. NaN-boxing is a fairly important optimization while we don't even guarantee that float operations properly preserve signalingness. As such this seems like the more natural strategy to take (as opposed to trying to mangle the signaling bit on a per-platform basis). This implementation is also of course faster.,HOORAY,2017-11-15T21:31:25Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46012,MERGED,2017-11-15T20:10:30Z,2017-11-24T12:38:15Z,Make float::from_bits transmute,Gankra,439576fd7bedf741db5fb6a21c902e858d51f2a0,2,Make float::from_bits transmute (and update the documentation to reflect this). The current implementation/documentation was made to avoid sNaN because of potential safety issues implied by old/bad LLVM documentation. These issues aren't real so we can just make the implementation transmute (as permitted by the existing documentation of this method). Also the documentation didn't actually match the behaviour: it said we may change sNaNs but in fact we canonicalized *all* NaNs. Also an example in the documentation was wrong: it said we *always* change sNaNs when the documentation was explicitly written to indicate it was implementation-defined. This makes to_bits and from_bits perfectly roundtrip cross-platform except for one caveat: although the 2008 edition of IEEE-754 specifies how to interpet the signaling bit earlier editions didn't. This lead to some platforms picking the opposite interpretation so all signaling NaNs on x86/ARM are quiet on MIPS and vice-versa. NaN-boxing is a fairly important optimization while we don't even guarantee that float operations properly preserve signalingness. As such this seems like the more natural strategy to take (as opposed to trying to mangle the signaling bit on a per-platform basis). This implementation is also of course faster.,HOORAY,2017-11-17T20:21:16Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/46051,MERGED,2017-11-17T07:02:40Z,2017-11-23T10:46:08Z,Implement in-band lifetime bindings,cramertj,79bf7db3191717df4738321a596ba21345b6cc3b,1,add some tests for the interaction with existential impl trait,HOORAY,2017-11-17T09:41:16Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46051,MERGED,2017-11-17T07:02:40Z,2017-11-23T10:46:08Z,Implement in-band lifetime bindings,cramertj,79bf7db3191717df4738321a596ba21345b6cc3b,1,add some tests for the interaction with existential impl trait,HOORAY,2017-11-17T17:11:37Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46051,MERGED,2017-11-17T07:02:40Z,2017-11-23T10:46:08Z,Implement in-band lifetime bindings,cramertj,79bf7db3191717df4738321a596ba21345b6cc3b,1,add some tests for the interaction with existential impl trait,HOORAY,2017-11-17T18:01:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46051,MERGED,2017-11-17T07:02:40Z,2017-11-23T10:46:08Z,Implement in-band lifetime bindings,cramertj,79bf7db3191717df4738321a596ba21345b6cc3b,1,add some tests for the interaction with existential impl trait,HOORAY,2018-02-21T19:00:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46093,MERGED,2017-11-19T05:58:23Z,2017-11-24T17:54:29Z,Add a MIR pass to lower 128-bit operators to lang item calls,scottmcm,42208c122757fca706bc5224f3a0c7200fae32e9,3,Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32 like the `*_sh?` methods in core * Because shift-by-anything is allowed cast into a new local for every shift,HOORAY,2017-11-19T17:58:45Z,est31,NA https://github.com/rust-lang/rust/pull/46093,MERGED,2017-11-19T05:58:23Z,2017-11-24T17:54:29Z,Add a MIR pass to lower 128-bit operators to lang item calls,scottmcm,42208c122757fca706bc5224f3a0c7200fae32e9,3,Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32 like the `*_sh?` methods in core * Because shift-by-anything is allowed cast into a new local for every shift,HOORAY,2017-11-19T20:32:09Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46093,MERGED,2017-11-19T05:58:23Z,2017-11-24T17:54:29Z,Add a MIR pass to lower 128-bit operators to lang item calls,scottmcm,42208c122757fca706bc5224f3a0c7200fae32e9,3,Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32 like the `*_sh?` methods in core * Because shift-by-anything is allowed cast into a new local for every shift,HOORAY,2017-11-22T09:32:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/46093,MERGED,2017-11-19T05:58:23Z,2017-11-24T17:54:29Z,Add a MIR pass to lower 128-bit operators to lang item calls,scottmcm,42208c122757fca706bc5224f3a0c7200fae32e9,3,Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32 like the `*_sh?` methods in core * Because shift-by-anything is allowed cast into a new local for every shift,HOORAY,2017-11-28T21:59:51Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/46093,MERGED,2017-11-19T05:58:23Z,2017-11-24T17:54:29Z,Add a MIR pass to lower 128-bit operators to lang item calls,scottmcm,42208c122757fca706bc5224f3a0c7200fae32e9,3,Handle shifts properly * The overflow-checking shift items need to take a full 128-bit type since they need to be able to detect idiocy like `1i128 << (1u128 << 127)` * The unchecked ones just take u32 like the `*_sh?` methods in core * Because shift-by-anything is allowed cast into a new local for every shift,HOORAY,2019-04-04T21:04:01Z,zone117x,NA https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",THUMBS_UP,2017-11-19T09:09:31Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",HOORAY,2017-11-19T09:09:47Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",HOORAY,2017-11-19T09:15:45Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",THUMBS_UP,2017-11-19T09:15:46Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",THUMBS_UP,2017-11-19T10:12:06Z,kennytm,NA https://github.com/rust-lang/rust/pull/46094,MERGED,2017-11-19T08:43:43Z,2017-11-28T23:22:37Z,Remove `T: Sized` on `ptr::is_null()`,dtolnay,e0f58c6a11c7990a302b47c488dc2f13fab7b9a1,3,"Remove `T: Sized` on `ptr::is_null()` This reverts commit 604f049cd5060129cf14f7bd340d442811345ea8. This is purely a revert of cuviper's revert ""Restore `T: Sized` on `ptr::is_null`"". So double revert means this is code written by cuviper!",THUMBS_UP,2017-11-19T16:20:17Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/46103,MERGED,2017-11-19T18:27:13Z,2017-11-21T20:05:48Z,"dead code lint to say ""never constructed"" for variants",zackmdavis,1a9dc2e9023ffd42d7c1b06bf149a98df7a911af,5,"dead code lint to say ""never constructed"" for variants As reported in #19140 #44083 and #44565 some users were confused when the dead-code lint reported an enum variant to be ""unused"" when it was matched on (but not constructed). This wording change makes it clearer that the lint is in fact checking for construction. We continue to say ""used"" for all other items (it's tempting to say ""called"" for functions and methods but this turns out not to be correct: functions can be passed as arguments and the dead-code lint isn't special-casing that or anything). Resolves #19140.",THUMBS_UP,2017-11-20T01:28:17Z,durka,NA https://github.com/rust-lang/rust/pull/46103,MERGED,2017-11-19T18:27:13Z,2017-11-21T20:05:48Z,"dead code lint to say ""never constructed"" for variants",zackmdavis,1a9dc2e9023ffd42d7c1b06bf149a98df7a911af,5,"dead code lint to say ""never constructed"" for variants As reported in #19140 #44083 and #44565 some users were confused when the dead-code lint reported an enum variant to be ""unused"" when it was matched on (but not constructed). This wording change makes it clearer that the lint is in fact checking for construction. We continue to say ""used"" for all other items (it's tempting to say ""called"" for functions and methods but this turns out not to be correct: functions can be passed as arguments and the dead-code lint isn't special-casing that or anything). Resolves #19140.",THUMBS_UP,2017-11-20T20:26:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46103,MERGED,2017-11-19T18:27:13Z,2017-11-21T20:05:48Z,"dead code lint to say ""never constructed"" for variants",zackmdavis,1a9dc2e9023ffd42d7c1b06bf149a98df7a911af,5,"dead code lint to say ""never constructed"" for variants As reported in #19140 #44083 and #44565 some users were confused when the dead-code lint reported an enum variant to be ""unused"" when it was matched on (but not constructed). This wording change makes it clearer that the lint is in fact checking for construction. We continue to say ""used"" for all other items (it's tempting to say ""called"" for functions and methods but this turns out not to be correct: functions can be passed as arguments and the dead-code lint isn't special-casing that or anything). Resolves #19140.",HEART,2017-11-21T06:36:26Z,Havvy,NA https://github.com/rust-lang/rust/pull/46106,MERGED,2017-11-19T22:59:56Z,2017-11-26T21:30:34Z,Add a MIR-borrowck-only output mode,est31,d79179891a40f442aee6082e43822be818a5e59c,1,Use the official abbrev.,HEART,2017-11-20T04:13:43Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:26:06Z,killercup,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:26:32Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:27:11Z,matprec,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:35:20Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:40:16Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T15:52:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T18:10:35Z,anderejd,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T19:03:39Z,mythmon,mythmon@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T21:03:00Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-20T21:32:00Z,jminer,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-21T02:59:57Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-21T09:02:51Z,Racum,ronaldo@racum.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-21T16:45:27Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-21T18:40:34Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-21T23:53:05Z,Dessix,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-21T23:53:07Z,Dessix,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-22T18:56:35Z,tirr-c,chwo9843@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-22T22:48:45Z,Dessix,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-23T17:17:33Z,shritesh,shr@ite.sh https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-23T19:07:47Z,martinrlilja,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-24T04:39:45Z,tjpalmer,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-24T19:10:16Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-24T19:10:21Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-25T01:23:44Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-25T22:18:11Z,dfrankland,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-26T08:52:44Z,disjukr,jong@chan.moe https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-26T13:20:34Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-26T13:20:34Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-26T13:20:35Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-26T20:24:03Z,sjmackenzie,setori88@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-26T20:24:04Z,sjmackenzie,setori88@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-26T20:24:05Z,sjmackenzie,setori88@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-26T20:58:20Z,joaomoreno,mail@joaomoreno.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-26T22:11:55Z,samsymons,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-26T22:33:07Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-26T23:04:39Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-26T23:04:39Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T00:16:39Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-27T00:22:45Z,dougyoung,douglasryoung@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T01:19:58Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-27T01:26:03Z,jk-gan,junkai@hey.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-27T02:18:42Z,KeenS,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-27T02:28:33Z,kaorun343,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-27T03:47:09Z,kylecesmat,kyle@kylecesmat.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T03:47:11Z,kylecesmat,kyle@kylecesmat.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T06:14:09Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T08:01:25Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-27T08:01:26Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-11-27T09:08:27Z,chrysn,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-27T17:12:06Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-28T00:15:53Z,rchaser53,tayoshizawa29@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-11-28T22:23:14Z,chpio,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-29T00:00:38Z,abdullahibnnadjo,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-11-30T13:10:55Z,TimvanScherpenzeel,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-12-02T04:21:17Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-12-08T03:16:34Z,cssivision,cssivision@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-12-08T03:16:36Z,cssivision,cssivision@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-12-08T03:16:38Z,cssivision,cssivision@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-12-10T02:53:10Z,repi,NA https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2017-12-11T15:30:37Z,baransu,tomaszcichocinski@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HOORAY,2017-12-11T15:30:37Z,baransu,tomaszcichocinski@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2017-12-11T15:30:37Z,baransu,tomaszcichocinski@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2018-01-01T13:01:29Z,Obooman,oboochin@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2018-01-22T11:33:23Z,msudgh,masoudghorbani@pm.me https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,THUMBS_UP,2018-02-15T16:56:39Z,gurghet,gurghet@gmail.com https://github.com/rust-lang/rust/pull/46115,MERGED,2017-11-20T15:19:02Z,2017-11-25T21:31:30Z,rustbuild: Enable WebAssembly backend by default,alexcrichton,48996f9e759912140ccc98072e9e55fa6480a9d7,12,rustbuild: Enable WebAssembly backend by default This commit alters how we compile LLVM by default enabling the WebAssembly backend. This then also adds the wasm32-unknown-unknown target to get compiled on the `cross` builder and distributed through rustup. Tests are not yet enabled for this target but that should hopefully be coming soon!,HEART,2019-08-08T18:45:54Z,MitchDickinson,NA https://github.com/rust-lang/rust/pull/46116,MERGED,2017-11-20T15:26:50Z,2017-11-24T15:11:17Z,Check //~ERROR comments in ui tests,oli-obk,8937d6a6cfb011d9e1fe6b4a426913dbbf9fd584,670,Merge cfail and ui tests into ui tests,HOORAY,2017-11-20T15:46:14Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46116,MERGED,2017-11-20T15:26:50Z,2017-11-24T15:11:17Z,Check //~ERROR comments in ui tests,oli-obk,8937d6a6cfb011d9e1fe6b4a426913dbbf9fd584,670,Merge cfail and ui tests into ui tests,HOORAY,2017-11-20T17:01:02Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/46116,MERGED,2017-11-20T15:26:50Z,2017-11-24T15:11:17Z,Check //~ERROR comments in ui tests,oli-obk,8937d6a6cfb011d9e1fe6b4a426913dbbf9fd584,670,Merge cfail and ui tests into ui tests,HOORAY,2017-11-20T19:03:44Z,estebank,NA https://github.com/rust-lang/rust/pull/46116,MERGED,2017-11-20T15:26:50Z,2017-11-24T15:11:17Z,Check //~ERROR comments in ui tests,oli-obk,8937d6a6cfb011d9e1fe6b4a426913dbbf9fd584,670,Merge cfail and ui tests into ui tests,HOORAY,2017-11-20T20:32:40Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46116,MERGED,2017-11-20T15:26:50Z,2017-11-24T15:11:17Z,Check //~ERROR comments in ui tests,oli-obk,8937d6a6cfb011d9e1fe6b4a426913dbbf9fd584,670,Merge cfail and ui tests into ui tests,HOORAY,2017-11-23T12:06:39Z,est31,NA https://github.com/rust-lang/rust/pull/46123,MERGED,2017-11-20T17:31:54Z,2017-11-28T10:41:55Z,Implement the special repr(C)-non-clike-enum layout,Gankra,0e63d2727c3215fab617a64c0a159ea871f4819c,1,Fix and improve test for enum repr sizes,THUMBS_UP,2017-12-09T00:18:15Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/46123,MERGED,2017-11-20T17:31:54Z,2017-11-28T10:41:55Z,Implement the special repr(C)-non-clike-enum layout,Gankra,0e63d2727c3215fab617a64c0a159ea871f4819c,1,Fix and improve test for enum repr sizes,THUMBS_UP,2017-12-12T14:35:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46123,MERGED,2017-11-20T17:31:54Z,2017-11-28T10:41:55Z,Implement the special repr(C)-non-clike-enum layout,Gankra,0e63d2727c3215fab617a64c0a159ea871f4819c,1,Fix and improve test for enum repr sizes,HEART,2018-01-07T13:45:40Z,bluss,NA https://github.com/rust-lang/rust/pull/46123,MERGED,2017-11-20T17:31:54Z,2017-11-28T10:41:55Z,Implement the special repr(C)-non-clike-enum layout,Gankra,0e63d2727c3215fab617a64c0a159ea871f4819c,1,Fix and improve test for enum repr sizes,THUMBS_UP,2021-03-01T19:36:56Z,fschutt,NA https://github.com/rust-lang/rust/pull/46128,MERGED,2017-11-20T18:40:01Z,2017-11-21T03:03:41Z,Fix doc tests for trim_right_matches,Arzte,f69d4d44d8de9edbf94e240bbd2ba252c6937179,1,Fix result for assert_eq,HOORAY,2017-11-20T20:08:02Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/46128,MERGED,2017-11-20T18:40:01Z,2017-11-21T03:03:41Z,Fix doc tests for trim_right_matches,Arzte,f69d4d44d8de9edbf94e240bbd2ba252c6937179,1,Fix result for assert_eq,THUMBS_UP,2017-11-20T20:08:05Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/46129,MERGED,2017-11-20T18:51:41Z,2017-11-25T11:00:01Z,Properly handle reexport of foreign items.,kennytm,f0fcdbc021e9f166120755ee340f15558cd23bbe,3,Properly handle reexport of foreign items. Handles `pub use` of `extern { fn static type }`. Also plug in some more `match` arms where handling `extern type` is reasonable. Fixed #46098.,THUMBS_UP,2017-11-24T08:37:02Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/46132,MERGED,2017-11-20T19:24:59Z,2017-11-20T22:35:37Z,[stable] Prepare the 1.22.0 stable release,alexcrichton,328886ba2eaf0d3ac7e78ef3ba27eb296d0af3c0,1,[stable] Prepare the 1.22.0 stable release,HOORAY,2017-11-20T22:27:45Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/46132,MERGED,2017-11-20T19:24:59Z,2017-11-20T22:35:37Z,[stable] Prepare the 1.22.0 stable release,alexcrichton,328886ba2eaf0d3ac7e78ef3ba27eb296d0af3c0,1,[stable] Prepare the 1.22.0 stable release,HOORAY,2017-11-21T09:39:11Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/46134,MERGED,2017-11-20T20:50:37Z,2017-11-21T20:05:50Z,Display negative traits implementation,GuillaumeGomez,09dcc5f361bb6d68251ff2cbc4a76b13f173ec7b,2,Display negative traits implementation,HEART,2017-11-20T23:47:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46136,MERGED,2017-11-20T21:35:07Z,2017-12-06T17:28:41Z,Clarify what `-D warnings` or `-F warnings` does,tbu-,e1e1dcc8d8e6ed6b62439d0a947b8e5308ff4216,1,Changed the wording for the `warnings` lint,HEART,2017-11-20T23:02:51Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/46136,MERGED,2017-11-20T21:35:07Z,2017-12-06T17:28:41Z,Clarify what `-D warnings` or `-F warnings` does,tbu-,e1e1dcc8d8e6ed6b62439d0a947b8e5308ff4216,1,Changed the wording for the `warnings` lint,CONFUSED,2017-11-21T09:18:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/46136,MERGED,2017-11-20T21:35:07Z,2017-12-06T17:28:41Z,Clarify what `-D warnings` or `-F warnings` does,tbu-,e1e1dcc8d8e6ed6b62439d0a947b8e5308ff4216,1,Changed the wording for the `warnings` lint,CONFUSED,2017-11-24T20:57:17Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HOORAY,2017-11-21T00:57:27Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-21T10:42:15Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-21T11:41:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HOORAY,2017-11-21T11:41:10Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-21T12:03:46Z,arielb1,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-21T12:30:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-21T22:59:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-23T17:04:49Z,est31,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HOORAY,2017-11-23T17:04:51Z,est31,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HOORAY,2017-11-23T21:38:46Z,lqd,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-11-23T21:38:47Z,lqd,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HOORAY,2017-12-06T17:09:59Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-12-06T18:08:58Z,kazcw,keziahw@gmail.com https://github.com/rust-lang/rust/pull/46142,MERGED,2017-11-21T00:33:18Z,2017-11-28T08:05:01Z,MIR: split Operand::Consume into Copy and Move.,eddyb,919ed409b0fbb56bcd6c70ff50bfc9275c4b7701,36,tests: update to include move annotations in MIR.,HEART,2017-12-12T14:23:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46148,MERGED,2017-11-21T07:38:45Z,2017-11-21T20:05:52Z,Expand a couple points in 1.22.0 release notes,SimonSapin,13c1cbe749a5d6f737152454ea4041b5d53d9acb,1,Remove 1.23.0 release notes entry on const_fn It doesn’t change anything for stable users in practice. See discussion in https://github.com/rust-lang/rust/pull/46148,THUMBS_UP,2017-11-21T17:12:15Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-11-21T15:53:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-11-21T22:07:41Z,bluss,NA https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-11-22T15:04:42Z,vojtechkral,NA https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-11-22T21:27:24Z,luciusmagn,luk.hozda@gmail.com https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-11-24T19:54:06Z,est31,NA https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-12-17T18:21:23Z,nicodemus26,NA https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2017-12-18T01:40:48Z,niconegoto,niconegoto@gmail.com https://github.com/rust-lang/rust/pull/46156,MERGED,2017-11-21T13:44:53Z,2018-02-03T14:38:58Z,Document the size of bool,SimonSapin,219ba511c824bc44149d55c570f723dcd0f0217d,1,Document the size of bool,THUMBS_UP,2021-02-04T04:22:38Z,fdwr,NA https://github.com/rust-lang/rust/pull/46174,MERGED,2017-11-21T23:11:09Z,2017-11-28T02:08:57Z,Stabilize spin_loop_hint,NA,NA,NA,NA,THUMBS_UP,2017-11-22T14:45:13Z,arthurprs,NA https://github.com/rust-lang/rust/pull/46174,MERGED,2017-11-21T23:11:09Z,2017-11-28T02:08:57Z,Stabilize spin_loop_hint,NA,NA,NA,NA,THUMBS_UP,2017-12-07T21:12:24Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,LAUGH,2017-11-21T23:48:40Z,durka,NA https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,HEART,2017-11-22T00:11:55Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,LAUGH,2017-11-22T08:32:59Z,Havvy,NA https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,LAUGH,2017-11-22T10:32:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,HEART,2017-11-22T22:23:54Z,bluss,NA https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,HEART,2017-12-28T01:01:18Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/46176,CLOSED,2017-11-21T23:31:31Z,2018-02-02T06:14:24Z,Lint for the reserved ABI of bool,est31,NA,NA,NA,HEART,2021-09-02T15:48:26Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/46177,MERGED,2017-11-22T01:08:20Z,2017-11-24T00:20:57Z,Add missing Debug impls to std_unicode,ollie27,fb094642e13fc7b41a55aa2eaba4361411cccf8f,4,Add missing Debug impls to std_unicode Also adds #![deny(missing_debug_implementations)] so they don't get missed again.,HEART,2017-11-22T06:01:45Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46196,MERGED,2017-11-22T21:31:46Z,2018-01-15T04:50:32Z,Adding RBE as a submodule #46194,projektir,a2df4131871b6d18e1d3d2913d7a4436cd0d0277,4,Adding RBE as a submodule #46194,HEART,2017-12-02T05:25:39Z,Havvy,NA https://github.com/rust-lang/rust/pull/46196,MERGED,2017-11-22T21:31:46Z,2018-01-15T04:50:32Z,Adding RBE as a submodule #46194,projektir,a2df4131871b6d18e1d3d2913d7a4436cd0d0277,4,Adding RBE as a submodule #46194,HEART,2018-01-22T10:07:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46201,MERGED,2017-11-23T05:11:10Z,2017-11-26T11:43:26Z,Adding `eprint*!` to the list of macros in the `format!` family,davidalber,2f51f671c46efe91e803de8ab02fc5d379c089a8,1,Adding `eprint*!` to the list of macros in the `format!` family,THUMBS_UP,2017-11-23T07:20:50Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HOORAY,2017-11-25T21:13:50Z,cramertj,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HEART,2017-11-25T21:15:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HOORAY,2017-11-27T07:00:54Z,durka,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HEART,2017-11-27T07:00:55Z,durka,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HEART,2017-11-30T10:53:14Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HEART,2018-01-04T17:22:54Z,estebank,NA https://github.com/rust-lang/rust/pull/46206,CLOSED,2017-11-23T15:23:47Z,2018-01-16T19:58:45Z,Default Type Parameter Fallback: Revival,leoyvens,NA,NA,NA,HEART,2018-01-14T11:39:01Z,bluss,NA https://github.com/rust-lang/rust/pull/46207,MERGED,2017-11-23T15:32:59Z,2017-11-29T01:55:44Z,Replace most call to grep in run-make by a script that cat the input.,kennytm,918158debb97b03b897c9365b89a0338f28ef6ad,1,Disable the cdylib-fewer-symbols test for all Windows (test was broken).,THUMBS_UP,2017-11-23T19:44:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46219,MERGED,2017-11-23T19:53:11Z,2017-11-29T14:55:28Z,Improve documentation for slice swap/copy/clone operations.,frewsxcv,1ad38f2ce5b1075b64e586a6f383c431053126a6,1,Improve documentation for slice swap/copy/clone operations. Fixes #45636. - Demonstrate how to use these operations with slices of differing lengths - Demonstrate how to swap/copy/clone sub-slices of a slice using `split_at_mut`,HEART,2017-11-24T07:12:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46222,CLOSED,2017-11-23T20:22:38Z,2017-11-24T20:06:42Z,DO NOT MERGE: Enable full backtraces,Zoxc,NA,NA,NA,CONFUSED,2017-11-23T20:26:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/46223,CLOSED,2017-11-23T20:36:15Z,2017-12-21T18:37:19Z,[WIP] New implementation of the slice iterators using NonZero,bluss,NA,NA,NA,HOORAY,2017-11-23T20:45:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46223,CLOSED,2017-11-23T20:36:15Z,2017-12-21T18:37:19Z,[WIP] New implementation of the slice iterators using NonZero,bluss,NA,NA,NA,HOORAY,2017-11-24T07:08:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46232,MERGED,2017-11-24T02:52:10Z,2017-12-10T21:35:04Z,Add docs for never primitive,canndrew,172f16bc9dcaa928af973f693589754d86473435,1,Update never_type docs based on feedback,HEART,2017-11-24T09:04:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46232,MERGED,2017-11-24T02:52:10Z,2017-12-10T21:35:04Z,Add docs for never primitive,canndrew,172f16bc9dcaa928af973f693589754d86473435,1,Update never_type docs based on feedback,HEART,2017-11-24T16:49:23Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/46232,MERGED,2017-11-24T02:52:10Z,2017-12-10T21:35:04Z,Add docs for never primitive,canndrew,172f16bc9dcaa928af973f693589754d86473435,1,Update never_type docs based on feedback,HEART,2017-11-25T00:15:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46233,MERGED,2017-11-24T08:59:41Z,2017-12-20T09:13:59Z,Make fmt::DebugList and friends forward formatting parameters,SimonSapin,bf087895102f1ab275a7ceed9f789dcfb7e172f3,2,Keep access to private Formatter fields in Formatter methods,HOORAY,2017-11-24T11:08:23Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46248,MERGED,2017-11-24T22:16:44Z,2017-12-11T02:04:59Z,one-time diagnostics for private enum variants glob reëxport,zackmdavis,4fb57e0796cc61bec9d6a8a0392bbfe5855d693e,3,one-time diagnostic and suggestion for reëxporting private variant error We issue just one message for an erroneous glob private variant reëxport (using the Session's one-time-diagnostics capability) but individual (non-glob) such erroneous reëxports still get their own messages. The suggestion to make the enum public is also one-time. The enum variant reëxport error didn't have an associated error code (and remedying this here is deemed out of the scope of this commit) so we resort to the expediency of using 0 as the `DiagnosticMessageId` value. Adding Debug to NameResolution was helpful in development. This resolves #46209.,HEART,2017-11-27T14:26:24Z,estebank,NA https://github.com/rust-lang/rust/pull/46255,CLOSED,2017-11-25T12:50:26Z,2018-01-26T17:56:03Z,Use the linker directly on darwin ios,tamird,NA,NA,NA,THUMBS_UP,2018-01-02T20:36:04Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/46258,MERGED,2017-11-25T15:43:07Z,2017-11-28T02:09:02Z,Remove semicolon note,colinmarsh19,096e698e4e8e48bd38a2002107616f4ad194e8eb,1,Changed to correct quotes ` `,HEART,2017-11-26T23:29:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46258,MERGED,2017-11-25T15:43:07Z,2017-11-28T02:09:02Z,Remove semicolon note,colinmarsh19,096e698e4e8e48bd38a2002107616f4ad194e8eb,1,Changed to correct quotes ` `,HEART,2017-12-06T08:55:05Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/46258,MERGED,2017-11-25T15:43:07Z,2017-11-28T02:09:02Z,Remove semicolon note,colinmarsh19,096e698e4e8e48bd38a2002107616f4ad194e8eb,1,Changed to correct quotes ` `,THUMBS_UP,2017-12-12T14:20:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46260,MERGED,2017-11-25T17:27:06Z,2017-12-04T01:36:01Z,Make doc stubs for builtin macros reflect existing support for trailing commas,ExpHP,31b8a15e7026eb882aeda7b7b1c704f444da4e81,1,Update libcore macro stubs like libstd,HEART,2017-11-26T23:41:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46262,MERGED,2017-11-25T18:09:01Z,2017-11-28T02:09:03Z,Introduce LinkedList::drain_filter,udoprog,60aa8347f51fddaaed61d8304689111f6ac3e0af,2,Implement LinkedList::drain_filter Relates to rust-lang/rfcs#2140 - drain_filter for all collections `drain_filter` is implemented instead of `LinkedList::remove_if` based on review feedback.,HEART,2017-11-27T20:15:43Z,bluss,NA https://github.com/rust-lang/rust/pull/46264,MERGED,2017-11-25T20:13:00Z,2017-11-26T11:43:32Z,InstCombine Len([_; N]) => const N in MIR,scottmcm,62391c8c862556e22933af2510f4852b63444b41,2,InstCombine Len([_; N]) => const N in MIR,THUMBS_UP,2017-11-25T21:02:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46264,MERGED,2017-11-25T20:13:00Z,2017-11-26T11:43:32Z,InstCombine Len([_; N]) => const N in MIR,scottmcm,62391c8c862556e22933af2510f4852b63444b41,2,InstCombine Len([_; N]) => const N in MIR,THUMBS_UP,2017-11-29T20:37:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46264,MERGED,2017-11-25T20:13:00Z,2017-11-26T11:43:32Z,InstCombine Len([_; N]) => const N in MIR,scottmcm,62391c8c862556e22933af2510f4852b63444b41,2,InstCombine Len([_; N]) => const N in MIR,THUMBS_UP,2019-12-03T02:36:23Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/46268,MERGED,2017-11-25T23:04:15Z,2017-12-06T21:06:00Z,MIR borrowck: implement union-and-array-compatible semantics,arielb1,9d3558725b9110beaa6740e88847e3addc9c2d0d,2,work around weird match arm lifetimes,HOORAY,2017-11-27T22:43:11Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46280,MERGED,2017-11-26T17:49:25Z,2017-12-02T00:15:08Z,rustc_llvm: remove stale references,tamird,94d02b896c3feb5e997b95a660e850c7ad8cbe74,5,"*: strip calls to cc::Build::compile The documentation states: ""The name output should be the name of the library."" and this is already done in more recently-added callers.",HEART,2017-11-26T18:22:45Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46281,CLOSED,2017-11-26T20:07:59Z,2017-12-23T13:08:58Z,Add low-level APIs for converting integers to strings,SimonSapin,NA,NA,NA,CONFUSED,2017-11-27T09:42:35Z,kennytm,NA https://github.com/rust-lang/rust/pull/46281,CLOSED,2017-11-26T20:07:59Z,2017-12-23T13:08:58Z,Add low-level APIs for converting integers to strings,SimonSapin,NA,NA,NA,THUMBS_UP,2017-11-27T23:38:51Z,jminer,NA https://github.com/rust-lang/rust/pull/46285,MERGED,2017-11-26T21:58:11Z,2017-11-28T02:09:05Z,Document non-obvious behavior of fmt::UpperHex & co for negative integers,SimonSapin,a326d8d1ba6286b1641b8c89d5ae1383fbfac76a,1,Document non-obvious behavior of fmt::UpperHex & co for negative integers Before stabilization I’d have suggested changing the behavior but that time is past.,HEART,2019-09-18T09:38:01Z,Enet4,NA https://github.com/rust-lang/rust/pull/46285,MERGED,2017-11-26T21:58:11Z,2017-11-28T02:09:05Z,Document non-obvious behavior of fmt::UpperHex & co for negative integers,SimonSapin,a326d8d1ba6286b1641b8c89d5ae1383fbfac76a,1,Document non-obvious behavior of fmt::UpperHex & co for negative integers Before stabilization I’d have suggested changing the behavior but that time is past.,THUMBS_UP,2020-08-27T00:48:14Z,cmcqueen,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-11-26T23:59:45Z,durka,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-26T23:59:47Z,durka,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-26T23:59:49Z,durka,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-27T01:04:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-27T01:04:29Z,cramertj,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-11-27T01:04:30Z,cramertj,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-11-27T01:37:25Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-27T01:37:25Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-27T01:37:26Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-27T10:08:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-27T10:18:51Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-27T17:30:22Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-27T23:53:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-11-27T23:53:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-27T23:53:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-28T17:41:45Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-29T06:15:58Z,jminer,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HEART,2017-11-29T15:06:31Z,lqd,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-11-29T15:06:32Z,lqd,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-11-29T15:06:33Z,lqd,NA https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,HOORAY,2017-12-06T12:24:22Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46287,MERGED,2017-11-26T22:22:03Z,2017-11-29T14:55:31Z,Stabilize const-calling existing const-fns in std,SimonSapin,6c5f53e65ee5f022611033dbf58c42e26be7f93d,45,Stabilize const-calling existing const-fns in std Fixes #46038,THUMBS_UP,2017-12-12T14:19:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46288,MERGED,2017-11-26T22:23:09Z,2017-12-02T07:49:37Z,Bump to 1.24.0,alexcrichton,a850bb0e5d07212ae716f447f3f69f6e4ce467da,13,Update bootstrap compiler Also remove a number of `stage0` annotations and such,HOORAY,2017-11-26T23:24:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46288,MERGED,2017-11-26T22:23:09Z,2017-12-02T07:49:37Z,Bump to 1.24.0,alexcrichton,a850bb0e5d07212ae716f447f3f69f6e4ce467da,13,Update bootstrap compiler Also remove a number of `stage0` annotations and such,HOORAY,2017-11-26T23:48:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46288,MERGED,2017-11-26T22:23:09Z,2017-12-02T07:49:37Z,Bump to 1.24.0,alexcrichton,a850bb0e5d07212ae716f447f3f69f6e4ce467da,13,Update bootstrap compiler Also remove a number of `stage0` annotations and such,HOORAY,2017-12-02T18:43:27Z,alexbool,NA https://github.com/rust-lang/rust/pull/46290,MERGED,2017-11-27T00:37:54Z,2017-12-03T10:27:18Z,Update compiler-builtins and use it in the 128-bit lowering MIR test,scottmcm,c0654ce8156c0b3811595a29c137d318d90d0686,2,Add ignore-emscripten too,HEART,2017-11-27T01:01:36Z,est31,NA https://github.com/rust-lang/rust/pull/46290,MERGED,2017-11-27T00:37:54Z,2017-12-03T10:27:18Z,Update compiler-builtins and use it in the 128-bit lowering MIR test,scottmcm,c0654ce8156c0b3811595a29c137d318d90d0686,2,Add ignore-emscripten too,HEART,2017-11-27T01:07:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/46290,MERGED,2017-11-27T00:37:54Z,2017-12-03T10:27:18Z,Update compiler-builtins and use it in the 128-bit lowering MIR test,scottmcm,c0654ce8156c0b3811595a29c137d318d90d0686,2,Add ignore-emscripten too,HEART,2017-11-27T02:45:37Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,HOORAY,2017-11-27T03:45:10Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,HEART,2017-11-27T03:45:12Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,THUMBS_UP,2017-11-27T07:30:32Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,HOORAY,2017-11-27T15:34:35Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,HEART,2017-11-27T15:34:36Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,THUMBS_UP,2017-11-27T15:34:37Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46291,MERGED,2017-11-27T00:43:04Z,2017-11-28T20:40:59Z,ci: Start running wasm32 tests on Travis,alexcrichton,73970bf6f287b93ebd9775783652217e1aca02d3,23,ci: Start running wasm32 tests on Travis This commit allocates a builder to running wasm32 tests on Travis. Not all test suites pass right now so this is starting out with just the run-pass and the libcore test suites. This'll hopefully give us a pretty broad set of coverage for integration in rustc itself as well as a somewhat broad coverage of the llvm backend itself through integration/unit tests.,THUMBS_UP,2017-11-28T21:56:17Z,NikVolf,nikvolf@gmail.com https://github.com/rust-lang/rust/pull/46305,MERGED,2017-11-27T15:24:08Z,2017-12-05T02:58:07Z,Move rustc_back modules where they belong.,irinagpopa,2c175df013a701321e44bcdba3c7ba7772ed3b94,14,rustc_back: replace tempdir with crates.io version.,HEART,2017-11-27T15:35:52Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46319,MERGED,2017-11-27T22:37:57Z,2017-12-04T21:46:21Z,NLL: improve inference with flow results represent regions with bitsets and more,nikomatsakis,a6adc74e8726dd0fa0260964d0d7c03e9b48c655,1,adopt `longer` and `shorter` rather than `fr` and `outlived_fr`,HOORAY,2017-11-27T23:35:15Z,est31,NA https://github.com/rust-lang/rust/pull/46319,MERGED,2017-11-27T22:37:57Z,2017-12-04T21:46:21Z,NLL: improve inference with flow results represent regions with bitsets and more,nikomatsakis,a6adc74e8726dd0fa0260964d0d7c03e9b48c655,1,adopt `longer` and `shorter` rather than `fr` and `outlived_fr`,HEART,2017-11-27T23:35:18Z,est31,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T06:37:30Z,est31,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T06:47:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T07:11:31Z,delacian,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T07:51:14Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T08:38:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T08:59:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T09:18:19Z,lqd,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T10:15:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T10:15:39Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T15:12:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T15:12:52Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T15:45:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T17:47:26Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T19:08:53Z,i80and,heli@heli.pet https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T19:28:35Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-28T20:58:11Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T20:58:12Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-28T22:05:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-29T03:05:51Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-29T08:07:19Z,matprec,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-29T14:57:21Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-29T15:15:26Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-29T15:35:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-29T21:50:36Z,bitshifter,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-11-29T21:58:25Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-29T21:58:25Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-30T19:29:43Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-11-30T21:47:31Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-12-09T20:36:58Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2017-12-09T20:37:00Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2017-12-15T07:09:43Z,kornholi,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2018-06-25T19:16:18Z,frol,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2019-05-03T12:31:04Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,THUMBS_UP,2019-05-18T08:50:29Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2019-06-12T15:18:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-05-30T09:29:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/46321,CLOSED,2017-11-28T06:30:41Z,2017-12-20T06:03:33Z," rustc_mir: implement an ""lvalue reuse"" optimization (aka destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2020-05-30T09:29:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/46327,MERGED,2017-11-28T12:04:48Z,2017-12-29T23:07:45Z,Updated RELEASES.md for 1.23.0,XAMPPRocky,a1438b704c15ae0a16587d3cfe08ac4b946daa84,1,Update RELEASES.md,HOORAY,2017-11-28T12:48:53Z,kennytm,NA https://github.com/rust-lang/rust/pull/46327,MERGED,2017-11-28T12:04:48Z,2017-12-29T23:07:45Z,Updated RELEASES.md for 1.23.0,XAMPPRocky,a1438b704c15ae0a16587d3cfe08ac4b946daa84,1,Update RELEASES.md,HOORAY,2017-11-28T16:58:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46327,MERGED,2017-11-28T12:04:48Z,2017-12-29T23:07:45Z,Updated RELEASES.md for 1.23.0,XAMPPRocky,a1438b704c15ae0a16587d3cfe08ac4b946daa84,1,Update RELEASES.md,HOORAY,2017-11-28T17:03:13Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46347,MERGED,2017-11-28T21:10:27Z,2017-12-02T15:08:16Z,Add case insensitive comparison besides Levenstein for DYM,raventid,f18446e78de1e925b9849bd618e20ed471ad0e61,2,add magic comment for ui test remove newline,HEART,2017-11-29T16:38:11Z,estebank,NA https://github.com/rust-lang/rust/pull/46349,MERGED,2017-11-28T22:42:42Z,2017-12-02T17:37:18Z,On type mismatch error highlight `&` when type matches,estebank,02808f1e9e5315addbc3c3fa3f12116d366323b9,1,Include lifetime on highlighted ref type mismatch,THUMBS_UP,2017-11-29T04:41:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46349,MERGED,2017-11-28T22:42:42Z,2017-12-02T17:37:18Z,On type mismatch error highlight `&` when type matches,estebank,02808f1e9e5315addbc3c3fa3f12116d366323b9,1,Include lifetime on highlighted ref type mismatch,THUMBS_UP,2017-11-29T06:37:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46349,MERGED,2017-11-28T22:42:42Z,2017-12-02T17:37:18Z,On type mismatch error highlight `&` when type matches,estebank,02808f1e9e5315addbc3c3fa3f12116d366323b9,1,Include lifetime on highlighted ref type mismatch,THUMBS_UP,2017-11-29T06:58:01Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/46349,MERGED,2017-11-28T22:42:42Z,2017-12-02T17:37:18Z,On type mismatch error highlight `&` when type matches,estebank,02808f1e9e5315addbc3c3fa3f12116d366323b9,1,Include lifetime on highlighted ref type mismatch,THUMBS_UP,2017-11-29T08:12:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46349,MERGED,2017-11-28T22:42:42Z,2017-12-02T17:37:18Z,On type mismatch error highlight `&` when type matches,estebank,02808f1e9e5315addbc3c3fa3f12116d366323b9,1,Include lifetime on highlighted ref type mismatch,THUMBS_UP,2017-11-29T21:39:53Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46353,CLOSED,2017-11-29T01:19:35Z,2018-01-04T16:02:27Z,[WIP] rustc_llvm: use rust-bindgen to generate FFI bindings,tamird,NA,NA,NA,HEART,2017-11-29T11:42:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46353,CLOSED,2017-11-29T01:19:35Z,2018-01-04T16:02:27Z,[WIP] rustc_llvm: use rust-bindgen to generate FFI bindings,tamird,NA,NA,NA,HEART,2017-11-29T14:46:25Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/46353,CLOSED,2017-11-29T01:19:35Z,2018-01-04T16:02:27Z,[WIP] rustc_llvm: use rust-bindgen to generate FFI bindings,tamird,NA,NA,NA,HEART,2018-04-11T20:23:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T06:33:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T10:36:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T11:42:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T13:53:50Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T14:45:58Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-11-29T23:11:41Z,Ixrec,NA https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-12-06T16:09:28Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-12-07T00:22:34Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/46356,MERGED,2017-11-29T05:37:46Z,2017-11-29T14:55:37Z,Reject '2' as a binary digit in internals of b: number formatting,daboross,2c98378ace8d9d406c9701844a7e556def6f7cbc,1,Reject '2' as a binary digit in internals of 'b' formatting I don't believe the previous code `0 ... 2` would run into any real problems but it seems confusing to read given that '2' is never a valid binary digit. As far as I can tell this code is only ever called from within another private method in the trait which has logic to never hand it '2' anyways. I thought we could change this for clarity anyways.,LAUGH,2017-12-07T21:05:11Z,johnthagen,NA https://github.com/rust-lang/rust/pull/46370,MERGED,2017-11-29T15:32:52Z,2017-12-01T03:26:05Z,incr.comp.: Remove ability to produce incr. comp. hashes during metadata export.,michaelwoerister,7ebccbb7a4003e036cae61c575ac7edb871a8259,29,incr.comp.: Update test cases after metadata hashing removal.,HEART,2017-11-29T17:01:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-11-29T23:23:49Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-11-29T23:58:03Z,sinkuu,NA https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-11-30T01:39:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-11-30T09:46:49Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-12-01T02:03:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-12-06T12:34:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46382,MERGED,2017-11-29T21:52:32Z,2017-12-03T00:55:00Z,rustc: Prepare to enable ThinLTO by default,alexcrichton,855f6d1483e023cea3b7988db294ed9767e15359,8,rustc: Prepare to enable ThinLTO by default This commit prepares to enable ThinLTO and multiple codegen units in release mode by default. We've still got a debuginfo bug or two to sort out before actually turning it on by default.,HOORAY,2017-12-12T14:12:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46385,MERGED,2017-11-29T23:02:42Z,2017-12-02T00:15:13Z,rustbuild: Fix a typo with the Cargo book,alexcrichton,326eb79cf61a4ff22b10467d60330417294b91dd,1,rustbuild: Fix a typo with the Cargo book The usage of `Path::new` prevented out-of-tree builds (like the bots do) from working by accident! Closes #46195,LAUGH,2017-11-29T23:10:53Z,kennytm,NA https://github.com/rust-lang/rust/pull/46385,MERGED,2017-11-29T23:02:42Z,2017-12-02T00:15:13Z,rustbuild: Fix a typo with the Cargo book,alexcrichton,326eb79cf61a4ff22b10467d60330417294b91dd,1,rustbuild: Fix a typo with the Cargo book The usage of `Path::new` prevented out-of-tree builds (like the bots do) from working by accident! Closes #46195,LAUGH,2017-11-30T05:39:37Z,est31,NA https://github.com/rust-lang/rust/pull/46385,MERGED,2017-11-29T23:02:42Z,2017-12-02T00:15:13Z,rustbuild: Fix a typo with the Cargo book,alexcrichton,326eb79cf61a4ff22b10467d60330417294b91dd,1,rustbuild: Fix a typo with the Cargo book The usage of `Path::new` prevented out-of-tree builds (like the bots do) from working by accident! Closes #46195,LAUGH,2017-11-30T12:17:37Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46387,MERGED,2017-11-29T23:32:58Z,2017-12-02T00:15:14Z,Fix rustdoc item summaries that are headers,chrisduerr,91a41069115c70f95509fadae70e67c0effbed93,2,Fix rustoc item summaries that are headers Rustoc item summaries that are headers were not displayed at all because they started with whitespace. This PR fixes this and now removes the whitespace and then displays the block.,THUMBS_UP,2017-11-30T01:24:40Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/46393,MERGED,2017-11-30T10:41:02Z,2017-12-03T20:31:29Z,[auto-toolstate][2+3/8] Move external tools tests into its own job with --no-fail-fast,kennytm,183964505bf6775c90da5d034cc8951cd46d7c10,4,Update the tools CI to use --no-fail-fast and --save-toolstates.,HEART,2017-11-30T19:22:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46417,CLOSED,2017-12-01T06:55:57Z,2018-01-10T02:24:04Z,libtest: add glob support to test name filters,jonhoo,NA,NA,NA,THUMBS_UP,2017-12-01T15:37:57Z,ekmartin,mail@ekmartin.com https://github.com/rust-lang/rust/pull/46417,CLOSED,2017-12-01T06:55:57Z,2018-01-10T02:24:04Z,libtest: add glob support to test name filters,jonhoo,NA,NA,NA,THUMBS_UP,2017-12-01T19:31:20Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/46425,MERGED,2017-12-01T14:25:30Z,2017-12-01T21:29:40Z,"MIR: change ""lvalue"" terminology to ""place"".",eddyb,473f044225e7cab4047fecd15268042f7aee2509,60,MIR: s/lv(al(ue)?)?/place in function/variable/module names.,THUMBS_UP,2017-12-01T14:39:19Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46425,MERGED,2017-12-01T14:25:30Z,2017-12-01T21:29:40Z,"MIR: change ""lvalue"" terminology to ""place"".",eddyb,473f044225e7cab4047fecd15268042f7aee2509,60,MIR: s/lv(al(ue)?)?/place in function/variable/module names.,THUMBS_UP,2017-12-01T16:33:59Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/46425,MERGED,2017-12-01T14:25:30Z,2017-12-01T21:29:40Z,"MIR: change ""lvalue"" terminology to ""place"".",eddyb,473f044225e7cab4047fecd15268042f7aee2509,60,MIR: s/lv(al(ue)?)?/place in function/variable/module names.,THUMBS_UP,2017-12-01T17:34:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/46425,MERGED,2017-12-01T14:25:30Z,2017-12-01T21:29:40Z,"MIR: change ""lvalue"" terminology to ""place"".",eddyb,473f044225e7cab4047fecd15268042f7aee2509,60,MIR: s/lv(al(ue)?)?/place in function/variable/module names.,THUMBS_UP,2017-12-02T09:03:16Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/46431,MERGED,2017-12-01T18:02:03Z,2017-12-06T17:28:46Z,Mention the name of ? in Result's docs,steveklabnik,893474ea6d16497b23503582f5b85be2ea2bab0b,1,Mention the name of ? in Result's docs Fixes #42725 or at least this is the best we can really do. #35946 is tracking better errors already so that should cover the other part of it.,THUMBS_UP,2017-12-06T21:21:52Z,mistydemeo,mistydemeo@gmail.com https://github.com/rust-lang/rust/pull/46436,MERGED,2017-12-01T22:58:25Z,2017-12-17T18:53:21Z,Detect unaligned fields via `aggregate.align < field.align` instead of a `packed` flag.,eddyb,799a83ca2faf1af870a4120376b47f2511685982,1,Mark miri as broken.,THUMBS_UP,2017-12-05T05:35:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46441,MERGED,2017-12-02T07:51:32Z,2017-12-20T03:58:19Z, Lint against single-use lifetime names,gaurikholkar,e741dad62990660f2f9a3378e695dfb5e03320ef,12,adding lint for single use lifetime names,HOORAY,2017-12-02T10:42:52Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46441,MERGED,2017-12-02T07:51:32Z,2017-12-20T03:58:19Z, Lint against single-use lifetime names,gaurikholkar,e741dad62990660f2f9a3378e695dfb5e03320ef,12,adding lint for single use lifetime names,HOORAY,2017-12-29T22:01:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46441,MERGED,2017-12-02T07:51:32Z,2017-12-20T03:58:19Z, Lint against single-use lifetime names,gaurikholkar,e741dad62990660f2f9a3378e695dfb5e03320ef,12,adding lint for single use lifetime names,HOORAY,2018-02-21T18:43:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HEART,2017-12-02T18:47:54Z,estebank,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HEART,2017-12-03T14:52:24Z,killercup,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HOORAY,2017-12-03T15:57:53Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HOORAY,2017-12-06T23:07:10Z,jgrund,grundjoseph@gmail.com https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HEART,2018-01-27T13:46:47Z,0xNetay,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HOORAY,2018-01-27T13:46:50Z,0xNetay,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HOORAY,2018-02-13T06:48:16Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HEART,2018-09-29T15:48:50Z,mchernyavsky,NA https://github.com/rust-lang/rust/pull/46450,MERGED,2017-12-02T15:51:53Z,2018-01-27T13:40:11Z,Libtest json output,Gilnaa,8b7f1d0cec3884e07e2dd9ea4d0d4faeda5b95ed,1,libtest: Fixed call to python in run-make,HOORAY,2018-10-06T08:17:36Z,lu-zero,NA https://github.com/rust-lang/rust/pull/46461,MERGED,2017-12-03T08:30:14Z,2018-01-13T05:02:09Z, type error method suggestions use whitelisted identity-like conversions,zackmdavis,aba56ddd05d821b6f0a3e5fc05bc47311e09051c,14,"type error method suggestions use whitelisted identity-like conversions Previously on a type mismatch (and if this wasn't preëmpted by a higher-priority suggestion) we would look for argumentless methods returning the expected type and list them in a `help` note. This had two major shortcomings. Firstly a lot of the suggestions didn't really make sense (if you used a &str where a String was expected `.to_ascii_uppercase()` is probably not the solution you were hoping for). Secondly we weren't generating suggestions from the most useful traits! We address the first problem with an internal `#[rustc_conversion_suggestion]` attribute meant to mark methods that keep the ""same value"" in the relevant sense just converting the type. We address the second problem by making `FnCtxt.probe_for_return_type` pass the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe because grep reveals no other callers of `probe_for_return_type`. Also structured suggestions are preferred (because they're pretty but also for RLS and friends). Also also we make the E0055 autoderef recursion limit error use the one-time-diagnostics set because we can potentially hit the limit a lot during probing. (Without this test/ui/did_you_mean/recursion_limit_deref.rs would report ""aborting due to 51 errors""). Unfortunately the trait probing is still not all one would hope for: at a minimum we don't know how to rule out `into()` in cases where it wouldn't actually work and we don't know how to rule in `.to_owned()` where it would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME. This is hoped to resolve #42929 #44672 and #45777.",HEART,2017-12-04T05:31:53Z,durka,NA https://github.com/rust-lang/rust/pull/46461,MERGED,2017-12-03T08:30:14Z,2018-01-13T05:02:09Z, type error method suggestions use whitelisted identity-like conversions,zackmdavis,aba56ddd05d821b6f0a3e5fc05bc47311e09051c,14,"type error method suggestions use whitelisted identity-like conversions Previously on a type mismatch (and if this wasn't preëmpted by a higher-priority suggestion) we would look for argumentless methods returning the expected type and list them in a `help` note. This had two major shortcomings. Firstly a lot of the suggestions didn't really make sense (if you used a &str where a String was expected `.to_ascii_uppercase()` is probably not the solution you were hoping for). Secondly we weren't generating suggestions from the most useful traits! We address the first problem with an internal `#[rustc_conversion_suggestion]` attribute meant to mark methods that keep the ""same value"" in the relevant sense just converting the type. We address the second problem by making `FnCtxt.probe_for_return_type` pass the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe because grep reveals no other callers of `probe_for_return_type`. Also structured suggestions are preferred (because they're pretty but also for RLS and friends). Also also we make the E0055 autoderef recursion limit error use the one-time-diagnostics set because we can potentially hit the limit a lot during probing. (Without this test/ui/did_you_mean/recursion_limit_deref.rs would report ""aborting due to 51 errors""). Unfortunately the trait probing is still not all one would hope for: at a minimum we don't know how to rule out `into()` in cases where it wouldn't actually work and we don't know how to rule in `.to_owned()` where it would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME. This is hoped to resolve #42929 #44672 and #45777.",HEART,2017-12-06T23:59:19Z,estebank,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-04T08:21:57Z,cramertj,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-04T09:51:34Z,killercup,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-17T00:18:09Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-17T04:57:39Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-18T22:59:34Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-26T10:28:20Z,lqd,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2017-12-28T15:56:46Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T08:55:02Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",THUMBS_UP,2018-01-03T08:55:05Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",THUMBS_UP,2018-01-03T13:03:35Z,chpio,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T13:03:36Z,chpio,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T16:12:57Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T16:50:53Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T20:06:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T21:02:11Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-03T21:22:13Z,colin-kiegel,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",THUMBS_UP,2018-01-03T22:15:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-08T07:56:40Z,axlrose,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",THUMBS_UP,2018-01-13T01:46:32Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",THUMBS_UP,2018-01-15T08:48:05Z,kgv,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-01-15T08:48:06Z,kgv,NA https://github.com/rust-lang/rust/pull/46479,MERGED,2017-12-03T21:28:58Z,2017-12-27T18:27:25Z,Implements RFC 1937: `?` in `main`,bkchr,09f94bea4aca7696b58dd7e6668ca27d71908984,2,"Revert ""New generated main returns void"" This reverts commit 267800a7c0834dd8ca93a82a20cb0cdd9e7dc025.",HOORAY,2018-06-24T02:58:55Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/46480,CLOSED,2017-12-03T22:36:12Z,2018-01-13T18:04:29Z,Remove `impl Foo for .. {}` in favor `auto trait Foo {}`,leoyvens,NA,NA,NA,HEART,2017-12-04T08:13:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46480,CLOSED,2017-12-03T22:36:12Z,2018-01-13T18:04:29Z,Remove `impl Foo for .. {}` in favor `auto trait Foo {}`,leoyvens,NA,NA,NA,HEART,2017-12-04T11:47:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46480,CLOSED,2017-12-03T22:36:12Z,2018-01-13T18:04:29Z,Remove `impl Foo for .. {}` in favor `auto trait Foo {}`,leoyvens,NA,NA,NA,HEART,2017-12-25T02:09:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/46483,MERGED,2017-12-03T23:03:09Z,2017-12-06T17:28:49Z,Document behavior of `ptr::swap` with overlapping regions of memory.,frewsxcv,f3662275e45271b6f0f1d30d572a21e19f3261a1,1,Document behavior of `ptr::swap` with overlapping regions of memory. Fixes https://github.com/rust-lang/rust/issues/44479.,HEART,2017-12-04T00:54:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46485,MERGED,2017-12-04T04:48:47Z,2017-12-04T12:38:44Z,Add a specialization of read_exact for Cursor.,khuey,02c1862fb55c6ae4198038b1b317bcdd06e395d1,1,Add a specialization of read_exact for Cursor. The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy. On a workload I have that decompresses deserializes (via bincode) and processes some data this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.,HOORAY,2017-12-04T05:00:04Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/46485,MERGED,2017-12-04T04:48:47Z,2017-12-04T12:38:44Z,Add a specialization of read_exact for Cursor.,khuey,02c1862fb55c6ae4198038b1b317bcdd06e395d1,1,Add a specialization of read_exact for Cursor. The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy. On a workload I have that decompresses deserializes (via bincode) and processes some data this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.,HOORAY,2017-12-04T06:11:18Z,est31,NA https://github.com/rust-lang/rust/pull/46485,MERGED,2017-12-04T04:48:47Z,2017-12-04T12:38:44Z,Add a specialization of read_exact for Cursor.,khuey,02c1862fb55c6ae4198038b1b317bcdd06e395d1,1,Add a specialization of read_exact for Cursor. The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy. On a workload I have that decompresses deserializes (via bincode) and processes some data this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.,HOORAY,2017-12-04T09:59:35Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/46485,MERGED,2017-12-04T04:48:47Z,2017-12-04T12:38:44Z,Add a specialization of read_exact for Cursor.,khuey,02c1862fb55c6ae4198038b1b317bcdd06e395d1,1,Add a specialization of read_exact for Cursor. The read_exact implementation for &[u8] is optimized and usually allows LLVM to reduce a read_exact call for small numbers of bytes to a bounds check and a register load instead of a generic memcpy. On a workload I have that decompresses deserializes (via bincode) and processes some data this leads to a 40% speedup by essentially eliminating the deserialization overhead entirely.,HOORAY,2017-12-12T14:23:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46497,MERGED,2017-12-04T18:01:58Z,2017-12-07T23:48:00Z,Modify message for keyword as identifier name,AgustinCB,29e268060209765e5a9efb4c0941765d064e13ea,1,remove unnecessary change,HEART,2017-12-07T00:15:32Z,estebank,NA https://github.com/rust-lang/rust/pull/46518,MERGED,2017-12-05T17:17:28Z,2018-03-20T12:50:47Z,Improve documentation for Borrow,partim,13d94d666e037162808174f0bedbd5db9d65c7fe,1,Fix formatting.,HOORAY,2017-12-05T17:30:21Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/46518,MERGED,2017-12-05T17:17:28Z,2018-03-20T12:50:47Z,Improve documentation for Borrow,partim,13d94d666e037162808174f0bedbd5db9d65c7fe,1,Fix formatting.,HEART,2017-12-05T17:30:23Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/46518,MERGED,2017-12-05T17:17:28Z,2018-03-20T12:50:47Z,Improve documentation for Borrow,partim,13d94d666e037162808174f0bedbd5db9d65c7fe,1,Fix formatting.,THUMBS_UP,2017-12-05T23:08:48Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/46518,MERGED,2017-12-05T17:17:28Z,2018-03-20T12:50:47Z,Improve documentation for Borrow,partim,13d94d666e037162808174f0bedbd5db9d65c7fe,1,Fix formatting.,THUMBS_UP,2018-01-05T06:01:50Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/46518,MERGED,2017-12-05T17:17:28Z,2018-03-20T12:50:47Z,Improve documentation for Borrow,partim,13d94d666e037162808174f0bedbd5db9d65c7fe,1,Fix formatting.,THUMBS_UP,2018-01-29T19:42:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/46526,MERGED,2017-12-05T23:43:35Z,2017-12-08T05:13:53Z,Greatly improve sidebar when width < 700px,GuillaumeGomez,423e5ac6f3ca61cd050277293dcae9faf9bd08f5,1,Fix JS errors,HEART,2017-12-06T23:58:29Z,estebank,NA https://github.com/rust-lang/rust/pull/46528,MERGED,2017-12-06T00:24:57Z,2017-12-07T04:46:15Z,Stabilize abi_sysv64,CensoredUsername,d68d1278752d67bd8dc98958713daabf716db549,5,Stabilize abi_sysv64,THUMBS_UP,2017-12-06T13:42:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46528,MERGED,2017-12-06T00:24:57Z,2017-12-07T04:46:15Z,Stabilize abi_sysv64,CensoredUsername,d68d1278752d67bd8dc98958713daabf716db549,5,Stabilize abi_sysv64,THUMBS_UP,2019-01-17T19:54:20Z,terylmiller,NA https://github.com/rust-lang/rust/pull/46532,MERGED,2017-12-06T09:22:50Z,2017-12-07T21:06:02Z,Allow feature-gate tests to live in ui/ and migrate most of the tests from compile-fail,est31,6dba3e68e670a3b1418b259ca5f3758444dd1a68,71,Migrate even more feature gate tests to ui We also rename some of the files to conform to the feature-gate-.rs pattern that is most common.,HOORAY,2017-12-06T21:01:09Z,estebank,NA https://github.com/rust-lang/rust/pull/46533,MERGED,2017-12-06T11:04:06Z,2017-12-07T07:16:56Z,compiletest: account for `ui` reference files when deciding to skip,nikomatsakis,7b456c053cb66c86919d1475b9ab418c4665a6af,1,pacify the mercilous tidy,HEART,2017-12-06T15:36:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T13:04:12Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T13:30:32Z,est31,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HEART,2017-12-06T13:30:34Z,est31,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T14:03:14Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T14:21:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T14:29:34Z,alexbool,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T14:35:48Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T15:12:44Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T15:56:07Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T17:48:30Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T17:50:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T18:23:30Z,arthurprs,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T21:01:47Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-06T21:27:26Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-07T07:26:38Z,Seadragon91,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-07T23:57:29Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2017-12-15T07:17:20Z,matprec,NA https://github.com/rust-lang/rust/pull/46537,MERGED,2017-12-06T12:05:44Z,2017-12-15T08:13:38Z,[MIR-borrowck] Two phase borrows,pnkfelix,159037e05383f2349a709aa1c1681f11f89c552a,1,"Address review feedback: don't treat ""first"" activation special. Instead filter out (non-)conflicts of activiations with themselves in the same manner that we filter out non-conflict between an activation and its reservation.",HOORAY,2018-01-04T13:36:52Z,vramana,NA https://github.com/rust-lang/rust/pull/46548,MERGED,2017-12-07T01:44:29Z,2017-12-08T05:13:55Z,Recommends lazily evaluated alternatives for `Option::or` and `Result::or`,jonathanstrong,5847d0babdb4bc4545d9aeb9ef89862589ae1504,2,adds links to methods removes trailing whitespace,HEART,2017-12-07T19:20:08Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/46549,MERGED,2017-12-07T02:02:24Z,2017-12-08T11:34:35Z,rustc: Further tweak linkage in ThinLTO,alexcrichton,17fb43bdc61481ff754fe53e8e8fa589fb8789ee,2,"rustc: Further tweak linkage in ThinLTO In #46382 the logic around linkage preservation with ThinLTO ws tweaked but the loop that registered all otherwise exported GUID values as ""don't internalize me please"" was erroneously too conservative and only asking ""external"" linkage items to not be internalized. Instead we actually want the inversion of that condition everything *without* ""local"" linkage to be internalized. This commit updates the condition there adds a test and... Closes #46543",THUMBS_UP,2017-12-07T02:29:15Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/46550,MERGED,2017-12-07T04:44:21Z,2017-12-13T13:43:43Z,macros: hygienize use of `core`/`std` in builtin macros,jseyfried,85d19b33357897c51d80727a4208f46b19c5c5a6,6,Improve pretty printing `$crate::` paths.,THUMBS_UP,2017-12-07T07:39:37Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2017-12-07T06:55:48Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2017-12-07T07:38:17Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2017-12-07T23:56:59Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2018-01-17T19:48:20Z,bstrie,NA https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2018-01-17T22:04:28Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/46551,MERGED,2017-12-07T05:06:02Z,2018-01-12T12:51:35Z,macros: improve 1.0/2.0 interaction,jseyfried,b766fa887dc0e4b923a38751fe4d570e35a75710,3,Add example of making an unhygienic macro hygienic by wrapping it in a declarative macro.,THUMBS_UP,2018-01-18T04:55:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46554,MERGED,2017-12-07T08:50:52Z,2017-12-26T20:47:40Z,[auto-toolstate] Upload the toolstate result to an external git repository and removes BuildExpectation,kennytm,44954ab52d82fe5ae5222c3bfd482d38c3db0baa,6,Clarify toolstate names. Move publish.py to a more convenient location.,HEART,2017-12-07T10:18:46Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46558,MERGED,2017-12-07T15:01:49Z,2017-12-11T19:22:36Z,Clean up the MIR borrowck code,arielb1,e798cb0e52e505ed759f8af01e90a758858b115d,3,centralize `does_not_live_long_enough` error reporting,HOORAY,2017-12-07T16:07:49Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/46558,MERGED,2017-12-07T15:01:49Z,2017-12-11T19:22:36Z,Clean up the MIR borrowck code,arielb1,e798cb0e52e505ed759f8af01e90a758858b115d,3,centralize `does_not_live_long_enough` error reporting,HOORAY,2017-12-07T16:27:09Z,est31,NA https://github.com/rust-lang/rust/pull/46558,MERGED,2017-12-07T15:01:49Z,2017-12-11T19:22:36Z,Clean up the MIR borrowck code,arielb1,e798cb0e52e505ed759f8af01e90a758858b115d,3,centralize `does_not_live_long_enough` error reporting,HOORAY,2017-12-07T18:33:42Z,cramertj,NA https://github.com/rust-lang/rust/pull/46558,MERGED,2017-12-07T15:01:49Z,2017-12-11T19:22:36Z,Clean up the MIR borrowck code,arielb1,e798cb0e52e505ed759f8af01e90a758858b115d,3,centralize `does_not_live_long_enough` error reporting,HOORAY,2017-12-07T23:50:52Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46560,MERGED,2017-12-07T15:17:54Z,2017-12-16T06:31:37Z,Loading the dependency graph in the background,Yoric,a0fb93ddb4eb5fe1fe59ae10c14795b893ba786a,4,Resolves #46555 - Moving loading and decoding of dependency graph to background thread,THUMBS_UP,2017-12-08T18:03:18Z,bjorn3,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-07T16:34:55Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-07T16:44:19Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-07T22:10:24Z,vramana,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-07T23:47:32Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-08T02:27:23Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-08T09:08:21Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-08T21:38:25Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-08T23:13:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-09T04:33:44Z,tirr-c,chwo9843@gmail.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-09T05:20:36Z,sinkuu,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-11T15:12:47Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2017-12-14T16:03:37Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-01-08T07:45:04Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-01-22T22:28:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-02-04T13:20:53Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-03-15T12:33:30Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-05-17T14:23:07Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-05-18T03:50:46Z,hcpl,NA https://github.com/rust-lang/rust/pull/46564,CLOSED,2017-12-07T16:27:32Z,2018-07-10T17:03:49Z,WIP: Parallelize passes using rayon,Zoxc,NA,NA,NA,HOORAY,2018-06-26T04:18:47Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/46570,MERGED,2017-12-07T19:31:10Z,2017-12-13T01:44:49Z,Ignore `unsopported constant expr` error,AgustinCB,cbd25ed8f420a0728d5a6d8e726f898d26686060,1,deny instead of warn,THUMBS_UP,2017-12-07T22:44:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46616,MERGED,2017-12-10T05:58:31Z,2017-12-13T07:13:25Z,Implement impl Trait lifetime elision,cramertj,018c4038c79820e418e600df64cf36a88712652b,3,Implement impl Trait lifetime elision,HEART,2017-12-12T15:00:44Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/46666,MERGED,2017-12-11T18:43:06Z,2018-01-31T06:59:19Z,Move Duration to libcore,clarfonthey,aab712cbc8f657f3e87dacd762d23c80e589ac95,3,Move time::Duration to libcore,HOORAY,2017-12-12T14:02:46Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/46692,CLOSED,2017-12-12T17:28:16Z,2017-12-12T20:27:54Z,Rollup of 2 pull requests,GuillaumeGomez,NA,NA,NA,CONFUSED,2017-12-12T17:32:49Z,kennytm,NA https://github.com/rust-lang/rust/pull/46706,MERGED,2017-12-13T02:29:31Z,2017-12-15T13:26:45Z,Lifetime Resolution for Generic Associated Types,sunjay,f701b4cca07d740d4d17c906ff982d40101ec09e,2,Added test to make sure that undeclared lifetimes are in fact detected,THUMBS_UP,2017-12-17T22:13:34Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/46706,MERGED,2017-12-13T02:29:31Z,2017-12-15T13:26:45Z,Lifetime Resolution for Generic Associated Types,sunjay,f701b4cca07d740d4d17c906ff982d40101ec09e,2,Added test to make sure that undeclared lifetimes are in fact detected,THUMBS_UP,2021-08-04T10:07:49Z,fwcd,NA https://github.com/rust-lang/rust/pull/46706,MERGED,2017-12-13T02:29:31Z,2017-12-15T13:26:45Z,Lifetime Resolution for Generic Associated Types,sunjay,f701b4cca07d740d4d17c906ff982d40101ec09e,2,Added test to make sure that undeclared lifetimes are in fact detected,THUMBS_UP,2021-08-06T14:00:29Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/46714,MERGED,2017-12-13T16:23:12Z,2018-02-16T06:23:39Z,Refactor diverging and numeric fallback.,leoyvens,d49d428f791b97c476c066deb9c2b3c20165199f,5,Revert checking casts before fallback. This turns out to not be backwards compatible.,HOORAY,2017-12-13T21:22:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/46721,CLOSED,2017-12-14T04:49:44Z,2017-12-16T09:02:47Z,suggest `..` for erroneous `...` in struct pattern; don't discard successfully-parsed fields on error,zackmdavis,NA,NA,NA,HEART,2017-12-14T18:02:35Z,estebank,NA https://github.com/rust-lang/rust/pull/46731,CLOSED,2017-12-14T19:37:45Z,2018-01-13T00:49:11Z,Make eprint! use its own LOCAL_STDERR handle instead of reusing the panicking one,Zoxc,NA,NA,NA,THUMBS_UP,2017-12-15T17:37:22Z,durka,NA https://github.com/rust-lang/rust/pull/46731,CLOSED,2017-12-14T19:37:45Z,2018-01-13T00:49:11Z,Make eprint! use its own LOCAL_STDERR handle instead of reusing the panicking one,Zoxc,NA,NA,NA,THUMBS_UP,2017-12-27T06:20:30Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/46732,MERGED,2017-12-14T19:49:51Z,2017-12-22T09:54:35Z,Do not emit type errors on recovered blocks,estebank,d90d5d19da1126c5e66ede7d23bcfd8e18601a8a,1,Mark clippy as broken,HOORAY,2018-01-01T03:37:15Z,bluss,NA https://github.com/rust-lang/rust/pull/46733,MERGED,2017-12-14T19:55:31Z,2017-12-20T06:37:36Z,nll part 5,nikomatsakis,1816ede386c6dd6e61f50e7b0f9bdba19adc0e24,1,be specific about what kind of normalization we mean,HOORAY,2017-12-15T15:47:15Z,est31,NA https://github.com/rust-lang/rust/pull/46733,MERGED,2017-12-14T19:55:31Z,2017-12-20T06:37:36Z,nll part 5,nikomatsakis,1816ede386c6dd6e61f50e7b0f9bdba19adc0e24,1,be specific about what kind of normalization we mean,HOORAY,2017-12-19T10:39:20Z,arthurprs,NA https://github.com/rust-lang/rust/pull/46733,MERGED,2017-12-14T19:55:31Z,2017-12-20T06:37:36Z,nll part 5,nikomatsakis,1816ede386c6dd6e61f50e7b0f9bdba19adc0e24,1,be specific about what kind of normalization we mean,HOORAY,2017-12-19T12:36:50Z,matprec,NA https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-01-03T09:54:09Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-01-03T14:27:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-01-03T20:27:13Z,mitchhentges,mitch9654@gmail.com https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-01-09T09:06:49Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-01-09T17:02:29Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-15T21:21:56Z,ypconstante,NA https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-15T22:47:14Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-16T05:58:11Z,lafolle,fghjklp@gmail.com https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-16T08:25:01Z,wanderrful,NA https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-22T15:19:43Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-02-28T22:08:37Z,vsartor,victhor@victhor.io https://github.com/rust-lang/rust/pull/46735,MERGED,2017-12-14T21:57:38Z,2018-01-01T21:47:16Z,Use memchr for str::find(char),Manishearth,5cf55165fae5c8538db5c00e252ad9ba42aaf246,1,handle overflow/underflow in index offsets,HOORAY,2018-03-02T06:01:38Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/46754,MERGED,2017-12-15T20:57:30Z,2017-12-21T10:56:52Z,Refactor argument-position impl Trait,cramertj,e502194e7e2605b461c3e24d30fdc5def4e1c166,11,Refactor argument-position impl Trait,THUMBS_UP,2017-12-16T00:25:33Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/46760,MERGED,2017-12-16T07:15:27Z,2017-12-20T17:34:18Z,add aarch64-unknown-openbsd support,semarie,8c7b0938c2c425cbf46f363d84d326105d2a80ba,2,add aarch64-unknown-openbsd support - make liblibc to point to libc with aarch64-unknown-openbsd - make c_char (in std::os::raw) to point to right value,HOORAY,2018-01-09T17:03:46Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46772,MERGED,2017-12-16T16:22:50Z,2017-12-21T13:34:16Z,rustc: Work around `DICompileUnit` bugs in LLVM,alexcrichton,e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af,3,rustc: Work around `DICompileUnit` bugs in LLVM This commit implements a workaround for #46346 which basically just avoids triggering the situation that LLVM's bug https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be found in the code itself but this commit is also intended to ... Closes #46346,HEART,2017-12-16T16:30:25Z,durka,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-16T22:10:26Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-16T23:28:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-17T02:42:07Z,retep998,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-17T06:50:05Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-17T07:38:32Z,Havvy,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-17T10:04:05Z,qnighy,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-22T02:12:25Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2017-12-28T17:02:20Z,bluss,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-01-17T21:43:52Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-01-19T17:17:19Z,danilaml,NA https://github.com/rust-lang/rust/pull/46777,MERGED,2017-12-16T21:37:26Z,2018-01-10T06:33:34Z,Deprecate [T]::rotate in favor of [T]::rotate_{left right}.,frewsxcv,66ef6b9c0995cc678a00f4d061ba8e6adb16f610,6,Deprecate [T]::rotate in favor of [T]::rotate_{left right}. Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_left(2); assert_eq!(a ['c' 'd' 'e' 'f' 'a' 'b']); ``` ```rust let mut a = ['a' 'b' 'c' 'd' 'e' 'f']; a.rotate_right(2); assert_eq!(a ['e' 'f' 'a' 'b' 'c' 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-01-19T19:48:43Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/46778,MERGED,2017-12-16T23:56:05Z,2017-12-17T06:57:38Z,syntax: Rename `P::unwrap` into something less alarming,petrochenkov,a4aa26aaa076ce732f2c26803d9d48459aa2046a,7,syntax: Rename `P::unwrap` into `P::into_inner`,LAUGH,2017-12-17T00:59:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46778,MERGED,2017-12-16T23:56:05Z,2017-12-17T06:57:38Z,syntax: Rename `P::unwrap` into something less alarming,petrochenkov,a4aa26aaa076ce732f2c26803d9d48459aa2046a,7,syntax: Rename `P::unwrap` into `P::into_inner`,LAUGH,2017-12-17T02:34:55Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46778,MERGED,2017-12-16T23:56:05Z,2017-12-17T06:57:38Z,syntax: Rename `P::unwrap` into something less alarming,petrochenkov,a4aa26aaa076ce732f2c26803d9d48459aa2046a,7,syntax: Rename `P::unwrap` into `P::into_inner`,THUMBS_UP,2017-12-17T02:34:58Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46778,MERGED,2017-12-16T23:56:05Z,2017-12-17T06:57:38Z,syntax: Rename `P::unwrap` into something less alarming,petrochenkov,a4aa26aaa076ce732f2c26803d9d48459aa2046a,7,syntax: Rename `P::unwrap` into `P::into_inner`,LAUGH,2017-12-17T07:41:40Z,kennytm,NA https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,HOORAY,2017-12-17T13:55:35Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,THUMBS_UP,2017-12-17T15:11:16Z,dlight,NA https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,HEART,2017-12-17T15:29:46Z,GiovanniSM20,giovannimartins2000@gmail.com https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,HOORAY,2017-12-17T15:29:49Z,GiovanniSM20,giovannimartins2000@gmail.com https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,HEART,2018-01-13T01:27:22Z,estebank,NA https://github.com/rust-lang/rust/pull/46785,MERGED,2017-12-17T13:24:33Z,2018-03-01T17:27:07Z,[Underspecified semantics] Type check defaults at declaration.,leoyvens,3e84aeda0fa308424338529611a8ee157776b221,1,Update UI test,THUMBS_UP,2018-03-21T14:34:52Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/46787,MERGED,2017-12-17T15:23:09Z,2017-12-20T17:34:19Z,Add an option to allow rustdoc to list modules by appearance,varkor,b3c6102be3752fa1b70cc5f9cf9903b13a4c3928,1,Add a test for `--sort-modules-by-appearance`,HEART,2017-12-19T01:46:04Z,Havvy,NA https://github.com/rust-lang/rust/pull/46787,MERGED,2017-12-17T15:23:09Z,2017-12-20T17:34:19Z,Add an option to allow rustdoc to list modules by appearance,varkor,b3c6102be3752fa1b70cc5f9cf9903b13a4c3928,1,Add a test for `--sort-modules-by-appearance`,HEART,2017-12-19T08:51:28Z,chordowl,NA https://github.com/rust-lang/rust/pull/46788,MERGED,2017-12-17T16:06:53Z,2017-12-17T23:29:40Z,syntax: recovery for incorrect associated item paths like `[T; N]::clone`,petrochenkov,70e5c3731961b5754bc5b155a75b2f7ff7fb997b,9,syntax: recovery for incorrect associated item paths like `[T; N]::clone`,HEART,2017-12-17T18:51:42Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/46788,MERGED,2017-12-17T16:06:53Z,2017-12-17T23:29:40Z,syntax: recovery for incorrect associated item paths like `[T; N]::clone`,petrochenkov,70e5c3731961b5754bc5b155a75b2f7ff7fb997b,9,syntax: recovery for incorrect associated item paths like `[T; N]::clone`,HEART,2017-12-18T01:25:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46790,MERGED,2017-12-17T21:04:40Z,2017-12-19T07:05:21Z,Display binary notation for numeric swap_bytes methods.,frewsxcv,05cb6a5857a0b3966dfb48e6cc779b6a2137d6c6,1,Display binary notation for numeric swap_bytes methods. This better illustrates what's happening to the bits behind the scenes.,THUMBS_UP,2017-12-18T05:50:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46799,CLOSED,2017-12-18T01:58:52Z,2018-01-29T07:06:01Z,Fix windows home dir implementation,Diggsey,NA,NA,NA,THUMBS_UP,2017-12-18T09:18:31Z,retep998,NA https://github.com/rust-lang/rust/pull/46799,CLOSED,2017-12-18T01:58:52Z,2018-01-29T07:06:01Z,Fix windows home dir implementation,Diggsey,NA,NA,NA,THUMBS_UP,2017-12-18T21:09:05Z,jminer,NA https://github.com/rust-lang/rust/pull/46799,CLOSED,2017-12-18T01:58:52Z,2018-01-29T07:06:01Z,Fix windows home dir implementation,Diggsey,NA,NA,NA,THUMBS_UP,2017-12-21T15:11:01Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46799,CLOSED,2017-12-18T01:58:52Z,2018-01-29T07:06:01Z,Fix windows home dir implementation,Diggsey,NA,NA,NA,THUMBS_UP,2018-01-26T09:28:39Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/46814,MERGED,2017-12-18T15:36:00Z,2017-12-22T01:48:44Z,Prevent rustc overwriting input files,varkor,3a29f2878f33cadb0f63094e574bad222d63aef3,1,Fix a `compile_input` test,HEART,2017-12-18T17:40:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46814,MERGED,2017-12-18T15:36:00Z,2017-12-22T01:48:44Z,Prevent rustc overwriting input files,varkor,3a29f2878f33cadb0f63094e574bad222d63aef3,1,Fix a `compile_input` test,HEART,2017-12-18T21:47:03Z,estebank,NA https://github.com/rust-lang/rust/pull/46814,MERGED,2017-12-18T15:36:00Z,2017-12-22T01:48:44Z,Prevent rustc overwriting input files,varkor,3a29f2878f33cadb0f63094e574bad222d63aef3,1,Fix a `compile_input` test,HEART,2017-12-27T15:05:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/46814,MERGED,2017-12-18T15:36:00Z,2017-12-22T01:48:44Z,Prevent rustc overwriting input files,varkor,3a29f2878f33cadb0f63094e574bad222d63aef3,1,Fix a `compile_input` test,HEART,2017-12-27T15:12:47Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/46815,CLOSED,2017-12-18T15:46:25Z,2018-03-02T19:24:15Z,WIP: Whitelist based suggestions,dbrgn,NA,NA,NA,HEART,2017-12-18T21:56:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46815,CLOSED,2017-12-18T15:46:25Z,2018-03-02T19:24:15Z,WIP: Whitelist based suggestions,dbrgn,NA,NA,NA,HEART,2017-12-19T13:43:07Z,bjorn3,NA https://github.com/rust-lang/rust/pull/46815,CLOSED,2017-12-18T15:46:25Z,2018-03-02T19:24:15Z,WIP: Whitelist based suggestions,dbrgn,NA,NA,NA,HEART,2018-01-04T17:57:14Z,estebank,NA https://github.com/rust-lang/rust/pull/46815,CLOSED,2017-12-18T15:46:25Z,2018-03-02T19:24:15Z,WIP: Whitelist based suggestions,dbrgn,NA,NA,NA,HEART,2018-01-13T21:11:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46820,MERGED,2017-12-18T18:16:19Z,2017-12-22T01:48:45Z,libcore/num/mod.rs: simplify the int_impl! macro.,nodakai,6bce6acebb9b62791034e821e6215f53a8bf2002,1,libcore/num/mod.rs: simplify the int_impl! macro. We can simply use generic intrinsics since cd1848a1a6 Also minimize unsafe blocks. Signed-off-by: NODA Kai ,THUMBS_UP,2017-12-18T21:04:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46830,MERGED,2017-12-18T22:11:56Z,2018-01-10T09:28:27Z,Implement `Write` for `Cursor<&mut Vec>`,Diggsey,77b3090854f7d64cec26924a4109cd54cd975b9a,1,Implement `Write` for `Cursor<&mut Vec>`,LAUGH,2017-12-19T18:39:41Z,kennytm,NA https://github.com/rust-lang/rust/pull/46830,MERGED,2017-12-18T22:11:56Z,2018-01-10T09:28:27Z,Implement `Write` for `Cursor<&mut Vec>`,Diggsey,77b3090854f7d64cec26924a4109cd54cd975b9a,1,Implement `Write` for `Cursor<&mut Vec>`,HEART,2018-01-10T09:30:56Z,est31,NA https://github.com/rust-lang/rust/pull/46830,MERGED,2017-12-18T22:11:56Z,2018-01-10T09:28:27Z,Implement `Write` for `Cursor<&mut Vec>`,Diggsey,77b3090854f7d64cec26924a4109cd54cd975b9a,1,Implement `Write` for `Cursor<&mut Vec>`,HEART,2018-03-28T20:56:50Z,JesseWright,NA https://github.com/rust-lang/rust/pull/46830,MERGED,2017-12-18T22:11:56Z,2018-01-10T09:28:27Z,Implement `Write` for `Cursor<&mut Vec>`,Diggsey,77b3090854f7d64cec26924a4109cd54cd975b9a,1,Implement `Write` for `Cursor<&mut Vec>`,LAUGH,2018-03-28T20:56:50Z,JesseWright,NA https://github.com/rust-lang/rust/pull/46831,MERGED,2017-12-18T23:19:16Z,2017-12-20T17:34:23Z,Always `Debug` floats with a decimal point,Diggsey,3e98f18280a9204f9476f3a7ffc83782ea81dfdf,3,Always print floats with a decimal point with the Debug formatter,THUMBS_UP,2017-12-19T00:34:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-19T08:26:04Z,est31,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-19T10:05:53Z,arielb1,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-19T10:21:13Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-25T16:36:18Z,bstrie,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-27T15:10:46Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-29T10:53:08Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2017-12-29T11:58:32Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2018-01-21T11:40:42Z,bluss,NA https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2018-02-15T21:13:48Z,isislovecruft,isis@patternsinthevoid.net https://github.com/rust-lang/rust/pull/46833,MERGED,2017-12-19T04:02:43Z,2017-12-24T05:11:37Z,Prevent unwinding past FFI boundaries,diwic,4910ed2b1e12cfb9518ea1e1be0ec144fa0d95a6,1,Mir: fixup nits in previous commit (f536143) As suggested by arielb1. Closes rust-lang/rust#18510 Signed-off-by: David Henningsson ,HOORAY,2018-02-23T21:38:28Z,Pacoup,NA https://github.com/rust-lang/rust/pull/46857,MERGED,2017-12-19T22:46:06Z,2017-12-23T04:40:46Z,Point at `while true` span instead of entire block,estebank,e9f4fc8d406ddd2d75e4aae34fe84abdd1bc479a,4,Point at `while true` span instead of entire block,THUMBS_UP,2017-12-20T07:29:13Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46857,MERGED,2017-12-19T22:46:06Z,2017-12-23T04:40:46Z,Point at `while true` span instead of entire block,estebank,e9f4fc8d406ddd2d75e4aae34fe84abdd1bc479a,4,Point at `while true` span instead of entire block,THUMBS_UP,2017-12-20T10:01:50Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T07:12:51Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T10:20:34Z,est31,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T16:34:53Z,cramertj,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T16:48:09Z,crlf0710,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T20:00:57Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:12:31Z,CryZe,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:12:56Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:13:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:18:16Z,mmun,im.mmun@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:20:32Z,tailhook,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:22:03Z,lqd,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:22:39Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:24:17Z,kivikakk,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:30:05Z,chordowl,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:44:30Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:49:58Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T21:57:54Z,isomorpheme,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T22:04:13Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T22:04:30Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T22:09:59Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T22:12:34Z,fluxxu,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T22:32:12Z,discosultan,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T23:01:32Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T23:05:39Z,nayato,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T23:07:39Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T23:22:49Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-20T23:38:34Z,erickt,erick.tryzelaar@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T00:00:27Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T00:24:22Z,alilleybrinker,abrinker@mitre.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T00:38:47Z,makoConstruct,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T01:03:54Z,matprec,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T01:44:00Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-21T01:44:35Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T02:05:33Z,sinkuu,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T02:06:50Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T02:22:11Z,mzji,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T02:22:13Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T03:53:07Z,passchaos,greedwolf.dss@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T04:09:16Z,kornholi,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T04:14:00Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T05:45:37Z,stephanbuys,hello@stephanbuys.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-21T06:07:42Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T06:07:43Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-21T07:54:01Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T08:48:47Z,djc,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T09:45:16Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-21T10:02:45Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T10:02:46Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T10:10:35Z,bradleybeddoes,bradleybeddoes@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T10:11:24Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-21T10:29:00Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-21T10:29:02Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T12:06:52Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T13:16:39Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-21T16:49:20Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T16:49:20Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T17:13:04Z,dginev,deyan.ginev@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T18:38:18Z,stshine,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-21T23:33:43Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-22T10:58:22Z,Enet4,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-22T18:11:25Z,tbg,tobias.schottdorf@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-23T20:54:19Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-25T17:06:53Z,hcpl,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-25T17:30:27Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-25T17:30:28Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-25T17:30:29Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-25T19:17:23Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-25T19:22:38Z,Seadragon91,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-25T22:05:40Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-25T22:05:40Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-25T22:05:47Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-25T23:32:37Z,max-frai,me@maxfrai.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-26T00:10:27Z,fulmicoton,paul.masurel@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T00:10:29Z,fulmicoton,paul.masurel@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T00:44:52Z,TomGillen,thomas.gillen@googlemail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-26T02:02:37Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-26T04:32:26Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T04:33:32Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-26T04:33:33Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-26T06:13:24Z,lynnux,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T09:10:35Z,iitalics,iitalics@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T12:12:51Z,palango,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T16:14:25Z,emk,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T18:38:27Z,vittorioromeo,vittorio.romeo@outlook.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-26T22:35:14Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-27T08:11:34Z,pocket7878,poketo7878@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-27T08:11:34Z,pocket7878,poketo7878@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-27T08:11:39Z,pocket7878,poketo7878@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-27T09:46:18Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-27T15:30:39Z,thedodd,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-27T15:30:39Z,thedodd,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-27T15:30:40Z,thedodd,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-28T03:37:11Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-28T03:37:16Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-28T09:20:16Z,HongxuChen,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2017-12-28T12:47:12Z,burjui,bytefu@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-28T16:08:40Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-29T05:09:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2017-12-29T05:10:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2017-12-31T22:04:48Z,dchammond,dillonhammond@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2018-01-10T17:05:02Z,chpio,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2018-01-10T17:05:05Z,chpio,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2018-01-11T20:29:14Z,sinyakinilya,sinyakin.ilya@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HEART,2018-01-11T20:29:20Z,sinyakinilya,sinyakin.ilya@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2018-01-11T20:29:21Z,sinyakinilya,sinyakin.ilya@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2018-02-07T02:33:11Z,FraGag,fragag1@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,HOORAY,2018-03-14T20:47:14Z,eminence,NA https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2018-05-20T20:13:19Z,PetrGlad,PetrGlad@gmail.com https://github.com/rust-lang/rust/pull/46862,MERGED,2017-12-20T01:36:18Z,2017-12-21T02:05:34Z,NLL feature complete (adds `feature(nll)`)!,nikomatsakis,d925f4d1ddef8b894e4e85a115c39b63c37cc30b,1,fix truncated comment,THUMBS_UP,2018-07-23T05:49:22Z,viechang,viechang@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2017-12-23T03:52:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2017-12-30T16:40:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-01-15T10:14:33Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T10:59:17Z,kennytm,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T11:22:53Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T11:24:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T18:39:01Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T20:00:53Z,lqd,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-01-15T20:00:58Z,lqd,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-15T20:01:03Z,lqd,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T20:36:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-15T21:16:18Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-16T17:02:01Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-16T17:02:01Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-17T01:18:55Z,cramertj,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-17T01:18:56Z,cramertj,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-17T13:33:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-18T14:32:51Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-01-18T21:07:56Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-18T22:23:11Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-18T22:23:14Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-20T07:45:24Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-21T08:17:55Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-25T09:57:17Z,varkor,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-25T18:59:02Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-26T09:53:17Z,usbalbin,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-26T23:25:42Z,tinaun,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-27T11:26:31Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-27T11:26:32Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-01-27T11:26:35Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-27T14:20:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-29T13:07:35Z,msiglreith,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-29T15:48:40Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-29T15:52:52Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-29T15:53:47Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-01-29T15:53:49Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-29T18:38:30Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-31T10:20:41Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-31T14:41:21Z,bjorn3,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-01-31T17:31:34Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-05T17:08:35Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-05T19:50:20Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-10T06:37:33Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-13T12:40:06Z,killercup,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-02-14T00:34:40Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-21T21:14:31Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-22T13:54:31Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-02-26T21:38:55Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-02-28T17:17:00Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-05T09:47:53Z,obust,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-05T17:23:33Z,estebank,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-08T07:36:21Z,mzji,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-08T07:36:21Z,mzji,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-08T11:37:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-08T14:37:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-08T14:55:57Z,ZhangHanDong,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-08T15:00:42Z,ZhangHanDong,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-08T15:00:46Z,ZhangHanDong,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-08T15:00:48Z,ZhangHanDong,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-08T16:54:12Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-09T05:03:34Z,KeenS,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-09T09:39:15Z,novacrazy,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T01:47:45Z,martinlindhe,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T02:02:34Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T03:56:47Z,dodheim,dodheim@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T04:03:36Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T04:03:38Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T05:42:37Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:06:43Z,dlight,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:13:17Z,timClicks,paperless@timmcnamara.co.nz https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:14:49Z,michael-p,michael.partheil@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:30:53Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:34:48Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T07:46:05Z,repax,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T08:32:16Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T08:45:26Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T08:47:38Z,mkawia,send2kawia@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T08:56:09Z,devonhollowood,devonhollowood@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T09:20:16Z,hcpl,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T10:14:37Z,Thiez,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T11:01:02Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T11:01:02Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T11:23:59Z,krdln,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T11:32:50Z,darfink,elliott@linder.dev https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T11:42:41Z,portal-chan,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T12:09:29Z,dmilith,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T12:09:32Z,dmilith,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T12:09:32Z,dmilith,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-14T12:09:34Z,dmilith,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T12:38:06Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T13:09:50Z,Vurich,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T13:09:58Z,Vurich,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T13:28:33Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T13:40:53Z,ducdetronquito,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T13:59:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-14T14:00:28Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T14:00:29Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T14:00:31Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T15:08:06Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T15:36:50Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T16:01:43Z,souvik1997,souvik@souvik.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T16:15:51Z,piedoom,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T17:06:28Z,wrmsr,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T17:36:13Z,reptofrog,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-14T17:43:14Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T17:43:15Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T17:43:17Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-14T20:27:37Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-14T20:35:41Z,schulzch,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-14T23:41:01Z,tyranron,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T00:53:07Z,erinzm,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-15T04:10:41Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T04:10:41Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-15T07:33:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-15T07:33:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T07:33:02Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-15T07:33:03Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-15T09:42:54Z,ondj,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T14:42:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T17:53:47Z,mcarton,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-15T19:19:13Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-15T19:19:14Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-16T06:39:33Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-16T09:01:37Z,johncf,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-16T09:01:38Z,johncf,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-16T09:01:40Z,johncf,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-16T10:46:10Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-16T13:37:40Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-16T17:08:51Z,g-k,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-16T20:20:17Z,vittorioromeo,vittorio.romeo@outlook.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-20T03:24:49Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-03-20T03:24:49Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-20T03:24:50Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-03-20T03:24:51Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-03-22T00:07:43Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-30T12:18:55Z,UtherII,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-03-31T19:10:44Z,bb010g,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-04-25T19:36:02Z,krk,keremkat@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-05-07T19:09:21Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-05-08T00:50:27Z,Lokathor,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-05-08T07:39:11Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-05-09T09:47:05Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-05-09T13:19:55Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-05-10T20:52:13Z,hedgehog1024,NA https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HOORAY,2018-05-11T08:47:59Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,HEART,2018-05-11T08:48:20Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,THUMBS_UP,2018-07-25T06:05:31Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/46882,MERGED,2017-12-20T16:22:23Z,2018-03-08T11:33:51Z,Replace all const evaluation with miri,oli-obk,52dec0e1c9e0fe5bbbe81385531e69c2c46ef56e,1,Don't derive traits on packed structs,LAUGH,2018-09-04T09:58:34Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/46888,MERGED,2017-12-20T18:25:28Z,2017-12-24T10:07:38Z,Add a feature gate for nested uses of `impl Trait`,cramertj,c026d19baf4b2ea96b218fd5d83275ae6e8220a1,5,Add a feature gate for nested uses of `impl Trait`,HEART,2017-12-20T20:10:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46890,MERGED,2017-12-20T19:23:25Z,2017-12-22T01:48:50Z,A few small improvements to the contributing docs,arielb1,f68e11b4405e85d3d80242620b71b8de9d2c6dbd,2,A few small improvements to the contributing docs,HOORAY,2017-12-20T20:09:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HEART,2017-12-20T23:02:07Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HEART,2017-12-21T01:42:44Z,jseyfried,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HEART,2017-12-21T05:25:52Z,durka,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,LAUGH,2017-12-21T09:20:51Z,kennytm,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HOORAY,2017-12-27T18:44:53Z,durka,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HEART,2018-01-01T15:48:07Z,mikeyhew,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HEART,2018-01-15T08:51:59Z,kgv,NA https://github.com/rust-lang/rust/pull/46895,MERGED,2017-12-20T22:26:29Z,2018-01-01T10:02:50Z,Allow lifetimes in macros,ricochet1k,8b4bdc2f3f753e0d0b00ecc892a813e9786621e9,2,refactor lifetime out of is_lifetime,HOORAY,2018-01-15T08:52:03Z,kgv,NA https://github.com/rust-lang/rust/pull/46899,MERGED,2017-12-21T05:12:20Z,2017-12-25T02:14:47Z,Set the dwarf linkage_name to the mangled name,m4b,990a5cc1e51301cc623bd5864f15ace66fdc186a,3,dwarf: set dwarf linkage_name for fns and statics to its mangled symbol name,HEART,2017-12-21T05:13:31Z,sfackler,NA https://github.com/rust-lang/rust/pull/46899,MERGED,2017-12-21T05:12:20Z,2017-12-25T02:14:47Z,Set the dwarf linkage_name to the mangled name,m4b,990a5cc1e51301cc623bd5864f15ace66fdc186a,3,dwarf: set dwarf linkage_name for fns and statics to its mangled symbol name,HEART,2017-12-21T09:42:53Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/46899,MERGED,2017-12-21T05:12:20Z,2017-12-25T02:14:47Z,Set the dwarf linkage_name to the mangled name,m4b,990a5cc1e51301cc623bd5864f15ace66fdc186a,3,dwarf: set dwarf linkage_name for fns and statics to its mangled symbol name,HEART,2017-12-21T14:11:53Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/46899,MERGED,2017-12-21T05:12:20Z,2017-12-25T02:14:47Z,Set the dwarf linkage_name to the mangled name,m4b,990a5cc1e51301cc623bd5864f15ace66fdc186a,3,dwarf: set dwarf linkage_name for fns and statics to its mangled symbol name,HOORAY,2017-12-21T19:02:50Z,kennytm,NA https://github.com/rust-lang/rust/pull/46899,MERGED,2017-12-21T05:12:20Z,2017-12-25T02:14:47Z,Set the dwarf linkage_name to the mangled name,m4b,990a5cc1e51301cc623bd5864f15ace66fdc186a,3,dwarf: set dwarf linkage_name for fns and statics to its mangled symbol name,HEART,2017-12-21T22:11:15Z,estebank,NA https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2017-12-22T18:39:14Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2017-12-26T19:06:33Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2017-12-30T15:00:37Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2018-01-09T17:06:19Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2018-02-14T10:02:55Z,kishoreneelamegam,kishore@lendsmart.ai https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2018-02-15T20:36:17Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2018-02-19T09:29:28Z,behnam,NA https://github.com/rust-lang/rust/pull/46910,MERGED,2017-12-21T15:05:43Z,2017-12-25T04:56:05Z,rustc: Set release mode cgus to 16 by default,alexcrichton,b5361d0d41871874926bd489b8dc014a016c3f52,4,rustc: Set release mode cgus to 16 by default This commit is the next attempt to enable multiple codegen units by default in release mode getting some of those sweet sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320,HOORAY,2021-11-11T10:46:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/46926,CLOSED,2017-12-21T21:03:15Z,2017-12-30T21:44:26Z,Add LLVM `minnum`/`maxnum` intrinsics,varkor,NA,NA,NA,THUMBS_UP,2017-12-21T22:09:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46926,CLOSED,2017-12-21T21:03:15Z,2017-12-30T21:44:26Z,Add LLVM `minnum`/`maxnum` intrinsics,varkor,NA,NA,NA,HOORAY,2017-12-21T22:50:11Z,estebank,NA https://github.com/rust-lang/rust/pull/46926,CLOSED,2017-12-21T21:03:15Z,2017-12-30T21:44:26Z,Add LLVM `minnum`/`maxnum` intrinsics,varkor,NA,NA,NA,HOORAY,2017-12-21T23:50:15Z,bluss,NA https://github.com/rust-lang/rust/pull/46931,MERGED,2017-12-22T01:24:49Z,2018-01-24T06:19:36Z,Expose float from_bits and to_bits in libcore.,clarfonthey,556fb02e43a16de50764af55db20f64ac17e7f23,2,Move Bits constraints to RawFloat::RawBits,THUMBS_UP,2017-12-22T06:53:16Z,est31,NA https://github.com/rust-lang/rust/pull/46933,MERGED,2017-12-22T01:30:03Z,2017-12-26T11:16:22Z,Make core::f32/f64 docs match std.,clarfonthey,ebdd667d4083bae7aadebd8b56856fd2a30d9f1c,4,Make core::f32/f64 docs match std.,THUMBS_UP,2017-12-22T12:30:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/46938,MERGED,2017-12-22T05:42:51Z,2018-01-21T09:17:32Z,add kbd style tag to main.css in rustdoc,hellow554,0c946c01795b8a3c05273805764ca5d90cb1af60,2,converted space to tab in css files,HEART,2017-12-22T05:45:52Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/46940,MERGED,2017-12-22T08:41:18Z,2017-12-26T11:16:24Z,Add support for CloudABI targets to the rustc backend.,EdSchouten,41567525fe4e0efaf3fd2483af5b7800e7befbcf,1,Add CloudABI to the list of supported targets. Backend definitions for these targets are present meaning we can start announcing this target. While there sort the list alphabetically.,HOORAY,2018-01-04T13:20:03Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46940,MERGED,2017-12-22T08:41:18Z,2017-12-26T11:16:24Z,Add support for CloudABI targets to the rustc backend.,EdSchouten,41567525fe4e0efaf3fd2483af5b7800e7befbcf,1,Add CloudABI to the list of supported targets. Backend definitions for these targets are present meaning we can start announcing this target. While there sort the list alphabetically.,HOORAY,2018-01-08T23:09:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/46940,MERGED,2017-12-22T08:41:18Z,2017-12-26T11:16:24Z,Add support for CloudABI targets to the rustc backend.,EdSchouten,41567525fe4e0efaf3fd2483af5b7800e7befbcf,1,Add CloudABI to the list of supported targets. Backend definitions for these targets are present meaning we can start announcing this target. While there sort the list alphabetically.,HOORAY,2018-01-19T21:03:20Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/46940,MERGED,2017-12-22T08:41:18Z,2017-12-26T11:16:24Z,Add support for CloudABI targets to the rustc backend.,EdSchouten,41567525fe4e0efaf3fd2483af5b7800e7befbcf,1,Add CloudABI to the list of supported targets. Backend definitions for these targets are present meaning we can start announcing this target. While there sort the list alphabetically.,HOORAY,2018-09-26T12:46:40Z,TypedLambda,NA https://github.com/rust-lang/rust/pull/46941,MERGED,2017-12-22T09:16:40Z,2017-12-26T13:53:49Z,Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433,ScottAbbey,b989428f7dec7b52d68bed6a21e9b5b0a8086267,1,Don't try to statically link libstdc++ on FreeBSD The code inside this conditional will not work on FreeBSD 10+ because those versions use clang and libc++ rather than libstdc++. Since FreeBSD comes with libc++ in the base presumably all 10+ systems will have it present. Searching for libstdc++.a will not work if it is not present. As a result this would previously have set `LLVM_STATIC_STDCPP=libstdc++.a` which isn't a valid path and caused problems later on when building `librustc_llvm`. This could possibly be updated in the future to look for `libc++.a` on FreeBSD by expanding the code inside the conditional. In one attempt to run this on x86_64-freebsd I found that libc++ was not compiled with PIC so it failed anyway.,HOORAY,2017-12-26T17:12:49Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/46941,MERGED,2017-12-22T09:16:40Z,2017-12-26T13:53:49Z,Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433,ScottAbbey,b989428f7dec7b52d68bed6a21e9b5b0a8086267,1,Don't try to statically link libstdc++ on FreeBSD The code inside this conditional will not work on FreeBSD 10+ because those versions use clang and libc++ rather than libstdc++. Since FreeBSD comes with libc++ in the base presumably all 10+ systems will have it present. Searching for libstdc++.a will not work if it is not present. As a result this would previously have set `LLVM_STATIC_STDCPP=libstdc++.a` which isn't a valid path and caused problems later on when building `librustc_llvm`. This could possibly be updated in the future to look for `libc++.a` on FreeBSD by expanding the code inside the conditional. In one attempt to run this on x86_64-freebsd I found that libc++ was not compiled with PIC so it failed anyway.,THUMBS_UP,2017-12-27T21:03:22Z,matprec,NA https://github.com/rust-lang/rust/pull/46941,MERGED,2017-12-22T09:16:40Z,2017-12-26T13:53:49Z,Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433,ScottAbbey,b989428f7dec7b52d68bed6a21e9b5b0a8086267,1,Don't try to statically link libstdc++ on FreeBSD The code inside this conditional will not work on FreeBSD 10+ because those versions use clang and libc++ rather than libstdc++. Since FreeBSD comes with libc++ in the base presumably all 10+ systems will have it present. Searching for libstdc++.a will not work if it is not present. As a result this would previously have set `LLVM_STATIC_STDCPP=libstdc++.a` which isn't a valid path and caused problems later on when building `librustc_llvm`. This could possibly be updated in the future to look for `libc++.a` on FreeBSD by expanding the code inside the conditional. In one attempt to run this on x86_64-freebsd I found that libc++ was not compiled with PIC so it failed anyway.,HOORAY,2018-01-18T05:44:06Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2017-12-22T19:09:48Z,joshlf,NA https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2017-12-22T20:41:53Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2017-12-22T20:41:57Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2017-12-22T20:49:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2017-12-22T20:49:58Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2017-12-22T21:31:55Z,florianjacob,NA https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2017-12-28T19:46:52Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2018-01-01T15:17:01Z,diwic,NA https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2018-01-10T20:18:54Z,bluss,NA https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2018-01-25T17:25:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,HOORAY,2018-01-26T16:29:23Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/46952,MERGED,2017-12-22T18:56:41Z,2018-01-20T15:06:44Z,Rename std::ptr::Shared to NonNull and stabilize it,SimonSapin,602a445b92b37ec6af4d3d7f331e1a0d1360b8d2,2,Assign its own tracking issue to Box::into_raw_non_null https://github.com/rust-lang/rust/issues/47336,THUMBS_UP,2018-01-26T16:29:24Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/46960,CLOSED,2017-12-23T01:07:16Z,2018-01-03T02:51:04Z,WIP: Lots of fixes from clippy,clarfonthey,NA,NA,NA,HEART,2017-12-23T01:43:58Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46960,CLOSED,2017-12-23T01:07:16Z,2018-01-03T02:51:04Z,WIP: Lots of fixes from clippy,clarfonthey,NA,NA,NA,HEART,2017-12-23T15:18:44Z,killercup,NA https://github.com/rust-lang/rust/pull/46960,CLOSED,2017-12-23T01:07:16Z,2018-01-03T02:51:04Z,WIP: Lots of fixes from clippy,clarfonthey,NA,NA,NA,HEART,2017-12-24T00:48:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/46980,MERGED,2017-12-24T03:39:44Z,2018-01-20T17:51:59Z,in which the unused-parens lint comes to cover function and method args,zackmdavis,14982db2d68268458a3de03e395b2e9afe518b50,7,in which the unused-parens lint comes to cover function and method args Resolves #46137.,THUMBS_UP,2018-01-20T18:18:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/46984,MERGED,2017-12-24T13:00:24Z,2018-01-03T23:55:37Z,NLL fixes,arielb1,bd1bd76cd83d0a75917842966c52140a44753ed3,3,fix linking of place projections projections other than dereferences of `&mut` used to do no linking. Fix that. Fixes #46974.,THUMBS_UP,2017-12-25T00:07:11Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/46984,MERGED,2017-12-24T13:00:24Z,2018-01-03T23:55:37Z,NLL fixes,arielb1,bd1bd76cd83d0a75917842966c52140a44753ed3,3,fix linking of place projections projections other than dereferences of `&mut` used to do no linking. Fix that. Fixes #46974.,THUMBS_UP,2017-12-25T10:27:57Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/46984,MERGED,2017-12-24T13:00:24Z,2018-01-03T23:55:37Z,NLL fixes,arielb1,bd1bd76cd83d0a75917842966c52140a44753ed3,3,fix linking of place projections projections other than dereferences of `&mut` used to do no linking. Fix that. Fixes #46974.,THUMBS_UP,2017-12-25T18:11:08Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/46984,MERGED,2017-12-24T13:00:24Z,2018-01-03T23:55:37Z,NLL fixes,arielb1,bd1bd76cd83d0a75917842966c52140a44753ed3,3,fix linking of place projections projections other than dereferences of `&mut` used to do no linking. Fix that. Fixes #46974.,THUMBS_UP,2017-12-25T20:29:31Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/46984,MERGED,2017-12-24T13:00:24Z,2018-01-03T23:55:37Z,NLL fixes,arielb1,bd1bd76cd83d0a75917842966c52140a44753ed3,3,fix linking of place projections projections other than dereferences of `&mut` used to do no linking. Fix that. Fixes #46974.,THUMBS_UP,2017-12-28T22:34:52Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/46985,MERGED,2017-12-24T17:41:05Z,2018-01-12T23:28:04Z,Implement AsRef for Component,Diggsey,e0855ff4a13ea79daa56d23a25f827fe86e8147b,1,Implement AsRef for Component,HEART,2018-01-13T01:42:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/46990,CLOSED,2017-12-24T22:57:49Z,2018-01-31T15:39:22Z,Show long-running tests in progress even when multithreaded,sourcefrog,NA,NA,NA,THUMBS_UP,2017-12-25T00:16:18Z,SailReal,NA https://github.com/rust-lang/rust/pull/46990,CLOSED,2017-12-24T22:57:49Z,2018-01-31T15:39:22Z,Show long-running tests in progress even when multithreaded,sourcefrog,NA,NA,NA,THUMBS_UP,2017-12-28T23:10:11Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/46990,CLOSED,2017-12-24T22:57:49Z,2018-01-31T15:39:22Z,Show long-running tests in progress even when multithreaded,sourcefrog,NA,NA,NA,HEART,2018-01-17T11:39:54Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,THUMBS_UP,2017-12-25T11:08:04Z,lqd,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,THUMBS_UP,2017-12-25T12:45:34Z,oli-obk,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2017-12-25T13:48:27Z,killercup,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2017-12-25T18:08:49Z,Gilnaa,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,THUMBS_UP,2017-12-28T21:41:26Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-06T02:38:29Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-06T03:52:54Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-10T07:25:04Z,hayd,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-10T09:35:27Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-11T15:45:00Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,THUMBS_UP,2018-01-27T00:07:07Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-27T00:07:08Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/46993,CLOSED,2017-12-25T03:10:50Z,2018-01-27T17:17:12Z,[proof of concept] give String support for CoW wrapping of literals,Gankra,NA,NA,NA,HEART,2018-01-28T15:13:27Z,lqd,NA https://github.com/rust-lang/rust/pull/47004,MERGED,2017-12-25T22:07:26Z,2017-12-31T13:12:28Z,Remove transmute in From<&str> impls for Arc/Rc,nvzqz,0fbcb7b873d140341fcfead9c47b1468617a596f,2,Remove transmute in From<&str> impls for Arc/Rc,THUMBS_UP,2017-12-25T22:34:44Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47005,CLOSED,2017-12-25T22:56:32Z,2018-02-03T01:42:02Z,[WIP] Remove various transmutes,nvzqz,NA,NA,NA,THUMBS_UP,2017-12-25T23:43:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2017-12-25T23:45:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2017-12-26T00:07:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2017-12-27T19:51:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2017-12-27T20:30:17Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2017-12-27T20:56:32Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-01-02T22:11:21Z,durka,NA https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-01-31T11:29:19Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-02-01T21:01:01Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-03-29T16:33:10Z,b-jonas0,ambrus@math.bme.hu https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-09-08T16:52:02Z,hcpl,NA https://github.com/rust-lang/rust/pull/47006,MERGED,2017-12-25T23:44:00Z,2018-01-25T03:21:04Z,Stabilized `#[repr(align(x))]` attribute (RFC 1358),bitshifter,651ea8ea44d8ac8a02dc357412eb73f830057cae,14,Stabilized `#[repr(align(x))]` attribute (RFC 1358),HOORAY,2018-10-20T17:30:23Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/47009,MERGED,2017-12-26T01:25:24Z,2017-12-27T15:42:02Z,rustc_trans: support ZST indexing involving uninhabited types.,eddyb,57bb8ab832a1bfc732d06bace1fc55c19677d9fa,2,rustc_trans: support ZST indexing involving uninhabited types.,HEART,2017-12-27T20:23:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47014,MERGED,2017-12-26T10:26:37Z,2017-12-27T22:39:11Z,Add tests to fixed ICEs,topecongiro,f6f9cbe56011debeb4d6df9ad71139bc8a87d653,8,Add tests to fixed ICEs Closes #27078. Closes #27985. Closes #39848. Closes #42164. Closes #42479. Closes #45152. Closes #45662. Closes #45876. Closes #45965.,HOORAY,2017-12-28T15:39:19Z,OmnipotentEntity,NA https://github.com/rust-lang/rust/pull/47016,MERGED,2017-12-26T11:30:49Z,2017-12-28T01:25:49Z,Add dist builder for armv5te-unknown-linux-gnueabi (again),malbarbo,606a0a5da0978de723a79dfbebd04280f31d1ab1,1,Add dist builder for armv5te-unknown-linux-gnueabi,THUMBS_UP,2017-12-27T08:48:16Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/47030,MERGED,2017-12-27T15:26:25Z,2018-01-05T13:02:59Z,Correct a few stability attributes,ollie27,a8d107be258514261a9366a8a384e370eb0a9628,8,Correct a few stability attributes,THUMBS_UP,2018-01-04T18:31:05Z,Enet4,NA https://github.com/rust-lang/rust/pull/47043,CLOSED,2017-12-28T06:19:54Z,2018-01-31T09:53:39Z,Future-proof the compiler for Box.,eddyb,NA,NA,NA,HEART,2017-12-28T06:20:23Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/47043,CLOSED,2017-12-28T06:19:54Z,2018-01-31T09:53:39Z,Future-proof the compiler for Box.,eddyb,NA,NA,NA,THUMBS_UP,2017-12-28T16:21:49Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/47043,CLOSED,2017-12-28T06:19:54Z,2018-01-31T09:53:39Z,Future-proof the compiler for Box.,eddyb,NA,NA,NA,HEART,2017-12-30T17:19:47Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/47044,MERGED,2017-12-28T06:48:37Z,2017-12-31T07:28:12Z,Add tests on fixed ICEs,topecongiro,b3c022db8b0263a5a361e8ab358c085ff300888f,7,Add tests on fixed ICEs Closes #29924. Closes #38857. Closes #39665. Closes #39872. Closes #39553. Closes #41210. Closes #41880. Closes #43483.,HOORAY,2017-12-28T08:23:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/47044,MERGED,2017-12-28T06:48:37Z,2017-12-31T07:28:12Z,Add tests on fixed ICEs,topecongiro,b3c022db8b0263a5a361e8ab358c085ff300888f,7,Add tests on fixed ICEs Closes #29924. Closes #38857. Closes #39665. Closes #39872. Closes #39553. Closes #41210. Closes #41880. Closes #43483.,HOORAY,2017-12-28T17:33:42Z,estebank,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2017-12-28T18:09:13Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2017-12-28T18:23:08Z,est31,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2017-12-28T22:32:27Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2017-12-29T09:30:42Z,vermiculus,code@seanallred.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-01-03T14:37:50Z,killercup,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-03T14:37:52Z,killercup,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-08T11:34:34Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-09T08:13:58Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-09T08:42:02Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2018-01-09T16:24:59Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,LAUGH,2018-01-10T10:34:44Z,kennytm,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-01-18T22:01:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-23T02:52:55Z,sinkuu,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-23T11:06:19Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2018-01-23T17:46:35Z,bluejekyll,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-23T19:53:58Z,bluss,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,LAUGH,2018-01-23T21:32:12Z,ruabmbua,roland.rucky@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2018-01-23T21:32:17Z,ruabmbua,roland.rucky@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-01-23T21:32:21Z,ruabmbua,roland.rucky@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-23T21:32:21Z,ruabmbua,roland.rucky@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-01-24T04:55:40Z,jwilm,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2018-01-24T18:19:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-01-31T20:51:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2018-02-04T18:33:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-02-04T18:33:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-02-04T18:33:52Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-02-14T03:22:35Z,lawliet89,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HEART,2018-04-03T18:44:30Z,mcarton,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-04-14T04:39:15Z,hcpl,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2018-08-21T20:19:52Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,HOORAY,2020-07-08T19:58:51Z,betamos,didrik.nordstrom@gmail.com https://github.com/rust-lang/rust/pull/47046,MERGED,2017-12-28T11:34:21Z,2018-01-23T10:22:07Z,Implement RFC 1946 - intra-rustdoc links,Manishearth,63811b66f676c1971b15452946bad35223b8c403,1,don't process code blocks when scanning for links,THUMBS_UP,2020-07-16T11:20:28Z,Schwenger,schwengermaximilian@gmail.com https://github.com/rust-lang/rust/pull/47050,MERGED,2017-12-28T18:32:05Z,2017-12-29T03:23:47Z,rustdoc: Don't try to generate links for modules in import paths,ollie27,95f9491bc797e9e41176dbb9fecc5cb8e27d95e7,3,rustdoc: Don't try to generate links for modules in import paths The modules may be private or may even be enums so it would generate dead links.,THUMBS_UP,2017-12-28T20:46:18Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/47063,MERGED,2017-12-29T16:21:19Z,2017-12-30T22:24:12Z,Requires tools to test-pass if the corresponding submodule is updated.,kennytm,8ed16fe47a421781752272f4bd1e11eb5d3c9839,3,Requires tools to test-pass if the corresponding submodule is updated. If a PR intends to update a tool but its test has failed abort the merge regardless of current channel. This should help the tool maintainers if the update turns out to be failing due to changes in latest master.,HEART,2017-12-29T17:03:40Z,est31,NA https://github.com/rust-lang/rust/pull/47064,MERGED,2017-12-29T18:31:02Z,2018-01-01T07:20:45Z,Add a tidy check for missing or too many trailing newlines.,kennytm,4577a70934b6167862586cbb7f52b75fad448d05,1,Add a tidy check to ensure all files have 1 or 2 trailing newlines.,THUMBS_UP,2017-12-29T19:20:54Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/47064,MERGED,2017-12-29T18:31:02Z,2018-01-01T07:20:45Z,Add a tidy check for missing or too many trailing newlines.,kennytm,4577a70934b6167862586cbb7f52b75fad448d05,1,Add a tidy check to ensure all files have 1 or 2 trailing newlines.,THUMBS_UP,2017-12-29T23:57:23Z,mzimnn,NA https://github.com/rust-lang/rust/pull/47064,MERGED,2017-12-29T18:31:02Z,2018-01-01T07:20:45Z,Add a tidy check for missing or too many trailing newlines.,kennytm,4577a70934b6167862586cbb7f52b75fad448d05,1,Add a tidy check to ensure all files have 1 or 2 trailing newlines.,THUMBS_UP,2017-12-31T03:21:00Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/47064,MERGED,2017-12-29T18:31:02Z,2018-01-01T07:20:45Z,Add a tidy check for missing or too many trailing newlines.,kennytm,4577a70934b6167862586cbb7f52b75fad448d05,1,Add a tidy check to ensure all files have 1 or 2 trailing newlines.,THUMBS_UP,2017-12-31T03:43:18Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/47080,MERGED,2017-12-30T21:39:56Z,2017-12-31T02:43:42Z,Optimise min/max,varkor,fba16d3f0bcf697775d91e91064f8584b9697042,2,Optimise min/max Swapping the conditions generates more efficient x86 assembly. See https://github.com/rust-lang/rust/pull/46926#issuecomment-354567412.,HEART,2018-12-09T16:14:59Z,bluss,NA https://github.com/rust-lang/rust/pull/47082,CLOSED,2017-12-30T22:28:55Z,2018-02-01T20:31:59Z,Add UnboundedIterator Trait,oberien,NA,NA,NA,THUMBS_UP,2017-12-31T03:13:38Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/47082,CLOSED,2017-12-30T22:28:55Z,2018-02-01T20:31:59Z,Add UnboundedIterator Trait,oberien,NA,NA,NA,THUMBS_UP,2018-09-15T19:19:19Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/47084,MERGED,2017-12-31T05:22:41Z,2017-12-31T16:38:21Z,in which leading zeroes on tuple-struct accesses are abjured,zackmdavis,b0f880ddd95b5ed73bb9db66119c730fecb23fad,3,in which leading zeroes on tuple-struct accesses are abjured Resolves #47073.,LAUGH,2017-12-31T05:56:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47084,MERGED,2017-12-31T05:22:41Z,2017-12-31T16:38:21Z,in which leading zeroes on tuple-struct accesses are abjured,zackmdavis,b0f880ddd95b5ed73bb9db66119c730fecb23fad,3,in which leading zeroes on tuple-struct accesses are abjured Resolves #47073.,LAUGH,2017-12-31T07:25:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/47084,MERGED,2017-12-31T05:22:41Z,2017-12-31T16:38:21Z,in which leading zeroes on tuple-struct accesses are abjured,zackmdavis,b0f880ddd95b5ed73bb9db66119c730fecb23fad,3,in which leading zeroes on tuple-struct accesses are abjured Resolves #47073.,LAUGH,2017-12-31T16:39:09Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/47084,MERGED,2017-12-31T05:22:41Z,2017-12-31T16:38:21Z,in which leading zeroes on tuple-struct accesses are abjured,zackmdavis,b0f880ddd95b5ed73bb9db66119c730fecb23fad,3,in which leading zeroes on tuple-struct accesses are abjured Resolves #47073.,LAUGH,2018-03-24T06:25:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/47088,MERGED,2017-12-31T07:10:24Z,2018-01-03T10:07:57Z,Move static code outside of unciode.py.,clarfonthey,b4b3ddd59e2a041646f7b300ad727a5d4f48a488,6,Move static code outside of unciode.py.,THUMBS_UP,2017-12-31T11:15:35Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47099,MERGED,2018-01-01T02:43:38Z,2018-01-06T14:50:23Z,Add 'Span::parent()' and 'Span::source()' to proc_macro API.,SergioBenitez,ab365be1406919d4da42442b70c153296980ba52,4,Add 'Span.parent()' and 'Span.source()' to proc_macro API.,THUMBS_UP,2018-01-02T19:34:46Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47102,MERGED,2018-01-01T15:51:48Z,2018-02-02T04:19:16Z,Implement extensible syscall interface for wasm,Diggsey,0e6601f630743939443c7a9f5c0164cae7f46ade,4,Add wasm_syscall feature to build system,THUMBS_UP,2018-01-01T18:36:12Z,est31,NA https://github.com/rust-lang/rust/pull/47102,MERGED,2018-01-01T15:51:48Z,2018-02-02T04:19:16Z,Implement extensible syscall interface for wasm,Diggsey,0e6601f630743939443c7a9f5c0164cae7f46ade,4,Add wasm_syscall feature to build system,HEART,2018-01-01T18:36:17Z,est31,NA https://github.com/rust-lang/rust/pull/47102,MERGED,2018-01-01T15:51:48Z,2018-02-02T04:19:16Z,Implement extensible syscall interface for wasm,Diggsey,0e6601f630743939443c7a9f5c0164cae7f46ade,4,Add wasm_syscall feature to build system,HEART,2018-01-02T21:59:09Z,pshc,paul@paulcollier.ca https://github.com/rust-lang/rust/pull/47102,MERGED,2018-01-01T15:51:48Z,2018-02-02T04:19:16Z,Implement extensible syscall interface for wasm,Diggsey,0e6601f630743939443c7a9f5c0164cae7f46ade,4,Add wasm_syscall feature to build system,THUMBS_UP,2018-01-08T19:44:10Z,Dessix,NA https://github.com/rust-lang/rust/pull/47102,MERGED,2018-01-01T15:51:48Z,2018-02-02T04:19:16Z,Implement extensible syscall interface for wasm,Diggsey,0e6601f630743939443c7a9f5c0164cae7f46ade,4,Add wasm_syscall feature to build system,THUMBS_UP,2018-01-11T14:09:20Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/47108,MERGED,2018-01-01T19:21:58Z,2018-01-02T00:31:02Z,Prepare the 1.23.0 stable release,alexcrichton,cb7348bf6794371e96147927d707c841dff6c9a3,2,Prepare the 1.23.0 stable release * Update the release channel to `stable` * Update the Cargo submodule to the latest tip for 1.23.0,HOORAY,2018-01-01T19:26:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47120,MERGED,2018-01-02T03:02:43Z,2018-01-15T15:37:02Z,Better Debug impl for io::Error.,clarfonthey,52e074e40ee3eaf04415b2044c93bcfddad52f35,1,Better Debug impl for io::Error.,THUMBS_UP,2018-01-17T14:52:38Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/47120,MERGED,2018-01-02T03:02:43Z,2018-01-15T15:37:02Z,Better Debug impl for io::Error.,clarfonthey,52e074e40ee3eaf04415b2044c93bcfddad52f35,1,Better Debug impl for io::Error.,THUMBS_UP,2018-01-17T16:40:18Z,chpio,NA https://github.com/rust-lang/rust/pull/47120,MERGED,2018-01-02T03:02:43Z,2018-01-15T15:37:02Z,Better Debug impl for io::Error.,clarfonthey,52e074e40ee3eaf04415b2044c93bcfddad52f35,1,Better Debug impl for io::Error.,THUMBS_UP,2018-01-18T00:59:32Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/47122,CLOSED,2018-01-02T03:38:19Z,2018-01-22T21:35:35Z,Use #[non_exhaustive] when possible.,clarfonthey,NA,NA,NA,THUMBS_UP,2018-01-03T12:40:22Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/47126,MERGED,2018-01-02T09:28:52Z,2018-01-15T15:37:03Z,Add slice::ExactChunks and ::ExactChunksMut iterators,sdroege,5f4fc8214279f2ffadbf2cc3a4c22b748c17bd15,4,Add unit tests for exact_chunks/exact_chunks_mut These are basically modified copies of the chunks/chunks_mut tests.,THUMBS_UP,2018-01-17T21:32:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47141,MERGED,2018-01-02T23:00:42Z,2018-01-06T17:40:19Z,Bump to 1.25.0,alexcrichton,fcdca7f2da86111704e54e932f3e5ffa31d70366,1,rustc: Don't ICE if we invalidate an invalid incr dir This showed up on the Windows bot for testing this PR and this pr allows `mark_incr_comp_session_as_invalid` ok if it's already invalid hopefully avoiding scary ICEs and instead leaving the nicely printed errors,HOORAY,2018-01-03T01:16:15Z,est31,NA https://github.com/rust-lang/rust/pull/47147,MERGED,2018-01-03T01:54:43Z,2018-01-04T12:46:41Z,Force appropriate extension when converting from int to ptr #43291,projektir,6536d363d5365b0cb2584227b9a919dc287e1424,3,Force appropriate extension when converting from int to ptr #43291,HEART,2018-01-13T05:51:33Z,Havvy,NA https://github.com/rust-lang/rust/pull/47149,MERGED,2018-01-03T07:36:52Z,2018-01-05T13:03:04Z,Span::resolved_at and Span::located_at to combine behavior of two spans,dtolnay,000e907c1fc73ca249252cba3b2c9b1a20de857d,1,Span::resolved_at and Span::located_at to combine behavior of two spans Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span. In particular consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait I want the error message to underline the corresponding struct field. Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1. ``` | 4 | #[derive(HeapSize)] | ^^^^^^^^ ``` Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site. ``` | 7 | bad: std::thread::Thread | ^^^^^^^^^^^^^^^^^^^^^^^^ ``` The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column. ``` field.span.resolved_at(Span::def_site()) // equivalently Span::def_site().located_at(field.span) ``` Adding both because which one is more natural will depend on context.,THUMBS_UP,2018-01-03T19:34:23Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47149,MERGED,2018-01-03T07:36:52Z,2018-01-05T13:03:04Z,Span::resolved_at and Span::located_at to combine behavior of two spans,dtolnay,000e907c1fc73ca249252cba3b2c9b1a20de857d,1,Span::resolved_at and Span::located_at to combine behavior of two spans Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span. In particular consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait I want the error message to underline the corresponding struct field. Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1. ``` | 4 | #[derive(HeapSize)] | ^^^^^^^^ ``` Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site. ``` | 7 | bad: std::thread::Thread | ^^^^^^^^^^^^^^^^^^^^^^^^ ``` The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column. ``` field.span.resolved_at(Span::def_site()) // equivalently Span::def_site().located_at(field.span) ``` Adding both because which one is more natural will depend on context.,THUMBS_UP,2018-01-04T19:21:31Z,SergioBenitez,NA https://github.com/rust-lang/rust/pull/47152,CLOSED,2018-01-03T11:10:21Z,2018-03-02T19:22:33Z,Don't force-enable frame pointers when generating debug info,dotdash,NA,NA,NA,HOORAY,2018-01-03T13:20:30Z,retep998,NA https://github.com/rust-lang/rust/pull/47152,CLOSED,2018-01-03T11:10:21Z,2018-03-02T19:22:33Z,Don't force-enable frame pointers when generating debug info,dotdash,NA,NA,NA,THUMBS_UP,2018-01-03T13:20:34Z,retep998,NA https://github.com/rust-lang/rust/pull/47152,CLOSED,2018-01-03T11:10:21Z,2018-03-02T19:22:33Z,Don't force-enable frame pointers when generating debug info,dotdash,NA,NA,NA,HOORAY,2018-01-04T23:18:55Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/47152,CLOSED,2018-01-03T11:10:21Z,2018-03-02T19:22:33Z,Don't force-enable frame pointers when generating debug info,dotdash,NA,NA,NA,THUMBS_UP,2018-01-19T00:50:49Z,fitzgen,NA https://github.com/rust-lang/rust/pull/47155,MERGED,2018-01-03T15:06:34Z,2018-01-06T08:01:57Z,Restore working debuginfo tests by trimming comments from non-header directive lines,nerd2,0a24acda18056dd6bc4a5b8ec1897f5b34d283f4,23,Disable failing tests temporarily,HEART,2018-01-03T16:05:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/47155,MERGED,2018-01-03T15:06:34Z,2018-01-06T08:01:57Z,Restore working debuginfo tests by trimming comments from non-header directive lines,nerd2,0a24acda18056dd6bc4a5b8ec1897f5b34d283f4,23,Disable failing tests temporarily,HEART,2018-01-03T21:43:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-03T17:15:02Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-03T17:15:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HEART,2018-01-04T14:09:17Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-07T19:48:03Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-22T11:41:11Z,lqd,NA https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-24T18:38:55Z,bluss,NA https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-24T19:08:19Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-24T20:17:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-01-24T20:23:17Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HEART,2018-01-26T08:57:52Z,hannesg,hannes.georg@googlemail.com https://github.com/rust-lang/rust/pull/47158,MERGED,2018-01-03T16:52:35Z,2018-01-22T11:11:48Z,Implement repr(transparent),hanna-kruppe,2be697bc215f19b4bf17df6b9b56626ab7b1d994,21,Implement repr(transparent),HOORAY,2018-05-07T21:20:21Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/47170,MERGED,2018-01-04T01:13:45Z,2018-01-06T23:33:02Z,rustc: use {U I}size instead of {U I}s shorthands.,eddyb,210ac01792878ce0d654e852b0c794c782c04e01,33,rustc: use {U I}size instead of {U I}s shorthands.,HEART,2018-01-04T01:36:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47173,MERGED,2018-01-04T08:51:24Z,2018-01-06T05:20:37Z,Remove some outdated LLVM-related code,dotdash,7e522b2f0ebddd60fb3df467cb755c2de0f37f4d,1,Simplify LLVMRustModuleCost(),THUMBS_UP,2018-01-04T10:54:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47181,MERGED,2018-01-04T13:09:58Z,2018-01-13T11:50:28Z,Use DefIndex encoding that works better with on-disk variable length integer representations.,michaelwoerister,c9d25e3269664885e485ffefddf71472dc398019,10,Use different DefIndex representation that is better suited for variable length integer encodings.,HEART,2018-01-04T13:24:41Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-01-11T15:06:59Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-01-24T21:02:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-02-20T12:43:53Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-02-22T23:15:50Z,Ralith,NA https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-08-01T13:38:06Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2018-10-17T14:43:14Z,jpastuszek,NA https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2019-01-10T14:52:29Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47193,MERGED,2018-01-04T19:37:01Z,2018-01-21T09:17:36Z,Add transpose conversions for nested Option and Result,cramertj,c9ae249265c5da207ba0d8a2f8be95e58817e1dc,3,Add transpose conversions for Option and Result These impls are useful when working with combinator methods that expect an option or a result but you have a Result E> instead of an Option> or vice versa.,HEART,2021-08-20T13:10:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/47198,MERGED,2018-01-04T21:02:18Z,2018-01-05T13:03:09Z,Fix an error in std::process documentation,dzamlo,8fc4a24062a4088b3b5af24d25c12f818b84c841,1,Fix an error in std::process documentation,THUMBS_UP,2018-01-04T23:09:51Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/47209,MERGED,2018-01-05T05:45:18Z,2018-01-16T11:01:08Z,rustc_trans: reorganize CrateContext and rename context types.,eddyb,4e40a0d43640a5cf26f28cea35ec16445966a000,9,rustc_trans: rename mircx: MirContext to fx: FunctionCx.,THUMBS_UP,2018-01-05T11:01:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47209,MERGED,2018-01-05T05:45:18Z,2018-01-16T11:01:08Z,rustc_trans: reorganize CrateContext and rename context types.,eddyb,4e40a0d43640a5cf26f28cea35ec16445966a000,9,rustc_trans: rename mircx: MirContext to fx: FunctionCx.,HEART,2018-01-05T15:33:27Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/47209,MERGED,2018-01-05T05:45:18Z,2018-01-16T11:01:08Z,rustc_trans: reorganize CrateContext and rename context types.,eddyb,4e40a0d43640a5cf26f28cea35ec16445966a000,9,rustc_trans: rename mircx: MirContext to fx: FunctionCx.,THUMBS_UP,2018-01-25T17:20:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47223,MERGED,2018-01-05T23:43:33Z,2018-01-14T06:09:23Z,rustc: Tweak `#[target_feature]` syntax,alexcrichton,0ecaa67e9082b609bd8fd315b6cc41be7e8ee139,5,rustc: Refactor attribute checking to operate on HIR This'll enable running queries that could be cached and overall be more amenable to the query infastructure.,HOORAY,2018-01-06T00:17:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/47223,MERGED,2018-01-05T23:43:33Z,2018-01-14T06:09:23Z,rustc: Tweak `#[target_feature]` syntax,alexcrichton,0ecaa67e9082b609bd8fd315b6cc41be7e8ee139,5,rustc: Refactor attribute checking to operate on HIR This'll enable running queries that could be cached and overall be more amenable to the query infastructure.,HOORAY,2018-01-06T12:56:25Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/47223,MERGED,2018-01-05T23:43:33Z,2018-01-14T06:09:23Z,rustc: Tweak `#[target_feature]` syntax,alexcrichton,0ecaa67e9082b609bd8fd315b6cc41be7e8ee139,5,rustc: Refactor attribute checking to operate on HIR This'll enable running queries that could be cached and overall be more amenable to the query infastructure.,HOORAY,2018-01-17T11:26:09Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/47223,MERGED,2018-01-05T23:43:33Z,2018-01-14T06:09:23Z,rustc: Tweak `#[target_feature]` syntax,alexcrichton,0ecaa67e9082b609bd8fd315b6cc41be7e8ee139,5,rustc: Refactor attribute checking to operate on HIR This'll enable running queries that could be cached and overall be more amenable to the query infastructure.,HOORAY,2018-01-18T09:33:55Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/47223,MERGED,2018-01-05T23:43:33Z,2018-01-14T06:09:23Z,rustc: Tweak `#[target_feature]` syntax,alexcrichton,0ecaa67e9082b609bd8fd315b6cc41be7e8ee139,5,rustc: Refactor attribute checking to operate on HIR This'll enable running queries that could be cached and overall be more amenable to the query infastructure.,HOORAY,2018-01-19T19:46:18Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/47228,CLOSED,2018-01-06T02:14:58Z,2018-02-03T01:35:31Z,Extend `BTreeMap`'s Entry API to be able to access other elements directly from the `Entry`,pmarcelll,NA,NA,NA,THUMBS_UP,2018-01-06T12:40:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/47228,CLOSED,2018-01-06T02:14:58Z,2018-02-03T01:35:31Z,Extend `BTreeMap`'s Entry API to be able to access other elements directly from the `Entry`,pmarcelll,NA,NA,NA,THUMBS_UP,2021-04-17T16:00:24Z,so235,NA https://github.com/rust-lang/rust/pull/47231,MERGED,2018-01-06T12:36:32Z,2018-01-09T10:02:43Z,Clean emitted diagnostics when `reset_err_count` is called.,ereslibre,b48d944165dd878b887273898b7e4e4b4163c786,1,Clean emitted diagnostics when `reset_err_count` is called. When external tools like `rustfmt` calls to `reset_err_count` for handler reusing it will set the error count on the handler to 0 but since https://github.com/rust-lang/rust/pull/47146 the handler will contain status that will prevent the error count to be bumped if this handler is reused. This caused `rustfmt` idempotency tests to fail: https://github.com/rust-lang-nursery/rustfmt/issues/2338 Fixes: https://github.com/rust-lang-nursery/rustfmt/issues/2338,HOORAY,2018-01-07T04:07:01Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/47251,MERGED,2018-01-07T15:35:38Z,2018-01-13T18:06:25Z,Remove deprecated unstable attribute #[simd],hanna-kruppe,95c3fc05a91d432b215a22a082b4d4a9336db8a6,4,Remove deprecated unstable attribute `#[simd]` The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]` and if they didn't they're likely broken by now anyway.,LAUGH,2018-01-17T21:18:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47277,MERGED,2018-01-08T18:32:49Z,2018-01-15T15:37:06Z,doc: show that `f32::log` and `f64::log` are not correctly rounded,tspiteri,6d82e7814f1a387c0510ee525c6e0ac8fa890c40,2,remove implementation detail from doc,THUMBS_UP,2018-01-12T05:25:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47280,MERGED,2018-01-08T21:57:14Z,2018-01-18T14:03:22Z,Update Cargo and its dependencies,alexcrichton,80d6ed2d8b2f76cd526d2449c70a1a6af315c114,7,Update Cargo and its dependencies This'll probably have a bunch of build errors so let's try and head those off and find them sooner rather than later!,HOORAY,2018-01-08T22:17:54Z,EdSchouten,ed@nuxi.nl https://github.com/rust-lang/rust/pull/47280,MERGED,2018-01-08T21:57:14Z,2018-01-18T14:03:22Z,Update Cargo and its dependencies,alexcrichton,80d6ed2d8b2f76cd526d2449c70a1a6af315c114,7,Update Cargo and its dependencies This'll probably have a bunch of build errors so let's try and head those off and find them sooner rather than later!,HOORAY,2018-01-08T23:06:48Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/47286,MERGED,2018-01-09T01:40:17Z,2018-02-11T02:42:21Z,Update RELEASES.md for 1.24.0,XAMPPRocky,28b39f5d7aec44176b06fbbad0d5fc6e711d28f3,1,Update release notes for 1.24.0,THUMBS_UP,2018-01-09T08:35:49Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/47286,MERGED,2018-01-09T01:40:17Z,2018-02-11T02:42:21Z,Update RELEASES.md for 1.24.0,XAMPPRocky,28b39f5d7aec44176b06fbbad0d5fc6e711d28f3,1,Update release notes for 1.24.0,THUMBS_UP,2018-01-09T21:33:53Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,THUMBS_UP,2018-01-09T21:22:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,HEART,2018-01-12T06:22:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,HEART,2018-01-17T01:07:54Z,cramertj,NA https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,THUMBS_UP,2018-01-17T01:07:54Z,cramertj,NA https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,HEART,2018-02-11T05:51:51Z,estebank,NA https://github.com/rust-lang/rust/pull/47291,CLOSED,2018-01-09T12:11:23Z,2018-08-28T17:24:23Z,Eager unreachable blocks for `!` type,varkor,NA,NA,NA,HEART,2018-07-10T22:15:39Z,mgxm,i@mgxm.me https://github.com/rust-lang/rust/pull/47298,MERGED,2018-01-09T19:01:00Z,2018-01-12T23:28:18Z,Treat #[path] files as mod.rs files,cramertj,7b420cf3da1e5ff7675923cc25a2d39715d300b6,7,Treat #[path] files as mod.rs files,THUMBS_UP,2018-01-09T23:47:40Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/47298,MERGED,2018-01-09T19:01:00Z,2018-01-12T23:28:18Z,Treat #[path] files as mod.rs files,cramertj,7b420cf3da1e5ff7675923cc25a2d39715d300b6,7,Treat #[path] files as mod.rs files,THUMBS_UP,2018-01-10T20:04:59Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47298,MERGED,2018-01-09T19:01:00Z,2018-01-12T23:28:18Z,Treat #[path] files as mod.rs files,cramertj,7b420cf3da1e5ff7675923cc25a2d39715d300b6,7,Treat #[path] files as mod.rs files,THUMBS_UP,2018-01-13T03:40:02Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/47298,MERGED,2018-01-09T19:01:00Z,2018-01-12T23:28:18Z,Treat #[path] files as mod.rs files,cramertj,7b420cf3da1e5ff7675923cc25a2d39715d300b6,7,Treat #[path] files as mod.rs files,THUMBS_UP,2018-01-13T11:21:23Z,dd10-e,NA https://github.com/rust-lang/rust/pull/47298,MERGED,2018-01-09T19:01:00Z,2018-01-12T23:28:18Z,Treat #[path] files as mod.rs files,cramertj,7b420cf3da1e5ff7675923cc25a2d39715d300b6,7,Treat #[path] files as mod.rs files,THUMBS_UP,2018-01-13T14:32:33Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/47299,MERGED,2018-01-09T19:40:51Z,2018-01-24T10:39:31Z,Make core::ops::Place an unsafe trait,cramertj,f25f4687093c1c7e69a06fa7fa6cc3cc6f9aa9d1,1,Adjust wording of Placer trait safety requirements,THUMBS_UP,2018-01-09T19:46:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47299,MERGED,2018-01-09T19:40:51Z,2018-01-24T10:39:31Z,Make core::ops::Place an unsafe trait,cramertj,f25f4687093c1c7e69a06fa7fa6cc3cc6f9aa9d1,1,Adjust wording of Placer trait safety requirements,HOORAY,2018-01-22T18:12:31Z,bluss,NA https://github.com/rust-lang/rust/pull/47299,MERGED,2018-01-09T19:40:51Z,2018-01-24T10:39:31Z,Make core::ops::Place an unsafe trait,cramertj,f25f4687093c1c7e69a06fa7fa6cc3cc6f9aa9d1,1,Adjust wording of Placer trait safety requirements,THUMBS_UP,2018-01-31T22:09:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47322,MERGED,2018-01-10T15:15:46Z,2018-01-14T16:56:26Z,"resolve type and region variables in ""NLL dropck""",nikomatsakis,00ce7eed7d03b63a91c90d1fc5736b1f6450e239,2,"resolve type and region variables in ""NLL dropck"" Fixes #47022.",THUMBS_UP,2018-01-10T15:17:16Z,discosultan,NA https://github.com/rust-lang/rust/pull/47324,MERGED,2018-01-10T16:14:28Z,2018-01-12T23:28:22Z,Pre-allocate in fs::read and fs::read_string,mbrubeck,44912bf77bf1fd2137e5b7d1d31b2e59e2819136,1,Pre-allocate in fs::read and fs::read_string,THUMBS_UP,2018-01-12T06:17:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47328,MERGED,2018-01-10T17:13:26Z,2018-01-12T23:28:22Z,Use the new fs_read_write functions in rustc internals,mbrubeck,3f9c057ea60db153b7f3d24fee4b892b130cb874,18,Use the new fs_read_write functions in rustc internals,THUMBS_UP,2018-01-10T22:06:40Z,kennytm,NA https://github.com/rust-lang/rust/pull/47328,MERGED,2018-01-10T17:13:26Z,2018-01-12T23:28:22Z,Use the new fs_read_write functions in rustc internals,mbrubeck,3f9c057ea60db153b7f3d24fee4b892b130cb874,18,Use the new fs_read_write functions in rustc internals,THUMBS_UP,2018-01-12T06:13:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47334,MERGED,2018-01-10T19:50:44Z,2018-01-22T01:27:09Z,Only link res_init() on GNU/*nix,etaoins,090a968fe7680cce0d3aa8fde25a5dc48948e43e,3,"Only link res_init() on GNU/*nix To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol. This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue #46797 Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the ""gnu"" environment on Unix This should include all glibc platforms while excluding musl windows-gnu macOS FreeBSD etc. This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now.",THUMBS_UP,2018-01-10T21:24:23Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47334,MERGED,2018-01-10T19:50:44Z,2018-01-22T01:27:09Z,Only link res_init() on GNU/*nix,etaoins,090a968fe7680cce0d3aa8fde25a5dc48948e43e,3,"Only link res_init() on GNU/*nix To workaround a bug in glibc <= 2.26 lookup_host() calls res_init() based on the glibc version detected at runtime. While this avoids calling res_init() on platforms where it's not required we will still end up linking against the symbol. This causes an issue on macOS where res_init() is implemented in a separate library (libresolv.9.dylib) from the main libc. While this is harmless for standalone programs it becomes a problem if Rust code is statically linked against another program. If the linked program doesn't already specify -lresolv it will cause the link to fail. This is captured in issue #46797 Fix this by hooking in to the glibc workaround in `cvt_gai` and only activating it for the ""gnu"" environment on Unix This should include all glibc platforms while excluding musl windows-gnu macOS FreeBSD etc. This has the side benefit of removing the #[cfg] in sys_common; only unix.rs has code related to the workaround now.",HOORAY,2018-01-22T12:35:58Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/47337,CLOSED,2018-01-10T21:23:29Z,2018-02-03T01:38:46Z,Enable ASan and TSan on FreeBSD (WIP),unrelentingtech,NA,NA,NA,HEART,2018-01-10T21:59:41Z,ararslan,NA https://github.com/rust-lang/rust/pull/47337,CLOSED,2018-01-10T21:23:29Z,2018-02-03T01:38:46Z,Enable ASan and TSan on FreeBSD (WIP),unrelentingtech,NA,NA,NA,HOORAY,2018-01-10T21:59:47Z,ararslan,NA https://github.com/rust-lang/rust/pull/47343,MERGED,2018-01-11T01:23:57Z,2018-01-12T23:28:24Z,Glued tokens can themselves be joint.,goffrie,2e0ad5af309c016986e6c81da181762e833c802f,1,Glued tokens can themselves be joint. When gluing two tokens the second of which is joint the result should also be joint. This fixes an issue with joining three `Dot` tokens to make a `DotDotDot` - the intermediate `DotDot` would not be joint and therefore we would not attempt to glue the last `Dot` token yielding `.. .` instead of `...`.,THUMBS_UP,2018-01-11T20:51:36Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47363,CLOSED,2018-01-11T20:39:50Z,2018-03-26T11:12:55Z,Adding Path.normalize() method,linclelinkpart5,NA,NA,NA,THUMBS_UP,2018-01-12T13:35:56Z,cristicbz,NA https://github.com/rust-lang/rust/pull/47363,CLOSED,2018-01-11T20:39:50Z,2018-03-26T11:12:55Z,Adding Path.normalize() method,linclelinkpart5,NA,NA,NA,THUMBS_UP,2018-01-24T01:13:17Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/47379,MERGED,2018-01-12T11:21:18Z,2018-02-22T14:23:03Z,Derive std::cmp::Reverse as Copy or Clone,da-x,96157ef8422298e66bcbf7dc1b2b28dd6d90b745,1,Derive std::cmp::Reverse as Copy or Clone If the type parameter is Copy or Clone then `Reverse` should be too.,THUMBS_UP,2018-01-13T00:26:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47387,MERGED,2018-01-12T16:06:29Z,2018-01-17T22:20:51Z,Report errors instead of panic!() when linkcheck encounters absolute paths,Rantanen,f7b48778b1472045bd8b7ee6aacdbf1487efe50b,1,Report errors instead of panic!(),HEART,2018-01-13T02:03:54Z,projektir,NA https://github.com/rust-lang/rust/pull/47398,MERGED,2018-01-12T21:47:53Z,2018-01-18T16:57:49Z,Switch to pulldown as default markdown renderer,GuillaumeGomez,f31204662b6d5ab343b901d9684ecda71e777cc0,1,Switch to pulldown as default markdown renderer,HOORAY,2018-01-12T22:38:27Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47398,MERGED,2018-01-12T21:47:53Z,2018-01-18T16:57:49Z,Switch to pulldown as default markdown renderer,GuillaumeGomez,f31204662b6d5ab343b901d9684ecda71e777cc0,1,Switch to pulldown as default markdown renderer,HOORAY,2018-01-13T00:14:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47398,MERGED,2018-01-12T21:47:53Z,2018-01-18T16:57:49Z,Switch to pulldown as default markdown renderer,GuillaumeGomez,f31204662b6d5ab343b901d9684ecda71e777cc0,1,Switch to pulldown as default markdown renderer,HOORAY,2018-01-13T17:18:58Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/47398,MERGED,2018-01-12T21:47:53Z,2018-01-18T16:57:49Z,Switch to pulldown as default markdown renderer,GuillaumeGomez,f31204662b6d5ab343b901d9684ecda71e777cc0,1,Switch to pulldown as default markdown renderer,HOORAY,2018-01-13T19:00:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/47398,MERGED,2018-01-12T21:47:53Z,2018-01-18T16:57:49Z,Switch to pulldown as default markdown renderer,GuillaumeGomez,f31204662b6d5ab343b901d9684ecda71e777cc0,1,Switch to pulldown as default markdown renderer,HOORAY,2018-01-13T19:23:52Z,bluss,NA https://github.com/rust-lang/rust/pull/47404,MERGED,2018-01-13T02:48:23Z,2018-01-17T22:20:51Z,"Standardize on ""re-export"" rather than ""reexport""",carols10cents,e168aa385b9afb6c84071a09910724bdde3dfc5f,26,Reexport -> re-export in prose and documentation comments,LAUGH,2018-01-13T18:01:18Z,kennytm,NA https://github.com/rust-lang/rust/pull/47414,MERGED,2018-01-13T13:47:58Z,2018-01-15T15:37:12Z,Enforce dashes in the unstable book file names,est31,38e2667584505a81fad8380f93d7de33578914fb,6,Enforce dashes in the unstable book file names Also rename the existing underscore using files to use dashes. Fixes #47394.,HOORAY,2018-01-15T16:30:42Z,carols10cents,NA https://github.com/rust-lang/rust/pull/47416,MERGED,2018-01-13T18:02:07Z,2018-01-14T00:42:26Z,Remove `impl Foo for .. {}` in favor `auto trait Foo {}`,petrochenkov,22598776b04cc947f001191b47c18d981b46eec7,4,Re-add support for `impl Trait for ..` to the parser,HEART,2018-01-13T19:54:15Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/47420,MERGED,2018-01-13T23:32:30Z,2018-01-27T22:41:50Z,Fix off-by-one spans in MIR borrowck errors,davidtwco,0bd96671f0312fdc1eb07885835e58d258f1f927,1,Fixed infinite loop issues and added some improved logging.,HEART,2018-01-13T23:52:14Z,estebank,NA https://github.com/rust-lang/rust/pull/47424,CLOSED,2018-01-14T09:46:39Z,2018-01-14T19:07:39Z,Extend macro name suggestion span,etaoins,NA,NA,NA,HEART,2018-01-14T14:24:12Z,Vlad-Shcherbina,vlad.shcherbina@gmail.com https://github.com/rust-lang/rust/pull/47426,MERGED,2018-01-14T17:16:26Z,2018-01-17T22:20:53Z,Add a default directory for -Zdump-mir-dir,varkor,394b95fdd671a8c9fd252f5288c88d5afba486c7,1,Fix test,THUMBS_UP,2018-01-14T17:27:44Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47426,MERGED,2018-01-14T17:16:26Z,2018-01-17T22:20:53Z,Add a default directory for -Zdump-mir-dir,varkor,394b95fdd671a8c9fd252f5288c88d5afba486c7,1,Fix test,THUMBS_UP,2018-01-14T18:15:27Z,kennytm,NA https://github.com/rust-lang/rust/pull/47427,MERGED,2018-01-14T17:43:35Z,2018-01-17T22:20:53Z,Add a Docker container for doing automated builds for CloudABI.,EdSchouten,dcf0cd0ac00a91afcc24e4c073dd99befa188091,1,Only enable CloudABI builds for x86-64 for now. We'll turn on other architectures if it turns out we have enough capacity.,THUMBS_UP,2018-01-15T11:22:20Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/47440,MERGED,2018-01-15T03:22:48Z,2018-01-23T19:56:57Z,Change the --unpretty flag to -Z unpretty,mark-i-m,ebfa6c709aecb12a164695912785643d916e75fb,8,Change the --unpretty flag to -Z unpretty -Z unpretty no longer requires -Z unstable-options. Also I mildly changed the syntax of the flag to match the other -Z flags. All uses of the flag take the form `unpretty=something` where something can either `string` or `string=string` (see the help messages of the CLI).,HEART,2018-01-16T00:19:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47443,MERGED,2018-01-15T06:17:44Z,2018-01-15T15:37:15Z,Remove leftover Rand stuff,FenrirWolf,1482afbbedfbbd6920b8cf05bd23ba30a36630ce,1,Remove leftover Rand stuff,THUMBS_UP,2018-01-15T09:41:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47444,MERGED,2018-01-15T08:24:10Z,2018-01-17T22:20:55Z,Don't include bang in macro replacement suggestion,etaoins,ecd47a91c7c5eb22fba5fcdec7fa8d78a8bcac51,4,"Don't include bang in macro replacement suggestion When we suggest the replacement for a macro we include the ""!"" in the suggested replacement but the span only contains the name of the macro itself. Using that replacement would cause a duplicate ""!"" in the resulting code. I originally tried to extend the span to be replaced by 1 byte in rust-lang/rust#47424. However @zackmdavis pointed out that there can be whitespace between the macro name and the bang. Instead just remove the bang from the suggested replacement. Fixes #47418",THUMBS_UP,2018-01-15T13:28:32Z,killercup,NA https://github.com/rust-lang/rust/pull/47458,MERGED,2018-01-15T16:30:10Z,2018-01-17T22:20:56Z,Allow a trailing comma in lint_array,mark-i-m,f81c2ded5e7f8d3288fa0daccb8c92396e9b7e14,3,Allow a trailing comma in lint_array; fix #47428,THUMBS_UP,2018-01-15T20:36:06Z,killercup,NA https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-15T17:29:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-15T17:38:34Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-15T17:48:37Z,estebank,NA https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-15T19:26:53Z,lqd,NA https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-15T20:03:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/47460,MERGED,2018-01-15T17:22:00Z,2018-01-26T20:34:07Z,Add ./x.py check src/{libstd libtest librustc},Mark-Simulacrum,6aeb1cfb64ea04e334d296bf9a47c659116c96bf,7,Add ./x.py check src/{libstd libtest rustc}. This currently only supports a limited subset of the full compilation but is likely 90% of what people will want and is possible without building a full compiler (i.e. running LLVM). In theory this means that contributors who don't want to build LLVM now have an easy way to compile locally though running tests won't work.,HOORAY,2018-01-19T20:31:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/47465,MERGED,2018-01-15T21:02:53Z,2018-02-02T07:05:24Z,Include space in suggestion `mut` in bindings,estebank,df412ce2083308cbe7c21ce2fc5622bfa8518993,1,Change offset to `0`,THUMBS_UP,2018-01-16T10:32:53Z,killercup,NA https://github.com/rust-lang/rust/pull/47487,MERGED,2018-01-16T09:17:53Z,2018-01-17T22:20:59Z,"implement ""only-"" for test headers",Pulkit07,bd70f0fa66853125797bfa4cdea37b9ca2120159,1,add a comment about parsing only prefix in header.rs,THUMBS_UP,2018-01-24T21:04:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47507,MERGED,2018-01-17T01:24:30Z,2018-01-22T23:32:29Z,rustc: Lower link args to `@`-files on Windows more,alexcrichton,66366f96267949cf41a992bec477e04763c42565,5,"rustc: Lower link args to `@`-files on Windows more When spawning a linker rustc has historically been known to blow OS limits for the command line being too large notably on Windows. This is especially true of incremental compilation where there can be dozens of object files per compilation. The compiler currently has logic for detecting a failure to spawn and instead passing arguments via a file instead but this failure detection only triggers if a process actually fails to spawn. Unfortunately on Windows we've got something else to worry about which is `cmd.exe`. The compiler may be running a linker through `cmd.exe` where `cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`. Moreso rustc actually succeeds in spawning `cmd.exe` today it's just that after it's running `cmd.exe` fails to spawn its child which rustc doesn't currently detect. Consequently this commit updates the logic for the spawning the linker on Windows to instead have a heuristic to see if we need to pass arguments via a file. This heuristic is an overly pessimistic and ""inaccurate"" calculation which just calls `len` on a bunch of `OsString` instances (where `len` is not precisely the length in u16 elements). This number when exceeding the 6k threshold will force rustc to always pass arguments through a file. This strategy should avoid us trying to parse the output on Windows of the linker to see if it successfully spawned yet failed to actually sub-spawn the linker. We may just be passing arguments through files a little more commonly now... The motivation for this commit was a recent bug in Gecko [1] when beta testing notably when incremental compilation was enabled it blew out the limit on `cmd.exe`. This commit will also fix #46999 as well though as emscripten uses a bat script as well (and we're blowing the limit there). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886 Closes #46999",HOORAY,2018-01-17T10:49:31Z,Diggsey,NA https://github.com/rust-lang/rust/pull/47507,MERGED,2018-01-17T01:24:30Z,2018-01-22T23:32:29Z,rustc: Lower link args to `@`-files on Windows more,alexcrichton,66366f96267949cf41a992bec477e04763c42565,5,"rustc: Lower link args to `@`-files on Windows more When spawning a linker rustc has historically been known to blow OS limits for the command line being too large notably on Windows. This is especially true of incremental compilation where there can be dozens of object files per compilation. The compiler currently has logic for detecting a failure to spawn and instead passing arguments via a file instead but this failure detection only triggers if a process actually fails to spawn. Unfortunately on Windows we've got something else to worry about which is `cmd.exe`. The compiler may be running a linker through `cmd.exe` where `cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`. Moreso rustc actually succeeds in spawning `cmd.exe` today it's just that after it's running `cmd.exe` fails to spawn its child which rustc doesn't currently detect. Consequently this commit updates the logic for the spawning the linker on Windows to instead have a heuristic to see if we need to pass arguments via a file. This heuristic is an overly pessimistic and ""inaccurate"" calculation which just calls `len` on a bunch of `OsString` instances (where `len` is not precisely the length in u16 elements). This number when exceeding the 6k threshold will force rustc to always pass arguments through a file. This strategy should avoid us trying to parse the output on Windows of the linker to see if it successfully spawned yet failed to actually sub-spawn the linker. We may just be passing arguments through files a little more commonly now... The motivation for this commit was a recent bug in Gecko [1] when beta testing notably when incremental compilation was enabled it blew out the limit on `cmd.exe`. This commit will also fix #46999 as well though as emscripten uses a bat script as well (and we're blowing the limit there). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886 Closes #46999",HOORAY,2018-01-17T10:54:42Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/47507,MERGED,2018-01-17T01:24:30Z,2018-01-22T23:32:29Z,rustc: Lower link args to `@`-files on Windows more,alexcrichton,66366f96267949cf41a992bec477e04763c42565,5,"rustc: Lower link args to `@`-files on Windows more When spawning a linker rustc has historically been known to blow OS limits for the command line being too large notably on Windows. This is especially true of incremental compilation where there can be dozens of object files per compilation. The compiler currently has logic for detecting a failure to spawn and instead passing arguments via a file instead but this failure detection only triggers if a process actually fails to spawn. Unfortunately on Windows we've got something else to worry about which is `cmd.exe`. The compiler may be running a linker through `cmd.exe` where `cmd.exe` has a limit of 8192 on the command line vs 32k on `CreateProcess`. Moreso rustc actually succeeds in spawning `cmd.exe` today it's just that after it's running `cmd.exe` fails to spawn its child which rustc doesn't currently detect. Consequently this commit updates the logic for the spawning the linker on Windows to instead have a heuristic to see if we need to pass arguments via a file. This heuristic is an overly pessimistic and ""inaccurate"" calculation which just calls `len` on a bunch of `OsString` instances (where `len` is not precisely the length in u16 elements). This number when exceeding the 6k threshold will force rustc to always pass arguments through a file. This strategy should avoid us trying to parse the output on Windows of the linker to see if it successfully spawned yet failed to actually sub-spawn the linker. We may just be passing arguments through files a little more commonly now... The motivation for this commit was a recent bug in Gecko [1] when beta testing notably when incremental compilation was enabled it blew out the limit on `cmd.exe`. This commit will also fix #46999 as well though as emscripten uses a bat script as well (and we're blowing the limit there). [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1430886 Closes #46999",HOORAY,2018-01-19T09:53:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47508,MERGED,2018-01-17T01:38:47Z,2018-01-21T09:17:42Z,add Rust By Example to the bookshelf,QuietMisdreavus,0e1ecbed8364716d131a466b3e3f09e74e52385e,1,add Rust By Example to the bookshelf,HEART,2018-01-17T01:45:59Z,projektir,NA https://github.com/rust-lang/rust/pull/47508,MERGED,2018-01-17T01:38:47Z,2018-01-21T09:17:42Z,add Rust By Example to the bookshelf,QuietMisdreavus,0e1ecbed8364716d131a466b3e3f09e74e52385e,1,add Rust By Example to the bookshelf,HEART,2018-01-17T02:19:54Z,Havvy,NA https://github.com/rust-lang/rust/pull/47508,MERGED,2018-01-17T01:38:47Z,2018-01-21T09:17:42Z,add Rust By Example to the bookshelf,QuietMisdreavus,0e1ecbed8364716d131a466b3e3f09e74e52385e,1,add Rust By Example to the bookshelf,HEART,2018-01-17T04:31:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47520,MERGED,2018-01-17T16:40:26Z,2018-01-18T16:57:55Z,Use File::metadata instead of fs::metadata to choose buffer size,mbrubeck,e9fdee8818f5c089013b9c8604e183b1cbd816ad,1,Use File::metadata instead of fs::metadata to choose buffer size This replaces a `stat` syscall with `fstat` or similar which can be faster. Fixes #47519.,HEART,2018-01-17T19:34:00Z,etaoins,NA https://github.com/rust-lang/rust/pull/47529,MERGED,2018-01-17T23:02:01Z,2018-01-26T20:34:09Z,track recursion limit when expanding existential impl trait,nikomatsakis,072c3daa4cb6e1a8958ad9d61ebc7e062d570eac,4,track recursion limit when expanding existential impl trait,THUMBS_UP,2018-02-01T21:02:41Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/47534,MERGED,2018-01-18T04:18:13Z,2018-01-25T18:17:04Z,On missing method do not suggest private traits,estebank,4121ddb041aaa20769c8b31bc6496906c6330170,6,Do not suggest private traits that have missing method When encountering a method call for an ADT that doesn't have any implementation of it we search for traits that could be implemented that do have that method. Filter out private non-local traits that would not be able to be implemented. This doesn't account for public traits that are in a private scope but works as a first approximation and is a more correct behavior than the current one.,HEART,2018-01-24T20:21:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47540,MERGED,2018-01-18T11:50:28Z,2018-02-01T07:33:48Z,Add approximate suggestions for rustfix,Manishearth,540f95d9fad41a605e4c8b898d77f47374a76cbd,4,Add internal-only rustc_serialize_exclude_null attribute for making the field only exist in the json if the flag is passed,HEART,2018-01-18T11:55:44Z,killercup,NA https://github.com/rust-lang/rust/pull/47540,MERGED,2018-01-18T11:50:28Z,2018-02-01T07:33:48Z,Add approximate suggestions for rustfix,Manishearth,540f95d9fad41a605e4c8b898d77f47374a76cbd,4,Add internal-only rustc_serialize_exclude_null attribute for making the field only exist in the json if the flag is passed,HEART,2018-02-01T16:46:47Z,estebank,NA https://github.com/rust-lang/rust/pull/47540,MERGED,2018-01-18T11:50:28Z,2018-02-01T07:33:48Z,Add approximate suggestions for rustfix,Manishearth,540f95d9fad41a605e4c8b898d77f47374a76cbd,4,Add internal-only rustc_serialize_exclude_null attribute for making the field only exist in the json if the flag is passed,HEART,2018-02-07T06:57:47Z,llogiq,NA https://github.com/rust-lang/rust/pull/47540,MERGED,2018-01-18T11:50:28Z,2018-02-01T07:33:48Z,Add approximate suggestions for rustfix,Manishearth,540f95d9fad41a605e4c8b898d77f47374a76cbd,4,Add internal-only rustc_serialize_exclude_null attribute for making the field only exist in the json if the flag is passed,HEART,2018-02-09T07:30:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47544,MERGED,2018-01-18T14:53:54Z,2018-02-18T06:02:37Z,Relax termination_trait's error bound,U007D,7948afdc53cabf9330662ec894bf668839880a3c,11,changed termination_trait's bound from Error to Debug; added compiletest header command and appropriate tests,THUMBS_UP,2018-01-18T18:30:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/47544,MERGED,2018-01-18T14:53:54Z,2018-02-18T06:02:37Z,Relax termination_trait's error bound,U007D,7948afdc53cabf9330662ec894bf668839880a3c,11,changed termination_trait's bound from Error to Debug; added compiletest header command and appropriate tests,THUMBS_UP,2018-01-19T09:27:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47547,MERGED,2018-01-18T15:29:07Z,2018-02-10T22:40:19Z,Document the behaviour of infinite iterators on potentially-computable methods,varkor,f129374d11d51ca23d85bc678fbc1ed4e7082ab1,1,Use repeat instead of RangeFrom,HEART,2018-01-19T09:48:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47548,MERGED,2018-01-18T15:41:40Z,2018-01-21T22:38:26Z,"[beta] Turn back on ""fat"" LTO by default",alexcrichton,c4771ecbc72a2e61943a1f79fcdf8378db622aa0,1,"[beta] Turn back on ""fat"" LTO by default This commit reverts a small portion of the switch to ThinLTO by default which changed the meaning of `-C lto` from ""put the whole crate graph into one codegen unit"" to ""perform ThinLTO over the whole crate graph"". This backport has no corresponding commit on master as #47521 is making the same change but in a slightly different manner. This commit is intended to be a surgical change with low impact on beta. Closes #47409",THUMBS_UP,2018-01-19T02:14:02Z,gamozolabs,NA https://github.com/rust-lang/rust/pull/47549,MERGED,2018-01-18T15:55:18Z,2018-01-23T19:57:00Z,Add regression test for #29723,Manishearth,67f922bfcceb4219c4c65e1dfaaca9368337f46a,1,fix line,HEART,2018-01-18T22:41:55Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47549,MERGED,2018-01-18T15:55:18Z,2018-01-23T19:57:00Z,Add regression test for #29723,Manishearth,67f922bfcceb4219c4c65e1dfaaca9368337f46a,1,fix line,HEART,2018-01-21T07:15:36Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/47549,MERGED,2018-01-18T15:55:18Z,2018-01-23T19:57:00Z,Add regression test for #29723,Manishearth,67f922bfcceb4219c4c65e1dfaaca9368337f46a,1,fix line,HEART,2018-04-24T20:06:41Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/47552,MERGED,2018-01-18T19:55:55Z,2018-01-31T23:50:10Z,Specialize StepBy::nth,oberien,4a0da4cf2c7a2b5903fd1b8bc124f8963ce1b535,1,Spacing,THUMBS_UP,2018-01-20T00:13:17Z,varkor,NA https://github.com/rust-lang/rust/pull/47558,MERGED,2018-01-18T22:45:24Z,2018-01-23T19:57:02Z,Add rustc-args option to test runner,spastorino,db41f1e1cfa0d817a96830fecbdcf70d249597e7,2,Add rustc-args option to test runner,HOORAY,2018-01-18T22:57:19Z,qmx,qmx@qmx.me https://github.com/rust-lang/rust/pull/47558,MERGED,2018-01-18T22:45:24Z,2018-01-23T19:57:02Z,Add rustc-args option to test runner,spastorino,db41f1e1cfa0d817a96830fecbdcf70d249597e7,2,Add rustc-args option to test runner,HOORAY,2018-01-18T23:19:31Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47562,MERGED,2018-01-19T02:37:01Z,2018-08-20T11:45:47Z,Add the identity function as core::convert::identity,Centril,86641d97b23674a7b0df8523a8684e8b02bf0b33,1,core::convert::identity: fix issue number to #53500,THUMBS_UP,2018-08-22T18:06:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47574,MERGED,2018-01-19T13:05:16Z,2018-03-10T13:31:08Z,"Show the used type variable when issuing a ""can't use type parameters from outer function"" error message",zilbuz,0e68bb97285a1ade22cf6e68103dc54fb75db43f,8,Update tests,HEART,2018-01-19T19:11:23Z,estebank,NA https://github.com/rust-lang/rust/pull/47603,MERGED,2018-01-19T22:45:18Z,2018-01-30T15:08:08Z,Run rustfmt and add doc comments to libsyntax/ext/tt/quoted.rs,mark-i-m,576294237b10fff22bc462398ff7d06fffa05bd0,1,fix typos,THUMBS_UP,2018-01-29T22:55:49Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47610,MERGED,2018-01-20T06:00:19Z,2018-01-23T19:57:03Z,LLVM5: Update DW_OP_plus to DW_OP_plus_uconst,cuviper,e2f6b280ea13e48bff86254549988e61eee37139,3,Update DW_OP_plus to DW_OP_plus_uconst LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`. In the DWARF standard this adds two items on the expressions stack. LLVM's behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant that follows the op. The patch series starting with [D33892] switched to the standard DWARF interpretation so we need to follow. [D33892]: https://reviews.llvm.org/D33892,THUMBS_UP,2018-01-21T11:55:23Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/47620,MERGED,2018-01-20T21:17:28Z,2018-01-23T16:13:33Z,Multiple themes for rustdoc,GuillaumeGomez,5b8504401c7590130eb01a34155b12c26881b0b1,3,Fasten even more theme switch,HOORAY,2018-01-20T21:44:54Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/47620,MERGED,2018-01-20T21:17:28Z,2018-01-23T16:13:33Z,Multiple themes for rustdoc,GuillaumeGomez,5b8504401c7590130eb01a34155b12c26881b0b1,3,Fasten even more theme switch,HEART,2018-01-23T03:12:15Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47620,MERGED,2018-01-20T21:17:28Z,2018-01-23T16:13:33Z,Multiple themes for rustdoc,GuillaumeGomez,5b8504401c7590130eb01a34155b12c26881b0b1,3,Fasten even more theme switch,HEART,2018-01-23T18:59:36Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47620,MERGED,2018-01-20T21:17:28Z,2018-01-23T16:13:33Z,Multiple themes for rustdoc,GuillaumeGomez,5b8504401c7590130eb01a34155b12c26881b0b1,3,Fasten even more theme switch,HEART,2018-01-28T13:19:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47626,MERGED,2018-01-21T00:47:21Z,2018-01-26T20:34:13Z,rustc_trans: remove an unwrap by replacing a bool with Result.,eddyb,51fe2fe07fc81e177fe9b822bc4db91e51837e45,1,rustc_trans: remove an unwrap by replacing a bool with Result.,HEART,2018-01-21T01:26:43Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-21T17:05:17Z,killercup,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-21T20:05:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-21T21:20:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-21T21:46:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-21T23:14:04Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-24T10:06:58Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-24T16:06:51Z,jplatte,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-25T16:01:06Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-25T19:24:09Z,estebank,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-01-27T23:22:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-02-02T04:15:20Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-02-07T05:25:42Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-02-13T20:37:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-02-22T13:42:47Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-01T00:48:02Z,remexre,nathan@remexre.xyz https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-02T10:02:55Z,kdy1,kdy1997.dev@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-12T07:38:00Z,sinkuu,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-18T05:46:11Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-21T09:28:59Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-21T09:41:47Z,IBUzPE9,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-21T10:26:06Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-21T11:53:26Z,mistodon,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-21T16:31:48Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-23T09:19:37Z,bash,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-03-26T16:12:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-04-04T21:48:15Z,boozook,NA https://github.com/rust-lang/rust/pull/47630,MERGED,2018-01-21T08:52:03Z,2018-03-15T02:16:55Z,Stabilise feature(never_type). Introduce feature(exhaustive_patterns),canndrew,a8a0c691914b72d1ca54057914b4cee2bd097ae3,1,fix ui test error again,HOORAY,2018-05-16T02:51:38Z,bb010g,NA https://github.com/rust-lang/rust/pull/47650,CLOSED,2018-01-22T04:11:15Z,2018-06-30T20:23:10Z,Implement unsized unions,mikeyhew,NA,NA,NA,HOORAY,2018-03-13T01:34:11Z,cramertj,NA https://github.com/rust-lang/rust/pull/47650,CLOSED,2018-01-22T04:11:15Z,2018-06-30T20:23:10Z,Implement unsized unions,mikeyhew,NA,NA,NA,THUMBS_UP,2019-08-25T16:22:37Z,ConnorGray,NA https://github.com/rust-lang/rust/pull/47652,MERGED,2018-01-22T05:30:03Z,2018-01-26T20:34:14Z,Add `-Z teach` flag to provide extended diagnostic help,estebank,2b737334961916daee73ea018eea877f389ad0dc,1,Add description to field and method,HEART,2018-01-22T10:49:50Z,killercup,NA https://github.com/rust-lang/rust/pull/47652,MERGED,2018-01-22T05:30:03Z,2018-01-26T20:34:14Z,Add `-Z teach` flag to provide extended diagnostic help,estebank,2b737334961916daee73ea018eea877f389ad0dc,1,Add description to field and method,HEART,2018-01-22T15:30:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/47652,MERGED,2018-01-22T05:30:03Z,2018-01-26T20:34:14Z,Add `-Z teach` flag to provide extended diagnostic help,estebank,2b737334961916daee73ea018eea877f389ad0dc,1,Add description to field and method,HEART,2018-01-31T16:21:39Z,jryans,jryans@gmail.com https://github.com/rust-lang/rust/pull/47652,MERGED,2018-01-22T05:30:03Z,2018-01-26T20:34:14Z,Add `-Z teach` flag to provide extended diagnostic help,estebank,2b737334961916daee73ea018eea877f389ad0dc,1,Add description to field and method,HEART,2018-01-31T16:55:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47652,MERGED,2018-01-22T05:30:03Z,2018-01-26T20:34:14Z,Add `-Z teach` flag to provide extended diagnostic help,estebank,2b737334961916daee73ea018eea877f389ad0dc,1,Add description to field and method,HEART,2018-02-14T18:02:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47657,MERGED,2018-01-22T15:35:16Z,2018-02-11T08:21:32Z,Emit data::Impl in save-analysis,algesten,9a6afa8f670af6da28a62c551d9df1fbe51b7434,5,Emit data::Impl in save-analysis,HEART,2018-01-22T15:52:33Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T02:24:05Z,est31,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T05:46:51Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T08:40:17Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T09:14:58Z,oli-obk,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T09:15:28Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T09:52:01Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-23T09:56:04Z,lqd,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-24T16:29:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-24T16:35:22Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-25T16:18:27Z,CryZe,NA https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-31T16:55:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47671,MERGED,2018-01-23T01:49:23Z,2018-01-28T06:20:29Z,rustc: Load the `rustc_trans` crate at runtime,alexcrichton,884715c65420141dc06753f242a224462b120109,33,rustc: Load the `rustc_trans` crate at runtime Building on the work of # 45684 this commit updates the compiler to unconditionally load the `rustc_trans` crate at runtime instead of linking to it at compile time. The end goal of this work is to implement # 46819 where rustc will have multiple backends available to it to load. This commit starts off by removing the `extern crate rustc_trans` from the driver. This involved moving some miscellaneous functionality into the `TransCrate` trait and also required an implementation of how to locate and load the trans backend. This ended up being a little tricky because the sysroot isn't always the right location (for example `--sysroot` arguments) so some extra code was added as well to probe a directory relative to the current dll (the rustc_driver dll). Rustbuild has been updated accordingly as well to have a separate compilation invocation for the `rustc_trans` crate and assembly it accordingly into the sysroot. Finally the distribution logic for the `rustc` package was also updated to slurp up the trans backends folder. A number of assorted fallout changes were included here as well to ensure tests pass and such and they should all be commented inline.,HOORAY,2018-01-31T22:00:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47672,MERGED,2018-01-23T02:08:02Z,2018-01-23T19:57:08Z,rustdoc: Show when traits are auto traits,ollie27,04a884726a5a332aefd0af96c8d702b0830e5375,7,rustdoc: Show when traits are auto traits,HOORAY,2018-01-31T22:14:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47676,MERGED,2018-01-23T06:48:24Z,2018-01-26T06:58:20Z,Update rls,topecongiro,8636d0142b80375680eaedb4d67b079c2f7f5284,2,Update rls,HEART,2018-01-26T04:05:05Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/47676,MERGED,2018-01-23T06:48:24Z,2018-01-26T06:58:20Z,Update rls,topecongiro,8636d0142b80375680eaedb4d67b079c2f7f5284,2,Update rls,HEART,2018-01-26T04:05:56Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47679,MERGED,2018-01-23T09:26:30Z,2018-01-25T18:17:10Z,Remove broken redundant backtrace hint,etaoins,5de8e040d2ed8f3d9da79a4f12b9ece51c352f2e,1,Remove broken redundant backtrace hint When the compiler driver panics it attempts to show a hint about using `RUST_BACKTRACE`. However the logic is currently reversed to the hint is only shown if `RUST_BACKTRACE` is *already* set: ```shell > RUST_BACKTRACE=1 rustc /dev/null --crate-type proc-macro error: internal compiler error: unexpected panic ... note: run with `RUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'attempt to subtract with overflow' librustc_errors/emitter.rs:287:49 note: Some details are omitted run with `RUST_BACKTRACE=full` for a verbose backtrace. > RUST_BACKTRACE=0 rustc /dev/null --crate-type proc-macro error: internal compiler error: unexpected panic ... thread 'rustc' panicked at 'attempt to subtract with overflow' librustc_errors/emitter.rs:287:49 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` As the `panic` itself already has a working `RUST_BACKTRACE` hint just remove the broken duplicate hint entirely.,LAUGH,2018-01-23T18:41:48Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/47681,CLOSED,2018-01-23T15:53:10Z,2018-01-24T00:37:25Z,[WIP] Upgrade to and test LLVM 6,alexcrichton,NA,NA,NA,HOORAY,2018-01-23T17:05:55Z,est31,NA https://github.com/rust-lang/rust/pull/47681,CLOSED,2018-01-23T15:53:10Z,2018-01-24T00:37:25Z,[WIP] Upgrade to and test LLVM 6,alexcrichton,NA,NA,NA,HEART,2018-01-23T17:05:56Z,est31,NA https://github.com/rust-lang/rust/pull/47681,CLOSED,2018-01-23T15:53:10Z,2018-01-24T00:37:25Z,[WIP] Upgrade to and test LLVM 6,alexcrichton,NA,NA,NA,HOORAY,2018-01-23T17:38:10Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/47681,CLOSED,2018-01-23T15:53:10Z,2018-01-24T00:37:25Z,[WIP] Upgrade to and test LLVM 6,alexcrichton,NA,NA,NA,HOORAY,2018-01-23T19:43:35Z,mrhota,NA https://github.com/rust-lang/rust/pull/47681,CLOSED,2018-01-23T15:53:10Z,2018-01-24T00:37:25Z,[WIP] Upgrade to and test LLVM 6,alexcrichton,NA,NA,NA,HEART,2018-01-23T19:44:52Z,estebank,NA https://github.com/rust-lang/rust/pull/47689,MERGED,2018-01-23T22:53:10Z,2018-02-25T04:52:09Z,Fix borrow checker unsoundness with unions ,davidtwco,e6376a15b4f22bc296a832d232937add7e04511d,2,Added test for #45157,HEART,2018-02-20T18:59:00Z,estebank,NA https://github.com/rust-lang/rust/pull/47701,MERGED,2018-01-24T09:34:32Z,2018-01-26T20:34:19Z,Fixes for intra-doc-links,Manishearth,08ca4fd1358e172de351df475ea55b4e52605a21,1,Add tests,THUMBS_UP,2018-01-25T08:46:23Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/47702,MERGED,2018-01-24T09:48:28Z,2018-01-25T18:17:12Z,Fix into() cast paren check precedence,etaoins,65b1e86aed22bfcd3a4ce27da9be2b14c7d5738e,3,Fix into() cast paren check precedence As discussed in #47699 the logic for determining if an expression needs parenthesis when suggesting an `.into()` cast is incorrect. Two broken examples from nightly are: ``` error[E0308]: mismatched types --> main.rs:4:10 | 4 | test(foo as i8); | ^^^^^^^^^ expected i32 found i8 help: you can cast an `i8` to `i32` which will sign-extend the source value | 4 | test(foo as i8.into()); | ``` ``` error[E0308]: mismatched types --> main.rs:4:10 | 4 | test(*foo); | ^^^^ expected i32 found i8 help: you can cast an `i8` to `i32` which will sign-extend the source value | 4 | test(*foo.into()); | ``` As suggested by @petrochenkov switch the precedence check to PREC_POSTFIX. This catches both `as` and unary operators. Fixes #47699.,HEART,2018-01-25T18:22:29Z,estebank,NA https://github.com/rust-lang/rust/pull/47705,MERGED,2018-01-24T12:18:30Z,2018-01-26T20:34:20Z,Fix ICE when use trees have multiple empty nested groups,pietroalbini,5faba281ad08e6d57dc015f9547e18256eb8247f,2,Fix ICE when use trees have multiple empty nested groups,THUMBS_UP,2018-01-24T13:02:20Z,dwrensha,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T07:37:47Z,est31,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T09:11:29Z,lqd,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T09:25:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T09:29:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T10:50:28Z,RanHum,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T11:59:06Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T18:25:10Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T18:47:32Z,estebank,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T18:59:42Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T19:07:02Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T21:53:10Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-25T21:56:59Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-01-26T14:59:27Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-02-09T21:21:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HEART,2018-02-09T21:22:10Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/47730,MERGED,2018-01-25T04:25:08Z,2018-01-29T07:50:39Z,rustc: Split Emscripten to a separate codegen backend ,alexcrichton,c6daea7c9a7d4be88e1ae8d54d992937fcfe24fa,23,rustc: Split Emscripten to a separate codegen backend This commit introduces a separately compiled backend for Emscripten avoiding compiling the `JSBackend` target in the main LLVM codegen backend. This builds on the foundation provided by #47671 to create a new codegen backend dedicated solely to Emscripten removing the `JSBackend` of the main codegen backend in the process. A new field was added to each target for this commit which specifies the backend to use for translation the default being `llvm` which is the main backend that we use. The Emscripten targets specify an `emscripten` backend instead of the main `llvm` one. There's a whole bunch of consequences of this change but I'll try to enumerate them here: * A *second* LLVM submodule was added in this commit. The main LLVM submodule will soon start to drift from the Emscripten submodule but currently they're both at the same revision. * Logic was added to rustbuild to *not* build the Emscripten backend by default. This is gated behind a `--enable-emscripten` flag to the configure script. By default users should neither check out the emscripten submodule nor compile it. * The `init_repo.sh` script was updated to fetch the Emscripten submodule from GitHub the same way we do the main LLVM submodule (a tarball fetch). * The Emscripten backend turned off by default is still turned on for a number of targets on CI. We'll only be shipping an Emscripten backend with Tier 1 platforms though. All cross-compiled platforms will not be receiving an Emscripten backend yet. This commit means that when you download the `rustc` package in Rustup for Tier 1 platforms you'll be receiving two trans backends one for Emscripten and one that's the general LLVM backend. If you never compile for Emscripten you'll never use the Emscripten backend so we may update this one day to only download the Emscripten backend when you add the Emscripten target. For now though it's just an extra 10MB gzip'd. Closes #46819,HOORAY,2018-02-14T06:55:33Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/47732,MERGED,2018-01-25T05:25:48Z,2018-01-30T15:08:12Z,Run rustfmt and add doc comments to libsyntax/ext/tt/macro_parser.rs,mark-i-m,2184400be7f6b695792af7ddde14482f3e72f1e1,1,Update comment,HOORAY,2018-01-26T21:17:33Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/47732,MERGED,2018-01-25T05:25:48Z,2018-01-30T15:08:12Z,Run rustfmt and add doc comments to libsyntax/ext/tt/macro_parser.rs,mark-i-m,2184400be7f6b695792af7ddde14482f3e72f1e1,1,Update comment,HOORAY,2018-01-29T22:20:35Z,jseyfried,NA https://github.com/rust-lang/rust/pull/47743,MERGED,2018-01-25T16:21:09Z,2018-01-26T20:34:23Z,rustc: SIMD types use pointers in Rust's ABI,alexcrichton,502de01ff40d37d3e6b419c3931a23284ce1a4e4,3,"rustc: SIMD types use pointers in Rust's ABI This commit changes the ABI of SIMD types in the ""Rust"" ABI to unconditionally be passed via pointers instead of being passed as immediates. This should fix a longstanding issue #44367 where SIMD-using programs ended up showing very odd behavior at runtime because the ABI between functions was mismatched. As a bit of a recap this is sort of an LLVM bug and sort of an LLVM feature (today's behavior). LLVM will generate code for a function solely looking at the function it's generating including calls to other functions. Let's then say you've got something that looks like: ```llvm define void @foo() { ; no target features enabled call void @bar( zeroinitializer) ret void } define void @bar() #0 { ; enables the AVX feature ... } ``` LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo` doesn't have access to these registers. Instead it's generated with emulation that uses two 128-bit registers. The `bar` function on the other hand will expect its argument in an AVX register (as it has AVX enabled). This means we've got a codegen problem! Comments on #44367 have some more contexutal information but the crux of the issue is that if we want SIMD to work in general we'll need to ensure that whenever a function calls another they ABI of the arguments being passed is in agreement. One possible solution to this would be to insert ""shim functions"" where whenever a `target_feature` mismatch is detected the compiler inserts a shim function where you pass arguments via memory to the shim and then the shim loads the values and calls the target function (where the shim and the target have the same target features enabled). This unfortunately is quite nontrivial to implement in rustc today (especially when accounting for function pointers and such). This commit takes a different solution *always* passing SIMD arguments through memory instead of passing as immediates. This strategy solves the problem at the LLVM layer because the ABI between two functions never uses SIMD registers. This also shouldn't be a hit to performance because SIMD performance is thought to often rely on inlining anyway where a `call` instruction even if using SIMD registers would be disastrous to performance regardless. LLVM should then be more than capable of fixing all our memory usage to use registers instead after enough inlining has been performed. Note that there's a few caveats to this commit though: * The ""platform intrinsic"" ABI is omitted from ""always pass via memory"". This ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc need to have the arguments as an immediate. * Additionally this commit does *not* fix the `extern` (""C"") ABI. This means that the bug in #44367 can still happen when using non-Rust-ABI functions. My hope is that before stabilization we can ban and/or warn about SIMD types in these functions (as AFAIK there's not much motivation to belong there anyway) but I'll leave that for a later commit and if this is merged I'll file a follow-up issue. All in all this... Closes #44367",THUMBS_UP,2018-01-25T16:30:10Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/47743,MERGED,2018-01-25T16:21:09Z,2018-01-26T20:34:23Z,rustc: SIMD types use pointers in Rust's ABI,alexcrichton,502de01ff40d37d3e6b419c3931a23284ce1a4e4,3,"rustc: SIMD types use pointers in Rust's ABI This commit changes the ABI of SIMD types in the ""Rust"" ABI to unconditionally be passed via pointers instead of being passed as immediates. This should fix a longstanding issue #44367 where SIMD-using programs ended up showing very odd behavior at runtime because the ABI between functions was mismatched. As a bit of a recap this is sort of an LLVM bug and sort of an LLVM feature (today's behavior). LLVM will generate code for a function solely looking at the function it's generating including calls to other functions. Let's then say you've got something that looks like: ```llvm define void @foo() { ; no target features enabled call void @bar( zeroinitializer) ret void } define void @bar() #0 { ; enables the AVX feature ... } ``` LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo` doesn't have access to these registers. Instead it's generated with emulation that uses two 128-bit registers. The `bar` function on the other hand will expect its argument in an AVX register (as it has AVX enabled). This means we've got a codegen problem! Comments on #44367 have some more contexutal information but the crux of the issue is that if we want SIMD to work in general we'll need to ensure that whenever a function calls another they ABI of the arguments being passed is in agreement. One possible solution to this would be to insert ""shim functions"" where whenever a `target_feature` mismatch is detected the compiler inserts a shim function where you pass arguments via memory to the shim and then the shim loads the values and calls the target function (where the shim and the target have the same target features enabled). This unfortunately is quite nontrivial to implement in rustc today (especially when accounting for function pointers and such). This commit takes a different solution *always* passing SIMD arguments through memory instead of passing as immediates. This strategy solves the problem at the LLVM layer because the ABI between two functions never uses SIMD registers. This also shouldn't be a hit to performance because SIMD performance is thought to often rely on inlining anyway where a `call` instruction even if using SIMD registers would be disastrous to performance regardless. LLVM should then be more than capable of fixing all our memory usage to use registers instead after enough inlining has been performed. Note that there's a few caveats to this commit though: * The ""platform intrinsic"" ABI is omitted from ""always pass via memory"". This ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc need to have the arguments as an immediate. * Additionally this commit does *not* fix the `extern` (""C"") ABI. This means that the bug in #44367 can still happen when using non-Rust-ABI functions. My hope is that before stabilization we can ban and/or warn about SIMD types in these functions (as AFAIK there's not much motivation to belong there anyway) but I'll leave that for a later commit and if this is merged I'll file a follow-up issue. All in all this... Closes #44367",HOORAY,2018-01-25T17:33:27Z,AdamNiederer,NA https://github.com/rust-lang/rust/pull/47743,MERGED,2018-01-25T16:21:09Z,2018-01-26T20:34:23Z,rustc: SIMD types use pointers in Rust's ABI,alexcrichton,502de01ff40d37d3e6b419c3931a23284ce1a4e4,3,"rustc: SIMD types use pointers in Rust's ABI This commit changes the ABI of SIMD types in the ""Rust"" ABI to unconditionally be passed via pointers instead of being passed as immediates. This should fix a longstanding issue #44367 where SIMD-using programs ended up showing very odd behavior at runtime because the ABI between functions was mismatched. As a bit of a recap this is sort of an LLVM bug and sort of an LLVM feature (today's behavior). LLVM will generate code for a function solely looking at the function it's generating including calls to other functions. Let's then say you've got something that looks like: ```llvm define void @foo() { ; no target features enabled call void @bar( zeroinitializer) ret void } define void @bar() #0 { ; enables the AVX feature ... } ``` LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo` doesn't have access to these registers. Instead it's generated with emulation that uses two 128-bit registers. The `bar` function on the other hand will expect its argument in an AVX register (as it has AVX enabled). This means we've got a codegen problem! Comments on #44367 have some more contexutal information but the crux of the issue is that if we want SIMD to work in general we'll need to ensure that whenever a function calls another they ABI of the arguments being passed is in agreement. One possible solution to this would be to insert ""shim functions"" where whenever a `target_feature` mismatch is detected the compiler inserts a shim function where you pass arguments via memory to the shim and then the shim loads the values and calls the target function (where the shim and the target have the same target features enabled). This unfortunately is quite nontrivial to implement in rustc today (especially when accounting for function pointers and such). This commit takes a different solution *always* passing SIMD arguments through memory instead of passing as immediates. This strategy solves the problem at the LLVM layer because the ABI between two functions never uses SIMD registers. This also shouldn't be a hit to performance because SIMD performance is thought to often rely on inlining anyway where a `call` instruction even if using SIMD registers would be disastrous to performance regardless. LLVM should then be more than capable of fixing all our memory usage to use registers instead after enough inlining has been performed. Note that there's a few caveats to this commit though: * The ""platform intrinsic"" ABI is omitted from ""always pass via memory"". This ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc need to have the arguments as an immediate. * Additionally this commit does *not* fix the `extern` (""C"") ABI. This means that the bug in #44367 can still happen when using non-Rust-ABI functions. My hope is that before stabilization we can ban and/or warn about SIMD types in these functions (as AFAIK there's not much motivation to belong there anyway) but I'll leave that for a later commit and if this is merged I'll file a follow-up issue. All in all this... Closes #44367",THUMBS_UP,2018-01-26T06:12:11Z,parched,NA https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-01-25T21:36:37Z,est31,NA https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-01-25T22:00:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-01-26T15:19:48Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-01-27T18:25:25Z,bluss,NA https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-01-28T05:12:32Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-02-14T07:41:47Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-02-14T09:47:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47752,MERGED,2018-01-25T20:53:33Z,2018-02-11T21:07:56Z,Implement `?` macro repetition,mark-i-m,b92e542ddd41affaf6fb5d1267b8e8dfc03089a5,2,Fix the test,HOORAY,2018-02-14T18:50:52Z,Ryman,NA https://github.com/rust-lang/rust/pull/47760,MERGED,2018-01-25T23:15:47Z,2018-01-30T15:08:13Z,implement Send for process::Command on unix,little-dude,077d3434aa8a2a3064afcc1c9406a49d0acf0a8d,1,add test checking that process::Command is Send,THUMBS_UP,2018-02-08T00:08:25Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/47763,CLOSED,2018-01-26T01:07:03Z,2018-02-26T16:44:54Z,Detect possibly non-Rust closure syntax during parse,estebank,NA,NA,NA,HEART,2018-01-26T10:10:46Z,killercup,NA https://github.com/rust-lang/rust/pull/47767,MERGED,2018-01-26T06:44:39Z,2018-01-28T10:42:00Z,Correctly format `extern crate` conflict resolution help,estebank,445e404ba4c9782e4f5028eccb7c9473ae33c70a,4,Instead of modifying the item's span synthesize it,HEART,2018-01-26T18:21:40Z,Cldfire,NA https://github.com/rust-lang/rust/pull/47769,MERGED,2018-01-26T08:54:00Z,2018-01-26T20:34:28Z,Upgrade LLVM to incorporate a fix for #47364,dotdash,aca88e185a5233e6306bd6196864668b09342490,3,Upgrade LLVM to incorporate a fix for #47364 Fixes #47364,HOORAY,2018-01-27T17:27:56Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47802,MERGED,2018-01-27T10:20:23Z,2018-02-09T16:42:34Z,[NLL] Add false edges out of infinite loops,bobtwinkles,85dfa9d1a33be7a4e7276e03660fb9966057cb6e,2,Fix tests for MIR loop lowering Fixes the hash test to recognize that MirValidated can change when changing around labels and add a new test that makes sure we're lowering loop statements correctly.,THUMBS_UP,2018-01-29T17:26:06Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-27T21:07:25Z,durka,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-27T21:21:24Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-27T21:54:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-27T22:10:17Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-27T23:28:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-28T01:04:50Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-28T03:19:41Z,est31,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-28T13:23:04Z,arthurprs,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-28T21:44:14Z,bluss,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-29T01:36:11Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-29T18:05:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-01-31T05:00:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-02-03T01:52:27Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-02-06T01:24:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-02-07T03:35:15Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-02-17T16:29:49Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-02-26T16:04:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-15T21:30:27Z,hedgehog1024,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,CONFUSED,2018-03-16T03:16:28Z,lilydjwg,lilydjwg@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T06:05:17Z,sunjay,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T07:27:34Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T08:44:32Z,ha-shine,h@shine.rocks https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T09:55:51Z,iPixelOldC,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T15:46:03Z,nicklauri,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-16T16:38:55Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-18T22:37:04Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-19T12:04:35Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-21T07:36:48Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-21T10:26:37Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-22T13:14:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-03-26T22:06:18Z,JesseWright,NA https://github.com/rust-lang/rust/pull/47813,MERGED,2018-01-27T20:15:03Z,2018-03-15T18:51:21Z,Stabilize inclusive range (`..=`),kennytm,939cfa251aeb34b4b1a11396af1a3396792c708d,7,Keep the fields of RangeInclusive unstable.,HOORAY,2018-04-11T14:51:53Z,pszpetkowski,NA https://github.com/rust-lang/rust/pull/47818,CLOSED,2018-01-28T06:41:54Z,2018-01-31T19:40:12Z,Tweak error message when reborrowing `&mut self` as `mut`,estebank,NA,NA,NA,HEART,2018-01-28T06:51:48Z,est31,NA https://github.com/rust-lang/rust/pull/47822,MERGED,2018-01-28T12:47:24Z,2018-01-30T15:08:18Z,Whitelist aes x86 feature flag,gnzlbg,2497d10ff34bf4d03283e4562143762426492789,1,Whitelist aes x86 feature flag Required to fix https://github.com/rust-lang-nursery/stdsimd/issues/295 in stdsimd. r? @alexcrichton,THUMBS_UP,2018-01-28T16:17:01Z,ruuda,NA https://github.com/rust-lang/rust/pull/47822,MERGED,2018-01-28T12:47:24Z,2018-01-30T15:08:18Z,Whitelist aes x86 feature flag,gnzlbg,2497d10ff34bf4d03283e4562143762426492789,1,Whitelist aes x86 feature flag Required to fix https://github.com/rust-lang-nursery/stdsimd/issues/295 in stdsimd. r? @alexcrichton,THUMBS_UP,2018-01-28T16:35:46Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/47822,MERGED,2018-01-28T12:47:24Z,2018-01-30T15:08:18Z,Whitelist aes x86 feature flag,gnzlbg,2497d10ff34bf4d03283e4562143762426492789,1,Whitelist aes x86 feature flag Required to fix https://github.com/rust-lang-nursery/stdsimd/issues/295 in stdsimd. r? @alexcrichton,THUMBS_UP,2018-01-28T17:12:56Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/47824,CLOSED,2018-01-28T15:22:27Z,2018-02-26T16:42:30Z,Ignore functions before main and thread entry points in backtraces,Zoxc,NA,NA,NA,THUMBS_UP,2018-01-28T15:30:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/47824,CLOSED,2018-01-28T15:22:27Z,2018-02-26T16:42:30Z,Ignore functions before main and thread entry points in backtraces,Zoxc,NA,NA,NA,THUMBS_UP,2018-01-30T04:15:05Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:17:29Z,estebank,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:21:13Z,oberien,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:26:24Z,MaloJaffre,jaffre.malo@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:29:51Z,kennytm,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:46:33Z,alexbool,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T19:55:17Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T20:18:05Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T21:11:13Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T21:45:39Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T22:21:04Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T22:23:14Z,lqd,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T22:33:45Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-28T22:43:38Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-29T01:36:02Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-29T12:11:23Z,RanHum,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-29T17:47:19Z,aheart,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-29T18:30:06Z,est31,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-29T22:03:51Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-30T00:46:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-01-31T05:01:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-02T06:10:45Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-02T13:16:25Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-09T20:05:16Z,bstrie,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-09T21:16:27Z,rushmorem,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HEART,2018-02-09T21:23:15Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-09T21:23:16Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-09T23:25:19Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-09T23:33:58Z,ethanpailes,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T00:17:09Z,fschutt,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T02:21:37Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T06:01:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T06:21:16Z,sfackler,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T06:39:46Z,Valinora,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HEART,2018-02-10T06:50:34Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T07:26:42Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T15:20:12Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T16:21:06Z,akien-mga,rverschelde@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-10T22:09:13Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-11T11:55:12Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-11T12:48:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T05:29:28Z,bitshifter,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T06:55:15Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T11:15:57Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T12:34:45Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HEART,2018-02-14T13:56:54Z,cyplo,cyplo@cyplo.net https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T17:27:52Z,smaeul,samuel@sholland.org https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T18:50:51Z,boozook,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HEART,2018-02-14T18:50:51Z,boozook,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-14T21:50:40Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-02-15T10:29:52Z,CvX,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HEART,2018-02-24T15:39:55Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-03-06T01:25:55Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-03-26T19:27:48Z,jannisj1,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-04-01T00:58:35Z,jpeddicord,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-04-01T17:01:05Z,SplittyDev,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-04-04T14:07:13Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/47828,MERGED,2018-01-28T19:15:22Z,2018-02-10T05:43:00Z,rustc: Upgrade to LLVM 6,alexcrichton,6b7b6b63a928479a29d9fc1282e553e409c66934,9,"rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch) but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome along with scrutiny of the ""missing patches"" like a [change to pass manager order](rust-lang/llvm@27174447533) [another change to pass manager order](rust-lang/llvm@c782febb7b9) some [compile fixes for sparc](rust-lang/llvm@1a83de63c42) and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons notably: * This'll allow us to keep up with the upstream wasm backend picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3",HOORAY,2018-04-07T00:52:02Z,gaming-hacker,NA https://github.com/rust-lang/rust/pull/47832,MERGED,2018-01-28T19:37:34Z,2018-03-04T15:16:01Z,Have Vec use slice's implementations of Index and IndexMut,fintelia,370df40dab8df9f3c0b10bb7396225b8d24869b3,2,Don't have Vec delegate to [T]'s bounds for indexing,THUMBS_UP,2018-01-31T05:05:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47832,MERGED,2018-01-28T19:37:34Z,2018-03-04T15:16:01Z,Have Vec use slice's implementations of Index and IndexMut,fintelia,370df40dab8df9f3c0b10bb7396225b8d24869b3,2,Don't have Vec delegate to [T]'s bounds for indexing,THUMBS_UP,2018-02-08T03:27:29Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-01-28T21:12:09Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-01-28T22:19:57Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-01-29T06:49:23Z,qnighy,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-01T20:31:45Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-01T20:51:57Z,Emerentius,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-01T21:19:25Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-04T18:44:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-04T18:44:52Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-12T11:06:09Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-15T21:34:48Z,durka,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-18T06:59:35Z,sinkuu,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-21T00:17:19Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-21T00:22:10Z,cjubb39,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-22T18:57:01Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-22T18:57:33Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-22T18:57:39Z,sfackler,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-22T18:58:50Z,RalfJung,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HEART,2018-02-22T18:58:51Z,RalfJung,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-22T19:39:57Z,bluss,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-02-23T14:41:40Z,lnicola,NA https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-03-01T21:10:39Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/47833,MERGED,2018-01-28T20:37:55Z,2018-02-22T14:23:06Z,Generate documentation for auto-trait impls,Aaron1011,44d07df1cc5913b108d9207410ede33c38905bec,4,Sort synthetic impls bounds before rendering This removes the implicit dependency on the iteration order of FxHashMap,HOORAY,2018-03-30T02:57:31Z,hcpl,NA https://github.com/rust-lang/rust/pull/47835,MERGED,2018-01-28T23:34:47Z,2018-02-10T22:40:25Z,Remove unused data structures,Mark-Simulacrum,caa42e11bb6b7aea210ced552a157fa7de100d68,2,Remove VecCell,THUMBS_UP,2018-02-03T01:51:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/47835,MERGED,2018-01-28T23:34:47Z,2018-02-10T22:40:25Z,Remove unused data structures,Mark-Simulacrum,caa42e11bb6b7aea210ced552a157fa7de100d68,2,Remove VecCell,THUMBS_UP,2018-02-07T20:02:01Z,estebank,NA https://github.com/rust-lang/rust/pull/47837,MERGED,2018-01-29T00:32:20Z,2018-01-29T22:45:09Z,"Replace ""lvalue"" terminology with ""place"".",eddyb,bba81c975d9136d2bf10413826c743d25e54d97b,3,"rustc_borrowck: replace ""lvalue"" terminology with ""place"" in docs.",THUMBS_UP,2018-01-29T09:09:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47838,MERGED,2018-01-29T02:26:47Z,2018-01-31T23:50:19Z,use correct casing for rename suggestions,euclio,043d4615f2a9ff44d7b3726de51fa9e3bfb60d7e,8,use correct casing for rename suggestions If the original name is uppercase use camel case. Otherwise use snake case.,THUMBS_UP,2018-01-29T09:16:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/47841,CLOSED,2018-01-29T05:40:30Z,2018-01-29T09:56:45Z,Mark debug impl of numbers as inlineable,Manishearth,NA,NA,NA,THUMBS_UP,2018-01-29T05:50:59Z,retep998,NA https://github.com/rust-lang/rust/pull/47843,MERGED,2018-01-29T05:47:02Z,2018-02-12T12:34:13Z,Add `-Zteach` documentation,estebank,51f0c0dc4c0ce47f4019c78f4b865718bf278a8d,482,Move some E0XXX to `ui`,HEART,2018-01-29T10:28:42Z,killercup,NA https://github.com/rust-lang/rust/pull/47843,MERGED,2018-01-29T05:47:02Z,2018-02-12T12:34:13Z,Add `-Zteach` documentation,estebank,51f0c0dc4c0ce47f4019c78f4b865718bf278a8d,482,Move some E0XXX to `ui`,HEART,2018-02-14T18:51:34Z,Ryman,NA https://github.com/rust-lang/rust/pull/47844,MERGED,2018-01-29T07:47:06Z,2018-01-31T23:50:21Z,Fix regression: account for trait methods in arg count mismatch error,CAD97,c06c707fbfdfa074026b6b09a5da9168e247d156,3,Fix regression: account for trait methods in arg count mismatch error,HEART,2018-01-29T16:51:54Z,estebank,NA https://github.com/rust-lang/rust/pull/47846,MERGED,2018-01-29T10:07:38Z,2018-02-15T16:42:39Z,Work around LLVM OCAML binding installation failure,roblabla,3c01dea03e1b4ffbcb665a68bcf228c02497ecdc,1,Add comment about the problem and use provided path if available,LAUGH,2018-01-29T13:21:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47846,MERGED,2018-01-29T10:07:38Z,2018-02-15T16:42:39Z,Work around LLVM OCAML binding installation failure,roblabla,3c01dea03e1b4ffbcb665a68bcf228c02497ecdc,1,Add comment about the problem and use provided path if available,CONFUSED,2018-01-29T14:12:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/47848,CLOSED,2018-01-29T11:23:38Z,2018-01-30T07:55:09Z,[WIP] Make derive(Clone) memcpy on enum variants containing Copy types,Manishearth,NA,NA,NA,HOORAY,2018-01-29T11:24:04Z,est31,NA https://github.com/rust-lang/rust/pull/47857,CLOSED,2018-01-29T18:36:29Z,2018-02-24T13:28:40Z,Implement TryFrom for float to integer types,udoprog,NA,NA,NA,HEART,2018-01-29T19:10:24Z,estebank,NA https://github.com/rust-lang/rust/pull/47857,CLOSED,2018-01-29T18:36:29Z,2018-02-24T13:28:40Z,Implement TryFrom for float to integer types,udoprog,NA,NA,NA,THUMBS_UP,2018-11-20T22:05:12Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/47857,CLOSED,2018-01-29T18:36:29Z,2018-02-24T13:28:40Z,Implement TryFrom for float to integer types,udoprog,NA,NA,NA,HEART,2019-12-28T15:11:58Z,kacejot,NA https://github.com/rust-lang/rust/pull/47877,MERGED,2018-01-30T13:56:43Z,2018-02-05T01:45:43Z,Do not ignore lifetime bounds in Copy impls,spastorino,b9f756416a02fe3fd1c145fc081494b68f494f76,2,Do not ignore lifetime bounds in Copy impls Closes #29149,HOORAY,2018-02-05T14:05:51Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47886,MERGED,2018-01-30T20:12:32Z,2018-01-31T23:50:26Z,rustc: Add some defines for LLVM 7 compat,alexcrichton,d492fe0a00b4afb99c7ba6292961d6d98698373c,1,rustc: Add some defines for LLVM 7 compat I was testing out the tip support to see what's going on with wasm and this was I believe the only issue encountered with LLVM 7 support so far.,HEART,2018-01-30T20:37:25Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47886,MERGED,2018-01-30T20:12:32Z,2018-01-31T23:50:26Z,rustc: Add some defines for LLVM 7 compat,alexcrichton,d492fe0a00b4afb99c7ba6292961d6d98698373c,1,rustc: Add some defines for LLVM 7 compat I was testing out the tip support to see what's going on with wasm and this was I believe the only issue encountered with LLVM 7 support so far.,HEART,2018-01-30T20:49:07Z,estebank,NA https://github.com/rust-lang/rust/pull/47886,MERGED,2018-01-30T20:12:32Z,2018-01-31T23:50:26Z,rustc: Add some defines for LLVM 7 compat,alexcrichton,d492fe0a00b4afb99c7ba6292961d6d98698373c,1,rustc: Add some defines for LLVM 7 compat I was testing out the tip support to see what's going on with wasm and this was I believe the only issue encountered with LLVM 7 support so far.,HEART,2018-01-30T21:09:38Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47886,MERGED,2018-01-30T20:12:32Z,2018-01-31T23:50:26Z,rustc: Add some defines for LLVM 7 compat,alexcrichton,d492fe0a00b4afb99c7ba6292961d6d98698373c,1,rustc: Add some defines for LLVM 7 compat I was testing out the tip support to see what's going on with wasm and this was I believe the only issue encountered with LLVM 7 support so far.,HEART,2018-01-31T02:15:34Z,cramertj,NA https://github.com/rust-lang/rust/pull/47894,MERGED,2018-01-31T00:50:41Z,2018-02-28T07:10:10Z,rustdoc: Foldable impl blocks,vi,df1b9a8584bf273fb807bae2d9dd55833aee5964,1,rustdoc: On mobile: hide § adjust [+] position,HOORAY,2018-02-01T16:29:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47894,MERGED,2018-01-31T00:50:41Z,2018-02-28T07:10:10Z,rustdoc: Foldable impl blocks,vi,df1b9a8584bf273fb807bae2d9dd55833aee5964,1,rustdoc: On mobile: hide § adjust [+] position,HEART,2018-02-22T00:37:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47913,CLOSED,2018-01-31T21:23:55Z,2018-02-01T11:09:34Z,Fix typo: s/MAN_MASK/NAN_MASK/g,hanna-kruppe,NA,NA,NA,LAUGH,2018-01-31T21:32:13Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/47913,CLOSED,2018-01-31T21:23:55Z,2018-02-01T11:09:34Z,Fix typo: s/MAN_MASK/NAN_MASK/g,hanna-kruppe,NA,NA,NA,CONFUSED,2018-02-01T11:03:45Z,ranma42,NA https://github.com/rust-lang/rust/pull/47922,MERGED,2018-02-01T05:30:10Z,2018-02-07T20:50:33Z,correct unused field pattern suggestions,zackmdavis,e4b1a7971d7b4ed61d27af44e3169cb26595ae13,4,"concerning well-formed suggestions for unused shorthand field patterns Previously unused variables would get a note that the warning could be silenced by prefixing the variable with an underscore but that doesn't work for field shorthand patterns which the liveness analysis didn't know about. The ""to avoid this warning"" verbiage seemed unnecessary. Resolves #47390.",THUMBS_UP,2018-02-01T06:23:35Z,estebank,NA https://github.com/rust-lang/rust/pull/47922,MERGED,2018-02-01T05:30:10Z,2018-02-07T20:50:33Z,correct unused field pattern suggestions,zackmdavis,e4b1a7971d7b4ed61d27af44e3169cb26595ae13,4,"concerning well-formed suggestions for unused shorthand field patterns Previously unused variables would get a note that the warning could be silenced by prefixing the variable with an underscore but that doesn't work for field shorthand patterns which the liveness analysis didn't know about. The ""to avoid this warning"" verbiage seemed unnecessary. Resolves #47390.",THUMBS_UP,2018-02-01T09:11:38Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/47922,MERGED,2018-02-01T05:30:10Z,2018-02-07T20:50:33Z,correct unused field pattern suggestions,zackmdavis,e4b1a7971d7b4ed61d27af44e3169cb26595ae13,4,"concerning well-formed suggestions for unused shorthand field patterns Previously unused variables would get a note that the warning could be silenced by prefixing the variable with an underscore but that doesn't work for field shorthand patterns which the liveness analysis didn't know about. The ""to avoid this warning"" verbiage seemed unnecessary. Resolves #47390.",THUMBS_UP,2018-02-06T07:21:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47922,MERGED,2018-02-01T05:30:10Z,2018-02-07T20:50:33Z,correct unused field pattern suggestions,zackmdavis,e4b1a7971d7b4ed61d27af44e3169cb26595ae13,4,"concerning well-formed suggestions for unused shorthand field patterns Previously unused variables would get a note that the warning could be silenced by prefixing the variable with an underscore but that doesn't work for field shorthand patterns which the liveness analysis didn't know about. The ""to avoid this warning"" verbiage seemed unnecessary. Resolves #47390.",THUMBS_UP,2018-02-06T14:44:15Z,mrhota,NA https://github.com/rust-lang/rust/pull/47926,MERGED,2018-02-01T09:29:41Z,2018-02-17T11:32:16Z,add transform for uniform array move out,mikhail-m1,31253d5557f8c161ac97028a3966d617491b86a6,6,add transform for uniform array move out,HOORAY,2018-02-01T18:11:58Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/47926,MERGED,2018-02-01T09:29:41Z,2018-02-17T11:32:16Z,add transform for uniform array move out,mikhail-m1,31253d5557f8c161ac97028a3966d617491b86a6,6,add transform for uniform array move out,HOORAY,2018-02-02T04:11:15Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47926,MERGED,2018-02-01T09:29:41Z,2018-02-17T11:32:16Z,add transform for uniform array move out,mikhail-m1,31253d5557f8c161ac97028a3966d617491b86a6,6,add transform for uniform array move out,HOORAY,2018-02-06T10:41:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/47943,MERGED,2018-02-01T20:19:59Z,2018-02-02T19:25:02Z,[beta] Backports,MaloJaffre,0a339818d7ffb794629e0df88f0591364f04bf90,1,Update Cargo on beta,THUMBS_UP,2018-02-01T21:56:17Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,HOORAY,2018-02-01T21:47:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,HOORAY,2018-02-08T19:39:28Z,mcarton,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-03-29T17:24:05Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-03-29T18:54:42Z,tdbgamer,timbessmail@gmail.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-03-29T21:16:55Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-03-30T18:33:46Z,Gedweb,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-03-31T16:08:19Z,tkukushkin,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-04-08T15:04:32Z,nicklauri,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-04-12T21:23:14Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-04-20T06:44:54Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-05-09T15:41:19Z,hoodie,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,HOORAY,2018-05-09T23:44:53Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-06-06T01:15:49Z,SnirkImmington,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-06-27T03:19:57Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-07-11T06:11:06Z,Arcaelyx,NA https://github.com/rust-lang/rust/pull/47947,MERGED,2018-02-01T21:40:58Z,2018-02-05T01:45:48Z,Stabilize feature(match_beginning_vert),goodmanjonathan,a99b5db56a36652185a91be630b3e2af8ea09360,9,stabilize match_beginning_vert,THUMBS_DOWN,2018-07-24T06:23:34Z,SephVelut,NA https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-01T22:17:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-02T04:02:39Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-05T17:13:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-06T16:24:13Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-10T07:25:16Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/47948,MERGED,2018-02-01T21:57:45Z,2018-02-06T09:51:19Z,Stabilize use_nested_groups,pietroalbini,01f0814a2a7db7d93b4cb90b74242b082861e674,9,Stabilize use_nested_groups,HOORAY,2018-02-14T18:02:15Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-02T07:50:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-02T11:40:54Z,lqd,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-02T13:01:01Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-02T15:12:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-02T21:00:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-03T16:25:23Z,cynecx,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-02-22T16:59:03Z,cramertj,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2018-11-22T22:02:54Z,arthurprs,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,THUMBS_UP,2019-05-18T08:51:10Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,EYES,2019-05-18T08:51:16Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,EYES,2019-12-28T15:22:45Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-01-03T09:09:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,ROCKET,2020-01-14T20:33:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-01-17T00:06:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,THUMBS_UP,2020-01-20T19:37:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-01-20T19:37:17Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-01-23T01:40:03Z,tmandry,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-02-14T01:08:01Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,THUMBS_UP,2020-02-23T23:15:33Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-02-23T23:15:35Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,THUMBS_UP,2020-03-22T06:13:20Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-03-22T06:13:21Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,ROCKET,2020-03-22T06:13:21Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,EYES,2020-03-22T06:13:22Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-04-08T11:47:32Z,iago-lito,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HEART,2020-04-08T11:47:36Z,iago-lito,NA https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,HOORAY,2020-06-10T00:29:46Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/47954,CLOSED,2018-02-01T23:55:19Z,2020-03-24T18:41:18Z,"[WIP] Implement a ""place unification"" MIR optimization (aka source/destination propagation aka NRVO).",eddyb,NA,NA,NA,ROCKET,2020-10-08T17:46:51Z,recmo,remco@wicked.ventures https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HEART,2018-02-02T01:25:08Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HOORAY,2018-02-02T01:25:10Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-02-02T01:25:11Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T01:37:59Z,Havvy,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T01:39:52Z,projektir,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T03:55:52Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T04:32:09Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T06:53:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HOORAY,2018-02-02T06:53:49Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T07:46:52Z,kennytm,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T09:42:25Z,aatxe,aweiss@hey.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T15:12:59Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-02T15:23:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-03T02:54:29Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HOORAY,2018-02-03T15:30:32Z,Jragon,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-08T16:19:04Z,niksaak,niksaak@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-10T10:54:31Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-02-11T15:37:57Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-21T16:10:03Z,Stealth2800,github@stealthyone.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-02-21T19:00:21Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-21T21:54:06Z,danilaml,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HEART,2018-02-22T08:22:55Z,PBertinJohannet,pierre.bertin-johannet@orange.fr https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-22T17:02:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-02-22T17:02:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-02-23T06:11:00Z,saphtea,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HOORAY,2018-02-23T06:11:01Z,saphtea,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HEART,2018-02-23T06:11:02Z,saphtea,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-02-23T06:11:03Z,saphtea,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-03-04T12:29:26Z,johncf,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-03-04T12:29:27Z,johncf,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2018-03-21T13:51:11Z,adityasrini,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2018-11-13T05:20:00Z,rivy,NA https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,THUMBS_UP,2020-05-12T01:09:21Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HEART,2020-05-12T01:09:22Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,HOORAY,2020-05-12T01:09:23Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/47956,MERGED,2018-02-02T01:22:02Z,2018-02-17T14:31:37Z,This is the ideal FileType on Windows. You may not like it but this is what peak performance looks like.,retep998,9269e83b37e8e5fd9cef12255fafbc6db6220035,2,Add an unstable FileTypeExt extension trait for Windows,LAUGH,2022-05-06T20:36:25Z,AronParker,NA https://github.com/rust-lang/rust/pull/47967,CLOSED,2018-02-02T15:28:54Z,2018-03-30T19:15:43Z,[WIP] Warn when `$name:matcher` syntax is used on expansion side,krdln,NA,NA,NA,THUMBS_UP,2018-02-06T04:19:52Z,qnighy,NA https://github.com/rust-lang/rust/pull/47967,CLOSED,2018-02-02T15:28:54Z,2018-03-30T19:15:43Z,[WIP] Warn when `$name:matcher` syntax is used on expansion side,krdln,NA,NA,NA,THUMBS_UP,2018-02-12T10:59:04Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/47967,CLOSED,2018-02-02T15:28:54Z,2018-03-30T19:15:43Z,[WIP] Warn when `$name:matcher` syntax is used on expansion side,krdln,NA,NA,NA,CONFUSED,2018-03-13T22:43:58Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/47975,CLOSED,2018-02-02T21:34:08Z,2018-02-13T23:26:46Z,Add safe volatile functions.,clarfonthey,NA,NA,NA,THUMBS_UP,2018-02-03T07:52:33Z,oli-obk,NA https://github.com/rust-lang/rust/pull/47999,MERGED,2018-02-04T15:33:04Z,2018-02-05T01:45:53Z,Remove 'the this' in doc comments.,jaystrictor,f168700ba6257979dd90b20e0149e1ccf53590f0,2,Remove 'the this' in doc comments.,LAUGH,2018-02-04T19:22:40Z,est31,NA https://github.com/rust-lang/rust/pull/47999,MERGED,2018-02-04T15:33:04Z,2018-02-05T01:45:53Z,Remove 'the this' in doc comments.,jaystrictor,f168700ba6257979dd90b20e0149e1ccf53590f0,2,Remove 'the this' in doc comments.,LAUGH,2018-02-04T21:58:17Z,kinggoesgaming,hunar.roop@gmail.com https://github.com/rust-lang/rust/pull/48012,MERGED,2018-02-05T07:58:35Z,2018-02-06T22:21:19Z,Override try_[r]fold for RangeInclusive,scottmcm,1b1e887f4d40e5800a8d5ae81f8574806e7ba21a,2,Override try_[r]fold for RangeInclusive Because the last item needs special handling it seems that LLVM has trouble canonicalizing the loops in external iteration. With the override it becomes obvious that the start==end case exits the loop (as opposed to the one *after* that exiting the loop in external iteration).,HOORAY,2018-02-14T10:34:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48014,MERGED,2018-02-05T14:25:23Z,2018-02-07T20:50:36Z,Implement RFC 2052 (Epochs),Manishearth,b8aa8cadd6e868e74becaffaae17b64aeb66d004,2,Add tests for -Zepoch using tyvar_raw_pointer,LAUGH,2018-02-05T16:54:41Z,kennytm,NA https://github.com/rust-lang/rust/pull/48028,MERGED,2018-02-06T02:35:08Z,2018-02-07T20:50:38Z,correct E0619 span re method call receivers whose type must be known,zackmdavis,b55e07ee50c9e4d00b6fc13dc27d45bd03a7965d,3,correct E0619 span re method call receivers whose type must be known Previously when the type of a method receiver could not be determined the error message would potentially confusingly highlight the span of the entire method call. Resolves #36598 resolves #42234.,THUMBS_UP,2018-02-06T09:38:40Z,varkor,NA https://github.com/rust-lang/rust/pull/48028,MERGED,2018-02-06T02:35:08Z,2018-02-07T20:50:38Z,correct E0619 span re method call receivers whose type must be known,zackmdavis,b55e07ee50c9e4d00b6fc13dc27d45bd03a7965d,3,correct E0619 span re method call receivers whose type must be known Previously when the type of a method receiver could not be determined the error message would potentially confusingly highlight the span of the entire method call. Resolves #36598 resolves #42234.,THUMBS_UP,2018-02-06T23:48:26Z,estebank,NA https://github.com/rust-lang/rust/pull/48028,MERGED,2018-02-06T02:35:08Z,2018-02-07T20:50:38Z,correct E0619 span re method call receivers whose type must be known,zackmdavis,b55e07ee50c9e4d00b6fc13dc27d45bd03a7965d,3,correct E0619 span re method call receivers whose type must be known Previously when the type of a method receiver could not be determined the error message would potentially confusingly highlight the span of the entire method call. Resolves #36598 resolves #42234.,HEART,2018-02-06T23:48:28Z,estebank,NA https://github.com/rust-lang/rust/pull/48033,MERGED,2018-02-06T13:57:50Z,2018-02-15T16:42:43Z,Show better warning for trying to cast non-u8 scalar to char,GuillaumeGomez,0cccd9aca51e3fe2952633b34c4c877539d1113d,3,Show better warning for trying to cast non-u8 scalar to char,HEART,2018-02-06T23:46:51Z,estebank,NA https://github.com/rust-lang/rust/pull/48033,MERGED,2018-02-06T13:57:50Z,2018-02-15T16:42:43Z,Show better warning for trying to cast non-u8 scalar to char,GuillaumeGomez,0cccd9aca51e3fe2952633b34c4c877539d1113d,3,Show better warning for trying to cast non-u8 scalar to char,HEART,2018-02-08T04:09:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48035,MERGED,2018-02-06T14:27:53Z,2018-02-15T16:42:44Z,Early exit for empty HashMap (issue #38880),technicalguy,e034dddb32cd9814d9f71bb2b444f9863fba2dfc,1,38880 remove unnecessary self.table.size check,HOORAY,2018-02-08T00:23:53Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/48035,MERGED,2018-02-06T14:27:53Z,2018-02-15T16:42:44Z,Early exit for empty HashMap (issue #38880),technicalguy,e034dddb32cd9814d9f71bb2b444f9863fba2dfc,1,38880 remove unnecessary self.table.size check,HOORAY,2018-02-21T15:11:12Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/48035,MERGED,2018-02-06T14:27:53Z,2018-02-15T16:42:44Z,Early exit for empty HashMap (issue #38880),technicalguy,e034dddb32cd9814d9f71bb2b444f9863fba2dfc,1,38880 remove unnecessary self.table.size check,HOORAY,2018-02-22T09:34:59Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48035,MERGED,2018-02-06T14:27:53Z,2018-02-15T16:42:44Z,Early exit for empty HashMap (issue #38880),technicalguy,e034dddb32cd9814d9f71bb2b444f9863fba2dfc,1,38880 remove unnecessary self.table.size check,THUMBS_UP,2018-02-22T17:03:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48035,MERGED,2018-02-06T14:27:53Z,2018-02-15T16:42:44Z,Early exit for empty HashMap (issue #38880),technicalguy,e034dddb32cd9814d9f71bb2b444f9863fba2dfc,1,38880 remove unnecessary self.table.size check,HOORAY,2018-02-22T20:10:56Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/48056,MERGED,2018-02-07T19:17:59Z,2018-02-28T10:02:30Z,Comprehensively support trailing commas in std/core macros,ExpHP,af503be3685ae925edefe96d0f160369520e7b5a,1,ignore-pretty for the macro-comma-support test include! and the pretty test do not mix,HOORAY,2018-03-10T16:33:07Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,LAUGH,2018-02-07T22:28:50Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,LAUGH,2018-02-07T22:40:37Z,est31,NA https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,LAUGH,2018-02-07T22:44:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,LAUGH,2018-02-09T18:58:40Z,cramertj,NA https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,LAUGH,2018-02-28T06:46:33Z,Havvy,NA https://github.com/rust-lang/rust/pull/48061,MERGED,2018-02-07T22:27:59Z,2018-02-24T23:28:34Z,do not run MIR type checker twice,nikomatsakis,bcd996857e42a383c79ea9ae84994d3ad932ac4a,1,explain why we don't need to run type-checker when NLL is enabled,HOORAY,2018-03-01T08:08:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48065,MERGED,2018-02-08T03:16:08Z,2018-02-15T16:42:46Z,Apply optimization from #44355 to retain,Xaeroxe,fbad3b2468f46c14d0fd1283aa4935b3d79f007b,1,Switch to retain calling drain_filter.,HOORAY,2018-02-22T09:33:42Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48076,MERGED,2018-02-08T19:40:05Z,2018-02-25T17:48:46Z,pass correct pie args to gcc linker,canarysnort01,ab9cae1ba192afcc35e8bd6a5fddcd1445d05da7,1,only pass -no-pie if linker_is_gnu,THUMBS_UP,2019-06-03T13:53:27Z,pkoliveira,NA https://github.com/rust-lang/rust/pull/48079,CLOSED,2018-02-08T21:42:26Z,2018-02-08T23:46:12Z,Relax termination trait error bound,U007D,NA,NA,NA,CONFUSED,2018-02-08T22:22:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/48091,CLOSED,2018-02-09T14:59:41Z,2018-02-10T06:15:44Z,Fix rustllvm compile on LLVM 6,alexcrichton,NA,NA,NA,THUMBS_UP,2018-02-09T22:55:48Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/48097,MERGED,2018-02-09T17:54:15Z,2018-03-16T22:43:33Z,Automatically enable the `clippy` feature of `rls` if clippy builds,oli-obk,02ac15cb898a3c74b1bd2453e5ff9fdb35e03157,9,Automatically enable the `clippy` feature of `rls` if clippy builds,HOORAY,2018-02-09T21:41:38Z,killercup,NA https://github.com/rust-lang/rust/pull/48107,MERGED,2018-02-09T21:20:18Z,2018-02-10T22:40:43Z,fix typo: substract -> subtract,matthiaskrgr,e6f910e31e578301cc8608f049f1763172569ca8,3,fix typo: substract -> subtract.,THUMBS_UP,2018-02-09T21:56:00Z,estebank,NA https://github.com/rust-lang/rust/pull/48115,MERGED,2018-02-10T06:38:06Z,2018-02-25T17:48:47Z,Add Iterator::flatten,Centril,819d57abc94d162e0d6f58fcbed757849f8305b4,1,core::iter::Iterator::flatten: improve docs wrt. deep vs. shallow flatten per @clarcharr's review,THUMBS_UP,2018-03-01T20:49:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48120,MERGED,2018-02-10T11:31:59Z,2018-02-10T22:40:45Z,fix typos in src/{bootstrap ci etc lib{backtrace core fmt_macros}},matthiaskrgr,7ee3e39f640a9532842e1441bf6bc98893b6a3ba,11,fix typos in src/{bootstrap ci etc lib{backtrace core fmt_macros}},THUMBS_UP,2018-02-11T11:56:19Z,discosultan,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:15:40Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:18:32Z,Ryman,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:19:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:34:41Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:35:09Z,est31,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-10T15:35:11Z,est31,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-10T15:35:13Z,est31,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-10T15:37:44Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:47:18Z,Cldfire,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T15:55:55Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-10T16:16:15Z,fckt,alexey@fckt.dev https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-10T17:19:17Z,Turbo87,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-10T17:32:43Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T17:32:44Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-10T17:32:44Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-10T17:49:32Z,fitzgen,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T18:27:51Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T20:25:39Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T23:02:49Z,emberian,ember@lunar.town https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-10T23:02:49Z,emberian,ember@lunar.town https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T23:04:25Z,sfackler,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T23:05:12Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-10T23:05:49Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-11T01:11:42Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T01:11:42Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-11T01:11:43Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T01:13:20Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T03:57:58Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T05:14:58Z,dherman,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T09:18:39Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-11T18:35:40Z,lqd,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T18:35:42Z,lqd,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T19:21:45Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-11T23:30:47Z,canarysnort01,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-12T00:35:50Z,Enet4,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-12T00:35:51Z,Enet4,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-12T09:13:16Z,pierre-rouanet,pierre.rouanet@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-12T09:13:18Z,pierre-rouanet,pierre.rouanet@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-12T13:21:42Z,lilianmoraru,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-12T16:19:35Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-12T20:12:25Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-13T01:39:56Z,xeqlol,xeqlol@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-14T00:44:43Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-14T00:45:43Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-15T19:00:35Z,bkolobara,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-21T11:16:04Z,ffflorian,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-21T18:20:34Z,raphaelrobert,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-23T09:42:44Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-23T09:42:45Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-23T09:42:46Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-02-25T17:21:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-02-25T17:21:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-02-25T17:21:07Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-03-04T11:22:54Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-03-06T18:09:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-03-06T22:38:28Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-03-31T09:38:14Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-04-06T18:31:55Z,mschorsch,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-04-06T18:31:58Z,mschorsch,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-04-06T18:32:01Z,mschorsch,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-04-07T23:49:43Z,thedodd,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-04-07T23:49:45Z,thedodd,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-04-07T23:49:46Z,thedodd,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-04-09T10:47:13Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-04-22T20:39:17Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-06-07T07:06:19Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HOORAY,2018-06-07T07:06:20Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-06-07T07:06:24Z,TomasHubelbauer,tomas@hubelbauer.net https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-08-22T17:15:57Z,qm3ster,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-10-09T22:39:38Z,tjklemz,NA https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,THUMBS_UP,2018-11-12T06:16:21Z,RicoGit,constantine.solovev@gmail.com https://github.com/rust-lang/rust/pull/48125,MERGED,2018-02-10T15:09:45Z,2018-03-04T07:09:42Z,rust: Import LLD for linking wasm objects,alexcrichton,0129b01a41a062f82909cecdfd0cc7f0093c71f8,26,rustc: Tweak default linker selection This commit refactors how the path to the linker that we're going to invoke is selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker` (path) option but this meant that whenever you changed one you had to change the other. The purpose of this commit is to avoid coupling these where possible. Target specifications now only unconditionally define the *flavor* of the linker that they're using by default. If not otherwise specified each flavor now implies a particular default linker to run. As a result this means that if you'd like to test out `ld` for example you should be able to do: rustc -Z linker-flavor=ld foo.rs whereas previously you had to do rustc -Z linker-flavor=ld -C linker=ld foo.rs This will hopefully make it a bit easier to tinker around with variants that should otherwise be well known to work for example with LLD `ld` on OSX etc.,HEART,2018-11-12T06:16:22Z,RicoGit,constantine.solovev@gmail.com https://github.com/rust-lang/rust/pull/48127,CLOSED,2018-02-10T21:08:09Z,2018-02-14T15:19:07Z,Debug #48116.,kennytm,NA,NA,NA,HEART,2018-02-10T23:10:33Z,estebank,NA https://github.com/rust-lang/rust/pull/48127,CLOSED,2018-02-10T21:08:09Z,2018-02-14T15:19:07Z,Debug #48116.,kennytm,NA,NA,NA,HEART,2018-02-10T23:12:05Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/48139,CLOSED,2018-02-11T09:39:33Z,2018-04-23T14:58:05Z,[WIP] Deduplicate instances,bjorn3,NA,NA,NA,HOORAY,2018-03-20T23:00:05Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/48139,CLOSED,2018-02-11T09:39:33Z,2018-04-23T14:58:05Z,[WIP] Deduplicate instances,bjorn3,NA,NA,NA,HOORAY,2018-03-22T08:27:34Z,nical,nical@fastmail.com https://github.com/rust-lang/rust/pull/48139,CLOSED,2018-02-11T09:39:33Z,2018-04-23T14:58:05Z,[WIP] Deduplicate instances,bjorn3,NA,NA,NA,HOORAY,2018-03-30T17:13:47Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48139,CLOSED,2018-02-11T09:39:33Z,2018-04-23T14:58:05Z,[WIP] Deduplicate instances,bjorn3,NA,NA,NA,HOORAY,2018-04-09T21:54:02Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/48143,MERGED,2018-02-11T14:39:15Z,2018-02-24T23:28:37Z,Termination trait in tests,nikomatsakis,10f7c110928ee7d3db7fef15fd7dce776b17e161,1,re-export `assert_test_result` for use when testing libtest itself,THUMBS_UP,2018-02-11T20:34:36Z,bkchr,NA https://github.com/rust-lang/rust/pull/48143,MERGED,2018-02-11T14:39:15Z,2018-02-24T23:28:37Z,Termination trait in tests,nikomatsakis,10f7c110928ee7d3db7fef15fd7dce776b17e161,1,re-export `assert_test_result` for use when testing libtest itself,THUMBS_UP,2018-02-22T20:32:52Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48149,MERGED,2018-02-11T23:26:05Z,2018-06-21T23:08:33Z,The Great Generics Generalisation: HIR Edition,varkor,daf7e359a10306c004bdffd06b6432998d70b858,3,Fix rebase issues with existential types,THUMBS_UP,2018-06-27T09:23:38Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/48149,MERGED,2018-02-11T23:26:05Z,2018-06-21T23:08:33Z,The Great Generics Generalisation: HIR Edition,varkor,daf7e359a10306c004bdffd06b6432998d70b858,3,Fix rebase issues with existential types,HOORAY,2018-06-29T04:54:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/48151,MERGED,2018-02-12T02:04:24Z,2018-02-15T16:42:52Z,Update ops range example to avoid confusion between indexes and values.,echochamber,bd426f1d69ec8371d86e06382e96e9ed842f3933,1,Update ops range example to avoid confusion between indexes and values.,HEART,2018-02-12T02:19:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48156,MERGED,2018-02-12T08:54:01Z,2018-02-15T16:42:54Z,Add std/core::iter::repeat_with,Centril,db13296b6fd6b68ab06055bdcb9a22078b11de6a,1,core::iter::repeat_with: fix missing word see @Pazzaz's review,THUMBS_UP,2018-02-12T10:23:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48157,MERGED,2018-02-12T09:48:19Z,2018-02-24T10:30:29Z,Add Iterator::try_for_each,scottmcm,0bb818cc0b2885b01ce670ce192aac1dbc6db16a,1,Add Iterator::try_for_each The fallible version of for_each and the stateless version of try_fold.,THUMBS_UP,2018-02-12T17:16:53Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/48157,MERGED,2018-02-12T09:48:19Z,2018-02-24T10:30:29Z,Add Iterator::try_for_each,scottmcm,0bb818cc0b2885b01ce670ce192aac1dbc6db16a,1,Add Iterator::try_for_each The fallible version of for_each and the stateless version of try_fold.,THUMBS_UP,2018-03-01T01:41:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/48157,MERGED,2018-02-12T09:48:19Z,2018-02-24T10:30:29Z,Add Iterator::try_for_each,scottmcm,0bb818cc0b2885b01ce670ce192aac1dbc6db16a,1,Add Iterator::try_for_each The fallible version of for_each and the stateless version of try_fold.,THUMBS_UP,2018-04-09T20:01:02Z,hcpl,NA https://github.com/rust-lang/rust/pull/48157,MERGED,2018-02-12T09:48:19Z,2018-02-24T10:30:29Z,Add Iterator::try_for_each,scottmcm,0bb818cc0b2885b01ce670ce192aac1dbc6db16a,1,Add Iterator::try_for_each The fallible version of for_each and the stateless version of try_fold.,EYES,2021-06-09T17:51:26Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",LAUGH,2018-02-12T17:44:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",HOORAY,2018-02-13T16:30:47Z,mrhota,NA https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",HEART,2018-02-15T15:57:31Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",HOORAY,2018-02-21T13:21:52Z,RanHum,NA https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",HOORAY,2018-02-22T16:58:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48163,MERGED,2018-02-12T16:46:30Z,2018-02-15T16:42:55Z,rustc: Persist LLVM's `Linker` in Fat LTO,alexcrichton,43e8ac27d9bf645b66a15f762be6969e9fe16285,5,"rustc: Persist LLVM's `Linker` in Fat LTO This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's ""link modules"" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds clearly being a nice improvement! Closes #48025",HOORAY,2018-02-24T16:58:20Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/48166,MERGED,2018-02-12T19:28:49Z,2018-02-25T17:48:48Z,Stabilize 'entry_and_modify' feature,hedgehog1024,0aa753ba30254631ce05f37cd2ff0dd428d931c5,2,1.25.0 -> 1.26.-,THUMBS_UP,2018-02-20T00:14:34Z,Qqwy,qqwy@gmx.com https://github.com/rust-lang/rust/pull/48166,MERGED,2018-02-12T19:28:49Z,2018-02-25T17:48:48Z,Stabilize 'entry_and_modify' feature,hedgehog1024,0aa753ba30254631ce05f37cd2ff0dd428d931c5,2,1.25.0 -> 1.26.-,THUMBS_UP,2018-03-01T01:39:16Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/48191,CLOSED,2018-02-13T19:00:39Z,2018-03-14T20:34:05Z,Add a generic `From<&Borrow>` impl for `Cow`,burtonageo,NA,NA,NA,THUMBS_UP,2018-02-13T20:29:03Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48195,MERGED,2018-02-13T21:40:27Z,2018-02-15T16:42:59Z,Update compiler-builtins to latest master.,paoloteti,893fc3274477fe22fb3b481583df9d0b81df718d,1,Update compiler-builtins to latest master. - Rebase compiler-rt to LLVM 6 - New VFP intrinsics on ARM - Add generic conversion from a narrower to a wider FP type (f32->f64) - Fixes minor issues on _subsf3 __subdf3 and __aeabi_fcmple - Split test suite to a separate crate,THUMBS_UP,2018-02-15T19:20:43Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48219,MERGED,2018-02-14T21:03:16Z,2018-02-24T10:30:32Z,lookup exported symbols only when needed.,andjo403,7041ef3cf437acd39262eed4cec0d4aa3c1ff1f9,2,lookup exported symbols only when needed. reduces the time to emit dep-info and metadata.,HEART,2018-02-14T21:05:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/48219,MERGED,2018-02-14T21:03:16Z,2018-02-24T10:30:32Z,lookup exported symbols only when needed.,andjo403,7041ef3cf437acd39262eed4cec0d4aa3c1ff1f9,2,lookup exported symbols only when needed. reduces the time to emit dep-info and metadata.,HEART,2018-02-14T21:16:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48219,MERGED,2018-02-14T21:03:16Z,2018-02-24T10:30:32Z,lookup exported symbols only when needed.,andjo403,7041ef3cf437acd39262eed4cec0d4aa3c1ff1f9,2,lookup exported symbols only when needed. reduces the time to emit dep-info and metadata.,HEART,2018-02-14T22:35:37Z,estebank,NA https://github.com/rust-lang/rust/pull/48221,MERGED,2018-02-14T22:26:07Z,2018-02-24T10:30:32Z,Overhaul improper_ctypes output,hanna-kruppe,051ea5cc9bac00c7f588b4eae72b8a382d8ceb68,2,[improper_ctypes] Don't suggest raw pointers when encountering trait objects It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.,HEART,2018-02-14T22:52:29Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/48221,MERGED,2018-02-14T22:26:07Z,2018-02-24T10:30:32Z,Overhaul improper_ctypes output,hanna-kruppe,051ea5cc9bac00c7f588b4eae72b8a382d8ceb68,2,[improper_ctypes] Don't suggest raw pointers when encountering trait objects It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.,HEART,2018-02-14T22:57:49Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/48221,MERGED,2018-02-14T22:26:07Z,2018-02-24T10:30:32Z,Overhaul improper_ctypes output,hanna-kruppe,051ea5cc9bac00c7f588b4eae72b8a382d8ceb68,2,[improper_ctypes] Don't suggest raw pointers when encountering trait objects It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.,HEART,2018-02-15T18:34:26Z,estebank,NA https://github.com/rust-lang/rust/pull/48232,MERGED,2018-02-15T14:37:51Z,2018-02-24T23:28:40Z,mir: Gather move at SwitchInt Assert terminators,fpoli,fe0260fbf892d5b49e79ee310b5e198c72c3d576,1,"mir: Gather move at SwitchInt Assert terminators Previously ""_1"" was not marked as ""definitely uninitialized"" after a ""switchInt(move _1)"" terminator. Related discussion: https://internals.rust-lang.org/t/why-is-2-definitely-initialized-after-switchint-move-2/6760",HEART,2018-02-15T20:56:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48235,MERGED,2018-02-15T15:55:33Z,2018-02-25T17:48:50Z,"Make "".e0"" not parse as 0.0",varkor,c0e87f13a4d2f6fcef92c8c01bdc8dda9e0549a5,2,"Make "".e0"" not parse as 0.0 This forces floats to have either a digit before the separating point or after. Thus "".e0"" is invalid like ""."" when using `parse()`.",HEART,2018-02-15T20:56:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48235,MERGED,2018-02-15T15:55:33Z,2018-02-25T17:48:50Z,"Make "".e0"" not parse as 0.0",varkor,c0e87f13a4d2f6fcef92c8c01bdc8dda9e0549a5,2,"Make "".e0"" not parse as 0.0 This forces floats to have either a digit before the separating point or after. Thus "".e0"" is invalid like ""."" when using `parse()`.",LAUGH,2018-02-28T06:44:12Z,Havvy,NA https://github.com/rust-lang/rust/pull/48235,MERGED,2018-02-15T15:55:33Z,2018-02-25T17:48:50Z,"Make "".e0"" not parse as 0.0",varkor,c0e87f13a4d2f6fcef92c8c01bdc8dda9e0549a5,2,"Make "".e0"" not parse as 0.0 This forces floats to have either a digit before the separating point or after. Thus "".e0"" is invalid like ""."" when using `parse()`.",LAUGH,2018-03-01T07:57:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48236,CLOSED,2018-02-15T16:53:10Z,2018-02-16T18:42:13Z,move Cargo.toml to live alongside x.py,nikomatsakis,NA,NA,NA,THUMBS_UP,2018-02-15T17:24:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48246,MERGED,2018-02-15T22:44:29Z,2018-02-24T23:28:40Z,Avoid ICE in arg mistmatch error for tuple variants,estebank,b9fa2dac25786e67d8332dfa3fe7524ba4c196b9,3,Avoid ICE in arg mistmatch error for tuple variants,THUMBS_UP,2018-02-16T00:26:12Z,FraGag,fragag1@gmail.com https://github.com/rust-lang/rust/pull/48273,MERGED,2018-02-16T13:53:06Z,2018-02-18T20:46:23Z,Add a warning to File about mutability.,alercah,ec905975b85d504abdd428be668346d008bc7a69,1,Wording fixes from review for File.,THUMBS_UP,2018-02-19T00:18:28Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/48273,MERGED,2018-02-16T13:53:06Z,2018-02-18T20:46:23Z,Add a warning to File about mutability.,alercah,ec905975b85d504abdd428be668346d008bc7a69,1,Wording fixes from review for File.,HEART,2018-02-19T00:18:32Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T14:30:26Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T14:36:38Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T14:39:45Z,qmx,qmx@qmx.me https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T14:40:13Z,ollie27,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T14:54:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T15:37:04Z,kennytm,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T15:52:53Z,caemor,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T16:21:59Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T16:22:08Z,killercup,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T17:49:03Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T18:21:43Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-16T19:30:46Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-17T00:49:45Z,estebank,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-22T17:27:22Z,jminer,NA https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-02-26T09:49:39Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48274,MERGED,2018-02-16T14:11:04Z,2018-02-18T20:46:23Z,Remove hoedown from rustdoc,GuillaumeGomez,6661ebb4bd73bfe2ef93f9edcf9c89243ab32e46,1,Remove useless comment,HOORAY,2018-05-10T18:14:18Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/48275,MERGED,2018-02-16T15:00:08Z,2018-02-18T20:46:24Z,fix more typos found by codespell.,matthiaskrgr,4452446292086d9c92ea709eea61a31cedb55e22,69,fix more typos found by codespell.,HEART,2018-02-16T15:18:54Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/48275,MERGED,2018-02-16T15:00:08Z,2018-02-18T20:46:24Z,fix more typos found by codespell.,matthiaskrgr,4452446292086d9c92ea709eea61a31cedb55e22,69,fix more typos found by codespell.,HEART,2018-02-17T00:51:11Z,estebank,NA https://github.com/rust-lang/rust/pull/48275,MERGED,2018-02-16T15:00:08Z,2018-02-18T20:46:24Z,fix more typos found by codespell.,matthiaskrgr,4452446292086d9c92ea709eea61a31cedb55e22,69,fix more typos found by codespell.,HEART,2018-02-17T17:15:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48283,MERGED,2018-02-16T23:02:30Z,2018-03-03T22:22:16Z,add readme for librustdoc,QuietMisdreavus,8d893c1e9e136302a1640035b29e23023f87866e,1,review nits,HOORAY,2018-02-17T00:40:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/48283,MERGED,2018-02-16T23:02:30Z,2018-03-03T22:22:16Z,add readme for librustdoc,QuietMisdreavus,8d893c1e9e136302a1640035b29e23023f87866e,1,review nits,HOORAY,2018-02-17T22:45:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48284,MERGED,2018-02-16T23:24:20Z,2018-02-17T17:28:37Z,Remove unneeded string allocations,crawford,c670ae67b606ccdae475e0db2cddd2f3ece8c7e6,1,Remove unneeded string allocations,THUMBS_UP,2018-02-16T23:33:04Z,retep998,NA https://github.com/rust-lang/rust/pull/48284,MERGED,2018-02-16T23:24:20Z,2018-02-17T17:28:37Z,Remove unneeded string allocations,crawford,c670ae67b606ccdae475e0db2cddd2f3ece8c7e6,1,Remove unneeded string allocations,THUMBS_UP,2018-02-17T11:49:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-17T15:13:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-17T17:57:31Z,sfackler,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-17T20:50:17Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-17T22:21:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-18T12:22:09Z,hcpl,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,THUMBS_UP,2018-02-18T12:39:09Z,mhristache,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-19T01:57:50Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-19T08:28:21Z,estebank,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-20T17:49:12Z,Ryman,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T04:56:41Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T05:30:26Z,Ralith,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T07:47:23Z,izik1,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T09:04:00Z,RalfJung,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T14:10:11Z,bvssvni,bvssvni@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T16:37:25Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T18:14:40Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,THUMBS_UP,2018-02-25T23:15:22Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-25T23:15:22Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-26T10:25:52Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-02-28T23:03:30Z,elwl,NA https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,THUMBS_UP,2018-03-01T05:59:02Z,wuranbo,wuranbo@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-03-01T07:58:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,HEART,2018-05-08T23:28:42Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/48296,MERGED,2018-02-17T14:27:43Z,2018-02-25T04:52:18Z,Fix exponential projection complexity on nested types,ishitatsuyuki,5a2bec9f453f94a64b3d62bb546eed666969d9cf,3,impl_or_trait_obligations: deduplicate obligations,THUMBS_UP,2018-05-10T21:32:22Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/48300,CLOSED,2018-02-17T15:49:06Z,2020-04-15T12:47:10Z,rustc_mir: add a pass for fragmenting locals into their fields (aka SROA).,eddyb,NA,NA,NA,HEART,2020-01-30T14:11:22Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48300,CLOSED,2018-02-17T15:49:06Z,2020-04-15T12:47:10Z,rustc_mir: add a pass for fragmenting locals into their fields (aka SROA).,eddyb,NA,NA,NA,ROCKET,2020-01-30T14:11:24Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48300,CLOSED,2018-02-17T15:49:06Z,2020-04-15T12:47:10Z,rustc_mir: add a pass for fragmenting locals into their fields (aka SROA).,eddyb,NA,NA,NA,HEART,2020-01-30T14:34:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/48305,CLOSED,2018-02-17T20:32:10Z,2018-02-24T20:08:20Z,Remove section about compiler-rt in COPYRIGHT.,frewsxcv,NA,NA,NA,CONFUSED,2018-02-21T16:27:34Z,kennytm,NA https://github.com/rust-lang/rust/pull/48309,MERGED,2018-02-17T23:36:37Z,2018-05-28T00:35:49Z,Make anon params lint warn-by-default,mark-i-m,0e53b788309c446788335b4fbb478490eea1e667,16,Make anon params lint warn-by-default,THUMBS_UP,2018-02-18T02:58:49Z,est31,NA https://github.com/rust-lang/rust/pull/48309,MERGED,2018-02-17T23:36:37Z,2018-05-28T00:35:49Z,Make anon params lint warn-by-default,mark-i-m,0e53b788309c446788335b4fbb478490eea1e667,16,Make anon params lint warn-by-default,THUMBS_UP,2018-03-22T19:38:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48309,MERGED,2018-02-17T23:36:37Z,2018-05-28T00:35:49Z,Make anon params lint warn-by-default,mark-i-m,0e53b788309c446788335b4fbb478490eea1e667,16,Make anon params lint warn-by-default,THUMBS_UP,2018-05-24T19:30:27Z,estebank,NA https://github.com/rust-lang/rust/pull/48309,MERGED,2018-02-17T23:36:37Z,2018-05-28T00:35:49Z,Make anon params lint warn-by-default,mark-i-m,0e53b788309c446788335b4fbb478490eea1e667,16,Make anon params lint warn-by-default,THUMBS_UP,2018-08-24T20:26:33Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/48326,MERGED,2018-02-18T18:56:05Z,2018-03-09T13:23:37Z,Warn about ignored generic bounds in `for`,RalfJung,780b544a391fb2dc42d814ce8cb7e6ad3633fa39,1,note a FIXME,THUMBS_UP,2018-02-18T19:39:53Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_DOWN,2018-02-18T22:50:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-19T21:22:36Z,coder543,coder543@gmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-19T21:25:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-19T23:15:35Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-20T06:11:34Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-20T06:37:33Z,AronParker,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-21T23:26:34Z,archer884,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-22T15:02:55Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2018-02-22T22:52:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2018-02-27T09:52:55Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-27T12:09:51Z,WaDelma,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_DOWN,2018-02-27T12:15:07Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_DOWN,2018-02-27T13:08:17Z,chenxiaolong,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-27T15:56:48Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-02-27T17:37:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-03-07T08:14:18Z,danclive,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2018-04-02T04:31:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-04-04T04:45:21Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_DOWN,2018-04-04T20:07:12Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,CONFUSED,2018-04-04T20:07:16Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-04-04T21:11:49Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-04-05T09:35:43Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-04-07T08:29:46Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2018-04-07T08:29:48Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_DOWN,2018-04-07T12:03:39Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-04-20T14:48:51Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,CONFUSED,2018-10-01T20:38:01Z,JesseWright,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2018-10-01T20:38:08Z,JesseWright,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2019-01-13T16:35:10Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2019-01-13T16:35:11Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2019-08-09T13:28:43Z,rivertam,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,THUMBS_UP,2021-09-09T14:09:48Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/48333,MERGED,2018-02-18T22:13:40Z,2018-04-04T03:48:07Z,Remove all unstable placement features,aidanhs,9b5859aea199d5f34a4d4b5ae7112c5c41f3b242,41,Remove all unstable placement features Closes #22181 #27779,HEART,2021-09-09T14:09:50Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HEART,2018-02-19T08:59:28Z,killercup,NA https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HEART,2018-02-20T19:23:58Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HEART,2018-02-22T17:44:45Z,erinzm,NA https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HOORAY,2018-02-23T22:05:35Z,isislovecruft,isis@patternsinthevoid.net https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HOORAY,2018-02-28T07:01:00Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/48335,MERGED,2018-02-18T22:57:51Z,2018-02-22T14:23:24Z,Implement implied shortcut links for intra-rustdoc-links,Manishearth,5fdc10c68b3b5a42b17555be18baf5d7d60d55e6,1,Filter out non-macros in resolve_macro Fixes https://github.com/rust-lang/rust/issues/48341,HEART,2018-02-28T07:01:02Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/48338,MERGED,2018-02-18T23:14:28Z,2018-03-03T10:07:02Z,Provide context for missing comma in match arm and if statement without block,estebank,24be75d420bf316cb09c179781d6c1c63636fbc1,2,fix rebase,HEART,2018-02-18T23:46:28Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/48338,MERGED,2018-02-18T23:14:28Z,2018-03-03T10:07:02Z,Provide context for missing comma in match arm and if statement without block,estebank,24be75d420bf316cb09c179781d6c1c63636fbc1,2,fix rebase,HEART,2018-02-19T11:29:18Z,killercup,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-02-19T09:11:33Z,NotBad4U,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-19T10:54:46Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-19T11:47:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-19T20:22:11Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-20T06:13:17Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-20T06:43:57Z,andjo403,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-20T07:31:20Z,cpeterso,cpeterson@mozilla.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-24T09:08:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-02-28T06:00:13Z,robsmith11,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-03-07T02:53:08Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-03-07T10:44:34Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-03-19T18:12:54Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-03-19T18:12:56Z,wdv4758h,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-03-20T11:54:50Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-03-20T18:07:47Z,delacian,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-03-28T14:58:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-03-28T19:59:02Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-03-28T20:29:21Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-03-29T03:53:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-04-02T13:39:43Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-04-03T23:29:50Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HEART,2018-04-03T23:29:53Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HOORAY,2018-04-03T23:29:56Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,THUMBS_UP,2018-04-04T09:40:39Z,jsagarribay,NA https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HOORAY,2018-04-04T11:22:30Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/48346,MERGED,2018-02-19T02:06:21Z,2018-03-26T15:48:07Z,Add basic PGO support.,emilio,1e1d907e6a407a474d46af343678e45c4eb327f9,1,pgo: Blindly try to fix Windows build.,HOORAY,2018-04-04T14:13:27Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/48353,MERGED,2018-02-19T15:54:21Z,2018-02-24T23:28:46Z,Allow for instantiating statics from upstream crates,michaelwoerister,89b3ef3e8eae1a9cf119888341509e10fd7e1b9a,2,Allow for instantiating statics from upstream crates.,HOORAY,2018-02-19T22:42:18Z,retep998,NA https://github.com/rust-lang/rust/pull/48353,MERGED,2018-02-19T15:54:21Z,2018-02-24T23:28:46Z,Allow for instantiating statics from upstream crates,michaelwoerister,89b3ef3e8eae1a9cf119888341509e10fd7e1b9a,2,Allow for instantiating statics from upstream crates.,HOORAY,2018-02-21T20:05:52Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48359,MERGED,2018-02-19T20:51:16Z,2018-03-01T02:09:16Z,Implement --remap-path-prefix,jsgf,56a68285332000c858e9aeba7d66a4ec66ebff91,10,Implement --remap-path-prefix Remove experimental -Zremap-path-prefix-from/to and replace it with the stabilized --remap-path-prefix=from=to variant. This is an implementation for issue of #41555.,HEART,2018-02-21T17:56:18Z,fitzgen,NA https://github.com/rust-lang/rust/pull/48359,MERGED,2018-02-19T20:51:16Z,2018-03-01T02:09:16Z,Implement --remap-path-prefix,jsgf,56a68285332000c858e9aeba7d66a4ec66ebff91,10,Implement --remap-path-prefix Remove experimental -Zremap-path-prefix-from/to and replace it with the stabilized --remap-path-prefix=from=to variant. This is an implementation for issue of #41555.,HOORAY,2018-02-21T17:56:20Z,fitzgen,NA https://github.com/rust-lang/rust/pull/48359,MERGED,2018-02-19T20:51:16Z,2018-03-01T02:09:16Z,Implement --remap-path-prefix,jsgf,56a68285332000c858e9aeba7d66a4ec66ebff91,10,Implement --remap-path-prefix Remove experimental -Zremap-path-prefix-from/to and replace it with the stabilized --remap-path-prefix=from=to variant. This is an implementation for issue of #41555.,HEART,2018-02-21T18:27:06Z,estebank,NA https://github.com/rust-lang/rust/pull/48359,MERGED,2018-02-19T20:51:16Z,2018-03-01T02:09:16Z,Implement --remap-path-prefix,jsgf,56a68285332000c858e9aeba7d66a4ec66ebff91,10,Implement --remap-path-prefix Remove experimental -Zremap-path-prefix-from/to and replace it with the stabilized --remap-path-prefix=from=to variant. This is an implementation for issue of #41555.,HOORAY,2018-03-15T11:14:49Z,luser,NA https://github.com/rust-lang/rust/pull/48366,CLOSED,2018-02-20T05:34:07Z,2018-03-08T23:34:16Z,HashMap HashSet: impl Hash,Centril,NA,NA,NA,THUMBS_UP,2018-02-20T12:45:35Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/48366,CLOSED,2018-02-20T05:34:07Z,2018-03-08T23:34:16Z,HashMap HashSet: impl Hash,Centril,NA,NA,NA,THUMBS_UP,2020-04-17T02:04:57Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/48366,CLOSED,2018-02-20T05:34:07Z,2018-03-08T23:34:16Z,HashMap HashSet: impl Hash,Centril,NA,NA,NA,THUMBS_UP,2021-03-20T18:11:13Z,mankinskin,linusbehrbohm@web.de https://github.com/rust-lang/rust/pull/48366,CLOSED,2018-02-20T05:34:07Z,2018-03-08T23:34:16Z,HashMap HashSet: impl Hash,Centril,NA,NA,NA,THUMBS_UP,2021-12-15T13:17:28Z,ThrashAbaddon,NA https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-02-20T16:03:17Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HEART,2018-02-20T16:03:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-02-20T16:26:10Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-02-20T17:15:03Z,cramertj,NA https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-02-20T19:12:33Z,retep998,NA https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HEART,2018-02-20T20:34:04Z,lqd,NA https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-02-20T20:34:05Z,lqd,NA https://github.com/rust-lang/rust/pull/48373,CLOSED,2018-02-20T15:48:47Z,2018-03-01T13:04:56Z,[experimental] Allow for RLIBs to only contain metadata.,michaelwoerister,NA,NA,NA,HOORAY,2018-03-02T02:34:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/48380,MERGED,2018-02-20T18:51:53Z,2018-03-01T02:09:17Z,make `#[unwind]` attribute specify expectations more clearly,nikomatsakis,566c6ac6bac479d4977339fc91bb497cb96342c6,1,add `unwind_attributes` feature,THUMBS_UP,2018-04-02T20:08:41Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-20T21:50:31Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-20T22:05:58Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-20T22:17:16Z,ashleygwilliams,NA https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-20T22:41:24Z,chordowl,NA https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-21T07:30:44Z,kelseasy,key@kelseyz.org https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-21T08:51:19Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,THUMBS_UP,2018-02-21T08:52:14Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,THUMBS_UP,2018-02-21T09:02:41Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,HEART,2018-02-21T20:15:15Z,killercup,NA https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,THUMBS_UP,2018-02-27T06:20:14Z,llogiq,NA https://github.com/rust-lang/rust/pull/48386,MERGED,2018-02-20T21:39:13Z,2018-02-25T04:52:22Z,Add nonstandard_style alias for bad_style.,withoutboats,5949d8b2d7b2bd01cfa454b029e7d921aedd7e27,1,Fix internal references to bad_style in test code.,THUMBS_UP,2018-02-28T00:39:21Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-21T19:29:34Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-21T20:14:58Z,killercup,NA https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-21T20:37:28Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-21T22:37:15Z,estebank,NA https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-22T00:38:19Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-22T05:18:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-22T12:28:11Z,chriskrycho,ckrycho@linkedin.com https://github.com/rust-lang/rust/pull/48404,MERGED,2018-02-21T19:27:16Z,2018-02-25T04:52:23Z,Update the book to promote second edition,steveklabnik,ef48e0f2b91117898b71f5c85fddf6619c434753,1,Update the book to promote second edition This updates the book repository but mostly to include https://github.com/rust-lang/book/pull/1180 TL;DR: the second edition is close enough to done that we should universally recommend it over the first edition.,HEART,2018-02-23T02:22:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48411,MERGED,2018-02-21T22:21:12Z,2018-03-13T18:21:19Z,introduce canonical queries use for normalization and dropck-outlives,nikomatsakis,17c4103f3f0cc8bd4dea9de5e7ef155daf363cfe,1,"add ""text"" sections for things that seem likely to be a problem",HOORAY,2018-02-23T18:01:00Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/48411,MERGED,2018-02-21T22:21:12Z,2018-03-13T18:21:19Z,introduce canonical queries use for normalization and dropck-outlives,nikomatsakis,17c4103f3f0cc8bd4dea9de5e7ef155daf363cfe,1,"add ""text"" sections for things that seem likely to be a problem",HOORAY,2018-03-22T12:52:52Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48430,CLOSED,2018-02-22T15:03:24Z,2018-03-05T09:54:35Z,Removed ascii_ctype,hellow554,NA,NA,NA,THUMBS_UP,2018-02-22T16:02:41Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48432,MERGED,2018-02-22T15:17:09Z,2018-03-06T18:08:26Z,Suggest type for overflowing bin/hex-literals,flip1995,fc33b2567cac0ae453807f4118872ab81a16ddf7,1,Improve getting literal representation,HEART,2018-02-23T19:23:44Z,estebank,NA https://github.com/rust-lang/rust/pull/48432,MERGED,2018-02-22T15:17:09Z,2018-03-06T18:08:26Z,Suggest type for overflowing bin/hex-literals,flip1995,fc33b2567cac0ae453807f4118872ab81a16ddf7,1,Improve getting literal representation,HEART,2018-03-15T16:10:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-02-23T00:57:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,HOORAY,2018-02-23T00:57:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-02-23T08:48:37Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-03-07T20:42:45Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,THUMBS_UP,2018-03-08T16:49:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48450,MERGED,2018-02-23T00:54:39Z,2018-02-28T14:22:50Z,Stabilize [T]::rotate_{left right},frewsxcv,b1a6c8bdd3a76207eff76b004945bc2a13755eca,6,Stabilize [T]::rotate_{left right} https://github.com/rust-lang/rust/issues/41891,HOORAY,2018-03-26T18:26:30Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/48456,MERGED,2018-02-23T02:00:54Z,2018-03-06T03:47:15Z,Whitelist rustc dependencies,mark-i-m,e5d292013be6a0074d185e0de4c563545a4ed755,1,Add ena to whitelist,HEART,2018-02-23T02:19:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48456,MERGED,2018-02-23T02:00:54Z,2018-03-06T03:47:15Z,Whitelist rustc dependencies,mark-i-m,e5d292013be6a0074d185e0de4c563545a4ed755,1,Add ena to whitelist,HEART,2018-02-23T21:57:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48456,MERGED,2018-02-23T02:00:54Z,2018-03-06T03:47:15Z,Whitelist rustc dependencies,mark-i-m,e5d292013be6a0074d185e0de4c563545a4ed755,1,Add ena to whitelist,HEART,2018-02-24T13:09:26Z,repi,NA https://github.com/rust-lang/rust/pull/48461,MERGED,2018-02-23T08:25:41Z,2018-03-01T02:09:20Z,Add functionality for epoch lints; add epoch lint for dyn-trait,Manishearth,0cb367266b0a336c0a18ae999beeadd3235961a2,2,Emit parentheses in suggestion for global paths,HOORAY,2018-02-25T21:19:48Z,mcarton,NA https://github.com/rust-lang/rust/pull/48461,MERGED,2018-02-23T08:25:41Z,2018-03-01T02:09:20Z,Add functionality for epoch lints; add epoch lint for dyn-trait,Manishearth,0cb367266b0a336c0a18ae999beeadd3235961a2,2,Emit parentheses in suggestion for global paths,HOORAY,2018-03-09T21:52:41Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48465,CLOSED,2018-02-23T10:52:16Z,2018-04-01T23:35:28Z,Expand items before their derives,abonander,NA,NA,NA,THUMBS_UP,2018-03-08T00:39:23Z,jseyfried,NA https://github.com/rust-lang/rust/pull/48474,MERGED,2018-02-23T18:01:22Z,2018-03-06T18:08:27Z,New Cell docs,pvdrz,9091584def3b566f24f8fbeac495e6dc87178be8,1,some grammar corrections,THUMBS_UP,2018-02-28T07:19:31Z,Havvy,NA https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,HOORAY,2018-02-23T22:10:05Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,THUMBS_DOWN,2018-02-23T22:34:50Z,theotherphil,NA https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,HOORAY,2018-02-23T23:59:43Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,HOORAY,2018-02-25T21:19:27Z,mcarton,NA https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,HOORAY,2018-03-08T03:35:58Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/48477,MERGED,2018-02-23T18:31:15Z,2018-03-03T10:07:06Z,Use `dyn trait` everywhere,Manishearth,40f218f7035a533c921417c240ebdd5a5de8502d,1,Remove allow(bare_trait_object) from librustc_mir,THUMBS_UP,2018-03-20T16:31:54Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/48479,MERGED,2018-02-23T19:29:06Z,2018-02-28T14:22:52Z,Start moving to the rustc guide!,mark-i-m,7a82da1c4d3c5cb3e7bfa0dc43337842a677943c,1,tidy fix,HEART,2018-02-23T23:16:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48491,MERGED,2018-02-24T00:21:04Z,2018-02-25T17:49:04Z,test: Fix s390x-unknown-linux-gnu atomic-lock-free test not run for systemz,glaubitz,e3781c65852f7624fd58b723b66be7470cb41ea0,1,test: Fix s390x-unknown-linux-gnu atomic-lock-free test not run for systemz,THUMBS_UP,2018-02-24T01:30:05Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-02-25T08:21:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-02-26T05:34:55Z,estebank,NA https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-02-26T16:04:58Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-02-27T00:30:15Z,durka,NA https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-02-27T05:09:30Z,qnighy,NA https://github.com/rust-lang/rust/pull/48500,MERGED,2018-02-24T12:36:30Z,2018-03-02T08:55:55Z,Support parentheses in patterns under feature gate,petrochenkov,c9aff92e6dc3ea43228d3d4e24ee7f5485943569,12,Support parentheses in patterns under feature gate Improve recovery for trailing comma after `..`,HOORAY,2018-03-09T13:02:22Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48503,MERGED,2018-02-24T14:02:22Z,2018-02-25T04:52:31Z,Remove directory `src/rt`,petrochenkov,aafebbcba97a89cedafe82a2142e367bafa607b2,2,Remove directory `src/rt`,HOORAY,2018-02-24T14:29:19Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-24T19:54:33Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-24T21:40:26Z,sfackler,NA https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-25T17:29:53Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-26T11:40:47Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-27T09:40:18Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-02-28T08:51:40Z,zolkko,NA https://github.com/rust-lang/rust/pull/48513,MERGED,2018-02-24T19:14:37Z,2018-03-03T22:22:23Z,std: Add `arch` and `simd` modules,alexcrichton,c72537f20442c9afd0f2f90999163adb43f34953,5,std: Add `arch` and `simd` modules This commit imports the `stdsimd` crate into the standard library creating an `arch` and `simd` module inside of both libcore and libstd. Both of these modules are **unstable** and will continue to be so until RFC 2335 is stabilized. As a brief recap the modules are organized as so: * `arch` contains all current architectures with intrinsics for example `std::arch::x86` `std::arch::x86_64` `std::arch::arm` etc. These modules contain all of the intrinsics defined for the platform like `_mm_set1_epi8`. * In the standard library the `arch` module also exports a `is_target_feature_detected` macro which performs runtime detection to determine whether a target feature is available at runtime. * The `simd` module contains experimental versions of strongly-typed lane-aware SIMD primitives to be fully fleshed out in a future RFC. The main purpose of this commit is to start pulling in all these intrinsics and such into the standard library on nightly and allow testing and such. This'll help allow users to easily kick the tires and see if intrinsics work as well as allow us to test out all the infrastructure for moving the intrinsics into the standard library.,HOORAY,2018-03-05T00:50:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-25T01:35:20Z,tinaun,NA https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-25T01:51:52Z,repnop,NA https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-25T02:59:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-25T03:58:57Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-25T08:33:44Z,mitchmindtree,mail@mitchellnordine.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-02-26T16:04:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-03-07T10:10:38Z,bb010g,NA https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-03-08T10:13:19Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-03-19T20:44:13Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-05-08T07:39:25Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/48516,MERGED,2018-02-24T20:39:22Z,2018-03-20T10:18:46Z,Stabilize slice patterns without `..`,petrochenkov,7c90189e1331cea3eac0ab0e8959f664cffba1ae,75,Stabilize slice patterns without `..` Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`,HOORAY,2018-05-10T07:40:01Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/48522,MERGED,2018-02-25T00:48:42Z,2018-03-02T08:55:56Z,Fix find_width_of_character_at_span bounds check,etaoins,363d6040fdac7baa8eb18a804f02832fec5ad35f,1,Add ignore-pretty for issue-48506.rs The out-of-line module #37195,THUMBS_UP,2018-02-25T10:02:11Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/48522,MERGED,2018-02-25T00:48:42Z,2018-03-02T08:55:56Z,Fix find_width_of_character_at_span bounds check,etaoins,363d6040fdac7baa8eb18a804f02832fec5ad35f,1,Add ignore-pretty for issue-48506.rs The out-of-line module #37195,THUMBS_UP,2018-02-26T01:10:48Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/48522,MERGED,2018-02-25T00:48:42Z,2018-03-02T08:55:56Z,Fix find_width_of_character_at_span bounds check,etaoins,363d6040fdac7baa8eb18a804f02832fec5ad35f,1,Add ignore-pretty for issue-48506.rs The out-of-line module #37195,THUMBS_UP,2018-02-26T05:31:53Z,estebank,NA https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-02-25T06:28:10Z,kennytm,NA https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-03-02T19:32:27Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-03-04T03:04:54Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-03-23T08:44:31Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-04-17T17:23:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-04-24T19:42:28Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-04-28T17:37:48Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-04-28T17:37:49Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-05-03T16:21:23Z,pmarks,pmarks@gmail.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-05-16T20:40:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-05-16T20:40:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-05-20T21:54:29Z,hcpl,NA https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-06-03T01:07:25Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-06-03T05:21:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-06-12T12:29:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-06-14T13:34:12Z,zzeroo,co@zzeroo.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,LAUGH,2018-06-14T13:34:14Z,zzeroo,co@zzeroo.com https://github.com/rust-lang/rust/pull/48523,MERGED,2018-02-25T01:08:05Z,2018-05-16T01:43:29Z,The Great Generics Generalisation: Ty Edition,varkor,5be2bdb498249d71a4a5671f73224727784a1203,1,One must always remember to clean up after themselves,THUMBS_UP,2018-12-15T17:14:45Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/48524,MERGED,2018-02-25T03:16:06Z,2018-03-16T05:20:58Z,check stability of macro invocations,abonander,69035f20b92870a7ad5dbc22c65aee971d8f8698,10,check stability of macro invocations,THUMBS_UP,2018-03-01T19:45:04Z,jseyfried,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,THUMBS_UP,2018-02-25T09:15:20Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,THUMBS_UP,2018-02-25T13:49:24Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,THUMBS_UP,2018-02-25T21:35:18Z,estebank,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,HOORAY,2018-02-26T06:36:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,HEART,2018-03-03T00:03:14Z,krdln,NA https://github.com/rust-lang/rust/pull/48527,MERGED,2018-02-25T05:13:35Z,2018-03-09T06:29:25Z,in which parentheses are suggested for should-have-been-tuple-patterns,zackmdavis,1f04597c3ca3af45236ecb496bd30db5c57daae9,3,in which parentheses are suggested for should-have-been-tuple-patterns Programmers used to working in some other languages (such as Python or Go) might expect to be able to destructure values with comma-separated identifiers but no parentheses on the left side of an assignment. Previously the first name in such code would get parsed as a single-indentifier pattern—recognizing for example the `let a` in `let a b = (1 2);`—whereupon we would have a fatal syntax error on seeing an unexpected comma rather than the expected semicolon (all the way nearer to the end of `parse_full_stmt`). Instead let's look for that comma when parsing the pattern and if we see it momentarily make-believe that we're parsing the remaining elements in a tuple pattern so that we can suggest wrapping it all in parentheses. We need to do this in a separate wrapper method called on the top-level pattern (or `|`-patterns) in a `let` statement `for` loop `if`- or `while let` expression or match arm rather than within `parse_pat` itself because `parse_pat` gets called recursively to parse the sub-patterns within a tuple pattern. Resolves #48492.,THUMBS_UP,2018-03-09T16:29:49Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/48528,MERGED,2018-02-25T05:22:42Z,2018-04-12T05:38:50Z,Implementation of `#[repr(packed(n))]` RFC 1399.,bitshifter,15d1c4d2139611fcb87a2c802bd015b5f4f0aed8,26,Implementation of `#[repr(packed(n))]` RFC 1399.,HOORAY,2018-02-25T06:16:00Z,IvanUkhov,ivan.ukhov@gmail.com https://github.com/rust-lang/rust/pull/48528,MERGED,2018-02-25T05:22:42Z,2018-04-12T05:38:50Z,Implementation of `#[repr(packed(n))]` RFC 1399.,bitshifter,15d1c4d2139611fcb87a2c802bd015b5f4f0aed8,26,Implementation of `#[repr(packed(n))]` RFC 1399.,HOORAY,2018-02-25T09:06:35Z,yandexx,yandexx@gmail.com https://github.com/rust-lang/rust/pull/48528,MERGED,2018-02-25T05:22:42Z,2018-04-12T05:38:50Z,Implementation of `#[repr(packed(n))]` RFC 1399.,bitshifter,15d1c4d2139611fcb87a2c802bd015b5f4f0aed8,26,Implementation of `#[repr(packed(n))]` RFC 1399.,HOORAY,2018-02-26T13:18:48Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/48529,MERGED,2018-02-25T05:50:43Z,2018-02-25T17:49:08Z,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,remexre,64236092e5aa8fca2b9175df5a1192fd3d46e29b,3,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,LAUGH,2018-02-25T08:17:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48529,MERGED,2018-02-25T05:50:43Z,2018-02-25T17:49:08Z,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,remexre,64236092e5aa8fca2b9175df5a1192fd3d46e29b,3,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,LAUGH,2018-02-25T09:03:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/48529,MERGED,2018-02-25T05:50:43Z,2018-02-25T17:49:08Z,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,remexre,64236092e5aa8fca2b9175df5a1192fd3d46e29b,3,Fixes docs for ASCII functions to no longer claim U+0021 is '@'.,LAUGH,2018-02-25T15:39:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48544,CLOSED,2018-02-26T11:09:04Z,2018-03-10T07:50:20Z,Produce better size_hints from Flatten & FlatMap,scottmcm,NA,NA,NA,HEART,2018-03-09T18:16:00Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/48544,CLOSED,2018-02-26T11:09:04Z,2018-03-10T07:50:20Z,Produce better size_hints from Flatten & FlatMap,scottmcm,NA,NA,NA,HEART,2020-09-26T08:41:05Z,pythonesque,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-26T19:48:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-26T19:54:23Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-26T19:55:20Z,sfackler,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HOORAY,2018-02-26T19:55:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-26T20:07:46Z,bluss,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-26T20:50:52Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HOORAY,2018-02-27T11:00:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-27T11:00:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-02-28T19:13:08Z,jminer,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HOORAY,2018-03-01T09:10:24Z,Lymia,lymia@lymiahugs.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-03-04T06:59:40Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-03-08T17:49:24Z,estebank,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HOORAY,2018-03-21T12:45:26Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-05-07T11:15:38Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2018-06-13T05:51:10Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2019-03-20T15:10:25Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HOORAY,2019-03-20T15:10:28Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2019-03-20T20:02:09Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/48552,MERGED,2018-02-26T19:07:12Z,2018-03-24T07:18:35Z,Lower the priority of unstable methods when picking a candidate.,kennytm,17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7,1,Track IsSuggestion in ProbeContext. Don't warn stability for suggestions.,HEART,2019-10-22T14:24:38Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/48553,MERGED,2018-02-26T19:40:01Z,2018-04-20T01:41:38Z,atomic: remove 'Atomic*' from Debug output,seanmonstar,c689db2c463f42422ff4ee47e28ebeb2865951ba,1,atomic: remove 'Atomic*' from Debug output,THUMBS_UP,2018-04-25T11:54:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48553,MERGED,2018-02-26T19:40:01Z,2018-04-20T01:41:38Z,atomic: remove 'Atomic*' from Debug output,seanmonstar,c689db2c463f42422ff4ee47e28ebeb2865951ba,1,atomic: remove 'Atomic*' from Debug output,THUMBS_DOWN,2018-06-22T01:44:14Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/48553,MERGED,2018-02-26T19:40:01Z,2018-04-20T01:41:38Z,atomic: remove 'Atomic*' from Debug output,seanmonstar,c689db2c463f42422ff4ee47e28ebeb2865951ba,1,atomic: remove 'Atomic*' from Debug output,THUMBS_UP,2021-06-21T10:23:36Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/48557,MERGED,2018-02-26T21:32:24Z,2018-05-16T11:18:06Z,Implement RFC 2056 trivial constraints in where clauses,matthewjasper,be2900c33b043ca2002bdb11870e8d26c3e410f3,7,Make is_global true for latebound regions,HEART,2018-02-27T07:42:34Z,cramertj,NA https://github.com/rust-lang/rust/pull/48567,CLOSED,2018-02-27T00:28:20Z,2018-02-27T03:54:17Z,rustc: Use custom personality functions on MSVC,alexcrichton,NA,NA,NA,HEART,2018-02-27T01:01:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48567,CLOSED,2018-02-27T00:28:20Z,2018-02-27T03:54:17Z,rustc: Use custom personality functions on MSVC,alexcrichton,NA,NA,NA,HEART,2018-02-27T01:55:58Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/48567,CLOSED,2018-02-27T00:28:20Z,2018-02-27T03:54:17Z,rustc: Use custom personality functions on MSVC,alexcrichton,NA,NA,NA,HEART,2018-02-27T04:04:31Z,kyren,kyren@kyju.org https://github.com/rust-lang/rust/pull/48567,CLOSED,2018-02-27T00:28:20Z,2018-02-27T03:54:17Z,rustc: Use custom personality functions on MSVC,alexcrichton,NA,NA,NA,HEART,2018-02-27T15:12:45Z,OmnipotentEntity,NA https://github.com/rust-lang/rust/pull/48567,CLOSED,2018-02-27T00:28:20Z,2018-02-27T03:54:17Z,rustc: Use custom personality functions on MSVC,alexcrichton,NA,NA,NA,HEART,2020-04-30T18:28:28Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/48569,MERGED,2018-02-27T01:54:41Z,2018-03-03T22:22:25Z,Improve --help performance for x.py,Phlosioneer,2269ff521fe2a945e462d5156799011c5fce2966,1,Remove print_what_bootstrap_means It was an existing solution to tell the user why a --help command takes a long time to process. However it would only print if the stage0 rust compiler needed to be downloaded it came after update_submodules (which took a long time) and it was immediately followed by download messages and loading bars meaning users could easily gloss over the message. This commit also moves the help message out of main() and instead puts it at the top of bootstrap(). main() is intended to be minimal only handling error messages.,HEART,2018-02-27T05:37:15Z,andjo403,NA https://github.com/rust-lang/rust/pull/48572,MERGED,2018-02-27T03:53:58Z,2018-03-02T08:56:00Z,rustc: Tweak funclet cleanups of ffi functions,alexcrichton,804666f4ad5a66e6a1bae3b2e326efa030135a05,4,"rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups accidentally running the ""abort the program"" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to ""accidentally"" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp so we'll probably still recommend ""don't have destructors on the stack"" but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.",THUMBS_UP,2018-02-27T04:12:23Z,kyren,kyren@kyju.org https://github.com/rust-lang/rust/pull/48572,MERGED,2018-02-27T03:53:58Z,2018-03-02T08:56:00Z,rustc: Tweak funclet cleanups of ffi functions,alexcrichton,804666f4ad5a66e6a1bae3b2e326efa030135a05,4,"rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups accidentally running the ""abort the program"" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to ""accidentally"" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp so we'll probably still recommend ""don't have destructors on the stack"" but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.",THUMBS_UP,2018-03-02T02:31:23Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/48572,MERGED,2018-02-27T03:53:58Z,2018-03-02T08:56:00Z,rustc: Tweak funclet cleanups of ffi functions,alexcrichton,804666f4ad5a66e6a1bae3b2e326efa030135a05,4,"rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups accidentally running the ""abort the program"" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to ""accidentally"" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp so we'll probably still recommend ""don't have destructors on the stack"" but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.",THUMBS_UP,2018-03-02T08:26:07Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/48572,MERGED,2018-02-27T03:53:58Z,2018-03-02T08:56:00Z,rustc: Tweak funclet cleanups of ffi functions,alexcrichton,804666f4ad5a66e6a1bae3b2e326efa030135a05,4,"rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups accidentally running the ""abort the program"" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to ""accidentally"" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp so we'll probably still recommend ""don't have destructors on the stack"" but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.",THUMBS_UP,2019-09-19T20:04:37Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/48572,MERGED,2018-02-27T03:53:58Z,2018-03-02T08:56:00Z,rustc: Tweak funclet cleanups of ffi functions,alexcrichton,804666f4ad5a66e6a1bae3b2e326efa030135a05,4,"rustc: Tweak funclet cleanups of ffi functions This commit is targeted at addressing #48251 by specifically fixing a case where a longjmp over Rust frames on MSVC runs cleanups accidentally running the ""abort the program"" cleanup as well. Added in #46833 `extern` ABI functions in Rust will abort the process if Rust panics and currently this is modeled as a normal cleanup like all other destructors. Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH the same mechanism used to implement panics in Rust. This means that `longjmp` over Rust frames will run Rust cleanups (even though we don't necessarily want it to). Notably this means that if you `longjmp` over a Rust stack frame then that probably means you'll abort the program because one of the cleanups will abort the process. After some discussion on IRC it turns out that `longjmp` doesn't run cleanups for *caught* exceptions it only runs cleanups for cleanup pads. Using this information this commit tweaks the codegen for an `extern` function to a catch-all clause for exceptions instead of a cleanup block. This catch-all is equivalent to the C++ code: try { foo(); } catch (...) { bar(); } and in fact our codegen here is designed to match exactly what clang emits for that C++ code! With this tweak a longjmp over Rust code will no longer abort the process. A longjmp will continue to ""accidentally"" run Rust cleanups (destructors) on MSVC. Other non-MSVC platforms will not rust destructors with a longjmp so we'll probably still recommend ""don't have destructors on the stack"" but in any case this is a more surgical fix than #48567 and should help us stick to standard personality functions a bit longer.",HEART,2020-04-30T18:28:47Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/48573,MERGED,2018-02-27T04:38:41Z,2018-03-06T18:08:31Z,Add functions for reversing the bit pattern in an integer,Amanieu,88aec91017bf7def8401f47f3f90acd25882a2da,1,Add i128 tests for intrinsics,HEART,2018-02-27T23:32:03Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48573,MERGED,2018-02-27T04:38:41Z,2018-03-06T18:08:31Z,Add functions for reversing the bit pattern in an integer,Amanieu,88aec91017bf7def8401f47f3f90acd25882a2da,1,Add i128 tests for intrinsics,HEART,2018-02-28T06:28:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48573,MERGED,2018-02-27T04:38:41Z,2018-03-06T18:08:31Z,Add functions for reversing the bit pattern in an integer,Amanieu,88aec91017bf7def8401f47f3f90acd25882a2da,1,Add i128 tests for intrinsics,HEART,2018-02-28T19:05:12Z,jminer,NA https://github.com/rust-lang/rust/pull/48576,MERGED,2018-02-27T08:30:55Z,2018-02-28T01:39:08Z,Bring back ParamEnv deduplication,ishitatsuyuki,f297f56e767ea440672b4d5996770afd478401b2,1,Bring back ParamEnv deduplication,HOORAY,2018-02-28T02:01:46Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/48590,MERGED,2018-02-27T18:59:45Z,2018-03-06T18:08:32Z,doc: no need for the reference,tshepang,df8dd3fd3ef2080c01360db38de610c13db1766e,1,doc: no need for the references Also: - apply some rustfmt love - fix output of one example,THUMBS_UP,2018-02-27T19:28:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/48599,MERGED,2018-02-28T01:17:51Z,2018-03-11T20:28:43Z,Remove ONLY_BUILD and ONLY_BUILD_TARGETS,Mark-Simulacrum,29a852970bf6ac9abee1a637727ed03d1888d582,2,Refactor run_host_only to have the proper effect. Previously it was set to true when we didn't run HOSTS steps.,THUMBS_UP,2018-03-02T12:28:53Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/48602,CLOSED,2018-02-28T04:16:13Z,2018-03-20T07:59:36Z,rustc_mir: always run the inlining pass.,eddyb,NA,NA,NA,HEART,2018-02-28T09:26:04Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/48611,MERGED,2018-02-28T15:16:56Z,2018-03-06T15:00:19Z,Don't recompute SymbolExportLevel for upstream crates.,michaelwoerister,f5ab4d4cdd1a8eda860628e97b619da8c10ac7b3,4,Don't show crate metadata symbol as exported symbol to downstream crates.,HEART,2018-02-28T15:49:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48611,MERGED,2018-02-28T15:16:56Z,2018-03-06T15:00:19Z,Don't recompute SymbolExportLevel for upstream crates.,michaelwoerister,f5ab4d4cdd1a8eda860628e97b619da8c10ac7b3,4,Don't show crate metadata symbol as exported symbol to downstream crates.,HEART,2018-02-28T16:20:56Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48611,MERGED,2018-02-28T15:16:56Z,2018-03-06T15:00:19Z,Don't recompute SymbolExportLevel for upstream crates.,michaelwoerister,f5ab4d4cdd1a8eda860628e97b619da8c10ac7b3,4,Don't show crate metadata symbol as exported symbol to downstream crates.,HEART,2018-03-01T15:15:40Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/48611,MERGED,2018-02-28T15:16:56Z,2018-03-06T15:00:19Z,Don't recompute SymbolExportLevel for upstream crates.,michaelwoerister,f5ab4d4cdd1a8eda860628e97b619da8c10ac7b3,4,Don't show crate metadata symbol as exported symbol to downstream crates.,HEART,2018-03-01T17:03:03Z,kennytm,NA https://github.com/rust-lang/rust/pull/48611,MERGED,2018-02-28T15:16:56Z,2018-03-06T15:00:19Z,Don't recompute SymbolExportLevel for upstream crates.,michaelwoerister,f5ab4d4cdd1a8eda860628e97b619da8c10ac7b3,4,Don't show crate metadata symbol as exported symbol to downstream crates.,HEART,2018-03-05T13:10:27Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/48624,MERGED,2018-02-28T23:43:07Z,2018-03-23T21:41:44Z,Command: Support posix_spawn() on FreeBSD/OSX/GNU Linux,bdrewery,70559c54ce2a493a15f447436e281e16fc55b291,1,Command::env_saw_path() may be unused on platforms not using posix_spawn(),THUMBS_UP,2018-03-02T12:31:24Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/48631,MERGED,2018-03-01T07:09:47Z,2018-03-13T02:41:55Z,Remember state of top-level collapse toggle widget,focusaurus,2dd81c86c51435ed57d7a2b16f1b66c254a64cc8,1,Rename doc collapse sentinal to rustdoc-collapse,THUMBS_UP,2018-03-08T17:17:29Z,jminer,NA https://github.com/rust-lang/rust/pull/48631,MERGED,2018-03-01T07:09:47Z,2018-03-13T02:41:55Z,Remember state of top-level collapse toggle widget,focusaurus,2dd81c86c51435ed57d7a2b16f1b66c254a64cc8,1,Rename doc collapse sentinal to rustdoc-collapse,THUMBS_UP,2018-03-12T19:38:46Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-03-01T14:10:06Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-03-01T15:37:08Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-03-01T15:48:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-03-02T16:45:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-03-28T07:20:47Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-04-04T08:29:29Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2018-12-24T17:38:02Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/48639,MERGED,2018-03-01T13:55:00Z,2018-03-28T05:30:00Z,Add slice::sort_by_cached_key as a memoised sort_by_key,varkor,9c7b69e17909ceb090a1c4b8882a4e0924a2a755,1,Remove mentions of unstable sort_by_cached key from stable documentation,HEART,2020-09-13T14:27:22Z,kraktus,NA https://github.com/rust-lang/rust/pull/48648,MERGED,2018-03-01T23:30:44Z,2018-03-15T10:58:10Z,Fallible allocation,snf,06057d9143bc42f82c35b20c5c26fbfce58abc95,1,try_reserve: updating message for feature-gate-try_reserve.stderr,HOORAY,2018-03-14T13:45:24Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/48648,MERGED,2018-03-01T23:30:44Z,2018-03-15T10:58:10Z,Fallible allocation,snf,06057d9143bc42f82c35b20c5c26fbfce58abc95,1,try_reserve: updating message for feature-gate-try_reserve.stderr,HOORAY,2018-03-20T07:52:03Z,qnighy,NA https://github.com/rust-lang/rust/pull/48648,MERGED,2018-03-01T23:30:44Z,2018-03-15T10:58:10Z,Fallible allocation,snf,06057d9143bc42f82c35b20c5c26fbfce58abc95,1,try_reserve: updating message for feature-gate-try_reserve.stderr,HOORAY,2018-03-22T13:07:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-03T03:16:07Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-07T20:27:18Z,bluss,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-14T14:49:28Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-15T12:34:13Z,light4,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-16T10:42:14Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-03-17T23:00:21Z,twmb,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2018-09-28T07:29:04Z,frol,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2019-09-28T17:38:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/48657,MERGED,2018-03-02T04:55:46Z,2018-03-06T18:08:35Z,Optimize str::repeat,sinkuu,3d58543d49266a7ec3eb5f5f2ffaf902fce17c53,1,Avoid unnecessary calculation,THUMBS_UP,2022-04-11T02:44:34Z,mustakimur,NA https://github.com/rust-lang/rust/pull/48658,MERGED,2018-03-02T06:36:19Z,2018-04-05T15:43:32Z,Add a generic CAS loop to std::sync::Atomic*,llogiq,0f5e4191632de4bbc1ef4ef2be26b517861cbff0,1,Add a generic CAS loop to std::sync::Atomic* This adds a new method to all numeric `Atomic*` types with a safe compare-and-set loop so users will no longer need to write their own except in *very* strange circumstances. This solves #48384 with `x.fetch_max(_)`/`x.fetch_min(_)`. It also relates to #48655 (which I misuse as tracking issue for now). *note* This *might* need a crater run because the functions could clash with third party extension traits.,HOORAY,2018-03-24T19:08:56Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/48658,MERGED,2018-03-02T06:36:19Z,2018-04-05T15:43:32Z,Add a generic CAS loop to std::sync::Atomic*,llogiq,0f5e4191632de4bbc1ef4ef2be26b517861cbff0,1,Add a generic CAS loop to std::sync::Atomic* This adds a new method to all numeric `Atomic*` types with a safe compare-and-set loop so users will no longer need to write their own except in *very* strange circumstances. This solves #48384 with `x.fetch_max(_)`/`x.fetch_min(_)`. It also relates to #48655 (which I misuse as tracking issue for now). *note* This *might* need a crater run because the functions could clash with third party extension traits.,HOORAY,2018-04-02T06:37:03Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/48658,MERGED,2018-03-02T06:36:19Z,2018-04-05T15:43:32Z,Add a generic CAS loop to std::sync::Atomic*,llogiq,0f5e4191632de4bbc1ef4ef2be26b517861cbff0,1,Add a generic CAS loop to std::sync::Atomic* This adds a new method to all numeric `Atomic*` types with a safe compare-and-set loop so users will no longer need to write their own except in *very* strange circumstances. This solves #48384 with `x.fetch_max(_)`/`x.fetch_min(_)`. It also relates to #48655 (which I misuse as tracking issue for now). *note* This *might* need a crater run because the functions could clash with third party extension traits.,HOORAY,2018-04-12T20:53:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48669,MERGED,2018-03-02T14:44:09Z,2018-03-08T01:01:40Z,Update rust-installer,Eijebong,4858065ab98ad7f76e163ba9379add73e276365f,2,Reupdate rust-installer Removes the walkdir 1.0 and same-file 0.1 dependencies,HEART,2018-03-02T20:00:11Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/48699,MERGED,2018-03-03T15:26:51Z,2018-03-09T00:59:15Z,Replace iterator structures with `impl Trait`.,frewsxcv,08a01825364c429675d28b326e047ce4bc56ff7f,1,Run rustfmt on `src/librustc_data_structures/graph/mod.rs`.,HEART,2018-03-04T07:37:20Z,estebank,NA https://github.com/rust-lang/rust/pull/48699,MERGED,2018-03-03T15:26:51Z,2018-03-09T00:59:15Z,Replace iterator structures with `impl Trait`.,frewsxcv,08a01825364c429675d28b326e047ce4bc56ff7f,1,Run rustfmt on `src/librustc_data_structures/graph/mod.rs`.,THUMBS_UP,2018-03-06T02:31:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48699,MERGED,2018-03-03T15:26:51Z,2018-03-09T00:59:15Z,Replace iterator structures with `impl Trait`.,frewsxcv,08a01825364c429675d28b326e047ce4bc56ff7f,1,Run rustfmt on `src/librustc_data_structures/graph/mod.rs`.,HEART,2018-03-15T15:52:18Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48705,MERGED,2018-03-03T19:16:33Z,2018-03-13T02:41:57Z,Update Feature Request instructions,klnusbaum,f9c5b1f8e8fbc9c6d8e4b69ecbef6345a73ce515,1,Update Feature Request instructions,THUMBS_UP,2018-03-04T01:24:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48705,MERGED,2018-03-03T19:16:33Z,2018-03-13T02:41:57Z,Update Feature Request instructions,klnusbaum,f9c5b1f8e8fbc9c6d8e4b69ecbef6345a73ce515,1,Update Feature Request instructions,THUMBS_UP,2018-03-04T12:24:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/48757,MERGED,2018-03-05T20:10:47Z,2018-03-09T21:47:12Z,rustbuild: Fix MSBuild location of `llvm-config.exe`,alexcrichton,be902e7168505954b85e1bbb35322f8df8a29c19,6,rustbuild: Fix MSBuild location of `llvm-config.exe` For LLD integration the path to `llvm-config` needed to change to inside the build directory itself (for whatever reason) but the build directory is different on MSBuild than it is on `ninja` for MSVC builds so the path to `llvm-config.exe` was actually wrong and not working! This commit removes the `Build::llvm_config` function in favor of the source of truth the `Llvm` build step itself. The build step was then updated to find the right build directory for MSBuild as well as `ninja` for where `llvm-config.exe` is located. Closes #48749,THUMBS_UP,2018-03-08T17:06:53Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/48759,MERGED,2018-03-05T22:28:37Z,2018-03-22T20:01:07Z,rustdoc: expose #[target_feature] attributes as doc(cfg) flags,QuietMisdreavus,b3fb0d10f03fe7d8f2eaa705a972b0f45e1723db,1,add target_feature items to doc_cfg rustdoc test,HEART,2018-03-06T00:51:28Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48759,MERGED,2018-03-05T22:28:37Z,2018-03-22T20:01:07Z,rustdoc: expose #[target_feature] attributes as doc(cfg) flags,QuietMisdreavus,b3fb0d10f03fe7d8f2eaa705a972b0f45e1723db,1,add target_feature items to doc_cfg rustdoc test,HEART,2018-03-06T02:33:19Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/48759,MERGED,2018-03-05T22:28:37Z,2018-03-22T20:01:07Z,rustdoc: expose #[target_feature] attributes as doc(cfg) flags,QuietMisdreavus,b3fb0d10f03fe7d8f2eaa705a972b0f45e1723db,1,add target_feature items to doc_cfg rustdoc test,HEART,2018-03-06T11:40:33Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/48759,MERGED,2018-03-05T22:28:37Z,2018-03-22T20:01:07Z,rustdoc: expose #[target_feature] attributes as doc(cfg) flags,QuietMisdreavus,b3fb0d10f03fe7d8f2eaa705a972b0f45e1723db,1,add target_feature items to doc_cfg rustdoc test,HEART,2018-03-06T19:18:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/48765,MERGED,2018-03-06T05:14:33Z,2018-03-14T23:43:14Z,Add info message for -Wall command,Phlosioneer,c1337cda4ccf349b8a5a80156e32c2499520b621,1,Update -Wall message based on feedback The reference to -Wunused was removed and some phrasing was changed.,THUMBS_UP,2018-03-21T16:30:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,THUMBS_UP,2018-03-06T21:42:37Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-07T00:41:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-07T17:18:18Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-07T17:52:51Z,lqd,NA https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-08T07:04:38Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-11T13:08:29Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/48770,MERGED,2018-03-06T08:39:25Z,2018-03-12T15:52:37Z,Two phase borrows rewrite,bobtwinkles,9a5d61a840b2dd3dc6d069750945759035c85286,1,Remove some commented out code Left over from prior experimentation no longer required.,HOORAY,2018-03-22T12:47:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HEART,2018-03-20T12:38:20Z,est31,NA https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2018-03-20T12:38:22Z,est31,NA https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HEART,2018-03-21T12:55:19Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2018-03-22T00:56:19Z,sinkuu,NA https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2018-03-22T21:35:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2018-04-06T18:00:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HEART,2020-08-12T08:08:30Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2020-08-14T11:24:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/48779,MERGED,2018-03-06T13:49:46Z,2018-04-06T17:38:45Z,Allow for re-using monomorphizations in upstream crates.,michaelwoerister,61991a544f2e673e626e5db7639585fe8aa048b7,3,Update run-make/symbol-visibility to also cover shared-generics,HOORAY,2020-09-06T07:16:50Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/48782,MERGED,2018-03-06T16:45:24Z,2018-03-08T01:01:47Z,rustc: Update LLVM,alexcrichton,04eaefb25f31cd1da2d55ab8bfbe6a8a3187f009,2,rustc: Update LLVM This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes #48226,HOORAY,2018-03-06T17:19:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48782,MERGED,2018-03-06T16:45:24Z,2018-03-08T01:01:47Z,rustc: Update LLVM,alexcrichton,04eaefb25f31cd1da2d55ab8bfbe6a8a3187f009,2,rustc: Update LLVM This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes #48226,HOORAY,2018-03-06T18:25:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/48782,MERGED,2018-03-06T16:45:24Z,2018-03-08T01:01:47Z,rustc: Update LLVM,alexcrichton,04eaefb25f31cd1da2d55ab8bfbe6a8a3187f009,2,rustc: Update LLVM This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes #48226,HOORAY,2018-03-07T03:37:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/48782,MERGED,2018-03-06T16:45:24Z,2018-03-08T01:01:47Z,rustc: Update LLVM,alexcrichton,04eaefb25f31cd1da2d55ab8bfbe6a8a3187f009,2,rustc: Update LLVM This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes #48226,HOORAY,2018-03-07T04:24:12Z,martell,NA https://github.com/rust-lang/rust/pull/48786,MERGED,2018-03-06T18:35:23Z,2018-05-01T10:10:49Z,Add force-frame-pointer flag to allow control of frame pointer ommision,nagisa,7ec045219040876730693543e6cca53120a3236b,1,Force frame pointers for the backtrace test,HEART,2018-08-26T13:59:41Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/48799,MERGED,2018-03-06T23:46:56Z,2018-03-11T12:39:34Z,travis: Upgrade OSX builders,alexcrichton,55a2fdf2cf5408edba890ad1702462414899f40b,5,travis: Upgrade OSX builders This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as opposed to the 2 that our builders currently have. Should help make those OSX builds a bit speedier!,HOORAY,2018-03-07T02:14:45Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/48801,MERGED,2018-03-07T00:18:15Z,2018-03-09T06:29:32Z,Add functionality for gating feature flags on epochs ; rejigger epoch lints,Manishearth,a08cfc4cb6020164372a52080b64280c711d1bd5,3,Add rust_2018_idioms lint group,THUMBS_UP,2018-03-07T18:54:00Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48810,MERGED,2018-03-07T04:24:02Z,2018-03-20T12:50:56Z,Implement Integer methods for Wrapping,Phlosioneer,bf101a5759fd0ddab7c9cbb1dc93d22d35f54722,1,Fix trailing whitespace,THUMBS_UP,2018-03-07T05:31:24Z,pitdicker,NA https://github.com/rust-lang/rust/pull/48810,MERGED,2018-03-07T04:24:02Z,2018-03-20T12:50:56Z,Implement Integer methods for Wrapping,Phlosioneer,bf101a5759fd0ddab7c9cbb1dc93d22d35f54722,1,Fix trailing whitespace,THUMBS_UP,2018-03-09T18:07:12Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/48810,MERGED,2018-03-07T04:24:02Z,2018-03-20T12:50:56Z,Implement Integer methods for Wrapping,Phlosioneer,bf101a5759fd0ddab7c9cbb1dc93d22d35f54722,1,Fix trailing whitespace,HEART,2018-03-09T18:07:14Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/48810,MERGED,2018-03-07T04:24:02Z,2018-03-20T12:50:56Z,Implement Integer methods for Wrapping,Phlosioneer,bf101a5759fd0ddab7c9cbb1dc93d22d35f54722,1,Fix trailing whitespace,THUMBS_UP,2018-03-28T21:20:39Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/48813,MERGED,2018-03-07T09:02:46Z,2018-03-16T11:13:28Z,Make `assert` a built-in procedural macro,sinkuu,4a254c00506abdbb660e9c71d34b5b836b86da8d,3,Escape stringified expression Payload of `Literal` token must be escaped. Also print printable non-ASCII characters.,HEART,2018-03-08T21:57:28Z,estebank,NA https://github.com/rust-lang/rust/pull/48832,MERGED,2018-03-08T01:04:28Z,2018-03-08T03:59:10Z,appveyor: Fix a switched condition for cargotest,alexcrichton,893e499e8636c8e9ee3eea6e9f3337db9115018e,1,appveyor: Fix a switched condition for cargotest It was intended that EXCLUDE_CARGO *doesn't* run cargotest!,LAUGH,2018-03-08T08:34:48Z,kennytm,NA https://github.com/rust-lang/rust/pull/48834,MERGED,2018-03-08T01:14:02Z,2018-03-20T12:50:57Z,Suggest removing `&`s,ysiraichi,736ba433ac2f0d2f6604a64f744f86a311a56be4,3,Cleaned comments and extras s.,THUMBS_UP,2018-03-14T01:21:01Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/48834,MERGED,2018-03-08T01:14:02Z,2018-03-20T12:50:57Z,Suggest removing `&`s,ysiraichi,736ba433ac2f0d2f6604a64f744f86a311a56be4,3,Cleaned comments and extras s.,THUMBS_UP,2018-03-14T18:03:13Z,estebank,NA https://github.com/rust-lang/rust/pull/48851,MERGED,2018-03-08T19:56:10Z,2018-04-05T09:59:08Z,Stabilize attributes on generic parameters,petrochenkov,1a2a23447e451faee7ffbffab2be8831f3098f6d,29,Stabilize attributes on generic parameters,HOORAY,2018-03-08T22:22:48Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-09T00:27:32Z,estebank,NA https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-09T05:32:34Z,ordovicia,NA https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-09T09:09:22Z,killercup,NA https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-09T15:28:57Z,flaki,git@flaki.hu https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-10T19:14:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-11T10:49:21Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/48858,CLOSED,2018-03-09T00:12:39Z,2018-03-22T05:46:35Z,suggest `!` instead of erroneous `not` on if/while block parse failure,zackmdavis,NA,NA,NA,HEART,2018-03-18T00:12:51Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/48867,CLOSED,2018-03-09T08:12:32Z,2018-03-09T20:23:47Z,[Nothing to see here] Just borrowing Travis,scottmcm,NA,NA,NA,LAUGH,2018-03-09T08:26:30Z,kennytm,NA https://github.com/rust-lang/rust/pull/48880,MERGED,2018-03-09T14:12:41Z,2018-03-13T02:42:04Z,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,petrochenkov,c1a73d2f4a8ef0003b93c4307930438be4aae9a5,7,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,HEART,2018-03-09T17:55:55Z,estebank,NA https://github.com/rust-lang/rust/pull/48880,MERGED,2018-03-09T14:12:41Z,2018-03-13T02:42:04Z,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,petrochenkov,c1a73d2f4a8ef0003b93c4307930438be4aae9a5,7,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,HEART,2018-03-10T19:13:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48880,MERGED,2018-03-09T14:12:41Z,2018-03-13T02:42:04Z,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,petrochenkov,c1a73d2f4a8ef0003b93c4307930438be4aae9a5,7,tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories,HEART,2018-03-12T06:28:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/48896,MERGED,2018-03-09T22:12:39Z,2018-03-16T16:44:04Z,rustc: Enable embedding LLVM bitcode for iOS,alexcrichton,0e0f74bcf93341ff3b1d8b59f3639416a159a140,4,rustc: Embed LLVM bitcode by default on iOS This commit updates rustc to embed bitcode in each object file generated by default when compiling for iOS. This was determined in #35968 as a step towards better compatibility with the iOS toolchain so let's give it a spin and see how it turns out! Note that this also updates the `cc` dependency which should propagate this change of embedding bitcode for C dependencies as well.,THUMBS_UP,2018-10-22T13:46:44Z,joelhandwell,joelhandwell@gmail.com https://github.com/rust-lang/rust/pull/48898,MERGED,2018-03-09T23:36:43Z,2018-03-13T02:42:06Z,Remove auto trait implementation section when empty,GuillaumeGomez,7dc71ec009ffce75142b2987374401b50a3a194c,2,Remove auto trait implementation section when empty,THUMBS_UP,2018-03-22T12:53:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48909,MERGED,2018-03-10T12:48:18Z,2018-03-23T21:41:47Z,Improve lint for type alias bounds,RalfJung,c05d23406ead7b5747256c02127097807db45b83,2,update compile-fail tests: fewer warnings because this is now a HIR lint,HEART,2018-03-15T02:05:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48925,MERGED,2018-03-11T01:25:01Z,2018-05-01T00:09:04Z,stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940),zackmdavis,3dbdccc6a9c1ead58325d415381b25c676386c34,20,stabilize `#[must_use]` for functions and must-use operators This is in the matter of RFC 1940 and tracking issue #43302.,HOORAY,2018-03-16T06:40:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/48925,MERGED,2018-03-11T01:25:01Z,2018-05-01T00:09:04Z,stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940),zackmdavis,3dbdccc6a9c1ead58325d415381b25c676386c34,20,stabilize `#[must_use]` for functions and must-use operators This is in the matter of RFC 1940 and tracking issue #43302.,HOORAY,2018-04-26T14:57:58Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/48925,MERGED,2018-03-11T01:25:01Z,2018-05-01T00:09:04Z,stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940),zackmdavis,3dbdccc6a9c1ead58325d415381b25c676386c34,20,stabilize `#[must_use]` for functions and must-use operators This is in the matter of RFC 1940 and tracking issue #43302.,HOORAY,2018-05-10T03:41:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48928,MERGED,2018-03-11T08:14:27Z,2018-03-13T02:42:08Z,in which some labels and notes are upgraded to structured suggestions,zackmdavis,9b599856a4b7e375e4e54eb759c250be969f5562,10,in which some labels and notes are upgraded to structured suggestions (Meanwhile a couple of parse-fail tests are moved to UI tests so that the reader can see the new output and an existing UI test is given a more evocative name.),THUMBS_UP,2018-03-11T20:56:32Z,estebank,NA https://github.com/rust-lang/rust/pull/48939,MERGED,2018-03-11T20:41:08Z,2018-03-22T20:01:09Z,Querify WF-checking so it can be cached,wesleywiser,b418b7ba0f7393d789860f96a718a4fba2729271,2,Remove CheckTypeWellFormed struct and convert to free functions Related to #48939,HEART,2018-03-13T17:36:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/48939,MERGED,2018-03-11T20:41:08Z,2018-03-22T20:01:09Z,Querify WF-checking so it can be cached,wesleywiser,b418b7ba0f7393d789860f96a718a4fba2729271,2,Remove CheckTypeWellFormed struct and convert to free functions Related to #48939,HOORAY,2018-03-13T19:35:46Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48945,MERGED,2018-03-12T00:52:18Z,2018-04-16T16:07:12Z,Replace manual iterator exhaust with for_each(drop),clarfonthey,5c58eec0bd8cee8fb2a191396d5ad5b5c9b0116a,6,Replace manual iter exhaust with for_each(drop).,THUMBS_UP,2018-03-15T21:33:35Z,hedgehog1024,NA https://github.com/rust-lang/rust/pull/48945,MERGED,2018-03-12T00:52:18Z,2018-04-16T16:07:12Z,Replace manual iterator exhaust with for_each(drop),clarfonthey,5c58eec0bd8cee8fb2a191396d5ad5b5c9b0116a,6,Replace manual iter exhaust with for_each(drop).,THUMBS_UP,2018-04-21T18:45:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48958,MERGED,2018-03-12T20:03:39Z,2018-03-13T12:16:53Z,Update the rls-rustc package,alexcrichton,9b1c69ec93d17b9593d183858b7d8b3c3e0cb703,1,Update the rls-rustc package Should hopefully fix compiling the rls!,THUMBS_UP,2018-03-12T23:57:38Z,bdrewery,NA https://github.com/rust-lang/rust/pull/48958,MERGED,2018-03-12T20:03:39Z,2018-03-13T12:16:53Z,Update the rls-rustc package,alexcrichton,9b1c69ec93d17b9593d183858b7d8b3c3e0cb703,1,Update the rls-rustc package Should hopefully fix compiling the rls!,THUMBS_UP,2018-03-13T00:25:59Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/48958,MERGED,2018-03-12T20:03:39Z,2018-03-13T12:16:53Z,Update the rls-rustc package,alexcrichton,9b1c69ec93d17b9593d183858b7d8b3c3e0cb703,1,Update the rls-rustc package Should hopefully fix compiling the rls!,THUMBS_UP,2018-03-13T22:55:57Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-13T09:39:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-13T11:28:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-13T12:10:41Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-14T15:55:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HEART,2018-03-15T22:39:01Z,Ixrec,NA https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HEART,2018-03-18T10:07:46Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-19T06:23:50Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/48973,CLOSED,2018-03-13T03:23:21Z,2018-04-15T23:08:15Z,Implement RFC 2011 (nicer assert messages),sinkuu,NA,NA,NA,HOORAY,2018-03-22T21:30:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-13T16:44:24Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-13T22:06:06Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-14T15:11:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-14T15:44:38Z,lqd,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-15T18:33:02Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-15T19:32:18Z,obust,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-15T22:26:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-17T00:00:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-17T19:36:33Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-19T15:45:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-21T12:04:01Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-21T16:58:47Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/48985,MERGED,2018-03-13T16:42:17Z,2018-03-18T10:03:32Z,MVP for chalkification,scalexm,ef3b4e1f5bfb8cf5347b086ed60aefd519a3335d,1,Fix tidy,HOORAY,2018-03-26T16:04:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/48986,MERGED,2018-03-13T17:22:03Z,2018-03-18T12:48:49Z,Update Cargo,matklad,b15b023226176d4fc0ceef6cfd5698b7df6787f2,2,Update Cargo This notably includes * https://github.com/rust-lang/cargo/pull/5152 * https://github.com/rust-lang/cargo/pull/5188 The first one switches cargo from docopt to clap ( we also update to the latest calp in this repository) the second one should help us to unify feature flags for Cargo itself and RLS and build Cargo libray only once.,THUMBS_UP,2018-03-16T13:28:55Z,BubbaSheen,NA https://github.com/rust-lang/rust/pull/48990,MERGED,2018-03-13T19:35:21Z,2018-03-16T02:46:47Z,Fix ICE on malformed plugin attributes,ExpHP,dc96467e220ffd68a68447a822659e245dcc9a4f,1,Fix ICE on malformed plugin attributes,HOORAY,2018-03-13T20:14:17Z,estebank,NA https://github.com/rust-lang/rust/pull/48992,CLOSED,2018-03-13T21:05:00Z,2018-03-14T19:35:49Z,rustc: Add a `#[wasm_import_module]` attribute,alexcrichton,NA,NA,NA,HOORAY,2018-03-14T02:44:52Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/48995,MERGED,2018-03-13T21:44:45Z,2018-04-27T06:30:27Z,Create a canonical trait query for `evaluate_obligation`,aravind-pg,e423dcc7133f20c8da2609dba96afeeab1efbc5a,1,Update a compile-fail test,HOORAY,2018-03-14T16:21:19Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/48999,MERGED,2018-03-13T23:16:46Z,2018-04-24T05:43:35Z,Add repeat method on slice,GuillaumeGomez,3c1fea9c0de008d105e8e043b53c4aba57d0df65,1,Add run-pass test for repeat-generic-slice feature,THUMBS_UP,2018-03-17T22:41:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-13T23:28:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-13T23:45:25Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-14T00:50:26Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-14T02:47:35Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-14T08:12:22Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-14T08:12:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-14T12:47:18Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-14T12:47:18Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-15T01:39:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-15T19:46:54Z,novacrazy,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-16T10:59:51Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2018-03-16T10:59:52Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-16T11:42:49Z,delacian,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-20T20:02:14Z,kennytm,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-03-21T17:23:07Z,gmorenz,greg-morenz@droid.cafe https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-04-08T11:16:21Z,hcpl,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HEART,2018-04-08T11:16:28Z,hcpl,NA https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,HOORAY,2018-04-12T10:37:01Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/49000,CLOSED,2018-03-13T23:27:57Z,2018-04-30T00:53:00Z,impl IntoIterator for arrays,cuviper,NA,NA,NA,THUMBS_UP,2021-07-11T15:21:57Z,nayuki,NA https://github.com/rust-lang/rust/pull/49014,MERGED,2018-03-14T14:09:20Z,2018-03-14T20:59:30Z,Update RLS,Bobo1239,c21480233e49d0e98f6cbd4d333e6be0a008082a,2,Update RLS,HEART,2018-03-14T15:00:32Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49014,MERGED,2018-03-14T14:09:20Z,2018-03-14T20:59:30Z,Update RLS,Bobo1239,c21480233e49d0e98f6cbd4d333e6be0a008082a,2,Update RLS,HEART,2018-03-14T18:27:16Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49019,MERGED,2018-03-14T15:52:00Z,2018-03-28T15:31:38Z,Introduce a TargetTriple enum to support absolute target paths,phil-opp,b889f98fba63dfcce68902c3a8c330fdea16a33b,1,Add a hash when a TargetPath is displayed,THUMBS_UP,2018-03-15T20:24:47Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/49019,MERGED,2018-03-14T15:52:00Z,2018-03-28T15:31:38Z,Introduce a TargetTriple enum to support absolute target paths,phil-opp,b889f98fba63dfcce68902c3a8c330fdea16a33b,1,Add a hash when a TargetPath is displayed,THUMBS_UP,2018-03-23T21:10:18Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/49027,CLOSED,2018-03-14T21:43:41Z,2018-03-24T04:15:18Z,str: add cut and cutn methods,cool-cool-sweat,NA,NA,NA,THUMBS_DOWN,2018-03-15T08:51:55Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/49028,MERGED,2018-03-14T21:51:37Z,2018-03-23T21:41:51Z,"add an ""unstable features"" chapter to the rustdoc book",QuietMisdreavus,b996f9d60fdb1db6bd870fc7f600be4c7660f3a2,1,review comments,THUMBS_UP,2018-03-15T18:09:34Z,bb010g,NA https://github.com/rust-lang/rust/pull/49028,MERGED,2018-03-14T21:51:37Z,2018-03-23T21:41:51Z,"add an ""unstable features"" chapter to the rustdoc book",QuietMisdreavus,b996f9d60fdb1db6bd870fc7f600be4c7660f3a2,1,review comments,HEART,2018-03-18T11:57:34Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-15T05:39:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-15T05:57:55Z,sdleffler,shea@errno.com https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-15T10:05:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-15T13:02:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-21T18:24:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-03-28T15:59:13Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49038,MERGED,2018-03-15T04:37:26Z,2018-03-22T20:01:13Z,replace `convert::Infallible` with `!`,canndrew,15bab452f30ce6cb67a849f13e9de80586a8b180,1,Add From for TryFromIntError,HEART,2018-04-13T19:19:54Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/49045,MERGED,2018-03-15T14:18:13Z,2018-04-05T19:25:43Z,Make queries thread safe,Zoxc,4f7d0fde1c5f577c1f956d5d4edfbb202a5bc3cf,4,Some cleanups and added comments,HOORAY,2018-04-13T00:05:31Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49046,MERGED,2018-03-15T14:41:25Z,2018-03-24T21:28:36Z,Always print `aborting due to n previous error(s)`,Zoxc,b1d872b38eaacefbef73faa6a4a0c07622a8c941,33,Update tests,HEART,2018-03-22T11:50:26Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49056,CLOSED,2018-03-15T19:47:34Z,2018-07-14T12:38:27Z,Add empty dropped variant to ManuallyDrop,cramertj,NA,NA,NA,THUMBS_UP,2018-03-16T06:11:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,THUMBS_UP,2018-03-15T21:39:43Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-15T22:15:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HEART,2018-03-16T01:39:49Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-16T06:15:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HEART,2018-03-19T00:34:09Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-21T21:20:00Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-22T02:37:01Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-22T13:15:28Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,THUMBS_UP,2018-03-26T16:56:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49057,MERGED,2018-03-15T19:50:47Z,2018-03-17T14:19:16Z,Faster submodule updating,Zoxc,72cb109bec8e73b1568c2f287ed08348453bf534,2,Faster submodule updating,HOORAY,2018-03-28T09:29:11Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HEART,2018-03-15T20:15:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HEART,2018-03-16T03:18:11Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HEART,2018-03-16T10:51:13Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-16T14:52:31Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-19T22:56:37Z,lqd,NA https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-21T04:24:04Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-21T09:20:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-28T14:35:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-28T15:56:12Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HOORAY,2018-03-28T17:28:02Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HEART,2018-03-28T17:28:03Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49058,MERGED,2018-03-15T20:03:49Z,2018-03-20T01:43:04Z,Pin Unpin PinBox,withoutboats,540021ff5d4771d3dfb8ce8ea5346a0ff2c1d060,1,Okay this is the right way.,HEART,2018-04-06T15:21:24Z,repi,NA https://github.com/rust-lang/rust/pull/49067,CLOSED,2018-03-15T23:00:54Z,2018-03-18T17:09:28Z,Add `DisplayAsDebug` - A struct to help with Debug impls,Centril,NA,NA,NA,CONFUSED,2018-03-18T12:22:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/49077,MERGED,2018-03-16T08:02:52Z,2018-03-17T14:19:17Z,Checks for unknown attributes before aborting due to unresolved macros,sinkuu,4be3e96b80a5dc5bddeaccd2a7c3af1abf8bf452,3,Checks for unknown attributes before aborting ...due to unresolved macros.,HEART,2018-03-16T18:32:11Z,estebank,NA https://github.com/rust-lang/rust/pull/49082,MERGED,2018-03-16T10:46:09Z,2018-03-17T14:19:18Z,Remove deprecated unstable alloc::heap::EMPTY constant,SimonSapin,f0ad533fe316c4eb26ab6ebda879e60956633c0e,1,Remove deprecated unstable alloc::heap::EMPTY constant,THUMBS_UP,2018-03-16T14:09:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49083,MERGED,2018-03-16T10:50:37Z,2018-03-17T14:19:18Z,Only generate miri backtraces if explicitly requested,oli-obk,4133b160363143b975cf9927cff87d183f1f5405,1,Only generate miri backtraces if explicitly requested,THUMBS_UP,2018-03-17T00:50:14Z,bdrewery,NA https://github.com/rust-lang/rust/pull/49083,MERGED,2018-03-16T10:50:37Z,2018-03-17T14:19:18Z,Only generate miri backtraces if explicitly requested,oli-obk,4133b160363143b975cf9927cff87d183f1f5405,1,Only generate miri backtraces if explicitly requested,HEART,2018-03-17T05:23:32Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49094,MERGED,2018-03-16T19:30:57Z,2018-03-22T12:29:11Z,ci: Print out how long each step takes on CI,alexcrichton,1b5eb17d61f1651d6b9d412a5be586dfb80fd447,5,ci: Print out how long each step takes on CI This commit updates CI configuration to inform rustbuild that it should print out how long each step takes on CI. This'll hopefully allow us to track the duration of steps over time and follow regressions a bit more closesly (as well as have closer analysis of differences between two builds). cc #48829,HOORAY,2018-03-19T18:13:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T01:58:26Z,cramertj,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T04:46:54Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T05:16:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T06:10:39Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T08:28:08Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T09:37:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T17:14:31Z,tinaun,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T17:27:13Z,bb010g,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T17:49:37Z,pitdicker,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-17T23:37:54Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-19T01:45:03Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-19T17:11:36Z,est31,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-26T02:25:14Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-26T21:20:48Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-27T07:08:29Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-28T20:48:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-29T03:59:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-03-29T21:01:16Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-04-01T04:43:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-04-08T23:07:52Z,hcpl,NA https://github.com/rust-lang/rust/pull/49101,MERGED,2018-03-17T01:17:30Z,2018-03-26T21:21:40Z,Stabilize 128-bit integers :tada:,mark-i-m,140bf949bf65bb0479dbe31bd3474d5546ef59e1,2,fix last two tidy,HOORAY,2018-05-11T23:23:37Z,Nudin,michi4@schoenitzer.de https://github.com/rust-lang/rust/pull/49104,MERGED,2018-03-17T05:51:39Z,2018-03-20T12:51:09Z,improve error message of inner attribute syntax,csmoe,9f5a356c1d01e971b1fe33f7afb2b81d0eec2b1c,3,improve attribute trailing semicolon error,THUMBS_UP,2018-03-19T18:16:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49104,MERGED,2018-03-17T05:51:39Z,2018-03-20T12:51:09Z,improve error message of inner attribute syntax,csmoe,9f5a356c1d01e971b1fe33f7afb2b81d0eec2b1c,3,improve attribute trailing semicolon error,THUMBS_UP,2018-03-24T09:03:27Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/49109,MERGED,2018-03-17T11:17:09Z,2018-03-22T20:01:17Z,Deprecate the AsciiExt trait in favor of inherent methods,SimonSapin,c09b9f937250db0f51b705a3110f8cffdad083bb,5,Deprecate the AsciiExt trait in favor of inherent methods The trait and some of its methods are stable and will remain. Some of the newer methods are unstable and can be removed later. Fixes https://github.com/rust-lang/rust/issues/39658,THUMBS_UP,2018-03-17T22:53:25Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/49119,CLOSED,2018-03-17T20:55:44Z,2018-06-12T17:18:06Z,Skip stage 0 libstd,Zoxc,NA,NA,NA,HEART,2018-03-22T14:45:31Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/49119,CLOSED,2018-03-17T20:55:44Z,2018-06-12T17:18:06Z,Skip stage 0 libstd,Zoxc,NA,NA,NA,HEART,2018-04-18T09:06:11Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/49124,MERGED,2018-03-18T00:21:08Z,2018-04-02T13:04:38Z,Expand Attributes on Statements and Expressions,abonander,7c0124dd357650acb9b7115a408712ea281d8d22,16,Expand attribute macros on statements and expressions. Retains the `stmt_expr_attributes` feature requirement for attributes on expressions. closes #41475 cc #38356,THUMBS_UP,2018-03-18T00:30:23Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49124,MERGED,2018-03-18T00:21:08Z,2018-04-02T13:04:38Z,Expand Attributes on Statements and Expressions,abonander,7c0124dd357650acb9b7115a408712ea281d8d22,16,Expand attribute macros on statements and expressions. Retains the `stmt_expr_attributes` feature requirement for attributes on expressions. closes #41475 cc #38356,THUMBS_UP,2018-03-19T06:20:11Z,liuhongyi0101,NA https://github.com/rust-lang/rust/pull/49130,MERGED,2018-03-18T08:44:46Z,2018-04-16T18:51:33Z,Move Range*::contains to a single default impl on RangeBounds,smmalis37,51f24ec7f01b6a636750baff5ab5a12ec6bfe6cd,1,Add symmetric requirement of PartialOrd.,HOORAY,2018-03-20T04:58:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49139,MERGED,2018-03-18T16:21:24Z,2018-03-20T12:51:12Z,Add BufReader::buffer,sfackler,16da5d4bb2d65a4d533d1da2a4e0d288d3a474c5,1,Add BufReader::buffer This subsumes the need for an explicit is_empty function and provides access to the buffered data itself which has been requested from time to time.,HOORAY,2018-03-28T14:47:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49139,MERGED,2018-03-18T16:21:24Z,2018-03-20T12:51:12Z,Add BufReader::buffer,sfackler,16da5d4bb2d65a4d533d1da2a4e0d288d3a474c5,1,Add BufReader::buffer This subsumes the need for an explicit is_empty function and provides access to the buffered data itself which has been requested from time to time.,HOORAY,2018-03-28T20:52:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HEART,2018-03-19T01:22:32Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HEART,2018-03-19T14:36:52Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HEART,2018-03-19T15:18:22Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HEART,2018-03-19T18:12:57Z,estebank,NA https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HOORAY,2018-03-19T20:38:38Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HOORAY,2018-03-21T23:09:06Z,jseyfried,NA https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HOORAY,2018-04-03T23:24:23Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/49154,MERGED,2018-03-19T00:59:47Z,2018-04-06T12:03:21Z,AST: Give spans to all identifiers,petrochenkov,145868427989655f286a3dda0cd46435bcdf42ac,1,Fix feature gating for crate/extern in paths,HOORAY,2018-04-15T06:31:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49160,MERGED,2018-03-19T06:03:36Z,2018-03-23T21:41:57Z,Reduce the diagnostic spam when multiple fields are missing in pattern,estebank,062a46fdd1d49b1ccdc4f713433521463224d7d9,9,Reduce diagnostic verbosity by removing labels,THUMBS_UP,2018-03-28T14:39:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-03-19T07:02:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-03-19T12:40:09Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-03-19T15:56:26Z,cramertj,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-21T13:26:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-03-21T15:26:00Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-21T20:31:27Z,estebank,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-22T21:34:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-03-28T14:48:47Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-28T14:48:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-28T16:13:02Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-28T20:46:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-03-29T03:59:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HOORAY,2018-05-30T02:51:25Z,ajjaic,NA https://github.com/rust-lang/rust/pull/49162,MERGED,2018-03-19T06:50:19Z,2018-03-24T21:28:42Z,Stabilize termination_trait split out termination_trait_test,tmandry,2b13d95da02d318c12814261dd36edd91ae6879e,5,termination_trait: Make error message more helpful,HEART,2018-05-30T02:51:26Z,ajjaic,NA https://github.com/rust-lang/rust/pull/49163,MERGED,2018-03-19T08:45:50Z,2018-03-29T14:17:00Z,Rename RangeArgument to RangeBounds move it and Bound to libcore,SimonSapin,6c9b3cccbcef8918829e173a2ea9c5d975cd2777,1,Update clippy,HOORAY,2018-03-22T22:21:01Z,kennytm,NA https://github.com/rust-lang/rust/pull/49163,MERGED,2018-03-19T08:45:50Z,2018-03-29T14:17:00Z,Rename RangeArgument to RangeBounds move it and Bound to libcore,SimonSapin,6c9b3cccbcef8918829e173a2ea9c5d975cd2777,1,Update clippy,HOORAY,2018-03-25T15:59:17Z,cmyr,NA https://github.com/rust-lang/rust/pull/49163,MERGED,2018-03-19T08:45:50Z,2018-03-29T14:17:00Z,Rename RangeArgument to RangeBounds move it and Bound to libcore,SimonSapin,6c9b3cccbcef8918829e173a2ea9c5d975cd2777,1,Update clippy,HOORAY,2018-04-04T07:51:25Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-19T14:17:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-19T16:12:27Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-19T19:39:00Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-22T21:27:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-22T22:28:15Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-03-22T23:09:07Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-04-03T13:53:18Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-04-20T10:51:59Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-04-24T16:56:06Z,cramertj,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-04-24T19:05:40Z,estebank,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-05-06T21:24:54Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-05-19T17:09:28Z,lqd,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-05-22T15:24:17Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-05-23T05:59:38Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/49172,MERGED,2018-03-19T13:46:27Z,2018-05-22T15:16:23Z,Allow let bindings and destructuring in constants and const fn,oli-obk,2483c812176c8ecca54207517a2ba5500805b205,1,Deduplicate match arms,HOORAY,2018-06-01T07:18:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49173,CLOSED,2018-03-19T13:46:40Z,2018-06-27T14:09:36Z,Introduce <&[_]>::split_off and <&str>::split_off,nox,NA,NA,NA,HEART,2018-03-19T13:50:38Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49173,CLOSED,2018-03-19T13:46:40Z,2018-06-27T14:09:36Z,Introduce <&[_]>::split_off and <&str>::split_off,nox,NA,NA,NA,HEART,2018-03-19T14:45:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/49173,CLOSED,2018-03-19T13:46:40Z,2018-06-27T14:09:36Z,Introduce <&[_]>::split_off and <&str>::split_off,nox,NA,NA,NA,HEART,2018-03-19T15:56:39Z,cramertj,NA https://github.com/rust-lang/rust/pull/49173,CLOSED,2018-03-19T13:46:40Z,2018-06-27T14:09:36Z,Introduce <&[_]>::split_off and <&str>::split_off,nox,NA,NA,NA,HEART,2018-06-04T17:48:48Z,estebank,NA https://github.com/rust-lang/rust/pull/49179,MERGED,2018-03-19T17:28:47Z,2018-04-05T00:19:34Z,Handle future deprecation annotations ,varkor,b2ed9dd546e33ded4a80acd02e1710fe811936b2,1,Replace as_ref with &,THUMBS_UP,2018-04-12T20:59:30Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49193,MERGED,2018-03-20T02:09:17Z,2018-03-24T21:28:43Z,Host compiler documentation,davidtwco,73fa6d52ed99651940267affa941a1069cc20f35,2,Remove std/test documentation from compiler docs.,HEART,2018-03-20T10:30:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49193,MERGED,2018-03-20T02:09:17Z,2018-03-24T21:28:43Z,Host compiler documentation,davidtwco,73fa6d52ed99651940267affa941a1069cc20f35,2,Remove std/test documentation from compiler docs.,HOORAY,2018-03-20T15:50:54Z,kennytm,NA https://github.com/rust-lang/rust/pull/49193,MERGED,2018-03-20T02:09:17Z,2018-03-24T21:28:43Z,Host compiler documentation,davidtwco,73fa6d52ed99651940267affa941a1069cc20f35,2,Remove std/test documentation from compiler docs.,HOORAY,2018-03-22T16:05:09Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49193,MERGED,2018-03-20T02:09:17Z,2018-03-24T21:28:43Z,Host compiler documentation,davidtwco,73fa6d52ed99651940267affa941a1069cc20f35,2,Remove std/test documentation from compiler docs.,HOORAY,2018-03-22T21:27:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49193,MERGED,2018-03-20T02:09:17Z,2018-03-24T21:28:43Z,Host compiler documentation,davidtwco,73fa6d52ed99651940267affa941a1069cc20f35,2,Remove std/test documentation from compiler docs.,HOORAY,2018-03-25T02:57:06Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/49202,MERGED,2018-03-20T10:02:33Z,2018-03-27T17:21:25Z,Introduce trait engine,csmoe,39712e5721f92ca94f556d3b67f5bd60b592ebc2,1,rename `'tcx` and `tcx` to `'gcx` and `gcx` This helps to make clear where *global* lifetimes are needed in `coerce_unsized_info`,HOORAY,2018-03-22T21:24:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49202,MERGED,2018-03-20T10:02:33Z,2018-03-27T17:21:25Z,Introduce trait engine,csmoe,39712e5721f92ca94f556d3b67f5bd60b592ebc2,1,rename `'tcx` and `tcx` to `'gcx` and `gcx` This helps to make clear where *global* lifetimes are needed in `coerce_unsized_info`,HOORAY,2018-03-26T11:11:50Z,scalexm,alexandre@scalexm.fr https://github.com/rust-lang/rust/pull/49204,CLOSED,2018-03-20T10:56:29Z,2018-03-22T19:37:34Z,Add '\e' escape sequence,florenzo-42,NA,NA,NA,THUMBS_DOWN,2018-03-20T17:52:50Z,retep998,NA https://github.com/rust-lang/rust/pull/49204,CLOSED,2018-03-20T10:56:29Z,2018-03-22T19:37:34Z,Add '\e' escape sequence,florenzo-42,NA,NA,NA,THUMBS_DOWN,2018-03-21T21:28:32Z,mcarton,NA https://github.com/rust-lang/rust/pull/49211,MERGED,2018-03-20T15:14:46Z,2018-03-22T20:01:26Z,"Implement Chalk lowering rule ""Implemented-From-Env""",varkor,7791995ad5200b65cd9c8391703a76a18f492664,2,Add unit test for Implemented-From-Env,HEART,2018-03-20T16:47:25Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-20T22:04:09Z,kennytm,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-20T22:04:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-20T22:12:42Z,eternaleye,eternaleye@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-20T22:41:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-20T23:31:31Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-21T00:13:01Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-21T00:16:23Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-21T00:31:27Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-21T00:59:32Z,jseyfried,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-21T14:20:11Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-22T07:11:27Z,bjorn3,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-22T15:25:36Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-03-22T21:21:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-04-17T04:05:59Z,retep998,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-05-07T05:54:21Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-05-11T14:24:42Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-05-23T09:05:29Z,hcpl,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-07-19T21:30:30Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-07-27T09:29:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-08-18T23:51:31Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-08-23T08:32:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-08-30T16:17:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-09-03T10:44:50Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-09-07T04:18:27Z,Aloxaf,bailong104@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-09-26T10:51:43Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-09-30T08:50:32Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-10-15T15:48:17Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-10-16T00:29:28Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-10-23T22:32:28Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-12T22:23:52Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-17T14:33:46Z,ljedrz,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-17T16:02:25Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-23T11:24:43Z,kgv,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-24T18:31:41Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-25T14:54:09Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-26T01:05:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-30T11:09:43Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-11-30T20:05:34Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-12-06T01:29:31Z,estebank,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2018-12-06T08:44:30Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HEART,2018-12-08T05:08:26Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HEART,2019-03-28T06:54:27Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/49219,MERGED,2018-03-20T21:56:23Z,2018-11-30T09:39:48Z,Decouple proc_macro from the rest of the compiler.,eddyb,3a04d448f935dcd8ed0e5ff98e776431196a4ece,1,bootstrap: provide host `rust_test_helpers` to compiletest not just target.,HOORAY,2020-05-21T16:00:22Z,taiki-e,NA https://github.com/rust-lang/rust/pull/49222,MERGED,2018-03-20T22:52:14Z,2018-04-07T05:33:18Z,Print query stack on ICEs,Zoxc,4fd188e5f31f14625eb8b1feec38da5ad538e3c9,3,Print query stack on ICEs,HOORAY,2018-03-21T11:04:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49222,MERGED,2018-03-20T22:52:14Z,2018-04-07T05:33:18Z,Print query stack on ICEs,Zoxc,4fd188e5f31f14625eb8b1feec38da5ad538e3c9,3,Print query stack on ICEs,HOORAY,2018-03-21T14:19:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/49222,MERGED,2018-03-20T22:52:14Z,2018-04-07T05:33:18Z,Print query stack on ICEs,Zoxc,4fd188e5f31f14625eb8b1feec38da5ad538e3c9,3,Print query stack on ICEs,THUMBS_UP,2018-03-21T22:53:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49222,MERGED,2018-03-20T22:52:14Z,2018-04-07T05:33:18Z,Print query stack on ICEs,Zoxc,4fd188e5f31f14625eb8b1feec38da5ad538e3c9,3,Print query stack on ICEs,HOORAY,2018-03-26T17:32:31Z,estebank,NA https://github.com/rust-lang/rust/pull/49223,MERGED,2018-03-20T23:03:21Z,2018-03-28T05:30:07Z,Propose a variant if it is an enum for E0599,GuillaumeGomez,1f51840db0d846c2370f7d726eb8e41424431850,3,Propose a variant if it is an enum for E0599,HEART,2018-03-21T03:42:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49234,MERGED,2018-03-21T14:07:59Z,2018-03-22T20:01:29Z,dpl 1.9.5 has been released revert #49217.,kennytm,c7bdd371a64ff5b9b86680fd77dd56d1eeabb76c,1,"Revert ""Apply a fix to travis-ci/dpl#788 manually until dpl 1.9.5 is released."" This reverts commit 20e65f11f3bb0538c5676425e74b593676bd0f12.",HOORAY,2018-03-23T03:49:31Z,BanzaiMan,asari.ruby@gmail.com https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-03-21T22:47:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-03-24T16:10:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-03-24T16:48:21Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-03-28T15:50:27Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-03-28T16:09:40Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/49251,MERGED,2018-03-21T22:45:18Z,2018-03-24T15:57:56Z,support elision in impl headers,nikomatsakis,94468dac6350a29dc2eb1eed01308ec78224f7ba,18,permit `'_` and `&T` in impl headers Deprecated forms of elision are not supported.,HOORAY,2018-04-02T13:38:52Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T02:20:36Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-22T02:20:38Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T03:05:47Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T06:24:58Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T06:27:56Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T07:27:22Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-22T08:45:09Z,killercup,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T08:54:42Z,adwhit,adwhit@fastmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T09:02:02Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T09:41:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T11:47:21Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T12:04:21Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T12:34:27Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T13:10:24Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T13:56:52Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T21:10:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T21:14:56Z,jwilm,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T22:19:10Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T22:36:49Z,gsquire,github@garrettsquire.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_DOWN,2018-03-22T23:09:28Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-22T23:23:27Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T00:07:15Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T00:24:57Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-23T02:28:06Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-23T03:19:51Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T03:19:53Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-23T03:39:08Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T08:05:13Z,jacobh,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T09:19:45Z,bash,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T11:58:52Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T14:19:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-23T14:49:00Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T14:49:03Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T15:31:30Z,zowens,zowens2009@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T20:16:24Z,bluss,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-23T22:43:54Z,obust,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-26T10:22:05Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-26T10:22:07Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-26T17:47:55Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-26T17:47:57Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-26T17:48:00Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-26T18:32:27Z,timglabisch,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-27T01:14:03Z,jesselloyd,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-27T02:13:41Z,KeenS,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-27T02:13:42Z,KeenS,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-27T18:28:42Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-27T18:28:45Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-28T11:44:07Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-28T11:52:55Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-28T17:27:36Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-28T17:27:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-03-28T17:27:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-28T17:48:30Z,dailypips,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-03-29T02:22:20Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-29T05:39:22Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-03-30T07:09:23Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-04-11T08:19:28Z,qthree,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-04-16T20:08:22Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-04-25T18:06:34Z,whitfin,iw@whitfin.io https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-04-26T17:02:42Z,dschaeffer,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HEART,2018-05-08T04:14:37Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-05-08T04:14:39Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-05-08T04:14:41Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,THUMBS_UP,2018-05-11T06:14:37Z,leehyong,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-05-11T06:14:39Z,leehyong,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-05-22T22:41:09Z,Etherian,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-05-23T14:41:34Z,tsiq-nicolas,NA https://github.com/rust-lang/rust/pull/49255,MERGED,2018-03-22T01:42:09Z,2018-03-26T11:53:19Z,Stabilize impl Trait,cramertj,0f5b52e4a8d3004ef2d69b2ec7f410d4b2c9494c,68,Stabilize conservative_impl_trait,HOORAY,2018-05-27T15:44:57Z,justas-d,NA https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,THUMBS_UP,2018-03-22T10:52:25Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,THUMBS_UP,2018-03-22T15:33:15Z,killercup,NA https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,THUMBS_UP,2018-03-24T01:21:02Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,THUMBS_UP,2018-04-18T06:30:38Z,jplatte,NA https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,HOORAY,2018-04-18T19:37:36Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/49258,MERGED,2018-03-22T05:46:11Z,2018-04-10T06:24:04Z,suggest `!` for erroneous identifier `not`,zackmdavis,ba0dd8eb026e2dcff27a7ee3b29514a53cc5c1d9,4,in which `!` is suggested for erroneous identifier `not` Impressing confused Python users with magical diagnostics is perhaps worth this not-grossly-unreasonable (only 40ish lines) extra complexity in the parser? Thanks to Vadim Petrochenkov for guidance. This resolves #46836.,HOORAY,2018-04-20T15:50:07Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/49274,MERGED,2018-03-22T14:16:39Z,2018-03-24T21:28:51Z,Remove slow HashSet during miri stack frame creation,oli-obk,f9019aee5bc2f84b69771dc4e2e0cfad5e053566,2,Simplify local accessors,THUMBS_UP,2018-03-22T14:17:36Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49274,MERGED,2018-03-22T14:16:39Z,2018-03-24T21:28:51Z,Remove slow HashSet during miri stack frame creation,oli-obk,f9019aee5bc2f84b69771dc4e2e0cfad5e053566,2,Simplify local accessors,THUMBS_UP,2018-03-23T02:21:30Z,estebank,NA https://github.com/rust-lang/rust/pull/49274,MERGED,2018-03-22T14:16:39Z,2018-03-24T21:28:51Z,Remove slow HashSet during miri stack frame creation,oli-obk,f9019aee5bc2f84b69771dc4e2e0cfad5e053566,2,Simplify local accessors,THUMBS_UP,2018-03-23T08:42:51Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/49284,MERGED,2018-03-22T21:32:27Z,2018-03-25T05:27:14Z,ci: Don't use Travis caches for docker images,alexcrichton,a09e9e9a2a0977d164173d8d08aac9fc3c9c3b4b,2,ci: Don't use Travis caches for docker images This commit moves away from caching on Travis to our own caching on S3 for caching docker layers between builds. Unfortunately the Travis caches have over time had a few critical pain points: * Caches are only updated for successful builds meaning that if a build times out or fails in a different location the sucessfully-created docker images isn't always cached. While this makes sense as a general rule of caches it hurts our use cases. * Caches are per-branch and builder which means that we don't have a separate cache on each release channel. All our merges go through the `auto` branch which means that they're all sharing the same cache even those for merging to master/beta. This means that PRs which switch between master/beta will keep rebuilting and having cache misses. * Caches have historically been invaliated somewhat regularly a little more aggressively than we'd want (I think). * We don't always need to update the contents of the cache if the Docker image didn't change at all and saving off the docker layers can sometimes be quite expensive. For all these reasons this commit drops the usage of Travis's built-in caching support. Instead our own caching is used by storing blobs to S3. Normally this would be a very risky endeavour but we're basically priming a cache for a cache (docker) so if we get this wrong the failure mode is longer builds not stale caches. We'll notice that pretty quickly and hopefully fix it! The logic here is inserted directly into the `src/ci/docker/run.sh` script to download an image based on a shasum of the `Dockerfile` and other assorted files. This blob if found is loaded into docker and we record what layers were inserted. After docker finishes the build (hopefully quickly with lots of cache hits) we then see the sha of the final image. If it's one of the layers we loaded then there's no need to update the cache. Otherwise we upload our layers to the global cache possibly overwriting what we previously just downloaded. This is hopefully a step towards mitigating #49278 although it doesn't completely fix it as it means we'll still probably have to retry builds that bust the cache.,HEART,2018-03-22T22:04:51Z,kennytm,NA https://github.com/rust-lang/rust/pull/49286,CLOSED,2018-03-22T21:54:17Z,2018-05-02T15:13:32Z,"rustdoc: move the ""important traits"" button to beside the type",QuietMisdreavus,NA,NA,NA,THUMBS_UP,2018-04-08T11:57:19Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49291,MERGED,2018-03-23T03:23:38Z,2018-03-29T05:44:57Z,Check for known but incorrect attributes,tejom,4957a40d13a78e0f9f1208cc0528663c49f24386,2,Add extra test for expressions and fix typo in message,THUMBS_UP,2021-12-30T10:44:24Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/49293,MERGED,2018-03-23T03:52:10Z,2018-04-06T09:32:13Z,Add compiletest `--compare-mode nll` option,memoryleak47,03e1509f577c2a474ade1d286210fbf1142d4103,1,make tidy happy,HOORAY,2018-03-23T17:31:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-23T12:31:51Z,chpio,NA https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-23T12:47:28Z,jugglerchris,NA https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-23T14:56:04Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-23T21:28:49Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-24T08:28:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-03-26T08:56:59Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,THUMBS_UP,2018-04-05T12:56:07Z,clux,NA https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,HOORAY,2018-05-24T06:12:45Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49299,MERGED,2018-03-23T10:53:25Z,2018-03-24T21:28:53Z,Stabilize the copy_closures and clone_closures features,SimonSapin,1efe0b34813650fd0715732b6ffa1fff1e60e05f,1,Rename variables in rustc’s SelectionContext::copy_clone_conditions,HOORAY,2018-06-04T11:33:37Z,justanotherdot,NA https://github.com/rust-lang/rust/pull/49304,MERGED,2018-03-23T13:38:10Z,2018-03-28T08:01:32Z,Rustdoc support for universal_impl_trait,sinkuu,4800afa5f5982b06d9cf27ae6003b058ca8855c8,2,Cleanup,THUMBS_UP,2018-03-27T05:12:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-24T00:15:56Z,killercup,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-24T16:06:42Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-24T19:24:01Z,jimmycuadra,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-25T23:31:40Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,THUMBS_DOWN,2018-03-26T19:34:12Z,ollie27,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-27T14:49:11Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-03-27T18:29:32Z,fanzier,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2018-04-04T14:55:35Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,THUMBS_UP,2018-04-05T00:31:14Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49305,MERGED,2018-03-23T13:41:32Z,2018-03-27T14:31:56Z,Stabilize TryFrom / TryInto and tweak impls for integers,SimonSapin,837d6c70233715a0ae8e15c703d40e3046a2f36a,4,Remove TryFrom impls that might become conditionally-infallible with a portability lint https://github.com/rust-lang/rust/pull/49305#issuecomment-376293243,HOORAY,2019-09-19T19:37:10Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/49314,MERGED,2018-03-23T21:09:03Z,2018-03-24T21:28:54Z,Remove getopts leftover from tree,Mark-Simulacrum,700fd5acd063286156d3409bb26152e9174158c3,1,Remove getopts leftover from tree This was attempted but left incomplete in PR #42664 where only the toml file was removed.,LAUGH,2018-03-24T00:19:53Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49316,MERGED,2018-03-23T21:40:42Z,2018-03-30T01:46:12Z,rustc: Group linked libraries where needed,alexcrichton,88114f61b44dba22c6fa180e17d7638f2cf7a9d7,7,"rustc: Group linked libraries where needed This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol the ability to unwind. The `std` crate is the crate which actually defines this symbol but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate ""libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes #18807 Closes #47074",HOORAY,2018-03-27T09:56:49Z,LunNova,github@lunnova.dev https://github.com/rust-lang/rust/pull/49316,MERGED,2018-03-23T21:40:42Z,2018-03-30T01:46:12Z,rustc: Group linked libraries where needed,alexcrichton,88114f61b44dba22c6fa180e17d7638f2cf7a9d7,7,"rustc: Group linked libraries where needed This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol the ability to unwind. The `std` crate is the crate which actually defines this symbol but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate ""libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes #18807 Closes #47074",HOORAY,2018-03-29T13:59:57Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/49316,MERGED,2018-03-23T21:40:42Z,2018-03-30T01:46:12Z,rustc: Group linked libraries where needed,alexcrichton,88114f61b44dba22c6fa180e17d7638f2cf7a9d7,7,"rustc: Group linked libraries where needed This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol the ability to unwind. The `std` crate is the crate which actually defines this symbol but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate ""libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes #18807 Closes #47074",HOORAY,2018-03-29T14:48:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49316,MERGED,2018-03-23T21:40:42Z,2018-03-30T01:46:12Z,rustc: Group linked libraries where needed,alexcrichton,88114f61b44dba22c6fa180e17d7638f2cf7a9d7,7,"rustc: Group linked libraries where needed This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol the ability to unwind. The `std` crate is the crate which actually defines this symbol but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate ""libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes #18807 Closes #47074",HEART,2018-03-30T02:18:31Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/49321,MERGED,2018-03-24T02:28:59Z,2018-04-25T17:07:46Z,Introduce compile-pass,ishitatsuyuki,00bc634f8f396b7a0e1e6545b05eb117b5ddc7c6,3,compiletest: introduce skip-trans,THUMBS_UP,2018-03-24T02:39:50Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49321,MERGED,2018-03-24T02:28:59Z,2018-04-25T17:07:46Z,Introduce compile-pass,ishitatsuyuki,00bc634f8f396b7a0e1e6545b05eb117b5ddc7c6,3,compiletest: introduce skip-trans,THUMBS_UP,2018-03-24T09:45:50Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/49321,MERGED,2018-03-24T02:28:59Z,2018-04-25T17:07:46Z,Introduce compile-pass,ishitatsuyuki,00bc634f8f396b7a0e1e6545b05eb117b5ddc7c6,3,compiletest: introduce skip-trans,THUMBS_UP,2018-03-28T05:57:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49324,MERGED,2018-03-24T10:18:45Z,2018-03-30T21:55:16Z,Deprecate signed std::num::NonZeroI* with a call for use cases ,SimonSapin,cea018f290f05b32ca6b5bcb2f8599d20b5de75c,3,Deprecate signed std::num::NonZeroI* with a call for use cases,HEART,2018-03-25T04:21:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49332,MERGED,2018-03-24T14:43:02Z,2018-03-24T20:17:58Z,[beta] A few final backports,alexcrichton,a1d7c15de185823722e2b847e7d944552ebd16bd,1,Fix DefKey lookup for proc-macro crates.,THUMBS_UP,2018-03-24T20:40:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49345,MERGED,2018-03-24T22:41:33Z,2018-04-05T15:43:41Z,RFC 2008 non-exhaustive enums/structs: Finishing Touches,davidtwco,138472bdc6b428eafc755dbc97b2706fa13a268c,3,Checking location and syntax of non_exhaustive attribute.,HEART,2018-03-24T22:42:07Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49345,MERGED,2018-03-24T22:41:33Z,2018-04-05T15:43:41Z,RFC 2008 non-exhaustive enums/structs: Finishing Touches,davidtwco,138472bdc6b428eafc755dbc97b2706fa13a268c,3,Checking location and syntax of non_exhaustive attribute.,HEART,2018-03-26T05:34:48Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49349,MERGED,2018-03-25T04:20:31Z,2018-04-18T10:53:47Z,Make Handler more thread-safe,Zoxc,e5fc06da8a3b91c8787a6395722e551550161cff,1,Make one_time_diagnostics thread-safe,THUMBS_UP,2018-04-11T01:20:33Z,estebank,NA https://github.com/rust-lang/rust/pull/49353,MERGED,2018-03-25T05:32:04Z,2018-03-26T18:41:59Z,Fix confusing doc for `scan`,chisophugis,f198b0acf512458bdbe5079d12414ff94b03f7ac,1,"Fix confusing doc for `scan` The comment ""the value passed on to the next iteration"" confused me since it sounded more like what Haskell's [scanl](http://hackage.haskell.org/package/base-4.11.0.0/docs/Prelude.html#v:scanl) does where the closure's return value serves as both the ""yielded value"" *and* the new value of the ""state"". I tried changing the example to make it clear that the closure's return value is decoupled from the state argument.",HEART,2018-03-25T08:20:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49353,MERGED,2018-03-25T05:32:04Z,2018-03-26T18:41:59Z,Fix confusing doc for `scan`,chisophugis,f198b0acf512458bdbe5079d12414ff94b03f7ac,1,"Fix confusing doc for `scan` The comment ""the value passed on to the next iteration"" confused me since it sounded more like what Haskell's [scanl](http://hackage.haskell.org/package/base-4.11.0.0/docs/Prelude.html#v:scanl) does where the closure's return value serves as both the ""yielded value"" *and* the new value of the ""state"". I tried changing the example to make it clear that the closure's return value is decoupled from the state argument.",HEART,2018-03-26T02:22:39Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/49358,CLOSED,2018-03-25T12:49:08Z,2018-04-19T01:02:22Z,Implement `clone_raw` for `Rc` and `Arc`,Diggsey,NA,NA,NA,THUMBS_UP,2018-03-25T18:07:56Z,danburkert,dan@danburkert.com https://github.com/rust-lang/rust/pull/49364,MERGED,2018-03-25T17:46:27Z,2018-03-29T00:41:29Z,[incremental] Don't panic if decoding the cache fails,wesleywiser,49fd71bea7bd3d8d11818503ca048227ffa1e758,4,"[incremental] Don't panic if decoding the cache fails If the cached data can't be loaded from disk just issue a warning to the user so they know why compilation is taking longer than usual but don't fail the entire compilation since we can recover by ignorning the on disk cache. In the same way if the disk cache can't be deserialized (because it has been corrupted for some reason) report the issue as a warning and continue without failing the compilation. `Decodable::decode()` tends to panic with various errors like ""entered unreachable code"" or ""index out of range"" if the input data is corrupted. Work around this by catching panics from the `decode()` calls when joining the thread and continuing without the cached data. Fixes #48847",HEART,2018-03-29T00:44:13Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/49383,MERGED,2018-03-26T14:27:13Z,2018-03-28T10:57:42Z,Allow niche-filling dataful variants to be represented as a ScalarPair,nox,bda718fd255237167f08198b0fc80ab0d484d58e,2,Allow niche-filling dataful variants to be represented as a ScalarPair,HEART,2018-03-26T15:18:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49383,MERGED,2018-03-26T14:27:13Z,2018-03-28T10:57:42Z,Allow niche-filling dataful variants to be represented as a ScalarPair,nox,bda718fd255237167f08198b0fc80ab0d484d58e,2,Allow niche-filling dataful variants to be represented as a ScalarPair,HEART,2018-03-27T00:14:05Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49383,MERGED,2018-03-26T14:27:13Z,2018-03-28T10:57:42Z,Allow niche-filling dataful variants to be represented as a ScalarPair,nox,bda718fd255237167f08198b0fc80ab0d484d58e,2,Allow niche-filling dataful variants to be represented as a ScalarPair,HEART,2018-03-28T09:52:34Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/49387,CLOSED,2018-03-26T17:14:02Z,2018-07-10T17:28:14Z,Implement a sandbox for environment variables and files,jsgf,NA,NA,NA,THUMBS_UP,2018-03-27T00:14:54Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49387,CLOSED,2018-03-26T17:14:02Z,2018-07-10T17:28:14Z,Implement a sandbox for environment variables and files,jsgf,NA,NA,NA,THUMBS_UP,2019-03-22T17:11:23Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,THUMBS_UP,2018-03-26T19:26:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HOORAY,2018-03-26T20:29:30Z,varkor,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,THUMBS_UP,2018-03-27T17:59:04Z,fmeum,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HOORAY,2018-04-22T23:55:17Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HOORAY,2018-06-02T08:38:41Z,coryshrmn,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HOORAY,2018-06-23T19:47:40Z,isomorpheme,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HEART,2018-07-21T21:16:37Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HEART,2019-07-24T08:33:03Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,THUMBS_UP,2019-07-25T12:53:22Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,THUMBS_UP,2020-03-18T11:06:14Z,NightMachinery,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,THUMBS_UP,2022-01-30T15:17:23Z,Warkanlock,NA https://github.com/rust-lang/rust/pull/49389,MERGED,2018-03-26T18:35:03Z,2018-04-13T10:34:01Z,Implement RFC #2169 (Euclidean modulo).,fanzier,ca4e458089d0fecb8684de0437534d5f40b003bf,1,Address more nits.,HOORAY,2022-01-30T15:17:24Z,Warkanlock,NA https://github.com/rust-lang/rust/pull/49390,MERGED,2018-03-26T19:36:22Z,2018-04-10T11:45:13Z,More thread-safety changes,Zoxc,1e3f6388361e1489d27679d6b9e8ba16681e3d26,2,Make LLVM worker channel thread-safe,HEART,2018-03-27T00:16:08Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49394,MERGED,2018-03-26T21:45:03Z,2018-03-28T18:11:58Z,Stabilize match_default_bindings,cramertj,3c65f536206a4df9900f5f6666f3674817d3638b,56,Stabilize match_default_bindings This includes a submodule update to rustfmt in order to allow a stable feature declaration.,HOORAY,2018-03-27T05:03:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49394,MERGED,2018-03-26T21:45:03Z,2018-03-28T18:11:58Z,Stabilize match_default_bindings,cramertj,3c65f536206a4df9900f5f6666f3674817d3638b,56,Stabilize match_default_bindings This includes a submodule update to rustfmt in order to allow a stable feature declaration.,HOORAY,2018-03-27T07:04:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49394,MERGED,2018-03-26T21:45:03Z,2018-03-28T18:11:58Z,Stabilize match_default_bindings,cramertj,3c65f536206a4df9900f5f6666f3674817d3638b,56,Stabilize match_default_bindings This includes a submodule update to rustfmt in order to allow a stable feature declaration.,HOORAY,2018-03-27T21:48:06Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/49395,MERGED,2018-03-26T21:47:08Z,2018-03-28T05:30:15Z,libsyntax: Remove obsolete.rs,petrochenkov,604bbee84cbd0ef5064bfd6b40c384268b1b38c0,3,libsyntax: Remove obsolete.rs,LAUGH,2018-03-27T05:03:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49420,MERGED,2018-03-27T14:45:58Z,2018-04-27T03:53:40Z,Use ScalarPair for tagged enums,nox,3ca6ad922eb6d8c3139d961c844a0194eaf58770,4,Use ScalarPair for tagged enums,HEART,2018-03-28T13:27:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49420,MERGED,2018-03-27T14:45:58Z,2018-04-27T03:53:40Z,Use ScalarPair for tagged enums,nox,3ca6ad922eb6d8c3139d961c844a0194eaf58770,4,Use ScalarPair for tagged enums,HEART,2018-04-14T16:54:20Z,est31,NA https://github.com/rust-lang/rust/pull/49420,MERGED,2018-03-27T14:45:58Z,2018-04-27T03:53:40Z,Use ScalarPair for tagged enums,nox,3ca6ad922eb6d8c3139d961c844a0194eaf58770,4,Use ScalarPair for tagged enums,HEART,2018-04-25T15:36:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49422,MERGED,2018-03-27T17:30:01Z,2018-03-30T09:11:21Z,Stabilize fs::read and fs::write,mbrubeck,0600d0f38d4998f1cacb3b97408224a0ee350db4,1,Stabilize fs::read and fs::write,HEART,2018-03-27T17:58:48Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49422,MERGED,2018-03-27T17:30:01Z,2018-03-30T09:11:21Z,Stabilize fs::read and fs::write,mbrubeck,0600d0f38d4998f1cacb3b97408224a0ee350db4,1,Stabilize fs::read and fs::write,HEART,2018-03-29T20:09:18Z,sfackler,NA https://github.com/rust-lang/rust/pull/49425,MERGED,2018-03-27T18:46:18Z,2018-03-30T16:44:28Z,rustc: Forbid #[inline(always)] with #[target_feature],alexcrichton,38d48ef53778674baa99dd0a3a193cec78f74e63,3,rustc: Forbid #[inline(always)] with #[target_feature] Once a target feature is enabled for a function that means that it in general can't be inlined into other functions which don't have that target feature enabled. This can cause both safety and LLVM issues if we were to actually inline it so `#[inline(always)]` both can't be respected and would be an error if we did so! Today LLVM doesn't inline functions with different `#[target_feature]` annotations but it turns out that if one is tagged with `#[inline(always)]` it'll override this and cause scary LLVM error to arise! This commit fixes this issue by forbidding these two attributes to be used in conjunction with one another. cc rust-lang-nursery/stdsimd#404,THUMBS_UP,2018-03-27T18:47:19Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/49425,MERGED,2018-03-27T18:46:18Z,2018-03-30T16:44:28Z,rustc: Forbid #[inline(always)] with #[target_feature],alexcrichton,38d48ef53778674baa99dd0a3a193cec78f74e63,3,rustc: Forbid #[inline(always)] with #[target_feature] Once a target feature is enabled for a function that means that it in general can't be inlined into other functions which don't have that target feature enabled. This can cause both safety and LLVM issues if we were to actually inline it so `#[inline(always)]` both can't be respected and would be an error if we did so! Today LLVM doesn't inline functions with different `#[target_feature]` annotations but it turns out that if one is tagged with `#[inline(always)]` it'll override this and cause scary LLVM error to arise! This commit fixes this issue by forbidding these two attributes to be used in conjunction with one another. cc rust-lang-nursery/stdsimd#404,HEART,2018-03-27T19:03:13Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/49425,MERGED,2018-03-27T18:46:18Z,2018-03-30T16:44:28Z,rustc: Forbid #[inline(always)] with #[target_feature],alexcrichton,38d48ef53778674baa99dd0a3a193cec78f74e63,3,rustc: Forbid #[inline(always)] with #[target_feature] Once a target feature is enabled for a function that means that it in general can't be inlined into other functions which don't have that target feature enabled. This can cause both safety and LLVM issues if we were to actually inline it so `#[inline(always)]` both can't be respected and would be an error if we did so! Today LLVM doesn't inline functions with different `#[target_feature]` annotations but it turns out that if one is tagged with `#[inline(always)]` it'll override this and cause scary LLVM error to arise! This commit fixes this issue by forbidding these two attributes to be used in conjunction with one another. cc rust-lang-nursery/stdsimd#404,HEART,2018-03-27T19:34:45Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/49425,MERGED,2018-03-27T18:46:18Z,2018-03-30T16:44:28Z,rustc: Forbid #[inline(always)] with #[target_feature],alexcrichton,38d48ef53778674baa99dd0a3a193cec78f74e63,3,rustc: Forbid #[inline(always)] with #[target_feature] Once a target feature is enabled for a function that means that it in general can't be inlined into other functions which don't have that target feature enabled. This can cause both safety and LLVM issues if we were to actually inline it so `#[inline(always)]` both can't be respected and would be an error if we did so! Today LLVM doesn't inline functions with different `#[target_feature]` annotations but it turns out that if one is tagged with `#[inline(always)]` it'll override this and cause scary LLVM error to arise! This commit fixes this issue by forbidding these two attributes to be used in conjunction with one another. cc rust-lang-nursery/stdsimd#404,THUMBS_UP,2018-03-27T19:34:45Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/49425,MERGED,2018-03-27T18:46:18Z,2018-03-30T16:44:28Z,rustc: Forbid #[inline(always)] with #[target_feature],alexcrichton,38d48ef53778674baa99dd0a3a193cec78f74e63,3,rustc: Forbid #[inline(always)] with #[target_feature] Once a target feature is enabled for a function that means that it in general can't be inlined into other functions which don't have that target feature enabled. This can cause both safety and LLVM issues if we were to actually inline it so `#[inline(always)]` both can't be respected and would be an error if we did so! Today LLVM doesn't inline functions with different `#[target_feature]` annotations but it turns out that if one is tagged with `#[inline(always)]` it'll override this and cause scary LLVM error to arise! This commit fixes this issue by forbidding these two attributes to be used in conjunction with one another. cc rust-lang-nursery/stdsimd#404,THUMBS_UP,2018-03-27T22:47:02Z,parched,NA https://github.com/rust-lang/rust/pull/49427,MERGED,2018-03-27T19:27:53Z,2018-03-29T00:41:34Z,Correctly handle impl trait in external items in rustdoc,Manishearth,33dceaa24409951dfe7607c580de6fd504932c90,2,rustdoc: Add test for foreign impl trait with bounds,HOORAY,2018-03-27T22:08:42Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/49427,MERGED,2018-03-27T19:27:53Z,2018-03-29T00:41:34Z,Correctly handle impl trait in external items in rustdoc,Manishearth,33dceaa24409951dfe7607c580de6fd504932c90,2,rustdoc: Add test for foreign impl trait with bounds,HOORAY,2018-03-28T17:45:31Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49428,MERGED,2018-03-27T19:54:43Z,2018-03-29T00:41:34Z,Enable target_feature on any LLVM 6+,cuviper,a93a4d259ae3670d748859f430aba94f065ea6df,2,Enable target_feature on any LLVM 6+ In `LLVMRustHasFeature()` rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.,HEART,2018-03-27T20:12:07Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49428,MERGED,2018-03-27T19:54:43Z,2018-03-29T00:41:34Z,Enable target_feature on any LLVM 6+,cuviper,a93a4d259ae3670d748859f430aba94f065ea6df,2,Enable target_feature on any LLVM 6+ In `LLVMRustHasFeature()` rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.,THUMBS_UP,2018-03-27T22:53:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49428,MERGED,2018-03-27T19:54:43Z,2018-03-29T00:41:34Z,Enable target_feature on any LLVM 6+,cuviper,a93a4d259ae3670d748859f430aba94f065ea6df,2,Enable target_feature on any LLVM 6+ In `LLVMRustHasFeature()` rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.,HOORAY,2018-03-28T06:44:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49428,MERGED,2018-03-27T19:54:43Z,2018-03-29T00:41:34Z,Enable target_feature on any LLVM 6+,cuviper,a93a4d259ae3670d748859f430aba94f065ea6df,2,Enable target_feature on any LLVM 6+ In `LLVMRustHasFeature()` rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.,HEART,2018-04-05T00:40:41Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49428,MERGED,2018-03-27T19:54:43Z,2018-03-29T00:41:34Z,Enable target_feature on any LLVM 6+,cuviper,a93a4d259ae3670d748859f430aba94f065ea6df,2,Enable target_feature on any LLVM 6+ In `LLVMRustHasFeature()` rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.,THUMBS_UP,2018-04-05T06:50:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49432,MERGED,2018-03-27T21:30:25Z,2018-04-05T15:43:45Z,Flush executables to disk after linkage,nabijaczleweli,e1d3c471d75bbc4360eee17178ccb32dce348542,1,Open the file as write before trying to flush it This should be enough and shouldn't require append(true) since we're not explicitly writing anything so we're not flushing it so we've no risk of overwriting it,THUMBS_UP,2018-03-27T22:56:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49433,MERGED,2018-03-27T21:55:11Z,2018-04-16T13:22:10Z,Skip MIR encoding for cargo check,varkor,5576ce84cf13a32ebcf9a08366e3117da9832c84,1,Take OutputType::DepInfo into account for metadata_output_only,THUMBS_UP,2018-03-27T22:39:34Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/49446,MERGED,2018-03-28T09:28:01Z,2018-03-30T06:49:58Z,Explicitly mention `Option` in `?` error message.,frewsxcv,1f143bc46fe04aa564736b4741a8f179c46eccc5,3,Explicitly mention `Option` in `?` error message. Save users the time/effort of having to lookup what types implement the `Try` trait.,HOORAY,2018-03-30T05:33:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49466,MERGED,2018-03-29T00:43:43Z,2018-03-30T06:50:00Z,Use f{32 64}::to_bits for is_zero test in vec::SpecFromElem,glandium,262be13643cf5e3ff4f4e880b2dee601d4740fd8,1,Use f{32 64}::to_bits for is_zero test in vec::SpecFromElem vec::SpecFromElem provides an optimization to use calloc to fill a Vec when the element given to fill the Vec is represented by 0. For floats the test for that currently used is `x == 0. && x.is_sign_positive()`. When compiled in a standalone function rustc generates the following assembly: ``` xorps xmm1 xmm1 ucomisd xmm0 xmm1 setnp al sete cl and cl al movq rax xmm0 test rax rax setns al and al cl ret ``` A simpler test telling us whether the value is represented by 0 is `x.to_bits() == 0` which rustc compiles to: ``` movq rax xmm0 test rax rax sete al ret ``` Not that the test is hot in any way but it also makes it clearer what the intent in the rust code is.,THUMBS_UP,2018-03-29T18:25:44Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49466,MERGED,2018-03-29T00:43:43Z,2018-03-30T06:50:00Z,Use f{32 64}::to_bits for is_zero test in vec::SpecFromElem,glandium,262be13643cf5e3ff4f4e880b2dee601d4740fd8,1,Use f{32 64}::to_bits for is_zero test in vec::SpecFromElem vec::SpecFromElem provides an optimization to use calloc to fill a Vec when the element given to fill the Vec is represented by 0. For floats the test for that currently used is `x == 0. && x.is_sign_positive()`. When compiled in a standalone function rustc generates the following assembly: ``` xorps xmm1 xmm1 ucomisd xmm0 xmm1 setnp al sete cl and cl al movq rax xmm0 test rax rax setns al and al cl ret ``` A simpler test telling us whether the value is represented by 0 is `x.to_bits() == 0` which rustc compiles to: ``` movq rax xmm0 test rax rax sete al ret ``` Not that the test is hot in any way but it also makes it clearer what the intent in the rust code is.,HEART,2018-03-30T05:34:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49469,MERGED,2018-03-29T03:46:54Z,2018-06-26T11:20:19Z,Implementation of RFC 2086 - Allow Irrefutable Let patterns,Nokel81,91680347a7ef48ddffd9ff06eedb54a550891cf1,1,make the `while let` loop terminate,HOORAY,2018-03-30T05:37:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T11:42:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T11:51:53Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T13:01:50Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T14:46:20Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-03-29T16:15:41Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-03-29T16:45:32Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T18:29:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-03-29T18:29:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-29T22:39:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-03-29T22:39:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-03-31T21:55:46Z,mcarton,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-04-03T00:53:09Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-04-04T13:05:59Z,est31,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,HOORAY,2018-04-04T13:06:00Z,est31,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-05-04T01:25:34Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-05-04T07:23:22Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-05-10T03:35:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49479,MERGED,2018-03-29T11:29:07Z,2018-05-16T20:22:12Z,Reenable the MergeFunctions pass,nox,5701779b8e1ad05dc5eb165b4b00188fb43ebbf2,1,Reenable the MergeFunctions pass The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.,THUMBS_UP,2018-05-12T14:02:36Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/49487,CLOSED,2018-03-29T20:36:20Z,2018-03-30T08:13:48Z,[WIP] test enabling i128 lowering for emscripten,est31,NA,NA,NA,HEART,2018-03-30T05:14:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HEART,2018-03-31T06:53:33Z,fitzgen,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-03-31T06:53:37Z,fitzgen,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HEART,2018-03-31T07:32:18Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-03-31T07:32:19Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",THUMBS_UP,2018-03-31T08:42:32Z,NikVolf,nikvolf@gmail.com https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-04-05T07:33:02Z,killercup,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-04-06T17:56:56Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",THUMBS_UP,2018-04-09T08:32:05Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HEART,2018-04-12T01:32:24Z,estebank,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HEART,2018-04-16T22:09:26Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",THUMBS_UP,2018-04-17T00:38:54Z,minstrel271,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-04-24T22:38:06Z,Thiez,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",HOORAY,2018-04-27T14:02:31Z,chrish42,NA https://github.com/rust-lang/rust/pull/49488,MERGED,2018-03-29T22:05:51Z,2018-04-17T01:41:50Z,std: Minimize size of panicking on wasm,alexcrichton,46d16b66e0b017430eb50b247926ea447c60ef07,4,"std: Avoid allocating panic message unless needed This commit removes allocation of the panic message in instances like `panic!(""foo: {}"" ""bar"")` if we don't actually end up needing the message. We don't need it in the case of wasm32 right now and in general it's not needed for panic=abort instances that use the default panic hook. For now this commit only solves the wasm use case where with LTO the allocation is entirely removed but the panic=abort use case can be implemented at a later date if needed.",THUMBS_UP,2018-05-02T16:27:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49490,CLOSED,2018-03-29T23:43:54Z,2018-04-09T20:52:01Z,Removed hacks before clonable closures was a thing.,clarfonthey,NA,NA,NA,HOORAY,2018-03-30T09:47:15Z,est31,NA https://github.com/rust-lang/rust/pull/49496,MERGED,2018-03-30T08:51:09Z,2018-04-05T15:43:47Z,Add more vec![... ; n] optimizations,glandium,0df837f79289819f9b671b67d4e63dfe5c80d419,1,Add vec!['\0'; n] optimization like vec![0; n] Similarly to vec![ptr::null{ _mut}(); n] in previous change this adds the optimization for vec!['\0'; n].,THUMBS_UP,2018-03-30T12:14:24Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49499,CLOSED,2018-03-30T09:45:39Z,2018-04-09T10:06:02Z,Swap the 2 variants of Option,nox,NA,NA,NA,HEART,2018-03-31T05:46:45Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49512,MERGED,2018-03-30T13:44:55Z,2018-04-05T00:19:42Z,Add support for variant and types fields for intra links,GuillaumeGomez,d0eeb291dddb99ad6f2aedafa5355556b40e483f,2,Add support for variant and types fields for intra links,HEART,2018-03-31T14:55:41Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/49512,MERGED,2018-03-30T13:44:55Z,2018-04-05T00:19:42Z,Add support for variant and types fields for intra links,GuillaumeGomez,d0eeb291dddb99ad6f2aedafa5355556b40e483f,2,Add support for variant and types fields for intra links,HEART,2018-04-02T20:41:48Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/49513,MERGED,2018-03-30T13:55:54Z,2018-04-26T20:49:57Z,Treat repr(Rust) univariant fieldless enums as ZSTs,nox,1c09977c9a1aa344c52ddf44ebd42bacd876274b,1,Mark SingleVariant as repr(u8) in c-style-enum I should rather properly fix debuginfo but I have no clue how to do that.,HEART,2018-03-31T04:12:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49513,MERGED,2018-03-30T13:55:54Z,2018-04-26T20:49:57Z,Treat repr(Rust) univariant fieldless enums as ZSTs,nox,1c09977c9a1aa344c52ddf44ebd42bacd876274b,1,Mark SingleVariant as repr(u8) in c-style-enum I should rather properly fix debuginfo but I have no clue how to do that.,HEART,2018-04-11T01:32:47Z,estebank,NA https://github.com/rust-lang/rust/pull/49513,MERGED,2018-03-30T13:55:54Z,2018-04-26T20:49:57Z,Treat repr(Rust) univariant fieldless enums as ZSTs,nox,1c09977c9a1aa344c52ddf44ebd42bacd876274b,1,Mark SingleVariant as repr(u8) in c-style-enum I should rather properly fix debuginfo but I have no clue how to do that.,HEART,2018-04-18T08:10:19Z,est31,NA https://github.com/rust-lang/rust/pull/49513,MERGED,2018-03-30T13:55:54Z,2018-04-26T20:49:57Z,Treat repr(Rust) univariant fieldless enums as ZSTs,nox,1c09977c9a1aa344c52ddf44ebd42bacd876274b,1,Mark SingleVariant as repr(u8) in c-style-enum I should rather properly fix debuginfo but I have no clue how to do that.,HEART,2018-04-28T05:44:47Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/49513,MERGED,2018-03-30T13:55:54Z,2018-04-26T20:49:57Z,Treat repr(Rust) univariant fieldless enums as ZSTs,nox,1c09977c9a1aa344c52ddf44ebd42bacd876274b,1,Mark SingleVariant as repr(u8) in c-style-enum I should rather properly fix debuginfo but I have no clue how to do that.,THUMBS_UP,2018-05-03T04:09:06Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-30T14:58:38Z,flosse,NA https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-30T15:03:56Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-30T15:17:53Z,tirkarthi,tir.karthi@gmail.com https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-30T15:39:56Z,nayato,NA https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-30T17:03:24Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-31T15:45:31Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-03-31T23:08:10Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-04-26T19:09:22Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/49518,MERGED,2018-03-30T14:43:06Z,2018-03-30T19:11:40Z,"Revert ""Add TryFrom and TryInto to the prelude""",SimonSapin,ba4f310e3fc961af7b9e6db52c53b51244473ae7,2,"Revert ""Add TryFrom and TryInto to the prelude"" This reverts commit 09008cc23ff6395c2c928f3690e07d7389d08ebc.",THUMBS_UP,2018-05-02T02:26:39Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/49522,MERGED,2018-03-30T17:18:23Z,2018-04-01T05:10:04Z,Rename fs::read_string to read_to_string and stabilize,mbrubeck,6b7627f8c9858303d85a97217ddf38abec9425d3,3,Rename fs::read_string to read_to_string and stabilize,HOORAY,2018-03-30T17:20:21Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/49522,MERGED,2018-03-30T17:18:23Z,2018-04-01T05:10:04Z,Rename fs::read_string to read_to_string and stabilize,mbrubeck,6b7627f8c9858303d85a97217ddf38abec9425d3,3,Rename fs::read_string to read_to_string and stabilize,HEART,2018-03-30T17:20:23Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/49522,MERGED,2018-03-30T17:18:23Z,2018-04-01T05:10:04Z,Rename fs::read_string to read_to_string and stabilize,mbrubeck,6b7627f8c9858303d85a97217ddf38abec9425d3,3,Rename fs::read_string to read_to_string and stabilize,THUMBS_UP,2018-03-30T17:20:25Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HEART,2018-03-30T17:50:47Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HEART,2018-03-30T20:26:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HOORAY,2018-03-30T22:16:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HOORAY,2018-03-30T23:35:49Z,kennytm,NA https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,THUMBS_UP,2018-03-31T03:50:28Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,THUMBS_UP,2018-03-31T20:34:42Z,est31,NA https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HEART,2018-04-04T20:22:11Z,AlexArgoAi,NA https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HOORAY,2018-04-12T11:38:00Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,THUMBS_UP,2018-05-08T21:00:06Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HOORAY,2018-05-08T21:00:07Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/49523,MERGED,2018-03-30T17:37:28Z,2018-05-09T15:44:27Z,Update RELEASES.md for 1.26.0,XAMPPRocky,111786d30e346f356e87d5ec4e6da218d66a85e2,1,Update RELEASES.md,HEART,2018-05-08T21:00:07Z,jnicholls,jarred.nicholls@gmail.com https://github.com/rust-lang/rust/pull/49527,MERGED,2018-03-30T23:46:19Z,2018-04-01T02:45:03Z,Handle fast-submodules option correctly,petrhosek,a24811e15a68b94c1fd90261f3b1036dad17add6,2,Handle fast-submodules option correctly This option was introduced in 72cb109bec8 but it uses two different spellings (fast-submodule vs fast-submodules) and isn't handled by Rust bootstrap which means that any attempt to set this flag fails.,HEART,2018-03-31T06:23:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),HOORAY,2018-03-31T07:08:20Z,novacrazy,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-03-31T07:32:11Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-03-31T10:59:48Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-03-31T11:50:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-03-31T12:03:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),HOORAY,2018-04-01T00:02:49Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),HEART,2018-04-03T13:49:58Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-04-05T18:13:56Z,jminer,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-06-01T12:44:08Z,mati865,NA https://github.com/rust-lang/rust/pull/49533,MERGED,2018-03-31T06:09:37Z,2018-04-05T00:19:44Z,Add #[must_use] to a few standard library methods,scottmcm,fb7deda27419eae61da3cbf5a5b1b4f51ae16d04,4,Add #[must_use] to a few standard library methods Chosen to start a precedent of using it on ones that are potentially-expensive and where using it for side effects is particularly discouraged. Discuss :),THUMBS_UP,2018-07-06T04:40:04Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/49536,CLOSED,2018-03-31T10:20:04Z,2018-04-20T16:15:10Z,Soft-deprecate the description() method of the Error trait,SimonSapin,NA,NA,NA,HOORAY,2018-04-20T15:26:49Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49546,MERGED,2018-03-31T22:11:23Z,2018-05-31T22:58:33Z,Stabilize short error format,GuillaumeGomez,426b63f8a3aed16b293a34345714c13c836e9276,2,Make short-error format GNU compatible,HEART,2018-04-19T19:13:14Z,kennytm,NA https://github.com/rust-lang/rust/pull/49546,MERGED,2018-03-31T22:11:23Z,2018-05-31T22:58:33Z,Stabilize short error format,GuillaumeGomez,426b63f8a3aed16b293a34345714c13c836e9276,2,Make short-error format GNU compatible,HEART,2018-06-06T14:44:29Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/49546,MERGED,2018-03-31T22:11:23Z,2018-05-31T22:58:33Z,Stabilize short error format,GuillaumeGomez,426b63f8a3aed16b293a34345714c13c836e9276,2,Make short-error format GNU compatible,HEART,2018-06-07T15:02:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49546,MERGED,2018-03-31T22:11:23Z,2018-05-31T22:58:33Z,Stabilize short error format,GuillaumeGomez,426b63f8a3aed16b293a34345714c13c836e9276,2,Make short-error format GNU compatible,HOORAY,2018-08-01T08:58:37Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49555,MERGED,2018-04-01T10:01:55Z,2018-04-16T23:19:53Z,Inline most of the code paths for conversions with boxed slices,nox,b59fa0d9e81fe36c5d298f8f828aaf0755e96f89,1,Remove #[inline(always)] on Vec::into_boxed_slice,THUMBS_UP,2018-04-01T18:21:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49563,MERGED,2018-04-01T17:01:30Z,2018-04-05T15:43:50Z,add a dist builder to build rust-std components for the THUMB targets,japaric,b1015f5c5a4dcd6118b86ef5361371f04a7bce8b,1,compile other no-std crates,THUMBS_UP,2018-04-01T17:11:14Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/49563,MERGED,2018-04-01T17:01:30Z,2018-04-05T15:43:50Z,add a dist builder to build rust-std components for the THUMB targets,japaric,b1015f5c5a4dcd6118b86ef5361371f04a7bce8b,1,compile other no-std crates,THUMBS_UP,2018-04-01T17:35:29Z,azasypkin,aleh.zasypkin@gmail.com https://github.com/rust-lang/rust/pull/49563,MERGED,2018-04-01T17:01:30Z,2018-04-05T15:43:50Z,add a dist builder to build rust-std components for the THUMB targets,japaric,b1015f5c5a4dcd6118b86ef5361371f04a7bce8b,1,compile other no-std crates,THUMBS_UP,2018-04-01T18:21:46Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49563,MERGED,2018-04-01T17:01:30Z,2018-04-05T15:43:50Z,add a dist builder to build rust-std components for the THUMB targets,japaric,b1015f5c5a4dcd6118b86ef5361371f04a7bce8b,1,compile other no-std crates,HEART,2018-04-02T07:36:03Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/49575,MERGED,2018-04-02T04:37:10Z,2018-04-12T00:35:44Z,Stabilize `Option::filter`.,tmccombs,c7ac32a1c1b35cb2206d9f09549cf93ef8b31e76,2,Remove uses of option_filter feature,HOORAY,2018-04-21T18:41:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49575,MERGED,2018-04-02T04:37:10Z,2018-04-12T00:35:44Z,Stabilize `Option::filter`.,tmccombs,c7ac32a1c1b35cb2206d9f09549cf93ef8b31e76,2,Remove uses of option_filter feature,HOORAY,2018-04-29T13:26:13Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49587,MERGED,2018-04-02T14:11:10Z,2018-04-05T02:44:26Z,Update RLS,Bobo1239,ae86e83c526af80db2571e1b4acab2aee0d6bd09,2,Update RLS,THUMBS_UP,2018-04-04T05:07:00Z,gheoan,NA https://github.com/rust-lang/rust/pull/49589,MERGED,2018-04-02T15:39:49Z,2018-04-03T03:27:30Z,[beta] Prepare the 1.26.0 beta release,alexcrichton,09d0a980d65f87fbfb69a82cc2c2e2b781a2fbbe,1,Don't verify miri's build status on beta,HOORAY,2018-04-02T18:00:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/49597,MERGED,2018-04-02T19:16:59Z,2018-04-05T22:28:00Z,proc_macro: Reorganize public API,alexcrichton,a57b1fbd84543880e4cba99013c81b7b82292c31,1,Tweak doc comment expansion * Expand `!` tokens for inner doc comments * Trim leading doc comment decoration in the string literal Both of these should help bring the expansion inline with what `macro_rules!` already does. Closes #49655 Closes #49656,THUMBS_UP,2018-04-04T13:08:54Z,hcpl,NA https://github.com/rust-lang/rust/pull/49597,MERGED,2018-04-02T19:16:59Z,2018-04-05T22:28:00Z,proc_macro: Reorganize public API,alexcrichton,a57b1fbd84543880e4cba99013c81b7b82292c31,1,Tweak doc comment expansion * Expand `!` tokens for inner doc comments * Trim leading doc comment decoration in the string literal Both of these should help bring the expansion inline with what `macro_rules!` already does. Closes #49655 Closes #49656,THUMBS_UP,2018-04-11T11:09:41Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/49606,MERGED,2018-04-02T22:57:38Z,2018-04-16T23:19:53Z,Prevent broken pipes causing ICEs,varkor,7ab31f6556c2cce433695b113f53d6275edd724d,4,Prevent EPIPE causing ICEs in rustc and rustdoc,HOORAY,2018-04-03T01:23:24Z,est31,NA https://github.com/rust-lang/rust/pull/49606,MERGED,2018-04-02T22:57:38Z,2018-04-16T23:19:53Z,Prevent broken pipes causing ICEs,varkor,7ab31f6556c2cce433695b113f53d6275edd724d,4,Prevent EPIPE causing ICEs in rustc and rustdoc,LAUGH,2018-04-08T15:15:04Z,kennytm,NA https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-04-03T04:20:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-04-03T16:56:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-04-11T11:49:39Z,justinrlle,justinrlle@pm.me https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-04-12T20:53:54Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-04-21T01:36:34Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2018-05-21T19:11:48Z,JulianSchmid,NA https://github.com/rust-lang/rust/pull/49607,MERGED,2018-04-03T00:02:02Z,2018-04-05T00:19:51Z,Stabilize iterator methods in 1.27,cuviper,9db63bb033271c7b9c9f4315eb6db3314758a33e,3,Stabilize iterator_try_fold in 1.27.0,HOORAY,2019-12-23T07:54:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49611,CLOSED,2018-04-03T01:17:53Z,2018-05-03T01:49:52Z,Edition-gated keywords,Manishearth,NA,NA,NA,HEART,2018-04-10T22:39:29Z,estebank,NA https://github.com/rust-lang/rust/pull/49614,MERGED,2018-04-03T03:20:17Z,2018-04-12T00:35:45Z,in which the non-shorthand patterns lint keeps its own counsel in macros,zackmdavis,a1d90a2a2a2d3ff6843d8fca17be4819dba9ab6b,2,"in which the non-shorthand patterns lint keeps its own counsel in macros In issue #49588 Michael Lamparski pointed out a scenario in which the non-shorthand-field-patterns lint could be triggered by a macro-expanded pattern in a way which was direly unwieldy for the macro author to guard against and unreasonable to expect the macro user to take into account. We can avoid this by not linting patterns that come from macro-expansions. Although this entails accepting ""false negatives"" where the lint could genuinely improve macro-templated code avoiding the reported ""true-but-super-annoying positive"" may be worth the trade? (Some precedent for these relative priorities exists as no. 47775 (5985b0b0).) Resolves #49588.",HOORAY,2018-04-03T11:27:15Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/49614,MERGED,2018-04-03T03:20:17Z,2018-04-12T00:35:45Z,in which the non-shorthand patterns lint keeps its own counsel in macros,zackmdavis,a1d90a2a2a2d3ff6843d8fca17be4819dba9ab6b,2,"in which the non-shorthand patterns lint keeps its own counsel in macros In issue #49588 Michael Lamparski pointed out a scenario in which the non-shorthand-field-patterns lint could be triggered by a macro-expanded pattern in a way which was direly unwieldy for the macro author to guard against and unreasonable to expect the macro user to take into account. We can avoid this by not linting patterns that come from macro-expansions. Although this entails accepting ""false negatives"" where the lint could genuinely improve macro-templated code avoiding the reported ""true-but-super-annoying positive"" may be worth the trade? (Some precedent for these relative priorities exists as no. 47775 (5985b0b0).) Resolves #49588.",THUMBS_UP,2018-04-03T20:18:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49621,MERGED,2018-04-03T14:01:51Z,2018-04-05T22:28:01Z,impl Unpin for Pin,Nemo157,a29d4d9ad6fb27003712932566724be265e354cd,1,impl Unpin for PinBox,LAUGH,2018-04-03T18:28:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-04-03T16:28:49Z,marioidival,marioidival@gmail.com https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-04-03T17:45:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-04-12T21:00:17Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-06-09T09:47:36Z,xerz-one,NA https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HEART,2018-06-21T23:41:54Z,Harnesser,NA https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-06-22T13:49:07Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HEART,2018-06-22T13:49:11Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HEART,2018-07-02T13:24:10Z,viluon,hire@viluon.me https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HEART,2018-07-03T06:14:23Z,artshell,872780008@qq.com https://github.com/rust-lang/rust/pull/49623,MERGED,2018-04-03T14:32:33Z,2018-04-07T02:51:34Z,update mdbook,steveklabnik,ecfbaca13e8afa7a9b3dca80d085501d09014567,2,update mdbook This includes search for all books a long-requested feature!,HOORAY,2018-07-03T06:14:27Z,artshell,872780008@qq.com https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-04-03T14:34:56Z,sinkuu,NA https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-04-03T20:14:58Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-04-04T17:58:10Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-04-06T00:45:47Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-06-07T03:23:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-06-12T12:29:56Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,HOORAY,2018-06-12T17:42:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/49624,CLOSED,2018-04-03T14:32:46Z,2018-07-03T17:21:51Z,#48538 Specialization: Intersection Impls,giannicic,NA,NA,NA,THUMBS_UP,2019-09-14T06:27:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/49628,MERGED,2018-04-03T16:43:21Z,2018-04-05T00:19:55Z,Re-write the documentation index,steveklabnik,77b570f831c128278f3716f887f3d8e0efe6801e,1,"Re-write the documentation index The docs team has decided that we're framing resources in three ways: ""learning Rust "" ""using Rust "" ""mastering Rust."" This is a more useful split than ""beginner/intermediate/advanced."" As we add more resources in the future we expect ""using Rust"" to grow. ""the bookshelf"" as a concept is great but isn't really organized along these lines. As such this reorganizes the docs along these lines.",THUMBS_UP,2018-04-03T17:44:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49642,MERGED,2018-04-04T09:07:32Z,2018-04-05T00:19:58Z,Rollup of 25 pull requests,kennytm,00ada06bba83b0f6b780b017e4de406b0cee37ac,1,Rollup merge of #49547 - Phlosioneer:44831-borrowck-remove-ignore r=arielb1 Unignore borrowck test Unignores a test that has been fixed. See #44831,HEART,2018-04-04T19:21:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49642,MERGED,2018-04-04T09:07:32Z,2018-04-05T00:19:58Z,Rollup of 25 pull requests,kennytm,00ada06bba83b0f6b780b017e4de406b0cee37ac,1,Rollup merge of #49547 - Phlosioneer:44831-borrowck-remove-ignore r=arielb1 Unignore borrowck test Unignores a test that has been fixed. See #44831,HEART,2018-04-04T20:17:34Z,novacrazy,NA https://github.com/rust-lang/rust/pull/49654,MERGED,2018-04-04T15:16:13Z,2018-04-05T15:43:54Z,Host compiler documentation: Include private items,davidtwco,809d01c62ef25814abf8e490eb80128989985014,5,Updated codeblocks to specify language where required.,HOORAY,2018-04-04T22:44:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49654,MERGED,2018-04-04T15:16:13Z,2018-04-05T15:43:54Z,Host compiler documentation: Include private items,davidtwco,809d01c62ef25814abf8e490eb80128989985014,5,Updated codeblocks to specify language where required.,THUMBS_UP,2018-04-05T13:40:55Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49661,MERGED,2018-04-04T16:15:52Z,2018-04-07T14:34:05Z,Bump the bootstrap compiler to 1.26.0 beta,alexcrichton,8958815916201421b0a6648c68d7eb31bd3197ee,39,Bump the bootstrap compiler to 1.26.0 beta Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language features!,LAUGH,2018-04-04T16:17:41Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/49661,MERGED,2018-04-04T16:15:52Z,2018-04-07T14:34:05Z,Bump the bootstrap compiler to 1.26.0 beta,alexcrichton,8958815916201421b0a6648c68d7eb31bd3197ee,39,Bump the bootstrap compiler to 1.26.0 beta Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language features!,LAUGH,2018-04-04T18:25:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/49661,MERGED,2018-04-04T16:15:52Z,2018-04-07T14:34:05Z,Bump the bootstrap compiler to 1.26.0 beta,alexcrichton,8958815916201421b0a6648c68d7eb31bd3197ee,39,Bump the bootstrap compiler to 1.26.0 beta Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language features!,HOORAY,2018-04-05T00:55:55Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T20:59:32Z,Latrasis,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:01:31Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:02:01Z,bvinc,brainn@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:11:40Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:39:31Z,rseymour,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:39:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:46:57Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T21:58:01Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T22:09:31Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T22:11:58Z,RanHum,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-04T22:23:32Z,mammothbane,np@nathanperry.dev https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T00:01:59Z,sunchao,sunchao@apache.org https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T00:10:18Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T00:39:16Z,isislovecruft,isis@patternsinthevoid.net https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T01:35:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T01:35:54Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T03:18:45Z,hdevalence,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T05:45:22Z,jasercion,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T05:49:52Z,est31,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T06:14:16Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T06:22:31Z,emoon,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T06:54:18Z,comex,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T07:17:36Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T08:31:01Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T08:49:04Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T08:56:56Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T09:40:42Z,lqd,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T09:42:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T10:19:28Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T10:22:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_DOWN,2018-04-05T10:30:16Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-05T10:56:43Z,alexshelkov,alexshelkov@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T11:02:27Z,discosultan,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T12:13:14Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T12:32:10Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T14:07:08Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-05T14:07:13Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T17:47:36Z,kaorun343,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-05T19:52:55Z,xd009642,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-07T22:39:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-12T07:36:17Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T09:51:13Z,UtherII,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T10:28:06Z,aheart,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T10:45:47Z,vks,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-17T11:02:13Z,CarlSchwan,carl@carlschwan.eu https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T11:02:16Z,CarlSchwan,carl@carlschwan.eu https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-17T11:02:18Z,CarlSchwan,carl@carlschwan.eu https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T11:27:12Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T11:34:46Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T11:55:00Z,L-as,me@las.rs https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T13:00:53Z,killercup,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T13:29:07Z,TeXitoi,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T13:38:15Z,brendanzab,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-17T14:17:40Z,jinankjain,jinank94@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T14:48:51Z,liranringel,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-17T15:27:30Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T15:37:00Z,ethanpailes,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-17T16:37:04Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-17T16:39:03Z,bluss,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T16:39:04Z,bluss,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T17:27:50Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-17T17:29:30Z,hauleth,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-17T17:59:18Z,sebosp,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T18:31:26Z,demizer,jeezusjr@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T19:49:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T21:06:04Z,literallynotjesus,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-17T23:19:17Z,elmarco,marcandre.lureau@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-17T23:31:53Z,dschaeffer,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T01:54:08Z,nassor,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T02:18:29Z,QuantumGhost,obelisk.reg+git@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T02:51:07Z,SProst,spencer.prost@pnnl.gov https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-18T05:53:24Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T10:27:40Z,dailypips,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T13:21:34Z,skerkour,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-18T18:21:35Z,PallHaraldsson,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-18T22:14:22Z,vbogaevsky,gitvbogaevsky@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-18T22:14:27Z,vbogaevsky,gitvbogaevsky@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-19T12:06:28Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-19T12:06:32Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-04-19T12:06:34Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-19T20:16:04Z,qezz,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-19T21:23:10Z,JesseWright,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-21T07:54:56Z,fuine,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-22T12:34:24Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-24T14:35:08Z,asypost,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-24T23:31:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-25T12:08:06Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-25T12:08:09Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-25T18:58:59Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-26T01:57:34Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-26T04:08:27Z,michael8090,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-04-27T09:25:02Z,dethoter,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-27T09:25:05Z,dethoter,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-04-29T18:16:58Z,behnam,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-05-02T16:28:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-05-10T18:26:10Z,HarrisJT,harris@harrisjt.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-05-10T18:26:13Z,HarrisJT,harris@harrisjt.com https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-06-02T01:08:11Z,AdamNiederer,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-06-09T09:45:53Z,xerz-one,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-06-15T15:00:49Z,kirugan,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-06-22T11:39:19Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-06-22T11:39:20Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HEART,2018-06-22T11:39:30Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-06-22T16:04:51Z,mickaelpham,inbox@mickael.dev https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-07-09T01:09:04Z,pszpetkowski,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,THUMBS_UP,2018-07-09T01:09:07Z,pszpetkowski,NA https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-07-23T13:45:16Z,viluon,hire@viluon.me https://github.com/rust-lang/rust/pull/49664,MERGED,2018-04-04T19:44:12Z,2018-04-17T06:46:43Z,Stabilize x86/x86_64 SIMD,alexcrichton,1217d70465edb2079880347fea4baaac56895f51,14,Separately gate each target_feature feature Use an explicit whitelist for what features are actually stable and can be enabled.,HOORAY,2018-09-10T14:53:09Z,mayurdhaka-suryasoftware,NA https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,THUMBS_UP,2018-04-04T22:43:29Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,HOORAY,2018-04-04T22:43:31Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,HOORAY,2018-04-05T07:15:22Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,THUMBS_UP,2018-04-05T07:15:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,THUMBS_UP,2018-04-05T16:13:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49669,MERGED,2018-04-04T21:39:45Z,2018-04-13T13:09:48Z,Add GlobalAlloc trait + tweaks for initial stabilization,SimonSapin,c5ffdd787d134c06735a1dc4457515a63bbce5f5,1,Initial docs for the GlobalAlloc trait,HOORAY,2018-05-16T21:28:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49673,MERGED,2018-04-05T00:38:56Z,2018-04-09T06:06:02Z,Correct a few stability attributes,ollie27,521e41e77d0c9213ff3ed3f2a5e863b600ce2c3a,5,Correct a few stability attributes,HEART,2018-04-05T22:56:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49678,MERGED,2018-04-05T03:20:00Z,2018-04-07T22:25:07Z,two-phase borrows: support multiple activations in one statement,bobtwinkles,bacd1209575b94f9f2347cebf254bf99ce5ab4bc,2,Add test from #49736 Fixes #49736,HOORAY,2018-04-05T03:52:54Z,est31,NA https://github.com/rust-lang/rust/pull/49678,MERGED,2018-04-05T03:20:00Z,2018-04-07T22:25:07Z,two-phase borrows: support multiple activations in one statement,bobtwinkles,bacd1209575b94f9f2347cebf254bf99ce5ab4bc,2,Add test from #49736 Fixes #49736,HOORAY,2018-04-05T09:13:17Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/49678,MERGED,2018-04-05T03:20:00Z,2018-04-07T22:25:07Z,two-phase borrows: support multiple activations in one statement,bobtwinkles,bacd1209575b94f9f2347cebf254bf99ce5ab4bc,2,Add test from #49736 Fixes #49736,HOORAY,2018-04-06T21:33:23Z,justinmayhew,NA https://github.com/rust-lang/rust/pull/49678,MERGED,2018-04-05T03:20:00Z,2018-04-07T22:25:07Z,two-phase borrows: support multiple activations in one statement,bobtwinkles,bacd1209575b94f9f2347cebf254bf99ce5ab4bc,2,Add test from #49736 Fixes #49736,HOORAY,2018-04-07T00:38:19Z,Osspial,oss@osspial.net https://github.com/rust-lang/rust/pull/49692,MERGED,2018-04-05T15:33:50Z,2018-04-07T17:15:04Z,Fix ICE with `main`'s return type containing lifetimes,sinkuu,40a1ee8efa69ae3cfa2532d047ea62f4ad28b1c1,1,add `failure-status: 1` to the test,HEART,2018-04-05T22:52:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49692,MERGED,2018-04-05T15:33:50Z,2018-04-07T17:15:04Z,Fix ICE with `main`'s return type containing lifetimes,sinkuu,40a1ee8efa69ae3cfa2532d047ea62f4ad28b1c1,1,add `failure-status: 1` to the test,HEART,2018-04-08T14:59:02Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/49697,MERGED,2018-04-05T17:24:18Z,2018-04-05T22:28:05Z,Give a name to every CI job.,kennytm,649f431acfaff1bcaad56f63b19c28499fb75964,4,Give a name to every CI job. Bots that read the log can simply look for `[CI_JOB_NAME=...]` to find out the job's name.,HEART,2018-04-05T17:27:52Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/49697,MERGED,2018-04-05T17:24:18Z,2018-04-05T22:28:05Z,Give a name to every CI job.,kennytm,649f431acfaff1bcaad56f63b19c28499fb75964,4,Give a name to every CI job. Bots that read the log can simply look for `[CI_JOB_NAME=...]` to find out the job's name.,LAUGH,2018-04-05T17:27:55Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/49697,MERGED,2018-04-05T17:24:18Z,2018-04-05T22:28:05Z,Give a name to every CI job.,kennytm,649f431acfaff1bcaad56f63b19c28499fb75964,4,Give a name to every CI job. Bots that read the log can simply look for `[CI_JOB_NAME=...]` to find out the job's name.,THUMBS_UP,2018-04-05T17:27:59Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,THUMBS_DOWN,2018-04-05T19:45:47Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,THUMBS_UP,2018-04-05T20:03:28Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,HEART,2018-04-06T02:31:27Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,HOORAY,2018-04-08T18:25:32Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,THUMBS_UP,2018-04-10T17:14:09Z,vks,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,THUMBS_UP,2018-04-11T00:56:39Z,behnam,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,HOORAY,2018-04-11T00:56:39Z,behnam,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,HEART,2018-04-11T00:56:41Z,behnam,NA https://github.com/rust-lang/rust/pull/49698,MERGED,2018-04-05T17:30:01Z,2018-04-12T02:58:59Z,Merge the std_unicode crate into the core crate,SimonSapin,ef41788cf37074e44f70257508c97efd539a7f29,7,Mark the rest of the `unicode` feature flag as perma-unstable.,HOORAY,2018-04-22T23:36:39Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/49699,MERGED,2018-04-05T17:47:54Z,2018-04-17T19:03:37Z,Removed 'proc' from the reserved keywords list,zesterer,7f58d2ff6621911d25c5e84d32fde53e47494506,1,Removed proc test,THUMBS_UP,2018-04-09T15:05:59Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/49699,MERGED,2018-04-05T17:47:54Z,2018-04-17T19:03:37Z,Removed 'proc' from the reserved keywords list,zesterer,7f58d2ff6621911d25c5e84d32fde53e47494506,1,Removed proc test,THUMBS_UP,2018-04-25T08:27:51Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/49699,MERGED,2018-04-05T17:47:54Z,2018-04-17T19:03:37Z,Removed 'proc' from the reserved keywords list,zesterer,7f58d2ff6621911d25c5e84d32fde53e47494506,1,Removed proc test,THUMBS_UP,2018-04-26T15:47:35Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/49699,MERGED,2018-04-05T17:47:54Z,2018-04-17T19:03:37Z,Removed 'proc' from the reserved keywords list,zesterer,7f58d2ff6621911d25c5e84d32fde53e47494506,1,Removed proc test,THUMBS_UP,2018-05-02T16:30:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49699,MERGED,2018-04-05T17:47:54Z,2018-04-17T19:03:37Z,Removed 'proc' from the reserved keywords list,zesterer,7f58d2ff6621911d25c5e84d32fde53e47494506,1,Removed proc test,THUMBS_UP,2018-05-17T05:03:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49704,MERGED,2018-04-05T18:27:57Z,2018-04-08T03:03:45Z,Fix regression in defaults #49344,leoyvens,933f9ebaae36c15ac917142033ec5f80e066d119,2,Fix #49344,HEART,2018-04-06T00:27:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-06T13:20:25Z,ehuss,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-09T18:48:18Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-22T21:10:54Z,aheart,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-22T21:34:40Z,hcpl,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-22T23:00:17Z,regexident,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T03:23:25Z,dikiaap,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T04:19:36Z,ava57r,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T04:44:31Z,tirkarthi,tir.karthi@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T06:28:19Z,avjinder,avisekhon@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T08:47:26Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T10:47:18Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,HOORAY,2018-04-23T10:47:21Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T13:01:30Z,DesWurstes,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-23T19:35:28Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-24T08:15:21Z,isaacg1,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-24T21:26:23Z,orium,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-04-27T20:09:42Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-05-09T21:39:20Z,b-jonas0,ambrus@math.bme.hu https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-05-14T22:27:26Z,alfonso-higuera,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,HOORAY,2018-06-09T09:47:47Z,xerz-one,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,HOORAY,2018-06-25T17:24:57Z,turboladen,steve.loveless@gmail.com https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-06-27T09:13:28Z,AdamRzepka,NA https://github.com/rust-lang/rust/pull/49707,MERGED,2018-04-05T18:51:21Z,2018-04-27T12:13:28Z,"Add ""the Rustc book""",steveklabnik,36475d947b4c39ec9dcaad137d51019c8b861918,1,more nits,THUMBS_UP,2018-07-29T01:24:30Z,Oliver2213,NA https://github.com/rust-lang/rust/pull/49711,MERGED,2018-04-05T20:00:54Z,2018-05-09T19:17:40Z,Refactor auto trait handling in librustdoc to be accessible from librustc.,ibabushkin,890139256c341c54779ba229942b4d90771a7690,1,Updated comments in auto trait machinery.,THUMBS_UP,2018-04-21T23:50:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/49715,MERGED,2018-04-05T22:00:55Z,2018-04-11T06:04:01Z,Move deny(warnings) into rustbuild,Mark-Simulacrum,53718d2ef1729c987531dc94971c905815daef55,2,Allow incorrectly reported unused attribute warning,THUMBS_UP,2018-04-05T22:18:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/49715,MERGED,2018-04-05T22:00:55Z,2018-04-11T06:04:01Z,Move deny(warnings) into rustbuild,Mark-Simulacrum,53718d2ef1729c987531dc94971c905815daef55,2,Allow incorrectly reported unused attribute warning,THUMBS_UP,2018-04-05T22:36:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/49715,MERGED,2018-04-05T22:00:55Z,2018-04-11T06:04:01Z,Move deny(warnings) into rustbuild,Mark-Simulacrum,53718d2ef1729c987531dc94971c905815daef55,2,Allow incorrectly reported unused attribute warning,THUMBS_UP,2018-04-05T23:21:45Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/49715,MERGED,2018-04-05T22:00:55Z,2018-04-11T06:04:01Z,Move deny(warnings) into rustbuild,Mark-Simulacrum,53718d2ef1729c987531dc94971c905815daef55,2,Allow incorrectly reported unused attribute warning,THUMBS_UP,2018-04-06T19:58:44Z,kennytm,NA https://github.com/rust-lang/rust/pull/49715,MERGED,2018-04-05T22:00:55Z,2018-04-11T06:04:01Z,Move deny(warnings) into rustbuild,Mark-Simulacrum,53718d2ef1729c987531dc94971c905815daef55,2,Allow incorrectly reported unused attribute warning,THUMBS_UP,2018-04-07T03:25:37Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/49718,MERGED,2018-04-06T00:42:31Z,2018-04-13T04:34:19Z,Hygiene 2.0: Avoid comparing fields by name,petrochenkov,fcf48520a0d63828190217ea59849f9098177427,8,Add some new tests + Fix failing tests,THUMBS_UP,2019-05-09T21:16:19Z,jseyfried,NA https://github.com/rust-lang/rust/pull/49719,MERGED,2018-04-06T00:55:36Z,2018-04-16T02:34:42Z,Update `?` repetition disambiguation.,mark-i-m,54bba4c45648b02b92dcec74f4230bfa02846d5e,2,fix test,THUMBS_UP,2018-04-06T00:57:15Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-04-10T13:52:59Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-05-02T17:12:44Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-05-02T20:37:24Z,archshift,gh@archshift.com https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-05-03T11:30:55Z,frol,NA https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-05-03T16:23:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49727,MERGED,2018-04-06T13:16:36Z,2018-04-24T08:33:05Z,Add Cell::update,NA,NA,NA,NA,HEART,2018-05-03T17:02:21Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-04-06T17:37:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-04-06T20:37:20Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-05-07T16:18:18Z,DSpeckhals,NA https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-05-10T12:32:06Z,iAmao,inumidun.amao@gmail.com https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-05-10T13:32:11Z,esirK,esirkings@gmail.com https://github.com/rust-lang/rust/pull/49729,MERGED,2018-04-06T14:09:52Z,2018-05-10T04:43:04Z,./x.py test should be able to run individual tests,collin5,2f8c2a93bf5277774d93f690d1b03fe3e1a7b43f,1,ignore test-args if user specifies suite_path,HOORAY,2018-05-16T20:37:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49732,MERGED,2018-04-06T14:41:09Z,2018-04-26T08:51:50Z,Make incremental compilation thread-safe,Zoxc,3f802ee801bfde83084a4979cd85274ed963f316,2,Move the Lock into OpenTask,HOORAY,2018-04-06T18:04:38Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/49732,MERGED,2018-04-06T14:41:09Z,2018-04-26T08:51:50Z,Make incremental compilation thread-safe,Zoxc,3f802ee801bfde83084a4979cd85274ed963f316,2,Move the Lock into OpenTask,HOORAY,2018-05-03T15:57:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49734,MERGED,2018-04-06T14:45:42Z,2018-04-12T00:35:50Z,proc_macro: Generalize `FromIterator` impl,alexcrichton,d985344b933f2ccc07602fdf86fda94bc3e643cf,1,proc_macro: Generalize `FromIterator` impl While never intended to be stable we forgot that trait impls are insta-stable! This construction of `FromIterator` wasn't our first choice of how to stabilize the impl but our hands are tied at this point so revert back to the original definition of `FromIterator` before #49597 Closes #49725,THUMBS_UP,2018-04-10T14:44:00Z,rail44,amemiya@protonmail.com https://github.com/rust-lang/rust/pull/49734,MERGED,2018-04-06T14:45:42Z,2018-04-12T00:35:50Z,proc_macro: Generalize `FromIterator` impl,alexcrichton,d985344b933f2ccc07602fdf86fda94bc3e643cf,1,proc_macro: Generalize `FromIterator` impl While never intended to be stable we forgot that trait impls are insta-stable! This construction of `FromIterator` wasn't our first choice of how to stabilize the impl but our hands are tied at this point so revert back to the original definition of `FromIterator` before #49597 Closes #49725,THUMBS_UP,2018-04-13T22:46:04Z,anxiousmodernman,coleman.mcfarland@gmail.com https://github.com/rust-lang/rust/pull/49748,MERGED,2018-04-06T22:22:32Z,2018-04-07T11:59:02Z,proc_macro: Improve Debug representations,alexcrichton,52766b57477002583b0a72c917a172c082cb4a36,1,Print proc_macro spans as a half-open range A span covering a single byte such as for an operator `+` token should print as e.g. `80..81` rather than `80...81`. The lo end of the range is inclusive and the hi end is exclusive.,THUMBS_UP,2018-04-11T16:57:23Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/49755,CLOSED,2018-04-07T10:59:47Z,2018-05-21T10:45:47Z,[WIP] add check if lints belong to an external macro,Dylan-DPC-zz,NA,NA,NA,HOORAY,2018-04-09T08:55:58Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/49757,MERGED,2018-04-07T12:04:38Z,2018-04-22T06:03:29Z,Add specific never search,GuillaumeGomez,1ed3e77b8a254fd9cbf8f922d1f910d375a9d1e4,2,Add doc about doc alias feature,THUMBS_UP,2018-04-07T18:56:05Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/49757,MERGED,2018-04-07T12:04:38Z,2018-04-22T06:03:29Z,Add specific never search,GuillaumeGomez,1ed3e77b8a254fd9cbf8f922d1f910d375a9d1e4,2,Add doc about doc alias feature,THUMBS_UP,2018-04-22T09:58:04Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/49757,MERGED,2018-04-07T12:04:38Z,2018-04-22T06:03:29Z,Add specific never search,GuillaumeGomez,1ed3e77b8a254fd9cbf8f922d1f910d375a9d1e4,2,Add doc about doc alias feature,HOORAY,2018-04-25T12:04:22Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49771,MERGED,2018-04-08T02:33:02Z,2018-04-08T21:41:01Z,Don't default to stage 1 with incremental,tamird,b204b498c5ff41a49cd36cb225056e4bf2466ea1,1,Don't default to stage 1 with incremental Closes #43177.,THUMBS_UP,2018-04-09T08:37:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/49789,MERGED,2018-04-08T16:06:19Z,2018-05-01T19:14:41Z,Module experiments: Add one more prelude layer for extern crate names passed with `--extern`,petrochenkov,c1492fe3039d014809960f91b2a95fe30e5d6b9c,13,Add one more prelude layer for extern crate names passed with `--extern`,HOORAY,2018-04-08T18:07:05Z,cramertj,NA https://github.com/rust-lang/rust/pull/49789,MERGED,2018-04-08T16:06:19Z,2018-05-01T19:14:41Z,Module experiments: Add one more prelude layer for extern crate names passed with `--extern`,petrochenkov,c1492fe3039d014809960f91b2a95fe30e5d6b9c,13,Add one more prelude layer for extern crate names passed with `--extern`,HOORAY,2018-04-10T16:23:48Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49789,MERGED,2018-04-08T16:06:19Z,2018-05-01T19:14:41Z,Module experiments: Add one more prelude layer for extern crate names passed with `--extern`,petrochenkov,c1492fe3039d014809960f91b2a95fe30e5d6b9c,13,Add one more prelude layer for extern crate names passed with `--extern`,HOORAY,2018-04-18T18:38:42Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/49805,MERGED,2018-04-09T09:56:53Z,2018-04-09T13:39:03Z,Update Rustfmt,nrc,7e297ff96a921f225c1f7e8c8a012055f6e606a2,2,Update Rustfmt,HOORAY,2018-04-11T00:41:33Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/49826,MERGED,2018-04-10T00:37:54Z,2018-04-28T08:53:22Z,rustc_driver: Catch ICEs on the main thread too,cuviper,64bcbca81b25a8c7192ffa5a16c824c59aa2b0a2,1,rustc_driver: Catch ICEs on the main thread too,THUMBS_UP,2018-04-10T00:39:54Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/49826,MERGED,2018-04-10T00:37:54Z,2018-04-28T08:53:22Z,rustc_driver: Catch ICEs on the main thread too,cuviper,64bcbca81b25a8c7192ffa5a16c824c59aa2b0a2,1,rustc_driver: Catch ICEs on the main thread too,THUMBS_UP,2018-04-12T16:30:29Z,estebank,NA https://github.com/rust-lang/rust/pull/49826,MERGED,2018-04-10T00:37:54Z,2018-04-28T08:53:22Z,rustc_driver: Catch ICEs on the main thread too,cuviper,64bcbca81b25a8c7192ffa5a16c824c59aa2b0a2,1,rustc_driver: Catch ICEs on the main thread too,THUMBS_UP,2018-05-03T16:22:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49856,MERGED,2018-04-10T21:32:27Z,2018-04-12T00:35:56Z,Do not uppercase-lint #[no_mangle] statics,varkor,6e0089ea7776eea84fb26690b590074710247146,2,Do not uppercase-lint no_mangle statics,HEART,2018-04-11T09:11:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_UP,2018-04-11T10:15:58Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_DOWN,2018-04-11T15:43:33Z,retep998,NA https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_UP,2018-04-13T18:02:51Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_DOWN,2018-05-29T21:59:06Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_UP,2018-06-26T20:03:18Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/49868,CLOSED,2018-04-11T10:12:23Z,2018-07-13T17:16:30Z,Implement `Display` for `Path` and `PathBuf`,withoutboats,NA,NA,NA,THUMBS_UP,2020-04-15T14:43:17Z,al42and,al42and@gmail.com https://github.com/rust-lang/rust/pull/49870,MERGED,2018-04-11T10:38:08Z,2018-05-04T17:44:53Z,Immutably and implicitly borrow all pattern ids for their guards (NLL only),pnkfelix,930e76e2af5c1ba9f91240da5de20049b52e739c,1,Update mir-opt test to reflect change to MIR code-generation.,HEART,2018-04-21T21:27:43Z,arielb1,NA https://github.com/rust-lang/rust/pull/49870,MERGED,2018-04-11T10:38:08Z,2018-05-04T17:44:53Z,Immutably and implicitly borrow all pattern ids for their guards (NLL only),pnkfelix,930e76e2af5c1ba9f91240da5de20049b52e739c,1,Update mir-opt test to reflect change to MIR code-generation.,HEART,2018-05-10T03:41:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49870,MERGED,2018-04-11T10:38:08Z,2018-05-04T17:44:53Z,Immutably and implicitly borrow all pattern ids for their guards (NLL only),pnkfelix,930e76e2af5c1ba9f91240da5de20049b52e739c,1,Update mir-opt test to reflect change to MIR code-generation.,HEART,2018-07-25T16:09:02Z,norcalli,NA https://github.com/rust-lang/rust/pull/49878,MERGED,2018-04-11T13:43:48Z,2018-11-29T22:15:13Z,libcore: Add VaList and variadic arg handling intrinsics,dlrobertson,e9e084f5fa8820aca67e5cf0ec301e52bbae1028,3,test: Add basic test for VaList,HOORAY,2018-12-05T23:40:23Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/49878,MERGED,2018-04-11T13:43:48Z,2018-11-29T22:15:13Z,libcore: Add VaList and variadic arg handling intrinsics,dlrobertson,e9e084f5fa8820aca67e5cf0ec301e52bbae1028,3,test: Add basic test for VaList,HOORAY,2018-12-08T03:34:11Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/49878,MERGED,2018-04-11T13:43:48Z,2018-11-29T22:15:13Z,libcore: Add VaList and variadic arg handling intrinsics,dlrobertson,e9e084f5fa8820aca67e5cf0ec301e52bbae1028,3,test: Add basic test for VaList,HOORAY,2019-12-28T14:52:38Z,proninyaroslav,proninyaroslav@mail.ru https://github.com/rust-lang/rust/pull/49880,MERGED,2018-04-11T15:09:39Z,2018-04-15T01:26:06Z,[beta] [incremental] Hash `Allocation`s,oli-obk,a6102fb9761b5b7443c8e51897c0aebf172b8924,4,[incremental] Hash `Allocation`s,HEART,2018-04-11T15:13:55Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-12T08:29:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-12T14:03:17Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-12T14:03:20Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-12T16:31:59Z,estebank,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-14T01:05:09Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-14T01:05:10Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-14T07:32:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-15T18:00:19Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HEART,2018-04-21T18:12:02Z,bluss,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-25T02:40:01Z,hcpl,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-25T04:50:11Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-25T08:58:40Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-04-25T11:52:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49896,MERGED,2018-04-12T07:58:08Z,2018-04-22T02:18:51Z,Add inherent methods in libcore for [T] [u8] str f32 and f64,SimonSapin,70fdd1b5c0f6a0673fcf924b3d8880af034bdee0,8,Make the unstable StrExt and SliceExt traits private to libcore in not(stage0) `Float` still needs to be public for libcore unit tests.,HOORAY,2018-05-02T16:19:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49904,MERGED,2018-04-12T13:17:41Z,2018-04-17T21:57:06Z,Work around LLVM debuginfo problem in librustc_driver.,michaelwoerister,281492898be7fd6b9705a818d2c880e9d7fd2da0,1,Clean up attribute handling in create_function_debug_context().,THUMBS_UP,2018-04-12T14:10:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/49911,MERGED,2018-04-12T19:32:40Z,2018-04-24T12:56:35Z,Don't allow #[should_panic] with non-() tests,rcoh,14e5e0e9c9f01e29cd1e8d7da10e85b655288b2e,4,Don't allow #[should_panic] with non-() tests,HEART,2018-04-12T20:48:31Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/49911,MERGED,2018-04-12T19:32:40Z,2018-04-24T12:56:35Z,Don't allow #[should_panic] with non-() tests,rcoh,14e5e0e9c9f01e29cd1e8d7da10e85b655288b2e,4,Don't allow #[should_panic] with non-() tests,HEART,2018-04-13T13:02:47Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/49911,MERGED,2018-04-12T19:32:40Z,2018-04-24T12:56:35Z,Don't allow #[should_panic] with non-() tests,rcoh,14e5e0e9c9f01e29cd1e8d7da10e85b655288b2e,4,Don't allow #[should_panic] with non-() tests,HOORAY,2018-04-14T07:30:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49948,CLOSED,2018-04-13T16:00:33Z,2018-04-21T00:10:20Z,[beta] ICE fixes for newly stabilized features,sinkuu,NA,NA,NA,HEART,2018-04-15T08:36:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49954,MERGED,2018-04-13T20:54:44Z,2018-04-22T13:24:10Z,Add rustdoc settings menu,GuillaumeGomez,1f7892f16a83af3d96dc815c7a688f4cb541c600,2,Remove link generation on image favicon and logo in settings,HOORAY,2018-04-13T20:59:11Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/49959,MERGED,2018-04-14T00:03:37Z,2018-04-16T23:20:04Z,rustbuild: allow building tools with debuginfo,cuviper,93734e9c46e30acc9a51f19c56511ce8516b6855,1,Make debuginfo-tools always default false,HEART,2018-04-14T10:24:01Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49962,CLOSED,2018-04-14T11:21:28Z,2018-04-16T15:13:01Z,change OpenOptions to Self in std::os::windows::fs,csmoe,NA,NA,NA,THUMBS_UP,2018-04-15T04:45:34Z,pitdicker,NA https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-04-17T03:48:38Z,tmandry,NA https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-04-18T03:40:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-04-18T18:44:21Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-04-22T06:26:20Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-04-30T05:34:11Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-05-03T16:19:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/49968,MERGED,2018-04-14T19:25:59Z,2018-04-27T23:31:56Z,Stabilize dyn trait,pvdrz,b5c7cbf2f288967f55f8155a1ded7379ee4161f0,1,rustdoc asks for dyn_trait feature in stage0,HOORAY,2018-05-03T20:56:45Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49985,MERGED,2018-04-15T18:25:28Z,2018-04-24T08:33:14Z,don't see issue #0,zackmdavis,e77110e1f61e42c0f0e9e3288edb0d663eb39bba,3,"don't see issue #0 The unstable-feature attribute requires an issue (neglecting it is E0547) which gets used in the error messages. Unfortunately there are some cases where ""0"" is apparently used a placeholder where no issue exists directing the user to see the (nonexistent) issue #0. (It would have been better to either let `issue` be optional—compare to how issue is an `Option` in the feature-gate declarations in libsyntax/feature-gate.rs—or actually require that an issue be created.) Rather than endeavoring to change how `#[unstable]` works at this time (given competing contributor and reviewer priorities) this simple patch proposes the less-ambitious solution of just not adding the ""(see issue)"" note when the number is zero. Resolves #49983.",LAUGH,2018-04-16T09:27:30Z,kennytm,NA https://github.com/rust-lang/rust/pull/49985,MERGED,2018-04-15T18:25:28Z,2018-04-24T08:33:14Z,don't see issue #0,zackmdavis,e77110e1f61e42c0f0e9e3288edb0d663eb39bba,3,"don't see issue #0 The unstable-feature attribute requires an issue (neglecting it is E0547) which gets used in the error messages. Unfortunately there are some cases where ""0"" is apparently used a placeholder where no issue exists directing the user to see the (nonexistent) issue #0. (It would have been better to either let `issue` be optional—compare to how issue is an `Option` in the feature-gate declarations in libsyntax/feature-gate.rs—or actually require that an issue be created.) Rather than endeavoring to change how `#[unstable]` works at this time (given competing contributor and reviewer priorities) this simple patch proposes the less-ambitious solution of just not adding the ""(see issue)"" note when the number is zero. Resolves #49983.",THUMBS_UP,2018-04-16T14:59:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/49988,MERGED,2018-04-15T21:07:37Z,2018-05-09T15:44:31Z,Mention Result in never docs.,clarfonthey,fc6d6c98dedca297c09016615011bee448e5e468,1,Fixed typos,THUMBS_UP,2018-04-17T14:13:49Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/49988,MERGED,2018-04-15T21:07:37Z,2018-05-09T15:44:31Z,Mention Result in never docs.,clarfonthey,fc6d6c98dedca297c09016615011bee448e5e468,1,Fixed typos,THUMBS_UP,2018-05-16T09:17:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49989,CLOSED,2018-04-15T21:52:50Z,2018-05-14T09:42:03Z,in which we check for confusable Unicodepoints in float literal exponent,zackmdavis,NA,NA,NA,THUMBS_UP,2018-04-20T04:33:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/49991,MERGED,2018-04-16T02:25:58Z,2018-04-20T10:40:42Z,Remove HIR inlining,wesleywiser,4a77d35c1ed89310a0ed128ce931cd4b85ca4cd4,15,Remove HIR inlining Fixes #49690,HOORAY,2018-04-17T08:23:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/49991,MERGED,2018-04-16T02:25:58Z,2018-04-20T10:40:42Z,Remove HIR inlining,wesleywiser,4a77d35c1ed89310a0ed128ce931cd4b85ca4cd4,15,Remove HIR inlining Fixes #49690,HOORAY,2018-04-25T09:58:47Z,RalfJung,NA https://github.com/rust-lang/rust/pull/49991,MERGED,2018-04-16T02:25:58Z,2018-04-20T10:40:42Z,Remove HIR inlining,wesleywiser,4a77d35c1ed89310a0ed128ce931cd4b85ca4cd4,15,Remove HIR inlining Fixes #49690,HOORAY,2018-04-25T11:45:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/49993,MERGED,2018-04-16T06:44:24Z,2018-04-18T17:06:43Z,Change the hashcounts in raw `Lit` variants from usize to u16.,nnethercote,4d34bfd00a57f8a8bdb60ec3f908c5d4256f8a9a,7,Change the hashcounts in raw `Lit` variants from usize to u16. This reduces the size of `Token` from 32 bytes to 24 bytes on 64-bit platforms.,THUMBS_UP,2018-04-16T19:33:04Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T14:59:29Z,lqd,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T15:17:20Z,kennytm,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T15:22:54Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T15:29:43Z,CryZe,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T15:40:54Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T16:58:07Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-16T19:34:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-17T03:46:31Z,tmandry,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-17T17:17:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-04-18T14:56:14Z,hban,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-05-09T17:10:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50000,MERGED,2018-04-16T14:34:00Z,2018-05-07T11:09:25Z,Add some groundwork for cross-language LTO.,michaelwoerister,0bf26bf9519025e2c89d1d51ba8c7fe52351675f,1,Fix Mac OS section name for LLVM bitcode.,HOORAY,2018-05-09T20:27:42Z,RanHum,NA https://github.com/rust-lang/rust/pull/50010,MERGED,2018-04-16T22:00:35Z,2018-05-11T02:03:32Z,Give SliceIndex impls a test suite of girth befitting the implementation,ExpHP,f1d7b453fed6acefc68f90752922b37c6e3ac7a4,1,revise test gen macro for str,HEART,2018-05-06T22:26:02Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/50011,MERGED,2018-04-16T22:35:28Z,2018-05-15T05:39:45Z,Ensure derive(PartialOrd) is no longer accidentally exponential,varkor,6805e5abd2a6fbdca75ff3c96ee58398dcbdfd04,1,Update comments to UFCS style,THUMBS_UP,2018-04-17T00:39:14Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/50011,MERGED,2018-04-16T22:35:28Z,2018-05-15T05:39:45Z,Ensure derive(PartialOrd) is no longer accidentally exponential,varkor,6805e5abd2a6fbdca75ff3c96ee58398dcbdfd04,1,Update comments to UFCS style,THUMBS_UP,2018-04-18T10:56:42Z,kennytm,NA https://github.com/rust-lang/rust/pull/50011,MERGED,2018-04-16T22:35:28Z,2018-05-15T05:39:45Z,Ensure derive(PartialOrd) is no longer accidentally exponential,varkor,6805e5abd2a6fbdca75ff3c96ee58398dcbdfd04,1,Update comments to UFCS style,HEART,2018-04-18T14:07:10Z,RalfJung,NA https://github.com/rust-lang/rust/pull/50014,CLOSED,2018-04-17T02:11:38Z,2018-05-02T21:15:05Z,Desugar `fn(&mut self)` to `fn(mut self: &mut self)`,estebank,NA,NA,NA,CONFUSED,2018-04-17T09:28:58Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/50014,CLOSED,2018-04-17T02:11:38Z,2018-05-02T21:15:05Z,Desugar `fn(&mut self)` to `fn(mut self: &mut self)`,estebank,NA,NA,NA,CONFUSED,2018-04-17T18:15:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/50014,CLOSED,2018-04-17T02:11:38Z,2018-05-02T21:15:05Z,Desugar `fn(&mut self)` to `fn(mut self: &mut self)`,estebank,NA,NA,NA,CONFUSED,2018-04-27T20:46:37Z,jseyfried,NA https://github.com/rust-lang/rust/pull/50016,MERGED,2018-04-17T03:43:05Z,2018-04-25T23:25:59Z,Make Binder's field private and clean up its usage,tmandry,9ffe9bea53ac6dfb1bc1b23b22fbe1c5fafcfe8c,5,Remove methods with implicit Binder::skip_bound Fixes #20664.,LAUGH,2018-04-17T23:45:58Z,kennytm,NA https://github.com/rust-lang/rust/pull/50017,MERGED,2018-04-17T05:13:30Z,2018-04-18T22:30:16Z,stabilize a bunch of minor api additions,tinaun,fd042eee0002bc2640447c08034de00171ca1aa3,1,stabilize `hash_map_remove_entry` feature,HEART,2018-04-19T07:46:24Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/50017,MERGED,2018-04-17T05:13:30Z,2018-04-18T22:30:16Z,stabilize a bunch of minor api additions,tinaun,fd042eee0002bc2640447c08034de00171ca1aa3,1,stabilize `hash_map_remove_entry` feature,HEART,2018-04-20T17:25:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50017,MERGED,2018-04-17T05:13:30Z,2018-04-18T22:30:16Z,stabilize a bunch of minor api additions,tinaun,fd042eee0002bc2640447c08034de00171ca1aa3,1,stabilize `hash_map_remove_entry` feature,HEART,2018-04-25T12:02:55Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50020,MERGED,2018-04-17T07:13:58Z,2018-04-19T19:36:07Z,Update clippy,oli-obk,0f1f9a79f29e3033e4cd8774c4b2d59a413e43b2,2,Update clippy,HEART,2018-04-17T08:21:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50026,CLOSED,2018-04-17T13:46:37Z,2018-04-17T17:33:05Z,[beta] Turing complete const eval,oli-obk,NA,NA,NA,HOORAY,2018-04-17T17:15:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50027,MERGED,2018-04-17T13:56:29Z,2018-04-19T22:14:32Z,[beta] backport various PRs,oli-obk,0f4bb2fc8c222e467386591513a5a50f8ed8a3ed,5,Rollup merge of #50046 - michaelwoerister:backport-no-debug r=alexcrichton Backport of #49904 See #49904.,THUMBS_UP,2018-04-18T07:21:23Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50030,MERGED,2018-04-17T15:12:45Z,2018-05-03T14:17:21Z,Implement tool_attributes feature (RFC 2103),flip1995,84f450866041e0269875acb1350920308cdc109f,4,fix tests,HOORAY,2018-05-04T23:21:33Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-04-18T08:06:16Z,krk,keremkat@gmail.com https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,HOORAY,2018-04-18T17:37:59Z,jcarres-mdsol,jcarres@mdsol.com https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,HOORAY,2018-04-18T21:01:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-04-18T21:01:15Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,HOORAY,2018-04-19T12:04:47Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-04-19T12:10:16Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-04-20T07:55:56Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50044,CLOSED,2018-04-18T07:46:17Z,2018-05-21T10:53:16Z,Add Polly support,DiamondLovesYou,NA,NA,NA,HOORAY,2018-04-20T14:20:54Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50045,MERGED,2018-04-18T07:52:56Z,2018-05-16T17:05:36Z,Implement label break value (RFC 2046),est31,ae1553aa027c395a93426dc0fe0abd4ec6af2291,2,Address review comments,HOORAY,2018-04-19T02:14:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50045,MERGED,2018-04-18T07:52:56Z,2018-05-16T17:05:36Z,Implement label break value (RFC 2046),est31,ae1553aa027c395a93426dc0fe0abd4ec6af2291,2,Address review comments,HOORAY,2018-05-12T09:58:33Z,varkor,NA https://github.com/rust-lang/rust/pull/50045,MERGED,2018-04-18T07:52:56Z,2018-05-16T17:05:36Z,Implement label break value (RFC 2046),est31,ae1553aa027c395a93426dc0fe0abd4ec6af2291,2,Address review comments,HOORAY,2021-08-02T11:36:36Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/50051,MERGED,2018-04-18T12:02:39Z,2018-04-20T03:59:20Z,Lazily evaluate EvalErrorKind::*.into() calls.,nnethercote,5070dea2366104fb0b5c344ce7f2a5cf8af176b0,1,"Lazily evaluate EvalErrorKind::*.into() calls. eval_context.rs calls `ok_or` in multiple places with an eagerly evaluated `EvalErrorKind::*.into()` argument which calls EvalError::from() which calls env::var(""MIRI_BACKTRACE"") which allocates a String. This code is hot enough for this to have a measurable effect on some benchmarks. This patch changes the `ok_or` calls into `ok_or_else` thus avoiding the evaluations when they're not needed. As a result most of the rustc-perf benchmarks get a measurable speedup particularly the shorter-running ones where the improvement is as high as 6%.",HOORAY,2018-04-30T08:46:38Z,dbrgn,NA https://github.com/rust-lang/rust/pull/50051,MERGED,2018-04-18T12:02:39Z,2018-04-20T03:59:20Z,Lazily evaluate EvalErrorKind::*.into() calls.,nnethercote,5070dea2366104fb0b5c344ce7f2a5cf8af176b0,1,"Lazily evaluate EvalErrorKind::*.into() calls. eval_context.rs calls `ok_or` in multiple places with an eagerly evaluated `EvalErrorKind::*.into()` argument which calls EvalError::from() which calls env::var(""MIRI_BACKTRACE"") which allocates a String. This code is hot enough for this to have a measurable effect on some benchmarks. This patch changes the `ok_or` calls into `ok_or_else` thus avoiding the evaluations when they're not needed. As a result most of the rustc-perf benchmarks get a measurable speedup particularly the shorter-running ones where the improvement is as high as 6%.",THUMBS_UP,2018-05-02T16:26:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50051,MERGED,2018-04-18T12:02:39Z,2018-04-20T03:59:20Z,Lazily evaluate EvalErrorKind::*.into() calls.,nnethercote,5070dea2366104fb0b5c344ce7f2a5cf8af176b0,1,"Lazily evaluate EvalErrorKind::*.into() calls. eval_context.rs calls `ok_or` in multiple places with an eagerly evaluated `EvalErrorKind::*.into()` argument which calls EvalError::from() which calls env::var(""MIRI_BACKTRACE"") which allocates a String. This code is hot enough for this to have a measurable effect on some benchmarks. This patch changes the `ok_or` calls into `ok_or_else` thus avoiding the evaluations when they're not needed. As a result most of the rustc-perf benchmarks get a measurable speedup particularly the shorter-running ones where the improvement is as high as 6%.",HOORAY,2018-06-02T16:45:44Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50051,MERGED,2018-04-18T12:02:39Z,2018-04-20T03:59:20Z,Lazily evaluate EvalErrorKind::*.into() calls.,nnethercote,5070dea2366104fb0b5c344ce7f2a5cf8af176b0,1,"Lazily evaluate EvalErrorKind::*.into() calls. eval_context.rs calls `ok_or` in multiple places with an eagerly evaluated `EvalErrorKind::*.into()` argument which calls EvalError::from() which calls env::var(""MIRI_BACKTRACE"") which allocates a String. This code is hot enough for this to have a measurable effect on some benchmarks. This patch changes the `ok_or` calls into `ok_or_else` thus avoiding the evaluations when they're not needed. As a result most of the rustc-perf benchmarks get a measurable speedup particularly the shorter-running ones where the improvement is as high as 6%.",HOORAY,2018-06-07T12:28:10Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-18T12:48:37Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-18T14:58:56Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-19T02:13:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-19T10:54:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-19T11:48:42Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-19T18:50:54Z,mcarton,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-20T04:23:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-24T21:53:41Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-25T18:59:12Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-04-27T12:09:32Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/50052,MERGED,2018-04-18T12:07:04Z,2018-04-20T12:53:06Z,Avoid allocating when parsing \u{...} literals.,nnethercote,9f145022ef9390e6cfb0b2416744a393d62d3350,1,Avoid allocating when parsing \u{...} literals. `char_lit` uses an allocation in order to ignore '_' chars in \u{...} literals. This patch changes it to not do that by processing the chars more directly. This improves various rustc-perf benchmark measurements by up to 6% particularly regex futures clap coercions hyper and encoding.,HEART,2018-05-02T16:26:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50072,MERGED,2018-04-19T11:19:24Z,2018-04-26T11:07:28Z,Allow variant discriminant initializers to refer to other initializer…,oli-obk,195c9f47e9d92ceb110fdcb31056fe9f6780171c,6,Allow variant discriminant initializers to refer to other initializers of the same enum,THUMBS_UP,2018-04-19T16:42:55Z,durka,NA https://github.com/rust-lang/rust/pull/50079,MERGED,2018-04-19T20:22:39Z,2018-04-24T16:32:42Z,Android abstract unix domain sockets AddressKind correction,NickAtAccuPS,da6142c81057342d8d6686ae4078995aab73b5bc,1,Rustfmt result (for relevant changes) to satisfy Travis line length check. Signed-off-by: Nicholas Rishel ,THUMBS_UP,2018-04-19T22:01:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50080,MERGED,2018-04-19T21:36:45Z,2018-04-21T07:42:27Z,add --edition option,klnusbaum,c8c9bf97e3ed2eab3ed60a3412574e7c5b548eab,2,fix two compile-fail tests that were still using -Zedition,HOORAY,2018-04-20T04:18:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50083,MERGED,2018-04-19T21:55:01Z,2018-04-20T19:03:28Z,wasm: Increase default stack size to 1MB,alexcrichton,e58629b990ee8ca2dc8fde0703fc7ca2b4b2a809,1,"wasm: Increase default stack size to 1MB This commit increases the dfeault stack size allocated to the wasm32-unknown-unknown target to 1MB by default. Currently the default stack size is one wasm page or 64 kilobytes. This default stack is quite small and has caused a stack overflow or two in the wild by accident. The current ""best practice"" for fixing this is to pass `-Clink-args='-z stack-size=$bigger'` but that's not great nor always easy to do. A default of 1MB matches more closely with other platforms where it's ""pretty big"" by default. Note that it was tested and if the users uses `-C link-args` to pass a custom stack size that's still resepected as lld seems to take the first argument and where rustc is passing it will always be last.",HEART,2018-04-19T21:55:38Z,fitzgen,NA https://github.com/rust-lang/rust/pull/50083,MERGED,2018-04-19T21:55:01Z,2018-04-20T19:03:28Z,wasm: Increase default stack size to 1MB,alexcrichton,e58629b990ee8ca2dc8fde0703fc7ca2b4b2a809,1,"wasm: Increase default stack size to 1MB This commit increases the dfeault stack size allocated to the wasm32-unknown-unknown target to 1MB by default. Currently the default stack size is one wasm page or 64 kilobytes. This default stack is quite small and has caused a stack overflow or two in the wild by accident. The current ""best practice"" for fixing this is to pass `-Clink-args='-z stack-size=$bigger'` but that's not great nor always easy to do. A default of 1MB matches more closely with other platforms where it's ""pretty big"" by default. Note that it was tested and if the users uses `-C link-args` to pass a custom stack size that's still resepected as lld seems to take the first argument and where rustc is passing it will always be last.",THUMBS_UP,2018-04-19T22:03:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50084,MERGED,2018-04-19T22:10:21Z,2018-05-05T01:27:47Z,First step towards rustfix compiletest mode,killercup,6f2d023028bbd666be2c211b923b32faf10a41da,29,Fold rustfix tests back into the UI test suite,HOORAY,2018-04-20T04:17:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50084,MERGED,2018-04-19T22:10:21Z,2018-05-05T01:27:47Z,First step towards rustfix compiletest mode,killercup,6f2d023028bbd666be2c211b923b32faf10a41da,29,Fold rustfix tests back into the UI test suite,HOORAY,2018-04-20T07:25:45Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50084,MERGED,2018-04-19T22:10:21Z,2018-05-05T01:27:47Z,First step towards rustfix compiletest mode,killercup,6f2d023028bbd666be2c211b923b32faf10a41da,29,Fold rustfix tests back into the UI test suite,HOORAY,2018-04-20T07:37:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50084,MERGED,2018-04-19T22:10:21Z,2018-05-05T01:27:47Z,First step towards rustfix compiletest mode,killercup,6f2d023028bbd666be2c211b923b32faf10a41da,29,Fold rustfix tests back into the UI test suite,HOORAY,2018-05-05T10:41:37Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/50100,MERGED,2018-04-20T03:02:59Z,2018-04-25T06:49:02Z,Edition breakage lint for absolute paths starting with modules,Manishearth,2a5ce10dfb20e794d324cb1621e5ac892b7e421a,2,Add test,HOORAY,2018-04-20T04:15:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50106,MERGED,2018-04-20T10:25:46Z,2018-04-25T09:19:24Z,Speed up `nearest_common_ancestor`.,nnethercote,cccd51cd6e8861ba2640834c11fa67f83fa7698f,1,Speed up `nearest_common_ancestor()`. `nearest_common_ancestor()` uses an algorithm that requires computing the full scope chain for both scopes which is expensive because each element involves a hash table lookup and then looking for a common tail. This patch changes `nearest_common_ancestor()` to use a different algorithm which starts at the given scopes and works outwards (i.e. up the scope tree) until a common ancestor is found. This is much faster because in most cases the common ancestor is found well before the end of the scope chains. Also the use of a SmallVec avoids the need for any allocation most of the time.,HOORAY,2018-04-23T02:33:42Z,sinkuu,NA https://github.com/rust-lang/rust/pull/50106,MERGED,2018-04-20T10:25:46Z,2018-04-25T09:19:24Z,Speed up `nearest_common_ancestor`.,nnethercote,cccd51cd6e8861ba2640834c11fa67f83fa7698f,1,Speed up `nearest_common_ancestor()`. `nearest_common_ancestor()` uses an algorithm that requires computing the full scope chain for both scopes which is expensive because each element involves a hash table lookup and then looking for a common tail. This patch changes `nearest_common_ancestor()` to use a different algorithm which starts at the given scopes and works outwards (i.e. up the scope tree) until a common ancestor is found. This is much faster because in most cases the common ancestor is found well before the end of the scope chains. Also the use of a SmallVec avoids the need for any allocation most of the time.,HOORAY,2018-04-25T00:04:42Z,mrhota,NA https://github.com/rust-lang/rust/pull/50109,MERGED,2018-04-20T11:57:16Z,2018-04-22T08:48:54Z,Implement Copy for std::alloc::Layout,SimonSapin,1caaafdce7871bc2816c9f42a14fd9262eda4037,1,Implement Copy for std::alloc::Layout Fixes https://github.com/rust-lang/rust/issues/48458,THUMBS_UP,2018-04-21T00:43:44Z,glandium,NA https://github.com/rust-lang/rust/pull/50110,MERGED,2018-04-20T12:21:58Z,2018-04-25T11:30:01Z,Warn on all erroneous constants,oli-obk,cd6c186e4eb410413522e2be2ef6309edf3d0b32,18,Warn on all erroneous constants,HOORAY,2018-04-25T18:34:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50121,MERGED,2018-04-20T16:13:41Z,2018-04-22T00:01:36Z,Revert stabilization of never_type (!) et al,pnkfelix,42b6d4653a2ad22be695760aba3514fc64c18d66,8,Add back missing `#![feature(never_type)]`s,HEART,2018-04-20T17:55:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/50131,MERGED,2018-04-21T00:29:39Z,2018-04-26T01:57:27Z,Allow crate:: in local paths,Manishearth,9f5e08e0a167d6ce406445a619a8bf358deeade4,4,Fix crate:: in local paths,HOORAY,2018-04-21T00:30:28Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/50137,MERGED,2018-04-21T09:25:51Z,2018-04-27T21:01:58Z,Remove hack around comparisons of i1 values (fixes #40980),nox,5d5fb97b6e8085cb920c1c10a9b298c3c7f2a53d,1,Remove hack around comparisons of i1 values (fixes #40980) The regression test still passes without that 2 years old hack. The underlying LLVM bug has probably been fixed upstream since then.,HOORAY,2018-04-23T05:04:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-21T18:17:56Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-21T19:40:01Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-21T21:24:31Z,fitzgen,NA https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-21T22:41:10Z,glandium,NA https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-22T00:13:21Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-22T13:30:02Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-24T23:48:27Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-25T09:07:27Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-04-25T12:21:38Z,chpio,NA https://github.com/rust-lang/rust/pull/50144,MERGED,2018-04-21T17:02:22Z,2018-04-22T21:51:47Z,Replace {Alloc GlobalAlloc}::oom with a lang item.,sfackler,5969712c3f2163b7ca6f809e0f5e31f73e8898bb,3,Remove unused AllocatorTy::Bang,THUMBS_UP,2018-05-02T16:18:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50148,MERGED,2018-04-21T21:25:06Z,2018-05-09T15:44:34Z,turn `ManuallyDrop::new` into a constant function,japaric,b61a4c20c6acd963070adb083b12d5e21a5843d3,1,make the const constructor unstable,THUMBS_UP,2018-04-22T08:20:03Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50149,MERGED,2018-04-21T22:21:25Z,2018-04-28T06:27:04Z,Added warning for unused arithmetic expressions,aaronaaeng,91aa267eda21be36d7cae43b6809eba63f1aac4c,6,Make must_use lint cover all binary/unary operators,HOORAY,2018-04-21T22:34:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50149,MERGED,2018-04-21T22:21:25Z,2018-04-28T06:27:04Z,Added warning for unused arithmetic expressions,aaronaaeng,91aa267eda21be36d7cae43b6809eba63f1aac4c,6,Make must_use lint cover all binary/unary operators,HOORAY,2018-04-23T20:50:25Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/50149,MERGED,2018-04-21T22:21:25Z,2018-04-28T06:27:04Z,Added warning for unused arithmetic expressions,aaronaaeng,91aa267eda21be36d7cae43b6809eba63f1aac4c,6,Make must_use lint cover all binary/unary operators,HOORAY,2018-04-27T00:00:35Z,estebank,NA https://github.com/rust-lang/rust/pull/50149,MERGED,2018-04-21T22:21:25Z,2018-04-28T06:27:04Z,Added warning for unused arithmetic expressions,aaronaaeng,91aa267eda21be36d7cae43b6809eba63f1aac4c,6,Make must_use lint cover all binary/unary operators,THUMBS_UP,2018-04-28T11:29:38Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50149,MERGED,2018-04-21T22:21:25Z,2018-04-28T06:27:04Z,Added warning for unused arithmetic expressions,aaronaaeng,91aa267eda21be36d7cae43b6809eba63f1aac4c,6,Make must_use lint cover all binary/unary operators,THUMBS_UP,2018-07-10T17:02:34Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/50150,CLOSED,2018-04-21T23:09:53Z,2018-05-07T04:19:26Z,turn `mem::uninitialized` into a constant function,japaric,NA,NA,NA,THUMBS_UP,2018-04-22T08:20:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50161,MERGED,2018-04-22T17:53:37Z,2018-05-12T01:48:13Z,added missing implementation hint,rizakrko,17c56d409ec43f8492b4ffd5117fcee6c4ce0a27,1,resolved merge conflict,THUMBS_UP,2018-05-17T05:02:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-04-23T03:20:29Z,retep998,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-04-23T04:57:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-04-24T09:39:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-04-26T20:56:28Z,Boscop,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-04-30T16:17:45Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-05-21T21:55:10Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-05-22T21:28:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-06-04T18:40:34Z,estebank,NA https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-06-06T14:38:12Z,dodheim,dodheim@gmail.com https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-06-07T15:19:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-07-01T14:53:08Z,dmitmel,dmytro.meleshko@gmail.com https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,THUMBS_UP,2018-08-28T04:13:23Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/50167,MERGED,2018-04-22T19:51:56Z,2018-06-03T00:31:04Z, Add as_nanos function to Duration,fintelia,fc895665c9a6ba9bc0be7844cb7162797b557a34,1,Avoid 128-bit arithmetic where possible,HEART,2018-08-28T04:13:27Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-04-24T16:01:02Z,cramertj,NA https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-05-16T06:02:38Z,davll,NA https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-05-18T11:08:48Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-05-21T00:42:10Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-08-05T08:46:22Z,qnighy,NA https://github.com/rust-lang/rust/pull/50173,CLOSED,2018-04-23T06:16:15Z,2018-09-20T09:41:22Z,Implement object-safety for arbitrary_self_types,mikeyhew,NA,NA,NA,THUMBS_UP,2018-09-04T15:22:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50188,MERGED,2018-04-23T22:19:13Z,2018-04-29T02:26:55Z,Add `-C target-feature` to all functions,alexcrichton,622371153c66f9e371f587205d14040534060c18,3,Add `-C target-feature` to all functions Previously the features specified to LLVM via `-C target-feature` were only reflected in the `TargetMachine` but this change *also* reflects these and the base features inside each function itself. This change matches clang and... Closes rust-lang-nursery/stdsimd#427,THUMBS_UP,2018-04-23T23:32:07Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/50188,MERGED,2018-04-23T22:19:13Z,2018-04-29T02:26:55Z,Add `-C target-feature` to all functions,alexcrichton,622371153c66f9e371f587205d14040534060c18,3,Add `-C target-feature` to all functions Previously the features specified to LLVM via `-C target-feature` were only reflected in the `TargetMachine` but this change *also* reflects these and the base features inside each function itself. This change matches clang and... Closes rust-lang-nursery/stdsimd#427,THUMBS_UP,2018-04-24T21:03:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50188,MERGED,2018-04-23T22:19:13Z,2018-04-29T02:26:55Z,Add `-C target-feature` to all functions,alexcrichton,622371153c66f9e371f587205d14040534060c18,3,Add `-C target-feature` to all functions Previously the features specified to LLVM via `-C target-feature` were only reflected in the `TargetMachine` but this change *also* reflects these and the base features inside each function itself. This change matches clang and... Closes rust-lang-nursery/stdsimd#427,THUMBS_UP,2018-04-28T11:40:23Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/50192,MERGED,2018-04-24T04:01:02Z,2018-04-27T23:32:02Z,Add some utilities to `libsyntax`,bobtwinkles,73e0c1e968caaf7b70d659e58c0a40782c60f8da,3,Fix review nits,THUMBS_UP,2018-04-26T04:46:52Z,jseyfried,NA https://github.com/rust-lang/rust/pull/50192,MERGED,2018-04-24T04:01:02Z,2018-04-27T23:32:02Z,Add some utilities to `libsyntax`,bobtwinkles,73e0c1e968caaf7b70d659e58c0a40782c60f8da,3,Fix review nits,THUMBS_UP,2018-04-26T22:31:08Z,estebank,NA https://github.com/rust-lang/rust/pull/50198,MERGED,2018-04-24T13:55:30Z,2018-05-01T14:23:06Z,Remove some unused code,oli-obk,487f7bc016aeca615ada10fce5bcd7190702bda6,1,Merge adjacent write! invocations,HOORAY,2018-04-24T16:29:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50198,MERGED,2018-04-24T13:55:30Z,2018-05-01T14:23:06Z,Remove some unused code,oli-obk,487f7bc016aeca615ada10fce5bcd7190702bda6,1,Merge adjacent write! invocations,HOORAY,2018-04-26T14:52:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/50198,MERGED,2018-04-24T13:55:30Z,2018-05-01T14:23:06Z,Remove some unused code,oli-obk,487f7bc016aeca615ada10fce5bcd7190702bda6,1,Merge adjacent write! invocations,HOORAY,2018-04-26T23:17:10Z,estebank,NA https://github.com/rust-lang/rust/pull/50204,MERGED,2018-04-24T22:42:51Z,2018-04-30T10:30:31Z,Use enum for approximate suggestions,Manishearth,4e2cd4104a39c1e0562c3fb00085a1a3f4f22291,7,Approximate -> Applicability,HEART,2018-04-29T23:07:26Z,estebank,NA https://github.com/rust-lang/rust/pull/50204,MERGED,2018-04-24T22:42:51Z,2018-04-30T10:30:31Z,Use enum for approximate suggestions,Manishearth,4e2cd4104a39c1e0562c3fb00085a1a3f4f22291,7,Approximate -> Applicability,THUMBS_UP,2018-04-30T01:17:16Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/50204,MERGED,2018-04-24T22:42:51Z,2018-04-30T10:30:31Z,Use enum for approximate suggestions,Manishearth,4e2cd4104a39c1e0562c3fb00085a1a3f4f22291,7,Approximate -> Applicability,THUMBS_UP,2018-05-03T16:09:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50204,MERGED,2018-04-24T22:42:51Z,2018-04-30T10:30:31Z,Use enum for approximate suggestions,Manishearth,4e2cd4104a39c1e0562c3fb00085a1a3f4f22291,7,Approximate -> Applicability,HEART,2018-05-13T22:36:15Z,mcarton,NA https://github.com/rust-lang/rust/pull/50228,MERGED,2018-04-25T16:46:51Z,2018-04-26T18:25:17Z,Rename rustc_back to rustc_target and move ABI code to it.,irinagpopa,a131c518ad640ccd12711ccd63d8b98cafa55ee9,16,Fixed tidy errors.,HOORAY,2018-04-25T17:33:37Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50231,MERGED,2018-04-25T18:22:07Z,2018-04-27T12:13:41Z,Add more doc aliases,GuillaumeGomez,30e3f1a620b06b6edd697c55858ea9f251a4332a,5,Add more doc aliases,HEART,2018-04-25T21:40:53Z,novacrazy,NA https://github.com/rust-lang/rust/pull/50231,MERGED,2018-04-25T18:22:07Z,2018-04-27T12:13:41Z,Add more doc aliases,GuillaumeGomez,30e3f1a620b06b6edd697c55858ea9f251a4332a,5,Add more doc aliases,HOORAY,2018-04-26T20:51:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,HEART,2018-04-27T03:37:11Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,THUMBS_UP,2018-04-29T23:20:07Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,HEART,2018-05-01T14:36:31Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,HEART,2018-05-02T14:43:28Z,Havvy,NA https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,HEART,2018-05-02T17:08:56Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,THUMBS_UP,2018-05-02T20:57:29Z,dbkaplun,dbkaplun@gmail.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,THUMBS_UP,2018-05-03T11:08:00Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,HEART,2018-05-03T11:08:00Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,THUMBS_UP,2018-05-03T16:17:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50233,MERGED,2018-04-25T21:40:08Z,2018-04-30T19:49:41Z,Make `Vec::new` a `const fn`,mark-i-m,f9f992379de4a82637ec4bf717ff42f27872bc48,1,heh logic is hard,THUMBS_UP,2019-11-13T10:27:17Z,denisandroid,denis2005991@gmail.com https://github.com/rust-lang/rust/pull/50235,MERGED,2018-04-25T22:53:16Z,2018-05-13T03:43:57Z,Add a Rayon thread pool,Zoxc,4afdae633d34384b0582c209f38d1f89ae4aa673,1,Update Cargo.lock,HOORAY,2018-04-26T21:13:23Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50235,MERGED,2018-04-25T22:53:16Z,2018-05-13T03:43:57Z,Add a Rayon thread pool,Zoxc,4afdae633d34384b0582c209f38d1f89ae4aa673,1,Update Cargo.lock,HOORAY,2018-04-27T05:27:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,HEART,2018-04-26T09:59:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,HEART,2018-04-26T19:50:14Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,THUMBS_UP,2018-04-26T21:13:43Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,THUMBS_UP,2018-04-27T15:19:42Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,HEART,2018-04-28T21:14:49Z,mcarton,NA https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,THUMBS_UP,2018-05-03T05:57:07Z,RanHum,NA https://github.com/rust-lang/rust/pull/50240,MERGED,2018-04-26T01:30:34Z,2018-04-28T23:49:41Z,Implement LazyBTreeMap and use it in a few places.,nnethercote,259ae181391933040389e7e4206e792ad66b1487,5,Implement LazyBTreeMap and use it in a few places. This is a thin wrapper around BTreeMap that avoids allocating upon creation. It speeds up some rustc-perf benchmarks by up to 3.6%.,THUMBS_UP,2020-08-26T14:59:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,HOORAY,2018-04-26T11:06:02Z,lqd,NA https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,LAUGH,2018-04-26T11:06:04Z,lqd,NA https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,LAUGH,2018-04-26T15:25:12Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,HOORAY,2018-04-26T17:16:03Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,HOORAY,2018-04-26T18:52:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,THUMBS_UP,2018-04-26T21:14:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,LAUGH,2018-04-27T06:14:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,LAUGH,2018-04-27T11:46:29Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,THUMBS_UP,2018-04-27T11:46:30Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,HOORAY,2018-04-27T11:46:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,THUMBS_UP,2018-04-30T12:53:08Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,THUMBS_UP,2018-05-03T03:57:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50246,MERGED,2018-04-26T09:26:30Z,2018-04-27T12:13:42Z,Make dump_{alloc allocs local}() no-ops when tracing is disabled.,nnethercote,2e4f66a86f7baa5644d18bb2adc07a8cd1c7409d,3,Make dump_{alloc allocs local}() no-ops when tracing is disabled. Because they traverse data structures and build up strings which is wasted effort if those strings aren't printed. The patch also removes some now-unnecessary log_enabled! tests at call sites.,HOORAY,2020-08-26T15:02:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50250,MERGED,2018-04-26T13:18:49Z,2018-07-09T23:08:54Z,Chalk lowering rule: WellFormed-TraitRef,csmoe,37c5c0bf9ce4e14b3cfaf102b1250c9201113b55,1,Change wording,HOORAY,2018-04-27T05:27:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50250,MERGED,2018-04-26T13:18:49Z,2018-07-09T23:08:54Z,Chalk lowering rule: WellFormed-TraitRef,csmoe,37c5c0bf9ce4e14b3cfaf102b1250c9201113b55,1,Change wording,HOORAY,2018-07-19T04:23:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50251,MERGED,2018-04-26T13:57:45Z,2018-04-27T23:32:05Z,rustc: Disable threads in LLD for wasm,alexcrichton,a2a9cc68fe44a4a667dddd01c17b3dcceefb5a5a,1,rustc: Disable threads in LLD for wasm Upstream bug reports (rustwasm/wasm-bindgen#119) show that this may be the culprit of odd crashes/hangs. The linker is a tiny fraction of build time anyway right now so let's disable it and figure out how to possibly reenable it later if necessary.,THUMBS_UP,2018-04-26T14:20:12Z,mvlabat,mvlabat@gmail.com https://github.com/rust-lang/rust/pull/50257,MERGED,2018-04-26T21:22:37Z,2018-04-27T23:32:06Z,Don't ICE on tuple struct ctor with incorrect arg count,estebank,d92d1935cb01cfa469a725f041e4c1d8a2ee9564,3,Don't ICE on tuple struct ctor with incorrect arg count,HEART,2018-04-26T21:24:49Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HEART,2018-04-27T17:57:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2018-04-27T17:57:39Z,cramertj,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2018-04-27T17:57:40Z,cramertj,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HEART,2018-04-27T18:09:24Z,estebank,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2018-04-27T19:19:48Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HEART,2018-04-27T19:49:15Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2018-04-27T19:49:16Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2018-04-28T18:59:54Z,azasypkin,aleh.zasypkin@gmail.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2018-05-04T15:15:45Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2018-05-04T15:15:46Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HEART,2018-05-23T14:44:52Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2018-05-24T03:27:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2018-07-31T20:49:14Z,frol,NA https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2018-09-11T13:10:32Z,Pulgovisk,pulgovisk@protonmail.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,THUMBS_UP,2019-08-30T03:34:21Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HOORAY,2019-08-30T03:34:52Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/50265,MERGED,2018-04-27T00:30:35Z,2018-05-21T14:45:44Z,stabilize opt-level={s z},japaric,2b09d7cc6455715205e08fedf16d382f49e82152,1,stabilize opt-level={s z} closes #35784,HEART,2019-08-30T03:34:53Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,THUMBS_UP,2018-04-27T01:25:19Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,HEART,2018-04-28T20:23:27Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,THUMBS_UP,2018-05-24T23:14:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,THUMBS_UP,2018-07-31T05:53:39Z,ljedrz,NA https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,THUMBS_UP,2018-08-08T09:39:23Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,HEART,2018-08-08T09:39:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50267,MERGED,2018-04-27T01:22:05Z,2018-07-31T13:32:32Z,Implement inner deref for Option and Result,U007D,56016cb1e02ece29f25c619b297f9c9797db821c,4336,resolved upstream merge conflicts,THUMBS_UP,2018-08-09T19:21:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50273,MERGED,2018-04-27T05:24:05Z,2018-04-27T23:32:10Z,Allow #[inline] on closures,Amanieu,5f2c111165371b1e59fec9cd90e364ccf08b68ef,8,Allow #[inline] on closures Fixes #49632,THUMBS_UP,2021-12-30T10:44:09Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/50296,MERGED,2018-04-28T06:06:24Z,2018-06-15T21:13:41Z,Add error message for using >= 65535 hashes for raw string literal escapes,dcao,313d6c53df9a2725ab62c653c8e87100ec45724f,1,provide error message when using more than 65535 hash symbols for raw strings,THUMBS_UP,2018-04-29T21:34:27Z,varkor,NA https://github.com/rust-lang/rust/pull/50296,MERGED,2018-04-28T06:06:24Z,2018-06-15T21:13:41Z,Add error message for using >= 65535 hashes for raw string literal escapes,dcao,313d6c53df9a2725ab62c653c8e87100ec45724f,1,provide error message when using more than 65535 hash symbols for raw strings,THUMBS_UP,2018-04-29T23:02:57Z,estebank,NA https://github.com/rust-lang/rust/pull/50296,MERGED,2018-04-28T06:06:24Z,2018-06-15T21:13:41Z,Add error message for using >= 65535 hashes for raw string literal escapes,dcao,313d6c53df9a2725ab62c653c8e87100ec45724f,1,provide error message when using more than 65535 hash symbols for raw strings,THUMBS_DOWN,2018-05-01T06:44:22Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50296,MERGED,2018-04-28T06:06:24Z,2018-06-15T21:13:41Z,Add error message for using >= 65535 hashes for raw string literal escapes,dcao,313d6c53df9a2725ab62c653c8e87100ec45724f,1,provide error message when using more than 65535 hash symbols for raw strings,THUMBS_DOWN,2018-06-20T05:09:21Z,StefanoD,NA https://github.com/rust-lang/rust/pull/50304,MERGED,2018-04-28T19:11:03Z,2018-05-01T08:06:08Z,Mark functions returning uninhabited types as noreturn,nox,69ec4aa97c23cfc316ec340d1afcaaeb4877e8ef,3,Mark functions returning uninhabited types as noreturn,HEART,2018-04-30T06:52:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50307,MERGED,2018-04-29T00:22:43Z,2018-05-18T13:13:51Z,Implement edition hygiene for keywords,petrochenkov,d8bbc1ee1ad44e9c7bd93c8d59103eacd0ed36e8,1,Fix rebase,HEART,2018-04-29T03:36:42Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/50307,MERGED,2018-04-29T00:22:43Z,2018-05-18T13:13:51Z,Implement edition hygiene for keywords,petrochenkov,d8bbc1ee1ad44e9c7bd93c8d59103eacd0ed36e8,1,Fix rebase,HEART,2021-03-28T08:11:54Z,alichraghi,NA https://github.com/rust-lang/rust/pull/50317,MERGED,2018-04-29T17:49:22Z,2018-04-30T00:18:50Z,Improve error message for #[repr(align=x)],varkor,35fe2998c0c555c978617913771691e384670486,2,Add test for repr(align=x),THUMBS_UP,2018-05-02T23:06:53Z,bitshifter,NA https://github.com/rust-lang/rust/pull/50319,MERGED,2018-04-29T19:32:58Z,2018-05-19T00:27:49Z,Implement [T]::align_to,nagisa,59bb0fe66ea6d80c5e1466b9609887e4cf7cde47,2,Fix align_offset_stride1 & align_to_simple tests,HEART,2019-04-26T13:36:16Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/50327,MERGED,2018-04-30T00:30:23Z,2018-04-30T19:49:47Z,Display correct unused field suggestion for nested struct patterns,varkor,2eb8343af18470d3c48a50c68dbaeb1887b42c37,3,Correct unused field warning on struct match container patterns,HEART,2018-04-30T02:20:30Z,estebank,NA https://github.com/rust-lang/rust/pull/50327,MERGED,2018-04-30T00:30:23Z,2018-04-30T19:49:47Z,Display correct unused field suggestion for nested struct patterns,varkor,2eb8343af18470d3c48a50c68dbaeb1887b42c37,3,Correct unused field warning on struct match container patterns,HEART,2018-04-30T11:17:50Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50327,MERGED,2018-04-30T00:30:23Z,2018-04-30T19:49:47Z,Display correct unused field suggestion for nested struct patterns,varkor,2eb8343af18470d3c48a50c68dbaeb1887b42c37,3,Correct unused field warning on struct match container patterns,HEART,2018-05-01T15:36:06Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/50327,MERGED,2018-04-30T00:30:23Z,2018-04-30T19:49:47Z,Display correct unused field suggestion for nested struct patterns,varkor,2eb8343af18470d3c48a50c68dbaeb1887b42c37,3,Correct unused field warning on struct match container patterns,HEART,2018-05-02T18:52:51Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/50327,MERGED,2018-04-30T00:30:23Z,2018-04-30T19:49:47Z,Display correct unused field suggestion for nested struct patterns,varkor,2eb8343af18470d3c48a50c68dbaeb1887b42c37,3,Correct unused field warning on struct match container patterns,HEART,2018-05-03T16:18:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50331,MERGED,2018-04-30T06:10:35Z,2018-05-10T23:33:28Z,Map the stack guard page with max protection on NetBSD,MartinHusemann,244e24a312925779f6c62ce7d6b315fa2c120a7c,1,Add comments and unify guard page setup. While currently only NetBSD seems to be affected all systems implementing PAX MPROTECT in strict mode need this treatment and it does not hurt others.,THUMBS_UP,2018-05-01T20:28:42Z,estebank,NA https://github.com/rust-lang/rust/pull/50332,MERGED,2018-04-30T07:00:30Z,2018-05-11T15:40:46Z,Only lookup types in one interner,Zoxc,e245d693225552b70d4dba7a1ee5d3cae12a8ab4,1,Only lookup types in one interner,HEART,2018-05-02T11:56:33Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50336,MERGED,2018-04-30T08:21:51Z,2018-06-21T13:36:41Z,ship LLVM tools with the toolchain,japaric,9a96876d2d1f8e2a4ca066f132c4b6ddec1b94ff,1,no -Bsymbolic for mac; no static-libstdc++ for windows,THUMBS_UP,2018-04-30T13:36:51Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50336,MERGED,2018-04-30T08:21:51Z,2018-06-21T13:36:41Z,ship LLVM tools with the toolchain,japaric,9a96876d2d1f8e2a4ca066f132c4b6ddec1b94ff,1,no -Bsymbolic for mac; no static-libstdc++ for windows,THUMBS_UP,2018-04-30T17:56:52Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/50336,MERGED,2018-04-30T08:21:51Z,2018-06-21T13:36:41Z,ship LLVM tools with the toolchain,japaric,9a96876d2d1f8e2a4ca066f132c4b6ddec1b94ff,1,no -Bsymbolic for mac; no static-libstdc++ for windows,THUMBS_UP,2018-05-01T19:08:36Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/50336,MERGED,2018-04-30T08:21:51Z,2018-06-21T13:36:41Z,ship LLVM tools with the toolchain,japaric,9a96876d2d1f8e2a4ca066f132c4b6ddec1b94ff,1,no -Bsymbolic for mac; no static-libstdc++ for windows,THUMBS_UP,2018-06-03T15:37:51Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,THUMBS_UP,2018-04-30T13:06:41Z,jcsoo,NA https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,HOORAY,2018-05-05T18:34:23Z,est31,NA https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,THUMBS_UP,2018-05-13T15:37:42Z,CryZe,NA https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,HOORAY,2018-05-13T15:37:43Z,CryZe,NA https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,HOORAY,2018-05-23T20:29:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,THUMBS_UP,2018-06-07T15:15:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50338,MERGED,2018-04-30T09:00:08Z,2018-06-03T22:53:47Z,implement #[panic_implementation],japaric,8ad15dea3f9ac9b0fcfad4a61a70aa47ecc4d938,3,turn run-make test into a run-make-fulldeps test,HOORAY,2018-07-03T12:41:36Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-04-30T13:39:15Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-04-30T15:50:04Z,alexbool,NA https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,HEART,2018-05-01T07:29:18Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,HEART,2018-05-06T22:08:03Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-06-01T18:56:58Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-06-06T16:02:43Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,HEART,2018-06-06T20:30:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-06-07T15:09:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50340,MERGED,2018-04-30T11:52:36Z,2018-06-01T18:25:12Z,optimize joining for slices,Emerentius,12bd28874697d600d347518c8636053b92e81801,2,incorporate changes from code review further reduce unsafe fn calls reduce right drift assert! sufficient capacity,THUMBS_UP,2018-06-07T18:44:24Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/50342,MERGED,2018-04-30T14:21:30Z,2018-06-28T01:41:45Z,Document round-off error in `.mod_euc()`-method see issue #50179,clamydo,bd853a6469fb71b4719d05c20535a70e75d1aa78,1,Add unit tests for `.mod_euc()` and `.div_euc()`,HEART,2018-05-01T04:24:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50342,MERGED,2018-04-30T14:21:30Z,2018-06-28T01:41:45Z,Document round-off error in `.mod_euc()`-method see issue #50179,clamydo,bd853a6469fb71b4719d05c20535a70e75d1aa78,1,Add unit tests for `.mod_euc()` and `.div_euc()`,HEART,2018-05-01T16:40:25Z,fanzier,NA https://github.com/rust-lang/rust/pull/50348,CLOSED,2018-04-30T18:26:05Z,2018-05-28T16:55:53Z,std: Add support for SOCK_SEQPACKET Unix sockets,dkl,NA,NA,NA,THUMBS_UP,2018-05-08T18:42:23Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-02T19:11:33Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-06T19:35:42Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-12T14:18:04Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-12T17:14:28Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-13T15:27:07Z,llogiq,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-14T13:08:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-14T13:14:23Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-14T14:19:52Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-14T19:44:57Z,killercup,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-14T19:58:48Z,Dr-Emann,dremann@gmail.com https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-15T22:16:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-16T11:31:28Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-16T16:52:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-05-16T17:36:34Z,delacian,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-06-05T07:25:24Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2018-09-03T05:35:46Z,bb010g,NA https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2019-08-13T14:53:44Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50352,MERGED,2018-04-30T22:00:47Z,2018-05-12T12:03:38Z,Don't allocate when creating an empty BTree,porglezomp,e83c18f91d373592ecf7a0fbbc24d7597925af13,2,Make an ensure_root_is_owned method to reduce duplication Also remove some unnecessary debug_assert! when creating the shared root since the root should be stored in the rodata and thus be impossible to accidentally modify.,HOORAY,2020-08-26T15:00:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-01T11:35:11Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-02T17:49:54Z,cramertj,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-03T01:57:20Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-05T16:06:50Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-06T10:35:47Z,mcarton,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-07T11:48:58Z,Enet4,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-26T05:46:24Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-31T02:53:10Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-05-31T18:26:05Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-06-01T07:43:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-06-01T15:46:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-06-05T21:27:05Z,rust-bus-owner,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-07-31T15:49:18Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2018-09-13T01:24:53Z,tikue,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2019-03-18T00:22:47Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2020-08-01T04:47:05Z,mpfaff,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2020-11-16T23:50:33Z,tjkirch,NA https://github.com/rust-lang/rust/pull/50364,MERGED,2018-05-01T11:26:29Z,2018-05-26T09:59:54Z,Improve `Debug` impl of `time::Duration`,LukasKalbertodt,59e71141029162fe4b4a3ed4cad430dace3fb995,2,Fix `Debug` impl of `Duration` for precisions > 9 Previously the code would panic for high precision values. Now it has the same behavior as printing normal floating point values: if a high precision is specified '0's are added.,HEART,2022-06-15T02:40:34Z,ndelvalle,nicolas.delvalle@gmail.com https://github.com/rust-lang/rust/pull/50369,MERGED,2018-05-01T15:08:12Z,2018-05-03T04:25:06Z,Fix a warning in libcore on 16bit targets.,pftbest,f29e62aadf9efa961b3da9d960fb35f748aed0d5,1,Fix a warning in libcore on 16bit targets. This code is assuming that usize >= 32bits but it is not the case on 16bit targets. It is producing a warning that will fail the compilation on MSP430 if deny(warnings) is enabled. It is very unlikely that someone would actually use this code on a microcontroller but since unicode was merged into libcore we have compile it on 16bit targets.,HEART,2018-05-01T20:43:00Z,estebank,NA https://github.com/rust-lang/rust/pull/50385,MERGED,2018-05-02T03:03:44Z,2018-05-14T15:00:08Z,stabilize macro_lifetime_matcher,durka,e857c1b79028765c62e7f29584c7ce75bfb739b9,3,restore feature for stage0,HOORAY,2018-05-02T17:18:54Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/50387,MERGED,2018-05-02T06:38:30Z,2018-05-18T05:23:32Z,Remove leftover tab in libtest outputs,phansch,4f2cfb57f5afe503c554f13484c53482e38d7bba,2,Remove leftover tab in libtest outputs Closes #50362,THUMBS_UP,2018-10-23T21:03:57Z,thanatos,NA https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HEART,2018-05-02T10:46:24Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-05-02T11:36:41Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-05-02T14:21:50Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-05-03T13:00:19Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HEART,2018-05-03T13:00:22Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-05-10T03:47:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-05-10T13:42:08Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/50391,MERGED,2018-05-02T10:43:43Z,2018-05-03T10:28:57Z,Use escape_default() for strings in LitKind::token().,nnethercote,7a56360ecef1dca261110281e78385fc8f14b154,2,Remove parse::escape_default(). str::escape_default() can be used instead.,HOORAY,2018-06-06T17:51:18Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/50395,MERGED,2018-05-02T14:31:34Z,2018-05-10T16:27:40Z,Optimize layout of TypeVariants,Zoxc,c9d9c249ec95afa53a1862fcb99bf04c339b126c,60,Insert fields from TypeAndMut into TyRef to allow layout optimization,HOORAY,2018-05-02T18:42:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50395,MERGED,2018-05-02T14:31:34Z,2018-05-10T16:27:40Z,Optimize layout of TypeVariants,Zoxc,c9d9c249ec95afa53a1862fcb99bf04c339b126c,60,Insert fields from TypeAndMut into TyRef to allow layout optimization,HOORAY,2018-05-02T23:01:34Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/50398,MERGED,2018-05-02T22:00:37Z,2018-05-04T08:22:35Z,nano-optimization for memchr::repeat_byte,llogiq,1cefb5ce310fe7f799d0926d2644a25a567d2ddb,1,nano-optimization for memchr::repeat_byte,LAUGH,2018-05-02T22:10:59Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50398,MERGED,2018-05-02T22:00:37Z,2018-05-04T08:22:35Z,nano-optimization for memchr::repeat_byte,llogiq,1cefb5ce310fe7f799d0926d2644a25a567d2ddb,1,nano-optimization for memchr::repeat_byte,LAUGH,2018-05-02T23:33:53Z,kennytm,NA https://github.com/rust-lang/rust/pull/50398,MERGED,2018-05-02T22:00:37Z,2018-05-04T08:22:35Z,nano-optimization for memchr::repeat_byte,llogiq,1cefb5ce310fe7f799d0926d2644a25a567d2ddb,1,nano-optimization for memchr::repeat_byte,THUMBS_UP,2018-05-04T01:00:15Z,vmchale,NA https://github.com/rust-lang/rust/pull/50398,MERGED,2018-05-02T22:00:37Z,2018-05-04T08:22:35Z,nano-optimization for memchr::repeat_byte,llogiq,1cefb5ce310fe7f799d0926d2644a25a567d2ddb,1,nano-optimization for memchr::repeat_byte,LAUGH,2018-05-04T04:58:31Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/50398,MERGED,2018-05-02T22:00:37Z,2018-05-04T08:22:35Z,nano-optimization for memchr::repeat_byte,llogiq,1cefb5ce310fe7f799d0926d2644a25a567d2ddb,1,nano-optimization for memchr::repeat_byte,THUMBS_UP,2018-05-05T11:33:55Z,bluss,NA https://github.com/rust-lang/rust/pull/50401,MERGED,2018-05-02T23:41:15Z,2018-05-03T23:12:31Z,"Revert ""Implement FromStr for PathBuf""",alexcrichton,f6841470f1beb007052b12a090c1eb109c7259e8,1,"Revert ""Implement FromStr for PathBuf"" This reverts commit 05a9acc3b844ff284a3e3d85dde2d9798abfb215.",HEART,2018-05-03T23:48:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50404,CLOSED,2018-05-03T01:36:46Z,2018-07-03T22:19:58Z,Build `librustc_llvm` as a dylib and install it as part of the private rustc crates.,DiamondLovesYou,NA,NA,NA,THUMBS_DOWN,2018-06-15T17:42:13Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50406,MERGED,2018-05-03T03:10:37Z,2018-05-03T23:12:32Z,Forbid constructing empty identifiers from concat_idents,ExpHP,8e38d02d986a5fa5ef51b6995058d7327aa0da4b,2,update concat_idents doc stubs,LAUGH,2018-06-25T02:42:46Z,Ixrec,NA https://github.com/rust-lang/rust/pull/50416,MERGED,2018-05-03T11:15:27Z,2018-05-03T23:12:34Z,check if the token is a lifetime before parsing,rleungx,390c3cee6a8e0c0550eb6213c0e7e5f74c4fbc31,3,check if the token is a lifetime before parsing,HOORAY,2018-05-03T17:47:08Z,estebank,NA https://github.com/rust-lang/rust/pull/50418,MERGED,2018-05-03T12:18:25Z,2018-05-05T11:05:40Z,Avoid many `cmt` allocations.,nnethercote,7cf142f78b82b0b2ae08b52ccb6a6e15c0270c38,12,Avoid many `cmt` allocations. `cmt` is a ref-counted wrapper around `cmt_` The use of refcounting keeps `cmt` handling simple but a lot of `cmt` instances are very short-lived and heap-allocating the short-lived ones takes up time. This patch changes things in the following ways. - Most of the functions that produced `cmt` instances now produce `cmt_` instances. The `Rc::new` calls that occurred within those functions now occur at their call sites (but only when necessary which isn't that often). - Many of the functions that took `cmt` arguments now take `&cmt_` arguments. This includes all the methods in the `Delegate` trait. As a result the vast majority of the heap allocations are avoided. In an extreme case the number of calls to malloc in tuple-stress drops from 9.9M to 7.9M a drop of 20%. And the compile times for many runs of coercions deep-vector and tuple-stress drop by 1--2%.,THUMBS_UP,2018-05-03T17:49:53Z,estebank,NA https://github.com/rust-lang/rust/pull/50418,MERGED,2018-05-03T12:18:25Z,2018-05-05T11:05:40Z,Avoid many `cmt` allocations.,nnethercote,7cf142f78b82b0b2ae08b52ccb6a6e15c0270c38,12,Avoid many `cmt` allocations. `cmt` is a ref-counted wrapper around `cmt_` The use of refcounting keeps `cmt` handling simple but a lot of `cmt` instances are very short-lived and heap-allocating the short-lived ones takes up time. This patch changes things in the following ways. - Most of the functions that produced `cmt` instances now produce `cmt_` instances. The `Rc::new` calls that occurred within those functions now occur at their call sites (but only when necessary which isn't that often). - Many of the functions that took `cmt` arguments now take `&cmt_` arguments. This includes all the methods in the `Delegate` trait. As a result the vast majority of the heap allocations are avoided. In an extreme case the number of calls to malloc in tuple-stress drops from 9.9M to 7.9M a drop of 20%. And the compile times for many runs of coercions deep-vector and tuple-stress drop by 1--2%.,THUMBS_UP,2018-05-03T22:15:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/50418,MERGED,2018-05-03T12:18:25Z,2018-05-05T11:05:40Z,Avoid many `cmt` allocations.,nnethercote,7cf142f78b82b0b2ae08b52ccb6a6e15c0270c38,12,Avoid many `cmt` allocations. `cmt` is a ref-counted wrapper around `cmt_` The use of refcounting keeps `cmt` handling simple but a lot of `cmt` instances are very short-lived and heap-allocating the short-lived ones takes up time. This patch changes things in the following ways. - Most of the functions that produced `cmt` instances now produce `cmt_` instances. The `Rc::new` calls that occurred within those functions now occur at their call sites (but only when necessary which isn't that often). - Many of the functions that took `cmt` arguments now take `&cmt_` arguments. This includes all the methods in the `Delegate` trait. As a result the vast majority of the heap allocations are avoided. In an extreme case the number of calls to malloc in tuple-stress drops from 9.9M to 7.9M a drop of 20%. And the compile times for many runs of coercions deep-vector and tuple-stress drop by 1--2%.,THUMBS_UP,2018-05-04T13:46:02Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50418,MERGED,2018-05-03T12:18:25Z,2018-05-05T11:05:40Z,Avoid many `cmt` allocations.,nnethercote,7cf142f78b82b0b2ae08b52ccb6a6e15c0270c38,12,Avoid many `cmt` allocations. `cmt` is a ref-counted wrapper around `cmt_` The use of refcounting keeps `cmt` handling simple but a lot of `cmt` instances are very short-lived and heap-allocating the short-lived ones takes up time. This patch changes things in the following ways. - Most of the functions that produced `cmt` instances now produce `cmt_` instances. The `Rc::new` calls that occurred within those functions now occur at their call sites (but only when necessary which isn't that often). - Many of the functions that took `cmt` arguments now take `&cmt_` arguments. This includes all the methods in the `Delegate` trait. As a result the vast majority of the heap allocations are avoided. In an extreme case the number of calls to malloc in tuple-stress drops from 9.9M to 7.9M a drop of 20%. And the compile times for many runs of coercions deep-vector and tuple-stress drop by 1--2%.,THUMBS_UP,2018-05-04T14:31:42Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50418,MERGED,2018-05-03T12:18:25Z,2018-05-05T11:05:40Z,Avoid many `cmt` allocations.,nnethercote,7cf142f78b82b0b2ae08b52ccb6a6e15c0270c38,12,Avoid many `cmt` allocations. `cmt` is a ref-counted wrapper around `cmt_` The use of refcounting keeps `cmt` handling simple but a lot of `cmt` instances are very short-lived and heap-allocating the short-lived ones takes up time. This patch changes things in the following ways. - Most of the functions that produced `cmt` instances now produce `cmt_` instances. The `Rc::new` calls that occurred within those functions now occur at their call sites (but only when necessary which isn't that often). - Many of the functions that took `cmt` arguments now take `&cmt_` arguments. This includes all the methods in the `Delegate` trait. As a result the vast majority of the heap allocations are avoided. In an extreme case the number of calls to malloc in tuple-stress drops from 9.9M to 7.9M a drop of 20%. And the compile times for many runs of coercions deep-vector and tuple-stress drop by 1--2%.,THUMBS_UP,2018-05-05T07:22:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50436,CLOSED,2018-05-03T23:41:19Z,2018-05-22T01:26:13Z,Split the common usage patterns off the `Alloc` trait,glandium,NA,NA,NA,THUMBS_UP,2018-05-04T16:52:02Z,xgalaxy,NA https://github.com/rust-lang/rust/pull/50437,MERGED,2018-05-04T04:07:39Z,2018-05-07T08:41:22Z,in which the must-use additional messaging is tucked into a note,zackmdavis,5a5a25c701e27eb9fbd46a6c54053e3a1d05b042,3,in which the must-use additional messaging is tucked into a note Also a comment is edited to reflect that spaces around the equals-sign in attributes is the standard (q.v. rust-lang-nursery/fmt-rfcs@bea80532e7).,THUMBS_UP,2018-05-05T07:25:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50440,MERGED,2018-05-04T09:55:50Z,2018-05-11T04:45:37Z,Improve single-use and zero-use lifetime lints,nikomatsakis,6f98ee95d8ac9fb310cb6b8fcf2ce48d68d08a24,1,ensure lint are issued in a stable order,HEART,2018-05-05T05:13:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50441,MERGED,2018-05-04T11:50:15Z,2018-05-05T16:42:49Z,Suggest more helpful formatting string,kornelski,1e38eee63b0a0a3429a59dd756c852116b4d3615,2,Suggest more helpful formatting string,THUMBS_UP,2018-05-05T00:06:19Z,deikatsuo,NA https://github.com/rust-lang/rust/pull/50441,MERGED,2018-05-04T11:50:15Z,2018-05-05T16:42:49Z,Suggest more helpful formatting string,kornelski,1e38eee63b0a0a3429a59dd756c852116b4d3615,2,Suggest more helpful formatting string,THUMBS_UP,2018-05-09T03:46:05Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/50451,CLOSED,2018-05-04T19:20:21Z,2018-05-07T08:03:48Z,Fix tidy check,GuillaumeGomez,NA,NA,NA,CONFUSED,2018-05-04T19:37:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/50453,MERGED,2018-05-04T21:13:30Z,2018-05-06T06:34:09Z,proc_macro: Explicitly make everything !Send/Sync,alexcrichton,3e0ed2fc05780f2d2a0709fb2716631c9eaa47df,1,proc_macro: Explicitly make everything !Send/Sync This commit adds explicit imp blocks to ensure that all publicly exported types (except simple enums) are not `Send` nor `Sync` in the `proc_macro` crate. cc #38356,THUMBS_UP,2018-05-04T21:36:20Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/50457,CLOSED,2018-05-05T05:30:57Z,2018-05-14T21:56:26Z,Reusable handle to thread-local replaceable stdout/err,CAD97,NA,NA,NA,THUMBS_UP,2018-05-05T07:26:02Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50460,MERGED,2018-05-05T08:38:59Z,2018-05-09T15:44:43Z,Make `String::new()` const,F001,160063aad2206a35e6312bfaa159f0f4475af0ae,3,make `String::new()` const,HOORAY,2018-05-06T18:44:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50460,MERGED,2018-05-05T08:38:59Z,2018-05-09T15:44:43Z,Make `String::new()` const,F001,160063aad2206a35e6312bfaa159f0f4475af0ae,3,make `String::new()` const,HOORAY,2018-05-08T20:10:22Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/50460,MERGED,2018-05-05T08:38:59Z,2018-05-09T15:44:43Z,Make `String::new()` const,F001,160063aad2206a35e6312bfaa159f0f4475af0ae,3,make `String::new()` const,HOORAY,2018-05-16T11:31:33Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/50460,MERGED,2018-05-05T08:38:59Z,2018-05-09T15:44:43Z,Make `String::new()` const,F001,160063aad2206a35e6312bfaa159f0f4475af0ae,3,make `String::new()` const,HOORAY,2018-05-16T13:02:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50460,MERGED,2018-05-05T08:38:59Z,2018-05-09T15:44:43Z,Make `String::new()` const,F001,160063aad2206a35e6312bfaa159f0f4475af0ae,3,make `String::new()` const,HEART,2018-05-17T04:58:50Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50466,MERGED,2018-05-05T18:42:40Z,2018-05-06T08:47:01Z,rustbuild: Allow quick testing of libstd and libcore at stage0,kennytm,05af55bd8052576bc172d635f8eb9207ccedfd29,4,s/DocTestsOption/DocTests/g,HEART,2018-05-05T18:45:27Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/50466,MERGED,2018-05-05T18:42:40Z,2018-05-06T08:47:01Z,rustbuild: Allow quick testing of libstd and libcore at stage0,kennytm,05af55bd8052576bc172d635f8eb9207ccedfd29,4,s/DocTestsOption/DocTests/g,HEART,2018-05-05T19:05:11Z,qmx,qmx@qmx.me https://github.com/rust-lang/rust/pull/50466,MERGED,2018-05-05T18:42:40Z,2018-05-06T08:47:01Z,rustbuild: Allow quick testing of libstd and libcore at stage0,kennytm,05af55bd8052576bc172d635f8eb9207ccedfd29,4,s/DocTestsOption/DocTests/g,HOORAY,2018-05-07T01:53:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50473,MERGED,2018-05-06T00:46:20Z,2018-05-16T13:33:30Z,Review proc macro API 1.2,petrochenkov,dab8c0ab28c317f7b9e350a0ba84fd51787f84d6,33,Fix stability annotations for already stable bits of proc macro API 1.1 Remove unnecessary proc-macro-related `feature`s,THUMBS_UP,2018-05-06T20:37:55Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/50473,MERGED,2018-05-06T00:46:20Z,2018-05-16T13:33:30Z,Review proc macro API 1.2,petrochenkov,dab8c0ab28c317f7b9e350a0ba84fd51787f84d6,33,Fix stability annotations for already stable bits of proc macro API 1.1 Remove unnecessary proc-macro-related `feature`s,THUMBS_UP,2018-05-14T15:39:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50473,MERGED,2018-05-06T00:46:20Z,2018-05-16T13:33:30Z,Review proc macro API 1.2,petrochenkov,dab8c0ab28c317f7b9e350a0ba84fd51787f84d6,33,Fix stability annotations for already stable bits of proc macro API 1.1 Remove unnecessary proc-macro-related `feature`s,THUMBS_UP,2018-05-24T03:23:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50473,MERGED,2018-05-06T00:46:20Z,2018-05-16T13:33:30Z,Review proc macro API 1.2,petrochenkov,dab8c0ab28c317f7b9e350a0ba84fd51787f84d6,33,Fix stability annotations for already stable bits of proc macro API 1.1 Remove unnecessary proc-macro-related `feature`s,THUMBS_UP,2018-10-27T15:51:29Z,hcpl,NA https://github.com/rust-lang/rust/pull/50474,MERGED,2018-05-06T02:10:19Z,2018-05-06T17:47:47Z,Fix ICE in assertion macro,sinkuu,39df2231bb7d3de171b6a7117bb76bbee5a4597f,3,Fix assertion message generation,THUMBS_UP,2018-05-06T12:18:19Z,ollie27,NA https://github.com/rust-lang/rust/pull/50474,MERGED,2018-05-06T02:10:19Z,2018-05-06T17:47:47Z,Fix ICE in assertion macro,sinkuu,39df2231bb7d3de171b6a7117bb76bbee5a4597f,3,Fix assertion message generation,THUMBS_UP,2018-05-06T14:00:59Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/50486,MERGED,2018-05-06T20:32:30Z,2018-05-22T04:17:23Z,Stabilize suggestion applicability field in json output,Manishearth,b0e66386f761ef7dff9edba1f81a693c94e1adfa,2,update tests,HOORAY,2018-06-22T20:42:14Z,mcarton,NA https://github.com/rust-lang/rust/pull/50491,CLOSED,2018-05-07T03:53:16Z,2018-05-13T10:24:51Z,Use LazyBTreeMap for region constraints.,nnethercote,NA,NA,NA,HOORAY,2018-05-07T17:57:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50491,CLOSED,2018-05-07T03:53:16Z,2018-05-13T10:24:51Z,Use LazyBTreeMap for region constraints.,nnethercote,NA,NA,NA,HOORAY,2018-05-08T23:14:33Z,estebank,NA https://github.com/rust-lang/rust/pull/50491,CLOSED,2018-05-07T03:53:16Z,2018-05-13T10:24:51Z,Use LazyBTreeMap for region constraints.,nnethercote,NA,NA,NA,HOORAY,2020-08-26T14:58:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50494,MERGED,2018-05-07T07:36:14Z,2018-07-23T21:44:38Z,Implement rfc 1789: Conversions from `&mut T` to `&Cell`,F001,489101cc45d21d3909a728d16864e26599c12bee,2,use inherent method instead,HOORAY,2018-06-15T06:53:42Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/50494,MERGED,2018-05-07T07:36:14Z,2018-07-23T21:44:38Z,Implement rfc 1789: Conversions from `&mut T` to `&Cell`,F001,489101cc45d21d3909a728d16864e26599c12bee,2,use inherent method instead,HOORAY,2018-07-26T11:45:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-07T16:43:23Z,cramertj,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HEART,2018-05-07T16:43:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-07T17:20:51Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,THUMBS_UP,2018-05-07T17:58:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-07T18:31:39Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-07T18:48:17Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-09T11:22:40Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-09T16:34:59Z,Hugal31,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-09T17:10:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,THUMBS_UP,2018-05-10T03:34:38Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-10T03:34:39Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HEART,2018-05-10T03:34:39Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-10T07:22:57Z,oherrala,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,THUMBS_UP,2018-05-10T08:56:28Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-10T08:56:29Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-10T11:53:27Z,davll,NA https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,THUMBS_UP,2018-05-10T13:35:35Z,kishoreneelamegam,kishore@lendsmart.ai https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-10T13:35:36Z,kishoreneelamegam,kishore@lendsmart.ai https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HEART,2018-05-10T13:35:37Z,kishoreneelamegam,kishore@lendsmart.ai https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,LAUGH,2018-05-10T13:35:45Z,kishoreneelamegam,kishore@lendsmart.ai https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,THUMBS_UP,2018-05-10T16:11:45Z,lostintime,lostintime.dev@gmail.com https://github.com/rust-lang/rust/pull/50510,MERGED,2018-05-07T16:04:45Z,2018-05-07T19:56:22Z,Stable release 1.26.0,Mark-Simulacrum,adcf7dad3ea2fda6ff47c6a401a3ee0ee53c7cb5,1,Stable release 1.26.0,HOORAY,2018-05-11T21:44:46Z,andradei,NA https://github.com/rust-lang/rust/pull/50521,MERGED,2018-05-08T00:17:24Z,2018-05-28T19:16:34Z,Add simd math intrinsics and gather/scatter,gnzlbg,de60483e6dc8542ea8d1c0daaba45e17b986a13f,3,more reverts,HEART,2018-05-08T01:09:41Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/50521,MERGED,2018-05-08T00:17:24Z,2018-05-28T19:16:34Z,Add simd math intrinsics and gather/scatter,gnzlbg,de60483e6dc8542ea8d1c0daaba45e17b986a13f,3,more reverts,HEART,2018-05-08T07:05:05Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50521,MERGED,2018-05-08T00:17:24Z,2018-05-28T19:16:34Z,Add simd math intrinsics and gather/scatter,gnzlbg,de60483e6dc8542ea8d1c0daaba45e17b986a13f,3,more reverts,HEART,2018-05-18T20:33:17Z,novacrazy,NA https://github.com/rust-lang/rust/pull/50521,MERGED,2018-05-08T00:17:24Z,2018-05-28T19:16:34Z,Add simd math intrinsics and gather/scatter,gnzlbg,de60483e6dc8542ea8d1c0daaba45e17b986a13f,3,more reverts,HOORAY,2018-05-30T12:51:02Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50521,MERGED,2018-05-08T00:17:24Z,2018-05-28T19:16:34Z,Add simd math intrinsics and gather/scatter,gnzlbg,de60483e6dc8542ea8d1c0daaba45e17b986a13f,3,more reverts,HOORAY,2018-06-01T07:15:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50525,MERGED,2018-05-08T05:16:32Z,2018-05-09T15:44:48Z,Optimize string handling in lit_token().,nnethercote,65ea0ff29d32ca4fea30477f7fb1a1d43342dc26,1,Optimize string handling in lit_token(). In the common case the string value in a string literal Token is the same as the string value in a string literal LitKind. (The exception is when escapes or \r are involved.) This patch takes advantage of that to avoid calling str_lit() and re-interning the string in that case. This speeds up incremental builds for a few of the rustc-benchmarks the best by 3%.,THUMBS_UP,2018-05-08T07:06:38Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50526,MERGED,2018-05-08T07:24:38Z,2018-06-29T11:46:07Z,Add a fallback for stacktrace printing for older Windows versions.,moxian,be7f619870085121bdd7911aa882c35e70aedb8a,1,Change traits to bare FnMut where possible.,THUMBS_UP,2018-06-28T01:53:06Z,SpaceManiac,tad@platymuus.com https://github.com/rust-lang/rust/pull/50526,MERGED,2018-05-08T07:24:38Z,2018-06-29T11:46:07Z,Add a fallback for stacktrace printing for older Windows versions.,moxian,be7f619870085121bdd7911aa882c35e70aedb8a,1,Change traits to bare FnMut where possible.,HOORAY,2018-06-28T01:53:08Z,SpaceManiac,tad@platymuus.com https://github.com/rust-lang/rust/pull/50526,MERGED,2018-05-08T07:24:38Z,2018-06-29T11:46:07Z,Add a fallback for stacktrace printing for older Windows versions.,moxian,be7f619870085121bdd7911aa882c35e70aedb8a,1,Change traits to bare FnMut where possible.,HEART,2018-06-28T01:53:10Z,SpaceManiac,tad@platymuus.com https://github.com/rust-lang/rust/pull/50526,MERGED,2018-05-08T07:24:38Z,2018-06-29T11:46:07Z,Add a fallback for stacktrace printing for older Windows versions.,moxian,be7f619870085121bdd7911aa882c35e70aedb8a,1,Change traits to bare FnMut where possible.,THUMBS_UP,2018-08-16T01:40:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50545,MERGED,2018-05-08T20:52:36Z,2018-05-12T21:12:01Z,Made some functions in time module const,rizakrko,4d8d0a6f85ee66c7b65c53de3039aa38d99f05af,3,const time added rustc_const_unstable attribute extended tests added conversion test fixed tidy test added feature attribute,HEART,2018-05-09T04:51:48Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50545,MERGED,2018-05-08T20:52:36Z,2018-05-12T21:12:01Z,Made some functions in time module const,rizakrko,4d8d0a6f85ee66c7b65c53de3039aa38d99f05af,3,const time added rustc_const_unstable attribute extended tests added conversion test fixed tidy test added feature attribute,THUMBS_UP,2018-05-09T08:23:10Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50549,CLOSED,2018-05-08T23:09:07Z,2018-05-11T10:44:18Z,Use Rc instead of Box for interned strings.,nnethercote,NA,NA,NA,HOORAY,2018-05-09T08:22:38Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50549,CLOSED,2018-05-08T23:09:07Z,2018-05-11T10:44:18Z,Use Rc instead of Box for interned strings.,nnethercote,NA,NA,NA,HOORAY,2018-05-09T10:49:14Z,sfackler,NA https://github.com/rust-lang/rust/pull/50553,MERGED,2018-05-09T01:30:05Z,2018-05-18T05:23:35Z,Add Option::xor method,clarfonthey,8ab2d15f6753054797c88f07028e4802c43b70ab,1,Add Option::xor method,CONFUSED,2018-05-10T06:48:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50553,MERGED,2018-05-09T01:30:05Z,2018-05-18T05:23:35Z,Add Option::xor method,clarfonthey,8ab2d15f6753054797c88f07028e4802c43b70ab,1,Add Option::xor method,THUMBS_UP,2018-06-01T10:45:48Z,loovjo,NA https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_UP,2018-05-09T08:58:00Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_UP,2018-05-21T18:25:24Z,ithinuel,wilfried.chauveau@ithinuel.me https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,CONFUSED,2018-06-06T16:05:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,CONFUSED,2018-06-07T20:25:52Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-06-07T20:28:11Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-06-07T21:07:24Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,CONFUSED,2018-06-07T21:20:06Z,repi,NA https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-06-07T21:42:25Z,hoodie,NA https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-06-08T01:54:28Z,bluejekyll,NA https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-06-08T07:27:01Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_UP,2018-06-11T09:05:34Z,mati865,NA https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_UP,2018-07-31T13:51:29Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,CONFUSED,2018-07-31T21:53:35Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/50554,MERGED,2018-05-09T01:37:42Z,2018-06-02T09:58:44Z,Add From for int types,clarfonthey,b1797d57ffb42a063a8ecc8cc5f9d2b625708c72,1,Add @ithinuel's tests from #50597,THUMBS_DOWN,2018-10-09T20:07:19Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/50559,CLOSED,2018-05-09T06:28:14Z,2018-05-09T17:21:39Z, make size_of_val and align_of_val const fns ,Gankra,NA,NA,NA,THUMBS_DOWN,2018-05-09T08:21:10Z,kennytm,NA https://github.com/rust-lang/rust/pull/50559,CLOSED,2018-05-09T06:28:14Z,2018-05-09T17:21:39Z, make size_of_val and align_of_val const fns ,Gankra,NA,NA,NA,THUMBS_DOWN,2018-05-09T08:57:47Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/50564,MERGED,2018-05-09T10:16:50Z,2018-05-11T02:03:46Z,Inline `Span` methods.,nnethercote,77c40f8c6f8cc472f6438f7724d60bf3b7718a0c,1,Inline `Span` methods. Because they are simple and hot. This change speeds up some incremental runs of a few rustc-perf benchmarks the best by 3%.,HOORAY,2018-05-09T10:45:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50564,MERGED,2018-05-09T10:16:50Z,2018-05-11T02:03:46Z,Inline `Span` methods.,nnethercote,77c40f8c6f8cc472f6438f7724d60bf3b7718a0c,1,Inline `Span` methods. Because they are simple and hot. This change speeds up some incremental runs of a few rustc-perf benchmarks the best by 3%.,HOORAY,2018-05-09T23:35:42Z,estebank,NA https://github.com/rust-lang/rust/pull/50564,MERGED,2018-05-09T10:16:50Z,2018-05-11T02:03:46Z,Inline `Span` methods.,nnethercote,77c40f8c6f8cc472f6438f7724d60bf3b7718a0c,1,Inline `Span` methods. Because they are simple and hot. This change speeds up some incremental runs of a few rustc-perf benchmarks the best by 3%.,HOORAY,2018-05-16T13:15:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50565,MERGED,2018-05-09T10:38:41Z,2018-05-11T02:03:47Z,Use SmallVec for DepNodeIndex within dep_graph.,nnethercote,78262e700dc6a7b57e376742f344e80115d2d3f2,1,Use SmallVec for DepNodeIndex within dep_graph. This avoids a decent number of allocations enough to speed up incremental runs of many rustc-benchmarks the best by 2%.,HEART,2018-05-09T19:53:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50565,MERGED,2018-05-09T10:38:41Z,2018-05-11T02:03:47Z,Use SmallVec for DepNodeIndex within dep_graph.,nnethercote,78262e700dc6a7b57e376742f344e80115d2d3f2,1,Use SmallVec for DepNodeIndex within dep_graph. This avoids a decent number of allocations enough to speed up incremental runs of many rustc-benchmarks the best by 2%.,HEART,2020-05-14T10:16:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-09T16:22:22Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-09T17:56:34Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-09T18:21:04Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-09T18:21:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-09T22:57:20Z,nnethercote,NA https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-10T19:06:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-16T09:54:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-16T13:17:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50575,MERGED,2018-05-09T16:11:20Z,2018-05-11T02:03:49Z,std: Avoid `ptr::copy` if unnecessary in `vec::Drain`,alexcrichton,254b6014d20f51a3e91b88c24a8f19e31f17acc9,1,"std: Avoid `ptr::copy` if unnecessary in `vec::Drain` This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was ""fast"" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length but under the hood memmove was being called a lot causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24 exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3",HEART,2018-05-18T06:00:35Z,hcpl,NA https://github.com/rust-lang/rust/pull/50593,MERGED,2018-05-10T02:26:17Z,2018-05-18T00:09:51Z,stop considering location when computing outlives relationships,nikomatsakis,a64ef13a061b198d2a2d3bb26c7c622d7931b2c3,1,fix test region-liveness-two-disjoint-uses We no longer get two disjoint uses. =),THUMBS_UP,2018-05-23T03:38:31Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/50593,MERGED,2018-05-10T02:26:17Z,2018-05-18T00:09:51Z,stop considering location when computing outlives relationships,nikomatsakis,a64ef13a061b198d2a2d3bb26c7c622d7931b2c3,1,fix test region-liveness-two-disjoint-uses We no longer get two disjoint uses. =),THUMBS_UP,2018-05-24T03:18:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50593,MERGED,2018-05-10T02:26:17Z,2018-05-18T00:09:51Z,stop considering location when computing outlives relationships,nikomatsakis,a64ef13a061b198d2a2d3bb26c7c622d7931b2c3,1,fix test region-liveness-two-disjoint-uses We no longer get two disjoint uses. =),CONFUSED,2018-06-19T03:13:01Z,tinaun,NA https://github.com/rust-lang/rust/pull/50597,CLOSED,2018-05-10T06:06:58Z,2018-07-07T16:11:45Z,Add TryFrom<{integer}> for bool,ithinuel,NA,NA,NA,THUMBS_DOWN,2018-05-10T07:35:30Z,UtherII,NA https://github.com/rust-lang/rust/pull/50597,CLOSED,2018-05-10T06:06:58Z,2018-07-07T16:11:45Z,Add TryFrom<{integer}> for bool,ithinuel,NA,NA,NA,THUMBS_DOWN,2018-05-15T00:51:40Z,dgrunwald,daniel@danielgrunwald.de https://github.com/rust-lang/rust/pull/50610,MERGED,2018-05-10T16:14:58Z,2018-05-18T05:23:36Z,Improve format string errors,estebank,3f6b3bbace466f4be1311192f335c4c7792a83d2,5,Improve format string errors - Point at format string position inside the formatting string - Explain that argument names can't start with an underscore,THUMBS_UP,2018-05-10T18:04:01Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50615,MERGED,2018-05-10T17:26:43Z,2018-05-17T16:44:49Z,Rename trans to codegen everywhere.,irinagpopa,b63d7e2b1c4019e40051036bcb1fd5f254a8f6e2,264,Rename trans to codegen everywhere.,HOORAY,2018-05-15T13:42:54Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50620,MERGED,2018-05-10T18:30:14Z,2018-05-11T09:45:12Z,Rename the 2018 edition lint names,alexcrichton,d636aec3514874274f2acc8a6897c451ac380d1f,2,Rename the 2018 edition lint names * `rust_2018_breakage` -> `rust_2018_compatibility` - the lint for ensuring that your code in the 2015 edition is compatible with the 2018 edition's semantics. This is required to pass *before* you enable the 2018 edition. * `rust_2018_migration` -> `rust_2018_idioms` - the lint for writing idiomatic code after you've already enabled the 2018 edition,THUMBS_UP,2018-05-10T20:21:44Z,killercup,NA https://github.com/rust-lang/rust/pull/50629,MERGED,2018-05-10T20:17:41Z,2018-05-17T19:32:38Z,Switch to bootstrapping from 1.27,Mark-Simulacrum,a22af69c8f5b3838a8822b9e6dbe2199cfb8f297,1,Remove MAKEFLAGS to prevent accidental inheritance,HOORAY,2018-05-11T02:10:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50630,MERGED,2018-05-10T20:24:13Z,2018-06-26T05:56:18Z,Fix possibly endless loop in ReadDir iterator,sharkdp,af75314ecdbc5564f300467e732fdb5c923a873a,1,Fix possibly endless loop in ReadDir iterator Certain directories in `/proc` can cause the `ReadDir` iterator to loop indefinitely. We get an error code (22) when calling libc's `readdir_r` on these directories but `entry_ptr` is `NULL` at the same time signalling the end of the directory stream. This change introduces an internal state to the iterator such that the `Some(Err(..))` value will only be returned once when calling `next`. Subsequent calls will return `None`. fixes #50619,HOORAY,2018-05-11T12:11:50Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/50630,MERGED,2018-05-10T20:24:13Z,2018-06-26T05:56:18Z,Fix possibly endless loop in ReadDir iterator,sharkdp,af75314ecdbc5564f300467e732fdb5c923a873a,1,Fix possibly endless loop in ReadDir iterator Certain directories in `/proc` can cause the `ReadDir` iterator to loop indefinitely. We get an error code (22) when calling libc's `readdir_r` on these directories but `entry_ptr` is `NULL` at the same time signalling the end of the directory stream. This change introduces an internal state to the iterator such that the `Some(Err(..))` value will only be returned once when calling `next`. Subsequent calls will return `None`. fixes #50619,HOORAY,2018-07-06T20:45:12Z,frol,NA https://github.com/rust-lang/rust/pull/50630,MERGED,2018-05-10T20:24:13Z,2018-06-26T05:56:18Z,Fix possibly endless loop in ReadDir iterator,sharkdp,af75314ecdbc5564f300467e732fdb5c923a873a,1,Fix possibly endless loop in ReadDir iterator Certain directories in `/proc` can cause the `ReadDir` iterator to loop indefinitely. We get an error code (22) when calling libc's `readdir_r` on these directories but `entry_ptr` is `NULL` at the same time signalling the end of the directory stream. This change introduces an internal state to the iterator such that the `Some(Err(..))` value will only be returned once when calling `next`. Subsequent calls will return `None`. fixes #50619,HOORAY,2018-07-07T22:54:07Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/50638,MERGED,2018-05-10T23:50:50Z,2018-05-17T04:52:25Z,Don't unconditionally set CLOEXEC twice on every fd we open on Linux,tbu-,6d1da8232997af4b785486329f01995440818920,2,Don't unconditionally set CLOEXEC twice on every fd we open on Linux Previously every `open64` was accompanied by a `ioctl(… FIOCLEX)` because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now we check whether the `CLOEXEC` flag is set on the first file we open – if it is we won't do extra syscalls for every opened file. If it is not set we fall back to the old behavior of unconditionally calling `ioctl(… FIOCLEX)` on newly opened files. On old Linuxes this amounts to one extra syscall per process namely the `fcntl(… F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes this reduces the number of syscalls per opened file by one except for the first file where it does the same number of syscalls as before (`fcntl(… F_GETFD)` to check the flag instead of `ioctl(… FIOCLEX)` to set it).,THUMBS_UP,2018-05-12T16:07:59Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50638,MERGED,2018-05-10T23:50:50Z,2018-05-17T04:52:25Z,Don't unconditionally set CLOEXEC twice on every fd we open on Linux,tbu-,6d1da8232997af4b785486329f01995440818920,2,Don't unconditionally set CLOEXEC twice on every fd we open on Linux Previously every `open64` was accompanied by a `ioctl(… FIOCLEX)` because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now we check whether the `CLOEXEC` flag is set on the first file we open – if it is we won't do extra syscalls for every opened file. If it is not set we fall back to the old behavior of unconditionally calling `ioctl(… FIOCLEX)` on newly opened files. On old Linuxes this amounts to one extra syscall per process namely the `fcntl(… F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes this reduces the number of syscalls per opened file by one except for the first file where it does the same number of syscalls as before (`fcntl(… F_GETFD)` to check the flag instead of `ioctl(… FIOCLEX)` to set it).,THUMBS_UP,2018-05-24T03:25:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50656,MERGED,2018-05-11T14:30:49Z,2018-05-17T04:52:26Z,Fix `fn main() -> impl Trait` for non-`Termination` trait,leoyvens,0582d025e80e4557d7b9e1642ddec3f0188a1aac,1,Rename ret_ty to declared_ret_ty,THUMBS_UP,2018-05-11T22:52:54Z,estebank,NA https://github.com/rust-lang/rust/pull/50656,MERGED,2018-05-11T14:30:49Z,2018-05-17T04:52:26Z,Fix `fn main() -> impl Trait` for non-`Termination` trait,leoyvens,0582d025e80e4557d7b9e1642ddec3f0188a1aac,1,Rename ret_ty to declared_ret_ty,HEART,2018-05-12T02:31:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50656,MERGED,2018-05-11T14:30:49Z,2018-05-17T04:52:26Z,Fix `fn main() -> impl Trait` for non-`Termination` trait,leoyvens,0582d025e80e4557d7b9e1642ddec3f0188a1aac,1,Rename ret_ty to declared_ret_ty,THUMBS_UP,2018-05-12T02:31:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50656,MERGED,2018-05-11T14:30:49Z,2018-05-17T04:52:26Z,Fix `fn main() -> impl Trait` for non-`Termination` trait,leoyvens,0582d025e80e4557d7b9e1642ddec3f0188a1aac,1,Rename ret_ty to declared_ret_ty,THUMBS_UP,2018-05-14T18:29:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/50656,MERGED,2018-05-11T14:30:49Z,2018-05-17T04:52:26Z,Fix `fn main() -> impl Trait` for non-`Termination` trait,leoyvens,0582d025e80e4557d7b9e1642ddec3f0188a1aac,1,Rename ret_ty to declared_ret_ty,THUMBS_UP,2018-05-24T03:20:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50684,MERGED,2018-05-12T12:22:44Z,2018-05-12T18:45:25Z,Set PrepareForThinLTO flag when using ThinLTO,nikic,a70ef4cb49295563a09b254de4751c016c79e262,4,Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes which ensures that all globals have a name. * In optimized builds a number of late passes (mainly related to vectorization and unrolling) are disabled on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479 which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs this might have performance (or other) impact so we want to land this separately.,HEART,2018-05-12T15:31:11Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50684,MERGED,2018-05-12T12:22:44Z,2018-05-12T18:45:25Z,Set PrepareForThinLTO flag when using ThinLTO,nikic,a70ef4cb49295563a09b254de4751c016c79e262,4,Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes which ensures that all globals have a name. * In optimized builds a number of late passes (mainly related to vectorization and unrolling) are disabled on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479 which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs this might have performance (or other) impact so we want to land this separately.,HEART,2018-05-12T16:08:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50684,MERGED,2018-05-12T12:22:44Z,2018-05-12T18:45:25Z,Set PrepareForThinLTO flag when using ThinLTO,nikic,a70ef4cb49295563a09b254de4751c016c79e262,4,Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes which ensures that all globals have a name. * In optimized builds a number of late passes (mainly related to vectorization and unrolling) are disabled on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479 which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs this might have performance (or other) impact so we want to land this separately.,HEART,2018-05-12T18:09:27Z,lqd,NA https://github.com/rust-lang/rust/pull/50684,MERGED,2018-05-12T12:22:44Z,2018-05-12T18:45:25Z,Set PrepareForThinLTO flag when using ThinLTO,nikic,a70ef4cb49295563a09b254de4751c016c79e262,4,Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes which ensures that all globals have a name. * In optimized builds a number of late passes (mainly related to vectorization and unrolling) are disabled on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479 which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs this might have performance (or other) impact so we want to land this separately.,HEART,2018-05-16T13:04:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50684,MERGED,2018-05-12T12:22:44Z,2018-05-12T18:45:25Z,Set PrepareForThinLTO flag when using ThinLTO,nikic,a70ef4cb49295563a09b254de4751c016c79e262,4,Set PrepareForThinLTO flag when using ThinLTO The LLVM PassManager has a PrepareForThinLTO flag which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes which ensures that all globals have a name. * In optimized builds a number of late passes (mainly related to vectorization and unrolling) are disabled on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479 which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs this might have performance (or other) impact so we want to land this separately.,HEART,2018-05-17T10:03:06Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50699,MERGED,2018-05-12T22:34:15Z,2018-06-07T01:11:50Z,Blocking Rayon queries,Zoxc,f273f285b887e84471eaae5d841e125eec197186,1,Update Cargo,THUMBS_UP,2018-05-13T17:32:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50699,MERGED,2018-05-12T22:34:15Z,2018-06-07T01:11:50Z,Blocking Rayon queries,Zoxc,f273f285b887e84471eaae5d841e125eec197186,1,Update Cargo,HEART,2018-05-16T08:59:53Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50699,MERGED,2018-05-12T22:34:15Z,2018-06-07T01:11:50Z,Blocking Rayon queries,Zoxc,f273f285b887e84471eaae5d841e125eec197186,1,Update Cargo,THUMBS_UP,2018-06-14T11:45:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50709,MERGED,2018-05-13T14:46:20Z,2018-05-19T05:49:39Z,Revert #50105 until regression is fixed,alexcrichton,acc874fbcda98bb5ec95399bea76b9f83227b758,1,"Revert ""bootstrap.py: respect crt-static"" This reverts commit 5ecf29df052c7eca10fccc96f4179d338fe0014e.",HEART,2018-05-13T14:49:19Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/50710,MERGED,2018-05-13T15:03:29Z,2018-05-16T23:46:41Z,Fix conversion from Miri Value to ConstValue,Zoxc,41a032db9050941e19fec7f3409de00ae175848d,2,Fix conversion from Miri Value to ConstValue,THUMBS_UP,2018-05-16T17:31:42Z,nayato,NA https://github.com/rust-lang/rust/pull/50713,MERGED,2018-05-13T16:47:41Z,2018-05-22T23:51:37Z,Update rustfix,killercup,7a738564d746d7b4235300958b4e49a05896bb80,3,Update compiltest to use rustfix 0.3.1,THUMBS_UP,2018-05-13T17:34:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50733,MERGED,2018-05-14T05:19:50Z,2018-05-15T15:50:11Z,Hyperlink DOI against preferred resolver,katrinleinweber,703ecebe02333014e6c948370042db9df696d818,1,Hyperlink DOI against preferred resolver https://www.doi.org/doi_handbook/3_Resolution.html#3.8,THUMBS_UP,2018-05-15T08:54:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50739,MERGED,2018-05-14T12:08:19Z,2018-05-21T08:34:16Z,Switch Vec from doubling size on growth to using RawVec's reserve,gnzlbg,50c4506329673d38b3170f048f546a5885dd8310,1,Switch Vec from doubling size on growth to using RawVec's reserve On growth Vec does not require to exactly double its size for correctness like for example VecDeque does. Using reserve instead better expresses this intent. It also allows to reuse Excess capacity on growth and for better growth-policies to be provided by RawVec.,THUMBS_UP,2018-05-31T12:28:18Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50740,MERGED,2018-05-14T12:30:50Z,2018-05-17T04:52:30Z,Remove LazyBTreeMap.,nnethercote,f46b888f73d66149f1abe424489722283f60d6e1,5,Remove LazyBTreeMap. It was introduced in #50240 to avoid an allocation when creating a new BTreeMap which gave some speed-ups. But then #50352 made that the default behaviour for BTreeMap so LazyBTreeMap is no longer necessary.,THUMBS_UP,2018-05-14T14:14:51Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50740,MERGED,2018-05-14T12:30:50Z,2018-05-17T04:52:30Z,Remove LazyBTreeMap.,nnethercote,f46b888f73d66149f1abe424489722283f60d6e1,5,Remove LazyBTreeMap. It was introduced in #50240 to avoid an allocation when creating a new BTreeMap which gave some speed-ups. But then #50352 made that the default behaviour for BTreeMap so LazyBTreeMap is no longer necessary.,THUMBS_UP,2018-05-14T19:13:39Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/50740,MERGED,2018-05-14T12:30:50Z,2018-05-17T04:52:30Z,Remove LazyBTreeMap.,nnethercote,f46b888f73d66149f1abe424489722283f60d6e1,5,Remove LazyBTreeMap. It was introduced in #50240 to avoid an allocation when creating a new BTreeMap which gave some speed-ups. But then #50352 made that the default behaviour for BTreeMap so LazyBTreeMap is no longer necessary.,HEART,2018-05-15T06:05:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50740,MERGED,2018-05-14T12:30:50Z,2018-05-17T04:52:30Z,Remove LazyBTreeMap.,nnethercote,f46b888f73d66149f1abe424489722283f60d6e1,5,Remove LazyBTreeMap. It was introduced in #50240 to avoid an allocation when creating a new BTreeMap which gave some speed-ups. But then #50352 made that the default behaviour for BTreeMap so LazyBTreeMap is no longer necessary.,THUMBS_UP,2018-05-15T22:16:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50740,MERGED,2018-05-14T12:30:50Z,2018-05-17T04:52:30Z,Remove LazyBTreeMap.,nnethercote,f46b888f73d66149f1abe424489722283f60d6e1,5,Remove LazyBTreeMap. It was introduced in #50240 to avoid an allocation when creating a new BTreeMap which gave some speed-ups. But then #50352 made that the default behaviour for BTreeMap so LazyBTreeMap is no longer necessary.,THUMBS_UP,2020-08-26T14:59:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/50741,MERGED,2018-05-14T13:20:34Z,2018-05-15T18:45:12Z,[beta] Process backports,pietroalbini,eee8802ceb24eee99394e629bac5883b67da7fa5,2,Fix self referential impl Trait substitutions A high impact bug because a lot of common traits use a `Self` substitution by default. Should be backported to beta. There was a check for this which wasn't catching all cases it was made more robust. Fixes #49376 Fixes #50626 r? @petrochenkov,HEART,2018-05-14T14:00:35Z,kennytm,NA https://github.com/rust-lang/rust/pull/50743,CLOSED,2018-05-14T13:33:28Z,2018-06-04T10:23:02Z,Make NonNull::dangling a const fn.,lachlansneff,NA,NA,NA,THUMBS_UP,2018-05-15T08:55:49Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-14T14:13:39Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-14T21:26:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-14T21:33:31Z,lqd,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-14T22:29:48Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-15T12:21:33Z,Lymia,lymia@lymiahugs.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-15T15:31:48Z,delacian,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-19T17:58:09Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-20T18:07:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-21T14:54:51Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-21T15:23:30Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T01:16:07Z,tikue,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T02:09:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T03:25:23Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T06:13:02Z,bitshifter,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T06:24:07Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T06:52:29Z,Thiez,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T09:20:46Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T12:12:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T12:41:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T14:46:48Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T15:14:24Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T15:25:41Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T17:59:17Z,TyOverby,ty@pre-alpha.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T19:06:39Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-23T20:32:13Z,mcarton,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-24T03:15:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,THUMBS_UP,2018-05-24T05:01:05Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-24T17:08:09Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-24T18:26:01Z,johnthagen,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-25T00:10:48Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-25T00:42:54Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-25T03:41:09Z,bstrie,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-28T11:59:40Z,krdln,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-28T14:04:50Z,pythonesque,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-05-30T16:17:19Z,hcpl,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-06-19T21:10:57Z,novacrazy,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-06-27T23:24:31Z,L-as,me@las.rs https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-06-29T00:54:26Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-08-06T20:03:28Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,THUMBS_UP,2018-08-06T20:03:30Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2018-08-06T23:37:07Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2019-03-26T13:10:00Z,jfbaro,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2020-03-30T17:40:02Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,THUMBS_UP,2021-07-23T19:54:38Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/50744,MERGED,2018-05-14T13:57:02Z,2018-05-19T10:04:52Z,Emit noalias on &mut parameters by default,nikic,12308139ec76dfa050ed012606495250391aaf74,3,Emit noalias on &mut parameters by default This used to be disabled due to LLVM bugs in the handling of noalias information in conjunction with unwinding. However according to #31681 all known LLVM bugs have been fixed by LLVM 6.0 so it's probably time to reenable this optimization. Noalias annotations will not be emitted by default if either -C panic=abort (as previously) or LLVM >= 6.0 (new). -Z mutable-noalias=no is left as an escape-hatch to allow debugging problems suspected to stem from this change.,HOORAY,2021-07-23T19:54:39Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/50760,MERGED,2018-05-14T23:58:33Z,2018-05-19T14:52:43Z,Turn deprecation lint `legacy_imports` into a hard error,petrochenkov,d1b027421edb0c559ed0840174b83dfa3bcab7ce,9,Turn deprecation lint `legacy_imports` into a hard error,THUMBS_UP,2018-05-15T11:21:04Z,qnighy,NA https://github.com/rust-lang/rust/pull/50760,MERGED,2018-05-14T23:58:33Z,2018-05-19T14:52:43Z,Turn deprecation lint `legacy_imports` into a hard error,petrochenkov,d1b027421edb0c559ed0840174b83dfa3bcab7ce,9,Turn deprecation lint `legacy_imports` into a hard error,HOORAY,2018-05-15T11:21:08Z,qnighy,NA https://github.com/rust-lang/rust/pull/50760,MERGED,2018-05-14T23:58:33Z,2018-05-19T14:52:43Z,Turn deprecation lint `legacy_imports` into a hard error,petrochenkov,d1b027421edb0c559ed0840174b83dfa3bcab7ce,9,Turn deprecation lint `legacy_imports` into a hard error,THUMBS_UP,2018-05-24T03:16:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50762,CLOSED,2018-05-15T05:03:53Z,2018-05-17T10:52:41Z,Use Vec::with_capacity(1) in a couple of places.,nnethercote,NA,NA,NA,HOORAY,2018-05-15T05:25:47Z,est31,NA https://github.com/rust-lang/rust/pull/50762,CLOSED,2018-05-15T05:03:53Z,2018-05-17T10:52:41Z,Use Vec::with_capacity(1) in a couple of places.,nnethercote,NA,NA,NA,HEART,2018-05-15T06:04:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50762,CLOSED,2018-05-15T05:03:53Z,2018-05-17T10:52:41Z,Use Vec::with_capacity(1) in a couple of places.,nnethercote,NA,NA,NA,HEART,2018-05-15T08:20:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50762,CLOSED,2018-05-15T05:03:53Z,2018-05-17T10:52:41Z,Use Vec::with_capacity(1) in a couple of places.,nnethercote,NA,NA,NA,HOORAY,2018-05-15T22:57:33Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/50763,MERGED,2018-05-15T06:40:18Z,2018-05-19T17:04:00Z,Add lint checks for unused loop labels,kylestach,6da64a7666e89b39b99d728aaa3a40c124f31563,4,"Default `unused_labels` to allow move to ""unused""",HOORAY,2018-05-16T07:02:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50763,MERGED,2018-05-15T06:40:18Z,2018-05-19T17:04:00Z,Add lint checks for unused loop labels,kylestach,6da64a7666e89b39b99d728aaa3a40c124f31563,4,"Default `unused_labels` to allow move to ""unused""",THUMBS_UP,2018-05-19T17:14:13Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50766,CLOSED,2018-05-15T08:36:45Z,2018-08-03T14:27:09Z,mark std::string::String::new() and std::vec::Vec::new() as #[must_use].,matthiaskrgr,NA,NA,NA,THUMBS_UP,2018-05-15T22:00:31Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50770,CLOSED,2018-05-15T13:00:19Z,2018-06-04T11:53:52Z,Add existential type syntax,oli-obk,NA,NA,NA,HOORAY,2018-05-15T17:18:58Z,cramertj,NA https://github.com/rust-lang/rust/pull/50771,CLOSED,2018-05-15T14:25:47Z,2018-06-04T10:22:29Z,Add Content Security Policy to default,mozfreddyb,NA,NA,NA,HOORAY,2018-05-15T22:55:12Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2018-05-15T16:03:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,HOORAY,2018-05-15T22:07:08Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2018-06-06T12:38:26Z,mati865,NA https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2018-06-22T07:58:55Z,astamatto,astamatto@gmail.com https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,HOORAY,2018-06-22T07:58:57Z,astamatto,astamatto@gmail.com https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2018-06-22T11:14:24Z,frol,NA https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2018-06-22T11:43:56Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,HOORAY,2018-06-22T11:43:56Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/50772,MERGED,2018-05-15T14:28:32Z,2018-05-30T02:12:04Z,fs: copy: use copy_file_range on Linux,nicokoch,c7d6a0130b6b76b65982916198e7de2b348f9718,1,Fix additional nits: - compute bytes_to_copy more elegantly - add assert that written is 0 in fallback case,THUMBS_UP,2021-04-16T22:37:35Z,chpio,NA https://github.com/rust-lang/rust/pull/50774,CLOSED,2018-05-15T16:44:00Z,2018-05-29T17:21:05Z,Add compensated_add for floats,clarfonthey,NA,NA,NA,THUMBS_UP,2018-05-15T22:08:46Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50774,CLOSED,2018-05-15T16:44:00Z,2018-05-29T17:21:05Z,Add compensated_add for floats,clarfonthey,NA,NA,NA,CONFUSED,2018-05-16T08:49:07Z,kennytm,NA https://github.com/rust-lang/rust/pull/50777,CLOSED,2018-05-15T18:24:10Z,2018-05-17T20:58:31Z,[Do not merge perf only] Try enabling NewGVN,nikic,NA,NA,NA,HOORAY,2018-05-15T22:09:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50777,CLOSED,2018-05-15T18:24:10Z,2018-05-17T20:58:31Z,[Do not merge perf only] Try enabling NewGVN,nikic,NA,NA,NA,HEART,2018-05-16T12:39:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50777,CLOSED,2018-05-15T18:24:10Z,2018-05-17T20:58:31Z,[Do not merge perf only] Try enabling NewGVN,nikic,NA,NA,NA,HOORAY,2018-05-17T13:56:17Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50789,MERGED,2018-05-16T01:05:50Z,2018-05-17T04:52:34Z,Ensure libraries built in stage0 have unique metadata,cuviper,e8e5eb58c0d6890f73ea01354e18f51b1a6697f8,1,"Ensure libraries built in stage0 have unique metadata Issue #50786 shows a case with local rebuild where the libraries built by stage0 had the same suffix as stage0's own and were accidentally loaded by that stage0 rustc when compiling `librustc_trans`. Now we set `__CARGO_DEFAULT_LIB_METADATA` to ""bootstrap"" during stage0 rather than the release channel like usual so the library suffix will always be completely distinct from the stage0 compiler.",HEART,2018-05-16T08:08:25Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50793,MERGED,2018-05-16T02:28:54Z,2018-05-17T04:52:35Z,tidy: Add a check for empty UI test files,yaahc,6ed200aaeabb7ab2e12c6fd2a52627bd3f457a95,1,Remove empty file introduced by rebase,HEART,2018-05-17T20:26:59Z,estebank,NA https://github.com/rust-lang/rust/pull/50800,CLOSED,2018-05-16T08:36:12Z,2018-07-21T18:55:42Z,adds Default impl for Instant,jonathanstrong,NA,NA,NA,THUMBS_UP,2018-05-16T18:44:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50801,MERGED,2018-05-16T10:12:51Z,2018-05-21T19:38:08Z,Quick refactoring around Substs & friends.,eddyb,73f62106ad9f9bf10962bf10540510ec914ee305,25,rustc: move TypeParamDef's fields into GenericParamDefKind::Type.,THUMBS_UP,2018-05-16T12:29:23Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50801,MERGED,2018-05-16T10:12:51Z,2018-05-21T19:38:08Z,Quick refactoring around Substs & friends.,eddyb,73f62106ad9f9bf10962bf10540510ec914ee305,25,rustc: move TypeParamDef's fields into GenericParamDefKind::Type.,HEART,2018-05-16T12:43:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50801,MERGED,2018-05-16T10:12:51Z,2018-05-21T19:38:08Z,Quick refactoring around Substs & friends.,eddyb,73f62106ad9f9bf10962bf10540510ec914ee305,25,rustc: move TypeParamDef's fields into GenericParamDefKind::Type.,THUMBS_UP,2018-05-16T12:56:13Z,varkor,NA https://github.com/rust-lang/rust/pull/50805,CLOSED,2018-05-16T14:57:53Z,2018-07-03T15:45:09Z,Add a lint for unused const fn results,est31,NA,NA,NA,THUMBS_UP,2018-05-16T16:34:48Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/50805,CLOSED,2018-05-16T14:57:53Z,2018-07-03T15:45:09Z,Add a lint for unused const fn results,est31,NA,NA,NA,THUMBS_UP,2018-05-17T05:04:24Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50805,CLOSED,2018-05-16T14:57:53Z,2018-07-03T15:45:09Z,Add a lint for unused const fn results,est31,NA,NA,NA,HOORAY,2018-05-18T05:19:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50805,CLOSED,2018-05-16T14:57:53Z,2018-07-03T15:45:09Z,Add a lint for unused const fn results,est31,NA,NA,NA,THUMBS_UP,2018-05-28T08:57:05Z,frol,NA https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HOORAY,2018-05-16T15:24:03Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HOORAY,2018-05-16T16:44:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HOORAY,2018-05-16T20:25:30Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HOORAY,2018-05-17T07:59:11Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HOORAY,2018-05-18T05:17:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50806,MERGED,2018-05-16T15:19:29Z,2018-05-18T05:23:43Z,Add `bless` x.py subcommand for easy ui test replacement,oli-obk,0ac2fd1ce2917e3e5f1845ff8d319d03181b244b,2,Update docs and diagnostics,HEART,2018-06-09T13:45:11Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50808,MERGED,2018-05-16T16:10:14Z,2018-05-17T04:52:38Z,Stabilize num::NonZeroU*,SimonSapin,89d9ca9b50e01cbc5dc78a26f15cc8c435bbc5a4,11,Stabilize num::NonZeroU* Tracking issue: https://github.com/rust-lang/rust/issues/49137,HOORAY,2018-05-17T20:24:13Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/50808,MERGED,2018-05-16T16:10:14Z,2018-05-17T04:52:38Z,Stabilize num::NonZeroU*,SimonSapin,89d9ca9b50e01cbc5dc78a26f15cc8c435bbc5a4,11,Stabilize num::NonZeroU* Tracking issue: https://github.com/rust-lang/rust/issues/49137,HOORAY,2018-05-23T12:19:10Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50821,CLOSED,2018-05-17T04:31:40Z,2018-06-12T17:08:02Z,WIP: add raw_entry API to HashMap,Gankra,NA,NA,NA,THUMBS_UP,2018-05-18T10:25:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50821,CLOSED,2018-05-17T04:31:40Z,2018-06-12T17:08:02Z,WIP: add raw_entry API to HashMap,Gankra,NA,NA,NA,THUMBS_UP,2018-06-04T17:57:24Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/50821,CLOSED,2018-05-17T04:31:40Z,2018-06-12T17:08:02Z,WIP: add raw_entry API to HashMap,Gankra,NA,NA,NA,THUMBS_UP,2018-06-07T00:58:53Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/50821,CLOSED,2018-05-17T04:31:40Z,2018-06-12T17:08:02Z,WIP: add raw_entry API to HashMap,Gankra,NA,NA,NA,HEART,2018-07-03T05:50:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/50827,MERGED,2018-05-17T09:14:31Z,2018-05-20T00:49:46Z,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97,nox,032831da7882909fc575651bd341acce360143ef,2,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97 This brings in https://github.com/rust-lang/llvm/pull/115 which fixes https://github.com/rust-lang/rust/issues/49873.,HEART,2018-05-17T13:02:07Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50827,MERGED,2018-05-17T09:14:31Z,2018-05-20T00:49:46Z,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97,nox,032831da7882909fc575651bd341acce360143ef,2,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97 This brings in https://github.com/rust-lang/llvm/pull/115 which fixes https://github.com/rust-lang/rust/issues/49873.,THUMBS_UP,2018-05-18T10:25:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50827,MERGED,2018-05-17T09:14:31Z,2018-05-20T00:49:46Z,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97,nox,032831da7882909fc575651bd341acce360143ef,2,Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97 This brings in https://github.com/rust-lang/llvm/pull/115 which fixes https://github.com/rust-lang/rust/issues/49873.,THUMBS_UP,2018-05-24T03:16:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50839,MERGED,2018-05-17T16:50:51Z,2018-05-18T05:23:46Z,Make sure people know the book is free oline,glassresistor,cfa26da963790dd59cdd6f6dc0005e83ccfc4ec5,1,Update tutorial.md,HEART,2018-05-18T05:15:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-18T05:10:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-18T09:22:34Z,killercup,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-18T10:26:48Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-18T16:20:06Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-18T16:31:02Z,estebank,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-19T07:02:03Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-19T12:15:44Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-19T13:00:35Z,qnighy,NA https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-19T21:44:00Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/50850,CLOSED,2018-05-17T22:10:30Z,2018-06-04T18:21:10Z,[WIP] async functions,withoutboats,NA,NA,NA,HOORAY,2018-05-21T07:24:45Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HOORAY,2018-05-18T01:34:24Z,est31,NA https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HOORAY,2018-05-18T01:56:48Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HOORAY,2018-05-18T07:19:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HEART,2018-05-18T12:43:55Z,varkor,NA https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HOORAY,2018-05-18T12:53:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HEART,2018-05-18T19:28:04Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/50851,MERGED,2018-05-18T00:18:53Z,2018-05-21T01:23:30Z,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",eddyb,26aad254875464ff352a4e18d16f668b5bd9b7cb,35,"rustc: introduce {ast hir}::AnonConst to consolidate so-called ""embedded constants"".",HOORAY,2018-05-24T03:19:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50854,MERGED,2018-05-18T08:03:01Z,2018-05-20T00:49:49Z,in which the unused shorthand field pattern debacle/saga continues,zackmdavis,59782f4829db1afed5a3d50d03709711b8dd16e0,3,in which the unused shorthand field pattern debacle/saga continues In e4b1a79 (#47922) we corrected erroneous suggestions for unused shorthand field pattern bindings suggesting `field: _` where the previous suggestion of `_field` wouldn't even have compiled (#47390). Soon it was revealed that this was insufficient (#50303) and the fix was extended to references slices &c. (#50327) But even this proved inadequate as the erroneous suggestions were still being issued for patterns in local (`let`) bindings (#50804). Here we yank the shorthand-detection and variable/node registration code into a new common function that can be called while visiting both match arms and `let` bindings. Resolves #50804.,THUMBS_UP,2018-05-18T13:15:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50854,MERGED,2018-05-18T08:03:01Z,2018-05-20T00:49:49Z,in which the unused shorthand field pattern debacle/saga continues,zackmdavis,59782f4829db1afed5a3d50d03709711b8dd16e0,3,in which the unused shorthand field pattern debacle/saga continues In e4b1a79 (#47922) we corrected erroneous suggestions for unused shorthand field pattern bindings suggesting `field: _` where the previous suggestion of `_field` wouldn't even have compiled (#47390). Soon it was revealed that this was insufficient (#50303) and the fix was extended to references slices &c. (#50327) But even this proved inadequate as the erroneous suggestions were still being issued for patterns in local (`let`) bindings (#50804). Here we yank the shorthand-detection and variable/node registration code into a new common function that can be called while visiting both match arms and `let` bindings. Resolves #50804.,THUMBS_UP,2018-05-18T16:23:31Z,estebank,NA https://github.com/rust-lang/rust/pull/50854,MERGED,2018-05-18T08:03:01Z,2018-05-20T00:49:49Z,in which the unused shorthand field pattern debacle/saga continues,zackmdavis,59782f4829db1afed5a3d50d03709711b8dd16e0,3,in which the unused shorthand field pattern debacle/saga continues In e4b1a79 (#47922) we corrected erroneous suggestions for unused shorthand field pattern bindings suggesting `field: _` where the previous suggestion of `_field` wouldn't even have compiled (#47390). Soon it was revealed that this was insufficient (#50303) and the fix was extended to references slices &c. (#50327) But even this proved inadequate as the erroneous suggestions were still being issued for patterns in local (`let`) bindings (#50804). Here we yank the shorthand-detection and variable/node registration code into a new common function that can be called while visiting both match arms and `let` bindings. Resolves #50804.,HEART,2018-05-18T16:25:18Z,estebank,NA https://github.com/rust-lang/rust/pull/50854,MERGED,2018-05-18T08:03:01Z,2018-05-20T00:49:49Z,in which the unused shorthand field pattern debacle/saga continues,zackmdavis,59782f4829db1afed5a3d50d03709711b8dd16e0,3,in which the unused shorthand field pattern debacle/saga continues In e4b1a79 (#47922) we corrected erroneous suggestions for unused shorthand field pattern bindings suggesting `field: _` where the previous suggestion of `_field` wouldn't even have compiled (#47390). Soon it was revealed that this was insufficient (#50303) and the fix was extended to references slices &c. (#50327) But even this proved inadequate as the erroneous suggestions were still being issued for patterns in local (`let`) bindings (#50804). Here we yank the shorthand-detection and variable/node registration code into a new common function that can be called while visiting both match arms and `let` bindings. Resolves #50804.,THUMBS_UP,2018-11-29T05:46:39Z,hcpl,NA https://github.com/rust-lang/rust/pull/50854,MERGED,2018-05-18T08:03:01Z,2018-05-20T00:49:49Z,in which the unused shorthand field pattern debacle/saga continues,zackmdavis,59782f4829db1afed5a3d50d03709711b8dd16e0,3,in which the unused shorthand field pattern debacle/saga continues In e4b1a79 (#47922) we corrected erroneous suggestions for unused shorthand field pattern bindings suggesting `field: _` where the previous suggestion of `_field` wouldn't even have compiled (#47390). Soon it was revealed that this was insufficient (#50303) and the fix was extended to references slices &c. (#50327) But even this proved inadequate as the erroneous suggestions were still being issued for patterns in local (`let`) bindings (#50804). Here we yank the shorthand-detection and variable/node registration code into a new common function that can be called while visiting both match arms and `let` bindings. Resolves #50804.,HEART,2018-11-29T05:47:16Z,hcpl,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T10:14:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T10:28:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T11:39:46Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T12:30:28Z,est31,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T13:12:49Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T14:16:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T18:56:12Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-18T21:59:04Z,killercup,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-19T12:14:57Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-20T21:29:48Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-23T02:06:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-23T03:22:28Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-24T03:23:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-05-30T13:58:39Z,hcpl,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HOORAY,2018-06-23T02:47:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HOORAY,2018-08-09T10:03:26Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HEART,2018-08-11T20:40:25Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50855,MERGED,2018-05-18T09:51:23Z,2018-05-20T11:13:40Z,Speed up the macro parser,nnethercote,ad471452ba6fbbf91ad566dc4bdf1033a7281811,4,Make `Directory::path` a `Cow`. Because we create a lot of these in the macro parser but only very rarely modify them. This speeds up some html5ever runs by 2--3%.,HOORAY,2018-08-11T20:40:26Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,LAUGH,2018-05-18T12:25:21Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,HEART,2018-05-18T12:25:25Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,HEART,2018-05-18T12:30:43Z,est31,NA https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,LAUGH,2018-05-18T12:49:58Z,lqd,NA https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,HEART,2018-05-18T12:50:01Z,lqd,NA https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,LAUGH,2018-05-18T12:55:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50860,MERGED,2018-05-18T12:23:07Z,2018-05-21T03:36:45Z,Find the largest niche when computing layouts,nox,b7db68f516bc1a4296aaf2f682ec2384dc2af31e,2,Find the largest niche when computing layouts Otherwise we end up with `Option>` unnecessarily large.,HEART,2018-06-01T15:43:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50861,CLOSED,2018-05-18T13:10:05Z,2018-05-22T08:28:38Z,experimental: Share generic code for optimized builds.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-05-18T20:15:26Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50861,CLOSED,2018-05-18T13:10:05Z,2018-05-22T08:28:38Z,experimental: Share generic code for optimized builds.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-05-19T12:14:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-18T16:45:34Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-18T16:55:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-18T19:43:58Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-18T20:00:07Z,cramertj,NA https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-19T15:15:14Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-30T14:07:06Z,neoeinstein,marcus@griep.us https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-30T14:24:57Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-30T16:44:46Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-05-31T18:26:59Z,hcpl,NA https://github.com/rust-lang/rust/pull/50863,MERGED,2018-05-18T13:38:37Z,2018-05-22T18:56:18Z,Make `[T]::len` and `str::len` const fn,oli-obk,2788f66ab079e76ee5c73ba1651103c557be7a61,1,Add some runtime sanity checks,HEART,2018-06-01T07:14:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50864,MERGED,2018-05-18T14:35:17Z,2018-05-24T14:31:12Z,Add NetBSD/arm target specs,jakllsch,ec779b9f08a55a88b866d2c9d514cb104af5c052,3,Add armv6-unknown-netbsd-eabihf target,THUMBS_UP,2018-05-18T14:38:14Z,alarixnia,NA https://github.com/rust-lang/rust/pull/50864,MERGED,2018-05-18T14:35:17Z,2018-05-24T14:31:12Z,Add NetBSD/arm target specs,jakllsch,ec779b9f08a55a88b866d2c9d514cb104af5c052,3,Add armv6-unknown-netbsd-eabihf target,HOORAY,2018-05-18T14:42:07Z,coypoop,NA https://github.com/rust-lang/rust/pull/50866,MERGED,2018-05-18T16:13:50Z,2018-05-23T14:26:47Z,Use different datastructure for MIRI relocations,michaelwoerister,95fac99a2036a0120be26262110a1e473a85950d,1,Add some doc comments to SortedMap.,THUMBS_UP,2018-05-18T20:17:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50874,MERGED,2018-05-18T19:59:06Z,2018-05-19T12:17:14Z,use `reset_unifications` instead of creating new unification table,nikomatsakis,7ed0fd76998be8e537fa985c9ec52d3c22844e6e,3,use `reset_unifications` instead of creating new unification table,HEART,2018-05-18T20:18:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50874,MERGED,2018-05-18T19:59:06Z,2018-05-19T12:17:14Z,use `reset_unifications` instead of creating new unification table,nikomatsakis,7ed0fd76998be8e537fa985c9ec52d3c22844e6e,3,use `reset_unifications` instead of creating new unification table,HEART,2018-05-23T07:53:02Z,arthurprs,NA https://github.com/rust-lang/rust/pull/50874,MERGED,2018-05-18T19:59:06Z,2018-05-19T12:17:14Z,use `reset_unifications` instead of creating new unification table,nikomatsakis,7ed0fd76998be8e537fa985c9ec52d3c22844e6e,3,use `reset_unifications` instead of creating new unification table,HEART,2018-05-24T03:19:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50876,MERGED,2018-05-18T21:45:35Z,2018-05-22T09:04:49Z,Filter global bounds from ParamEnv again.,matthewjasper,aa5635338c53fbd9f3ca326b55948bc21e655606,14,Filter global bounds from ParamEnv again.,HEART,2018-05-18T22:29:31Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/50876,MERGED,2018-05-18T21:45:35Z,2018-05-22T09:04:49Z,Filter global bounds from ParamEnv again.,matthewjasper,aa5635338c53fbd9f3ca326b55948bc21e655606,14,Filter global bounds from ParamEnv again.,HEART,2018-05-19T15:04:24Z,gsollazzo,NA https://github.com/rust-lang/rust/pull/50876,MERGED,2018-05-18T21:45:35Z,2018-05-22T09:04:49Z,Filter global bounds from ParamEnv again.,matthewjasper,aa5635338c53fbd9f3ca326b55948bc21e655606,14,Filter global bounds from ParamEnv again.,HEART,2018-05-20T12:00:13Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/50876,MERGED,2018-05-18T21:45:35Z,2018-05-22T09:04:49Z,Filter global bounds from ParamEnv again.,matthewjasper,aa5635338c53fbd9f3ca326b55948bc21e655606,14,Filter global bounds from ParamEnv again.,HEART,2018-05-20T19:39:19Z,Arignir,NA https://github.com/rust-lang/rust/pull/50876,MERGED,2018-05-18T21:45:35Z,2018-05-22T09:04:49Z,Filter global bounds from ParamEnv again.,matthewjasper,aa5635338c53fbd9f3ca326b55948bc21e655606,14,Filter global bounds from ParamEnv again.,HEART,2018-05-21T08:19:10Z,holmgr,viktor.holmgren@gmail.com https://github.com/rust-lang/rust/pull/50879,MERGED,2018-05-18T22:39:06Z,2018-05-25T03:38:16Z,Fix naming conventions for new lints,petrochenkov,e60eaf59dfb080317e9a8f8b3b301fca0b430fea,65,Fix naming conventions for new lints,THUMBS_UP,2018-05-18T23:21:08Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/50879,MERGED,2018-05-18T22:39:06Z,2018-05-25T03:38:16Z,Fix naming conventions for new lints,petrochenkov,e60eaf59dfb080317e9a8f8b3b301fca0b430fea,65,Fix naming conventions for new lints,HEART,2018-05-18T23:21:10Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/50879,MERGED,2018-05-18T22:39:06Z,2018-05-25T03:38:16Z,Fix naming conventions for new lints,petrochenkov,e60eaf59dfb080317e9a8f8b3b301fca0b430fea,65,Fix naming conventions for new lints,THUMBS_UP,2018-05-22T17:10:14Z,jminer,NA https://github.com/rust-lang/rust/pull/50891,MERGED,2018-05-19T14:41:41Z,2018-05-23T17:36:48Z,Remove extra calls to kill_loans_out_of_scope_at_location.,davidtwco,280c6fadee1b919763a1f073171880057a325205,1,Remove extra calls to kill_loans_out_of_scope_at_location - keep only before_statement_effect and before_terminator_effect.,HOORAY,2018-05-23T23:10:18Z,lqd,NA https://github.com/rust-lang/rust/pull/50891,MERGED,2018-05-19T14:41:41Z,2018-05-23T17:36:48Z,Remove extra calls to kill_loans_out_of_scope_at_location.,davidtwco,280c6fadee1b919763a1f073171880057a325205,1,Remove extra calls to kill_loans_out_of_scope_at_location - keep only before_statement_effect and before_terminator_effect.,HOORAY,2018-06-01T07:12:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50894,MERGED,2018-05-19T15:53:38Z,2018-06-18T21:08:17Z,Stabilize std::path::Path::ancestors,teiesti,65d119cbf631affd08bc7f0934a6bd77ffb709cd,1,Stabilize std::path::Path:ancestors,THUMBS_UP,2018-06-13T18:49:29Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/50894,MERGED,2018-05-19T15:53:38Z,2018-06-18T21:08:17Z,Stabilize std::path::Path::ancestors,teiesti,65d119cbf631affd08bc7f0934a6bd77ffb709cd,1,Stabilize std::path::Path:ancestors,THUMBS_UP,2018-06-13T23:23:00Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/50894,MERGED,2018-05-19T15:53:38Z,2018-06-18T21:08:17Z,Stabilize std::path::Path::ancestors,teiesti,65d119cbf631affd08bc7f0934a6bd77ffb709cd,1,Stabilize std::path::Path:ancestors,THUMBS_UP,2018-06-28T20:35:41Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/50911,MERGED,2018-05-20T01:05:09Z,2018-08-17T21:20:46Z,Stabilize `use_extern_macros`,petrochenkov,674a5db1a50e25dd60a8ee6669edee9a366c9fab,5,Fix undesirable fallout compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions ui/issues/issue-49074.rs - diagnostics regression not enough recovery to report the second error ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?,HOORAY,2018-08-17T21:22:38Z,mati865,NA https://github.com/rust-lang/rust/pull/50911,MERGED,2018-05-20T01:05:09Z,2018-08-17T21:20:46Z,Stabilize `use_extern_macros`,petrochenkov,674a5db1a50e25dd60a8ee6669edee9a366c9fab,5,Fix undesirable fallout compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions ui/issues/issue-49074.rs - diagnostics regression not enough recovery to report the second error ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?,HOORAY,2018-08-22T17:16:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50911,MERGED,2018-05-20T01:05:09Z,2018-08-17T21:20:46Z,Stabilize `use_extern_macros`,petrochenkov,674a5db1a50e25dd60a8ee6669edee9a366c9fab,5,Fix undesirable fallout compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions ui/issues/issue-49074.rs - diagnostics regression not enough recovery to report the second error ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?,HOORAY,2018-08-22T19:46:31Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/50911,MERGED,2018-05-20T01:05:09Z,2018-08-17T21:20:46Z,Stabilize `use_extern_macros`,petrochenkov,674a5db1a50e25dd60a8ee6669edee9a366c9fab,5,Fix undesirable fallout compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions ui/issues/issue-49074.rs - diagnostics regression not enough recovery to report the second error ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?,HOORAY,2018-09-18T21:12:04Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/50911,MERGED,2018-05-20T01:05:09Z,2018-08-17T21:20:46Z,Stabilize `use_extern_macros`,petrochenkov,674a5db1a50e25dd60a8ee6669edee9a366c9fab,5,Fix undesirable fallout compile-fail-fulldeps/proc-macro/proc-macro-attributes.rs - resolution change for derive helper attributes with the same name as derive itself run-pass/macro-comma-support.rs - indeterminate resolutions for macros in expression positions ui/issues/issue-49074.rs - diagnostics regression not enough recovery to report the second error ui/object-lifetime/object-lifetime-default.stderr - unstable diagnostics?,HOORAY,2018-10-23T10:45:07Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T05:06:07Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T07:34:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T08:15:26Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T08:52:01Z,novacrazy,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-05-20T10:24:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T14:16:49Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T15:04:39Z,pitdicker,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-05-20T15:24:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T15:24:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-05-20T15:27:18Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-20T15:43:38Z,iovxw,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-05-21T02:29:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-05-21T03:16:28Z,sinkuu,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-21T19:28:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-05-22T21:27:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-05-24T20:22:10Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-05-29T00:19:45Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-06-01T20:10:20Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-04T07:46:12Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-04T18:35:48Z,estebank,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-06T13:44:35Z,piderman314,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-06T16:10:05Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-06T16:51:33Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-06T17:46:25Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-06T20:16:39Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-06-06T20:26:25Z,BernhardPosselt,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-07T01:22:16Z,joshleeb,mail@joshleeb.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-07T08:36:01Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-07T08:36:02Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-06-07T08:36:03Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-07T10:16:57Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-10T14:11:09Z,progval,progval+github@progval.net https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-13T06:01:36Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-13T10:20:39Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-13T11:25:11Z,iago-lito,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-06-13T13:28:06Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-13T17:40:37Z,igaray,igarai@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-13T18:40:35Z,KiChjang,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-13T18:45:06Z,sfackler,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-13T20:07:52Z,mcarton,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-06-13T23:17:23Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-14T11:52:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-16T16:00:19Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-17T05:09:03Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-23T17:01:10Z,kyrias,johannes@kyriasis.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-25T17:39:08Z,Viknet,viknetmsu@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-06-26T02:03:13Z,shmutalov,shmutalov@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-06-26T02:03:17Z,shmutalov,shmutalov@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-07-05T16:45:30Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-07-06T19:10:19Z,ljedrz,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-07-14T12:56:44Z,jcgruenhage,jan.christian@gruenhage.xyz https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-10T15:59:25Z,bombless,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-14T03:28:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-14T03:28:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-14T03:28:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-14T20:33:01Z,est31,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-14T20:33:02Z,est31,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-22T01:20:33Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-22T01:20:33Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-22T01:20:37Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-22T04:01:55Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-22T04:01:56Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-22T04:01:57Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-22T10:09:29Z,lqd,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-22T10:09:30Z,lqd,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-22T10:09:30Z,lqd,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-29T15:07:01Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-29T16:49:16Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-08-30T07:52:29Z,Boiethios,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2018-08-31T16:23:11Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-08-31T16:23:12Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-09-06T13:09:03Z,Pzixel,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2018-10-09T10:08:44Z,hcpl,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-10-09T10:08:45Z,hcpl,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2018-11-27T15:47:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,THUMBS_UP,2019-12-13T06:38:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HOORAY,2019-12-13T06:38:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2019-12-13T06:38:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/50912,MERGED,2018-05-20T01:36:27Z,2018-08-22T03:01:14Z,Exhaustive integer matching,varkor,6971c5d55d06c02c8f0b943b3d0b06ef2611c8ac,3,Add some extra edge case tests,HEART,2020-11-19T18:38:05Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/50914,MERGED,2018-05-20T04:45:09Z,2018-05-22T18:56:22Z,Issue #50636: Improve error diagnostic with missing commas after struct fields.,simartin,e6bf3e2ddbfc7907cdf5f3eef0eee4b610200e4b,3,Issue #50636: Improve error diagnostic with missing commas after struct fields.,HEART,2018-05-22T21:53:58Z,estebank,NA https://github.com/rust-lang/rust/pull/50916,MERGED,2018-05-20T12:16:38Z,2018-05-23T22:43:06Z,Allow `Size` to be any valid `u64`,oli-obk,9f79a1946a29110146364a7d8c12a2f8c8740262,1,Allow `Size` to be any valid `u64`,THUMBS_UP,2018-05-20T14:06:11Z,bjorn3,NA https://github.com/rust-lang/rust/pull/50919,MERGED,2018-05-20T16:39:52Z,2018-06-03T00:31:10Z,Provide more context for what the {f32 f64}::EPSILON values represent.,frewsxcv,12878a78a7528dbe5888fe70fd5a0861c820c86a,2,Provide more context for what the {f32 f64}::EPSILON values represent.,HEART,2018-05-21T06:04:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/50931,MERGED,2018-05-21T08:40:10Z,2018-05-22T18:56:24Z,Inline `try_get`.,nnethercote,95120164b0c14f0d78c167224074e870740ee17a,1,Inline `try_get`. This speeds up lots of rustc-perf benchmark runs. The maximum improvement is 1% but there are a lot in the 0.5--1.0% range.,THUMBS_UP,2018-05-21T23:37:56Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50932,MERGED,2018-05-21T08:44:47Z,2018-05-22T18:56:24Z,Optimize seen Predicate filtering.,nnethercote,2ff632484cd8c2e3b123fbf52d9dd39b54a94505,1,Optimize seen Predicate filtering. This speeds up a few rustc-perf benchmark runs most notably ones involving 'coercions' the best by 2%.,THUMBS_UP,2018-05-21T23:38:24Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50932,MERGED,2018-05-21T08:44:47Z,2018-05-22T18:56:24Z,Optimize seen Predicate filtering.,nnethercote,2ff632484cd8c2e3b123fbf52d9dd39b54a94505,1,Optimize seen Predicate filtering. This speeds up a few rustc-perf benchmark runs most notably ones involving 'coercions' the best by 2%.,THUMBS_UP,2018-06-01T06:54:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50933,MERGED,2018-05-21T09:51:17Z,2018-05-24T01:25:52Z,Remove the unstable Float trait,SimonSapin,b825477154e32e8538e00e1e230dadf93bc7e6df,10,Remove the unstable Float trait Following up to #49896 and #50629. Fixes #32110. E0689 is weird.,HOORAY,2018-05-21T11:12:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/50933,MERGED,2018-05-21T09:51:17Z,2018-05-24T01:25:52Z,Remove the unstable Float trait,SimonSapin,b825477154e32e8538e00e1e230dadf93bc7e6df,10,Remove the unstable Float trait Following up to #49896 and #50629. Fixes #32110. E0689 is weird.,HOORAY,2018-06-01T06:59:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HOORAY,2018-05-22T11:06:23Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HOORAY,2018-05-23T17:48:47Z,est31,NA https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HOORAY,2018-05-24T17:54:13Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HOORAY,2018-06-01T07:20:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HEART,2018-06-02T18:14:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/50937,MERGED,2018-05-21T13:14:04Z,2018-05-25T01:33:59Z,implement the chalk-engine traits ,nikomatsakis,8fd316f5b560d926333f0c7cd832c179f430ea27,2,pacify the mercilous tidy,HOORAY,2018-07-04T16:28:04Z,AlexDvorak,NA https://github.com/rust-lang/rust/pull/50941,MERGED,2018-05-21T14:53:24Z,2018-06-13T02:27:07Z,Replace `core::iter::AlwaysOk` by `Result`,kennytm,8ae188959ba5237f3c40f9d9c15954cce6288aee,3,Replace `core::iter::AlwaysOk` by `Result`,THUMBS_UP,2018-06-07T04:27:05Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/50941,MERGED,2018-05-21T14:53:24Z,2018-06-13T02:27:07Z,Replace `core::iter::AlwaysOk` by `Result`,kennytm,8ae188959ba5237f3c40f9d9c15954cce6288aee,3,Replace `core::iter::AlwaysOk` by `Result`,THUMBS_UP,2018-06-20T13:27:08Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/50943,MERGED,2018-05-21T16:07:20Z,2018-05-24T06:13:18Z,impl Trait diagnostic/test cleanups,oli-obk,849c565e2f98c2eb180a21ad1842c32579ed14e3,2,Prevent local paths into libstd from leaking into ui tests,HEART,2018-05-22T19:55:09Z,estebank,NA https://github.com/rust-lang/rust/pull/50955,MERGED,2018-05-22T01:03:26Z,2018-05-30T16:33:12Z,Update libbacktrace,steveklabnik,7c14a54bc81d8e259b43ac8077f2e851c7769753,6,Replace libbacktrace with a submodule While we're at it update the `backtrace` crate from crates.io. It turns out that the submodule's configure script has gotten a lot more finnicky as of late so also switch over to using the `cc` crate manually which allows to avoid some hacks around the configure script as well,THUMBS_UP,2018-05-22T10:03:15Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50955,MERGED,2018-05-22T01:03:26Z,2018-05-30T16:33:12Z,Update libbacktrace,steveklabnik,7c14a54bc81d8e259b43ac8077f2e851c7769753,6,Replace libbacktrace with a submodule While we're at it update the `backtrace` crate from crates.io. It turns out that the submodule's configure script has gotten a lot more finnicky as of late so also switch over to using the `cc` crate manually which allows to avoid some hacks around the configure script as well,THUMBS_DOWN,2018-05-29T17:49:32Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/50958,MERGED,2018-05-22T04:46:33Z,2018-05-22T18:56:29Z,Micro-optimization on PR#50697,KiChjang,1fcb475271571659f15b7a47ef0d4de30d7cc680,1,Micro-optimization on PR#50697,THUMBS_UP,2018-05-22T10:05:26Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50963,MERGED,2018-05-22T09:59:17Z,2018-05-22T18:56:30Z,Right-size the `VecDeque` in `coerce_unsized`.,nnethercote,a86544b799b0fe81e2e2a734a2b49d16faad4f3d,1,"Right-size the `VecDeque` in `coerce_unsized`. The default capacity of a VecDeque is 8 which is excessive here. In a ""base incremental"" check build of rustc-perf's tuple-stress benchmark this decreases total heap allocation by 26%. I couldn't see a clear speedup but it can't hurt.",THUMBS_UP,2018-05-22T10:06:10Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50963,MERGED,2018-05-22T09:59:17Z,2018-05-22T18:56:30Z,Right-size the `VecDeque` in `coerce_unsized`.,nnethercote,a86544b799b0fe81e2e2a734a2b49d16faad4f3d,1,"Right-size the `VecDeque` in `coerce_unsized`. The default capacity of a VecDeque is 8 which is excessive here. In a ""base incremental"" check build of rustc-perf's tuple-stress benchmark this decreases total heap allocation by 26%. I couldn't see a clear speedup but it can't hurt.",THUMBS_UP,2018-06-01T07:06:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50972,MERGED,2018-05-22T17:31:12Z,2018-05-24T14:31:18Z,Add -Z no-parallel-llvm flag,nikic,54f0668a1084b8e64355de5b194fc2fd02fe3854,2,Add -Z no-parallel-llvm flag Codegen issues commonly only manifest under specific circumstances e.g. if multiple codegen units are used and ThinLTO is enabled. However these configuration are threaded making the use of LLVM debugging facilities hard as output is interleaved. This patch adds a -Z no-parallel-llvm flag which allows disabling parallelization of codegen and linking while otherwise preserving behavior with regard to codegen units and LTO.,THUMBS_UP,2018-05-22T22:51:54Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-23T17:47:47Z,est31,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-23T18:21:04Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-23T19:02:14Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-23T21:45:40Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-23T23:59:53Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-24T07:46:19Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-24T13:19:30Z,lqd,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-24T15:20:26Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-24T17:13:18Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-24T17:14:34Z,j16r,gh@j16r.net https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-26T19:08:16Z,bluss,NA https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-29T15:35:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/50981,MERGED,2018-05-22T22:58:16Z,2018-05-24T14:31:19Z,Shrink `LiveNode`.,nnethercote,8d0fad5d3832c6c1f14542ea0be038274e454524,1,"Shrink `LiveNode`. `Liveness::users` is a vector that is occasionally enormous. For example doing a ""clean incremental"" check build of `inflate` there is one instance that represents 5 499 live nodes and 1087 vars which requires 5 977 413 entries. At 24 bytes per entry that is 143MB. This patch changes LiveNode from a usize to a u32. On 64-bit machines that halves the size of these entries significantly reducing peak memory usage and memory traffic and speeding up ""clean incremental"" builds of `inflate` by about 10%.",HOORAY,2018-05-30T20:52:34Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/50997,MERGED,2018-05-23T14:31:19Z,2018-06-28T13:23:13Z, Make FileMap::{lines multibyte_chars non_narrow_chars} non-mutable. ,michaelwoerister,a1f8a6ce80a340d51074071c0d9e30eb14f65d25,2,Fix FileMap::line_begin_pos(). The method relied on the FileMap still being under construction in order for it to do what the name promises. It's now independent of the current state.,THUMBS_UP,2018-05-23T15:17:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/50997,MERGED,2018-05-23T14:31:19Z,2018-06-28T13:23:13Z, Make FileMap::{lines multibyte_chars non_narrow_chars} non-mutable. ,michaelwoerister,a1f8a6ce80a340d51074071c0d9e30eb14f65d25,2,Fix FileMap::line_begin_pos(). The method relied on the FileMap still being under construction in order for it to do what the name promises. It's now independent of the current state.,THUMBS_UP,2018-05-31T21:46:33Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/50997,MERGED,2018-05-23T14:31:19Z,2018-06-28T13:23:13Z, Make FileMap::{lines multibyte_chars non_narrow_chars} non-mutable. ,michaelwoerister,a1f8a6ce80a340d51074071c0d9e30eb14f65d25,2,Fix FileMap::line_begin_pos(). The method relied on the FileMap still being under construction in order for it to do what the name promises. It's now independent of the current state.,THUMBS_UP,2018-07-05T08:52:00Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/50997,MERGED,2018-05-23T14:31:19Z,2018-06-28T13:23:13Z, Make FileMap::{lines multibyte_chars non_narrow_chars} non-mutable. ,michaelwoerister,a1f8a6ce80a340d51074071c0d9e30eb14f65d25,2,Fix FileMap::line_begin_pos(). The method relied on the FileMap still being under construction in order for it to do what the name promises. It's now independent of the current state.,THUMBS_UP,2018-07-06T18:44:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51034,MERGED,2018-05-24T13:06:20Z,2018-05-26T14:30:48Z,Remove unused lowering field and method,oli-obk,6a0806b75a6e7f98b07ef14804c6e9fbc1b7b9f4,1,Remove unused lowering field and method,LAUGH,2018-05-26T07:44:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51034,MERGED,2018-05-24T13:06:20Z,2018-05-26T14:30:48Z,Remove unused lowering field and method,oli-obk,6a0806b75a6e7f98b07ef14804c6e9fbc1b7b9f4,1,Remove unused lowering field and method,HEART,2018-05-26T07:44:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51034,MERGED,2018-05-24T13:06:20Z,2018-05-26T14:30:48Z,Remove unused lowering field and method,oli-obk,6a0806b75a6e7f98b07ef14804c6e9fbc1b7b9f4,1,Remove unused lowering field and method,LAUGH,2018-06-01T07:21:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51047,MERGED,2018-05-24T21:54:54Z,2018-05-26T14:30:49Z,Use AllFacts from polonius-engine,spastorino,8429d11a0b80dfaf8a79fb0d5e9bb5fd50455712,10,Use AllFacts from polonius-engine,HOORAY,2018-05-24T21:55:58Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/51047,MERGED,2018-05-24T21:54:54Z,2018-05-26T14:30:49Z,Use AllFacts from polonius-engine,spastorino,8429d11a0b80dfaf8a79fb0d5e9bb5fd50455712,10,Use AllFacts from polonius-engine,HOORAY,2018-06-01T06:53:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-05-25T06:31:49Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-05-25T14:30:23Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-05-28T18:13:51Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-06-06T13:24:48Z,lnicola,NA https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-06-07T15:17:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-06-25T14:29:05Z,mati865,NA https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-07-18T20:45:03Z,cauebs,NA https://github.com/rust-lang/rust/pull/51050,MERGED,2018-05-24T22:48:01Z,2018-05-31T19:53:32Z,std::fs::DirEntry.metadata(): use fstatat instead of lstat when possible,symphorien,8dec03b71af22a160803c241b6812b8e54ee9671,1,libstd/sys/unix/fs.rs: fix compilation on fuchsia,HEART,2018-07-30T09:59:54Z,ondj,NA https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-05-25T14:49:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-05-25T14:58:37Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-05-25T15:09:47Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-05-26T00:16:28Z,est31,NA https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-06-01T07:17:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51059,MERGED,2018-05-25T14:49:19Z,2018-05-26T14:30:51Z,What does an expression look like that consists only of special characters?,oberien,5ad84cf3fa988e47d5b6b058c2888de076881d5c,1,Don't use a char that's already used within the expr,LAUGH,2018-06-06T11:08:31Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-05-25T20:28:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-05-26T11:16:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-08-20T03:44:02Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-09-02T14:45:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-09-04T08:06:00Z,mati865,NA https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-09-06T00:47:15Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-09-14T09:31:02Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-10-29T06:44:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51061,CLOSED,2018-05-25T16:25:27Z,2018-12-01T13:55:41Z,Add Polly support.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-11-08T06:33:58Z,lucmos,luca.moschella94@gmail.com https://github.com/rust-lang/rust/pull/51066,MERGED,2018-05-25T20:40:33Z,2018-05-27T03:33:03Z,Point to the current box syntax tracking issue,est31,20ab8841b1cfd7c1d3288bdba4a5b57a12511b49,4,Point to the current box syntax tracking issue The issue was used for both box syntax as well as placement new. It got closed due to placement new being unapproved. So a new one got created for box syntax yet neither the unstable book nor feature_gate.rs got updated. We are doing this now.,HEART,2018-05-26T07:38:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51066,MERGED,2018-05-25T20:40:33Z,2018-05-27T03:33:03Z,Point to the current box syntax tracking issue,est31,20ab8841b1cfd7c1d3288bdba4a5b57a12511b49,4,Point to the current box syntax tracking issue The issue was used for both box syntax as well as placement new. It got closed due to placement new being unapproved. So a new one got created for box syntax yet neither the unstable book nor feature_gate.rs got updated. We are doing this now.,HEART,2021-09-09T14:10:44Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/51073,MERGED,2018-05-26T02:53:24Z,2018-05-26T14:30:54Z,Rename TokenStream::empty to TokenStream::new,dtolnay,a49bc9ce5996b9cb0c49142f458a6612ef3c252c,5,Rename TokenStream::empty to TokenStream::new There is no precedent for the `empty` name -- we do not have `Vec::empty` or `HashMap::empty` etc.,THUMBS_UP,2018-05-31T00:47:42Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/51075,MERGED,2018-05-26T05:05:28Z,2018-05-27T05:53:32Z,Check for confusable Unicode chars in float literal exponent ,estebank,7dec8a4e99ee10696a3b1e61bfa5918683c49437,5,Fix test,HEART,2018-05-26T07:35:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51079,MERGED,2018-05-26T09:12:30Z,2018-06-10T15:11:45Z,Stabilize entry-or-default,GuillaumeGomez,861c7cb9fd37fc171f80a9f0b58f995ad67c6df0,4,Stabilize entry-or-default,HOORAY,2018-06-11T16:06:39Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/51096,MERGED,2018-05-26T19:04:21Z,2018-06-01T01:09:34Z,Register outlives predicates from queries the right way around.,matthewjasper,b83daea479ceee19445058001ed0a6412ec25889,4,Register outlives predicates from queries the right way around.,HEART,2018-06-01T05:35:06Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/51096,MERGED,2018-05-26T19:04:21Z,2018-06-01T01:09:34Z,Register outlives predicates from queries the right way around.,matthewjasper,b83daea479ceee19445058001ed0a6412ec25889,4,Register outlives predicates from queries the right way around.,HEART,2018-06-07T14:55:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51100,MERGED,2018-05-27T00:07:59Z,2018-05-30T19:30:42Z,Suggest using `as_ref` on some borrow errors [hack],estebank,a19a03a31fc1145f66513de74e9b5f89558719ec,3,Suggest using `as_ref` on some borrow errors [hack] When encountering the following code: ```rust struct Foo; fn takes_ref(_: &Foo) {} let ref opt = Some(Foo); opt.map(|arg| takes_ref(arg)); ``` Suggest using `opt.as_ref().map(|arg| takes_ref(arg));` instead. This is a stop gap solution until we expand typeck to deal with these cases in a more graceful way.,HOORAY,2018-05-27T01:07:14Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/51100,MERGED,2018-05-27T00:07:59Z,2018-05-30T19:30:42Z,Suggest using `as_ref` on some borrow errors [hack],estebank,a19a03a31fc1145f66513de74e9b5f89558719ec,3,Suggest using `as_ref` on some borrow errors [hack] When encountering the following code: ```rust struct Foo; fn takes_ref(_: &Foo) {} let ref opt = Some(Foo); opt.map(|arg| takes_ref(arg)); ``` Suggest using `opt.as_ref().map(|arg| takes_ref(arg));` instead. This is a stop gap solution until we expand typeck to deal with these cases in a more graceful way.,HOORAY,2018-05-27T22:36:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51100,MERGED,2018-05-27T00:07:59Z,2018-05-30T19:30:42Z,Suggest using `as_ref` on some borrow errors [hack],estebank,a19a03a31fc1145f66513de74e9b5f89558719ec,3,Suggest using `as_ref` on some borrow errors [hack] When encountering the following code: ```rust struct Foo; fn takes_ref(_: &Foo) {} let ref opt = Some(Foo); opt.map(|arg| takes_ref(arg)); ``` Suggest using `opt.as_ref().map(|arg| takes_ref(arg));` instead. This is a stop gap solution until we expand typeck to deal with these cases in a more graceful way.,HOORAY,2018-06-07T15:00:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51104,MERGED,2018-05-27T04:45:21Z,2018-06-26T13:18:07Z,add `dyn ` to display of dynamic (trait) types,zackmdavis,4b1808578a99b1a452b65f0bf27de4c8775e9105,57,add `dyn` to display of dynamic (trait) type names The `dyn Trait` syntax was stabilized in 199ee327. Resolves #49277.,THUMBS_UP,2018-05-28T06:29:28Z,bjorn3,NA https://github.com/rust-lang/rust/pull/51105,MERGED,2018-05-27T08:54:23Z,2018-05-27T16:01:50Z,lib.rs don't beautiful,NA,NA,NA,NA,LAUGH,2018-05-27T10:06:45Z,kennytm,NA https://github.com/rust-lang/rust/pull/51105,MERGED,2018-05-27T08:54:23Z,2018-05-27T16:01:50Z,lib.rs don't beautiful,NA,NA,NA,NA,LAUGH,2018-05-27T12:28:27Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/51105,MERGED,2018-05-27T08:54:23Z,2018-05-27T16:01:50Z,lib.rs don't beautiful,NA,NA,NA,NA,LAUGH,2019-01-30T17:46:09Z,vlasove,NA https://github.com/rust-lang/rust/pull/51105,MERGED,2018-05-27T08:54:23Z,2018-05-27T16:01:50Z,lib.rs don't beautiful,NA,NA,NA,NA,LAUGH,2019-02-01T10:48:32Z,btwotwo,NA https://github.com/rust-lang/rust/pull/51110,MERGED,2018-05-27T16:10:37Z,2018-07-02T00:58:28Z,Loosened rules involving statics mentioning other statics,alexreg,1c342270424058847b3e348dea4038ff42ab75eb,2,Modified expected error messages in accordance with rebase.,THUMBS_UP,2018-07-04T17:18:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51110,MERGED,2018-05-27T16:10:37Z,2018-07-02T00:58:28Z,Loosened rules involving statics mentioning other statics,alexreg,1c342270424058847b3e348dea4038ff42ab75eb,2,Modified expected error messages in accordance with rebase.,THUMBS_UP,2018-07-06T18:25:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,LAUGH,2018-05-28T11:57:16Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,LAUGH,2018-05-28T12:40:13Z,kennytm,NA https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,THUMBS_UP,2018-05-29T06:39:59Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,HOORAY,2018-05-29T08:56:10Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,HEART,2018-05-29T14:46:02Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,HOORAY,2018-05-29T14:46:05Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,THUMBS_UP,2018-05-29T14:46:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,THUMBS_UP,2018-05-30T11:39:16Z,mati865,NA https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,HOORAY,2018-07-04T19:08:37Z,mcarton,NA https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,THUMBS_UP,2018-07-06T18:27:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51122,MERGED,2018-05-28T11:55:36Z,2018-07-02T16:04:59Z,Did you mean to block nightlies on clippy?,oli-obk,78adefd15dd45bc1466424c5d2a3231471559324,1,Clippy tool also has only a single LICENSE file,LAUGH,2018-09-12T06:39:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-28T15:37:10Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-28T16:49:23Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-28T18:15:09Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-29T03:50:50Z,sinkuu,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-29T04:16:59Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-05-29T07:18:44Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-05-30T00:13:33Z,cramertj,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-05-30T00:13:33Z,cramertj,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-01T10:57:00Z,iovxw,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-06-01T10:57:01Z,iovxw,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-02T11:24:37Z,utam0k,k0ma@utam0k.jp https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-06-05T21:02:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-07T03:22:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-12T09:10:48Z,bjorn3,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-18T07:56:18Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-06-21T02:54:11Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-21T02:54:13Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-06-22T19:15:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-22T19:15:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-23T11:13:07Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-06-23T11:13:09Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-06-30T11:47:13Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-07-10T19:47:20Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-07-10T19:47:26Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-07-13T16:27:37Z,estebank,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-07-26T06:55:59Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-07-26T06:56:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-08-02T10:01:12Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-08-05T10:47:03Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-08-09T06:50:36Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-08-21T07:02:54Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-08-21T07:02:54Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HEART,2018-08-22T11:47:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2018-08-22T17:19:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,THUMBS_UP,2018-08-24T02:11:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,THUMBS_UP,2018-08-24T03:11:18Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2020-01-04T22:51:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51131,MERGED,2018-05-28T15:24:55Z,2018-08-19T14:44:51Z,Implement Unsized Rvalues,qnighy,c488d59addf6bc66725a2ca7314629ee0f92b4e5,7,Integrate OperandValue::UnsizedRef into OperandValue::Ref.,HOORAY,2022-04-19T08:20:16Z,pro465,NA https://github.com/rust-lang/rust/pull/51133,MERGED,2018-05-28T15:50:58Z,2018-05-29T17:18:05Z,Make borrowck use polonius output,spastorino,c3d688962d2940a033f4b4df85b8ab8417981210,1,WIP fix rustc-hash cargo.lock entry for polonius-engine,HOORAY,2018-06-07T01:46:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51133,MERGED,2018-05-28T15:50:58Z,2018-05-29T17:18:05Z,Make borrowck use polonius output,spastorino,c3d688962d2940a033f4b4df85b8ab8417981210,1,WIP fix rustc-hash cargo.lock entry for polonius-engine,HOORAY,2018-06-07T03:19:47Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/51133,MERGED,2018-05-28T15:50:58Z,2018-05-29T17:18:05Z,Make borrowck use polonius output,spastorino,c3d688962d2940a033f4b4df85b8ab8417981210,1,WIP fix rustc-hash cargo.lock entry for polonius-engine,HOORAY,2018-06-07T14:55:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51133,MERGED,2018-05-28T15:50:58Z,2018-05-29T17:18:05Z,Make borrowck use polonius output,spastorino,c3d688962d2940a033f4b4df85b8ab8417981210,1,WIP fix rustc-hash cargo.lock entry for polonius-engine,HOORAY,2018-06-24T07:21:53Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51138,MERGED,2018-05-28T18:28:44Z,2018-05-31T01:06:46Z,Add polonius compare mode,spastorino,b39a1d6f1a30ba29f25d7141038b9a5bf0126e36,4,Run rustfmt,THUMBS_UP,2018-06-07T03:20:37Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/51149,MERGED,2018-05-29T05:56:23Z,2018-06-27T01:26:44Z,lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase,zackmdavis,64365e46f2675403babb2669d60d418fae3e0a7c,1,driveby status update to 2015 comment about parens in patterns,HEART,2018-06-03T17:50:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51149,MERGED,2018-05-29T05:56:23Z,2018-06-27T01:26:44Z,lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase,zackmdavis,64365e46f2675403babb2669d60d418fae3e0a7c,1,driveby status update to 2015 comment about parens in patterns,HEART,2018-06-04T18:35:16Z,estebank,NA https://github.com/rust-lang/rust/pull/51149,MERGED,2018-05-29T05:56:23Z,2018-06-27T01:26:44Z,lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase,zackmdavis,64365e46f2675403babb2669d60d418fae3e0a7c,1,driveby status update to 2015 comment about parens in patterns,HEART,2018-06-05T18:06:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/51149,MERGED,2018-05-29T05:56:23Z,2018-06-27T01:26:44Z,lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase,zackmdavis,64365e46f2675403babb2669d60d418fae3e0a7c,1,driveby status update to 2015 comment about parens in patterns,HEART,2018-06-20T01:54:31Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/51149,MERGED,2018-05-29T05:56:23Z,2018-06-27T01:26:44Z,lint to favor `..=` over `...` range patterns; migrate to `..=` throughout codebase,zackmdavis,64365e46f2675403babb2669d60d418fae3e0a7c,1,driveby status update to 2015 comment about parens in patterns,HEART,2018-07-06T18:31:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51151,MERGED,2018-05-29T07:42:50Z,2018-06-04T09:58:24Z,Move slice::exact_chunks directly above exact_chunks_mut for more con…,sdroege,eb3a73484b5d5b8cadbf92074c2cbe6a38cb11b1,1,Move slice::exact_chunks directly above exact_chunks_mut for more consistent docs order See https://github.com/rust-lang/rust/issues/47115#issuecomment-392532855,THUMBS_UP,2018-05-29T07:53:22Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51159,MERGED,2018-05-29T09:50:14Z,2018-09-12T04:28:57Z,First step towards `u128` instead of `Const` in `PatternKind::Range`,pacman82,26c05b13e11518a99f06b618b833a48851a39fbe,3,Add ty::Ty to PatternKind::Range;u128 for Const in Constructor::ConstantRange,HOORAY,2018-09-20T06:51:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,HOORAY,2018-06-05T18:23:47Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-06-05T18:23:54Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-06-19T16:45:18Z,estebank,NA https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-06-20T18:43:20Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-07-07T22:53:38Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-09-12T06:34:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,HOORAY,2018-09-12T14:50:53Z,chrish42,NA https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,THUMBS_UP,2018-09-15T08:35:59Z,liranringel,NA https://github.com/rust-lang/rust/pull/51178,MERGED,2018-05-29T16:18:36Z,2018-06-30T06:03:13Z,Implement PartialEq between &str and OsString,GabrielMajeri,fbd3c92a885b02a5397eaf65d36beae8e1ed999c,1,Add run-pass test,HEART,2018-09-19T10:09:27Z,jmcomets,NA https://github.com/rust-lang/rust/pull/51183,MERGED,2018-05-29T19:46:36Z,2018-06-05T18:19:50Z,Update rustdoc book to suggest using Termination trait instead of hidden ‘foo’ function,teiesti,089da06cc437aa4764f958ff441e79d7fca6b148,1,Improve wording,THUMBS_UP,2018-06-05T10:27:02Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/51183,MERGED,2018-05-29T19:46:36Z,2018-06-05T18:19:50Z,Update rustdoc book to suggest using Termination trait instead of hidden ‘foo’ function,teiesti,089da06cc437aa4764f958ff441e79d7fca6b148,1,Improve wording,THUMBS_UP,2018-06-13T18:49:40Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51184,MERGED,2018-05-29T19:52:48Z,2018-06-22T13:18:52Z,Issue #50974 : Suboptimal error in case of duplicate ` ` in struct constructor,lambtowolf,a99767f64f400f694aec02655af4b5cb5913609e,1,add an explanatory comment for recovery behavior,THUMBS_UP,2018-05-29T21:46:50Z,estebank,NA https://github.com/rust-lang/rust/pull/51207,CLOSED,2018-05-30T09:15:17Z,2018-07-30T16:59:53Z,[experimental]: Build LLVM with ThinLTO enabled,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-05-31T18:17:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51207,CLOSED,2018-05-30T09:15:17Z,2018-07-30T16:59:53Z,[experimental]: Build LLVM with ThinLTO enabled,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-06-02T10:29:33Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51213,MERGED,2018-05-30T09:43:59Z,2018-05-31T22:58:52Z,fs: copy: Use File::set_permissions instead of fs::set_permissions,nicokoch,c5ee3b6df1db2c4410b0e8d7a80a2885cf5628f1,1,Remobve unused import,THUMBS_UP,2018-05-30T16:36:39Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/51213,MERGED,2018-05-30T09:43:59Z,2018-05-31T22:58:52Z,fs: copy: Use File::set_permissions instead of fs::set_permissions,nicokoch,c5ee3b6df1db2c4410b0e8d7a80a2885cf5628f1,1,Remobve unused import,THUMBS_UP,2018-05-30T22:27:37Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/51225,MERGED,2018-05-30T16:43:18Z,2018-06-01T08:46:57Z,Fix the miri submodule,oli-obk,06394518f8c53ac940977fb16467942c0a1ca58c,2,Update miri submodule,THUMBS_UP,2018-05-31T06:12:11Z,bjorn3,NA https://github.com/rust-lang/rust/pull/51227,MERGED,2018-05-30T19:30:06Z,2018-05-31T22:58:53Z,mod.rs isn't beautiful,NA,NA,NA,NA,THUMBS_UP,2018-05-30T19:33:22Z,rossnomann,rossnomann@protonmail.com https://github.com/rust-lang/rust/pull/51227,MERGED,2018-05-30T19:30:06Z,2018-05-31T22:58:53Z,mod.rs isn't beautiful,NA,NA,NA,NA,THUMBS_UP,2018-05-30T19:38:57Z,kirillDanshin,NA https://github.com/rust-lang/rust/pull/51235,MERGED,2018-05-30T23:57:48Z,2018-05-31T17:47:32Z,remove notion of Implicit derefs from mem-cat,nikomatsakis,8a624b737a772ecc6840870bbf895950602b2920,13,change `PointerKind::Implicit` to a note `PointerKind` is included in `LoanPath` and hence forms part of the equality check; this led to having two unequal paths that both represent `*x` depending on whether the `*` was inserted automatically or explicitly. Bad mojo. The `note` field in contrast is intended more-or-less primarily for this purpose of adding extra data.,HOORAY,2018-05-31T08:34:28Z,est31,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-05-31T19:17:20Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-05-31T23:17:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T04:14:14Z,geofft,geofft@ldpreload.com https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T04:28:05Z,sfackler,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T11:26:39Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T14:38:09Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T15:22:02Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T16:16:20Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T17:36:05Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T18:23:50Z,chrish42,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T19:10:19Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-01T23:28:56Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-04T01:13:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-07T15:51:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-12T05:02:48Z,est31,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-19T15:20:29Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-06-20T02:57:11Z,cauebs,NA https://github.com/rust-lang/rust/pull/51241,MERGED,2018-05-31T07:13:52Z,2018-06-12T02:48:26Z,Stabilize GlobalAlloc and #[global_allocator],glandium,7f0d54d98842c786ab7a140c17c3ea32aea6aead,2,More alloc docs tweaks,HOORAY,2018-07-20T00:55:20Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/51258,MERGED,2018-05-31T20:53:48Z,2018-06-01T22:49:40Z,1.26.2 release,Mark-Simulacrum,7093b11690486e5fd3502b299b5477a83fd3b001,1,Update version to 1.26.2,THUMBS_UP,2018-06-01T00:38:02Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HEART,2018-05-31T22:45:01Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HOORAY,2018-05-31T22:57:44Z,kennytm,NA https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HEART,2018-05-31T23:03:38Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HOORAY,2018-06-01T22:00:35Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HOORAY,2018-06-03T19:51:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HOORAY,2018-06-07T01:48:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51261,MERGED,2018-05-31T22:34:50Z,2018-06-12T19:47:19Z,Updated RELEASES.md for 1.27.0,XAMPPRocky,46f74a3ef5f25f0a47daa4d19643dbf14303a90e,1,Updated RELEASES.md for 1.27.0,HOORAY,2018-06-07T16:21:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T00:03:01Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T00:04:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T02:51:36Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T03:55:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T04:39:02Z,crlf0710,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T06:38:33Z,est31,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HEART,2018-06-01T10:47:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-01T14:41:06Z,kellytk,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-02T02:10:56Z,nooberfsh,nooberfsh@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-02T09:48:04Z,legokichi,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-02T10:28:16Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-03T20:02:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-05T09:13:39Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-06T03:01:42Z,kamyuentse,kevin.xjy@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-06T23:09:21Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-06T23:21:29Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-06T23:44:56Z,hcpl,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T00:26:10Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HEART,2018-06-07T00:26:13Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T00:26:14Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_DOWN,2018-06-07T00:26:36Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T00:59:02Z,axlrose,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T01:44:51Z,Naupio,naupio@163.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T01:44:54Z,Naupio,naupio@163.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T03:52:12Z,tjkirch,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T06:26:05Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T07:11:28Z,jpeddicord,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T07:39:20Z,utam0k,k0ma@utam0k.jp https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T09:05:36Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T09:05:38Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T12:35:42Z,davll,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T12:35:43Z,davll,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-07T14:55:10Z,bancek,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T14:55:11Z,bancek,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-07T15:13:58Z,pzuraq,me@pzuraq.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-08T17:10:11Z,invokesus,souviksen44@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-13T05:30:11Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-13T08:12:03Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-13T09:19:53Z,meven,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-13T09:26:21Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-13T09:51:38Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-14T11:46:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,HOORAY,2018-06-15T09:44:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-17T07:32:24Z,dainslef,dainsleftei@outlook.com https://github.com/rust-lang/rust/pull/51263,MERGED,2018-05-31T23:47:17Z,2018-06-06T22:24:17Z,Add Future and task system to the standard library,cramertj,a6055c885917093faf37bcb834350df7b6ddca82,8,Add Future and task system to the standard library,THUMBS_UP,2018-06-27T07:23:41Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/51264,MERGED,2018-06-01T00:02:48Z,2018-06-01T16:16:55Z,Make the OOM hook return `()` rather than `!`,glandium,b945be71e87f99f7578a039a541aeae6de8b6020,1,Make the OOM hook return `()` rather than `!` Per discussion in https://github.com/rust-lang/rust/issues/51245#issuecomment-393651083 This allows more flexibility in what can be done with the API. This also splits `rtabort!` into `dumb_print` happening in the default hook and `abort_internal` happening in the actual oom handler after calling the hook. Registering an empty function thus makes the oom handler not print anything but still abort. Cc: @alexcrichton,HOORAY,2018-06-01T14:31:18Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/51264,MERGED,2018-06-01T00:02:48Z,2018-06-01T16:16:55Z,Make the OOM hook return `()` rather than `!`,glandium,b945be71e87f99f7578a039a541aeae6de8b6020,1,Make the OOM hook return `()` rather than `!` Per discussion in https://github.com/rust-lang/rust/issues/51245#issuecomment-393651083 This allows more flexibility in what can be done with the API. This also splits `rtabort!` into `dumb_print` happening in the default hook and `abort_internal` happening in the actual oom handler after calling the hook. Registering an empty function thus makes the oom handler not print anything but still abort. Cc: @alexcrichton,HOORAY,2018-06-07T15:09:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51265,MERGED,2018-06-01T01:03:59Z,2018-06-10T01:45:46Z,crate-ify and delete unused code from syntax::parse,Mark-Simulacrum,60058e5dbe1ef466010cc34aa31e84ccf1ebb330,10,Crate-ify and delete unused code in syntax::parse,HEART,2018-06-01T19:14:23Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/51265,MERGED,2018-06-01T01:03:59Z,2018-06-10T01:45:46Z,crate-ify and delete unused code from syntax::parse,Mark-Simulacrum,60058e5dbe1ef466010cc34aa31e84ccf1ebb330,10,Crate-ify and delete unused code in syntax::parse,HEART,2018-06-04T18:05:05Z,estebank,NA https://github.com/rust-lang/rust/pull/51281,CLOSED,2018-06-01T19:35:04Z,2018-06-07T01:17:36Z,Remove Box from RcSlice,Mark-Simulacrum,NA,NA,NA,HEART,2018-06-01T21:48:15Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51281,CLOSED,2018-06-01T19:35:04Z,2018-06-07T01:17:36Z,Remove Box from RcSlice,Mark-Simulacrum,NA,NA,NA,HEART,2018-06-01T23:16:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51283,MERGED,2018-06-01T21:23:32Z,2018-06-08T02:01:06Z,Deny #[cfg] and #[cfg_attr] on generic parameters.,kennytm,c9cb806689a9691e2a29836e2c597751cdbcfdc8,6,Deny #[cfg] and #[cfg_attr] on generic parameters.,HOORAY,2018-06-01T23:07:00Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51283,MERGED,2018-06-01T21:23:32Z,2018-06-08T02:01:06Z,Deny #[cfg] and #[cfg_attr] on generic parameters.,kennytm,c9cb806689a9691e2a29836e2c597751cdbcfdc8,6,Deny #[cfg] and #[cfg_attr] on generic parameters.,HOORAY,2018-06-14T11:59:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2018-06-02T09:23:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2018-06-21T23:15:05Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2018-06-23T14:44:33Z,est31,NA https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2018-11-07T21:06:13Z,estebank,NA https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2018-12-08T00:22:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2019-01-06T08:35:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/51285,MERGED,2018-06-01T23:09:17Z,2019-01-24T18:31:28Z,Remove quote_*! macros,Mark-Simulacrum,db97c48ad6e7f36468b152e9b08efc6f2f7da691,60,Remove quote_*! macros and associated APIs,HOORAY,2019-01-23T10:19:50Z,ljedrz,NA https://github.com/rust-lang/rust/pull/51291,MERGED,2018-06-02T07:22:52Z,2018-06-03T00:31:20Z,Fix typos of ‘ambiguous’,evincarofautumn,562d97d978fbe4cee2fe454c54bda30c1bed7035,2,Fix typos of 'ambiguous',LAUGH,2018-06-03T10:45:22Z,brendanzab,NA https://github.com/rust-lang/rust/pull/51294,CLOSED,2018-06-02T09:46:58Z,2018-07-12T16:46:11Z,[WIP] Impl a more strict transmute check,nagisa,NA,NA,NA,HEART,2018-06-30T17:52:44Z,anderejd,NA https://github.com/rust-lang/rust/pull/51294,CLOSED,2018-06-02T09:46:58Z,2018-07-12T16:46:11Z,[WIP] Impl a more strict transmute check,nagisa,NA,NA,NA,HEART,2018-07-03T10:31:08Z,est31,NA https://github.com/rust-lang/rust/pull/51294,CLOSED,2018-06-02T09:46:58Z,2018-07-12T16:46:11Z,[WIP] Impl a more strict transmute check,nagisa,NA,NA,NA,HEART,2018-08-31T21:16:11Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/51294,CLOSED,2018-06-02T09:46:58Z,2018-07-12T16:46:11Z,[WIP] Impl a more strict transmute check,nagisa,NA,NA,NA,THUMBS_UP,2022-06-26T10:11:50Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HOORAY,2018-06-03T13:47:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HEART,2018-06-03T17:46:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HOORAY,2018-06-13T06:56:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HEART,2018-06-13T06:56:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HOORAY,2018-06-14T11:48:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,THUMBS_UP,2018-06-15T14:05:57Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HEART,2018-07-31T21:23:48Z,dragostis,NA https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HOORAY,2018-07-31T22:33:05Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/51298,MERGED,2018-06-02T12:01:13Z,2018-06-09T01:32:58Z,Stabilize unit tests with non-`()` return type,Dylan-DPC-zz,8ecbd351bb80f03a76110ba9f7b9e6a68b3d2798,2,fix stderrs,HEART,2018-08-03T08:27:47Z,pacman82,NA https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-02T15:27:34Z,oli-obk,NA https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-03T00:20:17Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-03T13:47:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-06T20:09:33Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-07T15:06:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-06-07T18:03:31Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51299,MERGED,2018-06-02T12:29:42Z,2018-06-04T04:57:43Z,const fn integer operations,faern,8b5f962762b500a1428e9d6937d964922a233fa1,1,Ignore i128 test on asmjs,HEART,2018-07-01T15:21:13Z,hcpl,NA https://github.com/rust-lang/rust/pull/51302,MERGED,2018-06-02T13:52:11Z,2018-06-03T00:31:21Z,Permit building rustdoc without compiler artifacts,Mark-Simulacrum,cf24a1df331ae4314245825c4ce668bc74b6d55c,2,Rustdoc itself no longer requires proc macros to build This avoids a full compiler build in order to build and/or run tests for rustdoc.,HOORAY,2018-06-04T22:10:02Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/51318,CLOSED,2018-06-02T22:36:11Z,2018-07-12T18:01:39Z,provide various trait implementations for arrays up to 44 elements,alex,NA,NA,NA,CONFUSED,2018-06-03T07:27:34Z,kennytm,NA https://github.com/rust-lang/rust/pull/51318,CLOSED,2018-06-02T22:36:11Z,2018-07-12T18:01:39Z,provide various trait implementations for arrays up to 44 elements,alex,NA,NA,NA,CONFUSED,2018-06-03T10:39:15Z,mati865,NA https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-03T19:37:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-13T05:16:29Z,KeenS,NA https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-13T07:07:37Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-13T09:19:14Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-14T11:48:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51320,MERGED,2018-06-03T02:57:48Z,2018-06-10T03:52:39Z,Stabilize Iterator::step_by,tmccombs,72e17b81fa88894e3fe04f221166f5a48e753e94,6,Stabilize Iterator::step_by Fixes #27741,HOORAY,2018-06-15T09:50:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51321,MERGED,2018-06-03T03:59:24Z,2018-07-02T18:09:26Z,HirId-ification continued,zackmdavis,f23d90a1475e65915923814d4ad3d8d183b24c7e,1,add FIXMEs pleading for post-@ edit of commentary on mem_categorization (The present author fears not being knowledgeable enough to rewrite the comments unilaterally; merely calling it out is a lazy half-measure but at least doesn't actively make things worse the way an ill-informed rewrite would.),HOORAY,2018-06-04T01:15:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51321,MERGED,2018-06-03T03:59:24Z,2018-07-02T18:09:26Z,HirId-ification continued,zackmdavis,f23d90a1475e65915923814d4ad3d8d183b24c7e,1,add FIXMEs pleading for post-@ edit of commentary on mem_categorization (The present author fears not being knowledgeable enough to rewrite the comments unilaterally; merely calling it out is a lazy half-measure but at least doesn't actively make things worse the way an ill-informed rewrite would.),HOORAY,2018-07-02T18:19:20Z,estebank,NA https://github.com/rust-lang/rust/pull/51321,MERGED,2018-06-03T03:59:24Z,2018-07-02T18:09:26Z,HirId-ification continued,zackmdavis,f23d90a1475e65915923814d4ad3d8d183b24c7e,1,add FIXMEs pleading for post-@ edit of commentary on mem_categorization (The present author fears not being knowledgeable enough to rewrite the comments unilaterally; merely calling it out is a lazy half-measure but at least doesn't actively make things worse the way an ill-informed rewrite would.),HOORAY,2018-07-06T18:26:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51323,MERGED,2018-06-03T09:00:45Z,2018-06-04T04:57:46Z,Generate br for all two target SwitchInts,nikic,4f4f7dfc00d69b8a94638ed1d9e666ada9911217,1,Generate br for all two target SwitchInts Instead of only for booleans. This means that if let also becomes a br. Apart from making the IR slightly simpler this is supported by FastISel.,THUMBS_UP,2018-06-03T11:12:55Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51329,MERGED,2018-06-03T17:11:56Z,2018-06-04T04:57:47Z,Remove the unused `-Z trans-time-graph` flag.,kennytm,efa02b6d2fff602c464ad2d0cd912fc4e6789dff,1,Remove the unused `-Z trans-time-graph` flag. Rebase of #50783 has accidentally revived the flag (which should be renamed to `-Z codegen-time-graph` by #50615).,HEART,2018-06-03T17:43:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51339,MERGED,2018-06-04T07:50:26Z,2018-07-12T22:09:43Z,Add ExactChunks::remainder and ExactChunks::into_remainder,sdroege,903624fb8d845afac62b1fca2d9114c04ef35fea,2,Add ExactChunks::remainder and ExactChunks::into_remainder These allow to get the leftover items of the slice that are not being iterated as part of the iterator due to not filling a complete chunk. The mutable version consumes the slice because otherwise we would either a) have to borrow the iterator instead of taking the lifetime of the underlying slice which is not what *any* of the other iterator functions is doing or b) would allow returning multiple mutable references to the same data The current behaviour of consuming the iterator is consistent with IterMut::into_slice for the normal iterator.,HOORAY,2018-06-04T12:16:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51339,MERGED,2018-06-04T07:50:26Z,2018-07-12T22:09:43Z,Add ExactChunks::remainder and ExactChunks::into_remainder,sdroege,903624fb8d845afac62b1fca2d9114c04ef35fea,2,Add ExactChunks::remainder and ExactChunks::into_remainder These allow to get the leftover items of the slice that are not being iterated as part of the iterator due to not filling a complete chunk. The mutable version consumes the slice because otherwise we would either a) have to borrow the iterator instead of taking the lifetime of the underlying slice which is not what *any* of the other iterator functions is doing or b) would allow returning multiple mutable references to the same data The current behaviour of consuming the iterator is consistent with IterMut::into_slice for the normal iterator.,HOORAY,2018-07-19T04:18:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51363,MERGED,2018-06-05T08:50:02Z,2018-09-11T11:26:29Z,stabilize #[used],japaric,d37658afbda2a74f35e0d3fb479fcb6985bb9e53,1,bump version,HEART,2018-06-09T06:47:23Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/51363,MERGED,2018-06-05T08:50:02Z,2018-09-11T11:26:29Z,stabilize #[used],japaric,d37658afbda2a74f35e0d3fb479fcb6985bb9e53,1,bump version,HEART,2018-09-11T12:24:23Z,est31,NA https://github.com/rust-lang/rust/pull/51363,MERGED,2018-06-05T08:50:02Z,2018-09-11T11:26:29Z,stabilize #[used],japaric,d37658afbda2a74f35e0d3fb479fcb6985bb9e53,1,bump version,HEART,2018-09-19T15:15:48Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/51363,MERGED,2018-06-05T08:50:02Z,2018-09-11T11:26:29Z,stabilize #[used],japaric,d37658afbda2a74f35e0d3fb479fcb6985bb9e53,1,bump version,HEART,2018-09-20T07:55:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-06-05T11:22:34Z,alevy,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-06-05T14:35:47Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-06-05T19:09:40Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-06-06T00:20:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-06-12T03:59:43Z,est31,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HEART,2018-06-18T09:23:00Z,niklasad1,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-07T20:28:18Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-08T11:59:09Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-08T15:27:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-08T21:09:46Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-11T08:17:12Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-12T15:28:52Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-09-12T19:32:43Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-10-07T02:45:40Z,RandomInsano,EdwinGuy@GMail.com https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-10-25T18:42:50Z,gdox,NA https://github.com/rust-lang/rust/pull/51366,MERGED,2018-06-05T09:30:18Z,2018-09-08T11:53:18Z,stabilize #[panic_handler],japaric,358fc5b62126f997a1c38ba4c8be60ae16e4a2c4,25,stabilize `#[panic_handler]`,HOORAY,2018-10-29T20:33:29Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/51384,MERGED,2018-06-05T23:44:03Z,2018-08-31T19:59:56Z,rustdoc: add flag to control the html_root_url of dependencies,QuietMisdreavus,fcb54f674ab5f86b72ef97178a3df255f1ef4783,1,add test for --extern-html-root-url,HOORAY,2018-06-05T23:56:34Z,est31,NA https://github.com/rust-lang/rust/pull/51384,MERGED,2018-06-05T23:44:03Z,2018-08-31T19:59:56Z,rustdoc: add flag to control the html_root_url of dependencies,QuietMisdreavus,fcb54f674ab5f86b72ef97178a3df255f1ef4783,1,add test for --extern-html-root-url,HOORAY,2018-06-09T10:11:44Z,onur,onur@onur.im https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,HEART,2018-06-06T10:30:06Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,THUMBS_UP,2018-06-06T11:11:20Z,Valinora,NA https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,HEART,2018-06-06T12:51:35Z,killercup,NA https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,HEART,2018-06-06T13:19:51Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,THUMBS_UP,2018-06-06T14:27:07Z,berkus,NA https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,THUMBS_UP,2018-06-06T15:16:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,THUMBS_UP,2018-06-06T18:27:13Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,HEART,2018-06-06T23:57:40Z,fhartwig,florian.j.hartwig@gmail.com https://github.com/rust-lang/rust/pull/51394,MERGED,2018-06-06T10:13:26Z,2018-06-09T01:33:01Z,Use scope tree depths to speed up `nearest_common_ancestor`.,nnethercote,5c36e01f35c1e0290afd654367c2ba1e2353ca36,2,Use scope tree depths to speed up `nearest_common_ancestor`. This patch adds depth markings to all entries in the `ScopeTree`'s `parent_map`. This change increases memory usage somewhat but permits a much faster algorithm to be used: - If one scope has a greater depth than the other the deeper scope is moved upward until they are at equal depths. - Then we move the two scopes upward in lockstep until they match. This avoids the need to keep track of which scopes have already been seen which was the major part of the cost of the old algorithm. It also reduces the number of child-to-parent moves (which are hash table lookups) when the scopes start at different levels because it never goes past the nearest common ancestor the way the old algorithm did. Finally the case where one of the scopes is the root is now handled in advance because that is moderately common and lets us skip everything. This change speeds up runs of several rust-perf benchmarks the best by 6%.,THUMBS_UP,2018-06-14T11:58:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-06T11:46:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-06T12:01:14Z,lqd,NA https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-06T12:23:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,THUMBS_UP,2018-06-06T16:13:59Z,fitzgen,NA https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-06T21:40:08Z,estebank,NA https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-08T11:28:03Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,HEART,2018-06-09T03:04:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,THUMBS_UP,2018-06-14T16:03:14Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,THUMBS_UP,2018-06-29T13:40:06Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/51395,MERGED,2018-06-06T11:38:22Z,2018-07-04T18:15:20Z,Add #[repr(transparent)] to some libcore types,SimonSapin,530d7bc5174e93682a38b22ac7ff4e3569bcd813,5,Add #[repr(transparent)] to some libcore types * `UnsafeCell` * `Cell` * `NonZero*` * `NonNull` * `Unique`,THUMBS_UP,2018-07-12T07:55:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-06T21:04:32Z,est31,NA https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-13T06:40:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-13T09:46:59Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-13T13:46:01Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,LAUGH,2018-06-13T18:02:43Z,StefanoD,NA https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-13T18:02:55Z,StefanoD,NA https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-14T12:01:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HOORAY,2018-06-14T12:16:27Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51399,MERGED,2018-06-06T16:32:56Z,2018-06-08T02:01:13Z,NLL performance boost,ngg,f1c92476634485c6a2fb17d33046cedddaa150a2,1,NLL performance boost,HEART,2018-06-17T11:32:52Z,pyfisch,NA https://github.com/rust-lang/rust/pull/51400,MERGED,2018-06-06T16:42:42Z,2018-06-09T12:35:35Z,Increase number of usages of `u8` in weird expressions u8 test,xfix,b7fcf8f576956174e4ebf83aa2d0867a21e8d364,1,Increase number of usages of `u8` in weird expressions u8 test,LAUGH,2018-06-06T18:55:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/51400,MERGED,2018-06-06T16:42:42Z,2018-06-09T12:35:35Z,Increase number of usages of `u8` in weird expressions u8 test,xfix,b7fcf8f576956174e4ebf83aa2d0867a21e8d364,1,Increase number of usages of `u8` in weird expressions u8 test,LAUGH,2018-06-06T18:58:44Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51400,MERGED,2018-06-06T16:42:42Z,2018-06-09T12:35:35Z,Increase number of usages of `u8` in weird expressions u8 test,xfix,b7fcf8f576956174e4ebf83aa2d0867a21e8d364,1,Increase number of usages of `u8` in weird expressions u8 test,LAUGH,2018-06-06T21:54:33Z,est31,NA https://github.com/rust-lang/rust/pull/51400,MERGED,2018-06-06T16:42:42Z,2018-06-09T12:35:35Z,Increase number of usages of `u8` in weird expressions u8 test,xfix,b7fcf8f576956174e4ebf83aa2d0867a21e8d364,1,Increase number of usages of `u8` in weird expressions u8 test,LAUGH,2018-06-06T22:23:04Z,mcarton,NA https://github.com/rust-lang/rust/pull/51400,MERGED,2018-06-06T16:42:42Z,2018-06-09T12:35:35Z,Increase number of usages of `u8` in weird expressions u8 test,xfix,b7fcf8f576956174e4ebf83aa2d0867a21e8d364,1,Increase number of usages of `u8` in weird expressions u8 test,LAUGH,2018-06-09T06:27:39Z,kennytm,NA https://github.com/rust-lang/rust/pull/51404,MERGED,2018-06-06T23:42:49Z,2018-06-18T00:28:12Z,impl Hash for !,clarfonthey,570590f7271ddd1bcedf14a7bbc38975db720419,1,impl Hash for !,THUMBS_UP,2018-06-06T23:44:04Z,cramertj,NA https://github.com/rust-lang/rust/pull/51404,MERGED,2018-06-06T23:42:49Z,2018-06-18T00:28:12Z,impl Hash for !,clarfonthey,570590f7271ddd1bcedf14a7bbc38975db720419,1,impl Hash for !,THUMBS_UP,2018-06-15T02:02:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51404,MERGED,2018-06-06T23:42:49Z,2018-06-18T00:28:12Z,impl Hash for !,clarfonthey,570590f7271ddd1bcedf14a7bbc38975db720419,1,impl Hash for !,THUMBS_UP,2018-06-20T04:22:44Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/51404,MERGED,2018-06-06T23:42:49Z,2018-06-18T00:28:12Z,impl Hash for !,clarfonthey,570590f7271ddd1bcedf14a7bbc38975db720419,1,impl Hash for !,THUMBS_UP,2018-06-30T05:22:58Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/51404,MERGED,2018-06-06T23:42:49Z,2018-06-18T00:28:12Z,impl Hash for !,clarfonthey,570590f7271ddd1bcedf14a7bbc38975db720419,1,impl Hash for !,THUMBS_UP,2018-07-01T15:15:07Z,hcpl,NA https://github.com/rust-lang/rust/pull/51408,CLOSED,2018-06-07T05:15:48Z,2018-07-03T15:45:14Z,[WIP]: Remove libbacktrace,est31,NA,NA,NA,HOORAY,2018-06-08T07:56:18Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/51408,CLOSED,2018-06-07T05:15:48Z,2018-07-03T15:45:14Z,[WIP]: Remove libbacktrace,est31,NA,NA,NA,HOORAY,2018-06-08T19:06:31Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/51408,CLOSED,2018-06-07T05:15:48Z,2018-07-03T15:45:14Z,[WIP]: Remove libbacktrace,est31,NA,NA,NA,HOORAY,2018-06-12T05:34:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51408,CLOSED,2018-06-07T05:15:48Z,2018-07-03T15:45:14Z,[WIP]: Remove libbacktrace,est31,NA,NA,NA,HOORAY,2018-06-12T19:37:34Z,cramertj,NA https://github.com/rust-lang/rust/pull/51410,MERGED,2018-06-07T09:54:15Z,2018-06-08T20:41:48Z,Update the cargo submodule,oli-obk,0288ab03a98c1f62a72678008d8c69465cad7d9a,1,Update the cargo submodule,THUMBS_UP,2018-06-07T11:48:27Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51410,MERGED,2018-06-07T09:54:15Z,2018-06-08T20:41:48Z,Update the cargo submodule,oli-obk,0288ab03a98c1f62a72678008d8c69465cad7d9a,1,Update the cargo submodule,THUMBS_UP,2018-06-07T20:51:38Z,mati865,NA https://github.com/rust-lang/rust/pull/51411,MERGED,2018-06-07T10:23:06Z,2018-06-16T05:17:35Z,Speed up obligation forest code,nnethercote,c83d152ebae3667e5545245acbe1b14bf0b74236,3,Introduce `ProcessResult`. A tri-valued enum is nicer than Result> and it's slightly faster.,HOORAY,2018-06-20T20:57:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51411,MERGED,2018-06-07T10:23:06Z,2018-06-16T05:17:35Z,Speed up obligation forest code,nnethercote,c83d152ebae3667e5545245acbe1b14bf0b74236,3,Introduce `ProcessResult`. A tri-valued enum is nicer than Result> and it's slightly faster.,HOORAY,2018-06-23T00:58:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51436,MERGED,2018-06-08T14:31:32Z,2018-06-09T01:33:06Z,Do not require stage 2 compiler for rustdoc,Mark-Simulacrum,721f2e789ae821e85f30ac6bfad8da31b6f1c692,1,Do not require stage 2 compiler for rustdoc,HEART,2018-06-13T06:39:55Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51442,MERGED,2018-06-08T20:51:19Z,2018-06-11T22:23:23Z,[futures] add a few blanket impls to std,tinaun,fb507cadf32e1eacccc07c1c3511636fd6378f7b,2,add inherent methods to Poll,HEART,2018-06-09T18:21:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51450,MERGED,2018-06-09T01:25:44Z,2018-07-03T20:10:12Z,Add lint warning for inner function marked as `#[test]`,estebank,51a0425f36f313a08a6925612e772c7302525991,4,rename lint to `unnameable-test-functions`,THUMBS_UP,2018-06-12T04:25:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51460,MERGED,2018-06-09T21:20:50Z,2018-06-18T18:52:08Z,Improve memoization and refactor NLL type check,nikomatsakis,2e25bed9b1552a8af58fb3fe21d8db69a6114a18,4,remove some `#[inline(never)]`,HOORAY,2018-06-12T20:22:47Z,lqd,NA https://github.com/rust-lang/rust/pull/51460,MERGED,2018-06-09T21:20:50Z,2018-06-18T18:52:08Z,Improve memoization and refactor NLL type check,nikomatsakis,2e25bed9b1552a8af58fb3fe21d8db69a6114a18,4,remove some `#[inline(never)]`,HOORAY,2018-06-18T03:17:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51460,MERGED,2018-06-09T21:20:50Z,2018-06-18T18:52:08Z,Improve memoization and refactor NLL type check,nikomatsakis,2e25bed9b1552a8af58fb3fe21d8db69a6114a18,4,remove some `#[inline(never)]`,HOORAY,2018-06-20T06:30:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51463,MERGED,2018-06-09T23:19:44Z,2018-06-22T05:25:50Z,Various changes to existing diagnostics,estebank,28cea50a46f4669b94d8332bf64d07e7e5a02d79,4,Update error code numbers,THUMBS_UP,2018-06-29T06:49:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51466,MERGED,2018-06-10T05:33:50Z,2018-06-17T09:48:25Z,Add Ref/RefMut map_split method,joshlf,2a999b4b525ed8b4f735e233cc065b292d3eeb03,3,Add Ref/RefMut map_split method,HOORAY,2018-06-20T21:00:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51475,MERGED,2018-06-10T12:05:13Z,2018-06-11T00:32:40Z,Fix error codes,GuillaumeGomez,f2349d5ec6d2f184d8b83cebe255834f927568c3,11,Fix error codes,THUMBS_UP,2018-06-10T12:36:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51475,MERGED,2018-06-10T12:05:13Z,2018-06-11T00:32:40Z,Fix error codes,GuillaumeGomez,f2349d5ec6d2f184d8b83cebe255834f927568c3,11,Fix error codes,THUMBS_UP,2018-06-10T21:22:48Z,estebank,NA https://github.com/rust-lang/rust/pull/51482,MERGED,2018-06-10T22:32:15Z,2018-06-23T00:07:05Z,Greatly improve tables display in docs,GuillaumeGomez,de974645e1a7ae7567ec9eacfd57513f802cd4d3,1,Greatly improve tables display in docs,HOORAY,2018-06-11T05:42:56Z,pitdicker,NA https://github.com/rust-lang/rust/pull/51482,MERGED,2018-06-10T22:32:15Z,2018-06-23T00:07:05Z,Greatly improve tables display in docs,GuillaumeGomez,de974645e1a7ae7567ec9eacfd57513f802cd4d3,1,Greatly improve tables display in docs,THUMBS_UP,2018-06-27T03:30:10Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51482,MERGED,2018-06-10T22:32:15Z,2018-06-23T00:07:05Z,Greatly improve tables display in docs,GuillaumeGomez,de974645e1a7ae7567ec9eacfd57513f802cd4d3,1,Greatly improve tables display in docs,THUMBS_UP,2018-06-27T09:28:40Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51485,MERGED,2018-06-11T02:46:38Z,2018-07-22T01:54:06Z,Remove highlighting from secondary messages,estebank,ed5dcc31182631a8df8818f4896179177d607fcf,2,Remove highlighting from secondary messages Deemphasize the secondary messages so that all other highlights stand out more.,HOORAY,2018-06-18T03:13:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51487,MERGED,2018-06-11T06:58:34Z,2019-01-13T22:20:44Z,Make more passes incremental,Zoxc,e69c2c75d6d279ffd636634b0cde2529bbf8b6f5,7,Address comments,THUMBS_UP,2019-01-18T06:25:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HEART,2018-06-11T17:33:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HOORAY,2018-06-11T17:33:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HEART,2018-06-12T03:38:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HEART,2018-06-20T19:15:21Z,niklasad1,NA https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HOORAY,2018-06-20T20:05:18Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HEART,2018-06-25T21:43:16Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/51496,MERGED,2018-06-11T13:30:24Z,2018-06-27T13:26:14Z,Implement `#[macro_export(local_inner_macros)]` (a solution for the macro helper import problem),petrochenkov,d347270e0c241823d6e3333060f5ee902fffee6a,19,Implement `#[macro_export(local_inner_macros)]`,HOORAY,2018-07-06T18:40:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51500,CLOSED,2018-06-11T15:51:58Z,2018-06-18T09:49:43Z,Add a system for explicitly marking const fns as promotable,oli-obk,NA,NA,NA,HOORAY,2018-06-11T15:56:08Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51514,CLOSED,2018-06-12T08:34:59Z,2018-07-09T10:50:22Z,[WIP Do not merge] Helpful stack overflow messages.,gilescope,NA,NA,NA,THUMBS_UP,2018-06-12T11:45:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51527,MERGED,2018-06-12T23:54:59Z,2018-06-13T12:12:45Z,Don't auto-hide inherent impls even if `rustdoc-collapse == true`.,kennytm,ca65a5e485761ed06e88756d9066156109b0755f,1,Don't auto-hide inherent impls even if `rustdoc-collapse == true`.,THUMBS_UP,2018-06-20T05:59:12Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51536,MERGED,2018-06-13T15:16:55Z,2018-07-01T17:53:50Z,NLL: bad error message when converting anonymous lifetime to `'static`,davidtwco,c0c4741ef794d707a4378ace1547e8a41961016a,6,Updated affected tests after rebase.,THUMBS_UP,2018-06-27T23:07:03Z,lqd,NA https://github.com/rust-lang/rust/pull/51538,MERGED,2018-06-13T15:51:06Z,2018-06-28T03:57:38Z,convert NLL ops to caches,nikomatsakis,1523de34a2267b624f1b920c1b4496568bd8c16b,4,rustfmt various files,HOORAY,2018-06-14T13:03:33Z,lqd,NA https://github.com/rust-lang/rust/pull/51538,MERGED,2018-06-13T15:51:06Z,2018-06-28T03:57:38Z,convert NLL ops to caches,nikomatsakis,1523de34a2267b624f1b920c1b4496568bd8c16b,4,rustfmt various files,HOORAY,2018-06-26T23:53:30Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/51538,MERGED,2018-06-13T15:51:06Z,2018-06-28T03:57:38Z,convert NLL ops to caches,nikomatsakis,1523de34a2267b624f1b920c1b4496568bd8c16b,4,rustfmt various files,HOORAY,2018-07-04T17:22:47Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51538,MERGED,2018-06-13T15:51:06Z,2018-06-28T03:57:38Z,convert NLL ops to caches,nikomatsakis,1523de34a2267b624f1b920c1b4496568bd8c16b,4,rustfmt various files,HOORAY,2018-07-06T18:32:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2018-06-14T12:34:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2018-06-15T14:56:27Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2018-07-02T20:25:36Z,mati865,NA https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2018-07-11T16:57:16Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2018-07-12T07:53:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51548,MERGED,2018-06-14T06:21:33Z,2018-07-03T14:31:19Z,Initialize LLVM's AMDGPU target machine if available.,DiamondLovesYou,b4d64b7b28038d7e4b0bc75f1d407d5382512996,1,Initialize LLVM's AMDGPU target machine if available. Note this isn't useful yet. More changes will be necessary to be able to actually codegen for this machine. As such it is not enabled by default. This patch is on its own for the benefit of the reviewers.,HEART,2019-04-17T01:46:05Z,Wulfsta,wulfstawulfsta@gmail.com https://github.com/rust-lang/rust/pull/51558,MERGED,2018-06-14T17:47:51Z,2018-06-16T21:48:50Z,Fix my comment on editions,Manishearth,dc943349bd0bcc5ab0b849537c6198ab8f1470b7,1,Fix comment on editions,LAUGH,2018-06-14T18:20:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/51558,MERGED,2018-06-14T17:47:51Z,2018-06-16T21:48:50Z,Fix my comment on editions,Manishearth,dc943349bd0bcc5ab0b849537c6198ab8f1470b7,1,Fix comment on editions,LAUGH,2018-06-15T01:15:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51558,MERGED,2018-06-14T17:47:51Z,2018-06-16T21:48:50Z,Fix my comment on editions,Manishearth,dc943349bd0bcc5ab0b849537c6198ab8f1470b7,1,Fix comment on editions,LAUGH,2018-06-17T13:47:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-14T19:38:30Z,cramertj,NA https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-14T21:02:33Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-14T22:10:12Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-17T07:17:04Z,lqd,NA https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-20T05:02:40Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-20T06:31:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-06-20T20:43:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HEART,2018-08-03T18:49:19Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/51562,MERGED,2018-06-14T19:01:36Z,2018-06-16T13:08:33Z,Stabilize #[repr(transparent)],SimonSapin,e2aef92c19a95d6a0b8e75b473023f77de6150f0,17,Stabilize #[repr(transparent)] Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318 Reference PR: https://github.com/rust-lang-nursery/reference/pull/353,HOORAY,2018-08-03T19:05:57Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2018-06-17T10:18:44Z,berkus,NA https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2018-06-25T15:23:48Z,snim2,s.mount@aston.ac.uk https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2018-07-11T23:54:29Z,estebank,NA https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2018-07-12T07:55:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2021-04-06T21:20:11Z,Stargateur,NA https://github.com/rust-lang/rust/pull/51564,MERGED,2018-06-14T21:32:46Z,2018-07-03T07:06:54Z,Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms,SimonSapin,e7c122c5b58d4db2262b1f4325d9fe82d1423ad8,4,"Revert ""Remove TryFrom impls that might become conditionally-infallible with a portability lint"" This reverts commit 837d6c70233715a0ae8e15c703d40e3046a2f36a. Fixes https://github.com/rust-lang/rust/issues/49415",THUMBS_UP,2022-04-21T17:56:06Z,xkr47,NA https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,THUMBS_UP,2018-06-18T21:28:39Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,HEART,2018-06-18T21:29:00Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,THUMBS_UP,2018-06-19T20:03:22Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,HEART,2018-06-19T20:03:23Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,THUMBS_UP,2018-06-23T17:44:29Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/51569,MERGED,2018-06-15T02:13:48Z,2018-06-29T20:22:13Z,Make the public API of the alloc crate a subset of std,SimonSapin,15bb6c431da6f486fd048a00ba9c72fe5bc2dd74,1,liballoc docs: Remove “not intended for general usage”,THUMBS_UP,2018-07-06T18:59:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51576,CLOSED,2018-06-15T15:12:46Z,2019-03-11T22:20:38Z,Make `librustc_codegen_llvm` aware of LLVM address spaces.,DiamondLovesYou,NA,NA,NA,THUMBS_UP,2018-08-11T18:21:38Z,mati865,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-15T21:38:48Z,sfackler,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-15T21:49:57Z,lqd,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-15T22:01:46Z,killercup,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-15T23:24:50Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T00:11:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T00:21:54Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T01:31:01Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T04:16:05Z,tinaun,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T05:14:16Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T05:14:25Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T05:14:28Z,luthfianto,mrluthfianto@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T05:19:08Z,utam0k,k0ma@utam0k.jp https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T05:19:09Z,utam0k,k0ma@utam0k.jp https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T05:26:21Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T05:28:14Z,rozaliev,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T05:45:22Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T05:45:24Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T06:36:41Z,frol,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T06:36:56Z,nirui,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T06:58:52Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T06:58:54Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T06:58:56Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:00:57Z,babariviere,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T07:02:47Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:02:48Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T07:02:50Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:19:39Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:26:29Z,aheart,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T07:30:17Z,mjduijn,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T07:32:35Z,phonkee,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T07:40:50Z,andrewhickman,andrew.hickman1@sky.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T07:41:53Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:41:53Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T07:41:54Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T07:56:47Z,oberien,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:11:21Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:12:04Z,marcelbuesing,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T08:31:01Z,AgtLucas,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:31:02Z,AgtLucas,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:35:12Z,Selicre,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:36:53Z,eksuri,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:37:43Z,jmatraszek,jakub.matraszek@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T08:37:45Z,jmatraszek,jakub.matraszek@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T08:56:27Z,yishn,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T08:58:30Z,ava57r,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:19:31Z,anderejd,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:21:29Z,rushmorem,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:23:22Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T09:23:45Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T09:23:46Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:31:48Z,palango,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:39:11Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T09:39:12Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T09:48:44Z,howdoicomputer,dr.frankinfurter@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T09:48:45Z,howdoicomputer,dr.frankinfurter@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T09:48:47Z,howdoicomputer,dr.frankinfurter@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T10:03:12Z,Dowwie,dkcdkg@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T10:18:19Z,dd10-e,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T10:24:24Z,arthurprs,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T10:32:13Z,pmarino90,paolo.marino@hey.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T10:32:16Z,pmarino90,paolo.marino@hey.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T10:34:06Z,jzimmek,jan.zimmek@web.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T10:48:19Z,paulogdm,me@paulogdm.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T10:48:21Z,paulogdm,me@paulogdm.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T10:58:12Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T11:06:50Z,est31,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T11:06:52Z,est31,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T11:06:54Z,est31,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T11:12:46Z,au5ton,austinjckson@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T11:18:55Z,dailypips,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T11:19:37Z,joshleeb,mail@joshleeb.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T11:29:05Z,tinco,mail@tinco.nl https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T11:41:48Z,myaats,mats@mats.sh https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T11:41:50Z,myaats,mats@mats.sh https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T11:41:56Z,myaats,mats@mats.sh https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T11:45:57Z,HelloEdit,corentin.poupry@edu.esiee.fr https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T12:00:02Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T12:00:03Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T12:01:11Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T12:01:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T12:08:35Z,alper,github@alper.nl https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T12:32:39Z,XX,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T12:34:50Z,kyrias,johannes@kyriasis.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:00:35Z,luleyleo,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T13:30:48Z,FerrielMelarpis,ferriel@canva.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:30:50Z,FerrielMelarpis,ferriel@canva.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T13:30:51Z,FerrielMelarpis,ferriel@canva.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:34:02Z,daniel-levin,daniellevin2607@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T13:35:47Z,paolodellepiane,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T13:39:57Z,georich,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:39:59Z,georich,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T13:40:00Z,georich,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:40:05Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:47:27Z,ngg,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T13:53:59Z,davidbarsky,me@davidbarsky.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T14:04:33Z,crlf0710,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T14:09:39Z,rojasleon,rojasleon.dev@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T14:22:19Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T14:47:33Z,achanda,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T14:47:34Z,achanda,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T14:47:35Z,achanda,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T14:48:55Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T15:45:59Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T16:01:28Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T16:05:34Z,yask123,yask.srivastava@shopify.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T16:07:57Z,tikue,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T16:18:02Z,gsalaz98,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T16:18:56Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T16:18:58Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T16:18:58Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T17:37:03Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T17:37:04Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T17:37:04Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T17:45:41Z,flosse,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T17:45:45Z,flosse,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T17:45:46Z,flosse,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T17:46:36Z,CodeBrew28,arshiam2828@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T17:59:41Z,discosultan,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T18:04:53Z,siygle,shiyung+github@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T18:16:26Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T18:16:27Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T18:16:28Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T18:28:29Z,tjkirch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T18:28:32Z,tjkirch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T18:28:33Z,tjkirch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T18:29:50Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T18:45:20Z,raviqqe,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T18:45:31Z,raviqqe,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T18:46:44Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T19:00:29Z,MichaelTheriot,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T19:10:23Z,arrizalamin,arrizalamin@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T19:18:03Z,chmln,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T19:18:09Z,chmln,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T19:18:12Z,chmln,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T19:20:47Z,maxkrieger,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T19:36:27Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T20:06:50Z,r3nya,me@r3nya.ru https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T20:48:43Z,cyplo,cyplo@cyplo.net https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T20:59:50Z,fundon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T20:59:51Z,fundon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T21:12:08Z,ds84182,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T21:12:09Z,ds84182,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T21:12:09Z,ds84182,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T21:19:12Z,athiwatc,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T21:19:13Z,athiwatc,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T21:19:14Z,athiwatc,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T21:41:58Z,Powersource,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T21:47:26Z,shimbaco,me@shimba.co https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T21:54:08Z,Valloric,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T22:04:27Z,alex34567,eckhartalex@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T22:15:49Z,kornholi,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T22:15:49Z,kornholi,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T22:15:50Z,kornholi,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T22:36:32Z,clarkzinzow,clark@anyscale.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T22:36:33Z,clarkzinzow,clark@anyscale.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T22:36:34Z,clarkzinzow,clark@anyscale.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T23:12:46Z,johnnyasantoss,johnnyadsantos@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T23:12:50Z,johnnyasantoss,johnnyadsantos@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T23:12:53Z,johnnyasantoss,johnnyadsantos@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T23:16:36Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-16T23:29:14Z,rauchg,rauchg@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-16T23:29:15Z,rauchg,rauchg@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-16T23:29:15Z,rauchg,rauchg@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T00:23:19Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-17T00:23:20Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T00:23:20Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T01:05:29Z,fundon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T02:33:47Z,leaxoy,lixiaohui0812@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T02:59:17Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T03:01:46Z,thedodd,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T03:01:49Z,thedodd,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-17T03:01:51Z,thedodd,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T05:06:12Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T05:23:18Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T07:17:09Z,beardedeagle,randy@heroictek.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T07:17:10Z,beardedeagle,randy@heroictek.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-17T07:17:12Z,beardedeagle,randy@heroictek.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T07:44:41Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T09:47:03Z,qnighy,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T09:47:13Z,qnighy,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-17T09:47:16Z,qnighy,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T10:08:06Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-17T11:31:52Z,thedrow,omer.katz@omerkatz.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T11:31:54Z,thedrow,omer.katz@omerkatz.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T11:31:56Z,thedrow,omer.katz@omerkatz.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-17T12:08:37Z,huxi,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-17T15:10:25Z,MichalLytek,michal.wojciech.lytek@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T02:56:18Z,blueridanus,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T03:07:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T04:32:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-18T08:25:34Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T08:25:35Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-18T08:25:36Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-18T12:13:03Z,mschorsch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T12:13:07Z,mschorsch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-18T12:13:09Z,mschorsch,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T13:58:57Z,kjvalencik,kj@valencik.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-18T14:02:43Z,rbuchmann,rasmus.buchmann@gmx.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-19T02:06:28Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-19T10:23:32Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-19T10:23:32Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-19T10:23:35Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-19T16:12:01Z,buntpfotenkatze,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-19T18:19:01Z,estk,esims89@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-19T18:19:03Z,estk,esims89@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-20T07:50:27Z,michalczaplinski,mmczaplinski@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-20T16:13:22Z,tux3,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-21T03:08:11Z,gsquire,github@garrettsquire.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-22T08:27:55Z,ufoscout,ufoscout@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-22T21:22:02Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-22T21:22:04Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-22T21:22:05Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T11:15:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-23T12:51:08Z,Pzixel,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-23T13:05:50Z,brotzeit,brotzeitmacher@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T13:39:23Z,Bigomby,bigomby@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T14:08:27Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T14:11:23Z,renato-zannon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T14:14:10Z,fodil-a,dev@fodil.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T14:56:37Z,sticnarf,sticnarf@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-23T15:28:57Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T15:33:43Z,pgyer-framework,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-23T18:00:32Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T19:33:46Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-23T20:08:29Z,AndreasHassing,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T20:36:53Z,yerke,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-23T20:56:45Z,liranringel,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-23T21:49:46Z,drklee3,hello@dlee.dev https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-23T22:22:54Z,hyunsik,hyunsik@apache.org https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T01:46:18Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T02:48:10Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T02:48:12Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T03:34:08Z,incon,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T06:00:33Z,sudeep9,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T07:43:57Z,wyshk2007,251075893@qq.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T07:44:11Z,wyshk2007,251075893@qq.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-24T07:44:14Z,wyshk2007,251075893@qq.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T09:20:07Z,futile,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T09:20:08Z,futile,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T09:33:58Z,divslinger,oskar@oldorf.net https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T09:34:00Z,divslinger,oskar@oldorf.net https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-24T12:08:53Z,pinylin,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T12:08:54Z,pinylin,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-24T12:08:57Z,pinylin,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T16:46:33Z,max-frai,me@maxfrai.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-24T17:44:00Z,davll,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-25T00:49:18Z,mastfissh,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-25T02:42:56Z,iPixelOldC,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-25T04:16:39Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-25T04:32:07Z,uonr,me@yuru.me https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-25T05:36:24Z,tomoyat1,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-25T10:56:18Z,mati865,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-25T12:47:09Z,Skarlso,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-25T12:47:10Z,Skarlso,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-25T12:47:11Z,Skarlso,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-26T04:21:56Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-26T22:14:45Z,iskeld,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-26T22:14:46Z,iskeld,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-26T22:14:47Z,iskeld,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-27T06:09:32Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-27T07:11:57Z,chpio,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T07:11:58Z,chpio,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T14:56:17Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T15:05:51Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T17:30:59Z,JesseWright,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-27T17:30:59Z,JesseWright,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-27T17:31:02Z,JesseWright,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-27T18:29:19Z,libreoscar,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T18:29:20Z,libreoscar,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-27T18:29:21Z,libreoscar,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T20:49:13Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-27T23:00:15Z,jgrosso,jgrosso256@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-27T23:00:16Z,jgrosso,jgrosso256@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-27T23:00:17Z,jgrosso,jgrosso256@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-28T10:46:23Z,piedoom,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-28T13:18:20Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-28T14:41:26Z,poelzi,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-29T02:49:16Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-29T02:49:17Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-29T02:49:18Z,theotherjimmy,jimmy.brisson@arm.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-29T06:48:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-29T11:25:53Z,Antti,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-29T11:25:54Z,Antti,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-06-29T13:01:21Z,davidlgj,david.lgj@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-29T13:01:23Z,davidlgj,david.lgj@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-06-29T13:01:25Z,davidlgj,david.lgj@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-06-30T18:50:13Z,kjaleshire,kjaleshire@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-07-01T14:56:50Z,hcpl,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-07-06T03:29:22Z,Reconcyl,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-07-10T16:50:40Z,denzp,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-07-16T07:34:29Z,samsartor,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-07-23T12:59:02Z,sinclairzx81,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-08-29T01:02:49Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-08-29T01:02:51Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-08-29T01:02:52Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-10-23T04:18:15Z,PeterDing,dfhayst@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2018-11-02T11:08:45Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2018-11-02T11:08:48Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2018-11-02T11:08:50Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,THUMBS_UP,2019-06-01T09:00:49Z,taiki-e,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HOORAY,2019-06-01T09:00:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/51580,MERGED,2018-06-15T21:32:34Z,2018-06-23T11:01:05Z,async/await,cramertj,30c17ccbffdbb88020e6ed42d89cc214fc3e6e5f,1,Update libsyntax test,HEART,2019-06-01T09:00:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/51587,MERGED,2018-06-16T02:52:25Z,2018-07-24T17:22:49Z,2018 edition `?` Kleene operator,mark-i-m,10ee0f68a6815fafa69f58daf347f0c2a8339f32,6,Allow by default fix tests,HEART,2018-06-16T15:03:09Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51587,MERGED,2018-06-16T02:52:25Z,2018-07-24T17:22:49Z,2018 edition `?` Kleene operator,mark-i-m,10ee0f68a6815fafa69f58daf347f0c2a8339f32,6,Allow by default fix tests,HEART,2018-06-16T19:34:07Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/51587,MERGED,2018-06-16T02:52:25Z,2018-07-24T17:22:49Z,2018 edition `?` Kleene operator,mark-i-m,10ee0f68a6815fafa69f58daf347f0c2a8339f32,6,Allow by default fix tests,THUMBS_DOWN,2018-07-04T18:01:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/51587,MERGED,2018-06-16T02:52:25Z,2018-07-24T17:22:49Z,2018 edition `?` Kleene operator,mark-i-m,10ee0f68a6815fafa69f58daf347f0c2a8339f32,6,Allow by default fix tests,HEART,2018-07-25T05:25:02Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/51589,CLOSED,2018-06-16T08:40:45Z,2018-06-22T12:01:44Z,WIP: Fix unexpected E0110 when using GATs,LukasKalbertodt,NA,NA,NA,HOORAY,2018-06-18T03:06:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51599,MERGED,2018-06-16T19:29:17Z,2018-07-05T20:25:10Z,reduce search-index size,GuillaumeGomez,115df577573ffba1534e9d04bc7b131bf32cffe8,3,reduce search-index size,HOORAY,2018-06-17T13:33:50Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51599,MERGED,2018-06-16T19:29:17Z,2018-07-05T20:25:10Z,reduce search-index size,GuillaumeGomez,115df577573ffba1534e9d04bc7b131bf32cffe8,3,reduce search-index size,HOORAY,2018-06-18T03:04:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51606,CLOSED,2018-06-17T11:22:37Z,2018-07-09T11:59:37Z,Add GroupBy and GroupByMut iterators to the slice,Kerollmops,NA,NA,NA,HOORAY,2018-06-17T13:40:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51606,CLOSED,2018-06-17T11:22:37Z,2018-07-09T11:59:37Z,Add GroupBy and GroupByMut iterators to the slice,Kerollmops,NA,NA,NA,HOORAY,2018-06-18T21:27:38Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,HOORAY,2018-06-17T15:15:19Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,THUMBS_UP,2018-06-17T15:15:21Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,HOORAY,2018-06-17T16:42:28Z,geofft,geofft@ldpreload.com https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,HOORAY,2018-06-17T23:14:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,HOORAY,2018-06-18T14:11:28Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,HOORAY,2018-06-19T20:03:42Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51607,CLOSED,2018-06-17T15:04:31Z,2018-07-02T20:16:29Z,Move OOM handling to liballoc and remove the `oom` lang item,SimonSapin,NA,NA,NA,THUMBS_UP,2018-06-19T20:03:44Z,lexxvir,NA https://github.com/rust-lang/rust/pull/51609,MERGED,2018-06-17T18:06:34Z,2018-08-01T19:54:09Z,Treat gc=No characters as numeric,dscorbett,5150ff0c729b5af88da8f45f15bef1b95ba70c08,4,Treat gc=No characters as numeric,THUMBS_UP,2018-06-18T21:26:29Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-06-18T06:05:20Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-06-18T09:42:51Z,bjorn3,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-06-20T11:16:25Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-06-20T12:21:39Z,Diggsey,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,LAUGH,2018-06-21T03:33:52Z,kvark,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,LAUGH,2018-06-21T13:51:23Z,rustonaut,philipp@korber.dev https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-06-23T15:11:44Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,HEART,2018-07-13T17:54:23Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-07-24T13:37:36Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2018-08-08T14:44:48Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,LAUGH,2018-08-08T15:39:28Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_DOWN,2018-08-08T15:39:31Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_DOWN,2018-09-26T19:22:36Z,VersBinarii,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2020-04-24T02:11:25Z,acshi,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2020-06-17T14:03:03Z,kangalioo,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2020-12-10T14:36:35Z,TotalKrill,NA https://github.com/rust-lang/rust/pull/51610,CLOSED,2018-06-17T19:31:57Z,2018-08-14T16:41:14Z,Undeprecate `thread::sleep_ms`,matklad,NA,NA,NA,THUMBS_UP,2021-10-27T13:31:32Z,atanas-w,NA https://github.com/rust-lang/rust/pull/51613,MERGED,2018-06-18T00:47:43Z,2018-06-26T09:20:56Z,Obligation forest cleanup,nnethercote,70d22fa0519c8970cecbae400e7f6ebf69704d92,1,Improve `Node::{parent dependents}` interplay. This patch: - Reorders things a bit so that `parent` is always handled before `dependents`. - Uses iterator chaining to avoid some code duplication.,THUMBS_UP,2018-07-04T18:54:31Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51613,MERGED,2018-06-18T00:47:43Z,2018-06-26T09:20:56Z,Obligation forest cleanup,nnethercote,70d22fa0519c8970cecbae400e7f6ebf69704d92,1,Improve `Node::{parent dependents}` interplay. This patch: - Reorders things a bit so that `parent` is always handled before `dependents`. - Uses iterator chaining to avoid some code duplication.,THUMBS_UP,2018-07-06T18:25:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51614,MERGED,2018-06-18T01:30:52Z,2018-07-11T21:54:50Z,Correct suggestion for println,csmoe,790c09e8495d74e31073da0a88f1eacdb4a77dee,2,suggest on new snippet,HEART,2018-06-19T00:51:20Z,estebank,NA https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-06-18T10:29:25Z,mati865,NA https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-06-19T19:11:23Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-06-20T15:01:05Z,lqd,NA https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-06-27T18:46:52Z,StefanoD,NA https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-06-29T06:45:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51617,MERGED,2018-06-18T09:35:47Z,2018-06-20T03:46:27Z,Reduce number of allocations done by NLL,nnethercote,ba0bb02f6ff241297281784d2aed7dd8c2c78c4d,1,Return a `SmallVec` from `place_elements`. These vectors are always small so this avoids lots of allocations.,THUMBS_UP,2018-07-01T14:58:37Z,hcpl,NA https://github.com/rust-lang/rust/pull/51622,MERGED,2018-06-18T21:05:35Z,2018-07-13T12:19:51Z,Change RangeInclusive to a three-field struct.,kennytm,6093128ef3c5ae661ec66fbf3685833d6be217bb,3,Changed implementation of the third field to make LLVM optimize it better.,HEART,2018-06-18T21:48:17Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/51622,MERGED,2018-06-18T21:05:35Z,2018-07-13T12:19:51Z,Change RangeInclusive to a three-field struct.,kennytm,6093128ef3c5ae661ec66fbf3685833d6be217bb,3,Changed implementation of the third field to make LLVM optimize it better.,HEART,2018-06-23T23:59:11Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51622,MERGED,2018-06-18T21:05:35Z,2018-07-13T12:19:51Z,Change RangeInclusive to a three-field struct.,kennytm,6093128ef3c5ae661ec66fbf3685833d6be217bb,3,Changed implementation of the third field to make LLVM optimize it better.,HEART,2018-07-19T04:18:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51653,MERGED,2018-06-20T08:14:04Z,2018-06-23T22:27:47Z,Option::get_or_insert(_with): Replace unreachable! with unreachable_unchecked,mglagla,11341e2b069d70710cc0625c4bd3be6f851e04c7,1,Replace unreachable! with unreachable_unchecked,THUMBS_UP,2018-06-22T12:11:14Z,Vurich,NA https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2018-06-21T04:06:49Z,Screwtapello,NA https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2018-06-23T08:26:23Z,thvdburgt,thomas@thvdburgt.nl https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2018-07-12T07:16:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2018-07-12T09:36:52Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2018-08-05T12:05:14Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_DOWN,2020-06-01T15:59:32Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_DOWN,2021-05-30T02:44:35Z,Vurv78,NA https://github.com/rust-lang/rust/pull/51656,MERGED,2018-06-20T11:59:52Z,2018-07-07T03:55:16Z,Deprecate `std::env::home_dir` and fix incorrect documentation,soc,0afc16a03942931254c05846f60f3afa00d147c3,1,Deprecate `std::env::home_dir` and fix incorrect documentation,THUMBS_UP,2022-04-04T21:56:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-20T14:27:59Z,lqd,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-20T16:28:33Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-20T16:36:55Z,tmandry,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-21T05:45:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-22T03:26:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-06-25T00:11:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-08-03T12:31:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-08-08T09:22:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-08-08T16:40:14Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-08-26T11:18:40Z,emoon,NA https://github.com/rust-lang/rust/pull/51657,MERGED,2018-06-20T12:20:00Z,2018-08-03T02:53:27Z,Implement a self profiler,wesleywiser,2d3a0a99279093e024c819dda826626a088bcd7e,1,Generate self-profiler types with macros,HOORAY,2018-09-14T20:41:00Z,vramana,NA https://github.com/rust-lang/rust/pull/51660,MERGED,2018-06-20T16:14:47Z,2018-06-22T10:33:43Z,"NLL: Walk the MIR only once for the ""unused mut"" lint",lqd,63a4e721b30964022cbe7abb98dabc74f3a7a676,2,Share code between gather_used_muts and find_assignments,THUMBS_UP,2018-06-20T16:53:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/51660,MERGED,2018-06-20T16:14:47Z,2018-06-22T10:33:43Z,"NLL: Walk the MIR only once for the ""unused mut"" lint",lqd,63a4e721b30964022cbe7abb98dabc74f3a7a676,2,Share code between gather_used_muts and find_assignments,THUMBS_UP,2018-06-22T11:30:09Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/51660,MERGED,2018-06-20T16:14:47Z,2018-06-22T10:33:43Z,"NLL: Walk the MIR only once for the ""unused mut"" lint",lqd,63a4e721b30964022cbe7abb98dabc74f3a7a676,2,Share code between gather_used_muts and find_assignments,THUMBS_UP,2018-06-29T05:12:08Z,BrianOn99,chiu6700@gmail.com https://github.com/rust-lang/rust/pull/51678,MERGED,2018-06-21T11:43:10Z,2018-06-26T16:26:20Z,Combine all builtin late lints,Zoxc,c5ecc6fefbecb7fcc1393d578c0b4a5aa06dd2e2,4,Combine all builtin late lints,HEART,2018-06-25T18:23:49Z,estebank,NA https://github.com/rust-lang/rust/pull/51679,MERGED,2018-06-21T12:54:54Z,2018-06-21T20:58:47Z,[beta] Rust 1.28.0 beta,Mark-Simulacrum,09a0bc7975c1d9a98177f3e5037e67765e3b44dc,1,Fix error-chain warnings,LAUGH,2018-06-21T13:05:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/51680,MERGED,2018-06-21T12:55:47Z,2018-06-21T15:48:17Z,Revert #51662,Mark-Simulacrum,43557fc8f9ce3287be7d4872b19282bd3625b34f,3,"Revert ""Auto merge of #51662 - Mark-Simulacrum:beta-next r=Mark-Simulacrum"" This reverts commit fff1abadd7a4ec861ca4b9c77035379578ef033d reversing changes made to 01172a7d137dcba06f190241caadcaabe7c94767.",LAUGH,2018-06-21T13:02:48Z,kennytm,NA https://github.com/rust-lang/rust/pull/51688,MERGED,2018-06-21T18:09:42Z,2018-06-25T08:54:42Z,Fix erroneous error note when using field after move,spastorino,1dae309ca1c8ae89384170de2e5d4683d5f94cd4,3,Run rustfmt,HOORAY,2018-06-23T16:53:26Z,estebank,NA https://github.com/rust-lang/rust/pull/51697,MERGED,2018-06-22T01:22:25Z,2018-06-23T02:21:26Z,Add label to lint for lifetimes used once,estebank,973baaa5b2f91876e1304272fffdea2d0679554f,9,Add label to lint for lifetimes used once,HEART,2018-06-22T18:53:55Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HEART,2018-06-23T23:58:30Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HOORAY,2018-06-23T23:58:32Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HOORAY,2018-06-25T00:17:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HOORAY,2018-07-18T16:47:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HOORAY,2018-07-18T21:34:07Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/51702,MERGED,2018-06-22T08:01:08Z,2018-07-11T18:31:13Z,Infinite loop detection for const evaluation,ecstatic-morse,cf5eaa75bb171f00d6baa475333b741b86f93f72,3,Move `Eq + Hash + Clone` bounds to `Machine`,HOORAY,2018-07-19T04:28:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-22T20:31:26Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-22T20:41:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-22T21:17:45Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-22T21:41:01Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-23T00:47:00Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-23T01:39:12Z,crlf0710,NA https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HOORAY,2018-06-23T02:46:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-23T11:14:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/51722,MERGED,2018-06-22T20:26:44Z,2018-07-11T00:37:31Z,Updated RELEASES for 1.28.0,XAMPPRocky,dab257f1932718b659564a242ee450016175d12c,1,Update RELEASES.md,HEART,2018-06-27T05:38:30Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/51723,MERGED,2018-06-22T22:37:18Z,2018-06-23T13:15:32Z,Accept `TyError` in `analyze_closure` to avoid ICE,estebank,8ddf9a3360a3be0831141c714c51ad5b655c56fd,3,Accept `TyError` in `analyze_closure` to avoid ICE,THUMBS_UP,2018-06-22T23:06:25Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/51723,MERGED,2018-06-22T22:37:18Z,2018-06-23T13:15:32Z,Accept `TyError` in `analyze_closure` to avoid ICE,estebank,8ddf9a3360a3be0831141c714c51ad5b655c56fd,3,Accept `TyError` in `analyze_closure` to avoid ICE,THUMBS_UP,2018-06-22T23:53:32Z,passy,NA https://github.com/rust-lang/rust/pull/51723,MERGED,2018-06-22T22:37:18Z,2018-06-23T13:15:32Z,Accept `TyError` in `analyze_closure` to avoid ICE,estebank,8ddf9a3360a3be0831141c714c51ad5b655c56fd,3,Accept `TyError` in `analyze_closure` to avoid ICE,HEART,2018-06-22T23:53:34Z,passy,NA https://github.com/rust-lang/rust/pull/51728,MERGED,2018-06-23T10:05:00Z,2018-06-25T19:41:17Z,build: add llvm-tools to manifest,bradjc,f10da5fdb9f08a70d2917aadf51c1e7952b9027b,1,build: llvm-tools: replace compiler.host Use `target` instead.,THUMBS_UP,2018-06-23T10:06:44Z,niklasad1,NA https://github.com/rust-lang/rust/pull/51729,MERGED,2018-06-23T11:24:55Z,2018-06-29T14:44:01Z,[NLL] Better move errors,matthewjasper,2cb0a0631a640318ae288ead20758db8508f6835,16,Update tests for grouped nll move errors,THUMBS_UP,2018-06-28T00:24:23Z,lqd,NA https://github.com/rust-lang/rust/pull/51731,MERGED,2018-06-23T12:29:15Z,2018-06-26T13:18:27Z,Fix ICEs when using continue as an array length inside closures (inside loop conditions),varkor,c3d6ee9e7b652546b892bc2eac56896a8a39415a,1,Make find_breakable_scope non-mutable,HOORAY,2018-06-23T16:41:48Z,estebank,NA https://github.com/rust-lang/rust/pull/51733,MERGED,2018-06-23T13:43:25Z,2018-06-25T13:43:44Z,Fix an ICE when matching over const slices,varkor,e14e48bfaa36bda05a467dca0743dab5b10de097,2,Fix an ICE when matching over const slices,HEART,2018-06-23T16:41:33Z,estebank,NA https://github.com/rust-lang/rust/pull/51787,CLOSED,2018-06-25T19:44:19Z,2018-06-30T17:59:16Z,Iterator::map_into method,vorner,NA,NA,NA,CONFUSED,2018-06-25T19:52:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/51787,CLOSED,2018-06-25T19:44:19Z,2018-06-30T17:59:16Z,Iterator::map_into method,vorner,NA,NA,NA,THUMBS_DOWN,2018-06-27T22:05:28Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/51791,MERGED,2018-06-25T22:04:20Z,2018-06-26T13:18:33Z,Minify css,GuillaumeGomez,f7485df05bd742daf3fcb2f1aeb997877e7b86ac,3,Minify css,THUMBS_UP,2018-06-26T01:51:44Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51828,MERGED,2018-06-26T22:57:05Z,2018-06-30T16:17:28Z,Do not allow LLVM to increase a TLS's alignment on macOS.,kennytm,e3d113eca91d639c697d925d9de38b5efde70c1b,4,Do not allow LLVM to increase a TLS's alignment on macOS.,HOORAY,2018-07-01T09:00:58Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/51828,MERGED,2018-06-26T22:57:05Z,2018-06-30T16:17:28Z,Do not allow LLVM to increase a TLS's alignment on macOS.,kennytm,e3d113eca91d639c697d925d9de38b5efde70c1b,4,Do not allow LLVM to increase a TLS's alignment on macOS.,HOORAY,2018-07-02T04:40:50Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/51828,MERGED,2018-06-26T22:57:05Z,2018-06-30T16:17:28Z,Do not allow LLVM to increase a TLS's alignment on macOS.,kennytm,e3d113eca91d639c697d925d9de38b5efde70c1b,4,Do not allow LLVM to increase a TLS's alignment on macOS.,HOORAY,2018-07-05T21:42:45Z,felixrabe,NA https://github.com/rust-lang/rust/pull/51829,MERGED,2018-06-26T23:29:12Z,2018-07-14T18:28:58Z,Remove most of `PartialEq` and `Hash` impls from AST and HIR structures,petrochenkov,7d142c1e53165fea78314117f59e13257d7bf85d,8,Address comments,HEART,2018-06-29T17:35:03Z,estebank,NA https://github.com/rust-lang/rust/pull/51829,MERGED,2018-06-26T23:29:12Z,2018-07-14T18:28:58Z,Remove most of `PartialEq` and `Hash` impls from AST and HIR structures,petrochenkov,7d142c1e53165fea78314117f59e13257d7bf85d,8,Address comments,HEART,2018-06-30T14:39:09Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/51829,MERGED,2018-06-26T23:29:12Z,2018-07-14T18:28:58Z,Remove most of `PartialEq` and `Hash` impls from AST and HIR structures,petrochenkov,7d142c1e53165fea78314117f59e13257d7bf85d,8,Address comments,HEART,2018-07-02T08:09:11Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/51829,MERGED,2018-06-26T23:29:12Z,2018-07-14T18:28:58Z,Remove most of `PartialEq` and `Hash` impls from AST and HIR structures,petrochenkov,7d142c1e53165fea78314117f59e13257d7bf85d,8,Address comments,HEART,2018-07-19T04:25:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-27T04:45:01Z,nnethercote,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-27T09:30:03Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-27T10:50:35Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-27T12:31:23Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-27T20:06:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-06-30T00:04:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-07-01T18:34:46Z,est31,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-07-04T17:25:26Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-07-06T18:33:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HOORAY,2018-07-07T08:10:51Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51833,MERGED,2018-06-27T04:06:44Z,2018-07-01T20:49:16Z,Speed up compilation of large constant arrays,wesleywiser,46512e09c9f97a68a36e2d72e3be766b1e76a1a0,2,Add two regression tests for const eval,HEART,2018-07-07T22:52:03Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/51835,MERGED,2018-06-27T05:20:11Z,2018-06-27T11:20:41Z,Stabilize to_bytes and from_bytes for integers.,tmccombs,c8f9b84b393915a48253e3edc862c15a9b7152a7,1,Stabilize to_bytes and from_bytes for integers. Fixes #49792,THUMBS_UP,2018-07-04T12:45:07Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/51839,MERGED,2018-06-27T11:49:06Z,2018-06-29T01:05:17Z,Detect overflows of non u32 shifts,oli-obk,0fa166ad7f2684cecb184204141abe159b5b7b4f,3,Detect overflows of non u32 shifts,THUMBS_UP,2018-07-05T08:33:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51839,MERGED,2018-06-27T11:49:06Z,2018-06-29T01:05:17Z,Detect overflows of non u32 shifts,oli-obk,0fa166ad7f2684cecb184204141abe159b5b7b4f,3,Detect overflows of non u32 shifts,THUMBS_UP,2018-07-06T18:26:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,HOORAY,2018-06-27T14:49:01Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,HEART,2018-06-27T14:51:45Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,THUMBS_UP,2018-06-27T14:51:47Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,THUMBS_UP,2018-07-02T05:06:08Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,THUMBS_UP,2019-01-20T22:32:44Z,garbageslam,garbageslamb@gmail.com https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,HOORAY,2019-01-20T22:32:45Z,garbageslam,garbageslamb@gmail.com https://github.com/rust-lang/rust/pull/51846,CLOSED,2018-06-27T14:01:22Z,2018-07-09T11:22:41Z,Move HashMap to liballoc,Amanieu,NA,NA,NA,HEART,2019-01-20T22:32:46Z,garbageslam,garbageslamb@gmail.com https://github.com/rust-lang/rust/pull/51851,CLOSED,2018-06-27T16:13:19Z,2018-06-29T11:43:33Z,Remove use of uninitialized() in Weak::new(),SimonSapin,NA,NA,NA,HOORAY,2018-06-27T17:34:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/51855,MERGED,2018-06-27T20:53:10Z,2018-07-01T12:38:45Z,A fix for 51821,Eh2406,ac5bd5dd2b4abd8eb888f14ea01b59028173c0db,1,remove the FxHashSet since it's not helping us in practice It turns out that we don't have duplicates just self-cycles.,THUMBS_UP,2018-06-27T23:00:16Z,lqd,NA https://github.com/rust-lang/rust/pull/51861,MERGED,2018-06-27T23:57:20Z,2018-07-06T02:42:32Z,Prevent some markdown transformation on short docblocks,GuillaumeGomez,6a86ee73285c6a522dce0da5fee3ed4681501b21,2,Prevent some markdown transformation on short docblocks,HEART,2018-06-28T07:05:29Z,nical,nical@fastmail.com https://github.com/rust-lang/rust/pull/51862,MERGED,2018-06-28T00:41:57Z,2018-06-30T18:55:24Z,Point to lifetime spans on lifetime errors,estebank,8449c5ab8a83cfa1f89c8f7810a42a54130c844d,2,Fix rebase,HEART,2018-06-28T08:52:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/51862,MERGED,2018-06-28T00:41:57Z,2018-06-30T18:55:24Z,Point to lifetime spans on lifetime errors,estebank,8449c5ab8a83cfa1f89c8f7810a42a54130c844d,2,Fix rebase,HEART,2018-06-28T15:46:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/51862,MERGED,2018-06-28T00:41:57Z,2018-06-30T18:55:24Z,Point to lifetime spans on lifetime errors,estebank,8449c5ab8a83cfa1f89c8f7810a42a54130c844d,2,Fix rebase,HEART,2018-07-05T08:30:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51862,MERGED,2018-06-28T00:41:57Z,2018-06-30T18:55:24Z,Point to lifetime spans on lifetime errors,estebank,8449c5ab8a83cfa1f89c8f7810a42a54130c844d,2,Fix rebase,HEART,2018-07-06T18:47:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51866,MERGED,2018-06-28T06:58:30Z,2018-07-02T05:19:43Z,add modifier keyword spans to hir::Visibility; improve unreachable-pub private-no-mangle lint suggestions,zackmdavis,43a0a65fa2d812c0e48e6cc60a985a4bf47bff57,15,call it `hir::VisibilityKind` instead of `hir::Visibility_:*` It was pointed out in review that the glob-exported underscore-suffixed convention for `Spanned` HIR nodes is no longer preferred: see February 2016's #31487 for AST's migration away from this style towards properly namespaced NodeKind enums. This concerns #51968.,THUMBS_UP,2018-06-28T09:41:24Z,mati865,NA https://github.com/rust-lang/rust/pull/51866,MERGED,2018-06-28T06:58:30Z,2018-07-02T05:19:43Z,add modifier keyword spans to hir::Visibility; improve unreachable-pub private-no-mangle lint suggestions,zackmdavis,43a0a65fa2d812c0e48e6cc60a985a4bf47bff57,15,call it `hir::VisibilityKind` instead of `hir::Visibility_:*` It was pointed out in review that the glob-exported underscore-suffixed convention for `Spanned` HIR nodes is no longer preferred: see February 2016's #31487 for AST's migration away from this style towards properly namespaced NodeKind enums. This concerns #51968.,THUMBS_UP,2018-07-01T18:37:50Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/51866,MERGED,2018-06-28T06:58:30Z,2018-07-02T05:19:43Z,add modifier keyword spans to hir::Visibility; improve unreachable-pub private-no-mangle lint suggestions,zackmdavis,43a0a65fa2d812c0e48e6cc60a985a4bf47bff57,15,call it `hir::VisibilityKind` instead of `hir::Visibility_:*` It was pointed out in review that the glob-exported underscore-suffixed convention for `Spanned` HIR nodes is no longer preferred: see February 2016's #31487 for AST's migration away from this style towards properly namespaced NodeKind enums. This concerns #51968.,THUMBS_UP,2018-07-02T00:26:33Z,estebank,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-06-29T05:32:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-06-29T13:37:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-06-29T19:55:48Z,me6iaton,me6iaton@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-06-29T20:17:10Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-06-29T20:17:10Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-06-30T00:12:56Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-07-01T09:13:18Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-07-01T09:13:20Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-07-03T19:29:28Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-07-12T05:09:58Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-07-25T05:26:06Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-07-25T05:26:07Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T19:34:33Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T20:09:48Z,thekashifmalik,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T20:18:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T20:41:18Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T20:44:05Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T20:54:32Z,estebank,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T22:30:41Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-20T22:53:04Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-21T00:06:28Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-21T06:12:18Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-21T09:22:22Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HEART,2018-08-21T09:32:00Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-21T10:14:19Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-21T21:05:47Z,tucanae47,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,THUMBS_UP,2018-08-21T21:05:49Z,tucanae47,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-22T15:01:24Z,blueridanus,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-22T16:15:46Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51880,MERGED,2018-06-28T21:17:18Z,2018-08-20T18:26:26Z,The Great Generics Generalisation: HIR Followup,varkor,ee9bd0fd99ef5049f53b5d8233369187637cb71c,2,Add a test for skipping all arguments versus just one,HOORAY,2018-08-23T04:50:00Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51896,MERGED,2018-06-29T11:05:43Z,2018-07-02T20:12:17Z,introduce dirty list to liveness eliminate `ins` vector,nikomatsakis,78ea95258d6e3f603713ffde001334305044a4fb,2,improve comments,THUMBS_UP,2018-06-29T11:07:40Z,lqd,NA https://github.com/rust-lang/rust/pull/51896,MERGED,2018-06-29T11:05:43Z,2018-07-02T20:12:17Z,introduce dirty list to liveness eliminate `ins` vector,nikomatsakis,78ea95258d6e3f603713ffde001334305044a4fb,2,improve comments,THUMBS_UP,2018-06-29T11:11:51Z,PramodBisht,NA https://github.com/rust-lang/rust/pull/51896,MERGED,2018-06-29T11:05:43Z,2018-07-02T20:12:17Z,introduce dirty list to liveness eliminate `ins` vector,nikomatsakis,78ea95258d6e3f603713ffde001334305044a4fb,2,improve comments,THUMBS_UP,2018-06-29T14:36:42Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/51896,MERGED,2018-06-29T11:05:43Z,2018-07-02T20:12:17Z,introduce dirty list to liveness eliminate `ins` vector,nikomatsakis,78ea95258d6e3f603713ffde001334305044a4fb,2,improve comments,THUMBS_UP,2018-07-04T17:21:53Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/51899,MERGED,2018-06-29T13:03:49Z,2018-07-10T01:07:31Z,bump minimum LLVM version to 5.0,gnzlbg,3b36ce64a55c32886a752e0935a4f5068d5f1678,1,revert travis-ci changes,HOORAY,2018-06-30T02:15:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51899,MERGED,2018-06-29T13:03:49Z,2018-07-10T01:07:31Z,bump minimum LLVM version to 5.0,gnzlbg,3b36ce64a55c32886a752e0935a4f5068d5f1678,1,revert travis-ci changes,HOORAY,2018-07-03T20:41:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/51899,MERGED,2018-06-29T13:03:49Z,2018-07-10T01:07:31Z,bump minimum LLVM version to 5.0,gnzlbg,3b36ce64a55c32886a752e0935a4f5068d5f1678,1,revert travis-ci changes,HOORAY,2018-08-28T17:15:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51900,MERGED,2018-06-29T13:40:03Z,2018-07-03T23:48:44Z,introduce dirty list to dataflow,PramodBisht,09df6a0aba257270bf2154a0aa0ca1c9acdddcc8,1,Address #51813,THUMBS_UP,2018-07-02T21:05:31Z,lqd,NA https://github.com/rust-lang/rust/pull/51914,MERGED,2018-06-29T19:14:14Z,2018-07-03T14:31:30Z,add outlives annotations to `BTreeMap`,nikomatsakis,59f2edbf1adfea256216cb7fb65d291d324ea857,1,add outlives annotations to `BTreeMap` nll requires these annotations I believe because of https://github.com/rust-lang/rust/issues/29149,THUMBS_UP,2018-06-29T19:21:42Z,lqd,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-01T07:09:02Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-01T21:28:25Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-02T05:41:30Z,xen0n,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-02T16:08:19Z,felix91gr,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-02T16:14:41Z,ollie27,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-09T20:29:39Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-07-24T23:12:51Z,jminer,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-01T05:28:57Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-08T09:04:20Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-08T09:35:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-08T23:13:16Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-09T10:20:47Z,michalsrb,michalsrb@gmail.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-09T14:57:13Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2018-08-09T19:16:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51919,MERGED,2018-06-29T20:47:24Z,2018-08-04T18:22:35Z,Provide `{to from}_{ne le be}_bytes` functions on integers,tbu-,0ddfae5ba2d0104a33f3a7162571b761458f0464,1,Change tracking issue from #49792 to #51919 The old issue has already been in FCP a new issue was opened for the new API.,THUMBS_UP,2019-01-17T22:56:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/51920,MERGED,2018-06-29T20:57:09Z,2018-07-01T23:00:44Z,use literal span for concrete type suggestion,euclio,28c4813920545dd3c15b1ad2f8ffdbe8c4c5bd52,3,use literal span for concrete type suggestion Fixes #51874.,HEART,2018-06-29T21:06:11Z,estebank,NA https://github.com/rust-lang/rust/pull/51920,MERGED,2018-06-29T20:57:09Z,2018-07-01T23:00:44Z,use literal span for concrete type suggestion,euclio,28c4813920545dd3c15b1ad2f8ffdbe8c4c5bd52,3,use literal span for concrete type suggestion Fixes #51874.,HEART,2018-06-30T07:22:54Z,bjorn3,NA https://github.com/rust-lang/rust/pull/51920,MERGED,2018-06-29T20:57:09Z,2018-07-01T23:00:44Z,use literal span for concrete type suggestion,euclio,28c4813920545dd3c15b1ad2f8ffdbe8c4c5bd52,3,use literal span for concrete type suggestion Fixes #51874.,HEART,2018-07-06T18:49:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51936,MERGED,2018-06-30T03:26:54Z,2018-07-05T08:38:48Z,rename rustc's lld to rust-lld,japaric,31ed5c7a01d9826c10bdd166ffcd23efd95b1efe,1,in the second copy lld is already named rust-lld,THUMBS_UP,2018-06-30T05:32:37Z,retep998,NA https://github.com/rust-lang/rust/pull/51936,MERGED,2018-06-30T03:26:54Z,2018-07-05T08:38:48Z,rename rustc's lld to rust-lld,japaric,31ed5c7a01d9826c10bdd166ffcd23efd95b1efe,1,in the second copy lld is already named rust-lld,THUMBS_UP,2018-07-12T07:21:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51946,MERGED,2018-06-30T17:17:03Z,2018-09-26T18:17:00Z,[eRFC] add -Z emit-stack-sizes,japaric,531e3566504f2bab929eaf57c4ba84838857933f,1,don't run the test on macOS,HEART,2018-07-02T16:20:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/51946,MERGED,2018-06-30T17:17:03Z,2018-09-26T18:17:00Z,[eRFC] add -Z emit-stack-sizes,japaric,531e3566504f2bab929eaf57c4ba84838857933f,1,don't run the test on macOS,HEART,2018-09-05T07:38:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/51946,MERGED,2018-06-30T17:17:03Z,2018-09-26T18:17:00Z,[eRFC] add -Z emit-stack-sizes,japaric,531e3566504f2bab929eaf57c4ba84838857933f,1,don't run the test on macOS,HEART,2018-09-26T17:46:43Z,sfackler,NA https://github.com/rust-lang/rust/pull/51952,MERGED,2018-06-30T19:34:21Z,2018-07-11T21:54:54Z, hygiene: Decouple transparencies from expansion IDs,petrochenkov,fc74e359819002fad402f68728f6e5ba2d4cb704,16,Remove fallback to parent modules from lexical resolution,HEART,2018-06-30T19:42:06Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/51952,MERGED,2018-06-30T19:34:21Z,2018-07-11T21:54:54Z, hygiene: Decouple transparencies from expansion IDs,petrochenkov,fc74e359819002fad402f68728f6e5ba2d4cb704,16,Remove fallback to parent modules from lexical resolution,HEART,2018-07-05T20:40:58Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/51959,MERGED,2018-07-01T03:40:46Z,2018-07-21T21:01:22Z,Turn implied_outlives_bounds into a query,tmandry,0d8f3b3628129fa0b59e6f4953ab7fd60ebe09b9,2,we now get 2 extra mismatched type errors These new errors actually seem a *tad* clearer than the old one so that's good but now there are 3. Maybe call it a wash?,HOORAY,2018-07-18T19:42:41Z,lqd,NA https://github.com/rust-lang/rust/pull/51962,MERGED,2018-07-01T08:52:28Z,2018-07-13T22:06:16Z,Provide llvm-strip in llvm-tools component,crlf0710,de2ecea3592c81eae5c0ce4e3d26729f7d552c34,1,Provide llvm-strip in llvm-tools component Shipping this tool gives people reliable way to reduce the generated executable size. I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric,THUMBS_UP,2018-07-01T10:12:30Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/51964,MERGED,2018-07-01T16:17:49Z,2018-07-05T02:35:43Z,[NLL] Fix various unused mut errors,matthewjasper,125c9d99e58466b27f2b01f3865e6668d4c196ff,10,Fix various nll unused mut errors,HOORAY,2018-07-02T17:13:31Z,lqd,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-01T17:02:46Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-01T17:13:53Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-02T02:17:10Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-02T14:30:14Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-02T15:37:33Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-02T15:39:02Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-02T15:40:11Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-03T09:14:33Z,frol,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HEART,2018-07-03T16:44:00Z,fitzgen,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-09T14:37:21Z,Arkrait,arkrait04@gmail.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-11T04:27:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HEART,2018-07-12T01:11:30Z,Terkwood,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-12T01:11:32Z,Terkwood,NA https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HEART,2018-07-13T06:15:30Z,AmaanC,amaan.cheval@gmail.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HOORAY,2018-07-13T06:15:35Z,AmaanC,amaan.cheval@gmail.com https://github.com/rust-lang/rust/pull/51966,MERGED,2018-07-01T16:55:39Z,2018-07-11T10:00:42Z,Upgrade to LLVM's master branch (LLVM 7),alexcrichton,42eb85002ae4bda9899216805d03fa7d77279ede,39,Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD however we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382,HEART,2018-08-25T12:19:47Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/51967,MERGED,2018-07-01T17:33:49Z,2018-07-05T11:44:23Z,Fix various issues with control-flow statements inside anonymous constants,varkor,adf4ef7b98212e1295e7cbc68a7133e67f9af846,2,Use LitToConstError rather than bool for errors,HEART,2018-07-02T00:15:28Z,estebank,NA https://github.com/rust-lang/rust/pull/51973,MERGED,2018-07-01T22:12:11Z,2018-07-03T14:31:35Z,Make Stdio handle UnwindSafe,estk,9797665b286db3f34cc475560a68380012fadde7,2,Make Stdio handle UnwindSafe,THUMBS_UP,2018-07-02T15:26:57Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/51974,CLOSED,2018-07-01T22:34:36Z,2018-08-07T17:26:47Z,Update docs for std::alloc to show how to turn on the system allocator,brson,NA,NA,NA,HEART,2018-07-01T23:27:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/51987,MERGED,2018-07-02T16:34:57Z,2018-07-13T15:42:53Z,nll experiment: compute SCCs instead of iterative region solving,nikomatsakis,6918c170488179bbba582d26af3b6b2c27a77641,1,nit: fix typo,THUMBS_UP,2018-07-02T17:10:38Z,lqd,NA https://github.com/rust-lang/rust/pull/51987,MERGED,2018-07-02T16:34:57Z,2018-07-13T15:42:53Z,nll experiment: compute SCCs instead of iterative region solving,nikomatsakis,6918c170488179bbba582d26af3b6b2c27a77641,1,nit: fix typo,THUMBS_UP,2018-07-08T17:19:36Z,PramodBisht,NA https://github.com/rust-lang/rust/pull/52004,MERGED,2018-07-02T20:54:49Z,2018-07-03T14:31:41Z,toolstate: Fixed detection of changed submodule and other fixes.,kennytm,689cffa211e4c2c2c74dbc759020be40fe222d23,1,"Run ""tools"" job on PR when commit message starts with ""Update RLS/miri/...""",HEART,2018-07-03T09:49:05Z,mati865,NA https://github.com/rust-lang/rust/pull/52004,MERGED,2018-07-02T20:54:49Z,2018-07-03T14:31:41Z,toolstate: Fixed detection of changed submodule and other fixes.,kennytm,689cffa211e4c2c2c74dbc759020be40fe222d23,1,"Run ""tools"" job on PR when commit message starts with ""Update RLS/miri/...""",HEART,2018-07-03T13:22:25Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2018-07-06T21:39:57Z,estebank,NA https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2018-07-09T22:46:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2018-07-12T05:31:49Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2018-09-15T20:23:20Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2019-07-16T23:27:09Z,elichai,NA https://github.com/rust-lang/rust/pull/52011,MERGED,2018-07-03T07:50:29Z,2018-08-23T00:22:23Z,Allow panicking with string literal messages inside constants,oli-obk,bd6ae6a6d10f3ebe51d0a7a8d7ef342a65f68ff4,9,Reexpose stability hole in the presence of feature gates,HEART,2022-01-08T14:40:10Z,95th,NA https://github.com/rust-lang/rust/pull/52016,MERGED,2018-07-03T10:04:32Z,2018-07-06T08:59:40Z,Deduplicate error reports for statics,oli-obk,1eeb5dcb677d281e3dd2483a47b7cb30d8c8c31f,5,Deduplicate error reports for statics,THUMBS_UP,2018-07-03T14:41:30Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/52018,MERGED,2018-07-03T11:55:46Z,2018-07-06T20:05:36Z,Implementation of tool lints.,flip1995,c3949009adf7e8a039a1f467cbc6e6b5cf993303,5,Improving span of unknown lint tool error message,HOORAY,2018-07-03T12:05:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52018,MERGED,2018-07-03T11:55:46Z,2018-07-06T20:05:36Z,Implementation of tool lints.,flip1995,c3949009adf7e8a039a1f467cbc6e6b5cf993303,5,Improving span of unknown lint tool error message,HOORAY,2018-07-03T15:49:03Z,mati865,NA https://github.com/rust-lang/rust/pull/52018,MERGED,2018-07-03T11:55:46Z,2018-07-06T20:05:36Z,Implementation of tool lints.,flip1995,c3949009adf7e8a039a1f467cbc6e6b5cf993303,5,Improving span of unknown lint tool error message,HOORAY,2018-07-12T07:18:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52019,MERGED,2018-07-03T14:54:10Z,2018-07-06T08:59:41Z,[cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD),michaelwoerister,65ff4141a5ed69223b29634a49a499b9415993ee,2,Allow the linker to choose the LTO-plugin (which is useful when using LLD),THUMBS_UP,2018-07-03T15:11:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52019,MERGED,2018-07-03T14:54:10Z,2018-07-06T08:59:41Z,[cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD),michaelwoerister,65ff4141a5ed69223b29634a49a499b9415993ee,2,Allow the linker to choose the LTO-plugin (which is useful when using LLD),THUMBS_UP,2018-07-03T18:00:04Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52020,CLOSED,2018-07-03T15:10:25Z,2018-07-09T21:42:51Z,[Do not merge yet] Remove alloc_jemalloc switch the default global allocator to System,SimonSapin,NA,NA,NA,THUMBS_UP,2018-07-03T16:23:21Z,mati865,NA https://github.com/rust-lang/rust/pull/52020,CLOSED,2018-07-03T15:10:25Z,2018-07-09T21:42:51Z,[Do not merge yet] Remove alloc_jemalloc switch the default global allocator to System,SimonSapin,NA,NA,NA,HOORAY,2018-07-03T16:41:54Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/52020,CLOSED,2018-07-03T15:10:25Z,2018-07-09T21:42:51Z,[Do not merge yet] Remove alloc_jemalloc switch the default global allocator to System,SimonSapin,NA,NA,NA,HOORAY,2018-07-03T17:33:12Z,cramertj,NA https://github.com/rust-lang/rust/pull/52020,CLOSED,2018-07-03T15:10:25Z,2018-07-09T21:42:51Z,[Do not merge yet] Remove alloc_jemalloc switch the default global allocator to System,SimonSapin,NA,NA,NA,HEART,2018-07-03T17:33:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/52020,CLOSED,2018-07-03T15:10:25Z,2018-07-09T21:42:51Z,[Do not merge yet] Remove alloc_jemalloc switch the default global allocator to System,SimonSapin,NA,NA,NA,HOORAY,2018-07-04T17:20:27Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52021,MERGED,2018-07-03T15:48:43Z,2018-07-07T01:51:20Z,refactor and cleanup region errors for NLL,nikomatsakis,727f01700b074181bddf49caa07ac5e34455680d,49,write code to extract region names and emit new style message,HEART,2018-07-03T17:24:36Z,estebank,NA https://github.com/rust-lang/rust/pull/52022,CLOSED,2018-07-03T16:05:29Z,2018-07-05T07:18:38Z,[experimental] Avoid sorting hashmaps during ICH computation.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-07-03T18:03:42Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T17:55:26Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T18:00:45Z,cramertj,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-03T18:02:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T18:04:26Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T18:09:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-03T18:09:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T18:17:29Z,sinkuu,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T18:25:10Z,fanzier,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-03T18:31:05Z,varkor,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-03T20:04:09Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-03T20:09:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-04T00:02:29Z,lqd,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-04T00:02:30Z,lqd,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-04T03:16:50Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-04T09:53:29Z,killercup,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-04T09:53:30Z,killercup,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-10T21:25:44Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2018-07-17T21:42:09Z,Pratyush,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-17T21:42:10Z,Pratyush,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-20T06:03:17Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-21T16:11:39Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-25T20:55:42Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,THUMBS_UP,2018-07-26T03:39:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-26T03:58:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-26T06:52:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-26T11:27:26Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2018-07-26T12:14:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2019-12-13T11:22:56Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HOORAY,2020-03-04T15:24:12Z,95th,NA https://github.com/rust-lang/rust/pull/52024,MERGED,2018-07-03T17:46:51Z,2018-07-19T23:24:57Z,Implement existential types,oli-obk,9017f79282f1d745453a5117af25a3b477600a90,1,Generate a page for existential types,HEART,2020-03-04T15:24:13Z,95th,NA https://github.com/rust-lang/rust/pull/52031,MERGED,2018-07-03T20:20:27Z,2018-07-06T08:59:42Z,Strenghten synchronization in `Arc::is_unique`,RalfJung,f96c2468695911222ba7557ce04af0dd8fbb6df2,1,Strenghten synchronization in `Arc::is_unique` Previously `is_unique` would not synchronize at all with a `drop` that returned early because it was not the last reference leading to a data race. Fixes #51780,THUMBS_UP,2018-07-06T11:28:55Z,bjorn3,NA https://github.com/rust-lang/rust/pull/52031,MERGED,2018-07-03T20:20:27Z,2018-07-06T08:59:42Z,Strenghten synchronization in `Arc::is_unique`,RalfJung,f96c2468695911222ba7557ce04af0dd8fbb6df2,1,Strenghten synchronization in `Arc::is_unique` Previously `is_unique` would not synchronize at all with a `drop` that returned early because it was not the last reference leading to a data race. Fixes #51780,THUMBS_UP,2018-07-14T02:30:09Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/52031,MERGED,2018-07-03T20:20:27Z,2018-07-06T08:59:42Z,Strenghten synchronization in `Arc::is_unique`,RalfJung,f96c2468695911222ba7557ce04af0dd8fbb6df2,1,Strenghten synchronization in `Arc::is_unique` Previously `is_unique` would not synchronize at all with a `drop` that returned early because it was not the last reference leading to a data race. Fixes #51780,THUMBS_UP,2018-07-19T19:12:41Z,hcpl,NA https://github.com/rust-lang/rust/pull/52032,MERGED,2018-07-03T20:58:39Z,2018-07-14T02:11:21Z,Add the `amdgpu-kernel` ABI.,DiamondLovesYou,6332bb15062b3e193ba64a4ddb2619e8940a079f,9,Add the `amdgpu-kernel` ABI. Technically there are requirements imposed by the LLVM `AMDGPUTargetMachine` on functions with this ABI (eg the return type must be void) but I'm unsure exactly where this should be enforced.,HEART,2018-07-04T01:05:45Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52032,MERGED,2018-07-03T20:58:39Z,2018-07-14T02:11:21Z,Add the `amdgpu-kernel` ABI.,DiamondLovesYou,6332bb15062b3e193ba64a4ddb2619e8940a079f,9,Add the `amdgpu-kernel` ABI. Technically there are requirements imposed by the LLVM `AMDGPUTargetMachine` on functions with this ABI (eg the return type must be void) but I'm unsure exactly where this should be enforced.,HEART,2018-07-19T14:02:53Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/52032,MERGED,2018-07-03T20:58:39Z,2018-07-14T02:11:21Z,Add the `amdgpu-kernel` ABI.,DiamondLovesYou,6332bb15062b3e193ba64a4ddb2619e8940a079f,9,Add the `amdgpu-kernel` ABI. Technically there are requirements imposed by the LLVM `AMDGPUTargetMachine` on functions with this ABI (eg the return type must be void) but I'm unsure exactly where this should be enforced.,HEART,2018-07-20T15:10:28Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/52032,MERGED,2018-07-03T20:58:39Z,2018-07-14T02:11:21Z,Add the `amdgpu-kernel` ABI.,DiamondLovesYou,6332bb15062b3e193ba64a4ddb2619e8940a079f,9,Add the `amdgpu-kernel` ABI. Technically there are requirements imposed by the LLVM `AMDGPUTargetMachine` on functions with this ABI (eg the return type must be void) but I'm unsure exactly where this should be enforced.,HEART,2020-01-25T08:38:28Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/52046,MERGED,2018-07-04T01:20:56Z,2018-07-13T02:44:17Z,Ensure StorageDead is created even if variable initialization fails,cramertj,9c15a6606eff9c5821921f5cb6be305ccf8005de,8,Ensure StorageDead is created even if variable initialization fails,HOORAY,2018-07-09T12:27:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/52046,MERGED,2018-07-04T01:20:56Z,2018-07-13T02:44:17Z,Ensure StorageDead is created even if variable initialization fails,cramertj,9c15a6606eff9c5821921f5cb6be305ccf8005de,8,Ensure StorageDead is created even if variable initialization fails,HOORAY,2018-07-19T04:17:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-07-04T14:27:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-07-06T17:20:48Z,frol,NA https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-07-25T21:09:42Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-07-26T07:33:37Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-07-26T11:47:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2018-08-23T01:40:12Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/52051,MERGED,2018-07-04T10:23:24Z,2018-07-22T20:54:13Z,mem::swap the obvious way for types smaller than the SIMD optimization's block size,scottmcm,c9482f724f2c6369a56faddd3ba4c1f00545a086,1,Only run the test on x86_64 Smaller platforms don't merge the loads the same way.,HOORAY,2019-10-23T05:24:26Z,Lokathor,NA https://github.com/rust-lang/rust/pull/52052,CLOSED,2018-07-04T10:35:19Z,2018-07-30T16:47:50Z,Make verbose --version show if parallel queries are supported.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-07-04T14:26:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52058,MERGED,2018-07-04T19:09:05Z,2018-07-07T05:54:47Z,Use of unimplemented!() causing ICE with NLL,davidtwco,f90eada1c97dd0d0a752d34090a957661789379a,1,Improve comments.,THUMBS_UP,2018-07-07T22:22:29Z,lqd,NA https://github.com/rust-lang/rust/pull/52061,CLOSED,2018-07-04T20:02:36Z,2018-07-05T07:31:45Z,Only convert chars when needed in str case conversion methods.,Pazzaz,NA,NA,NA,THUMBS_UP,2018-07-05T01:04:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52067,MERGED,2018-07-05T01:49:30Z,2018-07-07T05:54:48Z,Visit the mir basic blocks in reverse-postfix order,csmoe,e7e8c72fdd0195358b4fe82f16fce81668ef0c3c,6,update test,THUMBS_UP,2018-07-05T13:38:41Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52069,MERGED,2018-07-05T04:34:41Z,2018-07-22T23:05:19Z,add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint,zackmdavis,41d5c0ce1fb4618c98b3ed07d657bdedfc98c959,9,"in which the elided-lifetimes-in-paths lint undergoes a revolution The existing elided-lifetimes-in-paths lint (introduced in Nov. 2017's accd997b5 / #46254) lacked stuctured suggestions and—much more alarmingly—produced false positives on associated functions (like `Ref::clone`) and on anonymous '_ lifetimes (!!—yes the very anonymous lifetimes that we meant to suggest ""instead""). That this went apparently unnoticed for so long maybe tells you something about how many people actually bother to flip on allow-by-default lints. After many hours of good old-fashioned American elbow grease—and a little help from expert reviewers—it turns out that getting the right answer is a lot easier if we fire the lint while lowering the Higher Intermediate Representation. The lint is promoted to the idioms-2018 group. Also in the matter of test filenames ""elided"" only has one 'l' (see e.g. https://en.wiktionary.org/wiki/elide). Resolves #52041.",HOORAY,2018-07-06T10:11:32Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/52069,MERGED,2018-07-05T04:34:41Z,2018-07-22T23:05:19Z,add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint,zackmdavis,41d5c0ce1fb4618c98b3ed07d657bdedfc98c959,9,"in which the elided-lifetimes-in-paths lint undergoes a revolution The existing elided-lifetimes-in-paths lint (introduced in Nov. 2017's accd997b5 / #46254) lacked stuctured suggestions and—much more alarmingly—produced false positives on associated functions (like `Ref::clone`) and on anonymous '_ lifetimes (!!—yes the very anonymous lifetimes that we meant to suggest ""instead""). That this went apparently unnoticed for so long maybe tells you something about how many people actually bother to flip on allow-by-default lints. After many hours of good old-fashioned American elbow grease—and a little help from expert reviewers—it turns out that getting the right answer is a lot easier if we fire the lint while lowering the Higher Intermediate Representation. The lint is promoted to the idioms-2018 group. Also in the matter of test filenames ""elided"" only has one 'l' (see e.g. https://en.wiktionary.org/wiki/elide). Resolves #52041.",HOORAY,2018-07-14T01:59:03Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/52069,MERGED,2018-07-05T04:34:41Z,2018-07-22T23:05:19Z,add structured suggestions and fix false-positive for elided-lifetimes-in-paths lint,zackmdavis,41d5c0ce1fb4618c98b3ed07d657bdedfc98c959,9,"in which the elided-lifetimes-in-paths lint undergoes a revolution The existing elided-lifetimes-in-paths lint (introduced in Nov. 2017's accd997b5 / #46254) lacked stuctured suggestions and—much more alarmingly—produced false positives on associated functions (like `Ref::clone`) and on anonymous '_ lifetimes (!!—yes the very anonymous lifetimes that we meant to suggest ""instead""). That this went apparently unnoticed for so long maybe tells you something about how many people actually bother to flip on allow-by-default lints. After many hours of good old-fashioned American elbow grease—and a little help from expert reviewers—it turns out that getting the right answer is a lot easier if we fire the lint while lowering the Higher Intermediate Representation. The lint is promoted to the idioms-2018 group. Also in the matter of test filenames ""elided"" only has one 'l' (see e.g. https://en.wiktionary.org/wiki/elide). Resolves #52041.",LAUGH,2018-07-22T17:08:28Z,kennytm,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-05T12:25:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,HEART,2018-07-05T15:31:56Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-05T17:45:20Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-05T18:49:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-05T20:23:04Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-06T02:54:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-11T16:39:04Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-11T16:55:27Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,THUMBS_UP,2018-07-12T07:20:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-12T09:32:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-12T12:06:20Z,pacman82,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-12T16:26:23Z,IC3Q,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-12T20:51:56Z,Bamieh,ahmadbamieh@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-12T23:06:42Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2018-07-13T13:16:29Z,bjorn3,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2019-01-03T02:09:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2019-02-26T05:08:59Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-20T21:53:31Z,omppye,omppye@gmail.com https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-20T23:23:20Z,max-sixty,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-21T00:06:11Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,HEART,2020-04-21T20:17:08Z,GrayJack,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-21T20:17:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-21T20:25:49Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-22T09:04:23Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-22T10:47:59Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-04-22T19:13:29Z,0x5459,NA https://github.com/rust-lang/rust/pull/52073,MERGED,2018-07-05T10:08:01Z,2018-07-06T08:59:46Z,Add a punch card to weird expressions test,xfix,0ce01776bacbfc9077672119dcd3b70f235ba7b8,1,Add a punch card to weird expressions test,LAUGH,2020-10-28T03:28:34Z,juliand665,NA https://github.com/rust-lang/rust/pull/52077,CLOSED,2018-07-05T15:01:08Z,2018-07-06T10:04:49Z,prohibit types named dyn`,nikomatsakis,NA,NA,NA,THUMBS_UP,2018-07-06T02:39:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T18:01:04Z,sfackler,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T18:17:35Z,vikrrrr,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T18:33:14Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T18:34:46Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T18:55:19Z,mateusmedeiros,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T19:34:20Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T20:40:19Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T20:45:45Z,killercup,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T20:54:45Z,tailhook,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T21:04:16Z,ds84182,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-05T23:46:34Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T00:46:51Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T02:01:37Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T02:38:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T03:00:01Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T04:16:21Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T12:25:45Z,lightdiscord,root@arnaud.sh https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T12:26:08Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T12:42:15Z,anderejd,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T13:00:22Z,repi,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T14:36:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T15:38:35Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-06T16:06:52Z,Cackbone,contact@cackbone.fr https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-07T01:49:58Z,RadicalZephyr,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-07T09:55:11Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-07T15:08:02Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T00:53:13Z,hayd,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T03:18:32Z,xilec,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T07:51:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T09:58:25Z,dd10-e,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T12:48:21Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-09T22:05:51Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-10T22:09:00Z,mati865,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-11T19:42:08Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,THUMBS_UP,2018-07-11T21:08:46Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-12T15:19:13Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-14T14:27:43Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-14T16:23:48Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-16T15:37:49Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-17T10:18:02Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-18T11:43:10Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-18T14:10:33Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-18T17:25:57Z,adnanademovic,adnanademovic100@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-18T21:29:30Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-19T02:01:24Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-19T03:53:46Z,daleione,guoyunlei@live.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,THUMBS_UP,2018-07-19T04:26:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-19T04:26:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-19T10:17:05Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-20T09:34:52Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-20T15:42:30Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-07-25T05:43:03Z,tmccombs,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,THUMBS_UP,2018-07-25T05:43:04Z,tmccombs,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-08-14T02:49:02Z,Ekleog,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-19T07:41:38Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-20T14:34:24Z,hcpl,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-23T22:32:47Z,Congee,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-24T11:29:18Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-25T10:40:42Z,darfink,elliott@linder.dev https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-25T17:43:00Z,abhi18av,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-10-28T17:07:48Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,THUMBS_UP,2018-10-28T17:07:53Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-11-09T04:02:09Z,NotIntMan,shepardiwe@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2018-11-16T07:59:28Z,zedrian,artsiom.kopats@gmail.com https://github.com/rust-lang/rust/pull/52081,MERGED,2018-07-05T17:53:59Z,2018-07-16T23:11:10Z,rustc: Stabilize the `proc_macro` feature,alexcrichton,65f3007fa8a08daf77f2b8382a56eb80cb277131,80,rustc: Stabilize much of the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros custom derives with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR once landed will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252,HOORAY,2019-08-18T10:30:20Z,ithinuel,wilfried.chauveau@ithinuel.me https://github.com/rust-lang/rust/pull/52083,MERGED,2018-07-05T18:18:33Z,2018-07-07T05:54:49Z,Dont run ast borrowck on mir mode,spastorino,25266c18409858ac0c482bc00a6d72c0f83f3df2,6,Do not run AST borrowck when -Zborrowck=mir,THUMBS_UP,2018-07-07T22:22:10Z,lqd,NA https://github.com/rust-lang/rust/pull/52087,MERGED,2018-07-05T22:56:22Z,2018-07-07T18:22:01Z,Update musl to 1.1.19 and add patch to fix tls issue,malbarbo,f969b61bd61d31b4a6f001b7047fd4a192bedd35,1,Update musl to 1.1.19 and add patch to fix tls issue,HEART,2018-07-07T20:48:09Z,tjkirch,NA https://github.com/rust-lang/rust/pull/52103,MERGED,2018-07-06T07:02:01Z,2018-07-07T05:54:50Z,Stabilize rc_downcast,tmccombs,7fbc3895e359b9212bc0a78692198f15bbe462b5,2,Stabilize rc_downcast Fixes #44608,THUMBS_UP,2018-07-06T09:51:53Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52106,MERGED,2018-07-06T10:16:27Z,2018-07-08T16:09:09Z,Don't suggest `let` bindings if they don't help with borrows,PramodBisht,ab767eecb00847df456fa519a07b9ee96d786000,3,Added UI testcases for #52049,HOORAY,2018-07-07T00:34:30Z,estebank,NA https://github.com/rust-lang/rust/pull/52109,MERGED,2018-07-06T12:28:53Z,2018-07-07T16:21:44Z,When doing linker-plugin based LTO write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.,michaelwoerister,4a269642c9c458fe084eebc11f979d49c5fdc1c9,2,Remove CrossLangLto::NoLink which does not have a use case anymore.,HOORAY,2018-07-06T15:15:59Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52116,MERGED,2018-07-06T17:55:57Z,2018-07-19T03:05:13Z,Handle array manually in str case conversion methods,Pazzaz,ad7621d42ee90143cd15715cc546177575fd5844,2,Handle array manually in string case conversion methods,THUMBS_UP,2018-07-06T20:23:45Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52116,MERGED,2018-07-06T17:55:57Z,2018-07-19T03:05:13Z,Handle array manually in str case conversion methods,Pazzaz,ad7621d42ee90143cd15715cc546177575fd5844,2,Handle array manually in string case conversion methods,THUMBS_UP,2018-07-07T14:32:03Z,kennytm,NA https://github.com/rust-lang/rust/pull/52116,MERGED,2018-07-06T17:55:57Z,2018-07-19T03:05:13Z,Handle array manually in str case conversion methods,Pazzaz,ad7621d42ee90143cd15715cc546177575fd5844,2,Handle array manually in string case conversion methods,THUMBS_UP,2018-07-19T07:39:25Z,msiemens,markus@m-siemens.de https://github.com/rust-lang/rust/pull/52119,CLOSED,2018-07-06T22:52:05Z,2018-07-08T15:47:46Z,Add the `alloc::prelude` module,SimonSapin,NA,NA,NA,THUMBS_UP,2018-07-06T22:53:55Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/52119,CLOSED,2018-07-06T22:52:05Z,2018-07-08T15:47:46Z,Add the `alloc::prelude` module,SimonSapin,NA,NA,NA,HOORAY,2018-07-06T22:53:58Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/52119,CLOSED,2018-07-06T22:52:05Z,2018-07-08T15:47:46Z,Add the `alloc::prelude` module,SimonSapin,NA,NA,NA,HEART,2018-07-06T22:53:59Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/52119,CLOSED,2018-07-06T22:52:05Z,2018-07-08T15:47:46Z,Add the `alloc::prelude` module,SimonSapin,NA,NA,NA,THUMBS_UP,2018-07-07T01:48:49Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/52119,CLOSED,2018-07-06T22:52:05Z,2018-07-08T15:47:46Z,Add the `alloc::prelude` module,SimonSapin,NA,NA,NA,HOORAY,2018-07-07T01:48:50Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/52121,MERGED,2018-07-06T23:58:11Z,2018-10-05T12:52:55Z,Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`,jebrosen,d3c902f3113575b134641c14a9734b5075d06b09,25,Merge the `proc_macro_` expansion feature gates into a single `proc_macro_hygiene` gate.,THUMBS_UP,2018-07-07T03:48:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52121,MERGED,2018-07-06T23:58:11Z,2018-10-05T12:52:55Z,Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`,jebrosen,d3c902f3113575b134641c14a9734b5075d06b09,25,Merge the `proc_macro_` expansion feature gates into a single `proc_macro_hygiene` gate.,CONFUSED,2018-08-25T22:56:02Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/52121,MERGED,2018-07-06T23:58:11Z,2018-10-05T12:52:55Z,Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`,jebrosen,d3c902f3113575b134641c14a9734b5075d06b09,25,Merge the `proc_macro_` expansion feature gates into a single `proc_macro_hygiene` gate.,THUMBS_UP,2018-10-03T17:22:43Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/52121,MERGED,2018-07-06T23:58:11Z,2018-10-05T12:52:55Z,Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`,jebrosen,d3c902f3113575b134641c14a9734b5075d06b09,25,Merge the `proc_macro_` expansion feature gates into a single `proc_macro_hygiene` gate.,THUMBS_UP,2018-10-11T04:19:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,THUMBS_UP,2018-07-08T19:39:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,HOORAY,2018-07-11T04:30:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,HEART,2018-10-02T16:30:58Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,THUMBS_UP,2018-11-14T07:52:46Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,HOORAY,2018-11-14T11:54:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,THUMBS_UP,2018-11-14T11:54:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/52153,MERGED,2018-07-08T15:30:04Z,2018-11-14T05:45:09Z,chalk lowering rule: ProjectionEq-Normalize,csmoe,e853d6c5b6c4eb6f66569bc86c0655a74ef3897d,2,Implement `ProjectionEq-Normalize`,THUMBS_UP,2018-11-22T05:06:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52159,MERGED,2018-07-08T19:18:23Z,2018-07-09T16:41:39Z,Add the `alloc::prelude` module,SimonSapin,5b795cf57e42aa31da7cb175d8ff27633085b5d7,1,Reformat std prelude source to show it is the sum of core and alloc preludes,THUMBS_UP,2018-07-08T19:37:26Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/52166,MERGED,2018-07-09T03:06:11Z,2018-07-09T06:39:12Z,Performance improvement of Vec's swap_remove.,orlp,e529dfd590e6c7e0c19bbf0f3c72e34f25c0cfb8,1,Removed a single trailing space. Oops.,HOORAY,2018-07-12T09:29:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52168,MERGED,2018-07-09T05:09:17Z,2018-07-10T13:22:28Z,find and highlight the `&` or `'_` in `region_name`,nikomatsakis,a6adb1ebff51dd4ff2e724bf980c9b8586142beb,7,find and highlight the `&` or `'_` in `region_name`,THUMBS_UP,2018-07-09T08:51:17Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/52168,MERGED,2018-07-09T05:09:17Z,2018-07-10T13:22:28Z,find and highlight the `&` or `'_` in `region_name`,nikomatsakis,a6adb1ebff51dd4ff2e724bf980c9b8586142beb,7,find and highlight the `&` or `'_` in `region_name`,THUMBS_UP,2018-07-09T19:06:55Z,estebank,NA https://github.com/rust-lang/rust/pull/52172,MERGED,2018-07-09T08:10:12Z,2018-07-11T23:58:56Z,Inject clippy into the rls again,oli-obk,0fc61be68efe6b3419989c62c284c408368b2ea4,1,Remove unused variable,HOORAY,2018-07-09T08:24:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/52172,MERGED,2018-07-09T08:10:12Z,2018-07-11T23:58:56Z,Inject clippy into the rls again,oli-obk,0fc61be68efe6b3419989c62c284c408368b2ea4,1,Remove unused variable,HOORAY,2018-07-09T12:33:15Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/52172,MERGED,2018-07-09T08:10:12Z,2018-07-11T23:58:56Z,Inject clippy into the rls again,oli-obk,0fc61be68efe6b3419989c62c284c408368b2ea4,1,Remove unused variable,HOORAY,2018-07-10T15:55:14Z,mati865,NA https://github.com/rust-lang/rust/pull/52189,MERGED,2018-07-09T20:35:35Z,2018-07-24T13:10:21Z,doc: Clarify the lifetime returned by `Box::leak`,cuviper,6aeeda714e04ac34205a7b948e5585e00d0fa14d,1,doc: Clarify the lifetime returned by `Box::leak` `Box::leak` mentions that it can return a `'static` reference but it wasn't immediately clear to me why it doesn't always do so. This is because of the `T: 'a` constraint needed to form a valid reference and in general we want to be more flexible than requiring `T: 'static`. This patch tries to clarify the relationship between `T` and `'a`.,THUMBS_UP,2018-07-10T03:06:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52189,MERGED,2018-07-09T20:35:35Z,2018-07-24T13:10:21Z,doc: Clarify the lifetime returned by `Box::leak`,cuviper,6aeeda714e04ac34205a7b948e5585e00d0fa14d,1,doc: Clarify the lifetime returned by `Box::leak` `Box::leak` mentions that it can return a `'static` reference but it wasn't immediately clear to me why it doesn't always do so. This is because of the `T: 'a` constraint needed to form a valid reference and in general we want to be more flexible than requiring `T: 'static`. This patch tries to clarify the relationship between `T` and `'a`.,THUMBS_UP,2018-07-24T09:34:09Z,bluss,NA https://github.com/rust-lang/rust/pull/52191,MERGED,2018-07-09T21:24:24Z,2018-07-10T17:29:48Z,Implement #[alloc_error_handler],SimonSapin,239ec7d2dce9c19de16c9ee64addbb834119397c,16,"Implement #[alloc_error_handler] This to-be-stable attribute is equivalent to `#[lang = ""oom""]`. It is required when using the alloc crate without the std crate. It is called by `handle_alloc_error` which is in turned called by ""infallible"" allocations APIs such as `Vec::push`.",THUMBS_UP,2018-07-19T04:24:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52194,MERGED,2018-07-09T22:17:26Z,2018-07-12T06:16:37Z,Remove rustdoc's plugins feature,steveklabnik,0df68d850c0f032afaebba442f0800333772503e,2,Remove rustdoc plugins See CVE-2018-1000622.,THUMBS_UP,2018-07-09T23:25:29Z,ollie27,NA https://github.com/rust-lang/rust/pull/52194,MERGED,2018-07-09T22:17:26Z,2018-07-12T06:16:37Z,Remove rustdoc's plugins feature,steveklabnik,0df68d850c0f032afaebba442f0800333772503e,2,Remove rustdoc plugins See CVE-2018-1000622.,THUMBS_UP,2018-07-10T04:51:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52201,CLOSED,2018-07-10T02:45:33Z,2018-07-11T08:39:17Z,Add #[must_use] to compare_and_swap,jonhoo,NA,NA,NA,THUMBS_UP,2018-07-11T04:28:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52205,CLOSED,2018-07-10T06:24:31Z,2018-07-10T18:24:48Z,Add nowrap_{add|sub|mul|neg} intrinsics,scottmcm,NA,NA,NA,THUMBS_UP,2018-07-10T11:22:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52206,MERGED,2018-07-10T07:08:12Z,2018-08-02T02:24:23Z,slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts,RalfJung,9fcf2c972663ab510417ba1df058f99f0b0d0abe,1,use the same length computation everywhere,HOORAY,2018-07-10T07:12:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52206,MERGED,2018-07-10T07:08:12Z,2018-08-02T02:24:23Z,slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts,RalfJung,9fcf2c972663ab510417ba1df058f99f0b0d0abe,1,use the same length computation everywhere,HOORAY,2018-07-10T19:49:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52206,MERGED,2018-07-10T07:08:12Z,2018-08-02T02:24:23Z,slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts,RalfJung,9fcf2c972663ab510417ba1df058f99f0b0d0abe,1,use the same length computation everywhere,HOORAY,2018-07-30T05:00:03Z,estebank,NA https://github.com/rust-lang/rust/pull/52206,MERGED,2018-07-10T07:08:12Z,2018-08-02T02:24:23Z,slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts,RalfJung,9fcf2c972663ab510417ba1df058f99f0b0d0abe,1,use the same length computation everywhere,HOORAY,2018-08-10T04:12:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52206,MERGED,2018-07-10T07:08:12Z,2018-08-02T02:24:23Z,slices: fix ZST slice iterators making up pointers; debug_assert alignment in from_raw_parts,RalfJung,9fcf2c972663ab510417ba1df058f99f0b0d0abe,1,use the same length computation everywhere,HEART,2018-11-28T13:44:23Z,bluss,NA https://github.com/rust-lang/rust/pull/52207,MERGED,2018-07-10T09:09:26Z,2018-07-11T21:55:00Z,improve error message shown for unsafe operations,RalfJung,f68323b28adf9b5ac1d85abe48915bc189aed813,1,fix typo,THUMBS_UP,2018-07-10T10:03:20Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/52207,MERGED,2018-07-10T09:09:26Z,2018-07-11T21:55:00Z,improve error message shown for unsafe operations,RalfJung,f68323b28adf9b5ac1d85abe48915bc189aed813,1,fix typo,THUMBS_UP,2018-07-10T14:56:26Z,pitdicker,NA https://github.com/rust-lang/rust/pull/52207,MERGED,2018-07-10T09:09:26Z,2018-07-11T21:55:00Z,improve error message shown for unsafe operations,RalfJung,f68323b28adf9b5ac1d85abe48915bc189aed813,1,fix typo,THUMBS_UP,2018-07-10T17:59:53Z,estebank,NA https://github.com/rust-lang/rust/pull/52207,MERGED,2018-07-10T09:09:26Z,2018-07-11T21:55:00Z,improve error message shown for unsafe operations,RalfJung,f68323b28adf9b5ac1d85abe48915bc189aed813,1,fix typo,THUMBS_UP,2018-07-19T04:27:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52207,MERGED,2018-07-10T09:09:26Z,2018-07-11T21:55:00Z,improve error message shown for unsafe operations,RalfJung,f68323b28adf9b5ac1d85abe48915bc189aed813,1,fix typo,THUMBS_UP,2018-07-21T16:51:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52212,MERGED,2018-07-10T14:51:37Z,2018-07-14T12:32:38Z,Set opt-level = 3 the third time.,kennytm,6c635b719d1cc8c8b0165f6ef303ba338cbbd15b,1,"Revert ""Auto merge of #51165 - SimonSapin:opt2 r=alexcrichton"" This reverts commit 524ad9b9e03656f3fdeb03ed82fe78db3916e566 reversing changes made to 59c0f5913ddc2f66c1ff8ab612f7027e38c85a6d.",HOORAY,2018-07-11T04:27:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52212,MERGED,2018-07-10T14:51:37Z,2018-07-14T12:32:38Z,Set opt-level = 3 the third time.,kennytm,6c635b719d1cc8c8b0165f6ef303ba338cbbd15b,1,"Revert ""Auto merge of #51165 - SimonSapin:opt2 r=alexcrichton"" This reverts commit 524ad9b9e03656f3fdeb03ed82fe78db3916e566 reversing changes made to 59c0f5913ddc2f66c1ff8ab612f7027e38c85a6d.",LAUGH,2018-07-11T04:27:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52212,MERGED,2018-07-10T14:51:37Z,2018-07-14T12:32:38Z,Set opt-level = 3 the third time.,kennytm,6c635b719d1cc8c8b0165f6ef303ba338cbbd15b,1,"Revert ""Auto merge of #51165 - SimonSapin:opt2 r=alexcrichton"" This reverts commit 524ad9b9e03656f3fdeb03ed82fe78db3916e566 reversing changes made to 59c0f5913ddc2f66c1ff8ab612f7027e38c85a6d.",HOORAY,2018-07-11T10:31:57Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52212,MERGED,2018-07-10T14:51:37Z,2018-07-14T12:32:38Z,Set opt-level = 3 the third time.,kennytm,6c635b719d1cc8c8b0165f6ef303ba338cbbd15b,1,"Revert ""Auto merge of #51165 - SimonSapin:opt2 r=alexcrichton"" This reverts commit 524ad9b9e03656f3fdeb03ed82fe78db3916e566 reversing changes made to 59c0f5913ddc2f66c1ff8ab612f7027e38c85a6d.",LAUGH,2018-07-14T09:34:03Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/52212,MERGED,2018-07-10T14:51:37Z,2018-07-14T12:32:38Z,Set opt-level = 3 the third time.,kennytm,6c635b719d1cc8c8b0165f6ef303ba338cbbd15b,1,"Revert ""Auto merge of #51165 - SimonSapin:opt2 r=alexcrichton"" This reverts commit 524ad9b9e03656f3fdeb03ed82fe78db3916e566 reversing changes made to 59c0f5913ddc2f66c1ff8ab612f7027e38c85a6d.",LAUGH,2018-08-27T00:07:01Z,estebank,NA https://github.com/rust-lang/rust/pull/52218,MERGED,2018-07-10T17:27:04Z,2018-07-19T03:05:15Z,Amend option.take examples,rivertam,ede1a5d5edcebe28f98057d915ae4602378354dc,1,Amend option.take examples It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change but I think it's an improvement. =) Apologies if I'm not following proper procedures.,THUMBS_UP,2018-07-10T18:22:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52218,MERGED,2018-07-10T17:27:04Z,2018-07-19T03:05:15Z,Amend option.take examples,rivertam,ede1a5d5edcebe28f98057d915ae4602378354dc,1,Amend option.take examples It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change but I think it's an improvement. =) Apologies if I'm not following proper procedures.,HEART,2018-07-10T18:22:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52218,MERGED,2018-07-10T17:27:04Z,2018-07-19T03:05:15Z,Amend option.take examples,rivertam,ede1a5d5edcebe28f98057d915ae4602378354dc,1,Amend option.take examples It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change but I think it's an improvement. =) Apologies if I'm not following proper procedures.,THUMBS_UP,2018-07-11T18:00:55Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/52218,MERGED,2018-07-10T17:27:04Z,2018-07-19T03:05:15Z,Amend option.take examples,rivertam,ede1a5d5edcebe28f98057d915ae4602378354dc,1,Amend option.take examples It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change but I think it's an improvement. =) Apologies if I'm not following proper procedures.,THUMBS_UP,2018-07-18T20:01:49Z,Pratyush,NA https://github.com/rust-lang/rust/pull/52220,MERGED,2018-07-10T18:06:34Z,2018-07-12T15:12:59Z,Deny bare trait objects in src/bootstrap,ljedrz,72b908ffbe42d97dfbad848e0fc53e7e9eecfed9,1,Restore #![deny(warnings)],THUMBS_UP,2018-07-11T04:26:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52221,MERGED,2018-07-10T18:37:26Z,2018-07-27T22:31:47Z,Deny bare trait objects in src/libstd,ljedrz,72e2c00af48ac0c59f5dcae819a6842e8e2029cf,1,Fix redox libstd leftover,THUMBS_UP,2018-07-11T04:26:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52222,MERGED,2018-07-10T18:41:30Z,2018-07-27T22:31:47Z,Deny bare trait objects in src/libcore,ljedrz,66c4dc9769b7ae456fe2960dc5a1e037b2432184,23,Add missing dyn,THUMBS_UP,2018-07-11T04:26:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52224,MERGED,2018-07-10T19:08:17Z,2018-07-11T21:55:03Z,Deny bare trait objects in src/libsyntax,ljedrz,84dadb6139aa4e5f6495a86b2fa27476a6758b4f,1,Pacify tidy,THUMBS_UP,2018-07-11T04:25:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52232,MERGED,2018-07-10T22:16:24Z,2018-07-11T02:44:47Z, use the adjusted type for cat_pattern in tuple patterns ,arielb1,4c044537ce11b5e291e341d90ee112a70b92b040,1,add test for #52213,HOORAY,2018-07-10T22:22:02Z,NilSet,thomas.a.levy@gmail.com https://github.com/rust-lang/rust/pull/52232,MERGED,2018-07-10T22:16:24Z,2018-07-11T02:44:47Z, use the adjusted type for cat_pattern in tuple patterns ,arielb1,4c044537ce11b5e291e341d90ee112a70b92b040,1,add test for #52213,HOORAY,2018-07-10T23:06:24Z,est31,NA https://github.com/rust-lang/rust/pull/52232,MERGED,2018-07-10T22:16:24Z,2018-07-11T02:44:47Z, use the adjusted type for cat_pattern in tuple patterns ,arielb1,4c044537ce11b5e291e341d90ee112a70b92b040,1,add test for #52213,LAUGH,2018-07-10T23:10:37Z,kennytm,NA https://github.com/rust-lang/rust/pull/52232,MERGED,2018-07-10T22:16:24Z,2018-07-11T02:44:47Z, use the adjusted type for cat_pattern in tuple patterns ,arielb1,4c044537ce11b5e291e341d90ee112a70b92b040,1,add test for #52213,HOORAY,2018-07-11T05:22:42Z,estebank,NA https://github.com/rust-lang/rust/pull/52232,MERGED,2018-07-10T22:16:24Z,2018-07-11T02:44:47Z, use the adjusted type for cat_pattern in tuple patterns ,arielb1,4c044537ce11b5e291e341d90ee112a70b92b040,1,add test for #52213,HOORAY,2018-07-11T06:16:59Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/52234,MERGED,2018-07-10T23:54:47Z,2018-07-31T23:00:10Z,resolve: Modularize crate-local `#[macro_export] macro_rules`,petrochenkov,44422409a43544a1300506c83fbc2e8f3049d8a5,14,resolve: Modularize crate-local `#[macro_export] macro_rules`,THUMBS_UP,2018-07-11T00:06:21Z,cramertj,NA https://github.com/rust-lang/rust/pull/52234,MERGED,2018-07-10T23:54:47Z,2018-07-31T23:00:10Z,resolve: Modularize crate-local `#[macro_export] macro_rules`,petrochenkov,44422409a43544a1300506c83fbc2e8f3049d8a5,14,resolve: Modularize crate-local `#[macro_export] macro_rules`,THUMBS_UP,2018-07-13T08:21:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/52234,MERGED,2018-07-10T23:54:47Z,2018-07-31T23:00:10Z,resolve: Modularize crate-local `#[macro_export] macro_rules`,petrochenkov,44422409a43544a1300506c83fbc2e8f3049d8a5,14,resolve: Modularize crate-local `#[macro_export] macro_rules`,THUMBS_UP,2018-08-27T20:43:22Z,jseyfried,NA https://github.com/rust-lang/rust/pull/52239,MERGED,2018-07-11T02:52:49Z,2018-07-11T21:55:04Z,Remove sync::Once::call_once 'static bound,CAD97,0f3f292b4c7a15b656a925e7ebe5f2d3955b8553,1,remove sync::Once::call_once 'static - [std: Rewrite the `sync` modulehttps://github.com/rust-lang/rust/commit/71d4e77db8ad4b6d821da7e5d5300134ac95974e) (Nov 2014) ```diff - pub fn doit(&self f: ||) { + pub fn doit(&'static self f: ||) { ``` > ```text > The second layer is the layer provided by `std::sync` which is intended to be > the thinnest possible layer on top of `sys_common` which is entirely safe to > use. There are a few concerns which need to be addressed when making these > system primitives safe: > > * Once used the OS primitives can never be **moved**. This means that they > essentially need to have a stable address. The static primitives use > `&'static self` to enforce this and the non-static primitives all use a > `Box` to provide this guarantee. > ``` The author of this diff is @alexcrichton. `sync::Once` contains only a pointer to (privately hidden) `Waiter`s which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable. See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.,THUMBS_UP,2018-07-18T21:21:17Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/52242,MERGED,2018-07-11T06:40:29Z,2018-07-13T19:49:27Z,NLL: Suggest `ref mut` and `&mut self`,ashtneoi,1ed861910f1a875c7bf19ee398cad1570b92aad4,1,Bless one more test,HEART,2018-07-12T12:25:08Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/52242,MERGED,2018-07-11T06:40:29Z,2018-07-13T19:49:27Z,NLL: Suggest `ref mut` and `&mut self`,ashtneoi,1ed861910f1a875c7bf19ee398cad1570b92aad4,1,Bless one more test,HEART,2018-07-19T04:25:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52250,MERGED,2018-07-11T10:33:11Z,2018-07-22T04:46:56Z,Speed up `SparseBitMatrix` use in `RegionValues`.,nnethercote,798209e78b90b83a3742f713b70473b6ab799aca,2,Speed up `SparseBitMatrix`. Using a `BTreeMap` to represent rows in the bit matrix is really slow. This patch changes things so that each row is represented by a `BitVector`. This is a less sparse representation but a much faster one. As a result `SparseBitSet` and `SparseChunk` can be removed. Other minor changes in this patch. - It renames `BitVector::insert()` as `merge()` which matches the terminology in the other classes in bitvec.rs. - It removes `SparseBitMatrix::is_subset()` which is unused. - It reinstates `RegionValueElements::num_elements()` which #52190 had removed. - It removes a low-value `debug!` call in `SparseBitMatrix::add()`.,THUMBS_UP,2018-07-11T13:04:48Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52250,MERGED,2018-07-11T10:33:11Z,2018-07-22T04:46:56Z,Speed up `SparseBitMatrix` use in `RegionValues`.,nnethercote,798209e78b90b83a3742f713b70473b6ab799aca,2,Speed up `SparseBitMatrix`. Using a `BTreeMap` to represent rows in the bit matrix is really slow. This patch changes things so that each row is represented by a `BitVector`. This is a less sparse representation but a much faster one. As a result `SparseBitSet` and `SparseChunk` can be removed. Other minor changes in this patch. - It renames `BitVector::insert()` as `merge()` which matches the terminology in the other classes in bitvec.rs. - It removes `SparseBitMatrix::is_subset()` which is unused. - It reinstates `RegionValueElements::num_elements()` which #52190 had removed. - It removes a low-value `debug!` call in `SparseBitMatrix::add()`.,THUMBS_UP,2018-07-11T15:29:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52264,MERGED,2018-07-11T15:39:37Z,2018-07-16T16:18:58Z,Rename spanned HIR node enums from Foo_ to FooKind ,csmoe,c692816eaf927fae0247866eb704c99a757932fd,1,Update the clippy submodule,HOORAY,2018-07-11T15:53:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52264,MERGED,2018-07-11T15:39:37Z,2018-07-16T16:18:58Z,Rename spanned HIR node enums from Foo_ to FooKind ,csmoe,c692816eaf927fae0247866eb704c99a757932fd,1,Update the clippy submodule,HEART,2018-07-11T18:02:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/52264,MERGED,2018-07-11T15:39:37Z,2018-07-16T16:18:58Z,Rename spanned HIR node enums from Foo_ to FooKind ,csmoe,c692816eaf927fae0247866eb704c99a757932fd,1,Update the clippy submodule,HOORAY,2018-07-11T18:02:50Z,cramertj,NA https://github.com/rust-lang/rust/pull/52266,MERGED,2018-07-11T15:58:37Z,2018-07-14T00:12:32Z,Preliminary work for incremental ThinLTO.,michaelwoerister,e045a6cd8c0235a26ef11e6cd9a13ebd817f1265,4,Use callback-based interface to load ThinLTO import data into rustc.,THUMBS_UP,2018-07-11T18:01:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52266,MERGED,2018-07-11T15:58:37Z,2018-07-14T00:12:32Z,Preliminary work for incremental ThinLTO.,michaelwoerister,e045a6cd8c0235a26ef11e6cd9a13ebd817f1265,4,Use callback-based interface to load ThinLTO import data into rustc.,THUMBS_UP,2018-07-11T18:07:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52266,MERGED,2018-07-11T15:58:37Z,2018-07-14T00:12:32Z,Preliminary work for incremental ThinLTO.,michaelwoerister,e045a6cd8c0235a26ef11e6cd9a13ebd817f1265,4,Use callback-based interface to load ThinLTO import data into rustc.,THUMBS_UP,2018-07-11T18:48:24Z,ondj,NA https://github.com/rust-lang/rust/pull/52271,CLOSED,2018-07-11T19:58:28Z,2018-07-30T16:50:39Z,Remove the private field from LayoutErr,Amanieu,NA,NA,NA,THUMBS_DOWN,2018-07-11T20:10:58Z,kennytm,NA https://github.com/rust-lang/rust/pull/52271,CLOSED,2018-07-11T19:58:28Z,2018-07-30T16:50:39Z,Remove the private field from LayoutErr,Amanieu,NA,NA,NA,THUMBS_DOWN,2018-07-17T06:01:58Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/52285,MERGED,2018-07-12T07:16:13Z,2018-07-17T05:43:33Z,Deny bare trait objects in librustc_driver,ljedrz,db7170cf4ad9e4c72e5c456891647d0e1b6355be,1,Add missing dyn in driver.rs,HEART,2018-07-16T08:46:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52302,MERGED,2018-07-12T12:22:04Z,2018-07-13T22:06:27Z,Deny bare trait objects in the rest of rust,ljedrz,5058af70039d4cf417f6cc94617da7b5d647182a,26,Deny bare trait objects in the rest of rust,HOORAY,2018-07-12T13:07:35Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/52309,CLOSED,2018-07-12T15:16:20Z,2018-07-23T08:42:53Z,[wip] Enable ThinLTO with incremental compilation.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-07-12T20:20:24Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52309,CLOSED,2018-07-12T15:16:20Z,2018-07-23T08:42:53Z,[wip] Enable ThinLTO with incremental compilation.,michaelwoerister,NA,NA,NA,HOORAY,2018-07-12T20:20:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52309,CLOSED,2018-07-12T15:16:20Z,2018-07-23T08:42:53Z,[wip] Enable ThinLTO with incremental compilation.,michaelwoerister,NA,NA,NA,HOORAY,2018-07-13T14:44:13Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/52333,MERGED,2018-07-13T05:20:48Z,2018-07-13T22:06:31Z,CI: Enable core dump on Linux and print their stack trace on segfault. ,kennytm,1e1b800c2eb81418613520f9ede321e9d97e1707,3,Enabled core dump on Linux and print stack trace on failure.,THUMBS_UP,2018-07-13T11:44:08Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52336,MERGED,2018-07-13T05:58:43Z,2018-07-27T22:31:48Z,Rollup of bare_trait_objects PRs,ishitatsuyuki,62f73dc87c34a99360ba4aacdffe6c8bc320d763,4,Refactor is_external_tool into source_type,THUMBS_UP,2018-07-13T06:14:16Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52340,MERGED,2018-07-13T10:53:57Z,2018-08-01T10:42:32Z,Document From trait implementations for OsStr OsString CString and CStr,cypher,ed5edcb3186e87715143bbd53ab1dfa69771cbf9,2,Seperate summaries from rest of the comment,THUMBS_UP,2018-07-13T11:45:58Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52342,MERGED,2018-07-13T13:06:09Z,2018-07-18T03:05:38Z,Avoid most allocations in `Canonicalizer`.,nnethercote,7cc527770d1270921647a4324cb30d0d89467de6,12,"Avoid most allocations in `Canonicalizer`. Extra allocations are a significant cost of NLL and the most common ones come from within `Canonicalizer`. In particular `canonical_var()` contains this code: indices .entry(kind) .or_insert_with(|| { let cvar1 = variables.push(info); let cvar2 = var_values.push(kind); assert_eq!(cvar1 cvar2); cvar1 }) .clone() `variables` and `var_values` are `Vec`s. `indices` is a `HashMap` used to track what elements have been inserted into `var_values`. If `kind` hasn't been seen before `indices` `variables` and `var_values` all get a new element. (The number of elements in each container is always the same.) This results in lots of allocations. In practice most of the time these containers only end up holding a few elements. This PR changes them to avoid heap allocations in the common case by changing the `Vec`s to `SmallVec`s and only using `indices` once enough elements are present. (When the number of elements is small a direct linear search of `var_values` is as good or better than a hashmap lookup.) The changes to `variables` are straightforward and contained within `Canonicalizer`. The changes to `indices` are more complex but also contained within `Canonicalizer`. The changes to `var_values` are more intrusive because they require defining a new type `SmallCanonicalVarValues` -- which is to `CanonicalVarValues` as `SmallVec` is to `Vec -- and passing stack-allocated values of that type in from outside. All this speeds up a number of NLL ""check"" builds the best by 2%.",THUMBS_UP,2018-07-14T19:39:56Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52354,MERGED,2018-07-13T20:52:35Z,2018-07-20T20:07:00Z,stabilize lint handling in rustdoc,QuietMisdreavus,8f1ebbc03c7add660350034b2c7e2cf77cba08c2,1,stabilize lint handling in rustdoc,THUMBS_UP,2018-07-13T22:28:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/52361,MERGED,2018-07-14T02:51:03Z,2018-07-15T10:29:18Z,rustdoc: don't panic when the cross-re-export handler sees a proc-macro,QuietMisdreavus,e78fb9bad0e9137c75147c4469806fe0e61154c2,1,add test for issue 52129,THUMBS_UP,2018-07-14T04:30:02Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/52386,MERGED,2018-07-14T19:08:38Z,2018-07-16T06:48:01Z,Clarify how the quote macro is loaded,Manishearth,58f3f7b0810ff2349cec21395ee066dc2df004a7,2,Clarify how the quote macro is loaded,HEART,2018-07-14T19:13:14Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/52391,MERGED,2018-07-14T22:57:42Z,2018-07-25T02:29:35Z,Add unaligned volatile intrinsics,Amanieu,303306cf5ede678719ec1324bb02d3d02c014183,6,Add unaligned volatile intrinsics,THUMBS_UP,2018-07-14T23:53:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52394,MERGED,2018-07-15T03:53:23Z,2018-07-22T08:52:20Z,Improve suggestion for missing fmt str in println,estebank,dc563d950017fedaa4690165d2d8b9b3e6cbd982,1,fix test,HEART,2018-07-15T05:02:50Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/52394,MERGED,2018-07-15T03:53:23Z,2018-07-22T08:52:20Z,Improve suggestion for missing fmt str in println,estebank,dc563d950017fedaa4690165d2d8b9b3e6cbd982,1,fix test,HEART,2018-07-15T09:40:04Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HEART,2018-08-08T00:24:21Z,sunjay,NA https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HEART,2018-08-08T09:48:30Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HEART,2018-08-14T23:44:28Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HEART,2018-08-15T10:47:01Z,jplatte,NA https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HEART,2018-08-16T05:24:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52397,MERGED,2018-07-15T07:07:22Z,2018-08-08T00:21:12Z,"Suggest comma when writing `println!(""{}"" a);`",estebank,daa5bd35a8746126a4af014d135ddb8bc442b9e6,1,fix typo,HOORAY,2018-08-17T08:51:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/52401,MERGED,2018-07-15T11:47:09Z,2018-07-16T01:41:09Z,tidy: add a new test for external dependencies,semarie,a4ddda31e95184a443fd237744479557c09cc76b,3,tidy: add a new test for external dependencies ensure all packages in Cargo.lock will be vendored and fail if the source packages isn't whitelisted.,HEART,2018-07-15T14:27:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52405,MERGED,2018-07-15T18:01:03Z,2018-07-21T16:41:43Z,[NLL] Mutability errors,matthewjasper,a06b2433fc2963dba4ef25deee6720c63ffcc03b,52,Update tests for new NLL mutability errors,HOORAY,2018-07-17T12:56:12Z,lqd,NA https://github.com/rust-lang/rust/pull/52434,MERGED,2018-07-16T15:35:38Z,2018-07-17T15:38:56Z,Enable incremental independent of stage,Mark-Simulacrum,827f656ebb1230f31af6d968c4bfe69a79914ffc,1,Enable incremental independent of stage Previously we'd only do so for stage 0 but with keep-stage improvements it seems likely that we'll see more developers working in the stage 1 so we should allow enabling incremental for them. Ideally the check we probably want is to only enable incremental for the last compiler build scheduled but there's no good way to do so today. Just enabling incremental in all stages should be sufficient; we may be doing extra work that's needles -- compiling incrementally something that will never be recompiled in-place -- but that should be sufficiently unlikely (i.e. users either don't care or won't be compiling the compiler twice).,THUMBS_UP,2018-07-17T10:53:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52450,MERGED,2018-07-17T02:37:50Z,2018-08-07T11:00:14Z,Closes #52413: Provide structured suggestion instead of label,PramodBisht,49b0a1e073f708edb172cba50d8cb352204cfdc4,39,#52413: addressed @estebank's Nit,HEART,2018-08-05T20:59:53Z,estebank,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-17T16:09:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HEART,2018-07-17T16:09:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-17T17:21:38Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-18T08:24:08Z,bjorn3,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-18T10:33:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-21T07:27:07Z,qnighy,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HEART,2018-07-21T07:27:08Z,qnighy,NA https://github.com/rust-lang/rust/pull/52461,MERGED,2018-07-17T15:58:58Z,2018-07-31T15:33:33Z, rustc_codegen_llvm: use safe references for LLVM FFI types.,irinagpopa,baff67d51f691734ecee0faa83acee91ec16cc5d,2,rustc_llvm: fix linking on mingw.,HOORAY,2018-07-30T17:47:47Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52467,MERGED,2018-07-17T18:30:05Z,2018-07-20T11:11:13Z,Squash all lints tied to foreign macros by default,alexcrichton,8adf08c4373f5bdd5bbef9aa4dfd0ca5c4a2eefc,5,rustc: Polish off `in_external_macro` This commit polishes off this new function to compile on newer rustc as well as update and add a suite of test cases to work with this new check for lints.,THUMBS_UP,2018-07-17T18:31:25Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/52467,MERGED,2018-07-17T18:30:05Z,2018-07-20T11:11:13Z,Squash all lints tied to foreign macros by default,alexcrichton,8adf08c4373f5bdd5bbef9aa4dfd0ca5c4a2eefc,5,rustc: Polish off `in_external_macro` This commit polishes off this new function to compile on newer rustc as well as update and add a suite of test cases to work with this new check for lints.,THUMBS_UP,2018-07-17T19:06:49Z,estebank,NA https://github.com/rust-lang/rust/pull/52467,MERGED,2018-07-17T18:30:05Z,2018-07-20T11:11:13Z,Squash all lints tied to foreign macros by default,alexcrichton,8adf08c4373f5bdd5bbef9aa4dfd0ca5c4a2eefc,5,rustc: Polish off `in_external_macro` This commit polishes off this new function to compile on newer rustc as well as update and add a suite of test cases to work with this new check for lints.,HEART,2018-07-17T19:14:52Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/52467,MERGED,2018-07-17T18:30:05Z,2018-07-20T11:11:13Z,Squash all lints tied to foreign macros by default,alexcrichton,8adf08c4373f5bdd5bbef9aa4dfd0ca5c4a2eefc,5,rustc: Polish off `in_external_macro` This commit polishes off this new function to compile on newer rustc as well as update and add a suite of test cases to work with this new check for lints.,HEART,2018-07-17T20:31:49Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/52476,MERGED,2018-07-18T02:14:17Z,2018-07-20T13:22:51Z,Categorize queries for later self-profiling,wesleywiser,0223ef90111a95d5110c34299bf19c36120d5212,2,Categorize queries for later self-profiling Change the define_queries! macro per feedback on #51657. Big thanks to @mark-i-m for the help getting the macro changes correct!,HEART,2018-07-18T02:45:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52476,MERGED,2018-07-18T02:14:17Z,2018-07-20T13:22:51Z,Categorize queries for later self-profiling,wesleywiser,0223ef90111a95d5110c34299bf19c36120d5212,2,Categorize queries for later self-profiling Change the define_queries! macro per feedback on #51657. Big thanks to @mark-i-m for the help getting the macro changes correct!,THUMBS_UP,2018-07-18T17:39:46Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52498,MERGED,2018-07-18T16:53:38Z,2018-07-20T15:33:47Z,Const propagate casts,oli-obk,9329957d321a3612fe9c95cf58a67115b0bbda5f,4,Const-propagate casts,LAUGH,2018-07-18T21:52:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/52502,MERGED,2018-07-18T17:37:35Z,2018-07-21T00:56:01Z,fix ptr_rotate comments,RalfJung,16c057256f68b39df70737838f367cf645d6e0c7,1,fix safety-related comment in slice::rotate,HEART,2018-07-19T03:49:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52506,MERGED,2018-07-18T19:14:55Z,2018-07-23T15:39:01Z,rustc: Work around an upstream wasm ThinLTO bug,alexcrichton,e08fcbbd8d241ab68d72dc8b288ca55b8c1114fe,4,rustc: Work around an upstream wasm ThinLTO bug This commit implements a workaround for an [upstream LLVM bug][1] where custom sections were accidentally duplicated amongst codegen units when ThinLTO passes were performed. This is due to the fact that custom sections for wasm are stored as metadata nodes which are automatically imported into modules when ThinLTO happens. The fix here is to forcibly delete the metadata node from imported modules before LLVM has a chance to try to copy it over. [1]: https://bugs.llvm.org/show_bug.cgi?id=38184,THUMBS_UP,2018-07-26T11:47:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52514,MERGED,2018-07-19T03:06:44Z,2018-09-12T11:27:44Z,Fix a few AMDGPU related issues,DiamondLovesYou,66e8e1953e25a8d9e86e2e3fef88cc178a9cea02,1,Fix an AMDGPU related load bit range metadata assertion.,THUMBS_UP,2018-07-19T18:24:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52514,MERGED,2018-07-19T03:06:44Z,2018-09-12T11:27:44Z,Fix a few AMDGPU related issues,DiamondLovesYou,66e8e1953e25a8d9e86e2e3fef88cc178a9cea02,1,Fix an AMDGPU related load bit range metadata assertion.,THUMBS_UP,2018-08-11T18:21:12Z,mati865,NA https://github.com/rust-lang/rust/pull/52514,MERGED,2018-07-19T03:06:44Z,2018-09-12T11:27:44Z,Fix a few AMDGPU related issues,DiamondLovesYou,66e8e1953e25a8d9e86e2e3fef88cc178a9cea02,1,Fix an AMDGPU related load bit range metadata assertion.,HEART,2018-09-16T11:07:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52518,CLOSED,2018-07-19T03:40:10Z,2019-02-12T15:52:25Z,[WIP] Preliminary work splitting const qualification into separate passes,alexreg,NA,NA,NA,HOORAY,2018-07-22T19:14:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52535,MERGED,2018-07-19T14:02:44Z,2018-07-21T08:31:50Z,Update stdsimd to undo an accidental stabilization,alexcrichton,d77defcca114c14e6bbedc24697ead76a249a567,4,Update stdsimd to undo an accidental stabilization Closes #52403,THUMBS_UP,2018-07-19T20:12:41Z,pitdicker,NA https://github.com/rust-lang/rust/pull/52536,MERGED,2018-07-19T14:09:00Z,2018-07-21T06:26:30Z,proc_macro: Preserve spans of attributes on functions,alexcrichton,53323751a9caaf678689e0d437f79d0c169b2dae,5,proc_macro: Preserve spans of attributes on functions This commit updates the tokenization of items which are subsequently passed to `proc_macro` to ensure that span information is preserved on attributes as much as possible. Previously this area of the code suffered from #43081 where we haven't actually implemented converting an attribute to to a token tree yet but a local fix was possible here. Closes #47941,HOORAY,2018-07-21T06:28:11Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/52552,MERGED,2018-07-19T21:22:43Z,2018-07-21T10:30:26Z,Prepare proc_macro for decoupling it from the rest of the compiler.,eddyb,99eac011c6059de129de4b1c8ab7c6cd6794e6e4,1,proc_macro: avoid exposing internal details in formatting impls.,HOORAY,2018-07-19T21:25:45Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/52552,MERGED,2018-07-19T21:22:43Z,2018-07-21T10:30:26Z,Prepare proc_macro for decoupling it from the rest of the compiler.,eddyb,99eac011c6059de129de4b1c8ab7c6cd6794e6e4,1,proc_macro: avoid exposing internal details in formatting impls.,HOORAY,2018-07-19T23:27:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52552,MERGED,2018-07-19T21:22:43Z,2018-07-21T10:30:26Z,Prepare proc_macro for decoupling it from the rest of the compiler.,eddyb,99eac011c6059de129de4b1c8ab7c6cd6794e6e4,1,proc_macro: avoid exposing internal details in formatting impls.,HOORAY,2018-07-20T02:43:57Z,est31,NA https://github.com/rust-lang/rust/pull/52552,MERGED,2018-07-19T21:22:43Z,2018-07-21T10:30:26Z,Prepare proc_macro for decoupling it from the rest of the compiler.,eddyb,99eac011c6059de129de4b1c8ab7c6cd6794e6e4,1,proc_macro: avoid exposing internal details in formatting impls.,HOORAY,2018-07-20T13:05:11Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/52552,MERGED,2018-07-19T21:22:43Z,2018-07-21T10:30:26Z,Prepare proc_macro for decoupling it from the rest of the compiler.,eddyb,99eac011c6059de129de4b1c8ab7c6cd6794e6e4,1,proc_macro: avoid exposing internal details in formatting impls.,HOORAY,2018-07-20T13:54:58Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52553,MERGED,2018-07-19T21:39:49Z,2018-08-18T11:04:24Z,Non-naive implementation of `VecDeque.append`,Pazzaz,b063bd4616bf2f27b814f39f0e452efd171fd539,1,Test VecDeque append not dropping twice,HOORAY,2018-07-19T21:41:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52553,MERGED,2018-07-19T21:39:49Z,2018-08-18T11:04:24Z,Non-naive implementation of `VecDeque.append`,Pazzaz,b063bd4616bf2f27b814f39f0e452efd171fd539,1,Test VecDeque append not dropping twice,HOORAY,2018-07-19T22:07:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/52553,MERGED,2018-07-19T21:39:49Z,2018-08-18T11:04:24Z,Non-naive implementation of `VecDeque.append`,Pazzaz,b063bd4616bf2f27b814f39f0e452efd171fd539,1,Test VecDeque append not dropping twice,THUMBS_UP,2018-08-22T08:38:49Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/52553,MERGED,2018-07-19T21:39:49Z,2018-08-18T11:04:24Z,Non-naive implementation of `VecDeque.append`,Pazzaz,b063bd4616bf2f27b814f39f0e452efd171fd539,1,Test VecDeque append not dropping twice,HOORAY,2018-08-22T17:15:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52553,MERGED,2018-07-19T21:39:49Z,2018-08-18T11:04:24Z,Non-naive implementation of `VecDeque.append`,Pazzaz,b063bd4616bf2f27b814f39f0e452efd171fd539,1,Test VecDeque append not dropping twice,HOORAY,2018-08-22T18:08:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-20T00:44:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T13:34:00Z,Flaise,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T13:56:26Z,Mortichar,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T15:12:56Z,Tom-Phinney,tom.phinney@cox.net https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,CONFUSED,2018-07-21T16:08:37Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T16:19:06Z,ChristopherRabotin,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T18:31:46Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T18:52:04Z,sunjay,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T19:11:32Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-21T22:46:59Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,CONFUSED,2018-07-21T23:15:43Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T02:12:54Z,randomPoison,dlegare.1001@gmail.com https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T06:33:10Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_DOWN,2018-07-22T10:29:15Z,flexera-cnixon,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,CONFUSED,2018-07-22T10:29:19Z,flexera-cnixon,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T11:05:33Z,snsmac,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,CONFUSED,2018-07-22T12:45:56Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T17:25:20Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T19:12:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,HOORAY,2018-07-22T19:13:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T21:53:16Z,JelteF,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-22T23:32:57Z,Ralith,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-23T04:41:55Z,jakeschurch,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-24T11:01:16Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,HOORAY,2018-07-24T11:01:17Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,CONFUSED,2018-07-25T15:48:12Z,johnteee,NA https://github.com/rust-lang/rust/pull/52556,CLOSED,2018-07-20T00:43:10Z,2018-07-28T22:03:08Z,Time units,newpavlov,NA,NA,NA,THUMBS_UP,2018-07-26T00:36:30Z,Sasasu,i@sasa.su https://github.com/rust-lang/rust/pull/52558,MERGED,2018-07-20T03:21:12Z,2018-07-26T19:51:26Z,Add tests for ICEs which no longer repro,wesleywiser,715005c1a76129f7d2c0e85f2ef0af96a8c2add6,5,Update compile-fail tests to be ui tests,HOORAY,2018-07-20T03:25:32Z,estebank,NA https://github.com/rust-lang/rust/pull/52558,MERGED,2018-07-20T03:21:12Z,2018-07-26T19:51:26Z,Add tests for ICEs which no longer repro,wesleywiser,715005c1a76129f7d2c0e85f2ef0af96a8c2add6,5,Update compile-fail tests to be ui tests,HEART,2018-07-20T12:09:41Z,varkor,NA https://github.com/rust-lang/rust/pull/52558,MERGED,2018-07-20T03:21:12Z,2018-07-26T19:51:26Z,Add tests for ICEs which no longer repro,wesleywiser,715005c1a76129f7d2c0e85f2ef0af96a8c2add6,5,Update compile-fail tests to be ui tests,HEART,2018-07-23T00:43:28Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52558,MERGED,2018-07-20T03:21:12Z,2018-07-26T19:51:26Z,Add tests for ICEs which no longer repro,wesleywiser,715005c1a76129f7d2c0e85f2ef0af96a8c2add6,5,Update compile-fail tests to be ui tests,HOORAY,2018-07-23T00:43:28Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52571,MERGED,2018-07-20T16:47:27Z,2018-07-23T05:03:40Z,Abort if a promoted fails to be const evaluable and its runtime checks didn't trigger,oli-obk,233a6e13ca2f6dec6590a6bf92dd73de303a9d00,1,Use correct exclusion comment,THUMBS_UP,2018-07-20T16:56:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52571,MERGED,2018-07-20T16:47:27Z,2018-07-23T05:03:40Z,Abort if a promoted fails to be const evaluable and its runtime checks didn't trigger,oli-obk,233a6e13ca2f6dec6590a6bf92dd73de303a9d00,1,Use correct exclusion comment,HEART,2018-07-20T16:59:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52571,MERGED,2018-07-20T16:47:27Z,2018-07-23T05:03:40Z,Abort if a promoted fails to be const evaluable and its runtime checks didn't trigger,oli-obk,233a6e13ca2f6dec6590a6bf92dd73de303a9d00,1,Use correct exclusion comment,HOORAY,2018-07-20T18:40:53Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52571,MERGED,2018-07-20T16:47:27Z,2018-07-23T05:03:40Z,Abort if a promoted fails to be const evaluable and its runtime checks didn't trigger,oli-obk,233a6e13ca2f6dec6590a6bf92dd73de303a9d00,1,Use correct exclusion comment,THUMBS_UP,2018-08-02T06:00:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52572,MERGED,2018-07-20T16:59:11Z,2018-07-22T18:52:00Z,NLL diagnostics replaced nice closure errors w/ indecipherable free region errors ,davidtwco,c64db0078a425c71e131432c41d9c6fc6f961b0e,10,Fallback to general error handling in ICE cases.,HOORAY,2018-07-22T19:58:44Z,estebank,NA https://github.com/rust-lang/rust/pull/52580,CLOSED,2018-07-20T23:15:32Z,2018-08-27T16:10:30Z,Define non-panicking UTF encoding methods on `char`,strake,NA,NA,NA,THUMBS_UP,2018-08-01T06:11:28Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-07-21T13:05:30Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-07-21T13:23:10Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-07-21T14:04:15Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HEART,2018-07-21T14:04:17Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-07-21T14:32:39Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HEART,2018-07-21T14:40:55Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-07-22T19:42:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HOORAY,2018-12-01T16:42:57Z,hcpl,NA https://github.com/rust-lang/rust/pull/52585,MERGED,2018-07-21T12:36:48Z,2018-07-28T22:52:19Z,[rustdoc] Generic impls,GuillaumeGomez,06364bd46019bc598d5c8eb16ae1481d57827530,1,Move blanket implementations generation into its own function,HEART,2018-12-01T16:42:58Z,hcpl,NA https://github.com/rust-lang/rust/pull/52592,MERGED,2018-07-21T19:52:30Z,2018-08-19T00:08:26Z,Use the new Entry::or_default method where possible.,eddyb,14aed81d9ac058824af62c37b892b50fdb769912,36,Use the new Entry::or_default method where possible.,HOORAY,2018-07-23T01:39:52Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/52592,MERGED,2018-07-21T19:52:30Z,2018-08-19T00:08:26Z,Use the new Entry::or_default method where possible.,eddyb,14aed81d9ac058824af62c37b892b50fdb769912,36,Use the new Entry::or_default method where possible.,HOORAY,2018-07-30T04:38:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52602,MERGED,2018-07-22T01:50:02Z,2018-08-23T13:53:58Z,Implement try block expressions,scottmcm,009547141729b6d66f721065820edf9ddbde4831,2,Switch out another use of `do catch`,THUMBS_UP,2018-08-29T15:18:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52602,MERGED,2018-07-22T01:50:02Z,2018-08-23T13:53:58Z,Implement try block expressions,scottmcm,009547141729b6d66f721065820edf9ddbde4831,2,Switch out another use of `do catch`,THUMBS_UP,2020-01-21T02:22:44Z,BrandonDyer64,brandondyer64@gmail.com https://github.com/rust-lang/rust/pull/52612,MERGED,2018-07-22T10:21:01Z,2018-07-23T08:55:04Z,Don't keep the possibly initialized flow around longer than needed,matthewjasper,1d912bfb422b187d929a2bc3542556a78b19257d,2,Don't keep the possibly init flow around longer than needed,THUMBS_UP,2018-07-24T20:47:33Z,lqd,NA https://github.com/rust-lang/rust/pull/52621,MERGED,2018-07-22T18:21:55Z,2018-07-24T05:56:26Z,Fix color detection for Windows msys terminals.,ehuss,bf2fc77a2fa5543b7d527ddf2c9f2bc6452c5eed,1,Fix color detection for Windows msys terminals.,HOORAY,2018-07-22T19:01:13Z,aloucks,NA https://github.com/rust-lang/rust/pull/52621,MERGED,2018-07-22T18:21:55Z,2018-07-24T05:56:26Z,Fix color detection for Windows msys terminals.,ehuss,bf2fc77a2fa5543b7d527ddf2c9f2bc6452c5eed,1,Fix color detection for Windows msys terminals.,HOORAY,2018-07-22T19:02:06Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52642,MERGED,2018-07-23T12:50:54Z,2018-07-24T05:56:29Z,Replace a few expect+format combos with unwrap_or_else+panic,ljedrz,fe588d894fa392fdf787c18a959b342d38d0c71c,5,Replace a few expect+format combos with unwrap_or_else+panic,THUMBS_UP,2018-07-23T18:14:46Z,estebank,NA https://github.com/rust-lang/rust/pull/52644,MERGED,2018-07-23T12:54:59Z,2018-08-06T19:15:12Z,Add errors for unknown stable and duplicate feature attributes,varkor,4687476470d383fefe62ac9cde4e6f9015ba550f,1,"Special-case ""test"" feature",HOORAY,2018-07-23T13:20:23Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/52644,MERGED,2018-07-23T12:54:59Z,2018-08-06T19:15:12Z,Add errors for unknown stable and duplicate feature attributes,varkor,4687476470d383fefe62ac9cde4e6f9015ba550f,1,"Special-case ""test"" feature",HOORAY,2018-08-03T17:24:15Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/52644,MERGED,2018-07-23T12:54:59Z,2018-08-06T19:15:12Z,Add errors for unknown stable and duplicate feature attributes,varkor,4687476470d383fefe62ac9cde4e6f9015ba550f,1,"Special-case ""test"" feature",HOORAY,2018-08-06T20:34:17Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/52644,MERGED,2018-07-23T12:54:59Z,2018-08-06T19:15:12Z,Add errors for unknown stable and duplicate feature attributes,varkor,4687476470d383fefe62ac9cde4e6f9015ba550f,1,"Special-case ""test"" feature",HOORAY,2018-08-16T05:24:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52647,MERGED,2018-07-23T14:20:34Z,2018-07-26T19:51:32Z,Suggest to take and ignore args while closure args count mismatching,csmoe,1d79588994ca773fa80938021729dbff4679d78b,1,Update ui test,HEART,2018-07-25T01:21:28Z,estebank,NA https://github.com/rust-lang/rust/pull/52649,MERGED,2018-07-23T15:39:41Z,2018-07-26T19:51:32Z,Point spans to inner elements of format strings,estebank,9a893cc2b82ac6259aead1319758404b80b8a959,4,Add span label for format str missing specifier,HEART,2018-07-26T07:33:29Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/52649,MERGED,2018-07-23T15:39:41Z,2018-07-26T19:51:32Z,Point spans to inner elements of format strings,estebank,9a893cc2b82ac6259aead1319758404b80b8a959,4,Add span label for format str missing specifier,HEART,2018-07-26T17:34:49Z,lqd,NA https://github.com/rust-lang/rust/pull/52649,MERGED,2018-07-23T15:39:41Z,2018-07-26T19:51:32Z,Point spans to inner elements of format strings,estebank,9a893cc2b82ac6259aead1319758404b80b8a959,4,Add span label for format str missing specifier,HEART,2019-10-05T01:43:03Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-07-23T17:18:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-07-23T22:46:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-07-23T22:52:27Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-07-24T04:23:05Z,estebank,NA https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-07-25T14:48:27Z,qnighy,NA https://github.com/rust-lang/rust/pull/52650,MERGED,2018-07-23T15:41:04Z,2018-07-27T09:10:24Z,Implement associated existential types,oli-obk,33712a8a10eb193e1d90c52b666a053309b7a8dc,1,Add type system canaries for potential future bugs,HEART,2018-08-04T15:39:04Z,chpio,NA https://github.com/rust-lang/rust/pull/52658,MERGED,2018-07-24T06:45:19Z,2018-07-25T02:29:42Z,Prefer `Option::map`/etc over `match` wherever it improves clarity,Wallacoloo,cbe5f1c4207673b9059e832ef2f134b4f87b380d,1,libsyntax_ext: Prefer `Option::map` over `match` where applicable,THUMBS_UP,2018-07-24T06:58:55Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52658,MERGED,2018-07-24T06:45:19Z,2018-07-25T02:29:42Z,Prefer `Option::map`/etc over `match` wherever it improves clarity,Wallacoloo,cbe5f1c4207673b9059e832ef2f134b4f87b380d,1,libsyntax_ext: Prefer `Option::map` over `match` where applicable,THUMBS_UP,2018-07-24T07:11:11Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/52658,MERGED,2018-07-24T06:45:19Z,2018-07-25T02:29:42Z,Prefer `Option::map`/etc over `match` wherever it improves clarity,Wallacoloo,cbe5f1c4207673b9059e832ef2f134b4f87b380d,1,libsyntax_ext: Prefer `Option::map` over `match` where applicable,HEART,2018-07-24T07:23:45Z,kennytm,NA https://github.com/rust-lang/rust/pull/52658,MERGED,2018-07-24T06:45:19Z,2018-07-25T02:29:42Z,Prefer `Option::map`/etc over `match` wherever it improves clarity,Wallacoloo,cbe5f1c4207673b9059e832ef2f134b4f87b380d,1,libsyntax_ext: Prefer `Option::map` over `match` where applicable,HEART,2018-07-24T08:03:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52658,MERGED,2018-07-24T06:45:19Z,2018-07-25T02:29:42Z,Prefer `Option::map`/etc over `match` wherever it improves clarity,Wallacoloo,cbe5f1c4207673b9059e832ef2f134b4f87b380d,1,libsyntax_ext: Prefer `Option::map` over `match` where applicable,HEART,2018-07-24T10:02:14Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52672,CLOSED,2018-07-24T18:23:46Z,2018-07-27T21:31:32Z,Prefer sort_unstable*() over sort*(),ljedrz,NA,NA,NA,HEART,2018-07-27T19:58:22Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52678,MERGED,2018-07-24T20:44:04Z,2018-07-28T09:40:21Z,[NLL] Use better spans in some errors,matthewjasper,b32caef1ad605c8607ad0c3ccc682f6536f0e812,5,Use better spans for cannot-move errors,HEART,2018-07-24T23:47:28Z,estebank,NA https://github.com/rust-lang/rust/pull/52678,MERGED,2018-07-24T20:44:04Z,2018-07-28T09:40:21Z,[NLL] Use better spans in some errors,matthewjasper,b32caef1ad605c8607ad0c3ccc682f6536f0e812,5,Use better spans for cannot-move errors,HEART,2018-07-25T14:15:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-07-25T00:09:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-07-25T01:19:34Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-07-25T03:21:14Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-07-25T08:11:01Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-07-25T14:33:04Z,varkor,NA https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2018-08-29T09:35:21Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/52681,MERGED,2018-07-24T23:47:24Z,2018-07-27T11:02:35Z,Add `-Z borrowck=migrate`,pnkfelix,9f05f29e564c03a432df78f7c4b6421e4fb1a338,6,Incorporate edition flag testing into tests of `-Z borrowck=migrate`.,HOORAY,2022-06-13T21:30:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/52692,MERGED,2018-07-25T10:15:17Z,2018-07-26T19:51:35Z,Improve readability in a few sorts,ljedrz,f653bf4fba40c6415b6f580c30fbcfe2e82cce62,6,Improve readability in a few sorts,THUMBS_UP,2018-07-26T06:45:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52702,MERGED,2018-07-25T14:36:22Z,2018-07-28T11:37:58Z,Suggest fix when encountering different mutability from impl to trait,csmoe,d5347ff9c909af1c977dbb064c10cecea084d9d7,3,Fix ui test,HEART,2018-07-27T18:12:41Z,estebank,NA https://github.com/rust-lang/rust/pull/52702,MERGED,2018-07-25T14:36:22Z,2018-07-28T11:37:58Z,Suggest fix when encountering different mutability from impl to trait,csmoe,d5347ff9c909af1c977dbb064c10cecea084d9d7,3,Fix ui test,THUMBS_UP,2018-08-02T05:58:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52703,MERGED,2018-07-25T14:43:46Z,2018-07-28T11:37:59Z,Improve a few vectors - calculate capacity or build from iterators,ljedrz,acd38f656ad20166f25f527530ddc32a523c9e97,6,Improve a few vectors - calculate capacity or build from iterators,HEART,2018-07-26T06:37:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-07-25T18:43:31Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-07-25T19:34:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-07-25T19:44:50Z,kennytm,NA https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-07-25T19:50:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-08-01T17:38:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2018-08-02T05:20:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52711,MERGED,2018-07-25T18:24:09Z,2018-07-28T16:37:34Z,Change ManuallyDrop to a lang item.,eddyb,4e6aea1a10a50fcde27b74edbd99db69bfae724e,1,uodate reference again to hopefully fix all link issues,HOORAY,2020-11-16T16:11:21Z,Folyd,NA https://github.com/rust-lang/rust/pull/52716,MERGED,2018-07-25T20:34:15Z,2018-08-15T05:09:56Z,Add lldb to the build,tromey,6e3a4f4dddec17dfcf76083276c69f5528c43b84,16,Add lldb to the build This optionally adds lldb (and clang which it needs) to the build. Because rust uses LLVM 7 and because clang 7 is not yet released a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.,HOORAY,2018-08-13T20:29:08Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/52716,MERGED,2018-07-25T20:34:15Z,2018-08-15T05:09:56Z,Add lldb to the build,tromey,6e3a4f4dddec17dfcf76083276c69f5528c43b84,16,Add lldb to the build This optionally adds lldb (and clang which it needs) to the build. Because rust uses LLVM 7 and because clang 7 is not yet released a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.,HOORAY,2018-08-14T08:22:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/52716,MERGED,2018-07-25T20:34:15Z,2018-08-15T05:09:56Z,Add lldb to the build,tromey,6e3a4f4dddec17dfcf76083276c69f5528c43b84,16,Add lldb to the build This optionally adds lldb (and clang which it needs) to the build. Because rust uses LLVM 7 and because clang 7 is not yet released a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.,HOORAY,2018-08-15T23:51:18Z,xilec,NA https://github.com/rust-lang/rust/pull/52716,MERGED,2018-07-25T20:34:15Z,2018-08-15T05:09:56Z,Add lldb to the build,tromey,6e3a4f4dddec17dfcf76083276c69f5528c43b84,16,Add lldb to the build This optionally adds lldb (and clang which it needs) to the build. Because rust uses LLVM 7 and because clang 7 is not yet released a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.,HOORAY,2018-08-17T14:52:28Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/52716,MERGED,2018-07-25T20:34:15Z,2018-08-15T05:09:56Z,Add lldb to the build,tromey,6e3a4f4dddec17dfcf76083276c69f5528c43b84,16,Add lldb to the build This optionally adds lldb (and clang which it needs) to the build. Because rust uses LLVM 7 and because clang 7 is not yet released a recent git master version of clang is used. The lldb that is used includes the Rust plugin. lldb is only built when asked for or when doing a nightly build on macOS. Only macOS is done for now due to difficulties with the Python dependency.,HOORAY,2018-10-17T12:45:38Z,raphaelcohn,raphael.cohn@stormmq.com https://github.com/rust-lang/rust/pull/52738,MERGED,2018-07-26T15:56:59Z,2018-07-29T23:48:17Z,Replace push loops with extend() where possible,ljedrz,59c8a279daf6912b99ba089ff6dafbfc3469831e,28,Replace push loops with collect() and extend() where possible,HEART,2018-07-27T19:44:52Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52738,MERGED,2018-07-26T15:56:59Z,2018-07-29T23:48:17Z,Replace push loops with extend() where possible,ljedrz,59c8a279daf6912b99ba089ff6dafbfc3469831e,28,Replace push loops with collect() and extend() where possible,THUMBS_UP,2018-07-28T20:59:45Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/52744,MERGED,2018-07-26T16:30:37Z,2018-07-28T18:41:54Z,make memrchr use align_offset,RalfJung,3bc59b5205410b229eb66236b4aafbb90487fa34,1,use slice::align_to,THUMBS_UP,2018-08-02T05:58:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52764,MERGED,2018-07-27T08:40:01Z,2018-07-29T08:26:52Z,Misc cleanups,sinkuu,e995a91a314da7df85f5471cbc621874b5d42b53,3,Better Option handling,THUMBS_UP,2018-07-27T09:22:58Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52765,MERGED,2018-07-27T08:54:06Z,2018-07-28T11:38:03Z,"Remove unused ""-Zenable_nonzeroing_move_hints"" flag",sinkuu,31709562766494d301d372cd7066743c6b79d4d4,2,Remove unused option flag,HEART,2018-07-27T22:53:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52767,MERGED,2018-07-27T09:15:50Z,2018-07-29T11:28:02Z,Prefer to_string() to format!(),ljedrz,57a5a9b05423c4f832cd9a3aaa7e06d55fab6efa,36,Prefer to_string() to format!(),THUMBS_UP,2018-07-27T12:01:28Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52767,MERGED,2018-07-27T09:15:50Z,2018-07-29T11:28:02Z,Prefer to_string() to format!(),ljedrz,57a5a9b05423c4f832cd9a3aaa7e06d55fab6efa,36,Prefer to_string() to format!(),HEART,2018-07-27T19:40:23Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52767,MERGED,2018-07-27T09:15:50Z,2018-07-29T11:28:02Z,Prefer to_string() to format!(),ljedrz,57a5a9b05423c4f832cd9a3aaa7e06d55fab6efa,36,Prefer to_string() to format!(),THUMBS_UP,2018-07-27T21:48:47Z,killercup,NA https://github.com/rust-lang/rust/pull/52767,MERGED,2018-07-27T09:15:50Z,2018-07-29T11:28:02Z,Prefer to_string() to format!(),ljedrz,57a5a9b05423c4f832cd9a3aaa7e06d55fab6efa,36,Prefer to_string() to format!(),THUMBS_UP,2018-07-28T20:54:31Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/52773,MERGED,2018-07-27T11:21:26Z,2018-08-09T21:18:03Z,Avoid unnecessary pattern matching against Option and Result,ljedrz,44d32d441342aac1eb802c4379aa4eb324c90679,16,Avoid unnecessary pattern matching against Option and Result,HEART,2018-07-27T19:39:28Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52773,MERGED,2018-07-27T11:21:26Z,2018-08-09T21:18:03Z,Avoid unnecessary pattern matching against Option and Result,ljedrz,44d32d441342aac1eb802c4379aa4eb324c90679,16,Avoid unnecessary pattern matching against Option and Result,THUMBS_UP,2018-07-28T20:51:54Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/52775,CLOSED,2018-07-27T12:22:49Z,2018-07-29T01:22:42Z,RFC 2008: Variants,davidtwco,NA,NA,NA,HOORAY,2018-07-27T16:44:14Z,Ralith,NA https://github.com/rust-lang/rust/pull/52775,CLOSED,2018-07-27T12:22:49Z,2018-07-29T01:22:42Z,RFC 2008: Variants,davidtwco,NA,NA,NA,HOORAY,2018-07-27T23:36:51Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/52775,CLOSED,2018-07-27T12:22:49Z,2018-07-29T01:22:42Z,RFC 2008: Variants,davidtwco,NA,NA,NA,HOORAY,2018-07-27T23:57:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52779,MERGED,2018-07-27T13:12:12Z,2018-07-28T11:38:05Z,revert accidental atty downgrade,RalfJung,a171ed2164cfce1301842495c509df01951b8282,1,revert accidental atty downgrade,THUMBS_UP,2018-07-27T17:18:56Z,lqd,NA https://github.com/rust-lang/rust/pull/52781,MERGED,2018-07-27T14:53:21Z,2018-07-28T11:38:06Z,Use a slice where a vector is not necessary,ljedrz,1cca4204357454dbf2e2b7f57f9f024631da209f,15,Use slices where a vector is not necessary,HEART,2018-07-27T19:37:19Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/52781,MERGED,2018-07-27T14:53:21Z,2018-07-28T11:38:06Z,Use a slice where a vector is not necessary,ljedrz,1cca4204357454dbf2e2b7f57f9f024631da209f,15,Use slices where a vector is not necessary,HEART,2018-07-27T23:56:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52781,MERGED,2018-07-27T14:53:21Z,2018-07-28T11:38:06Z,Use a slice where a vector is not necessary,ljedrz,1cca4204357454dbf2e2b7f57f9f024631da209f,15,Use slices where a vector is not necessary,HEART,2018-07-28T11:13:58Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52782,MERGED,2018-07-27T16:00:22Z,2018-08-02T21:39:24Z,[NLL] Dangly paths for box,pnkfelix,c02c00b8455d6ec6eff50ae94bebb4a424c95e02,1,Fix bug in test pointed out during review.,HEART,2018-07-27T20:57:51Z,estebank,NA https://github.com/rust-lang/rust/pull/52782,MERGED,2018-07-27T16:00:22Z,2018-08-02T21:39:24Z,[NLL] Dangly paths for box,pnkfelix,c02c00b8455d6ec6eff50ae94bebb4a424c95e02,1,Fix bug in test pointed out during review.,HEART,2018-07-31T06:45:26Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/52782,MERGED,2018-07-27T16:00:22Z,2018-08-02T21:39:24Z,[NLL] Dangly paths for box,pnkfelix,c02c00b8455d6ec6eff50ae94bebb4a424c95e02,1,Fix bug in test pointed out during review.,HEART,2018-08-09T19:22:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T19:07:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T19:19:27Z,est31,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T19:25:46Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-27T19:25:48Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T19:38:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T19:46:46Z,robatipoor,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-27T21:56:54Z,rrbutani,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T21:59:20Z,rrbutani,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-27T22:48:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-27T23:54:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-28T08:44:31Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-28T08:44:33Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-28T10:50:59Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-28T11:23:17Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-28T17:44:44Z,ingenieroariel,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-28T17:44:50Z,ingenieroariel,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-29T06:27:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-29T06:27:25Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-29T08:36:04Z,TheWaWaR,thewawar@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-29T23:56:03Z,diodesign,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-30T15:02:43Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-30T15:02:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-30T18:27:44Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-30T22:07:15Z,bradjc,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-07-31T06:25:40Z,levex,lev@boilerplate.co https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-07-31T14:53:27Z,jeffvandyke,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-01T09:00:17Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-03T19:36:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-04T00:28:50Z,nlinker,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-04T00:42:10Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T00:42:12Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T05:28:32Z,johnteee,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-04T05:28:33Z,johnteee,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T08:15:31Z,Viknet,viknetmsu@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T11:19:53Z,whitepoplars,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T12:06:29Z,Mijyuoon,mijyuoon@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-04T12:06:30Z,Mijyuoon,mijyuoon@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-04T17:47:40Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-06T03:20:48Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-08T08:15:10Z,light4,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-08T09:00:31Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-08T09:03:02Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-08T09:03:03Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-08T09:49:07Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-08T23:13:07Z,elahn,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-09T15:02:05Z,tux3,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-09T16:24:37Z,dsciarra,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-09T19:15:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-09T20:28:05Z,vimpostor,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-13T11:19:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-13T11:19:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-14T06:27:25Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-14T06:27:25Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-08-14T07:15:03Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-08-14T07:15:05Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-09-19T11:23:22Z,Hoblovski,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-09-19T13:04:48Z,wangrunji0408,wangrunji0408@163.com https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2018-12-22T19:21:28Z,nikileshsa,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2018-12-22T19:21:29Z,nikileshsa,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2020-11-13T03:08:53Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2020-11-13T03:08:54Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2021-07-14T16:37:03Z,forkachild,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HOORAY,2022-01-15T03:48:38Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/52787,MERGED,2018-07-27T18:45:38Z,2018-08-02T04:22:31Z,Enable RISCV,dvc94ch,d974dc9a7896cafe5daec28ab7dae19f14e2e971,1,[RISCV] Disable c extension and atomic_cas.,HEART,2022-01-15T03:48:38Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/52788,MERGED,2018-07-27T19:53:02Z,2018-08-10T00:14:58Z,Add help message for missing `IndexMut` impl ,LukasKalbertodt,24abef3689840ec2ad0bb6ccdbc7cbcfb3844a82,4,Add and update tests for `IndexMut` help message,THUMBS_UP,2018-08-17T08:49:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/52788,MERGED,2018-07-27T19:53:02Z,2018-08-10T00:14:58Z,Add help message for missing `IndexMut` impl ,LukasKalbertodt,24abef3689840ec2ad0bb6ccdbc7cbcfb3844a82,4,Add and update tests for `IndexMut` help message,THUMBS_UP,2018-08-17T09:05:02Z,Boiethios,NA https://github.com/rust-lang/rust/pull/52805,MERGED,2018-07-28T12:42:29Z,2018-07-30T08:25:53Z,Don't format!() string literals,ljedrz,421b2ba347a3a1afa41b91f4254f238c790fd73b,42,Don't format!() string literals,THUMBS_UP,2018-07-28T14:02:24Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/52805,MERGED,2018-07-28T12:42:29Z,2018-07-30T08:25:53Z,Don't format!() string literals,ljedrz,421b2ba347a3a1afa41b91f4254f238c790fd73b,42,Don't format!() string literals,THUMBS_UP,2018-08-08T01:13:52Z,estebank,NA https://github.com/rust-lang/rust/pull/52813,MERGED,2018-07-28T23:01:20Z,2018-09-21T01:16:12Z,Duration div mul extras,newpavlov,fd7565b076440829b86cc7bc5f2457bf42d43936,1,Added tracking issue fixed check 1.30 -> 1.31,THUMBS_UP,2018-09-27T18:57:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/52813,MERGED,2018-07-28T23:01:20Z,2018-09-21T01:16:12Z,Duration div mul extras,newpavlov,fd7565b076440829b86cc7bc5f2457bf42d43936,1,Added tracking issue fixed check 1.30 -> 1.31,THUMBS_UP,2019-08-10T00:57:30Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/52813,MERGED,2018-07-28T23:01:20Z,2018-09-21T01:16:12Z,Duration div mul extras,newpavlov,fd7565b076440829b86cc7bc5f2457bf42d43936,1,Added tracking issue fixed check 1.30 -> 1.31,THUMBS_UP,2019-09-26T21:54:17Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/52821,MERGED,2018-07-29T07:25:25Z,2018-08-01T10:42:40Z,pretty print for std::collections::vecdeque,fukatani,9845ee08867e3527b9e57c86b08d38d5a0db255a,1,fix coding style,THUMBS_UP,2018-07-29T10:09:21Z,teuron,NA https://github.com/rust-lang/rust/pull/52824,MERGED,2018-07-29T11:21:40Z,2018-08-01T10:42:41Z,Fix -Wpessimizing-move warnings in rustllvm/PassWrapper,varkor,9ccd7eef1eeda8d207f62dae0c32d35cad7fa826,1,Fix -Wpessimizing-move warnings in rustllvm/PassWrapper,THUMBS_UP,2018-07-29T14:35:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52825,MERGED,2018-07-29T11:43:22Z,2018-08-01T10:42:42Z,Make sure #47772 does not regress,RalfJung,fb7d8a12db2a561c7dcc2534714243793446c7c4,1,hopefully make test pass on windows,LAUGH,2018-07-29T14:36:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/52828,MERGED,2018-07-29T15:04:18Z,2018-07-30T03:14:48Z,Clear out rustdoc check builds if dependencies change,Mark-Simulacrum,d68176e1158d3f4c72c98ed8fee295ecfa189661,1,Clear out rustdoc check builds if dependencies change,HEART,2018-07-29T15:10:32Z,varkor,NA https://github.com/rust-lang/rust/pull/52830,MERGED,2018-07-29T17:17:40Z,2018-07-30T12:21:17Z,[NLL] Fix some things for bootstrap,matthewjasper,18d5f821480803811f3f7ef866ef0ef8ae9bf9c1,1,Change order of copy and borrow to avoid conflict Note that the first argument is `self as &mut dyn Delegate` so this isn't allowed with two-phase borrows.,THUMBS_UP,2018-07-30T17:54:55Z,lqd,NA https://github.com/rust-lang/rust/pull/52830,MERGED,2018-07-29T17:17:40Z,2018-07-30T12:21:17Z,[NLL] Fix some things for bootstrap,matthewjasper,18d5f821480803811f3f7ef866ef0ef8ae9bf9c1,1,Change order of copy and borrow to avoid conflict Note that the first argument is `self as &mut dyn Delegate` so this isn't allowed with two-phase borrows.,THUMBS_UP,2018-08-02T05:57:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52841,MERGED,2018-07-30T00:52:26Z,2018-08-02T23:43:26Z,resolve: Implement prelude search for macro paths implement tool attributes,petrochenkov,c3e54217e855a2492d9b707eb3fb7cdb6702d45a,42,resolve: Implement prelude search for macro paths resolve/expansion: Implement tool attributes,HOORAY,2018-07-30T06:53:57Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/52841,MERGED,2018-07-30T00:52:26Z,2018-08-02T23:43:26Z,resolve: Implement prelude search for macro paths implement tool attributes,petrochenkov,c3e54217e855a2492d9b707eb3fb7cdb6702d45a,42,resolve: Implement prelude search for macro paths resolve/expansion: Implement tool attributes,HEART,2018-07-30T09:08:02Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-07-30T05:01:30Z,estebank,NA https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-07-30T06:49:03Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-07-30T06:58:13Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-07-30T15:02:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-08-08T16:39:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2018-08-09T02:18:46Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HOORAY,2018-08-09T14:50:48Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HOORAY,2018-08-09T19:19:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52847,MERGED,2018-07-30T04:22:09Z,2018-08-02T06:29:49Z,Don't commit thread stack on Windows,upsuper,fc8bb9c42c998dc5e82347d53f318b28d91fc9e3,2,Don't commit thread stack on Windows,HEART,2019-01-16T07:26:30Z,yfdyh000,yfdyh000@gmail.com https://github.com/rust-lang/rust/pull/52851,MERGED,2018-07-30T10:08:03Z,2018-08-01T10:42:44Z,Make the tool_lints actually usable,flip1995,7b9388b7b5fcdbb2f7e7178dc0a533e3284184c5,1,Explain that the tool is responsible for unknown tool_lints,HOORAY,2018-07-30T10:39:07Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52859,MERGED,2018-07-30T13:17:22Z,2018-08-01T10:42:45Z,Use Vec::extend in SmallVec::extend when applicable,ljedrz,ca5264826430cb5dab7a3c61394e8e795bbbd851,1,Benchmarks for SmallVec,HOORAY,2018-07-30T22:15:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52859,MERGED,2018-07-30T13:17:22Z,2018-08-01T10:42:45Z,Use Vec::extend in SmallVec::extend when applicable,ljedrz,ca5264826430cb5dab7a3c61394e8e795bbbd851,1,Benchmarks for SmallVec,HOORAY,2018-08-10T07:01:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52872,MERGED,2018-07-30T18:51:10Z,2018-08-08T12:48:35Z,Make IpvXAddr::new const fns and the well known addresses associated constants,faern,c0041f4a17b587cf47f0ecc481afb29a4ae28716,1,Use repr(align(x)) for redox in6_addr,THUMBS_UP,2018-07-31T21:54:36Z,tmccombs,NA https://github.com/rust-lang/rust/pull/52872,MERGED,2018-07-30T18:51:10Z,2018-08-08T12:48:35Z,Make IpvXAddr::new const fns and the well known addresses associated constants,faern,c0041f4a17b587cf47f0ecc481afb29a4ae28716,1,Use repr(align(x)) for redox in6_addr,THUMBS_UP,2018-08-16T05:27:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52876,MERGED,2018-07-30T20:13:49Z,2018-08-01T10:42:47Z,run-pass/const-endianness: negate before to_le(),cuviper,1ea2765918d1212a07e1359537470c477d82a681,1,run-pass/const-endianness: negate before to_le() `const LE_I128` needs parentheses to negate the value *before* calling `to_le()` otherwise it doesn't match the operations performed in the black-boxed part of the test. This only makes a tangible difference on big-endian targets.,LAUGH,2018-07-30T23:38:20Z,kennytm,NA https://github.com/rust-lang/rust/pull/52888,MERGED,2018-07-31T01:19:20Z,2018-08-01T10:42:49Z,Use suggestions for shell format arguments,estebank,75ff0ddb4349eca292016a29402980205c181d3f,4,Use suggestions for shell format arguments,HEART,2018-08-01T07:58:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/52915,MERGED,2018-07-31T20:05:57Z,2018-08-01T22:06:31Z,Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator,Zoxc,0babbf11e6b1b4aa95f30e01373d3f1488eca9c4,3,Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator,HOORAY,2018-07-31T20:37:05Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/52915,MERGED,2018-07-31T20:05:57Z,2018-08-01T22:06:31Z,Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator,Zoxc,0babbf11e6b1b4aa95f30e01373d3f1488eca9c4,3,Don't count MIR locals as borrowed after StorageDead when finding locals live across a yield terminator,HOORAY,2018-07-31T23:57:24Z,nwoeanhinnogaehr,NA https://github.com/rust-lang/rust/pull/52923,MERGED,2018-07-31T22:18:08Z,2018-08-14T06:31:21Z,#[feature(uniform_paths)]: allow `use x::y;` to resolve through `self::x` not just `::x`.,eddyb,13bc0b5a48aff52e828b6b645b166ccfa56e7681,4,rustc_resolve: also inject canaries to detect block scopes shadowing `uniform_paths` imports.,HOORAY,2018-08-14T06:39:44Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/52923,MERGED,2018-07-31T22:18:08Z,2018-08-14T06:31:21Z,#[feature(uniform_paths)]: allow `use x::y;` to resolve through `self::x` not just `::x`.,eddyb,13bc0b5a48aff52e828b6b645b166ccfa56e7681,4,rustc_resolve: also inject canaries to detect block scopes shadowing `uniform_paths` imports.,THUMBS_UP,2018-08-14T06:39:45Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/52923,MERGED,2018-07-31T22:18:08Z,2018-08-14T06:31:21Z,#[feature(uniform_paths)]: allow `use x::y;` to resolve through `self::x` not just `::x`.,eddyb,13bc0b5a48aff52e828b6b645b166ccfa56e7681,4,rustc_resolve: also inject canaries to detect block scopes shadowing `uniform_paths` imports.,THUMBS_UP,2018-08-22T17:01:16Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/52923,MERGED,2018-07-31T22:18:08Z,2018-08-14T06:31:21Z,#[feature(uniform_paths)]: allow `use x::y;` to resolve through `self::x` not just `::x`.,eddyb,13bc0b5a48aff52e828b6b645b166ccfa56e7681,4,rustc_resolve: also inject canaries to detect block scopes shadowing `uniform_paths` imports.,HOORAY,2018-08-22T17:50:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52928,MERGED,2018-08-01T00:41:45Z,2018-08-15T02:52:16Z,(old) borrowck cleanup,Mark-Simulacrum,8592039b8c5ebe4d64533bb5138ddad784567225,6,Remove dead code,HOORAY,2018-08-04T03:27:38Z,estebank,NA https://github.com/rust-lang/rust/pull/52940,MERGED,2018-08-01T10:08:31Z,2018-08-04T18:22:41Z,Align 6-week cycle check with beta promotion instead of stable release.,kennytm,0da7da8391cfb27a809b3fea7e0f50dd64d018c8,1,Align 6-week cycle check with beta promotion instead of stable release. The regression check is to make beta promotion easier so it makes more sense to use the Tuesday of the release week (T-2) as the end point of the regression prevention instead of Thursday (T-0). But since the beta promotion PR is sent at Tuesday evening at UTC the protection should include the whole Tuesday as well meaning the 6-week cycle will start from Wednesdays. This will also move the start of the regression protection week one day earlier.,THUMBS_UP,2018-08-01T14:33:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/52942,MERGED,2018-08-01T11:03:26Z,2018-08-01T22:06:34Z,Another SmallVec.extend optimization,llogiq,e462c06a280e4198b404323d7754e1308817b22e,1,Another SmallVec.extend optimization This improves SmallVec.extend even more over #52859 Before (as of #52859): ``` test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10) ``` After: ``` test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2) ```,HEART,2018-08-01T11:56:29Z,ljedrz,NA https://github.com/rust-lang/rust/pull/52942,MERGED,2018-08-01T11:03:26Z,2018-08-01T22:06:34Z,Another SmallVec.extend optimization,llogiq,e462c06a280e4198b404323d7754e1308817b22e,1,Another SmallVec.extend optimization This improves SmallVec.extend even more over #52859 Before (as of #52859): ``` test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10) ``` After: ``` test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2) ```,HEART,2018-08-01T17:58:04Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/52942,MERGED,2018-08-01T11:03:26Z,2018-08-01T22:06:34Z,Another SmallVec.extend optimization,llogiq,e462c06a280e4198b404323d7754e1308817b22e,1,Another SmallVec.extend optimization This improves SmallVec.extend even more over #52859 Before (as of #52859): ``` test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10) ``` After: ``` test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2) ```,HEART,2018-08-03T23:51:07Z,killercup,NA https://github.com/rust-lang/rust/pull/52942,MERGED,2018-08-01T11:03:26Z,2018-08-01T22:06:34Z,Another SmallVec.extend optimization,llogiq,e462c06a280e4198b404323d7754e1308817b22e,1,Another SmallVec.extend optimization This improves SmallVec.extend even more over #52859 Before (as of #52859): ``` test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10) ``` After: ``` test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2) ```,HEART,2018-08-04T03:01:12Z,estebank,NA https://github.com/rust-lang/rust/pull/52942,MERGED,2018-08-01T11:03:26Z,2018-08-01T22:06:34Z,Another SmallVec.extend optimization,llogiq,e462c06a280e4198b404323d7754e1308817b22e,1,Another SmallVec.extend optimization This improves SmallVec.extend even more over #52859 Before (as of #52859): ``` test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10) ``` After: ``` test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3) test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2) test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4) test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0) test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15) test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2) ```,HEART,2018-08-08T10:35:21Z,mati865,NA https://github.com/rust-lang/rust/pull/52952,CLOSED,2018-08-01T16:44:34Z,2018-08-06T16:43:51Z,Update LLVM submodule,cramertj,NA,NA,NA,HOORAY,2018-08-01T16:51:54Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/52952,CLOSED,2018-08-01T16:44:34Z,2018-08-06T16:43:51Z,Update LLVM submodule,cramertj,NA,NA,NA,HOORAY,2018-08-02T00:51:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/52954,MERGED,2018-08-01T16:50:55Z,2018-08-01T22:06:36Z,async can begin expressions,cramertj,f685142f8610e702843544f9ec5c5a742e5a85a7,2,async can begin expressions,HEART,2018-08-01T17:27:09Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/52954,MERGED,2018-08-01T16:50:55Z,2018-08-01T22:06:36Z,async can begin expressions,cramertj,f685142f8610e702843544f9ec5c5a742e5a85a7,2,async can begin expressions,HOORAY,2018-08-08T09:44:59Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/52954,MERGED,2018-08-01T16:50:55Z,2018-08-01T22:06:36Z,async can begin expressions,cramertj,f685142f8610e702843544f9ec5c5a742e5a85a7,2,async can begin expressions,HOORAY,2018-08-09T19:18:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52959,MERGED,2018-08-01T20:57:36Z,2018-08-05T11:28:16Z,[NLL] Use smaller spans for errors involving closure captures,matthewjasper,12af36a5c4638755be622c220efadffb1864f2ab,22,Update tests for new spans for nll errors involving closures,HOORAY,2018-08-01T21:00:44Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/52959,MERGED,2018-08-01T20:57:36Z,2018-08-05T11:28:16Z,[NLL] Use smaller spans for errors involving closure captures,matthewjasper,12af36a5c4638755be622c220efadffb1864f2ab,22,Update tests for new spans for nll errors involving closures,HOORAY,2018-08-02T06:35:06Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/52959,MERGED,2018-08-01T20:57:36Z,2018-08-05T11:28:16Z,[NLL] Use smaller spans for errors involving closure captures,matthewjasper,12af36a5c4638755be622c220efadffb1864f2ab,22,Update tests for new spans for nll errors involving closures,HOORAY,2018-08-04T03:23:58Z,estebank,NA https://github.com/rust-lang/rust/pull/52968,MERGED,2018-08-02T04:12:24Z,2018-08-04T18:22:43Z,App-lint-cability,zackmdavis,6e63b0dbedd5d4617d95aee1a42b9345b180d27b,4,`Applicability`-ify librustc_lint Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's surprising that `cargo fix` (now shipping with Cargo itself!) doesn't fix very common lint warnings which is as good of a reminder as any that we should finish #50723.,HOORAY,2018-08-02T23:42:02Z,eminence,NA https://github.com/rust-lang/rust/pull/52968,MERGED,2018-08-02T04:12:24Z,2018-08-04T18:22:43Z,App-lint-cability,zackmdavis,6e63b0dbedd5d4617d95aee1a42b9345b180d27b,4,`Applicability`-ify librustc_lint Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's surprising that `cargo fix` (now shipping with Cargo itself!) doesn't fix very common lint warnings which is as good of a reminder as any that we should finish #50723.,HOORAY,2018-08-04T00:26:54Z,estebank,NA https://github.com/rust-lang/rust/pull/52968,MERGED,2018-08-02T04:12:24Z,2018-08-04T18:22:43Z,App-lint-cability,zackmdavis,6e63b0dbedd5d4617d95aee1a42b9345b180d27b,4,`Applicability`-ify librustc_lint Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's surprising that `cargo fix` (now shipping with Cargo itself!) doesn't fix very common lint warnings which is as good of a reminder as any that we should finish #50723.,HOORAY,2018-08-10T04:06:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52982,CLOSED,2018-08-02T14:42:57Z,2018-08-30T01:40:09Z,Stabilize tool_attributes,mominul,NA,NA,NA,HOORAY,2018-08-02T15:15:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-02T18:27:00Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-02T21:39:15Z,mati865,NA https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-03T00:44:52Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-03T06:13:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-03T11:26:58Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-03T19:28:12Z,Nickforall,contact@nickvernij.nl https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-05T14:21:06Z,volodg,gorbenko.vova@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-06T05:29:23Z,rchaser53,tayoshizawa29@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-08T09:00:27Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-08T11:56:14Z,djc,NA https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-08T16:09:56Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-08T16:43:56Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-09T19:18:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-10T11:36:33Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/52983,MERGED,2018-08-02T15:00:50Z,2018-08-05T18:45:15Z,Update LLVM submodule to 7.0,alexcrichton,b0337a81bdda6958d20db1d9944968e505521cf9,4,Update LLVM submodule to 7.0 This commit updates the following submodules to LLVM's [recently branched][1] 7.0 release branch: * src/llvm * src/tools/lld * src/libcompiler_builtins/compiler-rt [1]: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125004.html Closes #52970,HEART,2018-08-11T16:28:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/52990,MERGED,2018-08-02T18:44:22Z,2018-08-06T16:24:03Z,Fix ICE when rustdoc encounters certain usages of HRTBs,Aaron1011,b010d1f9295821f2f37de76a84ea4e26620456dd,1,Tidy fixes,THUMBS_UP,2018-08-04T00:30:12Z,estebank,NA https://github.com/rust-lang/rust/pull/52990,MERGED,2018-08-02T18:44:22Z,2018-08-06T16:24:03Z,Fix ICE when rustdoc encounters certain usages of HRTBs,Aaron1011,b010d1f9295821f2f37de76a84ea4e26620456dd,1,Tidy fixes,HEART,2018-08-06T16:40:50Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/52990,MERGED,2018-08-02T18:44:22Z,2018-08-06T16:24:03Z,Fix ICE when rustdoc encounters certain usages of HRTBs,Aaron1011,b010d1f9295821f2f37de76a84ea4e26620456dd,1,Tidy fixes,HEART,2018-08-07T15:09:29Z,khaledkbadr,khaledkbadr@outlook.com https://github.com/rust-lang/rust/pull/52990,MERGED,2018-08-02T18:44:22Z,2018-08-06T16:24:03Z,Fix ICE when rustdoc encounters certain usages of HRTBs,Aaron1011,b010d1f9295821f2f37de76a84ea4e26620456dd,1,Tidy fixes,THUMBS_UP,2018-08-10T04:06:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/52993,MERGED,2018-08-02T19:44:21Z,2018-08-08T03:32:49Z,rustc: Tweak visibility of some lang items ,alexcrichton,7c58ab671fb49200c0cbd1ad9218713a5c3afe0d,9,rustc: Tweak visibility of some lang items This commit tweaks the linker-level visibility of some lang items that rustc uses and defines. Notably this means that `#[panic_implementation]` and `#[alloc_error_handler]` functions are never marked as `internal`. It's up to the linker to eliminate these not rustc. Additionally `#[global_allocator]` generated symbols are no longer forced to `Default` visibility (fully exported) but rather they're relaxed to `Hidden` visibility). This symbols are *not* needed across DLL boundaries only as a local implementation detail of the compiler-injected allocator symbols so `Hidden` should suffice. Closes #51342 Closes #52795,HEART,2018-08-02T19:50:51Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/52993,MERGED,2018-08-02T19:44:21Z,2018-08-08T03:32:49Z,rustc: Tweak visibility of some lang items ,alexcrichton,7c58ab671fb49200c0cbd1ad9218713a5c3afe0d,9,rustc: Tweak visibility of some lang items This commit tweaks the linker-level visibility of some lang items that rustc uses and defines. Notably this means that `#[panic_implementation]` and `#[alloc_error_handler]` functions are never marked as `internal`. It's up to the linker to eliminate these not rustc. Additionally `#[global_allocator]` generated symbols are no longer forced to `Default` visibility (fully exported) but rather they're relaxed to `Hidden` visibility). This symbols are *not* needed across DLL boundaries only as a local implementation detail of the compiler-injected allocator symbols so `Hidden` should suffice. Closes #51342 Closes #52795,HEART,2018-08-17T12:13:24Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/53003,MERGED,2018-08-02T22:02:14Z,2018-08-04T18:22:46Z,Stabilize --color and --error-format options in rustdoc,GuillaumeGomez,dda85abf099fc6f9f42ee270102117326d4b5184,1,Stabilize --color and --error-format options in rustdoc,THUMBS_UP,2018-08-03T11:42:26Z,kennytm,NA https://github.com/rust-lang/rust/pull/53016,MERGED,2018-08-03T07:16:36Z,2018-08-07T00:08:07Z,Extract impl_header_lifetime_elision out of in_band_lifetimes,scottmcm,1c7af279aac534d179021b473f2c1667c3442cf6,1,Remove in-band lifetimes from the 2018 edition As mentioned in the 2018-08-04 edition status update these are postponed as lacking consensus to stabilize.,THUMBS_UP,2018-08-03T10:02:59Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53016,MERGED,2018-08-03T07:16:36Z,2018-08-07T00:08:07Z,Extract impl_header_lifetime_elision out of in_band_lifetimes,scottmcm,1c7af279aac534d179021b473f2c1667c3442cf6,1,Remove in-band lifetimes from the 2018 edition As mentioned in the 2018-08-04 edition status update these are postponed as lacking consensus to stabilize.,THUMBS_UP,2018-08-03T16:45:58Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53016,MERGED,2018-08-03T07:16:36Z,2018-08-07T00:08:07Z,Extract impl_header_lifetime_elision out of in_band_lifetimes,scottmcm,1c7af279aac534d179021b473f2c1667c3442cf6,1,Remove in-band lifetimes from the 2018 edition As mentioned in the 2018-08-04 edition status update these are postponed as lacking consensus to stabilize.,HEART,2018-08-03T17:09:37Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/53022,MERGED,2018-08-03T10:16:40Z,2018-08-04T18:22:47Z,volatile operations docs: clarify that this does not help wrt. concurrency,RalfJung,71460d4d1144de2ddc4a088b81a30c6bc47dee59,1,volatile operations docs: clarify that this does not help wrt. concurrency,THUMBS_UP,2018-08-03T10:29:00Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53033,MERGED,2018-08-03T16:09:33Z,2018-08-14T10:42:04Z,unsized ManuallyDrop,RalfJung,5ee5a7eb5568011b29a9fee16b00e2b576603da3,1,repr(transparent),THUMBS_UP,2018-08-03T19:06:05Z,cramertj,NA https://github.com/rust-lang/rust/pull/53033,MERGED,2018-08-03T16:09:33Z,2018-08-14T10:42:04Z,unsized ManuallyDrop,RalfJung,5ee5a7eb5568011b29a9fee16b00e2b576603da3,1,repr(transparent),THUMBS_UP,2018-08-03T20:33:54Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/53033,MERGED,2018-08-03T16:09:33Z,2018-08-14T10:42:04Z,unsized ManuallyDrop,RalfJung,5ee5a7eb5568011b29a9fee16b00e2b576603da3,1,repr(transparent),THUMBS_UP,2018-08-05T04:34:23Z,qnighy,NA https://github.com/rust-lang/rust/pull/53033,MERGED,2018-08-03T16:09:33Z,2018-08-14T10:42:04Z,unsized ManuallyDrop,RalfJung,5ee5a7eb5568011b29a9fee16b00e2b576603da3,1,repr(transparent),THUMBS_UP,2018-08-05T10:35:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53033,MERGED,2018-08-03T16:09:33Z,2018-08-14T10:42:04Z,unsized ManuallyDrop,RalfJung,5ee5a7eb5568011b29a9fee16b00e2b576603da3,1,repr(transparent),HOORAY,2018-08-15T20:48:42Z,mikeyhew,NA https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,THUMBS_UP,2018-08-03T22:16:11Z,Keats,github@vincentprouillet.com https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,THUMBS_UP,2018-08-04T03:18:38Z,estebank,NA https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,HOORAY,2018-08-11T07:07:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,HOORAY,2018-08-22T08:07:05Z,sersorrel,ash@sorrel.sh https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,HOORAY,2018-08-22T16:18:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,THUMBS_UP,2018-08-22T16:18:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,HOORAY,2018-08-30T05:44:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53044,MERGED,2018-08-03T22:13:52Z,2018-08-24T17:02:28Z,Stabilize 'attr_literals' feature.,SergioBenitez,ed0bd38cac24d21b193561bb6813c8a9ae5de66c,28,Stabilize 'attr_literals' feature.,HOORAY,2018-11-03T12:04:28Z,hcpl,NA https://github.com/rust-lang/rust/pull/53047,MERGED,2018-08-03T22:35:30Z,2018-08-04T18:22:50Z,Make entire row of doc search results clickable,carols10cents,11ffeed1ed8bb1bb48b5655c3dcc61687835f548,1,Make entire row of doc search results clickable By adding empty `after` content that clears and is `display: block`. Technique found here: https://stackoverflow.com/a/7817313/51683 Now any part of a documentation search result that is highlighted when you hover over it should also be clickable.,HEART,2018-08-04T03:16:01Z,estebank,NA https://github.com/rust-lang/rust/pull/53049,CLOSED,2018-08-03T23:13:12Z,2018-08-04T06:33:37Z,Rollup of 14 pull requests,cramertj,NA,NA,NA,THUMBS_UP,2018-08-03T23:14:39Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/53050,MERGED,2018-08-04T00:47:32Z,2018-08-04T18:22:50Z,Make left column of rustdoc search results narrower,carols10cents,d5dd37b00ff52099bfed85f242500803beb0dbdf,1,Make left column of rustdoc search results narrower To make more room for the description of the item,THUMBS_UP,2018-08-04T06:31:02Z,kennytm,NA https://github.com/rust-lang/rust/pull/53051,MERGED,2018-08-04T01:22:28Z,2018-08-13T04:53:46Z,Emit error for pattern arguments in trait methods,varkor,5c814e2e4e0649972ec6a18c7dbf57259edf2210,6,Clean up and add extra tests,HEART,2018-08-05T21:06:25Z,estebank,NA https://github.com/rust-lang/rust/pull/53051,MERGED,2018-08-04T01:22:28Z,2018-08-13T04:53:46Z,Emit error for pattern arguments in trait methods,varkor,5c814e2e4e0649972ec6a18c7dbf57259edf2210,6,Clean up and add extra tests,HEART,2018-08-16T05:24:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53058,CLOSED,2018-08-04T11:55:16Z,2018-08-04T12:58:24Z,Split long literals with underscores,ljedrz,NA,NA,NA,LAUGH,2018-08-04T12:18:57Z,killercup,NA https://github.com/rust-lang/rust/pull/53074,CLOSED,2018-08-04T21:55:25Z,2018-08-06T00:18:21Z,[Do not merge] Allow generic parameters to be specified in expressions without `::`,varkor,NA,NA,NA,CONFUSED,2018-08-05T15:55:54Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2018-08-05T03:37:33Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2018-08-09T21:04:32Z,cramertj,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,HEART,2018-08-29T08:20:15Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2018-08-30T05:42:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,HEART,2018-09-12T19:04:50Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2018-09-18T13:56:26Z,EPashkin,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2018-10-28T00:57:05Z,hcpl,NA https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,THUMBS_UP,2019-09-14T18:46:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/53076,MERGED,2018-08-04T23:38:41Z,2018-09-01T18:08:41Z,set cfg(rustdoc) when rustdoc is running on a crate,QuietMisdreavus,ad2169c095b190afd76a5e32865410502a8bcfdd,7,use cfg(rustdoc) instead of cfg(dox) in std and friends,HEART,2020-12-25T03:44:43Z,zhangli-pear,NA https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-05T17:08:48Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-05T17:31:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-21T04:20:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-29T16:38:39Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-29T16:52:05Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53080,MERGED,2018-08-05T03:37:35Z,2018-08-21T08:46:01Z,Change `Rc::inc_{weak strong}` to better hint optimization to LLVM,dshynkev,79a905ef305b1c3048ad2535887951721ab65f5c,1,Added explicit optimization flag to test,HEART,2018-08-30T05:39:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53111,CLOSED,2018-08-06T12:17:13Z,2018-08-14T12:50:32Z,Speed up leb128 write functions add benchmarks,ljedrz,NA,NA,NA,HOORAY,2018-08-06T13:11:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53113,MERGED,2018-08-06T14:37:32Z,2018-08-31T05:56:52Z,Add example for Cow,kpp,5bfb7850782c440f27e0a5b64157aed9e04c5cc6,1,Review fix,THUMBS_UP,2018-08-08T00:52:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53124,MERGED,2018-08-06T19:15:56Z,2018-08-10T04:18:30Z,region error messages involving impls are confusing ,davidtwco,31657c99533f7c5dc44229c709a2ce6ad24908db,11,Updated tests after rebase.,HEART,2018-08-07T06:22:07Z,estebank,NA https://github.com/rust-lang/rust/pull/53161,MERGED,2018-08-07T15:07:00Z,2018-08-13T14:09:24Z,Avoid many allocations for CStrings during codegen.,michaelwoerister,88d84b38f19eff3c25ec88931f04bf2640edf2b5,13,Introduce SmallCStr and use it where applicable.,THUMBS_UP,2018-08-13T18:42:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53161,MERGED,2018-08-07T15:07:00Z,2018-08-13T14:09:24Z,Avoid many allocations for CStrings during codegen.,michaelwoerister,88d84b38f19eff3c25ec88931f04bf2640edf2b5,13,Introduce SmallCStr and use it where applicable.,THUMBS_UP,2018-08-17T13:04:18Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/53162,MERGED,2018-08-07T15:25:45Z,2018-09-20T17:25:12Z,rustdoc: collect trait impls as an early pass,QuietMisdreavus,110657711605c439b0f175a8ba674c89f9d86e81,4,fix intra-links for trait impls,THUMBS_UP,2018-08-07T16:08:10Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53165,MERGED,2018-08-07T17:07:21Z,2018-08-13T00:21:18Z, Add aarch64-unknown-netbsd target,jakllsch,538d1ba6d7e300ddd4d6d1ca3a84363b8eff5767,1,aarch64-unknown-netbsd: add openssl configuration,THUMBS_UP,2018-08-10T06:24:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53168,CLOSED,2018-08-07T18:54:16Z,2018-08-08T10:23:21Z,avoid computing liveness when possible,nikomatsakis,NA,NA,NA,HOORAY,2018-08-07T19:35:09Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/53168,CLOSED,2018-08-07T18:54:16Z,2018-08-08T10:23:21Z,avoid computing liveness when possible,nikomatsakis,NA,NA,NA,HOORAY,2018-08-07T19:57:53Z,est31,NA https://github.com/rust-lang/rust/pull/53168,CLOSED,2018-08-07T18:54:16Z,2018-08-08T10:23:21Z,avoid computing liveness when possible,nikomatsakis,NA,NA,NA,HOORAY,2018-08-07T22:32:34Z,lqd,NA https://github.com/rust-lang/rust/pull/53173,MERGED,2018-08-07T20:23:54Z,2018-08-16T13:29:52Z,Start adding an `aarch64-pc-windows-msvc` target,alexcrichton,fccc04d3e72bb462cba1b492ba0e2cd4ab2aebec,8,Start adding an `aarch64-pc-windows-msvc` target This commit adds the necessary definitions for target specs and such as well as the necessary support in libstd to compile basic `aarch64-pc-windows-msvc` binaries. The target is not currently built on CI but it can be built locally with: ./configure --target=aarch64-pc-windows-msvc --set rust.lld ./x.py build src/libstd --target aarch64-pc-windows-msvc Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?) which hasn't been investigate yet. Otherwise though with libstd you can build a hello world program (linked with LLD). I've not tried to execute it yet but it at least links! Full support for this target is still a long road ahead but this is hopefully a good stepping stone to get started. Points of note about this target are: * Currently defaults to `panic=abort` as support is still landing in LLVM for SEH on AArch64. * Currently defaults to LLD as a linker as I was able to get farther with it than I was with `link.exe`,HOORAY,2018-08-07T20:27:17Z,froydnj,froydnj@gmail.com https://github.com/rust-lang/rust/pull/53173,MERGED,2018-08-07T20:23:54Z,2018-08-16T13:29:52Z,Start adding an `aarch64-pc-windows-msvc` target,alexcrichton,fccc04d3e72bb462cba1b492ba0e2cd4ab2aebec,8,Start adding an `aarch64-pc-windows-msvc` target This commit adds the necessary definitions for target specs and such as well as the necessary support in libstd to compile basic `aarch64-pc-windows-msvc` binaries. The target is not currently built on CI but it can be built locally with: ./configure --target=aarch64-pc-windows-msvc --set rust.lld ./x.py build src/libstd --target aarch64-pc-windows-msvc Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?) which hasn't been investigate yet. Otherwise though with libstd you can build a hello world program (linked with LLD). I've not tried to execute it yet but it at least links! Full support for this target is still a long road ahead but this is hopefully a good stepping stone to get started. Points of note about this target are: * Currently defaults to `panic=abort` as support is still landing in LLVM for SEH on AArch64. * Currently defaults to LLD as a linker as I was able to get farther with it than I was with `link.exe`,HOORAY,2018-08-07T21:03:14Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53173,MERGED,2018-08-07T20:23:54Z,2018-08-16T13:29:52Z,Start adding an `aarch64-pc-windows-msvc` target,alexcrichton,fccc04d3e72bb462cba1b492ba0e2cd4ab2aebec,8,Start adding an `aarch64-pc-windows-msvc` target This commit adds the necessary definitions for target specs and such as well as the necessary support in libstd to compile basic `aarch64-pc-windows-msvc` binaries. The target is not currently built on CI but it can be built locally with: ./configure --target=aarch64-pc-windows-msvc --set rust.lld ./x.py build src/libstd --target aarch64-pc-windows-msvc Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?) which hasn't been investigate yet. Otherwise though with libstd you can build a hello world program (linked with LLD). I've not tried to execute it yet but it at least links! Full support for this target is still a long road ahead but this is hopefully a good stepping stone to get started. Points of note about this target are: * Currently defaults to `panic=abort` as support is still landing in LLVM for SEH on AArch64. * Currently defaults to LLD as a linker as I was able to get farther with it than I was with `link.exe`,HOORAY,2018-08-08T00:50:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53175,MERGED,2018-08-07T21:25:12Z,2018-08-18T14:35:49Z,[NLL] Returns are interesting for free regions,matthewjasper,a19db49c863f28103a3ae64423b88574ccf700ff,46,Update former compile-fail tests,THUMBS_UP,2018-08-17T11:23:12Z,lqd,NA https://github.com/rust-lang/rust/pull/53177,MERGED,2018-08-07T22:04:44Z,2018-08-10T22:06:06Z,optimize redundant borrows and escaping paths in NLL ,nikomatsakis,ff7f6d57de1112805272bae57ff5918d4f25e0ab,2,don't walk MIR if no local variables need liveness This is true for tuple-stress and html5ever,HOORAY,2018-08-11T07:29:59Z,lqd,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T07:05:44Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T07:09:20Z,sYnfo,matej.stuchlik@gmail.com https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T09:33:05Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T09:47:26Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T12:19:09Z,varkor,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T14:32:47Z,robertDurst,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T15:08:05Z,OGFris,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T15:52:40Z,kujon,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-08T21:46:33Z,thisaurel,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-09T08:39:03Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-09T13:15:39Z,patrick91,patrick.arminio@gmail.com https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-14T23:44:12Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-15T10:46:42Z,jplatte,NA https://github.com/rust-lang/rust/pull/53183,MERGED,2018-08-08T05:34:00Z,2018-08-09T21:18:14Z,Suggest comma when missing in macro call,estebank,f4039affa338fc5640c102ac5786a491bc94201f,4,Suggest comma when missing in macro call When missing a comma in a macro call suggest it regardless of position. When a macro call doesn't match any of the patterns check if the call's token stream could be missing a comma between two idents and if so create a new token stream containing the comma and try to match against the macro patterns. If successful emit the suggestion.,HEART,2018-08-16T05:24:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53190,MERGED,2018-08-08T11:02:12Z,2018-08-17T13:03:44Z,Add crate build test for `thumb*` targets. [IRR-2018-embedded],sekineh,ad78c2fc55b09624846c12f407b39852fbf573e6,1,add copyright from template,HOORAY,2018-08-17T16:07:16Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/53190,MERGED,2018-08-08T11:02:12Z,2018-08-17T13:03:44Z,Add crate build test for `thumb*` targets. [IRR-2018-embedded],sekineh,ad78c2fc55b09624846c12f407b39852fbf573e6,1,add copyright from template,HEART,2018-11-14T15:21:06Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HEART,2018-08-08T15:34:58Z,varkor,NA https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HOORAY,2018-08-08T17:45:34Z,lqd,NA https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HOORAY,2018-08-14T09:28:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HOORAY,2018-08-14T16:34:35Z,estebank,NA https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HOORAY,2018-08-14T20:14:23Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/53196,MERGED,2018-08-08T14:47:50Z,2018-08-14T15:09:57Z,Move `compile-fail` tests to `ui` ,davidtwco,7b026568f7bf36540fdc7db44dd8e37bb62ad233,2,Moved problematic tests on x86_64-gnu-nopt back to compile-fail.,HOORAY,2018-08-14T23:35:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53199,MERGED,2018-08-08T16:22:19Z,2018-08-09T19:05:11Z,[beta] Update the clippy submodule,oli-obk,22a4ef1e37457cacfcdb7702f2bc1874587899b1,1,Add some missing winapi features,LAUGH,2018-08-09T10:50:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53213,MERGED,2018-08-09T07:54:30Z,2018-08-21T18:16:24Z,Stabilize IP associated constants,tmccombs,e6244e597978bb3c73c3b222a860a033dea6acf4,1,Stabilize IP associated constants Fixes #44582,HOORAY,2018-08-09T08:58:50Z,faern,NA https://github.com/rust-lang/rust/pull/53225,MERGED,2018-08-09T16:04:38Z,2018-08-25T00:50:33Z,MIR: support user-given type annotations on fns structs and enums,nikomatsakis,ed73a3267a648cffb92f60e50aa75a6547d9955d,7,address pnkfelix nits,THUMBS_UP,2018-08-09T16:14:04Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/53225,MERGED,2018-08-09T16:04:38Z,2018-08-25T00:50:33Z,MIR: support user-given type annotations on fns structs and enums,nikomatsakis,ed73a3267a648cffb92f60e50aa75a6547d9955d,7,address pnkfelix nits,THUMBS_UP,2018-08-09T17:44:50Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/53225,MERGED,2018-08-09T16:04:38Z,2018-08-25T00:50:33Z,MIR: support user-given type annotations on fns structs and enums,nikomatsakis,ed73a3267a648cffb92f60e50aa75a6547d9955d,7,address pnkfelix nits,THUMBS_UP,2018-08-09T18:19:01Z,lqd,NA https://github.com/rust-lang/rust/pull/53225,MERGED,2018-08-09T16:04:38Z,2018-08-25T00:50:33Z,MIR: support user-given type annotations on fns structs and enums,nikomatsakis,ed73a3267a648cffb92f60e50aa75a6547d9955d,7,address pnkfelix nits,THUMBS_UP,2018-08-12T11:45:39Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/53233,MERGED,2018-08-09T20:11:21Z,2018-08-14T19:39:02Z,targets: aarch64: Add bare-metal aarch64 target,andre-richter,898950caf1a7bc9b6c41e74bbfac9591724f307c,2,targets: aarch64: Add bare-metal aarch64 target A generic AArch64 target that can be used for writing bare-metal code for 64-bit ARM architectures.,THUMBS_UP,2018-08-10T04:06:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53233,MERGED,2018-08-09T20:11:21Z,2018-08-14T19:39:02Z,targets: aarch64: Add bare-metal aarch64 target,andre-richter,898950caf1a7bc9b6c41e74bbfac9591724f307c,2,targets: aarch64: Add bare-metal aarch64 target A generic AArch64 target that can be used for writing bare-metal code for 64-bit ARM architectures.,THUMBS_UP,2018-08-10T06:21:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53233,MERGED,2018-08-09T20:11:21Z,2018-08-14T19:39:02Z,targets: aarch64: Add bare-metal aarch64 target,andre-richter,898950caf1a7bc9b6c41e74bbfac9591724f307c,2,targets: aarch64: Add bare-metal aarch64 target A generic AArch64 target that can be used for writing bare-metal code for 64-bit ARM architectures.,THUMBS_UP,2018-08-22T17:20:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53233,MERGED,2018-08-09T20:11:21Z,2018-08-14T19:39:02Z,targets: aarch64: Add bare-metal aarch64 target,andre-richter,898950caf1a7bc9b6c41e74bbfac9591724f307c,2,targets: aarch64: Add bare-metal aarch64 target A generic AArch64 target that can be used for writing bare-metal code for 64-bit ARM architectures.,THUMBS_UP,2018-08-23T12:34:43Z,singulared,NA https://github.com/rust-lang/rust/pull/53236,MERGED,2018-08-09T20:59:08Z,2018-08-21T16:04:24Z,Stabilise raw_identifiers feature,alexreg,e221fcce66ed8fd9e7c89988596d28e768193f98,30,Removed `raw_identifiers` feature gate.,HEART,2018-08-09T21:02:21Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53236,MERGED,2018-08-09T20:59:08Z,2018-08-21T16:04:24Z,Stabilise raw_identifiers feature,alexreg,e221fcce66ed8fd9e7c89988596d28e768193f98,30,Removed `raw_identifiers` feature gate.,HEART,2018-08-09T21:30:17Z,Havvy,NA https://github.com/rust-lang/rust/pull/53236,MERGED,2018-08-09T20:59:08Z,2018-08-21T16:04:24Z,Stabilise raw_identifiers feature,alexreg,e221fcce66ed8fd9e7c89988596d28e768193f98,30,Removed `raw_identifiers` feature gate.,HEART,2018-08-09T21:31:24Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/53236,MERGED,2018-08-09T20:59:08Z,2018-08-21T16:04:24Z,Stabilise raw_identifiers feature,alexreg,e221fcce66ed8fd9e7c89988596d28e768193f98,30,Removed `raw_identifiers` feature gate.,HEART,2018-08-13T04:21:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53236,MERGED,2018-08-09T20:59:08Z,2018-08-21T16:04:24Z,Stabilise raw_identifiers feature,alexreg,e221fcce66ed8fd9e7c89988596d28e768193f98,30,Removed `raw_identifiers` feature gate.,HEART,2018-10-31T05:54:01Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/53237,MERGED,2018-08-09T21:30:18Z,2018-08-15T17:03:53Z,Export WASM table by default,overdrivenpotato,c7a39b190ea4f5ac6fcdbe4f40188c2a617d88d6,1,Export WASM table by default,THUMBS_UP,2018-08-10T22:02:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53238,MERGED,2018-08-09T22:11:01Z,2018-08-13T09:15:42Z,Update RLS,nrc,4076dc46ae4277953b1310d037b0255802146a86,2,Update RLS,HOORAY,2018-08-11T13:51:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53245,MERGED,2018-08-10T10:31:26Z,2018-08-29T13:35:32Z,[experimental]: Build LLVM with ThinLTO enabled (2nd attempt),michaelwoerister,3cf6f0db1ab61ed33c585b156a0d5c41279f0810,3,bootstrap: Link LLVM tools dynamically in order to save time in ThinLTO builds.,THUMBS_UP,2018-08-11T04:29:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53247,CLOSED,2018-08-10T13:12:06Z,2018-09-24T12:37:16Z,[nll] change how MIR represents places,csmoe,NA,NA,NA,THUMBS_UP,2018-08-11T04:30:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53255,MERGED,2018-08-10T17:52:43Z,2018-09-30T22:20:18Z,Add a per-tree error cache to the obligation forest,orium,6bfa6aa87255cf8291333139ad2d383950b5a0f7,5,Deduplicate errors in the obligation forest. Fixes #40827.,HOORAY,2018-08-10T17:55:12Z,metabrain,NA https://github.com/rust-lang/rust/pull/53255,MERGED,2018-08-10T17:52:43Z,2018-09-30T22:20:18Z,Add a per-tree error cache to the obligation forest,orium,6bfa6aa87255cf8291333139ad2d383950b5a0f7,5,Deduplicate errors in the obligation forest. Fixes #40827.,HOORAY,2018-10-04T04:22:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,HOORAY,2018-08-11T07:28:43Z,lqd,NA https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,THUMBS_UP,2018-08-11T07:28:48Z,lqd,NA https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,HEART,2018-08-11T07:28:51Z,lqd,NA https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,THUMBS_UP,2018-08-13T15:19:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,HOORAY,2018-08-13T15:19:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,HEART,2018-08-13T15:19:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53258,MERGED,2018-08-10T22:08:25Z,2018-08-19T19:53:02Z,optimize reassignment immutable state,nikomatsakis,58e4b54bd49a2a554ee8a573827b9ccbf7a9b65e,16,move tests to borrowck directory remove feature(nll) now compare-mode can show us the differences,THUMBS_UP,2018-08-22T17:07:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53272,MERGED,2018-08-11T16:18:04Z,2018-08-28T03:12:51Z,Warn on anon params in 2015 edition,mark-i-m,548f28e194cd27937fb569afec3eb5bd87d6a90b,2,fix test stderrs,HEART,2018-08-11T16:36:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53272,MERGED,2018-08-11T16:18:04Z,2018-08-28T03:12:51Z,Warn on anon params in 2015 edition,mark-i-m,548f28e194cd27937fb569afec3eb5bd87d6a90b,2,fix test stderrs,HEART,2018-08-11T18:20:26Z,est31,NA https://github.com/rust-lang/rust/pull/53272,MERGED,2018-08-11T16:18:04Z,2018-08-28T03:12:51Z,Warn on anon params in 2015 edition,mark-i-m,548f28e194cd27937fb569afec3eb5bd87d6a90b,2,fix test stderrs,HEART,2018-08-14T02:28:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53272,MERGED,2018-08-11T16:18:04Z,2018-08-28T03:12:51Z,Warn on anon params in 2015 edition,mark-i-m,548f28e194cd27937fb569afec3eb5bd87d6a90b,2,fix test stderrs,HEART,2018-08-14T03:52:32Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/53273,MERGED,2018-08-11T18:12:14Z,2018-08-13T00:21:28Z,Add links to std::char::REPLACEMENT_CHARACTER from docs.,frewsxcv,ec18991492849393a8b3ae4e0c70a22319e8ea60,6,Add links to std::char::REPLACEMENT_CHARACTER from docs. There are a few places where we mention the replacement character in the docs and it could be helpful for users to utilize the constant which is available in the standard library so let’s link to it!,THUMBS_UP,2018-08-11T20:31:19Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/53274,MERGED,2018-08-11T18:59:44Z,2018-08-14T19:39:06Z,Remove statics field from CodegenCx,bjorn3,44af0683883b0c1ce2a4d5f360cc9f50062dc9d1,3,Remove statics field from CodegenCx,HEART,2018-08-13T08:04:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53289,MERGED,2018-08-12T17:34:51Z,2018-08-16T03:15:29Z,A few cleanups and minor improvements for the lexer,ljedrz,40d9bd014707ae82972509f5da9b7478eb2a9709,4,A few cleanups and minor improvements for the lexer,THUMBS_UP,2018-08-12T17:47:51Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,THUMBS_UP,2018-08-12T18:29:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,HOORAY,2018-08-12T18:56:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,THUMBS_UP,2018-08-12T18:56:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,HOORAY,2018-08-14T19:57:04Z,tdaede,daede003@umn.edu https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,THUMBS_UP,2018-08-22T07:38:27Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,THUMBS_UP,2018-08-22T17:52:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53290,MERGED,2018-08-12T18:03:03Z,2018-08-14T19:39:07Z,Make LLVM emit assembly comments with -Z asm-comments,whitequark,66fd1ebfae2fff815f27bf2be19469f40dd99c88,3,Make LLVM emit assembly comments with -Z asm-comments. Fixes #35741.,THUMBS_UP,2018-08-24T02:26:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/53299,MERGED,2018-08-13T01:00:27Z,2018-09-07T15:14:56Z,Updated core/macros.rs to note it works in a no_std environment.,MagnumOpus21,9d440d578d3ec724cae93d9fac3a2701724e780a,1,Spacing changes made to the example,HEART,2018-09-09T02:22:49Z,behnam,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-13T05:39:39Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-13T06:11:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-13T07:37:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-13T18:31:43Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-14T03:53:00Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-16T16:48:36Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-17T07:48:42Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T03:59:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T07:14:58Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-22T07:15:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-22T11:46:16Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-22T15:40:04Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T15:40:05Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T16:51:16Z,MarkSwanson,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-22T17:10:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-22T17:36:50Z,StefanoD,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T17:36:51Z,StefanoD,NA https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-08-22T18:04:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HOORAY,2018-08-27T01:15:58Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-09-12T19:17:38Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/53304,MERGED,2018-08-13T05:20:23Z,2018-08-16T17:53:42Z,TokenStream::extend,dtolnay,69b9c23b3858dc87ceb6629b7640d5f579b8ed79,1,Address review of RcVec,HEART,2018-10-29T00:40:56Z,hcpl,NA https://github.com/rust-lang/rust/pull/53314,MERGED,2018-08-13T21:31:53Z,2018-08-28T13:12:32Z,NLL: experiment with inverting liveness ,nikomatsakis,8d231ec872aa7ede20faf70e988ebfbded351b53,1,Fix definition of `LocalUseMapBuild` so that it can build under stage0 which does not have as many feature gates enabled.,HOORAY,2018-08-14T12:33:10Z,lqd,NA https://github.com/rust-lang/rust/pull/53314,MERGED,2018-08-13T21:31:53Z,2018-08-28T13:12:32Z,NLL: experiment with inverting liveness ,nikomatsakis,8d231ec872aa7ede20faf70e988ebfbded351b53,1,Fix definition of `LocalUseMapBuild` so that it can build under stage0 which does not have as many feature gates enabled.,HOORAY,2018-09-05T07:51:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53323,CLOSED,2018-08-14T01:48:19Z,2018-08-15T04:15:47Z,Sort reported 'similar impl candidates' alphabetically,BurntPizza,NA,NA,NA,HEART,2018-08-14T01:58:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53323,CLOSED,2018-08-14T01:48:19Z,2018-08-15T04:15:47Z,Sort reported 'similar impl candidates' alphabetically,BurntPizza,NA,NA,NA,HEART,2018-08-14T02:38:02Z,estebank,NA https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,HEART,2018-08-14T03:24:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,HEART,2018-08-15T01:45:02Z,estebank,NA https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,HEART,2018-08-22T08:06:23Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,THUMBS_UP,2018-08-22T08:33:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,HEART,2018-08-22T18:00:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53324,MERGED,2018-08-14T01:53:25Z,2018-08-18T21:58:42Z,`Self` in type definitions (self_in_typedefs),alexreg,4e7d3f5a5eb9db95194cbb672f081c2ad9647674,2,Added page for feature to unstable book.,THUMBS_UP,2018-08-29T08:49:29Z,sanpii,NA https://github.com/rust-lang/rust/pull/53327,MERGED,2018-08-14T03:22:07Z,2018-09-07T20:25:10Z,[nll] teach SCC about `'static` ,wesleywiser,b1211e870370cac1000a64c48ceb8a2ad6dc1f45,31,Fix tests,THUMBS_UP,2018-08-20T18:06:49Z,lqd,NA https://github.com/rust-lang/rust/pull/53327,MERGED,2018-08-14T03:22:07Z,2018-09-07T20:25:10Z,[nll] teach SCC about `'static` ,wesleywiser,b1211e870370cac1000a64c48ceb8a2ad6dc1f45,31,Fix tests,THUMBS_UP,2018-08-23T19:32:04Z,estebank,NA https://github.com/rust-lang/rust/pull/53327,MERGED,2018-08-14T03:22:07Z,2018-09-07T20:25:10Z,[nll] teach SCC about `'static` ,wesleywiser,b1211e870370cac1000a64c48ceb8a2ad6dc1f45,31,Fix tests,THUMBS_UP,2018-09-13T16:06:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53329,MERGED,2018-08-14T04:24:21Z,2018-08-21T18:16:27Z,Replace usages of ptr::offset with ptr::{add sub}.,frewsxcv,993fb934640b7e514f3c629c33a2698a83ed8c3e,29,Replace usages of ptr::offset with ptr::{add sub}.,THUMBS_UP,2018-08-14T08:39:23Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/53329,MERGED,2018-08-14T04:24:21Z,2018-08-21T18:16:27Z,Replace usages of ptr::offset with ptr::{add sub}.,frewsxcv,993fb934640b7e514f3c629c33a2698a83ed8c3e,29,Replace usages of ptr::offset with ptr::{add sub}.,THUMBS_UP,2018-08-20T02:25:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53347,MERGED,2018-08-14T13:54:17Z,2018-08-17T19:10:50Z,rustc_resolve: don't allow paths starting with `::crate`.,eddyb,9b1d3c70ac5e16fd43daf0b56c739c6bd5ded3fd,16,rustc_resolve: don't allow paths starting with `::crate`.,THUMBS_UP,2018-08-14T17:24:40Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/53376,MERGED,2018-08-15T03:32:03Z,2018-09-07T15:14:57Z,Cross reference io::copy and fs::copy in docs.,frewsxcv,5f198a5e442bfef37e752594a6d037e7e143e42f,2,Cross reference io::copy and fs::copy in docs. Fixes https://github.com/rust-lang/rust/issues/52524.,THUMBS_UP,2018-08-15T06:49:07Z,Havvy,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,THUMBS_UP,2018-08-15T13:48:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-15T13:48:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HEART,2018-08-15T13:48:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-15T15:30:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-15T17:42:20Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HEART,2018-08-16T17:05:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-17T00:40:07Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-17T06:42:56Z,lqd,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-22T07:45:54Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HEART,2018-08-22T16:17:37Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-22T17:08:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-08-22T18:03:46Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,THUMBS_UP,2018-08-29T05:48:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2018-11-09T21:48:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53383,MERGED,2018-08-15T10:52:31Z,2018-08-17T09:41:33Z,Speed up NLL with HybridIdxSetBuf.,nnethercote,5745597e6195fe0591737f242d02350001b6c590,5,Speed up NLL with `HybridIdxSetBuf`. `HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set that is very efficient for sets that (a) have few elements (b) have large `universe_size` values and (c) are cleared frequently. Which makes it perfect for the `gen_set` and `kill_set` sets used by the new borrow checker. This patch reduces the execution time of the five slowest NLL benchmarks by 55% 21% 16% 10% and 9%. It also reduces the max-rss of three benchmarks by 53% 33% and 9%.,HOORAY,2022-06-13T21:33:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-15T13:11:51Z,ondj,NA https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-15T13:33:59Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-15T13:58:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-15T15:22:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-15T23:04:21Z,llogiq,NA https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-16T14:33:14Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53384,MERGED,2018-08-15T11:04:22Z,2018-08-23T17:13:49Z,Use optimized SmallVec implementation,gootorov,4d81fe9243cc8372d3ad5a0eec3dd638578a3541,46,Use optimized SmallVec implementation,THUMBS_UP,2018-08-18T22:19:29Z,arthurprs,NA https://github.com/rust-lang/rust/pull/53385,MERGED,2018-08-15T11:13:30Z,2018-08-25T10:59:50Z,Stablize Iterator::find_map,matklad,057878ac71c2e9647e90636e2517f64bc4ac4288,6,Stablize Iterator::find_map,THUMBS_UP,2018-08-15T15:19:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53385,MERGED,2018-08-15T11:13:30Z,2018-08-25T10:59:50Z,Stablize Iterator::find_map,matklad,057878ac71c2e9647e90636e2517f64bc4ac4288,6,Stablize Iterator::find_map,THUMBS_UP,2018-08-15T23:05:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53385,MERGED,2018-08-15T11:13:30Z,2018-08-25T10:59:50Z,Stablize Iterator::find_map,matklad,057878ac71c2e9647e90636e2517f64bc4ac4288,6,Stablize Iterator::find_map,THUMBS_UP,2018-08-30T05:45:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53393,MERGED,2018-08-15T15:55:44Z,2018-08-21T18:16:30Z,Mark libserialize functions as inline,BurntPizza,1540e8cac0a7723a79a0601004f58574367c7eca,2,Remove inline attribute on generic functions,THUMBS_UP,2018-08-15T17:37:35Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53395,MERGED,2018-08-15T16:20:36Z,2018-08-16T20:36:06Z,Use #[non_exhaustive] on internal enums,varkor,27f2a8420f3208d7ecc007094a2b9189ccf00f7b,2,Remove outdated Unstable Book sections,HOORAY,2018-08-16T19:51:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53403,MERGED,2018-08-15T18:46:01Z,2018-08-31T14:06:24Z,Do not used Move data flow analysis make it lazy instead,spastorino,a6aa5ddf56a42f547224f616c4f37d490d5e9b88,2,Run rustfmt,THUMBS_UP,2018-08-16T12:18:02Z,lqd,NA https://github.com/rust-lang/rust/pull/53406,MERGED,2018-08-15T19:31:47Z,2018-08-17T19:10:54Z,Do not suggest conversion method that is already there,estebank,5a0a38a46f325512f00809ba5406c1fd6b3dae49,3,Do not suggest conversion method that is already there,HEART,2018-08-15T20:53:51Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/53406,MERGED,2018-08-15T19:31:47Z,2018-08-17T19:10:54Z,Do not suggest conversion method that is already there,estebank,5a0a38a46f325512f00809ba5406c1fd6b3dae49,3,Do not suggest conversion method that is already there,HEART,2018-08-22T17:02:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-16T05:50:55Z,Pazzaz,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-16T07:25:41Z,killercup,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-17T22:26:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-21T16:56:26Z,bjorn3,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-21T18:10:24Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-22T20:22:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-25T00:08:50Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-25T15:46:37Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-27T13:25:45Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-08-31T12:22:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-04T18:15:10Z,nickmccurdy,nick@nickmccurdy.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-05T01:17:20Z,sunjay,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-12T15:20:53Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-12T16:20:53Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-12T18:22:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-12T20:30:04Z,futile,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-13T08:45:48Z,Boiethios,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-13T12:09:27Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-13T16:33:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-14T15:16:33Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,THUMBS_UP,2018-09-15T06:32:10Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-09-16T02:31:35Z,tmandry,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,HOORAY,2018-11-25T14:44:27Z,bluss,NA https://github.com/rust-lang/rust/pull/53410,MERGED,2018-08-15T23:00:33Z,2018-09-05T09:58:04Z,Introduce Custom Test Frameworks,djrenren,0593dc7e3c9783f1c0bbbc8f017f9e914114e057,15,Move #[test_case] to a syntax extension,THUMBS_UP,2022-02-04T09:43:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/53412,MERGED,2018-08-15T23:14:08Z,2018-08-16T20:36:08Z, syntax_ext: remove leftover span_err_if_not_stage0 macro.,eddyb,e7b65bd4578b1d8254f6ef700994fe3677693f02,12,enable more tests on stage1 again,THUMBS_UP,2018-08-15T23:27:27Z,varkor,NA https://github.com/rust-lang/rust/pull/53412,MERGED,2018-08-15T23:14:08Z,2018-08-16T20:36:08Z, syntax_ext: remove leftover span_err_if_not_stage0 macro.,eddyb,e7b65bd4578b1d8254f6ef700994fe3677693f02,12,enable more tests on stage1 again,THUMBS_UP,2018-08-16T13:42:16Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53418,MERGED,2018-08-16T03:12:04Z,2018-08-22T22:08:08Z,Mark some suggestions as MachineApplicable,ekse,e6657154c4f0359fc67730d3e9aa0eb1a4a4e108,4,Mark some suggestions as MachineApplicable,HEART,2018-08-17T18:46:17Z,estebank,NA https://github.com/rust-lang/rust/pull/53428,MERGED,2018-08-16T13:22:15Z,2018-08-26T22:50:02Z,libtest terse format: show how far in we are,RalfJung,ffbb4078015ea0153e04991efa5565524cba0a8f,1,comment,THUMBS_UP,2018-08-16T13:25:45Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53428,MERGED,2018-08-16T13:22:15Z,2018-08-26T22:50:02Z,libtest terse format: show how far in we are,RalfJung,ffbb4078015ea0153e04991efa5565524cba0a8f,1,comment,THUMBS_UP,2018-08-16T13:36:21Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53428,MERGED,2018-08-16T13:22:15Z,2018-08-26T22:50:02Z,libtest terse format: show how far in we are,RalfJung,ffbb4078015ea0153e04991efa5565524cba0a8f,1,comment,THUMBS_UP,2018-08-16T20:04:30Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/53436,MERGED,2018-08-16T18:48:10Z,2018-08-18T19:34:39Z,std: stop backtracing when the frames are full,cuviper,f4e8d57b6ad6f599de54c020ba185db83cb011a3,3,std: stop backtracing when the frames are full,THUMBS_UP,2018-08-16T20:34:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53439,MERGED,2018-08-16T22:01:11Z,2018-08-22T00:57:15Z,Generate blanket implementations for reexported items as well,GuillaumeGomez,985da801b07ec997e3eb6d735a0dfd041728623e,2,Generate blanket implementations for reexported items as well,HEART,2018-08-17T15:42:01Z,ehuss,NA https://github.com/rust-lang/rust/pull/53441,MERGED,2018-08-17T00:15:37Z,2018-08-27T19:51:21Z,fix for late-bound regions,toidiu,c63b633971a1cb0201b6747ddea2b7c7f82a57b7,1,remove dupe attribute,THUMBS_UP,2018-08-21T17:22:13Z,estebank,NA https://github.com/rust-lang/rust/pull/53444,MERGED,2018-08-17T10:41:03Z,2018-08-21T20:33:47Z,Only fetch lib_features when there are unknown feature attributes,varkor,16958569af5c3dca9d1a46b0485254e2c095f022,2,Iterate through all crates in stability.rs rather than lib_features.rs,HEART,2018-08-17T10:52:08Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/53452,MERGED,2018-08-17T17:38:52Z,2018-08-21T18:16:33Z,Change target triple used to check for lldb in build-manifest,tromey,c37787eb932e8586c80ccc4da757fd532bce84f6,1,Change target triple used to check for lldb in build-manifest The wrong target triple was used for lldb in build-manifest. lldb is only built for macOS so update the triple to reflect that. This is an attempt to fix bug#48168.,THUMBS_UP,2018-08-17T18:21:36Z,cynecx,NA https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-18T07:41:27Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-18T14:23:31Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-18T21:01:43Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-22T01:46:35Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-22T20:29:24Z,tyre,NA https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-23T11:24:48Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-23T20:53:30Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-08-30T05:17:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-10-23T10:46:34Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53459,MERGED,2018-08-17T23:02:08Z,2018-08-23T10:56:55Z,Stabilize a few secondary macro features,petrochenkov,b34503e60ee674b31797790b2b8d8a20f1a54e48,23,Stabilize a few secondary macro features `tool_attributes` `proc_macro_path_invoc` partially `proc_macro_gen`,HOORAY,2018-11-05T09:04:48Z,behnam,NA https://github.com/rust-lang/rust/pull/53461,MERGED,2018-08-17T23:10:44Z,2018-09-16T23:13:34Z,resolve: Do not error on access to proc macros imported with `#[macro_use]`,petrochenkov,e411bb33f828fd8e63ca5e9e6f011e50828e23bd,6,resolve: Do not error on access to proc macros imported with `#[macro_use]`,THUMBS_UP,2018-08-21T23:53:29Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/53472,MERGED,2018-08-18T12:54:45Z,2018-08-31T05:56:57Z,Use FxHash{Map Set} instead of the default Hash{Map Set} everywhere in rustc.,eddyb,93f3f5b1552489dbee03020505d896f01fd53852,34,Use FxHash{Map Set} instead of the default Hash{Map Set} everywhere in rustc.,THUMBS_UP,2018-08-18T15:17:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53479,MERGED,2018-08-18T23:22:20Z,2018-08-30T02:58:17Z,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;`",joshtriplett,7cec516ef9a60aec740725ca35050b5345d95818,3,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;` When importing a crate and renaming it to an underscore-prefixed name suppress ""unused extern crate"" warnings (but not idiom lints).",THUMBS_UP,2018-08-20T00:40:30Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/53479,MERGED,2018-08-18T23:22:20Z,2018-08-30T02:58:17Z,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;`",joshtriplett,7cec516ef9a60aec740725ca35050b5345d95818,3,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;` When importing a crate and renaming it to an underscore-prefixed name suppress ""unused extern crate"" warnings (but not idiom lints).",THUMBS_UP,2018-08-20T23:40:07Z,estebank,NA https://github.com/rust-lang/rust/pull/53479,MERGED,2018-08-18T23:22:20Z,2018-08-30T02:58:17Z,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;`",joshtriplett,7cec516ef9a60aec740725ca35050b5345d95818,3,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;` When importing a crate and renaming it to an underscore-prefixed name suppress ""unused extern crate"" warnings (but not idiom lints).",THUMBS_UP,2018-08-23T19:18:59Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/53479,MERGED,2018-08-18T23:22:20Z,2018-08-30T02:58:17Z,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;`",joshtriplett,7cec516ef9a60aec740725ca35050b5345d95818,3,"Don't emit ""unused extern crate"" warnings for `extern crate foo as _;` When importing a crate and renaming it to an underscore-prefixed name suppress ""unused extern crate"" warnings (but not idiom lints).",HOORAY,2018-08-27T05:03:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53492,MERGED,2018-08-19T11:30:02Z,2018-08-21T18:16:37Z,update lld submodule to include RISCV patch,danc86,99bba340f77ae2693eed531f1b3212397ec151aa,1,update lld submodule to include RISCV patch This pulls in one new commit to add support for linking static RISCV binaries suitable for the new riscv32imac-unknown-none-elf target. See: https://github.com/rust-lang/lld/pull/1,HOORAY,2018-08-19T12:10:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53492,MERGED,2018-08-19T11:30:02Z,2018-08-21T18:16:37Z,update lld submodule to include RISCV patch,danc86,99bba340f77ae2693eed531f1b3212397ec151aa,1,update lld submodule to include RISCV patch This pulls in one new commit to add support for linking static RISCV binaries suitable for the new riscv32imac-unknown-none-elf target. See: https://github.com/rust-lang/lld/pull/1,HOORAY,2018-08-19T14:37:49Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53492,MERGED,2018-08-19T11:30:02Z,2018-08-21T18:16:37Z,update lld submodule to include RISCV patch,danc86,99bba340f77ae2693eed531f1b3212397ec151aa,1,update lld submodule to include RISCV patch This pulls in one new commit to add support for linking static RISCV binaries suitable for the new riscv32imac-unknown-none-elf target. See: https://github.com/rust-lang/lld/pull/1,HOORAY,2018-08-21T03:45:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53492,MERGED,2018-08-19T11:30:02Z,2018-08-21T18:16:37Z,update lld submodule to include RISCV patch,danc86,99bba340f77ae2693eed531f1b3212397ec151aa,1,update lld submodule to include RISCV patch This pulls in one new commit to add support for linking static RISCV binaries suitable for the new riscv32imac-unknown-none-elf target. See: https://github.com/rust-lang/lld/pull/1,HOORAY,2018-08-24T04:26:53Z,dvc94ch,david@craven.ch https://github.com/rust-lang/rust/pull/53503,MERGED,2018-08-19T19:09:08Z,2018-08-24T19:21:44Z,Discourage overuse of mem::forget,kornelski,e7709b3d44da921a65c009eb52492830141d330a,1,Discourage overuse of mem::forget,THUMBS_UP,2018-08-19T20:01:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-08-19T22:25:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-08-20T20:47:02Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-08-28T01:11:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-08-29T05:37:21Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-09-26T16:18:56Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-09-26T16:43:08Z,L-as,me@las.rs https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-09-27T05:55:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-09-27T18:55:09Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-09-30T14:48:33Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2018-11-12T17:44:52Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/53508,MERGED,2018-08-19T21:39:58Z,2018-09-23T01:39:54Z,Implement `MaybeUninit`,japaric,1cdbad20224a2e8da4a63aea8389b34bf8313281,1,allow dead_code,HOORAY,2019-01-08T20:22:04Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/53511,CLOSED,2018-08-19T23:20:39Z,2018-08-21T11:18:57Z,[Do not merge] Allow generic parameters to be specified in expressions without `::`,varkor,NA,NA,NA,HEART,2018-08-20T19:02:06Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/53511,CLOSED,2018-08-19T23:20:39Z,2018-08-21T11:18:57Z,[Do not merge] Allow generic parameters to be specified in expressions without `::`,varkor,NA,NA,NA,HEART,2018-08-20T19:11:49Z,AndrewGaspar,andrew.gaspar@outlook.com https://github.com/rust-lang/rust/pull/53511,CLOSED,2018-08-19T23:20:39Z,2018-08-21T11:18:57Z,[Do not merge] Allow generic parameters to be specified in expressions without `::`,varkor,NA,NA,NA,HEART,2018-08-20T20:35:12Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/53511,CLOSED,2018-08-19T23:20:39Z,2018-08-21T11:18:57Z,[Do not merge] Allow generic parameters to be specified in expressions without `::`,varkor,NA,NA,NA,HEART,2018-08-21T10:25:43Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53514,CLOSED,2018-08-20T00:47:16Z,2018-10-30T17:25:35Z,Correct alignment of atomic types and (re)add Atomic{I U}128,ollie27,NA,NA,NA,THUMBS_UP,2018-08-21T07:23:00Z,parched,NA https://github.com/rust-lang/rust/pull/53521,MERGED,2018-08-20T04:29:23Z,2018-08-21T18:16:39Z,syntax: Optimize some literal parsing,alexcrichton,5bf2ad3018de1f5a94bed2685211f3694f94249c,1,syntax: Optimize some literal parsing Currently in the `wasm-bindgen` project we have a very very large crate that's procedurally generated `web-sys`. To generate this crate we parse all of a browser's WebIDL and we then generate bindings for all of the APIs contained within. The resulting Rust file is 18MB large (wow!) and currently takes a very long time to compile in debug mode. On the nightly compiler a *debug* build takes 90s for the crate to finish. I was curious what was taking so long and upon investigating a *massive* portion of the time was spent in the `lit_token` method of the compiler primarily formatting strings via `format!`. Upon some more investigation it looks like the `byte_str_lit` was allocating an error message once per byte causing a very large number of allocations to happen for large literals of which wasm-bindgen generates quite a few (some are MB large). This commit fixes the issue by lazily allocating the error message only doing so if the error message is actually needed (which should be never). As a result the debug mode compilation time for our `web-sys` crate decreased from 90s to 20s a very nice improvement! (although we've still got some work to do).,HEART,2018-08-20T17:49:13Z,fitzgen,NA https://github.com/rust-lang/rust/pull/53521,MERGED,2018-08-20T04:29:23Z,2018-08-21T18:16:39Z,syntax: Optimize some literal parsing,alexcrichton,5bf2ad3018de1f5a94bed2685211f3694f94249c,1,syntax: Optimize some literal parsing Currently in the `wasm-bindgen` project we have a very very large crate that's procedurally generated `web-sys`. To generate this crate we parse all of a browser's WebIDL and we then generate bindings for all of the APIs contained within. The resulting Rust file is 18MB large (wow!) and currently takes a very long time to compile in debug mode. On the nightly compiler a *debug* build takes 90s for the crate to finish. I was curious what was taking so long and upon investigating a *massive* portion of the time was spent in the `lit_token` method of the compiler primarily formatting strings via `format!`. Upon some more investigation it looks like the `byte_str_lit` was allocating an error message once per byte causing a very large number of allocations to happen for large literals of which wasm-bindgen generates quite a few (some are MB large). This commit fixes the issue by lazily allocating the error message only doing so if the error message is actually needed (which should be never). As a result the debug mode compilation time for our `web-sys` crate decreased from 90s to 20s a very nice improvement! (although we've still got some work to do).,HEART,2018-08-20T22:24:25Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/53521,MERGED,2018-08-20T04:29:23Z,2018-08-21T18:16:39Z,syntax: Optimize some literal parsing,alexcrichton,5bf2ad3018de1f5a94bed2685211f3694f94249c,1,syntax: Optimize some literal parsing Currently in the `wasm-bindgen` project we have a very very large crate that's procedurally generated `web-sys`. To generate this crate we parse all of a browser's WebIDL and we then generate bindings for all of the APIs contained within. The resulting Rust file is 18MB large (wow!) and currently takes a very long time to compile in debug mode. On the nightly compiler a *debug* build takes 90s for the crate to finish. I was curious what was taking so long and upon investigating a *massive* portion of the time was spent in the `lit_token` method of the compiler primarily formatting strings via `format!`. Upon some more investigation it looks like the `byte_str_lit` was allocating an error message once per byte causing a very large number of allocations to happen for large literals of which wasm-bindgen generates quite a few (some are MB large). This commit fixes the issue by lazily allocating the error message only doing so if the error message is actually needed (which should be never). As a result the debug mode compilation time for our `web-sys` crate decreased from 90s to 20s a very nice improvement! (although we've still got some work to do).,HEART,2018-08-29T15:23:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53521,MERGED,2018-08-20T04:29:23Z,2018-08-21T18:16:39Z,syntax: Optimize some literal parsing,alexcrichton,5bf2ad3018de1f5a94bed2685211f3694f94249c,1,syntax: Optimize some literal parsing Currently in the `wasm-bindgen` project we have a very very large crate that's procedurally generated `web-sys`. To generate this crate we parse all of a browser's WebIDL and we then generate bindings for all of the APIs contained within. The resulting Rust file is 18MB large (wow!) and currently takes a very long time to compile in debug mode. On the nightly compiler a *debug* build takes 90s for the crate to finish. I was curious what was taking so long and upon investigating a *massive* portion of the time was spent in the `lit_token` method of the compiler primarily formatting strings via `format!`. Upon some more investigation it looks like the `byte_str_lit` was allocating an error message once per byte causing a very large number of allocations to happen for large literals of which wasm-bindgen generates quite a few (some are MB large). This commit fixes the issue by lazily allocating the error message only doing so if the error message is actually needed (which should be never). As a result the debug mode compilation time for our `web-sys` crate decreased from 90s to 20s a very nice improvement! (although we've still got some work to do).,HEART,2018-08-30T05:16:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53521,MERGED,2018-08-20T04:29:23Z,2018-08-21T18:16:39Z,syntax: Optimize some literal parsing,alexcrichton,5bf2ad3018de1f5a94bed2685211f3694f94249c,1,syntax: Optimize some literal parsing Currently in the `wasm-bindgen` project we have a very very large crate that's procedurally generated `web-sys`. To generate this crate we parse all of a browser's WebIDL and we then generate bindings for all of the APIs contained within. The resulting Rust file is 18MB large (wow!) and currently takes a very long time to compile in debug mode. On the nightly compiler a *debug* build takes 90s for the crate to finish. I was curious what was taking so long and upon investigating a *massive* portion of the time was spent in the `lit_token` method of the compiler primarily formatting strings via `format!`. Upon some more investigation it looks like the `byte_str_lit` was allocating an error message once per byte causing a very large number of allocations to happen for large literals of which wasm-bindgen generates quite a few (some are MB large). This commit fixes the issue by lazily allocating the error message only doing so if the error message is actually needed (which should be never). As a result the debug mode compilation time for our `web-sys` crate decreased from 90s to 20s a very nice improvement! (although we've still got some work to do).,HEART,2018-08-31T16:31:05Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/53524,MERGED,2018-08-20T06:47:06Z,2018-08-22T15:29:24Z,Buffer LLVM's object output stream,alexcrichton,9d54bf8df2677dd5f985838c5686efaa24a73b6c,1,Buffer LLVM's object output stream In some profiling on OSX I saw the `write` syscall as quite high up on the profiling graph which is definitely not good! It looks like we're setting the output stream of an object file as directly to a file descriptor which means that we run the risk of doing lots of little writes rather than a few large writes. This commit fixes this issue by adding a buffered stream on the output causing the `write` syscall to disappear from the profiles on OSX.,HEART,2018-08-20T10:35:24Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/53524,MERGED,2018-08-20T06:47:06Z,2018-08-22T15:29:24Z,Buffer LLVM's object output stream,alexcrichton,9d54bf8df2677dd5f985838c5686efaa24a73b6c,1,Buffer LLVM's object output stream In some profiling on OSX I saw the `write` syscall as quite high up on the profiling graph which is definitely not good! It looks like we're setting the output stream of an object file as directly to a file descriptor which means that we run the risk of doing lots of little writes rather than a few large writes. This commit fixes this issue by adding a buffered stream on the output causing the `write` syscall to disappear from the profiles on OSX.,HEART,2018-08-20T17:49:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53524,MERGED,2018-08-20T06:47:06Z,2018-08-22T15:29:24Z,Buffer LLVM's object output stream,alexcrichton,9d54bf8df2677dd5f985838c5686efaa24a73b6c,1,Buffer LLVM's object output stream In some profiling on OSX I saw the `write` syscall as quite high up on the profiling graph which is definitely not good! It looks like we're setting the output stream of an object file as directly to a file descriptor which means that we run the risk of doing lots of little writes rather than a few large writes. This commit fixes this issue by adding a buffered stream on the output causing the `write` syscall to disappear from the profiles on OSX.,HEART,2018-08-20T18:49:24Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53524,MERGED,2018-08-20T06:47:06Z,2018-08-22T15:29:24Z,Buffer LLVM's object output stream,alexcrichton,9d54bf8df2677dd5f985838c5686efaa24a73b6c,1,Buffer LLVM's object output stream In some profiling on OSX I saw the `write` syscall as quite high up on the profiling graph which is definitely not good! It looks like we're setting the output stream of an object file as directly to a file descriptor which means that we run the risk of doing lots of little writes rather than a few large writes. This commit fixes this issue by adding a buffered stream on the output causing the `write` syscall to disappear from the profiles on OSX.,HEART,2018-08-21T03:26:26Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53524,MERGED,2018-08-20T06:47:06Z,2018-08-22T15:29:24Z,Buffer LLVM's object output stream,alexcrichton,9d54bf8df2677dd5f985838c5686efaa24a73b6c,1,Buffer LLVM's object output stream In some profiling on OSX I saw the `write` syscall as quite high up on the profiling graph which is definitely not good! It looks like we're setting the output stream of an object file as directly to a file descriptor which means that we run the risk of doing lots of little writes rather than a few large writes. This commit fixes this issue by adding a buffered stream on the output causing the `write` syscall to disappear from the profiles on OSX.,HEART,2018-08-30T05:27:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2018-08-20T19:20:04Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2018-08-21T21:45:36Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2018-08-22T07:30:25Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2018-08-22T17:55:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2018-08-31T19:05:05Z,tcr,tim@timryan.org https://github.com/rust-lang/rust/pull/53533,MERGED,2018-08-20T18:29:47Z,2018-09-01T20:31:38Z,Add Error::source method per RFC 2504.,withoutboats,e2e4f57bf84ca3cbdb91ba9d235c12b46666d090,1,Correctly parenthesize dyn Error + 'static.,HOORAY,2019-03-05T12:22:23Z,hcpl,NA https://github.com/rust-lang/rust/pull/53541,MERGED,2018-08-20T22:44:57Z,2018-08-22T22:08:14Z,Fix missing impl trait display as ret type,GuillaumeGomez,e67bba8ebe14c815c4f756aa267249e5c35d5ec5,2,Fix missing impl trait display as ret type,HOORAY,2018-09-07T06:30:35Z,bjorn3,NA https://github.com/rust-lang/rust/pull/53541,MERGED,2018-08-20T22:44:57Z,2018-08-22T22:08:14Z,Fix missing impl trait display as ret type,GuillaumeGomez,e67bba8ebe14c815c4f756aa267249e5c35d5ec5,2,Fix missing impl trait display as ret type,HOORAY,2018-09-14T05:02:51Z,estebank,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-09-26T14:45:00Z,orium,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,THUMBS_UP,2018-10-03T18:30:31Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,THUMBS_UP,2018-10-03T20:42:02Z,thedodd,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-03T20:42:03Z,thedodd,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-03T22:46:37Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-04T03:20:39Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-04T04:29:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-04T09:12:24Z,SephVelut,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-04T19:59:04Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-05T05:14:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-10-06T15:18:41Z,hcpl,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,THUMBS_UP,2018-10-06T19:53:45Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2018-11-20T07:33:24Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/53542,MERGED,2018-08-20T22:51:51Z,2018-09-25T22:52:21Z,`impl trait` in bindings (feature: impl-trait-existential-types),alexreg,16cf404f9853e716a216be32d05f5215ff821c00,1,Added section to Unstable Book.,HOORAY,2019-04-29T09:17:53Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/53545,MERGED,2018-08-20T23:29:08Z,2018-08-24T19:21:47Z,Fix #50865: ICE on impl-trait returning functions reaching private items,FelixMcFelix,85a05d1815217584c096ebc9d64b3a547b667f48,3,Light restructuring.,HEART,2018-08-23T17:20:09Z,estebank,NA https://github.com/rust-lang/rust/pull/53558,MERGED,2018-08-21T11:00:32Z,2018-08-22T22:08:15Z,Normalize source line and column numbers.,davidtwco,6e24868384408da8b542f70085f7a45a3c383fc7,3,Normalize source line and column numbers. This commit adds a normalization for line and column numbers in stderr files where the line/col is from the source directory rather than the test itself - thereby removing the need to update tests as compiler source changes.,HOORAY,2018-08-21T23:35:53Z,estebank,NA https://github.com/rust-lang/rust/pull/53558,MERGED,2018-08-21T11:00:32Z,2018-08-22T22:08:15Z,Normalize source line and column numbers.,davidtwco,6e24868384408da8b542f70085f7a45a3c383fc7,3,Normalize source line and column numbers. This commit adds a normalization for line and column numbers in stderr files where the line/col is from the source directory rather than the test itself - thereby removing the need to update tests as compiler source changes.,HOORAY,2018-08-22T10:40:12Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T13:49:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-21T13:49:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-21T13:49:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T13:58:35Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:03:57Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:04:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:06:47Z,Ixrec,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:17:18Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-21T14:17:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:18:46Z,vorner,vorner+github@vorner.cz https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:27:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:29:32Z,kennytm,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-21T14:30:06Z,StyMaar,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:33:18Z,kjeremy,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:45:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:50:37Z,Fingercomp,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T14:54:34Z,hgallagher1993,hgallagher@protonmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:00:47Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:03:33Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:04:11Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:16:49Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-21T15:18:39Z,killercup,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:18:39Z,killercup,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T15:18:39Z,killercup,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:27:07Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:29:19Z,martinrlilja,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T15:34:32Z,KasMA1990,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:36:07Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T15:36:08Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:42:50Z,qmx,qmx@qmx.me https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:50:42Z,Kroc,kroc@camendesign.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T15:52:23Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T15:58:16Z,denismerigoux,denis.merigoux@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:02:20Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:04:10Z,llogiq,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:08:12Z,brendanzab,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T16:08:18Z,brendanzab,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:16:10Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T16:39:51Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:39:52Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T16:57:51Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T16:57:51Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T17:00:04Z,matematikaadit,matematika.adit@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T17:15:17Z,anderejd,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T17:19:29Z,cramertj,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T17:28:14Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T18:07:03Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-21T18:11:29Z,neoeinstein,marcus@griep.us https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T18:31:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T19:02:23Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T19:02:24Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T19:37:32Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T19:37:33Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-21T19:37:45Z,Enet4,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T19:37:47Z,Enet4,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T19:42:40Z,PixelPirate,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T19:42:48Z,sersorrel,ash@sorrel.sh https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T20:09:16Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T20:19:44Z,estebank,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-21T20:26:26Z,XOSplicer,stegmaier.felix@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T21:06:21Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T21:19:23Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T21:24:02Z,kimsnj,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T21:52:25Z,orium,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T21:54:03Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T23:15:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T23:29:26Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-21T23:47:43Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T00:13:50Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T00:34:54Z,m-wynn,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T00:34:55Z,m-wynn,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-22T00:34:56Z,m-wynn,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T00:35:00Z,m-wynn,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T00:43:41Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T00:43:42Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T00:43:44Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-22T00:43:45Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T01:18:51Z,andersk,andersk@mit.edu https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T01:43:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-22T01:43:37Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T01:43:38Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T01:43:39Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T02:09:07Z,ogiekako,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T02:34:13Z,worace,horace.d.williams@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T07:26:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T08:09:03Z,sjbwylbs,sjbwylbs@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T08:20:22Z,MrMuetze,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T08:20:24Z,MrMuetze,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-22T08:20:28Z,MrMuetze,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T08:20:29Z,MrMuetze,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T08:33:59Z,L-as,me@las.rs https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T11:34:19Z,jnicklas,jonas@jnicklas.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T14:36:40Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T15:54:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T16:52:09Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-22T17:16:53Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-22T19:49:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-08-22T19:56:34Z,taralx,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-23T00:23:11Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-23T08:29:23Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-23T13:42:03Z,Kvikal,g4rrus@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-24T05:33:33Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-29T07:16:02Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-29T20:25:34Z,kalebo,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-30T05:44:06Z,8573,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-08-30T06:04:06Z,CircuitCoder,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-08-30T06:04:08Z,CircuitCoder,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2018-08-30T20:20:38Z,florianjacob,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-09-03T10:49:49Z,JamesHinshelwood,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-09-03T12:37:20Z,tommilligan,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-09-04T18:04:06Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-09-15T22:48:10Z,maxdeviant,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-10-06T12:43:14Z,burjui,bytefu@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-10-09T17:04:47Z,JesseWright,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2018-10-09T17:04:48Z,JesseWright,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2018-11-06T08:23:38Z,kaliumxyz,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2018-11-19T18:31:26Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2019-02-27T17:52:47Z,johnaoss,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2019-03-06T14:08:27Z,emlun,emil@emlun.se https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2019-05-26T11:22:14Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2019-05-26T11:22:18Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2019-08-01T08:41:44Z,JJJollyjim,jamie@kwiius.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2019-08-01T08:41:45Z,JJJollyjim,jamie@kwiius.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2019-12-03T22:47:47Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2019-12-03T22:47:50Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2020-02-01T01:30:32Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2020-11-16T03:17:10Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-02-05T05:56:21Z,toasterrepairman,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-05T08:36:17Z,noahtallen,noahtallen@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-02-05T08:36:19Z,noahtallen,noahtallen@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-05T14:51:34Z,tomtomjhj,tomtomjhj@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2021-02-05T15:44:00Z,nayuki,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-05T22:03:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-02-06T01:52:04Z,rrbutani,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-06T11:43:49Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2021-02-06T11:43:50Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-06T18:45:36Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-02-24T13:29:45Z,torokati44,torokati44@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2021-02-28T06:33:44Z,nulladdict,nulladdicted@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-02-28T06:33:45Z,nulladdict,nulladdicted@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-03-02T15:28:03Z,make-github-pseudonymous-again,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-03-12T08:46:54Z,Mrp1Dev,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2021-05-22T13:32:22Z,kgtkr,contact@kgtkr.net https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-07-22T23:47:41Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-09-09T15:46:02Z,ZetaNumbers,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-09-09T15:54:08Z,zohnannor,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,THUMBS_UP,2021-09-09T15:54:08Z,zohnannor,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HOORAY,2021-09-09T15:54:08Z,zohnannor,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,HEART,2021-09-09T15:54:09Z,zohnannor,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2021-10-18T09:11:51Z,nhamovitz,NA https://github.com/rust-lang/rust/pull/53562,MERGED,2018-08-21T13:47:42Z,2018-08-24T19:21:48Z,Lament the invincibility of the Turbofish,varkor,b188c2a4eb7a3eede8477e3fbeaea623fc256586,1,Lament the invincibility of the Turbofish,LAUGH,2022-03-24T12:25:23Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/53563,MERGED,2018-08-21T14:15:01Z,2018-08-24T19:21:49Z,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",matthiaskrgr,ede1f7d2a5a2f4038e3f3b2e953c44ee5ea06194,87,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",HOORAY,2018-08-21T15:30:39Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/53563,MERGED,2018-08-21T14:15:01Z,2018-08-24T19:21:49Z,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",matthiaskrgr,ede1f7d2a5a2f4038e3f3b2e953c44ee5ea06194,87,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",THUMBS_UP,2018-08-21T15:54:11Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53563,MERGED,2018-08-21T14:15:01Z,2018-08-24T19:21:49Z,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",matthiaskrgr,ede1f7d2a5a2f4038e3f3b2e953c44ee5ea06194,87,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",HOORAY,2018-08-21T23:32:31Z,estebank,NA https://github.com/rust-lang/rust/pull/53563,MERGED,2018-08-21T14:15:01Z,2018-08-24T19:21:49Z,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",matthiaskrgr,ede1f7d2a5a2f4038e3f3b2e953c44ee5ea06194,87,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",THUMBS_UP,2018-08-22T20:25:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53563,MERGED,2018-08-21T14:15:01Z,2018-08-24T19:21:49Z,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",matthiaskrgr,ede1f7d2a5a2f4038e3f3b2e953c44ee5ea06194,87,"use String::new() instead of String::from("""") """".to_string() """".to_owned() or """".into()",HEART,2018-08-22T20:36:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53565,MERGED,2018-08-21T15:30:22Z,2018-09-10T10:29:01Z,#53359: putting multiple unresolved import on single line,PramodBisht,21ba03e2b910cf58dd5c21c8dd97d4f66b6518c5,5,Fixed 53359: E0432 unresolved import on the same line is now emiting one diagnostic Addressed estebank's comments for 53359,HEART,2018-08-21T17:11:44Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53565,MERGED,2018-08-21T15:30:22Z,2018-09-10T10:29:01Z,#53359: putting multiple unresolved import on single line,PramodBisht,21ba03e2b910cf58dd5c21c8dd97d4f66b6518c5,5,Fixed 53359: E0432 unresolved import on the same line is now emiting one diagnostic Addressed estebank's comments for 53359,THUMBS_UP,2018-08-21T17:11:46Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53565,MERGED,2018-08-21T15:30:22Z,2018-09-10T10:29:01Z,#53359: putting multiple unresolved import on single line,PramodBisht,21ba03e2b910cf58dd5c21c8dd97d4f66b6518c5,5,Fixed 53359: E0432 unresolved import on the same line is now emiting one diagnostic Addressed estebank's comments for 53359,HEART,2018-08-21T17:14:24Z,estebank,NA https://github.com/rust-lang/rust/pull/53565,MERGED,2018-08-21T15:30:22Z,2018-09-10T10:29:01Z,#53359: putting multiple unresolved import on single line,PramodBisht,21ba03e2b910cf58dd5c21c8dd97d4f66b6518c5,5,Fixed 53359: E0432 unresolved import on the same line is now emiting one diagnostic Addressed estebank's comments for 53359,THUMBS_UP,2018-08-31T16:14:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53575,MERGED,2018-08-21T19:59:14Z,2018-09-06T23:30:06Z,Don't reduce E0161 to a warning in NLL migrate mode,matthewjasper,cd92da833fcb8818ac679be615c7bfe02edaa235,11,Update E0161 test to cover more cases Update another test that broke due to E0161 no longer being buffered,THUMBS_UP,2018-09-14T12:43:01Z,qnighy,NA https://github.com/rust-lang/rust/pull/53577,MERGED,2018-08-21T22:21:40Z,2018-08-25T04:45:10Z,Search a substring instead of start of string in rustdoc search,GuillaumeGomez,e87b4b3100556a84042482eeaedc5de8f2d1fe28,2,Search a substring instead of start of string in rustdoc search,THUMBS_UP,2018-08-22T12:36:57Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53577,MERGED,2018-08-21T22:21:40Z,2018-08-25T04:45:10Z,Search a substring instead of start of string in rustdoc search,GuillaumeGomez,e87b4b3100556a84042482eeaedc5de8f2d1fe28,2,Search a substring instead of start of string in rustdoc search,THUMBS_UP,2018-08-22T16:36:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53577,MERGED,2018-08-21T22:21:40Z,2018-08-25T04:45:10Z,Search a substring instead of start of string in rustdoc search,GuillaumeGomez,e87b4b3100556a84042482eeaedc5de8f2d1fe28,2,Search a substring instead of start of string in rustdoc search,HEART,2018-08-22T16:36:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53578,CLOSED,2018-08-21T22:26:40Z,2018-09-26T23:56:04Z,[Do not merge] Optional turbofish breakage test,varkor,NA,NA,NA,LAUGH,2018-08-21T23:32:23Z,estebank,NA https://github.com/rust-lang/rust/pull/53578,CLOSED,2018-08-21T22:26:40Z,2018-09-26T23:56:04Z,[Do not merge] Optional turbofish breakage test,varkor,NA,NA,NA,LAUGH,2018-08-22T02:13:37Z,kennytm,NA https://github.com/rust-lang/rust/pull/53578,CLOSED,2018-08-21T22:26:40Z,2018-09-26T23:56:04Z,[Do not merge] Optional turbofish breakage test,varkor,NA,NA,NA,LAUGH,2018-08-27T03:46:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53578,CLOSED,2018-08-21T22:26:40Z,2018-09-26T23:56:04Z,[Do not merge] Optional turbofish breakage test,varkor,NA,NA,NA,LAUGH,2018-09-19T08:21:45Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53580,MERGED,2018-08-21T23:27:18Z,2018-08-27T17:43:29Z,fix NLL ICEs,nikomatsakis,a59584a6ff381ad701e80723db743ed0771ddad8,5,use `TypeOp` machinery for `outlives_bounds` Fixes #52992,HOORAY,2018-08-22T08:54:21Z,passy,NA https://github.com/rust-lang/rust/pull/53580,MERGED,2018-08-21T23:27:18Z,2018-08-27T17:43:29Z,fix NLL ICEs,nikomatsakis,a59584a6ff381ad701e80723db743ed0771ddad8,5,use `TypeOp` machinery for `outlives_bounds` Fixes #52992,HOORAY,2018-08-22T10:06:56Z,lqd,NA https://github.com/rust-lang/rust/pull/53580,MERGED,2018-08-21T23:27:18Z,2018-08-27T17:43:29Z,fix NLL ICEs,nikomatsakis,a59584a6ff381ad701e80723db743ed0771ddad8,5,use `TypeOp` machinery for `outlives_bounds` Fixes #52992,HOORAY,2018-08-30T05:31:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53581,MERGED,2018-08-22T00:18:29Z,2018-08-22T20:00:11Z,Rename TyVariants and variants,varkor,71722b9cef68388790fbbd5f30d35750cb2f93f9,6,Fix rebase issues,HEART,2018-08-22T15:05:38Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53581,MERGED,2018-08-22T00:18:29Z,2018-08-22T20:00:11Z,Rename TyVariants and variants,varkor,71722b9cef68388790fbbd5f30d35750cb2f93f9,6,Fix rebase issues,HEART,2018-08-30T05:44:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53584,MERGED,2018-08-22T01:40:37Z,2018-08-25T15:06:28Z,Fix #53525 - Unify E0243 E0244 E0087 E0088 E0089 and E0090 into E0107,matthew-russo,79afc6e9e880244bf841ae85d02505b257a28343,39,updates tests to use new error code,HEART,2018-08-24T12:15:01Z,varkor,NA https://github.com/rust-lang/rust/pull/53585,MERGED,2018-08-22T01:58:56Z,2018-08-22T22:08:18Z,Remove super old comment on function that parses items,dtolnay,cf1b6d6fe87b01f556d49372d1c988c7cc686057,1,Remove super old comment on function that parses items This comment was added more than 5 years ago in ab03c1e4221. As far as anyone reading this comment today needs to know the function has never parsed items from inside an extern crate.,LAUGH,2018-08-22T17:32:17Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/53586,MERGED,2018-08-22T02:55:05Z,2018-11-22T18:59:35Z,Move Cargo.{toml lock} to the repository root directory.,eddyb,7c166f54b201dbefe27d4ab61dfdf640ac3a2722,11,Move Cargo.{toml lock} to the repository root directory.,THUMBS_UP,2018-11-21T14:39:57Z,mati865,NA https://github.com/rust-lang/rust/pull/53586,MERGED,2018-08-22T02:55:05Z,2018-11-22T18:59:35Z,Move Cargo.{toml lock} to the repository root directory.,eddyb,7c166f54b201dbefe27d4ab61dfdf640ac3a2722,11,Move Cargo.{toml lock} to the repository root directory.,THUMBS_UP,2018-11-25T03:07:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HEART,2018-08-22T15:49:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HOORAY,2018-08-22T15:49:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HOORAY,2018-08-22T17:59:15Z,cramertj,NA https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HEART,2018-08-22T17:59:16Z,cramertj,NA https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HOORAY,2018-08-22T19:37:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53604,MERGED,2018-08-22T14:02:22Z,2018-09-01T13:45:07Z,Implement the `min_const_fn` feature gate,oli-obk,2839f4f0e8d58c295e146999961b78e2cc47354f,1,Get rid of token passing,HOORAY,2018-08-31T12:30:57Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53611,MERGED,2018-08-22T18:25:22Z,2018-09-01T03:27:50Z,Update LLVM submodule,alexcrichton,6c101422514104dc7dbca13bab7a4e8b3b06f030,6,Update LLVM submodule This commit updates the LLVM submodule to the current trunk of LLVM itself. This brings a few notable improvements for the wasm target: * Support for wasm atomic instructions is greatly improved * Renamed memory wasm intrinsics are fully supported * LLD has fixed a quadratic execution bug with large numbers of relocations in wasm files. The compiler-rt submodule has been updated in tandem as well.,THUMBS_UP,2018-08-23T03:12:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53611,MERGED,2018-08-22T18:25:22Z,2018-09-01T03:27:50Z,Update LLVM submodule,alexcrichton,6c101422514104dc7dbca13bab7a4e8b3b06f030,6,Update LLVM submodule This commit updates the LLVM submodule to the current trunk of LLVM itself. This brings a few notable improvements for the wasm target: * Support for wasm atomic instructions is greatly improved * Renamed memory wasm intrinsics are fully supported * LLD has fixed a quadratic execution bug with large numbers of relocations in wasm files. The compiler-rt submodule has been updated in tandem as well.,THUMBS_UP,2018-09-05T07:52:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53617,MERGED,2018-08-22T22:19:59Z,2018-08-24T19:21:53Z,tidy: Stop requiring a license header,joshtriplett,a15b61780b24a2311a3e42a3437b3418921a3ed3,1,tidy: Stop requiring a license header Previously approved in rust-lang/rust#43498 ; update tidy to match.,HOORAY,2018-08-22T22:39:56Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53617,MERGED,2018-08-22T22:19:59Z,2018-08-24T19:21:53Z,tidy: Stop requiring a license header,joshtriplett,a15b61780b24a2311a3e42a3437b3418921a3ed3,1,tidy: Stop requiring a license header Previously approved in rust-lang/rust#43498 ; update tidy to match.,HOORAY,2018-08-23T13:03:52Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53617,MERGED,2018-08-22T22:19:59Z,2018-08-24T19:21:53Z,tidy: Stop requiring a license header,joshtriplett,a15b61780b24a2311a3e42a3437b3418921a3ed3,1,tidy: Stop requiring a license header Previously approved in rust-lang/rust#43498 ; update tidy to match.,HOORAY,2018-08-23T15:01:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53617,MERGED,2018-08-22T22:19:59Z,2018-08-24T19:21:53Z,tidy: Stop requiring a license header,joshtriplett,a15b61780b24a2311a3e42a3437b3418921a3ed3,1,tidy: Stop requiring a license header Previously approved in rust-lang/rust#43498 ; update tidy to match.,HOORAY,2018-08-23T15:27:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53617,MERGED,2018-08-22T22:19:59Z,2018-08-24T19:21:53Z,tidy: Stop requiring a license header,joshtriplett,a15b61780b24a2311a3e42a3437b3418921a3ed3,1,tidy: Stop requiring a license header Previously approved in rust-lang/rust#43498 ; update tidy to match.,HOORAY,2018-08-24T06:33:15Z,iago-lito,NA https://github.com/rust-lang/rust/pull/53626,MERGED,2018-08-23T07:55:00Z,2018-08-26T22:50:08Z,Automatically expand a section even after page load,kzys,2c61f3ce9e82fa5eb0cb780400b8d95cd5a76571,1,Expand a collapsed element on onclick Doing the expansion on onhashchange seems too late. Fixes #48726,HOORAY,2018-08-23T08:09:04Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/53629,MERGED,2018-08-23T08:41:11Z,2018-08-26T11:54:30Z,Lazier sparse bit matrix,nnethercote,002f03b654845667023cdaad8af988909a030bfe,1,Make SparseBitMatrix a bit lazier. Currently when a row is instantiated in SparseBitMatrix any missing rows prior to it are also fully instantiated. This patch changes things so that those prior rows are minimally instantiated (with a `None`). This avoids a decent number of allocations in NLL speeding up several benchmarks by up to 0.5%. The patch also removes two unused methods `len()` and `iter_enumerated()`.,THUMBS_UP,2018-08-26T03:21:56Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53642,MERGED,2018-08-23T18:05:39Z,2018-08-29T04:20:14Z,Fix warnings about the `native` target-cpu,alexcrichton,1fd45a13dee17701fc0aeaa847c1919d485d09fd,8,Fix warnings about the `native` target-cpu This fixes a regression from #53031 where specifying `-C target-cpu=native` is printing a lot of warnings from LLVM about `native` being an unknown CPU. It turns out that `native` is indeed an unknown CPU and we have to perform a mapping to an actual CPU name but this mapping is only performed in one location rather than all locations we inform LLVM about the target CPU. This commit centralizes the mapping of `native` to LLVM's value of the native CPU ensuring that all locations we inform LLVM about the `target-cpu` it's never `native`. Closes #53322,HOORAY,2018-08-23T18:31:42Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/53642,MERGED,2018-08-23T18:05:39Z,2018-08-29T04:20:14Z,Fix warnings about the `native` target-cpu,alexcrichton,1fd45a13dee17701fc0aeaa847c1919d485d09fd,8,Fix warnings about the `native` target-cpu This fixes a regression from #53031 where specifying `-C target-cpu=native` is printing a lot of warnings from LLVM about `native` being an unknown CPU. It turns out that `native` is indeed an unknown CPU and we have to perform a mapping to an actual CPU name but this mapping is only performed in one location rather than all locations we inform LLVM about the target CPU. This commit centralizes the mapping of `native` to LLVM's value of the native CPU ensuring that all locations we inform LLVM about the `target-cpu` it's never `native`. Closes #53322,HOORAY,2018-08-23T21:01:11Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/53642,MERGED,2018-08-23T18:05:39Z,2018-08-29T04:20:14Z,Fix warnings about the `native` target-cpu,alexcrichton,1fd45a13dee17701fc0aeaa847c1919d485d09fd,8,Fix warnings about the `native` target-cpu This fixes a regression from #53031 where specifying `-C target-cpu=native` is printing a lot of warnings from LLVM about `native` being an unknown CPU. It turns out that `native` is indeed an unknown CPU and we have to perform a mapping to an actual CPU name but this mapping is only performed in one location rather than all locations we inform LLVM about the target CPU. This commit centralizes the mapping of `native` to LLVM's value of the native CPU ensuring that all locations we inform LLVM about the `target-cpu` it's never `native`. Closes #53322,HOORAY,2018-08-27T06:36:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53644,MERGED,2018-08-23T18:24:06Z,2018-08-24T19:21:56Z,Use SmallVec for SmallCStr,llogiq,25a83e3a88bf5f199c8a8d8d8f452bab83d9a061,1,Use SmallVec for SmallCStr,HOORAY,2018-08-24T22:07:38Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53644,MERGED,2018-08-23T18:24:06Z,2018-08-24T19:21:56Z,Use SmallVec for SmallCStr,llogiq,25a83e3a88bf5f199c8a8d8d8f452bab83d9a061,1,Use SmallVec for SmallCStr,HOORAY,2018-08-30T05:32:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:03:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:08:36Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T19:08:39Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:13:33Z,declanvk,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:16:23Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T19:33:23Z,lqd,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:36:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T19:36:33Z,cramertj,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T19:49:54Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:49:56Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T19:55:47Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T19:58:19Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T20:13:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T20:13:26Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T20:24:02Z,arielb1,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T20:36:50Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T20:47:21Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T21:08:19Z,tinaun,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T21:08:49Z,Nercury,nercury@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T21:40:10Z,est31,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T21:40:17Z,est31,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-23T21:52:04Z,est31,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-23T22:19:26Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T22:39:03Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-23T23:55:51Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T01:20:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-24T01:54:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T01:54:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-24T01:54:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T04:23:41Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T13:40:42Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-24T13:40:46Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T18:13:01Z,Pratyush,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-24T18:13:16Z,Pratyush,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-24T18:13:18Z,Pratyush,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-24T22:11:15Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-25T08:53:24Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-25T08:56:32Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-25T20:03:11Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-25T20:03:12Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-26T05:30:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T04:46:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-08-27T04:46:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T06:04:39Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-27T06:04:39Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-27T21:12:33Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T21:12:35Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-27T21:14:29Z,jethrogb,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T21:25:15Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-27T21:40:34Z,RustyYato,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T22:22:35Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-27T22:29:53Z,Enet4,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-27T22:29:54Z,Enet4,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T22:53:24Z,kjetilkjeka,kjetilkjeka@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-27T23:15:08Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T01:42:55Z,felix91gr,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T02:43:37Z,johncf,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T02:44:00Z,johncf,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-28T04:58:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-08-28T04:58:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T04:58:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T04:58:38Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T05:14:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T07:45:48Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T07:45:48Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-28T07:45:49Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-08-28T07:45:49Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T08:12:07Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T08:12:08Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-08-28T09:12:00Z,kennytm,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-28T11:57:07Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-28T13:20:13Z,kskjer,kskjer@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-28T13:58:25Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-08-30T02:06:09Z,Qata,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-30T02:06:10Z,Qata,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-30T02:06:13Z,Qata,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-08-30T02:06:15Z,Qata,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-30T07:35:54Z,aspurdy,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-08-31T07:03:10Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-08-31T21:56:01Z,fusedFET,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-04T02:54:00Z,nicoburns,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-05T08:16:21Z,canndrew,shum@canndrew.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-05T08:16:28Z,canndrew,shum@canndrew.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-09-07T16:00:29Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-09-07T16:00:30Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-07T16:00:31Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-07T16:00:32Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-07T17:14:25Z,samsartor,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-09-07T23:19:43Z,bluebear94,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-09T11:43:58Z,hrektts,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-10T10:12:32Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-09-12T03:52:47Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-12T03:52:50Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-12T03:52:50Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-09-13T16:30:44Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-09-14T05:31:16Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-09-14T05:31:56Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-14T13:21:18Z,JamesHinshelwood,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-22T06:36:49Z,aschuhardt,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-09-23T00:34:01Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-09-29T06:48:46Z,nielsle,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-10-02T12:54:18Z,jeehoonkang,jeehoon.kang@kaist.ac.kr https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-10-10T00:12:23Z,bjadamson,adamson dot benjamin at gmail dot com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-10-10T02:24:16Z,ambaxter,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-10-10T02:24:17Z,ambaxter,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-10-10T02:24:17Z,ambaxter,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-10-10T02:24:18Z,ambaxter,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-10-10T14:05:13Z,brian-dawn,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-10-18T19:40:34Z,werner,werner_a_e@yahoo.es https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-10-18T19:40:36Z,werner,werner_a_e@yahoo.es https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-10-22T06:49:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-10-25T02:01:07Z,branan,branan@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-11-02T20:53:13Z,zroug,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-11-05T14:23:44Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-11-09T00:40:11Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-11-09T05:53:50Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-11-10T21:58:37Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-11-11T18:58:08Z,sebcrozet,developer@crozet.re https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-11-11T18:58:11Z,sebcrozet,developer@crozet.re https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-11-11T18:58:13Z,sebcrozet,developer@crozet.re https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-11-11T18:58:15Z,sebcrozet,developer@crozet.re https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-11-17T20:33:16Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-11-17T20:33:18Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-11-17T20:33:21Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-11-18T19:00:11Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-11-18T19:00:11Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-11-18T19:00:12Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-11-22T21:18:01Z,bluss,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-12-07T00:59:48Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-12-07T16:18:55Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-12-07T16:18:57Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-12-07T19:56:40Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-12-12T14:17:20Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-12-21T13:46:31Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-12-21T22:44:51Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2018-12-26T01:31:20Z,Frizi,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2018-12-26T01:31:22Z,Frizi,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2018-12-26T01:31:24Z,Frizi,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-12-26T01:31:26Z,Frizi,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2018-12-27T20:15:25Z,estebank,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-02T19:00:51Z,qthree,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-04T10:11:14Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-06T09:56:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-01-06T09:56:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-08T10:54:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-01-10T20:48:50Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-11T08:34:14Z,chpio,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-01-11T11:29:00Z,jplatte,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-11T16:37:29Z,kfreiman,k.freiman@yandex.ru https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-13T12:53:25Z,AgustinCB,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-13T18:38:28Z,squishy-clouds,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-01-13T21:44:12Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-14T04:03:54Z,Airtnp,lrxiao@ucla.edu https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-16T19:15:18Z,distransient,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-01-16T19:15:18Z,distransient,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-01-16T19:15:19Z,distransient,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-01-16T19:15:19Z,distransient,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-01-17T07:34:07Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-01T04:42:42Z,kbarros,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-02-01T10:16:23Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-02-01T10:16:24Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-02-01T10:16:24Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-01T10:16:24Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-02-09T10:27:38Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-09T10:27:39Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-02-10T16:17:43Z,mati865,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-02-12T12:38:44Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-02-12T12:38:45Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-02-12T12:38:46Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-12T12:38:46Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-02-16T03:17:16Z,udscbt-wsx,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-02-16T03:17:19Z,udscbt-wsx,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-16T03:17:19Z,udscbt-wsx,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-02-25T21:23:33Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-02-27T11:19:01Z,orium,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-03-12T01:59:18Z,jrr45,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-03-14T13:43:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-04-08T17:50:59Z,jeffvandyke,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-04-08T17:51:08Z,jeffvandyke,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-04-09T05:02:21Z,flseaui,flseaui@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-04-23T23:30:56Z,delacian,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-04-24T10:22:47Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-04-24T10:22:49Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-04-24T10:22:50Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-05-02T20:43:13Z,frol,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-05-02T20:43:15Z,frol,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-05-02T20:43:16Z,frol,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-05-02T20:43:16Z,frol,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-05-03T04:19:19Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-05-03T04:19:21Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-05-03T06:36:51Z,qnighy,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-05-06T20:48:44Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-05-10T15:24:17Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-05-10T15:24:26Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2019-05-10T15:24:28Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-05-10T15:24:29Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2019-06-12T04:20:48Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2019-07-24T04:59:53Z,pythondude325,me@gisch.dev https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2019-12-02T02:41:58Z,nravic,nravichandra@6river.com https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2020-04-11T09:47:48Z,jon-chuang,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,THUMBS_UP,2020-09-10T14:46:23Z,Virgiel,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2020-09-10T14:46:24Z,Virgiel,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HOORAY,2020-09-10T14:46:24Z,Virgiel,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,HEART,2020-09-10T14:46:26Z,Virgiel,NA https://github.com/rust-lang/rust/pull/53645,MERGED,2018-08-23T18:54:34Z,2019-05-06T19:32:27Z,The Genesis of Generic Germination,varkor,9a2772aff0e6c2058fb52a844b4593eabd18fcbc,3,Implement `ToTrace` for `ty::Const`,LAUGH,2022-01-19T01:16:41Z,kaiuri,uriel.acioli@gmail.com https://github.com/rust-lang/rust/pull/53648,MERGED,2018-08-23T20:18:49Z,2018-08-27T09:08:50Z,change the default linker of the ARM Cortex-M targets,japaric,d65a64e31b8a5007b4ee0fb1dbd4cad2176859ab,5,change the default linker of the ARM Cortex-M targets to rust-lld so users won't need an external linker to build programs,THUMBS_UP,2018-08-23T21:11:04Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/53648,MERGED,2018-08-23T20:18:49Z,2018-08-27T09:08:50Z,change the default linker of the ARM Cortex-M targets,japaric,d65a64e31b8a5007b4ee0fb1dbd4cad2176859ab,5,change the default linker of the ARM Cortex-M targets to rust-lld so users won't need an external linker to build programs,THUMBS_UP,2018-08-24T04:26:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53648,MERGED,2018-08-23T20:18:49Z,2018-08-27T09:08:50Z,change the default linker of the ARM Cortex-M targets,japaric,d65a64e31b8a5007b4ee0fb1dbd4cad2176859ab,5,change the default linker of the ARM Cortex-M targets to rust-lld so users won't need an external linker to build programs,THUMBS_UP,2018-08-24T20:54:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53651,MERGED,2018-08-23T22:04:56Z,2018-08-26T22:50:09Z,Add struct keyword doc,GuillaumeGomez,61fc7f18c3f3fed492ec117d25e9bcc3c5b52217,1,Add struct keyword doc,LAUGH,2018-08-25T11:29:16Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/53652,MERGED,2018-08-23T23:45:12Z,2018-09-22T17:00:37Z,define copy_within on slices,oconnor663,d0e59f563d11a0d8efbe9a59e7b20526bc42adce,2,add tests for copy_within,THUMBS_UP,2018-09-27T19:23:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T01:53:08Z,varkor,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HEART,2018-08-24T01:53:39Z,varkor,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HEART,2018-08-24T03:31:29Z,est31,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T04:19:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T04:27:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T07:06:28Z,ljedrz,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HEART,2018-08-24T07:12:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HOORAY,2018-08-24T10:22:45Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T19:35:43Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-08-24T21:21:41Z,cramertj,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-10-22T20:12:27Z,hcpl,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HOORAY,2018-11-02T18:23:21Z,estebank,NA https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-11-03T00:32:43Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HEART,2018-11-03T00:32:44Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,LAUGH,2018-11-05T12:16:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53654,CLOSED,2018-08-24T01:51:10Z,2018-08-29T20:16:26Z,REMOVE ALL THE LICENSE THINGS,mark-i-m,NA,NA,NA,HEART,2018-11-29T17:49:59Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53659,MERGED,2018-08-24T06:33:39Z,2018-08-29T06:24:48Z,Remove `AccumulateVec` and its uses.,nnethercote,8cecfa62e8783d68fde7002d50d202e58cf44466,13,Remove `AccumulateVec` and its uses. It's basically just a less capable version of `SmallVec`.,HEART,2018-08-24T08:14:36Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/53659,MERGED,2018-08-24T06:33:39Z,2018-08-29T06:24:48Z,Remove `AccumulateVec` and its uses.,nnethercote,8cecfa62e8783d68fde7002d50d202e58cf44466,13,Remove `AccumulateVec` and its uses. It's basically just a less capable version of `SmallVec`.,HEART,2018-09-06T02:25:38Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/53661,CLOSED,2018-08-24T07:21:48Z,2018-10-23T17:16:27Z,rustc: remove type & lifetime parameter names from the typesystem.,eddyb,NA,NA,NA,THUMBS_UP,2018-08-24T08:01:46Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/53661,CLOSED,2018-08-24T07:21:48Z,2018-10-23T17:16:27Z,rustc: remove type & lifetime parameter names from the typesystem.,eddyb,NA,NA,NA,THUMBS_UP,2018-08-24T09:12:27Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/53661,CLOSED,2018-08-24T07:21:48Z,2018-10-23T17:16:27Z,rustc: remove type & lifetime parameter names from the typesystem.,eddyb,NA,NA,NA,THUMBS_UP,2018-08-24T12:10:07Z,varkor,NA https://github.com/rust-lang/rust/pull/53664,MERGED,2018-08-24T10:22:50Z,2018-08-24T19:21:59Z,Remove unnecessary closure in rustc_mir/build/mod.rs,IsaacWoods,b24a30e94d19b3ac537665e9b9856f7caabc895f,1,Remove unnecessary closure in rustc_mir/build/mod.rs,THUMBS_UP,2018-08-24T12:46:08Z,bjorn3,NA https://github.com/rust-lang/rust/pull/53666,MERGED,2018-08-24T11:15:01Z,2018-08-24T19:21:59Z,Added rustc_codegen_llvm to compiler documentation.,davidtwco,c802be6f30868a14b6472bcb3160de127cb6ab89,1,Added rustc_codegen_llvm to compiler documentation.,HOORAY,2018-08-24T12:46:23Z,bjorn3,NA https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-08-25T09:54:21Z,lqd,NA https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-08-25T16:38:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-08-27T07:06:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-08-31T22:22:59Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-09-05T07:34:59Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/53671,MERGED,2018-08-24T14:46:16Z,2018-08-29T02:08:14Z,Miri engine cleanup,RalfJung,c9b5fac7da34eaf027ba5dc62b5f7f9605e0b2e9,1,first test const-ness then hook fn call,THUMBS_UP,2018-09-05T18:06:20Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,THUMBS_UP,2018-08-24T16:17:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-08-29T11:40:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HEART,2018-08-29T11:40:59Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-04T01:06:17Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-04T10:45:19Z,mati865,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-05T07:55:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-05T13:06:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,THUMBS_UP,2018-09-05T13:40:57Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-05T18:00:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-06T21:41:50Z,lqd,NA https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,THUMBS_UP,2018-09-07T19:29:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-07T19:29:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HEART,2018-09-07T19:29:41Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53673,MERGED,2018-08-24T15:10:04Z,2018-09-03T16:31:46Z,Enable ThinLTO with incremental compilation.,michaelwoerister,21d05f64aa10fd15208bd6d96599275b044a0636,2,incr.ThinLTO: Do some cleanup and add some logging.,HOORAY,2018-09-08T17:02:18Z,rakenodiax,NA https://github.com/rust-lang/rust/pull/53679,MERGED,2018-08-24T18:17:39Z,2018-08-28T18:41:40Z,add more Cortex-R targets,japaric,521df797d5ca67ef362913621ea2a10aa7c4deaf,1,add the other two targets to the manifest,THUMBS_UP,2018-08-24T18:22:03Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53679,MERGED,2018-08-24T18:17:39Z,2018-08-28T18:41:40Z,add more Cortex-R targets,japaric,521df797d5ca67ef362913621ea2a10aa7c4deaf,1,add the other two targets to the manifest,THUMBS_UP,2018-08-24T18:35:10Z,parched,NA https://github.com/rust-lang/rust/pull/53679,MERGED,2018-08-24T18:17:39Z,2018-08-28T18:41:40Z,add more Cortex-R targets,japaric,521df797d5ca67ef362913621ea2a10aa7c4deaf,1,add the other two targets to the manifest,THUMBS_UP,2018-08-25T00:58:52Z,kenkeiter,ken@kenkeiter.com https://github.com/rust-lang/rust/pull/53685,MERGED,2018-08-24T21:31:21Z,2018-08-30T05:52:11Z,Generalize `async_idents` to all new keywords,alexcrichton,003cab25d7619f1eabb7de01ce6fa1ff3226b511,14,Generalize `async_idents` to all new keywords This commit generalizes the existing `async_idents` lint to easily encompass other identifiers that will be keywords in future editions. The new lint is called `keyword_idents` and the old `async_idents` lint is registered as renamed to this new lint. As a proof of concept the `try` keyword was added to this list as it looks to be listed as a keyword in the 2018 edition only. The `await` keyword was not added as it's not listed as a keyword yet. Closes #53077,HEART,2018-08-24T23:12:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53693,MERGED,2018-08-25T07:59:53Z,2018-09-25T06:06:02Z,Support an explicit annotation for marker traits,scottmcm,3932249249fa56dd1515c487a5a9eb02cb631775,1,Add marker_trait_attr to the unstable book,THUMBS_UP,2018-10-05T09:17:05Z,L-as,me@las.rs https://github.com/rust-lang/rust/pull/53697,MERGED,2018-08-25T10:43:30Z,2018-09-03T20:07:20Z,Add more const int ops,TimDiekmann,4811e5b6c71657772b4c12e6f5cbb5c1624bf669,1,Add missing brace,THUMBS_UP,2018-08-25T14:36:02Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/53697,MERGED,2018-08-25T10:43:30Z,2018-09-03T20:07:20Z,Add more const int ops,TimDiekmann,4811e5b6c71657772b4c12e6f5cbb5c1624bf669,1,Add missing brace,THUMBS_UP,2018-08-26T03:23:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/53697,MERGED,2018-08-25T10:43:30Z,2018-09-03T20:07:20Z,Add more const int ops,TimDiekmann,4811e5b6c71657772b4c12e6f5cbb5c1624bf669,1,Add missing brace,THUMBS_UP,2018-09-05T11:14:10Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/53697,MERGED,2018-08-25T10:43:30Z,2018-09-03T20:07:20Z,Add more const int ops,TimDiekmann,4811e5b6c71657772b4c12e6f5cbb5c1624bf669,1,Add missing brace,THUMBS_UP,2018-09-05T20:22:37Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/53699,MERGED,2018-08-25T13:35:40Z,2018-08-31T17:39:41Z,Fix promotion stability hole in old borrowck,oli-obk,2d2b69d4998ea71674d292af223bcacae8a5df4a,1,Satisfy tidy,LAUGH,2018-09-06T17:01:41Z,mati865,NA https://github.com/rust-lang/rust/pull/53705,MERGED,2018-08-25T20:31:12Z,2018-09-08T16:36:39Z,#53576 Renaming TyAnon -> TyOpaque,ms2300,f4d4faaeedbdb7271221c9b48fd809a5e8469445,9,Fixing tests from anon -> opaque,HEART,2018-08-25T22:15:10Z,varkor,NA https://github.com/rust-lang/rust/pull/53715,MERGED,2018-08-26T08:16:57Z,2018-08-27T01:29:06Z,Include missing tools in the manifest and mark them as unavailable,pietroalbini,dc03139e6610f71a2379f9eebf68c40e1fcaf134,1,Include missing tools in the manifest and mark them as unavailable,HOORAY,2018-08-26T15:23:21Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/53715,MERGED,2018-08-26T08:16:57Z,2018-08-27T01:29:06Z,Include missing tools in the manifest and mark them as unavailable,pietroalbini,dc03139e6610f71a2379f9eebf68c40e1fcaf134,1,Include missing tools in the manifest and mark them as unavailable,HOORAY,2018-08-31T09:26:15Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/53721,MERGED,2018-08-26T13:39:41Z,2018-09-06T09:06:48Z,fix `is_non_exhaustive` confusion between structs and enums,arielb1,ae2ad30bf1f3f924ed9ef977b3d2782f85fe2593,9,move the is_field_list_non_exhaustive flag to VariantDef This completely splits the IS_NON_EXHAUSTIVE flag. No functional changes intended.,HEART,2018-08-28T01:30:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53721,MERGED,2018-08-26T13:39:41Z,2018-09-06T09:06:48Z,fix `is_non_exhaustive` confusion between structs and enums,arielb1,ae2ad30bf1f3f924ed9ef977b3d2782f85fe2593,9,move the is_field_list_non_exhaustive flag to VariantDef This completely splits the IS_NON_EXHAUSTIVE flag. No functional changes intended.,HEART,2018-09-13T16:41:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53751,MERGED,2018-08-28T04:55:30Z,2018-09-14T06:11:17Z,Implement RFC 2302: tuple_struct_self_ctor,F001,2157958b27b7f1cd471533d71c8e09843aec57ad,28,introduce SelfCtor,HEART,2018-09-17T21:27:41Z,estebank,NA https://github.com/rust-lang/rust/pull/53751,MERGED,2018-08-28T04:55:30Z,2018-09-14T06:11:17Z,Implement RFC 2302: tuple_struct_self_ctor,F001,2157958b27b7f1cd471533d71c8e09843aec57ad,28,introduce SelfCtor,HEART,2018-09-20T07:17:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53751,MERGED,2018-08-28T04:55:30Z,2018-09-14T06:11:17Z,Implement RFC 2302: tuple_struct_self_ctor,F001,2157958b27b7f1cd471533d71c8e09843aec57ad,28,introduce SelfCtor,HEART,2018-09-20T14:32:25Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53751,MERGED,2018-08-28T04:55:30Z,2018-09-14T06:11:17Z,Implement RFC 2302: tuple_struct_self_ctor,F001,2157958b27b7f1cd471533d71c8e09843aec57ad,28,introduce SelfCtor,HEART,2018-12-05T18:16:31Z,kgv,NA https://github.com/rust-lang/rust/pull/53751,MERGED,2018-08-28T04:55:30Z,2018-09-14T06:11:17Z,Implement RFC 2302: tuple_struct_self_ctor,F001,2157958b27b7f1cd471533d71c8e09843aec57ad,28,introduce SelfCtor,THUMBS_UP,2018-12-07T22:12:41Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/53754,MERGED,2018-08-28T08:43:55Z,2018-09-16T09:47:17Z,stabilize slice_align_to,RalfJung,f4f114002e2a39494674107eb307770fffe33e95,2,stabilize slice_align_to,THUMBS_UP,2018-09-02T07:05:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53754,MERGED,2018-08-28T08:43:55Z,2018-09-16T09:47:17Z,stabilize slice_align_to,RalfJung,f4f114002e2a39494674107eb307770fffe33e95,2,stabilize slice_align_to,THUMBS_UP,2018-09-29T16:34:05Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/53762,MERGED,2018-08-28T12:45:18Z,2018-09-01T05:44:03Z,Backwards compatibility for tool/clippy lints,flip1995,9cbe5182168e3240234ab368b6d26242cfb42029,2,Fix typo and small mistake,HOORAY,2018-08-28T12:46:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53762,MERGED,2018-08-28T12:45:18Z,2018-09-01T05:44:03Z,Backwards compatibility for tool/clippy lints,flip1995,9cbe5182168e3240234ab368b6d26242cfb42029,2,Fix typo and small mistake,HOORAY,2018-08-28T13:15:45Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/53762,MERGED,2018-08-28T12:45:18Z,2018-09-01T05:44:03Z,Backwards compatibility for tool/clippy lints,flip1995,9cbe5182168e3240234ab368b6d26242cfb42029,2,Fix typo and small mistake,HOORAY,2018-08-28T13:22:58Z,mati865,NA https://github.com/rust-lang/rust/pull/53777,MERGED,2018-08-29T01:39:34Z,2018-09-12T11:27:51Z,Implemented map_or_else for Result,ivanbakel,79408c3f32e605ac6def31cb2849f7f4017c9084,1,Added feature attribute to example code in map_or_else doc,THUMBS_UP,2018-09-03T14:13:07Z,Boscop,NA https://github.com/rust-lang/rust/pull/53777,MERGED,2018-08-29T01:39:34Z,2018-09-12T11:27:51Z,Implemented map_or_else for Result,ivanbakel,79408c3f32e605ac6def31cb2849f7f4017c9084,1,Added feature attribute to example code in map_or_else doc,THUMBS_UP,2018-09-12T13:43:00Z,niklasad1,NA https://github.com/rust-lang/rust/pull/53777,MERGED,2018-08-29T01:39:34Z,2018-09-12T11:27:51Z,Implemented map_or_else for Result,ivanbakel,79408c3f32e605ac6def31cb2849f7f4017c9084,1,Added feature attribute to example code in map_or_else doc,THUMBS_UP,2018-09-20T06:57:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53777,MERGED,2018-08-29T01:39:34Z,2018-09-12T11:27:51Z,Implemented map_or_else for Result,ivanbakel,79408c3f32e605ac6def31cb2849f7f4017c9084,1,Added feature attribute to example code in map_or_else doc,HEART,2020-02-20T02:17:53Z,bilelmoussaoui,bil.elmoussaoui@gmail.com https://github.com/rust-lang/rust/pull/53783,MERGED,2018-08-29T12:45:45Z,2018-09-24T20:07:44Z,Rewrite docs for pointer methods,RalfJung,c197dc467fc18c3923f27c8e57e174497f2e63ed,1,clarify write_bytes a bit,HEART,2018-08-29T13:08:18Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/53783,MERGED,2018-08-29T12:45:45Z,2018-09-24T20:07:44Z,Rewrite docs for pointer methods,RalfJung,c197dc467fc18c3923f27c8e57e174497f2e63ed,1,clarify write_bytes a bit,HEART,2018-08-29T17:42:17Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/53783,MERGED,2018-08-29T12:45:45Z,2018-09-24T20:07:44Z,Rewrite docs for pointer methods,RalfJung,c197dc467fc18c3923f27c8e57e174497f2e63ed,1,clarify write_bytes a bit,HEART,2018-08-30T15:22:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53783,MERGED,2018-08-29T12:45:45Z,2018-09-24T20:07:44Z,Rewrite docs for pointer methods,RalfJung,c197dc467fc18c3923f27c8e57e174497f2e63ed,1,clarify write_bytes a bit,HEART,2018-09-12T15:53:15Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/53784,MERGED,2018-08-29T13:23:48Z,2018-10-01T12:56:50Z,Document that slices cannot be larger than `isize::MAX` bytes,tbu-,e370b1ccaed1f2775e2d944acc2898c98b415083,1,"Don't have two adjacent ""see also"" sentences",HEART,2018-09-17T05:32:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53784,MERGED,2018-08-29T13:23:48Z,2018-10-01T12:56:50Z,Document that slices cannot be larger than `isize::MAX` bytes,tbu-,e370b1ccaed1f2775e2d944acc2898c98b415083,1,"Don't have two adjacent ""see also"" sentences",HEART,2018-10-01T17:25:00Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/53786,MERGED,2018-08-29T13:26:17Z,2018-08-31T05:57:11Z,Replace usages of 'bad_style' with 'nonstandard_style'.,frewsxcv,e477a13d63c2139f39c192c8e22dcfd0810f68e4,31,Replace usages of 'bad_style' with 'nonstandard_style'. `bad_style` is being deprecated in favor of `nonstandard_style`: - https://github.com/rust-lang/rust/issues/41646,THUMBS_UP,2018-08-29T13:32:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/53786,MERGED,2018-08-29T13:26:17Z,2018-08-31T05:57:11Z,Replace usages of 'bad_style' with 'nonstandard_style'.,frewsxcv,e477a13d63c2139f39c192c8e22dcfd0810f68e4,31,Replace usages of 'bad_style' with 'nonstandard_style'. `bad_style` is being deprecated in favor of `nonstandard_style`: - https://github.com/rust-lang/rust/issues/41646,THUMBS_UP,2018-08-31T02:02:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53804,MERGED,2018-08-29T21:14:43Z,2018-09-16T20:28:27Z,fix some uses of pointer intrinsics with invalid pointers,RalfJung,357c5dacee1015dc03583287d0c7a132d9fe7880,1,use mem::zeroed to make up ZST values,HEART,2018-09-02T07:04:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53804,MERGED,2018-08-29T21:14:43Z,2018-09-16T20:28:27Z,fix some uses of pointer intrinsics with invalid pointers,RalfJung,357c5dacee1015dc03583287d0c7a132d9fe7880,1,use mem::zeroed to make up ZST values,HEART,2018-09-19T11:01:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53804,MERGED,2018-08-29T21:14:43Z,2018-09-16T20:28:27Z,fix some uses of pointer intrinsics with invalid pointers,RalfJung,357c5dacee1015dc03583287d0c7a132d9fe7880,1,use mem::zeroed to make up ZST values,HEART,2018-09-20T06:49:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53804,MERGED,2018-08-29T21:14:43Z,2018-09-16T20:28:27Z,fix some uses of pointer intrinsics with invalid pointers,RalfJung,357c5dacee1015dc03583287d0c7a132d9fe7880,1,use mem::zeroed to make up ZST values,HEART,2019-12-06T17:00:22Z,bvinc,brainn@gmail.com https://github.com/rust-lang/rust/pull/53815,MERGED,2018-08-30T04:25:15Z,2018-09-01T22:44:14Z,refactor match guard,F001,7a083ca25f14833d704d2efba5ca9b431f6c65ad,22,introduce Guard enum,THUMBS_UP,2018-09-06T13:17:57Z,mati865,NA https://github.com/rust-lang/rust/pull/53828,MERGED,2018-08-30T16:50:23Z,2018-08-31T01:19:02Z,rustbuild: Distribute libLLVM.so with rustc,alexcrichton,b7a604ab34ac247f13b1f91f8351a0e3c50df52f,1,rustbuild: Distribute libLLVM.so with rustc A recent change (#53245) started to build LLVM with ThinLTO enabled and to ensure that compile times are kept down it builds LLVM dynamically by default to ensure that all the various LLVM tools aren't redoing all that optimization work. This means however that all LLVM tools depend on LLVM's dynamic library by default. While the LLVM tools and LLDB components were updated to include the shared library we accidentally forgot about LLD included with the main rustc component. LLD also links dynamically to LLVM and ships a non-working binary right now because of this! This commit updates our distribution to ship the LLVM dynamic library with the compiler libraries. While not technically needed for rustc itself to operate (right now) it may be needed for LLD and otherwise it serves as a good basis for the other LLVM tools components to work with as well. This should... Closes #53813,HEART,2018-08-31T01:03:42Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/53829,MERGED,2018-08-30T17:29:40Z,2018-09-14T01:07:30Z,Add rustc SHA to released DWARF debuginfo,alexcrichton,5595aeb6b7eda6b96cb2fe882401213c4fc04c6f,14,Add rustc SHA to released DWARF debuginfo This commit updates the debuginfo that is encoded in all of our released artifacts by default. Currently it has paths like `/checkout/src/...` but these are a little inconsistent and have changed over time. This commit instead attempts to actually define the file paths in our debuginfo to be consistent between releases. All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git sha of the released compiler. Sub-paths are all paths into the git repo at that `$sha`.,THUMBS_UP,2018-08-30T17:32:58Z,yurydelendik,ydelendik@mozilla.com https://github.com/rust-lang/rust/pull/53829,MERGED,2018-08-30T17:29:40Z,2018-09-14T01:07:30Z,Add rustc SHA to released DWARF debuginfo,alexcrichton,5595aeb6b7eda6b96cb2fe882401213c4fc04c6f,14,Add rustc SHA to released DWARF debuginfo This commit updates the debuginfo that is encoded in all of our released artifacts by default. Currently it has paths like `/checkout/src/...` but these are a little inconsistent and have changed over time. This commit instead attempts to actually define the file paths in our debuginfo to be consistent between releases. All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git sha of the released compiler. Sub-paths are all paths into the git repo at that `$sha`.,THUMBS_UP,2018-09-26T07:57:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/53830,MERGED,2018-08-30T17:47:19Z,2018-09-07T12:48:36Z,Add help message for missing IndexMut impl with NLL,davidtwco,08a4a376782f31b73f21646a5fcde5c52b6c8c37,4,Omit 'missing IndexMut impl' suggestion when IndexMut is implemented.,THUMBS_UP,2018-09-05T21:59:44Z,lqd,NA https://github.com/rust-lang/rust/pull/53830,MERGED,2018-08-30T17:47:19Z,2018-09-07T12:48:36Z,Add help message for missing IndexMut impl with NLL,davidtwco,08a4a376782f31b73f21646a5fcde5c52b6c8c37,4,Omit 'missing IndexMut impl' suggestion when IndexMut is implemented.,THUMBS_UP,2019-02-14T14:53:17Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/53851,MERGED,2018-08-31T11:54:03Z,2018-10-04T09:17:58Z,Limit the promotion of const fns to the libstd and the `rustc_promotable` attribute,oli-obk,c793391e6d04106df57a4f431c7deeb4258a0592,4,Move platform dependent output ui tests to compile-fail,THUMBS_UP,2018-09-02T11:56:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53873,MERGED,2018-08-31T23:39:23Z,2018-09-11T23:28:51Z,support ascription for patterns in NLL,nikomatsakis,f95f23f0c3f56d40a57b6e5b538aa98fd4f18b0f,1,fix incremental test We are now carrying the user-given type through MIR so it makes sense that this would change the hash.,HOORAY,2018-09-02T07:02:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53873,MERGED,2018-08-31T23:39:23Z,2018-09-11T23:28:51Z,support ascription for patterns in NLL,nikomatsakis,f95f23f0c3f56d40a57b6e5b538aa98fd4f18b0f,1,fix incremental test We are now carrying the user-given type through MIR so it makes sense that this would change the hash.,HOORAY,2018-09-07T13:34:29Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/53873,MERGED,2018-08-31T23:39:23Z,2018-09-11T23:28:51Z,support ascription for patterns in NLL,nikomatsakis,f95f23f0c3f56d40a57b6e5b538aa98fd4f18b0f,1,fix incremental test We are now carrying the user-given type through MIR so it makes sense that this would change the hash.,HOORAY,2018-09-20T08:42:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53877,MERGED,2018-09-01T04:56:23Z,2018-09-19T09:20:47Z,Update to a new pinning API.,withoutboats,574bca7262f0ddab9e1818253012dbff34755b98,1,Cleanup Deref impls and add ?Sized bound to &mut T impls,HEART,2018-09-01T18:16:04Z,cramertj,NA https://github.com/rust-lang/rust/pull/53877,MERGED,2018-09-01T04:56:23Z,2018-09-19T09:20:47Z,Update to a new pinning API.,withoutboats,574bca7262f0ddab9e1818253012dbff34755b98,1,Cleanup Deref impls and add ?Sized bound to &mut T impls,HEART,2018-09-27T05:55:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53877,MERGED,2018-09-01T04:56:23Z,2018-09-19T09:20:47Z,Update to a new pinning API.,withoutboats,574bca7262f0ddab9e1818253012dbff34755b98,1,Cleanup Deref impls and add ?Sized bound to &mut T impls,HEART,2018-09-27T19:16:37Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/53892,CLOSED,2018-09-01T23:00:43Z,2018-09-07T01:24:26Z,Display for SystemTime,stepancheg,NA,NA,NA,THUMBS_UP,2020-09-13T17:38:47Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/53900,MERGED,2018-09-02T09:12:36Z,2018-09-18T09:06:53Z,NLL regresses diagnostic for impl-trait/static-return-lifetime-infered.rs,davidtwco,18c1374bf86bf061a7f5f73fcebea5abc2a80922,1,Update from TyKind::Anon to TyKind::Opaque,HEART,2018-09-04T17:17:07Z,estebank,NA https://github.com/rust-lang/rust/pull/53909,MERGED,2018-09-02T19:48:58Z,2018-09-08T22:20:04Z,Skip a shared borrow of a immutable local variables,mikhail-m1,d0c1e5a99e3a9b0d57e8f1deea3c76bd1fb7c0e9,9,rustfmt src/librustc_mir/build/expr,THUMBS_UP,2018-09-05T05:14:49Z,lqd,NA https://github.com/rust-lang/rust/pull/53909,MERGED,2018-09-02T19:48:58Z,2018-09-08T22:20:04Z,Skip a shared borrow of a immutable local variables,mikhail-m1,d0c1e5a99e3a9b0d57e8f1deea3c76bd1fb7c0e9,9,rustfmt src/librustc_mir/build/expr,THUMBS_UP,2018-09-05T13:35:47Z,orium,NA https://github.com/rust-lang/rust/pull/53909,MERGED,2018-09-02T19:48:58Z,2018-09-08T22:20:04Z,Skip a shared borrow of a immutable local variables,mikhail-m1,d0c1e5a99e3a9b0d57e8f1deea3c76bd1fb7c0e9,9,rustfmt src/librustc_mir/build/expr,THUMBS_UP,2018-09-05T14:57:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53910,MERGED,2018-09-02T21:13:07Z,2018-09-17T01:37:05Z,Move std::os::raw::c_void into libcore and re-export in libstd,IsaacWoods,23e345bc0c79c43753b224ab127f5c06d553e4c4,4,Move std::os::raw::c_void into libcore and re-export in libstd,HOORAY,2018-09-04T23:37:05Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/53910,MERGED,2018-09-02T21:13:07Z,2018-09-17T01:37:05Z,Move std::os::raw::c_void into libcore and re-export in libstd,IsaacWoods,23e345bc0c79c43753b224ab127f5c06d553e4c4,4,Move std::os::raw::c_void into libcore and re-export in libstd,HOORAY,2018-09-05T04:12:09Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/53910,MERGED,2018-09-02T21:13:07Z,2018-09-17T01:37:05Z,Move std::os::raw::c_void into libcore and re-export in libstd,IsaacWoods,23e345bc0c79c43753b224ab127f5c06d553e4c4,4,Move std::os::raw::c_void into libcore and re-export in libstd,HOORAY,2018-09-14T13:38:44Z,levex,lev@boilerplate.co https://github.com/rust-lang/rust/pull/53910,MERGED,2018-09-02T21:13:07Z,2018-09-17T01:37:05Z,Move std::os::raw::c_void into libcore and re-export in libstd,IsaacWoods,23e345bc0c79c43753b224ab127f5c06d553e4c4,4,Move std::os::raw::c_void into libcore and re-export in libstd,HOORAY,2018-09-27T06:14:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53910,MERGED,2018-09-02T21:13:07Z,2018-09-17T01:37:05Z,Move std::os::raw::c_void into libcore and re-export in libstd,IsaacWoods,23e345bc0c79c43753b224ab127f5c06d553e4c4,4,Move std::os::raw::c_void into libcore and re-export in libstd,HEART,2018-09-30T14:48:12Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/53913,MERGED,2018-09-03T02:22:49Z,2018-09-12T01:56:54Z,resolve: Future proof resolutions for potentially built-in attributes,petrochenkov,de153d61f5a4ef8681fc64fc55de2bcfe449c8c4,7,resolve: Reserve a few very special names in macro namespace,HEART,2018-09-03T18:51:29Z,estebank,NA https://github.com/rust-lang/rust/pull/53918,MERGED,2018-09-03T05:29:37Z,2018-11-22T10:04:43Z,Doc total order requirement of sort(_unstable)_by,Havvy,99bed21101ef098393c9e6c8eb64f21892dbc8be,2,Linkify types in docs,THUMBS_UP,2018-09-03T05:31:39Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/53918,MERGED,2018-09-03T05:29:37Z,2018-11-22T10:04:43Z,Doc total order requirement of sort(_unstable)_by,Havvy,99bed21101ef098393c9e6c8eb64f21892dbc8be,2,Linkify types in docs,THUMBS_UP,2018-09-03T06:46:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53930,CLOSED,2018-09-03T19:00:43Z,2018-09-09T16:55:14Z,proc_macro::Span::len and subspan,dtolnay,NA,NA,NA,HOORAY,2018-09-03T19:20:25Z,parched,NA https://github.com/rust-lang/rust/pull/53931,MERGED,2018-09-03T19:22:43Z,2018-10-25T17:44:36Z,Gradually expanding libstd's keyword documentation,iirelu,320ec8137e90bf6dd13b62df033372a33f261bb8,1,Hopefully fix compile error This was added in the fortnight this PR spent stale. I'm hoping this one-liner fixes it.,HEART,2018-09-03T19:25:56Z,killercup,NA https://github.com/rust-lang/rust/pull/53931,MERGED,2018-09-03T19:22:43Z,2018-10-25T17:44:36Z,Gradually expanding libstd's keyword documentation,iirelu,320ec8137e90bf6dd13b62df033372a33f261bb8,1,Hopefully fix compile error This was added in the fortnight this PR spent stale. I'm hoping this one-liner fixes it.,HEART,2018-09-03T20:28:33Z,crepererum,marco@crepererum.net https://github.com/rust-lang/rust/pull/53931,MERGED,2018-09-03T19:22:43Z,2018-10-25T17:44:36Z,Gradually expanding libstd's keyword documentation,iirelu,320ec8137e90bf6dd13b62df033372a33f261bb8,1,Hopefully fix compile error This was added in the fortnight this PR spent stale. I'm hoping this one-liner fixes it.,HEART,2018-09-04T02:41:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/53931,MERGED,2018-09-03T19:22:43Z,2018-10-25T17:44:36Z,Gradually expanding libstd's keyword documentation,iirelu,320ec8137e90bf6dd13b62df033372a33f261bb8,1,Hopefully fix compile error This was added in the fortnight this PR spent stale. I'm hoping this one-liner fixes it.,HEART,2018-10-22T00:59:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2018-09-04T10:42:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2018-09-04T10:43:09Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2018-09-05T00:02:46Z,est31,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HEART,2018-09-05T18:43:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2018-09-05T18:43:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2018-10-25T06:04:38Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HOORAY,2018-10-25T06:05:52Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HEART,2018-10-25T06:05:53Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HEART,2019-06-17T23:43:48Z,twitzelbos,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,THUMBS_UP,2019-07-20T18:22:25Z,bermanboris,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HOORAY,2019-07-20T18:22:26Z,bermanboris,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HEART,2019-07-20T18:22:28Z,bermanboris,NA https://github.com/rust-lang/rust/pull/53938,CLOSED,2018-09-04T06:48:50Z,2018-11-07T17:34:19Z,Add a total ordering method for floating-point,scottmcm,NA,NA,NA,HEART,2019-09-18T21:23:14Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/53942,MERGED,2018-09-04T09:26:15Z,2018-09-08T14:16:42Z,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.,nnethercote,fb307e529d217c6602c1c0359b14947b6897265c,1,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`.,HEART,2018-09-04T15:23:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/53942,MERGED,2018-09-04T09:26:15Z,2018-09-08T14:16:42Z,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.,nnethercote,fb307e529d217c6602c1c0359b14947b6897265c,1,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`.,HEART,2018-09-05T21:09:11Z,lqd,NA https://github.com/rust-lang/rust/pull/53942,MERGED,2018-09-04T09:26:15Z,2018-09-08T14:16:42Z,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.,nnethercote,fb307e529d217c6602c1c0359b14947b6897265c,1,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`.,THUMBS_UP,2018-09-05T21:09:17Z,lqd,NA https://github.com/rust-lang/rust/pull/53942,MERGED,2018-09-04T09:26:15Z,2018-09-08T14:16:42Z,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.,nnethercote,fb307e529d217c6602c1c0359b14947b6897265c,1,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`.,THUMBS_UP,2018-09-13T16:43:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53942,MERGED,2018-09-04T09:26:15Z,2018-09-08T14:16:42Z,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.,nnethercote,fb307e529d217c6602c1c0359b14947b6897265c,1,Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups. It now does one hash table lookup per basic block instead of one per statement. This is worthwhile because this function is hot for NLL builds of `ucd`.,HEART,2018-11-06T13:51:15Z,mrtnbroder,NA https://github.com/rust-lang/rust/pull/53949,MERGED,2018-09-04T15:12:25Z,2018-09-09T04:00:35Z,Improve messages for un-closed delimiter errors,estebank,3192d3dc0c4417a6e360018b341c07d32f3f3d7f,6,Change wording of unclosed delimiter label,HEART,2018-09-04T15:14:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53949,MERGED,2018-09-04T15:12:25Z,2018-09-09T04:00:35Z,Improve messages for un-closed delimiter errors,estebank,3192d3dc0c4417a6e360018b341c07d32f3f3d7f,6,Change wording of unclosed delimiter label,HEART,2018-09-08T10:57:24Z,killercup,NA https://github.com/rust-lang/rust/pull/53955,MERGED,2018-09-04T20:13:56Z,2018-09-06T04:32:45Z,rustbuild: Tweak LLVM distribution layout,alexcrichton,bce09b6e34d97a4d71771c6283f25f6199e8e5c7,1,rustbuild: Tweak LLVM distribution layout This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic library which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools at runtime need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located however at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately though this directive is only correct for the LLVM tools at `$sysroot/bin` not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes #53813,HOORAY,2018-09-05T13:18:04Z,twilco,tyler.wilcock@protonmail.com https://github.com/rust-lang/rust/pull/53955,MERGED,2018-09-04T20:13:56Z,2018-09-06T04:32:45Z,rustbuild: Tweak LLVM distribution layout,alexcrichton,bce09b6e34d97a4d71771c6283f25f6199e8e5c7,1,rustbuild: Tweak LLVM distribution layout This commit tweaks the layout of a few components that we distribute to hopefully fix across all platforms the recent issues with LLD being unable to find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic library which means that LLVM tools by default link to LLVM dynamically rather than statically. This in turn means that the tools at runtime need to find the LLVM shared library. LLVM's shared library is currently distributed as part of the rustc component. This library is located however at `$sysroot/lib`. The LLVM tools we ship are in two locations: * LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld` * Other LLVM tools are shipped at `$sysroot/bin` Each LLVM tool has an embedded rpath directive indicating where it will search for dynamic libraries. This currently points to `../lib` and is presumably inserted by LLVM's build system. Unfortunately though this directive is only correct for the LLVM tools at `$sysroot/bin` not LLD! This commit is targeted at fixing this situation by making two changes: * LLVM tools other than LLD are moved in the distribution to `$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should position them for... * The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib` Together this means that all tools should natively be able to find the shared object and the shared object should be installed all the time for the various tools. Overall this should... Closes #53813,HOORAY,2018-09-13T16:50:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53966,MERGED,2018-09-05T15:39:54Z,2018-09-07T15:15:13Z,A few cleanups and minor improvements to mir/dataflow,ljedrz,b7c0d32c5f53d748dc3d05672dedc71dc786970a,4,A few cleanups and minor improvements to mir/dataflow,HEART,2018-09-05T16:33:03Z,estebank,NA https://github.com/rust-lang/rust/pull/53979,MERGED,2018-09-05T22:42:38Z,2018-09-07T15:15:15Z,Remove `#[repr(transparent)]` from atomics,alexcrichton,0338d340c4ad64dde20dfa5ab8b983861e58c631,1,Remove `#[repr(transparent)]` from atomics Added in #52149 the discussion in #53514 is showing how we may not want to actually add this attribute to the atomic types. While we continue to debate #53514 this commit reverts the addition of the `transparent` attribute. This should be a more conservative route which leaves us the ability to tweak this in the future but in the meantime allows us to continue discussion as well.,THUMBS_UP,2018-09-06T09:38:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/53981,MERGED,2018-09-06T03:13:58Z,2018-09-08T14:16:44Z,Implement initializer() for FileDesc,fbernier,28745a6e190a8c61ba2f08b03ea8afed620c9735,1,Implement initializer() for FileDesc in order to avoid constantly zeroing memory when it's not needed.,THUMBS_UP,2018-09-07T20:55:59Z,Yoshiji,NA https://github.com/rust-lang/rust/pull/53981,MERGED,2018-09-06T03:13:58Z,2018-09-08T14:16:44Z,Implement initializer() for FileDesc,fbernier,28745a6e190a8c61ba2f08b03ea8afed620c9735,1,Implement initializer() for FileDesc in order to avoid constantly zeroing memory when it's not needed.,THUMBS_UP,2018-10-26T13:43:21Z,pjhades,NA https://github.com/rust-lang/rust/pull/53987,MERGED,2018-09-06T10:28:46Z,2018-09-08T14:16:44Z,rustbuild: allow configuring llvm version suffix,Keruspe,ef440686131096e08635df418a70507bfc621a30,3,rustbuild: allow configuring llvm version suffix Signed-off-by: Marc-Antoine Perennou ,THUMBS_UP,2018-09-06T16:46:53Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/53988,MERGED,2018-09-06T10:34:50Z,2018-09-09T08:54:39Z,rustc_resolve: only prepend CrateRoot to a non-keyword segment.,eddyb,e0e7cf303ba2fd63763e6d99a9d67dced1fac8ab,2,rustc_resolve: only prepend CrateRoot to a non-keyword segment.,HEART,2018-09-06T17:11:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/53988,MERGED,2018-09-06T10:34:50Z,2018-09-09T08:54:39Z,rustc_resolve: only prepend CrateRoot to a non-keyword segment.,eddyb,e0e7cf303ba2fd63763e6d99a9d67dced1fac8ab,2,rustc_resolve: only prepend CrateRoot to a non-keyword segment.,HEART,2018-09-06T22:51:14Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53995,MERGED,2018-09-06T13:56:06Z,2018-09-19T02:37:49Z,NLL: Deduplicate errors for incorrect move in loop,davidtwco,88ca3412e238d2d6b738ff5e81fa123e33fcc9ae,2,Switched from FxHashMap to BTreeMap to preserve ordering when iterating.,THUMBS_UP,2018-09-06T23:35:41Z,lqd,NA https://github.com/rust-lang/rust/pull/53995,MERGED,2018-09-06T13:56:06Z,2018-09-19T02:37:49Z,NLL: Deduplicate errors for incorrect move in loop,davidtwco,88ca3412e238d2d6b738ff5e81fa123e33fcc9ae,2,Switched from FxHashMap to BTreeMap to preserve ordering when iterating.,THUMBS_UP,2018-09-19T06:31:46Z,estebank,NA https://github.com/rust-lang/rust/pull/53995,MERGED,2018-09-06T13:56:06Z,2018-09-19T02:37:49Z,NLL: Deduplicate errors for incorrect move in loop,davidtwco,88ca3412e238d2d6b738ff5e81fa123e33fcc9ae,2,Switched from FxHashMap to BTreeMap to preserve ordering when iterating.,THUMBS_UP,2018-09-27T05:59:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T17:02:03Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T17:05:44Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T17:11:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T17:12:19Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T17:29:48Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-06T18:50:21Z,lqd,NA https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-07T01:59:59Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,THUMBS_DOWN,2018-09-07T02:32:43Z,retep998,NA https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-07T05:58:01Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-07T13:46:41Z,oli-obk,NA https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-07T14:18:18Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/53999,CLOSED,2018-09-06T16:59:25Z,2018-09-08T20:27:42Z,Stabilize 2018 edition,Mark-Simulacrum,NA,NA,NA,HOORAY,2018-09-08T01:02:07Z,mati865,NA https://github.com/rust-lang/rust/pull/54000,MERGED,2018-09-06T18:04:41Z,2018-09-10T15:42:26Z,Allow named lifetimes in async functions.,jkozlowski,4b7f2eb947b62974d72f9d14738c784a8a1a2095,2,Fixup whitespace,HEART,2018-09-06T18:18:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/54000,MERGED,2018-09-06T18:04:41Z,2018-09-10T15:42:26Z,Allow named lifetimes in async functions.,jkozlowski,4b7f2eb947b62974d72f9d14738c784a8a1a2095,2,Fixup whitespace,HEART,2018-09-20T06:59:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-06T18:56:39Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-09-06T18:56:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-06T19:01:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-09-06T19:01:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-06T19:04:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-09-06T19:55:12Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-06T20:53:24Z,lqd,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-06T22:36:35Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-07T01:22:59Z,est31,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-09-07T01:23:00Z,est31,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-07T01:33:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-09-07T01:33:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-07T04:52:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-07T09:36:10Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-07T13:12:24Z,cynecx,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-22T22:09:04Z,estebank,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-09-30T00:36:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-10-01T09:45:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-10-31T06:06:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-10-31T06:55:16Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-11-07T18:31:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HOORAY,2018-11-07T19:41:55Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-11-07T20:15:15Z,choudanu4,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,HEART,2018-11-08T14:35:05Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54004,MERGED,2018-09-06T18:50:15Z,2018-10-31T02:18:22Z,Fix DWARF generation for enums,tromey,98b26888e552cf498518a6d34538302dc41ac6ae,1,Update lldb Update src/tools/lldb to pick up a needed bug fix in the DW_TAG_variant_part handling.,THUMBS_UP,2018-11-11T07:16:58Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HEART,2018-09-06T19:13:57Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HOORAY,2018-09-06T19:13:59Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HOORAY,2018-09-06T19:24:22Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HEART,2018-09-06T19:24:23Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HOORAY,2018-09-06T20:08:39Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54005,MERGED,2018-09-06T19:13:00Z,2018-09-07T01:49:54Z,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,eddyb,31fce914b27497addbbc9f8235fdecc0962f2f98,4,rustc_resolve: allow `use crate_name;` under `uniform_paths`.,HEART,2018-09-06T20:10:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54011,MERGED,2018-09-06T22:04:34Z,2018-09-10T12:58:19Z,rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate on Rust 2018.,eddyb,d5da94a3b1e635eeb9520b87f6414ff3c24c8602,4,rustc_resolve: ignore uniform_paths canaries that resolve to an import of the same crate.,HEART,2018-09-06T22:07:11Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/54011,MERGED,2018-09-06T22:04:34Z,2018-09-10T12:58:19Z,rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate on Rust 2018.,eddyb,d5da94a3b1e635eeb9520b87f6414ff3c24c8602,4,rustc_resolve: ignore uniform_paths canaries that resolve to an import of the same crate.,HEART,2018-09-06T22:20:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54011,MERGED,2018-09-06T22:04:34Z,2018-09-10T12:58:19Z,rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate on Rust 2018.,eddyb,d5da94a3b1e635eeb9520b87f6414ff3c24c8602,4,rustc_resolve: ignore uniform_paths canaries that resolve to an import of the same crate.,HEART,2018-09-07T12:33:45Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-06T22:13:40Z,lqd,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-06T22:36:35Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-06T22:49:05Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-06T22:52:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-07T00:09:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-07T03:43:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-07T14:27:55Z,estebank,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-08T06:20:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-09T20:59:42Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-09-28T12:24:01Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-10-15T02:41:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-10-23T16:30:09Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/54012,CLOSED,2018-09-06T22:11:00Z,2018-11-04T17:36:31Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,denismerigoux,NA,NA,NA,HOORAY,2018-10-24T23:44:58Z,gabi-250,NA https://github.com/rust-lang/rust/pull/54029,CLOSED,2018-09-07T10:49:11Z,2018-10-16T17:31:21Z,Try to recover from unmatched delimiters in the parser,estebank,NA,NA,NA,HEART,2018-09-08T10:57:20Z,killercup,NA https://github.com/rust-lang/rust/pull/54033,CLOSED,2018-09-07T15:42:56Z,2018-10-24T20:08:05Z,[WIP] rustc_typeck: check well-formedness of type aliases.,eddyb,NA,NA,NA,HEART,2018-09-07T20:34:27Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54034,MERGED,2018-09-07T15:54:40Z,2018-09-18T14:25:08Z,Add feature to enable bind by move pattern guards,pnkfelix,3a07d3dbd6cdb2014369935b62b36c64d6c580a6,5,On nightly with NLL suggest `#![feature(bind_by_move_pattern_guards)]` when it might fix the code.,HOORAY,2018-09-08T14:46:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/54034,MERGED,2018-09-07T15:54:40Z,2018-09-18T14:25:08Z,Add feature to enable bind by move pattern guards,pnkfelix,3a07d3dbd6cdb2014369935b62b36c64d6c580a6,5,On nightly with NLL suggest `#![feature(bind_by_move_pattern_guards)]` when it might fix the code.,HOORAY,2018-09-18T01:17:02Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/54043,MERGED,2018-09-07T20:50:42Z,2018-11-02T09:46:24Z,Add raw_entry API to HashMap,fintelia,daf5bd564a0eb8ff7784f85a015cbe4f06ac162e,1,A couple suggested edits,HEART,2018-11-08T07:38:18Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/54046,MERGED,2018-09-07T23:32:41Z,2018-09-12T11:27:57Z,Update documentation for fill_buf in std::io::BufRead,illfygli,aa4f73c845f29188acf51a42db7d3d86b827cb6f,1,Update documentation for fill_buf in std::io::BufRead Brings the documentation in line with the BufReader implementation. Fixes #48022.,HEART,2018-09-08T01:59:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54046,MERGED,2018-09-07T23:32:41Z,2018-09-12T11:27:57Z,Update documentation for fill_buf in std::io::BufRead,illfygli,aa4f73c845f29188acf51a42db7d3d86b827cb6f,1,Update documentation for fill_buf in std::io::BufRead Brings the documentation in line with the BufReader implementation. Fixes #48022.,HEART,2018-09-12T14:39:20Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/54058,MERGED,2018-09-08T13:49:47Z,2018-09-26T01:16:07Z,Introduce the partition_dedup/by/by_key methods for slices,Kerollmops,d560292a87a89587e0345e13b9714c90495ea50f,2,Make the `Vec::dedup` method use `slice::partition_dedup` internally,HEART,2018-09-29T13:06:29Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/54058,MERGED,2018-09-08T13:49:47Z,2018-09-26T01:16:07Z,Introduce the partition_dedup/by/by_key methods for slices,Kerollmops,d560292a87a89587e0345e13b9714c90495ea50f,2,Make the `Vec::dedup` method use `slice::partition_dedup` internally,CONFUSED,2018-10-03T18:31:14Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/54058,MERGED,2018-09-08T13:49:47Z,2018-09-26T01:16:07Z,Introduce the partition_dedup/by/by_key methods for slices,Kerollmops,d560292a87a89587e0345e13b9714c90495ea50f,2,Make the `Vec::dedup` method use `slice::partition_dedup` internally,THUMBS_UP,2020-10-02T19:37:02Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/54080,MERGED,2018-09-09T12:08:50Z,2018-09-14T15:45:20Z,Addressed #53692 : Don't suggest extra clone when converting cloned slice to Vec,PramodBisht,af09bf9293ed89b93662bad02006bcabde587a16,3,53692: Addressed Estebank's Nits,THUMBS_UP,2018-09-09T13:50:09Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/54080,MERGED,2018-09-09T12:08:50Z,2018-09-14T15:45:20Z,Addressed #53692 : Don't suggest extra clone when converting cloned slice to Vec,PramodBisht,af09bf9293ed89b93662bad02006bcabde587a16,3,53692: Addressed Estebank's Nits,THUMBS_UP,2018-09-09T14:08:09Z,sunjay,NA https://github.com/rust-lang/rust/pull/54080,MERGED,2018-09-09T12:08:50Z,2018-09-14T15:45:20Z,Addressed #53692 : Don't suggest extra clone when converting cloned slice to Vec,PramodBisht,af09bf9293ed89b93662bad02006bcabde587a16,3,53692: Addressed Estebank's Nits,THUMBS_UP,2018-09-19T10:52:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/54080,MERGED,2018-09-09T12:08:50Z,2018-09-14T15:45:20Z,Addressed #53692 : Don't suggest extra clone when converting cloned slice to Vec,PramodBisht,af09bf9293ed89b93662bad02006bcabde587a16,3,53692: Addressed Estebank's Nits,THUMBS_UP,2018-09-20T06:47:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54092,MERGED,2018-09-09T21:58:00Z,2018-09-11T03:36:10Z,Don't compute padding of braces unless they are unmatched,estebank,014a56ca9c0ad4b0ab1e377a66236242b4329413,2,Don't compute padding of braces unless they are unmatched,THUMBS_UP,2018-09-20T06:46:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54111,MERGED,2018-09-10T21:21:43Z,2018-09-11T18:19:02Z,warn about keywords in macro invocations,nikomatsakis,0cd8e0d03edcdc3fc7d74bdb149e91a4d0b0cbd1,3,we now successfully warn about `async` in macro invocations,HEART,2018-09-10T22:38:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54116,MERGED,2018-09-11T01:19:02Z,2018-09-15T22:14:39Z,rustc_resolve: allow only core std meta and --extern in Rust 2018 paths.,eddyb,bde0a54737653776ce271ec38f65f07fe1bd4388,1,"Revert ""Auto merge of #53527 - Emerentius:test_all r=nrc"" This reverts commit 9f53c87b4b1f097e111c9525d60470ed22631018 reversing changes made to cba0fdf43c22795822e1d7c751a69e6c85007221.",HEART,2018-09-13T21:00:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54116,MERGED,2018-09-11T01:19:02Z,2018-09-15T22:14:39Z,rustc_resolve: allow only core std meta and --extern in Rust 2018 paths.,eddyb,bde0a54737653776ce271ec38f65f07fe1bd4388,1,"Revert ""Auto merge of #53527 - Emerentius:test_all r=nrc"" This reverts commit 9f53c87b4b1f097e111c9525d60470ed22631018 reversing changes made to cba0fdf43c22795822e1d7c751a69e6c85007221.",HEART,2018-09-15T15:12:07Z,lqd,NA https://github.com/rust-lang/rust/pull/54116,MERGED,2018-09-11T01:19:02Z,2018-09-15T22:14:39Z,rustc_resolve: allow only core std meta and --extern in Rust 2018 paths.,eddyb,bde0a54737653776ce271ec38f65f07fe1bd4388,1,"Revert ""Auto merge of #53527 - Emerentius:test_all r=nrc"" This reverts commit 9f53c87b4b1f097e111c9525d60470ed22631018 reversing changes made to cba0fdf43c22795822e1d7c751a69e6c85007221.",HEART,2018-09-19T12:27:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/54139,CLOSED,2018-09-11T20:50:32Z,2018-09-13T14:42:41Z,[WIP] migrate more of src/test/run-pass to src/test/ui/run-pass,pnkfelix,NA,NA,NA,THUMBS_UP,2018-09-12T14:31:49Z,lqd,NA https://github.com/rust-lang/rust/pull/54152,MERGED,2018-09-12T10:50:11Z,2018-09-12T21:20:23Z,Really make CGU names unique across crates.,michaelwoerister,3beb762dcf2ff721f2c30534ab6ce6b94c3aebaf,6,Really make CGU names unique across crates.,HOORAY,2018-09-12T16:58:08Z,cramertj,NA https://github.com/rust-lang/rust/pull/54157,MERGED,2018-09-12T18:19:23Z,2018-09-16T12:13:50Z,"use structured suggestion for ""missing mut"" label",euclio,d871b8ad4ab15b7003cd6aad4b5f361ef6d35fd8,77,"use structured suggestion for ""missing mut"" label Fixes #54133.",HEART,2018-09-12T18:26:46Z,estebank,NA https://github.com/rust-lang/rust/pull/54157,MERGED,2018-09-12T18:19:23Z,2018-09-16T12:13:50Z,"use structured suggestion for ""missing mut"" label",euclio,d871b8ad4ab15b7003cd6aad4b5f361ef6d35fd8,77,"use structured suggestion for ""missing mut"" label Fixes #54133.",HEART,2018-09-12T21:55:30Z,killercup,NA https://github.com/rust-lang/rust/pull/54157,MERGED,2018-09-12T18:19:23Z,2018-09-16T12:13:50Z,"use structured suggestion for ""missing mut"" label",euclio,d871b8ad4ab15b7003cd6aad4b5f361ef6d35fd8,77,"use structured suggestion for ""missing mut"" label Fixes #54133.",HEART,2018-09-20T08:02:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54161,CLOSED,2018-09-12T21:27:33Z,2018-10-12T22:05:55Z,WIP: Suggest method names when mistyping trait methods,ereslibre,NA,NA,NA,THUMBS_UP,2018-09-12T22:45:42Z,estebank,NA https://github.com/rust-lang/rust/pull/54164,MERGED,2018-09-12T23:05:05Z,2018-09-26T03:46:04Z,"add ""temporary value borrowed for too long"" error",mikhail-m1,2af199d58e10374d907d26b671c8b1c2e84ebf9a,34,Update E0714 to E0716 in tests output,HEART,2018-09-14T17:56:10Z,estebank,NA https://github.com/rust-lang/rust/pull/54173,MERGED,2018-09-13T06:48:08Z,2018-09-14T09:47:20Z,Suggest valid crate type if invalid crate type is found,phansch,7249a1b1ae075e3a955fda69cdea5161d0eb1aa5,4,Suggest valid crate type if invalid This adds a suggestion to the `invalid_crate_types` lint. The suggestion is based on the Levenshtein distance to existing crate types. If no suggestion is found it will show the lint without any suggestions.,HEART,2018-09-13T16:52:07Z,estebank,NA https://github.com/rust-lang/rust/pull/54181,MERGED,2018-09-13T13:05:45Z,2018-09-16T18:03:53Z,Suggest && and || instead of 'and' and 'or',vi,bc63a4a13a442e1844bb5577adcc464c2a6bfd21,2,issue 54109: use short suggestions,THUMBS_UP,2018-09-14T19:46:08Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54181,MERGED,2018-09-13T13:05:45Z,2018-09-16T18:03:53Z,Suggest && and || instead of 'and' and 'or',vi,bc63a4a13a442e1844bb5577adcc464c2a6bfd21,2,issue 54109: use short suggestions,THUMBS_UP,2018-09-21T20:08:59Z,estebank,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-13T14:28:19Z,cramertj,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-13T23:57:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-16T13:24:51Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-20T03:23:46Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-22T11:28:35Z,hban,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-09-25T18:17:27Z,cynecx,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-01T15:07:19Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-01T16:50:25Z,sfackler,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-17T18:33:05Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-20T03:42:04Z,tinaun,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-23T19:53:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-27T12:05:56Z,rhysd,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-27T23:56:36Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-29T04:55:16Z,sinkuu,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-31T17:08:28Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-10-31T18:16:40Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-01T00:42:58Z,durka,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-01T03:55:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-01T09:24:33Z,hcpl,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-01T14:05:58Z,Vurich,NA https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-03T00:39:50Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2018-11-03T14:18:06Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/54183,MERGED,2018-09-13T13:40:34Z,2018-10-27T22:17:05Z,Implement by-value object safety,qnighy,2f7ea4a8725d433db4f34fca87eb7f61afb7ef9a,7,Add more tests on unsized locals autoderef and borrowck.,HOORAY,2019-03-17T06:41:16Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/54199,MERGED,2018-09-13T19:53:38Z,2018-09-26T15:40:50Z,overlook overflows in rustdoc trait solving,nikomatsakis,a3997f72556855a175bd5447993c7361ddedb194,1,add regression test,HOORAY,2018-09-25T19:10:27Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/54199,MERGED,2018-09-13T19:53:38Z,2018-09-26T15:40:50Z,overlook overflows in rustdoc trait solving,nikomatsakis,a3997f72556855a175bd5447993c7361ddedb194,1,add regression test,HOORAY,2018-09-28T13:00:57Z,Vurich,NA https://github.com/rust-lang/rust/pull/54210,MERGED,2018-09-14T01:36:06Z,2018-09-14T09:47:23Z,Update Cargo,alexcrichton,7a1eed73be3e420cf3b3fc9f5cadd64725a17c9f,1,Update Cargo Should bring in some nice progress bars for compilations!,HOORAY,2018-09-14T02:05:26Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54210,MERGED,2018-09-14T01:36:06Z,2018-09-14T09:47:23Z,Update Cargo,alexcrichton,7a1eed73be3e420cf3b3fc9f5cadd64725a17c9f,1,Update Cargo Should bring in some nice progress bars for compilations!,LAUGH,2018-09-14T02:36:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/54211,MERGED,2018-09-14T03:02:56Z,2018-09-20T02:52:09Z,Split `Liveness::users` into three.,nnethercote,efae70c73621046d5ba33a341bfc6e4100c32945,1,Split `Liveness::users` into three. This reduces memory usage on some benchmarks because no space is wasted for padding. For a `check-clean` build of `keccak` it reduces `max-rss` by 20%.,THUMBS_UP,2018-09-18T18:44:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54211,MERGED,2018-09-14T03:02:56Z,2018-09-20T02:52:09Z,Split `Liveness::users` into three.,nnethercote,efae70c73621046d5ba33a341bfc6e4100c32945,1,Split `Liveness::users` into three. This reduces memory usage on some benchmarks because no space is wasted for padding. For a `check-clean` build of `keccak` it reduces `max-rss` by 20%.,THUMBS_UP,2018-09-27T06:00:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54213,MERGED,2018-09-14T05:02:31Z,2018-09-16T18:03:55Z,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`.,nnethercote,aa9aca0d3d6aa371691d226bd41b4dd4af083a46,1,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`. This reduces `max-rss` for an `nll-check` build by 27% for `keccak` and by 8% for `inflate`.,HEART,2018-09-14T05:16:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54213,MERGED,2018-09-14T05:02:31Z,2018-09-16T18:03:55Z,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`.,nnethercote,aa9aca0d3d6aa371691d226bd41b4dd4af083a46,1,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`. This reduces `max-rss` for an `nll-check` build by 27% for `keccak` and by 8% for `inflate`.,HEART,2018-09-14T23:51:53Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54213,MERGED,2018-09-14T05:02:31Z,2018-09-16T18:03:55Z,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`.,nnethercote,aa9aca0d3d6aa371691d226bd41b4dd4af083a46,1,De-overlap the lifetimes of `flow_inits` and `flow_{un ever_}inits`. This reduces `max-rss` for an `nll-check` build by 27% for `keccak` and by 8% for `inflate`.,HEART,2018-09-20T07:16:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54219,CLOSED,2018-09-14T09:30:52Z,2018-10-23T14:07:16Z,Introduce the `Result::into_inner` method,Kerollmops,NA,NA,NA,CONFUSED,2018-09-15T07:50:01Z,kennytm,NA https://github.com/rust-lang/rust/pull/54219,CLOSED,2018-09-14T09:30:52Z,2018-10-23T14:07:16Z,Introduce the `Result::into_inner` method,Kerollmops,NA,NA,NA,THUMBS_DOWN,2018-10-11T07:50:14Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/54219,CLOSED,2018-09-14T09:30:52Z,2018-10-23T14:07:16Z,Introduce the `Result::into_inner` method,Kerollmops,NA,NA,NA,CONFUSED,2018-10-17T23:25:11Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/54219,CLOSED,2018-09-14T09:30:52Z,2018-10-23T14:07:16Z,Introduce the `Result::into_inner` method,Kerollmops,NA,NA,NA,THUMBS_DOWN,2018-10-17T23:25:11Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/54219,CLOSED,2018-09-14T09:30:52Z,2018-10-23T14:07:16Z,Introduce the `Result::into_inner` method,Kerollmops,NA,NA,NA,CONFUSED,2018-10-20T14:58:06Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/54228,CLOSED,2018-09-14T12:57:47Z,2018-09-16T12:44:02Z,[Do not merge] Rename mpsc_select feature to break its users on Crater,SimonSapin,NA,NA,NA,HEART,2018-09-14T16:49:17Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/54229,MERGED,2018-09-14T13:48:37Z,2018-09-23T17:49:31Z,[nll] borrows that must be valid for a free lifetime should explain why,davidtwco,b342f0017931180097f17905da8640f674165255,9,Only annotate if borrow is returned. Error now correctly checks whether the borrow that does not live long enough is being returned before annotating the error with the arguments and return type from the signature - as this would not be relevant if the borrow was not being returned.,HEART,2018-09-14T17:52:05Z,estebank,NA https://github.com/rust-lang/rust/pull/54229,MERGED,2018-09-14T13:48:37Z,2018-09-23T17:49:31Z,[nll] borrows that must be valid for a free lifetime should explain why,davidtwco,b342f0017931180097f17905da8640f674165255,9,Only annotate if borrow is returned. Error now correctly checks whether the borrow that does not live long enough is being returned before annotating the error with the arguments and return type from the signature - as this would not be relevant if the borrow was not being returned.,THUMBS_UP,2018-09-14T23:35:02Z,lqd,NA https://github.com/rust-lang/rust/pull/54240,MERGED,2018-09-15T01:49:02Z,2018-09-29T22:20:10Z,Impl From> for T,csmoe,95c1d817ae6ec50d3c636c54e33b4d51cab57148,2,move from_nonzero test from run-pass to libcore,THUMBS_UP,2018-09-17T04:33:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54241,MERGED,2018-09-15T02:40:09Z,2018-09-20T09:03:01Z,Remove usages of span_suggestion without Applicability,vi,d0790c490a2233d04375072123e70ed158eb3848,14,Whitespace fix again.,HOORAY,2018-09-17T09:52:37Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54241,MERGED,2018-09-15T02:40:09Z,2018-09-20T09:03:01Z,Remove usages of span_suggestion without Applicability,vi,d0790c490a2233d04375072123e70ed158eb3848,14,Whitespace fix again.,HOORAY,2018-09-17T21:50:00Z,estebank,NA https://github.com/rust-lang/rust/pull/54241,MERGED,2018-09-15T02:40:09Z,2018-09-20T09:03:01Z,Remove usages of span_suggestion without Applicability,vi,d0790c490a2233d04375072123e70ed158eb3848,14,Whitespace fix again.,HOORAY,2018-09-20T09:05:28Z,killercup,NA https://github.com/rust-lang/rust/pull/54261,MERGED,2018-09-15T17:25:49Z,2018-09-22T17:00:44Z,Make `dyn` a keyword in the 2018 edition,varkor,cb594cf3730c35fd6c514e98d9c7a0d78a00a02d,9,Treat `dyn` as a keyword in the 2018 edition,THUMBS_UP,2018-09-15T20:11:41Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/54265,MERGED,2018-09-15T20:33:25Z,2018-09-22T14:26:31Z,avoid leaking host details in proc macro metadata decoding,arielb1,1b938068b601ffa211e5503f565d082d78ebcd14,1,Ignore new test on Windows,HEART,2018-09-19T13:44:03Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/54266,MERGED,2018-09-15T20:34:49Z,2018-09-21T01:16:25Z,"Update LLVM to fix ""bool"" arguments on PPC32",LionNatsu,ad8053fe73d39fb7fb7e6d052f0bd005dae31686,2,"Update LLVM to fix ""bool"" arguments on PPC32 Fixes #50960.",HEART,2018-09-16T03:43:07Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/54271,MERGED,2018-09-16T10:33:45Z,2018-12-07T03:11:34Z,Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes,petrochenkov,8ab115c21d5309ecf486a517d52deaa56522c823,19,Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes,HOORAY,2018-09-17T15:20:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54271,MERGED,2018-09-16T10:33:45Z,2018-12-07T03:11:34Z,Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes,petrochenkov,8ab115c21d5309ecf486a517d52deaa56522c823,19,Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes,HEART,2018-09-17T15:20:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54273,MERGED,2018-09-16T13:24:27Z,2018-09-18T11:40:06Z,Suggest to change numeric literal instead of casting,csmoe,2fb6585f33bf1af3b6b5143347eb534cebd257e4,2,add test for float/integer,HEART,2018-09-17T17:19:19Z,estebank,NA https://github.com/rust-lang/rust/pull/54281,MERGED,2018-09-16T22:15:34Z,2018-09-26T01:16:10Z,Search box,GuillaumeGomez,9d5ca397c73325a32801b3d4b619368ac7c54b94,1,Improve search box display,THUMBS_UP,2018-09-16T23:19:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54281,MERGED,2018-09-16T22:15:34Z,2018-09-26T01:16:10Z,Search box,GuillaumeGomez,9d5ca397c73325a32801b3d4b619368ac7c54b94,1,Improve search box display,THUMBS_UP,2018-09-27T12:28:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54292,MERGED,2018-09-17T13:11:24Z,2018-09-21T01:16:27Z,Suggest array indexing when tuple indexing on an array,memoryruins,73fdc81b39138d3526c3629e7d83f581901dce58,2,Use expr's span,HEART,2018-09-17T17:10:58Z,estebank,NA https://github.com/rust-lang/rust/pull/54292,MERGED,2018-09-17T13:11:24Z,2018-09-21T01:16:27Z,Suggest array indexing when tuple indexing on an array,memoryruins,73fdc81b39138d3526c3629e7d83f581901dce58,2,Use expr's span,HEART,2018-09-19T02:51:22Z,mcognetta,cognetta.marco@gmail.com https://github.com/rust-lang/rust/pull/54300,MERGED,2018-09-17T16:45:47Z,2018-10-19T12:14:30Z,Updated RELEASES.md for 1.30.0,XAMPPRocky,518a5a4898799e4b6732ac217f85def83fc462aa,1,Updated RELEASES.md for 1.30.0,HOORAY,2018-09-21T08:18:44Z,kennytm,NA https://github.com/rust-lang/rust/pull/54300,MERGED,2018-09-17T16:45:47Z,2018-10-19T12:14:30Z,Updated RELEASES.md for 1.30.0,XAMPPRocky,518a5a4898799e4b6732ac217f85def83fc462aa,1,Updated RELEASES.md for 1.30.0,HOORAY,2018-09-30T00:39:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54300,MERGED,2018-09-17T16:45:47Z,2018-10-19T12:14:30Z,Updated RELEASES.md for 1.30.0,XAMPPRocky,518a5a4898799e4b6732ac217f85def83fc462aa,1,Updated RELEASES.md for 1.30.0,HOORAY,2018-10-06T15:24:26Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/54300,MERGED,2018-09-17T16:45:47Z,2018-10-19T12:14:30Z,Updated RELEASES.md for 1.30.0,XAMPPRocky,518a5a4898799e4b6732ac217f85def83fc462aa,1,Updated RELEASES.md for 1.30.0,HOORAY,2018-10-08T17:15:14Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/54300,MERGED,2018-09-17T16:45:47Z,2018-10-19T12:14:30Z,Updated RELEASES.md for 1.30.0,XAMPPRocky,518a5a4898799e4b6732ac217f85def83fc462aa,1,Updated RELEASES.md for 1.30.0,HOORAY,2018-10-19T00:28:36Z,flosse,NA https://github.com/rust-lang/rust/pull/54308,MERGED,2018-09-17T21:55:14Z,2018-10-01T12:56:56Z,Better user experience when attempting to call associated functions with dot notation,dsciarra,0390736dce86cb97880e3eb144de9ec5759bec14,3,Improve ux when calling associated functions with dot notation Issue: 22692,THUMBS_UP,2018-09-18T06:30:14Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/54308,MERGED,2018-09-17T21:55:14Z,2018-10-01T12:56:56Z,Better user experience when attempting to call associated functions with dot notation,dsciarra,0390736dce86cb97880e3eb144de9ec5759bec14,3,Improve ux when calling associated functions with dot notation Issue: 22692,HEART,2018-09-22T02:18:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54308,MERGED,2018-09-17T21:55:14Z,2018-10-01T12:56:56Z,Better user experience when attempting to call associated functions with dot notation,dsciarra,0390736dce86cb97880e3eb144de9ec5759bec14,3,Improve ux when calling associated functions with dot notation Issue: 22692,HEART,2018-10-01T00:49:56Z,estebank,NA https://github.com/rust-lang/rust/pull/54308,MERGED,2018-09-17T21:55:14Z,2018-10-01T12:56:56Z,Better user experience when attempting to call associated functions with dot notation,dsciarra,0390736dce86cb97880e3eb144de9ec5759bec14,3,Improve ux when calling associated functions with dot notation Issue: 22692,HEART,2018-10-01T15:06:17Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/54308,MERGED,2018-09-17T21:55:14Z,2018-10-01T12:56:56Z,Better user experience when attempting to call associated functions with dot notation,dsciarra,0390736dce86cb97880e3eb144de9ec5759bec14,3,Improve ux when calling associated functions with dot notation Issue: 22692,THUMBS_UP,2018-10-04T03:20:23Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54310,MERGED,2018-09-18T00:10:21Z,2018-09-23T06:30:12Z,Report when borrow could cause `&mut` aliasing during Drop,pnkfelix,c9cf4993307b9623580b1fe7f12aa87df1225fb8,1,Address following error from rustdoc tests: error[E0106]: missing lifetime specifier --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:11424:23 | 9 | fn demo(s: &mut S) -> &mut String { let p = &mut *(*s).data; p } | ^ expected lifetime parameter | = help: this function's return type contains a borrowed value but the signature does not say which one of `s`'s 2 lifetimes it is borrowed from,THUMBS_UP,2018-09-18T00:33:30Z,lqd,NA https://github.com/rust-lang/rust/pull/54310,MERGED,2018-09-18T00:10:21Z,2018-09-23T06:30:12Z,Report when borrow could cause `&mut` aliasing during Drop,pnkfelix,c9cf4993307b9623580b1fe7f12aa87df1225fb8,1,Address following error from rustdoc tests: error[E0106]: missing lifetime specifier --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:11424:23 | 9 | fn demo(s: &mut S) -> &mut String { let p = &mut *(*s).data; p } | ^ expected lifetime parameter | = help: this function's return type contains a borrowed value but the signature does not say which one of `s`'s 2 lifetimes it is borrowed from,THUMBS_UP,2018-09-19T18:24:17Z,estebank,NA https://github.com/rust-lang/rust/pull/54310,MERGED,2018-09-18T00:10:21Z,2018-09-23T06:30:12Z,Report when borrow could cause `&mut` aliasing during Drop,pnkfelix,c9cf4993307b9623580b1fe7f12aa87df1225fb8,1,Address following error from rustdoc tests: error[E0106]: missing lifetime specifier --> /checkout/obj/build/x86_64-unknown-linux-gnu/test/error-index.md:11424:23 | 9 | fn demo(s: &mut S) -> &mut String { let p = &mut *(*s).data; p } | ^ expected lifetime parameter | = help: this function's return type contains a borrowed value but the signature does not say which one of `s`'s 2 lifetimes it is borrowed from,THUMBS_UP,2018-09-27T06:17:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-09-19T13:42:16Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,HOORAY,2018-09-21T00:44:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-09-22T16:16:11Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-09-23T19:50:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-09-25T15:14:01Z,danreeves,hey@danreev.es https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,HOORAY,2018-09-25T15:14:01Z,danreeves,hey@danreev.es https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-10-04T04:26:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-10-04T14:32:36Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,HOORAY,2018-10-05T01:17:58Z,estebank,NA https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,HOORAY,2018-10-05T05:14:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54317,MERGED,2018-09-18T05:54:50Z,2018-09-25T09:33:22Z,Implement the dbg!(..) macro,Centril,e5b9331a863c071954bcfbaa4446888414e87249,1,dbg_macro: fix line numbers,THUMBS_UP,2018-10-06T19:53:08Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-18T07:12:47Z,lqd,NA https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-18T11:09:28Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-18T18:53:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-19T08:51:14Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-19T08:55:04Z,vorner,vorner+github@vorner.cz https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-19T09:04:25Z,djc,NA https://github.com/rust-lang/rust/pull/54318,MERGED,2018-09-18T06:35:00Z,2018-09-19T05:14:49Z,Use `HybridBitSet` in `SparseBitMatrix`.,nnethercote,154be2c98cf348de080ce951df3f73649e8bb1a6,3,Use `HybridBitSet` for rows within `SparseBitMatrix`. This requires adding a few extra methods to `HybridBitSet`. (These are tested in a new unit test.) This commit reduces the `max-rss` for `nll-check` builds of `html5ever` by 46% `ucd` by 45% `clap-rs` by 23% `inflate` by 14%. And the results for the `unic-ucd-name` crate are even more impressive: a 21% reduction in instructions a 60% reduction in wall-time a 96% reduction in `max-rss` and a 97% reduction in faults! Fixes #52028.,HOORAY,2018-09-27T06:00:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54339,MERGED,2018-09-19T00:52:24Z,2018-09-23T12:34:08Z,Remove spawning from task::Context,cramertj,1b00f0b9fa92daa489510b8718ce56130420795f,13,Remove spawning from task::Context,HOORAY,2018-09-20T00:12:23Z,Ralith,NA https://github.com/rust-lang/rust/pull/54339,MERGED,2018-09-19T00:52:24Z,2018-09-23T12:34:08Z,Remove spawning from task::Context,cramertj,1b00f0b9fa92daa489510b8718ce56130420795f,13,Remove spawning from task::Context,HOORAY,2018-10-15T00:01:29Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/54350,MERGED,2018-09-19T09:30:06Z,2018-09-22T17:00:48Z,Support specifying edition in doc test,Munksgaard,06b197582e1974e925925d28196b1ed867208ebf,1,Add documentation about the edition flag,THUMBS_UP,2018-09-19T22:01:02Z,estebank,NA https://github.com/rust-lang/rust/pull/54358,MERGED,2018-09-19T14:20:48Z,2018-10-03T04:35:23Z, [beta] Cancel warning for tool_lints,flip1995,4e5eba50a3545fc22b047418e4dafe8abc7750a4,2,Remove lint_tool tests,CONFUSED,2018-10-02T14:02:15Z,aesedepece,adan@stampery.com https://github.com/rust-lang/rust/pull/54358,MERGED,2018-09-19T14:20:48Z,2018-10-03T04:35:23Z, [beta] Cancel warning for tool_lints,flip1995,4e5eba50a3545fc22b047418e4dafe8abc7750a4,2,Remove lint_tool tests,CONFUSED,2018-10-02T14:07:39Z,mariocao,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-09-20T10:39:22Z,qnighy,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-09-20T13:58:07Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-09-20T18:19:43Z,cramertj,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-09-20T19:53:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-09-26T16:58:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-11-04T09:34:24Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,HOORAY,2018-11-04T09:34:26Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,HOORAY,2018-11-07T15:45:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,THUMBS_UP,2018-11-07T19:13:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,HOORAY,2018-11-07T19:43:17Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,HOORAY,2018-11-08T14:48:04Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54383,MERGED,2018-09-20T09:40:44Z,2018-11-03T05:19:19Z,Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types,mikeyhew,192e7c4b51ab35f4cfbbacde9eeffa8e12dba873,2,Add comments explaining how codegen works for `dyn Trait` methods,HOORAY,2018-11-16T15:52:27Z,hcpl,NA https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,CONFUSED,2018-09-20T19:41:45Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HOORAY,2018-09-20T20:11:17Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,CONFUSED,2018-09-20T20:17:20Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-20T20:29:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-30T11:03:16Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HOORAY,2018-09-30T11:03:17Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,THUMBS_UP,2018-09-30T11:03:20Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,THUMBS_UP,2018-12-09T14:28:40Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,CONFUSED,2018-12-17T00:12:55Z,pczarn,NA https://github.com/rust-lang/rust/pull/54397,MERGED,2018-09-20T16:38:22Z,2018-09-20T19:44:44Z,[stable] std: Check for overflow in `str::repeat`,alexcrichton,1b94b84ad0143ea2039610e3aec9e929a8a20733,4,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-12-17T00:12:57Z,pczarn,NA https://github.com/rust-lang/rust/pull/54398,MERGED,2018-09-20T16:38:25Z,2018-09-21T03:41:29Z,[beta] std: Check for overflow in `str::repeat`,alexcrichton,4d1d1beea6020cb2b760169c215da693b4fa4d13,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-20T20:29:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54399,MERGED,2018-09-20T16:38:28Z,2018-09-21T13:01:11Z,std: Check for overflow in `str::repeat`,alexcrichton,8ac88d375e00c91a3db5d78852048322f88be3c1,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-20T20:29:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54399,MERGED,2018-09-20T16:38:28Z,2018-09-21T13:01:11Z,std: Check for overflow in `str::repeat`,alexcrichton,8ac88d375e00c91a3db5d78852048322f88be3c1,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-26T01:48:22Z,sinkuu,NA https://github.com/rust-lang/rust/pull/54399,MERGED,2018-09-20T16:38:28Z,2018-09-21T13:01:11Z,std: Check for overflow in `str::repeat`,alexcrichton,8ac88d375e00c91a3db5d78852048322f88be3c1,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HEART,2018-09-27T05:59:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54399,MERGED,2018-09-20T16:38:28Z,2018-09-21T13:01:11Z,std: Check for overflow in `str::repeat`,alexcrichton,8ac88d375e00c91a3db5d78852048322f88be3c1,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HOORAY,2018-09-30T14:44:59Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54399,MERGED,2018-09-20T16:38:28Z,2018-09-21T13:01:11Z,std: Check for overflow in `str::repeat`,alexcrichton,8ac88d375e00c91a3db5d78852048322f88be3c1,2,std: Check for overflow in `str::repeat` This commit fixes a buffer overflow issue in the standard library discovered by Scott McMurray where if a large number was passed to `str::repeat` it may cause and out of bounds write to the buffer of a `Vec`. This bug was accidentally introduced in #48657 when optimizing the `str::repeat` function. The bug affects stable Rust releases 1.26.0 to 1.29.0. We plan on backporting this fix to create a 1.29.1 release and the 1.30.0 release onwards will include this fix. The fix in this commit is to introduce a deterministic panic in the case of capacity overflow. When repeating a slice where the resulting length is larger than the address space there’s no way it can succeed anyway! The standard library and surrounding libraries were briefly checked to see if there were othere instances of preallocating a vector with a calculation that may overflow. No instances of this bug (out of bounds write due to a calculation overflow) were found at this time. Note that this commit is the first steps towards fixing this issue we'll be making a formal post to the Rust security list once these commits have been merged.,HOORAY,2019-01-03T06:16:20Z,kaoet,kaoet.ibe@outlook.com https://github.com/rust-lang/rust/pull/54403,MERGED,2018-09-20T19:09:39Z,2018-09-22T09:38:56Z,Stabilize crate_in_paths extern_absolute_paths and extern_prelude on all editions.,eddyb,fa2c24638493cc91c08a9ddab979448286e3dea1,19,Stabilize crate_in_paths extern_absolute_paths and extern_prelude on all editions.,HEART,2018-09-20T20:58:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54411,MERGED,2018-09-21T00:42:17Z,2018-09-25T17:55:08Z,"Make ""await"" a pseudo-edition keyword",cramertj,fb14662e74d6fb2e99d73525bf46931a05ce974a,12,"Make ""await"" a pseudo-edition keyword This change makes ""await"" ident an error in 2018 edition without async_await feature and adds ""await"" to the 2018 edition keyword lint group that suggest migration on the 2015 edition.",HEART,2018-09-22T02:16:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54411,MERGED,2018-09-21T00:42:17Z,2018-09-25T17:55:08Z,"Make ""await"" a pseudo-edition keyword",cramertj,fb14662e74d6fb2e99d73525bf46931a05ce974a,12,"Make ""await"" a pseudo-edition keyword This change makes ""await"" ident an error in 2018 edition without async_await feature and adds ""await"" to the 2018 edition keyword lint group that suggest migration on the 2015 edition.",HEART,2018-09-22T13:55:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54411,MERGED,2018-09-21T00:42:17Z,2018-09-25T17:55:08Z,"Make ""await"" a pseudo-edition keyword",cramertj,fb14662e74d6fb2e99d73525bf46931a05ce974a,12,"Make ""await"" a pseudo-edition keyword This change makes ""await"" ident an error in 2018 edition without async_await feature and adds ""await"" to the 2018 edition keyword lint group that suggest migration on the 2015 edition.",HEART,2018-10-04T04:25:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54411,MERGED,2018-09-21T00:42:17Z,2018-09-25T17:55:08Z,"Make ""await"" a pseudo-edition keyword",cramertj,fb14662e74d6fb2e99d73525bf46931a05ce974a,12,"Make ""await"" a pseudo-edition keyword This change makes ""await"" ident an error in 2018 edition without async_await feature and adds ""await"" to the 2018 edition keyword lint group that suggest migration on the 2015 edition.",HEART,2018-10-04T14:29:00Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,HEART,2018-09-21T11:19:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,THUMBS_UP,2018-09-21T11:38:30Z,lqd,NA https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,HEART,2018-09-21T13:25:59Z,ljedrz,NA https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,HEART,2018-09-21T13:52:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,THUMBS_UP,2018-09-21T17:15:04Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,HEART,2018-09-21T17:15:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,THUMBS_UP,2018-09-21T18:49:46Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,THUMBS_UP,2018-09-27T05:54:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,THUMBS_UP,2022-06-13T21:35:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/54420,MERGED,2018-09-21T10:57:02Z,2018-09-22T17:00:54Z,Compress `Liveness` data some more.,nnethercote,b2f25e3c38ff29eebe6c8ce69b8c69243faa440d,1,Compress `Liveness` data some more. Profiling shows that the `(reader writer used)` triples used by liveness analysis almost always have invalid `reader` and `writer` fields. We can take advantage of this knowledge to use a compressed representation for them falling back to a secondary table for the uncommon cases. This change reduces instruction counts on numerous benchmarks the best by 16%. It also reduces max-rss on numerous benchmarks the best by 38%. The patch also renames these triples from `Users` to `RWU` because it's confusing having a type whose name is plural and then used within vectors whose names are also plural.,HEART,2022-06-13T21:35:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/54422,MERGED,2018-09-21T11:12:27Z,2018-09-22T17:00:55Z,Simplify slice's first(_mut) and last(_mut) with get,ljedrz,48f46056b7604acd1fb328e41792eb25d1d37163,1,Simplify slice's first(_mut) and last(_mut) with get,THUMBS_UP,2018-09-22T02:15:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54424,CLOSED,2018-09-21T11:51:15Z,2019-01-22T18:18:29Z,do not borrow non-Sync data in constants,RalfJung,NA,NA,NA,THUMBS_UP,2018-11-08T18:33:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54440,CLOSED,2018-09-21T16:32:50Z,2018-09-28T05:40:55Z,extend unused_parens lint to `break`/`return ()`,llogiq,NA,NA,NA,THUMBS_UP,2018-09-21T17:48:21Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/54451,MERGED,2018-09-21T23:03:43Z,2018-10-07T05:41:52Z,rustc: Allow `#[no_mangle]` anywhere in a crate,alexcrichton,d7d704537457c613e667e9f0cd9fda32600bfb36,22,rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable* meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable* no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135,HOORAY,2018-09-21T23:14:18Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/54451,MERGED,2018-09-21T23:03:43Z,2018-10-07T05:41:52Z,rustc: Allow `#[no_mangle]` anywhere in a crate,alexcrichton,d7d704537457c613e667e9f0cd9fda32600bfb36,22,rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable* meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable* no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135,HOORAY,2018-09-22T00:42:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/54451,MERGED,2018-09-21T23:03:43Z,2018-10-07T05:41:52Z,rustc: Allow `#[no_mangle]` anywhere in a crate,alexcrichton,d7d704537457c613e667e9f0cd9fda32600bfb36,22,rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable* meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable* no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135,HOORAY,2018-11-21T15:56:16Z,hcpl,NA https://github.com/rust-lang/rust/pull/54459,CLOSED,2018-09-22T09:26:21Z,2018-12-24T10:49:58Z,Enable line-only debuginfo by default.,eddyb,NA,NA,NA,THUMBS_UP,2018-09-22T14:16:42Z,estebank,NA https://github.com/rust-lang/rust/pull/54459,CLOSED,2018-09-22T09:26:21Z,2018-12-24T10:49:58Z,Enable line-only debuginfo by default.,eddyb,NA,NA,NA,THUMBS_UP,2018-09-23T02:58:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,THUMBS_UP,2018-09-22T16:49:49Z,lqd,NA https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,HOORAY,2018-09-22T16:49:51Z,lqd,NA https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,HEART,2018-09-22T16:49:53Z,lqd,NA https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,THUMBS_UP,2018-09-23T13:45:12Z,sbant,NA https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,HOORAY,2018-10-04T04:22:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,HOORAY,2018-10-04T09:13:05Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54468,MERGED,2018-09-22T13:16:29Z,2018-09-27T22:08:15Z,[NLL] Get Polonius borrow check to work in simple cases,matthewjasper,610903fb118cb7cbf1474bd6cf11ae8afa380c4e,10,Get Polonius borrow check to work in simple cases * Restores the generation of outlives facts from subtyping. * Restore liveness facts. * Generate invalidates facts at the start point of each location where we check for errors. * Add a small test for simple cases.,HOORAY,2018-10-05T05:16:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54485,MERGED,2018-09-22T18:59:59Z,2018-09-24T00:20:34Z,avoid loading constructor attributes in AdtDef decoding,arielb1,2c28c4ed69fd99eea1972e7d796435b9bb0e171d,3,"avoid loading constructor attributes in AdtDef decoding During metadata loading the AdtDefs for every ADT in the universe need to be loaded (for example for coherence of builtin traits). For that the attributes of the AdtDef need to be loaded too. The attributes of a struct are duplicated between 2 def ids - the constructor def-id and the ""type"" def id. Loading attributes for both def-ids which was done in #53721 slowed the compilation of small crates by 2-3%. This PR makes sure we only load the attributes for the ""type"" def-id avoiding the slowdown.",HEART,2018-09-22T22:49:37Z,nnethercote,NA https://github.com/rust-lang/rust/pull/54485,MERGED,2018-09-22T18:59:59Z,2018-09-24T00:20:34Z,avoid loading constructor attributes in AdtDef decoding,arielb1,2c28c4ed69fd99eea1972e7d796435b9bb0e171d,3,"avoid loading constructor attributes in AdtDef decoding During metadata loading the AdtDefs for every ADT in the universe need to be loaded (for example for coherence of builtin traits). For that the attributes of the AdtDef need to be loaded too. The attributes of a struct are duplicated between 2 def ids - the constructor def-id and the ""type"" def id. Loading attributes for both def-ids which was done in #53721 slowed the compilation of small crates by 2-3%. This PR makes sure we only load the attributes for the ""type"" def-id avoiding the slowdown.",HEART,2018-10-04T04:28:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54485,MERGED,2018-09-22T18:59:59Z,2018-09-24T00:20:34Z,avoid loading constructor attributes in AdtDef decoding,arielb1,2c28c4ed69fd99eea1972e7d796435b9bb0e171d,3,"avoid loading constructor attributes in AdtDef decoding During metadata loading the AdtDefs for every ADT in the universe need to be loaded (for example for coherence of builtin traits). For that the attributes of the AdtDef need to be loaded too. The attributes of a struct are duplicated between 2 def ids - the constructor def-id and the ""type"" def id. Loading attributes for both def-ids which was done in #53721 slowed the compilation of small crates by 2-3%. This PR makes sure we only load the attributes for the ""type"" def-id avoiding the slowdown.",HEART,2018-10-04T07:24:01Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/54488,MERGED,2018-09-22T20:59:15Z,2018-10-01T12:57:00Z,in which we include attributes in unused `extern crate` suggestion spans,zackmdavis,7cbe0605fa6eacb13aa8d256b999c8424144a4e1,4,in which we include attributes in unused `extern crate` suggestion spans Resolves #54400.,HEART,2018-09-22T21:48:58Z,estebank,NA https://github.com/rust-lang/rust/pull/54488,MERGED,2018-09-22T20:59:15Z,2018-10-01T12:57:00Z,in which we include attributes in unused `extern crate` suggestion spans,zackmdavis,7cbe0605fa6eacb13aa8d256b999c8424144a4e1,4,in which we include attributes in unused `extern crate` suggestion spans Resolves #54400.,HEART,2018-09-22T22:08:12Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/54488,MERGED,2018-09-22T20:59:15Z,2018-10-01T12:57:00Z,in which we include attributes in unused `extern crate` suggestion spans,zackmdavis,7cbe0605fa6eacb13aa8d256b999c8424144a4e1,4,in which we include attributes in unused `extern crate` suggestion spans Resolves #54400.,HEART,2018-10-04T04:21:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54495,MERGED,2018-09-23T02:40:44Z,2018-09-24T02:50:36Z,Improve error message for E0424,raventid,b8a7c6f5b611202598a14871c2d08e3bc6122196,4,Improve error message for E0424,THUMBS_UP,2018-09-23T04:17:19Z,estebank,NA https://github.com/rust-lang/rust/pull/54497,MERGED,2018-09-23T05:27:44Z,2018-09-26T10:05:02Z,Stabilize pattern_parentheses feature,ralexstokes,a3818685e412435d6faecfcf9b016b4eb7627e90,6,stabilize pattern_parentheses feature,HEART,2018-09-25T23:52:39Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54497,MERGED,2018-09-23T05:27:44Z,2018-09-26T10:05:02Z,Stabilize pattern_parentheses feature,ralexstokes,a3818685e412435d6faecfcf9b016b4eb7627e90,6,stabilize pattern_parentheses feature,THUMBS_UP,2018-10-04T03:19:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54497,MERGED,2018-09-23T05:27:44Z,2018-09-26T10:05:02Z,Stabilize pattern_parentheses feature,ralexstokes,a3818685e412435d6faecfcf9b016b4eb7627e90,6,stabilize pattern_parentheses feature,THUMBS_UP,2018-10-04T04:27:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54497,MERGED,2018-09-23T05:27:44Z,2018-09-26T10:05:02Z,Stabilize pattern_parentheses feature,ralexstokes,a3818685e412435d6faecfcf9b016b4eb7627e90,6,stabilize pattern_parentheses feature,HEART,2018-12-04T12:31:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54497,MERGED,2018-09-23T05:27:44Z,2018-09-26T10:05:02Z,Stabilize pattern_parentheses feature,ralexstokes,a3818685e412435d6faecfcf9b016b4eb7627e90,6,stabilize pattern_parentheses feature,THUMBS_UP,2018-12-04T12:31:23Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54507,MERGED,2018-09-23T15:01:10Z,2018-09-24T12:38:33Z,Deny the `overflowing_literals` lint for the 2018 edition,csmoe,6523eabf6e013f2889ed8af60ab6019690f6b00b,2,add test for edition 2018,THUMBS_UP,2018-10-03T18:31:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/54507,MERGED,2018-09-23T15:01:10Z,2018-09-24T12:38:33Z,Deny the `overflowing_literals` lint for the 2018 edition,csmoe,6523eabf6e013f2889ed8af60ab6019690f6b00b,2,add test for edition 2018,HEART,2018-10-04T03:32:45Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54507,MERGED,2018-09-23T15:01:10Z,2018-09-24T12:38:33Z,Deny the `overflowing_literals` lint for the 2018 edition,csmoe,6523eabf6e013f2889ed8af60ab6019690f6b00b,2,add test for edition 2018,THUMBS_UP,2018-10-04T04:22:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54507,MERGED,2018-09-23T15:01:10Z,2018-09-24T12:38:33Z,Deny the `overflowing_literals` lint for the 2018 edition,csmoe,6523eabf6e013f2889ed8af60ab6019690f6b00b,2,add test for edition 2018,HOORAY,2018-10-11T17:21:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54547,MERGED,2018-09-25T03:14:03Z,2018-09-28T05:11:57Z,Rely only on base alignment and offset for computing field alignment,AstralSorcerer,06b8c3ee5b52dc849259655578afca70cb32dda3,2,Rely only on base alignment and offset for computing field alignment Fix #54028,HEART,2018-09-28T05:43:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54554,MERGED,2018-09-25T13:11:03Z,2018-09-29T12:35:56Z,Revert most of MaybeUninit except for the new API itself,RalfJung,546e45ab5b20b9151b3331c727ecb5fd2e3eecaf,1,add MaybeUninit,THUMBS_UP,2018-09-25T20:30:20Z,nnethercote,NA https://github.com/rust-lang/rust/pull/54554,MERGED,2018-09-25T13:11:03Z,2018-09-29T12:35:56Z,Revert most of MaybeUninit except for the new API itself,RalfJung,546e45ab5b20b9151b3331c727ecb5fd2e3eecaf,1,add MaybeUninit,HEART,2018-09-29T02:22:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54554,MERGED,2018-09-25T13:11:03Z,2018-09-29T12:35:56Z,Revert most of MaybeUninit except for the new API itself,RalfJung,546e45ab5b20b9151b3331c727ecb5fd2e3eecaf,1,add MaybeUninit,THUMBS_UP,2018-09-29T14:13:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54558,MERGED,2018-09-25T15:19:53Z,2018-09-26T01:16:21Z,Improvements to finding LLVM's FileCheck,tromey,f4b4939f3e024c53355d4f99c0762135a613dae0,4,"Improvements to finding LLVM's FileCheck This patch adds a few improvements to how the build system finds LLVM's FileCheck program. * On Fedora the system LLVM installs FileCheck in the ""llvm"" subdirectory of the LLVM libdir. This patch teaches the build system to look there. * This adds a configure option to specify which llvm-config executable to use. This is handy on systems that can parallel install multiple versions of LLVM; for example I can now: ./configure --llvm-config=/bin/llvm-config-5.0-64 ... to build against LLVM 5 rather than whatever the default llvm-config might be. * Finally this adds a configure- and config.toml- option to set the path to FileCheck. This is handy when building against an LLVM where FileCheck was not installed. This happens on compatibility installs of LLVM on Fedora.",HEART,2018-09-25T22:57:08Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/54558,MERGED,2018-09-25T15:19:53Z,2018-09-26T01:16:21Z,Improvements to finding LLVM's FileCheck,tromey,f4b4939f3e024c53355d4f99c0762135a613dae0,4,"Improvements to finding LLVM's FileCheck This patch adds a few improvements to how the build system finds LLVM's FileCheck program. * On Fedora the system LLVM installs FileCheck in the ""llvm"" subdirectory of the LLVM libdir. This patch teaches the build system to look there. * This adds a configure option to specify which llvm-config executable to use. This is handy on systems that can parallel install multiple versions of LLVM; for example I can now: ./configure --llvm-config=/bin/llvm-config-5.0-64 ... to build against LLVM 5 rather than whatever the default llvm-config might be. * Finally this adds a configure- and config.toml- option to set the path to FileCheck. This is handy when building against an LLVM where FileCheck was not installed. This happens on compatibility installs of LLVM on Fedora.",HEART,2018-10-04T04:20:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54577,MERGED,2018-09-25T21:46:14Z,2018-09-29T15:07:50Z,rustdoc: give proc-macros their own pages,QuietMisdreavus,d37f3696b167251a96b8f0e4b33336d023daa2c5,1,"check for proc-macros in ""all items""",HEART,2018-09-26T11:20:57Z,killercup,NA https://github.com/rust-lang/rust/pull/54577,MERGED,2018-09-25T21:46:14Z,2018-09-29T15:07:50Z,rustdoc: give proc-macros their own pages,QuietMisdreavus,d37f3696b167251a96b8f0e4b33336d023daa2c5,1,"check for proc-macros in ""all items""",HEART,2018-09-26T16:51:28Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/54577,MERGED,2018-09-25T21:46:14Z,2018-09-29T15:07:50Z,rustdoc: give proc-macros their own pages,QuietMisdreavus,d37f3696b167251a96b8f0e4b33336d023daa2c5,1,"check for proc-macros in ""all items""",HEART,2018-11-09T08:22:01Z,hcpl,NA https://github.com/rust-lang/rust/pull/54580,MERGED,2018-09-25T22:39:09Z,2018-10-18T15:34:37Z,Add slice::rchunks() rchunks_mut() rchunks_exact() and rchunks_exact_mut(),sdroege,80a8e5c1f767384d0736807f33f5e435a748cf4c,7,Add slice::rchunks() rchunks_mut() rchunks_exact() and rchunks_exact_mut() These work exactly like the normal chunks iterators but start creating chunks from the end of the slice. See #55177 for the tracking issue,HOORAY,2018-09-26T04:37:02Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/54580,MERGED,2018-09-25T22:39:09Z,2018-10-18T15:34:37Z,Add slice::rchunks() rchunks_mut() rchunks_exact() and rchunks_exact_mut(),sdroege,80a8e5c1f767384d0736807f33f5e435a748cf4c,7,Add slice::rchunks() rchunks_mut() rchunks_exact() and rchunks_exact_mut() These work exactly like the normal chunks iterators but start creating chunks from the end of the slice. See #55177 for the tracking issue,HOORAY,2018-10-10T21:00:50Z,0e4ef622,0e4ef622@gmail.com https://github.com/rust-lang/rust/pull/54590,MERGED,2018-09-26T14:52:39Z,2018-09-29T15:07:50Z,std: Don't let `rust_panic` get inlined,alexcrichton,243030b1408a70f073878e5a206d46d43fc60dab,1,std: Don't let `rust_panic` get inlined It's meant for breakpoints so if it gets inlined we can't set a breakpoint on it easily!,THUMBS_UP,2018-09-26T15:11:16Z,nical,nical@fastmail.com https://github.com/rust-lang/rust/pull/54590,MERGED,2018-09-26T14:52:39Z,2018-09-29T15:07:50Z,std: Don't let `rust_panic` get inlined,alexcrichton,243030b1408a70f073878e5a206d46d43fc60dab,1,std: Don't let `rust_panic` get inlined It's meant for breakpoints so if it gets inlined we can't set a breakpoint on it easily!,THUMBS_UP,2018-11-27T13:53:41Z,briprowe,briprowe@gmail.com https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,THUMBS_UP,2018-09-29T10:12:27Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,HEART,2018-09-29T14:39:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,HEART,2018-10-08T16:58:57Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,THUMBS_UP,2018-10-10T14:23:00Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,HEART,2018-10-10T16:52:58Z,simonlindholm,simon.lindholm10@gmail.com https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,THUMBS_UP,2018-10-11T08:06:22Z,m0n0chr0m3,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,THUMBS_UP,2018-10-11T15:31:12Z,tux3,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,HEART,2018-10-11T15:31:14Z,tux3,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,THUMBS_UP,2018-10-15T16:10:03Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/54592,MERGED,2018-09-26T16:55:35Z,2018-10-11T22:22:13Z,Support for disabling PLT for better function call performance,GabrielMajeri,6009da079419c9693fe4965ecacbd473c2553173,12,Support for disabling the PLT on ELF targets Disable the PLT where possible to improve performance for indirect calls into shared libraries. This optimization is enabled by default where possible. - Add the `NonLazyBind` attribute to `rustllvm`: This attribute informs LLVM to skip PLT calls in codegen. - Disable PLT unconditionally: Apply the `NonLazyBind` attribute on every function. - Only enable no-plt when full relro is enabled: Ensures we only enable it when we have linker support. - Add `-Z plt` as a compiler option,HEART,2018-10-16T18:40:21Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/54601,MERGED,2018-09-26T21:29:23Z,2018-09-30T04:17:36Z,Bump to 1.31.0 and bootstrap from 1.30 beta,cuviper,d40b6cf086734109ec402aa546eca4d3925732ca,3,Update ui lines,HOORAY,2018-09-29T02:12:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54613,MERGED,2018-09-27T10:10:52Z,2018-10-09T22:36:28Z,liballoc: mark str.to_owned() and String::from(&str) as #[inline].,matthiaskrgr,d24070bf8d58f40887b4b33f63c1c3d3df55c346,2,liballoc: mark str.to_owned() and String::from(&str) as #[inline]. Fixes #53681,THUMBS_UP,2018-09-29T02:16:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54621,CLOSED,2018-09-27T21:11:29Z,2018-10-12T15:28:13Z,Fix variable does not need to be mutable warning,spastorino,NA,NA,NA,HEART,2018-10-10T00:56:34Z,estebank,NA https://github.com/rust-lang/rust/pull/54623,MERGED,2018-09-27T21:35:31Z,2018-10-01T12:57:04Z,Added help message for `impl_trait_in_bindings` feature gate,alexreg,3e142b92bc84c48b2bccf8673b49b02e9b1f13c4,3,Added help message for `impl_trait_in_bindings` feature gate.,HEART,2018-10-01T00:53:12Z,estebank,NA https://github.com/rust-lang/rust/pull/54623,MERGED,2018-09-27T21:35:31Z,2018-10-01T12:57:04Z,Added help message for `impl_trait_in_bindings` feature gate,alexreg,3e142b92bc84c48b2bccf8673b49b02e9b1f13c4,3,Added help message for `impl_trait_in_bindings` feature gate.,HEART,2018-10-01T09:41:46Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/54639,MERGED,2018-09-28T14:49:31Z,2018-09-30T09:22:54Z,Do not put noalias annotations by default,nagisa,9c62193fec1c5d2200c19d9445fe9bad753eefea,3,Do not put noalias annotations by default This will be re-enabled sooner or later depending on results of further investigation. Fixes #54462,THUMBS_UP,2018-09-30T11:59:25Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/54639,MERGED,2018-09-28T14:49:31Z,2018-09-30T09:22:54Z,Do not put noalias annotations by default,nagisa,9c62193fec1c5d2200c19d9445fe9bad753eefea,3,Do not put noalias annotations by default This will be re-enabled sooner or later depending on results of further investigation. Fixes #54462,THUMBS_UP,2021-07-23T15:39:07Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/54640,MERGED,2018-09-28T14:50:51Z,2018-09-30T19:41:05Z,[beta] Do not put noalias annotations by default,nagisa,090cc199d300bbe0d2a0c886d05e04912b680d2f,3,Do not put noalias annotations by default This will be re-enabled sooner or later depending on results of further investigation. Fixes #54462,THUMBS_UP,2018-09-30T11:59:40Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/54641,MERGED,2018-09-28T15:41:55Z,2018-10-01T12:57:06Z,A few cleanups and minor improvements to rustc/infer,ljedrz,52da88639e515dabe4927706025adf976d9cd2b7,3,rustc/infer: miscellaneous minor code improvements,HEART,2018-09-28T18:51:21Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/54641,MERGED,2018-09-28T15:41:55Z,2018-10-01T12:57:06Z,A few cleanups and minor improvements to rustc/infer,ljedrz,52da88639e515dabe4927706025adf976d9cd2b7,3,rustc/infer: miscellaneous minor code improvements,HEART,2018-09-30T04:13:44Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/54648,MERGED,2018-09-28T18:30:59Z,2018-10-03T02:06:15Z,Update Cargo's submodule,alexcrichton,d99e7c2dae1109ed1b92bebe924b854338bfaad2,2,Update Cargo's submodule Bring in a few updates and fixes mostly a standard update.,THUMBS_UP,2018-10-02T11:12:06Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54650,MERGED,2018-09-28T20:37:27Z,2018-10-01T00:51:33Z,Don't lint non-extern-prelude extern crate's in Rust 2018.,eddyb,81ca8ebee229ec85d9d2c54d7eda7fd0106a34f3,6,rustc_typeck: don't lint non-extern-prelude extern crate's in Rust 2018.,THUMBS_UP,2018-10-01T12:48:51Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/54650,MERGED,2018-09-28T20:37:27Z,2018-10-01T00:51:33Z,Don't lint non-extern-prelude extern crate's in Rust 2018.,eddyb,81ca8ebee229ec85d9d2c54d7eda7fd0106a34f3,6,rustc_typeck: don't lint non-extern-prelude extern crate's in Rust 2018.,THUMBS_UP,2018-10-04T04:22:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54658,MERGED,2018-09-29T00:32:35Z,2018-10-25T12:00:58Z,Add `extern crate` items to extern prelude,petrochenkov,d1e337bded30b84df777f6de3d8fc588286f0834,5,Prohibit macro-expanded `extern crate` items shadowing crates passed with `--extern`,THUMBS_UP,2018-09-29T12:32:46Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/54658,MERGED,2018-09-29T00:32:35Z,2018-10-25T12:00:58Z,Add `extern crate` items to extern prelude,petrochenkov,d1e337bded30b84df777f6de3d8fc588286f0834,5,Prohibit macro-expanded `extern crate` items shadowing crates passed with `--extern`,THUMBS_UP,2018-09-29T13:10:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/54658,MERGED,2018-09-29T00:32:35Z,2018-10-25T12:00:58Z,Add `extern crate` items to extern prelude,petrochenkov,d1e337bded30b84df777f6de3d8fc588286f0834,5,Prohibit macro-expanded `extern crate` items shadowing crates passed with `--extern`,THUMBS_UP,2018-09-29T19:23:07Z,tmandry,NA https://github.com/rust-lang/rust/pull/54658,MERGED,2018-09-29T00:32:35Z,2018-10-25T12:00:58Z,Add `extern crate` items to extern prelude,petrochenkov,d1e337bded30b84df777f6de3d8fc588286f0834,5,Prohibit macro-expanded `extern crate` items shadowing crates passed with `--extern`,THUMBS_UP,2018-11-24T17:19:14Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54658,MERGED,2018-09-29T00:32:35Z,2018-10-25T12:00:58Z,Add `extern crate` items to extern prelude,petrochenkov,d1e337bded30b84df777f6de3d8fc588286f0834,5,Prohibit macro-expanded `extern crate` items shadowing crates passed with `--extern`,THUMBS_UP,2021-04-07T16:27:37Z,lukechu10,NA https://github.com/rust-lang/rust/pull/54666,MERGED,2018-09-29T11:37:34Z,2018-10-04T19:11:39Z,"[NLL] Improve ""borrow later used here"" messages",matthewjasper,bc4f9b848d745022ededdfaa3099158a766e8faa,102,Clearer later use messages for calls Give a special message when the later use is from a call. Use the span of the callee instead of the whole expression. For conflicting borrow messages say that the later use is of the first borrow.,HEART,2018-10-02T00:32:55Z,estebank,NA https://github.com/rust-lang/rust/pull/54667,MERGED,2018-09-29T12:54:28Z,2018-10-01T17:44:15Z,Panic when using mem::uninitialized or mem::zeroed on an uninhabited type,RalfJung,dd65d732ed702302ac0943179cb2feec835975ee,1,the test requires unwinding so we don't run it on the wasm32-bare target,HEART,2018-10-01T01:15:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54667,MERGED,2018-09-29T12:54:28Z,2018-10-01T17:44:15Z,Panic when using mem::uninitialized or mem::zeroed on an uninhabited type,RalfJung,dd65d732ed702302ac0943179cb2feec835975ee,1,the test requires unwinding so we don't run it on the wasm32-bare target,HEART,2018-10-04T04:20:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54667,MERGED,2018-09-29T12:54:28Z,2018-10-01T17:44:15Z,Panic when using mem::uninitialized or mem::zeroed on an uninhabited type,RalfJung,dd65d732ed702302ac0943179cb2feec835975ee,1,the test requires unwinding so we don't run it on the wasm32-bare target,THUMBS_UP,2018-10-05T05:17:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54686,MERGED,2018-09-30T04:42:38Z,2018-10-09T01:01:58Z,structured suggestions for unused-lifetimes lint,zackmdavis,efd7a311506d3a4291dc8f9ed21bda43e39686ae,1,in which rightward drift is opposed Thanks to reviewers Tyler Mandry (for pointing out that this is ridiculous and we need a helper function) Niko Matsakis (for pointing out that the span-calculation code only has a couple free variables) and Esteban Küber (for pointing out `get_generics`).,HEART,2018-09-30T05:20:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54686,MERGED,2018-09-30T04:42:38Z,2018-10-09T01:01:58Z,structured suggestions for unused-lifetimes lint,zackmdavis,efd7a311506d3a4291dc8f9ed21bda43e39686ae,1,in which rightward drift is opposed Thanks to reviewers Tyler Mandry (for pointing out that this is ridiculous and we need a helper function) Niko Matsakis (for pointing out that the span-calculation code only has a couple free variables) and Esteban Küber (for pointing out `get_generics`).,HEART,2018-09-30T14:17:40Z,killercup,NA https://github.com/rust-lang/rust/pull/54686,MERGED,2018-09-30T04:42:38Z,2018-10-09T01:01:58Z,structured suggestions for unused-lifetimes lint,zackmdavis,efd7a311506d3a4291dc8f9ed21bda43e39686ae,1,in which rightward drift is opposed Thanks to reviewers Tyler Mandry (for pointing out that this is ridiculous and we need a helper function) Niko Matsakis (for pointing out that the span-calculation code only has a couple free variables) and Esteban Küber (for pointing out `get_generics`).,HEART,2018-10-01T15:27:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/54686,MERGED,2018-09-30T04:42:38Z,2018-10-09T01:01:58Z,structured suggestions for unused-lifetimes lint,zackmdavis,efd7a311506d3a4291dc8f9ed21bda43e39686ae,1,in which rightward drift is opposed Thanks to reviewers Tyler Mandry (for pointing out that this is ridiculous and we need a helper function) Niko Matsakis (for pointing out that the span-calculation code only has a couple free variables) and Esteban Küber (for pointing out `get_generics`).,HEART,2018-10-02T00:28:03Z,estebank,NA https://github.com/rust-lang/rust/pull/54686,MERGED,2018-09-30T04:42:38Z,2018-10-09T01:01:58Z,structured suggestions for unused-lifetimes lint,zackmdavis,efd7a311506d3a4291dc8f9ed21bda43e39686ae,1,in which rightward drift is opposed Thanks to reviewers Tyler Mandry (for pointing out that this is ridiculous and we need a helper function) Niko Matsakis (for pointing out that the span-calculation code only has a couple free variables) and Esteban Küber (for pointing out `get_generics`).,HEART,2018-10-17T16:00:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54687,MERGED,2018-09-30T05:14:23Z,2018-10-03T02:06:17Z,Use impl_header_lifetime_elision in libcore,scottmcm,d4840da77993d052bae2a900163026602ac89d3c,1,Activate the feature in the libcore tests too,THUMBS_UP,2018-09-30T07:30:41Z,ljedrz,NA https://github.com/rust-lang/rust/pull/54687,MERGED,2018-09-30T05:14:23Z,2018-10-03T02:06:17Z,Use impl_header_lifetime_elision in libcore,scottmcm,d4840da77993d052bae2a900163026602ac89d3c,1,Activate the feature in the libcore tests too,THUMBS_UP,2018-10-03T09:58:09Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54694,MERGED,2018-09-30T12:55:08Z,2018-10-02T03:50:52Z,Suggest to use self for fake-self from other languages,csmoe,4470b1cec0a5b8eb580a8cce96009a46f54bf2c2,2,mark fix as MaybeIncorrect,THUMBS_UP,2018-09-30T15:51:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54694,MERGED,2018-09-30T12:55:08Z,2018-10-02T03:50:52Z,Suggest to use self for fake-self from other languages,csmoe,4470b1cec0a5b8eb580a8cce96009a46f54bf2c2,2,mark fix as MaybeIncorrect,HEART,2018-10-01T15:38:44Z,tmandry,NA https://github.com/rust-lang/rust/pull/54694,MERGED,2018-09-30T12:55:08Z,2018-10-02T03:50:52Z,Suggest to use self for fake-self from other languages,csmoe,4470b1cec0a5b8eb580a8cce96009a46f54bf2c2,2,mark fix as MaybeIncorrect,HEART,2018-10-01T18:23:00Z,estebank,NA https://github.com/rust-lang/rust/pull/54694,MERGED,2018-09-30T12:55:08Z,2018-10-02T03:50:52Z,Suggest to use self for fake-self from other languages,csmoe,4470b1cec0a5b8eb580a8cce96009a46f54bf2c2,2,mark fix as MaybeIncorrect,HEART,2018-10-13T06:29:00Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/54699,MERGED,2018-09-30T15:49:23Z,2018-10-03T02:06:18Z,Re-export `getopts` so custom drivers can reference it.,DiamondLovesYou,0b76a97793ddf7e249717507022fae6b6ecd2361,1,Re-export `getopts` so custom drivers can reference it. Otherwise custom drivers will have to use their own copy of `getopts` which won't match the types used in `CompilerCalls`.,THUMBS_UP,2018-09-30T17:36:50Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/54700,MERGED,2018-09-30T16:29:05Z,2018-10-08T05:40:21Z,Clarify docs for when binary_search has many matches.,frewsxcv,b5c64e2e261ab2d3a009ccf1630d532202400009,1,Clarify docs for when binary_search has many matches. Fixes https://github.com/rust-lang/rust/issues/51817.,THUMBS_UP,2018-10-01T01:13:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54700,MERGED,2018-09-30T16:29:05Z,2018-10-08T05:40:21Z,Clarify docs for when binary_search has many matches.,frewsxcv,b5c64e2e261ab2d3a009ccf1630d532202400009,1,Clarify docs for when binary_search has many matches. Fixes https://github.com/rust-lang/rust/issues/51817.,HOORAY,2018-10-01T19:15:07Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/54702,MERGED,2018-09-30T17:48:10Z,2018-10-03T02:06:19Z,do not promote comparing function pointers,RalfJung,4cbfc9398d93d9eb0b1178b129f80de9be5c8ef9,3,also compile-fail test fn ptr comparison promotion,THUMBS_UP,2018-10-11T04:19:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54703,MERGED,2018-09-30T19:45:58Z,2018-10-05T10:08:18Z,error message when trying to move from an Rc or Arc is ungreat,davidtwco,8c6d08b71f56541a540d365746aab460862d3149,7,Add special cases for move from `Rc`/`Arc` errors. This commit special cases the move out of borrowed content error previously: ``` error[E0507]: cannot move out of borrowed content --> src/main.rs:7:10 | 7 | drop(x.field); | ^ cannot move out of borrowed content ``` to instead mention that it is a move out of a `Rc`/`Arc` which is more helpful: ``` error[E0507]: cannot move out of an `Rc` --> src/main.rs:7:10 | 7 | drop(x.field); | ^ cannot move out of an `Rc` ```,HEART,2018-10-01T03:48:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/54717,MERGED,2018-10-01T14:11:48Z,2018-10-06T03:28:11Z,Cleanup rustc/ty part 1,ljedrz,7ad21a88e6e5016af53ec3b277c32dac65cc8c66,1,rustc/ty: improve stack shifting and remove related allocations,HEART,2018-10-01T18:19:05Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/54717,MERGED,2018-10-01T14:11:48Z,2018-10-06T03:28:11Z,Cleanup rustc/ty part 1,ljedrz,7ad21a88e6e5016af53ec3b277c32dac65cc8c66,1,rustc/ty: improve stack shifting and remove related allocations,HEART,2018-10-04T05:19:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54717,MERGED,2018-10-01T14:11:48Z,2018-10-06T03:28:11Z,Cleanup rustc/ty part 1,ljedrz,7ad21a88e6e5016af53ec3b277c32dac65cc8c66,1,rustc/ty: improve stack shifting and remove related allocations,HEART,2018-10-07T08:49:42Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,HEART,2019-09-25T15:21:25Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,THUMBS_UP,2019-11-18T20:43:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,THUMBS_UP,2019-11-21T11:53:11Z,Folyd,NA https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,THUMBS_UP,2019-11-25T22:25:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,HEART,2020-01-30T00:13:55Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,THUMBS_UP,2020-06-04T21:26:24Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,HEART,2020-06-04T21:26:26Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,HEART,2020-06-04T22:52:33Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/54733,MERGED,2018-10-01T22:43:48Z,2019-11-18T22:09:10Z,Stabilize rustdoc theme options,GuillaumeGomez,45b83c9164c2462503c2cd381a4b1b85f75fa107,2,Fix Makefile themes check,THUMBS_UP,2020-06-04T22:52:34Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/54734,MERGED,2018-10-01T23:39:33Z,2018-10-10T01:17:27Z,Fix range literals borrowing suggestions,pawroman,1f7dafbb778dc9bff6a13828813fbcd105d977c9,2,Fix test for windows os,HEART,2018-10-02T00:27:00Z,estebank,NA https://github.com/rust-lang/rust/pull/54734,MERGED,2018-10-01T23:39:33Z,2018-10-10T01:17:27Z,Fix range literals borrowing suggestions,pawroman,1f7dafbb778dc9bff6a13828813fbcd105d977c9,2,Fix test for windows os,HEART,2018-10-02T10:55:19Z,varkor,NA https://github.com/rust-lang/rust/pull/54747,MERGED,2018-10-02T11:10:21Z,2018-10-11T01:19:50Z,codegen_llvm: verify that inline assembly operands are scalars,levex,3d7476eae1f4903684426835e97ba8f5d337c300,4,codegen_llvm: verify that inline assembly operands are scalars Otherwise LLVM translation will fail with a panic. Signed-off-by: Levente Kurusa ,THUMBS_UP,2018-10-02T12:45:02Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/54761,MERGED,2018-10-02T19:43:40Z,2018-10-04T14:08:33Z,Make spec_extend use for_each(),Lucretiel,ec59188025582fd91ab868206cfb3f3f05e27ade,1,Make spec_extend use for_each(),HEART,2018-10-04T03:34:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54772,CLOSED,2018-10-03T01:28:32Z,2018-10-17T22:31:36Z,More natural rustdoc typography styling,jonhoo,NA,NA,NA,HOORAY,2018-10-04T20:14:26Z,mcarton,NA https://github.com/rust-lang/rust/pull/54777,MERGED,2018-10-03T06:06:00Z,2018-10-04T14:08:36Z,abolish ICE when pretty-printing async block,zackmdavis,1081bbbfc5d170f22b5810b40c456a17da59cf7f,2,"abolish ICE when pretty-printing async block Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead to preserve the formatting of the original source?—but for that you'd have to ask the author of 5c9f806d.) But then the pretty-printer panics when trying to call `::end` when `State.boxes` is empty. Empirically the problem would seem to be solved if we start some ""boxes"" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style` exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty (""pretty"") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks right?? Of course it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves #54752.",HEART,2018-10-03T06:28:03Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54777,MERGED,2018-10-03T06:06:00Z,2018-10-04T14:08:36Z,abolish ICE when pretty-printing async block,zackmdavis,1081bbbfc5d170f22b5810b40c456a17da59cf7f,2,"abolish ICE when pretty-printing async block Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead to preserve the formatting of the original source?—but for that you'd have to ask the author of 5c9f806d.) But then the pretty-printer panics when trying to call `::end` when `State.boxes` is empty. Empirically the problem would seem to be solved if we start some ""boxes"" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style` exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty (""pretty"") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks right?? Of course it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves #54752.",HEART,2018-10-03T14:04:03Z,emilyskidsister,jocelyn@nettek.ca https://github.com/rust-lang/rust/pull/54777,MERGED,2018-10-03T06:06:00Z,2018-10-04T14:08:36Z,abolish ICE when pretty-printing async block,zackmdavis,1081bbbfc5d170f22b5810b40c456a17da59cf7f,2,"abolish ICE when pretty-printing async block Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead to preserve the formatting of the original source?—but for that you'd have to ask the author of 5c9f806d.) But then the pretty-printer panics when trying to call `::end` when `State.boxes` is empty. Empirically the problem would seem to be solved if we start some ""boxes"" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style` exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty (""pretty"") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks right?? Of course it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves #54752.",LAUGH,2018-10-03T14:59:05Z,kennytm,NA https://github.com/rust-lang/rust/pull/54777,MERGED,2018-10-03T06:06:00Z,2018-10-04T14:08:36Z,abolish ICE when pretty-printing async block,zackmdavis,1081bbbfc5d170f22b5810b40c456a17da59cf7f,2,"abolish ICE when pretty-printing async block Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead to preserve the formatting of the original source?—but for that you'd have to ask the author of 5c9f806d.) But then the pretty-printer panics when trying to call `::end` when `State.boxes` is empty. Empirically the problem would seem to be solved if we start some ""boxes"" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style` exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty (""pretty"") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks right?? Of course it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves #54752.",HEART,2018-10-03T16:27:04Z,Pratyush,NA https://github.com/rust-lang/rust/pull/54777,MERGED,2018-10-03T06:06:00Z,2018-10-04T14:08:36Z,abolish ICE when pretty-printing async block,zackmdavis,1081bbbfc5d170f22b5810b40c456a17da59cf7f,2,"abolish ICE when pretty-printing async block Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (#54752). In order to compose an autofixable suggestion the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead to preserve the formatting of the original source?—but for that you'd have to ask the author of 5c9f806d.) But then the pretty-printer panics when trying to call `::end` when `State.boxes` is empty. Empirically the problem would seem to be solved if we start some ""boxes"" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style` exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty (""pretty"") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks right?? Of course it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves #54752.",HEART,2018-10-04T10:42:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-10-03T10:50:36Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-10-06T22:56:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-10-17T05:26:13Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-10-23T07:16:59Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-11-16T18:02:29Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-11-17T02:31:51Z,CBenoit,bcortier@peculiarz.one https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-11-20T04:54:06Z,tyre,NA https://github.com/rust-lang/rust/pull/54778,MERGED,2018-10-03T07:34:57Z,2018-10-23T06:40:57Z,Stabilize impl_header_lifetime_elision in 2015,scottmcm,18f7db3d69377ebf85b6ff3a319445411f4b16b1,3,`impl<'_> IceCube<'_> {}` is now only one error in both editions,HEART,2018-12-04T12:31:55Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54799,CLOSED,2018-10-03T22:18:41Z,2018-11-26T14:10:44Z,Make the NonZero* methods const fn,JamesHinshelwood,NA,NA,NA,THUMBS_UP,2018-11-10T23:20:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/54811,MERGED,2018-10-04T10:44:01Z,2018-10-12T17:50:46Z,During rustc bootstrap make default for `optimize` independent of `debug`,pnkfelix,40e20e288d0f928c25bc74c14d74227c4d5c7182,1,Added text explaining the (new) relative roles of `optimize`+`debug` and to briefly touch on the theory of debugging rustc versus the practice of such.,THUMBS_UP,2018-10-12T23:12:36Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/54813,MERGED,2018-10-04T13:33:55Z,2018-10-07T13:37:24Z,Fix two UI tests with locale-dependent output,petrochenkov,a7cce470b6c6524249b25449d85b12ce62aef4af,4,Fix two UI tests with locale-dependent output,HEART,2018-10-04T13:37:29Z,ljedrz,NA https://github.com/rust-lang/rust/pull/54824,MERGED,2018-10-04T20:31:47Z,2018-10-26T20:08:21Z,Cleanup rustdoc tests with `@!has` and `@!matches`,Munksgaard,a9217e316c7fd35ef5be4b0c1e84f637ec0fa813,1,Fix typo in issue-13698.rs,HOORAY,2018-10-04T20:38:49Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54824,MERGED,2018-10-04T20:31:47Z,2018-10-26T20:08:21Z,Cleanup rustdoc tests with `@!has` and `@!matches`,Munksgaard,a9217e316c7fd35ef5be4b0c1e84f637ec0fa813,1,Fix typo in issue-13698.rs,HOORAY,2018-10-04T20:44:10Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/54824,MERGED,2018-10-04T20:31:47Z,2018-10-26T20:08:21Z,Cleanup rustdoc tests with `@!has` and `@!matches`,Munksgaard,a9217e316c7fd35ef5be4b0c1e84f637ec0fa813,1,Fix typo in issue-13698.rs,HEART,2018-10-04T20:44:11Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T08:39:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T08:47:27Z,lqd,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T09:03:01Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T09:54:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T11:59:08Z,killercup,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T13:48:38Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T14:06:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T15:46:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T17:08:59Z,dragostis,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T17:52:26Z,ljedrz,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-05T19:45:37Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-06T00:56:26Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-06T15:50:21Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-07T11:24:48Z,hcpl,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-07T12:35:37Z,CryZe,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T20:05:17Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T21:09:57Z,darksv,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T21:36:01Z,Pratyush,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,LAUGH,2018-10-09T21:42:11Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T22:17:41Z,discosultan,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T22:55:26Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T23:02:33Z,weihanglo,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,LAUGH,2018-10-09T23:02:48Z,weihanglo,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-09T23:35:54Z,sunjay,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T03:12:41Z,logannc,logan.neal.collins@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T06:11:27Z,max-frai,me@maxfrai.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T07:19:27Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T07:33:40Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T11:49:05Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T12:32:12Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-10T16:55:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,THUMBS_UP,2018-10-11T01:52:40Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,THUMBS_UP,2018-10-11T08:34:32Z,funbringer,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-11T18:43:53Z,tmandry,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-13T21:26:49Z,warrenrentlytics,warren@rentlytics.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,LAUGH,2018-10-13T21:26:49Z,warrenrentlytics,warren@rentlytics.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,THUMBS_UP,2018-10-13T21:26:50Z,warrenrentlytics,warren@rentlytics.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-10-16T21:36:06Z,nwn,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-11-20T08:30:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2018-12-04T12:32:06Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,LAUGH,2018-12-04T12:32:07Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,THUMBS_UP,2018-12-04T12:32:07Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2019-04-28T18:27:13Z,tiagoamaro,NA https://github.com/rust-lang/rust/pull/54835,MERGED,2018-10-05T08:18:18Z,2018-10-07T16:06:47Z,Stabilize `min_const_fn`,oli-obk,fb04e2644730f48ff257d467c2ef6e25274e17d1,1,Stabilize min_const_fn feature gate,HOORAY,2019-10-22T02:56:44Z,taiki-e,NA https://github.com/rust-lang/rust/pull/54861,MERGED,2018-10-05T23:35:00Z,2018-11-04T04:23:31Z,rustdoc: Replaces fn main search and extern crate search with proper parsing during doctests.,repnop,014c8c4c3872ff74169ffbbc3a69acd92be2a76c,2,implement existing parser fns in terms of fallible fns,THUMBS_UP,2018-10-05T23:36:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54861,MERGED,2018-10-05T23:35:00Z,2018-11-04T04:23:31Z,rustdoc: Replaces fn main search and extern crate search with proper parsing during doctests.,repnop,014c8c4c3872ff74169ffbbc3a69acd92be2a76c,2,implement existing parser fns in terms of fallible fns,HEART,2018-10-10T21:48:37Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/54861,MERGED,2018-10-05T23:35:00Z,2018-11-04T04:23:31Z,rustdoc: Replaces fn main search and extern crate search with proper parsing during doctests.,repnop,014c8c4c3872ff74169ffbbc3a69acd92be2a76c,2,implement existing parser fns in terms of fallible fns,THUMBS_UP,2018-10-12T21:34:22Z,xd009642,NA https://github.com/rust-lang/rust/pull/54861,MERGED,2018-10-05T23:35:00Z,2018-11-04T04:23:31Z,rustdoc: Replaces fn main search and extern crate search with proper parsing during doctests.,repnop,014c8c4c3872ff74169ffbbc3a69acd92be2a76c,2,implement existing parser fns in terms of fallible fns,HEART,2018-11-01T18:22:18Z,estebank,NA https://github.com/rust-lang/rust/pull/54861,MERGED,2018-10-05T23:35:00Z,2018-11-04T04:23:31Z,rustdoc: Replaces fn main search and extern crate search with proper parsing during doctests.,repnop,014c8c4c3872ff74169ffbbc3a69acd92be2a76c,2,implement existing parser fns in terms of fallible fns,HEART,2018-11-01T18:59:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/54862,MERGED,2018-10-06T00:30:24Z,2018-10-11T09:19:44Z,Implement RFC 2539: cfg_attr with multiple attributes,Havvy,bbe832d570e826b2012c09869aa77d6201932730,4,cfg-attr-multi: Change issue number to actual tracking issue,THUMBS_UP,2018-10-07T20:14:37Z,tmandry,NA https://github.com/rust-lang/rust/pull/54870,MERGED,2018-10-06T16:57:41Z,2018-10-11T09:19:45Z,Stabilize tool lints,flip1995,ffe15277ff182b1981b2d46264882bca31b89d13,1,Remove nightly check for tool_lints warning,THUMBS_UP,2018-10-06T17:12:16Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/54870,MERGED,2018-10-06T16:57:41Z,2018-10-11T09:19:45Z,Stabilize tool lints,flip1995,ffe15277ff182b1981b2d46264882bca31b89d13,1,Remove nightly check for tool_lints warning,HOORAY,2018-10-06T18:08:59Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/54870,MERGED,2018-10-06T16:57:41Z,2018-10-11T09:19:45Z,Stabilize tool lints,flip1995,ffe15277ff182b1981b2d46264882bca31b89d13,1,Remove nightly check for tool_lints warning,THUMBS_UP,2018-10-08T21:34:16Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/54870,MERGED,2018-10-06T16:57:41Z,2018-10-11T09:19:45Z,Stabilize tool lints,flip1995,ffe15277ff182b1981b2d46264882bca31b89d13,1,Remove nightly check for tool_lints warning,HOORAY,2018-10-08T21:34:27Z,strega-nil,mazzucan@outlook.com https://github.com/rust-lang/rust/pull/54870,MERGED,2018-10-06T16:57:41Z,2018-10-11T09:19:45Z,Stabilize tool lints,flip1995,ffe15277ff182b1981b2d46264882bca31b89d13,1,Remove nightly check for tool_lints warning,HOORAY,2018-10-18T03:17:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/54891,MERGED,2018-10-07T10:01:47Z,2018-10-12T17:50:50Z,Fix tracking issue for Once::is_completed,SimonSapin,9a9894a8f1f0dbf1acb35947081bbd299fc44968,1,Fix tracking issue for Once::is_completed,HEART,2018-10-07T10:04:08Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/54891,MERGED,2018-10-07T10:01:47Z,2018-10-12T17:50:50Z,Fix tracking issue for Once::is_completed,SimonSapin,9a9894a8f1f0dbf1acb35947081bbd299fc44968,1,Fix tracking issue for Once::is_completed,HEART,2018-10-08T07:19:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54904,MERGED,2018-10-08T08:07:45Z,2018-10-11T09:19:46Z,Stabilize the `Option::replace` method,Kerollmops,c232ea12763b82ae8d4b616df649c23c4961d0fb,1,Bump the `Option::replace` stabilize version to 1.31.0,CONFUSED,2018-10-17T16:01:11Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/54917,MERGED,2018-10-08T19:37:40Z,2018-10-15T16:47:12Z,"Unused result warning: ""X which must"" ↦ ""X that must""",varkor,f5b89062f664c3a0df7638b8493d8120ac4be8a9,10,"Unused result warning: ""X which must"" ↦ ""X that must""",LAUGH,2018-10-09T20:33:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54917,MERGED,2018-10-08T19:37:40Z,2018-10-15T16:47:12Z,"Unused result warning: ""X which must"" ↦ ""X that must""",varkor,f5b89062f664c3a0df7638b8493d8120ac4be8a9,10,"Unused result warning: ""X which must"" ↦ ""X that must""",HEART,2018-10-09T20:33:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54920,MERGED,2018-10-08T20:09:19Z,2018-10-12T17:50:52Z,Fix handling of #[must_use] on unit and uninhabited types,varkor,be8896109af7b939b5c01c4ad1c470904d06f494,3,Fix handling of #[must_use] on unit and uninhabited types,HEART,2018-10-08T20:22:44Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/54920,MERGED,2018-10-08T20:09:19Z,2018-10-12T17:50:52Z,Fix handling of #[must_use] on unit and uninhabited types,varkor,be8896109af7b939b5c01c4ad1c470904d06f494,3,Fix handling of #[must_use] on unit and uninhabited types,HEART,2018-10-17T16:20:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/54920,MERGED,2018-10-08T20:09:19Z,2018-10-12T17:50:52Z,Fix handling of #[must_use] on unit and uninhabited types,varkor,be8896109af7b939b5c01c4ad1c470904d06f494,3,Fix handling of #[must_use] on unit and uninhabited types,HEART,2018-10-22T20:14:46Z,estebank,NA https://github.com/rust-lang/rust/pull/54924,MERGED,2018-10-09T06:59:33Z,2018-10-12T04:45:52Z,Use MaybeUninit in liballoc,RalfJung,e4434be6b7caa1261fa1500d321c20a59f9953b1,1,remove a now outdated comment,HEART,2018-10-11T01:09:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/54946,MERGED,2018-10-10T02:04:41Z,2018-10-17T14:38:47Z,Add filtering option to `rustc_on_unimplemented` and reword `Iterator` E0277 errors,estebank,def0f544a31bc6cc3dbf153f28304219fa38fa5c,1,Change Scalar to numeric cast,HEART,2018-10-11T16:46:25Z,varkor,NA https://github.com/rust-lang/rust/pull/54946,MERGED,2018-10-10T02:04:41Z,2018-10-17T14:38:47Z,Add filtering option to `rustc_on_unimplemented` and reword `Iterator` E0277 errors,estebank,def0f544a31bc6cc3dbf153f28304219fa38fa5c,1,Change Scalar to numeric cast,HEART,2018-10-17T14:43:58Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/54958,MERGED,2018-10-10T09:30:58Z,2018-10-12T17:50:58Z,add a macro for static (compile-time) assertions,RalfJung,a332387b87f850fd3ac8474ff3fc9c83fd70167b,3,add a macro for static assertions,THUMBS_UP,2018-10-11T05:38:16Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/54976,MERGED,2018-10-10T23:30:10Z,2018-10-18T21:13:52Z,NLL lacks various special case handling of closures,davidtwco,d088edc5310518f740df973b6f85d078684152f6,2,Improve check to consider how value is used.,HEART,2018-10-15T18:58:33Z,estebank,NA https://github.com/rust-lang/rust/pull/54977,MERGED,2018-10-10T23:56:30Z,2018-10-25T17:44:48Z,Accept `Option>` in macro argument,estebank,c77a0cf5881e8e894d6fc15403cca002b9781d15,2,Accept `Option>` in macro argument Given the following code compile successfuly: ``` macro_rules! test { ( fn fun() -> Option>; ) => { fn fun(x: $t) -> Option> { Some(Box::new(x)) } } } test! { fn fun() -> Option>; } ```,HEART,2018-10-12T01:03:17Z,tmandry,NA https://github.com/rust-lang/rust/pull/54983,MERGED,2018-10-11T05:55:51Z,2018-10-12T17:51:00Z,Fix slice's benchmarks,kzys,f9300871595196f31305dacd95d53245fd6c0214,1,Fix slice's benchmarks Fixes #54013.,THUMBS_UP,2018-10-11T08:03:00Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/54983,MERGED,2018-10-11T05:55:51Z,2018-10-12T17:51:00Z,Fix slice's benchmarks,kzys,f9300871595196f31305dacd95d53245fd6c0214,1,Fix slice's benchmarks Fixes #54013.,THUMBS_UP,2018-10-12T00:36:20Z,tmandry,NA https://github.com/rust-lang/rust/pull/54991,MERGED,2018-10-11T15:34:19Z,2018-10-15T22:20:53Z,add test for #23189,euclio,3855af573475f7dbdc143b477f73362b7f0723d2,2,add test for #23189 Fixes #23189.,HEART,2018-10-12T00:51:45Z,tmandry,NA https://github.com/rust-lang/rust/pull/55003,MERGED,2018-10-12T06:20:57Z,2018-10-13T19:43:55Z,`#[must_use]` for associated functions is supposed to actually work,zackmdavis,ab91a6b4df04a60cf19682b1f016848d3e4784ad,6,"`#[must_use]` for associated functions is supposed to actually work In the comments of (closed defunct) pull request #54884 Mazdak ""Centril"" Farrokhzad noted that must-use annotations didn't work on an associated function (what other communities might call a ""static method""). Subsequent logging revealed that in this case we have a `Def::Method` whereas the lint pass was only matching on `Def::Fn`. (One could argue that those def-names are thereby misleading—must-use for self-ful methods have always worked—but documenting or reworking that can be left to another day.)",HEART,2018-10-22T20:14:33Z,estebank,NA https://github.com/rust-lang/rust/pull/55010,MERGED,2018-10-12T13:36:48Z,2018-12-03T14:32:18Z,Add template parameter debuginfo to generic types,tromey,fb204cb92f5da2cd0b630ee4b6be85b02404823e,9,Add template parameter debuginfo to generic types This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types not just for functions like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string offset: 0x375): Generic <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string offset: 0xa65e): T Closes #9224,HEART,2018-10-17T21:25:23Z,cramertj,NA https://github.com/rust-lang/rust/pull/55010,MERGED,2018-10-12T13:36:48Z,2018-12-03T14:32:18Z,Add template parameter debuginfo to generic types,tromey,fb204cb92f5da2cd0b630ee4b6be85b02404823e,9,Add template parameter debuginfo to generic types This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types not just for functions like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string offset: 0x375): Generic <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string offset: 0xa65e): T Closes #9224,HEART,2018-11-09T21:25:33Z,ortem,ortem00@gmail.com https://github.com/rust-lang/rust/pull/55010,MERGED,2018-10-12T13:36:48Z,2018-12-03T14:32:18Z,Add template parameter debuginfo to generic types,tromey,fb204cb92f5da2cd0b630ee4b6be85b02404823e,9,Add template parameter debuginfo to generic types This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types not just for functions like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string offset: 0x375): Generic <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string offset: 0xa65e): T Closes #9224,HEART,2018-12-02T04:30:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55010,MERGED,2018-10-12T13:36:48Z,2018-12-03T14:32:18Z,Add template parameter debuginfo to generic types,tromey,fb204cb92f5da2cd0b630ee4b6be85b02404823e,9,Add template parameter debuginfo to generic types This changes debuginfo generation to add template parameters to generic types. With this change the DWARF now has DW_TAG_template_type_param for types not just for functions like: <2><40d>: Abbrev Number: 6 (DW_TAG_structure_type) <40e> DW_AT_name : (indirect string offset: 0x375): Generic <412> DW_AT_byte_size : 4 <413> DW_AT_alignment : 4 ... <3><41f>: Abbrev Number: 8 (DW_TAG_template_type_param) <420> DW_AT_type : <0x42a> <424> DW_AT_name : (indirect string offset: 0xa65e): T Closes #9224,HEART,2018-12-13T06:03:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55011,MERGED,2018-10-12T13:56:54Z,2018-11-30T22:01:13Z,"Add libstd Cargo feature ""panic_immediate_abort""",vi,f18a8c6163fa3b1eef5aabd1baf1eef2b9789c46,2,Fix exceeding line width limit,HEART,2021-08-23T14:23:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55025,MERGED,2018-10-13T00:54:04Z,2018-10-15T22:20:55Z,Add missing lifetime fragment specifier to error message.,ehuss,09f42dd9029f0913355a9c52d6a0c6642f0e6e52,4,Add missing lifetime fragment specifier to error message. A very minor issue `lifetime` was missing from the error list. I left `literal` in the list even though it is unstable. It looks like it may stabilize soon anyways.,HEART,2018-10-15T16:53:48Z,estebank,NA https://github.com/rust-lang/rust/pull/55041,MERGED,2018-10-13T14:55:29Z,2018-12-04T01:03:24Z,targets: thumbv8m: Add target for baseline ARMv8-M,evq,8a0666d5cc2def02e64b1090efc494d81a0b8dd1,2,rename to thumbv8m.base-none-eabi fix strict alignment,THUMBS_UP,2018-10-13T17:55:11Z,parched,NA https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2018-10-13T18:03:31Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2018-10-18T06:48:27Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2019-01-19T09:02:11Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2019-01-23T09:21:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2019-01-23T09:43:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55045,MERGED,2018-10-13T17:12:45Z,2019-01-21T16:40:39Z,Add `is_sorted` to `Iterator` and `[T]`,kleimkuhler,b4766f80775a2635c026626070201356f33d2700,1,Correct error location indicated by comments,THUMBS_UP,2019-01-23T09:58:22Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55046,MERGED,2018-10-13T17:16:38Z,2018-10-15T00:18:30Z,[mir-inlining] Don't inline virtual calls,wesleywiser,69eaa11633b1279d4f2edb734e541f545d583b0a,2,[mir-inlining] Don't inline virtual calls Prior to this change the test case would output `1` instead of `2` like it should.,THUMBS_UP,2018-10-15T12:30:43Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55046,MERGED,2018-10-13T17:16:38Z,2018-10-15T00:18:30Z,[mir-inlining] Don't inline virtual calls,wesleywiser,69eaa11633b1279d4f2edb734e541f545d583b0a,2,[mir-inlining] Don't inline virtual calls Prior to this change the test case would output `1` instead of `2` like it should.,THUMBS_UP,2018-10-25T06:08:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55051,MERGED,2018-10-13T21:34:30Z,2018-10-14T14:24:41Z,boostrap: dist: if a file cannot be installed because it does not exist print its name in the error message.,matthiaskrgr,da1c75c3a6666e94d087cd55d0709328ce906442,1,boostrap: dist: if a file cannot be installed because it does not exist print its name in the error message.,THUMBS_UP,2018-10-14T09:50:22Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55071,MERGED,2018-10-14T15:42:53Z,2018-10-19T12:14:39Z,Fix ICE and report a human readable error,oli-obk,38f3ad41c0bbf6ed7c389a070afb60a465b3afe3,1,Squash closure cast error into fn ptr cast error,HEART,2018-10-15T16:51:49Z,estebank,NA https://github.com/rust-lang/rust/pull/55071,MERGED,2018-10-14T15:42:53Z,2018-10-19T12:14:39Z,Fix ICE and report a human readable error,oli-obk,38f3ad41c0bbf6ed7c389a070afb60a465b3afe3,1,Squash closure cast error into fn ptr cast error,HEART,2018-10-27T18:11:09Z,Voultapher,NA https://github.com/rust-lang/rust/pull/55073,MERGED,2018-10-14T19:35:12Z,2018-10-21T01:06:46Z,rustc: Fix (again) simd vectors by-val in ABI,alexcrichton,3cc8f738d4247a9b475d8e074b621e602ac2b7be,9,rustc: Fix (again) simd vectors by-val in ABI The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion] and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to again try to fix this issue. The fundamental problem here remains the same if a SIMD vector argument is passed by-value in LLVM's function type then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We just before codegen will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working and it unfortunately is likely producing suboptimal code even in release mode. The saving grace for this in theory is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154,HOORAY,2018-10-14T23:27:28Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/55073,MERGED,2018-10-14T19:35:12Z,2018-10-21T01:06:46Z,rustc: Fix (again) simd vectors by-val in ABI,alexcrichton,3cc8f738d4247a9b475d8e074b621e602ac2b7be,9,rustc: Fix (again) simd vectors by-val in ABI The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion] and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to again try to fix this issue. The fundamental problem here remains the same if a SIMD vector argument is passed by-value in LLVM's function type then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We just before codegen will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working and it unfortunately is likely producing suboptimal code even in release mode. The saving grace for this in theory is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154,HOORAY,2018-10-19T21:18:18Z,holloway,matthew@holloway.co.nz https://github.com/rust-lang/rust/pull/55073,MERGED,2018-10-14T19:35:12Z,2018-10-21T01:06:46Z,rustc: Fix (again) simd vectors by-val in ABI,alexcrichton,3cc8f738d4247a9b475d8e074b621e602ac2b7be,9,rustc: Fix (again) simd vectors by-val in ABI The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion] and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to again try to fix this issue. The fundamental problem here remains the same if a SIMD vector argument is passed by-value in LLVM's function type then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We just before codegen will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working and it unfortunately is likely producing suboptimal code even in release mode. The saving grace for this in theory is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154,HOORAY,2018-10-21T00:41:10Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/55073,MERGED,2018-10-14T19:35:12Z,2018-10-21T01:06:46Z,rustc: Fix (again) simd vectors by-val in ABI,alexcrichton,3cc8f738d4247a9b475d8e074b621e602ac2b7be,9,rustc: Fix (again) simd vectors by-val in ABI The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion] and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to again try to fix this issue. The fundamental problem here remains the same if a SIMD vector argument is passed by-value in LLVM's function type then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We just before codegen will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working and it unfortunately is likely producing suboptimal code even in release mode. The saving grace for this in theory is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154,THUMBS_UP,2018-10-22T19:08:51Z,jackmott,jack.mott@gmail.com https://github.com/rust-lang/rust/pull/55073,MERGED,2018-10-14T19:35:12Z,2018-10-21T01:06:46Z,rustc: Fix (again) simd vectors by-val in ABI,alexcrichton,3cc8f738d4247a9b475d8e074b621e602ac2b7be,9,rustc: Fix (again) simd vectors by-val in ABI The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion] and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to again try to fix this issue. The fundamental problem here remains the same if a SIMD vector argument is passed by-value in LLVM's function type then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We just before codegen will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working and it unfortunately is likely producing suboptimal code even in release mode. The saving grace for this in theory is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass only doing the reverse. In local testing this... Closes #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154,HOORAY,2018-10-25T06:14:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55077,MERGED,2018-10-15T00:07:48Z,2018-10-18T09:53:23Z,rustdoc: Use dyn keyword when rendering dynamic traits,ollie27,86d5a33c890404da65c48925525af06b9b68a0ac,4,rustdoc: Use dyn keyword when rendering dynamic traits The dyn keyword has been stable for a while now so rustdoc should start using it.,THUMBS_UP,2018-10-24T22:07:40Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/55087,MERGED,2018-10-15T08:53:26Z,2018-11-02T21:27:53Z,rustc: improve E0669 span,levex,46b9461c4b77bf51528c81207e190d74be63ca10,2,Add a test for multiple cases of E0669 Signed-off-by: Levente Kurusa ,HEART,2018-10-15T16:50:32Z,estebank,NA https://github.com/rust-lang/rust/pull/55101,MERGED,2018-10-15T18:57:02Z,2018-11-03T20:13:58Z,Implement trait aliases (RFC 1733),alexreg,417168587beda80b97e9de83b61cbb8517a61dbc,4,Fixed bug with Self type param coming before lifetimes.,HOORAY,2018-10-16T00:29:02Z,durka,NA https://github.com/rust-lang/rust/pull/55101,MERGED,2018-10-15T18:57:02Z,2018-11-03T20:13:58Z,Implement trait aliases (RFC 1733),alexreg,417168587beda80b97e9de83b61cbb8517a61dbc,4,Fixed bug with Self type param coming before lifetimes.,HOORAY,2018-10-30T04:50:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/55101,MERGED,2018-10-15T18:57:02Z,2018-11-03T20:13:58Z,Implement trait aliases (RFC 1733),alexreg,417168587beda80b97e9de83b61cbb8517a61dbc,4,Fixed bug with Self type param coming before lifetimes.,HOORAY,2018-11-05T08:48:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55101,MERGED,2018-10-15T18:57:02Z,2018-11-03T20:13:58Z,Implement trait aliases (RFC 1733),alexreg,417168587beda80b97e9de83b61cbb8517a61dbc,4,Fixed bug with Self type param coming before lifetimes.,HOORAY,2018-11-07T05:22:13Z,hcpl,NA https://github.com/rust-lang/rust/pull/55119,MERGED,2018-10-16T13:58:15Z,2018-10-20T17:37:41Z,Allow explicit matches on ! without warning,varkor,26346467c52e34c730f3e924be7d635d69b4f737,3,Warning about unreachable arms after matching on a diverging type,HEART,2018-10-16T14:31:30Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55119,MERGED,2018-10-16T13:58:15Z,2018-10-20T17:37:41Z,Allow explicit matches on ! without warning,varkor,26346467c52e34c730f3e924be7d635d69b4f737,3,Warning about unreachable arms after matching on a diverging type,HEART,2018-10-25T06:10:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55128,MERGED,2018-10-16T17:20:11Z,2018-10-18T09:53:29Z,Fix LLVMRustInlineAsmVerify return type mismatch,varkor,f40932f106d3670a4b2041d54bf37fa3f49c20f2,2,Fix LLVMRustInlineAsmVerify return type mismatch,HEART,2018-10-16T17:22:10Z,levex,lev@boilerplate.co https://github.com/rust-lang/rust/pull/55148,MERGED,2018-10-17T13:55:28Z,2018-10-28T18:50:02Z,Implement FromStr for PathBuf,SimonSapin,a0df4204c49975d3a5fb9c3a6562d49faf130b01,1,Implement FromStr for PathBuf Initially landed in https://github.com/rust-lang/rust/pull/48292 and reverted in https://github.com/rust-lang/rust/pull/50401. This time use `std::string::ParseError` as suggested in https://github.com/rust-lang/rust/issues/44431#issuecomment-428112632,HOORAY,2018-10-17T13:57:09Z,mitsuhiko,armin.ronacher@active-4.com https://github.com/rust-lang/rust/pull/55148,MERGED,2018-10-17T13:55:28Z,2018-10-28T18:50:02Z,Implement FromStr for PathBuf,SimonSapin,a0df4204c49975d3a5fb9c3a6562d49faf130b01,1,Implement FromStr for PathBuf Initially landed in https://github.com/rust-lang/rust/pull/48292 and reverted in https://github.com/rust-lang/rust/pull/50401. This time use `std::string::ParseError` as suggested in https://github.com/rust-lang/rust/issues/44431#issuecomment-428112632,HEART,2018-10-17T13:57:11Z,mitsuhiko,armin.ronacher@active-4.com https://github.com/rust-lang/rust/pull/55148,MERGED,2018-10-17T13:55:28Z,2018-10-28T18:50:02Z,Implement FromStr for PathBuf,SimonSapin,a0df4204c49975d3a5fb9c3a6562d49faf130b01,1,Implement FromStr for PathBuf Initially landed in https://github.com/rust-lang/rust/pull/48292 and reverted in https://github.com/rust-lang/rust/pull/50401. This time use `std::string::ParseError` as suggested in https://github.com/rust-lang/rust/issues/44431#issuecomment-428112632,THUMBS_UP,2018-10-20T04:12:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55148,MERGED,2018-10-17T13:55:28Z,2018-10-28T18:50:02Z,Implement FromStr for PathBuf,SimonSapin,a0df4204c49975d3a5fb9c3a6562d49faf130b01,1,Implement FromStr for PathBuf Initially landed in https://github.com/rust-lang/rust/pull/48292 and reverted in https://github.com/rust-lang/rust/pull/50401. This time use `std::string::ParseError` as suggested in https://github.com/rust-lang/rust/issues/44431#issuecomment-428112632,THUMBS_UP,2018-10-24T16:51:57Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55152,MERGED,2018-10-17T15:10:17Z,2018-10-19T22:54:33Z,support type annot in constants casts,nikomatsakis,9a7bb0ef249258aacf144d04f5d437ba70533128,2,normalize the self-type that we extract from impl,LAUGH,2018-10-19T11:13:58Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/55156,MERGED,2018-10-17T16:17:27Z,2018-10-20T22:23:53Z,Fixed: Multiple errors on single typo in match pattern,PramodBisht,978dc3d66f5e9a3bea733aca664e25b845fa0f27,5,"Fixed: Multiple errors on single typo in match pattern Here we have fixed the case where we were throwing two diagnostic messages `E0026` and `E0027` for same case like this Example error[E0026]: variant `A::A` does not have a field named `fob` --> src/test/ui/issue-52717.rs:20:12 | 20 | A::A { fob } => { println!(""{}"" fob); } | ^^^ variant `A::A` does not have this field error[E0027]: pattern does not mention field `foo` --> src/test/ui/issue-52717.rs:20:5 | 20 | A::A { fob } => { println!(""{}"" fob); } | ^^^^^^^^^^^^ missing field `foo` error: aborting due to 2 previous errors Here above we can see that both `E0026` and `E0027` are depicting same thing. So to fix this issue we are simply checking element of `inexistent_fields` is there any value lies in `unmentioned_fields` using Levenshtein algorithm if does then for that case we are simply deleting element from `unmentioned_fields`. More or less now instead of showing separate message in `E0027` we are giving extra hint on `E0026` Address: #52717",HEART,2018-10-17T17:01:34Z,estebank,NA https://github.com/rust-lang/rust/pull/55156,MERGED,2018-10-17T16:17:27Z,2018-10-20T22:23:53Z,Fixed: Multiple errors on single typo in match pattern,PramodBisht,978dc3d66f5e9a3bea733aca664e25b845fa0f27,5,"Fixed: Multiple errors on single typo in match pattern Here we have fixed the case where we were throwing two diagnostic messages `E0026` and `E0027` for same case like this Example error[E0026]: variant `A::A` does not have a field named `fob` --> src/test/ui/issue-52717.rs:20:12 | 20 | A::A { fob } => { println!(""{}"" fob); } | ^^^ variant `A::A` does not have this field error[E0027]: pattern does not mention field `foo` --> src/test/ui/issue-52717.rs:20:5 | 20 | A::A { fob } => { println!(""{}"" fob); } | ^^^^^^^^^^^^ missing field `foo` error: aborting due to 2 previous errors Here above we can see that both `E0026` and `E0027` are depicting same thing. So to fix this issue we are simply checking element of `inexistent_fields` is there any value lies in `unmentioned_fields` using Levenshtein algorithm if does then for that case we are simply deleting element from `unmentioned_fields`. More or less now instead of showing separate message in `E0027` we are giving extra hint on `E0026` Address: #52717",HEART,2018-10-25T06:16:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55162,MERGED,2018-10-17T21:21:14Z,2018-10-20T01:31:29Z,handle underscore bounds in unexpected places,nikomatsakis,c294ec640be6b4cdd3b4922a622a6c12f6078b1d,9,add more to the ERROR messages,HEART,2018-10-19T07:38:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-10-18T14:17:39Z,nathansgreen,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-11-02T16:12:56Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-11-17T17:28:41Z,xerz-one,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-11-22T15:46:10Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-11-23T14:52:44Z,mati865,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-12-06T01:40:12Z,whoizit,whoami@systemli.org https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2018-12-28T09:27:31Z,z64,zachnowicki@gmail.com https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2019-01-02T02:46:53Z,benjaminboruff,benboruff@gmail.com https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2019-01-05T21:13:37Z,martell,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2019-01-05T21:51:44Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2019-01-06T20:56:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2019-08-06T02:46:19Z,camelmasa,camelmasa@gmail.com https://github.com/rust-lang/rust/pull/55163,CLOSED,2018-10-17T21:26:05Z,2019-01-07T22:08:02Z,Add x86_64-musl as a host architecture,strfry,NA,NA,NA,THUMBS_UP,2020-11-12T05:20:31Z,anirudhb,NA https://github.com/rust-lang/rust/pull/55167,MERGED,2018-10-18T00:41:31Z,2018-10-26T20:08:27Z,"Add a ""cheap"" mode for `compute_missing_ctors`.",nnethercote,b5336c0b9755f635db4eafba6254e192ee451e6a,1,Add a cheap mode for `compute_missing_ctors`. `compute_missing_ctors` is called a lot. It produces a vector which can be reasonably large (e.g. 100+ elements) but the vector is almost always only checked for emptiness. This commit changes `compute_missing_ctors` so it can be called in a cheap way that just indicates if the vector would be empty. If necessary the function can subsequently be called in an expensive way to compute the full vector. This change reduces instruction counts for several benchmarks up to 2%.,THUMBS_UP,2018-10-18T15:27:40Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/55167,MERGED,2018-10-18T00:41:31Z,2018-10-26T20:08:27Z,"Add a ""cheap"" mode for `compute_missing_ctors`.",nnethercote,b5336c0b9755f635db4eafba6254e192ee451e6a,1,Add a cheap mode for `compute_missing_ctors`. `compute_missing_ctors` is called a lot. It produces a vector which can be reasonably large (e.g. 100+ elements) but the vector is almost always only checked for emptiness. This commit changes `compute_missing_ctors` so it can be called in a cheap way that just indicates if the vector would be empty. If necessary the function can subsequently be called in an expensive way to compute the full vector. This change reduces instruction counts for several benchmarks up to 2%.,THUMBS_UP,2018-10-19T12:31:51Z,varkor,NA https://github.com/rust-lang/rust/pull/55167,MERGED,2018-10-18T00:41:31Z,2018-10-26T20:08:27Z,"Add a ""cheap"" mode for `compute_missing_ctors`.",nnethercote,b5336c0b9755f635db4eafba6254e192ee451e6a,1,Add a cheap mode for `compute_missing_ctors`. `compute_missing_ctors` is called a lot. It produces a vector which can be reasonably large (e.g. 100+ elements) but the vector is almost always only checked for emptiness. This commit changes `compute_missing_ctors` so it can be called in a cheap way that just indicates if the vector would be empty. If necessary the function can subsequently be called in an expensive way to compute the full vector. This change reduces instruction counts for several benchmarks up to 2%.,THUMBS_UP,2018-11-02T09:52:34Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/55169,MERGED,2018-10-18T01:32:35Z,2018-10-19T12:14:43Z,Add a `copysign` function to f32 and f64,raphlinus,f08db6bf1ee44dd1bc8c4d3ddcea1425fcd8d118,2,Add must_use on copysign Added a #[must_use] annotation on copysign per review feedback.,HEART,2018-10-18T20:17:57Z,tmandry,NA https://github.com/rust-lang/rust/pull/55190,MERGED,2018-10-18T23:32:41Z,2018-10-30T03:58:13Z,Rename other occs of (Code/File)Map to Source(Map/File) #51574,dlavati,6c9f6a1afdd60603ddb7ab28755fbc134b7d4844,13,Rename other occs of (Code/File)Map to Source(Map/File) #51574,HOORAY,2018-11-03T09:34:22Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/55207,CLOSED,2018-10-19T16:23:49Z,2018-11-13T18:39:24Z,Implement Copy and Clone for UnsafeCell,jamesmunns,NA,NA,NA,THUMBS_UP,2018-10-19T17:00:45Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/55213,MERGED,2018-10-19T20:23:41Z,2018-10-21T01:06:52Z,ignore target folders,qmx,cf90f72f55240686be268e9f6929e9bbec678616,1,ignore target folders when you try to edit a crate inside the compiler tree using rls it generates it's assets under target/rls then tidy is trying to validate line lenghts for C headers etc,HEART,2018-10-19T21:47:05Z,tmandry,NA https://github.com/rust-lang/rust/pull/55221,MERGED,2018-10-20T09:11:06Z,2018-10-30T06:35:14Z,Don't emit cannot move errors twice in migrate mode,matthewjasper,42a541e0f152441204a00ae77dc23a82bf1fec02,44,Don't emit cannot move errors twice in migrate mode,HEART,2018-10-24T18:06:44Z,estebank,NA https://github.com/rust-lang/rust/pull/55224,MERGED,2018-10-20T12:29:28Z,2018-10-22T06:18:42Z,Use a keyword in raw identifier example,kryptan,e10f0cd07db1be8579cd6fd4f3da7cd94502a18c,1,Use a keyword in raw identifier example,HEART,2018-10-24T02:46:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T12:19:03Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T13:58:15Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T15:07:47Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T15:39:07Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T15:42:31Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-10-21T15:50:02Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-10-21T18:53:51Z,estebank,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-21T21:11:36Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-22T01:12:31Z,qnighy,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-10-22T01:12:34Z,qnighy,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-23T07:52:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-10-23T08:14:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-10-30T04:48:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-03T17:57:33Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-11-03T17:57:33Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-11-03T18:19:44Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-03T19:19:21Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-03T19:49:31Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-03T20:36:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-04T15:09:49Z,natpen,natpen@natpen.net https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HEART,2018-11-04T15:09:50Z,natpen,natpen@natpen.net https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-04T15:15:33Z,discosultan,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-07T14:27:44Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-07T18:46:49Z,jq-rs,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-07T19:13:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,THUMBS_UP,2018-11-07T20:29:12Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,HOORAY,2018-11-27T00:06:22Z,hcpl,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,THUMBS_UP,2019-01-10T04:02:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/55238,MERGED,2018-10-21T02:21:07Z,2018-11-03T12:11:37Z,Remove the `alloc_jemalloc` crate,alexcrichton,14c6835e03b285f7c73459ca851848fe8513b7a5,3,rustc: Wait for all codegen threads to exit This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238 and hopefully we'll see whether this actually fixes things in practice...,THUMBS_UP,2019-03-28T19:20:02Z,superblaubeere27,NA https://github.com/rust-lang/rust/pull/55244,MERGED,2018-10-21T15:03:33Z,2018-10-28T18:50:07Z,Don't rerun MIR passes when inlining,wesleywiser,4655866a11ddb345c84781cf4e292e99e26ee9fe,2,Fix CR feedback,HOORAY,2018-10-21T16:01:27Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55260,CLOSED,2018-10-22T11:12:00Z,2018-11-06T18:18:37Z,Get rid of the `Scalar` and `ScalarPair` variants of `ConstValue`...,oli-obk,NA,NA,NA,HOORAY,2018-10-22T13:01:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55264,MERGED,2018-10-22T15:06:48Z,2018-10-26T20:08:32Z,Compile the libstd we distribute with -Ccodegen-unit=1,michaelwoerister,5dedf0cead430d2cfef6e3957c26d066fb1a40eb,1,CI: Set codegen-units-std=1 for dist builds.,HEART,2018-10-24T02:53:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55264,MERGED,2018-10-22T15:06:48Z,2018-10-26T20:08:32Z,Compile the libstd we distribute with -Ccodegen-unit=1,michaelwoerister,5dedf0cead430d2cfef6e3957c26d066fb1a40eb,1,CI: Set codegen-units-std=1 for dist builds.,HEART,2018-10-24T20:12:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55264,MERGED,2018-10-22T15:06:48Z,2018-10-26T20:08:32Z,Compile the libstd we distribute with -Ccodegen-unit=1,michaelwoerister,5dedf0cead430d2cfef6e3957c26d066fb1a40eb,1,CI: Set codegen-units-std=1 for dist builds.,HEART,2018-10-26T14:02:11Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55275,MERGED,2018-10-22T22:33:40Z,2018-12-01T15:15:15Z,experiment: Support aliasing local crate root in extern prelude,petrochenkov,549bd45e9eb13e501416e17887b65ad4189ebe6b,9,resolve: Support aliasing local crate root in extern prelude,THUMBS_UP,2018-11-03T09:36:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/55278,MERGED,2018-10-23T01:13:12Z,2018-11-12T21:55:57Z,Minor standard library constification,Centril,ac1c6b0378789250a5070772ad18e936949c7a3c,2,adjust ui/../mod-static-with-const-fn.rs,HEART,2018-10-24T03:41:00Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/55278,MERGED,2018-10-23T01:13:12Z,2018-11-12T21:55:57Z,Minor standard library constification,Centril,ac1c6b0378789250a5070772ad18e936949c7a3c,2,adjust ui/../mod-static-with-const-fn.rs,THUMBS_UP,2018-11-06T10:36:09Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55278,MERGED,2018-10-23T01:13:12Z,2018-11-12T21:55:57Z,Minor standard library constification,Centril,ac1c6b0378789250a5070772ad18e936949c7a3c,2,adjust ui/../mod-static-with-const-fn.rs,HOORAY,2018-11-07T15:49:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55278,MERGED,2018-10-23T01:13:12Z,2018-11-12T21:55:57Z,Minor standard library constification,Centril,ac1c6b0378789250a5070772ad18e936949c7a3c,2,adjust ui/../mod-static-with-const-fn.rs,HOORAY,2018-11-14T16:17:58Z,bluss,NA https://github.com/rust-lang/rust/pull/55278,MERGED,2018-10-23T01:13:12Z,2018-11-12T21:55:57Z,Minor standard library constification,Centril,ac1c6b0378789250a5070772ad18e936949c7a3c,2,adjust ui/../mod-static-with-const-fn.rs,HOORAY,2018-11-26T05:29:37Z,hcpl,NA https://github.com/rust-lang/rust/pull/55296,MERGED,2018-10-23T22:39:49Z,2018-10-25T17:45:05Z,Set RUST_BACKTRACE=0 for rustdoc-ui/failed-doctest-output.rs,cuviper,f2443a9b2005865a0e9c8b3163ec47e82d87f503,2,Set RUST_BACKTRACE=0 for rustdoc-ui/failed-doctest-output.rs This UI test is sensitive to backtrace output so it should make sure that backtraces are not enabled by the environment.,THUMBS_UP,2018-10-24T15:12:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/55302,MERGED,2018-10-24T07:45:09Z,2018-10-26T20:08:36Z,Extend the impl_stable_hash_for! macro for miri.,goffrie,4747d83c7059049ddb088c3d0087ab9e501bbf9a,2,Extend the impl_stable_hash_for! macro for miri.,HEART,2018-10-24T09:20:56Z,varkor,NA https://github.com/rust-lang/rust/pull/55315,MERGED,2018-10-24T14:29:13Z,2018-10-24T22:31:06Z,Stable release 1.30,pietroalbini,4a0c8d12f73e93af70e363fced9f335d26eb149d,1,1.30.0 stable release,HOORAY,2018-10-24T22:32:16Z,ehuss,NA https://github.com/rust-lang/rust/pull/55325,MERGED,2018-10-24T19:34:01Z,2018-10-26T20:08:38Z,Fix link to macros chapter,steveklabnik,ee26e8edebd16b1d11e2af686a12143826fa46fb,1,Update RELEASES.md Co-Authored-By: steveklabnik ,THUMBS_UP,2018-10-25T07:33:06Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55325,MERGED,2018-10-24T19:34:01Z,2018-10-26T20:08:38Z,Fix link to macros chapter,steveklabnik,ee26e8edebd16b1d11e2af686a12143826fa46fb,1,Update RELEASES.md Co-Authored-By: steveklabnik ,THUMBS_UP,2018-10-25T15:20:50Z,CoolOppo,NA https://github.com/rust-lang/rust/pull/55325,MERGED,2018-10-24T19:34:01Z,2018-10-26T20:08:38Z,Fix link to macros chapter,steveklabnik,ee26e8edebd16b1d11e2af686a12143826fa46fb,1,Update RELEASES.md Co-Authored-By: steveklabnik ,THUMBS_UP,2018-10-25T18:54:58Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/55328,MERGED,2018-10-24T22:22:16Z,2018-10-25T17:45:08Z,Fix doc for new copysign functions,raphlinus,538f65eb617f5d4596cf0d263e48998a70137ce1,2,Fix doc for new copysign functions Thanks to @LukasKalbertodt for catching this. Addresses a comment raised in #55169 after it was merged.,THUMBS_UP,2018-10-24T22:24:33Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/55355,CLOSED,2018-10-25T18:52:02Z,2018-11-12T23:02:24Z,Add Iterator::single,Centril,NA,NA,NA,THUMBS_UP,2018-10-27T02:01:22Z,gurry,NA https://github.com/rust-lang/rust/pull/55355,CLOSED,2018-10-25T18:52:02Z,2018-11-12T23:02:24Z,Add Iterator::single,Centril,NA,NA,NA,THUMBS_UP,2018-10-27T16:00:47Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/55355,CLOSED,2018-10-25T18:52:02Z,2018-11-12T23:02:24Z,Add Iterator::single,Centril,NA,NA,NA,CONFUSED,2018-11-10T02:43:19Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/55359,MERGED,2018-10-25T19:48:04Z,2018-11-02T07:04:24Z,Fixes #46775 -- don't mutate the process's environment in Command::exec,alex,36fe3b605a7a7143a14565272140ba1b43c1b041,3,Fixes #46775 -- don't mutate the process's environment in Command::exec Instead pass the environment to execvpe so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason as well as a race condition if there are other threads alive during the exec.,HEART,2018-10-25T19:49:00Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/55366,MERGED,2018-10-25T22:54:58Z,2018-11-08T09:39:00Z,Add tracking issue for Layout methods (and some API changes),Amanieu,02d50de63e50423c9cbaf3daa46dde6c9c5c9dba,3,Add a tracking issue for extra Layout methods,HOORAY,2018-10-25T23:04:41Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55366,MERGED,2018-10-25T22:54:58Z,2018-11-08T09:39:00Z,Add tracking issue for Layout methods (and some API changes),Amanieu,02d50de63e50423c9cbaf3daa46dde6c9c5c9dba,3,Add a tracking issue for extra Layout methods,HOORAY,2018-10-26T13:20:55Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55366,MERGED,2018-10-25T22:54:58Z,2018-11-08T09:39:00Z,Add tracking issue for Layout methods (and some API changes),Amanieu,02d50de63e50423c9cbaf3daa46dde6c9c5c9dba,3,Add a tracking issue for extra Layout methods,HOORAY,2018-10-30T05:30:25Z,RicoGit,constantine.solovev@gmail.com https://github.com/rust-lang/rust/pull/55366,MERGED,2018-10-25T22:54:58Z,2018-11-08T09:39:00Z,Add tracking issue for Layout methods (and some API changes),Amanieu,02d50de63e50423c9cbaf3daa46dde6c9c5c9dba,3,Add a tracking issue for extra Layout methods,HOORAY,2018-11-03T20:58:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55423,MERGED,2018-10-27T22:11:12Z,2018-10-29T13:11:25Z,back out bogus `Ok`-wrapping suggestion on `?` arm type mismatch,zackmdavis,b7546150b2f372bc31f908c41c0078936c3d8b66,4,back out bogus `Ok`-wrapping suggestion on `?` arm type mismatch This suggestion was introduced in #51938 / 6cc78bf8d7 (while introducing different language for type errors coming from `?` rather than a `match`) but it has a lot of false-positives (as repeatedly reported in Issues #52537 #52598 #54578 #55336) and incorrect suggestions carry more badness than marginal good suggestions do goodness. Just get rid of it (unless and until someone figures out how to do it correctly). Resolves #52537 resolves #54578.,THUMBS_UP,2018-10-28T16:07:15Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-10-28T08:38:37Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HEART,2018-10-28T08:38:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-10-28T11:33:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HEART,2018-10-28T11:33:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-10-28T13:38:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-10-30T06:43:36Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-10-31T03:43:03Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HEART,2018-11-02T20:11:04Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-11-03T20:58:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-11-05T17:48:00Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2018-11-10T11:23:57Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2019-02-03T01:01:17Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2019-02-06T17:39:39Z,koute,NA https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2019-02-12T13:19:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2019-04-01T05:39:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HOORAY,2019-05-24T11:02:50Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/55431,CLOSED,2018-10-28T06:57:04Z,2019-03-11T13:01:04Z,Unsized rvalues: implement boxed closure impls.,qnighy,NA,NA,NA,HEART,2019-05-24T11:02:51Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/55448,MERGED,2018-10-28T16:30:31Z,2019-04-03T08:32:35Z,Add 'partition_at_index/_by/_by_key' for slices.,Mokosha,3f306db3dbe390f43c7dfa8e17630747723e39e3,4,"Add initial implementation of 'sort_at_index' for slices -- analog to C++'s std::nth_element (a.k.a. quickselect) Add some more notes to the documentation: - Mention that the median can be found if we used `len() / 2`. - Mention that this function is usually called ""kth element"" in other libraries. Address some comments in PR: - Change wording on some of the documentation - Change recursive function into a loop Update name to `partition_at_index` and add convenience return values. Address reviewer comments: - Don't swap on each iteration when searching for min/max element. - Add some docs about when we panic. - Test that the sum of the lengths of the output matches the length of the input. - Style fix for for-loop. Address more reviewer comments Fix Rng stuff for test Fix doc test build Don't run the partition_at_index test on wasm targets Miri does not support entropy for test partition_at_index",THUMBS_UP,2019-08-04T09:47:31Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/55448,MERGED,2018-10-28T16:30:31Z,2019-04-03T08:32:35Z,Add 'partition_at_index/_by/_by_key' for slices.,Mokosha,3f306db3dbe390f43c7dfa8e17630747723e39e3,4,"Add initial implementation of 'sort_at_index' for slices -- analog to C++'s std::nth_element (a.k.a. quickselect) Add some more notes to the documentation: - Mention that the median can be found if we used `len() / 2`. - Mention that this function is usually called ""kth element"" in other libraries. Address some comments in PR: - Change wording on some of the documentation - Change recursive function into a loop Update name to `partition_at_index` and add convenience return values. Address reviewer comments: - Don't swap on each iteration when searching for min/max element. - Add some docs about when we panic. - Test that the sum of the lengths of the output matches the length of the input. - Style fix for for-loop. Address more reviewer comments Fix Rng stuff for test Fix doc test build Don't run the partition_at_index test on wasm targets Miri does not support entropy for test partition_at_index",HEART,2019-08-04T09:47:35Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/55448,MERGED,2018-10-28T16:30:31Z,2019-04-03T08:32:35Z,Add 'partition_at_index/_by/_by_key' for slices.,Mokosha,3f306db3dbe390f43c7dfa8e17630747723e39e3,4,"Add initial implementation of 'sort_at_index' for slices -- analog to C++'s std::nth_element (a.k.a. quickselect) Add some more notes to the documentation: - Mention that the median can be found if we used `len() / 2`. - Mention that this function is usually called ""kth element"" in other libraries. Address some comments in PR: - Change wording on some of the documentation - Change recursive function into a loop Update name to `partition_at_index` and add convenience return values. Address reviewer comments: - Don't swap on each iteration when searching for min/max element. - Add some docs about when we panic. - Test that the sum of the lengths of the output matches the length of the input. - Style fix for for-loop. Address more reviewer comments Fix Rng stuff for test Fix doc test build Don't run the partition_at_index test on wasm targets Miri does not support entropy for test partition_at_index",THUMBS_UP,2020-06-17T17:11:16Z,function2-llx,luolx21@mails.tsinghua.edu.cn https://github.com/rust-lang/rust/pull/55448,MERGED,2018-10-28T16:30:31Z,2019-04-03T08:32:35Z,Add 'partition_at_index/_by/_by_key' for slices.,Mokosha,3f306db3dbe390f43c7dfa8e17630747723e39e3,4,"Add initial implementation of 'sort_at_index' for slices -- analog to C++'s std::nth_element (a.k.a. quickselect) Add some more notes to the documentation: - Mention that the median can be found if we used `len() / 2`. - Mention that this function is usually called ""kth element"" in other libraries. Address some comments in PR: - Change wording on some of the documentation - Change recursive function into a loop Update name to `partition_at_index` and add convenience return values. Address reviewer comments: - Don't swap on each iteration when searching for min/max element. - Add some docs about when we panic. - Test that the sum of the lengths of the output matches the length of the input. - Style fix for for-loop. Address more reviewer comments Fix Rng stuff for test Fix doc test build Don't run the partition_at_index test on wasm targets Miri does not support entropy for test partition_at_index",HEART,2020-06-17T17:11:16Z,function2-llx,luolx21@mails.tsinghua.edu.cn https://github.com/rust-lang/rust/pull/55448,MERGED,2018-10-28T16:30:31Z,2019-04-03T08:32:35Z,Add 'partition_at_index/_by/_by_key' for slices.,Mokosha,3f306db3dbe390f43c7dfa8e17630747723e39e3,4,"Add initial implementation of 'sort_at_index' for slices -- analog to C++'s std::nth_element (a.k.a. quickselect) Add some more notes to the documentation: - Mention that the median can be found if we used `len() / 2`. - Mention that this function is usually called ""kth element"" in other libraries. Address some comments in PR: - Change wording on some of the documentation - Change recursive function into a loop Update name to `partition_at_index` and add convenience return values. Address reviewer comments: - Don't swap on each iteration when searching for min/max element. - Add some docs about when we panic. - Test that the sum of the lengths of the output matches the length of the input. - Style fix for for-loop. Address more reviewer comments Fix Rng stuff for test Fix doc test build Don't run the partition_at_index test on wasm targets Miri does not support entropy for test partition_at_index",LAUGH,2020-06-17T17:11:21Z,function2-llx,luolx21@mails.tsinghua.edu.cn https://github.com/rust-lang/rust/pull/55476,MERGED,2018-10-29T15:30:56Z,2018-10-30T14:20:18Z,Change a flat_map with 0/1-element vecs to a filter_map,ljedrz,bb3e77d28443835d03c0148bfeb84ecad56b986d,1,Change a flat_map with 0/1-element vecs to a filter_map,THUMBS_UP,2018-11-07T11:00:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/55485,MERGED,2018-10-29T18:52:01Z,2018-11-22T13:07:40Z,Return &T / &mut T in ManuallyDrop Deref(Mut) impl,petertodd,bc1885703cb46a462a4be1eea7c4e0f9abbe7a95,1,Return &T / &mut T in ManuallyDrop Deref(Mut) impl Without this change the generated documentation looks like this: fn deref(&self) -> & as Deref>::Target Returning the actual type directly makes the generated docs more clear: fn deref(&self) -> &T,THUMBS_UP,2018-11-28T20:11:28Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/55485,MERGED,2018-10-29T18:52:01Z,2018-11-22T13:07:40Z,Return &T / &mut T in ManuallyDrop Deref(Mut) impl,petertodd,bc1885703cb46a462a4be1eea7c4e0f9abbe7a95,1,Return &T / &mut T in ManuallyDrop Deref(Mut) impl Without this change the generated documentation looks like this: fn deref(&self) -> & as Deref>::Target Returning the actual type directly makes the generated docs more clear: fn deref(&self) -> &T,THUMBS_UP,2018-11-29T05:05:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55496,MERGED,2018-10-30T04:12:46Z,2018-10-30T14:20:23Z,Update clippy,Manishearth,49e712f1224d7086ac5ab8ac1ca06e4cb3fe3d7b,2,Update clippy,THUMBS_UP,2018-10-30T08:57:30Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/55510,MERGED,2018-10-30T16:58:51Z,2018-11-07T20:13:32Z,Fix feature gate only being checked on first repr attr.,bitshifter,d22ae75c9d6aeb4bb79b51e7c6fc3d824c736ac6,6,Fix feature gate only being checked on first repr attr.,HOORAY,2018-11-01T12:37:37Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55510,MERGED,2018-10-30T16:58:51Z,2018-11-07T20:13:32Z,Fix feature gate only being checked on first repr attr.,bitshifter,d22ae75c9d6aeb4bb79b51e7c6fc3d824c736ac6,6,Fix feature gate only being checked on first repr attr.,THUMBS_UP,2018-11-04T19:48:53Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55515,MERGED,2018-10-30T20:02:13Z,2018-11-05T12:33:52Z,rustdoc: refactor: centralize all command-line argument parsing,QuietMisdreavus,560a01c795923d7ae9e4dafa8bce7261d6450ade,1,fix formatting,THUMBS_UP,2018-10-31T11:16:41Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/55515,MERGED,2018-10-30T20:02:13Z,2018-11-05T12:33:52Z,rustdoc: refactor: centralize all command-line argument parsing,QuietMisdreavus,560a01c795923d7ae9e4dafa8bce7261d6450ade,1,fix formatting,THUMBS_UP,2018-11-03T08:32:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55515,MERGED,2018-10-30T20:02:13Z,2018-11-05T12:33:52Z,rustdoc: refactor: centralize all command-line argument parsing,QuietMisdreavus,560a01c795923d7ae9e4dafa8bce7261d6450ade,1,fix formatting,HEART,2018-11-07T19:12:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-01T18:57:26Z,tmandry,NA https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-03T21:03:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-04T23:09:23Z,scalexm,alexandre@scalexm.fr https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-10T23:15:19Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-24T02:29:26Z,jennylialiu,NA https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2018-11-27T21:22:33Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2019-01-03T16:04:56Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2019-01-10T18:50:12Z,kornholi,NA https://github.com/rust-lang/rust/pull/55517,MERGED,2018-10-30T21:02:38Z,2019-01-03T20:27:43Z,Universes,nikomatsakis,8e89184a7beb03d58d3a3969dddc1d78964dec37,15,rename `type_moves_by_default` to `type_is_copy_modulo_regions`,HOORAY,2019-01-11T05:26:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55527,MERGED,2018-10-31T05:51:19Z,2018-11-25T22:00:16Z,Implement checked_add_duration for SystemTime,sgeisler,f2106d0746cdbd04ddad44c35b4e13eeced2a546,2,use ? operator instead of match,THUMBS_UP,2018-11-28T20:09:38Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/55527,MERGED,2018-10-31T05:51:19Z,2018-11-25T22:00:16Z,Implement checked_add_duration for SystemTime,sgeisler,f2106d0746cdbd04ddad44c35b4e13eeced2a546,2,use ? operator instead of match,THUMBS_UP,2018-12-04T08:28:37Z,faern,NA https://github.com/rust-lang/rust/pull/55545,CLOSED,2018-10-31T16:25:47Z,2018-11-13T18:41:08Z,Remove the grammar.,steveklabnik,NA,NA,NA,HEART,2018-11-02T07:29:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55555,MERGED,2018-10-31T23:21:55Z,2018-11-03T17:30:46Z,Make `-Z ls` list the actual filename of external dependencies,aidanhs,e84f461d0abbb499430ab2dd9c81ae90a16f24d1,1,Make `-Z ls` list the actual filename of external dependencies,LAUGH,2018-11-01T09:59:29Z,kennytm,NA https://github.com/rust-lang/rust/pull/55556,MERGED,2018-10-31T23:27:04Z,2018-11-15T15:40:10Z,Use `Mmap` to open the rmeta file.,nnethercote,818257e70233fbafdb382b940893c9c1d615da22,4,Use `Mmap` to open the rmeta file. Because those files are quite large contribute significantly to peak memory usage but only a small fraction of the data is ever read.,THUMBS_UP,2018-11-01T01:16:48Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55556,MERGED,2018-10-31T23:27:04Z,2018-11-15T15:40:10Z,Use `Mmap` to open the rmeta file.,nnethercote,818257e70233fbafdb382b940893c9c1d615da22,4,Use `Mmap` to open the rmeta file. Because those files are quite large contribute significantly to peak memory usage but only a small fraction of the data is ever read.,HEART,2018-11-10T23:08:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55566,CLOSED,2018-11-01T01:49:36Z,2019-04-02T00:29:46Z,Require static native libraries when linking static executables,smaeul,NA,NA,NA,THUMBS_UP,2018-11-28T16:50:55Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/55566,CLOSED,2018-11-01T01:49:36Z,2019-04-02T00:29:46Z,Require static native libraries when linking static executables,smaeul,NA,NA,NA,THUMBS_UP,2019-01-03T15:31:20Z,mati865,NA https://github.com/rust-lang/rust/pull/55566,CLOSED,2018-11-01T01:49:36Z,2019-04-02T00:29:46Z,Require static native libraries when linking static executables,smaeul,NA,NA,NA,THUMBS_UP,2019-02-05T11:49:14Z,frol,NA https://github.com/rust-lang/rust/pull/55567,MERGED,2018-11-01T03:27:03Z,2018-11-03T17:30:48Z,add test for deriving Debug on uninhabited enum,durka,2279f6260c42344257fccef364c5cfef6c9b093e,2,add test for deriving Debug on uninhabited enum,HEART,2018-11-02T07:29:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55573,MERGED,2018-11-01T07:33:38Z,2018-11-01T19:11:42Z,Make sure the `aws` executable is in $PATH on macOS,kennytm,a85467748f1f6b88d18d5b1f1a0611d8e27b8627,1,Make sure the installed `awscli` is found on macOS.,HOORAY,2018-11-01T12:51:05Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55573,MERGED,2018-11-01T07:33:38Z,2018-11-01T19:11:42Z,Make sure the `aws` executable is in $PATH on macOS,kennytm,a85467748f1f6b88d18d5b1f1a0611d8e27b8627,1,Make sure the installed `awscli` is found on macOS.,HEART,2018-11-01T12:51:08Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55573,MERGED,2018-11-01T07:33:38Z,2018-11-01T19:11:42Z,Make sure the `aws` executable is in $PATH on macOS,kennytm,a85467748f1f6b88d18d5b1f1a0611d8e27b8627,1,Make sure the installed `awscli` is found on macOS.,HEART,2018-11-09T20:48:25Z,Others,NA https://github.com/rust-lang/rust/pull/55574,MERGED,2018-11-01T08:03:10Z,2018-11-01T19:11:43Z,Use `SmallVec` within `MoveData`.,nnethercote,0e5d7d2322db2a5db82161dc1d57158acad7b2d9,2,Use `SmallVec` within `MoveData`. This reduces allocation counts significantly in a few benchmarks reducing instruction counts by up to 2%.,THUMBS_UP,2018-11-08T14:27:54Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55585,CLOSED,2018-11-01T15:32:40Z,2018-11-06T11:01:27Z,Try perf impact of faster local dominance queries in LLVM,nikic,NA,NA,NA,HEART,2018-11-01T21:17:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55598,MERGED,2018-11-01T21:40:51Z,2018-11-03T17:30:50Z,publish-toolstate: ping maintainers when a tool builds again,nrc,d0778ac88e5e920e9ac2432a7c5c3246fb236310,1,publish-toolstate: ping maintainers when a tool builds again And add @Xanewok as an RLS maintainer,THUMBS_UP,2018-11-02T01:05:50Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/55598,MERGED,2018-11-01T21:40:51Z,2018-11-03T17:30:50Z,publish-toolstate: ping maintainers when a tool builds again,nrc,d0778ac88e5e920e9ac2432a7c5c3246fb236310,1,publish-toolstate: ping maintainers when a tool builds again And add @Xanewok as an RLS maintainer,THUMBS_UP,2018-11-03T12:32:26Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/55601,MERGED,2018-11-01T23:25:32Z,2018-11-06T12:07:49Z,Fix tracking issue numbers for some unstable features,petrochenkov,29d2ceae7c03fb4a4d99e4e766cf212fb9582ffa,10,Remove deprecated unstable `#[panic_implementation]` It was superseded by `#[panic_handler]`,HOORAY,2018-11-03T01:53:14Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55604,MERGED,2018-11-02T02:41:04Z,2018-11-12T10:58:36Z,Avoid the Box in `TyCtxt::associated_items`.,nnethercote,e927a244ea8f162858594552ddaec8465d54c329,2,Avoid the Box in `TyCtxt::associated_items`. This reduces instruction counts on packed_simd by 2%.,HEART,2018-11-02T07:26:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55604,MERGED,2018-11-02T02:41:04Z,2018-11-12T10:58:36Z,Avoid the Box in `TyCtxt::associated_items`.,nnethercote,e927a244ea8f162858594552ddaec8465d54c329,2,Avoid the Box in `TyCtxt::associated_items`. This reduces instruction counts on packed_simd by 2%.,HEART,2018-11-02T14:15:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55604,MERGED,2018-11-02T02:41:04Z,2018-11-12T10:58:36Z,Avoid the Box in `TyCtxt::associated_items`.,nnethercote,e927a244ea8f162858594552ddaec8465d54c329,2,Avoid the Box in `TyCtxt::associated_items`. This reduces instruction counts on packed_simd by 2%.,HEART,2018-11-15T04:39:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55609,MERGED,2018-11-02T12:46:59Z,2018-11-07T20:13:36Z,Run name-anon-globals after LTO passes as well,nikic,66702fcd0ae34100aaf74a9bdf8da77b6e273616,3,Run name-anon-globals after LTO passes as well If we're going to emit bitcode (through ThinLTOBuffer) then we need to ensure that anon globals are named. This was already done after optimization passes but also has to happen after LTO passes as we always emit the final result in a ThinLTO-compatible manner. Fixes #51947.,HEART,2018-11-05T21:36:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55613,CLOSED,2018-11-02T14:19:37Z,2019-02-27T18:53:44Z,"suggesting for traits do not search the ""prelude crates""",davidtwco,NA,NA,NA,HEART,2018-11-04T18:07:30Z,estebank,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-11-05T12:10:51Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-11-13T18:48:25Z,lqd,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-11-15T08:24:22Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-11-15T15:10:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-11-22T15:03:13Z,varkor,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2018-12-03T17:20:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2019-04-02T19:50:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2019-08-01T19:41:52Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2019-11-19T12:11:05Z,Victor-Savu,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2020-03-26T02:02:56Z,estebank,NA https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2020-05-08T15:23:27Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/55617,MERGED,2018-11-02T15:28:22Z,2020-05-07T03:32:51Z,Prevent compiler stack overflow for deeply recursive code,oli-obk,97f3eeec8216d7155c24674b9be55e7c672bcae3,16,"Auto merge of #55617 - oli-obk:stacker r=nagisa oli-obk Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit=""1000000""] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.",HEART,2020-05-15T14:28:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55626,MERGED,2018-11-02T19:21:58Z,2018-11-10T04:15:03Z,Update emscripten,nikic,82574e9ec804b6efbf6dfcf523d32618528ee32b,2,Pull in fix for dist-i686-linux build,HEART,2018-11-05T21:30:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55626,MERGED,2018-11-02T19:21:58Z,2018-11-10T04:15:03Z,Update emscripten,nikic,82574e9ec804b6efbf6dfcf523d32618528ee32b,2,Pull in fix for dist-i686-linux build,HEART,2018-11-10T14:47:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55626,MERGED,2018-11-02T19:21:58Z,2018-11-10T04:15:03Z,Update emscripten,nikic,82574e9ec804b6efbf6dfcf523d32618528ee32b,2,Pull in fix for dist-i686-linux build,HEART,2018-11-10T22:52:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-04T20:23:35Z,lqd,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-05T08:25:07Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-05T19:37:50Z,estebank,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-05T20:57:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-10T23:04:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-16T13:15:21Z,denismerigoux,denis.merigoux@gmail.com https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-16T13:38:15Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-16T19:05:30Z,lachlansneff,lachlan@charted.space https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-16T20:48:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-16T21:54:01Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-17T00:49:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-18T18:18:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55627,MERGED,2018-11-02T19:40:13Z,2018-11-17T07:10:04Z,rustc_codegen_llvm: traitification of LLVM-specific CodegenCx and Builder methods,sunfishcode,756f84d7cef90b7364ae88ca707e59670dde4c92,4,[eddyb] rustc_codegen_llvm: remove unused parametrization of `CodegenCx` and `Builder` over `Value`s.,HOORAY,2018-11-19T18:33:41Z,bjorn3,NA https://github.com/rust-lang/rust/pull/55639,CLOSED,2018-11-03T03:53:45Z,2019-01-12T13:44:26Z,Stabilize allow irrefutable if-let patterns,Nokel81,NA,NA,NA,HOORAY,2018-11-09T23:24:29Z,estebank,NA https://github.com/rust-lang/rust/pull/55639,CLOSED,2018-11-03T03:53:45Z,2019-01-12T13:44:26Z,Stabilize allow irrefutable if-let patterns,Nokel81,NA,NA,NA,HOORAY,2018-11-21T15:10:03Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55639,CLOSED,2018-11-03T03:53:45Z,2019-01-12T13:44:26Z,Stabilize allow irrefutable if-let patterns,Nokel81,NA,NA,NA,HEART,2019-01-12T13:44:16Z,varkor,NA https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-10T05:39:34Z,barzamin,NA https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-30T10:42:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-30T14:10:20Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-30T17:45:08Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-30T21:31:02Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-01-31T06:52:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55641,MERGED,2018-11-03T09:22:38Z,2019-01-26T09:47:46Z,Implement optimize(size) and optimize(speed) attributes,nagisa,ce289c6c9911c7ea55b7f30b125d3c38ed359da4,7,Resolve breakage,HEART,2019-02-01T08:12:06Z,ryazanov,NA https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2018-11-03T15:47:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2018-11-05T21:30:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2018-11-10T22:50:11Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2018-11-15T04:40:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2018-11-26T06:02:58Z,hcpl,NA https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2019-02-13T09:00:39Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55650,MERGED,2018-11-03T15:27:18Z,2018-11-10T22:46:57Z,Implement rotate using funnel shift on LLVM >= 7,nikic,4c40ff6a2472124cd061721463f329184ca76fa3,10,Implement rotate using funnel shift on LLVM >= 7 Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However emulation of funnel shifts requires emitting a conditional to check for zero shift amount which is not necessary for rotates. I was uncomfortable doing that here as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.,HEART,2020-05-08T17:45:48Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-03T20:20:15Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-04T03:34:10Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-04T19:06:49Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-05T16:50:04Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-11T17:49:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-12T04:24:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-14T19:40:15Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-15T04:42:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,HOORAY,2018-11-15T15:57:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55660,MERGED,2018-11-03T18:34:39Z,2018-11-11T22:39:09Z,Remove the `alloc_system` crate,alexcrichton,cc7590341a6ac213909d0ef56a7ebc2834274c8b,31,std: Delete the `alloc_system` crate This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate and as a result this should not affect any stable code.,THUMBS_UP,2018-11-26T23:54:38Z,hcpl,NA https://github.com/rust-lang/rust/pull/55665,MERGED,2018-11-03T21:12:59Z,2018-11-04T21:41:07Z,rustc_target: pass contexts by reference not value.,eddyb,d00d42d079236893f0a8b2cd726c6957d96ec296,38,rustc_target: pass contexts by reference not value.,HEART,2018-11-03T22:14:30Z,oli-obk,NA https://github.com/rust-lang/rust/pull/55665,MERGED,2018-11-03T21:12:59Z,2018-11-04T21:41:07Z,rustc_target: pass contexts by reference not value.,eddyb,d00d42d079236893f0a8b2cd726c6957d96ec296,38,rustc_target: pass contexts by reference not value.,HEART,2018-11-03T23:13:14Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/55665,MERGED,2018-11-03T21:12:59Z,2018-11-04T21:41:07Z,rustc_target: pass contexts by reference not value.,eddyb,d00d42d079236893f0a8b2cd726c6957d96ec296,38,rustc_target: pass contexts by reference not value.,HEART,2018-11-04T16:28:43Z,denismerigoux,denis.merigoux@gmail.com https://github.com/rust-lang/rust/pull/55665,MERGED,2018-11-03T21:12:59Z,2018-11-04T21:41:07Z,rustc_target: pass contexts by reference not value.,eddyb,d00d42d079236893f0a8b2cd726c6957d96ec296,38,rustc_target: pass contexts by reference not value.,HEART,2018-11-07T19:13:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55678,MERGED,2018-11-04T17:52:01Z,2018-11-20T15:16:13Z,Updated RELEASES.md for 1.31.0,XAMPPRocky,9240ad4571d9000cffc7a02764f09834fade6e4d,1,Update releases to add rename dependencies feature,HOORAY,2018-11-14T16:44:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55698,MERGED,2018-11-05T14:06:09Z,2018-11-12T01:20:46Z,Remove support for building against LLVM 4,nikic,3cc8b17451aac4a144baa48bb48f4187a5529769,6,Remove support for building against LLVM 4 With emscripten removed in #55626 we no longer need to support building against LLVM 4.,THUMBS_UP,2018-11-05T19:32:47Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/55698,MERGED,2018-11-05T14:06:09Z,2018-11-12T01:20:46Z,Remove support for building against LLVM 4,nikic,3cc8b17451aac4a144baa48bb48f4187a5529769,6,Remove support for building against LLVM 4 With emscripten removed in #55626 we no longer need to support building against LLVM 4.,THUMBS_UP,2018-11-05T21:30:08Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55698,MERGED,2018-11-05T14:06:09Z,2018-11-12T01:20:46Z,Remove support for building against LLVM 4,nikic,3cc8b17451aac4a144baa48bb48f4187a5529769,6,Remove support for building against LLVM 4 With emscripten removed in #55626 we no longer need to support building against LLVM 4.,THUMBS_UP,2018-11-06T13:46:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55698,MERGED,2018-11-05T14:06:09Z,2018-11-12T01:20:46Z,Remove support for building against LLVM 4,nikic,3cc8b17451aac4a144baa48bb48f4187a5529769,6,Remove support for building against LLVM 4 With emscripten removed in #55626 we no longer need to support building against LLVM 4.,THUMBS_UP,2018-11-14T18:03:21Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2018-11-05T17:35:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2018-11-05T20:05:37Z,cramertj,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2018-11-08T23:28:25Z,yuriks,yuriks@yuriks.net https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2018-11-09T08:16:29Z,hcpl,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2018-11-16T20:53:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2019-01-04T18:38:13Z,cynecx,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2019-01-05T09:59:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2019-01-29T00:23:33Z,leinlawun,leinlawun@leinlawun.org https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,THUMBS_UP,2019-01-30T07:40:08Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,HOORAY,2019-01-30T17:44:02Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,THUMBS_UP,2019-01-30T17:44:03Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/55704,MERGED,2018-11-05T17:12:51Z,2019-01-28T16:55:54Z,Use pinning for generators to make trait safe,Nemo157,a21c95f08e37a2e609a0cb523eb9c132d8c341f3,3,Mark non-static generators as always Unpin,THUMBS_UP,2019-01-31T06:51:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55705,MERGED,2018-11-05T18:26:28Z,2018-11-26T04:43:58Z,Make `ParseIntError` and `IntErrorKind` fully public,eopb,121e5e806e41c4825fc4a25ad45d2585d1058165,1,fix missing borrow,THUMBS_UP,2019-01-02T17:11:13Z,kozlice,NA https://github.com/rust-lang/rust/pull/55705,MERGED,2018-11-05T18:26:28Z,2018-11-26T04:43:58Z,Make `ParseIntError` and `IntErrorKind` fully public,eopb,121e5e806e41c4825fc4a25ad45d2585d1058165,1,fix missing borrow,THUMBS_UP,2021-04-17T19:41:55Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/55707,MERGED,2018-11-06T00:41:18Z,2018-12-04T09:21:32Z,Add source file sidebar,GuillaumeGomez,82a7b6fde819e7e402ea9be6af14fe2c1575950e,2,Don't generate suffix for source-file.js,HOORAY,2018-11-06T03:23:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,THUMBS_UP,2018-11-06T15:49:56Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,HOORAY,2018-11-06T16:44:32Z,chinedufn,frankie.nwafili@gmail.com https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,THUMBS_UP,2018-11-06T19:32:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,HOORAY,2018-11-06T20:58:46Z,killercup,NA https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,HEART,2018-11-09T23:50:04Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,THUMBS_UP,2018-11-09T23:50:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,HOORAY,2018-11-09T23:50:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,THUMBS_UP,2019-01-27T15:54:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/55715,CLOSED,2018-11-06T11:51:56Z,2019-02-25T10:36:20Z,implement .trailing_ones() .leading_ones(),yoshuawuyts,NA,NA,NA,THUMBS_UP,2019-01-30T10:23:01Z,bluetech,ran@unusedvar.com https://github.com/rust-lang/rust/pull/55717,MERGED,2018-11-06T12:07:10Z,2018-11-10T09:38:30Z,Bubble up an overflow error so that rustdoc can ignore it,oli-obk,69c80f48787655f4e3b0489c70c0aeeea87ff86a,2,Bubble up an overflow error so that rustdoc can ignore it,HEART,2018-11-06T13:13:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/55717,MERGED,2018-11-06T12:07:10Z,2018-11-10T09:38:30Z,Bubble up an overflow error so that rustdoc can ignore it,oli-obk,69c80f48787655f4e3b0489c70c0aeeea87ff86a,2,Bubble up an overflow error so that rustdoc can ignore it,HEART,2018-11-06T15:58:27Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/55717,MERGED,2018-11-06T12:07:10Z,2018-11-10T09:38:30Z,Bubble up an overflow error so that rustdoc can ignore it,oli-obk,69c80f48787655f4e3b0489c70c0aeeea87ff86a,2,Bubble up an overflow error so that rustdoc can ignore it,HEART,2018-11-07T08:33:57Z,weiznich,NA https://github.com/rust-lang/rust/pull/55722,MERGED,2018-11-06T15:11:26Z,2018-11-14T01:18:53Z,impl_stable_hash_for: support enums and tuple structs with generic parameters,RalfJung,db3c69ec80a9a9fbb2c4a7d3e10547549152387a,3,impl_stable_hash_for: support enums and tuple structs with generic parameters,HEART,2018-11-06T20:00:07Z,varkor,NA https://github.com/rust-lang/rust/pull/55722,MERGED,2018-11-06T15:11:26Z,2018-11-14T01:18:53Z,impl_stable_hash_for: support enums and tuple structs with generic parameters,RalfJung,db3c69ec80a9a9fbb2c4a7d3e10547549152387a,3,impl_stable_hash_for: support enums and tuple structs with generic parameters,HEART,2018-11-07T18:51:29Z,tmandry,NA https://github.com/rust-lang/rust/pull/55722,MERGED,2018-11-06T15:11:26Z,2018-11-14T01:18:53Z,impl_stable_hash_for: support enums and tuple structs with generic parameters,RalfJung,db3c69ec80a9a9fbb2c4a7d3e10547549152387a,3,impl_stable_hash_for: support enums and tuple structs with generic parameters,HEART,2018-11-22T05:06:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55734,MERGED,2018-11-06T22:10:55Z,2018-11-07T20:13:48Z,refactor: use shorthand fields,teresy,eca11b99a7d25e4e6573472a16537c1aacb5d5e1,57,refactor: use shorthand fields,THUMBS_UP,2018-11-07T08:18:10Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55739,MERGED,2018-11-07T03:47:18Z,2018-11-09T09:44:16Z,Consume optimization fuel from the MIR inliner,wesleywiser,e72afa9573ab8cb7ca2482f53b234bb59e3040ef,1,Consume optimization fuel from the MIR inliner This makes it easier to debug mis-optimizations that occur during inlining. Thanks to @nikomatsakis for the suggestion!,HEART,2018-11-07T05:42:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55739,MERGED,2018-11-07T03:47:18Z,2018-11-09T09:44:16Z,Consume optimization fuel from the MIR inliner,wesleywiser,e72afa9573ab8cb7ca2482f53b234bb59e3040ef,1,Consume optimization fuel from the MIR inliner This makes it easier to debug mis-optimizations that occur during inlining. Thanks to @nikomatsakis for the suggestion!,HEART,2018-11-15T04:40:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55761,MERGED,2018-11-07T16:15:41Z,2018-11-09T09:44:21Z,mir: remove a hacky recursive helper function,ljedrz,5159b32997c92323ac7dd746b6898c1e96e7078c,1,mir: remove a hacky recursive helper function,THUMBS_UP,2018-11-07T19:31:30Z,estebank,NA https://github.com/rust-lang/rust/pull/55781,MERGED,2018-11-08T11:58:56Z,2018-11-15T15:40:16Z,More precise spans for temps and their drops,pnkfelix,dd6398256ec0bde52722831d6b6cf604c9cdf1ed,2,Revise the temp creation for blocks in `stmt_expr` to setup `BlockTailInfo`.,HEART,2018-11-09T21:14:25Z,estebank,NA https://github.com/rust-lang/rust/pull/55783,MERGED,2018-11-08T13:28:50Z,2018-11-09T09:44:24Z,Deprecate mpsc channel selection,NA,NA,NA,NA,THUMBS_UP,2018-11-08T17:06:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/55788,MERGED,2018-11-08T15:53:22Z,2018-11-09T09:44:25Z,rustc: Request ansi colors if stderr isn't a tty,alexcrichton,255cc1aed33442567c29c95fa445a534575e925c,1,rustc: Request ansi colors if stderr isn't a tty Currently Cargo will always capture the output of rustc meaning that rustc is never hooked up to a tty. To retain colors Cargo uses the `fwdansi` crate to ensure that ansi color codes are translated to windows terminal methods (and ansi codes otherwise just go their natural route on Unix). Cargo passes `--color always` to rustc to ensure that using a pipe doesn't trick it into not emitting colors at all. It turns out however that `--color always` ends up still accidentally using the native shell api on native windows shells. The fix here is to instead pass `AlwaysAnsi` to `termcolor` instead of `Always` ensuring that when `--color always` is passed to rustc and its output isn't a terminal we're always generating ansi colors regardless of the platform. Closes #55769,HOORAY,2018-11-08T16:03:11Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55798,MERGED,2018-11-08T23:01:41Z,2018-12-21T04:55:43Z,Add version display for associated consts,GuillaumeGomez,ca04c639307e700e4684a46ef71d0781b8f35736,1,Add test for associated const version display,THUMBS_UP,2018-11-26T15:49:14Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/55798,MERGED,2018-11-08T23:01:41Z,2018-12-21T04:55:43Z,Add version display for associated consts,GuillaumeGomez,ca04c639307e700e4684a46ef71d0781b8f35736,1,Add test for associated const version display,THUMBS_UP,2018-12-21T08:22:56Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/55807,CLOSED,2018-11-09T02:31:17Z,2019-01-25T16:38:45Z,[WIP] Rework impl-trait-in-bindings feature,alexreg,NA,NA,NA,THUMBS_UP,2019-01-24T19:06:13Z,EliSnow,NA https://github.com/rust-lang/rust/pull/55808,MERGED,2018-11-09T02:59:39Z,2018-11-23T14:22:15Z,Suggest correct syntax when writing type arg instead of assoc type,estebank,510f836d2378bc9d7ec48e3c39ca83006aadb197,6,Do not point at associated types from other crates This is a somewhat arbitrary restriction in order to be consistent in the output of the tests regardless of target platform.,THUMBS_UP,2018-11-09T06:00:48Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55808,MERGED,2018-11-09T02:59:39Z,2018-11-23T14:22:15Z,Suggest correct syntax when writing type arg instead of assoc type,estebank,510f836d2378bc9d7ec48e3c39ca83006aadb197,6,Do not point at associated types from other crates This is a somewhat arbitrary restriction in order to be consistent in the output of the tests regardless of target platform.,THUMBS_UP,2018-11-28T19:11:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/55808,MERGED,2018-11-09T02:59:39Z,2018-11-23T14:22:15Z,Suggest correct syntax when writing type arg instead of assoc type,estebank,510f836d2378bc9d7ec48e3c39ca83006aadb197,6,Do not point at associated types from other crates This is a somewhat arbitrary restriction in order to be consistent in the output of the tests regardless of target platform.,THUMBS_UP,2018-11-29T05:07:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55808,MERGED,2018-11-09T02:59:39Z,2018-11-23T14:22:15Z,Suggest correct syntax when writing type arg instead of assoc type,estebank,510f836d2378bc9d7ec48e3c39ca83006aadb197,6,Do not point at associated types from other crates This is a somewhat arbitrary restriction in order to be consistent in the output of the tests regardless of target platform.,THUMBS_UP,2018-12-10T18:02:53Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55816,MERGED,2018-11-09T08:11:33Z,2018-11-11T09:07:54Z,Use `SmallVec` to avoid allocations in `from_decimal_string`.,nnethercote,a66d7b2001def5ab87e99d661e31890660f38374,4,"Use `SmallVec` to avoid allocations in `from_decimal_string`. This reduces the number of allocations in a ""check clean"" build of `tuple-stress` by 14% reducing instruction counts by 0.6%.",THUMBS_UP,2018-11-15T20:17:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55835,MERGED,2018-11-09T23:07:58Z,2018-11-26T15:12:21Z,Upgrade LLVM to trunk still version 8,alexcrichton,7215963e56321c5e92b9c2f7c4ad788362451b37,1,Temporarily disable LLDB,THUMBS_UP,2018-11-10T11:20:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55835,MERGED,2018-11-09T23:07:58Z,2018-11-26T15:12:21Z,Upgrade LLVM to trunk still version 8,alexcrichton,7215963e56321c5e92b9c2f7c4ad788362451b37,1,Temporarily disable LLDB,THUMBS_UP,2018-11-10T14:52:52Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/55835,MERGED,2018-11-09T23:07:58Z,2018-11-26T15:12:21Z,Upgrade LLVM to trunk still version 8,alexcrichton,7215963e56321c5e92b9c2f7c4ad788362451b37,1,Temporarily disable LLDB,THUMBS_UP,2018-11-10T22:54:20Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/55835,MERGED,2018-11-09T23:07:58Z,2018-11-26T15:12:21Z,Upgrade LLVM to trunk still version 8,alexcrichton,7215963e56321c5e92b9c2f7c4ad788362451b37,1,Temporarily disable LLDB,THUMBS_UP,2018-11-12T23:37:06Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/55835,MERGED,2018-11-09T23:07:58Z,2018-11-26T15:12:21Z,Upgrade LLVM to trunk still version 8,alexcrichton,7215963e56321c5e92b9c2f7c4ad788362451b37,1,Temporarily disable LLDB,THUMBS_UP,2018-12-06T08:26:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55843,MERGED,2018-11-10T10:49:20Z,2018-11-14T01:18:58Z,add FromIterator to Box<[A]>,lcnr,ab55d9b5d33f324495509ab45c8386b97b74d04f,1,change attribute to stable,THUMBS_UP,2018-11-10T20:16:16Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55843,MERGED,2018-11-10T10:49:20Z,2018-11-14T01:18:58Z,add FromIterator to Box<[A]>,lcnr,ab55d9b5d33f324495509ab45c8386b97b74d04f,1,change attribute to stable,THUMBS_UP,2018-11-11T12:19:00Z,bluetech,ran@unusedvar.com https://github.com/rust-lang/rust/pull/55843,MERGED,2018-11-10T10:49:20Z,2018-11-14T01:18:58Z,add FromIterator to Box<[A]>,lcnr,ab55d9b5d33f324495509ab45c8386b97b74d04f,1,change attribute to stable,HOORAY,2018-11-14T10:49:58Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/55843,MERGED,2018-11-10T10:49:20Z,2018-11-14T01:18:58Z,add FromIterator to Box<[A]>,lcnr,ab55d9b5d33f324495509ab45c8386b97b74d04f,1,change attribute to stable,THUMBS_UP,2018-11-22T00:00:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/55843,MERGED,2018-11-10T10:49:20Z,2018-11-14T01:18:58Z,add FromIterator to Box<[A]>,lcnr,ab55d9b5d33f324495509ab45c8386b97b74d04f,1,change attribute to stable,THUMBS_UP,2018-11-22T05:11:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55852,MERGED,2018-11-10T18:09:19Z,2018-11-15T15:40:21Z,Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint,varkor,c63df7c64fbb1cd010e24ac4eb66b87aab8e650f,3,Use non-short suggestion for parenthesised ..=,HEART,2018-11-10T22:24:40Z,killercup,NA https://github.com/rust-lang/rust/pull/55852,MERGED,2018-11-10T18:09:19Z,2018-11-15T15:40:21Z,Rewrite `...` as `..=` as a `MachineApplicable` 2018 idiom lint,varkor,c63df7c64fbb1cd010e24ac4eb66b87aab8e650f,3,Use non-short suggestion for parenthesised ..=,HOORAY,2018-11-13T07:40:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/55862,MERGED,2018-11-11T06:43:14Z,2018-11-19T16:59:35Z,"in which the E0618 ""expected function"" diagnostic gets a makeover",zackmdavis,f3e9b1a703203be4f375dc5fa3950b642a156ec7,18,"in which the E0618 ""expected function"" diagnostic gets a makeover Now the main span focuses on the erroneous not-a-function callee while showing the entire call expression is relegated to a secondary span. In the case where the erroneous callee is itself a call we point out the definition and if the call expression spans multiple lines tentatively suggest a semicolon (because we suspect that the ""outer"" call is actually supposed to be a tuple). The new `bug!` assertion is in fact safe (`confirm_builtin_call` is only called by `check_call` which is only called with a first arg of kind `ExprKind::Call` in `check_expr_kind`). Resolves #51055.",HEART,2018-11-11T20:52:18Z,estebank,NA https://github.com/rust-lang/rust/pull/55865,MERGED,2018-11-11T09:11:23Z,2018-11-15T15:40:23Z,Unix RwLock: avoid racy access to write_locked,RalfJung,db133901042f7ccc8194b240c8381281bc4be575,1,do not skip return code check in release builds,THUMBS_UP,2018-11-12T23:49:24Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/55865,MERGED,2018-11-11T09:11:23Z,2018-11-15T15:40:23Z,Unix RwLock: avoid racy access to write_locked,RalfJung,db133901042f7ccc8194b240c8381281bc4be575,1,do not skip return code check in release builds,THUMBS_UP,2018-11-22T05:02:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55867,MERGED,2018-11-11T09:45:44Z,2018-11-19T16:59:36Z,do not panic just because cargo failed,RalfJung,b7c319c56ae8380aa2ab03d2b9b6702ae43d49b3,1,do not panic just because cargo failed,THUMBS_UP,2018-11-12T02:36:29Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/55867,MERGED,2018-11-11T09:45:44Z,2018-11-19T16:59:36Z,do not panic just because cargo failed,RalfJung,b7c319c56ae8380aa2ab03d2b9b6702ae43d49b3,1,do not panic just because cargo failed,THUMBS_UP,2018-11-16T16:53:19Z,bjorn3,NA https://github.com/rust-lang/rust/pull/55867,MERGED,2018-11-11T09:45:44Z,2018-11-19T16:59:36Z,do not panic just because cargo failed,RalfJung,b7c319c56ae8380aa2ab03d2b9b6702ae43d49b3,1,do not panic just because cargo failed,THUMBS_UP,2018-11-28T16:59:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-11T20:28:27Z,killercup,NA https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-11T20:52:09Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-12T08:34:27Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-13T01:37:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-13T05:44:02Z,NLincoln,nate.school42@gmail.com https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-28T15:35:04Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-28T17:08:13Z,aldanor,NA https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-11-30T14:25:34Z,42triangles,NA https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-12-03T09:56:24Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-12-03T10:04:18Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-12-03T21:02:04Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/55869,MERGED,2018-11-11T11:23:52Z,2018-11-23T21:46:18Z,Add std::iter::unfold,SimonSapin,a4279a07e29091fd8a72b13b2109c8969e713ffd,2,Capitalize,THUMBS_UP,2018-12-05T11:40:05Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/55874,MERGED,2018-11-11T14:47:45Z,2018-11-14T01:19:02Z,string: Add documentation for `From` impls,denisvasilik,6f3add34ca18cf6fbe5374d3e519b0c8838b1dfe,1,Minor style guide corrections.,THUMBS_UP,2018-11-11T19:34:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55879,MERGED,2018-11-11T20:47:46Z,2018-11-14T01:19:02Z,save-analysis: Don't panic for macro-generated use globs,Xanewok,04cc0d651e8b40dffbcd3865c1e2c2cfc1663911,1,save-analysis: Don't panic for macro-generated use globs Follow-up to https://github.com/rust-lang/rust/commit/c2bb7cadf24e82b80f403c09e800fe5fad504caf.,HOORAY,2018-11-11T23:56:33Z,mati865,NA https://github.com/rust-lang/rust/pull/55879,MERGED,2018-11-11T20:47:46Z,2018-11-14T01:19:02Z,save-analysis: Don't panic for macro-generated use globs,Xanewok,04cc0d651e8b40dffbcd3865c1e2c2cfc1663911,1,save-analysis: Don't panic for macro-generated use globs Follow-up to https://github.com/rust-lang/rust/commit/c2bb7cadf24e82b80f403c09e800fe5fad504caf.,THUMBS_UP,2018-11-12T16:24:50Z,norru,nigu.orru@gmail.com https://github.com/rust-lang/rust/pull/55882,MERGED,2018-11-12T01:56:37Z,2018-11-14T01:19:03Z,Reference count `crate_inherent_impls`s return value.,hugwijst,4fdae853f70d9bbdf4dbc365743f6545cfd4a9ac,2,Reference count `crate_inherent_impls`s return value. The repeated cloning of the result in `inherent_impls` queries has quite an impact on crates with many inherent trait implementations.,HOORAY,2018-11-12T09:05:04Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55882,MERGED,2018-11-12T01:56:37Z,2018-11-14T01:19:03Z,Reference count `crate_inherent_impls`s return value.,hugwijst,4fdae853f70d9bbdf4dbc365743f6545cfd4a9ac,2,Reference count `crate_inherent_impls`s return value. The repeated cloning of the result in `inherent_impls` queries has quite an impact on crates with many inherent trait implementations.,HOORAY,2018-11-12T10:06:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/55882,MERGED,2018-11-12T01:56:37Z,2018-11-14T01:19:03Z,Reference count `crate_inherent_impls`s return value.,hugwijst,4fdae853f70d9bbdf4dbc365743f6545cfd4a9ac,2,Reference count `crate_inherent_impls`s return value. The repeated cloning of the result in `inherent_impls` queries has quite an impact on crates with many inherent trait implementations.,HOORAY,2018-11-22T05:05:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HOORAY,2018-11-12T07:11:13Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HEART,2018-11-12T07:11:15Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HOORAY,2018-11-12T13:45:41Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HEART,2018-11-12T23:27:42Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HOORAY,2018-11-12T23:27:44Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HOORAY,2018-11-13T03:32:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HEART,2018-11-13T03:32:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HEART,2018-11-18T13:23:22Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/55884,MERGED,2018-11-12T02:13:36Z,2018-11-18T09:24:22Z,[beta] resolve: Implement uniform paths 2.0,petrochenkov,b3664152ae5b47ab484c8dfbab907dcdf9a49a25,14,Add a couple more tests + address review comments,HOORAY,2019-06-23T11:34:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,THUMBS_UP,2018-11-20T04:31:39Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,THUMBS_UP,2019-02-18T18:33:30Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,HEART,2019-02-18T18:33:35Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,ROCKET,2019-02-18T18:33:38Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,HOORAY,2019-02-18T18:33:53Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/55909,CLOSED,2018-11-13T03:06:05Z,2019-01-14T15:17:06Z,Sparse-file handling for the Linux implementation of std::fs::copy(),tarka,NA,NA,NA,THUMBS_UP,2020-04-12T10:37:58Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/55921,MERGED,2018-11-13T15:16:04Z,2018-11-25T09:40:51Z,Add placeholder types,scalexm,b8a30f04cdd129ab89b85d0eda11f1c65058767a,1,Try to work around #53332 in `src/test/run-pass/rustc-rust-log.rs`,HEART,2018-11-28T06:33:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55926,MERGED,2018-11-13T16:27:30Z,2018-11-15T15:40:27Z,Change sidebar selector to fix compatibility with docs.rs,cynecx,2f7b95d932f9bac550e076920b7fab1e1021bd16,1,Change sidebar selector to fix compatibility with docs.rs,HEART,2018-11-15T16:20:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2018-11-13T17:47:17Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2018-11-13T18:09:12Z,ljedrz,NA https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2018-11-14T09:25:17Z,kennytm,NA https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2018-11-21T13:44:36Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2018-11-22T05:12:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55932,MERGED,2018-11-13T17:37:34Z,2018-11-15T15:40:29Z,core/char: Speed up `to_digit()` for `radix <= 10`,Turbo87,7843e2792dce0f20d23b3c1cca51652013bef0ea,1,core/char: Add comment to `to_digit()`,THUMBS_UP,2020-12-24T07:47:06Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/55933,MERGED,2018-11-13T19:35:30Z,2018-12-05T23:00:45Z,emit error when doc generation fails,euclio,c359f98c7a0cd6f2af10fb1369477b9a03b32c44,4,emit error when doc generation fails Fixes #41813.,THUMBS_UP,2018-12-12T23:57:59Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/55949,MERGED,2018-11-14T14:05:34Z,2018-11-19T16:59:42Z,ty: return impl Iterator from Predicate::walk_tys,ljedrz,e6e56357308d1e20b56f1be9af2c2dfc73c49d0d,1,ty: return impl Iterator from Predicate::walk_tys,HEART,2018-11-15T07:59:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/55949,MERGED,2018-11-14T14:05:34Z,2018-11-19T16:59:42Z,ty: return impl Iterator from Predicate::walk_tys,ljedrz,e6e56357308d1e20b56f1be9af2c2dfc73c49d0d,1,ty: return impl Iterator from Predicate::walk_tys,HEART,2018-11-22T05:06:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/55959,MERGED,2018-11-14T22:19:10Z,2018-11-25T05:55:29Z,Cleanup from lexical MIR borrowck removal,matthewjasper,1d7fc0ca500d8e532e7b1019397baec353560c26,2,Simplify MIR drop generation Now that EndRegion is gone we don't need to create as many gotos.,HOORAY,2018-11-19T22:18:35Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55961,MERGED,2018-11-14T23:23:34Z,2018-11-22T13:07:48Z,Fix VecDeque pretty-printer,tromey,a9a48ed3da1134364052322d628fd9d9418998f4,2,Fix VecDeque pretty-printer This fixes the VecDeque pretty-printer to handle cases where head < tail. Closes #55944,THUMBS_UP,2018-11-17T04:37:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55961,MERGED,2018-11-14T23:23:34Z,2018-11-22T13:07:48Z,Fix VecDeque pretty-printer,tromey,a9a48ed3da1134364052322d628fd9d9418998f4,2,Fix VecDeque pretty-printer This fixes the VecDeque pretty-printer to handle cases where head < tail. Closes #55944,THUMBS_UP,2018-12-03T21:00:10Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/55968,MERGED,2018-11-15T04:03:17Z,2018-11-19T16:59:46Z,Clean up some non-mod-rs stuff.,ehuss,7f4bc2247a5fbfd8010ae1a799c3a6b2d173ec82,29,Clean up some non-mod-rs stuff.,THUMBS_UP,2018-11-15T18:54:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-11-15T20:16:12Z,RalfJung,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-11-17T17:57:10Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-11-24T15:39:17Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-11-25T10:21:18Z,kennytm,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-04T04:25:40Z,anderejd,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-04T07:15:45Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-04T17:41:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-05T18:17:44Z,AndrewGaspar,andrew.gaspar@outlook.com https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-06T18:02:32Z,brunoczim,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HEART,2018-12-08T14:14:10Z,whentze,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2018-12-11T20:28:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2019-01-21T02:55:02Z,ramosbugs,ramos@cs.stanford.edu https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HOORAY,2019-01-28T12:23:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,THUMBS_DOWN,2019-02-26T19:23:22Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HEART,2019-03-11T08:16:15Z,anderejd,NA https://github.com/rust-lang/rust/pull/55982,MERGED,2018-11-15T15:07:42Z,2018-12-13T03:35:20Z,rustc: Switch `extern` functions to abort by default on panic,alexcrichton,1091eee65b91a9968f2a0b2f0c7d6e8e27d8d033,10,rustc: Switch `extern` functions to abort by default on panic This was intended to land way back in 1.24 but it was backed out due to breakage which has long since been fixed. An unstable `#[unwind]` attribute can be used to tweak the behavior here but this is currently simply switching rustc's internal default to abort-by-default if an `extern` function panics making our codegen sound primarily (as currently you can produce UB with safe code) Closes #52652,HEART,2019-08-17T19:45:57Z,ralfbiedert,rb@xr.io https://github.com/rust-lang/rust/pull/55986,MERGED,2018-11-15T17:39:53Z,2019-01-04T14:21:25Z,Allow to dispatch fn traits depending on number of parameters,cjgillot,91c155bcd7af54fba0b705de1a2c2d55fa9788fa,2,Change return types and check return values in tests. This allows to verify that we handle different types as return types and that we call the expected functions.,THUMBS_UP,2018-12-29T02:13:17Z,sebastiencs,NA https://github.com/rust-lang/rust/pull/55986,MERGED,2018-11-15T17:39:53Z,2019-01-04T14:21:25Z,Allow to dispatch fn traits depending on number of parameters,cjgillot,91c155bcd7af54fba0b705de1a2c2d55fa9788fa,2,Change return types and check return values in tests. This allows to verify that we handle different types as return types and that we call the expected functions.,CONFUSED,2019-01-10T14:31:43Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/55986,MERGED,2018-11-15T17:39:53Z,2019-01-04T14:21:25Z,Allow to dispatch fn traits depending on number of parameters,cjgillot,91c155bcd7af54fba0b705de1a2c2d55fa9788fa,2,Change return types and check return values in tests. This allows to verify that we handle different types as return types and that we call the expected functions.,THUMBS_UP,2019-01-11T13:41:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/55986,MERGED,2018-11-15T17:39:53Z,2019-01-04T14:21:25Z,Allow to dispatch fn traits depending on number of parameters,cjgillot,91c155bcd7af54fba0b705de1a2c2d55fa9788fa,2,Change return types and check return values in tests. This allows to verify that we handle different types as return types and that we call the expected functions.,THUMBS_UP,2019-01-14T17:32:06Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/55987,MERGED,2018-11-15T18:00:25Z,2018-12-06T01:36:58Z,Add Weak.ptr_eq,Thomasdezeeuw,38e21f92f1c09a597788062045b1e1d8c879e4f2,1,Fix link in Weak::new,THUMBS_UP,2018-11-19T07:54:34Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/55987,MERGED,2018-11-15T18:00:25Z,2018-12-06T01:36:58Z,Add Weak.ptr_eq,Thomasdezeeuw,38e21f92f1c09a597788062045b1e1d8c879e4f2,1,Fix link in Weak::new,THUMBS_UP,2019-04-26T07:58:25Z,chpio,NA https://github.com/rust-lang/rust/pull/55992,MERGED,2018-11-15T23:50:50Z,2018-12-12T23:56:08Z,Expand std::pin module docs and rename std::pin::Pinned to PhantomPinned,cramertj,709b7515e744cdf242ab53806414aa295ea6977f,2,Rename Pinned marker type to PhantomPinned,THUMBS_UP,2018-11-17T01:35:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/55992,MERGED,2018-11-15T23:50:50Z,2018-12-12T23:56:08Z,Expand std::pin module docs and rename std::pin::Pinned to PhantomPinned,cramertj,709b7515e744cdf242ab53806414aa295ea6977f,2,Rename Pinned marker type to PhantomPinned,THUMBS_UP,2018-11-27T05:00:15Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/55992,MERGED,2018-11-15T23:50:50Z,2018-12-12T23:56:08Z,Expand std::pin module docs and rename std::pin::Pinned to PhantomPinned,cramertj,709b7515e744cdf242ab53806414aa295ea6977f,2,Rename Pinned marker type to PhantomPinned,THUMBS_UP,2018-11-29T13:54:43Z,hcpl,NA https://github.com/rust-lang/rust/pull/55992,MERGED,2018-11-15T23:50:50Z,2018-12-12T23:56:08Z,Expand std::pin module docs and rename std::pin::Pinned to PhantomPinned,cramertj,709b7515e744cdf242ab53806414aa295ea6977f,2,Rename Pinned marker type to PhantomPinned,THUMBS_UP,2018-12-09T17:25:05Z,0e4ef622,0e4ef622@gmail.com https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,THUMBS_UP,2018-11-16T11:34:15Z,parched,NA https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,HOORAY,2018-11-16T11:49:35Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,THUMBS_UP,2018-11-16T12:35:00Z,paoloteti,NA https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,HOORAY,2018-11-16T13:47:39Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,HEART,2018-11-16T19:02:34Z,evq,NA https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,HOORAY,2018-11-30T11:29:08Z,0xc0170,martin.kojtal@arm.com https://github.com/rust-lang/rust/pull/56000,MERGED,2018-11-16T11:24:06Z,2018-12-07T11:05:34Z,Add Armv8-M Mainline targets,hug-dev,0f47c2a078588f4e9d118f7039dc3d10985b68bd,4,Add Armv8-M Mainline targets This commit enables the Armv8-M Mainline architecture profile. It adds two targets: - thumbv8m.main-none-eabi - thumbv8m.main-none-eabihf The second one uses the Floating Point Unit for floating point operations. It mainly targets the Cortex-M33 processor which can have the optional Floating Point Unit extension.,THUMBS_UP,2019-01-17T14:25:31Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/56002,MERGED,2018-11-16T12:13:53Z,2018-11-22T13:07:50Z,fix #55972: Erroneous self arguments on bare functions emit subpar compilation error,lcnr,88d60941da317d8e9deee34d2ed5e8dbb54f928c,7,improve error note,HEART,2018-11-16T16:01:40Z,estebank,NA https://github.com/rust-lang/rust/pull/56005,MERGED,2018-11-16T15:35:16Z,2018-12-15T09:05:08Z,Greatly improve rustdoc rendering speed issues,GuillaumeGomez,b8c1726f267ce24b773f04c7d161c62f6fbc05fb,2,Show 'loading content' when loading content,THUMBS_UP,2018-12-04T09:34:50Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/56011,MERGED,2018-11-16T20:36:42Z,2018-11-19T16:59:50Z,Replace data.clone() by Arc::clone(&data) in mutex doc.,CBenoit,c1221e2072beebe90d6bbe8be99a51be1e6d11ea,1,Replace data.clone() by Arc::clone(&data) in mutex doc. Arc::clone(&from) is considered as more idiomatic because it conveys more explicitly the meaning of the code.,THUMBS_UP,2018-11-16T20:37:15Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56012,MERGED,2018-11-16T21:20:44Z,2018-11-19T16:59:50Z,avoid shared ref in UnsafeCell::get,RalfJung,25d46f309130be1671d7e44d48e67b23f510bcdc,1,add comment explaining why what we do is legal,THUMBS_UP,2018-11-16T23:01:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56012,MERGED,2018-11-16T21:20:44Z,2018-11-19T16:59:50Z,avoid shared ref in UnsafeCell::get,RalfJung,25d46f309130be1671d7e44d48e67b23f510bcdc,1,add comment explaining why what we do is legal,THUMBS_UP,2018-11-22T05:07:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-11-19T11:38:05Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-11-19T16:33:37Z,jack-fortanix,jack.lloyd@fortanix.com https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-11-19T19:38:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-11-20T05:22:49Z,VardhanThigle,NA https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-11-27T19:58:15Z,Pratyush,NA https://github.com/rust-lang/rust/pull/56066,MERGED,2018-11-19T11:15:06Z,2018-12-07T08:46:57Z,Add SGX target to std and dependencies,jethrogb,7bea6a19641118937781d7971ba96e8d4a81497c,2,SGX target: implement command-line arguments and environment variables,HOORAY,2018-12-07T20:54:31Z,jseyfried,NA https://github.com/rust-lang/rust/pull/56070,MERGED,2018-11-19T12:49:35Z,2018-11-26T11:18:40Z,Allow assignments in const contexts,oli-obk,6db8c6c6d9fd1f8226b3afd9e18c6fb3cd2f1176,5,Explain why we do not overwrite qualification of locals,HEART,2018-11-22T12:40:21Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56070,MERGED,2018-11-19T12:49:35Z,2018-11-26T11:18:40Z,Allow assignments in const contexts,oli-obk,6db8c6c6d9fd1f8226b3afd9e18c6fb3cd2f1176,5,Explain why we do not overwrite qualification of locals,HOORAY,2018-11-28T17:01:36Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56070,MERGED,2018-11-19T12:49:35Z,2018-11-26T11:18:40Z,Allow assignments in const contexts,oli-obk,6db8c6c6d9fd1f8226b3afd9e18c6fb3cd2f1176,5,Explain why we do not overwrite qualification of locals,HOORAY,2018-11-28T19:07:00Z,whentze,NA https://github.com/rust-lang/rust/pull/56074,MERGED,2018-11-19T19:45:57Z,2019-01-04T17:01:31Z,Forbid recursive impl trait,matthewjasper,65c1f54a06293b2a1345c69d0b5d88d1343e3b5b,7,Forbid impl Trait from referring to unnamable recursive types There is no type T such that `T = [T; 2]` we should not allow this to be circumvented by impl Trait.,LAUGH,2018-11-24T22:26:03Z,RalfJung,NA https://github.com/rust-lang/rust/pull/56074,MERGED,2018-11-19T19:45:57Z,2019-01-04T17:01:31Z,Forbid recursive impl trait,matthewjasper,65c1f54a06293b2a1345c69d0b5d88d1343e3b5b,7,Forbid impl Trait from referring to unnamable recursive types There is no type T such that `T = [T; 2]` we should not allow this to be circumvented by impl Trait.,THUMBS_UP,2019-01-09T21:55:39Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56074,MERGED,2018-11-19T19:45:57Z,2019-01-04T17:01:31Z,Forbid recursive impl trait,matthewjasper,65c1f54a06293b2a1345c69d0b5d88d1343e3b5b,7,Forbid impl Trait from referring to unnamable recursive types There is no type T such that `T = [T; 2]` we should not allow this to be circumvented by impl Trait.,THUMBS_UP,2019-01-11T05:24:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56074,MERGED,2018-11-19T19:45:57Z,2019-01-04T17:01:31Z,Forbid recursive impl trait,matthewjasper,65c1f54a06293b2a1345c69d0b5d88d1343e3b5b,7,Forbid impl Trait from referring to unnamable recursive types There is no type T such that `T = [T; 2]` we should not allow this to be circumvented by impl Trait.,THUMBS_UP,2019-01-11T12:56:41Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/56090,MERGED,2018-11-20T04:10:54Z,2018-12-13T05:58:59Z,Overhaul `FileSearch` and `SearchPaths`,nnethercote,209240dc267075d69eb8d1dba23be2a8c80c6427,1,"Remove some env vars for rustdoc invocations. In an attempt to avoid ""thread '' panicked at 'failed to acquire jobserver token: Bad file descriptor"" errors.",THUMBS_UP,2018-12-19T18:50:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-11T13:31:38Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-11T20:18:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-11T20:51:24Z,faern,NA https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-19T17:06:17Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-19T18:57:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-20T15:36:09Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2018-12-25T18:23:04Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/56092,MERGED,2018-11-20T06:36:01Z,2018-12-12T15:37:43Z,std: Depend directly on crates.io crates,alexcrichton,4c21a3bc2afc5933f31f1368f6b3406c5f1bdeb3,99,"std: Depend directly on crates.io crates Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations namely that Cargo doesn't understand that crates from crates.io depend on libcore so Cargo tries to build crates before libcore is finished. I had an idea this afternoon however which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins` but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = ""0.1"" features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build ""as is"" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept this commit removes the `dlmalloc` `libcompiler_builtins` and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working however as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3",HOORAY,2019-06-15T02:09:28Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/56102,MERGED,2018-11-20T14:39:20Z,2018-11-21T02:30:30Z,beta backport rollup,nikomatsakis,93704f2f975efed3a764a5dbab8c4afc66049ece,3,Add a couple more tests,HOORAY,2018-11-21T00:27:46Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/56102,MERGED,2018-11-20T14:39:20Z,2018-11-21T02:30:30Z,beta backport rollup,nikomatsakis,93704f2f975efed3a764a5dbab8c4afc66049ece,3,Add a couple more tests,HOORAY,2018-11-28T22:40:13Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/56113,MERGED,2018-11-20T19:51:04Z,2019-02-22T09:33:29Z,Erroneous loop diagnostic in nll,spastorino,a12982cdc2fee3d892015ee981a2f98481f831f0,1,Run rustfmt,THUMBS_UP,2018-11-23T23:36:13Z,estebank,NA https://github.com/rust-lang/rust/pull/56118,MERGED,2018-11-21T02:27:28Z,2018-11-21T19:07:35Z,Update books for Rust 2018,steveklabnik,d7b3f5c6aeedf07c6a0ea4d5a79a106642488e0d,9,update various stdlib docs,HOORAY,2018-11-21T02:36:13Z,ashleygwilliams,NA https://github.com/rust-lang/rust/pull/56119,MERGED,2018-11-21T04:02:36Z,2018-12-06T01:37:01Z,Utilize `?` instead of `return None`.,frewsxcv,9012af6f19d999869824e3b933de5f7b30986877,12,Utilize `?` instead of `return None`.,HEART,2018-12-03T06:04:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56120,MERGED,2018-11-21T05:14:32Z,2018-11-23T21:46:29Z,Add unstable Literal::subspan().,SergioBenitez,09e7051b7eb1d2aa1e1d34b7b09a594cba901141,4,Add unstable Literal::subspan().,HOORAY,2018-11-21T08:22:10Z,parched,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2018-11-21T16:58:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_DOWN,2018-11-21T19:53:39Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,CONFUSED,2018-11-23T06:23:09Z,kennytm,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2018-12-02T08:09:08Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_DOWN,2018-12-11T11:10:09Z,Vurich,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_DOWN,2019-01-14T06:23:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2019-02-01T09:31:32Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2019-02-05T08:03:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_DOWN,2019-02-06T17:34:20Z,koute,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2019-02-06T22:09:29Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_UP,2019-02-12T00:47:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,THUMBS_DOWN,2019-02-13T16:47:26Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/56138,CLOSED,2018-11-21T14:28:34Z,2019-02-14T21:54:27Z,Rename `MaybeUninit` to `MaybeUninitialized`,shepmaster,NA,NA,NA,CONFUSED,2019-02-13T22:56:28Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/56144,MERGED,2018-11-21T19:32:28Z,2018-11-25T19:01:16Z,Fix BTreeSet and BTreeMap gdb pretty-printers,tromey,d4ee1c93ff25a7fa6f5e35dc774a648a7e6d578e,3,Fix BTreeSet and BTreeMap gdb pretty-printers The BTreeSet and BTreeMap gdb pretty-printers did not take the node structure into account and consequently only worked for shallow sets. This fixes the problem by iterating over child nodes when needed. This patch avoids the current approach of implementing some of the value manipulations in debugger-indepdendent code. This was done for convenience: a type lookup was needed for the first time and there currently are no lldb formatters for these types. Closes #55771,HOORAY,2018-11-25T19:12:42Z,ortem,ortem00@gmail.com https://github.com/rust-lang/rust/pull/56144,MERGED,2018-11-21T19:32:28Z,2018-11-25T19:01:16Z,Fix BTreeSet and BTreeMap gdb pretty-printers,tromey,d4ee1c93ff25a7fa6f5e35dc774a648a7e6d578e,3,Fix BTreeSet and BTreeMap gdb pretty-printers The BTreeSet and BTreeMap gdb pretty-printers did not take the node structure into account and consequently only worked for shallow sets. This fixes the problem by iterating over child nodes when needed. This patch avoids the current approach of implementing some of the value manipulations in debugger-indepdendent code. This was done for convenience: a type lookup was needed for the first time and there currently are no lldb formatters for these types. Closes #55771,HOORAY,2018-11-29T05:05:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HEART,2018-11-22T00:05:17Z,cramertj,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2018-11-22T01:21:39Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2018-11-22T12:40:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HEART,2018-11-22T12:40:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2018-11-22T16:57:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2018-11-22T18:15:47Z,killercup,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HEART,2018-11-22T18:15:51Z,killercup,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2018-11-23T02:18:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HEART,2018-11-25T22:44:43Z,bluss,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2019-01-09T21:10:42Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2019-01-09T21:55:01Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56145,MERGED,2018-11-21T21:47:15Z,2019-01-05T03:36:37Z,Implement the Re-rebalance coherence RFC,weiznich,d758e4db783618daef974d067fdf6cfb285f48d5,6,Update tests changed by rebase,HOORAY,2019-01-11T05:25:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-11-22T16:56:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-11-22T17:41:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-11-22T18:19:05Z,killercup,NA https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-11-23T10:10:30Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-11-24T00:55:32Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/56160,MERGED,2018-11-22T13:44:28Z,2018-12-18T16:51:23Z,Fix various aspects around `let` bindings inside const functions,oli-obk,d815e2b870793e8793900be0aeb8ccaf5e4c7291,2,Explain that lack of short circuiting support in constants is temporary,HOORAY,2018-12-26T18:03:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2018-11-22T14:07:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2018-11-22T16:55:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2018-11-24T20:43:47Z,bluss,NA https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2018-12-19T18:57:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2018-12-22T07:45:56Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2019-08-21T15:08:18Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56161,MERGED,2018-11-22T13:46:38Z,2018-12-13T09:47:24Z,VecDeque: fix for stacked borrows,RalfJung,feb775c834361f635df9e3824f9d2ae9582becbb,1,Drain only needs a shared reference,HEART,2020-02-24T22:56:02Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/56170,MERGED,2018-11-22T18:12:48Z,2018-11-25T19:01:19Z,Fix self profiler ICE on Windows,wesleywiser,dce1c4530e2707c338fe56b26a36797377f11514,1,[Windows] Work around non-monotonic clocks in the self-profiler On Windows the high-resolution timestamp api doesn't seem to always be monotonic. This can cause panics when the self-profiler uses the `Instant` api to find elapsed time. Work around this by detecting the case where now is less than the start time and just use 0 elapsed ticks as the measurement. Fixes #51648,HOORAY,2018-11-25T15:38:32Z,estebank,NA https://github.com/rust-lang/rust/pull/56170,MERGED,2018-11-22T18:12:48Z,2018-11-25T19:01:19Z,Fix self profiler ICE on Windows,wesleywiser,dce1c4530e2707c338fe56b26a36797377f11514,1,[Windows] Work around non-monotonic clocks in the self-profiler On Windows the high-resolution timestamp api doesn't seem to always be monotonic. This can cause panics when the self-profiler uses the `Instant` api to find elapsed time. Work around this by detecting the case where now is less than the start time and just use 0 elapsed ticks as the measurement. Fixes #51648,HOORAY,2018-11-29T05:04:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56188,MERGED,2018-11-23T21:05:02Z,2018-12-24T10:04:13Z,enum type instead of variant suggestion unification ,zackmdavis,64ad3e2c423f701b856a6780380a0dbb03f90c22,4,adjust enum type instead of variant suggestions for prelude enums The present author regrets not thinking of a more eloquent way to do this.,THUMBS_UP,2019-01-07T02:05:15Z,estebank,NA https://github.com/rust-lang/rust/pull/56189,MERGED,2018-11-23T22:49:02Z,2019-01-18T19:08:29Z,rustdoc: Add option to persist doc test executables,repnop,f5413cd1e232837775bd8dfc803af4429e8c89c4,2,Bless test. Bless test remove submodule and fix book entry. bless test again? maybe it'll work this time...,THUMBS_UP,2018-11-25T05:04:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56189,MERGED,2018-11-23T22:49:02Z,2019-01-18T19:08:29Z,rustdoc: Add option to persist doc test executables,repnop,f5413cd1e232837775bd8dfc803af4429e8c89c4,2,Bless test. Bless test remove submodule and fix book entry. bless test again? maybe it'll work this time...,THUMBS_UP,2018-11-27T22:14:18Z,xd009642,NA https://github.com/rust-lang/rust/pull/56189,MERGED,2018-11-23T22:49:02Z,2019-01-18T19:08:29Z,rustdoc: Add option to persist doc test executables,repnop,f5413cd1e232837775bd8dfc803af4429e8c89c4,2,Bless test. Bless test remove submodule and fix book entry. bless test again? maybe it'll work this time...,THUMBS_UP,2019-01-06T03:08:31Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/56189,MERGED,2018-11-23T22:49:02Z,2019-01-18T19:08:29Z,rustdoc: Add option to persist doc test executables,repnop,f5413cd1e232837775bd8dfc803af4429e8c89c4,2,Bless test. Bless test remove submodule and fix book entry. bless test again? maybe it'll work this time...,HEART,2019-02-18T22:45:23Z,sunjay,NA https://github.com/rust-lang/rust/pull/56200,CLOSED,2018-11-24T16:23:42Z,2018-12-17T07:30:26Z,Rustdoc dark theme improvements,denisdefreyne,NA,NA,NA,HEART,2018-12-13T09:16:21Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56207,MERGED,2018-11-25T07:29:58Z,2018-11-25T19:01:22Z,Stabilize the int_to_from_bytes feature,SimonSapin,68a26ec647147d70bcd7f0e7f56a0bf9fedb5f06,3,Stabilize the int_to_from_bytes feature Fixes #52963,HOORAY,2018-11-25T09:11:05Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56207,MERGED,2018-11-25T07:29:58Z,2018-11-25T19:01:22Z,Stabilize the int_to_from_bytes feature,SimonSapin,68a26ec647147d70bcd7f0e7f56a0bf9fedb5f06,3,Stabilize the int_to_from_bytes feature Fixes #52963,HOORAY,2018-11-26T03:17:42Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/56207,MERGED,2018-11-25T07:29:58Z,2018-11-25T19:01:22Z,Stabilize the int_to_from_bytes feature,SimonSapin,68a26ec647147d70bcd7f0e7f56a0bf9fedb5f06,3,Stabilize the int_to_from_bytes feature Fixes #52963,HOORAY,2018-11-29T05:05:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56207,MERGED,2018-11-25T07:29:58Z,2018-11-25T19:01:22Z,Stabilize the int_to_from_bytes feature,SimonSapin,68a26ec647147d70bcd7f0e7f56a0bf9fedb5f06,3,Stabilize the int_to_from_bytes feature Fixes #52963,HOORAY,2019-01-10T01:46:38Z,hugwijst,NA https://github.com/rust-lang/rust/pull/56214,MERGED,2018-11-25T15:48:29Z,2018-11-30T22:01:29Z,Implement chalk unification routines,scalexm,1fce415649784ecaf3bcb3a6916e10284c0affec,1,Correctly generalize inference variables in `nll_relate`,HEART,2018-11-30T06:11:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56214,MERGED,2018-11-25T15:48:29Z,2018-11-30T22:01:29Z,Implement chalk unification routines,scalexm,1fce415649784ecaf3bcb3a6916e10284c0affec,1,Correctly generalize inference variables in `nll_relate`,HEART,2018-12-06T08:26:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56214,MERGED,2018-11-25T15:48:29Z,2018-11-30T22:01:29Z,Implement chalk unification routines,scalexm,1fce415649784ecaf3bcb3a6916e10284c0affec,1,Correctly generalize inference variables in `nll_relate`,HEART,2018-12-08T03:24:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56219,MERGED,2018-11-25T17:48:34Z,2018-12-20T06:13:26Z,trigger unsized coercions keyed on Sized bounds,arielb1,5b7443810794aa9f771ea26a5e72ae2b567481b0,1,add comment about subtyping,HOORAY,2018-11-29T20:31:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56219,MERGED,2018-11-25T17:48:34Z,2018-12-20T06:13:26Z,trigger unsized coercions keyed on Sized bounds,arielb1,5b7443810794aa9f771ea26a5e72ae2b567481b0,1,add comment about subtyping,HOORAY,2018-12-13T22:09:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56219,MERGED,2018-11-25T17:48:34Z,2018-12-20T06:13:26Z,trigger unsized coercions keyed on Sized bounds,arielb1,5b7443810794aa9f771ea26a5e72ae2b567481b0,1,add comment about subtyping,HOORAY,2018-12-19T03:10:12Z,kennytm,NA https://github.com/rust-lang/rust/pull/56219,MERGED,2018-11-25T17:48:34Z,2018-12-20T06:13:26Z,trigger unsized coercions keyed on Sized bounds,arielb1,5b7443810794aa9f771ea26a5e72ae2b567481b0,1,add comment about subtyping,HOORAY,2018-12-20T07:53:24Z,RalfJung,NA https://github.com/rust-lang/rust/pull/56219,MERGED,2018-11-25T17:48:34Z,2018-12-20T06:13:26Z,trigger unsized coercions keyed on Sized bounds,arielb1,5b7443810794aa9f771ea26a5e72ae2b567481b0,1,add comment about subtyping,HOORAY,2018-12-26T18:03:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2018-11-26T08:30:41Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2018-11-29T21:54:45Z,caitp,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2018-12-02T15:36:07Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2018-12-03T03:54:50Z,tlively,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2018-12-09T21:35:06Z,timsueberkrueb,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2018-12-09T21:35:22Z,timsueberkrueb,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2018-12-15T19:42:06Z,estebank,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2018-12-24T03:56:05Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2018-12-24T03:56:07Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2019-01-01T11:47:32Z,KeenS,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2019-01-14T09:43:16Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2019-01-16T06:40:57Z,behnam,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2019-04-04T18:30:55Z,anirudhb,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,HOORAY,2019-04-04T18:30:56Z,anirudhb,NA https://github.com/rust-lang/rust/pull/56225,MERGED,2018-11-26T04:16:38Z,2018-12-29T23:45:51Z,"Implement RFC 2338 ""Type alias enum variants""",alexreg,a4fa7ef2b90880623499e86324b7b40626a02f9d,3,Fixed stderr files for ui tests.,THUMBS_UP,2019-04-09T09:13:49Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/56231,MERGED,2018-11-26T10:31:30Z,2019-11-27T21:01:33Z,rustc: move debug info from LocalDecl and UpvarDecl into a dedicated VarDebugInfo.,eddyb,563ed27c01c204d734355709c905f9a14246d4ff,49,rustc: move debug info from LocalDecl and UpvarDecl into a dedicated VarDebugInfo.,ROCKET,2019-12-23T20:15:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56236,MERGED,2018-11-26T13:43:39Z,2018-11-29T15:24:57Z,Remove unsafe `unsafe` inner function.,frewsxcv,cc466851bc458219121142ae75f5cc47bb3a927f,1,Remove unsafe `unsafe` inner function. Within this `Iterator` implementation a function `unsafe_get` is defined which unsafely allows _unchecked_ indexing of any element in a slice. This should be marked as _unsafe_ but it is not. To address this issue I removed that inner function.,THUMBS_UP,2018-12-05T21:15:06Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-26T17:10:35Z,tennix,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-26T20:44:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-27T10:23:56Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-28T17:10:22Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-11-29T00:22:34Z,varkor,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-29T12:55:11Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-29T17:19:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-11-29T22:28:34Z,killercup,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-11-29T22:28:35Z,killercup,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-11-30T00:05:20Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-02T00:17:36Z,faern,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-02T14:36:55Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-02T14:36:58Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-02T22:16:18Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-03T18:22:38Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-04T09:06:39Z,SaulDoesCode,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-04T20:38:27Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-04T23:03:24Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-04T23:03:35Z,Veedrac,joshua@landau.ws https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-05T00:28:28Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-05T02:34:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-05T02:34:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-07T21:11:30Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-07T23:16:56Z,bluss,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-12T14:40:55Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-12T14:40:56Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-18T10:22:27Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-21T03:04:52Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-27T17:51:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-27T17:51:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-29T19:01:42Z,mati865,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2018-12-29T19:01:45Z,mati865,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2018-12-31T21:11:21Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-01-04T18:39:21Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-01-06T09:29:58Z,Proximyst,mariell@mardroemmar.dev https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-01-06T09:29:59Z,Proximyst,mariell@mardroemmar.dev https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-01-24T11:28:48Z,QuestofIranon,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-01-29T12:46:21Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-02-03T13:13:43Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-02-03T13:14:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-02-13T01:36:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-02-13T01:36:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-02-18T23:11:23Z,slmjkdbtl,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-02-28T10:49:16Z,hcpl,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-02T17:05:21Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-02T19:00:47Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-03-02T23:43:07Z,elahn,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-03-03T00:10:27Z,hbobenicio,hbobenicio@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-03-04T14:48:39Z,i30817,i30817@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-04T14:48:43Z,i30817,i30817@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-08T06:03:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-03-11T05:14:15Z,abolking,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-11T05:14:17Z,abolking,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-16T20:57:06Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-17T16:23:02Z,rockmenjack,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-03-25T01:25:35Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HOORAY,2019-09-13T10:22:42Z,weihanglo,NA https://github.com/rust-lang/rust/pull/56241,CLOSED,2018-11-26T16:19:31Z,2019-03-06T12:46:58Z,Replace HashMap implementation with SwissTable,Amanieu,NA,NA,NA,HEART,2019-09-13T10:22:42Z,weihanglo,NA https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-05T18:41:32Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-05T22:43:38Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-06T08:27:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-06T09:09:28Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-07T10:17:15Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-19T21:16:36Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2018-12-25T10:51:34Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2019-01-17T20:41:26Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/56245,MERGED,2018-11-26T17:04:41Z,2018-11-29T09:36:49Z,Stabilize feature `macro_at_most_once_rep`,mark-i-m,5d7717360c8f343f70a33455029355f00e39dea2,1,fix test,HOORAY,2019-01-19T00:58:36Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/56258,MERGED,2018-11-26T21:57:28Z,2018-12-08T01:47:21Z,use top level `fs` functions where appropriate,euclio,2f6226518bd5085896a0f27cfd3ea396367ecd50,26,use top level `fs` functions where appropriate This commit replaces many usages of `File::open` and reading or writing with `fs::read_to_string` `fs::read` and `fs::write`. This reduces code complexity and will improve performance for most reads since the functions allocate the buffer to be the size of the file. I believe that this commit will not impact behavior in any way so some matches will check the error kind in case the file was not valid UTF-8. Some of these cases may not actually care about the error.,HEART,2018-11-29T07:45:49Z,jplatte,NA https://github.com/rust-lang/rust/pull/56258,MERGED,2018-11-26T21:57:28Z,2018-12-08T01:47:21Z,use top level `fs` functions where appropriate,euclio,2f6226518bd5085896a0f27cfd3ea396367ecd50,26,use top level `fs` functions where appropriate This commit replaces many usages of `File::open` and reading or writing with `fs::read_to_string` `fs::read` and `fs::write`. This reduces code complexity and will improve performance for most reads since the functions allocate the buffer to be the size of the file. I believe that this commit will not impact behavior in any way so some matches will check the error kind in case the file was not valid UTF-8. Some of these cases may not actually care about the error.,THUMBS_UP,2018-12-10T00:34:48Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56262,MERGED,2018-11-26T23:02:47Z,2018-11-27T04:06:27Z,[master] resolve: Implement edition hygiene for imports and absolute paths,petrochenkov,6f13708299c22cf8450e239c4ab06aada2d1cf07,16,resolve: Suggest `crate::` for resolving ambiguities when appropriate More precise spans for ambiguities from macros,HOORAY,2018-11-27T03:29:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56269,MERGED,2018-11-27T03:35:30Z,2018-12-10T03:33:31Z,Use a `SmallVec` within `_match::Matrix`.,nnethercote,cdc66334242dec2d30a17988ca8d150c65580620,2,Use a `SmallVec` within `_match::Matrix`. This commit also fixes up lifetimes a bit: - Renames `'a` as `'p` when used with `Matrix` and `Pattern` for consistency. - Removes some unnecessary `'p` lifetimes on some function arguments. - Adds some missing lifetime parameters.,THUMBS_UP,2018-11-30T00:10:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56275,MERGED,2018-11-27T10:09:27Z,2018-12-02T16:17:34Z,use MaybeUninit instead of mem::uninitialized for Windows Mutex,RalfJung,ebe69c06b38e0d1d20c79ee4342715514e917107,1,avoid MaybeUninit::get_mut where it is not needed,HOORAY,2018-11-27T10:24:40Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56275,MERGED,2018-11-27T10:09:27Z,2018-12-02T16:17:34Z,use MaybeUninit instead of mem::uninitialized for Windows Mutex,RalfJung,ebe69c06b38e0d1d20c79ee4342715514e917107,1,avoid MaybeUninit::get_mut where it is not needed,HOORAY,2018-12-06T08:27:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56291,MERGED,2018-11-27T18:35:33Z,2019-02-05T04:32:18Z,Initial addition of the Embedded Rust Book,jamesmunns,4633cca157d9730d75e3fc6144ae952b76f5559f,1,Update embedded book dependency,HOORAY,2018-11-28T09:09:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56291,MERGED,2018-11-27T18:35:33Z,2019-02-05T04:32:18Z,Initial addition of the Embedded Rust Book,jamesmunns,4633cca157d9730d75e3fc6144ae952b76f5559f,1,Update embedded book dependency,HOORAY,2018-12-13T09:04:46Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56291,MERGED,2018-11-27T18:35:33Z,2019-02-05T04:32:18Z,Initial addition of the Embedded Rust Book,jamesmunns,4633cca157d9730d75e3fc6144ae952b76f5559f,1,Update embedded book dependency,HOORAY,2019-02-13T19:12:20Z,Jesse-Millwood,NA https://github.com/rust-lang/rust/pull/56291,MERGED,2018-11-27T18:35:33Z,2019-02-05T04:32:18Z,Initial addition of the Embedded Rust Book,jamesmunns,4633cca157d9730d75e3fc6144ae952b76f5559f,1,Update embedded book dependency,HOORAY,2019-02-13T20:08:40Z,dotcypress,dotcypress@gmail.com https://github.com/rust-lang/rust/pull/56291,MERGED,2018-11-27T18:35:33Z,2019-02-05T04:32:18Z,Initial addition of the Embedded Rust Book,jamesmunns,4633cca157d9730d75e3fc6144ae952b76f5559f,1,Update embedded book dependency,HOORAY,2019-02-14T06:04:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,THUMBS_UP,2018-11-28T00:29:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,HOORAY,2018-11-28T01:10:44Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,THUMBS_UP,2018-11-28T01:10:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,HOORAY,2018-12-12T13:01:51Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,THUMBS_UP,2018-12-12T20:05:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,HOORAY,2018-12-18T00:49:51Z,strake,strake888@gmail.com https://github.com/rust-lang/rust/pull/56303,MERGED,2018-11-28T00:00:30Z,2018-12-18T00:39:46Z,Stabilize `underscore_imports`,petrochenkov,7c901ba537c0df324c8b99f06ca3b76fcf20766a,12,Stabilize `underscore_imports`,THUMBS_UP,2018-12-26T18:23:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56315,MERGED,2018-11-28T16:13:45Z,2018-12-06T15:07:54Z,Rustdoc inline macro reexport,weiznich,956b03f7db8b6b6b73bb4b2b6e0cbb1016e08f8a,1,Add a test case for inlining the docs of a macro reexport,THUMBS_UP,2018-11-28T16:36:31Z,bkchr,NA https://github.com/rust-lang/rust/pull/56319,MERGED,2018-11-28T18:32:16Z,2018-11-29T15:25:07Z,fix futures creating aliasing mutable and shared ref,RalfJung,46a683111d4827800aae5eab4875c23089dce17e,1,fix futures aliasing mutable and shared ref,HEART,2018-12-08T05:06:50Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56319,MERGED,2018-11-28T18:32:16Z,2018-11-29T15:25:07Z,fix futures creating aliasing mutable and shared ref,RalfJung,46a683111d4827800aae5eab4875c23089dce17e,1,fix futures aliasing mutable and shared ref,HEART,2019-11-01T10:05:41Z,95th,NA https://github.com/rust-lang/rust/pull/56323,CLOSED,2018-11-28T20:09:14Z,2019-01-28T14:57:28Z,serialize: rename to rustc_serialize.,eddyb,NA,NA,NA,LAUGH,2018-11-29T03:44:40Z,kennytm,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-29T21:05:57Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-29T22:38:43Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2018-11-29T23:57:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T10:14:59Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T12:01:14Z,qnighy,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T12:17:49Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T14:32:33Z,killercup,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T17:55:50Z,xen0n,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T18:20:36Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-11-30T23:38:11Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-01T04:56:32Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-01T07:12:00Z,Ralith,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-02T08:03:14Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-03T00:04:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-04T05:04:37Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-04T23:09:44Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2018-12-05T19:32:59Z,bluss,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-06T03:29:00Z,chris-morgan,me@chrismorgan.info https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-11T07:40:56Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2018-12-22T12:37:15Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-01-03T13:59:02Z,jesskfullwood,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-02-16T22:07:37Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-02T06:27:53Z,Avi-D-coder,avi.the.coder@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-18T15:59:13Z,pingiun,jelle@pingiun.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-19T14:15:39Z,delacian,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-19T22:21:44Z,gliderkite,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-24T15:42:24Z,hcpl,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2019-03-27T11:55:05Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-27T12:30:16Z,Boiethios,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-27T12:39:08Z,zivit,zinc.vitaliy@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2019-03-27T17:17:32Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-27T22:04:09Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_DOWN,2019-03-28T07:12:17Z,mikhail-krainik,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-28T09:59:48Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-28T10:18:50Z,qdequele,quentin@meilisearch.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-28T17:23:25Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-28T17:42:14Z,dotcypress,dotcypress@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-28T18:06:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2019-03-29T04:07:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-30T09:25:56Z,Emerentius,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-03-31T19:28:41Z,xilec,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-04-01T19:08:27Z,slmjkdbtl,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-04-19T16:04:30Z,moshg,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,CONFUSED,2019-06-22T19:41:13Z,mcarton,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-07-28T17:31:24Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_DOWN,2019-10-10T07:47:02Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-10-24T21:39:20Z,warrd,NA https://github.com/rust-lang/rust/pull/56348,MERGED,2018-11-29T19:20:55Z,2019-03-19T17:58:33Z,Add todo!() macro,matklad,9d408d972f7cf16162ec3ab35e11c659ccee9566,2,Add todo!() macro The use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro.,THUMBS_UP,2019-12-16T15:56:37Z,prostomarkeloff,NA https://github.com/rust-lang/rust/pull/56351,MERGED,2018-11-29T21:02:05Z,2018-12-14T02:53:39Z,Stabilize `linker-flavor` flag.,davidtwco,9536d04a2d1af8163a0ec772ec747a0e98a8e4db,8,Stabilize `linker-flavor` flag. This commit moves the linker-flavor flag from a debugging option to a codegen option thus stabilizing it. There are no feature flags associated with this flag.,HEART,2019-02-06T20:48:54Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56351,MERGED,2018-11-29T21:02:05Z,2018-12-14T02:53:39Z,Stabilize `linker-flavor` flag.,davidtwco,9536d04a2d1af8163a0ec772ec747a0e98a8e4db,8,Stabilize `linker-flavor` flag. This commit moves the linker-flavor flag from a debugging option to a codegen option thus stabilizing it. There are no feature flags associated with this flag.,HEART,2019-03-12T17:06:05Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/56352,MERGED,2018-11-29T21:02:29Z,2018-11-30T04:46:50Z,Rollup beta backports,alexcrichton,9023e9430bf4e6380638babe34aa0019b62b2066,2,Update rustfmt to build on all arches cc #56261,HEART,2018-11-29T21:32:24Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/56352,MERGED,2018-11-29T21:02:29Z,2018-11-30T04:46:50Z,Rollup beta backports,alexcrichton,9023e9430bf4e6380638babe34aa0019b62b2066,2,Update rustfmt to build on all arches cc #56261,HEART,2018-11-29T21:32:56Z,estebank,NA https://github.com/rust-lang/rust/pull/56357,CLOSED,2018-11-29T22:26:45Z,2018-12-01T21:21:25Z,Use `?` Kleene operator again,mark-i-m,NA,NA,NA,HOORAY,2018-11-29T22:37:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56358,MERGED,2018-11-29T22:39:23Z,2018-12-03T04:52:58Z,Enable -mergefunc-use-aliases,nikic,850d2f1af0224cf1d442a66c33470791a2597888,1,Run name-anon-globals after all other passes name-anon-globals should always be run at the very end of the pass pipeline as optimization passes (in particular mergefunc) may introduce new anonymous globals. I believe we did not run into this earlier because it requires the rather specific combination of a) mergefunc merging two weak functions b) compilation not using thinlto.,HOORAY,2018-11-29T23:19:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56358,MERGED,2018-11-29T22:39:23Z,2018-12-03T04:52:58Z,Enable -mergefunc-use-aliases,nikic,850d2f1af0224cf1d442a66c33470791a2597888,1,Run name-anon-globals after all other passes name-anon-globals should always be run at the very end of the pass pipeline as optimization passes (in particular mergefunc) may introduce new anonymous globals. I believe we did not run into this earlier because it requires the rather specific combination of a) mergefunc merging two weak functions b) compilation not using thinlto.,HEART,2018-11-29T23:27:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HOORAY,2018-11-29T23:12:14Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HEART,2018-11-29T23:12:17Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HEART,2018-11-29T23:16:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HOORAY,2018-11-30T00:14:15Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HOORAY,2018-11-30T05:08:26Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HOORAY,2018-11-30T10:50:05Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HOORAY,2018-11-30T15:33:14Z,kennytm,NA https://github.com/rust-lang/rust/pull/56360,MERGED,2018-11-29T23:03:46Z,2018-11-30T22:01:40Z,Optimize local linkchecker program,alexcrichton,225140ed216d7395530b2e4597fb224305e6375b,1,Optimize local linkchecker program I noticed on a [recent build][1] that the linkchecker stage of CI took a whopping 15 minutes of CI time for something that should be near instantaneous. Some local profiling showed some very hot functions and clones which were pretty easy to remove and now instead of running in minutes locally it runs in seconds. [1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu,HEART,2018-12-04T16:34:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-11-30T15:30:35Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-11-30T16:29:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-12-01T21:55:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-12-03T05:55:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-12-04T18:36:15Z,lqd,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2018-12-05T11:43:07Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2019-02-25T17:24:38Z,sfackler,NA https://github.com/rust-lang/rust/pull/56362,CLOSED,2018-11-30T00:46:23Z,2018-12-06T17:50:32Z,Stabilise exhaustive integer patterns,varkor,NA,NA,NA,HOORAY,2019-03-05T22:58:12Z,hcpl,NA https://github.com/rust-lang/rust/pull/56363,MERGED,2018-11-30T01:36:53Z,2018-12-19T15:23:07Z,Defactored Bytes::read,Lucretiel,a1790e8c200335b6f41f09bb7c7d17bd65b43f8a,1,Reordered match arms,THUMBS_UP,2018-12-10T08:05:28Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56377,CLOSED,2018-11-30T15:43:20Z,2018-12-13T07:21:41Z,[do not merge] Benchmark parallel queries on perf.rlo.,michaelwoerister,NA,NA,NA,THUMBS_UP,2018-12-02T20:41:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56378,MERGED,2018-11-30T15:51:20Z,2018-12-02T13:45:44Z,arena: speed up TypedArena::clear and improve common patterns,ljedrz,95f32f1ebddae26ac6610040ea93ea3de440089a,1,arena: improve common patterns,THUMBS_UP,2018-12-01T00:06:20Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T18:56:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T18:59:04Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HEART,2018-11-30T19:01:14Z,Valinora,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T19:10:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HEART,2018-11-30T19:10:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T19:11:23Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T19:44:40Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HEART,2018-11-30T19:52:02Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T21:18:30Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T22:55:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-11-30T23:30:54Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-01T21:54:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-02T09:27:11Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,THUMBS_UP,2018-12-02T11:24:05Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-02T13:24:29Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-02T22:34:23Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-05T22:09:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-05T23:23:19Z,lqd,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,THUMBS_UP,2018-12-06T18:06:20Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-06T18:06:22Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-11T09:58:37Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HEART,2018-12-11T09:58:41Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,THUMBS_UP,2018-12-11T09:58:43Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-11T11:42:21Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-11T13:38:15Z,Janno,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-11T20:22:02Z,kornholi,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,THUMBS_UP,2018-12-12T20:28:47Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-17T19:07:50Z,tmandry,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-18T12:49:19Z,bjorn3,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-20T10:44:49Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-27T16:22:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HEART,2018-12-29T11:53:44Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/56384,MERGED,2018-11-30T18:52:04Z,2018-12-27T22:27:34Z,Implement the new-style trait solver,scalexm,993d213fdac8dfcecfa134087be385dc609e4f7b,3,Set a `def_id` in `ParamEnv` only with `-Z chalk`,HOORAY,2018-12-30T11:54:18Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/56391,MERGED,2018-11-30T22:32:54Z,2018-12-01T05:29:23Z,ci: Only run compare-mode tests on one builder,alexcrichton,8ee62bb2394596e2c9a72828b755ba90329ea119,4,ci: Only run compare-mode tests on one builder The run-pass test suite currently takes 30 minutes on Windows and that appears to be roughly split between two 15 minute runs of the test suite: one without NLL and one with NLL. In discussion on Discord the platform coverage of the NLL compare mode may not necessarily be worth it so this commit removes the NLL compare mode from tests by default and then reenables it on only one builder.,THUMBS_UP,2018-11-30T22:35:14Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/56391,MERGED,2018-11-30T22:32:54Z,2018-12-01T05:29:23Z,ci: Only run compare-mode tests on one builder,alexcrichton,8ee62bb2394596e2c9a72828b755ba90329ea119,4,ci: Only run compare-mode tests on one builder The run-pass test suite currently takes 30 minutes on Windows and that appears to be roughly split between two 15 minute runs of the test suite: one without NLL and one with NLL. In discussion on Discord the platform coverage of the NLL compare mode may not necessarily be worth it so this commit removes the NLL compare mode from tests by default and then reenables it on only one builder.,THUMBS_UP,2018-11-30T22:54:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56391,MERGED,2018-11-30T22:32:54Z,2018-12-01T05:29:23Z,ci: Only run compare-mode tests on one builder,alexcrichton,8ee62bb2394596e2c9a72828b755ba90329ea119,4,ci: Only run compare-mode tests on one builder The run-pass test suite currently takes 30 minutes on Windows and that appears to be roughly split between two 15 minute runs of the test suite: one without NLL and one with NLL. In discussion on Discord the platform coverage of the NLL compare mode may not necessarily be worth it so this commit removes the NLL compare mode from tests by default and then reenables it on only one builder.,THUMBS_UP,2018-12-01T04:52:04Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2018-12-01T03:18:21Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2018-12-01T21:53:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2018-12-02T16:15:04Z,0e4ef622,0e4ef622@gmail.com https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2018-12-03T05:47:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2018-12-06T01:42:48Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2018-12-06T01:42:49Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),CONFUSED,2018-12-06T03:25:32Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2019-01-16T03:09:31Z,danclive,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2019-01-17T20:23:57Z,Congee,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2019-01-18T00:50:30Z,yihongang,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2019-01-18T00:50:32Z,yihongang,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2019-01-18T09:31:49Z,tforgione,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),THUMBS_UP,2019-01-18T10:14:38Z,brown121407,NA https://github.com/rust-lang/rust/pull/56395,MERGED,2018-12-01T01:57:57Z,2018-12-03T18:10:13Z,Stabilize dbg!(...),Centril,f4cde5bc4e17198670d49c21aa8ce4c199c5489c,9,stabilize std::dbg!(...),HOORAY,2019-02-27T15:59:25Z,xasopheno,danny@xasopheno.com https://github.com/rust-lang/rust/pull/56397,MERGED,2018-12-01T03:52:11Z,2018-12-19T09:02:19Z,Search other library paths when loking for link objects,petrhosek,6d9640b6f6275a4b59e2a59705e18807329b9300,3,Search other library paths when loking for link objects Support the case when link objects are not located in Rust sysroot but in other locations which could be specify through library paths.,THUMBS_UP,2018-12-20T22:06:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-01T15:32:28Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-01T17:22:21Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-01T17:43:44Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-02T00:19:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-02T04:04:41Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-02T04:04:43Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-02T07:42:16Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-02T11:41:50Z,hoodie,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-03T08:50:06Z,Yura52,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-03T10:48:47Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-05T04:40:28Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-05T04:40:29Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2018-12-06T19:00:44Z,koute,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-06T19:00:46Z,koute,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-06T21:17:17Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2018-12-13T15:55:01Z,killercup,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-14T10:58:58Z,anderejd,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-15T16:41:37Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-15T16:41:42Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-17T13:46:52Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-26T21:57:52Z,qmx,qmx@qmx.me https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2018-12-27T18:03:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2018-12-27T18:03:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2018-12-27T18:03:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-01-03T12:26:11Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-02-14T22:23:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-02-14T22:23:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-02-27T15:30:04Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-01T19:33:04Z,pitdicker,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-02T14:52:49Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-02T17:04:42Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-02T17:50:08Z,ondj,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-03T05:54:06Z,00imvj00,vijaybambhaniya007@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-03T21:38:37Z,flosse,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-03T21:38:40Z,flosse,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-03T21:38:44Z,flosse,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-05T08:04:35Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-06T14:47:10Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-08T01:31:43Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-08T01:43:16Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-08T01:43:18Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-11T05:16:16Z,abolking,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-11T05:17:13Z,abolking,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-11T05:17:13Z,abolking,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-11T05:26:16Z,robatipoor,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-11T05:26:16Z,robatipoor,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-11T05:26:17Z,robatipoor,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-14T08:31:00Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-14T08:31:02Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-03-14T08:31:03Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-15T02:57:17Z,KaneGreen,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-03-16T20:57:15Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-03-16T20:57:39Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-04-01T13:05:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-04-01T13:05:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-04-01T13:05:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-04-05T14:40:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-04-09T11:38:29Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,ROCKET,2019-04-12T19:48:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-04-22T02:16:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-04-22T02:16:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-04-22T02:16:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-05-24T21:40:13Z,vmarkushin,negigic@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-05-24T21:40:17Z,vmarkushin,negigic@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-06-15T02:03:26Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-07-09T06:21:24Z,aheart,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-07-15T10:20:44Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-07-15T10:20:45Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-07-15T10:20:45Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-07-21T22:02:06Z,acheronfail,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-08-06T01:27:06Z,xen0n,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-08-31T14:58:33Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-09-08T03:12:12Z,web3shannon,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,ROCKET,2019-09-30T07:43:44Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2019-09-30T07:43:45Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-09-30T07:43:45Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-09-30T07:43:46Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-10-02T07:42:32Z,gliderkite,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-10-22T05:07:21Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-11-09T14:06:13Z,luukvanderduim,luukvanderduim@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-11-20T18:42:01Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2019-12-04T00:41:18Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2019-12-16T23:02:51Z,emcfarlane,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-02-03T04:01:18Z,alexlapa,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2020-02-17T17:06:06Z,d-e-s-o,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-04-30T19:34:30Z,XiangpengHao,me@haoxp.xyz https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-07-26T05:48:18Z,LastLightSith,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,ROCKET,2020-09-18T09:17:48Z,Virgiel,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2020-09-18T09:17:49Z,Virgiel,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2020-09-18T09:17:49Z,Virgiel,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-09-18T09:17:50Z,Virgiel,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-10-03T02:46:31Z,cher-nov,blackdoomer@yandex.ru https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-10-21T09:39:29Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2020-10-21T09:39:30Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2020-10-21T09:39:32Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,ROCKET,2020-10-21T09:39:32Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2020-12-15T08:11:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2020-12-15T08:11:31Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,ROCKET,2020-12-15T08:11:31Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2020-12-15T08:11:35Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2021-02-14T08:58:09Z,sercangenc,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2021-04-26T06:43:58Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2021-08-04T06:41:49Z,yume-chan,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,THUMBS_UP,2021-08-26T05:10:18Z,dbstratta,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HEART,2021-08-26T05:10:19Z,dbstratta,NA https://github.com/rust-lang/rust/pull/56410,CLOSED,2018-12-01T15:15:48Z,2020-02-18T20:58:18Z,Use the parking_lot locking primitives,faern,NA,NA,NA,HOORAY,2021-09-15T20:00:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/56418,MERGED,2018-12-01T21:22:56Z,2018-12-03T18:10:17Z,Fix failing tidy (line endings on Windows),petrochenkov,12c9b79b68ab9c8add6e8ffaab411a2d40b2fd3f,2,Fix failing tidy (line endings on Windows),THUMBS_UP,2018-12-01T21:52:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56419,MERGED,2018-12-01T21:50:31Z,2018-12-03T18:10:17Z,Remove some uses of try!,mark-i-m,e7e96921c28ab8d29b6ee61053152eead822f09a,11,remove some uses of try!,HEART,2018-12-03T05:47:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56425,MERGED,2018-12-02T00:37:50Z,2019-01-12T14:08:28Z,Redo the docs for Vec::set_len,scottmcm,986e49da04fbe2543267561eb8326765c9f48195,1,Merge pull request #1 from Centril/redo-vec-set_len-docs-adjust Explain safety for `vec.set_len(0)`,HEART,2019-01-14T16:53:44Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/56435,MERGED,2018-12-02T12:57:11Z,2018-12-03T18:10:20Z,make the C part of compiler-builtins opt-out,RalfJung,bd20718c8f14cc7f486e1556f7d7897f8f32725b,1,make the C part of compiler-builtins opt-out,THUMBS_UP,2018-12-03T00:01:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56435,MERGED,2018-12-02T12:57:11Z,2018-12-03T18:10:20Z,make the C part of compiler-builtins opt-out,RalfJung,bd20718c8f14cc7f486e1556f7d7897f8f32725b,1,make the C part of compiler-builtins opt-out,THUMBS_UP,2018-12-03T02:10:23Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/56444,MERGED,2018-12-02T20:10:42Z,2018-12-09T21:19:36Z,Move compile-fail-fulldeps tests to UI,petrochenkov,44fe5860607243da202dc97c167c9786d84b0a8d,2,Fix rebase + Add missing `// force-host`,HEART,2018-12-03T00:00:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56444,MERGED,2018-12-02T20:10:42Z,2018-12-09T21:19:36Z,Move compile-fail-fulldeps tests to UI,petrochenkov,44fe5860607243da202dc97c167c9786d84b0a8d,2,Fix rebase + Add missing `// force-host`,HEART,2018-12-03T08:37:04Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/56444,MERGED,2018-12-02T20:10:42Z,2018-12-09T21:19:36Z,Move compile-fail-fulldeps tests to UI,petrochenkov,44fe5860607243da202dc97c167c9786d84b0a8d,2,Fix rebase + Add missing `// force-host`,HEART,2018-12-03T18:31:56Z,estebank,NA https://github.com/rust-lang/rust/pull/56444,MERGED,2018-12-02T20:10:42Z,2018-12-09T21:19:36Z,Move compile-fail-fulldeps tests to UI,petrochenkov,44fe5860607243da202dc97c167c9786d84b0a8d,2,Fix rebase + Add missing `// force-host`,HEART,2018-12-08T10:13:40Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-02T23:13:25Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-02T23:50:35Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T00:02:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T05:19:05Z,estebank,NA https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T05:55:24Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T06:02:30Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T10:19:20Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-03T18:58:19Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HEART,2018-12-04T11:38:13Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2018-12-11T10:39:44Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/56447,CLOSED,2018-12-02T23:02:58Z,2019-02-04T14:17:57Z,Start using serde_derive in a couple places in the compiler.,eddyb,NA,NA,NA,HOORAY,2019-02-03T07:10:51Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/56451,MERGED,2018-12-03T10:07:21Z,2018-12-03T18:10:24Z,Rollup of 13 pull requests,kennytm,ac363d8793a1c6b69822a583e6f7d0b2f9904c86,6,Rollup merge of #56438 - yui-knk:remove_not_used_DotEq_token r=petrochenkov Remove not used `DotEq` token Currently libproc_macro does not use `DotEq` token. https://github.com/rust-lang/rust/pull/49545 changed libproc_macro to not generate `DotEq` token.,HEART,2018-12-03T21:00:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56452,MERGED,2018-12-03T10:19:40Z,2018-12-06T01:37:12Z,Remove redundant clones,sinkuu,bc7c3dc71de785da813784bafaa490f12d4d7cfe,1,sort_by_cached_key -> sort_by,THUMBS_UP,2018-12-03T10:23:17Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56455,MERGED,2018-12-03T13:45:10Z,2018-12-03T21:07:55Z,Stable 1.31.0 release,Mark-Simulacrum,5a31783c6c06e396bc93e3ff48bfbfd343900a92,1,Stable 1.31.0 release,HOORAY,2018-12-03T15:47:07Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/56455,MERGED,2018-12-03T13:45:10Z,2018-12-03T21:07:55Z,Stable 1.31.0 release,Mark-Simulacrum,5a31783c6c06e396bc93e3ff48bfbfd343900a92,1,Stable 1.31.0 release,HOORAY,2018-12-03T18:44:10Z,RalfJung,NA https://github.com/rust-lang/rust/pull/56455,MERGED,2018-12-03T13:45:10Z,2018-12-03T21:07:55Z,Stable 1.31.0 release,Mark-Simulacrum,5a31783c6c06e396bc93e3ff48bfbfd343900a92,1,Stable 1.31.0 release,HOORAY,2018-12-03T21:33:46Z,killercup,NA https://github.com/rust-lang/rust/pull/56455,MERGED,2018-12-03T13:45:10Z,2018-12-03T21:07:55Z,Stable 1.31.0 release,Mark-Simulacrum,5a31783c6c06e396bc93e3ff48bfbfd343900a92,1,Stable 1.31.0 release,HOORAY,2018-12-03T22:51:02Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/56462,MERGED,2018-12-03T15:23:59Z,2019-03-19T00:48:07Z,Define queries using a proc macro,Zoxc,198dfceb80e62dfe62f5f3fdbedcd9ffbe25c93b,1,Preprocess query modifiers,THUMBS_UP,2018-12-03T15:52:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56462,MERGED,2018-12-03T15:23:59Z,2019-03-19T00:48:07Z,Define queries using a proc macro,Zoxc,198dfceb80e62dfe62f5f3fdbedcd9ffbe25c93b,1,Preprocess query modifiers,HOORAY,2018-12-03T15:52:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56462,MERGED,2018-12-03T15:23:59Z,2019-03-19T00:48:07Z,Define queries using a proc macro,Zoxc,198dfceb80e62dfe62f5f3fdbedcd9ffbe25c93b,1,Preprocess query modifiers,HOORAY,2018-12-03T18:10:24Z,estebank,NA https://github.com/rust-lang/rust/pull/56462,MERGED,2018-12-03T15:23:59Z,2019-03-19T00:48:07Z,Define queries using a proc macro,Zoxc,198dfceb80e62dfe62f5f3fdbedcd9ffbe25c93b,1,Preprocess query modifiers,HOORAY,2018-12-03T19:10:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56462,MERGED,2018-12-03T15:23:59Z,2019-03-19T00:48:07Z,Define queries using a proc macro,Zoxc,198dfceb80e62dfe62f5f3fdbedcd9ffbe25c93b,1,Preprocess query modifiers,HOORAY,2019-02-17T15:56:28Z,mati865,NA https://github.com/rust-lang/rust/pull/56465,CLOSED,2018-12-03T16:34:55Z,2018-12-03T19:02:34Z,Add Result::map_into and Result::map_err_into,PvdBerg1998,NA,NA,NA,CONFUSED,2018-12-03T17:36:07Z,kennytm,NA https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2018-12-03T18:39:46Z,bluss,NA https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2018-12-10T17:52:45Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-01T09:49:37Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-19T15:48:19Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-27T15:05:37Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-28T05:07:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-28T11:05:44Z,elegaanz,NA https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-02-28T11:06:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-04-08T20:15:21Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/56470,MERGED,2018-12-03T17:25:17Z,2019-02-20T12:59:36Z,Modify doctest's auto-`fn main()` to allow `Result`s,llogiq,dad211ef9fdcef5328813a1907d323303f09fc6c,3,Modify doctest's auto-`fn main()` to allow `Result`s This lets the default `fn main()` unwrap any `Result`s which allows the use of `?` in most tests without adding it manually.,HOORAY,2019-04-11T23:16:06Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/56481,MERGED,2018-12-03T21:25:45Z,2018-12-18T09:22:47Z,add coherence future-compat warnings for marker-only trait objects,arielb1,f934cfc40c253415ab6d4a9ac232fc99a21764db,1,fix english,HEART,2018-12-03T21:46:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56481,MERGED,2018-12-03T21:25:45Z,2018-12-18T09:22:47Z,add coherence future-compat warnings for marker-only trait objects,arielb1,f934cfc40c253415ab6d4a9ac232fc99a21764db,1,fix english,THUMBS_UP,2018-12-03T21:54:58Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56481,MERGED,2018-12-03T21:25:45Z,2018-12-18T09:22:47Z,add coherence future-compat warnings for marker-only trait objects,arielb1,f934cfc40c253415ab6d4a9ac232fc99a21764db,1,fix english,THUMBS_UP,2018-12-04T01:09:27Z,qnighy,NA https://github.com/rust-lang/rust/pull/56481,MERGED,2018-12-03T21:25:45Z,2018-12-18T09:22:47Z,add coherence future-compat warnings for marker-only trait objects,arielb1,f934cfc40c253415ab6d4a9ac232fc99a21764db,1,fix english,THUMBS_UP,2018-12-05T07:28:58Z,scalexm,alexandre@scalexm.fr https://github.com/rust-lang/rust/pull/56486,MERGED,2018-12-03T23:19:37Z,2018-12-04T23:26:32Z,Propagate all closure requirements to the caller,matthewjasper,b2e6da7a7f8e3a82a48b0e3d6cb7912d2e31e758,1,Call methods on the right tcx There are two `TyCtxt`s one global one local. Methods must be called on the right one as they differ by invariant lifetimes.,THUMBS_UP,2018-12-04T20:25:29Z,lqd,NA https://github.com/rust-lang/rust/pull/56491,MERGED,2018-12-04T02:07:45Z,2018-12-11T00:05:55Z,emit error with span for empty asserts,euclio,a367cec6e355a0b17d611acba5577ee72c228971,3,emit error with span for empty asserts Fixes #55547.,HEART,2018-12-04T02:14:01Z,estebank,NA https://github.com/rust-lang/rust/pull/56491,MERGED,2018-12-04T02:07:45Z,2018-12-11T00:05:55Z,emit error with span for empty asserts,euclio,a367cec6e355a0b17d611acba5577ee72c228971,3,emit error with span for empty asserts Fixes #55547.,HEART,2019-02-28T12:50:24Z,joIivier,olivier.jolit@pianoctal.com https://github.com/rust-lang/rust/pull/56498,MERGED,2018-12-04T10:35:17Z,2018-12-06T01:37:18Z,Fix line numbers display,GuillaumeGomez,e41e85cb5ca7f37eb8b1615a724ab016721d4237,1,Fix line numbers display,HOORAY,2018-12-12T12:03:45Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/56498,MERGED,2018-12-04T10:35:17Z,2018-12-06T01:37:18Z,Fix line numbers display,GuillaumeGomez,e41e85cb5ca7f37eb8b1615a724ab016721d4237,1,Fix line numbers display,HOORAY,2018-12-13T06:01:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56502,MERGED,2018-12-04T12:48:09Z,2018-12-07T22:22:53Z,Use a function to access the Hir map to be able to turn it into a query later,Zoxc,a70babed03d58d042024e41f0a46f7e33e34d0d1,160,Use a function to access the Hir map to be able to turn it into a query later,HEART,2018-12-04T14:54:04Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T16:11:41Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T16:28:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T16:46:18Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T16:58:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T17:57:27Z,estebank,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T18:45:49Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,THUMBS_UP,2018-12-04T18:45:56Z,nrc,nrc@ncameron.org https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T19:59:03Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-04T20:00:50Z,killercup,NA https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2018-12-07T00:49:00Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,THUMBS_UP,2018-12-12T21:08:00Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/56511,CLOSED,2018-12-04T16:06:31Z,2018-12-14T22:18:59Z,[WIP] Move from rustc_serialize::json to serde_json.,eddyb,NA,NA,NA,HOORAY,2019-02-03T07:11:00Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-05T02:57:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-05T14:20:11Z,kennytm,NA https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-06T00:22:55Z,killercup,NA https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-06T14:21:41Z,z64,zachnowicki@gmail.com https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-06T19:06:57Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-07T02:59:02Z,estebank,NA https://github.com/rust-lang/rust/pull/56516,MERGED,2018-12-04T19:18:54Z,2018-12-07T11:05:51Z,Replace usages of `..i + 1` ranges with `..=i`.,frewsxcv,c025d6140999e07ddf0294f0676c64ff2322a210,19,Replace usages of `..i + 1` ranges with `..=i`.,LAUGH,2018-12-11T12:31:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56534,MERGED,2018-12-05T13:47:27Z,2018-12-26T22:19:50Z,Add unstable Iterator::copied(),xfix,315401ddf8857c9431a889ac1307dca856e4fe65,2,Add a tracking issue for Iterator::copied,THUMBS_UP,2019-12-22T13:57:43Z,OnlyLys,NA https://github.com/rust-lang/rust/pull/56541,CLOSED,2018-12-05T17:49:09Z,2018-12-06T18:24:55Z,Fix ItemKind::TraitAlias encoding,dlrobertson,NA,NA,NA,THUMBS_UP,2018-12-06T17:40:55Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/56559,CLOSED,2018-12-06T11:50:28Z,2019-01-29T20:18:22Z,Add more rust_private attributes,ljedrz,NA,NA,NA,HEART,2018-12-06T15:04:25Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56563,CLOSED,2018-12-06T14:40:25Z,2019-02-03T22:38:35Z, Override ::try_(r)fold ,sinkuu,NA,NA,NA,THUMBS_UP,2018-12-06T17:34:05Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/56563,CLOSED,2018-12-06T14:40:25Z,2019-02-03T22:38:35Z, Override ::try_(r)fold ,sinkuu,NA,NA,NA,THUMBS_UP,2018-12-07T04:45:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/56563,CLOSED,2018-12-06T14:40:25Z,2019-02-03T22:38:35Z, Override ::try_(r)fold ,sinkuu,NA,NA,NA,THUMBS_UP,2018-12-07T10:07:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2018-12-06T20:17:19Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2018-12-07T06:14:53Z,pitdicker,NA https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2018-12-07T14:32:00Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,HEART,2018-12-11T19:46:57Z,estebank,NA https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2019-02-28T22:25:39Z,olson-sean-k,olson.sean.k@gmail.com https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2019-03-01T05:09:52Z,autozimu,autozimu@gmail.com https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,THUMBS_UP,2019-03-01T08:54:57Z,nicklauri,NA https://github.com/rust-lang/rust/pull/56568,MERGED,2018-12-06T18:32:36Z,2018-12-14T16:15:34Z,Remove dependency on shell32.dll,notriddle,83fe6e4392b2b89005f3056cf56a382887c939d5,1,Use iterators instead of raw offsets in Windows argument parser,HEART,2019-03-01T08:55:00Z,nicklauri,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-07T15:49:34Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-07T16:22:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-08T13:30:32Z,killercup,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-08T16:01:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-09T18:19:04Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-09T19:59:41Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2018-12-17T12:32:40Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2019-04-28T10:19:10Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/56595,MERGED,2018-12-07T14:48:22Z,2019-05-26T01:31:31Z,Add clippy and fix commands to x.py,ljedrz,2f3533b7582c735969e9e2aa32d5845d3b565350,5,Add clippy and fix commands to x.py,HOORAY,2019-05-30T05:39:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56601,MERGED,2018-12-07T15:44:07Z,2018-12-19T17:41:21Z,Make the 'a lifetime on TyCtxt useless,Zoxc,d0190d348b4840e6a3e9632fae7453ee77d5a15a,2,Some changes,HOORAY,2018-12-08T13:43:48Z,bjorn3,NA https://github.com/rust-lang/rust/pull/56601,MERGED,2018-12-07T15:44:07Z,2018-12-19T17:41:21Z,Make the 'a lifetime on TyCtxt useless,Zoxc,d0190d348b4840e6a3e9632fae7453ee77d5a15a,2,Some changes,LAUGH,2018-12-10T14:31:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/56601,MERGED,2018-12-07T15:44:07Z,2018-12-19T17:41:21Z,Make the 'a lifetime on TyCtxt useless,Zoxc,d0190d348b4840e6a3e9632fae7453ee77d5a15a,2,Some changes,HOORAY,2018-12-26T18:01:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56619,CLOSED,2018-12-08T01:19:55Z,2018-12-18T03:37:36Z,Add (failing) test to check order of repr(int) enum fields,petertodd,NA,NA,NA,THUMBS_UP,2018-12-17T17:03:52Z,RCasatta,NA https://github.com/rust-lang/rust/pull/56620,MERGED,2018-12-08T01:25:07Z,2018-12-08T12:20:47Z,resolve: Reduce some clutter in import ambiguity errors,petrochenkov,2010b4f60b6fd2d3b54e7aeef329bcb7f92aec76,3,resolve: Reduce some clutter in import ambiguity errors,THUMBS_UP,2018-12-08T01:32:00Z,estebank,NA https://github.com/rust-lang/rust/pull/56621,MERGED,2018-12-08T04:26:49Z,2018-12-08T12:20:47Z,Add missing comma in Generators,Morganamilo,2fc33f9b9771eb2fd84e3dbae02b772ec01fd57e,1,Add missing comma in Generators,THUMBS_UP,2021-08-29T13:33:23Z,Gremious,gremious@gremy.co.uk https://github.com/rust-lang/rust/pull/56636,CLOSED,2018-12-08T17:54:04Z,2019-03-30T15:00:37Z,Refactor rustc_codegen_ssa (part 2),bjorn3,NA,NA,NA,HEART,2019-02-09T16:59:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56636,CLOSED,2018-12-08T17:54:04Z,2019-03-30T15:00:37Z,Refactor rustc_codegen_ssa (part 2),bjorn3,NA,NA,NA,HEART,2019-03-16T05:54:04Z,panaman67,NA https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,THUMBS_UP,2018-12-09T17:02:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,THUMBS_UP,2018-12-10T05:37:18Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,HOORAY,2018-12-10T05:37:58Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,THUMBS_UP,2018-12-10T09:34:22Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,THUMBS_UP,2018-12-11T02:08:07Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,HOORAY,2018-12-11T20:26:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,THUMBS_UP,2018-12-19T18:57:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56642,MERGED,2018-12-09T10:34:32Z,2018-12-17T06:34:19Z,Bump minimum required LLVM version to 6.0,nikic,6c2d704950a5f05b8ee5468df53d8db9b94e2028,3,Remove env_alloca hack This is no longer necessary for LLVM >= 6.,HOORAY,2019-01-09T02:42:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56645,MERGED,2018-12-09T14:54:59Z,2019-02-11T13:15:14Z,Initial implementation of rustfixable unused_imports lint,pietroalbini,5ef71508fec1e2f89b257f6b6b65e5ca3295d658,13,unused_imports: update tests,HOORAY,2019-02-10T15:50:21Z,dwijnand,dale.wijnand@gmail.com https://github.com/rust-lang/rust/pull/56645,MERGED,2018-12-09T14:54:59Z,2019-02-11T13:15:14Z,Initial implementation of rustfixable unused_imports lint,pietroalbini,5ef71508fec1e2f89b257f6b6b65e5ca3295d658,13,unused_imports: update tests,HOORAY,2019-02-13T21:10:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56645,MERGED,2018-12-09T14:54:59Z,2019-02-11T13:15:14Z,Initial implementation of rustfixable unused_imports lint,pietroalbini,5ef71508fec1e2f89b257f6b6b65e5ca3295d658,13,unused_imports: update tests,HOORAY,2019-02-14T06:07:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56645,MERGED,2018-12-09T14:54:59Z,2019-02-11T13:15:14Z,Initial implementation of rustfixable unused_imports lint,pietroalbini,5ef71508fec1e2f89b257f6b6b65e5ca3295d658,13,unused_imports: update tests,HOORAY,2019-08-26T15:23:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/56655,CLOSED,2018-12-09T20:49:16Z,2020-07-17T10:37:46Z,rustc: remove unnecessary extern_prelude logic from ty::item_path.,eddyb,NA,NA,NA,THUMBS_UP,2018-12-09T20:51:01Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/56658,MERGED,2018-12-09T23:05:37Z,2018-12-14T18:35:59Z,Add non-panicking `maybe_new_parser_from_file` variant,Xanewok,85b50d03120cf7bd1beb472a78ce9427c0d8d06e,1,Add missing non-panicking `maybe_new_parser_from_file` variant,HEART,2018-12-11T19:36:56Z,estebank,NA https://github.com/rust-lang/rust/pull/56662,CLOSED,2018-12-10T03:56:10Z,2018-12-11T00:42:46Z,Use `NonZeroU32` instead of `u32` within `Symbol`.,nnethercote,NA,NA,NA,THUMBS_UP,2018-12-10T08:02:08Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/56662,CLOSED,2018-12-10T03:56:10Z,2018-12-11T00:42:46Z,Use `NonZeroU32` instead of `u32` within `Symbol`.,nnethercote,NA,NA,NA,THUMBS_UP,2018-12-10T18:12:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56677,MERGED,2018-12-10T14:49:38Z,2018-12-15T19:11:49Z,#[must_use] on traits in stdlib,aelred,3246f495d0c52549ca2f3722a915360518f0c062,1,Add trailing newline,THUMBS_UP,2018-12-10T20:41:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56677,MERGED,2018-12-10T14:49:38Z,2018-12-15T19:11:49Z,#[must_use] on traits in stdlib,aelred,3246f495d0c52549ca2f3722a915360518f0c062,1,Add trailing newline,THUMBS_UP,2018-12-19T18:57:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56679,MERGED,2018-12-10T17:16:06Z,2018-12-15T19:11:50Z,overhaul external doc attribute diagnostics,euclio,7f7045f84795a7e1c1fb0a0160bf3319368c09ba,4,improve diagnostics for invalid external docs,HEART,2018-12-11T19:40:32Z,estebank,NA https://github.com/rust-lang/rust/pull/56679,MERGED,2018-12-10T17:16:06Z,2018-12-15T19:11:50Z,overhaul external doc attribute diagnostics,euclio,7f7045f84795a7e1c1fb0a0160bf3319368c09ba,4,improve diagnostics for invalid external docs,HEART,2018-12-15T10:28:56Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/56698,CLOSED,2018-12-11T00:05:40Z,2019-01-07T18:47:49Z,Fix the UB recommended in the wrapping_offset docs,strega-nil,NA,NA,NA,THUMBS_UP,2018-12-11T11:38:17Z,Enet4,NA https://github.com/rust-lang/rust/pull/56699,MERGED,2018-12-11T00:42:22Z,2018-12-14T18:36:01Z,Use a `newtype_index!` within `Symbol`.,nnethercote,0f68749260d04b61dfe2b38dbc423aefe2914a58,3,Use a `newtype_index!` within `Symbol`. This shrinks `Option` from 8 bytes to 4 bytes which shrinks `Token` from 24 bytes to 16 bytes. This reduces instruction counts by up to 1% across a range of benchmarks.,THUMBS_UP,2018-12-11T02:53:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56703,MERGED,2018-12-11T03:35:36Z,2018-12-11T10:34:39Z,Fix build of the `build-manifest` tool,alexcrichton,ddd8b416a6bfa009db997e4e8724fa0069a850dc,1,Build manifest tool on mingw-check builder This builder is not really the correct place to put this but it definitely has the time budget and checking this tool builds on just one platform is more than sufficient.,THUMBS_UP,2018-12-11T09:01:28Z,Enet4,NA https://github.com/rust-lang/rust/pull/56703,MERGED,2018-12-11T03:35:36Z,2018-12-11T10:34:39Z,Fix build of the `build-manifest` tool,alexcrichton,ddd8b416a6bfa009db997e4e8724fa0069a850dc,1,Build manifest tool on mingw-check builder This builder is not really the correct place to put this but it definitely has the time budget and checking this tool builds on just one platform is more than sufficient.,THUMBS_UP,2019-01-02T00:51:49Z,steakknife,NA https://github.com/rust-lang/rust/pull/56713,MERGED,2018-12-11T14:09:37Z,2018-12-15T19:11:52Z,Test capacity of ZST vector,xfix,1006425769ada70d0f394ccdab3caecaf6fa3e77,1,Test capacity of ZST vector Initially #50233 accidentally changed the capacity of empty ZST. This was pointed out during code review. This commit adds a test to prevent capacity of ZST vectors from accidentally changing to prevent that from happening again.,HEART,2018-12-15T03:58:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-01-21T10:29:01Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-01-22T08:30:12Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-01-22T09:57:51Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-02-01T22:35:15Z,mati865,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-02-02T02:33:34Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-02-05T00:50:23Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-02-08T23:09:56Z,hcpl,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-02-19T11:18:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-13T20:41:09Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-13T22:47:19Z,frol,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-14T01:14:15Z,arbitrix,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-14T06:13:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-14T13:37:28Z,icefoxen,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-14T16:21:18Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-15T16:37:09Z,chrish42,NA https://github.com/rust-lang/rust/pull/56732,MERGED,2018-12-12T01:11:01Z,2019-03-10T09:24:59Z,Make the rustc driver and interface demand driven,Zoxc,51938c61f6f1b26e463f9071716f543543486e72,60,Make the rustc driver and interface demand driven,HEART,2019-03-15T16:56:26Z,maksimsco,NA https://github.com/rust-lang/rust/pull/56739,CLOSED,2018-12-12T06:25:57Z,2018-12-28T12:17:16Z,Make the getter for NonZero types into a const fn,Lokathor,NA,NA,NA,THUMBS_UP,2018-12-15T03:59:23Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56748,MERGED,2018-12-12T16:05:31Z,2018-12-14T18:36:06Z,Update panic message to be clearer about env-vars,kinnison,6057147fde962f2369c61f8dbf74dd2b1b2ce239,4,Update panic message to be clearer about env-vars Esteban Kuber requested that the panic message make it clear that `RUST_BACKTRACE=1` is an environment variable. This change makes that clear. Wording provided in part by David Tolnay.,THUMBS_UP,2018-12-13T19:19:20Z,estebank,NA https://github.com/rust-lang/rust/pull/56755,MERGED,2018-12-12T21:59:04Z,2018-12-15T13:46:27Z,Account for `impl Trait` when suggesting lifetime,estebank,b9235ea57c460ef4c2f2b963d85f3040c7e09398,4,Account for `impl Trait` when suggesting lifetime,THUMBS_UP,2018-12-15T13:49:39Z,bjorn3,NA https://github.com/rust-lang/rust/pull/56758,MERGED,2018-12-12T22:44:26Z,2018-12-15T13:46:27Z,Add short emoji status to toolstate updates,Manishearth,ae893bb9aba27a8dd09cf7ee5fff5cc69c8d2acf,1,Add short emoji status to toolstate updates,HEART,2018-12-13T08:10:11Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56759,MERGED,2018-12-12T23:48:04Z,2019-01-12T23:00:19Z,Stabilize `uniform_paths`,petrochenkov,250935d0c7c23b4d80703f5b660a92d6591d8649,7,Fix a hole in generic parameter import future-proofing Add some tests for buggy derive helpers,THUMBS_UP,2019-01-13T01:56:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/56759,MERGED,2018-12-12T23:48:04Z,2019-01-12T23:00:19Z,Stabilize `uniform_paths`,petrochenkov,250935d0c7c23b4d80703f5b660a92d6591d8649,7,Fix a hole in generic parameter import future-proofing Add some tests for buggy derive helpers,THUMBS_UP,2021-07-07T02:06:31Z,dope2684,NA https://github.com/rust-lang/rust/pull/56764,MERGED,2018-12-13T02:59:30Z,2018-12-17T08:54:34Z,mir-opt: Make SimplifyCfg collapse goto chains starting from bb0,sinkuu,83298a212076e74808198f46bb98467d2cb41ac9,2,Make SimplifyCfg collapse goto chains from bb0,HEART,2018-12-15T04:00:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56764,MERGED,2018-12-13T02:59:30Z,2018-12-17T08:54:34Z,mir-opt: Make SimplifyCfg collapse goto chains starting from bb0,sinkuu,83298a212076e74808198f46bb98467d2cb41ac9,2,Make SimplifyCfg collapse goto chains from bb0,HEART,2018-12-17T16:22:22Z,bluss,NA https://github.com/rust-lang/rust/pull/56764,MERGED,2018-12-13T02:59:30Z,2018-12-17T08:54:34Z,mir-opt: Make SimplifyCfg collapse goto chains starting from bb0,sinkuu,83298a212076e74808198f46bb98467d2cb41ac9,2,Make SimplifyCfg collapse goto chains from bb0,HEART,2018-12-26T17:59:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2018-12-14T01:04:18Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2018-12-14T01:23:21Z,icefoxen,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-01-25T23:46:08Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-01T00:09:21Z,insomniacslk,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-06T10:12:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-07T22:47:18Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-24T23:50:18Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-25T18:12:16Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-25T19:05:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-26T20:37:20Z,Bckempa,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-02-28T17:34:11Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2019-03-02T20:45:25Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,THUMBS_UP,2019-06-26T22:18:00Z,edigaryev,edigaryev@gmail.com https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,THUMBS_UP,2019-07-07T22:32:21Z,JonahPlusPlus,NA https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,HEART,2020-09-20T07:38:06Z,alishir,alishirv@pm.me https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,THUMBS_UP,2020-09-20T07:38:07Z,alishir,alishirv@pm.me https://github.com/rust-lang/rust/pull/56769,MERGED,2018-12-13T09:25:24Z,2018-12-15T13:46:29Z,Add x86_64-unknown-uefi target,dvdhrm,88cf2a23e24cdbf7a134d14185c1e5b69ffd07c3,3,Add x86_64-unknown-uefi target This adds a new rustc target-configuration called 'x86_64-unknown_uefi'. Furthermore it adds a UEFI base-configuration to be used with other targets supported by UEFI (e.g. i386 armv7hl aarch64 itanium ...). UEFI systems provide a very basic operating-system environment meant to unify how systems are booted. It is tailored for simplicity and fast setup as it is only meant to bootstrap other systems. For instance it copies most of the ABI from Microsoft Windows rather than inventing anything on its own. Furthermore any complex CPU features are disabled. Only one CPU is allowed to be up no interrupts other than the timer-interrupt are allowed no process-separation is performed page-tables are identity-mapped ... Nevertheless UEFI has an application model. Its main purpose is to allow operating-system vendors to write small UEFI applications that load their kernel and terminate the UEFI system. However many other UEFI applications have emerged in the past including network-boot debug-consoles and more. This UEFI target allows to compile rust code natively as UEFI applications. No standard library support is added but libcore can be used out-of-the-box if a panic-handler is provided. Furthermore liballoc works as well if a `GlobalAlloc` handler is provided. Both have been tested with this target-configuration. Note that full libstd support is unlikely to happen. While UEFI does have standardized interfaces for networking and alike none of these are mandatory and they are unlikely to be shipped in common consumer firmwares. Furthermore several features like process-separation are not available (or only in very limited fashion). Those parts of libstd would have to be masked.,THUMBS_UP,2021-06-23T06:07:15Z,Himself65,himself65@outlook.com https://github.com/rust-lang/rust/pull/56781,MERGED,2018-12-13T15:39:00Z,2018-12-16T23:23:27Z,Update LLVM submodule,nikic,1d8a3a03b91fea0fdc2f236a7f864bb0c365cdb8,2,Update LLVM submodule,THUMBS_UP,2018-12-13T21:12:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56796,MERGED,2018-12-13T21:57:19Z,2019-01-21T11:07:43Z,Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`,RustyYato,ea68b3ff3dd5a49c5984c476570fb5404c342079,1,update to reflect changes recommended by @shepmaster his review,HEART,2018-12-18T10:12:02Z,regexident,NA https://github.com/rust-lang/rust/pull/56796,MERGED,2018-12-13T21:57:19Z,2019-01-21T11:07:43Z,Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`,RustyYato,ea68b3ff3dd5a49c5984c476570fb5404c342079,1,update to reflect changes recommended by @shepmaster his review,HEART,2018-12-18T18:28:59Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/56796,MERGED,2018-12-13T21:57:19Z,2019-01-21T11:07:43Z,Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`,RustyYato,ea68b3ff3dd5a49c5984c476570fb5404c342079,1,update to reflect changes recommended by @shepmaster his review,HEART,2018-12-21T02:33:30Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/56796,MERGED,2018-12-13T21:57:19Z,2019-01-21T11:07:43Z,Change bounds on `TryFrom` blanket impl to use `Into` instead of `From`,RustyYato,ea68b3ff3dd5a49c5984c476570fb5404c342079,1,update to reflect changes recommended by @shepmaster his review,HEART,2019-01-23T09:39:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56802,MERGED,2018-12-14T04:28:26Z,2018-12-23T01:51:15Z,Add DoubleEndedIterator::nth_back,clarfonthey,fb18ddaaaa8eeec29bf6fc8684cfceccaa09e064,4,Add DoubleEndedIterator::nth_back,HEART,2018-12-26T16:57:38Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/56802,MERGED,2018-12-14T04:28:26Z,2018-12-23T01:51:15Z,Add DoubleEndedIterator::nth_back,clarfonthey,fb18ddaaaa8eeec29bf6fc8684cfceccaa09e064,4,Add DoubleEndedIterator::nth_back,HEART,2018-12-26T18:05:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-14T19:33:26Z,cramertj,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HEART,2018-12-14T19:33:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HOORAY,2018-12-14T19:33:30Z,cramertj,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-14T21:07:30Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-15T02:52:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HOORAY,2018-12-16T09:02:45Z,bluss,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-26T17:06:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-26T18:05:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HOORAY,2018-12-26T18:41:46Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-28T12:37:48Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2018-12-30T07:44:03Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HOORAY,2018-12-30T07:44:05Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HEART,2018-12-30T07:44:05Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2019-01-05T14:23:36Z,tux3,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2019-03-01T08:40:01Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2019-03-01T20:06:23Z,nwn,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2020-01-09T14:11:39Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",THUMBS_UP,2021-05-18T13:48:05Z,ahlinc,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HEART,2021-05-18T13:48:07Z,ahlinc,NA https://github.com/rust-lang/rust/pull/56805,MERGED,2018-12-14T06:05:24Z,2018-12-22T04:21:38Z,Stabilize `Rc` `Arc` and `Pin` as method receivers,mikeyhew,286503ace2fd1fc8ac8bf8aa10378fb93763d99f,5,"Refactor and add comments to code in receiver_is_valid also updated some error messages removed the code manually checking for `receiver_ty: Deref` in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before a ""mismatched method receiver"" error would be emitted when `receiver_ty` was valid except for a lifetime parameter but only when `feature(arbitrary_self_types)` was enabled and without the feature flag the error would be ""uncoercible receiver"". Now it emits ""mismatched method receiver"" in both cases.",HOORAY,2021-05-18T13:48:08Z,ahlinc,NA https://github.com/rust-lang/rust/pull/56810,MERGED,2018-12-14T10:11:11Z,2018-12-17T16:02:12Z,Improve MIR match generation for ranges,sinkuu,d66a55e4de9604c5e4f56c0756a747990ae0bc4b,1,tidy,HEART,2018-12-15T12:22:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56810,MERGED,2018-12-14T10:11:11Z,2018-12-17T16:02:12Z,Improve MIR match generation for ranges,sinkuu,d66a55e4de9604c5e4f56c0756a747990ae0bc4b,1,tidy,HEART,2018-12-19T18:56:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56813,MERGED,2018-12-14T12:12:36Z,2018-12-21T13:35:38Z,Always run rustc in a thread,oli-obk,6b96827ae971cec1f1bf83245d8356481e76b644,8,Remove dead code,THUMBS_UP,2018-12-26T18:05:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56827,MERGED,2018-12-14T21:37:11Z,2019-01-02T04:39:59Z,Eliminate Receiver::recv_timeout panic,faern,496f547af604f5430ab6fbb3ce78ef0ea79a6ae8,1,Add documentation about panicking Add impls,THUMBS_UP,2019-01-09T21:01:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56827,MERGED,2018-12-14T21:37:11Z,2019-01-02T04:39:59Z,Eliminate Receiver::recv_timeout panic,faern,496f547af604f5430ab6fbb3ce78ef0ea79a6ae8,1,Add documentation about panicking Add impls,THUMBS_UP,2019-01-09T22:13:22Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56841,MERGED,2018-12-15T10:02:54Z,2018-12-15T19:11:57Z,Add some unit tests to compiletest,phansch,9637c27fb531dc4a030bc978ebff4335baebc28d,1,compiletest: unit test parse_normalization_string There is a FIXME inside that function and I think the unit tests can be helpful to resolve it without breaking anything else.,HEART,2018-12-15T10:12:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/56844,MERGED,2018-12-15T11:42:39Z,2018-12-16T23:23:33Z,Improve CSS rule,GuillaumeGomez,122684d3934a2a51b53a65c281cfad0c7663dda1,1,Improve CSS rule,THUMBS_UP,2018-12-16T00:23:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HOORAY,2018-12-16T12:00:54Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HOORAY,2018-12-17T18:17:13Z,cramertj,NA https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HEART,2019-03-09T10:43:35Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HOORAY,2019-03-11T17:18:52Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HEART,2019-03-11T19:37:26Z,estebank,NA https://github.com/rust-lang/rust/pull/56864,MERGED,2018-12-15T23:07:45Z,2019-03-13T14:58:54Z,Use derive macro for HashStable,Zoxc,bc3a84a7f33d8652cbf53c0877731265e3ecc1bc,1,Add missing project attributes,HEART,2019-03-13T02:44:47Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2018-12-16T07:37:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2018-12-16T08:37:47Z,bluss,NA https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2018-12-16T13:48:03Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2018-12-16T23:50:56Z,killercup,NA https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2018-12-18T21:59:58Z,onur,onur@onur.im https://github.com/rust-lang/rust/pull/56869,MERGED,2018-12-16T01:36:45Z,2019-01-17T05:00:25Z,Reduce search-index.js size,GuillaumeGomez,d405606c3bc499d215ff0bcb6a56080ff4bf07d4,4,End fixing search index minification,HEART,2019-01-10T14:58:53Z,linkmauve,linkmauve@linkmauve.fr https://github.com/rust-lang/rust/pull/56874,MERGED,2018-12-16T10:57:56Z,2019-01-14T00:59:49Z,Simplify foreign type rendering.,JohnHeitmann,34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9,19,Simplify foreign type rendering. Simplified foreign type rendering by switching from tables to flexbox. Also removed some seemingly extraneous elements like “ghost” spans. Reduces element count on std::iter::Iterator by 30%.,HEART,2018-12-20T16:15:32Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/56876,MERGED,2018-12-16T13:45:44Z,2018-12-16T20:58:36Z,Fix js errors,GuillaumeGomez,fa9c8232d74be77a0f214b7e650acad43994dbbe,2,Fix invalid JS file generation,HEART,2018-12-16T13:47:32Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/56917,MERGED,2018-12-17T13:32:16Z,2018-12-24T10:04:24Z,Simplify MIR generation for logical operations,sinkuu,e38e954a0d249f88d0a55504f70d6055e865a931,1,Simplify MIR generation for logical ops,HEART,2018-12-20T02:45:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56917,MERGED,2018-12-17T13:32:16Z,2018-12-24T10:04:24Z,Simplify MIR generation for logical operations,sinkuu,e38e954a0d249f88d0a55504f70d6055e865a931,1,Simplify MIR generation for logical ops,HEART,2018-12-26T18:02:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56917,MERGED,2018-12-17T13:32:16Z,2018-12-24T10:04:24Z,Simplify MIR generation for logical operations,sinkuu,e38e954a0d249f88d0a55504f70d6055e865a931,1,Simplify MIR generation for logical ops,HEART,2018-12-30T10:57:19Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/56932,MERGED,2018-12-17T22:12:00Z,2019-01-27T23:27:02Z,Refactor core::iter module,clarfonthey,02bda7a0617fd0d0d3ac11dffb17ffba8c0f0601,2,Move trivial constructors to inherent methods,HEART,2018-12-27T10:43:55Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/56932,MERGED,2018-12-17T22:12:00Z,2019-01-27T23:27:02Z,Refactor core::iter module,clarfonthey,02bda7a0617fd0d0d3ac11dffb17ffba8c0f0601,2,Move trivial constructors to inherent methods,HEART,2019-01-09T01:14:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/56932,MERGED,2018-12-17T22:12:00Z,2019-01-27T23:27:02Z,Refactor core::iter module,clarfonthey,02bda7a0617fd0d0d3ac11dffb17ffba8c0f0601,2,Move trivial constructors to inherent methods,HEART,2019-01-23T05:48:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/56932,MERGED,2018-12-17T22:12:00Z,2019-01-27T23:27:02Z,Refactor core::iter module,clarfonthey,02bda7a0617fd0d0d3ac11dffb17ffba8c0f0601,2,Move trivial constructors to inherent methods,HEART,2019-01-27T20:02:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56932,MERGED,2018-12-17T22:12:00Z,2019-01-27T23:27:02Z,Refactor core::iter module,clarfonthey,02bda7a0617fd0d0d3ac11dffb17ffba8c0f0601,2,Move trivial constructors to inherent methods,HEART,2019-01-28T07:50:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/56933,MERGED,2018-12-17T22:17:57Z,2018-12-23T01:51:21Z,Add --progress to git submodule commands in x.py,clarfonthey,6130fc884bc1dff9bb835894a7bb2042c110b011,1,Add --progress to git submodule commands,THUMBS_UP,2018-12-18T06:23:36Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-18T02:28:14Z,sinkuu,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-18T03:46:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-18T10:01:22Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-18T15:26:51Z,tux3,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-18T18:15:40Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-21T13:59:12Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-22T05:08:24Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-23T19:22:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-25T15:05:04Z,uonr,me@yuru.me https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-26T17:09:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-26T18:48:06Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-27T00:25:00Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-27T01:42:59Z,hcpl,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-27T16:26:08Z,davidbarsky,me@davidbarsky.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-28T15:54:15Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-29T08:22:21Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56939,MERGED,2018-12-18T02:17:48Z,2018-12-24T10:04:25Z,Pin stabilization,cramertj,861df06e077bb17c2d22ab978e37ee2c5350ff9b,1,Fix Unpin docs link,HOORAY,2018-12-30T07:44:11Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/56946,MERGED,2018-12-18T08:07:35Z,2019-03-02T04:39:09Z,Add support for using a jobserver with Rayon,Zoxc,5c78fa836d271e1ae664b9e0be4c5de3cb9e4698,1,Update Cargo.lock,THUMBS_UP,2018-12-19T22:20:04Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56946,MERGED,2018-12-18T08:07:35Z,2019-03-02T04:39:09Z,Add support for using a jobserver with Rayon,Zoxc,5c78fa836d271e1ae664b9e0be4c5de3cb9e4698,1,Update Cargo.lock,THUMBS_UP,2019-03-02T05:28:26Z,taiki-e,NA https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-19T12:25:36Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-19T17:44:39Z,estebank,NA https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-19T22:20:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-24T16:29:34Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-25T09:59:08Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2018-12-30T20:54:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2019-01-02T18:54:22Z,mati865,NA https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2019-02-03T04:49:30Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/56951,MERGED,2018-12-18T12:36:41Z,2019-02-13T16:02:15Z,Automatically open an issue when a tool breaks,oli-obk,6ed4401609817e18a0ff781529e35b2a209ff0da,1,Permit issue posting to have network failures,THUMBS_UP,2019-02-13T18:25:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56983,MERGED,2018-12-19T14:17:28Z,2018-12-25T13:32:53Z,Parallel query tweaks,ljedrz,dfe187d348aa74b47c4caaac112945adfd47456e,1,query: simplify stack trimming in cycle_check,THUMBS_UP,2018-12-19T17:54:14Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/56983,MERGED,2018-12-19T14:17:28Z,2018-12-25T13:32:53Z,Parallel query tweaks,ljedrz,dfe187d348aa74b47c4caaac112945adfd47456e,1,query: simplify stack trimming in cycle_check,THUMBS_UP,2018-12-19T22:22:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56983,MERGED,2018-12-19T14:17:28Z,2018-12-25T13:32:53Z,Parallel query tweaks,ljedrz,dfe187d348aa74b47c4caaac112945adfd47456e,1,query: simplify stack trimming in cycle_check,THUMBS_UP,2019-01-04T06:31:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56986,MERGED,2018-12-19T16:28:34Z,2018-12-24T15:19:12Z,rustc: Move jemalloc from rustc_driver to rustc,alexcrichton,ba0ed5b13f23dd6e4ff0047a653ee615b84a67f2,5,rustc: Move jemalloc from rustc_driver to rustc This commit moves jemalloc to just the rustc binary rather than the rustc_driver shared library enusring that it's only used for binaries that opt-in to it like rustc rather than other binaries using librustc_driver like rustdoc/rls/etc. This will hopefully address #56980,THUMBS_UP,2018-12-20T09:53:59Z,alexheretic,NA https://github.com/rust-lang/rust/pull/56986,MERGED,2018-12-19T16:28:34Z,2018-12-24T15:19:12Z,rustc: Move jemalloc from rustc_driver to rustc,alexcrichton,ba0ed5b13f23dd6e4ff0047a653ee615b84a67f2,5,rustc: Move jemalloc from rustc_driver to rustc This commit moves jemalloc to just the rustc binary rather than the rustc_driver shared library enusring that it's only used for binaries that opt-in to it like rustc rather than other binaries using librustc_driver like rustdoc/rls/etc. This will hopefully address #56980,THUMBS_UP,2019-01-04T06:29:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T17:20:10Z,sfackler,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T17:24:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T17:38:37Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T18:32:26Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T18:39:31Z,malbarbo,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T20:17:22Z,sinkuu,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-19T21:25:16Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-20T04:12:31Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-20T12:15:54Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-20T16:20:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-24T11:29:31Z,retep998,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-26T21:55:06Z,estebank,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2018-12-27T18:54:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2019-01-04T01:39:18Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2019-01-08T13:49:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2019-01-08T13:50:25Z,mati865,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2019-01-09T14:06:47Z,crlf0710,NA https://github.com/rust-lang/rust/pull/56987,CLOSED,2018-12-19T17:13:20Z,2019-01-22T17:01:20Z,rustc: Remove `dylib` crate type from most rustc crates,alexcrichton,NA,NA,NA,HOORAY,2019-11-29T11:37:08Z,kdy1,kdy1997.dev@gmail.com https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,HEART,2018-12-19T18:37:00Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,HEART,2018-12-19T18:37:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,HEART,2018-12-20T14:55:51Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,HEART,2019-01-02T20:20:10Z,estebank,NA https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,THUMBS_UP,2019-01-13T18:02:23Z,CvX,NA https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,THUMBS_UP,2019-01-16T15:56:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,THUMBS_UP,2019-01-18T06:05:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,THUMBS_UP,2019-01-19T16:29:29Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,HEART,2019-01-27T00:28:15Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/56988,MERGED,2018-12-19T18:32:46Z,2019-01-08T14:11:29Z,std: Force `Instant::now()` to be monotonic,alexcrichton,255a3f3e183150e30d411628d5996bd3a183bd6f,7,std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940,THUMBS_UP,2020-11-26T21:49:25Z,bb010g,NA https://github.com/rust-lang/rust/pull/56990,CLOSED,2018-12-19T19:08:33Z,2019-02-04T12:40:00Z,Add gdb to the build,tromey,NA,NA,NA,THUMBS_UP,2018-12-19T22:23:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/56990,CLOSED,2018-12-19T19:08:33Z,2019-02-04T12:40:00Z,Add gdb to the build,tromey,NA,NA,NA,THUMBS_UP,2019-01-11T15:09:52Z,ljedrz,NA https://github.com/rust-lang/rust/pull/56992,MERGED,2018-12-19T20:07:00Z,2018-12-23T01:51:29Z,suggest similar lint names for unknown lints,euclio,90726e1ac17a91d07ca5749ade718239f439d1bd,7,suggest similar lint names for unknown lints,HEART,2018-12-19T20:31:23Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/56992,MERGED,2018-12-19T20:07:00Z,2018-12-23T01:51:29Z,suggest similar lint names for unknown lints,euclio,90726e1ac17a91d07ca5749ade718239f439d1bd,7,suggest similar lint names for unknown lints,HOORAY,2018-12-19T20:58:03Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/56992,MERGED,2018-12-19T20:07:00Z,2018-12-23T01:51:29Z,suggest similar lint names for unknown lints,euclio,90726e1ac17a91d07ca5749ade718239f439d1bd,7,suggest similar lint names for unknown lints,HOORAY,2019-01-16T22:13:04Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/56994,CLOSED,2018-12-19T21:05:55Z,2019-02-11T20:15:51Z,Add TryClone trait,clarfonthey,NA,NA,NA,THUMBS_UP,2018-12-20T20:26:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/56994,CLOSED,2018-12-19T21:05:55Z,2019-02-11T20:15:51Z,Add TryClone trait,clarfonthey,NA,NA,NA,CONFUSED,2018-12-27T16:29:34Z,kennytm,NA https://github.com/rust-lang/rust/pull/56994,CLOSED,2018-12-19T21:05:55Z,2019-02-11T20:15:51Z,Add TryClone trait,clarfonthey,NA,NA,NA,THUMBS_UP,2019-01-17T19:33:35Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/56999,MERGED,2018-12-20T01:01:53Z,2018-12-28T01:00:04Z,AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end,petrochenkov,bc16edeb28e38e5bbed8828fb6314b1cc5151235,33,Fix rebase and more CI failures,HEART,2018-12-20T01:21:18Z,estebank,NA https://github.com/rust-lang/rust/pull/56999,MERGED,2018-12-20T01:01:53Z,2018-12-28T01:00:04Z,AST/HIR: Introduce `ExprKind::Err` for better error recovery in the front-end,petrochenkov,bc16edeb28e38e5bbed8828fb6314b1cc5151235,33,Fix rebase and more CI failures,HEART,2019-01-04T06:27:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57004,MERGED,2018-12-20T09:12:34Z,2019-01-13T19:44:01Z,Make `TokenStream` less recursive.,nnethercote,e80a93040ffbbb7eb8013f1dcd3b594ce8a631cd,7,Make `TokenStream` less recursive. `TokenStream` is currently recursive in *two* ways: - the `TokenTree` variant contains a `ThinTokenStream` which can contain a `TokenStream`; - the `TokenStream` variant contains a `Vec`. The latter is not necessary and causes significant complexity. This commit replaces it with the simpler `Vec<(TokenTree IsJoint)>`. This reduces complexity significantly. In particular `StreamCursor` is eliminated and `Cursor` becomes much simpler consisting now of just a `TokenStream` and an index. The commit also removes the `Extend` impl for `TokenStream` because it is only used in tests. (The commit also removes those tests.) Overall the commit reduces the number of lines of code by almost 200.,HEART,2019-01-08T19:30:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/57004,MERGED,2018-12-20T09:12:34Z,2019-01-13T19:44:01Z,Make `TokenStream` less recursive.,nnethercote,e80a93040ffbbb7eb8013f1dcd3b594ce8a631cd,7,Make `TokenStream` less recursive. `TokenStream` is currently recursive in *two* ways: - the `TokenTree` variant contains a `ThinTokenStream` which can contain a `TokenStream`; - the `TokenStream` variant contains a `Vec`. The latter is not necessary and causes significant complexity. This commit replaces it with the simpler `Vec<(TokenTree IsJoint)>`. This reduces complexity significantly. In particular `StreamCursor` is eliminated and `Cursor` becomes much simpler consisting now of just a `TokenStream` and an index. The commit also removes the `Extend` impl for `TokenStream` because it is only used in tests. (The commit also removes those tests.) Overall the commit reduces the number of lines of code by almost 200.,HEART,2019-01-16T23:59:27Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/57004,MERGED,2018-12-20T09:12:34Z,2019-01-13T19:44:01Z,Make `TokenStream` less recursive.,nnethercote,e80a93040ffbbb7eb8013f1dcd3b594ce8a631cd,7,Make `TokenStream` less recursive. `TokenStream` is currently recursive in *two* ways: - the `TokenTree` variant contains a `ThinTokenStream` which can contain a `TokenStream`; - the `TokenStream` variant contains a `Vec`. The latter is not necessary and causes significant complexity. This commit replaces it with the simpler `Vec<(TokenTree IsJoint)>`. This reduces complexity significantly. In particular `StreamCursor` is eliminated and `Cursor` becomes much simpler consisting now of just a `TokenStream` and an index. The commit also removes the `Extend` impl for `TokenStream` because it is only used in tests. (The commit also removes those tests.) Overall the commit reduces the number of lines of code by almost 200.,HEART,2019-01-17T10:23:30Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57004,MERGED,2018-12-20T09:12:34Z,2019-01-13T19:44:01Z,Make `TokenStream` less recursive.,nnethercote,e80a93040ffbbb7eb8013f1dcd3b594ce8a631cd,7,Make `TokenStream` less recursive. `TokenStream` is currently recursive in *two* ways: - the `TokenTree` variant contains a `ThinTokenStream` which can contain a `TokenStream`; - the `TokenStream` variant contains a `Vec`. The latter is not necessary and causes significant complexity. This commit replaces it with the simpler `Vec<(TokenTree IsJoint)>`. This reduces complexity significantly. In particular `StreamCursor` is eliminated and `Cursor` becomes much simpler consisting now of just a `TokenStream` and an index. The commit also removes the `Extend` impl for `TokenStream` because it is only used in tests. (The commit also removes those tests.) Overall the commit reduces the number of lines of code by almost 200.,HEART,2019-01-18T06:00:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57006,MERGED,2018-12-20T12:30:09Z,2018-12-29T04:13:00Z,Add no-crate filter option on rustdoc,GuillaumeGomez,dbcf68951c564f946ab0021c7699ea1a4bf861d0,9,Add no-crate filter option on rustdoc,HEART,2018-12-20T12:53:49Z,onur,onur@onur.im https://github.com/rust-lang/rust/pull/57018,MERGED,2018-12-20T21:08:07Z,2019-03-20T17:54:31Z,Keep last redundant linker flag not first,dcreager,32d99efa403a5c3ba93d3389110cd9f4226591d2,1,Ignore test on Windows,THUMBS_UP,2018-12-20T22:49:10Z,maxbrunsfeld,maxbrunsfeld@gmail.com https://github.com/rust-lang/rust/pull/57018,MERGED,2018-12-20T21:08:07Z,2019-03-20T17:54:31Z,Keep last redundant linker flag not first,dcreager,32d99efa403a5c3ba93d3389110cd9f4226591d2,1,Ignore test on Windows,THUMBS_UP,2019-02-22T06:01:21Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/57018,MERGED,2018-12-20T21:08:07Z,2019-03-20T17:54:31Z,Keep last redundant linker flag not first,dcreager,32d99efa403a5c3ba93d3389110cd9f4226591d2,1,Ignore test on Windows,THUMBS_UP,2019-03-04T06:51:42Z,ruffsl,roxfoxpox@gmail.com https://github.com/rust-lang/rust/pull/57026,CLOSED,2018-12-21T09:58:37Z,2019-01-07T18:05:33Z,Use the raw API in queries to avoid hashing the query key 3 times,Zoxc,NA,NA,NA,HEART,2018-12-21T10:17:52Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2018-12-24T10:58:43Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2019-01-11T02:35:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2019-01-23T09:45:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',HEART,2019-01-23T15:11:56Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2019-01-23T18:40:43Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2019-01-24T11:48:39Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/57043,MERGED,2018-12-21T14:15:45Z,2019-01-15T01:41:44Z,Fix poor worst case performance of set intersection,ssomers,cef2e2f3d53795787085bf63a6c2a8563e7ba9c9,1,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2020-03-17T22:01:54Z,amadeusine,NA https://github.com/rust-lang/rust/pull/57045,MERGED,2018-12-21T14:53:11Z,2019-01-29T07:52:54Z,Kill remaining uses of mem::uninitialized in libcore liballoc,RalfJung,489a79247ddf5da8090019ff4da4b688ad55afa7,1,fix gdb debug printing,HOORAY,2018-12-21T15:21:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/57045,MERGED,2018-12-21T14:53:11Z,2019-01-29T07:52:54Z,Kill remaining uses of mem::uninitialized in libcore liballoc,RalfJung,489a79247ddf5da8090019ff4da4b688ad55afa7,1,fix gdb debug printing,HOORAY,2018-12-21T18:20:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/57045,MERGED,2018-12-21T14:53:11Z,2019-01-29T07:52:54Z,Kill remaining uses of mem::uninitialized in libcore liballoc,RalfJung,489a79247ddf5da8090019ff4da4b688ad55afa7,1,fix gdb debug printing,HOORAY,2018-12-28T13:21:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57045,MERGED,2018-12-21T14:53:11Z,2019-01-29T07:52:54Z,Kill remaining uses of mem::uninitialized in libcore liballoc,RalfJung,489a79247ddf5da8090019ff4da4b688ad55afa7,1,fix gdb debug printing,HOORAY,2019-01-23T05:56:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/57045,MERGED,2018-12-21T14:53:11Z,2019-01-29T07:52:54Z,Kill remaining uses of mem::uninitialized in libcore liballoc,RalfJung,489a79247ddf5da8090019ff4da4b688ad55afa7,1,fix gdb debug printing,HOORAY,2019-01-29T00:13:06Z,mati865,NA https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HOORAY,2018-12-21T19:37:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HOORAY,2018-12-21T22:02:26Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HEART,2018-12-22T17:03:27Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HEART,2018-12-23T04:12:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HOORAY,2018-12-23T04:34:27Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HOORAY,2018-12-24T22:37:46Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HOORAY,2021-07-27T13:21:27Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/57048,CLOSED,2018-12-21T17:07:43Z,2018-12-25T04:54:47Z,rustc: Rewrite platform intrinsics crate,alexcrichton,NA,NA,NA,HEART,2021-07-27T13:21:29Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/57049,MERGED,2018-12-21T18:19:57Z,2018-12-23T01:51:35Z,Stabilize #[repr(packed(N))],cramertj,e5e19d960815a66d9094a817319ca92c7ed13872,1,Remove unstable-book repr-packed entry,HOORAY,2018-12-22T04:26:16Z,retep998,NA https://github.com/rust-lang/rust/pull/57049,MERGED,2018-12-21T18:19:57Z,2018-12-23T01:51:35Z,Stabilize #[repr(packed(N))],cramertj,e5e19d960815a66d9094a817319ca92c7ed13872,1,Remove unstable-book repr-packed entry,HOORAY,2018-12-23T02:01:39Z,LegNeato,NA https://github.com/rust-lang/rust/pull/57049,MERGED,2018-12-21T18:19:57Z,2018-12-23T01:51:35Z,Stabilize #[repr(packed(N))],cramertj,e5e19d960815a66d9094a817319ca92c7ed13872,1,Remove unstable-book repr-packed entry,HOORAY,2018-12-23T10:19:49Z,bitshifter,NA https://github.com/rust-lang/rust/pull/57049,MERGED,2018-12-21T18:19:57Z,2018-12-23T01:51:35Z,Stabilize #[repr(packed(N))],cramertj,e5e19d960815a66d9094a817319ca92c7ed13872,1,Remove unstable-book repr-packed entry,HOORAY,2019-02-26T05:02:10Z,axlrose,NA https://github.com/rust-lang/rust/pull/57061,MERGED,2018-12-22T12:51:35Z,2018-12-31T13:37:36Z,Group dep node data into a single structure,Zoxc,2738f2c891aec904888cc79c0119ab1b40663e1b,2,Address comments,HEART,2018-12-28T22:16:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57068,CLOSED,2018-12-22T20:36:35Z,2019-01-03T19:51:14Z,[WIP] split libtest types and formatting into a libtest-utils crate,gnzlbg,NA,NA,NA,THUMBS_UP,2018-12-23T00:24:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57073,CLOSED,2018-12-23T05:21:26Z,2019-01-29T18:46:09Z,use `MIN`/`MAX` constant names in integer pattern coverage messages,zackmdavis,NA,NA,NA,HEART,2019-04-30T00:17:19Z,estebank,NA https://github.com/rust-lang/rust/pull/57081,CLOSED,2018-12-23T13:19:06Z,2018-12-24T13:06:50Z, Use a single hash map to store query state,Zoxc,NA,NA,NA,THUMBS_UP,2018-12-24T10:59:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57082,MERGED,2018-12-23T13:19:43Z,2018-12-24T23:20:39Z,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 fix submodule handling,matthiaskrgr,49eb1e54199fa8529ff7c13bf6dd6a772b63c63f,1,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 ./x.py used to automatically check out the right commit when a submodule was outdated and ./x.py build was run and submodules handling was enabled in config.toml (submodules = true). But it threw an error: [...] failed to run: git submodule -q sync --progress src/tools/clippy The commit removes the --progress from git submodule call. Fixes #57080,THUMBS_UP,2018-12-23T13:41:01Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/57082,MERGED,2018-12-23T13:19:43Z,2018-12-24T23:20:39Z,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 fix submodule handling,matthiaskrgr,49eb1e54199fa8529ff7c13bf6dd6a772b63c63f,1,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 ./x.py used to automatically check out the right commit when a submodule was outdated and ./x.py build was run and submodules handling was enabled in config.toml (submodules = true). But it threw an error: [...] failed to run: git submodule -q sync --progress src/tools/clippy The commit removes the --progress from git submodule call. Fixes #57080,THUMBS_UP,2018-12-23T22:15:28Z,estebank,NA https://github.com/rust-lang/rust/pull/57082,MERGED,2018-12-23T13:19:43Z,2018-12-24T23:20:39Z,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 fix submodule handling,matthiaskrgr,49eb1e54199fa8529ff7c13bf6dd6a772b63c63f,1,x.py: fixup 6130fc884bc1dff9bb835894a7bb2042c110b011 ./x.py used to automatically check out the right commit when a submodule was outdated and ./x.py build was run and submodules handling was enabled in config.toml (submodules = true). But it threw an error: [...] failed to run: git submodule -q sync --progress src/tools/clippy The commit removes the --progress from git submodule call. Fixes #57080,THUMBS_UP,2018-12-24T12:12:14Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/57086,MERGED,2018-12-23T20:24:28Z,2019-01-09T09:21:38Z,Prepare everything for distributing miri via rustup,oli-obk,2ab78e195a8af531012f820ab84995c44d32c5c1,1,More feature whitelisting of winapi,THUMBS_UP,2019-01-07T11:04:16Z,mati865,NA https://github.com/rust-lang/rust/pull/57095,MERGED,2018-12-24T12:36:15Z,2019-01-08T04:48:01Z,Fix and optimize query profiling,Zoxc,23c742cce74b3e46e9b5b900d45e4c854ca17f47,3,Rename some functions,THUMBS_UP,2018-12-26T14:19:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57095,MERGED,2018-12-24T12:36:15Z,2019-01-08T04:48:01Z,Fix and optimize query profiling,Zoxc,23c742cce74b3e46e9b5b900d45e4c854ca17f47,3,Rename some functions,THUMBS_UP,2018-12-28T22:18:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57095,MERGED,2018-12-24T12:36:15Z,2019-01-08T04:48:01Z,Fix and optimize query profiling,Zoxc,23c742cce74b3e46e9b5b900d45e4c854ca17f47,3,Rename some functions,THUMBS_UP,2019-01-18T06:23:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57105,CLOSED,2018-12-24T18:50:48Z,2019-01-12T04:42:43Z,Stablilize const_int_{rotate wrapping sign},Centril,NA,NA,NA,THUMBS_UP,2019-01-05T21:58:13Z,Lokathor,NA https://github.com/rust-lang/rust/pull/57106,MERGED,2018-12-24T22:25:42Z,2019-01-31T06:31:41Z,Mark str::trim.* functions as #[must_use].,matthiaskrgr,74e9057905c3c24303245a4a2c5671d80a9503b6,1,modify remaining #[must_use[ messages,THUMBS_UP,2019-02-06T21:41:59Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HEART,2018-12-25T01:46:21Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HEART,2018-12-25T07:15:40Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HEART,2018-12-25T13:11:44Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2018-12-25T19:14:08Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2018-12-25T22:51:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2018-12-26T19:03:18Z,dwijnand,dale.wijnand@gmail.com https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2019-01-04T00:34:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2019-01-11T11:23:08Z,norru,nigu.orru@gmail.com https://github.com/rust-lang/rust/pull/57108,MERGED,2018-12-24T23:13:46Z,2018-12-26T18:54:00Z,Remove header licenses across the project,Mark-Simulacrum,e132d9066dd1d7acede428438ba8a32345ac343f,1,Account for no newline before test annotations Previously the license comment would always provide that newline but since that's been removed this change is needed.,HOORAY,2019-03-30T08:05:02Z,srinivasreddy42,NA https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-01-02T22:05:23Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-01-02T22:06:41Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-01-03T12:09:50Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-01-04T06:31:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-01-16T05:06:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57124,MERGED,2018-12-25T21:27:49Z,2018-12-27T00:57:58Z,Stabilize Duration::{as_millis as_micros as_nanos},sunjay,1e8261861385a5cabc7df2ecab7132ae5226fae0,3,Stabilize duration_as_u128,HOORAY,2019-02-01T10:12:54Z,PSeitz,NA https://github.com/rust-lang/rust/pull/57125,MERGED,2018-12-26T05:27:07Z,2019-01-01T23:30:56Z,Fix inconsistent Clone documentation.,doitian,bbc8c932fb05dfaed7b5bfe252712bede722b764,1,Fix inconsistent Clone documentation. Use function pointer as the example to demonstrate how to implement Clone for Copy types. refs #57123,THUMBS_UP,2018-12-28T11:27:57Z,Aimeedeer,NA https://github.com/rust-lang/rust/pull/57158,MERGED,2018-12-28T01:06:36Z,2018-12-30T12:32:55Z,Suggest `.as_ref()` when appropriate for `Option` and `Result`,estebank,0ecc128ccb43d0302288011a6919989e91da3bb8,2,Use `same_type` instead of duplicating logic,HOORAY,2018-12-28T12:35:46Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/57158,MERGED,2018-12-28T01:06:36Z,2018-12-30T12:32:55Z,Suggest `.as_ref()` when appropriate for `Option` and `Result`,estebank,0ecc128ccb43d0302288011a6919989e91da3bb8,2,Use `same_type` instead of duplicating logic,HOORAY,2018-12-29T06:39:54Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/57158,MERGED,2018-12-28T01:06:36Z,2018-12-30T12:32:55Z,Suggest `.as_ref()` when appropriate for `Option` and `Result`,estebank,0ecc128ccb43d0302288011a6919989e91da3bb8,2,Use `same_type` instead of duplicating logic,HOORAY,2019-01-02T23:02:02Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/57158,MERGED,2018-12-28T01:06:36Z,2018-12-30T12:32:55Z,Suggest `.as_ref()` when appropriate for `Option` and `Result`,estebank,0ecc128ccb43d0302288011a6919989e91da3bb8,2,Use `same_type` instead of duplicating logic,HOORAY,2019-01-09T03:00:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57163,MERGED,2018-12-28T06:28:51Z,2018-12-29T21:03:29Z,Give the crate select chevron room to breathe.,JohnHeitmann,94dd67bc6ee6b7e39321a1e968b5096d02213365,1,Give the crate select chevron room to breathe.,HOORAY,2018-12-28T12:39:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57163,MERGED,2018-12-28T06:28:51Z,2018-12-29T21:03:29Z,Give the crate select chevron room to breathe.,JohnHeitmann,94dd67bc6ee6b7e39321a1e968b5096d02213365,1,Give the crate select chevron room to breathe.,HOORAY,2018-12-28T14:39:46Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/57163,MERGED,2018-12-28T06:28:51Z,2018-12-29T21:03:29Z,Give the crate select chevron room to breathe.,JohnHeitmann,94dd67bc6ee6b7e39321a1e968b5096d02213365,1,Give the crate select chevron room to breathe.,HOORAY,2018-12-28T19:17:12Z,estebank,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-28T19:18:32Z,estebank,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-29T14:41:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-30T18:30:12Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-31T02:56:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-31T03:01:41Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2018-12-31T03:01:43Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2018-12-31T06:28:51Z,crlf0710,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-01-03T03:25:40Z,DCjanus,DCjanus@dcjanus.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-01-03T03:25:41Z,DCjanus,DCjanus@dcjanus.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-01-03T06:35:09Z,taiki-e,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-01-09T22:28:50Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-01-17T10:56:53Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-01-18T06:08:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-01-24T05:28:52Z,ckampfe,clark.kampfe@gmail.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-02-09T19:10:11Z,ckampfe,clark.kampfe@gmail.com https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-02-22T00:56:10Z,CoolOppo,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-03-01T04:22:25Z,axlrose,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-03-01T06:34:32Z,hcpl,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-03-01T06:34:32Z,hcpl,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-03-10T21:24:34Z,mrLSD,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HOORAY,2019-03-18T16:41:36Z,overvenus,NA https://github.com/rust-lang/rust/pull/57175,MERGED,2018-12-28T19:16:18Z,2019-01-12T14:08:39Z,Stabilize `let` bindings and destructuring in constants and const fn,oli-obk,6c623224dcf6f7cf06afd46b17ce7f665e6b4fda,4,const_let: --bless with --compare-mode=nll,HEART,2019-04-18T12:41:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57185,MERGED,2018-12-29T00:12:00Z,2018-12-30T05:53:23Z,resolve: Fix one more ICE in import validation,petrochenkov,ddb550a0e35921d2f4ecf023a7883b247f2ac407,6,resolve: Never override real bindings with `Def::Err`s from error recovery,HOORAY,2019-01-04T14:21:40Z,ashleygwilliams,NA https://github.com/rust-lang/rust/pull/57209,MERGED,2018-12-30T01:21:38Z,2019-01-02T02:03:32Z,Suggest using raw identifiers in 2018 edition when using keywords,estebank,18e0bdae542e2bc5312ab3f27c2864f946609f9a,1,Update tests after rebase,HEART,2019-01-10T18:22:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57214,MERGED,2018-12-30T12:44:20Z,2019-06-03T14:02:12Z,Store CtxtInterners for local values in AllArenas,Zoxc,66a376ea4f8caf9049c90888c1c1caa9a109b02c,2,Store CtxtInterners for local values in AllArenas,HOORAY,2019-06-02T17:01:16Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2018-12-31T01:16:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2018-12-31T05:04:12Z,honggyukim,honggyu.kp@gmail.com https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-02T18:37:10Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-02T21:58:12Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-02T22:58:34Z,mcarton,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-03T03:07:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-04T06:26:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-07T19:10:24Z,funbringer,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",HOORAY,2019-01-11T16:56:42Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",THUMBS_UP,2019-01-13T03:17:01Z,taeguk,xornrbboy@gmail.com https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",HOORAY,2019-01-19T13:49:43Z,taeguk,xornrbboy@gmail.com https://github.com/rust-lang/rust/pull/57220,MERGED,2018-12-30T20:03:12Z,2018-12-31T17:09:36Z,Add `-Z instrument-mcount`,quark-zju,31a5066e0b5f0e7e79b6cc04ae09166de0352c63,3,"Add `-Z instrument-mcount` This flag inserts `mcount` function call to the beginning of every function after inline processing. So tracing tools like uftrace [1] (or ftrace for Linux kernel modules) have a chance to examine function calls. It is similar to the `-pg` flag provided by gcc or clang but without generating a `__gmon_start__` function for executables. If a program runs without being traced no `gmon.out` will be written to disk. Under the hood it simply adds `""instrument-function-entry-inlined""=""mcount""` attribute to every function. The `post-inline-ee-instrument` LLVM pass does the actual job. [1]: https://github.com/namhyung/uftrace",HOORAY,2019-02-09T06:47:45Z,lu-zero,NA https://github.com/rust-lang/rust/pull/57232,MERGED,2018-12-31T10:28:04Z,2019-01-14T15:46:01Z,Parallelize and optimize parts of HIR map creation,Zoxc,cbb5a001792618a2f100e3198f1f874cdce6900f,4,Parallelize and optimize parts of HIR map creation,HOORAY,2018-12-31T21:09:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57232,MERGED,2018-12-31T10:28:04Z,2019-01-14T15:46:01Z,Parallelize and optimize parts of HIR map creation,Zoxc,cbb5a001792618a2f100e3198f1f874cdce6900f,4,Parallelize and optimize parts of HIR map creation,HOORAY,2019-01-01T04:32:08Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/57232,MERGED,2018-12-31T10:28:04Z,2019-01-14T15:46:01Z,Parallelize and optimize parts of HIR map creation,Zoxc,cbb5a001792618a2f100e3198f1f874cdce6900f,4,Parallelize and optimize parts of HIR map creation,HOORAY,2019-01-08T19:40:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/57232,MERGED,2018-12-31T10:28:04Z,2019-01-14T15:46:01Z,Parallelize and optimize parts of HIR map creation,Zoxc,cbb5a001792618a2f100e3198f1f874cdce6900f,4,Parallelize and optimize parts of HIR map creation,HOORAY,2019-01-18T06:04:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57238,MERGED,2018-12-31T21:08:50Z,2019-01-05T20:22:44Z,Fix backtraces for inlined functions on Windows,Zoxc,f4826abf6d04d3c468e37c3e7b670d35030ef0e0,1,Fix backtraces on Windows,HOORAY,2019-01-01T15:46:55Z,retep998,NA https://github.com/rust-lang/rust/pull/57243,MERGED,2019-01-01T00:35:29Z,2019-01-02T18:01:23Z,Bound sgx target_env with fortanix as target_vendor,dingelish,20e0395e66557a1be055ec3f11c35082bf9a5882,124,Merge remote-tracking branch 'upstream/master',THUMBS_UP,2019-01-05T12:49:58Z,davidp94,NA https://github.com/rust-lang/rust/pull/57250,MERGED,2019-01-01T19:35:39Z,2019-01-02T14:36:31Z,Improve type mismatch error messages,codeworm96,710dcbd3818deca8f193a45e321b58af3c24feae,54,"Improve type mismatch error messages Replace ""integral variable"" with ""integer"" and replace ""floating-point variable"" with ""floating-point number"" to make the message less confusing.",HOORAY,2019-01-02T15:39:42Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/57285,CLOSED,2019-01-02T21:06:31Z,2019-01-03T15:08:28Z,Unbreak the RLS,Xanewok,NA,NA,NA,THUMBS_UP,2019-01-03T03:33:53Z,cryptoquick,cryptoquick@pm.me https://github.com/rust-lang/rust/pull/57292,MERGED,2019-01-02T23:51:47Z,2019-01-04T03:11:17Z,[BETA] Update cargo,ehuss,6ce64ccc27f51b60561fb93f3cdc31c46f57a77b,1,[BETA] Update cargo,HOORAY,2019-01-03T00:56:11Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/57294,MERGED,2019-01-03T00:45:26Z,2019-01-25T03:59:09Z,When using value after move point at span of local,estebank,baa0828ee35475987fd825d8eaf77e009dca2bbe,49,Fix --compare-mode=nll tests,THUMBS_UP,2019-01-31T06:58:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57308,MERGED,2019-01-03T18:02:11Z,2019-01-07T19:43:06Z,Make CompileController thread-safe,Zoxc,75b2e143f125d7e214b8d3e54b3079caba1cc065,2,Make CompileController thread-safe,HOORAY,2019-01-11T05:22:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-03T22:23:50Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-03T23:04:57Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-04T00:26:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-04T00:46:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-04T07:19:36Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/57318,CLOSED,2019-01-03T22:08:02Z,2019-01-14T21:18:07Z,Format Rust code,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-01-04T13:52:08Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57333,CLOSED,2019-01-04T14:03:59Z,2019-02-10T13:43:37Z,better error message for trailing doc comment in traits (issue #56766),lcnr,NA,NA,NA,HEART,2019-01-23T18:24:46Z,estebank,NA https://github.com/rust-lang/rust/pull/57350,MERGED,2019-01-05T04:42:10Z,2019-01-19T02:26:01Z,Better error note on unimplemented Index trait for string,folex,c120199116439827a89a0ac0f24f91f99dbed60f,3,Show suggestion to use .char().nth() and link to The Book on unimplemented Index trait,THUMBS_UP,2019-01-10T20:49:34Z,mexus,NA https://github.com/rust-lang/rust/pull/57350,MERGED,2019-01-05T04:42:10Z,2019-01-19T02:26:01Z,Better error note on unimplemented Index trait for string,folex,c120199116439827a89a0ac0f24f91f99dbed60f,3,Show suggestion to use .char().nth() and link to The Book on unimplemented Index trait,THUMBS_UP,2019-01-18T19:24:18Z,estebank,NA https://github.com/rust-lang/rust/pull/57351,MERGED,2019-01-05T12:05:47Z,2019-01-13T14:36:00Z,Don't actually create a full MIR stack frame when not needed,oli-obk,dec79e44705992d607b001cd349c98807761d3d8,1,Not seeing the forest because there are too many trees in the way,THUMBS_UP,2019-01-05T21:23:15Z,dotdash,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-06T04:54:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HEART,2019-01-06T18:05:25Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HOORAY,2019-01-06T18:05:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-06T18:05:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HEART,2019-01-06T20:58:50Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HEART,2019-01-09T09:49:53Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HEART,2019-01-14T12:03:50Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HOORAY,2019-01-16T15:57:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-16T17:21:18Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-16T18:41:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HOORAY,2019-01-16T21:04:31Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-17T10:26:31Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HOORAY,2019-01-17T13:07:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-17T13:15:21Z,Vurich,NA https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,HOORAY,2019-01-18T06:06:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57353,MERGED,2019-01-05T15:18:53Z,2019-01-13T14:36:01Z,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).,huonw,6e742dbb3f5f9dde10dda8ba1930e03a0f057b5e,2,Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x). These can both rely on IEEE754 semantics to be made faster by folding away the sign with an abs (left private for now) and then comparing to infinity letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and) and so these new forms compile down to a few instructions without branches e.g. for f32: ```asm is_infinite: andps xmm0 xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0 dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0 xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1 dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1 xmm0 seta al ret ``` When used in loops/repeatedly they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls to be shared and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons and the old `is_finite` did three (with a branch) and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8 7 years ago. Benchmark (`abs` is the new form `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32 f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910 0.135 0.735 -0.874 0.518 0.150 -0.527 -0.418 0.449 -0.158 -0.064 -0.144 -0.948 -0.103 0.225 -0.104 -0.795 0.435 0.860 0.027 0.625 -0.848 -0.454 0.359 -0.930 0.067 0.642 0.976 -0.682 -0.035 0.750 0.005 -0.825 0.731 -0.850 -0.740 -0.118 -0.972 0.888 -0.958 0.086 0.237 -0.580 0.488 0.028 -0.552 0.302 0.058 -0.229 -0.166 -0.248 -0.430 0.789 -0.122 0.120 -0.934 -0.911 -0.976 0.882 -0.410 0.311 -0.611 -0.758 0.786 -0.711 0.378 0.803 -0.068 0.932 0.483 0.085 0.247 -0.128 -0.839 -0.737 -0.605 0.637 -0.230 -0.502 0.231 -0.694 -0.400 -0.441 0.142 0.174 0.681 -0.763 -0.608 0.848 -0.550 0.883 -0.212 0.876 0.186 -0.909 0.401 -0.533 -0.961 0.539 -0.298 -0.448 0.223 -0.307 -0.594 0.629 -0.534 0.959 0.349 -0.926 -0.523 -0.895 -0.157 -0.074 -0.060 0.513 -0.647 -0.649 0.428 0.401 0.391 0.426 0.700 0.880 -0.101 0.862 0.493 0.819 -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```,THUMBS_UP,2019-01-23T18:23:37Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/57355,MERGED,2019-01-05T17:19:47Z,2019-01-11T14:53:14Z,use the correct supertrait substitution in `object_ty_for_trait`,arielb1,85c4b4c7f249bdb33cba9ac738efbcb9000e4b86,2,use the correct supertrait substitution in `object_ty_for_trait` Fixes #57156.,THUMBS_UP,2019-01-07T00:53:02Z,mikeyhew,NA https://github.com/rust-lang/rust/pull/57364,MERGED,2019-01-06T00:32:01Z,2019-02-24T09:44:39Z,Improve parsing diagnostic for negative supertrait bounds,hdhoang,7cfddfb4e40584dc206cedef7c70b5fecb03d6a1,4,Improve parsing diagnostic for negative supertrait bounds,HEART,2019-01-07T01:52:38Z,estebank,NA https://github.com/rust-lang/rust/pull/57364,MERGED,2019-01-06T00:32:01Z,2019-02-24T09:44:39Z,Improve parsing diagnostic for negative supertrait bounds,hdhoang,7cfddfb4e40584dc206cedef7c70b5fecb03d6a1,4,Improve parsing diagnostic for negative supertrait bounds,HEART,2019-02-28T05:14:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57366,MERGED,2019-01-06T01:09:42Z,2019-01-14T00:59:58Z,Point at match discriminant on type error in match arm pattern,estebank,10fbdbf949f3ca171a52010eb2c53547c3e5b4f5,1,Update documentation comment,HEART,2019-01-16T21:45:24Z,lnicola,NA https://github.com/rust-lang/rust/pull/57367,MERGED,2019-01-06T01:52:50Z,2019-02-26T02:22:01Z,Stabilize `unrestricted_attribute_tokens`,petrochenkov,eccc19996b1e6a38568544e0be3cfe971caa12eb,16,Stabilize `unrestricted_attribute_tokens`,HEART,2019-04-11T22:43:01Z,estebank,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T12:59:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T13:38:02Z,terry90,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T14:37:54Z,retep998,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2019-01-06T14:51:07Z,antifuchs,asf@boinkor.net https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2019-01-06T15:22:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T15:23:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T15:41:19Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2019-01-06T15:41:20Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T17:56:36Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T19:00:45Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2019-01-06T20:53:50Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-06T23:12:25Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2019-01-09T21:01:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-10T22:08:02Z,Lokathor,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2019-01-11T05:28:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,THUMBS_UP,2020-06-01T16:02:51Z,YerinAlexey,NA https://github.com/rust-lang/rust/pull/57375,MERGED,2019-01-06T12:51:35Z,2019-01-07T19:43:10Z,Add duration constants,NA,NA,NA,NA,HOORAY,2020-06-01T16:02:51Z,YerinAlexey,NA https://github.com/rust-lang/rust/pull/57378,CLOSED,2019-01-06T15:49:18Z,2019-02-03T16:21:01Z,RangeInclusive iteration performance improvement.,matthieu-m,NA,NA,NA,THUMBS_UP,2019-01-06T18:09:48Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57378,CLOSED,2019-01-06T15:49:18Z,2019-02-03T16:21:01Z,RangeInclusive iteration performance improvement.,matthieu-m,NA,NA,NA,HEART,2019-01-13T20:11:39Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/57380,MERGED,2019-01-06T19:05:45Z,2019-01-25T00:27:44Z,Fix Instant/Duration math precision & associativity on Windows,bearcage,14ce5364de3bf7d2da59fbe52360459c0f2c6ada,1,Add a comment on the meaning of Instant t: Duration,HOORAY,2019-01-06T19:45:49Z,pitdicker,NA https://github.com/rust-lang/rust/pull/57380,MERGED,2019-01-06T19:05:45Z,2019-01-25T00:27:44Z,Fix Instant/Duration math precision & associativity on Windows,bearcage,14ce5364de3bf7d2da59fbe52360459c0f2c6ada,1,Add a comment on the meaning of Instant t: Duration,HEART,2019-01-09T01:10:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57381,MERGED,2019-01-06T21:39:05Z,2019-01-14T06:36:10Z,"Tweak output of type mismatch between ""then"" and `else` `if` arms",estebank,9567544902e1a6cca1b10333b6fc929e50ec1fba,6,Suggest removal of semicolon when appropriate,HEART,2019-01-16T21:44:28Z,lnicola,NA https://github.com/rust-lang/rust/pull/57381,MERGED,2019-01-06T21:39:05Z,2019-01-14T06:36:10Z,"Tweak output of type mismatch between ""then"" and `else` `if` arms",estebank,9567544902e1a6cca1b10333b6fc929e50ec1fba,6,Suggest removal of semicolon when appropriate,HEART,2019-01-16T22:02:47Z,tikue,NA https://github.com/rust-lang/rust/pull/57381,MERGED,2019-01-06T21:39:05Z,2019-01-14T06:36:10Z,"Tweak output of type mismatch between ""then"" and `else` `if` arms",estebank,9567544902e1a6cca1b10333b6fc929e50ec1fba,6,Suggest removal of semicolon when appropriate,HEART,2019-01-17T10:22:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57381,MERGED,2019-01-06T21:39:05Z,2019-01-14T06:36:10Z,"Tweak output of type mismatch between ""then"" and `else` `if` arms",estebank,9567544902e1a6cca1b10333b6fc929e50ec1fba,6,Suggest removal of semicolon when appropriate,HEART,2019-01-18T05:58:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57394,MERGED,2019-01-07T04:22:08Z,2019-01-07T08:56:20Z,slightly optimize compiletest test collection,euclio,2a9ad77d952d658b4566a3201b98598e7f1e2ebd,1,slightly optimize compiletest test collection Save quite a few syscalls and avoiding pushing in a loop.,THUMBS_UP,2019-01-07T09:07:31Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57407,MERGED,2019-01-07T16:09:38Z,2019-01-26T20:58:51Z,Stabilize extern_crate_self,mehcode,09d073a4c59dee09f69f3cb144c3067a153c30e6,10,stabilize extern_crate_self,HOORAY,2019-04-12T09:06:17Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-07T19:42:25Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-07T20:00:13Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-07T21:32:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HEART,2019-01-07T21:32:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-08T03:04:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-08T13:59:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-08T23:03:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-09T04:28:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-16T12:23:50Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-23T09:35:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2019-01-23T16:26:01Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HEART,2019-01-23T22:51:31Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HOORAY,2021-07-27T13:20:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/57416,MERGED,2019-01-07T19:27:09Z,2019-01-16T15:01:48Z,rustc: Remove platform intrinsics crate,alexcrichton,7616daabc7aa114a958bd4fb61d91345a4ff7a45,57,"rustc: Remove platform intrinsics crate This was originally attempted in #57048 but it was realized that we could fully remove the crate via the `""unadjusted""` ABI on intrinsics. This means that all intrinsics in stdsimd are implemented directly against LLVM rather than using the abstraction layer provided here. That ends up meaning that this crate is no longer used at all. This crate developed long ago to implement the SIMD intrinsics but we didn't end up using it in the long run. In that case let's remove it!",HEART,2021-07-27T13:20:55Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-07T20:52:42Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-07T21:29:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-08T09:10:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-09T10:42:57Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-20T01:01:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-01-31T07:00:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-03-06T18:34:45Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-03-26T13:02:12Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-04-08T20:29:17Z,frol,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-04-09T04:39:43Z,lexxvir,NA https://github.com/rust-lang/rust/pull/57425,MERGED,2019-01-07T20:46:25Z,2019-01-26T12:21:29Z,std: Stabilize fixed-width integer atomics,alexcrichton,14b36fb15a49bc2d38964ec5bd93ca26adda0486,1,std: Stabilize fixed-width integer atomics This commit stabilizes the `Atomic{I U}{8 16 32 64}` APIs in the `std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753 and tracked in #32976 this feature has been unstable for quite some time and is hopefully ready to go over the finish line now! The API is being stabilized as-is. The API of `AtomicU8` and friends mirrors that of `AtomicUsize`. A list of changes made here are: * A portability documentation section has been added to describe the current state of affairs. * Emulation of smaller-size atomics with larger-size atomics has been documented. * As an added bonus `ATOMIC_*_INIT` is now scheduled for deprecation across the board in 1.34.0 now that `const` functions can be invoked in statics. Note that the 128-bit atomic types are omitted from this stabilization explicitly. They have far less platform support than the other atomic types and will likely require further discussion about their best location. Closes #32976 Closes #56753,HOORAY,2019-04-16T03:59:41Z,nwn,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-03-23T01:01:32Z,estebank,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-03-30T12:55:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-03-30T21:28:28Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-04-06T17:36:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-05-04T22:19:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-05-05T20:19:39Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-05-14T15:11:18Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-03T11:23:21Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-12T12:37:03Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-12T14:56:04Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-12T16:50:40Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-12T17:21:43Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-13T09:58:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-13T13:16:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-13T20:49:15Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-13T21:41:56Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-15T21:48:29Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-16T07:02:54Z,theduke,NA https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-16T17:39:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2019-06-29T23:19:20Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2021-02-14T03:03:02Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/57428,MERGED,2019-01-07T21:36:56Z,2019-06-06T06:36:12Z,Implementation of RFC 2289 (associated_type_bounds),alexreg,ee890331f6e33afe12ef250eb6388db2aab7cbbf,3,Reblessed tests with NLL compare mode on.,HEART,2021-08-13T05:05:46Z,ahrens,mahrens@delphix.com https://github.com/rust-lang/rust/pull/57442,MERGED,2019-01-08T13:21:09Z,2019-01-28T03:22:13Z,Simplify `ConstValue::ScalarPair`,oli-obk,fe50b4eb1d6f7a31c53798bca3d0fa2b0670fa3d,12,`ConstValue::ScalarPair` only needs to represent slices,THUMBS_UP,2019-01-08T17:24:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/57442,MERGED,2019-01-08T13:21:09Z,2019-01-28T03:22:13Z,Simplify `ConstValue::ScalarPair`,oli-obk,fe50b4eb1d6f7a31c53798bca3d0fa2b0670fa3d,12,`ConstValue::ScalarPair` only needs to represent slices,THUMBS_UP,2019-01-09T00:06:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57442,MERGED,2019-01-08T13:21:09Z,2019-01-28T03:22:13Z,Simplify `ConstValue::ScalarPair`,oli-obk,fe50b4eb1d6f7a31c53798bca3d0fa2b0670fa3d,12,`ConstValue::ScalarPair` only needs to represent slices,THUMBS_UP,2019-02-07T15:11:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57449,CLOSED,2019-01-08T19:38:18Z,2019-01-11T20:23:21Z,re-do documentation for Drop,steveklabnik,NA,NA,NA,HOORAY,2019-01-08T20:04:27Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57449,CLOSED,2019-01-08T19:38:18Z,2019-01-11T20:23:21Z,re-do documentation for Drop,steveklabnik,NA,NA,NA,HOORAY,2019-01-10T05:09:30Z,crlf0710,NA https://github.com/rust-lang/rust/pull/57451,MERGED,2019-01-08T20:04:43Z,2019-02-14T07:07:16Z,suggestion-diagnostics: as_ref improve snippet,dlrobertson,285d4a7eb67cdf3ebba4b8fe60a5c5a6abf3edfc,2,suggestion-diagnostics: as_ref improve snippet Improve the code snippet suggested in suggestion-diagnostics when suggesting the use of as_ref.,HEART,2019-02-13T17:54:42Z,estebank,NA https://github.com/rust-lang/rust/pull/57454,MERGED,2019-01-08T21:35:59Z,2019-01-13T14:36:07Z,Some cleanups for core::fmt,sinkuu,12ae3651f891d22f804c67923d02cbdfa10fa60d,2,Misc cleanups,HEART,2019-01-08T22:18:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/57459,MERGED,2019-01-08T23:55:33Z,2019-01-12T14:08:51Z,Reference tracking issue for inherent associated types in diagnostic,varkor,ac4a4547ba674b6d9d0e3b3e018be94d32766faa,2,Consolidate equality constraints error message,HEART,2019-01-09T04:48:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57467,MERGED,2019-01-09T11:58:43Z,2019-01-15T16:35:47Z,Implement `check_attribute` to forbid `#[allow_internal_unsafe]`,JohnTitor,bd1551e46e4a788dc974f4aac8ba821133625663,4,Fix tests,HEART,2019-01-15T12:00:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57471,MERGED,2019-01-09T15:13:42Z,2019-01-11T03:07:12Z,Updated RELEASES.md for 1.32.0,XAMPPRocky,890a8a45c2b3264cc487411e7d2878cb42149965,1,Update RELEASES.md,HEART,2019-01-09T15:26:07Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/57471,MERGED,2019-01-09T15:13:42Z,2019-01-11T03:07:12Z,Updated RELEASES.md for 1.32.0,XAMPPRocky,890a8a45c2b3264cc487411e7d2878cb42149965,1,Update RELEASES.md,HEART,2019-01-09T16:30:24Z,ehuss,NA https://github.com/rust-lang/rust/pull/57471,MERGED,2019-01-09T15:13:42Z,2019-01-11T03:07:12Z,Updated RELEASES.md for 1.32.0,XAMPPRocky,890a8a45c2b3264cc487411e7d2878cb42149965,1,Update RELEASES.md,HEART,2019-01-09T16:51:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57471,MERGED,2019-01-09T15:13:42Z,2019-01-11T03:07:12Z,Updated RELEASES.md for 1.32.0,XAMPPRocky,890a8a45c2b3264cc487411e7d2878cb42149965,1,Update RELEASES.md,HEART,2019-01-10T09:11:56Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57471,MERGED,2019-01-09T15:13:42Z,2019-01-11T03:07:12Z,Updated RELEASES.md for 1.32.0,XAMPPRocky,890a8a45c2b3264cc487411e7d2878cb42149965,1,Update RELEASES.md,HEART,2019-01-10T13:57:09Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57475,MERGED,2019-01-09T18:48:38Z,2019-01-22T08:25:15Z,Add signed num::NonZeroI* types,SimonSapin,e195ce654a570606a85ead6cefb36042a206205a,4,Fix some non-determinism in help messages for E0277 errors. The diagnostic for this error prints `the following implementations were found` followed by the first N relevant impls sorted. This commit makes the sort happen before slicing so that the set of impls being printed is deterministic when the input is not.,HEART,2019-01-10T13:57:28Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/57475,MERGED,2019-01-09T18:48:38Z,2019-01-22T08:25:15Z,Add signed num::NonZeroI* types,SimonSapin,e195ce654a570606a85ead6cefb36042a206205a,4,Fix some non-determinism in help messages for E0277 errors. The diagnostic for this error prints `the following implementations were found` followed by the first N relevant impls sorted. This commit makes the sort happen before slicing so that the set of impls being printed is deterministic when the input is not.,HEART,2019-01-10T15:19:58Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/57475,MERGED,2019-01-09T18:48:38Z,2019-01-22T08:25:15Z,Add signed num::NonZeroI* types,SimonSapin,e195ce654a570606a85ead6cefb36042a206205a,4,Fix some non-determinism in help messages for E0277 errors. The diagnostic for this error prints `the following implementations were found` followed by the first N relevant impls sorted. This commit makes the sort happen before slicing so that the set of impls being printed is deterministic when the input is not.,HEART,2019-01-30T10:37:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57475,MERGED,2019-01-09T18:48:38Z,2019-01-22T08:25:15Z,Add signed num::NonZeroI* types,SimonSapin,e195ce654a570606a85ead6cefb36042a206205a,4,Fix some non-determinism in help messages for E0277 errors. The diagnostic for this error prints `the following implementations were found` followed by the first N relevant impls sorted. This commit makes the sort happen before slicing so that the set of impls being printed is deterministic when the input is not.,HEART,2019-01-31T06:56:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57477,MERGED,2019-01-09T19:12:49Z,2019-01-14T15:46:11Z,clarify resolve typo suggestion,euclio,404ad50d148af4ea388861d1f9a45dd9f5c43ef7,40,clarify resolve typo suggestion Include the kind of the binding that we're suggesting and use a structured suggestion.,HEART,2019-01-10T12:04:19Z,killercup,NA https://github.com/rust-lang/rust/pull/57481,MERGED,2019-01-09T21:59:35Z,2019-01-15T01:41:51Z,provide suggestion for invalid boolean cast,euclio,565c39de439f59e83efe2f0064c0dbebb287c8e9,7,provide suggestion for invalid boolean cast Also don't suggest comparing to zero for non-numeric expressions.,THUMBS_UP,2019-01-09T22:15:31Z,estebank,NA https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T04:25:09Z,SamuelMarks,NA https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T07:04:17Z,kdy1,kdy1997.dev@gmail.com https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T08:05:46Z,jondot,dn@rng0.io https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T08:31:14Z,xcaptain,joey.xf@gmail.com https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T09:15:22Z,petamoriken,moriken@kimamass.com https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T13:42:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T14:47:29Z,damienmg,NA https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-10T15:47:02Z,johnthagen,NA https://github.com/rust-lang/rust/pull/57484,MERGED,2019-01-10T01:14:57Z,2019-01-11T00:20:33Z,Integrate miri into build-manifest,alexcrichton,dd326f84fb0acb10aaa18da23db56e92dc79afdb,2,Integrate miri into build-manifest This fixes a mistake where miri was accidentally left out of the build-manifest parsing meaning that today's nightly generated a manifest with invalid urls!,THUMBS_UP,2019-01-11T04:40:14Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/57486,MERGED,2019-01-10T03:42:14Z,2019-01-19T18:37:24Z,Simplify `TokenStream` some more,nnethercote,728572440171d8d9c0557c89c3d71cc8d7cf6c2e,1,Make `TokenStream` use `Option`. Because that's the more typical way of representing an all-or-nothing type.,THUMBS_UP,2019-01-10T04:15:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/57486,MERGED,2019-01-10T03:42:14Z,2019-01-19T18:37:24Z,Simplify `TokenStream` some more,nnethercote,728572440171d8d9c0557c89c3d71cc8d7cf6c2e,1,Make `TokenStream` use `Option`. Because that's the more typical way of representing an all-or-nothing type.,THUMBS_UP,2019-01-23T09:41:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57494,MERGED,2019-01-10T19:15:39Z,2019-01-13T14:36:10Z,Speed up item_bodies for large match statements involving regions,dotdash,5f402b827726607b04887c7c7b8d8b95cce8f487,1,Add a fast path for identical regions in lub_concrete_regions In functions with lots of region constraint if the fixed point iteration converges only slowly a lot of the var/var constraints will have equal regions most of the time. Yet we still perform the LUB calculation and try to intern the result. Especially the latter incurs quite some overhead. This reduces the take taken by the item bodies checking pass for the unicode_normalization crate by about 75%.,THUMBS_UP,2019-01-18T06:20:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57501,MERGED,2019-01-10T22:00:24Z,2019-01-19T13:11:53Z,High priority resolutions for associated variants,petrochenkov,01d0ae96188b99c367178a38906b7269e1ada244,11,Prioritize variants as inherent associated items during name resolution,THUMBS_UP,2019-01-10T22:50:05Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/57501,MERGED,2019-01-10T22:00:24Z,2019-01-19T13:11:53Z,High priority resolutions for associated variants,petrochenkov,01d0ae96188b99c367178a38906b7269e1ada244,11,Prioritize variants as inherent associated items during name resolution,THUMBS_UP,2019-01-23T10:46:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57508,MERGED,2019-01-11T02:25:16Z,2019-01-13T14:36:12Z,rustdoc: Allow inlining of reexported crates and crate items,DebugSteven,ca47808479f7b5eccdbb595c7769ea6009db9a9c,2,add test for pub extern crate,HOORAY,2019-01-11T17:12:19Z,estebank,NA https://github.com/rust-lang/rust/pull/57508,MERGED,2019-01-11T02:25:16Z,2019-01-13T14:36:12Z,rustdoc: Allow inlining of reexported crates and crate items,DebugSteven,ca47808479f7b5eccdbb595c7769ea6009db9a9c,2,add test for pub extern crate,HOORAY,2019-01-17T13:09:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57508,MERGED,2019-01-11T02:25:16Z,2019-01-13T14:36:12Z,rustdoc: Allow inlining of reexported crates and crate items,DebugSteven,ca47808479f7b5eccdbb595c7769ea6009db9a9c,2,add test for pub extern crate,HOORAY,2019-01-18T06:08:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57510,MERGED,2019-01-11T05:15:25Z,2019-01-12T14:08:56Z,Add a profiles section to the manifest,nrc,4103e5b34bcd5fff13afe79494d6955d7996c804,1,Add a profiles section to the manifest,HOORAY,2019-01-11T07:54:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57513,CLOSED,2019-01-11T12:04:44Z,2019-01-11T19:45:19Z,Rollup of 2 pull requests,Centril,NA,NA,NA,CONFUSED,2019-01-11T15:59:01Z,kennytm,NA https://github.com/rust-lang/rust/pull/57520,MERGED,2019-01-11T17:25:45Z,2019-01-17T10:16:18Z,Add lint for copyright headers to 'tidy' tool,alexreg,4d1802308b128c757d443d39945bd335515ef4ee,2,Updated Book and Reference submodules.,HEART,2019-01-12T04:48:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57522,MERGED,2019-01-11T18:01:30Z,2019-01-12T14:08:58Z,don't unwrap unexpected tokens in `format!`,euclio,020e1f5b60d406524599bff35b43167f2af4302f,3,don't unwrap unexpected tokens in `format!` Fixes #57512.,HOORAY,2019-01-18T22:08:49Z,estebank,NA https://github.com/rust-lang/rust/pull/57537,MERGED,2019-01-12T04:58:01Z,2019-01-22T16:14:33Z,Small perf improvement for fmt,sinkuu,038d8372244ab088ea186e10704e2bfc4e83f477,2,Fix simple formatting optimization name old2 ns/iter new2 ns/iter diff ns/iter diff % speedup fmt::write_str_macro1 12 295 12 308 13 0.11% x 1.00 fmt::write_str_macro2 24 079 21 451 -2 628 -10.91% x 1.12 fmt::write_str_macro_debug 238 363 230 807 -7 556 -3.17% x 1.03 fmt::write_str_ref 6 203 6 064 -139 -2.24% x 1.02 fmt::write_str_value 6 225 6 075 -150 -2.41% x 1.02 fmt::write_vec_macro1 17 144 17 121 -23 -0.13% x 1.00 fmt::write_vec_macro2 29 845 26 703 -3 142 -10.53% x 1.12 fmt::write_vec_macro_debug 248 840 242 117 -6 723 -2.70% x 1.03 fmt::write_vec_ref 5 954 6 438 484 8.13% x 0.92 fmt::write_vec_value 5 959 6 439 480 8.06% x 0.93,THUMBS_UP,2019-01-22T16:28:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/57537,MERGED,2019-01-12T04:58:01Z,2019-01-22T16:14:33Z,Small perf improvement for fmt,sinkuu,038d8372244ab088ea186e10704e2bfc4e83f477,2,Fix simple formatting optimization name old2 ns/iter new2 ns/iter diff ns/iter diff % speedup fmt::write_str_macro1 12 295 12 308 13 0.11% x 1.00 fmt::write_str_macro2 24 079 21 451 -2 628 -10.91% x 1.12 fmt::write_str_macro_debug 238 363 230 807 -7 556 -3.17% x 1.03 fmt::write_str_ref 6 203 6 064 -139 -2.24% x 1.02 fmt::write_str_value 6 225 6 075 -150 -2.41% x 1.02 fmt::write_vec_macro1 17 144 17 121 -23 -0.13% x 1.00 fmt::write_vec_macro2 29 845 26 703 -3 142 -10.53% x 1.12 fmt::write_vec_macro_debug 248 840 242 117 -6 723 -2.70% x 1.03 fmt::write_vec_ref 5 954 6 438 484 8.13% x 0.92 fmt::write_vec_value 5 959 6 439 480 8.06% x 0.93,THUMBS_UP,2019-01-31T06:42:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57540,MERGED,2019-01-12T07:20:58Z,2019-01-15T01:41:52Z,Modify some parser diagnostics to continue evaluating beyond the parser,estebank,28ea03e11477032a29b30284487d6d73e181ecaf,7,Suggest correct location for lifetime parameters in use,HEART,2019-01-12T18:50:52Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/57540,MERGED,2019-01-12T07:20:58Z,2019-01-15T01:41:52Z,Modify some parser diagnostics to continue evaluating beyond the parser,estebank,28ea03e11477032a29b30284487d6d73e181ecaf,7,Suggest correct location for lifetime parameters in use,HEART,2019-01-23T10:06:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57546,CLOSED,2019-01-12T14:24:37Z,2019-01-14T15:44:20Z,Avoid layout calculations in assert_bits to speed up match checking,dotdash,NA,NA,NA,HEART,2019-01-12T14:26:51Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/57546,CLOSED,2019-01-12T14:24:37Z,2019-01-14T15:44:20Z,Avoid layout calculations in assert_bits to speed up match checking,dotdash,NA,NA,NA,HEART,2019-01-12T15:50:22Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/57546,CLOSED,2019-01-12T14:24:37Z,2019-01-14T15:44:20Z,Avoid layout calculations in assert_bits to speed up match checking,dotdash,NA,NA,NA,HEART,2019-01-12T17:21:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/57551,MERGED,2019-01-12T21:16:36Z,2019-01-18T21:50:51Z,resolve: Add a test for issue #57539,petrochenkov,ebdd072e3b1d4b3eb39048c27be4e9b2ccc849a8,2,resolve: Add a test for issue #57539,HEART,2019-01-12T23:29:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57552,MERGED,2019-01-12T21:28:25Z,2019-01-22T16:14:33Z,Default images,GuillaumeGomez,b5d167f58a423cb0003714eceeb72172d1726473,4,Add default favicon for documentation,THUMBS_UP,2019-01-22T22:46:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57561,CLOSED,2019-01-13T01:07:22Z,2019-01-13T04:26:43Z,Rollup of 15 pull requests,Centril,NA,NA,NA,HOORAY,2019-01-13T02:44:11Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-01-13T16:44:15Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T16:44:17Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-01-13T17:00:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T17:00:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T17:04:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T17:13:55Z,varkor,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T17:52:53Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-13T20:13:53Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-01-13T21:15:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-13T21:15:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-13T21:15:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-13T23:54:32Z,sinkuu,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-14T01:16:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-14T09:42:10Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-01-14T16:49:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-14T16:49:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-01-14T16:49:38Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-18T03:51:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HOORAY,2019-01-18T03:53:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-01-31T20:45:28Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,HEART,2019-02-06T02:32:13Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/57578,CLOSED,2019-01-13T16:27:14Z,2019-02-25T14:21:02Z,[WIP] HirId-ification,ljedrz,NA,NA,NA,THUMBS_UP,2019-02-13T22:33:12Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/57579,MERGED,2019-01-13T16:43:35Z,2019-01-15T16:35:51Z,Add core::iter::once_with(),NA,NA,NA,NA,THUMBS_UP,2019-01-23T18:45:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57579,MERGED,2019-01-13T16:43:35Z,2019-01-15T16:35:51Z,Add core::iter::once_with(),NA,NA,NA,NA,THUMBS_UP,2019-01-24T04:08:47Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/57579,MERGED,2019-01-13T16:43:35Z,2019-01-15T16:35:51Z,Add core::iter::once_with(),NA,NA,NA,NA,THUMBS_UP,2020-02-06T11:37:52Z,tomwhoiscontrary,NA https://github.com/rust-lang/rust/pull/57584,MERGED,2019-01-13T22:26:42Z,2019-01-14T15:46:17Z,Remove the `connect_timeout_unroutable` test.,nnethercote,24a9ac7d03972e8a5163e6c3774b4eddc05a6ca2,1,Remove the `connect_timeout_unroutable` test. It requires an unreachable IP address but there is no such thing and this has caused it to fail for multiple people. Fixes #44698 fixes #50065.,THUMBS_UP,2019-01-13T22:32:28Z,RalfJung,NA https://github.com/rust-lang/rust/pull/57585,MERGED,2019-01-14T01:31:16Z,2019-01-15T01:41:55Z,Recover from item trailing semicolon,estebank,3874c7755f292abc87fa2ce4fe82479ad063367e,7,Recover from item trailing semicolon,HEART,2019-01-14T06:52:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2019-01-14T23:38:24Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2019-01-14T23:57:32Z,estebank,NA https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2019-02-04T13:37:17Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HEART,2019-02-04T13:39:09Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2019-02-12T11:38:08Z,kgv,NA https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2019-03-20T03:36:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HOORAY,2020-06-18T05:09:39Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/57586,MERGED,2019-01-14T03:43:17Z,2019-02-01T17:59:53Z,Implement public/private dependency feature,Aaron1011,369faaeaffa1b960f8260a1905b1fc34f33a23f6,2,Cleanup unecessary code,HEART,2020-06-18T05:09:40Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/57589,MERGED,2019-01-14T06:45:12Z,2019-01-15T01:41:56Z,Add a debug_assert to Vec::set_len,scottmcm,1fd971c3b97bc1f01740a552aeb3d23b6ed194f5,1,Add a debug_assert to Vec::set_len,HOORAY,2019-01-14T07:35:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57589,MERGED,2019-01-14T06:45:12Z,2019-01-15T01:41:56Z,Add a debug_assert to Vec::set_len,scottmcm,1fd971c3b97bc1f01740a552aeb3d23b6ed194f5,1,Add a debug_assert to Vec::set_len,HOORAY,2019-01-14T16:17:14Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/57589,MERGED,2019-01-14T06:45:12Z,2019-01-15T01:41:56Z,Add a debug_assert to Vec::set_len,scottmcm,1fd971c3b97bc1f01740a552aeb3d23b6ed194f5,1,Add a debug_assert to Vec::set_len,HOORAY,2019-01-23T09:49:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-14T16:30:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-14T17:18:34Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-14T20:22:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-15T13:51:27Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-15T14:08:58Z,taiki-e,NA https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-15T23:09:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-16T03:58:43Z,o01eg,NA https://github.com/rust-lang/rust/pull/57600,MERGED,2019-01-14T16:26:21Z,2019-01-16T12:01:38Z,Rust 1.32.0 stable release,pietroalbini,05fe2fc3941ce5fa584204239f090fe51d4b4598,1,Update the `tar` crate Fixes a bug in extracting a tarball by correctly recognizing entries are files instead of directories.,HOORAY,2019-01-16T13:40:38Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/57604,MERGED,2019-01-14T18:03:47Z,2019-01-22T16:14:34Z,Make `str` indexing generic on `SliceIndex`.,alercah,c7d25a2a4082e6d2601ea4c06ea01b632d196172,13,Make `str` indexing generic on `SliceIndex`.,THUMBS_UP,2019-01-30T10:36:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57609,MERGED,2019-01-14T22:06:10Z,2019-02-25T09:18:35Z,Use normal mutable borrows in matches,matthewjasper,5ffc9197264a07a50bfb27e436fe284ae8c0687c,5,Move the exit block of the match to the end,HEART,2019-02-03T21:42:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/57609,MERGED,2019-01-14T22:06:10Z,2019-02-25T09:18:35Z,Use normal mutable borrows in matches,matthewjasper,5ffc9197264a07a50bfb27e436fe284ae8c0687c,5,Move the exit block of the match to the end,THUMBS_UP,2019-02-21T21:05:52Z,lqd,NA https://github.com/rust-lang/rust/pull/57609,MERGED,2019-01-14T22:06:10Z,2019-02-25T09:18:35Z,Use normal mutable borrows in matches,matthewjasper,5ffc9197264a07a50bfb27e436fe284ae8c0687c,5,Move the exit block of the match to the end,THUMBS_UP,2019-02-28T05:16:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57634,MERGED,2019-01-15T16:20:52Z,2019-01-19T13:11:58Z,Remove an unused function argument,oli-obk,096ca873330d61de91d81618ce3a1e9905581ff1,4,Remove an unused function argument,HEART,2019-01-15T20:03:21Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57634,MERGED,2019-01-15T16:20:52Z,2019-01-19T13:11:58Z,Remove an unused function argument,oli-obk,096ca873330d61de91d81618ce3a1e9905581ff1,4,Remove an unused function argument,HEART,2019-01-16T01:19:28Z,estebank,NA https://github.com/rust-lang/rust/pull/57634,MERGED,2019-01-15T16:20:52Z,2019-01-19T13:11:58Z,Remove an unused function argument,oli-obk,096ca873330d61de91d81618ce3a1e9905581ff1,4,Remove an unused function argument,HEART,2019-01-18T14:15:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/57651,MERGED,2019-01-16T00:39:18Z,2019-01-20T11:09:02Z,Implement new literal type `Err`,JohnTitor,4005d3a8cb082f84f6bfb8c2168387a747aabf1e,2,Remove whitespace,HEART,2019-01-16T01:42:09Z,estebank,NA https://github.com/rust-lang/rust/pull/57655,MERGED,2019-01-16T04:31:43Z,2019-01-20T13:46:27Z,OSX: fix #57534 registering thread dtors while running thread dtors,mtak-,1a51bb8174e97251a37fcd83ff8750b7773e762a,2,OSX: fix #57534 registering thread dtors while running thread dtors,THUMBS_UP,2019-01-16T05:22:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/57655,MERGED,2019-01-16T04:31:43Z,2019-01-20T13:46:27Z,OSX: fix #57534 registering thread dtors while running thread dtors,mtak-,1a51bb8174e97251a37fcd83ff8750b7773e762a,2,OSX: fix #57534 registering thread dtors while running thread dtors,THUMBS_UP,2019-01-16T17:48:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57667,MERGED,2019-01-16T14:07:49Z,2019-01-22T16:14:36Z,Fix memory leak in P::filter_map,ishitatsuyuki,763392cb8ca09e0f332c1ab9b75376afbdafc18f,1,Fix memory leak in P::filter_map,THUMBS_UP,2019-01-22T10:54:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/57674,MERGED,2019-01-16T18:37:54Z,2019-01-29T07:53:00Z,Avoid erase_regions_ty queries if there are no regions to erase,dotdash,da06898a7539ff66e636a5bf9d3b176b865a2737,1,Avoid erase_regions_ty queries if there are no regions to erase It's overall faster to perform this extra check than to perform the query even if the result is already in the query cache.,THUMBS_UP,2019-01-20T17:26:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-16T20:15:48Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-16T20:58:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-16T22:13:20Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-17T02:45:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-17T02:45:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-17T04:13:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-17T04:39:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-20T00:59:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-23T06:07:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-23T06:07:59Z,panaman67,NA https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-24T00:45:55Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HOORAY,2019-01-26T03:22:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57675,MERGED,2019-01-16T18:40:31Z,2019-01-26T04:48:26Z,Rebase to the llvm-project monorepo,cuviper,059ed4f21f42914028af5fc0083d3eca13a49d6f,1,Update `dlmalloc` to 0.1.2 Remove usage of an old and removed wasm intrinsic,HEART,2019-01-26T03:22:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57677,MERGED,2019-01-16T19:50:26Z,2019-01-22T16:14:37Z,const_eval: Predetermine the layout of all locals when pushing a stack frame,dotdash,98d4f33626c4a18092cd015b4e1cc15381989677,4,const_eval: Predetermine the layout of all locals when pushing a stack frame Usually the layout of any locals is required at least three times once when it becomes live once when it is written to and once it is read from. By adding a cache for them we can reduce the number of layout queries speeding up code that is heavy on const_eval.,THUMBS_UP,2019-01-18T04:10:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57677,MERGED,2019-01-16T19:50:26Z,2019-01-22T16:14:37Z,const_eval: Predetermine the layout of all locals when pushing a stack frame,dotdash,98d4f33626c4a18092cd015b4e1cc15381989677,4,const_eval: Predetermine the layout of all locals when pushing a stack frame Usually the layout of any locals is required at least three times once when it becomes live once when it is written to and once it is read from. By adding a cache for them we can reduce the number of layout queries speeding up code that is heavy on const_eval.,THUMBS_UP,2019-01-18T07:48:59Z,oli-obk,NA https://github.com/rust-lang/rust/pull/57677,MERGED,2019-01-16T19:50:26Z,2019-01-22T16:14:37Z,const_eval: Predetermine the layout of all locals when pushing a stack frame,dotdash,98d4f33626c4a18092cd015b4e1cc15381989677,4,const_eval: Predetermine the layout of all locals when pushing a stack frame Usually the layout of any locals is required at least three times once when it becomes live once when it is written to and once it is read from. By adding a cache for them we can reduce the number of layout queries speeding up code that is heavy on const_eval.,THUMBS_UP,2019-01-22T00:54:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57677,MERGED,2019-01-16T19:50:26Z,2019-01-22T16:14:37Z,const_eval: Predetermine the layout of all locals when pushing a stack frame,dotdash,98d4f33626c4a18092cd015b4e1cc15381989677,4,const_eval: Predetermine the layout of all locals when pushing a stack frame Usually the layout of any locals is required at least three times once when it becomes live once when it is written to and once it is read from. By adding a cache for them we can reduce the number of layout queries speeding up code that is heavy on const_eval.,THUMBS_UP,2019-01-31T06:41:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57689,MERGED,2019-01-17T04:31:35Z,2019-01-19T23:58:42Z,Redo `hir::Stmt`,nnethercote,afbd004d696063adf1301ae461c41565f2f1921a,16,Remove `hir::StmtKind::Decl`. It's a level of indirection that hurts far more than it helps. The code is simpler without it. (This commit cuts more than 120 lines of code.) In particular this commit removes some unnecessary `Span`s within `DeclKind` that were always identical to those in the enclosing `Stmt` and some unnecessary allocations via `P`.,THUMBS_UP,2019-01-18T04:10:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57689,MERGED,2019-01-17T04:31:35Z,2019-01-19T23:58:42Z,Redo `hir::Stmt`,nnethercote,afbd004d696063adf1301ae461c41565f2f1921a,16,Remove `hir::StmtKind::Decl`. It's a level of indirection that hurts far more than it helps. The code is simpler without it. (This commit cuts more than 120 lines of code.) In particular this commit removes some unnecessary `Span`s within `DeclKind` that were always identical to those in the enclosing `Stmt` and some unnecessary allocations via `P`.,THUMBS_UP,2019-01-18T14:38:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/57689,MERGED,2019-01-17T04:31:35Z,2019-01-19T23:58:42Z,Redo `hir::Stmt`,nnethercote,afbd004d696063adf1301ae461c41565f2f1921a,16,Remove `hir::StmtKind::Decl`. It's a level of indirection that hurts far more than it helps. The code is simpler without it. (This commit cuts more than 120 lines of code.) In particular this commit removes some unnecessary `Span`s within `DeclKind` that were always identical to those in the enclosing `Stmt` and some unnecessary allocations via `P`.,THUMBS_UP,2019-01-23T09:42:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57697,MERGED,2019-01-17T14:30:48Z,2019-01-20T19:02:06Z,Use a faster early exit during region expansion,dotdash,f0d3df39cbe1a3afaaabddbc5764b4057c713dd5,1,Use a faster early exit during region expansion Turns out that the equality check for regions is rather expensive and the current early exit check works in such a way that the comparison is even done twice. As we only really care about the case of equal scopes we can perform a faster more specialized check and move it up one level so we can eventually skip the additional full comparison as well.,THUMBS_UP,2019-01-18T04:09:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57697,MERGED,2019-01-17T14:30:48Z,2019-01-20T19:02:06Z,Use a faster early exit during region expansion,dotdash,f0d3df39cbe1a3afaaabddbc5764b4057c713dd5,1,Use a faster early exit during region expansion Turns out that the equality check for regions is rather expensive and the current early exit check works in such a way that the comparison is even done twice. As we only really care about the case of equal scopes we can perform a faster more specialized check and move it up one level so we can eventually skip the additional full comparison as well.,THUMBS_UP,2019-01-20T10:50:31Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/57697,MERGED,2019-01-17T14:30:48Z,2019-01-20T19:02:06Z,Use a faster early exit during region expansion,dotdash,f0d3df39cbe1a3afaaabddbc5764b4057c713dd5,1,Use a faster early exit during region expansion Turns out that the equality check for regions is rather expensive and the current early exit check works in such a way that the comparison is even done twice. As we only really care about the case of equal scopes we can perform a faster more specialized check and move it up one level so we can eventually skip the additional full comparison as well.,THUMBS_UP,2019-01-21T02:02:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/57697,MERGED,2019-01-17T14:30:48Z,2019-01-20T19:02:06Z,Use a faster early exit during region expansion,dotdash,f0d3df39cbe1a3afaaabddbc5764b4057c713dd5,1,Use a faster early exit during region expansion Turns out that the equality check for regions is rather expensive and the current early exit check works in such a way that the comparison is even done twice. As we only really care about the case of equal scopes we can perform a faster more specialized check and move it up one level so we can eventually skip the additional full comparison as well.,THUMBS_UP,2019-01-23T09:33:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57697,MERGED,2019-01-17T14:30:48Z,2019-01-20T19:02:06Z,Use a faster early exit during region expansion,dotdash,f0d3df39cbe1a3afaaabddbc5764b4057c713dd5,1,Use a faster early exit during region expansion Turns out that the equality check for regions is rather expensive and the current early exit check works in such a way that the comparison is even done twice. As we only really care about the case of equal scopes we can perform a faster more specialized check and move it up one level so we can eventually skip the additional full comparison as well.,THUMBS_UP,2019-01-23T18:56:14Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57699,MERGED,2019-01-17T15:22:27Z,2019-01-19T18:37:31Z,add applicability to remaining suggestions,euclio,02843d9eb71ad50d490afc6276f4bfe59f182624,5,properly deprecate suggestion methods,HEART,2019-01-19T01:07:35Z,estebank,NA https://github.com/rust-lang/rust/pull/57714,MERGED,2019-01-17T21:41:36Z,2019-01-25T17:14:43Z,[NLL] Clean up handling of type annotations,matthewjasper,620a03f5aa7490cc904f868c91fbb303ec6a3274,1,Unit test from #57866.,THUMBS_UP,2019-01-20T21:40:33Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/57714,MERGED,2019-01-17T21:41:36Z,2019-01-25T17:14:43Z,[NLL] Clean up handling of type annotations,matthewjasper,620a03f5aa7490cc904f868c91fbb303ec6a3274,1,Unit test from #57866.,HEART,2019-01-25T18:13:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57720,MERGED,2019-01-18T01:30:28Z,2019-01-19T02:26:13Z,Fix suggestions given mulitple bad lifetimes,dlrobertson,e3ba6ed3f571119e2f9165805e77c20b5e7a14b4,5,Fix suggestions given mulitple bad lifetimes When given multiple lifetimes prior to type parameters in generic parameters do not ICE and print the correct suggestion.,HOORAY,2019-01-18T03:18:37Z,estebank,NA https://github.com/rust-lang/rust/pull/57745,CLOSED,2019-01-18T21:01:11Z,2019-03-21T20:10:55Z,[WIP] resolve: Fallback to extern crates in absolute paths on 2015 edition,petrochenkov,NA,NA,NA,EYES,2019-01-20T14:31:27Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57746,MERGED,2019-01-18T21:28:38Z,2019-01-19T13:12:04Z,Update README.md,mark-i-m,0c4602aaef787d94ec01d990744bc9e6941ed2eb,1,Update README.md Point contributors to the rustc-guide...,THUMBS_UP,2019-01-19T01:29:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57757,CLOSED,2019-01-19T14:47:43Z,2019-01-27T16:06:20Z,Refactor ty::query::config,Centril,NA,NA,NA,THUMBS_UP,2019-01-19T15:20:26Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57757,CLOSED,2019-01-19T14:47:43Z,2019-01-27T16:06:20Z,Refactor ty::query::config,Centril,NA,NA,NA,THUMBS_UP,2019-01-19T16:44:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/57757,CLOSED,2019-01-19T14:47:43Z,2019-01-27T16:06:20Z,Refactor ty::query::config,Centril,NA,NA,NA,HEART,2019-01-19T16:44:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-01-19T17:41:34Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-01-19T18:25:06Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-01-21T03:10:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-01-24T00:28:04Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-01-24T19:24:56Z,Saldivarcher,saldivarcher@gmail.com https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-02-01T16:54:22Z,bjorn3,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-02-02T23:28:37Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-02-28T18:42:30Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-03-06T18:20:28Z,chrish42,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-03-07T17:37:02Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-03-07T18:35:20Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-03-08T05:49:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-04-09T18:21:06Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-04-22T14:52:16Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-04-22T14:52:20Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,THUMBS_UP,2019-07-07T21:43:27Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/57760,MERGED,2019-01-19T17:23:53Z,2019-02-28T17:59:32Z,Support defining C compatible variadic functions,dlrobertson,f7dd4389f8145fe0f29c5b29784b244fa38d2bfb,1,Fix doc comments in librustc/hir/lowering.rs,HOORAY,2019-07-07T21:43:28Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/57763,MERGED,2019-01-19T19:25:20Z,2019-01-20T04:16:41Z,Update beta to released compiler,Mark-Simulacrum,79a942bb395557b578cd1d9062306e191c7f62df,1,Update beta to released compiler,HOORAY,2019-01-19T20:55:41Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57765,MERGED,2019-01-19T23:26:32Z,2019-01-27T20:50:35Z,Bump bootstrap compiler to 1.33 beta,Mark-Simulacrum,cd39cf748e3a5ab7cc4449ba9acfddb969c79209,2,Update cargo to fix deprecation warnings Implemented in rust-lang/cargo#6600,HOORAY,2019-01-21T05:00:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57765,MERGED,2019-01-19T23:26:32Z,2019-01-27T20:50:35Z,Bump bootstrap compiler to 1.33 beta,Mark-Simulacrum,cd39cf748e3a5ab7cc4449ba9acfddb969c79209,2,Update cargo to fix deprecation warnings Implemented in rust-lang/cargo#6600,HOORAY,2019-01-24T04:33:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/57783,MERGED,2019-01-20T19:29:24Z,2019-01-21T11:07:58Z,"Add ""dereference boxed value"" suggestion.",davidtwco,f13fe5f3f7e2e2ed689967e818ffadc9cdba8af6,6,"Add ""dereference boxed value"" suggestion. This commit adds a `help: consider dereferencing the boxed value` suggestion to discriminants of match statements when the match arms have type `T` and the discriminant has type `Box`.",THUMBS_UP,2019-01-27T14:36:05Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57784,MERGED,2019-01-20T19:56:27Z,2019-01-21T11:07:59Z,Add span for bad doc comment,JohnTitor,b97c9641f51c6897ddded240c87e84f065f55588,3,Fix tests,HEART,2019-01-20T21:45:43Z,estebank,NA https://github.com/rust-lang/rust/pull/57802,MERGED,2019-01-21T12:28:06Z,2019-01-25T03:59:17Z,Print visible name for types as well as modules.,davidtwco,1db42756f7fec98d3705a0f975a1c92d10e88cd7,4,Print visible name for types as well as modules. This commit extends previous work in #55007 where the name from the visible parent was used for modules. Now we also print the name from the visible parent for types.,HOORAY,2019-01-24T19:57:06Z,estebank,NA https://github.com/rust-lang/rust/pull/57802,MERGED,2019-01-21T12:28:06Z,2019-01-25T03:59:17Z,Print visible name for types as well as modules.,davidtwco,1db42756f7fec98d3705a0f975a1c92d10e88cd7,4,Print visible name for types as well as modules. This commit extends previous work in #55007 where the name from the visible parent was used for modules. Now we also print the name from the visible parent for types.,HOORAY,2019-01-31T06:49:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-01-22T00:57:38Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-02-20T15:13:58Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-02-20T18:32:30Z,frol,NA https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-02-20T18:34:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-02-21T05:09:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57815,MERGED,2019-01-21T18:43:52Z,2019-02-13T07:46:35Z,Speed up the fast path for assert_eq! and assert_ne!,dotdash,5a7cd848f740291f94f2400b50f41136fc8657bb,1,Speed up the fast path for assert_eq! and assert_ne! Currently the panic!() calls directly borrow the value bindings. This causes those bindings to always be initialized i.e. they're initialized even before the values are even compared. This causes noticeable overhead in what should be a really cheap operation. By performing a reborrow of the value in the call to panic!() we allow LLVM to optimize that code so that the extra borrow only happens in the error case. We could achieve the same result by dereferencing the values passed to panic!() as the format machinery borrows them anyway but this causes assertions to fail to compile if one of the values is unsized i.e. it would be a breaking change.,THUMBS_UP,2019-12-06T07:31:13Z,kdy1,kdy1997.dev@gmail.com https://github.com/rust-lang/rust/pull/57817,MERGED,2019-01-21T20:28:55Z,2019-01-24T04:16:35Z,Add error for trailing angle brackets.,davidtwco,914d142c02b558a597055c66a0e7e09115416211,4,Extend trailing `>` detection for paths. This commit extends the trailing `>` detection to also work for paths such as `Foo::>:Baz`. This involves making the existing check take the token that is expected to follow the path being checked as a parameter. Care is taken to ensure that this only happens on the construction of a whole path segment and not a partial path segment (during recursion). Through this enhancement it was also observed that the ordering of right shift token and greater than tokens was overfitted to the examples being tested. In practice given a sequence of `>` characters: `>>>>>>>>>` ..then they will be split into `>>` eagerly: `>> >> >> >> >`. ..but when a `<` is prepended then the first `>>` is split: ` > >> >> >> >` ..and then when another `<` is prepended a right shift is first again: `Vec<> >> >> >> >` In the previous commits a example that had two `<<` characters was always used and therefore it was incorrectly assumed that `>>` would always be first - but when there is a single `<` this is not the case.,HEART,2019-01-21T20:41:47Z,estebank,NA https://github.com/rust-lang/rust/pull/57817,MERGED,2019-01-21T20:28:55Z,2019-01-24T04:16:35Z,Add error for trailing angle brackets.,davidtwco,914d142c02b558a597055c66a0e7e09115416211,4,Extend trailing `>` detection for paths. This commit extends the trailing `>` detection to also work for paths such as `Foo::>:Baz`. This involves making the existing check take the token that is expected to follow the path being checked as a parameter. Care is taken to ensure that this only happens on the construction of a whole path segment and not a partial path segment (during recursion). Through this enhancement it was also observed that the ordering of right shift token and greater than tokens was overfitted to the examples being tested. In practice given a sequence of `>` characters: `>>>>>>>>>` ..then they will be split into `>>` eagerly: `>> >> >> >> >`. ..but when a `<` is prepended then the first `>>` is split: ` > >> >> >> >` ..and then when another `<` is prepended a right shift is first again: `Vec<> >> >> >> >` In the previous commits a example that had two `<<` characters was always used and therefore it was incorrectly assumed that `>>` would always be first - but when there is a single `<` this is not the case.,HEART,2019-01-31T06:46:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-22T09:02:15Z,jethrogb,NA https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-22T09:33:28Z,comex,NA https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-22T15:02:39Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-24T07:06:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-30T02:07:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-30T02:38:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-30T05:56:13Z,burjui,bytefu@gmail.com https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-30T12:09:28Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-30T19:37:13Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57825,MERGED,2019-01-22T08:33:09Z,2019-01-26T20:58:57Z,un-deprecate mem::zeroed,RalfJung,e7998bf6a6e5cb3c12604d97c72435c1b4cea492,1,un-deprecate mem::zeroed,THUMBS_UP,2019-01-31T06:52:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57834,MERGED,2019-01-22T13:26:44Z,2019-01-24T04:16:36Z,Stabilize Any::get_type_id and rename to type_id,SimonSapin,fb5d3c1f379e42b9d31887b744982159a0dc651b,2,Stabilize Any::get_type_id and rename to type_id FCP: https://github.com/rust-lang/rust/issues/27745#issuecomment-373906749,HOORAY,2019-01-24T19:47:57Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/57835,MERGED,2019-01-22T13:50:22Z,2019-01-23T02:00:50Z,typeck: remove leaky nested probe during trait object method resolution,pnkfelix,33c2ceb3a2b769fb3f2f6019b1071439f0dc6444,2,unit test for issue 57673.,THUMBS_UP,2019-01-23T09:40:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/57836,MERGED,2019-01-22T14:09:57Z,2019-01-24T04:16:36Z,Fix some cross crate existential type ICEs,oli-obk,5d6faf7b4af94d0da681e9873539f9f13279290d,2,Remove unused feature gates,HEART,2019-01-22T15:31:44Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/57836,MERGED,2019-01-22T14:09:57Z,2019-01-24T04:16:36Z,Fix some cross crate existential type ICEs,oli-obk,5d6faf7b4af94d0da681e9873539f9f13279290d,2,Remove unused feature gates,HEART,2019-01-22T19:26:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/57836,MERGED,2019-01-22T14:09:57Z,2019-01-24T04:16:36Z,Fix some cross crate existential type ICEs,oli-obk,5d6faf7b4af94d0da681e9873539f9f13279290d,2,Remove unused feature gates,HEART,2019-01-23T18:37:10Z,estebank,NA https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-01-28T22:51:25Z,mati865,NA https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-03-02T18:10:33Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-03-02T20:25:06Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-03-27T16:12:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-03-27T16:31:16Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/57842,MERGED,2019-01-22T20:11:21Z,2019-03-19T21:40:04Z,Move libtest out of rust-lang/rust,gnzlbg,1446b242cec21f896e10360c8f80ee047dbe24c8,1,Remove libterm from bootstrap,HOORAY,2019-03-28T18:09:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57851,MERGED,2019-01-23T00:58:50Z,2019-02-05T22:09:06Z,Don't try to clean predicates involving ReErased,Aaron1011,e4fedf4be4c0cf735787bc81ff5ea0d7086fe6cd,2,Don't try to clean predicates involving ReErased There's nothing to render when we have a bound involving ReErased (either a type or region outliving it) so we don't attempt to generate a clean WherePredicate Fixes #57806,HEART,2019-02-05T23:03:41Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/57852,MERGED,2019-01-23T01:38:31Z,2019-01-26T18:15:11Z,Suggest removing leading left angle brackets.,davidtwco,8ab12f6cc06033f483d085b37b766d681dcc61ca,1,Optimize snapshot usage. This commit implements a suggestion from @estebank that optimizes the use of snapshots. Instead of creating a snapshot for each recursion in `parse_path_segment` and then replacing `self` with them until the first invocation where if leading angle brackets are detected `self` is not replaced and instead the snapshot is used to inform how parsing should continue. Now a snapshot is created in the first invocation that acts as a backup of the parser state before any generic arguments are parsed (and therefore before recursion starts). This backup replaces `self` if after all parsing of generic arguments has concluded we can determine that there are leading angle brackets. Parsing can then proceed from the backup state making use of the now known number of unmatched leading angle brackets to recover.,THUMBS_UP,2019-01-31T06:49:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57852,MERGED,2019-01-23T01:38:31Z,2019-01-26T18:15:11Z,Suggest removing leading left angle brackets.,davidtwco,8ab12f6cc06033f483d085b37b766d681dcc61ca,1,Optimize snapshot usage. This commit implements a suggestion from @estebank that optimizes the use of snapshots. Instead of creating a snapshot for each recursion in `parse_path_segment` and then replacing `self` with them until the first invocation where if leading angle brackets are detected `self` is not replaced and instead the snapshot is used to inform how parsing should continue. Now a snapshot is created in the first invocation that acts as a backup of the parser state before any generic arguments are parsed (and therefore before recursion starts). This backup replaces `self` if after all parsing of generic arguments has concluded we can determine that there are leading angle brackets. Parsing can then proceed from the backup state making use of the now known number of unmatched leading angle brackets to recover.,HEART,2019-02-01T21:12:36Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/57856,MERGED,2019-01-23T07:16:03Z,2019-02-14T07:07:19Z,Convert old first edition links to current edition one,tesuji,e7f8e63ed425cef77a9ad43e463b39009c1a495a,15,Convert old doc links to current edition Use footnote style to bypass the tidy check,THUMBS_UP,2019-01-23T09:03:36Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/57863,MERGED,2019-01-23T16:01:33Z,2019-01-25T00:27:55Z,Add suggestion for incorrect field syntax.,davidtwco,f14d007ee4f4b69cdb3880db49608b432bea8352,4,Add suggestion for incorrect field syntax. This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character.,HEART,2019-01-23T18:19:00Z,estebank,NA https://github.com/rust-lang/rust/pull/57863,MERGED,2019-01-23T16:01:33Z,2019-01-25T00:27:55Z,Add suggestion for incorrect field syntax.,davidtwco,f14d007ee4f4b69cdb3880db49608b432bea8352,4,Add suggestion for incorrect field syntax. This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character.,HEART,2019-01-31T06:40:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57870,CLOSED,2019-01-24T00:27:15Z,2019-03-05T22:32:51Z,Allow hidden lifetimes in `impl Trait`,cramertj,NA,NA,NA,THUMBS_UP,2019-01-24T01:00:15Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/57870,CLOSED,2019-01-24T00:27:15Z,2019-03-05T22:32:51Z,Allow hidden lifetimes in `impl Trait`,cramertj,NA,NA,NA,THUMBS_UP,2019-01-27T03:20:15Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/57871,MERGED,2019-01-24T00:39:05Z,2019-01-27T02:55:02Z,Correctly set filetime for copied LLVM,Mark-Simulacrum,82fae2be049f37bc20d2bad6c6c482a7d957f687,3,Correctly set filetime for copied LLVM This also makes compiletest no longer always retest everything.,HEART,2019-01-24T02:07:10Z,estebank,NA https://github.com/rust-lang/rust/pull/57871,MERGED,2019-01-24T00:39:05Z,2019-01-27T02:55:02Z,Correctly set filetime for copied LLVM,Mark-Simulacrum,82fae2be049f37bc20d2bad6c6c482a7d957f687,3,Correctly set filetime for copied LLVM This also makes compiletest no longer always retest everything.,HEART,2019-01-24T09:23:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/57871,MERGED,2019-01-24T00:39:05Z,2019-01-27T02:55:02Z,Correctly set filetime for copied LLVM,Mark-Simulacrum,82fae2be049f37bc20d2bad6c6c482a7d957f687,3,Correctly set filetime for copied LLVM This also makes compiletest no longer always retest everything.,HEART,2019-01-24T15:16:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/57871,MERGED,2019-01-24T00:39:05Z,2019-01-27T02:55:02Z,Correctly set filetime for copied LLVM,Mark-Simulacrum,82fae2be049f37bc20d2bad6c6c482a7d957f687,3,Correctly set filetime for copied LLVM This also makes compiletest no longer always retest everything.,HEART,2019-01-27T10:10:11Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/57882,MERGED,2019-01-24T21:28:46Z,2019-03-09T11:17:03Z,overhaul unused doc comments lint,euclio,daf80f721b0c9f3a57f13dd9d8934e851ad17dd5,14,expand unused doc comment diagnostic Report the diagnostic on macro expansions and add a label indicating why the comment is unused.,HEART,2019-01-24T22:28:12Z,estebank,NA https://github.com/rust-lang/rust/pull/57882,MERGED,2019-01-24T21:28:46Z,2019-03-09T11:17:03Z,overhaul unused doc comments lint,euclio,daf80f721b0c9f3a57f13dd9d8934e851ad17dd5,14,expand unused doc comment diagnostic Report the diagnostic on macro expansions and add a label indicating why the comment is unused.,HEART,2019-01-25T01:06:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57882,MERGED,2019-01-24T21:28:46Z,2019-03-09T11:17:03Z,overhaul unused doc comments lint,euclio,daf80f721b0c9f3a57f13dd9d8934e851ad17dd5,14,expand unused doc comment diagnostic Report the diagnostic on macro expansions and add a label indicating why the comment is unused.,HEART,2019-02-27T14:58:23Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57886,MERGED,2019-01-24T23:40:29Z,2019-01-26T02:10:44Z,Add suggestion for moving type declaration before associated type bindings in generic arguments.,davidtwco,7a0abbff8be746e46841ac7eef5a17364d6b8b51,3,Combining move lifetime and type suggestions. This commit combines the move lifetime and move type suggestions so that when rustfix applies them they don't conflict with each other.,HEART,2019-01-25T00:57:47Z,estebank,NA https://github.com/rust-lang/rust/pull/57886,MERGED,2019-01-24T23:40:29Z,2019-01-26T02:10:44Z,Add suggestion for moving type declaration before associated type bindings in generic arguments.,davidtwco,7a0abbff8be746e46841ac7eef5a17364d6b8b51,3,Combining move lifetime and type suggestions. This commit combines the move lifetime and move type suggestions so that when rustfix applies them they don't conflict with each other.,ROCKET,2019-01-25T00:57:49Z,estebank,NA https://github.com/rust-lang/rust/pull/57886,MERGED,2019-01-24T23:40:29Z,2019-01-26T02:10:44Z,Add suggestion for moving type declaration before associated type bindings in generic arguments.,davidtwco,7a0abbff8be746e46841ac7eef5a17364d6b8b51,3,Combining move lifetime and type suggestions. This commit combines the move lifetime and move type suggestions so that when rustfix applies them they don't conflict with each other.,HEART,2019-01-31T06:50:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57904,MERGED,2019-01-25T19:32:21Z,2019-01-29T07:53:04Z,add typo suggestion to unknown attribute error,euclio,5e6702117223b61057957ca2593f03e3f45ccd8a,6,add typo suggestion to unknown attribute error,HEART,2019-01-25T21:29:26Z,estebank,NA https://github.com/rust-lang/rust/pull/57904,MERGED,2019-01-25T19:32:21Z,2019-01-29T07:53:04Z,add typo suggestion to unknown attribute error,euclio,5e6702117223b61057957ca2593f03e3f45ccd8a,6,add typo suggestion to unknown attribute error,HEART,2019-01-28T10:25:42Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/57907,MERGED,2019-01-25T21:08:30Z,2019-01-27T09:19:23Z,remove deprecated suggestion functions,euclio,0897ffc28f68fab862e970599c95bb65b280b48b,53,remove `_with_applicability` from suggestion fns,HEART,2019-01-25T21:25:02Z,estebank,NA https://github.com/rust-lang/rust/pull/57907,MERGED,2019-01-25T21:08:30Z,2019-01-27T09:19:23Z,remove deprecated suggestion functions,euclio,0897ffc28f68fab862e970599c95bb65b280b48b,53,remove `_with_applicability` from suggestion fns,HEART,2019-01-26T08:01:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57908,MERGED,2019-01-25T23:02:58Z,2019-01-26T20:59:00Z,resolve: Fix span arithmetics in the import conflict error,petrochenkov,1b659d69bc0ba7fe534cc26bda8544a558a7d2b2,4,Address review comments and cleanup code,THUMBS_UP,2019-01-25T23:07:15Z,estebank,NA https://github.com/rust-lang/rust/pull/57915,MERGED,2019-01-26T14:45:34Z,2019-01-29T07:53:05Z,Pretty print `$crate` as `crate` or `crate_name` in more cases,petrochenkov,c375333362bd1b5f006f6d627ff129c2c54d620c,6,Pretty print `$crate` as `crate` or `crate_name` in more cases,THUMBS_UP,2019-01-31T08:21:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HOORAY,2019-02-07T08:05:14Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HOORAY,2019-02-07T15:08:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HOORAY,2019-02-07T19:21:55Z,joaosoares,joao.soares@avantsoft.com.br https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HOORAY,2019-12-27T18:48:48Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HEART,2020-01-01T23:45:16Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HEART,2020-03-07T07:53:59Z,lahwran,NA https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HOORAY,2020-03-07T07:54:02Z,lahwran,NA https://github.com/rust-lang/rust/pull/57937,MERGED,2019-01-27T20:21:27Z,2019-02-02T02:18:45Z,NVPTX target specification,denzp,49931fda56dc6268ba3c104b64768f551cfc4636,2,Use correct CI test image for WASM and NVPTX,HEART,2020-07-01T06:12:16Z,schulzch,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-28T16:42:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-28T19:18:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-28T19:29:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-29T08:40:35Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-29T08:46:38Z,mati865,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-29T09:04:18Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-29T18:04:29Z,bjorn3,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-01-31T08:24:28Z,tesuji,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HEART,2019-02-06T17:12:20Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-02-06T21:39:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57948,MERGED,2019-01-28T14:52:38Z,2019-01-29T16:26:41Z,Use multiple threads by default. Limits tests to one thread. Do some renaming.,Zoxc,fd9d9ee3a293bab88fd4dfb69f28d5ccb92e292c,1,Fix a comment,HOORAY,2019-02-07T15:11:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57950,MERGED,2019-01-28T15:32:27Z,2019-01-29T07:53:08Z,Extend E0106 E0261,QuietMisdreavus,a2b75eda955a46ec643b8277b1fb41c4fed94f4e,1,review comments,THUMBS_UP,2019-01-28T19:07:11Z,estebank,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T09:22:21Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T09:23:50Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T09:31:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T09:38:20Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T09:50:28Z,varkor,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T10:11:21Z,mati865,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T11:28:54Z,oli-obk,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T11:36:42Z,qnighy,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T15:27:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T15:51:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T18:41:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T22:33:37Z,killercup,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-29T23:56:20Z,panaman67,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-30T09:38:07Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-30T16:14:46Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-30T22:26:08Z,javierhonduco,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-31T11:27:08Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-01-31T13:44:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-01T03:57:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-02-02T17:06:11Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-02T17:38:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-03T00:45:39Z,komawoyo,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-03T01:20:19Z,naftulikay,me@naftuli.wtf https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-03T05:13:48Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-03T06:15:31Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-03T11:25:41Z,denzp,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-02-03T13:20:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-02-04T06:34:13Z,mcginty,me@jake.su https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-04T16:13:40Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-05T07:11:08Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-02-13T17:55:25Z,estebank,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-03-05T03:59:12Z,lu-zero,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-03-05T03:59:13Z,lu-zero,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-04-16T09:46:21Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-04-30T21:27:13Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-05-05T19:02:19Z,ljedrz,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-05-08T08:18:26Z,hcpl,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-05-21T15:43:40Z,jplatte,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-05-30T11:47:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-05-30T11:47:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-05-30T15:47:38Z,z64,zachnowicki@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-01T15:35:56Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-01T15:35:59Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-01T15:57:06Z,debayande,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-01T17:09:08Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-01T17:16:13Z,weihanglo,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-01T17:16:15Z,weihanglo,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-01T18:25:12Z,qezz,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-01T18:25:12Z,qezz,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-01T22:44:06Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-02T11:42:08Z,LYP951018,liuyupei951018@hotmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-02T21:31:54Z,boozook,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-02T21:31:56Z,boozook,NA https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-04T11:44:54Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-04T11:44:56Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-05T16:28:26Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-06T02:13:21Z,zicklag,zicklag@katharostech.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HOORAY,2019-06-06T05:44:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57967,MERGED,2019-01-29T09:09:59Z,2019-05-31T20:02:11Z,Introduce Rust symbol mangling scheme.,eddyb,3652ea4594918d5f4c7e7a073d3e3105c726d1ef,3,test: add a more complex symbol-name testcase.,HEART,2019-06-07T19:13:59Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/57978,MERGED,2019-01-29T22:22:29Z,2019-02-01T23:43:50Z,Fix bug in integer range matching,varkor,cd1047e0d45619f1d668bfbf6cccbbf6396335be,2,Fix bug in integer range matching,HEART,2019-01-30T03:04:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/57978,MERGED,2019-01-29T22:22:29Z,2019-02-01T23:43:50Z,Fix bug in integer range matching,varkor,cd1047e0d45619f1d668bfbf6cccbbf6396335be,2,Fix bug in integer range matching,HEART,2019-01-31T00:29:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/57978,MERGED,2019-01-29T22:22:29Z,2019-02-01T23:43:50Z,Fix bug in integer range matching,varkor,cd1047e0d45619f1d668bfbf6cccbbf6396335be,2,Fix bug in integer range matching,HEART,2019-02-01T08:38:48Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/57978,MERGED,2019-01-29T22:22:29Z,2019-02-01T23:43:50Z,Fix bug in integer range matching,varkor,cd1047e0d45619f1d668bfbf6cccbbf6396335be,2,Fix bug in integer range matching,HEART,2019-02-06T22:17:13Z,frol,NA https://github.com/rust-lang/rust/pull/57978,MERGED,2019-01-29T22:22:29Z,2019-02-01T23:43:50Z,Fix bug in integer range matching,varkor,cd1047e0d45619f1d668bfbf6cccbbf6396335be,2,Fix bug in integer range matching,HEART,2019-02-07T15:08:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/57984,MERGED,2019-01-30T06:33:51Z,2019-01-31T06:31:53Z,Improve bug message in check_ty,phansch,037fdb8213da90f3fe26f78b1e415b86f59b0185,1,Improve bug message in check_ty This branch was hit in Clippy and I think it would be nice to show the thing that was unexpected in the bug message. It's also in line with the other `bug!` messages in `check_ty`.,HEART,2019-01-31T11:53:41Z,mati865,NA https://github.com/rust-lang/rust/pull/57987,MERGED,2019-01-30T08:13:41Z,2019-03-28T12:12:22Z,Fix some AArch64 typos,parched,62c159e500dac61dd6f20c8a50f1b1570ed481ee,1,Fix missing cfg for aarch64 + ios in ffi.rs,HEART,2019-02-25T18:59:06Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-01-30T10:42:10Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-01-30T14:10:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-03T14:14:49Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-05T08:52:56Z,cramertj,NA https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-07T18:27:49Z,taiki-e,NA https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-20T14:45:48Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-21T09:15:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-02-21T13:16:08Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/57992,MERGED,2019-01-30T09:37:35Z,2019-02-14T07:07:21Z,Update the future/task API,Matthias247,871338c3aed87cb84f02ebd7fd9b447966d5b05d,1347,Merging master,HOORAY,2019-03-13T08:29:44Z,broomstar,NA https://github.com/rust-lang/rust/pull/57997,MERGED,2019-01-30T13:23:00Z,2019-02-22T16:32:46Z,Wrap write_bytes in a function. Move docs,nitnelave,26bd43355f839f6005910056e89b2364b7fec06a,1,Move the intrinsics into a submodule,HEART,2019-01-31T02:57:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-01-30T17:50:25Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-01-31T02:51:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-01-31T09:35:40Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-02-04T13:35:08Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-02-06T21:24:18Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-02-06T21:54:38Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-02-07T15:08:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58003,MERGED,2019-01-30T17:21:13Z,2019-01-31T16:21:58Z,Use LLVM intrinsics for saturating add/sub,nikic,4a4186e4d1168f9faf3df019596bcf87f0a4dc2b,5,Use LLVM intrinsics for saturating add/sub,HEART,2019-02-15T19:01:35Z,terence-dickson-thalmic,NA https://github.com/rust-lang/rust/pull/58005,MERGED,2019-01-30T18:13:43Z,2019-01-31T06:31:55Z,update docs for fix_start/end_matches,vitiral,4a3caca978042b3d1f6700a5dce757414992a714,1,fix #57686: update docs for fix_start/end_matches,THUMBS_UP,2019-01-31T06:33:42Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58012,CLOSED,2019-01-30T20:42:36Z,2019-02-12T18:00:32Z,Add riscv64imc-unknown-none-elf target,fintelia,NA,NA,NA,HEART,2019-01-30T22:45:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58012,CLOSED,2019-01-30T20:42:36Z,2019-02-12T18:00:32Z,Add riscv64imc-unknown-none-elf target,fintelia,NA,NA,NA,HEART,2019-02-02T13:02:40Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/58013,MERGED,2019-01-30T20:54:28Z,2019-03-08T08:39:26Z,Create a derive macro for HashStable and allow proc macros in rustc,Zoxc,f2ef283b7265a35ee4b6e250e1160ba28b33953a,2,Make Cargo a rustc tool again,HOORAY,2019-02-17T15:57:31Z,mati865,NA https://github.com/rust-lang/rust/pull/58013,MERGED,2019-01-30T20:54:28Z,2019-03-08T08:39:26Z,Create a derive macro for HashStable and allow proc macros in rustc,Zoxc,f2ef283b7265a35ee4b6e250e1160ba28b33953a,2,Make Cargo a rustc tool again,HOORAY,2019-03-14T06:29:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-01-31T02:51:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-01-31T03:43:18Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-02-14T14:27:26Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-02-14T17:40:22Z,jplatte,NA https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-02-27T14:11:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58015,MERGED,2019-01-31T00:48:32Z,2019-03-12T22:15:13Z,Expand docs for `TryFrom` and `TryInto`.,icefoxen,db99a3bccdc21e80d832b061defe1002527c1c46,1,Remove stabilized feature gate in doctest,HEART,2019-02-28T09:00:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T07:33:26Z,retep998,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T10:03:36Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T11:33:54Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T15:27:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T15:33:31Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T16:06:48Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T18:23:44Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T18:57:47Z,estebank,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-01-31T19:02:44Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-02-01T11:46:43Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HOORAY,2019-02-04T20:38:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HOORAY,2019-03-19T01:59:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HOORAY,2019-03-29T01:36:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58019,MERGED,2019-01-31T03:41:41Z,2019-03-29T11:20:59Z,Combine all builtin late lints and make lint checking parallel,Zoxc,dee389f749ebe2b6a80e08550ccd8aa8e5a1f019,2,Run module lint passes in parallel,HEART,2019-03-29T01:36:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58021,MERGED,2019-01-31T09:30:15Z,2019-03-11T20:09:30Z,Fix fallout from #57667,ishitatsuyuki,a03e20db6d15fe1cdda64c0fbe934e36209a08f6,1,Fix fallout from #57667,THUMBS_UP,2019-01-31T11:11:51Z,coronelargie,NA https://github.com/rust-lang/rust/pull/58024,MERGED,2019-01-31T13:12:40Z,2019-02-03T23:53:33Z,submodule: update rls from c9d25b to f331ff7,h-michael,6e72077b3b01aa33accf4925bd6faf701e322194,2,submodule: update rls from c9d25b667a to f331ff7,THUMBS_UP,2019-01-31T13:14:59Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/58033,MERGED,2019-01-31T20:33:23Z,2019-02-07T17:41:27Z,rustdoc: wrap stability tags in colored spans,euclio,ea2b1b035b3aa2e0e464dabb0e46f6c2092d357f,6,rustdoc: wrap stability tags in colored spans,THUMBS_UP,2019-02-07T12:10:34Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58044,MERGED,2019-02-01T08:36:30Z,2019-02-20T12:59:44Z,Make overflowing and wrapping negation const,Lokathor,e06302fda90dedd814c15f0517b98416b11cc204,2,fix the build errors,HEART,2019-02-01T09:21:22Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58044,MERGED,2019-02-01T08:36:30Z,2019-02-20T12:59:44Z,Make overflowing and wrapping negation const,Lokathor,e06302fda90dedd814c15f0517b98416b11cc204,2,fix the build errors,HEART,2019-02-01T10:32:49Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/58044,MERGED,2019-02-01T08:36:30Z,2019-02-20T12:59:44Z,Make overflowing and wrapping negation const,Lokathor,e06302fda90dedd814c15f0517b98416b11cc204,2,fix the build errors,HEART,2019-02-01T16:58:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/58044,MERGED,2019-02-01T08:36:30Z,2019-02-20T12:59:44Z,Make overflowing and wrapping negation const,Lokathor,e06302fda90dedd814c15f0517b98416b11cc204,2,fix the build errors,HEART,2019-02-03T19:08:10Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/58044,MERGED,2019-02-01T08:36:30Z,2019-02-20T12:59:44Z,Make overflowing and wrapping negation const,Lokathor,e06302fda90dedd814c15f0517b98416b11cc204,2,fix the build errors,HEART,2019-02-28T05:16:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-01T23:58:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-03T22:12:03Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-04T20:32:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-05T01:53:19Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-12T05:16:56Z,green-s,sam.green81@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-12T17:47:33Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-13T17:05:16Z,tux3,NA https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-13T21:38:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-14T05:26:13Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-14T09:24:56Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-15T19:54:02Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-02-16T19:29:57Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,ROCKET,2019-02-18T03:55:58Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-04-09T05:29:59Z,nicklauri,NA https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,ROCKET,2019-04-11T12:18:48Z,ejpcmac,jean-philippe@cugnet.eu https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-04-12T19:54:30Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2019-05-20T07:09:59Z,yajirobee,secret.heart.ks@gmail.com https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,ROCKET,2019-07-30T08:36:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,HEART,2021-02-27T04:06:37Z,Be-ing,NA https://github.com/rust-lang/rust/pull/58057,MERGED,2019-02-01T16:31:13Z,2019-02-13T07:46:41Z,Stabilize linker-plugin based LTO (aka cross-language LTO),michaelwoerister,3a9d171b0a118d8f0ecda1bf44775ec4ba9bb79d,1,Fix some rebasing fallout regarding xLTO.,ROCKET,2021-02-27T04:06:37Z,Be-ing,NA https://github.com/rust-lang/rust/pull/58059,MERGED,2019-02-01T18:54:35Z,2019-02-23T00:15:52Z,deprecate before_exec in favor of unsafe pre_exec,RalfJung,e023403da2da17ba7320c53c415b960c93348247,2,POSIX requires async signal safety for fork in signal handlers not in general,THUMBS_UP,2019-02-01T18:56:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58062,MERGED,2019-02-01T23:00:08Z,2019-02-03T11:40:31Z,Rename iter::unfold to iter::from_fn and remove explicit state,SimonSapin,61e92b586b550fc46d0d8b83f711b27f937ca87f,2,Rename iter::unfold to iter::from_fn and remove explicit state This API is unstable. CC https://github.com/rust-lang/rust/issues/55977#issuecomment-459657195,THUMBS_UP,2019-02-01T23:03:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58062,MERGED,2019-02-01T23:00:08Z,2019-02-03T11:40:31Z,Rename iter::unfold to iter::from_fn and remove explicit state,SimonSapin,61e92b586b550fc46d0d8b83f711b27f937ca87f,2,Rename iter::unfold to iter::from_fn and remove explicit state This API is unstable. CC https://github.com/rust-lang/rust/issues/55977#issuecomment-459657195,THUMBS_UP,2019-02-06T21:52:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58074,MERGED,2019-02-02T09:11:14Z,2019-02-17T10:14:04Z,Stabilize slice_sort_by_cached_key,scottmcm,317f15304e6091a1f3cc58c52d36df037ef50db0,2,"Revert ""Remove mentions of unstable sort_by_cached key from stable documentation"" This reverts commit 9c7b69e17909ceb090a1c4b8882a4e0924a2a755.",THUMBS_UP,2019-02-06T18:55:46Z,frol,NA https://github.com/rust-lang/rust/pull/58079,MERGED,2019-02-02T14:41:34Z,2019-02-03T03:11:56Z,hir: add HirId to main Hir nodes,ljedrz,55ef78e885f0f7a15237fff7cb204fa65a526aac,24,hir: add HirId to main Hir nodes,HEART,2019-02-02T15:11:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/58079,MERGED,2019-02-02T14:41:34Z,2019-02-03T03:11:56Z,hir: add HirId to main Hir nodes,ljedrz,55ef78e885f0f7a15237fff7cb204fa65a526aac,24,hir: add HirId to main Hir nodes,HEART,2019-02-02T17:22:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58079,MERGED,2019-02-02T14:41:34Z,2019-02-03T03:11:56Z,hir: add HirId to main Hir nodes,ljedrz,55ef78e885f0f7a15237fff7cb204fa65a526aac,24,hir: add HirId to main Hir nodes,HEART,2019-02-02T18:55:26Z,varkor,NA https://github.com/rust-lang/rust/pull/58079,MERGED,2019-02-02T14:41:34Z,2019-02-03T03:11:56Z,hir: add HirId to main Hir nodes,ljedrz,55ef78e885f0f7a15237fff7cb204fa65a526aac,24,hir: add HirId to main Hir nodes,HEART,2019-02-02T20:08:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58081,MERGED,2019-02-02T16:53:57Z,2019-02-03T21:19:58Z,Transition liballoc to Rust 2018,Centril,2396780cdaedf097dd6a8f3927749bcaf5b1238b,34,liballoc: revert nested imports style changes.,HOORAY,2019-02-02T19:54:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58081,MERGED,2019-02-02T16:53:57Z,2019-02-03T21:19:58Z,Transition liballoc to Rust 2018,Centril,2396780cdaedf097dd6a8f3927749bcaf5b1238b,34,liballoc: revert nested imports style changes.,HOORAY,2019-02-03T01:47:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/58081,MERGED,2019-02-02T16:53:57Z,2019-02-03T21:19:58Z,Transition liballoc to Rust 2018,Centril,2396780cdaedf097dd6a8f3927749bcaf5b1238b,34,liballoc: revert nested imports style changes.,HEART,2019-02-03T01:47:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/58081,MERGED,2019-02-02T16:53:57Z,2019-02-03T21:19:58Z,Transition liballoc to Rust 2018,Centril,2396780cdaedf097dd6a8f3927749bcaf5b1238b,34,liballoc: revert nested imports style changes.,HOORAY,2019-02-03T01:48:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/58085,MERGED,2019-02-02T23:00:26Z,2019-02-10T13:55:12Z,Implement more detailed self profiling,wesleywiser,584081af4a386e9ef2e03684f1f3f1466b3996d1,1,Calculate self-times not total times,THUMBS_UP,2019-02-05T07:36:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58085,MERGED,2019-02-02T23:00:26Z,2019-02-10T13:55:12Z,Implement more detailed self profiling,wesleywiser,584081af4a386e9ef2e03684f1f3f1466b3996d1,1,Calculate self-times not total times,THUMBS_UP,2019-02-14T06:01:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58087,CLOSED,2019-02-03T03:03:28Z,2019-02-03T15:03:59Z,[WIP] Transition some crates to Rust 2018,Centril,NA,NA,NA,HEART,2019-02-03T03:05:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/58090,MERGED,2019-02-03T08:57:50Z,2019-02-04T04:00:54Z,HirIdification: add key HirId methods,ljedrz,272f4dfff6d0a6ae172e3efbef7d563ea088f6fd,2,hir: remove Definitions::hir_to_def_index,HEART,2019-02-03T16:00:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/58090,MERGED,2019-02-03T08:57:50Z,2019-02-04T04:00:54Z,HirIdification: add key HirId methods,ljedrz,272f4dfff6d0a6ae172e3efbef7d563ea088f6fd,2,hir: remove Definitions::hir_to_def_index,HOORAY,2019-02-03T21:44:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/58090,MERGED,2019-02-03T08:57:50Z,2019-02-04T04:00:54Z,HirIdification: add key HirId methods,ljedrz,272f4dfff6d0a6ae172e3efbef7d563ea088f6fd,2,hir: remove Definitions::hir_to_def_index,HOORAY,2019-02-07T15:12:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58098,MERGED,2019-02-03T13:16:41Z,2019-02-12T15:08:48Z,Require a list of features in `#[allow_internal_unstable]`,oli-obk,bbe524d7c1a1028737a93c7c71c508a68363b681,3,Parallel rustc needs synchronizing smart pointer cloning,HEART,2019-02-03T13:42:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58098,MERGED,2019-02-03T13:16:41Z,2019-02-12T15:08:48Z,Require a list of features in `#[allow_internal_unstable]`,oli-obk,bbe524d7c1a1028737a93c7c71c508a68363b681,3,Parallel rustc needs synchronizing smart pointer cloning,HEART,2019-02-04T00:03:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58098,MERGED,2019-02-03T13:16:41Z,2019-02-12T15:08:48Z,Require a list of features in `#[allow_internal_unstable]`,oli-obk,bbe524d7c1a1028737a93c7c71c508a68363b681,3,Parallel rustc needs synchronizing smart pointer cloning,HEART,2019-02-04T21:17:02Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/58098,MERGED,2019-02-03T13:16:41Z,2019-02-12T15:08:48Z,Require a list of features in `#[allow_internal_unstable]`,oli-obk,bbe524d7c1a1028737a93c7c71c508a68363b681,3,Parallel rustc needs synchronizing smart pointer cloning,THUMBS_UP,2019-02-08T09:22:11Z,kennytm,NA https://github.com/rust-lang/rust/pull/58103,MERGED,2019-02-03T14:13:31Z,2019-02-10T11:19:08Z,Make -Zdump-mir dump shims,RalfJung,544b3a1bb476364f1e5d149cf82beb98a219dda5,23,fix rebase fallout,THUMBS_UP,2022-03-24T11:48:41Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/58118,MERGED,2019-02-03T15:57:16Z,2019-02-07T09:48:56Z,Transition libtest to 2018 edition,h-michael,3c6787306d6b7a45e3b76f18ce543be700fb3c00,1,Excute rustfmt for fixing tidy check,ROCKET,2019-02-04T20:24:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58118,MERGED,2019-02-03T15:57:16Z,2019-02-07T09:48:56Z,Transition libtest to 2018 edition,h-michael,3c6787306d6b7a45e3b76f18ce543be700fb3c00,1,Excute rustfmt for fixing tidy check,ROCKET,2019-02-05T11:04:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HEART,2019-02-03T19:54:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HOORAY,2019-02-25T07:21:57Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HOORAY,2019-02-27T13:02:53Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HOORAY,2019-02-28T05:05:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HOORAY,2019-02-28T12:03:04Z,frol,NA https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HOORAY,2020-02-09T11:02:54Z,Boscop,NA https://github.com/rust-lang/rust/pull/58122,MERGED,2019-02-03T16:24:22Z,2019-02-23T17:00:25Z,RangeInclusive internal iteration performance improvement.,matthieu-m,4fed67f94220351ffa60de1dca078c02a7c15734,2,Fix exhaustion of inclusive range try_fold and try_rfold,HEART,2020-02-09T11:03:00Z,Boscop,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-03T19:51:54Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-04T00:02:32Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-04T00:59:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-04T19:43:27Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-04T22:31:56Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-05T04:51:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-13T20:42:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58123,MERGED,2019-02-03T16:25:45Z,2019-02-07T09:48:58Z,Avoid some bounds checks in binary_heap::{PeekMut Hole},lnicola,ea72066f5c0cc93ea7efe73396eb691724fccaaf,1,Avoid some bounds checks in binary_heap::{PeekMut Hole},THUMBS_UP,2019-02-14T05:59:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58124,MERGED,2019-02-03T16:48:42Z,2019-02-07T09:48:58Z,libsyntax_pos => 2018,taiki-e,6413480adf6bc788e515a9746cf382e1ceb153fe,7,libsyntax_pos => 2018,ROCKET,2019-02-04T20:24:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58124,MERGED,2019-02-03T16:48:42Z,2019-02-07T09:48:58Z,libsyntax_pos => 2018,taiki-e,6413480adf6bc788e515a9746cf382e1ceb153fe,7,libsyntax_pos => 2018,ROCKET,2019-02-05T11:15:22Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58125,MERGED,2019-02-03T19:42:13Z,2019-02-07T04:26:34Z,libsyntax => 2018,taiki-e,7bb082d27fe472f52b103de0ae9fc6fa7e6546cc,46,libsyntax => 2018,ROCKET,2019-02-04T20:24:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58125,MERGED,2019-02-03T19:42:13Z,2019-02-07T04:26:34Z,libsyntax => 2018,taiki-e,7bb082d27fe472f52b103de0ae9fc6fa7e6546cc,46,libsyntax => 2018,ROCKET,2019-02-05T11:18:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58128,MERGED,2019-02-03T21:03:51Z,2019-02-05T19:12:03Z,libunwind => 2018,taiki-e,5440149229068ef202af1b59846d123a24e4c62f,3,libunwind => 2018,ROCKET,2019-02-04T20:23:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58128,MERGED,2019-02-03T21:03:51Z,2019-02-05T19:12:03Z,libunwind => 2018,taiki-e,5440149229068ef202af1b59846d123a24e4c62f,3,libunwind => 2018,ROCKET,2019-02-05T12:03:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58133,MERGED,2019-02-04T00:11:17Z,2019-02-07T09:48:59Z,libsyntax_ext => 2018,taiki-e,94f121ff3f47fecdcf458b691f1bf87f8b1f1f1d,35,libsyntax_ext => 2018,ROCKET,2019-02-04T20:23:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58133,MERGED,2019-02-04T00:11:17Z,2019-02-07T09:48:59Z,libsyntax_ext => 2018,taiki-e,94f121ff3f47fecdcf458b691f1bf87f8b1f1f1d,35,libsyntax_ext => 2018,ROCKET,2019-02-05T12:03:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58138,MERGED,2019-02-04T09:06:07Z,2019-02-05T19:12:04Z,Fix #58101,ishitatsuyuki,652f2c753aed97261f5d988f0a2b50aa6508964c,2,Add test,THUMBS_UP,2019-02-05T19:18:43Z,bjorn3,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,THUMBS_UP,2019-02-04T16:13:30Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,THUMBS_UP,2019-02-04T16:24:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,HEART,2019-02-04T16:24:53Z,panaman67,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,HEART,2019-02-05T00:32:20Z,estebank,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,THUMBS_UP,2019-02-10T18:50:32Z,mati865,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,THUMBS_UP,2019-02-14T07:21:51Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/58140,MERGED,2019-02-04T10:20:32Z,2019-03-15T17:39:04Z,Refactor ppaux out of existence.,eddyb,dbf19c3975a014861535b775b2fb7cd71e6c5042,2,rustbuild: remove obsolete fulldeps behavior from src/test/pretty tests and enable them by default.,THUMBS_UP,2019-02-27T10:07:49Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58143,MERGED,2019-02-04T11:43:07Z,2019-02-07T17:41:32Z,Sort elements in the sidebar,GuillaumeGomez,c40fa3271a939ee34662482052be64929978ca6a,1,sort elements in the sidebar,CONFUSED,2019-02-04T12:45:06Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/58166,MERGED,2019-02-04T18:50:32Z,2019-02-13T07:46:44Z,allow shorthand syntax for deprecation reason,euclio,113b7f7be15c49fcd0854ca53486e92f1badfdd6,8,allow shorthand syntax for deprecation reason,THUMBS_UP,2019-02-05T09:09:40Z,estebank,NA https://github.com/rust-lang/rust/pull/58167,MERGED,2019-02-04T19:02:52Z,2019-02-14T01:17:34Z,HirId-ify hir::BodyId,ljedrz,eac43ccda4858e5415822a3a31bffb029cb0ed2b,35,HirId-ify hir::BodyId,THUMBS_UP,2019-02-04T22:36:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/58167,MERGED,2019-02-04T19:02:52Z,2019-02-14T01:17:34Z,HirId-ify hir::BodyId,ljedrz,eac43ccda4858e5415822a3a31bffb029cb0ed2b,35,HirId-ify hir::BodyId,HEART,2019-02-04T22:36:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/58173,CLOSED,2019-02-05T00:11:54Z,2019-02-08T11:43:10Z,Change privacy checks particularly for tuple structs,estebank,NA,NA,NA,HEART,2019-02-05T00:37:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58180,MERGED,2019-02-05T08:08:06Z,2019-02-12T03:20:35Z,Fix span for closure return type when annotated.,davidtwco,b377d0b14ce141b8ce6c9bb22c22b1fb12d8232f,3,Fix span for closure return type when annotated. This commit adjusts the span used to label closure return types so that if the user specifies the return type i.e. `|_| -> X {}` instead of `|_| {}` we correctly highlight all of it and not just the last character.,THUMBS_UP,2019-02-05T09:05:19Z,estebank,NA https://github.com/rust-lang/rust/pull/58183,MERGED,2019-02-05T11:27:48Z,2019-02-24T09:44:44Z,Clarify guarantees for `Box` allocation,jethrogb,e41e694d9e5a6bcb2109c936df9757879a65eb59,2,Clarify guarantees for `Box` allocation,THUMBS_UP,2019-02-06T23:31:15Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/58186,MERGED,2019-02-05T14:34:54Z,2019-02-05T19:12:11Z,Add Rustlings to the doc index,komaeda,014ffa3ac9e499fc0c3f03b7e902be6d819d02f3,1,Add Rustlings to the doc index,HEART,2019-02-05T14:49:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58186,MERGED,2019-02-05T14:34:54Z,2019-02-05T19:12:11Z,Add Rustlings to the doc index,komaeda,014ffa3ac9e499fc0c3f03b7e902be6d819d02f3,1,Add Rustlings to the doc index,HEART,2019-02-05T16:39:06Z,carols10cents,NA https://github.com/rust-lang/rust/pull/58186,MERGED,2019-02-05T14:34:54Z,2019-02-05T19:12:11Z,Add Rustlings to the doc index,komaeda,014ffa3ac9e499fc0c3f03b7e902be6d819d02f3,1,Add Rustlings to the doc index,THUMBS_UP,2019-02-05T17:38:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58187,CLOSED,2019-02-05T14:49:02Z,2019-03-18T14:21:35Z,Remove EraseRegionsVisitor since mir implements TypeFoldable,spastorino,NA,NA,NA,THUMBS_UP,2019-02-05T14:56:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/58187,CLOSED,2019-02-05T14:49:02Z,2019-03-18T14:21:35Z,Remove EraseRegionsVisitor since mir implements TypeFoldable,spastorino,NA,NA,NA,HEART,2019-02-05T14:56:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T16:39:35Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T16:43:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T16:50:42Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T17:51:20Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T17:57:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T18:07:36Z,jplatte,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-05T18:21:33Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-05T18:47:35Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T18:47:36Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T18:51:58Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T20:17:56Z,darksv,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-05T20:53:15Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-06T02:28:42Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-06T08:59:45Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-06T09:08:58Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-06T09:32:33Z,lqd,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-06T09:38:24Z,qwerty19106,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-06T09:53:03Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-06T12:32:56Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-06T14:15:18Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-06T14:15:18Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-06T14:15:23Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-06T16:43:23Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-07T14:35:52Z,AlexNav73,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-07T22:57:41Z,teiesti,tobias.stolzmann@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-08T03:26:45Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-08T03:27:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-08T03:39:21Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-08T04:17:03Z,kupiakos,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-08T06:57:29Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-08T08:42:45Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-08T09:02:32Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-08T09:26:10Z,hovind,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-08T09:26:11Z,hovind,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-08T09:26:12Z,hovind,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-08T13:01:40Z,zroug,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-11T12:15:33Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-11T13:57:44Z,jrr45,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-12T12:40:32Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-12T12:40:32Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-12T12:40:33Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-13T15:16:20Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-13T15:52:53Z,Selicre,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-13T16:21:36Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-13T18:12:50Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-13T18:13:46Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-13T20:28:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-13T21:02:58Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-13T21:03:00Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-14T03:54:32Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-14T05:14:29Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-14T05:14:30Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-14T05:14:30Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-14T06:00:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,THUMBS_UP,2019-02-15T02:44:57Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-15T02:44:58Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,ROCKET,2019-02-15T02:45:00Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58191,MERGED,2019-02-05T16:02:46Z,2019-02-08T08:37:48Z,Add const generics to the AST,varkor,f2fe71c02ac7ecb29106b1a826d657ff5705ad6c,13,Resolve incorrect diagnostic for using a non-const value in a constant,HOORAY,2019-02-15T18:51:41Z,mtak-,NA https://github.com/rust-lang/rust/pull/58192,MERGED,2019-02-05T16:55:43Z,2019-02-07T09:49:03Z,Do not ICE in codegen when using a extern_type static,dlrobertson,80c052bed76d7b7406e956747012bc8a929fe909,4,Do not ICE in codegen given a extern_type static The layout of a extern_type static is unsized but may pass the Well-Formed check in typeck. As a result we cannot assume that a static is sized when generating the `Place` for an r-value.,THUMBS_UP,2019-02-07T10:03:17Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58193,MERGED,2019-02-05T17:29:07Z,2019-02-07T09:49:04Z,Move librustc to 2018,mark-i-m,e957ed9d10ec589bdd523b88b4b44c41b1ecf763,179,move librustc to 2018,THUMBS_UP,2019-02-05T20:56:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58198,MERGED,2019-02-05T20:59:55Z,2019-02-23T00:15:55Z,Suggest removing parentheses surrounding lifetimes,igorsdv,f753d304c6c5d7f2c10147d783d58db7db4ffc4c,2,Suggest removing parentheses surrounding lifetimes,HEART,2019-02-18T19:22:16Z,estebank,NA https://github.com/rust-lang/rust/pull/58198,MERGED,2019-02-05T20:59:55Z,2019-02-23T00:15:55Z,Suggest removing parentheses surrounding lifetimes,igorsdv,f753d304c6c5d7f2c10147d783d58db7db4ffc4c,2,Suggest removing parentheses surrounding lifetimes,HEART,2019-02-28T05:06:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58199,MERGED,2019-02-05T21:01:10Z,2019-02-23T17:00:27Z,Add better error message for partial move,clintfred,02fe6a7ba6b0d1733c9abbe40ac85c26bba38403,6,./x.py test src/test/ui --stage 1 --bless -i --compare-mode=nll,THUMBS_UP,2019-02-05T21:03:08Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/58199,MERGED,2019-02-05T21:01:10Z,2019-02-23T17:00:27Z,Add better error message for partial move,clintfred,02fe6a7ba6b0d1733c9abbe40ac85c26bba38403,6,./x.py test src/test/ui --stage 1 --bless -i --compare-mode=nll,THUMBS_UP,2019-02-06T09:39:53Z,estebank,NA https://github.com/rust-lang/rust/pull/58199,MERGED,2019-02-05T21:01:10Z,2019-02-23T17:00:27Z,Add better error message for partial move,clintfred,02fe6a7ba6b0d1733c9abbe40ac85c26bba38403,6,./x.py test src/test/ui --stage 1 --bless -i --compare-mode=nll,THUMBS_UP,2019-02-28T10:47:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58200,MERGED,2019-02-05T21:13:47Z,2019-02-13T07:46:45Z,fix str mutating through a ptr derived from &self,RalfJung,66c894e07f95a324a39bb4c281c8db4c8842689b,1,also fix bad use of shared ref in split_at_mut,THUMBS_UP,2019-07-21T04:04:53Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/58200,MERGED,2019-02-05T21:13:47Z,2019-02-13T07:46:45Z,fix str mutating through a ptr derived from &self,RalfJung,66c894e07f95a324a39bb4c281c8db4c8842689b,1,also fix bad use of shared ref in split_at_mut,THUMBS_UP,2020-12-06T05:01:41Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/58203,MERGED,2019-02-05T22:34:12Z,2019-02-11T01:05:49Z,rustdoc: display sugared return types for async functions,euclio,4deb5959a3a2cbc189e26cb4b0c59a6707a10b45,4,display sugared return types for async functions,HOORAY,2019-02-11T08:19:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-06T08:31:13Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-06T11:11:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-06T17:33:50Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-09T11:39:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-09T15:18:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58207,MERGED,2019-02-06T01:52:21Z,2019-02-09T15:12:12Z,Make `intern_lazy_const` actually intern its argument.,nnethercote,f2871a9ce552cd21b1c7b8df69eefe06af6d59da,17,"Make `intern_lazy_const` actually intern its argument. Currently it just unconditionally allocates it in the arena. For a ""Clean Check"" build of the the `packed-simd` benchmark this change reduces both the `max-rss` and `faults` counts by 59%; it slightly (~3%) increases the instruction counts but the `wall-time` is unchanged. For the same builds of a few other benchmarks `max-rss` and `faults` drop by 1--5% but instruction counts and `wall-time` changes are in the noise. Fixes #57432 fixes #57829.",HEART,2019-02-14T06:03:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-06T04:53:42Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-06T16:43:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-14T07:27:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-14T14:59:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-15T06:39:32Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/58208,MERGED,2019-02-06T04:02:18Z,2019-02-28T14:31:40Z,libstd => 2018,taiki-e,aad9e29f52988c55cd8cee2bd181a2e3c9d436a4,4,Fix rebase fail,ROCKET,2019-02-18T13:56:29Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/58210,MERGED,2019-02-06T08:07:17Z,2019-02-07T09:49:06Z,Make an assert debug-only in `find_constraint_paths_between_regions`.,nnethercote,f7ed6e18160bc8fccf27a73c05f3935c9e8f672e,1,Make an assert debug-only in `find_constraint_paths_between_regions`. This reduces instruction counts for NLL builds of `wg-grammar` by over 20%.,HEART,2019-02-06T20:39:31Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58210,MERGED,2019-02-06T08:07:17Z,2019-02-07T09:49:06Z,Make an assert debug-only in `find_constraint_paths_between_regions`.,nnethercote,f7ed6e18160bc8fccf27a73c05f3935c9e8f672e,1,Make an assert debug-only in `find_constraint_paths_between_regions`. This reduces instruction counts for NLL builds of `wg-grammar` by over 20%.,HEART,2019-02-07T10:23:27Z,estebank,NA https://github.com/rust-lang/rust/pull/58210,MERGED,2019-02-06T08:07:17Z,2019-02-07T09:49:06Z,Make an assert debug-only in `find_constraint_paths_between_regions`.,nnethercote,f7ed6e18160bc8fccf27a73c05f3935c9e8f672e,1,Make an assert debug-only in `find_constraint_paths_between_regions`. This reduces instruction counts for NLL builds of `wg-grammar` by over 20%.,HEART,2020-11-19T20:24:39Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-06T14:08:33Z,killercup,NA https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-06T14:22:27Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-06T14:38:47Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-06T14:49:37Z,estebank,NA https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-06T15:31:06Z,mati865,NA https://github.com/rust-lang/rust/pull/58221,CLOSED,2019-02-06T14:03:44Z,2019-03-03T16:53:55Z, multiple substitutions become multiple children in JSON output,zackmdavis,NA,NA,NA,HEART,2019-02-15T00:52:11Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/58227,MERGED,2019-02-06T14:47:11Z,2019-02-23T17:00:28Z,Updated RELEASES.md for 1.33.0,XAMPPRocky,fda51c2fbd0c646af5c5356dba2ad59d2c8ea8f8,1,Update RELEASES.md,HEART,2019-02-07T00:25:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58227,MERGED,2019-02-06T14:47:11Z,2019-02-23T17:00:28Z,Updated RELEASES.md for 1.33.0,XAMPPRocky,fda51c2fbd0c646af5c5356dba2ad59d2c8ea8f8,1,Update RELEASES.md,HEART,2019-02-07T18:23:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58227,MERGED,2019-02-06T14:47:11Z,2019-02-23T17:00:28Z,Updated RELEASES.md for 1.33.0,XAMPPRocky,fda51c2fbd0c646af5c5356dba2ad59d2c8ea8f8,1,Update RELEASES.md,HEART,2019-02-11T15:30:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58232,MERGED,2019-02-06T15:43:00Z,2019-02-24T03:08:26Z,HirId-ify intravisit,ljedrz,404e6435d0bbe3d4baf2e37bd225530d60bed6a7,1,update clippy: partially HirIdify,HEART,2019-02-06T16:33:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/58232,MERGED,2019-02-06T15:43:00Z,2019-02-24T03:08:26Z,HirId-ify intravisit,ljedrz,404e6435d0bbe3d4baf2e37bd225530d60bed6a7,1,update clippy: partially HirIdify,HEART,2019-02-21T23:22:36Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58242,MERGED,2019-02-06T19:27:13Z,2019-02-07T09:49:12Z,Document the one TyKind that isn't documented,notriddle,5db385064e26202d71dc3801dee8a41a6ce28a9b,1,Document the one TyKind that isn't documented This is especially confusing since the name `Foreign` and the name `extern type` are so different. I deduced that they're the same by consulting git-blame.,HEART,2019-02-06T21:04:11Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58250,MERGED,2019-02-06T23:18:37Z,2019-02-28T23:58:37Z,Introduce rustc_interface and move some methods there,Zoxc,23a51f91c928a4ff2cbf39218e6e991365e5f562,29,Introduce rustc_interface and move some methods there,HEART,2019-02-19T13:56:38Z,mati865,NA https://github.com/rust-lang/rust/pull/58250,MERGED,2019-02-06T23:18:37Z,2019-02-28T23:58:37Z,Introduce rustc_interface and move some methods there,Zoxc,23a51f91c928a4ff2cbf39218e6e991365e5f562,29,Introduce rustc_interface and move some methods there,HEART,2019-02-28T14:53:52Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58250,MERGED,2019-02-06T23:18:37Z,2019-02-28T23:58:37Z,Introduce rustc_interface and move some methods there,Zoxc,23a51f91c928a4ff2cbf39218e6e991365e5f562,29,Introduce rustc_interface and move some methods there,HEART,2019-02-28T21:27:13Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58262,MERGED,2019-02-07T10:47:38Z,2019-02-11T01:05:51Z,Add #[must_use] message to Fn* traits,taiki-e,1d05f81d19084be01a172205b091bbfe4dd4e5fa,1,Add #[must_use] message to Fn* traits,HEART,2019-02-07T11:55:23Z,estebank,NA https://github.com/rust-lang/rust/pull/58262,MERGED,2019-02-07T10:47:38Z,2019-02-11T01:05:51Z,Add #[must_use] message to Fn* traits,taiki-e,1d05f81d19084be01a172205b091bbfe4dd4e5fa,1,Add #[must_use] message to Fn* traits,HEART,2019-02-14T05:59:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58271,CLOSED,2019-02-07T15:19:23Z,2019-03-11T09:20:19Z,rustc_codegen_llvm: use opaque LLVM structs for `extern type`.,eddyb,NA,NA,NA,THUMBS_UP,2019-02-07T18:48:50Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58271,CLOSED,2019-02-07T15:19:23Z,2019-03-11T09:20:19Z,rustc_codegen_llvm: use opaque LLVM structs for `extern type`.,eddyb,NA,NA,NA,HEART,2019-02-08T10:04:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58271,CLOSED,2019-02-07T15:19:23Z,2019-03-11T09:20:19Z,rustc_codegen_llvm: use opaque LLVM structs for `extern type`.,eddyb,NA,NA,NA,THUMBS_UP,2019-02-13T15:08:09Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/58271,CLOSED,2019-02-07T15:19:23Z,2019-03-11T09:20:19Z,rustc_codegen_llvm: use opaque LLVM structs for `extern type`.,eddyb,NA,NA,NA,THUMBS_UP,2019-02-13T15:31:24Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/58272,MERGED,2019-02-07T16:07:47Z,2019-02-14T01:17:37Z,Cut down on number formating code size,fitzgen,f00f0e676887c8970858897836aa1e8a81d8aa60,1,Don't shadow the provided `stringify!` macro in a wasm code size test case,HEART,2019-02-14T08:48:32Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/58272,MERGED,2019-02-07T16:07:47Z,2019-02-14T01:17:37Z,Cut down on number formating code size,fitzgen,f00f0e676887c8970858897836aa1e8a81d8aa60,1,Don't shadow the provided `stringify!` macro in a wasm code size test case,HEART,2019-02-20T15:12:43Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/58272,MERGED,2019-02-07T16:07:47Z,2019-02-14T01:17:37Z,Cut down on number formating code size,fitzgen,f00f0e676887c8970858897836aa1e8a81d8aa60,1,Don't shadow the provided `stringify!` macro in a wasm code size test case,HEART,2019-02-21T05:12:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58272,MERGED,2019-02-07T16:07:47Z,2019-02-14T01:17:37Z,Cut down on number formating code size,fitzgen,f00f0e676887c8970858897836aa1e8a81d8aa60,1,Don't shadow the provided `stringify!` macro in a wasm code size test case,HEART,2019-02-21T13:13:44Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58273,MERGED,2019-02-07T16:40:39Z,2019-02-13T07:46:48Z,Rename rustc_errors dependency in rust 2018 crates,taiki-e,c08b5ca4ad26250f6af17ba7e2938d9e694f2842,1,Fix rebase fail,THUMBS_UP,2019-02-07T16:53:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/58273,MERGED,2019-02-07T16:40:39Z,2019-02-13T07:46:48Z,Rename rustc_errors dependency in rust 2018 crates,taiki-e,c08b5ca4ad26250f6af17ba7e2938d9e694f2842,1,Fix rebase fail,THUMBS_UP,2019-02-10T04:26:15Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,THUMBS_UP,2019-02-08T11:30:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-04-12T02:05:20Z,estebank,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,THUMBS_UP,2019-06-19T23:48:52Z,chmln,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-06-19T23:48:54Z,chmln,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-07-09T16:35:36Z,lqd,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-08-20T07:56:36Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-08-20T23:29:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/58281,MERGED,2019-02-08T03:19:19Z,2019-11-19T01:16:54Z,Add outlives suggestions for some lifetime errors,mark-i-m,cba0761e5f3677b90390fe7aee1eeda684296658,134,update tests,HEART,2019-12-02T20:08:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58293,MERGED,2019-02-08T08:46:16Z,2019-02-17T10:14:09Z,Remove code for updating copyright years in generate-deriving-span-tests,xfix,df420aa783f7f6e89d9004552db4d7625c3beb0f,1,Remove initial newline from automatically generated span tests This change was accidentally introduced while removing license headers.,HEART,2019-02-08T16:08:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/58295,MERGED,2019-02-08T10:43:09Z,2019-02-11T01:05:53Z,std::sys::unix::stdio: explain why we do into_raw,RalfJung,541503afa13a4ea8596755e0e88e6dd13a95faa5,1,std::sys::unix::stdio: explain why we do into_raw,THUMBS_UP,2019-02-08T13:35:43Z,pitdicker,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-11T21:43:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-02-13T13:18:00Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-13T15:04:04Z,TedDriggs,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-13T16:06:02Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-13T16:37:20Z,stevenlr,steven.lerouzic@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-02-13T16:44:16Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-02-13T21:22:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-14T00:06:40Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-02-14T17:22:53Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-15T18:21:48Z,kaj,kaj@kth.se https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-02-17T10:06:41Z,pyfisch,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-20T12:32:57Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-20T23:55:47Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-22T10:34:38Z,kirushik,kirill@parity.io https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-22T18:33:29Z,aschampion,andrew.champion@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-27T13:42:45Z,ravern,ravernkoh@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-27T20:56:00Z,sunjay,NA https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-02-28T05:12:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-03-01T02:50:32Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-03-01T08:55:54Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,HOORAY,2019-03-11T08:37:51Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/58302,MERGED,2019-02-08T14:08:30Z,2019-02-25T23:23:23Z,Stabilize TryFrom and TryInto with a convert::Infallible empty enum,SimonSapin,cf267540ebabdeac1f2045819cd6bac561017e29,1,Review comments,ROCKET,2019-04-09T08:48:18Z,florianjacob,NA https://github.com/rust-lang/rust/pull/58305,MERGED,2019-02-08T14:39:52Z,2019-03-24T17:53:53Z,(WIP) Small fixes in chalkification,scalexm,ca5a2122cc68fa14e72f1631ee5e9bbf2ac9c94f,1,expand the fixme,HEART,2019-02-08T14:48:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58305,MERGED,2019-02-08T14:39:52Z,2019-03-24T17:53:53Z,(WIP) Small fixes in chalkification,scalexm,ca5a2122cc68fa14e72f1631ee5e9bbf2ac9c94f,1,expand the fixme,HEART,2019-02-08T16:03:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/58305,MERGED,2019-02-08T14:39:52Z,2019-03-24T17:53:53Z,(WIP) Small fixes in chalkification,scalexm,ca5a2122cc68fa14e72f1631ee5e9bbf2ac9c94f,1,expand the fixme,HEART,2019-02-10T07:41:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58309,MERGED,2019-02-08T16:23:29Z,2019-02-14T13:35:05Z,Add more profiler events,wesleywiser,e9ebc2e9561d285b0e9991943a834da18cb65c1f,1,[self-profiler] Misc cleanups,THUMBS_UP,2019-02-08T17:33:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58309,MERGED,2019-02-08T16:23:29Z,2019-02-14T13:35:05Z,Add more profiler events,wesleywiser,e9ebc2e9561d285b0e9991943a834da18cb65c1f,1,[self-profiler] Misc cleanups,THUMBS_UP,2019-02-09T11:26:54Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58313,MERGED,2019-02-08T18:43:47Z,2019-02-12T08:20:03Z,Use `?` in librustc macros,matthewjasper,0a16b8754abe419f8541788c1092e4ef91fcf137,2,Use ? in librustc macros,THUMBS_UP,2019-02-09T05:24:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58313,MERGED,2019-02-08T18:43:47Z,2019-02-12T08:20:03Z,Use `?` in librustc macros,matthewjasper,0a16b8754abe419f8541788c1092e4ef91fcf137,2,Use ? in librustc macros,THUMBS_UP,2019-02-09T07:12:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/58313,MERGED,2019-02-08T18:43:47Z,2019-02-12T08:20:03Z,Use `?` in librustc macros,matthewjasper,0a16b8754abe419f8541788c1092e4ef91fcf137,2,Use ? in librustc macros,HOORAY,2019-02-10T12:07:02Z,RalfJung,NA https://github.com/rust-lang/rust/pull/58315,MERGED,2019-02-08T20:14:46Z,2019-02-24T17:12:27Z,Implement unstable ffi_return_twice attribute,gnzlbg,94aa74004efddf0cfb6fe4bb65eee9effbe40ae8,3,Use E0724 instead of E0723 as an error code,HEART,2019-02-08T22:08:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58315,MERGED,2019-02-08T20:14:46Z,2019-02-24T17:12:27Z,Implement unstable ffi_return_twice attribute,gnzlbg,94aa74004efddf0cfb6fe4bb65eee9effbe40ae8,3,Use E0724 instead of E0723 as an error code,HEART,2019-02-09T01:26:19Z,comex,NA https://github.com/rust-lang/rust/pull/58315,MERGED,2019-02-08T20:14:46Z,2019-02-24T17:12:27Z,Implement unstable ffi_return_twice attribute,gnzlbg,94aa74004efddf0cfb6fe4bb65eee9effbe40ae8,3,Use E0724 instead of E0723 as an error code,HEART,2019-02-13T09:59:44Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58315,MERGED,2019-02-08T20:14:46Z,2019-02-24T17:12:27Z,Implement unstable ffi_return_twice attribute,gnzlbg,94aa74004efddf0cfb6fe4bb65eee9effbe40ae8,3,Use E0724 instead of E0723 as an error code,HEART,2021-08-04T15:06:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/58318,MERGED,2019-02-09T08:37:07Z,2019-02-12T08:20:03Z,libserialize => 2018,taiki-e,06b63046b298fad478e69007ee207396bc1a9a2d,3,Cleanup imports,THUMBS_UP,2019-02-09T08:57:28Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58327,CLOSED,2019-02-09T19:11:26Z,2019-08-04T07:53:08Z,Experimentally add `ffi_const` and `ffi_pure` extern fn attributes,gnzlbg,NA,NA,NA,HEART,2019-02-09T20:31:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58333,CLOSED,2019-02-09T21:38:40Z,2019-04-29T17:28:17Z,Lift TypeFoldable over Result and remove the Relate hack in combine/nll,arielb1,NA,NA,NA,THUMBS_UP,2019-02-13T03:43:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/58347,MERGED,2019-02-10T12:09:20Z,2019-02-14T13:35:06Z,Closure bounds fixes,matthewjasper,79e8c311765df4c35558aa9683f1e2004719175a,3,Propagate region constraints more precisely from closures,HEART,2019-02-10T12:22:43Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58347,MERGED,2019-02-10T12:09:20Z,2019-02-14T13:35:06Z,Closure bounds fixes,matthewjasper,79e8c311765df4c35558aa9683f1e2004719175a,3,Propagate region constraints more precisely from closures,HEART,2019-02-12T10:41:32Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-10T23:05:11Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-11T02:34:39Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-11T02:52:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-12T20:10:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-21T06:58:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58357,MERGED,2019-02-10T17:29:48Z,2019-02-26T05:48:13Z,Add vectored read and write support,sfackler,4785c748f2190440fb3f90b5319f121f2d31e0e4,1,Fix redox,THUMBS_UP,2019-02-26T15:55:38Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58359,MERGED,2019-02-10T18:30:03Z,2019-02-17T10:14:13Z,librustc_mir: use ? in impl_snapshot_for! macro,taiki-e,6156defd516aad7002fb88f3003cd549fca9f084,1,librustc_mir: use ? in impl_snapshot_for! macro,ROCKET,2019-02-12T18:30:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58364,CLOSED,2019-02-10T23:01:12Z,2019-04-03T19:55:20Z,Add variant/struct field search tab,GuillaumeGomez,NA,NA,NA,HEART,2019-02-12T19:42:59Z,estebank,NA https://github.com/rust-lang/rust/pull/58364,CLOSED,2019-02-10T23:01:12Z,2019-04-03T19:55:20Z,Add variant/struct field search tab,GuillaumeGomez,NA,NA,NA,HEART,2019-02-18T15:39:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58370,MERGED,2019-02-11T11:02:11Z,2019-02-25T06:27:55Z,Relax some Hash bounds on HashMap and HashSet,nox,d9e2259d659dfd3abd931bf6e1c4eb54d101a8f7,4,Relax some Hash bounds on HashMap and HashSet Notably hash iterators don't require any trait bounds to be iterated.,HEART,2019-02-12T11:48:03Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/58370,MERGED,2019-02-11T11:02:11Z,2019-02-25T06:27:55Z,Relax some Hash bounds on HashMap and HashSet,nox,d9e2259d659dfd3abd931bf6e1c4eb54d101a8f7,4,Relax some Hash bounds on HashMap and HashSet Notably hash iterators don't require any trait bounds to be iterated.,HEART,2019-02-28T05:03:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58370,MERGED,2019-02-11T11:02:11Z,2019-02-25T06:27:55Z,Relax some Hash bounds on HashMap and HashSet,nox,d9e2259d659dfd3abd931bf6e1c4eb54d101a8f7,4,Relax some Hash bounds on HashMap and HashSet Notably hash iterators don't require any trait bounds to be iterated.,HEART,2019-02-28T10:57:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58373,MERGED,2019-02-11T14:26:40Z,2019-02-18T05:36:39Z,update stdsimd and remove now-unused MaybeUninit::into_inner,RalfJung,aba0d29320a49cc8c62b02168da4dabd1c332a03,1,update stdsimd,HEART,2019-02-11T21:17:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58373,MERGED,2019-02-11T14:26:40Z,2019-02-18T05:36:39Z,update stdsimd and remove now-unused MaybeUninit::into_inner,RalfJung,aba0d29320a49cc8c62b02168da4dabd1c332a03,1,update stdsimd,HEART,2019-02-13T23:57:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-11T21:18:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-11T23:18:53Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-12T03:58:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-12T16:03:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",ROCKET,2019-02-12T18:11:36Z,fitzgen,NA https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-12T20:08:59Z,cramertj,NA https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-15T23:17:28Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-20T12:21:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-20T15:37:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-21T05:11:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-21T13:11:28Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-21T15:03:05Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/58378,MERGED,2019-02-11T17:41:04Z,2019-02-14T13:35:09Z,"rustc: Implement incremental ""fat"" LTO",alexcrichton,e983b4f64ee6d919a60938b6e7371a66877f4a23,8,"rustc: Implement incremental ""fat"" LTO Currently the compiler will produce an error if both incremental compilation and full fat LTO is requested. With recent changes and the advent of incremental ThinLTO however all the hard work is already done for us and it's actually not too bad to remove this error! This commit updates the codegen backend to allow incremental full fat LTO. The semantics are that the input modules to LTO are all produce incrementally but the final LTO step is always done unconditionally regardless of whether the inputs changed or not. The only real incremental win we could have here is if zero of the input modules changed but that's so rare it's unlikely to be worthwhile to implement such a code path. cc #57968 cc rust-lang/cargo#6643",HOORAY,2019-02-24T20:47:00Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/58380,MERGED,2019-02-11T17:57:39Z,2019-03-04T07:40:54Z,Point at enum definition when match patterns are not exhaustive,estebank,d651281a71b7d31947e33383dcb2a5647827e0fb,2,Reword error message,THUMBS_UP,2019-02-20T00:53:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58381,MERGED,2019-02-11T18:31:06Z,2019-02-14T01:17:44Z,Only suggest imports if not imported.,davidtwco,48b0c9da69965cd40d037cee42cf3093ed09c6ee,5,Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant.,HEART,2019-02-11T19:29:07Z,estebank,NA https://github.com/rust-lang/rust/pull/58381,MERGED,2019-02-11T18:31:06Z,2019-02-14T01:17:44Z,Only suggest imports if not imported.,davidtwco,48b0c9da69965cd40d037cee42cf3093ed09c6ee,5,Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant.,HEART,2019-02-12T18:44:02Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/58384,MERGED,2019-02-11T23:19:25Z,2019-02-20T12:59:52Z,Fix tables display,GuillaumeGomez,b53305df7fab08aac7255fc4fa44eebbcfe222ac,3,Fix tables display,THUMBS_UP,2019-02-12T00:10:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/58392,MERGED,2019-02-12T07:01:31Z,2019-02-20T12:59:53Z,Use less explicit shifting in std::net::ip,scottmcm,5d8058477e9f3a6bbff696b97ae2c06ccbd9133f,1,Use less explicit shifting in std::net::ip Now that we have {to|from}_be_bytes the code can be simpler. (Inspired by PR #57740),THUMBS_UP,2019-02-12T09:10:29Z,ondj,NA https://github.com/rust-lang/rust/pull/58392,MERGED,2019-02-12T07:01:31Z,2019-02-20T12:59:53Z,Use less explicit shifting in std::net::ip,scottmcm,5d8058477e9f3a6bbff696b97ae2c06ccbd9133f,1,Use less explicit shifting in std::net::ip Now that we have {to|from}_be_bytes the code can be simpler. (Inspired by PR #57740),THUMBS_UP,2019-02-12T09:40:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/58392,MERGED,2019-02-12T07:01:31Z,2019-02-20T12:59:53Z,Use less explicit shifting in std::net::ip,scottmcm,5d8058477e9f3a6bbff696b97ae2c06ccbd9133f,1,Use less explicit shifting in std::net::ip Now that we have {to|from}_be_bytes the code can be simpler. (Inspired by PR #57740),THUMBS_UP,2019-02-18T16:49:02Z,TheBiggerGuy,github.profile@thebiggerguy.com https://github.com/rust-lang/rust/pull/58395,MERGED,2019-02-12T08:01:40Z,2019-02-17T10:14:14Z,Instant::checked_duration_since,vi,91f67fd1a75d7cc1b1ac5fc957ff30f16d01232e,1,Add Instant::saturating_duration_since,THUMBS_UP,2019-02-12T10:52:49Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HEART,2019-02-12T14:00:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,ROCKET,2019-02-12T14:00:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HEART,2019-02-12T14:37:20Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HOORAY,2019-02-12T14:37:24Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,ROCKET,2019-02-12T14:42:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HEART,2019-02-12T14:42:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HOORAY,2019-02-12T14:42:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,ROCKET,2019-02-12T16:03:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HEART,2019-02-12T21:35:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,ROCKET,2019-10-19T13:12:26Z,hugecheese,NA https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HEART,2019-10-19T13:12:27Z,hugecheese,NA https://github.com/rust-lang/rust/pull/58403,MERGED,2019-02-12T13:51:46Z,2019-02-15T15:04:40Z,"rustc_mir: split qualify_consts' ""value qualification"" bitflags into separate computations.",eddyb,f04424acd1bf894d1dc930c2a347871ea8b96dfa,3,rustc_mir: compute all the qualification bits separately in qualify_consts.,HOORAY,2019-10-19T13:12:27Z,hugecheese,NA https://github.com/rust-lang/rust/pull/58406,MERGED,2019-02-12T17:27:27Z,2019-02-15T19:06:01Z,Add riscv64{imac gc}-unknown-none-elf targets,Disasm,1f1a82434b0d8679dbaaab8c2dd53c78d30a8c8c,4,Add riscv64gc-unknown-none-elf target,HOORAY,2019-02-13T07:36:06Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58406,MERGED,2019-02-12T17:27:27Z,2019-02-15T19:06:01Z,Add riscv64{imac gc}-unknown-none-elf targets,Disasm,1f1a82434b0d8679dbaaab8c2dd53c78d30a8c8c,4,Add riscv64gc-unknown-none-elf target,HOORAY,2019-02-14T13:26:52Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58406,MERGED,2019-02-12T17:27:27Z,2019-02-15T19:06:01Z,Add riscv64{imac gc}-unknown-none-elf targets,Disasm,1f1a82434b0d8679dbaaab8c2dd53c78d30a8c8c,4,Add riscv64gc-unknown-none-elf target,HOORAY,2019-02-14T22:51:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58406,MERGED,2019-02-12T17:27:27Z,2019-02-15T19:06:01Z,Add riscv64{imac gc}-unknown-none-elf targets,Disasm,1f1a82434b0d8679dbaaab8c2dd53c78d30a8c8c,4,Add riscv64gc-unknown-none-elf target,HOORAY,2019-02-15T20:36:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58407,MERGED,2019-02-12T17:41:15Z,2019-02-14T13:35:11Z,"specify ""upper camel case"" in style lint",euclio,2f95299f6bf87a7b23381cda954570e72c80c159,8,"specify ""upper camel case"" in style lint Also fix an issue where internal upper case letters were converted to lower case.",THUMBS_UP,2019-02-13T18:06:39Z,estebank,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-12T18:55:50Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-12T19:19:30Z,fitzgen,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-12T19:51:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-12T20:42:10Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-13T00:38:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-13T01:47:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-13T03:58:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-13T08:59:44Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-02-13T09:32:54Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-03-01T21:18:31Z,mati865,NA https://github.com/rust-lang/rust/pull/58408,MERGED,2019-02-12T18:54:34Z,2019-03-01T05:17:34Z,rustc: Update LLVM remove dead wasm code,alexcrichton,320640060f38957028141ea30bc4d5577d1e53b0,4,Whitelist containers that allow older toolchains We'll use this as a temporary measure to get an LLVM update landed but we'll have to go through and update images later to make sure they've got the right toolchains.,HOORAY,2019-03-16T14:09:38Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58421,MERGED,2019-02-13T11:24:39Z,2019-02-25T06:27:56Z,Relax some Ord bounds on BinaryHeap,nox,ac32359f085875837007b575a7b52339df017a7b,1,Relax some Ord bounds on BinaryHeap Notably iterators don't require any trait bounds to be iterated.,THUMBS_UP,2019-02-25T08:24:49Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/58421,MERGED,2019-02-13T11:24:39Z,2019-02-25T06:27:56Z,Relax some Ord bounds on BinaryHeap,nox,ac32359f085875837007b575a7b52339df017a7b,1,Relax some Ord bounds on BinaryHeap Notably iterators don't require any trait bounds to be iterated.,THUMBS_UP,2019-02-28T01:10:53Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/58421,MERGED,2019-02-13T11:24:39Z,2019-02-25T06:27:56Z,Relax some Ord bounds on BinaryHeap,nox,ac32359f085875837007b575a7b52339df017a7b,1,Relax some Ord bounds on BinaryHeap Notably iterators don't require any trait bounds to be iterated.,THUMBS_UP,2019-02-28T05:03:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58421,MERGED,2019-02-13T11:24:39Z,2019-02-25T06:27:56Z,Relax some Ord bounds on BinaryHeap,nox,ac32359f085875837007b575a7b52339df017a7b,1,Relax some Ord bounds on BinaryHeap Notably iterators don't require any trait bounds to be iterated.,THUMBS_UP,2019-02-28T10:56:00Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-02-13T11:45:57Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-02-13T17:06:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,HEART,2019-02-13T17:06:39Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-02-14T14:50:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-02-14T18:28:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-03-14T00:51:28Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,HEART,2019-03-14T00:51:29Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-03-15T00:25:46Z,tux3,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-03-15T18:52:01Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,HEART,2019-03-20T14:25:20Z,chrish42,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-03-20T15:54:40Z,andre-vm,NA https://github.com/rust-lang/rust/pull/58422,MERGED,2019-02-13T11:28:53Z,2019-03-21T17:44:34Z,Add provided methods `Seek::{stream_len stream_position}`,LukasKalbertodt,f95219fa580a514b5ca6c1425335afadbe394b57,1,Apply suggestions from code review Fix typos in the documentation Co-Authored-By: LukasKalbertodt ,THUMBS_UP,2019-03-27T17:54:29Z,DianaNites,NA https://github.com/rust-lang/rust/pull/58431,MERGED,2019-02-13T16:55:14Z,2019-02-23T00:16:00Z,fix overlapping references in BTree,RalfJung,f0bef49cf10c19b72b7d025aedb407ab5745c365,2,fix invalidating references in BTree iterators,HEART,2019-02-28T10:54:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58431,MERGED,2019-02-13T16:55:14Z,2019-02-23T00:16:00Z,fix overlapping references in BTree,RalfJung,f0bef49cf10c19b72b7d025aedb407ab5745c365,2,fix invalidating references in BTree iterators,HEART,2019-02-28T19:37:09Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/58431,MERGED,2019-02-13T16:55:14Z,2019-02-23T00:16:00Z,fix overlapping references in BTree,RalfJung,f0bef49cf10c19b72b7d025aedb407ab5745c365,2,fix invalidating references in BTree iterators,HEART,2019-03-04T13:31:26Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/58438,MERGED,2019-02-13T20:32:02Z,2019-02-17T10:14:17Z,Use posix_spawn_file_actions_addchdir_np when possible,cuviper,a301655c8aed20e5cea9a062663820fc29c5e80c,1,Use posix_spawn_file_actions_addchdir_np when possible This is a non-POSIX extension implemented in Solaris and in glibc 2.29. With this we can still use `posix_spawn()` when `Command::current_dir()` has been set otherwise we fallback to `fork(); chdir(); exec()`.,THUMBS_UP,2019-02-13T21:50:28Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-02-15T00:27:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-02-16T22:28:51Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-03-03T13:40:54Z,jeehoonkang,jeehoon.kang@kaist.ac.kr https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-04-01T18:10:05Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-04-29T03:31:40Z,breezewish,breezewish@pingcap.com https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-05-06T09:12:42Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-07-02T14:29:58Z,fredpointzero,frederic.vauchelles@gmail.com https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-07-10T05:19:45Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/58457,CLOSED,2019-02-14T08:07:51Z,2019-11-28T06:23:14Z,Associate an allocator to boxes,glandium,NA,NA,NA,HOORAY,2019-09-13T05:36:58Z,Avi-D-coder,avi.the.coder@gmail.com https://github.com/rust-lang/rust/pull/58464,MERGED,2019-02-14T12:42:17Z,2019-03-03T05:51:57Z,Use the correct stderr when testing libstd,jethrogb,c0e8cf94103289c424c62ca48e1e3f56e352a84a,4,Use the correct stderr when testing libstd,THUMBS_UP,2019-02-14T18:29:34Z,188716218,NA https://github.com/rust-lang/rust/pull/58466,CLOSED,2019-02-14T17:28:18Z,2019-02-17T12:11:28Z,tidy: Accept CC0-1.0 license,mati865,NA,NA,NA,THUMBS_UP,2019-02-15T06:00:29Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58468,MERGED,2019-02-14T19:10:45Z,2019-02-17T10:14:20Z,split MaybeUninit into several features expand docs a bit,RalfJung,95ef9b4fc28ad2f5db078eb1ae233fd5be76806b,3,make Centril happy,HOORAY,2019-02-14T19:17:35Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/58468,MERGED,2019-02-14T19:10:45Z,2019-02-17T10:14:20Z,split MaybeUninit into several features expand docs a bit,RalfJung,95ef9b4fc28ad2f5db078eb1ae233fd5be76806b,3,make Centril happy,HOORAY,2019-02-15T00:03:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58468,MERGED,2019-02-14T19:10:45Z,2019-02-17T10:14:20Z,split MaybeUninit into several features expand docs a bit,RalfJung,95ef9b4fc28ad2f5db078eb1ae233fd5be76806b,3,make Centril happy,HEART,2019-02-15T01:57:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58476,MERGED,2019-02-15T03:47:06Z,2019-02-23T17:00:34Z,Remove `LazyTokenStream`.,nnethercote,895a79423bf5298e13a177ee6317f43380d437bc,1,Remove some unnecessary `into()` calls. These are probably leftovers from recent `TokenStream` simplifications.,HEART,2019-02-15T06:11:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/58476,MERGED,2019-02-15T03:47:06Z,2019-02-23T17:00:34Z,Remove `LazyTokenStream`.,nnethercote,895a79423bf5298e13a177ee6317f43380d437bc,1,Remove some unnecessary `into()` calls. These are probably leftovers from recent `TokenStream` simplifications.,THUMBS_UP,2019-02-15T06:11:17Z,panaman67,NA https://github.com/rust-lang/rust/pull/58476,MERGED,2019-02-15T03:47:06Z,2019-02-23T17:00:34Z,Remove `LazyTokenStream`.,nnethercote,895a79423bf5298e13a177ee6317f43380d437bc,1,Remove some unnecessary `into()` calls. These are probably leftovers from recent `TokenStream` simplifications.,HEART,2019-02-15T06:26:07Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/58476,MERGED,2019-02-15T03:47:06Z,2019-02-23T17:00:34Z,Remove `LazyTokenStream`.,nnethercote,895a79423bf5298e13a177ee6317f43380d437bc,1,Remove some unnecessary `into()` calls. These are probably leftovers from recent `TokenStream` simplifications.,THUMBS_UP,2019-02-28T05:07:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58488,MERGED,2019-02-15T13:36:31Z,2019-03-14T12:09:21Z,Replace TimeLine LLVM profiling with the self profiler,wesleywiser,4c8cc141863274683681a6fa3d5d4e0230780c66,12,Replace TimeLine with SelfProfiler,THUMBS_UP,2019-03-14T15:37:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-15T21:12:36Z,varkor,NA https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-15T21:13:46Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-15T22:24:45Z,estebank,NA https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-15T23:21:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-16T16:12:56Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58501,MERGED,2019-02-15T21:07:07Z,2019-02-16T03:46:43Z,[beta] Fix `attempted .def_id() on invalid def: NonMacroAttr(Builtin)`,oli-obk,81571bfac1e38af642a026b7ca033bc8a695e418,2,libpanic_unwind => 2018: fix ICEs.,THUMBS_UP,2019-02-17T14:58:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-15T22:55:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-15T23:09:42Z,ebarnard,eabarnard@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-16T06:26:48Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-17T00:32:09Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-17T05:38:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-18T01:11:41Z,qnighy,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-18T02:13:46Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-18T09:52:40Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-18T10:14:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-18T11:08:19Z,o01eg,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-20T00:24:56Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-27T13:39:41Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-27T23:06:47Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-28T01:09:08Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-02-28T05:02:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-03-01T18:12:57Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/58503,MERGED,2019-02-15T22:29:51Z,2019-02-19T03:28:38Z,Add const generics to the HIR,varkor,727e20410c61293f38b7f7984a469dc7daad632a,2,Add a test for const parameter uppercase lint,THUMBS_UP,2019-03-04T01:13:22Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/58505,MERGED,2019-02-16T01:22:22Z,2019-03-04T01:46:53Z,[NLL] Remove `LiveVar`,schomatis,ae5f7224b5ee08f9762befb26eccb8ad26cdbcbc,2,nll: remove `IdentityMap` and `LiveVariableMap` With `NllLivenessMap` and `LiveVar` removed the `IdentityMap` (remaining structure implementing the `LiveVariableMap` trait) loses its meaning. Specialize the `LiveVarSet` to a `BitSet` removing the `V` and related parameters. The `LiveVarSet` was only being used as `LiveVarSet` so this commit doesn't bring any change to the logic it just removes an unused parameter (that without `LiveVar` now it couldn't have been specialized to anything but `Local`).,HEART,2019-02-21T04:20:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/58505,MERGED,2019-02-16T01:22:22Z,2019-03-04T01:46:53Z,[NLL] Remove `LiveVar`,schomatis,ae5f7224b5ee08f9762befb26eccb8ad26cdbcbc,2,nll: remove `IdentityMap` and `LiveVariableMap` With `NllLivenessMap` and `LiveVar` removed the `IdentityMap` (remaining structure implementing the `LiveVariableMap` trait) loses its meaning. Specialize the `LiveVarSet` to a `BitSet` removing the `V` and related parameters. The `LiveVarSet` was only being used as `LiveVarSet` so this commit doesn't bring any change to the logic it just removes an unused parameter (that without `LiveVar` now it couldn't have been specialized to anything but `Local`).,THUMBS_UP,2019-03-08T06:05:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58526,MERGED,2019-02-17T02:05:41Z,2019-02-23T17:00:36Z,Special suggestion for illegal unicode curly quote pairs,pmccarter,71cd4c8e4af4a05991fef5a61110510c78d90131,2,ui test for directed quote help suggestion #58436,THUMBS_UP,2019-02-23T01:10:45Z,estebank,NA https://github.com/rust-lang/rust/pull/58534,MERGED,2019-02-17T10:24:58Z,2019-02-20T12:59:59Z,Mention capping forbid lints,dwijnand,8fbb013c1c0605a4738a6f5f5ec5b47550a2a5ec,1,Mention capping forbid lints I felt the description of forbid was misleading/incomplete without mentioning how --cap-lints interacts with it.,THUMBS_UP,2019-02-17T10:45:03Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/58534,MERGED,2019-02-17T10:24:58Z,2019-02-20T12:59:59Z,Mention capping forbid lints,dwijnand,8fbb013c1c0605a4738a6f5f5ec5b47550a2a5ec,1,Mention capping forbid lints I felt the description of forbid was misleading/incomplete without mentioning how --cap-lints interacts with it.,HEART,2019-02-19T20:45:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58543,MERGED,2019-02-17T17:17:16Z,2019-02-19T00:46:41Z,Bump the bootstrap compiler,jonas-schievink,1a0d800ef624057953c29cb14e9ea14cdf80158f,1,Bump the bootstrap compiler,THUMBS_UP,2019-02-17T17:26:49Z,fabric-and-ink,NA https://github.com/rust-lang/rust/pull/58553,MERGED,2019-02-18T03:44:36Z,2019-02-20T13:00:06Z,Use more impl header lifetime elision,scottmcm,3bea2ca49d24606920b3a81811379debc0668992,35,Use more impl header lifetime elision There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl Read for &mut R`) I omitted things that seemed like they could be more controversial like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.,HEART,2019-02-18T05:37:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/58553,MERGED,2019-02-18T03:44:36Z,2019-02-20T13:00:06Z,Use more impl header lifetime elision,scottmcm,3bea2ca49d24606920b3a81811379debc0668992,35,Use more impl header lifetime elision There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl Read for &mut R`) I omitted things that seemed like they could be more controversial like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.,HEART,2019-02-18T17:30:41Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/58553,MERGED,2019-02-18T03:44:36Z,2019-02-20T13:00:06Z,Use more impl header lifetime elision,scottmcm,3bea2ca49d24606920b3a81811379debc0668992,35,Use more impl header lifetime elision There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl Read for &mut R`) I omitted things that seemed like they could be more controversial like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.,HEART,2019-02-18T18:50:45Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58553,MERGED,2019-02-18T03:44:36Z,2019-02-20T13:00:06Z,Use more impl header lifetime elision,scottmcm,3bea2ca49d24606920b3a81811379debc0668992,35,Use more impl header lifetime elision There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl Read for &mut R`) I omitted things that seemed like they could be more controversial like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.,HEART,2019-02-19T19:46:03Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/58562,MERGED,2019-02-18T19:03:32Z,2019-02-20T13:00:07Z,Fix style nits,dlrobertson,f8b6449f80b75c8d42b1ebbe4c1fb6d4bfec7ace,16,Fix style nits Fix style nits discovered in reading code.,THUMBS_UP,2019-02-18T19:39:07Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/58565,MERGED,2019-02-18T23:26:52Z,2019-02-20T13:00:08Z,Fix typo in std::future::Future docs,thomaseizinger,75c541f228be5c76e2b81971b4f11fd537b83eee,1,Fix typo in std::future::Future docs,THUMBS_UP,2019-02-19T06:01:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58565,MERGED,2019-02-18T23:26:52Z,2019-02-20T13:00:08Z,Fix typo in std::future::Future docs,thomaseizinger,75c541f228be5c76e2b81971b4f11fd537b83eee,1,Fix typo in std::future::Future docs,HEART,2019-02-19T06:01:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,THUMBS_UP,2019-03-01T03:21:18Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,HOORAY,2019-03-08T16:22:27Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,HOORAY,2019-05-22T06:58:15Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,THUMBS_UP,2019-07-05T06:01:28Z,p-kraszewski,NA https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,HOORAY,2019-08-17T23:24:41Z,mcandre,NA https://github.com/rust-lang/rust/pull/58575,MERGED,2019-02-19T12:40:59Z,2019-03-15T13:58:18Z,Musl host toolchain,mati865,451343e0f3d90904bdc2080cc8bc4eb00be0364e,1,Fix TARGET variable in musl-toolchain.sh,THUMBS_UP,2019-08-17T23:24:43Z,mcandre,NA https://github.com/rust-lang/rust/pull/58577,CLOSED,2019-02-19T15:25:14Z,2019-03-21T23:50:09Z,improve worst-case performance of BTreeSet intersection v1,ssomers,NA,NA,NA,THUMBS_UP,2019-02-20T11:40:41Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-02-20T01:30:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-02-20T01:48:12Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-02-20T14:37:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-02-24T04:15:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HOORAY,2019-02-26T23:37:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-03-01T15:21:23Z,kbarros,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HOORAY,2019-03-01T15:21:25Z,kbarros,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-03-07T10:05:39Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HOORAY,2019-03-07T10:05:44Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HEART,2019-03-07T18:57:24Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-03-13T16:36:52Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HOORAY,2019-03-13T17:24:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HOORAY,2019-03-13T20:43:48Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,THUMBS_UP,2019-03-14T06:08:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58583,MERGED,2019-02-20T01:24:26Z,2019-03-07T03:29:13Z,Add const generics to ty (and transitive dependencies),varkor,de4478af91765999f51b2950bea16686ee4cd60a,1,Refactor const_to_op,HEART,2019-03-14T13:09:12Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/58584,MERGED,2019-02-20T02:00:27Z,2019-02-21T20:17:23Z,Update cargo,ehuss,158f074b08c5c53898679878827e735e3be8c0c0,1,Update cargo,THUMBS_UP,2019-02-20T12:57:01Z,mati865,NA https://github.com/rust-lang/rust/pull/58584,MERGED,2019-02-20T02:00:27Z,2019-02-21T20:17:23Z,Update cargo,ehuss,158f074b08c5c53898679878827e735e3be8c0c0,1,Update cargo,THUMBS_UP,2019-02-20T14:39:35Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58588,MERGED,2019-02-20T07:03:24Z,2019-02-23T00:16:05Z,remove a bit of dead code,matklad,abb07c42ecd364940c16ecd740116b847d7bcffc,1,remove a bit of dead code,LAUGH,2019-02-20T08:42:58Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58588,MERGED,2019-02-20T07:03:24Z,2019-02-23T00:16:05Z,remove a bit of dead code,matklad,abb07c42ecd364940c16ecd740116b847d7bcffc,1,remove a bit of dead code,LAUGH,2019-02-20T13:07:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58591,MERGED,2019-02-20T10:20:28Z,2019-02-23T00:16:06Z,Dedup a rustdoc diagnostic construction,dwijnand,ad096d1a0e82ecb1174d92ea08eb223d7dc0117a,1,Dedup a rustdoc diagnostic construction,THUMBS_UP,2019-02-20T16:21:21Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/58603,CLOSED,2019-02-20T19:18:27Z,2019-06-22T14:48:23Z,Add version switcher,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2019-02-21T02:31:28Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58603,CLOSED,2019-02-20T19:18:27Z,2019-06-22T14:48:23Z,Add version switcher,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2019-02-22T12:54:06Z,mati865,NA https://github.com/rust-lang/rust/pull/58603,CLOSED,2019-02-20T19:18:27Z,2019-06-22T14:48:23Z,Add version switcher,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2019-05-09T17:35:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58608,MERGED,2019-02-20T21:43:38Z,2019-03-12T15:34:07Z,Warning period for detecting nested impl trait,pnkfelix,0a03ca74935efab546298a8394a0ed0b31ccb646,1,Addressed review feedback regarding comment phrasing.,HEART,2019-02-21T07:01:51Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/58608,MERGED,2019-02-20T21:43:38Z,2019-03-12T15:34:07Z,Warning period for detecting nested impl trait,pnkfelix,0a03ca74935efab546298a8394a0ed0b31ccb646,1,Addressed review feedback regarding comment phrasing.,HEART,2019-03-07T02:26:45Z,estebank,NA https://github.com/rust-lang/rust/pull/58609,MERGED,2019-02-20T22:07:00Z,2019-02-23T17:00:39Z,Allow Self::Module to be mutated.,gabi-250,e5d1fa58f2dd5e86dd91f370313a4be85a39917a,2,codegen and write_metadata can mutate ModuleLLvm.,THUMBS_UP,2019-02-21T10:25:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58616,MERGED,2019-02-21T13:03:12Z,2019-02-22T04:11:52Z,Destabilize fixed-width const defined atomic integers,vertexclique,99d67ca3b801befd7a91d65f471f7335fdbd563e,1,Destabilize fixed-width const defined atomic integers * With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.,HEART,2019-02-21T18:43:14Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58616,MERGED,2019-02-21T13:03:12Z,2019-02-22T04:11:52Z,Destabilize fixed-width const defined atomic integers,vertexclique,99d67ca3b801befd7a91d65f471f7335fdbd563e,1,Destabilize fixed-width const defined atomic integers * With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.,HEART,2019-02-21T20:58:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58616,MERGED,2019-02-21T13:03:12Z,2019-02-22T04:11:52Z,Destabilize fixed-width const defined atomic integers,vertexclique,99d67ca3b801befd7a91d65f471f7335fdbd563e,1,Destabilize fixed-width const defined atomic integers * With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.,HEART,2019-02-22T09:56:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58616,MERGED,2019-02-21T13:03:12Z,2019-02-22T04:11:52Z,Destabilize fixed-width const defined atomic integers,vertexclique,99d67ca3b801befd7a91d65f471f7335fdbd563e,1,Destabilize fixed-width const defined atomic integers * With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.,HEART,2019-02-28T05:17:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58616,MERGED,2019-02-21T13:03:12Z,2019-02-22T04:11:52Z,Destabilize fixed-width const defined atomic integers,vertexclique,99d67ca3b801befd7a91d65f471f7335fdbd563e,1,Destabilize fixed-width const defined atomic integers * With this PR 1.34.0 onwards const declarations of atomic integers will be unstable.,HEART,2020-07-12T18:09:39Z,isidentical,batuhan@python.org https://github.com/rust-lang/rust/pull/58620,MERGED,2019-02-21T17:17:34Z,2019-02-23T00:16:09Z,introduce benchmarks of BTreeSet.intersection,ssomers,09a24545a848f0d89bb6464c2af730095b816618,2,introduce benchmarks of BTreeSet.intersection,THUMBS_UP,2019-02-21T22:12:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T21:07:38Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T21:07:38Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T21:10:46Z,MggMuggins,mggmugginsmc@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T21:11:04Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T21:19:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T21:22:07Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T21:25:18Z,mati865,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T21:25:19Z,mati865,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T21:55:54Z,ondj,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T22:02:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T22:02:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T22:12:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T22:13:45Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T22:13:50Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-21T23:15:32Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-21T23:15:33Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-22T01:05:51Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-22T03:35:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-22T03:35:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-02-22T03:41:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-22T05:14:41Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-22T07:50:12Z,killercup,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-02-22T16:53:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-22T19:39:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-23T08:14:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-23T08:14:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-24T10:10:25Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-02-25T11:33:40Z,magnet,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-25T16:12:41Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-02-25T16:12:43Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-02-25T16:12:45Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-02-25T16:12:46Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-28T10:48:59Z,hcpl,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-02-28T19:56:19Z,jviide,jviide@iki.fi https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-03-02T01:39:09Z,linouxis9,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-02T01:39:10Z,linouxis9,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-02T23:44:07Z,elahn,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-04T17:16:44Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-06T13:00:38Z,jplatte,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-03-08T16:14:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-03-08T16:14:30Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-03-09T11:40:07Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-10T04:23:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-03-20T09:12:38Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-03-27T22:00:06Z,akiekintveld,akiekintveld@icloud.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-03T17:14:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-03T17:14:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-03T21:44:59Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T08:33:26Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T09:43:07Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-05T09:43:08Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T09:43:16Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T10:36:35Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-05T10:36:37Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T11:12:01Z,KarboniteKream,klemen.kosir@kream.io https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T11:25:27Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T11:49:58Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T11:49:59Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T11:50:00Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-05T11:50:00Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T12:41:09Z,robatipoor,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T13:37:55Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T13:46:46Z,yannleretaille,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T14:09:16Z,lawliet89,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T15:10:24Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T15:34:26Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-05T15:34:29Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T16:26:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T16:39:56Z,anirudhb,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-05T16:39:56Z,anirudhb,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T16:39:58Z,anirudhb,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T17:03:28Z,sidcool1234,sidd.kulk@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T17:12:23Z,michael-grunder,michael.grunder@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-05T17:39:11Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T19:16:02Z,minijackson,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-05T19:36:30Z,tux3,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-05T23:58:35Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-06T06:56:16Z,hawkingrei,hawking.rei@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-06T07:56:38Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-06T16:42:24Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-07T14:47:26Z,yuche,i@yuche.me https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-07T22:35:47Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-08T05:42:17Z,greyblake,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-08T05:42:18Z,greyblake,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-09T23:49:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-11T17:08:03Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-16T06:27:41Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-16T06:27:44Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-18T18:06:07Z,Vurich,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-18T18:06:07Z,Vurich,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-21T19:06:11Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-21T19:06:12Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-21T19:06:13Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-21T19:06:13Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T03:19:07Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T04:15:41Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-24T04:15:42Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-24T04:15:49Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-24T04:15:51Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-24T04:53:26Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-24T06:00:46Z,lqd,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T07:06:44Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T08:22:28Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-24T08:22:30Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-24T08:22:32Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-24T08:22:34Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-04-24T08:38:10Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-04-24T09:35:36Z,Dentrax,furkan.turkal@hotmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-24T10:42:18Z,vittorioromeo,vittorio.romeo@outlook.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T12:19:10Z,kaigedong,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-04-24T13:27:42Z,gpahal,g10pahal@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-25T07:20:03Z,pczarn,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-04-26T20:24:06Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-05-02T02:51:52Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-05-02T03:03:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-05-02T04:31:57Z,frol,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-05-02T04:31:58Z,frol,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-05-02T04:31:59Z,frol,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-05-02T04:32:01Z,frol,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-05-03T07:29:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-05-03T13:04:06Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-05-06T11:28:02Z,SimSmith,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-06-28T14:20:51Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-06-28T14:20:53Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-06-28T14:20:55Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-06-28T14:20:56Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-07-04T15:40:57Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-07-05T14:24:34Z,Wenzel,mathieu.tarral@protonmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-07-05T14:24:36Z,Wenzel,mathieu.tarral@protonmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-07-07T21:19:56Z,anoadragon453,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2019-07-07T21:19:56Z,anoadragon453,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-07-07T21:19:57Z,anoadragon453,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-07-07T21:19:57Z,anoadragon453,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,ROCKET,2019-07-09T10:22:16Z,Object905,Object905@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2019-09-04T01:42:02Z,yuanbohan,yuanbo.han@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HEART,2019-09-25T21:34:52Z,lily-commure,NA https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,HOORAY,2020-02-03T22:15:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/58623,MERGED,2019-02-21T21:04:32Z,2019-04-24T03:13:44Z,Replace HashMap implementation with SwissTable (as an external crate),Amanieu,e7f162fdd8a5f45ee0c2869ee6a8afe7dba69248,2,Update hashbrown to 0.3.0,THUMBS_UP,2020-06-10T15:54:17Z,Folyd,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-02-22T03:43:56Z,maxdeviant,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HOORAY,2019-02-22T07:03:29Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-02-22T09:33:09Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-02-22T09:54:58Z,huxi,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HOORAY,2019-02-22T14:36:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-03-11T15:20:45Z,seanlinsley,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-03-14T01:39:00Z,kanru,kanru@kanru.info https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-03-14T04:05:34Z,dconnolly,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HOORAY,2019-03-14T06:29:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-03-14T23:30:41Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HOORAY,2019-03-14T23:30:43Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HEART,2019-03-15T07:04:03Z,elpiel,NA https://github.com/rust-lang/rust/pull/58626,MERGED,2019-02-21T22:14:02Z,2019-03-09T21:24:31Z,"rustdoc: add option to calculate ""documentation coverage""",QuietMisdreavus,3df0b895c1ba705bd4ecf110e3f6bdac7fe20953,1,only print coverage pass lists if running on nightly,HOORAY,2019-09-07T00:22:33Z,recmo,remco@wicked.ventures https://github.com/rust-lang/rust/pull/58628,MERGED,2019-02-22T00:20:05Z,2019-02-23T17:00:39Z,Optimise vec![false; N] to zero-alloc,RReverser,9f58c5fa7cf434dc6b19a961c4ec5a453e6dedcd,1,Optimise vec![false; N] to zero-alloc Nowadays booleans have a well-defined representation so there is no reason not to optimise their allocation.,HEART,2019-02-22T04:20:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58628,MERGED,2019-02-22T00:20:05Z,2019-02-23T17:00:39Z,Optimise vec![false; N] to zero-alloc,RReverser,9f58c5fa7cf434dc6b19a961c4ec5a453e6dedcd,1,Optimise vec![false; N] to zero-alloc Nowadays booleans have a well-defined representation so there is no reason not to optimise their allocation.,HEART,2019-02-22T09:49:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/58628,MERGED,2019-02-22T00:20:05Z,2019-02-23T17:00:39Z,Optimise vec![false; N] to zero-alloc,RReverser,9f58c5fa7cf434dc6b19a961c4ec5a453e6dedcd,1,Optimise vec![false; N] to zero-alloc Nowadays booleans have a well-defined representation so there is no reason not to optimise their allocation.,THUMBS_UP,2019-02-28T02:18:54Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/58628,MERGED,2019-02-22T00:20:05Z,2019-02-23T17:00:39Z,Optimise vec![false; N] to zero-alloc,RReverser,9f58c5fa7cf434dc6b19a961c4ec5a453e6dedcd,1,Optimise vec![false; N] to zero-alloc Nowadays booleans have a well-defined representation so there is no reason not to optimise their allocation.,THUMBS_UP,2019-02-28T05:06:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58630,MERGED,2019-02-22T02:37:09Z,2019-02-27T18:51:10Z,Make `visit_clobber` panic-safe.,nnethercote,eddd07cc8a92dd603e9884789fb58b2d3edd2e16,1,Make `visit_clobber` panic-safe.,THUMBS_UP,2019-02-22T04:44:11Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58632,MERGED,2019-02-22T08:08:13Z,2019-02-23T00:16:11Z,Make std feature list sorted,matklad,88d55f537ddf6630aafb2e7755ebd9831b8031c0,1,Make std feature list sorted This helps to avoid merge conflicts when concurrent PRs append features to the end of the list.,THUMBS_UP,2019-02-22T08:21:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58636,CLOSED,2019-02-22T10:33:07Z,2019-03-01T14:59:04Z,fs::copy() linux: handle sparse files and set file mode early,haraldh,NA,NA,NA,THUMBS_UP,2019-02-26T21:45:22Z,frol,NA https://github.com/rust-lang/rust/pull/58636,CLOSED,2019-02-22T10:33:07Z,2019-03-01T14:59:04Z,fs::copy() linux: handle sparse files and set file mode early,haraldh,NA,NA,NA,THUMBS_UP,2019-02-27T07:05:23Z,MrAwesome,NA https://github.com/rust-lang/rust/pull/58636,CLOSED,2019-02-22T10:33:07Z,2019-03-01T14:59:04Z,fs::copy() linux: handle sparse files and set file mode early,haraldh,NA,NA,NA,THUMBS_UP,2019-02-28T10:37:35Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58641,CLOSED,2019-02-22T12:43:21Z,2019-02-23T10:16:47Z,[BETA] Universe leak check,nikomatsakis,NA,NA,NA,HOORAY,2019-02-22T13:03:42Z,lqd,NA https://github.com/rust-lang/rust/pull/58660,MERGED,2019-02-22T21:25:03Z,2019-03-09T21:24:32Z,MaybeUninit: add read_initialized add examples,RalfJung,cefe9b09c120cfd8684fc2310ed2b295aafca01c,1,Apply suggestions from code review,HEART,2019-02-24T03:34:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/58660,MERGED,2019-02-22T21:25:03Z,2019-03-09T21:24:32Z,MaybeUninit: add read_initialized add examples,RalfJung,cefe9b09c120cfd8684fc2310ed2b295aafca01c,1,Apply suggestions from code review,HEART,2019-03-14T06:28:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58660,MERGED,2019-02-22T21:25:03Z,2019-03-09T21:24:32Z,MaybeUninit: add read_initialized add examples,RalfJung,cefe9b09c120cfd8684fc2310ed2b295aafca01c,1,Apply suggestions from code review,HEART,2019-03-14T09:41:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58675,MERGED,2019-02-23T17:16:23Z,2019-02-26T21:18:01Z,Update stdsimd,gnzlbg,2cf6e914aa4630fc06cb0a55d41d4364cee95682,1,Update stdsimd,THUMBS_UP,2019-02-23T17:22:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58675,MERGED,2019-02-23T17:16:23Z,2019-02-26T21:18:01Z,Update stdsimd,gnzlbg,2cf6e914aa4630fc06cb0a55d41d4364cee95682,1,Update stdsimd,THUMBS_UP,2019-02-23T17:50:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/58678,MERGED,2019-02-23T18:47:04Z,2019-02-27T18:51:12Z,Deny `async fn` in 2015 edition,doctorn,8300f51936149ec43eb063205e4d03c54a308f3c,22,Deny `async fn` in 2015 edition Fix style issues and update diagnostic messages Update src/librustc_passes/diagnostics.rs Co-Authored-By: doctorn Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition,HEART,2019-02-23T21:10:38Z,varkor,NA https://github.com/rust-lang/rust/pull/58678,MERGED,2019-02-23T18:47:04Z,2019-02-27T18:51:12Z,Deny `async fn` in 2015 edition,doctorn,8300f51936149ec43eb063205e4d03c54a308f3c,22,Deny `async fn` in 2015 edition Fix style issues and update diagnostic messages Update src/librustc_passes/diagnostics.rs Co-Authored-By: doctorn Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition,HEART,2019-02-24T03:39:53Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58678,MERGED,2019-02-23T18:47:04Z,2019-02-27T18:51:12Z,Deny `async fn` in 2015 edition,doctorn,8300f51936149ec43eb063205e4d03c54a308f3c,22,Deny `async fn` in 2015 edition Fix style issues and update diagnostic messages Update src/librustc_passes/diagnostics.rs Co-Authored-By: doctorn Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition,HEART,2019-02-24T07:41:02Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58678,MERGED,2019-02-23T18:47:04Z,2019-02-27T18:51:12Z,Deny `async fn` in 2015 edition,doctorn,8300f51936149ec43eb063205e4d03c54a308f3c,22,Deny `async fn` in 2015 edition Fix style issues and update diagnostic messages Update src/librustc_passes/diagnostics.rs Co-Authored-By: doctorn Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition,HEART,2019-02-25T22:33:52Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58679,MERGED,2019-02-23T18:54:35Z,2019-03-09T21:24:33Z,Refactor passes and pass execution to be more parallel,Zoxc,7985c6f8ecf680dcc960bb2ccc0c787274a449de,6,Rename check_privacy to check_private_in_public,HEART,2019-02-23T21:00:25Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58679,MERGED,2019-02-23T18:54:35Z,2019-03-09T21:24:33Z,Refactor passes and pass execution to be more parallel,Zoxc,7985c6f8ecf680dcc960bb2ccc0c787274a449de,6,Rename check_privacy to check_private_in_public,HOORAY,2019-02-23T21:00:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58679,MERGED,2019-02-23T18:54:35Z,2019-03-09T21:24:33Z,Refactor passes and pass execution to be more parallel,Zoxc,7985c6f8ecf680dcc960bb2ccc0c787274a449de,6,Rename check_privacy to check_private_in_public,HEART,2019-03-01T16:24:49Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58679,MERGED,2019-02-23T18:54:35Z,2019-03-09T21:24:33Z,Refactor passes and pass execution to be more parallel,Zoxc,7985c6f8ecf680dcc960bb2ccc0c787274a449de,6,Rename check_privacy to check_private_in_public,HEART,2019-03-05T18:50:40Z,estebank,NA https://github.com/rust-lang/rust/pull/58679,MERGED,2019-02-23T18:54:35Z,2019-03-09T21:24:33Z,Refactor passes and pass execution to be more parallel,Zoxc,7985c6f8ecf680dcc960bb2ccc0c787274a449de,6,Rename check_privacy to check_private_in_public,HEART,2019-03-06T09:43:28Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58690,MERGED,2019-02-24T04:01:12Z,2019-02-25T14:48:53Z,Reduce a Code Repetition like `(n << amt) >> amt`,kenta7777,423ae56943a7a91957c7f6f9c011afeead4933cb,1,reduce a code repetition like (n << amt) >> amt,THUMBS_UP,2019-02-24T10:10:06Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/58698,CLOSED,2019-02-24T13:19:03Z,2019-02-24T16:11:49Z,Remove NodeId from Block and Expr,ljedrz,NA,NA,NA,HEART,2019-02-24T14:49:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-02-26T23:10:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-04-15T05:21:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-04-17T07:14:07Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-04-18T17:01:29Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-04-19T19:33:30Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/58702,MERGED,2019-02-24T14:41:29Z,2019-04-18T20:45:23Z,libcore => 2018,taiki-e,e28bce7a518824a90a23f1e1e79ba62507d9dc44,1,Update stdsimd,HOORAY,2019-07-05T17:36:20Z,hadfl,NA https://github.com/rust-lang/rust/pull/58704,MERGED,2019-02-24T15:45:11Z,2019-02-25T06:28:04Z,Remove some unnecessary 'extern crate',taiki-e,9a0b4b6705469e356a03fb7ea9522636492957c4,7,Remove some unnecessary 'extern crate',HEART,2019-02-24T17:27:48Z,panaman67,NA https://github.com/rust-lang/rust/pull/58709,MERGED,2019-02-24T18:00:26Z,2019-02-27T10:44:04Z,Update book submodule,kornelski,19c302c89af342de9f9a7c48c5f6cd6860fed546,2,Update book submodule,HEART,2019-02-26T08:28:39Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-15T15:08:17Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-19T22:14:06Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-21T05:04:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-21T06:52:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-21T21:14:50Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-21T21:50:37Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2019-03-25T09:21:22Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2020-02-05T04:36:24Z,YoshiTheChinchilla,NA https://github.com/rust-lang/rust/pull/58710,MERGED,2019-02-24T18:52:59Z,2019-03-15T09:17:53Z,Add clamp for ranges. Implements #44095,EdorianDark,6041ec3b788a519ab740925c6b1c2f0ac19ad17d,3,add feature clamp,HOORAY,2020-09-07T06:47:30Z,c12h,NA https://github.com/rust-lang/rust/pull/58721,MERGED,2019-02-25T07:58:15Z,2019-02-25T11:56:58Z,[stable] Rust 1.33.0 release,pietroalbini,ab4c12ac5a67d74514a636bc427d0a442f102a0b,1,stable 1.33.0 release,ROCKET,2019-02-25T08:00:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58721,MERGED,2019-02-25T07:58:15Z,2019-02-25T11:56:58Z,[stable] Rust 1.33.0 release,pietroalbini,ab4c12ac5a67d74514a636bc427d0a442f102a0b,1,stable 1.33.0 release,ROCKET,2019-02-25T09:33:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58741,MERGED,2019-02-25T22:16:48Z,2019-02-27T15:15:41Z,Allow lang and lib features to share names,varkor,0f6b148db278dd14b11e009c60712f0303c05f79,1,Allow lang and lib features to share names,HEART,2019-02-25T22:42:01Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/58741,MERGED,2019-02-25T22:16:48Z,2019-02-27T15:15:41Z,Allow lang and lib features to share names,varkor,0f6b148db278dd14b11e009c60712f0303c05f79,1,Allow lang and lib features to share names,HEART,2019-02-25T23:31:10Z,cramertj,NA https://github.com/rust-lang/rust/pull/58741,MERGED,2019-02-25T22:16:48Z,2019-02-27T15:15:41Z,Allow lang and lib features to share names,varkor,0f6b148db278dd14b11e009c60712f0303c05f79,1,Allow lang and lib features to share names,HOORAY,2019-02-26T01:29:34Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/58747,MERGED,2019-02-26T08:32:20Z,2019-02-27T00:10:35Z,[beta] Prepare beta 1.34.0,pietroalbini,c57827ed72bb2315470a761c83b43488f7fce7e4,2,prepare beta 1.34.0,HOORAY,2019-02-26T11:12:32Z,mati865,NA https://github.com/rust-lang/rust/pull/58747,MERGED,2019-02-26T08:32:20Z,2019-02-27T00:10:35Z,[beta] Prepare beta 1.34.0,pietroalbini,c57827ed72bb2315470a761c83b43488f7fce7e4,2,prepare beta 1.34.0,HOORAY,2019-02-26T11:26:06Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/58747,MERGED,2019-02-26T08:32:20Z,2019-02-27T00:10:35Z,[beta] Prepare beta 1.34.0,pietroalbini,c57827ed72bb2315470a761c83b43488f7fce7e4,2,prepare beta 1.34.0,HOORAY,2019-02-26T11:57:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58747,MERGED,2019-02-26T08:32:20Z,2019-02-27T00:10:35Z,[beta] Prepare beta 1.34.0,pietroalbini,c57827ed72bb2315470a761c83b43488f7fce7e4,2,prepare beta 1.34.0,HOORAY,2019-02-26T13:55:57Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58754,MERGED,2019-02-26T15:01:10Z,2019-03-01T18:32:12Z,Remove NodeId from more HIR nodes,ljedrz,9cd184590847ae20f3e49c3f23d8118632011872,4,hir: remove NodeId from VisibilityKind,HEART,2019-03-01T02:28:10Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58755,MERGED,2019-02-26T15:12:27Z,2019-02-27T18:51:17Z,Clarify `rotate_{left right}` docs,tbu-,998896c036cca6ed984f39fe28bb867055432167,2,Clarify `rotate_{left right}` docs I wondered what the `<,HEART,2019-03-06T06:43:54Z,andylokandy,andylokandy@hotmail.com https://github.com/rust-lang/rust/pull/58785,MERGED,2019-02-27T18:03:23Z,2019-03-03T11:42:21Z,allow specifying attributes for tool lints,euclio,a998b1f425bc13d891ed5b28f1b708970f9db4b4,2,allow specifying attributes for tool lints,HEART,2019-02-27T20:25:26Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58785,MERGED,2019-02-27T18:03:23Z,2019-03-03T11:42:21Z,allow specifying attributes for tool lints,euclio,a998b1f425bc13d891ed5b28f1b708970f9db4b4,2,allow specifying attributes for tool lints,HEART,2019-02-27T20:40:16Z,estebank,NA https://github.com/rust-lang/rust/pull/58788,MERGED,2019-02-27T21:06:06Z,2019-03-11T09:09:02Z,Make migrate mode work at item level granularity,matthewjasper,7285b5630b36b3e6aba135f91ded546e82775288,7,Make migrate mode work at item level granularity,HOORAY,2019-02-27T21:33:47Z,lqd,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-02-28T19:23:24Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,HOORAY,2019-02-28T21:16:17Z,peterhj,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-01T16:37:55Z,bjorn3,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,HOORAY,2019-03-03T08:07:43Z,Schultzer,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-13T10:01:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-13T11:59:54Z,mati865,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-21T19:00:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,HOORAY,2019-03-21T19:00:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-27T11:41:17Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/58791,MERGED,2019-02-27T22:58:01Z,2019-03-20T21:07:51Z,Introduce assembly tests suite,denzp,60f1644fd2746fd29520099d1667b6c3a3eb7b83,478,Merge remote-tracking branch 'upstream/master' into asm-compile-tests,THUMBS_UP,2019-03-28T18:09:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58793,MERGED,2019-02-28T00:01:21Z,2019-03-03T08:48:16Z,Bootstrap compiler update for 1.35 release,Mark-Simulacrum,04679431a249570bb2ca6d5813ebb37db76cc9db,1,Call clang and llvm-objdump with correct library path,HOORAY,2019-02-28T20:22:37Z,mati865,NA https://github.com/rust-lang/rust/pull/58803,MERGED,2019-02-28T09:29:42Z,2019-03-28T12:12:27Z,fs::copy() unix: set file mode early,haraldh,cf8347ba6bc82c41de2ad9bf561af593a89cbe45,2,"fs::copy() set file mode early A convenience method like fs::copy() should try to prevent pitfalls a normal user doesn't think about. In case of an empty umask setting the file mode early prevents temporarily world readable or even writeable files because the default mode is 0o666. In case the target is a named pipe or special device node setting the file mode can lead to unwanted side effects like setting permissons on `/dev/stdout` or for root setting permissions on `/dev/null`. copy_file_range() returns EINVAL if the destination is a FIFO/pipe or a device like ""/dev/null"" so fallback to io::copy too. Use `fcopyfile` on MacOS instead of `copyfile`. Fixes: https://github.com/rust-lang/rust/issues/26933 Fixed: https://github.com/rust-lang/rust/issues/37885",HEART,2019-03-01T13:28:01Z,mati865,NA https://github.com/rust-lang/rust/pull/58803,MERGED,2019-02-28T09:29:42Z,2019-03-28T12:12:27Z,fs::copy() unix: set file mode early,haraldh,cf8347ba6bc82c41de2ad9bf561af593a89cbe45,2,"fs::copy() set file mode early A convenience method like fs::copy() should try to prevent pitfalls a normal user doesn't think about. In case of an empty umask setting the file mode early prevents temporarily world readable or even writeable files because the default mode is 0o666. In case the target is a named pipe or special device node setting the file mode can lead to unwanted side effects like setting permissons on `/dev/stdout` or for root setting permissions on `/dev/null`. copy_file_range() returns EINVAL if the destination is a FIFO/pipe or a device like ""/dev/null"" so fallback to io::copy too. Use `fcopyfile` on MacOS instead of `copyfile`. Fixes: https://github.com/rust-lang/rust/issues/26933 Fixed: https://github.com/rust-lang/rust/issues/37885",THUMBS_UP,2021-02-27T19:39:22Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/58805,MERGED,2019-02-28T10:48:07Z,2019-03-31T20:27:38Z,Lint for redundant imports,fabric-and-ink,c1d5314bd3b628749491e4fe201b4c6916a53ce6,1,Remove redundant import,THUMBS_UP,2019-03-20T19:44:18Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/58805,MERGED,2019-02-28T10:48:07Z,2019-03-31T20:27:38Z,Lint for redundant imports,fabric-and-ink,c1d5314bd3b628749491e4fe201b4c6916a53ce6,1,Remove redundant import,THUMBS_UP,2019-03-31T13:27:48Z,ljedrz,NA https://github.com/rust-lang/rust/pull/58829,MERGED,2019-03-01T09:19:53Z,2019-03-13T06:18:57Z,librustc_interface: Update scoped-tls to 1.0,Xanewok,204f087daf6570824832eec56b24d9cd8cbf4a70,2,librustc_interface: Update scoped-tls to 1.0 Done previously as a part of https://github.com/rust-lang/rust/pull/58748,THUMBS_UP,2019-03-01T13:10:41Z,mati865,NA https://github.com/rust-lang/rust/pull/58847,MERGED,2019-03-01T15:58:34Z,2019-03-18T14:46:03Z,Remove metadata only codegen backend,bjorn3,0e0488fa53ddc465139023c023957a70176f34e2,1,Fix formatting,HOORAY,2019-03-09T17:01:42Z,mati865,NA https://github.com/rust-lang/rust/pull/58848,MERGED,2019-03-01T16:04:04Z,2019-03-28T12:12:29Z,Prevent cache issues on version updates,GuillaumeGomez,5652dd677c63d0d1bc7d26f09baceaff7e7525b5,2,Fix error index CSS file name,HEART,2019-03-01T20:16:15Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/58848,MERGED,2019-03-01T16:04:04Z,2019-03-28T12:12:29Z,Prevent cache issues on version updates,GuillaumeGomez,5652dd677c63d0d1bc7d26f09baceaff7e7525b5,2,Fix error index CSS file name,HEART,2019-03-02T10:28:11Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/58848,MERGED,2019-03-01T16:04:04Z,2019-03-28T12:12:29Z,Prevent cache issues on version updates,GuillaumeGomez,5652dd677c63d0d1bc7d26f09baceaff7e7525b5,2,Fix error index CSS file name,HEART,2019-03-07T03:14:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/58852,MERGED,2019-03-01T18:35:47Z,2019-03-03T11:42:28Z,Update toolchain to build NetBSD release,alexcrichton,a7d17bfcd537c89908b59d86f4af1d6137974845,2,"Update toolchain to build NetBSD release This allows us to remove the ""allow old toolchains"" flag we pass to LLVM ensuring that we'll be up to date when LLVM needs us to be!",THUMBS_UP,2019-03-01T21:18:39Z,mati865,NA https://github.com/rust-lang/rust/pull/58852,MERGED,2019-03-01T18:35:47Z,2019-03-03T11:42:28Z,Update toolchain to build NetBSD release,alexcrichton,a7d17bfcd537c89908b59d86f4af1d6137974845,2,"Update toolchain to build NetBSD release This allows us to remove the ""allow old toolchains"" flag we pass to LLVM ensuring that we'll be up to date when LLVM needs us to be!",THUMBS_UP,2019-03-02T04:04:58Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58861,MERGED,2019-03-01T22:43:32Z,2019-03-09T08:18:03Z,Expand where negative supertrait specific error is shown,estebank,dc4973dfd918f5d71cd8e5c8e5aac5b8a86bf4e4,3,Expand where negative supertrait specific error is shown Fix #58857.,HEART,2019-03-02T01:55:56Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/58872,MERGED,2019-03-02T14:33:18Z,2019-03-18T11:11:38Z,Adds help message in error for invalid `impl for T` syntax,repnop,e19b2289594746ce733588ac444df3fefaad4912,3,Improve recovery for missing trait in a trait impl,HEART,2019-03-16T03:37:44Z,estebank,NA https://github.com/rust-lang/rust/pull/58872,MERGED,2019-03-02T14:33:18Z,2019-03-18T11:11:38Z,Adds help message in error for invalid `impl for T` syntax,repnop,e19b2289594746ce733588ac444df3fefaad4912,3,Improve recovery for missing trait in a trait impl,HEART,2019-03-18T11:18:03Z,Ravenslofty,dan.ravensloft@gmail.com https://github.com/rust-lang/rust/pull/58899,MERGED,2019-03-03T17:41:18Z,2019-03-17T00:00:21Z,Do not accidentally treat multi-segment meta-items as single-segment,petrochenkov,2fd4cbb3f283b903f55444bb585d38a2539f4e8d,3,Fix rebase,THUMBS_UP,2019-03-08T21:34:10Z,estebank,NA https://github.com/rust-lang/rust/pull/58901,MERGED,2019-03-03T19:53:38Z,2019-03-16T17:52:28Z,Change `std::fs::copy` to use `copyfile` on MacOS and iOS,ebarnard,124ab2a4d87f2d10b88d668e35286af4c00ec12b,1,Fix typo,THUMBS_UP,2019-03-20T22:21:44Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/58901,MERGED,2019-03-03T19:53:38Z,2019-03-16T17:52:28Z,Change `std::fs::copy` to use `copyfile` on MacOS and iOS,ebarnard,124ab2a4d87f2d10b88d668e35286af4c00ec12b,1,Fix typo,THUMBS_UP,2019-03-21T06:54:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/58901,MERGED,2019-03-03T19:53:38Z,2019-03-16T17:52:28Z,Change `std::fs::copy` to use `copyfile` on MacOS and iOS,ebarnard,124ab2a4d87f2d10b88d668e35286af4c00ec12b,1,Fix typo,THUMBS_UP,2019-03-21T21:15:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/58908,MERGED,2019-03-04T07:25:22Z,2019-03-13T06:19:00Z,Update rand version,JohnTitor,939a2639742f161811b500bc45bd06a1d63e9d18,2,Update rand version,THUMBS_UP,2019-03-04T11:02:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/58908,MERGED,2019-03-04T07:25:22Z,2019-03-13T06:19:00Z,Update rand version,JohnTitor,939a2639742f161811b500bc45bd06a1d63e9d18,2,Update rand version,THUMBS_UP,2019-03-04T13:55:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58908,MERGED,2019-03-04T07:25:22Z,2019-03-13T06:19:00Z,Update rand version,JohnTitor,939a2639742f161811b500bc45bd06a1d63e9d18,2,Update rand version,THUMBS_UP,2019-03-08T14:02:00Z,mati865,NA https://github.com/rust-lang/rust/pull/58915,MERGED,2019-03-04T14:46:14Z,2019-03-08T17:04:04Z,HirIdification: almost there,ljedrz,24fad4c145122ba4abfdcb3bdafb3f4a2f429ba6,1,update clippy,ROCKET,2019-03-13T20:52:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/58915,MERGED,2019-03-04T14:46:14Z,2019-03-08T17:04:04Z,HirIdification: almost there,ljedrz,24fad4c145122ba4abfdcb3bdafb3f4a2f429ba6,1,update clippy,ROCKET,2019-03-14T06:14:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/58918,MERGED,2019-03-04T18:56:26Z,2019-03-09T08:18:10Z,Regression test added for an async ICE.,gilescope,143e7d57321babc6fe993df370e0b54861443c11,1,Desugared asyncs into generators and minimised.,THUMBS_UP,2019-03-05T00:12:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/58924,MERGED,2019-03-04T23:26:48Z,2019-03-09T21:24:41Z,Add as_slice() to slice::IterMut and vec::Drain,cuviper,e478cadbbe51e335b7248018141877b88770fe68,2,Add a tracking issue for new as_slice methods,THUMBS_UP,2020-08-25T07:38:37Z,iago-lito,NA https://github.com/rust-lang/rust/pull/58927,MERGED,2019-03-05T01:29:47Z,2019-03-21T12:13:25Z,Add default keyword handling in rustdoc,GuillaumeGomez,541ad45a83482e3132c75fbbc55fb2afc03a6031,4,Add default keyword handling in rustdoc,THUMBS_UP,2019-03-21T17:34:56Z,bjorn3,NA https://github.com/rust-lang/rust/pull/58933,MERGED,2019-03-05T09:02:57Z,2019-03-16T17:52:30Z,Move alloc::prelude::* to alloc::prelude::v1 make alloc a subset of std,SimonSapin,5d1022ad7b82168aee243d2adcbd83d1e886586f,2,Rename the feature gate for alloc::prelude … to separate it from that of the crate. New tracking issue: https://github.com/rust-lang/rust/issues/58935,THUMBS_UP,2019-03-05T10:59:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/58933,MERGED,2019-03-05T09:02:57Z,2019-03-16T17:52:30Z,Move alloc::prelude::* to alloc::prelude::v1 make alloc a subset of std,SimonSapin,5d1022ad7b82168aee243d2adcbd83d1e886586f,2,Rename the feature gate for alloc::prelude … to separate it from that of the crate. New tracking issue: https://github.com/rust-lang/rust/issues/58935,THUMBS_UP,2019-03-16T18:21:32Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/58933,MERGED,2019-03-05T09:02:57Z,2019-03-16T17:52:30Z,Move alloc::prelude::* to alloc::prelude::v1 make alloc a subset of std,SimonSapin,5d1022ad7b82168aee243d2adcbd83d1e886586f,2,Rename the feature gate for alloc::prelude … to separate it from that of the crate. New tracking issue: https://github.com/rust-lang/rust/issues/58935,ROCKET,2019-03-16T18:21:37Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/58941,MERGED,2019-03-05T15:35:27Z,2019-03-16T17:52:31Z,MIPS: add r6 support,wzssyqa,710988ad603c52657c72a7f1028415e3e244a97c,7,MIPS: add r6 support MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3,HOORAY,2019-03-05T18:11:54Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/58941,MERGED,2019-03-05T15:35:27Z,2019-03-16T17:52:31Z,MIPS: add r6 support,wzssyqa,710988ad603c52657c72a7f1028415e3e244a97c,7,MIPS: add r6 support MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3,THUMBS_UP,2019-03-06T18:18:42Z,paoloteti,NA https://github.com/rust-lang/rust/pull/58953,MERGED,2019-03-05T23:08:32Z,2019-03-22T21:00:21Z,Unify OsString/OsStr for byte-based implementations,jethrogb,2079df1c8740dd76d5c28bb8f6193826f6afdec4,13,Unify OsString/OsStr for byte-based implementations,HEART,2019-03-05T23:21:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/58953,MERGED,2019-03-05T23:08:32Z,2019-03-22T21:00:21Z,Unify OsString/OsStr for byte-based implementations,jethrogb,2079df1c8740dd76d5c28bb8f6193826f6afdec4,13,Unify OsString/OsStr for byte-based implementations,HEART,2019-03-10T15:17:52Z,kennytm,NA https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-07T19:42:27Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-15T15:52:50Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-15T17:59:53Z,donaldpipowitch,NA https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-15T18:10:02Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-16T01:56:10Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-03-28T16:13:21Z,mati865,NA https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-04-21T23:31:02Z,tjkirch,NA https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-10-22T04:38:22Z,hugecheese,NA https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2019-11-04T18:02:04Z,dylanede,dylanede@googlemail.com https://github.com/rust-lang/rust/pull/58974,CLOSED,2019-03-06T18:23:15Z,2019-05-16T18:26:59Z,std: implement `Error` for `Box`,seanmonstar,NA,NA,NA,THUMBS_UP,2020-08-27T10:32:36Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/58976,MERGED,2019-03-06T19:00:05Z,2019-03-16T17:52:34Z,Default to integrated `rust-lld` linker for UEFI targets,phil-opp,876258b0fa31fc1d1a79ddc0e5a0c9c5f0e8f85b,1,Default to integrated `rust-lld` linker for UEFI targets,THUMBS_UP,2019-03-07T16:31:24Z,kkk669,NA https://github.com/rust-lang/rust/pull/58976,MERGED,2019-03-06T19:00:05Z,2019-03-16T17:52:34Z,Default to integrated `rust-lld` linker for UEFI targets,phil-opp,876258b0fa31fc1d1a79ddc0e5a0c9c5f0e8f85b,1,Default to integrated `rust-lld` linker for UEFI targets,THUMBS_UP,2019-07-16T21:24:38Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/58986,MERGED,2019-03-07T04:14:59Z,2019-03-20T08:26:09Z,[CI] Update binutils for powerpc64 and powerpc64le,cuviper,c843fe710bb7fb454d68505c8000c0a50bc2a729,1,Wrap a long configure line,THUMBS_UP,2019-03-07T13:10:39Z,mati865,NA https://github.com/rust-lang/rust/pull/58986,MERGED,2019-03-07T04:14:59Z,2019-03-20T08:26:09Z,[CI] Update binutils for powerpc64 and powerpc64le,cuviper,c843fe710bb7fb454d68505c8000c0a50bc2a729,1,Wrap a long configure line,THUMBS_UP,2019-03-08T12:15:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,ROCKET,2019-03-07T12:07:12Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,ROCKET,2019-03-07T13:34:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,ROCKET,2019-03-07T14:23:09Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,HEART,2019-03-07T14:57:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,ROCKET,2019-03-07T15:24:41Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,HEART,2019-03-07T18:04:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,HEART,2019-03-08T05:19:06Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,ROCKET,2019-03-08T05:50:43Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,HEART,2019-03-08T05:50:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/58992,CLOSED,2019-03-07T12:00:21Z,2019-03-08T09:47:25Z,HirIdification: almost there,ljedrz,NA,NA,NA,HEART,2019-03-30T04:38:32Z,hcpl,NA https://github.com/rust-lang/rust/pull/58995,MERGED,2019-03-07T17:15:21Z,2019-03-22T11:18:25Z,Refactor tools/build-mainfest,Centril,83534874444f8981c540685eba1ddb8fb42999bc,1,refactor build-mainfest.,HEART,2019-03-07T17:41:51Z,panaman67,NA https://github.com/rust-lang/rust/pull/58995,MERGED,2019-03-07T17:15:21Z,2019-03-22T11:18:25Z,Refactor tools/build-mainfest,Centril,83534874444f8981c540685eba1ddb8fb42999bc,1,refactor build-mainfest.,HEART,2019-03-07T17:50:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/58999,CLOSED,2019-03-07T20:36:57Z,2019-03-29T07:20:43Z,Change the `?` lowering to selectively omit the `from`,llogiq,NA,NA,NA,THUMBS_UP,2019-03-08T01:52:54Z,estebank,NA https://github.com/rust-lang/rust/pull/59007,MERGED,2019-03-07T23:39:24Z,2019-03-09T08:18:19Z,Add a test for invalid const arguments,varkor,8bb62d18f3645fd4fc83096a3fec3d7e30a7674b,2,Add a test for invalid const arguments,THUMBS_UP,2019-03-08T23:49:53Z,estebank,NA https://github.com/rust-lang/rust/pull/59007,MERGED,2019-03-07T23:39:24Z,2019-03-09T08:18:19Z,Add a test for invalid const arguments,varkor,8bb62d18f3645fd4fc83096a3fec3d7e30a7674b,2,Add a test for invalid const arguments,THUMBS_UP,2019-03-09T09:38:03Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T02:28:32Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T04:06:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T04:12:26Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T13:56:00Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T22:29:40Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-08T22:29:50Z,lachlansneff,lachlan@charted.space https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-09T08:36:44Z,crlf0710,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-09T17:19:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-09T23:59:10Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-11T09:04:54Z,jplatte,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-12T09:37:01Z,mati865,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-12T19:19:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-14T00:20:20Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-14T06:08:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-14T13:45:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-27T16:40:09Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-27T18:21:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-03-31T12:17:08Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-04-15T07:07:33Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-04-17T19:27:48Z,o01eg,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-04-22T23:49:37Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-04-30T13:13:25Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-05-01T23:50:54Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-05-02T13:50:37Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HEART,2019-05-02T13:50:51Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-05-02T20:43:59Z,frol,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HEART,2019-05-02T20:44:00Z,frol,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-05-03T06:34:49Z,qnighy,NA https://github.com/rust-lang/rust/pull/59008,MERGED,2019-03-08T01:24:21Z,2019-05-02T07:38:33Z,Add const generics to infer (and transitive dependencies),varkor,a68ed060bdab2d4c5d36062cda24f89d22488271,3,Split `ct_err` out into `CommonConsts` Co-Authored-By: Gabriel Smith ,HOORAY,2019-05-04T00:58:34Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/59009,MERGED,2019-03-08T02:40:49Z,2019-03-16T17:52:36Z,Fix SGX implementations of read/write_vectored.,sfackler,ab8e1d264e6722169d25d3f52ac2e8de172e205d,3,Always call read/write from default vectored io methods,THUMBS_UP,2019-03-08T02:59:33Z,jethrogb,NA https://github.com/rust-lang/rust/pull/59009,MERGED,2019-03-08T02:40:49Z,2019-03-16T17:52:36Z,Fix SGX implementations of read/write_vectored.,sfackler,ab8e1d264e6722169d25d3f52ac2e8de172e205d,3,Always call read/write from default vectored io methods,THUMBS_UP,2019-03-08T04:06:04Z,panaman67,NA https://github.com/rust-lang/rust/pull/59038,MERGED,2019-03-09T06:43:19Z,2019-03-20T08:26:11Z,Track embedded-book in the toolstate,kennytm,d6f51006cd47ca3f1ccacc4e0faa345877653b81,1,Fix tidy,THUMBS_UP,2019-03-09T15:27:11Z,mati865,NA https://github.com/rust-lang/rust/pull/59041,MERGED,2019-03-09T08:03:51Z,2019-04-01T21:55:55Z,fixes rust-lang#56766,saleemjaffer,d2584816254278cd844d4892f0acf563f2e7e207,1,tidy test,HEART,2019-03-09T21:36:57Z,estebank,NA https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-09T09:11:58Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-09T10:33:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-09T15:54:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-09T16:40:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-13T20:53:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-03-30T12:59:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59042,MERGED,2019-03-09T08:42:15Z,2019-04-25T03:44:28Z,HirIdification: rework Map,ljedrz,37954df1a71b204174719f28c59be8b38fd439f0,3,doc: some HirIdification,HEART,2019-04-25T19:32:51Z,hcpl,NA https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T11:59:08Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T12:08:18Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T12:22:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T14:05:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T20:39:22Z,estebank,NA https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,HEART,2019-03-09T20:40:07Z,estebank,NA https://github.com/rust-lang/rust/pull/59044,MERGED,2019-03-09T11:56:18Z,2019-03-12T00:58:01Z,Filter away test annotations from UI test output,petrochenkov,07f99b9fec4ba0c549596e8e7d99553e86763d35,4,Update tests that don't run on my platform,THUMBS_UP,2019-03-09T22:12:08Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/59054,MERGED,2019-03-09T23:50:32Z,2019-03-10T23:42:16Z,CI: Trim some tests from i686-gnu,ehuss,609316a7df8851aeba204e4575c39140788cd964,1,CI: Trim some tests from i686-gnu This removes some tests from the i686-gnu job. This job clocks in at 2hr 56min and removing these should cut about 10 to 15 minutes giving a little more breathing room. I suspect these don't need to be tested on every platform.,THUMBS_UP,2019-03-10T15:58:59Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59056,MERGED,2019-03-10T03:11:35Z,2019-03-13T06:19:06Z,Use lifetime contravariance to elide more lifetimes in core+alloc+std,scottmcm,df4ea90b39c808e858e05f3b4bb05fc29f812d26,19,Use lifetime contravariance to elide more lifetimes in core+alloc+std,HEART,2019-03-10T09:55:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59056,MERGED,2019-03-10T03:11:35Z,2019-03-13T06:19:06Z,Use lifetime contravariance to elide more lifetimes in core+alloc+std,scottmcm,df4ea90b39c808e858e05f3b4bb05fc29f812d26,19,Use lifetime contravariance to elide more lifetimes in core+alloc+std,HEART,2019-03-10T11:25:00Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59056,MERGED,2019-03-10T03:11:35Z,2019-03-13T06:19:06Z,Use lifetime contravariance to elide more lifetimes in core+alloc+std,scottmcm,df4ea90b39c808e858e05f3b4bb05fc29f812d26,19,Use lifetime contravariance to elide more lifetimes in core+alloc+std,HEART,2019-03-11T14:37:27Z,estebank,NA https://github.com/rust-lang/rust/pull/59058,MERGED,2019-03-10T09:20:11Z,2019-03-23T09:01:13Z, syntax: Better recovery for `$ty::AssocItem` and `ty!()::AssocItem`,petrochenkov,1ab8ca353237470c2587985279d074c1524e90e1,1,Address review comments,HEART,2019-03-10T19:52:30Z,estebank,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-10T11:44:50Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-10T12:19:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-10T13:11:23Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-10T13:57:51Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-10T14:54:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-23T15:32:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-04-12T01:46:25Z,estebank,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-06-12T15:21:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-08-24T18:09:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59064,CLOSED,2019-03-10T11:35:35Z,2019-12-22T07:28:07Z,Turn HIR indexing into a query,Zoxc,NA,NA,NA,ROCKET,2019-09-15T02:53:38Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/59068,MERGED,2019-03-10T12:58:35Z,2019-03-23T20:52:58Z,HirIdification: kill off NodeId stragglers,ljedrz,584d61a2bee9af2af572103899fc3e485e0a1fa8,4,hir: remove trait_auto_impl,HEART,2019-03-10T22:12:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/59068,MERGED,2019-03-10T12:58:35Z,2019-03-23T20:52:58Z,HirIdification: kill off NodeId stragglers,ljedrz,584d61a2bee9af2af572103899fc3e485e0a1fa8,4,hir: remove trait_auto_impl,HEART,2019-03-11T15:17:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59068,MERGED,2019-03-10T12:58:35Z,2019-03-23T20:52:58Z,HirIdification: kill off NodeId stragglers,ljedrz,584d61a2bee9af2af572103899fc3e485e0a1fa8,4,hir: remove trait_auto_impl,HEART,2019-03-11T17:27:38Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/59068,MERGED,2019-03-10T12:58:35Z,2019-03-23T20:52:58Z,HirIdification: kill off NodeId stragglers,ljedrz,584d61a2bee9af2af572103899fc3e485e0a1fa8,4,hir: remove trait_auto_impl,HEART,2019-03-13T21:18:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59068,MERGED,2019-03-10T12:58:35Z,2019-03-23T20:52:58Z,HirIdification: kill off NodeId stragglers,ljedrz,584d61a2bee9af2af572103899fc3e485e0a1fa8,4,hir: remove trait_auto_impl,HEART,2019-03-15T21:00:41Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/59072,MERGED,2019-03-10T16:49:12Z,2019-03-16T17:52:40Z,we can now skip should_panic tests with the libtest harness,RalfJung,52d9fa827d3cf5ef5fc0e2042ca1fc7f6dc391ed,2,enabled too many tests,THUMBS_UP,2019-03-10T17:34:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",ROCKET,2019-03-10T23:04:59Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",HOORAY,2019-03-10T23:05:01Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",EYES,2019-03-11T03:37:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",THUMBS_UP,2019-03-12T03:02:08Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",THUMBS_UP,2019-05-17T02:24:13Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",HOORAY,2019-05-21T10:38:22Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",HOORAY,2019-05-21T11:42:57Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",THUMBS_UP,2019-05-23T22:36:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",THUMBS_UP,2019-07-04T16:08:00Z,DianaNites,NA https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",HOORAY,2019-07-04T16:08:01Z,DianaNites,NA https://github.com/rust-lang/rust/pull/59076,MERGED,2019-03-10T21:34:27Z,2019-04-05T17:45:47Z,Include trailing comma in multiline Debug representation,dtolnay,cfd31fb4df214ab84a917ba9afd148ed13d01a3a,28,"Include trailing comma in multiline Debug representation This commit changes the behavior of Formatter::debug_struct debug_tuple debug_list debug_set and debug_map to render trailing commas in {:#?} mode which is the dominant style in modern Rust code. Before: Language { name: ""Rust"" trailing_commas: false } After: Language { name: ""Rust"" trailing_commas: true }",THUMBS_UP,2019-08-28T22:34:31Z,emiflake,emi@haskell.fyi https://github.com/rust-lang/rust/pull/59079,MERGED,2019-03-11T01:03:08Z,2019-03-16T17:52:41Z,add suggestions to invalid macro item error,euclio,5abd6d9492e8a5a4592bca4c18e1de6104b1ea51,5,add suggestions to invalid macro item error,HEART,2019-03-11T13:41:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59083,MERGED,2019-03-11T02:46:52Z,2019-03-13T06:19:08Z,Fix #54822 and associated faulty tests,kyren,aa9bd68fa8134e55ded5e65abef745f96ba0e622,2,Rename test struct names to something more sensible,HEART,2019-03-12T18:51:43Z,varkor,NA https://github.com/rust-lang/rust/pull/59089,MERGED,2019-03-11T07:02:56Z,2019-04-04T08:26:26Z,Support using LLVM's libunwind as the unwinder implementation,petrhosek,86d1678403a46cd30019487dcc21166c1d09a597,9,Support using LLVM's libunwind as the unwinder implementation This avoids the dependency on host libraries such as libgcc_s which may be undesirable in some deployment environments where these aren't available.,HOORAY,2019-03-11T17:06:35Z,mati865,NA https://github.com/rust-lang/rust/pull/59089,MERGED,2019-03-11T07:02:56Z,2019-04-04T08:26:26Z,Support using LLVM's libunwind as the unwinder implementation,petrhosek,86d1678403a46cd30019487dcc21166c1d09a597,9,Support using LLVM's libunwind as the unwinder implementation This avoids the dependency on host libraries such as libgcc_s which may be undesirable in some deployment environments where these aren't available.,HOORAY,2019-03-11T19:29:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/59092,CLOSED,2019-03-11T08:48:04Z,2019-03-28T13:53:02Z,HirIdify hir::ItemId,ljedrz,NA,NA,NA,HEART,2019-03-13T21:23:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59093,MERGED,2019-03-11T08:57:14Z,2019-03-13T06:19:09Z,Remove precompute_in_scope_traits_hashes,Zoxc,01e2e1f88f4e1d82060aba4a01a6cae0343d3b89,2,Remove precompute_in_scope_traits_hashes,HEART,2019-03-11T18:27:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,THUMBS_UP,2019-03-11T12:25:49Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,THUMBS_UP,2019-03-11T17:26:11Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,THUMBS_UP,2019-03-11T18:26:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,HEART,2019-03-11T18:27:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,THUMBS_UP,2019-03-12T22:54:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,HEART,2019-03-13T21:24:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,HOORAY,2019-03-14T12:19:55Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59096,MERGED,2019-03-11T10:07:01Z,2019-03-23T15:49:58Z,middle: replace NodeId with HirId in AccessLevels,ljedrz,856b081eb2ae3264da07434debd55d734fba7eb4,8,middle: replace NodeId with HirId in AccessLevels,THUMBS_UP,2019-03-31T21:08:54Z,hcpl,NA https://github.com/rust-lang/rust/pull/59101,MERGED,2019-03-11T13:33:34Z,2019-03-13T06:19:10Z,Reduces Code Repetitions like `!n >> amt`,kenta7777,18b40c64136aedb78a494c0c7e44273353198b0e,1,removed the definition of mask,HEART,2019-03-11T18:25:52Z,panaman67,NA https://github.com/rust-lang/rust/pull/59106,MERGED,2019-03-11T16:14:14Z,2019-03-23T00:33:30Z,Add peer_addr function to UdpSocket,LinusU,81d5fb5c6fc65e947ff97c02997bfff9a1f6ce16,1,Add UdpSocket peer_addr implementation for Wasm,THUMBS_UP,2019-03-25T00:13:24Z,MOZGIII,NA https://github.com/rust-lang/rust/pull/59111,MERGED,2019-03-11T18:51:23Z,2019-04-25T23:22:59Z,Improved error message when type must be bound due to generator.,gilescope,66e41bc675e9e7c8fc649bc088b1d48857610fb2,9,Improved error message when type must be bound due to generator. Error now mentions type var name and span is highlighted.,THUMBS_UP,2019-03-12T17:10:39Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59111,MERGED,2019-03-11T18:51:23Z,2019-04-25T23:22:59Z,Improved error message when type must be bound due to generator.,gilescope,66e41bc675e9e7c8fc649bc088b1d48857610fb2,9,Improved error message when type must be bound due to generator. Error now mentions type var name and span is highlighted.,HOORAY,2019-03-12T17:10:41Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59111,MERGED,2019-03-11T18:51:23Z,2019-04-25T23:22:59Z,Improved error message when type must be bound due to generator.,gilescope,66e41bc675e9e7c8fc649bc088b1d48857610fb2,9,Improved error message when type must be bound due to generator. Error now mentions type var name and span is highlighted.,THUMBS_UP,2019-03-13T02:25:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/59111,MERGED,2019-03-11T18:51:23Z,2019-04-25T23:22:59Z,Improved error message when type must be bound due to generator.,gilescope,66e41bc675e9e7c8fc649bc088b1d48857610fb2,9,Improved error message when type must be bound due to generator. Error now mentions type var name and span is highlighted.,HOORAY,2019-03-13T02:25:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-11T20:11:02Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-11T20:11:04Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-11T20:11:06Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-11T20:11:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-11T20:11:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-11T20:11:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T20:11:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T20:11:50Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-11T20:11:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-11T20:26:21Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T20:36:50Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T20:44:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T20:54:17Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T21:12:09Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-11T22:02:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-11T22:02:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T22:02:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-11T22:02:02Z,cramertj,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T22:22:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-11T23:19:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-11T23:19:58Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-11T23:20:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-11T23:20:02Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T00:54:16Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T01:10:04Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T05:25:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-12T07:10:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T07:10:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-12T07:10:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-12T07:10:46Z,panaman67,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-12T14:16:56Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T15:46:09Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-12T16:11:24Z,RalfJung,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-12T22:47:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-13T08:47:33Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-03-13T08:47:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-03-15T09:54:51Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-21T23:38:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-03-21T23:38:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-03-28T19:44:49Z,mati865,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-05T08:55:51Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-11T05:47:13Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,THUMBS_UP,2019-04-19T04:32:48Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-04-19T04:32:49Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,ROCKET,2019-04-19T04:32:50Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-19T04:32:52Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-22T15:11:14Z,lqd,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-22T15:34:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-23T00:51:37Z,qnighy,NA https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HEART,2019-04-23T18:08:50Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-04-23T20:53:19Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/59114,MERGED,2019-03-11T20:07:16Z,2019-04-22T15:06:14Z,Enable NLL migrate mode on the 2015 edition,matthewjasper,8eef102270647af94f38274efb9a2fd5ef8a92ec,1356,update tests for migrate mode by default,HOORAY,2019-05-09T14:53:01Z,estebank,NA https://github.com/rust-lang/rust/pull/59118,MERGED,2019-03-11T23:40:51Z,2019-03-16T17:52:44Z,rustc: fix ICE when trait alias has bare Self,seanmonstar,df05fbf006e90ed4827c385eb9192e4c46de70f4,4,rustc: fix ICE when trait alias has bare Self,THUMBS_UP,2019-03-12T23:16:19Z,estebank,NA https://github.com/rust-lang/rust/pull/59118,MERGED,2019-03-11T23:40:51Z,2019-03-16T17:52:44Z,rustc: fix ICE when trait alias has bare Self,seanmonstar,df05fbf006e90ed4827c385eb9192e4c46de70f4,4,rustc: fix ICE when trait alias has bare Self,THUMBS_UP,2019-03-12T23:48:34Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-03-12T07:30:35Z,kennytm,NA https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-03-12T07:58:33Z,killercup,NA https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-03-12T22:48:12Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,THUMBS_UP,2019-03-13T00:43:17Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,THUMBS_UP,2019-03-20T02:45:43Z,linjunjj,1045735402@qq.com https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-03-28T10:42:32Z,jenshnielsen,jenshnielsen@gmail.com https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-04-03T20:54:19Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/59119,MERGED,2019-03-11T23:57:47Z,2019-04-07T12:33:10Z,Future-proof the Futures API,cramertj,1691e06db661a19a5e25276c18cd165386f027bb,11,Future-proof the Futures API,LAUGH,2019-04-05T22:40:49Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/59128,MERGED,2019-03-12T12:08:41Z,2019-04-17T12:58:04Z,Emit ansi color codes in the `rendered` field of json diagnostics,oli-obk,5c6a43a58bfb31bcabfd52e2c378cdaa48a68290,2,Don't test json with color codes on windows,ROCKET,2019-03-12T12:19:31Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59128,MERGED,2019-03-12T12:08:41Z,2019-04-17T12:58:04Z,Emit ansi color codes in the `rendered` field of json diagnostics,oli-obk,5c6a43a58bfb31bcabfd52e2c378cdaa48a68290,2,Don't test json with color codes on windows,HEART,2019-03-12T14:51:00Z,ehuss,NA https://github.com/rust-lang/rust/pull/59128,MERGED,2019-03-12T12:08:41Z,2019-04-17T12:58:04Z,Emit ansi color codes in the `rendered` field of json diagnostics,oli-obk,5c6a43a58bfb31bcabfd52e2c378cdaa48a68290,2,Don't test json with color codes on windows,HEART,2019-03-12T19:14:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59128,MERGED,2019-03-12T12:08:41Z,2019-04-17T12:58:04Z,Emit ansi color codes in the `rendered` field of json diagnostics,oli-obk,5c6a43a58bfb31bcabfd52e2c378cdaa48a68290,2,Don't test json with color codes on windows,EYES,2019-03-19T06:14:46Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59128,MERGED,2019-03-12T12:08:41Z,2019-04-17T12:58:04Z,Emit ansi color codes in the `rendered` field of json diagnostics,oli-obk,5c6a43a58bfb31bcabfd52e2c378cdaa48a68290,2,Don't test json with color codes on windows,HEART,2019-03-24T18:46:48Z,estebank,NA https://github.com/rust-lang/rust/pull/59130,MERGED,2019-03-12T12:43:21Z,2019-03-13T06:19:12Z,Note that NonNull does not launder shared references for mutation,RalfJung,8ec8639bf3f8c7b17d91028f698abc3067cd56ea,1,expand,THUMBS_UP,2019-03-25T17:53:10Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/59135,CLOSED,2019-03-12T16:38:07Z,2019-04-02T08:02:54Z,[wg-async-await] Drop `async fn` arguments in async block,davidtwco,NA,NA,NA,THUMBS_UP,2019-03-13T09:24:55Z,anqurvanillapy,anqurvanillapy@gmail.com https://github.com/rust-lang/rust/pull/59135,CLOSED,2019-03-12T16:38:07Z,2019-04-02T08:02:54Z,[wg-async-await] Drop `async fn` arguments in async block,davidtwco,NA,NA,NA,THUMBS_UP,2019-03-14T09:24:33Z,hcpl,NA https://github.com/rust-lang/rust/pull/59138,MERGED,2019-03-12T18:51:52Z,2019-03-13T06:19:14Z,Simplify Iterator::{min max},timvermeulen,6cc5a3d9cc470e2db2b2a45fcddb2350ac0b039e,1,Forward `max` and `min` to `max_by` and `min_by` respectively,HEART,2019-03-12T21:00:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/59138,MERGED,2019-03-12T18:51:52Z,2019-03-13T06:19:14Z,Simplify Iterator::{min max},timvermeulen,6cc5a3d9cc470e2db2b2a45fcddb2350ac0b039e,1,Forward `max` and `min` to `max_by` and `min_by` respectively,HEART,2019-03-13T08:22:58Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/59138,MERGED,2019-03-12T18:51:52Z,2019-03-13T06:19:14Z,Simplify Iterator::{min max},timvermeulen,6cc5a3d9cc470e2db2b2a45fcddb2350ac0b039e,1,Forward `max` and `min` to `max_by` and `min_by` respectively,HEART,2019-03-14T12:15:48Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/59152,MERGED,2019-03-13T04:02:29Z,2019-03-16T17:52:47Z,Stabilize Range*::contains.,smmalis37,266ca31f74ae343fc773b88f3bb77b601034babf,5,Stabilize Range*::contains.,HOORAY,2019-03-21T21:15:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59152,MERGED,2019-03-13T04:02:29Z,2019-03-16T17:52:47Z,Stabilize Range*::contains.,smmalis37,266ca31f74ae343fc773b88f3bb77b601034babf,5,Stabilize Range*::contains.,HOORAY,2019-04-06T13:20:28Z,samcday,NA https://github.com/rust-lang/rust/pull/59155,CLOSED,2019-03-13T07:57:44Z,2019-05-18T13:58:24Z,Add element-wise atomic memory operations,tmccombs,NA,NA,NA,HEART,2019-03-16T17:55:09Z,mtak-,NA https://github.com/rust-lang/rust/pull/59155,CLOSED,2019-03-13T07:57:44Z,2019-05-18T13:58:24Z,Add element-wise atomic memory operations,tmccombs,NA,NA,NA,HEART,2019-05-01T20:18:10Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/59169,MERGED,2019-03-13T23:33:22Z,2019-03-16T17:52:49Z,Add `-Z allow_features=...` flag,tmandry,7c59ce9f5db9cb7dbfbd07fab625e2b67aa042f5,9,Add `-Z allow_features=...` flag,THUMBS_UP,2019-03-14T18:02:06Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/59169,MERGED,2019-03-13T23:33:22Z,2019-03-16T17:52:49Z,Add `-Z allow_features=...` flag,tmandry,7c59ce9f5db9cb7dbfbd07fab625e2b67aa042f5,9,Add `-Z allow_features=...` flag,THUMBS_UP,2019-03-18T18:08:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/59173,MERGED,2019-03-14T01:27:40Z,2019-03-16T17:52:50Z,bootstrap: Default to a sensible llvm-suffix.,emilio,e7b7c417e639a2070ae91c2b84e0574beafb0bb7,2,bootstrap: Default to a sensible llvm-suffix. I used version-channel-sha hopefully that should work. I checked that bootstrap builds but I cannot check anything else since the llvm build process is started from cargo and thus calls clang and thus I hit the same bug I hope to fix with this change. Hopefully fixes #59034.,THUMBS_UP,2019-04-21T00:08:19Z,mati865,NA https://github.com/rust-lang/rust/pull/59186,MERGED,2019-03-14T16:46:34Z,2019-04-03T08:32:45Z,improve worst-case performance of BTreeSet intersection v3,ssomers,f5fee8fd7d2bd25ac63b9ea44925f9ac2f61c3d2,3,improve worst-case performance of BTreeSet difference and intersection,HEART,2019-03-27T22:33:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59186,MERGED,2019-03-14T16:46:34Z,2019-04-03T08:32:45Z,improve worst-case performance of BTreeSet intersection v3,ssomers,f5fee8fd7d2bd25ac63b9ea44925f9ac2f61c3d2,3,improve worst-case performance of BTreeSet difference and intersection,THUMBS_UP,2019-04-13T15:34:08Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/59195,MERGED,2019-03-14T23:12:07Z,2019-03-25T03:52:32Z,When moving out of a for loop head suggest borrowing it,estebank,66202c113a5397198757d1eb09b78eb0b9b368b1,1,Add nll test,HEART,2019-03-21T05:15:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59197,MERGED,2019-03-14T23:50:53Z,2019-03-27T08:58:44Z,Exclude old book redirect stubs from search engines,kornelski,8b5a748d507a30c8d97dca55bd2c3f0f0455e34e,2,Exclude old book redirect stubs from search engines,THUMBS_UP,2019-03-15T01:37:02Z,estebank,NA https://github.com/rust-lang/rust/pull/59197,MERGED,2019-03-14T23:50:53Z,2019-03-27T08:58:44Z,Exclude old book redirect stubs from search engines,kornelski,8b5a748d507a30c8d97dca55bd2c3f0f0455e34e,2,Exclude old book redirect stubs from search engines,HEART,2019-03-15T15:37:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59197,MERGED,2019-03-14T23:50:53Z,2019-03-27T08:58:44Z,Exclude old book redirect stubs from search engines,kornelski,8b5a748d507a30c8d97dca55bd2c3f0f0455e34e,2,Exclude old book redirect stubs from search engines,THUMBS_UP,2019-03-16T07:59:36Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/59197,MERGED,2019-03-14T23:50:53Z,2019-03-27T08:58:44Z,Exclude old book redirect stubs from search engines,kornelski,8b5a748d507a30c8d97dca55bd2c3f0f0455e34e,2,Exclude old book redirect stubs from search engines,HEART,2019-03-16T07:59:38Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/59197,MERGED,2019-03-14T23:50:53Z,2019-03-27T08:58:44Z,Exclude old book redirect stubs from search engines,kornelski,8b5a748d507a30c8d97dca55bd2c3f0f0455e34e,2,Exclude old book redirect stubs from search engines,THUMBS_UP,2019-03-18T18:16:48Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59205,CLOSED,2019-03-15T10:38:56Z,2019-12-22T07:28:14Z,Turn HIR lowering into a query,Zoxc,NA,NA,NA,HEART,2019-03-15T16:17:51Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59205,CLOSED,2019-03-15T10:38:56Z,2019-12-22T07:28:14Z,Turn HIR lowering into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-18T21:23:41Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59205,CLOSED,2019-03-15T10:38:56Z,2019-12-22T07:28:14Z,Turn HIR lowering into a query,Zoxc,NA,NA,NA,THUMBS_UP,2019-07-10T15:16:00Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/59231,MERGED,2019-03-16T11:13:15Z,2019-03-16T17:52:58Z,Stabilize Option::copied,matklad,08f264d5762fc8cf817288084c03ce0d53ecb85b,2,Stabilize Option::copied closes https://github.com/rust-lang/rust/issues/57126,HOORAY,2019-04-27T00:47:21Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/59231,MERGED,2019-03-16T11:13:15Z,2019-03-16T17:52:58Z,Stabilize Option::copied,matklad,08f264d5762fc8cf817288084c03ce0d53ecb85b,2,Stabilize Option::copied closes https://github.com/rust-lang/rust/issues/57126,HOORAY,2019-05-08T21:16:48Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/59253,MERGED,2019-03-17T11:42:00Z,2019-03-20T08:26:18Z,Calculate Docker cache hash precisely from Dockerfile's dependencies,kennytm,07aee1df4427bcc2be5e9f6be5c853a0f6987b40,1,Calculate Docker cache hash precisely from Dockerfile's dependencies `src/ci/docker` so that when files under `dist-x86_64-linux` is changed its dependent image `dist-i686-linux` will also be rebuilt. However this ultraconservative solution caused the `dist-i686-linux` to be rebuilt every time an irrelevant Dockerfile (e.g. the PowerPC ones) is changed which increases the building time beyond 3 hours and forcing a spurious but expected failure. This commit instead parses the Dockerfile itself and look for the actual dependencies. The scripts needs to be copied into the Docker image which must be done with the COPY command so we just need to find all lines with a COPY command and add the source file into the hash calculator. Note: this script only handles single-lined COPY command in the form `COPY src1 src2 src3 dst` since these are the only variant used inside this repository.,THUMBS_UP,2019-03-17T12:16:15Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/59253,MERGED,2019-03-17T11:42:00Z,2019-03-20T08:26:18Z,Calculate Docker cache hash precisely from Dockerfile's dependencies,kennytm,07aee1df4427bcc2be5e9f6be5c853a0f6987b40,1,Calculate Docker cache hash precisely from Dockerfile's dependencies `src/ci/docker` so that when files under `dist-x86_64-linux` is changed its dependent image `dist-i686-linux` will also be rebuilt. However this ultraconservative solution caused the `dist-i686-linux` to be rebuilt every time an irrelevant Dockerfile (e.g. the PowerPC ones) is changed which increases the building time beyond 3 hours and forcing a spurious but expected failure. This commit instead parses the Dockerfile itself and look for the actual dependencies. The scripts needs to be copied into the Docker image which must be done with the COPY command so we just need to find all lines with a COPY command and add the source file into the hash calculator. Note: this script only handles single-lined COPY command in the form `COPY src1 src2 src3 dst` since these are the only variant used inside this repository.,THUMBS_UP,2019-03-18T14:05:57Z,mati865,NA https://github.com/rust-lang/rust/pull/59253,MERGED,2019-03-17T11:42:00Z,2019-03-20T08:26:18Z,Calculate Docker cache hash precisely from Dockerfile's dependencies,kennytm,07aee1df4427bcc2be5e9f6be5c853a0f6987b40,1,Calculate Docker cache hash precisely from Dockerfile's dependencies `src/ci/docker` so that when files under `dist-x86_64-linux` is changed its dependent image `dist-i686-linux` will also be rebuilt. However this ultraconservative solution caused the `dist-i686-linux` to be rebuilt every time an irrelevant Dockerfile (e.g. the PowerPC ones) is changed which increases the building time beyond 3 hours and forcing a spurious but expected failure. This commit instead parses the Dockerfile itself and look for the actual dependencies. The scripts needs to be copied into the Docker image which must be done with the COPY command so we just need to find all lines with a COPY command and add the source file into the hash calculator. Note: this script only handles single-lined COPY command in the form `COPY src1 src2 src3 dst` since these are the only variant used inside this repository.,THUMBS_UP,2019-03-18T18:16:21Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59260,CLOSED,2019-03-17T18:33:02Z,2019-04-29T19:55:08Z,Introduce the assert_matches! macro family,Kerollmops,NA,NA,NA,THUMBS_UP,2019-03-17T19:49:31Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/59260,CLOSED,2019-03-17T18:33:02Z,2019-04-29T19:55:08Z,Introduce the assert_matches! macro family,Kerollmops,NA,NA,NA,THUMBS_UP,2019-03-18T01:09:41Z,kinggoesgaming,hunar.roop@gmail.com https://github.com/rust-lang/rust/pull/59260,CLOSED,2019-03-17T18:33:02Z,2019-04-29T19:55:08Z,Introduce the assert_matches! macro family,Kerollmops,NA,NA,NA,THUMBS_UP,2020-10-10T23:27:48Z,wchargin,NA https://github.com/rust-lang/rust/pull/59262,MERGED,2019-03-17T18:39:34Z,2019-04-02T16:18:15Z,Remove duplicated code from Iterator::{ne lt le gt ge},timvermeulen,075b2697e47e9370dcf2d38f01469b38bd4d903e,1,Simplify Iterator::{lt gt},ROCKET,2019-03-18T15:03:59Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/59262,MERGED,2019-03-17T18:39:34Z,2019-04-02T16:18:15Z,Remove duplicated code from Iterator::{ne lt le gt ge},timvermeulen,075b2697e47e9370dcf2d38f01469b38bd4d903e,1,Simplify Iterator::{lt gt},ROCKET,2019-03-30T11:42:14Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/59262,MERGED,2019-03-17T18:39:34Z,2019-04-02T16:18:15Z,Remove duplicated code from Iterator::{ne lt le gt ge},timvermeulen,075b2697e47e9370dcf2d38f01469b38bd4d903e,1,Simplify Iterator::{lt gt},ROCKET,2019-04-10T12:46:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59262,MERGED,2019-03-17T18:39:34Z,2019-04-02T16:18:15Z,Remove duplicated code from Iterator::{ne lt le gt ge},timvermeulen,075b2697e47e9370dcf2d38f01469b38bd4d903e,1,Simplify Iterator::{lt gt},ROCKET,2019-04-11T05:46:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59266,MERGED,2019-03-18T03:11:48Z,2019-03-23T00:33:37Z,Do not complain about non-existing fields after parse recovery,estebank,757eb679927e2c85457f567487e887eb080eb7cb,3,review comments,HOORAY,2019-03-27T14:15:14Z,krdln,NA https://github.com/rust-lang/rust/pull/59266,MERGED,2019-03-18T03:11:48Z,2019-03-23T00:33:37Z,Do not complain about non-existing fields after parse recovery,estebank,757eb679927e2c85457f567487e887eb080eb7cb,3,review comments,HOORAY,2019-03-27T19:02:20Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/59266,MERGED,2019-03-18T03:11:48Z,2019-03-23T00:33:37Z,Do not complain about non-existing fields after parse recovery,estebank,757eb679927e2c85457f567487e887eb080eb7cb,3,review comments,HOORAY,2019-03-28T18:04:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59273,MERGED,2019-03-18T11:40:02Z,2019-03-23T00:33:38Z,some small HIR doc improvements,llogiq,37789c4a1d6e46af2ef619f5640c05764b875dbb,1,Update src/librustc/hir/mod.rs Co-Authored-By: llogiq ,THUMBS_UP,2019-03-18T12:06:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/59275,MERGED,2019-03-18T13:05:18Z,2019-03-19T17:59:00Z,Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs,regexident,698bbe52533e8ef07793b6a696cc89015a9dc7f6,8,Replaced self-reflective explicit types with clearer `Self` or `Self::…` in stdlib docs,THUMBS_UP,2019-03-18T15:30:09Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/59276,MERGED,2019-03-18T13:24:04Z,2019-05-25T19:01:03Z,Cleanup (pretty) printing of `ty::Const`,oli-obk,0b732aa6071fd165d8f2c0972495b5e058699b47,1,Update nll ui tests,HEART,2019-05-14T23:26:43Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/59276,MERGED,2019-03-18T13:24:04Z,2019-05-25T19:01:03Z,Cleanup (pretty) printing of `ty::Const`,oli-obk,0b732aa6071fd165d8f2c0972495b5e058699b47,1,Update nll ui tests,HEART,2019-05-25T21:15:15Z,estebank,NA https://github.com/rust-lang/rust/pull/59280,MERGED,2019-03-18T19:00:10Z,2019-03-19T17:59:00Z,Stabilize refcell_map_split feature,joshlf,de4be2cd85b5c8b707185d0e1f10b3373be0a3d5,2,Stabilize refcell_map_split feature - Closes #51476,THUMBS_UP,2019-03-28T07:40:51Z,mikhail-krainik,NA https://github.com/rust-lang/rust/pull/59282,CLOSED,2019-03-18T19:54:35Z,2019-12-22T07:28:44Z,Turn macro expansion and name resolution into a query,Zoxc,NA,NA,NA,EYES,2019-03-18T21:26:56Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/59282,CLOSED,2019-03-18T19:54:35Z,2019-12-22T07:28:44Z,Turn macro expansion and name resolution into a query,Zoxc,NA,NA,NA,EYES,2019-03-19T13:46:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59282,CLOSED,2019-03-18T19:54:35Z,2019-12-22T07:28:44Z,Turn macro expansion and name resolution into a query,Zoxc,NA,NA,NA,EYES,2019-03-21T11:50:51Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-18T20:27:44Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-18T20:57:11Z,lqd,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-18T21:01:51Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-18T22:46:49Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-19T01:19:22Z,rrbutani,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-19T18:28:58Z,killercup,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-19T19:23:14Z,estebank,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-20T12:42:58Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-21T05:09:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-03-31T12:12:02Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-04-03T16:24:37Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",ROCKET,2019-04-03T20:51:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",ROCKET,2019-04-03T23:33:49Z,krdln,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",ROCKET,2019-04-04T07:24:19Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-04-04T18:28:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-05-04T21:45:53Z,panaman67,NA https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",HEART,2019-08-21T11:29:01Z,syuilo,Syuilotan@yahoo.co.jp https://github.com/rust-lang/rust/pull/59283,MERGED,2019-03-18T20:11:58Z,2019-03-28T05:44:15Z,Make ASCII case conversions more than 4× faster,SimonSapin,7fad370fe9dc000f6f6f497a1939de6196e2c4fc,1,"ASCII uppercase: add ""subtract multiplied bool"" benchmark",ROCKET,2019-08-21T11:29:02Z,syuilo,Syuilotan@yahoo.co.jp https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-03-21T00:54:57Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-03-21T02:20:19Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-04-04T07:25:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-04-05T06:27:49Z,moshg,NA https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-04-05T10:02:46Z,gralpli,NA https://github.com/rust-lang/rust/pull/59284,MERGED,2019-03-18T21:47:37Z,2019-03-28T05:44:16Z,adjust MaybeUninit API to discussions,RalfJung,853ae8d931c3fe4cd303edf7d80271c1930b9654,5,fix some uses I missed,THUMBS_UP,2019-04-07T01:22:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-19T13:58:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-20T17:42:34Z,aheart,NA https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-21T04:14:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-21T05:06:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-21T21:01:51Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-25T23:24:11Z,estebank,NA https://github.com/rust-lang/rust/pull/59285,MERGED,2019-03-18T22:36:08Z,2019-03-27T05:26:07Z,Rebase LLVM to 8.0.0 final,cuviper,0dabf8c835d61b2f7df454be362c23ba6590c761,3,Rebase LLVM to 8.0.0 final,HEART,2019-03-27T01:10:02Z,jseyfried,NA https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HEART,2019-03-20T20:27:52Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HEART,2019-03-20T21:50:30Z,hcpl,NA https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HOORAY,2019-03-23T20:13:02Z,najamelan,NA https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HEART,2019-03-30T17:34:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HEART,2019-04-02T16:25:31Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HEART,2019-04-04T17:19:35Z,intellild,intellild@outlook.com https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HOORAY,2019-04-04T17:19:36Z,intellild,intellild@outlook.com https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HOORAY,2019-04-09T17:25:12Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HOORAY,2019-04-11T05:45:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59286,MERGED,2019-03-19T00:58:01Z,2019-04-02T16:18:16Z,Refactor async fn return type lowering,cramertj,749349fc9f7b12f212bca9ba2297e463328cb701,13,Refactor async fn return type lowering async fn now lowers directly to an existential type declaration rather than reusing the `impl Trait` return type lowering. As part of this it lowers all argument-position elided lifetimes using the in-band-lifetimes machinery creating fresh parameter names for each of them using each lifetime parameter as a generic argument to the generated existential type. This doesn't currently successfully allow multiple argument-position elided lifetimes since `existential type` doesn't yet support multiple lifetimes where neither outlive the other. This requires a separate fix.,HOORAY,2021-08-05T01:49:19Z,arazmj,arazmj@gmail.com https://github.com/rust-lang/rust/pull/59288,MERGED,2019-03-19T06:19:09Z,2019-05-11T01:41:41Z,[let_chains 1/6] Remove hir::ExprKind::If,Centril,f9cc5a65d24270fac44a7ccf709d7a7efd7b525d,1,check_match: add FIXME for removing of hack.,THUMBS_UP,2019-03-21T02:35:41Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/59288,MERGED,2019-03-19T06:19:09Z,2019-05-11T01:41:41Z,[let_chains 1/6] Remove hir::ExprKind::If,Centril,f9cc5a65d24270fac44a7ccf709d7a7efd7b525d,1,check_match: add FIXME for removing of hack.,HEART,2019-04-24T23:23:04Z,estebank,NA https://github.com/rust-lang/rust/pull/59288,MERGED,2019-03-19T06:19:09Z,2019-05-11T01:41:41Z,[let_chains 1/6] Remove hir::ExprKind::If,Centril,f9cc5a65d24270fac44a7ccf709d7a7efd7b525d,1,check_match: add FIXME for removing of hack.,THUMBS_UP,2019-05-16T04:45:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59291,MERGED,2019-03-19T13:01:56Z,2019-03-23T00:33:40Z,Make Option no larger than ThreadId with NonZeroU64,SimonSapin,c1d9191fa576c600775b4fbb90a3d09ca5e0fa0b,1,Add a test for size_of Option,HEART,2019-03-21T05:06:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59291,MERGED,2019-03-19T13:01:56Z,2019-03-23T00:33:40Z,Make Option no larger than ThreadId with NonZeroU64,SimonSapin,c1d9191fa576c600775b4fbb90a3d09ca5e0fa0b,1,Add a test for size_of Option,HEART,2019-03-27T11:49:56Z,frol,NA https://github.com/rust-lang/rust/pull/59297,MERGED,2019-03-19T19:58:03Z,2019-03-23T00:33:40Z,convert field/method confusion help to suggestions,euclio,a291d4e94cbcd9082f942147cde92b8ae5a39cdc,5,convert field/method confusion help to suggestions,HEART,2019-03-19T20:25:04Z,estebank,NA https://github.com/rust-lang/rust/pull/59303,MERGED,2019-03-19T23:44:05Z,2019-03-29T14:56:20Z,replace llvm-rebuild-trigger with submodule commit hash,euclio,e1daa36ba7df88788c2684bbe5ff6eb37f1cda69,2,replace llvm-rebuild-trigger with commit hash,THUMBS_UP,2019-03-20T12:38:40Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59303,MERGED,2019-03-19T23:44:05Z,2019-03-29T14:56:20Z,replace llvm-rebuild-trigger with submodule commit hash,euclio,e1daa36ba7df88788c2684bbe5ff6eb37f1cda69,2,replace llvm-rebuild-trigger with commit hash,THUMBS_UP,2019-03-20T16:53:34Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/59303,MERGED,2019-03-19T23:44:05Z,2019-03-29T14:56:20Z,replace llvm-rebuild-trigger with submodule commit hash,euclio,e1daa36ba7df88788c2684bbe5ff6eb37f1cda69,2,replace llvm-rebuild-trigger with commit hash,THUMBS_UP,2019-03-29T14:04:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59303,MERGED,2019-03-19T23:44:05Z,2019-03-29T14:56:20Z,replace llvm-rebuild-trigger with submodule commit hash,euclio,e1daa36ba7df88788c2684bbe5ff6eb37f1cda69,2,replace llvm-rebuild-trigger with commit hash,HOORAY,2019-03-30T10:20:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/59303,MERGED,2019-03-19T23:44:05Z,2019-03-29T14:56:20Z,replace llvm-rebuild-trigger with submodule commit hash,euclio,e1daa36ba7df88788c2684bbe5ff6eb37f1cda69,2,replace llvm-rebuild-trigger with commit hash,HOORAY,2019-05-31T00:17:12Z,varkor,NA https://github.com/rust-lang/rust/pull/59330,MERGED,2019-03-20T22:25:37Z,2019-03-27T08:58:48Z,Improve the documentation for std::convert (From Into AsRef and AsMut),DevQps,6c479c3d02e134dbc8812582c3241fa8747c35d7,1,Formatting changes including better wrapping and creating short summary lines.,THUMBS_UP,2019-03-22T02:58:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/59338,CLOSED,2019-03-21T10:42:17Z,2019-08-03T04:45:19Z,Turn parsing into a query,Zoxc,NA,NA,NA,ROCKET,2019-03-23T20:20:56Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59338,CLOSED,2019-03-21T10:42:17Z,2019-08-03T04:45:19Z,Turn parsing into a query,Zoxc,NA,NA,NA,ROCKET,2019-04-22T05:51:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/59338,CLOSED,2019-03-21T10:42:17Z,2019-08-03T04:45:19Z,Turn parsing into a query,Zoxc,NA,NA,NA,ROCKET,2019-05-15T15:39:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59349,CLOSED,2019-03-21T21:46:48Z,2019-04-11T18:14:33Z,Update pulldown-cmark version,GuillaumeGomez,NA,NA,NA,HOORAY,2019-03-21T22:54:31Z,ehuss,NA https://github.com/rust-lang/rust/pull/59349,CLOSED,2019-03-21T21:46:48Z,2019-04-11T18:14:33Z,Update pulldown-cmark version,GuillaumeGomez,NA,NA,NA,HOORAY,2019-03-25T12:19:04Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/59351,MERGED,2019-03-21T22:44:38Z,2019-03-28T12:12:39Z,Include llvm-ar with llvm-tools component,phil-opp,45e9accecb18cbdbadad05abeed860f68d7a46f3,1,Include llvm-ar with llvm-tools component,HEART,2019-03-23T16:24:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/59351,MERGED,2019-03-21T22:44:38Z,2019-03-28T12:12:39Z,Include llvm-ar with llvm-tools component,phil-opp,45e9accecb18cbdbadad05abeed860f68d7a46f3,1,Include llvm-ar with llvm-tools component,HEART,2019-03-28T16:00:51Z,nhynes,nhynes@nhynes.com https://github.com/rust-lang/rust/pull/59363,MERGED,2019-03-22T11:57:28Z,2019-03-29T01:17:35Z,#59361 Moved rustc edition opt to short list,peterjoel,3eb4eae96d2e400c2a99146491367bffa34ba29e,1,Fixes #59361,THUMBS_UP,2019-03-22T17:37:55Z,estebank,NA https://github.com/rust-lang/rust/pull/59363,MERGED,2019-03-22T11:57:28Z,2019-03-29T01:17:35Z,#59361 Moved rustc edition opt to short list,peterjoel,3eb4eae96d2e400c2a99146491367bffa34ba29e,1,Fixes #59361,THUMBS_UP,2019-03-22T18:14:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/59369,MERGED,2019-03-22T17:55:15Z,2019-08-05T22:49:00Z,`unwrap_usize` should at least try to evaluate the underlying constant,oli-obk,bd57498e7d509168609a685b264289643ef8b2c3,1,Get rid of one more useless `lift` invocation,THUMBS_UP,2019-03-24T09:59:32Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/59370,MERGED,2019-03-22T18:31:42Z,2019-03-23T00:33:50Z,Rollup of 18 pull requests,Centril,cf8c73936d48560b50d98a299c98fd35e5b4581e,1,Rollup merge of #59360 - LukasKalbertodt:patch-2 r=rkruppe Add tracking issue number for `seek_convenience` We forgot to do that in #58422,HOORAY,2019-03-23T00:13:17Z,mati865,NA https://github.com/rust-lang/rust/pull/59372,MERGED,2019-03-22T19:05:29Z,2019-03-28T05:44:20Z,add rustfix-able suggestions to trim_{left right} deprecations,euclio,b34a71b7daf0f770cd5e7f9c36be960e32d2b167,1,add suggestions to trim_{left right} deprecations,HEART,2019-03-24T05:17:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59382,MERGED,2019-03-23T11:54:32Z,2019-03-25T00:29:20Z,Separate `DefId`s for variants and their constructors,davidtwco,23cae1d3f06ccb339f2f780e63b6d6d5c1c6a9da,16,Re-order fields in `Def::Ctor`. This commit moves the `DefId` field of `Def::Ctor` to be the first field.,HEART,2019-03-25T02:48:05Z,estebank,NA https://github.com/rust-lang/rust/pull/59382,MERGED,2019-03-23T11:54:32Z,2019-03-25T00:29:20Z,Separate `DefId`s for variants and their constructors,davidtwco,23cae1d3f06ccb339f2f780e63b6d6d5c1c6a9da,16,Re-order fields in `Def::Ctor`. This commit moves the `DefId` field of `Def::Ctor` to be the first field.,HEART,2019-05-14T01:50:31Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/59390,MERGED,2019-03-24T01:27:40Z,2019-03-28T05:44:22Z,Make `ptr::eq` documentation mention fat-pointer behavior,czipperz,61b6c56f50af6ca2848f4bd623c8b2cd2b24cb77,1,Minor rewordings and add `dyn` keyword,HEART,2019-03-28T08:06:56Z,derekdreery,NA https://github.com/rust-lang/rust/pull/59398,MERGED,2019-03-24T13:50:54Z,2019-03-29T01:17:38Z,Add a way to track Rustfix UI test coverage,phansch,d808bd46515e4de5d21a62b2c1557ac9d2751846,4,Save coverage file in build_base path not /tmp,HEART,2019-03-24T21:29:28Z,killercup,NA https://github.com/rust-lang/rust/pull/59401,MERGED,2019-03-24T16:54:00Z,2019-03-29T11:21:15Z,bootstrap: build crates under libtest with -Z emit-stack-sizes,japaric,7d365cf27f4249fc9b61ba8abfc813abe43f1cb7,2,compile all crates under test w/ -Zemit-stack-sizes,THUMBS_UP,2019-03-25T17:17:10Z,MarkSwanson,NA https://github.com/rust-lang/rust/pull/59409,CLOSED,2019-03-25T10:32:10Z,2019-04-08T14:39:24Z,[WIP] HACK: rustc_typeck: don't pretend constant exprs don't have generics in scope.,eddyb,NA,NA,NA,THUMBS_UP,2019-03-26T02:12:31Z,estebank,NA https://github.com/rust-lang/rust/pull/59413,MERGED,2019-03-25T14:05:51Z,2019-03-28T12:12:42Z,HirIdify hir::ItemId,Zoxc,f7c66fb625ad61bcac325c844180c1c32a04aa13,1,Allocate HIR id counters on demand,HOORAY,2019-03-25T14:41:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59424,MERGED,2019-03-25T23:39:30Z,2019-03-27T08:58:53Z,Fix code block display in portability element in dark theme,GuillaumeGomez,868833f9a6d739f6bcb7ab9772f3a79c2c750559,2,Fix code block display in portability element in dark theme,HEART,2019-03-26T00:07:38Z,ehuss,NA https://github.com/rust-lang/rust/pull/59439,MERGED,2019-03-26T14:17:03Z,2019-03-28T05:44:27Z,Generalize diagnostic for `x = y` where `bool` is the expected type,Centril,ce1c5e0a61ab05bd0a944e27c91e2001844516d9,2,add negative test case in assignment-expected-bool,HEART,2019-03-26T19:44:59Z,estebank,NA https://github.com/rust-lang/rust/pull/59439,MERGED,2019-03-26T14:17:03Z,2019-03-28T05:44:27Z,Generalize diagnostic for `x = y` where `bool` is the expected type,Centril,ce1c5e0a61ab05bd0a944e27c91e2001844516d9,2,add negative test case in assignment-expected-bool,HEART,2019-03-26T19:48:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59439,MERGED,2019-03-26T14:17:03Z,2019-03-28T05:44:27Z,Generalize diagnostic for `x = y` where `bool` is the expected type,Centril,ce1c5e0a61ab05bd0a944e27c91e2001844516d9,2,add negative test case in assignment-expected-bool,HEART,2019-03-31T12:09:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59441,MERGED,2019-03-26T15:58:12Z,2019-03-28T12:12:44Z,Remove the block on natvis for lld-link.,TheGoddessInari,2a4281998b6cac4893dabea52d38518973bac41a,1,Remove the block on natvis for lld-link.,HEART,2019-08-16T22:06:52Z,MaulingMonkey,git@maulingmonkey.com https://github.com/rust-lang/rust/pull/59443,CLOSED,2019-03-26T16:29:14Z,2019-06-21T17:35:42Z,Add unstable cfg_if! macro to libcore,gnzlbg,NA,NA,NA,THUMBS_UP,2019-03-31T20:51:08Z,faern,NA https://github.com/rust-lang/rust/pull/59443,CLOSED,2019-03-26T16:29:14Z,2019-06-21T17:35:42Z,Add unstable cfg_if! macro to libcore,gnzlbg,NA,NA,NA,THUMBS_UP,2019-04-19T16:01:57Z,moshg,NA https://github.com/rust-lang/rust/pull/59456,MERGED,2019-03-27T05:23:49Z,2019-03-28T12:12:46Z,Add documentation about `for` used as higher ranked trait bounds,czipperz,25452501ee53c60445b9774fa69e2dc2134ddc44,1,Move link to rust book to next line to pass 100 column limit,HEART,2019-03-27T08:44:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T16:34:51Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-27T16:34:56Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T17:35:41Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-27T17:50:06Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-27T18:21:54Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T18:32:51Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-27T18:32:52Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-27T18:56:03Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T19:16:54Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-27T19:28:32Z,Dispersia,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T19:28:32Z,Dispersia,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T20:19:32Z,maxmcd,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-27T21:17:14Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T21:17:16Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-27T21:59:40Z,theduke,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-03-28T02:06:29Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-28T02:06:48Z,chicoxyzzy,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T03:24:56Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-28T04:29:21Z,rrbutani,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T04:29:23Z,rrbutani,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T08:01:15Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T08:13:24Z,Meralis40,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T08:43:49Z,moshg,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-28T08:43:50Z,moshg,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-28T09:09:39Z,matprec,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T12:49:13Z,Boiethios,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-03-28T12:49:14Z,Boiethios,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-28T13:16:15Z,marvinhagemeister,hello@marvinh.dev https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-28T20:59:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-28T20:59:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-29T00:06:53Z,mstallmo,masonstallmo@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-29T00:06:54Z,mstallmo,masonstallmo@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-03-29T06:21:51Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-03-29T06:21:52Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-29T06:21:53Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-03-29T12:37:41Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-03-29T16:17:41Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-04-01T14:21:26Z,chpio,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-04-04T04:27:10Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-04-04T04:27:13Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-04-16T06:27:33Z,keith-hall,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-04-30T23:58:42Z,klimashkin,klimashkin@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-05-10T17:42:30Z,darshanime,deathbullet@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-05-10T17:42:34Z,darshanime,deathbullet@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-05-21T10:28:28Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-05-21T20:43:33Z,icefoxen,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-05-23T22:42:58Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2019-07-09T07:27:22Z,sagudev,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-07-10T13:38:43Z,Itanq,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-07-10T13:38:46Z,Itanq,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-09-27T13:23:54Z,qzmfranklin,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2019-10-17T01:05:15Z,Type1J,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2019-10-17T01:05:17Z,Type1J,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2019-10-17T01:05:19Z,Type1J,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2020-04-24T10:28:24Z,fominok,fominok@hotmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2020-06-04T17:21:16Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2020-06-04T17:21:17Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2020-07-30T06:32:25Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2020-07-30T06:32:27Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2020-07-30T06:32:28Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2020-07-30T06:32:29Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,THUMBS_UP,2020-09-18T12:55:50Z,thedodd,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2020-09-18T12:55:53Z,thedodd,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HEART,2020-09-18T12:55:54Z,thedodd,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,ROCKET,2020-09-18T12:55:55Z,thedodd,NA https://github.com/rust-lang/rust/pull/59464,MERGED,2019-03-27T16:23:34Z,2019-03-30T06:06:16Z,Add a new wasm32-unknown-wasi target,alexcrichton,ace71240d233e71fcc6e3824fa2e5e05697fd2cc,33,Add a new wasm32-unknown-wasi target This commit adds a new wasm32-based target distributed through rustup supported in the standard library and implemented in the compiler. The `wasm32-unknown-wasi` target is intended to be a WebAssembly target which matches the [WASI proposal recently announced.][LINK]. In summary the WASI target is an effort to define a standard set of syscalls for WebAssembly modules allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The wasi target in libstd is still somewhat bare bones. This PR does not fill out the filesystem networking threads etc. Instead it only provides the most basic of integration with the wasi syscalls enabling features like: * `Instant::now` and `SystemTime::now` work * `env::args` is hooked up * `env::vars` will look up environment variables * `println!` will print to standard out * `process::{exit abort}` should be hooked up appropriately None of these APIs can work natively on the `wasm32-unknown-unknown` target but with the assumption of the WASI set of syscalls we're able to provide implementations of these syscalls that engines can implement. Currently the primary engine implementing wasi is [wasmtime] but more will surely emerge! In terms of future development of libstd I think this is something we'll probably want to discuss. The purpose of the WASI target is to provide a standardized set of syscalls but it's *also* to provide a standard C sysroot for compiling C/C++ programs. This means it's intended that functions like `read` and `write` are implemented for this target with a relatively standard definition and implementation. It's unclear therefore how we want to expose file descriptors and how we'll want to implement system primitives. For example should `std::fs::File` have a libc-based file descriptor underneath it? The raw wasi file descriptor? We'll see! Currently these details are all intentionally hidden and things we can change over time. A `WasiFd` sample struct was added to the standard library as part of this commit but it's not currently used. It shows how all the wasi syscalls could be ergonomically bound in Rust and they offer a possible implementation of primitives like `std::fs::File` if we bind wasi file descriptors exactly. Apart from the standard library there's also the matter of how this target is integrated with respect to its C standard library. The reference sysroot for example provides managment of standard unix file descriptors and also standard APIs like `open` (as opposed to the relative `openat` inspiration for the wasi ssycalls). Currently the standard library relies on the C sysroot symbols for operations such as environment management process exit and `read`/`write` of stdio fds. We want these operations in Rust to be interoperable with C if they're used in the same process. Put another way if Rust and C are linked into the same WebAssembly binary they should work together but that requires that the same C standard library is used. We also however want the `wasm32-unknown-wasi` target to be usable-by-default with the Rust compiler without requiring a separate toolchain to get downloaded and configured. With that in mind there's two modes of operation for the `wasm32-unknown-wasi` target: 1. By default the C standard library is statically provided inside of `liblibc.rlib` distributed as part of the sysroot. This means that you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're good to go a fully workable wasi binary pops out. This is incompatible with linking in C code however which may be compiled against a different sysroot than the Rust code was previously compiled against. In this mode the default of `rust-lld` is used to link binaries. 2. For linking with C code the `-C target-feature=-crt-static` flag needs to be passed. This takes inspiration from the musl target for this flag but the idea is that you're no longer using the provided static C runtime but rather one will be provided externally. This flag is intended to also get coupled with an external `clang` compiler configured with its own sysroot. Therefore you'll typically use this flag with `-C linker=/path/to/clang-script-wrapper`. Using this mode the Rust code will continue to reference standard C symbols but the definition will be pulled in by the linker configured. Alright so that's all the current state of this PR. I suspect we'll definitely want to discuss this before landing of course! This PR is coupled with libc changes as well which I'll be posting shortly. [LINK]: [wasmtime]:,HOORAY,2021-01-07T06:00:58Z,GarfieldZHU,Garfield.bupt@gmail.com https://github.com/rust-lang/rust/pull/59467,MERGED,2019-03-27T17:21:59Z,2019-03-29T21:45:59Z,Better diagnostic for binary operation on BoxedValues,hgallagher1993,4644c3a6aa0ff0ad394175a029f5531728ecff31,9,Add check for when left and right overlap and change span for explanation to point at operator,HEART,2019-03-27T17:37:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59467,MERGED,2019-03-27T17:21:59Z,2019-03-29T21:45:59Z,Better diagnostic for binary operation on BoxedValues,hgallagher1993,4644c3a6aa0ff0ad394175a029f5531728ecff31,9,Add check for when left and right overlap and change span for explanation to point at operator,HEART,2019-03-27T17:41:05Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59467,MERGED,2019-03-27T17:21:59Z,2019-03-29T21:45:59Z,Better diagnostic for binary operation on BoxedValues,hgallagher1993,4644c3a6aa0ff0ad394175a029f5531728ecff31,9,Add check for when left and right overlap and change span for explanation to point at operator,HEART,2019-03-27T18:17:35Z,estebank,NA https://github.com/rust-lang/rust/pull/59468,MERGED,2019-03-27T17:38:47Z,2019-03-29T11:21:19Z,musl: build toolchain libs with -fPIC,mati865,c764890d7c508b401764c79bde9c0f3c430138e0,1,musl: build toolchain libs with -fPIC,HEART,2019-03-27T17:41:29Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/59468,MERGED,2019-03-27T17:38:47Z,2019-03-29T11:21:19Z,musl: build toolchain libs with -fPIC,mati865,c764890d7c508b401764c79bde9c0f3c430138e0,1,musl: build toolchain libs with -fPIC,HEART,2019-03-27T17:48:47Z,sfackler,NA https://github.com/rust-lang/rust/pull/59468,MERGED,2019-03-27T17:38:47Z,2019-03-29T11:21:19Z,musl: build toolchain libs with -fPIC,mati865,c764890d7c508b401764c79bde9c0f3c430138e0,1,musl: build toolchain libs with -fPIC,HEART,2019-03-29T01:47:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59468,MERGED,2019-03-27T17:38:47Z,2019-03-29T11:21:19Z,musl: build toolchain libs with -fPIC,mati865,c764890d7c508b401764c79bde9c0f3c430138e0,1,musl: build toolchain libs with -fPIC,HEART,2019-05-18T19:24:17Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/59476,MERGED,2019-03-28T05:23:52Z,2019-03-29T11:21:20Z,Use `SmallVec` in `TokenStreamBuilder`.,nnethercote,17a8aff20abdef46ae90801c85cc232e81443e1b,2,"Use `SmallVec` in `TokenStreamBuilder`. This reduces by 12% the number of allocations done for a ""clean incremental"" of `webrender_api` which reduces the instruction count by about 0.5%. It also reduces instruction counts by up to 1.4% across a range of rustc-perf benchmark runs.",THUMBS_UP,2019-03-28T15:37:58Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59476,MERGED,2019-03-28T05:23:52Z,2019-03-29T11:21:20Z,Use `SmallVec` in `TokenStreamBuilder`.,nnethercote,17a8aff20abdef46ae90801c85cc232e81443e1b,2,"Use `SmallVec` in `TokenStreamBuilder`. This reduces by 12% the number of allocations done for a ""clean incremental"" of `webrender_api` which reduces the instruction count by about 0.5%. It also reduces instruction counts by up to 1.4% across a range of rustc-perf benchmark runs.",THUMBS_UP,2019-03-28T20:57:41Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59476,MERGED,2019-03-28T05:23:52Z,2019-03-29T11:21:20Z,Use `SmallVec` in `TokenStreamBuilder`.,nnethercote,17a8aff20abdef46ae90801c85cc232e81443e1b,2,"Use `SmallVec` in `TokenStreamBuilder`. This reduces by 12% the number of allocations done for a ""clean incremental"" of `webrender_api` which reduces the instruction count by about 0.5%. It also reduces instruction counts by up to 1.4% across a range of rustc-perf benchmark runs.",HEART,2019-03-29T04:53:47Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59476,MERGED,2019-03-28T05:23:52Z,2019-03-29T11:21:20Z,Use `SmallVec` in `TokenStreamBuilder`.,nnethercote,17a8aff20abdef46ae90801c85cc232e81443e1b,2,"Use `SmallVec` in `TokenStreamBuilder`. This reduces by 12% the number of allocations done for a ""clean incremental"" of `webrender_api` which reduces the instruction count by about 0.5%. It also reduces instruction counts by up to 1.4% across a range of rustc-perf benchmark runs.",THUMBS_UP,2019-04-04T07:23:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59476,MERGED,2019-03-28T05:23:52Z,2019-03-29T11:21:20Z,Use `SmallVec` in `TokenStreamBuilder`.,nnethercote,17a8aff20abdef46ae90801c85cc232e81443e1b,2,"Use `SmallVec` in `TokenStreamBuilder`. This reduces by 12% the number of allocations done for a ""clean incremental"" of `webrender_api` which reduces the instruction count by about 0.5%. It also reduces instruction counts by up to 1.4% across a range of rustc-perf benchmark runs.",THUMBS_UP,2019-04-04T09:31:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59482,CLOSED,2019-03-28T09:56:41Z,2019-04-15T21:35:22Z,[WIP] BARE_TRAIT_OBJECTS -> Deny,Centril,NA,NA,NA,ROCKET,2019-03-28T09:57:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59482,CLOSED,2019-03-28T09:56:41Z,2019-04-15T21:35:22Z,[WIP] BARE_TRAIT_OBJECTS -> Deny,Centril,NA,NA,NA,ROCKET,2019-03-28T14:48:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59482,CLOSED,2019-03-28T09:56:41Z,2019-04-15T21:35:22Z,[WIP] BARE_TRAIT_OBJECTS -> Deny,Centril,NA,NA,NA,ROCKET,2019-04-02T09:19:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59482,CLOSED,2019-03-28T09:56:41Z,2019-04-15T21:35:22Z,[WIP] BARE_TRAIT_OBJECTS -> Deny,Centril,NA,NA,NA,THUMBS_UP,2019-04-02T09:20:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59496,MERGED,2019-03-28T18:00:06Z,2019-03-29T11:21:21Z,Remove unnecessary with_globals calls,Zoxc,e9a8befd2d4c0e19a9ec85cc047ef335a2b8b943,2,Remove unnecessary with_globals calls,HOORAY,2019-03-28T18:07:18Z,mati865,NA https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-04-01T05:39:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-04-02T16:30:42Z,mati865,NA https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-04-10T12:50:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-04-11T05:43:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HEART,2019-04-13T15:31:30Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-04-22T16:10:47Z,ExpHP,diagonaldevice@gmail.com https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-05-04T21:33:44Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,THUMBS_UP,2019-05-22T00:04:13Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,THUMBS_UP,2019-05-22T06:10:55Z,wayslog,NA https://github.com/rust-lang/rust/pull/59500,MERGED,2019-03-28T18:53:21Z,2019-04-05T20:33:37Z,Unsized rvalues: implement boxed closure impls. (2nd try),crlf0710,812d89c87d9346ac4b70426b67a8eb989a13c853,1,Fix expectations on some ui test in nll compare mode.,HOORAY,2019-05-22T19:12:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59507,MERGED,2019-03-28T22:47:31Z,2019-04-01T03:38:11Z,Optimize indentation in the pretty printer.,nnethercote,606f3158bf7dd2708b1efdde2e6de34f8eaebd7b,1,Optimize indentation in the pretty printer. Currently the pretty-printer calls `write!` for every space of indentation. On some workloads the indentation level can exceed 100 and a faster implementation reduces instruction counts by up to 7% on a few workloads.,HEART,2019-03-28T23:04:34Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59507,MERGED,2019-03-28T22:47:31Z,2019-04-01T03:38:11Z,Optimize indentation in the pretty printer.,nnethercote,606f3158bf7dd2708b1efdde2e6de34f8eaebd7b,1,Optimize indentation in the pretty printer. Currently the pretty-printer calls `write!` for every space of indentation. On some workloads the indentation level can exceed 100 and a faster implementation reduces instruction counts by up to 7% on a few workloads.,HEART,2019-04-04T07:23:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59507,MERGED,2019-03-28T22:47:31Z,2019-04-01T03:38:11Z,Optimize indentation in the pretty printer.,nnethercote,606f3158bf7dd2708b1efdde2e6de34f8eaebd7b,1,Optimize indentation in the pretty printer. Currently the pretty-printer calls `write!` for every space of indentation. On some workloads the indentation level can exceed 100 and a faster implementation reduces instruction counts by up to 7% on a few workloads.,HEART,2019-04-04T09:46:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59517,MERGED,2019-03-29T05:10:29Z,2019-04-04T11:12:36Z,Move query definitions over to the proc macro,Zoxc,45580684825c1855a4be5a7b4cd28525b24e7322,53,Update tests,HOORAY,2019-03-29T17:32:58Z,mati865,NA https://github.com/rust-lang/rust/pull/59517,MERGED,2019-03-29T05:10:29Z,2019-04-04T11:12:36Z,Move query definitions over to the proc macro,Zoxc,45580684825c1855a4be5a7b4cd28525b24e7322,53,Update tests,HOORAY,2019-03-31T18:11:13Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59525,MERGED,2019-03-29T14:07:37Z,2019-03-30T12:04:58Z,Whitelist some rustc attrs,pnkfelix,cbbd4d5f98da0c218958766355ea58d28d92f68d,1,Regression test for incremental treatment of rustc_scalar_valid_range_{start end}.,HEART,2019-03-30T02:46:51Z,varkor,NA https://github.com/rust-lang/rust/pull/59537,MERGED,2019-03-29T22:03:24Z,2019-03-30T12:05:00Z,Fix OnceWith docstring.,goffrie,7ce0b67272a760aff12505b5ca04357a3dc5c0ed,1,Fix OnceWith docstring. This was incorrectly copypasta'd from RepeatWith.,THUMBS_UP,2019-03-30T02:33:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/59544,MERGED,2019-03-30T01:00:57Z,2019-03-30T17:22:18Z,manifest: only include miri on the nightly channel,cuviper,b222b6fa7f4607ef1b0e8e5a950295550b3b1db0,1,manifest: only include miri on the nightly channel miri needs to build std with xargo which doesn't allow stable/beta: Therefore at this time there's no point in making miri available on any but the nightly channel. If we get a stable way to build `std` like [RFC 2663] then we can re-evaluate whether to start including miri perhaps still as `miri-preview`. [RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663,THUMBS_UP,2019-03-30T10:29:18Z,mati865,NA https://github.com/rust-lang/rust/pull/59544,MERGED,2019-03-30T01:00:57Z,2019-03-30T17:22:18Z,manifest: only include miri on the nightly channel,cuviper,b222b6fa7f4607ef1b0e8e5a950295550b3b1db0,1,manifest: only include miri on the nightly channel miri needs to build std with xargo which doesn't allow stable/beta: Therefore at this time there's no point in making miri available on any but the nightly channel. If we get a stable way to build `std` like [RFC 2663] then we can re-evaluate whether to start including miri perhaps still as `miri-preview`. [RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663,THUMBS_UP,2019-03-30T12:29:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/59544,MERGED,2019-03-30T01:00:57Z,2019-03-30T17:22:18Z,manifest: only include miri on the nightly channel,cuviper,b222b6fa7f4607ef1b0e8e5a950295550b3b1db0,1,manifest: only include miri on the nightly channel miri needs to build std with xargo which doesn't allow stable/beta: Therefore at this time there's no point in making miri available on any but the nightly channel. If we get a stable way to build `std` like [RFC 2663] then we can re-evaluate whether to start including miri perhaps still as `miri-preview`. [RFC 2663]: https://github.com/rust-lang/rfcs/pull/2663,THUMBS_UP,2019-03-30T14:04:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59545,MERGED,2019-03-30T02:15:41Z,2019-05-24T03:06:56Z,Use arenas to avoid Lrc in queries #2,Zoxc,d46e732e393a01884115e4506968606bd4da0d17,4,Update crate_variances and inferred_outlives_crate,EYES,2019-03-31T18:00:17Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59545,MERGED,2019-03-30T02:15:41Z,2019-05-24T03:06:56Z,Use arenas to avoid Lrc in queries #2,Zoxc,d46e732e393a01884115e4506968606bd4da0d17,4,Update crate_variances and inferred_outlives_crate,EYES,2019-05-23T02:58:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59546,MERGED,2019-03-30T02:27:58Z,2019-10-10T19:31:04Z,Add llvm.sideeffect to potential infinite loops and recursions,sfanxiang,e9acfa306f47a40be27e8cf72c55dbec35d94017,4,Generate llvm.sideeffect at function entry instead of call,HEART,2019-10-10T21:20:49Z,bluss,NA https://github.com/rust-lang/rust/pull/59566,MERGED,2019-03-30T16:47:12Z,2019-03-31T04:51:20Z,Use the existing LLVM GitInfo for checking rebuilds,cuviper,49b65e683dbf7b710deaede48a66211ce924c851,3,Don't ignore git for LLVM info,THUMBS_UP,2019-03-30T17:01:20Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/59581,MERGED,2019-03-31T12:24:52Z,2019-03-31T20:27:58Z,Stabilize refcell_replace_swap feature,jmcomets,c789a539a29b411b89411f8660d6ed2c2c4c4bbb,2,refcell_replace_swap: remove feature gate & obsolete documentation item,THUMBS_UP,2019-04-04T09:13:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59583,MERGED,2019-03-31T13:24:15Z,2019-03-31T20:27:58Z,match match match match match,oberien,55b7efe29f333427bdc0d664a13171490ee615cc,1,match match match match match,EYES,2019-03-31T13:27:55Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59583,MERGED,2019-03-31T13:24:15Z,2019-03-31T20:27:58Z,match match match match match,oberien,55b7efe29f333427bdc0d664a13171490ee615cc,1,match match match match match,LAUGH,2019-03-31T16:16:33Z,Emerentius,NA https://github.com/rust-lang/rust/pull/59583,MERGED,2019-03-31T13:24:15Z,2019-03-31T20:27:58Z,match match match match match,oberien,55b7efe29f333427bdc0d664a13171490ee615cc,1,match match match match match,LAUGH,2019-03-31T17:57:32Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59583,MERGED,2019-03-31T13:24:15Z,2019-03-31T20:27:58Z,match match match match match,oberien,55b7efe29f333427bdc0d664a13171490ee615cc,1,match match match match match,LAUGH,2019-03-31T19:10:31Z,kennytm,NA https://github.com/rust-lang/rust/pull/59583,MERGED,2019-03-31T13:24:15Z,2019-03-31T20:27:58Z,match match match match match,oberien,55b7efe29f333427bdc0d664a13171490ee615cc,1,match match match match match,LAUGH,2019-03-31T21:40:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59591,CLOSED,2019-03-31T18:54:03Z,2019-07-02T06:14:14Z,[WIP] Implement Needle API (RFC 2500),kennytm,NA,NA,NA,HOORAY,2019-05-07T18:26:10Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/59591,CLOSED,2019-03-31T18:54:03Z,2019-07-02T06:14:14Z,[WIP] Implement Needle API (RFC 2500),kennytm,NA,NA,NA,HOORAY,2019-05-26T13:50:33Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/59591,CLOSED,2019-03-31T18:54:03Z,2019-07-02T06:14:14Z,[WIP] Implement Needle API (RFC 2500),kennytm,NA,NA,NA,HOORAY,2019-06-03T20:58:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59591,CLOSED,2019-03-31T18:54:03Z,2019-07-02T06:14:14Z,[WIP] Implement Needle API (RFC 2500),kennytm,NA,NA,NA,HOORAY,2019-06-21T18:52:48Z,panaman67,NA https://github.com/rust-lang/rust/pull/59599,MERGED,2019-04-01T08:54:30Z,2019-04-06T01:36:14Z,Updated RELEASES.md for 1.34.0,XAMPPRocky,4ba30341402cd4c80018f6f61e38987897ceeb1b,1,Update RELEASES.md Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>,HEART,2019-04-01T14:32:37Z,ehuss,NA https://github.com/rust-lang/rust/pull/59599,MERGED,2019-04-01T08:54:30Z,2019-04-06T01:36:14Z,Updated RELEASES.md for 1.34.0,XAMPPRocky,4ba30341402cd4c80018f6f61e38987897ceeb1b,1,Update RELEASES.md Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>,HEART,2019-04-01T18:07:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/59599,MERGED,2019-04-01T08:54:30Z,2019-04-06T01:36:14Z,Updated RELEASES.md for 1.34.0,XAMPPRocky,4ba30341402cd4c80018f6f61e38987897ceeb1b,1,Update RELEASES.md Co-Authored-By: XAMPPRocky <4464295+XAMPPRocky@users.noreply.github.com>,ROCKET,2019-04-02T13:51:03Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-04-28T12:02:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-04-28T23:36:01Z,tocubed,tocubed@gmail.com https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-05-03T18:38:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-05-17T05:40:12Z,chmln,NA https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-06-13T13:18:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59600,MERGED,2019-04-01T09:23:23Z,2019-06-10T14:07:42Z,Replaced linear token counting macros with optimized implementation,tobia,a4a07e00ced90e076dbadd8b350db527bcc588bd,2,Replaced linear token counting macros with optimized implementation,THUMBS_UP,2019-07-02T03:43:24Z,matematikaadit,matematika.adit@gmail.com https://github.com/rust-lang/rust/pull/59617,CLOSED,2019-04-01T20:25:44Z,2019-04-08T08:06:57Z,Update Clippy,flip1995,NA,NA,NA,HOORAY,2019-04-01T21:50:01Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-01T21:25:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-01T21:29:29Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-02T02:39:48Z,panaman67,NA https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-02T06:21:17Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-02T16:43:05Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-02T17:32:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-03T02:41:28Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-04T11:46:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-04T20:38:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59619,MERGED,2019-04-01T20:39:02Z,2019-04-04T15:36:38Z,wasi: Implement more of the standard library,alexcrichton,61b487ca8be1d8667a82c1357dc2729cfe56186d,13,"wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented such as permissions-related ones and `canonicalize` but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd` a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI namely `*at` syscalls (opening a file relative to an already opened one for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about ""pre opened"" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use so we implement it for now and will swap it out as soon as one is available.",HOORAY,2019-04-25T15:51:31Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/59624,MERGED,2019-04-02T00:44:11Z,2019-04-06T01:36:15Z,SGX target: Use linker option to avoid code CGU assignment kludge,jethrogb,0a1a4759537091c240cadd517159696eeca6ead2,5,SGX target: Use linker option to avoid code CGU assignment kludge,THUMBS_UP,2019-04-02T09:35:17Z,faern,NA https://github.com/rust-lang/rust/pull/59625,MERGED,2019-04-02T01:19:34Z,2019-06-19T00:53:57Z,Refactor C FFI variadics to more closely match their C counterparts and add Clone implementation,ahomescu,b9ea653aee231114acbe6d4b3c7b1d692772d060,26,Expose `VaListImpl` as the Rust equivalent of `__va_list_tag` and implement Clone for it.,HOORAY,2019-05-25T18:58:14Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/59625,MERGED,2019-04-02T01:19:34Z,2019-06-19T00:53:57Z,Refactor C FFI variadics to more closely match their C counterparts and add Clone implementation,ahomescu,b9ea653aee231114acbe6d4b3c7b1d692772d060,26,Expose `VaListImpl` as the Rust equivalent of `__va_list_tag` and implement Clone for it.,HOORAY,2019-06-21T01:47:33Z,thedataking,perl@immunant.com https://github.com/rust-lang/rust/pull/59625,MERGED,2019-04-02T01:19:34Z,2019-06-19T00:53:57Z,Refactor C FFI variadics to more closely match their C counterparts and add Clone implementation,ahomescu,b9ea653aee231114acbe6d4b3c7b1d692772d060,26,Expose `VaListImpl` as the Rust equivalent of `__va_list_tag` and implement Clone for it.,HOORAY,2019-08-23T09:04:24Z,Vurich,NA https://github.com/rust-lang/rust/pull/59630,MERGED,2019-04-02T09:09:19Z,2019-04-03T08:32:57Z,Shrink `mir::Statement`.,nnethercote,d00d639c54ae49a35c0c215cd8161af8c7d2e8ee,8,Shrink `mir::Statement`. The `InlineAsm` variant is extremely rare and `mir::Statement` often contributes significantly to peak memory usage.,HEART,2019-04-02T09:29:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59634,MERGED,2019-04-02T13:52:20Z,2019-05-02T04:47:50Z,Added an explanation for the E0704 error.,DevQps,2be37ad42197f202dfb87c073cb0c6b5e9e5b2ec,2,Added the E0704 error with a link to the Rust reference.,HEART,2019-04-18T18:38:32Z,estebank,NA https://github.com/rust-lang/rust/pull/59639,MERGED,2019-04-02T18:57:42Z,2019-04-04T18:22:15Z,Never return uninhabited values at all,cuviper,c2e0d7f1eb25bd9b4a8eaa7990cd0fd3a8c416bb,2,Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn` but we were still generating return instructions for this. When running with `-C passes=lint` LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value.,HEART,2019-04-04T02:43:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59639,MERGED,2019-04-02T18:57:42Z,2019-04-04T18:22:15Z,Never return uninhabited values at all,cuviper,c2e0d7f1eb25bd9b4a8eaa7990cd0fd3a8c416bb,2,Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn` but we were still generating return instructions for this. When running with `-C passes=lint` LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value.,HEART,2019-04-04T10:45:54Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59639,MERGED,2019-04-02T18:57:42Z,2019-04-04T18:22:15Z,Never return uninhabited values at all,cuviper,c2e0d7f1eb25bd9b4a8eaa7990cd0fd3a8c416bb,2,Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn` but we were still generating return instructions for this. When running with `-C passes=lint` LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value.,HEART,2019-04-10T12:28:11Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59639,MERGED,2019-04-02T18:57:42Z,2019-04-04T18:22:15Z,Never return uninhabited values at all,cuviper,c2e0d7f1eb25bd9b4a8eaa7990cd0fd3a8c416bb,2,Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn` but we were still generating return instructions for this. When running with `-C passes=lint` LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value.,HEART,2019-04-11T05:43:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59639,MERGED,2019-04-02T18:57:42Z,2019-04-04T18:22:15Z,Never return uninhabited values at all,cuviper,c2e0d7f1eb25bd9b4a8eaa7990cd0fd3a8c416bb,2,Never return uninhabited values at all Functions with uninhabited return values are already marked `noreturn` but we were still generating return instructions for this. When running with `-C passes=lint` LLVM prints: Unusual: Return statement in function with noreturn attribute The LLVM manual makes a stronger statement about `noreturn` though: > This produces undefined behavior at runtime if the function ever does dynamically return. We now emit an `abort` anywhere that would have tried to return an uninhabited value.,HEART,2019-04-11T14:20:50Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/59658,CLOSED,2019-04-03T03:27:35Z,2019-07-24T02:12:27Z,Minimum lint levels for C-future-compatibility issues,Centril,NA,NA,NA,HEART,2019-04-03T10:00:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/59658,CLOSED,2019-04-03T03:27:35Z,2019-07-24T02:12:27Z,Minimum lint levels for C-future-compatibility issues,Centril,NA,NA,NA,HEART,2019-05-08T01:29:22Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/59658,CLOSED,2019-04-03T03:27:35Z,2019-07-24T02:12:27Z,Minimum lint levels for C-future-compatibility issues,Centril,NA,NA,NA,HEART,2019-05-09T17:24:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-03T12:33:31Z,LooMaclin,NA https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-03T15:23:34Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-03T23:47:20Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-04T03:56:21Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-11T05:45:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59665,MERGED,2019-04-03T11:12:22Z,2019-04-05T15:01:22Z,improve worst-case performance of HashSet.is_subset,ssomers,5b8bfe047123bad63ead0370c165cd9307a07caa,1,improve worst-case performance of HashSet.is_subset,THUMBS_UP,2019-04-11T14:14:02Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T18:21:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T18:31:07Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T18:35:16Z,lexxvir,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T18:58:44Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T19:12:46Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T19:22:56Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T19:24:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T19:31:21Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T19:32:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-03T21:19:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T01:56:08Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T02:21:23Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T02:38:41Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T07:00:46Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T11:45:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-04T16:43:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-05T11:19:20Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T05:17:22Z,GrayJack,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T06:02:04Z,Boiethios,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T07:40:39Z,awulkan,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T08:13:10Z,Lokathor,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T10:00:18Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T10:51:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T12:27:49Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T13:11:01Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-06T16:42:29Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-07T02:09:29Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-07T13:16:21Z,hcpl,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-08T14:51:03Z,robert-w-gries,robert.w.gries@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-08T23:54:49Z,cramertj,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-11T01:34:17Z,ds84182,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-12T13:52:40Z,mati865,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-14T03:38:21Z,amilajack,amilajack@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-14T15:14:22Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-14T15:50:00Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-14T15:56:16Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-14T16:22:39Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-17T18:46:10Z,gz,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-18T04:21:31Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-23T11:56:12Z,johnthagen,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-04-24T05:58:25Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-06-20T10:16:28Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2019-08-22T14:07:09Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2020-06-06T19:05:06Z,not-matthias,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2021-05-25T22:57:00Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2022-01-15T15:22:59Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/59675,MERGED,2019-04-03T18:17:01Z,2019-04-14T01:11:12Z,Stabilize the `alloc` crate.,SimonSapin,fc928a18bad0b6aa275a6908351b164f6f4abcd6,28,Stabilize the `alloc` crate. This implements RFC 2480: * https://github.com/rust-lang/rfcs/pull/2480 * https://github.com/rust-lang/rfcs/blob/master/text/2480-liballoc.md Closes https://github.com/rust-lang/rust/issues/27783,HOORAY,2022-05-13T06:15:08Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-04T09:55:59Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-04T10:48:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-04T14:51:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-04T16:40:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-04T20:21:42Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",LAUGH,2019-04-05T04:38:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HOORAY,2019-04-05T06:50:10Z,lqd,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-12T20:29:12Z,estebank,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",LAUGH,2019-04-17T11:33:06Z,CoolOppo,NA https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2019-04-18T04:27:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59693,MERGED,2019-04-04T09:44:40Z,2019-04-14T11:48:12Z,Increase `Span` from 4 bytes to 8 bytes.,nnethercote,fd7f605365b27bfdd3cd6763124e81bddd61dd28,4,"Increase `Span` from 4 bytes to 8 bytes. This increases the size of some important types such as `ast::Expr` and `mir::Statement`. However it drastically reduces how much the interner is used and the fields are more natural sizes that don't require bit operations to extract. As a result instruction counts drop across a range of workloads by as much as 12% for incremental ""check"" builds of `script-servo`. Peak memory usage goes up a little for some cases but down by more for some other cases -- as much as 18% for non-incremental builds of `packed-simd`. The commit also: - removes the `repr(packed)` because it has negligible effect but can cause undefined behaviour; - replaces explicit impls of common traits (`Copy` `PartialEq` etc.) with derived ones.",HEART,2022-06-14T10:49:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-04-04T20:03:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-04-04T20:09:10Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-04-05T00:54:20Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-04-09T22:12:01Z,teskje,jteske@posteo.net https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,HOORAY,2019-05-10T15:23:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-05-12T15:59:58Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-05-12T16:32:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-06-09T04:40:08Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-06-18T10:13:52Z,iago-lito,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-03T02:12:54Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-20T10:17:28Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,HOORAY,2019-07-21T11:41:39Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-24T15:52:47Z,Boiethios,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,HOORAY,2019-07-24T15:52:48Z,Boiethios,NA https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-24T19:11:19Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-25T03:30:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,THUMBS_UP,2019-07-25T16:41:42Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/59706,MERGED,2019-04-04T19:00:27Z,2019-07-21T10:59:03Z,The essence of lexer,matklad,395ee0b79f23b90593b01dd0a78451b8c93b0aa6,15,Introduce rustc_lexer The idea here is to make a reusable library out of the existing rust-lexer by separating out pure lexing and rustc-specific concerns like spans error reporting an interning. So rustc_lexer operates directly on `&str` produces simple tokens which are a pair of type-tag and a bit of original text and does not report errors instead storing them as flags on the token.,HOORAY,2019-08-26T15:36:14Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/59720,CLOSED,2019-04-05T10:41:56Z,2019-04-12T15:11:02Z,Inline __getit,mati865,NA,NA,NA,THUMBS_UP,2019-04-05T11:18:41Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59722,MERGED,2019-04-05T11:14:36Z,2019-06-30T15:39:30Z,Clean up query cache code,Zoxc,ede41ab4d6dbd56f62021c4951fea8f3278e5030,1,Keep caching for non-promoted queries,THUMBS_UP,2019-04-05T15:23:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/59723,MERGED,2019-04-05T11:25:54Z,2019-04-06T06:59:56Z,Remove no_force from coherent_trait,Zoxc,25c448ffd8f09e0a93da140a530c459462064996,1,Remove no_force from coherent_trait,HEART,2019-04-08T12:48:21Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/59733,MERGED,2019-04-05T18:52:12Z,2019-04-12T20:06:39Z,Final (one can only hope) futures_api adjustments,cramertj,6786fa7795880a899d85058831a1fd719edb43e1,2,Rename Waker::new_unchecked to Waker::from_raw,HOORAY,2019-04-08T21:45:00Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/59733,MERGED,2019-04-05T18:52:12Z,2019-04-12T20:06:39Z,Final (one can only hope) futures_api adjustments,cramertj,6786fa7795880a899d85058831a1fd719edb43e1,2,Rename Waker::new_unchecked to Waker::from_raw,HOORAY,2019-04-09T04:02:58Z,lelandjansen,hello@lelandjansen.com https://github.com/rust-lang/rust/pull/59733,MERGED,2019-04-05T18:52:12Z,2019-04-12T20:06:39Z,Final (one can only hope) futures_api adjustments,cramertj,6786fa7795880a899d85058831a1fd719edb43e1,2,Rename Waker::new_unchecked to Waker::from_raw,HOORAY,2019-04-09T14:11:54Z,NieDzejkob,kuba@kadziolka.net https://github.com/rust-lang/rust/pull/59733,MERGED,2019-04-05T18:52:12Z,2019-04-12T20:06:39Z,Final (one can only hope) futures_api adjustments,cramertj,6786fa7795880a899d85058831a1fd719edb43e1,2,Rename Waker::new_unchecked to Waker::from_raw,HOORAY,2019-04-11T19:42:04Z,marcelbuesing,NA https://github.com/rust-lang/rust/pull/59733,MERGED,2019-04-05T18:52:12Z,2019-04-12T20:06:39Z,Final (one can only hope) futures_api adjustments,cramertj,6786fa7795880a899d85058831a1fd719edb43e1,2,Rename Waker::new_unchecked to Waker::from_raw,HOORAY,2019-04-16T01:37:40Z,encombhat,encomblackhat@gmail.com https://github.com/rust-lang/rust/pull/59735,MERGED,2019-04-05T20:17:01Z,2019-04-14T01:11:16Z,remove lookup_char_pos_adj,matklad,63080b3c25046b29cbbaef8d587c7da91a302fce,5,remove lookup_char_pos_adj It is now exactly equivalent to lookup_char_pos.,HEART,2019-04-05T22:09:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-05T21:22:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-05T21:25:49Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-05T21:28:01Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-05T21:36:10Z,lelandjansen,hello@lelandjansen.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-05T22:33:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-06T02:22:32Z,uvd,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-06T02:44:34Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-06T04:00:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-06T10:22:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-06T10:22:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-06T12:40:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-08T06:21:26Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-10T15:08:49Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-12T21:25:44Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-12T21:25:44Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-14T04:16:34Z,davll,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-15T08:27:39Z,mijamo,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-16T20:23:49Z,fairingrey,fairingrey@mixini.dev https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-17T16:34:37Z,chpio,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T03:22:06Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T05:48:27Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T06:53:40Z,bmisiak,wickoo@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T07:03:12Z,Jancd,sergeychang@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T07:11:17Z,flosse,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-24T07:12:01Z,flosse,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T07:27:07Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-24T07:27:08Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-24T07:27:10Z,nolik,nolik03@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-24T09:34:41Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T09:50:19Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T10:15:08Z,samnardoni,sam.nardoni@spirent.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T10:26:40Z,GeorgeHahn,George.Hahn.VHS@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T11:35:03Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T11:52:41Z,wanghao-engineer,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-24T12:09:57Z,leeola,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T12:09:59Z,leeola,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-24T13:28:54Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T14:45:31Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T15:29:23Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T16:48:59Z,estebank,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-24T16:49:04Z,pavelshackih,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T17:02:30Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T17:20:38Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T19:47:24Z,Selicre,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-24T21:56:20Z,fluxxu,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T21:56:21Z,fluxxu,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-24T21:56:23Z,fluxxu,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T22:24:05Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T22:48:15Z,mersinvald,git@mkl.dev https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-24T23:43:51Z,VinceOPS,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-25T00:05:26Z,saks,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-25T05:51:21Z,jeffesquivels,jeff.esquivel@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-25T07:07:35Z,o01eg,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T07:07:37Z,o01eg,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-25T07:07:38Z,o01eg,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T08:48:21Z,felixrabe,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T10:24:53Z,marcelbuesing,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T10:27:02Z,gugahoa,gugahoa@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T12:22:41Z,niubell,bigpyer@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T15:33:53Z,bluejekyll,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-25T17:57:17Z,uonr,me@yuru.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T06:57:45Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T06:57:46Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T09:23:23Z,CryZe,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-26T17:09:11Z,r0xsh,contact@antoinebagnaud.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T17:09:11Z,r0xsh,contact@antoinebagnaud.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T17:09:13Z,r0xsh,contact@antoinebagnaud.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T17:58:28Z,k0pernicus,dev@0xc0ff33.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-26T17:58:29Z,k0pernicus,dev@0xc0ff33.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T17:58:32Z,k0pernicus,dev@0xc0ff33.me https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T18:07:05Z,repi,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T18:09:13Z,milosgajdos,milosthegajdos@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T18:25:13Z,ianchanning,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T19:14:49Z,xire28,near_alex@hotmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-26T20:02:01Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T20:02:03Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-26T20:02:04Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-26T21:26:33Z,leodutra,leodutra.br@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-26T21:26:34Z,leodutra,leodutra.br@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-27T19:31:46Z,Kroisse,kroisse@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-04-27T19:31:49Z,Kroisse,kroisse@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-28T17:30:43Z,simlay,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-28T18:39:02Z,budziq,budziq@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-28T18:39:04Z,budziq,budziq@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-04-29T05:20:46Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-29T13:00:05Z,95th,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-04-29T17:35:41Z,sidcool1234,sidd.kulk@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-05-03T08:15:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-05-04T06:34:43Z,KeenS,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-05-24T00:52:39Z,lawliet89,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-05-24T00:52:40Z,lawliet89,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-05-25T12:02:14Z,kellytk,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,ROCKET,2019-05-25T12:02:19Z,kellytk,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-05-31T15:43:53Z,mihyaeru21,mihyaeru21@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-06-24T09:51:48Z,lucasterra,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-07-04T14:38:39Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-07-04T15:33:20Z,franchb,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-07-04T15:33:21Z,franchb,NA https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-07-05T04:22:20Z,phbai,48466846@qq.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-07-06T09:30:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,HOORAY,2019-07-06T12:29:55Z,PeterDing,dfhayst@gmail.com https://github.com/rust-lang/rust/pull/59739,MERGED,2019-04-05T21:16:25Z,2019-04-24T06:09:14Z,Stabilize futures_api,cramertj,3f966dcd53faabd8313d29a4e1ba2464995e624a,32,Stabilize futures_api,THUMBS_UP,2019-07-15T11:53:45Z,Algirdyz,NA https://github.com/rust-lang/rust/pull/59755,MERGED,2019-04-06T17:39:31Z,2019-04-07T00:18:47Z,Update miri,matthewjasper,acfe36e2e9151b4d4ade68b18f6119536cb2777a,1,Update miri,HEART,2019-04-06T18:23:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59769,MERGED,2019-04-07T10:44:30Z,2019-04-16T13:15:54Z,compiletest normalization: preserve non-JSON lines such as ICEs,RalfJung,28c4397b28277cbbfb8f41aa007b9cac0e6b826f,3,this panic occurs not just on Windows normalize it away everywhere,THUMBS_UP,2019-04-07T13:11:00Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59769,MERGED,2019-04-07T10:44:30Z,2019-04-16T13:15:54Z,compiletest normalization: preserve non-JSON lines such as ICEs,RalfJung,28c4397b28277cbbfb8f41aa007b9cac0e6b826f,3,this panic occurs not just on Windows normalize it away everywhere,THUMBS_UP,2019-04-08T16:31:59Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/59780,MERGED,2019-04-07T18:24:41Z,2019-04-11T18:40:45Z,Miri: unsized locals and by-value dyn traits,RalfJung,4d79d391b0aa1175f493e3544d8f66e6600fbfc6,3,avoid reading from ZST locals,HOORAY,2019-04-07T19:01:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59780,MERGED,2019-04-07T18:24:41Z,2019-04-11T18:40:45Z,Miri: unsized locals and by-value dyn traits,RalfJung,4d79d391b0aa1175f493e3544d8f66e6600fbfc6,3,avoid reading from ZST locals,HOORAY,2019-04-08T14:55:53Z,crlf0710,NA https://github.com/rust-lang/rust/pull/59780,MERGED,2019-04-07T18:24:41Z,2019-04-11T18:40:45Z,Miri: unsized locals and by-value dyn traits,RalfJung,4d79d391b0aa1175f493e3544d8f66e6600fbfc6,3,avoid reading from ZST locals,HOORAY,2019-04-18T09:41:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59784,MERGED,2019-04-07T22:14:53Z,2019-04-14T03:58:20Z,Suggest importing macros from the crate root,davidtwco,5158063c3ec1e1dc8d9b0a0806e29d6c6e54d765,6,Switch to multipart suggestions. This commit changes the suggestion so that it is split into multiple parts in an effort to reduce the impact the applied suggestion could have on formatting.,HEART,2019-04-10T18:36:09Z,estebank,NA https://github.com/rust-lang/rust/pull/59784,MERGED,2019-04-07T22:14:53Z,2019-04-14T03:58:20Z,Suggest importing macros from the crate root,davidtwco,5158063c3ec1e1dc8d9b0a0806e29d6c6e54d765,6,Switch to multipart suggestions. This commit changes the suggestion so that it is split into multiple parts in an effort to reduce the impact the applied suggestion could have on formatting.,HEART,2019-04-10T21:56:13Z,varkor,NA https://github.com/rust-lang/rust/pull/59784,MERGED,2019-04-07T22:14:53Z,2019-04-14T03:58:20Z,Suggest importing macros from the crate root,davidtwco,5158063c3ec1e1dc8d9b0a0806e29d6c6e54d765,6,Switch to multipart suggestions. This commit changes the suggestion so that it is split into multiple parts in an effort to reduce the impact the applied suggestion could have on formatting.,HEART,2019-04-18T19:23:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59794,MERGED,2019-04-08T12:38:46Z,2019-04-08T15:43:35Z,[stable] Rust 1.34.0,pietroalbini,a1fe335a537bda99d07069a8861ef9035463378c,1,stable 1.34.0 release,ROCKET,2019-04-08T15:08:00Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/59794,MERGED,2019-04-08T12:38:46Z,2019-04-08T15:43:35Z,[stable] Rust 1.34.0,pietroalbini,a1fe335a537bda99d07069a8861ef9035463378c,1,stable 1.34.0 release,ROCKET,2019-04-08T18:36:47Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-08T17:13:47Z,mati865,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-08T18:01:08Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-08T18:39:25Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-10T10:04:11Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-11T10:03:33Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-04-22T05:58:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HEART,2019-04-22T05:58:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-05-04T22:16:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-05-28T13:53:14Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HEART,2019-05-28T13:53:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-06-21T16:10:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/59800,MERGED,2019-04-08T16:18:33Z,2019-07-07T14:57:10Z,rustc: Remove `dylib` crate type from most rustc crates,Zoxc,7198687bb2df13a3298ef1e8f594753073d6b9e8,15,Link compiler plugins to rustc_driver,HOORAY,2019-06-22T21:27:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/59804,MERGED,2019-04-08T18:46:58Z,2019-04-14T01:11:20Z,Clean up jobserver integration,Zoxc,03727a4f257fc86b467457a1e87d06d56e62d5f0,2,Clean up jobserver integration,HOORAY,2019-04-09T15:24:14Z,mati865,NA https://github.com/rust-lang/rust/pull/59811,MERGED,2019-04-09T10:58:58Z,2019-04-12T14:31:14Z,Kill dead code dominator code.,vext01,3262d1e25242a6dc0c486e78be8b03b71a9106b7,1,Kill dead code dominator code.,HEART,2019-04-09T16:38:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/59818,MERGED,2019-04-09T17:09:13Z,2019-04-14T01:11:21Z,Eliminate `FnBox` usages from libstd.,crlf0710,6635fbed4ca8c65822f99e994735bd1877fb063e,10,Eliminate `FnBox` usages from libstd.,THUMBS_UP,2019-04-10T11:19:52Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/59818,MERGED,2019-04-09T17:09:13Z,2019-04-14T01:11:21Z,Eliminate `FnBox` usages from libstd.,crlf0710,6635fbed4ca8c65822f99e994735bd1877fb063e,10,Eliminate `FnBox` usages from libstd.,THUMBS_UP,2019-04-10T13:18:08Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59818,MERGED,2019-04-09T17:09:13Z,2019-04-14T01:11:21Z,Eliminate `FnBox` usages from libstd.,crlf0710,6635fbed4ca8c65822f99e994735bd1877fb063e,10,Eliminate `FnBox` usages from libstd.,THUMBS_UP,2019-04-11T03:10:03Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/59821,MERGED,2019-04-09T18:23:49Z,2019-04-12T14:31:15Z,improve unknown enum variant errors,euclio,757ef3843192b27100ec1746721386d245a8644d,24,improve unknown enum variant errors,HEART,2019-04-12T16:37:09Z,estebank,NA https://github.com/rust-lang/rust/pull/59825,MERGED,2019-04-09T20:45:58Z,2019-05-16T12:58:06Z,string: implement From<&String> for String,jsgf,08b0aca05e3709766fd7e0e01ec56a8511e4c46b,1,string: implement From<&String> for String Allow Strings to be created from borrowed Strings. This is mostly to make things like passing &String to an `impl Into` parameter frictionless.,THUMBS_UP,2019-04-18T10:22:33Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59825,MERGED,2019-04-09T20:45:58Z,2019-05-16T12:58:06Z,string: implement From<&String> for String,jsgf,08b0aca05e3709766fd7e0e01ec56a8511e4c46b,1,string: implement From<&String> for String Allow Strings to be created from borrowed Strings. This is mostly to make things like passing &String to an `impl Into` parameter frictionless.,HEART,2019-06-30T14:08:43Z,killercup,NA https://github.com/rust-lang/rust/pull/59826,MERGED,2019-04-09T21:01:22Z,2019-04-20T23:44:08Z,allow multiple args to `dbg!(..)`,llogiq,b641fd374e82fc8e3cf6b876fa57270f2de39b32,2,extend ui test,HEART,2019-04-10T08:07:12Z,mati865,NA https://github.com/rust-lang/rust/pull/59826,MERGED,2019-04-09T21:01:22Z,2019-04-20T23:44:08Z,allow multiple args to `dbg!(..)`,llogiq,b641fd374e82fc8e3cf6b876fa57270f2de39b32,2,extend ui test,HEART,2019-04-10T14:29:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59826,MERGED,2019-04-09T21:01:22Z,2019-04-20T23:44:08Z,allow multiple args to `dbg!(..)`,llogiq,b641fd374e82fc8e3cf6b876fa57270f2de39b32,2,extend ui test,HEART,2019-04-25T17:41:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59844,CLOSED,2019-04-10T16:43:25Z,2019-05-14T14:29:31Z,Don't build rustdoc in more than one stage,Mark-Simulacrum,NA,NA,NA,HEART,2019-04-10T21:36:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59846,MERGED,2019-04-10T17:02:21Z,2019-04-13T10:44:53Z,"clarify what the item is in ""not a module"" error",euclio,bbdeafc13c2387c62c14c6b8214709331e61dca9,15,"clarify what the item is in ""not a module"" error",THUMBS_UP,2019-04-10T19:56:58Z,ljedrz,NA https://github.com/rust-lang/rust/pull/59850,MERGED,2019-04-10T19:21:19Z,2019-04-15T16:18:07Z,Preallocate BUILTIN_ATTRIBUTES symbols,Zoxc,cf3a25615997a1193196c4364a529a4b3830945f,2,Update test,THUMBS_UP,2019-04-13T10:58:57Z,bjorn3,NA https://github.com/rust-lang/rust/pull/59852,MERGED,2019-04-10T19:54:01Z,2019-04-14T01:11:24Z,std: Add `{read write}_vectored` for more types,alexcrichton,acf3ddb5ad163ea98f8935b045fc6d15faefa454,19,std: Add `{read write}_vectored` for more types This commit implements the `{read write}_vectored` methods on more types in the standard library namely: * `std::fs::File` * `std::process::ChildStd{in out err}` * `std::io::Std{in out err}` * `std::io::Std{in out err}Lock` * `std::io::Std{in out err}Raw` Where supported the OS implementations hook up to native support otherwise it falls back to the already-defaulted implementation.,THUMBS_UP,2019-04-10T21:17:26Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59852,MERGED,2019-04-10T19:54:01Z,2019-04-14T01:11:24Z,std: Add `{read write}_vectored` for more types,alexcrichton,acf3ddb5ad163ea98f8935b045fc6d15faefa454,19,std: Add `{read write}_vectored` for more types This commit implements the `{read write}_vectored` methods on more types in the standard library namely: * `std::fs::File` * `std::process::ChildStd{in out err}` * `std::io::Std{in out err}` * `std::io::Std{in out err}Lock` * `std::io::Std{in out err}Raw` Where supported the OS implementations hook up to native support otherwise it falls back to the already-defaulted implementation.,THUMBS_UP,2019-04-10T21:25:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/59852,MERGED,2019-04-10T19:54:01Z,2019-04-14T01:11:24Z,std: Add `{read write}_vectored` for more types,alexcrichton,acf3ddb5ad163ea98f8935b045fc6d15faefa454,19,std: Add `{read write}_vectored` for more types This commit implements the `{read write}_vectored` methods on more types in the standard library namely: * `std::fs::File` * `std::process::ChildStd{in out err}` * `std::io::Std{in out err}` * `std::io::Std{in out err}Lock` * `std::io::Std{in out err}Raw` Where supported the OS implementations hook up to native support otherwise it falls back to the already-defaulted implementation.,THUMBS_UP,2019-04-17T12:04:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/59855,MERGED,2019-04-10T20:32:24Z,2019-04-14T01:11:25Z,Fix attributes position in type declaration,GuillaumeGomez,825a11ea3bb8a4b1a07d4e03a009b2ca4205c6a9,2,Fix attributes position in type declaration,HOORAY,2019-04-10T22:13:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59859,MERGED,2019-04-10T21:30:12Z,2019-04-13T10:44:55Z,Suggest removing `?` to resolve type errors.,davidtwco,16592f691b71802f8876a4f087cdc22a21869836,8,Suggest removing `?` to resolve type errors. This commit adds a suggestion to remove the `?` from expressions if removing the `?` would resolve a type error.,HEART,2019-04-10T21:52:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/59859,MERGED,2019-04-10T21:30:12Z,2019-04-13T10:44:55Z,Suggest removing `?` to resolve type errors.,davidtwco,16592f691b71802f8876a4f087cdc22a21869836,8,Suggest removing `?` to resolve type errors. This commit adds a suggestion to remove the `?` from expressions if removing the `?` would resolve a type error.,HEART,2019-04-11T10:32:07Z,varkor,NA https://github.com/rust-lang/rust/pull/59859,MERGED,2019-04-10T21:30:12Z,2019-04-13T10:44:55Z,Suggest removing `?` to resolve type errors.,davidtwco,16592f691b71802f8876a4f087cdc22a21869836,8,Suggest removing `?` to resolve type errors. This commit adds a suggestion to remove the `?` from expressions if removing the `?` would resolve a type error.,HEART,2019-04-17T12:12:50Z,florianjacob,NA https://github.com/rust-lang/rust/pull/59859,MERGED,2019-04-10T21:30:12Z,2019-04-13T10:44:55Z,Suggest removing `?` to resolve type errors.,davidtwco,16592f691b71802f8876a4f087cdc22a21869836,8,Suggest removing `?` to resolve type errors. This commit adds a suggestion to remove the `?` from expressions if removing the `?` would resolve a type error.,HEART,2019-04-18T04:20:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/59862,MERGED,2019-04-10T23:40:41Z,2019-04-13T10:44:55Z,Tweak unstable diagnostic output,estebank,66ed5d9cb095f125f2216979505a001c21cd5da0,2,Fix ui-fulldeps test,HEART,2019-04-11T20:52:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/59880,MERGED,2019-04-11T14:03:42Z,2019-04-12T14:31:22Z,Remove note about transmute for float bitpatterns.,solson,f54df449072895f258876adf9545fe3a0840492f,1,Remove note about transmute for float bitpatterns.,THUMBS_UP,2019-04-12T10:42:04Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/59880,MERGED,2019-04-11T14:03:42Z,2019-04-12T14:31:22Z,Remove note about transmute for float bitpatterns.,solson,f54df449072895f258876adf9545fe3a0840492f,1,Remove note about transmute for float bitpatterns.,THUMBS_UP,2019-04-13T06:42:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/59883,MERGED,2019-04-11T15:19:13Z,2019-05-03T10:16:00Z,Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS,ebarnard,0fd446ea78504132add1acff3d0a626467337a2c,2,Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS.,THUMBS_UP,2019-04-15T00:40:26Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/59883,MERGED,2019-04-11T15:19:13Z,2019-05-03T10:16:00Z,Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS,ebarnard,0fd446ea78504132add1acff3d0a626467337a2c,2,Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS.,THUMBS_UP,2021-09-03T07:36:14Z,chpio,NA https://github.com/rust-lang/rust/pull/59889,MERGED,2019-04-11T20:13:13Z,2019-04-12T14:31:23Z,Update diagnostics.rs,andrewbanchich,aefc1581b125876f37c652f84fddc81b0b25fe12,1,Update diagnostics.rs Add `a` and other minor text improvements,THUMBS_UP,2019-04-11T21:18:16Z,estebank,NA https://github.com/rust-lang/rust/pull/59912,MERGED,2019-04-12T10:43:16Z,2019-04-14T01:11:30Z,MaybeUninit: remove deprecated functions,RalfJung,1ce6645d1f6e80325f2c13ae72b879c66d09c644,1,MaybeUninit: remove deprecated functions,HOORAY,2019-04-12T15:49:14Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/59922,MERGED,2019-04-12T18:36:20Z,2019-04-13T10:45:01Z,Rollup of 8 pull requests,Centril,ba173135becd5681baa67551cafa20ce9a3017e2,2,Rollup merge of #59892 - rylev:as-raw-fd r=alexcrichton Impl RawFd conversion traits for WASI TcpListener TcpStream and UdpSocket r? @alexcrichton,HOORAY,2019-04-13T00:37:38Z,eaglgenes101,NA https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,HEART,2019-04-13T00:14:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,HEART,2019-04-13T07:06:21Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,HEART,2019-04-13T14:30:27Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,HEART,2019-04-13T15:36:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,HEART,2019-04-14T11:51:54Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59930,MERGED,2019-04-12T23:40:27Z,2019-04-14T01:11:32Z,Exclude some copies of old book editions from search engines,kornelski,0a9b214b503265e42e86ca7846577664efb1819e,1,Exclude some copies of old book editions from search engines,THUMBS_UP,2019-04-14T11:52:00Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/59953,MERGED,2019-04-14T02:23:37Z,2019-10-17T14:43:03Z, rustc_metadata: replace Entry table with one table for each of its fields (AoS -> SoA).,eddyb,d89dddc9204a540efcd7f86c36d60381020b2422,1,rustc_metadata: address some review comments.,HEART,2019-10-15T21:14:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/59958,CLOSED,2019-04-14T12:31:40Z,2019-07-24T16:28:02Z,Fix main.js for gtk-rs,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2019-04-14T12:32:00Z,antoyo,NA https://github.com/rust-lang/rust/pull/59974,MERGED,2019-04-14T20:38:34Z,2019-04-17T07:06:01Z,Bump bootstrap compiler to 2019-04-11,Centril,f2371e3b7daa43d8ea267e07c52a057fc08dc708,1,bump bootstrap; remove redundant 'use libc;' on macOS.,HEART,2019-04-15T13:20:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/59974,MERGED,2019-04-14T20:38:34Z,2019-04-17T07:06:01Z,Bump bootstrap compiler to 2019-04-11,Centril,f2371e3b7daa43d8ea267e07c52a057fc08dc708,1,bump bootstrap; remove redundant 'use libc;' on macOS.,HEART,2019-04-15T16:46:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/59974,MERGED,2019-04-14T20:38:34Z,2019-04-17T07:06:01Z,Bump bootstrap compiler to 2019-04-11,Centril,f2371e3b7daa43d8ea267e07c52a057fc08dc708,1,bump bootstrap; remove redundant 'use libc;' on macOS.,HEART,2019-04-15T19:35:37Z,mati865,NA https://github.com/rust-lang/rust/pull/59981,MERGED,2019-04-15T00:07:13Z,2019-04-19T23:06:54Z,Emit specific error for struct literal in conditions,estebank,aa393b0cde881c612379d90ca300396cd7ce2e96,4,Some cleanup to `maybe_parse_struct_expr`,THUMBS_UP,2019-04-21T06:55:05Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/59986,MERGED,2019-04-15T12:57:53Z,2019-04-17T12:58:20Z,Miri: refactor new allocation tagging,RalfJung,19485cc10173cb72e24813ce95b65c8f3cf92326,9,Miri: refactor new allocation tagging,HOORAY,2019-04-15T13:13:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59986,MERGED,2019-04-15T12:57:53Z,2019-04-17T12:58:20Z,Miri: refactor new allocation tagging,RalfJung,19485cc10173cb72e24813ce95b65c8f3cf92326,9,Miri: refactor new allocation tagging,HOORAY,2019-04-15T16:44:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/59986,MERGED,2019-04-15T12:57:53Z,2019-04-17T12:58:20Z,Miri: refactor new allocation tagging,RalfJung,19485cc10173cb72e24813ce95b65c8f3cf92326,9,Miri: refactor new allocation tagging,HOORAY,2019-04-15T22:40:47Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/59988,CLOSED,2019-04-15T14:10:42Z,2019-04-24T15:17:46Z,Encode eval_always in the lowest bit of DepNodeKind,Zoxc,NA,NA,NA,HEART,2019-04-16T11:40:28Z,oli-obk,NA https://github.com/rust-lang/rust/pull/59990,MERGED,2019-04-15T16:06:38Z,2019-04-16T05:28:47Z,Use resume_unwind instead of panic!() for nicer compiletest errors,bjorn3,dc08f5519ff05a562f3ab5eda9b9b8fbc0cecfff,1,Use resume_unwind instead of panic!() for nicer compiletest errors,HOORAY,2019-04-16T08:31:31Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/59993,MERGED,2019-04-15T17:12:26Z,2019-04-16T08:23:20Z,include mode in unused binding suggestion span,euclio,74560f3ab36bb4f7f3aef3c66a3e9717f9ee1978,4,include mode in unused binding suggestion span,HEART,2019-04-15T23:47:27Z,estebank,NA https://github.com/rust-lang/rust/pull/59993,MERGED,2019-04-15T17:12:26Z,2019-04-16T08:23:20Z,include mode in unused binding suggestion span,euclio,74560f3ab36bb4f7f3aef3c66a3e9717f9ee1978,4,include mode in unused binding suggestion span,HEART,2019-04-16T09:49:58Z,ehuss,NA https://github.com/rust-lang/rust/pull/60000,MERGED,2019-04-15T21:53:41Z,2019-04-16T08:23:21Z,Add repo-specific triagebot configuration,pietroalbini,3db489bdcfcf2c31034194a30ca60a7cc2ba5adb,1,add repo-specific triagebot configuration,HOORAY,2019-04-16T08:20:04Z,kennytm,NA https://github.com/rust-lang/rust/pull/60002,CLOSED,2019-04-15T22:24:05Z,2019-07-22T12:16:14Z,Add CLI option to setup favicon,GuillaumeGomez,NA,NA,NA,HEART,2019-04-15T23:47:14Z,estebank,NA https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-18T08:46:43Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-24T20:02:39Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-24T20:45:58Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-24T21:01:14Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-25T07:22:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-04-25T17:58:59Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/60013,MERGED,2019-04-16T16:56:58Z,2019-04-17T19:19:09Z,Fix the max value of usize on 16-bit platforms,NieDzejkob,d9c42d5c84bf32183b9be3e6b1860d507279b0cc,1,Fix the max value of usize on 16-bit platforms,LAUGH,2019-05-17T00:34:46Z,moshg,NA https://github.com/rust-lang/rust/pull/60018,MERGED,2019-04-16T18:06:53Z,2019-04-17T12:58:21Z,Miri now supports entropy but is still slow,RalfJung,d55e4b7a259b887202be91708f839a75b234697c,2,test sort_unstable in Miri,THUMBS_UP,2019-04-16T20:31:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60025,MERGED,2019-04-16T23:12:30Z,2019-04-18T17:48:40Z,Rename files about error codes,JohnTitor,a1d2f7222cf1f5c4344a918251c7f37d252c2434,1,Rename module,THUMBS_UP,2019-04-17T20:49:42Z,estebank,NA https://github.com/rust-lang/rust/pull/60026,MERGED,2019-04-17T01:12:25Z,2019-11-13T00:43:01Z,Add hooks for Miri panic unwinding,Aaron1011,b4545a4ad625c68479120db845280f4c61b39640,1,Update,HEART,2019-11-11T23:10:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60027,MERGED,2019-04-17T01:12:42Z,2019-04-17T10:03:26Z,SGX target: change re-entry abort logic,jethrogb,d0a1c2d3e0ac91849882693720cb81b5da533439,3,SGX target: change re-entry abort logic,THUMBS_UP,2019-04-17T21:01:14Z,jseyfried,NA https://github.com/rust-lang/rust/pull/60036,MERGED,2019-04-17T10:07:54Z,2019-04-18T01:19:41Z,Remove nrc from toolstate pings,nrc,dbbf87583b24284af95425d2dccb6236440d86b0,1,Remove nrc from toolstate pings,LAUGH,2019-04-17T13:13:15Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/60036,MERGED,2019-04-17T10:07:54Z,2019-04-18T01:19:41Z,Remove nrc from toolstate pings,nrc,dbbf87583b24284af95425d2dccb6236440d86b0,1,Remove nrc from toolstate pings,LAUGH,2019-04-17T16:47:51Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60036,MERGED,2019-04-17T10:07:54Z,2019-04-18T01:19:41Z,Remove nrc from toolstate pings,nrc,dbbf87583b24284af95425d2dccb6236440d86b0,1,Remove nrc from toolstate pings,LAUGH,2019-04-18T08:46:14Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/60038,MERGED,2019-04-17T11:00:33Z,2019-04-25T06:33:54Z,Add codegen test for PGO instrumentation.,michaelwoerister,ff976fe0f13491f0e6d3f7cbd52ab409fd93165a,3,Fix ignore-logic for sanitizer run-make tests.,HEART,2019-04-17T17:29:27Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60039,MERGED,2019-04-17T12:35:27Z,2019-04-29T17:44:29Z,Make assert! ensure the macro is parsed completely,rasendubi,f29e9a5cb83ef6dca14652b323e2c00c36997a54,3,Handle common assert! misuses,HEART,2019-04-24T17:48:22Z,estebank,NA https://github.com/rust-lang/rust/pull/60039,MERGED,2019-04-17T12:35:27Z,2019-04-29T17:44:29Z,Make assert! ensure the macro is parsed completely,rasendubi,f29e9a5cb83ef6dca14652b323e2c00c36997a54,3,Handle common assert! misuses,HEART,2019-04-29T14:15:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/60045,MERGED,2019-04-17T17:29:30Z,2019-04-19T07:03:02Z,Suggest appropriate path when calling associated item on bare types,estebank,6aa4c992bc8ee003be01bfc59d2d7b54d01bc131,7,Suggest appropriate path when calling associated item on bare types When looking at the documentation for `std::f32` or `std::str` for example it is easy to get confused and assume `std::f32` and `f32` are the same thing. Because of this it is not uncommon to attempt writing `f32::consts::PI` instead of the correct `std::f32::consts::PI`. When encountering the former which results in an access error due to it being an inexistent path try to access the same path under `std`. If this succeeds this information is stored for later tweaking of the final E0599 to provide an appropriate suggestion. This suggestion applies to both E0233 and E0599 and is only checked when the first ident of a path corresponds to a primitive type.,HEART,2019-04-17T21:50:28Z,tesuji,NA https://github.com/rust-lang/rust/pull/60046,MERGED,2019-04-17T17:29:51Z,2019-04-19T00:23:38Z,hide `--explain` hint if error has no extended info,euclio,b6f148c8bdf2dd1beb11445441366934f8b61f74,833,hide `--explain` hint if error has no extended info,HEART,2019-04-17T20:46:08Z,estebank,NA https://github.com/rust-lang/rust/pull/60060,MERGED,2019-04-18T00:22:06Z,2019-04-19T07:03:04Z,whitelist RTM x86 target cpu feature,mtak-,365a48a8bf0d4dbb343889c53f773adad74ef965,5,whitelist rtm x86 cpu feature,HOORAY,2019-04-18T07:07:01Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60064,MERGED,2019-04-18T01:33:17Z,2019-04-19T07:03:05Z,Point at try `?` on errors affecting the err match arm of the desugared code,estebank,1e99b2ec9dc60dc01a413118051d273ed7688c7e,6,Give custom error for E0277 on `?` error case,THUMBS_UP,2019-04-19T07:52:43Z,mati865,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-04-18T07:07:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,HOORAY,2019-04-18T08:01:42Z,shengsheng,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,HOORAY,2019-07-24T09:17:24Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-07-27T02:53:11Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-07-31T19:59:03Z,koute,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,HOORAY,2019-07-31T19:59:03Z,koute,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,ROCKET,2019-07-31T19:59:08Z,koute,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-07-31T21:50:55Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-08-01T02:59:02Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-08-02T04:32:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-08-03T10:38:02Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,HOORAY,2019-08-03T10:38:04Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/60066,MERGED,2019-04-18T02:42:24Z,2019-07-26T02:17:56Z,Stabilize the type_name intrinsic in core::any,sfackler,91fa898975609f09f33e3e03fa8706c31a6b7d9b,14,Stabilize the type_name intrinsic in core::any Closes rust-lang/rfcs#1428,THUMBS_UP,2019-08-17T03:17:10Z,dwnusbaum,NA https://github.com/rust-lang/rust/pull/60072,MERGED,2019-04-18T09:50:34Z,2019-04-19T20:15:32Z,fix LinkedList invalidating mutable references,RalfJung,8b09d046fedf84ed869204bbe0779a0439bbf9eb,1,fix LinkedList invalidating mutable references,HEART,2019-04-26T00:25:19Z,kpp,NA https://github.com/rust-lang/rust/pull/60072,MERGED,2019-04-18T09:50:34Z,2019-04-19T20:15:32Z,fix LinkedList invalidating mutable references,RalfJung,8b09d046fedf84ed869204bbe0779a0439bbf9eb,1,fix LinkedList invalidating mutable references,HEART,2019-06-07T23:21:31Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/60080,MERGED,2019-04-18T13:50:06Z,2019-04-19T07:03:07Z,Fix small errors in docs for `rchunks_exact` and `rchunks_exact_mut`.,nathankleyn,d98afc51dcfe254d25925c4b675a6099dede4f47,1,"Fix small errors in docs for `rchunks_exact` and `rchunks_exact_mut`. The documentation for `rchunks_exact` said it started at the beginning of the slice bit it actually starts at the end of the slice. In addition there were a couple of ""of the slice of the slice"" duplicate phrases going on for `rchunks_exact` and `rchunks_exact_mut`. This fixes #60068.",THUMBS_UP,2019-04-18T21:50:09Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/60103,CLOSED,2019-04-19T03:56:20Z,2019-06-18T15:55:17Z,Proposal: `fold_self` and `try_fold_self` for Iterators,Lucretiel,NA,NA,NA,THUMBS_UP,2019-04-22T11:53:00Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/60109,CLOSED,2019-04-19T09:30:46Z,2019-09-06T01:45:46Z,Stabilize ADX TBM and SSE4a target features,gnzlbg,NA,NA,NA,HEART,2019-04-20T22:46:59Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60109,CLOSED,2019-04-19T09:30:46Z,2019-09-06T01:45:46Z,Stabilize ADX TBM and SSE4a target features,gnzlbg,NA,NA,NA,HEART,2022-02-06T19:40:32Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/60124,MERGED,2019-04-19T20:33:33Z,2019-04-21T16:25:23Z,Remove mutability from `Def::Static`,petrochenkov,4eb94b44072697be70fc2a74ed9989e88f9cd70c,10,AST/HIR: Use `Mutability` instead of bool in foreign statics,HEART,2019-04-19T20:36:59Z,panaman67,NA https://github.com/rust-lang/rust/pull/60130,MERGED,2019-04-20T05:01:41Z,2019-05-14T23:56:13Z,Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators,khuey,3e86cf36b5114f201868bf459934fe346a76a2d4,14,Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators. r?Manishearth,HOORAY,2019-05-22T17:47:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60130,MERGED,2019-04-20T05:01:41Z,2019-05-14T23:56:13Z,Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators,khuey,3e86cf36b5114f201868bf459934fe346a76a2d4,14,Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators. r?Manishearth,HOORAY,2019-05-23T04:27:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60132,MERGED,2019-04-20T10:37:09Z,2019-04-21T10:13:50Z,Fix fn front matter parsing ICE from invalid code.,davidtwco,60c6ed9664e8d6fa30388290d5fe86eb80bc6fc7,3,"Fix fn front matter parsing ICE from invalid code. This commit fixes an ""unreachable code"" ICE that results from parsing invalid code where the compiler is expecting the next trait item declaration in the middle of the previous trait item due to extra closing braces.",THUMBS_UP,2019-04-20T21:43:56Z,estebank,NA https://github.com/rust-lang/rust/pull/60145,MERGED,2019-04-20T21:16:24Z,2019-06-01T06:34:27Z,std::net: Ipv4Addr and Ipv6Addr improvements,little-dude,cddb838043fb0201c09bf0a8692001b04b3bec1a,1,std::net: tests for Ipv4addr::is_shared(),THUMBS_UP,2019-04-21T11:39:09Z,ondj,NA https://github.com/rust-lang/rust/pull/60145,MERGED,2019-04-20T21:16:24Z,2019-06-01T06:34:27Z,std::net: Ipv4Addr and Ipv6Addr improvements,little-dude,cddb838043fb0201c09bf0a8692001b04b3bec1a,1,std::net: tests for Ipv4addr::is_shared(),THUMBS_UP,2019-04-21T15:58:57Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60145,MERGED,2019-04-20T21:16:24Z,2019-06-01T06:34:27Z,std::net: Ipv4Addr and Ipv6Addr improvements,little-dude,cddb838043fb0201c09bf0a8692001b04b3bec1a,1,std::net: tests for Ipv4addr::is_shared(),THUMBS_UP,2019-05-31T22:50:07Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/60155,MERGED,2019-04-21T19:02:20Z,2019-04-23T18:50:26Z,Suggest dereferencing when `Deref` is implemented.,davidtwco,7ab1bfd692c2679278c5dc978b04dfb16dfae470,9,Only make suggestion when type is `Copy`. This commit makes the suggestion to dereference when a type implements `Deref` only apply if the dereference would succeed (ie. the type is `Copy` otherwise a borrow check error would occur).,THUMBS_UP,2019-04-21T20:28:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60155,MERGED,2019-04-21T19:02:20Z,2019-04-23T18:50:26Z,Suggest dereferencing when `Deref` is implemented.,davidtwco,7ab1bfd692c2679278c5dc978b04dfb16dfae470,9,Only make suggestion when type is `Copy`. This commit makes the suggestion to dereference when a type implements `Deref` only apply if the dereference would succeed (ie. the type is `Copy` otherwise a borrow check error would occur).,THUMBS_UP,2019-04-22T16:16:38Z,estebank,NA https://github.com/rust-lang/rust/pull/60159,MERGED,2019-04-21T22:46:23Z,2019-04-30T15:20:04Z,Suggest `try_into` when possible,estebank,31eb5cc7305f8967efd449f7067178c980ab27ba,5,Account for const fns to avoid incorrect suggestions,THUMBS_UP,2019-05-09T05:07:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60160,MERGED,2019-04-22T02:15:55Z,2019-04-25T06:33:58Z,Fix #58270 fix off-by-one error in error diagnostics.,xldenis,4a073dda936b2bc594056dca43c3ea51479435fe,7,Fix #58270 fix off-by-one error in error diagnostics.,THUMBS_UP,2019-04-22T16:21:48Z,estebank,NA https://github.com/rust-lang/rust/pull/60166,MERGED,2019-04-22T11:57:12Z,2019-05-31T13:24:16Z,Make the `type_name` intrinsic deterministic,oli-obk,5b9848912a85e28d000602fc2e81bad9c2f2a981,9,Make the `type_name` intrinsic's output deterministic,HEART,2019-05-30T09:22:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,HEART,2019-04-22T15:41:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,THUMBS_UP,2019-04-22T15:41:52Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,HOORAY,2019-04-22T15:41:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,THUMBS_UP,2019-04-22T16:12:07Z,estebank,NA https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,HEART,2019-04-22T19:12:55Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/60167,MERGED,2019-04-22T14:32:08Z,2019-04-26T07:32:58Z,Add a tidy check for files with over 3 000 lines,varkor,8c3068784c91a2be86b5ea0e5512290cb0e12481,1,Fix false position on style.rs itself,LAUGH,2019-06-07T00:44:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60171,MERGED,2019-04-22T15:50:41Z,2019-05-17T16:11:36Z,Use -Zborrowck=mir for NLL compare mode,matthewjasper,be5fe051a843cfbbc1ba4fcd347b641417181b8f,301,Remove feature(nll) when compare mode is sufficient,THUMBS_UP,2019-05-07T19:37:22Z,lqd,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-22T17:02:06Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-22T17:17:50Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-22T21:02:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-23T10:27:48Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-23T20:46:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-04-26T13:20:29Z,lqd,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-05-06T12:51:12Z,varkor,NA https://github.com/rust-lang/rust/pull/60174,MERGED,2019-04-22T16:53:35Z,2019-05-23T07:31:41Z,Add match arm scopes and other scope fixes,matthewjasper,0835048ea0fc724163b5032112df3c7555a2073b,1,Fix match ergonomics suggestion,HOORAY,2019-05-22T05:03:46Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/60186,MERGED,2019-04-22T22:57:58Z,2019-04-24T06:09:25Z,Temporarily accept [i|u][32|size] suffixes on a tuple index and warn,estebank,4c015739eadc1419b92a6a399ad145960d08f281,1,review comment: change linked ticket,THUMBS_UP,2019-04-23T08:35:38Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60186,MERGED,2019-04-22T22:57:58Z,2019-04-24T06:09:25Z,Temporarily accept [i|u][32|size] suffixes on a tuple index and warn,estebank,4c015739eadc1419b92a6a399ad145960d08f281,1,review comment: change linked ticket,THUMBS_UP,2019-04-23T13:20:38Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2019-05-15T14:25:18Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2019-06-07T20:44:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2019-06-11T23:35:40Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,HEART,2019-06-12T05:30:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2019-06-20T09:52:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2019-06-21T18:07:06Z,nosideeffects,NA https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,HEART,2021-09-16T13:43:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60187,MERGED,2019-04-23T01:28:24Z,2019-06-12T04:57:49Z,Generator optimization: Overlap locals that never have storage live at the same time,tmandry,aeefbc4cbad4461f4f846e897a04e0b3ce8cdb22,3,More review fixes,THUMBS_UP,2021-09-16T13:43:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60188,MERGED,2019-04-23T02:40:23Z,2019-05-10T03:42:56Z,Identify when a stmt could have been parsed as an expr,estebank,54430ad53ab00bf86090a8d11844db1c40b2ca24,5,review comments: fix typo and add comments,HEART,2019-04-23T05:38:06Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/60191,MERGED,2019-04-23T06:45:43Z,2019-04-23T22:39:53Z,Add f16c target_feature,gnzlbg,2d401fb4dc89eaef5b8f31330636094f9c26b4c4,1,Add f16c target_feature,HOORAY,2019-04-23T07:58:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60191,MERGED,2019-04-23T06:45:43Z,2019-04-23T22:39:53Z,Add f16c target_feature,gnzlbg,2d401fb4dc89eaef5b8f31330636094f9c26b4c4,1,Add f16c target_feature,HOORAY,2019-05-01T18:34:54Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/60198,MERGED,2019-04-23T14:24:07Z,2019-04-25T00:53:24Z,[stable] 1.34.1 point release,pietroalbini,d8a026d3bf7536e5233e6a5df42ca677a343c749,1,Try previous build image on AppVeyor,ROCKET,2019-04-24T10:58:52Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60198,MERGED,2019-04-23T14:24:07Z,2019-04-25T00:53:24Z,[stable] 1.34.1 point release,pietroalbini,d8a026d3bf7536e5233e6a5df42ca677a343c749,1,Try previous build image on AppVeyor,HEART,2019-04-24T14:58:26Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60225,MERGED,2019-04-24T04:48:56Z,2019-04-26T04:42:05Z,Introduce hir::ExprKind::Use and employ in for loop desugaring.,Centril,4bd36ab64cae41e89d53113f683d790210846c1f,13,Introduce hir::ExprKind::Use and employ in for loop desugaring. Here ExprKind::Use(P) tweaks the drop order to act the same way as '{ let _tmp = expr; _tmp }' does.,HEART,2019-04-24T06:32:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60225,MERGED,2019-04-24T04:48:56Z,2019-04-26T04:42:05Z,Introduce hir::ExprKind::Use and employ in for loop desugaring.,Centril,4bd36ab64cae41e89d53113f683d790210846c1f,13,Introduce hir::ExprKind::Use and employ in for loop desugaring. Here ExprKind::Use(P) tweaks the drop order to act the same way as '{ let _tmp = expr; _tmp }' does.,HEART,2019-04-25T14:12:04Z,estebank,NA https://github.com/rust-lang/rust/pull/60225,MERGED,2019-04-24T04:48:56Z,2019-04-26T04:42:05Z,Introduce hir::ExprKind::Use and employ in for loop desugaring.,Centril,4bd36ab64cae41e89d53113f683d790210846c1f,13,Introduce hir::ExprKind::Use and employ in for loop desugaring. Here ExprKind::Use(P) tweaks the drop order to act the same way as '{ let _tmp = expr; _tmp }' does.,HEART,2019-05-01T15:48:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60225,MERGED,2019-04-24T04:48:56Z,2019-04-26T04:42:05Z,Introduce hir::ExprKind::Use and employ in for loop desugaring.,Centril,4bd36ab64cae41e89d53113f683d790210846c1f,13,Introduce hir::ExprKind::Use and employ in for loop desugaring. Here ExprKind::Use(P) tweaks the drop order to act the same way as '{ let _tmp = expr; _tmp }' does.,HEART,2019-05-03T08:17:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60234,MERGED,2019-04-24T12:04:59Z,2019-05-10T03:42:57Z,std: Derive `Default` for `io::Cursor`,tesaguri,902904a79a5498438e93f41d728615b54c679f19,1,std: Derive `Default` for `io::Cursor`,CONFUSED,2019-05-16T12:14:37Z,fhartwig,florian.j.hartwig@gmail.com https://github.com/rust-lang/rust/pull/60240,MERGED,2019-04-24T16:25:50Z,2019-04-26T10:28:32Z, Bootstrap x86_64 musl by itself ,mati865,d4024159617e89e1ed253bd80739f6c74a3ee22f,1,Bootstrap x86_64 musl by itself,HEART,2019-04-25T12:39:55Z,ncopa,NA https://github.com/rust-lang/rust/pull/60244,MERGED,2019-04-24T19:16:26Z,2019-05-12T17:44:28Z,const-stabilize NonNull::dangling and NonNull::cast,SimonSapin,885a001788d18dbbde14587e1dbccca0dad73776,2,const-stabilize NonNull::dangling and NonNull::cast,HEART,2019-04-24T22:45:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/60244,MERGED,2019-04-24T19:16:26Z,2019-05-12T17:44:28Z,const-stabilize NonNull::dangling and NonNull::cast,SimonSapin,885a001788d18dbbde14587e1dbccca0dad73776,2,const-stabilize NonNull::dangling and NonNull::cast,HEART,2019-05-07T23:28:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60244,MERGED,2019-04-24T19:16:26Z,2019-05-12T17:44:28Z,const-stabilize NonNull::dangling and NonNull::cast,SimonSapin,885a001788d18dbbde14587e1dbccca0dad73776,2,const-stabilize NonNull::dangling and NonNull::cast,HEART,2019-05-08T18:15:42Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/60246,MERGED,2019-04-24T19:47:28Z,2019-05-08T15:24:31Z,Optimize HIR map,Zoxc,d33db6ed570a38fa52d8fdf29dbad9a5cdf4c44d,2,Rename HirMap to HirEntryMap and add some comments,HEART,2019-04-24T21:39:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/60246,MERGED,2019-04-24T19:47:28Z,2019-05-08T15:24:31Z,Optimize HIR map,Zoxc,d33db6ed570a38fa52d8fdf29dbad9a5cdf4c44d,2,Rename HirMap to HirEntryMap and add some comments,THUMBS_UP,2019-04-27T18:46:29Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60246,MERGED,2019-04-24T19:47:28Z,2019-05-08T15:24:31Z,Optimize HIR map,Zoxc,d33db6ed570a38fa52d8fdf29dbad9a5cdf4c44d,2,Rename HirMap to HirEntryMap and add some comments,THUMBS_UP,2019-05-16T04:45:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-04-26T05:26:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-04-29T20:32:03Z,tesuji,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-04-29T21:16:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-04-30T09:01:08Z,eopb,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-04-30T17:45:12Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-05-08T18:11:04Z,estebank,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-05-09T05:17:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-05-12T16:34:26Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-06-30T12:07:24Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-07-21T13:15:15Z,jesskfullwood,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-08-22T07:20:26Z,Dessix,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-09-19T16:21:26Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-11-01T15:45:43Z,alopatindev,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-11-04T23:14:34Z,d-e-s-o,NA https://github.com/rust-lang/rust/pull/60256,MERGED,2019-04-25T11:08:53Z,2019-04-29T23:35:17Z,Option::flatten,eopb,fa7ba66e6a1799982b200d563006d3c6d390aefe,1,Add flatten option for `Option>` squashed commit,HEART,2019-11-22T02:45:05Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/60257,MERGED,2019-04-25T11:22:57Z,2019-04-25T17:19:05Z,submodules: update clippy from 9897442f to 8c0e038f,matthiaskrgr,f9945f58e2df5f07b704eb2c92da5c47f62bf262,2,"submodules: update clippy from 9897442f to 8c0e038f Changes: ```` Rustup for https://github.com/rust-lang/rust/pull/59042 Update pulldown_cmark to 0.5 Only run AppVeyor on r+ try and the master branch Remove approx_constant known problems Suppress let_and_return if let has attributes Add test for or_fun_call macro suggestion UI test cleanup: Extract needless_range_loop tests Change ""if types change"" to ""if you later change the type"" ````",HEART,2019-04-25T12:21:37Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/60257,MERGED,2019-04-25T11:22:57Z,2019-04-25T17:19:05Z,submodules: update clippy from 9897442f to 8c0e038f,matthiaskrgr,f9945f58e2df5f07b704eb2c92da5c47f62bf262,2,"submodules: update clippy from 9897442f to 8c0e038f Changes: ```` Rustup for https://github.com/rust-lang/rust/pull/59042 Update pulldown_cmark to 0.5 Only run AppVeyor on r+ try and the master branch Remove approx_constant known problems Suppress let_and_return if let has attributes Add test for or_fun_call macro suggestion UI test cleanup: Extract needless_range_loop tests Change ""if types change"" to ""if you later change the type"" ````",HEART,2019-04-25T13:47:49Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-25T13:17:01Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-25T13:31:36Z,rom1v,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-25T13:49:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-25T14:32:51Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-25T17:49:47Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T01:37:21Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T05:25:26Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T05:56:34Z,gurpreetshanky,kakar.shanky@hotmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T06:33:24Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T06:54:26Z,discosultan,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T07:54:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T08:21:50Z,robatipoor,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T09:21:51Z,Dentrax,furkan.turkal@hotmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T12:08:28Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T17:31:01Z,frol,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-26T19:30:56Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HEART,2019-04-26T19:31:02Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-04-27T12:16:33Z,saschanaz,saschanaz@outlook.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-05-01T17:32:54Z,kirushik,kirill@parity.io https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HEART,2019-05-02T01:01:24Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-05-03T05:52:18Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-05-20T13:37:01Z,20iahazban,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-05-22T20:02:59Z,ArmsOfSorrow,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-06-26T12:57:34Z,seamlik,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-06-29T17:41:09Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-07-26T06:22:50Z,ellisy0,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-07-26T07:37:52Z,msabwat,mehdisabwat@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HEART,2019-08-01T10:17:16Z,schulzch,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-08-02T04:35:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HEART,2019-08-05T00:21:52Z,MaulingMonkey,git@maulingmonkey.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2019-08-05T00:21:53Z,MaulingMonkey,git@maulingmonkey.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2020-02-26T06:46:54Z,hez2010,hez2010@outlook.com https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2020-05-26T11:41:08Z,someniatko,NA https://github.com/rust-lang/rust/pull/60260,MERGED,2019-04-25T13:13:54Z,2019-07-26T06:03:33Z,Add support for UWP targets,chouquette,7ed5c36934c8023a0e55c8708dec87774212ca23,4,Add UWP mingw targets,HOORAY,2020-08-02T01:41:40Z,perrog,roger.y.persson@teliacompany.com https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,HEART,2019-04-25T15:32:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,HEART,2019-05-07T21:34:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,THUMBS_UP,2019-06-07T20:16:48Z,lqd,NA https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,HEART,2019-06-07T21:25:13Z,mati865,NA https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,THUMBS_UP,2019-07-11T13:36:48Z,panaman67,NA https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,HEART,2019-07-12T03:44:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,THUMBS_UP,2019-07-12T03:44:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60266,MERGED,2019-04-25T14:48:51Z,2019-07-13T13:44:47Z,Fact generation for liveness calculations in Polonius,amandasystems,9d3c59d69750e07d9446339c4b733c925d3571bc,5,rustfmt all the things!,THUMBS_UP,2019-07-18T04:46:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60270,MERGED,2019-04-25T16:10:49Z,2019-04-28T15:39:48Z,rustc: Flag metadata compatible with multiple CGUs,alexcrichton,955f283e11dec628a988e23100f21ab92329b3bd,1,rustc: Flag metadata compatible with multiple CGUs It looks like the `OutputType::Metadata` kind in the compiler was misclassified in #38571 long ago by accident as incompatible with codegen units and a single output file. This means that if you emit both a linkable artifact and metadata it silently turns off multiple codegen units unintentionally! This commit corrects the situation to ensure that if `--emit metadata` is used it doesn't implicitly disable multiple codegen units. This will ensure we don't accidentally regress compiler performance when striving to implement pipelined compilation!,HEART,2019-04-25T16:21:06Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/60284,MERGED,2019-04-25T20:14:48Z,2019-04-26T04:42:10Z,Do not allow const generics to depend on type parameters,varkor,6d7c7940b581e8a7f311327e9b48203ce97b8137,2,Add comment explaining restriction,HOORAY,2019-04-26T06:35:50Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60295,CLOSED,2019-04-26T01:38:20Z,2019-04-28T19:39:08Z,Elide unused import errors for failed use statements,estebank,NA,NA,NA,HOORAY,2019-04-26T02:37:47Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/60295,CLOSED,2019-04-26T01:38:20Z,2019-04-28T19:39:08Z,Elide unused import errors for failed use statements,estebank,NA,NA,NA,HOORAY,2020-09-16T15:56:15Z,arora-aman,NA https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-04-26T21:34:06Z,estebank,NA https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-05-15T14:10:52Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-05-15T15:04:26Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-05-17T00:45:31Z,RustyYato,NA https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-05-29T17:01:06Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-05-30T05:29:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-06-17T13:18:23Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-06-23T07:33:49Z,Lokathor,NA https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2019-08-12T17:40:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60300,MERGED,2019-04-26T06:16:37Z,2019-05-23T01:51:06Z,Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe,mjbshaw,a31dc8e3b153ac3073f9fb14d8e523a350fe10f2,9,"Allow null-pointer-optimized enums in FFI if their underlying representation is FFI safe This allows types like Option to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if: - E has no explicit #[repr(...)]. - It only has two variants. - One of those variants is empty (meaning it has no fields). - The other variant has only one field. - That field is one of the following: - &T - &mut T - extern ""C"" fn - core::num::NonZero* - core::ptr::NonNull - #[repr(transparent)] struct wrapper around one of the types in this list. - The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).",HEART,2020-04-29T21:06:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60305,MERGED,2019-04-26T12:26:34Z,2019-04-29T23:35:19Z,hir: remove LoweredNodeId,ljedrz,d536ec4d39b73d8bc41d2b28f3020f18f5fc6cb0,1,hir: remove LoweredNodeId,HOORAY,2019-04-26T12:33:57Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60305,MERGED,2019-04-26T12:26:34Z,2019-04-29T23:35:19Z,hir: remove LoweredNodeId,ljedrz,d536ec4d39b73d8bc41d2b28f3020f18f5fc6cb0,1,hir: remove LoweredNodeId,HOORAY,2019-04-26T14:16:03Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60305,MERGED,2019-04-26T12:26:34Z,2019-04-29T23:35:19Z,hir: remove LoweredNodeId,ljedrz,d536ec4d39b73d8bc41d2b28f3020f18f5fc6cb0,1,hir: remove LoweredNodeId,HOORAY,2019-04-26T17:31:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/60305,MERGED,2019-04-26T12:26:34Z,2019-04-29T23:35:19Z,hir: remove LoweredNodeId,ljedrz,d536ec4d39b73d8bc41d2b28f3020f18f5fc6cb0,1,hir: remove LoweredNodeId,HOORAY,2019-04-27T05:18:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60317,MERGED,2019-04-26T17:00:43Z,2019-04-28T23:32:53Z,Internal lints: usage_of_qualified_ty & ty_pass_by_reference,flip1995,2e5f0b3c49875e8cf1ee1bad2a74c2a81dcc7f78,4,Remove unused TyCtxt argument from allow_two_phase_borrow function,HOORAY,2019-04-26T19:11:15Z,estebank,NA https://github.com/rust-lang/rust/pull/60323,CLOSED,2019-04-27T02:16:00Z,2019-05-02T18:38:12Z,Parse qualified paths in type params and provide custom diagnostic,estebank,NA,NA,NA,CONFUSED,2019-04-29T07:22:15Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/60337,MERGED,2019-04-27T17:28:42Z,2019-05-06T16:43:48Z,A bit of HirIdification,fabric-and-ink,164988c1297c4c28a8f38561cbf1481c25a1c5b8,2,Remove `def_path_from_id` `node_id_to_string`,THUMBS_UP,2019-04-27T18:47:28Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60337,MERGED,2019-04-27T17:28:42Z,2019-05-06T16:43:48Z,A bit of HirIdification,fabric-and-ink,164988c1297c4c28a8f38561cbf1481c25a1c5b8,2,Remove `def_path_from_id` `node_id_to_string`,THUMBS_UP,2019-04-27T19:36:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/60341,MERGED,2019-04-27T19:39:11Z,2019-06-20T05:43:14Z,macos tlv workaround,mtak-,b148c25cacd05a0268537ead29881357317a4073,1,fix compile-fail test for targets without thread locals,HEART,2019-04-28T00:42:51Z,panaman67,NA https://github.com/rust-lang/rust/pull/60346,MERGED,2019-04-28T01:28:32Z,2019-04-28T12:50:34Z,"Fix default value for setting ""Auto-hide item methods' documentation""",dima74,b6cfcd363bcc700197da504f345afc394f9fc7f3,1,"Fix default value for setting ""Auto-hide item methods' documentation""",THUMBS_UP,2019-04-28T12:53:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/60359,MERGED,2019-04-28T19:38:45Z,2019-04-29T23:35:23Z,resolve: Consider erroneous imports used to avoid duplicate diagnostics,petrochenkov,fbbec7670137860cfbdcf3522f61c8b87f4319cb,3,resolve: Consider erroneous imports used to avoid duplicate diagnostics,HEART,2019-04-28T19:47:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60359,MERGED,2019-04-28T19:38:45Z,2019-04-29T23:35:23Z,resolve: Consider erroneous imports used to avoid duplicate diagnostics,petrochenkov,fbbec7670137860cfbdcf3522f61c8b87f4319cb,3,resolve: Consider erroneous imports used to avoid duplicate diagnostics,HEART,2019-04-29T00:29:22Z,estebank,NA https://github.com/rust-lang/rust/pull/60369,MERGED,2019-04-29T12:16:44Z,2019-05-01T20:09:38Z,Support ZSTs in DispatchFromDyn,TimDiekmann,1b679e74f050bc3ff40452e4d4c82d3fc4b03cf4,3,Only allow ZSTs with 1 byte alignment,HEART,2019-04-30T17:27:25Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/60369,MERGED,2019-04-29T12:16:44Z,2019-05-01T20:09:38Z,Support ZSTs in DispatchFromDyn,TimDiekmann,1b679e74f050bc3ff40452e4d4c82d3fc4b03cf4,3,Only allow ZSTs with 1 byte alignment,THUMBS_UP,2019-04-30T17:27:28Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/60369,MERGED,2019-04-29T12:16:44Z,2019-05-01T20:09:38Z,Support ZSTs in DispatchFromDyn,TimDiekmann,1b679e74f050bc3ff40452e4d4c82d3fc4b03cf4,3,Only allow ZSTs with 1 byte alignment,ROCKET,2019-04-30T17:27:29Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/60370,MERGED,2019-04-29T15:36:26Z,2019-05-19T04:49:47Z,Mark core::alloc::Layout::from_size_align_unchecked const,Richard-W,c0b6d3c975915e740548f0ec7bcf5963e7a3b218,2,Add ui test for const Layout::from_size_align_unchecked,THUMBS_UP,2019-04-29T20:22:51Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60373,MERGED,2019-04-29T18:00:30Z,2019-05-03T18:05:43Z,Tidy: ensure lang features are sorted by since,rasendubi,201f14b88b19d43615845bfc2a6de9bc31985b13,2,Make tidy::version::Version copy,THUMBS_UP,2019-05-01T19:57:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/60376,MERGED,2019-04-29T19:39:34Z,2019-06-13T04:19:43Z,Stabilize Option::xor,tesuji,1fa50b3ab809ec63b8b44a9f8a3a78b6d5ba41e3,1,Stabilize Option::xor,HOORAY,2019-04-29T20:27:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60376,MERGED,2019-04-29T19:39:34Z,2019-06-13T04:19:43Z,Stabilize Option::xor,tesuji,1fa50b3ab809ec63b8b44a9f8a3a78b6d5ba41e3,1,Stabilize Option::xor,HOORAY,2019-05-02T15:05:59Z,andre-vm,NA https://github.com/rust-lang/rust/pull/60376,MERGED,2019-04-29T19:39:34Z,2019-06-13T04:19:43Z,Stabilize Option::xor,tesuji,1fa50b3ab809ec63b8b44a9f8a3a78b6d5ba41e3,1,Stabilize Option::xor,HOORAY,2019-06-12T08:45:46Z,iago-lito,NA https://github.com/rust-lang/rust/pull/60376,MERGED,2019-04-29T19:39:34Z,2019-06-13T04:19:43Z,Stabilize Option::xor,tesuji,1fa50b3ab809ec63b8b44a9f8a3a78b6d5ba41e3,1,Stabilize Option::xor,HOORAY,2019-06-20T09:47:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-04-30T15:23:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-04-30T19:32:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-05-01T05:42:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-05-01T14:51:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-05-04T20:43:25Z,tmandry,NA https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2019-08-28T15:11:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60385,MERGED,2019-04-29T22:59:12Z,2019-05-02T04:48:05Z,Emit metadata files earlier,nnethercote,38dffeba21842adc9deb647b30f3a4a00abca133,4,Move metadata writing earlier. The commit moves metadata writing from `link_binary` to `encode_metadata` (and renames the latter as `encode_and_write_metadata`). This is at the very start of code generation.,HOORAY,2020-09-20T10:24:50Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/60387,MERGED,2019-04-29T23:22:21Z,2019-09-10T16:19:52Z,Allow cross-compiling doctests,Goirad,4a2094c9f61836214d9e37fa042761948483c2d9,3,address rebase changes,THUMBS_UP,2019-05-02T07:36:39Z,mati865,NA https://github.com/rust-lang/rust/pull/60387,MERGED,2019-04-29T23:22:21Z,2019-09-10T16:19:52Z,Allow cross-compiling doctests,Goirad,4a2094c9f61836214d9e37fa042761948483c2d9,3,address rebase changes,HEART,2019-06-11T20:46:30Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/60387,MERGED,2019-04-29T23:22:21Z,2019-09-10T16:19:52Z,Allow cross-compiling doctests,Goirad,4a2094c9f61836214d9e37fa042761948483c2d9,3,address rebase changes,HOORAY,2019-06-11T20:46:33Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/60396,MERGED,2019-04-30T04:10:22Z,2019-05-12T09:20:00Z,Document the order of {Vec VecDeque String}::retain,cuviper,0545375ca6822b4b140cd853f368473d69b76227,3,Add examples of ordered retain,THUMBS_UP,2019-04-30T09:11:11Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/60396,MERGED,2019-04-30T04:10:22Z,2019-05-12T09:20:00Z,Document the order of {Vec VecDeque String}::retain,cuviper,0545375ca6822b4b140cd853f368473d69b76227,3,Add examples of ordered retain,THUMBS_UP,2019-05-11T07:32:57Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/60396,MERGED,2019-04-30T04:10:22Z,2019-05-12T09:20:00Z,Document the order of {Vec VecDeque String}::retain,cuviper,0545375ca6822b4b140cd853f368473d69b76227,3,Add examples of ordered retain,THUMBS_UP,2021-05-29T12:08:34Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/60401,MERGED,2019-04-30T08:37:20Z,2019-05-03T18:05:46Z,Rename `RUST_LOG` to `RUSTC_LOG`,JohnTitor,bf4d0adf2395a260b024586e105f2e109222201c,9,Rename to RUSTC_LOG,THUMBS_UP,2019-05-03T20:02:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60401,MERGED,2019-04-30T08:37:20Z,2019-05-03T18:05:46Z,Rename `RUST_LOG` to `RUSTC_LOG`,JohnTitor,bf4d0adf2395a260b024586e105f2e109222201c,9,Rename to RUSTC_LOG,THUMBS_UP,2019-05-03T22:23:41Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60401,MERGED,2019-04-30T08:37:20Z,2019-05-03T18:05:46Z,Rename `RUST_LOG` to `RUSTC_LOG`,JohnTitor,bf4d0adf2395a260b024586e105f2e109222201c,9,Rename to RUSTC_LOG,HEART,2019-05-03T23:42:34Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/60417,MERGED,2019-04-30T15:50:00Z,2019-05-01T20:09:41Z,Rename hir::ExprKind::Use to ::DropTemps and improve docs.,Centril,d58cb934cb78b1f11c2fa44c469621c10a8359fd,12,Rename hir::ExprKind::Use to ::DropTemps and improve docs.,THUMBS_UP,2019-04-30T16:11:59Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60437,MERGED,2019-05-01T12:55:01Z,2019-05-02T04:48:08Z,Ensure that drop order of `async fn` matches `fn` and that users cannot refer to generated arguments.,davidtwco,1fedb0a20bfe03e1bf7d5c2576806c761b4e3963,4,Unify tests under async-await directory.,THUMBS_UP,2019-05-01T13:50:27Z,lqd,NA https://github.com/rust-lang/rust/pull/60439,MERGED,2019-05-01T14:03:18Z,2019-05-02T04:48:08Z,doc: Warn about possible zombie apocalypse,vorner,26199a27ffe777db9bfbff32e7ff8f5e4c7dde4c,1,doc: Warn about possible zombie apocalypse Extend the std::process::Child docs with warning about possible zombies. The previous version mentioned that when dropping the Child the process is not killed. However the wording gave the impression that such behaviour is fine to do (leaving the reader believe low-level details like reaping zombies of the dead processes is taken over by std somehow; or simply leaving the reader unaware about the problem).,LAUGH,2019-05-01T16:26:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/60439,MERGED,2019-05-01T14:03:18Z,2019-05-02T04:48:08Z,doc: Warn about possible zombie apocalypse,vorner,26199a27ffe777db9bfbff32e7ff8f5e4c7dde4c,1,doc: Warn about possible zombie apocalypse Extend the std::process::Child docs with warning about possible zombies. The previous version mentioned that when dropping the Child the process is not killed. However the wording gave the impression that such behaviour is fine to do (leaving the reader believe low-level details like reaping zombies of the dead processes is taken over by std somehow; or simply leaving the reader unaware about the problem).,LAUGH,2019-05-01T18:06:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60443,MERGED,2019-05-01T16:02:02Z,2019-05-14T23:56:18Z,as_ptr returns a read-only pointer,RalfJung,30cf0e4251533e67603c755acee5b0bd56197fce,2,clarify wording,HEART,2019-05-03T05:36:57Z,jethrogb,NA https://github.com/rust-lang/rust/pull/60444,MERGED,2019-05-01T17:25:06Z,2019-05-14T23:56:19Z,forego caching for all participants in cycles apart from root node,nikomatsakis,decd6d366018823a8b1116b346bc778eb010accd,1,modify comment modify the comment on `in_cycle` to reflect changes requested by ariel and myself.,HEART,2019-05-01T17:41:52Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60444,MERGED,2019-05-01T17:25:06Z,2019-05-14T23:56:19Z,forego caching for all participants in cycles apart from root node,nikomatsakis,decd6d366018823a8b1116b346bc778eb010accd,1,modify comment modify the comment on `in_cycle` to reflect changes requested by ariel and myself.,HEART,2019-05-01T19:10:39Z,kjeremy,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-01T18:06:47Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-01T19:23:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-01T20:54:02Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-01T20:54:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-01T21:17:26Z,cramertj,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-01T21:17:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-02T01:33:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-02T01:33:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-02T04:13:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-02T04:13:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-02T20:20:50Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-03T01:15:09Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-03T01:15:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-03T15:12:00Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-03T15:12:01Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-03T22:15:03Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-05T21:11:33Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-05T21:11:35Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-07T23:26:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-15T11:35:54Z,Dr-Emann,dremann@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-15T19:12:41Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,ROCKET,2019-05-17T12:35:13Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-18T02:04:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-20T13:55:13Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,ROCKET,2019-05-22T14:18:24Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HEART,2019-05-22T14:18:24Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-22T14:18:25Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-22T17:43:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-05-23T04:27:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,ROCKET,2019-05-28T12:20:05Z,moshg,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-07-10T17:51:19Z,bluss,NA https://github.com/rust-lang/rust/pull/60445,MERGED,2019-05-01T18:03:31Z,2019-05-20T18:07:36Z,stabilize core parts of MaybeUninit,RalfJung,1916391ea8b97389a9ed690b4df614a2b96069fd,1,update miri,HOORAY,2019-12-05T14:41:12Z,citizen-stig,nikolay.v.golub@gmail.com https://github.com/rust-lang/rust/pull/60451,MERGED,2019-05-01T20:41:51Z,2019-05-10T07:03:01Z,BinaryHeap: add min-heap example,rasendubi,adbaf7a9cdc3f67116e2034d0e5e235779dae286,1,BinaryHeap: add min-heap example,THUMBS_UP,2019-05-01T21:06:29Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/60454,MERGED,2019-05-01T21:26:59Z,2019-06-20T10:40:24Z,Add custom nth_back to Skip,acrrd,e80a37558df5ac9828caccd48459fdb7be488f5b,2,Add custom nth_back for Skip,HEART,2019-05-02T08:22:46Z,koalatux,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-01T23:34:16Z,estebank,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T00:27:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T07:52:23Z,mati865,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T08:21:59Z,tesuji,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T08:39:14Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T11:25:04Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T14:06:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/60462,MERGED,2019-05-01T23:31:40Z,2019-05-04T01:59:38Z,rustc: factor out most of hir::def::Def's variants into DefKind and rename to Res.,eddyb,ff174fe09e2e0a8f959b970e6ec410b3aafbc58a,51,"rustc: rename hir::def::Def to Res (short for ""resolution"").",THUMBS_UP,2019-05-02T19:09:58Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60463,MERGED,2019-05-02T01:15:49Z,2019-06-11T13:56:30Z,Implement RFC 2645 (transparent enums and unions),mjbshaw,dac1c6a731713ec9e90a1e05b3e2c789faf3f2ba,34,Implement RFC 2645 (transparent enums and unions) Tracking issue: #60405,THUMBS_UP,2019-05-03T21:20:58Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-02T13:51:01Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-02T14:01:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-02T15:21:05Z,cramertj,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-02T15:30:47Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-02T20:24:02Z,CryZe,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-03T00:32:51Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-03T07:56:23Z,dragostis,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-03T17:22:00Z,Pratyush,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-03T21:18:02Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-04T22:22:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T05:45:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T05:45:53Z,Randl,zheltonozhskiy@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T05:57:05Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T06:24:33Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T10:54:35Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T11:02:14Z,bash,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T12:24:07Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T12:41:26Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T13:45:05Z,archseer,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-05T18:10:01Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T18:11:34Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T19:04:46Z,kgv,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-05T23:34:47Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-06T08:17:17Z,jplatte,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-06T09:15:52Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-06T17:57:03Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-06T18:28:25Z,Avi-D-coder,avi.the.coder@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-06T19:20:10Z,darksv,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-07T02:32:17Z,moshg,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-07T02:32:26Z,moshg,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-07T14:14:58Z,JonathanBrouwer,jonathantbrouwer@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-08T05:54:17Z,kgv,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-08T09:27:28Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-08T09:27:29Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-08T14:33:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-08T15:17:18Z,berkus,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-09T05:06:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-09T12:29:32Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-18T10:55:46Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-18T21:53:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-18T23:43:36Z,qezz,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-18T23:43:39Z,qezz,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-27T12:29:57Z,kpp,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-30T15:00:04Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-30T19:32:49Z,varkor,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T05:03:03Z,kennytm,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-31T06:09:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T10:34:35Z,varkor,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T13:28:04Z,polachok,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T13:30:28Z,kpp,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-05-31T15:46:39Z,yuriy-larin-firstbridge,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T15:46:41Z,yuriy-larin-firstbridge,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T22:45:31Z,bb010g,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-05-31T23:56:48Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-01T13:04:58Z,awulkan,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-01T13:04:59Z,awulkan,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-01T18:24:30Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T04:54:43Z,kamalmarhubi,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T05:21:23Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T05:48:58Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T06:14:30Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T06:14:30Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T06:25:18Z,UtherII,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T06:32:24Z,jeehoonkang,jeehoon.kang@kaist.ac.kr https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T06:32:27Z,jeehoonkang,jeehoon.kang@kaist.ac.kr https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T06:54:56Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T06:54:57Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T07:05:25Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T07:46:07Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T07:56:09Z,justanotherdot,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T08:13:54Z,martinlindhe,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T08:20:12Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T08:57:19Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T08:57:21Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T09:04:51Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T09:04:56Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T09:29:33Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T09:49:29Z,funbringer,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T10:11:31Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T10:24:18Z,MOZGIII,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T10:40:54Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T10:47:47Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T11:23:26Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T11:25:09Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T12:02:55Z,DCjanus,DCjanus@dcjanus.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T12:26:55Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T13:11:31Z,hwchen,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T13:11:33Z,hwchen,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T14:12:12Z,delacian,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T14:42:22Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T14:54:40Z,chirsz-ever,chirsz@foxmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T14:54:45Z,chirsz-ever,chirsz@foxmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T15:05:45Z,eupn,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T15:05:46Z,eupn,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T15:15:49Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T15:27:29Z,Angr1st,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T15:55:02Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T15:59:22Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T15:59:23Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T15:59:24Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T16:05:32Z,ALSchwalm,adamschwalm@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T16:08:01Z,bestouff,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T16:30:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T16:33:28Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T16:45:59Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T17:01:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T17:09:26Z,estebank,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T17:40:29Z,elpiel,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T17:40:30Z,elpiel,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T18:24:02Z,eyelash,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T18:35:37Z,killercup,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T18:36:59Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T20:15:42Z,maplant,maplant95@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T20:28:13Z,matematikaadit,matematika.adit@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T21:07:26Z,tikue,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T21:07:27Z,tikue,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T21:07:28Z,tikue,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T21:09:43Z,steffengy,steffen.butzer@outlook.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T21:45:32Z,gabibbo97,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-02T21:45:34Z,gabibbo97,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-02T21:45:35Z,gabibbo97,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-02T21:45:38Z,gabibbo97,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-02T22:41:08Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-02T23:20:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T01:42:18Z,rsphing,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T02:16:17Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-03T04:43:54Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-03T05:50:27Z,Fly-Style,alex.syrotenko.official@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T05:58:57Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T09:47:29Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-03T09:47:30Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-03T10:05:54Z,elichai,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T10:05:55Z,elichai,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T11:17:59Z,Vurich,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-03T11:32:01Z,mati865,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T13:30:26Z,yfaming,yfaming@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T14:13:09Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T14:44:08Z,Jaak,jaak.ra@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-03T17:02:45Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,EYES,2019-06-03T17:02:51Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T17:11:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T18:29:44Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T20:48:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-03T22:27:12Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-04T18:05:04Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-05T20:41:54Z,brson,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-05T20:41:54Z,brson,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-05T20:41:54Z,brson,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-05T20:41:55Z,brson,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,EYES,2019-06-05T20:41:56Z,brson,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-05T21:13:42Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-06T06:34:53Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-07T15:13:27Z,andre-vm,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-08T14:06:27Z,keliwang,root@keli.im https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-08T18:48:45Z,vcombey,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-08T18:48:47Z,vcombey,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-08T18:48:48Z,vcombey,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-12T06:23:16Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-12T09:40:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-13T13:42:09Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-06-18T17:34:49Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-06-18T17:34:51Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-19T07:33:44Z,adamjcook,adam.j.cook@alliedstrand.com https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,THUMBS_UP,2019-06-21T19:05:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-06-21T19:05:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,EYES,2019-06-21T19:05:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-07-11T08:30:34Z,bermanboris,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HEART,2019-07-11T08:30:35Z,bermanboris,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,ROCKET,2019-07-11T08:30:35Z,bermanboris,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2019-07-16T10:58:09Z,kompass,NA https://github.com/rust-lang/rust/pull/60466,CLOSED,2019-05-02T09:01:57Z,2019-07-07T03:40:06Z,Switch libcore array implementations to const generics.,crlf0710,NA,NA,NA,HOORAY,2020-04-06T09:59:32Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/60467,MERGED,2019-05-02T10:47:06Z,2019-05-03T18:05:51Z,Avoid repeated interning of static strings.,nnethercote,6ef39e69eac42e1cc86ec8eeb1b85c6b3a8784fa,2,"Avoid repeated interning of static strings. `file_metadata_raw` interns the strings `""""` and `""""` very frequently. This commit avoids that which reduces the number of symbols interned significantly and reduces instruction counts by up to 0.5% on some workloads.",THUMBS_UP,2019-05-09T05:07:59Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60501,MERGED,2019-05-03T04:14:47Z,2019-05-03T18:05:53Z,Propagate mutability from arguments to local bindings in async fn,taiki-e,2fe50bc01bf9023b64a72407bb41a1f3b7245abd,2,Propagate mutability from arguments to local bindings in async fn,THUMBS_UP,2019-05-03T07:02:19Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60501,MERGED,2019-05-03T04:14:47Z,2019-05-03T18:05:53Z,Propagate mutability from arguments to local bindings in async fn,taiki-e,2fe50bc01bf9023b64a72407bb41a1f3b7245abd,2,Propagate mutability from arguments to local bindings in async fn,HOORAY,2019-05-03T07:02:22Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60501,MERGED,2019-05-03T04:14:47Z,2019-05-03T18:05:53Z,Propagate mutability from arguments to local bindings in async fn,taiki-e,2fe50bc01bf9023b64a72407bb41a1f3b7245abd,2,Propagate mutability from arguments to local bindings in async fn,ROCKET,2019-05-03T07:02:24Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60501,MERGED,2019-05-03T04:14:47Z,2019-05-03T18:05:53Z,Propagate mutability from arguments to local bindings in async fn,taiki-e,2fe50bc01bf9023b64a72407bb41a1f3b7245abd,2,Propagate mutability from arguments to local bindings in async fn,HEART,2019-05-03T07:02:26Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60511,MERGED,2019-05-03T15:10:43Z,2019-05-21T00:33:54Z,Fix intra-doc link resolution failure on re-exporting libstd,taiki-e,ccb9dac5ed65341bf8d9ce01a83b9aad02f42526,13,Fix intra-doc link resolution failure on re-exporting libstd,THUMBS_UP,2019-05-03T15:12:12Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/60511,MERGED,2019-05-03T15:10:43Z,2019-05-21T00:33:54Z,Fix intra-doc link resolution failure on re-exporting libstd,taiki-e,ccb9dac5ed65341bf8d9ce01a83b9aad02f42526,13,Fix intra-doc link resolution failure on re-exporting libstd,THUMBS_UP,2019-05-05T17:04:51Z,najamelan,NA https://github.com/rust-lang/rust/pull/60511,MERGED,2019-05-03T15:10:43Z,2019-05-21T00:33:54Z,Fix intra-doc link resolution failure on re-exporting libstd,taiki-e,ccb9dac5ed65341bf8d9ce01a83b9aad02f42526,13,Fix intra-doc link resolution failure on re-exporting libstd,THUMBS_UP,2019-05-23T14:04:04Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/60513,MERGED,2019-05-03T17:00:09Z,2019-05-04T10:22:32Z,Remove -Z borrowck=compare flag,chrisvittal,db6f7a9d1a8b9aeae93e0512f0f236fda36b0314,2,Update help message,HOORAY,2019-05-03T17:01:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60513,MERGED,2019-05-03T17:00:09Z,2019-05-04T10:22:32Z,Remove -Z borrowck=compare flag,chrisvittal,db6f7a9d1a8b9aeae93e0512f0f236fda36b0314,2,Update help message,HOORAY,2019-05-03T17:22:45Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/60513,MERGED,2019-05-03T17:00:09Z,2019-05-04T10:22:32Z,Remove -Z borrowck=compare flag,chrisvittal,db6f7a9d1a8b9aeae93e0512f0f236fda36b0314,2,Update help message,HEART,2019-05-03T18:18:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/60513,MERGED,2019-05-03T17:00:09Z,2019-05-04T10:22:32Z,Remove -Z borrowck=compare flag,chrisvittal,db6f7a9d1a8b9aeae93e0512f0f236fda36b0314,2,Update help message,HOORAY,2019-05-03T18:18:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/60515,MERGED,2019-05-03T17:09:20Z,2019-05-06T00:07:55Z,use span instead of div for since version,euclio,8fc6e420d16dc882f2047e6ec1b981cac5ef0d14,3,use span instead of div for since version,THUMBS_UP,2019-05-03T18:14:07Z,kentfredric,kentfredric@gmail.com https://github.com/rust-lang/rust/pull/60516,MERGED,2019-05-03T17:27:28Z,2019-05-04T10:22:33Z,Remove TypeckMir,JohnTitor,f734057c3c8cf621dc59d4c8e29b361d40c42612,1,Fix test,HEART,2019-05-03T18:15:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/60520,MERGED,2019-05-03T18:46:44Z,2019-05-04T10:22:34Z,Add rustfmt toml,matklad,ce39461ca75ae5cdc5e7798869d88666ad139646,1,Add rustfmt toml This commit adds an rustfmt.toml for using for **new** code. Old code should continut to use old style until we put automated style checks in place. See https://internals.rust-lang.org/t/running-rustfmt-on-rust-lang-rust-and-other-rust-lang-repositories/8732/81 for the reason why we deviate from the default formatting. The TL;DR is that currently compiler uses a pretty condensed style of code and default settings both create a huge diff and inflate the number of lines. use_small_heuristics=Max fixes that. version=Two is required for bug-fixes which technically can't be made to the stable first version,THUMBS_UP,2019-05-03T18:49:48Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/60520,MERGED,2019-05-03T18:46:44Z,2019-05-04T10:22:34Z,Add rustfmt toml,matklad,ce39461ca75ae5cdc5e7798869d88666ad139646,1,Add rustfmt toml This commit adds an rustfmt.toml for using for **new** code. Old code should continut to use old style until we put automated style checks in place. See https://internals.rust-lang.org/t/running-rustfmt-on-rust-lang-rust-and-other-rust-lang-repositories/8732/81 for the reason why we deviate from the default formatting. The TL;DR is that currently compiler uses a pretty condensed style of code and default settings both create a huge diff and inflate the number of lines. use_small_heuristics=Max fixes that. version=Two is required for bug-fixes which technically can't be made to the stable first version,THUMBS_UP,2019-05-03T18:51:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60520,MERGED,2019-05-03T18:46:44Z,2019-05-04T10:22:34Z,Add rustfmt toml,matklad,ce39461ca75ae5cdc5e7798869d88666ad139646,1,Add rustfmt toml This commit adds an rustfmt.toml for using for **new** code. Old code should continut to use old style until we put automated style checks in place. See https://internals.rust-lang.org/t/running-rustfmt-on-rust-lang-rust-and-other-rust-lang-repositories/8732/81 for the reason why we deviate from the default formatting. The TL;DR is that currently compiler uses a pretty condensed style of code and default settings both create a huge diff and inflate the number of lines. use_small_heuristics=Max fixes that. version=Two is required for bug-fixes which technically can't be made to the stable first version,THUMBS_UP,2019-05-03T18:51:33Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60520,MERGED,2019-05-03T18:46:44Z,2019-05-04T10:22:34Z,Add rustfmt toml,matklad,ce39461ca75ae5cdc5e7798869d88666ad139646,1,Add rustfmt toml This commit adds an rustfmt.toml for using for **new** code. Old code should continut to use old style until we put automated style checks in place. See https://internals.rust-lang.org/t/running-rustfmt-on-rust-lang-rust-and-other-rust-lang-repositories/8732/81 for the reason why we deviate from the default formatting. The TL;DR is that currently compiler uses a pretty condensed style of code and default settings both create a huge diff and inflate the number of lines. use_small_heuristics=Max fixes that. version=Two is required for bug-fixes which technically can't be made to the stable first version,THUMBS_UP,2019-05-03T18:52:27Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60542,MERGED,2019-05-04T11:42:57Z,2019-05-29T10:39:30Z,Add Step::sub_usize,timvermeulen,f1d0829e20e3ff3ff78a09136968612887544af2,3,Add Step::sub_usize,THUMBS_UP,2019-05-06T05:53:36Z,koalatux,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HEART,2019-05-04T21:36:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-05-04T21:36:51Z,panaman67,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-05-04T21:36:53Z,panaman67,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-05-05T01:19:53Z,MichaelHoelzl,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HEART,2019-05-05T07:44:16Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-05-05T13:28:24Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HEART,2019-05-05T13:28:25Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-05-05T13:28:25Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HOORAY,2019-05-06T07:48:18Z,mati865,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-05-10T15:57:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-06-13T15:56:57Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HOORAY,2019-06-24T05:30:18Z,panaman67,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-07-12T02:11:51Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HOORAY,2019-07-21T23:57:46Z,yerke,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HEART,2019-08-07T15:44:10Z,RalfJung,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-08-07T19:39:24Z,fabiao,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HOORAY,2019-08-07T19:39:26Z,fabiao,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HEART,2019-08-07T19:39:27Z,fabiao,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-08-07T19:39:28Z,fabiao,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,HOORAY,2019-11-29T02:22:54Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-11-29T02:22:55Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2019-12-05T16:53:06Z,librelois,NA https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,ROCKET,2019-12-22T12:57:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60547,MERGED,2019-05-04T16:07:31Z,2019-08-07T20:48:14Z,redox: convert to target_family unix,jackpot51,ebb648d4fbda07477ab9454dfda98187cd26aa34,2,Fix cfg_if usage,THUMBS_UP,2020-11-24T17:33:16Z,qarmin,NA https://github.com/rust-lang/rust/pull/60549,MERGED,2019-05-04T20:15:16Z,2019-05-29T21:56:20Z,do not print panic message on doctest failures,euclio,89d437ec76cab8153ada936c5d67ef2deb901eb4,10,do not print panic message on doctest failures,HOORAY,2019-05-06T13:47:35Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/60549,MERGED,2019-05-04T20:15:16Z,2019-05-29T21:56:20Z,do not print panic message on doctest failures,euclio,89d437ec76cab8153ada936c5d67ef2deb901eb4,10,do not print panic message on doctest failures,HEART,2019-05-06T13:47:38Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/60549,MERGED,2019-05-04T20:15:16Z,2019-05-29T21:56:20Z,do not print panic message on doctest failures,euclio,89d437ec76cab8153ada936c5d67ef2deb901eb4,10,do not print panic message on doctest failures,HOORAY,2019-05-06T13:48:35Z,DebugSteven,debugsteven@gmail.com https://github.com/rust-lang/rust/pull/60568,MERGED,2019-05-05T19:43:34Z,2019-05-24T15:40:35Z,rustbuild: Simplify debuginfo configuration,petrochenkov,780e406db2eb553e9127e64462ee8626f4132aa3,1,Address review comments,HEART,2019-05-05T19:45:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/60581,MERGED,2019-05-06T12:57:05Z,2019-05-22T04:42:15Z,convert custom try macro to `?`,hellow554,5458b651b1ecad5cc334b494209352ac935360ce,2,use exhaustive_patterns to be able to use `?`,THUMBS_UP,2019-05-07T22:08:25Z,estebank,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T18:16:29Z,tesuji,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T18:29:04Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T18:52:13Z,marty-se,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T19:11:01Z,ngg,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T19:23:38Z,viktorku,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T21:23:41Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-06T22:09:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T03:59:31Z,rushmorem,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T07:37:52Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T07:50:42Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T09:10:15Z,shengsheng,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-07T09:23:52Z,95th,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T12:06:35Z,Kvikal,g4rrus@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T12:13:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T14:20:11Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T17:14:40Z,tmandry,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T17:34:25Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-07T17:34:27Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T19:44:32Z,JuanPotato,hasan@juanpota.to https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T19:51:42Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T20:15:13Z,frol,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-07T20:28:50Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T21:23:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-07T21:36:42Z,estebank,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-07T21:51:04Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-07T21:51:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T01:01:57Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T02:26:53Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-08T02:26:56Z,h-michael,h.hata.ai.t@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T06:50:21Z,buesima,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T07:15:51Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-08T07:15:55Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-08T07:16:03Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T09:36:42Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T11:46:28Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T12:17:17Z,light4,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-08T18:26:51Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T20:00:22Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-08T21:49:51Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-08T23:23:38Z,skippy10110,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T00:02:03Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T00:29:27Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T00:40:06Z,fanzier,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T01:46:05Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T03:57:09Z,k-nasa,htilcs1115@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T04:10:56Z,yerke,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-09T06:06:41Z,dev-bio,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T06:51:48Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-09T08:00:03Z,justinas,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-09T08:01:29Z,bitbegin,bitbegin@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-09T09:52:01Z,theduke,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T12:58:34Z,keliwang,root@keli.im https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T13:55:40Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-09T15:24:25Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-09T19:37:06Z,EmilHernvall,emil@c0la.se https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-10T03:18:06Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-10T04:20:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-10T05:27:01Z,5aaee9,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-10T09:13:25Z,darksv,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-11T04:08:00Z,AndrewJakubowicz,spyr1014@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-11T04:08:01Z,AndrewJakubowicz,spyr1014@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-11T22:11:07Z,huxi,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-12T13:38:44Z,phaux,lisqxd@proton.me https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-12T14:03:23Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-15T12:05:06Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-15T13:19:49Z,jq-rs,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-15T14:07:28Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-15T14:07:31Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-15T19:16:59Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-15T19:17:03Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-15T21:48:21Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-15T22:00:43Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-16T04:49:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-16T05:19:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-16T06:21:30Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-16T07:55:53Z,elpiel,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-16T08:47:31Z,kjaleshire,kjaleshire@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-16T09:03:09Z,RomanAkberov,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-16T13:47:32Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-16T13:47:34Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-16T14:17:27Z,PeterDing,dfhayst@gmail.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-17T10:12:04Z,zzeroo,co@zzeroo.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-17T22:34:50Z,tjkirch,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-18T12:59:10Z,Terkwood,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-18T12:59:11Z,Terkwood,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-18T12:59:13Z,Terkwood,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-18T12:59:15Z,Terkwood,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-19T02:40:29Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-19T02:40:35Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,CONFUSED,2019-05-19T11:27:12Z,thomaswulz,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-20T19:09:07Z,ssilaev,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,ROCKET,2019-05-21T17:35:10Z,jeffvandyke,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,THUMBS_UP,2019-05-21T17:35:26Z,jeffvandyke,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HEART,2019-05-23T21:26:33Z,chrish42,NA https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-05-30T03:46:08Z,mantou132,709922234@qq.com https://github.com/rust-lang/rust/pull/60586,MERGED,2019-05-06T17:52:42Z,2019-05-08T01:28:24Z,Implement built-in await syntax,cramertj,fe8760cb848d45f5c83b41e689878b893b74e45d,37,Implement built-in await syntax Adds support for .await under the existing async_await feature gate. Moves macro-like await! syntax to the await_macro feature gate. Removes support for `await` as a non-keyword under the `async_await` feature.,HOORAY,2019-06-11T17:45:53Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/60588,MERGED,2019-05-06T20:03:14Z,2019-05-10T18:26:59Z,"Revert ""Disable big-endian simd in swap_nonoverlapping_bytes""",cuviper,9a0a87a654303c69856d55dac419a2c440efc3d4,1,"Revert ""Disable big-endian simd in swap_nonoverlapping_bytes"" This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e. Issue #42778 was formerly easy to reproduce on two big-endian targets `powerpc64` and `s390x` so we disabled SIMD on this function for all big-endian targets as a workaround. I have re-tested this code on `powerpc64` and `s390x` each with the bundled LLVM 8 and with external LLVM 7 and LLVM 6 and the problems no longer appear. So it seems safe to remove this workaround although I'm still a little uncomfortable that we never found a root-cause...",HOORAY,2019-05-17T02:55:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/60597,MERGED,2019-05-07T01:31:51Z,2019-05-17T00:50:11Z,Do some simple constant propagation in the ConstProp pass,wesleywiser,b17066dd5eaf3dabd403bd4caccfca193c7184db,1,Add test to ensure const-prop fails gracefully,THUMBS_UP,2019-05-16T15:22:04Z,lqd,NA https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T14:10:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T14:19:33Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T15:40:41Z,hcpl,NA https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T18:57:18Z,mcarton,NA https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T21:44:42Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/60601,MERGED,2019-05-07T11:48:42Z,2019-05-09T21:51:18Z,Add a `cast` method to raw pointers.,SimonSapin,d5e819015f550bedb27bc287f96f3937bb831cd5,1,Add a `cast` method to raw pointers. This is similar to `NonNull::cast`. Compared to the `as` operator (which has a wide range of meanings depending on the input and output types) a call to this method: * Can only go from a raw pointer to a raw pointer * Cannot change the pointer’s `const`ness … even when the pointed types are inferred based on context.,THUMBS_UP,2019-05-07T23:13:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60618,MERGED,2019-05-07T22:44:49Z,2019-05-10T03:43:09Z,Comment ext::tt::transcribe,mark-i-m,eb7d47cba90ac716c84fe720418e58c6eb84ac4e,1,fix incorrect assert,HEART,2019-05-07T22:48:15Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60618,MERGED,2019-05-07T22:44:49Z,2019-05-10T03:43:09Z,Comment ext::tt::transcribe,mark-i-m,eb7d47cba90ac716c84fe720418e58c6eb84ac4e,1,fix incorrect assert,HEART,2019-05-07T22:52:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-08T11:51:29Z,mati865,NA https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,HEART,2019-05-08T13:40:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-08T17:29:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-08T20:35:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,HEART,2019-05-08T20:35:52Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-15T23:39:42Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,HEART,2019-05-15T23:39:43Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-16T04:50:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60630,MERGED,2019-05-08T09:46:05Z,2019-05-13T03:12:05Z,Use `Symbol` more,nnethercote,ea9fac5687c24abad493caf4ec5042af47458af9,15,Return a `Symbol` from `name_or_empty` functions.,THUMBS_UP,2019-05-17T21:33:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/60634,MERGED,2019-05-08T13:01:41Z,2019-05-09T01:51:28Z,Document + Cleanup lang_items.rs,Centril,47768b2613393e39218c255ed990169665d69df9,1,Document + Cleanup lang_items.rs,HEART,2019-05-08T17:16:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60641,MERGED,2019-05-08T17:24:41Z,2019-05-09T01:51:28Z,Instead of ICEing on incorrect pattern use delay_span_bug,estebank,cc40f41ee5baefa0dc1845dd9d794abe90511161,3,Instead of ICEing on incorrect pattern use delay_span_bug,HEART,2019-05-09T06:44:49Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60647,MERGED,2019-05-08T21:10:12Z,2019-05-09T21:51:20Z,cleanup: Remove `DefIndexAddressSpace`,petrochenkov,ee6d31520071b38f9a2996d60a66d6e2cd965fe7,42,cleanup: Remove `DefIndexAddressSpace`,HEART,2019-05-08T23:22:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/60647,MERGED,2019-05-08T21:10:12Z,2019-05-09T21:51:20Z,cleanup: Remove `DefIndexAddressSpace`,petrochenkov,ee6d31520071b38f9a2996d60a66d6e2cd965fe7,42,cleanup: Remove `DefIndexAddressSpace`,HEART,2019-05-09T10:52:05Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/60647,MERGED,2019-05-08T21:10:12Z,2019-05-09T21:51:20Z,cleanup: Remove `DefIndexAddressSpace`,petrochenkov,ee6d31520071b38f9a2996d60a66d6e2cd965fe7,42,cleanup: Remove `DefIndexAddressSpace`,HEART,2019-05-09T22:59:26Z,tmandry,NA https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-08T22:38:19Z,swgillespie,sean@swgillespie.me https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-08T22:50:01Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-08T23:09:52Z,estebank,NA https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-09T13:17:27Z,lqd,NA https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-13T12:22:34Z,mattjohnruss,NA https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-13T13:56:41Z,mati865,NA https://github.com/rust-lang/rust/pull/60649,MERGED,2019-05-08T22:30:13Z,2019-05-13T13:48:23Z,save-analysis: Fix ICE when processing associated constant,Xanewok,0af18eed107f8b5d113e7d8e33f9182e37f0996b,2,Appease tidy,HOORAY,2019-05-13T14:58:43Z,norru,nigu.orru@gmail.com https://github.com/rust-lang/rust/pull/60656,MERGED,2019-05-09T02:55:46Z,2019-05-09T21:51:21Z,Inline some Cursor calls for slices,petertodd,b9c430129d5971df4410b6c829b100ce8191328e,1,Inline some Cursor calls for slices (Partially) brings back https://github.com/rust-lang/rust/pull/33921,THUMBS_UP,2019-05-09T05:03:02Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60656,MERGED,2019-05-09T02:55:46Z,2019-05-09T21:51:21Z,Inline some Cursor calls for slices,petertodd,b9c430129d5971df4410b6c829b100ce8191328e,1,Inline some Cursor calls for slices (Partially) brings back https://github.com/rust-lang/rust/pull/33921,THUMBS_UP,2019-05-09T08:59:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60667,MERGED,2019-05-09T11:49:14Z,2019-06-19T19:28:00Z, Add functions for building raw slices to libcore ,oli-obk,8b21b075f73c629c25e8225c78a2992aa6e1d874,2,Add functions to build raw slices,HEART,2019-05-11T08:43:19Z,mati865,NA https://github.com/rust-lang/rust/pull/60667,MERGED,2019-05-09T11:49:14Z,2019-06-19T19:28:00Z, Add functions for building raw slices to libcore ,oli-obk,8b21b075f73c629c25e8225c78a2992aa6e1d874,2,Add functions to build raw slices,HEART,2019-06-19T08:45:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60667,MERGED,2019-05-09T11:49:14Z,2019-06-19T19:28:00Z, Add functions for building raw slices to libcore ,oli-obk,8b21b075f73c629c25e8225c78a2992aa6e1d874,2,Add functions to build raw slices,HEART,2019-07-27T10:14:20Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/60667,MERGED,2019-05-09T11:49:14Z,2019-06-19T19:28:00Z, Add functions for building raw slices to libcore ,oli-obk,8b21b075f73c629c25e8225c78a2992aa6e1d874,2,Add functions to build raw slices,HEART,2019-10-04T22:48:26Z,bluss,NA https://github.com/rust-lang/rust/pull/60669,MERGED,2019-05-09T12:39:46Z,2019-06-12T10:33:16Z,Allow attributes in formal function parameters,c410-f3r,1eaaf440d5173f090d6e937f4b4cffec6c038984,28,Allow attributes in formal function parameters,THUMBS_UP,2019-05-09T14:56:01Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60669,MERGED,2019-05-09T12:39:46Z,2019-06-12T10:33:16Z,Allow attributes in formal function parameters,c410-f3r,1eaaf440d5173f090d6e937f4b4cffec6c038984,28,Allow attributes in formal function parameters,THUMBS_UP,2019-05-26T20:39:14Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60669,MERGED,2019-05-09T12:39:46Z,2019-06-12T10:33:16Z,Allow attributes in formal function parameters,c410-f3r,1eaaf440d5173f090d6e937f4b4cffec6c038984,28,Allow attributes in formal function parameters,THUMBS_UP,2019-06-12T10:50:10Z,Kvikal,g4rrus@gmail.com https://github.com/rust-lang/rust/pull/60669,MERGED,2019-05-09T12:39:46Z,2019-06-12T10:33:16Z,Allow attributes in formal function parameters,c410-f3r,1eaaf440d5173f090d6e937f4b4cffec6c038984,28,Allow attributes in formal function parameters,THUMBS_UP,2020-03-01T23:28:46Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/60669,MERGED,2019-05-09T12:39:46Z,2019-06-12T10:33:16Z,Allow attributes in formal function parameters,c410-f3r,1eaaf440d5173f090d6e937f4b4cffec6c038984,28,Allow attributes in formal function parameters,THUMBS_UP,2022-06-21T10:46:12Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/60675,MERGED,2019-05-09T17:51:35Z,2019-05-10T03:43:11Z,Remove the old await! macro,cramertj,df41e4f695a057fb14fdbc63b9009dafe4d7f681,1,Remove the old await! macro This doesn't work anymore and its continued presence is cause for confusion.,THUMBS_UP,2019-05-09T18:39:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/60675,MERGED,2019-05-09T17:51:35Z,2019-05-10T03:43:11Z,Remove the old await! macro,cramertj,df41e4f695a057fb14fdbc63b9009dafe4d7f681,1,Remove the old await! macro This doesn't work anymore and its continued presence is cause for confusion.,THUMBS_UP,2019-05-09T18:42:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60676,MERGED,2019-05-09T18:21:12Z,2019-05-10T03:43:12Z,Fix async desugaring providing wrong input to procedural macros.,davidtwco,d5e04067cb23df91070fea1a01aa6417afa714ed,1,Add FIXME about `construct_async_arguments`. This is unrelated to the rest of this PR but it made sense to add a FIXME explaining that the function shouldn't really be in the parser.,HEART,2019-05-09T18:27:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60676,MERGED,2019-05-09T18:21:12Z,2019-05-10T03:43:12Z,Fix async desugaring providing wrong input to procedural macros.,davidtwco,d5e04067cb23df91070fea1a01aa6417afa714ed,1,Add FIXME about `construct_async_arguments`. This is unrelated to the rest of this PR but it made sense to add a FIXME explaining that the function shouldn't really be in the parser.,HEART,2019-05-09T18:30:35Z,lqd,NA https://github.com/rust-lang/rust/pull/60679,MERGED,2019-05-09T19:28:33Z,2019-05-12T20:28:53Z,Keep original literal tokens in AST,petrochenkov,83ed781c017632d48746553bdb2bf3d1633d5ca4,3,Address comments + Fix tests,HEART,2019-05-09T19:33:19Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60679,MERGED,2019-05-09T19:28:33Z,2019-05-12T20:28:53Z,Keep original literal tokens in AST,petrochenkov,83ed781c017632d48746553bdb2bf3d1633d5ca4,3,Address comments + Fix tests,HEART,2019-05-10T15:22:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60679,MERGED,2019-05-09T19:28:33Z,2019-05-12T20:28:53Z,Keep original literal tokens in AST,petrochenkov,83ed781c017632d48746553bdb2bf3d1633d5ca4,3,Address comments + Fix tests,HEART,2019-05-12T21:29:36Z,estebank,NA https://github.com/rust-lang/rust/pull/60679,MERGED,2019-05-09T19:28:33Z,2019-05-12T20:28:53Z,Keep original literal tokens in AST,petrochenkov,83ed781c017632d48746553bdb2bf3d1633d5ca4,3,Address comments + Fix tests,HEART,2019-05-16T04:51:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60684,MERGED,2019-05-09T22:02:55Z,2019-05-10T12:56:38Z,Fix cfg(test) build on SGX,jethrogb,adb998fe21f148e8f84fc1262725c4385216c95d,1,Fix cfg(test) build on SGX,THUMBS_UP,2019-05-09T23:09:08Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/60685,MERGED,2019-05-09T22:48:13Z,2019-05-17T03:52:09Z,Switch to SPDX 2.1 license expression,dtolnay,08cd34e4fc062345dd20c018384b360cd57915b1,6,Switch to SPDX 2.1 license expression According to the Cargo Reference: https://doc.rust-lang.org/cargo/reference/manifest.html > This is an SPDX 2.1 license expression for this package. Currently > crates.io will validate the license provided against a whitelist of > known license and exception identifiers from the SPDX license list > 2.4. Parentheses are not currently supported. > > Multiple licenses can be separated with a `/` although that usage > is deprecated. Instead use a license expression with AND and OR > operators to get more explicit semantics.,THUMBS_UP,2019-05-10T02:26:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/60687,MERGED,2019-05-09T23:31:33Z,2019-05-17T03:52:09Z,Fix .natvis visualizers.,MaulingMonkey,7c55b48d3121178ca05e04812e4c708f7fa6dff5,2,Fix .natvis visualizers. Updated to handle these changes: - `core::ptr::*` lost their `__0` elements and are just plain pointers - `core::ptr::*` probably shouldn't dereference in `DisplayString` s - `VecDeque` and `Vec` use `core::ptr::*` s - `VecDeque` and `LinkedList` moved modules again. Retested - still working fine left alone: - `String` `&str` `Option`,THUMBS_UP,2019-05-14T21:57:58Z,Vlad-Shcherbina,vlad.shcherbina@gmail.com https://github.com/rust-lang/rust/pull/60703,CLOSED,2019-05-10T15:48:19Z,2020-01-12T13:07:20Z,WIP: Allocator- and fallibility-polymorphic collections ,Ericson2314,NA,NA,NA,HEART,2019-07-22T16:45:57Z,cramertj,NA https://github.com/rust-lang/rust/pull/60719,MERGED,2019-05-10T23:44:42Z,2019-05-14T23:56:25Z,Allow subdirectories to be tested by x.py test,varkor,b470d48c8a58a6cd91a14e5ba6387f424da6c5db,1,Add comment,HEART,2019-05-11T07:38:08Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60719,MERGED,2019-05-10T23:44:42Z,2019-05-14T23:56:25Z,Allow subdirectories to be tested by x.py test,varkor,b470d48c8a58a6cd91a14e5ba6387f424da6c5db,1,Add comment,HEART,2019-05-12T06:16:48Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60719,MERGED,2019-05-10T23:44:42Z,2019-05-14T23:56:25Z,Allow subdirectories to be tested by x.py test,varkor,b470d48c8a58a6cd91a14e5ba6387f424da6c5db,1,Add comment,HEART,2019-05-13T18:20:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60730,MERGED,2019-05-11T10:54:44Z,2019-06-16T12:15:16Z,Optimize matches,matthewjasper,89ea69ab238d1d61d00a44e72061f6794d937255,1,Add a test for simple matches,THUMBS_UP,2019-06-20T09:46:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2019-05-11T23:13:17Z,kellytk,NA https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2019-05-13T16:30:36Z,RReverser,me@rreverser.com https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2019-05-16T06:28:58Z,Xiphoseer,hi@dseiler.eu https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2019-06-09T13:34:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2019-06-20T08:44:29Z,lucab,lucab@lucabruno.net https://github.com/rust-lang/rust/pull/60732,MERGED,2019-05-11T12:58:37Z,2019-06-25T18:05:06Z,Implement arbitrary_enum_discriminant,jswrenn,ac98342e846e79985f0c4969a2d546dee24a70d1,18,Implement arbitrary_enum_discriminant,HOORAY,2020-10-29T09:14:22Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-05-12T04:59:22Z,nnethercote,NA https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-05-13T12:48:47Z,mati865,NA https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-05-23T02:55:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-05-23T09:55:33Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-05-29T23:04:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/60740,MERGED,2019-05-11T16:31:46Z,2019-05-23T04:48:39Z,Simplify use of keyword symbols,petrochenkov,a1885cdba38a63448ceec02f951ddc0844d0ff38,13,Restore the old behavior of the rustdoc keyword check + Fix rebase,HEART,2019-06-15T18:13:28Z,chansuke,moonset20@gmail.com https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-13T01:15:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-14T12:53:57Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-22T14:13:56Z,est31,NA https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-26T20:37:08Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-27T13:13:34Z,mati865,NA https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-27T13:32:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/60742,MERGED,2019-05-11T17:03:12Z,2019-05-29T01:52:50Z,Allow const parameters in array sizes to be unified,varkor,6233d1fee5df70258b02bb549967bc9319014081,2,Use assert_eq! instead of println! in tests,ROCKET,2019-05-27T19:34:29Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/60750,MERGED,2019-05-11T23:19:47Z,2019-05-12T23:15:59Z,syntax: Remove some legacy nonterminal tokens,petrochenkov,14b353820f94d8613a678be73ce96cf646038bf4,4,syntax: Remove some legacy nonterminal tokens,HEART,2019-05-12T01:10:06Z,panaman67,NA https://github.com/rust-lang/rust/pull/60760,MERGED,2019-05-12T14:55:25Z,2019-05-19T08:56:52Z,Fix display of const generics in rustdoc,GuillaumeGomez,2caeaf54a1d44b1fe95c3ecaee9daa4ac576fd76,3,Fix display of const generics in rustdoc,THUMBS_UP,2019-05-22T17:50:00Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60771,CLOSED,2019-05-12T22:08:06Z,2019-10-12T05:47:26Z,Remove helper-methods from Alloc trait and add associated Err type.,lachlansneff,NA,NA,NA,HEART,2019-07-12T19:18:56Z,panaman67,NA https://github.com/rust-lang/rust/pull/60772,MERGED,2019-05-12T22:39:16Z,2019-06-20T10:40:27Z,Implement nth_back for slice::{Iter IterMut},timvermeulen,97a6c932e02fcd7f55fdad9aef76c5619f91f481,2,Implement nth_back for slice::{Iter IterMut},HOORAY,2019-06-26T20:00:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T08:46:34Z,mati865,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T09:33:06Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T09:49:19Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T10:59:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T11:02:45Z,ctaggart,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T11:12:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T11:19:29Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T11:23:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HEART,2019-05-13T12:10:21Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T13:59:57Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HEART,2019-05-13T14:00:35Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T14:55:41Z,johnterickson,johnterickson@github.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HEART,2019-05-13T14:55:48Z,johnterickson,johnterickson@github.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T17:28:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HEART,2019-05-13T23:43:42Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-13T23:43:44Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-15T21:02:03Z,lwshang,github@lwshang.com https://github.com/rust-lang/rust/pull/60777,MERGED,2019-05-13T08:20:47Z,2019-05-24T22:14:20Z,Add Azure Pipelines configuration,pietroalbini,2244ca3973fa4a43ef53a16826086e43eae86539,1,ci: fix invalid syntax in the azure auto.yml,HOORAY,2019-05-22T22:51:22Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/60778,CLOSED,2019-05-13T08:21:36Z,2019-09-16T10:34:06Z,[rustdoc] Add sub settings,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2019-05-13T09:26:11Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60787,MERGED,2019-05-13T15:19:13Z,2019-05-14T18:46:12Z,Destabilize the `Error::type_id` function,alexcrichton,3db667a81944c14f0933522560822fc20809c63f,1,add release notes for rust 1.34.2,EYES,2019-05-13T15:36:33Z,crlf0710,NA https://github.com/rust-lang/rust/pull/60791,MERGED,2019-05-13T16:41:27Z,2019-05-17T23:07:20Z,Update books,ehuss,66a3ce78b44faf317c6b3c69fc66b6a75f99743d,8,Update books,THUMBS_UP,2019-05-13T17:26:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60793,MERGED,2019-05-13T18:53:27Z,2019-06-11T02:25:57Z,lexer: Disallow bare CR in raw byte strings,Xanewok,630d5f355fc85fc2c3bab28a278c517d945d328d,6,Don't suggest using \r in raw strings,THUMBS_UP,2019-05-14T08:40:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60796,CLOSED,2019-05-13T20:37:48Z,2019-07-22T17:03:36Z,[WIP] Use `Into::into` in operator `?`,cuviper,NA,NA,NA,THUMBS_UP,2019-05-14T08:42:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60796,CLOSED,2019-05-13T20:37:48Z,2019-07-22T17:03:36Z,[WIP] Use `Into::into` in operator `?`,cuviper,NA,NA,NA,HEART,2019-08-06T07:02:57Z,scottmcm,NA https://github.com/rust-lang/rust/pull/60799,MERGED,2019-05-13T21:01:34Z,2019-05-14T23:56:31Z,Allow late-bound regions in existential types,matthewjasper,36fd00e81cd4af2c83839f0c0b96dc20663710c5,2,Allow late bound regions in existential types,THUMBS_UP,2019-05-15T19:26:27Z,tmandry,NA https://github.com/rust-lang/rust/pull/60803,MERGED,2019-05-13T21:29:48Z,2019-05-24T12:52:09Z,Remove `ObsoleteInPlace`,varkor,36f654262d05a65c41efdbac0ddeffa9bac8ae21,6,Update tests,HEART,2019-05-13T21:54:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/60803,MERGED,2019-05-13T21:29:48Z,2019-05-24T12:52:09Z,Remove `ObsoleteInPlace`,varkor,36f654262d05a65c41efdbac0ddeffa9bac8ae21,6,Update tests,HEART,2019-05-13T23:19:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60803,MERGED,2019-05-13T21:29:48Z,2019-05-24T12:52:09Z,Remove `ObsoleteInPlace`,varkor,36f654262d05a65c41efdbac0ddeffa9bac8ae21,6,Update tests,THUMBS_UP,2019-05-14T08:43:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60803,MERGED,2019-05-13T21:29:48Z,2019-05-24T12:52:09Z,Remove `ObsoleteInPlace`,varkor,36f654262d05a65c41efdbac0ddeffa9bac8ae21,6,Update tests,HEART,2019-05-14T09:26:29Z,tesuji,NA https://github.com/rust-lang/rust/pull/60815,MERGED,2019-05-14T06:36:27Z,2019-05-20T06:33:17Z,Use `Symbol` even more,nnethercote,c06cdbeac55ec87181d015d2ef759349521773ea,4,Introduce `LocalInternedString::intern`. `LocalInternedString::intern(x)` is preferable to `Symbol::intern(x).as_str()` because the former involves one call to `with_interner` while the latter involves two.,THUMBS_UP,2019-05-14T08:47:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60815,MERGED,2019-05-14T06:36:27Z,2019-05-20T06:33:17Z,Use `Symbol` even more,nnethercote,c06cdbeac55ec87181d015d2ef759349521773ea,4,Introduce `LocalInternedString::intern`. `LocalInternedString::intern(x)` is preferable to `Symbol::intern(x).as_str()` because the former involves one call to `with_interner` while the latter involves two.,THUMBS_UP,2019-05-14T09:41:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/60815,MERGED,2019-05-14T06:36:27Z,2019-05-20T06:33:17Z,Use `Symbol` even more,nnethercote,c06cdbeac55ec87181d015d2ef759349521773ea,4,Introduce `LocalInternedString::intern`. `LocalInternedString::intern(x)` is preferable to `Symbol::intern(x).as_str()` because the former involves one call to `with_interner` while the latter involves two.,THUMBS_UP,2019-05-14T14:58:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/60815,MERGED,2019-05-14T06:36:27Z,2019-05-20T06:33:17Z,Use `Symbol` even more,nnethercote,c06cdbeac55ec87181d015d2ef759349521773ea,4,Introduce `LocalInternedString::intern`. `LocalInternedString::intern(x)` is preferable to `Symbol::intern(x).as_str()` because the former involves one call to `with_interner` while the latter involves two.,THUMBS_UP,2019-05-29T13:27:44Z,Jaak,jaak.ra@gmail.com https://github.com/rust-lang/rust/pull/60815,MERGED,2019-05-14T06:36:27Z,2019-05-20T06:33:17Z,Use `Symbol` even more,nnethercote,c06cdbeac55ec87181d015d2ef759349521773ea,4,Introduce `LocalInternedString::intern`. `LocalInternedString::intern(x)` is preferable to `Symbol::intern(x).as_str()` because the former involves one call to `with_interner` while the latter involves two.,THUMBS_UP,2019-05-30T05:39:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-05-14T15:51:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-05-14T18:06:23Z,estebank,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-05-14T18:10:47Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-05-16T13:19:12Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HEART,2019-05-16T13:19:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,ROCKET,2019-05-16T13:19:22Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-06-03T20:54:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-06-12T07:53:12Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-06-20T22:45:56Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-08-01T19:36:55Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HEART,2019-08-01T19:36:57Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,ROCKET,2019-08-01T19:36:58Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-08-27T10:11:27Z,mati865,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-09-28T03:37:22Z,cynecx,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HEART,2019-11-20T13:17:05Z,joemphilips,joemphilips@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-11-20T13:17:09Z,joemphilips,joemphilips@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2019-11-22T16:08:56Z,DianaNites,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2020-01-27T03:10:52Z,kpp,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2020-02-25T13:48:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2020-03-10T16:05:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2020-03-31T18:52:40Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2020-12-25T09:06:23Z,sunqi1993,NA https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HOORAY,2021-08-16T21:14:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,HEART,2021-08-16T21:14:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60826,CLOSED,2019-05-14T13:43:05Z,2020-05-05T09:46:52Z,Implement new gdb/lldb pretty-printers,ortem,NA,NA,NA,ROCKET,2021-08-16T21:14:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60832,MERGED,2019-05-14T18:41:33Z,2019-05-15T15:00:38Z,CMake: Do not print installation messages for up-to-date files,petrochenkov,3646b3c3d9f60c0632668943ca65beb259d035f9,1,rustbuild/LLVM: Do not print installation messages for up-to-date files,THUMBS_UP,2021-09-20T02:53:58Z,evandrocoan,evandrocoan@hotmail.com https://github.com/rust-lang/rust/pull/60839,MERGED,2019-05-14T20:57:34Z,2019-05-30T14:55:55Z,Fix ICE with struct ctors and const generics.,davidtwco,41aaf7bc468759b4775b28fc039ff07c538d4ccb,6,Fix ICE with struct ctors and const generics. This commit fixes a ICE where struct constructors were resulting in an ICE with const generics. Previously a `match` in `type_of` did not have an arm for the `DefKind::Ctor` resolutions and therefore would assume that the type did not have generics.,HEART,2019-05-14T23:24:30Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/60839,MERGED,2019-05-14T20:57:34Z,2019-05-30T14:55:55Z,Fix ICE with struct ctors and const generics.,davidtwco,41aaf7bc468759b4775b28fc039ff07c538d4ccb,6,Fix ICE with struct ctors and const generics. This commit fixes a ICE where struct constructors were resulting in an ICE with const generics. Previously a `match` in `type_of` did not have an arm for the `DefKind::Ctor` resolutions and therefore would assume that the type did not have generics.,HEART,2019-10-19T14:30:30Z,varkor,NA https://github.com/rust-lang/rust/pull/60850,MERGED,2019-05-15T09:56:47Z,2019-05-30T14:55:56Z,Stabilize RefCell::try_borrow_unguarded,SimonSapin,9fd4d48b5e12494926041bb1a053d5891e661bc4,2,Stabilize RefCell::try_borrow_unguarded Servo has been using this since https://github.com/servo/servo/pull/23196 to add a runtime check to some unsafe code as discussed in PR https://github.com/rust-lang/rust/pull/59211. Stabilizing would help do more of the same in libraries that also have users on Stable.,THUMBS_UP,2019-05-15T13:22:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T14:51:16Z,crlf0710,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T15:30:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T15:34:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T16:11:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T16:24:22Z,mati865,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T18:30:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-15T18:42:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-16T05:21:59Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-16T17:04:10Z,ljedrz,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-17T12:05:07Z,CryZe,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-23T03:02:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-23T22:57:09Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-26T04:03:26Z,estebank,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-27T09:27:11Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-30T12:38:36Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-05-31T09:21:28Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-06-01T12:03:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-06-04T17:42:33Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-09-01T07:29:43Z,archseer,NA https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2019-09-26T13:37:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/60852,MERGED,2019-05-15T14:41:38Z,2019-05-26T06:09:33Z,std: Depend on `backtrace` crate from crates.io,alexcrichton,d1040fe329a8db99ae0aae47975830a0829d7792,35,std: Depend on `backtrace` crate from crates.io This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature however uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well but I figured I'd hold off on that until we get closer to merging.,HOORAY,2020-11-09T00:10:14Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-05-16T15:14:05Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-05-16T17:37:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-05-16T21:03:50Z,sfleischman105,sfleischman105@gmail.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-05-17T17:14:18Z,estebank,NA https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,HOORAY,2019-05-18T01:47:51Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,HOORAY,2019-05-28T10:57:25Z,mati865,NA https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-06-06T15:59:32Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,HOORAY,2019-06-06T15:59:32Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,HOORAY,2019-06-21T18:55:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-06-21T18:55:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/60861,MERGED,2019-05-15T19:15:22Z,2019-06-23T15:14:21Z,[let_chains 2/6] Introduce `Let(..)` in AST remove IfLet + WhileLet and parse let chains,Centril,c75f7ecaee508c568c0bc01c102965ce8b2246ef,1,let_chains: note re. back-compat wrt. expr beginning.,THUMBS_UP,2019-06-26T23:04:53Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/60873,MERGED,2019-05-16T02:48:09Z,2019-05-17T03:52:19Z,Parse alternative incorrect uses of await and recover,estebank,c084d0ed7d1dcad99d523cb82d7fc78c6d76a8c6,1,review comments,HOORAY,2019-05-16T13:12:48Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60873,MERGED,2019-05-16T02:48:09Z,2019-05-17T03:52:19Z,Parse alternative incorrect uses of await and recover,estebank,c084d0ed7d1dcad99d523cb82d7fc78c6d76a8c6,1,review comments,HOORAY,2019-05-16T21:24:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60873,MERGED,2019-05-16T02:48:09Z,2019-05-17T03:52:19Z,Parse alternative incorrect uses of await and recover,estebank,c084d0ed7d1dcad99d523cb82d7fc78c6d76a8c6,1,review comments,HOORAY,2019-05-20T20:34:12Z,maxdeviant,NA https://github.com/rust-lang/rust/pull/60873,MERGED,2019-05-16T02:48:09Z,2019-05-17T03:52:19Z,Parse alternative incorrect uses of await and recover,estebank,c084d0ed7d1dcad99d523cb82d7fc78c6d76a8c6,1,review comments,HOORAY,2019-05-27T06:01:27Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/60874,MERGED,2019-05-16T05:28:57Z,2019-05-16T21:55:25Z,Update cargo,ehuss,6a09cfab0bf1770dfa4819f422e6bb9381c7d2e1,3,Update cargo,HOORAY,2019-05-16T17:02:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60874,MERGED,2019-05-16T05:28:57Z,2019-05-16T21:55:25Z,Update cargo,ehuss,6a09cfab0bf1770dfa4819f422e6bb9381c7d2e1,3,Update cargo,HOORAY,2019-05-18T09:46:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60891,MERGED,2019-05-16T20:26:24Z,2019-05-17T23:07:24Z,Allow claiming issues with triagebot,jonas-schievink,441ecb88e791cd156f1753a44c70d79f40315326,1,Allow claiming issues with triagebot,HOORAY,2019-05-16T20:38:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60897,MERGED,2019-05-17T00:11:38Z,2019-06-01T03:46:29Z,error: remove StringError from Debug output,seanmonstar,d2d89b10de394b4a1d5e2491dfffd3d65d1741b3,1,"error: remove StringError from Debug output Seeing `StringError(""something something"")` in debug output can cause someone to think there was an error dealing with `String`s not that the error type is just a string. So remove that noise.",THUMBS_UP,2019-05-17T00:37:05Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60897,MERGED,2019-05-17T00:11:38Z,2019-06-01T03:46:29Z,error: remove StringError from Debug output,seanmonstar,d2d89b10de394b4a1d5e2491dfffd3d65d1741b3,1,"error: remove StringError from Debug output Seeing `StringError(""something something"")` in debug output can cause someone to think there was an error dealing with `String`s not that the error type is just a string. So remove that noise.",THUMBS_UP,2019-05-17T06:38:35Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60897,MERGED,2019-05-17T00:11:38Z,2019-06-01T03:46:29Z,error: remove StringError from Debug output,seanmonstar,d2d89b10de394b4a1d5e2491dfffd3d65d1741b3,1,"error: remove StringError from Debug output Seeing `StringError(""something something"")` in debug output can cause someone to think there was an error dealing with `String`s not that the error type is just a string. So remove that noise.",THUMBS_UP,2019-05-18T22:57:16Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60897,MERGED,2019-05-17T00:11:38Z,2019-06-01T03:46:29Z,error: remove StringError from Debug output,seanmonstar,d2d89b10de394b4a1d5e2491dfffd3d65d1741b3,1,"error: remove StringError from Debug output Seeing `StringError(""something something"")` in debug output can cause someone to think there was an error dealing with `String`s not that the error type is just a string. So remove that noise.",THUMBS_UP,2019-06-01T04:10:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-05-17T22:56:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-05-20T17:23:44Z,cramertj,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-07-01T17:12:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-07-08T12:46:37Z,gawen,g@wenarab.com https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-10-07T21:22:32Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-10-23T22:46:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-11-23T09:44:36Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2019-11-23T17:00:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-01-03T13:35:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-01-28T08:48:24Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-02-23T23:02:49Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-03-06T00:59:31Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-03-13T09:06:30Z,Boscop,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-03-13T14:15:44Z,cynecx,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-03-18T11:35:08Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-03-19T21:04:52Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-05-06T07:23:13Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-05-12T02:16:03Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2020-08-03T05:53:04Z,vorner,vorner+github@vorner.cz https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2021-01-29T17:54:00Z,Kiiyya,NA https://github.com/rust-lang/rust/pull/60900,CLOSED,2019-05-17T01:35:45Z,2020-05-18T15:50:31Z,Trait upcasting,alexreg,NA,NA,NA,THUMBS_UP,2021-06-13T15:05:43Z,TOETOE55,NA https://github.com/rust-lang/rust/pull/60903,MERGED,2019-05-17T04:51:05Z,2019-05-21T09:39:42Z,Move gensym operations from `Symbol` to `Ident`,nnethercote,88d29992bdd3d881b336b724675c59323e70e2e7,8,Remove `Symbol::gensym()`.,ROCKET,2019-05-17T07:44:22Z,mati865,NA https://github.com/rust-lang/rust/pull/60904,CLOSED,2019-05-17T06:14:48Z,2019-07-03T14:46:40Z,libstd: use block buffering when stdout is not a TTY,Arcterus,NA,NA,NA,HEART,2019-05-17T20:28:18Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/60904,CLOSED,2019-05-17T06:14:48Z,2019-07-03T14:46:40Z,libstd: use block buffering when stdout is not a TTY,Arcterus,NA,NA,NA,HEART,2019-05-17T23:03:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60907,CLOSED,2019-05-17T08:28:50Z,2019-05-18T21:02:35Z,Change clippy's symbol interning strategy to be reentrant,oli-obk,NA,NA,NA,HEART,2019-05-17T11:57:16Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/60907,CLOSED,2019-05-17T08:28:50Z,2019-05-18T21:02:35Z,Change clippy's symbol interning strategy to be reentrant,oli-obk,NA,NA,NA,HEART,2019-05-17T13:08:18Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60907,CLOSED,2019-05-17T08:28:50Z,2019-05-18T21:02:35Z,Change clippy's symbol interning strategy to be reentrant,oli-obk,NA,NA,NA,HEART,2019-05-17T20:02:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60907,CLOSED,2019-05-17T08:28:50Z,2019-05-18T21:02:35Z,Change clippy's symbol interning strategy to be reentrant,oli-obk,NA,NA,NA,HEART,2019-05-17T23:06:03Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60911,CLOSED,2019-05-17T11:02:07Z,2019-05-23T06:48:13Z,[DO NOT MERGE] NLL crater run 1: switch default borrowck mode from migrate to full NLLs,lqd,NA,NA,NA,HEART,2019-05-17T19:56:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60914,CLOSED,2019-05-17T12:23:24Z,2019-07-26T17:43:48Z,[DO NOT MERGE] NLL crater run 2: deny NLL warning lints in migrate mode,lqd,NA,NA,NA,HEART,2019-05-17T19:56:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HEART,2019-05-17T18:58:36Z,cramertj,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-17T18:58:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,ROCKET,2019-05-17T18:58:40Z,cramertj,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2019-05-17T18:58:46Z,cramertj,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-17T19:01:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-17T22:02:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-18T00:18:35Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2019-05-18T04:13:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-18T04:13:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HEART,2019-05-18T04:13:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,ROCKET,2019-05-18T04:13:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2019-05-20T11:26:22Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-20T11:26:26Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HEART,2019-05-20T11:26:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,ROCKET,2019-05-20T11:26:33Z,taiki-e,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2019-05-23T02:40:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2019-05-23T04:28:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2019-05-24T19:38:28Z,Havvy,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,THUMBS_UP,2021-09-13T14:21:28Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HOORAY,2021-09-13T14:21:29Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,HEART,2021-09-13T14:21:30Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/60921,MERGED,2019-05-17T18:57:46Z,2019-05-20T11:22:51Z,Remove the unstable and deprecated mpsc_select,cuviper,f950193d74d13628537a04728eef25cec642e41b,10,Remove the unstable and deprecated mpsc_select This removes macro `select!` and `std::sync::mpsc::{Handle Select}` which were all unstable and have been deprecated since 1.32.,ROCKET,2021-09-13T14:21:32Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/60930,CLOSED,2019-05-18T00:41:56Z,2019-05-18T11:44:54Z,[experiment] How expensive are doc comments?,petrochenkov,NA,NA,NA,THUMBS_UP,2019-05-18T01:40:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60932,MERGED,2019-05-18T06:26:38Z,2019-06-09T07:48:28Z,Support ? Kleene macro operator in 2015,Centril,3ba82f7cd8f74d73ebbdcd45aefc761f518f782d,1,pacify tidy.,THUMBS_UP,2019-05-18T10:22:54Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/60938,MERGED,2019-05-18T14:14:45Z,2019-07-26T02:18:00Z,rustdoc: make #[doc(include)] relative to the containing file,jonas-schievink,218ab4cd7fdf145a0870c582a23ad5fd85cd80e5,2,Update test,THUMBS_UP,2019-05-20T02:39:35Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/60938,MERGED,2019-05-18T14:14:45Z,2019-07-26T02:18:00Z,rustdoc: make #[doc(include)] relative to the containing file,jonas-schievink,218ab4cd7fdf145a0870c582a23ad5fd85cd80e5,2,Update test,THUMBS_UP,2019-07-31T19:37:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/60944,CLOSED,2019-05-18T18:36:54Z,2019-05-26T06:00:42Z,Allow lifetime elision in arbitrary_self_types,taiki-e,NA,NA,NA,HEART,2019-05-20T08:08:24Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/60945,MERGED,2019-05-18T19:37:38Z,2019-05-19T04:50:08Z,Simplify BufRead::fill_buf doc example using NLL,blkerby,01cf36ebde50521993a61013487059be5f568c19,1,Simplify BufRead doc example using NLL,HEART,2019-05-18T21:43:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,HOORAY,2019-05-19T12:05:14Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,HOORAY,2019-05-19T13:56:02Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,HOORAY,2019-05-20T02:32:10Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,HOORAY,2019-05-20T02:47:28Z,estebank,NA https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,HOORAY,2019-05-20T05:20:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,THUMBS_UP,2019-05-20T08:18:19Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/60959,MERGED,2019-05-19T11:10:32Z,2019-05-21T00:34:08Z,rustc: Improve type size assertions,petrochenkov,88fa5c6a45a533a78c698a22f4b16002a3bc9fc3,12,Improve type size assertions Now they - Tell what the new size is when it changes - Do not require passing an identifier,THUMBS_UP,2019-05-30T05:28:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60960,MERGED,2019-05-19T12:22:10Z,2019-05-20T03:36:50Z,Stop using gensyms in HIR lowering,matthewjasper,6bb3980e7a7b6ecf891e2309cc858fe167d1a651,2,Stop using gensyms in HIR lowering These names aren't ever handled by resolve so there's no reason to make them gensyms.,HOORAY,2019-05-19T13:12:51Z,mati865,NA https://github.com/rust-lang/rust/pull/60960,MERGED,2019-05-19T12:22:10Z,2019-05-20T03:36:50Z,Stop using gensyms in HIR lowering,matthewjasper,6bb3980e7a7b6ecf891e2309cc858fe167d1a651,2,Stop using gensyms in HIR lowering These names aren't ever handled by resolve so there's no reason to make them gensyms.,HOORAY,2019-05-19T15:00:44Z,oli-obk,NA https://github.com/rust-lang/rust/pull/60960,MERGED,2019-05-19T12:22:10Z,2019-05-20T03:36:50Z,Stop using gensyms in HIR lowering,matthewjasper,6bb3980e7a7b6ecf891e2309cc858fe167d1a651,2,Stop using gensyms in HIR lowering These names aren't ever handled by resolve so there's no reason to make them gensyms.,HOORAY,2019-05-19T21:10:27Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/60960,MERGED,2019-05-19T12:22:10Z,2019-05-20T03:36:50Z,Stop using gensyms in HIR lowering,matthewjasper,6bb3980e7a7b6ecf891e2309cc858fe167d1a651,2,Stop using gensyms in HIR lowering These names aren't ever handled by resolve so there's no reason to make them gensyms.,HEART,2019-05-20T04:09:20Z,nnethercote,NA https://github.com/rust-lang/rust/pull/60960,MERGED,2019-05-19T12:22:10Z,2019-05-20T03:36:50Z,Stop using gensyms in HIR lowering,matthewjasper,6bb3980e7a7b6ecf891e2309cc858fe167d1a651,2,Stop using gensyms in HIR lowering These names aren't ever handled by resolve so there's no reason to make them gensyms.,HOORAY,2019-05-23T04:18:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60965,MERGED,2019-05-19T17:43:40Z,2019-05-23T16:16:21Z,syntax: Continue refactoring literals,petrochenkov,90d15e770419fb4ae8e120909baafc35ef243947,9,syntax: Some code cleanup,HEART,2019-05-20T05:19:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/60965,MERGED,2019-05-19T17:43:40Z,2019-05-23T16:16:21Z,syntax: Continue refactoring literals,petrochenkov,90d15e770419fb4ae8e120909baafc35ef243947,9,syntax: Some code cleanup,HEART,2019-05-21T17:08:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/60965,MERGED,2019-05-19T17:43:40Z,2019-05-23T16:16:21Z,syntax: Continue refactoring literals,petrochenkov,90d15e770419fb4ae8e120909baafc35ef243947,9,syntax: Some code cleanup,HEART,2019-05-23T18:48:03Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60966,MERGED,2019-05-19T18:17:26Z,2019-08-30T06:49:20Z,"Add a ""diagnostic item"" scheme for lints referring to libstd items",oli-obk,6978b9482b976d991dac1dc55a6effe1f697cd1f,2,Update tests,HOORAY,2019-05-23T06:42:19Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/60966,MERGED,2019-05-19T18:17:26Z,2019-08-30T06:49:20Z,"Add a ""diagnostic item"" scheme for lints referring to libstd items",oli-obk,6978b9482b976d991dac1dc55a6effe1f697cd1f,2,Update tests,HOORAY,2019-05-25T18:05:45Z,estebank,NA https://github.com/rust-lang/rust/pull/60966,MERGED,2019-05-19T18:17:26Z,2019-08-30T06:49:20Z,"Add a ""diagnostic item"" scheme for lints referring to libstd items",oli-obk,6978b9482b976d991dac1dc55a6effe1f697cd1f,2,Update tests,HOORAY,2019-05-27T19:44:19Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/60966,MERGED,2019-05-19T18:17:26Z,2019-08-30T06:49:20Z,"Add a ""diagnostic item"" scheme for lints referring to libstd items",oli-obk,6978b9482b976d991dac1dc55a6effe1f697cd1f,2,Update tests,HOORAY,2019-08-30T07:11:27Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/60967,MERGED,2019-05-19T19:17:23Z,2019-05-27T12:46:31Z,Short circuit Send and Sync impls for TokenTree,Zoxc,3ed05613eeadd6baf332f6d4021c1973cb37ac21,1,Short circuit Send and Sync impls for TokenTree,THUMBS_UP,2019-06-06T05:41:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,HEART,2019-05-21T06:34:22Z,retep998,NA https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,HOORAY,2019-05-21T06:34:26Z,retep998,NA https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,ROCKET,2019-05-21T06:34:29Z,retep998,NA https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,ROCKET,2019-05-21T06:37:20Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,HEART,2019-05-21T06:56:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60971,MERGED,2019-05-20T02:31:24Z,2019-06-22T05:06:35Z,Add DocFS layer to rustdoc,rbtcollins,65f12950b64cbea42e97f1425952c77cf024d5ed,2,Better handling of the sender channel part in rustdoc file writing,HOORAY,2019-05-21T06:56:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/60972,MERGED,2019-05-20T07:53:44Z,2019-05-21T00:34:10Z,remove confusing remarks about mixed volatile and non-volatile accesses,RalfJung,b9be68ce2ed75a3801075f66f50200e329211400,1,remove confusing remarks about mixed volatile and non-volatile accesses,HEART,2019-05-21T16:48:28Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/60998,MERGED,2019-05-21T07:10:55Z,2019-05-22T04:42:29Z,static_assert: make use of anonymous constants,RalfJung,a2168b0259f67ca478255239cdde9b76603b08c8,1,update doc comment,HEART,2019-05-21T07:54:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/61020,MERGED,2019-05-21T21:53:17Z,2019-06-22T17:59:20Z,librustc_data_structures: Speedup union of sparse and dense hybrid set ,HeroicKatora,3f28811774da8ee16bd6391a0e66d23e6962485f,1,Add documentation on the reasoning Explains the thought process behind adding the union algorithm and discusses the alternative and heuristic behind.,THUMBS_UP,2019-05-22T00:20:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61020,MERGED,2019-05-21T21:53:17Z,2019-06-22T17:59:20Z,librustc_data_structures: Speedup union of sparse and dense hybrid set ,HeroicKatora,3f28811774da8ee16bd6391a0e66d23e6962485f,1,Add documentation on the reasoning Explains the thought process behind adding the union algorithm and discusses the alternative and heuristic behind.,THUMBS_UP,2019-06-27T11:35:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61034,MERGED,2019-05-22T09:20:27Z,2019-05-23T01:51:22Z,rustc_metadata: parametrize schema::CrateRoot by 'tcx and rip out old unused incremental infra.,eddyb,7327768a75621df3f4cec4229a0812eceb7c5adb,6,rustc_metadata: rip out unused incremental infrastructure.,HEART,2019-05-22T18:10:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/61041,CLOSED,2019-05-22T13:57:45Z,2019-08-20T12:13:43Z,Fix an ICE encountered in clippy that will be possible to trigger in rustc in the future,oli-obk,NA,NA,NA,HEART,2019-05-22T14:14:28Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61041,CLOSED,2019-05-22T13:57:45Z,2019-08-20T12:13:43Z,Fix an ICE encountered in clippy that will be possible to trigger in rustc in the future,oli-obk,NA,NA,NA,THUMBS_UP,2019-06-14T11:52:11Z,jmcomets,NA https://github.com/rust-lang/rust/pull/61052,MERGED,2019-05-22T19:09:31Z,2019-06-11T05:25:01Z,Emit save analysis notifications,jsgf,7a22c34be712b5071b7e9db1aecf4e8f8afdeb8b,4,Emit artifact notifications for save-analysis output Issue: https://github.com/rust-lang/rust/issues/61047,THUMBS_UP,2019-05-28T09:54:18Z,bjorn3,NA https://github.com/rust-lang/rust/pull/61054,MERGED,2019-05-22T20:10:58Z,2019-05-24T03:07:17Z,Suggest dereferencing on assignment to mutable borrow,estebank,7fbbcfaafd08023cc2296481425e16a02ccd3f1a,2,Add regression test for negative case,HEART,2019-05-22T20:21:22Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61054,MERGED,2019-05-22T20:10:58Z,2019-05-24T03:07:17Z,Suggest dereferencing on assignment to mutable borrow,estebank,7fbbcfaafd08023cc2296481425e16a02ccd3f1a,2,Add regression test for negative case,HEART,2019-05-23T03:06:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61054,MERGED,2019-05-22T20:10:58Z,2019-05-24T03:07:17Z,Suggest dereferencing on assignment to mutable borrow,estebank,7fbbcfaafd08023cc2296481425e16a02ccd3f1a,2,Add regression test for negative case,HEART,2019-05-23T03:41:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61056,MERGED,2019-05-22T21:00:39Z,2019-05-24T03:07:18Z,tweak discriminant on non-nullary enum diagnostic,euclio,3cbf5864a6b7088eb28da30b9ccf61ba8d90054f,6,"tweak discriminant on non-nullary enum diagnostic Adds notes pointing at the non-nullary variants and uses ""custom discriminant"" language to be consistent with the Reference.",HEART,2019-05-22T21:01:36Z,estebank,NA https://github.com/rust-lang/rust/pull/61062,MERGED,2019-05-23T00:37:05Z,2019-06-03T11:11:08Z,Remove _all_ codegen dependencies on `rustc_mir` :tada:,mark-i-m,0f822d775f046df87713edf8ffb4e308fc77b3ef,5,query-fy type_name,HOORAY,2019-05-23T07:40:06Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61062,MERGED,2019-05-23T00:37:05Z,2019-06-03T11:11:08Z,Remove _all_ codegen dependencies on `rustc_mir` :tada:,mark-i-m,0f822d775f046df87713edf8ffb4e308fc77b3ef,5,query-fy type_name,HOORAY,2019-05-23T15:21:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61062,MERGED,2019-05-23T00:37:05Z,2019-06-03T11:11:08Z,Remove _all_ codegen dependencies on `rustc_mir` :tada:,mark-i-m,0f822d775f046df87713edf8ffb4e308fc77b3ef,5,query-fy type_name,HOORAY,2019-05-24T22:36:37Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/61062,MERGED,2019-05-23T00:37:05Z,2019-06-03T11:11:08Z,Remove _all_ codegen dependencies on `rustc_mir` :tada:,mark-i-m,0f822d775f046df87713edf8ffb4e308fc77b3ef,5,query-fy type_name,HOORAY,2019-06-03T05:33:25Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61068,CLOSED,2019-05-23T02:40:12Z,2019-08-30T17:16:47Z,Show the message in case of `should_panic` failure,chansuke,NA,NA,NA,HEART,2019-05-24T16:42:25Z,fbenkstein,NA https://github.com/rust-lang/rust/pull/61078,MERGED,2019-05-23T10:28:37Z,2019-05-28T01:57:13Z,Bump nightly to 1.37.0,pietroalbini,924cdd4532e4b0124f38584a7b886ba0f8516782,3,bump nightly to 1.37.0,HOORAY,2019-05-23T15:10:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61078,MERGED,2019-05-23T10:28:37Z,2019-05-28T01:57:13Z,Bump nightly to 1.37.0,pietroalbini,924cdd4532e4b0124f38584a7b886ba0f8516782,3,bump nightly to 1.37.0,HOORAY,2019-06-01T12:37:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/61080,MERGED,2019-05-23T11:38:12Z,2019-05-26T12:25:00Z,Ship profiler with windows-gnu,mati865,1a35a1c688511bb09a67c1430d55e022ac5f88eb,2,Ship profiler with windows-gnu,THUMBS_UP,2019-05-23T19:06:24Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61113,MERGED,2019-05-24T06:59:59Z,2019-05-25T07:06:10Z,Deprecate `FnBox`. `Box` can be called directly since 1.35,SimonSapin,73fd3497d4cc65c733cc1848bea363c00cb87878,4,Deprecate `FnBox`. `Box` can be called directly since 1.35 FCP completion: https://github.com/rust-lang/rust/issues/28796#issuecomment-439731515,HEART,2019-05-24T14:37:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61113,MERGED,2019-05-24T06:59:59Z,2019-05-25T07:06:10Z,Deprecate `FnBox`. `Box` can be called directly since 1.35,SimonSapin,73fd3497d4cc65c733cc1848bea363c00cb87878,4,Deprecate `FnBox`. `Box` can be called directly since 1.35 FCP completion: https://github.com/rust-lang/rust/issues/28796#issuecomment-439731515,HEART,2019-05-25T13:28:58Z,qnighy,NA https://github.com/rust-lang/rust/pull/61126,CLOSED,2019-05-24T17:08:30Z,2019-10-04T14:33:01Z,[WIP] Enable va_arg for raw pointers to unsized types,ahomescu,NA,NA,NA,THUMBS_UP,2019-10-02T08:18:25Z,XVilka,xvilka@gmail.com https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",HOORAY,2019-05-29T15:20:02Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",CONFUSED,2019-05-31T04:57:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",THUMBS_UP,2019-06-05T18:06:34Z,delacian,NA https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",THUMBS_UP,2019-06-08T21:06:45Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",THUMBS_UP,2019-06-10T23:28:47Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/61130,MERGED,2019-05-24T17:55:12Z,2019-06-07T21:16:36Z,Add std::mem::take as suggested in #61129,jonhoo,5a01b547078e45cc1a96a062334d8571f129ddc2,1,"Add std::mem::take as suggested in #61129 The name `swap_default` was suggested but rejected. @SimonSapin observed that this operation isn't really a `swap` in the same sense as `mem::swap`; it is a `replace`. Since `replace_default` is a bit misleading the ""correct"" name would be `replace_with_default` which is quite verbose. @czipperz observed that we have precedence for using `take` to refer to methods that replace with `Default` in `Cell::take` and `Option::take` so this reverts commit 99c00591c29b472c8a87c4a9342d0e0c508647a3 to return to the original `take` method name. The name `replace_with_default` was suggested but was deemed too verbose especially given that we use `take` for methods that replace with `Default` elsewhere.",THUMBS_UP,2019-07-01T07:11:35Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/61135,MERGED,2019-05-24T20:30:09Z,2019-06-04T08:32:28Z,Fix documentation of `Rc::make_mut` regarding `rc::Weak`.,czipperz,b34b714a896644c7ac5787b214f4115fc0226d96,1,Remove unused import in doctest,THUMBS_UP,2019-06-04T12:42:20Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/61136,MERGED,2019-05-24T20:31:26Z,2019-06-04T11:14:12Z,Make cannot move errors more consistent with other borrowck errors,matthewjasper,8ffa4080597231c49fabf63795dae4bf8e116248,100,Update tests for changes to cannot move errors,HEART,2019-05-25T00:59:45Z,cramertj,NA https://github.com/rust-lang/rust/pull/61136,MERGED,2019-05-24T20:31:26Z,2019-06-04T11:14:12Z,Make cannot move errors more consistent with other borrowck errors,matthewjasper,8ffa4080597231c49fabf63795dae4bf8e116248,100,Update tests for changes to cannot move errors,HEART,2019-05-25T01:34:13Z,tmandry,NA https://github.com/rust-lang/rust/pull/61136,MERGED,2019-05-24T20:31:26Z,2019-06-04T11:14:12Z,Make cannot move errors more consistent with other borrowck errors,matthewjasper,8ffa4080597231c49fabf63795dae4bf8e116248,100,Update tests for changes to cannot move errors,HEART,2019-05-25T01:57:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/61136,MERGED,2019-05-24T20:31:26Z,2019-06-04T11:14:12Z,Make cannot move errors more consistent with other borrowck errors,matthewjasper,8ffa4080597231c49fabf63795dae4bf8e116248,100,Update tests for changes to cannot move errors,HEART,2019-05-27T04:10:23Z,estebank,NA https://github.com/rust-lang/rust/pull/61138,MERGED,2019-05-24T21:09:33Z,2019-05-25T07:06:15Z,Move async/await tests to their own folder,varkor,c91ab64048a32861c48d94f31f31b609addfdda7,1,Add extra arc_wake,HEART,2019-05-25T04:01:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61138,MERGED,2019-05-24T21:09:33Z,2019-05-25T07:06:15Z,Move async/await tests to their own folder,varkor,c91ab64048a32861c48d94f31f31b609addfdda7,1,Add extra arc_wake,HEART,2019-05-26T03:45:17Z,estebank,NA https://github.com/rust-lang/rust/pull/61147,MERGED,2019-05-25T02:10:36Z,2019-05-27T03:59:26Z,When encountering move error on an `Option` suggest using `as_ref`,estebank,1cc42ea6750affbef2bca699bde30ac321e15939,4,Add support for suggesting as_ref to Result accesses,HOORAY,2019-06-05T23:28:24Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/61147,MERGED,2019-05-25T02:10:36Z,2019-05-27T03:59:26Z,When encountering move error on an `Option` suggest using `as_ref`,estebank,1cc42ea6750affbef2bca699bde30ac321e15939,4,Add support for suggesting as_ref to Result accesses,HOORAY,2019-06-07T04:25:42Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/61159,MERGED,2019-05-25T07:04:50Z,2019-05-28T20:31:24Z,split core::ptr module into multiple files,RalfJung,c2e7eb6ff0493e89d0fcaf5bd8aa527c2e7c7c26,3,split core::ptr module into multiple files,HOORAY,2019-05-27T07:07:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61159,MERGED,2019-05-25T07:04:50Z,2019-05-28T20:31:24Z,split core::ptr module into multiple files,RalfJung,c2e7eb6ff0493e89d0fcaf5bd8aa527c2e7c7c26,3,split core::ptr module into multiple files,HOORAY,2019-05-27T18:32:14Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/61159,MERGED,2019-05-25T07:04:50Z,2019-05-28T20:31:24Z,split core::ptr module into multiple files,RalfJung,c2e7eb6ff0493e89d0fcaf5bd8aa527c2e7c7c26,3,split core::ptr module into multiple files,HEART,2019-05-27T18:32:16Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/61181,MERGED,2019-05-25T14:40:14Z,2019-06-22T05:06:38Z,Fix theme-checker failure,GuillaumeGomez,640bdbdb1da73cde39c33fc2be3cddd3b71389b0,1,Improve theme checker by removing unneeded conditions,HEART,2019-05-27T09:27:21Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/61181,MERGED,2019-05-25T14:40:14Z,2019-06-22T05:06:38Z,Fix theme-checker failure,GuillaumeGomez,640bdbdb1da73cde39c33fc2be3cddd3b71389b0,1,Improve theme checker by removing unneeded conditions,THUMBS_UP,2019-05-30T21:33:18Z,czipperz,czipperz@gmail.com https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-05-25T19:35:56Z,varkor,NA https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,HOORAY,2019-05-25T20:59:20Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-05-25T22:55:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,HOORAY,2019-05-25T22:55:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-05-26T09:13:38Z,kennytm,NA https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-05-29T13:42:38Z,samoylovfp,NA https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-05-30T05:54:14Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-06-03T15:03:14Z,bash,NA https://github.com/rust-lang/rust/pull/61189,MERGED,2019-05-25T19:18:54Z,2019-05-26T08:58:33Z,Turn turbo 🐟 🍨 into an error,oli-obk,a15df94b69e6b93334819d382479a43e07471071,3,Turn ICE on type arguments on variables into an error,LAUGH,2019-06-03T15:03:53Z,janhohenheim,jan@hohenheim.ch https://github.com/rust-lang/rust/pull/61203,MERGED,2019-05-26T02:44:42Z,2019-05-30T00:39:16Z,Warn on bare_trait_objects by default,memoryruins,83660b62734c4f966c536b60864bb51fac696f6c,2,Update libstd doctests to use dyn,ROCKET,2019-08-05T13:59:51Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/61203,MERGED,2019-05-26T02:44:42Z,2019-05-30T00:39:16Z,Warn on bare_trait_objects by default,memoryruins,83660b62734c4f966c536b60864bb51fac696f6c,2,Update libstd doctests to use dyn,HOORAY,2019-08-13T05:52:43Z,moshg,NA https://github.com/rust-lang/rust/pull/61207,MERGED,2019-05-26T05:30:28Z,2019-07-28T04:56:47Z,Allow lifetime elision in `Pin<&(mut) Self>`,taiki-e,05f67a297a25dc33f2d739dbccc42f44bc6d7ab9,7,arbitrary_self_types lifetime elision: --bless --compare-mode=nll,THUMBS_UP,2019-05-26T14:17:49Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61209,MERGED,2019-05-26T09:48:14Z,2019-06-07T12:30:44Z,Make tuple constructors real const fns,matthewjasper,bcf836567560c2f31dac79aa0379c0f0e2740081,2,Make sure constructors functions are type checked correctly,HEART,2019-05-26T16:11:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/61209,MERGED,2019-05-26T09:48:14Z,2019-06-07T12:30:44Z,Make tuple constructors real const fns,matthewjasper,bcf836567560c2f31dac79aa0379c0f0e2740081,2,Make sure constructors functions are type checked correctly,HEART,2019-05-28T19:14:05Z,cramertj,NA https://github.com/rust-lang/rust/pull/61209,MERGED,2019-05-26T09:48:14Z,2019-06-07T12:30:44Z,Make tuple constructors real const fns,matthewjasper,bcf836567560c2f31dac79aa0379c0f0e2740081,2,Make sure constructors functions are type checked correctly,HEART,2019-06-02T03:00:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61209,MERGED,2019-05-26T09:48:14Z,2019-06-07T12:30:44Z,Make tuple constructors real const fns,matthewjasper,bcf836567560c2f31dac79aa0379c0f0e2740081,2,Make sure constructors functions are type checked correctly,HEART,2019-06-12T16:52:04Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/61209,MERGED,2019-05-26T09:48:14Z,2019-06-07T12:30:44Z,Make tuple constructors real const fns,matthewjasper,bcf836567560c2f31dac79aa0379c0f0e2740081,2,Make sure constructors functions are type checked correctly,HEART,2019-06-15T11:30:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/61213,MERGED,2019-05-26T15:14:59Z,2019-05-26T21:38:39Z,azure: fix multiple checkouts on azure,pietroalbini,4af19b0ce9c438a222e5fc30c91cbc2db3afc37b,1,ci: increase timeout on the auto branch in azure,HOORAY,2019-05-26T15:21:56Z,mati865,NA https://github.com/rust-lang/rust/pull/61223,MERGED,2019-05-27T02:05:06Z,2019-06-08T04:30:12Z,Document tuple's Ord behavior as sequential,czipperz,0fd9934b1e2c523cf32ee2f88450dab9feb65ee4,1,Document tuple's Ord behavior as sequential,HEART,2019-06-01T02:23:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61229,MERGED,2019-05-27T06:18:41Z,2019-06-10T02:35:50Z,Stabilize #![feature(repr_align_enum)] in Rust 1.37.0,Centril,c25e3d2be5825463cf63c518854b583fbc9e8386,2,Harden tests for repr_align_enum.,ROCKET,2019-05-27T19:33:18Z,Dentrax,furkan.turkal@hotmail.com https://github.com/rust-lang/rust/pull/61229,MERGED,2019-05-27T06:18:41Z,2019-06-10T02:35:50Z,Stabilize #![feature(repr_align_enum)] in Rust 1.37.0,Centril,c25e3d2be5825463cf63c518854b583fbc9e8386,2,Harden tests for repr_align_enum.,ROCKET,2019-06-07T19:28:59Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/61244,MERGED,2019-05-27T20:43:49Z,2019-05-30T14:56:07Z,Box::into_vec: use Box::into_raw instead of mem::forget,RalfJung,645f685e1b05f3f62de26ea1579861e83cbd0d74,1,Box::into_vec: use Box::into_raw instead of mem::forget,THUMBS_UP,2022-07-04T22:41:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61246,MERGED,2019-05-27T20:50:16Z,2019-05-28T17:38:31Z,Update clippy submodule,oli-obk,a1da365eb31c2aaf1a53d9d3b8e2dfec846637fb,1,Update clippy submodule,HEART,2019-05-27T22:10:42Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/61253,MERGED,2019-05-28T02:17:42Z,2019-05-30T19:51:08Z,Avoid `hygiene_data` lookups,nnethercote,95ea7fd735619089ea9a0e95e2f41170127df567,1,Add `HygieneData::{outer expn_info is_descendant_of}` methods. This commit factors out some repeated code.,THUMBS_UP,2019-05-28T12:42:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/61255,CLOSED,2019-05-28T06:51:26Z,2019-08-07T12:25:03Z,Improve raw string diagnostic,hellow554,NA,NA,NA,HEART,2019-05-28T07:20:47Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/61255,CLOSED,2019-05-28T06:51:26Z,2019-08-07T12:25:03Z,Improve raw string diagnostic,hellow554,NA,NA,NA,HEART,2019-05-28T16:36:13Z,estebank,NA https://github.com/rust-lang/rust/pull/61255,CLOSED,2019-05-28T06:51:26Z,2019-08-07T12:25:03Z,Improve raw string diagnostic,hellow554,NA,NA,NA,HEART,2019-07-15T14:49:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/61259,MERGED,2019-05-28T10:54:47Z,2019-05-29T01:53:07Z,Mailmap fixes,JosephTLyons,b0c3385a6348d8ed3ed71d95b643c9ec041cc5e3,1,Alphabetized lines with Atom's Sort Lines package https://github.com/atom/sort-lines,HEART,2019-05-28T12:12:13Z,carols10cents,NA https://github.com/rust-lang/rust/pull/61263,MERGED,2019-05-28T13:47:14Z,2019-06-01T09:27:58Z,Don't generate div inside header (h4/h3/h...) elements,GuillaumeGomez,35091620e6726b1f6262a2a3ae4575833fd994a9,2,Don't generate div inside header (h4/h3/h...) elements,HEART,2019-06-02T06:54:32Z,kentfredric,kentfredric@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-05-28T15:21:40Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-05-28T20:06:18Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-05-28T20:13:47Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-05-29T01:39:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-05-29T08:07:45Z,mati865,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-05-29T09:59:39Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-05-29T16:25:20Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-03T23:06:21Z,lqd,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-06-05T17:00:42Z,chrish42,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-06T01:50:47Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-07T08:51:53Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-06-07T08:51:54Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-12T14:13:00Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-06-12T14:13:03Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-12T14:23:01Z,bgourlie,bgourlie@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-06-12T14:43:00Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-12T18:06:26Z,mforsb,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-06-16T11:23:19Z,Cogitri,oss@cogitri.dev https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-28T00:06:58Z,youjiali1995,zlwgx1023@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-06-30T20:38:06Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-06-30T20:38:07Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T08:15:28Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T09:15:15Z,rafalopilowski1,me@justsomebody.dev https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T10:50:46Z,aheart,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T11:16:13Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T11:16:14Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-03T11:16:17Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T12:03:52Z,gentoid,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T12:16:04Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-03T12:16:09Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T12:32:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T12:32:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T12:38:28Z,Aloxaf,bailong104@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T13:19:43Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T13:57:39Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T13:57:40Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-03T13:57:48Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T15:05:58Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T15:28:40Z,jonringer,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T16:09:49Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T16:28:59Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T16:29:01Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-03T16:29:04Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-03T16:29:33Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T19:28:00Z,qrilka,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-03T23:58:50Z,tmandry,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-04T01:39:56Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-04T05:19:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-04T05:37:43Z,frol,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-04T05:37:47Z,frol,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-04T14:14:03Z,kpp,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-05T08:03:35Z,mxinden,mail@max-inden.de https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-08T21:39:13Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-10T13:40:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-10T14:12:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-10T20:41:24Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-12T16:05:54Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-07-12T16:05:54Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-12T16:05:57Z,pdavydov108,pdavydov108@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,ROCKET,2019-07-15T23:58:55Z,moshg,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-07-15T23:59:43Z,moshg,NA https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-08-07T16:04:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HEART,2019-08-15T17:17:48Z,i80and,heli@heli.pet https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2019-08-22T09:15:46Z,u2,zhangyaning1985@gmail.com https://github.com/rust-lang/rust/pull/61268,MERGED,2019-05-28T15:07:26Z,2019-07-02T23:34:07Z,Stabilize support for Profile-guided Optimization,michaelwoerister,b7fe2ca5e09b8edab393073198f8f55e1a78079f,14,Stabilize profile-guided optimization.,HOORAY,2020-08-27T15:17:41Z,Caduser2020,NA https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HOORAY,2019-05-28T18:01:57Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HOORAY,2019-05-28T19:07:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HEART,2019-05-28T19:39:18Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HOORAY,2019-05-28T20:38:22Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HOORAY,2019-05-28T22:21:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/61276,MERGED,2019-05-28T16:44:06Z,2019-06-02T14:42:35Z,rustc: remove Res::Upvar.,eddyb,f7a4c9d7b55950c6b8451b42f203df2c009fc653,12,rustc: collect upvars from HIR instead of during name resolution.,HEART,2019-05-28T22:21:06Z,panaman67,NA https://github.com/rust-lang/rust/pull/61297,MERGED,2019-05-28T22:48:35Z,2019-05-29T10:39:50Z,Remove LLVM instruction stats and other (obsolete) codegen stats.,eddyb,7fa97c08508057b29142211fc45b3e282f194a7b,1,rustc_codegen_llvm: rename away the last occurrence of `insn`.,HEART,2019-05-29T03:15:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/61297,MERGED,2019-05-28T22:48:35Z,2019-05-29T10:39:50Z,Remove LLVM instruction stats and other (obsolete) codegen stats.,eddyb,7fa97c08508057b29142211fc45b3e282f194a7b,1,rustc_codegen_llvm: rename away the last occurrence of `insn`.,HOORAY,2019-05-29T07:32:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61297,MERGED,2019-05-28T22:48:35Z,2019-05-29T10:39:50Z,Remove LLVM instruction stats and other (obsolete) codegen stats.,eddyb,7fa97c08508057b29142211fc45b3e282f194a7b,1,rustc_codegen_llvm: rename away the last occurrence of `insn`.,HOORAY,2019-05-29T22:15:54Z,mati865,NA https://github.com/rust-lang/rust/pull/61299,MERGED,2019-05-29T01:58:21Z,2019-06-02T04:10:59Z,rustc_codegen_llvm: a couple builder niceties.,eddyb,25d68344932f740c4f4cbbb454ef65f9e33aca59,2,rustc_codegen_llvm: replace `fn noname()` with `const UNNAMED`.,HOORAY,2019-05-29T12:32:06Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61299,MERGED,2019-05-29T01:58:21Z,2019-06-02T04:10:59Z,rustc_codegen_llvm: a couple builder niceties.,eddyb,25d68344932f740c4f4cbbb454ef65f9e33aca59,2,rustc_codegen_llvm: replace `fn noname()` with `const UNNAMED`.,HOORAY,2019-05-29T18:19:06Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,THUMBS_UP,2019-05-29T07:17:25Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,HOORAY,2019-05-29T07:46:39Z,TheSirC,NA https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,THUMBS_UP,2019-05-29T13:55:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,HOORAY,2019-05-29T13:55:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,HOORAY,2019-05-29T13:59:01Z,tschneidereit,till@tillschneidereit.net https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,LAUGH,2019-05-29T14:36:34Z,kennytm,NA https://github.com/rust-lang/rust/pull/61304,MERGED,2019-05-29T06:11:43Z,2019-06-01T03:46:39Z,Speed up Azure CI installing Windows dependencies,lzybkr,6c534c316fd75f04b128116abdde46f4f036b306,868,Merge branch 'master' into iwr_progress,LAUGH,2019-05-29T17:32:18Z,aidanhs,aidanhs@cantab.net https://github.com/rust-lang/rust/pull/61319,MERGED,2019-05-29T15:06:28Z,2019-06-01T03:46:40Z,Swap order of `unsafe async fn` to `async unsafe fn`,Centril,2ebfbb4fabda543f090890a889914df025ccbb77,3,Parse 'async unsafe fn' instead of 'unsafe async fn'.,THUMBS_UP,2019-05-29T18:34:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/61339,MERGED,2019-05-30T03:37:39Z,2019-07-17T16:02:22Z,Optimize pointer alignment in utf8 validation,jridgewell,3b6e8ed502e351d5d8daa3ac0c61a4e44b428d98,1,Do not use pointer alignment on unsupported platforms,THUMBS_UP,2019-05-30T23:40:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61339,MERGED,2019-05-30T03:37:39Z,2019-07-17T16:02:22Z,Optimize pointer alignment in utf8 validation,jridgewell,3b6e8ed502e351d5d8daa3ac0c61a4e44b428d98,1,Do not use pointer alignment on unsupported platforms,THUMBS_UP,2019-07-18T12:09:02Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HEART,2019-06-12T16:20:30Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-06-17T00:41:51Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-06-17T11:25:39Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-06-20T09:50:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-07-16T20:47:11Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-07-30T09:10:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61347,MERGED,2019-05-30T10:31:55Z,2019-06-16T23:25:35Z,Stabilize underscore_const_names in 1.37.0,Centril,e62c9d7917052db098c6f27314f4daa5b9513387,1,Stabilize underscore_const_names: stage0 -> bootstrap.,HOORAY,2019-08-15T14:43:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/61351,MERGED,2019-05-30T11:43:15Z,2019-11-24T01:39:21Z,Stabilize cfg(doc),GuillaumeGomez,0d7a7b554771daee7b08caa8c49544910948c915,3,move cfg(doc) docs into a separate page,THUMBS_UP,2019-11-21T01:41:55Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/61351,MERGED,2019-05-30T11:43:15Z,2019-11-24T01:39:21Z,Stabilize cfg(doc),GuillaumeGomez,0d7a7b554771daee7b08caa8c49544910948c915,3,move cfg(doc) docs into a separate page,THUMBS_UP,2019-11-25T19:34:30Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/61351,MERGED,2019-05-30T11:43:15Z,2019-11-24T01:39:21Z,Stabilize cfg(doc),GuillaumeGomez,0d7a7b554771daee7b08caa8c49544910948c915,3,move cfg(doc) docs into a separate page,HOORAY,2019-11-25T19:34:32Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/61351,MERGED,2019-05-30T11:43:15Z,2019-11-24T01:39:21Z,Stabilize cfg(doc),GuillaumeGomez,0d7a7b554771daee7b08caa8c49544910948c915,3,move cfg(doc) docs into a separate page,HOORAY,2019-12-02T20:26:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61351,MERGED,2019-05-30T11:43:15Z,2019-11-24T01:39:21Z,Stabilize cfg(doc),GuillaumeGomez,0d7a7b554771daee7b08caa8c49544910948c915,3,move cfg(doc) docs into a separate page,HOORAY,2020-01-31T06:43:17Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/61353,MERGED,2019-05-30T14:29:21Z,2019-05-30T22:42:45Z,ci: Favor SCRIPT instead of RUST_CHECK_TARGET,alexcrichton,ebdf42e9650a969bef553a0886d3754a670bd335,8,ci: Favor SCRIPT instead of RUST_CHECK_TARGET Since #61212 we've been timing out on OSX and this looks to be because we're building tools like Cargo and the RLS twice instead of once. This turns out to be a slight bug in our configuration. CI builders using the `RUST_CHECK_TARGET` directive actually execute `make all` just before their acual target. In `make all` we're building a stage2 cargo and then in `make dist` we're building a stage1 cargo. Other builders use `SCRIPT` which provides explicit control over what `x.py` script for example is used to execute the build. This moves almost all targets to using `SCRIPT` to ensure that we're explicitly specifying what's being built where. Additionally this updates the logic of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the pre-flight `make all`. The system LLVM builder (run on PRs) now explicitly runs tidy first and then runs the rest of the test suite.,HEART,2019-05-30T14:36:40Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61361,MERGED,2019-05-30T17:24:54Z,2019-06-03T05:41:09Z,Add more detail to type inference error,estebank,e420f4410ba44b3e39f54c755f456f4f65406e25,6,Account for cases where we can find the type arg name but the local name is `_`,THUMBS_UP,2019-05-30T22:57:41Z,sinkuu,NA https://github.com/rust-lang/rust/pull/61363,MERGED,2019-05-30T18:02:19Z,2019-06-01T03:46:44Z,Stabilize iter_nth_back feature,tesuji,0c35c699d43ba24943bb8f38986f84c4be676dc3,3,Stabilize iter_nth_back feature,HEART,2019-06-01T01:50:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61363,MERGED,2019-05-30T18:02:19Z,2019-06-01T03:46:44Z,Stabilize iter_nth_back feature,tesuji,0c35c699d43ba24943bb8f38986f84c4be676dc3,3,Stabilize iter_nth_back feature,HEART,2019-06-09T22:23:04Z,koalatux,NA https://github.com/rust-lang/rust/pull/61364,MERGED,2019-05-30T18:24:55Z,2019-06-01T09:28:02Z,Stabilize reverse_bits feature,tesuji,1c26bbf6283baefa7d6f598d693c57bcec4c3450,8,Stabilize reverse_bits feature,HEART,2019-06-01T01:50:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61374,MERGED,2019-05-30T20:51:33Z,2019-06-01T03:46:46Z,Explicitly suggest 'type_ascription' feature,VirrageS,4c5eb8ecfc1accda036053d50c8c44b3c5eebb3b,6,Explicitly suggest 'type_ascription' feature,THUMBS_UP,2019-05-30T22:26:27Z,estebank,NA https://github.com/rust-lang/rust/pull/61384,MERGED,2019-05-31T00:18:27Z,2019-06-02T07:13:28Z,Update LLVM to include fmin/fmax optimisations,varkor,f2210a9971693e7724432379b7f38191c058ddb0,1,Update LLVM,THUMBS_UP,2019-06-06T05:26:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61386,CLOSED,2019-05-31T00:36:38Z,2019-10-03T13:27:51Z,Use statx on Linux,ariasuni,NA,NA,NA,HOORAY,2019-06-05T14:29:48Z,xen0n,NA https://github.com/rust-lang/rust/pull/61393,MERGED,2019-05-31T10:43:23Z,2019-08-02T11:24:30Z,Update Cargo.lock,gnzlbg,52caca0c45f5a2f19dc2b1af2e1fa86e2e0ad4be,1,Update Cargo.lock,THUMBS_UP,2019-07-10T19:54:05Z,dCSeven,NA https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HEART,2019-05-31T20:16:44Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HOORAY,2019-05-31T20:16:46Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HOORAY,2019-06-01T00:26:18Z,estebank,NA https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HOORAY,2019-06-03T07:15:25Z,mati865,NA https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HOORAY,2019-06-28T21:24:20Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/61407,MERGED,2019-05-31T19:29:07Z,2019-06-04T23:05:24Z,Add new diagnostic writer using annotate-snippet library,phansch,bfe5d9796b38fdecab6cd7afd28e0a7f23e4915a,2,eprint -> eprintln to add trailing newline,HOORAY,2019-06-30T20:23:33Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61408,MERGED,2019-05-31T19:30:07Z,2019-06-07T04:31:34Z,Use LLVM intrinsics for floating-point min/max,varkor,0e5edc9f1611e5c13864e4f66a9e69ce7776ea91,6,Add intrinsics for floating-point min and max,THUMBS_UP,2019-05-31T23:02:26Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61408,MERGED,2019-05-31T19:30:07Z,2019-06-07T04:31:34Z,Use LLVM intrinsics for floating-point min/max,varkor,0e5edc9f1611e5c13864e4f66a9e69ce7776ea91,6,Add intrinsics for floating-point min and max,THUMBS_UP,2019-06-13T13:17:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61409,MERGED,2019-05-31T19:49:46Z,2019-06-04T08:32:38Z,Fix an ICE with a const argument in a trait,varkor,2b27c6235b4feb1e2aaac2dde5c5c67a29470127,2,Allow `true` and `false` in const generic arguments,HEART,2019-05-31T20:22:00Z,est31,NA https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-01T04:32:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-01T05:49:40Z,est31,NA https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-01T08:18:12Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-01T08:22:50Z,RalfJung,NA https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-01T10:46:11Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/61417,CLOSED,2019-06-01T03:20:27Z,2019-07-22T12:33:25Z,Improve determinism/security of CI environment,indygreg,NA,NA,NA,THUMBS_UP,2019-06-02T13:16:58Z,bjorn3,NA https://github.com/rust-lang/rust/pull/61419,MERGED,2019-06-01T07:25:00Z,2019-06-04T08:32:40Z,Add an unusual-conversion example to to_uppercase,scottmcm,dfd9d0429cbea6133d240a37d6f4edf2a5a90a85,1,Add an unusual-conversion example to to_uppercase Like how to_lowercase has ὈΔΥΣΣΕΎΣ.,THUMBS_UP,2019-06-01T07:54:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61426,MERGED,2019-06-01T11:50:30Z,2019-06-12T22:05:11Z,Use a single lifetime for MIR construction,Zoxc,d3e1181b1cabb45388b0141974b01ca3ec36c8b9,24,Use a single lifetime for MIR construction,HOORAY,2019-06-01T15:52:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61426,MERGED,2019-06-01T11:50:30Z,2019-06-12T22:05:11Z,Use a single lifetime for MIR construction,Zoxc,d3e1181b1cabb45388b0141974b01ca3ec36c8b9,24,Use a single lifetime for MIR construction,HOORAY,2019-06-01T21:59:00Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61428,CLOSED,2019-06-01T12:18:18Z,2019-06-12T10:34:49Z,RawPthread should use libc::pthread_t,gnzlbg,NA,NA,NA,THUMBS_UP,2019-06-04T16:37:50Z,neoeinstein,marcus@griep.us https://github.com/rust-lang/rust/pull/61444,MERGED,2019-06-01T23:25:08Z,2019-06-04T08:32:42Z,Suggest using `as_ref` on `*const T`,estebank,eb73b73b8d50b29658d87670670d939746b2d00c,3,Suggest using `as_ref` on `*const T`,HEART,2019-06-02T11:54:38Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/61447,MERGED,2019-06-02T00:30:26Z,2019-06-16T07:31:07Z,Add some Vec <-> VecDeque documentation,scottmcm,0150448f1b5474bb0c5fe3297eed0c51dae44dc8,1,Remove the questionably-useful example,THUMBS_UP,2019-06-06T04:15:24Z,czipperz,czipperz@gmail.com https://github.com/rust-lang/rust/pull/61492,MERGED,2019-06-03T16:08:46Z,2019-06-11T08:15:39Z,Const qualification comments,RalfJung,0edf46f7d1db0f09dc07bf93ed466ea067d50054,1,comments,THUMBS_UP,2019-06-09T14:16:29Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61502,MERGED,2019-06-03T19:31:54Z,2019-06-05T11:15:18Z,std: Update dependency on `backtrace`,alexcrichton,fa1b6add097bf8865e843169b5ae0656b0486dad,2,std: Update dependency on `backtrace` Discovered in #61416 an accidental regression in libstd's backtrace behavior is that it previously attempted to consult libbacktrace and would then fall back to `dladdr` if libbacktrace didn't report anything. The `backtrace` crate however did not do this so that's now been fixed! Changes: https://github.com/rust-lang/backtrace-rs/compare/0.3.25...0.3.27 Closes #61416,THUMBS_UP,2019-06-04T01:11:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-03T22:23:23Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-03T23:57:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T04:02:43Z,Stargateur,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T04:23:52Z,wafflespeanut,wafflespeanut@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T06:06:29Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T09:07:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T10:43:08Z,KarboniteKream,klemen.kosir@kream.io https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T11:53:33Z,kennytm,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T12:50:24Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T12:52:38Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T13:21:49Z,lnicola,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-04T13:40:43Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-04T14:10:19Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T14:10:20Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T14:10:22Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T14:15:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T14:18:39Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T14:53:28Z,estebank,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T14:58:49Z,aschampion,andrew.champion@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-04T15:36:09Z,jminer,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T16:24:26Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-04T19:58:14Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-04T19:58:15Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-05T00:07:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-05T04:58:33Z,bash,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-05T04:58:49Z,bash,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-05T07:49:19Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-05T07:49:21Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-05T11:06:22Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-05T19:57:35Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-09T15:20:20Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T10:52:49Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T10:57:39Z,g2p,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T11:06:02Z,crides,zhuhaoqing@live.cn https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T11:09:50Z,VanillaBrooks,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T11:14:51Z,lawliet89,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T11:15:57Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T11:17:58Z,enizor,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T11:20:07Z,SugaR256,kuba.krapiec@outlook.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T11:28:13Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T11:43:36Z,gobanos,gregory.obanos@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T11:43:43Z,gobanos,gregory.obanos@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T11:43:43Z,gobanos,gregory.obanos@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T12:55:24Z,Karrq,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T12:55:24Z,Karrq,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T13:10:52Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T13:22:09Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T13:30:33Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T13:30:33Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T13:30:34Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T13:31:10Z,kazimuth,jhgilles@mit.edu https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T13:42:41Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T13:59:33Z,jplatte,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T14:01:20Z,msifd,remsifeed@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T14:36:04Z,mcginty,me@jake.su https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T14:36:08Z,mcginty,me@jake.su https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T14:36:10Z,mcginty,me@jake.su https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,ROCKET,2019-06-19T14:36:20Z,mcginty,me@jake.su https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T14:56:07Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T14:56:11Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T15:18:27Z,keliwang,root@keli.im https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T15:39:07Z,klingtnet,klingt.net@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T15:54:30Z,sbstp,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T16:46:48Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T17:11:07Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T17:47:11Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T17:47:11Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T17:49:30Z,tikue,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T17:49:32Z,tikue,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T18:07:43Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T18:07:43Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T18:07:43Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T18:16:59Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T19:42:33Z,Timidger,APragmaticPlace@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T20:49:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T21:18:26Z,etaoins,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T21:18:27Z,etaoins,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T21:18:29Z,etaoins,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T21:44:21Z,AndyGauge,andygauge@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T22:03:13Z,carols10cents,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T22:03:16Z,carols10cents,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-19T23:29:16Z,wg,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-19T23:29:17Z,wg,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-19T23:29:22Z,wg,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,ROCKET,2019-06-20T02:24:22Z,Alexhuszagh,ahuszagh@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-20T03:40:37Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-20T06:49:05Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-20T07:17:28Z,Vurich,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-20T09:22:57Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-20T18:18:36Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-21T10:32:05Z,xjkdev,xjk2008@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-21T22:36:51Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2019-06-21T22:36:52Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-26T19:45:27Z,axelf4,axelsfor@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-06-27T04:20:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-29T02:32:19Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2019-06-29T03:58:42Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2019-07-30T11:04:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2020-04-16T14:23:00Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2021-01-23T23:39:18Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,THUMBS_UP,2021-08-19T16:32:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HOORAY,2021-08-19T16:32:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61505,MERGED,2019-06-03T22:11:18Z,2019-06-19T09:44:28Z,Only show methods that appear in `impl` blocks in the Implementors sections of trait doc pages,ebarnard,45bb4097b4bb2670f93d0836d40d31bbde38aab2,1,Only show methods that appear in the impl block for types in the Implementors and Implementations on Foreign Types sections of trait documentation pages.,HEART,2021-08-19T16:32:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61515,MERGED,2019-06-04T12:21:38Z,2019-08-06T21:05:22Z,Add implementations for converting boxed slices into boxed arrays,shepmaster,32324d22c33dda31eadf49c5f27d6e6ff38a3ef1,9,Add implementations for converting boxed slices into boxed arrays This mirrors the implementations of reference slices into arrays.,HEART,2019-06-04T20:33:12Z,Wallacoloo,colin@mooooo.ooo https://github.com/rust-lang/rust/pull/61515,MERGED,2019-06-04T12:21:38Z,2019-08-06T21:05:22Z,Add implementations for converting boxed slices into boxed arrays,shepmaster,32324d22c33dda31eadf49c5f27d6e6ff38a3ef1,9,Add implementations for converting boxed slices into boxed arrays This mirrors the implementations of reference slices into arrays.,HEART,2019-08-15T17:47:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61541,MERGED,2019-06-05T11:43:27Z,2019-06-07T09:41:39Z,syntax: Keep token span as a part of `Token`,petrochenkov,3a31f0634bb1669eae64e83f595942986f867125,3,Address review comments,HEART,2019-06-05T13:11:10Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61541,MERGED,2019-06-05T11:43:27Z,2019-06-07T09:41:39Z,syntax: Keep token span as a part of `Token`,petrochenkov,3a31f0634bb1669eae64e83f595942986f867125,3,Address review comments,HEART,2019-06-05T15:21:57Z,mati865,NA https://github.com/rust-lang/rust/pull/61541,MERGED,2019-06-05T11:43:27Z,2019-06-07T09:41:39Z,syntax: Keep token span as a part of `Token`,petrochenkov,3a31f0634bb1669eae64e83f595942986f867125,3,Address review comments,HEART,2019-06-07T18:07:17Z,estebank,NA https://github.com/rust-lang/rust/pull/61545,MERGED,2019-06-05T14:18:56Z,2019-07-05T21:52:23Z,Implement another internal lints,flip1995,d0625a380b03e83fcfc2f0230986186992d13c71,5,Allow usage_of_ty_tykind only in sty and in some special cases,HOORAY,2019-06-05T14:19:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61545,MERGED,2019-06-05T14:18:56Z,2019-07-05T21:52:23Z,Implement another internal lints,flip1995,d0625a380b03e83fcfc2f0230986186992d13c71,5,Allow usage_of_ty_tykind only in sty and in some special cases,HOORAY,2019-06-05T15:19:31Z,mati865,NA https://github.com/rust-lang/rust/pull/61545,MERGED,2019-06-05T14:18:56Z,2019-07-05T21:52:23Z,Implement another internal lints,flip1995,d0625a380b03e83fcfc2f0230986186992d13c71,5,Allow usage_of_ty_tykind only in sty and in some special cases,HEART,2019-06-05T20:08:06Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61557,MERGED,2019-06-05T19:40:32Z,2019-06-06T15:05:21Z,rustbuild: Include `rustfmt` in deduplicated dependencies,alexcrichton,f708228508f29983e7d936e9b0388b0e64a51512,2,"rustbuild: Include `rustfmt` in deduplicated dependencies Currently `rustfmt` is excluded from the ""don't build dependencies twice"" check but it's currently building dependencies twice! Namely big dependencies like `rustc-ap-syntax` are built once for rustfmt and once for the RLS. This commit includes `rustfmt` in these checks and then fixes the resulting feature mismatches for winapi.",HEART,2019-06-05T19:56:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/61568,MERGED,2019-06-06T00:08:21Z,2019-06-12T07:38:24Z,Use Symbol Span in libfmt_macros,Mark-Simulacrum,45df52f2cca9bee04690f476f4a3f791ea1b04cc,1,Properly point at the last opening brace,HEART,2019-06-06T00:51:46Z,estebank,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-06-06T16:44:05Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-06-07T00:26:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HEART,2019-06-10T22:30:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-06-11T18:24:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HEART,2019-06-12T03:37:10Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-06-16T12:56:30Z,mati865,NA https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HEART,2019-07-01T23:07:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-07-01T23:07:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HOORAY,2019-07-07T18:55:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/61590,MERGED,2019-06-06T16:39:47Z,2019-07-12T08:36:13Z,Remove rustc_mir dependency from rustc_borrowck,matthewjasper,34ddc70c3f4a013f22273d9497631186b26f07b2,16,Move rustc_borrowck -> rustc_ast_borrowck,HEART,2019-07-11T17:26:42Z,lqd,NA https://github.com/rust-lang/rust/pull/61603,MERGED,2019-06-06T21:13:48Z,2019-06-07T17:44:10Z,Increases heap size available during testing for SGX,Goirad,9a498419615600741d6c29fb3ace4e31a1831efa,1,increase max heapsize available during sgx tests,THUMBS_UP,2019-06-06T21:20:16Z,jethrogb,NA https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-07T00:27:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-07T08:15:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-10T10:57:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-10T16:01:19Z,estebank,NA https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-10T19:21:59Z,cramertj,NA https://github.com/rust-lang/rust/pull/61606,MERGED,2019-06-07T00:19:03Z,2019-06-12T02:13:41Z,Remove some legacy proc macro flavors,petrochenkov,93eb63c9a540e8721adf8b97085301b7b692785d,12,syntax: Rename variants of `SyntaxExtension` for consistency,HEART,2019-06-10T20:05:50Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/61613,MERGED,2019-06-07T08:05:42Z,2019-08-25T23:01:38Z,Support `impl Trait` in inlined documentation,sinkuu,1fe6160c7e4b584795c66f21683064f62803acf0,3,Fix ICE with `impl Trait` in type bounds,HOORAY,2019-08-29T08:41:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61613,MERGED,2019-06-07T08:05:42Z,2019-08-25T23:01:38Z,Support `impl Trait` in inlined documentation,sinkuu,1fe6160c7e4b584795c66f21683064f62803acf0,3,Fix ICE with `impl Trait` in type bounds,HOORAY,2019-08-30T17:38:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61620,MERGED,2019-06-07T14:27:16Z,2019-06-08T13:03:26Z,Stabilize Cell::from_mut and as_slice_of_cells,SimonSapin,2ce94403688c938bdc857fb498ab756cbe72ada7,2,Stabilize Cell::from_mut and as_slice_of_cells FCP: https://github.com/rust-lang/rust/issues/43038#issuecomment-499900463,HOORAY,2019-06-07T16:43:43Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/61620,MERGED,2019-06-07T14:27:16Z,2019-06-08T13:03:26Z,Stabilize Cell::from_mut and as_slice_of_cells,SimonSapin,2ce94403688c938bdc857fb498ab756cbe72ada7,2,Stabilize Cell::from_mut and as_slice_of_cells FCP: https://github.com/rust-lang/rust/issues/43038#issuecomment-499900463,HOORAY,2019-06-12T14:31:46Z,novacrazy,NA https://github.com/rust-lang/rust/pull/61620,MERGED,2019-06-07T14:27:16Z,2019-06-08T13:03:26Z,Stabilize Cell::from_mut and as_slice_of_cells,SimonSapin,2ce94403688c938bdc857fb498ab756cbe72ada7,2,Stabilize Cell::from_mut and as_slice_of_cells FCP: https://github.com/rust-lang/rust/issues/43038#issuecomment-499900463,HOORAY,2019-06-14T04:13:44Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/61626,MERGED,2019-06-07T17:24:00Z,2019-09-18T02:13:36Z,Get rid of special const intrinsic query in favour of `const_eval`,oli-obk,0de9485038a5a068644efbfa397feec6d02e05ea,14,Get rid of special const intrinsic query in favour of `const_eval`,HOORAY,2019-06-08T02:29:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61626,MERGED,2019-06-07T17:24:00Z,2019-09-18T02:13:36Z,Get rid of special const intrinsic query in favour of `const_eval`,oli-obk,0de9485038a5a068644efbfa397feec6d02e05ea,14,Get rid of special const intrinsic query in favour of `const_eval`,HOORAY,2019-07-11T13:39:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/61626,MERGED,2019-06-07T17:24:00Z,2019-09-18T02:13:36Z,Get rid of special const intrinsic query in favour of `const_eval`,oli-obk,0de9485038a5a068644efbfa397feec6d02e05ea,14,Get rid of special const intrinsic query in favour of `const_eval`,HOORAY,2019-08-17T08:57:54Z,mati865,NA https://github.com/rust-lang/rust/pull/61626,MERGED,2019-06-07T17:24:00Z,2019-09-18T02:13:36Z,Get rid of special const intrinsic query in favour of `const_eval`,oli-obk,0de9485038a5a068644efbfa397feec6d02e05ea,14,Get rid of special const intrinsic query in favour of `const_eval`,HOORAY,2019-08-28T15:43:31Z,estebank,NA https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-07T20:41:21Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-08T02:30:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,ROCKET,2019-06-09T20:53:00Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-09T20:53:02Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-12T16:58:06Z,tesuji,NA https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-19T21:40:42Z,estebank,NA https://github.com/rust-lang/rust/pull/61629,MERGED,2019-06-07T18:09:51Z,2019-06-13T04:20:04Z,Hygienize macros in the standard library,petrochenkov,eb09daa762c37c743584ec3b5c05a2d181960ced,7,Hygienize macros in the standard library,HOORAY,2019-06-20T09:45:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61635,MERGED,2019-06-07T21:22:38Z,2019-06-08T10:16:09Z,Make `i*::signum` a `const fn`.,ecstatic-morse,f6611db1d59bbf5fb7d5cfbcccc629b6916d06a3,1,Add `const`-ness tests for `i32::signum`,HEART,2019-06-07T21:52:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/61635,MERGED,2019-06-07T21:22:38Z,2019-06-08T10:16:09Z,Make `i*::signum` a `const fn`.,ecstatic-morse,f6611db1d59bbf5fb7d5cfbcccc629b6916d06a3,1,Add `const`-ness tests for `i32::signum`,HEART,2019-06-08T05:35:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61635,MERGED,2019-06-07T21:22:38Z,2019-06-08T10:16:09Z,Make `i*::signum` a `const fn`.,ecstatic-morse,f6611db1d59bbf5fb7d5cfbcccc629b6916d06a3,1,Add `const`-ness tests for `i32::signum`,HEART,2019-06-13T13:15:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61635,MERGED,2019-06-07T21:22:38Z,2019-06-08T10:16:09Z,Make `i*::signum` a `const fn`.,ecstatic-morse,f6611db1d59bbf5fb7d5cfbcccc629b6916d06a3,1,Add `const`-ness tests for `i32::signum`,HEART,2019-06-30T19:56:06Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61639,MERGED,2019-06-07T22:03:12Z,2019-06-14T01:13:27Z,Bootstrap cleanup,Mark-Simulacrum,d728d27ef3a00734e3a13e68da1c40f371400fbd,2,Remove unnecessary Std dependency,HEART,2019-06-08T03:13:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/61639,MERGED,2019-06-07T22:03:12Z,2019-06-14T01:13:27Z,Bootstrap cleanup,Mark-Simulacrum,d728d27ef3a00734e3a13e68da1c40f371400fbd,2,Remove unnecessary Std dependency,HEART,2019-06-10T16:37:38Z,mati865,NA https://github.com/rust-lang/rust/pull/61639,MERGED,2019-06-07T22:03:12Z,2019-06-14T01:13:27Z,Bootstrap cleanup,Mark-Simulacrum,d728d27ef3a00734e3a13e68da1c40f371400fbd,2,Remove unnecessary Std dependency,HEART,2019-06-11T18:22:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61643,CLOSED,2019-06-07T22:36:08Z,2019-06-12T23:00:50Z,Do not suggest using | in let assignments,estebank,NA,NA,NA,HEART,2019-06-08T05:38:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61643,CLOSED,2019-06-07T22:36:08Z,2019-06-12T23:00:50Z,Do not suggest using | in let assignments,estebank,NA,NA,NA,HEART,2019-06-08T06:53:27Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/61646,MERGED,2019-06-07T23:45:59Z,2019-06-09T02:08:16Z,Remove useless allocations in macro_rules follow logic.,L117,7a74f33f9067365f9b67057ea536e5f4d84fcc45,1,Remove useless allocations in macro_rules follow logic.,HOORAY,2019-06-08T00:00:00Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61646,MERGED,2019-06-07T23:45:59Z,2019-06-09T02:08:16Z,Remove useless allocations in macro_rules follow logic.,L117,7a74f33f9067365f9b67057ea536e5f4d84fcc45,1,Remove useless allocations in macro_rules follow logic.,HOORAY,2019-06-08T00:25:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61646,MERGED,2019-06-07T23:45:59Z,2019-06-09T02:08:16Z,Remove useless allocations in macro_rules follow logic.,L117,7a74f33f9067365f9b67057ea536e5f4d84fcc45,1,Remove useless allocations in macro_rules follow logic.,HOORAY,2019-06-08T02:26:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61646,MERGED,2019-06-07T23:45:59Z,2019-06-09T02:08:16Z,Remove useless allocations in macro_rules follow logic.,L117,7a74f33f9067365f9b67057ea536e5f4d84fcc45,1,Remove useless allocations in macro_rules follow logic.,HOORAY,2019-06-08T03:11:18Z,panaman67,NA https://github.com/rust-lang/rust/pull/61646,MERGED,2019-06-07T23:45:59Z,2019-06-09T02:08:16Z,Remove useless allocations in macro_rules follow logic.,L117,7a74f33f9067365f9b67057ea536e5f4d84fcc45,1,Remove useless allocations in macro_rules follow logic.,HOORAY,2019-06-13T13:15:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61660,MERGED,2019-06-08T14:52:34Z,2019-06-09T02:08:18Z,Minimize use of `#![feature(custom_attribute)]`,petrochenkov,ee189ae028ce4ff620630686432f44b0ea706181,4,Address review comments,HOORAY,2019-06-08T16:07:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61660,MERGED,2019-06-08T14:52:34Z,2019-06-09T02:08:18Z,Minimize use of `#![feature(custom_attribute)]`,petrochenkov,ee189ae028ce4ff620630686432f44b0ea706181,4,Address review comments,HOORAY,2019-06-08T20:35:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/61660,MERGED,2019-06-08T14:52:34Z,2019-06-09T02:08:18Z,Minimize use of `#![feature(custom_attribute)]`,petrochenkov,ee189ae028ce4ff620630686432f44b0ea706181,4,Address review comments,HOORAY,2019-06-13T13:12:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61669,MERGED,2019-06-08T19:42:11Z,2019-06-09T02:08:20Z, syntax: Remove `Deref` impl from `Token`,petrochenkov,9aaa7c770c976e35b1614f1f6bf120204c5727c8,1,syntax: Move some `Token` methods around,HEART,2019-06-08T20:34:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/61669,MERGED,2019-06-08T19:42:11Z,2019-06-09T02:08:20Z, syntax: Remove `Deref` impl from `Token`,petrochenkov,9aaa7c770c976e35b1614f1f6bf120204c5727c8,1,syntax: Move some `Token` methods around,HEART,2019-06-13T13:17:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61673,MERGED,2019-06-08T22:54:13Z,2019-06-11T11:07:05Z,Miri: convert to/from apfloat instead of host floats,RalfJung,8dfc8db235e205c60b56e0753996399a6f66f3e1,1,forgot about multivariant enum casts,HOORAY,2019-06-11T03:51:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61675,MERGED,2019-06-08T23:32:33Z,2019-06-13T04:20:05Z,Include frame pointer for bare metal RISC-V targets,fintelia,493d1b473a271e3fc8d332c6bf8e24930a7be597,4,Include frame pointer for bare metal RISC-V targets,HEART,2019-06-09T13:47:57Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/61675,MERGED,2019-06-08T23:32:33Z,2019-06-13T04:20:05Z,Include frame pointer for bare metal RISC-V targets,fintelia,493d1b473a271e3fc8d332c6bf8e24930a7be597,4,Include frame pointer for bare metal RISC-V targets,HEART,2019-06-10T02:15:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61675,MERGED,2019-06-08T23:32:33Z,2019-06-13T04:20:05Z,Include frame pointer for bare metal RISC-V targets,fintelia,493d1b473a271e3fc8d332c6bf8e24930a7be597,4,Include frame pointer for bare metal RISC-V targets,HEART,2019-06-10T04:56:27Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/61675,MERGED,2019-06-08T23:32:33Z,2019-06-13T04:20:05Z,Include frame pointer for bare metal RISC-V targets,fintelia,493d1b473a271e3fc8d332c6bf8e24930a7be597,4,Include frame pointer for bare metal RISC-V targets,HEART,2019-06-12T05:19:14Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61679,MERGED,2019-06-09T04:52:45Z,2019-06-14T12:37:54Z,in which we decline to suggest the anonymous lifetime in declarations,zackmdavis,7a3184a04c4023d9ab93fe793c0d0ffb5e91240b,3,"in which we decline to suggest the anonymous lifetime in declarations The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum indicating whether the present path-segment was part of an expression or anywhere else. The present case seemed to be part of the ""anywhere else"" and yet meriting different rules as far as the lint was concerned so it seemed expedient to introduce a new enum member. We yank out a `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields. (The alternative strategy of changing the signature of `lower_ty` to take a `ParamMode` would be inelegant given that most of the `TyKind` match arm bodies therein don't concern themselves with `ParamMode`.) Resolves #61124.",HEART,2019-06-09T05:26:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61679,MERGED,2019-06-09T04:52:45Z,2019-06-14T12:37:54Z,in which we decline to suggest the anonymous lifetime in declarations,zackmdavis,7a3184a04c4023d9ab93fe793c0d0ffb5e91240b,3,"in which we decline to suggest the anonymous lifetime in declarations The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum indicating whether the present path-segment was part of an expression or anywhere else. The present case seemed to be part of the ""anywhere else"" and yet meriting different rules as far as the lint was concerned so it seemed expedient to introduce a new enum member. We yank out a `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields. (The alternative strategy of changing the signature of `lower_ty` to take a `ParamMode` would be inelegant given that most of the `TyKind` match arm bodies therein don't concern themselves with `ParamMode`.) Resolves #61124.",HEART,2019-06-09T17:10:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61679,MERGED,2019-06-09T04:52:45Z,2019-06-14T12:37:54Z,in which we decline to suggest the anonymous lifetime in declarations,zackmdavis,7a3184a04c4023d9ab93fe793c0d0ffb5e91240b,3,"in which we decline to suggest the anonymous lifetime in declarations The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum indicating whether the present path-segment was part of an expression or anywhere else. The present case seemed to be part of the ""anywhere else"" and yet meriting different rules as far as the lint was concerned so it seemed expedient to introduce a new enum member. We yank out a `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields. (The alternative strategy of changing the signature of `lower_ty` to take a `ParamMode` would be inelegant given that most of the `TyKind` match arm bodies therein don't concern themselves with `ParamMode`.) Resolves #61124.",HEART,2019-06-10T23:41:53Z,estebank,NA https://github.com/rust-lang/rust/pull/61679,MERGED,2019-06-09T04:52:45Z,2019-06-14T12:37:54Z,in which we decline to suggest the anonymous lifetime in declarations,zackmdavis,7a3184a04c4023d9ab93fe793c0d0ffb5e91240b,3,"in which we decline to suggest the anonymous lifetime in declarations The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum indicating whether the present path-segment was part of an expression or anywhere else. The present case seemed to be part of the ""anywhere else"" and yet meriting different rules as far as the lint was concerned so it seemed expedient to introduce a new enum member. We yank out a `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields. (The alternative strategy of changing the signature of `lower_ty` to take a `ParamMode` would be inelegant given that most of the `TyKind` match arm bodies therein don't concern themselves with `ParamMode`.) Resolves #61124.",HEART,2019-06-14T15:11:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61680,CLOSED,2019-06-09T04:55:16Z,2019-06-13T19:08:51Z,Add Vec::flatten (as unstable of course),scottmcm,NA,NA,NA,THUMBS_UP,2019-06-09T05:10:16Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/61680,CLOSED,2019-06-09T04:55:16Z,2019-06-13T19:08:51Z,Add Vec::flatten (as unstable of course),scottmcm,NA,NA,NA,THUMBS_UP,2019-06-09T13:38:26Z,ds84182,NA https://github.com/rust-lang/rust/pull/61680,CLOSED,2019-06-09T04:55:16Z,2019-06-13T19:08:51Z,Add Vec::flatten (as unstable of course),scottmcm,NA,NA,NA,THUMBS_UP,2019-09-21T04:50:00Z,mikeumus,NA https://github.com/rust-lang/rust/pull/61680,CLOSED,2019-06-09T04:55:16Z,2019-06-13T19:08:51Z,Add Vec::flatten (as unstable of course),scottmcm,NA,NA,NA,THUMBS_UP,2022-03-23T18:33:38Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,HOORAY,2019-06-09T09:07:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,THUMBS_UP,2019-06-10T03:15:57Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,THUMBS_UP,2019-06-12T05:18:24Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,HOORAY,2019-06-13T04:14:53Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,HOORAY,2019-06-28T16:14:58Z,jakelogemann,NA https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,THUMBS_UP,2019-07-15T10:08:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,THUMBS_UP,2019-08-14T04:12:33Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/61682,MERGED,2019-06-09T05:38:13Z,2019-07-01T06:42:11Z,Stabilize `type_alias_enum_variants` in Rust 1.37.0,Centril,57e6869a6be56cd75e382deb313fb5f4d1bb1fda,3,type_alias_enum_variants: cleanup redundant 'allow(unused)'.,HOORAY,2019-08-14T04:12:36Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/61698,MERGED,2019-06-09T19:57:52Z,2019-06-12T02:13:47Z,typeck: Fix const generic in repeat param ICE.,davidtwco,9ed4674269f3d1ecedfd173e279087d256d66e77,6,typeck: Fix const generic in repeat param ICE. This commit fixes an ICE that occured when a const generic was used in a repeat expression. This was due to the code expecting the length of the repeat expression to be const evaluatable to a constant but a const generic parameter is not (however it can be made into a constant).,HEART,2019-06-10T10:41:35Z,varkor,NA https://github.com/rust-lang/rust/pull/61698,MERGED,2019-06-09T19:57:52Z,2019-06-12T02:13:47Z,typeck: Fix const generic in repeat param ICE.,davidtwco,9ed4674269f3d1ecedfd173e279087d256d66e77,6,typeck: Fix const generic in repeat param ICE. This commit fixes an ICE that occured when a const generic was used in a repeat expression. This was due to the code expecting the length of the repeat expression to be const evaluatable to a constant but a const generic parameter is not (however it can be made into a constant).,HEART,2019-06-10T18:24:14Z,lqd,NA https://github.com/rust-lang/rust/pull/61698,MERGED,2019-06-09T19:57:52Z,2019-06-12T02:13:47Z,typeck: Fix const generic in repeat param ICE.,davidtwco,9ed4674269f3d1ecedfd173e279087d256d66e77,6,typeck: Fix const generic in repeat param ICE. This commit fixes an ICE that occured when a const generic was used in a repeat expression. This was due to the code expecting the length of the repeat expression to be const evaluatable to a constant but a const generic parameter is not (however it can be made into a constant).,HEART,2019-06-12T01:45:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-06-10T03:16:12Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-06-10T04:01:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-06-10T09:37:01Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-06-12T01:44:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-06-23T15:30:17Z,jplatte,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-07-07T23:09:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-07-14T13:15:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-07-24T15:45:54Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,THUMBS_UP,2019-07-27T06:03:13Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,HOORAY,2019-08-18T06:51:37Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,HOORAY,2019-08-18T23:14:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61708,MERGED,2019-06-10T02:17:43Z,2019-08-18T04:37:10Z,Initial implementation of or-patterns,dlrobertson,1870537f2701e5aa47080a879b63a4d6b391553b,22,initial implementation of or-pattern parsing Initial implementation of parsing or-patterns e.g. `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.,HOORAY,2019-08-24T21:27:18Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/61719,CLOSED,2019-06-10T14:56:05Z,2019-06-12T09:14:34Z,Add `--filter-mode=run-pass compile-pass` to compiletest,Centril,NA,NA,NA,THUMBS_UP,2019-06-10T15:19:19Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61720,MERGED,2019-06-10T15:18:03Z,2019-06-13T15:45:32Z,std: Remove internal definitions of `cfg_if!` macro,alexcrichton,8eb7f36a3ba06dbea4a44254c3e2d92455ae150f,18,std: Remove internal definitions of `cfg_if!` macro This is duplicated in a few locations throughout the sysroot to work around issues with not exporting a macro in libstd but still wanting it available to sysroot crates to define blocks. Nowadays though we can simply depend on the `cfg-if` crate on crates.io allowing us to use it from there!,HEART,2019-06-10T22:12:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T16:27:59Z,mati865,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T16:30:49Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T16:46:52Z,varkor,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T16:47:43Z,estebank,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T18:08:20Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T18:50:17Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T19:24:58Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T19:32:24Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HOORAY,2019-06-10T20:52:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-10T22:11:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HOORAY,2019-06-10T22:11:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HOORAY,2019-06-11T10:50:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HEART,2019-06-11T10:50:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HOORAY,2019-06-12T00:38:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/61722,MERGED,2019-06-10T16:23:06Z,2019-06-12T16:30:29Z,rustc: replace `TyCtxt<'a 'gcx 'tcx>` with `TyCtxt<'gcx 'tcx>`.,eddyb,4c98cb6f7586d92be37c94c6063fa9645a448e92,3,rustc_codegen_llvm: `deny(internal)`.,HOORAY,2019-06-13T04:09:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/61735,MERGED,2019-06-11T10:29:01Z,2019-06-11T23:30:03Z,Add deny(unused_lifetimes) to all the crates that have deny(internal).,eddyb,1d720ec27c5bdbc377145b8a29c1d727fb7131d6,13,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-11T10:32:01Z,mati865,NA https://github.com/rust-lang/rust/pull/61739,MERGED,2019-06-11T12:55:47Z,2019-06-16T14:58:35Z,Separate unit tests,chansuke,5a9643c95be10fb99c218286883f82640db72610,2,Fix tidy,HEART,2019-06-11T18:39:57Z,estebank,NA https://github.com/rust-lang/rust/pull/61739,MERGED,2019-06-11T12:55:47Z,2019-06-16T14:58:35Z,Separate unit tests,chansuke,5a9643c95be10fb99c218286883f82640db72610,2,Fix tidy,HEART,2019-06-12T18:28:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/61748,MERGED,2019-06-11T20:29:35Z,2019-06-19T09:44:33Z,Tweak transparent enums and unions diagnostic spans,estebank,f06b76122cde7ddd4f6778d77952b63baa70bdfe,1,review comments: move diagnostic code out of happy path,HEART,2019-06-11T21:47:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/61750,MERGED,2019-06-11T21:22:55Z,2019-06-13T04:20:10Z,Fix x.py install,tmandry,4f3cd3ca07f9583d503ad9b260a8d397ebf10055,1,Fix x.py install Make sure we look for save analysis in the right place. Fixes #61703.,THUMBS_UP,2019-06-11T21:24:42Z,cramertj,NA https://github.com/rust-lang/rust/pull/61750,MERGED,2019-06-11T21:22:55Z,2019-06-13T04:20:10Z,Fix x.py install,tmandry,4f3cd3ca07f9583d503ad9b260a8d397ebf10055,1,Fix x.py install Make sure we look for save analysis in the right place. Fixes #61703.,THUMBS_UP,2019-06-12T11:40:47Z,Keruspe,NA https://github.com/rust-lang/rust/pull/61753,CLOSED,2019-06-11T21:59:27Z,2019-06-20T21:19:15Z,Do not discern between statements with and without semicolon after lowering to HIR,petrochenkov,NA,NA,NA,THUMBS_UP,2019-06-12T15:41:12Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/61753,CLOSED,2019-06-11T21:59:27Z,2019-06-20T21:19:15Z,Do not discern between statements with and without semicolon after lowering to HIR,petrochenkov,NA,NA,NA,THUMBS_UP,2019-06-12T18:25:46Z,panaman67,NA https://github.com/rust-lang/rust/pull/61753,CLOSED,2019-06-11T21:59:27Z,2019-06-20T21:19:15Z,Do not discern between statements with and without semicolon after lowering to HIR,petrochenkov,NA,NA,NA,HEART,2019-06-12T18:25:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/61754,MERGED,2019-06-11T23:11:12Z,2019-06-16T17:48:51Z,"create a ""provisional cache"" to restore performance in the case of cycles",nikomatsakis,0baa9258dd2f901a24d744705f514fa678e64940,1,put back the workarounds for #60846 based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.,ROCKET,2019-06-11T23:34:31Z,mati865,NA https://github.com/rust-lang/rust/pull/61754,MERGED,2019-06-11T23:11:12Z,2019-06-16T17:48:51Z,"create a ""provisional cache"" to restore performance in the case of cycles",nikomatsakis,0baa9258dd2f901a24d744705f514fa678e64940,1,put back the workarounds for #60846 based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.,ROCKET,2019-06-11T23:55:17Z,cramertj,NA https://github.com/rust-lang/rust/pull/61754,MERGED,2019-06-11T23:11:12Z,2019-06-16T17:48:51Z,"create a ""provisional cache"" to restore performance in the case of cycles",nikomatsakis,0baa9258dd2f901a24d744705f514fa678e64940,1,put back the workarounds for #60846 based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.,ROCKET,2019-06-16T21:38:02Z,ipetkov,ivanppetkov@gmail.com https://github.com/rust-lang/rust/pull/61754,MERGED,2019-06-11T23:11:12Z,2019-06-16T17:48:51Z,"create a ""provisional cache"" to restore performance in the case of cycles",nikomatsakis,0baa9258dd2f901a24d744705f514fa678e64940,1,put back the workarounds for #60846 based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.,ROCKET,2019-06-18T12:46:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/61754,MERGED,2019-06-11T23:11:12Z,2019-06-16T17:48:51Z,"create a ""provisional cache"" to restore performance in the case of cycles",nikomatsakis,0baa9258dd2f901a24d744705f514fa678e64940,1,put back the workarounds for #60846 based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.,ROCKET,2019-06-19T15:19:04Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/61757,MERGED,2019-06-12T01:59:14Z,2019-06-13T15:45:34Z,Deprecate ONCE_INIT in future 1.38 release,sfackler,72e99f57c5118430361d23ed8e8815c1dd7271a5,4,Deprecate ONCE_INIT Once::new() has been a stable const fn for a while now. Closes #61746,THUMBS_UP,2019-06-12T15:24:58Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/61757,MERGED,2019-06-12T01:59:14Z,2019-06-13T15:45:34Z,Deprecate ONCE_INIT in future 1.38 release,sfackler,72e99f57c5118430361d23ed8e8815c1dd7271a5,4,Deprecate ONCE_INIT Once::new() has been a stable const fn for a while now. Closes #61746,THUMBS_UP,2019-06-12T18:24:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/61757,MERGED,2019-06-12T01:59:14Z,2019-06-13T15:45:34Z,Deprecate ONCE_INIT in future 1.38 release,sfackler,72e99f57c5118430361d23ed8e8815c1dd7271a5,4,Deprecate ONCE_INIT Once::new() has been a stable const fn for a while now. Closes #61746,HEART,2019-06-12T18:24:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/61757,MERGED,2019-06-12T01:59:14Z,2019-06-13T15:45:34Z,Deprecate ONCE_INIT in future 1.38 release,sfackler,72e99f57c5118430361d23ed8e8815c1dd7271a5,4,Deprecate ONCE_INIT Once::new() has been a stable const fn for a while now. Closes #61746,THUMBS_UP,2019-06-13T02:21:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/61757,MERGED,2019-06-12T01:59:14Z,2019-06-13T15:45:34Z,Deprecate ONCE_INIT in future 1.38 release,sfackler,72e99f57c5118430361d23ed8e8815c1dd7271a5,4,Deprecate ONCE_INIT Once::new() has been a stable const fn for a while now. Closes #61746,THUMBS_UP,2019-06-13T23:40:12Z,estebank,NA https://github.com/rust-lang/rust/pull/61771,MERGED,2019-06-12T14:38:52Z,2019-06-18T05:17:02Z,Update cargo,ehuss,afa4827e986f8f6e683e09c983767d68e05e6038,1,Bump libgit2-sys to get it to compile on i686-pc-windows-gnu.,HOORAY,2019-06-18T07:06:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-12T17:21:30Z,cramertj,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-12T17:25:32Z,cramertj,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-16T10:54:46Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-16T10:54:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-16T14:47:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-18T11:14:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-18T11:14:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-18T18:13:52Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-18T23:00:19Z,sachaarbonel,sacha.arbonel@hotmail.fr https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-19T02:44:03Z,aminroosta,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-19T04:18:05Z,RobertWHurst,robertwhurst@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-20T10:00:19Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-21T12:14:50Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-21T12:14:51Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-21T12:14:52Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-23T05:45:52Z,tomhoule,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-06-23T05:45:53Z,tomhoule,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-06-23T05:45:54Z,tomhoule,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-06-25T04:04:37Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-07-03T17:58:17Z,tmandry,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-07-03T17:58:18Z,tmandry,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-07-03T21:54:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-07-03T21:54:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-07-04T02:08:26Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-07-10T08:17:24Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-07-10T09:47:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-07-10T13:46:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HEART,2019-07-11T14:53:53Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-07-11T14:53:55Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,HOORAY,2019-07-11T14:53:56Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/61775,MERGED,2019-06-12T15:38:47Z,2019-07-03T07:21:59Z,generalize impl trait to permit multiple lifetime bounds,nikomatsakis,f7e00a55bba51de1d58f829b562f9aff05d543f3,4,fix ICE with delay-span-bug,THUMBS_UP,2019-07-12T04:29:17Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/61778,MERGED,2019-06-12T16:06:00Z,2019-06-23T20:05:28Z,compiletest: Introduce `// {check build run}-pass` pass modes,petrochenkov,0886bc4cbf3ec9b782b2dc9ed99ac6bed9df7b00,1,compiletest: Move pass mode update into a separate function,THUMBS_UP,2019-06-12T17:36:40Z,cramertj,NA https://github.com/rust-lang/rust/pull/61778,MERGED,2019-06-12T16:06:00Z,2019-06-23T20:05:28Z,compiletest: Introduce `// {check build run}-pass` pass modes,petrochenkov,0886bc4cbf3ec9b782b2dc9ed99ac6bed9df7b00,1,compiletest: Move pass mode update into a separate function,THUMBS_UP,2019-06-21T18:33:32Z,estebank,NA https://github.com/rust-lang/rust/pull/61778,MERGED,2019-06-12T16:06:00Z,2019-06-23T20:05:28Z,compiletest: Introduce `// {check build run}-pass` pass modes,petrochenkov,0886bc4cbf3ec9b782b2dc9ed99ac6bed9df7b00,1,compiletest: Move pass mode update into a separate function,THUMBS_UP,2019-06-23T11:17:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61778,MERGED,2019-06-12T16:06:00Z,2019-06-23T20:05:28Z,compiletest: Introduce `// {check build run}-pass` pass modes,petrochenkov,0886bc4cbf3ec9b782b2dc9ed99ac6bed9df7b00,1,compiletest: Move pass mode update into a separate function,THUMBS_UP,2019-07-04T13:52:09Z,agnxy,andrewxuyuan@gmail.com https://github.com/rust-lang/rust/pull/61778,MERGED,2019-06-12T16:06:00Z,2019-06-23T20:05:28Z,compiletest: Introduce `// {check build run}-pass` pass modes,petrochenkov,0886bc4cbf3ec9b782b2dc9ed99ac6bed9df7b00,1,compiletest: Move pass mode update into a separate function,THUMBS_UP,2019-07-16T21:57:16Z,lqd,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-12T17:13:39Z,lqd,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-12T18:14:31Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-12T19:10:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-13T05:03:28Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-18T22:55:11Z,mati865,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-06-29T00:12:23Z,tmandry,NA https://github.com/rust-lang/rust/pull/61779,MERGED,2019-06-12T16:13:41Z,2019-07-23T13:32:30Z,Use sharded maps for interning,Zoxc,0e73386a667498414df76f1b6f3bc2471845fbf6,4,Use sharded maps for interning,HOORAY,2019-07-05T14:54:31Z,estebank,NA https://github.com/rust-lang/rust/pull/61780,MERGED,2019-06-12T17:12:32Z,2019-08-16T22:06:29Z,Finalize the error type for `try_reserve`,SimonSapin,59a340963fa5d8b5507d95cd015f7ca2855ba151,8,Add the Layout of the failed allocation to TryReserveError::AllocError … and add a separately-unstable field to force non-exhaustive matching (`#[non_exhaustive]` is no implemented yet on enum variants) so that we have the option to later expose the allocator’s error value. CC https://github.com/rust-lang/wg-allocators/issues/23,THUMBS_UP,2019-06-12T18:44:26Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/61780,MERGED,2019-06-12T17:12:32Z,2019-08-16T22:06:29Z,Finalize the error type for `try_reserve`,SimonSapin,59a340963fa5d8b5507d95cd015f7ca2855ba151,8,Add the Layout of the failed allocation to TryReserveError::AllocError … and add a separately-unstable field to force non-exhaustive matching (`#[non_exhaustive]` is no implemented yet on enum variants) so that we have the option to later expose the allocator’s error value. CC https://github.com/rust-lang/wg-allocators/issues/23,HEART,2019-06-14T00:32:14Z,snf,NA https://github.com/rust-lang/rust/pull/61782,MERGED,2019-06-12T19:11:42Z,2019-06-20T10:40:43Z,suggest tuple struct syntax,Electron-libre,b72b1ac062a66819cd06a3f147486678e99b4f40,3,fix indentation,HEART,2019-06-14T20:23:29Z,estebank,NA https://github.com/rust-lang/rust/pull/61792,MERGED,2019-06-13T03:31:44Z,2019-06-14T06:46:34Z,Add ui test for issue 51301,tesuji,8a5e1eeee65dd6c5c592a34aa483f461c068e533,2,Add ui test for issue 51301,THUMBS_UP,2019-06-13T17:46:53Z,estebank,NA https://github.com/rust-lang/rust/pull/61797,MERGED,2019-06-13T10:25:16Z,2019-09-15T00:10:31Z,Stabilise weak_ptr_eq,Thomasdezeeuw,307804a00d191b6f15d1a1a5b98fbae5ea6593b0,2,Update {rc sync}::Weak::ptr_eq doc about comparing Weak::new,THUMBS_UP,2019-06-13T12:26:20Z,chpio,NA https://github.com/rust-lang/rust/pull/61802,MERGED,2019-06-13T13:59:12Z,2019-06-19T09:44:36Z,Make MaybeUninit #[repr(transparent)],mjbshaw,0f9dc6c48e51637a5d54fc791df94d104c1e0aee,2,Make MaybeUninit #[repr(transparent)] Tracking issue: #60405,THUMBS_UP,2019-08-13T11:47:29Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-06-14T18:59:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-06-14T19:51:41Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-06-16T22:24:51Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-06-25T07:39:14Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-07-01T01:19:03Z,estebank,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-07-06T19:59:55Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-08-17T09:35:52Z,mati865,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2019-10-16T18:07:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-01-05T00:25:10Z,varkor,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-01-16T13:39:29Z,jplatte,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-01-28T02:31:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-02-25T22:59:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-02-25T23:53:30Z,ehuss,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-02-26T13:05:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-02-26T15:13:31Z,M-Adoo,Adoo@outlook.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-03-05T19:45:47Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2020-03-06T02:26:44Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-03-06T03:55:05Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-03-06T04:34:37Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2020-03-06T19:15:38Z,rrbutani,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-03-06T19:15:38Z,rrbutani,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2020-03-07T11:49:43Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-04-20T19:28:32Z,MikeeyBikeey,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-08-21T04:12:52Z,95th,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2020-08-21T04:12:56Z,95th,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2020-12-10T20:58:15Z,gliderkite,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2021-08-28T11:46:28Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2021-08-28T11:46:29Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2021-09-10T18:03:49Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HOORAY,2021-09-19T15:15:45Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/61812,MERGED,2019-06-13T19:40:19Z,2020-02-26T12:50:07Z,Implement RFC 2532 – Associated Type Defaults,jonas-schievink,3a0d106109d73ed2e45a9925a9512ade2afb7df9,53,Auto merge of #61812 - jonas-schievink:assoc-ty-defaults r=nikomatsakis Implement RFC 2532 – Associated Type Defaults This is a partial implementation that is still missing the changes to object types since I ran into some trouble while implementing that. I'm opening this part already to get feedback on the implementation and the unexpected test fallout (see my comments below). The remaining changes can be done in a later PR. Blockers before this can land: * [x] Resolve unsoundness around interaction with specialization (https://github.com/rust-lang/rust/pull/61812#discussion_r300504010) - #64564 cc https://github.com/rust-lang/rust/issues/29661 Fixes #53907 Fixes #54182 Fixes #62211 Fixes #41868 Fixes #63593 Fixes #47385 Fixes #43924 Fixes #32350 Fixes #26681 Fixes https://github.com/rust-lang/rust/issues/67187,HEART,2021-09-19T15:15:46Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/61813,MERGED,2019-06-13T20:45:13Z,2019-06-15T21:16:09Z,Remove some unnecessary symbol interner ops,matthewjasper,5c84cd37cbfc16ef80bbad1f6416419d3cf06df6,2,Use `sym` constansts for `PrimitiveTypeTable` keys,HEART,2019-06-13T22:57:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-13T23:28:20Z,varkor,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-13T23:28:27Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-13T23:30:27Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-13T23:42:52Z,estebank,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T00:07:20Z,mati865,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T04:03:52Z,panaman67,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T05:57:42Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T11:04:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T12:31:52Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HOORAY,2019-06-14T15:44:49Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HOORAY,2019-06-14T16:12:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HEART,2019-06-14T17:03:35Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HOORAY,2019-06-14T17:03:36Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/61817,MERGED,2019-06-13T23:25:37Z,2019-06-14T19:07:39Z,Unify all uses of 'gcx and 'tcx.,eddyb,afc39bbf2447844569e872468f9440d430b81a46,107,Run `rustfmt --file-lines ...` for changes from previous commits.,HOORAY,2019-06-20T09:47:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61825,MERGED,2019-06-14T07:27:48Z,2019-06-15T06:33:58Z,type_alias_enum_variants: fix #61801; allow a path pattern to infer,Centril,065151f8b2c31d9e4ddd34aaf8d3263a997f5cfe,1,type_alias_enum_variants: add regression test for #61801.,THUMBS_UP,2019-06-14T12:39:31Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/61836,MERGED,2019-06-14T14:17:44Z,2019-06-18T02:17:50Z,Replace some uses of NodeId with HirId,ljedrz,e1bf56de25a78b3883822f82aeba0010c4a2fad7,1,remove superfluous space,HEART,2019-06-14T18:53:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61836,MERGED,2019-06-14T14:17:44Z,2019-06-18T02:17:50Z,Replace some uses of NodeId with HirId,ljedrz,e1bf56de25a78b3883822f82aeba0010c4a2fad7,1,remove superfluous space,HEART,2019-06-17T05:08:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/61839,MERGED,2019-06-14T15:35:22Z,2019-06-19T09:44:38Z,ci: Add a script for generating CPU usage graphs,alexcrichton,831ddf700d91b50ac8e3beffe35d7ee5f5dd5218,2,ci: Add a script for generating CPU usage graphs This commit checks in a script which generates CPU usage graphs over time expanding on the previous comment that was include in the collection file.,HEART,2019-06-17T20:53:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61839,MERGED,2019-06-14T15:35:22Z,2019-06-19T09:44:38Z,ci: Add a script for generating CPU usage graphs,alexcrichton,831ddf700d91b50ac8e3beffe35d7ee5f5dd5218,2,ci: Add a script for generating CPU usage graphs This commit checks in a script which generates CPU usage graphs over time expanding on the previous comment that was include in the collection file.,ROCKET,2019-06-17T20:53:21Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61845,CLOSED,2019-06-14T18:39:54Z,2019-12-29T12:20:06Z,[WIP] Use a sharded dep node to dep node index map,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-17T20:55:31Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61845,CLOSED,2019-06-14T18:39:54Z,2019-12-29T12:20:06Z,[WIP] Use a sharded dep node to dep node index map,Zoxc,NA,NA,NA,HOORAY,2019-06-17T20:55:37Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61845,CLOSED,2019-06-14T18:39:54Z,2019-12-29T12:20:06Z,[WIP] Use a sharded dep node to dep node index map,Zoxc,NA,NA,NA,HOORAY,2019-06-18T22:55:22Z,mati865,NA https://github.com/rust-lang/rust/pull/61856,MERGED,2019-06-15T01:31:26Z,2019-07-29T00:08:48Z,Lint attributes on function arguments,c410-f3r,53fc7fbc9606ba8b29e674ab08c3ccf1ebfd128d,28,Lint attributes on function arguments,HOORAY,2019-07-08T10:42:52Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61862,MERGED,2019-06-15T07:06:55Z,2019-07-07T01:14:22Z,Make the Weak::{into as}_raw methods,vorner,49fbd76a7667fba9dfbf283ca792a0dc66c9fb5b,2,Make the Weak::{into as}_raw methods Because Weak doesn't Deref so there's no reason for them to be only associated methods.,THUMBS_UP,2019-06-15T07:32:01Z,chpio,NA https://github.com/rust-lang/rust/pull/61862,MERGED,2019-06-15T07:06:55Z,2019-07-07T01:14:22Z,Make the Weak::{into as}_raw methods,vorner,49fbd76a7667fba9dfbf283ca792a0dc66c9fb5b,2,Make the Weak::{into as}_raw methods Because Weak doesn't Deref so there's no reason for them to be only associated methods.,THUMBS_UP,2019-06-15T09:24:50Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/61862,MERGED,2019-06-15T07:06:55Z,2019-07-07T01:14:22Z,Make the Weak::{into as}_raw methods,vorner,49fbd76a7667fba9dfbf283ca792a0dc66c9fb5b,2,Make the Weak::{into as}_raw methods Because Weak doesn't Deref so there's no reason for them to be only associated methods.,THUMBS_UP,2019-06-18T01:36:21Z,cramertj,NA https://github.com/rust-lang/rust/pull/61864,MERGED,2019-06-15T07:59:55Z,2019-06-18T08:12:36Z,Make use of `ptr::null(_mut)` instead of casting zero,tesuji,7d69d4ced23c446d6af341e3f9dc031a302150fc,33,Make use of `ptr::null(_mut)` instead of casting zero,THUMBS_UP,2019-06-16T19:10:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61866,MERGED,2019-06-15T11:34:23Z,2019-06-16T07:31:22Z,Remove redundant `clone()`s,sinkuu,6a0abd60486d7301dea849e7107bc92380e6045e,14,Remove unnecessary `.clone()`,THUMBS_UP,2019-06-15T12:16:43Z,tesuji,NA https://github.com/rust-lang/rust/pull/61866,MERGED,2019-06-15T11:34:23Z,2019-06-16T07:31:22Z,Remove redundant `clone()`s,sinkuu,6a0abd60486d7301dea849e7107bc92380e6045e,14,Remove unnecessary `.clone()`,THUMBS_UP,2019-06-15T12:31:33Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61866,MERGED,2019-06-15T11:34:23Z,2019-06-16T07:31:22Z,Remove redundant `clone()`s,sinkuu,6a0abd60486d7301dea849e7107bc92380e6045e,14,Remove unnecessary `.clone()`,THUMBS_UP,2019-06-19T17:00:57Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-15T22:16:10Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-16T03:25:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-16T11:51:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-16T13:03:21Z,mati865,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-16T16:29:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-17T05:04:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T13:53:24Z,galich,sergey.galich@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T17:40:25Z,DCjanus,DCjanus@dcjanus.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T20:08:55Z,erikjohnston,github@jki.re https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T20:09:49Z,rjsberry,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T20:43:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T22:59:56Z,sachaarbonel,sacha.arbonel@hotmail.fr https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-18T23:14:07Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-19T05:36:00Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-20T10:00:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-20T10:03:26Z,lqd,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-20T16:27:54Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-20T21:26:25Z,darksv,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-21T12:14:39Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-22T11:13:04Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-22T20:58:55Z,davidbarsky,me@davidbarsky.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-22T22:06:48Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-24T12:36:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-24T13:59:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-24T23:31:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-26T03:06:12Z,G11Max,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-26T04:39:10Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-26T16:17:44Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-06-26T20:11:54Z,theduke,NA https://github.com/rust-lang/rust/pull/61872,MERGED,2019-06-15T19:52:13Z,2019-06-26T07:24:49Z,Clean up MIR drop generation,matthewjasper,3131427784b2c9f906a50b290f7d3cc215d0c0e8,5,Use `Local`s instead of `Place`s in MIR drop generation,HEART,2019-07-04T13:41:38Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61877,CLOSED,2019-06-15T21:52:32Z,2019-06-23T20:10:37Z,Fix imports of built-in macros (mostly),petrochenkov,NA,NA,NA,HOORAY,2019-06-15T21:54:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61878,MERGED,2019-06-15T22:05:57Z,2019-06-28T17:35:05Z,improve pinning projection docs,RalfJung,bf03a3c539c30f518ca66dcd8ad3890a8b414d15,1,nits,THUMBS_UP,2019-06-15T23:45:27Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/61878,MERGED,2019-06-15T22:05:57Z,2019-06-28T17:35:05Z,improve pinning projection docs,RalfJung,bf03a3c539c30f518ca66dcd8ad3890a8b414d15,1,nits,THUMBS_UP,2019-06-16T12:40:00Z,mzabaluev,mikhail.zabaluev@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-06-15T23:41:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-06-16T03:23:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-06-17T05:03:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-06-19T11:00:26Z,orium,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HEART,2019-06-21T08:03:04Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T00:51:07Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T01:30:05Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T05:37:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T07:17:58Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T10:40:06Z,Kvikal,g4rrus@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T10:43:25Z,Yura52,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-04T14:11:04Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HEART,2019-07-04T14:43:40Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-04T16:33:15Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-04T17:35:19Z,delacian,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-07T21:47:41Z,flosse,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-08T09:17:27Z,AregevDev,aregevdev@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-10T08:00:34Z,Fuzen-py,me@fuzen.cafe https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-10T12:20:31Z,Boiethios,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-10T12:52:40Z,BuggStream,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-10T17:20:09Z,rov-man,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-07-11T21:00:29Z,totorigolo,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-17T10:26:23Z,jesskfullwood,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-18T21:48:01Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HEART,2019-07-18T21:48:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-28T06:11:50Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-07-28T17:38:16Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-08-29T12:13:53Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-10-10T20:53:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-10-11T02:56:38Z,busyluo,2488091@qq.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HOORAY,2019-10-11T05:30:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-10-11T16:59:30Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,CONFUSED,2019-11-03T10:56:18Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/61879,MERGED,2019-06-15T23:26:29Z,2019-10-04T03:36:11Z,Stabilize todo macro,NA,NA,NA,NA,HEART,2019-12-09T06:28:15Z,xasopheno,danny@xasopheno.com https://github.com/rust-lang/rust/pull/61883,MERGED,2019-06-16T03:35:26Z,2019-07-07T18:32:05Z,`non_ascii_idents` lint (part of RFC 2457),zackmdavis,6de8e39e2612305cef4e2d8ef3eca296294d01b5,4,"in which the `non_ascii_idents` lint appears (RFC 2457) RFC 2457 declares: ""A `non_ascii_idents` lint is added to the compiler. This lint is allow by default.""",ROCKET,2019-06-21T19:12:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-06-16T05:59:33Z,est31,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-06-16T19:02:01Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-06-17T20:42:17Z,anirudhb,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-06-17T21:00:50Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-07-10T00:56:52Z,richli,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-07-17T17:16:29Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-07-24T17:02:59Z,delacian,NA https://github.com/rust-lang/rust/pull/61884,MERGED,2019-06-16T03:36:58Z,2019-07-26T02:18:08Z,Stablize Euclidean Modulo (feature euclidean_division),crlf0710,72ac8ce9aa50d4456239755076a5dd869232006e,4,Stablize Euclidean Modulo (feature euclidean_division),HOORAY,2019-09-26T14:34:25Z,CGMossa,NA https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-16T08:16:46Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-16T08:39:32Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-16T09:41:46Z,CryZe,NA https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-17T05:02:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-17T09:50:17Z,mati865,NA https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-17T21:04:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61885,MERGED,2019-06-16T04:00:59Z,2019-06-18T02:17:55Z,Help LLVM better optimize slice::Iter(Mut)::len,scottmcm,af0e35e6a6837aba121c873e6f91fff6df61d268,3,Help LLVM better optimize slice::Iter(Mut)::len,HEART,2019-06-27T12:05:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61890,MERGED,2019-06-16T11:40:41Z,2019-07-26T02:18:09Z,Fix some sanity checks,golddranks,f78cd4de454c4b55c95137f2db07b4f36b86c3af,1,Fix building_llvm in sanity check add swig sanity check.,HEART,2019-06-17T05:02:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/61891,MERGED,2019-06-16T11:54:39Z,2019-06-18T21:51:21Z,rustc: remove 'x: 'y bounds (except where necessary or from comments/strings).,eddyb,2be847b2f95414690538bea48138a6738b47b43a,2,test: normalize away the line/column info in ui/pattern/const-pat-ice.,HEART,2019-06-16T18:14:54Z,mati865,NA https://github.com/rust-lang/rust/pull/61891,MERGED,2019-06-16T11:54:39Z,2019-06-18T21:51:21Z,rustc: remove 'x: 'y bounds (except where necessary or from comments/strings).,eddyb,2be847b2f95414690538bea48138a6738b47b43a,2,test: normalize away the line/column info in ui/pattern/const-pat-ice.,HEART,2019-06-16T19:07:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61891,MERGED,2019-06-16T11:54:39Z,2019-06-18T21:51:21Z,rustc: remove 'x: 'y bounds (except where necessary or from comments/strings).,eddyb,2be847b2f95414690538bea48138a6738b47b43a,2,test: normalize away the line/column info in ui/pattern/const-pat-ice.,HEART,2019-06-17T16:56:44Z,estebank,NA https://github.com/rust-lang/rust/pull/61891,MERGED,2019-06-16T11:54:39Z,2019-06-18T21:51:21Z,rustc: remove 'x: 'y bounds (except where necessary or from comments/strings).,eddyb,2be847b2f95414690538bea48138a6738b47b43a,2,test: normalize away the line/column info in ui/pattern/const-pat-ice.,HEART,2019-06-18T18:03:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-16T14:17:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-16T16:08:41Z,bjorn3,NA https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-16T17:14:43Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-16T19:09:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-17T20:31:25Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-19T16:57:06Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2019-06-27T15:31:52Z,breezewish,breezewish@pingcap.com https://github.com/rust-lang/rust/pull/61892,MERGED,2019-06-16T12:03:45Z,2019-06-17T02:08:46Z,weird-exprs: if if if if,rijenkii,7c84efddc4a756272eabfe79de826a30849ccd2f,1,if if if if,LAUGH,2020-08-24T01:57:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,HEART,2019-06-16T15:51:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,HEART,2019-06-16T16:54:43Z,tesuji,NA https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,THUMBS_UP,2019-06-16T22:54:12Z,varkor,NA https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,HEART,2019-06-17T05:01:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,THUMBS_UP,2019-06-17T05:01:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,THUMBS_UP,2019-06-18T23:01:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61896,MERGED,2019-06-16T15:21:44Z,2019-06-19T09:44:43Z,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,eddyb,dedf2eda8f6d062da91c80a8980b3b794f5c876e,7,rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`.,THUMBS_UP,2019-06-19T22:01:37Z,estebank,NA https://github.com/rust-lang/rust/pull/61897,CLOSED,2019-06-16T18:32:06Z,2019-06-19T05:55:54Z,[do not merge] Test parallel compiler #2,Zoxc,NA,NA,NA,ROCKET,2019-06-16T19:09:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61897,CLOSED,2019-06-16T18:32:06Z,2019-06-19T05:55:54Z,[do not merge] Test parallel compiler #2,Zoxc,NA,NA,NA,ROCKET,2019-06-16T20:26:14Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61897,CLOSED,2019-06-16T18:32:06Z,2019-06-19T05:55:54Z,[do not merge] Test parallel compiler #2,Zoxc,NA,NA,NA,ROCKET,2019-06-17T09:35:35Z,mati865,NA https://github.com/rust-lang/rust/pull/61897,CLOSED,2019-06-16T18:32:06Z,2019-06-19T05:55:54Z,[do not merge] Test parallel compiler #2,Zoxc,NA,NA,NA,ROCKET,2019-06-17T21:06:20Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/61898,MERGED,2019-06-16T19:05:36Z,2019-06-19T09:44:44Z,syntax: Factor out common fields from `SyntaxExtension` variants,petrochenkov,e152554e11ff44b1a08e21a8416e1fc18504764e,3,resolve/expand: Move expansion info setting to a single earlier point,HOORAY,2019-06-17T06:07:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-06-18T13:44:51Z,bstrie,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-06-21T16:56:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-06-22T22:27:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-06-24T19:51:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-06-25T14:03:49Z,kellytk,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-07-02T16:00:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-07-03T08:52:27Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-07-15T15:31:51Z,estebank,NA https://github.com/rust-lang/rust/pull/61922,MERGED,2019-06-18T02:12:54Z,2019-07-02T15:54:32Z,Don't store locals that have been moved from in generators,tmandry,a68e2c716113d4f7a10a149cc13b18b851853000,3,Clean up extra lifetime add assertions,HOORAY,2019-08-15T09:21:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T05:34:22Z,XVilka,xvilka@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T05:36:15Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T09:39:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T15:27:54Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T16:04:16Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T16:22:57Z,sstangl,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T16:33:43Z,hbowden,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T16:35:45Z,Austinh100,austin.1111h@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T16:38:13Z,edwarde-astranis,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T16:42:49Z,leonardinius,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T16:42:54Z,leonardinius,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T16:49:27Z,arkorobotics,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T16:49:28Z,arkorobotics,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T19:08:39Z,photex,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T19:08:42Z,photex,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T19:09:58Z,XavierT,sseingalt@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T19:10:02Z,XavierT,sseingalt@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-19T21:31:32Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T22:41:46Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-19T22:48:49Z,yerke,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-20T02:23:57Z,green-s,sam.green81@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-20T02:43:10Z,nsmryan,nsmryan@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-20T03:39:33Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-20T20:06:38Z,dunielpls,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-21T09:54:15Z,g-plane,g-plane@hotmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-06-27T04:14:45Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-06-27T04:14:46Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-07-15T21:24:59Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-07-16T23:08:51Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-07-20T22:15:17Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-10-09T23:00:41Z,kellpossible,l.frisken@gmail.com https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-10-10T21:02:05Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,HEART,2019-10-10T21:02:06Z,DianaNites,NA https://github.com/rust-lang/rust/pull/61946,MERGED,2019-06-19T00:33:16Z,2019-07-16T23:05:27Z,port rust for vxWorks,BaoshanPang,4c0c0f6158b464ee5070b32bb37f2863d0eff012,69,Add supporting for vxWorks r? @alexcrichton,THUMBS_UP,2019-11-01T14:53:29Z,iincity,NA https://github.com/rust-lang/rust/pull/61947,MERGED,2019-06-19T01:42:51Z,2019-06-20T01:26:10Z, Fix ICE involving mut references,estebank,8a415d145a935959d7415c16ea660d4b9dceabf0,1,review comment,THUMBS_UP,2019-06-20T01:31:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/61948,MERGED,2019-06-19T03:42:26Z,2019-06-21T06:08:26Z,Update mdbook,ehuss,2dafa91310354fdca43211434878b329c0535f46,10,Update mdbook,HOORAY,2019-06-19T07:19:48Z,mati865,NA https://github.com/rust-lang/rust/pull/61948,MERGED,2019-06-19T03:42:26Z,2019-06-21T06:08:26Z,Update mdbook,ehuss,2dafa91310354fdca43211434878b329c0535f46,10,Update mdbook,HOORAY,2019-06-19T18:08:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61948,MERGED,2019-06-19T03:42:26Z,2019-06-21T06:08:26Z,Update mdbook,ehuss,2dafa91310354fdca43211434878b329c0535f46,10,Update mdbook,HEART,2019-06-19T18:08:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61953,MERGED,2019-06-19T10:17:03Z,2019-07-13T10:16:05Z,Add `impl FromIterator for Arc/Rc<[T]>`,Centril,85def307fc83f8c0d164b1506bb855dfaed5f8b5,3,shared_from_iter: Polish internal docs.,THUMBS_UP,2019-09-27T00:03:09Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/61968,MERGED,2019-06-19T18:28:00Z,2019-06-20T10:40:51Z,rustc: disallow cloning HIR nodes.,eddyb,673c3fc23ad0c78fe26420b641957e4fdfea553b,12,rustc: disallow cloning HIR nodes.,HEART,2019-06-19T19:00:21Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61968,MERGED,2019-06-19T18:28:00Z,2019-06-20T10:40:51Z,rustc: disallow cloning HIR nodes.,eddyb,673c3fc23ad0c78fe26420b641957e4fdfea553b,12,rustc: disallow cloning HIR nodes.,HEART,2019-06-19T19:02:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/61968,MERGED,2019-06-19T18:28:00Z,2019-06-20T10:40:51Z,rustc: disallow cloning HIR nodes.,eddyb,673c3fc23ad0c78fe26420b641957e4fdfea553b,12,rustc: disallow cloning HIR nodes.,HEART,2019-06-19T21:33:32Z,estebank,NA https://github.com/rust-lang/rust/pull/61968,MERGED,2019-06-19T18:28:00Z,2019-06-20T10:40:51Z,rustc: disallow cloning HIR nodes.,eddyb,673c3fc23ad0c78fe26420b641957e4fdfea553b,12,rustc: disallow cloning HIR nodes.,HEART,2019-06-19T21:35:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/61968,MERGED,2019-06-19T18:28:00Z,2019-06-20T10:40:51Z,rustc: disallow cloning HIR nodes.,eddyb,673c3fc23ad0c78fe26420b641957e4fdfea553b,12,rustc: disallow cloning HIR nodes.,HEART,2019-06-20T07:47:12Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/61976,CLOSED,2019-06-19T22:25:05Z,2019-08-18T22:18:36Z,Add Mutex::with,jsgf,NA,NA,NA,ROCKET,2019-06-19T23:38:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61984,MERGED,2019-06-20T09:36:00Z,2019-06-22T05:07:00Z,More NodeId pruning,ljedrz,0a511cce79c41eeddbdc0623581e61872f97793c,3,revert the NodeId to HirId parameter change to get_path_res,HOORAY,2019-06-20T10:33:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/61984,MERGED,2019-06-20T09:36:00Z,2019-06-22T05:07:00Z,More NodeId pruning,ljedrz,0a511cce79c41eeddbdc0623581e61872f97793c,3,revert the NodeId to HirId parameter change to get_path_res,HOORAY,2019-06-20T13:29:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/61984,MERGED,2019-06-20T09:36:00Z,2019-06-22T05:07:00Z,More NodeId pruning,ljedrz,0a511cce79c41eeddbdc0623581e61872f97793c,3,revert the NodeId to HirId parameter change to get_path_res,HEART,2019-06-20T13:29:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/61987,MERGED,2019-06-20T12:13:23Z,2019-06-25T21:27:14Z,rustc: produce AST instead of HIR from `hir::lowering::Resolver` methods.,eddyb,e6ee8a0d44fcedb583067bbaf36bcdf325029cdd,3,rustc: produce AST instead of HIR from `hir::lowering::Resolver` methods.,THUMBS_UP,2019-06-20T16:05:45Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-20T13:28:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-20T16:27:29Z,ljedrz,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-21T10:11:26Z,mati865,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-21T19:08:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-22T22:07:58Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-06-26T16:53:44Z,jplatte,NA https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-07-10T13:39:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-07-10T14:15:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/61988,MERGED,2019-06-20T12:29:17Z,2019-07-06T09:38:42Z,[let_chains 3/6] And then there was only Loop,Centril,9b1d513e47b22180f5b73f64bb97ef7390efe7a0,1,#NAME?,HEART,2019-08-09T21:37:53Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/62004,CLOSED,2019-06-20T19:29:49Z,2019-08-07T17:50:00Z,Account for associated type const and static when using type argument,estebank,NA,NA,NA,THUMBS_UP,2019-06-30T21:55:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62008,MERGED,2019-06-20T22:00:06Z,2019-07-20T06:19:15Z,Add meta-variable checks in macro definitions,ia0,6ec4584d8482f51249d78efc340aaead76251859,16,Implement checks for meta-variables in macros,HOORAY,2019-06-21T02:13:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62008,MERGED,2019-06-20T22:00:06Z,2019-07-20T06:19:15Z,Add meta-variable checks in macro definitions,ia0,6ec4584d8482f51249d78efc340aaead76251859,16,Implement checks for meta-variables in macros,HOORAY,2019-06-21T09:45:42Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62008,MERGED,2019-06-20T22:00:06Z,2019-07-20T06:19:15Z,Add meta-variable checks in macro definitions,ia0,6ec4584d8482f51249d78efc340aaead76251859,16,Implement checks for meta-variables in macros,HOORAY,2019-07-06T14:49:19Z,est31,NA https://github.com/rust-lang/rust/pull/62008,MERGED,2019-06-20T22:00:06Z,2019-07-20T06:19:15Z,Add meta-variable checks in macro definitions,ia0,6ec4584d8482f51249d78efc340aaead76251859,16,Implement checks for meta-variables in macros,HOORAY,2019-07-25T03:30:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62019,MERGED,2019-06-21T09:39:58Z,2019-06-22T05:07:04Z,Remove needless lifetimes,jeremystucki,004efa27059441651b240ee1a408d40f420413f8,6,Remove needless lifetimes,HEART,2019-06-21T13:43:04Z,panaman67,NA https://github.com/rust-lang/rust/pull/62026,MERGED,2019-06-21T11:51:40Z,2019-07-08T01:33:12Z,Final nail in `rand 0.4` coffin,mati865,2ac20e2be6ce75dbf5e95aa0078c758c35e0c0e9,1,Update phf to get rid of rand 0.4,HEART,2019-06-21T13:41:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/62026,MERGED,2019-06-21T11:51:40Z,2019-07-08T01:33:12Z,Final nail in `rand 0.4` coffin,mati865,2ac20e2be6ce75dbf5e95aa0078c758c35e0c0e9,1,Update phf to get rid of rand 0.4,HOORAY,2019-06-22T10:38:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62026,MERGED,2019-06-21T11:51:40Z,2019-07-08T01:33:12Z,Final nail in `rand 0.4` coffin,mati865,2ac20e2be6ce75dbf5e95aa0078c758c35e0c0e9,1,Update phf to get rid of rand 0.4,HOORAY,2019-07-01T12:58:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/62026,MERGED,2019-06-21T11:51:40Z,2019-07-08T01:33:12Z,Final nail in `rand 0.4` coffin,mati865,2ac20e2be6ce75dbf5e95aa0078c758c35e0c0e9,1,Update phf to get rid of rand 0.4,HOORAY,2019-07-08T01:36:05Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62026,MERGED,2019-06-21T11:51:40Z,2019-07-08T01:33:12Z,Final nail in `rand 0.4` coffin,mati865,2ac20e2be6ce75dbf5e95aa0078c758c35e0c0e9,1,Update phf to get rid of rand 0.4,HOORAY,2019-07-08T01:50:43Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,THUMBS_UP,2019-06-21T21:36:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,HOORAY,2019-06-22T07:03:34Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,THUMBS_UP,2019-06-23T01:18:14Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,THUMBS_UP,2019-06-23T11:19:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,HOORAY,2019-06-23T11:19:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,THUMBS_UP,2019-06-23T21:04:58Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/62037,MERGED,2019-06-21T21:23:56Z,2019-06-23T22:51:35Z,Speed up tidy,Mark-Simulacrum,777951c926820cc20f0047d49091c37e0fbff14e,1,Exit early from feature search if no features in file,THUMBS_UP,2019-06-25T17:33:55Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-22T01:05:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HEART,2019-06-22T01:05:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HEART,2019-06-22T15:10:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-22T15:10:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-23T10:26:20Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HEART,2019-06-23T10:26:21Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HEART,2019-06-24T10:39:53Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-24T17:02:16Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-24T22:39:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-06-24T23:10:50Z,jseyfried,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-07-06T03:23:39Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-07-10T03:07:29Z,DianaNites,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HEART,2019-07-10T03:07:30Z,DianaNites,NA https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-07-10T07:38:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62042,MERGED,2019-06-22T00:46:51Z,2019-07-07T18:32:10Z,Support stability and deprecation checking for all macros,petrochenkov,941653b528deb96d5ed13935143db14c45d99d6e,5,Address review comments + Fix rebase,HOORAY,2019-07-10T13:46:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-06-22T15:10:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-06-22T21:32:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-06-23T10:27:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-06-28T19:40:19Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-06-30T12:03:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HEART,2019-07-04T00:27:43Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,THUMBS_UP,2019-07-04T00:46:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,THUMBS_UP,2019-07-04T01:39:47Z,benhansenslc,github@benjamin-hansen.com https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HOORAY,2019-07-04T04:51:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HOORAY,2019-07-04T07:59:46Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HOORAY,2019-07-04T08:52:51Z,torkleyy,me@torkleyy.com https://github.com/rust-lang/rust/pull/62043,MERGED,2019-06-22T05:11:27Z,2019-06-28T17:35:12Z,Remove `FnBox`,Centril,a99a7b7f35e3b30862058cc28ed4b0cf51638cf4,5,Remove FnBox.,HOORAY,2019-07-04T13:40:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62067,MERGED,2019-06-22T22:39:26Z,2019-06-28T17:35:13Z,Add suggestion for missing `.await` keyword,doctorn,88194200e57c90ba0fa7b725d63ff4de28e71bbb,9,Add suggestion for missing `.await` keyword,HEART,2019-08-28T23:25:22Z,estebank,NA https://github.com/rust-lang/rust/pull/62068,MERGED,2019-06-22T23:33:09Z,2019-06-23T03:09:49Z,Fix meta-variable binding errors in macros,ia0,b8106b59d2faaea57301ad000d7787b70c5b2985,16,Fix meta-variable binding errors in macros The errors are either: - The meta-variable used in the right-hand side is not bound (or defined) in the left-hand side. - The meta-variable used in the right-hand side does not repeat with the same kleene operator as its binder in the left-hand side. Either it does not repeat enough or it uses a different operator somewhere. This change should have no semantic impact.,THUMBS_UP,2019-06-22T23:56:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62070,MERGED,2019-06-23T00:00:22Z,2019-06-24T01:53:53Z,Run rustfmt on some libsyntax files,ia0,0aeab41e5a814c96c6a6d7a7e6f7ff3f8e741648,2,Run rustfmt,THUMBS_UP,2019-06-23T00:01:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,LAUGH,2019-06-23T08:10:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-23T10:08:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,HEART,2019-06-23T13:37:44Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,ROCKET,2019-06-23T13:37:46Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-23T13:37:49Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-23T15:34:44Z,cynecx,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-23T19:19:02Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,THUMBS_UP,2019-06-23T21:19:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,HEART,2019-06-23T21:19:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/62073,CLOSED,2019-06-23T07:48:29Z,2019-06-24T23:34:01Z,[do not merge] Test mimalloc,Zoxc,NA,NA,NA,HEART,2019-06-24T09:15:30Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/62076,MERGED,2019-06-23T09:48:43Z,2019-06-28T17:35:14Z,Updated RELEASES.md for 1.36.0,XAMPPRocky,0f34d7a7e5f068683097e0e664249bd6a417032f,1,Updated RELEASES.md for 1.36.0 Co-Authored-By: Taiki Endo Co-Authored-By: Jonas Schievink Co-Authored-By: Torbjørn Birch Moltu ,HEART,2019-06-26T12:04:01Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62077,CLOSED,2019-06-23T12:21:55Z,2019-07-14T12:24:41Z,Deprecate `try!` macro,NA,NA,NA,NA,THUMBS_UP,2019-06-23T19:23:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62077,CLOSED,2019-06-23T12:21:55Z,2019-07-14T12:24:41Z,Deprecate `try!` macro,NA,NA,NA,NA,THUMBS_UP,2019-07-06T03:23:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62077,CLOSED,2019-06-23T12:21:55Z,2019-07-14T12:24:41Z,Deprecate `try!` macro,NA,NA,NA,NA,THUMBS_UP,2019-07-08T06:35:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62081,MERGED,2019-06-23T16:04:33Z,2019-06-24T20:39:12Z,Refactor miri pointer checks,RalfJung,7e830286c7a0c19e57d1a09e9a0bde7933f68bb6,1,fix reoccurring typo,THUMBS_UP,2019-06-24T10:34:45Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/62081,MERGED,2019-06-23T16:04:33Z,2019-06-24T20:39:12Z,Refactor miri pointer checks,RalfJung,7e830286c7a0c19e57d1a09e9a0bde7933f68bb6,1,fix reoccurring typo,THUMBS_UP,2019-06-27T11:35:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-06-28T03:36:12Z,sinkuu,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-06-30T21:53:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-10T07:52:07Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-13T17:20:45Z,estebank,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-18T11:49:43Z,mati865,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-20T19:39:28Z,est31,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-25T02:13:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/62086,MERGED,2019-06-23T20:08:47Z,2019-07-27T03:14:19Z,Define built-in macros through libcore,petrochenkov,8eaf17bca2674293eba0ea10056d5c77b6352086,46,Introduce built-in macros through libcore,HOORAY,2019-07-27T10:52:02Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/62090,MERGED,2019-06-24T08:19:10Z,2019-07-09T06:20:30Z,typeck: merge opaque type inference logic,davidtwco,de8660ab610f046bbdeb1a90f2c94cba1d3d3185,8,typeck: merge opaque type inference logic This commit merges the logic used for opaque type type inference for impl Trait and non-impl Trait cases. This fixes an ICE where existential types used in the return types of functions would be allowed to have an out-of-scope generic type parameter.,HOORAY,2019-06-24T08:31:11Z,denzp,NA https://github.com/rust-lang/rust/pull/62090,MERGED,2019-06-24T08:19:10Z,2019-07-09T06:20:30Z,typeck: merge opaque type inference logic,davidtwco,de8660ab610f046bbdeb1a90f2c94cba1d3d3185,8,typeck: merge opaque type inference logic This commit merges the logic used for opaque type type inference for impl Trait and non-impl Trait cases. This fixes an ICE where existential types used in the return types of functions would be allowed to have an out-of-scope generic type parameter.,HOORAY,2019-06-24T16:42:33Z,cramertj,NA https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,HEART,2019-06-24T13:48:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,HEART,2019-06-24T17:14:29Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,THUMBS_UP,2019-06-24T17:14:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,HEART,2019-06-24T19:53:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,THUMBS_UP,2019-06-25T04:50:33Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,THUMBS_UP,2019-06-25T06:49:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62091,MERGED,2019-06-24T09:25:08Z,2019-06-25T21:27:22Z,HirIdification: almost there,ljedrz,87438a163ec153e2322b70e8c5c987c7c89be0b4,2,HirIdification: miscellaneous bits,HEART,2019-06-25T06:49:14Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62096,MERGED,2019-06-24T15:48:32Z,2019-06-25T21:27:23Z,Implement From for Place and PlaceBase,spastorino,099f9e4e8aac3968888636e2126c4b7f8e6bb2d3,32,Implement From for Place and PlaceBase,HOORAY,2019-06-24T15:49:34Z,pvdrz,NA https://github.com/rust-lang/rust/pull/62096,MERGED,2019-06-24T15:48:32Z,2019-06-25T21:27:23Z,Implement From for Place and PlaceBase,spastorino,099f9e4e8aac3968888636e2126c4b7f8e6bb2d3,32,Implement From for Place and PlaceBase,HOORAY,2019-06-24T16:42:46Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62096,MERGED,2019-06-24T15:48:32Z,2019-06-25T21:27:23Z,Implement From for Place and PlaceBase,spastorino,099f9e4e8aac3968888636e2126c4b7f8e6bb2d3,32,Implement From for Place and PlaceBase,HOORAY,2019-06-24T19:54:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62096,MERGED,2019-06-24T15:48:32Z,2019-06-25T21:27:23Z,Implement From for Place and PlaceBase,spastorino,099f9e4e8aac3968888636e2126c4b7f8e6bb2d3,32,Implement From for Place and PlaceBase,HOORAY,2019-06-25T02:29:03Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/62096,MERGED,2019-06-24T15:48:32Z,2019-06-25T21:27:23Z,Implement From for Place and PlaceBase,spastorino,099f9e4e8aac3968888636e2126c4b7f8e6bb2d3,32,Implement From for Place and PlaceBase,HOORAY,2019-06-25T14:08:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/62098,CLOSED,2019-06-24T18:20:32Z,2019-06-25T12:53:51Z,Cleanup to syntax::print/rustc::hir::print,Mark-Simulacrum,NA,NA,NA,HEART,2019-06-24T19:15:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/62098,CLOSED,2019-06-24T18:20:32Z,2019-06-25T12:53:51Z,Cleanup to syntax::print/rustc::hir::print,Mark-Simulacrum,NA,NA,NA,HEART,2019-06-25T11:41:39Z,mati865,NA https://github.com/rust-lang/rust/pull/62099,MERGED,2019-06-24T18:53:51Z,2019-07-05T10:10:20Z,Remove io::Result from syntax::print,Mark-Simulacrum,d26c4b7bd6e5905280dd4441482331fb9fb65e07,1,Inline rust_printer,HEART,2019-06-25T11:47:39Z,mati865,NA https://github.com/rust-lang/rust/pull/62099,MERGED,2019-06-24T18:53:51Z,2019-07-05T10:10:20Z,Remove io::Result from syntax::print,Mark-Simulacrum,d26c4b7bd6e5905280dd4441482331fb9fb65e07,1,Inline rust_printer,HEART,2019-07-05T07:11:58Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62100,MERGED,2019-06-24T18:58:35Z,2019-06-25T02:17:50Z,Update cargo,ehuss,342fa2be25903dab423c05a93782a80d94a8547c,2,Update cargo,HEART,2019-06-24T19:10:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/62102,MERGED,2019-06-24T20:59:32Z,2019-06-28T17:35:16Z,call out explicitly that general read needs to be called with an initialized buffer,RalfJung,390f717a0af5851271792da9ff235c95f3db2556,1,tweak wording,THUMBS_UP,2020-12-25T18:41:14Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/62103,MERGED,2019-06-24T21:20:02Z,2019-07-16T08:39:06Z,Add debug assertions to write_bytes and copy*,RalfJung,85d76a1b481dfabf49a1dead04996705f0d489d1,1,bump compiler_builtins,HEART,2019-07-06T08:32:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62103,MERGED,2019-06-24T21:20:02Z,2019-07-16T08:39:06Z,Add debug assertions to write_bytes and copy*,RalfJung,85d76a1b481dfabf49a1dead04996705f0d489d1,1,bump compiler_builtins,HEART,2019-07-07T12:15:25Z,mati865,NA https://github.com/rust-lang/rust/pull/62106,MERGED,2019-06-25T00:50:28Z,2019-06-28T17:35:17Z,Add more tests for async/await,cramertj,ba12e7862c58df2155011bb165a8ae1186828bc4,8,Add more tests for async/await,HOORAY,2019-06-25T15:30:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62113,CLOSED,2019-06-25T09:24:32Z,2019-09-11T09:30:03Z,Failure is not an option,Centril,NA,NA,NA,LAUGH,2019-06-25T10:17:31Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62113,CLOSED,2019-06-25T09:24:32Z,2019-09-11T09:30:03Z,Failure is not an option,Centril,NA,NA,NA,LAUGH,2019-06-25T11:33:19Z,mati865,NA https://github.com/rust-lang/rust/pull/62113,CLOSED,2019-06-25T09:24:32Z,2019-09-11T09:30:03Z,Failure is not an option,Centril,NA,NA,NA,LAUGH,2019-06-25T15:24:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62113,CLOSED,2019-06-25T09:24:32Z,2019-09-11T09:30:03Z,Failure is not an option,Centril,NA,NA,NA,LAUGH,2019-06-25T15:39:23Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62113,CLOSED,2019-06-25T09:24:32Z,2019-09-11T09:30:03Z,Failure is not an option,Centril,NA,NA,NA,LAUGH,2019-06-26T02:30:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62123,MERGED,2019-06-25T17:45:09Z,2019-07-05T15:31:01Z, Remove needless lifetimes (std),jeremystucki,fc67e5774df2ca5d5fdcf78835983b8c2ddb134d,1,Add missing lifetime specifier Co-Authored-By: Mazdak Farrokhzad ,THUMBS_UP,2019-06-25T19:02:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/62131,MERGED,2019-06-25T21:51:23Z,2019-06-28T17:35:19Z,libsyntax: Fix some Clippy warnings,Xanewok,ad62b4203ce3f0bd4c7c348aeabca4f49d5ce075,1,Fix clippy::precedence,HEART,2019-06-26T05:50:38Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62145,MERGED,2019-06-26T09:20:01Z,2019-06-27T12:20:55Z,ci: Sync AppVeyor/Travis with Azure configuration,alexcrichton,db4f2367eefe4b43c2a56d342fb7c5e07a0082d3,1,ci: Sync AppVeyor/Travis with Azure configuration Manually make sure that we do the same thing across all the services uncovering one spot where we needed to pass one more configure flag on Azure but otherwise we're good to go!,ROCKET,2019-06-26T10:07:24Z,mati865,NA https://github.com/rust-lang/rust/pull/62150,MERGED,2019-06-26T11:57:03Z,2019-07-05T15:31:02Z,Implement mem::{zeroed uninitialized} in terms of MaybeUninit.,alex,e4f250e405046713ba6fbcf481d0a88f26d25ae8,7,Implement mem::{zeroed uninitialized} in terms of MaybeUninit. Refs #62061,HEART,2019-06-26T13:44:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/62150,MERGED,2019-06-26T11:57:03Z,2019-07-05T15:31:02Z,Implement mem::{zeroed uninitialized} in terms of MaybeUninit.,alex,e4f250e405046713ba6fbcf481d0a88f26d25ae8,7,Implement mem::{zeroed uninitialized} in terms of MaybeUninit. Refs #62061,HEART,2019-07-10T04:36:26Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62150,MERGED,2019-06-26T11:57:03Z,2019-07-05T15:31:02Z,Implement mem::{zeroed uninitialized} in terms of MaybeUninit.,alex,e4f250e405046713ba6fbcf481d0a88f26d25ae8,7,Implement mem::{zeroed uninitialized} in terms of MaybeUninit. Refs #62061,HEART,2019-07-10T13:47:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62152,MERGED,2019-06-26T12:54:30Z,2019-06-28T17:35:21Z,Don't ICE on item in `.await` expression,doctorn,5cb841d72e70f92fc4318833db4824d07ab4c911,7,Don't ICE on item in `.await` expression,THUMBS_UP,2019-06-26T14:08:51Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/62152,MERGED,2019-06-26T12:54:30Z,2019-06-28T17:35:21Z,Don't ICE on item in `.await` expression,doctorn,5cb841d72e70f92fc4318833db4824d07ab4c911,7,Don't ICE on item in `.await` expression,THUMBS_UP,2019-06-26T15:54:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/62152,MERGED,2019-06-26T12:54:30Z,2019-06-28T17:35:21Z,Don't ICE on item in `.await` expression,doctorn,5cb841d72e70f92fc4318833db4824d07ab4c911,7,Don't ICE on item in `.await` expression,THUMBS_UP,2019-06-27T08:07:07Z,Aloxaf,bailong104@gmail.com https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T08:12:39Z,sinkuu,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T08:35:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T10:41:14Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T11:23:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T11:24:45Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-27T13:27:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HEART,2019-06-27T13:27:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-28T11:38:24Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-29T15:40:08Z,fabric-and-ink,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-29T19:08:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-06-30T21:48:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HOORAY,2019-07-03T07:48:58Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62168,MERGED,2019-06-27T08:10:56Z,2019-07-05T21:52:38Z,The (almost) culmination of HirIdification,ljedrz,a6030ff699e24a2d8f09bfd833361f119a9f0633,1,infer: fix a Region-related debug message,HEART,2019-07-03T07:48:59Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-27T12:46:24Z,mati865,NA https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-27T13:10:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-27T13:17:36Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-27T14:35:08Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-27T20:25:15Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-28T03:05:12Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-06-28T10:58:27Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/62179,MERGED,2019-06-27T12:39:34Z,2019-06-28T14:08:49Z,ci: Move most builders to Azure Pipelines,alexcrichton,6f838b4d4ad954eda685235b807cb6e5c44a8b14,3,"ci: Move most builders to Azure Pipelines This commit disables all builders on Travis and almost all builders on AppVeyor now that they're all running on Azure Pipelines. There is one remaining builder on AppVeyor which hasn't been migrated yet due to a test failure on Azure which we'll be debugging soon. One remaining builder is left on Travis which is the tools builder whenever a submodule is changed but we'll probably turn that off soon since it's just for PRs. The other major change in this PR is that the auto builders on Azure are now configured with ""real"" prod credentials which should cause them to publish all artifacts into the official CI buckets.",HOORAY,2019-07-02T21:54:55Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/62193,MERGED,2019-06-27T21:06:09Z,2019-07-05T21:52:39Z,Create async version of the dynamic-drop test,matthewjasper,61ddf5e85cdc46cff8617088594d7916d597e87e,1,Create async version of the dynamic-drop test,HEART,2019-06-27T21:15:41Z,cramertj,NA https://github.com/rust-lang/rust/pull/62193,MERGED,2019-06-27T21:06:09Z,2019-07-05T21:52:39Z,Create async version of the dynamic-drop test,matthewjasper,61ddf5e85cdc46cff8617088594d7916d597e87e,1,Create async version of the dynamic-drop test,HEART,2019-06-30T13:17:20Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62193,MERGED,2019-06-27T21:06:09Z,2019-07-05T21:52:39Z,Create async version of the dynamic-drop test,matthewjasper,61ddf5e85cdc46cff8617088594d7916d597e87e,1,Create async version of the dynamic-drop test,HEART,2019-06-30T13:20:12Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62198,CLOSED,2019-06-28T01:08:23Z,2019-10-01T17:06:18Z,Rename ManuallyDrop::take to read,CAD97,NA,NA,NA,HEART,2019-07-06T03:17:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62207,CLOSED,2019-06-28T14:04:49Z,2019-08-16T06:49:51Z,Implement va_arg for AArch64 Linux,parched,NA,NA,NA,HOORAY,2019-06-28T14:14:03Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/62207,CLOSED,2019-06-28T14:04:49Z,2019-08-16T06:49:51Z,Implement va_arg for AArch64 Linux,parched,NA,NA,NA,HEART,2019-06-28T15:41:04Z,panaman67,NA https://github.com/rust-lang/rust/pull/62207,CLOSED,2019-06-28T14:04:49Z,2019-08-16T06:49:51Z,Implement va_arg for AArch64 Linux,parched,NA,NA,NA,HOORAY,2019-06-29T11:50:00Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62209,MERGED,2019-06-28T15:01:21Z,2019-06-29T11:45:08Z,"Emergency backport of ""arbitrary self types lifetime elision 2""",nikomatsakis,83dc1b52f6709169a00fa7138dd3e908d611a28b,2,arbitrary_self_types lifetime elision: --bless --compare-mode=nll.,HEART,2019-06-29T05:53:05Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62224,MERGED,2019-06-29T02:53:30Z,2019-07-01T10:09:53Z,rustdoc: remove unused derives and variants,euclio,e991abd00455b20bb96076bbeec63e56764fc822,7,remove unused derives and variants,THUMBS_UP,2019-06-29T08:19:06Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/62228,MERGED,2019-06-29T12:54:34Z,2019-07-01T10:09:54Z,Extend the #[must_use] lint to boxed types,varkor,400fd6055fea43ccd89769a4ddb85586c70bf8ae,1,Update miri,HEART,2019-06-29T13:59:40Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/62228,MERGED,2019-06-29T12:54:34Z,2019-07-01T10:09:54Z,Extend the #[must_use] lint to boxed types,varkor,400fd6055fea43ccd89769a4ddb85586c70bf8ae,1,Update miri,HEART,2019-06-29T15:32:47Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62228,MERGED,2019-06-29T12:54:34Z,2019-07-01T10:09:54Z,Extend the #[must_use] lint to boxed types,varkor,400fd6055fea43ccd89769a4ddb85586c70bf8ae,1,Update miri,HEART,2019-07-04T13:49:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62228,MERGED,2019-06-29T12:54:34Z,2019-07-01T10:09:54Z,Extend the #[must_use] lint to boxed types,varkor,400fd6055fea43ccd89769a4ddb85586c70bf8ae,1,Update miri,HEART,2019-08-15T06:07:36Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/62233,MERGED,2019-06-29T15:16:37Z,2019-07-09T16:51:08Z,Exit arm scopes,matthewjasper,de5c6ec1f4a6bbd8600fda0e7c1574d914ac35bd,3,Exit arm scopes correctly in the HIR CFG When a match evaluates to false we jump to the next arm when we do so we need to make sure that we exit the scope for that arm.,THUMBS_UP,2019-06-30T12:59:09Z,lqd,NA https://github.com/rust-lang/rust/pull/62241,MERGED,2019-06-29T19:43:06Z,2019-07-01T10:09:57Z,Always parse 'async unsafe fn' + properly ban in 2015,Centril,ce1d95af4c1b179536c3c0daccd62946ef20b006,7,Always parse 'async unsafe fn' + properly ban in 2015.,HEART,2019-06-30T16:16:05Z,estebank,NA https://github.com/rust-lang/rust/pull/62241,MERGED,2019-06-29T19:43:06Z,2019-07-01T10:09:57Z,Always parse 'async unsafe fn' + properly ban in 2015,Centril,ce1d95af4c1b179536c3c0daccd62946ef20b006,7,Always parse 'async unsafe fn' + properly ban in 2015.,HEART,2019-07-04T13:49:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62243,MERGED,2019-06-29T22:32:10Z,2019-07-07T01:14:32Z,Improve documentation for built-in macros,petrochenkov,327450797d460ae011eaaba68fae356117ab883d,5,resolve: Reserve cfg/cfg_attr/derive only in attribute sub-namespace,HEART,2019-07-05T22:03:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62249,MERGED,2019-06-30T18:35:16Z,2019-07-04T03:12:15Z,Use mem::take instead of mem::replace with default,czipperz,eddfad31400b9c6cba6eda95cadd96c455504898,1,Fix import of take in collapse_docs.rs,HEART,2019-06-30T20:06:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62249,MERGED,2019-06-30T18:35:16Z,2019-07-04T03:12:15Z,Use mem::take instead of mem::replace with default,czipperz,eddfad31400b9c6cba6eda95cadd96c455504898,1,Fix import of take in collapse_docs.rs,HEART,2019-07-01T12:59:26Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/62258,MERGED,2019-06-30T22:30:31Z,2019-07-04T03:12:16Z,syntax: Unsupport `foo! bar { ... }` macros in the parser,petrochenkov,d0dc41a2bdd45531e9d5ef9364027763158b4b85,1,Address review comments,HEART,2019-06-30T22:53:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/62258,MERGED,2019-06-30T22:30:31Z,2019-07-04T03:12:16Z,syntax: Unsupport `foo! bar { ... }` macros in the parser,petrochenkov,d0dc41a2bdd45531e9d5ef9364027763158b4b85,1,Address review comments,HEART,2019-06-30T23:30:14Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/62258,MERGED,2019-06-30T22:30:31Z,2019-07-04T03:12:16Z,syntax: Unsupport `foo! bar { ... }` macros in the parser,petrochenkov,d0dc41a2bdd45531e9d5ef9364027763158b4b85,1,Address review comments,HEART,2019-06-30T23:48:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62262,CLOSED,2019-07-01T01:03:47Z,2019-10-25T09:47:47Z,Extend `#[must_use]` to nested structures,varkor,NA,NA,NA,HEART,2019-08-05T22:54:21Z,estebank,NA https://github.com/rust-lang/rust/pull/62262,CLOSED,2019-07-01T01:03:47Z,2019-10-25T09:47:47Z,Extend `#[must_use]` to nested structures,varkor,NA,NA,NA,HEART,2019-09-19T06:05:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62262,CLOSED,2019-07-01T01:03:47Z,2019-10-25T09:47:47Z,Extend `#[must_use]` to nested structures,varkor,NA,NA,NA,HEART,2019-09-24T15:44:47Z,jplatte,NA https://github.com/rust-lang/rust/pull/62262,CLOSED,2019-07-01T01:03:47Z,2019-10-25T09:47:47Z,Extend `#[must_use]` to nested structures,varkor,NA,NA,NA,HEART,2019-09-24T23:02:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62268,MERGED,2019-07-01T12:54:44Z,2019-07-04T03:12:17Z,Clean up inherent_impls,Zoxc,8d6b1d10d48c3d189718c46c3b6441c2b7a0598b,1,Clean up inherent_impls,HEART,2019-07-01T13:06:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/62279,MERGED,2019-07-01T20:05:23Z,2019-07-02T02:06:58Z,ci: explicitly disable CRLF conversion on Windows,pietroalbini,239a404cae1bebbd0fe6e01688e8cf94be3a6c52,1,ci: explicitly disable CRLF conversion on Windows The Azure image enables CRLF conversion on Windows builders but that caused regressions both in our test suite (the miri test suite broke) and in the ecosystem since we started shipping install scripts with CRLF endings instead of the old LF. The Godbolt Compiler Explorer is one such case of breakage. This adds a step to the build explicitly disabling the conversion before the repository is checked out.,HOORAY,2019-07-01T20:44:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62281,MERGED,2019-07-01T21:03:12Z,2019-07-07T04:43:32Z,Add support for pc-relative addressing on 64-bit RISC-V,Disasm,c65ffa789d57004db42f6c30405c59e0a5bae330,2,Use code model 'medium' for 64-bit RISC-V targets,HEART,2019-07-01T22:57:45Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/62281,MERGED,2019-07-01T21:03:12Z,2019-07-07T04:43:32Z,Add support for pc-relative addressing on 64-bit RISC-V,Disasm,c65ffa789d57004db42f6c30405c59e0a5bae330,2,Use code model 'medium' for 64-bit RISC-V targets,HEART,2019-07-07T07:30:12Z,laanwj,NA https://github.com/rust-lang/rust/pull/62282,CLOSED,2019-07-01T21:09:49Z,2020-05-02T14:34:21Z,Add `take_...` functions to slices,cramertj,NA,NA,NA,THUMBS_UP,2020-03-07T14:59:37Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/62282,CLOSED,2019-07-01T21:09:49Z,2020-05-02T14:34:21Z,Add `take_...` functions to slices,cramertj,NA,NA,NA,THUMBS_UP,2020-05-02T18:55:15Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/62292,MERGED,2019-07-02T02:28:57Z,2019-07-05T15:31:10Z,Move `async || ...` closures into `#![feature(async_closure)]`,Centril,43315bc15e274d62b7bb239488066a21d40b4269,20,Adjust tests wrt. 'async_closure' feature gate.,THUMBS_UP,2019-07-02T06:38:49Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/62297,MERGED,2019-07-02T08:10:32Z,2019-07-04T03:12:22Z,refactor check_for_substitution,matklad,dc088b26ce39d8a4632d73e62e5440ae474a8cb5,2,refactor check_for_substitution No behavior change just flatter and simpler code,HEART,2019-07-02T13:05:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/62329,MERGED,2019-07-03T12:19:29Z,2019-07-06T06:16:19Z,Remove support for 1-token lookahead from the lexer,matklad,3e362a4800932186c7351972753ecdf715050983,1,make unwrap_or_abort non-generic again,HOORAY,2019-07-03T13:16:23Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/62329,MERGED,2019-07-03T12:19:29Z,2019-07-06T06:16:19Z,Remove support for 1-token lookahead from the lexer,matklad,3e362a4800932186c7351972753ecdf715050983,1,make unwrap_or_abort non-generic again,HOORAY,2019-07-03T13:45:21Z,mati865,NA https://github.com/rust-lang/rust/pull/62329,MERGED,2019-07-03T12:19:29Z,2019-07-06T06:16:19Z,Remove support for 1-token lookahead from the lexer,matklad,3e362a4800932186c7351972753ecdf715050983,1,make unwrap_or_abort non-generic again,HOORAY,2019-07-03T13:45:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/62329,MERGED,2019-07-03T12:19:29Z,2019-07-06T06:16:19Z,Remove support for 1-token lookahead from the lexer,matklad,3e362a4800932186c7351972753ecdf715050983,1,make unwrap_or_abort non-generic again,HEART,2019-07-03T13:45:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/62329,MERGED,2019-07-03T12:19:29Z,2019-07-06T06:16:19Z,Remove support for 1-token lookahead from the lexer,matklad,3e362a4800932186c7351972753ecdf715050983,1,make unwrap_or_abort non-generic again,HOORAY,2019-07-03T23:32:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62330,MERGED,2019-07-03T12:21:41Z,2019-10-22T04:10:02Z,Change untagged_unions to not allow union fields with drop,SimonSapin,875bdd5dbe663a6dafd785b86c8964a90653eeb7,3,Report even duplilcate errors in case the feature gat is not active,HEART,2019-07-13T12:30:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62330,MERGED,2019-07-03T12:21:41Z,2019-10-22T04:10:02Z,Change untagged_unions to not allow union fields with drop,SimonSapin,875bdd5dbe663a6dafd785b86c8964a90653eeb7,3,Report even duplilcate errors in case the feature gat is not active,HEART,2019-10-23T09:46:44Z,bluss,NA https://github.com/rust-lang/rust/pull/62330,MERGED,2019-07-03T12:21:41Z,2019-10-22T04:10:02Z,Change untagged_unions to not allow union fields with drop,SimonSapin,875bdd5dbe663a6dafd785b86c8964a90653eeb7,3,Report even duplilcate errors in case the feature gat is not active,HEART,2019-11-05T16:09:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62340,CLOSED,2019-07-03T15:23:49Z,2019-09-13T06:32:43Z,[WIP] Switch rustc allocator to mimalloc,gnzlbg,NA,NA,NA,THUMBS_UP,2019-07-03T16:08:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62340,CLOSED,2019-07-03T15:23:49Z,2019-09-13T06:32:43Z,[WIP] Switch rustc allocator to mimalloc,gnzlbg,NA,NA,NA,THUMBS_UP,2019-07-03T18:47:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/62340,CLOSED,2019-07-03T15:23:49Z,2019-09-13T06:32:43Z,[WIP] Switch rustc allocator to mimalloc,gnzlbg,NA,NA,NA,THUMBS_UP,2019-07-03T18:55:18Z,mati865,NA https://github.com/rust-lang/rust/pull/62340,CLOSED,2019-07-03T15:23:49Z,2019-09-13T06:32:43Z,[WIP] Switch rustc allocator to mimalloc,gnzlbg,NA,NA,NA,THUMBS_UP,2019-07-06T07:54:28Z,thedrow,omer.katz@omerkatz.com https://github.com/rust-lang/rust/pull/62344,MERGED,2019-07-03T17:24:47Z,2019-07-04T03:12:27Z,simplify Option::get_or_insert,matklad,c51802ac6087206e302bbded174d5ac9feabf2b7,1,simplify Option::get_or_insert,HEART,2019-07-03T18:44:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/62344,MERGED,2019-07-03T17:24:47Z,2019-07-04T03:12:27Z,simplify Option::get_or_insert,matklad,c51802ac6087206e302bbded174d5ac9feabf2b7,1,simplify Option::get_or_insert,HOORAY,2019-07-03T18:45:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/62344,MERGED,2019-07-03T17:24:47Z,2019-07-04T03:12:27Z,simplify Option::get_or_insert,matklad,c51802ac6087206e302bbded174d5ac9feabf2b7,1,simplify Option::get_or_insert,THUMBS_UP,2019-07-04T02:14:58Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/62344,MERGED,2019-07-03T17:24:47Z,2019-07-04T03:12:27Z,simplify Option::get_or_insert,matklad,c51802ac6087206e302bbded174d5ac9feabf2b7,1,simplify Option::get_or_insert,HEART,2019-07-04T06:53:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62351,MERGED,2019-07-03T18:16:11Z,2019-07-04T03:12:28Z,remove bogus example from drop_in_place,RalfJung,6225607e67d9934bcb8ddd0ab74abe4ea974f178,1,remove bogus example from drop_in_place,HEART,2019-07-03T18:44:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/62356,MERGED,2019-07-03T23:49:47Z,2019-07-08T04:57:05Z,Implement Option::contains and Result::contains,soc,6f76da494b4b89839cd9a1a13e725ec5cdd83743,2,Implement Option::contains Result::contains and Result::contains_err This increases consistency with other common data structures.,HEART,2019-07-12T13:12:44Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/62356,MERGED,2019-07-03T23:49:47Z,2019-07-08T04:57:05Z,Implement Option::contains and Result::contains,soc,6f76da494b4b89839cd9a1a13e725ec5cdd83743,2,Implement Option::contains Result::contains and Result::contains_err This increases consistency with other common data structures.,HEART,2020-08-17T01:53:46Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/62359,MERGED,2019-07-04T00:50:46Z,2019-12-13T19:39:52Z,replace serialize with serde in rustdoc,euclio,94630d4c8bbf4c7c7e680210cd5d5f848c53aeaa,6,replace serialize with serde in rustdoc,HEART,2019-07-04T12:23:06Z,mati865,NA https://github.com/rust-lang/rust/pull/62359,MERGED,2019-07-04T00:50:46Z,2019-12-13T19:39:52Z,replace serialize with serde in rustdoc,euclio,94630d4c8bbf4c7c7e680210cd5d5f848c53aeaa,6,replace serialize with serde in rustdoc,HEART,2019-07-27T17:44:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62384,CLOSED,2019-07-04T19:04:47Z,2019-08-04T07:46:08Z,suggest return type for main(),llogiq,NA,NA,NA,HEART,2019-07-06T16:03:42Z,estebank,NA https://github.com/rust-lang/rust/pull/62399,CLOSED,2019-07-05T08:39:56Z,2019-07-05T11:50:03Z,Rollup of 10 pull requests,Centril,NA,NA,NA,HEART,2019-07-05T08:46:14Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62403,MERGED,2019-07-05T10:08:01Z,2019-07-09T06:20:39Z,Replace SliceConcatExt trait with inherent methods and SliceConcat helper trait,SimonSapin,e808d921ddc0ad81a200934fc4caabc34094afe5,5,Replace SliceConcatExt trait with inherent methods and SliceConcat helper trait Before this change `SliceConcatExt` was an unstable extension trait with stable methods. It was in the libstd prelude so that its methods could be used on the stable channel. This replaces it with inherent methods which can be used without any addition to the prelude. Since the methods are stable and very generic (with for example a return type that depends on the types of parameters) an helper trait is still needed. But now that trait does not need to be in scope for the methods to be used. Removing this depedency on the libstd prelude allows the methods to be used in `#![no_std]` crate that use liballoc which does not have its own implicitly-imported prelude.,THUMBS_UP,2019-07-05T12:04:00Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/62407,MERGED,2019-07-05T11:53:14Z,2019-07-05T15:31:20Z,Rollup of 10 pull requests,Centril,18081890ea7c4f3cb38d51be5ddea4f51dc262c3,5,Rollup merge of #62388 - rust-lang:fix-loop-break-mir-generation r=eddyb Break out of the correct number of scopes in loops We were incorrectly breaking out of one too many drop scopes when generating MIR for loops and breakable blocks resulting in use after free and associated borrow checker warnings. This wasn't noticed because the scope that we're breaking out of twice is only used for temporaries that are created for adjustments applied to the loop. Since loops generally propagate coercions to the `break` expressions the only case we see this is when the type of the loop is a smart pointer to a trait object. Closes #62312,HEART,2019-07-05T14:50:23Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62413,CLOSED,2019-07-05T15:34:14Z,2019-07-05T22:03:24Z,Rollup of 14 pull requests,Centril,NA,NA,NA,HEART,2019-07-05T15:52:35Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62414,MERGED,2019-07-05T16:04:29Z,2019-07-05T21:52:54Z,Remove last use of mem::uninitialized in SGX,jethrogb,7fb17d868bd629019bf11c56596bb64eea6bd6f6,1,Remove last use of mem::uninitialized in SGX,HOORAY,2019-07-05T16:18:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62414,MERGED,2019-07-05T16:04:29Z,2019-07-05T21:52:54Z,Remove last use of mem::uninitialized in SGX,jethrogb,7fb17d868bd629019bf11c56596bb64eea6bd6f6,1,Remove last use of mem::uninitialized in SGX,HOORAY,2019-07-05T17:42:02Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-07-06T03:14:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-07-07T01:36:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-07-11T13:56:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-07-27T06:39:59Z,z4rathustr4,NA https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-08-14T21:03:54Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-08-15T09:38:05Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2019-08-22T13:14:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62429,MERGED,2019-07-06T01:15:22Z,2019-08-15T08:13:53Z,Reduce the genericity of closures in the iterator traits,cuviper,bca6f28f7f7a6db3416c0d4e631a7a4cc1072cf7,4,Force optimization in 32-bit iter overflow tests,HEART,2020-08-14T11:05:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-06T14:46:23Z,est31,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-06T19:21:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-06T19:54:31Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-06T20:37:39Z,mooman219,joewcu+git@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T03:48:23Z,crlf0710,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T09:04:34Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T10:57:01Z,jplatte,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T12:15:49Z,kpp,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T13:15:38Z,qezz,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T18:49:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T19:10:20Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-07T19:45:36Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T04:21:40Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T05:18:11Z,robatipoor,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,THUMBS_UP,2019-07-08T06:08:18Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T06:57:43Z,linyinfeng,lin.yinfeng@outlook.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T08:10:28Z,bestouff,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T09:29:40Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T10:33:40Z,flosse,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T12:53:25Z,theduke,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T20:39:45Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-08T23:52:41Z,mati865,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-11T07:46:44Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-12T21:11:46Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-17T14:34:33Z,Boiethios,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-18T04:45:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-23T15:45:07Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-07-25T16:17:14Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-10-18T19:48:12Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,THUMBS_UP,2019-10-18T19:48:13Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-10-19T13:16:59Z,hugecheese,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,THUMBS_UP,2019-10-19T13:17:00Z,hugecheese,NA https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2019-10-19T18:19:44Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,HOORAY,2020-04-16T11:50:18Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/62435,MERGED,2019-07-06T07:46:21Z,2019-07-07T22:04:32Z,Use const generics for array impls [part 1],scottmcm,d6a9793722c1ab6066f4f71224aac078b54f03c0,9,Use const generics for array impls restricted to 0..=32 - uses a never-stable core::array::LengthAtMost32 to bound the impls - includes a custom error message to avoid mentioning LengthAtMost32 too often - doesn't use macros for the slice implementations to avoid #62433,THUMBS_UP,2020-04-16T11:51:32Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/62438,MERGED,2019-07-06T10:48:25Z,2019-07-07T08:08:38Z,rustbuild: Cleanup global lint settings,petrochenkov,36a5aa832503a2fb6ab2eb80e1873711807430a5,1,Address review comments,THUMBS_UP,2019-07-06T13:57:44Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/62450,MERGED,2019-07-06T17:15:49Z,2019-07-10T01:53:37Z,Raise the default recursion limit to 128,nagisa,7e40df3f134f72597c8b125f21abf3b4d3aefceb,15,Raise the default recursion limit to 128,HEART,2019-07-07T23:30:15Z,goddessfreya,zegentzy@protonmail.com https://github.com/rust-lang/rust/pull/62450,MERGED,2019-07-06T17:15:49Z,2019-07-10T01:53:37Z,Raise the default recursion limit to 128,nagisa,7e40df3f134f72597c8b125f21abf3b4d3aefceb,15,Raise the default recursion limit to 128,HEART,2019-07-08T10:58:23Z,tyranron,NA https://github.com/rust-lang/rust/pull/62451,MERGED,2019-07-06T20:09:03Z,2019-08-18T01:02:29Z,Add APIs for uninitialized Box Rc and Arc. (Plus get_mut_unchecked),SimonSapin,9bd70834b0084f17d622b204a22dc80835d8d962,1,Doc nit Co-Authored-By: Ralf Jung ,THUMBS_UP,2019-07-24T10:29:45Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/62451,MERGED,2019-07-06T20:09:03Z,2019-08-18T01:02:29Z,Add APIs for uninitialized Box Rc and Arc. (Plus get_mut_unchecked),SimonSapin,9bd70834b0084f17d622b204a22dc80835d8d962,1,Doc nit Co-Authored-By: Ralf Jung ,THUMBS_UP,2019-08-08T16:07:44Z,crlf0710,NA https://github.com/rust-lang/rust/pull/62451,MERGED,2019-07-06T20:09:03Z,2019-08-18T01:02:29Z,Add APIs for uninitialized Box Rc and Arc. (Plus get_mut_unchecked),SimonSapin,9bd70834b0084f17d622b204a22dc80835d8d962,1,Doc nit Co-Authored-By: Ralf Jung ,THUMBS_UP,2019-08-08T20:24:17Z,lqd,NA https://github.com/rust-lang/rust/pull/62451,MERGED,2019-07-06T20:09:03Z,2019-08-18T01:02:29Z,Add APIs for uninitialized Box Rc and Arc. (Plus get_mut_unchecked),SimonSapin,9bd70834b0084f17d622b204a22dc80835d8d962,1,Doc nit Co-Authored-By: Ralf Jung ,THUMBS_UP,2019-08-22T15:43:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/62451,MERGED,2019-07-06T20:09:03Z,2019-08-18T01:02:29Z,Add APIs for uninitialized Box Rc and Arc. (Plus get_mut_unchecked),SimonSapin,9bd70834b0084f17d622b204a22dc80835d8d962,1,Doc nit Co-Authored-By: Ralf Jung ,THUMBS_UP,2020-04-17T02:43:22Z,gz,NA https://github.com/rust-lang/rust/pull/62453,MERGED,2019-07-06T22:17:36Z,2019-07-13T03:12:57Z,in which we suggest anonymizing single-use lifetimes in paths ,zackmdavis,acc4e564feb5151ca02070e0890e428d7967b8b4,3,in which we suggest anonymizing single-use lifetimes in paths,HEART,2019-07-12T18:33:04Z,estebank,NA https://github.com/rust-lang/rust/pull/62453,MERGED,2019-07-06T22:17:36Z,2019-07-13T03:12:57Z,in which we suggest anonymizing single-use lifetimes in paths ,zackmdavis,acc4e564feb5151ca02070e0890e428d7967b8b4,3,in which we suggest anonymizing single-use lifetimes in paths,THUMBS_UP,2019-07-13T03:09:47Z,czipperz,czipperz@gmail.com https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",THUMBS_UP,2019-07-07T04:30:46Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",THUMBS_UP,2019-07-12T22:57:03Z,estebank,NA https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",HEART,2019-07-12T22:58:07Z,estebank,NA https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",HEART,2019-08-06T18:03:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",HEART,2019-08-07T17:06:17Z,mati865,NA https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",HEART,2019-08-08T02:37:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/62457,MERGED,2019-07-07T02:50:38Z,2019-08-08T01:48:50Z,pretty-pretty extremal constants!,zackmdavis,d1cdb02e4d408bc9be293e081ba0116f9f7670f6,12,"pretty-pretty extremal constants! While many programmers may intuitively appreciate the significance of ""magic numbers"" like −2147483648 Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof). The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance. Resolves #56393.",HEART,2019-08-08T09:31:53Z,varkor,NA https://github.com/rust-lang/rust/pull/62460,MERGED,2019-07-07T07:34:30Z,2019-07-09T09:51:29Z, Handle null from LLVMRustGetSectionName ,RalfJung,076a5cdc357a3a9e03850a745bee0b3f0db3d54f,1,format a bit,THUMBS_UP,2019-07-07T10:11:11Z,mati865,NA https://github.com/rust-lang/rust/pull/62463,MERGED,2019-07-07T12:36:03Z,2019-07-09T13:11:08Z,Update LLVM: apply patch necessary for ThinLTO on RISC-V,Disasm,f90d6d5144af8a9a9312a6fd3e155bb1b799c623,1,Update LLVM: apply patch necessary for ThinLTO on RISC-V,THUMBS_UP,2019-07-08T07:46:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/62465,MERGED,2019-07-07T14:12:57Z,2019-07-11T02:30:10Z,Sometimes generate storage statements for temporaries with type `!`,matthewjasper,163c059354ed24d8b5e1c50177fd4dd2872d63e7,3,Only omit StorageLive/Dead for variable that are never initialized With `feature(never_type)` it's not guaranteed that any variable with type `!` isn't ever assigned to.,HEART,2019-07-08T01:39:02Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/62468,MERGED,2019-07-07T15:20:07Z,2019-07-13T17:12:13Z,Improve diagnostics for invalid mutation through overloaded operators,matthewjasper,38306adf16ea6eecb6ccfaf0f701b0a1117bb19d,12,Add help message for mutation though overloaded place operators,HEART,2019-07-12T23:05:03Z,estebank,NA https://github.com/rust-lang/rust/pull/62468,MERGED,2019-07-07T15:20:07Z,2019-07-13T17:12:13Z,Improve diagnostics for invalid mutation through overloaded operators,matthewjasper,38306adf16ea6eecb6ccfaf0f701b0a1117bb19d,12,Add help message for mutation though overloaded place operators,HEART,2019-07-14T00:15:34Z,dustinfreeman,dustin.freeman@gmail.com https://github.com/rust-lang/rust/pull/62468,MERGED,2019-07-07T15:20:07Z,2019-07-13T17:12:13Z,Improve diagnostics for invalid mutation through overloaded operators,matthewjasper,38306adf16ea6eecb6ccfaf0f701b0a1117bb19d,12,Add help message for mutation though overloaded place operators,HEART,2019-07-14T18:57:11Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/62468,MERGED,2019-07-07T15:20:07Z,2019-07-13T17:12:13Z,Improve diagnostics for invalid mutation through overloaded operators,matthewjasper,38306adf16ea6eecb6ccfaf0f701b0a1117bb19d,12,Add help message for mutation though overloaded place operators,HEART,2019-07-27T07:33:32Z,eupn,NA https://github.com/rust-lang/rust/pull/62474,MERGED,2019-07-07T19:36:06Z,2019-07-10T08:59:14Z,Prepare for LLVM 9 update,nikic,ac560258e36659d542850651fc1b79e4db2eb29d,2,Adjust codegen tests for DISPFlagMainSubprogram,ROCKET,2019-07-08T08:29:58Z,mati865,NA https://github.com/rust-lang/rust/pull/62474,MERGED,2019-07-07T19:36:06Z,2019-07-10T08:59:14Z,Prepare for LLVM 9 update,nikic,ac560258e36659d542850651fc1b79e4db2eb29d,2,Adjust codegen tests for DISPFlagMainSubprogram,ROCKET,2019-07-08T21:44:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62474,MERGED,2019-07-07T19:36:06Z,2019-07-10T08:59:14Z,Prepare for LLVM 9 update,nikic,ac560258e36659d542850651fc1b79e4db2eb29d,2,Adjust codegen tests for DISPFlagMainSubprogram,ROCKET,2019-07-09T08:55:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/62474,MERGED,2019-07-07T19:36:06Z,2019-07-10T08:59:14Z,Prepare for LLVM 9 update,nikic,ac560258e36659d542850651fc1b79e4db2eb29d,2,Adjust codegen tests for DISPFlagMainSubprogram,ROCKET,2019-07-09T21:37:49Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/62476,MERGED,2019-07-07T22:03:33Z,2019-07-11T08:13:28Z,Continue refactoring macro expansion and resolution,petrochenkov,e86e5cb38ffb9a55f6d9ab6ebda2d384fb154626,7,Add a regression test for #44692 Add a test for the issue resolved by removing `resolve_macro_path` Add a test making sure that extern prelude entries introduced from an opaque macro are not visible anywhere even it that macro Fix test output after rebase,HOORAY,2019-07-08T00:39:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62476,MERGED,2019-07-07T22:03:33Z,2019-07-11T08:13:28Z,Continue refactoring macro expansion and resolution,petrochenkov,e86e5cb38ffb9a55f6d9ab6ebda2d384fb154626,7,Add a regression test for #44692 Add a test for the issue resolved by removing `resolve_macro_path` Add a test making sure that extern prelude entries introduced from an opaque macro are not visible anywhere even it that macro Fix test output after rebase,HEART,2019-07-08T05:19:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/62476,MERGED,2019-07-07T22:03:33Z,2019-07-11T08:13:28Z,Continue refactoring macro expansion and resolution,petrochenkov,e86e5cb38ffb9a55f6d9ab6ebda2d384fb154626,7,Add a regression test for #44692 Add a test for the issue resolved by removing `resolve_macro_path` Add a test making sure that extern prelude entries introduced from an opaque macro are not visible anywhere even it that macro Fix test output after rebase,THUMBS_UP,2019-07-08T15:39:22Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/62477,MERGED,2019-07-07T22:48:43Z,2019-07-08T04:57:13Z,Re-add bootstrap attribute to libunwind for llvm-libunwind feature,petrhosek,1dcee4cc631d22f1e67eb72190f3baa384301099,2,Re-add bootstrap attribute to libunwind for llvm-libunwind feature This was removed in 8a7dded but since #62286 hasn't yet made it into beta this is breaking the build with llvm-libunwind feature enabled. Furthemore restrict the link attribute to Fuchsia and Linux matching the logic in build.rs since llvm-libunwind feature isn't yet supported on other systems.,EYES,2019-07-08T02:45:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/62493,MERGED,2019-07-08T14:04:46Z,2019-07-11T02:30:13Z,#62357: doc(ptr): add example for {read write}_unaligned,Freyskeyd,bc322af444006973addb3e65bcd74f033080402b,1,doc(ptr): add example for {read write}_unaligned Signed-off-by: Freyskeyd ,THUMBS_UP,2019-07-08T15:11:34Z,Kyos,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,THUMBS_UP,2019-07-08T15:49:10Z,mati865,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,THUMBS_UP,2019-07-08T16:04:18Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,THUMBS_UP,2019-07-08T16:49:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,HEART,2019-07-08T16:50:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,THUMBS_UP,2019-07-08T17:10:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/62494,MERGED,2019-07-08T15:41:17Z,2019-07-09T06:20:46Z,Remove unused dependencies,sinkuu,b06ed52cfd57a971bf71bb8a4dab1a134cd041a3,4,Remove unused dependencies,HEART,2019-07-08T19:24:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,HEART,2019-07-08T23:03:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,HEART,2019-07-09T01:50:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,HEART,2019-07-09T07:42:32Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,HEART,2019-07-19T13:11:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,EYES,2019-07-22T13:54:09Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/62507,MERGED,2019-07-08T21:36:13Z,2019-08-01T14:43:28Z,Remove derives `Encodable`/`Decodable` and unstabilize attribute `#[bench]`,petrochenkov,ef7ef05e8ee29ccf4c225b1ad1cd3772ace8d660,2,Drive-by fix: Update two tests failing in `--pass check` mode,HEART,2019-08-01T16:01:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/62513,CLOSED,2019-07-09T04:29:47Z,2019-07-28T01:02:54Z,Revival of 'Compile core crates before std',Aaron1011,NA,NA,NA,HEART,2019-07-09T06:23:52Z,est31,NA https://github.com/rust-lang/rust/pull/62513,CLOSED,2019-07-09T04:29:47Z,2019-07-28T01:02:54Z,Revival of 'Compile core crates before std',Aaron1011,NA,NA,NA,HEART,2019-07-10T09:18:02Z,mati865,NA https://github.com/rust-lang/rust/pull/62518,CLOSED,2019-07-09T09:07:37Z,2019-07-11T22:59:41Z,move `async unsafe fn` into `#![feature(async_unsafe)]`,delan,NA,NA,NA,THUMBS_UP,2019-07-09T10:07:22Z,ar1a,NA https://github.com/rust-lang/rust/pull/62528,MERGED,2019-07-09T12:44:03Z,2019-07-26T02:18:20Z,Add joining slices of slices with a slice separator not just a single item,SimonSapin,5f7768a976edc296c62479b936993b4dc9af065b,1,Update src/liballoc/str.rs Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-07-09T13:42:24Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/62528,MERGED,2019-07-09T12:44:03Z,2019-07-26T02:18:20Z,Add joining slices of slices with a slice separator not just a single item,SimonSapin,5f7768a976edc296c62479b936993b4dc9af065b,1,Update src/liballoc/str.rs Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-09-08T12:58:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/62532,MERGED,2019-07-09T14:08:26Z,2019-07-11T02:30:16Z,Some more cleanups to syntax::print,Mark-Simulacrum,56a9237b595b4523f2be3123d52662739e89d4c2,1,File is now short enough for tidy,HEART,2019-07-09T14:26:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/62532,MERGED,2019-07-09T14:08:26Z,2019-07-11T02:30:16Z,Some more cleanups to syntax::print,Mark-Simulacrum,56a9237b595b4523f2be3123d52662739e89d4c2,1,File is now short enough for tidy,THUMBS_UP,2019-07-09T14:36:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/62541,MERGED,2019-07-09T18:58:53Z,2019-07-10T01:53:48Z,Add spastorino for rustc-guide toolstate,mark-i-m,4eb492db54abcb57773979b4ea3b8fe041d63a89,1,Add spastorino for rustc-guide toolstate,THUMBS_UP,2019-07-10T13:31:17Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/62547,CLOSED,2019-07-09T23:37:30Z,2019-08-24T16:42:43Z,Add a Use-Definition Chain implementation for the MIR.,ecstatic-morse,NA,NA,NA,THUMBS_UP,2019-07-10T18:33:51Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62547,CLOSED,2019-07-09T23:37:30Z,2019-08-24T16:42:43Z,Add a Use-Definition Chain implementation for the MIR.,ecstatic-morse,NA,NA,NA,THUMBS_UP,2019-08-16T22:49:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-09T23:54:20Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-10T01:29:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-10T01:48:37Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-10T09:10:56Z,mati865,NA https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-10T09:41:36Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/62549,MERGED,2019-07-09T23:50:46Z,2019-07-12T12:04:55Z,Update cargo-vendor usage,ehuss,06c3256a6b1a42b2226a0f2ec75c43cd8951b962,4,Update cargo-vendor usage,HOORAY,2019-07-11T18:05:41Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62561,MERGED,2019-07-10T14:08:27Z,2019-07-11T02:30:19Z,Rollup of 5 pull requests,Centril,3c299a987cfd9522c4e1f6e53ed79123b4a4acab,15,Rollup merge of #62532 - Mark-Simulacrum:syntax-print-cleanup r=petrochenkov Some more cleanups to syntax::print All of these changes should be functionally equivalent to previous code. Each commit mostly stands alone and this PR is easiest to review by-commit.,HEART,2019-07-10T18:08:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/62564,MERGED,2019-07-10T16:37:32Z,2019-07-10T23:03:38Z,Ensure that checkout is with \n line endings,Mark-Simulacrum,df725c28d68d049aa29e06548961193531a9b891,2,Ensure that checkout is with \n line endings During installation of mingw at least the git directories change so we need to reset the core.autocrlf config to false. Once we finish checking out submodules check that the line endings are \n and not \r\n.,HOORAY,2019-07-11T07:37:59Z,mati865,NA https://github.com/rust-lang/rust/pull/62568,MERGED,2019-07-10T19:50:39Z,2019-07-13T03:13:04Z,Replace unsafe_destructor_blind_to_params with may_dangle,tesuji,8347917dd955e40c813867e0fddb52c3adb4711c,18,Remove feature gate `dropck_parametricity` completely Therefore we also remove `#[unsafe_destructor_blind_to_params]` attribute completly.,HEART,2019-07-12T09:06:02Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62574,MERGED,2019-07-10T23:57:41Z,2019-07-11T13:35:16Z,pretty-print: Do not lose the `$crate` printing flag in `print_tt`,petrochenkov,e38106599a1f3f27de889e5efc8d1812571b310b,1,Address review comments,THUMBS_UP,2019-07-11T06:53:43Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/62574,MERGED,2019-07-10T23:57:41Z,2019-07-11T13:35:16Z,pretty-print: Do not lose the `$crate` printing flag in `print_tt`,petrochenkov,e38106599a1f3f27de889e5efc8d1812571b310b,1,Address review comments,THUMBS_UP,2019-07-11T21:12:01Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/62592,MERGED,2019-07-11T17:41:18Z,2019-07-17T02:50:16Z,Update to LLVM 9 trunk,nikic,d2c1d1bc158eb07f5df95277ba36c6259d98b050,1,Compile new InstrProfilingPlatformWindows.c file,ROCKET,2019-07-11T18:58:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62592,MERGED,2019-07-11T17:41:18Z,2019-07-17T02:50:16Z,Update to LLVM 9 trunk,nikic,d2c1d1bc158eb07f5df95277ba36c6259d98b050,1,Compile new InstrProfilingPlatformWindows.c file,ROCKET,2019-07-11T23:43:53Z,mati865,NA https://github.com/rust-lang/rust/pull/62592,MERGED,2019-07-11T17:41:18Z,2019-07-17T02:50:16Z,Update to LLVM 9 trunk,nikic,d2c1d1bc158eb07f5df95277ba36c6259d98b050,1,Compile new InstrProfilingPlatformWindows.c file,ROCKET,2019-07-15T09:58:07Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62592,MERGED,2019-07-11T17:41:18Z,2019-07-17T02:50:16Z,Update to LLVM 9 trunk,nikic,d2c1d1bc158eb07f5df95277ba36c6259d98b050,1,Compile new InstrProfilingPlatformWindows.c file,ROCKET,2019-07-15T17:26:34Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62592,MERGED,2019-07-11T17:41:18Z,2019-07-17T02:50:16Z,Update to LLVM 9 trunk,nikic,d2c1d1bc158eb07f5df95277ba36c6259d98b050,1,Compile new InstrProfilingPlatformWindows.c file,ROCKET,2019-07-17T06:42:44Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/62594,MERGED,2019-07-11T17:49:48Z,2019-07-12T01:22:26Z,Update miri,JohnTitor,f8b620da758381e4eb84115929a1f05e83fd2c8d,1,Update miri,THUMBS_UP,2019-07-11T18:01:29Z,tesuji,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-11T19:59:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-11T20:20:50Z,RustyYato,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-11T21:55:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-11T22:26:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-12T12:13:05Z,SOF3,sofe2038@gmail.com https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-13T03:02:11Z,czipperz,czipperz@gmail.com https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-14T21:21:40Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-16T15:36:01Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-17T19:48:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-24T15:48:39Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-24T19:31:38Z,Reconcyl,NA https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-25T03:31:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62596,MERGED,2019-07-11T19:07:38Z,2019-07-17T12:14:18Z,Add Option::expect_none(msg) and unwrap_none(),cuviper,74c8d984dbd73c070f9c9a5ac991cc271ff05164,1,Add tracking issue 62633,THUMBS_UP,2019-07-26T17:14:44Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/62599,MERGED,2019-07-11T20:26:14Z,2019-07-13T03:13:08Z,move mem::uninitialized deprecation back by 1 release to 1.39,RalfJung,608249703c1636ca541fa8b33be29db93d3177c0,2,move mem::uninitialized deprecation back by 1 release to 1.39,HEART,2019-07-11T20:32:12Z,est31,NA https://github.com/rust-lang/rust/pull/62603,MERGED,2019-07-11T21:42:10Z,2019-08-26T04:11:02Z,Permit unwinding through FFI by default,cuviper,367b793790d7f362fa41313143e1015607b21700,1,Force #[unwind(aborts)] in test/codegen/c-variadic.rs,THUMBS_UP,2019-07-12T15:45:30Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/62604,MERGED,2019-07-11T23:55:33Z,2019-07-13T20:46:26Z,Handle errors during error recovery gracefully,estebank,e1c7747cf06bc063a6586c1eab898703f61899d8,3,Handle errors during error recovery gracefully,HOORAY,2019-07-12T03:32:44Z,dwrensha,NA https://github.com/rust-lang/rust/pull/62605,MERGED,2019-07-11T23:59:36Z,2019-07-13T03:13:10Z,Emit dropped unemitted errors to aid in ICE debugging,estebank,c9f7a3d2060a7b2c6f691f4f4b32328edffcf5bd,3,Emit dropped unemitted errors to aid in ICE debugging,HEART,2019-07-12T01:53:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62605,MERGED,2019-07-11T23:59:36Z,2019-07-13T03:13:10Z,Emit dropped unemitted errors to aid in ICE debugging,estebank,c9f7a3d2060a7b2c6f691f4f4b32328edffcf5bd,3,Emit dropped unemitted errors to aid in ICE debugging,HEART,2019-07-12T08:42:53Z,tesuji,NA https://github.com/rust-lang/rust/pull/62607,MERGED,2019-07-12T03:04:08Z,2019-07-13T03:13:10Z,Correctly break out of recovery loop,estebank,8c5f6907a1ddb1dc19a4163775f087a46ca77c40,2,add test case,HOORAY,2019-07-12T03:28:53Z,dwrensha,NA https://github.com/rust-lang/rust/pull/62608,MERGED,2019-07-12T04:18:09Z,2019-07-13T03:13:11Z,`async unsafe fn` tests,delan,5f8d0a1920de9973f980423cd29dbed2eed0b92c,3,test `unsafe fn` and `async unsafe fn` calls in `unsafe { async || }`,HEART,2019-07-12T04:35:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62608,MERGED,2019-07-12T04:18:09Z,2019-07-13T03:13:11Z,`async unsafe fn` tests,delan,5f8d0a1920de9973f980423cd29dbed2eed0b92c,3,test `unsafe fn` and `async unsafe fn` calls in `unsafe { async || }`,HEART,2019-07-18T06:26:15Z,heckad,NA https://github.com/rust-lang/rust/pull/62610,MERGED,2019-07-12T07:36:36Z,2019-07-14T17:30:01Z,Fix miri error in into_inner() of CString,Stargateur,4c4bd3406705066223e9dddb909de7eddbeac861,1,Fix miri error in into_inner() of CString,THUMBS_UP,2019-07-12T07:43:18Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/62639,MERGED,2019-07-12T23:11:38Z,2019-07-16T08:39:22Z,Make VaListImpl<'f> invariant over the 'f lifetime,ahomescu,0c981e0a8a01426dbcac895d67dd33db7f5b6ff4,4,Make VaListImpl<'f> invariant over the 'f lifetime,THUMBS_UP,2019-07-16T12:51:32Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/62644,MERGED,2019-07-13T01:52:03Z,2019-08-01T18:21:46Z,simplify std::io::Write::write rustdoc,arnottcr,e8e13f04b2218fbc5faa9774a1b5bba9296f3389,1,simplify std::io::Write::write rustdoc The std::io::Write::write method currensly suggests consumers guaranteed that `0 <= n <= buf.len()` for `Ok(n)` however `n` is of type `usize` causing the compiler to emit a warning: ``` warning: comparison is useless due to type limits --> lib.rs:6:18 | 6 | Ok(n) => 0 <= n && n <= output.len() | ^^^^^^ | = note: #[warn(unused_comparisons)] on by default ``` This PR removes the suggestion to check `0 <= n` since it is moot. r? @steveklabnik,THUMBS_UP,2019-07-13T03:03:29Z,czipperz,czipperz@gmail.com https://github.com/rust-lang/rust/pull/62653,CLOSED,2019-07-13T12:17:51Z,2019-07-30T20:25:33Z,Updated RELEASES.md for 1.37.0,XAMPPRocky,NA,NA,NA,THUMBS_UP,2019-07-14T17:55:22Z,tesuji,NA https://github.com/rust-lang/rust/pull/62653,CLOSED,2019-07-13T12:17:51Z,2019-07-30T20:25:33Z,Updated RELEASES.md for 1.37.0,XAMPPRocky,NA,NA,NA,HEART,2019-07-15T05:54:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62653,CLOSED,2019-07-13T12:17:51Z,2019-07-30T20:25:33Z,Updated RELEASES.md for 1.37.0,XAMPPRocky,NA,NA,NA,THUMBS_UP,2019-07-28T00:04:30Z,flosse,NA https://github.com/rust-lang/rust/pull/62655,CLOSED,2019-07-13T13:16:39Z,2019-12-17T22:07:24Z,Avoid copying some undef memory in MIR,HeroicKatora,NA,NA,NA,ROCKET,2019-07-15T15:13:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62655,CLOSED,2019-07-13T13:16:39Z,2019-12-17T22:07:24Z,Avoid copying some undef memory in MIR,HeroicKatora,NA,NA,NA,ROCKET,2019-10-08T02:26:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62657,CLOSED,2019-07-13T13:33:37Z,2019-07-14T13:16:41Z,Removing use of mem::uninitialized from std::io::util,JulianGindi,NA,NA,NA,THUMBS_UP,2019-07-13T15:55:19Z,panaman67,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-07-13T16:13:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-07-13T16:35:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-07-14T17:57:32Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-07-17T06:57:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-07-25T23:14:40Z,estebank,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-08-15T08:13:16Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-08-17T00:08:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-08-29T05:47:58Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-09-23T06:57:45Z,crlf0710,NA https://github.com/rust-lang/rust/pull/62661,MERGED,2019-07-13T15:04:41Z,2019-09-26T12:35:31Z,reserve `impl From for T`,arielb1,e70724c23bd2bd5cfbbac784d103f2a61a40284f,2,address rebase damage,HEART,2019-10-03T13:03:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62668,MERGED,2019-07-14T00:52:00Z,2019-07-16T08:39:26Z,Fix #62660,goodmanjonathan,7111328556e0580f1323cde3d5193eb8d2767693,3,Don't drop DiagnosticBuilder if parsing fails If the explicitly given type of a `self` parameter fails to parse correctly we need to propagate the error rather than dropping it and causing an ICE. Fixes #62660.,HOORAY,2019-07-14T02:24:31Z,estebank,NA https://github.com/rust-lang/rust/pull/62669,MERGED,2019-07-14T02:23:00Z,2019-07-18T08:39:29Z,Suggest assoc type on type not found in trait method definition,estebank,6b9580b651fa67ca7cf536ceab995d185202a114,3,Suggest assoc type on type not found in trait method definition,HEART,2019-07-14T09:36:08Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/62669,MERGED,2019-07-14T02:23:00Z,2019-07-18T08:39:29Z,Suggest assoc type on type not found in trait method definition,estebank,6b9580b651fa67ca7cf536ceab995d185202a114,3,Suggest assoc type on type not found in trait method definition,HEART,2019-07-17T18:01:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62669,MERGED,2019-07-14T02:23:00Z,2019-07-18T08:39:29Z,Suggest assoc type on type not found in trait method definition,estebank,6b9580b651fa67ca7cf536ceab995d185202a114,3,Suggest assoc type on type not found in trait method definition,HEART,2019-07-18T12:03:18Z,killercup,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-14T14:37:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-07-14T14:37:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HEART,2019-07-14T14:37:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-07-16T19:31:27Z,estebank,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-17T16:48:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-07-17T16:48:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-18T07:31:50Z,faern,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-23T10:38:23Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,CONFUSED,2019-07-24T08:30:26Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_DOWN,2019-07-24T15:21:33Z,novacrazy,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_DOWN,2019-07-24T16:45:35Z,Thiez,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-07-24T19:40:21Z,chrish42,NA https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-25T03:05:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-07-25T03:05:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HEART,2019-07-25T03:05:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_DOWN,2019-07-25T10:21:23Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-07-25T11:03:28Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-08-09T13:24:47Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,HOORAY,2019-08-14T19:32:36Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/62672,MERGED,2019-07-14T08:19:37Z,2019-08-09T15:54:54Z,Deprecate `try!` macro,tesuji,6842316f6ff4586465e6412edce5e6808cfcd396,7,Allow deprecated try macro in test crates,THUMBS_UP,2019-08-15T17:47:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62673,MERGED,2019-07-14T09:56:04Z,2019-07-16T08:39:28Z,miri validation: better error messages for dangling references,RalfJung,5db782767c1b1ee0dd5b0119fed9a1b99410237f,3,miri validation: better error messages for dangling references,HEART,2019-07-14T14:36:52Z,panaman67,NA https://github.com/rust-lang/rust/pull/62678,CLOSED,2019-07-14T15:58:59Z,2019-07-29T11:20:22Z,Implement VEC_NEW internal lint,flip1995,NA,NA,NA,CONFUSED,2019-07-14T16:01:37Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/62678,CLOSED,2019-07-14T15:58:59Z,2019-07-29T11:20:22Z,Implement VEC_NEW internal lint,flip1995,NA,NA,NA,CONFUSED,2019-07-14T21:36:05Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/62678,CLOSED,2019-07-14T15:58:59Z,2019-07-29T11:20:22Z,Implement VEC_NEW internal lint,flip1995,NA,NA,NA,THUMBS_UP,2019-07-16T05:59:56Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/62681,CLOSED,2019-07-14T23:13:01Z,2019-09-16T10:26:56Z,expand osx sanitizer support (lsan dylib cdylib staticlib),mtak-,NA,NA,NA,HOORAY,2019-07-17T19:49:02Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62690,MERGED,2019-07-15T15:29:36Z,2019-07-19T19:35:00Z,azure: Prepare configuration for 4-core machines,alexcrichton,9b4f6de7a47c87f78f88a70397cf222d8e359e35,5,azure: Prepare configuration for 4-core machines This commit updates some of our assorted Azure/CI configuration to prepare for some 4-core machines coming online. We're still in the process of performance testing them to get final numbers but some changes are worth landing ahead of this. The updates here are: * Use `C:/` instead of `D:/` for submodule checkout since it should have plenty of space and the 4-core machines won't have `D:/` * Update `lzma-sys` to 0.1.14 which has support for VS2019 where 0.1.10 doesn't. * Update `src/ci/docker/run.sh` to work when it itself is running inside of a docker container (see the comment in the file for more info) * Print step timings on the `try` branch in addition to the `auto` branch in. The logs there should be seen by similarly many humans (not many) and can be useful for performance analysis after a `try` build runs. * Install the WIX and InnoSetup tools manually on Windows instead of relying on pre-installed copies on the VM. This gives us more control over what's being used on the Azure cloud right now (we control the version) and in the 4-core machines these won't be pre-installed. Note that on AppVeyor we actually already were installing InnoSetup we just didn't carry that over on Azure!,HOORAY,2019-07-16T23:53:14Z,mati865,NA https://github.com/rust-lang/rust/pull/62693,MERGED,2019-07-15T16:23:56Z,2019-07-16T19:26:43Z,ci: Remove Travis/AppVeyor configuration,alexcrichton,3dd00bac7c60452055b657903da9c736149140ad,15,ci: Remove Travis/AppVeyor configuration Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around and if Azure ever adds support we can always add it back!,HEART,2019-07-15T16:31:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/62693,MERGED,2019-07-15T16:23:56Z,2019-07-16T19:26:43Z,ci: Remove Travis/AppVeyor configuration,alexcrichton,3dd00bac7c60452055b657903da9c736149140ad,15,ci: Remove Travis/AppVeyor configuration Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around and if Azure ever adds support we can always add it back!,ROCKET,2019-07-15T16:31:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/62693,MERGED,2019-07-15T16:23:56Z,2019-07-16T19:26:43Z,ci: Remove Travis/AppVeyor configuration,alexcrichton,3dd00bac7c60452055b657903da9c736149140ad,15,ci: Remove Travis/AppVeyor configuration Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around and if Azure ever adds support we can always add it back!,HEART,2019-07-15T16:33:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62693,MERGED,2019-07-15T16:23:56Z,2019-07-16T19:26:43Z,ci: Remove Travis/AppVeyor configuration,alexcrichton,3dd00bac7c60452055b657903da9c736149140ad,15,ci: Remove Travis/AppVeyor configuration Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around and if Azure ever adds support we can always add it back!,ROCKET,2019-07-15T16:33:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62693,MERGED,2019-07-15T16:23:56Z,2019-07-16T19:26:43Z,ci: Remove Travis/AppVeyor configuration,alexcrichton,3dd00bac7c60452055b657903da9c736149140ad,15,ci: Remove Travis/AppVeyor configuration Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around and if Azure ever adds support we can always add it back!,ROCKET,2019-07-15T18:11:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62694,MERGED,2019-07-15T16:41:53Z,2019-07-19T07:49:47Z,rustc_typeck: improve diagnostics for -> _ fn return type,lundibundi,f8681f0c05c91df4aaf90a0ca60d1f823cf89d9d,6,rustc_typeck: improve diagnostics for -> _ fn return type Closes: https://github.com/rust-lang/rust/issues/56132,HEART,2019-07-16T18:58:49Z,estebank,NA https://github.com/rust-lang/rust/pull/62694,MERGED,2019-07-15T16:41:53Z,2019-07-19T07:49:47Z,rustc_typeck: improve diagnostics for -> _ fn return type,lundibundi,f8681f0c05c91df4aaf90a0ca60d1f823cf89d9d,6,rustc_typeck: improve diagnostics for -> _ fn return type Closes: https://github.com/rust-lang/rust/issues/56132,HEART,2019-07-16T19:02:54Z,varkor,NA https://github.com/rust-lang/rust/pull/62694,MERGED,2019-07-15T16:41:53Z,2019-07-19T07:49:47Z,rustc_typeck: improve diagnostics for -> _ fn return type,lundibundi,f8681f0c05c91df4aaf90a0ca60d1f823cf89d9d,6,rustc_typeck: improve diagnostics for -> _ fn return type Closes: https://github.com/rust-lang/rust/issues/56132,HEART,2019-07-16T22:38:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62694,MERGED,2019-07-15T16:41:53Z,2019-07-19T07:49:47Z,rustc_typeck: improve diagnostics for -> _ fn return type,lundibundi,f8681f0c05c91df4aaf90a0ca60d1f823cf89d9d,6,rustc_typeck: improve diagnostics for -> _ fn return type Closes: https://github.com/rust-lang/rust/issues/56132,HEART,2019-07-24T18:07:53Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/62705,MERGED,2019-07-16T00:08:36Z,2019-07-20T00:45:35Z,libsyntax: Rename `Mark` into `ExpnId`,petrochenkov,8f30d260304ffc260764e51b2d3e40d1734df502,7,hygiene: Tweak naming some more,HEART,2019-07-16T07:16:32Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62705,MERGED,2019-07-16T00:08:36Z,2019-07-20T00:45:35Z,libsyntax: Rename `Mark` into `ExpnId`,petrochenkov,8f30d260304ffc260764e51b2d3e40d1734df502,7,hygiene: Tweak naming some more,HEART,2019-07-16T22:04:41Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/62705,MERGED,2019-07-16T00:08:36Z,2019-07-20T00:45:35Z,libsyntax: Rename `Mark` into `ExpnId`,petrochenkov,8f30d260304ffc260764e51b2d3e40d1734df502,7,hygiene: Tweak naming some more,HEART,2019-07-18T15:49:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/62705,MERGED,2019-07-16T00:08:36Z,2019-07-20T00:45:35Z,libsyntax: Rename `Mark` into `ExpnId`,petrochenkov,8f30d260304ffc260764e51b2d3e40d1734df502,7,hygiene: Tweak naming some more,HEART,2019-07-18T21:59:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62707,MERGED,2019-07-16T02:10:40Z,2019-07-26T02:18:25Z,Add tests for overlapping explicitly dropped locals in generators,JohnTitor,404281125e565a4889910657504112789c75a11e,1,Use Foo instead of raw arrays,HEART,2019-07-25T01:20:48Z,tmandry,NA https://github.com/rust-lang/rust/pull/62712,MERGED,2019-07-16T04:35:12Z,2019-07-18T20:42:21Z,Update the help message on error for self type,limira,b7cbd4ec47640323e5b25cc64110f5ff414e4946,6,Update the help message on error for self type,THUMBS_UP,2019-07-16T04:42:03Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/62712,MERGED,2019-07-16T04:35:12Z,2019-07-18T20:42:21Z,Update the help message on error for self type,limira,b7cbd4ec47640323e5b25cc64110f5ff414e4946,6,Update the help message on error for self type,THUMBS_UP,2019-07-16T16:17:32Z,estebank,NA https://github.com/rust-lang/rust/pull/62713,MERGED,2019-07-16T06:54:56Z,2019-07-22T20:47:39Z,Stabilize <*mut _>::cast and <*const _>::cast,SimonSapin,8040c54b085967bc6b29cf6d27eda5908c204ca3,1,Stabilize <*mut _>::cast and <*const _>::cast FCP: https://github.com/rust-lang/rust/issues/60602#issuecomment-511146402,HEART,2019-07-17T16:48:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62713,MERGED,2019-07-16T06:54:56Z,2019-07-22T20:47:39Z,Stabilize <*mut _>::cast and <*const _>::cast,SimonSapin,8040c54b085967bc6b29cf6d27eda5908c204ca3,1,Stabilize <*mut _>::cast and <*const _>::cast FCP: https://github.com/rust-lang/rust/issues/60602#issuecomment-511146402,HEART,2019-07-23T08:29:53Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/62713,MERGED,2019-07-16T06:54:56Z,2019-07-22T20:47:39Z,Stabilize <*mut _>::cast and <*const _>::cast,SimonSapin,8040c54b085967bc6b29cf6d27eda5908c204ca3,1,Stabilize <*mut _>::cast and <*const _>::cast FCP: https://github.com/rust-lang/rust/issues/60602#issuecomment-511146402,HEART,2019-07-25T02:31:18Z,Lokathor,NA https://github.com/rust-lang/rust/pull/62713,MERGED,2019-07-16T06:54:56Z,2019-07-22T20:47:39Z,Stabilize <*mut _>::cast and <*const _>::cast,SimonSapin,8040c54b085967bc6b29cf6d27eda5908c204ca3,1,Stabilize <*mut _>::cast and <*const _>::cast FCP: https://github.com/rust-lang/rust/issues/60602#issuecomment-511146402,HEART,2019-07-25T03:30:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62713,MERGED,2019-07-16T06:54:56Z,2019-07-22T20:47:39Z,Stabilize <*mut _>::cast and <*const _>::cast,SimonSapin,8040c54b085967bc6b29cf6d27eda5908c204ca3,1,Stabilize <*mut _>::cast and <*const _>::cast FCP: https://github.com/rust-lang/rust/issues/60602#issuecomment-511146402,HEART,2019-08-07T10:15:27Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/62730,MERGED,2019-07-16T20:34:47Z,2019-07-18T20:42:23Z,Consolidate hygiene tests,matthewjasper,a4a7bb9a3f72505efb6ca9856af45287c8685d5e,3,Make pretty-expanded-hygiene a `ui` test `normalize-stdout-test` removes the need for Make and it can be updated with `--bless` this way,HEART,2019-07-16T23:44:20Z,panaman67,NA https://github.com/rust-lang/rust/pull/62733,MERGED,2019-07-16T21:09:38Z,2019-07-18T03:13:20Z,Update mdbook cargo books,ehuss,04538c680c7a18b9e9a8419456aa3c6f82e2403b,13,Update mdbook cargo books This updates the last of the books using mdbook 0.1 finally removing it from the build.,HEART,2019-07-16T23:43:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/62733,MERGED,2019-07-16T21:09:38Z,2019-07-18T03:13:20Z,Update mdbook cargo books,ehuss,04538c680c7a18b9e9a8419456aa3c6f82e2403b,13,Update mdbook cargo books This updates the last of the books using mdbook 0.1 finally removing it from the build.,HOORAY,2019-07-16T23:49:20Z,mati865,NA https://github.com/rust-lang/rust/pull/62735,MERGED,2019-07-16T22:52:03Z,2019-07-26T02:18:27Z,Turn `#[global_allocator]` into a regular attribute macro,petrochenkov,a0c2c640d54fa1622c2fea4accae1025bf109c47,1,Fix rebase,HOORAY,2019-07-17T01:11:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62735,MERGED,2019-07-16T22:52:03Z,2019-07-26T02:18:27Z,Turn `#[global_allocator]` into a regular attribute macro,petrochenkov,a0c2c640d54fa1622c2fea4accae1025bf109c47,1,Fix rebase,HOORAY,2019-07-17T05:45:45Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/62735,MERGED,2019-07-16T22:52:03Z,2019-07-26T02:18:27Z,Turn `#[global_allocator]` into a regular attribute macro,petrochenkov,a0c2c640d54fa1622c2fea4accae1025bf109c47,1,Fix rebase,HOORAY,2019-07-17T05:50:27Z,jq-rs,NA https://github.com/rust-lang/rust/pull/62735,MERGED,2019-07-16T22:52:03Z,2019-07-26T02:18:27Z,Turn `#[global_allocator]` into a regular attribute macro,petrochenkov,a0c2c640d54fa1622c2fea4accae1025bf109c47,1,Fix rebase,HOORAY,2019-07-23T06:07:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62735,MERGED,2019-07-16T22:52:03Z,2019-07-26T02:18:27Z,Turn `#[global_allocator]` into a regular attribute macro,petrochenkov,a0c2c640d54fa1622c2fea4accae1025bf109c47,1,Fix rebase,HOORAY,2019-09-27T05:52:48Z,Gordon-x,NA https://github.com/rust-lang/rust/pull/62737,MERGED,2019-07-16T23:30:22Z,2019-08-17T12:54:10Z,Override Cycle::try_fold,timvermeulen,688c11216aca1d7449b07b3ebbcee3ba114d0d51,2,Override Cycle::try_fold,HEART,2019-07-27T22:00:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62740,MERGED,2019-07-17T03:44:41Z,2019-07-18T20:42:26Z,Add missing link to Infallible in TryFrom doc,tesuji,6471bd5f199a2825b23082a26574b1c26970b0e4,1,Add missing link to Infallible in TryFrom doc,THUMBS_UP,2019-07-17T06:56:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62748,MERGED,2019-07-17T11:31:26Z,2019-07-27T13:10:12Z,Optimize RefCell read borrowing,luca-barbieri,44c165074b1b034799c6e1b95a871cde46755632,1,fix comment,HEART,2019-07-17T13:16:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/62748,MERGED,2019-07-17T11:31:26Z,2019-07-27T13:10:12Z,Optimize RefCell read borrowing,luca-barbieri,44c165074b1b034799c6e1b95a871cde46755632,1,fix comment,HEART,2019-07-17T19:51:08Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-18T02:31:54Z,ehuss,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-18T07:00:42Z,est31,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-18T14:06:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-18T21:43:17Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-29T05:37:44Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-07-31T23:14:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-03T19:50:25Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-10T01:01:00Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-11T21:23:39Z,aloucks,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-15T12:18:55Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-15T17:47:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-08-19T16:47:57Z,busimus,NA https://github.com/rust-lang/rust/pull/62756,MERGED,2019-07-17T15:38:17Z,2019-08-10T05:01:46Z,Stabilize duration_float,newpavlov,4281e6136df6886462e8da4e45877f6eeecd552a,1,fix tests,HOORAY,2019-09-06T16:36:10Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62757,MERGED,2019-07-17T16:26:06Z,2019-07-17T23:21:06Z,ci: fix LinuxTools PR builder missing environment variables,pietroalbini,9926868195f3942c2c0d85e388c0ad1f8d2ab997,1,ci: include public credentials in the linuxtools pr job This allows the use of sccache to compile LLVM and should fix toolstate not working.,HOORAY,2019-07-17T19:33:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62759,MERGED,2019-07-17T16:45:13Z,2019-07-28T12:50:57Z,Actually add rustc-guide to toolstate don't fail builds for the guide,mark-i-m,11a3b742d8dfae9c9d4858adc5417918e13d84a5,1,add back check for update prs,THUMBS_UP,2019-07-17T16:54:44Z,ehuss,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-17T22:46:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T01:06:32Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T06:51:28Z,est31,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T08:09:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T08:49:31Z,mati865,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T10:25:55Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T13:25:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T14:02:23Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-18T15:00:09Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-30T12:10:00Z,tesuji,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-07-30T20:16:56Z,frol,NA https://github.com/rust-lang/rust/pull/62766,MERGED,2019-07-17T21:13:34Z,2019-07-30T12:26:57Z,rustc: Stabilize options for pipelined compilation,alexcrichton,17312337a9eb16389d11eca8472d1d083aa473bd,26,"rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable ""pipelined compilation"" by default. The concept of pipelined compilation how it's implemented and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987 the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a ""short"" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988",HOORAY,2019-08-08T18:53:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-18T04:56:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-18T06:30:30Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-18T07:18:09Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-18T07:25:51Z,sinkuu,NA https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-18T08:51:54Z,mati865,NA https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-19T18:07:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-24T19:01:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62771,MERGED,2019-07-17T23:28:55Z,2019-07-28T04:57:11Z,Break dependencies between `syntax_ext` and other crates,petrochenkov,b5a0e6ea807bcdc71f145038dd1129c22dcf17fd,10,syntax_ext: `proc_macro_decls` -> `proc_macro_harness` Few other minor renamings for consistency. Remove one unused dependency from `rustc_passes`. Fix libsyntax tests. Fix rebase.,HEART,2019-07-27T21:01:27Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/62772,MERGED,2019-07-17T23:35:40Z,2019-07-24T19:50:37Z,Suggest trait bound on type parameter when it is unconstrained,estebank,f22bc2d3ff650c3f0e5d492d18235d79ebdec230,5,Suggest trait bound on type parameter when it is unconstrained Given ``` mented on Jan 26 2015 • trait Foo { fn method(&self) {} } fn call_method(x: &T) { x.method() } ``` suggest constraining `T` with `Foo`.,THUMBS_UP,2019-07-18T14:26:29Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/62784,MERGED,2019-07-18T17:13:23Z,2019-07-25T05:46:27Z,Add riscv32i-unknown-none-elf target,Disasm,bb9bf0ca9a9eaeb14e910ff23037c02c14cdb494,4,Add riscv32i-unknown-none-elf target,HOORAY,2019-08-01T16:02:58Z,sameer,NA https://github.com/rust-lang/rust/pull/62789,MERGED,2019-07-18T22:06:27Z,2019-07-20T15:56:13Z,Update pulldown-cmark version,GuillaumeGomez,9d6b29af5a8ed31a017ab71f5d59f1e3b224ff8f,2,Update pulldown-cmark version,THUMBS_UP,2019-07-19T07:55:57Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62789,MERGED,2019-07-18T22:06:27Z,2019-07-20T15:56:13Z,Update pulldown-cmark version,GuillaumeGomez,9d6b29af5a8ed31a017ab71f5d59f1e3b224ff8f,2,Update pulldown-cmark version,THUMBS_UP,2019-07-19T13:19:09Z,Cldfire,NA https://github.com/rust-lang/rust/pull/62799,MERGED,2019-07-19T12:48:16Z,2019-07-22T20:47:47Z,use const array repeat expressions for uninit_array,RalfJung,f3abbf71035e469fce6db37bdb444ce3e50e870f,1,tidy is being silly,HOORAY,2019-07-19T16:57:18Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/62799,MERGED,2019-07-19T12:48:16Z,2019-07-22T20:47:47Z,use const array repeat expressions for uninit_array,RalfJung,f3abbf71035e469fce6db37bdb444ce3e50e870f,1,tidy is being silly,HOORAY,2019-07-22T13:58:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/62799,MERGED,2019-07-19T12:48:16Z,2019-07-22T20:47:47Z,use const array repeat expressions for uninit_array,RalfJung,f3abbf71035e469fce6db37bdb444ce3e50e870f,1,tidy is being silly,HEART,2019-07-22T13:58:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/62799,MERGED,2019-07-19T12:48:16Z,2019-07-22T20:47:47Z,use const array repeat expressions for uninit_array,RalfJung,f3abbf71035e469fce6db37bdb444ce3e50e870f,1,tidy is being silly,HOORAY,2019-08-02T04:36:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62822,MERGED,2019-07-20T11:20:41Z,2019-07-26T02:18:32Z,Improve some pointer-related documentation,RalfJung,65cf10d90276e40bd8cc27a79d6c6f0d13e0cc7a,1,word things more like we usually do,EYES,2019-07-20T14:35:57Z,Lokathor,NA https://github.com/rust-lang/rust/pull/62822,MERGED,2019-07-20T11:20:41Z,2019-07-26T02:18:32Z,Improve some pointer-related documentation,RalfJung,65cf10d90276e40bd8cc27a79d6c6f0d13e0cc7a,1,word things more like we usually do,THUMBS_UP,2019-07-20T14:36:02Z,Lokathor,NA https://github.com/rust-lang/rust/pull/62827,MERGED,2019-07-20T15:20:37Z,2019-07-25T05:46:31Z,Don't link mcjit/interpreter LLVM components,nikic,b9784b18c2d18dee7100529fd0cbadc8fa331a62,3,Don't link mcjit/interpreter LLVM components,HEART,2019-07-21T02:23:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/62828,MERGED,2019-07-20T15:24:50Z,2019-07-26T20:42:13Z,Remove vector fadd/fmul reduction workarounds,nikic,6fae7db65d5f772cfbf116fbb9e5944447725289,7,Remove vector fadd/fmul reduction workarounds The bugs that this was working around have been fixed in LLVM 9.,HEART,2019-07-21T02:22:04Z,panaman67,NA https://github.com/rust-lang/rust/pull/62829,CLOSED,2019-07-20T16:12:21Z,2019-08-05T14:50:11Z,[WIP EXPERIMENTAL] Update to libtest 0.0.2,crlf0710,NA,NA,NA,THUMBS_UP,2019-07-24T15:07:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/62848,MERGED,2019-07-21T12:51:16Z,2019-09-05T16:27:45Z,Use unicode-xid crate instead of libcore,matklad,206fe8e1c37d55d0bf3a82baaa23eb5fb148880b,7,flatten rustc_lexer::character_properties module On the call site `rustc_lexer::is_whitespace` reads much better than `character_properties::is_whitespace`.,HEART,2019-07-24T20:54:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/62848,MERGED,2019-07-21T12:51:16Z,2019-09-05T16:27:45Z,Use unicode-xid crate instead of libcore,matklad,206fe8e1c37d55d0bf3a82baaa23eb5fb148880b,7,flatten rustc_lexer::character_properties module On the call site `rustc_lexer::is_whitespace` reads much better than `character_properties::is_whitespace`.,HEART,2019-09-12T08:17:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62851,MERGED,2019-07-21T14:00:34Z,2019-07-23T23:37:45Z,move unescape module to rustc_lexer,matklad,e63fe150bfbce632dd7ff0a656a4180557128e4f,6,move unescape module to rustc_lexer,THUMBS_UP,2019-08-02T04:33:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HEART,2019-07-21T18:50:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HEART,2019-07-28T14:49:56Z,taiki-e,NA https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HEART,2019-07-29T10:30:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HEART,2019-08-04T18:11:35Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HOORAY,2019-08-07T16:50:10Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/62855,MERGED,2019-07-21T17:25:34Z,2019-08-29T05:05:28Z,Improve Rustdoc's handling of procedural macros,Aaron1011,4c3e386bd7ee9020407cee4ba120eebfb6373549,1,Allow running rustdoc on proc-macro crates without specifying '--crate-type proc-macro' Add a test to make sure that this works,HEART,2019-09-05T04:44:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62860,MERGED,2019-07-21T22:10:59Z,2019-09-05T06:03:52Z,Stabilize checked_duration_since for 1.39.0,vi,5545582a6f6111872cdda54d18f43a7da24661f4,1,Avoid feature name 'checked_duration_since' in a Tidy test,THUMBS_UP,2019-08-06T13:04:12Z,faern,NA https://github.com/rust-lang/rust/pull/62862,MERGED,2019-07-22T01:37:34Z,2019-07-26T20:42:15Z,code cleanup,BaoshanPang,279c399599357cdb40d2bbe24a769d2d1dd4a9d9,11,code cleanup,HEART,2019-07-22T04:20:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/62869,MERGED,2019-07-22T09:22:51Z,2019-07-23T23:37:47Z,add rustc_private as a proper language feature gate,matklad,7e612c19bee19b41796e8a4f4fe8a41714d7b3c7,1,Update src/librustc_lexer/src/lib.rs Co-Authored-By: Ralf Jung ,THUMBS_UP,2019-07-22T16:40:44Z,ljedrz,NA https://github.com/rust-lang/rust/pull/62871,MERGED,2019-07-22T12:16:49Z,2019-07-29T00:09:08Z,Explicit error message for async recursion.,gilescope,4b1d404d833929dffcc1ea8d704aa3d2c432ba11,3,Better recursive async fn error message. Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-07-24T05:34:20Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/62871,MERGED,2019-07-22T12:16:49Z,2019-07-29T00:09:08Z,Explicit error message for async recursion.,gilescope,4b1d404d833929dffcc1ea8d704aa3d2c432ba11,3,Better recursive async fn error message. Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-07-25T18:25:45Z,estebank,NA https://github.com/rust-lang/rust/pull/62883,MERGED,2019-07-22T23:06:40Z,2019-07-28T04:57:16Z,Refactoring use common code between option result and accum,Stargateur,3334802c83070d63b85b5b2e5508c15bfaf6e254,5,Refactoring use commun code between option result and accum,HEART,2019-07-23T00:13:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/62898,CLOSED,2019-07-23T15:01:29Z,2019-07-23T22:47:45Z,Share expansion definition data between expansions with the same definition,petrochenkov,NA,NA,NA,HEART,2019-07-23T16:42:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/62901,MERGED,2019-07-23T16:22:59Z,2019-07-25T05:46:36Z,cleanup: Remove `extern crate serialize as rustc_serialize`s,petrochenkov,614037171bf0140390033cc60f5e99aac079a0e5,52,cleanup: Remove `extern crate serialize as rustc_serialize`s,HEART,2019-07-23T16:40:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/62901,MERGED,2019-07-23T16:22:59Z,2019-07-25T05:46:36Z,cleanup: Remove `extern crate serialize as rustc_serialize`s,petrochenkov,614037171bf0140390033cc60f5e99aac079a0e5,52,cleanup: Remove `extern crate serialize as rustc_serialize`s,HEART,2019-07-23T16:46:13Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/62901,MERGED,2019-07-23T16:22:59Z,2019-07-25T05:46:36Z,cleanup: Remove `extern crate serialize as rustc_serialize`s,petrochenkov,614037171bf0140390033cc60f5e99aac079a0e5,52,cleanup: Remove `extern crate serialize as rustc_serialize`s,HEART,2019-07-23T19:54:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62904,MERGED,2019-07-23T18:35:42Z,2019-07-26T20:42:17Z,Disable d32 on armv6 hf targets,nikic,fe4cdd3078d43fc9d462e27f9dddcdef34ebe98e,4,Disable d32 on armv6 hf targets,THUMBS_UP,2019-07-24T15:11:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/62910,MERGED,2019-07-23T20:40:26Z,2019-07-28T20:23:14Z,cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild,petrochenkov,1a370109ec176fa33a9cac2fe143b43c56ebcfd9,5,Fix `cfg(parallel_compiler)` mode Fix rebase,THUMBS_UP,2019-07-23T20:55:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/62910,MERGED,2019-07-23T20:40:26Z,2019-07-28T20:23:14Z,cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild,petrochenkov,1a370109ec176fa33a9cac2fe143b43c56ebcfd9,5,Fix `cfg(parallel_compiler)` mode Fix rebase,HOORAY,2019-07-23T20:55:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/62910,MERGED,2019-07-23T20:40:26Z,2019-07-28T20:23:14Z,cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild,petrochenkov,1a370109ec176fa33a9cac2fe143b43c56ebcfd9,5,Fix `cfg(parallel_compiler)` mode Fix rebase,HEART,2019-07-23T20:55:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/62910,MERGED,2019-07-23T20:40:26Z,2019-07-28T20:23:14Z,cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild,petrochenkov,1a370109ec176fa33a9cac2fe143b43c56ebcfd9,5,Fix `cfg(parallel_compiler)` mode Fix rebase,HEART,2019-07-24T08:30:25Z,mati865,NA https://github.com/rust-lang/rust/pull/62910,MERGED,2019-07-23T20:40:26Z,2019-07-28T20:23:14Z,cleanup: Remove lint annotations in specific crates that are already enforced by rustbuild,petrochenkov,1a370109ec176fa33a9cac2fe143b43c56ebcfd9,5,Fix `cfg(parallel_compiler)` mode Fix rebase,THUMBS_UP,2019-07-27T06:00:17Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/62921,MERGED,2019-07-23T23:57:47Z,2019-07-26T02:18:39Z,Add method disambiguation help for trait implementation,iluuu1994,be510dbc35960c9d90f42811787eea2acef8ffe5,8,Adjust tests for method disambiguation help,HEART,2019-07-24T00:21:39Z,estebank,NA https://github.com/rust-lang/rust/pull/62921,MERGED,2019-07-23T23:57:47Z,2019-07-26T02:18:39Z,Add method disambiguation help for trait implementation,iluuu1994,be510dbc35960c9d90f42811787eea2acef8ffe5,8,Adjust tests for method disambiguation help,HEART,2019-08-02T04:33:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62928,MERGED,2019-07-24T09:15:03Z,2019-07-30T07:20:37Z,Syntax: Recover on `for ( $pat in $expr ) $block`,Centril,56b39fba563a7ae5ca39eae80b9e26e9890522cf,2,Add 'span_to_snippet' shortcut.,LAUGH,2019-07-24T16:24:08Z,estebank,NA https://github.com/rust-lang/rust/pull/62928,MERGED,2019-07-24T09:15:03Z,2019-07-30T07:20:37Z,Syntax: Recover on `for ( $pat in $expr ) $block`,Centril,56b39fba563a7ae5ca39eae80b9e26e9890522cf,2,Add 'span_to_snippet' shortcut.,THUMBS_UP,2019-07-24T17:49:24Z,PramodBisht,NA https://github.com/rust-lang/rust/pull/62928,MERGED,2019-07-24T09:15:03Z,2019-07-30T07:20:37Z,Syntax: Recover on `for ( $pat in $expr ) $block`,Centril,56b39fba563a7ae5ca39eae80b9e26e9890522cf,2,Add 'span_to_snippet' shortcut.,THUMBS_UP,2019-08-08T19:18:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62943,MERGED,2019-07-24T17:51:27Z,2019-07-28T16:35:34Z,submodules: update clippy from 164310dd to dc69a5c0,matthiaskrgr,79e612354e24273b9c5876169d13a24eb5d57089,1,"submodules: update clippy from 164310dd to dc69a5c0 Changes: ```` ci: temporarily disable rustfmt checks/tetss since it's broken for nightly rustup https://github.com/rust-lang/rust/pull/62964 Bump version of clippy_dummy update test stderr not sure which rustc pull request caused this. rustup https://github.com/rust-lang/rust/pull/62859 Fix tests for edition 2018 compatibility Revert ""Revert global fmt config and use `rustfmt::skip`"" Fix breakage due to rust-lang/rust#60913 Fix breakage due to rust-lang/rust#62705 Revert global fmt config and use `rustfmt::skip` Fix fmt rustup https://github.com/rust-lang/rust/pull/62679/ Update pulldown-cmark to 0.5.3 rustup https://github.com/rust-lang/rust/pull/62764 Add test Format code Decrease maximum length for stderr files Improved imports Fix ""unkown clippy lint"" error in UI test. Corrections for PR review. Implement lint for inherent to_string() method. UI Test Cleanup: Extract match_ref_pats tests Update UI tests Allow no_effect lint Remove comment cargo fmt UI Test Cleanup: Split up checked_unwrap tests Removed lintining on never type. UI Test Cleanup: Split out out_of_bounds_indexing false positives fixes of `implicit_return` Ignore generated fresh lifetimes in elision check. ````",ROCKET,2019-07-24T18:19:21Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/62946,MERGED,2019-07-24T18:40:40Z,2019-08-03T12:15:53Z,Miri: dispatch first on the type,RalfJung,b9db95edb1136de4230bb2e130c4e09b06f7f3a7,2,fix rebase fallout,HEART,2019-07-24T19:07:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/62946,MERGED,2019-07-24T18:40:40Z,2019-08-03T12:15:53Z,Miri: dispatch first on the type,RalfJung,b9db95edb1136de4230bb2e130c4e09b06f7f3a7,2,fix rebase fallout,HEART,2019-07-24T20:01:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/62946,MERGED,2019-07-24T18:40:40Z,2019-08-03T12:15:53Z,Miri: dispatch first on the type,RalfJung,b9db95edb1136de4230bb2e130c4e09b06f7f3a7,2,fix rebase fallout,HEART,2019-07-25T00:33:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62946,MERGED,2019-07-24T18:40:40Z,2019-08-03T12:15:53Z,Miri: dispatch first on the type,RalfJung,b9db95edb1136de4230bb2e130c4e09b06f7f3a7,2,fix rebase fallout,HEART,2019-07-31T11:09:39Z,mati865,NA https://github.com/rust-lang/rust/pull/62950,MERGED,2019-07-24T19:22:14Z,2019-08-09T15:54:59Z,Check rustbook links on all platforms when running locally,mati865,c7e16c5f47ac86877ab6c52db61709349e4cf276,4,Check links on all platforms when running locally,HEART,2019-08-06T18:48:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62955,MERGED,2019-07-24T21:32:42Z,2019-08-10T21:02:24Z,rustdoc: general cleanups,Mark-Simulacrum,32f144a5277d80baafcc192a4fd10336b999b6a8,2,Implement Clean on hir::Crate directly,HEART,2019-07-25T04:11:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-07-24T22:53:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-07-25T00:28:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-07-25T00:28:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-07-25T00:28:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-07-25T03:00:39Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-07-25T04:08:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-07-25T04:08:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-07-25T04:08:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-07-25T10:58:29Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-07-25T13:55:45Z,mati865,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-07-25T16:03:50Z,hyarsan,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-07-26T03:12:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-07-27T22:23:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-07-29T15:20:10Z,andre-vm,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-08-03T12:31:00Z,crlf0710,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-08-10T04:59:07Z,froody,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-08-17T00:07:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-09-15T14:11:53Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-09-25T02:02:49Z,kpp,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-04T02:42:17Z,Boscop,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-21T20:00:11Z,varkor,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-21T23:05:15Z,hugecheese,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-21T23:05:15Z,hugecheese,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-21T23:05:16Z,hugecheese,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-24T14:36:16Z,CryZe,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-24T14:36:16Z,CryZe,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-24T14:36:17Z,CryZe,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-25T03:48:19Z,tesuji,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-25T16:59:13Z,Osspial,oss@osspial.net https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-25T19:28:56Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-26T17:05:06Z,Enet4,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-26T17:05:08Z,Enet4,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-26T17:05:11Z,Enet4,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-31T10:08:49Z,Boiethios,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-31T10:08:49Z,Boiethios,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-31T10:08:54Z,Boiethios,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2019-10-31T18:47:59Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-10-31T18:47:59Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HEART,2019-10-31T18:48:00Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2019-11-07T13:44:51Z,Ten0,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2020-04-26T08:15:21Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,HOORAY,2020-05-23T02:27:43Z,juliand665,NA https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2020-07-25T19:42:41Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/62959,MERGED,2019-07-24T22:52:15Z,2019-10-25T07:47:55Z,Add by-value iterator for arrays ,LukasKalbertodt,c36b9ddcb40b81642cef2d1dd17bcd45f54c70da,3,Add UI tests for `array::IntoIter` impls This it to make sure traits are implemented for arrays with length 32 and below while they are not implemented for >= 33.,THUMBS_UP,2021-01-07T10:44:09Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/62970,MERGED,2019-07-25T12:17:49Z,2019-07-26T20:42:24Z,ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar,pietroalbini,b01b5b911f3bb209ee619055a154cd81ca0674be,1,ci: gate toolstate repo pushes on the TOOLSTATE_PUBLISH envvar Unfortunately due to an Azure quirk the TOOLSTATE_REPO_ACCESS_TOKEN is not suitable to gate whether to push new commits to the repo as if it's not defined on the Azure side it will actually be set to the literal `$(TOOLSTATE_REPO_ACCESS_TOKEN)` which screws everything up. This instead adds another non-secret environment variable to gate publishing: TOOLSTATE_PUBLISH. As non-secret environment variables behave correctly this fixes the issue.,HEART,2019-07-25T13:17:55Z,ehuss,NA https://github.com/rust-lang/rust/pull/62971,MERGED,2019-07-25T12:29:37Z,2019-08-01T18:21:59Z,Add keywords item into the sidebar,GuillaumeGomez,08a8de8181e606f009007475c743d4572758e160,2,Add keywords item into the sidebar,HOORAY,2019-07-25T15:05:54Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/62971,MERGED,2019-07-25T12:29:37Z,2019-08-01T18:21:59Z,Add keywords item into the sidebar,GuillaumeGomez,08a8de8181e606f009007475c743d4572758e160,2,Add keywords item into the sidebar,HEART,2019-07-28T01:53:37Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62974,MERGED,2019-07-25T13:58:25Z,2019-07-28T12:51:07Z,bump crossbeam-epoch dependency,RalfJung,c7a599e4df18acae8555a5b9940840349a555560,1,bump crossbeam-epoch dependency,HEART,2019-07-25T16:53:22Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62975,MERGED,2019-07-25T14:26:41Z,2019-09-25T18:35:13Z,Almost fully deprecate hir::map::Map.hir_to_node_id,ljedrz,9a6ca413714271adac017cbdd764a7de8b244001,9,HirIdify hir::Crate.modules,HOORAY,2019-07-25T14:52:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/62975,MERGED,2019-07-25T14:26:41Z,2019-09-25T18:35:13Z,Almost fully deprecate hir::map::Map.hir_to_node_id,ljedrz,9a6ca413714271adac017cbdd764a7de8b244001,9,HirIdify hir::Crate.modules,HOORAY,2019-07-25T16:54:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/62975,MERGED,2019-07-25T14:26:41Z,2019-09-25T18:35:13Z,Almost fully deprecate hir::map::Map.hir_to_node_id,ljedrz,9a6ca413714271adac017cbdd764a7de8b244001,9,HirIdify hir::Crate.modules,HEART,2019-08-05T16:11:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/62975,MERGED,2019-07-25T14:26:41Z,2019-09-25T18:35:13Z,Almost fully deprecate hir::map::Map.hir_to_node_id,ljedrz,9a6ca413714271adac017cbdd764a7de8b244001,9,HirIdify hir::Crate.modules,HOORAY,2019-08-17T00:01:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/62978,MERGED,2019-07-25T16:10:19Z,2019-07-26T02:18:47Z,Remove `cfg(bootstrap)` code for array implementations,LukasKalbertodt,9d39758d14df45956b1a8d8132e3e40c3558dd4b,2,"Remove `cfg(bootstrap)` code for array implementations In PR #62435 (""Use const generics for array impls [part 1]"") the old macro-based implementations were not removed but still used with `cfg(bootstrap)` since the bootstrap compiler had some problems with const generics at the time. This does not seem to be the case anymore so there is no reason to keep the old code.",HEART,2019-07-25T17:53:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/62979,MERGED,2019-07-25T16:30:47Z,2019-07-27T19:28:14Z,Cleanup save-analysis JsonDumper,Mark-Simulacrum,68c0ba284d3729a02392d7379673fb196c4a3711,3,Rename JsonDumper to Dumper The Dumper no longer has anything to do specifically with JSON it merely represents processing into an `Analysis` output.,HEART,2019-07-25T17:50:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/62981,MERGED,2019-07-25T17:11:22Z,2019-07-26T02:18:48Z,Add note suggesting to borrow a String argument to find,estebank,3ab60264b504c1f51b2a9e3dfa20ef0d03bcdaed,3,Add note suggesting to borrow a String argument to find,HEART,2019-08-02T04:29:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/62984,MERGED,2019-07-25T17:34:52Z,2019-08-15T04:24:53Z,Add lint for excess trailing semicolons,nathanwhit,76a134524295a04ed5f336265239ef5f39d089de,6,Update tests for excess semicolon lint,HEART,2019-07-28T01:55:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/62985,MERGED,2019-07-25T19:09:01Z,2019-07-26T20:42:28Z,librustc_errors: Support ui-testing flag in annotate-snippet emitter,phansch,dd0f2ac250e0f733cfbff5498c04312c96bb34fa,4,librustc_errors: Support ui-testing flag in annotate-snippet emitter This adds support for the `-Z ui-testing` flag to the new annotate-snippet diagnostic emitter. The support for the flag was added to `annotate-snippet-rs` in these PRs: * https://github.com/rust-lang/annotate-snippets-rs/pull/3 * https://github.com/rust-lang/annotate-snippets-rs/pull/5 Closes #61811,HEART,2019-07-25T23:08:47Z,estebank,NA https://github.com/rust-lang/rust/pull/63014,MERGED,2019-07-26T16:46:21Z,2019-07-27T19:28:18Z,Stop bare trait lint applying to macro call sites,davidtwco,cae8680544418d838344d9c258030592f0461ee9,3,lowering: Omit bare trait lint on macro call sites This commit implements a hacky fix for detecting when a span is pointing at a macro call site so that bare trait lints are not made incorrectly.,THUMBS_UP,2019-07-26T17:03:06Z,estebank,NA https://github.com/rust-lang/rust/pull/63017,MERGED,2019-07-26T17:53:40Z,2019-08-06T12:02:11Z,Remove special code-path for handing unknown tokens,matklad,b3e8c8bbe27e21a2e67039d9fb9ea41cb83b1499,3,adapt rustdoc to infailable lexer,HEART,2019-07-26T20:56:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/63029,MERGED,2019-07-27T00:27:29Z,2019-07-27T23:02:19Z,Move run-pass tests to ui,petrochenkov,f1c8673ae7584e0c1e53c554ba61b7bf831edf90,16,Fix issues with git converting CRLF to CR UI tests now run on asmjs-unknown-emscripten ignore tests with inline assembly which is not supported on emscripten targets,HEART,2019-07-27T00:45:10Z,estebank,NA https://github.com/rust-lang/rust/pull/63029,MERGED,2019-07-27T00:27:29Z,2019-07-27T23:02:19Z,Move run-pass tests to ui,petrochenkov,f1c8673ae7584e0c1e53c554ba61b7bf831edf90,16,Fix issues with git converting CRLF to CR UI tests now run on asmjs-unknown-emscripten ignore tests with inline assembly which is not supported on emscripten targets,ROCKET,2019-07-27T00:45:12Z,estebank,NA https://github.com/rust-lang/rust/pull/63029,MERGED,2019-07-27T00:27:29Z,2019-07-27T23:02:19Z,Move run-pass tests to ui,petrochenkov,f1c8673ae7584e0c1e53c554ba61b7bf831edf90,16,Fix issues with git converting CRLF to CR UI tests now run on asmjs-unknown-emscripten ignore tests with inline assembly which is not supported on emscripten targets,ROCKET,2019-07-27T00:53:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63029,MERGED,2019-07-27T00:27:29Z,2019-07-27T23:02:19Z,Move run-pass tests to ui,petrochenkov,f1c8673ae7584e0c1e53c554ba61b7bf831edf90,16,Fix issues with git converting CRLF to CR UI tests now run on asmjs-unknown-emscripten ignore tests with inline assembly which is not supported on emscripten targets,HEART,2019-07-27T00:53:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63038,MERGED,2019-07-27T09:49:25Z,2019-07-28T04:57:25Z,Make more informative error on outer attribute after inner,eupn,693be441f4c2d74805b855612556c54438c3022c,1,Fix ui/parser/attr test,HEART,2019-07-27T22:36:38Z,estebank,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-07-28T05:26:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-07-28T14:49:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-07-29T10:31:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-08-03T17:40:28Z,jplatte,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-08-07T16:46:39Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HOORAY,2019-08-07T16:46:57Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HOORAY,2019-08-07T21:26:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-08-07T21:26:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/63048,MERGED,2019-07-27T18:35:44Z,2019-08-04T15:13:23Z,Use doc comments from 'pub use' statements,Aaron1011,7ee9b7a410f955f220e9bbe6ce55c642bafec17b,5,Use doc comments from 'pub use' statements Split off from #62855 Currently rustdoc ignores any doc comments found on 'pub use' statements. As described in issue #58700 this makes it impossible to properly document procedural macros. Any doc comments must be written on the procedural macro definition which must occur in a dedicated proc-macro crate. This means that any doc comments or doc tests cannot reference items defined in re-exporting crate despite the fact that such items may be required to use the procedural macro. To solve this issue this commit allows doc comments to be written on 'pub use' statements. For consistency this applies to *all* 'pub use' statements not just those importing procedural macros. When inlining documentation documentation on 'pub use' statements will be prepended to the documentation of the inlined item. For example the following items: ```rust mod other_mod { /// Doc comment from definition pub struct MyStruct; } /// Doc comment from 'pub use' /// pub use other_mod::MyStruct; ``` will caues the documentation for the re-export of 'MyStruct' to be rendered as: ``` Doc comment from 'pub use' Doc comment from definition ``` Note the empty line in the 'pub use' doc comments - because doc comments are concatenated as-is this ensure that the doc comments on the definition start on a new line.,HEART,2019-08-08T19:20:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63050,MERGED,2019-07-27T20:24:04Z,2019-07-28T04:57:27Z,ci: download awscli from our mirror,pietroalbini,75dfdcb065231811bc9977da1aaf0e66889cbbce,3,ci: download awscli from our mirror This fixes multiple network issues we had when downloading awscli from PyPI on Azure Pipelines by vendoring awscli itself and its dependencies in our S3 bucket. Instructions on how to update the cache are present at the top of src/ci/install-awscli.sh,HEART,2019-07-27T20:26:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63050,MERGED,2019-07-27T20:24:04Z,2019-07-28T04:57:27Z,ci: download awscli from our mirror,pietroalbini,75dfdcb065231811bc9977da1aaf0e66889cbbce,3,ci: download awscli from our mirror This fixes multiple network issues we had when downloading awscli from PyPI on Azure Pipelines by vendoring awscli itself and its dependencies in our S3 bucket. Instructions on how to update the cache are present at the top of src/ci/install-awscli.sh,HOORAY,2019-07-27T20:26:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63053,MERGED,2019-07-27T20:50:51Z,2019-07-29T00:09:16Z,SystemTime docs: recommend Instant for elapsed time,kornelski,55c07b39ae89408c08de4781b2051cc4c7cc7b20,1,SystemTime docs: recommend Instant for elapsed time,THUMBS_UP,2019-07-28T18:29:15Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63056,MERGED,2019-07-28T00:54:53Z,2019-08-10T10:02:12Z,Give built-in macros stable addresses in the standard library,petrochenkov,cbcc7dd182b9bf67d664508b82284c5539ef8819,16,Give built-in macros stable addresses in the standard library,HEART,2019-07-28T01:54:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/63056,MERGED,2019-07-28T00:54:53Z,2019-08-10T10:02:12Z,Give built-in macros stable addresses in the standard library,petrochenkov,cbcc7dd182b9bf67d664508b82284c5539ef8819,16,Give built-in macros stable addresses in the standard library,HEART,2019-07-31T19:38:48Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/63056,MERGED,2019-07-28T00:54:53Z,2019-08-10T10:02:12Z,Give built-in macros stable addresses in the standard library,petrochenkov,cbcc7dd182b9bf67d664508b82284c5539ef8819,16,Give built-in macros stable addresses in the standard library,HEART,2019-08-01T00:56:53Z,sinkuu,NA https://github.com/rust-lang/rust/pull/63056,MERGED,2019-07-28T00:54:53Z,2019-08-10T10:02:12Z,Give built-in macros stable addresses in the standard library,petrochenkov,cbcc7dd182b9bf67d664508b82284c5539ef8819,16,Give built-in macros stable addresses in the standard library,HEART,2019-08-07T15:18:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63056,MERGED,2019-07-28T00:54:53Z,2019-08-10T10:02:12Z,Give built-in macros stable addresses in the standard library,petrochenkov,cbcc7dd182b9bf67d664508b82284c5539ef8819,16,Give built-in macros stable addresses in the standard library,HEART,2019-08-09T19:59:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63059,MERGED,2019-07-28T01:36:25Z,2019-08-03T23:57:58Z,Make `#![feature(bind_by_move_pattern_guards)]` sound without `#[feature(nll)]`,Centril,b289f6f2a402e33e70804522f6b949d0e847fb55,1,cargotest: servo -> caac107ae8145ef2fd20365e2b8fadaf09c2eb3b,HOORAY,2019-07-28T11:31:39Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63059,MERGED,2019-07-28T01:36:25Z,2019-08-03T23:57:58Z,Make `#![feature(bind_by_move_pattern_guards)]` sound without `#[feature(nll)]`,Centril,b289f6f2a402e33e70804522f6b949d0e847fb55,1,cargotest: servo -> caac107ae8145ef2fd20365e2b8fadaf09c2eb3b,HOORAY,2019-08-06T02:44:04Z,estebank,NA https://github.com/rust-lang/rust/pull/63061,MERGED,2019-07-28T04:50:52Z,2019-07-28T12:51:12Z,In which we constantly improve the Vec(Deque) array PartialEq impls,Centril,bfdfa85e73186ef96f082980113f7ace8561efd2,3,Add tests for Vec(Deque) array PartialEq impls.,THUMBS_UP,2019-07-30T14:51:35Z,neoeinstein,marcus@griep.us https://github.com/rust-lang/rust/pull/63061,MERGED,2019-07-28T04:50:52Z,2019-07-28T12:51:12Z,In which we constantly improve the Vec(Deque) array PartialEq impls,Centril,bfdfa85e73186ef96f082980113f7ace8561efd2,3,Add tests for Vec(Deque) array PartialEq impls.,THUMBS_UP,2019-07-31T10:21:11Z,frol,NA https://github.com/rust-lang/rust/pull/63061,MERGED,2019-07-28T04:50:52Z,2019-07-28T12:51:12Z,In which we constantly improve the Vec(Deque) array PartialEq impls,Centril,bfdfa85e73186ef96f082980113f7ace8561efd2,3,Add tests for Vec(Deque) array PartialEq impls.,THUMBS_UP,2019-08-02T04:33:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63083,MERGED,2019-07-28T15:13:06Z,2019-07-30T07:20:45Z,Make generic parameters always use modern hygiene,matthewjasper,0fb9295e1231d0878ec3cd06811e3e0dc8c7ce4f,2,Add another test for const parameter (non) hygiene.,HOORAY,2019-07-28T22:18:47Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63083,MERGED,2019-07-28T15:13:06Z,2019-07-30T07:20:45Z,Make generic parameters always use modern hygiene,matthewjasper,0fb9295e1231d0878ec3cd06811e3e0dc8c7ce4f,2,Add another test for const parameter (non) hygiene.,HOORAY,2019-07-30T10:09:56Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/63083,MERGED,2019-07-28T15:13:06Z,2019-07-30T07:20:45Z,Make generic parameters always use modern hygiene,matthewjasper,0fb9295e1231d0878ec3cd06811e3e0dc8c7ce4f,2,Add another test for const parameter (non) hygiene.,HOORAY,2019-10-19T14:18:12Z,varkor,NA https://github.com/rust-lang/rust/pull/63092,MERGED,2019-07-28T21:50:51Z,2019-07-29T04:02:09Z,Update `impl Trait` gate issues,Centril,2a49dd0db68ad727cdff01856548088913e280ea,3,Update existential_type + impl_trait_in_bindings issue numbers.,THUMBS_UP,2019-07-29T14:22:34Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63117,MERGED,2019-07-29T22:34:42Z,2019-07-31T00:37:14Z,Use global variable 'environ' to pass environments to rtpSpawn,BaoshanPang,f6906ba11b1d8148892aec733e8c7dd147ccc565,1,use gloabl variable 'environ' to pass environments to rtpSpawn,LAUGH,2019-07-30T10:22:02Z,pBeta00n,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-04T00:51:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-16T23:59:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-18T11:11:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-20T07:31:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-26T20:08:01Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-08-27T10:48:03Z,mati865,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-01T23:50:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-04T20:40:32Z,frol,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-05T02:20:33Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,THUMBS_UP,2019-09-05T05:52:26Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-05T11:38:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-06T00:25:15Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,THUMBS_UP,2019-09-06T01:18:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-06T01:53:27Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,THUMBS_UP,2019-09-09T16:43:55Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-11T20:23:56Z,madadam,adam.ciganek@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-12T08:05:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-12T08:46:17Z,bluss,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-09-17T03:12:07Z,d-e-s-o,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,HOORAY,2019-10-14T20:11:58Z,Pzixel,NA https://github.com/rust-lang/rust/pull/63118,MERGED,2019-07-29T23:42:07Z,2019-09-09T16:33:55Z,Stabilize `bind_by_move_pattern_guards` in Rust 1.39.0,Centril,aaa9762651c15ee16ae210b18c843bceab7bf454,1,bind-by-move: add E0008 commented out to error_codes.rs,THUMBS_UP,2019-10-21T14:13:29Z,red75prime,red75prim@gmail.com https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-07-30T09:36:09Z,killercup,NA https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-07-30T15:36:56Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-03T12:33:34Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-07T15:32:22Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-07T20:39:23Z,soluri,NA https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-08T00:35:35Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-08T06:38:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-08T18:51:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-08T20:53:33Z,cfsamson,NA https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-11T20:21:26Z,izik1,NA https://github.com/rust-lang/rust/pull/63121,MERGED,2019-07-30T01:23:07Z,2019-08-03T02:22:00Z,On `format!()` arg count mismatch provide extra info,estebank,22ea38dd792ec9983084a101ca6159999a9b851a,1,fix dedup,HEART,2019-08-14T15:51:49Z,kpp,NA https://github.com/rust-lang/rust/pull/63126,CLOSED,2019-07-30T06:15:34Z,2019-07-30T12:11:29Z,Update to rustfmt v1.4.1 / 9e960e7d6a0c6b7c46c195acbd6f92ade6eec3ba,SimonSapin,NA,NA,NA,THUMBS_UP,2019-07-30T09:15:00Z,rw,NA https://github.com/rust-lang/rust/pull/63127,MERGED,2019-07-30T06:56:54Z,2019-08-28T07:29:20Z,Cleanup: Consistently use `Param` instead of `Arg` #62426,kper,97319b2b952c32ac1f0b36a834615b60b0376797,6,Changing error messages and renaming tests #63127 `async-await/no-args-non-move-async-closure` `generator/no-arguments-on-generators`,HEART,2019-08-18T19:29:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/63146,MERGED,2019-07-30T19:13:32Z,2019-08-03T16:15:12Z,Cleanup syntax::attr,Mark-Simulacrum,c146344e32018a8b28c456352a873f9feafd6ff3,2,Decode AttrId via mk_attr_id,HEART,2019-07-30T20:01:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/63152,MERGED,2019-07-31T00:47:31Z,2019-08-07T08:07:12Z,Always error on `SizeOverflow` during mir evaluation,estebank,3144b0aa04e9a1857cfb50ba556f4634c56a81e7,2,review comment: reword test comment,HEART,2019-07-31T01:56:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63152,MERGED,2019-07-31T00:47:31Z,2019-08-07T08:07:12Z,Always error on `SizeOverflow` during mir evaluation,estebank,3144b0aa04e9a1857cfb50ba556f4634c56a81e7,2,review comment: reword test comment,HEART,2019-08-04T20:08:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/63153,MERGED,2019-07-31T00:52:48Z,2019-08-02T15:21:57Z,Remove redundant method with const variable resolution,varkor,87e73c1f8288823e689ca254cdee9ab6c1723154,3,Remove redundant method with const variable resolution,HEART,2019-07-31T02:08:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/63155,MERGED,2019-07-31T09:47:50Z,2019-08-15T16:31:07Z,Add UWP MSVC targets,mfkl,1581c43be0dd7ac529e85f0a88f7447a315cb787,1,review feedback: add comments and use local flavor variable,ROCKET,2019-08-15T17:05:41Z,larsbergstrom,lars@lars.com https://github.com/rust-lang/rust/pull/63155,MERGED,2019-07-31T09:47:50Z,2019-08-15T16:31:07Z,Add UWP MSVC targets,mfkl,1581c43be0dd7ac529e85f0a88f7447a315cb787,1,review feedback: add comments and use local flavor variable,ROCKET,2020-08-02T01:45:30Z,perrog,roger.y.persson@teliacompany.com https://github.com/rust-lang/rust/pull/63162,MERGED,2019-07-31T13:41:38Z,2019-08-09T03:27:56Z,Miri tests: use xargo to build separate libstd,RalfJung,e6be1d713497a47ddbcedd2776d999fe4324cc16,1,update miri,ROCKET,2019-08-01T08:52:42Z,mati865,NA https://github.com/rust-lang/rust/pull/63170,MERGED,2019-07-31T18:02:47Z,2019-08-01T18:22:10Z,cleanup StringReader fields,matklad,3f461f5ec674ba42c12cb000f307c98464ed5ee7,1,cleanup StringReader fields,HEART,2019-07-31T18:19:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/63175,MERGED,2019-07-31T21:44:07Z,2019-08-22T10:25:34Z,rustc: implement argsfiles for command line,jsgf,d9497749a87440d836495da6d40a5ce667a67ccb,8,Move argfile expansion into run_compiler This will make @path work with miri and other non-standard entrypoints. Also since this simplifies librustc_driver::args move it into a simple source file. Also remove the tests since they're doing nothing more than checking `str::lines` has the right behaviour.,HOORAY,2019-07-31T21:52:39Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63175,MERGED,2019-07-31T21:44:07Z,2019-08-22T10:25:34Z,rustc: implement argsfiles for command line,jsgf,d9497749a87440d836495da6d40a5ce667a67ccb,8,Move argfile expansion into run_compiler This will make @path work with miri and other non-standard entrypoints. Also since this simplifies librustc_driver::args move it into a simple source file. Also remove the tests since they're doing nothing more than checking `str::lines` has the right behaviour.,HOORAY,2019-07-31T22:52:58Z,cramertj,NA https://github.com/rust-lang/rust/pull/63175,MERGED,2019-07-31T21:44:07Z,2019-08-22T10:25:34Z,rustc: implement argsfiles for command line,jsgf,d9497749a87440d836495da6d40a5ce667a67ccb,8,Move argfile expansion into run_compiler This will make @path work with miri and other non-standard entrypoints. Also since this simplifies librustc_driver::args move it into a simple source file. Also remove the tests since they're doing nothing more than checking `str::lines` has the right behaviour.,HOORAY,2019-07-31T22:57:49Z,tmandry,NA https://github.com/rust-lang/rust/pull/63177,MERGED,2019-07-31T22:52:57Z,2020-01-02T13:20:57Z,Add Iterator::try_find,MOZGIII,5446cc99bb2a50bfed05bd781e9d72790a9ff570,4,Add Iterator::try_find,HEART,2021-08-31T17:25:23Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-01T20:22:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-01T22:46:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-01T23:44:02Z,estebank,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-02T08:58:42Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-03T04:05:23Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-03T06:45:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-04T03:32:58Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2019-08-11T12:12:10Z,alexkirsz,NA https://github.com/rust-lang/rust/pull/63180,MERGED,2019-08-01T00:26:47Z,2019-08-03T06:04:20Z,Change opaque type syntax from `existential type` to type alias `impl Trait`,varkor,fbd7e0cf0e31ab612343311a61fe4f58a76a1698,3,Fix broken test and nit,HOORAY,2021-06-05T05:26:07Z,ahlinc,NA https://github.com/rust-lang/rust/pull/63192,CLOSED,2019-08-01T10:22:43Z,2019-08-18T08:41:39Z,Remove the mention of LLDB from RELEASES.md,golddranks,NA,NA,NA,CONFUSED,2019-08-01T11:14:47Z,mati865,NA https://github.com/rust-lang/rust/pull/63207,MERGED,2019-08-02T00:19:12Z,2019-08-02T19:07:33Z,Unconfigure compiler unit test files during normal build,petrochenkov,62ec2cb7acb1b16d0abd8a2cf40da545a13d29f3,11,Remove some more `cfg(test)`s,HOORAY,2019-08-02T16:48:54Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63208,MERGED,2019-08-02T01:25:58Z,2019-08-03T02:22:07Z,Round generator sizes to a multiple of their alignment,tmandry,14be0886778aec5ed597db19b1778503b90c51ab,2,Round generator sizes to multiple of their alignment Fixes #62658.,THUMBS_UP,2019-08-02T05:30:27Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/63208,MERGED,2019-08-02T01:25:58Z,2019-08-03T02:22:07Z,Round generator sizes to a multiple of their alignment,tmandry,14be0886778aec5ed597db19b1778503b90c51ab,2,Round generator sizes to multiple of their alignment Fixes #62658.,THUMBS_UP,2019-08-02T05:31:23Z,jbg,jasper@jasperhugo.com https://github.com/rust-lang/rust/pull/63208,MERGED,2019-08-02T01:25:58Z,2019-08-03T02:22:07Z,Round generator sizes to a multiple of their alignment,tmandry,14be0886778aec5ed597db19b1778503b90c51ab,2,Round generator sizes to multiple of their alignment Fixes #62658.,HOORAY,2019-08-02T20:06:18Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/63208,MERGED,2019-08-02T01:25:58Z,2019-08-03T02:22:07Z,Round generator sizes to a multiple of their alignment,tmandry,14be0886778aec5ed597db19b1778503b90c51ab,2,Round generator sizes to multiple of their alignment Fixes #62658.,THUMBS_UP,2019-08-08T19:20:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:03:42Z,95th,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:04:04Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:04:38Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:05:35Z,CryZe,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:10:23Z,est31,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:27:12Z,Redrield,redrield@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:49:28Z,sfackler,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T02:55:10Z,lawliet89,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:19:40Z,egilburg,eugene.gilburg@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:19:54Z,jntrnr,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:21:59Z,zmanian,zaki@manian.org https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:41:23Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:41:43Z,bIgBV,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T03:46:27Z,souvik1997,souvik@souvik.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:00:30Z,morganherlocker,morgan.herlocker@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:21:41Z,shengsheng,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:30:14Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:34:23Z,atsuzaki,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:45:49Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:52:02Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:58:27Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T04:58:43Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:13:25Z,xanonid,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:24:40Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:27:28Z,VanillaBrooks,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:29:30Z,thezjy,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:41:33Z,frol,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:48:57Z,sachaarbonel,sacha.arbonel@hotmail.fr https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T05:54:41Z,minijackson,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T06:08:07Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T06:11:26Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T06:29:44Z,Connicpu,conni_h@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:12:10Z,bellatoris,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T07:17:19Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:18:52Z,williamhgough,williamhenrygough@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T07:18:55Z,williamhgough,williamhenrygough@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:20:55Z,darksv,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:23:17Z,simonhdickson,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:25:20Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:26:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:28:20Z,pavelshackih,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:33:36Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T07:37:40Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T07:37:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T07:37:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:01:47Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T08:27:31Z,mastfissh,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:32:41Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:37:40Z,rhysd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:39:48Z,milesgranger,miles59923@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:41:04Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T08:41:04Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T08:41:04Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T08:41:07Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T08:43:04Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T09:02:28Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T09:27:37Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T10:15:13Z,fxlae,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T10:24:45Z,Drakulix,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:02:14Z,Kvikal,g4rrus@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:03:16Z,OrmEmbaar,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T11:12:40Z,gkorland,gkorland@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:12:43Z,gkorland,gkorland@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:25:56Z,nottxy,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:33:33Z,davidbarsky,me@davidbarsky.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:34:08Z,adriankumpf,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:44:23Z,nylar,scott@raine.sh https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T11:46:02Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T11:46:04Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:53:53Z,qnighy,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:55:59Z,0x75960,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T11:58:34Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T11:58:40Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T12:16:25Z,repnop,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T12:16:27Z,repnop,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T12:18:03Z,gifnksm,makoto.nksm+github@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T12:25:08Z,timplication,tbaccaer@vub.be https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T12:25:39Z,mcarton,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T12:27:17Z,schulzch,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T13:05:37Z,Fedcomp,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T13:27:38Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T13:27:40Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T13:27:41Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T13:27:44Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T13:33:23Z,chrish42,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T14:32:51Z,weirane,gh@ruo-chen.wang https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T14:41:36Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T14:41:42Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T15:01:53Z,drklee3,hello@dlee.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T15:06:44Z,bvinc,brainn@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T15:06:47Z,bvinc,brainn@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T15:06:48Z,bvinc,brainn@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T16:03:44Z,onsah,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T16:14:12Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T17:21:54Z,bdonlan,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T17:28:29Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T17:28:29Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-02T17:28:31Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T17:28:32Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-02T18:11:55Z,DebugSteven,debugsteven@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T18:11:58Z,DebugSteven,debugsteven@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,CONFUSED,2019-08-02T18:17:37Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T18:32:39Z,eupn,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T18:32:40Z,eupn,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-02T18:37:43Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T19:36:17Z,estebank,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T19:44:12Z,oberien,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T20:26:47Z,evaera,eryn@eryn.io https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-02T21:24:19Z,elegaanz,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-03T02:05:21Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-03T04:57:45Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-03T04:57:46Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-03T04:57:47Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,CONFUSED,2019-08-03T08:41:17Z,emoon,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-03T16:16:49Z,iddan,mail@aniddan.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-03T18:05:22Z,95th,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-03T18:53:02Z,Redrield,redrield@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-03T18:53:03Z,Redrield,redrield@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-03T18:53:03Z,Redrield,redrield@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-03T20:59:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-04T00:21:31Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-04T00:40:53Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-04T05:11:42Z,nicklauri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-04T10:11:16Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-04T11:58:02Z,nick-wtf,nickwestendorf@gmx.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-04T11:58:04Z,nick-wtf,nickwestendorf@gmx.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-05T09:33:51Z,sowelisuwi,yana@riseup.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-05T12:43:34Z,leaxoy,lixiaohui0812@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-05T16:45:10Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-05T16:45:11Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-06T01:20:01Z,incon,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-06T11:15:03Z,alexandrebouthinon,bouthinon.alexandre@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-06T11:15:05Z,alexandrebouthinon,bouthinon.alexandre@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-07T07:01:21Z,lostintime,lostintime.dev@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-07T13:07:30Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-07T14:45:12Z,florianjacob,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-07T15:38:44Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-07T16:56:44Z,skade,florian.gilcher@ferrous-systems.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-08T00:57:35Z,Mr-Byte,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-08T00:57:39Z,Mr-Byte,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-08T07:05:41Z,iliana,iliana@buttslol.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-08T15:56:09Z,aheart,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-08T16:29:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-08T20:10:38Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-08T23:01:39Z,triniwiz,fortune.osei@yahoo.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-09T08:02:58Z,saks,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-09T14:38:11Z,xasopheno,danny@xasopheno.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-09T17:08:44Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-10T15:35:14Z,iyuq,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-10T20:36:39Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-10T20:36:41Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-10T20:36:42Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-11T12:58:46Z,adipascu,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-12T08:58:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-12T08:58:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-12T09:39:50Z,koushiro,koushiro.cqx@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-12T23:28:28Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-12T23:28:31Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-13T00:45:02Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-13T00:45:03Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-13T00:45:04Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-13T07:11:13Z,pimeys,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-13T07:11:17Z,pimeys,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-13T08:30:02Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-13T08:30:04Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-13T08:30:05Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-13T15:35:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-14T13:33:45Z,Blub,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-14T19:37:52Z,tema3210,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-16T08:07:54Z,hack3ric,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-17T12:00:17Z,dunxen,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-17T12:00:19Z,dunxen,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T01:22:25Z,Kilerd,blove694@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-20T01:41:41Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T13:20:16Z,huxi,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T18:21:40Z,PotHix,pothix@pothix.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-20T18:27:54Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T18:27:55Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-20T18:27:55Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T18:36:03Z,chertov,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T18:36:07Z,chertov,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T18:44:16Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T19:59:18Z,nilslice,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T22:18:25Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:34:00Z,tmandry,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:40:26Z,dungph,dung18j@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:41:27Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:45:54Z,fritzsche,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-20T22:46:02Z,fritzsche,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:49:09Z,whoizit,whoami@systemli.org https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T22:58:03Z,Speedy37,vincent@speedy37.fr https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:00:30Z,vkatushenok,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:09:59Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:12:44Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-20T23:12:45Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T23:12:46Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-20T23:12:47Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-20T23:13:40Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T23:13:41Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:13:44Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:19:00Z,tesuji,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-20T23:22:02Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:22:04Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:24:47Z,CalliEve,me@calli.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:24:52Z,dvic,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:26:03Z,michelboaventura,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:30:34Z,Jonathas-Conceicao,jonathasaoc@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:42:59Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:43:30Z,NAlexPear,alex@alexpear.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:43:32Z,EyeOfPython,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-20T23:46:05Z,mstange,mstange.moz@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-20T23:53:49Z,jleedev,jleedev@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T00:08:47Z,CrackedP0t,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T00:17:08Z,justdimaa,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T00:23:25Z,phlip9,philip@phlip9.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T00:23:27Z,phlip9,philip@phlip9.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T00:23:27Z,phlip9,philip@phlip9.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T00:36:59Z,95th,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T00:55:47Z,schirtze,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T01:08:52Z,xuyang2,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T01:11:45Z,kcking,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T01:14:28Z,lukaszmoroz,lukaszmoroz@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T01:47:15Z,icherukuri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,CONFUSED,2019-08-21T01:47:17Z,icherukuri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T01:47:19Z,icherukuri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T01:47:22Z,icherukuri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-21T01:47:23Z,icherukuri,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T01:49:37Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:12:40Z,sipubot,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:16:06Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T02:16:07Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T02:16:08Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:23:52Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T02:23:55Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T02:23:57Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:32:01Z,alswl,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-21T02:32:13Z,jesuszhu,zhu.yanhai@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:36:16Z,smackysnacks,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:36:43Z,Himself65,himself65@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:38:26Z,KaneGreen,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T02:59:12Z,sound2gd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T03:15:58Z,miangraham,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T03:29:01Z,willdady,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T04:03:16Z,yerke,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T04:24:10Z,bestouff,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T04:25:41Z,Observer42,yishengxu47@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T04:30:50Z,CamilleDrapier,camille.drapier@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T05:11:19Z,msizanoen,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T05:29:39Z,drunkday,take3812@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T05:33:42Z,robatipoor,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T05:47:09Z,belltoy,belltoy@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T05:47:14Z,bzar,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T06:25:52Z,fan-tom,lokomot476@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T06:31:45Z,AlisCode,oliv.pinon@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T06:31:49Z,AlisCode,oliv.pinon@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T06:31:51Z,AlisCode,oliv.pinon@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T06:35:23Z,anqurvanillapy,anqurvanillapy@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:00:30Z,liranringel,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:04:33Z,lovasoa,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:14:46Z,NieDzejkob,kuba@kadziolka.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:40:27Z,tkmct,1220t.takamichi@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:57:46Z,khanhtc1202,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:57:51Z,bilelmoussaoui,bil.elmoussaoui@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T07:59:24Z,ChetanBhasin,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T08:18:04Z,teh-cmc,cr.rey.clement@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T08:18:05Z,teh-cmc,cr.rey.clement@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T08:26:20Z,SashaMarrocco,me@sasha.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T08:27:39Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T08:27:40Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T08:27:42Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-21T08:27:46Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T08:30:58Z,a-khaledf,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T09:13:08Z,Karuma303,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T09:41:22Z,subnomo,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T09:46:16Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T09:55:28Z,cjpearce,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T10:17:09Z,vojtechkral,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:17:17Z,vojtechkral,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:23:54Z,nerosnm,soren@neros.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:26:18Z,zeroows,zeroows@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:37:47Z,Eroc33,euan@rochester.me.uk https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:47:57Z,LeDominik,dominik@wagenknecht.cc https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T10:53:46Z,jthomaschewski,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T11:45:10Z,amelekhin,anton.amelekhin@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T11:45:15Z,amelekhin,anton.amelekhin@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T11:54:46Z,palango,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T11:59:16Z,karim-agha,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T12:05:52Z,frondeus,frondeus@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T12:06:24Z,edusporto,eduardosandaloporto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T12:06:33Z,edusporto,eduardosandaloporto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T12:06:35Z,edusporto,eduardosandaloporto@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T12:12:26Z,sunng87,n@sunng.info https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T12:15:38Z,avinayak,su.atul.vi@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T12:18:40Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-08-21T12:43:29Z,RomanAkberov,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T12:59:22Z,yassinebridi,yassine@yasbr.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T12:59:24Z,yassinebridi,yassine@yasbr.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T13:37:29Z,AxlLind,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T13:37:32Z,AxlLind,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T13:39:37Z,AxlLind,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T13:39:45Z,AxlLind,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T14:08:02Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T14:08:04Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T14:08:04Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T14:12:39Z,d-dorazio,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T14:15:42Z,sirgl,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T14:35:10Z,soundslocke,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T14:35:47Z,theGeekPirate,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T14:35:50Z,theGeekPirate,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T14:35:53Z,theGeekPirate,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T14:35:58Z,theGeekPirate,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T15:46:05Z,anderejd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T15:58:55Z,espnicholas,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T16:14:30Z,leshow,cameron.evan@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T16:43:42Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T16:51:37Z,ithamsteri,alex.aspirine@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T17:58:12Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T18:19:01Z,return,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T19:05:09Z,haze,isnt@haze.cool https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-21T19:05:09Z,haze,isnt@haze.cool https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,CONFUSED,2019-08-21T19:05:10Z,haze,isnt@haze.cool https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-21T19:05:10Z,haze,isnt@haze.cool https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-21T19:05:10Z,haze,isnt@haze.cool https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T19:06:00Z,mwilliammyers,mwilliammyers@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T19:26:38Z,kurtrottmann,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T20:30:04Z,olatoft,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-21T23:52:02Z,tetrahedron341,bengdahl341@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T00:50:31Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T01:28:42Z,liangyongrui,leungyongrui@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T02:15:44Z,x1ah,x1ahgxq@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T02:37:41Z,zyfjeff,tianqian.zyf@alibaba-inc.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T03:09:14Z,teeceepee,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T04:49:26Z,mihyaeru21,mihyaeru21@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-22T07:37:45Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-22T08:14:40Z,vhelke,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T09:59:34Z,alexvilanovab,alexvilanovab@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-22T11:41:24Z,abhijithgopal,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T14:43:31Z,Steffey,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-22T14:43:32Z,Steffey,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-22T14:43:34Z,Steffey,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T15:56:29Z,delbonis,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-22T17:11:40Z,bondrewd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-22T17:11:43Z,bondrewd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-22T17:11:46Z,bondrewd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-22T17:11:50Z,bondrewd,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-22T21:23:03Z,CarlosLanderas,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T03:18:42Z,EduRenesto,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T03:48:26Z,243011068,243011068@qq.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-23T07:15:37Z,tim77,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T07:15:39Z,tim77,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T07:48:14Z,and-semakin,and-semakin@ya.ru https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T09:11:15Z,SharpKnifer,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-23T09:11:41Z,SharpKnifer,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-23T09:11:45Z,SharpKnifer,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-23T09:11:48Z,SharpKnifer,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T10:22:49Z,nijynot,nijynot@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T11:01:07Z,hails,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T15:08:52Z,jtomschroeder,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-23T16:37:52Z,gliderkite,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-23T23:59:28Z,weihanglo,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-08-23T23:59:31Z,weihanglo,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-08-23T23:59:33Z,weihanglo,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-24T11:13:44Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-25T14:51:34Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-26T12:50:02Z,sharkguto,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-26T15:47:08Z,kalihman,kalihman0515@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-26T20:55:53Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-27T04:40:10Z,hhwyt,hhwyt@hhwyt.xyz https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-27T21:14:52Z,ebroto,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T13:50:58Z,Nugine,nugine@foxmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T16:08:45Z,Catvert,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T16:38:04Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T17:22:29Z,CoolOppo,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T18:15:50Z,I60R,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T18:18:50Z,fernando-goncalves-ifood,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T18:57:36Z,iSynaptic,jterrell@wans.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T19:02:20Z,msull92,matthew@msull92.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T19:31:50Z,alexeden,alexandereden91@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T19:47:25Z,lowczarc,lancelot@owczarczak.fr https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-28T21:09:04Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T00:05:55Z,oddg,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T00:14:28Z,j-tai,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T00:24:34Z,hbobenicio,hbobenicio@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T00:27:47Z,watawuwu,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T01:40:36Z,huwsun,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T07:37:53Z,Boiethios,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T11:01:11Z,daleione,guoyunlei@live.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T11:05:47Z,bspeice,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-29T11:52:29Z,marco-fp,mfernandezpranno@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-30T07:37:12Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-08-30T14:45:52Z,Yura52,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-30T14:47:37Z,skrap,jonah@petri.us https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-30T17:49:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-08-31T04:05:25Z,b-r-oleary,brendon.oleary@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-09-01T20:13:32Z,saifali96,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-01T20:13:33Z,saifali96,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-09-01T20:13:36Z,saifali96,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-09-02T11:29:57Z,JackTattersall,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-02T15:05:02Z,ctaggart,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-02T18:44:22Z,Hainish,bill@eff.org https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-09-03T11:12:35Z,watawuwu,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-09-03T19:42:35Z,renannprado,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-05T02:03:22Z,roninro,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-06T07:52:52Z,czheji,czheji@126.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-06T18:05:19Z,younker,jason@ynkr.org https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-07T17:20:20Z,braddunbar,dunbarb2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-10T13:03:21Z,klotzambein,robin@kock-hamburg.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-16T20:04:32Z,qmmp123,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-18T00:49:18Z,svenstaro,svenstaro@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-18T10:18:21Z,taheris,github@taheris.net https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-20T13:00:16Z,loneken79,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-09-24T16:26:27Z,chrisbutcher,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-24T16:26:27Z,chrisbutcher,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-09-24T16:26:28Z,chrisbutcher,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-09-24T16:26:30Z,chrisbutcher,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-09-24T16:26:31Z,chrisbutcher,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-09-27T05:24:15Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-27T05:24:16Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-27T14:19:28Z,nicklaros,nicklaros@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-09-27T14:19:32Z,nicklaros,nicklaros@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-09-27T14:19:34Z,nicklaros,nicklaros@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-09-27T14:19:37Z,nicklaros,nicklaros@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-09-28T14:30:21Z,tux3,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-10-04T07:16:32Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-10-08T20:38:52Z,gj,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-10-08T20:38:53Z,gj,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-10-08T20:38:55Z,gj,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-10-08T20:38:56Z,gj,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-10-08T23:25:24Z,tembleking,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-10-08T23:25:25Z,tembleking,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-10-23T13:20:55Z,pzartem,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-10-26T21:18:55Z,RAnders00,ruben.anders@robotty.de https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-10-31T06:25:08Z,zhuxiujia,zhuxiujia@qq.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-03T17:00:12Z,z2665,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-04T17:41:01Z,My-,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-05T15:00:34Z,skhoroshavin,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-05T15:00:37Z,skhoroshavin,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-05T15:00:41Z,skhoroshavin,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-05T16:22:51Z,nui,narongwet.m@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-05T22:42:48Z,sangheestyle,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-05T22:42:49Z,sangheestyle,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-06T15:15:52Z,musaprg,mail@mssn.dev https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-06T19:01:13Z,someguynamedmatt,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-06T19:30:12Z,JKAnderson409,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-06T19:34:33Z,alan-andrade,alan.andradec@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-11-06T19:34:34Z,alan-andrade,alan.andradec@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-06T19:40:04Z,nkcmr,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-06T19:42:10Z,flacks,jean@4ray.co https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-06T19:42:10Z,flacks,jean@4ray.co https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-06T19:42:11Z,flacks,jean@4ray.co https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-11-06T19:42:12Z,flacks,jean@4ray.co https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-06T19:43:24Z,sawmurai,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-06T19:43:27Z,sawmurai,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-06T19:43:29Z,sawmurai,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-06T23:19:20Z,ewired,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-07T01:20:58Z,ckampfe,clark.kampfe@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-07T01:20:59Z,ckampfe,clark.kampfe@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-07T04:27:06Z,kaigedong,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-07T04:27:08Z,kaigedong,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-07T16:50:46Z,Kordyjan,pmarks@virtuslab.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-08T03:10:45Z,PeterDing,dfhayst@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-08T18:59:03Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-08T18:59:07Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-08T18:59:07Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-11-08T18:59:08Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,EYES,2019-11-08T18:59:08Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-08T21:31:59Z,andywwright,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-25T02:56:58Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-25T02:56:58Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-25T02:57:00Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-11-25T02:57:09Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-11-28T07:44:15Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-11-28T07:44:16Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2019-11-28T07:44:17Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2019-11-28T07:44:18Z,RobbieClarken,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-12-04T10:17:20Z,yunlingz,yunling.zhu@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2019-12-07T02:42:12Z,Bananaman,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2019-12-07T02:42:13Z,Bananaman,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2020-01-10T00:17:24Z,ravern,ravernkoh@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2020-01-31T14:42:35Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2020-02-10T03:08:19Z,tiendq,tiendq@gmail.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2020-02-14T09:50:47Z,vincentlao,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2020-05-01T05:20:28Z,caelunshun,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2021-03-28T08:11:04Z,alichraghi,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2021-10-30T21:02:46Z,MartinCura,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2021-11-25T11:35:07Z,MU001999,mu001999@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2021-11-25T11:35:09Z,MU001999,mu001999@outlook.com https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,THUMBS_UP,2021-12-29T20:16:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HEART,2021-12-29T20:16:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,HOORAY,2021-12-29T20:16:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/63209,MERGED,2019-08-02T02:00:12Z,2019-08-20T22:16:08Z,Stabilize `async_await` in Rust 1.39.0,Centril,21476e7d6ce80640ff39eb091584092076f13359,54,#NAME?,ROCKET,2021-12-29T20:16:55Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/63212,MERGED,2019-08-02T07:37:24Z,2019-08-03T02:22:08Z,Pretty print attributes in `print_arg`,Centril,d1c89d64bcc21e4f25ef89889048fe231dd7eabe,2,Test for printing attrs on formal params.,THUMBS_UP,2019-08-02T15:33:34Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/63212,MERGED,2019-08-02T07:37:24Z,2019-08-03T02:22:08Z,Pretty print attributes in `print_arg`,Centril,d1c89d64bcc21e4f25ef89889048fe231dd7eabe,2,Test for printing attrs on formal params.,THUMBS_UP,2019-08-02T22:07:11Z,estebank,NA https://github.com/rust-lang/rust/pull/63218,MERGED,2019-08-02T14:58:14Z,2019-08-03T16:15:17Z,rustbuild: RISC-V is no longer an experimental LLVM target,lenary,2921de63bb2287f6971f3fe54cae96035c8e1ec6,1,rustbuild: correct line length,HEART,2019-08-02T18:36:51Z,panaman67,NA https://github.com/rust-lang/rust/pull/63218,MERGED,2019-08-02T14:58:14Z,2019-08-03T16:15:17Z,rustbuild: RISC-V is no longer an experimental LLVM target,lenary,2921de63bb2287f6971f3fe54cae96035c8e1ec6,1,rustbuild: correct line length,HEART,2019-08-02T20:45:51Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/63235,MERGED,2019-08-03T11:13:38Z,2019-08-04T03:36:50Z,Update Rustfmt and RLS,Xanewok,5bcce8269d9726a0f750f70cbf19bdb4379075e3,3,Update Rustfmt and RLS,THUMBS_UP,2019-08-03T12:21:42Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/63236,CLOSED,2019-08-03T11:54:47Z,2019-11-23T11:08:11Z,"Stabilize #[doc_alias = ""...""]",GuillaumeGomez,NA,NA,NA,HEART,2019-08-03T22:32:15Z,estebank,NA https://github.com/rust-lang/rust/pull/63242,MERGED,2019-08-03T16:17:48Z,2019-08-03T20:10:18Z,ci: move .azure-pipelines to src/ci/azure-pipelines,pietroalbini,6e3c4c3b8ee817fcce9ee6ecd0843e23d1476da5,9,ci: move .azure-pipelines to src/ci/azure-pipelines,HEART,2019-08-03T22:30:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63247,CLOSED,2019-08-03T20:39:11Z,2019-10-10T16:50:27Z,Transition future compat lints to {ERROR DENY},Centril,NA,NA,NA,HOORAY,2019-08-04T06:29:48Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63247,CLOSED,2019-08-03T20:39:11Z,2019-10-10T16:50:27Z,Transition future compat lints to {ERROR DENY},Centril,NA,NA,NA,HOORAY,2019-08-16T23:46:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63248,MERGED,2019-08-03T21:16:19Z,2019-08-05T08:17:34Z,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,petrochenkov,2a9b75281bfb03fc795568ac8fb6eeff7cac8034,17,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,HEART,2019-08-03T21:21:20Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63248,MERGED,2019-08-03T21:16:19Z,2019-08-05T08:17:34Z,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,petrochenkov,2a9b75281bfb03fc795568ac8fb6eeff7cac8034,17,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,HEART,2019-08-04T01:48:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/63248,MERGED,2019-08-03T21:16:19Z,2019-08-05T08:17:34Z,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,petrochenkov,2a9b75281bfb03fc795568ac8fb6eeff7cac8034,17,Move special treatment of `derive(Copy PartialEq Eq)` from expansion infrastructure to elsewhere,HEART,2019-08-05T01:50:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-04T13:36:47Z,qnighy,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_DOWN,2019-08-05T15:21:17Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-07T12:37:31Z,pyfisch,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-09T03:09:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-14T18:33:04Z,phaylon,rs@474.at https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-14T20:47:22Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-14T22:47:29Z,DianaNites,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-14T23:35:21Z,tikue,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-15T04:19:29Z,tux3,NA https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2019-08-15T16:03:05Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/63252,MERGED,2019-08-04T10:10:54Z,2019-08-20T00:31:26Z,Remove recommendation about idiomatic syntax for Arc::clone,nrc,47b16b656376021041110df42e71c551fb2c4881,1,Remove recommendation about idiomatic syntax for Arc::Clone Signed-off-by: Nick Cameron ,THUMBS_UP,2020-01-13T19:45:22Z,axelf4,axelsfor@gmail.com https://github.com/rust-lang/rust/pull/63280,MERGED,2019-08-05T08:56:29Z,2019-08-07T16:57:22Z,submodules: Update clippy,tesuji,070eb0c707fbe219006a24af8bbdf75a7a1164b3,1,submodules: Update clippy,HEART,2019-08-05T10:27:17Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63280,MERGED,2019-08-05T08:56:29Z,2019-08-07T16:57:22Z,submodules: Update clippy,tesuji,070eb0c707fbe219006a24af8bbdf75a7a1164b3,1,submodules: Update clippy,HEART,2019-08-06T14:23:50Z,jplatte,NA https://github.com/rust-lang/rust/pull/63280,MERGED,2019-08-05T08:56:29Z,2019-08-07T16:57:22Z,submodules: Update clippy,tesuji,070eb0c707fbe219006a24af8bbdf75a7a1164b3,1,submodules: Update clippy,HEART,2019-08-07T10:52:44Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/63282,MERGED,2019-08-05T10:13:27Z,2019-08-08T09:07:18Z,Update RLS,Xanewok,2eb06cbce1e6a0df31c9179075ebba9bff014f94,1,Update RLS,THUMBS_UP,2019-08-05T21:32:02Z,alexheretic,NA https://github.com/rust-lang/rust/pull/63287,MERGED,2019-08-05T14:29:24Z,2019-08-06T12:02:24Z,Don't store &Span,Mark-Simulacrum,288b4e90780d827b0bca2b63b25b4a3056986111,2,Don't store &Span This is just needless indirection.,HEART,2019-08-06T05:37:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63294,MERGED,2019-08-05T16:02:55Z,2019-08-07T04:28:06Z,tests for async/await drop order,alsuren,c4940e0f90d7d0e1784ade2b9e1ccc7ae7acfd4a,1,test drop order for locals when a future is dropped part-way through execution,HEART,2019-08-06T14:30:26Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63294,MERGED,2019-08-05T16:02:55Z,2019-08-07T04:28:06Z,tests for async/await drop order,alsuren,c4940e0f90d7d0e1784ade2b9e1ccc7ae7acfd4a,1,test drop order for locals when a future is dropped part-way through execution,HEART,2019-08-06T17:29:44Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63337,MERGED,2019-08-06T21:21:13Z,2019-08-10T10:02:19Z,Tweak mismatched types error,estebank,45a5bc7619d19e58cbb1497f571e2ba987d1d53b,1,fix tests,HEART,2019-08-07T02:37:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/63337,MERGED,2019-08-06T21:21:13Z,2019-08-10T10:02:19Z,Tweak mismatched types error,estebank,45a5bc7619d19e58cbb1497f571e2ba987d1d53b,1,fix tests,HEART,2019-08-08T23:40:57Z,varkor,NA https://github.com/rust-lang/rust/pull/63337,MERGED,2019-08-06T21:21:13Z,2019-08-10T10:02:19Z,Tweak mismatched types error,estebank,45a5bc7619d19e58cbb1497f571e2ba987d1d53b,1,fix tests,HEART,2019-08-08T23:43:40Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63337,MERGED,2019-08-06T21:21:13Z,2019-08-10T10:02:19Z,Tweak mismatched types error,estebank,45a5bc7619d19e58cbb1497f571e2ba987d1d53b,1,fix tests,HEART,2019-08-10T10:56:26Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/63337,MERGED,2019-08-06T21:21:13Z,2019-08-10T10:02:19Z,Tweak mismatched types error,estebank,45a5bc7619d19e58cbb1497f571e2ba987d1d53b,1,fix tests,HEART,2019-08-20T05:00:35Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/63346,MERGED,2019-08-07T08:14:24Z,2019-08-11T22:53:25Z,Lint on some incorrect uses of mem::zeroed / mem::uninitialized,RalfJung,09307474c28eacf0d971ef95ecab0a2186a18c3b,1,update clippy,HEART,2019-08-11T12:29:57Z,est31,NA https://github.com/rust-lang/rust/pull/63347,CLOSED,2019-08-07T08:46:46Z,2019-08-30T20:05:34Z,Remove meaningless comment decoration from code,sd234678,NA,NA,NA,THUMBS_DOWN,2019-08-11T12:43:43Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/63352,MERGED,2019-08-07T16:39:48Z,2019-08-10T13:44:42Z,Sort the fat LTO modules to produce deterministic output.,jgalenson,b6767b3096f47b9dc4613cd7ae45c5e89bfd1146,5,Stop test from running on Windows.,THUMBS_UP,2019-09-01T01:11:29Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/63373,MERGED,2019-08-08T07:25:27Z,2019-08-09T03:28:04Z,gitignore: add comment explaining policy,RalfJung,798767ca2119a9557c6180d271ae039987d342dc,1,more alphabetical,THUMBS_UP,2019-08-08T08:34:44Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,THUMBS_UP,2019-08-08T16:58:14Z,cramertj,NA https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,THUMBS_UP,2019-08-08T17:02:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,THUMBS_UP,2019-08-08T17:48:47Z,est31,NA https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,THUMBS_UP,2019-08-08T18:10:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,HEART,2019-08-08T18:14:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63383,MERGED,2019-08-08T16:24:34Z,2019-08-14T10:52:11Z,`async fn` lifetime elision tests,Centril,5ce8f7a1f98072d9df9fb562526151b83ecfe879,7,Add async versions of arbitrary_self_types_pin_lifetime tests.,THUMBS_UP,2019-08-10T16:42:45Z,95th,NA https://github.com/rust-lang/rust/pull/63399,MERGED,2019-08-09T01:24:32Z,2019-08-10T10:02:23Z,More explicit diagnostic when using a `vec![]` in a pattern,estebank,75c5ad2e827a077c3738dee11d9e0dc99962f384,5,review comments: use structured suggestion,HEART,2019-08-09T02:35:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-09T10:04:35Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-10T06:17:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-10T10:02:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-12T09:30:11Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,ROCKET,2019-08-12T09:30:26Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-12T09:37:39Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-12T10:38:49Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/63400,MERGED,2019-08-09T01:31:15Z,2019-08-10T17:19:51Z,Try to break resolve into more isolated parts,petrochenkov,319f0debd4c4bbd5f0dbd13ba87362c6cccd5e66,4,resolve: Address FIXME from the previous commit Make the `is_import` flag in `ScopeSet` independent from namespace Fix rebase,HEART,2019-08-13T22:52:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63402,MERGED,2019-08-09T06:18:58Z,2019-08-30T10:25:44Z,Strip code to the left and right in diagnostics for long lines,estebank,aaf4dc35e33eea8b658b82a307b81e63e8b214f4,1,fix rebase,THUMBS_UP,2019-08-26T00:39:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63402,MERGED,2019-08-09T06:18:58Z,2019-08-30T10:25:44Z,Strip code to the left and right in diagnostics for long lines,estebank,aaf4dc35e33eea8b658b82a307b81e63e8b214f4,1,fix rebase,THUMBS_UP,2019-09-04T10:30:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/63402,MERGED,2019-08-09T06:18:58Z,2019-08-30T10:25:44Z,Strip code to the left and right in diagnostics for long lines,estebank,aaf4dc35e33eea8b658b82a307b81e63e8b214f4,1,fix rebase,THUMBS_UP,2019-09-04T12:36:48Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63402,MERGED,2019-08-09T06:18:58Z,2019-08-30T10:25:44Z,Strip code to the left and right in diagnostics for long lines,estebank,aaf4dc35e33eea8b658b82a307b81e63e8b214f4,1,fix rebase,THUMBS_UP,2019-09-04T14:47:43Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/63402,MERGED,2019-08-09T06:18:58Z,2019-08-30T10:25:44Z,Strip code to the left and right in diagnostics for long lines,estebank,aaf4dc35e33eea8b658b82a307b81e63e8b214f4,1,fix rebase,THUMBS_UP,2019-09-05T04:42:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63404,MERGED,2019-08-09T08:11:09Z,2019-08-09T15:55:14Z,enable flt2dec tests in Miri,RalfJung,29ca428ffa753a300b880ee11e132ead54f4dbb7,3,Miri is really slow,HOORAY,2019-08-09T14:19:12Z,pvdrz,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-10T10:00:09Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-13T13:23:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,HEART,2019-08-14T21:32:18Z,estebank,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-16T05:34:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,HEART,2019-08-16T05:36:39Z,djc,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T06:05:34Z,ramn,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T06:53:16Z,lavignes,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-16T07:41:42Z,dnsco,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T09:55:55Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-16T11:52:26Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T13:11:58Z,Jezza,jezzadabomb@gmail.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T13:41:20Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-16T15:56:12Z,Thiez,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-16T17:09:32Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,HEART,2019-08-16T17:09:33Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-16T23:37:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-17T04:45:48Z,josephrocca,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-19T17:00:09Z,jordanmack,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-21T06:17:52Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-26T08:15:03Z,berkus,NA https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2019-08-26T17:29:12Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_DOWN,2019-08-28T11:04:57Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,HEART,2019-09-03T10:48:18Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63418,CLOSED,2019-08-09T18:09:25Z,2019-09-04T17:09:31Z,[WIP] Add {HashMap HashSet} to std's prelude,tesuji,NA,NA,NA,THUMBS_UP,2021-03-09T08:52:18Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/63420,MERGED,2019-08-09T18:58:23Z,2019-09-13T19:35:47Z,[Place 2.0] Convert Place's projection to a boxed slice,spastorino,28db2c9e953f4e1e0f1511193c90b84f4d170d1a,3,Make all projection base names be proj_base,HOORAY,2019-08-16T19:52:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63429,MERGED,2019-08-10T06:47:55Z,2019-08-10T17:19:55Z,.gitignore: Readd `/tmp/`,Centril,83b837a7f911ea56ca3c466a43a7c3958eb24b13,1,.gitignore: Explain why `/obj/` is ignored,THUMBS_UP,2019-08-10T07:57:15Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63449,MERGED,2019-08-10T18:57:34Z,2019-08-12T12:44:09Z,resolve: Remove remaining special cases from built-in macros,petrochenkov,fa7fe196018e5fec39dee7ca6567c2024e60daf6,12,resolve: Remove remaining special cases from built-in macros,HOORAY,2019-08-10T21:20:28Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63449,MERGED,2019-08-10T18:57:34Z,2019-08-12T12:44:09Z,resolve: Remove remaining special cases from built-in macros,petrochenkov,fa7fe196018e5fec39dee7ca6567c2024e60daf6,12,resolve: Remove remaining special cases from built-in macros,HEART,2019-08-10T21:20:30Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63449,MERGED,2019-08-10T18:57:34Z,2019-08-12T12:44:09Z,resolve: Remove remaining special cases from built-in macros,petrochenkov,fa7fe196018e5fec39dee7ca6567c2024e60daf6,12,resolve: Remove remaining special cases from built-in macros,HEART,2019-08-22T02:36:36Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63449,MERGED,2019-08-10T18:57:34Z,2019-08-12T12:44:09Z,resolve: Remove remaining special cases from built-in macros,petrochenkov,fa7fe196018e5fec39dee7ca6567c2024e60daf6,12,resolve: Remove remaining special cases from built-in macros,HOORAY,2019-08-22T13:16:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,ROCKET,2019-08-11T12:36:00Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,HEART,2019-08-13T23:31:43Z,varkor,NA https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,HEART,2019-08-15T20:18:08Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,HEART,2019-08-21T23:36:26Z,jacobrosenthal,jacobrosenthal@gmail.com https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,HEART,2019-10-04T07:18:50Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/63455,CLOSED,2019-08-11T02:51:22Z,2019-11-17T00:48:56Z,Move sqrt from `std` to `core`,Lokathor,NA,NA,NA,ROCKET,2019-10-04T07:18:52Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/63459,MERGED,2019-08-11T05:29:39Z,2019-08-14T10:52:15Z,syntax: account for CVarArgs being in the argument list.,eddyb,34dcca20e5909513f08d1c21df1168357c3b6b6a,3,syntax: account for CVarArgs being in the argument list.,THUMBS_UP,2019-08-11T17:30:16Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/63467,MERGED,2019-08-11T18:40:41Z,2019-08-15T16:31:18Z,Add Catalyst (iOS apps running on macOS) target,terhechte,af1e668f33d5c8b4d93e35b31be8e78fec18fcf4,3,Add initial files for iOS catalyst / macabi support This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu iOS SDK linked agains the iOS ABI - Simulator: X86_64 cpu iOS SDK linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU iOS SDK linked again the macOS ABI. Note it the actual SDK is the also the macOS 10.15 SDK but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.,HEART,2019-08-12T11:07:12Z,ctaggart,NA https://github.com/rust-lang/rust/pull/63467,MERGED,2019-08-11T18:40:41Z,2019-08-15T16:31:18Z,Add Catalyst (iOS apps running on macOS) target,terhechte,af1e668f33d5c8b4d93e35b31be8e78fec18fcf4,3,Add initial files for iOS catalyst / macabi support This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu iOS SDK linked agains the iOS ABI - Simulator: X86_64 cpu iOS SDK linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU iOS SDK linked again the macOS ABI. Note it the actual SDK is the also the macOS 10.15 SDK but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.,HEART,2019-08-12T20:35:10Z,estebank,NA https://github.com/rust-lang/rust/pull/63467,MERGED,2019-08-11T18:40:41Z,2019-08-15T16:31:18Z,Add Catalyst (iOS apps running on macOS) target,terhechte,af1e668f33d5c8b4d93e35b31be8e78fec18fcf4,3,Add initial files for iOS catalyst / macabi support This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu iOS SDK linked agains the iOS ABI - Simulator: X86_64 cpu iOS SDK linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU iOS SDK linked again the macOS ABI. Note it the actual SDK is the also the macOS 10.15 SDK but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.,HEART,2019-08-14T15:02:33Z,Binlogo,binboy@live.com https://github.com/rust-lang/rust/pull/63467,MERGED,2019-08-11T18:40:41Z,2019-08-15T16:31:18Z,Add Catalyst (iOS apps running on macOS) target,terhechte,af1e668f33d5c8b4d93e35b31be8e78fec18fcf4,3,Add initial files for iOS catalyst / macabi support This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu iOS SDK linked agains the iOS ABI - Simulator: X86_64 cpu iOS SDK linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU iOS SDK linked again the macOS ABI. Note it the actual SDK is the also the macOS 10.15 SDK but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.,HEART,2019-08-20T14:32:22Z,Sam-Spencer,NA https://github.com/rust-lang/rust/pull/63467,MERGED,2019-08-11T18:40:41Z,2019-08-15T16:31:18Z,Add Catalyst (iOS apps running on macOS) target,terhechte,af1e668f33d5c8b4d93e35b31be8e78fec18fcf4,3,Add initial files for iOS catalyst / macabi support This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu iOS SDK linked agains the iOS ABI - Simulator: X86_64 cpu iOS SDK linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU iOS SDK linked again the macOS ABI. Note it the actual SDK is the also the macOS 10.15 SDK but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.,HEART,2019-09-09T09:18:39Z,eyeplum,eyeplum@gmail.com https://github.com/rust-lang/rust/pull/63468,MERGED,2019-08-11T18:44:09Z,2019-09-09T20:12:50Z,Resolve attributes in several places,c410-f3r,63a5f399aef46f94a24e0d0a3b03eb7f66a33800,37,Resolve attributes in several places Arm Field FieldPat GenericParam Param StructField and Variant,HOORAY,2019-08-11T18:48:01Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63468,MERGED,2019-08-11T18:44:09Z,2019-09-09T20:12:50Z,Resolve attributes in several places,c410-f3r,63a5f399aef46f94a24e0d0a3b03eb7f66a33800,37,Resolve attributes in several places Arm Field FieldPat GenericParam Param StructField and Variant,HOORAY,2019-09-03T10:56:07Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,THUMBS_UP,2019-08-11T19:20:19Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,THUMBS_UP,2019-08-11T19:53:47Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,THUMBS_UP,2019-08-11T21:08:20Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-11T21:08:22Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-12T02:48:32Z,crlf0710,NA https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-12T17:41:52Z,estebank,NA https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-13T16:18:53Z,qnighy,NA https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-14T01:47:18Z,taisukeoe,NA https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HEART,2019-08-14T03:03:03Z,yhara,NA https://github.com/rust-lang/rust/pull/63469,MERGED,2019-08-11T19:00:49Z,2019-08-12T06:19:32Z,libsyntax: Refactor `parser.rs` into reasonably sized logical units,Centril,bcfcbfc923aa821332d8ae8ce977f311764768b1,2,parser: {check expect}_lifetime into ty.rs,HOORAY,2019-08-14T07:22:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-11T19:11:33Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-11T19:16:59Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-11T19:38:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-11T20:18:04Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-12T02:20:17Z,shengsheng,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-12T02:23:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HEART,2019-08-16T12:59:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HEART,2019-08-16T18:46:44Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-16T18:46:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-16T19:52:51Z,lqd,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-16T21:58:41Z,mati865,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-17T00:57:39Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2019-08-18T11:32:42Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HEART,2019-08-18T11:32:50Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63470,MERGED,2019-08-11T19:05:07Z,2019-08-16T18:35:45Z,Utilize -Zbinary-dep-depinfo in rustbuild,Mark-Simulacrum,417f9ea90cf9bcccd8a1fa569a11a4fc071e3b8c,3,Utilize -Zbinary-dep-depinfo for dependency tracking,HOORAY,2020-08-22T08:51:59Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/63475,MERGED,2019-08-11T21:39:28Z,2019-08-14T10:52:18Z,Bring back suggestion for splitting `<-` into `< -`,iluuu1994,91af5c2daf950bd6f99e17dd2e0d23e7cd45e131,6,Bring back suggestion for splitting `<-` into `< -` Closes #62632,HEART,2019-08-12T13:10:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/63490,MERGED,2019-08-12T10:54:20Z,2019-08-15T04:25:07Z,libsyntax: cleanup and refactor `pat.rs`,Centril,c8fc4c106cfb7594dedf3372e33959e9b859c228,1,extract parse_pat_{tuple_}struct + recover_one_fewer_dotdot,HOORAY,2019-08-16T00:39:37Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/63492,MERGED,2019-08-12T13:04:41Z,2019-09-29T09:53:31Z,Remove redundancy from the implementation of C variadics.,eddyb,057f23d3ddabf8c89e5da371d724d1995e9655da,2,rustc_codegen_ssa: remove redundant `va_list_ref` field from `FunctionCx`.,HEART,2019-08-18T19:30:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/63495,MERGED,2019-08-12T15:35:29Z,2019-08-16T22:06:47Z, Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.,eddyb,45980e809f6f661230af5a92766b8fde454aee2a,7,bless you nll,THUMBS_UP,2019-08-12T15:38:13Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/63495,MERGED,2019-08-12T15:35:29Z,2019-08-16T22:06:47Z, Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.,eddyb,45980e809f6f661230af5a92766b8fde454aee2a,7,bless you nll,HEART,2019-08-12T15:41:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/63495,MERGED,2019-08-12T15:35:29Z,2019-08-16T22:06:47Z, Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.,eddyb,45980e809f6f661230af5a92766b8fde454aee2a,7,bless you nll,HEART,2019-08-12T17:22:43Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63495,MERGED,2019-08-12T15:35:29Z,2019-08-16T22:06:47Z, Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.,eddyb,45980e809f6f661230af5a92766b8fde454aee2a,7,bless you nll,HEART,2019-08-22T01:52:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63495,MERGED,2019-08-12T15:35:29Z,2019-08-16T22:06:47Z, Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.,eddyb,45980e809f6f661230af5a92766b8fde454aee2a,7,bless you nll,HEART,2019-08-22T13:22:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63499,MERGED,2019-08-12T18:46:58Z,2019-08-14T10:52:23Z,handle elision in async fn correctly,nikomatsakis,18d69c8ebe7b313d574014e6585680f78bd2e157,8,bless tests with compare-mode=nll,HOORAY,2019-08-13T13:48:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63499,MERGED,2019-08-12T18:46:58Z,2019-08-14T10:52:23Z,handle elision in async fn correctly,nikomatsakis,18d69c8ebe7b313d574014e6585680f78bd2e157,8,bless tests with compare-mode=nll,HOORAY,2019-08-15T04:25:51Z,95th,NA https://github.com/rust-lang/rust/pull/63499,MERGED,2019-08-12T18:46:58Z,2019-08-14T10:52:23Z,handle elision in async fn correctly,nikomatsakis,18d69c8ebe7b313d574014e6585680f78bd2e157,8,bless tests with compare-mode=nll,HOORAY,2019-08-22T02:37:28Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63499,MERGED,2019-08-12T18:46:58Z,2019-08-14T10:52:23Z,handle elision in async fn correctly,nikomatsakis,18d69c8ebe7b313d574014e6585680f78bd2e157,8,bless tests with compare-mode=nll,HOORAY,2019-08-22T13:22:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63508,MERGED,2019-08-13T06:31:40Z,2019-08-14T10:52:26Z,Do not ICE when synthesizing spans falling inside unicode chars,estebank,84e202e6b36250dfc319aa5a869ad1df29b4b55a,1,review comments,HEART,2019-08-13T18:58:48Z,ehuss,NA https://github.com/rust-lang/rust/pull/63511,MERGED,2019-08-13T07:41:45Z,2019-08-14T10:52:27Z,ci: add a check for clock drift,pietroalbini,686553dfce92eb35b3709f64b687c2757334df86,1,ci: add a check for clock drift Recently we encountered multiple spurious failures where the crates.io certificate was reported as expired even though it's currently due to expire in a few months. This adds some code to our CI to check for clock drifts to possibly find the cause or rule out a bad VM clock.,LAUGH,2019-08-13T11:34:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63518,CLOSED,2019-08-13T12:29:42Z,2019-08-19T14:55:56Z,rustc_mir: use dataflow analysis to determine whether locals were moved out of.,eddyb,NA,NA,NA,HOORAY,2019-08-17T09:07:20Z,mati865,NA https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-13T21:41:38Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-13T22:52:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-14T02:42:19Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-14T12:45:49Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-14T18:21:30Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63535,MERGED,2019-08-13T21:27:12Z,2019-08-16T10:42:44Z,Continue refactoring resolve and hygiene,petrochenkov,c76277340e3e5e8d6aca9c926c45cac3484eb5f8,5,resolve: `ParentScope::default` -> `ParentScope::module`,HEART,2019-08-16T06:35:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/63539,MERGED,2019-08-14T00:00:03Z,2019-08-16T10:42:45Z,Suggest Rust 2018 on `.await` with no such field,Centril,9287eb647f7168a65950965044bd5e22d1b05faf,2,typeck: add tests for suggesting -> 2018 on wrong .await,HEART,2019-08-15T19:43:58Z,cramertj,NA https://github.com/rust-lang/rust/pull/63539,MERGED,2019-08-14T00:00:03Z,2019-08-16T10:42:45Z,Suggest Rust 2018 on `.await` with no such field,Centril,9287eb647f7168a65950965044bd5e22d1b05faf,2,typeck: add tests for suggesting -> 2018 on wrong .await,HEART,2019-08-21T19:28:05Z,estebank,NA https://github.com/rust-lang/rust/pull/63539,MERGED,2019-08-14T00:00:03Z,2019-08-16T10:42:45Z,Suggest Rust 2018 on `.await` with no such field,Centril,9287eb647f7168a65950965044bd5e22d1b05faf,2,typeck: add tests for suggesting -> 2018 on wrong .await,HEART,2019-08-22T13:07:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63539,MERGED,2019-08-14T00:00:03Z,2019-08-16T10:42:45Z,Suggest Rust 2018 on `.await` with no such field,Centril,9287eb647f7168a65950965044bd5e22d1b05faf,2,typeck: add tests for suggesting -> 2018 on wrong .await,HEART,2019-08-22T15:11:05Z,seamlik,NA https://github.com/rust-lang/rust/pull/63539,MERGED,2019-08-14T00:00:03Z,2019-08-16T10:42:45Z,Suggest Rust 2018 on `.await` with no such field,Centril,9287eb647f7168a65950965044bd5e22d1b05faf,2,typeck: add tests for suggesting -> 2018 on wrong .await,HEART,2019-08-26T17:09:31Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/63548,MERGED,2019-08-14T07:51:43Z,2019-08-17T04:47:50Z,Update rustc-demangle to 0.1.16.,eddyb,1ab9e523f37bdc156bb9ab9d8b52749bc428437c,4,Update rustc-demangle to 0.1.16.,THUMBS_UP,2019-08-14T08:35:38Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/63548,MERGED,2019-08-14T07:51:43Z,2019-08-17T04:47:50Z,Update rustc-demangle to 0.1.16.,eddyb,1ab9e523f37bdc156bb9ab9d8b52749bc428437c,4,Update rustc-demangle to 0.1.16.,THUMBS_UP,2019-08-14T08:49:55Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/63548,MERGED,2019-08-14T07:51:43Z,2019-08-17T04:47:50Z,Update rustc-demangle to 0.1.16.,eddyb,1ab9e523f37bdc156bb9ab9d8b52749bc428437c,4,Update rustc-demangle to 0.1.16.,THUMBS_UP,2019-08-14T14:10:06Z,tesuji,NA https://github.com/rust-lang/rust/pull/63548,MERGED,2019-08-14T07:51:43Z,2019-08-17T04:47:50Z,Update rustc-demangle to 0.1.16.,eddyb,1ab9e523f37bdc156bb9ab9d8b52749bc428437c,4,Update rustc-demangle to 0.1.16.,THUMBS_UP,2019-08-14T19:26:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/63549,MERGED,2019-08-14T10:15:45Z,2019-09-05T06:03:58Z,Rev::rposition counts from the wrong end,sfanxiang,0e597d4c479b4533e38016b1adbe565b44aab922,2,Rev::rposition counts from the wrong end Because of a compiler bug that adding `Self: ExactSizeIterator` makes the compiler forget `Self::Item` is `::Item` we remove this specialization for now.,LAUGH,2019-08-14T15:27:27Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/63549,MERGED,2019-08-14T10:15:45Z,2019-09-05T06:03:58Z,Rev::rposition counts from the wrong end,sfanxiang,0e597d4c479b4533e38016b1adbe565b44aab922,2,Rev::rposition counts from the wrong end Because of a compiler bug that adding `Self: ExactSizeIterator` makes the compiler forget `Self::Item` is `::Item` we remove this specialization for now.,LAUGH,2019-08-16T16:00:13Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/63558,MERGED,2019-08-14T15:53:32Z,2019-08-17T04:47:51Z,Remap paths for proc-macro crates.,jgalenson,9e2d02a1a1c657fece7ed4f5c71fbdf484931ddc,1,Remap debuginfo for all crates.,THUMBS_UP,2019-09-01T01:11:52Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-08-14T18:35:45Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-09-06T17:07:37Z,crlf0710,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-09-07T03:33:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-09-07T06:57:25Z,weihanglo,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-09-09T09:49:11Z,Vurich,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,HOORAY,2019-09-10T20:59:09Z,chrish42,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-09-11T15:45:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,HOORAY,2019-09-12T08:06:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-11-08T03:05:05Z,billnote,jxsrhsb@gmail.com https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,THUMBS_UP,2019-11-10T03:35:56Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/63565,MERGED,2019-08-14T17:38:35Z,2019-09-06T20:49:16Z,Rust 2018: NLL migrate mode => hard error,Centril,055409538d601e905d72a08dd6c28256587fba3d,4,Refuse to downgrade NLL errors on Rust >= 2018.,HOORAY,2019-11-10T03:35:58Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/63574,CLOSED,2019-08-14T20:38:31Z,2019-08-15T04:36:51Z,Add HashMap to the prelude,djc,NA,NA,NA,HEART,2019-08-14T21:32:08Z,estebank,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HEART,2019-08-15T00:55:53Z,ehuss,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-15T00:55:55Z,ehuss,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HEART,2019-08-15T03:36:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-15T03:36:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-15T03:50:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-15T09:03:35Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-15T16:59:10Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HEART,2019-08-16T02:22:36Z,est31,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-16T02:22:39Z,est31,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-18T07:47:53Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-18T10:34:14Z,mati865,NA https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HEART,2019-08-19T17:59:25Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HOORAY,2019-08-19T21:14:50Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/63579,MERGED,2019-08-15T00:49:49Z,2019-08-19T20:45:14Z,Use to Cargo's experimental lockfile format,alexcrichton,093ede240ab8bb4ec6720301619dda831b5690fd,1,Use to Cargo's experimental lockfile format This commit changes the lock file format of this repository to an experimental format that isn't rolled out by default in Cargo but is intended to eventually become the default. The new format moves information around and compresses the lock file a bit. The intention of the new format is to reduce the amount of git merge conflicts that happen in a repository with rust-lang/rust being a prime candidate for testing this. The new format wille ventually become the default but for now it is off-by-default in Cargo but Cargo will preserve the format if it sees it. Since we always build with a beta version of Cargo for the rust-lang/rust repository it should be safe to go ahead and change the lock file format here and everyone building this repository will automatically pick it up. It's intended that we'll evaluate this lock file format in the rust-lang/rust repository to see if it reduces the number of perceived merge conflicts for changes that touch the lock file. This will in turn help inform the development of the feature in Cargo and whether we choose to stabilize this and turn it on by default. Note that this commit does not actually change the contents of the lock file in terms of a resolution graph it simply reencodes the lock file with a new format.,HEART,2019-08-20T07:03:12Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/63584,MERGED,2019-08-15T08:01:50Z,2019-08-16T10:42:48Z,libcore: more cleanups using `#![feature(associated_type_bounds)]`,Centril,f54503c908413ef54ac9dc8ccf47915fa07a3286,1,libcore: more cleanups using associated_type_bounds,THUMBS_UP,2019-08-15T08:06:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63584,MERGED,2019-08-15T08:01:50Z,2019-08-16T10:42:48Z,libcore: more cleanups using `#![feature(associated_type_bounds)]`,Centril,f54503c908413ef54ac9dc8ccf47915fa07a3286,1,libcore: more cleanups using associated_type_bounds,THUMBS_UP,2019-08-15T09:19:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/63584,MERGED,2019-08-15T08:01:50Z,2019-08-16T10:42:48Z,libcore: more cleanups using `#![feature(associated_type_bounds)]`,Centril,f54503c908413ef54ac9dc8ccf47915fa07a3286,1,libcore: more cleanups using associated_type_bounds,THUMBS_UP,2019-08-15T09:28:02Z,iluuu1994,NA https://github.com/rust-lang/rust/pull/63584,MERGED,2019-08-15T08:01:50Z,2019-08-16T10:42:48Z,libcore: more cleanups using `#![feature(associated_type_bounds)]`,Centril,f54503c908413ef54ac9dc8ccf47915fa07a3286,1,libcore: more cleanups using associated_type_bounds,THUMBS_UP,2019-08-15T14:38:01Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63586,MERGED,2019-08-15T09:08:06Z,2019-08-15T16:31:29Z,cleanup: Remove `Spanned` where possible,petrochenkov,a6182711efe32d4dd68da2663129e3e2e462d8cb,24,Remove `Spanned` from `{ast hir}::FieldPat`,THUMBS_UP,2019-08-15T09:24:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63587,MERGED,2019-08-15T10:11:00Z,2019-08-20T15:01:48Z,Update Clippy and cargo,flip1995,96c3ec12f64042633dfbad9758c961b8ee1cbc2f,1,Update Cargo.lock,THUMBS_UP,2019-08-17T13:51:21Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/63613,MERGED,2019-08-15T20:01:58Z,2019-08-16T22:06:53Z,Hygienize use of built-in macros in the standard library,petrochenkov,263e3c59505a16e78b757e0ead3928a3e961a8ab,9,Remove `__rust_unstable_column`,HOORAY,2019-08-15T21:22:53Z,est31,NA https://github.com/rust-lang/rust/pull/63613,MERGED,2019-08-15T20:01:58Z,2019-08-16T22:06:53Z,Hygienize use of built-in macros in the standard library,petrochenkov,263e3c59505a16e78b757e0ead3928a3e961a8ab,9,Remove `__rust_unstable_column`,HOORAY,2019-08-15T22:35:13Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/63613,MERGED,2019-08-15T20:01:58Z,2019-08-16T22:06:53Z,Hygienize use of built-in macros in the standard library,petrochenkov,263e3c59505a16e78b757e0ead3928a3e961a8ab,9,Remove `__rust_unstable_column`,HOORAY,2019-08-16T01:34:59Z,tesuji,NA https://github.com/rust-lang/rust/pull/63613,MERGED,2019-08-15T20:01:58Z,2019-08-16T22:06:53Z,Hygienize use of built-in macros in the standard library,petrochenkov,263e3c59505a16e78b757e0ead3928a3e961a8ab,9,Remove `__rust_unstable_column`,HOORAY,2019-08-16T23:00:11Z,mati865,NA https://github.com/rust-lang/rust/pull/63620,MERGED,2019-08-15T23:41:47Z,2019-08-20T00:31:33Z,Use constraint span when lowering associated types,estebank,1808e4da68bd94393c03229550b166cafebf38e8,5,review comments,THUMBS_UP,2019-08-16T15:47:53Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63621,MERGED,2019-08-15T23:52:15Z,2019-08-17T12:54:26Z,Modify librustc_llvm to pass -DNDEBUG while compiling.,jgalenson,191603653b90e25d8e0e67f125aec523412b51f9,2,Modify librustc_llvm to pass -DNDEBUG while compiling. Currently librustc_llvm builds are not reproducible because the LLVM files it compiles use the debug version of llvm_unreachable which uses __FILE__. To fix this we propagate NDEBUG from bootstrap if applicable and use it when compiling librustc_llvm.,THUMBS_UP,2019-09-01T01:11:47Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/63624,MERGED,2019-08-16T02:00:18Z,2019-08-22T21:51:41Z,When declaring a declarative macro in an item it's only accessible inside it,estebank,4971667f175e7e3d84b7a87f46633b3e069e48ba,4,review comments,THUMBS_UP,2019-08-16T02:05:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T15:44:59Z,crlf0710,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T15:58:19Z,panaman67,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HEART,2019-08-16T15:58:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T16:46:06Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T17:09:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T19:46:12Z,mati865,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-16T23:47:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HEART,2019-08-24T09:47:16Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-24T12:14:10Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63637,MERGED,2019-08-16T15:36:05Z,2019-08-24T09:26:44Z,bootstrap: Merge the libtest build step with libstd,alexcrichton,b47c9690d2974ec0318f1e87bf38f8f7ee6cf202,18,bootstrap: Merge the libtest build step with libstd Since its inception rustbuild has always worked in three stages: one for libstd one for libtest and one for rustc. These three stages were architected around crates.io dependencies where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild however and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.,HOORAY,2019-08-26T16:55:14Z,est31,NA https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-17T10:35:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-17T10:38:39Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-17T14:48:37Z,est31,NA https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-17T18:00:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-18T03:09:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-18T03:13:39Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-22T13:12:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63657,MERGED,2019-08-17T09:57:22Z,2019-08-18T01:02:48Z,Crank up invalid value lint,RalfJung,3288be515feb4e2143c97ccf0e8455f572e3b360,2,test in a way that works even with musl,HEART,2019-08-22T15:30:08Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/63681,CLOSED,2019-08-18T09:29:27Z,2019-10-10T18:49:15Z,convert \r\n -> \n in include_str! macro,matklad,NA,NA,NA,THUMBS_UP,2019-09-25T21:42:42Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/63681,CLOSED,2019-08-18T09:29:27Z,2019-10-10T18:49:15Z,convert \r\n -> \n in include_str! macro,matklad,NA,NA,NA,THUMBS_UP,2019-09-25T22:42:00Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/63681,CLOSED,2019-08-18T09:29:27Z,2019-10-10T18:49:15Z,convert \r\n -> \n in include_str! macro,matklad,NA,NA,NA,THUMBS_UP,2019-09-27T00:32:01Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/63681,CLOSED,2019-08-18T09:29:27Z,2019-10-10T18:49:15Z,convert \r\n -> \n in include_str! macro,matklad,NA,NA,NA,THUMBS_DOWN,2019-09-29T13:02:02Z,koute,NA https://github.com/rust-lang/rust/pull/63681,CLOSED,2019-08-18T09:29:27Z,2019-10-10T18:49:15Z,convert \r\n -> \n in include_str! macro,matklad,NA,NA,NA,THUMBS_DOWN,2019-09-29T20:10:45Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/63684,MERGED,2019-08-18T10:34:06Z,2019-08-31T01:23:44Z,Constify LinkedList new function,GrayJack,e0f73052a93eee54400b7d4f788181b28bb54b4d,1,Constify LinkedList new function,HEART,2019-08-18T14:51:17Z,panaman67,NA https://github.com/rust-lang/rust/pull/63684,MERGED,2019-08-18T10:34:06Z,2019-08-31T01:23:44Z,Constify LinkedList new function,GrayJack,e0f73052a93eee54400b7d4f788181b28bb54b4d,1,Constify LinkedList new function,HEART,2019-08-22T02:40:07Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63684,MERGED,2019-08-18T10:34:06Z,2019-08-31T01:23:44Z,Constify LinkedList new function,GrayJack,e0f73052a93eee54400b7d4f788181b28bb54b4d,1,Constify LinkedList new function,HEART,2019-08-26T00:36:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63686,CLOSED,2019-08-18T14:22:22Z,2019-08-19T17:58:19Z,Debug for 422,1loudsound,NA,NA,NA,THUMBS_DOWN,2019-08-19T09:30:45Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/63688,CLOSED,2019-08-18T16:11:32Z,2019-12-07T06:44:50Z,WIP: Initial implementation of or-pattern handling in MIR,dlrobertson,NA,NA,NA,HEART,2019-08-18T17:12:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63688,CLOSED,2019-08-18T16:11:32Z,2019-12-07T06:44:50Z,WIP: Initial implementation of or-pattern handling in MIR,dlrobertson,NA,NA,NA,HEART,2019-08-18T17:33:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/63688,CLOSED,2019-08-18T16:11:32Z,2019-12-07T06:44:50Z,WIP: Initial implementation of or-pattern handling in MIR,dlrobertson,NA,NA,NA,HEART,2019-08-19T08:57:42Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63688,CLOSED,2019-08-18T16:11:32Z,2019-12-07T06:44:50Z,WIP: Initial implementation of or-pattern handling in MIR,dlrobertson,NA,NA,NA,HEART,2019-08-26T00:36:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63688,CLOSED,2019-08-18T16:11:32Z,2019-12-07T06:44:50Z,WIP: Initial implementation of or-pattern handling in MIR,dlrobertson,NA,NA,NA,HEART,2019-09-27T03:32:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63691,MERGED,2019-08-18T19:53:21Z,2019-08-20T18:33:44Z,Fix bug in iter::Chain::size_hint,timvermeulen,ec54340756f325324f4b710105a708da1cf26564,2,Fix bug in iter::Chain::size_hint,THUMBS_UP,2019-08-29T08:32:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-18T22:52:41Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T05:31:10Z,ljedrz,NA https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T08:57:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T13:59:02Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T14:34:46Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T17:14:24Z,estebank,NA https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-19T19:22:55Z,cramertj,NA https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-21T17:22:59Z,mati865,NA https://github.com/rust-lang/rust/pull/63693,MERGED,2019-08-18T22:45:51Z,2019-08-27T03:50:06Z,Fully implement or-pattern parsing,Centril,2bd27fbdfe309f3f6abd76f72f379247d49048b7,3,parser: fix span for leading vert.,HOORAY,2019-08-26T00:36:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63703,MERGED,2019-08-19T15:12:51Z,2019-09-01T00:02:33Z,rustdoc: warn on empty doc test,tommilligan,0ec2e9fcebd18d98a32884786e1c4bbaf3db1ce0,3,librustdoc: warn on empty doc test,THUMBS_UP,2019-08-20T13:08:07Z,sd234678,NA https://github.com/rust-lang/rust/pull/63709,MERGED,2019-08-19T16:41:12Z,2019-08-20T11:24:59Z,Move token gluing to token stream parsing,matklad,914e1f456415eae0ae095dd39dc51c115c1ffb5a,3,glue tokens when building token stream,HOORAY,2019-08-19T16:55:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63709,MERGED,2019-08-19T16:41:12Z,2019-08-20T11:24:59Z,Move token gluing to token stream parsing,matklad,914e1f456415eae0ae095dd39dc51c115c1ffb5a,3,glue tokens when building token stream,HOORAY,2019-08-19T17:53:53Z,panaman67,NA https://github.com/rust-lang/rust/pull/63709,MERGED,2019-08-19T16:41:12Z,2019-08-20T11:24:59Z,Move token gluing to token stream parsing,matklad,914e1f456415eae0ae095dd39dc51c115c1ffb5a,3,glue tokens when building token stream,HEART,2019-08-19T17:53:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/63709,MERGED,2019-08-19T16:41:12Z,2019-08-20T11:24:59Z,Move token gluing to token stream parsing,matklad,914e1f456415eae0ae095dd39dc51c115c1ffb5a,3,glue tokens when building token stream,HOORAY,2019-08-19T17:56:47Z,ljedrz,NA https://github.com/rust-lang/rust/pull/63709,MERGED,2019-08-19T16:41:12Z,2019-08-20T11:24:59Z,Move token gluing to token stream parsing,matklad,914e1f456415eae0ae095dd39dc51c115c1ffb5a,3,glue tokens when building token stream,HOORAY,2019-08-20T02:31:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/63717,MERGED,2019-08-19T21:33:05Z,2019-08-21T20:50:51Z,Fix nested eager expansions in arguments of `format_args`,petrochenkov,fe2dc919726d17dbe3568f1cb9de34c73b7f1dff,1,Add a regression test for issue #63460,HEART,2019-08-19T22:02:39Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63717,MERGED,2019-08-19T21:33:05Z,2019-08-21T20:50:51Z,Fix nested eager expansions in arguments of `format_args`,petrochenkov,fe2dc919726d17dbe3568f1cb9de34c73b7f1dff,1,Add a regression test for issue #63460,HEART,2019-08-20T02:29:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/63717,MERGED,2019-08-19T21:33:05Z,2019-08-21T20:50:51Z,Fix nested eager expansions in arguments of `format_args`,petrochenkov,fe2dc919726d17dbe3568f1cb9de34c73b7f1dff,1,Add a regression test for issue #63460,HEART,2019-08-21T18:15:34Z,cwfitzgerald,connorwadefitzgerald@gmail.com https://github.com/rust-lang/rust/pull/63725,CLOSED,2019-08-20T01:59:37Z,2019-10-24T00:47:31Z,replace libterm with termcolor in libtest,euclio,NA,NA,NA,HEART,2019-08-20T02:34:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/63725,CLOSED,2019-08-20T01:59:37Z,2019-10-24T00:47:31Z,replace libterm with termcolor in libtest,euclio,NA,NA,NA,HEART,2019-08-20T02:50:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/63725,CLOSED,2019-08-20T01:59:37Z,2019-10-24T00:47:31Z,replace libterm with termcolor in libtest,euclio,NA,NA,NA,HEART,2019-08-21T15:27:14Z,crlf0710,NA https://github.com/rust-lang/rust/pull/63725,CLOSED,2019-08-20T01:59:37Z,2019-10-24T00:47:31Z,replace libterm with termcolor in libtest,euclio,NA,NA,NA,HEART,2019-08-27T08:17:27Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63725,CLOSED,2019-08-20T01:59:37Z,2019-10-24T00:47:31Z,replace libterm with termcolor in libtest,euclio,NA,NA,NA,HEART,2019-10-10T12:13:09Z,feroldi,mferoldif@gmail.com https://github.com/rust-lang/rust/pull/63743,MERGED,2019-08-20T13:58:53Z,2019-08-20T18:33:50Z,Allow git to merge `Cargo.lock`,alexcrichton,815ce8cb1df6708682691f732c30f10ca1aecc88,1,Allow git to merge `Cargo.lock` This commit backs out #46539 in order to fully leverage #63579 where `git` should be able to merge `Cargo.lock` nowadays with only minimal conflicts.,HEART,2019-08-20T14:16:38Z,mati865,NA https://github.com/rust-lang/rust/pull/63743,MERGED,2019-08-20T13:58:53Z,2019-08-20T18:33:50Z,Allow git to merge `Cargo.lock`,alexcrichton,815ce8cb1df6708682691f732c30f10ca1aecc88,1,Allow git to merge `Cargo.lock` This commit backs out #46539 in order to fully leverage #63579 where `git` should be able to merge `Cargo.lock` nowadays with only minimal conflicts.,HEART,2019-08-20T14:48:59Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/63743,MERGED,2019-08-20T13:58:53Z,2019-08-20T18:33:50Z,Allow git to merge `Cargo.lock`,alexcrichton,815ce8cb1df6708682691f732c30f10ca1aecc88,1,Allow git to merge `Cargo.lock` This commit backs out #46539 in order to fully leverage #63579 where `git` should be able to merge `Cargo.lock` nowadays with only minimal conflicts.,HEART,2019-08-20T15:01:41Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,HEART,2019-08-20T14:55:30Z,mati865,NA https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,HEART,2019-08-26T00:35:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,HEART,2019-09-01T20:51:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,THUMBS_UP,2019-09-01T20:51:59Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,THUMBS_UP,2019-09-07T23:16:19Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,HEART,2019-09-07T23:16:24Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,HEART,2019-09-09T10:42:38Z,g2p,NA https://github.com/rust-lang/rust/pull/63745,CLOSED,2019-08-20T14:32:50Z,2019-09-30T15:01:41Z,Expose Linux syscall interface,newpavlov,NA,NA,NA,THUMBS_UP,2019-09-13T13:58:56Z,ojeda,NA https://github.com/rust-lang/rust/pull/63749,CLOSED,2019-08-20T16:15:02Z,2019-09-11T09:41:31Z,Parse `default async fn` & Pre-expansion-gate `default`,Centril,NA,NA,NA,THUMBS_UP,2019-08-20T17:41:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/63749,CLOSED,2019-08-20T16:15:02Z,2019-09-11T09:41:31Z,Parse `default async fn` & Pre-expansion-gate `default`,Centril,NA,NA,NA,THUMBS_UP,2019-08-20T18:31:14Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63760,MERGED,2019-08-20T21:04:28Z,2019-08-21T15:29:01Z,Update books,ehuss,13c1db981905ea61d2d4ef7bf067b7d495a7f219,4,Update books,THUMBS_UP,2019-08-21T03:06:37Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/63761,MERGED,2019-08-20T22:12:13Z,2019-08-27T09:59:24Z,Propagate spans and attributes from proc macro definitions,petrochenkov,c476b55e528ce854b6198de5bcfdd20b08440c9d,6,proc_macro: Update `Span::def_site` to use the proc macro definition location Which is no longer dummy and is available from metadata now.,HEART,2019-08-20T23:23:00Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63761,MERGED,2019-08-20T22:12:13Z,2019-08-27T09:59:24Z,Propagate spans and attributes from proc macro definitions,petrochenkov,c476b55e528ce854b6198de5bcfdd20b08440c9d,6,proc_macro: Update `Span::def_site` to use the proc macro definition location Which is no longer dummy and is available from metadata now.,HEART,2019-08-21T09:54:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-20T23:03:45Z,Speedy37,vincent@speedy37.fr https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-20T23:12:12Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-20T23:44:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-21T00:37:06Z,qnighy,NA https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-21T03:03:43Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-21T03:05:13Z,Lokathor,NA https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-08-21T10:20:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63762,MERGED,2019-08-20T22:24:19Z,2019-08-21T15:29:02Z,`async_await` was stabilized in 1.39.0 not 1.38.0.,Centril,418eb181ca5777fb06e29a2acf37a5c641340538,1,async_await was stabilized in 1.39.0 not 1.38.0.,LAUGH,2019-09-01T20:15:19Z,saifali96,NA https://github.com/rust-lang/rust/pull/63766,MERGED,2019-08-21T00:33:33Z,2019-08-21T15:29:04Z,Remove some duplication when resolving constants,oli-obk,7dbc4b95fc274ac23453e1f4c3b01e22cc4e7836,2,Remove some duplication when resolving constants,HEART,2019-08-21T00:45:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/63766,MERGED,2019-08-21T00:33:33Z,2019-08-21T15:29:04Z,Remove some duplication when resolving constants,oli-obk,7dbc4b95fc274ac23453e1f4c3b01e22cc4e7836,2,Remove some duplication when resolving constants,HEART,2019-08-21T00:51:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-22T20:12:20Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-24T12:13:09Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-28T20:27:28Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-28T23:34:50Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-30T05:57:42Z,moshg,NA https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-30T11:46:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-30T14:43:27Z,Yura52,NA https://github.com/rust-lang/rust/pull/63767,MERGED,2019-08-21T00:41:41Z,2019-08-22T21:51:47Z,Use more optimal Ord implementation for integers,tesuji,f5b16f6212d2d72d505d4d6b1dedc2c9c61dd014,1,Add codegen test for integers compare,THUMBS_UP,2019-08-31T11:27:28Z,frol,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T05:14:29Z,tesuji,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T06:25:54Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T10:59:17Z,95th,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T12:19:48Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T15:53:38Z,mati865,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-21T15:58:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-08-23T10:37:29Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-19T08:04:56Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-19T08:49:20Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-19T16:19:55Z,koute,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,THUMBS_UP,2019-09-19T19:11:11Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-21T03:58:03Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-21T08:06:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-09-25T07:08:50Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-10-02T19:45:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-10-03T13:03:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-10-06T06:43:30Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63770,MERGED,2019-08-21T04:52:17Z,2019-09-24T14:50:54Z,Stabilize `str::len` `[T]::len` and `str::as_bytes` as const fn,oli-obk,7767e7fb165d527f1991175809a361f2d2313b80,12,Stabilize `str::len` `[T]::len` `is_empty` and `str::as_bytes` as const fn,HOORAY,2019-11-03T02:31:23Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/63780,MERGED,2019-08-21T10:29:32Z,2019-08-21T20:50:56Z,Improve diagnostics: break/continue in wrong context,u32i64,600a64bdb576cde946b71faa6e7ad6d15e84ff39,6,more `--bless`ing + test error annotations fixes,HEART,2019-08-21T15:20:39Z,estebank,NA https://github.com/rust-lang/rust/pull/63780,MERGED,2019-08-21T10:29:32Z,2019-08-21T20:50:56Z,Improve diagnostics: break/continue in wrong context,u32i64,600a64bdb576cde946b71faa6e7ad6d15e84ff39,6,more `--bless`ing + test error annotations fixes,HEART,2019-08-21T15:53:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/63780,MERGED,2019-08-21T10:29:32Z,2019-08-21T20:50:56Z,Improve diagnostics: break/continue in wrong context,u32i64,600a64bdb576cde946b71faa6e7ad6d15e84ff39,6,more `--bless`ing + test error annotations fixes,HEART,2019-08-26T01:36:55Z,Jancd,sergeychang@gmail.com https://github.com/rust-lang/rust/pull/63780,MERGED,2019-08-21T10:29:32Z,2019-08-21T20:50:56Z,Improve diagnostics: break/continue in wrong context,u32i64,600a64bdb576cde946b71faa6e7ad6d15e84ff39,6,more `--bless`ing + test error annotations fixes,HEART,2019-08-30T11:08:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63786,MERGED,2019-08-21T13:41:35Z,2019-09-10T20:22:00Z,Make `abs` `wrapping_abs` `overflowing_abs` const functions,tspiteri,adee559659774054497fc36afea0076c334c0bb2,3,test const abs wrapping_abs and overflowing_abs,THUMBS_UP,2019-09-05T05:55:15Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/63786,MERGED,2019-08-21T13:41:35Z,2019-09-10T20:22:00Z,Make `abs` `wrapping_abs` `overflowing_abs` const functions,tspiteri,adee559659774054497fc36afea0076c334c0bb2,3,test const abs wrapping_abs and overflowing_abs,THUMBS_UP,2019-11-04T19:12:20Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/63788,MERGED,2019-08-21T15:17:54Z,2019-08-22T21:51:49Z,Add amanjeev to rustc-guide toolstate,mark-i-m,a9900be9f41176003c0a1a613686b2e443342466,1,add amanjeev,HOORAY,2019-08-21T15:24:46Z,amanjeev,github@amanjeev.com https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,HEART,2019-08-21T19:14:43Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,THUMBS_UP,2019-08-21T19:14:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,THUMBS_UP,2019-08-22T15:01:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,HEART,2019-08-22T15:01:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,HEART,2019-09-16T21:05:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63793,MERGED,2019-08-21T17:58:13Z,2019-11-08T01:15:44Z,Have tidy ensure that we document all `unsafe` blocks in libcore,oli-obk,e28287b32c40c44fb120c9a3a7eae6f82a7031fa,1,The unsafety in `iter.rs` is already documented wonderfully,THUMBS_UP,2019-09-18T21:13:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-08-22T14:42:59Z,amrali,amralicc@gmail.com https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_DOWN,2019-09-05T09:21:55Z,CryZe,NA https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-10-13T02:05:30Z,Lokathor,NA https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-10-30T20:44:54Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-11-01T15:32:58Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-12-11T16:49:42Z,ctsrc,NA https://github.com/rust-lang/rust/pull/63803,MERGED,2019-08-22T09:29:04Z,2019-10-31T15:16:32Z,[rustdoc] stabilize cfg(doctest),GuillaumeGomez,1595fdee1f9bff2901bcd3cd3fd7a22ea64cac24,1,Update since version for doctest feature,THUMBS_UP,2019-12-19T20:37:01Z,DianaNites,NA https://github.com/rust-lang/rust/pull/63808,MERGED,2019-08-22T13:38:30Z,2019-08-23T08:58:59Z,A bunch of minor documentation tweaks and fixes.,tomasz-rozanski,d9f3258186cc221b41d2d869671d47fd4b716bbe,1,Fix for 7e13679.,HEART,2019-08-22T14:17:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/63809,CLOSED,2019-08-22T16:51:11Z,2019-10-23T15:28:44Z,"[WIP] proc_macro: check non-interned handles for ""leaks"" between/after invocations.",eddyb,NA,NA,NA,HEART,2019-08-22T16:53:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63810,MERGED,2019-08-22T16:52:11Z,2019-11-03T01:41:55Z,Make <*const/mut T>::offset_from `const fn`,oli-obk,b93f48f71a1764420978c6344acd5faf4c3f9a51,2,adjust for missing spans on x86 test runner,HEART,2019-08-23T18:44:19Z,mjbshaw,NA https://github.com/rust-lang/rust/pull/63810,MERGED,2019-08-22T16:52:11Z,2019-11-03T01:41:55Z,Make <*const/mut T>::offset_from `const fn`,oli-obk,b93f48f71a1764420978c6344acd5faf4c3f9a51,2,adjust for missing spans on x86 test runner,HEART,2019-10-01T09:59:10Z,thedrow,omer.katz@omerkatz.com https://github.com/rust-lang/rust/pull/63810,MERGED,2019-08-22T16:52:11Z,2019-11-03T01:41:55Z,Make <*const/mut T>::offset_from `const fn`,oli-obk,b93f48f71a1764420978c6344acd5faf4c3f9a51,2,adjust for missing spans on x86 test runner,HEART,2019-10-08T15:54:01Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/63810,MERGED,2019-08-22T16:52:11Z,2019-11-03T01:41:55Z,Make <*const/mut T>::offset_from `const fn`,oli-obk,b93f48f71a1764420978c6344acd5faf4c3f9a51,2,adjust for missing spans on x86 test runner,HEART,2019-11-11T21:58:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,HOORAY,2019-08-22T23:50:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,HEART,2019-08-22T23:50:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,HEART,2019-08-23T01:43:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,HOORAY,2019-08-23T02:51:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,THUMBS_UP,2019-08-23T13:52:07Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,HOORAY,2019-08-26T00:33:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63820,MERGED,2019-08-22T22:52:01Z,2019-08-28T11:07:14Z,Simplify eager normalization of constants,oli-obk,181ed55e96e589afe565e5ad4e7f1cd6a8000894,4,Simplify eager normalization of constants,THUMBS_UP,2019-09-05T04:44:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63823,MERGED,2019-08-22T23:26:30Z,2019-08-24T17:50:04Z,Audit uses of `apply_mark` in built-in macros + Remove default macro transparencies,petrochenkov,6548a5fa5d1f6d1794592945837111f7264ae598,5,Remove default macro transparencies All transparancies are passed explicitly now. Also remove `#[rustc_macro_transparency]` annotations from built-in macros they are no longer used. `#[rustc_macro_transparency]` only makes sense for declarative macros now.,THUMBS_UP,2019-08-23T05:46:55Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/63823,MERGED,2019-08-22T23:26:30Z,2019-08-24T17:50:04Z,Audit uses of `apply_mark` in built-in macros + Remove default macro transparencies,petrochenkov,6548a5fa5d1f6d1794592945837111f7264ae598,5,Remove default macro transparencies All transparancies are passed explicitly now. Also remove `#[rustc_macro_transparency]` annotations from built-in macros they are no longer used. `#[rustc_macro_transparency]` only makes sense for declarative macros now.,THUMBS_UP,2019-08-23T14:02:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/63825,MERGED,2019-08-23T00:28:38Z,2019-09-04T15:28:35Z,Allow checking of run-pass execution output in compiletest,nathanwhit,12adc395c375d4ab14d24624a0ccdd519d5a5978,1,"Strip remote-test-client output from run stdout The remote-test-client outputs a message of the form ""uploaded ""/"" waiting for result"" onto stdout when executing a test which is then captured in the process result. This needs to be removed when comparing the results of the run-pass test execution.",HOORAY,2019-08-23T00:56:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/63825,MERGED,2019-08-23T00:28:38Z,2019-09-04T15:28:35Z,Allow checking of run-pass execution output in compiletest,nathanwhit,12adc395c375d4ab14d24624a0ccdd519d5a5978,1,"Strip remote-test-client output from run stdout The remote-test-client outputs a message of the form ""uploaded ""/"" waiting for result"" onto stdout when executing a test which is then captured in the process result. This needs to be removed when comparing the results of the run-pass test execution.",HEART,2019-08-26T21:03:29Z,tmandry,NA https://github.com/rust-lang/rust/pull/63825,MERGED,2019-08-23T00:28:38Z,2019-09-04T15:28:35Z,Allow checking of run-pass execution output in compiletest,nathanwhit,12adc395c375d4ab14d24624a0ccdd519d5a5978,1,"Strip remote-test-client output from run stdout The remote-test-client outputs a message of the form ""uploaded ""/"" waiting for result"" onto stdout when executing a test which is then captured in the process result. This needs to be removed when comparing the results of the run-pass test execution.",HOORAY,2019-08-26T21:04:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/63825,MERGED,2019-08-23T00:28:38Z,2019-09-04T15:28:35Z,Allow checking of run-pass execution output in compiletest,nathanwhit,12adc395c375d4ab14d24624a0ccdd519d5a5978,1,"Strip remote-test-client output from run stdout The remote-test-client outputs a message of the form ""uploaded ""/"" waiting for result"" onto stdout when executing a test which is then captured in the process result. This needs to be removed when comparing the results of the run-pass test execution.",HOORAY,2019-09-12T09:20:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63833,MERGED,2019-08-23T19:03:24Z,2019-08-25T04:26:54Z,Suggest calling closure with resolved return type when appropriate,estebank,3890befa8ea9def7e1c9c57a321c7b8c9f759f1f,1,review comment,HEART,2019-08-24T16:06:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/63834,MERGED,2019-08-23T20:47:34Z,2019-09-02T05:55:57Z,remove the unstable rustdoc parameter --linker,andjo403,f0b30c7ded69123cffe26b54fb1feedf45d1c5a8,7,remove the unstable rustdoc parameter --linker use the code generation parameter -Clinker (same parameter as rustc) to control what linker to use for building the rustdoc test executables. closes: #63816,HEART,2019-08-24T01:05:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/63846,MERGED,2019-08-24T12:51:24Z,2019-09-14T18:54:09Z,Added table containing the system calls used by Instant and SystemTime.,DevQps,b3b671366bc98017fcac7bcfae0d46d038575aa3,1,Update src/libstd/time.rs Co-Authored-By: Robin Kruppe ,THUMBS_UP,2019-08-24T14:10:00Z,tesuji,NA https://github.com/rust-lang/rust/pull/63860,CLOSED,2019-08-24T18:02:28Z,2019-09-14T22:24:24Z,Use dataflow to propagate `Qualif`s during const-qualification,ecstatic-morse,NA,NA,NA,HOORAY,2019-08-26T00:21:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/63860,CLOSED,2019-08-24T18:02:28Z,2019-09-14T22:24:24Z,Use dataflow to propagate `Qualif`s during const-qualification,ecstatic-morse,NA,NA,NA,HOORAY,2019-08-26T11:37:39Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63860,CLOSED,2019-08-24T18:02:28Z,2019-09-14T22:24:24Z,Use dataflow to propagate `Qualif`s during const-qualification,ecstatic-morse,NA,NA,NA,HOORAY,2019-09-01T14:11:54Z,est31,NA https://github.com/rust-lang/rust/pull/63860,CLOSED,2019-08-24T18:02:28Z,2019-09-14T22:24:24Z,Use dataflow to propagate `Qualif`s during const-qualification,ecstatic-morse,NA,NA,NA,HOORAY,2019-09-03T23:23:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/63862,MERGED,2019-08-24T18:13:50Z,2019-08-25T08:06:34Z,typeck: refactor patterns => `pat.rs` + make the `def_bm` algo more declarative,Centril,5a7e1cb46a05fd176e5488beb58f72a05f4b1a0d,1,typeck/pat.rs: dedup in `check_pat_box`.,THUMBS_UP,2019-08-24T19:44:26Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/63867,MERGED,2019-08-24T20:48:04Z,2019-08-29T15:01:33Z,resolve: Block expansion of a derive container until all its derives are resolved,petrochenkov,ec45b87957c4158934fc3f5a821594ad0686ea4e,15,resolve: Block expansion of a derive container until all its derives are resolved Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.,HOORAY,2019-08-24T22:07:19Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/63867,MERGED,2019-08-24T20:48:04Z,2019-08-29T15:01:33Z,resolve: Block expansion of a derive container until all its derives are resolved,petrochenkov,ec45b87957c4158934fc3f5a821594ad0686ea4e,15,resolve: Block expansion of a derive container until all its derives are resolved Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.,HOORAY,2019-08-25T14:55:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/63870,MERGED,2019-08-24T21:52:54Z,2019-09-01T21:56:06Z,Suggest call fn ctor passed as arg to fn with type param bounds,estebank,e5530519502baf3ae37fa94eda27c2461d8c94aa,3,review comment,HOORAY,2019-08-31T07:32:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/63875,MERGED,2019-08-25T03:44:47Z,2019-08-28T21:43:19Z,debuginfo: give unique names to closure and generator types,philipc,61ff27aa1cc71042a7f3699713d38b1d1ed2b4c5,3,debuginfo: always include disambiguator in type names,THUMBS_UP,2019-08-27T21:42:28Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/63901,MERGED,2019-08-25T20:39:38Z,2019-08-26T21:17:54Z,Point at method call on missing annotation error,estebank,8458eba41bb1ae7848143f33c610b59e9614ec9b,5,Point at method call on missing annotation error Make it clearer where the type name that couldn't be infered comes from.,HEART,2019-08-26T04:41:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/63901,MERGED,2019-08-25T20:39:38Z,2019-08-26T21:17:54Z,Point at method call on missing annotation error,estebank,8458eba41bb1ae7848143f33c610b59e9614ec9b,5,Point at method call on missing annotation error Make it clearer where the type name that couldn't be infered comes from.,HEART,2019-08-26T06:52:22Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/63901,MERGED,2019-08-25T20:39:38Z,2019-08-26T21:17:54Z,Point at method call on missing annotation error,estebank,8458eba41bb1ae7848143f33c610b59e9614ec9b,5,Point at method call on missing annotation error Make it clearer where the type name that couldn't be infered comes from.,HEART,2019-08-26T17:07:23Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/63901,MERGED,2019-08-25T20:39:38Z,2019-08-26T21:17:54Z,Point at method call on missing annotation error,estebank,8458eba41bb1ae7848143f33c610b59e9614ec9b,5,Point at method call on missing annotation error Make it clearer where the type name that couldn't be infered comes from.,HEART,2019-08-27T07:32:32Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/63907,MERGED,2019-08-26T05:00:09Z,2019-09-22T06:33:28Z,Add explanation to type mismatch involving type params and assoc types,estebank,479ce39939014f0071f8600fa4ce150e33cb7d5b,27,Add explanation to type mismatch involving type params and assoc types,THUMBS_UP,2019-08-27T09:37:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/63907,MERGED,2019-08-26T05:00:09Z,2019-09-22T06:33:28Z,Add explanation to type mismatch involving type params and assoc types,estebank,479ce39939014f0071f8600fa4ce150e33cb7d5b,27,Add explanation to type mismatch involving type params and assoc types,THUMBS_UP,2019-09-17T19:13:03Z,tesuji,NA https://github.com/rust-lang/rust/pull/63909,CLOSED,2019-08-26T07:20:49Z,2019-10-12T17:30:33Z,fix nounwind attribute logic,RalfJung,NA,NA,NA,THUMBS_UP,2019-08-26T11:06:24Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/63909,CLOSED,2019-08-26T07:20:49Z,2019-10-12T17:30:33Z,fix nounwind attribute logic,RalfJung,NA,NA,NA,THUMBS_UP,2019-08-27T10:45:23Z,mati865,NA https://github.com/rust-lang/rust/pull/63909,CLOSED,2019-08-26T07:20:49Z,2019-10-12T17:30:33Z,fix nounwind attribute logic,RalfJung,NA,NA,NA,THUMBS_UP,2019-08-29T19:11:27Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/63909,CLOSED,2019-08-26T07:20:49Z,2019-10-12T17:30:33Z,fix nounwind attribute logic,RalfJung,NA,NA,NA,THUMBS_UP,2019-08-29T19:56:13Z,acfoltzer,acfoltzer@acfoltzer.net https://github.com/rust-lang/rust/pull/63909,CLOSED,2019-08-26T07:20:49Z,2019-10-12T17:30:33Z,fix nounwind attribute logic,RalfJung,NA,NA,NA,HOORAY,2019-08-29T19:57:33Z,acfoltzer,acfoltzer@acfoltzer.net https://github.com/rust-lang/rust/pull/63919,MERGED,2019-08-26T17:07:28Z,2019-09-07T14:13:16Z,Use hygiene for AST passes,matthewjasper,3f3fc52bfa255e68d84ca40a497137f5c6bae4a8,6,Simplify std lib injection,THUMBS_UP,2019-09-12T08:04:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63919,MERGED,2019-08-26T17:07:28Z,2019-09-07T14:13:16Z,Use hygiene for AST passes,matthewjasper,3f3fc52bfa255e68d84ca40a497137f5c6bae4a8,6,Simplify std lib injection,HOORAY,2019-09-13T08:53:24Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63929,CLOSED,2019-08-27T00:40:48Z,2019-08-27T01:23:13Z,[WIP] Move compiletest out of tree,djrenren,NA,NA,NA,CONFUSED,2019-08-27T01:00:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T01:01:13Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T02:14:47Z,mateusmedeiros,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T02:44:10Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T06:37:17Z,peterjoel,peterjoel@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T06:40:34Z,taiki-e,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T06:47:50Z,est31,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T08:03:07Z,theduke,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-08-27T13:37:35Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T14:47:48Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-27T19:25:26Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-28T08:06:50Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-08-28T08:06:52Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-28T20:23:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-08-30T06:48:17Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-09-16T11:27:39Z,lloydmeta,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-09-16T23:46:59Z,lloydmeta,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-09-20T02:59:08Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-09-20T08:33:08Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-09-20T08:45:27Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-09-22T19:48:36Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,THUMBS_UP,2019-09-28T20:11:30Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-10-01T14:47:55Z,mateusmedeiros,NA https://github.com/rust-lang/rust/pull/63931,MERGED,2019-08-27T00:51:06Z,2019-10-01T11:51:12Z,Stabilize macros in some more positions,petrochenkov,5ae38bbc7c6c79c4bbdb2f098bf770c24087f403,8,Stabilize proc macros in type positions,HOORAY,2019-10-11T05:40:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63934,MERGED,2019-08-27T02:18:41Z,2019-09-25T01:47:08Z,Fix coherence checking for impl trait in type aliases,Aaron1011,61cfe92a992f8cd8b1af8e443c442be9559c3a19,4,Add additional tests for type alias impl trait coherence,THUMBS_UP,2019-09-13T21:03:22Z,chpio,NA https://github.com/rust-lang/rust/pull/63934,MERGED,2019-08-27T02:18:41Z,2019-09-25T01:47:08Z,Fix coherence checking for impl trait in type aliases,Aaron1011,61cfe92a992f8cd8b1af8e443c442be9559c3a19,4,Add additional tests for type alias impl trait coherence,THUMBS_UP,2019-10-03T13:12:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63968,MERGED,2019-08-28T08:29:06Z,2019-08-29T08:47:28Z,rustc_apfloat: make the crate #![no_std] explicitly.,eddyb,0006216c9d83dabed3f13f5ed231c152561ceb6a,3,rustc_apfloat: make the crate #![no_std] explicitly.,THUMBS_UP,2019-08-28T08:41:21Z,RalfJung,NA https://github.com/rust-lang/rust/pull/63968,MERGED,2019-08-28T08:29:06Z,2019-08-29T08:47:28Z,rustc_apfloat: make the crate #![no_std] explicitly.,eddyb,0006216c9d83dabed3f13f5ed231c152561ceb6a,3,rustc_apfloat: make the crate #![no_std] explicitly.,THUMBS_UP,2019-08-28T10:09:11Z,mati865,NA https://github.com/rust-lang/rust/pull/63968,MERGED,2019-08-28T08:29:06Z,2019-08-29T08:47:28Z,rustc_apfloat: make the crate #![no_std] explicitly.,eddyb,0006216c9d83dabed3f13f5ed231c152561ceb6a,3,rustc_apfloat: make the crate #![no_std] explicitly.,THUMBS_UP,2019-08-28T11:19:22Z,est31,NA https://github.com/rust-lang/rust/pull/63969,MERGED,2019-08-28T11:22:31Z,2019-09-06T20:49:27Z,Add missing examples for Option type,GuillaumeGomez,fdc4f9028f838605d031248abda0ebfb7450bf9f,1,Add missing examples for Option type,HEART,2019-09-02T22:59:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/63970,MERGED,2019-08-28T11:34:40Z,2019-08-29T08:47:29Z,Notify me (flip1995) when Clippy toolstate changes,flip1995,8cf392114da9deb8bdf160b196b8fd1503fb395e,1,Notify me (flip1995) when Clippy toolstate changes,THUMBS_UP,2019-08-28T11:36:06Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/63979,MERGED,2019-08-28T15:36:21Z,2019-08-29T18:52:01Z,std: Remove the `wasm_syscall` feature,alexcrichton,8fe65da935d7e01dbac897dcfbb4fb0f9f24e442,11,std: Remove the `wasm_syscall` feature This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature.,HEART,2019-08-28T23:14:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/63979,MERGED,2019-08-28T15:36:21Z,2019-08-29T18:52:01Z,std: Remove the `wasm_syscall` feature,alexcrichton,8fe65da935d7e01dbac897dcfbb4fb0f9f24e442,11,std: Remove the `wasm_syscall` feature This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature.,THUMBS_UP,2019-09-10T17:40:47Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/63982,MERGED,2019-08-28T21:19:50Z,2019-08-30T21:31:34Z,When accessing private field of union do not misidentify it as a struct,sam09,378c32bc90b230d1f8feffee135942d442d2a5b7,3,Fix test.,HEART,2019-08-28T22:59:15Z,estebank,NA https://github.com/rust-lang/rust/pull/63992,MERGED,2019-08-29T03:59:14Z,2019-08-29T15:01:45Z,Small improvement for Ord implementation of integers,tesuji,ade191c70a51f6699b64423e0bc8e0f307de9ecd,2,Small improvement for Ord implementation of integers,ROCKET,2019-09-05T04:43:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/63992,MERGED,2019-08-29T03:59:14Z,2019-08-29T15:01:45Z,Small improvement for Ord implementation of integers,tesuji,ade191c70a51f6699b64423e0bc8e0f307de9ecd,2,Small improvement for Ord implementation of integers,ROCKET,2019-09-05T09:22:35Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/63992,MERGED,2019-08-29T03:59:14Z,2019-08-29T15:01:45Z,Small improvement for Ord implementation of integers,tesuji,ade191c70a51f6699b64423e0bc8e0f307de9ecd,2,Small improvement for Ord implementation of integers,ROCKET,2019-09-07T13:10:26Z,pesterev,pesterev@pm.me https://github.com/rust-lang/rust/pull/64007,MERGED,2019-08-29T23:11:23Z,2019-10-19T17:46:49Z,Add check for overlapping ranges to unreachable patterns lint,estebank,593cdcccf28361df155c37916dcfcbe1bf19d9a5,6,Lint only on single element overlap,HEART,2019-10-26T12:02:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-08-30T05:38:19Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-08-30T11:24:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-05T09:27:33Z,ljedrz,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-05T15:30:00Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-08T09:37:39Z,bbqsrc,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,THUMBS_UP,2019-09-08T09:37:41Z,bbqsrc,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-08T13:29:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-09T10:18:18Z,jcgruenhage,jan.christian@gruenhage.xyz https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-10T08:47:04Z,drrlvn,dror@psybear.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-11T16:16:43Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-18T17:33:49Z,estebank,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,THUMBS_UP,2019-09-19T19:11:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-22T08:45:37Z,boozook,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,THUMBS_UP,2019-09-22T08:45:44Z,boozook,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-23T11:06:36Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,THUMBS_UP,2019-09-23T11:06:40Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,THUMBS_UP,2019-09-25T13:55:56Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-25T13:56:00Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2019-09-26T19:36:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64010,MERGED,2019-08-29T23:31:59Z,2019-09-21T18:14:19Z,Stabilize `param_attrs` in Rust 1.39.0,c410-f3r,299d696b91e833f01f37e97b69767fcf6f5cccf0,23,Stabilize `param_attrs` in Rust 1.39.0,HOORAY,2022-02-16T23:28:02Z,roxrook,NA https://github.com/rust-lang/rust/pull/64011,CLOSED,2019-08-30T00:15:03Z,2020-02-26T18:11:29Z,Stabilize `transmute` in constants and statics but not const fn,oli-obk,NA,NA,NA,THUMBS_UP,2019-08-30T04:32:23Z,elichai,NA https://github.com/rust-lang/rust/pull/64011,CLOSED,2019-08-30T00:15:03Z,2020-02-26T18:11:29Z,Stabilize `transmute` in constants and statics but not const fn,oli-obk,NA,NA,NA,THUMBS_UP,2019-08-30T10:26:42Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/64011,CLOSED,2019-08-30T00:15:03Z,2020-02-26T18:11:29Z,Stabilize `transmute` in constants and statics but not const fn,oli-obk,NA,NA,NA,THUMBS_UP,2019-08-30T11:05:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/64011,CLOSED,2019-08-30T00:15:03Z,2020-02-26T18:11:29Z,Stabilize `transmute` in constants and statics but not const fn,oli-obk,NA,NA,NA,THUMBS_UP,2019-09-01T19:04:26Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/64011,CLOSED,2019-08-30T00:15:03Z,2020-02-26T18:11:29Z,Stabilize `transmute` in constants and statics but not const fn,oli-obk,NA,NA,NA,THUMBS_UP,2019-09-02T06:51:59Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/64016,MERGED,2019-08-30T07:38:08Z,2019-09-25T01:47:07Z,Streamline `Compiler`,nnethercote,25211894386a34db1639fbd69680e8f7b35ee1a4,2,Add a comment to `Compiler::compile()`. `Compiler::compile()` is different to all the other `Compiler` methods because it lacks a `Queries` entry. It only has one call site which is in a test that doesn't need its specific characteristics. This patch replaces that call with a call to `Compile::link()` which is similar enough for the test's purposes. It also notes that the method is an illustrative example of how `Compiler` can be used.,ROCKET,2019-08-30T11:04:47Z,mati865,NA https://github.com/rust-lang/rust/pull/64016,MERGED,2019-08-30T07:38:08Z,2019-09-25T01:47:07Z,Streamline `Compiler`,nnethercote,25211894386a34db1639fbd69680e8f7b35ee1a4,2,Add a comment to `Compiler::compile()`. `Compiler::compile()` is different to all the other `Compiler` methods because it lacks a `Queries` entry. It only has one call site which is in a test that doesn't need its specific characteristics. This patch replaces that call with a call to `Compile::link()` which is similar enough for the test's purposes. It also notes that the method is an illustrative example of how `Compiler` can be used.,ROCKET,2019-08-30T18:19:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/64016,MERGED,2019-08-30T07:38:08Z,2019-09-25T01:47:07Z,Streamline `Compiler`,nnethercote,25211894386a34db1639fbd69680e8f7b35ee1a4,2,Add a comment to `Compiler::compile()`. `Compiler::compile()` is different to all the other `Compiler` methods because it lacks a `Queries` entry. It only has one call site which is in a test that doesn't need its specific characteristics. This patch replaces that call with a call to `Compile::link()` which is similar enough for the test's purposes. It also notes that the method is an illustrative example of how `Compiler` can be used.,HEART,2019-08-30T18:19:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/64016,MERGED,2019-08-30T07:38:08Z,2019-09-25T01:47:07Z,Streamline `Compiler`,nnethercote,25211894386a34db1639fbd69680e8f7b35ee1a4,2,Add a comment to `Compiler::compile()`. `Compiler::compile()` is different to all the other `Compiler` methods because it lacks a `Queries` entry. It only has one call site which is in a test that doesn't need its specific characteristics. This patch replaces that call with a call to `Compile::link()` which is similar enough for the test's purposes. It also notes that the method is an illustrative example of how `Compiler` can be used.,HEART,2019-08-31T00:12:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T11:34:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T11:35:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T13:55:29Z,est31,NA https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T14:21:20Z,CryZe,NA https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T14:43:24Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-08-30T15:53:01Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/64017,CLOSED,2019-08-30T08:56:13Z,2019-09-02T12:48:28Z,Move error::Error from libstd to liballoc,taiki-e,NA,NA,NA,THUMBS_UP,2019-09-05T01:18:10Z,garbageslam,garbageslamb@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-08-31T14:52:51Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-04T07:45:26Z,mati865,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-04T10:31:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-04T14:53:59Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-04T14:54:01Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-04T16:06:22Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-04T16:06:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-05T05:54:57Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-05T16:24:25Z,weihanglo,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-05T16:24:27Z,weihanglo,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-06T01:53:33Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-11T17:31:50Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-11T17:31:52Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-12T08:48:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-13T04:18:17Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-16T20:13:02Z,killercup,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-17T00:14:16Z,estebank,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-17T11:07:06Z,95th,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-18T03:41:19Z,benesch,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,HEART,2019-09-18T15:07:19Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-19T15:25:07Z,tormol,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-20T04:21:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-09-20T07:05:22Z,EPashkin,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-10-04T06:56:55Z,0x4ce66f11,NA https://github.com/rust-lang/rust/pull/64028,MERGED,2019-08-30T23:17:27Z,2019-09-16T19:30:19Z,Stabilize `Vec::new` and `String::new` as `const fn`s,Centril,9b3e11f635c0354040ce515ac0ed4fade6fe928f,2,Const-stabilize `String::new`.,THUMBS_UP,2019-12-29T07:25:45Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/64031,MERGED,2019-08-31T05:13:56Z,2019-09-05T06:04:15Z,Harden `param_attrs` test wrt. usage of a proc macro `#[attr]`,Centril,5187a3e15723c85cd7ef3418b0c0e61c79709f4c,3,Harden param_attrs test wrt. usage of proc macro attrs.,THUMBS_UP,2019-08-31T21:46:02Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-08-31T13:27:55Z,est31,NA https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-08-31T17:38:42Z,saifali96,NA https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-09-01T16:51:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-09-02T09:04:07Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-09-03T10:31:43Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-09-03T22:42:38Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-09-12T21:06:55Z,fcard,ficarde@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,THUMBS_UP,2019-09-22T19:44:30Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-10-23T22:20:48Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-11-17T15:11:15Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,THUMBS_UP,2019-11-17T15:11:18Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/64035,MERGED,2019-08-31T12:26:47Z,2019-10-15T19:01:15Z,Stabilize proc macros generating `macro_rules` items,petrochenkov,d80be3b4ff49583d94dea89b1b9bd06a013f43d6,3,Test basic hygiene for `macro_rules` produced by transparent macros,HEART,2019-11-28T05:18:44Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/64041,MERGED,2019-08-31T17:09:12Z,2019-09-05T16:28:04Z,use TokenStream rather than &[TokenTree] for built-in macros,matklad,613649584a9571168c292f82156aee1c173337a8,4,use consistent naming for buildin expansion functions,THUMBS_UP,2019-08-31T18:04:12Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/64047,MERGED,2019-08-31T21:16:17Z,2019-09-21T08:11:26Z,Add `cmp::{min_by min_by_key max_by max_by_key}`,timvermeulen,72175915d6ae5abbc45cf2860a90508d2b4a38ea,1,Simplify Iterator::{min_by max_by} using cmp::{min_by max_by},HOORAY,2019-09-12T20:51:27Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/64047,MERGED,2019-08-31T21:16:17Z,2019-09-21T08:11:26Z,Add `cmp::{min_by min_by_key max_by max_by_key}`,timvermeulen,72175915d6ae5abbc45cf2860a90508d2b4a38ea,1,Simplify Iterator::{min_by max_by} using cmp::{min_by max_by},HOORAY,2019-09-26T19:26:02Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64047,MERGED,2019-08-31T21:16:17Z,2019-09-21T08:11:26Z,Add `cmp::{min_by min_by_key max_by max_by_key}`,timvermeulen,72175915d6ae5abbc45cf2860a90508d2b4a38ea,1,Simplify Iterator::{min_by max_by} using cmp::{min_by max_by},HOORAY,2020-07-10T13:03:56Z,robinmoussu,NA https://github.com/rust-lang/rust/pull/64047,MERGED,2019-08-31T21:16:17Z,2019-09-21T08:11:26Z,Add `cmp::{min_by min_by_key max_by max_by_key}`,timvermeulen,72175915d6ae5abbc45cf2860a90508d2b4a38ea,1,Simplify Iterator::{min_by max_by} using cmp::{min_by max_by},HOORAY,2021-01-15T13:15:28Z,kraktus,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2019-09-01T03:34:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,EYES,2019-09-01T08:53:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2019-09-01T14:34:17Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HOORAY,2019-09-01T14:34:21Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2019-09-01T17:58:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HOORAY,2019-09-01T17:58:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HEART,2019-09-01T17:58:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2019-09-01T21:52:25Z,jmhodges,jeff@somethingsimilar.com https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HEART,2019-09-01T22:54:01Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HOORAY,2019-09-01T22:54:12Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,HOORAY,2019-09-02T14:56:10Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2019-09-06T08:32:31Z,KeenS,NA https://github.com/rust-lang/rust/pull/64051,MERGED,2019-09-01T02:49:49Z,2019-09-05T16:28:05Z,Add x86_64-linux-kernel target,alex,5e933b490b17de43b5c9b45b77088732f17b7ffd,3,Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64 as well as base code that can be shared with other architectures.,THUMBS_UP,2020-04-07T22:42:16Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64056,MERGED,2019-09-01T09:23:44Z,2019-09-03T19:18:04Z,Account for arbitrary self types in E0599,estebank,141f5a7558289acb6c7aaf9c6500eb9f6dbeec1a,2,review comments,HEART,2019-09-01T10:39:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64056,MERGED,2019-09-01T09:23:44Z,2019-09-03T19:18:04Z,Account for arbitrary self types in E0599,estebank,141f5a7558289acb6c7aaf9c6500eb9f6dbeec1a,2,review comments,HEART,2019-09-03T20:37:11Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/64056,MERGED,2019-09-01T09:23:44Z,2019-09-03T19:18:04Z,Account for arbitrary self types in E0599,estebank,141f5a7558289acb6c7aaf9c6500eb9f6dbeec1a,2,review comments,THUMBS_UP,2019-09-26T14:45:34Z,vojtechkral,NA https://github.com/rust-lang/rust/pull/64056,MERGED,2019-09-01T09:23:44Z,2019-09-03T19:18:04Z,Account for arbitrary self types in E0599,estebank,141f5a7558289acb6c7aaf9c6500eb9f6dbeec1a,2,review comments,HEART,2019-09-27T00:17:29Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/64060,MERGED,2019-09-01T11:13:13Z,2019-09-11T04:37:37Z,Improve hygiene of `alloc::format!`,petrochenkov,d42e60331fb08efce78e7fc9739bf42620e51f8f,2,Improve hygiene of `alloc::format!`,THUMBS_UP,2019-09-03T21:55:10Z,kilpatty,sean@urkel.com https://github.com/rust-lang/rust/pull/64060,MERGED,2019-09-01T11:13:13Z,2019-09-11T04:37:37Z,Improve hygiene of `alloc::format!`,petrochenkov,d42e60331fb08efce78e7fc9739bf42620e51f8f,2,Improve hygiene of `alloc::format!`,THUMBS_UP,2019-09-08T02:49:59Z,est31,NA https://github.com/rust-lang/rust/pull/64062,CLOSED,2019-09-01T12:19:44Z,2019-10-24T08:34:36Z,Attempt to make Box::default() construct in-place + Box::new_in_place(),petertodd,NA,NA,NA,HEART,2019-09-05T09:43:07Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64065,CLOSED,2019-09-01T13:28:18Z,2019-09-01T23:22:09Z,Stop emitting impls for PartialEq::ne and PartialOrd::{lt le gt ge},Mark-Simulacrum,NA,NA,NA,HEART,2019-09-01T17:51:46Z,panaman67,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2019-09-02T22:56:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,HEART,2019-09-02T22:56:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2019-09-03T21:02:45Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,HEART,2019-09-03T21:02:47Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2019-09-03T21:32:59Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,HEART,2019-09-03T21:33:00Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,ROCKET,2019-09-04T03:24:14Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2019-09-04T23:11:44Z,8573,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2019-11-17T17:46:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2020-01-16T15:19:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,HEART,2020-01-16T15:19:44Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64069,MERGED,2019-09-01T15:40:23Z,2020-02-15T13:48:47Z,Added From> for CString,danielhenrymantilla,60274a95fef57a18113f7c48be68be31ece860eb,2,Added From> for CString Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad Improved layout checks type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments,THUMBS_UP,2020-01-22T20:52:55Z,LenaWil,NA https://github.com/rust-lang/rust/pull/64082,CLOSED,2019-09-02T02:20:39Z,2019-09-02T22:28:44Z,Even more optimal Ord implementation for integers,scottmcm,NA,NA,NA,HEART,2019-09-02T02:34:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/64082,CLOSED,2019-09-02T02:20:39Z,2019-09-02T22:28:44Z,Even more optimal Ord implementation for integers,scottmcm,NA,NA,NA,HEART,2019-09-02T03:59:12Z,est31,NA https://github.com/rust-lang/rust/pull/64082,CLOSED,2019-09-02T02:20:39Z,2019-09-02T22:28:44Z,Even more optimal Ord implementation for integers,scottmcm,NA,NA,NA,HEART,2019-09-02T09:20:03Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64083,MERGED,2019-09-02T03:16:39Z,2019-09-05T16:28:08Z,Point at appropriate arm on type error on if/else/match with one non-! arm,estebank,c430d743e90967e621e27cdbb8bd64de67969ca6,2,Add match test cases,HEART,2019-09-02T04:18:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/64083,MERGED,2019-09-02T03:16:39Z,2019-09-05T16:28:08Z,Point at appropriate arm on type error on if/else/match with one non-! arm,estebank,c430d743e90967e621e27cdbb8bd64de67969ca6,2,Add match test cases,HEART,2019-09-02T08:06:07Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/64083,MERGED,2019-09-02T03:16:39Z,2019-09-05T16:28:08Z,Point at appropriate arm on type error on if/else/match with one non-! arm,estebank,c430d743e90967e621e27cdbb8bd64de67969ca6,2,Add match test cases,HEART,2019-09-03T16:31:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/64085,MERGED,2019-09-02T04:51:42Z,2019-09-17T05:11:19Z,Tweak unsatisfied HRTB errors,estebank,0a985f2c86add139d880882c968e68747b366be6,11,Tweak unsatisfied HRTB errors,HEART,2019-09-02T08:05:16Z,ParadoxSpiral,NA https://github.com/rust-lang/rust/pull/64094,MERGED,2019-09-02T13:19:53Z,2019-09-06T11:37:20Z,Improve searching in rustdoc and add tests,kawa-yoiko,cb84aa4744c7a6120d8311806912240275d04960,8,Improve searching in rustdoc and add tests,HEART,2019-09-02T13:39:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64108,MERGED,2019-09-03T01:04:14Z,2019-09-09T04:44:58Z,Do not complain about unconstrained params when Self is Ty Error,estebank,c44ffafab902e687ef01d2366a7de7237e25245c,1,review comment,HEART,2019-09-09T16:03:12Z,bluss,NA https://github.com/rust-lang/rust/pull/64110,MERGED,2019-09-03T02:31:49Z,2019-09-05T06:04:23Z,"Refer to ""`self` type"" instead of ""receiver type""",estebank,e16ce8007a129fc3829d5ed9c1fed5cd4fb6c2c9,1,fix error code test,THUMBS_UP,2019-09-03T14:58:59Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64110,MERGED,2019-09-03T02:31:49Z,2019-09-05T06:04:23Z,"Refer to ""`self` type"" instead of ""receiver type""",estebank,e16ce8007a129fc3829d5ed9c1fed5cd4fb6c2c9,1,fix error code test,THUMBS_UP,2019-09-03T15:11:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/64110,MERGED,2019-09-03T02:31:49Z,2019-09-05T06:04:23Z,"Refer to ""`self` type"" instead of ""receiver type""",estebank,e16ce8007a129fc3829d5ed9c1fed5cd4fb6c2c9,1,fix error code test,THUMBS_UP,2019-09-05T04:06:37Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/64111,MERGED,2019-09-03T02:49:59Z,2019-09-06T11:37:21Z,or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve,Centril,16ba5029a19eaa5968e61f4447a2d3ebf3367dc2,3,or-patterns: fix fallout from #664128.,HOORAY,2019-09-03T02:52:04Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64111,MERGED,2019-09-03T02:49:59Z,2019-09-06T11:37:21Z,or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve,Centril,16ba5029a19eaa5968e61f4447a2d3ebf3367dc2,3,or-patterns: fix fallout from #664128.,HOORAY,2019-09-03T03:26:11Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/64111,MERGED,2019-09-03T02:49:59Z,2019-09-06T11:37:21Z,or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve,Centril,16ba5029a19eaa5968e61f4447a2d3ebf3367dc2,3,or-patterns: fix fallout from #664128.,HOORAY,2019-09-12T09:20:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64125,MERGED,2019-09-03T11:24:15Z,2019-09-04T20:31:39Z,Update Clippy,JohnTitor,3284734f789ad1a4c71576c20664bfa80e78f539,1,Update Clippy,HOORAY,2019-09-03T14:03:31Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-04T02:55:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-04T10:51:47Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-04T11:07:39Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-05T21:47:15Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-06T09:53:29Z,mati865,NA https://github.com/rust-lang/rust/pull/64139,MERGED,2019-09-04T02:44:34Z,2019-09-07T22:06:30Z,Migrate internal diagnostic registration to macro_rules,Mark-Simulacrum,5153db136e8419beb217340500a97db553ddabbe,1,Explicitly create test tempdir,HOORAY,2019-09-08T02:41:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/64141,MERGED,2019-09-04T05:23:28Z,2019-09-05T06:04:27Z,Minimize uses of `LocalInternedString`,nnethercote,cc17b1bc3c877c5cf9a2f5de58535477607972f2,1,Add `Symbol::{with with2}`. And remove the `unsafe` blocks they're not necessary. Also rewrite `InternedString::{with with2}` to use the new functions. Finally add some comments about the speed of the `as_str()`/`as_interned_str()` functions.,HEART,2019-09-04T18:01:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HEART,2019-09-10T18:53:16Z,varkor,NA https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HEART,2019-09-19T02:35:54Z,sinkuu,NA https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HOORAY,2019-10-02T17:11:24Z,krdln,NA https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HOORAY,2019-10-03T13:24:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HOORAY,2019-11-09T22:14:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64151,MERGED,2019-09-04T17:19:47Z,2019-09-23T02:25:28Z,On obligation errors point at the unfulfilled binding when possible,estebank,ff75124a377f60ee4bd084ca2569e1530ff52856,2,fix nll tests,HEART,2019-11-14T05:57:35Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T20:10:21Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T20:10:42Z,est31,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T20:10:46Z,azriel91,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-04T20:18:55Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-04T20:22:22Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T20:22:22Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-04T20:38:36Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T21:07:35Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-04T21:33:37Z,vultix,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-04T22:20:42Z,tmandry,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-05T00:14:03Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-05T06:12:09Z,ljedrz,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-05T09:06:32Z,aheart,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-11T18:48:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-11T18:48:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-19T09:50:22Z,Virgiel,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-19T09:50:23Z,Virgiel,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HOORAY,2019-09-20T04:30:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,HEART,2019-09-26T13:37:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,THUMBS_UP,2020-11-05T12:16:33Z,lei-april,NA https://github.com/rust-lang/rust/pull/64154,MERGED,2019-09-04T20:06:10Z,2019-09-11T18:46:52Z,std: Add a `backtrace` module,alexcrichton,34662c69614028944668f96c91ef294e7da048f0,5,std: Add a `backtrace` module This commit adds a `backtrace` module to the standard library as designed in [RFC 2504]. The `Backtrace` type is intentionally very conservative effectively only allowing capturing it and printing it. Additionally this commit also adds a `backtrace` method to the `Error` trait which defaults to returning `None` as specified in [RFC 2504]. More information about the design here can be found in [RFC 2504] and in the [tracking issue]. Implementation-wise this is all based on the `backtrace` crate and very closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise it's pretty standard in how it handles everything internally. [RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md [tracking issue]: https://github.com/rust-lang/rust/issues/53487 cc #53487,THUMBS_UP,2022-01-31T11:41:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/64158,MERGED,2019-09-04T23:23:06Z,2019-09-29T17:36:14Z,panic=abort support in libtest,tmandry,3f0254e3cf7656bd3726372106e98532b1575e2d,8,Put panic=abort test support behind -Z panic_abort_tests,HEART,2019-09-05T07:08:25Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64158,MERGED,2019-09-04T23:23:06Z,2019-09-29T17:36:14Z,panic=abort support in libtest,tmandry,3f0254e3cf7656bd3726372106e98532b1575e2d,8,Put panic=abort test support behind -Z panic_abort_tests,HEART,2019-09-06T11:43:03Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/64158,MERGED,2019-09-04T23:23:06Z,2019-09-29T17:36:14Z,panic=abort support in libtest,tmandry,3f0254e3cf7656bd3726372106e98532b1575e2d,8,Put panic=abort test support behind -Z panic_abort_tests,THUMBS_UP,2019-12-13T17:24:31Z,adetaylor,NA https://github.com/rust-lang/rust/pull/64161,MERGED,2019-09-05T02:05:37Z,2019-09-06T11:37:26Z,Point at variant on pattern field count mismatch,estebank,24d0a01b75c034d52bdca10cca08e69538e871ca,1,review comment,HEART,2019-09-05T02:18:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/64161,MERGED,2019-09-05T02:05:37Z,2019-09-06T11:37:26Z,Point at variant on pattern field count mismatch,estebank,24d0a01b75c034d52bdca10cca08e69538e871ca,1,review comment,HEART,2019-09-11T22:26:39Z,Havvy,NA https://github.com/rust-lang/rust/pull/64161,MERGED,2019-09-05T02:05:37Z,2019-09-06T11:37:26Z,Point at variant on pattern field count mismatch,estebank,24d0a01b75c034d52bdca10cca08e69538e871ca,1,review comment,HEART,2019-09-12T08:04:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64177,MERGED,2019-09-05T15:19:54Z,2019-09-08T02:12:56Z,resolve: Do not afraid to set current module to enums and traits,petrochenkov,56f635304b7a2689cfe5e98577428d67f059b413,2,resolve: Adjust `hygienic_lexical_parent` to account for enum and trait modules,THUMBS_UP,2019-09-08T13:42:07Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64178,MERGED,2019-09-05T15:29:54Z,2019-10-24T07:16:43Z,More Clippy fixes for alloc core and std,mati865,bedbf3bacbff36a477dcf28523cbf6cab67e9e0a,2,Apply clippy::single_match suggestion,HEART,2019-09-05T16:22:19Z,panaman67,NA https://github.com/rust-lang/rust/pull/64186,MERGED,2019-09-05T18:44:19Z,2019-09-06T11:37:28Z,std: Improve downstream codegen in `Command::env`,alexcrichton,0b7ba6ec54db24b676d376665692a49d0ecd603a,9,"std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new(""foo"").env(""a"" ""b"")` drops from 21k lines of LLVM IR to 10k.",HEART,2019-09-05T20:03:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/64186,MERGED,2019-09-05T18:44:19Z,2019-09-06T11:37:28Z,std: Improve downstream codegen in `Command::env`,alexcrichton,0b7ba6ec54db24b676d376665692a49d0ecd603a,9,"std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new(""foo"").env(""a"" ""b"")` drops from 21k lines of LLVM IR to 10k.",HEART,2019-09-05T21:02:02Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64186,MERGED,2019-09-05T18:44:19Z,2019-09-06T11:37:28Z,std: Improve downstream codegen in `Command::env`,alexcrichton,0b7ba6ec54db24b676d376665692a49d0ecd603a,9,"std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new(""foo"").env(""a"" ""b"")` drops from 21k lines of LLVM IR to 10k.",HEART,2019-09-06T10:02:02Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64186,MERGED,2019-09-05T18:44:19Z,2019-09-06T11:37:28Z,std: Improve downstream codegen in `Command::env`,alexcrichton,0b7ba6ec54db24b676d376665692a49d0ecd603a,9,"std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new(""foo"").env(""a"" ""b"")` drops from 21k lines of LLVM IR to 10k.",HEART,2019-09-06T11:57:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/64188,MERGED,2019-09-05T18:56:54Z,2019-09-11T04:37:42Z,rustc: Allow the cdylib crate type with wasm32-wasi,alexcrichton,bb9d3bea30c354fecca5dae735bec62962fc5e4c,1,rustc: Allow the cdylib crate type with wasm32-wasi The wasm32-wasi target respects configuration around `crt-static` in general but is defaulted to being static. This interacted badly with code which validated the `cdylib` crate type for `wasm32-wasi` erroneously saying that the `cdylib` crate type wasn't supported on `wasm32-wasi` by default. This commit sets the appropriate flag in `wasm32_wasi`'s target specification to indicate that the `cdylib` crate type is supported regardless of `crt-static` Closes #64187,THUMBS_UP,2019-09-06T09:18:10Z,kellytk,NA https://github.com/rust-lang/rust/pull/64198,MERGED,2019-09-05T23:45:20Z,2019-09-06T11:37:30Z,Add Fuchsia to actually_monotonic,cramertj,bb1e42599d0062b9a43e83b5486d61eb1fcf0771,1,Add Fuchsia to actually_monotonic Fuchsia provides a fully monotonic clock.,THUMBS_UP,2019-09-06T01:42:30Z,tmandry,NA https://github.com/rust-lang/rust/pull/64211,MERGED,2019-09-06T09:12:44Z,2019-09-06T15:42:56Z,Fix miri,oli-obk,39bfb3626c04fe03d50864e13a6baeed1c0378f4,2,Fix miri,ROCKET,2019-09-06T15:52:16Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-07T18:02:54Z,crlf0710,NA https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-09T20:14:07Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-25T15:34:31Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-25T17:15:16Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-26T08:00:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/64221,MERGED,2019-09-06T14:30:45Z,2019-09-27T00:16:05Z, Rust 2015: No longer downgrade NLL errors,Centril,5a0e4613ce62f1e46f974af4065e5ccb3f56a1af,3,issue-#45696: remove ignore-compare-mode-nll,HOORAY,2019-09-26T12:58:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64231,MERGED,2019-09-06T17:09:51Z,2019-09-07T14:13:31Z,Move the HIR CFG to `rustc_ast_borrowck`,matthewjasper,10f46b69bc32bd1cb5f013ce904957aeb28603bb,10,Move the HIR cfg to `rustc_ast_borrowck` No new code should be using it.,HEART,2019-09-06T17:19:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64233,MERGED,2019-09-06T18:21:47Z,2019-09-07T14:13:31Z,Correct pluralisation of various diagnostic messages,varkor,0b97726e6c524d2cc0de4c2f5b1284eca010a7b2,5,Update ui tests,THUMBS_UP,2019-09-06T22:09:25Z,estebank,NA https://github.com/rust-lang/rust/pull/64237,MERGED,2019-09-06T19:06:05Z,2019-09-09T12:47:32Z,Give method not found a primary span label,estebank,5799fb419c96a9e6a170f7980f67fd9047fd6f96,63,Give method not found a primary span label,HEART,2019-09-07T03:22:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-09T11:15:34Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-11T15:46:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-11T16:49:32Z,djc,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-11T21:07:18Z,frol,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-11T23:28:14Z,chmln,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-12T06:35:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-12T08:15:27Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-12T08:46:38Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-14T06:20:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2019-09-19T06:00:36Z,elpiel,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2020-10-22T21:50:38Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2020-12-14T20:40:35Z,iago-lito,NA https://github.com/rust-lang/rust/pull/64255,MERGED,2019-09-07T14:51:27Z,2019-09-08T02:13:00Z,Add methods for converting `bool` to `Option`,varkor,7b3f72906ffea5a8aec9e3d109d8e012f771a672,1,Add tracking issue,HEART,2022-05-20T14:26:10Z,zohnannor,NA https://github.com/rust-lang/rust/pull/64259,CLOSED,2019-09-07T15:41:26Z,2020-02-27T15:50:27Z,PowerPC C ZST ABI fixes,smaeul,NA,NA,NA,HOORAY,2019-10-04T06:57:58Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/64259,CLOSED,2019-09-07T15:41:26Z,2020-02-27T15:50:27Z,PowerPC C ZST ABI fixes,smaeul,NA,NA,NA,HOORAY,2019-11-05T23:36:49Z,glaubitz,NA https://github.com/rust-lang/rust/pull/64259,CLOSED,2019-09-07T15:41:26Z,2020-02-27T15:50:27Z,PowerPC C ZST ABI fixes,smaeul,NA,NA,NA,HOORAY,2019-11-08T21:00:11Z,awilfox,NA https://github.com/rust-lang/rust/pull/64265,MERGED,2019-09-07T18:28:01Z,2019-09-08T16:50:03Z,resolve: Mark more erroneous imports as used,petrochenkov,7dc3839b50d1ddb623aef0fbe76e982af460a18a,3,resolve: Mark more erroneous imports as used,HEART,2019-09-09T11:29:04Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64267,MERGED,2019-09-07T19:26:05Z,2019-09-08T16:50:03Z,rustdoc: fix diagnostic with mixed code block styles,ehuss,fb387088e2e327e4060290edc92a90d49669b04c,3,rustdoc: fix diagnostic with mixed code block styles,THUMBS_UP,2019-09-07T20:05:04Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/64267,MERGED,2019-09-07T19:26:05Z,2019-09-08T16:50:03Z,rustdoc: fix diagnostic with mixed code block styles,ehuss,fb387088e2e327e4060290edc92a90d49669b04c,3,rustdoc: fix diagnostic with mixed code block styles,THUMBS_UP,2019-09-08T17:17:53Z,estebank,NA https://github.com/rust-lang/rust/pull/64271,MERGED,2019-09-07T23:13:46Z,2019-09-11T22:40:43Z,check_match: refactor + improve non-exhaustive diagnostics for default binding modes,Centril,20a26055b7afa500e1b00c6e5a3d03a1208c1d00,1,pacify tidy.,THUMBS_UP,2019-09-20T04:30:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64272,MERGED,2019-09-07T23:25:52Z,2019-09-23T10:40:48Z,Refactor librustc_errors::Handler API,Mark-Simulacrum,4cc5aaada2f8ffd444a7fbb10394b83ba3156525,2,Protect error handler fields with single lock This avoids concurrency-related bugs when locks are acquired for too short a time and similar cases.,HOORAY,2019-09-15T11:34:20Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/64272,MERGED,2019-09-07T23:25:52Z,2019-09-23T10:40:48Z,Refactor librustc_errors::Handler API,Mark-Simulacrum,4cc5aaada2f8ffd444a7fbb10394b83ba3156525,2,Protect error handler fields with single lock This avoids concurrency-related bugs when locks are acquired for too short a time and similar cases.,HOORAY,2019-09-17T13:40:24Z,mati865,NA https://github.com/rust-lang/rust/pull/64272,MERGED,2019-09-07T23:25:52Z,2019-09-23T10:40:48Z,Refactor librustc_errors::Handler API,Mark-Simulacrum,4cc5aaada2f8ffd444a7fbb10394b83ba3156525,2,Protect error handler fields with single lock This avoids concurrency-related bugs when locks are acquired for too short a time and similar cases.,HOORAY,2019-09-22T19:13:18Z,estebank,NA https://github.com/rust-lang/rust/pull/64272,MERGED,2019-09-07T23:25:52Z,2019-09-23T10:40:48Z,Refactor librustc_errors::Handler API,Mark-Simulacrum,4cc5aaada2f8ffd444a7fbb10394b83ba3156525,2,Protect error handler fields with single lock This avoids concurrency-related bugs when locks are acquired for too short a time and similar cases.,HOORAY,2019-10-03T22:35:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64273,MERGED,2019-09-07T23:43:07Z,2019-12-30T08:24:35Z,Stabilize attribute macros on inline modules,petrochenkov,e3155abd2efd5d07a8bc323b1ea0a915616c7ae0,7,Stabilize attribute macros on inline modules,HOORAY,2020-01-12T06:34:28Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/64273,MERGED,2019-09-07T23:43:07Z,2019-12-30T08:24:35Z,Stabilize attribute macros on inline modules,petrochenkov,e3155abd2efd5d07a8bc323b1ea0a915616c7ae0,7,Stabilize attribute macros on inline modules,HEART,2020-01-12T06:34:31Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/64273,MERGED,2019-09-07T23:43:07Z,2019-12-30T08:24:35Z,Stabilize attribute macros on inline modules,petrochenkov,e3155abd2efd5d07a8bc323b1ea0a915616c7ae0,7,Stabilize attribute macros on inline modules,HOORAY,2020-01-14T16:35:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64279,MERGED,2019-09-08T08:31:24Z,2019-09-10T04:27:27Z,Bump RLS and Rustfmt submodules to use rustc-ap-* v583,Xanewok,c2249a4bf996435803ad3f8fbe9fe45d9289e19f,1,cargo update -p rustfmt-nightly,HEART,2019-09-09T17:56:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/64279,MERGED,2019-09-08T08:31:24Z,2019-09-10T04:27:27Z,Bump RLS and Rustfmt submodules to use rustc-ap-* v583,Xanewok,c2249a4bf996435803ad3f8fbe9fe45d9289e19f,1,cargo update -p rustfmt-nightly,HEART,2019-09-10T09:15:03Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/64292,MERGED,2019-09-08T20:27:18Z,2019-09-10T20:22:16Z,lowering: extend temporary lifetimes around await,davidtwco,63fad69a9967a56e33927aa31c50768bc1498588,4,lowering: extend temporary lifetimes around await This commit changes the HIR lowering around `await` so that temporary lifetimes are extended. Previously await was lowered as: ```rust { let mut pinned = future; loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` With this commit await is lowered as: ```rust match future { mut pinned => loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` However this change has the following side-effects: - All temporaries in future will be considered to live across a yield for the purpose of auto-traits. - Borrowed temporaries in future are likely to be considered to be live across the yield for the purpose of the generator transform. Signed-off-by: David Wood ,HOORAY,2019-09-08T21:24:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64292,MERGED,2019-09-08T20:27:18Z,2019-09-10T20:22:16Z,lowering: extend temporary lifetimes around await,davidtwco,63fad69a9967a56e33927aa31c50768bc1498588,4,lowering: extend temporary lifetimes around await This commit changes the HIR lowering around `await` so that temporary lifetimes are extended. Previously await was lowered as: ```rust { let mut pinned = future; loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` With this commit await is lowered as: ```rust match future { mut pinned => loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` However this change has the following side-effects: - All temporaries in future will be considered to live across a yield for the purpose of auto-traits. - Borrowed temporaries in future are likely to be considered to be live across the yield for the purpose of the generator transform. Signed-off-by: David Wood ,HOORAY,2019-09-09T03:05:51Z,est31,NA https://github.com/rust-lang/rust/pull/64292,MERGED,2019-09-08T20:27:18Z,2019-09-10T20:22:16Z,lowering: extend temporary lifetimes around await,davidtwco,63fad69a9967a56e33927aa31c50768bc1498588,4,lowering: extend temporary lifetimes around await This commit changes the HIR lowering around `await` so that temporary lifetimes are extended. Previously await was lowered as: ```rust { let mut pinned = future; loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` With this commit await is lowered as: ```rust match future { mut pinned => loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` However this change has the following side-effects: - All temporaries in future will be considered to live across a yield for the purpose of auto-traits. - Borrowed temporaries in future are likely to be considered to be live across the yield for the purpose of the generator transform. Signed-off-by: David Wood ,THUMBS_UP,2019-09-09T10:37:48Z,kellytk,NA https://github.com/rust-lang/rust/pull/64292,MERGED,2019-09-08T20:27:18Z,2019-09-10T20:22:16Z,lowering: extend temporary lifetimes around await,davidtwco,63fad69a9967a56e33927aa31c50768bc1498588,4,lowering: extend temporary lifetimes around await This commit changes the HIR lowering around `await` so that temporary lifetimes are extended. Previously await was lowered as: ```rust { let mut pinned = future; loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` With this commit await is lowered as: ```rust match future { mut pinned => loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` However this change has the following side-effects: - All temporaries in future will be considered to live across a yield for the purpose of auto-traits. - Borrowed temporaries in future are likely to be considered to be live across the yield for the purpose of the generator transform. Signed-off-by: David Wood ,HOORAY,2019-09-10T10:32:36Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64292,MERGED,2019-09-08T20:27:18Z,2019-09-10T20:22:16Z,lowering: extend temporary lifetimes around await,davidtwco,63fad69a9967a56e33927aa31c50768bc1498588,4,lowering: extend temporary lifetimes around await This commit changes the HIR lowering around `await` so that temporary lifetimes are extended. Previously await was lowered as: ```rust { let mut pinned = future; loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` With this commit await is lowered as: ```rust match future { mut pinned => loop { match ::std::future::poll_with_tls_context(unsafe { <::std::pin::Pin>::new_unchecked(&mut pinned) }) { ::std::task::Poll::Ready(result) => break result ::std::task::Poll::Pending => {} } yield (); } } ``` However this change has the following side-effects: - All temporaries in future will be considered to live across a yield for the purpose of auto-traits. - Borrowed temporaries in future are likely to be considered to be live across the yield for the purpose of the generator transform. Signed-off-by: David Wood ,HOORAY,2019-09-20T04:23:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-09T12:33:05Z,est31,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-09T14:39:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-10T04:49:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-10T09:06:02Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-11T06:54:04Z,mati865,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-13T15:27:58Z,lqd,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-14T14:13:15Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-19T16:20:27Z,estebank,NA https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-20T04:23:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-09-26T09:46:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2019-10-17T23:25:01Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/64302,MERGED,2019-09-09T07:53:44Z,2019-09-14T18:53:56Z,Shrink `ObligationCauseCode`,nnethercote,2e3b079836823446eb014c69866d6a0f8cca4ef2,5,Shrink `ObligationCauseCode` by boxing `IfExpression`. The reduction in `memcpy` calls outweighs the cost of the extra allocations for a net performance win.,HEART,2020-06-23T21:30:05Z,LionsAd,fabianfranz.oss@gmail.com https://github.com/rust-lang/rust/pull/64315,CLOSED,2019-09-09T16:48:58Z,2019-12-02T14:18:53Z,"Fixes soundness bug 18510 by aborting on unwind from safe extern ""C"" functions only",gnzlbg,NA,NA,NA,THUMBS_UP,2019-09-20T09:38:22Z,harrysarson,NA https://github.com/rust-lang/rust/pull/64315,CLOSED,2019-09-09T16:48:58Z,2019-12-02T14:18:53Z,"Fixes soundness bug 18510 by aborting on unwind from safe extern ""C"" functions only",gnzlbg,NA,NA,NA,THUMBS_UP,2019-11-29T08:33:16Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-09T17:48:55Z,tmandry,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-09T18:12:10Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-09T20:56:05Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-10T00:32:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-10T04:43:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-10T05:56:53Z,est31,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-10T07:17:46Z,mati865,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-10T22:25:40Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-13T05:27:32Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-13T13:57:04Z,sanmai-NL,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-17T14:58:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2019-09-28T14:55:09Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64316,MERGED,2019-09-09T17:38:00Z,2019-09-24T10:41:49Z,Delete most of `src/bootstrap/bin/rustc.rs`,alexcrichton,1a8897fd8a988cc3c81b7cb985005d6cf836116c,1,Fix rebase conflicts,HEART,2020-06-18T06:05:35Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-09-09T22:38:24Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-09-11T06:13:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-09-11T12:52:23Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-10-11T19:12:04Z,dcreager,dcreager@dcreager.net https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-10-16T22:14:34Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-10-24T06:55:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-10-24T11:42:31Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-10-24T12:53:46Z,Boiethios,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-11-01T23:10:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-12-05T06:18:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-12-05T19:47:15Z,chrish42,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-12-07T09:00:08Z,kgv,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2019-12-23T21:31:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-01-04T22:38:56Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-01-06T20:45:27Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-01-28T11:20:11Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-01-31T06:34:46Z,chirsz-ever,chirsz@foxmail.com https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-02-01T01:25:02Z,Folyd,NA https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2020-02-15T12:18:27Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/64325,MERGED,2019-09-09T22:32:21Z,2019-11-28T00:37:13Z,Stabilize nested self receivers in 1.41.0,cramertj,2083e2a6473ea9d2fc65097844c9e0fec899b225,58,Stabilize nested self receivers Previously only Self &Self &mut Self Arc Rc and Box were available as stable method receivers. This commit stabilizes nested uses of all the above types. However nested receivers remain non-object-safe.,HOORAY,2022-03-15T01:23:12Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/64334,MERGED,2019-09-10T05:46:03Z,2019-09-12T02:51:05Z,Add i686-unknown-uefi target,jyao1,21e062da2fa1a476380d64f5479e5049067648cb,2,Add i686-unknown-uefi target This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi we cannot use -gnu because the ABI between MSVC and GNU is totally different and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi the UEFI chooses cdecl ABI which is same as MSVC and GNU. According to LLVM code the only differences between MSVC and GNU are fmodf(f32) longjmp() and TLS which have no impact to UEFI. As such using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett Reviewed-by: Josh Triplett ,THUMBS_UP,2020-04-28T14:52:04Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/64334,MERGED,2019-09-10T05:46:03Z,2019-09-12T02:51:05Z,Add i686-unknown-uefi target,jyao1,21e062da2fa1a476380d64f5479e5049067648cb,2,Add i686-unknown-uefi target This adds a new rustc target-configuration called 'i686-unknown_uefi'. This is similar to existing x86_64-unknown_uefi target. The i686-unknown-uefi target can be used to build Intel Architecture 32bit UEFI application. The ABI defined in UEFI environment (aka IA32) is similar to cdecl. We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid the intrinsics generated by LLVM. The detail of root-cause and solution analysis is added as comment in the code. For x86_64-unknown-uefi we cannot use -gnu because the ABI between MSVC and GNU is totally different and UEFI chooses ABI similar to MSVC. For i686-unknown-uefi the UEFI chooses cdecl ABI which is same as MSVC and GNU. According to LLVM code the only differences between MSVC and GNU are fmodf(f32) longjmp() and TLS which have no impact to UEFI. As such using i686-unknown-uefi-gnu is the simplest way to pass the build. Adding the undefined symbols such as _aulldiv() to rust compiler-builtins is out of scope. But it may be considered later. The scope of this patch is limited to support target-configuration. No standard library support is added in this patch. Such work can be done in future enhancement. Cc: Josh Triplett Reviewed-by: Josh Triplett ,HEART,2020-04-28T14:52:05Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T10:59:09Z,mati865,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T13:18:53Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T13:31:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T14:32:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2019-09-10T14:34:16Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T16:05:37Z,estebank,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2019-09-10T16:05:46Z,estebank,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2019-09-10T20:28:37Z,cramertj,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-10T20:28:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2019-09-19T17:53:26Z,tux3,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2019-09-20T04:22:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2019-11-28T23:04:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,LAUGH,2020-01-22T22:03:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,HOORAY,2022-03-24T11:48:12Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/64344,MERGED,2019-09-10T10:49:43Z,2019-09-10T20:22:21Z,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,eddyb,1e7faef2204f02d79506559d298f61dc3dcd24b3,1,rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.,THUMBS_UP,2022-03-24T11:48:14Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/64358,MERGED,2019-09-10T17:15:26Z,2019-10-08T01:05:32Z,Rebase rustc-rayon on rayon-1.2,cuviper,29cd7eb6c9d9061d10af6207fd77705eeb4d6549,1,Update other rayon uses to 1.2 too,HEART,2019-09-10T20:53:57Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64358,MERGED,2019-09-10T17:15:26Z,2019-10-08T01:05:32Z,Rebase rustc-rayon on rayon-1.2,cuviper,29cd7eb6c9d9061d10af6207fd77705eeb4d6549,1,Update other rayon uses to 1.2 too,HEART,2019-09-11T07:11:59Z,mati865,NA https://github.com/rust-lang/rust/pull/64358,MERGED,2019-09-10T17:15:26Z,2019-10-08T01:05:32Z,Rebase rustc-rayon on rayon-1.2,cuviper,29cd7eb6c9d9061d10af6207fd77705eeb4d6549,1,Update other rayon uses to 1.2 too,HEART,2019-09-22T10:31:29Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/64359,MERGED,2019-09-10T17:17:47Z,2019-09-12T16:38:28Z,"Forbid opaque types in `extern ""C""` blocks",varkor,9d712177a34d42c9d78aab4a77d1a36692bc7fc1,13,"Refactor ""not FFI-safe"" diagnostic",THUMBS_UP,2019-09-10T20:51:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64359,MERGED,2019-09-10T17:17:47Z,2019-09-12T16:38:28Z,"Forbid opaque types in `extern ""C""` blocks",varkor,9d712177a34d42c9d78aab4a77d1a36692bc7fc1,13,"Refactor ""not FFI-safe"" diagnostic",HEART,2019-09-10T22:54:29Z,estebank,NA https://github.com/rust-lang/rust/pull/64374,MERGED,2019-09-11T10:45:19Z,2019-09-14T18:53:53Z,Box `DiagnosticBuilder`.,nnethercote,2fcd870711ce267c79408ec631f7eba8e0afcdf6,4,Box `DiagnosticBuilder`. It's a large type -- 176 bytes on 64-bit. And it's passed around and returned from a lot of functions including within PResult. This commit boxes it which reduces memory traffic. In particular `PResult` shrinks to 16 bytes in the best case; this reduces instruction counts by up to 2% on various workloads.,HOORAY,2019-09-11T14:54:50Z,zackmdavis,NA https://github.com/rust-lang/rust/pull/64374,MERGED,2019-09-11T10:45:19Z,2019-09-14T18:53:53Z,Box `DiagnosticBuilder`.,nnethercote,2fcd870711ce267c79408ec631f7eba8e0afcdf6,4,Box `DiagnosticBuilder`. It's a large type -- 176 bytes on 64-bit. And it's passed around and returned from a lot of functions including within PResult. This commit boxes it which reduces memory traffic. In particular `PResult` shrinks to 16 bytes in the best case; this reduces instruction counts by up to 2% on various workloads.,HOORAY,2019-09-11T20:17:43Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/64384,MERGED,2019-09-11T18:56:29Z,2019-09-14T18:53:50Z,Trim rustc-workspace-hack,mati865,612c3947b4550fb093f54ce56b1580685bfe92fd,2,Trim rustc-workspace-hack,HEART,2019-09-12T04:02:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/64386,MERGED,2019-09-11T20:40:43Z,2019-09-25T18:34:59Z,use `sign` variable in abs and wrapping_abs methods,tspiteri,562903a0a684860c0e51971ea11f1ce97795d6a2,1,use `sign` variable in abs and wrapping_abs methods This also makes the code easier to understand by hinting at the significance of `self >> ($BITS - 1)` and by including an explanation in the comments. Also now overflowing_abs simply uses wrapping_abs which is clearer and avoids a potential performance regression in the LLVM IR.,HEART,2019-09-12T14:21:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/64398,CLOSED,2019-09-12T07:42:41Z,2019-09-29T12:06:14Z,[WIP] Crater rollup of 3 PRs (#63809 #63812 #63831).,eddyb,NA,NA,NA,THUMBS_UP,2019-09-12T07:57:09Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/64406,MERGED,2019-09-12T14:48:45Z,2019-09-15T00:10:05Z,Ban non-extern rust intrinsics,Mark-Simulacrum,7b3adc289eb84f21199d1f2aeac9d88779b7369b,9,Ban non-extern rust intrinsics Intrinsics can only be defined by the compiler.,THUMBS_UP,2019-09-12T15:29:41Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/64408,MERGED,2019-09-12T16:57:44Z,2019-09-14T18:53:41Z,codegen: be more explicit about setting giving names to allocas.,eddyb,e9214a147b09f8020f82b450e7c9e16290649909,10,codegen: be more explicit about setting giving names to allocas.,HEART,2019-09-12T18:15:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/64415,CLOSED,2019-09-12T21:48:05Z,2019-10-05T17:36:55Z,Sort diagnostics by custom span,mark-i-m,NA,NA,NA,HEART,2019-09-15T02:53:17Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/64416,MERGED,2019-09-12T21:48:14Z,2019-09-17T05:11:10Z,Various refactorings to clean up nll diagnostics,mark-i-m,2a774b1e6bfda649f75dcc6d32502100f8420a3a,1,address Centril's comments,HEART,2019-09-15T02:53:08Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/64424,CLOSED,2019-09-13T10:55:45Z,2019-10-05T18:17:54Z,"Fix false ""never constructed"" warnings for `Self::` variant paths",jakubadamw,NA,NA,NA,HEART,2019-09-14T00:45:54Z,estebank,NA https://github.com/rust-lang/rust/pull/64424,CLOSED,2019-09-13T10:55:45Z,2019-10-05T18:17:54Z,"Fix false ""never constructed"" warnings for `Self::` variant paths",jakubadamw,NA,NA,NA,HEART,2019-09-17T04:38:47Z,iliana,iliana@buttslol.net https://github.com/rust-lang/rust/pull/64424,CLOSED,2019-09-13T10:55:45Z,2019-10-05T18:17:54Z,"Fix false ""never constructed"" warnings for `Self::` variant paths",jakubadamw,NA,NA,NA,HEART,2020-01-08T12:36:13Z,nikonthethird,NA https://github.com/rust-lang/rust/pull/64424,CLOSED,2019-09-13T10:55:45Z,2019-10-05T18:17:54Z,"Fix false ""never constructed"" warnings for `Self::` variant paths",jakubadamw,NA,NA,NA,HEART,2020-01-27T04:26:03Z,vorot93,artem@vorotnikov.me https://github.com/rust-lang/rust/pull/64424,CLOSED,2019-09-13T10:55:45Z,2019-10-05T18:17:54Z,"Fix false ""never constructed"" warnings for `Self::` variant paths",jakubadamw,NA,NA,NA,HEART,2020-02-22T06:46:28Z,seiyab,NA https://github.com/rust-lang/rust/pull/64432,MERGED,2019-09-13T15:19:38Z,2019-11-15T04:32:06Z,Make the semantics of Vec::truncate(N) consistent with slices.,gnzlbg,6da4df9fc95c1da7373f49c07742a42aaf840198,1,"Make the semantics of Vec::truncate(N) consistent with slices. This commit simplifies the implementation of `Vec::truncate(N)` and makes its semantics identical to dropping the `[vec.len() - N..]` sub-slice tail of the vector which is the same behavior as dropping a vector containing the same sub-slice. This changes two unspecified aspects of `Vec::truncate` behavior: * the drop order from back-to-front to front-to-back * the behavior of `Vec::truncate` on panics: if dropping one element of the tail panics currently `Vec::truncate` panics but with this PR all other elements are still dropped and if dropping a second element of the tail panics with this PR the program aborts. Programs can trivially observe both changes. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)): ```rust fn main() { struct Bomb(usize); impl Drop for Bomb { fn drop(&mut self) { panic!(format!(""{}"" self.0)); } } let mut v = vec![Bomb(0) Bomb(1)]; std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| { v.truncate(0); })); assert_eq!(v.len() 1); std::mem::forget(v); } ``` panics printing `1` today and succeeds. With this change it panics printing `0` first (due to the drop order change) and then aborts with a double-panic printing `1` just like dropping the `[Bomb(0) Bomb(1)]` slice does or dropping `vec![Bomb(0) Bomb(1)]` does.",CONFUSED,2019-11-08T07:03:06Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/64432,MERGED,2019-09-13T15:19:38Z,2019-11-15T04:32:06Z,Make the semantics of Vec::truncate(N) consistent with slices.,gnzlbg,6da4df9fc95c1da7373f49c07742a42aaf840198,1,"Make the semantics of Vec::truncate(N) consistent with slices. This commit simplifies the implementation of `Vec::truncate(N)` and makes its semantics identical to dropping the `[vec.len() - N..]` sub-slice tail of the vector which is the same behavior as dropping a vector containing the same sub-slice. This changes two unspecified aspects of `Vec::truncate` behavior: * the drop order from back-to-front to front-to-back * the behavior of `Vec::truncate` on panics: if dropping one element of the tail panics currently `Vec::truncate` panics but with this PR all other elements are still dropped and if dropping a second element of the tail panics with this PR the program aborts. Programs can trivially observe both changes. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)): ```rust fn main() { struct Bomb(usize); impl Drop for Bomb { fn drop(&mut self) { panic!(format!(""{}"" self.0)); } } let mut v = vec![Bomb(0) Bomb(1)]; std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| { v.truncate(0); })); assert_eq!(v.len() 1); std::mem::forget(v); } ``` panics printing `1` today and succeeds. With this change it panics printing `0` first (due to the drop order change) and then aborts with a double-panic printing `1` just like dropping the `[Bomb(0) Bomb(1)]` slice does or dropping `vec![Bomb(0) Bomb(1)]` does.",THUMBS_UP,2019-11-26T19:16:04Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64439,MERGED,2019-09-13T18:43:58Z,2019-09-14T18:53:42Z,fix #64430 confusing `owned_box` error message in no_std build,12101111,e484f213eebd2a61870eb25a6cee0992eab6275c,1,add trailing newline,HEART,2019-09-14T00:48:22Z,estebank,NA https://github.com/rust-lang/rust/pull/64444,MERGED,2019-09-13T20:41:53Z,2019-09-16T19:30:07Z,fix building libstd without backtrace feature,RalfJung,49854c4f71eb8470c2a4483cbad3f03eb99e67cb,2,avoid #[cfg] in favor of cfg!,THUMBS_UP,2019-09-13T22:16:51Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/64444,MERGED,2019-09-13T20:41:53Z,2019-09-16T19:30:07Z,fix building libstd without backtrace feature,RalfJung,49854c4f71eb8470c2a4483cbad3f03eb99e67cb,2,avoid #[cfg] in favor of cfg!,THUMBS_UP,2019-09-14T09:05:38Z,bjorn3,NA https://github.com/rust-lang/rust/pull/64457,MERGED,2019-09-14T14:52:42Z,2019-09-15T07:48:59Z,def_collector: Do not ICE on attributes on unnamed fields,petrochenkov,c681cf781b440620aca8cad4be9b76a477fc6c1a,1,def_collector: Factor out common field handling code,HOORAY,2019-09-15T00:38:06Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64459,CLOSED,2019-09-14T15:57:19Z,2019-09-27T01:08:05Z,Enable test-compare-mode on PR builder,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-09-14T15:58:57Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64459,CLOSED,2019-09-14T15:57:19Z,2019-09-27T01:08:05Z,Enable test-compare-mode on PR builder,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-09-14T16:28:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64459,CLOSED,2019-09-14T15:57:19Z,2019-09-27T01:08:05Z,Enable test-compare-mode on PR builder,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-09-16T11:36:09Z,mati865,NA https://github.com/rust-lang/rust/pull/64462,MERGED,2019-09-14T19:03:07Z,2019-09-15T00:10:01Z,feature_gate: Remove dead code from attribute checking,petrochenkov,cb771fdd6c927a4308440cad1607570140f058d6,1,feature_gate: Eliminate `check::Context` Use `PostExpansionVisitor` directly instead,THUMBS_UP,2019-09-15T00:37:58Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-14T23:52:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-15T12:54:39Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-15T18:49:06Z,est31,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-16T15:18:08Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-17T07:12:37Z,mati865,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-19T14:25:32Z,ProfFan,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-24T08:52:50Z,oli-obk,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-24T09:30:20Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-25T14:55:55Z,varkor,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-25T15:02:51Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-28T14:18:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-09-30T10:33:28Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-10-02T17:54:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-10-03T13:16:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-10-19T13:14:19Z,hugecheese,NA https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2019-10-26T16:34:06Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64470,MERGED,2019-09-14T21:50:03Z,2019-09-29T06:09:04Z,Implement dataflow-based const validation,ecstatic-morse,0bf1a80b322f285efb9ea45b62e7dc764ebe1954,2,Rename `sty` to `kind` Picks up changes made in #64513,HOORAY,2020-04-16T09:58:12Z,tema3210,NA https://github.com/rust-lang/rust/pull/64481,MERGED,2019-09-15T05:48:43Z,2019-09-25T05:53:49Z,A more explanatory thread local storage panic message,tomtau,68c3739f1268e496c096d89ab9e556f196e35974,1,updated the panic message wording,HEART,2019-09-15T06:16:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/64485,MERGED,2019-09-15T11:57:15Z,2019-09-17T01:06:42Z,update Miri,RalfJung,b7ebbc291a6304488eac6b13d5656d6981728551,1,update miri for latest breakage,THUMBS_UP,2019-09-16T11:34:17Z,mati865,NA https://github.com/rust-lang/rust/pull/64495,CLOSED,2019-09-15T19:42:23Z,2019-09-18T07:27:54Z,[WIP-test run] switch rustc allocator to mimalloc,gnzlbg,NA,NA,NA,HEART,2019-09-16T02:15:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-16T05:04:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-16T12:15:48Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-17T01:26:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-19T02:29:59Z,sinkuu,NA https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-20T11:41:55Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-20T12:24:29Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-21T09:46:02Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/64498,MERGED,2019-09-16T05:02:29Z,2019-09-20T11:39:09Z,When possible point at argument causing item obligation failure,estebank,c34d9e6a92fae416821f45d2b86c261f62aaf4f9,1,add comments,HEART,2019-09-21T22:20:24Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/64500,MERGED,2019-09-16T06:40:33Z,2019-09-17T05:11:06Z,Various `ObligationForest` improvements,nnethercote,4ecd94e1215882efde5f003c0042bd72a5f8acb2,1,Move `impl Node` just after `struct Node`.,HEART,2019-09-16T20:59:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/64500,MERGED,2019-09-16T06:40:33Z,2019-09-17T05:11:06Z,Various `ObligationForest` improvements,nnethercote,4ecd94e1215882efde5f003c0042bd72a5f8acb2,1,Move `impl Node` just after `struct Node`.,HEART,2019-09-25T17:03:17Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/64500,MERGED,2019-09-16T06:40:33Z,2019-09-17T05:11:06Z,Various `ObligationForest` improvements,nnethercote,4ecd94e1215882efde5f003c0042bd72a5f8acb2,1,Move `impl Node` just after `struct Node`.,HEART,2019-09-26T09:46:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64525,MERGED,2019-09-16T20:21:36Z,2019-09-17T22:21:12Z,adjust desugaring for async fn to correct drop order,nikomatsakis,2d8b10f63c394c99f2268de3132086bc72ee5a2b,1,adjust larger comment to include the body,HEART,2019-09-17T22:36:51Z,sfackler,NA https://github.com/rust-lang/rust/pull/64525,MERGED,2019-09-16T20:21:36Z,2019-09-17T22:21:12Z,adjust desugaring for async fn to correct drop order,nikomatsakis,2d8b10f63c394c99f2268de3132086bc72ee5a2b,1,adjust larger comment to include the body,HEART,2019-09-18T01:36:04Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/64528,MERGED,2019-09-16T23:14:44Z,2019-09-18T08:41:33Z,Load proc macro metadata in the correct order.,Aaron1011,3daa8bd2e473c80e71b036786fa15729960562af,3,Generate proc macro harness in AST order. This ensures that we match the order used by proc macro metadata serialization. Fixes #64251,THUMBS_UP,2019-09-16T23:19:47Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/64528,MERGED,2019-09-16T23:14:44Z,2019-09-18T08:41:33Z,Load proc macro metadata in the correct order.,Aaron1011,3daa8bd2e473c80e71b036786fa15729960562af,3,Generate proc macro harness in AST order. This ensures that we match the order used by proc macro metadata serialization. Fixes #64251,THUMBS_UP,2019-09-16T23:22:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64529,MERGED,2019-09-16T23:25:11Z,2019-09-18T02:13:07Z,Add an example to Pin::as_mut,taiki-e,a22e9ee8d0801f9738533b76a492e94065767cbc,1,Update src/libcore/pin.rs Co-Authored-By: Ralf Jung ,HEART,2019-09-17T00:54:49Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/64541,MERGED,2019-09-17T06:59:18Z,2019-09-18T02:13:06Z,document Miri error categories,RalfJung,daafeb35b731a599fc8b6c4cf37b81f838dae319,1,document Miri error categories,THUMBS_UP,2019-09-17T15:01:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64543,MERGED,2019-09-17T08:02:42Z,2019-09-17T14:43:44Z,Revert #64451,pietroalbini,a7a6dedfe661a6d9d181afeb0fbaa894fcb7362b,4,"Revert ""Rollup merge of #64451 - RalfJung:miri-manifest r=pietroalbini"" This reverts commit 7975973e2b806a7ee8e54b40f9e774528a777e31 reversing changes made to f0320e54c7c2c923e2e05996ac1d74f781115bbc.",THUMBS_UP,2019-09-17T08:35:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-18T01:43:16Z,shengsheng,NA https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-18T03:06:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-18T08:29:50Z,mati865,NA https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-25T22:48:12Z,cbourjau,NA https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-26T09:47:05Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64545,MERGED,2019-09-17T11:48:25Z,2019-09-19T10:45:04Z,More `ObligationForest` improvements,nnethercote,3b85597d22dc9dc9226445a95e275b8130880e63,2,Add a specialized version of `shallow_resolve()`. The super-hot call site of `inlined_shallow_resolve()` basically does `r.inlined_shallow_resolve(ty) != ty`. This commit introduces a version of that function specialized for that particular call pattern `shallow_resolve_changed()`. Incredibly this reduces the instruction count for `keccak` by 5%. The commit also renames `inlined_shallow_resolve()` as `shallow_resolve()` and removes the `inline(always)` annotation as it's no longer nearly so hot.,ROCKET,2019-09-26T13:43:08Z,est31,NA https://github.com/rust-lang/rust/pull/64553,MERGED,2019-09-17T16:01:05Z,2019-09-20T15:35:57Z,azure: Convert Windows installations scripts to `bash`,alexcrichton,72ea960056d40f1fcb5efb42d5914b35f908f63e,1,"azure: Convert Windows installations scripts to `bash` Looks like `script` which uses `cmd.exe` doesn't have fail-fast behavior and if a leading command fails the script doesn't actually fail so long as the last command succeeds. We instead want the opposite behavior where if any step fails the whole script fails. I don't really know `cmd.exe` that well nor powershell so I've opted to move everything to `bash` which should be a good common denominator amongst all platforms to work with. Additionally I know that `set -e` works to cause scripts to fail fast. Note that some scripts remain as `script` since they don't appear to work in` bash`. I'm not really sure why but I reorganized them slightly to have the ""meaty command"" run at the end.",THUMBS_UP,2019-09-17T18:15:27Z,mati865,NA https://github.com/rust-lang/rust/pull/64553,MERGED,2019-09-17T16:01:05Z,2019-09-20T15:35:57Z,azure: Convert Windows installations scripts to `bash`,alexcrichton,72ea960056d40f1fcb5efb42d5914b35f908f63e,1,"azure: Convert Windows installations scripts to `bash` Looks like `script` which uses `cmd.exe` doesn't have fail-fast behavior and if a leading command fails the script doesn't actually fail so long as the last command succeeds. We instead want the opposite behavior where if any step fails the whole script fails. I don't really know `cmd.exe` that well nor powershell so I've opted to move everything to `bash` which should be a good common denominator amongst all platforms to work with. Additionally I know that `set -e` works to cause scripts to fail fast. Note that some scripts remain as `script` since they don't appear to work in` bash`. I'm not really sure why but I reorganized them slightly to have the ""meaty command"" run at the end.",THUMBS_UP,2019-09-18T03:47:02Z,reaperhulk,NA https://github.com/rust-lang/rust/pull/64566,MERGED,2019-09-18T00:38:04Z,2019-09-19T06:53:47Z,A more generic interface for dataflow analysis,ecstatic-morse,b4e94d9a3a04798201676be8f18ee483eb292104,1,Fix bug where `is_call_return_effect_applied` was never set,HEART,2019-09-18T07:48:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/64566,MERGED,2019-09-18T00:38:04Z,2019-09-19T06:53:47Z,A more generic interface for dataflow analysis,ecstatic-morse,b4e94d9a3a04798201676be8f18ee483eb292104,1,Fix bug where `is_call_return_effect_applied` was never set,HEART,2019-09-18T13:11:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64566,MERGED,2019-09-18T00:38:04Z,2019-09-19T06:53:47Z,A more generic interface for dataflow analysis,ecstatic-morse,b4e94d9a3a04798201676be8f18ee483eb292104,1,Fix bug where `is_call_return_effect_applied` was never set,HEART,2019-10-15T17:12:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-18T11:37:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,LAUGH,2019-09-18T12:33:53Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-18T15:38:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,ROCKET,2019-09-18T15:38:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,ROCKET,2019-09-19T01:31:55Z,shengsheng,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-19T05:05:45Z,Lokathor,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,EYES,2019-09-19T11:28:11Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-19T14:15:37Z,deg4uss3r,ricky_github@hosfe.lt https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,ROCKET,2019-09-19T14:15:38Z,deg4uss3r,ricky_github@hosfe.lt https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-19T16:13:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-19T16:20:47Z,nwtnni,nwtnni@gmail.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,ROCKET,2019-09-19T16:20:49Z,nwtnni,nwtnni@gmail.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,ROCKET,2019-09-19T16:26:44Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-19T16:26:45Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-19T16:26:46Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-19T21:39:09Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-19T21:39:11Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-19T22:56:10Z,polybuildr,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-22T02:48:27Z,sbrichardson,srichardson@reactual.io https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,LAUGH,2019-09-23T22:19:25Z,cramertj,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-23T22:19:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-09-25T14:00:26Z,unneon,mateusz@cegla.net https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,THUMBS_UP,2019-10-11T05:46:01Z,rlabrecque,NA https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,HEART,2019-10-17T13:40:25Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/64572,CLOSED,2019-09-18T07:35:04Z,2019-09-30T23:52:47Z,Simplify some `Iterator` methods.,nnethercote,NA,NA,NA,LAUGH,2020-02-12T09:42:00Z,bb010g,NA https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2019-09-20T06:07:14Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-09-20T06:07:16Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-09-20T08:50:40Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2019-09-20T08:50:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2019-09-20T09:49:30Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-09-20T09:53:21Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-09-20T12:27:48Z,Dante-Broggi,NA https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-10-17T07:06:49Z,sindresorhus,sindresorhus@gmail.com https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2019-10-18T19:51:25Z,kiliankoe,me@kilian.io https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2019-10-18T19:51:26Z,kiliankoe,me@kilian.io https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2020-04-04T21:37:08Z,simlay,NA https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,HOORAY,2020-04-04T21:37:08Z,simlay,NA https://github.com/rust-lang/rust/pull/64582,CLOSED,2019-09-18T17:54:19Z,2019-10-24T00:34:13Z,Add Swift function call ABI,nvzqz,NA,NA,NA,THUMBS_UP,2020-07-10T22:15:25Z,UebelAndre,NA https://github.com/rust-lang/rust/pull/64583,MERGED,2019-09-18T17:58:10Z,2019-09-18T21:42:35Z,Rollup of 5 pull requests,tmandry,eeda31385df59b17d997d65e73e4ad474f27b96a,2,Rollup merge of #64580 - ehuss:update-books r=ehuss Update books ## book 24 commits in 7ddc46460f09a5cd9bd2a620565bdc20b3315ea9..871416b85c1a73717d65d6f4a9ea29e5aef3db0e 2019-06-27 09:50:36 -0400 to 2019-09-16 09:46:20 -0400 - Ch16-2 add missing Ferris (rust-lang/book#2033) - Update version mentioned on the front page - Update error messages (rust-lang/book#1737) - Update version of Rust used to 1.37 - Replace Cargo docs link with a more specific link (rust-lang/book#2066) - Added missing await reserved keyword (rust-lang/book#2064) - add does_not_compile for a snippet (rust-lang/book#2056) - Added second missing dyn (rust-lang/book#2046) - Removed unnecessary & in function call (rust-lang/book#2038) - Printing non-Display structs is a *compile* error (rust-lang/book#2031) - Update Readme mdBook version to match linked file (rust-lang/book#2012) - Update loose mdbook version reference (rust-lang/book#2003) - Added a bullet point to have list of things unsafe allows for match u… (rust-lang/book#1993) - Rewrote a confusing sentence (rust-lang/book#1986) - Replace deprecated `...` range syntax with `..=` (rust-lang/book#1977) - correct wording for integration test doc (rust-lang/book#1971) - Mark the dangle function as does_not_compile (rust-lang/book#1965) - Add more words to the quote from the actual Go documentation (rust-lang/book#1960) - Remove unused import in lfp (rust-lang/book#1944) - A small typo? (rust-lang/book#1931) - Make the code not compile to match the text (rust-lang/book#1926) - Ferris does-not-compile added (ch9.2) (rust-lang/book#1925) - ch07 - remove note regarding use and relative path (rust-lang/book#1820) - tweak opening paragraph of deref coercions (rust-lang/book#1749) ## rust-by-example 9 commits in e76be6b2dc84c6a992e186157efe29d625e29b94..67cfbf31df880728dcf7cb35b15b028ec92caf31 2019-09-03 07:42:26 -0300 to 2019-09-18 09:36:40 -0300 - Fix rust-lang/rust-by-example#90: Add supertraits and Fully Qualified syntax (rust-lang/rust-by-example#1259) - Fix some broken links. (rust-lang/rust-by-example#1258) - Fix rust-lang/rust-by-example#1253: Document enum type aliases (rust-lang/rust-by-example#1255) - Inline code in some new/changed chapters (rust-lang/rust-by-example#1254) - fix rust-lang/rust-by-example#1067: explain that unit tests can return Result<()> (rust-lang/rust-by-example#1252) - Fix rust-lang/rust-by-example#1060: add page on Impl Trait (rust-lang/rust-by-example#1251) - Fix rust-lang/rust-by-example#1053: Added a page about the dyn keyword (rust-lang/rust-by-example#1249) - Fix rust-lang/rust-by-example#1110: add examples of ? and Option (rust-lang/rust-by-example#1250) - fix 1037: add the TryFrom chapter back in (rust-lang/rust-by-example#1247),HEART,2019-09-18T18:37:11Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64584,MERGED,2019-09-18T18:42:38Z,2019-09-20T19:31:13Z,record fewer adjustment types in generator witnesses avoid spurious drops in MIR construction,nikomatsakis,77fd0a76491afb4c93359f6ceb33a9f79c4f4228,1,add a mir-opt test that we don't add the spurious drop,HEART,2019-09-19T16:17:52Z,sfackler,NA https://github.com/rust-lang/rust/pull/64584,MERGED,2019-09-18T18:42:38Z,2019-09-20T19:31:13Z,record fewer adjustment types in generator witnesses avoid spurious drops in MIR construction,nikomatsakis,77fd0a76491afb4c93359f6ceb33a9f79c4f4228,1,add a mir-opt test that we don't add the spurious drop,HEART,2019-09-19T16:23:02Z,Bunogi,haakon.jordet@gmail.com https://github.com/rust-lang/rust/pull/64584,MERGED,2019-09-18T18:42:38Z,2019-09-20T19:31:13Z,record fewer adjustment types in generator witnesses avoid spurious drops in MIR construction,nikomatsakis,77fd0a76491afb4c93359f6ceb33a9f79c4f4228,1,add a mir-opt test that we don't add the spurious drop,HEART,2019-09-19T17:58:07Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/64584,MERGED,2019-09-18T18:42:38Z,2019-09-20T19:31:13Z,record fewer adjustment types in generator witnesses avoid spurious drops in MIR construction,nikomatsakis,77fd0a76491afb4c93359f6ceb33a9f79c4f4228,1,add a mir-opt test that we don't add the spurious drop,HEART,2019-09-21T02:43:52Z,jmealo,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T21:12:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T21:20:40Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T21:42:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T22:14:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T22:26:51Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T22:37:50Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T22:46:10Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-18T22:47:50Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-19T07:43:43Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-09-20T09:42:11Z,harrysarson,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-10-03T07:33:54Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-10-08T15:57:04Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-10-09T21:25:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-11-26T01:06:48Z,jplatte,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-12-20T22:01:24Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-12-27T13:08:38Z,dlight,NA https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2019-12-27T13:49:14Z,burjui,bytefu@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2020-01-03T17:12:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64588,MERGED,2019-09-18T20:48:59Z,2019-12-20T19:43:55Z,"Add a raw ""address of"" operator",matthewjasper,a74911662e8de2c024ea188e4dcac6a494c74455,1,Fix comment ordering,HOORAY,2020-08-09T15:50:07Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/64592,MERGED,2019-09-18T22:36:19Z,2019-09-20T02:43:08Z,Point at original span when emitting unreachable lint,Aaron1011,d67528ff7dbbe226fa583b9585cee2138533770e,1,Merge inherent impl blocks for `Diverges,HOORAY,2019-09-19T22:00:57Z,estebank,NA https://github.com/rust-lang/rust/pull/64595,MERGED,2019-09-18T23:40:07Z,2019-10-17T18:53:49Z,Optimize dropck,Mark-Simulacrum,8de7fd884a9478e8fc41a810b9f4b647634efd0c,1,Keep allocated vectors during dropck Previously we'd frequently throw away vectors which is bad for performance,HOORAY,2019-10-24T09:30:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/64595,MERGED,2019-09-18T23:40:07Z,2019-10-17T18:53:49Z,Optimize dropck,Mark-Simulacrum,8de7fd884a9478e8fc41a810b9f4b647634efd0c,1,Keep allocated vectors during dropck Previously we'd frequently throw away vectors which is bad for performance,HOORAY,2019-10-26T07:46:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64599,MERGED,2019-09-19T03:33:24Z,2019-09-25T05:53:45Z,Rustdoc render async function re-export,csmoe,a744fd04321f6307303a22ecc8880cbc7b6bcbda,2,bug-out asyncness query on non-local funtions,HOORAY,2019-09-19T10:54:56Z,95th,NA https://github.com/rust-lang/rust/pull/64599,MERGED,2019-09-19T03:33:24Z,2019-09-25T05:53:45Z,Rustdoc render async function re-export,csmoe,a744fd04321f6307303a22ecc8880cbc7b6bcbda,2,bug-out asyncness query on non-local funtions,HOORAY,2019-09-20T17:24:23Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/64611,MERGED,2019-09-19T15:37:41Z,2019-09-20T02:43:05Z,rustbuild: Don't package libstd twice,alexcrichton,2fff78038cf3eb38f2bd3fecbab123bccb59c1a8,1,rustbuild: Don't package libstd twice Looks like the packaging step for the standard library was happening twice on CI but it only needs to happen once! The `Analysis` packaging step accidentally packaged `Std` instead of relying on compiling `Std` which meant that we ended up packaging it twice erroneously.,HOORAY,2019-09-19T17:59:04Z,mati865,NA https://github.com/rust-lang/rust/pull/64613,MERGED,2019-09-19T15:38:12Z,2019-09-20T02:43:04Z,rustbuild: Copy crate doc files fewer times,alexcrichton,d7f64749c0d32f3d63c0ee5d0999fce99f222553,1,rustbuild: Copy crate doc files fewer times Previously when building documentation for the standard library we'd copy all the files 5 times and these files include libcore/libstd docs which are huge! This commit instead only copies the files after rustdoc has been run for each crate reducing the number of redundant copies we're making.,HOORAY,2019-09-19T17:59:32Z,mati865,NA https://github.com/rust-lang/rust/pull/64613,MERGED,2019-09-19T15:38:12Z,2019-09-20T02:43:04Z,rustbuild: Copy crate doc files fewer times,alexcrichton,d7f64749c0d32f3d63c0ee5d0999fce99f222553,1,rustbuild: Copy crate doc files fewer times Previously when building documentation for the standard library we'd copy all the files 5 times and these files include libcore/libstd docs which are huge! This commit instead only copies the files after rustdoc has been run for each crate reducing the number of redundant copies we're making.,HOORAY,2019-09-25T18:11:40Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/64613,MERGED,2019-09-19T15:38:12Z,2019-09-20T02:43:04Z,rustbuild: Copy crate doc files fewer times,alexcrichton,d7f64749c0d32f3d63c0ee5d0999fce99f222553,1,rustbuild: Copy crate doc files fewer times Previously when building documentation for the standard library we'd copy all the files 5 times and these files include libcore/libstd docs which are huge! This commit instead only copies the files after rustdoc has been run for each crate reducing the number of redundant copies we're making.,THUMBS_UP,2019-09-25T21:37:57Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/64619,MERGED,2019-09-19T18:48:09Z,2019-09-22T06:33:07Z,Fixes #63962. Hint about missing tuple parentheses in patterns,sam09,a2a57bc6cf383fc113335148296c7965bb29e9a2,3,Fixes #63962. Hint about missing tuple parentheses in patterns,HEART,2019-09-19T21:57:53Z,estebank,NA https://github.com/rust-lang/rust/pull/64619,MERGED,2019-09-19T18:48:09Z,2019-09-22T06:33:07Z,Fixes #63962. Hint about missing tuple parentheses in patterns,sam09,a2a57bc6cf383fc113335148296c7965bb29e9a2,3,Fixes #63962. Hint about missing tuple parentheses in patterns,HEART,2019-09-19T22:03:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64623,MERGED,2019-09-19T20:54:25Z,2019-10-16T02:54:31Z,Remove last uses of gensyms,matthewjasper,4198df1f4be969747bc92254185ae4983e8f3c5c,2,Remove some mentions of gensyms,HOORAY,2019-09-20T00:15:24Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/64623,MERGED,2019-09-19T20:54:25Z,2019-10-16T02:54:31Z,Remove last uses of gensyms,matthewjasper,4198df1f4be969747bc92254185ae4983e8f3c5c,2,Remove some mentions of gensyms,HEART,2019-09-26T23:02:44Z,nnethercote,NA https://github.com/rust-lang/rust/pull/64623,MERGED,2019-09-19T20:54:25Z,2019-10-16T02:54:31Z,Remove last uses of gensyms,matthewjasper,4198df1f4be969747bc92254185ae4983e8f3c5c,2,Remove some mentions of gensyms,HOORAY,2019-09-27T07:04:08Z,mati865,NA https://github.com/rust-lang/rust/pull/64623,MERGED,2019-09-19T20:54:25Z,2019-10-16T02:54:31Z,Remove last uses of gensyms,matthewjasper,4198df1f4be969747bc92254185ae4983e8f3c5c,2,Remove some mentions of gensyms,HOORAY,2019-10-16T10:50:08Z,Zoxc,zoxc32@gmail.com https://github.com/rust-lang/rust/pull/64623,MERGED,2019-09-19T20:54:25Z,2019-10-16T02:54:31Z,Remove last uses of gensyms,matthewjasper,4198df1f4be969747bc92254185ae4983e8f3c5c,2,Remove some mentions of gensyms,HOORAY,2020-02-12T12:24:40Z,bb010g,NA https://github.com/rust-lang/rust/pull/64627,MERGED,2019-09-20T02:57:26Z,2019-09-25T09:54:59Z,Even more `ObligationForest` improvements,nnethercote,aa10abb2119f0740aac704a78d6eebd800ddb1da,1,Rename a variable. Because the meaning of this `index` variable is quite different to all the other `index` variables in this file.,THUMBS_UP,2019-10-03T13:06:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64627,MERGED,2019-09-20T02:57:26Z,2019-09-25T09:54:59Z,Even more `ObligationForest` improvements,nnethercote,aa10abb2119f0740aac704a78d6eebd800ddb1da,1,Rename a variable. Because the meaning of this `index` variable is quite different to all the other `index` variables in this file.,THUMBS_UP,2019-10-17T19:50:20Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/64634,MERGED,2019-09-20T16:37:29Z,2019-09-22T06:33:05Z,Update to LLVM 9.0.0,cuviper,633ad73ef17c02e1893becbd030e2d188851042c,2,Update to LLVM 9.0.0,HOORAY,2019-09-27T03:00:42Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/64634,MERGED,2019-09-20T16:37:29Z,2019-09-22T06:33:05Z,Update to LLVM 9.0.0,cuviper,633ad73ef17c02e1893becbd030e2d188851042c,2,Update to LLVM 9.0.0,HOORAY,2019-09-28T23:05:09Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/64634,MERGED,2019-09-20T16:37:29Z,2019-09-22T06:33:05Z,Update to LLVM 9.0.0,cuviper,633ad73ef17c02e1893becbd030e2d188851042c,2,Update to LLVM 9.0.0,HOORAY,2020-04-21T21:33:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-20T20:51:38Z,lqd,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-20T22:47:32Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-21T10:41:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-21T11:44:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-21T17:45:20Z,killercup,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-09-22T13:17:42Z,hgzimmerman,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-09-30T08:17:23Z,argv-minus-one,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-01T13:08:03Z,sfackler,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-10-01T19:27:01Z,est31,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-06T11:13:18Z,jplatte,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HEART,2019-10-09T19:52:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-09T21:50:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HEART,2019-10-11T03:28:17Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-10-11T03:28:17Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-11T03:28:18Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-10-29T20:20:36Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-29T20:20:37Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HEART,2019-10-29T20:21:13Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-10-30T18:23:43Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-10-31T02:10:18Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-11-05T16:36:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-11-08T23:04:01Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-11-08T23:04:02Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2019-12-10T22:24:30Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,HOORAY,2019-12-10T22:24:31Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/64639,MERGED,2019-09-20T20:44:33Z,2019-10-25T14:34:39Z,Stabilize `#[non_exhaustive]` (RFC 2008),davidtwco,e0590ea76f528357add6fd6615a82cf49e44f271,36,RFC 2008: Stabilization This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood ,ROCKET,2020-11-01T09:53:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-09-21T08:23:00Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-09-22T03:18:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-09-23T11:26:53Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-09-23T16:53:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-09-24T01:21:47Z,qnighy,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-09-24T01:21:49Z,qnighy,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-09-25T17:52:33Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-09-25T17:52:34Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-10-02T10:12:10Z,bluss,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-10-06T18:09:22Z,moshg,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-10-18T10:08:14Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-10-21T17:44:03Z,nixpulvis,nathan@nixpulvis.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-10-21T17:44:03Z,nixpulvis,nathan@nixpulvis.com https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HOORAY,2019-10-22T08:57:04Z,dorayakikun,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-10-22T08:57:05Z,dorayakikun,NA https://github.com/rust-lang/rust/pull/64648,CLOSED,2019-09-21T01:28:34Z,2020-05-21T21:50:20Z,REPL part 1: Added interpreter mode to compiler interface interpreter parsing functionality,alexreg,NA,NA,NA,HEART,2019-11-11T17:01:05Z,XVilka,xvilka@gmail.com https://github.com/rust-lang/rust/pull/64649,MERGED,2019-09-21T03:25:22Z,2019-10-02T10:01:13Z,Avoid ICE on return outside of fn with literal array,estebank,0e6fb8e8da2f3256f9e2c2c079b8174acf80d94d,1,review comments,LAUGH,2019-09-22T20:18:43Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,ROCKET,2019-09-23T12:30:59Z,mati865,NA https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,ROCKET,2019-09-23T23:01:32Z,cramertj,NA https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,ROCKET,2019-09-26T07:14:45Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,ROCKET,2021-03-02T17:01:05Z,omid,NA https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,ROCKET,2021-06-19T00:04:11Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/64663,MERGED,2019-09-21T17:55:22Z,2019-09-25T13:49:42Z,libtest: Add --report-time flag to print test execution time,jakoschiko,d91b965664c47cdf8dfa060f17f50d2fe972c2de,1,libtest: Make --report-time an unstable option,HEART,2021-10-17T12:37:26Z,bert2,NA https://github.com/rust-lang/rust/pull/64669,MERGED,2019-09-21T19:53:14Z,2019-09-22T10:21:06Z,Use span label instead of note in unreachable lint,estebank,9991d548c72529a7475d33c6925ee23601568aec,1,review comments,HEART,2019-09-22T01:30:04Z,tmandry,NA https://github.com/rust-lang/rust/pull/64670,MERGED,2019-09-21T19:57:46Z,2019-09-23T06:38:30Z,Cleanup syntax::ext::build,Mark-Simulacrum,8417ac67c3fe979098facad586438ea5244617b3,4,Inline attribute constructors,HEART,2019-09-21T20:07:46Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64670,MERGED,2019-09-21T19:57:46Z,2019-09-23T06:38:30Z,Cleanup syntax::ext::build,Mark-Simulacrum,8417ac67c3fe979098facad586438ea5244617b3,4,Inline attribute constructors,HEART,2019-09-21T21:16:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64670,MERGED,2019-09-21T19:57:46Z,2019-09-23T06:38:30Z,Cleanup syntax::ext::build,Mark-Simulacrum,8417ac67c3fe979098facad586438ea5244617b3,4,Inline attribute constructors,HEART,2019-09-21T23:22:39Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/64670,MERGED,2019-09-21T19:57:46Z,2019-09-23T06:38:30Z,Cleanup syntax::ext::build,Mark-Simulacrum,8417ac67c3fe979098facad586438ea5244617b3,4,Inline attribute constructors,HEART,2019-09-22T06:01:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/64672,CLOSED,2019-09-21T22:21:48Z,2019-11-16T15:37:36Z,Pre-expansion gate some more things,Centril,NA,NA,NA,THUMBS_UP,2019-09-22T08:47:33Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/64674,MERGED,2019-09-21T23:31:55Z,2019-09-23T06:38:29Z,Propagate `types.err` in locals further to avoid spurious knock-down errors,estebank,daed67481511b65475069214cd8325ca9d018509,3,review comments,HEART,2019-09-22T03:25:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/64674,MERGED,2019-09-21T23:31:55Z,2019-09-23T06:38:29Z,Propagate `types.err` in locals further to avoid spurious knock-down errors,estebank,daed67481511b65475069214cd8325ca9d018509,3,review comments,HEART,2019-09-23T17:33:32Z,bluss,NA https://github.com/rust-lang/rust/pull/64679,MERGED,2019-09-22T05:43:57Z,2019-09-23T06:38:26Z,Infer consts more consistently,skinny121,3f2855e4a6003f7e4d5736843d9ca5f327bef9d7,7,Infer consts consistently. Moved some logic into super_combined_consts also removed some duplicated logic from TypeRelation methods.,HEART,2019-09-22T14:08:32Z,varkor,NA https://github.com/rust-lang/rust/pull/64679,MERGED,2019-09-22T05:43:57Z,2019-09-23T06:38:26Z,Infer consts more consistently,skinny121,3f2855e4a6003f7e4d5736843d9ca5f327bef9d7,7,Infer consts consistently. Moved some logic into super_combined_consts also removed some duplicated logic from TypeRelation methods.,HEART,2019-09-23T07:05:43Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64679,MERGED,2019-09-22T05:43:57Z,2019-09-23T06:38:26Z,Infer consts more consistently,skinny121,3f2855e4a6003f7e4d5736843d9ca5f327bef9d7,7,Infer consts consistently. Moved some logic into super_combined_consts also removed some duplicated logic from TypeRelation methods.,HEART,2019-09-26T11:14:14Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/64683,CLOSED,2019-09-22T09:43:55Z,2019-11-02T01:10:39Z,Add is_const_eval intrinsic,gnzlbg,NA,NA,NA,HOORAY,2019-09-23T07:25:26Z,mati865,NA https://github.com/rust-lang/rust/pull/64689,MERGED,2019-09-22T16:45:59Z,2019-09-25T01:46:51Z,Refactor macro by example,matklad,81fe85710d7f749c87494c4b968861adc67a9c4a,4,make mbe::TokenTree private to module,HEART,2019-09-22T22:26:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64690,MERGED,2019-09-22T16:58:59Z,2019-10-04T03:35:51Z,proc_macro API: Expose `macro_rules` hygiene,petrochenkov,d1310dc6c989e191d85c73c943d4175fbf1dccb8,10,proc_macro: Add `Span::mixed_site` exposing `macro_rules` hygiene,EYES,2019-09-22T18:40:48Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/64690,MERGED,2019-09-22T16:58:59Z,2019-10-04T03:35:51Z,proc_macro API: Expose `macro_rules` hygiene,petrochenkov,d1310dc6c989e191d85c73c943d4175fbf1dccb8,10,proc_macro: Add `Span::mixed_site` exposing `macro_rules` hygiene,EYES,2019-10-03T19:17:21Z,macpp,NA https://github.com/rust-lang/rust/pull/64691,MERGED,2019-09-22T18:30:06Z,2019-09-29T22:21:55Z,Point at definition when misusing ADT,estebank,2ae90165534f18aa5020ae84f5e3768e99139069,20,Point at definition when misusing ADT When given `struct Foo(usize)` and using it as `Foo {}` or `Foo` point at `Foo`'s definition in the error.,HEART,2019-09-30T02:47:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/64691,MERGED,2019-09-22T18:30:06Z,2019-09-29T22:21:55Z,Point at definition when misusing ADT,estebank,2ae90165534f18aa5020ae84f5e3768e99139069,20,Point at definition when misusing ADT When given `struct Foo(usize)` and using it as `Foo {}` or `Foo` point at `Foo`'s definition in the error.,HEART,2019-10-03T13:24:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64694,MERGED,2019-09-22T22:15:33Z,2019-11-16T22:55:04Z,Fully integrate derive helpers into name resolution,petrochenkov,8668c1a19015148821c37255922f9a9b603dd148,3,Add some more tests,THUMBS_UP,2019-09-25T00:22:40Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64694,MERGED,2019-09-22T22:15:33Z,2019-11-16T22:55:04Z,Fully integrate derive helpers into name resolution,petrochenkov,8668c1a19015148821c37255922f9a9b603dd148,3,Add some more tests,THUMBS_UP,2019-10-08T23:55:32Z,estebank,NA https://github.com/rust-lang/rust/pull/64694,MERGED,2019-09-22T22:15:33Z,2019-11-16T22:55:04Z,Fully integrate derive helpers into name resolution,petrochenkov,8668c1a19015148821c37255922f9a9b603dd148,3,Add some more tests,THUMBS_UP,2019-11-06T19:15:49Z,theduke,NA https://github.com/rust-lang/rust/pull/64694,MERGED,2019-09-22T22:15:33Z,2019-11-16T22:55:04Z,Fully integrate derive helpers into name resolution,petrochenkov,8668c1a19015148821c37255922f9a9b603dd148,3,Add some more tests,THUMBS_UP,2019-11-26T06:17:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64698,MERGED,2019-09-23T03:09:49Z,2019-09-25T01:46:49Z,Recover on `const X = 42;` and infer type + Error Stash API,Centril,f70665a84692a80a820fccdaed19df5dde94c533,5,cleanup librustc_errors Handler code.,HEART,2019-09-23T13:12:35Z,bjorn3,NA https://github.com/rust-lang/rust/pull/64698,MERGED,2019-09-23T03:09:49Z,2019-09-25T01:46:49Z,Recover on `const X = 42;` and infer type + Error Stash API,Centril,f70665a84692a80a820fccdaed19df5dde94c533,5,cleanup librustc_errors Handler code.,HOORAY,2019-09-23T18:50:15Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/64698,MERGED,2019-09-23T03:09:49Z,2019-09-25T01:46:49Z,Recover on `const X = 42;` and infer type + Error Stash API,Centril,f70665a84692a80a820fccdaed19df5dde94c533,5,cleanup librustc_errors Handler code.,HEART,2019-09-24T22:29:24Z,varkor,NA https://github.com/rust-lang/rust/pull/64698,MERGED,2019-09-23T03:09:49Z,2019-09-25T01:46:49Z,Recover on `const X = 42;` and infer type + Error Stash API,Centril,f70665a84692a80a820fccdaed19df5dde94c533,5,cleanup librustc_errors Handler code.,HOORAY,2019-09-25T07:24:53Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64700,CLOSED,2019-09-23T05:00:14Z,2019-10-21T11:49:02Z,Suggest enclosing const expression in block,estebank,NA,NA,NA,HEART,2019-09-23T11:13:59Z,varkor,NA https://github.com/rust-lang/rust/pull/64700,CLOSED,2019-09-23T05:00:14Z,2019-10-21T11:49:02Z,Suggest enclosing const expression in block,estebank,NA,NA,NA,HEART,2019-09-23T19:40:26Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64700,CLOSED,2019-09-23T05:00:14Z,2019-10-21T11:49:02Z,Suggest enclosing const expression in block,estebank,NA,NA,NA,HEART,2020-04-04T20:46:14Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/64702,MERGED,2019-09-23T06:26:51Z,2019-09-25T01:46:48Z,Remove unused dependencies,sinkuu,0423c2a7a35ce17b44b4c93c227177fc0fcd7217,12,Remove unused dependencies,HEART,2019-09-24T04:31:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/64702,MERGED,2019-09-23T06:26:51Z,2019-09-25T01:46:48Z,Remove unused dependencies,sinkuu,0423c2a7a35ce17b44b4c93c227177fc0fcd7217,12,Remove unused dependencies,HEART,2019-09-24T19:56:12Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/64708,MERGED,2019-09-23T13:54:12Z,2019-10-06T08:40:40Z,Stabilize `Option::as_deref` and `Option::as_deref_mut`,SimonSapin,0797712e295e6c67b39d57d0801de9d0c6f9b100,10,Stabilize Option::deref and Option::deref_mut The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.,THUMBS_UP,2019-09-26T09:33:07Z,robjtede,NA https://github.com/rust-lang/rust/pull/64708,MERGED,2019-09-23T13:54:12Z,2019-10-06T08:40:40Z,Stabilize `Option::as_deref` and `Option::as_deref_mut`,SimonSapin,0797712e295e6c67b39d57d0801de9d0c6f9b100,10,Stabilize Option::deref and Option::deref_mut The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.,THUMBS_UP,2019-09-26T21:12:37Z,timotree3,timorcb@gmail.com https://github.com/rust-lang/rust/pull/64708,MERGED,2019-09-23T13:54:12Z,2019-10-06T08:40:40Z,Stabilize `Option::as_deref` and `Option::as_deref_mut`,SimonSapin,0797712e295e6c67b39d57d0801de9d0c6f9b100,10,Stabilize Option::deref and Option::deref_mut The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.,THUMBS_UP,2019-10-10T08:51:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64708,MERGED,2019-09-23T13:54:12Z,2019-10-06T08:40:40Z,Stabilize `Option::as_deref` and `Option::as_deref_mut`,SimonSapin,0797712e295e6c67b39d57d0801de9d0c6f9b100,10,Stabilize Option::deref and Option::deref_mut The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.,THUMBS_UP,2019-10-11T05:38:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64708,MERGED,2019-09-23T13:54:12Z,2019-10-06T08:40:40Z,Stabilize `Option::as_deref` and `Option::as_deref_mut`,SimonSapin,0797712e295e6c67b39d57d0801de9d0c6f9b100,10,Stabilize Option::deref and Option::deref_mut The tracking issue https://github.com/rust-lang/rust/issues/50264 still has unresolved question for the corresponding `Result` methods.,THUMBS_UP,2020-02-27T20:37:56Z,frol,NA https://github.com/rust-lang/rust/pull/64709,MERGED,2019-09-23T15:17:21Z,2019-09-24T01:03:42Z,[stable] 1.38.0 release,Mark-Simulacrum,e67a2238a50874a00aa92ba29533088af65ab7d2,1,[stable] 1.38.0 release,HOORAY,2019-09-23T15:43:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64709,MERGED,2019-09-23T15:17:21Z,2019-09-24T01:03:42Z,[stable] 1.38.0 release,Mark-Simulacrum,e67a2238a50874a00aa92ba29533088af65ab7d2,1,[stable] 1.38.0 release,HOORAY,2019-09-23T17:46:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64709,MERGED,2019-09-23T15:17:21Z,2019-09-24T01:03:42Z,[stable] 1.38.0 release,Mark-Simulacrum,e67a2238a50874a00aa92ba29533088af65ab7d2,1,[stable] 1.38.0 release,HOORAY,2019-09-23T19:46:44Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64709,MERGED,2019-09-23T15:17:21Z,2019-09-24T01:03:42Z,[stable] 1.38.0 release,Mark-Simulacrum,e67a2238a50874a00aa92ba29533088af65ab7d2,1,[stable] 1.38.0 release,HOORAY,2019-09-24T01:04:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/64709,MERGED,2019-09-23T15:17:21Z,2019-09-24T01:03:42Z,[stable] 1.38.0 release,Mark-Simulacrum,e67a2238a50874a00aa92ba29533088af65ab7d2,1,[stable] 1.38.0 release,HOORAY,2019-09-24T03:18:40Z,hyyzzz111,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-23T18:05:39Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-23T18:43:41Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-25T15:57:26Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-25T16:54:27Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-25T18:48:14Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-26T10:29:42Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,THUMBS_UP,2019-09-27T00:24:54Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-09-28T17:02:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-10-02T17:44:21Z,blackbeam,aikorsky@gmail.com https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-10-10T21:42:52Z,bluss,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,THUMBS_UP,2019-10-17T02:45:22Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64716,MERGED,2019-09-23T17:55:45Z,2019-10-11T16:28:32Z,Stabilize mem::take (mem_take),jonhoo,45aca119a6c94a2c408fb6da7a47d363ab852bac,14,Stabilize mem::take (mem_take) Tracking issue: https://github.com/rust-lang/rust/issues/61129,HEART,2019-10-17T18:46:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64721,MERGED,2019-09-23T23:27:01Z,2019-09-25T01:46:45Z,Fixed issue from #64447,hman523,a6da0e921b01352dbdf45320afc9e41f27ac5784,1,changed a line from an if else to std::cmp::max,THUMBS_UP,2019-09-24T10:45:43Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/64721,MERGED,2019-09-23T23:27:01Z,2019-09-25T01:46:45Z,Fixed issue from #64447,hman523,a6da0e921b01352dbdf45320afc9e41f27ac5784,1,changed a line from an if else to std::cmp::max,THUMBS_UP,2019-09-24T18:22:05Z,estebank,NA https://github.com/rust-lang/rust/pull/64721,MERGED,2019-09-23T23:27:01Z,2019-09-25T01:46:45Z,Fixed issue from #64447,hman523,a6da0e921b01352dbdf45320afc9e41f27ac5784,1,changed a line from an if else to std::cmp::max,THUMBS_UP,2019-09-30T22:48:43Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/64722,MERGED,2019-09-23T23:32:03Z,2019-10-02T10:01:10Z,Make all alt builders produce parallel-enabled compilers,Mark-Simulacrum,1a1067d1a537d6495f6aa9703e10119f05d578ad,4,"Make the default parallelism 1 This changes the default parallelism for parallel compilers to one instead of the previous default which was ""num cpus"". This is likely not an optimal default long-term but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.",ROCKET,2019-09-23T23:33:47Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/64722,MERGED,2019-09-23T23:32:03Z,2019-10-02T10:01:10Z,Make all alt builders produce parallel-enabled compilers,Mark-Simulacrum,1a1067d1a537d6495f6aa9703e10119f05d578ad,4,"Make the default parallelism 1 This changes the default parallelism for parallel compilers to one instead of the previous default which was ""num cpus"". This is likely not an optimal default long-term but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.",ROCKET,2019-09-24T00:27:01Z,est31,NA https://github.com/rust-lang/rust/pull/64722,MERGED,2019-09-23T23:32:03Z,2019-10-02T10:01:10Z,Make all alt builders produce parallel-enabled compilers,Mark-Simulacrum,1a1067d1a537d6495f6aa9703e10119f05d578ad,4,"Make the default parallelism 1 This changes the default parallelism for parallel compilers to one instead of the previous default which was ""num cpus"". This is likely not an optimal default long-term but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.",ROCKET,2019-09-24T04:46:19Z,ljedrz,NA https://github.com/rust-lang/rust/pull/64722,MERGED,2019-09-23T23:32:03Z,2019-10-02T10:01:10Z,Make all alt builders produce parallel-enabled compilers,Mark-Simulacrum,1a1067d1a537d6495f6aa9703e10119f05d578ad,4,"Make the default parallelism 1 This changes the default parallelism for parallel compilers to one instead of the previous default which was ""num cpus"". This is likely not an optimal default long-term but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.",ROCKET,2019-09-24T07:05:10Z,mati865,NA https://github.com/rust-lang/rust/pull/64722,MERGED,2019-09-23T23:32:03Z,2019-10-02T10:01:10Z,Make all alt builders produce parallel-enabled compilers,Mark-Simulacrum,1a1067d1a537d6495f6aa9703e10119f05d578ad,4,"Make the default parallelism 1 This changes the default parallelism for parallel compilers to one instead of the previous default which was ""num cpus"". This is likely not an optimal default long-term but it is a good default for testing whether parallel compilers are not a significant regression over a sequential compiler. Notably this in theory makes a parallel-enabled compiler behave exactly like a sequential compiler with respect to the jobserver.",ROCKET,2019-10-11T05:31:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64728,MERGED,2019-09-24T07:11:05Z,2019-10-06T08:40:39Z,Stabilize UdpSocket::peer_addr,messense,1de6f74ca47718ae22d7d76eff2986847c659390,1,Update src/libstd/net/udp.rs Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-09-30T10:36:00Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/64728,MERGED,2019-09-24T07:11:05Z,2019-10-06T08:40:39Z,Stabilize UdpSocket::peer_addr,messense,1de6f74ca47718ae22d7d76eff2986847c659390,1,Update src/libstd/net/udp.rs Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-10-11T05:31:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64736,MERGED,2019-09-24T13:09:44Z,2019-12-02T18:00:55Z,Remove interior mutability in mir predecessors cache,Nashenas88,3eaad564d25402013bdf5591c453c916b49cdf93,2,Fix issues caused during rebasing,THUMBS_UP,2019-12-23T20:04:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64737,MERGED,2019-09-24T13:32:19Z,2019-09-25T01:46:43Z,fix several issues in String docs,jordins,62dc7948d1e6b45e25a2ce177f76f257f3a5c1a4,1,fix several issues in String docs - In some places &str was shown instead of String. - into_bytes is the reverse of from_utf8 Fixes #63797,THUMBS_UP,2019-09-24T15:17:48Z,sam09,sk09idm@gmail.com https://github.com/rust-lang/rust/pull/64738,MERGED,2019-09-24T14:16:02Z,2019-09-25T18:34:43Z,Add const-eval support for SIMD types insert and extract,gnzlbg,5ecb7eb161e75ab33ca015e7f717424f32af3d59,10,Remove fail tests,HEART,2019-10-02T23:22:45Z,novacrazy,NA https://github.com/rust-lang/rust/pull/64738,MERGED,2019-09-24T14:16:02Z,2019-09-25T18:34:43Z,Add const-eval support for SIMD types insert and extract,gnzlbg,5ecb7eb161e75ab33ca015e7f717424f32af3d59,10,Remove fail tests,HEART,2019-10-03T01:14:11Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64738,MERGED,2019-09-24T14:16:02Z,2019-09-25T18:34:43Z,Add const-eval support for SIMD types insert and extract,gnzlbg,5ecb7eb161e75ab33ca015e7f717424f32af3d59,10,Remove fail tests,HEART,2019-10-03T13:16:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64739,MERGED,2019-09-24T15:14:46Z,2019-10-07T09:20:08Z,Remove as_str if the type is already &str,guanqun,11c2d43485e92a00d86b3a5bc1655165b6b8371b,1,typo fix in the code,HEART,2019-09-24T18:26:52Z,estebank,NA https://github.com/rust-lang/rust/pull/64742,MERGED,2019-09-24T16:37:02Z,2019-09-25T01:46:42Z,relnotes: make compatibility section more sterile and fix rustc version,pietroalbini,e8cf46e909bcfb6c77b3efb2a60ed674770e1603,1,relnotes: make compatibility section more sterile and fix rustc version,HEART,2019-09-24T16:46:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-09-24T19:57:50Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-09-24T20:39:52Z,eopb,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-09-25T03:08:39Z,elahn,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-02T21:15:11Z,leoyvens,leoyvens@gmail.com https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-08T04:25:19Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-08T14:08:27Z,hgzimmerman,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-24T05:47:51Z,kcking,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-24T13:00:24Z,Boiethios,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-10-28T06:14:17Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64747,MERGED,2019-09-24T19:26:24Z,2019-10-28T07:39:16Z,Stabilize `Option::flatten`,eopb,65af429c681e874bee6fb3a864ae3496517a72f4,2,Stabilize `Option::flatten`,HOORAY,2019-11-05T16:35:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64749,MERGED,2019-09-24T21:11:31Z,2019-10-04T11:20:35Z,Fix most remaining Polonius test differences,matthewjasper,2180c243214ebce29c45c37020e929924a8520d8,5,Make lifetimes in constants live at the point of use,THUMBS_UP,2019-09-26T17:56:33Z,lqd,NA https://github.com/rust-lang/rust/pull/64749,MERGED,2019-09-24T21:11:31Z,2019-10-04T11:20:35Z,Fix most remaining Polonius test differences,matthewjasper,2180c243214ebce29c45c37020e929924a8520d8,5,Make lifetimes in constants live at the point of use,THUMBS_UP,2019-09-26T18:04:13Z,amandasystems,mail@amandastjerna.se https://github.com/rust-lang/rust/pull/64749,MERGED,2019-09-24T21:11:31Z,2019-10-04T11:20:35Z,Fix most remaining Polonius test differences,matthewjasper,2180c243214ebce29c45c37020e929924a8520d8,5,Make lifetimes in constants live at the point of use,THUMBS_UP,2019-10-05T02:27:18Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/64756,CLOSED,2019-09-25T06:07:55Z,2019-10-03T15:04:24Z,Fix GAT lifetime bounds,PlasmaPower,NA,NA,NA,THUMBS_UP,2019-09-25T14:58:14Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64756,CLOSED,2019-09-25T06:07:55Z,2019-10-03T15:04:24Z,Fix GAT lifetime bounds,PlasmaPower,NA,NA,NA,THUMBS_UP,2019-09-25T22:31:30Z,tmandry,NA https://github.com/rust-lang/rust/pull/64756,CLOSED,2019-09-25T06:07:55Z,2019-10-03T15:04:24Z,Fix GAT lifetime bounds,PlasmaPower,NA,NA,NA,THUMBS_UP,2019-10-02T12:35:16Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/64757,CLOSED,2019-09-25T06:11:09Z,2019-09-26T02:38:03Z,Always inline `InterpCx::step()`.,nnethercote,NA,NA,NA,THUMBS_UP,2019-09-25T13:23:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64759,MERGED,2019-09-25T07:31:53Z,2019-09-25T18:34:41Z,Refactor mbe a tiny bit,matklad,f60a8734e088f3383512b0ffc12a9a909d2163b4,1,remove unused peekable,HEART,2019-09-25T13:27:16Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64772,MERGED,2019-09-25T17:28:10Z,2019-09-27T00:15:44Z,Remove tx_to_llvm_workers from TyCtxt,Mark-Simulacrum,b8a040fc5f5edc41af0ccb070239898c0c5d5484,10,Remove tx_to_llvm_workers from TyCtxt This can be kept within the codegen backend crates entirely,HOORAY,2019-09-25T18:14:03Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64772,MERGED,2019-09-25T17:28:10Z,2019-09-27T00:15:44Z,Remove tx_to_llvm_workers from TyCtxt,Mark-Simulacrum,b8a040fc5f5edc41af0ccb070239898c0c5d5484,10,Remove tx_to_llvm_workers from TyCtxt This can be kept within the codegen backend crates entirely,HOORAY,2019-09-26T06:56:35Z,mati865,NA https://github.com/rust-lang/rust/pull/64772,MERGED,2019-09-25T17:28:10Z,2019-09-27T00:15:44Z,Remove tx_to_llvm_workers from TyCtxt,Mark-Simulacrum,b8a040fc5f5edc41af0ccb070239898c0c5d5484,10,Remove tx_to_llvm_workers from TyCtxt This can be kept within the codegen backend crates entirely,HOORAY,2019-09-26T14:21:04Z,bjorn3,NA https://github.com/rust-lang/rust/pull/64778,MERGED,2019-09-25T18:58:48Z,2019-09-30T17:26:33Z,Introduce librustc_index crate,csmoe,64f61c7888c9cb2cbd7d37f87a6cbec2858ee409,125,remove indexed_vec re-export from rustc_data_structures,CONFUSED,2019-10-02T13:45:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/64780,MERGED,2019-09-25T20:18:55Z,2019-10-07T17:45:47Z,Only add sanitizer runtimes when linking an executable (#64629).,choller,640c261a1f2b6bdd994670246772c15af199c65a,1,Only add sanitizer runtimes when linking an executable (#64629).,THUMBS_UP,2019-10-11T05:27:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64781,MERGED,2019-09-25T20:44:17Z,2019-09-28T07:27:59Z,Remove stray references to the old global tcx,Mark-Simulacrum,4b23503b4285f7dd9ee92fd267b3cafaa723a048,8,Remove shrink_to_tcx_lifetime There's no longer two distinct gcx and tcx lifetimes which made this necessary (or at least the code compiles -- it's possible we got better at normalizing but that seems unlikely).,HOORAY,2019-09-26T06:47:15Z,mati865,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-25T23:37:48Z,varkor,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-25T23:50:26Z,nnethercote,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-25T23:57:18Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T00:51:42Z,shengsheng,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T01:02:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T01:09:03Z,crlf0710,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T01:38:31Z,cynecx,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T01:42:59Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T02:27:02Z,declanvk,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T02:27:03Z,declanvk,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T02:49:25Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T02:49:29Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T03:53:40Z,ljedrz,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T04:31:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T04:35:30Z,cwfitzgerald,connorwadefitzgerald@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T04:35:31Z,cwfitzgerald,connorwadefitzgerald@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T04:41:48Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T05:14:54Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T06:33:56Z,mati865,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T06:33:57Z,mati865,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T07:02:22Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T07:04:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T07:04:18Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:00:57Z,kali,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:26:19Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T08:27:00Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T08:27:08Z,Thiez,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T08:35:59Z,leudz,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:43:09Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T08:46:04Z,pbzweihander,pbzweihander@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:52:48Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:57:25Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T08:57:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T08:57:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T08:57:36Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T08:57:58Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T09:01:28Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:01:30Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T09:07:53Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T09:07:55Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:07:56Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T09:21:29Z,CryZe,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:21:30Z,CryZe,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T09:21:31Z,CryZe,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:21:50Z,beefsack,beefsack@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:24:51Z,josalhor,txemtech@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T09:46:48Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T09:57:35Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T10:04:12Z,hgallagher1993,hgallagher@protonmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T10:16:34Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T10:32:13Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T10:37:15Z,Speedy37,vincent@speedy37.fr https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T10:59:11Z,aheart,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:00:19Z,gilesv,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:04:15Z,bertof,berto.f@protonmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T11:13:10Z,dbrgn,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:14:57Z,weihanglo,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T11:14:58Z,weihanglo,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T11:14:59Z,weihanglo,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:15:06Z,henzosabiq,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T11:20:34Z,futile,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:21:19Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T11:27:46Z,fmckeogh,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:44:37Z,alexbool,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:47:43Z,jumbatm,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T11:55:34Z,bstrie,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:56:56Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T11:56:57Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T11:56:57Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T11:59:40Z,joshirio,joshirio@protonmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:18:01Z,jojva,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T12:28:56Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:28:57Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:28:58Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T12:29:01Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:35:20Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:36:23Z,tomsik68,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:38:08Z,Bannerets,comonoid@protonmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:43:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:43:24Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:43:27Z,fan-tom,lokomot476@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T12:43:28Z,fan-tom,lokomot476@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T12:43:29Z,fan-tom,lokomot476@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T12:43:29Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T12:43:31Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:44:42Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,CONFUSED,2019-09-26T12:44:44Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,EYES,2019-09-26T12:44:51Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T12:44:55Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_DOWN,2019-09-26T12:44:58Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:45:01Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T12:45:03Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T12:45:05Z,Duddino,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:45:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:45:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:55:23Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T12:55:56Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:55:58Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T12:56:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:56:32Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T12:57:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T12:59:42Z,wjzz,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:07:25Z,choleraehyq,choleraehyq@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T13:08:24Z,sunjay,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T13:08:27Z,sunjay,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:08:27Z,sunjay,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T13:09:34Z,repi,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T13:13:03Z,arusahni,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T13:28:33Z,Noxime,aaro.peramaa@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:32:58Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:35:50Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T13:36:37Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:36:40Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T13:44:19Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T13:48:04Z,unleashed,alex@flawedcode.org https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:52:24Z,bernardobelchior,Bernardo.belchior1@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T13:56:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T13:57:50Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T14:01:34Z,endrin,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:05:26Z,DeltaManiac,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:10:29Z,svmnotn,svmnotn@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T14:14:21Z,bjorn3,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:15:04Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T14:17:49Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T14:21:42Z,jq-rs,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:26:39Z,gralpli,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:29:43Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:29:58Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T14:34:17Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T14:34:19Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:52:33Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T14:52:50Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T14:52:54Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:55:25Z,WilliamAAK,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T14:55:26Z,WilliamAAK,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T14:57:24Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T14:57:27Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T14:58:01Z,pvdrz,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T14:59:57Z,Adyel,8qs5ipo9h@relay.firefox.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T15:08:35Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T15:08:37Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T15:08:39Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T15:23:05Z,chrish42,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T15:23:07Z,chrish42,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T15:23:12Z,chrish42,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T15:29:00Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T15:40:31Z,PaulGrandperrin,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T15:49:54Z,dmitmel,dmytro.meleshko@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T16:14:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T16:18:59Z,panaman67,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T16:19:18Z,marcogroppo,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T16:19:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T16:19:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T16:19:26Z,crides,zhuhaoqing@live.cn https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T16:19:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T16:22:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T16:42:04Z,insipx,aplaza@liquidthink.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T16:42:06Z,insipx,aplaza@liquidthink.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T16:50:25Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T17:29:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T17:29:51Z,cramertj,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-26T17:29:53Z,cramertj,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T17:36:14Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T17:44:52Z,Aetf,aetf@unlimited-code.works https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T17:44:53Z,Aetf,aetf@unlimited-code.works https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-26T18:24:37Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T19:06:02Z,andoriyu,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T19:18:35Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T19:21:27Z,kiljacken,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T20:17:35Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T20:17:35Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T20:52:53Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-26T21:49:24Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-26T22:31:09Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-26T22:35:11Z,estebank,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-27T00:40:00Z,joealden,me@joealden.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T00:57:36Z,jgilchrist,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-27T01:29:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-27T02:56:52Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T03:25:24Z,PeytonT,donaldpeytonturner@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T07:06:45Z,mandrean,sebastian.mandrean@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T09:51:34Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-27T09:51:37Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-27T12:47:11Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-27T12:47:11Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T12:47:14Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T12:50:46Z,Havvy,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-27T14:56:58Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-27T15:55:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-27T16:38:15Z,chloekek,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-27T17:00:16Z,Dispersia,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-27T17:00:17Z,Dispersia,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T17:00:17Z,Dispersia,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-27T17:00:18Z,Dispersia,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-27T17:00:19Z,Dispersia,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-27T19:35:14Z,edef1c,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-27T19:47:28Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-27T23:50:50Z,clavin,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-28T03:03:52Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-28T03:03:53Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-09-28T03:03:54Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-09-28T03:03:55Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-28T03:03:57Z,matthewjberger,matthewberger@nevada.unr.edu https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-28T05:01:17Z,SmiteWindows,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-09-28T07:07:41Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-28T07:07:42Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-28T22:54:48Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-09-28T23:54:25Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-09-28T23:54:29Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-02T18:07:28Z,snawaz,sir_nawaz959@yahoo.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-02T18:53:45Z,zengsai,zengsai@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-02T19:05:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-02T19:08:34Z,twissel,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-02T19:14:41Z,95th,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-02T19:14:44Z,95th,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-02T19:14:46Z,95th,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-02T19:48:56Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-02T19:48:57Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-02T19:48:57Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-02T19:48:58Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-02T19:49:02Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-02T21:15:16Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-02T21:18:51Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-02T21:18:53Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T01:18:22Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-03T06:18:46Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-03T06:18:51Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-03T06:18:53Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-03T06:18:56Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T06:18:57Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T09:14:39Z,Karrq,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-03T09:14:41Z,Karrq,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-03T09:14:47Z,Karrq,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T10:09:27Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T11:16:48Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T11:42:54Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-03T11:42:57Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-03T12:38:46Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T13:08:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-03T13:32:00Z,spoof,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-03T13:32:02Z,spoof,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-03T20:13:32Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-04T01:14:05Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-04T03:19:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-04T03:19:19Z,RalfJung,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-04T06:29:43Z,agnxy,andrewxuyuan@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-04T08:24:27Z,alygin,alygin@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-07T02:17:42Z,xen0n,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-07T02:17:44Z,xen0n,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-07T13:40:11Z,Mijyuoon,mijyuoon@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-07T13:40:13Z,Mijyuoon,mijyuoon@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-07T13:40:14Z,Mijyuoon,mijyuoon@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-08T09:19:18Z,sekineh,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-10T18:58:11Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-10T19:07:52Z,lily-commure,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-10T19:07:53Z,lily-commure,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-10T19:07:56Z,lily-commure,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-10T19:07:58Z,lily-commure,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-10T19:07:59Z,lily-commure,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-10T19:16:49Z,zrsmith92,zrsmith92@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-10T19:16:51Z,zrsmith92,zrsmith92@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-14T04:38:26Z,boybird,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-20T08:11:45Z,lnicola,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-20T11:34:28Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-20T11:34:29Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-20T11:34:35Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-20T13:20:51Z,foobar1643,foobar76239@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-10-20T13:20:52Z,foobar1643,foobar76239@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-23T21:36:54Z,0xpr03,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-24T07:56:08Z,elichai,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-24T11:51:57Z,wayslog,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-24T12:12:51Z,keliwang,root@keli.im https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-10-24T12:38:00Z,g-plane,g-plane@hotmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-24T12:44:44Z,fishky,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-10-24T12:44:57Z,fishky,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-10-24T15:41:35Z,hoptercat,hoptercat@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-10-25T05:07:21Z,Aloxaf,bailong104@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-11-03T13:17:55Z,isomorpheme,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-11-03T13:17:59Z,isomorpheme,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-11-04T02:30:03Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-11-04T02:30:07Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-11-04T02:30:08Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-11-07T09:48:59Z,Flowneee,Flowneee3@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-11-07T14:54:40Z,yfaming,yfaming@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-11-07T15:44:29Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-11-07T17:08:55Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-11-07T20:16:38Z,kjaleshire,kjaleshire@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-11-08T01:27:10Z,sonald,yinshuiboy@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-11-08T19:20:27Z,calebmeyer,Kiaulen@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-11-09T09:12:21Z,andywwright,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-11-10T00:49:45Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-11-12T12:18:25Z,xdk78,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-11-26T22:49:04Z,tmandry,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-12-02T06:18:33Z,lynnux,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-12-19T16:39:54Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-19T16:39:55Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-12-19T16:39:57Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-12-19T16:39:58Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-12-19T16:39:59Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-19T16:53:10Z,kennytm,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-12-19T18:22:19Z,jcdyer,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-19T18:33:24Z,antonok-edm,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-20T00:32:44Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-12-20T04:36:12Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-12-20T04:36:27Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-12-20T04:36:28Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-12-20T04:36:29Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-12-20T17:33:47Z,prostomarkeloff,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-12-21T11:54:52Z,luc-tielen,Luc.Tielen@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2019-12-21T18:39:31Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-21T18:39:32Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2019-12-21T18:39:35Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2019-12-21T18:39:39Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-22T07:18:44Z,raindev,andrew@raindev.io https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-12-24T04:49:37Z,ryym,ryym.64@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2019-12-28T01:36:18Z,arzg,aramisnoah@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2019-12-29T20:58:34Z,jharrilim,Josephharrisonlim@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2020-01-16T23:04:11Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2020-01-16T23:04:12Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2020-03-08T21:16:24Z,DzmitryFil,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2020-03-13T05:05:03Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2020-03-13T07:57:42Z,balta2ar,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2020-03-13T07:57:43Z,balta2ar,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2020-03-13T07:57:44Z,balta2ar,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2020-03-13T07:57:45Z,balta2ar,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2020-08-08T21:33:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2020-08-20T22:06:58Z,marccane,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2020-10-17T16:21:18Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2020-10-17T16:21:19Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,ROCKET,2020-10-17T16:21:21Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HEART,2020-10-17T16:21:22Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2021-07-29T21:37:30Z,tema3210,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2021-07-29T21:37:32Z,tema3210,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2021-07-29T21:37:35Z,tema3210,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2021-07-30T01:45:25Z,ellie-fisher,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,HOORAY,2021-07-30T01:45:25Z,ellie-fisher,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2021-08-06T12:04:29Z,HKalbasi,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2021-09-09T04:39:44Z,kawaemon,me@kawaemon.dev https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2021-09-09T04:39:45Z,kawaemon,me@kawaemon.dev https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,THUMBS_UP,2022-04-28T19:41:40Z,lukechu10,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2022-04-28T19:41:41Z,lukechu10,NA https://github.com/rust-lang/rust/pull/64790,MERGED,2019-09-25T23:35:14Z,2019-09-28T01:18:16Z,Rest In Peace AST borrowck (2012-2019),Centril,001357f97197797bec534cc5ec5ae6fabcc01e21,1,#NAME?,LAUGH,2022-06-10T21:39:06Z,Agrailag,NA https://github.com/rust-lang/rust/pull/64799,MERGED,2019-09-26T02:37:00Z,2019-09-29T09:53:05Z,Fix double panic when printing query stack during an ICE,Aaron1011,97906bcd5c9c5ba5d165c7330b2ee062a97f11cf,1,Add note about global state in try_print_query_stack,THUMBS_UP,2019-09-26T05:10:34Z,PlasmaPower,ljbousfield@gmail.com https://github.com/rust-lang/rust/pull/64799,MERGED,2019-09-26T02:37:00Z,2019-09-29T09:53:05Z,Fix double panic when printing query stack during an ICE,Aaron1011,97906bcd5c9c5ba5d165c7330b2ee062a97f11cf,1,Add note about global state in try_print_query_stack,THUMBS_UP,2019-10-03T13:27:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64817,MERGED,2019-09-26T16:33:25Z,2019-10-04T11:20:33Z,Replace ClosureSubsts with SubstsRef,csmoe,9b91bef78b15dfecc5144b0575f40a2d84ea795a,45,generate ClosureSubsts from SubstsRef,HEART,2019-09-28T02:37:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-26T22:17:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-26T22:18:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-26T22:27:09Z,est31,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-26T23:37:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T04:10:03Z,ljedrz,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T07:57:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T07:58:54Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T08:07:40Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-09-27T08:09:13Z,jplatte,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T09:10:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-27T13:19:25Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-09-28T07:38:32Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-03T18:05:24Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-03T18:06:00Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-04T02:18:12Z,sinkuu,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-04T04:53:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-04T10:56:27Z,kyrias,johannes@kyriasis.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-04T10:56:29Z,kyrias,johannes@kyriasis.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-04T10:56:31Z,kyrias,johannes@kyriasis.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-06T11:38:51Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-06T13:37:56Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-09T16:41:17Z,ehuss,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-09T16:41:19Z,ehuss,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-09T16:41:19Z,ehuss,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-09T21:49:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-10T17:37:12Z,mzji,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-10T20:33:43Z,stefson,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-11T00:44:09Z,tmandry,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-11T06:08:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-11T11:26:40Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T08:49:07Z,frol,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-12T08:49:08Z,frol,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T09:22:03Z,Byron,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-12T09:22:09Z,Byron,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T09:41:39Z,DianaNites,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T09:53:31Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-12T10:22:38Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T10:36:00Z,jessynt,alan.siu@linux.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T10:47:09Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-12T11:04:58Z,marcogroppo,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T11:13:21Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T11:14:19Z,recmo,remco@wicked.ventures https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T11:15:06Z,95th,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-12T11:15:08Z,95th,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HEART,2019-10-12T11:15:10Z,95th,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T11:30:25Z,Jake-Shadle,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T11:35:40Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T16:44:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-12T19:26:43Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T20:30:59Z,yerke,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T20:39:48Z,la10736,michele.damico@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-12T22:08:25Z,binarybana,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-13T07:06:39Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-13T12:52:37Z,Angr1st,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-13T12:56:46Z,clavin,NA https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,THUMBS_UP,2019-10-13T21:36:24Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2019-10-17T18:47:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64823,MERGED,2019-09-26T21:57:20Z,2019-10-11T03:21:45Z,minimize the rust-std component,cuviper,d3052540993b6acf009d39949b79077a49544934,1,Add rustc-dev to nightly default and complete profiles,HOORAY,2020-01-10T13:48:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/64824,MERGED,2019-09-26T23:02:43Z,2019-09-29T09:53:03Z,No StableHasherResult everywhere,Mark-Simulacrum,14a5aefb01bb4f18749ab56cd9fd37bf93c86a37,36,Switch over all StableHash impls to new format,HEART,2019-09-28T02:31:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/64825,MERGED,2019-09-27T00:19:17Z,2019-09-29T22:21:48Z,Point at enclosing match when expecting `()` in arm,estebank,c861e24e7251fcbf0cbb8b85c676afe6b901f8af,3,clean up,ROCKET,2019-10-03T13:30:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64828,MERGED,2019-09-27T02:01:52Z,2019-10-01T06:16:57Z,Graphviz debug output for generic dataflow analysis,ecstatic-morse,2b8e023b9d28f2f912ad21427b5266b62c007f11,1,Stop printing `Qualif` results in debug logs Now we can use the dataflow graphviz debugging.,HOORAY,2019-09-27T03:04:40Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/64828,MERGED,2019-09-27T02:01:52Z,2019-10-01T06:16:57Z,Graphviz debug output for generic dataflow analysis,ecstatic-morse,2b8e023b9d28f2f912ad21427b5266b62c007f11,1,Stop printing `Qualif` results in debug logs Now we can use the dataflow graphviz debugging.,HOORAY,2019-09-27T09:49:37Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/64828,MERGED,2019-09-27T02:01:52Z,2019-10-01T06:16:57Z,Graphviz debug output for generic dataflow analysis,ecstatic-morse,2b8e023b9d28f2f912ad21427b5266b62c007f11,1,Stop printing `Qualif` results in debug logs Now we can use the dataflow graphviz debugging.,HOORAY,2019-09-27T12:14:54Z,lqd,NA https://github.com/rust-lang/rust/pull/64828,MERGED,2019-09-27T02:01:52Z,2019-10-01T06:16:57Z,Graphviz debug output for generic dataflow analysis,ecstatic-morse,2b8e023b9d28f2f912ad21427b5266b62c007f11,1,Stop printing `Qualif` results in debug logs Now we can use the dataflow graphviz debugging.,HOORAY,2019-09-30T19:02:57Z,tmandry,NA https://github.com/rust-lang/rust/pull/64830,MERGED,2019-09-27T04:10:51Z,2019-09-28T07:27:51Z,Thou shallt not `.abort_if_errors()`,Centril,9ef6edb04ad059242551f134077dab88a36bdd61,3,lowering: don't .abort_if_errors(),HEART,2019-09-27T07:30:12Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64842,MERGED,2019-09-27T13:27:11Z,2019-10-04T03:35:45Z,Disallow Self in type param defaults of ADTs,pnkfelix,e443e1bdf9f474f822008f88862fed630b50381f,4,Regression tests. Update: incorporate review feedback.,THUMBS_UP,2019-10-04T00:44:28Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/64851,MERGED,2019-09-27T17:30:39Z,2019-09-28T07:27:47Z,Add mailmap entry for Dustin Bensing by request,Mark-Simulacrum,d559b725d3ac28b90607c0823fc5639d69053e10,1,Add mailmap entry for Dustin Bensing by request,HEART,2019-09-27T18:30:37Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/64852,MERGED,2019-09-27T18:06:07Z,2019-09-29T02:33:20Z,Print ParamTy span when accessing a field (#52082),Baranowski,9ad99c30cbf344b763602698b67c04ec3ce3de56,1,Refactor into ban_nonexisting_field method,HEART,2019-09-27T18:57:08Z,estebank,NA https://github.com/rust-lang/rust/pull/64852,MERGED,2019-09-27T18:06:07Z,2019-09-29T02:33:20Z,Print ParamTy span when accessing a field (#52082),Baranowski,9ad99c30cbf344b763602698b67c04ec3ce3de56,1,Refactor into ban_nonexisting_field method,HEART,2019-09-27T18:57:50Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2019-09-28T16:31:17Z,estebank,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2019-09-29T23:19:08Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2019-10-05T15:37:04Z,chmln,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-10-05T15:37:07Z,chmln,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-10-05T22:48:23Z,CrackedP0t,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-11-06T00:54:02Z,Hexilee,i@hexilee.me https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-11-20T22:48:37Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2019-11-20T22:48:40Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2019-11-21T00:22:16Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-11-21T00:22:23Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-11-21T01:43:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-12-29T11:06:29Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-12-30T07:29:49Z,netvl,vmatveev@citrine.cc https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-12-31T07:22:39Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2019-12-31T22:38:10Z,jeff-hiner,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2020-01-15T19:47:28Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2020-08-16T05:57:17Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,HOORAY,2020-08-16T05:57:19Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/64856,MERGED,2019-09-27T21:17:39Z,2019-11-24T05:34:56Z,Scope format! temporaries,jonhoo,31fc42b7f778accb21db8daaf0f0e725948c9d6d,2683,Merge branch 'master' into format-temporaries,THUMBS_UP,2020-09-04T07:55:40Z,twitchax,twitchax@gmail.com https://github.com/rust-lang/rust/pull/64858,MERGED,2019-09-27T22:56:55Z,2019-09-29T22:21:46Z,Add support for relating slices in `super_relate_consts`,skinny121,54bad930304a1f7009296e6cfc2f90a008189b1d,3,Add a couple more test cases including non-ascii strings.,HOORAY,2020-02-29T07:46:52Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/64858,MERGED,2019-09-27T22:56:55Z,2019-09-29T22:21:46Z,Add support for relating slices in `super_relate_consts`,skinny121,54bad930304a1f7009296e6cfc2f90a008189b1d,3,Add a couple more test cases including non-ascii strings.,HOORAY,2021-04-25T07:17:57Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/64859,MERGED,2019-09-28T00:36:12Z,2019-09-28T07:27:46Z,check_match: improve diagnostics for `let A = 2;` with `const A: i32 = 3`,Centril,aa03f1f5e3791f1ff07d414ba003f395ad6538d8,7,Improve diagnostic for `let A = 0;` where `A` is a constant not a new variable.,HOORAY,2019-09-28T00:50:20Z,Lokathor,NA https://github.com/rust-lang/rust/pull/64859,MERGED,2019-09-28T00:36:12Z,2019-09-28T07:27:46Z,check_match: improve diagnostics for `let A = 2;` with `const A: i32 = 3`,Centril,aa03f1f5e3791f1ff07d414ba003f395ad6538d8,7,Improve diagnostic for `let A = 0;` where `A` is a constant not a new variable.,HOORAY,2019-09-28T08:09:20Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/64859,MERGED,2019-09-28T00:36:12Z,2019-09-28T07:27:46Z,check_match: improve diagnostics for `let A = 2;` with `const A: i32 = 3`,Centril,aa03f1f5e3791f1ff07d414ba003f395ad6538d8,7,Improve diagnostic for `let A = 0;` where `A` is a constant not a new variable.,HOORAY,2019-10-03T13:54:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64861,CLOSED,2019-09-28T01:41:35Z,2019-10-29T22:33:39Z,Change to non-line buffered output if output is not a TTY,tbu-,NA,NA,NA,HOORAY,2019-10-15T17:27:11Z,bluss,NA https://github.com/rust-lang/rust/pull/64873,MERGED,2019-09-28T14:50:22Z,2019-10-13T03:37:44Z,Enhance report-time option,popzxc,15f571bbd3ce370d925d21f1ab281aee993e4860,1,Move unstable book entry into compiler flags directory,THUMBS_UP,2019-09-30T08:41:49Z,aleksuss,oleksandr.anyshchenko@xdev.re https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-09-28T18:38:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HEART,2019-09-28T18:38:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,THUMBS_UP,2019-09-28T18:38:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,THUMBS_UP,2019-09-28T21:40:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HEART,2019-09-28T21:40:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-09-28T21:40:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-09-29T00:20:04Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-10-03T15:21:52Z,lqd,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,THUMBS_UP,2019-10-03T15:21:54Z,lqd,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-10-03T22:54:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HOORAY,2019-10-04T06:32:38Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64874,MERGED,2019-09-28T15:22:51Z,2019-10-04T11:20:31Z,Simplify ExprUseVisitor,matthewjasper,b4ad612697b7dccbf83562010fcfaa36023324cd,2,Remove unused parts of ExprUseVisitor,HEART,2019-10-04T06:32:38Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/64885,MERGED,2019-09-28T22:11:13Z,2019-10-02T10:01:01Z,use try_fold instead of try_for_each to reduce compile time,andjo403,8737061cb59f2563153bdca3d121f40584597426,1,replace try_for_each with try_fold to generate less code removes two functions to inline by combining the check functions and extra call to try_for_each,THUMBS_UP,2019-10-02T04:33:49Z,bluss,NA https://github.com/rust-lang/rust/pull/64885,MERGED,2019-09-28T22:11:13Z,2019-10-02T10:01:01Z,use try_fold instead of try_for_each to reduce compile time,andjo403,8737061cb59f2563153bdca3d121f40584597426,1,replace try_for_each with try_fold to generate less code removes two functions to inline by combining the check functions and extra call to try_for_each,THUMBS_UP,2019-10-11T05:30:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64894,MERGED,2019-09-29T10:56:54Z,2019-09-29T22:21:42Z,syntax: fix dropping of attribute on first param of non-method assocated fn,Centril,8fd03b1e47147794ff955a13a474cd52a5f78359,15,syntax: fix #64682. Fuse parsing of `self` into `parse_param_general`.,THUMBS_UP,2019-09-29T13:05:28Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/64894,MERGED,2019-09-29T10:56:54Z,2019-09-29T22:21:42Z,syntax: fix dropping of attribute on first param of non-method assocated fn,Centril,8fd03b1e47147794ff955a13a474cd52a5f78359,15,syntax: fix #64682. Fuse parsing of `self` into `parse_param_general`.,THUMBS_UP,2019-09-30T11:38:38Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,THUMBS_UP,2019-09-29T17:08:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,THUMBS_UP,2019-09-30T13:45:57Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-09-30T21:41:50Z,tmandry,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,THUMBS_UP,2019-10-01T06:07:16Z,95th,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-01T06:07:18Z,95th,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,THUMBS_UP,2019-10-02T05:50:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-02T05:50:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-04T05:28:28Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-04T20:48:17Z,estebank,NA https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-10T08:45:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2019-10-11T05:27:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64895,MERGED,2019-09-29T13:40:40Z,2019-10-01T11:50:52Z,async/await: improve not-send errors,davidtwco,04fa9b1b3f947fa66bb3e92702e134c72af9486f,9,async/await: improve obligation errors This commit improves obligation errors for async/await: ``` note: future does not implement `std::marker::Send` because this value is used across an await --> $DIR/issue-64130-non-send-future-diags.rs:15:5 | LL | let g = x.lock().unwrap(); | - has type `std::sync::MutexGuard<'_ u32>` LL | baz().await; | ^^^^^^^^^^^ await occurs here with `g` maybe used later LL | } | - `g` is later dropped here ``` Signed-off-by: David Wood ,HEART,2020-01-15T05:05:56Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/64896,MERGED,2019-09-29T14:15:36Z,2019-10-01T11:50:51Z,Remove legacy grammar,XAMPPRocky,96c8049b201fa0b87b8074e139921fbc33a2db1d,8,Remove legacy grammar,HEART,2019-09-29T15:16:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/64896,MERGED,2019-09-29T14:15:36Z,2019-10-01T11:50:51Z,Remove legacy grammar,XAMPPRocky,96c8049b201fa0b87b8074e139921fbc33a2db1d,8,Remove legacy grammar,THUMBS_UP,2019-09-29T23:04:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/64896,MERGED,2019-09-29T14:15:36Z,2019-10-01T11:50:51Z,Remove legacy grammar,XAMPPRocky,96c8049b201fa0b87b8074e139921fbc33a2db1d,8,Remove legacy grammar,HEART,2019-09-30T07:17:25Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/64909,MERGED,2019-09-30T02:08:28Z,2019-10-06T08:40:34Z,When encountering chained operators use heuristics to recover from bad turbofish,estebank,76456e74066d7594f23757ebade169c33276ea4d,2,review comments,HEART,2019-09-30T02:45:49Z,tesuji,NA https://github.com/rust-lang/rust/pull/64912,MERGED,2019-09-30T05:46:23Z,2019-10-02T02:01:25Z,Remove unneeded `fn main` blocks from docs,tesuji,6c1b447f2e67f5eae89394344ade698aca3ec7e6,18,Remove unneeded `fn main` blocks from docs,LAUGH,2019-09-30T13:43:06Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/64912,MERGED,2019-09-30T05:46:23Z,2019-10-02T02:01:25Z,Remove unneeded `fn main` blocks from docs,tesuji,6c1b447f2e67f5eae89394344ade698aca3ec7e6,18,Remove unneeded `fn main` blocks from docs,THUMBS_UP,2019-09-30T13:43:08Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/64922,MERGED,2019-09-30T16:11:54Z,2019-10-02T22:35:32Z,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,spastorino,79dc862d4a8c0690fbc50d7ebd129fab2e199a49,1,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,HEART,2019-09-30T19:27:52Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/64922,MERGED,2019-09-30T16:11:54Z,2019-10-02T22:35:32Z,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,spastorino,79dc862d4a8c0690fbc50d7ebd129fab2e199a49,1,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,HEART,2019-10-10T08:50:10Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/64922,MERGED,2019-09-30T16:11:54Z,2019-10-02T22:35:32Z,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,spastorino,79dc862d4a8c0690fbc50d7ebd129fab2e199a49,1,Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions,HEART,2019-10-11T05:30:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64925,MERGED,2019-09-30T18:00:55Z,2019-10-18T14:02:40Z,Document JSON message output.,ehuss,f04ea6c7e1cdac012b31efcd97973f426571a97a,3,Document JSON message output.,HEART,2019-10-18T21:25:02Z,killercup,NA https://github.com/rust-lang/rust/pull/64933,MERGED,2019-09-30T21:51:38Z,2019-10-02T02:01:23Z,Fixes #64919. Suggest fix based on operator precendence.,sam09,9e4eb46790435c38a613d7f9d5d3e0eb5f77fca1,6,Change to use exprPrecedence instead of exprKind.,THUMBS_UP,2019-09-30T23:47:19Z,estebank,NA https://github.com/rust-lang/rust/pull/64933,MERGED,2019-09-30T21:51:38Z,2019-10-02T02:01:23Z,Fixes #64919. Suggest fix based on operator precendence.,sam09,9e4eb46790435c38a613d7f9d5d3e0eb5f77fca1,6,Change to use exprPrecedence instead of exprKind.,THUMBS_UP,2019-10-01T15:34:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/64933,MERGED,2019-09-30T21:51:38Z,2019-10-02T02:01:23Z,Fixes #64919. Suggest fix based on operator precendence.,sam09,9e4eb46790435c38a613d7f9d5d3e0eb5f77fca1,6,Change to use exprPrecedence instead of exprKind.,HEART,2019-10-01T15:39:33Z,varkor,NA https://github.com/rust-lang/rust/pull/64935,MERGED,2019-09-30T22:28:43Z,2019-10-01T11:50:47Z,Improve code clarity,AnthonyMikh,50c2a58d086ec9124a6749eb75afc35c0bc1652f,1,Fix borrowck errors Reborrowing doesn't work for loops,HEART,2019-09-30T22:41:35Z,kpp,NA https://github.com/rust-lang/rust/pull/64935,MERGED,2019-09-30T22:28:43Z,2019-10-01T11:50:47Z,Improve code clarity,AnthonyMikh,50c2a58d086ec9124a6749eb75afc35c0bc1652f,1,Fix borrowck errors Reborrowing doesn't work for loops,HEART,2019-09-30T22:49:14Z,estebank,NA https://github.com/rust-lang/rust/pull/64935,MERGED,2019-09-30T22:28:43Z,2019-10-01T11:50:47Z,Improve code clarity,AnthonyMikh,50c2a58d086ec9124a6749eb75afc35c0bc1652f,1,Fix borrowck errors Reborrowing doesn't work for loops,HEART,2019-10-01T00:07:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/64935,MERGED,2019-09-30T22:28:43Z,2019-10-01T11:50:47Z,Improve code clarity,AnthonyMikh,50c2a58d086ec9124a6749eb75afc35c0bc1652f,1,Fix borrowck errors Reborrowing doesn't work for loops,HEART,2019-10-01T02:49:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/64941,MERGED,2019-10-01T04:02:20Z,2019-10-03T09:58:06Z,Inline `{min max}_value` even in debug builds,tesuji,3b49ab6e4816fd79cf77d0813ceb17d5696d577c,1,Inline `{min max}_value` even in debug builds,CONFUSED,2019-10-01T10:13:07Z,mati865,NA https://github.com/rust-lang/rust/pull/64941,MERGED,2019-10-01T04:02:20Z,2019-10-03T09:58:06Z,Inline `{min max}_value` even in debug builds,tesuji,3b49ab6e4816fd79cf77d0813ceb17d5696d577c,1,Inline `{min max}_value` even in debug builds,CONFUSED,2019-10-10T03:27:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/64959,MERGED,2019-10-01T14:40:20Z,2019-10-03T06:02:22Z,syntax: improve parameter without type suggestions,davidtwco,2537a8aa7a44d76b3345b98f394f6d2744f3a9cc,8,syntax: improve parameter without type suggestions This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only ` ` and `)` or trait items) this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap)` -> `fn foo(HashMap: TypeName)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood ,HEART,2019-10-01T15:18:14Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/64959,MERGED,2019-10-01T14:40:20Z,2019-10-03T06:02:22Z,syntax: improve parameter without type suggestions,davidtwco,2537a8aa7a44d76b3345b98f394f6d2744f3a9cc,8,syntax: improve parameter without type suggestions This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only ` ` and `)` or trait items) this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap)` -> `fn foo(HashMap: TypeName)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood ,HEART,2019-10-01T15:20:06Z,estebank,NA https://github.com/rust-lang/rust/pull/64959,MERGED,2019-10-01T14:40:20Z,2019-10-03T06:02:22Z,syntax: improve parameter without type suggestions,davidtwco,2537a8aa7a44d76b3345b98f394f6d2744f3a9cc,8,syntax: improve parameter without type suggestions This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only ` ` and `)` or trait items) this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap)` -> `fn foo(HashMap: TypeName)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood ,HEART,2019-10-01T15:38:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/64959,MERGED,2019-10-01T14:40:20Z,2019-10-03T06:02:22Z,syntax: improve parameter without type suggestions,davidtwco,2537a8aa7a44d76b3345b98f394f6d2744f3a9cc,8,syntax: improve parameter without type suggestions This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only ` ` and `)` or trait items) this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap)` -> `fn foo(HashMap: TypeName)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood ,HEART,2019-10-11T05:37:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64977,CLOSED,2019-10-01T23:57:24Z,2019-11-21T06:27:32Z,Stop failing on toolstate changes,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-10-01T23:59:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64977,CLOSED,2019-10-01T23:57:24Z,2019-11-21T06:27:32Z,Stop failing on toolstate changes,Mark-Simulacrum,NA,NA,NA,CONFUSED,2019-10-02T06:35:56Z,kennytm,NA https://github.com/rust-lang/rust/pull/64977,CLOSED,2019-10-01T23:57:24Z,2019-11-21T06:27:32Z,Stop failing on toolstate changes,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2019-10-02T07:32:52Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/64977,CLOSED,2019-10-01T23:57:24Z,2019-11-21T06:27:32Z,Stop failing on toolstate changes,Mark-Simulacrum,NA,NA,NA,HOORAY,2019-10-02T12:03:23Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/64977,CLOSED,2019-10-01T23:57:24Z,2019-11-21T06:27:32Z,Stop failing on toolstate changes,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2019-10-02T22:09:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/64986,MERGED,2019-10-02T07:52:34Z,2019-10-12T10:06:00Z,Function pointers as const generic arguments,skinny121,8569dd1db985509cd235fafdd962aa52ced68e35,1,Preserve output of raw pointers in mir dump.,HEART,2019-10-02T11:26:48Z,varkor,NA https://github.com/rust-lang/rust/pull/64986,MERGED,2019-10-02T07:52:34Z,2019-10-12T10:06:00Z,Function pointers as const generic arguments,skinny121,8569dd1db985509cd235fafdd962aa52ced68e35,1,Preserve output of raw pointers in mir dump.,HEART,2019-10-02T17:57:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/64986,MERGED,2019-10-02T07:52:34Z,2019-10-12T10:06:00Z,Function pointers as const generic arguments,skinny121,8569dd1db985509cd235fafdd962aa52ced68e35,1,Preserve output of raw pointers in mir dump.,HEART,2019-10-19T21:17:39Z,Mr-Byte,NA https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,THUMBS_UP,2019-10-02T09:53:35Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,HEART,2019-10-02T09:53:37Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,HEART,2019-10-02T21:17:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,HEART,2019-10-03T00:19:46Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,THUMBS_UP,2019-10-03T00:19:48Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,THUMBS_UP,2019-10-03T04:05:18Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64989,MERGED,2019-10-02T09:30:42Z,2019-10-02T22:35:26Z,Fix ICE #64964,sinkuu,f0fddb1a89eda1c5588725e23a50b3073f4e7e97,2,Do not collect to vec for debug output,HEART,2019-10-03T04:05:19Z,taiki-e,NA https://github.com/rust-lang/rust/pull/64993,MERGED,2019-10-02T12:20:40Z,2019-10-03T06:02:20Z,BacktraceStatus: add Eq impl,mathstuf,fb80e6c62ea5ae3a19b1b4076f636ced3e3b70d8,1,BacktraceStatus: add Eq impl See discussion on #53487.,THUMBS_UP,2019-10-03T01:46:01Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-10-02T19:17:19Z,cramertj,NA https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,HEART,2019-10-02T19:17:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-10-03T03:57:00Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,HEART,2019-10-03T03:57:02Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-10-03T10:16:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,HEART,2019-10-03T10:17:02Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-10-04T20:40:52Z,macpp,NA https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,HEART,2019-10-07T03:59:22Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-10-11T05:40:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/64999,MERGED,2019-10-02T14:05:06Z,2019-10-03T16:14:36Z,extract expected return type for async fn generators,nikomatsakis,a807032f9e4e4b43db17a1f17be766bb02d23a57,6,./x.py test --bless --compare-mode=nll,THUMBS_UP,2019-11-12T13:38:03Z,yfaming,yfaming@gmail.com https://github.com/rust-lang/rust/pull/65013,MERGED,2019-10-02T17:48:41Z,2019-11-28T06:59:34Z,Implement Debug for MaybeUninit,petertodd,8fad66b43151c5c1bbb7933e54051ae8c11fe595,1,Implement Debug for MaybeUninit Precedent: UnsafeCell implements Debug even though it can't actually display the value.,THUMBS_UP,2019-12-05T13:45:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65013,MERGED,2019-10-02T17:48:41Z,2019-11-28T06:59:34Z,Implement Debug for MaybeUninit,petertodd,8fad66b43151c5c1bbb7933e54051ae8c11fe595,1,Implement Debug for MaybeUninit Precedent: UnsafeCell implements Debug even though it can't actually display the value.,THUMBS_UP,2019-12-23T20:19:03Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65016,MERGED,2019-10-02T18:41:29Z,2019-10-19T04:54:54Z,Always inline `mem::{size_of align_of}` in debug builds,tesuji,a87b44dbea5335c9b5d563b44e0e5f8b074ac9db,1,Always inline `mem::{size_of align_of}` in debug builds Those two are const fn and do not have any arguments. Inlining helps reducing generated code size in debug builds.,THUMBS_UP,2019-10-24T04:03:32Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65016,MERGED,2019-10-02T18:41:29Z,2019-10-19T04:54:54Z,Always inline `mem::{size_of align_of}` in debug builds,tesuji,a87b44dbea5335c9b5d563b44e0e5f8b074ac9db,1,Always inline `mem::{size_of align_of}` in debug builds Those two are const fn and do not have any arguments. Inlining helps reducing generated code size in debug builds.,ROCKET,2019-10-24T08:18:09Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65016,MERGED,2019-10-02T18:41:29Z,2019-10-19T04:54:54Z,Always inline `mem::{size_of align_of}` in debug builds,tesuji,a87b44dbea5335c9b5d563b44e0e5f8b074ac9db,1,Always inline `mem::{size_of align_of}` in debug builds Those two are const fn and do not have any arguments. Inlining helps reducing generated code size in debug builds.,HOORAY,2019-10-24T08:18:12Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65016,MERGED,2019-10-02T18:41:29Z,2019-10-19T04:54:54Z,Always inline `mem::{size_of align_of}` in debug builds,tesuji,a87b44dbea5335c9b5d563b44e0e5f8b074ac9db,1,Always inline `mem::{size_of align_of}` in debug builds Those two are const fn and do not have any arguments. Inlining helps reducing generated code size in debug builds.,HOORAY,2019-10-26T07:50:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65037,MERGED,2019-10-03T01:59:40Z,2019-10-09T07:10:58Z,`#[track_caller]` feature gate (RFC 2091 1/N),anp,cca58d1321b6de3098884d4af7bbff57f0f65101,1,Fix syntax typo in error message.,HOORAY,2019-10-03T08:03:39Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65037,MERGED,2019-10-03T01:59:40Z,2019-10-09T07:10:58Z,`#[track_caller]` feature gate (RFC 2091 1/N),anp,cca58d1321b6de3098884d4af7bbff57f0f65101,1,Fix syntax typo in error message.,HOORAY,2019-10-03T16:08:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65037,MERGED,2019-10-03T01:59:40Z,2019-10-09T07:10:58Z,`#[track_caller]` feature gate (RFC 2091 1/N),anp,cca58d1321b6de3098884d4af7bbff57f0f65101,1,Fix syntax typo in error message.,HOORAY,2019-10-04T04:54:35Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65037,MERGED,2019-10-03T01:59:40Z,2019-10-09T07:10:58Z,`#[track_caller]` feature gate (RFC 2091 1/N),anp,cca58d1321b6de3098884d4af7bbff57f0f65101,1,Fix syntax typo in error message.,HOORAY,2020-06-17T07:10:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/65066,MERGED,2019-10-03T17:47:58Z,2019-10-06T08:40:27Z,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,wesleywiser,e9009c86d2ed877e21011478f1083e3950507428,4,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,HOORAY,2019-10-03T18:58:17Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/65066,MERGED,2019-10-03T17:47:58Z,2019-10-06T08:40:27Z,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,wesleywiser,e9009c86d2ed877e21011478f1083e3950507428,4,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,HOORAY,2019-10-03T20:52:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65066,MERGED,2019-10-03T17:47:58Z,2019-10-06T08:40:27Z,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,wesleywiser,e9009c86d2ed877e21011478f1083e3950507428,4,[const-prop] Fix ICE when trying to eval polymorphic promoted MIR,HOORAY,2019-10-11T05:27:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65068,MERGED,2019-10-03T18:47:23Z,2019-10-30T05:33:11Z,Custom lifetime error for `impl` item doesn't conform to `trait`,estebank,213fd1f37f272e352ceb7dcdaddcd90b1da54d61,2,Silence crate external span error in x86 platforms This causes issues in at least `dist-i586-gnu-i586-i686-musl` possibly others.,HEART,2019-10-30T01:09:58Z,tmandry,NA https://github.com/rust-lang/rust/pull/65068,MERGED,2019-10-03T18:47:23Z,2019-10-30T05:33:11Z,Custom lifetime error for `impl` item doesn't conform to `trait`,estebank,213fd1f37f272e352ceb7dcdaddcd90b1da54d61,2,Silence crate external span error in x86 platforms This causes issues in at least `dist-i586-gnu-i586-i686-musl` possibly others.,HEART,2019-11-06T18:18:50Z,jplatte,NA https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2019-10-04T03:24:47Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2019-10-04T13:09:33Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2019-10-16T18:30:13Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2019-10-26T03:44:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2019-11-04T09:23:18Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/65083,CLOSED,2019-10-04T03:18:08Z,2020-05-18T03:04:38Z,WIP: stability annotations on generic parameters,Avi-D-coder,NA,NA,NA,HEART,2020-03-02T19:18:33Z,dkaste,darrenkaste@gmail.com https://github.com/rust-lang/rust/pull/65089,MERGED,2019-10-04T07:13:55Z,2019-10-06T16:32:52Z,Optimize integral pattern matching,nnethercote,2a3a5447418cc8e7a8b36ae4c9bdf8798a20b873,1,Replace `flat_map()` with `filter_map()` in `is_useful_specialized()`. `filter_map()` is less general but more efficient and has the same effect in this case. This commit reduces the instruction count for `unicode_normalization-check-clean` by about 2%.,THUMBS_UP,2019-10-04T10:34:45Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/65089,MERGED,2019-10-04T07:13:55Z,2019-10-06T16:32:52Z,Optimize integral pattern matching,nnethercote,2a3a5447418cc8e7a8b36ae4c9bdf8798a20b873,1,Replace `flat_map()` with `filter_map()` in `is_useful_specialized()`. `filter_map()` is less general but more efficient and has the same effect in this case. This commit reduces the instruction count for `unicode_normalization-check-clean` by about 2%.,THUMBS_UP,2019-10-05T00:26:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/65089,MERGED,2019-10-04T07:13:55Z,2019-10-06T16:32:52Z,Optimize integral pattern matching,nnethercote,2a3a5447418cc8e7a8b36ae4c9bdf8798a20b873,1,Replace `flat_map()` with `filter_map()` in `is_useful_specialized()`. `filter_map()` is less general but more efficient and has the same effect in this case. This commit reduces the instruction count for `unicode_normalization-check-clean` by about 2%.,THUMBS_UP,2019-10-11T05:39:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65091,MERGED,2019-10-04T08:52:19Z,2019-10-31T18:43:57Z,Implement ordered/sorted iterators on BinaryHeap as per #59278,sekineh,95442ae251d24c062ca317dcafdf3240f3cec846,1,fix doctest,HEART,2019-11-06T19:21:00Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65091,MERGED,2019-10-04T08:52:19Z,2019-10-31T18:43:57Z,Implement ordered/sorted iterators on BinaryHeap as per #59278,sekineh,95442ae251d24c062ca317dcafdf3240f3cec846,1,fix doctest,HEART,2019-11-11T22:05:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65092,MERGED,2019-10-04T09:15:50Z,2019-10-22T04:09:49Z,make is_power_of_two a const function,tspiteri,d689c709ea6e942de1687d918eaee541610aa86d,1,improve readability of is_power_of_two,THUMBS_UP,2019-10-21T05:44:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65092,MERGED,2019-10-04T09:15:50Z,2019-10-22T04:09:49Z,make is_power_of_two a const function,tspiteri,d689c709ea6e942de1687d918eaee541610aa86d,1,improve readability of is_power_of_two,THUMBS_UP,2019-11-08T11:19:39Z,rrbutani,NA https://github.com/rust-lang/rust/pull/65094,MERGED,2019-10-04T10:51:36Z,2019-10-20T02:00:19Z,Prefer statx on linux if available,oxalica,2ee45c9da28c4de155f29d402eff1d22977cbdc7,1,Fix cast of stx_btime.tv_nsec,THUMBS_UP,2019-10-04T17:40:49Z,ariasuni,perso@hack-libre.org https://github.com/rust-lang/rust/pull/65105,MERGED,2019-10-04T15:12:06Z,2019-10-06T08:40:21Z,Split out some passes from librustc,Mark-Simulacrum,7c3f65b3c4691ff0df270505ebfab89f171c0d28,8,middle::intrinsicck -> rustc_passes,THUMBS_UP,2019-10-04T18:31:35Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/65105,MERGED,2019-10-04T15:12:06Z,2019-10-06T08:40:21Z,Split out some passes from librustc,Mark-Simulacrum,7c3f65b3c4691ff0df270505ebfab89f171c0d28,8,middle::intrinsicck -> rustc_passes,THUMBS_UP,2019-10-04T19:28:22Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65105,MERGED,2019-10-04T15:12:06Z,2019-10-06T08:40:21Z,Split out some passes from librustc,Mark-Simulacrum,7c3f65b3c4691ff0df270505ebfab89f171c0d28,8,middle::intrinsicck -> rustc_passes,THUMBS_UP,2019-10-05T04:51:15Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65113,MERGED,2019-10-04T20:33:54Z,2019-10-06T08:40:20Z,Fix lonely backtick,Qwaz,d152d487276eda48601b5192ffcb8e69c4a83761,1,Fix lonely backtick,LAUGH,2019-10-04T21:01:05Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65113,MERGED,2019-10-04T20:33:54Z,2019-10-06T08:40:20Z,Fix lonely backtick,Qwaz,d152d487276eda48601b5192ffcb8e69c4a83761,1,Fix lonely backtick,LAUGH,2019-10-04T22:05:47Z,mati865,NA https://github.com/rust-lang/rust/pull/65113,MERGED,2019-10-04T20:33:54Z,2019-10-06T08:40:20Z,Fix lonely backtick,Qwaz,d152d487276eda48601b5192ffcb8e69c4a83761,1,Fix lonely backtick,LAUGH,2019-10-11T12:12:11Z,Ixrec,NA https://github.com/rust-lang/rust/pull/65130,MERGED,2019-10-05T13:11:31Z,2019-10-06T08:40:15Z,lint: extern non-exhaustive types are improper,davidtwco,080aa8663550c221221123a87f7c56bd1b7dc564,5,lint: extern non-exhaustive types are improper This commit makes the `improper_ctype` lint trigger for non-exhaustive types when those types aren't defined in the current crate. Signed-off-by: David Wood ,HEART,2019-10-05T20:31:20Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65133,MERGED,2019-10-05T16:15:40Z,2019-10-09T01:41:10Z,typeck: prohibit foreign statics w/ generics,davidtwco,ccbf2b76a6ca8ff3ca94e1ff9858089e67f79c04,8,"resolve: prohibit foreign statics w/ generics This commit modifies resolve to disallow foreign statics that use parent generics. `improper_ctypes` is not written to support type parameters as these are normally disallowed before the lint is run. Thus type parameters in foreign statics must be prohibited before the lint. The only other case where this *could* have occured is in functions but typeck prohibits this with a ""foreign items may not have type parameters"" error - a similar error did not exist for statics because statics cannot have type parameters but they can use any type parameters that are in scope (which isn't the case for functions). Signed-off-by: David Wood ",HEART,2019-10-08T17:56:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65133,MERGED,2019-10-05T16:15:40Z,2019-10-09T01:41:10Z,typeck: prohibit foreign statics w/ generics,davidtwco,ccbf2b76a6ca8ff3ca94e1ff9858089e67f79c04,8,"resolve: prohibit foreign statics w/ generics This commit modifies resolve to disallow foreign statics that use parent generics. `improper_ctypes` is not written to support type parameters as these are normally disallowed before the lint is run. Thus type parameters in foreign statics must be prohibited before the lint. The only other case where this *could* have occured is in functions but typeck prohibits this with a ""foreign items may not have type parameters"" error - a similar error did not exist for statics because statics cannot have type parameters but they can use any type parameters that are in scope (which isn't the case for functions). Signed-off-by: David Wood ",HEART,2019-10-09T17:05:31Z,gz,NA https://github.com/rust-lang/rust/pull/65134,MERGED,2019-10-05T16:31:37Z,2019-11-06T16:00:15Z,"improper_ctypes: `extern ""C""` fns",davidtwco,49e240346fe75eb5380469fb8e901f007fa829c1,2,libstd: allow `improper_ctypes` in `sys/sgx` Signed-off-by: David Wood ,HEART,2019-10-07T14:21:32Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/65134,MERGED,2019-10-05T16:31:37Z,2019-11-06T16:00:15Z,"improper_ctypes: `extern ""C""` fns",davidtwco,49e240346fe75eb5380469fb8e901f007fa829c1,2,libstd: allow `improper_ctypes` in `sys/sgx` Signed-off-by: David Wood ,HEART,2019-10-07T17:30:02Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/65134,MERGED,2019-10-05T16:31:37Z,2019-11-06T16:00:15Z,"improper_ctypes: `extern ""C""` fns",davidtwco,49e240346fe75eb5380469fb8e901f007fa829c1,2,libstd: allow `improper_ctypes` in `sys/sgx` Signed-off-by: David Wood ,HEART,2019-10-07T18:40:07Z,varkor,NA https://github.com/rust-lang/rust/pull/65137,MERGED,2019-10-05T19:16:27Z,2019-10-07T13:19:30Z,remove event that causes panics in measureme tools,andjo403,993e3a52cb33c4ea97ab8c73b449743669747497,1,remove event that causes panics in measureme tools the measureme tools summarize and crox do not alow a event to go out of scope of the parent event codegen_and_optimize_crate ends after the codegen_crate event,THUMBS_UP,2019-10-08T00:58:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65151,MERGED,2019-10-06T04:44:31Z,2019-10-06T08:40:12Z,"Revert #63649 - ""Upgrade Emscripten targets to use upstream LLVM backend""",tmandry,d16b7f705bd7c266a924e43a31495477dc4c9321,142,"Revert ""Auto merge of #63649 - tlively:emscripten-upstream-upgrade r=alexcrichton"" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91 reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.",HEART,2019-10-06T09:21:54Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/65151,MERGED,2019-10-06T04:44:31Z,2019-10-06T08:40:12Z,"Revert #63649 - ""Upgrade Emscripten targets to use upstream LLVM backend""",tmandry,d16b7f705bd7c266a924e43a31495477dc4c9321,142,"Revert ""Auto merge of #63649 - tlively:emscripten-upstream-upgrade r=alexcrichton"" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91 reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.",HEART,2019-10-08T05:59:32Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/65153,MERGED,2019-10-06T07:07:25Z,2019-10-10T23:44:05Z,Improve message when attempting to instantiate tuple structs with private fields,da-x,48f8beddd8e28a5bbdf1334f2c1de402196fa7f1,5,resolve: Use field spans for reporting the private constructor error,THUMBS_UP,2019-10-11T00:45:43Z,estebank,NA https://github.com/rust-lang/rust/pull/65154,MERGED,2019-10-06T07:10:56Z,2019-10-08T08:08:34Z,Fix const generic arguments not displaying in types mismatch diagnostic,skinny121,74eac929c270e896752fb826a3fed34aa0ef5725,2,Test diagnostic output of type mismatches for types that have const generics arguments.,HEART,2019-10-06T22:44:38Z,varkor,NA https://github.com/rust-lang/rust/pull/65154,MERGED,2019-10-06T07:10:56Z,2019-10-08T08:08:34Z,Fix const generic arguments not displaying in types mismatch diagnostic,skinny121,74eac929c270e896752fb826a3fed34aa0ef5725,2,Test diagnostic output of type mismatches for types that have const generics arguments.,HEART,2019-10-07T08:25:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/65154,MERGED,2019-10-06T07:10:56Z,2019-10-08T08:08:34Z,Fix const generic arguments not displaying in types mismatch diagnostic,skinny121,74eac929c270e896752fb826a3fed34aa0ef5725,2,Test diagnostic output of type mismatches for types that have const generics arguments.,HEART,2019-10-08T10:00:09Z,jplatte,NA https://github.com/rust-lang/rust/pull/65154,MERGED,2019-10-06T07:10:56Z,2019-10-08T08:08:34Z,Fix const generic arguments not displaying in types mismatch diagnostic,skinny121,74eac929c270e896752fb826a3fed34aa0ef5725,2,Test diagnostic output of type mismatches for types that have const generics arguments.,HEART,2019-10-16T23:33:37Z,GrayJack,NA https://github.com/rust-lang/rust/pull/65154,MERGED,2019-10-06T07:10:56Z,2019-10-08T08:08:34Z,Fix const generic arguments not displaying in types mismatch diagnostic,skinny121,74eac929c270e896752fb826a3fed34aa0ef5725,2,Test diagnostic output of type mismatches for types that have const generics arguments.,HEART,2019-10-17T18:49:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65158,MERGED,2019-10-06T09:29:05Z,2019-10-07T00:12:10Z,Remove dead module,ishitatsuyuki,c97f5f0045f8ba959dc3b72cd705043ac7b4d9eb,1,Remove dead module,HEART,2019-10-06T15:31:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-06T12:55:35Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-06T15:30:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-07T22:15:24Z,varkor,NA https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-07T22:39:38Z,estebank,NA https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-12T07:44:46Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65160,CLOSED,2019-10-06T11:29:30Z,2019-10-27T21:03:08Z,Refactor pattern-matching usefulness algorithm,Nadrieril,NA,NA,NA,HEART,2019-10-12T16:44:13Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65170,MERGED,2019-10-06T19:30:08Z,2019-10-15T04:56:36Z,rustc_metadata: Privatize private code and remove dead code,petrochenkov,f5baad2b5eae0dbe8c59768d51c2681a2cf7c9f1,9,rustc_metadata: Remove resolutions for extern crate items from `CStore` Use a more traditional scheme with providing them as a resolver output,HEART,2019-10-08T06:38:30Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/65172,MERGED,2019-10-06T21:34:34Z,2019-10-16T16:48:59Z,use precalculated dominators in explain_borrow,tanriol,4cc707cb7846c2a136daa42ea3498c5a92903189,1,use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example in rust-lang/rust#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct but no tests seem to fail as a result of this change in local testing.,HEART,2019-10-07T01:02:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65172,MERGED,2019-10-06T21:34:34Z,2019-10-16T16:48:59Z,use precalculated dominators in explain_borrow,tanriol,4cc707cb7846c2a136daa42ea3498c5a92903189,1,use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example in rust-lang/rust#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct but no tests seem to fail as a result of this change in local testing.,HEART,2019-10-07T08:22:15Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/65172,MERGED,2019-10-06T21:34:34Z,2019-10-16T16:48:59Z,use precalculated dominators in explain_borrow,tanriol,4cc707cb7846c2a136daa42ea3498c5a92903189,1,use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example in rust-lang/rust#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct but no tests seem to fail as a result of this change in local testing.,HEART,2019-10-07T09:21:17Z,moshg,NA https://github.com/rust-lang/rust/pull/65172,MERGED,2019-10-06T21:34:34Z,2019-10-16T16:48:59Z,use precalculated dominators in explain_borrow,tanriol,4cc707cb7846c2a136daa42ea3498c5a92903189,1,use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example in rust-lang/rust#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct but no tests seem to fail as a result of this change in local testing.,HEART,2019-10-09T21:46:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65172,MERGED,2019-10-06T21:34:34Z,2019-10-16T16:48:59Z,use precalculated dominators in explain_borrow,tanriol,4cc707cb7846c2a136daa42ea3498c5a92903189,1,use precalculated dominators in explain_borrow This looks like the only place calculating dominators from the MIR body every time instead of using the ones stored on the `MirBorrowckCtxt`. For example in rust-lang/rust#65131 a big generated function with a number of borrowck errors takes a few hours(!) recalculating the dominators while explaining the errors. I don't know enough about this part of rustc codebase to know for sure that this change is correct but no tests seem to fail as a result of this change in local testing.,HEART,2019-10-17T14:29:19Z,mati865,NA https://github.com/rust-lang/rust/pull/65174,MERGED,2019-10-06T21:51:19Z,2019-10-19T09:00:02Z,Fix zero-size uninitialized boxes,SimonSapin,227db40a98e5bd903aa3658c16f19a3d6f694deb,2,Uninitialized boxes: add test for zero-size allocations,THUMBS_UP,2019-10-06T21:53:40Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/65174,MERGED,2019-10-06T21:51:19Z,2019-10-19T09:00:02Z,Fix zero-size uninitialized boxes,SimonSapin,227db40a98e5bd903aa3658c16f19a3d6f694deb,2,Uninitialized boxes: add test for zero-size allocations,THUMBS_UP,2019-10-20T23:33:28Z,95th,NA https://github.com/rust-lang/rust/pull/65174,MERGED,2019-10-06T21:51:19Z,2019-10-19T09:00:02Z,Fix zero-size uninitialized boxes,SimonSapin,227db40a98e5bd903aa3658c16f19a3d6f694deb,2,Uninitialized boxes: add test for zero-size allocations,THUMBS_UP,2019-10-23T19:31:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65174,MERGED,2019-10-06T21:51:19Z,2019-10-19T09:00:02Z,Fix zero-size uninitialized boxes,SimonSapin,227db40a98e5bd903aa3658c16f19a3d6f694deb,2,Uninitialized boxes: add test for zero-size allocations,THUMBS_UP,2019-10-26T07:50:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65176,MERGED,2019-10-07T01:02:20Z,2019-10-08T21:12:15Z,Remove query-related macros,nnethercote,9267d9fe5b1f99f98da83a90e84de706cf8cc150,2,Remove `force_ex!`.,THUMBS_UP,2019-10-07T03:31:49Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65179,MERGED,2019-10-07T12:09:09Z,2019-10-08T21:12:15Z,Add long error explanation for E0567,GuillaumeGomez,6608e4af1bd80f096f1f52c118e856d23498c787,1,Update ui tests,ROCKET,2019-10-07T15:21:59Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-07T21:35:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-08T04:43:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-08T06:36:50Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-08T17:27:52Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-09T21:48:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-10T11:01:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-25T15:51:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-27T20:57:05Z,jplatte,NA https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-28T06:18:56Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,THUMBS_UP,2019-10-29T09:23:41Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/65188,MERGED,2019-10-07T20:13:54Z,2019-10-28T10:57:55Z,Stabilize `const_constructor`,matthewjasper,170718c93f3defba2edee69bae7abd64d1672355,8,Stabilize `const_constructor`,ROCKET,2019-11-05T16:46:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65191,MERGED,2019-10-07T21:16:34Z,2019-10-12T10:05:51Z,Add some regression tests,varkor,c99074490bc4e0d8a248bf807dfc3426341d7acd,3,Add a regression test for #57271,HEART,2019-10-07T23:56:12Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/65191,MERGED,2019-10-07T21:16:34Z,2019-10-12T10:05:51Z,Add some regression tests,varkor,c99074490bc4e0d8a248bf807dfc3426341d7acd,3,Add a regression test for #57271,HEART,2019-10-09T18:25:35Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/65192,MERGED,2019-10-07T21:26:49Z,2019-10-19T17:46:32Z,Use structured suggestion for restricting bounds,estebank,c6dce7802dc49a2e4b6049ad8971ba6f18252e64,1,Fix comparison after rebase,HEART,2019-10-18T04:00:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/65192,MERGED,2019-10-07T21:26:49Z,2019-10-19T17:46:32Z,Use structured suggestion for restricting bounds,estebank,c6dce7802dc49a2e4b6049ad8971ba6f18252e64,1,Fix comparison after rebase,HEART,2019-10-26T12:25:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HEART,2019-10-08T08:27:53Z,est31,NA https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HOORAY,2019-10-08T08:27:58Z,est31,NA https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HOORAY,2019-10-08T10:27:27Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HEART,2019-10-09T14:51:13Z,mati865,NA https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HOORAY,2019-10-10T20:02:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HEART,2019-10-11T05:14:43Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65193,MERGED,2019-10-07T22:57:46Z,2019-10-24T07:16:33Z,Lockless LintStore,Mark-Simulacrum,4e8d1b229217c7c83ce96b44410ccae9470db973,4,Add some documentation,HOORAY,2019-11-06T06:47:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65195,MERGED,2019-10-08T00:16:25Z,2019-12-06T22:24:54Z,Rename `bool::then_*` to `bool::to_option_*` and use where appropriate,varkor,f1db60ca9513c1693974f0b27c55d21a39f438b0,4,Fix rebase issues,THUMBS_UP,2019-10-08T04:43:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65195,MERGED,2019-10-08T00:16:25Z,2019-12-06T22:24:54Z,Rename `bool::then_*` to `bool::to_option_*` and use where appropriate,varkor,f1db60ca9513c1693974f0b27c55d21a39f438b0,4,Fix rebase issues,THUMBS_UP,2019-12-13T12:08:04Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/65195,MERGED,2019-10-08T00:16:25Z,2019-12-06T22:24:54Z,Rename `bool::then_*` to `bool::to_option_*` and use where appropriate,varkor,f1db60ca9513c1693974f0b27c55d21a39f438b0,4,Fix rebase issues,THUMBS_UP,2019-12-13T17:21:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65195,MERGED,2019-10-08T00:16:25Z,2019-12-06T22:24:54Z,Rename `bool::then_*` to `bool::to_option_*` and use where appropriate,varkor,f1db60ca9513c1693974f0b27c55d21a39f438b0,4,Fix rebase issues,THUMBS_UP,2019-12-13T17:58:44Z,Havvy,NA https://github.com/rust-lang/rust/pull/65196,MERGED,2019-10-08T03:02:46Z,2019-10-08T08:08:26Z,Rollup of 8 pull requests,Centril,bc7df81642fccf42c4250760e8a4c1ff298feec8,1,"Rollup merge of #65187 - Wind-River:master_before_merge r=rkruppe use 'invalid argument' for vxWorks vxWorks is using ""invalid argument"" instead of ""Invalid argument"" in reporting invalid options r? @rkruppe",THUMBS_UP,2019-10-08T13:27:01Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/65196,MERGED,2019-10-08T03:02:46Z,2019-10-08T08:08:26Z,Rollup of 8 pull requests,Centril,bc7df81642fccf42c4250760e8a4c1ff298feec8,1,"Rollup merge of #65187 - Wind-River:master_before_merge r=rkruppe use 'invalid argument' for vxWorks vxWorks is using ""invalid argument"" instead of ""Invalid argument"" in reporting invalid options r? @rkruppe",HOORAY,2019-10-08T13:27:27Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/65196,MERGED,2019-10-08T03:02:46Z,2019-10-08T08:08:26Z,Rollup of 8 pull requests,Centril,bc7df81642fccf42c4250760e8a4c1ff298feec8,1,"Rollup merge of #65187 - Wind-River:master_before_merge r=rkruppe use 'invalid argument' for vxWorks vxWorks is using ""invalid argument"" instead of ""Invalid argument"" in reporting invalid options r? @rkruppe",ROCKET,2019-10-08T13:27:34Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/65196,MERGED,2019-10-08T03:02:46Z,2019-10-08T08:08:26Z,Rollup of 8 pull requests,Centril,bc7df81642fccf42c4250760e8a4c1ff298feec8,1,"Rollup merge of #65187 - Wind-River:master_before_merge r=rkruppe use 'invalid argument' for vxWorks vxWorks is using ""invalid argument"" instead of ""Invalid argument"" in reporting invalid options r? @rkruppe",EYES,2019-10-08T13:27:39Z,srinivasreddy,thatiparthysreenivas@gmail.com https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-08T09:08:30Z,mati865,NA https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-08T09:21:06Z,bluss,NA https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-08T16:44:01Z,estebank,NA https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-09T15:14:06Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-10T10:58:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-17T11:29:09Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,ROCKET,2019-10-17T18:47:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65198,MERGED,2019-10-08T06:39:53Z,2019-10-09T12:51:07Z,Speed up `TokenStream` concatenation,nnethercote,75e0078a1703448a19e25eac85daaa5a4e6e68ac,1,Optimize `TokenStreamBuilder::push`. Currently when two tokens must be glued together this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first last}_tree`. The commit also restructures `push` somewhat by removing `TokenStream::{first_tree_and_joint last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter and in my opinion more readable.,HEART,2020-02-12T12:07:18Z,bb010g,NA https://github.com/rust-lang/rust/pull/65201,MERGED,2019-10-08T10:46:24Z,2019-10-19T04:54:47Z,Disable Go and OCaml bindings when building LLVM,tmiasko,3b0fd82bfad814ff777e7aa236b74804e4c469c0,1,Disable Go and OCaml bindings when building LLVM Instead of instaling OCaml bindings in a location where installation will not fail don't build them in the first place.,HOORAY,2019-10-12T19:12:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65202,MERGED,2019-10-08T11:16:29Z,2019-10-28T20:59:57Z,ci: move most of the prepare config into scripts,pietroalbini,7e051236b02ae6d924f24e080784fcf10cb8c4d3,1,ci: fix wrong path for wix being set,HEART,2019-10-08T15:19:34Z,mati865,NA https://github.com/rust-lang/rust/pull/65222,MERGED,2019-10-08T20:52:15Z,2020-03-27T19:23:06Z,Proposal: `fold_self` and `try_fold_self` for Iterators,Lucretiel,87fdf35572089028dff6bf4eb620c2f99764c1e0,1,Rollup merge of #65222 - Lucretiel:fold_self r=kodrAus Proposal: `fold_self` and `try_fold_self` for Iterators This pull request proposes & implements two new methods on Iterators: `fold_self` and `try_fold_self`. These are variants of `fold` and `try_fold` that use the first element in the iterator as the initial accumulator. Let me know if a public feature like this requires an RFC or if this pull request is sufficient as place for discussion.,THUMBS_UP,2020-04-02T17:36:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/65222,MERGED,2019-10-08T20:52:15Z,2020-03-27T19:23:06Z,Proposal: `fold_self` and `try_fold_self` for Iterators,Lucretiel,87fdf35572089028dff6bf4eb620c2f99764c1e0,1,Rollup merge of #65222 - Lucretiel:fold_self r=kodrAus Proposal: `fold_self` and `try_fold_self` for Iterators This pull request proposes & implements two new methods on Iterators: `fold_self` and `try_fold_self`. These are variants of `fold` and `try_fold` that use the first element in the iterator as the initial accumulator. Let me know if a public feature like this requires an RFC or if this pull request is sufficient as place for discussion.,THUMBS_UP,2020-04-03T06:14:31Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/65222,MERGED,2019-10-08T20:52:15Z,2020-03-27T19:23:06Z,Proposal: `fold_self` and `try_fold_self` for Iterators,Lucretiel,87fdf35572089028dff6bf4eb620c2f99764c1e0,1,Rollup merge of #65222 - Lucretiel:fold_self r=kodrAus Proposal: `fold_self` and `try_fold_self` for Iterators This pull request proposes & implements two new methods on Iterators: `fold_self` and `try_fold_self`. These are variants of `fold` and `try_fold` that use the first element in the iterator as the initial accumulator. Let me know if a public feature like this requires an RFC or if this pull request is sufficient as place for discussion.,THUMBS_UP,2020-06-01T11:42:22Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/65222,MERGED,2019-10-08T20:52:15Z,2020-03-27T19:23:06Z,Proposal: `fold_self` and `try_fold_self` for Iterators,Lucretiel,87fdf35572089028dff6bf4eb620c2f99764c1e0,1,Rollup merge of #65222 - Lucretiel:fold_self r=kodrAus Proposal: `fold_self` and `try_fold_self` for Iterators This pull request proposes & implements two new methods on Iterators: `fold_self` and `try_fold_self`. These are variants of `fold` and `try_fold` that use the first element in the iterator as the initial accumulator. Let me know if a public feature like this requires an RFC or if this pull request is sufficient as place for discussion.,THUMBS_UP,2020-12-07T08:37:40Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T10:43:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T11:46:20Z,mati865,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T16:25:54Z,lqd,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T17:08:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T18:50:57Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-09T22:56:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-10T16:34:25Z,varkor,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2019-10-11T16:28:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-13T15:43:09Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-14T00:04:46Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-15T23:02:32Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-15T23:36:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-16T07:56:47Z,jplatte,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-19T19:11:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-19T20:23:33Z,ah3nan,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-20T02:57:22Z,chmln,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-20T09:21:50Z,schulzch,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-20T13:28:15Z,chrish42,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-20T21:13:35Z,hugecheese,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-21T20:43:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-23T09:34:42Z,elpiel,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-23T18:23:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-10-24T23:43:52Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-11-04T01:00:34Z,tcbbd,tcbbdddd@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-11-07T02:51:39Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2019-11-10T01:33:55Z,Frizi,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-11-10T01:34:13Z,Frizi,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-12-18T03:23:55Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2019-12-18T07:21:31Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2020-01-13T01:48:24Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2020-01-13T01:48:24Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2020-02-07T09:42:31Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2020-02-07T09:42:35Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2020-02-08T13:54:41Z,crlf0710,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2020-02-09T14:19:11Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2020-02-13T17:08:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2020-02-13T17:08:40Z,Virgiel,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2020-08-26T15:03:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2021-08-04T10:08:23Z,fwcd,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2021-08-04T10:08:23Z,fwcd,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HOORAY,2021-08-06T14:00:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2021-08-06T14:01:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65232,MERGED,2019-10-09T09:44:56Z,2020-02-08T02:24:48Z,replace the leak check with universes take 2,nikomatsakis,4b3c66d2c309a16d48c2b7f992a2038016a098d3,4,make lint warn by default,HEART,2021-08-08T23:13:06Z,worstpractice,NA https://github.com/rust-lang/rust/pull/65234,MERGED,2019-10-09T12:20:30Z,2019-10-17T06:05:02Z,Add long error explanation for E0573,GuillaumeGomez,7d357fbffd7338957fe993b8dc28b91ca5c422b4,12,update ui tests,THUMBS_UP,2019-10-16T20:07:35Z,estebank,NA https://github.com/rust-lang/rust/pull/65241,MERGED,2019-10-09T16:55:35Z,2020-01-11T02:43:19Z,build-std compatible sanitizer support,tmiasko,e88f071ed373f1eb572dee6bc6898508425126e5,1,Document sanitizers in unstable-book,HEART,2019-10-09T17:08:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/65241,MERGED,2019-10-09T16:55:35Z,2020-01-11T02:43:19Z,build-std compatible sanitizer support,tmiasko,e88f071ed373f1eb572dee6bc6898508425126e5,1,Document sanitizers in unstable-book,HEART,2019-10-20T17:15:07Z,ehuss,NA https://github.com/rust-lang/rust/pull/65241,MERGED,2019-10-09T16:55:35Z,2020-01-11T02:43:19Z,build-std compatible sanitizer support,tmiasko,e88f071ed373f1eb572dee6bc6898508425126e5,1,Document sanitizers in unstable-book,HEART,2019-12-26T21:26:27Z,ogham,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-09T18:22:50Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-09T21:41:46Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-16T17:13:12Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-16T22:17:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-17T11:08:52Z,najamelan,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-17T11:31:44Z,flosse,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-17T14:13:05Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-17T21:51:24Z,estebank,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-19T04:35:18Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-10-25T15:55:25Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-10-28T05:53:46Z,imp,cyril.plisko@mountall.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-11-07T04:58:54Z,anacrolix,anacrolix@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-11-09T07:13:43Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-11-09T14:36:28Z,4meta5,asinghchrony@protonmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-11-09T21:05:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-11-12T15:07:14Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-11-12T15:07:15Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-11-15T05:22:30Z,echoulen,echoulen@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-11-19T11:59:06Z,chpio,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-11-28T17:54:20Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-05T00:34:17Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-06T01:47:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-06T21:01:39Z,matthunz,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-09T17:09:42Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-17T11:47:24Z,sangheestyle,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-17T21:38:07Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-12-17T21:38:09Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-17T21:42:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-12-17T21:42:23Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-19T18:39:21Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2019-12-19T19:23:31Z,frondeus,frondeus@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,CONFUSED,2019-12-30T09:24:17Z,AlphaHot,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2019-12-31T02:05:25Z,tmandry,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2020-01-02T22:53:12Z,GrayJack,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2020-01-02T22:53:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2020-01-03T13:06:42Z,robjtede,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2020-01-03T17:07:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2020-02-08T09:17:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2020-04-19T21:55:46Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2020-04-19T21:55:47Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2020-08-03T13:16:46Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2020-11-23T09:32:29Z,Voronar,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2021-12-22T01:49:42Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2021-12-22T01:49:50Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2022-01-03T09:27:07Z,nurmohammed840,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2022-01-25T10:49:17Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,LAUGH,2022-06-09T16:09:29Z,lukechu10,NA https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,LAUGH,2022-06-12T03:19:06Z,Jzow,jameszow@163.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,THUMBS_UP,2022-06-12T03:19:06Z,Jzow,jameszow@163.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2022-06-12T03:19:06Z,Jzow,jameszow@163.com https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2022-07-10T07:07:14Z,lucavenir,luca@venir.dev https://github.com/rust-lang/rust/pull/65244,MERGED,2019-10-09T17:22:14Z,2019-12-28T03:37:47Z,add IntoFuture trait and support for await,seanmonstar,f35517ee861dc012ccc26083dd4520045e2c4f6f,10,core: add IntoFuture trait and support for await,HOORAY,2022-07-10T09:47:42Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/65251,MERGED,2019-10-09T21:21:41Z,2019-10-17T10:45:30Z,Upgrade Emscripten targets to use upstream LLVM backend,tlively,c0aa7cb2b553f5c58102c6b95210c5adbb3518f3,3,Remove PR runs enable wasm32 CI and move asmjs to disabled,HOORAY,2019-10-11T12:55:37Z,est31,NA https://github.com/rust-lang/rust/pull/65251,MERGED,2019-10-09T21:21:41Z,2019-10-17T10:45:30Z,Upgrade Emscripten targets to use upstream LLVM backend,tlively,c0aa7cb2b553f5c58102c6b95210c5adbb3518f3,3,Remove PR runs enable wasm32 CI and move asmjs to disabled,HOORAY,2019-10-12T19:13:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65263,MERGED,2019-10-10T06:00:26Z,2019-10-12T10:05:43Z,Deduplicate is_{freeze copy sized}_raw,mbStavola,ee081145ac417b244e513580e15195c864763a6e,1,Qualify LangItem,HEART,2019-10-10T20:49:00Z,estebank,NA https://github.com/rust-lang/rust/pull/65266,MERGED,2019-10-10T09:43:04Z,2019-10-12T10:05:42Z,Mark Path::join as must_use,matklad,19bc0a8c674788539e0d93d072517ea3d7d9a998,1,Mark Path::join as must_use I've accidentally did `mut_path_buf.jon(a_path);` expecting this to be an in-place modification. Seems like we can easily warn in such cases?,THUMBS_UP,2019-10-10T09:59:46Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/65266,MERGED,2019-10-10T09:43:04Z,2019-10-12T10:05:42Z,Mark Path::join as must_use,matklad,19bc0a8c674788539e0d93d072517ea3d7d9a998,1,Mark Path::join as must_use I've accidentally did `mut_path_buf.jon(a_path);` expecting this to be an in-place modification. Seems like we can easily warn in such cases?,THUMBS_UP,2019-10-10T11:20:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65266,MERGED,2019-10-10T09:43:04Z,2019-10-12T10:05:42Z,Mark Path::join as must_use,matklad,19bc0a8c674788539e0d93d072517ea3d7d9a998,1,Mark Path::join as must_use I've accidentally did `mut_path_buf.jon(a_path);` expecting this to be an in-place modification. Seems like we can easily warn in such cases?,THUMBS_UP,2019-10-11T00:00:15Z,cramertj,NA https://github.com/rust-lang/rust/pull/65266,MERGED,2019-10-10T09:43:04Z,2019-10-12T10:05:42Z,Mark Path::join as must_use,matklad,19bc0a8c674788539e0d93d072517ea3d7d9a998,1,Mark Path::join as must_use I've accidentally did `mut_path_buf.jon(a_path);` expecting this to be an in-place modification. Seems like we can easily warn in such cases?,THUMBS_UP,2019-10-11T05:02:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-10T21:37:15Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-10T22:02:50Z,est31,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-10T22:03:23Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T00:13:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T00:27:40Z,estebank,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T00:32:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HOORAY,2019-10-11T01:17:46Z,comex,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T01:45:05Z,NavyAdmiral,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T09:31:48Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T11:08:28Z,fecetrulo,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,ROCKET,2019-10-11T11:22:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HOORAY,2019-10-11T11:22:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HEART,2019-10-11T11:52:43Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HOORAY,2019-10-11T12:58:22Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HEART,2019-10-11T12:58:24Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HOORAY,2019-10-11T13:56:04Z,mati865,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HEART,2019-10-11T17:50:44Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65281,CLOSED,2019-10-10T20:34:05Z,2019-10-29T19:01:53Z,for a more even partitioning inline before merge,andjo403,NA,NA,NA,HOORAY,2019-10-12T01:05:31Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/65294,MERGED,2019-10-11T01:42:41Z,2019-10-29T07:38:44Z,Lint ignored `#[inline]` on function prototypes,varkor,f47f53078c7477d2a2f7739c8f0e295125dd6bd3,3,Make inline associated constants a future compatibility warning,HEART,2019-10-23T11:11:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/65294,MERGED,2019-10-11T01:42:41Z,2019-10-29T07:38:44Z,Lint ignored `#[inline]` on function prototypes,varkor,f47f53078c7477d2a2f7739c8f0e295125dd6bd3,3,Make inline associated constants a future compatibility warning,HEART,2019-10-25T23:58:23Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65302,MERGED,2019-10-11T08:17:31Z,2019-10-20T06:11:07Z,Upgrade GCC to 8.3.0 glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux,msizanoen1,870ea528897d2500a97150ab01c1a2152e946f13,1,Mirror crosstool-ng on rust-lang-ci-mirrors,THUMBS_UP,2019-10-11T22:54:08Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/65302,MERGED,2019-10-11T08:17:31Z,2019-10-20T06:11:07Z,Upgrade GCC to 8.3.0 glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux,msizanoen1,870ea528897d2500a97150ab01c1a2152e946f13,1,Mirror crosstool-ng on rust-lang-ci-mirrors,THUMBS_UP,2019-10-12T06:29:05Z,stefson,NA https://github.com/rust-lang/rust/pull/65302,MERGED,2019-10-11T08:17:31Z,2019-10-20T06:11:07Z,Upgrade GCC to 8.3.0 glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux,msizanoen1,870ea528897d2500a97150ab01c1a2152e946f13,1,Mirror crosstool-ng on rust-lang-ci-mirrors,THUMBS_UP,2019-10-12T06:44:03Z,0x4ce66f11,NA https://github.com/rust-lang/rust/pull/65302,MERGED,2019-10-11T08:17:31Z,2019-10-20T06:11:07Z,Upgrade GCC to 8.3.0 glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux,msizanoen1,870ea528897d2500a97150ab01c1a2152e946f13,1,Mirror crosstool-ng on rust-lang-ci-mirrors,THUMBS_UP,2019-10-16T08:46:26Z,0ndorio,bruno.kirschner@online.de https://github.com/rust-lang/rust/pull/65310,MERGED,2019-10-11T13:40:04Z,2019-10-12T10:05:36Z,deriving: avoid dummy Span on an artificial `type_ident` path,da-x,e285175b63626bf930b90b27ba78b35842d0da2f,1,test: extend derive_on_deprecated to include more derivations,HEART,2019-10-11T17:43:15Z,estebank,NA https://github.com/rust-lang/rust/pull/65311,CLOSED,2019-10-11T14:30:33Z,2019-10-12T16:27:23Z,Update RLS and Rustfmt,Xanewok,NA,NA,NA,THUMBS_UP,2019-10-11T15:07:08Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/65311,CLOSED,2019-10-11T14:30:33Z,2019-10-12T16:27:23Z,Update RLS and Rustfmt,Xanewok,NA,NA,NA,HOORAY,2019-10-11T15:35:55Z,ghedo,alessandro@ghedini.me https://github.com/rust-lang/rust/pull/65312,MERGED,2019-10-11T15:20:17Z,2019-10-13T21:16:42Z,improve performance of signed saturating_mul,tspiteri,57aae75ce39de12f1af8d33d2836db59f7269ed2,1,improve performance of signed saturating_mul Reciprocal throughput is improved from 2.3 to 1.7. https://godbolt.org/z/ROMiX6,HEART,2019-10-11T21:18:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/65312,MERGED,2019-10-11T15:20:17Z,2019-10-13T21:16:42Z,improve performance of signed saturating_mul,tspiteri,57aae75ce39de12f1af8d33d2836db59f7269ed2,1,improve performance of signed saturating_mul Reciprocal throughput is improved from 2.3 to 1.7. https://godbolt.org/z/ROMiX6,HEART,2019-10-12T16:15:16Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65312,MERGED,2019-10-11T15:20:17Z,2019-10-13T21:16:42Z,improve performance of signed saturating_mul,tspiteri,57aae75ce39de12f1af8d33d2836db59f7269ed2,1,improve performance of signed saturating_mul Reciprocal throughput is improved from 2.3 to 1.7. https://godbolt.org/z/ROMiX6,HEART,2019-10-17T02:47:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65312,MERGED,2019-10-11T15:20:17Z,2019-10-13T21:16:42Z,improve performance of signed saturating_mul,tspiteri,57aae75ce39de12f1af8d33d2836db59f7269ed2,1,improve performance of signed saturating_mul Reciprocal throughput is improved from 2.3 to 1.7. https://godbolt.org/z/ROMiX6,HEART,2019-10-17T07:16:24Z,t-rapp,NA https://github.com/rust-lang/rust/pull/65312,MERGED,2019-10-11T15:20:17Z,2019-10-13T21:16:42Z,improve performance of signed saturating_mul,tspiteri,57aae75ce39de12f1af8d33d2836db59f7269ed2,1,improve performance of signed saturating_mul Reciprocal throughput is improved from 2.3 to 1.7. https://godbolt.org/z/ROMiX6,HEART,2019-10-17T18:47:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65315,MERGED,2019-10-11T18:18:19Z,2019-10-25T14:34:28Z,Intern place projection,spastorino,5f5903df31ae1beea85fc49e765ed57212d5346a,1,Add ignore-tidy-filelength on ty/context This is so we avoid a massive break of other people's code. Gonna run rustfmt and split the file on a different PR.,HOORAY,2019-10-18T17:22:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65315,MERGED,2019-10-11T18:18:19Z,2019-10-25T14:34:28Z,Intern place projection,spastorino,5f5903df31ae1beea85fc49e765ed57212d5346a,1,Add ignore-tidy-filelength on ty/context This is so we avoid a massive break of other people's code. Gonna run rustfmt and split the file on a different PR.,HOORAY,2019-10-22T14:28:56Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65321,MERGED,2019-10-11T21:43:48Z,2019-10-12T10:05:34Z,Remove painful test that is not pulling its weight,Mark-Simulacrum,000fe63b6fc57b09828930cacbab20c2ee6e6d15,3,Remove painful test that is not pulling its weight Research suggests that we are not properly testing this case anyway and even if we were it is unlikely that we will regress here -- or perhaps more accurately if we do I am uncertain that we care too much. It definitely seems like an edge case and one that is particularly unlikely to occur as time goes on.,HEART,2019-10-11T21:53:41Z,mati865,NA https://github.com/rust-lang/rust/pull/65321,MERGED,2019-10-11T21:43:48Z,2019-10-12T10:05:34Z,Remove painful test that is not pulling its weight,Mark-Simulacrum,000fe63b6fc57b09828930cacbab20c2ee6e6d15,3,Remove painful test that is not pulling its weight Research suggests that we are not properly testing this case anyway and even if we were it is unlikely that we will regress here -- or perhaps more accurately if we do I am uncertain that we care too much. It definitely seems like an edge case and one that is particularly unlikely to occur as time goes on.,HEART,2019-10-11T21:56:59Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/65324,MERGED,2019-10-12T04:22:09Z,2019-11-10T15:53:58Z,Split libsyntax apart,Centril,4ae2728fa8052915414127dce28245eb8f70842a,67,move syntax::parse -> librustc_parse also move MACRO_ARGUMENTS -> librustc_parse,HOORAY,2019-10-12T14:04:30Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/65324,MERGED,2019-10-12T04:22:09Z,2019-11-10T15:53:58Z,Split libsyntax apart,Centril,4ae2728fa8052915414127dce28245eb8f70842a,67,move syntax::parse -> librustc_parse also move MACRO_ARGUMENTS -> librustc_parse,HOORAY,2019-10-12T21:05:21Z,estebank,NA https://github.com/rust-lang/rust/pull/65324,MERGED,2019-10-12T04:22:09Z,2019-11-10T15:53:58Z,Split libsyntax apart,Centril,4ae2728fa8052915414127dce28245eb8f70842a,67,move syntax::parse -> librustc_parse also move MACRO_ARGUMENTS -> librustc_parse,HOORAY,2019-10-18T17:23:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65324,MERGED,2019-10-12T04:22:09Z,2019-11-10T15:53:58Z,Split libsyntax apart,Centril,4ae2728fa8052915414127dce28245eb8f70842a,67,move syntax::parse -> librustc_parse also move MACRO_ARGUMENTS -> librustc_parse,HOORAY,2019-10-26T12:47:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65324,MERGED,2019-10-12T04:22:09Z,2019-11-10T15:53:58Z,Split libsyntax apart,Centril,4ae2728fa8052915414127dce28245eb8f70842a,67,move syntax::parse -> librustc_parse also move MACRO_ARGUMENTS -> librustc_parse,HOORAY,2019-11-06T18:22:27Z,jplatte,NA https://github.com/rust-lang/rust/pull/65328,MERGED,2019-10-12T08:31:44Z,2019-10-12T22:04:18Z,Update rls and rustfmt,tesuji,81d813dd67fd94fdd680ba68f20e3df7b8953904,1,Bump home crate,HOORAY,2019-10-12T22:07:54Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/65337,CLOSED,2019-10-12T14:04:02Z,2019-10-19T16:11:33Z,Package non-rust objects,jethrogb,NA,NA,NA,THUMBS_UP,2019-10-14T08:22:05Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-13T10:55:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-13T16:47:15Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,HEART,2019-10-13T16:47:18Z,aleksanb,aleksanderburkow@gmail.com https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-14T20:57:52Z,izik1,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,HEART,2019-10-14T20:57:53Z,izik1,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,HEART,2019-10-16T05:38:15Z,chmln,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-16T05:38:15Z,chmln,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-17T18:45:25Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-10-28T02:14:55Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,HEART,2019-10-28T02:14:56Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-11-01T01:52:15Z,huwsun,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2019-12-12T23:29:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65338,CLOSED,2019-10-12T14:21:24Z,2019-10-26T11:20:51Z,[WIP] Add implicit named arguments for fmt macros,davidhewitt,NA,NA,NA,THUMBS_UP,2021-10-27T13:05:25Z,Wuelle,NA https://github.com/rust-lang/rust/pull/65340,MERGED,2019-10-12T14:42:27Z,2019-10-15T04:56:19Z,Several changes to the codegen backend organization,bjorn3,f0e2fc76235cb5184e264d028d86e1ab718b6214,2,Improve type safety,THUMBS_UP,2019-10-14T14:55:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65345,MERGED,2019-10-12T17:20:58Z,2019-12-11T22:53:49Z,async/await: improve not-send errors part 2,davidtwco,5cd9f22464a3ae2620c384094986d9549eca182e,1,erase regions instead of using `builtin_deref` The reason we were invoking `builtin_deref` was to enable comparisons when the type was `&T`. For the reasons outlined in the comment those comparisons failed because the regions disagreed.,HEART,2019-10-12T19:07:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65345,MERGED,2019-10-12T17:20:58Z,2019-12-11T22:53:49Z,async/await: improve not-send errors part 2,davidtwco,5cd9f22464a3ae2620c384094986d9549eca182e,1,erase regions instead of using `builtin_deref` The reason we were invoking `builtin_deref` was to enable comparisons when the type was `&T`. For the reasons outlined in the comment those comparisons failed because the regions disagreed.,HEART,2019-12-06T17:22:44Z,estebank,NA https://github.com/rust-lang/rust/pull/65353,MERGED,2019-10-13T01:24:15Z,2019-10-16T02:54:03Z,save-analysis: Don't ICE when resolving qualified type paths in struct members,Xanewok,eefc1697c5d3ba52c2af46994ed158e4457171b8,1,Nest typeck tables when processing struct member types,THUMBS_UP,2019-10-13T01:54:51Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/65353,MERGED,2019-10-13T01:24:15Z,2019-10-16T02:54:03Z,save-analysis: Don't ICE when resolving qualified type paths in struct members,Xanewok,eefc1697c5d3ba52c2af46994ed158e4457171b8,1,Nest typeck tables when processing struct member types,THUMBS_UP,2019-10-13T03:29:57Z,CoolOppo,NA https://github.com/rust-lang/rust/pull/65353,MERGED,2019-10-13T01:24:15Z,2019-10-16T02:54:03Z,save-analysis: Don't ICE when resolving qualified type paths in struct members,Xanewok,eefc1697c5d3ba52c2af46994ed158e4457171b8,1,Nest typeck tables when processing struct member types,THUMBS_UP,2019-10-16T07:49:56Z,kellytk,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T03:38:07Z,crlf0710,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T04:11:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T04:32:52Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T04:35:52Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T04:35:55Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T05:35:11Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T05:39:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T05:39:38Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T06:16:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T08:40:58Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T08:42:01Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T08:42:02Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T08:49:05Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T09:08:56Z,faern,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T09:53:33Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T10:19:56Z,crepererum,marco@crepererum.net https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T10:39:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T10:39:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T11:37:04Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T12:08:09Z,jplatte,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T12:08:10Z,jplatte,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T12:26:54Z,Ixrec,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T12:53:53Z,repnop,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T12:53:54Z,repnop,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T13:02:56Z,koute,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T13:02:56Z,koute,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-10-13T13:16:44Z,hvariant,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T14:01:13Z,Osspial,oss@osspial.net https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T14:01:13Z,Osspial,oss@osspial.net https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-10-13T14:24:45Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T16:50:35Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T17:07:24Z,Emerentius,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-13T20:00:50Z,mati865,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-13T20:00:55Z,mati865,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-10-13T22:44:35Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-14T06:52:43Z,qnighy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-14T06:52:43Z,qnighy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-14T12:29:12Z,orium,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-14T16:23:14Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-14T19:27:19Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-14T21:56:49Z,scott-maddox,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-15T07:32:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-10-15T10:49:04Z,petertodd,pete@petertodd.org https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-10-15T13:44:33Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-15T13:44:34Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-15T13:44:34Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-16T16:00:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-21T17:40:34Z,JesseWright,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-21T17:40:35Z,JesseWright,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-22T11:38:20Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-23T11:53:16Z,Selicre,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-28T04:13:34Z,Folyd,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-28T19:26:51Z,chrish42,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-29T12:14:02Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-10-30T20:54:50Z,RustyYato,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-10-30T20:54:51Z,RustyYato,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-06T11:23:10Z,ljedrz,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-08T10:44:38Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-10T02:57:34Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-10T02:57:35Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-10T07:18:33Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-11-13T15:22:03Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T17:20:21Z,chpio,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T17:52:02Z,tyranron,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T18:18:44Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T18:29:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-13T18:29:30Z,RalfJung,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-13T18:29:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T20:07:31Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-13T20:37:55Z,theduke,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T22:12:59Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-13T22:32:14Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-13T22:32:15Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-13T23:42:12Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-13T23:42:13Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-14T06:06:12Z,moshg,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-14T06:25:37Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,CONFUSED,2019-11-14T06:28:09Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-11-14T11:42:13Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-21T10:02:45Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-21T14:24:23Z,ecreeth,luismiguel1730@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-22T05:07:09Z,95th,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-11-22T05:07:10Z,95th,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-22T05:07:14Z,95th,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-22T05:07:17Z,95th,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-22T15:32:43Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-11-22T21:43:02Z,david-sawatzke,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-25T16:11:42Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-27T18:33:04Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-27T18:33:52Z,kureuil,louis@person.guru https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-11-27T23:20:17Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-28T05:17:59Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-28T05:50:06Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-11-28T05:50:08Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2019-11-28T05:50:10Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-28T14:22:46Z,lovasoa,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-11-28T16:28:37Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-12-01T11:03:27Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-12-01T11:03:28Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-12-02T19:59:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-12-02T20:26:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-12-11T17:56:45Z,mcarton,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2019-12-12T01:39:50Z,Dentosal,hannes.karppila@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2019-12-12T23:14:40Z,noc7c9,noc7c9@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-12-16T16:23:22Z,Elrendio,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2019-12-29T05:13:59Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2020-01-29T15:21:16Z,derekdreery,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2021-04-28T08:56:10Z,zohnannor,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2021-04-28T08:56:11Z,zohnannor,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2021-09-03T11:01:01Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2021-09-03T11:01:03Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2021-09-03T11:01:04Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2021-09-03T11:01:05Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,THUMBS_UP,2021-09-22T17:57:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HOORAY,2021-09-22T17:57:03Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,HEART,2021-09-22T17:57:04Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65355,MERGED,2019-10-13T03:12:21Z,2019-11-21T17:53:08Z,Stabilize `!` in Rust 1.41.0,Centril,238d03b3a32e7415becbcf22748286880ce21e3f,1,never_type: test interaction with auto traits,ROCKET,2021-09-22T17:57:04Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65357,MERGED,2019-10-13T04:15:24Z,2019-10-13T15:17:23Z,syntax: simplify maybe_annotate_with_ascription,Centril,9f09387f53792740edcb5dd0eea49ab02d3fe891,1,syntax: simplify maybe_annotate_with_ascription,HOORAY,2019-10-13T16:28:16Z,estebank,NA https://github.com/rust-lang/rust/pull/65364,MERGED,2019-10-13T05:18:02Z,2019-10-19T04:54:41Z,Collect occurrences of empty blocks for mismatched braces diagnostic,XiangQingW,fe819a074c748fd3d11fcc0be8164645a7cd58db,3,Collect occurrences of for mismatched braces diagnostic Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a,HEART,2019-10-15T16:14:32Z,estebank,NA https://github.com/rust-lang/rust/pull/65364,MERGED,2019-10-13T05:18:02Z,2019-10-19T04:54:41Z,Collect occurrences of empty blocks for mismatched braces diagnostic,XiangQingW,fe819a074c748fd3d11fcc0be8164645a7cd58db,3,Collect occurrences of for mismatched braces diagnostic Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a,THUMBS_UP,2019-10-15T18:15:40Z,PramodBisht,NA https://github.com/rust-lang/rust/pull/65365,MERGED,2019-10-13T06:19:21Z,2019-10-15T04:56:16Z,Include const generic arguments in metadata,skinny121,eb68bbb2b0a8fa78c81fc2a224133d480431fcfc,5,Include const generic arguments in metadata.,HEART,2019-10-13T14:00:02Z,varkor,NA https://github.com/rust-lang/rust/pull/65365,MERGED,2019-10-13T06:19:21Z,2019-10-15T04:56:16Z,Include const generic arguments in metadata,skinny121,eb68bbb2b0a8fa78c81fc2a224133d480431fcfc,5,Include const generic arguments in metadata.,HEART,2019-10-13T15:01:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/65365,MERGED,2019-10-13T06:19:21Z,2019-10-15T04:56:16Z,Include const generic arguments in metadata,skinny121,eb68bbb2b0a8fa78c81fc2a224133d480431fcfc,5,Include const generic arguments in metadata.,HEART,2019-10-15T09:29:09Z,est31,NA https://github.com/rust-lang/rust/pull/65370,MERGED,2019-10-13T11:50:10Z,2019-10-13T21:16:31Z,Add `dyn` to `Any` documentation,Cerber-Ursi,0510bbfb35c4628f4574b6b798d395bfa9f9a218,1,Added code element Co-Authored-By: Jonas Schievink ,THUMBS_UP,2019-10-13T11:52:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65393,CLOSED,2019-10-13T22:40:17Z,2019-11-09T11:15:15Z,Add {Impl Trait }Item::fn_header_span,llogiq,NA,NA,NA,HEART,2019-10-15T16:22:23Z,estebank,NA https://github.com/rust-lang/rust/pull/65395,MERGED,2019-10-14T01:58:13Z,2019-10-14T13:51:31Z,Add some tests for fixed ICEs,JohnTitor,f6e01e8d4098eccb9234368a576342cb781265eb,1,Add test for issue-48638,HOORAY,2019-10-14T14:37:16Z,VictorKoenders,github@trangar.com https://github.com/rust-lang/rust/pull/65398,MERGED,2019-10-14T04:49:16Z,2019-10-15T04:56:14Z,Bring attention to suggestions when the only difference is capitalization,estebank,8bf6d353772aacc15c78919e3d2f2db0528484b1,7,Tweak heuristics for less noise,HEART,2019-10-15T11:39:40Z,sunjay,NA https://github.com/rust-lang/rust/pull/65398,MERGED,2019-10-14T04:49:16Z,2019-10-15T04:56:14Z,Bring attention to suggestions when the only difference is capitalization,estebank,8bf6d353772aacc15c78919e3d2f2db0528484b1,7,Tweak heuristics for less noise,HEART,2019-10-26T07:51:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65398,MERGED,2019-10-14T04:49:16Z,2019-10-15T04:56:14Z,Bring attention to suggestions when the only difference is capitalization,estebank,8bf6d353772aacc15c78919e3d2f2db0528484b1,7,Tweak heuristics for less noise,HEART,2021-06-07T18:23:27Z,glittershark,github@gws.fyi https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-14T15:17:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-14T16:55:52Z,estebank,NA https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-14T18:11:05Z,cramertj,NA https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-24T17:18:51Z,jaseemabid,jaseemabid@gmail.com https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-26T07:48:22Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65410,MERGED,2019-10-14T15:10:23Z,2019-10-15T04:56:12Z,syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`,Centril,16266a54058a71c943d064054bfe3a1b5704a444,3,pprust: `p1@p2` -> `p1 @ p2`,HEART,2019-10-28T06:12:36Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/65414,MERGED,2019-10-14T18:09:12Z,2019-10-25T07:47:35Z,ignore uninhabited non-exhaustive variant fields,davidtwco,7ffbd62445b9706325d01ec8be8e70c41404fe0d,3,ignore uninhabited non-exhaustive variant fields This commit modifies the uninhabitedness checking so that the fields of a non-exhaustive variant (which is not local) are ignored if they are uninhabited. This is an improvement over the previous behaviour which considered all non-local non-exhaustive variants useful because unreachable patterns are now detected. Signed-off-by: David Wood ,HEART,2019-10-19T03:29:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65414,MERGED,2019-10-14T18:09:12Z,2019-10-25T07:47:35Z,ignore uninhabited non-exhaustive variant fields,davidtwco,7ffbd62445b9706325d01ec8be8e70c41404fe0d,3,ignore uninhabited non-exhaustive variant fields This commit modifies the uninhabitedness checking so that the fields of a non-exhaustive variant (which is not local) are ignored if they are uninhabited. This is an improvement over the previous behaviour which considered all non-local non-exhaustive variants useful because unreachable patterns are now detected. Signed-off-by: David Wood ,HEART,2019-10-24T23:16:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65421,MERGED,2019-10-15T00:21:20Z,2019-10-28T17:17:50Z,Point at local similarly named element and tweak references to variants,estebank,b26ddb8af37362e33c45c78c9c91a3c5cdabfe7e,132,Point at local similarly named element and tweak references to variants Point at the span for the definition of ADTs internal to the current crate. Look at the leading char of the ident to determine whether we're expecting a likely fn or any of a fn a tuple struct or a tuple variant. Turn fn `add_typo_suggestion` into a `Resolver` method.,THUMBS_UP,2019-10-15T05:55:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65425,MERGED,2019-10-15T03:18:44Z,2019-10-16T02:53:57Z,Optimize `BitIter`,nnethercote,60851b08e523e1a3ab4defc8b6049751b6bf1ad5,1,Optimize `BitSet` iteration. This commit removes an `Option` check in `BitIter::next()` avoids calling `trailing_zeros()` when it's not necessary and avoids the need for `enumerate()`. This gives a tiny (0.2%) instruction count win on a couple of benchmarks. The commit also adds some comments which is good because this iteration code is moderately complex.,THUMBS_UP,2019-10-15T15:40:02Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65429,MERGED,2019-10-15T08:27:37Z,2019-11-02T21:50:48Z,Add File::with_options,Timmmm,c8150cb1594af7f3c2fe4b3968809637ca274260,1,Fix read/write links hopefully!,THUMBS_UP,2019-10-15T10:15:39Z,aldanor,NA https://github.com/rust-lang/rust/pull/65429,MERGED,2019-10-15T08:27:37Z,2019-11-02T21:50:48Z,Add File::with_options,Timmmm,c8150cb1594af7f3c2fe4b3968809637ca274260,1,Fix read/write links hopefully!,THUMBS_UP,2019-10-15T10:45:26Z,retep998,NA https://github.com/rust-lang/rust/pull/65429,MERGED,2019-10-15T08:27:37Z,2019-11-02T21:50:48Z,Add File::with_options,Timmmm,c8150cb1594af7f3c2fe4b3968809637ca274260,1,Fix read/write links hopefully!,THUMBS_UP,2020-01-13T03:19:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65429,MERGED,2019-10-15T08:27:37Z,2019-11-02T21:50:48Z,Add File::with_options,Timmmm,c8150cb1594af7f3c2fe4b3968809637ca274260,1,Fix read/write links hopefully!,THUMBS_UP,2020-02-01T10:04:44Z,Herohtar,belac1186@gmail.com https://github.com/rust-lang/rust/pull/65435,MERGED,2019-10-15T11:54:59Z,2019-10-29T11:18:28Z,Fix #64153,michaelwoerister,a63dfb3b82a44e31bdfadb13d240a5366f9979fb,1,Ignore issue-64153 run-make test on Windows since supporting a Windows version is not worth the trouble.,THUMBS_UP,2019-10-29T11:29:23Z,lanp,NA https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-10-16T02:45:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-10-16T04:43:13Z,sinkuu,NA https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-11-18T03:38:47Z,ronjouch,NA https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-11-18T13:41:39Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-11-18T16:24:04Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-11-20T17:25:59Z,krdln,NA https://github.com/rust-lang/rust/pull/65456,MERGED,2019-10-16T01:43:41Z,2019-11-18T03:07:08Z,Suggest borrowing when it would satisfy an unmet trait bound,estebank,2fe8371268b36193fa4dc8461341db90f4ec96b9,2,review comments and fix rebase,HEART,2019-11-26T06:16:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65460,MERGED,2019-10-16T05:54:37Z,2019-10-20T23:35:43Z,Clean up `contains()` `insert()` chains on HashSet,sinkuu,ac2f906a592135953ede70429efadd876e21cd09,6,Make use of the return value of `HashSet::insert`,THUMBS_UP,2019-10-16T07:39:15Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65460,MERGED,2019-10-16T05:54:37Z,2019-10-20T23:35:43Z,Clean up `contains()` `insert()` chains on HashSet,sinkuu,ac2f906a592135953ede70429efadd876e21cd09,6,Make use of the return value of `HashSet::insert`,THUMBS_UP,2019-10-16T18:53:12Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/65460,MERGED,2019-10-16T05:54:37Z,2019-10-20T23:35:43Z,Clean up `contains()` `insert()` chains on HashSet,sinkuu,ac2f906a592135953ede70429efadd876e21cd09,6,Make use of the return value of `HashSet::insert`,THUMBS_UP,2019-10-16T19:40:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/65460,MERGED,2019-10-16T05:54:37Z,2019-10-20T23:35:43Z,Clean up `contains()` `insert()` chains on HashSet,sinkuu,ac2f906a592135953ede70429efadd876e21cd09,6,Make use of the return value of `HashSet::insert`,HEART,2019-10-16T19:41:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/65469,MERGED,2019-10-16T10:52:32Z,2019-10-20T10:11:16Z,Update libc to 0.2.64,mati865,6de4924b6c1ff5a99397ca1a3894c51f085f3e6f,2,Update emscripten functions declarations,HOORAY,2019-10-16T23:44:03Z,tlively,NA https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-10-16T17:04:03Z,ehuss,NA https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-10-17T09:52:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-10-17T19:31:10Z,jplatte,NA https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-10-19T16:35:33Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-10-30T22:37:27Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2019-11-11T22:05:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65474,MERGED,2019-10-16T16:38:44Z,2019-10-24T10:58:40Z,Split the rustc target libraries into separate rustc-dev component,Mark-Simulacrum,7ccf492ae616b4d06eab283ab604938fd234415a,3,Package non-rust objects,HEART,2020-01-10T13:56:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-16T23:00:41Z,djg,dan.glastonbury@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-16T23:52:08Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T01:30:37Z,Awpteamoose,awpteamoose@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T04:22:51Z,Vengarioth,opensource@deviru.de https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T04:43:51Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T07:08:14Z,sindresorhus,sindresorhus@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T07:46:45Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T11:46:29Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-17T17:45:42Z,alexheretic,NA https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-18T09:33:31Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-18T17:07:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-18T20:56:46Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HOORAY,2019-10-18T20:56:49Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HEART,2019-10-18T20:56:51Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HOORAY,2019-10-23T22:45:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-23T22:45:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-30T18:36:06Z,abonander,austin.bonander@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-10-31T16:44:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HOORAY,2019-11-01T15:33:07Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HEART,2019-11-01T15:33:07Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2019-11-01T15:33:08Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,HOORAY,2019-11-05T17:08:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65479,MERGED,2019-10-16T21:31:20Z,2019-10-24T07:16:23Z,Add the `matches!( $expr $pat ) -> bool` macro,SimonSapin,e76a1846153209b15dfbf697a33c25214bb753b3,1,Document guard expressions in `matches!`,THUMBS_UP,2020-08-02T00:05:17Z,jakajancar,jaka@kubje.org https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T14:29:49Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T14:48:32Z,mati865,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T16:17:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T20:42:49Z,ollie27,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T20:45:33Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-17T21:18:01Z,lqd,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-18T01:32:25Z,crlf0710,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-19T18:47:10Z,malbarbo,NA https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-21T17:30:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-21T20:14:02Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-22T00:48:06Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-10-22T04:17:24Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-12-02T23:07:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65501,MERGED,2019-10-17T14:06:08Z,2019-10-22T07:41:04Z,Remove `src/llvm-emscripten` submodule,alexcrichton,c7d285b78136a5bccf8419afa4c57428b83b8bec,15,Remove `src/llvm-emscripten` submodule With #65251 landed there's no need to build two LLVM backends and ship them with rustc every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.,HOORAY,2019-12-13T13:04:23Z,chpio,NA https://github.com/rust-lang/rust/pull/65503,MERGED,2019-10-17T16:47:01Z,2019-10-22T15:42:38Z,Refactor libtest,popzxc,ae04dc8473f9ea53b71123eb4eb0fcec71e6d797,1,Remove unneccessary use under cfg(unix),HEART,2019-10-18T13:57:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65503,MERGED,2019-10-17T16:47:01Z,2019-10-22T15:42:38Z,Refactor libtest,popzxc,ae04dc8473f9ea53b71123eb4eb0fcec71e6d797,1,Remove unneccessary use under cfg(unix),HEART,2019-10-18T18:09:26Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/65503,MERGED,2019-10-17T16:47:01Z,2019-10-22T15:42:38Z,Refactor libtest,popzxc,ae04dc8473f9ea53b71123eb4eb0fcec71e6d797,1,Remove unneccessary use under cfg(unix),HEART,2019-10-22T15:49:40Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65505,MERGED,2019-10-17T17:53:14Z,2019-10-19T17:46:16Z,Rc: value -> allocation,RalfJung,1b3846359a084f62eaab74390134011ed9e6cd48,1,do all the same edits with Arc,HEART,2019-10-17T20:57:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-18T17:09:50Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-19T08:34:56Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-19T13:42:50Z,hugecheese,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-20T00:15:51Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-23T22:27:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-24T04:04:22Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,ROCKET,2019-10-24T08:19:12Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,HOORAY,2019-10-24T08:19:14Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-24T08:38:13Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-10-24T08:55:02Z,lnicola,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,HOORAY,2019-10-25T02:28:58Z,yelite,NA https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,HOORAY,2019-10-26T07:47:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65551,MERGED,2019-10-18T08:05:37Z,2019-10-20T18:06:23Z,Avoid realloc in `CString::new`,sinkuu,23cb1d520bbe943b9dfae54c6a8f2f1fe4748872,3,Avoid realloc in `CString::new`,THUMBS_UP,2019-11-11T01:28:10Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/65554,MERGED,2019-10-18T11:34:48Z,2019-11-08T07:56:05Z,Enhance the documentation of BufReader for potential data loss,gliderkite,5b5196ad65db877c2f140dfc7a25f3fc6f2e40c6,1,rephrase sentence regarding data loss when using BufReader::into_inner,THUMBS_UP,2019-10-18T11:40:30Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/65554,MERGED,2019-10-18T11:34:48Z,2019-11-08T07:56:05Z,Enhance the documentation of BufReader for potential data loss,gliderkite,5b5196ad65db877c2f140dfc7a25f3fc6f2e40c6,1,rephrase sentence regarding data loss when using BufReader::into_inner,THUMBS_UP,2019-10-18T12:28:06Z,bausano,git@porkbrain.com https://github.com/rust-lang/rust/pull/65562,MERGED,2019-10-18T16:13:59Z,2019-10-29T07:38:35Z,"Improve the ""try using a variant of the expected type"" hint.",Patryk27,5c023d68d8b54d651e1775a69e999503ae5b2b30,3,Improve pretty-printing for compound qualified paths.,HEART,2019-10-18T16:56:43Z,estebank,NA https://github.com/rust-lang/rust/pull/65562,MERGED,2019-10-18T16:13:59Z,2019-10-29T07:38:35Z,"Improve the ""try using a variant of the expected type"" hint.",Patryk27,5c023d68d8b54d651e1775a69e999503ae5b2b30,3,Improve pretty-printing for compound qualified paths.,HEART,2019-11-06T18:20:55Z,jplatte,NA https://github.com/rust-lang/rust/pull/65576,MERGED,2019-10-18T22:18:09Z,2019-10-19T08:59:40Z,Don't add `argc` and `argv` arguments to `main` on WASI.,sunfishcode,b25e3238c76a4df767b4a929011ed47c479ed115,3,Don't add `argc` and `argv` arguments to `main` on WASI. Add a target setting to allow targets to specify whether the generated `main` function should be passed `argc` and `argv` arguments. Set it to false on wasm32-wasi since WASI's `args::args()` calls into the WASI APIs itself. This will allow the WASI toolchain to avoid linking and running command-line argument initialization code when the arguments aren't actually needed.,HEART,2019-10-19T01:26:59Z,est31,NA https://github.com/rust-lang/rust/pull/65579,MERGED,2019-10-18T23:13:22Z,2019-10-20T23:35:36Z,Changed `resolve_type_vars_with_obligations` to also resolve const inference variables,skinny121,9cefcd3051ac7f4ea3c924bd7542c70c59ac5dfd,7,Rename resolve_type_vars_with_obligations to resolve_vars_with_obligations as it now also resolves const variables.,HEART,2019-10-19T00:04:25Z,varkor,NA https://github.com/rust-lang/rust/pull/65579,MERGED,2019-10-18T23:13:22Z,2019-10-20T23:35:36Z,Changed `resolve_type_vars_with_obligations` to also resolve const inference variables,skinny121,9cefcd3051ac7f4ea3c924bd7542c70c59ac5dfd,7,Rename resolve_type_vars_with_obligations to resolve_vars_with_obligations as it now also resolves const variables.,HEART,2019-10-19T04:15:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65579,MERGED,2019-10-18T23:13:22Z,2019-10-20T23:35:36Z,Changed `resolve_type_vars_with_obligations` to also resolve const inference variables,skinny121,9cefcd3051ac7f4ea3c924bd7542c70c59ac5dfd,7,Rename resolve_type_vars_with_obligations to resolve_vars_with_obligations as it now also resolves const variables.,HEART,2019-10-19T16:03:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/65580,MERGED,2019-10-18T23:30:06Z,2019-11-08T07:56:03Z,Add `MaybeUninit` methods `uninit_array` `slice_get_ref` `slice_get_mut`,SimonSapin,639c4f779c60119383dd8a49b44522f6a6958a53,1,MaybeUninit::uninit_array docs: better example,HEART,2019-10-21T05:19:43Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65580,MERGED,2019-10-18T23:30:06Z,2019-11-08T07:56:03Z,Add `MaybeUninit` methods `uninit_array` `slice_get_ref` `slice_get_mut`,SimonSapin,639c4f779c60119383dd8a49b44522f6a6958a53,1,MaybeUninit::uninit_array docs: better example,HEART,2019-11-13T16:37:49Z,RustyYato,NA https://github.com/rust-lang/rust/pull/65580,MERGED,2019-10-18T23:30:06Z,2019-11-08T07:56:03Z,Add `MaybeUninit` methods `uninit_array` `slice_get_ref` `slice_get_mut`,SimonSapin,639c4f779c60119383dd8a49b44522f6a6958a53,1,MaybeUninit::uninit_array docs: better example,HEART,2019-11-16T18:22:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65580,MERGED,2019-10-18T23:30:06Z,2019-11-08T07:56:03Z,Add `MaybeUninit` methods `uninit_array` `slice_get_ref` `slice_get_mut`,SimonSapin,639c4f779c60119383dd8a49b44522f6a6958a53,1,MaybeUninit::uninit_array docs: better example,HEART,2021-11-27T11:36:54Z,r00ster91,NA https://github.com/rust-lang/rust/pull/65608,MERGED,2019-10-19T20:08:11Z,2019-11-12T21:13:12Z,Fix MIR lowering evaluation order and soundness bug,matthewjasper,4bf0685cca167e684340152809be20a16ad65a76,7,Evaluate borrow and struct expressions in `into` This fixes some ordering problems around assignment expressions.,HEART,2019-11-13T00:59:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/65608,MERGED,2019-10-19T20:08:11Z,2019-11-12T21:13:12Z,Fix MIR lowering evaluation order and soundness bug,matthewjasper,4bf0685cca167e684340152809be20a16ad65a76,7,Evaluate borrow and struct expressions in `into` This fixes some ordering problems around assignment expressions.,HEART,2019-11-20T18:36:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65608,MERGED,2019-10-19T20:08:11Z,2019-11-12T21:13:12Z,Fix MIR lowering evaluation order and soundness bug,matthewjasper,4bf0685cca167e684340152809be20a16ad65a76,7,Evaluate borrow and struct expressions in `into` This fixes some ordering problems around assignment expressions.,HEART,2019-11-26T06:34:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65613,MERGED,2019-10-19T23:24:17Z,2019-11-25T22:46:30Z,Preserve whitespace inside one-backtick codeblocks,Mark-Simulacrum,bc3ed3241b2e81c56d7a746df4fa0766e339c9b5,1,Preserve whitespace inside one-backtick codeblocks Previously this was only done inside short docblocks (e.g. summary lines) but we should also do so in general.,THUMBS_UP,2019-10-20T05:11:31Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/65613,MERGED,2019-10-19T23:24:17Z,2019-11-25T22:46:30Z,Preserve whitespace inside one-backtick codeblocks,Mark-Simulacrum,bc3ed3241b2e81c56d7a746df4fa0766e339c9b5,1,Preserve whitespace inside one-backtick codeblocks Previously this was only done inside short docblocks (e.g. summary lines) but we should also do so in general.,THUMBS_UP,2019-12-02T20:06:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65624,MERGED,2019-10-20T13:07:02Z,2019-10-21T19:46:29Z,[mir-opt] Improve SimplifyLocals pass so it can remove unused consts,wesleywiser,2ec73395b985a028062cc40faed6ace50be0c67d,9,Improve SimplifyLocals pass so it can remove unused consts The `ConstProp` can cause many locals to be initialized to a constant value and then never read from. `ConstProp` can also evaluate ZSTs into constant values. Previously many of these would be removed by other parts of the MIR optimization pipeline. However evaluating ZSTs (especially `()`) into constant values defeated those parts of the optimizer and so in a2e3ed5c054b544df6ceeb9e612d39af819f4aae I added a hack to `ConstProp` that skips evaluating ZSTs to avoid that regression. This commit changes `SimplifyLocals` so that it doesn't consider writes of const values to a local to be a use of that local. In doing so `SimplifyLocals` is able to remove otherwise unused locals left behind by other optimization passes (`ConstProp` in particular).,HOORAY,2019-10-21T07:49:42Z,mati865,NA https://github.com/rust-lang/rust/pull/65624,MERGED,2019-10-20T13:07:02Z,2019-10-21T19:46:29Z,[mir-opt] Improve SimplifyLocals pass so it can remove unused consts,wesleywiser,2ec73395b985a028062cc40faed6ace50be0c67d,9,Improve SimplifyLocals pass so it can remove unused consts The `ConstProp` can cause many locals to be initialized to a constant value and then never read from. `ConstProp` can also evaluate ZSTs into constant values. Previously many of these would be removed by other parts of the MIR optimization pipeline. However evaluating ZSTs (especially `()`) into constant values defeated those parts of the optimizer and so in a2e3ed5c054b544df6ceeb9e612d39af819f4aae I added a hack to `ConstProp` that skips evaluating ZSTs to avoid that regression. This commit changes `SimplifyLocals` so that it doesn't consider writes of const values to a local to be a use of that local. In doing so `SimplifyLocals` is able to remove otherwise unused locals left behind by other optimization passes (`ConstProp` in particular).,HOORAY,2019-10-26T12:03:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65625,MERGED,2019-10-20T14:09:58Z,2019-10-25T04:14:56Z,Turn crate store into a resolver output,petrochenkov,94216ce3adfdb7d6c206505fca736d274a98ad2b,2,rustc_interface: Remove `ExpansionResult` and some `Steal`s,HOORAY,2019-10-20T16:13:49Z,mati865,NA https://github.com/rust-lang/rust/pull/65625,MERGED,2019-10-20T14:09:58Z,2019-10-25T04:14:56Z,Turn crate store into a resolver output,petrochenkov,94216ce3adfdb7d6c206505fca736d274a98ad2b,2,rustc_interface: Remove `ExpansionResult` and some `Steal`s,HOORAY,2019-10-21T07:55:27Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/65625,MERGED,2019-10-20T14:09:58Z,2019-10-25T04:14:56Z,Turn crate store into a resolver output,petrochenkov,94216ce3adfdb7d6c206505fca736d274a98ad2b,2,rustc_interface: Remove `ExpansionResult` and some `Steal`s,HOORAY,2019-10-21T21:00:59Z,estebank,NA https://github.com/rust-lang/rust/pull/65625,MERGED,2019-10-20T14:09:58Z,2019-10-25T04:14:56Z,Turn crate store into a resolver output,petrochenkov,94216ce3adfdb7d6c206505fca736d274a98ad2b,2,rustc_interface: Remove `ExpansionResult` and some `Steal`s,HOORAY,2019-11-05T22:12:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65630,MERGED,2019-10-20T17:56:37Z,2019-10-21T07:50:51Z,Check all files in `src/test` for `borrowck_graphviz_postflow`,ecstatic-morse,efcae577bf5ebf503a702c7e66c2924ddb53cdb8,1,Ignore DOT files in .gitignore,HEART,2019-10-20T17:58:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/65637,MERGED,2019-10-20T20:00:03Z,2019-11-13T06:43:51Z,proposal for BTreeMap/Set min/max #62924,ssomers,ffeac1f71fe8d8206c9c83747cdd7816ad9aafc2,7,proposal for access to BTreeMap/BTreeSet first/last #62924,ROCKET,2019-11-25T22:42:13Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65637,MERGED,2019-10-20T20:00:03Z,2019-11-13T06:43:51Z,proposal for BTreeMap/Set min/max #62924,ssomers,ffeac1f71fe8d8206c9c83747cdd7816ad9aafc2,7,proposal for access to BTreeMap/BTreeSet first/last #62924,ROCKET,2019-12-01T17:33:35Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65640,MERGED,2019-10-20T21:48:14Z,2019-10-29T00:35:27Z,Use heuristics to recover parsing of missing `;`,estebank,e8016c2b13a7e16b6eed9e30b4b6bfe304750566,3,review comments,HOORAY,2019-11-06T18:50:55Z,justinrlle,justinrlle@pm.me https://github.com/rust-lang/rust/pull/65640,MERGED,2019-10-20T21:48:14Z,2019-10-29T00:35:27Z,Use heuristics to recover parsing of missing `;`,estebank,e8016c2b13a7e16b6eed9e30b4b6bfe304750566,3,review comments,HOORAY,2019-11-06T19:25:46Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65640,MERGED,2019-10-20T21:48:14Z,2019-10-29T00:35:27Z,Use heuristics to recover parsing of missing `;`,estebank,e8016c2b13a7e16b6eed9e30b4b6bfe304750566,3,review comments,THUMBS_UP,2019-11-06T20:01:53Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65640,MERGED,2019-10-20T21:48:14Z,2019-10-29T00:35:27Z,Use heuristics to recover parsing of missing `;`,estebank,e8016c2b13a7e16b6eed9e30b4b6bfe304750566,3,review comments,HOORAY,2019-11-11T21:53:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-10-21T20:32:03Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-10-27T11:32:02Z,mati865,NA https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T18:51:27Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T19:26:19Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T19:55:51Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T20:55:01Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T21:44:37Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T21:52:26Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-06T22:55:53Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-07T15:52:26Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-07T19:41:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-08T01:18:49Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-09T10:38:49Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-10T23:45:17Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-11T21:59:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65646,MERGED,2019-10-21T02:04:46Z,2019-11-03T21:56:13Z,Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI,Amanieu,f223e0d6274a8626b9d9428582384955e7f24b15,1,Fix macOS tests,HOORAY,2019-11-14T16:19:38Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/65647,MERGED,2019-10-21T03:43:22Z,2019-10-22T04:09:30Z,Remove unnecessary trait bounds and derivations,nnethercote,ac6daed384d17abd31f84fc8205c21eee6a248be,49,Remove many unnecessary trait derivations.,HEART,2019-10-21T05:10:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/65647,MERGED,2019-10-21T03:43:22Z,2019-10-22T04:09:30Z,Remove unnecessary trait bounds and derivations,nnethercote,ac6daed384d17abd31f84fc8205c21eee6a248be,49,Remove many unnecessary trait derivations.,HEART,2019-10-21T07:23:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/65647,MERGED,2019-10-21T03:43:22Z,2019-10-22T04:09:30Z,Remove unnecessary trait bounds and derivations,nnethercote,ac6daed384d17abd31f84fc8205c21eee6a248be,49,Remove many unnecessary trait derivations.,HEART,2019-11-05T16:07:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-21T07:37:13Z,mati865,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-21T08:24:50Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-21T09:04:37Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-21T09:10:20Z,varkor,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HOORAY,2019-10-21T09:12:33Z,varkor,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-21T22:20:56Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HOORAY,2019-10-21T22:20:59Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HEART,2019-10-22T01:37:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HOORAY,2019-10-22T01:48:19Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/65652,MERGED,2019-10-21T06:56:46Z,2019-10-21T19:46:24Z,Fix `canonicalize_const_var` leaking inference variables,skinny121,aa3d28f9a8e0fa2915e5321648d57af6c922799f,6,Fix `canonicalize_const_var` from leaking inference variables through it's type.,HOORAY,2019-10-26T07:47:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65653,MERGED,2019-10-21T08:33:50Z,2019-10-22T04:09:29Z,keep the root dir clean from debugging,RalfJung,ebc9a1ab10ff813664778e572eaeef4a9c6fcf4f,1,expand comment,THUMBS_UP,2019-10-21T09:25:45Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65653,MERGED,2019-10-21T08:33:50Z,2019-10-22T04:09:29Z,keep the root dir clean from debugging,RalfJung,ebc9a1ab10ff813664778e572eaeef4a9c6fcf4f,1,expand comment,THUMBS_UP,2019-10-21T15:44:13Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65653,MERGED,2019-10-21T08:33:50Z,2019-10-22T04:09:29Z,keep the root dir clean from debugging,RalfJung,ebc9a1ab10ff813664778e572eaeef4a9c6fcf4f,1,expand comment,THUMBS_UP,2019-10-21T19:49:15Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/65657,MERGED,2019-10-21T09:52:02Z,2019-10-24T07:16:13Z,Remove `InternedString`,nnethercote,08e2f05549de74022f2e596251ed88e784514640,4,Remove `InternedString`. By using `LocalInternedString` instead for the few remaining uses.,HEART,2019-10-21T18:34:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/65657,MERGED,2019-10-21T09:52:02Z,2019-10-24T07:16:13Z,Remove `InternedString`,nnethercote,08e2f05549de74022f2e596251ed88e784514640,4,Remove `InternedString`. By using `LocalInternedString` instead for the few remaining uses.,HEART,2019-10-21T20:52:58Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/65657,MERGED,2019-10-21T09:52:02Z,2019-10-24T07:16:13Z,Remove `InternedString`,nnethercote,08e2f05549de74022f2e596251ed88e784514640,4,Remove `InternedString`. By using `LocalInternedString` instead for the few remaining uses.,HEART,2019-10-23T20:35:27Z,estebank,NA https://github.com/rust-lang/rust/pull/65657,MERGED,2019-10-21T09:52:02Z,2019-10-24T07:16:13Z,Remove `InternedString`,nnethercote,08e2f05549de74022f2e596251ed88e784514640,4,Remove `InternedString`. By using `LocalInternedString` instead for the few remaining uses.,HEART,2019-10-25T09:21:07Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65672,MERGED,2019-10-21T20:26:31Z,2020-01-21T18:56:13Z,A single framework for gen-kill and generic dataflow problems,ecstatic-morse,7b4dca282a0bfad265238d04b22f7bdb0d498d74,3,Document all methods,ROCKET,2019-10-22T23:58:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65676,CLOSED,2019-10-21T23:30:39Z,2019-11-12T11:25:47Z,Use 1-based indexing for columns in debuginfo,ecstatic-morse,NA,NA,NA,HEART,2019-10-22T00:20:22Z,est31,NA https://github.com/rust-lang/rust/pull/65694,MERGED,2019-10-22T10:24:08Z,2019-11-10T02:15:54Z,[mir-opt] Implement pass to remove branches on uninhabited variants,wesleywiser,cbe2f6095a3a15318aa54362beae3535a7b049a2,4,Implement pass to remove branches on uninhabited variants,HEART,2019-10-22T11:07:02Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65696,MERGED,2019-10-22T13:01:48Z,2019-10-24T07:16:09Z,Fix an issue with const inference variables sticking around under Chalk + NLL,varkor,624e34a5d02d47b807bad3a81aa7ce0c088d2452,2,Account for const generalisation in nll_relate,HEART,2019-10-22T13:04:03Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65696,MERGED,2019-10-22T13:01:48Z,2019-10-24T07:16:09Z,Fix an issue with const inference variables sticking around under Chalk + NLL,varkor,624e34a5d02d47b807bad3a81aa7ce0c088d2452,2,Account for const generalisation in nll_relate,HEART,2019-10-22T15:07:47Z,skinny121,benjamin.lewis@seequent.com https://github.com/rust-lang/rust/pull/65696,MERGED,2019-10-22T13:01:48Z,2019-10-24T07:16:09Z,Fix an issue with const inference variables sticking around under Chalk + NLL,varkor,624e34a5d02d47b807bad3a81aa7ce0c088d2452,2,Account for const generalisation in nll_relate,HEART,2019-10-24T12:38:34Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-22T16:15:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-22T16:44:44Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-22T17:59:54Z,mati865,NA https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-22T18:45:30Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-22T21:31:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-10-29T10:41:53Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-11-06T19:00:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-11-20T17:44:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65703,CLOSED,2019-10-22T16:09:06Z,2019-12-05T20:28:34Z,rustc: Link LLVM directly into rustc again,alexcrichton,NA,NA,NA,HOORAY,2019-12-07T02:26:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/65705,MERGED,2019-10-22T16:49:22Z,2019-10-25T23:54:49Z,Add {String Vec}::into_raw_parts,shepmaster,6600cf604091a99bba990d41b93885b40c02a97d,3,Add {String Vec}::into_raw_parts,ROCKET,2019-10-22T20:57:30Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65705,MERGED,2019-10-22T16:49:22Z,2019-10-25T23:54:49Z,Add {String Vec}::into_raw_parts,shepmaster,6600cf604091a99bba990d41b93885b40c02a97d,3,Add {String Vec}::into_raw_parts,ROCKET,2019-10-22T23:48:16Z,est31,NA https://github.com/rust-lang/rust/pull/65705,MERGED,2019-10-22T16:49:22Z,2019-10-25T23:54:49Z,Add {String Vec}::into_raw_parts,shepmaster,6600cf604091a99bba990d41b93885b40c02a97d,3,Add {String Vec}::into_raw_parts,THUMBS_UP,2019-10-23T17:18:35Z,moshg,NA https://github.com/rust-lang/rust/pull/65705,MERGED,2019-10-22T16:49:22Z,2019-10-25T23:54:49Z,Add {String Vec}::into_raw_parts,shepmaster,6600cf604091a99bba990d41b93885b40c02a97d,3,Add {String Vec}::into_raw_parts,THUMBS_UP,2019-10-24T10:58:59Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/65705,MERGED,2019-10-22T16:49:22Z,2019-10-25T23:54:49Z,Add {String Vec}::into_raw_parts,shepmaster,6600cf604091a99bba990d41b93885b40c02a97d,3,Add {String Vec}::into_raw_parts,ROCKET,2019-11-05T16:41:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65706,MERGED,2019-10-22T17:15:32Z,2019-10-23T13:34:22Z,Add missing space in librustdoc,popzxc,8497f793d57d9d29432f31601068f7face3179c4,1,Add missing space in librustdoc,LAUGH,2019-10-22T21:01:58Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/65718,MERGED,2019-10-23T10:18:45Z,2019-11-01T15:11:24Z,rustc_codegen_ssa: introduce MIR VarDebugInfo but only for codegen.,eddyb,60a22665c8c6aff406ffa453965b011eca50ef0c,2,rustc_codegen_ssa: introduce MIR VarDebugInfo but only for codegen.,THUMBS_UP,2019-11-01T21:17:53Z,tmandry,NA https://github.com/rust-lang/rust/pull/65743,MERGED,2019-10-23T23:03:16Z,2019-10-26T19:36:11Z,rustc_typeck: don't record direct callees in generator_interior.,eddyb,d717806363e71332c1563d33ffa0aed97cbbcdbd,2,rustc_typeck: don't record direct callees in generator_interior.,THUMBS_UP,2019-10-24T00:47:20Z,tmandry,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-10-24T04:57:40Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-10-24T07:04:47Z,mati865,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-10-24T07:54:14Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-10-24T08:57:13Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-13T18:25:39Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-13T18:44:39Z,estebank,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-13T19:57:14Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-13T23:49:13Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-14T00:47:30Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-14T20:07:17Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-15T16:52:22Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-16T13:30:32Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-11-16T18:24:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-12-11T01:17:35Z,Virgiel,NA https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-12-11T18:07:22Z,ajyoon,andrew@nothing-to-say.org https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-12-11T19:35:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-12-11T20:20:37Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2019-12-13T13:52:41Z,PotHix,pothix@pothix.com https://github.com/rust-lang/rust/pull/65750,MERGED,2019-10-24T03:28:35Z,2019-11-07T03:54:52Z,Cheaper doc comments,nnethercote,eea6f23a0ed67fd8c6b8e1b02cda3628fee56b2f,25,Make doc comments cheaper with `AttrKind`. `AttrKind` is a new type with two variants `Normal` and `DocComment`. It's a big performance win (over 10% in some cases) because `DocComment` lets doc comments (which are common) be represented very cheaply. `Attribute` gets some new helper methods to ease the transition: - `has_name()`: check if the attribute name matches a single `Symbol`; for `DocComment` variants it succeeds if the symbol is `sym::doc`. - `is_doc_comment()`: check if it has a `DocComment` kind. - `{get unwrap}_normal_item()`: extract the item from a `Normal` variant; panic otherwise. Fixes #60935.,HEART,2020-02-12T11:53:14Z,bb010g,NA https://github.com/rust-lang/rust/pull/65761,MERGED,2019-10-24T13:19:06Z,2019-10-26T19:36:09Z,libsyntax: Enhance documentation of the AST module,popzxc,ae5203a1420013e88b212d882ccf53dfa64170ad,1,libsyntax: Document ast module Apply review suggestions Remove links in the module docs Flatten imports Apply review suggestions Remove useless comments Fix nits,HOORAY,2019-10-25T07:31:42Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65777,MERGED,2019-10-24T20:44:11Z,2019-10-27T19:40:47Z,Don't ICE for completely unexpandable `impl Trait` types,matthewjasper,0c05ed29fd26eb1a7cc5fa77c0fa41d940a78346,1,Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad ,THUMBS_UP,2019-11-05T16:09:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65779,MERGED,2019-10-24T22:32:43Z,2019-11-03T11:52:01Z,Highlight only relevant parts of type path in type errors,kevgrasso,2337bbb8a4131645e4a98ad81524703d76196f82,1,only relevant parts of type paths highlighted in E0308 type mismatch error message,HEART,2019-10-27T01:14:32Z,estebank,NA https://github.com/rust-lang/rust/pull/65800,MERGED,2019-10-25T09:19:24Z,2019-10-25T23:54:41Z,self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.,michaelwoerister,9c083068e31e8eb4d4f1d3f649354408d866574c,2,self-profiling: Switch query-blocking measurements to RAII-style API.,HOORAY,2019-10-25T11:41:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/65800,MERGED,2019-10-25T09:19:24Z,2019-10-25T23:54:41Z,self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.,michaelwoerister,9c083068e31e8eb4d4f1d3f649354408d866574c,2,self-profiling: Switch query-blocking measurements to RAII-style API.,HOORAY,2019-10-25T18:00:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/65806,MERGED,2019-10-25T12:16:28Z,2019-10-25T23:54:41Z,Add [T]::as_ptr_range() and [T]::as_mut_ptr_range().,m-ou-se,381c4425b7d0f428df6576f085ea03b1d42e06af,1,Fix slice::as_ptr_range doctest.,THUMBS_UP,2019-10-31T16:41:31Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/65806,MERGED,2019-10-25T12:16:28Z,2019-10-25T23:54:41Z,Add [T]::as_ptr_range() and [T]::as_mut_ptr_range().,m-ou-se,381c4425b7d0f428df6576f085ea03b1d42e06af,1,Fix slice::as_ptr_range doctest.,THUMBS_UP,2019-11-04T20:03:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65809,MERGED,2019-10-25T13:02:55Z,2019-10-29T07:38:24Z,Add new EFIAPI ABI,roblabla,1099826efa725b5de7833d42f2b96a53881e2118,1,Only run efiapi test on llvm 9.0+,HEART,2019-10-25T17:09:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65809,MERGED,2019-10-25T13:02:55Z,2019-10-29T07:38:24Z,Add new EFIAPI ABI,roblabla,1099826efa725b5de7833d42f2b96a53881e2118,1,Only run efiapi test on llvm 9.0+,HEART,2019-10-27T07:40:08Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/65809,MERGED,2019-10-25T13:02:55Z,2019-10-29T07:38:24Z,Add new EFIAPI ABI,roblabla,1099826efa725b5de7833d42f2b96a53881e2118,1,Only run efiapi test on llvm 9.0+,HEART,2019-10-29T16:11:11Z,al3xtjames,NA https://github.com/rust-lang/rust/pull/65811,CLOSED,2019-10-25T14:23:35Z,2019-11-30T06:16:03Z,Recover on `mut $p = $e;` and `var/auto $p = $e` suggesting `let` instead.,petar-dambovaliev,NA,NA,NA,THUMBS_UP,2019-10-26T22:22:58Z,estebank,NA https://github.com/rust-lang/rust/pull/65811,CLOSED,2019-10-25T14:23:35Z,2019-11-30T06:16:03Z,Recover on `mut $p = $e;` and `var/auto $p = $e` suggesting `let` instead.,petar-dambovaliev,NA,NA,NA,THUMBS_UP,2019-10-26T22:25:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-25T15:56:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-25T15:56:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-25T15:56:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-25T15:56:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-25T16:00:21Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-25T16:21:00Z,kennytm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-25T18:51:48Z,varkor,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-25T18:55:29Z,kjeremy,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-25T19:48:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-25T20:52:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-25T20:52:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-25T20:52:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-26T01:17:57Z,raviqqe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-26T01:17:58Z,raviqqe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-26T01:17:59Z,raviqqe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-26T01:57:50Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-26T17:44:31Z,darksv,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-26T17:44:32Z,darksv,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-26T17:44:32Z,darksv,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-26T17:44:35Z,darksv,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-27T06:18:47Z,pmarcelll,marcell.pardavi@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-28T10:12:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-28T10:12:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-28T10:12:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-29T07:56:58Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-29T12:14:20Z,CryZe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-29T12:14:20Z,CryZe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-29T12:14:22Z,CryZe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-29T12:14:22Z,CryZe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-29T15:05:25Z,RustyYato,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-29T15:22:18Z,andre-vm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-29T15:22:27Z,andre-vm,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-29T23:56:51Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-30T16:23:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-10-30T16:23:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-30T23:58:12Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-31T00:12:33Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-10-31T00:12:35Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-10-31T00:12:36Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-10-31T01:52:43Z,Gowee,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-11-06T10:00:07Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-11-08T01:23:12Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-11-08T02:40:05Z,wwylele,wwylele@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-11-13T06:58:09Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-12-06T23:49:52Z,bstrie,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-12-09T20:21:38Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2019-12-18T10:28:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2019-12-18T10:28:40Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-12-18T10:28:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2019-12-18T10:28:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-12-19T00:37:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2019-12-20T14:34:30Z,mkeeter,matt.j.keeter@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-01-12T23:57:37Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-01-26T21:04:13Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2020-02-14T04:12:26Z,danclive,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-02-14T04:12:27Z,danclive,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-02-14T04:12:27Z,danclive,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2020-02-14T04:12:27Z,danclive,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-03-05T18:54:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-03-05T18:54:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-03-09T09:52:44Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-03-20T09:16:37Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-04-07T09:11:52Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2020-04-15T13:41:08Z,LLFourn,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-05-02T16:18:05Z,mmaroti,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-05-12T03:02:46Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-05-25T09:13:42Z,mendess,pedro.mendes.26@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-06-11T13:23:25Z,Elrendio,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-06-11T22:34:28Z,HalidOdat,halidodat@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-06-16T03:51:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-06-16T11:48:30Z,weirane,gh@ruo-chen.wang https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-06-18T15:02:11Z,mcarton,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-06-28T20:30:55Z,Caduser2020,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2020-07-16T22:37:50Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-07-23T08:13:46Z,elichai,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-07-25T03:05:35Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-07-28T13:28:07Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-07-28T13:28:09Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-08-04T23:31:52Z,ItIsApachee,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-08-12T02:39:17Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-08-24T06:02:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2020-08-24T06:02:40Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-08-24T06:02:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-09-28T13:25:46Z,kaoet,kaoet.ibe@outlook.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-10-02T19:47:21Z,kangalioo,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-11-18T01:04:17Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-11-18T01:04:19Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2020-11-30T08:45:19Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-12-23T19:21:09Z,cynecx,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-12-28T11:19:34Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-12-28T23:18:52Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-12-30T15:59:41Z,branpk,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2020-12-30T15:59:43Z,branpk,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2021-01-07T10:43:06Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-01-07T10:43:09Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-01-07T10:43:10Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2021-01-07T10:43:10Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-01-08T11:34:30Z,Kestrer,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-01-09T22:56:50Z,TheButlah,thebutlah@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-11T16:28:10Z,carado,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-25T06:30:49Z,Krantz-XRF,Krantz.XRF@outlook.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-26T16:25:28Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-26T19:38:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-27T02:04:23Z,Throne3d,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-27T09:27:51Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-02-27T09:27:53Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-02-27T18:34:01Z,cdstanford,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-02-27T18:34:06Z,cdstanford,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-02T14:03:34Z,mcdenhoed,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-05T19:44:55Z,msmorgan,self@msmorgan.dev https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-13T12:11:16Z,ArturKovacs,kovacs.artur.barnabas@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-18T09:06:23Z,truchi,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-24T02:10:02Z,kupiakos,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-25T16:01:35Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2021-03-25T16:01:35Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-03-25T16:01:37Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2021-03-25T16:01:38Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-25T20:57:21Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-28T06:40:39Z,kpp,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-03-28T06:40:41Z,kpp,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-03-30T19:57:22Z,tiby312,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-04-04T15:58:44Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-04-09T15:09:39Z,aliassaf,ali.assaf.mail@gmail.com https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-04-14T04:22:31Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2021-04-14T04:22:32Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-04-16T12:01:34Z,btzy,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-05-31T01:54:09Z,nurmohammed840,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-07-06T04:51:46Z,Boiethios,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-09-01T18:01:34Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HOORAY,2021-09-01T18:01:35Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,HEART,2021-09-01T18:01:36Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65819,CLOSED,2019-10-25T15:50:06Z,2021-04-26T12:22:21Z,Add `IntoIterator` impl for arrays by value (`for [T; N]`),LukasKalbertodt,NA,NA,NA,ROCKET,2021-09-01T18:01:37Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65827,MERGED,2019-10-25T18:37:31Z,2019-11-03T15:14:25Z,Remove a loop which runs exactly once,AnthonyMikh,159d8a4154e9923e4890ce32d98e3ce5f43eafea,1,Remove a loop which runs exactly once,HOORAY,2019-10-25T20:27:55Z,estebank,NA https://github.com/rust-lang/rust/pull/65827,MERGED,2019-10-25T18:37:31Z,2019-11-03T15:14:25Z,Remove a loop which runs exactly once,AnthonyMikh,159d8a4154e9923e4890ce32d98e3ce5f43eafea,1,Remove a loop which runs exactly once,HOORAY,2019-10-25T23:06:05Z,kpp,NA https://github.com/rust-lang/rust/pull/65830,MERGED,2019-10-25T19:31:40Z,2019-11-06T12:45:50Z,Use ident.span instead of def_span in dead-code pass,Quantumplation,6186edeae52a95952e7da16a1f66d7352287427e,1,Use source_callee().is_some() to detect macros macro_backtrace() allocates a vector whereas source_callee() doesn't but indicates the same thing. Suggested by @estebank,HOORAY,2019-10-26T01:38:26Z,estebank,NA https://github.com/rust-lang/rust/pull/65830,MERGED,2019-10-25T19:31:40Z,2019-11-06T12:45:50Z,Use ident.span instead of def_span in dead-code pass,Quantumplation,6186edeae52a95952e7da16a1f66d7352287427e,1,Use source_callee().is_some() to detect macros macro_backtrace() allocates a vector whereas source_callee() doesn't but indicates the same thing. Suggested by @estebank,HOORAY,2019-10-26T02:50:34Z,martindevans,martindevans@gmail.com https://github.com/rust-lang/rust/pull/65830,MERGED,2019-10-25T19:31:40Z,2019-11-06T12:45:50Z,Use ident.span instead of def_span in dead-code pass,Quantumplation,6186edeae52a95952e7da16a1f66d7352287427e,1,Use source_callee().is_some() to detect macros macro_backtrace() allocates a vector whereas source_callee() doesn't but indicates the same thing. Suggested by @estebank,HOORAY,2019-11-06T13:01:15Z,alvinhochun,NA https://github.com/rust-lang/rust/pull/65837,CLOSED,2019-10-26T00:37:25Z,2020-01-06T10:13:19Z,rustc: rewrite the HirId validator to only check HIR map compactness.,eddyb,NA,NA,NA,HEART,2019-10-26T18:18:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/65837,CLOSED,2019-10-26T00:37:25Z,2020-01-06T10:13:19Z,rustc: rewrite the HirId validator to only check HIR map compactness.,eddyb,NA,NA,NA,HEART,2019-10-26T19:38:48Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/65838,MERGED,2019-10-26T01:31:17Z,2019-11-04T05:43:02Z,Reduce amount of errors given unclosed delimiter,estebank,454e2aa8c99850c9393fb2314e1a71da08120063,16,Do not complain about missing `fn main()` in some cases,THUMBS_UP,2019-11-03T20:43:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65838,MERGED,2019-10-26T01:31:17Z,2019-11-04T05:43:02Z,Reduce amount of errors given unclosed delimiter,estebank,454e2aa8c99850c9393fb2314e1a71da08120063,16,Do not complain about missing `fn main()` in some cases,THUMBS_UP,2019-11-16T18:25:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65839,MERGED,2019-10-26T06:17:41Z,2019-10-27T19:40:39Z,Clean up `check_consts` now that new promotion pass is implemented,ecstatic-morse,b93cdbce36b1a42c77b5f3f721d7d64dec80f8f3,3,Remove `QualifResolver` abstraction This is a relic from earlier attempts at dataflow-based const validation that attempted to do promotion at the same time. #63812 takes a different approach: `IsNotPromotable` is no longer a `Qualif` and is computed lazily instead of eagerly. As a result there's no need for an eager `TempPromotionResolver` and we can use the only implementer of `QualifResolver` directly instead of through a trait.,HEART,2019-10-26T18:18:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/65849,MERGED,2019-10-26T16:14:56Z,2019-10-28T07:38:54Z,librustc_lexer: Enhance documentation,popzxc,993b920032b17def5c773ed78b09890abb95854e,3,librustc_lexer: Enhance documentation Apply review suggestions Apply review suggestions,HEART,2019-10-26T17:43:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/65849,MERGED,2019-10-26T16:14:56Z,2019-10-28T07:38:54Z,librustc_lexer: Enhance documentation,popzxc,993b920032b17def5c773ed78b09890abb95854e,3,librustc_lexer: Enhance documentation Apply review suggestions Apply review suggestions,HEART,2019-10-27T08:50:24Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65857,MERGED,2019-10-26T23:03:06Z,2019-11-01T21:43:20Z,rustdoc: Resolve module-level doc references more locally,kinnison,c24a099e8b033470c12b2c5750b8dd76cf357477,2,rustdoc: Resolve module-level doc references more locally Module level docs should resolve intra-doc links as locally as possible. As such this commit alters the heuristic for finding intra-doc links such that we attempt to resolve names mentioned in *inner* documentation comments within the (sub-)module rather that from the context of its parent. Signed-off-by: Daniel Silverstone ,HOORAY,2019-10-28T20:59:35Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65858,MERGED,2019-10-26T23:45:05Z,2019-10-29T00:35:15Z,suggest `const_in_array_repeat_expression` flag,davidtwco,92b151287fcda73db8e95eeca8be97d66905626d,8,suggest `const_in_array_repeat_expression` flag This commit adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression. Signed-off-by: David Wood ,HEART,2019-10-26T23:50:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65858,MERGED,2019-10-26T23:45:05Z,2019-10-29T00:35:15Z,suggest `const_in_array_repeat_expression` flag,davidtwco,92b151287fcda73db8e95eeca8be97d66905626d,8,suggest `const_in_array_repeat_expression` flag This commit adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression. Signed-off-by: David Wood ,HEART,2019-10-27T23:20:25Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-10-28T18:51:28Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-06T07:17:32Z,Ralith,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-12T04:25:00Z,chmln,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-14T19:41:11Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-14T21:28:37Z,bstrie,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-15T11:36:36Z,Virgiel,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-21T09:31:18Z,alexlapa,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-21T14:06:39Z,librelois,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2019-11-26T09:51:30Z,kellytk,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,ROCKET,2019-11-26T09:51:36Z,kellytk,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,HOORAY,2019-11-26T09:51:42Z,kellytk,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2020-01-02T10:49:00Z,sudhakar,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2020-01-04T16:32:52Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,HOORAY,2020-01-04T16:32:54Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,ROCKET,2020-01-04T16:32:56Z,Lokathor,NA https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2020-01-10T15:08:14Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/65875,CLOSED,2019-10-27T18:49:24Z,2020-01-10T08:18:14Z,Add a minimal Futures executor,Matthias247,NA,NA,NA,THUMBS_UP,2020-06-29T14:31:29Z,hu55a1n1,sufialhussaini@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-10-28T09:38:24Z,weiznich,NA https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-10-29T02:42:07Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-10-29T14:03:24Z,omerbenamram,omerbenamram@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-10-29T19:11:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-11-09T11:49:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-11-12T14:45:09Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-11-13T20:05:17Z,DianaNites,NA https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2019-11-16T18:31:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2020-01-06T13:30:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2020-04-11T16:54:08Z,bluss,NA https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,THUMBS_UP,2020-04-29T05:01:31Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65879,MERGED,2019-10-27T20:01:17Z,2019-11-09T09:33:41Z,Stabilize the `re_rebalance_coherence` feature,ohadravid,3e0759dc0565c3b8e5ca0ab3ace15ae7e91b6ffd,1,Push `re_rebalance_coherence` to 1.41 Co-Authored-By: Mazdak Farrokhzad ,HOORAY,2022-02-05T18:52:36Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-02T12:41:17Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-02T18:31:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-08T14:31:47Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-12T22:10:22Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-12T22:39:23Z,krdln,NA https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-12T23:25:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,HOORAY,2019-12-13T01:28:37Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/65881,MERGED,2019-10-27T23:30:17Z,2019-12-08T00:27:06Z,Implement #[track_caller] attribute. (RFC 2091 4/N),anp,15d1f7cffdc0b111123a6d34a356eae95af04676,1,Add additional layer of #[track_caller] to test avoid const prop.,THUMBS_UP,2019-12-13T03:25:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65884,MERGED,2019-10-28T03:31:28Z,2019-11-07T11:31:06Z,syntax: ABI-oblivious grammar,Centril,55f76cdb2f4d01cf87e47148c706c53a129fa45e,19,syntax: use distinct FloatTy from rustc_target. We also sever syntax's dependency on rustc_target as a result. This should slightly improve pipe-lining. Moreover some cleanup is done in related code.,THUMBS_UP,2019-10-28T04:32:19Z,xen0n,NA https://github.com/rust-lang/rust/pull/65884,MERGED,2019-10-28T03:31:28Z,2019-11-07T11:31:06Z,syntax: ABI-oblivious grammar,Centril,55f76cdb2f4d01cf87e47148c706c53a129fa45e,19,syntax: use distinct FloatTy from rustc_target. We also sever syntax's dependency on rustc_target as a result. This should slightly improve pipe-lining. Moreover some cleanup is done in related code.,THUMBS_UP,2019-11-03T21:58:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65884,MERGED,2019-10-28T03:31:28Z,2019-11-07T11:31:06Z,syntax: ABI-oblivious grammar,Centril,55f76cdb2f4d01cf87e47148c706c53a129fa45e,19,syntax: use distinct FloatTy from rustc_target. We also sever syntax's dependency on rustc_target as a result. This should slightly improve pipe-lining. Moreover some cleanup is done in related code.,THUMBS_UP,2019-11-20T17:06:40Z,jplatte,NA https://github.com/rust-lang/rust/pull/65892,MERGED,2019-10-28T11:43:01Z,2019-11-06T05:55:02Z,Remove `PartialEq` and `Eq` from the `SpecialDerives`.,pnkfelix,99243616cc0c096e1d35b7c60d0b0ca6fc10fd48,2,Review feedback: alpha-rename field from `copy_derives` to `containers_derving_copy`.,HEART,2019-10-28T19:30:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/65894,CLOSED,2019-10-28T13:41:18Z,2020-02-07T16:58:28Z,Update pulldown-cmark version,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2022-01-28T23:48:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/65900,MERGED,2019-10-28T18:46:27Z,2019-10-29T22:27:07Z,proc_macro: clean up bridge::client::__run_expand{1 2} a bit.,eddyb,b58634454f2a6def88f3197261a458e208f77f49,1,proc_macro: don't use Rust ABI fn pointers in a C ABI fn signature.,HEART,2019-10-28T19:29:02Z,panaman67,NA https://github.com/rust-lang/rust/pull/65912,MERGED,2019-10-28T21:33:42Z,2020-01-11T10:16:15Z,Point at the span for the definition of crate foreign ADTs,estebank,38a3506c451d097ed19263b3734421b3e5ee5bfa,18,Ignore platforms that can't point to std,HEART,2019-10-29T03:08:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/65916,MERGED,2019-10-29T01:15:34Z,2019-11-08T01:15:24Z,syntax: move stuff around,Centril,cc9c139694389c8df158640d4bcc20a2fe31f1ea,4,move syntax::{parse::literal -> util::literal},HEART,2019-10-31T17:37:44Z,estebank,NA https://github.com/rust-lang/rust/pull/65927,MERGED,2019-10-29T11:11:15Z,2019-10-29T14:53:07Z,Don't use eval_always for miri queries used from codegen.,eddyb,beb06aed9af27fbf192d772e39ffe0421c50e02e,1,Don't use eval_always for miri queries used from codegen.,THUMBS_UP,2019-10-29T11:45:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/65927,MERGED,2019-10-29T11:11:15Z,2019-10-29T14:53:07Z,Don't use eval_always for miri queries used from codegen.,eddyb,beb06aed9af27fbf192d772e39ffe0421c50e02e,1,Don't use eval_always for miri queries used from codegen.,THUMBS_UP,2019-10-29T14:53:00Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/65927,MERGED,2019-10-29T11:11:15Z,2019-10-29T14:53:07Z,Don't use eval_always for miri queries used from codegen.,eddyb,beb06aed9af27fbf192d772e39ffe0421c50e02e,1,Don't use eval_always for miri queries used from codegen.,THUMBS_UP,2019-11-11T21:52:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65933,MERGED,2019-10-29T15:07:16Z,2019-11-11T22:33:31Z,Use ptr::drop_in_place for VecDeque::truncate and VecDeque::clear,crgl,27e0ab578cc0fc4c72da54bbeb42c0c44d848207,1,Use truncate(0) in VecDeque clear,THUMBS_UP,2019-10-30T18:11:58Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/65933,MERGED,2019-10-29T15:07:16Z,2019-11-11T22:33:31Z,Use ptr::drop_in_place for VecDeque::truncate and VecDeque::clear,crgl,27e0ab578cc0fc4c72da54bbeb42c0c44d848207,1,Use truncate(0) in VecDeque clear,CONFUSED,2019-11-08T07:08:10Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/65933,MERGED,2019-10-29T15:07:16Z,2019-11-11T22:33:31Z,Use ptr::drop_in_place for VecDeque::truncate and VecDeque::clear,crgl,27e0ab578cc0fc4c72da54bbeb42c0c44d848207,1,Use truncate(0) in VecDeque clear,THUMBS_UP,2019-11-16T18:28:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/65937,CLOSED,2019-10-29T15:49:09Z,2019-11-16T06:37:04Z,Add more context to `async fn` trait error. Suggest `async-trait`.,jafern14,NA,NA,NA,THUMBS_UP,2019-10-29T17:04:28Z,estebank,NA https://github.com/rust-lang/rust/pull/65938,MERGED,2019-10-29T15:58:03Z,2019-11-05T09:13:10Z,rustc_target: rename {Fn Arg}Type to {Fn Arg}Abi.,eddyb,8b06209c2883906427978305b854faa90e61a5c0,3,rustc_codegen_ssa: rename FnTypeLlvmExt to FnAbiLlvmExt.,THUMBS_UP,2019-10-29T16:17:51Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/65939,MERGED,2019-10-29T16:05:17Z,2019-12-22T16:53:25Z,Enable incremental rustfmt adoption,anp,b9e4174d8cf03fdcd0f9f128422b1f565d6b6607,1,Do not run if rustfmt.toml does not exist distcheck (and generally publishing tarballs) will not package rustfmt.toml and we for now still support running tidy etc in those tarballs.,THUMBS_UP,2019-10-31T00:07:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/65939,MERGED,2019-10-29T16:05:17Z,2019-12-22T16:53:25Z,Enable incremental rustfmt adoption,anp,b9e4174d8cf03fdcd0f9f128422b1f565d6b6607,1,Do not run if rustfmt.toml does not exist distcheck (and generally publishing tarballs) will not package rustfmt.toml and we for now still support running tidy etc in those tarballs.,HEART,2019-11-05T02:04:15Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/65939,MERGED,2019-10-29T16:05:17Z,2019-12-22T16:53:25Z,Enable incremental rustfmt adoption,anp,b9e4174d8cf03fdcd0f9f128422b1f565d6b6607,1,Do not run if rustfmt.toml does not exist distcheck (and generally publishing tarballs) will not package rustfmt.toml and we for now still support running tidy etc in those tarballs.,THUMBS_UP,2019-11-28T09:46:43Z,elichai,NA https://github.com/rust-lang/rust/pull/65939,MERGED,2019-10-29T16:05:17Z,2019-12-22T16:53:25Z,Enable incremental rustfmt adoption,anp,b9e4174d8cf03fdcd0f9f128422b1f565d6b6607,1,Do not run if rustfmt.toml does not exist distcheck (and generally publishing tarballs) will not package rustfmt.toml and we for now still support running tidy etc in those tarballs.,THUMBS_UP,2019-12-23T17:36:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/65945,MERGED,2019-10-29T19:42:49Z,2019-11-07T07:09:41Z,Optimize long-linker-command-line test,tmiasko,6bbe162c4d83f98e77e6646dfa95e0f9957dd257,1,Optimize long-linker-command-line test Replace O(n^3) text matching with inexpensive hash set lookups. On my machine this reduces the total runtime of complete run-make-fulldeps suite from roughly 75 seconds to 45 seconds.,HEART,2019-10-29T20:38:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/65947,MERGED,2019-10-29T20:36:21Z,2019-12-04T11:23:02Z,"rustc: split FnAbi's into definitions/direct calls (""of_instance"") and indirect calls (""of_fn_ptr"").",eddyb,c2f4c57296f0d929618baed0b0d6eb594abf01eb,2,rustc: add docs to FnAbi::{of_fn_ptr of_instance} and InstanceDef::Virtual.,HEART,2019-10-29T20:38:24Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/65951,MERGED,2019-10-30T00:47:11Z,2019-12-14T02:08:58Z,Point at method call when type annotations are needed,estebank,da023c0c6f3cdc72d72ef047c2dadb1a59c646df,41,Add more context for type parameters,HOORAY,2019-12-13T09:48:43Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/65951,MERGED,2019-10-30T00:47:11Z,2019-12-14T02:08:58Z,Point at method call when type annotations are needed,estebank,da023c0c6f3cdc72d72ef047c2dadb1a59c646df,41,Add more context for type parameters,HOORAY,2019-12-14T04:08:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65953,MERGED,2019-10-30T04:44:51Z,2019-11-05T23:43:20Z,Allow specifying LLVM's MCTargetOptions::ABIName in target specification files,archshift,539de439ad6f32e9a9a8a593299072a106786890,4,"Allow specifying key ""llvm-abiname"" in target specification This addresses #65024 as it allows RISC-V target specification files to set ""llvm-abiname"": ""lp64d"". In general it is useful for the programmer to be able to set this codegen parameter which other languages usually expose under a compiler argument like ""-mabi="".",HEART,2019-11-03T13:46:05Z,laanwj,NA https://github.com/rust-lang/rust/pull/65954,CLOSED,2019-10-30T05:20:55Z,2019-11-09T09:38:37Z,Make `time::Instant::actually_monotonic()` a const fn.,shamiao,NA,NA,NA,CONFUSED,2019-10-30T07:15:34Z,kennytm,NA https://github.com/rust-lang/rust/pull/65955,MERGED,2019-10-30T08:15:06Z,2019-10-31T06:04:30Z,ci: revert msys2 ca-certificates hack,pietroalbini,48d6510f6f0b44d4cdd3ebd0699d7ad703de6169,2,ci: revert msys2 ca-certificates hack The hack was added because upstream msys2 broke the ca-certificates package but since then it has been fixed. This reverts CI to use the upstream package.,HEART,2019-10-30T17:20:53Z,panaman67,NA https://github.com/rust-lang/rust/pull/65960,MERGED,2019-10-30T12:17:20Z,2019-11-01T21:43:12Z,doc: reword iter module example and mention other methods,tesuji,bb1f4c47c1086e9290461676e9779fb0901f9da0,1,doc: reword iter module example and mention other methods,HEART,2019-10-31T03:01:30Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/65966,CLOSED,2019-10-30T14:52:41Z,2019-11-03T12:23:12Z,Adjust close delim span,guanqun,NA,NA,NA,HEART,2019-10-30T17:05:34Z,estebank,NA https://github.com/rust-lang/rust/pull/65973,MERGED,2019-10-30T16:59:58Z,2019-11-06T09:35:10Z,caller_location: point to macro invocation sites like file!/line! and use in core::panic!.,eddyb,49f9626a553c0ff191aa96912f4880f99d0a8716,1,caller_location: use in core::panic!.,HEART,2019-10-30T17:06:07Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/65973,MERGED,2019-10-30T16:59:58Z,2019-11-06T09:35:10Z,caller_location: point to macro invocation sites like file!/line! and use in core::panic!.,eddyb,49f9626a553c0ff191aa96912f4880f99d0a8716,1,caller_location: use in core::panic!.,HEART,2019-11-01T22:46:48Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/65977,MERGED,2019-10-30T18:39:02Z,2019-11-01T21:43:09Z,Fix incorrect diagnostics for expected type in E0271 with an associated type,ohadravid,8bb54501280eba814b31628db1088ca4f03638e1,11,Fix incorrect diagnostics for expected type in E0271 with an associated type,HEART,2019-11-01T04:31:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/65977,MERGED,2019-10-30T18:39:02Z,2019-11-01T21:43:09Z,Fix incorrect diagnostics for expected type in E0271 with an associated type,ohadravid,8bb54501280eba814b31628db1088ca4f03638e1,11,Fix incorrect diagnostics for expected type in E0271 with an associated type,HEART,2019-12-17T23:20:24Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/65977,MERGED,2019-10-30T18:39:02Z,2019-11-01T21:43:09Z,Fix incorrect diagnostics for expected type in E0271 with an associated type,ohadravid,8bb54501280eba814b31628db1088ca4f03638e1,11,Fix incorrect diagnostics for expected type in E0271 with an associated type,HEART,2019-12-18T05:05:27Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/65989,MERGED,2019-10-31T01:24:19Z,2020-07-31T20:09:35Z,Normalize all opaque types when converting ParamEnv to Reveal::All,Aaron1011,6e87bacd37539b7e7cd75152dffd225047fa983a,19,Auto merge of #65989 - Aaron1011:fix/normalize-param-env r=nikomatsakis Normalize all opaque types when converting ParamEnv to Reveal::All When we normalize a type using a ParamEnv with a reveal mode of RevealMode::All we will normalize opaque types to their underlying types (e.g. `type MyOpaque = impl Foo` -> `StructThatImplsFoo`). However the ParamEnv may still have predicates referring to the un-normalized opaque type (e.g. `>`). This can cause trait projection to fail since a type containing normalized opaque types will not match up with the un-normalized type in the `ParamEnv`. To fix this we now explicitly normalize all opaque types in caller_bounds of a `ParamEnv` when changing its mode to `RevealMode::All`. This ensures that all predicatse will refer to the underlying types of any opaque types involved allowing them to be matched up properly during projection. To reflect the fact that normalization is occuring `ParamEnv::with_reveal_all` is renamed to `ParamEnv::with_reveal_all_normalized` Fixes #65918,THUMBS_UP,2019-11-01T10:26:38Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/65989,MERGED,2019-10-31T01:24:19Z,2020-07-31T20:09:35Z,Normalize all opaque types when converting ParamEnv to Reveal::All,Aaron1011,6e87bacd37539b7e7cd75152dffd225047fa983a,19,Auto merge of #65989 - Aaron1011:fix/normalize-param-env r=nikomatsakis Normalize all opaque types when converting ParamEnv to Reveal::All When we normalize a type using a ParamEnv with a reveal mode of RevealMode::All we will normalize opaque types to their underlying types (e.g. `type MyOpaque = impl Foo` -> `StructThatImplsFoo`). However the ParamEnv may still have predicates referring to the un-normalized opaque type (e.g. `>`). This can cause trait projection to fail since a type containing normalized opaque types will not match up with the un-normalized type in the `ParamEnv`. To fix this we now explicitly normalize all opaque types in caller_bounds of a `ParamEnv` when changing its mode to `RevealMode::All`. This ensures that all predicatse will refer to the underlying types of any opaque types involved allowing them to be matched up properly during projection. To reflect the fact that normalization is occuring `ParamEnv::with_reveal_all` is renamed to `ParamEnv::with_reveal_all_normalized` Fixes #65918,THUMBS_UP,2019-12-27T22:06:27Z,wdanilo,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,HOORAY,2019-11-01T17:36:58Z,cramertj,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,THUMBS_UP,2019-11-01T17:36:59Z,cramertj,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,HEART,2019-11-01T17:37:02Z,cramertj,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,THUMBS_UP,2019-11-01T17:38:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,HOORAY,2019-11-01T17:38:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,HEART,2019-11-01T17:38:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,HEART,2019-11-02T21:46:48Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,THUMBS_UP,2019-11-03T22:24:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66017,MERGED,2019-11-01T11:10:58Z,2019-11-07T11:30:59Z,Add future incompatibility lint for `array.into_iter()`,LukasKalbertodt,761ba89ffd73498c3014d3b43b5bc0b4f592a284,1,Replace `array.into_iter()` with `iter()` in `libtest/tests.rs`,THUMBS_UP,2019-11-04T07:40:32Z,taiki-e,NA https://github.com/rust-lang/rust/pull/66025,MERGED,2019-11-01T20:41:43Z,2019-11-05T23:43:14Z,`Span` cannot represent `span.hi < span.lo`,petrochenkov,ecaa96418bfff378a229ebf79d14f9e3c312cf78,5,`Span` cannot represent `span.hi < span.lo` So we can remove the corresponding checks from various code,THUMBS_UP,2019-11-02T15:01:11Z,est31,NA https://github.com/rust-lang/rust/pull/66042,MERGED,2019-11-02T10:58:41Z,2019-11-05T12:46:47Z,Suggest correct code when encountering an incorrect trait bound referencing the current trait,ohadravid,8c909344ed19c9f9a51f82c8e270ded09671fd8b,3,Suggest more likely code when encountering an incorrect assoc item referencing the current trait,HEART,2019-11-03T18:02:04Z,estebank,NA https://github.com/rust-lang/rust/pull/66042,MERGED,2019-11-02T10:58:41Z,2019-11-05T12:46:47Z,Suggest correct code when encountering an incorrect trait bound referencing the current trait,ohadravid,8c909344ed19c9f9a51f82c8e270ded09671fd8b,3,Suggest more likely code when encountering an incorrect assoc item referencing the current trait,HEART,2019-11-03T18:19:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66042,MERGED,2019-11-02T10:58:41Z,2019-11-05T12:46:47Z,Suggest correct code when encountering an incorrect trait bound referencing the current trait,ohadravid,8c909344ed19c9f9a51f82c8e270ded09671fd8b,3,Suggest more likely code when encountering an incorrect assoc item referencing the current trait,HEART,2019-11-04T09:47:24Z,omerbenamram,omerbenamram@gmail.com https://github.com/rust-lang/rust/pull/66044,MERGED,2019-11-02T16:53:34Z,2019-11-07T07:09:35Z,Improve uninit/zeroed lint,RalfJung,bb37d0078750b760f013bfa706fe19d4d823b8df,2,more robust method checking through DefId and diagnostic_item,HEART,2019-11-02T20:36:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/66044,MERGED,2019-11-02T16:53:34Z,2019-11-07T07:09:35Z,Improve uninit/zeroed lint,RalfJung,bb37d0078750b760f013bfa706fe19d4d823b8df,2,more robust method checking through DefId and diagnostic_item,HEART,2019-11-03T05:51:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66044,MERGED,2019-11-02T16:53:34Z,2019-11-07T07:09:35Z,Improve uninit/zeroed lint,RalfJung,bb37d0078750b760f013bfa706fe19d4d823b8df,2,more robust method checking through DefId and diagnostic_item,HEART,2019-11-04T21:48:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66044,MERGED,2019-11-02T16:53:34Z,2019-11-07T07:09:35Z,Improve uninit/zeroed lint,RalfJung,bb37d0078750b760f013bfa706fe19d4d823b8df,2,more robust method checking through DefId and diagnostic_item,HEART,2019-11-06T08:30:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66045,MERGED,2019-11-02T18:21:41Z,2020-01-10T23:27:18Z,Add method Result::into_ok,mzabaluev,6f0672c08b7609c7ed77245a3feea3040221b804,2,Rename Result::unwrap_infallible to into_ok,THUMBS_UP,2019-11-02T18:28:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66045,MERGED,2019-11-02T18:21:41Z,2020-01-10T23:27:18Z,Add method Result::into_ok,mzabaluev,6f0672c08b7609c7ed77245a3feea3040221b804,2,Rename Result::unwrap_infallible to into_ok,THUMBS_UP,2019-11-28T08:58:58Z,CodeSandwich,NA https://github.com/rust-lang/rust/pull/66045,MERGED,2019-11-02T18:21:41Z,2020-01-10T23:27:18Z,Add method Result::into_ok,mzabaluev,6f0672c08b7609c7ed77245a3feea3040221b804,2,Rename Result::unwrap_infallible to into_ok,THUMBS_UP,2019-12-05T00:10:04Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/66045,MERGED,2019-11-02T18:21:41Z,2020-01-10T23:27:18Z,Add method Result::into_ok,mzabaluev,6f0672c08b7609c7ed77245a3feea3040221b804,2,Rename Result::unwrap_infallible to into_ok,CONFUSED,2019-12-05T04:57:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66049,MERGED,2019-11-02T22:23:17Z,2019-11-08T07:55:47Z,consistent handling of missing sysroot spans,RalfJung,18089689c0d06264f82b1d373e98a3d3a31c409a,61,also adjust ignore in generated tests,THUMBS_UP,2019-11-04T18:03:43Z,estebank,NA https://github.com/rust-lang/rust/pull/66056,MERGED,2019-11-03T14:56:52Z,2019-11-08T07:55:46Z,rustc_metadata: Some reorganization of the module structure,petrochenkov,5eb1cf16197a8cc38d18e81338f4c148e14ee36f,9,rustc_metadata: Rename `schema` to `rmeta` And change `rmeta.rs` to `rmeta/mod.rs`,THUMBS_UP,2019-11-03T16:03:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66059,MERGED,2019-11-03T16:29:08Z,2020-03-11T12:50:55Z,mem::zeroed/uninit: panic on types that do not permit zero-initialization,RalfJung,a7c2eef2aeb23f52efc4a4bfd240292d43a61798,10,Rollup merge of #66059 - RalfJung:panic-on-non-zero r=eddyb mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc https://github.com/rust-lang/rust/issues/62825 Also see [this summary comment](https://github.com/rust-lang/rust/pull/66059#issuecomment-586734747),HEART,2020-01-11T17:27:36Z,est31,NA https://github.com/rust-lang/rust/pull/66059,MERGED,2019-11-03T16:29:08Z,2020-03-11T12:50:55Z,mem::zeroed/uninit: panic on types that do not permit zero-initialization,RalfJung,a7c2eef2aeb23f52efc4a4bfd240292d43a61798,10,Rollup merge of #66059 - RalfJung:panic-on-non-zero r=eddyb mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc https://github.com/rust-lang/rust/issues/62825 Also see [this summary comment](https://github.com/rust-lang/rust/pull/66059#issuecomment-586734747),HEART,2020-03-20T10:36:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66059,MERGED,2019-11-03T16:29:08Z,2020-03-11T12:50:55Z,mem::zeroed/uninit: panic on types that do not permit zero-initialization,RalfJung,a7c2eef2aeb23f52efc4a4bfd240292d43a61798,10,Rollup merge of #66059 - RalfJung:panic-on-non-zero r=eddyb mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc https://github.com/rust-lang/rust/issues/62825 Also see [this summary comment](https://github.com/rust-lang/rust/pull/66059#issuecomment-586734747),HEART,2020-06-04T21:17:30Z,yerke,NA https://github.com/rust-lang/rust/pull/66059,MERGED,2019-11-03T16:29:08Z,2020-03-11T12:50:55Z,mem::zeroed/uninit: panic on types that do not permit zero-initialization,RalfJung,a7c2eef2aeb23f52efc4a4bfd240292d43a61798,10,Rollup merge of #66059 - RalfJung:panic-on-non-zero r=eddyb mem::zeroed/uninit: panic on types that do not permit zero-initialization r? @eddyb @oli-obk Cc https://github.com/rust-lang/rust/issues/62825 Also see [this summary comment](https://github.com/rust-lang/rust/pull/66059#issuecomment-586734747),HEART,2020-06-05T07:42:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-10T04:39:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-12T02:38:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-12T03:42:20Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-13T07:33:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-13T15:03:34Z,mati865,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-13T16:01:50Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-19T07:52:32Z,lnicola,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-19T07:56:51Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-19T10:33:25Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-11-27T20:26:16Z,chrish42,NA https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-12-01T16:14:38Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-12-02T20:19:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-12-02T23:41:04Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-12-03T02:38:04Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/66074,MERGED,2019-11-04T03:17:24Z,2019-11-19T07:50:20Z,[mir-opt] Turn on the `ConstProp` pass by default,wesleywiser,db5fc10c21f7ee8ef7649628ae37e6481b8ca14c,4,[mir-opt] Turn on the `ConstProp` pass by default perf.rlo shows that running the `ConstProp` pass results in across-the-board wins regardless of debug or opt complilation mode. As a result we're turning it on to get the compile time benefits. `ConstProp` doesn't currently intern the memory used by its `Machine` so we can't yet propagate allocations which is why `ConstProp::should_const_prop()` checks if the value being propagated is a scalar or not.,HOORAY,2019-12-03T09:04:09Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/66076,MERGED,2019-11-04T08:51:38Z,2019-11-07T07:09:32Z,HIR docs: mention how to resolve method paths,RalfJung,f2ed1e661e69dc463aa18ef3912501e1dde936b8,1,Fix markdown link Co-Authored-By: Oliver Scherer ,HEART,2019-11-04T21:46:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66089,MERGED,2019-11-04T15:41:20Z,2019-11-04T19:44:20Z,[stable] 1.39.0 release,Mark-Simulacrum,4810c2515e4e08b9d69247c9d51ce2a8c0057e51,1,1.39.0 release,HOORAY,2019-11-07T05:03:29Z,remram44,remi@rampin.org https://github.com/rust-lang/rust/pull/66089,MERGED,2019-11-04T15:41:20Z,2019-11-04T19:44:20Z,[stable] 1.39.0 release,Mark-Simulacrum,4810c2515e4e08b9d69247c9d51ce2a8c0057e51,1,1.39.0 release,HOORAY,2019-11-07T10:04:43Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/66089,MERGED,2019-11-04T15:41:20Z,2019-11-04T19:44:20Z,[stable] 1.39.0 release,Mark-Simulacrum,4810c2515e4e08b9d69247c9d51ce2a8c0057e51,1,1.39.0 release,HOORAY,2019-11-07T13:27:58Z,dutchmartin,NA https://github.com/rust-lang/rust/pull/66089,MERGED,2019-11-04T15:41:20Z,2019-11-04T19:44:20Z,[stable] 1.39.0 release,Mark-Simulacrum,4810c2515e4e08b9d69247c9d51ce2a8c0057e51,1,1.39.0 release,HOORAY,2019-11-07T13:42:25Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HEART,2019-11-05T09:47:31Z,varkor,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HEART,2019-11-05T10:41:01Z,jplatte,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2019-11-06T15:49:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2019-11-09T16:08:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2019-11-11T15:26:03Z,varkor,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2019-11-20T09:31:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2020-01-02T15:32:45Z,lnicola,NA https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2020-01-02T19:52:42Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/66104,MERGED,2019-11-05T05:19:22Z,2019-11-20T06:34:34Z,Generic arg disambiguation,yodaldevoid,0207a15fa14c2c05e33acac1abd4604fce1f346a,4,test: Update tests with fallout of changes The error messages of the two tests effected degraded in quality. The errors no longer suggest types in other modules as they now assume that the arguments are const args not type args.,HOORAY,2020-06-22T14:03:44Z,frol,NA https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-05T10:25:04Z,iduartgomez,iduartgomez@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-05T11:56:20Z,ariesdevil,ariesdevil77@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HOORAY,2019-11-05T12:09:02Z,MaximFedorov,NA https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-06T01:24:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-06T01:55:32Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HOORAY,2019-11-06T01:55:33Z,Rufflewind,NA https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HOORAY,2019-11-06T02:20:41Z,rajasekarv,rajasekar3eg@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-06T02:20:49Z,rajasekarv,rajasekar3eg@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HEART,2019-11-06T21:07:40Z,iliazintchenko,iliazin@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-06T21:07:43Z,iliazintchenko,iliazin@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HOORAY,2019-11-06T21:07:47Z,iliazintchenko,iliazin@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2019-12-09T21:13:24Z,carado,NA https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2020-01-28T08:48:17Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HEART,2020-04-13T12:10:23Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HOORAY,2020-09-19T07:59:52Z,ariesdevil,ariesdevil77@gmail.com https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,THUMBS_UP,2021-04-27T19:32:56Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/66113,CLOSED,2019-11-05T10:12:36Z,2020-02-28T01:31:42Z,[WIP] Make a table of trait object type_ids and vtable pointers available to programs,alecmocatta,NA,NA,NA,HEART,2022-04-27T21:05:22Z,ritchie46,ritchie46@gmail.com https://github.com/rust-lang/rust/pull/66115,MERGED,2019-11-05T11:51:27Z,2019-11-06T05:54:40Z,"rustc: remove ""GlobalMetaData"" dead code from hir::map::definitions.",eddyb,25953321c00cc07cee0d414716a344357524d32b,29,"rustc: remove ""GlobalMetaData"" dead code from hir::map::definitions.",HEART,2019-11-05T17:15:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/66115,MERGED,2019-11-05T11:51:27Z,2019-11-06T05:54:40Z,"rustc: remove ""GlobalMetaData"" dead code from hir::map::definitions.",eddyb,25953321c00cc07cee0d414716a344357524d32b,29,"rustc: remove ""GlobalMetaData"" dead code from hir::map::definitions.",HEART,2019-11-05T23:27:22Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66122,CLOSED,2019-11-05T13:51:58Z,2019-11-26T12:37:46Z,Tweak where_clauses_object_safety lint to allow auto traits,alecmocatta,NA,NA,NA,THUMBS_UP,2019-11-05T20:45:08Z,rajasekarv,rajasekar3eg@gmail.com https://github.com/rust-lang/rust/pull/66128,MERGED,2019-11-05T18:29:30Z,2019-11-27T03:56:23Z,alloc: Add new_zeroed() versions like new_uninit().,emilio,b12e142bc5a6f6312ce2fd3305f449d03410a37a,3,alloc: Add new_zeroed() versions like new_uninit(). MaybeUninit has both uninit() and zeroed() it seems reasonable to have the same surface on Box/Rc/Arc. Needs tests.,THUMBS_UP,2019-12-23T20:04:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66129,MERGED,2019-11-05T18:33:54Z,2019-11-12T08:23:50Z,Refactor slice pattern usefulness checking,Nadrieril,fd9921b41c4354aaf790c2bc0393f818034100d0,1,tidy,HEART,2019-11-05T18:46:16Z,estebank,NA https://github.com/rust-lang/rust/pull/66129,MERGED,2019-11-05T18:33:54Z,2019-11-12T08:23:50Z,Refactor slice pattern usefulness checking,Nadrieril,fd9921b41c4354aaf790c2bc0393f818034100d0,1,tidy,HEART,2019-11-05T19:09:55Z,declanvk,NA https://github.com/rust-lang/rust/pull/66129,MERGED,2019-11-05T18:33:54Z,2019-11-12T08:23:50Z,Refactor slice pattern usefulness checking,Nadrieril,fd9921b41c4354aaf790c2bc0393f818034100d0,1,tidy,HEART,2019-11-06T07:17:00Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/66129,MERGED,2019-11-05T18:33:54Z,2019-11-12T08:23:50Z,Refactor slice pattern usefulness checking,Nadrieril,fd9921b41c4354aaf790c2bc0393f818034100d0,1,tidy,HEART,2019-11-06T10:21:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/66131,MERGED,2019-11-05T19:09:45Z,2020-03-19T12:22:58Z,rustc: use LocalDefId instead of DefIndex where possible.,eddyb,3c6f982cc908aacc39c3ac97f31c989f81cc213c,49,"Auto merge of #66131 - eddyb:local-def-id r=petrochenkov rustc: use LocalDefId instead of DefIndex where possible. That is wherever `DefIndex` always referred to a ""def"" in the local crate I replaced it with `LocalDefId`. While `LocalDefId` already existed it wasn't used a lot but I hope I'm on the right track. Unresolved questions: * [x] ~~should `LocalDefId` implement `rustc_index::Idx`?~~ * ~~this would get rid of a couple more `DefIndex` uses~~ * [x] ~~should `LocalDefId` be encoded/decoded as just a `DefIndex`?~~ * ~~right now it's a bit messy `LocalDefId` encodes/decodes like `DefId`~~ * [x] ~~should `DefId::assert_local` be named something else like `expect_local`?~~ A future PR should change `tcx.hir().local_def_id(...)` to return `LocalDefId` instead of `DefId` as changing it in this PR would be too noisy. r? @michaelwoerister cc @nikomatsakis @petrochenkov @Zoxc",HEART,2019-12-08T12:54:13Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66139,MERGED,2019-11-06T01:11:34Z,2019-11-06T09:34:49Z,use American spelling for `pluralize!`,euclio,ad550b8ef32e336ad74a87669de041eba9f7d1c6,21,use American spelling for `pluralize!`,THUMBS_DOWN,2019-11-06T01:13:17Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/66146,MERGED,2019-11-06T08:40:15Z,2019-11-07T07:09:25Z,Remove unused parameters in `__thread_local_inner`,3442853561,936349c81b59581c7c3a834a6b61eb94168e2807,1,Update local.rs Removed parameters not used in the macro,HEART,2019-11-06T19:30:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/66147,MERGED,2019-11-06T08:55:40Z,2019-11-07T07:09:24Z,Miri: Refactor to_scalar_ptr out of existence,RalfJung,2312a56f5c4e65df4b6d8128489bc58a79555718,1,#NAME?,HEART,2019-11-06T19:30:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/66156,MERGED,2019-11-06T13:10:46Z,2019-11-13T03:49:05Z,Stage0 step,Mark-Simulacrum,994d83666defc0cc6b0fde305d164fbf23433114,1,Remove no longer needed mutability,HEART,2019-11-06T19:28:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/66170,MERGED,2019-11-06T20:56:17Z,2019-11-13T23:22:12Z,Add a HIR pass to check consts for `if` `loop` etc.,ecstatic-morse,7552bd662f89c67c54e61e2f7c1c1979f6b510e2,1,Use `ast::Mutability`,HEART,2019-11-26T06:34:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66178,MERGED,2019-11-07T04:41:12Z,2019-11-26T01:55:17Z,Fix opaque types resulting from projections in function signature,Aaron1011,df3f33870ad48b29a82cce524c1fa092280e76c8,1,Update for ConstKind refactor,HEART,2019-11-14T00:33:52Z,estebank,NA https://github.com/rust-lang/rust/pull/66178,MERGED,2019-11-07T04:41:12Z,2019-11-26T01:55:17Z,Fix opaque types resulting from projections in function signature,Aaron1011,df3f33870ad48b29a82cce524c1fa092280e76c8,1,Update for ConstKind refactor,HEART,2019-11-19T11:51:29Z,chpio,NA https://github.com/rust-lang/rust/pull/66178,MERGED,2019-11-07T04:41:12Z,2019-11-26T01:55:17Z,Fix opaque types resulting from projections in function signature,Aaron1011,df3f33870ad48b29a82cce524c1fa092280e76c8,1,Update for ConstKind refactor,HEART,2019-12-23T20:13:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66183,MERGED,2019-11-07T10:31:31Z,2019-11-23T01:13:34Z,*Syntactically* permit visibilities on trait items & enum variants,Centril,9a88364525a4660dbd6f6a371b3b25199f5bbe4a,25,syntactically allow visibility on trait item & enum variant,HEART,2019-11-07T14:20:19Z,limira,NA https://github.com/rust-lang/rust/pull/66183,MERGED,2019-11-07T10:31:31Z,2019-11-23T01:13:34Z,*Syntactically* permit visibilities on trait items & enum variants,Centril,9a88364525a4660dbd6f6a371b3b25199f5bbe4a,25,syntactically allow visibility on trait item & enum variant,THUMBS_UP,2019-11-14T00:41:50Z,estebank,NA https://github.com/rust-lang/rust/pull/66183,MERGED,2019-11-07T10:31:31Z,2019-11-23T01:13:34Z,*Syntactically* permit visibilities on trait items & enum variants,Centril,9a88364525a4660dbd6f6a371b3b25199f5bbe4a,25,syntactically allow visibility on trait item & enum variant,HEART,2020-01-28T12:59:14Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/66197,MERGED,2019-11-07T19:22:02Z,2019-11-15T16:57:49Z,Push `ast::{ItemKind ImplItemKind}::OpaqueTy` hack down into lowering,Centril,03cf0d737f075aa8839dd7cc5b1047910ec00ddf,5,TAIT: adjust tests,THUMBS_UP,2019-11-08T16:07:32Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/66197,MERGED,2019-11-07T19:22:02Z,2019-11-15T16:57:49Z,Push `ast::{ItemKind ImplItemKind}::OpaqueTy` hack down into lowering,Centril,03cf0d737f075aa8839dd7cc5b1047910ec00ddf,5,TAIT: adjust tests,THUMBS_UP,2019-11-26T06:35:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66206,MERGED,2019-11-08T01:59:38Z,2019-11-19T10:57:33Z,Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]`,PotHix,3fa8692a5e5f69133464dabb52f549a46529ffe6,3,"Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]` The code was previously suggesting `#[repr(C packed ...)]` for incorrect uses of `repr` (e.g. `#[repr = ""C""]`). This change suggests the usage of `#[repr(C)]` instead. r? @estebank ref #61286",HOORAY,2019-11-28T18:01:57Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/66206,MERGED,2019-11-08T01:59:38Z,2019-11-19T10:57:33Z,Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]`,PotHix,3fa8692a5e5f69133464dabb52f549a46529ffe6,3,"Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]` The code was previously suggesting `#[repr(C packed ...)]` for incorrect uses of `repr` (e.g. `#[repr = ""C""]`). This change suggests the usage of `#[repr(C)]` instead. r? @estebank ref #61286",ROCKET,2019-11-28T18:01:59Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/66206,MERGED,2019-11-08T01:59:38Z,2019-11-19T10:57:33Z,Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]`,PotHix,3fa8692a5e5f69133464dabb52f549a46529ffe6,3,"Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]` The code was previously suggesting `#[repr(C packed ...)]` for incorrect uses of `repr` (e.g. `#[repr = ""C""]`). This change suggests the usage of `#[repr(C)]` instead. r? @estebank ref #61286",HEART,2019-11-28T18:02:00Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/66206,MERGED,2019-11-08T01:59:38Z,2019-11-19T10:57:33Z,Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]`,PotHix,3fa8692a5e5f69133464dabb52f549a46529ffe6,3,"Suggest `#[repr(C)]` instead of `#[repr(C packed ...)]` The code was previously suggesting `#[repr(C packed ...)]` for incorrect uses of `repr` (e.g. `#[repr = ""C""]`). This change suggests the usage of `#[repr(C)]` instead. r? @estebank ref #61286",HEART,2019-12-02T20:01:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66213,MERGED,2019-11-08T08:44:46Z,2019-11-11T12:55:32Z,Make error and warning annotations mandatory in UI tests,tmiasko,427952e8088233576102a1cc32f67183d22e922b,75,Make error and warning annotations mandatory in UI tests This change makes error and warning annotations mandatory in UI tests. The only exception are tests that use error patterns to match compiler output and don't have any annotations.,HEART,2019-11-08T08:59:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66216,MERGED,2019-11-08T11:13:41Z,2019-11-10T05:24:31Z,[mir-opt] Handle return place in ConstProp and improve SimplifyLocals pass,wesleywiser,4505ff4badd0ffe137772401c39dfa760ff9d4a6,3,[mir-opt] Handle aggregates in SimplifyLocals pass,HOORAY,2019-11-09T21:03:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66221,MERGED,2019-11-08T13:49:34Z,2019-12-24T18:02:38Z,Show the actual value of constant values in the documentation,ohadravid,811bdeee002827fbc950ac52a6175e933567823c,11,Show value for consts in the documentation,HOORAY,2019-11-29T18:46:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66221,MERGED,2019-11-08T13:49:34Z,2019-12-24T18:02:38Z,Show the actual value of constant values in the documentation,ohadravid,811bdeee002827fbc950ac52a6175e933567823c,11,Show value for consts in the documentation,HOORAY,2019-12-01T17:52:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/66221,MERGED,2019-11-08T13:49:34Z,2019-12-24T18:02:38Z,Show the actual value of constant values in the documentation,ohadravid,811bdeee002827fbc950ac52a6175e933567823c,11,Show value for consts in the documentation,HOORAY,2020-01-03T17:17:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66221,MERGED,2019-11-08T13:49:34Z,2019-12-24T18:02:38Z,Show the actual value of constant values in the documentation,ohadravid,811bdeee002827fbc950ac52a6175e933567823c,11,Show value for consts in the documentation,HOORAY,2020-03-29T23:53:24Z,rrbutani,NA https://github.com/rust-lang/rust/pull/66233,MERGED,2019-11-09T00:00:15Z,2019-11-14T08:03:16Z,Split ConstValue into two enums,cjgillot,552fa6479846951e242df412a08c86212beb1d0f,1,Bless mir-dump test.,HEART,2019-11-25T22:44:44Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66235,MERGED,2019-11-09T00:13:34Z,2019-11-10T05:24:28Z,rustc_metadata: don't let LLVM confuse rmeta blobs for COFF object files.,eddyb,0da85d62283257516a1dab97f7156a4e0cd96266,3,rustc_metadata: don't let LLVM confuse rmeta blobs for COFF object files.,HEART,2019-11-09T10:36:14Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/66238,MERGED,2019-11-09T00:16:31Z,2019-11-18T06:09:20Z,rustdoc: Stabilize `edition` annotation.,ehuss,1907589fbb87e63b2c93808f485f021d2cc81ca5,2,rustdoc: Stabilize `edition` annotation.,HEART,2019-12-02T20:06:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66241,MERGED,2019-11-09T03:53:34Z,2019-11-12T11:39:03Z,bump openssl version,tesuji,e6d72c3cef780ca0f72ab6cb4e01de66d8dd48aa,1,bump openssl version to support newer versions of libressl in rust builds Co-authored-by: dylanaraps ,THUMBS_UP,2019-11-09T06:57:44Z,dylanaraps,dylan.araps@gmail.com https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-09T12:00:30Z,RalfJung,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-09T12:07:23Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-09T13:54:52Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-09T16:25:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-09T20:19:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HOORAY,2019-11-10T02:54:58Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-13T22:39:42Z,estebank,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-27T08:36:43Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-27T09:48:15Z,ljedrz,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-27T11:56:56Z,lqd,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HOORAY,2019-11-27T16:01:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HOORAY,2019-11-28T16:35:41Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-11-28T16:35:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-12-05T17:32:14Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66246,MERGED,2019-11-09T10:51:57Z,2019-11-28T14:23:09Z,Simplify memory categorization,matthewjasper,5bc15866d752d4ba4a02e9ab130b08cb8186d8f9,6,Move ExprUseVisitor and mem_categorization to rustc_typeck `MemCategorizationContext` is now private the remaining types and traits remain public for Clippy.,HEART,2019-12-23T20:05:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66248,MERGED,2019-11-09T11:37:25Z,2019-11-13T16:18:11Z,add raw ptr variant of UnsafeCell::get,RalfJung,861698a493fc547254e61dc23a43dfb0683df91a,1,make things ugly,THUMBS_UP,2019-11-09T11:41:54Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/66248,MERGED,2019-11-09T11:37:25Z,2019-11-13T16:18:11Z,add raw ptr variant of UnsafeCell::get,RalfJung,861698a493fc547254e61dc23a43dfb0683df91a,1,make things ugly,THUMBS_UP,2019-11-09T12:20:32Z,pitdicker,NA https://github.com/rust-lang/rust/pull/66248,MERGED,2019-11-09T11:37:25Z,2019-11-13T16:18:11Z,add raw ptr variant of UnsafeCell::get,RalfJung,861698a493fc547254e61dc23a43dfb0683df91a,1,make things ugly,THUMBS_UP,2019-11-09T12:55:18Z,sfackler,NA https://github.com/rust-lang/rust/pull/66248,MERGED,2019-11-09T11:37:25Z,2019-11-13T16:18:11Z,add raw ptr variant of UnsafeCell::get,RalfJung,861698a493fc547254e61dc23a43dfb0683df91a,1,make things ugly,THUMBS_UP,2019-11-13T08:29:20Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66248,MERGED,2019-11-09T11:37:25Z,2019-11-13T16:18:11Z,add raw ptr variant of UnsafeCell::get,RalfJung,861698a493fc547254e61dc23a43dfb0683df91a,1,make things ugly,THUMBS_UP,2019-11-25T22:40:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66252,MERGED,2019-11-09T18:28:10Z,2019-11-11T17:10:40Z,Merge repeated definitions,cjgillot,76128f89a118ecd0fc2a69965e8a459105119c95,4,Fix tidy.,HEART,2019-11-10T23:36:58Z,panaman67,NA https://github.com/rust-lang/rust/pull/66253,MERGED,2019-11-09T18:45:02Z,2019-11-14T11:07:07Z,Improve errors after re rebalance coherence,ohadravid,2db744ca9d4da28c5d0088f5d21e237e7f678abb,25,Improve coherence errors for wrong type order,THUMBS_UP,2019-11-25T22:35:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66255,MERGED,2019-11-09T20:24:05Z,2019-11-16T11:02:44Z,Update cc git2 num_cpus.,ehuss,a902383053c763b12a242bf76baf754a8b660c09,3,Update cc git2 num_cpus.,THUMBS_UP,2019-11-09T20:33:05Z,mati865,NA https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-10T19:49:02Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-11T08:31:43Z,CryZe,NA https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-11T11:07:46Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-12T01:26:15Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-12T14:42:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-11-27T16:09:09Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-12-03T08:35:05Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-12-10T21:52:22Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-12-23T18:05:04Z,marmeladema,NA https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2019-12-31T01:33:03Z,c0nk,NA https://github.com/rust-lang/rust/pull/66262,CLOSED,2019-11-10T07:09:13Z,2020-01-10T08:29:15Z,Addition operation for two `char`s to produce a `String`,Ruster-a11y,NA,NA,NA,THUMBS_DOWN,2020-01-04T17:52:31Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/66264,MERGED,2019-11-10T07:45:51Z,2019-11-14T11:07:05Z,fix an ICE in macro's diagnostic message,guanqun,292ba98cb723fe2ab6ddcac9e4852be960deaaaa,4,fix an ICE in macro's diagnostic message,HOORAY,2019-11-14T11:56:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/66267,MERGED,2019-11-10T11:14:37Z,2019-11-12T11:38:59Z,Add rustdoc doc,GuillaumeGomez,528b0590b19bb0f413ebbafd78a8d1588f890526,3,Add rustdoc doc page for lints,HEART,2019-11-12T13:08:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/66271,MERGED,2019-11-10T15:01:59Z,2019-11-17T07:44:55Z,syntax: Keep string literals in ABIs and `asm!` more precisely,petrochenkov,28aec1beaa5e16b17143f993cab408debe1dcda5,3,Add some more tests,THUMBS_UP,2019-11-13T23:04:12Z,estebank,NA https://github.com/rust-lang/rust/pull/66271,MERGED,2019-11-10T15:01:59Z,2019-11-17T07:44:55Z,syntax: Keep string literals in ABIs and `asm!` more precisely,petrochenkov,28aec1beaa5e16b17143f993cab408debe1dcda5,3,Add some more tests,THUMBS_UP,2019-11-24T20:53:24Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/66277,MERGED,2019-11-10T17:30:04Z,2019-12-10T13:29:10Z,From impls for wider NonZero types,peter-wilkins,8f6a06285efe12d778ff7f44067aebeed7b14428,3312,move from non zero impls to `libcore/convert/num.rs`,THUMBS_UP,2019-11-11T12:01:19Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66277,MERGED,2019-11-10T17:30:04Z,2019-12-10T13:29:10Z,From impls for wider NonZero types,peter-wilkins,8f6a06285efe12d778ff7f44067aebeed7b14428,3312,move from non zero impls to `libcore/convert/num.rs`,THUMBS_UP,2019-11-13T03:05:49Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/66279,MERGED,2019-11-10T18:51:28Z,2019-11-25T12:42:17Z,Use proc-macro to derive HashStable everywhere,cjgillot,782cc9f65c0c19ef79bd009074e09bf0394674f4,3,Derive HashStable for TokenKind.,HOORAY,2019-11-12T10:07:36Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/66279,MERGED,2019-11-10T18:51:28Z,2019-11-25T12:42:17Z,Use proc-macro to derive HashStable everywhere,cjgillot,782cc9f65c0c19ef79bd009074e09bf0394674f4,3,Derive HashStable for TokenKind.,HOORAY,2019-12-02T20:02:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66280,MERGED,2019-11-10T23:57:34Z,2019-11-12T11:38:56Z,Fix HashSet::union performance,stepancheg,04a237b9e2c327e1ad6339afd2f967bfcad38483,1,Fix HashSet::union performance Consider this example: small_set = 0..2 large_set = 0..1000. To efficiently compute the union of these sets we should * take all elements of the larger set * for each element of the smaller set check it is not in the larger set This is exactly what this commit does. This particular optimization was implemented a year ago but the author mistaken `<` and `>`.,LAUGH,2019-11-11T08:53:11Z,mati865,NA https://github.com/rust-lang/rust/pull/66280,MERGED,2019-11-10T23:57:34Z,2019-11-12T11:38:56Z,Fix HashSet::union performance,stepancheg,04a237b9e2c327e1ad6339afd2f967bfcad38483,1,Fix HashSet::union performance Consider this example: small_set = 0..2 large_set = 0..1000. To efficiently compute the union of these sets we should * take all elements of the larger set * for each element of the smaller set check it is not in the larger set This is exactly what this commit does. This particular optimization was implemented a year ago but the author mistaken `<` and `>`.,LAUGH,2019-11-20T18:39:46Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66280,MERGED,2019-11-10T23:57:34Z,2019-11-12T11:38:56Z,Fix HashSet::union performance,stepancheg,04a237b9e2c327e1ad6339afd2f967bfcad38483,1,Fix HashSet::union performance Consider this example: small_set = 0..2 large_set = 0..1000. To efficiently compute the union of these sets we should * take all elements of the larger set * for each element of the smaller set check it is not in the larger set This is exactly what this commit does. This particular optimization was implemented a year ago but the author mistaken `<` and `>`.,LAUGH,2019-11-21T14:36:43Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/66280,MERGED,2019-11-10T23:57:34Z,2019-11-12T11:38:56Z,Fix HashSet::union performance,stepancheg,04a237b9e2c327e1ad6339afd2f967bfcad38483,1,Fix HashSet::union performance Consider this example: small_set = 0..2 large_set = 0..1000. To efficiently compute the union of these sets we should * take all elements of the larger set * for each element of the smaller set check it is not in the larger set This is exactly what this commit does. This particular optimization was implemented a year ago but the author mistaken `<` and `>`.,LAUGH,2019-11-21T20:55:37Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/66280,MERGED,2019-11-10T23:57:34Z,2019-11-12T11:38:56Z,Fix HashSet::union performance,stepancheg,04a237b9e2c327e1ad6339afd2f967bfcad38483,1,Fix HashSet::union performance Consider this example: small_set = 0..2 large_set = 0..1000. To efficiently compute the union of these sets we should * take all elements of the larger set * for each element of the smaller set check it is not in the larger set This is exactly what this commit does. This particular optimization was implemented a year ago but the author mistaken `<` and `>`.,HEART,2019-11-25T22:41:34Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66282,MERGED,2019-11-11T03:58:56Z,2019-11-22T03:16:24Z,[mir-opt] asking `?`s in a more optimized fashion,Centril,2f00e86cb5cbb4d4cfe17abc6136aacadbe02382,11,Introduce MIR optimizations for simplifying `x?` on `Result`s. This optimization depends on inlining for the identity conversions introduced by the lowering of the `?`. To take advantage of `SimplifyArmIdentity` `-Z mir-opt-level=2` is required because that triggers the inlining MIR optimization.,HEART,2019-12-01T16:13:53Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66282,MERGED,2019-11-11T03:58:56Z,2019-11-22T03:16:24Z,[mir-opt] asking `?`s in a more optimized fashion,Centril,2f00e86cb5cbb4d4cfe17abc6136aacadbe02382,11,Introduce MIR optimizations for simplifying `x?` on `Result`s. This optimization depends on inlining for the identity conversions introduced by the lowering of the `?`. To take advantage of `SimplifyArmIdentity` `-Z mir-opt-level=2` is required because that triggers the inlining MIR optimization.,HEART,2019-12-02T19:58:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66282,MERGED,2019-11-11T03:58:56Z,2019-11-22T03:16:24Z,[mir-opt] asking `?`s in a more optimized fashion,Centril,2f00e86cb5cbb4d4cfe17abc6136aacadbe02382,11,Introduce MIR optimizations for simplifying `x?` on `Result`s. This optimization depends on inlining for the identity conversions introduced by the lowering of the `?`. To take advantage of `SimplifyArmIdentity` `-Z mir-opt-level=2` is required because that triggers the inlining MIR optimization.,HEART,2020-04-12T17:34:35Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/66290,CLOSED,2019-11-11T10:57:15Z,2019-11-17T06:52:33Z,Move `test::Bencher` to a new (unstable) `std::bench` module,SimonSapin,NA,NA,NA,THUMBS_UP,2019-11-11T21:12:15Z,elichai,NA https://github.com/rust-lang/rust/pull/66292,MERGED,2019-11-11T12:45:33Z,2019-11-13T16:18:07Z,add Result::map_or,tesuji,e8f3a9ffbe0dc435d43767b31cc122ccc325f4c1,1,add Result::map_or,HEART,2019-11-25T22:36:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66292,MERGED,2019-11-11T12:45:33Z,2019-11-13T16:18:07Z,add Result::map_or,tesuji,e8f3a9ffbe0dc435d43767b31cc122ccc325f4c1,1,add Result::map_or,HEART,2019-12-02T19:47:07Z,jomaro,NA https://github.com/rust-lang/rust/pull/66292,MERGED,2019-11-11T12:45:33Z,2019-11-13T16:18:07Z,add Result::map_or,tesuji,e8f3a9ffbe0dc435d43767b31cc122ccc325f4c1,1,add Result::map_or,HEART,2020-02-24T12:59:52Z,Boscop,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-11-11T15:30:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-11-12T13:00:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,ROCKET,2019-11-12T16:00:01Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-11-12T18:29:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,ROCKET,2019-11-24T20:21:54Z,raoulj,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,THUMBS_UP,2019-11-27T09:30:40Z,iago-lito,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-11-27T15:37:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-11-29T20:49:01Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,THUMBS_UP,2019-12-05T18:17:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-12-05T19:48:12Z,chrish42,NA https://github.com/rust-lang/rust/pull/66294,MERGED,2019-11-11T14:37:22Z,2019-11-28T10:37:19Z,Add memoization for const function evaluations,davidhewitt,a28fbd46082f8ff6dd09dbbbaa553f09bd6ff824,1,Correct typo in src/librustc_mir/const_eval.rs Co-Authored-By: lqd ,HEART,2019-12-23T21:37:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66296,MERGED,2019-11-11T14:50:54Z,2019-12-24T01:10:41Z,Initial implementation of `#![feature(bindings_after_at)]`,Centril,acfe58272cb188e2da69d2bf1285bf2d954de9a2,1,adjust E0303 error code docs,HOORAY,2020-01-03T00:23:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66302,CLOSED,2019-11-11T17:33:48Z,2019-12-16T16:20:37Z,Allow constants to refer statics,spastorino,NA,NA,NA,ROCKET,2019-11-11T18:51:18Z,lqd,NA https://github.com/rust-lang/rust/pull/66302,CLOSED,2019-11-11T17:33:48Z,2019-12-16T16:20:37Z,Allow constants to refer statics,spastorino,NA,NA,NA,ROCKET,2019-11-12T17:58:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66302,CLOSED,2019-11-11T17:33:48Z,2019-12-16T16:20:37Z,Allow constants to refer statics,spastorino,NA,NA,NA,THUMBS_UP,2022-05-23T05:32:51Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66305,MERGED,2019-11-11T18:00:49Z,2019-11-28T00:36:54Z,Add by-value arrays to `improper_ctypes` lint,elichai,b3666b64738980579f05eec0cfae43f917f74a29,2,Update tests for raw array in FFI lint,THUMBS_UP,2019-11-12T07:11:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66305,MERGED,2019-11-11T18:00:49Z,2019-11-28T00:36:54Z,Add by-value arrays to `improper_ctypes` lint,elichai,b3666b64738980579f05eec0cfae43f917f74a29,2,Update tests for raw array in FFI lint,THUMBS_UP,2019-11-28T14:49:11Z,stevenroose,github@stevenroose.org https://github.com/rust-lang/rust/pull/66309,MERGED,2019-11-11T19:31:06Z,2019-11-12T11:38:52Z,Tiny cleanup to size assertions,petrochenkov,e7c42f0cf0b46ec4788f98c5bf30cda8a45cdd83,4,Tiny cleanup to size assertions,THUMBS_UP,2019-11-12T07:03:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66309,MERGED,2019-11-11T19:31:06Z,2019-11-12T11:38:52Z,Tiny cleanup to size assertions,petrochenkov,e7c42f0cf0b46ec4788f98c5bf30cda8a45cdd83,4,Tiny cleanup to size assertions,THUMBS_UP,2019-11-12T08:08:54Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66314,MERGED,2019-11-11T21:47:54Z,2019-11-14T17:13:48Z,Move error codes,GuillaumeGomez,b5b2a8984e57260bb91d3327490da74f6fa310db,1,Move E0210 to new error location,ROCKET,2019-11-13T23:52:36Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/66314,MERGED,2019-11-11T21:47:54Z,2019-11-14T17:13:48Z,Move error codes,GuillaumeGomez,b5b2a8984e57260bb91d3327490da74f6fa310db,1,Move E0210 to new error location,ROCKET,2019-11-14T18:08:04Z,smorimoto,sora@morimoto.io https://github.com/rust-lang/rust/pull/66318,MERGED,2019-11-11T23:35:46Z,2019-11-12T15:56:15Z,Update LLVM submodule,mati865,5a1aa8def3cd354101223609a8fa147832324876,1,Update llvm submodule,HEART,2019-11-11T23:41:40Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/66318,MERGED,2019-11-11T23:35:46Z,2019-11-12T15:56:15Z,Update LLVM submodule,mati865,5a1aa8def3cd354101223609a8fa147832324876,1,Update llvm submodule,HEART,2019-11-25T22:30:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66321,MERGED,2019-11-12T02:21:45Z,2019-11-29T21:24:04Z,Async fn resume after completion,ninjasource,851492c3724204834d833f940ed5447813fda672,3,Ignore wasm for panic tests,ROCKET,2019-11-13T08:27:28Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66321,MERGED,2019-11-12T02:21:45Z,2019-11-29T21:24:04Z,Async fn resume after completion,ninjasource,851492c3724204834d833f940ed5447813fda672,3,Ignore wasm for panic tests,ROCKET,2019-12-05T06:21:10Z,GrayJack,NA https://github.com/rust-lang/rust/pull/66322,MERGED,2019-11-12T03:11:43Z,2019-11-24T10:52:30Z,Stabilize Result::map_or_else,tesuji,c06a8ea727c720ed47b3f54192e92c449252d231,1,stabilize Result::map_or_else,THUMBS_DOWN,2019-11-25T05:23:37Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/66322,MERGED,2019-11-12T03:11:43Z,2019-11-24T10:52:30Z,Stabilize Result::map_or_else,tesuji,c06a8ea727c720ed47b3f54192e92c449252d231,1,stabilize Result::map_or_else,THUMBS_DOWN,2021-08-22T16:11:20Z,MightyPork,ondra@ondrovo.com https://github.com/rust-lang/rust/pull/66325,MERGED,2019-11-12T09:01:14Z,2019-12-08T09:07:59Z,Change unused_labels from allow to warn,BartMassey,34a45a5309dad66025df506a388fbdf1da9afa40,1,Changed unused_labels lint default from allow to warn Closes #66324.,THUMBS_UP,2019-11-19T01:38:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66325,MERGED,2019-11-12T09:01:14Z,2019-12-08T09:07:59Z,Change unused_labels from allow to warn,BartMassey,34a45a5309dad66025df506a388fbdf1da9afa40,1,Changed unused_labels lint default from allow to warn Closes #66324.,THUMBS_UP,2019-12-13T02:12:50Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/66325,MERGED,2019-11-12T09:01:14Z,2019-12-08T09:07:59Z,Change unused_labels from allow to warn,BartMassey,34a45a5309dad66025df506a388fbdf1da9afa40,1,Changed unused_labels lint default from allow to warn Closes #66324.,HOORAY,2019-12-13T02:12:52Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/66325,MERGED,2019-11-12T09:01:14Z,2019-12-08T09:07:59Z,Change unused_labels from allow to warn,BartMassey,34a45a5309dad66025df506a388fbdf1da9afa40,1,Changed unused_labels lint default from allow to warn Closes #66324.,HOORAY,2020-01-31T09:52:28Z,DarkKapla,NA https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,THUMBS_UP,2019-11-12T10:05:29Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,THUMBS_UP,2019-11-12T15:37:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,HEART,2019-11-12T15:37:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,THUMBS_UP,2019-11-20T18:34:21Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,THUMBS_UP,2019-11-20T19:00:41Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/66326,MERGED,2019-11-12T09:37:46Z,2019-11-16T02:41:03Z,Refactor integer range handling in the usefulness algorithm,Nadrieril,694a511df5e7473a696b50d30c3428bd0d54f140,1,Apply suggestions from code review,HEART,2019-11-25T22:24:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-12T14:47:43Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-12T14:55:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-12T15:30:20Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-12T16:14:36Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-12T18:00:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-11-20T23:45:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-12-06T21:56:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2019-12-30T13:16:23Z,mati865,NA https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,HEART,2020-01-22T17:53:08Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,THUMBS_UP,2020-01-22T19:04:18Z,twilco,tyler.wilcock@protonmail.com https://github.com/rust-lang/rust/pull/66329,MERGED,2019-11-12T13:41:05Z,2020-01-15T08:27:12Z,Add unreachable propagation mir optimization pass,ktrianta,72710d6dc2d0511cd21378f7cc99ac59ac3a5af5,8,Add unreachable propagation mir optimization pass,THUMBS_UP,2020-02-13T21:31:52Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/66330,MERGED,2019-11-12T15:42:22Z,2019-11-13T16:18:01Z,Improve non-exhaustiveness handling in usefulness checking,Nadrieril,e398d897b09f69bc4b5a1ab531db1c8742001bff,1,Move NonExhaustive checks to the relevant match branches,HEART,2019-11-12T17:45:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66330,MERGED,2019-11-12T15:42:22Z,2019-11-13T16:18:01Z,Improve non-exhaustiveness handling in usefulness checking,Nadrieril,e398d897b09f69bc4b5a1ab531db1c8742001bff,1,Move NonExhaustive checks to the relevant match branches,HEART,2019-11-26T06:16:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66334,MERGED,2019-11-12T17:40:17Z,2019-11-13T16:17:58Z,Move Session fields to CrateStore,Mark-Simulacrum,2c6d6094840cd88422f50b2c7972199a00578319,8,Move allocator_kind to CrateStore Similarly to the previous commit there's no need for this to be in Session and have a Once around it.,THUMBS_UP,2019-11-26T06:15:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66337,MERGED,2019-11-12T18:05:39Z,2019-11-13T16:17:57Z,Remove dead code for encoding/decoding lint IDs,Mark-Simulacrum,8c29b74b15d494fd963109bade5f31a0ada431d0,1,Remove dead code for encoding/decoding lint IDs This helps decouple the lint system from needing the implicit TLS TyCtxt as well.,HEART,2019-11-13T01:43:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/66344,MERGED,2019-11-12T20:16:26Z,2019-11-17T07:44:49Z,rustc_plugin: Remove `Registry::register_attribute`,petrochenkov,857574379310d6ca70d3d44dbf00cc45b23e7eb8,13,rustc_plugin: Remove `Registry::register_attribute`,HEART,2019-11-13T07:43:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66349,MERGED,2019-11-12T22:51:04Z,2019-11-14T11:06:56Z,expand source_util macros with def-site context,euclio,fe4b709c0cc51dda3a9ed0cb5d10346509e9966d,1,expand source_util macros with def-site context,THUMBS_UP,2019-11-25T22:44:14Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66351,MERGED,2019-11-12T23:40:22Z,2019-11-14T11:06:55Z,Tweak non-char/numeric in range pattern diagnostic,JohnTitor,030fa9a337cb7f224c1d74fda04304c69e07787a,1,Avoid using same code,HEART,2019-11-13T16:07:51Z,estebank,NA https://github.com/rust-lang/rust/pull/66361,MERGED,2019-11-13T11:07:21Z,2019-11-14T11:06:54Z,parser: don't use `unreachable!()` in `fn unexpected`.,Centril,dcd91d5ceb1990a48c985e01cbe6fca7e274f016,3,parser: don't use `unreachable!()` in `fn unexpected`.,THUMBS_UP,2019-11-13T16:03:54Z,estebank,NA https://github.com/rust-lang/rust/pull/66364,MERGED,2019-11-13T12:41:19Z,2020-03-10T20:30:28Z,Cleanup `rmeta::MacroDef`,Centril,15812785344d913d779d9738fe3cca8de56f71d5,33,Auto merge of #66364 - Centril:cleanup-macro-def r=petrochenkov eddyb Cleanup `rmeta::MacroDef` Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`. The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well. Fixes #49511. r? @eddyb cc @matthewjasper @estebank @petrochenkov,HEART,2020-01-24T08:59:34Z,najamelan,NA https://github.com/rust-lang/rust/pull/66364,MERGED,2019-11-13T12:41:19Z,2020-03-10T20:30:28Z,Cleanup `rmeta::MacroDef`,Centril,15812785344d913d779d9738fe3cca8de56f71d5,33,Auto merge of #66364 - Centril:cleanup-macro-def r=petrochenkov eddyb Cleanup `rmeta::MacroDef` Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`. The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well. Fixes #49511. r? @eddyb cc @matthewjasper @estebank @petrochenkov,HEART,2020-02-08T00:10:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66364,MERGED,2019-11-13T12:41:19Z,2020-03-10T20:30:28Z,Cleanup `rmeta::MacroDef`,Centril,15812785344d913d779d9738fe3cca8de56f71d5,33,Auto merge of #66364 - Centril:cleanup-macro-def r=petrochenkov eddyb Cleanup `rmeta::MacroDef` Avoid using rountrip parsing in the encoder and in `fn load_macro_untracked`. The main reason I was interested in this was to remove `rustc_parse` as a dependency of `rustc_metadata` but it seems like this had other benefits as well. Fixes #49511. r? @eddyb cc @matthewjasper @estebank @petrochenkov,HEART,2020-02-27T03:25:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/66369,MERGED,2019-11-13T13:34:17Z,2019-11-14T11:06:52Z,compiletest: Obtain timestamps for common inputs only once,tmiasko,1ac470f70c9de77cbd5fd6e5c5a624e55af81fad,1,compiletest: Avoid double negation in ignore condition,THUMBS_UP,2019-11-13T14:35:55Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/66369,MERGED,2019-11-13T13:34:17Z,2019-11-14T11:06:52Z,compiletest: Obtain timestamps for common inputs only once,tmiasko,1ac470f70c9de77cbd5fd6e5c5a624e55af81fad,1,compiletest: Avoid double negation in ignore condition,THUMBS_UP,2019-11-13T21:16:00Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/66377,MERGED,2019-11-13T17:23:38Z,2019-12-11T08:40:03Z,Update RELEASES.md for 1.40.0,XAMPPRocky,dbfb00c4de2bd2c071344729dd3609a963b2da4c,1,Update RELEASES.md Co-Authored-By: Mark Rousskov ,HEART,2019-11-13T18:03:12Z,ehuss,NA https://github.com/rust-lang/rust/pull/66377,MERGED,2019-11-13T17:23:38Z,2019-12-11T08:40:03Z,Update RELEASES.md for 1.40.0,XAMPPRocky,dbfb00c4de2bd2c071344729dd3609a963b2da4c,1,Update RELEASES.md Co-Authored-By: Mark Rousskov ,HEART,2019-11-14T12:06:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/66377,MERGED,2019-11-13T17:23:38Z,2019-12-11T08:40:03Z,Update RELEASES.md for 1.40.0,XAMPPRocky,dbfb00c4de2bd2c071344729dd3609a963b2da4c,1,Update RELEASES.md Co-Authored-By: Mark Rousskov ,HEART,2019-11-14T13:50:41Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/66377,MERGED,2019-11-13T17:23:38Z,2019-12-11T08:40:03Z,Update RELEASES.md for 1.40.0,XAMPPRocky,dbfb00c4de2bd2c071344729dd3609a963b2da4c,1,Update RELEASES.md Co-Authored-By: Mark Rousskov ,HEART,2019-11-18T20:50:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66381,MERGED,2019-11-13T18:35:35Z,2019-11-17T07:44:47Z,find_deprecation: deprecation attr may be ill-formed meta.,Centril,91aadf030548214da5a8f39a1b1dbd21db125625,3,find_deprecation: deprecation attr may be ill-formed meta.,HEART,2019-11-14T15:41:23Z,lucidBrot,eric@mink.li https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-13T21:52:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-13T22:49:06Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-13T22:58:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-13T22:59:46Z,estebank,NA https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-14T11:04:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-14T18:08:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-14T18:14:15Z,varkor,NA https://github.com/rust-lang/rust/pull/66384,MERGED,2019-11-13T20:55:44Z,2019-11-17T18:38:20Z,Derive TypeFoldable using a proc-macro,cjgillot,cb46c3558af9f9863f3fa3659693fcc883dbfcee,5,Use multiple derive clauses.,HEART,2019-11-16T15:13:53Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:11:57Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:17:21Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:34:19Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:37:14Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:43:48Z,darksv,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T21:52:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-13T21:52:18Z,panaman67,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T22:33:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-13T22:33:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-13T23:38:39Z,lachlansneff,lachlan@charted.space https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-14T04:36:55Z,est31,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-14T06:19:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-14T06:19:45Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-14T12:02:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-14T17:42:01Z,mati865,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-17T17:07:05Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-18T10:42:47Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-18T12:58:35Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-20T18:38:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-20T18:38:06Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-20T21:16:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-22T08:21:19Z,frol,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HOORAY,2019-11-22T08:21:27Z,frol,NA https://github.com/rust-lang/rust/pull/66385,MERGED,2019-11-13T21:01:01Z,2019-11-17T21:47:43Z,Make dataflow-based const qualification the canonical one,ecstatic-morse,a1135cc9463437ed806876b2406379c25321e7d3,3,Remove newtype for qualifs in `rustc_metadata` We have a proper type for these now so the wrapper is no longer necessary.,HEART,2019-11-25T22:37:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66388,MERGED,2019-11-13T22:30:14Z,2019-11-15T12:58:02Z,Do not ICE on recovery from unmet associated type bound obligation,estebank,b884205cf451463c9b0bda6e694831c1494e28d6,1,review comments,HEART,2019-11-13T22:44:22Z,azriel91,NA https://github.com/rust-lang/rust/pull/66388,MERGED,2019-11-13T22:30:14Z,2019-11-15T12:58:02Z,Do not ICE on recovery from unmet associated type bound obligation,estebank,b884205cf451463c9b0bda6e694831c1494e28d6,1,review comments,HEART,2019-11-14T07:01:41Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66391,MERGED,2019-11-13T23:23:21Z,2019-11-15T12:58:00Z,Do not ICE in `if` without `else` in `async fn`,estebank,c0a0a7d711b89d89e04a135d6035a2881a7de72e,2,review comments,HEART,2019-11-14T07:05:47Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66394,MERGED,2019-11-14T00:22:32Z,2019-11-17T02:07:05Z,Fix two OOM issues related to `ConstProp`,wesleywiser,2dea8af20cf494914d09105eb0c6c8924883f683,2,Only run tests on x86_64,HOORAY,2019-11-14T07:35:04Z,estebank,NA https://github.com/rust-lang/rust/pull/66394,MERGED,2019-11-14T00:22:32Z,2019-11-17T02:07:05Z,Fix two OOM issues related to `ConstProp`,wesleywiser,2dea8af20cf494914d09105eb0c6c8924883f683,2,Only run tests on x86_64,HOORAY,2019-11-14T11:52:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/66394,MERGED,2019-11-14T00:22:32Z,2019-11-17T02:07:05Z,Fix two OOM issues related to `ConstProp`,wesleywiser,2dea8af20cf494914d09105eb0c6c8924883f683,2,Only run tests on x86_64,HOORAY,2019-11-15T14:34:42Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/66394,MERGED,2019-11-14T00:22:32Z,2019-11-17T02:07:05Z,Fix two OOM issues related to `ConstProp`,wesleywiser,2dea8af20cf494914d09105eb0c6c8924883f683,2,Only run tests on x86_64,HOORAY,2019-11-20T18:37:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66394,MERGED,2019-11-14T00:22:32Z,2019-11-17T02:07:05Z,Fix two OOM issues related to `ConstProp`,wesleywiser,2dea8af20cf494914d09105eb0c6c8924883f683,2,Only run tests on x86_64,HOORAY,2019-11-25T22:38:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66396,MERGED,2019-11-14T01:14:09Z,2019-11-18T09:14:20Z,Make a test compatible across python versions.,smmalis37,56f9212b724cb00f4fc59ec676e4e97a127d586d,1,Change makefile back to python27.,HEART,2019-11-14T07:07:11Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,HEART,2019-11-14T01:48:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,HEART,2019-11-14T10:43:44Z,95th,NA https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,THUMBS_UP,2019-11-14T15:16:18Z,tmandry,NA https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,THUMBS_UP,2019-11-15T03:15:58Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,THUMBS_UP,2019-11-20T16:05:09Z,estebank,NA https://github.com/rust-lang/rust/pull/66398,MERGED,2019-11-14T01:23:27Z,2019-11-15T12:57:57Z,Remove some stack frames from `.async` calls,sfackler,3fe7cfc32656518d5e6262e580f0a16cd2412dd7,1,Remove some stack frames from `.async` calls The `Context` argument is currently smuggled through TLS for async-generated futures. The current infrastructure is closure-based and results in an extra 6 stack frames when .awaiting an async-generated future! ``` 12: foo::async_b::{{closure}} at src/main.rs:10 13: as core::future::future::Future>::poll::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 14: std::future::set_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:79 15: as core::future::future::Future>::poll at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:43 16: std::future::poll_with_tls_context::{{closure}} at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 17: std::future::get_task_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:111 18: std::future::poll_with_tls_context at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/future.rs:121 19: foo::async_a::{{closure}} at src/main.rs:6 ``` While the long (medium?) term solution is to remove the use of TLS entirely we can improve things a bit in the meantime. In particular this commit does 2 things: 1. `get_task_context` has been inlined into `poll_with_tls_context` removing 2 frames (16 and 17 above). 2. `set_task_context` now returns a guard type that resets the TLS rather than taking a closure removing 2 frames (13 and 14 above). We can also remove frame 18 by removing `poll_with_tls_context` in favor of a `get_task_context` function which returns a guard but that requires adjusting the code generated for .await so I've left that off for now.,HEART,2019-11-26T08:52:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66399,MERGED,2019-11-14T03:15:59Z,2019-11-28T00:36:50Z,rustc_metadata: simplify the interactions between Lazy and Table.,eddyb,a0556b3b79328c598a4f1539bbe81ceebc4a5b59,2,rustc_metadata: use a macro to deduplicate LazyPerDefTables and PerDefTableBuilders.,HEART,2019-11-14T06:50:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/66411,MERGED,2019-11-14T11:13:57Z,2019-11-24T05:34:32Z,mem::forget docs: mention ManuallyDrop,RalfJung,7009e6d001ebc807eca04c5b9f07779db02eca99,1,mem::forget docs: mention ManuallyDrop,THUMBS_UP,2019-11-14T11:21:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66419,MERGED,2019-11-14T18:20:07Z,2019-11-15T12:57:53Z,Don't warn labels beginning with `_` on unused_labels lint,JohnTitor,43492283b4952a0d6d55fbadfe53d48264f2f2b4,2,Don't warn labels beginning with `_`,THUMBS_UP,2019-11-15T07:55:54Z,BartMassey,bart@cs.pdx.edu https://github.com/rust-lang/rust/pull/66419,MERGED,2019-11-14T18:20:07Z,2019-11-15T12:57:53Z,Don't warn labels beginning with `_` on unused_labels lint,JohnTitor,43492283b4952a0d6d55fbadfe53d48264f2f2b4,2,Don't warn labels beginning with `_`,THUMBS_UP,2019-11-20T20:58:02Z,DianaNites,NA https://github.com/rust-lang/rust/pull/66431,MERGED,2019-11-15T02:30:21Z,2019-11-19T15:23:51Z,Fix 'type annotations needed' error with opaque types,Aaron1011,a11abe0d6b0f1a7a7bb4bdfde1dedfd89b357732,1,Update test output,HEART,2019-11-15T03:57:04Z,estebank,NA https://github.com/rust-lang/rust/pull/66454,MERGED,2019-11-15T17:32:34Z,2019-11-19T18:37:29Z,Derive Lift using a proc-macro,cjgillot,a65091ffff8953cdea1208ee2d10c7858f3c1fe6,1,Rename generated lifetime.,HOORAY,2019-11-15T21:27:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66454,MERGED,2019-11-15T17:32:34Z,2019-11-19T18:37:29Z,Derive Lift using a proc-macro,cjgillot,a65091ffff8953cdea1208ee2d10c7858f3c1fe6,1,Rename generated lifetime.,HOORAY,2019-11-19T01:36:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66462,CLOSED,2019-11-16T01:56:06Z,2019-12-07T11:00:12Z,Make Vec::len() and Vec::is_empty() const fn,GrayJack,NA,NA,NA,THUMBS_UP,2019-12-03T02:15:50Z,novacrazy,NA https://github.com/rust-lang/rust/pull/66463,MERGED,2019-11-16T02:53:55Z,2020-01-10T05:53:19Z,Point at opaque and closure type definitions in type errors,estebank,33ae3220b638551834fddf5c0658563d8a52e89a,1,remove unnecessary `Debug`,HOORAY,2019-12-31T04:08:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66466,MERGED,2019-11-16T08:28:57Z,2019-11-17T07:44:38Z,miri panic_unwind: fix hack for SEH platforms,RalfJung,e8ff4656fcfc4df97f5d0124c999cb5392a15dcb,1,avoid linking errors,HEART,2019-11-25T22:39:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66490,CLOSED,2019-11-17T14:13:28Z,2019-11-18T01:47:49Z,impl Add and AddAssign for String,Ruster-a11y,NA,NA,NA,THUMBS_UP,2019-11-17T14:19:16Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66493,MERGED,2019-11-17T15:52:58Z,2019-11-19T15:23:46Z,Add JohnTitor to rustc-guide toolstate notification list,JohnTitor,d8ea7866fc766c8366ff5d0fc04225270cdf11f6,1,Add JohnTitor to rustc-guide toolstate notification list Also update org names of some books,HEART,2019-11-18T20:49:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66497,MERGED,2019-11-17T18:14:41Z,2019-11-20T17:22:00Z,Fix #53820,Nadrieril,1425ae1154f3541a32e9ca607c09ce50cfb1298e,1,Tweak diagnostics code,HEART,2019-11-17T18:20:14Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66497,MERGED,2019-11-17T18:14:41Z,2019-11-20T17:22:00Z,Fix #53820,Nadrieril,1425ae1154f3541a32e9ca607c09ce50cfb1298e,1,Tweak diagnostics code,HEART,2019-11-17T18:34:20Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/66497,MERGED,2019-11-17T18:14:41Z,2019-11-20T17:22:00Z,Fix #53820,Nadrieril,1425ae1154f3541a32e9ca607c09ce50cfb1298e,1,Tweak diagnostics code,HEART,2019-11-17T20:34:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66497,MERGED,2019-11-17T18:14:41Z,2019-11-20T17:22:00Z,Fix #53820,Nadrieril,1425ae1154f3541a32e9ca607c09ce50cfb1298e,1,Tweak diagnostics code,HEART,2019-11-19T01:16:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/66497,MERGED,2019-11-17T18:14:41Z,2019-11-20T17:22:00Z,Fix #53820,Nadrieril,1425ae1154f3541a32e9ca607c09ce50cfb1298e,1,Tweak diagnostics code,HEART,2020-12-21T21:04:15Z,varkor,NA https://github.com/rust-lang/rust/pull/66503,MERGED,2019-11-18T00:32:17Z,2019-12-01T09:02:46Z,More useful test error messages on should_panic(expected=...) mismatch,thomasetter,16bf4f5e1b50773c6b4ec7b7524876440db69d1b,1,Simplify if else as suggested in PR feedback,HOORAY,2019-11-18T19:15:56Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66504,CLOSED,2019-11-18T01:53:40Z,2020-01-10T08:05:07Z,impl Add and AddAssign for String,Ruster-a11y,NA,NA,NA,THUMBS_UP,2019-11-19T08:00:50Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66504,CLOSED,2019-11-18T01:53:40Z,2020-01-10T08:05:07Z,impl Add and AddAssign for String,Ruster-a11y,NA,NA,NA,THUMBS_UP,2020-01-03T18:25:33Z,jplatte,NA https://github.com/rust-lang/rust/pull/66504,CLOSED,2019-11-18T01:53:40Z,2020-01-10T08:05:07Z,impl Add and AddAssign for String,Ruster-a11y,NA,NA,NA,THUMBS_UP,2020-08-05T22:27:22Z,calebsander,NA https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T02:34:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T02:34:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T05:34:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T10:33:25Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T20:49:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66506,CLOSED,2019-11-18T02:28:03Z,2019-11-20T02:44:48Z,Document unsafe in libcore,foeb,NA,NA,NA,HEART,2019-11-18T21:59:23Z,themasch,masch@masch.it https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T06:41:31Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T07:29:51Z,est31,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T07:47:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T08:45:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T10:09:57Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T10:39:14Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T12:26:19Z,Lokathor,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T12:44:18Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T14:19:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T14:59:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T15:56:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T16:18:20Z,darksv,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-18T20:56:55Z,Ixrec,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-19T01:29:35Z,cynecx,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-19T03:41:00Z,Pratyush,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-19T08:57:38Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-19T19:16:54Z,mati865,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T01:12:42Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T12:47:04Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T14:59:47Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T17:49:13Z,dmarcuse,dana@marcuse.us https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T17:49:15Z,dmarcuse,dana@marcuse.us https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T17:49:59Z,DataResearch,developGames@gmx.de https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T17:49:59Z,DataResearch,developGames@gmx.de https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T17:57:45Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:07:08Z,estebank,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:09:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:10:43Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2019-11-20T18:27:00Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:41:20Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:47:43Z,gz,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T18:53:04Z,Ben-Alderson,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T18:53:06Z,Ben-Alderson,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T19:18:17Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T20:06:56Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2019-11-20T20:06:57Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T20:06:58Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T20:09:51Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T21:26:51Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-20T21:48:52Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T22:05:52Z,chrish42,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T23:13:47Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T23:26:36Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-20T23:50:22Z,tikue,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-21T00:21:48Z,seongmin-kim,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T00:21:49Z,seongmin-kim,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2019-11-21T00:21:49Z,seongmin-kim,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T00:38:19Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T00:45:01Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-21T06:36:36Z,bash,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T09:44:34Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-21T09:44:51Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T10:46:01Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T10:59:10Z,futile,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T11:03:45Z,vittorioromeo,vittorio.romeo@outlook.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-21T12:58:30Z,mrjoe7,tomas.sedlak@masterminds.sk https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T12:58:30Z,mrjoe7,tomas.sedlak@masterminds.sk https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-21T13:54:36Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-21T23:11:31Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-22T21:04:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-23T04:03:53Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2019-11-23T04:03:54Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-23T10:17:48Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-23T10:17:48Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2019-11-23T10:17:50Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-23T11:15:21Z,elichai,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-23T11:15:23Z,elichai,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-23T12:04:59Z,koushiro,koushiro.cqx@gmail.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-23T17:06:39Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-23T17:17:28Z,95th,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-23T20:32:43Z,varkor,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2019-11-25T16:15:01Z,yuche,i@yuche.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-25T16:15:03Z,yuche,i@yuche.me https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-25T16:33:48Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2019-11-25T19:19:09Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2021-02-19T02:04:53Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,THUMBS_UP,2021-08-17T17:14:18Z,andrewsonin,sonin.cel@yandex.ru https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,HOORAY,2021-08-17T17:14:19Z,andrewsonin,sonin.cel@yandex.ru https://github.com/rust-lang/rust/pull/66507,MERGED,2019-11-18T05:46:43Z,2019-11-23T04:24:50Z,Enable `if` and `match` in constants behind a feature flag,ecstatic-morse,b09bb1569b23eaadcf22d7420f1ba9872c1088f7,1,Allow `Downcast` projections in `qualify_min_const_fn`,ROCKET,2021-08-17T17:14:20Z,andrewsonin,sonin.cel@yandex.ru https://github.com/rust-lang/rust/pull/66511,MERGED,2019-11-18T08:02:24Z,2019-11-19T15:23:42Z,std::error::Chain: remove Copy,haraldh,de122e673ac06f47652a593e0895f8367e049290,1,std::error::Chain: remove Copy remove Copy from Iterator as per comment https://github.com/rust-lang/rust/issues/58520#issuecomment-553682166,THUMBS_UP,2019-12-02T19:59:18Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66515,MERGED,2019-11-18T13:58:34Z,2019-11-21T17:52:37Z,Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`,Centril,44cebe5970d3cb0f87c4db7ecbf7fb8c8da2f456,13,reduce size of hir::ExprKind,ROCKET,2019-12-02T20:00:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66522,MERGED,2019-11-18T16:56:30Z,2019-11-26T05:07:21Z,Add support for sanitizer recover and tracking origins of uninitialized memory,tmiasko,bf121a33c4f9c3361e29545c6448e603952e6944,1,Create sanitizer passes in a separate function,THUMBS_UP,2019-12-05T18:19:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66522,MERGED,2019-11-18T16:56:30Z,2019-11-26T05:07:21Z,Add support for sanitizer recover and tracking origins of uninitialized memory,tmiasko,bf121a33c4f9c3361e29545c6448e603952e6944,1,Create sanitizer passes in a separate function,THUMBS_UP,2019-12-23T20:02:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66529,MERGED,2019-11-18T21:57:51Z,2019-11-19T15:23:38Z,resolve: Give derive helpers highest priority during resolution,petrochenkov,f74fe812fe802c71bd9f909cbce8a703a20ba479,5,resolve: Give derive helpers highest priority during resolution,HEART,2019-11-19T15:29:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/66529,MERGED,2019-11-18T21:57:51Z,2019-11-19T15:23:38Z,resolve: Give derive helpers highest priority during resolution,petrochenkov,f74fe812fe802c71bd9f909cbce8a703a20ba479,5,resolve: Give derive helpers highest priority during resolution,HEART,2019-12-02T19:55:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2019-11-19T10:39:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2019-11-19T11:09:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2019-11-29T19:49:28Z,pitaj,p.jaszkow@gmail.com https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2020-01-09T09:40:43Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2020-02-15T12:10:13Z,marmeladema,NA https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2020-06-23T13:31:08Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2020-08-17T04:30:05Z,kvark,NA https://github.com/rust-lang/rust/pull/66531,CLOSED,2019-11-18T23:10:22Z,2020-02-23T19:40:32Z,Add `ExactSizeIterator` impl for `iter::Chain`,LukasKalbertodt,NA,NA,NA,HEART,2020-10-06T21:09:36Z,LU15W1R7H,NA https://github.com/rust-lang/rust/pull/66532,MERGED,2019-11-18T23:13:44Z,2019-11-20T17:21:56Z,Generate DWARF address ranges for faster lookups,cuviper,4c2f1c802c4d582891a8e079949889d2462bbfd2,1,Mark -Zgenerate-arange-section as TRACKED,ROCKET,2019-12-02T20:07:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66536,MERGED,2019-11-19T02:48:16Z,2019-11-19T15:23:36Z,Move the definition of `QueryResult` into `plumbing.rs`.,nnethercote,c84fae13e5eb5a475dcb214b170aaf77a8c3783d,2,Move the definition of `QueryResult` into `plumbing.rs`. Because it's the only file that uses it and removes the need for importing it.,EYES,2019-11-19T11:48:43Z,tesuji,NA https://github.com/rust-lang/rust/pull/66537,MERGED,2019-11-19T03:32:39Z,2019-11-22T10:33:50Z,Delay an `is_local_ever_initialized` call.,nnethercote,965161714bd770d2a86d5864556e3a93d2ad9bc8,1,Delay an `is_local_ever_initialized` call. This commit moves the call after a `return` that almost always runs. It speeds up the `unicode_normalization` benchmark by about 2%.,ROCKET,2019-12-02T19:57:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66539,MERGED,2019-11-19T05:01:35Z,2019-11-24T01:38:45Z,Point at type in `let` assignment on type errors,estebank,34f03c01f688c0653b080914d4ab83461e1cfae2,101,Point at type in `let` assignment on type errors,HEART,2019-12-02T20:04:16Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66549,CLOSED,2019-11-19T18:14:35Z,2019-11-22T19:35:08Z,add PartialOrd for &mut,Dylan-DPC-zz,NA,NA,NA,THUMBS_UP,2019-11-20T11:01:25Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66561,MERGED,2019-11-19T22:26:57Z,2019-11-26T08:32:55Z,Add version mismatch help message for unimplemented trait,TimoFreiberg,2a0292f9aa96e32ca44ec7dc599c668fd735dbe8,1,fixup! Lowercase diagnostic message label,HEART,2019-11-25T22:23:27Z,estebank,NA https://github.com/rust-lang/rust/pull/66561,MERGED,2019-11-19T22:26:57Z,2019-11-26T08:32:55Z,Add version mismatch help message for unimplemented trait,TimoFreiberg,2a0292f9aa96e32ca44ec7dc599c668fd735dbe8,1,fixup! Lowercase diagnostic message label,HEART,2019-11-27T12:08:49Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/66561,MERGED,2019-11-19T22:26:57Z,2019-11-26T08:32:55Z,Add version mismatch help message for unimplemented trait,TimoFreiberg,2a0292f9aa96e32ca44ec7dc599c668fd735dbe8,1,fixup! Lowercase diagnostic message label,HEART,2019-12-23T21:31:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66567,MERGED,2019-11-20T06:32:08Z,2019-11-29T03:31:36Z,Use structured suggestion when requiring `Copy` constraint in type param,estebank,0f530ecb6875540f5cf5032ea7df54a38d01ab1c,3,review comments,HEART,2019-12-23T21:32:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66569,MERGED,2019-11-20T09:41:51Z,2019-11-25T22:46:07Z,GitHub Actions: preparations part 1,pietroalbini,90a37bce44d145715eeac9f1f2f34433fc813ef0,1,DO NOT MERGE: enable windows try builder,HOORAY,2019-11-20T10:26:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66569,MERGED,2019-11-20T09:41:51Z,2019-11-25T22:46:07Z,GitHub Actions: preparations part 1,pietroalbini,90a37bce44d145715eeac9f1f2f34433fc813ef0,1,DO NOT MERGE: enable windows try builder,HOORAY,2019-11-20T18:17:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66569,MERGED,2019-11-20T09:41:51Z,2019-11-25T22:46:07Z,GitHub Actions: preparations part 1,pietroalbini,90a37bce44d145715eeac9f1f2f34433fc813ef0,1,DO NOT MERGE: enable windows try builder,HOORAY,2019-11-20T19:35:34Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/66575,MERGED,2019-11-20T13:37:20Z,2019-11-23T01:13:16Z,Remove pretty printing of specific nodes in AST,Mark-Simulacrum,7ec20dd31ddf10e9d8b932a27cca17a056406e07,9,Remove pretty printing of specific nodes in AST The ability to print a specific item as identified by NodeId or path seems not particularly useful and certainly carries quite a bit of complexity with it.,THUMBS_UP,2019-12-02T19:56:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66576,MERGED,2019-11-20T15:38:40Z,2019-11-23T07:27:11Z,made gdb pretty-printing more robust when printing uninitialized vec,pnkfelix,9b40e0bb9af6641a23586fd5999430e4c7622636,1,made gdb pretty-printing script more robust when printing uninitialized vec. I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue #64343. In particular I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues #60826 and #65564.,HOORAY,2019-11-21T16:10:26Z,mati865,NA https://github.com/rust-lang/rust/pull/66576,MERGED,2019-11-20T15:38:40Z,2019-11-23T07:27:11Z,made gdb pretty-printing more robust when printing uninitialized vec,pnkfelix,9b40e0bb9af6641a23586fd5999430e4c7622636,1,made gdb pretty-printing script more robust when printing uninitialized vec. I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue #64343. In particular I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues #60826 and #65564.,THUMBS_UP,2019-11-28T04:31:52Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66576,MERGED,2019-11-20T15:38:40Z,2019-11-23T07:27:11Z,made gdb pretty-printing more robust when printing uninitialized vec,pnkfelix,9b40e0bb9af6641a23586fd5999430e4c7622636,1,made gdb pretty-printing script more robust when printing uninitialized vec. I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue #64343. In particular I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues #60826 and #65564.,HOORAY,2019-11-29T06:21:46Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66576,MERGED,2019-11-20T15:38:40Z,2019-11-23T07:27:11Z,made gdb pretty-printing more robust when printing uninitialized vec,pnkfelix,9b40e0bb9af6641a23586fd5999430e4c7622636,1,made gdb pretty-printing script more robust when printing uninitialized vec. I based this solution on my reading of: https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done That post claims that there is no clean way to check for garbage pointers and so this PR adopts the same solution of tentatively attempting to convert a dererence to a string which throws a clean exception on garbage that we can catch and recover from. I only made the change to vec and not the other pretty printers because I wanted to focus my effort on the simplest thing that would resolve issue #64343. In particular I *considered* generalizing this fix to work on the other datatypes in the pretty-printing support library but I don't want to invest effort in that until after we resolve our overall debugging support strategy; see also issues #60826 and #65564.,HOORAY,2019-12-02T20:07:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-20T16:08:04Z,mexus,NA https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-20T16:12:21Z,diaevd,diaevd@gmail.com https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-20T16:19:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-20T16:20:07Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-20T23:51:11Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-11-22T10:39:10Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2019-12-27T14:53:07Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2020-02-06T13:07:57Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2020-02-21T01:53:22Z,rkanati,rachel@automorphi.city https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2020-08-29T22:32:01Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2020-11-05T01:34:35Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2020-12-03T22:10:49Z,sloshwoven,NA https://github.com/rust-lang/rust/pull/66577,MERGED,2019-11-20T16:02:13Z,2020-01-31T00:04:16Z,Add `Iterator::map_while`,WaffleLapkin,db1a107b3f920637dc785fcc6d6bbe247a271e7b,3,Fill tracking issue for `iter_map_while` feature,THUMBS_UP,2021-09-19T07:09:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/66594,MERGED,2019-11-21T01:20:10Z,2019-11-24T05:34:24Z,Fix cycle when debug-printing opaque types,Aaron1011,2ba982d0e5ad87581e3685cba9207ffaf61a866e,1,Remove unnecessary clone,THUMBS_UP,2019-12-02T20:14:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-21T19:22:57Z,AlexEne,alex.ene0x11@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-23T10:44:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-27T09:57:04Z,lnicola,NA https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-27T16:34:46Z,DianaNites,NA https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-27T18:52:35Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,THUMBS_UP,2019-11-28T04:25:57Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-11-29T06:14:20Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,ROCKET,2019-11-29T06:14:23Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,THUMBS_UP,2019-11-29T06:14:27Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66597,MERGED,2019-11-21T03:41:52Z,2019-11-23T10:41:58Z,debuginfo: Support for std::collections::Hash* in windows debuggers.,MaulingMonkey,839d58ca56581c432d537ccca7a04010535d748c,3,debuginfo: Support for std::collections::Hash* in windows debuggers.,HEART,2019-12-02T20:13:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66598,CLOSED,2019-11-21T04:33:02Z,2019-11-26T22:13:38Z,Add an option to omit LLVM bitcode from rlibs.,nnethercote,NA,NA,NA,HEART,2019-11-21T16:12:57Z,mati865,NA https://github.com/rust-lang/rust/pull/66598,CLOSED,2019-11-21T04:33:02Z,2019-11-26T22:13:38Z,Add an option to omit LLVM bitcode from rlibs.,nnethercote,NA,NA,NA,HEART,2019-11-25T22:54:22Z,estebank,NA https://github.com/rust-lang/rust/pull/66598,CLOSED,2019-11-21T04:33:02Z,2019-11-26T22:13:38Z,Add an option to omit LLVM bitcode from rlibs.,nnethercote,NA,NA,NA,ROCKET,2019-11-26T20:41:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66603,MERGED,2019-11-21T11:24:11Z,2019-11-28T17:30:44Z,Fix #65413,Nadrieril,3f917120a09459c649cccf903752b2addb1c9a01,1,Reuse pat_constructor in split_grouped_ctors,HEART,2019-11-21T11:53:39Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2019-11-23T03:59:49Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2019-11-24T00:22:45Z,smmalis37,NA https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2019-11-25T17:16:02Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2019-11-26T17:13:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2019-12-04T13:52:42Z,iago-lito,NA https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2020-02-08T02:35:33Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-02-08T02:35:37Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-02-11T17:06:59Z,sjackman,sjackman@gmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-02-12T22:18:45Z,tmandry,NA https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-02-28T21:30:07Z,jplatte,NA https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-02-29T18:02:40Z,mc-allen,allen.marc@gmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-03-03T21:31:35Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-03-16T20:55:37Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HEART,2020-03-16T20:55:40Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2020-03-16T20:55:40Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-03-22T06:17:52Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HEART,2020-03-22T06:17:53Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2020-03-22T06:17:54Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HEART,2020-03-31T00:53:57Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HEART,2020-04-11T21:24:41Z,adamjstewart,ajstewart426@gmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,HOORAY,2020-04-11T21:24:42Z,adamjstewart,ajstewart426@gmail.com https://github.com/rust-lang/rust/pull/66605,MERGED,2019-11-21T12:58:45Z,2020-04-10T19:29:26Z,Stop explicitly depending on python 2,GuillaumeGomez,9682f0e14db95076454559a24c26287bcad57955,62,Auto merge of #66605 - GuillaumeGomez:drop-python2 r=Mark-Simulacrum Stop explicitly depending on python 2 This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available). The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such though only on one builder. This is intended as a temporary though likely long-lived measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time. Closes #65063 (as far as I can tell; please file explicit and separate issues or PRs if not).,THUMBS_UP,2020-04-11T21:24:43Z,adamjstewart,ajstewart426@gmail.com https://github.com/rust-lang/rust/pull/66606,MERGED,2019-11-21T13:46:12Z,2019-12-07T02:46:05Z,Add feature gate for mut refs in const fn,pvdrz,e01ad6a01abce35f59543bf38a280a05eb7f6929,2,Remove E0017 from error codes index,ROCKET,2019-11-21T14:44:42Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/66606,MERGED,2019-11-21T13:46:12Z,2019-12-07T02:46:05Z,Add feature gate for mut refs in const fn,pvdrz,e01ad6a01abce35f59543bf38a280a05eb7f6929,2,Remove E0017 from error codes index,HOORAY,2019-11-21T14:44:46Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/66606,MERGED,2019-11-21T13:46:12Z,2019-12-07T02:46:05Z,Add feature gate for mut refs in const fn,pvdrz,e01ad6a01abce35f59543bf38a280a05eb7f6929,2,Remove E0017 from error codes index,HOORAY,2019-11-22T11:40:58Z,RalfJung,NA https://github.com/rust-lang/rust/pull/66606,MERGED,2019-11-21T13:46:12Z,2019-12-07T02:46:05Z,Add feature gate for mut refs in const fn,pvdrz,e01ad6a01abce35f59543bf38a280a05eb7f6929,2,Remove E0017 from error codes index,HOORAY,2019-11-23T01:18:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66606,MERGED,2019-11-21T13:46:12Z,2019-12-07T02:46:05Z,Add feature gate for mut refs in const fn,pvdrz,e01ad6a01abce35f59543bf38a280a05eb7f6929,2,Remove E0017 from error codes index,HOORAY,2019-11-23T09:09:42Z,lqd,NA https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-11-21T20:11:28Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-11-21T21:38:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-11-21T22:41:28Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-11-23T01:05:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-11-30T14:08:12Z,varkor,NA https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-12-05T16:44:07Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/66612,MERGED,2019-11-21T18:56:47Z,2019-12-01T03:38:18Z,Initial implementation of or-pattern usefulness checking,Nadrieril,0f4c5fb20cf5d499bc3d6426b1909863f1c86a5b,2,Apply suggestions from code review Co-Authored-By: varkor ,HEART,2019-12-23T20:52:02Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66637,MERGED,2019-11-22T17:31:23Z,2019-11-23T01:13:08Z,fix reoccuring typo: dereferencable -> dereferenceable,RalfJung,9ff91ab2d3151078053bc3966f7163d048209d38,4,fix reoccuring typo: dereferencable -> dereferenceable,HEART,2019-11-22T19:24:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/66642,MERGED,2019-11-22T19:08:30Z,2019-11-28T20:39:54Z,Create promoted MIR fragments for `const` and `static`s,ecstatic-morse,f9ed2199ff5a69b88d43949c138042a42ecd98b5,1,Create promoted MIR fragments in `const` and `static`s The previous strategy of removing `Drop` and `StorageDead` for promoted locals only worked for rvalue lifetime extension. We now use the same implementation for promotion across all kinds of items.,THUMBS_UP,2019-11-23T19:53:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/66646,MERGED,2019-11-22T21:18:06Z,2019-11-27T00:32:46Z,refactor goto_block and also add unwind_to_block,RalfJung,6797d52ee02b19675621718dca823794ffb921b5,1,make sure we handle all transmute invocations including diverging ones,HEART,2019-11-22T21:39:18Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66647,MERGED,2019-11-22T21:38:29Z,2019-11-24T21:39:18Z,rustc_plugin: Remove support for syntactic plugins,petrochenkov,f89e6c881175503fd96a21e77691955ec90b5274,31,rustc_plugin: Remove support for syntactic plugins,HEART,2019-11-24T08:19:00Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/66650,MERGED,2019-11-22T22:50:08Z,2019-12-12T02:11:53Z,Remove uniform array move MIR passes,matthewjasper,d96485d49e3745a9b9f4b2ed6ba9cebf265f142e,13,Add more tests for borrowck and dropck slice pattern handling,HEART,2019-11-23T15:04:09Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66650,MERGED,2019-11-22T22:50:08Z,2019-12-12T02:11:53Z,Remove uniform array move MIR passes,matthewjasper,d96485d49e3745a9b9f4b2ed6ba9cebf265f142e,13,Add more tests for borrowck and dropck slice pattern handling,HEART,2019-11-23T15:08:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/66650,MERGED,2019-11-22T22:50:08Z,2019-12-12T02:11:53Z,Remove uniform array move MIR passes,matthewjasper,d96485d49e3745a9b9f4b2ed6ba9cebf265f142e,13,Add more tests for borrowck and dropck slice pattern handling,HEART,2019-11-23T21:13:51Z,lqd,NA https://github.com/rust-lang/rust/pull/66650,MERGED,2019-11-22T22:50:08Z,2019-12-12T02:11:53Z,Remove uniform array move MIR passes,matthewjasper,d96485d49e3745a9b9f4b2ed6ba9cebf265f142e,13,Add more tests for borrowck and dropck slice pattern handling,HEART,2019-11-26T11:42:38Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/66651,MERGED,2019-11-22T23:40:31Z,2019-12-03T16:27:44Z,Add `enclosing scope` parameter to `rustc_on_unimplemented`,Areredify,1d0c015f9b5e4da3695ed23f269dc51a8d09b8a9,6,added enclosing_scope attr to Try trait and fixed ui tests accordingly,HEART,2019-11-25T19:01:30Z,estebank,NA https://github.com/rust-lang/rust/pull/66651,MERGED,2019-11-22T23:40:31Z,2019-12-03T16:27:44Z,Add `enclosing scope` parameter to `rustc_on_unimplemented`,Areredify,1d0c015f9b5e4da3695ed23f269dc51a8d09b8a9,6,added enclosing_scope attr to Try trait and fixed ui tests accordingly,HEART,2019-12-07T16:54:52Z,mibac138,NA https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T09:02:21Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T13:34:57Z,laanwj,NA https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T14:46:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T15:36:20Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T18:34:10Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-25T20:22:59Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2019-11-27T04:28:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2020-01-07T16:16:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2020-01-31T07:10:19Z,sajattack,NA https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2020-07-02T06:31:19Z,jjyr,jjyruby@gmail.com https://github.com/rust-lang/rust/pull/66661,MERGED,2019-11-23T07:17:10Z,2019-11-27T03:56:02Z,Add riscv64gc-unknown-linux-gnu target,msizanoen1,75dac389fb168159e0b049f72141f889b7215889,2,Add riscv64gc-unknown-linux-gnu target,HOORAY,2020-07-06T21:11:02Z,FlashSheridan,NA https://github.com/rust-lang/rust/pull/66662,MERGED,2019-11-23T07:57:47Z,2019-12-01T09:02:42Z,Miri: run panic-catching tests in liballoc,RalfJung,a2299799e6193799f4d2cb546e56589c5dd587aa,2,enable more panic-catching tests in Miri,HOORAY,2019-11-23T14:48:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66662,MERGED,2019-11-23T07:57:47Z,2019-12-01T09:02:42Z,Miri: run panic-catching tests in liballoc,RalfJung,a2299799e6193799f4d2cb546e56589c5dd587aa,2,enable more panic-catching tests in Miri,HOORAY,2019-11-23T19:51:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/66670,MERGED,2019-11-23T14:43:49Z,2019-12-26T13:15:24Z,Normalize ident,crlf0710,27e7a1baedbcc5ddaf44f930860828dae99a7ebf,3,Add unicode-normalization to whitelist.,CONFUSED,2020-01-03T16:41:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66673,MERGED,2019-11-23T15:40:37Z,2019-11-24T01:38:30Z,Move def collector from `rustc` to `rustc_resolve`,petrochenkov,bbbdbb0e44bb4cea653584017acce4bcda158939,5,Move def collector from `rustc` to `rustc_resolve`,THUMBS_UP,2019-11-23T15:53:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66673,MERGED,2019-11-23T15:40:37Z,2019-11-24T01:38:30Z,Move def collector from `rustc` to `rustc_resolve`,petrochenkov,bbbdbb0e44bb4cea653584017acce4bcda158939,5,Move def collector from `rustc` to `rustc_resolve`,THUMBS_UP,2019-11-23T18:02:04Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66675,MERGED,2019-11-23T17:47:25Z,2019-11-27T08:01:10Z,Support anchors intra doc links,GuillaumeGomez,c1ea1fd2b03b16bfeab01cbcd7bae976ab596923,10,Update error messages,HEART,2019-11-23T20:06:51Z,killercup,NA https://github.com/rust-lang/rust/pull/66679,MERGED,2019-11-23T21:13:48Z,2019-12-01T09:02:41Z,Improve lifetime errors with implicit trait object lifetimes,mark-i-m,2a86b6cb33536efe5d4d10764b04542205abe581,1,minor fix,HEART,2019-11-25T02:09:35Z,estebank,NA https://github.com/rust-lang/rust/pull/66682,MERGED,2019-11-24T00:06:56Z,2019-11-25T16:02:56Z,Highlight parts of fn in type errors,estebank,9d7774c64fcbe9f535f649b51add9a701f459526,2,review comments: remove unnecessary `&str` to `String` conversions,HEART,2019-11-24T09:34:49Z,bjorn3,NA https://github.com/rust-lang/rust/pull/66682,MERGED,2019-11-24T00:06:56Z,2019-11-25T16:02:56Z,Highlight parts of fn in type errors,estebank,9d7774c64fcbe9f535f649b51add9a701f459526,2,review comments: remove unnecessary `&str` to `String` conversions,HEART,2019-11-24T09:51:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66682,MERGED,2019-11-24T00:06:56Z,2019-11-25T16:02:56Z,Highlight parts of fn in type errors,estebank,9d7774c64fcbe9f535f649b51add9a701f459526,2,review comments: remove unnecessary `&str` to `String` conversions,HEART,2019-11-25T02:23:41Z,cynecx,NA https://github.com/rust-lang/rust/pull/66682,MERGED,2019-11-24T00:06:56Z,2019-11-25T16:02:56Z,Highlight parts of fn in type errors,estebank,9d7774c64fcbe9f535f649b51add9a701f459526,2,review comments: remove unnecessary `&str` to `String` conversions,HEART,2019-11-26T12:19:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/66691,MERGED,2019-11-24T10:08:23Z,2019-11-27T15:39:36Z,Format libcore with rustfmt,dtolnay,166471e7f1f05fe272a4df99c20c1ffc0204a25f,1,Bless ui tests for libcore reformat,THUMBS_UP,2019-11-28T03:46:02Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/66691,MERGED,2019-11-24T10:08:23Z,2019-11-27T15:39:36Z,Format libcore with rustfmt,dtolnay,166471e7f1f05fe272a4df99c20c1ffc0204a25f,1,Bless ui tests for libcore reformat,THUMBS_UP,2019-11-28T15:11:03Z,mati865,NA https://github.com/rust-lang/rust/pull/66705,MERGED,2019-11-24T15:51:11Z,2019-12-01T03:38:14Z,Atomic as_mut_ptr,pitdicker,d34090a10a6517f3e3ea8528936175953ce8bc3d,1,Fill tracking issue,HEART,2019-11-29T13:07:04Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/66705,MERGED,2019-11-24T15:51:11Z,2019-12-01T03:38:14Z,Atomic as_mut_ptr,pitdicker,d34090a10a6517f3e3ea8528936175953ce8bc3d,1,Fill tracking issue,HEART,2019-12-23T21:44:42Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66716,MERGED,2019-11-24T20:53:44Z,2020-01-17T03:55:19Z,Implement `DebugStruct::non_exhaustive`.,derekdreery,73124df6eba9d81affb3ef597fdaeb4fce82f7af,1,Rust ./x.py fmt,THUMBS_UP,2019-11-24T20:56:34Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/66716,MERGED,2019-11-24T20:53:44Z,2020-01-17T03:55:19Z,Implement `DebugStruct::non_exhaustive`.,derekdreery,73124df6eba9d81affb3ef597fdaeb4fce82f7af,1,Rust ./x.py fmt,THUMBS_UP,2019-12-02T17:49:59Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/66716,MERGED,2019-11-24T20:53:44Z,2020-01-17T03:55:19Z,Implement `DebugStruct::non_exhaustive`.,derekdreery,73124df6eba9d81affb3ef597fdaeb4fce82f7af,1,Rust ./x.py fmt,THUMBS_UP,2019-12-17T13:42:04Z,pitdicker,NA https://github.com/rust-lang/rust/pull/66716,MERGED,2019-11-24T20:53:44Z,2020-01-17T03:55:19Z,Implement `DebugStruct::non_exhaustive`.,derekdreery,73124df6eba9d81affb3ef597fdaeb4fce82f7af,1,Rust ./x.py fmt,THUMBS_UP,2020-01-22T18:35:00Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/66716,MERGED,2019-11-24T20:53:44Z,2020-01-17T03:55:19Z,Implement `DebugStruct::non_exhaustive`.,derekdreery,73124df6eba9d81affb3ef597fdaeb4fce82f7af,1,Rust ./x.py fmt,THUMBS_UP,2020-01-22T21:28:13Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/66721,MERGED,2019-11-24T22:40:36Z,2020-02-15T13:48:40Z,implement LowerExp and UpperExp for integers,maxbla,a8fe47d1756df0fb68f6ed2edd2cedfb3cc66d7c,2,implement LowerExp and UpperExp for integers,THUMBS_UP,2020-02-21T07:21:05Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-25T13:53:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-26T04:51:37Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-26T11:27:02Z,CryZe,NA https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-26T11:48:38Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-26T13:14:16Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-11-26T14:22:33Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2019-12-09T22:47:06Z,Diggsey,NA https://github.com/rust-lang/rust/pull/66735,MERGED,2019-11-25T11:49:04Z,2019-12-16T15:31:41Z,Add str::strip_prefix and str::strip_suffix,SOF3,6176051dd0605b77c304aa647f277f4b069763a9,1,Set tracking issue for str_strip,THUMBS_UP,2020-11-01T15:48:07Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/66750,MERGED,2019-11-25T17:31:47Z,2019-12-03T21:52:27Z,Update the `wasi` crate for `wasm32-wasi`,alexcrichton,f3fb1c5e95b9fef29df00f0924a27790b03c524b,12,"Update the `wasi` crate for `wasm32-wasi` This commit updates the `wasi` crate used by the standard library which is used to implement most of the functionality of libstd on the `wasm32-wasi` target. This update comes with a brand new crate structure in the `wasi` crate which caused quite a few changes for the wasi target here but it also comes with a significant change to where the functionality is coming from. The WASI specification is organized into ""snapshots"" and a new snapshot happened recently so the WASI APIs themselves have changed since the previous revision. This had only minor impact on the public facing surface area of libstd only changing on `u32` to a `u64` in an unstable API. The actual source for all of these types and such however is now coming from the `wasi_preview_snapshot1` module instead of the `wasi_unstable` module like before. This means that any implementors generating binaries will need to ensure that their embedding environment handles the `wasi_preview_snapshot1` module.",EYES,2019-11-27T13:01:54Z,kubkon,kubkon@jakubkonka.com https://github.com/rust-lang/rust/pull/66750,MERGED,2019-11-25T17:31:47Z,2019-12-03T21:52:27Z,Update the `wasi` crate for `wasm32-wasi`,alexcrichton,f3fb1c5e95b9fef29df00f0924a27790b03c524b,12,"Update the `wasi` crate for `wasm32-wasi` This commit updates the `wasi` crate used by the standard library which is used to implement most of the functionality of libstd on the `wasm32-wasi` target. This update comes with a brand new crate structure in the `wasi` crate which caused quite a few changes for the wasi target here but it also comes with a significant change to where the functionality is coming from. The WASI specification is organized into ""snapshots"" and a new snapshot happened recently so the WASI APIs themselves have changed since the previous revision. This had only minor impact on the public facing surface area of libstd only changing on `u32` to a `u64` in an unstable API. The actual source for all of these types and such however is now coming from the `wasi_preview_snapshot1` module instead of the `wasi_unstable` module like before. This means that any implementors generating binaries will need to ensure that their embedding environment handles the `wasi_preview_snapshot1` module.",EYES,2019-11-28T13:20:02Z,marmistrz,marmistrz.dev@zoho.eu https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T11:01:25Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T12:58:57Z,bash,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T14:07:28Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T14:09:41Z,RustyYato,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T15:36:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_DOWN,2019-11-26T15:40:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T15:56:52Z,johnthagen,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T16:04:20Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T16:47:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T18:49:11Z,ollie27,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-26T19:46:37Z,cpeterso,cpeterson@mozilla.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-27T19:14:42Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-28T07:46:49Z,carrotflakes,carrotflakes@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-28T12:51:53Z,petamoriken,moriken@kimamass.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-28T13:26:19Z,gyu-don,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-29T15:07:42Z,sunjay,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-29T16:37:25Z,phaazon,dimitri.sabadie@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-29T17:11:10Z,daira,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-11-29T22:50:24Z,cx88,cx8128@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2019-12-08T16:49:24Z,1011X,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-04-26T16:06:25Z,jspurim,jspurim@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-04-30T01:27:54Z,purpleposeidon,purpleposeidon@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-06-12T05:12:29Z,vpzomtrrfrt,colin@vpzom.click https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-06-28T19:06:16Z,waldyrious,waldyrious@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-07-01T08:34:37Z,aaronfranke,arnfranke@yahoo.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-07-08T00:24:40Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-07-16T02:52:12Z,robjtede,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-08-06T20:40:17Z,math4tots,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2020-08-18T11:56:11Z,Aurora2500,NA https://github.com/rust-lang/rust/pull/66769,MERGED,2019-11-26T09:49:17Z,2019-11-28T00:36:26Z,Add core::{f32 f64}::consts::TAU.,m-ou-se,d220ed4fd72a26e40edf0d61bcd9ac52dc87f009,2,Add tracking issue number.,THUMBS_UP,2022-06-28T20:08:25Z,JockeTF,NA https://github.com/rust-lang/rust/pull/66771,MERGED,2019-11-26T10:39:33Z,2019-12-16T15:31:39Z,Stabilize the `core::panic` module,SimonSapin,eab1dc9b562c4ff128575d6af7afe819e34f9340,1,Stabilize the `core::panic` module `std::panic` is already stable. `core::panic::PanicInfo` and `core::panic::Location` are stable and can be used through that path because of a bug in stability checking: https://github.com/rust-lang/rust/issues/15702,LAUGH,2019-11-26T14:15:37Z,kennytm,NA https://github.com/rust-lang/rust/pull/66771,MERGED,2019-11-26T10:39:33Z,2019-12-16T15:31:39Z,Stabilize the `core::panic` module,SimonSapin,eab1dc9b562c4ff128575d6af7afe819e34f9340,1,Stabilize the `core::panic` module `std::panic` is already stable. `core::panic::PanicInfo` and `core::panic::Location` are stable and can be used through that path because of a bug in stability checking: https://github.com/rust-lang/rust/issues/15702,LAUGH,2020-03-11T12:02:52Z,eun-ice,NA https://github.com/rust-lang/rust/pull/66776,MERGED,2019-11-26T13:08:18Z,2019-11-26T19:05:30Z,"Revert ""DO NOT MERGE: enable windows try builder""",Mark-Simulacrum,47b3d4d8c937f174a8863fb123356ad51bd524b7,1,"Revert ""DO NOT MERGE: enable windows try builder"" This reverts commit 90a37bce44d145715eeac9f1f2f34433fc813ef0.",EYES,2019-11-26T13:17:04Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/66776,MERGED,2019-11-26T13:08:18Z,2019-11-26T19:05:30Z,"Revert ""DO NOT MERGE: enable windows try builder""",Mark-Simulacrum,47b3d4d8c937f174a8863fb123356ad51bd524b7,1,"Revert ""DO NOT MERGE: enable windows try builder"" This reverts commit 90a37bce44d145715eeac9f1f2f34433fc813ef0.",EYES,2019-11-26T14:07:44Z,kennytm,NA https://github.com/rust-lang/rust/pull/66789,MERGED,2019-11-26T20:38:49Z,2019-12-02T06:15:27Z,rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.,eddyb,a9976d89ed721184a95a24f109a65916f2905793,11,rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.,THUMBS_UP,2019-11-27T21:42:38Z,estebank,NA https://github.com/rust-lang/rust/pull/66789,MERGED,2019-11-26T20:38:49Z,2019-12-02T06:15:27Z,rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.,eddyb,a9976d89ed721184a95a24f109a65916f2905793,11,rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.,THUMBS_UP,2019-11-29T16:19:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66801,CLOSED,2019-11-27T05:53:24Z,2020-01-20T11:56:27Z,Add explicit XP targets,ChrisDenton,NA,NA,NA,THUMBS_UP,2019-11-28T23:44:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66801,CLOSED,2019-11-27T05:53:24Z,2020-01-20T11:56:27Z,Add explicit XP targets,ChrisDenton,NA,NA,NA,THUMBS_UP,2019-12-11T12:00:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/66801,CLOSED,2019-11-27T05:53:24Z,2020-01-20T11:56:27Z,Add explicit XP targets,ChrisDenton,NA,NA,NA,THUMBS_UP,2019-12-11T18:38:36Z,estebank,NA https://github.com/rust-lang/rust/pull/66801,CLOSED,2019-11-27T05:53:24Z,2020-01-20T11:56:27Z,Add explicit XP targets,ChrisDenton,NA,NA,NA,THUMBS_UP,2019-12-20T19:28:29Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/66813,CLOSED,2019-11-27T17:34:26Z,2020-03-30T11:48:04Z,Solution to trait alias bug #65673,alexreg,NA,NA,NA,THUMBS_UP,2019-11-27T21:37:25Z,estebank,NA https://github.com/rust-lang/rust/pull/66815,MERGED,2019-11-27T18:11:54Z,2019-12-05T17:46:32Z,Reorganize borrow check diagnostic code,mark-i-m,b998e8306423ea3746afcc92e3482a72cce75f2b,2,more private,THUMBS_UP,2019-11-27T19:22:33Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/66815,MERGED,2019-11-27T18:11:54Z,2019-12-05T17:46:32Z,Reorganize borrow check diagnostic code,mark-i-m,b998e8306423ea3746afcc92e3482a72cce75f2b,2,more private,THUMBS_UP,2019-11-28T13:22:57Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/66815,MERGED,2019-11-27T18:11:54Z,2019-12-05T17:46:32Z,Reorganize borrow check diagnostic code,mark-i-m,b998e8306423ea3746afcc92e3482a72cce75f2b,2,more private,THUMBS_UP,2019-11-28T19:51:43Z,estebank,NA https://github.com/rust-lang/rust/pull/66815,MERGED,2019-11-27T18:11:54Z,2019-12-05T17:46:32Z,Reorganize borrow check diagnostic code,mark-i-m,b998e8306423ea3746afcc92e3482a72cce75f2b,2,more private,THUMBS_UP,2019-12-10T19:58:51Z,amandasystems,mail@amandastjerna.se https://github.com/rust-lang/rust/pull/66820,MERGED,2019-11-27T19:15:19Z,2019-11-30T15:54:05Z,Format libstd with rustfmt,dtolnay,9ad085070746b5ff4c3262bb65c2cdefe4269198,1,Bless ui test for libstd reformat,HOORAY,2019-11-27T20:36:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66820,MERGED,2019-11-27T19:15:19Z,2019-11-30T15:54:05Z,Format libstd with rustfmt,dtolnay,9ad085070746b5ff4c3262bb65c2cdefe4269198,1,Bless ui test for libstd reformat,HOORAY,2019-11-28T15:08:55Z,mati865,NA https://github.com/rust-lang/rust/pull/66820,MERGED,2019-11-27T19:15:19Z,2019-11-30T15:54:05Z,Format libstd with rustfmt,dtolnay,9ad085070746b5ff4c3262bb65c2cdefe4269198,1,Bless ui test for libstd reformat,HOORAY,2019-11-28T17:17:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/66823,CLOSED,2019-11-27T20:28:49Z,2019-12-02T15:24:01Z,Making RWLock::new const fn,elichai,NA,NA,NA,THUMBS_UP,2019-11-27T20:35:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66823,CLOSED,2019-11-27T20:28:49Z,2019-12-02T15:24:01Z,Making RWLock::new const fn,elichai,NA,NA,NA,THUMBS_UP,2019-11-27T23:27:01Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/66835,MERGED,2019-11-28T10:31:32Z,2019-12-06T07:44:12Z,std:win: avoid WSA_FLAG_NO_INHERIT flag and don't use SetHandleInformation on UWP,AviKozokin,fa8b54901f1236cbcd48205856e8766496664105,1,added correct error code for WSASocketW failure fallback,ROCKET,2019-11-28T11:36:43Z,yogevyuval,yogevyuval@gmail.com https://github.com/rust-lang/rust/pull/66835,MERGED,2019-11-28T10:31:32Z,2019-12-06T07:44:12Z,std:win: avoid WSA_FLAG_NO_INHERIT flag and don't use SetHandleInformation on UWP,AviKozokin,fa8b54901f1236cbcd48205856e8766496664105,1,added correct error code for WSASocketW failure fallback,ROCKET,2019-11-28T11:37:25Z,hekmati,michael.hekmati@gmail.com https://github.com/rust-lang/rust/pull/66835,MERGED,2019-11-28T10:31:32Z,2019-12-06T07:44:12Z,std:win: avoid WSA_FLAG_NO_INHERIT flag and don't use SetHandleInformation on UWP,AviKozokin,fa8b54901f1236cbcd48205856e8766496664105,1,added correct error code for WSASocketW failure fallback,ROCKET,2019-11-28T11:58:15Z,Hezko,NA https://github.com/rust-lang/rust/pull/66852,CLOSED,2019-11-28T21:29:21Z,2019-12-12T11:11:52Z,Add inherent `try_from` and `try_into` methods to integer types,SimonSapin,NA,NA,NA,HEART,2019-11-28T22:51:35Z,RalfJung,NA https://github.com/rust-lang/rust/pull/66858,MERGED,2019-11-29T03:41:09Z,2019-12-01T03:38:03Z,Use LLVMAddAnalysisPasses instead of Rust's wrapper,0dvictor,b41b1d3407068fad2fc0f4e0cc7db92cb3589bc6,4,Use LLVMAddAnalysisPasses instead of Rust's wrapper LLVM exposes a C API `LLVMAddAnalysisPasses` and hence Rust's own wrapper `LLVMRustAddAnalysisPasses` is not needed anymore.,THUMBS_UP,2019-11-29T09:16:58Z,mati865,NA https://github.com/rust-lang/rust/pull/66858,MERGED,2019-11-29T03:41:09Z,2019-12-01T03:38:03Z,Use LLVMAddAnalysisPasses instead of Rust's wrapper,0dvictor,b41b1d3407068fad2fc0f4e0cc7db92cb3589bc6,4,Use LLVMAddAnalysisPasses instead of Rust's wrapper LLVM exposes a C API `LLVMAddAnalysisPasses` and hence Rust's own wrapper `LLVMRustAddAnalysisPasses` is not needed anymore.,THUMBS_UP,2019-12-01T03:51:53Z,tesuji,NA https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-11-29T20:28:26Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-11-30T00:57:53Z,varkor,NA https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-11-30T09:11:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-12-23T07:00:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-12-27T14:47:20Z,GrayJack,NA https://github.com/rust-lang/rust/pull/66877,MERGED,2019-11-29T20:15:26Z,2019-12-22T22:38:44Z,Add simpler entry points to const eval for common usages.,skinny121,c010d843aacc32ed2bc03d36121aa7f6e08ef045,23,Add simpler entry points to const eval for common usages.,HEART,2019-12-28T07:28:14Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,THUMBS_UP,2019-12-03T02:10:50Z,novacrazy,NA https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,THUMBS_UP,2019-12-11T00:46:53Z,carado,NA https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,HEART,2019-12-19T15:51:18Z,cristaloleg,oleg@hey.com https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,THUMBS_UP,2019-12-20T20:09:31Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,HEART,2019-12-22T23:23:39Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,HEART,2019-12-23T19:00:49Z,lnicola,NA https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,THUMBS_UP,2020-02-18T12:10:48Z,atopuzov,NA https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,HEART,2020-12-24T20:12:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/66881,MERGED,2019-11-29T22:35:17Z,2019-12-11T12:29:48Z,Optimize Ord trait implementation for bool,krishna-veerareddy,1f07aa582a41e6fc253139909d3bf9bfd04a9d6d,1,Add better documentation for unsafe block,THUMBS_UP,2020-12-24T20:12:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/66882,MERGED,2019-11-29T23:06:39Z,2019-12-07T05:53:04Z,Update LLVM submodule,mati865,049ca749c45aad70cd0d66c4ca48590512659cb6,1,Update LLVM submodule,HEART,2019-12-01T22:28:23Z,novacrazy,NA https://github.com/rust-lang/rust/pull/66882,MERGED,2019-11-29T23:06:39Z,2019-12-07T05:53:04Z,Update LLVM submodule,mati865,049ca749c45aad70cd0d66c4ca48590512659cb6,1,Update LLVM submodule,HEART,2019-12-07T05:59:49Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/66883,MERGED,2019-11-29T23:31:41Z,2019-12-01T03:37:59Z,rustc_typeck: gate AnonConst's generics on feature(const_generics).,eddyb,584ede5f3034af8b1b64518385e201de4942637c,1,rustc_typeck: gate AnonConst's generics on feature(const_generics).,THUMBS_UP,2019-11-30T00:52:21Z,varkor,NA https://github.com/rust-lang/rust/pull/66883,MERGED,2019-11-29T23:31:41Z,2019-12-01T03:37:59Z,rustc_typeck: gate AnonConst's generics on feature(const_generics).,eddyb,584ede5f3034af8b1b64518385e201de4942637c,1,rustc_typeck: gate AnonConst's generics on feature(const_generics).,THUMBS_UP,2019-11-30T01:44:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/66883,MERGED,2019-11-29T23:31:41Z,2019-12-01T03:37:59Z,rustc_typeck: gate AnonConst's generics on feature(const_generics).,eddyb,584ede5f3034af8b1b64518385e201de4942637c,1,rustc_typeck: gate AnonConst's generics on feature(const_generics).,HOORAY,2019-12-06T11:41:11Z,jplatte,NA https://github.com/rust-lang/rust/pull/66884,CLOSED,2019-11-30T00:25:59Z,2020-02-03T22:55:24Z,More const int functions,9999years,NA,NA,NA,THUMBS_UP,2019-11-30T01:46:36Z,lqf96,lqf.1996121@gmail.com https://github.com/rust-lang/rust/pull/66884,CLOSED,2019-11-30T00:25:59Z,2020-02-03T22:55:24Z,More const int functions,9999years,NA,NA,NA,THUMBS_UP,2019-12-10T13:36:50Z,CryZe,NA https://github.com/rust-lang/rust/pull/66884,CLOSED,2019-11-30T00:25:59Z,2020-02-03T22:55:24Z,More const int functions,9999years,NA,NA,NA,HEART,2019-12-23T00:22:32Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/66899,MERGED,2019-11-30T12:18:13Z,2020-01-06T22:22:45Z,Standard library support for riscv64gc-unknown-linux-gnu,msizanoen1,d61e193cd0867da2fbe81fca349bd1c0afc36d08,1,Update cc crate,HEART,2019-12-08T04:23:58Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/66903,MERGED,2019-11-30T13:56:02Z,2019-12-03T21:52:19Z,parse_enum_item -> parse_enum_variant,Centril,cb08677869568993bda926fe14c607b20163b898,1,parse_enum_item -> parse_enum_variant,THUMBS_UP,2019-12-02T17:33:25Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/66918,MERGED,2019-12-01T05:34:52Z,2019-12-02T06:15:13Z,Add crc and crypto to target feature whitelist on arm,makotokato,d86d5ab08ff42f9e5d08e880822e5e64d25792a6,1,Add crc and crypto to target feature whitelist on arm,THUMBS_UP,2019-12-23T21:26:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",HEART,2019-12-12T21:43:00Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",HEART,2019-12-12T23:34:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-13T06:06:09Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-13T12:15:18Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",HEART,2019-12-14T21:41:18Z,faern,NA https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-15T17:33:01Z,iliana,iliana@buttslol.net https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-15T19:48:54Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",HEART,2019-12-25T02:59:42Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-25T14:00:51Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2019-12-25T17:00:11Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2020-01-03T17:06:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2020-01-04T11:17:55Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2020-03-21T08:54:33Z,segfaultsourcery,NA https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",HEART,2020-03-21T08:54:35Z,segfaultsourcery,NA https://github.com/rust-lang/rust/pull/66919,MERGED,2019-12-01T06:18:19Z,2019-12-26T00:27:29Z,Deprecate Error::description for real,dtolnay,4646a88b7a1e68326d092b9cbbbbdd616a51077f,30,"Deprecate Error::description for real `description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = ""1.41.0"")] to Error::description; - moves description (and cause which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.",THUMBS_UP,2020-03-25T16:12:04Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/66927,MERGED,2019-12-01T11:13:00Z,2019-12-07T17:59:22Z,Miri core engine: use throw_ub instead of throw_panic,RalfJung,15f159addefd8fea7564ba7617c8af78582b7816,1,fix compile-fail tests,HEART,2019-12-01T16:33:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/66927,MERGED,2019-12-01T11:13:00Z,2019-12-07T17:59:22Z,Miri core engine: use throw_ub instead of throw_panic,RalfJung,15f159addefd8fea7564ba7617c8af78582b7816,1,fix compile-fail tests,HEART,2019-12-02T15:42:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/66931,MERGED,2019-12-01T12:09:16Z,2019-12-22T13:34:25Z,Allocate HIR on an arena 1/4,cjgillot,baa49b2343b852d4bd4151f7c42e36a3351d0981,2,Nits.,HEART,2019-12-12T23:47:11Z,estebank,NA https://github.com/rust-lang/rust/pull/66931,MERGED,2019-12-01T12:09:16Z,2019-12-22T13:34:25Z,Allocate HIR on an arena 1/4,cjgillot,baa49b2343b852d4bd4151f7c42e36a3351d0981,2,Nits.,HEART,2020-01-03T10:59:57Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/66931,MERGED,2019-12-01T12:09:16Z,2019-12-22T13:34:25Z,Allocate HIR on an arena 1/4,cjgillot,baa49b2343b852d4bd4151f7c42e36a3351d0981,2,Nits.,HEART,2020-01-03T15:29:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66938,MERGED,2019-12-01T19:14:04Z,2020-03-28T23:19:45Z,Add lint when no doc is present at the crate-level,GuillaumeGomez,77621317d643cc5d13da60b26ab68b057668e688,4,Auto merge of #66938 - GuillaumeGomez:lint-for-no-crate-level-doc r=Dylan-DPC Add lint when no doc is present at the crate-level Follow-up of #66267. r? @kinnison,CONFUSED,2019-12-02T19:21:32Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/66963,MERGED,2019-12-02T15:50:49Z,2019-12-11T15:44:35Z,rustc: include ParamEnv in global trait select/eval cache keys.,eddyb,1d1298ea5f83b1e6714f25b0b63a78c37712b240,4,rustc: include ParamEnv in global trait select/eval cache keys.,THUMBS_UP,2019-12-06T23:49:16Z,estebank,NA https://github.com/rust-lang/rust/pull/66967,MERGED,2019-12-02T16:16:08Z,2019-12-03T16:27:23Z,Remove hack for top-level or-patterns in match checking,Nadrieril,1c1bec2f6dbed0910b2e0ca19cffb92d95be4ee5,3,Remove top-level or-pattern hack,HEART,2019-12-02T16:35:18Z,varkor,NA https://github.com/rust-lang/rust/pull/66967,MERGED,2019-12-02T16:16:08Z,2019-12-03T16:27:23Z,Remove hack for top-level or-patterns in match checking,Nadrieril,1c1bec2f6dbed0910b2e0ca19cffb92d95be4ee5,3,Remove top-level or-pattern hack,HEART,2019-12-02T17:49:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/66967,MERGED,2019-12-02T16:16:08Z,2019-12-03T16:27:23Z,Remove hack for top-level or-patterns in match checking,Nadrieril,1c1bec2f6dbed0910b2e0ca19cffb92d95be4ee5,3,Remove top-level or-pattern hack,HEART,2019-12-02T23:46:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-02T22:51:51Z,mati865,NA https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-02T23:38:21Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-03T00:21:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-03T10:51:29Z,est31,NA https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-04T05:53:04Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/66973,MERGED,2019-12-02T19:41:32Z,2019-12-03T21:52:11Z,Update the minimum external LLVM to 7,cuviper,2304c25f31fb69c279110ecaf51627cc36bffd55,18,Update the minimum external LLVM to 7 LLVM 7 is over a year old which should be plenty for compatibility. The last LLVM 6 holdout was llvm-emscripten which went away in #65501. I've also included a fix for LLVM 8 lacking `MemorySanitizerOptions` which was broken by #66522.,THUMBS_UP,2019-12-15T19:38:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/66981,MERGED,2019-12-03T09:37:22Z,2019-12-08T22:44:18Z,Update measureme crate to 0.5.0,michaelwoerister,edcca15c5b2aeccc4dc0fb7946b283e9f2fe319c,6,Update measureme crate to 0.5.0.,HOORAY,2019-12-03T10:59:42Z,andjo403,NA https://github.com/rust-lang/rust/pull/66994,MERGED,2019-12-03T18:03:55Z,2019-12-21T14:22:15Z,refactor expr & stmt parsing + improve recovery,Centril,621661f8a63f2118f3add5c3d686d9a2b6f62e5e,3,tweak var/auto/mut recovery,HEART,2019-12-05T17:20:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/66994,MERGED,2019-12-03T18:03:55Z,2019-12-21T14:22:15Z,refactor expr & stmt parsing + improve recovery,Centril,621661f8a63f2118f3add5c3d686d9a2b6f62e5e,3,tweak var/auto/mut recovery,HEART,2019-12-06T18:05:13Z,estebank,NA https://github.com/rust-lang/rust/pull/66994,MERGED,2019-12-03T18:03:55Z,2019-12-21T14:22:15Z,refactor expr & stmt parsing + improve recovery,Centril,621661f8a63f2118f3add5c3d686d9a2b6f62e5e,3,tweak var/auto/mut recovery,HEART,2019-12-23T12:19:01Z,achan1989,NA https://github.com/rust-lang/rust/pull/66994,MERGED,2019-12-03T18:03:55Z,2019-12-21T14:22:15Z,refactor expr & stmt parsing + improve recovery,Centril,621661f8a63f2118f3add5c3d686d9a2b6f62e5e,3,tweak var/auto/mut recovery,HEART,2020-01-03T14:26:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/66996,MERGED,2019-12-03T18:23:36Z,2019-12-04T08:22:09Z,Update cargo,ehuss,8d7765364786ecef411cc04c67b77e1a8513c2b2,1,Update cargo,HOORAY,2019-12-03T22:15:24Z,est31,NA https://github.com/rust-lang/rust/pull/67011,MERGED,2019-12-04T04:13:44Z,2019-12-06T00:06:15Z,Include a span in more `expected...found` notes,Aaron1011,168e35d56935b265d9c3ce767430f40ed7448d05,33,Include a span in more `expected...found` notes In most places we use a span when emitting `expected...found` errors. However there were a couple of places where we didn't use any span resulting in hard-to-interpret error messages. This commit attaches the relevant span to these notes and additionally switches over to using `note_expected_found` instead of manually formatting the message,THUMBS_UP,2019-12-15T18:22:10Z,estebank,NA https://github.com/rust-lang/rust/pull/67015,MERGED,2019-12-04T10:52:08Z,2019-12-11T12:29:42Z,Fix constant propagation for scalar pairs,osa1,2404a067eedd83ab69bb0e07fdc8145825741722,5,const-prop: Restrict scalar pair propagation We now only propagate a scalar pair if the Rvalue is a tuple with two scalars. This for example avoids propagating a (u8 u8) value when Rvalue has type `(() u8 u8)` (see the regression test). While this is a correct thing to do implementation is tricky and will be done later. Fixes #66971 Fixes #66339 Fixes #67019,HOORAY,2019-12-06T14:50:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67016,MERGED,2019-12-04T11:46:26Z,2019-12-09T14:00:54Z,In which we implement illegal subset relations errors using Polonius,lqd,1314ba323b6612d5109344c1d8bf9ae16e1e421f,2,add subset relations test using polonius It's a relatively simple smoke-test for subset errors executed outside of the polonius compare-mode.,THUMBS_UP,2020-01-04T11:10:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67020,MERGED,2019-12-04T13:21:23Z,2019-12-21T00:07:16Z,save LTO import info and check it when trying to reuse build products,pnkfelix,42b00a46812bd6af74880984d66a5eac59fca43b,2,General purpose teest cases contributed by mw.,HEART,2019-12-04T13:34:57Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67020,MERGED,2019-12-04T13:21:23Z,2019-12-21T00:07:16Z,save LTO import info and check it when trying to reuse build products,pnkfelix,42b00a46812bd6af74880984d66a5eac59fca43b,2,General purpose teest cases contributed by mw.,HEART,2019-12-05T11:50:41Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/67020,MERGED,2019-12-04T13:21:23Z,2019-12-21T00:07:16Z,save LTO import info and check it when trying to reuse build products,pnkfelix,42b00a46812bd6af74880984d66a5eac59fca43b,2,General purpose teest cases contributed by mw.,HEART,2019-12-12T17:04:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67020,MERGED,2019-12-04T13:21:23Z,2019-12-21T00:07:16Z,save LTO import info and check it when trying to reuse build products,pnkfelix,42b00a46812bd6af74880984d66a5eac59fca43b,2,General purpose teest cases contributed by mw.,HEART,2019-12-21T02:34:39Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/67020,MERGED,2019-12-04T13:21:23Z,2019-12-21T00:07:16Z,save LTO import info and check it when trying to reuse build products,pnkfelix,42b00a46812bd6af74880984d66a5eac59fca43b,2,General purpose teest cases contributed by mw.,HEART,2019-12-28T21:23:37Z,adamreichold,NA https://github.com/rust-lang/rust/pull/67026,MERGED,2019-12-04T16:47:05Z,2019-12-13T22:56:46Z,Improve diagnostics and code for exhaustiveness of empty matches,Nadrieril,fbd2cd09e6fd044cad02af97e581853f1875ab2a,6,Revert a diagnostic change in the case of integer ranges,HEART,2019-12-04T17:39:03Z,varkor,NA https://github.com/rust-lang/rust/pull/67026,MERGED,2019-12-04T16:47:05Z,2019-12-13T22:56:46Z,Improve diagnostics and code for exhaustiveness of empty matches,Nadrieril,fbd2cd09e6fd044cad02af97e581853f1875ab2a,6,Revert a diagnostic change in the case of integer ranges,HEART,2019-12-05T00:41:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67026,MERGED,2019-12-04T16:47:05Z,2019-12-13T22:56:46Z,Improve diagnostics and code for exhaustiveness of empty matches,Nadrieril,fbd2cd09e6fd044cad02af97e581853f1875ab2a,6,Revert a diagnostic change in the case of integer ranges,HEART,2019-12-11T18:49:49Z,estebank,NA https://github.com/rust-lang/rust/pull/67031,MERGED,2019-12-04T17:49:48Z,2019-12-20T19:43:32Z,Update tokio crates to latest versions,mati865,2d8d8136fa4d67574e7b27a3f262819627cf1622,1,Update tokio crates to latest versions,HEART,2019-12-05T03:00:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/67033,MERGED,2019-12-04T20:07:02Z,2019-12-06T18:17:35Z,Migrate to LLVM{Get Set}ValueName2,cuviper,16d21783d63c9ff89742ab83c2d02d25307c262c,7,Migrate to LLVM{Get Set}ValueName2 The deprecated `LLVM{Get Set}ValueName` only work with NUL-terminated strings but the `2` variants use explicit lengths which fits better with Rust strings and slices. We now use these in new helper functions `llvm::{get set}_value_name` that convert to/from `&[u8]`.,HOORAY,2019-12-15T20:24:14Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,THUMBS_UP,2019-12-04T22:22:37Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,THUMBS_UP,2019-12-05T00:06:02Z,peddermaster2,NA https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,THUMBS_UP,2019-12-05T16:32:06Z,tesuji,NA https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,THUMBS_UP,2019-12-10T18:24:03Z,adlugopolski,NA https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,THUMBS_UP,2019-12-18T19:53:03Z,estebank,NA https://github.com/rust-lang/rust/pull/67034,CLOSED,2019-12-04T20:59:01Z,2020-04-02T00:23:04Z,Fix argument order in printed output on panic,sgrif,NA,NA,NA,HEART,2020-01-30T06:48:59Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/67039,MERGED,2019-12-04T23:08:56Z,2019-12-10T10:11:53Z,Use deref target in Pin trait implementations,xfix,61d9c001465f14be10b519fbb3030f5cebe22199,1,Explicitly refer to operator methods in Pin impls,HEART,2019-12-07T00:03:23Z,estebank,NA https://github.com/rust-lang/rust/pull/67039,MERGED,2019-12-04T23:08:56Z,2019-12-10T10:11:53Z,Use deref target in Pin trait implementations,xfix,61d9c001465f14be10b519fbb3030f5cebe22199,1,Explicitly refer to operator methods in Pin impls,HEART,2019-12-09T23:01:17Z,Selicre,NA https://github.com/rust-lang/rust/pull/67039,MERGED,2019-12-04T23:08:56Z,2019-12-10T10:11:53Z,Use deref target in Pin trait implementations,xfix,61d9c001465f14be10b519fbb3030f5cebe22199,1,Explicitly refer to operator methods in Pin impls,HEART,2019-12-11T01:08:03Z,uonr,me@yuru.me https://github.com/rust-lang/rust/pull/67052,MERGED,2019-12-05T13:24:17Z,2019-12-07T02:45:44Z,Ditch `parse_in_attr`,Centril,99191c2e717883bfec51b49df0e412a34849fc4a,9,parse_meta: ditch parse_in_attr,HEART,2019-12-09T17:50:51Z,estebank,NA https://github.com/rust-lang/rust/pull/67055,MERGED,2019-12-05T14:16:48Z,2019-12-06T00:06:08Z,Make const-qualification look at more `const fn`s,lqd,2d83b7608070d6ad250e8cd6d9d5a7d4be628dc4,1,update comment to explain the importance of this check more clearly,HEART,2019-12-05T17:25:53Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/67055,MERGED,2019-12-05T14:16:48Z,2019-12-06T00:06:08Z,Make const-qualification look at more `const fn`s,lqd,2d83b7608070d6ad250e8cd6d9d5a7d4be628dc4,1,update comment to explain the importance of this check more clearly,HEART,2019-12-05T20:11:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/67059,MERGED,2019-12-05T17:31:24Z,2019-12-21T17:35:31Z,Fix too restrictive checks on Drop impls,TommasoBianchi,b08d697236b236e96b0e8e6894e05aefe5a11b39,1,Formatting fixes,HEART,2019-12-05T22:46:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/67073,MERGED,2019-12-06T01:32:28Z,2020-01-31T21:52:10Z,Bundle and document 6 BTreeMap navigation algorithms,ssomers,3cf724d0c122f08ccbb3a9f77cb0ad888d8bebf0,4,Bundle and document 6 BTreeMap navigation algorithms,HEART,2019-12-11T03:26:23Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/67073,MERGED,2019-12-06T01:32:28Z,2020-01-31T21:52:10Z,Bundle and document 6 BTreeMap navigation algorithms,ssomers,3cf724d0c122f08ccbb3a9f77cb0ad888d8bebf0,4,Bundle and document 6 BTreeMap navigation algorithms,HEART,2020-02-29T05:43:51Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67077,MERGED,2019-12-06T03:05:36Z,2019-12-13T13:10:52Z,rustc: Link LLVM directly into rustc again (take two),Aaron1011,47e932b96e726d855f9885f073ef6b6b6bb78438,4,Fix weird implicit dependency between rustllvm and rustc_codegen_llvm rustllvm relies on the `LLVMRustStringWriteImpl` symbol existing but this symbol was previously defined in a *downstream* crate (rustc_codegen_llvm which depends on rustc_llvm. While this somehow worked under the old 'separate bootstrap step for codegen' scheme it meant that rustc_llvm could not actually be built by itself since it relied linking to the downstream rustc_codegen_llvm crate. Now that librustc_codegen_llvm is just a normal crate we actually try to build a standalone rustc_llvm when we run tests. This commit moves `LLVMRustStringWriteImpl` into rustc_llvm (technically the rustllvm directory which has its contents built by rustc_llvm). This ensures that we can build each crate in the graph by itself without requiring that any downstream crates be linked in as well.,HOORAY,2019-12-07T02:27:27Z,tmandry,NA https://github.com/rust-lang/rust/pull/67078,MERGED,2019-12-06T05:25:29Z,2019-12-07T02:45:40Z,accept union inside enum if not followed by identifier,kamleshbhalui,f8ecf04f4b60f1004b9ba4092747f16d290dfff7,2,accept union inside enum if not followed by identifier,ROCKET,2019-12-09T17:53:35Z,estebank,NA https://github.com/rust-lang/rust/pull/67085,MERGED,2019-12-06T12:34:20Z,2019-12-06T18:17:27Z,Remove boxed closures in address parser.,reitermarkus,79f876495b2853d1b78ba953ceb3114b8019100f,1,Remove boxed closures in address parser.,HOORAY,2019-12-13T17:04:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67112,MERGED,2019-12-07T04:09:06Z,2019-12-29T22:51:22Z,Refactor expression parsing thoroughly,Centril,7a246acf0a0413131765a3e78dc665e68f6f243d,1,fix rebase fallout,HEART,2019-12-26T20:41:04Z,estebank,NA https://github.com/rust-lang/rust/pull/67116,CLOSED,2019-12-07T06:09:46Z,2020-04-28T13:48:05Z,Print nicer async/await trait errors for generators in any place in the error 'stack',Aaron1011,NA,NA,NA,HEART,2019-12-09T22:19:26Z,estebank,NA https://github.com/rust-lang/rust/pull/67121,CLOSED,2019-12-07T15:18:35Z,2019-12-28T09:16:09Z,[experiment] Expand macros in inert key-value attributes,petrochenkov,NA,NA,NA,HOORAY,2019-12-07T15:19:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67121,CLOSED,2019-12-07T15:18:35Z,2019-12-28T09:16:09Z,[experiment] Expand macros in inert key-value attributes,petrochenkov,NA,NA,NA,HOORAY,2019-12-07T20:57:52Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/67121,CLOSED,2019-12-07T15:18:35Z,2019-12-28T09:16:09Z,[experiment] Expand macros in inert key-value attributes,petrochenkov,NA,NA,NA,HEART,2019-12-08T12:53:35Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/67121,CLOSED,2019-12-07T15:18:35Z,2019-12-28T09:16:09Z,[experiment] Expand macros in inert key-value attributes,petrochenkov,NA,NA,NA,EYES,2020-01-10T01:04:10Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/67126,CLOSED,2019-12-07T19:24:41Z,2019-12-23T22:58:06Z,Enable rlib generation for librustc_driver,sapir,NA,NA,NA,THUMBS_UP,2019-12-08T12:16:55Z,glaubitz,NA https://github.com/rust-lang/rust/pull/67126,CLOSED,2019-12-07T19:24:41Z,2019-12-23T22:58:06Z,Enable rlib generation for librustc_driver,sapir,NA,NA,NA,THUMBS_UP,2019-12-08T14:36:59Z,bstrie,NA https://github.com/rust-lang/rust/pull/67126,CLOSED,2019-12-07T19:24:41Z,2019-12-23T22:58:06Z,Enable rlib generation for librustc_driver,sapir,NA,NA,NA,THUMBS_UP,2019-12-09T04:48:38Z,cglong,chris@chrislong.dev https://github.com/rust-lang/rust/pull/67126,CLOSED,2019-12-07T19:24:41Z,2019-12-23T22:58:06Z,Enable rlib generation for librustc_driver,sapir,NA,NA,NA,THUMBS_UP,2019-12-09T16:04:36Z,harrysarson,NA https://github.com/rust-lang/rust/pull/67129,MERGED,2019-12-07T20:09:55Z,2019-12-08T09:07:32Z,Fixes typo,remexre,dfc04fc7a78888e9afa7dcc26d0173564e79adbe,1,Fixes typo `legacy_disrectory_ownership` vs `legacy_directory_ownership`,THUMBS_UP,2019-12-07T23:22:50Z,estebank,NA https://github.com/rust-lang/rust/pull/67130,MERGED,2019-12-07T21:16:18Z,2019-12-21T04:19:09Z,Const prop should finish propagation into user defined variables,wesleywiser,0745b8c5a248dffd25ad33611e044fab133bce00,6,Const prop should finish propagation into user defined variables Fixes #66638,HEART,2019-12-27T17:44:28Z,tesuji,NA https://github.com/rust-lang/rust/pull/67130,MERGED,2019-12-07T21:16:18Z,2019-12-21T04:19:09Z,Const prop should finish propagation into user defined variables,wesleywiser,0745b8c5a248dffd25ad33611e044fab133bce00,6,Const prop should finish propagation into user defined variables Fixes #66638,HEART,2020-01-03T17:21:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,HEART,2019-12-08T21:36:39Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,THUMBS_UP,2019-12-09T09:25:46Z,lqd,NA https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,HEART,2019-12-10T10:00:10Z,mati865,NA https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,HEART,2019-12-11T21:25:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,HEART,2019-12-12T08:51:58Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67136,MERGED,2019-12-08T01:33:53Z,2019-12-14T13:22:49Z,Require stable/unstable annotations for the constness of all stable fns with a const modifier,oli-obk,0b47ba7019adf06f6687a8c94040e63ae1ea4fba,1,The constness of 128 bit atomics will be stabilized together with the atomics,HEART,2019-12-12T10:30:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67137,MERGED,2019-12-08T02:12:33Z,2020-01-04T21:50:45Z,libstd uses `core::panic::Location` where possible.,anp,27b25eb822d32911b73991c7fd6921fea609f825,1,Restrict visibility of location_triple_for_span.,HOORAY,2019-12-08T07:50:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67137,MERGED,2019-12-08T02:12:33Z,2020-01-04T21:50:45Z,libstd uses `core::panic::Location` where possible.,anp,27b25eb822d32911b73991c7fd6921fea609f825,1,Restrict visibility of location_triple_for_span.,HOORAY,2019-12-08T14:34:39Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67137,MERGED,2019-12-08T02:12:33Z,2020-01-04T21:50:45Z,libstd uses `core::panic::Location` where possible.,anp,27b25eb822d32911b73991c7fd6921fea609f825,1,Restrict visibility of location_triple_for_span.,HOORAY,2019-12-09T09:25:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67137,MERGED,2019-12-08T02:12:33Z,2020-01-04T21:50:45Z,libstd uses `core::panic::Location` where possible.,anp,27b25eb822d32911b73991c7fd6921fea609f825,1,Restrict visibility of location_triple_for_span.,HOORAY,2019-12-11T05:47:11Z,nikki-nn4,NA https://github.com/rust-lang/rust/pull/67143,CLOSED,2019-12-08T09:27:22Z,2020-01-25T06:43:50Z,Optimize is_ascii_digit() and is_ascii_hexdigit(),DarkKirb,NA,NA,NA,THUMBS_UP,2020-01-23T09:51:46Z,ThomasdenH,NA https://github.com/rust-lang/rust/pull/67148,MERGED,2019-12-08T11:44:36Z,2019-12-22T10:11:33Z, Refactor type & bounds parsing thoroughly,Centril,db4818f3253254bafac707d58ec3d13def0e6f86,4,span_suggestion_hidden -> tool_only_span_suggestion,HEART,2019-12-08T13:50:40Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/67151,MERGED,2019-12-08T12:55:56Z,2019-12-28T23:02:24Z,doc comments: Less attribute mimicking,petrochenkov,3d57b8bcc0a6a0378a9cea0291bb76d44bec6ff8,9,doc comments: Less attribute mimicking,THUMBS_UP,2019-12-11T20:56:44Z,estebank,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-08T22:00:30Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HEART,2019-12-08T22:00:31Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-09T01:19:21Z,cynecx,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-09T01:22:35Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,THUMBS_UP,2019-12-09T01:47:56Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HEART,2019-12-09T01:47:58Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-09T01:47:59Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,ROCKET,2019-12-09T01:48:06Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,EYES,2019-12-09T01:48:11Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,LAUGH,2019-12-09T01:48:13Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-10T09:01:10Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-10T09:54:24Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-10T11:21:28Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HEART,2019-12-11T03:39:49Z,felix91gr,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-11T10:00:22Z,lqd,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-11T18:13:43Z,estebank,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-11T21:23:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HEART,2019-12-13T09:43:14Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,THUMBS_UP,2019-12-20T20:05:27Z,chpio,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,EYES,2019-12-22T10:21:56Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-22T20:36:38Z,kornholi,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-23T10:51:48Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2019-12-24T19:26:44Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,THUMBS_UP,2020-02-25T20:08:06Z,TomGillen,thomas.gillen@googlemail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2020-02-25T20:08:07Z,TomGillen,thomas.gillen@googlemail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2021-08-03T20:35:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,THUMBS_UP,2021-08-06T14:00:34Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HOORAY,2021-08-06T14:00:35Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,HEART,2021-08-06T14:00:36Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67160,MERGED,2019-12-08T18:22:25Z,2019-12-22T00:10:27Z,Make GATs less ICE-prone.,matthewjasper,e7b8bfe5b9f09a6c587ebe170abdf84a7bce26fa,1,Fix rustdoc,ROCKET,2021-08-06T14:00:36Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67189,MERGED,2019-12-10T09:45:49Z,2019-12-19T14:55:15Z,Unify binop wording,LeSeulArtichaut,e4abcfbd34f759c33da6f6d7e37235c15ede07c2,2,Added missing backticks,HEART,2019-12-15T12:46:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/67193,MERGED,2019-12-10T12:13:32Z,2019-12-11T08:39:27Z,In which we start tracking polonius in `-Z self-profile`,lqd,e0481d1d40913e0d074d6681d2354385055590c6,5,"add polonius activities to -Z self-profile - ""polonius_fact_generation"" is dedicated to profiling the Polonius fact generation from the MIR and NLL constraints - ""polonius_analysis"" is dedicated to profiling the duration of the Polonius computations themselves: move/init analysis liveness borrowck-ing",HOORAY,2019-12-10T13:40:38Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67193,MERGED,2019-12-10T12:13:32Z,2019-12-11T08:39:27Z,In which we start tracking polonius in `-Z self-profile`,lqd,e0481d1d40913e0d074d6681d2354385055590c6,5,"add polonius activities to -Z self-profile - ""polonius_fact_generation"" is dedicated to profiling the Polonius fact generation from the MIR and NLL constraints - ""polonius_analysis"" is dedicated to profiling the duration of the Polonius computations themselves: move/init analysis liveness borrowck-ing",HOORAY,2019-12-10T18:59:54Z,amandasystems,mail@amandastjerna.se https://github.com/rust-lang/rust/pull/67198,MERGED,2019-12-10T15:05:14Z,2019-12-11T05:31:31Z,Update RLS and Rustfmt,Xanewok,5b091305c50aa4ba8b79f09f056d25239e6287b7,3,Update RLS and Rustfmt,HOORAY,2019-12-11T00:25:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-11T06:47:03Z,darksv,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-11T08:00:08Z,mati865,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-11T10:55:50Z,CryZe,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-11T15:19:52Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T01:46:24Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T08:59:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T10:19:26Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T16:49:01Z,lqd,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T19:13:07Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-12T22:23:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-12T22:23:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-13T22:57:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-13T22:57:28Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-14T13:17:58Z,est31,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-14T13:17:58Z,est31,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-15T09:12:28Z,varkor,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-15T09:39:28Z,Pratyush,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-15T09:39:29Z,Pratyush,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-15T10:26:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T08:12:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T08:36:17Z,tesuji,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T08:47:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-16T08:47:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-16T09:10:57Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T10:07:34Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-16T10:07:34Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T11:23:57Z,ArtemGr,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T11:29:55Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T11:34:52Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2019-12-16T14:06:22Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HEART,2019-12-17T01:00:30Z,estebank,NA https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,THUMBS_UP,2019-12-27T05:11:53Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/67216,MERGED,2019-12-11T05:50:46Z,2019-12-15T04:46:14Z,Enable `loop` and `while` in constants behind a feature flag,ecstatic-morse,faa52d1cdaa8806201d56484df0c45bf550bf565,1,Correctly mark things as `min_const_fn`,HOORAY,2020-02-12T15:21:56Z,silverweed,silverweed1991@gmail.com https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-11T23:07:02Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-11T23:32:18Z,cramertj,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-12T16:17:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-12T17:17:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-12T19:43:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-12T22:47:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-12T23:49:42Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-13T03:04:30Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-14T19:48:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-15T02:48:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2019-12-21T06:52:53Z,8573,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2020-01-20T04:27:25Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,LAUGH,2021-09-22T17:57:18Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67224,MERGED,2019-12-11T15:06:18Z,2019-12-15T01:28:21Z,Revert stabilization of never type,nikomatsakis,775076ff4dc9ce4986a1286669cfa268b01ac592,1,update reference,THUMBS_UP,2022-01-07T02:50:21Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/67236,MERGED,2019-12-11T19:24:37Z,2019-12-12T05:31:01Z,resolve: Always resolve visibilities on impl items,petrochenkov,914c9aa78d7d43d268690e2cf1ae634795cd29aa,3,resolve: Always resolve visibilities on impl items,THUMBS_UP,2019-12-11T20:22:30Z,estebank,NA https://github.com/rust-lang/rust/pull/67236,MERGED,2019-12-11T19:24:37Z,2019-12-12T05:31:01Z,resolve: Always resolve visibilities on impl items,petrochenkov,914c9aa78d7d43d268690e2cf1ae634795cd29aa,3,resolve: Always resolve visibilities on impl items,HEART,2019-12-12T12:52:53Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67247,MERGED,2019-12-12T02:14:03Z,2019-12-13T06:50:57Z,Don't suggest wrong snippet in closure,JohnTitor,fa199c5f27cf09fa02ff7632a713ea613f731944,3,Don't suggest wrong snippet in closure,THUMBS_UP,2019-12-13T07:22:22Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/67249,MERGED,2019-12-12T02:43:47Z,2019-12-16T22:21:17Z,Improve code generated for `starts_with()`,ranma42,3de1923d5d3aad5c4bb0914f054e950bf166aa00,2,Add benchmarks for `start_with` and `ends_with`,HEART,2019-12-12T03:23:21Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/67249,MERGED,2019-12-12T02:43:47Z,2019-12-16T22:21:17Z,Improve code generated for `starts_with()`,ranma42,3de1923d5d3aad5c4bb0914f054e950bf166aa00,2,Add benchmarks for `start_with` and `ends_with`,THUMBS_UP,2019-12-12T13:54:56Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/67249,MERGED,2019-12-12T02:43:47Z,2019-12-16T22:21:17Z,Improve code generated for `starts_with()`,ranma42,3de1923d5d3aad5c4bb0914f054e950bf166aa00,2,Add benchmarks for `start_with` and `ends_with`,HEART,2019-12-12T23:37:46Z,kennytm,NA https://github.com/rust-lang/rust/pull/67249,MERGED,2019-12-12T02:43:47Z,2019-12-16T22:21:17Z,Improve code generated for `starts_with()`,ranma42,3de1923d5d3aad5c4bb0914f054e950bf166aa00,2,Add benchmarks for `start_with` and `ends_with`,HEART,2019-12-21T20:22:44Z,adamreichold,NA https://github.com/rust-lang/rust/pull/67249,MERGED,2019-12-12T02:43:47Z,2019-12-16T22:21:17Z,Improve code generated for `starts_with()`,ranma42,3de1923d5d3aad5c4bb0914f054e950bf166aa00,2,Add benchmarks for `start_with` and `ends_with`,HEART,2019-12-23T19:00:58Z,lnicola,NA https://github.com/rust-lang/rust/pull/67251,MERGED,2019-12-12T09:23:06Z,2019-12-13T06:50:55Z,Require `allow_internal_unstable` for stable min_const_fn using unsta…,oli-obk,0b1e08a9f4b431afcf3076fe41f3b2dbcc6f3548,9,Require `allow_internal_unstable` for stable min_const_fn using unstable features,THUMBS_UP,2019-12-12T09:26:04Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67253,MERGED,2019-12-12T14:07:56Z,2019-12-20T02:06:33Z,Add more delegations to the fmt docs and add doctests,elichai,a9d6889e4d211e251e2f37cca358f61e488cb7cc,1,Replace prints in fmt docs with asserts,HEART,2019-12-12T15:32:59Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67257,CLOSED,2019-12-12T15:54:36Z,2019-12-14T10:12:24Z,Add PartialEq and Eq to Mutex,Luro02,NA,NA,NA,CONFUSED,2019-12-13T13:44:16Z,CryZe,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2019-12-12T16:19:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2019-12-13T06:18:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2019-12-13T13:40:28Z,CryZe,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2019-12-20T13:36:24Z,D1mon,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2019-12-30T07:44:33Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-11T03:15:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-16T14:11:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-16T14:15:21Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-16T19:10:44Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,THUMBS_UP,2020-01-17T03:35:07Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-17T14:01:47Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-01-17T18:30:14Z,mustafakibar,mustafa@kibar.pro https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,HEART,2020-02-04T15:13:01Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,THUMBS_UP,2020-09-08T12:48:00Z,0nkery,NA https://github.com/rust-lang/rust/pull/67258,MERGED,2019-12-12T16:09:42Z,2020-01-10T23:27:06Z,Introduce `X..` `..X` and `..=X` range patterns,Centril,d5598aa7a07b324789576585f4f035c93993fea4,56,Introduce `#![feature(half_open_range_patterns)]`. This feature adds `X..` `..X` and `..=X` patterns.,THUMBS_UP,2021-08-30T10:04:39Z,poly000,NA https://github.com/rust-lang/rust/pull/67267,MERGED,2019-12-12T22:50:06Z,2019-12-15T10:11:23Z,Fix signature of `__wasilibc_find_relpath`,alexcrichton,641ccd58c168a296f5c36a191660ef63a32a98b9,1,Fix signature of `__wasilibc_find_relpath` Looks like this function changed upstream so it needs to be adjusted for when used by libstd.,HOORAY,2019-12-16T13:21:49Z,ratmice,NA https://github.com/rust-lang/rust/pull/67272,MERGED,2019-12-13T04:36:11Z,2020-02-18T14:49:24Z,recursion_limit parsing handles overflows,fisherdarling,c53693d34d83e6221dc8b93a2c4e17e66fa6f0e2,10,Handle recursion_limit parsing errors,THUMBS_UP,2019-12-13T07:33:56Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/67272,MERGED,2019-12-13T04:36:11Z,2020-02-18T14:49:24Z,recursion_limit parsing handles overflows,fisherdarling,c53693d34d83e6221dc8b93a2c4e17e66fa6f0e2,10,Handle recursion_limit parsing errors,THUMBS_UP,2019-12-14T01:09:47Z,estebank,NA https://github.com/rust-lang/rust/pull/67278,MERGED,2019-12-13T15:03:35Z,2019-12-13T22:56:28Z,`coerce_inner`: use initial `expected_ty`,Centril,f97c37f8ae9a3bb9eed2d2fa812c01ac78b460fb,3,coerce_inner: use initial expected_ty,HEART,2019-12-13T15:09:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67278,MERGED,2019-12-13T15:03:35Z,2019-12-13T22:56:28Z,`coerce_inner`: use initial `expected_ty`,Centril,f97c37f8ae9a3bb9eed2d2fa812c01ac78b460fb,3,coerce_inner: use initial expected_ty,HEART,2019-12-13T20:40:40Z,estebank,NA https://github.com/rust-lang/rust/pull/67282,MERGED,2019-12-13T19:16:26Z,2019-12-15T10:11:21Z,Fix example code of OpenOptions::open,pjw91,b65c6ec10fe2b80e22706f5b3245cc5f6f372edf,1,Fix incorrect example code of OpenOptions::open,THUMBS_UP,2019-12-13T21:09:18Z,pitdicker,NA https://github.com/rust-lang/rust/pull/67285,MERGED,2019-12-13T21:03:33Z,2019-12-20T14:31:03Z,Indicate origin of where type parameter for uninferred types ,ohadravid,8a4632dec69082301d3fe67e48d422bc9fb665be,28,Indicate origin of where type parameter for uninferred types,HEART,2019-12-13T21:39:00Z,estebank,NA https://github.com/rust-lang/rust/pull/67285,MERGED,2019-12-13T21:03:33Z,2019-12-20T14:31:03Z,Indicate origin of where type parameter for uninferred types ,ohadravid,8a4632dec69082301d3fe67e48d422bc9fb665be,28,Indicate origin of where type parameter for uninferred types,HEART,2019-12-14T04:01:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67285,MERGED,2019-12-13T21:03:33Z,2019-12-20T14:31:03Z,Indicate origin of where type parameter for uninferred types ,ohadravid,8a4632dec69082301d3fe67e48d422bc9fb665be,28,Indicate origin of where type parameter for uninferred types,HEART,2019-12-15T18:21:00Z,omerbenamram,omerbenamram@gmail.com https://github.com/rust-lang/rust/pull/67290,MERGED,2019-12-14T00:10:00Z,2020-02-26T16:02:29Z,Audit liballoc for leaks in `Drop` impls when user destructor panics,jonas-schievink,892cb143e5984f220e6b26b48d972bd1f4644298,11,Auto merge of #67290 - jonas-schievink:leak-audit r=KodrAus Audit liballoc for leaks in `Drop` impls when user destructor panics Inspired by https://github.com/rust-lang/rust/pull/67243 and https://github.com/rust-lang/rust/pull/67235 this audits and hopefully fixes the remaining `Drop` impls in liballoc for resource leaks in the presence of panics in destructors called by the affected `Drop` impl. This does not touch `Hash{Map Set}` since they live in hashbrown. They have similar issues though. r? @KodrAus,EYES,2019-12-15T21:42:47Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/67322,MERGED,2019-12-15T14:10:42Z,2019-12-16T22:21:10Z,use Self alias in place of macros,tesuji,7bf55f4aa536ce8fe12fabe640ea4eb5c5a7a572,2,use Self alias in place of macros,CONFUSED,2019-12-28T14:46:58Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67328,MERGED,2019-12-15T17:28:04Z,2019-12-20T14:31:00Z,Remove now-redundant range check on u128 -> f32 casts,hanna-kruppe,6ad0b55597d58f65b775cc32588d5cb396993c0c,1,Remove now-redundant range check on u128 -> f32 casts This code was added to avoid UB in LLVM 6 and earlier but we no longer support those LLVM versions. Since https://reviews.llvm.org/D47807 (released in LLVM 7) uitofp does exactly what we need. Closes #51872,HEART,2019-12-19T18:40:56Z,mati865,NA https://github.com/rust-lang/rust/pull/67340,MERGED,2019-12-16T03:38:01Z,2020-01-31T09:49:53Z,Shrink `Nonterminal`,nnethercote,7d2173ed27c1cddc4d4a7a9755f244b66cf1ec81,4,Use `P` for `NtMeta`. This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).,HEART,2019-12-17T20:49:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67340,MERGED,2019-12-16T03:38:01Z,2020-01-31T09:49:53Z,Shrink `Nonterminal`,nnethercote,7d2173ed27c1cddc4d4a7a9755f244b66cf1ec81,4,Use `P` for `NtMeta`. This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).,HEART,2019-12-20T03:06:55Z,crlf0710,NA https://github.com/rust-lang/rust/pull/67340,MERGED,2019-12-16T03:38:01Z,2020-01-31T09:49:53Z,Shrink `Nonterminal`,nnethercote,7d2173ed27c1cddc4d4a7a9755f244b66cf1ec81,4,Use `P` for `NtMeta`. This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).,HEART,2020-01-31T13:17:53Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/67340,MERGED,2019-12-16T03:38:01Z,2020-01-31T09:49:53Z,Shrink `Nonterminal`,nnethercote,7d2173ed27c1cddc4d4a7a9755f244b66cf1ec81,4,Use `P` for `NtMeta`. This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).,HEART,2020-02-06T22:16:56Z,lnicola,NA https://github.com/rust-lang/rust/pull/67346,CLOSED,2019-12-16T07:47:42Z,2019-12-19T10:11:55Z,doc: inline collections at reexport module,tesuji,NA,NA,NA,HEART,2019-12-16T07:58:23Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/67350,MERGED,2019-12-16T13:19:54Z,2019-12-16T18:54:50Z,[stable] 1.40 stable release,Mark-Simulacrum,ab4059edabe7f0f571f167b749a314fda6a7a6ee,1,1.40 stable release,ROCKET,2019-12-16T13:34:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67353,CLOSED,2019-12-16T15:51:36Z,2019-12-18T15:46:20Z,Remove few LLVMRust...() methods instead use LLVM C-API.,vivekvpandya,NA,NA,NA,THUMBS_UP,2019-12-16T17:12:41Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67353,CLOSED,2019-12-16T15:51:36Z,2019-12-18T15:46:20Z,Remove few LLVMRust...() methods instead use LLVM C-API.,vivekvpandya,NA,NA,NA,HEART,2019-12-16T18:36:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/67362,MERGED,2019-12-16T21:32:49Z,2019-12-17T21:21:38Z,4 thread parallelism by default,Mark-Simulacrum,5d4e59bc91374e095d9679e76551a06a151bc0b9,1,Disable cargo tests for now These depend on rustc being bug-free and it looks like that's not currently entirely the case (e.g. we know of at least one bug that introduces nondeterminism).,HEART,2019-12-17T20:47:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67374,CLOSED,2019-12-17T19:51:55Z,2020-01-15T11:58:54Z,Make char-iterators Hash & [Partial]Eq,lukaslueg,NA,NA,NA,THUMBS_DOWN,2019-12-20T05:28:16Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/67382,MERGED,2019-12-18T00:22:05Z,2019-12-19T14:55:01Z,Remove some unnecessary `ATTR_*` constants.,nnethercote,71278cbdcb0aaf93edd370c6aec24d670a3c1eab,4,Remove some unnecessary `ATTR_*` constants.,HEART,2019-12-18T00:26:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/67394,MERGED,2019-12-18T13:41:05Z,2019-12-19T14:54:59Z,Remove outdated references to @T from comments,matthew-healy,e77a55b5d91a7876e4ba23179d15ed0ce4affeb7,1,Remove outdated references to @T from comments,LAUGH,2019-12-18T21:53:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67397,MERGED,2019-12-18T15:03:52Z,2020-01-10T15:39:28Z,self-profiling: Support recording query keys,michaelwoerister,ad65e3e6bc8ded92db38507b84ec4a2bf2677d62,4,Fix some rebasing fallout.,HOORAY,2019-12-18T15:04:38Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67397,MERGED,2019-12-18T15:03:52Z,2020-01-10T15:39:28Z,self-profiling: Support recording query keys,michaelwoerister,ad65e3e6bc8ded92db38507b84ec4a2bf2677d62,4,Fix some rebasing fallout.,HOORAY,2019-12-18T18:09:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67397,MERGED,2019-12-18T15:03:52Z,2020-01-10T15:39:28Z,self-profiling: Support recording query keys,michaelwoerister,ad65e3e6bc8ded92db38507b84ec4a2bf2677d62,4,Fix some rebasing fallout.,HOORAY,2020-01-01T06:11:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67397,MERGED,2019-12-18T15:03:52Z,2020-01-10T15:39:28Z,self-profiling: Support recording query keys,michaelwoerister,ad65e3e6bc8ded92db38507b84ec4a2bf2677d62,4,Fix some rebasing fallout.,HOORAY,2020-01-08T13:10:44Z,lqd,NA https://github.com/rust-lang/rust/pull/67402,MERGED,2019-12-18T17:21:35Z,2019-12-19T01:15:49Z,Switch bootstrap to 1.41,Mark-Simulacrum,241d2e765dc7401e642812e43b75dbc3950f2c98,1,Fix compiletest fallout from stage0 bump,HOORAY,2019-12-18T20:51:32Z,mati865,NA https://github.com/rust-lang/rust/pull/67402,MERGED,2019-12-18T17:21:35Z,2019-12-19T01:15:49Z,Switch bootstrap to 1.41,Mark-Simulacrum,241d2e765dc7401e642812e43b75dbc3950f2c98,1,Fix compiletest fallout from stage0 bump,HOORAY,2019-12-18T21:53:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67406,MERGED,2019-12-18T19:42:09Z,2019-12-19T14:54:57Z,Suggest associated type when the specified one cannot be found,ohadravid,a4a2fc0af33ef5a4e1211c5d3e4f0eeca02322f8,2,Suggest associated type when the specified one cannot be found,HEART,2019-12-18T19:50:43Z,estebank,NA https://github.com/rust-lang/rust/pull/67406,MERGED,2019-12-18T19:42:09Z,2019-12-19T14:54:57Z,Suggest associated type when the specified one cannot be found,ohadravid,a4a2fc0af33ef5a4e1211c5d3e4f0eeca02322f8,2,Suggest associated type when the specified one cannot be found,HEART,2019-12-18T23:53:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67410,MERGED,2019-12-18T22:00:24Z,2019-12-22T10:11:21Z,Reenable static linking of libstdc++ on windows-gnu,mati865,44603a5cd6044e91a9fa4c1a95c5aaf98adc5b05,1,Reenable static linking of libstdc++ on windows-gnu,HEART,2019-12-22T10:12:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HEART,2019-12-22T10:12:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2019-12-30T16:01:39Z,crlf0710,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-01-01T06:13:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,ROCKET,2020-01-17T12:51:52Z,snuk182,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-01-25T14:30:09Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-02-04T21:10:04Z,bigkraig,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-02-21T18:03:29Z,EPashkin,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HEART,2020-02-21T18:03:32Z,EPashkin,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,ROCKET,2020-02-21T18:03:33Z,EPashkin,NA https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-03-07T19:23:29Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HEART,2020-04-21T22:12:58Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/67429,MERGED,2019-12-19T16:35:10Z,2020-02-05T22:42:56Z,windows-gnu: prefer system crt libraries if they are available,mati865,1fad337f79a6a554ae947def38ec2db0e91d864c,2,Prefer system MinGW libs when available,HOORAY,2020-04-21T22:12:59Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/67430,MERGED,2019-12-19T17:07:51Z,2019-12-31T16:21:35Z,doc: minus (U+2212) instead of dash (U+002D) for negative infinity,tspiteri,d1a3518e30febb459afeb25b4850a3222f44db8c,2,doc: minus (U+2212) instead of dash (U+002D) for negative infinity,THUMBS_UP,2019-12-19T23:52:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/67437,MERGED,2019-12-19T20:27:55Z,2019-12-27T14:04:13Z,Add LLVM `skip-rebuild` option to `x.py`,matthew-healy,e44fc4577fdf5e269db0c7f574ac8d125067ccd8,1,Skip LLVM rebuild when skip-rebuild is true,THUMBS_UP,2019-12-20T18:49:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67437,MERGED,2019-12-19T20:27:55Z,2019-12-27T14:04:13Z,Add LLVM `skip-rebuild` option to `x.py`,matthew-healy,e44fc4577fdf5e269db0c7f574ac8d125067ccd8,1,Skip LLVM rebuild when skip-rebuild is true,CONFUSED,2019-12-28T18:01:08Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67439,MERGED,2019-12-19T22:39:16Z,2019-12-22T10:11:18Z,Cleanup `lower_pattern_unadjusted` & Improve slice pat typeck,Centril,7353ff20d66267df821d9d161b914ef8fc513304,1,`SliceKind::VarLen`: make doc-comment render correctly. (The backticks were rendering badly in VSCode.),HEART,2019-12-19T23:51:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/67445,MERGED,2019-12-20T06:47:40Z,2019-12-25T00:41:59Z,Differentiate todo! and unimplemented!,llogiq,f4d0a04c64e29184e0a92258618e5cbdd0937f86,5,Differentiate todo! and unimplemented!,THUMBS_UP,2020-01-03T17:02:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67466,MERGED,2019-12-20T22:16:39Z,2019-12-23T21:49:55Z,Require const stability attributes on intrinsics to be able to use them in constant contexts,oli-obk,63d28221c62be5c63d6df4ac83043d9cacd2a226,1,Fix typo,THUMBS_UP,2019-12-22T15:14:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67466,MERGED,2019-12-20T22:16:39Z,2019-12-23T21:49:55Z,Require const stability attributes on intrinsics to be able to use them in constant contexts,oli-obk,63d28221c62be5c63d6df4ac83043d9cacd2a226,1,Fix typo,HEART,2019-12-22T15:18:19Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67467,MERGED,2019-12-20T23:19:37Z,2019-12-21T17:35:13Z,Test slice patterns more,matthewjasper,8c3c4466483af5f51b49148c64844ea0d31b59da,9,Add more tests for slice patterns,HEART,2019-12-20T23:25:01Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67476,MERGED,2019-12-21T06:22:47Z,2020-01-18T01:10:08Z,Region naming refactoring [6/N],mark-i-m,f05e40eb992fce44db348cfb1e8ecb4699e9cdd6,3,address review comments,HEART,2019-12-21T15:55:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/67476,MERGED,2019-12-21T06:22:47Z,2020-01-18T01:10:08Z,Region naming refactoring [6/N],mark-i-m,f05e40eb992fce44db348cfb1e8ecb4699e9cdd6,3,address review comments,HEART,2020-01-16T21:33:51Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/67487,MERGED,2019-12-21T14:49:03Z,2019-12-22T22:38:23Z,Rustdoc mutability removal,GuillaumeGomez,0d7a49d3563246f193e11ae63e713c0a65319f8c,3,Implement PrintWithSpace trait on hir::Mutability,HEART,2019-12-21T15:53:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/67489,MERGED,2019-12-21T15:56:12Z,2019-12-22T00:10:13Z,Drop petgraph dependency from bootstrap,Mark-Simulacrum,28af652793f5a1a366f1f04a0d790806a4300a7a,3,Drop petgraph dependency from bootstrap It was essentially unused likely leftover from a previous refactoring iteration.,HEART,2019-12-21T16:39:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/67489,MERGED,2019-12-21T15:56:12Z,2019-12-22T00:10:13Z,Drop petgraph dependency from bootstrap,Mark-Simulacrum,28af652793f5a1a366f1f04a0d790806a4300a7a,3,Drop petgraph dependency from bootstrap It was essentially unused likely leftover from a previous refactoring iteration.,HEART,2019-12-21T17:51:22Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67489,MERGED,2019-12-21T15:56:12Z,2019-12-22T00:10:13Z,Drop petgraph dependency from bootstrap,Mark-Simulacrum,28af652793f5a1a366f1f04a0d790806a4300a7a,3,Drop petgraph dependency from bootstrap It was essentially unused likely leftover from a previous refactoring iteration.,HEART,2019-12-21T17:55:52Z,mati865,NA https://github.com/rust-lang/rust/pull/67489,MERGED,2019-12-21T15:56:12Z,2019-12-22T00:10:13Z,Drop petgraph dependency from bootstrap,Mark-Simulacrum,28af652793f5a1a366f1f04a0d790806a4300a7a,3,Drop petgraph dependency from bootstrap It was essentially unused likely leftover from a previous refactoring iteration.,THUMBS_UP,2019-12-28T15:30:07Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67490,MERGED,2019-12-21T16:29:18Z,2019-12-22T00:10:12Z,Document privacy of RangeInclusive fields,Mark-Simulacrum,519fc84852d54cf30976a5ebfbb900d6f8a96756,1,Document privacy of RangeInclusive fields,HEART,2019-12-21T17:47:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67494,MERGED,2019-12-21T18:04:19Z,2020-01-12T05:40:12Z,Constify more of alloc::Layout,lukaslueg,c5a9a14c9f793ce20d34cffac09f4ee21d541565,2,Constify alloc::Layout Tracking issue #67521 Layout::new in #66254,HEART,2019-12-21T18:18:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/67494,MERGED,2019-12-21T18:04:19Z,2020-01-12T05:40:12Z,Constify more of alloc::Layout,lukaslueg,c5a9a14c9f793ce20d34cffac09f4ee21d541565,2,Constify alloc::Layout Tracking issue #67521 Layout::new in #66254,HEART,2019-12-22T18:27:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/67499,MERGED,2019-12-21T21:12:27Z,2019-12-22T22:38:22Z,Misc MIR building cleanups,Centril,f5a8d1ab034c48b69eef8ee3618f7eb97d72810f,7,simplify MIR building with cfg.goto(...),HEART,2019-12-22T16:07:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2019-12-26T16:15:49Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2019-12-27T10:44:53Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2019-12-31T03:22:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-01-02T18:34:35Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-01-25T18:16:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-05T03:52:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-15T00:18:11Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-19T21:48:26Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-20T11:35:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-20T18:09:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-20T22:35:06Z,aleksator,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-22T06:18:20Z,EPashkin,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-03-30T13:57:41Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-04-21T13:31:27Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-05-13T21:57:00Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-05-30T10:38:23Z,bluss,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-05-30T19:50:56Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-05-31T15:00:42Z,95th,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-04T18:19:27Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-04T20:44:04Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-04T21:10:55Z,yerke,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-04T23:08:25Z,DianaNites,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-05T07:35:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-05T08:32:05Z,Tamschi,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-11T08:02:12Z,harrysarson,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-06-18T22:36:17Z,trolleyman,cgtrolley@gmail.com https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2020-10-16T05:02:06Z,cynecx,NA https://github.com/rust-lang/rust/pull/67502,MERGED,2019-12-22T00:48:08Z,2020-03-14T02:03:24Z,Optimize catch_unwind to match C++ try/catch,Mark-Simulacrum,be055d96c4c223a5ad49a0181f0b43bc46781708,39,"Auto merge of #67502 - Mark-Simulacrum:opt-catch r=Mark-Simulacrum Optimize catch_unwind to match C++ try/catch This refactors the implementation of catching unwinds to allow LLVM to inline the ""try"" closure directly into the happy path avoiding indirection. This means that the catch_unwind implementation is (after this PR) zero-cost unless a panic is thrown. https://rust.godbolt.org/z/cZcUSB is an example of the current codegen in a simple case. Notably the codegen is *exactly the same* if `-Cpanic=abort` is passed which is clearly not great. This PR on the other hand generates the following assembly: ```asm # -Cpanic=unwind: push rbx mov ebx 0x2a call QWORD PTR [rip+0x1c53c] # mov eax ebx pop rbx ret mov rdi rax call QWORD PTR [rip+0x1c537] # cleanup function call call QWORD PTR [rip+0x1c539] # mov ebx 0xd mov eax ebx pop rbx ret # -Cpanic=abort: push rax call QWORD PTR [rip+0x20a1] # mov eax 0x2a pop rcx ret ``` Fixes #64224 and resolves #64222.",HOORAY,2021-06-11T06:42:01Z,mjguynn,NA https://github.com/rust-lang/rust/pull/67504,MERGED,2019-12-22T01:36:43Z,2019-12-22T10:11:11Z,Warn against relying on ?Sized being last,Mark-Simulacrum,a34c2677afeee2747d680536f302a8c5665a65f4,2,Warn against relying on ?Sized being last,HEART,2019-12-22T01:38:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67531,MERGED,2019-12-22T17:37:46Z,2020-01-04T09:32:54Z,no longer promote non-pattern const functions,RalfJung,368ac73c11662dbb860db178dc170768078b282d,1,no longer promote non-pattern const functions,HEART,2019-12-22T17:47:28Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T21:57:07Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T21:59:08Z,oli-obk,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T22:32:02Z,cedric-h,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T22:34:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T22:53:07Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-22T23:02:41Z,ehuss,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T00:46:40Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T02:54:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T06:02:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T06:16:22Z,tesuji,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T06:37:09Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T12:12:20Z,repi,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T16:56:28Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T18:07:42Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T22:19:37Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T23:10:13Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T23:25:50Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-23T23:45:49Z,blankname,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-24T09:35:32Z,ArmenAg,armen.ag@live.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-24T17:54:32Z,CephalonRho,CephalonRho@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-27T12:57:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-27T13:05:59Z,DianaNites,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-28T07:11:05Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-30T05:33:30Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2019-12-31T17:04:49Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2020-01-03T02:40:39Z,tmandry,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2020-01-03T16:16:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2020-05-04T06:58:44Z,95th,NA https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2021-02-14T08:17:21Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/67540,MERGED,2019-12-22T21:50:40Z,2019-12-23T05:49:39Z,Format the world,Mark-Simulacrum,0f24ccd21d9f734a21daaf3566900127167556d1,1,Change bound order in rustfmt test It is unclear why this changed but since it seems like a harmless change we're going to move forward with reformatting.,ROCKET,2022-03-24T08:09:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67543,MERGED,2019-12-22T23:08:43Z,2019-12-24T06:49:06Z,Add regression tests for fixed ICEs,JohnTitor,d918319bed23b418a98720688a3f59904aada978,1,Apply suggestion from Centril Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-12-23T06:57:23Z,estebank,NA https://github.com/rust-lang/rust/pull/67543,MERGED,2019-12-22T23:08:43Z,2019-12-24T06:49:06Z,Add regression tests for fixed ICEs,JohnTitor,d918319bed23b418a98720688a3f59904aada978,1,Apply suggestion from Centril Co-Authored-By: Mazdak Farrokhzad ,HEART,2019-12-24T08:39:20Z,felix91gr,NA https://github.com/rust-lang/rust/pull/67562,CLOSED,2019-12-23T15:51:19Z,2020-01-14T22:34:55Z,Make `Any` an unsafe trait,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2019-12-23T16:27:49Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67562,CLOSED,2019-12-23T15:51:19Z,2020-01-14T22:34:55Z,Make `Any` an unsafe trait,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2019-12-24T22:03:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67562,CLOSED,2019-12-23T15:51:19Z,2020-01-14T22:34:55Z,Make `Any` an unsafe trait,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2019-12-25T00:31:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/67566,MERGED,2019-12-23T18:15:06Z,2020-01-07T08:11:44Z,Add an unstable conversion from thread ID to u64,Mark-Simulacrum,d9a7db901e33940cb2ccda6afe21b9916e66d9d2,1,Add an unstable conversion from thread ID to u64 We see multiple cases inside rustc and ecosystem code where ThreadId is transmuted to u64 exploiting the underlying detail. This is suboptimal (can break unexpectedly if we change things in std). It is unlikely that ThreadId will ever need to be larger than u64 -- creating even 2^32 threads over the course of a program is quite hard 2^64 is even harder. As such we do not choose to return a larger sized type (e.g. u128). If we choose to shrink ThreadId in the future or otherwise change its internals it is likely that a mapping to u64 will still be applicable (though may become more complex).,THUMBS_UP,2019-12-28T11:24:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67569,MERGED,2019-12-23T22:40:55Z,2019-12-24T06:49:01Z,Clean up unsafety in char::encode_utf8,Mark-Simulacrum,df4d490038c37e441065890fa27ed2ce0bdf83e6,2,Minimize unsafety in encode_utf8 Use slice patterns to avoid having to skip bounds checking,HEART,2019-12-23T23:52:15Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67569,MERGED,2019-12-23T22:40:55Z,2019-12-24T06:49:01Z,Clean up unsafety in char::encode_utf8,Mark-Simulacrum,df4d490038c37e441065890fa27ed2ce0bdf83e6,2,Minimize unsafety in encode_utf8 Use slice patterns to avoid having to skip bounds checking,HEART,2020-01-22T21:15:23Z,lovasoa,NA https://github.com/rust-lang/rust/pull/67569,MERGED,2019-12-23T22:40:55Z,2019-12-24T06:49:01Z,Clean up unsafety in char::encode_utf8,Mark-Simulacrum,df4d490038c37e441065890fa27ed2ce0bdf83e6,2,Minimize unsafety in encode_utf8 Use slice patterns to avoid having to skip bounds checking,HEART,2020-01-23T01:22:43Z,estebank,NA https://github.com/rust-lang/rust/pull/67572,MERGED,2019-12-23T23:34:05Z,2019-12-24T06:49:01Z,Use the chocolatey CDN directly to avoid the flaky API,aidanhs,cefeb663666de29b42a4c233bee14793712613ae,1,Use the chocolatey CDN directly to avoid the flaky API,HEART,2019-12-24T02:05:40Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67585,MERGED,2019-12-24T14:04:54Z,2020-02-12T19:32:49Z,Improve `char::is_ascii_*` codegen,ranma42,4e7aeaf1b52ee66ede1adb104fcd08b0463eb0f9,1,Improve `char::is_ascii_*` code These methods explicitly check if a char is in a specific ASCII range therefore the `is_ascii()` check is not needed but LLVM seems to be unable to remove it. WARNING: this change improves the performance on ASCII `char`s but complex checks such as `is_ascii_punctuation` become slower on non-ASCII `char`s.,HEART,2020-01-25T03:53:18Z,panaman67,NA https://github.com/rust-lang/rust/pull/67588,MERGED,2019-12-24T15:16:19Z,2019-12-28T03:37:14Z,Use NonNull in slice::Iter and slice::IterMut.,Kixunil,2c796ee77c17a1af59a4bd311f2f4d8dd7332140,1,Use NonNull in slice::Iter and slice::IterMut. `ptr` of `slice::Iter` and `slice::IterMut` can never be null but this fact wasn't exploited for layout optimizations. By changing `ptr` from `* T` to `NonNull` the compiler can now optimize layout of `Option>`.,HEART,2019-12-28T10:34:57Z,olso,NA https://github.com/rust-lang/rust/pull/67594,MERGED,2019-12-24T19:03:29Z,2019-12-28T03:37:13Z,Update libc to 0.2.66,oxalica,ac31c716982489291ea2413e1a33dfceefb10aed,1,Update libc to 0.2.66,THUMBS_UP,2019-12-25T05:16:04Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/67594,MERGED,2019-12-24T19:03:29Z,2019-12-28T03:37:13Z,Update libc to 0.2.66,oxalica,ac31c716982489291ea2413e1a33dfceefb10aed,1,Update libc to 0.2.66,THUMBS_UP,2019-12-28T13:33:04Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/67635,MERGED,2019-12-26T17:14:09Z,2019-12-28T03:37:05Z,Document safety of Path casting,Mark-Simulacrum,9c0f3f7f2ae2492542fea99338fac13242cfe25e,1,Document safety of Path casting,HOORAY,2019-12-28T05:03:46Z,udoprog,udoprog@tedro.se https://github.com/rust-lang/rust/pull/67637,MERGED,2019-12-26T17:59:11Z,2020-02-26T04:57:24Z,Add primitive module to libcore,Mark-Simulacrum,0860f5aebd1939b821cf9af5ba568cbd6be8077e,5,Rollup merge of #67637 - Mark-Simulacrum:primitive-mod r=dtolnay Add primitive module to libcore This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from. Fixes #44865,THUMBS_UP,2020-02-11T01:42:17Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/67637,MERGED,2019-12-26T17:59:11Z,2020-02-26T04:57:24Z,Add primitive module to libcore,Mark-Simulacrum,0860f5aebd1939b821cf9af5ba568cbd6be8077e,5,Rollup merge of #67637 - Mark-Simulacrum:primitive-mod r=dtolnay Add primitive module to libcore This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from. Fixes #44865,THUMBS_UP,2020-04-06T21:36:32Z,rrbutani,NA https://github.com/rust-lang/rust/pull/67637,MERGED,2019-12-26T17:59:11Z,2020-02-26T04:57:24Z,Add primitive module to libcore,Mark-Simulacrum,0860f5aebd1939b821cf9af5ba568cbd6be8077e,5,Rollup merge of #67637 - Mark-Simulacrum:primitive-mod r=dtolnay Add primitive module to libcore This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from. Fixes #44865,THUMBS_UP,2020-04-23T15:58:20Z,weihanglo,NA https://github.com/rust-lang/rust/pull/67637,MERGED,2019-12-26T17:59:11Z,2020-02-26T04:57:24Z,Add primitive module to libcore,Mark-Simulacrum,0860f5aebd1939b821cf9af5ba568cbd6be8077e,5,Rollup merge of #67637 - Mark-Simulacrum:primitive-mod r=dtolnay Add primitive module to libcore This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from. Fixes #44865,HEART,2020-04-23T21:31:43Z,cristaloleg,oleg@hey.com https://github.com/rust-lang/rust/pull/67657,MERGED,2019-12-27T12:09:07Z,2019-12-30T08:24:04Z,Clean up const-hack PRs now that const if / match exist.,jumbatm,91c2f78b504e60e5c82ff3944d6663785bf47eee,1,Clean up const-hack from #58044,THUMBS_UP,2019-12-29T04:03:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67657,MERGED,2019-12-27T12:09:07Z,2019-12-30T08:24:04Z,Clean up const-hack PRs now that const if / match exist.,jumbatm,91c2f78b504e60e5c82ff3944d6663785bf47eee,1,Clean up const-hack from #58044,HEART,2020-08-07T11:37:12Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67658,MERGED,2019-12-27T12:10:05Z,2019-12-30T11:31:08Z,Avoid memory copy logic for zsts,spastorino,250a636217977ece9bbfcf21e5af7600ee57b5c5,2,Avoid copying some undef memory in MIR During MIR interpretation it may happen that a place containing uninitialized bytes is copied. This would read the current representation of these bytes and write it to the destination even though they must by definition not matter to the execution. This elides that representation change when no bytes are defined in such a copy saving some cpu cycles. In such a case the memory of the target allocation is not touched at all which also means that sometimes no physical page backing the memory allocation of the representation needs to be provided by the OS at all reducing memory pressure on the system.,HOORAY,2019-12-27T12:14:09Z,mati865,NA https://github.com/rust-lang/rust/pull/67658,MERGED,2019-12-27T12:10:05Z,2019-12-30T11:31:08Z,Avoid memory copy logic for zsts,spastorino,250a636217977ece9bbfcf21e5af7600ee57b5c5,2,Avoid copying some undef memory in MIR During MIR interpretation it may happen that a place containing uninitialized bytes is copied. This would read the current representation of these bytes and write it to the destination even though they must by definition not matter to the execution. This elides that representation change when no bytes are defined in such a copy saving some cpu cycles. In such a case the memory of the target allocation is not touched at all which also means that sometimes no physical page backing the memory allocation of the representation needs to be provided by the OS at all reducing memory pressure on the system.,HOORAY,2019-12-28T18:14:38Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/67658,MERGED,2019-12-27T12:10:05Z,2019-12-30T11:31:08Z,Avoid memory copy logic for zsts,spastorino,250a636217977ece9bbfcf21e5af7600ee57b5c5,2,Avoid copying some undef memory in MIR During MIR interpretation it may happen that a place containing uninitialized bytes is copied. This would read the current representation of these bytes and write it to the destination even though they must by definition not matter to the execution. This elides that representation change when no bytes are defined in such a copy saving some cpu cycles. In such a case the memory of the target allocation is not touched at all which also means that sometimes no physical page backing the memory allocation of the representation needs to be provided by the OS at all reducing memory pressure on the system.,HOORAY,2020-01-03T01:45:53Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/67658,MERGED,2019-12-27T12:10:05Z,2019-12-30T11:31:08Z,Avoid memory copy logic for zsts,spastorino,250a636217977ece9bbfcf21e5af7600ee57b5c5,2,Avoid copying some undef memory in MIR During MIR interpretation it may happen that a place containing uninitialized bytes is copied. This would read the current representation of these bytes and write it to the destination even though they must by definition not matter to the execution. This elides that representation change when no bytes are defined in such a copy saving some cpu cycles. In such a case the memory of the target allocation is not touched at all which also means that sometimes no physical page backing the memory allocation of the representation needs to be provided by the OS at all reducing memory pressure on the system.,HOORAY,2020-01-03T17:08:23Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,HOORAY,2019-12-28T00:42:41Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,HEART,2020-01-02T23:24:44Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,HOORAY,2020-01-02T23:24:46Z,niklasf,niklas.fiekas@backscattering.de https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,CONFUSED,2020-01-03T16:45:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,HOORAY,2020-01-03T17:16:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67659,MERGED,2019-12-27T13:11:28Z,2019-12-28T03:37:02Z,Stabilize the `matches!` macro,SimonSapin,1c572a2d6e7b9fe0d8dad4840c72ccc3f4add47b,5,Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119,HOORAY,2020-01-07T17:05:20Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-27T23:01:28Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-27T23:14:57Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-28T06:23:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-28T09:53:21Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-29T04:02:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2019-12-29T18:53:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-01-27T19:17:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-01-28T13:15:28Z,CryZe,NA https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-02-03T17:12:44Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-02-04T06:32:21Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-02-05T14:48:57Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-02-13T15:08:47Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67668,MERGED,2019-12-27T20:57:30Z,2020-02-04T01:24:02Z,Implement MIR lowering for or-patterns,matthewjasper,8dbbe4d14467d95d89ca3dff9054522f32cc12e8,3,Avoid scheduling repeated `StorageDead`s Also add some comments,HEART,2020-02-13T17:11:42Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/67676,MERGED,2019-12-28T11:48:38Z,2020-01-02T00:37:10Z,Lint overflowing integer casts in const prop,wesleywiser,e8c1c4cd5bc0d370f59d0399ae2458e872a51622,1,Ignore overflow lint on 32-bit platform,THUMBS_UP,2019-12-28T12:12:50Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/67676,MERGED,2019-12-28T11:48:38Z,2020-01-02T00:37:10Z,Lint overflowing integer casts in const prop,wesleywiser,e8c1c4cd5bc0d370f59d0399ae2458e872a51622,1,Ignore overflow lint on 32-bit platform,THUMBS_UP,2019-12-31T21:10:33Z,estebank,NA https://github.com/rust-lang/rust/pull/67688,MERGED,2019-12-28T22:37:43Z,2020-01-30T02:26:33Z,Move some code to librustc_passes.,cjgillot,f9335e990897b9ad1f072eb0a8e7385d720538f2,1,Make Target::from_impl_item a free function.,HOORAY,2019-12-29T01:00:30Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67701,MERGED,2019-12-29T11:40:13Z,2019-12-30T08:23:57Z,tidy: Enforce formatting rather than just check it if `--bless` is specified,petrochenkov,5b80a99a9f72d0f95641b9ab9358fa3801d68be0,1,tidy: Enforce formatting rather than just check it if `--bless` is specified,THUMBS_UP,2019-12-29T11:44:43Z,mati865,NA https://github.com/rust-lang/rust/pull/67707,MERGED,2019-12-29T16:47:54Z,2019-12-30T21:35:06Z,Rename some crates and modules in the frontend,petrochenkov,7608f21b278d9aadcdebbb6d99760d70c52d5750,7,Rename `rustc_resolve/resolve_imports.rs` -> `rustc_resolve/imports.rs`,HOORAY,2019-12-30T20:18:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67707,MERGED,2019-12-29T16:47:54Z,2019-12-30T21:35:06Z,Rename some crates and modules in the frontend,petrochenkov,7608f21b278d9aadcdebbb6d99760d70c52d5750,7,Rename `rustc_resolve/resolve_imports.rs` -> `rustc_resolve/imports.rs`,HOORAY,2019-12-31T07:29:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/67707,MERGED,2019-12-29T16:47:54Z,2019-12-30T21:35:06Z,Rename some crates and modules in the frontend,petrochenkov,7608f21b278d9aadcdebbb6d99760d70c52d5750,7,Rename `rustc_resolve/resolve_imports.rs` -> `rustc_resolve/imports.rs`,HOORAY,2019-12-31T22:31:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67707,MERGED,2019-12-29T16:47:54Z,2019-12-30T21:35:06Z,Rename some crates and modules in the frontend,petrochenkov,7608f21b278d9aadcdebbb6d99760d70c52d5750,7,Rename `rustc_resolve/resolve_imports.rs` -> `rustc_resolve/imports.rs`,HOORAY,2020-01-16T19:52:14Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T01:23:24Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T01:26:56Z,est31,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T01:32:32Z,connorskees,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T01:40:23Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,EYES,2019-12-30T01:45:51Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T01:50:31Z,crlf0710,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T02:07:32Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T02:46:52Z,whentze,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T03:26:44Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T03:26:46Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T03:29:37Z,tkadur,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T03:30:52Z,nicklauri,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T03:32:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T03:39:12Z,leudz,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T05:08:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T05:23:08Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T05:23:10Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T05:39:43Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T05:39:46Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T05:47:27Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T07:28:51Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T08:12:11Z,lnicola,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T08:15:08Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T08:29:40Z,elmarco,marcandre.lureau@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T08:33:35Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T08:53:28Z,Freyskeyd,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T09:06:50Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T09:46:09Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T10:18:11Z,lqd,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T10:24:28Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T10:35:55Z,PSeitz,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,EYES,2019-12-30T10:45:11Z,glaebhoerl,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T10:46:00Z,Inomares,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T10:46:01Z,Inomares,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T11:00:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2019-12-30T11:15:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T11:40:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T12:43:28Z,teh-cmc,cr.rey.clement@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T13:46:33Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2019-12-30T13:46:36Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T14:14:36Z,vallentin,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T14:37:01Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T14:39:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T14:39:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-30T14:39:49Z,mikhail-m1,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-30T14:50:21Z,weirane,gh@ruo-chen.wang https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2019-12-30T19:46:44Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-31T00:56:57Z,shengsheng,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-31T00:56:59Z,shengsheng,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2019-12-31T01:58:12Z,krdln,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,EYES,2019-12-31T02:52:54Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-31T02:52:56Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-31T02:52:57Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2019-12-31T05:38:38Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-31T05:38:39Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2019-12-31T13:01:48Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,EYES,2019-12-31T20:11:12Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-01T21:54:48Z,janriemer,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-01T21:54:49Z,janriemer,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-01T21:54:50Z,janriemer,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-02T09:39:23Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-08T05:05:12Z,estebank,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-10T12:05:14Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-14T08:03:58Z,unbornchikken,gabor.mezo@outlook.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-17T03:40:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-20T17:15:19Z,95th,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-20T17:15:19Z,95th,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-21T09:19:43Z,LoyVanBeek,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-21T09:19:47Z,LoyVanBeek,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-21T11:32:49Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-21T11:32:51Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-21T11:32:52Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,ROCKET,2020-01-21T11:32:55Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-22T07:07:04Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-22T11:36:14Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-22T11:36:18Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-22T13:09:45Z,jgall,John.willis.gallagher@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-22T15:27:10Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-24T13:16:46Z,anykey111,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-24T13:16:46Z,anykey111,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-24T13:16:47Z,anykey111,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-01-27T09:23:09Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-01-27T09:23:13Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-27T09:23:14Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-01-29T21:58:21Z,tjkirch,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-02-10T15:34:34Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-02-10T15:34:53Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-03-04T09:41:32Z,aplanas,aplanas@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-03-04T11:54:10Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-03-04T13:20:27Z,mars90226,mars.90226@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-03-05T08:46:08Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,ROCKET,2020-03-05T21:58:51Z,kellytk,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-03-05T21:58:52Z,kellytk,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-03-05T21:58:53Z,kellytk,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-03-11T02:47:19Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-03-11T02:47:22Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-03-13T08:30:18Z,EdmundsEcho,edmund.cape@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-03-14T00:04:33Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-04-18T00:35:10Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HEART,2020-04-18T00:35:11Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,HOORAY,2020-04-18T00:35:12Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-04-22T03:25:08Z,kajmagnus,NA https://github.com/rust-lang/rust/pull/67712,MERGED,2019-12-30T00:43:03Z,2020-01-18T22:09:13Z,Stabilize `#![feature(slice_patterns)]` in 1.42.0,Centril,57b6843100b247b6065b71e4485572dda4bfccc6,2,slice_patterns: address review comments,THUMBS_UP,2020-04-24T21:38:46Z,acoman92,NA https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2019-12-31T06:28:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2019-12-31T20:49:09Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2020-01-05T11:19:56Z,varkor,NA https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2020-01-05T23:53:21Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2020-01-07T09:23:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2020-01-15T21:10:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67717,CLOSED,2019-12-30T03:19:08Z,2020-01-24T07:15:07Z,Turn const eval queries into canonical queries,skinny121,NA,NA,NA,HOORAY,2020-01-22T18:28:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67727,MERGED,2019-12-30T11:52:17Z,2020-01-07T08:11:35Z,Stabilise vec::remove_item,Dylan-DPC-zz,503d06b90dfd8f6055c586c488dbd3a741e9f0c2,1,oh the one that was left behind,HOORAY,2019-12-31T04:07:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67727,MERGED,2019-12-30T11:52:17Z,2020-01-07T08:11:35Z,Stabilise vec::remove_item,Dylan-DPC-zz,503d06b90dfd8f6055c586c488dbd3a741e9f0c2,1,oh the one that was left behind,THUMBS_DOWN,2020-01-07T12:49:35Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T14:13:37Z,mati865,NA https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,ROCKET,2019-12-30T14:13:40Z,mati865,NA https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T14:31:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T15:24:45Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T16:16:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T16:40:56Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/67733,MERGED,2019-12-30T14:12:08Z,2020-01-08T09:04:11Z,GitHub Actions: preparations part 2,pietroalbini,39ddbeb87470071113d03fa7dfc34164180c76d6,1,ci: fix wrong sysroot in macos 10.15 onwards In their infinite wisdom Apple decided that (starting from macOS 10.15 onwards) /usr/include is not the location we should all search in for our beloved C headers. Instead we should look inside the extremely intuitive and easily guessable new path: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include Because why not.,HOORAY,2019-12-30T23:31:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67736,MERGED,2019-12-30T20:17:37Z,2020-01-03T12:22:16Z,Less-than is asymmetric not antisymmetric,taralx,d935a26d9d06eee42a5554af23b55af4fc2008cc,1,Less-than is asymmetric not antisymmetric This has bothered me for a while. It's such a small nit but...,THUMBS_UP,2019-12-30T20:37:12Z,petertodd,pete@petertodd.org https://github.com/rust-lang/rust/pull/67741,MERGED,2019-12-31T01:43:06Z,2020-03-07T12:03:35Z,When encountering an Item in a pat context point at the item def,estebank,e8bb6c05ab455999ccfe10e178bc2ada9d450187,10,Rollup merge of #67741 - estebank:point-at-pat-def r=Centril When encountering an Item in a pat context point at the item def ``` error[E0308]: mismatched types --> $DIR/const-in-struct-pat.rs:8:17 | LL | struct foo; | ----------- `foo` defined here ... LL | let Thing { foo } = t; | ^^^ expected struct `std::string::String` found struct `foo` | = note: `foo` is interpreted as a unit struct not a new binding help: you can bind the struct field to a different name | LL | let Thing { foo: other_foo } = t; | ^^^^^^^^^^^^^^ ``` ``` error[E0308]: mismatched types --> $DIR/const.rs:14:9 | LL | const FOO: Foo = Foo{bar: 5}; | ----------------------------- constant defined here ... LL | FOO => {} | ^^^ | | | expected `&Foo` found struct `Foo` | `FOO` is interpreted as a constant not a new binding | help: use different name to introduce a new binding: `other_foo` ``` Fix #55631 fix #48062 cc #42876.,HEART,2020-03-13T08:13:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67744,MERGED,2019-12-31T03:38:14Z,2019-12-31T22:51:18Z,parser: reduce diversity in error handling mechanisms,Centril,2e7806146c008742919124bf6ac9a37c3ece51bb,4,parser: bug -> span_bug,HOORAY,2019-12-31T05:36:41Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67744,MERGED,2019-12-31T03:38:14Z,2019-12-31T22:51:18Z,parser: reduce diversity in error handling mechanisms,Centril,2e7806146c008742919124bf6ac9a37c3ece51bb,4,parser: bug -> span_bug,HOORAY,2019-12-31T06:50:28Z,est31,NA https://github.com/rust-lang/rust/pull/67744,MERGED,2019-12-31T03:38:14Z,2019-12-31T22:51:18Z,parser: reduce diversity in error handling mechanisms,Centril,2e7806146c008742919124bf6ac9a37c3ece51bb,4,parser: bug -> span_bug,HOORAY,2019-12-31T20:58:15Z,estebank,NA https://github.com/rust-lang/rust/pull/67748,MERGED,2019-12-31T05:43:02Z,2019-12-31T22:51:17Z,"Use function attribute ""frame-pointer"" instead of ""no-frame-pointer-elim""",MaskRay,b40dc30a3ea218caae39052eb0ef57fb15493072,3,"Use function attribute ""frame-pointer"" instead of ""no-frame-pointer-elim"" LLVM 8 (D56351) introduced ""frame-pointer"". In LLVM 10 (D71863) ""no-frame-pointer-elim""/""no-frame-pointer-elim-non-leaf"" will be ignored.",THUMBS_UP,2019-12-31T08:51:24Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2019-12-31T20:42:28Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2019-12-31T20:45:56Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2019-12-31T20:45:58Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-01-01T00:13:38Z,kellytk,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-01T02:03:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-01T11:02:56Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-01T15:45:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-01T18:19:15Z,mati865,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-01-05T15:19:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-14T20:22:00Z,palango,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-01-21T03:34:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-01-21T22:59:24Z,tmandry,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-01-24T22:06:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-01-31T17:53:45Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-02-06T02:52:21Z,sinkuu,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-02-07T14:59:31Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-02-13T22:53:00Z,awulkan,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-03-03T18:51:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-25T23:57:52Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-03-25T23:57:53Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T17:53:17Z,ctaggart,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T18:11:34Z,futile,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-03-26T18:21:13Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-03-26T18:21:13Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-03-26T18:21:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T18:21:15Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T18:47:38Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-03-26T19:28:05Z,frol,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T19:28:06Z,frol,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-03-26T19:28:07Z,frol,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-03-26T19:28:11Z,frol,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-03-26T19:38:44Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-26T23:21:07Z,xStrom,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-29T02:22:26Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-03-31T09:04:50Z,trevyn,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,EYES,2020-04-09T16:36:42Z,g2p,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-04-21T21:34:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-04-21T21:34:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-04-21T21:40:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-05T19:52:41Z,dbalabka,dmitry.balabka@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-05T23:11:06Z,oleg-andreyev,oleg@andreyev.lv https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-06T07:48:21Z,iago-lito,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-06T07:48:24Z,iago-lito,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-10T19:25:07Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-10T19:25:09Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-10T19:54:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-10T20:01:33Z,gbrlsnchs,gabriel@gsr.dev https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-18T23:05:18Z,hbina,hanif.ariffin.4326@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-05-21T15:31:40Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-21T15:31:41Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T15:31:42Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-21T15:31:42Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T17:23:40Z,eduardosalaz,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-21T17:24:18Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-21T17:24:21Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,EYES,2020-05-21T17:24:22Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T17:24:24Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-05-21T17:24:25Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-05-21T17:48:06Z,alanyee,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T18:45:45Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T20:16:48Z,DenisRokker,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-21T20:25:45Z,yannleretaille,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-22T00:41:06Z,ryboe,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-22T00:41:06Z,ryboe,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-22T00:41:06Z,ryboe,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-22T07:11:00Z,robatipoor,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-22T11:14:28Z,reza-ebrahimi,reza.ebrahimi.dev@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-23T19:26:41Z,senseiod,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-25T04:25:22Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-25T04:25:24Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-25T04:25:25Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-05-25T04:25:26Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,EYES,2020-05-25T04:25:27Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-27T20:03:15Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-27T20:56:58Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-28T02:40:09Z,lygz5016,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-28T18:24:52Z,Sakul6499,me@sakul6499.de https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-05-28T18:24:53Z,Sakul6499,me@sakul6499.de https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-05-29T12:50:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-31T09:40:28Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-05-31T15:45:07Z,iwa13,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-07-01T11:12:48Z,narniec,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-07-01T11:12:49Z,narniec,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HEART,2020-07-01T11:12:49Z,narniec,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,ROCKET,2020-07-01T11:12:50Z,narniec,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,EYES,2020-07-01T11:12:50Z,narniec,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-07-14T01:55:03Z,rabirabirara,swyverng55@g.ucla.edu https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,THUMBS_UP,2020-07-28T02:45:50Z,atlx,NA https://github.com/rust-lang/rust/pull/67759,MERGED,2019-12-31T14:59:38Z,2020-05-21T02:55:20Z,Update to LLVM 10,nikic,82911b3bba76e73afe2881b732fe6b0edb35d5d3,3,Auto merge of #67759 - nikic:llvm-10 r=Mark-Simulacrum Update to LLVM 10 LLVM 10 is going to be branched soon so it's a good time to start finding all those tasty new miscompiles and performance regressions ;) Status: * Preparation split off into #67900. * Optimization regressions: * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed. * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed. * [x] https://reviews.llvm.org/D72169 submitted. * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted but unlikely eligible for LLVM 10. * Compile-time regressions: * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch. * [ ] Even with the revert there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14). * Assertion failures / infinite loops: * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135 https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch. * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.,HOORAY,2020-07-28T02:45:51Z,atlx,NA https://github.com/rust-lang/rust/pull/67768,MERGED,2020-01-01T01:39:03Z,2020-01-03T09:07:12Z,Revert #65244 for performance reasons,wesleywiser,717702dffdf9ddb84e1fd35f189511a307e350e1,10,"Revert ""core: add IntoFuture trait and support for await"" This reverts commit f35517ee861dc012ccc26083dd4520045e2c4f6f.",HEART,2020-01-01T03:27:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67770,MERGED,2020-01-01T03:51:35Z,2020-01-08T15:25:56Z,More reductions in error handling diversity,Centril,20ebb807d523947f5fac710c4ae95ac9730ad995,1,span_to_lines: account for DUMMY_SP,HEART,2020-01-06T22:03:12Z,estebank,NA https://github.com/rust-lang/rust/pull/67791,MERGED,2020-01-02T00:31:21Z,2020-01-17T19:34:15Z,Implement Lift using interners instead of in_arena,Zoxc,f4968c8e00daed7cc4e5658a7abe61557abd4570,1,Remove SyncTypedArena SyncDroplessArena and in_arena,THUMBS_UP,2020-01-11T08:59:52Z,lqd,NA https://github.com/rust-lang/rust/pull/67797,MERGED,2020-01-02T03:10:42Z,2020-04-05T22:49:22Z,Query-ify Instance::resolve,Aaron1011,829154f9807801b55317c4c4eea887829434c758,7,Rollup merge of #67797 - Aaron1011:feature/instance-query r=nikomatsakis Query-ify Instance::resolve Split off from #65989 Instance::resolve is now a wrapper for a new `resolve_instance` query. This greatly improves performance on several benchmarks,HEART,2020-02-05T13:03:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67797,MERGED,2020-01-02T03:10:42Z,2020-04-05T22:49:22Z,Query-ify Instance::resolve,Aaron1011,829154f9807801b55317c4c4eea887829434c758,7,Rollup merge of #67797 - Aaron1011:feature/instance-query r=nikomatsakis Query-ify Instance::resolve Split off from #65989 Instance::resolve is now a wrapper for a new `resolve_instance` query. This greatly improves performance on several benchmarks,HEART,2020-02-07T18:04:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67797,MERGED,2020-01-02T03:10:42Z,2020-04-05T22:49:22Z,Query-ify Instance::resolve,Aaron1011,829154f9807801b55317c4c4eea887829434c758,7,Rollup merge of #67797 - Aaron1011:feature/instance-query r=nikomatsakis Query-ify Instance::resolve Split off from #65989 Instance::resolve is now a wrapper for a new `resolve_instance` query. This greatly improves performance on several benchmarks,HEART,2020-03-10T03:29:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/67803,MERGED,2020-01-02T07:58:52Z,2020-01-05T01:18:47Z,Extract `rustc_hir` out of `rustc`,Centril,cdf32e1a0f8fc207b177857775c29549f609a094,2,pacify the parallel compiler,ROCKET,2020-01-02T10:50:05Z,mati865,NA https://github.com/rust-lang/rust/pull/67803,MERGED,2020-01-02T07:58:52Z,2020-01-05T01:18:47Z,Extract `rustc_hir` out of `rustc`,Centril,cdf32e1a0f8fc207b177857775c29549f609a094,2,pacify the parallel compiler,ROCKET,2020-01-02T19:04:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67803,MERGED,2020-01-02T07:58:52Z,2020-01-05T01:18:47Z,Extract `rustc_hir` out of `rustc`,Centril,cdf32e1a0f8fc207b177857775c29549f609a094,2,pacify the parallel compiler,ROCKET,2020-01-02T22:52:04Z,twilco,tyler.wilcock@protonmail.com https://github.com/rust-lang/rust/pull/67803,MERGED,2020-01-02T07:58:52Z,2020-01-05T01:18:47Z,Extract `rustc_hir` out of `rustc`,Centril,cdf32e1a0f8fc207b177857775c29549f609a094,2,pacify the parallel compiler,ROCKET,2020-01-03T02:42:35Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/67803,MERGED,2020-01-02T07:58:52Z,2020-01-05T01:18:47Z,Extract `rustc_hir` out of `rustc`,Centril,cdf32e1a0f8fc207b177857775c29549f609a094,2,pacify the parallel compiler,THUMBS_UP,2020-01-03T02:49:30Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/67808,MERGED,2020-01-02T13:31:02Z,2020-01-05T04:45:01Z,perf: Don't recurse into types that do not need normalizing,Marwes,e6e61d9dff939c1c4ebbae0006efe2a7ac038ff6,1,perf: Don't recurse into types that do not need normalizing A bit speculative at this stage but profiling shows that type folding takes up a substantial amount of time during normalization which may indicate that many types may be folded despite there being nothing to normalize,ROCKET,2020-01-02T19:42:33Z,mati865,NA https://github.com/rust-lang/rust/pull/67808,MERGED,2020-01-02T13:31:02Z,2020-01-05T04:45:01Z,perf: Don't recurse into types that do not need normalizing,Marwes,e6e61d9dff939c1c4ebbae0006efe2a7ac038ff6,1,perf: Don't recurse into types that do not need normalizing A bit speculative at this stage but profiling shows that type folding takes up a substantial amount of time during normalization which may indicate that many types may be folded despite there being nothing to normalize,ROCKET,2020-01-03T14:32:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/67810,MERGED,2020-01-02T15:39:26Z,2020-01-04T09:32:38Z,Implement uncommon_codepoints lint.,crlf0710,485e98aae2f4d6e7d795eb13170a08407a776fdf,7,Implement uncommon_codepoints lint.,HEART,2020-01-02T16:16:43Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/67810,MERGED,2020-01-02T15:39:26Z,2020-01-04T09:32:38Z,Implement uncommon_codepoints lint.,crlf0710,485e98aae2f4d6e7d795eb13170a08407a776fdf,7,Implement uncommon_codepoints lint.,HEART,2020-01-05T21:01:03Z,estebank,NA https://github.com/rust-lang/rust/pull/67829,MERGED,2020-01-03T09:47:28Z,2020-01-04T01:15:53Z,Attempt to fix intermittent failures of pgo-branch-weights test.,michaelwoerister,971aa2bd6218fb6c843db965f7da70586865171d,1,Attempt to fix intermittent failures of pgo-branch-weights test.,HEART,2020-01-03T14:56:44Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67835,MERGED,2020-01-03T14:11:33Z,2020-01-04T09:32:35Z,tweak wording of mismatched delimiter errors,euclio,7fd014d56986d7b52c49f07fb8db9529059d839d,50,tweak wording of mismatched delimiter errors,HEART,2020-01-05T21:02:41Z,estebank,NA https://github.com/rust-lang/rust/pull/67848,MERGED,2020-01-03T23:52:47Z,2020-01-04T15:34:38Z,"Remove unused `#[link_name = ""m""]` attributes",ollie27,83333fe85b25c77f35b79bf06cde69b889558dca,3,"Remove unused `#[link_name = ""m""]` attributes These were perhaps supposed to be `#[link(name = ""m"")]` but linking libm should be handled by the libc crate anyway.",LAUGH,2020-01-04T00:41:54Z,mati865,NA https://github.com/rust-lang/rust/pull/67849,MERGED,2020-01-04T00:39:03Z,2020-01-08T22:55:57Z,Add a check for swapped words when we can't find an identifier,cjkenn,e01e8b9256587a074968b440aa30d43b31642cb5,2,add ui test,THUMBS_UP,2020-01-04T10:07:21Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/67875,MERGED,2020-01-04T19:36:56Z,2020-01-08T22:55:55Z,Distinguish between private items and hidden items in rustdoc,dtolnay,90adafbc9e6583fa2edae0f320e7fe51407e7f3b,20,Distinguish between private items and hidden items in rustdoc I believe rustdoc should not be conflating private items (visibility lower than `pub`) and hidden items (attribute `doc(hidden)`). This matters now that Cargo is passing --document-private-items by default for bin crates. In bin crates that rely on macros intentionally hidden implementation details of the macros can overwhelm the actual useful internal API that one would want to document. This PR restores the strip-hidden pass when documenting private items and introduces a separate unstable --document-hidden-items option to skip the strip-hidden pass. The two options are orthogonal to one another.,THUMBS_UP,2020-01-04T19:41:38Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/67875,MERGED,2020-01-04T19:36:56Z,2020-01-08T22:55:55Z,Distinguish between private items and hidden items in rustdoc,dtolnay,90adafbc9e6583fa2edae0f320e7fe51407e7f3b,20,Distinguish between private items and hidden items in rustdoc I believe rustdoc should not be conflating private items (visibility lower than `pub`) and hidden items (attribute `doc(hidden)`). This matters now that Cargo is passing --document-private-items by default for bin crates. In bin crates that rely on macros intentionally hidden implementation details of the macros can overwhelm the actual useful internal API that one would want to document. This PR restores the strip-hidden pass when documenting private items and introduces a separate unstable --document-hidden-items option to skip the strip-hidden pass. The two options are orthogonal to one another.,THUMBS_UP,2020-01-16T15:16:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/67875,MERGED,2020-01-04T19:36:56Z,2020-01-08T22:55:55Z,Distinguish between private items and hidden items in rustdoc,dtolnay,90adafbc9e6583fa2edae0f320e7fe51407e7f3b,20,Distinguish between private items and hidden items in rustdoc I believe rustdoc should not be conflating private items (visibility lower than `pub`) and hidden items (attribute `doc(hidden)`). This matters now that Cargo is passing --document-private-items by default for bin crates. In bin crates that rely on macros intentionally hidden implementation details of the macros can overwhelm the actual useful internal API that one would want to document. This PR restores the strip-hidden pass when documenting private items and introduces a separate unstable --document-hidden-items option to skip the strip-hidden pass. The two options are orthogonal to one another.,THUMBS_UP,2020-01-17T14:00:56Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67877,MERGED,2020-01-04T20:39:55Z,2020-01-07T08:11:24Z,Omit underscore constants from rustdoc,dtolnay,097126e2840425b7d11f269c39a22c86ef003d6b,2,Omit underscore constants from rustdoc,LAUGH,2020-01-05T02:33:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/67877,MERGED,2020-01-04T20:39:55Z,2020-01-07T08:11:24Z,Omit underscore constants from rustdoc,dtolnay,097126e2840425b7d11f269c39a22c86ef003d6b,2,Omit underscore constants from rustdoc,THUMBS_UP,2020-01-05T02:33:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/67877,MERGED,2020-01-04T20:39:55Z,2020-01-07T08:11:24Z,Omit underscore constants from rustdoc,dtolnay,097126e2840425b7d11f269c39a22c86ef003d6b,2,Omit underscore constants from rustdoc,THUMBS_UP,2020-01-05T03:05:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-01-04T23:59:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-01-05T02:32:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-01-07T16:05:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-01-09T05:29:12Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-01-10T13:17:26Z,gnzlbg,NA https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-02-06T11:50:49Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-02-06T14:49:06Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-04-21T21:19:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67878,MERGED,2020-01-04T23:51:37Z,2020-01-31T03:10:39Z,Change opt-level from 2 back to 3,Others,0d52c562db18e85cf53078c9ddb40abe469a4aab,3,Change opt-level from 2 back to 3 In Cargo.toml the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However rust no longer uses LLVM 7 so this is no longer needed. This creates a small compile time regression in MIR constant eval so I've added a #[inline(always)] on the `step` function used in const eval Also creates a binary size increase in wasm-stringify-ints-small so I've bumped the limit there.,HOORAY,2020-04-23T18:25:52Z,HarryUntyped,NA https://github.com/rust-lang/rust/pull/67882,MERGED,2020-01-05T00:48:02Z,2020-01-05T20:56:06Z,remove bespoke flock bindings,euclio,c8774302d18a1b704b797f387108c5115cd87d3a,1,remove bespoke flock bindings,HEART,2020-01-05T02:31:47Z,panaman67,NA https://github.com/rust-lang/rust/pull/67882,MERGED,2020-01-05T00:48:02Z,2020-01-05T20:56:06Z,remove bespoke flock bindings,euclio,c8774302d18a1b704b797f387108c5115cd87d3a,1,remove bespoke flock bindings,HEART,2020-01-05T11:12:57Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-05T15:27:15Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,HEART,2020-01-05T15:30:08Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,HEART,2020-01-05T20:01:14Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-11T17:36:20Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-12T00:18:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,HEART,2020-01-12T01:25:26Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-12T01:25:27Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-12T03:32:39Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-01-13T15:36:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-02-01T00:51:27Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-02-05T20:40:15Z,estebank,NA https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,THUMBS_UP,2020-02-16T18:28:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67885,MERGED,2020-01-05T02:20:50Z,2020-02-16T18:43:24Z,rustc_session: allow overriding lint level of individual lints from a group,tobithiel,3fc9253a5a27771c72429a738d5379c34e1cd924,2,rustc: add lint level cli ordering into the documentation,HOORAY,2020-03-04T02:20:17Z,branan,branan@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T04:44:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T05:42:26Z,binarybana,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T08:32:40Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T10:13:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T10:14:44Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T10:32:20Z,darksv,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T13:49:51Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T15:07:42Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-05T15:07:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T15:20:12Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T15:30:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-05T17:50:08Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-05T18:03:39Z,bb010g,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-06T07:52:13Z,comex,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-06T10:01:19Z,petertodd,pete@petertodd.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-06T11:03:32Z,lqd,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-06T11:03:32Z,lqd,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-06T14:05:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T04:12:05Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T04:55:56Z,knight42,i@zackz.dev https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T14:04:50Z,estebank,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T14:20:17Z,AZanellato,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T14:20:20Z,AZanellato,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T14:21:15Z,kooparse,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T14:21:16Z,kooparse,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T14:23:13Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T14:23:16Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T14:33:23Z,Pratyush,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T14:33:29Z,Pratyush,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T14:53:02Z,56quarters,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T15:32:26Z,roy-work,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T16:25:16Z,luser,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T16:37:32Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T16:37:34Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T17:36:27Z,sunjay,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T17:36:30Z,sunjay,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T17:44:12Z,d-dorazio,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T19:03:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T19:03:05Z,tmandry,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-08T23:24:08Z,wilbeibi,wilbeibi@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-08T23:24:12Z,wilbeibi,wilbeibi@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T00:19:43Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T00:19:44Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T00:31:09Z,grauwoelfchen,yasuhiro.asaka@grauwoelfchen.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T00:50:42Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T00:50:43Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T00:53:45Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T01:45:25Z,CAFxX,cafxx@strayorange.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T02:14:37Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T02:14:37Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T03:28:52Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T03:28:53Z,Pauan,pauanyu+github@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T05:38:09Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T06:59:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T06:59:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T07:12:48Z,tux3,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T07:41:04Z,davidcl,c.david86@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T08:13:46Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T08:22:44Z,eopb,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T08:44:23Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T09:26:31Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T09:56:40Z,kuviki,kuviki777@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T10:00:04Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T10:06:55Z,est31,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T10:06:56Z,est31,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T10:17:03Z,aleksuss,oleksandr.anyshchenko@xdev.re https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T10:17:04Z,aleksuss,oleksandr.anyshchenko@xdev.re https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T10:27:23Z,Inomares,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T10:54:23Z,hollowaysmith,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T11:06:54Z,progval,progval+github@progval.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:09:28Z,fayizk1,fayizk1@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:28:40Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:30:23Z,viriuwu,hi@viri.moe https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:31:08Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T11:34:26Z,gentoid,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:34:27Z,gentoid,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:38:12Z,edrevo,ximo.guanter@datadoghq.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T11:39:14Z,soruh,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T11:55:44Z,95th,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:02:49Z,jeremyletang,me@jeremyletang.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:02:49Z,mustafakibar,mustafa@kibar.pro https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:05:20Z,DianaNites,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:05:20Z,DianaNites,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:29:54Z,dvdplm,dvdplm@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:33:34Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:33:37Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:36:43Z,madadam,adam.ciganek@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:37:43Z,Diggsey,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:40:55Z,luukvanderduim,luukvanderduim@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T12:49:06Z,gizmondo,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T12:49:12Z,gizmondo,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T13:05:19Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T13:05:21Z,Virgiel,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T13:14:40Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T13:17:57Z,aheart,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T13:33:43Z,johndrinkwater,john@johndrinkwater.name https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T13:37:49Z,raggy-rs,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T13:37:50Z,raggy-rs,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T13:48:03Z,taheris,github@taheris.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:07:45Z,pmarino90,paolo.marino@hey.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T14:09:28Z,azdle,patrick@psbarrett.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T14:11:47Z,ordian,noreply@reusable.software https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:11:48Z,ordian,noreply@reusable.software https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:29:52Z,Defaultldentity,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:32:07Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:35:44Z,diondokter,diondokter@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T14:35:47Z,diondokter,diondokter@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:38:03Z,dralley,dalley@redhat.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T14:40:42Z,Dispersia,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:40:45Z,Dispersia,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:57:08Z,captain-yossarian,sergiybiluk@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T14:59:31Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:02:16Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:08:08Z,Scotsguy,scotsbox+github@protonmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:08:08Z,Scotsguy,scotsbox+github@protonmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:10:39Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:11:53Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:12:07Z,tech6hutch,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:12:10Z,tech6hutch,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:14:36Z,sandeep-datta,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:14:39Z,sandeep-datta,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:15:52Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:20:29Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T15:27:41Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T15:39:36Z,fin-ger,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:07:41Z,HeyZoos,jessebracho@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T16:07:42Z,HeyZoos,jessebracho@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:15:17Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:18:01Z,michael-grunder,michael.grunder@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:31:08Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:31:50Z,invokesus,souviksen44@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T16:34:11Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:34:12Z,jorendorff,jorendorff@github.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T16:35:22Z,darksv,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:51:31Z,WarmongeringBeaver,warbeaver@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T16:54:45Z,paullgdc,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T16:56:58Z,weihanglo,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T16:56:59Z,weihanglo,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:10:14Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:10:15Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:15:06Z,nicklauri,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:27:11Z,anru,box@anru.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:29:50Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:29:51Z,peterhuene,peter@huene.dev https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:31:19Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:31:19Z,mmstick,mmstick@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:34:49Z,behnam,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:34:51Z,martinrlilja,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:36:04Z,kellytk,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:40:12Z,behouba,behouba@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T17:43:48Z,leeola,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:43:50Z,leeola,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T17:48:27Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T18:11:13Z,nanaian,alex@nanaian.town https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:12:10Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T18:12:11Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:18:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T18:18:39Z,cramertj,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:20:35Z,ant1441,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:33:23Z,kerskuchen,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T18:33:25Z,kerskuchen,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:36:18Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:40:44Z,Yatekii,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:46:57Z,CPerezz,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T18:49:06Z,qrilka,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T19:15:21Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T19:18:25Z,evanrichter,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T19:18:26Z,evanrichter,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T19:31:02Z,cole-h,cole.e.helbling@outlook.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T19:31:05Z,cole-h,cole.e.helbling@outlook.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T19:40:15Z,michael-p,michael.partheil@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T19:43:47Z,binarycrusader,shawn@binarycrusader.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T20:00:32Z,TatriX,me@tatrix.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:02:38Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:06:36Z,liamdiprose,liam@liamdiprose.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:09:36Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:22:29Z,dkull,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:22:55Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T20:22:59Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T20:35:40Z,stefanobaghino,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:35:40Z,stefanobaghino,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:38:06Z,Wodann,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T20:52:21Z,alexlapa,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T20:58:54Z,lpil,louis@lpil.uk https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T21:17:12Z,cedric-h,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T21:17:13Z,cedric-h,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T21:24:00Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T21:24:01Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T21:33:05Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T22:07:45Z,minijackson,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T22:07:52Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T22:07:53Z,chrisvittal,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T22:08:46Z,NULLx76,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T22:10:21Z,robjtede,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-09T22:24:56Z,galich,sergey.galich@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T22:24:57Z,galich,sergey.galich@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T22:25:03Z,purpleposeidon,purpleposeidon@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T23:07:46Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-09T23:53:53Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T00:01:58Z,Nuc1eoN,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T00:29:55Z,tikue,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T00:30:33Z,meltinglava,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T00:30:34Z,meltinglava,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T01:07:42Z,MrAwesome,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T01:35:25Z,zuobaoquan,baoquan.zuo@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T01:38:07Z,Jonathas-Conceicao,jonathasaoc@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T01:51:31Z,APlagman,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T01:51:33Z,APlagman,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T03:02:14Z,Celeo,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T03:09:16Z,lilyball,lily@ballards.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T03:41:59Z,camelmasa,camelmasa@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T03:59:32Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T03:59:33Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T04:26:29Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T04:26:31Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T06:58:59Z,SimSmith,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T07:08:06Z,ryanpbrewster,RyanPBrewster@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T07:20:37Z,cjpearce,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T07:36:34Z,geropl,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T09:38:30Z,stulentsev-stripe,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T09:43:04Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T12:00:08Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T13:11:53Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T13:11:54Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T13:27:02Z,hug-dev,hugues.de-valon@einride.tech https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T13:56:29Z,95th,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T14:26:09Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T14:26:09Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T14:34:50Z,tsurai,github@tsunix.de https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T14:34:52Z,tsurai,github@tsunix.de https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T14:41:19Z,TimvanScherpenzeel,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T15:54:56Z,stevenroose,github@stevenroose.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T15:54:57Z,stevenroose,github@stevenroose.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T16:18:26Z,apoelstra,apoelstra@wpsoftware.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-10T16:18:28Z,apoelstra,apoelstra@wpsoftware.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-10T19:03:53Z,ylxdzsw,ylxdzsw@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-11T06:02:43Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-11T06:02:43Z,Stargateur,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-11T11:31:15Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-11T12:39:34Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-11T14:36:17Z,vallentin,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-12T02:04:24Z,onatm,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-12T02:04:25Z,onatm,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-12T04:46:33Z,raviqqe,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-12T12:16:01Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-12T17:04:58Z,NikVolf,nikvolf@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-12T18:52:57Z,mwilliammyers,mwilliammyers@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-13T11:55:19Z,skariel,skariel@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-13T11:55:21Z,skariel,skariel@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-13T17:03:04Z,ciyool,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-13T21:00:56Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-15T03:03:11Z,videah,videah@selfish.systems https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-15T03:03:12Z,videah,videah@selfish.systems https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-15T22:48:29Z,keabarnes,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T00:51:48Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-16T00:51:50Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T06:04:42Z,jk-gan,junkai@hey.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T13:57:54Z,jplatte,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T15:24:22Z,Arzte,hoffmeyer25@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-16T15:24:23Z,Arzte,hoffmeyer25@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T15:59:38Z,Catvert,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T18:54:33Z,burjui,bytefu@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T19:02:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-16T19:02:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-16T20:57:44Z,tmokenc,tmokenc@protonmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-16T20:57:47Z,tmokenc,tmokenc@protonmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-17T03:00:30Z,nikki-nn4,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-17T03:00:31Z,nikki-nn4,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-01-17T03:37:25Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-17T09:35:34Z,faern,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-17T09:35:35Z,faern,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-17T09:37:54Z,pinkisemils,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-17T09:37:55Z,pinkisemils,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-01-17T09:37:57Z,pinkisemils,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-17T13:34:14Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-17T13:55:00Z,yelite,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-19T09:47:30Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-19T09:47:32Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-01-19T09:47:34Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,EYES,2020-01-19T09:47:38Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-01-19T22:26:06Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-19T22:26:07Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-19T22:26:08Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-20T09:19:56Z,Boiethios,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-21T08:23:11Z,bpbep23,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-22T04:22:46Z,abhijithgopal,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-22T07:16:24Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-23T16:34:16Z,EarvinKayonga,earvin@earvinkayonga.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-01-23T16:34:18Z,EarvinKayonga,earvin@earvinkayonga.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-01-30T17:55:46Z,jack-fortanix,jack.lloyd@fortanix.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-02-05T20:33:42Z,lord,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-02-09T09:56:03Z,ljedrz,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-02-09T16:56:42Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-02-11T12:14:40Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-02-13T14:21:52Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-02-14T01:14:25Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-02-14T01:14:26Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,THUMBS_UP,2020-02-14T01:14:27Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,EYES,2020-02-14T01:14:29Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-02-18T13:43:23Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-02-25T20:20:02Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-03-02T20:04:53Z,jeff-hiner,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-03T23:51:37Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-03-03T23:51:38Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-04T10:50:03Z,Folyd,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-03-05T07:35:05Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-09T08:41:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-03-09T08:41:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-09T12:27:54Z,senden9,NA https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-11T15:41:19Z,russelltg,russellgreene8@gmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-12T22:10:30Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-03-12T22:59:42Z,ice1000,ice1000kotlin@foxmail.com https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HEART,2020-06-12T19:33:46Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/67887,MERGED,2020-01-05T04:33:27Z,2020-01-08T22:55:53Z,`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]`,anp,3acd34659453a92fe28308105a7b95230215e380,1,Skip caller location test in wasm32.,HOORAY,2020-10-13T16:45:22Z,joek13,joek1301@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-05T11:21:22Z,varkor,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-05T11:21:24Z,varkor,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-05T14:47:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-05T14:55:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-05T15:01:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-05T15:04:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-05T15:04:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-05T15:07:15Z,akofke,akofke@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-06T00:04:02Z,Shnatsel,shnatsel@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-06T13:30:13Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-06T19:42:34Z,darksv,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-06T19:42:37Z,darksv,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-07T09:24:46Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-09T15:14:51Z,lqd,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-09T16:54:53Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-12T08:26:03Z,alexbool,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-13T16:42:32Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-13T16:42:33Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-16T18:02:21Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-17T21:18:56Z,tema3210,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-01-23T21:38:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-01-26T09:24:37Z,jplatte,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-03-06T13:13:23Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-03-07T20:08:43Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-03-07T20:08:44Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-04-07T09:04:54Z,est31,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-04-07T09:04:55Z,est31,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HOORAY,2020-04-18T05:21:07Z,taiki-e,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-04-23T20:47:18Z,felix91gr,NA https://github.com/rust-lang/rust/pull/67890,CLOSED,2020-01-05T06:49:12Z,2020-05-07T21:39:31Z,Lazy normalization of constants,skinny121,NA,NA,NA,HEART,2020-05-07T11:41:12Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/67892,CLOSED,2020-01-05T09:50:16Z,2020-01-09T10:43:25Z,perf: Merge done_cache and active_cache in ObligationForest,Marwes,NA,NA,NA,HEART,2020-01-05T10:29:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/67900,MERGED,2020-01-05T16:01:40Z,2020-01-13T07:19:05Z,Prepare for LLVM 10 upgrade,nikic,c9e996f05cff70e69240b9a9d2d56e57af21eb3a,1,Remove support for datalayout upgrade Only keep the downgrade code,HEART,2020-01-07T10:09:34Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/67900,MERGED,2020-01-05T16:01:40Z,2020-01-13T07:19:05Z,Prepare for LLVM 10 upgrade,nikic,c9e996f05cff70e69240b9a9d2d56e57af21eb3a,1,Remove support for datalayout upgrade Only keep the downgrade code,HEART,2020-01-13T13:06:54Z,ecreeth,luismiguel1730@gmail.com https://github.com/rust-lang/rust/pull/67900,MERGED,2020-01-05T16:01:40Z,2020-01-13T07:19:05Z,Prepare for LLVM 10 upgrade,nikic,c9e996f05cff70e69240b9a9d2d56e57af21eb3a,1,Remove support for datalayout upgrade Only keep the downgrade code,HEART,2020-01-17T13:57:22Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/67913,CLOSED,2020-01-06T02:02:01Z,2020-02-10T10:51:32Z,Move numeric consts to associated consts,faern,NA,NA,NA,THUMBS_UP,2020-01-06T07:13:23Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/67913,CLOSED,2020-01-06T02:02:01Z,2020-02-10T10:51:32Z,Move numeric consts to associated consts,faern,NA,NA,NA,THUMBS_UP,2020-01-06T16:29:59Z,bstrie,NA https://github.com/rust-lang/rust/pull/67913,CLOSED,2020-01-06T02:02:01Z,2020-02-10T10:51:32Z,Move numeric consts to associated consts,faern,NA,NA,NA,THUMBS_UP,2020-01-07T02:32:21Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/67913,CLOSED,2020-01-06T02:02:01Z,2020-02-10T10:51:32Z,Move numeric consts to associated consts,faern,NA,NA,NA,THUMBS_UP,2020-01-08T01:48:57Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/67913,CLOSED,2020-01-06T02:02:01Z,2020-02-10T10:51:32Z,Move numeric consts to associated consts,faern,NA,NA,NA,HOORAY,2020-01-09T15:22:44Z,jplatte,NA https://github.com/rust-lang/rust/pull/67936,MERGED,2020-01-06T14:52:15Z,2020-01-07T08:11:12Z,"fire ""non_camel_case_types"" for associated types",euclio,a7727c59ac0b80fbbd7b3ab045260727ab64ce21,5,"fire ""non_camel_case_types"" for associated types",HEART,2020-01-06T16:17:02Z,est31,NA https://github.com/rust-lang/rust/pull/67940,MERGED,2020-01-06T15:55:31Z,2020-01-18T08:06:59Z,Update rustc-guide,JohnTitor,6421127340047130e546af9dc3afb45643cf692f,1,Update rustc-guide,THUMBS_UP,2020-01-06T21:44:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/67940,MERGED,2020-01-06T15:55:31Z,2020-01-18T08:06:59Z,Update rustc-guide,JohnTitor,6421127340047130e546af9dc3afb45643cf692f,1,Update rustc-guide,THUMBS_UP,2020-01-07T17:23:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/67951,CLOSED,2020-01-06T19:49:00Z,2020-03-07T21:50:51Z,On privacy error caused by private reexport use spans to show the `use` chain,estebank,NA,NA,NA,ROCKET,2020-01-06T20:58:12Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/67951,CLOSED,2020-01-06T19:49:00Z,2020-03-07T21:50:51Z,On privacy error caused by private reexport use spans to show the `use` chain,estebank,NA,NA,NA,HEART,2020-01-10T01:52:58Z,varkor,NA https://github.com/rust-lang/rust/pull/67951,CLOSED,2020-01-06T19:49:00Z,2020-03-07T21:50:51Z,On privacy error caused by private reexport use spans to show the `use` chain,estebank,NA,NA,NA,ROCKET,2020-01-10T03:25:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/67951,CLOSED,2020-01-06T19:49:00Z,2020-03-07T21:50:51Z,On privacy error caused by private reexport use spans to show the `use` chain,estebank,NA,NA,NA,HEART,2020-01-10T03:25:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/67953,MERGED,2020-01-06T22:39:22Z,2020-02-17T01:51:51Z,Split librustc::{traits infer} to a separate crate rustc_infer,cjgillot,e88500b5e18bbbad2323944d3c23f8a4465eb147,2,Prune rustc dependencies.,EYES,2020-01-06T22:58:55Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HOORAY,2020-01-07T07:51:19Z,mati865,NA https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HOORAY,2020-01-07T16:25:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HOORAY,2020-01-07T23:13:05Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HEART,2020-01-17T10:29:32Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HOORAY,2020-02-04T10:40:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67954,MERGED,2020-01-06T23:09:39Z,2020-02-13T01:41:35Z,Support new LLVM pass manager,nikic,c6b0803202c95abd614c8ea448f7c7ff948da31a,7,Add support for new pass manager The new pass manager can be enabled using -Z new-llvm-pass-manager=on.,HOORAY,2020-02-21T17:32:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/67956,MERGED,2020-01-07T00:00:00Z,2020-01-17T12:25:40Z,Detail transitive containment in E0588 diagnostic,varkor,3ab95ceb12b60c1564d037e8d8d6e2406fad44b3,3,Detail transitive containment in E0588 diagnostic,HEART,2020-01-17T14:23:51Z,samuela,skainsworth@gmail.com https://github.com/rust-lang/rust/pull/67966,MERGED,2020-01-07T07:39:25Z,2020-01-09T05:16:06Z,Use matches macro in libcore and libstd,popzxc,f720469fd0c4dff6d92e2f778ea2f252f76dcc2e,12,Use matches macro in libcore and libstd,HOORAY,2020-01-07T09:01:12Z,95th,NA https://github.com/rust-lang/rust/pull/67988,MERGED,2020-01-07T22:29:52Z,2020-01-09T14:49:35Z,Change -Z time event naming scheme and make them generic activities,Zoxc,7db4b7efa28ae62cfc95f34b6ffdad81f2e59b09,1,More comments,THUMBS_UP,2020-01-08T16:49:55Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/67999,CLOSED,2020-01-08T09:45:44Z,2020-02-05T10:15:58Z,Replace HIR's ItemId structs with aliases,ljedrz,NA,NA,NA,HEART,2020-01-08T15:05:27Z,panaman67,NA https://github.com/rust-lang/rust/pull/67999,CLOSED,2020-01-08T09:45:44Z,2020-02-05T10:15:58Z,Replace HIR's ItemId structs with aliases,ljedrz,NA,NA,NA,HEART,2020-01-08T22:28:56Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/67999,CLOSED,2020-01-08T09:45:44Z,2020-02-05T10:15:58Z,Replace HIR's ItemId structs with aliases,ljedrz,NA,NA,NA,HEART,2020-01-15T21:29:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-01-08T11:47:38Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-01-08T12:23:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,ROCKET,2020-01-08T22:27:35Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-01-10T01:49:45Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-01-16T22:28:53Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-01-23T09:49:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-02-25T04:24:43Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-02-28T03:34:19Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,HOORAY,2020-02-28T10:34:33Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,HOORAY,2020-03-03T16:08:15Z,bcortier-devolutions,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-03-03T16:08:15Z,bcortier-devolutions,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-03-05T06:09:18Z,kaoet,kaoet.ibe@outlook.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,ROCKET,2020-03-22T10:48:24Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,HOORAY,2020-03-28T05:37:36Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,HOORAY,2020-04-02T17:24:37Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-04-02T17:24:39Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-04-05T19:28:08Z,I60R,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-09-07T09:05:04Z,chuigda,icey@icey.tech https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,HOORAY,2020-10-29T22:05:47Z,castarco,NA https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2020-12-04T13:01:13Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2021-08-05T11:04:54Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/68004,MERGED,2020-01-08T11:44:53Z,2020-03-26T15:39:55Z,permit negative impls for non-auto traits,nikomatsakis,b0a63cb932cc94a4360219780a46fc3bcfb89e88,133,Rollup merge of #68004 - nikomatsakis:negative-impls r=varkor permit negative impls for non-auto traits This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes). Fixes https://github.com/rust-lang/rust/issues/66544 TODO: - [x] need a test that you can't rely on negative impls for coherence purposes - [x] test that negative impls cannot specialize positive ones - [x] test that positive impls cannot specialize negative ones - [x] extend negative impl to `Clone` in order to fully fix #66544 - [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015 - [x] introduce feature flag and prepare a write-up - [x] improve diagnostics?,THUMBS_UP,2022-02-11T07:50:43Z,drmingdrmer,drdr.xp@gmail.com https://github.com/rust-lang/rust/pull/68009,MERGED,2020-01-08T15:18:16Z,2020-01-09T05:15:59Z,Spell check librustc_error_codes,wcampbell0x2a,c9a55fe3db8fbdbe71852a0aa3257253c6f4777a,5,Spell check librustc_error_codes Found one wrongly spelled error message and decided to check all the error messages for wrongly spelled statements. Signed-off-by: wcampbell ,THUMBS_UP,2020-01-08T15:26:43Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/68024,MERGED,2020-01-08T19:43:08Z,2020-01-09T05:15:56Z,Remove `-Z continue-parse-after-error`,petrochenkov,41a93cba38e1813986d4068cf2d2ccfcc35ef178,36,Remove `-Z continue-parse-after-error`,HEART,2020-01-08T20:52:30Z,estebank,NA https://github.com/rust-lang/rust/pull/68024,MERGED,2020-01-08T19:43:08Z,2020-01-09T05:15:56Z,Remove `-Z continue-parse-after-error`,petrochenkov,41a93cba38e1813986d4068cf2d2ccfcc35ef178,36,Remove `-Z continue-parse-after-error`,HEART,2020-01-13T10:21:57Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/68036,MERGED,2020-01-09T01:14:23Z,2020-01-14T10:28:03Z,libterm: parse extended terminfo format,euclio,f9a57469612ba457fb7865aef944bf05d7664516,4,parse extended terminfo format,THUMBS_UP,2020-01-10T07:05:23Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/68036,MERGED,2020-01-09T01:14:23Z,2020-01-14T10:28:03Z,libterm: parse extended terminfo format,euclio,f9a57469612ba457fb7865aef944bf05d7664516,4,parse extended terminfo format,HOORAY,2020-01-14T11:25:15Z,malbarbo,NA https://github.com/rust-lang/rust/pull/68037,MERGED,2020-01-09T02:15:21Z,2020-01-18T11:37:15Z,Distribution CI for riscv64gc-unknown-linux-gnu,msizanoen1,451c97ba53412f6b1b740a5e6783da954e7c7be9,4,Distribution CI for RISC-V GNU/Linux,HOORAY,2020-01-09T10:05:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68037,MERGED,2020-01-09T02:15:21Z,2020-01-18T11:37:15Z,Distribution CI for riscv64gc-unknown-linux-gnu,msizanoen1,451c97ba53412f6b1b740a5e6783da954e7c7be9,4,Distribution CI for RISC-V GNU/Linux,THUMBS_UP,2020-01-10T03:44:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68037,MERGED,2020-01-09T02:15:21Z,2020-01-18T11:37:15Z,Distribution CI for riscv64gc-unknown-linux-gnu,msizanoen1,451c97ba53412f6b1b740a5e6783da954e7c7be9,4,Distribution CI for RISC-V GNU/Linux,HOORAY,2020-06-02T16:43:46Z,tblah,NA https://github.com/rust-lang/rust/pull/68040,MERGED,2020-01-09T02:54:51Z,2020-01-09T22:53:55Z,Cleanup,sinkuu,f443ae68c2d9bbe83e73c495572dc5d59b36e6ea,7,Remove unused dependencies,HEART,2020-01-09T05:45:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/68046,CLOSED,2020-01-09T08:17:25Z,2020-04-06T08:30:57Z,perf: Use `for_each` in `Vec::extend`,Marwes,NA,NA,NA,HEART,2020-01-09T23:23:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/68047,MERGED,2020-01-09T08:52:30Z,2020-01-09T19:21:59Z,ci: another take at fixing toolstate,pietroalbini,cdbb60e6a81800b1376752fbd99dbe8f47387266,1,ci: another take at fixing toolstate Seems like the variable showed by $(ciCheckoutPath) on Azure Pipelines was wrong making the toolstate script fail. This commit changes that function to return the variable previously used by the toolstate script. Other uses of the function were audited and there should be no conflict.,HEART,2020-01-09T08:58:38Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68074,MERGED,2020-01-09T23:56:12Z,2020-01-11T06:16:06Z,Add `llvm-skip-rebuild` flag to `x.py`,matthew-healy,7e50b599bfeb75f7be1d5a1fa855e37ec6d0e65d,1,Prefer llvm-skip-rebuild flag value over config.toml,HEART,2020-01-10T01:39:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68089,MERGED,2020-01-10T10:37:07Z,2020-01-12T05:39:43Z,Unstabilize `Vec::remove_item`,tesuji,7ba25acd7a4a119fcfdb6beb58d3958647236b30,5,"Revert ""Rollup merge of #67727 - Dylan-DPC:stabilise/remove_item r=alexcrichton"" This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1 reversing changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.",THUMBS_UP,2020-01-10T10:45:36Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/68089,MERGED,2020-01-10T10:37:07Z,2020-01-12T05:39:43Z,Unstabilize `Vec::remove_item`,tesuji,7ba25acd7a4a119fcfdb6beb58d3958647236b30,5,"Revert ""Rollup merge of #67727 - Dylan-DPC:stabilise/remove_item r=alexcrichton"" This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1 reversing changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.",THUMBS_UP,2020-01-10T15:37:08Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/68089,MERGED,2020-01-10T10:37:07Z,2020-01-12T05:39:43Z,Unstabilize `Vec::remove_item`,tesuji,7ba25acd7a4a119fcfdb6beb58d3958647236b30,5,"Revert ""Rollup merge of #67727 - Dylan-DPC:stabilise/remove_item r=alexcrichton"" This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1 reversing changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.",THUMBS_UP,2020-04-23T09:37:25Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68096,MERGED,2020-01-10T15:25:17Z,2020-01-16T10:29:49Z,Clean up some diagnostics by making them more consistent,varkor,1faa05daac8069503a0ffbba735db3b259424296,4,Update `output-default.json` and rustdoc test,THUMBS_UP,2020-01-10T22:18:13Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/68096,MERGED,2020-01-10T15:25:17Z,2020-01-16T10:29:49Z,Clean up some diagnostics by making them more consistent,varkor,1faa05daac8069503a0ffbba735db3b259424296,4,Update `output-default.json` and rustdoc test,HEART,2020-01-11T16:08:51Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-11T07:59:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-11T17:07:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-11T19:32:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-11T22:08:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-12T22:15:13Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-13T12:03:57Z,varkor,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-15T21:11:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HOORAY,2020-01-22T13:54:42Z,shssoichiro,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-01-22T18:28:20Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HOORAY,2020-01-22T18:28:22Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HOORAY,2020-01-22T22:28:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HOORAY,2020-01-23T05:29:56Z,jens1o,hello@jens-hausdorf.de https://github.com/rust-lang/rust/pull/68118,MERGED,2020-01-11T04:23:02Z,2020-01-15T04:10:40Z,perf: Eagerly convert literals to consts,skinny121,583a4fc827d1f4f491286218549a6048c0a9c9bf,1,Fix normalizing 32bit symbol hash.,HEART,2020-08-26T15:06:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68120,MERGED,2020-01-11T05:55:03Z,2020-01-11T14:46:17Z,Ban `...X` pats harden tests and improve diagnostics,Centril,883932c6baf7acd28ab712b80ddeda960f6e37da,19,Ban `...X` pats harden tests and improve diagnostics. Also fix a bug with the span passed in `mk_range`.,THUMBS_UP,2020-01-17T03:36:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68122,MERGED,2020-01-11T07:55:34Z,2020-01-27T03:02:29Z,Stabilize `#[repr(transparent)]` on `enum`s in Rust 1.42.0,Centril,25460ebef6ae94494fc89a736a2f51bef2ea55c3,2,transparent_enums: test alignment,HOORAY,2020-01-22T16:02:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/68122,MERGED,2020-01-11T07:55:34Z,2020-01-27T03:02:29Z,Stabilize `#[repr(transparent)]` on `enum`s in Rust 1.42.0,Centril,25460ebef6ae94494fc89a736a2f51bef2ea55c3,2,transparent_enums: test alignment,HOORAY,2020-01-27T00:55:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68122,MERGED,2020-01-11T07:55:34Z,2020-01-27T03:02:29Z,Stabilize `#[repr(transparent)]` on `enum`s in Rust 1.42.0,Centril,25460ebef6ae94494fc89a736a2f51bef2ea55c3,2,transparent_enums: test alignment,HOORAY,2020-02-10T15:41:37Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68123,MERGED,2020-01-11T08:57:42Z,2020-01-15T22:39:24Z,Implement Cursor for linked lists. (RFC 2570).,crlf0710,06b9a73cfa5ef1cb6fb9160d61f1beada2b81b79,2,Update APIs according to RFC change suggestions.,HOORAY,2020-01-11T15:51:35Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/68123,MERGED,2020-01-11T08:57:42Z,2020-01-15T22:39:24Z,Implement Cursor for linked lists. (RFC 2570).,crlf0710,06b9a73cfa5ef1cb6fb9160d61f1beada2b81b79,2,Update APIs according to RFC change suggestions.,HOORAY,2020-01-13T12:19:46Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/68123,MERGED,2020-01-11T08:57:42Z,2020-01-15T22:39:24Z,Implement Cursor for linked lists. (RFC 2570).,crlf0710,06b9a73cfa5ef1cb6fb9160d61f1beada2b81b79,2,Update APIs according to RFC change suggestions.,HOORAY,2020-01-22T15:47:04Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/68133,MERGED,2020-01-11T16:23:48Z,2020-02-01T21:45:42Z,Slimmer syntax,Centril,1a3141c86e9b91d4f75117075d943b72ee7dba48,1,pretty: raise recursion_limit = 256,EYES,2020-01-11T17:05:47Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/68135,MERGED,2020-01-11T19:37:27Z,2020-01-13T11:34:41Z,restore some rustc_parse visibilities for rustfmt,calebcartwright,ed039e8f8443a84dddfda8be7379ca7b4aaeccd9,2,restore some rustc_parse visibilities,THUMBS_UP,2020-01-14T10:34:15Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/68140,MERGED,2020-01-12T01:38:39Z,2020-01-21T22:13:52Z,Implement `?const` opt-out for trait bounds,ecstatic-morse,6bd69a10921785aa8ab68e58d9c7a7ea1ff6ef96,1,Add comment explaining `MaybeConstMaybe` lowering,HOORAY,2020-01-12T03:05:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68140,MERGED,2020-01-12T01:38:39Z,2020-01-21T22:13:52Z,Implement `?const` opt-out for trait bounds,ecstatic-morse,6bd69a10921785aa8ab68e58d9c7a7ea1ff6ef96,1,Add comment explaining `MaybeConstMaybe` lowering,HOORAY,2020-01-13T13:29:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68140,MERGED,2020-01-12T01:38:39Z,2020-01-21T22:13:52Z,Implement `?const` opt-out for trait bounds,ecstatic-morse,6bd69a10921785aa8ab68e58d9c7a7ea1ff6ef96,1,Add comment explaining `MaybeConstMaybe` lowering,THUMBS_UP,2020-01-31T07:12:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68141,MERGED,2020-01-12T02:00:23Z,2020-01-15T16:28:24Z,use winapi for non-stdlib Windows bindings,euclio,7b564c67deb6f5e9d7102871d63a9ad3d7161278,18,use winapi for non-stdlib Windows bindings,HOORAY,2020-01-13T10:25:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/68141,MERGED,2020-01-12T02:00:23Z,2020-01-15T16:28:24Z,use winapi for non-stdlib Windows bindings,euclio,7b564c67deb6f5e9d7102871d63a9ad3d7161278,18,use winapi for non-stdlib Windows bindings,HOORAY,2020-01-14T23:00:04Z,estebank,NA https://github.com/rust-lang/rust/pull/68143,MERGED,2020-01-12T03:02:28Z,2020-01-14T10:27:55Z,Forbid elided lifetimes within const generic parameter types,skinny121,82b90bd9938fb56452b8a10bd004ad84a0f81503,1,Update test benchmark file,HEART,2020-01-12T15:39:59Z,varkor,NA https://github.com/rust-lang/rust/pull/68143,MERGED,2020-01-12T03:02:28Z,2020-01-14T10:27:55Z,Forbid elided lifetimes within const generic parameter types,skinny121,82b90bd9938fb56452b8a10bd004ad84a0f81503,1,Update test benchmark file,HEART,2020-01-14T10:46:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/68171,CLOSED,2020-01-13T05:30:18Z,2020-04-10T18:15:27Z,Ensure all iterations in Rayon iterators run in the presence of panics,Zoxc,NA,NA,NA,THUMBS_UP,2020-03-24T03:28:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68180,MERGED,2020-01-13T13:46:27Z,2020-02-01T18:29:35Z,Add support for Control Flow Guard on Windows.,ajpaverd,c0744e1e0c35b1083733fd5c74fc3fb5a6cd04f7,8,Add support for Control Flow Guard on Windows. This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.,THUMBS_UP,2020-01-13T17:57:47Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68180,MERGED,2020-01-13T13:46:27Z,2020-02-01T18:29:35Z,Add support for Control Flow Guard on Windows.,ajpaverd,c0744e1e0c35b1083733fd5c74fc3fb5a6cd04f7,8,Add support for Control Flow Guard on Windows. This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.,THUMBS_UP,2020-01-14T00:30:06Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/68180,MERGED,2020-01-13T13:46:27Z,2020-02-01T18:29:35Z,Add support for Control Flow Guard on Windows.,ajpaverd,c0744e1e0c35b1083733fd5c74fc3fb5a6cd04f7,8,Add support for Control Flow Guard on Windows. This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.,THUMBS_UP,2020-01-14T20:17:56Z,arlosi,arsiem@microsoft.com https://github.com/rust-lang/rust/pull/68180,MERGED,2020-01-13T13:46:27Z,2020-02-01T18:29:35Z,Add support for Control Flow Guard on Windows.,ajpaverd,c0744e1e0c35b1083733fd5c74fc3fb5a6cd04f7,8,Add support for Control Flow Guard on Windows. This patch enables rustc to emit the required LLVM module flags to enable Control Flow Guard metadata (cfguard=1) or metadata and checks (cfguard=2). The LLVM module flags are ignored on unsupported targets and operating systems.,THUMBS_UP,2020-01-15T21:06:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68183,MERGED,2020-01-13T14:46:59Z,2020-01-14T00:03:03Z,Update Clippy,JohnTitor,19f8c5824f1e431a08cfdfd27b816e48c56b4857,1,Update Clippy,THUMBS_UP,2020-01-13T18:47:30Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/68191,MERGED,2020-01-13T22:10:36Z,2020-03-12T07:16:25Z,Added tvOS as targets,simlay,e5e8ba4edc435c9f87314b23a6c5d9c175bdf19c,10,Auto merge of #68191 - simlay:add-tvSO-target r=nagisa Added tvOS as targets This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs). I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell all three targets (iOS tvOS and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts? As far as the `data_layout` and other parameters to `Target` I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters. I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`). I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this? Similar to the ending of https://github.com/rust-lang/rust/pull/63467 I'm not sure what to do next.,HOORAY,2020-01-19T13:54:48Z,dreampiggy,lizhuoli1126@126.com https://github.com/rust-lang/rust/pull/68191,MERGED,2020-01-13T22:10:36Z,2020-03-12T07:16:25Z,Added tvOS as targets,simlay,e5e8ba4edc435c9f87314b23a6c5d9c175bdf19c,10,Auto merge of #68191 - simlay:add-tvSO-target r=nagisa Added tvOS as targets This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs). I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell all three targets (iOS tvOS and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts? As far as the `data_layout` and other parameters to `Target` I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters. I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`). I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this? Similar to the ending of https://github.com/rust-lang/rust/pull/63467 I'm not sure what to do next.,THUMBS_UP,2020-01-19T13:54:54Z,dreampiggy,lizhuoli1126@126.com https://github.com/rust-lang/rust/pull/68191,MERGED,2020-01-13T22:10:36Z,2020-03-12T07:16:25Z,Added tvOS as targets,simlay,e5e8ba4edc435c9f87314b23a6c5d9c175bdf19c,10,Auto merge of #68191 - simlay:add-tvSO-target r=nagisa Added tvOS as targets This is a first attempt of adding support tvOS as described in #48862. It's got a lot of overlap with [src/librustc_target/spec/apple_ios_base.rs](https://github.com/rust-lang/rust/blob/31dd4f4acbcbdb02b0745d2136399ed664a28050/src/librustc_target/spec/apple_ios_base.rs). I thought about refactoring `apple_ios_base.rs` to include this as well but that would require each of the ios and tvos targets to be of the something like the form `let base = opts(AppleOS::TV Arch::Arm64)?;` I also did the same thing for watchOS because from what I can tell all three targets (iOS tvOS and watchOS) have the same logic but have different parameters being sent to `xcrun`. Thoughts? As far as the `data_layout` and other parameters to `Target` I did as much research as I could but it really seems that processor in the [iPhone 11 is the same as the apple TV](https://en.wikipedia.org/wiki/Apple-designed_processors) so I didn't change any of those parameters. I did get this to build and tested that it's actually running the the below logic (because the parameter to `xcrun` is `appletvos` not `tvos`). I didn't manage to get it to actually compile a file with `fn main(){}` because I don't have the stdlib for `aarch64-apple-tvos` compiled it seems. Is there documentation for this? Similar to the ending of https://github.com/rust-lang/rust/pull/63467 I'm not sure what to do next.,HOORAY,2020-06-04T21:11:24Z,yerke,NA https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,THUMBS_UP,2020-01-14T05:13:32Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,HEART,2020-01-14T05:13:36Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,HEART,2020-01-14T10:18:15Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,HEART,2020-01-14T13:37:41Z,chmln,NA https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,THUMBS_UP,2020-01-14T13:37:43Z,chmln,NA https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,HEART,2020-01-15T09:25:52Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,THUMBS_UP,2020-01-20T04:57:31Z,theduke,NA https://github.com/rust-lang/rust/pull/68195,MERGED,2020-01-14T02:30:45Z,2020-01-17T12:25:28Z,Account for common `impl Trait`/`dyn Trait` return type errors,estebank,029a9c625371e756d93024efd3deb7636a90f8f8,2,review comments,HEART,2020-01-23T23:59:48Z,krdln,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T08:14:43Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HEART,2020-01-14T08:14:50Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HEART,2020-01-14T09:38:52Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T10:06:37Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T10:31:43Z,iago-lito,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HEART,2020-01-14T10:32:13Z,iago-lito,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T11:03:08Z,pitdicker,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T12:07:02Z,bluetech,ran@unusedvar.com https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-14T14:18:34Z,RustyYato,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,THUMBS_UP,2020-01-15T04:42:53Z,rhysd,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-01-15T06:01:24Z,rchaser53,tayoshizawa29@gmail.com https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,THUMBS_UP,2020-01-15T21:08:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HEART,2020-01-17T06:22:48Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,THUMBS_UP,2020-01-17T06:22:49Z,JustAPerson,jason@jpriest.me https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2020-03-15T22:31:37Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,THUMBS_UP,2020-03-15T22:31:40Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,THUMBS_UP,2021-09-03T15:43:50Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HOORAY,2021-09-03T15:43:51Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68198,CLOSED,2020-01-14T04:01:25Z,2020-04-02T10:56:46Z,Add lazy initialization primitives to std,KodrAus,NA,NA,NA,HEART,2021-09-03T15:43:52Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68204,MERGED,2020-01-14T05:53:48Z,2020-01-18T04:45:17Z,Use named fields for `{ast hir}::ItemKind::Impl`,ecstatic-morse,4743995ed3f7a60e5e0b66eb6a095483883d8c90,33,Use named fields for `hir::ItemKind::Impl`,THUMBS_UP,2020-01-18T01:28:30Z,tmandry,NA https://github.com/rust-lang/rust/pull/68212,MERGED,2020-01-14T13:26:22Z,2020-01-15T22:39:18Z,Suggest to shorten temporary lifetime during method call inside generator,csmoe,4eb47ded54610300c54291aee74d5585a711e75b,5,wrap expr id into GeneratorInteriorTypeCause,HEART,2020-01-14T23:01:17Z,estebank,NA https://github.com/rust-lang/rust/pull/68212,MERGED,2020-01-14T13:26:22Z,2020-01-15T22:39:18Z,Suggest to shorten temporary lifetime during method call inside generator,csmoe,4eb47ded54610300c54291aee74d5585a711e75b,5,wrap expr id into GeneratorInteriorTypeCause,ROCKET,2020-01-14T23:29:20Z,tmandry,NA https://github.com/rust-lang/rust/pull/68212,MERGED,2020-01-14T13:26:22Z,2020-01-15T22:39:18Z,Suggest to shorten temporary lifetime during method call inside generator,csmoe,4eb47ded54610300c54291aee74d5585a711e75b,5,wrap expr id into GeneratorInteriorTypeCause,THUMBS_UP,2020-01-15T22:08:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68223,MERGED,2020-01-14T18:08:27Z,2020-01-16T10:29:42Z,Use 3.6 instead of 3.5 in float fract() documentation,SOF3,33bc9ef513d632825ea600cfb4bb6d89f4a09269,2,Use 3.6 instead of 3.5 in float fract() documentation It is not self-explanatory whether the fract() function inverts the fractional part of negative numbers. Co-Authored-By: Mateusz Mikuła ,THUMBS_UP,2020-01-14T19:10:48Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/68223,MERGED,2020-01-14T18:08:27Z,2020-01-16T10:29:42Z,Use 3.6 instead of 3.5 in float fract() documentation,SOF3,33bc9ef513d632825ea600cfb4bb6d89f4a09269,2,Use 3.6 instead of 3.5 in float fract() documentation It is not self-explanatory whether the fract() function inverts the fractional part of negative numbers. Co-Authored-By: Mateusz Mikuła ,THUMBS_UP,2020-01-14T23:47:04Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-14T21:29:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-14T21:40:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-14T22:21:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,THUMBS_UP,2020-01-14T22:21:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,THUMBS_UP,2020-01-14T22:53:15Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-14T22:53:18Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-14T23:47:26Z,varkor,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-15T02:56:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-15T04:08:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-15T08:37:24Z,CryZe,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,THUMBS_UP,2020-01-15T09:02:06Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,ROCKET,2020-01-15T12:51:24Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,THUMBS_UP,2020-01-22T15:45:52Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-22T15:45:53Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,ROCKET,2020-01-22T15:45:56Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-22T16:52:37Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-22T16:58:24Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-22T17:56:31Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-22T18:36:36Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HOORAY,2020-01-22T19:07:25Z,twilco,tyler.wilcock@protonmail.com https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,THUMBS_UP,2020-01-23T23:02:46Z,jminer,NA https://github.com/rust-lang/rust/pull/68232,MERGED,2020-01-14T21:23:43Z,2020-01-15T22:39:16Z,Optimize size/speed of Unicode datasets,Mark-Simulacrum,efcda047397262f403df54d9f5e569dd32704168,6,Replace old tables with new unicode data,HEART,2020-01-23T23:02:46Z,jminer,NA https://github.com/rust-lang/rust/pull/68234,MERGED,2020-01-14T21:47:47Z,2020-01-28T08:44:34Z,Stabilize ptr::slice_from_raw_parts[_mut],CAD97,1c0d4851a6a686d09b03fab575fb0847d1e9f665,1,Fix incorrect slice->ptr conversion in slice_from_raw_parts docs,THUMBS_UP,2020-01-23T02:31:35Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68234,MERGED,2020-01-14T21:47:47Z,2020-01-28T08:44:34Z,Stabilize ptr::slice_from_raw_parts[_mut],CAD97,1c0d4851a6a686d09b03fab575fb0847d1e9f665,1,Fix incorrect slice->ptr conversion in slice_from_raw_parts docs,THUMBS_UP,2020-01-26T09:50:46Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-01-20T08:38:21Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-01-22T08:48:08Z,joshchngs,josh@channings.me.uk https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-01-22T15:58:19Z,teburd,thomas.burdick@intel.com https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-01-22T16:00:54Z,ro-kue,NA https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-01-22T18:32:34Z,Machine-Hum,Ryan.cjw@gmail.com https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-03-10T13:54:00Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/68253,MERGED,2020-01-15T17:10:51Z,2020-01-23T03:47:30Z,add bare metal ARM Cortex-A targets to rustc,japaric,8abbd0beae79de5186158a759b08cb73d175b5ad,2,for now do not build rust-std for the armv7a-none-eabihf target it needs some upstream changes in the build script of the compiler-builtins crate,HOORAY,2020-06-04T21:12:56Z,yerke,NA https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-16T04:55:55Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-16T05:08:45Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-20T20:57:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-21T12:46:23Z,romac,NA https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-21T13:09:57Z,greut,NA https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-01-21T15:53:25Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2020-04-22T17:07:10Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2021-03-30T18:31:50Z,rottencandy,NA https://github.com/rust-lang/rust/pull/68267,MERGED,2020-01-16T02:39:27Z,2020-01-21T10:06:41Z,Tweak lifetime definition errors,estebank,03d7fed165a350c0b9acfbbaf76feae7014c97d1,2,review comments,HEART,2021-10-27T00:29:21Z,CGMossa,NA https://github.com/rust-lang/rust/pull/68274,MERGED,2020-01-16T07:30:42Z,2020-01-16T21:00:02Z,remove dead code,matthiaskrgr,c4d91aae5a72733479bab8df1aee78bb049b9735,1,remove dead code The condition if obligation.recursion_depth >= 0 is always true since recursion_depth is usize. The else branch is dead code and can be removed. Found by Clippy. Fixes #68251,HEART,2020-01-16T15:31:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/68275,CLOSED,2020-01-16T08:09:50Z,2020-01-16T09:42:19Z,reuse `Option::map_or*` in `Option::ok_or*`,king6cong,NA,NA,NA,CONFUSED,2020-01-16T08:16:00Z,kennytm,NA https://github.com/rust-lang/rust/pull/68290,MERGED,2020-01-16T19:47:21Z,2020-01-21T03:06:38Z,Fix some tests failing in `--pass check` mode,petrochenkov,8fa8b81a7701ba8c14476d86b641d5cbe6cfa713,6,Fix some tests failing in `--pass check` mode,HEART,2020-01-16T21:28:24Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68297,MERGED,2020-01-17T00:02:01Z,2020-01-21T03:06:38Z, Filter and test predicates using `normalize_and_test_predicates` for const-prop,Aaron1011,3fef3d8b76e70da88366e45a62f98592cf9be76c,1,Add @weiznich's regression test,HEART,2020-01-19T20:48:38Z,Turbo87,NA https://github.com/rust-lang/rust/pull/68320,CLOSED,2020-01-17T20:08:32Z,2020-01-30T20:47:41Z,rustc_hir: add Expr! pattern macro and try it out in a couple places.,eddyb,NA,NA,NA,HEART,2020-01-17T22:26:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/68325,MERGED,2020-01-17T22:04:32Z,2020-01-30T11:46:26Z,Move numeric consts to associated consts step1,faern,61fecfb82fe088af6d3a7832b72f298064398aff,1,Add test accessing the module level int/float consts,HOORAY,2020-02-16T03:55:23Z,kaoet,kaoet.ibe@outlook.com https://github.com/rust-lang/rust/pull/68332,CLOSED,2020-01-18T06:26:22Z,2020-03-07T20:46:22Z,FR: impl core::ops::* for F where F: Fn {},ZaneHannanAU,NA,NA,NA,THUMBS_UP,2020-02-10T15:49:22Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68332,CLOSED,2020-01-18T06:26:22Z,2020-03-07T20:46:22Z,FR: impl core::ops::* for F where F: Fn {},ZaneHannanAU,NA,NA,NA,THUMBS_UP,2021-03-07T15:41:51Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/68334,MERGED,2020-01-18T08:22:46Z,2020-04-03T07:26:57Z,AArch64 bare-metal targets: Build rust-std,andre-richter,73f0cf69c193228211e845a921546d9c3f1d0737,3,Rollup merge of #68334 - andre-richter:master r=japaric AArch64 bare-metal targets: Build rust-std This PR complements https://github.com/rust-lang/rust/pull/68253,THUMBS_UP,2020-03-10T02:15:24Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68334,MERGED,2020-01-18T08:22:46Z,2020-04-03T07:26:57Z,AArch64 bare-metal targets: Build rust-std,andre-richter,73f0cf69c193228211e845a921546d9c3f1d0737,3,Rollup merge of #68334 - andre-richter:master r=japaric AArch64 bare-metal targets: Build rust-std This PR complements https://github.com/rust-lang/rust/pull/68253,THUMBS_UP,2020-03-25T05:09:21Z,lain-dono,NA https://github.com/rust-lang/rust/pull/68334,MERGED,2020-01-18T08:22:46Z,2020-04-03T07:26:57Z,AArch64 bare-metal targets: Build rust-std,andre-richter,73f0cf69c193228211e845a921546d9c3f1d0737,3,Rollup merge of #68334 - andre-richter:master r=japaric AArch64 bare-metal targets: Build rust-std This PR complements https://github.com/rust-lang/rust/pull/68253,THUMBS_UP,2020-04-02T20:42:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68335,MERGED,2020-01-18T08:56:08Z,2020-01-20T09:15:27Z,Remove real_drop_in_place,RalfJung,95934937bb32190c70ce48915cac14bb4609336d,2,fix real_drop_in_place in comments,THUMBS_UP,2020-01-18T16:13:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68339,MERGED,2020-01-18T12:00:11Z,2020-01-21T03:06:34Z,Add `riscv64gc-unknown-linux-gnu` into target list in build-manifest,msizanoen1,45dd44c0e130479e6532ddb0505401a41884d2bb,1,Add `riscv64gc-unknown-linux-gnu` into target list in build-manifest Missed in #68037 r? @alexcrichton,HOORAY,2020-03-12T12:21:52Z,jethrogb,NA https://github.com/rust-lang/rust/pull/68342,MERGED,2020-01-18T13:46:11Z,2020-01-18T22:08:40Z,improve type_name_of_val docs,lcnr,6b7f3e50df3b4235756df9354ea90cf821460a8b,1,improve type_name_of_val docs,THUMBS_UP,2020-01-18T16:32:55Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/68353,MERGED,2020-01-18T21:05:20Z,2020-01-20T09:15:25Z,Remove `rustc_error_codes` deps except in `rustc_driver`,Centril,de6046fa0ff6e57afa50174c001d1668ee7f3cf6,109,remove rustc_error_codes deps except in rustc_driver,HOORAY,2020-01-19T00:45:39Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68353,MERGED,2020-01-18T21:05:20Z,2020-01-20T09:15:25Z,Remove `rustc_error_codes` deps except in `rustc_driver`,Centril,de6046fa0ff6e57afa50174c001d1668ee7f3cf6,109,remove rustc_error_codes deps except in rustc_driver,HOORAY,2020-01-19T17:59:39Z,mati865,NA https://github.com/rust-lang/rust/pull/68353,MERGED,2020-01-18T21:05:20Z,2020-01-20T09:15:25Z,Remove `rustc_error_codes` deps except in `rustc_driver`,Centril,de6046fa0ff6e57afa50174c001d1668ee7f3cf6,109,remove rustc_error_codes deps except in rustc_driver,HOORAY,2020-01-19T22:38:35Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68356,CLOSED,2020-01-18T23:14:52Z,2020-01-22T06:38:29Z,Disallow generic type parameters from appearing within certain constants,skinny121,NA,NA,NA,HEART,2020-01-18T23:18:52Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68376,MERGED,2020-01-19T23:24:42Z,2020-02-09T07:12:27Z,Initial implementation of `#![feature(move_ref_pattern)]`,Centril,d2b88b7050b0e21b136022c4cfe8d352c1425588,2,move_ref_pattern: test captures inside closure,HOORAY,2020-02-23T14:41:46Z,a-rodin,rodin.alexander@gmail.com https://github.com/rust-lang/rust/pull/68377,MERGED,2020-01-20T01:29:44Z,2020-02-04T20:31:17Z,Tweak obligation error output,estebank,0e584114c6153a3d7ff94349729c46a4735cb838,6,Change wording for object unsafe because of assoc const,HOORAY,2020-02-04T20:37:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68377,MERGED,2020-01-20T01:29:44Z,2020-02-04T20:31:17Z,Tweak obligation error output,estebank,0e584114c6153a3d7ff94349729c46a4735cb838,6,Change wording for object unsafe because of assoc const,HEART,2020-02-05T11:40:32Z,jplatte,NA https://github.com/rust-lang/rust/pull/68388,MERGED,2020-01-20T15:22:34Z,2020-01-23T03:47:21Z,Make `TooGeneric` error in WF checking a proper error,varkor,dd0507c054ea27ae836025761908d339a478e0ab,3,Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases the burden of proof should be with the caller so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error rather than silently ignoring it or ICEing.,HEART,2020-01-20T15:24:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68388,MERGED,2020-01-20T15:22:34Z,2020-01-23T03:47:21Z,Make `TooGeneric` error in WF checking a proper error,varkor,dd0507c054ea27ae836025761908d339a478e0ab,3,Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases the burden of proof should be with the caller so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error rather than silently ignoring it or ICEing.,HEART,2020-01-22T07:38:02Z,skinny121,benjamin.lewis@seequent.com https://github.com/rust-lang/rust/pull/68391,MERGED,2020-01-20T16:09:55Z,2020-01-23T22:54:01Z,compiletest: Simplify multi-debugger support,tmiasko,5c384ab00c7b4b39e457b75d385e9cbe12e699f5,1,compiletest: Do not run debuginfo tests with gdb on msvc targets,HEART,2020-01-20T19:21:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-20T20:33:48Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-20T20:36:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-20T21:58:53Z,mati865,NA https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-20T22:09:08Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-20T23:52:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68402,CLOSED,2020-01-20T20:28:14Z,2020-01-26T22:06:34Z,Enable inserting sideeffect by default,Mark-Simulacrum,NA,NA,NA,HEART,2020-01-21T02:11:05Z,Lokathor,NA https://github.com/rust-lang/rust/pull/68404,MERGED,2020-01-20T22:16:19Z,2020-03-27T06:32:36Z,Rename asm! to llvm_asm!,Amanieu,6c19a10e24af157b96687ca8dc1b48ebac4b9489,136,Auto merge of #68404 - Amanieu:llvm-asm r=estebank Rename asm! to llvm_asm! As per https://github.com/rust-lang/rfcs/pull/2843 this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850. This PR doesn't actually deprecate `asm!` yet it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.,HEART,2020-01-20T23:51:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68404,MERGED,2020-01-20T22:16:19Z,2020-03-27T06:32:36Z,Rename asm! to llvm_asm!,Amanieu,6c19a10e24af157b96687ca8dc1b48ebac4b9489,136,Auto merge of #68404 - Amanieu:llvm-asm r=estebank Rename asm! to llvm_asm! As per https://github.com/rust-lang/rfcs/pull/2843 this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850. This PR doesn't actually deprecate `asm!` yet it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.,HEART,2020-01-21T03:40:04Z,estebank,NA https://github.com/rust-lang/rust/pull/68404,MERGED,2020-01-20T22:16:19Z,2020-03-27T06:32:36Z,Rename asm! to llvm_asm!,Amanieu,6c19a10e24af157b96687ca8dc1b48ebac4b9489,136,Auto merge of #68404 - Amanieu:llvm-asm r=estebank Rename asm! to llvm_asm! As per https://github.com/rust-lang/rfcs/pull/2843 this PR renames `asm!` to `llvm_asm!`. It also renames the compiler's internal `InlineAsm` data structures to `LlvmInlineAsm` in preparation for the new `asm!` functionality specified in https://github.com/rust-lang/rfcs/pull/2850. This PR doesn't actually deprecate `asm!` yet it just makes it redirect to `llvm_asm!`. This is necessary because we first need to update the submodules (in particular stdarch) to use `llvm_asm!`.,HEART,2020-01-23T18:49:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/68406,MERGED,2020-01-20T22:40:25Z,2020-02-13T22:21:35Z,[self-profiler] add selfprofiling to llvm,andjo403,cec0ed0219c4e4961b9e7a33419d716a5ddf0e5d,10,add selfprofiling for new llvm passmanager,HEART,2020-01-21T14:00:22Z,mati865,NA https://github.com/rust-lang/rust/pull/68406,MERGED,2020-01-20T22:40:25Z,2020-02-13T22:21:35Z,[self-profiler] add selfprofiling to llvm,andjo403,cec0ed0219c4e4961b9e7a33419d716a5ddf0e5d,10,add selfprofiling for new llvm passmanager,HEART,2020-01-21T19:43:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68406,MERGED,2020-01-20T22:40:25Z,2020-02-13T22:21:35Z,[self-profiler] add selfprofiling to llvm,andjo403,cec0ed0219c4e4961b9e7a33419d716a5ddf0e5d,10,add selfprofiling for new llvm passmanager,HEART,2020-01-22T11:19:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/68406,MERGED,2020-01-20T22:40:25Z,2020-02-13T22:21:35Z,[self-profiler] add selfprofiling to llvm,andjo403,cec0ed0219c4e4961b9e7a33419d716a5ddf0e5d,10,add selfprofiling for new llvm passmanager,HEART,2020-02-13T17:57:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68406,MERGED,2020-01-20T22:40:25Z,2020-02-13T22:21:35Z,[self-profiler] add selfprofiling to llvm,andjo403,cec0ed0219c4e4961b9e7a33419d716a5ddf0e5d,10,add selfprofiling for new llvm passmanager,HEART,2020-02-14T01:08:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/68409,MERGED,2020-01-21T06:33:34Z,2020-01-23T03:47:18Z,Micro-optimize OutputFilenames,sinkuu,dc97181a0966cd1686a70ce06849a19c196f72eb,1,Do not base path to append extension We already have ownership of the base path so no need to clone it (within Path::with_extension).,ROCKET,2020-01-21T13:59:54Z,mati865,NA https://github.com/rust-lang/rust/pull/68409,MERGED,2020-01-21T06:33:34Z,2020-01-23T03:47:18Z,Micro-optimize OutputFilenames,sinkuu,dc97181a0966cd1686a70ce06849a19c196f72eb,1,Do not base path to append extension We already have ownership of the base path so no need to clone it (within Path::with_extension).,HEART,2020-01-21T18:58:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/68409,MERGED,2020-01-21T06:33:34Z,2020-01-23T03:47:18Z,Micro-optimize OutputFilenames,sinkuu,dc97181a0966cd1686a70ce06849a19c196f72eb,1,Do not base path to append extension We already have ownership of the base path so no need to clone it (within Path::with_extension).,HEART,2020-01-30T12:36:26Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68409,MERGED,2020-01-21T06:33:34Z,2020-01-23T03:47:18Z,Micro-optimize OutputFilenames,sinkuu,dc97181a0966cd1686a70ce06849a19c196f72eb,1,Do not base path to append extension We already have ownership of the base path so no need to clone it (within Path::with_extension).,ROCKET,2020-01-30T12:36:27Z,Virgiel,NA https://github.com/rust-lang/rust/pull/68413,MERGED,2020-01-21T13:05:23Z,2020-02-07T20:46:19Z,Add GitHub issue templates,XAMPPRocky,49d78fcd901700c5a14e19a6679db1646b5ca901,5,Add GitHub issue templates,HEART,2020-01-21T14:09:14Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68413,MERGED,2020-01-21T13:05:23Z,2020-02-07T20:46:19Z,Add GitHub issue templates,XAMPPRocky,49d78fcd901700c5a14e19a6679db1646b5ca901,5,Add GitHub issue templates,HEART,2020-01-23T14:02:44Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/68413,MERGED,2020-01-21T13:05:23Z,2020-02-07T20:46:19Z,Add GitHub issue templates,XAMPPRocky,49d78fcd901700c5a14e19a6679db1646b5ca901,5,Add GitHub issue templates,HEART,2020-01-24T17:08:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/68413,MERGED,2020-01-21T13:05:23Z,2020-02-07T20:46:19Z,Add GitHub issue templates,XAMPPRocky,49d78fcd901700c5a14e19a6679db1646b5ca901,5,Add GitHub issue templates,HEART,2020-02-07T16:37:23Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/68415,MERGED,2020-01-21T14:34:31Z,2020-01-21T22:13:31Z,tidy: fix most clippy warnings,matthiaskrgr,14c002edb6a2e336dca09dca96df2b7228db95a8,5,tidy: fix most clippy warnings,HEART,2020-01-21T18:56:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/68422,MERGED,2020-01-21T18:32:09Z,2020-01-22T04:22:16Z,typeck: simplify the handling of `diverges`,Centril,7dceff9b5b2e41855ff3ba2fab3a2ae41e965df5,1,typeck: remove redundant diverges check,HEART,2020-01-21T18:53:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/68424,MERGED,2020-01-21T19:11:24Z,2020-01-24T11:57:36Z,Suggest borrowing `Vec` in for loop,estebank,6eaf59dfc8be4ee5647f9c090c5a7668682f30c0,4,use `diagnostic_item` and modify wording,HOORAY,2020-01-24T03:28:09Z,tmandry,NA https://github.com/rust-lang/rust/pull/68447,MERGED,2020-01-22T07:02:01Z,2020-01-27T06:21:41Z,Suggest defining type parameter when appropriate,estebank,697fdc568e28fbb376567eda4edb2c2a05db68de,12,Suggest defining type parameter when appropriate ``` error[E0412]: cannot find type `T` in this scope --> file.rs:3:12 | 3 | impl Trait for Struct {} | - ^ not found in this scope | | | help: you might be missing a type parameter: `` ``` Fix #64298.,THUMBS_UP,2020-01-27T00:55:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68447,MERGED,2020-01-22T07:02:01Z,2020-01-27T06:21:41Z,Suggest defining type parameter when appropriate,estebank,697fdc568e28fbb376567eda4edb2c2a05db68de,12,Suggest defining type parameter when appropriate ``` error[E0412]: cannot find type `T` in this scope --> file.rs:3:12 | 3 | impl Trait for Struct {} | - ^ not found in this scope | | | help: you might be missing a type parameter: `` ``` Fix #64298.,THUMBS_UP,2020-01-27T10:28:57Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68447,MERGED,2020-01-22T07:02:01Z,2020-01-27T06:21:41Z,Suggest defining type parameter when appropriate,estebank,697fdc568e28fbb376567eda4edb2c2a05db68de,12,Suggest defining type parameter when appropriate ``` error[E0412]: cannot find type `T` in this scope --> file.rs:3:12 | 3 | impl Trait for Struct {} | - ^ not found in this scope | | | help: you might be missing a type parameter: `` ``` Fix #64298.,THUMBS_UP,2020-02-06T22:13:01Z,lnicola,NA https://github.com/rust-lang/rust/pull/68447,MERGED,2020-01-22T07:02:01Z,2020-01-27T06:21:41Z,Suggest defining type parameter when appropriate,estebank,697fdc568e28fbb376567eda4edb2c2a05db68de,12,Suggest defining type parameter when appropriate ``` error[E0412]: cannot find type `T` in this scope --> file.rs:3:12 | 3 | impl Trait for Struct {} | - ^ not found in this scope | | | help: you might be missing a type parameter: `` ``` Fix #64298.,HEART,2020-02-08T15:42:08Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/68459,MERGED,2020-01-22T15:32:34Z,2020-01-28T02:17:17Z,don't clone types that are copy round two.,matthiaskrgr,f7dcdcc0b96d4906288dadc459692ef80fd872a9,1,make matches exhaustive,HEART,2020-01-22T16:26:56Z,panaman67,NA https://github.com/rust-lang/rust/pull/68459,MERGED,2020-01-22T15:32:34Z,2020-01-28T02:17:17Z,don't clone types that are copy round two.,matthiaskrgr,f7dcdcc0b96d4906288dadc459692ef80fd872a9,1,make matches exhaustive,HEART,2020-01-24T01:12:49Z,estebank,NA https://github.com/rust-lang/rust/pull/68461,MERGED,2020-01-22T15:49:37Z,2020-02-06T01:47:15Z,Move datatypes definitions in specific modules inside rustc::{traits infer},cjgillot,735d664e7401de8f272cf26f404d1f0a44db5471,2,Move EvaluationCache::clear.,HEART,2020-01-22T20:45:48Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68472,CLOSED,2020-01-22T22:15:32Z,2020-02-23T17:45:16Z,perf: Let &mut T iterators forward for_each and friends,Marwes,NA,NA,NA,HEART,2020-01-26T12:57:29Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/68475,MERGED,2020-01-23T00:29:08Z,2020-02-15T02:24:39Z,Use a `ParamEnvAnd` for caching in `ObligationForest`,Aaron1011,90afc0765e5e536af6307b63e1655a38df06e235,4,Use a `ParamEnvAnd` for caching in `ObligationForest` Previously we used a plain `Predicate` to cache results (e.g. successes and failures) in ObligationForest. However fulfillment depends on the precise `ParamEnv` used so this is unsound in general. This commit changes the impl of `ForestObligation` for `PendingPredicateObligation` to use `ParamEnvAnd` instead of `Predicate` for the associated type. The associated type and method are renamed from 'predicate' to 'cache_key' to reflect the fact that type is no longer just a predicate.,HEART,2020-02-14T19:12:52Z,panaman67,NA https://github.com/rust-lang/rust/pull/68481,CLOSED,2020-01-23T12:10:23Z,2020-01-28T02:25:20Z,Improve nop-match simplification,sinkuu,NA,NA,NA,HOORAY,2020-01-23T12:31:06Z,mati865,NA https://github.com/rust-lang/rust/pull/68487,MERGED,2020-01-23T14:13:31Z,2020-02-12T13:17:55Z,[experiment] Support linking from a .rlink file,0dvictor,a47fdb99c04fc9119247c6511033e30735490804,7,Support linking from a .rlink file Flag `-Z no-link` was previously introduced which allows creating an `.rlink` file to perform compilation without linking. This change enables linking from an `.rlink` file.,HOORAY,2020-01-24T00:47:21Z,tmandry,NA https://github.com/rust-lang/rust/pull/68487,MERGED,2020-01-23T14:13:31Z,2020-02-12T13:17:55Z,[experiment] Support linking from a .rlink file,0dvictor,a47fdb99c04fc9119247c6511033e30735490804,7,Support linking from a .rlink file Flag `-Z no-link` was previously introduced which allows creating an `.rlink` file to perform compilation without linking. This change enables linking from an `.rlink` file.,HOORAY,2020-01-25T21:21:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68491,MERGED,2020-01-23T20:09:29Z,2020-02-11T23:56:41Z,Hide niches under UnsafeCell,pnkfelix,1b12232b8f6ede69485d4fd48f1ac8044d5d7c7c,2,Fix SGX RWLock representation for UnsafeCell niche fix,HEART,2020-01-24T05:54:14Z,pitdicker,NA https://github.com/rust-lang/rust/pull/68491,MERGED,2020-01-23T20:09:29Z,2020-02-11T23:56:41Z,Hide niches under UnsafeCell,pnkfelix,1b12232b8f6ede69485d4fd48f1ac8044d5d7c7c,2,Fix SGX RWLock representation for UnsafeCell niche fix,HEART,2020-01-24T17:42:39Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/68491,MERGED,2020-01-23T20:09:29Z,2020-02-11T23:56:41Z,Hide niches under UnsafeCell,pnkfelix,1b12232b8f6ede69485d4fd48f1ac8044d5d7c7c,2,Fix SGX RWLock representation for UnsafeCell niche fix,HEART,2020-01-30T00:10:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68493,CLOSED,2020-01-23T20:42:15Z,2020-01-24T18:46:07Z,[WIP] Don't drop an enum after all its fields have been moved from,ecstatic-morse,NA,NA,NA,HEART,2020-01-23T20:45:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68493,CLOSED,2020-01-23T20:42:15Z,2020-01-24T18:46:07Z,[WIP] Don't drop an enum after all its fields have been moved from,ecstatic-morse,NA,NA,NA,HEART,2020-01-23T20:47:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68493,CLOSED,2020-01-23T20:42:15Z,2020-01-24T18:46:07Z,[WIP] Don't drop an enum after all its fields have been moved from,ecstatic-morse,NA,NA,NA,HEART,2020-01-23T22:58:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/68501,CLOSED,2020-01-24T01:55:26Z,2020-03-10T00:41:33Z,Minimum lint levels for C-future-compatibility issues: take two,Aaron1011,NA,NA,NA,HEART,2020-01-24T05:19:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68505,MERGED,2020-01-24T07:14:53Z,2020-02-28T09:33:10Z,Canonicalize inputs to const eval where needed,skinny121,bfc32dd106f0fe191b8bcd9b76348a8875c30a60,8,Auto merge of #68505 - skinny121:canonicalize-const-eval-inputs r=nikomatsakis Canonicalize inputs to const eval where needed Canonicalize inputs to const eval so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it which can occur during trait selection. This is a reattempt of #67717 in a far less invasive way. Fixes #68477 r? @nikomatsakis cc @eddyb,HEART,2020-01-25T00:55:04Z,varkor,NA https://github.com/rust-lang/rust/pull/68505,MERGED,2020-01-24T07:14:53Z,2020-02-28T09:33:10Z,Canonicalize inputs to const eval where needed,skinny121,bfc32dd106f0fe191b8bcd9b76348a8875c30a60,8,Auto merge of #68505 - skinny121:canonicalize-const-eval-inputs r=nikomatsakis Canonicalize inputs to const eval where needed Canonicalize inputs to const eval so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it which can occur during trait selection. This is a reattempt of #67717 in a far less invasive way. Fixes #68477 r? @nikomatsakis cc @eddyb,HEART,2020-01-25T04:26:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68505,MERGED,2020-01-24T07:14:53Z,2020-02-28T09:33:10Z,Canonicalize inputs to const eval where needed,skinny121,bfc32dd106f0fe191b8bcd9b76348a8875c30a60,8,Auto merge of #68505 - skinny121:canonicalize-const-eval-inputs r=nikomatsakis Canonicalize inputs to const eval where needed Canonicalize inputs to const eval so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it which can occur during trait selection. This is a reattempt of #67717 in a far less invasive way. Fixes #68477 r? @nikomatsakis cc @eddyb,HEART,2020-01-26T13:49:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68511,MERGED,2020-01-24T15:29:07Z,2020-01-25T02:15:43Z,Remove unused ignore-license directives,tmiasko,2fd6c4a18a475a0474c035283e2c01480cbbc6fd,28,Remove unused ignore-license directives The tidy check was removed in rust-lang/rust#53617,HEART,2020-01-24T17:14:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/68522,MERGED,2020-01-24T19:23:31Z,2020-01-26T11:48:42Z,Further improve `impl Trait`/`dyn Trait` suggestions,estebank,16709f032cfaa0b37a83bc798f0dd4a30d2b2c0c,3,Revert suggestion window size change,THUMBS_UP,2020-01-25T13:38:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/68522,MERGED,2020-01-24T19:23:31Z,2020-01-26T11:48:42Z,Further improve `impl Trait`/`dyn Trait` suggestions,estebank,16709f032cfaa0b37a83bc798f0dd4a30d2b2c0c,3,Revert suggestion window size change,THUMBS_UP,2020-01-31T00:31:50Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/68522,MERGED,2020-01-24T19:23:31Z,2020-01-26T11:48:42Z,Further improve `impl Trait`/`dyn Trait` suggestions,estebank,16709f032cfaa0b37a83bc798f0dd4a30d2b2c0c,3,Revert suggestion window size change,THUMBS_UP,2020-01-31T03:30:29Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68522,MERGED,2020-01-24T19:23:31Z,2020-01-26T11:48:42Z,Further improve `impl Trait`/`dyn Trait` suggestions,estebank,16709f032cfaa0b37a83bc798f0dd4a30d2b2c0c,3,Revert suggestion window size change,THUMBS_UP,2020-01-31T09:09:28Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T21:56:33Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T22:03:54Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T22:11:10Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T22:23:29Z,cynecx,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T22:35:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T22:39:47Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-24T22:39:49Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-24T22:43:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-24T22:56:03Z,lilymara-onesignal,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-24T23:00:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-24T23:00:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-24T23:00:29Z,cramertj,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-24T23:18:57Z,rpjohnst,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-25T00:48:30Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-25T00:48:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-25T00:48:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-25T01:21:36Z,CryZe,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-25T01:21:37Z,CryZe,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-25T01:23:23Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-25T01:23:24Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-25T09:39:35Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-25T10:06:11Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-25T18:30:29Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-25T18:54:24Z,kpp,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-25T18:54:26Z,kpp,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-26T03:47:10Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-26T15:40:15Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-26T15:40:15Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-26T15:40:16Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-27T08:03:03Z,olegnn,olegnosov1@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-27T10:11:07Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-27T12:59:46Z,chpio,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-27T14:37:24Z,lqd,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-27T18:36:00Z,tmandry,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-27T18:36:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-27T18:36:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-27T19:58:53Z,lqd,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-01-27T23:19:33Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-01-28T08:45:02Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-01-28T09:06:52Z,sinkuu,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-01T02:16:26Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-01T07:43:36Z,denzp,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-07T06:59:15Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-07T06:59:17Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-07T16:24:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-07T16:56:09Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-07T18:46:34Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-07T19:20:37Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-07T19:29:08Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-08T03:37:40Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-08T08:42:45Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-08T08:42:47Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-08T08:43:02Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-08T09:14:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-08T09:14:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-08T09:14:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-08T20:10:27Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-08T20:10:28Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-10T12:21:37Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-12T08:47:23Z,bb010g,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-12T09:58:51Z,semtexzv,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-02-13T14:39:46Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-13T14:39:56Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-13T15:10:25Z,95th,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-13T16:20:41Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-13T18:42:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-02-13T23:12:11Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-02-15T11:36:26Z,jsdw,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-03-22T00:55:55Z,amadeusine,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-03-31T00:31:34Z,ahirner,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-04-06T10:02:58Z,jeswin,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-04-06T10:03:00Z,jeswin,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-04-06T10:03:02Z,jeswin,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-05-04T12:21:37Z,leinlawun,leinlawun@leinlawun.org https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-05-04T12:21:49Z,leinlawun,leinlawun@leinlawun.org https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-05-05T21:37:51Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2020-05-05T23:09:26Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,HEART,2020-05-05T23:09:27Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-05-05T23:09:30Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-06-05T11:06:19Z,iwa13,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,ROCKET,2020-07-07T23:15:41Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/68524,MERGED,2020-01-24T21:43:13Z,2020-02-07T03:09:52Z,Generator Resume Arguments,jonas-schievink,9d7b214ac6cb50a1b5454e0ae904a6479b54261c,1,Ignore panic-drops-resume.rs on wasm/emscripten It does not have unwinding support,THUMBS_UP,2022-03-30T00:07:02Z,chloekek,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-01-30T06:02:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-08T07:30:11Z,pitdicker,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-10T02:30:24Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-18T14:21:16Z,jplatte,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-21T07:31:23Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-26T20:24:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-28T10:40:58Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-02-28T14:57:22Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-05T19:49:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-05T21:42:15Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-05T21:59:00Z,yerke,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-06T00:03:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-06T00:09:15Z,krdln,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-06T03:45:24Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-06T18:03:55Z,Emerentius,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-07T08:43:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-08T14:13:00Z,Boscop,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-03-28T09:39:34Z,marmeladema,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-04-27T07:37:44Z,iago-lito,NA https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-05-24T04:07:15Z,khoek,keeley@hoek.io https://github.com/rust-lang/rust/pull/68528,MERGED,2020-01-25T00:28:52Z,2020-02-27T18:39:04Z,Mark other variants as uninitialized after switch on discriminant,ecstatic-morse,49c68bd53f90e375bfb3cbba8c1c67a9e0adb9c0,8,Auto merge of #68528 - ecstatic-morse:maybe-init-variants r=oli-obk Mark other variants as uninitialized after switch on discriminant During drop elaboration which builds the drop ladder that handles destruction during stack unwinding we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM which should improve performance. In #66753 a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap` which move out of an `enum`. While discussing possible remedies for that issue @eddyb suggested moving const-checking after drop elaboration. This would allow the former which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out leverage the work done by the latter. However it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example let's look at the code for `unwrap_or`. ```rust fn unwrap_or(opt: Option default: T) -> T { match opt { Some(inner) => inner None => default } } ``` `opt` never needs to be dropped since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`) and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen. ![pasted_image](https://user-images.githubusercontent.com/29463364/73384403-109a0d80-4280-11ea-8500-0637b368f2dc.png) @eddyb also suggested the solution to this problem. When we switch on an enum discriminant we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`. ![after](https://user-images.githubusercontent.com/29463364/73384823-e432c100-4280-11ea-84bd-d0bcc3b777b4.png) In concert with #68943 this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.,HOORAY,2020-05-31T11:06:44Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/68531,MERGED,2020-01-25T02:44:01Z,2020-01-27T15:15:33Z,[self-profiler] Two small cleanups,wesleywiser,2acf5a30bac39d6fd326b0d82b047b9e59b64692,1,[self-profiler] Clean up `EventFilter`,HEART,2020-01-25T03:42:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/68544,MERGED,2020-01-25T20:35:35Z,2020-02-05T03:21:01Z,Remove the `overlapping_marker_traits` feature,Aaron1011,302f8c97ea92d010f39a19563e8881a704c6f136,15,Remove the `overlapping_marker_traits` feature See #29864 This has been replaced by `#[feature(marker_trait_attr)]` A few notes: * Due to PR #68057 not yet being in the bootstrap compiler it's necessary to continue using `#![feature(overlapping_marker_traits)]` under `#[cfg(bootstrap)]` to work around type inference issues. * I've updated tests that used `overlapping_marker_traits` to now use `marker_trait_attr` where applicable The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense now that `overlapping_marker_traits` so I removed it. The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs` now fails since it's no longer possible to have multiple overlapping negative impls of `Send`. I believe that this is the behavior we want (assuming that `Send` is not going to become a `#[marker]` trait so I renamed the test to `overlap-permitted-for-marker-traits-neg`,HEART,2020-01-27T12:05:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68544,MERGED,2020-01-25T20:35:35Z,2020-02-05T03:21:01Z,Remove the `overlapping_marker_traits` feature,Aaron1011,302f8c97ea92d010f39a19563e8881a704c6f136,15,Remove the `overlapping_marker_traits` feature See #29864 This has been replaced by `#[feature(marker_trait_attr)]` A few notes: * Due to PR #68057 not yet being in the bootstrap compiler it's necessary to continue using `#![feature(overlapping_marker_traits)]` under `#[cfg(bootstrap)]` to work around type inference issues. * I've updated tests that used `overlapping_marker_traits` to now use `marker_trait_attr` where applicable The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense now that `overlapping_marker_traits` so I removed it. The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs` now fails since it's no longer possible to have multiple overlapping negative impls of `Send`. I believe that this is the behavior we want (assuming that `Send` is not going to become a `#[marker]` trait so I renamed the test to `overlap-permitted-for-marker-traits-neg`,HEART,2020-02-05T13:52:43Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68544,MERGED,2020-01-25T20:35:35Z,2020-02-05T03:21:01Z,Remove the `overlapping_marker_traits` feature,Aaron1011,302f8c97ea92d010f39a19563e8881a704c6f136,15,Remove the `overlapping_marker_traits` feature See #29864 This has been replaced by `#[feature(marker_trait_attr)]` A few notes: * Due to PR #68057 not yet being in the bootstrap compiler it's necessary to continue using `#![feature(overlapping_marker_traits)]` under `#[cfg(bootstrap)]` to work around type inference issues. * I've updated tests that used `overlapping_marker_traits` to now use `marker_trait_attr` where applicable The test `src/test/ui/overlap-marker-trait.rs` doesn't make any sense now that `overlapping_marker_traits` so I removed it. The test `src/test/ui/traits/overlap-permitted-for-marker-traits-neg.rs` now fails since it's no longer possible to have multiple overlapping negative impls of `Send`. I believe that this is the behavior we want (assuming that `Send` is not going to become a `#[marker]` trait so I renamed the test to `overlap-permitted-for-marker-traits-neg`,HEART,2020-08-19T01:03:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/68545,MERGED,2020-01-25T21:26:59Z,2020-01-26T15:11:28Z,Use better bound names in `-Zverbose` mode,estebank,3fb18104761fe5b6a8a70435ccff54c65400f360,10,Use better bound names in `-Zverbose` mode,THUMBS_UP,2020-01-26T00:05:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/68553,MERGED,2020-01-26T16:25:18Z,2020-01-29T04:37:06Z,Fix run button positionning in case of scrolling,GuillaumeGomez,85079f8b1fa8291593735b9b577e8e0dc22ad3b6,2,Fix run button positionning in case of scrolling,HEART,2020-01-27T03:43:26Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68556,MERGED,2020-01-26T21:46:58Z,2020-01-29T04:37:05Z,rustdoc: Fix re-exporting primitive types,ollie27,bbc2ae7590ad53fca02fda187e7f9c2470c9e949,6,rustdoc: Fix re-exporting primitive types * Generate links to the primitive type docs for re-exports. * Don't ICE on cross crate primitive type re-exports. * Make primitive type re-exports show up cross crate.,HEART,2020-01-26T21:54:12Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/68568,MERGED,2020-01-27T12:08:43Z,2020-01-27T18:33:39Z,[stable] Rust 1.41.0 stable release,pietroalbini,4600d3c594a6ea68aaa944386d14f0c20179861e,1,1.41.0 stable release,HOORAY,2020-01-27T15:50:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68577,CLOSED,2020-01-27T18:23:03Z,2020-04-07T08:27:52Z,[WIP] [let_chains 4/N] Introduce `hir::ExprKind::Let`,Centril,NA,NA,NA,ROCKET,2020-01-27T18:48:39Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/68577,CLOSED,2020-01-27T18:23:03Z,2020-04-07T08:27:52Z,[WIP] [let_chains 4/N] Introduce `hir::ExprKind::Let`,Centril,NA,NA,NA,ROCKET,2020-01-27T19:17:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68577,CLOSED,2020-01-27T18:23:03Z,2020-04-07T08:27:52Z,[WIP] [let_chains 4/N] Introduce `hir::ExprKind::Let`,Centril,NA,NA,NA,ROCKET,2020-01-28T13:14:56Z,CryZe,NA https://github.com/rust-lang/rust/pull/68588,MERGED,2020-01-28T02:26:00Z,2020-01-31T06:33:46Z,check_unsafety: more code reuse,Centril,dc17f38e041e6bde95c6f6c5c6170dbb3917d51e,1,check_unsafety: more code reuse,HEART,2020-01-28T05:06:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-01-28T18:03:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-01-29T01:45:42Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-02-05T20:59:16Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-02-05T21:43:36Z,fmckeogh,NA https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-02-08T09:16:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-05-06T04:13:57Z,lawliet89,NA https://github.com/rust-lang/rust/pull/68606,MERGED,2020-01-28T16:29:47Z,2020-01-28T23:44:35Z,Add an early-exit to `QueryNormalizer::fold_ty`,jonas-schievink,474d0e33717062696be4c9799ce9822bf7b56fc2,1,Add an early-exit to `QueryNormalizer::fold_ty`,HOORAY,2020-07-07T23:17:08Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/68623,MERGED,2020-01-29T00:07:13Z,2020-02-09T18:45:01Z,Add an option to use LLD to link the compiler on Windows platforms,Zoxc,d304cd0c5543c701bbfec0bd7b0c8b7c142b3bca,1,More comments,THUMBS_UP,2020-01-31T00:18:13Z,awulkan,NA https://github.com/rust-lang/rust/pull/68623,MERGED,2020-01-29T00:07:13Z,2020-02-09T18:45:01Z,Add an option to use LLD to link the compiler on Windows platforms,Zoxc,d304cd0c5543c701bbfec0bd7b0c8b7c142b3bca,1,More comments,THUMBS_UP,2020-02-09T00:19:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68623,MERGED,2020-01-29T00:07:13Z,2020-02-09T18:45:01Z,Add an option to use LLD to link the compiler on Windows platforms,Zoxc,d304cd0c5543c701bbfec0bd7b0c8b7c142b3bca,1,More comments,THUMBS_UP,2020-02-09T13:53:43Z,est31,NA https://github.com/rust-lang/rust/pull/68623,MERGED,2020-01-29T00:07:13Z,2020-02-09T18:45:01Z,Add an option to use LLD to link the compiler on Windows platforms,Zoxc,d304cd0c5543c701bbfec0bd7b0c8b7c142b3bca,1,More comments,HOORAY,2020-02-09T20:06:42Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/68623,MERGED,2020-01-29T00:07:13Z,2020-02-09T18:45:01Z,Add an option to use LLD to link the compiler on Windows platforms,Zoxc,d304cd0c5543c701bbfec0bd7b0c8b7c142b3bca,1,More comments,THUMBS_UP,2020-02-10T13:50:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/68626,MERGED,2020-01-29T00:47:20Z,2020-01-30T05:37:41Z,Use termize instead of term_size,Zoxc,b0b11d31a2cd4ff00973c17ff987c345301b2ebd,4,Use termize instead of term_size,THUMBS_UP,2020-01-29T01:42:40Z,estebank,NA https://github.com/rust-lang/rust/pull/68661,MERGED,2020-01-30T04:23:54Z,2020-01-30T15:31:35Z,Remove unused `read_uleb128` parameter.,nnethercote,6961db2024aa96bc1ba2d8f38c5dc1ba49fdabd9,1,Remove unused `read_uleb128` parameter.,LAUGH,2020-01-30T15:57:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-01-31T00:37:31Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-01-31T14:57:53Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-01-31T16:47:41Z,lqd,NA https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-02-02T00:03:17Z,cynecx,NA https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-02-05T21:01:30Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,ROCKET,2020-02-05T21:01:35Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/68672,MERGED,2020-01-30T15:11:33Z,2020-02-02T06:09:10Z,Deduplicate types in the generator witness,jonas-schievink,791123d2c4c884f97c431edf6aa8daa5dd9f6062,3,Deduplicate generator interior types,HEART,2020-02-08T09:17:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68678,MERGED,2020-01-30T20:28:08Z,2020-02-03T22:02:44Z,Install robots.txt into rust-docs tarballs,Mark-Simulacrum,39e502744c7db993eb0269285082ac5c7b7d4bdd,2,Install robots.txt into rust-docs tarballs,HEART,2020-01-31T03:19:52Z,carols10cents,NA https://github.com/rust-lang/rust/pull/68679,MERGED,2020-01-30T20:31:34Z,2020-02-12T22:43:51Z,Improve `ty.needs_drop`,matthewjasper,30a8353f372f7cc719d1de6811996ce5215183a6,2,Specify overflow checks behaviour in test,HEART,2020-02-11T22:20:48Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68679,MERGED,2020-01-30T20:31:34Z,2020-02-12T22:43:51Z,Improve `ty.needs_drop`,matthewjasper,30a8353f372f7cc719d1de6811996ce5215183a6,2,Specify overflow checks behaviour in test,HEART,2020-04-21T21:46:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68681,MERGED,2020-01-30T22:43:08Z,2020-02-02T02:55:07Z,Suggest path separator for single-colon typos,bobrippling,07ee472cd18925be45d424d9cfd59c441ea9c9a7,1,Avoid qualified path recovery when not followed by identifier,HEART,2020-01-31T03:39:16Z,estebank,NA https://github.com/rust-lang/rust/pull/68681,MERGED,2020-01-30T22:43:08Z,2020-02-02T02:55:07Z,Suggest path separator for single-colon typos,bobrippling,07ee472cd18925be45d424d9cfd59c441ea9c9a7,1,Avoid qualified path recovery when not followed by identifier,HEART,2020-02-01T21:40:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68688,MERGED,2020-01-31T01:29:58Z,2020-02-02T02:55:06Z,[docs] remind bug reporters to update nightly,jbr,2a79ed0b4999bf9e805e0e38cd1faf5f85068368,1,[docs] remind bug reporters to update nightly,THUMBS_UP,2020-01-31T04:23:53Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68688,MERGED,2020-01-31T01:29:58Z,2020-02-02T02:55:06Z,[docs] remind bug reporters to update nightly,jbr,2a79ed0b4999bf9e805e0e38cd1faf5f85068368,1,[docs] remind bug reporters to update nightly,THUMBS_UP,2020-01-31T05:16:42Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/68691,MERGED,2020-01-31T04:37:50Z,2020-02-06T19:00:47Z,Remove `RefCell` usage from `ObligationForest`.,nnethercote,6ad725e9f09f8ac1e577460ce31bc2928fe3531f,1,Remove `RefCell` usage from `ObligationForest`. It's not needed.,HEART,2020-01-31T05:09:52Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68691,MERGED,2020-01-31T04:37:50Z,2020-02-06T19:00:47Z,Remove `RefCell` usage from `ObligationForest`.,nnethercote,6ad725e9f09f8ac1e577460ce31bc2928fe3531f,1,Remove `RefCell` usage from `ObligationForest`. It's not needed.,HEART,2020-01-31T05:29:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/68691,MERGED,2020-01-31T04:37:50Z,2020-02-06T19:00:47Z,Remove `RefCell` usage from `ObligationForest`.,nnethercote,6ad725e9f09f8ac1e577460ce31bc2928fe3531f,1,Remove `RefCell` usage from `ObligationForest`. It's not needed.,HEART,2020-02-05T20:07:42Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/68691,MERGED,2020-01-31T04:37:50Z,2020-02-06T19:00:47Z,Remove `RefCell` usage from `ObligationForest`.,nnethercote,6ad725e9f09f8ac1e577460ce31bc2928fe3531f,1,Remove `RefCell` usage from `ObligationForest`. It's not needed.,HEART,2020-02-06T03:18:52Z,sinkuu,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-01-31T09:07:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-01-31T14:37:53Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-01-31T18:57:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-03-07T08:39:43Z,lperlaki,lperlaki@icloud.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-03-15T21:25:13Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-03-19T15:15:20Z,DianaNites,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-03-20T00:56:12Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-03-20T12:28:55Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-03-20T12:28:57Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-04-02T16:30:09Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-04-02T17:36:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-04-24T10:04:36Z,CGMossa,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-04-24T10:04:39Z,CGMossa,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-05-06T13:23:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-06-05T09:18:31Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HOORAY,2020-10-03T22:48:16Z,JarvisCraft,me@progrm-jarvis.ru https://github.com/rust-lang/rust/pull/68692,MERGED,2020-01-31T05:32:32Z,2020-03-29T12:58:44Z,impl From<[T; N]> for Vec,jyn514,c51fcb5f3847cc70de316db0b4c46f23fc8d0d35,4,Rollup merge of #68692 - jyn514:vec-from-array r=LukasKalbertodt impl From<[T; N]> for Vec Closes https://github.com/rust-lang/rust/issues/67963,HEART,2020-10-03T22:48:18Z,JarvisCraft,me@progrm-jarvis.ru https://github.com/rust-lang/rust/pull/68694,MERGED,2020-01-31T08:25:32Z,2020-02-10T13:56:06Z,Reduce the number of `RefCell`s in `InferCtxt`.,nnethercote,7426853ba255940b880f2e7f8026d60b94b42404,20,Reduce the number of `RefCell`s in `InferCtxt`. `InferCtxt` contains six structures within `RefCell`s. Every time we create and dispose of (commit or rollback) a snapshot we have to `borrow_mut` each one of them. This commit moves the six structures under a single `RefCell` which gives significant speed-ups by reducing the number of `borrow_mut` calls. To avoid runtime errors I had to reduce the lifetimes of dynamic borrows in a couple of places.,ROCKET,2020-01-31T10:36:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68694,MERGED,2020-01-31T08:25:32Z,2020-02-10T13:56:06Z,Reduce the number of `RefCell`s in `InferCtxt`.,nnethercote,7426853ba255940b880f2e7f8026d60b94b42404,20,Reduce the number of `RefCell`s in `InferCtxt`. `InferCtxt` contains six structures within `RefCell`s. Every time we create and dispose of (commit or rollback) a snapshot we have to `borrow_mut` each one of them. This commit moves the six structures under a single `RefCell` which gives significant speed-ups by reducing the number of `borrow_mut` calls. To avoid runtime errors I had to reduce the lifetimes of dynamic borrows in a couple of places.,ROCKET,2020-02-03T18:46:27Z,mati865,NA https://github.com/rust-lang/rust/pull/68694,MERGED,2020-01-31T08:25:32Z,2020-02-10T13:56:06Z,Reduce the number of `RefCell`s in `InferCtxt`.,nnethercote,7426853ba255940b880f2e7f8026d60b94b42404,20,Reduce the number of `RefCell`s in `InferCtxt`. `InferCtxt` contains six structures within `RefCell`s. Every time we create and dispose of (commit or rollback) a snapshot we have to `borrow_mut` each one of them. This commit moves the six structures under a single `RefCell` which gives significant speed-ups by reducing the number of `borrow_mut` calls. To avoid runtime errors I had to reduce the lifetimes of dynamic borrows in a couple of places.,ROCKET,2020-04-25T19:41:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68699,CLOSED,2020-01-31T13:25:24Z,2020-10-30T03:49:06Z,Keep code coloring in search results short text,GuillaumeGomez,NA,NA,NA,HEART,2020-01-31T13:49:49Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-01-31T13:46:14Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-01-31T13:50:01Z,K900,me@0upti.me https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-01-31T13:50:04Z,K900,me@0upti.me https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-01-31T13:53:05Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-01-31T14:00:45Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-01-31T14:00:46Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-01-31T15:02:43Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-01-31T17:39:54Z,95th,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-01-31T17:39:57Z,95th,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,ROCKET,2020-01-31T20:39:04Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-01T10:00:12Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-02T21:30:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-07T09:05:31Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-07T17:18:43Z,andrew-d,andrew@du.nham.ca https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-02-07T17:18:48Z,andrew-d,andrew@du.nham.ca https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-13T15:48:14Z,DianaNites,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-02-15T17:01:38Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HEART,2020-02-16T10:37:50Z,ohadravid,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-02-27T00:29:33Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-03-24T14:33:33Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-04-03T11:18:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68700,MERGED,2020-01-31T13:36:35Z,2020-03-23T22:03:02Z,Add Wake trait for safe construction of Wakers.,withoutboats,e4d2f747e56e52cbd4ee90222fb455c6488ba683,3,Rollup merge of #68700 - withoutboats:wake-trait r=withoutboats Add Wake trait for safe construction of Wakers. Currently constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc` with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc`: - We want to support futures on embedded systems which may not have an allocator and in optimized executors for which this API may not be best-suited. Therefore we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc it has not been feasible to provide a constructor for `Waker` from `Arc`. Therefore the Wake trait was left out of the initial version of the task waker API. However as Rust 1.41 it is possible under the more flexible orphan rules to implement `From> for Waker where W: Wake` in liballoc. Therefore we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait which contains two methods - A required method `wake` which is called by `Waker::wake` - A provided method `wake_by_ref` which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From> for RawWaker`.,HOORAY,2020-04-06T14:35:53Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-01-31T22:38:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-01-31T22:40:23Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-01-31T23:20:04Z,macpp,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-01-31T23:30:11Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-02-01T11:22:22Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-02-13T21:42:04Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-02-13T22:26:26Z,estebank,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-02-16T15:08:52Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-02-16T16:51:50Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-03-14T20:31:43Z,frol,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-03-29T13:49:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-04-16T09:54:10Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-04-17T06:09:32Z,samsartor,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-04-20T07:33:15Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-04-20T12:19:56Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-04-29T03:11:00Z,tmandry,NA https://github.com/rust-lang/rust/pull/68716,MERGED,2020-01-31T22:31:02Z,2020-04-27T05:48:07Z,Stabilize `Span::mixed_site`,petrochenkov,9d0025263a55f1bcb80ebdc0d83d1e64cdf05e5a,2,"Rollup merge of #68716 - petrochenkov:stabmixed r=dtolnay Stabilize `Span::mixed_site` Closes https://github.com/rust-lang/rust/issues/65049. cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Pre-requisite for https://github.com/rust-lang/rust/pull/68717 (""Stabilize fn-like proc macros in expression pattern and statement positions""). Stabilization report: https://github.com/rust-lang/rust/pull/68716#issuecomment-581076337.",HOORAY,2020-05-01T10:06:35Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T22:34:54Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T22:38:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T22:55:56Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T23:20:08Z,macpp,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T23:30:31Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-01-31T23:35:58Z,dbeckwith,daniel.beckwith@tulip.co https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-01T03:37:37Z,est31,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-01T11:22:18Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-08T14:49:15Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-10T06:50:21Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-11T08:15:52Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-13T21:45:16Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T04:25:36Z,ssokolow,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T07:58:02Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T08:04:04Z,strohel,matej@laitl.cz https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T10:02:52Z,thetric,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T10:16:41Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T12:53:10Z,Songtronix,contact@songtronix.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T15:13:17Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T16:51:35Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-16T17:55:01Z,zaccari,michael.zaccari@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-17T03:06:08Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-19T21:16:22Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-20T16:16:10Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-24T16:37:40Z,DaleLJefferson,dale@dalejefferson.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-02-25T18:12:32Z,otake84,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-03-14T20:29:42Z,frol,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-03-29T13:49:29Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-06T21:33:36Z,rrbutani,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-16T09:53:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-17T06:09:11Z,samsartor,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-20T16:41:58Z,hayd,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-27T05:54:13Z,sd2k,ben@bsull.io https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-27T19:42:03Z,iago-lito,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-29T04:16:58Z,tmandry,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-04-29T14:42:29Z,TatriX,me@tatrix.org https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-01T10:06:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-03T23:29:42Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-04T01:01:51Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-07T10:35:34Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-07T13:47:20Z,swarnimarun,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",THUMBS_UP,2020-05-10T16:49:58Z,Schultzer,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-12T17:45:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-12T23:29:20Z,brianchin,brianchin@google.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",THUMBS_UP,2020-05-13T01:11:10Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-13T01:11:12Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-14T09:43:04Z,martinrlilja,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-14T19:08:01Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-17T19:59:47Z,vlthr,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T00:12:22Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T00:36:00Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T01:17:33Z,weirane,gh@ruo-chen.wang https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T02:11:28Z,lily-mara,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T04:31:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T07:45:58Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T09:10:43Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-18T14:51:14Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-19T06:52:02Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-19T07:59:58Z,DuBistKomisch,me@jakebarn.es https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-19T08:19:39Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-19T11:26:25Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",THUMBS_UP,2020-05-19T11:26:26Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-22T00:59:12Z,ken0x0a,ken0x0a+github@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-28T13:21:52Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-28T17:52:59Z,PtaxLaine,andrei@ptaxa.net https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",THUMBS_UP,2020-05-29T03:25:09Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-05-30T12:06:46Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-06-14T15:34:21Z,seanjensengrey,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-06-26T09:32:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-07-14T07:31:31Z,Folyd,NA https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",THUMBS_UP,2020-07-15T17:19:57Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2020-07-21T10:02:41Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/68717,MERGED,2020-01-31T22:33:33Z,2020-05-19T06:31:24Z,Stabilize fn-like proc macros in expression pattern and statement positions,petrochenkov,5943351d0eb878c1cb5af42b9e85e101d8c58ed7,41,"Auto merge of #68717 - petrochenkov:stabexpat r=varkor Stabilize fn-like proc macros in expression pattern and statement positions I.e. all the positions in which stable `macro_rules` macros are supported. Depends on https://github.com/rust-lang/rust/pull/68716 (""Stabilize `Span::mixed_site`""). cc https://github.com/rust-lang/rust/issues/54727 cc https://github.com/rust-lang/rust/issues/54727#issuecomment-580647446 Stabilization report: https://github.com/rust-lang/rust/pull/68717#issuecomment-623197503.",HOORAY,2021-06-03T21:40:44Z,lukechu10,NA https://github.com/rust-lang/rust/pull/68720,MERGED,2020-02-01T00:05:44Z,2020-02-03T00:04:14Z,Add support for enabling the LLVM time-trace feature,wesleywiser,f5f86be1d40f30b3183ec148f443afa73d0cbe15,5,Add support for enabling the LLVM time-trace feature I found this helpful while investigating an LLVM performance issue. Passing `-Z llvm-time-trace` causes a `llvm_timings.json` file to be created. This file can be inspected in either the Chrome Profiler tools or with any other compatible tool like SpeedScope. More information on the LLVM feature: - https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/ - https://reviews.llvm.org/rL357340,THUMBS_UP,2020-02-07T07:07:29Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/68725,MERGED,2020-02-01T11:43:00Z,2020-02-11T17:46:21Z,Invert control in struct_lint_level.,jumbatm,b959da2f4cd2cf8f4b170369355fe7329cf5a9c9,6,Fix stage2 test failures from call to span_lint. span_lint was removed. Callers should use the `lint` method now and call `set_span` within the closure passed to this method.,HEART,2020-02-10T10:19:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/68725,MERGED,2020-02-01T11:43:00Z,2020-02-11T17:46:21Z,Invert control in struct_lint_level.,jumbatm,b959da2f4cd2cf8f4b170369355fe7329cf5a9c9,6,Fix stage2 test failures from call to span_lint. span_lint was removed. Callers should use the `lint` method now and call `set_span` within the closure passed to this method.,HEART,2020-04-21T21:58:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68728,MERGED,2020-02-01T12:51:14Z,2020-02-14T01:38:20Z,parse: merge `fn` syntax + cleanup item parsing,Centril,ad72c3abb9a7f9746d6ccc381e69ba88fb15b5cd,1,parser: inline parse_assoc_macro_invoc,HOORAY,2020-02-01T13:05:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/68728,MERGED,2020-02-01T12:51:14Z,2020-02-14T01:38:20Z,parse: merge `fn` syntax + cleanup item parsing,Centril,ad72c3abb9a7f9746d6ccc381e69ba88fb15b5cd,1,parser: inline parse_assoc_macro_invoc,HOORAY,2020-04-21T17:39:13Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/68733,MERGED,2020-02-01T17:08:08Z,2020-02-02T16:48:39Z,Update option.rs,cmarincia,2ce14b8a19865ed359e9df7eb5e8e6186cae1e58,1,Update option.rs I updated the example of the `expect` examples so they won't contain depressing sentences any more !,LAUGH,2020-02-01T19:38:00Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/68733,MERGED,2020-02-01T17:08:08Z,2020-02-02T16:48:39Z,Update option.rs,cmarincia,2ce14b8a19865ed359e9df7eb5e8e6186cae1e58,1,Update option.rs I updated the example of the `expect` examples so they won't contain depressing sentences any more !,LAUGH,2020-02-01T21:01:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/68733,MERGED,2020-02-01T17:08:08Z,2020-02-02T16:48:39Z,Update option.rs,cmarincia,2ce14b8a19865ed359e9df7eb5e8e6186cae1e58,1,Update option.rs I updated the example of the `expect` examples so they won't contain depressing sentences any more !,LAUGH,2020-02-02T01:22:34Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/68733,MERGED,2020-02-01T17:08:08Z,2020-02-02T16:48:39Z,Update option.rs,cmarincia,2ce14b8a19865ed359e9df7eb5e8e6186cae1e58,1,Update option.rs I updated the example of the `expect` examples so they won't contain depressing sentences any more !,LAUGH,2020-02-02T01:45:10Z,pie-flavor,pieflavor.mc@gmail.com https://github.com/rust-lang/rust/pull/68733,MERGED,2020-02-01T17:08:08Z,2020-02-02T16:48:39Z,Update option.rs,cmarincia,2ce14b8a19865ed359e9df7eb5e8e6186cae1e58,1,Update option.rs I updated the example of the `expect` examples so they won't contain depressing sentences any more !,LAUGH,2020-02-02T10:54:47Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/68744,MERGED,2020-02-01T21:41:52Z,2020-02-03T22:02:36Z,Do not ICE in `type-alias-impl-trait` with save-analysis,JohnTitor,ae22bf9d42abb7fc5ae4619a5feaafc61aa0c539,3,Catch more ICEs,HOORAY,2020-02-02T06:20:00Z,est31,NA https://github.com/rust-lang/rust/pull/68746,MERGED,2020-02-01T21:46:51Z,2020-03-17T18:28:21Z,Make macro metavars respect (non-)hygiene,matthewjasper,8cf9e9efcadef137b9f04c741115aa8664a5a910,7,Rollup merge of #68746 - matthewjasper:metahygiene r=petrochenkov Make macro metavars respect (non-)hygiene This makes them more consistent with other name resolution while not breaking any code on crater.,EYES,2020-02-01T21:51:15Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/68746,MERGED,2020-02-01T21:46:51Z,2020-03-17T18:28:21Z,Make macro metavars respect (non-)hygiene,matthewjasper,8cf9e9efcadef137b9f04c741115aa8664a5a910,7,Rollup merge of #68746 - matthewjasper:metahygiene r=petrochenkov Make macro metavars respect (non-)hygiene This makes them more consistent with other name resolution while not breaking any code on crater.,EYES,2020-02-02T12:19:42Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68758,MERGED,2020-02-02T03:05:38Z,2020-02-05T06:33:23Z,Fix 59191 - ICE when macro replaces crate root with non-module item,daboross,152811d8bf389fce7328ba7bc50c26c34afb0d81,3,Change expansion error to be non-fatal Changes the error handler for inner attributes that replace the root with a non-module. Previously it would emit a fatal error. It now emits an empty expasion and a non-fatal error like the existing handler for a failed expansion.,HEART,2020-02-02T09:08:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68758,MERGED,2020-02-02T03:05:38Z,2020-02-05T06:33:23Z,Fix 59191 - ICE when macro replaces crate root with non-module item,daboross,152811d8bf389fce7328ba7bc50c26c34afb0d81,3,Change expansion error to be non-fatal Changes the error handler for inner attributes that replace the root with a non-module. Previously it would emit a fatal error. It now emits an empty expasion and a non-fatal error like the existing handler for a failed expansion.,HEART,2020-02-03T00:52:39Z,estebank,NA https://github.com/rust-lang/rust/pull/68758,MERGED,2020-02-02T03:05:38Z,2020-02-05T06:33:23Z,Fix 59191 - ICE when macro replaces crate root with non-module item,daboross,152811d8bf389fce7328ba7bc50c26c34afb0d81,3,Change expansion error to be non-fatal Changes the error handler for inner attributes that replace the root with a non-module. Previously it would emit a fatal error. It now emits an empty expasion and a non-fatal error like the existing handler for a failed expansion.,HEART,2020-02-04T23:43:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68763,MERGED,2020-02-02T08:59:08Z,2020-02-02T16:48:34Z,Do not suggest duplicate bounds,JohnTitor,56ad8bcfe0025618d35c8479797bca5d05e81099,5,Do not suggest duplicate bounds,HOORAY,2020-02-06T16:31:29Z,najamelan,NA https://github.com/rust-lang/rust/pull/68764,MERGED,2020-02-02T10:12:51Z,2020-02-02T16:48:33Z,parser: syntactically allow `self` in all `fn` contexts,Centril,71a6f58229c00720b35579856bdb64e2a19af521,19,parser: address review comments re. `self`.,THUMBS_UP,2020-02-02T12:51:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68764,MERGED,2020-02-02T10:12:51Z,2020-02-02T16:48:33Z,parser: syntactically allow `self` in all `fn` contexts,Centril,71a6f58229c00720b35579856bdb64e2a19af521,19,parser: address review comments re. `self`.,THUMBS_UP,2020-02-02T20:48:45Z,SiavoshZarrasvand,siavosh@zarrasvand.com https://github.com/rust-lang/rust/pull/68795,CLOSED,2020-02-03T12:53:49Z,2020-02-05T01:01:16Z,[experiment] Try using a very simple heuristic for the inliner,wesleywiser,NA,NA,NA,HEART,2020-02-04T12:46:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/68798,MERGED,2020-02-03T15:17:44Z,2020-02-03T22:02:28Z,Test that `#[track_caller]` as `fn()` respects RT / CTFE equivalence,Centril,f0eec8858173868d2d266c5d7fe4ef83a2d9412c,2,track_caller test caller_location ctfe/rt equivalence wrt. fnptrs,HEART,2020-02-03T16:09:54Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/68802,MERGED,2020-02-03T17:57:14Z,2020-02-09T00:51:57Z,rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.,eddyb,80515f7528efd2921e474d932755b823eee6f53b,2,rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.,THUMBS_UP,2020-02-04T11:38:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68805,MERGED,2020-02-03T19:15:48Z,2020-02-05T06:33:18Z,bootstrap: fix clippy warnings,matthiaskrgr,5f979e9afab42dd7536ca93994de66169880361e,17,bootstrap: fix clippy warnings,HEART,2020-02-04T01:09:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/68810,MERGED,2020-02-03T22:36:20Z,2020-02-05T06:33:17Z,Remove Copy impl from OnceWith,ollie27,5f689fe466b6ed0d63e5d5f732804bb74c07b58d,1,Remove Copy impl from OnceWith Iterators typically don't implement `Copy` and this shouldn't be an exception.,THUMBS_UP,2020-02-04T06:11:14Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68811,CLOSED,2020-02-03T22:39:06Z,2020-03-29T18:54:52Z,"Re-land ""add IntoFuture trait and support for await""",tmandry,NA,NA,NA,EYES,2020-02-03T22:40:30Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68811,CLOSED,2020-02-03T22:39:06Z,2020-03-29T18:54:52Z,"Re-land ""add IntoFuture trait and support for await""",tmandry,NA,NA,NA,HOORAY,2020-02-03T22:41:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68818,MERGED,2020-02-04T01:29:15Z,2020-02-05T06:33:14Z,fix couple of perf related clippy warnings,matthiaskrgr,fe1314dbc42da3331062c9348f7117b3585ad6bd,4,fix couple of perf related clipyp warnings librustc: don't clone a type that is copy librustc_incremental: use faster vector initialization librustc_typeck: don't clone a type that is copy librustdoc: don't create a vector where a slice will do,HEART,2020-02-04T05:52:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/68818,MERGED,2020-02-04T01:29:15Z,2020-02-05T06:33:14Z,fix couple of perf related clippy warnings,matthiaskrgr,fe1314dbc42da3331062c9348f7117b3585ad6bd,4,fix couple of perf related clipyp warnings librustc: don't clone a type that is copy librustc_incremental: use faster vector initialization librustc_typeck: don't clone a type that is copy librustdoc: don't create a vector where a slice will do,HEART,2020-02-04T12:49:05Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/68819,MERGED,2020-02-04T02:00:47Z,2020-02-05T06:33:13Z,Suggest `split_at_mut` on multiple mutable index access,estebank,0f73133be6a6915e2d5836ce9986eaffc1b2954d,3,Suggest `split_at_mut` on multiple mutable index access,HEART,2020-02-04T15:42:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68819,MERGED,2020-02-04T02:00:47Z,2020-02-05T06:33:13Z,Suggest `split_at_mut` on multiple mutable index access,estebank,0f73133be6a6915e2d5836ce9986eaffc1b2954d,3,Suggest `split_at_mut` on multiple mutable index access,HEART,2020-11-20T14:00:32Z,fanzier,NA https://github.com/rust-lang/rust/pull/68820,MERGED,2020-02-04T09:07:06Z,2020-03-22T15:05:36Z,Remove `finished` flag from `MapWhile`,WaffleLapkin,5ae85f43f4eeaf177cd12f47958b7ff62786b612,2,Auto merge of #68820 - WaffleLapkin:remove_finished_from_map_while r=LukasKalbertodt Remove `finished` flag from `MapWhile` This PR removes `finished` flag from `MapWhile` as been proposed in https://github.com/rust-lang/rust/pull/66577#discussion_r370958025. This also resolves open questions of the tracking issue (#68537): - `MapWhile` can't implement both + `DoubleEndedIterator` (discussed in https://github.com/rust-lang/rust/pull/66577#discussion_r370947990 and following comments) + `FusedIterator` (this pr removes `finished` flag so `MapWhile` isn't fused anymore) - Debug output (this pr removes `finished` flag so there is no question in including it in debug output) r? @Mark-Simulacrum,HEART,2020-02-04T20:10:48Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/68820,MERGED,2020-02-04T09:07:06Z,2020-03-22T15:05:36Z,Remove `finished` flag from `MapWhile`,WaffleLapkin,5ae85f43f4eeaf177cd12f47958b7ff62786b612,2,Auto merge of #68820 - WaffleLapkin:remove_finished_from_map_while r=LukasKalbertodt Remove `finished` flag from `MapWhile` This PR removes `finished` flag from `MapWhile` as been proposed in https://github.com/rust-lang/rust/pull/66577#discussion_r370958025. This also resolves open questions of the tracking issue (#68537): - `MapWhile` can't implement both + `DoubleEndedIterator` (discussed in https://github.com/rust-lang/rust/pull/66577#discussion_r370947990 and following comments) + `FusedIterator` (this pr removes `finished` flag so `MapWhile` isn't fused anymore) - Debug output (this pr removes `finished` flag so there is no question in including it in debug output) r? @Mark-Simulacrum,HEART,2020-02-08T03:08:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68820,MERGED,2020-02-04T09:07:06Z,2020-03-22T15:05:36Z,Remove `finished` flag from `MapWhile`,WaffleLapkin,5ae85f43f4eeaf177cd12f47958b7ff62786b612,2,Auto merge of #68820 - WaffleLapkin:remove_finished_from_map_while r=LukasKalbertodt Remove `finished` flag from `MapWhile` This PR removes `finished` flag from `MapWhile` as been proposed in https://github.com/rust-lang/rust/pull/66577#discussion_r370958025. This also resolves open questions of the tracking issue (#68537): - `MapWhile` can't implement both + `DoubleEndedIterator` (discussed in https://github.com/rust-lang/rust/pull/66577#discussion_r370947990 and following comments) + `FusedIterator` (this pr removes `finished` flag so `MapWhile` isn't fused anymore) - Debug output (this pr removes `finished` flag so there is no question in including it in debug output) r? @Mark-Simulacrum,HEART,2020-12-02T16:38:31Z,bluss,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,ROCKET,2020-02-04T17:28:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,ROCKET,2020-02-04T17:48:42Z,panaman67,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-02-04T17:48:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,ROCKET,2020-02-05T02:36:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-02-06T19:49:15Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-02-27T00:26:51Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-05T19:55:11Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,ROCKET,2020-03-05T19:55:12Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-05T20:59:25Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-05T21:58:20Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-05T22:40:22Z,GrayJack,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-06T14:48:12Z,tux3,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,HEART,2020-03-08T01:16:32Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68827,MERGED,2020-02-04T17:17:29Z,2020-02-28T12:42:41Z,BTreeMap navigation done safer & faster,ssomers,e2223c94bf433fc38234d1303e88cbaf14755863,4,Auto merge of #68827 - ssomers:btree_navigation_revisited r=Mark-Simulacrum BTreeMap navigation done safer & faster It turns out that there was a faster way to do the tree navigation code bundled in #67073 by moving from edge to KV and from KV to next edge separately. It extracts most of the code as safe functions and contains the duplication of handles within the short wrapper functions. This somehow hits a sweet spot in the compiler because it reports boosts all over the board: ``` >cargo benchcmp pre3.txt posz4.txt --threshold 5 name pre3.txt ns/iter posz4.txt ns/iter diff ns/iter diff % speedup btree::map::first_and_last_0 40 37 -3 -7.50% x 1.08 btree::map::first_and_last_100 58 44 -14 -24.14% x 1.32 btree::map::iter_1000 8 920 3 419 -5 501 -61.67% x 2.61 btree::map::iter_100000 1 069 290 411 615 -657 675 -61.51% x 2.60 btree::map::iter_20 169 58 -111 -65.68% x 2.91 btree::map::iter_mut_1000 8 701 3 303 -5 398 -62.04% x 2.63 btree::map::iter_mut_100000 1 034 560 405 975 -628 585 -60.76% x 2.55 btree::map::iter_mut_20 165 58 -107 -64.85% x 2.84 btree::set::clone_100 1 831 1 562 -269 -14.69% x 1.17 btree::set::clone_100_and_clear 1 831 1 565 -266 -14.53% x 1.17 btree::set::clone_100_and_into_iter 1 917 1 541 -376 -19.61% x 1.24 btree::set::clone_100_and_pop_all 2 609 2 441 -168 -6.44% x 1.07 btree::set::clone_100_and_remove_all 4 598 3 927 -671 -14.59% x 1.17 btree::set::clone_100_and_remove_half 2 765 2 551 -214 -7.74% x 1.08 btree::set::clone_10k 191 610 164 616 -26 994 -14.09% x 1.16 btree::set::clone_10k_and_clear 192 003 164 616 -27 387 -14.26% x 1.17 btree::set::clone_10k_and_into_iter 200 037 163 010 -37 027 -18.51% x 1.23 btree::set::clone_10k_and_pop_all 267 023 250 913 -16 110 -6.03% x 1.06 btree::set::clone_10k_and_remove_all 536 230 464 100 -72 130 -13.45% x 1.16 btree::set::clone_10k_and_remove_half 453 350 430 545 -22 805 -5.03% x 1.05 btree::set::difference_random_100_vs_100 1 787 801 -986 -55.18% x 2.23 btree::set::difference_random_100_vs_10k 2 978 2 696 -282 -9.47% x 1.10 btree::set::difference_random_10k_vs_100 111 075 54 734 -56 341 -50.72% x 2.03 btree::set::difference_random_10k_vs_10k 246 380 175 980 -70 400 -28.57% x 1.40 btree::set::difference_staggered_100_vs_100 1 789 951 -838 -46.84% x 1.88 btree::set::difference_staggered_100_vs_10k 2 798 2 606 -192 -6.86% x 1.07 btree::set::difference_staggered_10k_vs_10k 176 452 97 401 -79 051 -44.80% x 1.81 btree::set::intersection_100_neg_vs_10k_pos 34 32 -2 -5.88% x 1.06 btree::set::intersection_100_pos_vs_100_neg 30 27 -3 -10.00% x 1.11 btree::set::intersection_random_100_vs_100 1 537 613 -924 -60.12% x 2.51 btree::set::intersection_random_100_vs_10k 2 793 2 649 -144 -5.16% x 1.05 btree::set::intersection_random_10k_vs_10k 222 127 147 166 -74 961 -33.75% x 1.51 btree::set::intersection_staggered_100_vs_100 1 447 622 -825 -57.01% x 2.33 btree::set::intersection_staggered_100_vs_10k 2 606 2 382 -224 -8.60% x 1.09 btree::set::intersection_staggered_10k_vs_10k 143 620 58 790 -84 830 -59.07% x 2.44 btree::set::is_subset_100_vs_100 1 349 488 -861 -63.83% x 2.76 btree::set::is_subset_100_vs_10k 1 720 1 428 -292 -16.98% x 1.20 btree::set::is_subset_10k_vs_10k 135 984 48 527 -87 457 -64.31% x 2.80 ``` The `first_and_last` ones are noise (they don't do iteration) the others seem genuine. As always approved by Miri. Also a separate commit with some more benchmarks of mutable behaviour (which also benefit). r? @cuviper,ROCKET,2020-03-08T01:16:34Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2020-02-04T20:36:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2020-02-04T23:45:34Z,bjorn3,NA https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2020-02-05T05:17:13Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2020-08-14T14:06:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2021-01-26T10:26:52Z,bluss,NA https://github.com/rust-lang/rust/pull/68828,MERGED,2020-02-04T17:46:19Z,2021-01-25T22:11:43Z,Prevent query cycles in the MIR inliner,oli-obk,f4eb5d9f719cd3c849befc8914ad8ce0ddcf34ed,15,Auto merge of #68828 - oli-obk:inline_cycle r=wesleywiser Prevent query cycles in the MIR inliner r? `@eddyb` `@wesleywiser` cc `@rust-lang/wg-mir-opt` The general design is that we have a new query that is run on the `validated_mir` instead of on the `optimized_mir`. That query is forced before going into the optimization pipeline so as to not try to read from a stolen MIR. The query should not be cached cross crate as you should never call it for items from other crates. By its very design calls into other crates can never cause query cycles. This is a pessimistic approach to inlining since we strictly have more calls in the `validated_mir` than we have in `optimized_mir` but that's not a problem imo.,HEART,2021-01-28T07:04:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68837,MERGED,2020-02-05T00:46:38Z,2020-02-06T19:00:30Z,Make associated item collection a query,jonas-schievink,4fc4b951f1da755298aea69f10a4951745ee8501,3,Make associated item lookup a query,THUMBS_UP,2020-02-05T02:33:46Z,estebank,NA https://github.com/rust-lang/rust/pull/68837,MERGED,2020-02-05T00:46:38Z,2020-02-06T19:00:30Z,Make associated item collection a query,jonas-schievink,4fc4b951f1da755298aea69f10a4951745ee8501,3,Make associated item lookup a query,THUMBS_UP,2020-02-05T02:34:49Z,tesuji,NA https://github.com/rust-lang/rust/pull/68837,MERGED,2020-02-05T00:46:38Z,2020-02-06T19:00:30Z,Make associated item collection a query,jonas-schievink,4fc4b951f1da755298aea69f10a4951745ee8501,3,Make associated item lookup a query,THUMBS_UP,2020-02-05T23:20:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68845,MERGED,2020-02-05T03:34:05Z,2020-02-06T19:00:26Z,stop using BytePos for computing spans in librustc_parse/parser/mod.rs,dwrensha,9ac68e128b112e312cfde264d04b9d374a4402d0,2,stop using BytePos for computing spans in librustc_parse/parser/mod.rs,HEART,2020-02-05T03:47:58Z,estebank,NA https://github.com/rust-lang/rust/pull/68845,MERGED,2020-02-05T03:34:05Z,2020-02-06T19:00:26Z,stop using BytePos for computing spans in librustc_parse/parser/mod.rs,dwrensha,9ac68e128b112e312cfde264d04b9d374a4402d0,2,stop using BytePos for computing spans in librustc_parse/parser/mod.rs,HEART,2020-02-05T06:22:49Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-05T10:25:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-05T17:51:04Z,Pratyush,NA https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-05T21:09:55Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-13T23:04:09Z,cramertj,NA https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-16T01:15:02Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-20T08:48:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-02-21T00:08:26Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-05-07T06:37:25Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-05-07T13:06:48Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68847,MERGED,2020-02-05T05:10:43Z,2020-02-20T12:06:40Z,Allow trait methods to be called on concrete types in a const context,ecstatic-morse,6af388b25050bca26710be7e4030e17bf6d8d2f7,22,Auto merge of #68847 - ecstatic-morse:const-impl r=oli-obk Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types we are able to take advantage of the machinery in `Instance::resolve` which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2021-07-30T11:24:38Z,andrewsonin,sonin.cel@yandex.ru https://github.com/rust-lang/rust/pull/68848,CLOSED,2020-02-05T05:15:06Z,2020-02-13T23:52:45Z,Hasten macro parsing,nnethercote,NA,NA,NA,HEART,2020-02-05T10:22:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68848,CLOSED,2020-02-05T05:15:06Z,2020-02-13T23:52:45Z,Hasten macro parsing,nnethercote,NA,NA,NA,ROCKET,2020-02-05T15:52:32Z,lqd,NA https://github.com/rust-lang/rust/pull/68849,CLOSED,2020-02-05T05:35:16Z,2020-02-05T06:15:58Z,Don't use the word 'unwrap' to describe core 'unwrap' functions,brson,NA,NA,NA,LAUGH,2020-02-05T05:40:46Z,Aimeedeer,NA https://github.com/rust-lang/rust/pull/68880,MERGED,2020-02-06T07:22:53Z,2020-02-06T19:00:22Z,Forbid using `0` as issue number,JohnTitor,bf269335d07b47e548277a02e4cda3c8519a9eec,5,Forbid using `0` as issue number,THUMBS_UP,2020-02-06T12:02:27Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/68884,MERGED,2020-02-06T10:14:37Z,2020-03-24T09:38:36Z,Make the `type_of` return a generic type for generators,Zoxc,a1309547f9b02825c4aaa8464a78bdaa059564ac,19,Rollup merge of #68884 - Zoxc:gen-type r=nikomatsakis Make the `type_of` return a generic type for generators Fixes https://github.com/rust-lang/rust/issues/67651. r? @nikomatsakis,HOORAY,2020-02-07T20:18:33Z,tmandry,NA https://github.com/rust-lang/rust/pull/68884,MERGED,2020-02-06T10:14:37Z,2020-03-24T09:38:36Z,Make the `type_of` return a generic type for generators,Zoxc,a1309547f9b02825c4aaa8464a78bdaa059564ac,19,Rollup merge of #68884 - Zoxc:gen-type r=nikomatsakis Make the `type_of` return a generic type for generators Fixes https://github.com/rust-lang/rust/issues/67651. r? @nikomatsakis,HOORAY,2020-03-25T01:49:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/68899,MERGED,2020-02-06T18:48:43Z,2020-03-12T19:37:45Z,Add Display and Error impls for proc_macro::LexError,kinseytamsin,703dcff081aa9f4aef2e94fb25d6743692c2dd47,1,Rollup merge of #68899 - kinseytamsin:lexerror-error-impl r=Centril Add Display and Error impls for proc_macro::LexError This should allow LexError to play much nicer with the `?` operator. Fixes #68896. (I'm not sure if I did the stability attributes right so if I need to change them please let me know!),THUMBS_UP,2020-02-06T22:33:03Z,Nutomic,me@nutomic.com https://github.com/rust-lang/rust/pull/68902,CLOSED,2020-02-06T19:28:45Z,2020-02-08T16:26:33Z,experiment: Use llvm.dbg.value instead of llvm.dbg.declare when possible.,eddyb,NA,NA,NA,LAUGH,2020-02-06T19:32:51Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68911,MERGED,2020-02-07T00:09:35Z,2020-02-09T22:13:17Z,Speed up the inherent impl overlap check,jonas-schievink,58a9284bff045ef81f38b730043b5acb00485d0e,1,Add missing import,HOORAY,2020-02-08T11:04:16Z,lqd,NA https://github.com/rust-lang/rust/pull/68911,MERGED,2020-02-07T00:09:35Z,2020-02-09T22:13:17Z,Speed up the inherent impl overlap check,jonas-schievink,58a9284bff045ef81f38b730043b5acb00485d0e,1,Add missing import,HOORAY,2020-02-10T00:53:55Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/68911,MERGED,2020-02-07T00:09:35Z,2020-02-09T22:13:17Z,Speed up the inherent impl overlap check,jonas-schievink,58a9284bff045ef81f38b730043b5acb00485d0e,1,Add missing import,HOORAY,2020-02-24T18:44:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68914,MERGED,2020-02-07T02:24:36Z,2020-02-12T19:32:16Z,Speed up `SipHasher128`.,nnethercote,9aea154e7893b498b98a3d9c8e4c385c96fbe454,1,Improve `u8to64_le`. This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.,HEART,2020-02-21T02:05:01Z,estebank,NA https://github.com/rust-lang/rust/pull/68914,MERGED,2020-02-07T02:24:36Z,2020-02-12T19:32:16Z,Speed up `SipHasher128`.,nnethercote,9aea154e7893b498b98a3d9c8e4c385c96fbe454,1,Improve `u8to64_le`. This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.,HEART,2020-04-24T17:56:31Z,stopyellingatme,NA https://github.com/rust-lang/rust/pull/68914,MERGED,2020-02-07T02:24:36Z,2020-02-12T19:32:16Z,Speed up `SipHasher128`.,nnethercote,9aea154e7893b498b98a3d9c8e4c385c96fbe454,1,Improve `u8to64_le`. This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.,HEART,2020-05-01T11:34:57Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/68914,MERGED,2020-02-07T02:24:36Z,2020-02-12T19:32:16Z,Speed up `SipHasher128`.,nnethercote,9aea154e7893b498b98a3d9c8e4c385c96fbe454,1,Improve `u8to64_le`. This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.,HOORAY,2020-11-18T05:45:39Z,bb010g,NA https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",THUMBS_UP,2020-02-07T22:01:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",HEART,2020-02-07T23:48:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",THUMBS_UP,2020-02-08T02:00:17Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",HEART,2020-02-08T02:01:24Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",THUMBS_UP,2020-02-08T20:29:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",THUMBS_UP,2020-04-11T04:48:00Z,95th,NA https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",HEART,2020-04-11T04:48:02Z,95th,NA https://github.com/rust-lang/rust/pull/68918,MERGED,2020-02-07T06:10:31Z,2020-02-09T13:41:12Z,"Don't use the word ""unwrap"" to describe ""unwrap"" methods",brson,8251e12950159c5802dd3995b14be7cf4fa99acd,2,"Don't use the word 'unwrap' to describe core unwrapping functions It's tautological and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words ""return"" ""contain"" ""consume"". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.",THUMBS_UP,2021-04-01T19:09:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68932,MERGED,2020-02-07T14:53:24Z,2020-02-11T02:00:44Z,self-profile: Support arguments for generic_activities.,michaelwoerister,81dccb1a5c7b67c61cb7eb421150c671d6e1a7de,8,self-profile: Support arguments for generic_activities.,THUMBS_UP,2020-02-08T03:10:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68940,CLOSED,2020-02-08T00:57:49Z,2020-06-11T21:11:09Z,Remove `qualify_min_const_fn` pass,ecstatic-morse,NA,NA,NA,HOORAY,2020-02-10T08:34:22Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68940,CLOSED,2020-02-08T00:57:49Z,2020-06-11T21:11:09Z,Remove `qualify_min_const_fn` pass,ecstatic-morse,NA,NA,NA,HOORAY,2020-02-16T14:50:50Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68943,MERGED,2020-02-08T04:10:37Z,2020-03-01T07:53:47Z,Skip `Drop` terminators for enum variants without drop glue,ecstatic-morse,d9051341a1c142542a3f7dab509266606c775382,1,"Auto merge of #68943 - ecstatic-morse:no-useless-drop-on-enum-variants r=matthewjasper Skip `Drop` terminators for enum variants without drop glue Split out from #68528. When doing drop elaboration for an `enum` that may or may not be moved out of (an open drop) we check the discriminant of the `enum` to see whether the live variant has any drop flags and then check the drop flags to see whether we need to drop each field. Sometimes however the live variant has no move paths and thus no drop flags. In this case we still emit a drop terminator for the entire enum after checking the enum discriminant. This drop shim will check the discriminant of the enum *again* and then drop the fields of the active variant. If the active variant has no drop glue nothing will be done. This commit skips emitting the drop terminator during drop elaboration when the ""otherwise"" variants those without move paths have no drop glue. A common example of this scenario is when an `Option` is moved from since `Option::None` never needs drop glue. Below is a fragment the pre-codegen CFG for `Option::unwrap_or` in which we check the drop flag (`_5`) for `self` (`_1`) before and after the change. Before: ![image](https://user-images.githubusercontent.com/29463364/74078927-52942380-49e5-11ea-8e34-4b9d6d94ef25.png) After: ![image](https://user-images.githubusercontent.com/29463364/74078945-78b9c380-49e5-11ea-8302-b043c4a7515a.png) This change doesn't do much on its own but it is a prerequisite to get the perf gains from #68528. cc @arielb1",THUMBS_UP,2020-02-08T20:44:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68943,MERGED,2020-02-08T04:10:37Z,2020-03-01T07:53:47Z,Skip `Drop` terminators for enum variants without drop glue,ecstatic-morse,d9051341a1c142542a3f7dab509266606c775382,1,"Auto merge of #68943 - ecstatic-morse:no-useless-drop-on-enum-variants r=matthewjasper Skip `Drop` terminators for enum variants without drop glue Split out from #68528. When doing drop elaboration for an `enum` that may or may not be moved out of (an open drop) we check the discriminant of the `enum` to see whether the live variant has any drop flags and then check the drop flags to see whether we need to drop each field. Sometimes however the live variant has no move paths and thus no drop flags. In this case we still emit a drop terminator for the entire enum after checking the enum discriminant. This drop shim will check the discriminant of the enum *again* and then drop the fields of the active variant. If the active variant has no drop glue nothing will be done. This commit skips emitting the drop terminator during drop elaboration when the ""otherwise"" variants those without move paths have no drop glue. A common example of this scenario is when an `Option` is moved from since `Option::None` never needs drop glue. Below is a fragment the pre-codegen CFG for `Option::unwrap_or` in which we check the drop flag (`_5`) for `self` (`_1`) before and after the change. Before: ![image](https://user-images.githubusercontent.com/29463364/74078927-52942380-49e5-11ea-8e34-4b9d6d94ef25.png) After: ![image](https://user-images.githubusercontent.com/29463364/74078945-78b9c380-49e5-11ea-8302-b043c4a7515a.png) This change doesn't do much on its own but it is a prerequisite to get the perf gains from #68528. cc @arielb1",THUMBS_UP,2020-03-05T19:50:54Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68943,MERGED,2020-02-08T04:10:37Z,2020-03-01T07:53:47Z,Skip `Drop` terminators for enum variants without drop glue,ecstatic-morse,d9051341a1c142542a3f7dab509266606c775382,1,"Auto merge of #68943 - ecstatic-morse:no-useless-drop-on-enum-variants r=matthewjasper Skip `Drop` terminators for enum variants without drop glue Split out from #68528. When doing drop elaboration for an `enum` that may or may not be moved out of (an open drop) we check the discriminant of the `enum` to see whether the live variant has any drop flags and then check the drop flags to see whether we need to drop each field. Sometimes however the live variant has no move paths and thus no drop flags. In this case we still emit a drop terminator for the entire enum after checking the enum discriminant. This drop shim will check the discriminant of the enum *again* and then drop the fields of the active variant. If the active variant has no drop glue nothing will be done. This commit skips emitting the drop terminator during drop elaboration when the ""otherwise"" variants those without move paths have no drop glue. A common example of this scenario is when an `Option` is moved from since `Option::None` never needs drop glue. Below is a fragment the pre-codegen CFG for `Option::unwrap_or` in which we check the drop flag (`_5`) for `self` (`_1`) before and after the change. Before: ![image](https://user-images.githubusercontent.com/29463364/74078927-52942380-49e5-11ea-8e34-4b9d6d94ef25.png) After: ![image](https://user-images.githubusercontent.com/29463364/74078945-78b9c380-49e5-11ea-8302-b043c4a7515a.png) This change doesn't do much on its own but it is a prerequisite to get the perf gains from #68528. cc @arielb1",THUMBS_UP,2020-04-09T22:32:05Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/68943,MERGED,2020-02-08T04:10:37Z,2020-03-01T07:53:47Z,Skip `Drop` terminators for enum variants without drop glue,ecstatic-morse,d9051341a1c142542a3f7dab509266606c775382,1,"Auto merge of #68943 - ecstatic-morse:no-useless-drop-on-enum-variants r=matthewjasper Skip `Drop` terminators for enum variants without drop glue Split out from #68528. When doing drop elaboration for an `enum` that may or may not be moved out of (an open drop) we check the discriminant of the `enum` to see whether the live variant has any drop flags and then check the drop flags to see whether we need to drop each field. Sometimes however the live variant has no move paths and thus no drop flags. In this case we still emit a drop terminator for the entire enum after checking the enum discriminant. This drop shim will check the discriminant of the enum *again* and then drop the fields of the active variant. If the active variant has no drop glue nothing will be done. This commit skips emitting the drop terminator during drop elaboration when the ""otherwise"" variants those without move paths have no drop glue. A common example of this scenario is when an `Option` is moved from since `Option::None` never needs drop glue. Below is a fragment the pre-codegen CFG for `Option::unwrap_or` in which we check the drop flag (`_5`) for `self` (`_1`) before and after the change. Before: ![image](https://user-images.githubusercontent.com/29463364/74078927-52942380-49e5-11ea-8e34-4b9d6d94ef25.png) After: ![image](https://user-images.githubusercontent.com/29463364/74078945-78b9c380-49e5-11ea-8302-b043c4a7515a.png) This change doesn't do much on its own but it is a prerequisite to get the perf gains from #68528. cc @arielb1",THUMBS_UP,2020-04-21T21:42:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-03-04T10:12:16Z,RalfJung,NA https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-03-04T11:02:07Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-03-04T13:44:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-03-12T11:25:42Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-03-13T08:23:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-04-22T11:42:10Z,RomanAkberov,NA https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-04-23T15:56:22Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/68952,MERGED,2020-02-08T12:05:47Z,2020-03-04T10:45:34Z,Stabilize assoc_int_consts associated int/float constants,faern,7a3700c37132385e8e965c18e73d0a09f9146335,22,Auto merge of #68952 - faern:stabilize-assoc-int-consts r=dtolnay Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt,HOORAY,2020-04-23T17:31:32Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68960,MERGED,2020-02-08T17:29:35Z,2020-02-09T13:41:06Z,codegen: misc cleanups around debuginfo scopes and locations.,eddyb,bdb72e7b5ac304c918710ec5c968eaece7e6b57c,6,rustc_codegen_ssa: remove unnecessary source_locations_enabled.,HEART,2020-02-08T19:46:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/68961,MERGED,2020-02-08T17:34:07Z,2020-02-11T10:51:31Z,"rustc_codegen_ssa: only ""spill"" SSA-like values to the stack for debuginfo.",eddyb,1a8f5efab8ccd9d5f6ac794ab1bcf90b5efa536a,3,"rustc_codegen_ssa: only ""spill"" SSA-like values to the stack for debuginfo.",HEART,2020-02-08T19:05:57Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/68961,MERGED,2020-02-08T17:34:07Z,2020-02-11T10:51:31Z,"rustc_codegen_ssa: only ""spill"" SSA-like values to the stack for debuginfo.",eddyb,1a8f5efab8ccd9d5f6ac794ab1bcf90b5efa536a,3,"rustc_codegen_ssa: only ""spill"" SSA-like values to the stack for debuginfo.",HEART,2020-02-09T14:41:30Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68963,CLOSED,2020-02-08T17:46:31Z,2020-04-14T09:03:20Z,Correctly display raw identifier in notes and help messages,olegnn,NA,NA,NA,HEART,2020-02-08T18:31:01Z,estebank,NA https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-02-08T21:20:30Z,bjorn3,NA https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-02-08T22:00:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-02-08T23:57:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-02-18T00:36:17Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-06-27T17:48:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-10-27T02:10:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/68965,MERGED,2020-02-08T20:51:42Z,2020-10-26T21:18:27Z, rustc_mir: track inlined callees in SourceScopeData.,eddyb,0da6d42f297642a60f2640ec313b879b376b9ad8,68,Auto merge of #68965 - eddyb:mir-inline-scope r=nagisa oli-obk rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees which allows us to generate the correct debuginfo in codegen similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass if the MIR inliner is turned on by default. Also `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`,HEART,2020-10-27T17:31:10Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-08T22:03:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-08T22:04:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-08T22:09:28Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-08T23:23:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-02-08T23:23:58Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-10T07:21:53Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-02-10T07:21:54Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-10T11:04:33Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-02-10T13:32:49Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-11T04:28:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-13T14:54:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-02-14T15:09:29Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-14T22:11:06Z,estebank,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-02-15T15:49:36Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-03-09T18:11:09Z,sunny-g,sunny.gonna@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-18T18:58:04Z,amadeusine,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-26T12:05:09Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-03-26T12:29:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-26T13:49:50Z,cynecx,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-26T15:33:15Z,frol,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-03-26T21:01:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-27T06:30:02Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-03-27T07:13:01Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-04-21T20:36:02Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-04-22T17:06:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-04-22T17:06:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-06-20T03:42:49Z,m-hugo,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-06-21T12:27:10Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-08-20T06:48:48Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-08-26T02:43:02Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-08-26T02:43:02Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-09-04T14:49:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2020-10-03T17:04:59Z,tux3,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2020-10-03T17:05:05Z,tux3,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2021-02-24T02:47:34Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2021-02-24T16:14:39Z,TriedAngle,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2021-03-16T22:38:43Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2021-09-15T15:33:27Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2021-09-15T15:33:29Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2021-10-18T22:53:03Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2021-10-18T22:53:04Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HEART,2021-12-16T19:05:59Z,mankinskin,linusbehrbohm@web.de https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",THUMBS_UP,2021-12-28T16:19:55Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",HOORAY,2022-01-01T20:12:49Z,zyansheep,zyansheep@protonmail.com https://github.com/rust-lang/rust/pull/68970,MERGED,2020-02-08T22:01:54Z,2020-03-17T00:01:34Z,Implement a feature for a sound specialization subset,matthewjasper,e24252a12cd2b6adf8678255939156a2d178fe2a,48,"Auto merge of #68970 - matthewjasper:min-spec r=nikomatsakis Implement a feature for a sound specialization subset This implements a new feature (`min_specialization`) that restricts specialization to a subset that is reasonable for the standard library to use. The plan is to then: * Update `libcore` and `liballoc` to compile with `min_specialization`. * Add a lint to forbid use of `feature(specialization)` (and other unsound type system extending features) in the standard library. * Fix the soundness issues around `specialization`. * Remove `min_specialization` The rest of this is an overview from a comment in this PR ## Basic approach To enforce this requirement on specializations we take the following approach: 1. Match up the substs for `impl2` so that the implemented trait and self-type match those for `impl1`. 2. Check for any direct use of `'static` in the substs of `impl2`. 3. Check that all of the generic parameters of `impl1` occur at most once in the *unconstrained* substs for `impl2`. A parameter is constrained if its value is completely determined by an associated type projection predicate. 4. Check that all predicates on `impl1` also exist on `impl2` (after matching substs). ## Example Suppose we have the following always applicable impl: ```rust impl SpecExtend for std::vec::IntoIter { /* specialized impl */ } impl> SpecExtend for I { /* default impl */ } ``` We get that the subst for `impl2` are `[T std::vec::IntoIter]`. `T` is constrained to be `::Item` so we check only `std::vec::IntoIter` for repeated parameters which it doesn't have. The predicates of `impl1` are only `T: Sized` which is also a predicate of impl2`. So this specialization is sound. ## Extensions Unfortunately not all specializations in the standard library are allowed by this. So there are two extensions to these rules that allow specializing on some traits. ### rustc_specialization_trait If a trait is always applicable then it's sound to specialize on it. We check trait is always applicable in the same way as impls except that step 4 is now ""all predicates on `impl1` are always applicable"". We require that `specialization` or `min_specialization` is enabled to implement these traits. ### rustc_specialization_marker There are also some specialization on traits with no methods including the `FusedIterator` trait which is advertised as allowing optimizations. We allow marking marker traits with an unstable attribute that means we ignore them in point 3 of the checks above. This is unsound but we allow it in the short term because it can't cause use after frees with purely safe code in the same way as specializing on traits methods can. r? @nikomatsakis cc #31844 #67194",THUMBS_UP,2022-02-02T04:33:14Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-02-09T09:52:17Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-02-09T15:31:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-02-21T03:27:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-02-22T16:43:07Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-02-22T18:52:24Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/68984,MERGED,2020-02-09T05:33:34Z,2020-02-22T18:07:32Z,Make `u8::is_ascii` a stable `const fn`,ecstatic-morse,c261ff1a77f8d5d51d51efd028f937b20146adff,2,Rollup merge of #68984 - ecstatic-morse:const-u8-is-ascii r=sfackler Make `u8::is_ascii` a stable `const fn` `char::is_ascii` was already stabilized as `const fn` in #55278 so there is no reason for `u8::is_ascii` to go through an unstable period. cc @rust-lang/libs,THUMBS_UP,2020-04-21T21:12:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/68993,CLOSED,2020-02-09T13:26:04Z,2020-02-26T15:17:51Z,[WIP] polonius: adapt to the new fact format,amandasystems,NA,NA,NA,HOORAY,2020-02-10T17:10:40Z,lqd,NA https://github.com/rust-lang/rust/pull/68999,MERGED,2020-02-09T14:58:43Z,2020-02-12T13:17:27Z,remove dependency on itertools,andjo403,3b23d22e759268766eb803530da9b933879b8029,4,remove some dependencies on itertools,HEART,2020-02-09T15:26:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/68999,MERGED,2020-02-09T14:58:43Z,2020-02-12T13:17:27Z,remove dependency on itertools,andjo403,3b23d22e759268766eb803530da9b933879b8029,4,remove some dependencies on itertools,HEART,2020-02-09T18:14:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/68999,MERGED,2020-02-09T14:58:43Z,2020-02-12T13:17:27Z,remove dependency on itertools,andjo403,3b23d22e759268766eb803530da9b933879b8029,4,remove some dependencies on itertools,HEART,2020-02-10T08:33:50Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/68999,MERGED,2020-02-09T14:58:43Z,2020-02-12T13:17:27Z,remove dependency on itertools,andjo403,3b23d22e759268766eb803530da9b933879b8029,4,remove some dependencies on itertools,HEART,2020-02-11T19:28:48Z,mati865,NA https://github.com/rust-lang/rust/pull/69009,CLOSED,2020-02-09T23:50:06Z,2020-02-16T09:33:26Z,Make the inherent impl overlap check linear-time,jonas-schievink,NA,NA,NA,HOORAY,2020-02-09T23:52:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69011,MERGED,2020-02-10T00:50:58Z,2020-03-12T19:37:41Z,Document unsafe blocks in core::fmt,foeb,156a05a2e79620605a1b59435cba7dc6fc365131,3,Rollup merge of #69011 - foeb:document-unsafe-core-fmt r=Mark-Simulacrum Document unsafe blocks in core::fmt r? @RalfJung CC: @rust-lang/wg-unsafe-code-guidelines #66219 Sorry for the hiatus but here's a few more files with the unsafe blocks documented! I think working on it smaller chunks like this will be easier for everyone.,HEART,2020-02-25T19:52:07Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/69022,MERGED,2020-02-10T14:26:51Z,2020-02-11T20:48:42Z,traits: preallocate 2 Vecs of known initial size,ljedrz,b8893df8d344c11880c4aada639727fbfc195792,2,preallocate 2 Vecs in traits; tweak WfPredicates::normalize,HOORAY,2020-02-21T17:52:11Z,twilco,tyler.wilcock@protonmail.com https://github.com/rust-lang/rust/pull/69022,MERGED,2020-02-10T14:26:51Z,2020-02-11T20:48:42Z,traits: preallocate 2 Vecs of known initial size,ljedrz,b8893df8d344c11880c4aada639727fbfc195792,2,preallocate 2 Vecs in traits; tweak WfPredicates::normalize,HOORAY,2020-04-21T21:39:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69023,MERGED,2020-02-10T14:41:12Z,2020-02-13T12:53:59Z,parse: unify function front matter parsing,Centril,9828559aad8672bb320517bd0fa1992ce144b848,1,parser: is_fn_front_matter -> check_fn_front_matter,HEART,2020-02-10T17:29:59Z,panaman67,NA https://github.com/rust-lang/rust/pull/69026,MERGED,2020-02-10T16:04:49Z,2020-02-12T13:17:23Z,Remove common usage pattern from `AllocRef`,TimDiekmann,25de80ad232b84ce581fe67cc08b43e9db6b0b1f,3,Remove common usage pattern from `AllocRef`,HEART,2020-02-12T01:15:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/69026,MERGED,2020-02-10T16:04:49Z,2020-02-12T13:17:23Z,Remove common usage pattern from `AllocRef`,TimDiekmann,25de80ad232b84ce581fe67cc08b43e9db6b0b1f,3,Remove common usage pattern from `AllocRef`,HEART,2020-04-19T13:38:56Z,sirgl,NA https://github.com/rust-lang/rust/pull/69027,MERGED,2020-02-10T16:09:54Z,2020-02-12T13:17:22Z,Add missing `_zeroed` varants to `AllocRef`,TimDiekmann,97d1f8d9bbb6ae25d22f5193006becf37a57d226,1,Add missing `_zeroed` varants to `AllocRef`,THUMBS_UP,2020-02-20T22:17:34Z,Wodann,NA https://github.com/rust-lang/rust/pull/69029,CLOSED,2020-02-10T16:24:47Z,2020-03-11T17:22:20Z,[TEST] Defer evaluation of method receiver type,estebank,NA,NA,NA,HOORAY,2020-02-10T16:29:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69029,CLOSED,2020-02-10T16:24:47Z,2020-03-11T17:22:20Z,[TEST] Defer evaluation of method receiver type,estebank,NA,NA,NA,HOORAY,2020-02-13T22:33:12Z,sinkuu,NA https://github.com/rust-lang/rust/pull/69029,CLOSED,2020-02-10T16:24:47Z,2020-03-11T17:22:20Z,[TEST] Defer evaluation of method receiver type,estebank,NA,NA,NA,HOORAY,2020-02-15T14:36:18Z,cynecx,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:19:57Z,branan,branan@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:20:19Z,kevinmehall,contact@kevinmehall.net https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:20:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:20:51Z,tesuji,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:22:20Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:22:20Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:22:26Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:22:27Z,japaric,jorge@japaric.io https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:23:01Z,Thog,contact@mary.zone https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:23:04Z,Thog,contact@mary.zone https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:24:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:25:00Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:25:01Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:25:33Z,vbe0201,valentin.be@protonmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:28:02Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:36:00Z,Limeth,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:36:44Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:36:45Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:37:13Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:42:29Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:45:57Z,teburd,thomas.burdick@intel.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:45:59Z,teburd,thomas.burdick@intel.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:48:07Z,CryZe,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:48:08Z,CryZe,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:49:44Z,denzp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:49:49Z,denzp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:53:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:53:57Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:55:15Z,gardnervickers,gardner@vickers.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:56:45Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:56:46Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:57:34Z,cynecx,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:57:39Z,skippy10110,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T17:57:40Z,jpeddicord,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T17:57:41Z,jpeddicord,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:02:36Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T18:02:37Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T18:03:06Z,darksv,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:03:07Z,darksv,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T18:03:28Z,kprotty,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:03:38Z,kprotty,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:10:55Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T18:11:52Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:11:53Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:14:10Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T18:42:18Z,adigie,adrian.gielniewski@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T18:45:57Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T19:07:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T19:07:22Z,cramertj,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T19:13:00Z,Tiwalun,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T19:19:45Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T20:28:40Z,jacobrosenthal,jacobrosenthal@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T20:34:58Z,lqd,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T20:42:45Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T20:42:46Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-10T20:42:50Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T21:28:35Z,birktj,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T21:53:55Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T22:36:04Z,taiki-e,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T22:36:05Z,taiki-e,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-10T22:37:55Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T22:54:49Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T22:58:03Z,sinkuu,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-10T22:58:05Z,dwrensha,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T00:28:25Z,jaseemabid,jaseemabid@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T01:22:21Z,otavio,otavio@ossystems.com.br https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T01:22:23Z,otavio,otavio@ossystems.com.br https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T02:08:38Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-11T02:08:39Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T02:08:41Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T02:50:23Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T02:50:25Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T03:15:48Z,dotcypress,dotcypress@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-11T03:15:50Z,dotcypress,dotcypress@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T04:51:32Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T04:55:18Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T04:55:20Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T05:28:43Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T05:28:44Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-11T05:28:44Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-11T05:29:02Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T06:51:46Z,bkchr,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-11T11:04:36Z,berkus,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T12:10:20Z,95th,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-11T12:10:24Z,95th,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T12:10:30Z,95th,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T13:14:06Z,Hakuyume,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T13:19:16Z,pronvis,stanislav.pirx@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-11T13:19:17Z,pronvis,stanislav.pirx@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T20:38:11Z,overdrivenpotato,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-11T21:23:51Z,jarek-przygodzki,jarek.przygodzki@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-12T08:03:27Z,bb010g,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-12T08:03:35Z,bb010g,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-12T13:41:09Z,obmarg,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-12T13:41:11Z,obmarg,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-12T13:41:12Z,obmarg,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-13T23:57:29Z,Joshuaweiss,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-16T07:11:16Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-16T12:45:58Z,hberntsen,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-16T19:56:16Z,andrewreds,andrewreds@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-17T21:34:16Z,vgarleanu,valerian@dusklabs.io https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-18T12:15:18Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-18T12:15:20Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-18T12:15:21Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-18T12:15:21Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-18T14:25:49Z,chpio,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-18T14:25:51Z,chpio,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-20T19:15:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-21T08:51:44Z,kvinwang,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-21T08:51:48Z,kvinwang,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-23T05:05:49Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-23T05:05:52Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-23T05:05:53Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-23T11:28:37Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-23T11:28:40Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-23T11:28:40Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-23T11:28:41Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-23T13:33:03Z,nspin,nick@nickspinale.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-24T01:20:46Z,reynoldsbd,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-24T16:27:43Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-27T23:24:37Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-28T08:42:30Z,kpp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-28T08:42:32Z,kpp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-28T08:42:35Z,kpp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-02-29T12:02:54Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-02-29T12:02:54Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-02-29T12:02:55Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-02-29T12:02:56Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-02-29T12:04:16Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-01T02:10:15Z,matthunz,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-04T14:10:56Z,sindrehan,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-04T14:22:28Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-04T15:15:54Z,wose,wose@zuendmasse.de https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-04T16:41:21Z,sticnarf,sticnarf@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-04T16:54:44Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-04T16:54:46Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-04T16:54:49Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-04T22:45:04Z,lights0123,developer@lights0123.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-05T02:33:55Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-05T08:58:51Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-05T10:51:43Z,dbrgn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-03-05T16:34:07Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-03-05T16:34:10Z,eupn,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-05T21:27:31Z,MarkSwanson,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-06T06:35:35Z,rrbutani,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-06T06:35:40Z,rrbutani,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-06T06:35:43Z,rrbutani,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-06T13:30:34Z,lambdabear,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-07T16:46:49Z,harrysarson,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-09T13:55:36Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-03-09T13:55:37Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-09T13:55:37Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-09T13:55:38Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-09T13:55:38Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-03-09T13:55:40Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-10T22:21:44Z,brainstorm,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-10T22:21:45Z,brainstorm,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-10T22:21:45Z,brainstorm,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-10T22:21:46Z,brainstorm,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-11T16:40:57Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-11T16:40:59Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-12T09:26:32Z,andoks,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-12T09:26:32Z,andoks,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-12T09:26:34Z,andoks,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-12T20:43:10Z,adamgreig,adam@adamgreig.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-13T01:20:16Z,flosse,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-13T01:20:21Z,flosse,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-13T09:16:44Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-13T11:10:53Z,NickeZ,niklas@dusenlund.se https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-13T11:10:54Z,NickeZ,niklas@dusenlund.se https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-13T11:10:54Z,NickeZ,niklas@dusenlund.se https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-14T14:54:58Z,MabezDev,scott@mabez.dev https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-14T16:16:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-14T16:16:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-14T18:58:27Z,MarkSwanson,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-15T09:28:27Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-15T13:09:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-15T13:09:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-15T20:49:10Z,macpp,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-16T09:26:48Z,iwa13,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-17T19:10:19Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-17T21:39:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-17T21:39:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-17T22:16:22Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-03-18T15:37:27Z,icewind1991,robin@icewind.nl https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-19T21:57:45Z,dotcypress,dotcypress@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-20T04:57:24Z,mwilliammyers,mwilliammyers@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-20T05:23:52Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-20T07:24:10Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-20T07:24:11Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-20T17:44:38Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-20T17:44:39Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-20T17:44:40Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-20T17:44:41Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-20T18:55:01Z,rubberduck203,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T08:09:41Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T09:14:24Z,termoshtt,toshiki.teramura@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-21T11:03:17Z,alsuren,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-21T11:03:55Z,gakonst,me@gakonst.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T12:08:38Z,frol,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-21T12:08:40Z,frol,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-21T12:08:42Z,frol,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-21T13:09:09Z,gliderkite,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T14:12:52Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T14:13:00Z,vbe0201,valentin.be@protonmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-21T14:39:37Z,0xd34d10cc,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T15:50:16Z,ryanisaacg,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-21T19:05:39Z,tinou98,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-21T19:05:41Z,tinou98,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-21T20:36:29Z,Ralith,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-22T00:54:11Z,amadeusine,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-22T13:05:43Z,luben,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-22T13:14:04Z,meh,meh@schizofreni.co https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-22T16:22:23Z,lnicola,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-22T20:55:57Z,K900,me@0upti.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-03-22T20:55:59Z,K900,me@0upti.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-22T21:19:46Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-22T23:21:54Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-03-22T23:21:55Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-23T01:12:48Z,yerke,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-23T01:12:50Z,yerke,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-03-23T01:12:53Z,yerke,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-23T10:13:00Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-26T13:54:14Z,Diggsey,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-03-26T13:54:16Z,Diggsey,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-26T16:09:48Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-26T17:50:34Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-27T07:11:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-03-27T12:23:12Z,Thomasdezeeuw,thomasdezeeuw@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-03-28T08:04:27Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-04-03T14:18:18Z,I60R,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-04-03T14:18:20Z,I60R,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-04-03T15:14:34Z,95th,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-04-03T16:53:25Z,est31,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-04-03T21:41:57Z,Angr1st,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-04-03T22:11:26Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-04-03T22:11:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-04-03T22:11:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-04-03T22:11:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-04-03T22:11:33Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-04-03T22:11:34Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-04-04T04:45:12Z,tocubed,tocubed@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-04-18T12:31:40Z,arlyon,arlyon@me.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-04-30T20:40:59Z,nui,narongwet.m@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-02T06:57:03Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-05-02T06:57:07Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-05-02T08:41:13Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-02T12:11:31Z,axelf4,axelsfor@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-03T04:11:51Z,yannsun,sunjinliang1992@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-05T20:36:45Z,kornholi,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-05T22:57:05Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-05-05T22:57:08Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-05-06T03:52:04Z,wrmsr,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-05-18T08:39:06Z,folex,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-05-19T10:53:37Z,moshg,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-05-22T13:40:41Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-05-30T09:05:04Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-05-30T19:49:21Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-02T07:08:50Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-04T19:31:49Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-06-04T19:31:50Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-04T19:31:53Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-04T19:31:54Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-06-04T19:31:56Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-06-04T19:31:58Z,stephenlb,stephen@pubnub.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-04T21:41:34Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-04T23:00:45Z,DianaNites,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-04T23:00:46Z,DianaNites,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-05T02:08:32Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-05T05:53:44Z,guiguan,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T06:05:49Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T06:53:58Z,coinwalletdev,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-05T07:35:00Z,katyo,kayo@illumium.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-06-05T07:35:09Z,katyo,kayo@illumium.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-05T07:35:11Z,katyo,kayo@illumium.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T07:35:14Z,katyo,kayo@illumium.org https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T08:22:01Z,hamidr,hrdavodi@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T09:07:24Z,marcelbuesing,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-05T10:08:14Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-05T15:13:26Z,fudanchii,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-05T15:13:28Z,fudanchii,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-06-05T15:13:29Z,fudanchii,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-06T05:08:44Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-06T05:08:47Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-06T05:08:51Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-06-06T05:08:54Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-06-06T05:08:56Z,redradist,redradist@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-08T07:49:27Z,Gui-Yom,guillaume.anthouard@hotmail.fr https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-08T17:06:08Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-06-12T09:46:07Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-12T09:46:08Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-12T09:46:09Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-06-12T09:46:10Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2020-06-12T09:46:10Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2020-06-12T09:46:10Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-06-12T23:43:41Z,Yam76,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-20T16:13:40Z,qrnch-jan,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2020-06-26T05:36:50Z,leodutra,leodutra.br@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2020-06-26T05:36:51Z,leodutra,leodutra.br@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-07-06T20:47:20Z,g-berthiaume,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-07-07T15:11:47Z,Folyd,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-07-15T15:15:43Z,COSTEMaxime,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2020-08-08T20:03:29Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2020-12-31T15:44:29Z,wanderanimrod,NA https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,THUMBS_UP,2021-03-08T11:34:46Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,LAUGH,2021-03-08T11:34:53Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HOORAY,2021-03-08T11:34:53Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,HEART,2021-03-08T11:34:55Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,ROCKET,2021-03-08T11:34:56Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69033,MERGED,2020-02-10T17:17:28Z,2020-03-21T07:47:46Z,Use generator resume arguments in the async/await lowering,jonas-schievink,ef7c8a158f5bb36e3f5b96eacc196061e8ab9d10,9,Rollup merge of #69033 - jonas-schievink:resume-with-context r=tmandry Use generator resume arguments in the async/await lowering This removes the TLS requirement from async/await and enables it in `#![no_std]` crates. Closes https://github.com/rust-lang/rust/issues/56974 I'm not confident the HIR lowering is completely correct there seem to be quite a few undocumented invariants in there. The `async-std` and tokio test suites are passing with these changes though.,EYES,2021-03-08T11:34:57Z,rokinsky,ankezy@gmail.com https://github.com/rust-lang/rust/pull/69036,MERGED,2020-02-10T18:11:39Z,2020-03-19T09:15:17Z,rustc: don't resolve Instances which would produce malformed shims.,eddyb,ffb3c2cb3d2081d295dab9ca38f3a5e1e13c863d,3,"Rollup merge of #69036 - eddyb:monoshim r=nikomatsakis rustc: don't resolve Instances which would produce malformed shims. There are some `InstanceDef` variants (shims and drop ""glue"") which contain a `Ty` and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters the generated shim would refer to them (but they won't match the `Substs` of the `Instance`) or worse generating the shim would fail because not enough of the type is known. Ideally we would always produce a ""skeleton"" of the type e.g. `(_ _)` for dropping any tuples with two elements or `Vec<_>` for dropping any `Vec` value but that's a lot of work and they would still not match the `Substs` of the `Instance` as it exists today so `Instance` would probably need to change. By making `Instance::resolve` return `None` in the still-generic cases we get behavior similar to specialization where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match.
This was found while testing the MIR inliner with #68965 because it was trying to inline shims. cc @rust-lang/wg-mir-opt",THUMBS_UP,2020-03-11T14:21:42Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/69044,MERGED,2020-02-10T23:28:28Z,2020-02-11T20:48:36Z,Don't run coherence twice for future-compat lints,jonas-schievink,f66793757fd1cdfa6098ec1b8532ba0382792c4d,1,Don't run coherence twice for future-compat lints,THUMBS_UP,2020-02-11T00:59:50Z,tmandry,NA https://github.com/rust-lang/rust/pull/69044,MERGED,2020-02-10T23:28:28Z,2020-02-11T20:48:36Z,Don't run coherence twice for future-compat lints,jonas-schievink,f66793757fd1cdfa6098ec1b8532ba0382792c4d,1,Don't run coherence twice for future-compat lints,THUMBS_UP,2020-02-20T16:04:27Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/69044,MERGED,2020-02-10T23:28:28Z,2020-02-11T20:48:36Z,Don't run coherence twice for future-compat lints,jonas-schievink,f66793757fd1cdfa6098ec1b8532ba0382792c4d,1,Don't run coherence twice for future-compat lints,THUMBS_UP,2020-04-21T21:40:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69048,MERGED,2020-02-11T03:14:53Z,2020-02-13T08:12:11Z,Suggestion when encountering assoc types from hrtb,estebank,bde96776a199064dec3c825ca5ada8f90e1e12d4,3,Suggest named lifetime in ADT with hrtb,HEART,2020-02-11T04:24:00Z,tesuji,NA https://github.com/rust-lang/rust/pull/69048,MERGED,2020-02-11T03:14:53Z,2020-02-13T08:12:11Z,Suggestion when encountering assoc types from hrtb,estebank,bde96776a199064dec3c825ca5ada8f90e1e12d4,3,Suggest named lifetime in ADT with hrtb,HEART,2020-02-11T11:32:57Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/69048,MERGED,2020-02-11T03:14:53Z,2020-02-13T08:12:11Z,Suggestion when encountering assoc types from hrtb,estebank,bde96776a199064dec3c825ca5ada8f90e1e12d4,3,Suggest named lifetime in ADT with hrtb,HEART,2020-02-27T22:41:32Z,otavio,otavio@ossystems.com.br https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,LAUGH,2020-02-11T09:01:02Z,mati865,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-11T09:09:00Z,bjorn3,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-11T17:05:20Z,panaman67,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,LAUGH,2020-02-11T18:24:49Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-11T18:24:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,LAUGH,2020-02-13T02:50:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T11:38:25Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T14:01:35Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T14:50:01Z,krishnachittur,krishna@chittur.dev https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T15:54:56Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T15:56:38Z,SugaR256,kuba.krapiec@outlook.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,LAUGH,2020-02-13T15:56:38Z,SugaR256,kuba.krapiec@outlook.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HEART,2020-02-13T15:56:41Z,SugaR256,kuba.krapiec@outlook.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-13T18:23:31Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-15T21:00:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HEART,2020-02-15T21:00:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HOORAY,2020-02-21T09:12:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HEART,2020-03-05T18:38:51Z,cztomsik,info@tomsik.cz https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HEART,2020-04-24T12:34:08Z,0rvar,orvarsegerstrom@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,LAUGH,2020-05-01T11:51:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69050,MERGED,2020-02-11T08:10:31Z,2020-02-13T08:12:09Z,Micro-optimize the heck out of LEB128 reading and writing.,nnethercote,ad7802f9d45b884dad58931c7a8bec91d196ad0e,1,Micro-optimize the heck out of LEB128 reading and writing. This commit makes the following writing improvements: - Removes the unnecessary `write_to_vec` function. - Reduces the number of conditions per loop from 2 to 1. - Avoids a mask and a shift on the final byte. And the following reading improvements: - Removes an unnecessary type annotation. - Fixes a dangerous unchecked slice access. Imagine a slice `[0x80]` -- the current code will read past the end of the slice some number of bytes. The bounds check at the end will subsequently trigger unless something bad (like a crash) happens first. The cost of doing bounds check in the loop body is negligible. - Avoids a mask on the final byte. And the following improvements for both reading and writing: - Changes `for` to `loop` for the loops avoiding an unnecessary condition on each iteration. This also removes the need for `leb128_size`. All of these changes give significant perf wins up to 5%.,HEART,2021-09-07T21:18:55Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/69057,MERGED,2020-02-11T11:51:08Z,2020-02-14T01:38:04Z,expand: misc cleanups and simplifications,Centril,ec434500157c47143a9b5600a7e34522c49f4e8e,1,expand: simplify flat_map_item wrt. inline module detection,HEART,2020-02-11T17:04:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/69058,MERGED,2020-02-11T12:17:20Z,2020-02-12T13:17:17Z,Preparation for allocator aware `Box`,TimDiekmann,76aa29ff5e5a6bb355b017da4f6e476049b8dd76,2,Preparation for allocator aware `Box`,THUMBS_UP,2020-02-20T22:16:58Z,Wodann,NA https://github.com/rust-lang/rust/pull/69058,MERGED,2020-02-11T12:17:20Z,2020-02-12T13:17:17Z,Preparation for allocator aware `Box`,TimDiekmann,76aa29ff5e5a6bb355b017da4f6e476049b8dd76,2,Preparation for allocator aware `Box`,THUMBS_UP,2020-02-21T01:03:03Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69059,MERGED,2020-02-11T12:46:46Z,2020-02-12T19:31:57Z,Remove a few unused objects,ljedrz,d8544ce2484553f6397d8986b582181a2e761360,2,remove some unused objects,HEART,2020-02-11T17:02:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-11T19:42:25Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-11T23:36:10Z,estebank,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,ROCKET,2020-02-11T23:36:12Z,estebank,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-11T23:53:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-12T01:27:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-12T15:02:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-02-13T02:49:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69072,MERGED,2020-02-11T19:37:41Z,2020-02-21T02:15:44Z,O(log n) lookup of associated items by name,ecstatic-morse,d3ebd592d0024994c4661807c925e20a018238b3,35,Auto merge of #69072 - ecstatic-morse:associated-items r=petrochenkov O(log n) lookup of associated items by name Resolves #68957 in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result the pathological case from that issue now runs in 8 seconds on my local machine as opposed to many minutes on the current stable. Currently method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used e.g. for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup we first find all items with the same `Symbol` using binary search then run hygienic comparison to find the one we are looking for. Ideally this would be implemented using an insertion-order preserving hash-based multi-map but one is not readily available. Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly even if it seemed strange (I left at least one FIXME to this effect). For example some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.,THUMBS_UP,2020-03-03T05:53:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69079,MERGED,2020-02-11T23:44:02Z,2020-03-22T21:40:10Z,Allow calculating the layout behind a pointer,CAD97,d1e81ef234ff5c2e0e3a69cb4e8e5f5b0fe1fd83,4,"Auto merge of #69079 - CAD97:layout-of-ptr r=RalfJung Allow calculating the layout behind a pointer There was some discussion around allowing this previously. This does make the requirement for raw pointers to have valid metadata exposed as part of the std API (as a safety invariant not validity invariant) though I think this is not strictly necessarily required as of current. cc @rust-lang/wg-unsafe-code-guidelines Naming is hard; I picked the best ""obvious"" name I could come up with. If it's agreed that this is actually a desired API surface I'll file a tracking issue and update the attributes.",HOORAY,2020-03-27T07:01:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69079,MERGED,2020-02-11T23:44:02Z,2020-03-22T21:40:10Z,Allow calculating the layout behind a pointer,CAD97,d1e81ef234ff5c2e0e3a69cb4e8e5f5b0fe1fd83,4,"Auto merge of #69079 - CAD97:layout-of-ptr r=RalfJung Allow calculating the layout behind a pointer There was some discussion around allowing this previously. This does make the requirement for raw pointers to have valid metadata exposed as part of the std API (as a safety invariant not validity invariant) though I think this is not strictly necessarily required as of current. cc @rust-lang/wg-unsafe-code-guidelines Naming is hard; I picked the best ""obvious"" name I could come up with. If it's agreed that this is actually a desired API surface I'll file a tracking issue and update the attributes.",HOORAY,2021-11-16T14:37:14Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/69080,MERGED,2020-02-12T00:44:39Z,2020-03-23T12:40:31Z,rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.,eddyb,198024286ae7429e98d44fc290dee5f1eaf4aba1,4,Rollup merge of #69080 - eddyb:one-billion-dwarves-walk-into-a-bar r=michaelwoerister rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1. Works towards #69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm` bringing us in line with what `clang -g1` generates (no debuginfo types nor debuginfo for `static`s).
My local build's (`debuginfo-level=1` `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB. It's still bad but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB i.e. roughly a 3.6x reduction.
Sadly I don't think this is enough to justify *shipping* all of this debuginfo but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it. That would give us real backtraces for e.g. ICEs during builds but I don't know how often that's relevant. We could also look into split DWARF and maybe have a `rustc-debuginfo` component in `rustup`. There's also the possibility of making it slimmer by omitting parameters to functions or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?). r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum,THUMBS_UP,2020-02-12T08:30:18Z,mati865,NA https://github.com/rust-lang/rust/pull/69081,CLOSED,2020-02-12T00:46:39Z,2020-04-24T22:45:42Z,Support static linking LLVM with ThinLTO,tmandry,NA,NA,NA,THUMBS_UP,2020-04-18T20:18:55Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/69097,MERGED,2020-02-12T14:50:17Z,2020-02-13T04:57:42Z,Update RLS and Rustfmt,Xanewok,8fc4bba2c457796b28da604160da90750f3695da,3,Update RLS and Rustfmt Bumps rustc-ap-* packages to v642.,HOORAY,2020-02-12T14:53:58Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/69097,MERGED,2020-02-12T14:50:17Z,2020-02-13T04:57:42Z,Update RLS and Rustfmt,Xanewok,8fc4bba2c457796b28da604160da90750f3695da,3,Update RLS and Rustfmt Bumps rustc-ap-* packages to v642.,HEART,2020-02-13T05:11:51Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/69097,MERGED,2020-02-12T14:50:17Z,2020-02-13T04:57:42Z,Update RLS and Rustfmt,Xanewok,8fc4bba2c457796b28da604160da90750f3695da,3,Update RLS and Rustfmt Bumps rustc-ap-* packages to v642.,HEART,2020-02-14T06:19:09Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/69113,MERGED,2020-02-12T22:55:12Z,2020-02-19T08:07:53Z,Combine `HaveBeenBorrowedLocals` and `IndirectlyMutableLocals` into one dataflow analysis,ecstatic-morse,077a93c6a9b1c8ee0e541ea484f7e13c207d50d0,1,Fix typo in comment,ROCKET,2020-02-19T00:21:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69115,MERGED,2020-02-12T23:23:31Z,2020-02-14T23:11:09Z,Update books.,ehuss,1e1b6ad1084783b4d6b21e9c6e79f114991f3dab,9,Update books.,THUMBS_UP,2020-02-13T22:54:37Z,awulkan,NA https://github.com/rust-lang/rust/pull/69119,CLOSED,2020-02-13T02:48:46Z,2020-02-13T07:39:03Z,Fix box_region.rs,lebensterben,NA,NA,NA,EYES,2020-02-13T03:27:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/69128,MERGED,2020-02-13T11:24:07Z,2020-02-15T02:24:10Z,Fix extra subslice lowering,Centril,f5bd9646be31d865a083193c21c7448d546ce07c,3,fix extra subslice lowering,THUMBS_UP,2020-02-13T18:26:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69129,MERGED,2020-02-13T13:01:22Z,2020-02-17T15:07:06Z,Transition macro_legacy_warnings into a hard error,Centril,cec2a9fad057f71fc640392ba3fa47602aea12f6,7,macro_legacy_warnings -> error,HOORAY,2020-02-13T22:26:18Z,estebank,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-02-13T20:49:38Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-13T20:59:18Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-13T21:22:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-14T00:45:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-14T04:13:07Z,tesuji,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-02-14T04:13:08Z,tesuji,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-17T09:35:49Z,95th,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-02-20T19:17:14Z,panaman67,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-02-20T21:21:08Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-28T18:27:17Z,ilyavenner,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-28T20:23:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-02-29T08:14:06Z,SOF3,sofe2038@gmail.com https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-02-29T08:14:09Z,SOF3,sofe2038@gmail.com https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-03-01T10:36:35Z,Dmitry-Borodin,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HEART,2020-03-01T17:07:15Z,eupn,NA https://github.com/rust-lang/rust/pull/69145,MERGED,2020-02-13T20:35:56Z,2020-02-20T19:17:11Z,Fix MIR typeck soundness holes,matthewjasper,bfb96048b5946e8c695790ae66ca105cb78da60b,7,Auto merge of #69145 - matthewjasper:mir-typeck-static-ty r=nikomatsakis Fix MIR typeck soundness holes * Check types of static items * Always check lifetime bounds of `Copy` impls r? @nikomatsakis closes #69114,HOORAY,2020-03-01T17:07:16Z,eupn,NA https://github.com/rust-lang/rust/pull/69152,CLOSED,2020-02-14T01:53:33Z,2020-03-11T21:26:18Z,Speed up `DefaultHasher` `SipHasher` and `SipHasher13`.,nnethercote,NA,NA,NA,HEART,2020-02-14T05:13:16Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/69152,CLOSED,2020-02-14T01:53:33Z,2020-03-11T21:26:18Z,Speed up `DefaultHasher` `SipHasher` and `SipHasher13`.,nnethercote,NA,NA,NA,HEART,2020-02-14T09:30:27Z,CryZe,NA https://github.com/rust-lang/rust/pull/69152,CLOSED,2020-02-14T01:53:33Z,2020-03-11T21:26:18Z,Speed up `DefaultHasher` `SipHasher` and `SipHasher13`.,nnethercote,NA,NA,NA,ROCKET,2020-02-19T00:20:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69156,MERGED,2020-02-14T04:44:26Z,2020-02-16T08:43:31Z,Use `ResultsCursor` for `elaborate_drops`,ecstatic-morse,26451d007e7482f0c4cdae152a972f4e7c8bf970,1,Print flow state in debug messages for `find_dead_unwinds`,HEART,2020-02-14T05:46:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/69164,MERGED,2020-02-14T10:09:35Z,2020-02-15T02:24:03Z,Update pulldown-cmark dependency,GuillaumeGomez,d8589de1f05fdf84016ad8b6fa1d14a076385b90,3,Update pulldown-cmark dependency,HOORAY,2020-02-14T10:49:41Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/69167,CLOSED,2020-02-14T13:33:26Z,2022-01-08T22:32:40Z,rustdoc: Add flag to use external source code pages,GuillaumeGomez,NA,NA,NA,HOORAY,2020-02-14T13:46:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/69167,CLOSED,2020-02-14T13:33:26Z,2022-01-08T22:32:40Z,rustdoc: Add flag to use external source code pages,GuillaumeGomez,NA,NA,NA,HOORAY,2020-02-19T00:19:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69168,MERGED,2020-02-14T13:40:10Z,2020-02-15T17:06:16Z,add regression test for issue #68794,brainlock,ea2ffda44e0c38854dbe63c786a194dd35559545,3,"add regression test for issue #68794 This is a minimal regression test for the issue #68794: ""TEXTREL in i686"" which was fixed with e86019c4a0968a1e393cdd0731649168624a88b8. The test links a minimal rust static library into a shared library and checks that the linker didn't have to add the TEXTREL flag.",THUMBS_UP,2020-02-15T01:54:48Z,tmandry,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-15T01:03:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-02-15T01:38:33Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-15T04:47:27Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-15T14:44:41Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-15T20:13:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-02-15T20:13:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-02-15T21:34:25Z,macpp,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-16T00:41:11Z,dlight,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-02-16T17:00:30Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-16T17:00:36Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-02-16T23:38:18Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-17T09:31:08Z,95th,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-02-18T07:35:57Z,comex,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-02-19T00:22:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-02-19T00:22:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-02-28T15:44:06Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-03-05T21:56:28Z,yerke,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-03-05T21:56:28Z,yerke,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-03-10T07:06:13Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-03-10T07:06:13Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-03-10T07:06:13Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-03-10T07:06:13Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-03-12T20:00:11Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-03-18T02:29:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-03-20T16:01:31Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-03-20T16:01:31Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-03-21T09:52:18Z,ljedrz,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-03-30T15:46:57Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-04-04T16:19:33Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-04-04T16:19:34Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-04-04T16:19:35Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-04-04T16:19:36Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-04-04T16:19:37Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-04-09T00:58:28Z,lu-zero,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-04-21T16:47:29Z,qwerty19106,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-04-25T09:43:58Z,darksv,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-04-25T09:44:00Z,darksv,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-04-25T09:44:01Z,darksv,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-04-25T09:44:03Z,darksv,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-04-25T09:44:51Z,darksv,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-04-30T06:03:34Z,qwerty19106,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-04-30T06:03:42Z,qwerty19106,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-01T22:33:46Z,Yura52,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-01T23:17:08Z,tmandry,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-02T13:11:34Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-06T16:37:31Z,bluss,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-08T21:28:14Z,l4l,mail@kitsu.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-16T18:49:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-16T18:49:54Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-16T18:49:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-16T18:49:56Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-19T21:59:48Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T03:14:24Z,95th,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T03:14:26Z,95th,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T03:14:29Z,95th,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T04:06:34Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T04:56:39Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T09:00:26Z,frol,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T09:17:23Z,LukeMathWalker,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T09:17:23Z,LukeMathWalker,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T09:36:21Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T11:39:35Z,gburd,greg@burd.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T11:53:08Z,nicklauri,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T11:53:09Z,nicklauri,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T11:53:31Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T11:53:31Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T11:53:32Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T11:53:35Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T11:53:37Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T11:54:34Z,lexxvir,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T12:08:23Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T12:08:25Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T12:08:26Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T12:08:28Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T12:34:48Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T13:15:21Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T13:15:21Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T13:15:22Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T13:15:25Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T13:25:38Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T13:25:38Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T13:29:07Z,sunjay,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T13:29:09Z,sunjay,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T13:29:10Z,sunjay,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T13:29:12Z,sunjay,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T13:29:13Z,sunjay,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T13:32:50Z,CPerezz,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T13:32:52Z,Phridge,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T13:58:41Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T14:02:01Z,discosultan,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T14:14:34Z,Fourchaux,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T14:41:35Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T14:41:35Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T14:41:38Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T14:41:40Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T14:42:43Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T14:42:44Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T14:46:05Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T14:57:09Z,benhansenslc,github@benjamin-hansen.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T15:31:30Z,kpp,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T15:43:01Z,quetz,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T15:43:03Z,quetz,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T16:00:59Z,pvdrz,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T16:02:46Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T16:09:47Z,gentoid,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T16:22:08Z,tux3,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T16:25:18Z,ecruzolivera,ernesto@ecruzolivera.tech https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T16:28:31Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T16:32:47Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T18:09:49Z,PriteshJain,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T19:33:03Z,not-matthias,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T20:06:44Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T20:44:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T20:44:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T21:25:04Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T21:25:04Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T21:25:05Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T21:25:06Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T21:25:06Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-20T22:53:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-20T22:53:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-20T22:53:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-20T22:53:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-20T22:53:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-21T01:19:47Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-21T05:00:52Z,schulzch,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-21T08:28:21Z,jhgg,me@jh.gg https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-21T09:09:38Z,bytebaendiger,nermax03@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-21T09:50:34Z,Oodachi,yujinjianxin@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-21T09:50:36Z,Oodachi,yujinjianxin@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-21T09:50:38Z,Oodachi,yujinjianxin@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-21T11:51:02Z,westernmagic,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-21T20:28:28Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-21T22:38:51Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-21T22:38:53Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-22T08:44:42Z,elpiel,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-23T15:43:27Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-23T15:43:28Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-23T15:43:29Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-05-23T15:43:29Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-05-23T15:43:30Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-05-27T22:35:36Z,harrysarson,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-29T05:29:11Z,ejpcmac,jean-philippe@cugnet.eu https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-29T13:53:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-05-31T03:15:01Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-05-31T03:15:08Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-06-02T06:05:24Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-06-04T23:00:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-06-04T23:00:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-06-04T23:00:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-06-04T23:00:55Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2020-06-04T23:00:56Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2020-06-10T13:47:13Z,orao,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2020-07-21T01:31:38Z,ohAitch,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-08-01T13:01:26Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-08-20T03:06:41Z,814471424,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2020-10-11T22:38:18Z,bstrie,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2020-10-27T09:29:12Z,ufoscout,ufoscout@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_DOWN,2021-01-06T04:38:09Z,xxscloud5722,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2021-02-13T08:53:12Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2021-03-10T21:30:39Z,a1phyr,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",THUMBS_UP,2021-08-22T23:28:32Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HOORAY,2021-08-22T23:28:34Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",ROCKET,2021-08-22T23:28:35Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",EYES,2021-08-22T23:28:35Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/69171,MERGED,2020-02-14T21:02:49Z,2020-05-19T21:57:03Z,Implement new asm! syntax from RFC 2850,Amanieu,3a7dfda40a3e798bf086bd58cc7e5e09deb808b5,140,"Auto merge of #69171 - Amanieu:new-asm r=nagisa nikomatsakis Implement new asm! syntax from RFC 2850 This PR implements the new `asm!` syntax proposed in https://github.com/rust-lang/rfcs/pull/2850. # Design A large part of this PR revolves around taking an `asm!` macro invocation and plumbing it through all of the compiler layers down to LLVM codegen. Throughout the various stages an `InlineAsm` generally consists of 3 components: - The template string which is stored as an array of `InlineAsmTemplatePiece`. Each piece represents either a literal or a placeholder for an operand (just like format strings). ```rust pub enum InlineAsmTemplatePiece { String(String) Placeholder { operand_idx: usize modifier: Option span: Span } } ``` - The list of operands to the `asm!` (`in` `[late]out` `in[late]out` `sym` `const`). These are represented differently at each stage of lowering but follow a common pattern: - `in` `out` and `inout` all have an associated register class (`reg`) or explicit register (`""eax""`). - `inout` has 2 forms: one with a single expression that is both read from and written to and one with two separate expressions for the input and output parts. - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register allocator is allowed to reuse an input register for this output. - `out` and the split variant of `inout` allow `_` to be specified for an output which means that the output is discarded. This is used to allocate scratch registers for assembly code. - `sym` is a bit special since it only accepts a path expression which must point to a `static` or a `fn`. - The options set at the end of the `asm!` macro. The only one that is particularly of interest to rustc is `NORETURN` which makes `asm!` return `!` instead of `()`. ```rust bitflags::bitflags! { pub struct InlineAsmOptions: u8 { const PURE = 1 << 0; const NOMEM = 1 << 1; const READONLY = 1 << 2; const PRESERVES_FLAGS = 1 << 3; const NORETURN = 1 << 4; const NOSTACK = 1 << 5; } } ``` ## AST `InlineAsm` is represented as an expression in the AST: ```rust pub struct InlineAsm { pub template: Vec pub operands: Vec<(InlineAsmOperand Span)> pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(Symbol) RegClass(Symbol) } pub enum InlineAsmOperand { In { reg: InlineAsmRegOrRegClass expr: P } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: P } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: P out_expr: Option> } Const { expr: P } Sym { expr: P } } ``` The `asm!` macro is implemented in librustc_builtin_macros and outputs an `InlineAsm` AST node. The template string is parsed using libfmt_macros positional and named operands are resolved to explicit operand indicies. Since target information is not available to macro invocations validation of the registers and register classes is deferred to AST lowering. ## HIR `InlineAsm` is represented as an expression in the HIR: ```rust pub struct InlineAsm<'hir> { pub template: &'hir [InlineAsmTemplatePiece] pub operands: &'hir [InlineAsmOperand<'hir>] pub options: InlineAsmOptions } pub enum InlineAsmRegOrRegClass { Reg(InlineAsmReg) RegClass(InlineAsmRegClass) } pub enum InlineAsmOperand<'hir> { In { reg: InlineAsmRegOrRegClass expr: Expr<'hir> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: Expr<'hir> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: Expr<'hir> out_expr: Option> } Const { expr: Expr<'hir> } Sym { expr: Expr<'hir> } } ``` AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or register class. If any modifiers are specified for a template string placeholder these are validated against the set allowed for that operand type. Finally explicit registers for inputs and outputs are checked for conflicts (same register used for different operands). ## Type checking Each register class has a whitelist of types that it may be used with. After the types of all operands have been determined the `intrinsicck` pass will check that these types are in the whitelist. It also checks that split `inout` operands have compatible types and that `const` operands are integers or floats. Suggestions are emitted where needed if a template modifier should be used for an operand based on the type that was passed into it. ## HAIR `InlineAsm` is represented as an expression in the HAIR: ```rust crate enum ExprKind<'tcx> { // [..] InlineAsm { template: &'tcx [InlineAsmTemplatePiece] operands: Vec> options: InlineAsmOptions } } crate enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass expr: ExprRef<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool expr: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool expr: ExprRef<'tcx> } SplitInOut { reg: InlineAsmRegOrRegClass late: bool in_expr: ExprRef<'tcx> out_expr: Option> } Const { expr: ExprRef<'tcx> } SymFn { expr: ExprRef<'tcx> } SymStatic { expr: ExprRef<'tcx> } } ``` The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` whose `expr` is a `Literal` ZST of the `fn` or a `SymStatic` whose `expr` is a `StaticRef`. ## MIR `InlineAsm` is represented as a `Terminator` in the MIR: ```rust pub enum TerminatorKind<'tcx> { // [..] /// Block ends with an inline assembly block. This is a terminator since /// inline assembly is allowed to diverge. InlineAsm { /// The template for the inline assembly with placeholders. template: &'tcx [InlineAsmTemplatePiece] /// The operands for the inline assembly as `Operand`s or `Place`s. operands: Vec> /// Miscellaneous options for the inline assembly. options: InlineAsmOptions /// Destination block after the inline assembly returns unless it is /// diverging (InlineAsmOptions::NORETURN). destination: Option } } pub enum InlineAsmOperand<'tcx> { In { reg: InlineAsmRegOrRegClass value: Operand<'tcx> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: Operand<'tcx> out_place: Option> } Const { value: Operand<'tcx> } SymFn { value: Box> } SymStatic { value: Box> } } ``` As part of HAIR lowering `InOut` and `SplitInOut` operands are lowered to a split form with a separate `in_value` and `out_place`. Semantically the `InlineAsm` terminator is similar to the `Call` terminator except that it has multiple output places where a `Call` only has a single return place output. The constant promotion pass is used to ensure that `const` operands are actually constants (using the same logic as `#[rustc_args_required_const]`). ## Codegen Operands are lowered one more time before being passed to LLVM codegen: ```rust pub enum InlineAsmOperandRef<'tcx B: BackendTypes + ?Sized> { In { reg: InlineAsmRegOrRegClass value: OperandRef<'tcx B::Value> } Out { reg: InlineAsmRegOrRegClass late: bool place: Option> } InOut { reg: InlineAsmRegOrRegClass late: bool in_value: OperandRef<'tcx B::Value> out_place: Option> } Const { string: String } SymFn { instance: Instance<'tcx> } SymStatic { def_id: DefId } } ``` The operands are lowered to LLVM operands and constraint codes as follow: - `out` and the output part of `inout` operands are added first as required by LLVM. Late output operands have a `=` prefix added to their constraint code non-late output operands have a `=&` prefix added to their constraint code. - `in` operands are added normally. - `inout` operands are tied to the matching output operand. - `sym` operands are passed as function pointers or pointers using the `""s""` constraint. - `const` operands are formatted to a string and directly inserted in the template string. The template string is converted to LLVM form: - `$` characters are escaped as `$$`. - `const` operands are converted to strings and inserted directly. - Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier character. Modifiers are converted from the Rust form to the LLVM form. The various options are converted to clobber constraints or LLVM attributes refer to the [RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) for more details. Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes so we sometimes need to insert conversions to/from a supported type. See the target-specific ISelLowering.cpp files in LLVM for details. # Adding support for new architectures Adding inline assembly support to an architecture is mostly a matter of defining the registers and register classes for that architecture. All the definitions for register classes are located in `src/librustc_target/asm/`. Additionally you will need to implement lowering of these register classes to LLVM constraint codes in `src/librustc_codegen_llvm/asm.rs`.",HEART,2021-08-22T23:28:37Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/69185,MERGED,2020-02-15T10:54:06Z,2020-02-20T22:43:40Z,Unify and improve const-prop lints,RalfJung,d237e0fc6c57b189e71fcbb66a332c7912da9eac,71,Rollup merge of #69185 - RalfJung:const-prop-lints r=oli-obk Unify and improve const-prop lints Add a single helper method for all lints emitted by const-prop and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic* not on the assertion to make behavior the same for debug and release builds. See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status. In terms of lint formatting I went for what seems to be the better style: have a general message above the code and then a specific message at the span: ``` error: this arithmetic operation will overflow --> $DIR/const-err2.rs:21:18 | LL | let a_i128 = -std::i128::MIN; | ^^^^^^^^^^^^^^^ attempt to negate with overflow ``` We could also just have the specific message above and no text at the span if that is preferred. I also converted some of the existing tests to use compiletest revisions so that the same test can check a bunch of different compile flags. Fixes https://github.com/rust-lang/rust/issues/69020. Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation. Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.,HEART,2020-04-23T02:15:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/69189,MERGED,2020-02-15T16:28:24Z,2020-03-19T03:34:45Z,Erase regions in writeback,matthewjasper,3f583fc27079fbc0983635f3fd40b47b89ed2f80,34,Rollup merge of #69189 - matthewjasper:erase-the-world r=nikomatsakis Erase regions in writeback Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further we no longer do lexical region solving on item bodies with `-Zborrowck=mir`. cc #68261 r? @nikomatsakis,HOORAY,2020-02-19T00:18:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69189,MERGED,2020-02-15T16:28:24Z,2020-03-19T03:34:45Z,Erase regions in writeback,matthewjasper,3f583fc27079fbc0983635f3fd40b47b89ed2f80,34,Rollup merge of #69189 - matthewjasper:erase-the-world r=nikomatsakis Erase regions in writeback Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further we no longer do lexical region solving on item bodies with `-Zborrowck=mir`. cc #68261 r? @nikomatsakis,HOORAY,2020-02-24T15:53:25Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/69189,MERGED,2020-02-15T16:28:24Z,2020-03-19T03:34:45Z,Erase regions in writeback,matthewjasper,3f583fc27079fbc0983635f3fd40b47b89ed2f80,34,Rollup merge of #69189 - matthewjasper:erase-the-world r=nikomatsakis Erase regions in writeback Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further we no longer do lexical region solving on item bodies with `-Zborrowck=mir`. cc #68261 r? @nikomatsakis,HOORAY,2020-03-09T14:03:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69189,MERGED,2020-02-15T16:28:24Z,2020-03-19T03:34:45Z,Erase regions in writeback,matthewjasper,3f583fc27079fbc0983635f3fd40b47b89ed2f80,34,Rollup merge of #69189 - matthewjasper:erase-the-world r=nikomatsakis Erase regions in writeback Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further we no longer do lexical region solving on item bodies with `-Zborrowck=mir`. cc #68261 r? @nikomatsakis,HOORAY,2020-03-12T20:03:55Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69189,MERGED,2020-02-15T16:28:24Z,2020-03-19T03:34:45Z,Erase regions in writeback,matthewjasper,3f583fc27079fbc0983635f3fd40b47b89ed2f80,34,Rollup merge of #69189 - matthewjasper:erase-the-world r=nikomatsakis Erase regions in writeback Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further we no longer do lexical region solving on item bodies with `-Zborrowck=mir`. cc #68261 r? @nikomatsakis,HOORAY,2020-03-17T20:27:23Z,lqd,NA https://github.com/rust-lang/rust/pull/69194,MERGED,2020-02-15T19:53:56Z,2020-02-19T01:36:49Z,parse: fuse associated and extern items up to defaultness,Centril,045b7d53a3fe94d2f6cb32d029a3f5d74e174ed9,1,ast: add a FIXME,HOORAY,2020-02-28T00:17:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-02-16T06:26:15Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-05T22:42:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-06T05:41:28Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-06T05:55:51Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-08T20:41:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-09T09:48:27Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-10T07:56:21Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-12T19:41:21Z,Lokathor,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-13T07:57:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-13T19:58:49Z,janriemer,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-03-14T16:19:03Z,95th,NA https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-04-21T21:08:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69201,MERGED,2020-02-16T00:08:51Z,2020-03-09T15:17:31Z,Permit attributes on 'if' expressions,Aaron1011,4ec997503c94913af44e7f9ec8a75a21c45b7bac,17,Rollup merge of #69201 - Aaron1011:feature/permit-if-attr r=Centril Permit attributes on 'if' expressions Previously attributes on 'if' expressions (e.g. `#[attr] if true {}`) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away) since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]` `#[cfg]`) and proc-macro attributes are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ``` Closes https://github.com/rust-lang/rust/issues/68618,HOORAY,2020-04-24T08:11:36Z,AntonGepting,anton.gepting@gmail.com https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-02-16T12:43:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-02-16T14:56:40Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-02-16T16:57:31Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,HOORAY,2020-02-19T00:16:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-02-19T16:56:44Z,sinkuu,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-02-23T11:27:55Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-03-14T09:14:50Z,niklasad1,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-03-18T15:26:15Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-03-24T19:08:30Z,orium,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-03-28T23:54:09Z,est31,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,HOORAY,2020-03-29T00:12:17Z,est31,NA https://github.com/rust-lang/rust/pull/69203,CLOSED,2020-02-16T06:00:42Z,2020-04-06T16:16:40Z, Implement unused crate lint for 2018 edition ,Aaron1011,NA,NA,NA,THUMBS_UP,2020-03-30T02:46:38Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-02-18T13:34:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-02-19T08:48:18Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-02-20T22:05:42Z,ramn,NA https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-02-23T19:36:24Z,lnicola,NA https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-02-28T04:07:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-03-16T01:19:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-05-19T14:11:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-07-10T21:25:16Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-07-17T13:32:31Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69218,CLOSED,2020-02-16T22:28:46Z,2020-11-24T10:06:04Z,perf: Only process changed obligations in ObligationForest,Marwes,NA,NA,NA,ROCKET,2020-08-07T12:27:47Z,cynecx,NA https://github.com/rust-lang/rust/pull/69220,MERGED,2020-02-17T00:12:45Z,2020-02-25T15:09:21Z,Add documentation for the `-Zself-profile` flag,wesleywiser,d91657877a44ecc9450b6d996bef577a1d1ec647,2,Rollup merge of #69220 - wesleywiser:doc_self_profile_unstable_book r=nikomatsakis Add documentation for the `-Zself-profile` flag,ROCKET,2020-02-19T00:15:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69241,MERGED,2020-02-17T18:12:03Z,2020-02-19T04:57:13Z,"Revert ""Remove `checked_add` in `Layout::repeat`""",shahn,3e17d191fa47b9ab262d0efa3a39e500e9fb1667,2,"Revert ""Remove `checked_add` in `Layout::repeat`"" This fixes a a segfault in safe code a stable regression. Reported in \#69225. This reverts commit a983e0590a43ed8b0f60417828efd4e79b51f494. Also adds a test for the expected behaviour.",HOORAY,2020-02-17T18:14:31Z,senden9,NA https://github.com/rust-lang/rust/pull/69241,MERGED,2020-02-17T18:12:03Z,2020-02-19T04:57:13Z,"Revert ""Remove `checked_add` in `Layout::repeat`""",shahn,3e17d191fa47b9ab262d0efa3a39e500e9fb1667,2,"Revert ""Remove `checked_add` in `Layout::repeat`"" This fixes a a segfault in safe code a stable regression. Reported in \#69225. This reverts commit a983e0590a43ed8b0f60417828efd4e79b51f494. Also adds a test for the expected behaviour.",HEART,2020-02-17T18:17:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69241,MERGED,2020-02-17T18:12:03Z,2020-02-19T04:57:13Z,"Revert ""Remove `checked_add` in `Layout::repeat`""",shahn,3e17d191fa47b9ab262d0efa3a39e500e9fb1667,2,"Revert ""Remove `checked_add` in `Layout::repeat`"" This fixes a a segfault in safe code a stable regression. Reported in \#69225. This reverts commit a983e0590a43ed8b0f60417828efd4e79b51f494. Also adds a test for the expected behaviour.",HEART,2020-02-18T07:47:45Z,estebank,NA https://github.com/rust-lang/rust/pull/69241,MERGED,2020-02-17T18:12:03Z,2020-02-19T04:57:13Z,"Revert ""Remove `checked_add` in `Layout::repeat`""",shahn,3e17d191fa47b9ab262d0efa3a39e500e9fb1667,2,"Revert ""Remove `checked_add` in `Layout::repeat`"" This fixes a a segfault in safe code a stable regression. Reported in \#69225. This reverts commit a983e0590a43ed8b0f60417828efd4e79b51f494. Also adds a test for the expected behaviour.",HOORAY,2020-02-19T00:15:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69245,CLOSED,2020-02-17T19:30:21Z,2020-03-26T22:41:04Z,"Remove ""unnecessary `unsafe` block in `unsafe` fn"" lint",LeSeulArtichaut,NA,NA,NA,HOORAY,2020-02-17T20:45:17Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69245,CLOSED,2020-02-17T19:30:21Z,2020-03-26T22:41:04Z,"Remove ""unnecessary `unsafe` block in `unsafe` fn"" lint",LeSeulArtichaut,NA,NA,NA,HOORAY,2020-02-19T20:18:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69245,CLOSED,2020-02-17T19:30:21Z,2020-03-26T22:41:04Z,"Remove ""unnecessary `unsafe` block in `unsafe` fn"" lint",LeSeulArtichaut,NA,NA,NA,HOORAY,2020-03-06T13:46:03Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/69247,MERGED,2020-02-17T20:42:07Z,2020-03-03T07:41:49Z,Remove experimental chalk option,CAD97,9381e8178b49636d4604e4ec0f1263960691c958,53,Auto merge of #69247 - CAD97:remove-chalk r=nikomatsakis Remove experimental chalk option As suggested by @nikomatsakis [here](https://github.com/rust-lang/rust/pull/68807#issuecomment-583339932). The current version of chalk used by the experimental `-Zchalk` flag is [v0.9.0 which is over a year old](https://crates.io/crates/chalk-engine). Since v0.9.0 chalk has seen [a lot of further development](https://github.com/rust-lang/chalk/compare/41dfe13...master) and the intent is to eventually upgrade rustc to use a more recent chalk. However it will take a decent chunk of effort to upgrade the current experimental chalk support and it is currently [blocking at least some PRs](https://github.com/rust-lang/rust/pull/68807) due to chalk:0.9.0's use of unstable features. So for the interim until the next chalk release and experimental rustc integration we remove the chalk-specific code from rustc.,HEART,2020-02-18T00:27:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/69247,MERGED,2020-02-17T20:42:07Z,2020-03-03T07:41:49Z,Remove experimental chalk option,CAD97,9381e8178b49636d4604e4ec0f1263960691c958,53,Auto merge of #69247 - CAD97:remove-chalk r=nikomatsakis Remove experimental chalk option As suggested by @nikomatsakis [here](https://github.com/rust-lang/rust/pull/68807#issuecomment-583339932). The current version of chalk used by the experimental `-Zchalk` flag is [v0.9.0 which is over a year old](https://crates.io/crates/chalk-engine). Since v0.9.0 chalk has seen [a lot of further development](https://github.com/rust-lang/chalk/compare/41dfe13...master) and the intent is to eventually upgrade rustc to use a more recent chalk. However it will take a decent chunk of effort to upgrade the current experimental chalk support and it is currently [blocking at least some PRs](https://github.com/rust-lang/rust/pull/68807) due to chalk:0.9.0's use of unstable features. So for the interim until the next chalk release and experimental rustc integration we remove the chalk-specific code from rustc.,HEART,2020-02-19T00:13:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-02-18T10:41:28Z,lqd,NA https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-02-18T12:53:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-02-18T18:07:31Z,cramertj,NA https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-02-18T19:10:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-02-21T07:11:16Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-03-22T10:45:03Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-03-23T19:33:49Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-03-26T20:43:38Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/69251,MERGED,2020-02-18T00:37:22Z,2020-03-23T09:08:30Z,#[track_caller] in traits,anp,5ed9d7ebb662ad993e9f2e8c70575fb27cd45041,15,"Rollup merge of #69251 - anp:track-caller-in-traits r=eddyb #[track_caller] in traits Per https://github.com/rust-lang/rust/issues/47809#issuecomment-572791760 this allows the `#[track_caller]` attribute on trait methods. Includes tests for `#[track_caller]` with: * ""regular"" trait impls * default trait impls * ""blanket-tracked"" trait impls where the annotation is in the trait definition and is inherited by ""regular"" impls of the trait",HOORAY,2020-03-27T07:11:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69255,MERGED,2020-02-18T07:28:49Z,2020-02-29T07:27:50Z,Add more context to E0599 errors,estebank,55aee8d49628ae8218e91745c388d5dc36771248,44,Auto merge of #69255 - estebank:e0599-details r=varkor Add more context to E0599 errors Point at the intermediary unfulfilled trait bounds. Fix #52523 fix #61661 cc #36513 fix #68131 fix #64417 fix #61768 cc #57457 cc #9082 fix #57994 cc #64934 cc #65149.,THUMBS_UP,2020-02-27T02:57:26Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/69255,MERGED,2020-02-18T07:28:49Z,2020-02-29T07:27:50Z,Add more context to E0599 errors,estebank,55aee8d49628ae8218e91745c388d5dc36771248,44,Auto merge of #69255 - estebank:e0599-details r=varkor Add more context to E0599 errors Point at the intermediary unfulfilled trait bounds. Fix #52523 fix #61661 cc #36513 fix #68131 fix #64417 fix #61768 cc #57457 cc #9082 fix #57994 cc #64934 cc #65149.,THUMBS_UP,2020-02-29T10:17:51Z,95th,NA https://github.com/rust-lang/rust/pull/69255,MERGED,2020-02-18T07:28:49Z,2020-02-29T07:27:50Z,Add more context to E0599 errors,estebank,55aee8d49628ae8218e91745c388d5dc36771248,44,Auto merge of #69255 - estebank:e0599-details r=varkor Add more context to E0599 errors Point at the intermediary unfulfilled trait bounds. Fix #52523 fix #61661 cc #36513 fix #68131 fix #64417 fix #61768 cc #57457 cc #9082 fix #57994 cc #64934 cc #65149.,HOORAY,2020-02-29T10:17:55Z,95th,NA https://github.com/rust-lang/rust/pull/69255,MERGED,2020-02-18T07:28:49Z,2020-02-29T07:27:50Z,Add more context to E0599 errors,estebank,55aee8d49628ae8218e91745c388d5dc36771248,44,Auto merge of #69255 - estebank:e0599-details r=varkor Add more context to E0599 errors Point at the intermediary unfulfilled trait bounds. Fix #52523 fix #61661 cc #36513 fix #68131 fix #64417 fix #61768 cc #57457 cc #9082 fix #57994 cc #64934 cc #65149.,HOORAY,2020-02-29T14:02:35Z,Jonathas-Conceicao,jonathasaoc@gmail.com https://github.com/rust-lang/rust/pull/69256,MERGED,2020-02-18T07:38:11Z,2020-02-20T05:18:21Z,Miscellaneous inlining improvements,nnethercote,183e893aaae581bd0ab499ba56b6c5e118557dc7,3,Auto merge of #69256 - nnethercote:misc-inlining r=Centril Miscellaneous inlining improvements These commits inline some hot functions that aren't currently inlined for some speed wins. r? @Centril,HEART,2020-03-26T00:27:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/69256,MERGED,2020-02-18T07:38:11Z,2020-02-20T05:18:21Z,Miscellaneous inlining improvements,nnethercote,183e893aaae581bd0ab499ba56b6c5e118557dc7,3,Auto merge of #69256 - nnethercote:misc-inlining r=Centril Miscellaneous inlining improvements These commits inline some hot functions that aren't currently inlined for some speed wins. r? @Centril,HEART,2020-04-12T18:19:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69256,MERGED,2020-02-18T07:38:11Z,2020-02-20T05:18:21Z,Miscellaneous inlining improvements,nnethercote,183e893aaae581bd0ab499ba56b6c5e118557dc7,3,Auto merge of #69256 - nnethercote:misc-inlining r=Centril Miscellaneous inlining improvements These commits inline some hot functions that aren't currently inlined for some speed wins. r? @Centril,HEART,2020-04-20T17:34:05Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/69274,MERGED,2020-02-18T21:50:08Z,2020-05-02T23:36:02Z,Implement RFC 2396: `#[target_feature]` 1.1,LeSeulArtichaut,f05a5240440b3eaef1684a7965860fab40301947,19,Auto merge of #69274 - LeSeulArtichaut:target-feature-11 r=hanna-kruppe Implement RFC 2396: `#[target_feature]` 1.1 Tracking issue: #69098 r? @nikomatsakis cc @gnzlbg @joshtriplett,HOORAY,2020-02-18T21:57:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69274,MERGED,2020-02-18T21:50:08Z,2020-05-02T23:36:02Z,Implement RFC 2396: `#[target_feature]` 1.1,LeSeulArtichaut,f05a5240440b3eaef1684a7965860fab40301947,19,Auto merge of #69274 - LeSeulArtichaut:target-feature-11 r=hanna-kruppe Implement RFC 2396: `#[target_feature]` 1.1 Tracking issue: #69098 r? @nikomatsakis cc @gnzlbg @joshtriplett,HOORAY,2020-02-18T22:52:16Z,est31,NA https://github.com/rust-lang/rust/pull/69274,MERGED,2020-02-18T21:50:08Z,2020-05-02T23:36:02Z,Implement RFC 2396: `#[target_feature]` 1.1,LeSeulArtichaut,f05a5240440b3eaef1684a7965860fab40301947,19,Auto merge of #69274 - LeSeulArtichaut:target-feature-11 r=hanna-kruppe Implement RFC 2396: `#[target_feature]` 1.1 Tracking issue: #69098 r? @nikomatsakis cc @gnzlbg @joshtriplett,HOORAY,2020-02-19T00:10:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69280,MERGED,2020-02-19T05:34:18Z,2020-02-19T22:29:12Z,Remove special case for `simd_shuffle` arg promotion,ecstatic-morse,61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c,9,Rollup merge of #69280 - ecstatic-morse:promote-shuffle-no-special-case r=petrochenkov Remove special case for `simd_shuffle` arg promotion After rust-lang/stdarch#825 these intrinsics are now defined with `#[rustc_args_required_const(2)]` so the special-case is no longer necessary.,HEART,2020-02-19T08:03:56Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69280,MERGED,2020-02-19T05:34:18Z,2020-02-19T22:29:12Z,Remove special case for `simd_shuffle` arg promotion,ecstatic-morse,61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c,9,Rollup merge of #69280 - ecstatic-morse:promote-shuffle-no-special-case r=petrochenkov Remove special case for `simd_shuffle` arg promotion After rust-lang/stdarch#825 these intrinsics are now defined with `#[rustc_args_required_const(2)]` so the special-case is no longer necessary.,HEART,2020-02-19T10:45:58Z,bjorn3,NA https://github.com/rust-lang/rust/pull/69280,MERGED,2020-02-19T05:34:18Z,2020-02-19T22:29:12Z,Remove special case for `simd_shuffle` arg promotion,ecstatic-morse,61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c,9,Rollup merge of #69280 - ecstatic-morse:promote-shuffle-no-special-case r=petrochenkov Remove special case for `simd_shuffle` arg promotion After rust-lang/stdarch#825 these intrinsics are now defined with `#[rustc_args_required_const(2)]` so the special-case is no longer necessary.,HEART,2020-02-19T17:10:01Z,panaman67,NA https://github.com/rust-lang/rust/pull/69284,MERGED,2020-02-19T10:20:40Z,2020-02-19T22:29:11Z,Reword OpenOptions::{create create_new} doc.,jumbatm,a97f354767844680311da5252fe0c81ecfb9ed45,1,Rollup merge of #69284 - jumbatm:openoptions-create-doc r=Dylan-DPC Reword OpenOptions::{create create_new} doc. Closes #69254. Currently the doc comment for `fs::OpenOptions::create` doesn't mention its behaviour when opening an existing file and `fs::OpenOptions::create_new`'s doc comment is worded in a way that doesn't make it clear that it actually _fails_ if the file already exists not overwrite the existing file with a new one. This PR addresses addresses this by rewording the doc comments to be more explicit. r? @GuillaumeGomez,THUMBS_UP,2020-02-19T17:05:56Z,pitdicker,NA https://github.com/rust-lang/rust/pull/69290,MERGED,2020-02-19T13:26:28Z,2020-02-21T10:04:26Z,Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors,wesleywiser,01a8b5f26e536a3bcd9449f62fd0b9b68ef3d650,1,Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4 r=RalfJung Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors Before this change `get_size_and_align()` calls `get_fn_alloc()` *a lot* in CTFE heavy code. This previously returned an `Error` which would check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this turned out to be a performance hotspot as @nnethercote discovered in #68792. This is an alternate take on that PR which resolves the performance issue by generating *many* fewer errors. Previously `ctfe-stress-4` would generate over 5 000 000 errors each of which would check for the presence of the environment variable. With these changes that number is reduced to 30. r? @RalfJung,HEART,2020-02-19T13:28:33Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69290,MERGED,2020-02-19T13:26:28Z,2020-02-21T10:04:26Z,Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors,wesleywiser,01a8b5f26e536a3bcd9449f62fd0b9b68ef3d650,1,Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4 r=RalfJung Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors Before this change `get_size_and_align()` calls `get_fn_alloc()` *a lot* in CTFE heavy code. This previously returned an `Error` which would check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this turned out to be a performance hotspot as @nnethercote discovered in #68792. This is an alternate take on that PR which resolves the performance issue by generating *many* fewer errors. Previously `ctfe-stress-4` would generate over 5 000 000 errors each of which would check for the presence of the environment variable. With these changes that number is reduced to 30. r? @RalfJung,HEART,2020-02-19T17:46:10Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69290,MERGED,2020-02-19T13:26:28Z,2020-02-21T10:04:26Z,Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors,wesleywiser,01a8b5f26e536a3bcd9449f62fd0b9b68ef3d650,1,Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4 r=RalfJung Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors Before this change `get_size_and_align()` calls `get_fn_alloc()` *a lot* in CTFE heavy code. This previously returned an `Error` which would check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this turned out to be a performance hotspot as @nnethercote discovered in #68792. This is an alternate take on that PR which resolves the performance issue by generating *many* fewer errors. Previously `ctfe-stress-4` would generate over 5 000 000 errors each of which would check for the presence of the environment variable. With these changes that number is reduced to 30. r? @RalfJung,HEART,2020-02-19T21:14:03Z,nnethercote,NA https://github.com/rust-lang/rust/pull/69290,MERGED,2020-02-19T13:26:28Z,2020-02-21T10:04:26Z,Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors,wesleywiser,01a8b5f26e536a3bcd9449f62fd0b9b68ef3d650,1,Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4 r=RalfJung Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors Before this change `get_size_and_align()` calls `get_fn_alloc()` *a lot* in CTFE heavy code. This previously returned an `Error` which would check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this turned out to be a performance hotspot as @nnethercote discovered in #68792. This is an alternate take on that PR which resolves the performance issue by generating *many* fewer errors. Previously `ctfe-stress-4` would generate over 5 000 000 errors each of which would check for the presence of the environment variable. With these changes that number is reduced to 30. r? @RalfJung,HEART,2020-02-19T22:00:24Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69295,MERGED,2020-02-19T18:03:58Z,2020-03-01T11:03:36Z,Use new dataflow framework for generators,ecstatic-morse,ee50590803f37abd7ad5f5f4bbd3bb844511fcf5,5,Auto merge of #69295 - ecstatic-morse:unified-dataflow-generators r=tmandry Use new dataflow framework for generators #65672 introduced a new dataflow framework that can handle arbitrarily complex transfer functions as well as ones expressed as a series of gen/kill operations. This PR ports the analyses used to implement generators to the new framework so that we can remove the old one. See #68241 for a prior example of this. The new framework has some superficial API changes but this shouldn't alter the generator passes in any way. r? @tmandry,HEART,2020-02-19T20:09:19Z,panaman67,NA https://github.com/rust-lang/rust/pull/69295,MERGED,2020-02-19T18:03:58Z,2020-03-01T11:03:36Z,Use new dataflow framework for generators,ecstatic-morse,ee50590803f37abd7ad5f5f4bbd3bb844511fcf5,5,Auto merge of #69295 - ecstatic-morse:unified-dataflow-generators r=tmandry Use new dataflow framework for generators #65672 introduced a new dataflow framework that can handle arbitrarily complex transfer functions as well as ones expressed as a series of gen/kill operations. This PR ports the analyses used to implement generators to the new framework so that we can remove the old one. See #68241 for a prior example of this. The new framework has some superficial API changes but this shouldn't alter the generator passes in any way. r? @tmandry,HEART,2020-02-19T20:14:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69295,MERGED,2020-02-19T18:03:58Z,2020-03-01T11:03:36Z,Use new dataflow framework for generators,ecstatic-morse,ee50590803f37abd7ad5f5f4bbd3bb844511fcf5,5,Auto merge of #69295 - ecstatic-morse:unified-dataflow-generators r=tmandry Use new dataflow framework for generators #65672 introduced a new dataflow framework that can handle arbitrarily complex transfer functions as well as ones expressed as a series of gen/kill operations. This PR ports the analyses used to implement generators to the new framework so that we can remove the old one. See #68241 for a prior example of this. The new framework has some superficial API changes but this shouldn't alter the generator passes in any way. r? @tmandry,HEART,2020-02-19T20:31:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69302,MERGED,2020-02-19T22:46:08Z,2020-02-22T03:54:51Z,Fix generator miscompilations,jonas-schievink,d735ede6ebfbdf6355d2857912b169bcecef3307,5,Auto merge of #69302 - jonas-schievink:yield-needs-storage r=Zoxc Fix generator miscompilations Fixes https://github.com/rust-lang/rust/issues/69039 r? @Zoxc,THUMBS_UP,2020-02-19T23:02:12Z,cynecx,NA https://github.com/rust-lang/rust/pull/69302,MERGED,2020-02-19T22:46:08Z,2020-02-22T03:54:51Z,Fix generator miscompilations,jonas-schievink,d735ede6ebfbdf6355d2857912b169bcecef3307,5,Auto merge of #69302 - jonas-schievink:yield-needs-storage r=Zoxc Fix generator miscompilations Fixes https://github.com/rust-lang/rust/issues/69039 r? @Zoxc,THUMBS_UP,2020-02-20T13:59:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/69326,MERGED,2020-02-20T20:11:55Z,2020-03-09T00:06:12Z,mir-interpret: add method to read wide strings from Memory,JOE1994,ff961789bc11bcace77e789cd680ee18de37ca05,2,Rollup merge of #69326 - JOE1994:os_str_widestring r=RalfJung mir-interpret: add method to read wide strings from Memory Implemented *step2* from [instructions](https://github.com/rust-lang/miri/issues/707#issuecomment-561564057) laid out in rust-lang/miri#707. Added 2 new methods to struct `rustc_mir::interpret::InterpCx`. * `read_os_str_from_wide_str` (src/librustc_mir/interpret/operand.rs) * `write_os_str_to_wide_str` (src/librustc_mir/interpret/place.rs) - used existing logic implemented in [MIRI/src/eval.rs](https://github.com/rust-lang/miri/blob/94732aaf7bf79fd01a4a48d11155c6586b937514/src/eval.rs#L132-L141) These methods are intended to be used for environment variable emulation in Windows.,THUMBS_UP,2020-03-13T08:03:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-21T14:12:46Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-21T14:46:09Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-21T15:21:16Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-21T16:25:10Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-21T23:44:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-02-24T12:10:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-03-05T16:07:46Z,bjorn3,NA https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-03-05T16:53:55Z,lqd,NA https://github.com/rust-lang/rust/pull/69349,MERGED,2020-02-21T14:07:21Z,2020-02-22T18:07:11Z,MIR is not an experiment anymore,spastorino,541b407c140bd8848fdeeba3448bc94ed72fd6a7,1,Rollup merge of #69349 - spastorino:mir-not-an-experiment r=Dylan-DPC MIR is not an experiment anymore At least I hope is not :stuck_out_tongue_closed_eyes: r? @oli-obk,LAUGH,2020-03-06T23:39:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69357,MERGED,2020-02-21T20:22:27Z,2020-03-15T14:19:06Z,Emit 1-based column numbers in debuginfo,tmiasko,62c057911640a269a8bbb1a4a814c146906194ce,7,Rollup merge of #69357 - tmiasko:debuginfo-column r=michaelwoerister Emit 1-based column numbers in debuginfo * Use byte offsets instead of char position offsets. Resolves #67360. * Use 1-based offsets instead of 0-based ones. Resolves #65437. * Consistently omit column information for msvc targets matching clang behaviour (previously columns have been omitted from `DILocation` but not from `DILexicalBlock`).,THUMBS_UP,2020-03-11T10:28:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/69357,MERGED,2020-02-21T20:22:27Z,2020-03-15T14:19:06Z,Emit 1-based column numbers in debuginfo,tmiasko,62c057911640a269a8bbb1a4a814c146906194ce,7,Rollup merge of #69357 - tmiasko:debuginfo-column r=michaelwoerister Emit 1-based column numbers in debuginfo * Use byte offsets instead of char position offsets. Resolves #67360. * Use 1-based offsets instead of 0-based ones. Resolves #65437. * Consistently omit column information for msvc targets matching clang behaviour (previously columns have been omitted from `DILocation` but not from `DILexicalBlock`).,THUMBS_UP,2020-03-15T18:07:12Z,RReverser,me@rreverser.com https://github.com/rust-lang/rust/pull/69357,MERGED,2020-02-21T20:22:27Z,2020-03-15T14:19:06Z,Emit 1-based column numbers in debuginfo,tmiasko,62c057911640a269a8bbb1a4a814c146906194ce,7,Rollup merge of #69357 - tmiasko:debuginfo-column r=michaelwoerister Emit 1-based column numbers in debuginfo * Use byte offsets instead of char position offsets. Resolves #67360. * Use 1-based offsets instead of 0-based ones. Resolves #65437. * Consistently omit column information for msvc targets matching clang behaviour (previously columns have been omitted from `DILocation` but not from `DILexicalBlock`).,THUMBS_UP,2020-03-20T10:30:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69362,MERGED,2020-02-21T22:36:08Z,2020-04-21T04:36:05Z,Stabilize most common subset of alloc_layout_extras,CAD97,69a528eda688b3191127865f889fef65d979bb9c,1,Rollup merge of #69362 - CAD97:alloc_layout_extras r=Amanieu Stabilize most common subset of alloc_layout_extras Tracking issue: https://github.com/rust-lang/rust/issues/55724 Specifically this stabilizes: ```rust pub fn Layout::align_to(&self align: usize) -> Result; pub fn Layout::pad_to_align(&self) -> Layout; pub fn Layout::extend(&self next: Layout) -> Result<(Layout usize) LayoutErr>; pub fn Layout::array(n: usize) -> Result; ``` Methods that are tracked by #55724 but are not stabilized here: ```rust pub fn Layout::padding_needed_for(&self align: usize) -> usize; pub fn Layout::repeat(&self n: usize) -> Result<(Layout usize) LayoutErr>; pub fn Layout::repeat_packed(&self n: usize) -> Result; pub fn Layout::extend_packed(&self next: Layout) -> Result; ``` Combined these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143) [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99) [pointer-utils/slice-dst](https://github.com/CAD97/pointer-utils/blob/92aeefeed9399f28d1b1654b63f8dcbe1242d8d4/crates/slice-dst/src/layout_polyfill.rs) and of course the standard library itself. Providing a higher-level API such as `Layout::repr_c(fields: [Layout; N]) -> Result<(Layout [usize; N]) LayoutErr>` is blocked on const generics which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets. The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However I think this is not just a (failing? limitation?) of the API but rather intrinsic complexity. While all Rust-defined types have size==stride and probably will for the foreseeable future there is no inherent reason why this is a limitation of all allocations. As such the `Layout` manipulation APIs shouldn't impose this limitation and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple. cc @matklad r? @rust-lang/libs,EYES,2020-02-22T02:48:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/69362,MERGED,2020-02-21T22:36:08Z,2020-04-21T04:36:05Z,Stabilize most common subset of alloc_layout_extras,CAD97,69a528eda688b3191127865f889fef65d979bb9c,1,Rollup merge of #69362 - CAD97:alloc_layout_extras r=Amanieu Stabilize most common subset of alloc_layout_extras Tracking issue: https://github.com/rust-lang/rust/issues/55724 Specifically this stabilizes: ```rust pub fn Layout::align_to(&self align: usize) -> Result; pub fn Layout::pad_to_align(&self) -> Layout; pub fn Layout::extend(&self next: Layout) -> Result<(Layout usize) LayoutErr>; pub fn Layout::array(n: usize) -> Result; ``` Methods that are tracked by #55724 but are not stabilized here: ```rust pub fn Layout::padding_needed_for(&self align: usize) -> usize; pub fn Layout::repeat(&self n: usize) -> Result<(Layout usize) LayoutErr>; pub fn Layout::repeat_packed(&self n: usize) -> Result; pub fn Layout::extend_packed(&self next: Layout) -> Result; ``` Combined these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143) [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99) [pointer-utils/slice-dst](https://github.com/CAD97/pointer-utils/blob/92aeefeed9399f28d1b1654b63f8dcbe1242d8d4/crates/slice-dst/src/layout_polyfill.rs) and of course the standard library itself. Providing a higher-level API such as `Layout::repr_c(fields: [Layout; N]) -> Result<(Layout [usize; N]) LayoutErr>` is blocked on const generics which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets. The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However I think this is not just a (failing? limitation?) of the API but rather intrinsic complexity. While all Rust-defined types have size==stride and probably will for the foreseeable future there is no inherent reason why this is a limitation of all allocations. As such the `Layout` manipulation APIs shouldn't impose this limitation and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple. cc @matklad r? @rust-lang/libs,HEART,2020-02-22T13:29:03Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/69362,MERGED,2020-02-21T22:36:08Z,2020-04-21T04:36:05Z,Stabilize most common subset of alloc_layout_extras,CAD97,69a528eda688b3191127865f889fef65d979bb9c,1,Rollup merge of #69362 - CAD97:alloc_layout_extras r=Amanieu Stabilize most common subset of alloc_layout_extras Tracking issue: https://github.com/rust-lang/rust/issues/55724 Specifically this stabilizes: ```rust pub fn Layout::align_to(&self align: usize) -> Result; pub fn Layout::pad_to_align(&self) -> Layout; pub fn Layout::extend(&self next: Layout) -> Result<(Layout usize) LayoutErr>; pub fn Layout::array(n: usize) -> Result; ``` Methods that are tracked by #55724 but are not stabilized here: ```rust pub fn Layout::padding_needed_for(&self align: usize) -> usize; pub fn Layout::repeat(&self n: usize) -> Result<(Layout usize) LayoutErr>; pub fn Layout::repeat_packed(&self n: usize) -> Result; pub fn Layout::extend_packed(&self next: Layout) -> Result; ``` Combined these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143) [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99) [pointer-utils/slice-dst](https://github.com/CAD97/pointer-utils/blob/92aeefeed9399f28d1b1654b63f8dcbe1242d8d4/crates/slice-dst/src/layout_polyfill.rs) and of course the standard library itself. Providing a higher-level API such as `Layout::repr_c(fields: [Layout; N]) -> Result<(Layout [usize; N]) LayoutErr>` is blocked on const generics which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets. The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However I think this is not just a (failing? limitation?) of the API but rather intrinsic complexity. While all Rust-defined types have size==stride and probably will for the foreseeable future there is no inherent reason why this is a limitation of all allocations. As such the `Layout` manipulation APIs shouldn't impose this limitation and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple. cc @matklad r? @rust-lang/libs,HEART,2020-02-26T08:40:04Z,kiljacken,NA https://github.com/rust-lang/rust/pull/69362,MERGED,2020-02-21T22:36:08Z,2020-04-21T04:36:05Z,Stabilize most common subset of alloc_layout_extras,CAD97,69a528eda688b3191127865f889fef65d979bb9c,1,Rollup merge of #69362 - CAD97:alloc_layout_extras r=Amanieu Stabilize most common subset of alloc_layout_extras Tracking issue: https://github.com/rust-lang/rust/issues/55724 Specifically this stabilizes: ```rust pub fn Layout::align_to(&self align: usize) -> Result; pub fn Layout::pad_to_align(&self) -> Layout; pub fn Layout::extend(&self next: Layout) -> Result<(Layout usize) LayoutErr>; pub fn Layout::array(n: usize) -> Result; ``` Methods that are tracked by #55724 but are not stabilized here: ```rust pub fn Layout::padding_needed_for(&self align: usize) -> usize; pub fn Layout::repeat(&self n: usize) -> Result<(Layout usize) LayoutErr>; pub fn Layout::repeat_packed(&self n: usize) -> Result; pub fn Layout::extend_packed(&self next: Layout) -> Result; ``` Combined these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143) [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99) [pointer-utils/slice-dst](https://github.com/CAD97/pointer-utils/blob/92aeefeed9399f28d1b1654b63f8dcbe1242d8d4/crates/slice-dst/src/layout_polyfill.rs) and of course the standard library itself. Providing a higher-level API such as `Layout::repr_c(fields: [Layout; N]) -> Result<(Layout [usize; N]) LayoutErr>` is blocked on const generics which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets. The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However I think this is not just a (failing? limitation?) of the API but rather intrinsic complexity. While all Rust-defined types have size==stride and probably will for the foreseeable future there is no inherent reason why this is a limitation of all allocations. As such the `Layout` manipulation APIs shouldn't impose this limitation and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple. cc @matklad r? @rust-lang/libs,HEART,2020-05-01T10:10:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69371,MERGED,2020-02-22T11:39:16Z,2020-03-03T19:57:29Z,Improve linking of crates with circular dependencies,tmiasko,3c5b1b7d63f55ac96fc7cd06df01e0f0e4f49d47,5,Auto merge of #69371 - tmiasko:weak-lang-cycle r=alexcrichton Improve linking of crates with circular dependencies Previously the code responsible for handling the cycles between crates introduces through weak lang items would keep a set of missing language items: * extending it with items missing from the current crate * removing items provided by the current crate * grouping the crates when the set changed from non-empty back to empty. This could produce incorrect results if a lang item was missing from a crate that comes after the crate that provides it (in the loop iteration order). In that case the grouping would not take place. The changes here address this specific failure scenario by keeping track of two separate sets of crates. Those that are required to link successfully and those that are available for linking. Verified using test case from #69368.,THUMBS_UP,2020-03-13T08:23:10Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69386,MERGED,2020-02-22T22:28:54Z,2020-02-24T14:54:44Z,Fix minor error in `MaybeUninit::get_mut()` doc example,danielhenrymantilla,c293ac9503bd7c5055b0d37ccee4d061fc28f61c,1,Rollup merge of #69386 - danielhenrymantilla:maybe_uninit_docs_replace_chunk_with_windows r=Dylan-DPC Fix minor error in `MaybeUninit::get_mut()` doc example In the `MaybeUninit::get_mut()` example I wanted to assert that the slice was sorted and mistakenly used `.chunks(2)` rather than `.windows(2)` to assert it as @ametisf pointed out in https://github.com/rust-lang/rust/pull/65948#issuecomment-589988183 . This fixes it.,THUMBS_UP,2020-02-23T13:11:16Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69388,CLOSED,2020-02-23T00:23:15Z,2020-03-30T14:23:39Z,x.py: don't enable -Zconfig-profile or -Zexternal-macro-backtrace with x.py clippy,matthiaskrgr,NA,NA,NA,THUMBS_UP,2020-02-29T18:26:06Z,Luro02,NA https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",THUMBS_UP,2020-02-23T04:49:24Z,Lokathor,NA https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",THUMBS_UP,2020-02-23T04:59:38Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",THUMBS_UP,2020-02-23T06:51:27Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",THUMBS_UP,2020-02-23T09:48:23Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",HEART,2020-02-23T09:48:29Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/69391,MERGED,2020-02-23T03:52:14Z,2020-02-25T15:09:11Z,Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping`,memoryruins,3e7a18e5e5efb870b9c4c7c4bd7a310270187213,1,"Rollup merge of #69391 - memoryruins:memalias r=Mark-Simulacrum Add rustdoc aliases to `ptr::copy` and `ptr::copy_nonoverlapping` This PR adds a [rustdoc alias](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#add-aliases-for-an-item-in-documentation-search) to `ptr::copy` and `ptr::copy_nonoverlapping` using the commonly used terms `memcpy` and `memmove`. The motivation for this PR is to improve discoverability for these functions since I've noticed users overlook these functions on multiple occasions (and they have thus reached for [libc](https://crates.io/crates/libc) without need). Currently std docs state: https://doc.rust-lang.org/nightly/std/ptr/fn.copy_nonoverlapping.html > `copy_nonoverlapping` is semantically equivalent to C's `memcpy` but with the argument order swapped. https://doc.rust-lang.org/nightly/std/ptr/fn.copy.html > `copy` is semantically equivalent to C's `memmove` but with the argument order swapped. #### search results before adding a rustdoc alias: ![screenshot 6517](https://user-images.githubusercontent.com/6868531/75102985-78fbb680-55c2-11ea-8e41-04979e6fa6f6.png) ![screenshot 6518](https://user-images.githubusercontent.com/6868531/75102984-78632000-55c2-11ea-9673-8822aae636d1.png) #### after adding `#[doc(alias = ""memcpy"")]` and `#[doc(alias = ""memmove"")]`: ![screenshot 6516](https://user-images.githubusercontent.com/6868531/75102986-78fbb680-55c2-11ea-93b9-1929be940043.png) ![screenshot 6515](https://user-images.githubusercontent.com/6868531/75102987-78fbb680-55c2-11ea-9861-ce8a77a0c3b9.png)",THUMBS_UP,2020-02-23T15:56:39Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/69397,MERGED,2020-02-23T14:25:23Z,2020-03-01T14:21:28Z,bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds,tmiasko,1e258784e141d68737d5702c6f388bd340c1d889,1,Rollup merge of #69397 - tmiasko:llvm-version-suffix r=nagisa bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds The custom LLVM version suffix was introduced to avoid unintentional library names conflicts. By default it included the LLVM submodule commit hash. Changing the version suffix requires the complete LLVM rebuild and since then every change to the submodules required it as well. Remove the commit hash from version suffix to avoid complete rebuilds while leaving the `rust` string the release number and release channel to disambiguate the library name. Context: version suffix was introduced by #59173 as solution to #59034. Resolves #68715.,HEART,2020-02-26T18:09:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69405,MERGED,2020-02-23T20:24:33Z,2020-02-24T14:54:40Z,docs: Stdin::read_line: mention the appending,NieDzejkob,ba3fee65377174a8d375b7edca0909bba4259bfe,1,Rollup merge of #69405 - NieDzejkob:docs-readline-appends r=joshtriplett docs: Stdin::read_line: mention the appending The fact that `stdin().read_line()` is an [unpleasant](https://twitter.com/Michcioperz/status/1231646797661167617?s=20) [footgun](https://rustbattle.net/battle/straight-finch-8-e4f4). Let's make it clearer in the documentation.,THUMBS_UP,2020-02-23T20:26:47Z,Michcioperz,public+github@meekchopp.es https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-04-30T17:16:42Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-01T21:14:08Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-07T22:33:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-07T22:50:20Z,declanvk,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-08T00:18:43Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-08T09:37:55Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-08T16:11:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-09T06:12:51Z,tmandry,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-09T21:33:23Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-12T06:12:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-15T13:42:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-16T08:35:36Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-18T21:35:51Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-19T05:41:49Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-05-19T14:36:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2020-10-17T11:22:07Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/69406,MERGED,2020-02-23T21:15:15Z,2020-05-09T20:56:44Z,upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir,jackh726,2420b42ac665ee2235b15847cacf26c7fc9633c7,51,Rollup merge of #69406 - jackh726:chalk-upgrade r=nikomatsakis upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir Reintegrate chalk into rustc. r? @nikomatsakis cc. @rust-lang/wg-traits,ROCKET,2021-06-08T15:47:05Z,MonliH,NA https://github.com/rust-lang/rust/pull/69429,MERGED,2020-02-24T13:57:36Z,2020-02-26T04:56:31Z,remove redundant clones and import,matthiaskrgr,ab3fb8b05aa0c90233982fc8a8d35672d12a93a1,9,Rollup merge of #69429 - matthiaskrgr:clippy_ r=estebank remove redundant clones and import,HEART,2020-02-24T16:17:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/69437,MERGED,2020-02-24T18:17:21Z,2020-02-25T15:09:03Z,no more codegen for miri_start_panic,RalfJung,e238eb610f363176ce582009533764edb7a711db,1,Rollup merge of #69437 - RalfJung:miri-no-codegen r=ecstatic-morse no more codegen for miri_start_panic With https://github.com/rust-lang/miri/pull/1136 landed we don't generate code any more for crates that will be run by Miri. So the LLVM backend does not have to implement the `miri_start_panic` intrinsic any more. Cc @Aaron1011,THUMBS_UP,2020-02-24T20:26:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69442,MERGED,2020-02-24T21:10:31Z,2020-03-02T06:31:09Z,`--explain` disambiguates no long description and invalid error codes,jakevossen5,e86c9e6ef8be7ddec0360f20aae7d86c69c59a83,5,Auto merge of #69442 - jakevossen5:master r=Mark-Simulacrum `--explain` disambiguates no long description and invalid error codes Closes #44710 First code contribution here so feedback is very much appreciated! cc @zackmdavis cc @Mark-Simulacrum,HEART,2020-02-27T23:43:06Z,estebank,NA https://github.com/rust-lang/rust/pull/69452,MERGED,2020-02-25T04:57:33Z,2020-02-28T21:14:13Z,typeck: use `Pattern` obligation cause more for better diagnostics,Centril,a245221497aa03553b983e2d2bcb1c7ee80bb477,28,Rollup merge of #69452 - Centril:typeck-pat r=estebank typeck: use `Pattern` obligation cause more for better diagnostics r? @estebank,HEART,2020-02-25T11:38:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69454,CLOSED,2020-02-25T08:02:34Z,2020-02-27T04:51:26Z,[WIP] Add `From<(Vec C)>` for BinaryHeap a.k.a. flexible `BinaryHeap`,sekineh,NA,NA,NA,THUMBS_UP,2020-02-25T09:15:33Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/69465,MERGED,2020-02-25T17:43:05Z,2020-02-25T18:28:53Z,Auto,botonespk,6fd8798f4de63328d743eb2a9a9c12e202a4a182,1,Auto merge of #69421 - flip1995:clippyup r=Dylan-DPC Update Clippy from 8fbb23f to fc5d0cc Fixes #69419 ``` Fix false positive in `missing_const_for_fn` Rustup to rust-lang/rust#69366 Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`] Add new lint `lossy_float_literal` to detect lossy whole number float literals ```,CONFUSED,2020-02-25T18:52:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69465,MERGED,2020-02-25T17:43:05Z,2020-02-25T18:28:53Z,Auto,botonespk,6fd8798f4de63328d743eb2a9a9c12e202a4a182,1,Auto merge of #69421 - flip1995:clippyup r=Dylan-DPC Update Clippy from 8fbb23f to fc5d0cc Fixes #69419 ``` Fix false positive in `missing_const_for_fn` Rustup to rust-lang/rust#69366 Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`] Add new lint `lossy_float_literal` to detect lossy whole number float literals ```,CONFUSED,2020-02-25T19:45:32Z,kennytm,NA https://github.com/rust-lang/rust/pull/69465,MERGED,2020-02-25T17:43:05Z,2020-02-25T18:28:53Z,Auto,botonespk,6fd8798f4de63328d743eb2a9a9c12e202a4a182,1,Auto merge of #69421 - flip1995:clippyup r=Dylan-DPC Update Clippy from 8fbb23f to fc5d0cc Fixes #69419 ``` Fix false positive in `missing_const_for_fn` Rustup to rust-lang/rust#69366 Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`] Add new lint `lossy_float_literal` to detect lossy whole number float literals ```,CONFUSED,2020-02-26T10:38:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/69465,MERGED,2020-02-25T17:43:05Z,2020-02-25T18:28:53Z,Auto,botonespk,6fd8798f4de63328d743eb2a9a9c12e202a4a182,1,Auto merge of #69421 - flip1995:clippyup r=Dylan-DPC Update Clippy from 8fbb23f to fc5d0cc Fixes #69419 ``` Fix false positive in `missing_const_for_fn` Rustup to rust-lang/rust#69366 Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`] Add new lint `lossy_float_literal` to detect lossy whole number float literals ```,CONFUSED,2020-02-26T15:04:00Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/69465,MERGED,2020-02-25T17:43:05Z,2020-02-25T18:28:53Z,Auto,botonespk,6fd8798f4de63328d743eb2a9a9c12e202a4a182,1,Auto merge of #69421 - flip1995:clippyup r=Dylan-DPC Update Clippy from 8fbb23f to fc5d0cc Fixes #69419 ``` Fix false positive in `missing_const_for_fn` Rustup to rust-lang/rust#69366 Add new lint [`wildcard imports`]. Add suggestion to [`enum_glob_use`] Add new lint `lossy_float_literal` to detect lossy whole number float literals ```,THUMBS_DOWN,2020-02-26T15:04:02Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/69469,MERGED,2020-02-25T20:48:14Z,2020-03-02T09:37:50Z,Clean up TypeFlags,matthewjasper,6af4fd385ec23145bc3ba08f700c61361ae961c0,17,Auto merge of #69469 - matthewjasper:type-flags r=cramertj Clean up TypeFlags * Add a new method `has_infer_types_or_consts` that's used instead of `has_infer_types` most of the time since there's generally no reason to only consider types. * Remove `has_closure_types`/`HAS_TY_CLOSURE` because closures are no longer implicitly linked to the `InferCtxt`. * Reorder flags to group similar ones together * Make some flags more granular * Compute `HAS_FREE_LOCAL_NAMES` from the other flags * Add some more doc comments,HEART,2020-02-26T03:11:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/69475,MERGED,2020-02-26T01:40:40Z,2020-03-10T09:15:29Z,Remove the `no_force` query attribute,Zoxc,5b08aad6d9630299d9fdc06fdd4d00c79d2eedd6,7,Rollup merge of #69475 - Zoxc:no-no-force r=michaelwoerister Remove the `no_force` query attribute This removes the `no_force` query attribute and instead uses the `DepNodeParams` trait to find out if a query can be forced. Also the `analysis` query is moved to the query macro. r? @eddyb,THUMBS_UP,2020-02-26T02:02:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69475,MERGED,2020-02-26T01:40:40Z,2020-03-10T09:15:29Z,Remove the `no_force` query attribute,Zoxc,5b08aad6d9630299d9fdc06fdd4d00c79d2eedd6,7,Rollup merge of #69475 - Zoxc:no-no-force r=michaelwoerister Remove the `no_force` query attribute This removes the `no_force` query attribute and instead uses the `DepNodeParams` trait to find out if a query can be forced. Also the `analysis` query is moved to the query macro. r? @eddyb,HEART,2020-02-26T03:09:41Z,panaman67,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T10:28:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T10:30:38Z,rubberduck203,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T10:36:00Z,lexxvir,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T10:38:25Z,flosse,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T10:38:28Z,flosse,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T10:41:52Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T11:34:47Z,ammgws,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T12:01:21Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T12:22:12Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T12:24:12Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T12:24:57Z,Peter-JanGootzen,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T12:50:19Z,minecrawler,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T12:50:20Z,minecrawler,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T13:18:57Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T13:19:50Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T14:02:26Z,kauhat,jack@jackflet.ch https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T17:06:21Z,est31,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T17:06:22Z,est31,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T17:10:59Z,darksv,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T17:11:03Z,darksv,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-26T18:14:07Z,dfrankland,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-26T18:14:09Z,dfrankland,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-02-27T09:16:41Z,CryZe,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-27T09:16:41Z,CryZe,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-27T15:57:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-27T21:12:32Z,Galhad,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-02-29T04:07:50Z,bouzuya,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-03-03T09:20:25Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-03T18:14:14Z,obust,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-03-04T05:39:40Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-05T03:29:24Z,crlf0710,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-08T00:57:25Z,juanfra684,nhw0dfv2@duck.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-10T05:01:44Z,somombo,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-03-10T05:01:52Z,somombo,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-11T07:59:21Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-16T08:08:02Z,brunodea,brunordea@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-16T08:49:43Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-03-16T17:04:00Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-03-18T15:26:48Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-03-19T13:19:27Z,dafyddcrosby,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-04-10T06:02:04Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-04-10T07:30:53Z,mati865,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-04-12T17:41:52Z,macpp,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-04-12T17:41:59Z,macpp,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-04-30T12:13:20Z,liquidnya,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-05-14T10:44:16Z,jbit,jbit@jbit.net https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-05-19T14:16:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-05-30T16:01:27Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-06-02T07:57:29Z,Rahix,rahix@rahix.de https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-06T14:56:00Z,grihabor,grihabor@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T05:13:54Z,alfiedotwtf,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T05:19:07Z,Nerixyz,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T06:33:16Z,0xdevalias,glenn@devalias.net https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-06-12T06:33:17Z,0xdevalias,glenn@devalias.net https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-06-12T07:27:12Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T10:12:38Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T12:25:19Z,codehippo,hornacek.jakub@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T15:01:41Z,edvorg,edvorg@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-12T16:22:37Z,yerke,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-06-12T16:22:39Z,yerke,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-06-14T19:39:17Z,asaaki,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-14T19:39:18Z,asaaki,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-15T06:37:26Z,nottxy,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-15T14:15:26Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T07:08:46Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T07:45:45Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T10:57:48Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-06-17T16:57:26Z,shalzz,shaleen@jain.sh https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T17:01:08Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T17:28:58Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-17T21:50:48Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-18T02:58:43Z,Fedcomp,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-19T00:22:02Z,42triangles,NA https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2020-06-19T05:48:34Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-06-19T05:48:34Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,THUMBS_UP,2020-06-19T05:48:34Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HOORAY,2020-08-12T21:19:47Z,Skelebot,antonisimka.8@gmail.com https://github.com/rust-lang/rust/pull/69478,MERGED,2020-02-26T10:20:24Z,2020-06-12T04:47:25Z,Enable AVR as a Tier 3 target upstream,dylanmckay,e91bf6c881dc8fa50dc18fc2f518a6c22424ddb5,24,Auto merge of #69478 - avr-rust:avr-support-upstream r=jonas-schievink Enable AVR as a Tier 3 target upstream Tracking issue: #44052. Things intentionally left out of the initial upstream: * The `target_cpu` flag I have made the cleanup suggestions by @jplatte and @jplatte in https://github.com/avr-rust/rust/commit/043550d9db0582add42e5837f636f61acb26b915. Anybody feel free to give the branch a test and see how it fares or make suggestions on the code patch itself.,HEART,2022-01-03T13:18:28Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/69481,MERGED,2020-02-26T12:13:18Z,2020-02-28T21:14:09Z,use char instead of &str for single char patterns,matthiaskrgr,07d9ed2c09b6eb4f114fff774570e6e11108f992,30,Rollup merge of #69481 - matthiaskrgr:single_char r=ecstatic-morse use char instead of &str for single char patterns,CONFUSED,2020-02-26T17:34:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/69496,MERGED,2020-02-26T22:05:51Z,2020-02-28T05:43:42Z,use find(x) instead of filter(x).next(),matthiaskrgr,5b32dd034ef2799c0ea648c6f55e6aa14ce444f4,6,Rollup merge of #69496 - matthiaskrgr:filter_next r=ecstatic-morse use find(x) instead of filter(x).next(),HEART,2020-02-27T03:21:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/69497,MERGED,2020-02-26T22:46:33Z,2020-03-21T16:42:14Z,Don't unwind when hitting the macro expansion recursion limit,Zoxc,a6596f2a4de1ea77a2a023510499de11adb53dc6,5,Rollup merge of #69497 - Zoxc:ast-fragment-error r=petrochenkov Don't unwind when hitting the macro expansion recursion limit This removes one use of `FatalError.raise()`. r? @petrochenkov,THUMBS_UP,2020-03-27T06:47:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69498,MERGED,2020-02-26T22:52:37Z,2020-03-15T14:18:59Z,"Change ""method"" to ""associated function""",mark-i-m,f40272ca6f9cba29632406efde371dc5c9751fe9,77,"Rollup merge of #69498 - mark-i-m:describe-it-2 r=matthewjasper Change ""method"" to ""associated function"" r? @matthewjasper cc @Centril @eddyb #67742 I'm opening this mostly as a test to see what the diagnostic changes would be. It seems that this makes them somewhat more verbose and I'm not sure it's worth it... The relevant changes are the last two commits (it is rebased on top of #67742)",CONFUSED,2020-03-15T18:23:52Z,estebank,NA https://github.com/rust-lang/rust/pull/69503,CLOSED,2020-02-27T00:53:00Z,2020-04-17T15:29:07Z,[experiment] Test different inline costs,wesleywiser,NA,NA,NA,THUMBS_UP,2020-03-04T00:03:09Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/69503,CLOSED,2020-02-27T00:53:00Z,2020-04-17T15:29:07Z,[experiment] Test different inline costs,wesleywiser,NA,NA,NA,HOORAY,2020-03-05T20:09:40Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69505,MERGED,2020-02-27T01:55:20Z,2020-02-27T11:44:03Z,Enable setting diagnostic labels,Mark-Simulacrum,c384acec291e76b99904bdfc7ddc9694fb0d02cf,1,Rollup merge of #69505 - Mark-Simulacrum:triagebot-diag-labels r=Centril Enable setting diagnostic labels,THUMBS_UP,2020-02-27T02:10:30Z,estebank,NA https://github.com/rust-lang/rust/pull/69513,MERGED,2020-02-27T11:33:38Z,2020-02-28T02:19:33Z,"Revert ""Mark attributes consumed by `check_mod_attrs` as normal""",tmiasko,fbc46b7d71d0fe93066d7c026eccd01c16185cd4,3,"Auto merge of #69513 - tmiasko:revert-checked-unused r=petrochenkov Revert ""Mark attributes consumed by `check_mod_attrs` as normal"" This reverts commit d78b22f35ec367368643fe7d6f7e87d01762692b. Those changes were incompatible with incremental compilation since the effect `check_mod_attrs` has with respect to marking the attributes as used is neither persisted nor recomputed.",HEART,2020-02-27T22:47:08Z,nnethercote,NA https://github.com/rust-lang/rust/pull/69514,MERGED,2020-02-27T13:41:57Z,2020-03-10T09:15:26Z,Remove spotlight,GuillaumeGomez,61150353bf9cc415f4554a9b4851c14e4255329f,22,Rollup merge of #69514 - GuillaumeGomez:remove-spotlight r=kinnison Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes the result is very clear: it's not useful. Considering the amount of code we have just to run it I think it's definitely worth it to remove it. r? @kinnison cc @ollie27,THUMBS_UP,2020-02-27T15:59:16Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69514,MERGED,2020-02-27T13:41:57Z,2020-03-10T09:15:26Z,Remove spotlight,GuillaumeGomez,61150353bf9cc415f4554a9b4851c14e4255329f,22,Rollup merge of #69514 - GuillaumeGomez:remove-spotlight r=kinnison Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes the result is very clear: it's not useful. Considering the amount of code we have just to run it I think it's definitely worth it to remove it. r? @kinnison cc @ollie27,HEART,2020-02-27T16:34:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/69514,MERGED,2020-02-27T13:41:57Z,2020-03-10T09:15:26Z,Remove spotlight,GuillaumeGomez,61150353bf9cc415f4554a9b4851c14e4255329f,22,Rollup merge of #69514 - GuillaumeGomez:remove-spotlight r=kinnison Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes the result is very clear: it's not useful. Considering the amount of code we have just to run it I think it's definitely worth it to remove it. r? @kinnison cc @ollie27,THUMBS_DOWN,2020-06-27T04:04:32Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/69514,MERGED,2020-02-27T13:41:57Z,2020-03-10T09:15:26Z,Remove spotlight,GuillaumeGomez,61150353bf9cc415f4554a9b4851c14e4255329f,22,Rollup merge of #69514 - GuillaumeGomez:remove-spotlight r=kinnison Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes the result is very clear: it's not useful. Considering the amount of code we have just to run it I think it's definitely worth it to remove it. r? @kinnison cc @ollie27,THUMBS_DOWN,2020-07-06T23:42:33Z,hdevalence,NA https://github.com/rust-lang/rust/pull/69514,MERGED,2020-02-27T13:41:57Z,2020-03-10T09:15:26Z,Remove spotlight,GuillaumeGomez,61150353bf9cc415f4554a9b4851c14e4255329f,22,Rollup merge of #69514 - GuillaumeGomez:remove-spotlight r=kinnison Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes the result is very clear: it's not useful. Considering the amount of code we have just to run it I think it's definitely worth it to remove it. r? @kinnison cc @ollie27,THUMBS_DOWN,2020-07-30T05:52:05Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/69544,MERGED,2020-02-28T11:35:53Z,2020-03-02T16:05:42Z,"Unrevert ""Remove `checked_add` in `Layout::repeat`""",lqd,f548a387a40b4a0d24ae16280930624100ccc7d5,1,"Rollup merge of #69544 - lqd:unrevert-67174 r=Mark-Simulacrum Unrevert ""Remove `checked_add` in `Layout::repeat`"" This reapplies @kraai's original `libcore::alloc::Layout::repeat` change from #67174 which was temporarily reverted in #69241. Now that the proper LLVM fix has been cherry-picked we can unrevert the revert. This change was originally reviewed by @hanna-kruppe on the initial PR. cc @RalfJung",HEART,2020-02-28T12:36:56Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69544,MERGED,2020-02-28T11:35:53Z,2020-03-02T16:05:42Z,"Unrevert ""Remove `checked_add` in `Layout::repeat`""",lqd,f548a387a40b4a0d24ae16280930624100ccc7d5,1,"Rollup merge of #69544 - lqd:unrevert-67174 r=Mark-Simulacrum Unrevert ""Remove `checked_add` in `Layout::repeat`"" This reapplies @kraai's original `libcore::alloc::Layout::repeat` change from #67174 which was temporarily reverted in #69241. Now that the proper LLVM fix has been cherry-picked we can unrevert the revert. This change was originally reviewed by @hanna-kruppe on the initial PR. cc @RalfJung",HEART,2020-02-28T17:58:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/69544,MERGED,2020-02-28T11:35:53Z,2020-03-02T16:05:42Z,"Unrevert ""Remove `checked_add` in `Layout::repeat`""",lqd,f548a387a40b4a0d24ae16280930624100ccc7d5,1,"Rollup merge of #69544 - lqd:unrevert-67174 r=Mark-Simulacrum Unrevert ""Remove `checked_add` in `Layout::repeat`"" This reapplies @kraai's original `libcore::alloc::Layout::repeat` change from #67174 which was temporarily reverted in #69241. Now that the proper LLVM fix has been cherry-picked we can unrevert the revert. This change was originally reviewed by @hanna-kruppe on the initial PR. cc @RalfJung",HEART,2020-02-28T20:07:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-28T20:13:56Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-28T20:22:46Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-28T22:07:37Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-28T22:52:55Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-29T15:23:00Z,o0Ignition0o,jeremy.lempereur@gmail.com https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-02-29T17:33:20Z,mati865,NA https://github.com/rust-lang/rust/pull/69562,MERGED,2020-02-28T20:13:19Z,2020-03-01T14:21:12Z,Don't `bug` when taking discriminant of generator during dataflow,ecstatic-morse,48ec25224b1e252608a0458585dc5e0847ed91c4,1,Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant r=oli-obk Don't `bug` when taking discriminant of generator during dataflow The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`. This required a small refactoring. `diff -w` is beneficial. r? @oli-obk cc @JohnTitor,HEART,2020-03-02T08:14:55Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/69571,MERGED,2020-02-29T01:16:52Z,2020-02-29T23:51:40Z,remove unneeded .as_ref() calls.,matthiaskrgr,b22631bfafe0a6dbe038b180bf838847b39385ea,3,Rollup merge of #69571 - matthiaskrgr:useless_asref r=Centril remove unneeded .as_ref() calls.,HEART,2020-02-29T17:25:00Z,panaman67,NA https://github.com/rust-lang/rust/pull/69572,MERGED,2020-02-29T02:18:38Z,2020-02-29T23:51:39Z,use .iter() instead of .into_iter() on references,matthiaskrgr,7d43997053f940d3aa656a5054995a08edf5f3d4,20,Rollup merge of #69572 - matthiaskrgr:try_err_and_iter_on_ref r=Centril use .iter() instead of .into_iter() on references,HEART,2020-02-29T17:24:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/69579,MERGED,2020-02-29T12:15:38Z,2020-03-01T14:21:09Z,parser: Remove `Parser::prev_span`,petrochenkov,4439bb09aabee6df4f0ca48552b61ea9d7bc60db,13,Rollup merge of #69579 - petrochenkov:noprevspan r=Centril parser: Remove `Parser::prev_span` Follow-up to https://github.com/rust-lang/rust/pull/69384. r? @Centril,HEART,2020-03-01T01:06:13Z,estebank,NA https://github.com/rust-lang/rust/pull/69583,MERGED,2020-02-29T13:27:30Z,2020-03-01T14:21:07Z,Do not ICE on invalid type node after parse recovery,LeSeulArtichaut,98016962148fdd22ea0b3566450dcdff46bc08b8,3,Rollup merge of #69583 - LeSeulArtichaut:ice-69378 r=Centril Do not ICE on invalid type node after parse recovery Closes #69378. r? @estebank,HEART,2020-03-01T01:04:05Z,estebank,NA https://github.com/rust-lang/rust/pull/69592,MERGED,2020-02-29T19:01:16Z,2020-03-01T04:42:18Z,Rename `libsyntax` to `librustc_ast`,petrochenkov,2917d993023dec5111147a1552ec78b206a5a37e,327,Auto merge of #69592 - petrochenkov:nosyntax r=Centril Rename `libsyntax` to `librustc_ast` This was the last rustc crate that wasn't following the `rustc_*` naming convention. Follow-up to https://github.com/rust-lang/rust/pull/67763.,HOORAY,2020-03-01T01:10:39Z,crlf0710,NA https://github.com/rust-lang/rust/pull/69592,MERGED,2020-02-29T19:01:16Z,2020-03-01T04:42:18Z,Rename `libsyntax` to `librustc_ast`,petrochenkov,2917d993023dec5111147a1552ec78b206a5a37e,327,Auto merge of #69592 - petrochenkov:nosyntax r=Centril Rename `libsyntax` to `librustc_ast` This was the last rustc crate that wasn't following the `rustc_*` naming convention. Follow-up to https://github.com/rust-lang/rust/pull/67763.,HOORAY,2020-03-02T07:51:40Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69609,MERGED,2020-03-01T11:33:43Z,2020-03-03T13:28:07Z,Remove `usable_size` APIs,TimDiekmann,4699b29a04e84746e28ef688f02993c3b4d54951,14,Rollup merge of #69609 - TimDiekmann:excess r=Amanieu Remove `usable_size` APIs This removes the usable size APIs: - remove `usable_size` (obv) - change return type of allocating methods to include the allocated size - remove `_excess` API r? @Amanieu closes rust-lang/wg-allocators#17,HEART,2020-03-01T22:25:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/69617,MERGED,2020-03-01T19:44:29Z,2020-03-02T16:05:35Z,constify mem::forget,DutchGhost,e725c04e626e95b526bc61eb364ca5731690764b,1,Rollup merge of #69617 - DutchGhost:master r=LukasKalbertodt constify mem::forget implements https://github.com/rust-lang/rust/issues/69616,HEART,2020-03-01T20:07:37Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/69617,MERGED,2020-03-01T19:44:29Z,2020-03-02T16:05:35Z,constify mem::forget,DutchGhost,e725c04e626e95b526bc61eb364ca5731690764b,1,Rollup merge of #69617 - DutchGhost:master r=LukasKalbertodt constify mem::forget implements https://github.com/rust-lang/rust/issues/69616,THUMBS_UP,2020-03-02T00:27:25Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/69617,MERGED,2020-03-01T19:44:29Z,2020-03-02T16:05:35Z,constify mem::forget,DutchGhost,e725c04e626e95b526bc61eb364ca5731690764b,1,Rollup merge of #69617 - DutchGhost:master r=LukasKalbertodt constify mem::forget implements https://github.com/rust-lang/rust/issues/69616,HEART,2020-03-05T22:41:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69618,MERGED,2020-03-01T20:43:47Z,2020-03-20T19:03:18Z,Clarify the relationship between `forget()` and `ManuallyDrop`.,hniksic,5d395176809c8f8a8399a8bec31bb2f6cdbf975a,1,"Rollup merge of #69618 - hniksic:mem-forget-doc-fix r=RalfJung Clarify the relationship between `forget()` and `ManuallyDrop`. As discussed on reddit this commit addresses two issues with the documentation of `mem::forget()`: * The documentation of `mem::forget()` can confuse the reader because of the discrepancy between usage examples that show correct usage and the accompanying text which speaks of the possibility of double-free. The text that says ""if the panic occurs before `mem::forget` was called"" refers to a variant of the second example that was never shown modified to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation should show both variants so it's clear what it's talking about. Also the double free could be fixed just by placing `mem::forget(v)` before the construction of `s`. Since the lifetimes of `s` and `v` wouldn't overlap there would be no point where panic could cause a double free. This could be mentioned and contrasted against the more robust fix of using `ManuallyDrop`. * This sentence seems unjustified: ""For some types operations such as passing ownership (to a funcion like `mem::forget`) requires them to actually be fully owned right now [...]"". Unlike C++ Rust has no move constructors its moves are (possibly elided) bitwise copies. Even if you pass an invalid object to `mem::forget` no harm should come to pass because `mem::forget` consumes the object and exists solely to prevent drop so there no one left to observe the invalid state state.",THUMBS_UP,2020-03-19T12:33:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/69619,MERGED,2020-03-01T20:44:30Z,2020-03-03T13:28:06Z,more cleanups,matthiaskrgr,f19684c7cf1819cf42b73d4358740c1392198e4d,11,Rollup merge of #69619 - matthiaskrgr:misc r=eddyb more cleanups * use starts_with() instead of chars().next() == Some(x) * use subsec_micros() instead of subsec_nanos() / 1000 * use for (idx item) in iter.enumerate() instead of manually counting loop iterations with variables * use values() or keys() respectively when iterating only over keys or values of maps.,HEART,2020-03-01T22:20:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/69621,MERGED,2020-03-01T22:29:41Z,2020-03-04T02:50:44Z,use question mark operator in a few places.,matthiaskrgr,2cfab735941e336946e339297c83e4a8cc88a1d1,4,Rollup merge of #69621 - matthiaskrgr:q r=petrochenkov use question mark operator in a few places.,HEART,2020-03-01T23:04:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/69644,MERGED,2020-03-02T20:03:53Z,2020-03-27T03:27:49Z,"Remove framework in `dataflow/mod.rs` in favor of ""generic"" one",ecstatic-morse,0f6144a115b2535feb8a84914105a2896e7e8e92,22,"Rollup merge of #69644 - ecstatic-morse:unified-dataflow-cleanup r=eddyb Remove framework in `dataflow/mod.rs` in favor of ""generic"" one This is the culmination of the work described in rust-lang/compiler-team#202. All dataflow analyses (including the one in `clippy`) have been ported to use the framework in `dataflow/generic` which can efficiently handle both gen/kill and generic problems. This PR moves the framework in `dataflow/generic` to `dataflow/framework` and removes the gen/kill framework in `dataflow/mod.rs`. More comprehensive documentation for the new framework is tracked in rust-lang/rustc-guide#564. `clippy` will need to change the path it uses to import the dataflow analysis traits.",HEART,2020-03-03T00:00:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/69644,MERGED,2020-03-02T20:03:53Z,2020-03-27T03:27:49Z,"Remove framework in `dataflow/mod.rs` in favor of ""generic"" one",ecstatic-morse,0f6144a115b2535feb8a84914105a2896e7e8e92,22,"Rollup merge of #69644 - ecstatic-morse:unified-dataflow-cleanup r=eddyb Remove framework in `dataflow/mod.rs` in favor of ""generic"" one This is the culmination of the work described in rust-lang/compiler-team#202. All dataflow analyses (including the one in `clippy`) have been ported to use the framework in `dataflow/generic` which can efficiently handle both gen/kill and generic problems. This PR moves the framework in `dataflow/generic` to `dataflow/framework` and removes the gen/kill framework in `dataflow/mod.rs`. More comprehensive documentation for the new framework is tracked in rust-lang/rustc-guide#564. `clippy` will need to change the path it uses to import the dataflow analysis traits.",HEART,2020-03-03T17:36:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69644,MERGED,2020-03-02T20:03:53Z,2020-03-27T03:27:49Z,"Remove framework in `dataflow/mod.rs` in favor of ""generic"" one",ecstatic-morse,0f6144a115b2535feb8a84914105a2896e7e8e92,22,"Rollup merge of #69644 - ecstatic-morse:unified-dataflow-cleanup r=eddyb Remove framework in `dataflow/mod.rs` in favor of ""generic"" one This is the culmination of the work described in rust-lang/compiler-team#202. All dataflow analyses (including the one in `clippy`) have been ported to use the framework in `dataflow/generic` which can efficiently handle both gen/kill and generic problems. This PR moves the framework in `dataflow/generic` to `dataflow/framework` and removes the gen/kill framework in `dataflow/mod.rs`. More comprehensive documentation for the new framework is tracked in rust-lang/rustc-guide#564. `clippy` will need to change the path it uses to import the dataflow analysis traits.",HEART,2020-03-04T21:10:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69644,MERGED,2020-03-02T20:03:53Z,2020-03-27T03:27:49Z,"Remove framework in `dataflow/mod.rs` in favor of ""generic"" one",ecstatic-morse,0f6144a115b2535feb8a84914105a2896e7e8e92,22,"Rollup merge of #69644 - ecstatic-morse:unified-dataflow-cleanup r=eddyb Remove framework in `dataflow/mod.rs` in favor of ""generic"" one This is the culmination of the work described in rust-lang/compiler-team#202. All dataflow analyses (including the one in `clippy`) have been ported to use the framework in `dataflow/generic` which can efficiently handle both gen/kill and generic problems. This PR moves the framework in `dataflow/generic` to `dataflow/framework` and removes the gen/kill framework in `dataflow/mod.rs`. More comprehensive documentation for the new framework is tracked in rust-lang/rustc-guide#564. `clippy` will need to change the path it uses to import the dataflow analysis traits.",HEART,2020-03-11T17:43:30Z,lqd,NA https://github.com/rust-lang/rust/pull/69646,MERGED,2020-03-02T20:17:56Z,2020-03-08T19:49:11Z,Miri visitor: detect primitive types based on type not layout (also more tests),RalfJung,c31b7044c1a1fceb9b22813b9e7219967cf478f3,14,Rollup merge of #69646 - RalfJung:layout-visitor r=eddyb Miri visitor: detect primitive types based on type not layout (also more tests) I also converted the union-based transmutes to use `mem::transmute` for increased readability. r? @eddyb @oli-obk,HEART,2020-03-02T23:59:06Z,panaman67,NA https://github.com/rust-lang/rust/pull/69650,MERGED,2020-03-03T00:04:51Z,2020-03-04T02:50:41Z,cleanup more iterator usages (and other things),matthiaskrgr,8ca3e59f8a768f9d246b69f629097a83af297fa1,8,Rollup merge of #69650 - matthiaskrgr:clnp r=varkor cleanup more iterator usages (and other things) * Improve weird formatting by moving comment inside else-code block. * Use .any(x) instead of .find(x).is_some() on iterators. * Use .nth(x) instead of .skip(x).next() on iterators. * Simplify conditions like x + 1 <= y to x < y * Use let instead of match to get value of enum with single variant.,HEART,2020-03-03T03:15:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-05-15T06:40:22Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-05-20T01:11:01Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-05-20T10:21:34Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-05-21T06:51:21Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-05-21T13:20:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-06-01T01:54:07Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/69659,MERGED,2020-03-03T02:51:51Z,2020-05-15T14:49:06Z,Rework the std::iter::Step trait,CAD97,ed084b0b8341c974769a0328f61851b0e1fc17fa,6,"Auto merge of #69659 - CAD97:step-rework-take-3 r=Amanieu Rework the std::iter::Step trait Previous attempts: #43127 #62886 #68807 Tracking issue: #42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite or if `end` would never be reached). /// /// # Invariants /// /// For any `a` `b` and `n`: /// /// * `steps_between(&a &b) == Some(n)` if and only if `Step::forward(&a n) == Some(b)` /// * `steps_between(&a &b) == Some(n)` if and only if `Step::backward(&a n) == Some(a)` /// * `steps_between(&a &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a &b) == None` if `a > b` fn steps_between(start: &Self end: &Self) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a m).and_then(|x| Step::forward_checked(x n))` /// /// For any `a` `n` and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a n).and_then(|x| Step::forward_checked(x m)) == Step::forward_checked(a n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a n) == (0..n).try_fold(a |x _| Step::forward_checked(&x 1))` /// * Corollary: `Step::forward_checked(&a 0) == Some(a)` fn forward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::forward(Step::forward(a n) m) == Step::forward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_checked(a n) == Some(Step::forward(a n))` /// * `Step::forward(a n) == (0..n).fold(a |x _| Step::forward(x 1))` /// * Corollary: `Step::forward(a 0) == a` /// * `Step::forward(a n) >= a` /// * `Step::backward(Step::forward(a n) n) == a` fn forward(start: Self count: usize) -> Self { Step::forward_checked(start count).expect(""overflow in `Step::forward`"") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a` it is safe to call `Step::forward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&a &b) == Some(n)` /// it is safe to call `Step::forward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::forward_unchecked(a n)` is equivalent to `Step::forward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn forward_unchecked(start: Self count: usize) -> Self { Step::forward(start count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` returns `None`. /// /// # Invariants /// /// For any `a` `n` and `m`: /// /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a x))` /// * `Step::backward_checked(a n).and_then(|x| Step::backward_checked(x m)) == try { Step::backward_checked(a n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a n) == (0..n).try_fold(a |x _| Step::backward_checked(&x 1))` /// * Corollary: `Step::backward_checked(&a 0) == Some(a)` fn backward_checked(start: Self count: usize) -> Option; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self` /// this function is allowed to panic wrap or saturate. /// The suggested behavior is to panic when debug assertions are enabled /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a` `n` and `m` where no overflow occurs: /// /// * `Step::backward(Step::backward(a n) m) == Step::backward(a n + m)` /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_checked(a n) == Some(Step::backward(a n))` /// * `Step::backward(a n) == (0..n).fold(a |x _| Step::backward(x 1))` /// * Corollary: `Step::backward(a 0) == a` /// * `Step::backward(a n) <= a` /// * `Step::forward(Step::backward(a n) n) == a` fn backward(start: Self count: usize) -> Self { Step::backward_checked(start count).expect(""overflow in `Step::backward`"") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a` it is safe to call `Step::backward_unchecked(a 1)` /// * if there exists `b` `n` such that `steps_between(&b &a) == Some(n)` /// it is safe to call `Step::backward_unchecked(a m)` for any `m <= n`. /// /// For any `a` and `n` where no overflow occurs: /// /// * `Step::backward_unchecked(a n)` is equivalent to `Step::backward(a n)` #[unstable(feature = ""unchecked_math"" reason = ""niche optimization path"" issue = ""none"")] unsafe fn backward_unchecked(start: Self count: usize) -> Self { Step::backward(start count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a ""step by one"" method directly this version of the trait only exposes ""step by n"". There are a few reasons for this: - `Range*` the primary consumer of `Step` assumes that the ""step by n"" operation is cheap. If a single step function is provided it will be a lot more enticing to implement ""step by n"" as n repeated calls to ""step by one"". While this is not strictly incorrect this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl this can be easily added backwards-compatibly later. - The debug-wrapping ""step by n"" needs to exist for `RangeFrom` to be consistent between ""step by n"" and ""step by one"" operation. (Note: the behavior is not changed by this PR but making the behavior consistent is made tenable by this PR.) Three ""kinds"" of step are provided: `_checked` which returns an `Option` indicating attempted overflow; (unsuffixed) which provides ""safe overflow"" behavior (is allowed to panic wrap or saturate depending on what is most convenient for a given type); and `_unchecked` which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the ""common sense"" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).",HEART,2020-07-01T05:35:49Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/69661,MERGED,2020-03-03T05:20:36Z,2020-03-15T20:40:45Z,Implement From<&mut str> for String,lopopolo,cc1623267b344684c165a0a6972f2791e2a46728,1,Rollup merge of #69661 - lopopolo:string-from-mut-str r=sfackler Implement From<&mut str> for String I ran into this missing impl when trying to do `String::from` on the result returned from this API in the `uuid` crate: https://docs.rs/uuid/0.8.1/uuid/adapter/struct.Hyphenated.html#method.encode_lower I wasn't sure what to put in the stability annotation. I'd appreciate some help with that :),CONFUSED,2020-03-03T05:30:08Z,tesuji,NA https://github.com/rust-lang/rust/pull/69667,MERGED,2020-03-03T09:27:44Z,2020-03-08T09:16:58Z,Remove the `no_debug` feature,JohnTitor,614cd8dc47f12ec7d265580f5ea1c79cd593809c,14,Rollup merge of #69667 - JohnTitor:no-debug r=nikomatsakis Remove the `no_debug` feature Context: https://github.com/rust-lang/rust/issues/29721#issuecomment-367642779 r? @nikomatsakis,HEART,2020-03-03T17:51:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/69669,CLOSED,2020-03-03T11:11:05Z,2020-03-03T13:38:02Z,Fixing broken references to char primitive methods in str module,bausano,NA,NA,NA,ROCKET,2020-03-03T11:16:59Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/69669,CLOSED,2020-03-03T11:11:05Z,2020-03-03T13:38:02Z,Fixing broken references to char primitive methods in str module,bausano,NA,NA,NA,ROCKET,2020-03-03T11:19:09Z,gliderkite,NA https://github.com/rust-lang/rust/pull/69685,MERGED,2020-03-04T00:06:32Z,2020-03-09T15:17:10Z,unix: Don't override existing SIGSEGV/BUS handlers,cuviper,eaf6905c558093c101b41b791ac4fba3dbe96779,2,Rollup merge of #69685 - cuviper:soft-segv r=sfackler unix: Don't override existing SIGSEGV/BUS handlers Although `stack_overflow::init` runs very early in the process even before `main` there may already be signal handlers installed for things like the address sanitizer. In that case just leave it alone and don't bother trying to allocate our own signal stacks either. Fixes #69524.,HEART,2020-03-04T05:28:12Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/69686,MERGED,2020-03-04T00:35:36Z,2020-03-16T06:22:57Z,Use `pprust` to print attributes in rustdoc,varkor,e5de0b13febfe9a9a3f0dc07489a7d19d5525e3b,2,Rollup merge of #69686 - varkor:rustdoc-attributes r=GuillaumeGomez Use `pprust` to print attributes in rustdoc Fixes https://github.com/rust-lang/rust/issues/69559. I'm not sure what the original motivation was for the `render_attribute` so I may be missing something but replacing it with `pprust::attribute_to_string` seems to give the intended output (modulo some spacing idiosyncrasies). r? @GuillaumeGomez,THUMBS_UP,2020-03-04T07:54:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/69693,CLOSED,2020-03-04T09:18:58Z,2020-03-04T16:54:38Z,more toolstate comments,RalfJung,NA,NA,NA,THUMBS_UP,2020-03-04T14:56:09Z,ehuss,NA https://github.com/rust-lang/rust/pull/69698,MERGED,2020-03-04T12:21:03Z,2020-03-06T01:25:39Z,Use associated constants of integer types,RalfJung,44f184acc0008646d046a21cd2578bfed6a79867,10,Rollup merge of #69698 - RalfJung:int_assoc r=davidtwco Use associated constants of integer types Take advantage of https://github.com/rust-lang/rust/pull/68952 in the interpreter and some nearby modules :),HEART,2020-03-04T19:13:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/69706,MERGED,2020-03-04T18:53:39Z,2020-03-07T12:02:39Z,Use subslice patterns in slice methods,cuviper,b25fb9e79bc52f4746c966a7ade7bb93b67c4aa0,1,Rollup merge of #69706 - cuviper:subslice-methods r=Centril Use subslice patterns in slice methods For all of the methods that pick off the first or last element we can use subslice patterns to implement them directly rather than relying on deeper indexing function calls. At a minimum this means the generated code will rely less on inlining for performance but in some cases it also optimizes better.,HEART,2020-03-04T19:11:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/69706,MERGED,2020-03-04T18:53:39Z,2020-03-07T12:02:39Z,Use subslice patterns in slice methods,cuviper,b25fb9e79bc52f4746c966a7ade7bb93b67c4aa0,1,Rollup merge of #69706 - cuviper:subslice-methods r=Centril Use subslice patterns in slice methods For all of the methods that pick off the first or last element we can use subslice patterns to implement them directly rather than relying on deeper indexing function calls. At a minimum this means the generated code will rely less on inlining for performance but in some cases it also optimizes better.,THUMBS_UP,2020-03-04T19:33:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69706,MERGED,2020-03-04T18:53:39Z,2020-03-07T12:02:39Z,Use subslice patterns in slice methods,cuviper,b25fb9e79bc52f4746c966a7ade7bb93b67c4aa0,1,Rollup merge of #69706 - cuviper:subslice-methods r=Centril Use subslice patterns in slice methods For all of the methods that pick off the first or last element we can use subslice patterns to implement them directly rather than relying on deeper indexing function calls. At a minimum this means the generated code will rely less on inlining for performance but in some cases it also optimizes better.,HEART,2020-03-04T21:44:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69707,MERGED,2020-03-04T19:04:03Z,2020-04-12T10:02:49Z,Handle `impl Trait` where `Trait` has an assoc type with missing bounds,estebank,32fb4dcdd7a57683a639a0959442711d0fd123bc,7,"Auto merge of #69707 - estebank:impl-trait-missing-bounds r=Centril Handle `impl Trait` where `Trait` has an assoc type with missing bounds When encountering a type parameter that needs more bounds the trivial case is `T` `where T: Bound` but it can also be an `impl Trait` param that needs to be decomposed to a type param for cleaner code. For example given ```rust fn foo(constraints: impl Iterator) { for constraint in constraints { println!(""{:?}"" constraint); } } ``` the previous output was ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 1 | fn foo(constraints: impl Iterator) { | - help: consider further restricting the associated type: `where ::Item: std::fmt::Debug` 2 | for constraint in constraints { 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` ``` which is incorrect as `where ::Item: std::fmt::Debug` is not valid syntax nor would it restrict the positional `impl Iterator` parameter if it were. The output being introduced is ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: T) where ::Item: std::fmt::Debug { | ^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This suggestion is correct and lead the user in the right direction: because you have an associated type restriction you can no longer use `impl Trait` the only reasonable alternative is to introduce a named type parameter bound by `Trait` and with a `where` binding on the associated type for the new type parameter `as Trait` for the missing bound. *Ideally* we would want to suggest something like the following but that is not valid syntax today ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: impl Iterator) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Fix #69638.",HEART,2020-04-15T16:56:48Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/69707,MERGED,2020-03-04T19:04:03Z,2020-04-12T10:02:49Z,Handle `impl Trait` where `Trait` has an assoc type with missing bounds,estebank,32fb4dcdd7a57683a639a0959442711d0fd123bc,7,"Auto merge of #69707 - estebank:impl-trait-missing-bounds r=Centril Handle `impl Trait` where `Trait` has an assoc type with missing bounds When encountering a type parameter that needs more bounds the trivial case is `T` `where T: Bound` but it can also be an `impl Trait` param that needs to be decomposed to a type param for cleaner code. For example given ```rust fn foo(constraints: impl Iterator) { for constraint in constraints { println!(""{:?}"" constraint); } } ``` the previous output was ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 1 | fn foo(constraints: impl Iterator) { | - help: consider further restricting the associated type: `where ::Item: std::fmt::Debug` 2 | for constraint in constraints { 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` ``` which is incorrect as `where ::Item: std::fmt::Debug` is not valid syntax nor would it restrict the positional `impl Iterator` parameter if it were. The output being introduced is ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: T) where ::Item: std::fmt::Debug { | ^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This suggestion is correct and lead the user in the right direction: because you have an associated type restriction you can no longer use `impl Trait` the only reasonable alternative is to introduce a named type parameter bound by `Trait` and with a `where` binding on the associated type for the new type parameter `as Trait` for the missing bound. *Ideally* we would want to suggest something like the following but that is not valid syntax today ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: impl Iterator) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Fix #69638.",HEART,2020-04-15T18:06:48Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/69707,MERGED,2020-03-04T19:04:03Z,2020-04-12T10:02:49Z,Handle `impl Trait` where `Trait` has an assoc type with missing bounds,estebank,32fb4dcdd7a57683a639a0959442711d0fd123bc,7,"Auto merge of #69707 - estebank:impl-trait-missing-bounds r=Centril Handle `impl Trait` where `Trait` has an assoc type with missing bounds When encountering a type parameter that needs more bounds the trivial case is `T` `where T: Bound` but it can also be an `impl Trait` param that needs to be decomposed to a type param for cleaner code. For example given ```rust fn foo(constraints: impl Iterator) { for constraint in constraints { println!(""{:?}"" constraint); } } ``` the previous output was ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 1 | fn foo(constraints: impl Iterator) { | - help: consider further restricting the associated type: `where ::Item: std::fmt::Debug` 2 | for constraint in constraints { 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` ``` which is incorrect as `where ::Item: std::fmt::Debug` is not valid syntax nor would it restrict the positional `impl Iterator` parameter if it were. The output being introduced is ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: T) where ::Item: std::fmt::Debug { | ^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This suggestion is correct and lead the user in the right direction: because you have an associated type restriction you can no longer use `impl Trait` the only reasonable alternative is to introduce a named type parameter bound by `Trait` and with a `where` binding on the associated type for the new type parameter `as Trait` for the missing bound. *Ideally* we would want to suggest something like the following but that is not valid syntax today ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: impl Iterator) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Fix #69638.",HEART,2020-04-15T19:37:07Z,adamreichold,NA https://github.com/rust-lang/rust/pull/69707,MERGED,2020-03-04T19:04:03Z,2020-04-12T10:02:49Z,Handle `impl Trait` where `Trait` has an assoc type with missing bounds,estebank,32fb4dcdd7a57683a639a0959442711d0fd123bc,7,"Auto merge of #69707 - estebank:impl-trait-missing-bounds r=Centril Handle `impl Trait` where `Trait` has an assoc type with missing bounds When encountering a type parameter that needs more bounds the trivial case is `T` `where T: Bound` but it can also be an `impl Trait` param that needs to be decomposed to a type param for cleaner code. For example given ```rust fn foo(constraints: impl Iterator) { for constraint in constraints { println!(""{:?}"" constraint); } } ``` the previous output was ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 1 | fn foo(constraints: impl Iterator) { | - help: consider further restricting the associated type: `where ::Item: std::fmt::Debug` 2 | for constraint in constraints { 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` ``` which is incorrect as `where ::Item: std::fmt::Debug` is not valid syntax nor would it restrict the positional `impl Iterator` parameter if it were. The output being introduced is ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: T) where ::Item: std::fmt::Debug { | ^^^^^^^^^^^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This suggestion is correct and lead the user in the right direction: because you have an associated type restriction you can no longer use `impl Trait` the only reasonable alternative is to introduce a named type parameter bound by `Trait` and with a `where` binding on the associated type for the new type parameter `as Trait` for the missing bound. *Ideally* we would want to suggest something like the following but that is not valid syntax today ``` error[E0277]: `::Item` doesn't implement `std::fmt::Debug` --> src/main.rs:3:26 | 3 | println!(""{:?}"" constraint); | ^^^^^^^^^^ `::Item` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug` | = help: the trait `std::fmt::Debug` is not implemented for `::Item` = note: required by `std::fmt::Debug::fmt` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn foo(constraints: impl Iterator) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Fix #69638.",HEART,2020-04-16T12:26:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69709,CLOSED,2020-03-04T19:09:56Z,2020-03-09T23:10:42Z,Maintain predicate obligation chain for more detailed diagnostics,estebank,NA,NA,NA,THUMBS_UP,2020-03-05T04:09:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69713,MERGED,2020-03-04T19:53:30Z,2020-03-06T01:25:35Z,more clippy cleanups,matthiaskrgr,22a743bc1c242b539cd70116068e62b1bd686a10,17,"Rollup merge of #69713 - matthiaskrgr:more_cleanup r=cramertj more clippy cleanups * Don't use .ok() before unwrapping via .expect() on a Result. * Use .map() to modify data inside Options instead of using .and_then(|x| Some(y)) * Use .as_deref() instead of .as_ref().map(Deref::deref) * Don't use ""if let"" bindings to only check a value and not actually bind anything. * Use single-char patter on {ends starts}_with and remove clone on copy type.",HEART,2020-03-05T04:41:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",THUMBS_UP,2020-03-05T16:36:40Z,eupn,NA https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",THUMBS_UP,2020-03-14T18:53:12Z,MarkSwanson,NA https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",THUMBS_UP,2020-03-15T00:37:19Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",THUMBS_UP,2020-03-20T00:49:17Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",ROCKET,2020-03-20T11:16:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69716,MERGED,2020-03-04T21:58:40Z,2020-03-14T05:10:27Z,Don't store locals in generators that are immediately overwritten with the resume argument,jonas-schievink,5ed3453af9db9c516e564e25ba9ee28056d48103,11,"Auto merge of #69716 - jonas-schievink:generator-size r=tmandry Don't store locals in generators that are immediately overwritten with the resume argument This fixes https://github.com/rust-lang/rust/issues/69672 and makes https://github.com/rust-lang/rust/pull/69033 pass the async fn size tests again (in other words there will be no size regression of async fn if both this and https://github.com/rust-lang/rust/pull/69033 land). ~~This is a small botch and I'd rather have a more precise analysis but that seems much harder to pull off so this special-cases `Yield` terminators that store the resume argument into a simple local (ie. without any field projections) and explicitly marks that local as ""not live"" in the suspend point of that yield. We know that this local does not need to be stored in the generator for this suspend point because the next resume would immediately overwrite it with the passed-in resume argument anyways. The local might still end up in the state if it is used across another yield.~~ (this now properly updates the dataflow framework to handle this case)",THUMBS_UP,2020-05-30T09:42:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69718,MERGED,2020-03-04T22:41:38Z,2020-04-04T06:05:02Z,Add hash of source files in debug info,arlosi,6050e523bae6de61de4e060facc43dc512adaccd,19,Auto merge of #69718 - arlosi:debughash r=eddyb Add hash of source files in debug info LLVM supports placing the hash of source files inside the debug info. This information can be used by a debugger to verify that the source code matches the executable. This change adds support for both hash algorithms supported by LLVM MD5 and SHA1 controlled by a target option. * DWARF only supports MD5 * LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11). * CodeView (.PDB) supports MD5 SHA1 and SHA256. Fixes #68980. Tracking issue: #70401 rustc dev guide PR with further details: https://github.com/rust-lang/rustc-dev-guide/pull/623,THUMBS_UP,2020-03-19T18:13:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69718,MERGED,2020-03-04T22:41:38Z,2020-04-04T06:05:02Z,Add hash of source files in debug info,arlosi,6050e523bae6de61de4e060facc43dc512adaccd,19,Auto merge of #69718 - arlosi:debughash r=eddyb Add hash of source files in debug info LLVM supports placing the hash of source files inside the debug info. This information can be used by a debugger to verify that the source code matches the executable. This change adds support for both hash algorithms supported by LLVM MD5 and SHA1 controlled by a target option. * DWARF only supports MD5 * LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11). * CodeView (.PDB) supports MD5 SHA1 and SHA256. Fixes #68980. Tracking issue: #70401 rustc dev guide PR with further details: https://github.com/rust-lang/rustc-dev-guide/pull/623,THUMBS_UP,2020-03-26T06:24:46Z,est31,NA https://github.com/rust-lang/rust/pull/69736,MERGED,2020-03-05T15:53:48Z,2020-03-06T01:25:29Z,even more clippy cleanups,matthiaskrgr,67d735c4bf99dbbbe2eea9a90a0149ffa942f492,26,"Rollup merge of #69736 - matthiaskrgr:even_more_clippy r=Dylan-DPC even more clippy cleanups * Don't pass &mut where immutable reference (&) is sufficient (clippy::unnecessary_mut_passed) * Use more efficient &&str to String conversion (clippy::inefficient_to_string) * Don't always eval arguments inside .expect() use unwrap_or_else and closure. (clippy::expect_fun_call) * Use righthand '&' instead of lefthand ""ref"". (clippy::toplevel_ref_arg) * Use simple 'for i in x' loops instead of 'while let Some(i) = x.next()' loops on iterators. (clippy::while_let_on_iterator) * Const items have by default a static lifetime there's no need to annotate it. (clippy::redundant_static_lifetimes) * Remove redundant patterns when matching ( x @ _ to x) (clippy::redundant_pattern)",THUMBS_UP,2020-03-05T17:14:30Z,panaman67,NA https://github.com/rust-lang/rust/pull/69736,MERGED,2020-03-05T15:53:48Z,2020-03-06T01:25:29Z,even more clippy cleanups,matthiaskrgr,67d735c4bf99dbbbe2eea9a90a0149ffa942f492,26,"Rollup merge of #69736 - matthiaskrgr:even_more_clippy r=Dylan-DPC even more clippy cleanups * Don't pass &mut where immutable reference (&) is sufficient (clippy::unnecessary_mut_passed) * Use more efficient &&str to String conversion (clippy::inefficient_to_string) * Don't always eval arguments inside .expect() use unwrap_or_else and closure. (clippy::expect_fun_call) * Use righthand '&' instead of lefthand ""ref"". (clippy::toplevel_ref_arg) * Use simple 'for i in x' loops instead of 'while let Some(i) = x.next()' loops on iterators. (clippy::while_let_on_iterator) * Const items have by default a static lifetime there's no need to annotate it. (clippy::redundant_static_lifetimes) * Remove redundant patterns when matching ( x @ _ to x) (clippy::redundant_pattern)",HEART,2020-03-05T17:14:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/69747,MERGED,2020-03-05T21:09:10Z,2020-03-12T19:37:12Z,Rename rustc guide,spastorino,39c6405097c4584633841f7fb8bc31dc285c986d,50,Rollup merge of #69747 - spastorino:rename-rustc-guide r=pietroalbini Rename rustc guide This is in preparation for https://github.com/rust-lang/rustc-guide/issues/470 Needs to be merged after we actually rename the guide. Have used this to rename: `git grep -l 'rustc_guide' | xargs sed -i 's/rustc_guide/rustc_dev_guide/g'` `git grep -l 'rustc-guide' | xargs sed -i 's/rustc-guide/rustc-dev-guide/g'` `git grep -l 'rustc guide' | xargs sed -i 's/rustc guide/rustc dev guide/g'`,THUMBS_UP,2020-03-05T22:17:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69747,MERGED,2020-03-05T21:09:10Z,2020-03-12T19:37:12Z,Rename rustc guide,spastorino,39c6405097c4584633841f7fb8bc31dc285c986d,50,Rollup merge of #69747 - spastorino:rename-rustc-guide r=pietroalbini Rename rustc guide This is in preparation for https://github.com/rust-lang/rustc-guide/issues/470 Needs to be merged after we actually rename the guide. Have used this to rename: `git grep -l 'rustc_guide' | xargs sed -i 's/rustc_guide/rustc_dev_guide/g'` `git grep -l 'rustc-guide' | xargs sed -i 's/rustc-guide/rustc-dev-guide/g'` `git grep -l 'rustc guide' | xargs sed -i 's/rustc guide/rustc dev guide/g'`,THUMBS_UP,2020-03-06T04:24:32Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/69747,MERGED,2020-03-05T21:09:10Z,2020-03-12T19:37:12Z,Rename rustc guide,spastorino,39c6405097c4584633841f7fb8bc31dc285c986d,50,Rollup merge of #69747 - spastorino:rename-rustc-guide r=pietroalbini Rename rustc guide This is in preparation for https://github.com/rust-lang/rustc-guide/issues/470 Needs to be merged after we actually rename the guide. Have used this to rename: `git grep -l 'rustc_guide' | xargs sed -i 's/rustc_guide/rustc_dev_guide/g'` `git grep -l 'rustc-guide' | xargs sed -i 's/rustc-guide/rustc-dev-guide/g'` `git grep -l 'rustc guide' | xargs sed -i 's/rustc guide/rustc dev guide/g'`,THUMBS_UP,2020-03-06T04:46:03Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-05T22:56:23Z,lqd,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T00:57:56Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T01:47:06Z,est31,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T01:47:48Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T01:51:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T02:02:12Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T02:09:22Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T02:15:02Z,byte1234,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T02:18:09Z,sinkuu,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T03:07:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T06:44:34Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T07:34:45Z,oli-obk,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T08:36:25Z,darksv,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T08:39:46Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T09:45:22Z,matprec,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T13:23:03Z,mati865,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T13:45:00Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T14:56:10Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T21:57:18Z,kornholi,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T22:04:38Z,CryZe,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-06T22:41:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-07T03:48:31Z,cynecx,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-09T14:57:45Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-09T17:02:26Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-24T18:54:36Z,varkor,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-24T19:03:15Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-25T02:00:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-03-25T02:00:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2020-03-25T02:00:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-03-25T11:42:57Z,ljedrz,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-04-24T18:49:41Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-04-26T17:03:25Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-04-30T14:56:22Z,tmandry,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-05-26T09:24:28Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-05-26T09:24:29Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-06-07T06:21:33Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-06-09T13:16:40Z,taiki-e,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-06-09T18:08:01Z,bluss,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2020-06-10T10:47:22Z,iago-lito,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,ROCKET,2020-06-10T10:47:51Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-06-16T21:09:05Z,ebarnard,eabarnard@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-06-25T18:16:02Z,nightmared,git@nightmared.fr https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,ROCKET,2020-07-05T04:01:37Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2020-07-05T04:01:39Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-07-07T13:25:09Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-07-16T15:14:28Z,estebank,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-07-17T11:31:25Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-07-17T14:48:50Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2020-07-17T15:40:17Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2020-07-18T01:55:55Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-07-18T01:55:56Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-07-18T01:55:56Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,ROCKET,2020-07-18T01:55:57Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2020-07-21T08:20:42Z,Byron,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-07-21T08:20:43Z,Byron,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-08-06T19:12:07Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2020-08-14T11:09:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2021-04-29T14:11:41Z,InnocentusLime,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HOORAY,2021-04-29T14:11:41Z,InnocentusLime,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2021-04-29T14:11:41Z,InnocentusLime,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,ROCKET,2021-04-29T14:11:42Z,InnocentusLime,NA https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,HEART,2021-05-05T08:58:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,THUMBS_UP,2021-06-25T13:47:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69749,MERGED,2020-03-05T22:33:27Z,2020-07-21T06:56:31Z,Polymorphization,davidtwco,b52522ade1f6979a35b24087dadcf5ba5c981cbe,67,Auto merge of #69749 - davidtwco:issue-46477-polymorphization r=eddyb Polymorphization This PR implements an analysis to detect when functions could remain polymorphic during code generation. Fixes #46477 r? @eddyb cc @rust-lang/wg-mir-opt @nikomatsakis @pnkfelix,ROCKET,2021-06-25T13:47:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,THUMBS_UP,2020-03-22T23:10:14Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-03-29T09:26:37Z,mati865,NA https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-04-09T13:29:05Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-05-14T11:11:39Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-05-14T20:11:49Z,darksv,NA https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-05-14T22:11:58Z,bluss,NA https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-05-15T01:33:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-05-15T02:00:07Z,tesuji,NA https://github.com/rust-lang/rust/pull/69756,MERGED,2020-03-06T03:58:16Z,2020-05-14T09:59:22Z,Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1,wesleywiser,7c34d8d6629506a596215886e5fc4bb2b04b00ae,16,Auto merge of #69756 - wesleywiser:simplify_try r=oli-obk Modify SimplifyArmIdentity so it can trigger on mir-opt-level=1 I also added test cases to make sure the optimization can fire on all of these cases: ```rust fn case_1(o: Option) -> Option { match o { Some(u) => Some(u) None => None } } fn case2(r: Result) -> Result { match r { Ok(u) => Ok(u) Err(i) => Err(i) } } fn case3(r: Result) -> Result { let u = r?; Ok(u) } ``` Without MIR inlining this still does not completely optimize away the `?` operator because the `Try::into_result()` `From::from()` and `Try::from_error()` calls still exist. This does move us a bit closer to that goal though because: - We can now run the pass on mir-opt-level=1 - We no longer depend on the copy propagation pass running which is unlikely to stabilize anytime soon. Fixes #66855,HOORAY,2020-07-24T22:55:53Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/69760,MERGED,2020-03-06T07:07:39Z,2020-03-11T16:17:47Z,Improve expression & attribute parsing,Centril,9674c09ae9b0c520150208bbfd8c66019edbb958,59,Rollup merge of #69760 - Centril:parse-expr-improve r=estebank Improve expression & attribute parsing This PR includes misc improvements to expression and attribute parsing. 1. Some code simplifications 2. Better recovery for various block forms e.g. `loop statements }` (missing `{` after `loop`). (See e.g. `block-no-opening-brace.rs` among others for examples.) 3. Added recovery for e.g. `unsafe $b` where `$b` refers to a `block` macro fragment. (See `bad-interpolated-block.rs` for examples.) 4. ^--- These are done so that code sharing in block parsing is increased. 5. Added recovery for e.g. `'label: loop { ... }` (See `labeled-no-colon-expr.rs`.) 6. Added recovery for e.g. `&'lifetime expr` (See `regions-out-of-scope-slice.rs`.) 7. Added recovery for e.g. `fn foo() = expr;` (See `fn-body-eq-expr-semi.rs`.) 8. Simplified attribute parsing code & slightly improved diagnostics. 9. Added recovery for e.g. `Box<('a) + Trait>`. 10. Added recovery for e.g `if true #[attr] {} else #[attr] {} else #[attr] if true {}`. r? @estebank,HEART,2020-03-20T11:02:27Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69776,MERGED,2020-03-06T13:54:14Z,2020-03-08T14:43:44Z,Fix & test leak of some BTreeMap nodes on panic during `into_iter`,ssomers,f497325b13fea12b5771b0f123880847598dd9d1,2,Rollup merge of #69776 - ssomers:fix69769 r=Mark-Simulacrum Fix & test leak of some BTreeMap nodes on panic during `into_iter` Fixes #69769,HEART,2020-03-06T17:30:59Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69776,MERGED,2020-03-06T13:54:14Z,2020-03-08T14:43:44Z,Fix & test leak of some BTreeMap nodes on panic during `into_iter`,ssomers,f497325b13fea12b5771b0f123880847598dd9d1,2,Rollup merge of #69776 - ssomers:fix69769 r=Mark-Simulacrum Fix & test leak of some BTreeMap nodes on panic during `into_iter` Fixes #69769,HEART,2020-03-13T08:12:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69778,MERGED,2020-03-06T15:49:22Z,2020-03-23T01:37:25Z,perf(dep_graph): Avoid allocating a set on when the number reads are …,Marwes,e4b01c7791446b2f79a1b1d517223378df2bf5f2,1,Auto merge of #69778 - Marwes:dep_graph r=davidtwco perf(dep_graph): Avoid allocating a set on when the number reads are … …small `reserve_and_rehash` takes up 1.4% of the runtime on the `packed-simd` benchmark which I believe is due to the number of reads are very low in many cases (see https://github.com/rust-lang/rust/pull/50565 for instance). This avoids allocating the set until we start allocating the `reads` `SmallVec` but it is possible that a lower limit might be better (not tested since the improvement will be hard to spot either way).,ROCKET,2020-06-06T23:43:54Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/69784,MERGED,2020-03-06T20:18:30Z,2020-03-31T17:25:30Z,Optimize strip_prefix and strip_suffix with str patterns,benesch,9ee373fd945511669775b8fd2c00990373ded8c7,3,Rollup merge of #69784 - benesch:fast-strip-prefix-suffix r=kennytm Optimize strip_prefix and strip_suffix with str patterns As mentioned in https://github.com/rust-lang/rust/issues/67302#issuecomment-585639226. I'm not sure whether adding these methods to `Pattern` is desirable—but they have default implementations so the change is backwards compatible. Plus it seems like they're slated for wholesale replacement soon anyway? #56345 ---- Constructing a Searcher in strip_prefix and strip_suffix is unnecessarily slow when the pattern is a fixed-length string. Add strip_prefix and strip_suffix methods to the Pattern trait and add optimized implementations of these methods in the str implementation. The old implementation is retained as the default for these methods.,THUMBS_UP,2020-03-07T04:36:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/69802,MERGED,2020-03-07T14:09:26Z,2020-03-13T22:24:52Z,fix more clippy findings,matthiaskrgr,8e17c8366c48f78f0fafe03c311cb0fd9b66ec50,23,"Rollup merge of #69802 - matthiaskrgr:cl1ppy r=Dylan-DPC fix more clippy findings * reduce references on match patterns (clippy::match_ref_pats) * Use writeln!(fmt ""word"") instead of write!(fmt ""word\n"") (clippy::write_with_newline) * libtest: remove redundant argument to writeln!() (clippy::writeln_empty_string) * remove unneeded mutable references (cippy::unnecessary_mut_passed) * libtest: declare variables as floats instead of casting them (clippy::unnecessary_cast) * rustdoc: remove redundant static lifetimes (clippy::redundant_static_lifetimes) * call .as_deref() instead of .as_ref().map(Deref::deref) (clippy::option_as_ref_deref) * iterate over a maps values directly. (clippy::for_kv_map) * rustdoc: simplify boolean condition (clippy::nonminimal_bool) * Use ?-operator in more places (clippy::question_mark had some false negatives fixed recently) * rustdoc: Use .any(p) instead of find(p).is_some(). (clippy::search_is_some) * rustdoc: don't call into_iter() on iterator. (clippy::identity_conversion)",HEART,2020-03-07T19:10:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/69808,MERGED,2020-03-07T19:24:06Z,2020-05-02T00:22:29Z,Avoid duplicating code for each query,cjgillot,dba944a6b79caf0056ddd282de01de70a0ff8a36,10,Auto merge of #69808 - cjgillot:vtbl r=pnkfelix Avoid duplicating code for each query There are at the moment roughly 170 queries in librustc. The way `ty::query` is structured a lot of code is duplicated for each query. I suspect this to be responsible for a part of librustc'c compile time. The first part of this PR reduces the amount of code generic on the query replacing it by code generic on the key-value types. I can split it out if needed. In a second part the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits are made into a virtual dispatch table. This allows to reduce even more the number of generated functions. This allows to save 1.5s on check build and 10% on the size of the librustc.rlib. (Attributed roughly half and half). My computer is not good enough to measure properly compiling time. I have no idea of the effect on performance. A perf run may be required. cc #65031,HEART,2020-03-07T19:27:50Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69808,MERGED,2020-03-07T19:24:06Z,2020-05-02T00:22:29Z,Avoid duplicating code for each query,cjgillot,dba944a6b79caf0056ddd282de01de70a0ff8a36,10,Auto merge of #69808 - cjgillot:vtbl r=pnkfelix Avoid duplicating code for each query There are at the moment roughly 170 queries in librustc. The way `ty::query` is structured a lot of code is duplicated for each query. I suspect this to be responsible for a part of librustc'c compile time. The first part of this PR reduces the amount of code generic on the query replacing it by code generic on the key-value types. I can split it out if needed. In a second part the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits are made into a virtual dispatch table. This allows to reduce even more the number of generated functions. This allows to save 1.5s on check build and 10% on the size of the librustc.rlib. (Attributed roughly half and half). My computer is not good enough to measure properly compiling time. I have no idea of the effect on performance. A perf run may be required. cc #65031,HEART,2020-03-07T20:11:00Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69808,MERGED,2020-03-07T19:24:06Z,2020-05-02T00:22:29Z,Avoid duplicating code for each query,cjgillot,dba944a6b79caf0056ddd282de01de70a0ff8a36,10,Auto merge of #69808 - cjgillot:vtbl r=pnkfelix Avoid duplicating code for each query There are at the moment roughly 170 queries in librustc. The way `ty::query` is structured a lot of code is duplicated for each query. I suspect this to be responsible for a part of librustc'c compile time. The first part of this PR reduces the amount of code generic on the query replacing it by code generic on the key-value types. I can split it out if needed. In a second part the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits are made into a virtual dispatch table. This allows to reduce even more the number of generated functions. This allows to save 1.5s on check build and 10% on the size of the librustc.rlib. (Attributed roughly half and half). My computer is not good enough to measure properly compiling time. I have no idea of the effect on performance. A perf run may be required. cc #65031,HEART,2020-03-07T20:11:18Z,estebank,NA https://github.com/rust-lang/rust/pull/69808,MERGED,2020-03-07T19:24:06Z,2020-05-02T00:22:29Z,Avoid duplicating code for each query,cjgillot,dba944a6b79caf0056ddd282de01de70a0ff8a36,10,Auto merge of #69808 - cjgillot:vtbl r=pnkfelix Avoid duplicating code for each query There are at the moment roughly 170 queries in librustc. The way `ty::query` is structured a lot of code is duplicated for each query. I suspect this to be responsible for a part of librustc'c compile time. The first part of this PR reduces the amount of code generic on the query replacing it by code generic on the key-value types. I can split it out if needed. In a second part the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits are made into a virtual dispatch table. This allows to reduce even more the number of generated functions. This allows to save 1.5s on check build and 10% on the size of the librustc.rlib. (Attributed roughly half and half). My computer is not good enough to measure properly compiling time. I have no idea of the effect on performance. A perf run may be required. cc #65031,HEART,2020-05-07T12:28:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69808,MERGED,2020-03-07T19:24:06Z,2020-05-02T00:22:29Z,Avoid duplicating code for each query,cjgillot,dba944a6b79caf0056ddd282de01de70a0ff8a36,10,Auto merge of #69808 - cjgillot:vtbl r=pnkfelix Avoid duplicating code for each query There are at the moment roughly 170 queries in librustc. The way `ty::query` is structured a lot of code is duplicated for each query. I suspect this to be responsible for a part of librustc'c compile time. The first part of this PR reduces the amount of code generic on the query replacing it by code generic on the key-value types. I can split it out if needed. In a second part the non-inlined methods in the `QueryAccessors` and `QueryDescription` traits are made into a virtual dispatch table. This allows to reduce even more the number of generated functions. This allows to save 1.5s on check build and 10% on the size of the librustc.rlib. (Attributed roughly half and half). My computer is not good enough to measure properly compiling time. I have no idea of the effect on performance. A perf run may be required. cc #65031,HEART,2020-05-10T08:28:55Z,lnicola,NA https://github.com/rust-lang/rust/pull/69809,MERGED,2020-03-07T20:45:01Z,2020-03-13T22:24:51Z,remove lifetimes that can be elided (clippy::needless_lifetimes),matthiaskrgr,c13548dccd297eb2f95d04ddc593c55b69381d8b,32,Rollup merge of #69809 - matthiaskrgr:lifetimes r=eddyb remove lifetimes that can be elided (clippy::needless_lifetimes),HEART,2020-03-08T01:17:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/69809,MERGED,2020-03-07T20:45:01Z,2020-03-13T22:24:51Z,remove lifetimes that can be elided (clippy::needless_lifetimes),matthiaskrgr,c13548dccd297eb2f95d04ddc593c55b69381d8b,32,Rollup merge of #69809 - matthiaskrgr:lifetimes r=eddyb remove lifetimes that can be elided (clippy::needless_lifetimes),HEART,2020-03-12T15:48:22Z,iago-lito,NA https://github.com/rust-lang/rust/pull/69812,MERGED,2020-03-07T22:23:30Z,2020-03-08T19:48:53Z,Refactorings to method/probe.rs and CrateId,Marwes,06689e212fbd95558c778ce753208223276bcac9,2,Rollup merge of #69812 - Marwes:refactor r=petrochenkov Refactorings to method/probe.rs and CrateId A couple of refactorings done while looking into performance improvements in method resolution.,HEART,2020-03-08T01:14:44Z,panaman67,NA https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-08T00:35:50Z,Lokathor,NA https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-08T09:40:34Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-10T12:08:47Z,tesuji,NA https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-12T22:03:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-17T19:57:24Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-03-24T04:06:06Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-04-23T14:18:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69813,MERGED,2020-03-08T00:23:42Z,2020-04-25T20:54:46Z,Implement BitOr and BitOrAssign for the NonZero integer types,thomcc,b6e03c464a0020f44a9e89af9e043fdb47889bfc,2,Rollup merge of #69813 - thomcc:nonzero-bitor r=Amanieu Implement BitOr and BitOrAssign for the NonZero integer types This provides overloaded operators for `NonZero$Int | NonZero$Int` `NonZero$Int | $Int` and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int` for symmetry. It's a pretty small conceptual addition but is good becasue but avoids a case where the operation is obviously sound but you'd otherwise need unsafe to do it. In crates trying to minimize `unsafe` usage this is unfortunate and makes working with `NonZero` types often not worth it even if the operations you're doing are clearly sound. I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information. I'm not entirely confident what version I should have put down so I followed https://www.whatrustisit.com. Hopefully it's correct for this. Apologies in advance if this has come up before but I couldn't find it.,THUMBS_UP,2020-05-01T10:05:25Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-08T14:25:45Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-08T14:26:05Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-08T16:45:24Z,sinkuu,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-08T18:11:47Z,CryZe,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-08T19:25:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-11T18:13:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-26T17:05:08Z,Virgiel,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-26T20:58:26Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-27T07:12:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-27T13:38:48Z,DianaNites,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-03-29T06:11:16Z,est31,NA https://github.com/rust-lang/rust/pull/69814,MERGED,2020-03-08T01:07:08Z,2020-03-19T09:14:57Z,Smaller and more correct generator codegen,jonas-schievink,5570a2374f1b50b1fb85ed247fcec8161eeb2530,2,Rollup merge of #69814 - jonas-schievink:gen-ret-unw r=Zoxc Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind respectively. Closes https://github.com/rust-lang/rust/issues/66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it ultimately reaching a `Resume` terminator which we already handled correctly. Future MIR optimizations might optimize that out though. r? @Zoxc,HOORAY,2020-05-06T13:27:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69825,MERGED,2020-03-08T13:18:53Z,2020-03-11T12:49:50Z,make `mem::discriminant` const,lcnr,dfbbd5d6ead535de08ff8d10e320194ac7585457,6,Rollup merge of #69825 - lcnr:discriminant r=oli-obk make `mem::discriminant` const implements #69821 which could be used as a tracking issue for `const_discriminant`. Should this be added to the meta tracking issue #57563? @Lokathor,THUMBS_UP,2020-03-08T15:59:19Z,Lokathor,NA https://github.com/rust-lang/rust/pull/69825,MERGED,2020-03-08T13:18:53Z,2020-03-11T12:49:50Z,make `mem::discriminant` const,lcnr,dfbbd5d6ead535de08ff8d10e320194ac7585457,6,Rollup merge of #69825 - lcnr:discriminant r=oli-obk make `mem::discriminant` const implements #69821 which could be used as a tracking issue for `const_discriminant`. Should this be added to the meta tracking issue #57563? @Lokathor,THUMBS_UP,2020-03-20T11:34:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69828,MERGED,2020-03-08T15:43:57Z,2020-03-11T16:17:42Z,fix memory leak when vec::IntoIter panics during drop,RalfJung,080d41391d84ccf61b1b3667e731981519f9d5b7,1,Rollup merge of #69828 - RalfJung:vec-leak r=kennytm fix memory leak when vec::IntoIter panics during drop Fixes https://github.com/rust-lang/rust/issues/69770,HEART,2020-03-20T00:16:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/69828,MERGED,2020-03-08T15:43:57Z,2020-03-11T16:17:42Z,fix memory leak when vec::IntoIter panics during drop,RalfJung,080d41391d84ccf61b1b3667e731981519f9d5b7,1,Rollup merge of #69828 - RalfJung:vec-leak r=kennytm fix memory leak when vec::IntoIter panics during drop Fixes https://github.com/rust-lang/rust/issues/69770,HEART,2020-03-20T07:04:15Z,updogliu,updogliu@gmail.com https://github.com/rust-lang/rust/pull/69828,MERGED,2020-03-08T15:43:57Z,2020-03-11T16:17:42Z,fix memory leak when vec::IntoIter panics during drop,RalfJung,080d41391d84ccf61b1b3667e731981519f9d5b7,1,Rollup merge of #69828 - RalfJung:vec-leak r=kennytm fix memory leak when vec::IntoIter panics during drop Fixes https://github.com/rust-lang/rust/issues/69770,HEART,2020-03-20T11:35:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/69828,MERGED,2020-03-08T15:43:57Z,2020-03-11T16:17:42Z,fix memory leak when vec::IntoIter panics during drop,RalfJung,080d41391d84ccf61b1b3667e731981519f9d5b7,1,Rollup merge of #69828 - RalfJung:vec-leak r=kennytm fix memory leak when vec::IntoIter panics during drop Fixes https://github.com/rust-lang/rust/issues/69770,THUMBS_UP,2020-03-26T02:41:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-08T23:37:36Z,CryZe,NA https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T02:50:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T06:08:34Z,95th,NA https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T07:56:45Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T08:00:55Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T14:15:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T15:41:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T15:48:30Z,jviide,jviide@iki.fi https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T16:18:40Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-09T23:55:39Z,tmandry,NA https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-11T18:11:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-03-11T19:05:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69837,MERGED,2020-03-08T22:13:04Z,2020-03-19T03:34:26Z,Use smaller discriminants for generators,jonas-schievink,4118ff61ec71a2b9869422ef1762b21051ce5e40,7,Rollup merge of #69837 - jonas-schievink:gen-discr-opt r=tmandry Use smaller discriminants for generators Closes https://github.com/rust-lang/rust/issues/69815 I'm not yet sure about the runtime performance impact of this so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on) * [x] Add test with a generator that has exactly 256 total states * [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant * [x] Add tests for the size of `Option<[generator]>` * [x] Add tests for the `discriminant_value` intrinsic in all cases,HOORAY,2020-05-03T13:11:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-03-08T22:22:20Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HEART,2020-03-09T08:01:54Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-03-09T08:02:55Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,ROCKET,2020-03-09T08:02:58Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-03-09T10:46:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-03-10T07:43:24Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HEART,2020-03-10T10:50:32Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-03-11T19:03:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69838,MERGED,2020-03-08T22:17:10Z,2020-03-19T03:34:25Z,Expansion-driven outline module parsing,Centril,23b79d83f2472bb310b4bb53f0bccbbaaab00044,47,Rollup merge of #69838 - Centril:expand-module r=petrochenkov Expansion-driven outline module parsing After this PR the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead the parser only leaves `mod foo;` in place in the AST with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid: ```rust #[cfg(FALSE)] mod foo { mod bar { mod baz; // `foo/bar/baz.rs` doesn't exist but no error! } } ``` Fixes https://github.com/rust-lang/rust/issues/64197. r? @petrochenkov,HOORAY,2020-06-05T07:34:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/69864,MERGED,2020-03-09T17:36:28Z,2020-12-02T20:03:03Z,unix: Extend UnixStream and UnixDatagram to send and receive file descriptors,LinkTed,af69066aa6afa7bff771a6ee9548b2b84a02a88a,11,Auto merge of #69864 - LinkTed:master r=Amanieu unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors by using `recvmsg` and `sendmsg` system call.,THUMBS_UP,2020-05-11T22:24:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69864,MERGED,2020-03-09T17:36:28Z,2020-12-02T20:03:03Z,unix: Extend UnixStream and UnixDatagram to send and receive file descriptors,LinkTed,af69066aa6afa7bff771a6ee9548b2b84a02a88a,11,Auto merge of #69864 - LinkTed:master r=Amanieu unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors by using `recvmsg` and `sendmsg` system call.,THUMBS_UP,2020-08-25T22:45:54Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/69864,MERGED,2020-03-09T17:36:28Z,2020-12-02T20:03:03Z,unix: Extend UnixStream and UnixDatagram to send and receive file descriptors,LinkTed,af69066aa6afa7bff771a6ee9548b2b84a02a88a,11,Auto merge of #69864 - LinkTed:master r=Amanieu unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors by using `recvmsg` and `sendmsg` system call.,THUMBS_UP,2020-09-28T13:26:41Z,voidc,NA https://github.com/rust-lang/rust/pull/69864,MERGED,2020-03-09T17:36:28Z,2020-12-02T20:03:03Z,unix: Extend UnixStream and UnixDatagram to send and receive file descriptors,LinkTed,af69066aa6afa7bff771a6ee9548b2b84a02a88a,11,Auto merge of #69864 - LinkTed:master r=Amanieu unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors by using `recvmsg` and `sendmsg` system call.,THUMBS_UP,2020-09-29T09:31:11Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/69864,MERGED,2020-03-09T17:36:28Z,2020-12-02T20:03:03Z,unix: Extend UnixStream and UnixDatagram to send and receive file descriptors,LinkTed,af69066aa6afa7bff771a6ee9548b2b84a02a88a,11,Auto merge of #69864 - LinkTed:master r=Amanieu unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors by using `recvmsg` and `sendmsg` system call.,THUMBS_UP,2020-10-21T15:54:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69866,MERGED,2020-03-09T18:43:06Z,2020-03-26T05:37:30Z,Rename `def_span` to `guess_head_span`,estebank,b105ac40188131b76ef02667847973caf54fd532,28,Rollup merge of #69866 - estebank:guess_head_span r=eddyb Rename `def_span` to `guess_head_span` r? @eddyb,THUMBS_UP,2020-03-09T18:55:41Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/69866,MERGED,2020-03-09T18:43:06Z,2020-03-26T05:37:30Z,Rename `def_span` to `guess_head_span`,estebank,b105ac40188131b76ef02667847973caf54fd532,28,Rollup merge of #69866 - estebank:guess_head_span r=eddyb Rename `def_span` to `guess_head_span` r? @eddyb,THUMBS_UP,2020-03-10T19:39:33Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/69870,MERGED,2020-03-09T22:23:12Z,2020-03-17T05:24:26Z,expand: Implement something similar to `#[cfg(accessible(path))]`,petrochenkov,9fc5c2d00d9834549846a4d6528219f0b1667c9c,22,"Rollup merge of #69870 - petrochenkov:cfgacc r=matthewjasper expand: Implement something similar to `#[cfg(accessible(path))]` cc https://github.com/rust-lang/rust/issues/64797 The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable and `cfg` cannot wait but macros can wait. Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`. This implementation is also incomplete in the sense that it never returns ""false"" from `cfg_accessible(path)` it requires some tweaks to resolve which is not quite ready to answer queries like this during early resolution. However the most important part of this PR is not `cfg_accessible` itself but expansion infrastructure for retrying expansions. Before this PR we could say ""we cannot resolve this macro path let's try it later"" with this PR we can say ""we cannot expand this macro let's try it later"" as well. This is a pre-requisite for - turning `#[derive(...)]` into a regular attribute macro - properly supporting eager expansion for macros that cannot yet be resolved like ``` fn main() { println!(not_available_yet!()); } macro_rules! make_available { () => { #[macro_export] macro_rules! not_available_yet { () => { ""Hello world!"" } }} } make_available!(); ```",HEART,2020-03-11T16:56:17Z,estebank,NA https://github.com/rust-lang/rust/pull/69870,MERGED,2020-03-09T22:23:12Z,2020-03-17T05:24:26Z,expand: Implement something similar to `#[cfg(accessible(path))]`,petrochenkov,9fc5c2d00d9834549846a4d6528219f0b1667c9c,22,"Rollup merge of #69870 - petrochenkov:cfgacc r=matthewjasper expand: Implement something similar to `#[cfg(accessible(path))]` cc https://github.com/rust-lang/rust/issues/64797 The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable and `cfg` cannot wait but macros can wait. Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`. This implementation is also incomplete in the sense that it never returns ""false"" from `cfg_accessible(path)` it requires some tweaks to resolve which is not quite ready to answer queries like this during early resolution. However the most important part of this PR is not `cfg_accessible` itself but expansion infrastructure for retrying expansions. Before this PR we could say ""we cannot resolve this macro path let's try it later"" with this PR we can say ""we cannot expand this macro let's try it later"" as well. This is a pre-requisite for - turning `#[derive(...)]` into a regular attribute macro - properly supporting eager expansion for macros that cannot yet be resolved like ``` fn main() { println!(not_available_yet!()); } macro_rules! make_available { () => { #[macro_export] macro_rules! not_available_yet { () => { ""Hello world!"" } }} } make_available!(); ```",HEART,2020-03-11T18:18:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69870,MERGED,2020-03-09T22:23:12Z,2020-03-17T05:24:26Z,expand: Implement something similar to `#[cfg(accessible(path))]`,petrochenkov,9fc5c2d00d9834549846a4d6528219f0b1667c9c,22,"Rollup merge of #69870 - petrochenkov:cfgacc r=matthewjasper expand: Implement something similar to `#[cfg(accessible(path))]` cc https://github.com/rust-lang/rust/issues/64797 The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable and `cfg` cannot wait but macros can wait. Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`. This implementation is also incomplete in the sense that it never returns ""false"" from `cfg_accessible(path)` it requires some tweaks to resolve which is not quite ready to answer queries like this during early resolution. However the most important part of this PR is not `cfg_accessible` itself but expansion infrastructure for retrying expansions. Before this PR we could say ""we cannot resolve this macro path let's try it later"" with this PR we can say ""we cannot expand this macro let's try it later"" as well. This is a pre-requisite for - turning `#[derive(...)]` into a regular attribute macro - properly supporting eager expansion for macros that cannot yet be resolved like ``` fn main() { println!(not_available_yet!()); } macro_rules! make_available { () => { #[macro_export] macro_rules! not_available_yet { () => { ""Hello world!"" } }} } make_available!(); ```",HEART,2020-03-12T03:16:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/69870,MERGED,2020-03-09T22:23:12Z,2020-03-17T05:24:26Z,expand: Implement something similar to `#[cfg(accessible(path))]`,petrochenkov,9fc5c2d00d9834549846a4d6528219f0b1667c9c,22,"Rollup merge of #69870 - petrochenkov:cfgacc r=matthewjasper expand: Implement something similar to `#[cfg(accessible(path))]` cc https://github.com/rust-lang/rust/issues/64797 The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable and `cfg` cannot wait but macros can wait. Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`. This implementation is also incomplete in the sense that it never returns ""false"" from `cfg_accessible(path)` it requires some tweaks to resolve which is not quite ready to answer queries like this during early resolution. However the most important part of this PR is not `cfg_accessible` itself but expansion infrastructure for retrying expansions. Before this PR we could say ""we cannot resolve this macro path let's try it later"" with this PR we can say ""we cannot expand this macro let's try it later"" as well. This is a pre-requisite for - turning `#[derive(...)]` into a regular attribute macro - properly supporting eager expansion for macros that cannot yet be resolved like ``` fn main() { println!(not_available_yet!()); } macro_rules! make_available { () => { #[macro_export] macro_rules! not_available_yet { () => { ""Hello world!"" } }} } make_available!(); ```",THUMBS_DOWN,2020-03-17T13:56:16Z,AlphaHot,NA https://github.com/rust-lang/rust/pull/69878,MERGED,2020-03-10T03:23:28Z,2020-03-26T05:37:29Z,Tweak chained operators diagnostic,estebank,9fa4953aa440cb85d13d6cc2a8a532a7d674cfa3,6,Rollup merge of #69878 - estebank:chained-ops r=Centril Tweak chained operators diagnostic Use more selective spans Improve suggestion output Be more selective when displaying suggestions Silence some knock-down type errors r? @Centril,HEART,2020-03-10T03:28:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/69889,CLOSED,2020-03-10T12:56:44Z,2020-03-18T15:04:13Z,Overhaul of the `AllocRef` trait to match allocator-wg's latest consens,TimDiekmann,NA,NA,NA,THUMBS_UP,2020-03-10T13:40:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/69889,CLOSED,2020-03-10T12:56:44Z,2020-03-18T15:04:13Z,Overhaul of the `AllocRef` trait to match allocator-wg's latest consens,TimDiekmann,NA,NA,NA,THUMBS_UP,2020-03-10T15:15:23Z,Lokathor,NA https://github.com/rust-lang/rust/pull/69889,CLOSED,2020-03-10T12:56:44Z,2020-03-18T15:04:13Z,Overhaul of the `AllocRef` trait to match allocator-wg's latest consens,TimDiekmann,NA,NA,NA,THUMBS_UP,2020-03-10T17:49:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/69889,CLOSED,2020-03-10T12:56:44Z,2020-03-18T15:04:13Z,Overhaul of the `AllocRef` trait to match allocator-wg's latest consens,TimDiekmann,NA,NA,NA,THUMBS_UP,2020-03-10T21:49:45Z,Wodann,NA https://github.com/rust-lang/rust/pull/69901,MERGED,2020-03-10T21:31:42Z,2020-03-21T16:42:03Z,add #[rustc_layout(debug)],RalfJung,fd3f9176c35f7918c46066af57078a96696e59c7,4,Rollup merge of #69901 - RalfJung:rustc_layout r=eddyb add #[rustc_layout(debug)] @eddyb recently told me about the `#[rustc_layout]` attribute and I think it would be very useful if it could be used to print all the layout information Rust has about a type. When working with layouts (e.g. in Miri) it is often not clear how certain surface language features get represented internally. I have some awful hacks locally to be able to dump this debug information; with this attribute I could get it on the playground which is so much better. :),THUMBS_UP,2020-03-10T22:30:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69901,MERGED,2020-03-10T21:31:42Z,2020-03-21T16:42:03Z,add #[rustc_layout(debug)],RalfJung,fd3f9176c35f7918c46066af57078a96696e59c7,4,Rollup merge of #69901 - RalfJung:rustc_layout r=eddyb add #[rustc_layout(debug)] @eddyb recently told me about the `#[rustc_layout]` attribute and I think it would be very useful if it could be used to print all the layout information Rust has about a type. When working with layouts (e.g. in Miri) it is often not clear how certain surface language features get represented internally. I have some awful hacks locally to be able to dump this debug information; with this attribute I could get it on the playground which is so much better. :),THUMBS_UP,2020-03-10T23:36:53Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69901,MERGED,2020-03-10T21:31:42Z,2020-03-21T16:42:03Z,add #[rustc_layout(debug)],RalfJung,fd3f9176c35f7918c46066af57078a96696e59c7,4,Rollup merge of #69901 - RalfJung:rustc_layout r=eddyb add #[rustc_layout(debug)] @eddyb recently told me about the `#[rustc_layout]` attribute and I think it would be very useful if it could be used to print all the layout information Rust has about a type. When working with layouts (e.g. in Miri) it is often not clear how certain surface language features get represented internally. I have some awful hacks locally to be able to dump this debug information; with this attribute I could get it on the playground which is so much better. :),THUMBS_UP,2020-03-11T18:17:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-11T10:54:28Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-11T13:23:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-11T14:00:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-11T19:56:48Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-13T14:10:42Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-13T15:27:09Z,lqd,NA https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-16T21:41:58Z,mati865,NA https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-03-17T18:05:02Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69916,MERGED,2020-03-11T10:53:06Z,2020-03-27T16:10:09Z,Enable blessing of mir opt tests,oli-obk,0a2df620735134d5907e4d4e25241a64cec2ceac,24,Auto merge of #69916 - oli-obk:mir_bless r=eddyb Enable blessing of mir opt tests cc @rust-lang/wg-mir-opt cc @RalfJung Long overdue but now you can finally just add a ```rust // EMIT_MIR rustc.function_name.MirPassName.before.mir ``` (or `after.mir` since most of the time you want to know the MIR after a pass). A `--bless` invocation will automatically create the files for you. I suggest we do this for all mir opt tests that have all of the MIR in their source anyway If you use `rustc.function.MirPass.diff` you only get the diff that the MIR pass causes on the MIR. Fixes #67865,HEART,2020-04-02T18:48:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69922,MERGED,2020-03-11T13:32:55Z,2020-03-17T18:27:42Z,implement zeroed and uninitialized with MaybeUninit,RalfJung,7a7ca8238f3b1b09d18b3e0cc05f44095cfcb673,10,Rollup merge of #69922 - RalfJung:less-intrinsic r=oli-obk implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: https://github.com/rust-lang/rust/pull/62150). The last change [got reverted](https://github.com/rust-lang/rust/pull/63343) because it [caused](https://github.com/rust-lang/rust/issues/62825) some [issues](https://github.com/rust-lang/rust/issues/52898#issuecomment-512182438) in [code that incorrectly used these functions](https://github.com/erlepereira/x11-rs/issues/99). Since then the [problematic code has been fixed](https://github.com/erlepereira/x11-rs/pull/101) and rustc [gained a lint](https://github.com/rust-lang/rust/pull/63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](https://github.com/rust-lang/rust/pull/66059) instead of causing UB for some incorrect uses. Fixes https://github.com/rust-lang/rust/issues/62825,HOORAY,2020-03-11T13:54:14Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/69922,MERGED,2020-03-11T13:32:55Z,2020-03-17T18:27:42Z,implement zeroed and uninitialized with MaybeUninit,RalfJung,7a7ca8238f3b1b09d18b3e0cc05f44095cfcb673,10,Rollup merge of #69922 - RalfJung:less-intrinsic r=oli-obk implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: https://github.com/rust-lang/rust/pull/62150). The last change [got reverted](https://github.com/rust-lang/rust/pull/63343) because it [caused](https://github.com/rust-lang/rust/issues/62825) some [issues](https://github.com/rust-lang/rust/issues/52898#issuecomment-512182438) in [code that incorrectly used these functions](https://github.com/erlepereira/x11-rs/issues/99). Since then the [problematic code has been fixed](https://github.com/erlepereira/x11-rs/pull/101) and rustc [gained a lint](https://github.com/rust-lang/rust/pull/63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](https://github.com/rust-lang/rust/pull/66059) instead of causing UB for some incorrect uses. Fixes https://github.com/rust-lang/rust/issues/62825,ROCKET,2020-03-11T13:54:15Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/69922,MERGED,2020-03-11T13:32:55Z,2020-03-17T18:27:42Z,implement zeroed and uninitialized with MaybeUninit,RalfJung,7a7ca8238f3b1b09d18b3e0cc05f44095cfcb673,10,Rollup merge of #69922 - RalfJung:less-intrinsic r=oli-obk implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: https://github.com/rust-lang/rust/pull/62150). The last change [got reverted](https://github.com/rust-lang/rust/pull/63343) because it [caused](https://github.com/rust-lang/rust/issues/62825) some [issues](https://github.com/rust-lang/rust/issues/52898#issuecomment-512182438) in [code that incorrectly used these functions](https://github.com/erlepereira/x11-rs/issues/99). Since then the [problematic code has been fixed](https://github.com/erlepereira/x11-rs/pull/101) and rustc [gained a lint](https://github.com/rust-lang/rust/pull/63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](https://github.com/rust-lang/rust/pull/66059) instead of causing UB for some incorrect uses. Fixes https://github.com/rust-lang/rust/issues/62825,ROCKET,2020-03-11T17:31:24Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/69922,MERGED,2020-03-11T13:32:55Z,2020-03-17T18:27:42Z,implement zeroed and uninitialized with MaybeUninit,RalfJung,7a7ca8238f3b1b09d18b3e0cc05f44095cfcb673,10,Rollup merge of #69922 - RalfJung:less-intrinsic r=oli-obk implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: https://github.com/rust-lang/rust/pull/62150). The last change [got reverted](https://github.com/rust-lang/rust/pull/63343) because it [caused](https://github.com/rust-lang/rust/issues/62825) some [issues](https://github.com/rust-lang/rust/issues/52898#issuecomment-512182438) in [code that incorrectly used these functions](https://github.com/erlepereira/x11-rs/issues/99). Since then the [problematic code has been fixed](https://github.com/erlepereira/x11-rs/pull/101) and rustc [gained a lint](https://github.com/rust-lang/rust/pull/63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](https://github.com/rust-lang/rust/pull/66059) instead of causing UB for some incorrect uses. Fixes https://github.com/rust-lang/rust/issues/62825,HOORAY,2020-03-11T19:11:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69922,MERGED,2020-03-11T13:32:55Z,2020-03-17T18:27:42Z,implement zeroed and uninitialized with MaybeUninit,RalfJung,7a7ca8238f3b1b09d18b3e0cc05f44095cfcb673,10,Rollup merge of #69922 - RalfJung:less-intrinsic r=oli-obk implement zeroed and uninitialized with MaybeUninit This is the second attempt of doing such a change (first PR: https://github.com/rust-lang/rust/pull/62150). The last change [got reverted](https://github.com/rust-lang/rust/pull/63343) because it [caused](https://github.com/rust-lang/rust/issues/62825) some [issues](https://github.com/rust-lang/rust/issues/52898#issuecomment-512182438) in [code that incorrectly used these functions](https://github.com/erlepereira/x11-rs/issues/99). Since then the [problematic code has been fixed](https://github.com/erlepereira/x11-rs/pull/101) and rustc [gained a lint](https://github.com/rust-lang/rust/pull/63346) that is able to detect many misuses of these functions statically and a [dynamic check that panics](https://github.com/rust-lang/rust/pull/66059) instead of causing UB for some incorrect uses. Fixes https://github.com/rust-lang/rust/issues/62825,HOORAY,2020-03-12T00:54:19Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/69929,MERGED,2020-03-11T17:27:16Z,2020-03-19T09:14:52Z,Regenerate tables for Unicode 13.0.0,cuviper,904909fd06cd203cea1651910962943b8338286c,2,Rollup merge of #69929 - cuviper:unicode-13.0.0 r=Mark-Simulacrum Regenerate tables for Unicode 13.0.0,HOORAY,2020-03-18T09:26:44Z,iago-lito,NA https://github.com/rust-lang/rust/pull/69929,MERGED,2020-03-11T17:27:16Z,2020-03-19T09:14:52Z,Regenerate tables for Unicode 13.0.0,cuviper,904909fd06cd203cea1651910962943b8338286c,2,Rollup merge of #69929 - cuviper:unicode-13.0.0 r=Mark-Simulacrum Regenerate tables for Unicode 13.0.0,HOORAY,2020-05-31T15:08:19Z,95th,NA https://github.com/rust-lang/rust/pull/69929,MERGED,2020-03-11T17:27:16Z,2020-03-19T09:14:52Z,Regenerate tables for Unicode 13.0.0,cuviper,904909fd06cd203cea1651910962943b8338286c,2,Rollup merge of #69929 - cuviper:unicode-13.0.0 r=Mark-Simulacrum Regenerate tables for Unicode 13.0.0,HOORAY,2020-07-13T09:01:20Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/69935,MERGED,2020-03-11T19:40:16Z,2020-03-20T19:03:04Z,codegen/mir: support polymorphic `InstanceDef`s,davidtwco,9dc699430f55af49a7e4f17de9a4482bfd54d481,7,Rollup merge of #69935 - davidtwco:issue-69925 r=eddyb codegen/mir: support polymorphic `InstanceDef`s cc #69925 This PR modifies the use of `subst_and_normalize_erasing_regions` on parts of the MIR bodies returned from `instance_mir` so that `InstanceDef::CloneShim` and `InstanceDef::DropGlue` (where there is a type) do not perform substitutions. This avoids double substitutions and enables polymorphic `InstanceDef`s. r? @eddyb cc @nikomatsakis,HEART,2020-03-12T03:33:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/69937,MERGED,2020-03-11T20:16:46Z,2020-03-29T04:07:09Z,ASCII methods on OsStr,TyPR124,d584f5a386c4d06afbe1d7375bfe43c08b19549d,5,Rollup merge of #69937 - TyPR124:osstr_ascii r=dtolnay ASCII methods on OsStr Would close #69566 I don't know enough about encodings to know if this is a valid change however the comment on the issue suggests it could be. This does two things: 1. Makes ASCII methods available on OsStr 2. Makes it possible to obtain a `&mut OsStr`. This is necessary to actually use `OsStr::make_ascii_*case` methods since they modify the underlying value. As far as I can tell the only way to modify a `&mut OsStr` is via the methods I just added. My original hope was to have these methods on `OsStrExt` for Windows since the standard library already assumes `make_ascii_uppercase` is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms I can move the methods to the ext trait instead.,HOORAY,2020-03-19T15:15:13Z,DianaNites,NA https://github.com/rust-lang/rust/pull/69937,MERGED,2020-03-11T20:16:46Z,2020-03-29T04:07:09Z,ASCII methods on OsStr,TyPR124,d584f5a386c4d06afbe1d7375bfe43c08b19549d,5,Rollup merge of #69937 - TyPR124:osstr_ascii r=dtolnay ASCII methods on OsStr Would close #69566 I don't know enough about encodings to know if this is a valid change however the comment on the issue suggests it could be. This does two things: 1. Makes ASCII methods available on OsStr 2. Makes it possible to obtain a `&mut OsStr`. This is necessary to actually use `OsStr::make_ascii_*case` methods since they modify the underlying value. As far as I can tell the only way to modify a `&mut OsStr` is via the methods I just added. My original hope was to have these methods on `OsStrExt` for Windows since the standard library already assumes `make_ascii_uppercase` is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms I can move the methods to the ext trait instead.,HOORAY,2020-04-15T03:06:22Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/69940,MERGED,2020-03-11T22:59:58Z,2020-03-23T12:40:13Z,librustc_codegen_llvm: Replace deprecated API usage,tmiasko,61a56fbe0053cbf5aee5967a3211dcd17b605710,8,Rollup merge of #69940 - tmiasko:llvm-api r=hanna-kruppe librustc_codegen_llvm: Replace deprecated API usage,HEART,2020-03-12T04:15:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/69940,MERGED,2020-03-11T22:59:58Z,2020-03-23T12:40:13Z,librustc_codegen_llvm: Replace deprecated API usage,tmiasko,61a56fbe0053cbf5aee5967a3211dcd17b605710,8,Rollup merge of #69940 - tmiasko:llvm-api r=hanna-kruppe librustc_codegen_llvm: Replace deprecated API usage,HEART,2020-03-12T10:32:29Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/69942,MERGED,2020-03-12T03:40:36Z,2020-03-23T12:40:12Z,Increase verbosity when suggesting subtle code changes,estebank,906b39958322c54b76de4f301976e7753777be4e,137,Rollup merge of #69942 - estebank:sized-verbose-sugg r=matthewjasper Increase verbosity when suggesting subtle code changes Do not suggest changes that are actually quite small inline to minimize the likelihood of confusion. Fix #69243.,THUMBS_UP,2020-03-13T22:31:26Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/69955,MERGED,2020-03-12T19:01:16Z,2020-03-21T16:41:59Z,Fix abort-on-eprintln during process shutdown,alexcrichton,276b54e9c930c4ff015e1958ad1c640deffd29b2,11,Rollup merge of #69955 - alexcrichton:stderr-infallible r=sfackler Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!` we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations since the `stderr` accessor should be infallible in more situations.,HEART,2020-03-12T19:06:52Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/69955,MERGED,2020-03-12T19:01:16Z,2020-03-21T16:41:59Z,Fix abort-on-eprintln during process shutdown,alexcrichton,276b54e9c930c4ff015e1958ad1c640deffd29b2,11,Rollup merge of #69955 - alexcrichton:stderr-infallible r=sfackler Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!` we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations since the `stderr` accessor should be infallible in more situations.,HEART,2020-03-12T23:09:05Z,pchickey,pat@moreproductive.org https://github.com/rust-lang/rust/pull/69968,MERGED,2020-03-13T02:24:33Z,2020-03-23T12:40:11Z,rustc: keep upvars tupled in {Closure Generator}Substs.,eddyb,bee074f032970fd1b59650c04a70e75eeee9c63b,65,"Rollup merge of #69968 - eddyb:tupled-closure-captures r=nikomatsakis rustc: keep upvars tupled in {Closure Generator}Substs. Previously each closure/generator capture's (aka ""upvar"") type was tracked as one ""synthetic"" type parameter in the closure/generator substs and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`. Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars and `TyCtxt` is not available there) which is how I got started on this but it's also possible that the `generics_of` queries are slowing down `{Closure Generator}Substs` methods. To give an example for a `foo::::{closure#0}` with captures `x: X` and `y: Y` substs are: * before this PR: `[T U /*kind*/ /*signature*/ X Y]` * after this PR: `[T U /*kind*/ /*signature*/ (X Y)]` You can see that with this PR no matter how many captures the last 3 entries in the substs (or 5 for a generator) are always the ""synthetic"" ones with the last one being the tuple of capture types. r? @nikomatsakis cc @Zoxc",THUMBS_UP,2020-03-13T10:12:02Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/69968,MERGED,2020-03-13T02:24:33Z,2020-03-23T12:40:11Z,rustc: keep upvars tupled in {Closure Generator}Substs.,eddyb,bee074f032970fd1b59650c04a70e75eeee9c63b,65,"Rollup merge of #69968 - eddyb:tupled-closure-captures r=nikomatsakis rustc: keep upvars tupled in {Closure Generator}Substs. Previously each closure/generator capture's (aka ""upvar"") type was tracked as one ""synthetic"" type parameter in the closure/generator substs and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`. Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars and `TyCtxt` is not available there) which is how I got started on this but it's also possible that the `generics_of` queries are slowing down `{Closure Generator}Substs` methods. To give an example for a `foo::::{closure#0}` with captures `x: X` and `y: Y` substs are: * before this PR: `[T U /*kind*/ /*signature*/ X Y]` * after this PR: `[T U /*kind*/ /*signature*/ (X Y)]` You can see that with this PR no matter how many captures the last 3 entries in the substs (or 5 for a generator) are always the ""synthetic"" ones with the last one being the tuple of capture types. r? @nikomatsakis cc @Zoxc",THUMBS_UP,2020-03-13T10:40:07Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/69969,MERGED,2020-03-13T03:53:11Z,2020-03-19T09:14:47Z,unix: Set a guard page at the end of signal stacks,iximeow,4c3a5a5da636f16ea0ada0a55960230760e4031c,1,Rollup merge of #69969 - iximeow:sigstack-guard-page r=cuviper unix: Set a guard page at the end of signal stacks This mitigates possible issues when signal stacks overflow which could manifest as segfaults or in unlucky circumstances possible clobbering of other memory values as stack overflows tend to enable. I went ahead and made a PR for this because it's a pretty small change though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have and the segfaults that could/should result instead [here](https://github.com/iximeow/jubilant-train).,HEART,2020-03-13T21:33:00Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/69969,MERGED,2020-03-13T03:53:11Z,2020-03-19T09:14:47Z,unix: Set a guard page at the end of signal stacks,iximeow,4c3a5a5da636f16ea0ada0a55960230760e4031c,1,Rollup merge of #69969 - iximeow:sigstack-guard-page r=cuviper unix: Set a guard page at the end of signal stacks This mitigates possible issues when signal stacks overflow which could manifest as segfaults or in unlucky circumstances possible clobbering of other memory values as stack overflows tend to enable. I went ahead and made a PR for this because it's a pretty small change though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have and the segfaults that could/should result instead [here](https://github.com/iximeow/jubilant-train).,HEART,2020-07-16T22:04:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-03-31T12:34:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-04-21T15:27:09Z,mcarton,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-04-28T23:58:48Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-07-15T17:55:06Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-07-23T08:13:58Z,elichai,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-08-19T16:55:23Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-10-28T16:15:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-10-28T16:46:26Z,taiki-e,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-11-17T17:45:09Z,untitaker,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-11-27T06:48:03Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2020-11-30T10:43:04Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2021-02-01T21:04:46Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/69985,CLOSED,2020-03-13T18:50:27Z,2021-08-27T13:47:58Z,Add `FromIterator` impl `for [T; N]`,lperlaki,NA,NA,NA,THUMBS_UP,2021-02-03T21:50:35Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/69989,MERGED,2020-03-13T23:24:20Z,2020-03-16T16:31:26Z,"resolve/hygiene: `macro_rules` are not ""legacy""",petrochenkov,8872d9057230e46f4bf35af5880cc6095a06e744,30,"Rollup merge of #69989 - petrochenkov:nolegacy r=eddyb matthewjasper resolve/hygiene: `macro_rules` are not ""legacy"" The ""modern"" vs ""legacy"" naming was introduced by jseyfried during initial implementation of macros 2.0. At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future. So this PR changes the naming ""legacy"" (when it implies ""macro_rules"") to ""macro_rules"". This should also help people reading this code because it's wasn't obvious that ""legacy"" actually meant ""macro_rules"" in these contexts. The most contentious renaming here is probably ``` fn modern -> fn normalize_to_macros_2_0 fn modern_and_legacy -> fn normalize_to_macro_rules ``` Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent` or `strip_non_opaque`/`strip_transparent` but they seemed less intuitive. The documentation to these functions can be found in `symbol.rs`. r? @matthewjasper",THUMBS_UP,2020-03-14T00:02:59Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/69989,MERGED,2020-03-13T23:24:20Z,2020-03-16T16:31:26Z,"resolve/hygiene: `macro_rules` are not ""legacy""",petrochenkov,8872d9057230e46f4bf35af5880cc6095a06e744,30,"Rollup merge of #69989 - petrochenkov:nolegacy r=eddyb matthewjasper resolve/hygiene: `macro_rules` are not ""legacy"" The ""modern"" vs ""legacy"" naming was introduced by jseyfried during initial implementation of macros 2.0. At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future. So this PR changes the naming ""legacy"" (when it implies ""macro_rules"") to ""macro_rules"". This should also help people reading this code because it's wasn't obvious that ""legacy"" actually meant ""macro_rules"" in these contexts. The most contentious renaming here is probably ``` fn modern -> fn normalize_to_macros_2_0 fn modern_and_legacy -> fn normalize_to_macro_rules ``` Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent` or `strip_non_opaque`/`strip_transparent` but they seemed less intuitive. The documentation to these functions can be found in `symbol.rs`. r? @matthewjasper",THUMBS_UP,2020-03-14T10:32:01Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/69989,MERGED,2020-03-13T23:24:20Z,2020-03-16T16:31:26Z,"resolve/hygiene: `macro_rules` are not ""legacy""",petrochenkov,8872d9057230e46f4bf35af5880cc6095a06e744,30,"Rollup merge of #69989 - petrochenkov:nolegacy r=eddyb matthewjasper resolve/hygiene: `macro_rules` are not ""legacy"" The ""modern"" vs ""legacy"" naming was introduced by jseyfried during initial implementation of macros 2.0. At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future. So this PR changes the naming ""legacy"" (when it implies ""macro_rules"") to ""macro_rules"". This should also help people reading this code because it's wasn't obvious that ""legacy"" actually meant ""macro_rules"" in these contexts. The most contentious renaming here is probably ``` fn modern -> fn normalize_to_macros_2_0 fn modern_and_legacy -> fn normalize_to_macro_rules ``` Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent` or `strip_non_opaque`/`strip_transparent` but they seemed less intuitive. The documentation to these functions can be found in `symbol.rs`. r? @matthewjasper",THUMBS_UP,2020-03-14T12:09:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/69989,MERGED,2020-03-13T23:24:20Z,2020-03-16T16:31:26Z,"resolve/hygiene: `macro_rules` are not ""legacy""",petrochenkov,8872d9057230e46f4bf35af5880cc6095a06e744,30,"Rollup merge of #69989 - petrochenkov:nolegacy r=eddyb matthewjasper resolve/hygiene: `macro_rules` are not ""legacy"" The ""modern"" vs ""legacy"" naming was introduced by jseyfried during initial implementation of macros 2.0. At this point it's clear that `macro_rules` are not going anywhere and won't be deprecated in the near future. So this PR changes the naming ""legacy"" (when it implies ""macro_rules"") to ""macro_rules"". This should also help people reading this code because it's wasn't obvious that ""legacy"" actually meant ""macro_rules"" in these contexts. The most contentious renaming here is probably ``` fn modern -> fn normalize_to_macros_2_0 fn modern_and_legacy -> fn normalize_to_macro_rules ``` Other alternatives that I could think of are `normalize_to_opaque`/`normalize_to_semitransparent` or `strip_non_opaque`/`strip_transparent` but they seemed less intuitive. The documentation to these functions can be found in `symbol.rs`. r? @matthewjasper",HEART,2020-03-14T22:24:30Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/69992,MERGED,2020-03-14T02:36:31Z,2020-03-16T06:22:35Z,Block version-specific docs from search engines,kornelski,d34ec3309fbda36e776977fed7da695a775c6195,1,Rollup merge of #69992 - kornelski:robots r=steveklabnik Block version-specific docs from search engines Latest stable beta and nightly URLs remain accessible because their URLs don't start with a version number. Robots.txt uses simple path prefixes so it's OK that the disallow rules aren't full directory paths. Direct links to old docs remain accessible to users because robots.txt only affects crawlers. With this change old docs for specific old versions of Rust won't pop up in search results. This is good because users won't be getting obsolete documentation by accident.,THUMBS_UP,2020-03-15T20:49:41Z,mati865,NA https://github.com/rust-lang/rust/pull/69992,MERGED,2020-03-14T02:36:31Z,2020-03-16T06:22:35Z,Block version-specific docs from search engines,kornelski,d34ec3309fbda36e776977fed7da695a775c6195,1,Rollup merge of #69992 - kornelski:robots r=steveklabnik Block version-specific docs from search engines Latest stable beta and nightly URLs remain accessible because their URLs don't start with a version number. Robots.txt uses simple path prefixes so it's OK that the disallow rules aren't full directory paths. Direct links to old docs remain accessible to users because robots.txt only affects crawlers. With this change old docs for specific old versions of Rust won't pop up in search results. This is good because users won't be getting obsolete documentation by accident.,THUMBS_UP,2020-03-15T21:54:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",HEART,2020-03-14T09:48:33Z,cristaloleg,oleg@hey.com https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",THUMBS_UP,2020-03-14T09:58:57Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",THUMBS_UP,2020-03-14T11:05:45Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",HEART,2020-03-14T11:05:53Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",THUMBS_UP,2020-03-14T11:55:24Z,prostomarkeloff,NA https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",HEART,2020-03-14T11:55:25Z,prostomarkeloff,NA https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",THUMBS_UP,2020-03-19T01:25:14Z,viriuwu,hi@viri.moe https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",HEART,2020-03-19T01:25:15Z,viriuwu,hi@viri.moe https://github.com/rust-lang/rust/pull/69997,MERGED,2020-03-14T09:13:43Z,2020-03-21T07:47:19Z,"add `Option::{zip zip_with}` methods under ""option_zip"" gate",WaffleLapkin,801a25abc1899df538939a8c2a3907bbea62cf1c,2,"Rollup merge of #69997 - WaffleLapkin:option_zip r=LukasKalbertodt add `Option::{zip zip_with}` methods under ""option_zip"" gate This PR introduces 2 methods - `Option::zip` and `Option::zip_with` with respective signatures: - zip: `(Option Option) -> Option<(T U)>` - zip_with: `(Option Option (T U) -> R) -> Option` Both are under the feature gate ""option_zip"". I'm not sure about the name ""zip"" maybe we can find a better name for this. (I would prefer `union` for example but this is a keyword :( ) -------------------------------------------------------------------------------- Recently in a russian rust begginers telegram chat a newbie asked (translated): > Are there any methods for these conversions: > > 1. `(Option Option) -> Option<(A B)>` > 2. `Vec> -> Option>` > > ? While second (2.) is clearly `vec.into_iter().collect::>()` the first one isn't that clear. I couldn't find anything similar in the `core` and I've come to this solution: ```rust let tuple: (Option Option) = ...; let res: Option<(A B)> = tuple.0.and_then(|a| tuple.1.map(|b| (a b))); ``` However this solution isn't ""nice"" (same for just `match`/`if let`) so I thought that this functionality should be in `core`.",THUMBS_UP,2020-06-19T09:42:51Z,CGMossa,NA https://github.com/rust-lang/rust/pull/70000,MERGED,2020-03-14T12:58:45Z,2020-03-17T05:24:11Z,resolve: Fix regression in resolution of raw keywords in paths,petrochenkov,3d25622537a6c79303fb86d76ad7cbca2702fc1f,7,Rollup merge of #70000 - petrochenkov:rawkeypars r=davidtwco resolve: Fix regression in resolution of raw keywords in paths Fixes https://github.com/rust-lang/rust/issues/63882.,HOORAY,2020-03-18T12:17:19Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70000,MERGED,2020-03-14T12:58:45Z,2020-03-17T05:24:11Z,resolve: Fix regression in resolution of raw keywords in paths,petrochenkov,3d25622537a6c79303fb86d76ad7cbca2702fc1f,7,Rollup merge of #70000 - petrochenkov:rawkeypars r=davidtwco resolve: Fix regression in resolution of raw keywords in paths Fixes https://github.com/rust-lang/rust/issues/63882.,HOORAY,2020-06-11T03:54:32Z,kennytm,NA https://github.com/rust-lang/rust/pull/70003,MERGED,2020-03-14T16:50:15Z,2020-03-22T00:58:24Z,symbol_names: treat ReifyShim like VtableShim.,eddyb,834ed36a532381aac4cb23d607e6522dff0ca244,3,Rollup merge of #70003 - eddyb:symbol-mangling-reify-shims r=nikomatsakis symbol_names: treat ReifyShim like VtableShim. Without this the `#[track_caller]` tests don't pass with `-Zsymbol-mangling-version=v0` because there is a symbol name collision between the `ReifyShim` and the original definition. cc @anp,THUMBS_UP,2020-03-14T17:40:22Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/70011,MERGED,2020-03-14T21:32:56Z,2020-03-15T20:40:18Z,def_collector: Fully visit async functions,petrochenkov,d74c5cd07cc5626d52d3364084e9f92d2b4f70ae,2,Rollup merge of #70011 - petrochenkov:asyncice r=Centril def_collector: Fully visit async functions We forgot to visit attributes previously it caused ICEs. Special treatment of async functions is also moved from `visit_item` to `visit_fn` to reuse more of the default visitor. Fixes https://github.com/rust-lang/rust/issues/67778.,HEART,2020-03-19T16:15:30Z,estebank,NA https://github.com/rust-lang/rust/pull/70012,CLOSED,2020-03-14T22:35:25Z,2020-04-17T14:27:23Z,Handle out of memory error in Vec::write,LenaWil2,NA,NA,NA,HOORAY,2020-04-01T20:03:45Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/70018,MERGED,2020-03-15T09:23:21Z,2020-03-15T20:40:15Z,"Fix ""since"" field for `Once::is_complete`'s `#[stable]` attribute",LukasKalbertodt,bde77af0944e7b6f666b64f92bc30f8fd55296d2,1,"Rollup merge of #70018 - LukasKalbertodt:fix-once-is-complete-since r=Centril Fix ""since"" field for `Once::is_complete`'s `#[stable]` attribute It was accidentally merged with the wrong version in #68945. Thanks @jplatte for noticing. This also needs to be beta backported.",THUMBS_UP,2020-03-15T10:17:23Z,jplatte,NA https://github.com/rust-lang/rust/pull/70039,CLOSED,2020-03-16T11:27:07Z,2020-04-10T18:12:43Z,Add queries for LocalDefId <-> HirId conversion,Zoxc,NA,NA,NA,HEART,2020-03-16T12:03:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70039,CLOSED,2020-03-16T11:27:07Z,2020-04-10T18:12:43Z,Add queries for LocalDefId <-> HirId conversion,Zoxc,NA,NA,NA,HEART,2020-03-17T02:37:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70042,CLOSED,2020-03-16T13:57:26Z,2020-04-16T11:24:13Z,Use explicit promotion for constants in repeat expressions,oli-obk,NA,NA,NA,HEART,2020-03-16T23:44:05Z,estebank,NA https://github.com/rust-lang/rust/pull/70042,CLOSED,2020-03-16T13:57:26Z,2020-04-16T11:24:13Z,Use explicit promotion for constants in repeat expressions,oli-obk,NA,NA,NA,HEART,2020-04-06T17:26:18Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70051,MERGED,2020-03-16T18:25:05Z,2020-03-22T00:58:20Z,Allow `hir().find` to return `None`,Zoxc,ce0af8a5bd90de722d5653965f7edcf2c302cf59,5,Rollup merge of #70051 - Zoxc:opt-find r=eddyb Allow `hir().find` to return `None` Fixes https://github.com/rust-lang/rust/issues/70041 r? @eddyb,THUMBS_UP,2020-03-18T11:09:06Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/70051,MERGED,2020-03-16T18:25:05Z,2020-03-22T00:58:20Z,Allow `hir().find` to return `None`,Zoxc,ce0af8a5bd90de722d5653965f7edcf2c302cf59,5,Rollup merge of #70051 - Zoxc:opt-find r=eddyb Allow `hir().find` to return `None` Fixes https://github.com/rust-lang/rust/issues/70041 r? @eddyb,THUMBS_UP,2020-03-18T19:12:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70066,CLOSED,2020-03-17T05:35:29Z,2020-03-17T05:48:27Z,Rollup of 8 pull requests,Centril,NA,NA,NA,EYES,2020-03-17T05:40:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70074,MERGED,2020-03-17T13:21:01Z,2020-03-24T09:38:08Z,Expand: nix all fatal errors,Centril,3d8b9614d3aae6ef8bd877e3f020f7ac8ad7f7e0,48,Rollup merge of #70074 - Centril:unpanictry r=petrochenkov Expand: nix all fatal errors Basically we go after all `.span_fatal` / `FatalError.raise()` and similar things and remove them one by one until there are no fatal errors left. r? @petrochenkov,THUMBS_UP,2020-03-17T13:40:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70080,MERGED,2020-03-17T16:57:47Z,2020-03-23T22:02:29Z,rustc_mir: remove extra space when pretty-printing MIR.,anyska,4d5eccae5034adfc4fb9a5ee103230fce2f8502d,2,Rollup merge of #70080 - anyska:mir-double-space r=oli-obk rustc_mir: remove extra space when pretty-printing MIR.,LAUGH,2020-03-18T15:51:32Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70081,MERGED,2020-03-17T18:04:26Z,2020-04-01T01:29:57Z,add `unused_braces` lint,lcnr,8993358e77b82a3c8745c1200c2ac5f3640a7053,44,Rollup merge of #70081 - lcnr:issue68387 r=varkor add `unused_braces` lint Add the lint `unused_braces` which is warn by default. `unused_parens` is also extended and now checks anon consts. closes #68387 r? @varkor,HEART,2020-03-17T18:52:32Z,varkor,NA https://github.com/rust-lang/rust/pull/70081,MERGED,2020-03-17T18:04:26Z,2020-04-01T01:29:57Z,add `unused_braces` lint,lcnr,8993358e77b82a3c8745c1200c2ac5f3640a7053,44,Rollup merge of #70081 - lcnr:issue68387 r=varkor add `unused_braces` lint Add the lint `unused_braces` which is warn by default. `unused_parens` is also extended and now checks anon consts. closes #68387 r? @varkor,HEART,2020-06-06T23:24:49Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/70081,MERGED,2020-03-17T18:04:26Z,2020-04-01T01:29:57Z,add `unused_braces` lint,lcnr,8993358e77b82a3c8745c1200c2ac5f3640a7053,44,Rollup merge of #70081 - lcnr:issue68387 r=varkor add `unused_braces` lint Add the lint `unused_braces` which is warn by default. `unused_parens` is also extended and now checks anon consts. closes #68387 r? @varkor,HOORAY,2020-06-06T23:24:52Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/70087,MERGED,2020-03-17T23:18:54Z,2020-03-24T04:08:06Z,Remove const eval loop detector,ecstatic-morse,72c99f2cf0021fe119dd3de8272349f679188150,12,"Rollup merge of #70087 - ecstatic-morse:remove-const-eval-loop-detector r=RalfJung Remove const eval loop detector Now that there is a configurable instruction limit for CTFE (see #67260) we can replace the loop detector with something much simpler. See #66946 for more discussion about this. Although the instruction limit is nightly-only the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable). This will at the very least require a crater run since it will result in an error wherever the ""long running const eval"" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this. Resolves #54384 cc #49980 r? @oli-obk cc @RalfJung",HEART,2020-03-21T16:26:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70087,MERGED,2020-03-17T23:18:54Z,2020-03-24T04:08:06Z,Remove const eval loop detector,ecstatic-morse,72c99f2cf0021fe119dd3de8272349f679188150,12,"Rollup merge of #70087 - ecstatic-morse:remove-const-eval-loop-detector r=RalfJung Remove const eval loop detector Now that there is a configurable instruction limit for CTFE (see #67260) we can replace the loop detector with something much simpler. See #66946 for more discussion about this. Although the instruction limit is nightly-only the only practical way to reach the default limit uses nightly-only features as well (although CTFE will still execute code using such features inside an array initializer on stable). This will at the very least require a crater run since it will result in an error wherever the ""long running const eval"" warning appeared before. We may need to increase the default for `const_eval_limit` to work around this. Resolves #54384 cc #49980 r? @oli-obk cc @RalfJung",HEART,2020-04-02T16:58:17Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/70091,CLOSED,2020-03-18T01:52:52Z,2020-05-14T07:43:11Z,Store tokens alongside more AST expressions,Aaron1011,NA,NA,NA,HEART,2020-03-18T01:56:13Z,estebank,NA https://github.com/rust-lang/rust/pull/70092,MERGED,2020-03-18T01:56:00Z,2020-03-21T11:11:44Z,"hir: replace ""items"" terminology with ""nodes"" where appropriate.",eddyb,569272ac05c6cae7fd64c31396bbdcb7aacd6aab,40,"Rollup merge of #70092 - eddyb:hir-items-are-just-nodes r=Zoxc hir: replace ""items"" terminology with ""nodes"" where appropriate. The newly added `HirOwnerItems` confused me before I realized that ""items"" there actually referred to HIR nodes not `hir:Item` or ""item-like"" (which we should IMO replace with ""owner""). I suspect the naming had something to do with `ItemLocalId`'s use of ""item"". That is `ItemLocalId` could be interpreted to mean one of two things: * `IntraItemNodeId` i.e. `IntraOwnerNodeId` * this is IMO correct and I'd even like to rename it but I didn't want to throw that into this PR * `IntraOwnerItemId` * this is what `HirOwnerItems` would seem to imply r? @Zoxc cc @michaelwoerister @nikomatsakis",THUMBS_UP,2020-03-18T10:56:58Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70095,MERGED,2020-03-18T04:16:40Z,2020-03-28T11:13:24Z,Implement -Zlink-native-libraries,jsgf,b76238a3ee5ebffbad8a3aefd36012f3bceb7069,3,Auto merge of #70095 - jsgf:link-native r=nagisa Implement -Zlink-native-libraries This implements a flag `-Zlink-native-libraries=yes/no`. If set to true/yes or unspecified then native libraries referenced via `#[link]` attributes will be put on the linker line (ie unchanged behaviour). If `-Zlink-native-libraries=no` is specified then rustc will not add the native libraries to the link line. The assumption is that the outer build system driving the build already knows about the native libraries and will specify them to the linker directly (for example via `-Clink-arg=`). Addresses issue #70093,HEART,2020-03-19T00:50:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/70095,MERGED,2020-03-18T04:16:40Z,2020-03-28T11:13:24Z,Implement -Zlink-native-libraries,jsgf,b76238a3ee5ebffbad8a3aefd36012f3bceb7069,3,Auto merge of #70095 - jsgf:link-native r=nagisa Implement -Zlink-native-libraries This implements a flag `-Zlink-native-libraries=yes/no`. If set to true/yes or unspecified then native libraries referenced via `#[link]` attributes will be put on the linker line (ie unchanged behaviour). If `-Zlink-native-libraries=no` is specified then rustc will not add the native libraries to the link line. The assumption is that the outer build system driving the build already knows about the native libraries and will specify them to the linker directly (for example via `-Clink-arg=`). Addresses issue #70093,HEART,2020-03-19T18:51:42Z,tmandry,NA https://github.com/rust-lang/rust/pull/70105,CLOSED,2020-03-18T15:09:14Z,2020-03-21T22:44:56Z,Beta: Update cargo clippy,ehuss,NA,NA,NA,THUMBS_UP,2020-03-18T15:16:17Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/70106,MERGED,2020-03-18T15:16:33Z,2020-03-19T03:33:59Z,Tidy: fix running rustfmt twice,ehuss,b6f61a1f51bd87dce41cf9523a24312f66d06b79,1,Rollup merge of #70106 - ehuss:fix-tidy-fmt-twice r=Mark-Simulacrum Tidy: fix running rustfmt twice `./x.py test tidy` runs rustfmt twice. This is because `Build::build` runs `execute_cli` twice (once dry once not). This can be quite slow (and prints a bunch of things twice). I'm not sure if this is really the best place to check the dry_run status.,HEART,2020-03-18T18:22:40Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,HEART,2020-03-18T15:29:43Z,varkor,NA https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,HEART,2020-04-30T02:26:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,ROCKET,2020-04-30T02:26:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,HEART,2020-05-18T19:29:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,ROCKET,2020-06-03T13:34:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/70107,MERGED,2020-03-18T15:19:59Z,2020-06-03T12:22:00Z,WF-check all ty::Const's not just array lengths.,lcnr,ff4aff6ce0f216c8cb8d40f432efaacdaca8095b,33,Auto merge of #70107 - lcnr:issue68977 r=eddyb WF-check all ty::Const's not just array lengths. fixes #68977 This PR removes the special case for array length in `wf::compute` and checks the well formedness of all consts. Changes `PredicateKind::WellFormed` to take a `GenericArg` and updates `wf::obligations`.,HEART,2020-06-03T13:34:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/70140,MERGED,2020-03-19T09:10:24Z,2020-03-29T17:57:42Z,Add Result E>::flatten -> Result,Nemo157,8212a1c7dcd4172c0cb8345f40191566abc0afb3,1,Rollup merge of #70140 - Nemo157:result-flatten r=Amanieu Add Result E>::flatten -> Result This PR makes this possible (modulo type inference): ```rust assert_eq!(Ok(6) Ok(Ok(6)).flatten()); ``` Tracking issue: #70142 largely cribbed directly from ,THUMBS_UP,2020-03-19T09:18:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70140,MERGED,2020-03-19T09:10:24Z,2020-03-29T17:57:42Z,Add Result E>::flatten -> Result,Nemo157,8212a1c7dcd4172c0cb8345f40191566abc0afb3,1,Rollup merge of #70140 - Nemo157:result-flatten r=Amanieu Add Result E>::flatten -> Result This PR makes this possible (modulo type inference): ```rust assert_eq!(Ok(6) Ok(Ok(6)).flatten()); ``` Tracking issue: #70142 largely cribbed directly from ,HEART,2021-03-02T21:46:50Z,eopb,NA https://github.com/rust-lang/rust/pull/70151,MERGED,2020-03-19T14:40:39Z,2020-03-21T11:11:39Z,Update stdarch submodule,Amanieu,744bcc630ef27857ae5b20620b98d2bdef62cf3b,1,Rollup merge of #70151 - Amanieu:stdarch r=sfackler Update stdarch submodule This only includes one commit: - https://github.com/rust-lang/stdarch/commit/abe96ca3b87fcca6aa1dfcefd40d8c8d92d2e673 (https://github.com/rust-lang/stdarch/pull/842) Fixes #68905,THUMBS_UP,2020-03-19T15:03:09Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/70162,MERGED,2020-03-19T18:23:08Z,2020-03-28T00:37:05Z,Move the query system to a dedicated crate,cjgillot,0bf7c2ad77fdcb18a65ae05996dc8e226fbaeab4,28,Auto merge of #70162 - cjgillot:split_query r=Zoxc Move the query system to a dedicated crate The query system `rustc::ty::query` is split out into the `rustc_query_system` crate. Some commits are unformatted to ease rebasing. Based on #67761 and #69910. r? @Zoxc,ROCKET,2020-03-19T23:36:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70162,MERGED,2020-03-19T18:23:08Z,2020-03-28T00:37:05Z,Move the query system to a dedicated crate,cjgillot,0bf7c2ad77fdcb18a65ae05996dc8e226fbaeab4,28,Auto merge of #70162 - cjgillot:split_query r=Zoxc Move the query system to a dedicated crate The query system `rustc::ty::query` is split out into the `rustc_query_system` crate. Some commits are unformatted to ease rebasing. Based on #67761 and #69910. r? @Zoxc,ROCKET,2020-03-24T21:28:52Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70163,MERGED,2020-03-19T19:12:03Z,2020-03-24T15:49:38Z,Prepare for LLVM 10 upgrade,nikic,374ab25585f0a817fe7bd6986737f12347b12d0b,7,Auto merge of #70163 - nikic:llvm-10-preparation r=cuviper Prepare for LLVM 10 upgrade This is #67759 minus the submodule update. * Fix two compatibility issues in the rustllvm wrapper. * Update data layout strings in tests. * Fix LLVM version comparison (this become a problem because the major version has two digits now). r? @cuviper,HEART,2020-03-20T08:16:47Z,mati865,NA https://github.com/rust-lang/rust/pull/70163,MERGED,2020-03-19T19:12:03Z,2020-03-24T15:49:38Z,Prepare for LLVM 10 upgrade,nikic,374ab25585f0a817fe7bd6986737f12347b12d0b,7,Auto merge of #70163 - nikic:llvm-10-preparation r=cuviper Prepare for LLVM 10 upgrade This is #67759 minus the submodule update. * Fix two compatibility issues in the rustllvm wrapper. * Update data layout strings in tests. * Fix LLVM version comparison (this become a problem because the major version has two digits now). r? @cuviper,HEART,2020-03-20T23:22:15Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/70163,MERGED,2020-03-19T19:12:03Z,2020-03-24T15:49:38Z,Prepare for LLVM 10 upgrade,nikic,374ab25585f0a817fe7bd6986737f12347b12d0b,7,Auto merge of #70163 - nikic:llvm-10-preparation r=cuviper Prepare for LLVM 10 upgrade This is #67759 minus the submodule update. * Fix two compatibility issues in the rustllvm wrapper. * Update data layout strings in tests. * Fix LLVM version comparison (this become a problem because the major version has two digits now). r? @cuviper,HEART,2020-03-26T00:01:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/70172,MERGED,2020-03-20T06:03:15Z,2020-03-22T18:37:39Z,parse/lexer: support `StringReader::retokenize` called on external files.,eddyb,9890d9a9d0e76cecbb6cfad41c0901f248430877,2,Rollup merge of #70172 - eddyb:retokenize-external-src r=petrochenkov parse/lexer: support `StringReader::retokenize` called on external files. This ~~should theoretically~~ fixes #69933 ~~but I'm not sure what the best way to test it is~~. **EDIT**: see https://github.com/rust-lang/rust/issues/69933#issuecomment-602019598. r? @petrochenkov cc @Xanewok @staktrace,THUMBS_UP,2020-03-21T10:06:29Z,meteficha,NA https://github.com/rust-lang/rust/pull/70172,MERGED,2020-03-20T06:03:15Z,2020-03-22T18:37:39Z,parse/lexer: support `StringReader::retokenize` called on external files.,eddyb,9890d9a9d0e76cecbb6cfad41c0901f248430877,2,Rollup merge of #70172 - eddyb:retokenize-external-src r=petrochenkov parse/lexer: support `StringReader::retokenize` called on external files. This ~~should theoretically~~ fixes #69933 ~~but I'm not sure what the best way to test it is~~. **EDIT**: see https://github.com/rust-lang/rust/issues/69933#issuecomment-602019598. r? @petrochenkov cc @Xanewok @staktrace,HEART,2020-03-21T10:06:31Z,meteficha,NA https://github.com/rust-lang/rust/pull/70172,MERGED,2020-03-20T06:03:15Z,2020-03-22T18:37:39Z,parse/lexer: support `StringReader::retokenize` called on external files.,eddyb,9890d9a9d0e76cecbb6cfad41c0901f248430877,2,Rollup merge of #70172 - eddyb:retokenize-external-src r=petrochenkov parse/lexer: support `StringReader::retokenize` called on external files. This ~~should theoretically~~ fixes #69933 ~~but I'm not sure what the best way to test it is~~. **EDIT**: see https://github.com/rust-lang/rust/issues/69933#issuecomment-602019598. r? @petrochenkov cc @Xanewok @staktrace,THUMBS_UP,2020-03-21T19:09:54Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/70175,MERGED,2020-03-20T12:24:12Z,2020-04-30T10:28:03Z,Remove -Z no-landing-pads flag,Amanieu,bf459752d41a93eb6df0e9513de4ef807883a80c,14,Auto merge of #70175 - Amanieu:remove_nlp r=pnkfelix Remove -Z no-landing-pads flag Since #67502 `-Z no-landing-pads` will cause all attempted unwinds to abort since we don't generate a `try` / `catch`. This previously worked because `__rust_try` was located in libpanic_unwind which is always compiled with `-C panic=unwind` but `__rust_try` is now directly inline into the crate that uses `catch_unwind`. As such `-Z no-landing-pads` is now mostly useless and people should use `-C panic=abort` instead.,HEART,2020-04-22T04:26:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T16:25:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T16:57:25Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T17:28:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T17:52:24Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T19:22:58Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-20T20:51:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-22T19:39:24Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-03-23T14:11:10Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/70190,MERGED,2020-03-20T16:18:59Z,2020-03-24T18:53:03Z,Add GitHub Actions configuration,pietroalbini,2dcf54f564c6d8bbf48960fb9aaec88a0e2e062a,25,Auto merge of #70190 - pietroalbini:gha r=Mark-Simulacrum Add GitHub Actions configuration This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch. Since GitHub Actions doesn't currently have any way to include pieces of configuration this also adds the `src/tools/expand-yaml-anchors` tool which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past). There are still a few small things I need to fix before we can land this but it's mostly complete and ready for an initial review. r? @Mark-Simulacrum,ROCKET,2020-04-07T17:47:14Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/70193,CLOSED,2020-03-20T16:47:14Z,2020-08-15T16:23:24Z,Limit maximum alignment in #[repr(align)] to 4K,Amanieu,NA,NA,NA,HEART,2020-04-22T13:04:00Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70199,MERGED,2020-03-20T20:26:06Z,2020-03-23T22:02:21Z,Revised span-to-lines conversion to produce an empty vec on DUMMY_SP.,pnkfelix,560eae31c549238b0a501c9800ffefebaf5e0b5a,3,Rollup merge of #70199 - pnkfelix:issue-68808-dont-turn-dummy-spans-into-invalid-lines r=estebank Revised span-to-lines conversion to produce an empty vec on DUMMY_SP. This required revising some of the client code to stop relying on the returned set of lines being non-empty. Fix #68808,HEART,2020-03-20T20:35:23Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70203,CLOSED,2020-03-21T02:25:45Z,2020-03-21T04:31:10Z,Rollup of 17 pull requests,Centril,NA,NA,NA,EYES,2020-03-21T03:23:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70204,MERGED,2020-03-21T04:03:51Z,2020-03-23T06:02:44Z,Liberate `rustc_ast_lowering` from `rustc`,Centril,37c945dd6178cb520eb1e450a795f8c3b3cc5a3b,27,Auto merge of #70204 - Centril:unshackled-lowering r=Zoxc Liberate `rustc_ast_lowering` from `rustc` The whole point of this PR is the very last commit in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031. Noteworthy: - From `rustc::arena` we move logic into `arena` in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena. - Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering` and this is their common dependency. - `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir` so that `rustc_ast_lowering` can stop referring to `rustc::hir`. r? @Zoxc,THUMBS_UP,2020-03-21T04:39:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70204,MERGED,2020-03-21T04:03:51Z,2020-03-23T06:02:44Z,Liberate `rustc_ast_lowering` from `rustc`,Centril,37c945dd6178cb520eb1e450a795f8c3b3cc5a3b,27,Auto merge of #70204 - Centril:unshackled-lowering r=Zoxc Liberate `rustc_ast_lowering` from `rustc` The whole point of this PR is the very last commit in which we remove `rustc` as one of `rustc_ast_lowering`'s dependencies thereby improving `./x.py` parallelism and working towards https://github.com/rust-lang/rust/issues/65031. Noteworthy: - From `rustc::arena` we move logic into `arena` in particular `declare_arena!`. This is then used in `rustc_ast_lowering` so that lowering has its own separate arena. - Some linting code is unfortunately moved to `rustc_session::lint` cause its used both in `rustc_lint` and `rustc_ast_lowering` and this is their common dependency. - `rustc_session::CrateDisambiguator` is moved into `rustc_ast` so that `rustc::hir::map::definitions` can be moved into `rustc_hir` so that `rustc_ast_lowering` can stop referring to `rustc::hir`. r? @Zoxc,HEART,2020-03-21T10:13:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70209,MERGED,2020-03-21T07:36:32Z,2020-03-22T18:37:35Z,parser: recover on `for<'a> |...| body` closures,Centril,ea44d71f9bc76d2136e20553259d43f55f282db1,5,Rollup merge of #70209 - Centril:recover-quant-closure r=petrochenkov parser: recover on `for<'a> |...| body` closures When encountering `for` and `<` is 1 token ahead interpret this as an explicitly quantified generic closure and recover rather than attempting to parse a `for` loop. This provides both improved diagnostics as well as an insurance policy for the ability to use this as the syntax for generic closures in the future. As requested by r? @eddyb,CONFUSED,2020-03-29T13:49:01Z,kennytm,NA https://github.com/rust-lang/rust/pull/70209,MERGED,2020-03-21T07:36:32Z,2020-03-22T18:37:35Z,parser: recover on `for<'a> |...| body` closures,Centril,ea44d71f9bc76d2136e20553259d43f55f282db1,5,Rollup merge of #70209 - Centril:recover-quant-closure r=petrochenkov parser: recover on `for<'a> |...| body` closures When encountering `for` and `<` is 1 token ahead interpret this as an explicitly quantified generic closure and recover rather than attempting to parse a `for` loop. This provides both improved diagnostics as well as an insurance policy for the ability to use this as the syntax for generic closures in the future. As requested by r? @eddyb,HEART,2022-01-14T15:56:15Z,fmease,NA https://github.com/rust-lang/rust/pull/70212,MERGED,2020-03-21T07:57:36Z,2020-08-28T03:19:24Z,Abort when foreign exceptions are caught by catch_unwind,Amanieu,41aaa90c67cdb04cac7427756891ad04c3e0bebf,26,Auto merge of #70212 - Amanieu:catch_foreign r=Mark-Simulacrum Abort when foreign exceptions are caught by catch_unwind Prior to this PR foreign exceptions were not caught by catch_unwind and instead passed through invisibly. This represented a painful soundness hole in some libraries ([take_mut](https://github.com/Sgeo/take_mut/blob/master/src/lib.rs#L37)) which relied on `catch_unwind` to handle all possible exit paths from a closure. With this PR foreign exceptions are now caught by `catch_unwind` and will trigger an abort since catching foreign exceptions is currently UB according to the latest proposals by the FFI unwind project group. cc @rust-lang/wg-ffi-unwind,HEART,2020-09-05T08:48:14Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70212,MERGED,2020-03-21T07:57:36Z,2020-08-28T03:19:24Z,Abort when foreign exceptions are caught by catch_unwind,Amanieu,41aaa90c67cdb04cac7427756891ad04c3e0bebf,26,Auto merge of #70212 - Amanieu:catch_foreign r=Mark-Simulacrum Abort when foreign exceptions are caught by catch_unwind Prior to this PR foreign exceptions were not caught by catch_unwind and instead passed through invisibly. This represented a painful soundness hole in some libraries ([take_mut](https://github.com/Sgeo/take_mut/blob/master/src/lib.rs#L37)) which relied on `catch_unwind` to handle all possible exit paths from a closure. With this PR foreign exceptions are now caught by `catch_unwind` and will trigger an abort since catching foreign exceptions is currently UB according to the latest proposals by the FFI unwind project group. cc @rust-lang/wg-ffi-unwind,HEART,2020-11-19T15:16:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70214,CLOSED,2020-03-21T08:38:25Z,2020-03-21T09:10:22Z,Update LICENSE-APACHE,NA,NA,NA,NA,EYES,2020-03-21T08:50:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/70223,MERGED,2020-03-21T12:23:54Z,2020-03-22T18:37:34Z,fix type of const params in associated types.,lcnr,3c8f8b6304e6d8ec735f32a8286a1461f36feeb0,5,Rollup merge of #70223 - lcnr:issue70167 r=eddyb fix type of const params in associated types. fixes #66906 fixes #70167 r? @eddyb,THUMBS_UP,2020-03-21T13:00:22Z,lqd,NA https://github.com/rust-lang/rust/pull/70223,MERGED,2020-03-21T12:23:54Z,2020-03-22T18:37:34Z,fix type of const params in associated types.,lcnr,3c8f8b6304e6d8ec735f32a8286a1461f36feeb0,5,Rollup merge of #70223 - lcnr:issue70167 r=eddyb fix type of const params in associated types. fixes #66906 fixes #70167 r? @eddyb,HEART,2020-03-21T14:21:56Z,varkor,NA https://github.com/rust-lang/rust/pull/70223,MERGED,2020-03-21T12:23:54Z,2020-03-22T18:37:34Z,fix type of const params in associated types.,lcnr,3c8f8b6304e6d8ec735f32a8286a1461f36feeb0,5,Rollup merge of #70223 - lcnr:issue70167 r=eddyb fix type of const params in associated types. fixes #66906 fixes #70167 r? @eddyb,HEART,2020-03-22T17:33:39Z,estebank,NA https://github.com/rust-lang/rust/pull/70224,MERGED,2020-03-21T12:55:17Z,2020-04-03T07:26:30Z,Clean up rustdoc js testers,GuillaumeGomez,a80b491ef27c1ccb30d0c603e80c74ddce127c66,3,Rollup merge of #70224 - GuillaumeGomez:clean-up-rustdoc-js-testers r=Dylan-DPC Clean up rustdoc js testers I realized after the improvement made by @ollie27 on the rustdoc-js-tester that a lot of code was actually duplicated. This PR intends to remove this duplication making it simpler to update in case of future main.js updates. r? @ollie27 cc @kinnison,HEART,2020-03-21T19:34:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/70229,MERGED,2020-03-21T15:00:01Z,2020-03-22T18:37:32Z,more clippy fixes,matthiaskrgr,e58fec0c1cfa6f306940edb20d8d5f7a3a468d6e,22,Rollup merge of #70229 - matthiaskrgr:cl3ppy r=Mark-Simulacrum more clippy fixes * remove unused unit values (clippy::unused_unit) * make some let-if-bindings more idiomatic (clippy::useless_let_if_seq) * clarify when we pass () to functions (clippy::unit_arg) * don't redundantly repeat field names (clippy::redundant_field_names) * remove redundant returns (clippy::needless_return) * use let instead of match for matches with single bindings (clippy::match_single_binding) * don't convert results to options just for matching (clippy::if_let_some_result),HEART,2020-03-21T19:31:17Z,panaman67,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-23T15:19:18Z,est31,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-23T15:35:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-23T16:15:50Z,harrysarson,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",HOORAY,2020-03-24T15:17:38Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-24T16:42:04Z,Lokathor,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-24T16:45:59Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",HOORAY,2020-03-24T18:34:51Z,akhilles,4@4khil.com https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-03-24T22:35:34Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",HOORAY,2020-04-02T14:42:55Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",HOORAY,2020-04-02T18:14:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",HOORAY,2020-04-15T03:09:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/70234,MERGED,2020-03-21T17:09:09Z,2020-03-24T23:47:14Z,#[track_caller] on core::ops::{Index IndexMut}.,anp,50d2f302cbf512271eac3e6242f08e7d77e1a2f3,4,"Rollup merge of #70234 - anp:tracked-std-traits r=Amanieu #[track_caller] on core::ops::{Index IndexMut}. Applies the attribute to `core::ops::Index(Mut)` and enough std internals to cover the [functions listed in ""tier 1"" in the original RFC](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#survey-of-panicking-standard-functions). Split out from #69251 to allow separate assessment of perf impact. To my knowledge this is the last piece of implementing RFC 2091. Tracking issue: https://github.com/rust-lang/rust/issues/47809",THUMBS_UP,2020-04-15T03:09:05Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/70236,MERGED,2020-03-21T18:00:20Z,2020-03-23T09:07:56Z,"resolve: Avoid ""self-confirming"" import resolutions in one more case",petrochenkov,08dfd1344c47c5a7e3abbee10db6d0bcfde6d107,2,"Rollup merge of #70236 - petrochenkov:globimpice r=ecstatic-morse resolve: Avoid ""self-confirming"" import resolutions in one more case So the idea behind ""blacklisted bindings"" is that we must ignore some name definitions during resolution because otherwise they cause infinite cycles. E.g. import ```rust use my_crate; ``` would refer to itself (on 2018 edition) without this blacklisting because `use my_crate;` is the first name in scope when we are resolving `my_crate` here. In this PR we are doing this blacklisting for the case ```rust use same::same; ``` namely blacklisting the second `same` when resolving the first `same`. This was previously forgotten. Fixes https://github.com/rust-lang/rust/issues/62767",HOORAY,2020-03-21T19:32:48Z,oberien,NA https://github.com/rust-lang/rust/pull/70248,MERGED,2020-03-21T22:17:36Z,2020-03-23T09:07:54Z,parser: simplify & remove unused field,Centril,8dda61792bc662073bee1cea6002705b1b5e0bc5,6,Rollup merge of #70248 - Centril:unroot r=petrochenkov parser: simplify & remove unused field r? @petrochenkov,HEART,2020-03-21T22:34:50Z,panaman67,NA https://github.com/rust-lang/rust/pull/70261,MERGED,2020-03-22T05:19:15Z,2020-03-28T14:15:39Z,Move arg/constraint partition check to validation & improve recovery,Centril,b9d5ee567652cd342d9348c215009049551747b0,23,Auto merge of #70261 - Centril:angle-args-partition r=varkor Move arg/constraint partition check to validation & improve recovery - In the first commit we move the check rejecting e.g. `<'a Item = u8 String>` from the parser into AST validation. - We then use this to improve the code for parsing generic arguments. - And we add recovery for e.g. `` (missing) `` (constant) and `` (lifetime). This is also preparatory work for supporting https://github.com/rust-lang/rust/issues/70256. r? @varkor,THUMBS_UP,2020-03-28T01:55:06Z,estebank,NA https://github.com/rust-lang/rust/pull/70266,MERGED,2020-03-22T10:00:31Z,2020-03-22T18:37:23Z,proc_macro_harness: Use item header spans for errors,petrochenkov,69c0bcd3d5d65e508751af5e7cb1c35b7e9ec4c9,5,Rollup merge of #70266 - petrochenkov:prochead r=varkor proc_macro_harness: Use item header spans for errors Addresses https://github.com/rust-lang/rust/pull/70233#discussion_r396043004.,THUMBS_UP,2020-03-22T10:02:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/70266,MERGED,2020-03-22T10:00:31Z,2020-03-22T18:37:23Z,proc_macro_harness: Use item header spans for errors,petrochenkov,69c0bcd3d5d65e508751af5e7cb1c35b7e9ec4c9,5,Rollup merge of #70266 - petrochenkov:prochead r=varkor proc_macro_harness: Use item header spans for errors Addresses https://github.com/rust-lang/rust/pull/70233#discussion_r396043004.,THUMBS_UP,2020-03-27T06:30:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70276,CLOSED,2020-03-22T15:31:45Z,2020-03-22T20:06:05Z,fix type of const params in assoc fns.,lcnr,NA,NA,NA,HEART,2020-03-22T17:34:12Z,estebank,NA https://github.com/rust-lang/rust/pull/70276,CLOSED,2020-03-22T15:31:45Z,2020-03-22T20:06:05Z,fix type of const params in assoc fns.,lcnr,NA,NA,NA,HEART,2020-03-22T18:23:36Z,varkor,NA https://github.com/rust-lang/rust/pull/70277,MERGED,2020-03-22T16:30:03Z,2020-03-24T04:07:53Z,Remove `ReClosureBound`,matthewjasper,6c58e0194e0aaf51c524f70f530f9f3648fc37fc,20,Rollup merge of #70277 - matthewjasper:remove-closurebound r=nikomatsakis Remove `ReClosureBound` We now substitute external names for regions in the query response. r? @nikomatsakis,HEART,2020-03-22T19:39:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/70281,MERGED,2020-03-22T19:06:49Z,2020-04-02T18:53:15Z,Implement Hash for Infallible,xfix,cb81b41c9a474d403bd35fd2898ad226bc02657c,1,Rollup merge of #70281 - xfix:infallible-hash r=dtolnay Implement Hash for Infallible https://www.reddit.com/r/rust/comments/fmllgx/never_crate_stable_alternative_to/ lists not implementing `Hash` as a reason for the `never` crate. I see no reason not to implement `Hash` for `Infallible` so might as well do it. No changes necessary for `!` because `!` already implements `Hash` (see https://github.com/rust-lang/rust/pull/51404).,THUMBS_UP,2020-03-27T02:06:42Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/70284,MERGED,2020-03-22T21:30:37Z,2020-03-24T09:37:53Z,correctly handle const params in type_of,lcnr,d30905810139c59459449cc95c7e49660bca5257,7,Rollup merge of #70284 - lcnr:issue70273-what-the-heck-git r=eddyb correctly handle const params in type_of extends #70223 retry of #70276 fixes #70273 r? @eddyb cc @varkor,ROCKET,2020-03-22T23:02:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70284,MERGED,2020-03-22T21:30:37Z,2020-03-24T09:37:53Z,correctly handle const params in type_of,lcnr,d30905810139c59459449cc95c7e49660bca5257,7,Rollup merge of #70284 - lcnr:issue70273-what-the-heck-git r=eddyb correctly handle const params in type_of extends #70223 retry of #70276 fixes #70273 r? @eddyb cc @varkor,HEART,2020-03-23T01:10:45Z,varkor,NA https://github.com/rust-lang/rust/pull/70284,MERGED,2020-03-22T21:30:37Z,2020-03-24T09:37:53Z,correctly handle const params in type_of,lcnr,d30905810139c59459449cc95c7e49660bca5257,7,Rollup merge of #70284 - lcnr:issue70273-what-the-heck-git r=eddyb correctly handle const params in type_of extends #70223 retry of #70276 fixes #70273 r? @eddyb cc @varkor,HEART,2020-03-25T01:46:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/70318,MERGED,2020-03-23T14:49:46Z,2020-03-23T22:02:09Z,Split long derive lists into two derive attributes.,anyska,5b29348cfe67f5ec7b81dbf9cde03eb7a9c8ff01,16,Rollup merge of #70318 - anyska:multiple-derives r=Dylan-DPC Split long derive lists into two derive attributes.,HEART,2020-03-23T17:07:35Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70319,MERGED,2020-03-23T14:51:43Z,2020-03-25T22:51:09Z,correctly normalize constants,lcnr,1154023118c81237fad4498d9ddbaf277fe41ab5,16,Rollup merge of #70319 - lcnr:issue63695 r=eddyb correctly normalize constants closes #70317 implements https://github.com/rust-lang/rust/issues/70125#issuecomment-602133708 r? eddyb cc @varkor,HEART,2020-03-23T19:31:04Z,varkor,NA https://github.com/rust-lang/rust/pull/70326,MERGED,2020-03-23T17:22:44Z,2020-03-30T12:35:52Z,Use if let instead of match when only matching a single variant (clippy::single_match),matthiaskrgr,a80ec3b3b1d11ed83754885efdd07037d256dbf2,48,Auto merge of #70326 - matthiaskrgr:cl1ppy_single_match r=Centril Use if let instead of match when only matching a single variant (clippy::single_match) Makes code more compact and reduces nesting.,HEART,2020-03-24T00:42:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/70345,MERGED,2020-03-24T04:03:42Z,2020-03-28T03:43:51Z,Remove `no_integrated_as` mode.,nnethercote,08e867cc3a30f8fb3339cfcc3dbb4daff6da3dcc,8,Rollup merge of #70345 - nnethercote:rm-no_integrated_as r=alexcrichton Remove `no_integrated_as` mode. Specifically remove both `-Z no_integrated_as` and `TargetOptions::no_integrated_as`. The latter was only used for the `msp430_none_elf` platform for which it's no longer required. r? @alexcrichton,HEART,2020-03-24T21:50:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/70350,MERGED,2020-03-24T05:57:09Z,2020-03-24T23:47:07Z,"Request ""-Z unstable-options"" for unstable options",workingjubilee,f8ec23f2c09b67dc2236973d068955a3557366c7,1,"Rollup merge of #70350 - workingjubilee:patch-1 r=Dylan-DPC Request ""-Z unstable-options"" for unstable options Explicitly requests the ""-Z unstable-options"" flag if someone attempts to use a cargo option gated by it. This enhances discoverability particularly in the instance where the user is on the nightly compiler but isn't using the flag. This relates to but does not end with or resolve issue #65770.",THUMBS_UP,2020-03-24T17:42:27Z,aleksator,NA https://github.com/rust-lang/rust/pull/70354,MERGED,2020-03-24T12:37:01Z,2020-04-16T02:11:05Z,Update RELEASES.md for 1.43.0,XAMPPRocky,3c6e1936bc410e69f8e5a4a3a40ae83330a381bc,1,Rollup merge of #70354 - XAMPPRocky:master r=Mark-Simulacrum Update RELEASES.md for 1.43.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/master/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-03-25T02:40:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70366,MERGED,2020-03-24T19:21:28Z,2020-03-25T22:51:06Z,Implement Fuse with Option,cuviper,530c320e7534aa3ae1afbd6dbf423d5578c391f6,2,Rollup merge of #70366 - cuviper:option-fuse r=dtolnay Implement Fuse with Option The former `done` flag was roughly similar to an `Option` tag but left the possibity of misuse. By using a real `Option` we can set `None` when the iterator is exhausted removing any way to call it again. We also allow niche layout this way so the `Fuse` may be smaller. The `FusedIterator` specialization does want to ignore the possibility of exhaustion though so it uses `unsafe { intrinsics::unreachable() }` to optimize that branch away. The entire `Fuse` implementation is now isolated in its own module to contain that unsafety. r? @scottmcm,HEART,2020-03-24T19:38:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/70366,MERGED,2020-03-24T19:21:28Z,2020-03-25T22:51:06Z,Implement Fuse with Option,cuviper,530c320e7534aa3ae1afbd6dbf423d5578c391f6,2,Rollup merge of #70366 - cuviper:option-fuse r=dtolnay Implement Fuse with Option The former `done` flag was roughly similar to an `Option` tag but left the possibity of misuse. By using a real `Option` we can set `None` when the iterator is exhausted removing any way to call it again. We also allow niche layout this way so the `Fuse` may be smaller. The `FusedIterator` specialization does want to ignore the possibility of exhaustion though so it uses `unsafe { intrinsics::unreachable() }` to optimize that branch away. The entire `Fuse` implementation is now isolated in its own module to contain that unsafety. r? @scottmcm,HEART,2020-03-24T21:45:24Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70367,MERGED,2020-03-24T19:22:04Z,2020-04-09T13:21:07Z,save/restore `pessimistic_yield` when entering bodies,nikomatsakis,ba50bc588e36a06a7b42970366534946beea5ce9,3,Rollup merge of #70367 - nikomatsakis:issue-69307 r=Aaron1011 save/restore `pessimistic_yield` when entering bodies This flag is used to make the execution order around `+=` operators pessimistic. Failure to save/restore the flag was causing independent async blocks to effect one another leading to strange ICEs and failed assumptions. Fixes #69307 r? @Zoxc,THUMBS_UP,2020-03-25T03:30:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,HEART,2020-03-25T09:41:37Z,folex,NA https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,THUMBS_UP,2020-03-25T09:41:39Z,folex,NA https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,ROCKET,2020-03-25T09:41:40Z,folex,NA https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,HOORAY,2020-03-25T09:41:41Z,folex,NA https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,THUMBS_UP,2020-03-25T09:48:36Z,repushko,repushko.a@gmail.com https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,HOORAY,2020-03-25T09:48:37Z,repushko,repushko.a@gmail.com https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,HEART,2020-03-25T09:48:37Z,repushko,repushko.a@gmail.com https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,ROCKET,2020-03-25T09:48:38Z,repushko,repushko.a@gmail.com https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,THUMBS_UP,2020-03-25T09:48:49Z,gus3inov,gus3inov@yandex.ru https://github.com/rust-lang/rust/pull/70374,CLOSED,2020-03-24T23:16:48Z,2020-03-28T15:50:45Z,Make `iter::Fuse` truly zero cost,AnthonyMikh,NA,NA,NA,HOORAY,2020-03-28T05:17:10Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/70379,MERGED,2020-03-25T01:36:04Z,2020-03-25T22:51:04Z,fix incorrect type name in doc comments,JOE1994,9a9cb2d372b4e41248bf20765da306cb0c92f74a,1,Rollup merge of #70379 - JOE1994:patch-2 r=petrochenkov fix incorrect type name in doc comments Change : `InterpCtx` => `InterpCx` (`rustc_mir::interpret::InterpCx`),HEART,2020-03-25T11:56:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70384,MERGED,2020-03-25T06:17:35Z,2020-03-27T00:01:52Z,Refactor object file handling,nnethercote,b15423e72e48125a40a3192c2d49a48e54b5c314,3,Rollup merge of #70384 - nnethercote:refactor-object-file-handling r=alexcrichton Refactor object file handling Some preliminary clean-ups that grease the path to #66961. r? @alexcrichton,HEART,2020-03-25T13:19:04Z,mati865,NA https://github.com/rust-lang/rust/pull/70384,MERGED,2020-03-25T06:17:35Z,2020-03-27T00:01:52Z,Refactor object file handling,nnethercote,b15423e72e48125a40a3192c2d49a48e54b5c314,3,Rollup merge of #70384 - nnethercote:refactor-object-file-handling r=alexcrichton Refactor object file handling Some preliminary clean-ups that grease the path to #66961. r? @alexcrichton,HEART,2020-04-24T11:57:33Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70389,MERGED,2020-03-25T10:45:11Z,2020-03-26T05:37:05Z,"borrowck: prefer ""value"" over ""`_`"" in diagnostics",Centril,7db48250cd688889870fa999ba13739efb9c5d24,13,"Rollup merge of #70389 - Centril:borrowck-no-underscores r=mark-i-m borrowck: prefer ""value"" over ""`_`"" in diagnostics Fixes https://github.com/rust-lang/rust/issues/67565. r? @pnkfelix @matthewjasper cc @mark-i-m",HEART,2020-03-25T19:45:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70414,MERGED,2020-03-26T00:50:22Z,2020-04-01T07:52:58Z,Upgrade GCC to 8.3.0 glibc to 2.17.0 and crosstool-ng to 1.24.0 for dist-arm-linux and dist-armhf-linux,lopsided98,1a87c49e33d87955e28fa92a8d59a17264ac6044,9,Auto merge of #70414 - lopsided98:armv6-gcc-8 r=pietroalbini Upgrade GCC to 8.3.0 glibc to 2.17.0 and crosstool-ng to 1.24.0 for dist-arm-linux and dist-armhf-linux Attempt to fix #69420 in the same manner as #65302 did for armv7l. I have tested that this eliminates the segfault while building a `hello_world` package on `arm-unknown-linux-gnueabihf`. I have not been able to test whether the bug exists for `arm-unknown-linux-gnueabi` as well but I suspect it does so I upgraded the toolchain for that platform as well.,LAUGH,2021-08-31T22:38:54Z,sigaloid,NA https://github.com/rust-lang/rust/pull/70417,MERGED,2020-03-26T05:13:37Z,2020-03-26T15:39:05Z,parser: recover on `...` as a pattern suggesting `..`,rakshith-ravi,37e186087c28891d04dd67c8657c9affc8cdc59a,3,Rollup merge of #70417 - rakshith-ravi:master r=Centril parser: recover on `...` as a pattern suggesting `..` Fixes #70388 My first PR to rust. So please let me know if I'm doing something wrong.,HEART,2020-03-30T08:25:19Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/70417,MERGED,2020-03-26T05:13:37Z,2020-03-26T15:39:05Z,parser: recover on `...` as a pattern suggesting `..`,rakshith-ravi,37e186087c28891d04dd67c8657c9affc8cdc59a,3,Rollup merge of #70417 - rakshith-ravi:master r=Centril parser: recover on `...` as a pattern suggesting `..` Fixes #70388 My first PR to rust. So please let me know if I'm doing something wrong.,HEART,2020-04-05T19:45:01Z,elichai,NA https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-26T10:11:09Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-26T12:46:50Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-26T15:42:49Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-29T17:38:59Z,imtsuki,me@qjx.app https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-30T07:59:16Z,dwijnand,dale.wijnand@gmail.com https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-03-31T22:58:10Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-04-01T14:36:41Z,banool,danielporteous1@gmail.com https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,ROCKET,2020-04-10T02:26:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,THUMBS_UP,2020-04-14T17:41:12Z,iago-lito,NA https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,ROCKET,2020-04-14T17:41:16Z,iago-lito,NA https://github.com/rust-lang/rust/pull/70420,CLOSED,2020-03-26T08:03:27Z,2020-04-30T22:57:50Z,Accept tuple.0.0 as tuple indexing,dtolnay,NA,NA,NA,HEART,2020-04-19T12:52:55Z,varkor,NA https://github.com/rust-lang/rust/pull/70421,MERGED,2020-03-26T08:35:13Z,2020-04-02T18:53:12Z,parse: recover on `const fn()` / `async fn()`,Centril,03591e8a7842896975985614221a152b28238bb8,7,Rollup merge of #70421 - Centril:recover-const-async-fn-ptr r=estebank parse: recover on `const fn()` / `async fn()` Recover on `const fn()` and `async fn()` function pointers suggesting to remove the qualifier. For example: ``` error: an `fn` pointer type cannot be `async` --> $DIR/recover-const-async-fn-ptr.rs:6:11 | LL | type T3 = async fn(); | -----^^^^^ | | | `async` because of this | help: remove the `async` qualifier ``` r? @estebank,THUMBS_UP,2020-03-26T09:07:31Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/70428,MERGED,2020-03-26T13:15:21Z,2020-03-27T00:01:48Z,`error_bad_item_kind`: add help text,Centril,ef43cdee2867a8a50ef9b421e82ae31afd28fe7f,5,Rollup merge of #70428 - Centril:move-to-mod r=petrochenkov `error_bad_item_kind`: add help text For example this adds: ``` = help: consider moving the `use` import out to a nearby module scope ``` r? @petrochenkov @estebank Fixes https://github.com/rust-lang/rust/issues/37205.,HEART,2020-03-26T17:47:21Z,estebank,NA https://github.com/rust-lang/rust/pull/70434,MERGED,2020-03-26T15:00:10Z,2020-03-28T03:43:47Z,suggest `;` on expr `mac!()` which is good as stmt `mac!()`,Centril,cfe1e330b5a5632f311bb4b45619b1a8d02878ec,4,Rollup merge of #70434 - Centril:fix-34421 r=estebank suggest `;` on expr `mac!()` which is good as stmt `mac!()` Fixes https://github.com/rust-lang/rust/issues/34421 by implementing @jseyfried's suggestion in https://github.com/rust-lang/rust/issues/34421#issuecomment-301578683. r? @petrochenkov,HEART,2020-03-26T16:24:32Z,estebank,NA https://github.com/rust-lang/rust/pull/70452,MERGED,2020-03-27T00:54:02Z,2020-04-15T00:39:56Z,typeck: always expose repeat count `AnonConst`s' parent in `generics_of`.,eddyb,d12f0304839e599d498b3faaa652336b273bdcc8,30,"Auto merge of #70452 - eddyb:repeat-expr-correct-generics-parent r=nikomatsakis typeck: always expose repeat count `AnonConst`s' parent in `generics_of`. This should reduce some of the confusion around #43408 although if you look at the changed test outputs (for the last commit) they all hit #68436 so nothing new will start compiling. We can let counts of ""repeat expressions"" (`N` in `[x; N]`) always have the correct generics parenting because they're always in a body so nothing in the `where` clauses or `impl` trait/type of the parent can use it and therefore no query cycles can occur.
Other potential candidates we might want to apply the same approach to are: * ~~(easy) `enum` discriminants (see also #70453)~~ opened #70825 * (trickier) array *type* (not *expression*) lengths nested in: * bodies * types of (associated or not) `const`/`static` * RHS of `type` aliases and associated `type`s * `fn` signatures We should've done so from the start the only reason we haven't is because I was squeamish about blacklisting some of the cases but if we whitelist instead we should be fine. Also lazy normalization is taking forever :disappointed:.
There's also 5 other commits here: * ""typeck: track any errors injected during writeback and taint tables appropriately."" - fixes #66706 as the next commit would otherwise trigger an ICE again * ""typeck: workaround WF hole in `to_const`."" - its purpose is to emulate most of #70107's direct effect at least in the case of repeat expressions where the count always goes through `to_const` * this is the reason no new code can really compile as the WF checks require #68436 to bypass * however this has more test changes than I hoped so it should be reviewed separately and maybe even landed separately (as #70107 might take a while as it's blocked on a few of my PRs) * ""ty: erase lifetimes early in `ty::Const::eval`."" - first attempt at fixing #70773 * still useful I believe the new approach is less likely to cause issues long-term * I could take this out or move it into another PR if desired or someone else could take over (cc @skinny121) * ""traits/query/normalize: add some `debug!` logging for the result."" - debugging aid for #70773 * ""borrow_check/type_check: normalize `Aggregate` and `Call` operands."" - actually fixes #70773 r? @nikomatsakis cc @pnkfelix @varkor @yodaldevoid @oli-obk @estebank",HEART,2020-03-27T16:39:20Z,estebank,NA https://github.com/rust-lang/rust/pull/70478,MERGED,2020-03-27T15:27:37Z,2020-03-28T03:43:41Z,Refactor type_of for constants,lcnr,5b68f9c46a550dec9f8ef8bafb9a815cf564af1d,1,Rollup merge of #70478 - lcnr:refactor-type_of r=varkor Refactor type_of for constants If I have to look at this function for a few hours I want it to at least look good. r? @varkor,LAUGH,2020-03-27T15:36:12Z,varkor,NA https://github.com/rust-lang/rust/pull/70478,MERGED,2020-03-27T15:27:37Z,2020-03-28T03:43:41Z,Refactor type_of for constants,lcnr,5b68f9c46a550dec9f8ef8bafb9a815cf564af1d,1,Rollup merge of #70478 - lcnr:refactor-type_of r=varkor Refactor type_of for constants If I have to look at this function for a few hours I want it to at least look good. r? @varkor,LAUGH,2020-03-28T02:32:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70479,MERGED,2020-03-27T15:36:37Z,2020-03-30T17:54:32Z,avoid creating unnecessary reference in Windows Env iterator,RalfJung,47ffca296a533ee389fcea91de3f09827a7c9c49,1,Rollup merge of #70479 - RalfJung:win-env r=Mark-Simulacrum avoid creating unnecessary reference in Windows Env iterator Discovered in https://github.com/rust-lang/miri/pull/1225: the Windows `Env` iterator violates Stacked Borrows by creating an `&u16` turning it into a raw pointer and then accessing memory outside the range of that type. There is no need to create a reference here in the first place so the fix is trivial. Cc @JOE1994 Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134,THUMBS_UP,2020-03-27T17:26:17Z,JOE1994,joseph942010@gmail.com https://github.com/rust-lang/rust/pull/70486,MERGED,2020-03-27T23:02:52Z,2020-03-28T20:11:04Z,Shrink Unicode tables (even more),Mark-Simulacrum,7f1e6261bfd05fb411ff361bf999e48ede6237b6,7,Rollup merge of #70486 - Mark-Simulacrum:unicode-shrink r=dtolnay Shrink Unicode tables (even more) This shrinks the Unicode tables further building upon the wins in #68232 (the previous counts differ due to an interim Unicode version update see #69929. The new data structure is slower by around 3x on the benchmark of looking up every Unicode scalar value in each data set sequentially in every data set included. Note that for ASCII the exposed functions on `char` optimize with direct branches so ASCII will retain the same performance regardless of internal optimizations (or the reverse). Also note that the size reduction due to the skip list (from where the performance losses come) is around 40% and as a result I believe the performance loss is acceptable as the routines are still quite fast. Anywhere where this is hot should probably be using a custom data structure anyway (e.g. a raw bitset) or something optimized for frequently seen values etc. This PR updates both the bitset data structure and introduces a new data structure similar to a skip list. For more details see the [main.rs] of the table generator which describes both. The commits mostly work individually and document size wins. As before this is tested on all valid chars to have the same results as nightly (and the canonical Unicode data sets) happily no bugs were found. [main.rs]: https://github.com/rust-lang/rust/blob/fb4a715e18b/src/tools/unicode-table-generator/src/main.rs Set | Previous | New | % of old | Codepoints | Ranges | ----------------|---------:|------:|-----------:|-----------:|-------:| Alphabetic | 3055 | 1599 | 52% | 132875 | 695 | Case Ignorable | 2136 | 949 | 44% | 2413 | 410 | Cased | 934 | 359 | 38% | 4286 | 141 | Cc | 43 | 9 | 20% | 65 | 2 | Grapheme Extend | 1774 | 813 | 46% | 1979 | 344 | Lowercase | 985 | 867 | 88% | 2344 | 652 | N | 1266 | 419 | 33% | 1781 | 133 | Uppercase | 934 | 777 | 83% | 1911 | 643 | White_Space | 140 | 37 | 26% | 25 | 10 | ----------------|----------|-------|------------|------------|--------| Total | 11267 | 5829 | 51% | - | - |,THUMBS_UP,2020-03-28T03:35:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70486,MERGED,2020-03-27T23:02:52Z,2020-03-28T20:11:04Z,Shrink Unicode tables (even more),Mark-Simulacrum,7f1e6261bfd05fb411ff361bf999e48ede6237b6,7,Rollup merge of #70486 - Mark-Simulacrum:unicode-shrink r=dtolnay Shrink Unicode tables (even more) This shrinks the Unicode tables further building upon the wins in #68232 (the previous counts differ due to an interim Unicode version update see #69929. The new data structure is slower by around 3x on the benchmark of looking up every Unicode scalar value in each data set sequentially in every data set included. Note that for ASCII the exposed functions on `char` optimize with direct branches so ASCII will retain the same performance regardless of internal optimizations (or the reverse). Also note that the size reduction due to the skip list (from where the performance losses come) is around 40% and as a result I believe the performance loss is acceptable as the routines are still quite fast. Anywhere where this is hot should probably be using a custom data structure anyway (e.g. a raw bitset) or something optimized for frequently seen values etc. This PR updates both the bitset data structure and introduces a new data structure similar to a skip list. For more details see the [main.rs] of the table generator which describes both. The commits mostly work individually and document size wins. As before this is tested on all valid chars to have the same results as nightly (and the canonical Unicode data sets) happily no bugs were found. [main.rs]: https://github.com/rust-lang/rust/blob/fb4a715e18b/src/tools/unicode-table-generator/src/main.rs Set | Previous | New | % of old | Codepoints | Ranges | ----------------|---------:|------:|-----------:|-----------:|-------:| Alphabetic | 3055 | 1599 | 52% | 132875 | 695 | Case Ignorable | 2136 | 949 | 44% | 2413 | 410 | Cased | 934 | 359 | 38% | 4286 | 141 | Cc | 43 | 9 | 20% | 65 | 2 | Grapheme Extend | 1774 | 813 | 46% | 1979 | 344 | Lowercase | 985 | 867 | 88% | 2344 | 652 | N | 1266 | 419 | 33% | 1781 | 133 | Uppercase | 934 | 777 | 83% | 1911 | 643 | White_Space | 140 | 37 | 26% | 25 | 10 | ----------------|----------|-------|------------|------------|--------| Total | 11267 | 5829 | 51% | - | - |,THUMBS_UP,2020-03-28T03:47:07Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/70487,MERGED,2020-03-27T23:23:49Z,2020-04-03T01:23:05Z,Stabilize float::to_int_unchecked,Mark-Simulacrum,1eabbd024c0e49d8ca66c804f502c65cbad90ced,6,Rollup merge of #70487 - Mark-Simulacrum:float-unchecked-casts r=SimonSapin Stabilize float::to_int_unchecked This renames and stabilizes unsafe floating point to integer casts which are intended to be the substitute for the currently unsound `as` behavior once that changes to safe-but-slower saturating casts. As such I believe this also likely unblocks #10184 (our oldest I-unsound issue!) as once this rolls out to stable it would be far easier IMO to change the behavior of `as` to be safe by default. This does not stabilize the trait or the associated method as they are deemed internal implementation details (and consumers should not generally want to expose them as in practice all callers likely know statically/without generics what the return type is). Closes #67058,HOORAY,2020-03-27T23:30:32Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70487,MERGED,2020-03-27T23:23:49Z,2020-04-03T01:23:05Z,Stabilize float::to_int_unchecked,Mark-Simulacrum,1eabbd024c0e49d8ca66c804f502c65cbad90ced,6,Rollup merge of #70487 - Mark-Simulacrum:float-unchecked-casts r=SimonSapin Stabilize float::to_int_unchecked This renames and stabilizes unsafe floating point to integer casts which are intended to be the substitute for the currently unsound `as` behavior once that changes to safe-but-slower saturating casts. As such I believe this also likely unblocks #10184 (our oldest I-unsound issue!) as once this rolls out to stable it would be far easier IMO to change the behavior of `as` to be safe by default. This does not stabilize the trait or the associated method as they are deemed internal implementation details (and consumers should not generally want to expose them as in practice all callers likely know statically/without generics what the return type is). Closes #67058,HOORAY,2020-03-30T15:54:35Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70487,MERGED,2020-03-27T23:23:49Z,2020-04-03T01:23:05Z,Stabilize float::to_int_unchecked,Mark-Simulacrum,1eabbd024c0e49d8ca66c804f502c65cbad90ced,6,Rollup merge of #70487 - Mark-Simulacrum:float-unchecked-casts r=SimonSapin Stabilize float::to_int_unchecked This renames and stabilizes unsafe floating point to integer casts which are intended to be the substitute for the currently unsound `as` behavior once that changes to safe-but-slower saturating casts. As such I believe this also likely unblocks #10184 (our oldest I-unsound issue!) as once this rolls out to stable it would be far easier IMO to change the behavior of `as` to be safe by default. This does not stabilize the trait or the associated method as they are deemed internal implementation details (and consumers should not generally want to expose them as in practice all callers likely know statically/without generics what the return type is). Closes #67058,HOORAY,2020-05-29T20:35:13Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/70487,MERGED,2020-03-27T23:23:49Z,2020-04-03T01:23:05Z,Stabilize float::to_int_unchecked,Mark-Simulacrum,1eabbd024c0e49d8ca66c804f502c65cbad90ced,6,Rollup merge of #70487 - Mark-Simulacrum:float-unchecked-casts r=SimonSapin Stabilize float::to_int_unchecked This renames and stabilizes unsafe floating point to integer casts which are intended to be the substitute for the currently unsound `as` behavior once that changes to safe-but-slower saturating casts. As such I believe this also likely unblocks #10184 (our oldest I-unsound issue!) as once this rolls out to stable it would be far easier IMO to change the behavior of `as` to be safe by default. This does not stabilize the trait or the associated method as they are deemed internal implementation details (and consumers should not generally want to expose them as in practice all callers likely know statically/without generics what the return type is). Closes #67058,HOORAY,2020-06-05T07:50:25Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/70502,CLOSED,2020-03-28T15:47:06Z,2020-05-14T16:58:25Z,Specialize internal state of Fuse depending on underlying iterator,AnthonyMikh,NA,NA,NA,THUMBS_UP,2020-04-09T02:48:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/70511,MERGED,2020-03-28T21:16:12Z,2020-04-01T17:09:53Z,Add `-Z dump-mir-dataflow` flag for dumping dataflow results visualization,ecstatic-morse,84a463388040a1bc86578c0e3df2bf65e91127d3,7,Rollup merge of #70511 - ecstatic-morse:mir-dataflow-graphviz r=davidtwco Add `-Z dump-mir-dataflow` flag for dumping dataflow results visualization Previously to visualize the results of a MIR dataflow pass one had to add a `#[rustc_mir(borrowck_graphviz_postflow)]` attribute to functions of interest. However there is no way to specify this attribute on closures and generators so it was impossible to view results for these MIR bodies. This PR adds a flag `-Z dump-mir-dataflow` which will output the dataflow results for any functions specified in `-Z dump-mir` to the output directory specified by `-Z dump-mir-dir`. This behavior is modeled on the `-Z dump-mir-graphviz` flag.,HEART,2020-03-28T21:38:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70522,MERGED,2020-03-29T04:13:09Z,2020-04-01T17:09:51Z,Improve error messages for raw strings (#60762),rcoh,c739465b1b760911d0e27df18a3b0460afbd4419,22,"Rollup merge of #70522 - rcoh:60762-raw-string-errors r=petrochenkov Improve error messages for raw strings (#60762) This diff improves error messages around raw strings in a few ways: - Catch extra trailing `#` in the parser. This can't be handled in the lexer because we could be in a macro that actually expects another # (see test) - Refactor & unify error handling in the lexer between ByteStrings and RawByteStrings - Detect potentially intended terminators (longest sequence of ""#*"" is suggested) Fixes #60762 cc @estebank who reviewed the original (abandoned) PR for the same ticket. r? @Centril",THUMBS_UP,2020-04-01T22:59:23Z,estebank,NA https://github.com/rust-lang/rust/pull/70522,MERGED,2020-03-29T04:13:09Z,2020-04-01T17:09:51Z,Improve error messages for raw strings (#60762),rcoh,c739465b1b760911d0e27df18a3b0460afbd4419,22,"Rollup merge of #70522 - rcoh:60762-raw-string-errors r=petrochenkov Improve error messages for raw strings (#60762) This diff improves error messages around raw strings in a few ways: - Catch extra trailing `#` in the parser. This can't be handled in the lexer because we could be in a macro that actually expects another # (see test) - Refactor & unify error handling in the lexer between ByteStrings and RawByteStrings - Detect potentially intended terminators (longest sequence of ""#*"" is suggested) Fixes #60762 cc @estebank who reviewed the original (abandoned) PR for the same ticket. r? @Centril",THUMBS_UP,2020-04-10T08:33:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70535,MERGED,2020-03-29T15:08:18Z,2020-04-01T23:32:28Z,Track the finalizing node in the specialization graph,jonas-schievink,0e0d84c13c55dad7ce0cc07b65366bc0e4198d15,9,Rollup merge of #70535 - jonas-schievink:graph-refactor r=nikomatsakis Track the finalizing node in the specialization graph Fixes https://github.com/rust-lang/rust/issues/70419 Fixes https://github.com/rust-lang/rust/issues/70442 r? @eddyb,HEART,2020-04-02T03:07:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70536,MERGED,2020-03-29T15:10:02Z,2020-03-30T08:18:25Z,Rename `librustc` to `librustc_middle`,Centril,8926bb497d9b127eb318aea5aed0e745d8381591,602,"Auto merge of #70536 - Centril:rustc-middle r=eddyb Rename `librustc` to `librustc_middle` Here we rename `librustc` to `librustc_middle`. This crate is not nearly as large or central as it was previously and so it doesn't make much sense to give it such a central name as `librustc` (""the entry point to the compiler""). Moreover there is already a `rustc` crate which is has the actual `fn main` of `rustc` so having `librustc` is confusing relative to that. r? @eddyb",EYES,2020-03-30T08:37:39Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70550,CLOSED,2020-03-30T02:19:17Z,2020-04-10T18:12:11Z,[WIP] Allow functions to be inlined across crates without an inline attribute,Zoxc,NA,NA,NA,HOORAY,2020-03-30T08:40:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70550,CLOSED,2020-03-30T02:19:17Z,2020-04-10T18:12:11Z,[WIP] Allow functions to be inlined across crates without an inline attribute,Zoxc,NA,NA,NA,HOORAY,2020-03-30T13:25:33Z,mati865,NA https://github.com/rust-lang/rust/pull/70550,CLOSED,2020-03-30T02:19:17Z,2020-04-10T18:12:11Z,[WIP] Allow functions to be inlined across crates without an inline attribute,Zoxc,NA,NA,NA,HOORAY,2020-04-05T15:17:53Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/70551,MERGED,2020-03-30T02:37:38Z,2020-06-19T05:04:46Z,Make all uses of ty::Error delay a span bug,mark-i-m,9d388d465d3ecab18843ae356256060a3612fce4,72,Rollup merge of #70551 - mark-i-m:ty-err-2 r=varkor Make all uses of ty::Error delay a span bug r? @eddyb A second attempt at https://github.com/rust-lang/rust/pull/70245 resolves https://github.com/rust-lang/rust/issues/70866,HOORAY,2020-05-26T02:36:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70551,MERGED,2020-03-30T02:37:38Z,2020-06-19T05:04:46Z,Make all uses of ty::Error delay a span bug,mark-i-m,9d388d465d3ecab18843ae356256060a3612fce4,72,Rollup merge of #70551 - mark-i-m:ty-err-2 r=varkor Make all uses of ty::Error delay a span bug r? @eddyb A second attempt at https://github.com/rust-lang/rust/pull/70245 resolves https://github.com/rust-lang/rust/issues/70866,HOORAY,2020-06-11T02:14:36Z,estebank,NA https://github.com/rust-lang/rust/pull/70551,MERGED,2020-03-30T02:37:38Z,2020-06-19T05:04:46Z,Make all uses of ty::Error delay a span bug,mark-i-m,9d388d465d3ecab18843ae356256060a3612fce4,72,Rollup merge of #70551 - mark-i-m:ty-err-2 r=varkor Make all uses of ty::Error delay a span bug r? @eddyb A second attempt at https://github.com/rust-lang/rust/pull/70245 resolves https://github.com/rust-lang/rust/issues/70866,HOORAY,2020-06-25T05:32:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70556,MERGED,2020-03-30T07:22:25Z,2020-04-01T01:29:38Z,parse_and_disallow_postfix_after_cast: account for `ExprKind::Err`.,Centril,81f19ec90925dd603ec17b9d79d2817f00fdbc7f,3,Rollup merge of #70556 - Centril:fix-70552 r=estebank parse_and_disallow_postfix_after_cast: account for `ExprKind::Err`. Fixes https://github.com/rust-lang/rust/issues/70552. r? @estebank cc @daboross,THUMBS_UP,2020-03-30T07:47:46Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/70562,MERGED,2020-03-30T12:10:42Z,2020-03-31T17:24:59Z,infer array len from pattern,lcnr,3ef70fe156be1f8236c23a49c0db841207895ef9,12,Rollup merge of #70562 - lcnr:const-arr_len r=Centril infer array len from pattern closes #70529 This still errors in the following case ```rust #![feature(const_generics)] fn arr() -> [u8; N] { todo!() } fn main() { match arr() { [5 ..] => () //~^ ERROR cannot pattern-match on an array without a fixed length [_ _] => () } } ``` Considering that this should be rare and is harder to implement I would merge this PR without *fixing* the above.,HEART,2020-03-30T14:15:03Z,varkor,NA https://github.com/rust-lang/rust/pull/70573,MERGED,2020-03-30T16:04:34Z,2020-04-06T21:30:11Z,Detailed panic messages for Vec functions,IgorPerikov,6dee5f1126dfd5c9314ee5ae9d9eb010e35ef257,1,Auto merge of #70573 - IgorPerikov:issue#70524_detailed_panic_messages r=LukasKalbertodt Detailed panic messages for Vec functions pass indexes to insert remove drain and split_off panic messages closes #70524,HEART,2020-04-15T02:22:52Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/70587,MERGED,2020-03-30T19:35:03Z,2020-03-31T17:24:54Z,Add `Rust` to the code snippet,DutchGhost,c55f5007b2dc089d5a4548dd4e04ea9343655e38,1,Rollup merge of #70587 - DutchGhost:patch-1 r=Dylan-DPC Add `Rust` to the code snippet Adds `Rust` to the snippet where the code causing the ICE should be placed so github can render it as Rust code rather than plain code.,HOORAY,2020-03-30T20:03:18Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/70595,MERGED,2020-03-31T01:45:43Z,2020-04-03T01:22:58Z,Remove unused discriminant reads from MIR bodies,wesleywiser,4cba69e5851d6b515afb970880f6fab0881b82f9,4,Rollup merge of #70595 - wesleywiser:remove_unused_discriminant_reads r=oli-obk Remove unused discriminant reads from MIR bodies Allow the `SimplifyLocals` pass to remove reads of discriminants if the read is never used. Fixes #70531 r? @oli-obk,HOORAY,2020-04-01T13:32:59Z,lqd,NA https://github.com/rust-lang/rust/pull/70595,MERGED,2020-03-31T01:45:43Z,2020-04-03T01:22:58Z,Remove unused discriminant reads from MIR bodies,wesleywiser,4cba69e5851d6b515afb970880f6fab0881b82f9,4,Rollup merge of #70595 - wesleywiser:remove_unused_discriminant_reads r=oli-obk Remove unused discriminant reads from MIR bodies Allow the `SimplifyLocals` pass to remove reads of discriminants if the read is never used. Fixes #70531 r? @oli-obk,HOORAY,2020-04-01T14:22:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/70595,MERGED,2020-03-31T01:45:43Z,2020-04-03T01:22:58Z,Remove unused discriminant reads from MIR bodies,wesleywiser,4cba69e5851d6b515afb970880f6fab0881b82f9,4,Rollup merge of #70595 - wesleywiser:remove_unused_discriminant_reads r=oli-obk Remove unused discriminant reads from MIR bodies Allow the `SimplifyLocals` pass to remove reads of discriminants if the read is never used. Fixes #70531 r? @oli-obk,HOORAY,2020-04-01T16:01:24Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-03-31T11:55:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-04-04T00:19:38Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-04-14T03:59:20Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-04-16T16:18:16Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-04-20T14:06:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/70598,MERGED,2020-03-31T04:37:27Z,2020-04-20T02:18:34Z,Make the necessary changes to support concurrency in Miri.,vakaras,c6b55eed638db7db34e887ef255c765bc8910ec0,17,Auto merge of #70598 - vakaras:add-threads-cr3 r=oli-obk RalfJung Make the necessary changes to support concurrency in Miri. This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency: 1. Move stack from the interpretation context (`InterpCx`) to machine so that the machine can switch the stacks when it changes the thread being executed. 2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique which allows using a simpler representation of the memory. r? @oli-obk cc @RalfJung,HEART,2020-04-20T15:32:19Z,davidbarsky,me@davidbarsky.com https://github.com/rust-lang/rust/pull/70612,MERGED,2020-03-31T13:18:35Z,2020-04-07T04:01:45Z,Add io::Write::write_all_vectored,Thomasdezeeuw,5768385615c61f6c9d63dccfb3548812f1ba1320,1,Rollup merge of #70612 - Thomasdezeeuw:issue_70436 r=LukasKalbertodt Add io::Write::write_all_vectored Similar to io::Write::write_all but uses io::Write::write_vectored instead. Updates #70436 /cc @cramertj @sfackler,THUMBS_UP,2020-03-31T17:57:47Z,cramertj,NA https://github.com/rust-lang/rust/pull/70612,MERGED,2020-03-31T13:18:35Z,2020-04-07T04:01:45Z,Add io::Write::write_all_vectored,Thomasdezeeuw,5768385615c61f6c9d63dccfb3548812f1ba1320,1,Rollup merge of #70612 - Thomasdezeeuw:issue_70436 r=LukasKalbertodt Add io::Write::write_all_vectored Similar to io::Write::write_all but uses io::Write::write_vectored instead. Updates #70436 /cc @cramertj @sfackler,THUMBS_UP,2020-04-05T15:20:16Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/70612,MERGED,2020-03-31T13:18:35Z,2020-04-07T04:01:45Z,Add io::Write::write_all_vectored,Thomasdezeeuw,5768385615c61f6c9d63dccfb3548812f1ba1320,1,Rollup merge of #70612 - Thomasdezeeuw:issue_70436 r=LukasKalbertodt Add io::Write::write_all_vectored Similar to io::Write::write_all but uses io::Write::write_vectored instead. Updates #70436 /cc @cramertj @sfackler,THUMBS_UP,2020-04-14T23:46:37Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/70612,MERGED,2020-03-31T13:18:35Z,2020-04-07T04:01:45Z,Add io::Write::write_all_vectored,Thomasdezeeuw,5768385615c61f6c9d63dccfb3548812f1ba1320,1,Rollup merge of #70612 - Thomasdezeeuw:issue_70436 r=LukasKalbertodt Add io::Write::write_all_vectored Similar to io::Write::write_all but uses io::Write::write_vectored instead. Updates #70436 /cc @cramertj @sfackler,THUMBS_UP,2020-07-14T18:49:35Z,naftulikay,me@naftuli.wtf https://github.com/rust-lang/rust/pull/70612,MERGED,2020-03-31T13:18:35Z,2020-04-07T04:01:45Z,Add io::Write::write_all_vectored,Thomasdezeeuw,5768385615c61f6c9d63dccfb3548812f1ba1320,1,Rollup merge of #70612 - Thomasdezeeuw:issue_70436 r=LukasKalbertodt Add io::Write::write_all_vectored Similar to io::Write::write_all but uses io::Write::write_vectored instead. Updates #70436 /cc @cramertj @sfackler,THUMBS_UP,2022-06-29T10:13:12Z,RCasatta,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T12:34:55Z,smartkrio,smartkrio@yandex.ru https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T13:15:11Z,lnicola,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T15:21:51Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T16:13:35Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T19:34:48Z,clintfred,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-09T21:37:32Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-10T08:31:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-11T08:45:14Z,SimSmith,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-12T01:50:28Z,lightclient,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-22T00:33:02Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-04-22T22:37:09Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-05-06T13:22:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-05-06T17:56:32Z,bluss,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-05-22T05:08:46Z,95th,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-01T19:24:06Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-02T09:10:26Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-04T21:56:25Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-04T23:08:30Z,DianaNites,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-04T23:25:27Z,CGMossa,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-05T02:22:51Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-05T09:12:01Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-05T11:26:23Z,elichai,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-08T22:42:04Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-11T21:47:05Z,calebsander,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2020-06-18T17:59:18Z,Ry0kugin,NA https://github.com/rust-lang/rust/pull/70632,MERGED,2020-03-31T19:42:38Z,2020-04-01T01:29:26Z,expand vec![] to Vec::new(),tspiteri,8310320ebd68d5f23ad21bb5a15326abeaf91dff,1,Rollup merge of #70632 - tspiteri:vec-new r=sfackler expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice which results in longer IR and even after optimization some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.,THUMBS_UP,2021-04-27T14:36:05Z,JarvisCraft,me@progrm-jarvis.ru https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-01T02:24:10Z,estebank,NA https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-01T07:24:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-01T07:27:23Z,mati865,NA https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-01T09:19:17Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-01T11:37:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-02T14:31:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70642,MERGED,2020-04-01T01:19:01Z,2020-04-03T04:18:45Z,Translate the virtual `/rustc/$hash` prefix back to a real directory.,eddyb,c53e4b38779c3c074ae571b8520ab08e5bb0b904,170,Auto merge of #70642 - eddyb:remap-sysroot-src r=Mark-Simulacrum Translate the virtual `/rustc/$hash` prefix back to a real directory. Closes #53486 and fixes #53081 by undoing the remapping to `/rustc/$hash` on the fly when appropriate (e.g. our testsuites or user crates that depend on `libstd`) but not during the Rust build itself (as that could leak the absolute build directory into the artifacts breaking deterministic builds). Tested locally by setting `remap-debuginfo = true` in `config.toml` which without these changes was causing 56 tests to fail (see https://github.com/rust-lang/rust/issues/53081#issuecomment-606703215 for more details). cc @Mark-Simulacrum @alexcrichton @ehuss,HEART,2020-04-02T17:39:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70644,MERGED,2020-04-01T06:11:34Z,2020-04-12T00:31:29Z,Clean up `ModuleConfig` initialization,nnethercote,f9c0ea2862280102bf33e9df81f33b1b7b464e19,1,Rollup merge of #70644 - nnethercote:clean-up-ModuleConfig-init r=Mark-Simulacrum Clean up `ModuleConfig` initialization Because it's currently a mess. r? @Mark-Simulacrum,HEART,2020-04-02T00:09:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:20:22Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:21:45Z,alexbool,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:23:23Z,mati865,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T07:36:29Z,AlecsFerra,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:39:02Z,MarcoBuster,mail@marcoaceti.it https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:39:23Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T07:39:24Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:39:37Z,killercup,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T07:42:02Z,bnjjj,benjamin.coenen@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T07:42:58Z,SnowyCoder,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T08:03:56Z,Enet4,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T08:03:58Z,Enet4,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T08:03:59Z,Enet4,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T08:04:00Z,Enet4,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T08:04:03Z,Enet4,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T08:19:12Z,jrouaix,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T08:25:16Z,somniumism,lucas@rtzr.ai https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T08:25:17Z,somniumism,lucas@rtzr.ai https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T08:34:19Z,JoshuaBatty,joshpbatty@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T08:44:43Z,xurtis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T08:57:57Z,ollie27,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:03:11Z,as3ii,as3ii777@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:03:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:04:17Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:19:43Z,cr0sh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:20:37Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:28:58Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:36:10Z,muhammad-saleh,msaleh.eg87@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T09:42:03Z,skade,florian.gilcher@ferrous-systems.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:42:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T09:50:14Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T09:51:00Z,chqoot-vgxu,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T09:55:45Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T09:59:53Z,nightmared,git@nightmared.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T10:00:43Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T10:00:47Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T10:00:50Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T10:02:09Z,puzzlewolf,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T10:10:00Z,Mirabellensaft,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T10:27:18Z,Dexterp37,a.placitelli@a2p.it https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T10:37:38Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T11:24:55Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T12:23:51Z,bjorn3,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T12:42:08Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T12:44:11Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T12:47:28Z,lemonholic,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T12:47:29Z,lemonholic,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T12:56:47Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T12:56:49Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T13:59:47Z,Nerzal,theel.tobias@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T13:59:49Z,Nerzal,theel.tobias@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T13:59:49Z,Nerzal,theel.tobias@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T13:59:51Z,Nerzal,theel.tobias@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T14:03:07Z,terry90,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T14:03:09Z,terry90,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T14:32:07Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T14:32:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T14:37:23Z,huitseeker,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T14:38:12Z,Skelebot,antonisimka.8@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T14:38:14Z,Skelebot,antonisimka.8@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T14:39:08Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T14:41:28Z,JosephLing,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T14:41:30Z,JosephLing,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T14:43:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T14:48:37Z,Ixrec,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T14:48:38Z,Ixrec,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T14:59:45Z,DianaNites,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T14:59:46Z,DianaNites,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T14:59:47Z,DianaNites,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T15:29:22Z,Limeth,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T15:29:23Z,Limeth,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T15:40:19Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T15:40:20Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T15:40:20Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T15:40:21Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T15:40:22Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:05:31Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:10:53Z,95th,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:10:57Z,95th,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:16:35Z,wackbyte,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T16:20:05Z,lowercase1024,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:26:42Z,NULLx76,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:31:17Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:32:53Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T16:32:55Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:32:56Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:35:16Z,marcoburato,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T16:35:43Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:35:44Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:40:52Z,A6GibKm,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T16:40:56Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:47:57Z,bogeholm,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T16:51:31Z,tomhoule,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:51:34Z,tomhoule,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:51:38Z,jrop,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:54:34Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T16:54:35Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T16:54:36Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T16:54:37Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T16:54:38Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:56:02Z,amanjeev,github@amanjeev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T16:59:13Z,RustyYato,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:00:10Z,pauloxnet,paolo@melchiorre.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T17:03:26Z,matthunz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:04:45Z,nicklauri,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:06:52Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:08:19Z,liamsi,Ismail.Khoffi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:10:51Z,tux3,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:11:10Z,liamsi,Ismail.Khoffi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:15:03Z,AxlLind,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:20:55Z,arguablykomodo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:24:29Z,matthewmueller,mattmuelle@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:29:04Z,shestifled,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:29:58Z,etiennebatise,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:29:59Z,etiennebatise,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:30:01Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T17:30:02Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T17:30:03Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:38:08Z,JayceFayne,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T17:38:14Z,JayceFayne,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:44:31Z,pgsill,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:45:37Z,psidex,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T17:48:22Z,1b15,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:48:45Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:48:47Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T17:50:11Z,AxelMontini,axel.montini@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:53:32Z,swedneck,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:54:04Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:57:30Z,DrBluefall,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:57:33Z,eightballocto,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T17:58:18Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T17:58:22Z,lnicola,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:01:38Z,cramertj,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:01:45Z,cramertj,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:02:45Z,connorskees,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T18:03:17Z,hug-dev,hugues.de-valon@einride.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:04:15Z,mati865,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:05:57Z,lostick,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:07:45Z,bbil,me@brandonbil.xyz https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:09:48Z,ivancompanyavi,ivancompanyavi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:09:49Z,ivancompanyavi,ivancompanyavi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T18:10:00Z,skibz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:10:13Z,saintaardvark,aardvark@saintaardvarkthecarpeted.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:10:58Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:11:40Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:11:41Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T18:11:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T18:11:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T18:11:43Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:11:44Z,Virgiel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:12:21Z,ollipa,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:14:23Z,fluunke,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:15:04Z,kylepollina,kylepollina@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:16:16Z,werner,werner_a_e@yahoo.es https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:22:07Z,domisterwoozy,jacobschneiderjgs@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:23:04Z,frictionPG,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:23:19Z,jeandudey,me@jeandudey.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:24:17Z,amadeusine,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:24:22Z,amadeusine,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:24:25Z,amadeusine,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:25:59Z,hombit,hombit@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:26:04Z,hombit,hombit@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:26:06Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:27:05Z,AdminXVII,xavier.lheureux@icloud.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:27:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:27:39Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:27:40Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:27:40Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:28:25Z,mgw854,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:28:32Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T18:29:11Z,valters-tomsons,valters@tomsons.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:29:43Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:29:45Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:29:46Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:29:48Z,marcogroppo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:31:02Z,pio2398,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:31:52Z,William-Edward,will.ed.business@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T18:32:11Z,louy2,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:32:31Z,estebank,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T18:33:55Z,William-Edward,will.ed.business@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:34:23Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:37:47Z,ziegeer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:38:57Z,ajyoon,andrew@nothing-to-say.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:39:04Z,ajyoon,andrew@nothing-to-say.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:39:14Z,ogendogen,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:39:20Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:39:22Z,bdelmas,bdelmas.pro@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:41:11Z,mcronce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:41:12Z,mcronce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T18:41:13Z,mcronce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:42:01Z,gliderkite,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:42:04Z,gliderkite,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:42:28Z,bcongdon,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:42:49Z,rockneurotiko,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:43:33Z,Avarel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T18:43:35Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:45:10Z,ashleydavies,ashley@davies.me.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:45:14Z,ashleydavies,ashley@davies.me.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:45:43Z,WAFFO,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:46:20Z,KevinMGranger,kgranger@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:48:37Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:49:13Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:49:17Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:49:20Z,RomualdGeairon,geairon.romuald@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:49:21Z,RomualdGeairon,geairon.romuald@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:49:23Z,izik1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:50:02Z,idanarye,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:50:23Z,DavidHusicka,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T18:50:25Z,DavidHusicka,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:50:50Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T18:50:52Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:51:08Z,zoechi,guenter@gzoechbauer.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:51:10Z,zoechi,guenter@gzoechbauer.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T18:51:11Z,zoechi,guenter@gzoechbauer.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:51:12Z,zoechi,guenter@gzoechbauer.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:51:38Z,SugaR256,kuba.krapiec@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:51:59Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T18:52:00Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:52:03Z,hobofan,goisser94@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:52:55Z,ralfbiedert,rb@xr.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:52:59Z,sakex,alexandre@senges.ch https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:53:01Z,dgarciah98,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:53:30Z,dowlandaiello,dowlandaiello@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:53:32Z,dowlandaiello,dowlandaiello@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:54:02Z,sawitom,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:54:20Z,SergejKembel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:54:21Z,SergejKembel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:54:30Z,gregkatz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:55:37Z,rigma,rigbuntu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:55:40Z,rigma,rigbuntu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T18:55:42Z,rigma,rigbuntu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:57:03Z,Weyzu,w.zurawik@nullthepointer.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:57:30Z,rochacbruno,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:57:31Z,nrabulinski,nikodem@rabulinski.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T18:57:32Z,rochacbruno,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:57:34Z,nrabulinski,nikodem@rabulinski.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:57:38Z,nrabulinski,nikodem@rabulinski.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T18:58:30Z,ducaale,sharaf.13@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T18:58:57Z,pheki,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T18:59:03Z,bretzle,johnfish218@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:01:47Z,praveenperera,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:02:21Z,nmuldavin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:03:01Z,Fussmatte,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T19:03:03Z,Fussmatte,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:03:14Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:03:14Z,qthree,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:03:16Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:03:18Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T19:03:18Z,qthree,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:03:21Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:03:22Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T19:03:24Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:03:42Z,piotrmoszkowicz,piotr@moszkowicz.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:04:24Z,thomasaarholt,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:04:28Z,thomasaarholt,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:05:22Z,bchesney-speedline,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:05:36Z,Drowrin,drowrin@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T19:05:58Z,Aliath,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:05:59Z,Boiethios,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:07:13Z,CohenArthur,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:08:37Z,AndrewGaspar,andrew.gaspar@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T19:08:49Z,GreeFine,greefine@hotmail.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:08:51Z,GreeFine,greefine@hotmail.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:10:42Z,dlsf,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:10:45Z,dlsf,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:12:05Z,arnavb,arnavborborah11@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:12:35Z,vrama628,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T19:13:23Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:13:28Z,iredelmeier,iredelmeier@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:14:02Z,ellisonleao,ellisonleao@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:14:12Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:14:25Z,Pyrhos,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:14:37Z,arusahni,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:14:42Z,mfornet,mfornet94@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:15:42Z,betamos,didrik.nordstrom@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:16:08Z,bzawada,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:18:14Z,richli,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:18:22Z,zphixon,zphixon@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:20:14Z,Thor99,thor.fc21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:20:17Z,Thor99,thor.fc21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:20:19Z,Thor99,thor.fc21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:20:23Z,Thor99,thor.fc21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:20:51Z,yk-sgr,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:21:53Z,yishn,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:24:12Z,ppamorim,pepa.amorim@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:26:12Z,xn3cr0nx,patrick.jusic@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:26:35Z,Dowwie,dkcdkg@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:27:56Z,nphinity,joeybeukema@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:28:12Z,landreussi,lucasandreussi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:28:32Z,bensadiku,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:28:33Z,bensadiku,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:28:35Z,bensadiku,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:29:10Z,landreussi,lucasandreussi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:29:11Z,landreussi,lucasandreussi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:29:23Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:30:52Z,4dam7,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:30:55Z,4dam7,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:30:56Z,4dam7,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:30:57Z,4dam7,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T19:30:59Z,4dam7,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:31:04Z,mafrasi2,mafrasi2@googlemail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:31:05Z,g-s-k,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:32:10Z,KamilJanda,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T19:32:50Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:33:51Z,jszczepanik,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:33:56Z,ewilken,eliasw@me.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:35:05Z,hckr,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:35:24Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:35:26Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:35:32Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:35:33Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:35:34Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:35:35Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T19:35:36Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:37:19Z,naomijub,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:37:40Z,ThouCheese,luuk.wester@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:38:00Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:38:04Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:38:04Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:38:05Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T19:38:06Z,evaporei,eba.pachi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:40:18Z,grzegorz-bielski,pesiok@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:40:21Z,alexb910,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:40:27Z,grzegorz-bielski,pesiok@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:41:14Z,aheart,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:41:15Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:42:22Z,ZargorNET,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:44:08Z,Gnbrkm41,ganbarukamo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:44:25Z,Gnbrkm41,ganbarukamo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:44:26Z,Gnbrkm41,ganbarukamo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:46:34Z,SonicZentropy,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:46:35Z,SonicZentropy,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:46:47Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:47:51Z,mchlrhw,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:48:45Z,wildbook,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:48:49Z,wildbook,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:49:13Z,drewtato,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:49:15Z,cchudant,cchudant@student.42.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:49:17Z,cchudant,cchudant@student.42.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:49:35Z,adevore,aaron.devore@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:50:13Z,SirJosh3917,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:50:13Z,Acrobot,andrzej.pomirski@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:50:14Z,juliavdkris,julia@juuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuulia.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:50:23Z,Cackbone,contact@cackbone.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:50:27Z,DarthHater,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:50:29Z,pallotron,pallotron@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:50:39Z,frndmg,frndmartinezglez@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T19:51:09Z,mateuszbrdon,brdon.mateusz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:51:20Z,williewillus,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T19:52:43Z,lauromoura,lauromoura@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:53:33Z,paddyhoran,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:53:45Z,tjkirch,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:54:02Z,fishnal,vishalpatel3199@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:54:05Z,victorcaidatavant,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:54:06Z,fishnal,vishalpatel3199@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T19:54:10Z,fishnal,vishalpatel3199@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:54:27Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:54:45Z,EmilHernvall,emil@c0la.se https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:56:00Z,bowlofeggs,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:57:26Z,word,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T19:59:01Z,cowang4,cowang4@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T19:59:06Z,ZargorNET,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T19:59:15Z,AngelicosPhosphoros,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:01:45Z,vitali2y,vitaliyy@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:01:58Z,LXSMNSYC,alexis@lyon.com.ph https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:04:26Z,garrettmaring,garrett.maring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:04:27Z,garrettmaring,garrett.maring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:04:28Z,garrettmaring,garrett.maring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:04:28Z,garrettmaring,garrett.maring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:05:39Z,Tyler-Zhang,me@tylerzhang.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:05:40Z,Tyler-Zhang,me@tylerzhang.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:05:41Z,Tyler-Zhang,me@tylerzhang.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:06:13Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:06:15Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:06:17Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:06:20Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:06:22Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T20:06:24Z,sunjay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:07:42Z,vorner,vorner+github@vorner.cz https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:10:55Z,MindTooth,contact+github@mindtooth.no https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:11:38Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:13:25Z,dsluijk,me@dany.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:14:26Z,SimSmith,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:14:53Z,mamantoha,anton.maminov@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:14:56Z,mamantoha,anton.maminov@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:14:59Z,mamantoha,anton.maminov@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:15:23Z,bpartridge,bapartridge@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:17:43Z,charlespierce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:17:45Z,charlespierce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:19:22Z,NicholasSterling,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:20:30Z,emmiegit,ammon.i.smith@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:21:07Z,futile,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:21:11Z,myrrlyn,self@myrrlyn.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:22:20Z,mkhan45,mikail.khan45@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:22:25Z,mkhan45,mikail.khan45@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:22:27Z,mkhan45,mikail.khan45@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:23:44Z,carumusan,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:23:47Z,vallentin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:24:17Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:24:17Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:24:49Z,Hoffs,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:25:24Z,ClaudiuCeia,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:26:46Z,mooli,github@cabal.org.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:26:59Z,Bannerets,comonoid@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:29:07Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:29:09Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:29:10Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:29:12Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:29:14Z,ariesdevil,ariesdevil77@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:29:15Z,pwoolcoc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:30:13Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:30:14Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:30:21Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:30:22Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:30:24Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T20:30:27Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:30:42Z,LDSpits,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:30:48Z,hryniuk,code@hryniuk.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:30:50Z,hryniuk,code@hryniuk.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:33:54Z,JohnDoneth,doneth7@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:35:15Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:35:29Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:35:55Z,possiblynova,possiblynova@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:35:57Z,possiblynova,possiblynova@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:36:07Z,LeChatErrant,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:36:07Z,mateuszgiza,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:36:22Z,lediur,dliu@lediur.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:36:24Z,lediur,dliu@lediur.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:38:57Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:39:12Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:40:16Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:40:18Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:41:17Z,dev-bio,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:41:24Z,Henning-K,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:41:48Z,qezz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:41:53Z,qezz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:41:55Z,qezz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T20:41:55Z,qezz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:42:01Z,BigRedEye,mail@bigredeye.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:42:03Z,BigRedEye,mail@bigredeye.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:44:19Z,crides,zhuhaoqing@live.cn https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:44:48Z,bluss,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:45:16Z,whew-inc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:45:24Z,vcsjones,vcsjones@github.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:45:28Z,torch2424,aaron@aaronthedev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:45:29Z,torch2424,aaron@aaronthedev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:45:31Z,torch2424,aaron@aaronthedev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:45:31Z,torch2424,aaron@aaronthedev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T20:45:32Z,torch2424,aaron@aaronthedev.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:46:22Z,HurricanKai,contact@kaij.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:47:38Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:47:43Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:49:47Z,lpil,louis@lpil.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:52:17Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:52:19Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T20:52:23Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T20:52:27Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:52:40Z,cacampbell,chris@launchbadge.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:53:09Z,cacampbell,chris@launchbadge.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T20:53:12Z,cacampbell,chris@launchbadge.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T20:53:13Z,cacampbell,chris@launchbadge.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:53:19Z,Eraden,adrian.wozniak@ita-prog.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:53:33Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:53:43Z,jeanmanguy,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T20:55:29Z,jmariondev,john@jmarion.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:55:50Z,KubaWernerowski,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:55:57Z,Antti,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:55:59Z,Antti,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:56:21Z,wangrat,amvangradt@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T20:56:39Z,MarcelGarus,hello@marcelgarus.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T20:58:20Z,EduRenesto,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:02:53Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:03:53Z,martinrlilja,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:06:05Z,JakubKoralewski,contact@jcubed.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:06:23Z,Lum-m,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:06:58Z,Luke-Draper,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:09:09Z,jokeyrhyme,jokeyrhyme@jokeyrhy.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T21:09:14Z,jokeyrhyme,jokeyrhyme@jokeyrhy.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T21:09:19Z,jokeyrhyme,jokeyrhyme@jokeyrhy.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:10:43Z,eduhenke,henke.edu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:10:48Z,deb0ch,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:10:51Z,deb0ch,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:11:28Z,danielakhterov,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:11:49Z,AnderRasoVazquez,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T21:12:13Z,x0rz3q,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:12:15Z,sambeckingham,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:13:59Z,kleinph,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:14:47Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:16:25Z,corazza,corazzajan@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:17:38Z,Crauzer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:17:41Z,Crauzer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:18:45Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:19:07Z,shackra,jorge@esavara.cr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:20:07Z,dgsantana,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:21:23Z,rafaeldelboni,rafadelboni@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:22:54Z,DazKins,david.atkins1998@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:26:23Z,dmarcuse,dana@marcuse.us https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:26:49Z,octavonce,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:26:50Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:26:53Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:31:59Z,jendakol,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:33:03Z,ayyess,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:33:31Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:35:07Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:35:40Z,cory2067,cjl2625@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:35:50Z,Codex-,codex.nz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:39:23Z,webknjaz,webknjaz+github/profile@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:39:24Z,webknjaz,webknjaz+github/profile@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T21:39:26Z,webknjaz,webknjaz+github/profile@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T21:39:29Z,webknjaz,webknjaz+github/profile@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T21:39:33Z,webknjaz,webknjaz+github/profile@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:46:51Z,Kawa-oneechan,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T21:46:53Z,Kawa-oneechan,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:53:00Z,Alcaro,floating@muncher.se https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T21:54:33Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T21:57:28Z,Alcaro,floating@muncher.se https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T21:58:55Z,fpoli,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:01:34Z,livingsilver94,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:02:11Z,EbonJaeger,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:08:18Z,boyan-soubachov,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:08:29Z,ZebulanStanphill,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:09:31Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:10:06Z,hbjydev,hi@hbjy.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:10:18Z,SimonWoodburyForget,SimonWoodburyForget@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:11:55Z,mbuffa,mbuffa@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:14:34Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:15:42Z,zebp,zeb@zebulon.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:19:16Z,marcusnewton,marcus.newton@hey.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:23:45Z,Recursing,buonanno.lorenzo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:27:27Z,joseluisq,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:34:17Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:34:27Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:34:47Z,Angr1st,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:35:22Z,Axmouth,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T22:38:24Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:38:25Z,cstyles,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T22:38:38Z,thomasantony,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:38:52Z,cfpgomes,claudiogomes@cmu.edu https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:39:19Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:39:24Z,dywedir,dywedir@gra.red https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:42:58Z,divagant-martian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-01T22:43:01Z,divagant-martian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T22:43:04Z,divagant-martian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T22:43:06Z,divagant-martian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:43:08Z,divagant-martian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:45:53Z,neuromancer85,neuromancer85@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:45:54Z,peterdelevoryas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T22:46:04Z,peterdelevoryas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:46:17Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:47:19Z,ebuchman,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:48:09Z,carlosnufe,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:49:19Z,quat1024,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:50:17Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:50:27Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:50:51Z,johanneshardt,me@johanneshardt.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:52:40Z,maruthgoyal,maruthgoyal@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:52:42Z,maruthgoyal,maruthgoyal@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:57:57Z,alekratz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-01T22:59:05Z,mhseiden,140dbs+github@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T22:59:27Z,darakian,darakian@github.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T22:59:31Z,darakian,darakian@github.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T22:59:32Z,byronmejia,hello@byronis.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T22:59:35Z,byronmejia,hello@byronis.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T23:05:26Z,cfbender,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T23:18:07Z,mimoo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:22:03Z,Yatekii,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T23:22:06Z,Yatekii,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:22:20Z,michael-grunder,michael.grunder@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T23:22:24Z,RenaKunisaki,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T23:22:31Z,xtrm0,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:28:08Z,gabelluardo,gabriele.belluardo@outlook.it https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:29:14Z,appaquet,appaquet@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T23:30:03Z,PrismaPhonic,Peter@PrismaPhonic.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:30:07Z,PrismaPhonic,Peter@PrismaPhonic.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-01T23:31:10Z,robertjerovsek,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:33:30Z,ZOXEXIVO,zoxexivo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:38:20Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:38:24Z,brettinternet,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-01T23:38:25Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-01T23:38:26Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-01T23:38:30Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-01T23:38:34Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-01T23:58:58Z,theraccoonbear,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:03:19Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T00:03:38Z,dos1,dos@dosowisko.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:05:14Z,the-maldridge,maldridge@michaelwashere.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:07:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:07:19Z,panaman67,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T00:07:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T00:07:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T00:13:22Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T00:13:23Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:13:27Z,arzg,aramisnoah@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:13:57Z,ShirleyNekoDev,maximilian.stiede@student.hpi.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T00:14:01Z,ShirleyNekoDev,maximilian.stiede@student.hpi.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:14:05Z,ShirleyNekoDev,maximilian.stiede@student.hpi.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T00:16:56Z,kirk-baird,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:17:03Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T00:17:35Z,ta5een,taseen00.islam@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T00:18:57Z,evant,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:22:21Z,jmolinski,jakub@molinski.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:26:21Z,pauled23,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:26:25Z,pauled23,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:26:38Z,Keavon,keavon@keavon.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T00:26:42Z,Keavon,keavon@keavon.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T00:26:43Z,Keavon,keavon@keavon.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T00:26:44Z,Keavon,keavon@keavon.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:26:45Z,Keavon,keavon@keavon.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T00:34:37Z,bigkraig,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:44:10Z,snawaz,sir_nawaz959@yahoo.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T00:44:12Z,snawaz,sir_nawaz959@yahoo.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T00:44:13Z,snawaz,sir_nawaz959@yahoo.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T00:47:23Z,ThothLogos,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:54:23Z,Khalian,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:56:27Z,zacps,zacmps@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T00:58:25Z,tyrellj,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T01:02:36Z,programmerjake,programmerjake@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T01:07:00Z,dkter,dkteresi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T01:09:12Z,laptou,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T01:12:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T01:13:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T01:32:43Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T01:32:44Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T01:32:46Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T01:32:49Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T01:32:50Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T01:32:52Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T01:34:23Z,Neightro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T01:34:27Z,Neightro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T01:43:32Z,cole-h,cole.e.helbling@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T01:43:33Z,cole-h,cole.e.helbling@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:02:07Z,Blaisorblade,p.giarrusso@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T02:02:09Z,Blaisorblade,p.giarrusso@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T02:02:13Z,Blaisorblade,p.giarrusso@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T02:02:34Z,jumbatm,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T02:05:16Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:12:59Z,olanti-p,olanti-p@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T02:17:18Z,cyphar,cyphar@cyphar.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T02:27:55Z,mcallegari10,martin.callegari94@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:29:41Z,markubiak,mkubiak.dev@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:29:57Z,boustrophedon,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T02:35:29Z,antoineMoPa,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T02:36:31Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:39:38Z,grantras,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T02:51:55Z,gfreezy,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T02:58:57Z,gitsouler,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T02:59:00Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T03:12:49Z,Chasesc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T03:26:59Z,ElusiveMori,me@mori.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T03:31:58Z,humancalico,hey@akshat.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T03:38:49Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T03:38:51Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T03:38:54Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T03:38:55Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T03:38:58Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T03:38:59Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T03:56:32Z,nerdypepper,nerdy@peppe.rs https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T03:56:34Z,nerdypepper,nerdy@peppe.rs https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T04:01:56Z,hyunsikjeong,jhs7jhs@naver.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T04:14:47Z,avocadomaster,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T04:23:09Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T04:29:50Z,pricejc,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T04:40:47Z,GVRV,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:01:35Z,MyYogurt,panosmoisiadis@pm.me https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:06:21Z,bstro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:06:26Z,bstro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T05:09:09Z,paoda,rekai@musuka.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T05:25:35Z,TonyTheMagnificent,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T05:27:41Z,chadselph,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:30:20Z,lambdabear,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:32:45Z,rj00a,ryanj00a@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:33:30Z,simlay,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:34:07Z,dvberkel,daan.v.berkel.1980@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:34:50Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:38:58Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:40:36Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:44:33Z,Meralis40,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:51:43Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T05:51:45Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T05:51:46Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T05:51:49Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T05:51:50Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T05:51:50Z,ze,zelkatani@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T05:52:41Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T05:52:44Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T05:52:45Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:01:23Z,mihainsto,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:03:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:06:18Z,forbjok,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:11:06Z,robinmoussu,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T06:22:36Z,franklsf95,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:24:07Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:24:13Z,tomsiewert,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T06:24:14Z,tomsiewert,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:24:14Z,tomsiewert,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T06:24:16Z,tomsiewert,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T06:24:17Z,tomsiewert,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T06:24:22Z,Batuzz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:26:37Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:26:37Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T06:26:39Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T06:26:40Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T06:26:41Z,msizanoen1,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:27:29Z,9motom6,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:28:08Z,nilsding,nilsding@nilsding.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T06:35:14Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:38:02Z,franky47,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T06:41:48Z,r-bit-rry,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:46:47Z,BojanKogoj,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:49:11Z,oribenshir,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T06:54:50Z,enkelli,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T06:54:51Z,tdh8316,tdh8316@naver.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T06:55:05Z,JosephCatrambone,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:04:44Z,Dietr1ch,dietr1ch@acm.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T07:10:39Z,o0Ignition0o,jeremy.lempereur@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:13:00Z,kpp,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T07:13:25Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:13:40Z,silven,mikael@silven.nu https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:13:45Z,piny4man,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T07:15:53Z,lu-zero,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:20:21Z,rschiang,hi@poren.tw https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:21:36Z,liptakmatyas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:21:57Z,jcgruenhage,jan.christian@gruenhage.xyz https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T07:24:33Z,Kjarrigan,github@kjarrigan.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:38:22Z,borismueller,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:46:44Z,ivanyu,ivanyu@aiven.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:46:46Z,ivanyu,ivanyu@aiven.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T07:46:46Z,ivanyu,ivanyu@aiven.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T07:46:47Z,ivanyu,ivanyu@aiven.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T07:47:08Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:50:02Z,Inomares,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:50:05Z,Inomares,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T07:53:16Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T07:53:19Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T07:55:03Z,beagleknight,david.morcillo@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T08:00:26Z,a-qxin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:00:33Z,a-qxin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:03:26Z,YtvwlD,niklas@ytvwld.de https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:06:07Z,j30ng,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T08:17:20Z,CodeSandwich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:17:21Z,CodeSandwich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T08:17:24Z,CodeSandwich,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T08:20:00Z,Dietr1ch,dietr1ch@acm.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:20:17Z,orangemocha,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:23:56Z,Zoltan-Balazs,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:24:13Z,Aracem,marcostruji@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:24:14Z,Aracem,marcostruji@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T08:24:14Z,Aracem,marcostruji@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T08:24:15Z,Aracem,marcostruji@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:24:15Z,sekunho,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T08:24:17Z,Aracem,marcostruji@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:24:50Z,frictionPG,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:31:10Z,manugildev,manugildev@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:35:30Z,pmeinhardt,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:36:11Z,nickgnd,nicolo.gnudi@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:36:24Z,willydee,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:37:08Z,L1nkus,juliusz.kk@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T08:43:37Z,agluszak,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:47:53Z,captainGeech42,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T08:48:00Z,captainGeech42,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T08:48:00Z,captainGeech42,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T08:57:30Z,capponMatteo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T08:57:51Z,anthonyreinettesonos,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:03:23Z,ferrix,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T09:03:24Z,JackThomson2,jackathomson@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T09:03:25Z,JackThomson2,jackathomson@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:03:26Z,JackThomson2,jackathomson@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T09:06:47Z,rokkerruslan,rokkerruslan@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:07:49Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:09:18Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T09:09:22Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T09:09:23Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T09:09:24Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T09:09:25Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:09:27Z,ilai-deutel,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:11:55Z,Ran4,rasmus.ansin@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T09:13:20Z,qboileau,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:18:30Z,sp-jordi-forns,jordi.forns@socialpoint.es https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:19:35Z,oleaalarsen,ole00larsen@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:20:23Z,adrienbaron,adrien@abaron.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:29:37Z,qnighy,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T09:30:17Z,Sogomn,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:39:37Z,marco-c,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T09:39:39Z,marco-c,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T09:39:40Z,marco-c,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:39:55Z,Starl1ght,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T09:41:05Z,kellpossible,l.frisken@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T09:41:19Z,ThibsG,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:42:13Z,xkubov,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T09:46:04Z,mihaitodor,todormihai@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T09:46:08Z,mihaitodor,todormihai@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T09:48:40Z,SrTobi,code.databyte@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:51:24Z,tforgione,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:51:35Z,arosetti,alessandro.rosetti@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T09:55:45Z,ethercrow,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T09:58:33Z,mpapierski,michal@papierski.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T10:04:20Z,remigastaldi,remi.gastaldi@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T10:05:01Z,dunnock,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T10:06:54Z,davidbernalabb,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T10:22:02Z,delvedor,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T10:28:28Z,Adanos020,a.gasior@newcastle.ac.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T10:28:40Z,Adanos020,a.gasior@newcastle.ac.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T10:35:44Z,Ytrog,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T10:38:42Z,rlespinasse,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T10:38:43Z,rlespinasse,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T10:38:46Z,rlespinasse,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T10:38:49Z,rlespinasse,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T10:46:26Z,dabljues,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T10:49:56Z,dwardu89,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T10:59:07Z,OliverHofkens,oliver@gorilla.co https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T10:59:09Z,OliverHofkens,oliver@gorilla.co https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T10:59:12Z,OliverHofkens,oliver@gorilla.co https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T11:03:36Z,VanillaBrooks,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T11:03:53Z,veggero,niccolo@venerandi.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T11:04:45Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T11:04:46Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T11:10:01Z,wrux,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T11:10:01Z,wrux,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T11:11:59Z,clavin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T11:16:21Z,nasa42,nasa42@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T11:29:31Z,kwohlfahrt,kai.wohlfahrt@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T11:34:46Z,tcbegley,tomcbegley@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T11:35:47Z,maxoly,massimo.oliviero@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T11:35:50Z,maxoly,massimo.oliviero@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T11:39:01Z,Panky-codes,pankydev8@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T12:02:09Z,robinfriedli,robinfriedli@icloud.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T12:04:15Z,hugosilvaguerreiro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T12:04:17Z,hugosilvaguerreiro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T12:23:06Z,craiga,craiga@craiga.id.au https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T12:29:30Z,sgrowe,sgrowe@live.co.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T12:34:50Z,JacobTheEvans,jacobtheevans@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T12:34:51Z,JacobTheEvans,jacobtheevans@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T13:00:03Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T13:10:10Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T13:10:12Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T13:10:15Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T13:12:12Z,clock21am,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T13:34:48Z,poulp,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T13:48:06Z,noisersup,patryk@kwiatek.xyz https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T13:54:06Z,lili668668,lili668668@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T14:01:25Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T14:07:06Z,muloka,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-02T14:15:49Z,nedseb,sebastien@nedjar.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T14:20:44Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T14:20:44Z,bencelaszlo,bencelaszlo@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T14:24:35Z,swfsql,swfsql@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T14:27:03Z,elihunter173,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T14:27:05Z,elihunter173,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T14:54:57Z,evanlazaro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T15:02:22Z,nwn,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T15:04:45Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T15:04:47Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T15:25:37Z,EverlastingBugstopper,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T15:37:32Z,Eragonfr,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T15:37:36Z,Eragonfr,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T15:47:02Z,dcariotti,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T16:01:03Z,aklitzke,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T16:10:09Z,honnza,honnza@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T16:10:31Z,theduke,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T16:11:18Z,kylegalbraith,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T16:31:29Z,armand1m,armando.mag95@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T16:31:30Z,armand1m,armando.mag95@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T16:31:30Z,armand1m,armando.mag95@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T16:31:33Z,armand1m,armando.mag95@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T16:31:34Z,armand1m,armando.mag95@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T16:33:33Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T16:33:49Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T16:33:50Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T16:33:51Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T16:36:57Z,Zeroeh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T17:17:52Z,SaltyAimbOtter,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T17:36:01Z,ronlobo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T17:59:15Z,BaiqingL,baiqinglyu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T17:59:16Z,BaiqingL,baiqinglyu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T17:59:17Z,BaiqingL,baiqinglyu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T17:59:22Z,BaiqingL,baiqinglyu@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:15:13Z,Seirdy,seirdy@seirdy.one https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:15:23Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T18:15:24Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T18:15:24Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T18:15:25Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T18:15:25Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-02T18:15:26Z,iahuang,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:19:02Z,Eivinddh,eivind.d.halderaker@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T18:19:04Z,Eivinddh,eivind.d.halderaker@hotmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T18:22:02Z,ldr709,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T18:31:28Z,GeorgeHahn,George.Hahn.VHS@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T18:31:59Z,JoelEllis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T18:32:02Z,JoelEllis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:32:02Z,JoelEllis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T18:32:04Z,JoelEllis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:39:15Z,panicbit,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T18:39:17Z,panicbit,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-02T18:39:18Z,panicbit,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T18:39:19Z,panicbit,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-02T18:39:20Z,panicbit,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T18:40:44Z,kuberkaul,kuberkaul1989@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T18:55:39Z,thomasaiman,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-02T19:10:08Z,mrchief,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T19:19:26Z,pa3ng,raph@moov.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T21:07:54Z,vinhowe,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-02T21:42:31Z,foldu,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-02T22:32:46Z,Ghabriel,ghabriel.nunes@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-02T22:32:47Z,Ghabriel,ghabriel.nunes@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T00:52:41Z,OctavioBR,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T02:19:27Z,f8122dac,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T02:19:30Z,f8122dac,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T04:19:03Z,magks,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T07:50:20Z,ozanerdogan90,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-03T07:55:04Z,simoheinonen,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T09:03:56Z,zeenix,zeeshanak@gnome.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T09:31:45Z,ibazulic,ibazulic@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T09:31:47Z,ibazulic,ibazulic@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-03T09:31:49Z,ibazulic,ibazulic@redhat.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-03T09:44:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-03T09:47:50Z,manusa,marc@marcnuri.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T13:20:24Z,kahboom,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T13:20:28Z,kahboom,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-03T13:20:30Z,kahboom,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-03T15:13:01Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T15:58:04Z,apragacz,apragacz@o2.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T16:06:48Z,alecmerdler,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T16:14:06Z,unleashed,alex@flawedcode.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-03T16:14:10Z,unleashed,alex@flawedcode.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T19:47:10Z,Quetzal2,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-03T19:47:11Z,Quetzal2,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-03T21:05:15Z,ioanachirca,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-03T23:23:58Z,Dizeeee,jackxmalcom@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-04T03:42:33Z,yohan-pg,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-04T05:48:51Z,JimLynchCodes,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-04T05:49:01Z,JimLynchCodes,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-04T16:13:18Z,musikid,musikid@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-04T16:34:04Z,TheButlah,thebutlah@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-04T19:44:37Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-04T19:44:39Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-04T23:57:47Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-04T23:57:50Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-05T08:24:43Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-05T08:24:45Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-05T08:24:46Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-05T16:32:00Z,danbruder,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-05T18:59:05Z,janriemer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-05T18:59:06Z,janriemer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-05T22:09:54Z,A-UNDERSCORE-D,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-06T08:52:32Z,AntonOellerer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-06T09:20:43Z,anderejd,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-06T16:19:14Z,coffeenotfound,jan@katzer.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-06T17:54:51Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-06T19:13:33Z,gus3inov,gus3inov@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-08T01:19:41Z,joseluis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-08T01:19:46Z,joseluis,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-08T13:29:19Z,dontlaugh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-08T22:10:32Z,BreadFish64,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-09T15:54:30Z,bobbae,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-09T16:05:02Z,dsherret,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-09T16:16:36Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-09T16:16:37Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-04-09T16:16:37Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-09T16:16:39Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-09T16:16:40Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-09T16:16:43Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-09T16:16:43Z,ratijas,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-09T20:17:34Z,streof,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-10T12:52:08Z,CodingKoopa,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-10T21:59:27Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-10T21:59:29Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-10T21:59:29Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-04-10T21:59:30Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-04-12T11:26:49Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2020-04-12T11:26:55Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-12T11:29:43Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-13T07:37:28Z,akeamc,ake@amcoff.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-13T07:37:49Z,akeamc,ake@amcoff.net https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-13T23:17:48Z,rhymefororange,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-15T00:52:57Z,dmmulroy,dillon.mulroy@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-15T00:52:59Z,dmmulroy,dillon.mulroy@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-04-15T00:53:00Z,dmmulroy,dillon.mulroy@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-04-15T00:53:01Z,dmmulroy,dillon.mulroy@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-17T14:00:49Z,s3rvac,s3rvac@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-20T12:18:22Z,PatrickOBoyle,patrickoboyle21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-20T12:18:24Z,PatrickOBoyle,patrickoboyle21@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-04-21T16:36:41Z,ShubhangKrishna,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-23T23:07:54Z,vexx32,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-28T23:04:15Z,micromaomao,m@maowtm.org https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-04-30T09:32:11Z,ngotchac,ngotchac@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-05-01T21:01:31Z,sharno,sharnoby3@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-05-08T10:39:39Z,ShadowJonathan,jonathandejong02@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-05-28T15:43:01Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-05-28T15:43:04Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-05-28T15:43:05Z,Daksh14,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-05-29T06:51:28Z,ikanago,ikanago-dev@protonmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2020-05-29T18:25:33Z,ilyavenner,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-05-30T15:49:36Z,3c1u,3c1u@tohkani.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-05-31T16:55:19Z,not-matthias,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-06-02T14:57:19Z,Pedro-Souza,souza.vipedro@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-06-03T07:21:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-06-10T21:15:56Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-06-16T10:09:41Z,davtur19,dav.tur19@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2020-06-19T20:03:15Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-06-19T20:19:01Z,icefoxen,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-06-26T12:49:14Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-07-01T19:04:36Z,samsartor,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-07-06T06:53:04Z,Fyko,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-07-29T15:48:18Z,kumuji,alexey@nekrasov.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-08-26T09:25:51Z,Fogapod,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2020-09-02T16:38:21Z,danii,himself@danii.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2020-09-02T16:38:24Z,danii,himself@danii.dev https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-09-04T10:35:20Z,Snoop05,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-09-07T23:16:57Z,Owez,root@ogriffiths.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-09-17T17:39:17Z,outloudvi,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2020-10-03T09:39:10Z,Newbytee,newbie13xd@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-10-19T11:59:12Z,MLG-fun,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2020-10-20T06:06:15Z,rafi9898,r-podraza@wp.pl https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2020-10-26T05:53:02Z,zml2008,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-01-01T18:51:47Z,koalp,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-01-18T05:50:15Z,ALinuxPerson,alinuxperson@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-02-26T11:59:34Z,thibault-ml,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2021-02-26T11:59:37Z,thibault-ml,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-02-26T11:59:39Z,thibault-ml,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-02-27T23:16:05Z,ReturnedTrue,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-02-28T16:19:27Z,oilaba,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-02-28T16:20:38Z,oilaba,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-03-03T06:47:19Z,prekel,misterptits@yandex.ru https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-04-08T13:53:07Z,joboet,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-15T05:01:33Z,XDXD-XDXD,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-04-15T05:01:36Z,XDXD-XDXD,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-04-16T14:44:44Z,kizza7984,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-16T14:52:24Z,xleelz,xleelz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-04-16T14:52:28Z,xleelz,xleelz@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-16T14:59:56Z,scxr,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-26T19:56:57Z,Milo123459,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-27T03:58:43Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-04-27T04:09:03Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2021-04-27T04:09:03Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-04-27T04:09:09Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2021-04-27T04:09:10Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2021-04-27T04:09:11Z,safinsingh,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-04-27T04:14:41Z,cjdenio,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-04-27T04:29:17Z,anirudhb,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-04-27T05:22:20Z,bellesea,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2021-04-27T05:22:25Z,bellesea,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-05-03T19:00:37Z,AaronRecord,aaronjrecord@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-04T01:55:23Z,Raspberry1111,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-04T02:16:18Z,VoidCatter,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-18T16:14:10Z,eduardosalaz,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-18T16:44:20Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-05-18T21:54:56Z,Anders429,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-19T00:29:39Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-05-19T00:29:43Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-05-19T00:29:43Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2021-05-19T00:29:50Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2021-05-19T00:29:54Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-05-19T00:29:54Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2021-05-19T00:29:56Z,seandewar,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-26T15:59:46Z,apppppppple,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-27T06:22:50Z,jae1911,me@jae.fi https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-05-27T09:23:57Z,Xerbo,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-06-07T18:11:36Z,rokonio,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-06-11T03:44:18Z,metamemelord,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-06-23T15:32:40Z,Madoshakalaka,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-07-03T01:33:29Z,paij0se,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-07-13T20:44:03Z,oidro,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-07-23T17:22:25Z,ElonMax404,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-07-23T17:22:30Z,ElonMax404,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-07-27T10:35:00Z,rambip,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-08-04T04:15:14Z,Procrat,stijnseghers@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-08-04T04:15:31Z,Procrat,stijnseghers@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-08-18T11:25:41Z,bee-san,github@skerritt.blog https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-08-24T01:42:10Z,BGR360,benwolverine2019@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-09-14T17:56:35Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-09-14T18:12:35Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,EYES,2021-09-14T18:12:39Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-09-14T18:12:39Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2021-09-14T18:12:40Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-09-14T18:18:51Z,DerpyChap,holla@derpychap.co.uk https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2021-09-14T19:05:02Z,rnbguy,mail@ranadeep.in https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-09-14T19:05:15Z,rnbguy,mail@ranadeep.in https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2021-09-14T19:05:17Z,rnbguy,mail@ranadeep.in https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2021-09-14T19:05:17Z,rnbguy,mail@ranadeep.in https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2021-10-16T16:30:31Z,Blytungdev,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2021-11-01T14:20:32Z,CarlSchwan,carl@carlschwan.eu https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-01-07T00:24:52Z,smj-edison,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2022-01-22T10:39:19Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-01-24T09:39:27Z,spacecheeserocks,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2022-01-24T14:47:45Z,PrincessOfEvil,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_DOWN,2022-01-24T23:08:45Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-01-27T13:48:42Z,pro465,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,CONFUSED,2022-02-12T09:42:27Z,Zxilly,zxilly@outlook.com https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-03-04T04:46:58Z,gimbles,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-03-11T17:55:09Z,Nufflee,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-03-16T08:01:39Z,AlexKalopsia,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2022-03-16T08:01:41Z,AlexKalopsia,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2022-03-16T08:01:42Z,AlexKalopsia,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2022-03-16T08:05:38Z,AlexKalopsia,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-03-17T18:30:54Z,leetfin,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2022-03-18T23:45:01Z,NotWearingPants,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-03-31T11:56:38Z,realAP,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,LAUGH,2022-03-31T11:56:39Z,realAP,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HOORAY,2022-03-31T11:56:40Z,realAP,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,HEART,2022-03-31T11:56:40Z,realAP,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,ROCKET,2022-03-31T11:56:41Z,realAP,NA https://github.com/rust-lang/rust/pull/70645,CLOSED,2020-04-01T07:17:56Z,2020-04-02T13:18:07Z,Forbid pineapple on pizza,pietroalbini,NA,NA,NA,THUMBS_UP,2022-06-12T19:43:23Z,MysticalUser,NA https://github.com/rust-lang/rust/pull/70650,CLOSED,2020-04-01T11:21:37Z,2020-04-01T12:20:57Z,Make clippy a subrepo,oli-obk,NA,NA,NA,HOORAY,2020-04-01T11:28:52Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-04-02T07:15:37Z,mati865,NA https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-04-02T09:42:48Z,ThibsG,NA https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-04-23T12:00:57Z,felix91gr,NA https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-04-27T19:08:43Z,tmandry,NA https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-05-02T13:24:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-05-02T17:52:57Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70655,MERGED,2020-04-01T12:55:00Z,2020-05-02T16:25:32Z,Make clippy a git subtree instead of a git submodule,oli-obk,53d3bc02ed90eba01c5dbc5b2d0c4cabb67ffb4d,1294,Auto merge of #70655 - oli-obk:subrepo_funness r=Mark-Simulacrum Make clippy a git subtree instead of a git submodule r? @eddyb cc #70651 documentation at https://github.com/rust-lang/rust/pull/70654,HEART,2020-05-06T04:20:08Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-02T07:34:52Z,mati865,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-02T16:44:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-02T18:38:29Z,tmandry,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-02T18:46:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-03T09:36:24Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-03T11:09:12Z,raggy-rs,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-05T15:22:17Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-08T19:26:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-04-09T18:15:16Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-05-02T12:39:40Z,Mrmaxmeier,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-05-11T08:28:37Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-05-14T03:44:57Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-05-17T18:59:53Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HEART,2020-05-17T19:00:02Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-06-05T22:35:12Z,adetaylor,NA https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HOORAY,2020-10-10T16:24:57Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/70680,CLOSED,2020-04-02T04:03:11Z,2020-06-05T02:39:27Z,WIP toward LLVM Code Coverage for Rust,richkadel,NA,NA,NA,HEART,2020-10-10T16:24:58Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/70699,CLOSED,2020-04-02T14:56:22Z,2020-04-08T10:40:21Z,Make our pattern matching logic undestand `&[T]` constants,oli-obk,NA,NA,NA,HEART,2020-04-02T15:13:10Z,varkor,NA https://github.com/rust-lang/rust/pull/70699,CLOSED,2020-04-02T14:56:22Z,2020-04-08T10:40:21Z,Make our pattern matching logic undestand `&[T]` constants,oli-obk,NA,NA,NA,HEART,2020-04-02T15:18:54Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70707,MERGED,2020-04-02T18:06:54Z,2020-04-03T23:50:13Z,Remove unused graphviz emitter,ecstatic-morse,aa42d12d16982713bde501bb8a258196129499b6,1,Rollup merge of #70707 - ecstatic-morse:dataflow-graphviz-cleanup r=nikomatsakis Remove unused graphviz emitter This was only used by the old dataflow framework that was removed in #69644.,HEART,2020-04-03T06:23:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/70712,MERGED,2020-04-02T19:18:04Z,2020-04-25T20:54:34Z,stabilize BTreeMap::remove_entry,DutchGhost,29fd52811428c040b972a6ac77dbbb8b69239b45,1,Rollup merge of #70712 - :stabilize-remove-entry r=Amanieu stabilize BTreeMap::remove_entry This PR stabilizes `BTreeMap::remove_entry` as implemented in https://github.com/rust-lang/rust/pull/68378. Closes https://github.com/rust-lang/rust/issues/66714,HOORAY,2020-04-02T22:46:27Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/70712,MERGED,2020-04-02T19:18:04Z,2020-04-25T20:54:34Z,stabilize BTreeMap::remove_entry,DutchGhost,29fd52811428c040b972a6ac77dbbb8b69239b45,1,Rollup merge of #70712 - :stabilize-remove-entry r=Amanieu stabilize BTreeMap::remove_entry This PR stabilizes `BTreeMap::remove_entry` as implemented in https://github.com/rust-lang/rust/pull/68378. Closes https://github.com/rust-lang/rust/issues/66714,HOORAY,2020-04-13T14:49:49Z,billyrieger,NA https://github.com/rust-lang/rust/pull/70712,MERGED,2020-04-02T19:18:04Z,2020-04-25T20:54:34Z,stabilize BTreeMap::remove_entry,DutchGhost,29fd52811428c040b972a6ac77dbbb8b69239b45,1,Rollup merge of #70712 - :stabilize-remove-entry r=Amanieu stabilize BTreeMap::remove_entry This PR stabilizes `BTreeMap::remove_entry` as implemented in https://github.com/rust-lang/rust/pull/68378. Closes https://github.com/rust-lang/rust/issues/66714,HOORAY,2020-04-23T14:18:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70720,MERGED,2020-04-02T21:05:56Z,2020-04-03T23:50:11Z,Place TLS initializers with relocations in .tdata,ecstatic-morse,80690b0418aa2f352fda2fe436233e00356cb95a,2,Rollup merge of #70720 - ecstatic-morse:issue-70637 r=oli-obk Place TLS initializers with relocations in .tdata Should fix #70673 although I'm not sure how to test this. Perhaps @joshlf could find a MCVE? Also adds more context to the FIXME. r? @oli-obk,HEART,2020-04-03T12:17:02Z,cormacrelf,NA https://github.com/rust-lang/rust/pull/70720,MERGED,2020-04-02T21:05:56Z,2020-04-03T23:50:11Z,Place TLS initializers with relocations in .tdata,ecstatic-morse,80690b0418aa2f352fda2fe436233e00356cb95a,2,Rollup merge of #70720 - ecstatic-morse:issue-70637 r=oli-obk Place TLS initializers with relocations in .tdata Should fix #70673 although I'm not sure how to test this. Perhaps @joshlf could find a MCVE? Also adds more context to the FIXME. r? @oli-obk,HEART,2020-04-09T17:55:34Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/70733,MERGED,2020-04-03T11:14:54Z,2020-05-08T04:40:32Z,Add Arc::{incr decr}_strong_count,yoshuawuyts,5e9b3720e5c49656b78a047922bbc34fe74a67b3,2,Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount r=Mark-Simulacrum Add Arc::{incr decr}_strong_count This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064 and from asking a few people this seemed like generally useful to have. References: - [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064) - [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13),HEART,2020-04-03T11:39:00Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/70733,MERGED,2020-04-03T11:14:54Z,2020-05-08T04:40:32Z,Add Arc::{incr decr}_strong_count,yoshuawuyts,5e9b3720e5c49656b78a047922bbc34fe74a67b3,2,Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount r=Mark-Simulacrum Add Arc::{incr decr}_strong_count This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064 and from asking a few people this seemed like generally useful to have. References: - [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064) - [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13),HEART,2020-04-08T07:25:20Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/70733,MERGED,2020-04-03T11:14:54Z,2020-05-08T04:40:32Z,Add Arc::{incr decr}_strong_count,yoshuawuyts,5e9b3720e5c49656b78a047922bbc34fe74a67b3,2,Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount r=Mark-Simulacrum Add Arc::{incr decr}_strong_count This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064 and from asking a few people this seemed like generally useful to have. References: - [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064) - [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13),HEART,2020-04-10T05:43:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-04T01:26:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-04T04:46:05Z,xrl,NA https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-04T09:34:12Z,crepererum,marco@crepererum.net https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-04T12:44:53Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-04T16:22:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-04-11T13:51:55Z,npmccallum,nathaniel@mccallum.life https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-08-27T20:40:52Z,DianaNites,NA https://github.com/rust-lang/rust/pull/70740,MERGED,2020-04-03T16:26:01Z,2020-06-19T12:13:49Z,Enabling static-pie for musl,haraldh,27d4737ef9f54613e01594b49217378ac05cca42,3,"Rollup merge of #70740 - haraldh:static-pie r=petrochenkov Enabling static-pie for musl and make it the default for the x86_64-unknown-linux-musl target This is a quick implementation for https://github.com/rust-lang/rust/issues/70693 Opening it as a draft PR to gather some feedback before I put more work in it. ```console ❯ cat hello.rs fn main() { println!(""main = {:#x}"" &main as *const _ as usize); } ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl ~/hello.rs ❯ ldd hello statically linked ❯ file hello hello: ELF 64-bit LSB shared object x86-64 version 1 (GNU/Linux) statically linked BuildID[sha1]=fec5cdc170f503a712a63a6958691ce5ce433654 with debug_info not stripped ❯ ./hello main = 0x7f233ca30008 ❯ ./hello main = 0x7f9ddc529008 ❯ ./hello main = 0x7f1e5a224008 ❯ ./hello main = 0x7f4485c7c008 ❯ /tmp/rust-musl/bin/rustc --target x86_64-unknown-linux-musl -Z print-link-args ~/hello.rs ""cc"" ""-Wl --as-needed"" ""-Wl -z noexecstack"" ""-Wl --eh-frame-hdr"" ""-m64"" ""-nostdlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/rcrt1.o"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""hello.hello.7rcbfp3g-cgu.0.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.1.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.2.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.3.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.4.rcgu.o"" ""hello.hello.7rcbfp3g-cgu.5.rcgu.o"" ""-o"" ""hello"" ""hello.1nxjf9so94czdgcz.rcgu.o"" ""-Wl --gc-sections"" ""-static-pie"" ""-Wl -zrelro"" ""-Wl -znow"" ""-nodefaultlibs"" ""-L"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib"" ""-Wl --start-group"" ""-Wl -Bstatic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0f9cb7646f9e2c34.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ba857f2f2e4e7187.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libhashbrown-58ba5e25bbdf9d29.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_alloc-886bfe43afa847dc.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace-fbfb8fe99f19a67b.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-85fa859e7d364cc9.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-07ab026cd3ec0d82.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-a8ec5932d92ea864.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcfg_if-0ba4cc2f38a198d5.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-c1bb2b3ce4f78b7c.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-0ff673c1cf0d451a.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-c8ff2001db856926.rlib"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-2ae14177140eeca2.rlib"" ""-Wl --end-group"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-4fd81b5ce1b08a9c.rlib"" ""-static"" ""-Wl -Bdynamic"" ""/tmp/rust-musl/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"" ``` Closes https://github.com/rust-lang/rust/issues/70693 Closes https://github.com/rust-lang/rust/issues/53968",HOORAY,2020-12-09T14:09:31Z,IceCodeNew,NA https://github.com/rust-lang/rust/pull/70743,MERGED,2020-04-03T17:25:54Z,2020-09-26T08:46:00Z,Fully destructure constants into patterns,oli-obk,fd15e6180d9c48b4f1157e44cdaff6e901e5f854,66,Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion r=eddyb Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed,HOORAY,2020-04-03T18:07:44Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/70743,MERGED,2020-04-03T17:25:54Z,2020-09-26T08:46:00Z,Fully destructure constants into patterns,oli-obk,fd15e6180d9c48b4f1157e44cdaff6e901e5f854,66,Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion r=eddyb Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed,HEART,2020-04-03T19:45:36Z,varkor,NA https://github.com/rust-lang/rust/pull/70743,MERGED,2020-04-03T17:25:54Z,2020-09-26T08:46:00Z,Fully destructure constants into patterns,oli-obk,fd15e6180d9c48b4f1157e44cdaff6e901e5f854,66,Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion r=eddyb Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed,HEART,2020-04-03T20:18:29Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70743,MERGED,2020-04-03T17:25:54Z,2020-09-26T08:46:00Z,Fully destructure constants into patterns,oli-obk,fd15e6180d9c48b4f1157e44cdaff6e901e5f854,66,Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion r=eddyb Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed,HEART,2020-04-03T21:39:41Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70743,MERGED,2020-04-03T17:25:54Z,2020-09-26T08:46:00Z,Fully destructure constants into patterns,oli-obk,fd15e6180d9c48b4f1157e44cdaff6e901e5f854,66,Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion r=eddyb Fully destructure constants into patterns r? `@varkor` as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924 we should probably crater it once reviewed,HOORAY,2020-09-12T19:16:05Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,ROCKET,2020-04-03T18:28:13Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-03T18:28:14Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HEART,2020-04-03T18:28:19Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HEART,2020-04-03T18:32:29Z,flodiebold,flodiebold@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-03T19:05:28Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,ROCKET,2020-04-03T19:10:46Z,SomeoneToIgnore,mail4score@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HEART,2020-04-03T20:47:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-03T21:12:35Z,kjeremy,NA https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-03T22:09:13Z,marcogroppo,NA https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HEART,2020-04-04T01:28:18Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,ROCKET,2020-04-04T01:28:21Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-04T01:28:23Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HEART,2020-04-04T06:53:45Z,detrumi,NA https://github.com/rust-lang/rust/pull/70745,CLOSED,2020-04-03T18:06:14Z,2020-04-04T11:31:53Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-04T10:36:33Z,est31,NA https://github.com/rust-lang/rust/pull/70750,MERGED,2020-04-03T21:39:46Z,2020-04-06T02:21:50Z,Match options directly in the Fuse implementation,cuviper,618ba73b3150ad19979aad96f20506953544122e,1,Rollup merge of #70750 - cuviper:direct-fuse r=scottmcm Match options directly in the Fuse implementation Rather than using `as_ref()` `as_mut()` and `?` we can use `match` directly to save a lot of generated code. This was mentioned as a possibility in https://github.com/rust-lang/rust/pull/70366#issuecomment-603462546 and I found that it had a very large impact on #70332 using `Fuse` within `Chain`. Let's evaluate this change on its own first.,HEART,2020-05-06T18:34:09Z,bluss,NA https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-05T15:08:42Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-06T15:54:43Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-08T20:55:05Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-09T07:18:07Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-09T15:24:33Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-10T05:44:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-04-10T21:16:23Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/70752,MERGED,2020-04-03T22:05:23Z,2020-04-05T09:50:36Z,Add slice::fill,yoshuawuyts,6ea27010b5e648ce6ca9405b732ff548d53f02a4,1,"Rollup merge of #70752 - yoshuawuyts:slice_fill r=dtolnay Add slice::fill Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function. ## Usage ```rust let mut buf = vec![0; 10]; buf.fill(1); assert_eq!(buf vec![1; 10]); ``` ## Performance When compiling in release mode for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile. ## Why now? Conversations about adding `slice::fill` are not new. In fact https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details and it's not seen much forward motion since. In [""The Hunt for the Fastest Zero""](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests the author notes the following: > That the optimization fails perhaps unexpectedly in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms at least where performance matters for example by replacing std::fill with memset? I don’t think so. Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values so it either needs to be optimized at the MIR layer or more likely rely on LLVM's optimizer. By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples. ## References - [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/) - [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html) - [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067) - [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill) - [ASM output on Godbolt](https://godbolt.org/z/5-XU66)",THUMBS_UP,2020-11-29T21:44:06Z,TheButlah,thebutlah@gmail.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-04T11:38:03Z,est31,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-04T13:28:34Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-05T21:31:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-06T01:02:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-06T10:54:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-06T14:02:16Z,lnicola,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-06T14:03:02Z,detrumi,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-07T06:11:47Z,yerke,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-07T12:34:55Z,bkchr,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-08T04:31:48Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-08T17:13:59Z,mikhail-m1,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-09T18:38:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-20T07:08:44Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-04-21T11:42:45Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/70761,CLOSED,2020-04-04T11:35:49Z,2020-05-15T10:46:55Z,Add support for parsing with rust-analyzer instead of librustc_parse,luca-barbieri,NA,NA,NA,HOORAY,2020-05-01T08:13:17Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/70765,CLOSED,2020-04-04T12:22:46Z,2020-04-22T11:02:03Z,AtomicPtr without losing pointer provenance,RalfJung,NA,NA,NA,HEART,2020-04-13T02:27:49Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/70771,MERGED,2020-04-04T14:59:27Z,2020-04-06T14:43:57Z, Miri terminator handling: only do progress sanity check for 'Call' terminator,RalfJung,bd18bc9a4c142100a7230e1fd1cfe6be08214693,8,Auto merge of #70771 - RalfJung:ctfe-loop r=oli-obk Miri terminator handling: only do progress sanity check for 'Call' terminator This will still catch mistakes in bad intrinsic/foreign-item shims which is the main source of errors here. Fixes https://github.com/rust-lang/rust/issues/70723 r? @oli-obk,HEART,2020-04-04T15:44:37Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/70776,MERGED,2020-04-04T17:33:16Z,2020-04-05T16:13:47Z,clarify comment in RawVec::into_box,RalfJung,c185c4fe4740227100c869da44825ca6eb80be74,1,"Rollup merge of #70776 - RalfJung:raw-vec r=Dylan-DPC TimDiekmann clarify comment in RawVec::into_box On first reading I almost thought ""len <= cap"" would be all that there is to check here. Expand the comment to clarify that that is not the case.",THUMBS_UP,2020-04-05T07:37:50Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-04-11T22:32:24Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-08-04T16:01:01Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-08-26T02:42:11Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-09-04T01:58:52Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-09-10T04:23:27Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-09-11T05:22:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-04T10:45:12Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-04T17:10:31Z,robinvd,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-04T17:28:53Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-05T05:21:55Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-05T09:01:39Z,Boiethios,NA https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2020-10-05T20:59:14Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/70793,MERGED,2020-04-04T23:30:23Z,2020-09-03T23:29:27Z,specialize some collection and iterator operations to run in-place,the8472,0d0f6b113047b2cf9afbde990cee30fd5b866469,15,Auto merge of #70793 - the8472:in-place-iter-collect r=Amanieu specialize some collection and iterator operations to run in-place This is a rebase and update of #66383 which was closed due inactivity. Recent rustc changes made the compile time regressions disappear at least for webrender-wrench. Running a stage2 compile and the rustc-perf suite takes hours on the hardware I have at the moment so I can't do much more than that. ![Screenshot_2020-04-05 rustc performance data](https://user-images.githubusercontent.com/1065730/78462657-5d60f100-76d4-11ea-8a0b-4f3962707c38.png) In the best case of the `vec::bench_in_place_recycle` synthetic microbenchmark these optimizations can provide a 15x speedup over the regular implementation which allocates a new vec for every benchmark iteration. [Benchmark results](https://gist.github.com/the8472/6d999b2d08a2bedf3b93f12112f96e2f). In real code the speedups are tiny but it also depends on the allocator used a system allocator that uses a process-wide mutex will benefit more than one with thread-local pools. ## What was changed * `SpecExtend` which covered `from_iter` and `extend` specializations was split into separate traits * `extend` and `from_iter` now reuse the `append_elements` if passed iterators are from slices. * A preexisting `vec.into_iter().collect::>()` optimization that passed through the original vec has been generalized further to also cover cases where the original has been partially drained. * A chain of *Vec / BinaryHeap / Box<[T]>* `IntoIter`s through various iterator adapters collected into *Vec* and *BinaryHeap* will be performed in place as long as `T` and `U` have the same alignment and size and aren't ZSTs. * To enable above specialization the unsafe unstable `SourceIter` and `InPlaceIterable` traits have been added. The first allows reaching through the iterator pipeline to grab a pointer to the source memory. The latter is a marker that promises that the read pointer will advance as fast or faster than the write pointer and thus in-place operation is possible in the first place. * `vec::IntoIter` implements `TrustedRandomAccess` for `T: Copy` to allow in-place collection when there is a `Zip` adapter in the iterator. TRA had to be made an unstable public trait to support this. ## In-place collectible adapters * `Map` * `MapWhile` * `Filter` * `FilterMap` * `Fuse` * `Skip` * `SkipWhile` * `Take` * `TakeWhile` * `Enumerate` * `Zip` (left hand side only `Copy` types only) * `Peek` * `Scan` * `Inspect` ## Concerns `vec.into_iter().filter(|_| false).collect()` will no longer return a vec with 0 capacity instead it will return its original allocation. This avoids the cost of doing any allocation or deallocation but could lead to large allocations living longer than expected. If that's not acceptable some resizing policy at the end of the attempted in-place collect would be necessary which in the worst case could result in one more memcopy than the non-specialized case. ## Possible followup work * split liballoc/vec.rs to remove `ignore-tidy-filelength` * try to get trivial chains such as `vec.into_iter().skip(1).collect::>()` to compile to a `memmove` (currently compiles to a pile of SIMD see #69187 ) * improve up the traits so they can be reused by other crates e.g. itertools. I think currently they're only good enough for internal use * allow iterators sourced from a `HashSet` to be in-place collected into a `Vec`,THUMBS_UP,2021-03-14T11:34:47Z,boxdot,NA https://github.com/rust-lang/rust/pull/70803,MERGED,2020-04-05T08:56:08Z,2020-04-05T13:00:43Z,Fix performance regression in debuginfo file_metadata.,arlosi,607b8582362be8e26df7acc12fa242359d7edf95,3,Auto merge of #70803 - arlosi:hash-regression r=eddyb Fix performance regression in debuginfo file_metadata. Fixes performance regression caused by #69718. Finding the `SourceFile` associated with a `FileName` called `get_source_file` on the `SourceMap` which does a linear search through all files in the `SourceMap`. This resolves the issue by passing the `SourceFile` in from the caller (which already had it available) instead of the `FileName` Fixes #70785.,HEART,2020-04-05T19:12:13Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70815,MERGED,2020-04-05T15:14:36Z,2020-04-05T22:48:24Z,Enable layout debugging for `impl Trait` type aliases,RalfJung,8c081f69fb35814710649c54cc23aff05c06881b,3,Rollup merge of #70815 - RalfJung:layout-debug r=jonas-schievink Enable layout debugging for `impl Trait` type aliases I also made it print the actual type name that the alias picks under the hood.,THUMBS_UP,2020-04-05T16:28:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70817,MERGED,2020-04-05T16:48:04Z,2020-07-19T07:26:23Z,Add core::task::ready! macro,yoshuawuyts,479c8ad17c6908bd792dcacb0a3e0b5503903cf4,3,Rollup merge of #70817 - yoshuawuyts:task-ready r=dtolnay Add core::task::ready! macro This PR adds `ready!` as a top-level macro to `libcore` following the implementation of `futures_core::ready` tracking issue https://github.com/rust-lang/rust/issues/70922. This macro is commonly used when implementing `Future` `AsyncRead` `AsyncWrite` and `Stream`. And being only 5 lines it seems like a useful and straight forward addition to std. ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ``` ## Naming In `async-std` we chose to nest the macro under the `task` module instead of having the macro at the top-level. This is a pattern that currently does not occur in std mostly due to this not being possible prior to Rust 2018. This PR proposes to add the `ready` macro as `core::ready`. But another option would be to introduce it as `core::task::ready` since it's really only useful when used in conjunction with `task::{Context Poll}`. ## Implementation questions I tried rendering the documentation locally but the macro didn't show up under `core`. I'm not sure if I quite got this right. I used the [`todo!` macro PR](https://github.com/rust-lang/rust/pull/56348/files) as a reference and our approaches look similar. ## References - [`futures::ready`](https://docs.rs/futures/0.3.4/futures/macro.ready.html) - [`async_std::task::ready`](https://docs.rs/async-std/1.5.0/async_std/task/index.html) - [`futures_core::ready`](https://docs.rs/futures-core/0.3.4/futures_core/macro.ready.html),HEART,2020-04-12T18:53:40Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/70817,MERGED,2020-04-05T16:48:04Z,2020-07-19T07:26:23Z,Add core::task::ready! macro,yoshuawuyts,479c8ad17c6908bd792dcacb0a3e0b5503903cf4,3,Rollup merge of #70817 - yoshuawuyts:task-ready r=dtolnay Add core::task::ready! macro This PR adds `ready!` as a top-level macro to `libcore` following the implementation of `futures_core::ready` tracking issue https://github.com/rust-lang/rust/issues/70922. This macro is commonly used when implementing `Future` `AsyncRead` `AsyncWrite` and `Stream`. And being only 5 lines it seems like a useful and straight forward addition to std. ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ``` ## Naming In `async-std` we chose to nest the macro under the `task` module instead of having the macro at the top-level. This is a pattern that currently does not occur in std mostly due to this not being possible prior to Rust 2018. This PR proposes to add the `ready` macro as `core::ready`. But another option would be to introduce it as `core::task::ready` since it's really only useful when used in conjunction with `task::{Context Poll}`. ## Implementation questions I tried rendering the documentation locally but the macro didn't show up under `core`. I'm not sure if I quite got this right. I used the [`todo!` macro PR](https://github.com/rust-lang/rust/pull/56348/files) as a reference and our approaches look similar. ## References - [`futures::ready`](https://docs.rs/futures/0.3.4/futures/macro.ready.html) - [`async_std::task::ready`](https://docs.rs/async-std/1.5.0/async_std/task/index.html) - [`futures_core::ready`](https://docs.rs/futures-core/0.3.4/futures_core/macro.ready.html),HEART,2020-07-19T08:54:55Z,wolf4ood,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-06T08:30:09Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T08:49:51Z,oli-cosmian,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T09:07:00Z,menixator,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-06T09:09:58Z,ansrivas,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T09:26:22Z,bkolobara,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T10:13:55Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-06T13:20:38Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T14:27:19Z,payload,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-06T16:17:15Z,rrbutani,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-07T00:42:21Z,95th,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-07T08:57:47Z,Folyd,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-09T08:06:52Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-12T01:01:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-12T01:01:59Z,tesuji,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-12T22:18:56Z,tema3210,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-12T22:18:59Z,tema3210,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-14T01:52:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-17T13:28:42Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-23T00:52:31Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-23T03:30:05Z,tux3,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-23T03:30:08Z,tux3,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-23T12:28:17Z,mcarton,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-23T13:39:44Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-23T15:58:55Z,lnicola,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-23T17:48:00Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-23T18:07:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HEART,2020-04-23T18:07:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70831,MERGED,2020-04-06T01:55:13Z,2020-04-16T12:49:29Z,Remove a stack frame from .await calls,sfackler,4e4d49d60fd696c4036d438292673a2d7fd34519,5,Auto merge of #70831 - sfackler:shrink-future-stack r=matthewjasper Remove a stack frame from .await calls The stack frames when `.await`ing one async fn from another currently look like this: ``` 12: foo::b::{{closure}} at src/main.rs:2 13: as core::future::future::Future>::poll at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66 14: core::future::poll_with_context at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84 15: foo::a::{{closure}} at src/main.rs:6 ``` Since the move away from using TLS to pass the Context around it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame but that seems significantly harder to deal with. It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.,HOORAY,2020-04-24T05:33:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/70834,MERGED,2020-04-06T07:42:28Z,2020-05-09T06:27:57Z,Add core::future::{pending ready},yoshuawuyts,62374ee4ad00a4cc8a4807ed13823a49e2e8422d,3,Rollup merge of #70834 - yoshuawuyts:future-pending-ready r=sfackler Add core::future::{pending ready} Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve or never resolve which is an incredible useful tool when writing documentation. These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate. ## Examples In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin` which leads to the use of `unsafe`. Instead had we had `future::ready` available we could've written the same example without using `unsafe`: ```rust use core::task::{Context Poll}; use core::future::{self Future}; use core::pin::Pin; pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut fut = future::ready(42_u8); let num = ready!(Pin::new(fut).poll(cx)); // ... use num Poll::Ready(()) } ``` ## Why future::ready? Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin` and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)). The final minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future` and can be used as a useful teaching device. ## References - [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html) - [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html) - [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html) - [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html),THUMBS_UP,2020-05-02T06:59:33Z,flosse,NA https://github.com/rust-lang/rust/pull/70834,MERGED,2020-04-06T07:42:28Z,2020-05-09T06:27:57Z,Add core::future::{pending ready},yoshuawuyts,62374ee4ad00a4cc8a4807ed13823a49e2e8422d,3,Rollup merge of #70834 - yoshuawuyts:future-pending-ready r=sfackler Add core::future::{pending ready} Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve or never resolve which is an incredible useful tool when writing documentation. These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate. ## Examples In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin` which leads to the use of `unsafe`. Instead had we had `future::ready` available we could've written the same example without using `unsafe`: ```rust use core::task::{Context Poll}; use core::future::{self Future}; use core::pin::Pin; pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut fut = future::ready(42_u8); let num = ready!(Pin::new(fut).poll(cx)); // ... use num Poll::Ready(()) } ``` ## Why future::ready? Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin` and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)). The final minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future` and can be used as a useful teaching device. ## References - [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html) - [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html) - [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html) - [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html),THUMBS_UP,2020-05-09T10:26:05Z,Folyd,NA https://github.com/rust-lang/rust/pull/70834,MERGED,2020-04-06T07:42:28Z,2020-05-09T06:27:57Z,Add core::future::{pending ready},yoshuawuyts,62374ee4ad00a4cc8a4807ed13823a49e2e8422d,3,Rollup merge of #70834 - yoshuawuyts:future-pending-ready r=sfackler Add core::future::{pending ready} Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve or never resolve which is an incredible useful tool when writing documentation. These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate. ## Examples In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin` which leads to the use of `unsafe`. Instead had we had `future::ready` available we could've written the same example without using `unsafe`: ```rust use core::task::{Context Poll}; use core::future::{self Future}; use core::pin::Pin; pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut fut = future::ready(42_u8); let num = ready!(Pin::new(fut).poll(cx)); // ... use num Poll::Ready(()) } ``` ## Why future::ready? Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin` and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)). The final minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future` and can be used as a useful teaching device. ## References - [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html) - [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html) - [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html) - [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html),HOORAY,2020-05-10T10:32:57Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/70834,MERGED,2020-04-06T07:42:28Z,2020-05-09T06:27:57Z,Add core::future::{pending ready},yoshuawuyts,62374ee4ad00a4cc8a4807ed13823a49e2e8422d,3,Rollup merge of #70834 - yoshuawuyts:future-pending-ready r=sfackler Add core::future::{pending ready} Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve or never resolve which is an incredible useful tool when writing documentation. These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate. ## Examples In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin` which leads to the use of `unsafe`. Instead had we had `future::ready` available we could've written the same example without using `unsafe`: ```rust use core::task::{Context Poll}; use core::future::{self Future}; use core::pin::Pin; pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut fut = future::ready(42_u8); let num = ready!(Pin::new(fut).poll(cx)); // ... use num Poll::Ready(()) } ``` ## Why future::ready? Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin` and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)). The final minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future` and can be used as a useful teaching device. ## References - [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html) - [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html) - [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html) - [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html),THUMBS_UP,2020-05-13T00:48:30Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/70834,MERGED,2020-04-06T07:42:28Z,2020-05-09T06:27:57Z,Add core::future::{pending ready},yoshuawuyts,62374ee4ad00a4cc8a4807ed13823a49e2e8422d,3,Rollup merge of #70834 - yoshuawuyts:future-pending-ready r=sfackler Add core::future::{pending ready} Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve or never resolve which is an incredible useful tool when writing documentation. These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate. ## Examples In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin` which leads to the use of `unsafe`. Instead had we had `future::ready` available we could've written the same example without using `unsafe`: ```rust use core::task::{Context Poll}; use core::future::{self Future}; use core::pin::Pin; pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut fut = future::ready(42_u8); let num = ready!(Pin::new(fut).poll(cx)); // ... use num Poll::Ready(()) } ``` ## Why future::ready? Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin` and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)). The final minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future` and can be used as a useful teaching device. ## References - [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html) - [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html) - [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html) - [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html),THUMBS_UP,2020-08-18T21:07:15Z,faern,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-06T12:30:08Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HOORAY,2020-04-06T12:30:11Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,THUMBS_UP,2020-04-06T12:30:13Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,THUMBS_UP,2020-04-06T13:34:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-06T22:05:58Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-08T07:28:29Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HOORAY,2020-04-08T11:53:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-08T11:53:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-09T02:05:22Z,frol,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-09T05:34:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HOORAY,2020-04-12T20:48:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,HEART,2020-04-16T06:25:15Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/70835,CLOSED,2020-04-06T11:01:48Z,2020-08-13T00:34:50Z,Add Integer::checked_{log log2 log10},yoshuawuyts,NA,NA,NA,THUMBS_UP,2020-07-06T16:30:35Z,Folyd,NA https://github.com/rust-lang/rust/pull/70846,MERGED,2020-04-06T15:03:15Z,2020-04-07T16:58:26Z,Keep codegen units unmerged when building compiler builtins,tmiasko,f56fb51a8bd9b65936abcd4515fff9bced1208da,2,Rollup merge of #70846 - tmiasko:compiler-builtins-codegen-units r=alexcrichton Keep codegen units unmerged when building compiler builtins Make it possible to control how mono items are partitioned into code generation units when compiling the compiler builtins by retaining the original partitioning. Helps with #48625 #61063 #67960 #70489. r? @alexcrichton,THUMBS_UP,2020-04-06T16:33:26Z,mati865,NA https://github.com/rust-lang/rust/pull/70846,MERGED,2020-04-06T15:03:15Z,2020-04-07T16:58:26Z,Keep codegen units unmerged when building compiler builtins,tmiasko,f56fb51a8bd9b65936abcd4515fff9bced1208da,2,Rollup merge of #70846 - tmiasko:compiler-builtins-codegen-units r=alexcrichton Keep codegen units unmerged when building compiler builtins Make it possible to control how mono items are partitioned into code generation units when compiling the compiler builtins by retaining the original partitioning. Helps with #48625 #61063 #67960 #70489. r? @alexcrichton,HEART,2020-04-07T14:52:18Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/70846,MERGED,2020-04-06T15:03:15Z,2020-04-07T16:58:26Z,Keep codegen units unmerged when building compiler builtins,tmiasko,f56fb51a8bd9b65936abcd4515fff9bced1208da,2,Rollup merge of #70846 - tmiasko:compiler-builtins-codegen-units r=alexcrichton Keep codegen units unmerged when building compiler builtins Make it possible to control how mono items are partitioned into code generation units when compiling the compiler builtins by retaining the original partitioning. Helps with #48625 #61063 #67960 #70489. r? @alexcrichton,HEART,2020-04-08T07:51:14Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/70852,CLOSED,2020-04-06T19:17:21Z,2020-04-13T18:28:16Z,MinGW: improve compatibility with LLD,mati865,NA,NA,NA,HEART,2020-04-06T19:20:13Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70852,CLOSED,2020-04-06T19:17:21Z,2020-04-13T18:28:16Z,MinGW: improve compatibility with LLD,mati865,NA,NA,NA,HEART,2020-04-06T19:26:33Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/70868,MERGED,2020-04-06T23:29:16Z,2020-04-09T13:20:43Z,rustc_codegen_ssa: Refactor construction of linker arguments,petrochenkov,cefee7bd9a7e188e406cac0190cf4a19fcca27ff,2,Rollup merge of #70868 - petrochenkov:linkorder r=nagisa mati865 rustc_codegen_ssa: Refactor construction of linker arguments And add comments. This PR doesn't reorder any linker arguments and therefore shouldn't contain any observable changes. The next goal here is to - Factor out order-independent linker arguments in the compiler code and in target specifications and pass them together. Such arguments generally apply to the whole linking session or the produced linking result rather to individual object files or libraries. - Figure out where exactly among the remaining order-dependent arguments we should place customization points like `-C link-args` and `-Z pre-link-args`. - Possibly provide command line opt-outs for options that are currently passed unconditionally (like CRT objects or arguments defined by the target spec). - Document and stabilize the customization points that are not yet stable (https://github.com/rust-lang/rust/pull/70505).,HEART,2020-04-06T23:59:23Z,mati865,NA https://github.com/rust-lang/rust/pull/70872,CLOSED,2020-04-07T01:42:55Z,2020-05-20T13:17:45Z,Enforce a whitelist on the constant primitive types allowed in patterns.,eddyb,NA,NA,NA,THUMBS_UP,2020-04-07T02:11:39Z,varkor,NA https://github.com/rust-lang/rust/pull/70881,MERGED,2020-04-07T12:00:33Z,2020-04-11T15:32:08Z,"bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds.",eddyb,4dfa73a0d8eec6732b70ced27062913bf5160a48,1,"Rollup merge of #70881 - eddyb:stage0-hide-incremental-unused-attrs r=Mark-Simulacrum bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds. This should alleviate #58633 separately from a proper fix. r? @Mark-Simulacrum",THUMBS_UP,2020-04-07T12:02:52Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70881,MERGED,2020-04-07T12:00:33Z,2020-04-11T15:32:08Z,"bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds.",eddyb,4dfa73a0d8eec6732b70ced27062913bf5160a48,1,"Rollup merge of #70881 - eddyb:stage0-hide-incremental-unused-attrs r=Mark-Simulacrum bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds. This should alleviate #58633 separately from a proper fix. r? @Mark-Simulacrum",THUMBS_UP,2020-04-07T12:38:28Z,mati865,NA https://github.com/rust-lang/rust/pull/70881,MERGED,2020-04-07T12:00:33Z,2020-04-11T15:32:08Z,"bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds.",eddyb,4dfa73a0d8eec6732b70ced27062913bf5160a48,1,"Rollup merge of #70881 - eddyb:stage0-hide-incremental-unused-attrs r=Mark-Simulacrum bootstrap: work around ""unused attribute"" errors in incremental stdlib rebuilds. This should alleviate #58633 separately from a proper fix. r? @Mark-Simulacrum",THUMBS_UP,2020-04-11T16:18:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70906,MERGED,2020-04-07T22:12:50Z,2020-04-09T03:28:21Z,Suggest move for closures and async blocks in more cases.,gizmondo,6f8fc4d656b7ab5bc680128074817771628e9985,9,Rollup merge of #70906 - gizmondo:66107 r=estebank Suggest move for closures and async blocks in more cases. Fixes #66107 also improves #67577 Related PR https://github.com/rust-lang/rust/pull/65166,THUMBS_UP,2020-04-08T18:47:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70906,MERGED,2020-04-07T22:12:50Z,2020-04-09T03:28:21Z,Suggest move for closures and async blocks in more cases.,gizmondo,6f8fc4d656b7ab5bc680128074817771628e9985,9,Rollup merge of #70906 - gizmondo:66107 r=estebank Suggest move for closures and async blocks in more cases. Fixes #66107 also improves #67577 Related PR https://github.com/rust-lang/rust/pull/65166,ROCKET,2020-04-09T01:39:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/70909,MERGED,2020-04-07T23:50:25Z,2020-04-10T02:35:18Z,librustc_hir: return LocalDefId instead of DefId in local_def_id,marmeladema,0c835b0cca83fe21090562603e4bda77c183ace3,8,Auto merge of #70909 - marmeladema:issue70853/librustc_hir-local-def-id r=eddyb librustc_hir: return LocalDefId instead of DefId in local_def_id Its a first try to remove a few calls to `expect_local` and use `LocalDefId` instead of `DefId` where possible for #70853 This adds some calls to `.to_def_id()` to get a `DefId` back when needed. I don't know if I should push `LocalDefId` even further and change for example `Res::Def` to accept a `LocalDefId` instead of a `DefId` as second argument. cc @ecstatic-morse,HOORAY,2020-04-08T15:53:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70909,MERGED,2020-04-07T23:50:25Z,2020-04-10T02:35:18Z,librustc_hir: return LocalDefId instead of DefId in local_def_id,marmeladema,0c835b0cca83fe21090562603e4bda77c183ace3,8,Auto merge of #70909 - marmeladema:issue70853/librustc_hir-local-def-id r=eddyb librustc_hir: return LocalDefId instead of DefId in local_def_id Its a first try to remove a few calls to `expect_local` and use `LocalDefId` instead of `DefId` where possible for #70853 This adds some calls to `.to_def_id()` to get a `DefId` back when needed. I don't know if I should push `LocalDefId` even further and change for example `Res::Def` to accept a `LocalDefId` instead of a `DefId` as second argument. cc @ecstatic-morse,HOORAY,2020-04-08T16:52:03Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70911,CLOSED,2020-04-08T01:09:38Z,2020-05-19T10:44:15Z,Move `str` to libcore.,eddyb,NA,NA,NA,LAUGH,2020-04-08T01:41:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/70911,CLOSED,2020-04-08T01:09:38Z,2020-05-19T10:44:15Z,Move `str` to libcore.,eddyb,NA,NA,NA,LAUGH,2020-04-08T04:47:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/70911,CLOSED,2020-04-08T01:09:38Z,2020-05-19T10:44:15Z,Move `str` to libcore.,eddyb,NA,NA,NA,LAUGH,2020-04-08T06:58:03Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70911,CLOSED,2020-04-08T01:09:38Z,2020-05-19T10:44:15Z,Move `str` to libcore.,eddyb,NA,NA,NA,HOORAY,2020-04-08T08:23:25Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/70911,CLOSED,2020-04-08T01:09:38Z,2020-05-19T10:44:15Z,Move `str` to libcore.,eddyb,NA,NA,NA,HOORAY,2020-04-08T19:31:45Z,estebank,NA https://github.com/rust-lang/rust/pull/70912,MERGED,2020-04-08T01:11:22Z,2020-04-09T03:28:19Z,Do not suggest adding type param when `use` is already suggested,estebank,268f09f9e63a3cb9698b32e52f56e11bed6a6f0b,3,Rollup merge of #70912 - estebank:reduce-type-param-sugg-verbosity r=davidtwco Do not suggest adding type param when `use` is already suggested Fix #70365 cc #70572.,HEART,2020-04-08T01:37:00Z,ehuss,NA https://github.com/rust-lang/rust/pull/70913,MERGED,2020-04-08T01:29:06Z,2020-04-10T16:13:38Z,"Replace ""rc""/""arc"" lang items with Rc/Arc diagnostic items.",eddyb,74e93bb8e6cd15dd262868b5e13605e9c595bef7,17,"Rollup merge of #70913 - eddyb:rc-arc-diagnostic-items r=matthewjasper Replace ""rc""/""arc"" lang items with Rc/Arc diagnostic items. `Rc`/`Arc` should have no special semantics so it seems appropriate for them to not be lang items. r? @matthewjasper",THUMBS_UP,2020-04-08T08:20:32Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/70913,MERGED,2020-04-08T01:29:06Z,2020-04-10T16:13:38Z,"Replace ""rc""/""arc"" lang items with Rc/Arc diagnostic items.",eddyb,74e93bb8e6cd15dd262868b5e13605e9c595bef7,17,"Rollup merge of #70913 - eddyb:rc-arc-diagnostic-items r=matthewjasper Replace ""rc""/""arc"" lang items with Rc/Arc diagnostic items. `Rc`/`Arc` should have no special semantics so it seems appropriate for them to not be lang items. r? @matthewjasper",HEART,2020-04-10T10:51:25Z,RalfJung,NA https://github.com/rust-lang/rust/pull/70937,MERGED,2020-04-08T22:54:20Z,2020-04-12T00:31:15Z,Fix staticlib name for *-pc-windows-gnu targets,mati865,5ecc18f3ece1124a56ff76a74c3eb4153be5b3b8,3,Rollup merge of #70937 - mati865:mingw-staticlib-suffix r=petrochenkov Fix staticlib name for *-pc-windows-gnu targets Fix https://github.com/rust-lang/rust/issues/69904 Guess this will need FCP but opened PR anyway to bring the attention. In short Rust has been using wrong `foo.lib` format for static libraries when building for `*-pc-windows-gnu` since version [1.8.0](https://github.com/rust-lang/rust/commit/34b4e66736a0fb65235feadbb5178d42bd09ed67). [LD](https://github.com/bminor/binutils-gdb/blob/f4a220077b03af3a1f905b7dc6dc84c0a06d582f/ld/emultempl/pe.em#L2224-L2227) and [LLD](https://github.com/llvm/llvm-project/blob/0605f5fbe755326e3dbc8daa4fc34453b8c5ac0e/lld/MinGW/Driver.cpp#L140-L141) agree in that regard and only accept static libraries with `libfoo.a` format. So the only thing to break here is when somebody added a hack to rename created library to proper format (like [here](https://gitlab.gnome.org/GNOME/librsvg/-/commit/ad86ab8580c8779fc3eb2bee2422bb116919844e#d5b4de16d947214ec306bd57bed1bd23a939b5f9_197_194)).,HEART,2020-04-08T22:58:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/70937,MERGED,2020-04-08T22:54:20Z,2020-04-12T00:31:15Z,Fix staticlib name for *-pc-windows-gnu targets,mati865,5ecc18f3ece1124a56ff76a74c3eb4153be5b3b8,3,Rollup merge of #70937 - mati865:mingw-staticlib-suffix r=petrochenkov Fix staticlib name for *-pc-windows-gnu targets Fix https://github.com/rust-lang/rust/issues/69904 Guess this will need FCP but opened PR anyway to bring the attention. In short Rust has been using wrong `foo.lib` format for static libraries when building for `*-pc-windows-gnu` since version [1.8.0](https://github.com/rust-lang/rust/commit/34b4e66736a0fb65235feadbb5178d42bd09ed67). [LD](https://github.com/bminor/binutils-gdb/blob/f4a220077b03af3a1f905b7dc6dc84c0a06d582f/ld/emultempl/pe.em#L2224-L2227) and [LLD](https://github.com/llvm/llvm-project/blob/0605f5fbe755326e3dbc8daa4fc34453b8c5ac0e/lld/MinGW/Driver.cpp#L140-L141) agree in that regard and only accept static libraries with `libfoo.a` format. So the only thing to break here is when somebody added a hack to rename created library to proper format (like [here](https://gitlab.gnome.org/GNOME/librsvg/-/commit/ad86ab8580c8779fc3eb2bee2422bb116919844e#d5b4de16d947214ec306bd57bed1bd23a939b5f9_197_194)).,HEART,2020-04-09T08:43:34Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/70937,MERGED,2020-04-08T22:54:20Z,2020-04-12T00:31:15Z,Fix staticlib name for *-pc-windows-gnu targets,mati865,5ecc18f3ece1124a56ff76a74c3eb4153be5b3b8,3,Rollup merge of #70937 - mati865:mingw-staticlib-suffix r=petrochenkov Fix staticlib name for *-pc-windows-gnu targets Fix https://github.com/rust-lang/rust/issues/69904 Guess this will need FCP but opened PR anyway to bring the attention. In short Rust has been using wrong `foo.lib` format for static libraries when building for `*-pc-windows-gnu` since version [1.8.0](https://github.com/rust-lang/rust/commit/34b4e66736a0fb65235feadbb5178d42bd09ed67). [LD](https://github.com/bminor/binutils-gdb/blob/f4a220077b03af3a1f905b7dc6dc84c0a06d582f/ld/emultempl/pe.em#L2224-L2227) and [LLD](https://github.com/llvm/llvm-project/blob/0605f5fbe755326e3dbc8daa4fc34453b8c5ac0e/lld/MinGW/Driver.cpp#L140-L141) agree in that regard and only accept static libraries with `libfoo.a` format. So the only thing to break here is when somebody added a hack to rename created library to proper format (like [here](https://gitlab.gnome.org/GNOME/librsvg/-/commit/ad86ab8580c8779fc3eb2bee2422bb116919844e#d5b4de16d947214ec306bd57bed1bd23a939b5f9_197_194)).,HEART,2020-04-09T16:05:04Z,crlf0710,NA https://github.com/rust-lang/rust/pull/70937,MERGED,2020-04-08T22:54:20Z,2020-04-12T00:31:15Z,Fix staticlib name for *-pc-windows-gnu targets,mati865,5ecc18f3ece1124a56ff76a74c3eb4153be5b3b8,3,Rollup merge of #70937 - mati865:mingw-staticlib-suffix r=petrochenkov Fix staticlib name for *-pc-windows-gnu targets Fix https://github.com/rust-lang/rust/issues/69904 Guess this will need FCP but opened PR anyway to bring the attention. In short Rust has been using wrong `foo.lib` format for static libraries when building for `*-pc-windows-gnu` since version [1.8.0](https://github.com/rust-lang/rust/commit/34b4e66736a0fb65235feadbb5178d42bd09ed67). [LD](https://github.com/bminor/binutils-gdb/blob/f4a220077b03af3a1f905b7dc6dc84c0a06d582f/ld/emultempl/pe.em#L2224-L2227) and [LLD](https://github.com/llvm/llvm-project/blob/0605f5fbe755326e3dbc8daa4fc34453b8c5ac0e/lld/MinGW/Driver.cpp#L140-L141) agree in that regard and only accept static libraries with `libfoo.a` format. So the only thing to break here is when somebody added a hack to rename created library to proper format (like [here](https://gitlab.gnome.org/GNOME/librsvg/-/commit/ad86ab8580c8779fc3eb2bee2422bb116919844e#d5b4de16d947214ec306bd57bed1bd23a939b5f9_197_194)).,HEART,2020-04-14T15:11:35Z,kleisauke,info@kleisauke.nl https://github.com/rust-lang/rust/pull/70946,MERGED,2020-04-09T09:12:04Z,2020-06-21T05:57:28Z,Add a lint to catch clashing `extern` fn declarations.,jumbatm,228a0ed7b0cef2fbfeb781acf6c23015ccc40ba2,14,Auto merge of #70946 - jumbatm:clashing-extern-decl r=nagisa Add a lint to catch clashing `extern` fn declarations. Closes #69390. Adds lint `clashing_extern_decl` to detect when within a single crate an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time and one function cannot possibly have two types a clashing extern declaration is almost certainly a mistake. This lint does not run between crates because a project may have dependencies which both rely on the same extern function but declare it in a different (but valid) way. For example they may both declare an opaque type for one or more of the arguments (which would end up distinct types) or use types that are valid conversions in the language the extern fn is defined in. In these cases we can't say that the clashing declaration is incorrect. r? @eddyb,THUMBS_UP,2020-06-19T09:31:56Z,mati865,NA https://github.com/rust-lang/rust/pull/70946,MERGED,2020-04-09T09:12:04Z,2020-06-21T05:57:28Z,Add a lint to catch clashing `extern` fn declarations.,jumbatm,228a0ed7b0cef2fbfeb781acf6c23015ccc40ba2,14,Auto merge of #70946 - jumbatm:clashing-extern-decl r=nagisa Add a lint to catch clashing `extern` fn declarations. Closes #69390. Adds lint `clashing_extern_decl` to detect when within a single crate an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time and one function cannot possibly have two types a clashing extern declaration is almost certainly a mistake. This lint does not run between crates because a project may have dependencies which both rely on the same extern function but declare it in a different (but valid) way. For example they may both declare an opaque type for one or more of the arguments (which would end up distinct types) or use types that are valid conversions in the language the extern fn is defined in. In these cases we can't say that the clashing declaration is incorrect. r? @eddyb,THUMBS_UP,2020-06-21T02:52:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70950,MERGED,2020-04-09T10:54:27Z,2020-04-30T22:13:24Z,extend NLL checker to understand `'empty` combined with universes,nikomatsakis,09f3c908bb4e65154d974a8a9d38e57f00d8ae04,20,"Rollup merge of #70950 - nikomatsakis:leak-check-nll-2 r=matthewjasper extend NLL checker to understand `'empty` combined with universes This PR extends the NLL region checker to understand `'empty` combined with universes. In particular it means that the NLL region checker no longer considers `exists { forall { R1: R2 } }` to be provable. This is work towards https://github.com/rust-lang/rust/issues/59490 but we're not all the way there. One thing in particular it does not address is error messages. The modifications to the NLL region inference code turned out to be simpler than expected. The main change is to require that if `R1: R2` then `universe(R1) <= universe(R2)`. This constraint follows from the region lattice (shown below) because we assume then that `R2` is ""at least"" `empty(Universe(R2))` and hence if `R1: R2` (i.e. `R1 >= R2` on the lattice) then `R1` must be in some universe that can name `'empty(Universe(R2))` which requires that `Universe(R1) <= Universe(R2)`. ``` static ----------+-----...------+ (greatest) | | | early-bound and | | free regions | | | | | scope regions | | | | | empty(root) placeholder(U1) | | / | | / placeholder(Un) empty(U1) -- / | / ... / | / empty(Un) -------- (smallest) ``` I also made what turned out to be a somewhat unrelated change to add a special region to represent `'empty(U0)` which we use (somewhat hackily) to indicate well-formedness checks in some parts of the compiler. This fixes #68550. I did some investigation into fixing the error message situation. That's a bit trickier: the existing ""nice region error"" code around placeholders relies on having better error tracing than NLL currently provides so that it knows (e.g.) that the constraint arose from applying a trait impl and things like that. I feel like I was hoping *not* to do such fine-grained tracing in NLL and it seems like we...largely...got away with that. I'm not sure yet if we'll have to add more tracing information or if there is some sort of alternative. It's worth pointing out though that I've not kind of shifted my opinion on whose job it should be to enforce lifetimes: I tend to think we ought to be moving back towards *something like* the leak-check (just not the one we *had*). If we took that approach it would actually resolve this aspect of the error message problem because we would be resolving 'higher-ranked errors' in the trait solver itself and hence we wouldn't have to thread as much causal information back to the region checker. I think it would also help us with removing the leak check while not breaking some of the existing crates out there. Regardless I think it's worth landing this change because it was relatively simple and it aligns the set of programs that NLL accepts with those that are accepted by the main region checker and hence should at least *help* us in migration (though I guess we still also have to resolve the existing crates that rely on leak check for coherence). r? @matthewjasper",ROCKET,2020-04-12T20:42:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2020-04-12T20:42:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2020-04-21T16:26:46Z,estebank,NA https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2020-05-12T03:29:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2021-01-24T06:56:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2021-02-21T03:51:43Z,camelid,NA https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2021-02-26T08:00:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2021-05-04T15:02:12Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,HEART,2021-05-04T15:02:16Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/70951,MERGED,2020-04-09T11:02:07Z,2021-02-20T21:38:59Z,Move the query engine out of rustc_middle,cjgillot,83b30a639d5abd1270ade35d9bd92271f5a5ba18,37,Auto merge of #70951 - cjgillot:anarchy r=oli-obk Move the query engine out of rustc_middle The handling of queries is moved to a trait `QueryEngine`. It replaces `query::Queries` in the `TyCtxt` allowing to move the query engine out of librustc_middle. There are 2 modes to access the query engine: through `TyCtxt` and dynamic dispatch or through a `QueryCtxt`. The `QueryCtxt` is required for everything touching the `OnDiskCache`. For now I put it in librustc_incremental which is very small. This may not be the best place. A significant part of the codegen time for librustc_middle is moved to the recipient crate. This PR may require a perf run. cc #65031 r? `@Zoxc`,ROCKET,2021-05-06T15:05:28Z,lqd,NA https://github.com/rust-lang/rust/pull/70956,CLOSED,2020-04-09T14:34:06Z,2020-04-12T14:28:12Z, librustc_middle: change query functions to accept impl Into<$K> type,marmeladema,NA,NA,NA,HEART,2020-04-09T14:39:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70956,CLOSED,2020-04-09T14:34:06Z,2020-04-12T14:28:12Z, librustc_middle: change query functions to accept impl Into<$K> type,marmeladema,NA,NA,NA,HEART,2020-04-09T16:51:02Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70958,MERGED,2020-04-09T14:58:00Z,2020-04-09T23:18:22Z,Disable try_reserve tests on Android,Amanieu,2c3147f018d8b6c05940b66e9f6098737277c882,3,Rollup merge of #70958 - Amanieu:android_try_reserve r=Mark-Simulacrum Disable try_reserve tests on Android Calling `realloc` with large sizes seems to be broken on older Android versions that use dlmalloc as the default allocator. This is not an issue for modern Android versions that use jemalloc. Fixes #55861,ROCKET,2020-04-09T15:56:09Z,badboy,NA https://github.com/rust-lang/rust/pull/70964,MERGED,2020-04-09T21:03:41Z,2020-04-10T16:13:32Z,rustc_session CLI lint parsing: mark a temporary hack as such,RalfJung,490bdc0e57a160fdcf07e70b8bb8d49085aa2640,1,Rollup merge of #70964 - RalfJung:mark-cli-lint-hack r=petrochenkov rustc_session CLI lint parsing: mark a temporary hack as such This code was added in https://github.com/rust-lang/rust/pull/70918 but it should not be necessary any more once `forbid` works as expected for in-code attributes. Cc @tobithiel @davidtwco,THUMBS_UP,2020-04-09T21:04:51Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/70986,MERGED,2020-04-10T11:31:08Z,2020-04-11T02:15:42Z,rustc_middle: return `LocalDefId` where possible in hir::map module,marmeladema,f3634503587a1f4e3b34f96452163595f242f911,24,Auto merge of #70986 - marmeladema:issue70853/librustc_middle-local-def-id r=eddyb rustc_middle: return `LocalDefId` where possible in hir::map module This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`: * opt_local_def_id_from_node_id * opt_local_def_id * body_owner_def_id * local_def_id_from_node_id * get_parent_id This is another step in the right direction for #70853 This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive we might want to wait for #70956 or #70961 (or some other form it) to land first.,ROCKET,2020-04-10T15:17:44Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/70989,MERGED,2020-04-10T14:06:29Z,2020-04-13T19:47:32Z, ci: run mir-opt tests on PR CI also as 32-bit (for `EMIT_MIR_FOR_EACH_BIT_WIDTH`).,eddyb,c58c53274401acdc739f177aa3e408241e2e52d8,6,Auto merge of #70989 - eddyb:mir-opt-32-pr-ci r=Mark-Simulacrum ci: run mir-opt tests on PR CI also as 32-bit (for `EMIT_MIR_FOR_EACH_BIT_WIDTH`). Background: #69916 and [`src/test/mir-opt/README.md`](https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md): > By default 32 bit and 64 bit targets use the same dump files which can be problematic in the presence of pointers in constants or other bit width dependent things. In that case you can add > > ``` > // EMIT_MIR_FOR_EACH_BIT_WIDTH > ``` > > to your test causing separate files to be generated for 32bit and 64bit systems. However if you change the output of such a test (intentionally or not) or if you add a test and it varies between 32-bit and 64-bit platforms you have to run this command (for a x64 linux host): `./x.py test --stage 1 --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu --bless src/test/mir-opt` Otherwise bors trying to merge the PR will fail since we test 32-bit targets there. But we don't on PR CI which means there's no way the PR author would know (unless they were burnt by this already and know what to look for). This PR resolves that by running `mir-opt` tests for ~~`i686-unknown-linux-gnu`~~ on PR CI. **EDIT**: switched to `armv5te-unknown-linux-gnueabi` to work around LLVM 7 crashes (see https://github.com/rust-lang/compiler-builtins/pull/311#issuecomment-612270089) found during testing. cc @rust-lang/wg-mir-opt @rust-lang/infra,HEART,2020-04-10T14:13:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/70996,MERGED,2020-04-10T17:02:38Z,2020-04-12T00:31:11Z,Add or_insert_with_key to Entry of HashMap/BTreeMap,ChaiTRex,03a724bd486da1d2691df3d8709c688a0704f1e0,2,Rollup merge of #70996 - ChaiTRex:master r=Amanieu Add or_insert_with_key to Entry of HashMap/BTreeMap Going along with `or_insert_with` `or_insert_with_key` provides the `Entry`'s key to the lambda avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time. This is useful when the initial value for a map entry is derived from the key. For example the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can given an argument to the lambda produce either the cached result or execute the lambda. --- I'm fairly new to Rust so any optimizations corrections to types better names better documentation or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable. As a somewhat-related note this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015 so if this pull request is accepted that should be closed.,THUMBS_UP,2020-04-10T17:20:30Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/70996,MERGED,2020-04-10T17:02:38Z,2020-04-12T00:31:11Z,Add or_insert_with_key to Entry of HashMap/BTreeMap,ChaiTRex,03a724bd486da1d2691df3d8709c688a0704f1e0,2,Rollup merge of #70996 - ChaiTRex:master r=Amanieu Add or_insert_with_key to Entry of HashMap/BTreeMap Going along with `or_insert_with` `or_insert_with_key` provides the `Entry`'s key to the lambda avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time. This is useful when the initial value for a map entry is derived from the key. For example the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can given an argument to the lambda produce either the cached result or execute the lambda. --- I'm fairly new to Rust so any optimizations corrections to types better names better documentation or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable. As a somewhat-related note this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015 so if this pull request is accepted that should be closed.,HOORAY,2020-04-15T05:12:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/70996,MERGED,2020-04-10T17:02:38Z,2020-04-12T00:31:11Z,Add or_insert_with_key to Entry of HashMap/BTreeMap,ChaiTRex,03a724bd486da1d2691df3d8709c688a0704f1e0,2,Rollup merge of #70996 - ChaiTRex:master r=Amanieu Add or_insert_with_key to Entry of HashMap/BTreeMap Going along with `or_insert_with` `or_insert_with_key` provides the `Entry`'s key to the lambda avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time. This is useful when the initial value for a map entry is derived from the key. For example the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can given an argument to the lambda produce either the cached result or execute the lambda. --- I'm fairly new to Rust so any optimizations corrections to types better names better documentation or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable. As a somewhat-related note this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015 so if this pull request is accepted that should be closed.,HOORAY,2020-04-17T17:00:04Z,evdokimovs,NA https://github.com/rust-lang/rust/pull/70996,MERGED,2020-04-10T17:02:38Z,2020-04-12T00:31:11Z,Add or_insert_with_key to Entry of HashMap/BTreeMap,ChaiTRex,03a724bd486da1d2691df3d8709c688a0704f1e0,2,Rollup merge of #70996 - ChaiTRex:master r=Amanieu Add or_insert_with_key to Entry of HashMap/BTreeMap Going along with `or_insert_with` `or_insert_with_key` provides the `Entry`'s key to the lambda avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time. This is useful when the initial value for a map entry is derived from the key. For example the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can given an argument to the lambda produce either the cached result or execute the lambda. --- I'm fairly new to Rust so any optimizations corrections to types better names better documentation or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable. As a somewhat-related note this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015 so if this pull request is accepted that should be closed.,THUMBS_UP,2020-04-21T19:37:28Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/70996,MERGED,2020-04-10T17:02:38Z,2020-04-12T00:31:11Z,Add or_insert_with_key to Entry of HashMap/BTreeMap,ChaiTRex,03a724bd486da1d2691df3d8709c688a0704f1e0,2,Rollup merge of #70996 - ChaiTRex:master r=Amanieu Add or_insert_with_key to Entry of HashMap/BTreeMap Going along with `or_insert_with` `or_insert_with_key` provides the `Entry`'s key to the lambda avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time. This is useful when the initial value for a map entry is derived from the key. For example the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can given an argument to the lambda produce either the cached result or execute the lambda. --- I'm fairly new to Rust so any optimizations corrections to types better names better documentation or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable. As a somewhat-related note this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015 so if this pull request is accepted that should be closed.,HOORAY,2020-07-30T18:32:50Z,TheLostLambda,b.j.rady@gmail.com https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-10T19:36:58Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-10T20:47:36Z,mati865,NA https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-11T03:51:23Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-11T22:32:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-12T12:54:00Z,ljedrz,NA https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-12T18:48:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-12T20:37:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-13T22:20:50Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-16T14:44:34Z,lnicola,NA https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-16T23:54:31Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-19T17:10:09Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/70999,CLOSED,2020-04-10T18:06:40Z,2020-04-30T11:51:28Z,"Support building with ""cargo"" directly instead of ""x.py"" for development purposes",luca-barbieri,NA,NA,NA,HOORAY,2020-04-21T10:36:07Z,taiki-e,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-10T23:01:58Z,mati865,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-10T23:12:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-10T23:51:47Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-11T00:40:35Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-11T07:15:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-11T11:11:20Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-12T00:57:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-12T09:16:33Z,darksv,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-12T20:39:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-14T01:43:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-14T16:23:20Z,cramertj,NA https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-15T03:31:08Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-15T05:55:22Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-04-15T12:46:18Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-05-29T14:37:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71003,CLOSED,2020-04-10T19:14:05Z,2020-04-17T21:50:35Z,[WIP] NRVO pass for acyclic CFGs,jonas-schievink,NA,NA,NA,HEART,2020-06-10T02:10:03Z,95th,NA https://github.com/rust-lang/rust/pull/71005,MERGED,2020-04-10T20:14:36Z,2020-04-23T17:40:15Z,Reading from the return place is fine,jonas-schievink,61fbc6a394e00778876a5776db27a5e58231f67b,13,Rollup merge of #71005 - jonas-schievink:no-place-like-return r=oli-obk Reading from the return place is fine Const eval thinks that reading from local `_0` is UB but it isn't. `_0` is just a normal local like any other and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it. I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003. r? @oli-obk,HEART,2020-04-10T20:32:53Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71005,MERGED,2020-04-10T20:14:36Z,2020-04-23T17:40:15Z,Reading from the return place is fine,jonas-schievink,61fbc6a394e00778876a5776db27a5e58231f67b,13,Rollup merge of #71005 - jonas-schievink:no-place-like-return r=oli-obk Reading from the return place is fine Const eval thinks that reading from local `_0` is UB but it isn't. `_0` is just a normal local like any other and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it. I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003. r? @oli-obk,HEART,2020-04-13T12:55:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71005,MERGED,2020-04-10T20:14:36Z,2020-04-23T17:40:15Z,Reading from the return place is fine,jonas-schievink,61fbc6a394e00778876a5776db27a5e58231f67b,13,Rollup merge of #71005 - jonas-schievink:no-place-like-return r=oli-obk Reading from the return place is fine Const eval thinks that reading from local `_0` is UB but it isn't. `_0` is just a normal local like any other and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it. I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003. r? @oli-obk,HEART,2020-04-25T16:40:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71005,MERGED,2020-04-10T20:14:36Z,2020-04-23T17:40:15Z,Reading from the return place is fine,jonas-schievink,61fbc6a394e00778876a5776db27a5e58231f67b,13,Rollup merge of #71005 - jonas-schievink:no-place-like-return r=oli-obk Reading from the return place is fine Const eval thinks that reading from local `_0` is UB but it isn't. `_0` is just a normal local like any other and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it. I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003. r? @oli-obk,HEART,2020-05-21T14:16:10Z,95th,NA https://github.com/rust-lang/rust/pull/71005,MERGED,2020-04-10T20:14:36Z,2020-04-23T17:40:15Z,Reading from the return place is fine,jonas-schievink,61fbc6a394e00778876a5776db27a5e58231f67b,13,Rollup merge of #71005 - jonas-schievink:no-place-like-return r=oli-obk Reading from the return place is fine Const eval thinks that reading from local `_0` is UB but it isn't. `_0` is just a normal local like any other and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it. I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003. r? @oli-obk,HEART,2020-05-29T14:41:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-10T20:31:42Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-10T20:31:52Z,lqd,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-10T20:39:36Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-11T01:29:08Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-18T01:48:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-21T03:14:37Z,byte1234,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-04-28T23:35:18Z,mati865,NA https://github.com/rust-lang/rust/pull/71006,MERGED,2020-04-10T20:28:03Z,2020-05-03T22:55:29Z,Use existing framework for backward dataflow analyses,ecstatic-morse,65b448273dd280401cd440a6740a7cd891525ba3,25,"Auto merge of #71006 - ecstatic-morse:dataflow-bidi r=ecstatic-morse Use existing framework for backward dataflow analyses This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API all newly implemented backward dataflow analyses get cursors/visitors `rustc_peek` tests and graphviz visualizations for free. In the near-term this makes it much easier to implement global dead-store elimination and I believe that this will enable even more MIR optimizations in the future. This PR makes many changes to the dataflow API since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes. - ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~ - `seek_{before after}` -> `seek_{before after}_primary_effect` (the unprefixed dataflow effect is now referred to as the ""primary"" effect instead of the ""after"" effect. The ""before"" effect remains the same although I considered changing it to the ""antecedent"" effect. In both backward and forward dataflow the ""before"" effect is applied prior to the ""primary"" effect. I feel very strongly that this is the correct choice as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis. - `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it. - `visit_{statement terminator}_exit` -> `visit_{statement terminator}_after_primary_effect` - `visit_{statement terminator}` -> `visit_{statement terminator}_before_primary_effect` Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:. In order to avoid computing the reverse CFG for forward dataflow analyses I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently. r? @eddyb (feel free to reassign) cc @rust-lang/wg-mir-opt",HOORAY,2020-05-07T12:30:48Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71007,MERGED,2020-04-10T22:09:45Z,2020-04-20T05:30:33Z,Deprecate the asm! macro in favor of llvm_asm!,Amanieu,9b2f8dbba39dd4167f22a7026674a585c3d907d8,11,Auto merge of #71007 - Amanieu:deprecate_asm r=Mark-Simulacrum Deprecate the asm! macro in favor of llvm_asm! Since we will be changing the syntax of `asm!` soon deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed. RFC: https://github.com/rust-lang/rfcs/pull/2843,ROCKET,2020-04-12T20:39:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71007,MERGED,2020-04-10T22:09:45Z,2020-04-20T05:30:33Z,Deprecate the asm! macro in favor of llvm_asm!,Amanieu,9b2f8dbba39dd4167f22a7026674a585c3d907d8,11,Auto merge of #71007 - Amanieu:deprecate_asm r=Mark-Simulacrum Deprecate the asm! macro in favor of llvm_asm! Since we will be changing the syntax of `asm!` soon deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed. RFC: https://github.com/rust-lang/rfcs/pull/2843,HEART,2020-04-16T06:47:03Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/71007,MERGED,2020-04-10T22:09:45Z,2020-04-20T05:30:33Z,Deprecate the asm! macro in favor of llvm_asm!,Amanieu,9b2f8dbba39dd4167f22a7026674a585c3d907d8,11,Auto merge of #71007 - Amanieu:deprecate_asm r=Mark-Simulacrum Deprecate the asm! macro in favor of llvm_asm! Since we will be changing the syntax of `asm!` soon deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed. RFC: https://github.com/rust-lang/rfcs/pull/2843,THUMBS_UP,2020-04-16T06:47:06Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/71007,MERGED,2020-04-10T22:09:45Z,2020-04-20T05:30:33Z,Deprecate the asm! macro in favor of llvm_asm!,Amanieu,9b2f8dbba39dd4167f22a7026674a585c3d907d8,11,Auto merge of #71007 - Amanieu:deprecate_asm r=Mark-Simulacrum Deprecate the asm! macro in favor of llvm_asm! Since we will be changing the syntax of `asm!` soon deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed. RFC: https://github.com/rust-lang/rfcs/pull/2843,ROCKET,2020-04-23T08:57:08Z,95th,NA https://github.com/rust-lang/rust/pull/71018,MERGED,2020-04-11T08:28:40Z,2020-05-02T03:39:41Z,handle ConstValue::ByRef in relate,lcnr,14c3ee906b4e88cb80b027fb7fd32c2fb53944bd,7,Rollup merge of #71018 - lcnr:custom-const-param r=eddyb handle ConstValue::ByRef in relate fixes #68615 r? @eddyb,HEART,2020-04-11T11:29:31Z,jplatte,NA https://github.com/rust-lang/rust/pull/71049,MERGED,2020-04-12T03:40:36Z,2020-04-17T15:03:40Z,Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it.,eddyb,8d67f576b56e8fc98a31123e5963f8d00e40611c,57,"Auto merge of #71049 - eddyb:const-err r=oli-obk Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it. By replicating the `ty::Error` approach to encoding ""an error has occurred"" all of the mechanisms that skip redundant/downstream errors are engaged and help out (see the reduction in test output). This PR also adds `ErrorHandled::Linted` for the lint case because using `ErrorHandled::Reported` *without* having emitted an error that is *guaranteed* to stop compilation is incorrect now. r? @oli-obk cc @rust-lang/wg-const-eval @varkor @yodaldevoid",HEART,2020-04-12T13:44:11Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/71049,MERGED,2020-04-12T03:40:36Z,2020-04-17T15:03:40Z,Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it.,eddyb,8d67f576b56e8fc98a31123e5963f8d00e40611c,57,"Auto merge of #71049 - eddyb:const-err r=oli-obk Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it. By replicating the `ty::Error` approach to encoding ""an error has occurred"" all of the mechanisms that skip redundant/downstream errors are engaged and help out (see the reduction in test output). This PR also adds `ErrorHandled::Linted` for the lint case because using `ErrorHandled::Reported` *without* having emitted an error that is *guaranteed* to stop compilation is incorrect now. r? @oli-obk cc @rust-lang/wg-const-eval @varkor @yodaldevoid",HEART,2020-04-12T18:11:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71049,MERGED,2020-04-12T03:40:36Z,2020-04-17T15:03:40Z,Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it.,eddyb,8d67f576b56e8fc98a31123e5963f8d00e40611c,57,"Auto merge of #71049 - eddyb:const-err r=oli-obk Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it. By replicating the `ty::Error` approach to encoding ""an error has occurred"" all of the mechanisms that skip redundant/downstream errors are engaged and help out (see the reduction in test output). This PR also adds `ErrorHandled::Linted` for the lint case because using `ErrorHandled::Reported` *without* having emitted an error that is *guaranteed* to stop compilation is incorrect now. r? @oli-obk cc @rust-lang/wg-const-eval @varkor @yodaldevoid",HEART,2020-04-13T02:52:36Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/71051,MERGED,2020-04-12T06:54:34Z,2020-04-13T23:03:27Z,Suggest .into() over try_into() when it would work,ryr3,f551d8a4104b68a6dcd204ee8f5ef53567be20b2,5,Rollup merge of #71051 - ryr3:fix_try_into r=estebank Suggest .into() over try_into() when it would work It would be better to suggest x.into() instead which is shorter cannot fail and doesn't require importing a trait. Tests have been added and made up to date. Fixes #70851,HEART,2020-04-12T09:22:55Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/71051,MERGED,2020-04-12T06:54:34Z,2020-04-13T23:03:27Z,Suggest .into() over try_into() when it would work,ryr3,f551d8a4104b68a6dcd204ee8f5ef53567be20b2,5,Rollup merge of #71051 - ryr3:fix_try_into r=estebank Suggest .into() over try_into() when it would work It would be better to suggest x.into() instead which is shorter cannot fail and doesn't require importing a trait. Tests have been added and made up to date. Fixes #70851,HEART,2020-04-24T05:36:06Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71051,MERGED,2020-04-12T06:54:34Z,2020-04-13T23:03:27Z,Suggest .into() over try_into() when it would work,ryr3,f551d8a4104b68a6dcd204ee8f5ef53567be20b2,5,Rollup merge of #71051 - ryr3:fix_try_into r=estebank Suggest .into() over try_into() when it would work It would be better to suggest x.into() instead which is shorter cannot fail and doesn't require importing a trait. Tests have been added and made up to date. Fixes #70851,HEART,2020-04-27T20:40:43Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/71063,MERGED,2020-04-12T15:06:33Z,2020-04-24T04:14:55Z,Document unsafety in core::{option hash},LeSeulArtichaut,9ff020e0dd73cd8a64711bf999f69970ec608718,3,Rollup merge of #71063 - LeSeulArtichaut:document-unsafe r=Mark-Simulacrum Document unsafety in core::{option hash} Helps with #66219. I think that the part that will need reviewing the most is the `hash/sip.rs` file. r? @LukasKalbertodt (or someone else from the libs team),HEART,2020-04-13T03:04:31Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/71064,MERGED,2020-04-12T15:39:08Z,2020-04-13T00:59:36Z,fix issue 69130,dwrensha,ebb1a8b6ff2475213a45cebed9583e3e6c7951c8,4,Rollup merge of #71064 - dwrensha:issue-69130 r=eddyb fix issue 69130 Closes #69130.,HEART,2020-04-13T15:29:34Z,estebank,NA https://github.com/rust-lang/rust/pull/71068,MERGED,2020-04-12T17:29:32Z,2020-04-24T04:14:54Z,Stabilize UNICODE_VERSION (feature unicode_version),pyfisch,c33deb9fda9558d4c46201cddbe2a89ede78082b,3,Rollup merge of #71068 - pyfisch:unicode-version-stable r=SimonSapin Stabilize UNICODE_VERSION (feature unicode_version) Tracking issue: #49726 r? @sfackler #71020 changed the definition of `UNICODE_VERSION` just yesterday from a struct to a tuple. Maybe you want to wait some more before stabilizing this constant on the other hand this is a very small and simple addition. CC @behnam @SimonSapin @Serentty,HEART,2020-09-25T01:07:58Z,behnam,NA https://github.com/rust-lang/rust/pull/71087,MERGED,2020-04-13T02:42:00Z,2020-04-13T23:03:24Z,Remove `FnCtxt::impl_self_ty`,JohnTitor,fd1b057004301be32a915ac8d924f7eb59ed1a9c,8,Rollup merge of #71087 - JohnTitor:impl-self-ty r=eddyb Remove `FnCtxt::impl_self_ty` Fixes #69489 r? @eddyb cc @Centril,HEART,2020-04-13T02:57:33Z,Centril,twingoow@gmail.com https://github.com/rust-lang/rust/pull/71087,MERGED,2020-04-13T02:42:00Z,2020-04-13T23:03:24Z,Remove `FnCtxt::impl_self_ty`,JohnTitor,fd1b057004301be32a915ac8d924f7eb59ed1a9c,8,Rollup merge of #71087 - JohnTitor:impl-self-ty r=eddyb Remove `FnCtxt::impl_self_ty` Fixes #69489 r? @eddyb cc @Centril,HEART,2020-04-13T04:00:17Z,panaman67,NA https://github.com/rust-lang/rust/pull/71092,MERGED,2020-04-13T12:46:24Z,2020-04-14T03:11:15Z,Remove some usage of `DUMMY_HIR_ID`,marmeladema,9de2a792fb8b88d25102f7c3e3309943e69e073b,9,Rollup merge of #71092 - marmeladema:dummy-hir-id-removal r=eddyb Remove some usage of `DUMMY_HIR_ID`,HEART,2020-04-13T16:59:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71092,MERGED,2020-04-13T12:46:24Z,2020-04-14T03:11:15Z,Remove some usage of `DUMMY_HIR_ID`,marmeladema,9de2a792fb8b88d25102f7c3e3309943e69e073b,9,Rollup merge of #71092 - marmeladema:dummy-hir-id-removal r=eddyb Remove some usage of `DUMMY_HIR_ID`,HEART,2020-04-13T21:54:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/71092,MERGED,2020-04-13T12:46:24Z,2020-04-14T03:11:15Z,Remove some usage of `DUMMY_HIR_ID`,marmeladema,9de2a792fb8b88d25102f7c3e3309943e69e073b,9,Rollup merge of #71092 - marmeladema:dummy-hir-id-removal r=eddyb Remove some usage of `DUMMY_HIR_ID`,HEART,2020-04-14T08:48:19Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71108,MERGED,2020-04-13T20:37:32Z,2020-05-04T09:40:29Z,On type mismatch involving associated type suggest constraint,estebank,d6823ba1666fa5f65e5fdd17cfc78ff227c092f2,35,Auto merge of #71108 - estebank:suggest-proj-type-mismatch-constraint r=oli-obk On type mismatch involving associated type suggest constraint When an associated type is found when a specific type was expected if possible provide a structured suggestion constraining the associated type in a bound. ``` error[E0271]: type mismatch resolving `::Y == i32` --> $DIR/associated-types-multiple-types-one-trait.rs:13:5 | LL | want_y(t); | ^^^^^^ expected `i32` found associated type ... LL | fn want_y>(t: &T) { } | ----- required by this bound in `want_y` | = note: expected type `i32` found associated type `::Y` help: consider constraining the associated type `::Y` to `i32` | LL | fn have_x_want_y>(t: &T) | ^^^^^^^^^ ``` ``` error[E0308]: mismatched types --> $DIR/trait-with-missing-associated-type-restriction.rs:12:9 | LL | qux(x.func()) | ^^^^^^^^ expected `usize` found associated type | = note: expected type `usize` found associated type `::A` help: consider constraining the associated type `::A` to `usize` | LL | fn foo(x: impl Trait) { | ^^^^^^^^^^ ``` Fix #71035. Related to #70908.,HEART,2020-04-14T17:02:07Z,manuels,NA https://github.com/rust-lang/rust/pull/71109,MERGED,2020-04-13T20:38:11Z,2020-04-14T03:11:11Z,allow const generics in const fn,lcnr,dd27462ea9c7c12e107272f699e940c76c4adb95,3,Rollup merge of #71109 - lcnr:generics_in_const_fn r=eddyb allow const generics in const fn This was explicitly forbidden before. As we were unable to think of a reason why this should still be the case this check has been removed. r? @eddyb cc @varkor @Centril,THUMBS_UP,2020-04-13T21:27:26Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/71109,MERGED,2020-04-13T20:38:11Z,2020-04-14T03:11:11Z,allow const generics in const fn,lcnr,dd27462ea9c7c12e107272f699e940c76c4adb95,3,Rollup merge of #71109 - lcnr:generics_in_const_fn r=eddyb allow const generics in const fn This was explicitly forbidden before. As we were unable to think of a reason why this should still be the case this check has been removed. r? @eddyb cc @varkor @Centril,THUMBS_UP,2020-04-14T01:22:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71116,MERGED,2020-04-14T07:49:10Z,2020-04-15T10:21:21Z,Entirely remove `DUMMY_HIR_ID`,marmeladema,7341cad3f312df5d735f2a8c3f3eb4480ed3a95d,15,Rollup merge of #71116 - marmeladema:dummy-hir-id-removal r=eddyb Entirely remove `DUMMY_HIR_ID` Some helpers functions have been introduced to deal with (buggy) cases where either a `NodeId` or a `DefId` do not have a corresponding `HirId`. Those cases are tracked in issue #71104.,THUMBS_UP,2020-04-14T15:04:46Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71116,MERGED,2020-04-14T07:49:10Z,2020-04-15T10:21:21Z,Entirely remove `DUMMY_HIR_ID`,marmeladema,7341cad3f312df5d735f2a8c3f3eb4480ed3a95d,15,Rollup merge of #71116 - marmeladema:dummy-hir-id-removal r=eddyb Entirely remove `DUMMY_HIR_ID` Some helpers functions have been introduced to deal with (buggy) cases where either a `NodeId` or a `DefId` do not have a corresponding `HirId`. Those cases are tracked in issue #71104.,HEART,2020-04-17T15:15:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71123,CLOSED,2020-04-14T13:22:53Z,2020-09-05T01:02:25Z,Upgrade Android SDK to API level 17,badboy,NA,NA,NA,THUMBS_UP,2020-07-17T20:34:57Z,awulkan,NA https://github.com/rust-lang/rust/pull/71140,MERGED,2020-04-14T17:05:22Z,2020-04-26T04:30:51Z,[breaking change] Disallow statics initializing themselves,oli-obk,b964451a72eb20283ee8f23541eae24474278158,4,Rollup merge of #71140 - oli-obk:static_cycle r=RalfJung [breaking change] Disallow statics initializing themselves fixes #71078 Self-initialization is unsound because it breaks privacy assumptions that unsafe code can make. In ```rust pub mod foo { #[derive(Debug Copy Clone)] pub struct Foo { x: () } } pub static FOO: foo::Foo = FOO; ``` unsafe could could expect that ony functions inside the `foo` module were able to create a value of type `Foo`.,THUMBS_UP,2020-05-01T13:46:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71141,MERGED,2020-04-14T17:33:14Z,2020-04-16T21:28:36Z,Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa,Duddino,e4ec7965ef364e3860cb8d24a877d3e420f015b9,4,Rollup merge of #71141 - Duddino:master r=estebank Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa Fixes #71089,HEART,2020-04-14T18:06:40Z,estebank,NA https://github.com/rust-lang/rust/pull/71141,MERGED,2020-04-14T17:33:14Z,2020-04-16T21:28:36Z,Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa,Duddino,e4ec7965ef364e3860cb8d24a877d3e420f015b9,4,Rollup merge of #71141 - Duddino:master r=estebank Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa Fixes #71089,HOORAY,2020-04-14T19:10:13Z,alvinhochun,NA https://github.com/rust-lang/rust/pull/71141,MERGED,2020-04-14T17:33:14Z,2020-04-16T21:28:36Z,Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa,Duddino,e4ec7965ef364e3860cb8d24a877d3e420f015b9,4,Rollup merge of #71141 - Duddino:master r=estebank Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa Fixes #71089,HOORAY,2020-04-23T11:53:32Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-14T19:29:32Z,mariadb-ashleynelson,ashley.nelson@mariadb.com https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-14T19:42:51Z,bahamat,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-14T19:46:39Z,jclulow,josh@sysmgr.org https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-14T20:07:28Z,sjorge,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-14T20:07:29Z,sjorge,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-14T20:08:12Z,wiedi,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-14T21:04:25Z,antoinereyt,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-14T21:09:07Z,plluksie,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-14T21:09:08Z,plluksie,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-14T21:09:09Z,plluksie,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-14T22:43:15Z,bytes-and-bits,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-15T00:13:33Z,JohnAZoidberg,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-15T00:13:34Z,JohnAZoidberg,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-15T00:13:35Z,JohnAZoidberg,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-15T10:17:18Z,dcarosone,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-15T10:17:19Z,dcarosone,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-15T15:53:53Z,papertigers,NA https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-16T02:25:36Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,ROCKET,2020-04-16T02:25:37Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-16T02:25:39Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,THUMBS_UP,2020-04-16T18:02:56Z,kraileth,kraileth@elderlinux.org https://github.com/rust-lang/rust/pull/71145,MERGED,2020-04-14T19:19:23Z,2020-04-16T02:10:33Z,Add illumos triple,pfmooney,905a92031371629d28f02bc5eb04415c627c4c9f,28,Rollup merge of #71145 - pfmooney:illumos-triple r=nagisa Add illumos triple This fixes rust-lang/rust#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking with subsequent additions by @pfmooney and @jclulow.,HOORAY,2020-04-16T19:16:07Z,bradjonesca,bradjonesca@gmail.com https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-14T19:44:50Z,mati865,NA https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-14T20:07:10Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-14T21:07:11Z,panaman67,NA https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-14T22:53:57Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-17T06:32:09Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-17T14:19:08Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-04-18T20:12:44Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/71147,MERGED,2020-04-14T19:32:50Z,2020-04-18T04:50:13Z,Update the minimum external LLVM to 8,cuviper,28742a1146f10a4f09369baad027a464acb7a766,30,Auto merge of #71147 - cuviper:min-llvm8 r=Mark-Simulacrum Update the minimum external LLVM to 8 LLVM 8 was released on March 20 2019 over a year ago.,THUMBS_UP,2020-06-05T07:41:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HOORAY,2020-04-18T16:22:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HEART,2020-04-27T16:51:47Z,varkor,NA https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HOORAY,2020-04-27T16:51:49Z,varkor,NA https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HOORAY,2020-04-29T21:03:07Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HOORAY,2020-05-19T22:03:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71154,CLOSED,2020-04-14T22:07:21Z,2020-07-05T15:09:11Z,Support const args in type dependent paths,lcnr,NA,NA,NA,HEART,2021-06-08T05:42:16Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-04-15T08:03:13Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-04-15T12:59:38Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-04-15T12:59:41Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-04-18T01:11:56Z,zhenghaoz,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-04-18T13:08:12Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-04-18T13:08:12Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-04-18T13:08:15Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-04-18T17:19:29Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-04-18T17:19:30Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-04-22T05:50:41Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_DOWN,2020-04-23T06:10:21Z,brson,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-05-04T21:52:03Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-05-04T21:52:04Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-05-04T21:52:09Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-05-13T19:34:18Z,louy2,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-05-13T19:34:21Z,louy2,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-05-30T03:51:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-06-26T09:25:35Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-06-26T09:25:38Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-08-14T18:08:40Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-08-14T18:08:41Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-08-14T18:08:44Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-08-14T18:08:46Z,jerielverissimo,jeriel.verissimo@protonmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-08-15T21:40:27Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-08-20T06:24:40Z,I60R,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-08-20T06:24:45Z,I60R,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-08-20T06:24:47Z,I60R,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-08-24T18:46:00Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-08-24T18:46:02Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-08-24T18:46:04Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-09-03T17:36:01Z,skondrashov,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-09-03T17:36:02Z,skondrashov,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-09-03T17:36:03Z,skondrashov,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-09-03T17:36:07Z,skondrashov,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-10-13T02:53:15Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-10-24T12:09:57Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-10-27T17:15:34Z,discosultan,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-10-28T10:30:12Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-10-29T21:27:08Z,yerke,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2020-10-29T21:27:09Z,yerke,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-10-29T21:27:10Z,yerke,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-10-29T21:27:11Z,yerke,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-11-07T08:03:11Z,TobiP64,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-11-08T02:38:06Z,lukechu10,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-11-11T15:02:54Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-12-06T15:56:12Z,xkr47,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2020-12-16T11:38:30Z,williamfhe,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2020-12-20T04:43:09Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2020-12-22T17:54:45Z,giggio,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2021-06-25T10:37:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2021-08-01T18:48:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HOORAY,2021-08-01T18:48:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2021-08-01T18:49:00Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,ROCKET,2021-08-01T18:49:00Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,THUMBS_UP,2021-10-01T19:17:33Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/71156,CLOSED,2020-04-14T23:01:30Z,2020-11-14T19:08:06Z,Implement destructuring assignment,fanzier,NA,NA,NA,HEART,2021-11-06T23:25:53Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71165,MERGED,2020-04-15T12:10:37Z,2020-05-03T12:06:22Z,`slice::fill`: use `T` instead of generic arg,lcnr,8cb8d9cfe26d9044efca0343067857229fd90b97,1,Rollup merge of #71165 - lcnr:patch-2 r=Amanieu `slice::fill`: use `T` instead of generic arg implements https://github.com/rust-lang/rust/issues/70758#issuecomment-613994427 As the discussion in #70758 has shifted I now use `T` instead of `&T`.,HEART,2020-05-06T09:45:32Z,bluss,NA https://github.com/rust-lang/rust/pull/71170,MERGED,2020-04-15T15:46:12Z,2020-04-21T12:11:36Z,Make Box respect self alignment,spastorino,45d050cde277b22a755847338f2acc2c7b834141,6,Auto merge of #71170 - spastorino:dyn-fnonce-alignment r=nikomatsakis Make Box respect self alignment Closes #68304 r? @eddyb @nikomatsakis,HEART,2020-04-17T08:47:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71172,MERGED,2020-04-15T16:23:20Z,2020-04-15T19:44:42Z,Update tool maintainers,pietroalbini,835428c35d785733e72bfbf32fc2f8fff3e50e63,1,Auto merge of #71172 - pietroalbini:update-tool-maintainers r=pietroalbini Update tool maintainers Centril is taking a break from the project.,HEART,2020-04-15T17:55:36Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/71174,MERGED,2020-04-15T18:11:04Z,2020-04-21T04:35:33Z,Check that main/start is not async,Nokel81,e3a514c44a7a896b210dcc59635452229703b9e6,9,Rollup merge of #71174 - Nokel81:fix-async-main-error r=petrochenkov Check that main/start is not async * Add new error code E0752 * Add span to hir::IsAsync::Yes * Emit an error if main or the start function is marked as async * Add two regression tests This PR fixes #68523.,HOORAY,2020-04-24T22:34:57Z,tmandry,NA https://github.com/rust-lang/rust/pull/71185,MERGED,2020-04-16T07:34:41Z,2020-05-09T20:56:25Z,Move tests from `test/run-fail` to UI,JohnTitor,1704dca270e86f5d33c84e1952897c2c33ad5256,165,Rollup merge of #71185 - JohnTitor:run-fail r=petrochenkov Move tests from `test/run-fail` to UI Fixes #65440 cc #65865 #65506 r? @nikomatsakis,HEART,2020-04-17T15:19:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71188,MERGED,2020-04-16T09:32:17Z,2020-04-19T16:43:19Z,"Fixed missing trait method suggests incorrect code (self parameter not named ""self""). ",Duddino,36791dabe8698e5faa78caa4ad043629875e5fbc,3,"Rollup merge of #71188 - Duddino:fix r=matthewjasper Fixed missing trait method suggests incorrect code (self parameter not named ""self""). fixes #71150",THUMBS_UP,2020-04-19T21:01:37Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/71188,MERGED,2020-04-16T09:32:17Z,2020-04-19T16:43:19Z,"Fixed missing trait method suggests incorrect code (self parameter not named ""self""). ",Duddino,36791dabe8698e5faa78caa4ad043629875e5fbc,3,"Rollup merge of #71188 - Duddino:fix r=matthewjasper Fixed missing trait method suggests incorrect code (self parameter not named ""self""). fixes #71150",THUMBS_UP,2020-04-20T18:41:28Z,estebank,NA https://github.com/rust-lang/rust/pull/71192,MERGED,2020-04-16T12:00:36Z,2020-06-01T15:42:50Z,Make TLS accesses explicit in MIR,oli-obk,d3cba254e464303a6495942f3a831c2bbd7f1768,31,Auto merge of #71192 - oli-obk:eager_alloc_id_canonicalization r=wesleywiser Make TLS accesses explicit in MIR r? @rust-lang/wg-mir-opt cc @RalfJung @vakaras for miri thread locals cc @bjorn3 for cranelift fixes #70685,HEART,2020-04-16T12:03:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71192,MERGED,2020-04-16T12:00:36Z,2020-06-01T15:42:50Z,Make TLS accesses explicit in MIR,oli-obk,d3cba254e464303a6495942f3a831c2bbd7f1768,31,Auto merge of #71192 - oli-obk:eager_alloc_id_canonicalization r=wesleywiser Make TLS accesses explicit in MIR r? @rust-lang/wg-mir-opt cc @RalfJung @vakaras for miri thread locals cc @bjorn3 for cranelift fixes #70685,HEART,2020-04-16T12:35:03Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/71192,MERGED,2020-04-16T12:00:36Z,2020-06-01T15:42:50Z,Make TLS accesses explicit in MIR,oli-obk,d3cba254e464303a6495942f3a831c2bbd7f1768,31,Auto merge of #71192 - oli-obk:eager_alloc_id_canonicalization r=wesleywiser Make TLS accesses explicit in MIR r? @rust-lang/wg-mir-opt cc @RalfJung @vakaras for miri thread locals cc @bjorn3 for cranelift fixes #70685,HEART,2020-04-16T12:43:04Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71192,MERGED,2020-04-16T12:00:36Z,2020-06-01T15:42:50Z,Make TLS accesses explicit in MIR,oli-obk,d3cba254e464303a6495942f3a831c2bbd7f1768,31,Auto merge of #71192 - oli-obk:eager_alloc_id_canonicalization r=wesleywiser Make TLS accesses explicit in MIR r? @rust-lang/wg-mir-opt cc @RalfJung @vakaras for miri thread locals cc @bjorn3 for cranelift fixes #70685,HEART,2020-05-31T20:54:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71197,MERGED,2020-04-16T13:05:24Z,2020-04-17T00:44:29Z,Don't use the HirId to NodeId map in MIR,ljedrz,aa0db0bb431b4172c58bdfdf9b748e0933e5bf06,1,Rollup merge of #71197 - ljedrz:unsafe_unused r=ecstatic-morse Don't use the HirId to NodeId map in MIR Another step towards not having to build a `HirId` to `NodeId` map other than for doc and RLS purposes. We are currently sorting `unsafe` blocks by `NodeId` in `check_unsafety`; change it to sorting by `Span` instead; this passes the tests but better ideas are welcome. In addition simplify the split between the used and unused `unsafe` blocks for readability and less sorting. cc https://github.com/rust-lang/rust/issues/50928,HOORAY,2020-04-16T13:22:37Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71208,CLOSED,2020-04-16T16:47:55Z,2020-04-28T11:47:10Z,Inline some serialize impls,ecstatic-morse,NA,NA,NA,HEART,2020-04-16T22:23:57Z,nnethercote,NA https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HOORAY,2020-04-16T20:32:06Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HEART,2020-04-16T20:56:12Z,repk,repk@triplefau.lt https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,ROCKET,2020-04-16T21:03:51Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HEART,2020-04-16T21:22:45Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HOORAY,2020-04-16T21:35:43Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HEART,2020-04-17T00:27:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/71215,MERGED,2020-04-16T19:39:54Z,2020-04-24T07:21:39Z,Simplify `local_def_id` and `as_local_hir_id`,marmeladema,5a59527516a917738c2e5f5d9f5e9a3533a6a5bc,119,Auto merge of #71215 - marmeladema:issue70853/librustc_middle-local-def-id-2 r=eddyb Simplify `local_def_id` and `as_local_hir_id` See #70853,HEART,2020-04-17T15:24:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71217,MERGED,2020-04-16T19:45:24Z,2020-04-29T13:59:55Z,Suggest `;` or assignment to drop borrows in tail exprs,estebank,d0ff2295e071a25568bb21f47287e7f76468591a,12,Rollup merge of #71217 - estebank:tail-borrow-sugg r=pnkfelix Suggest `;` or assignment to drop borrows in tail exprs Address the diagnostics part of #70844. ``` error[E0597]: `counter` does not live long enough --> $DIR/issue-54556-niconii.rs:22:20 | LL | if let Ok(_) = counter.lock() { } | ^^^^^^^------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... ... LL | } | - | | | `counter` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the destructor for type `std::result::Result ()>` | help: consider adding semicolon after the expression so its temporaries are dropped sooner before the local variables declared by the block are dropped | LL | if let Ok(_) = counter.lock() { }; | ^ ```,HOORAY,2020-04-28T19:03:57Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/71217,MERGED,2020-04-16T19:45:24Z,2020-04-29T13:59:55Z,Suggest `;` or assignment to drop borrows in tail exprs,estebank,d0ff2295e071a25568bb21f47287e7f76468591a,12,Rollup merge of #71217 - estebank:tail-borrow-sugg r=pnkfelix Suggest `;` or assignment to drop borrows in tail exprs Address the diagnostics part of #70844. ``` error[E0597]: `counter` does not live long enough --> $DIR/issue-54556-niconii.rs:22:20 | LL | if let Ok(_) = counter.lock() { } | ^^^^^^^------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... ... LL | } | - | | | `counter` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the destructor for type `std::result::Result ()>` | help: consider adding semicolon after the expression so its temporaries are dropped sooner before the local variables declared by the block are dropped | LL | if let Ok(_) = counter.lock() { }; | ^ ```,HOORAY,2020-05-07T11:07:19Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71220,MERGED,2020-04-16T20:33:03Z,2020-04-17T07:19:27Z,Dogfood or_patterns in the standard library,cuviper,28964b4ef2f165fdc667367bd9ba6b8d4cf81d34,10,Rollup merge of #71220 - cuviper:std_or_patterns r=Mark-Simulacrum Dogfood or_patterns in the standard library We can start using `or_patterns` in the standard library as a step toward stabilization. cc #54883 @Centril,THUMBS_UP,2020-08-07T04:47:05Z,95th,NA https://github.com/rust-lang/rust/pull/71220,MERGED,2020-04-16T20:33:03Z,2020-04-17T07:19:27Z,Dogfood or_patterns in the standard library,cuviper,28964b4ef2f165fdc667367bd9ba6b8d4cf81d34,10,Rollup merge of #71220 - cuviper:std_or_patterns r=Mark-Simulacrum Dogfood or_patterns in the standard library We can start using `or_patterns` in the standard library as a step toward stabilization. cc #54883 @Centril,HEART,2020-08-07T04:47:07Z,95th,NA https://github.com/rust-lang/rust/pull/71232,MERGED,2020-04-17T02:38:15Z,2020-04-20T08:39:33Z,ty/print: pretty-print constant aggregates (arrays tuples and ADTs).,eddyb,4ca5fd2d7b6b1d75b6cb8f679e8523fb3e7b19e2,21,Auto merge of #71232 - eddyb:print-const-adts r=oli-obk ty/print: pretty-print constant aggregates (arrays tuples and ADTs). Oddly enough we don't have any UI tests showing this off in types only `mir-opt` tests. However the pretty form should show up in the test output diff of #71018 if this PR is merged first.
Examples of before/after: |`Option`| |:-:| |`{transmute(0x01): std::option::Option}`| | :sparkles: ↓↓↓ :sparkles: | |`std::option::Option::::Some(true)`| | `RawVec` | |:-:| | `ByRef { alloc: Allocation { bytes: [4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] relocations: Relocations(SortedMap { data: [] }) undef_mask: UndefMask { blocks: [65535] len: Size { raw: 16 } } size: Size { raw: 16 } align: Align { pow2: 3 } mutability: Not extra: () } offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::`| | :sparkles: ↓↓↓ :sparkles: | |`alloc::raw_vec::RawVec:: { ptr: std::ptr::Unique:: { pointer: {0x4 as *const u32} _marker: std::marker::PhantomData:: } cap: 0usize alloc: std::alloc::Global }`|
This PR is a prerequisite for #61486 *sort of* in that we need to be able to pretty-print values in order to even consider how we might mangle them. We still don't have pretty-printing for constants of reference types @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
Each commit should be reviewed separately as I've fixed a couple deficiencies along the way. r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid,HEART,2020-04-17T09:45:57Z,varkor,NA https://github.com/rust-lang/rust/pull/71232,MERGED,2020-04-17T02:38:15Z,2020-04-20T08:39:33Z,ty/print: pretty-print constant aggregates (arrays tuples and ADTs).,eddyb,4ca5fd2d7b6b1d75b6cb8f679e8523fb3e7b19e2,21,Auto merge of #71232 - eddyb:print-const-adts r=oli-obk ty/print: pretty-print constant aggregates (arrays tuples and ADTs). Oddly enough we don't have any UI tests showing this off in types only `mir-opt` tests. However the pretty form should show up in the test output diff of #71018 if this PR is merged first.
Examples of before/after: |`Option`| |:-:| |`{transmute(0x01): std::option::Option}`| | :sparkles: ↓↓↓ :sparkles: | |`std::option::Option::::Some(true)`| | `RawVec` | |:-:| | `ByRef { alloc: Allocation { bytes: [4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] relocations: Relocations(SortedMap { data: [] }) undef_mask: UndefMask { blocks: [65535] len: Size { raw: 16 } } size: Size { raw: 16 } align: Align { pow2: 3 } mutability: Not extra: () } offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::`| | :sparkles: ↓↓↓ :sparkles: | |`alloc::raw_vec::RawVec:: { ptr: std::ptr::Unique:: { pointer: {0x4 as *const u32} _marker: std::marker::PhantomData:: } cap: 0usize alloc: std::alloc::Global }`|
This PR is a prerequisite for #61486 *sort of* in that we need to be able to pretty-print values in order to even consider how we might mangle them. We still don't have pretty-printing for constants of reference types @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
Each commit should be reviewed separately as I've fixed a couple deficiencies along the way. r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid,HEART,2020-04-17T10:08:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71232,MERGED,2020-04-17T02:38:15Z,2020-04-20T08:39:33Z,ty/print: pretty-print constant aggregates (arrays tuples and ADTs).,eddyb,4ca5fd2d7b6b1d75b6cb8f679e8523fb3e7b19e2,21,Auto merge of #71232 - eddyb:print-const-adts r=oli-obk ty/print: pretty-print constant aggregates (arrays tuples and ADTs). Oddly enough we don't have any UI tests showing this off in types only `mir-opt` tests. However the pretty form should show up in the test output diff of #71018 if this PR is merged first.
Examples of before/after: |`Option`| |:-:| |`{transmute(0x01): std::option::Option}`| | :sparkles: ↓↓↓ :sparkles: | |`std::option::Option::::Some(true)`| | `RawVec` | |:-:| | `ByRef { alloc: Allocation { bytes: [4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] relocations: Relocations(SortedMap { data: [] }) undef_mask: UndefMask { blocks: [65535] len: Size { raw: 16 } } size: Size { raw: 16 } align: Align { pow2: 3 } mutability: Not extra: () } offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::`| | :sparkles: ↓↓↓ :sparkles: | |`alloc::raw_vec::RawVec:: { ptr: std::ptr::Unique:: { pointer: {0x4 as *const u32} _marker: std::marker::PhantomData:: } cap: 0usize alloc: std::alloc::Global }`|
This PR is a prerequisite for #61486 *sort of* in that we need to be able to pretty-print values in order to even consider how we might mangle them. We still don't have pretty-printing for constants of reference types @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
Each commit should be reviewed separately as I've fixed a couple deficiencies along the way. r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid,HEART,2020-04-17T10:32:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/71232,MERGED,2020-04-17T02:38:15Z,2020-04-20T08:39:33Z,ty/print: pretty-print constant aggregates (arrays tuples and ADTs).,eddyb,4ca5fd2d7b6b1d75b6cb8f679e8523fb3e7b19e2,21,Auto merge of #71232 - eddyb:print-const-adts r=oli-obk ty/print: pretty-print constant aggregates (arrays tuples and ADTs). Oddly enough we don't have any UI tests showing this off in types only `mir-opt` tests. However the pretty form should show up in the test output diff of #71018 if this PR is merged first.
Examples of before/after: |`Option`| |:-:| |`{transmute(0x01): std::option::Option}`| | :sparkles: ↓↓↓ :sparkles: | |`std::option::Option::::Some(true)`| | `RawVec` | |:-:| | `ByRef { alloc: Allocation { bytes: [4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] relocations: Relocations(SortedMap { data: [] }) undef_mask: UndefMask { blocks: [65535] len: Size { raw: 16 } } size: Size { raw: 16 } align: Align { pow2: 3 } mutability: Not extra: () } offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::`| | :sparkles: ↓↓↓ :sparkles: | |`alloc::raw_vec::RawVec:: { ptr: std::ptr::Unique:: { pointer: {0x4 as *const u32} _marker: std::marker::PhantomData:: } cap: 0usize alloc: std::alloc::Global }`|
This PR is a prerequisite for #61486 *sort of* in that we need to be able to pretty-print values in order to even consider how we might mangle them. We still don't have pretty-printing for constants of reference types @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
Each commit should be reviewed separately as I've fixed a couple deficiencies along the way. r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid,HEART,2020-04-17T12:12:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71232,MERGED,2020-04-17T02:38:15Z,2020-04-20T08:39:33Z,ty/print: pretty-print constant aggregates (arrays tuples and ADTs).,eddyb,4ca5fd2d7b6b1d75b6cb8f679e8523fb3e7b19e2,21,Auto merge of #71232 - eddyb:print-const-adts r=oli-obk ty/print: pretty-print constant aggregates (arrays tuples and ADTs). Oddly enough we don't have any UI tests showing this off in types only `mir-opt` tests. However the pretty form should show up in the test output diff of #71018 if this PR is merged first.
Examples of before/after: |`Option`| |:-:| |`{transmute(0x01): std::option::Option}`| | :sparkles: ↓↓↓ :sparkles: | |`std::option::Option::::Some(true)`| | `RawVec` | |:-:| | `ByRef { alloc: Allocation { bytes: [4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] relocations: Relocations(SortedMap { data: [] }) undef_mask: UndefMask { blocks: [65535] len: Size { raw: 16 } } size: Size { raw: 16 } align: Align { pow2: 3 } mutability: Not extra: () } offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::`| | :sparkles: ↓↓↓ :sparkles: | |`alloc::raw_vec::RawVec:: { ptr: std::ptr::Unique:: { pointer: {0x4 as *const u32} _marker: std::marker::PhantomData:: } cap: 0usize alloc: std::alloc::Global }`|
This PR is a prerequisite for #61486 *sort of* in that we need to be able to pretty-print values in order to even consider how we might mangle them. We still don't have pretty-printing for constants of reference types @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
Each commit should be reviewed separately as I've fixed a couple deficiencies along the way. r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid,HEART,2020-04-17T13:26:09Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/71236,MERGED,2020-04-17T05:52:48Z,2020-04-22T06:57:58Z,Remove unused rustc_serialize::hex module,sinkuu,567e54fca5e864f95cd41ca05c113aa6b18d7006,17,Rollup merge of #71236 - sinkuu:cleanup r=nikomatsakis Remove unused rustc_serialize::hex module * Remove unused `rustc_serialize::hex` module * Cleanup `Cargo.toml`,HEART,2020-04-17T07:38:06Z,panaman67,NA https://github.com/rust-lang/rust/pull/71236,MERGED,2020-04-17T05:52:48Z,2020-04-22T06:57:58Z,Remove unused rustc_serialize::hex module,sinkuu,567e54fca5e864f95cd41ca05c113aa6b18d7006,17,Rollup merge of #71236 - sinkuu:cleanup r=nikomatsakis Remove unused rustc_serialize::hex module * Remove unused `rustc_serialize::hex` module * Cleanup `Cargo.toml`,HEART,2020-04-17T14:04:57Z,crlf0710,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-17T10:56:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-17T14:12:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-17T15:19:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-18T02:02:47Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-18T08:30:44Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-21T21:44:59Z,tema3210,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-30T02:25:32Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-04-30T04:48:36Z,najamelan,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-05-15T11:45:20Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-05-19T14:18:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-06-04T22:55:37Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-06-04T22:55:39Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-06-16T18:38:28Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-06-18T15:06:01Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-06-18T15:06:02Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-07-11T07:03:00Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-07-11T07:07:34Z,taiki-e,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-07-15T16:12:22Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-07-15T16:12:30Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-09-15T18:59:09Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-05T02:38:05Z,Congee,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-07T16:41:36Z,nlinker,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-08T14:11:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T15:01:29Z,pythondude325,me@gisch.dev https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T15:27:34Z,queer,null@amy.gg https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T15:40:51Z,tbelaire,theo.belaire@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-08T16:04:06Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T16:04:07Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T17:12:32Z,arj101,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T17:14:59Z,nanoqsh,nanoqsh@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-08T17:14:59Z,nanoqsh,nanoqsh@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T17:16:15Z,dempfi,mail@dempfi.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T18:26:34Z,Tom1380,zacktommy1118@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-08T20:19:21Z,mandreyel,mandreyel@protonmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-08T22:00:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-08T22:38:43Z,curlpipe,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-09T00:05:19Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-09T00:37:46Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-09T00:37:48Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-09T13:26:13Z,lovasoa,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-09T14:18:29Z,csrpi,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-10-09T14:18:30Z,csrpi,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-10T04:46:32Z,toddmath,tmatheson11186@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-16T23:46:49Z,rafaelalvessa,rafael@rafael.me.uk https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-27T12:14:34Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-10-30T16:35:47Z,hencrice,NA https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-11-13T01:42:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,HEART,2020-11-18T23:41:06Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/71237,MERGED,2020-04-17T08:22:18Z,2020-07-14T20:18:23Z,Add Ayu theme to rustdoc,Cldfire,03f565cdbfbdda55798f2c6e1fd0a96ac1c35c76,6,Rollup merge of #71237 - Cldfire:rustdoc-ayu-theme r=GuilliaumeGomez Add Ayu theme to rustdoc This is a port of a theme I maintain (https://github.com/Cldfire/ayu-rs) to the native rustdoc theme system. [Ayu](https://github.com/dempfi/ayu) (dark) is a richly-colored dark theme that many people enjoy using across a wide variety of environments. Corresponds to the Ayu theme in [mdBook](https://github.com/rust-lang/mdBook). Some screenshots: ![image](https://user-images.githubusercontent.com/13814214/79547087-6c935780-8061-11ea-8a33-38e9472e9fec.png) ![image](https://user-images.githubusercontent.com/13814214/79547150-8339ae80-8061-11ea-97be-9e13a8b275d7.png) ![image](https://user-images.githubusercontent.com/13814214/79547221-98164200-8061-11ea-9649-9b11ccbb33e3.png) ![image](https://user-images.githubusercontent.com/13814214/79547310-b419e380-8061-11ea-9965-d4f90b2280ab.png) ![image](https://user-images.githubusercontent.com/13814214/79547443-e7f50900-8061-11ea-8872-06d74010691e.png) Note that this pull request also makes some small code changes to allow for disabling theme stylesheets preventing the rules from all the different themes from conflicting with one another. The only stylesheet that is not disabled is `light.css`; the theming system (quite hackily) switches themes by changing the href on this stylesheet and so permanently disabling all the others works perfectly fine.,THUMBS_UP,2020-11-18T23:41:08Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/71243,MERGED,2020-04-17T12:09:35Z,2020-04-18T01:12:39Z,Account for use of `try!()` in 2018 edition and guide users in the right direction,Duddino,4b9eeca5c55f4064731a963674fa4056a9a50ce5,4,Rollup merge of #71243 - Duddino:Fix2 r=estebank Account for use of `try!()` in 2018 edition and guide users in the right direction fixes #71155,THUMBS_UP,2020-04-17T13:16:42Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/71243,MERGED,2020-04-17T12:09:35Z,2020-04-18T01:12:39Z,Account for use of `try!()` in 2018 edition and guide users in the right direction,Duddino,4b9eeca5c55f4064731a963674fa4056a9a50ce5,4,Rollup merge of #71243 - Duddino:Fix2 r=estebank Account for use of `try!()` in 2018 edition and guide users in the right direction fixes #71155,HEART,2020-04-17T17:19:41Z,estebank,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T15:54:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T15:54:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T15:54:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T15:55:34Z,adamgreig,adam@adamgreig.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T15:55:34Z,adamgreig,adam@adamgreig.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T15:58:05Z,teburd,thomas.burdick@intel.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T15:58:07Z,teburd,thomas.burdick@intel.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:05:21Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T16:05:22Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:05:34Z,Jan561,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T16:05:38Z,Jan561,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:08:11Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:28:50Z,yuttie,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:56:01Z,Folyd,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:58:31Z,Cldfire,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T16:58:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T17:00:32Z,extrawurst,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T18:22:33Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-17T18:22:34Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T18:25:54Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T19:20:56Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T19:34:11Z,PriteshJain,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-17T19:42:04Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-18T04:28:08Z,haileys,hailey@hailey.lol https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-18T05:52:50Z,lu-zero,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-18T07:27:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-18T07:27:51Z,tesuji,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-18T07:45:08Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-18T09:19:54Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-04-18T09:29:45Z,Yatekii,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-04-20T09:40:52Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-05-01T08:53:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-05-06T02:28:01Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-01T14:46:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-04T18:45:42Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-04T22:23:45Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-05T07:43:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-06-05T07:43:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-05T09:31:40Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2020-06-06T23:43:43Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,ROCKET,2020-06-06T23:43:43Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HEART,2020-06-06T23:43:45Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/71250,MERGED,2020-04-17T15:49:29Z,2020-04-20T22:16:40Z,Replace big JS dict with JSON parsing,GuillaumeGomez,2f06ac08e923a146134199cdb72c08b85a800203,2,Rollup merge of #71250 - GuillaumeGomez:use-json-instead-of-js r=kinnison Replace big JS dict with JSON parsing Part of #56545. @ollie27 suggested that using JSON instead of a JS dict might be faster so I decided to test it. And the results far exceeded whatever expectations I had... I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally: ```bash $ cargo doc --features doc --open ``` But I strongly recommend to do it with this PR. Some numbers: * Loading a page with the JSON search-index: less than 1 second * Loading a page with the JS search-index: crashed after 30 seconds I think the results are clear enough... r? @ollie27 cc @rust-lang/rustdoc,HOORAY,2021-01-22T21:46:24Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/71256,MERGED,2020-04-17T18:42:52Z,2020-04-23T03:44:48Z,Lint must_use on mem::replace,cuviper,10e47f5b7b58e1413ddc7cbb3164138c15e9684e,10,"Rollup merge of #71256 - cuviper:must_use_replace r=estebank Lint must_use on mem::replace This adds a hint on `mem::replace` ""if you don't need the old value you can just assign the new value directly"". This is in similar spirit to the `must_use` on `ManuallyDrop::take`.",THUMBS_UP,2020-04-22T16:29:27Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/71256,MERGED,2020-04-17T18:42:52Z,2020-04-23T03:44:48Z,Lint must_use on mem::replace,cuviper,10e47f5b7b58e1413ddc7cbb3164138c15e9684e,10,"Rollup merge of #71256 - cuviper:must_use_replace r=estebank Lint must_use on mem::replace This adds a hint on `mem::replace` ""if you don't need the old value you can just assign the new value directly"". This is in similar spirit to the `must_use` on `ManuallyDrop::take`.",THUMBS_UP,2021-03-04T21:56:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T06:56:20Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T08:07:21Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T08:15:24Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T08:30:16Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T09:23:30Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T12:27:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-18T17:35:22Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T01:05:41Z,kpp,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T02:01:29Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T02:16:07Z,TheDan64,ThaDan64@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T04:02:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T04:09:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T04:31:58Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T04:59:12Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T07:47:53Z,caelunshun,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T10:48:08Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-20T11:46:05Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2020-04-20T11:46:07Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-21T00:26:04Z,estebank,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-21T08:05:10Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-21T21:43:45Z,tema3210,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-21T22:50:38Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-23T01:07:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2020-04-23T01:07:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-23T05:45:28Z,brson,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2020-04-23T14:57:16Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-23T14:57:24Z,ActuallyaDeviloper,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-23T18:12:09Z,tux3,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-23T23:58:26Z,VictorGavrish,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2020-04-27T05:21:01Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-04-27T05:21:01Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2020-04-27T05:21:03Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2020-04-30T11:39:39Z,diwic,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-01T00:52:44Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-03T06:07:00Z,bstrie,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2020-05-03T12:27:08Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-06T21:21:52Z,charmander,~@charmander.me https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-06T23:48:34Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-07T07:09:55Z,t-rapp,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-13T00:56:39Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-13T21:54:35Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-13T23:24:05Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-14T10:54:21Z,dlight,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-15T15:31:41Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2020-05-19T09:15:29Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-05-31T21:40:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2020-06-02T11:08:43Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-06-04T19:34:58Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-06-04T21:17:51Z,yerke,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-06-05T07:42:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-06-05T08:20:37Z,AlphaHot,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-06-05T09:27:15Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2020-07-22T09:50:49Z,stanxii,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2020-10-21T14:46:16Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2021-01-22T07:11:50Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2021-01-22T07:11:51Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2021-01-22T07:11:52Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HOORAY,2021-10-31T00:29:48Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,HEART,2021-10-31T00:29:51Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/71269,MERGED,2020-04-18T01:47:23Z,2020-05-06T20:34:29Z,Define UB in float-to-int casts to saturate,Mark-Simulacrum,14d608f1d8a0b84da5f3bccecb3efb3d35f980dc,6,Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts r=nikic Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.,THUMBS_UP,2021-10-31T00:29:52Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/71275,CLOSED,2020-04-18T07:59:38Z,2020-04-18T11:53:43Z,Stable... It is possible to run Rust in this beauty ... || x 16,0lg0,NA,NA,NA,EYES,2020-04-18T08:01:19Z,0lg0,NA https://github.com/rust-lang/rust/pull/71289,MERGED,2020-04-18T16:20:12Z,2020-05-23T10:47:52Z,Allow using `Self::` in doc,xliiv,dd78839432e0ad3ab1d80bd5007d47358b76bfc3,2,Rollup merge of #71289 - xliiv:70802-intra-self r=GuillaumeGomez Allow using `Self::` in doc Closes #70802,HEART,2020-04-19T15:41:27Z,Cldfire,NA https://github.com/rust-lang/rust/pull/71292,MERGED,2020-04-18T16:59:29Z,2020-04-28T08:17:17Z,Convert more queries to use `LocalDefId`,marmeladema,fb5615a4771ea3d54256f969dc84d2dfd38d812c,43,Auto merge of #71292 - marmeladema:queries-local-def-id r=eddyb Convert more queries to use `LocalDefId` This PR is based on commits in https://github.com/rust-lang/rust/pull/71215 and should partially solve #70853,HEART,2020-04-18T17:17:10Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71292,MERGED,2020-04-18T16:59:29Z,2020-04-28T08:17:17Z,Convert more queries to use `LocalDefId`,marmeladema,fb5615a4771ea3d54256f969dc84d2dfd38d812c,43,Auto merge of #71292 - marmeladema:queries-local-def-id r=eddyb Convert more queries to use `LocalDefId` This PR is based on commits in https://github.com/rust-lang/rust/pull/71215 and should partially solve #70853,HEART,2020-04-18T18:13:28Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/71292,MERGED,2020-04-18T16:59:29Z,2020-04-28T08:17:17Z,Convert more queries to use `LocalDefId`,marmeladema,fb5615a4771ea3d54256f969dc84d2dfd38d812c,43,Auto merge of #71292 - marmeladema:queries-local-def-id r=eddyb Convert more queries to use `LocalDefId` This PR is based on commits in https://github.com/rust-lang/rust/pull/71215 and should partially solve #70853,HEART,2020-04-18T18:18:22Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71310,MERGED,2020-04-19T03:33:47Z,2020-04-19T23:02:12Z,Do not show DefId in diagnostics,JohnTitor,ab44c7701ef6214ba3ce89c0c1aac9baf4aa078a,3,Rollup merge of #71310 - JohnTitor:dont-did r=estebank Do not show DefId in diagnostics Fixes #71222 r? @estebank cc @eddyb,THUMBS_UP,2020-04-19T18:25:12Z,estebank,NA https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-04-19T12:03:28Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-04-20T10:43:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-05-02T17:56:29Z,Anne138,NA https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-05-06T03:08:23Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-05-06T17:59:46Z,lovasoa,NA https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-05-07T13:33:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2020-12-07T20:08:12Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2021-10-18T09:09:43Z,SadiinsoSnowfall,NA https://github.com/rust-lang/rust/pull/71314,MERGED,2020-04-19T09:05:30Z,2020-05-03T12:06:17Z,Implement RFC 2523 `#[cfg(version(..))]`,mibac138,ffe0a1c9fd6a75bb91955e50d639c619ecbcdd92,12,"Rollup merge of #71314 - mibac138:cfg-version r=petrochenkov Implement RFC 2523 `#[cfg(version(..))]` Hi! This is my first contribution to rust I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version(""1.44.0""))]` (note the quotes). Tracking issue: #64796",THUMBS_UP,2021-11-14T02:22:33Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/71321,MERGED,2020-04-19T12:43:15Z,2020-05-15T02:57:26Z,Use min_specialization in liballoc,matthewjasper,85f0da67ff31923955f7fb107fb097835bb3b6ff,7,Auto merge of #71321 - matthewjasper:alloc-min-spec r=sfackler Use min_specialization in liballoc - Remove a type parameter from `[A]RcFromIter`. - Remove an implementation of `[A]RcFromIter` that didn't actually specialize anything. - Remove unused implementation of `IsZero` for `Option<&mut T>`. - Change specializations of `[A]RcEqIdent` to use a marker trait version of `Eq`. - Remove `BTreeClone`. I couldn't find a way to make this work with `min_specialization`. - Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`. After this only libcore is the only standard library crate using `feature(specialization)`. cc #31844,HEART,2020-04-19T13:15:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71321,MERGED,2020-04-19T12:43:15Z,2020-05-15T02:57:26Z,Use min_specialization in liballoc,matthewjasper,85f0da67ff31923955f7fb107fb097835bb3b6ff,7,Auto merge of #71321 - matthewjasper:alloc-min-spec r=sfackler Use min_specialization in liballoc - Remove a type parameter from `[A]RcFromIter`. - Remove an implementation of `[A]RcFromIter` that didn't actually specialize anything. - Remove unused implementation of `IsZero` for `Option<&mut T>`. - Change specializations of `[A]RcEqIdent` to use a marker trait version of `Eq`. - Remove `BTreeClone`. I couldn't find a way to make this work with `min_specialization`. - Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`. After this only libcore is the only standard library crate using `feature(specialization)`. cc #31844,HEART,2020-05-14T16:39:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-04-19T12:53:01Z,varkor,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-04-19T14:34:26Z,cynecx,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-04-20T07:34:44Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-04-20T12:10:30Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-04-21T03:31:26Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-05-01T05:25:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-05-07T00:37:42Z,taiki-e,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-05-11T12:06:13Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-06-16T16:28:52Z,estebank,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-06-27T17:47:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-07-08T20:17:20Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-07-09T00:54:42Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,THUMBS_UP,2020-07-11T09:24:57Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-07-20T08:01:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-08-10T19:24:44Z,rahulnpadalkar,rahulnpadalkar@gmail.com https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,THUMBS_UP,2020-08-24T17:04:45Z,scrabsha,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-08-27T19:22:37Z,billyrieger,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-08-27T20:40:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-08-27T21:03:42Z,CreepySkeleton,creepy-skeleton@yandex.ru https://github.com/rust-lang/rust/pull/71322,MERGED,2020-04-19T12:46:41Z,2020-07-11T10:26:31Z,Accept tuple.0.0 as tuple indexing (take 2),petrochenkov,ec1e7e9dbc83e57da7809cfc32c01e881b42555b,13,Rollup merge of #71322 - petrochenkov:tuple00 r=nikomatsakis Accept tuple.0.0 as tuple indexing (take 2) If we expect something identifier-like when parsing a field name after `.` but encounter a float token we break that float token into parts similarly to how we break `&&` into `&` `&` or `<<` into `<` `<` etc. An alternative to https://github.com/rust-lang/rust/pull/70420.,HEART,2020-08-29T17:26:00Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/71346,MERGED,2020-04-20T10:40:13Z,2020-04-21T04:35:18Z,Do not build tools if user do not want them,mati865,9a0e7029062fb74a71a200b1f7ce0c212c9ea3a6,1,Rollup merge of #71346 - mati865:rustbuild-tools r=Mark-Simulacrum Do not build tools if user do not want them Fixes https://github.com/rust-lang/rust/issues/71307,HEART,2020-04-21T06:53:18Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/71374,MERGED,2020-04-21T07:40:38Z,2020-04-22T17:52:30Z,Alphabetize `-C` and `-Z` options,nnethercote,82e90d64266b8a4b53935d629786e69610b33f25,3,Auto merge of #71374 - nnethercote:alphabetize-C-and-Z-options r=petrochenkov Alphabetize `-C` and `-Z` options Because it will make it much easier to find options that way. r? @petrochenkov,HEART,2020-04-21T08:23:17Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/71374,MERGED,2020-04-21T07:40:38Z,2020-04-22T17:52:30Z,Alphabetize `-C` and `-Z` options,nnethercote,82e90d64266b8a4b53935d629786e69610b33f25,3,Auto merge of #71374 - nnethercote:alphabetize-C-and-Z-options r=petrochenkov Alphabetize `-C` and `-Z` options Because it will make it much easier to find options that way. r? @petrochenkov,HEART,2020-04-21T12:18:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71402,MERGED,2020-04-21T21:13:36Z,2020-04-22T03:49:58Z,Update cargo rls,ehuss,70f4f320b02cfd511c78389a6db1628285277410,3,"Auto merge of #71402 - ehuss:update-cargo r=ehuss Update cargo rls ## cargo 17 commits in ebda5065ee8a1e46801380abcbac21a25bc7e755..8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca 2020-04-16 14:28:43 +0000 to 2020-04-21 18:04:35 +0000 - Uplift windows gnu DLL import libraries. (rust-lang/cargo#8141) - Add windows-gnu CI and fix tests (rust-lang/cargo#8139) - Several updates to token/index handling. (rust-lang/cargo#7973) - Add `resolver` opt-in for new feature resolver. (rust-lang/cargo#8129) - Improve error message when running `cargo install .` (rust-lang/cargo#8137) - fix mem replace unused (rust-lang/cargo#8138) - Change `-Cembed-bitcode=no` use to `-Cbitcode-in-rlib=no`. (rust-lang/cargo#8134) - Refactor BuildContext (rust-lang/cargo#8068) - Rename allows_underscores to allows_dashes. (rust-lang/cargo#8135) - Fixed a needless borrow. (rust-lang/cargo#8130) - Add link to changelog in the Cargo book. (rust-lang/cargo#8126) - Fix target for doc test cross compilation (rust-lang/cargo#8094) - Add note about .cargo/config support. (rust-lang/cargo#8125) - Fix pdb uplift when executable has dashes. (rust-lang/cargo#8123) - Hint upgrading for future edition keys (rust-lang/cargo#8122) - Use some fs shorthand functions. (rust-lang/cargo#8124) - Update documentation to mention ""config.toml"" instead of ""config"" (rust-lang/cargo#8121) ## rls 1 commits in 2659cbf14bfb0929a16d7ce9b6858d0bb286ede7..7de2a1f299f8744ffe109139f9f1fdf28bfec909 2020-04-14 22:07:24 +0200 to 2020-04-19 22:41:55 +0000 - Update cargo (rust-lang-nursery/rls#1663)",HOORAY,2020-04-29T10:59:52Z,mati865,NA https://github.com/rust-lang/rust/pull/71402,MERGED,2020-04-21T21:13:36Z,2020-04-22T03:49:58Z,Update cargo rls,ehuss,70f4f320b02cfd511c78389a6db1628285277410,3,"Auto merge of #71402 - ehuss:update-cargo r=ehuss Update cargo rls ## cargo 17 commits in ebda5065ee8a1e46801380abcbac21a25bc7e755..8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca 2020-04-16 14:28:43 +0000 to 2020-04-21 18:04:35 +0000 - Uplift windows gnu DLL import libraries. (rust-lang/cargo#8141) - Add windows-gnu CI and fix tests (rust-lang/cargo#8139) - Several updates to token/index handling. (rust-lang/cargo#7973) - Add `resolver` opt-in for new feature resolver. (rust-lang/cargo#8129) - Improve error message when running `cargo install .` (rust-lang/cargo#8137) - fix mem replace unused (rust-lang/cargo#8138) - Change `-Cembed-bitcode=no` use to `-Cbitcode-in-rlib=no`. (rust-lang/cargo#8134) - Refactor BuildContext (rust-lang/cargo#8068) - Rename allows_underscores to allows_dashes. (rust-lang/cargo#8135) - Fixed a needless borrow. (rust-lang/cargo#8130) - Add link to changelog in the Cargo book. (rust-lang/cargo#8126) - Fix target for doc test cross compilation (rust-lang/cargo#8094) - Add note about .cargo/config support. (rust-lang/cargo#8125) - Fix pdb uplift when executable has dashes. (rust-lang/cargo#8123) - Hint upgrading for future edition keys (rust-lang/cargo#8122) - Use some fs shorthand functions. (rust-lang/cargo#8124) - Update documentation to mention ""config.toml"" instead of ""config"" (rust-lang/cargo#8121) ## rls 1 commits in 2659cbf14bfb0929a16d7ce9b6858d0bb286ede7..7de2a1f299f8744ffe109139f9f1fdf28bfec909 2020-04-14 22:07:24 +0200 to 2020-04-19 22:41:55 +0000 - Update cargo (rust-lang-nursery/rls#1663)",HOORAY,2020-05-05T08:06:30Z,twe4ked,NA https://github.com/rust-lang/rust/pull/71417,CLOSED,2020-04-22T06:19:43Z,2020-04-23T14:47:09Z,WIP: unsized_locals: refuse to emit incorrect LLVM IR,RalfJung,NA,NA,NA,THUMBS_UP,2020-04-22T14:07:56Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/71420,MERGED,2020-04-22T08:23:15Z,2020-06-20T06:53:20Z,Specialization is unsound,RalfJung,203305d09566e2924f893ed94845253da199eeab,123,"Rollup merge of #71420 - RalfJung:specialization-incomplete r=matthewjasper Specialization is unsound As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949 it might be a good idea to warn users of specialization that the feature they are using is unsound. I also expanded the ""incomplete feature"" warning to link the user to the tracking issue.",THUMBS_UP,2020-04-24T02:52:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71420,MERGED,2020-04-22T08:23:15Z,2020-06-20T06:53:20Z,Specialization is unsound,RalfJung,203305d09566e2924f893ed94845253da199eeab,123,"Rollup merge of #71420 - RalfJung:specialization-incomplete r=matthewjasper Specialization is unsound As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949 it might be a good idea to warn users of specialization that the feature they are using is unsound. I also expanded the ""incomplete feature"" warning to link the user to the tracking issue.",THUMBS_UP,2020-06-22T07:31:19Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/71420,MERGED,2020-04-22T08:23:15Z,2020-06-20T06:53:20Z,Specialization is unsound,RalfJung,203305d09566e2924f893ed94845253da199eeab,123,"Rollup merge of #71420 - RalfJung:specialization-incomplete r=matthewjasper Specialization is unsound As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949 it might be a good idea to warn users of specialization that the feature they are using is unsound. I also expanded the ""incomplete feature"" warning to link the user to the tracking issue.",THUMBS_UP,2020-06-24T00:04:32Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71420,MERGED,2020-04-22T08:23:15Z,2020-06-20T06:53:20Z,Specialization is unsound,RalfJung,203305d09566e2924f893ed94845253da199eeab,123,"Rollup merge of #71420 - RalfJung:specialization-incomplete r=matthewjasper Specialization is unsound As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949 it might be a good idea to warn users of specialization that the feature they are using is unsound. I also expanded the ""incomplete feature"" warning to link the user to the tracking issue.",THUMBS_UP,2020-06-25T03:46:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71420,MERGED,2020-04-22T08:23:15Z,2020-06-20T06:53:20Z,Specialization is unsound,RalfJung,203305d09566e2924f893ed94845253da199eeab,123,"Rollup merge of #71420 - RalfJung:specialization-incomplete r=matthewjasper Specialization is unsound As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949 it might be a good idea to warn users of specialization that the feature they are using is unsound. I also expanded the ""incomplete feature"" warning to link the user to the tracking issue.",THUMBS_UP,2020-06-25T05:43:05Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71421,MERGED,2020-04-22T09:46:42Z,2020-04-26T23:32:15Z,Add a function to turn Box into Box<[T]>,elichai,398d3eeca1f6cb84f91275826d66548c75e8fac0,4,Rollup merge of #71421 - elichai:2020-04-boxed-slice r=sfackler Add a function to turn Box into Box<[T]> Hi I think this is very useful as currently it's not possible in safe rust to do this without re-allocating. an alternative implementation of the same function can be: ```rust pub fn into_boxed_slice(boxed: Box) -> Box<[T]> { unsafe { let slice = slice::from_raw_parts_mut(Box::into_raw(boxed) 1); Box::from_raw(slice) } } ``` The only thing that makes me a little uncomfortable is this line : > The alignment of array types is greater or equal to the alignment of its element type from https://rust-lang.github.io/unsafe-code-guidelines/layout/arrays-and-slices.html But then I see: > The alignment of &T &mut T *const T and *mut T are the same and are at least the word size. > The alignment of &[T] is the word size. from https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html#representation So I do believe this is valid(FWIW it also passes in miri https://play.rust-lang.org/?gist=c002b99364ee6b29862aeb3565a91c19),THUMBS_UP,2020-04-30T22:17:40Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71480,MERGED,2020-04-23T18:19:13Z,2020-04-25T02:47:08Z,Improve PanicInfo examples readability,GuillaumeGomez,a23d8ec8a7525ae90e7625312cc2bee83dbb7493,1,Rollup merge of #71480 - GuillaumeGomez:panic-info-example r=Dylan-DPC Improve PanicInfo examples readability cc @Eijebong r? @Dylan-DPC,THUMBS_UP,2020-04-23T18:46:53Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/71481,MERGED,2020-04-23T18:20:34Z,2021-03-05T08:33:12Z,Inherit `#[stable(..)]` annotations in enum variants and fields from its item,estebank,a0d66b54fb3acc2125972b88ff543a2c04d14af5,17,Auto merge of #71481 - estebank:inherit-stability r=nikomatsakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for #65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.,THUMBS_DOWN,2021-02-22T14:24:39Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/71481,MERGED,2020-04-23T18:20:34Z,2021-03-05T08:33:12Z,Inherit `#[stable(..)]` annotations in enum variants and fields from its item,estebank,a0d66b54fb3acc2125972b88ff543a2c04d14af5,17,Auto merge of #71481 - estebank:inherit-stability r=nikomatsakis Inherit `#[stable(..)]` annotations in enum variants and fields from its item Lint changes for #65515. The stdlib will have to be updated once this lands in beta and that version is promoted in master.,THUMBS_UP,2021-02-22T14:25:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/71494,MERGED,2020-04-23T22:38:21Z,2020-04-25T14:15:19Z,Fix span of while (let) expressions after lowering,flip1995,6ded356d9c73648206bcb2c34744b76d6384c02e,3,Rollup merge of #71494 - flip1995:while_let_span r=petrochenkov Fix span of while (let) expressions after lowering Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy. While `if` `try` `for` and `await` expressions get the span of the original expression when desugared `while` loops got the span of the scrutinee which lead to weird code when building the suggestion that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108 I'm wondering if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly a new span with `self.mark_span_with_reason` should be used like it is done with `for` loops. There was some fallout but I think that is acceptable. If not I need some help to find out where this can be fixed.,THUMBS_UP,2020-04-24T06:29:37Z,alex-700,NA https://github.com/rust-lang/rust/pull/71494,MERGED,2020-04-23T22:38:21Z,2020-04-25T14:15:19Z,Fix span of while (let) expressions after lowering,flip1995,6ded356d9c73648206bcb2c34744b76d6384c02e,3,Rollup merge of #71494 - flip1995:while_let_span r=petrochenkov Fix span of while (let) expressions after lowering Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy. While `if` `try` `for` and `await` expressions get the span of the original expression when desugared `while` loops got the span of the scrutinee which lead to weird code when building the suggestion that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108 I'm wondering if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly a new span with `self.mark_span_with_reason` should be used like it is done with `for` loops. There was some fallout but I think that is acceptable. If not I need some help to find out where this can be fixed.,THUMBS_UP,2020-05-01T08:52:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71494,MERGED,2020-04-23T22:38:21Z,2020-04-25T14:15:19Z,Fix span of while (let) expressions after lowering,flip1995,6ded356d9c73648206bcb2c34744b76d6384c02e,3,Rollup merge of #71494 - flip1995:while_let_span r=petrochenkov Fix span of while (let) expressions after lowering Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy. While `if` `try` `for` and `await` expressions get the span of the original expression when desugared `while` loops got the span of the scrutinee which lead to weird code when building the suggestion that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108 I'm wondering if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly a new span with `self.mark_span_with_reason` should be used like it is done with `for` loops. There was some fallout but I think that is acceptable. If not I need some help to find out where this can be fixed.,THUMBS_UP,2020-05-01T15:35:44Z,estebank,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-24T06:40:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-24T09:00:30Z,crlf0710,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-24T09:00:41Z,crlf0710,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-24T13:07:19Z,est31,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-24T13:07:22Z,est31,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-24T14:32:41Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-24T14:32:42Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-24T17:18:03Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-24T17:18:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-04-25T07:35:07Z,retep998,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-25T07:35:08Z,retep998,NA https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-04-29T21:45:58Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HOORAY,2020-06-04T22:57:16Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/71497,CLOSED,2020-04-24T05:29:09Z,2020-11-21T14:35:04Z,[draft] Raw_dylib codegen,tinaun,NA,NA,NA,HEART,2020-06-04T22:57:26Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/71508,MERGED,2020-04-24T10:54:17Z,2020-05-09T20:56:14Z,Simplify the `tcx.alloc_map` API,oli-obk,8c0310d18caf38197f708a6e5a1c03b065373e6c,19,Rollup merge of #71508 - oli-obk:alloc_map_unlock r=RalfJung Simplify the `tcx.alloc_map` API This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private. r? @RalfJung,THUMBS_UP,2020-04-24T15:12:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71510,MERGED,2020-04-24T13:31:37Z,2020-05-06T14:39:31Z,Btreemap iter intertwined,ssomers,78a25cb10e28207398b16fecbcd92accb6a65e9e,2,Rollup merge of #71510 - ssomers:btreemap_iter_intertwined r=Mark-Simulacrum Btreemap iter intertwined 3 commits: 1. Introduced benchmarks for `BTreeMap::iter()`. Benchmarks named `iter_20` were of the whole iteration process so I renamed them. Also the benchmarks of `range` that I wrote earlier weren't very good. I included an (awkwardly named) one that compares `iter()` to `range(..)` on the same set because the contrast is surprising: ``` name ns/iter btree::map::range_unbounded_unbounded 28 176 btree::map::range_unbounded_vs_iter 89 369 ``` Both dig up the same pair of leaf edges. `range(..)` also checks that some keys are correctly ordered the only thing `iter()` does more is to copy the map's length. 2. Slightly refactoring the code to what I find more readable (not in chronological order of discovery) boosts performance: ``` >cargo-benchcmp.exe benchcmp a1 a2 --threshold 5 name a1 ns/iter a2 ns/iter diff ns/iter diff % speedup btree::map::find_rand_100 18 17 -1 -5.56% x 1.06 btree::map::first_and_last_10k 64 71 7 10.94% x 0.90 btree::map::iter_0 2 939 2 209 -730 -24.84% x 1.33 btree::map::iter_1 6 845 2 696 -4 149 -60.61% x 2.54 btree::map::iter_100 8 556 3 672 -4 884 -57.08% x 2.33 btree::map::iter_10k 9 292 5 884 -3 408 -36.68% x 1.58 btree::map::iter_1m 10 268 6 510 -3 758 -36.60% x 1.58 btree::map::iteration_mut_100000 478 575 453 050 -25 525 -5.33% x 1.06 btree::map::range_unbounded_unbounded 28 176 36 169 7 993 28.37% x 0.78 btree::map::range_unbounded_vs_iter 89 369 38 290 -51 079 -57.16% x 2.33 btree::set::clone_100_and_remove_all 4 801 4 245 -556 -11.58% x 1.13 btree::set::clone_10k_and_remove_all 529 450 496 030 -33 420 -6.31% x 1.07 ``` But you can tell from the `range_unbounded_*` lines that despite an unwarranted vengeful attack on the range_unbounded_unbounded benchmark this change still doesn't allow `iter()` to catch up with `range(..)`. 3. I guess that `range(..)` copes so well because it intertwines the leftmost and rightmost descend towards leaf edges doing the two root node accesses close together perhaps exploiting a CPU's internal pipelining? So the third commit distils a version of `range_search` (which we can't use directly because of the `Ord` bound) and we get another boost: ``` cargo-benchcmp.exe benchcmp a2 a3 --threshold 5 name a2 ns/iter a3 ns/iter diff ns/iter diff % speedup btree::map::first_and_last_100 40 43 3 7.50% x 0.93 btree::map::first_and_last_10k 71 64 -7 -9.86% x 1.11 btree::map::iter_0 2 209 1 719 -490 -22.18% x 1.29 btree::map::iter_1 2 696 2 205 -491 -18.21% x 1.22 btree::map::iter_100 3 672 2 943 -729 -19.85% x 1.25 btree::map::iter_10k 5 884 3 929 -1 955 -33.23% x 1.50 btree::map::iter_1m 6 510 5 532 -978 -15.02% x 1.18 btree::map::iteration_mut_100000 453 050 476 667 23 617 5.21% x 0.95 btree::map::range_included_excluded 405 075 371 297 -33 778 -8.34% x 1.09 btree::map::range_included_included 427 577 397 440 -30 137 -7.05% x 1.08 btree::map::range_unbounded_unbounded 36 169 28 175 -7 994 -22.10% x 1.28 btree::map::range_unbounded_vs_iter 38 290 30 838 -7 452 -19.46% x 1.24 ``` But I think this is just fake news from the microbenchmarking media. `iter()` is still trying to catch up with `range(..)`. And we can sure do without another function. So I would skip this 3rd commit. r? @Mark-Simulacrum,ROCKET,2020-04-25T09:05:57Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-24T19:48:04Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-24T20:10:01Z,lqd,NA https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-24T23:07:23Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-25T01:36:30Z,tesuji,NA https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-25T06:34:23Z,lnicola,NA https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-25T19:39:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-28T20:12:53Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71528,MERGED,2020-04-24T19:25:10Z,2020-04-30T03:04:39Z,Store LLVM bitcode in object files not compressed,alexcrichton,1357af3a55e24c7d28abb5eda258662f2307fadd,18,Auto merge of #71528 - alexcrichton:no-more-bitcode r=nnethercote Store LLVM bitcode in object files not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally note that an important consequence of this commit which is also one of its primary purposes is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR but the object code is later simply thrown away wastefully.,HOORAY,2020-04-30T21:45:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71530,CLOSED,2020-04-24T20:08:33Z,2020-04-26T14:49:01Z,Remove `ptr::Unique`,SimonSapin,NA,NA,NA,HEART,2020-04-24T20:23:40Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71530,CLOSED,2020-04-24T20:08:33Z,2020-04-26T14:49:01Z,Remove `ptr::Unique`,SimonSapin,NA,NA,NA,EYES,2020-04-24T22:36:56Z,Ixrec,NA https://github.com/rust-lang/rust/pull/71530,CLOSED,2020-04-24T20:08:33Z,2020-04-26T14:49:01Z,Remove `ptr::Unique`,SimonSapin,NA,NA,NA,HEART,2020-04-25T06:39:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/71530,CLOSED,2020-04-24T20:08:33Z,2020-04-26T14:49:01Z,Remove `ptr::Unique`,SimonSapin,NA,NA,NA,EYES,2020-04-25T17:34:18Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71530,CLOSED,2020-04-24T20:08:33Z,2020-04-26T14:49:01Z,Remove `ptr::Unique`,SimonSapin,NA,NA,NA,HEART,2021-06-27T02:39:22Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/71548,MERGED,2020-04-25T08:35:34Z,2020-04-25T20:53:53Z,Add missing Send and Sync impls for linked list Cursor and CursorMut.,crlf0710,82642d708fdd57a2072ef1d182558df5909380b0,1,Rollup merge of #71548 - crlf0710:cursor_bounds r=Amanieu Add missing Send and Sync impls for linked list Cursor and CursorMut. Someone pointed out these to me and i think it's indeed reasonable to add those impl. r? @Amanieu,THUMBS_UP,2020-04-25T08:37:36Z,mzji,NA https://github.com/rust-lang/rust/pull/71548,MERGED,2020-04-25T08:35:34Z,2020-04-25T20:53:53Z,Add missing Send and Sync impls for linked list Cursor and CursorMut.,crlf0710,82642d708fdd57a2072ef1d182558df5909380b0,1,Rollup merge of #71548 - crlf0710:cursor_bounds r=Amanieu Add missing Send and Sync impls for linked list Cursor and CursorMut. Someone pointed out these to me and i think it's indeed reasonable to add those impl. r? @Amanieu,ROCKET,2020-04-25T08:37:38Z,mzji,NA https://github.com/rust-lang/rust/pull/71569,MERGED,2020-04-26T03:40:24Z,2020-04-26T23:31:59Z,[miri] Throw UB if target size and data size don't match,samrat,b2a8a8a0f882728809a99841787cd8f745768f5f,2,"Rollup merge of #71569 - samrat:miri-ub-on-size-mismatch r=RalfJung [miri] Throw UB if target size and data size don't match Issue: https://github.com/rust-lang/miri/issues/1355 If an extern C function is defined as ``` extern ""C"" { fn malloc(size: u32) -> *mut std::ffi::c_void; } ``` on a 64-bit machine(ie. pointer sizes don't match) return undefined behaviour from Miri when [converting the argument into machine_usize](https://github.com/rust-lang/miri/blob/master/src/shims/foreign_items.rs#L200)",HEART,2020-04-27T18:55:53Z,kpp,NA https://github.com/rust-lang/rust/pull/71581,MERGED,2020-04-26T12:08:27Z,2020-05-08T23:46:32Z,Unify lints handling in rustdoc,GuillaumeGomez,807e8b80dcee480f0136654fa6c1dd847fa56c5e,2,Rollup merge of #71581 - GuillaumeGomez:unify-lints-handling r=kinnison Unify lints handling in rustdoc This is a small cleanup. The goal is to unify a bit things to make the reading simpler. r? @kinnison cc @rust-lang/rustdoc,HEART,2020-04-26T20:42:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/71592,CLOSED,2020-04-26T18:13:02Z,2020-07-26T13:12:57Z,Provide suggestions for `const` arguments missing braces,estebank,NA,NA,NA,HEART,2020-04-26T18:35:39Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71592,CLOSED,2020-04-26T18:13:02Z,2020-07-26T13:12:57Z,Provide suggestions for `const` arguments missing braces,estebank,NA,NA,NA,HEART,2020-04-27T09:21:38Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/71592,CLOSED,2020-04-26T18:13:02Z,2020-07-26T13:12:57Z,Provide suggestions for `const` arguments missing braces,estebank,NA,NA,NA,HEART,2020-04-29T16:47:04Z,varkor,NA https://github.com/rust-lang/rust/pull/71592,CLOSED,2020-04-26T18:13:02Z,2020-07-26T13:12:57Z,Provide suggestions for `const` arguments missing braces,estebank,NA,NA,NA,HEART,2020-05-26T16:10:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71592,CLOSED,2020-04-26T18:13:02Z,2020-07-26T13:12:57Z,Provide suggestions for `const` arguments missing braces,estebank,NA,NA,NA,HEART,2020-10-05T00:58:06Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/71599,MERGED,2020-04-27T01:12:56Z,2020-05-19T02:16:38Z,Support coercion between (FnDef | Closure) and (FnDef | Closure),ldm0,58e644736521b2916a6734aa225603c539bfeeed,14,Rollup merge of #71599 - ldm0:fnclo r=nikomatsakis Support coercion between (FnDef | Closure) and (FnDef | Closure) Fixes #46742 fixes #48109 Inject `Closure` into the `FnDef x FnDef` coercion special case which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible where closures should be **non-capturing**.,THUMBS_UP,2020-05-19T02:44:25Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/71599,MERGED,2020-04-27T01:12:56Z,2020-05-19T02:16:38Z,Support coercion between (FnDef | Closure) and (FnDef | Closure),ldm0,58e644736521b2916a6734aa225603c539bfeeed,14,Rollup merge of #71599 - ldm0:fnclo r=nikomatsakis Support coercion between (FnDef | Closure) and (FnDef | Closure) Fixes #46742 fixes #48109 Inject `Closure` into the `FnDef x FnDef` coercion special case which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible where closures should be **non-capturing**.,HOORAY,2020-05-19T02:44:27Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/71607,MERGED,2020-04-27T12:46:53Z,2020-05-22T11:25:20Z,clarify interaction of pin drop guarantee and panics,RalfJung,a819f428eddaff453011b75a543f7983fb93922f,1,Rollup merge of #71607 - RalfJung:pin-drop-panic r=nikomatsakis clarify interaction of pin drop guarantee and panics Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/232 @Diggsey would this have helped?,THUMBS_UP,2020-04-27T18:01:31Z,Diggsey,NA https://github.com/rust-lang/rust/pull/71645,MERGED,2020-04-28T16:02:01Z,2020-05-04T04:53:59Z,Direct contributors to try stage 0 rustdoc first,ecstatic-morse,ccc123a1e2a525c81173d432a9b53e90498a6ab3,1,Rollup merge of #71645 - ecstatic-morse:readme-build-doc r=Mark-Simulacrum Direct contributors to try stage 0 rustdoc first After #71458 `./x.py doc --stage 0 src/libstd` is (empirically) able to build the standard library docs using the `rustdoc` packaged with the bootstrap compiler. This means that new contributors don't need to build the compiler to locally inspect small documentation fixes. This was a roadblock for me when I first started contributing to rust and something that still regularly annoys people. We should recommend that contributors give bootstrap `rustdoc` a try before building the whole compiler.,HEART,2020-04-28T16:08:33Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71645,MERGED,2020-04-28T16:02:01Z,2020-05-04T04:53:59Z,Direct contributors to try stage 0 rustdoc first,ecstatic-morse,ccc123a1e2a525c81173d432a9b53e90498a6ab3,1,Rollup merge of #71645 - ecstatic-morse:readme-build-doc r=Mark-Simulacrum Direct contributors to try stage 0 rustdoc first After #71458 `./x.py doc --stage 0 src/libstd` is (empirically) able to build the standard library docs using the `rustdoc` packaged with the bootstrap compiler. This means that new contributors don't need to build the compiler to locally inspect small documentation fixes. This was a roadblock for me when I first started contributing to rust and something that still regularly annoys people. We should recommend that contributors give bootstrap `rustdoc` a try before building the whole compiler.,HEART,2020-04-28T16:13:45Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71645,MERGED,2020-04-28T16:02:01Z,2020-05-04T04:53:59Z,Direct contributors to try stage 0 rustdoc first,ecstatic-morse,ccc123a1e2a525c81173d432a9b53e90498a6ab3,1,Rollup merge of #71645 - ecstatic-morse:readme-build-doc r=Mark-Simulacrum Direct contributors to try stage 0 rustdoc first After #71458 `./x.py doc --stage 0 src/libstd` is (empirically) able to build the standard library docs using the `rustdoc` packaged with the bootstrap compiler. This means that new contributors don't need to build the compiler to locally inspect small documentation fixes. This was a roadblock for me when I first started contributing to rust and something that still regularly annoys people. We should recommend that contributors give bootstrap `rustdoc` a try before building the whole compiler.,HEART,2020-04-28T16:14:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/71648,CLOSED,2020-04-28T16:37:30Z,2020-09-11T16:26:30Z,Remove (useless) argument of entry_fn query,marmeladema,NA,NA,NA,HEART,2020-04-28T16:54:10Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71648,CLOSED,2020-04-28T16:37:30Z,2020-09-11T16:26:30Z,Remove (useless) argument of entry_fn query,marmeladema,NA,NA,NA,THUMBS_UP,2020-04-28T16:58:43Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71660,MERGED,2020-04-29T02:13:43Z,2020-06-22T16:39:28Z,impl PartialEq> for &[A] &mut [A],sollyucko,8da1dd0215791b0e20ea25d1bf706757d1f3da81,2,Rollup merge of #71660 - sollyucko:master r=dtolnay impl PartialEq> for &[A] &mut [A] https://github.com/rust-lang/rfcs/issues/2917,HOORAY,2020-06-16T23:48:33Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71660,MERGED,2020-04-29T02:13:43Z,2020-06-22T16:39:28Z,impl PartialEq> for &[A] &mut [A],sollyucko,8da1dd0215791b0e20ea25d1bf706757d1f3da81,2,Rollup merge of #71660 - sollyucko:master r=dtolnay impl PartialEq> for &[A] &mut [A] https://github.com/rust-lang/rfcs/issues/2917,HOORAY,2020-08-25T07:35:46Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71663,MERGED,2020-04-29T10:06:54Z,2020-05-03T19:46:34Z,Fix exceeding bitshifts not emitting for assoc. consts (properly this time I swear!),jumbatm,5b1729030ab99a32f5c68f8964f42f37810116a3,6,Rollup merge of #71663 - jumbatm:caller-handles-validation-error r=RalfJung Fix exceeding bitshifts not emitting for assoc. consts (properly this time I swear!) Fixes #69021 and fixes #71353. As described in https://github.com/rust-lang/rust/issues/71353#issuecomment-617901923 this PR: - adds a variant of `try_validation!` called `try_validation_pat!` that allows specific failures to be turned into validation failures (but returns the rest unchanged) and - allows `InvalidProgram` to be returned out of validation r? @RalfJung,LAUGH,2020-04-30T00:56:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71674,MERGED,2020-04-29T14:15:45Z,2020-04-29T20:32:49Z,Update Clippy,flip1995,c50bd7e40284839bd0a094be67c48528aeecacb0,1,Auto merge of #71674 - flip1995:clippyup r=Dylan-DPC Update Clippy Fixes #71608,THUMBS_UP,2020-04-29T14:53:03Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/71678,MERGED,2020-04-29T15:17:59Z,2020-04-29T23:47:30Z,Add an index page for nightly rustc docs.,ehuss,3286436e32a92c77f7b88cb329ae4195afdcffc6,1,Rollup merge of #71678 - ehuss:rustc-doc-index r=Mark-Simulacrum Add an index page for nightly rustc docs. This adds an `index.html` page at the root of the nightly-rustc docs so that the URL https://doc.rust-lang.org/nightly/nightly-rustc/ should have a landing page that lists all the crates.,HEART,2020-04-29T17:50:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71688,MERGED,2020-04-29T17:37:31Z,2020-05-01T01:38:00Z,Allow `Downcast` projections unconditionally in const-checking,ecstatic-morse,a8e0511b3288f40570812fe6524e0d80cf630f2c,9,Rollup merge of #71688 - ecstatic-morse:const-downcast r=oli-obk Allow `Downcast` projections unconditionally in const-checking `ProjectionElem::Downcast` sounds scary but it's really just the projection we use to access a particular enum variant. They usually appear in the lowering of a `match` statement so they have been associated with control flow in const-checking but they don't do any control flow by themselves. We already have a HIR pass that looks for `if` and `match` (even ones that have 1 or fewer reachable branches). That pass is double-checked by a MIR pass that looks for `SwitchInt`s and `FakeRead`s for match scrutinees. In my opinion there's no need to look for `Downcast` as well. r? @oli-obk,THUMBS_UP,2020-05-06T07:14:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71697,MERGED,2020-04-29T23:10:17Z,2020-05-04T20:44:18Z,Added MIR constant propagation of Scalars into function call arguments,felix91gr,d47ec165826acd95893c5e76e506be3d22188c99,3,Rollup merge of #71697 - felix91gr:new_prop_into_fn_call r=wesleywiser Added MIR constant propagation of Scalars into function call arguments Now for the function call arguments! Caveats: 1. It's only being enabled at `mir-opt-2` or higher because currently codegen gives performance regressions with this optimization. 2. Only propagates Scalars. Tuples and references (references are `Indirect` right??) are not being propagated into as of this PR. 3. Maybe more tests would be nice? 4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments. r? @wesleywiser,HOORAY,2020-04-30T00:50:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71697,MERGED,2020-04-29T23:10:17Z,2020-05-04T20:44:18Z,Added MIR constant propagation of Scalars into function call arguments,felix91gr,d47ec165826acd95893c5e76e506be3d22188c99,3,Rollup merge of #71697 - felix91gr:new_prop_into_fn_call r=wesleywiser Added MIR constant propagation of Scalars into function call arguments Now for the function call arguments! Caveats: 1. It's only being enabled at `mir-opt-2` or higher because currently codegen gives performance regressions with this optimization. 2. Only propagates Scalars. Tuples and references (references are `Indirect` right??) are not being propagated into as of this PR. 3. Maybe more tests would be nice? 4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments. r? @wesleywiser,HOORAY,2020-04-30T07:20:07Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71697,MERGED,2020-04-29T23:10:17Z,2020-05-04T20:44:18Z,Added MIR constant propagation of Scalars into function call arguments,felix91gr,d47ec165826acd95893c5e76e506be3d22188c99,3,Rollup merge of #71697 - felix91gr:new_prop_into_fn_call r=wesleywiser Added MIR constant propagation of Scalars into function call arguments Now for the function call arguments! Caveats: 1. It's only being enabled at `mir-opt-2` or higher because currently codegen gives performance regressions with this optimization. 2. Only propagates Scalars. Tuples and references (references are `Indirect` right??) are not being propagated into as of this PR. 3. Maybe more tests would be nice? 4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments. r? @wesleywiser,HOORAY,2020-04-30T09:46:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71697,MERGED,2020-04-29T23:10:17Z,2020-05-04T20:44:18Z,Added MIR constant propagation of Scalars into function call arguments,felix91gr,d47ec165826acd95893c5e76e506be3d22188c99,3,Rollup merge of #71697 - felix91gr:new_prop_into_fn_call r=wesleywiser Added MIR constant propagation of Scalars into function call arguments Now for the function call arguments! Caveats: 1. It's only being enabled at `mir-opt-2` or higher because currently codegen gives performance regressions with this optimization. 2. Only propagates Scalars. Tuples and references (references are `Indirect` right??) are not being propagated into as of this PR. 3. Maybe more tests would be nice? 4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments. r? @wesleywiser,HOORAY,2020-04-30T22:52:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/71697,MERGED,2020-04-29T23:10:17Z,2020-05-04T20:44:18Z,Added MIR constant propagation of Scalars into function call arguments,felix91gr,d47ec165826acd95893c5e76e506be3d22188c99,3,Rollup merge of #71697 - felix91gr:new_prop_into_fn_call r=wesleywiser Added MIR constant propagation of Scalars into function call arguments Now for the function call arguments! Caveats: 1. It's only being enabled at `mir-opt-2` or higher because currently codegen gives performance regressions with this optimization. 2. Only propagates Scalars. Tuples and references (references are `Indirect` right??) are not being propagated into as of this PR. 3. Maybe more tests would be nice? 4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments. r? @wesleywiser,HOORAY,2020-05-07T12:27:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71724,MERGED,2020-04-30T22:57:49Z,2020-05-16T03:56:31Z,Doc alias improvements,GuillaumeGomez,154db50d86432e7ddc7f292b161f9a52237a129e,9,Rollup merge of #71724 - GuillaumeGomez:doc-alias-improvements r=ollie27 Doc alias improvements After [this message](https://github.com/rust-lang/rust/issues/50146#issuecomment-496601755) I realized that the **doc alias**. So this PR does the followings: * Align the alias discovery on items added into the search-index. It brings a few nice advantages: * Instead of cloning the data between the two (in rustdoc source code) we now have the search-index one and aliases which reference to the first one. So we go from one big map containing a lot of duplicated data to just integers... * In the front-end (main.js) I improved the code around aliases to allow them to go through the same transformation as other items when we show the search results. * Improve the search tester in order to perform multiple requests into one file (I think it's better in this case than having a file for each case considering how many there are...) * I also had to add the new function inside the tester (`handleAliases`) Once this PR is merged I intend to finally stabilize this feature. r? @ollie27 cc @rust-lang/rustdoc,THUMBS_UP,2020-06-17T09:54:40Z,Ania85Bi,NA https://github.com/rust-lang/rust/pull/71726,MERGED,2020-05-01T00:33:06Z,2020-05-03T19:46:29Z,Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability,ldm0,44e678bf9e4846bf9ac9c2f30fa9533ead51ad13,10,Rollup merge of #71726 - ldm0:ref2ptr r=oli-obk Suggest deref when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability Fixes #71676 1. Implement dereference suggestion when coercing `ty::Ref` to `ty::RawPtr` with arbitrary mutability. 2. Extract the dereference steps into `deref_steps()` which removes all the `use` and `pub` noise introduced by last PR #71540 and makes the code more readable. 3. Use the `remove_prefix()` closure which makes the prefix removal more readable. 4. Introduce `Applicability` as a return value of `check_ref` to suggest `Applicability::Unspecified` suggestion. **Special**: I found it is not possible to genereate `Applicability::MachineApplicable` suggestion for situation like this: ```rust use std::ops::Deref; use std::ops::DerefMut; struct Bar(u8); struct Foo(Bar); struct Emm(Foo); impl Deref for Bar{ type Target = u8; fn deref(&self) -> &Self::Target { &self.0 } } impl Deref for Foo { type Target = Bar; fn deref(&self) -> &Self::Target { &self.0 } } impl Deref for Emm { type Target = Foo; fn deref(&self) -> &Self::Target { &self.0 } } impl DerefMut for Bar{ fn deref_mut(&mut self) -> &mut Self::Target { &mut self.0 } } impl DerefMut for Foo { fn deref_mut(&mut self) -> &mut Self::Target { &mut self.0 } } impl DerefMut for Emm { fn deref_mut(&mut self) -> &mut Self::Target { &mut self.0 } } fn main() { let a = Emm(Foo(Bar(0))); let _: *mut u8 = &a; //~ ERROR mismatched types } ``` We may suggest `&mut ***a` here but the `a` is not declared as mutable variable. And also when processing HIR it's not possible to check if `a` is declared as a mutable variable (currently we do borrow checking with MIR). So we cannot ensure that suggestion when coercing immutable reference to mutable pointer is always machine applicable. Therefore I added a `Applicability` return value in `check_ref()`. And move the `immutable reference -> mutable pointer` situation into a sperate test file without `run-rustfix`. (It seems that `run-rustfix` will also adopt `Applicability::Unspecified` suggestion which is strange),HEART,2020-05-01T02:35:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/71737,MERGED,2020-05-01T09:27:28Z,2020-05-12T14:00:03Z,Miri: run liballoc tests with threads,RalfJung,2a1581c50c5af46a7760f0ce9fe93d5b52818940,4,Rollup merge of #71737 - RalfJung:miri-test-threads r=shepmaster Miri: run liballoc tests with threads Miri now supports threads so we can run these tests. :),HEART,2020-05-01T10:21:50Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71738,MERGED,2020-05-01T09:34:15Z,2020-05-02T13:19:30Z,remove AllocId generalization of Pointer,RalfJung,6616e2ca27b945773cdb685a4726a1b03ff4afbb,5,"Rollup merge of #71738 - RalfJung:pointer-no-alloc-id r=oli-obk remove AllocId generalization of Pointer This was only needed for the ""snapshot"" machinery which is gone. r? @oli-obk",HEART,2020-05-01T09:39:29Z,oli-obk,NA https://github.com/rust-lang/rust/pull/71741,MERGED,2020-05-01T10:11:12Z,2020-05-14T16:07:04Z,Pointer printing: do not print 0 offset,RalfJung,7893d9a8d6065b7899f92c45f543528a0c099a7d,18,Rollup merge of #71741 - RalfJung:pointer-print r=oli-obk Pointer printing: do not print 0 offset r? @eddyb Cc @oli-obk,HEART,2020-05-01T10:41:51Z,oli-obk,NA https://github.com/rust-lang/rust/pull/71747,MERGED,2020-05-01T12:32:03Z,2020-05-01T21:08:31Z,Remove deadcode in eval_mir_constant_to_operand,spastorino,d83d8be65d92f00f816f5ae55731c6416b2ff849,1,Rollup merge of #71747 - spastorino:safety-scheme-around-consts-cleanup r=oli-obk Remove deadcode in eval_mir_constant_to_operand r? @oli-obk @RalfJung,HEART,2020-05-01T12:53:25Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71747,MERGED,2020-05-01T12:32:03Z,2020-05-01T21:08:31Z,Remove deadcode in eval_mir_constant_to_operand,spastorino,d83d8be65d92f00f816f5ae55731c6416b2ff849,1,Rollup merge of #71747 - spastorino:safety-scheme-around-consts-cleanup r=oli-obk Remove deadcode in eval_mir_constant_to_operand r? @oli-obk @RalfJung,HEART,2020-05-01T20:32:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/71754,MERGED,2020-05-01T15:32:51Z,2020-05-04T17:25:32Z,Don't copy bytecode files into the incr. comp. cache.,alexcrichton,649b6323cd20d4a454264798c189107fd1eda33f,7,Auto merge of #71754 - alexcrichton:no-bitcode-in-cache r=nnethercote Don't copy bytecode files into the incr. comp. cache. It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary which means that type is no longer necessary which allowed several places in the code to become simpler. This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires so I'm re-sending this patch!,HEART,2020-05-01T20:31:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/71754,MERGED,2020-05-01T15:32:51Z,2020-05-04T17:25:32Z,Don't copy bytecode files into the incr. comp. cache.,alexcrichton,649b6323cd20d4a454264798c189107fd1eda33f,7,Auto merge of #71754 - alexcrichton:no-bitcode-in-cache r=nnethercote Don't copy bytecode files into the incr. comp. cache. It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary which means that type is no longer necessary which allowed several places in the code to become simpler. This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires so I'm re-sending this patch!,HEART,2020-05-03T02:30:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71754,MERGED,2020-05-01T15:32:51Z,2020-05-04T17:25:32Z,Don't copy bytecode files into the incr. comp. cache.,alexcrichton,649b6323cd20d4a454264798c189107fd1eda33f,7,Auto merge of #71754 - alexcrichton:no-bitcode-in-cache r=nnethercote Don't copy bytecode files into the incr. comp. cache. It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary which means that type is no longer necessary which allowed several places in the code to become simpler. This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires so I'm re-sending this patch!,HEART,2020-05-03T08:29:18Z,mati865,NA https://github.com/rust-lang/rust/pull/71754,MERGED,2020-05-01T15:32:51Z,2020-05-04T17:25:32Z,Don't copy bytecode files into the incr. comp. cache.,alexcrichton,649b6323cd20d4a454264798c189107fd1eda33f,7,Auto merge of #71754 - alexcrichton:no-bitcode-in-cache r=nnethercote Don't copy bytecode files into the incr. comp. cache. It's no longer necessary now that bitcode is embedded into object files. This change meant that `WorkProductFileKind::Bytecode` is no longer necessary which means that type is no longer necessary which allowed several places in the code to become simpler. This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires so I'm re-sending this patch!,HEART,2020-05-04T21:34:11Z,nnethercote,NA https://github.com/rust-lang/rust/pull/71780,MERGED,2020-05-01T23:28:53Z,2021-03-19T03:28:51Z,Implement String::remove_matches,jcotton42,eb95acea8aeaeef834214eaffb15d64095fe9271,3,Auto merge of #71780 - jcotton42:string_remove_matches r=joshtriplett Implement String::remove_matches Closes #50206. I lifted the function help from `@frewsxcv's` original PR (#50015) hope they don't mind. I'm also wondering whether it would be useful for `remove_matches` to collect up the removed substrings into a `Vec` and return them right now they're just overwritten by the copy and lost.,HOORAY,2021-03-25T06:34:06Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/71780,MERGED,2020-05-01T23:28:53Z,2021-03-19T03:28:51Z,Implement String::remove_matches,jcotton42,eb95acea8aeaeef834214eaffb15d64095fe9271,3,Auto merge of #71780 - jcotton42:string_remove_matches r=joshtriplett Implement String::remove_matches Closes #50206. I lifted the function help from `@frewsxcv's` original PR (#50015) hope they don't mind. I'm also wondering whether it would be useful for `remove_matches` to collect up the removed substrings into a `Vec` and return them right now they're just overwritten by the copy and lost.,HOORAY,2021-03-26T15:47:59Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/71783,MERGED,2020-05-02T01:24:58Z,2020-05-08T04:39:59Z,Detect errors caused by `async` block in 2015 edition,estebank,f3691ac066630c09e1f9fc3eac8b06448f065108,7,Rollup merge of #71783 - estebank:async-block-2015 r=tmandry Detect errors caused by `async` block in 2015 edition Fix #67204.,HOORAY,2020-05-05T22:41:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/71783,MERGED,2020-05-02T01:24:58Z,2020-05-08T04:39:59Z,Detect errors caused by `async` block in 2015 edition,estebank,f3691ac066630c09e1f9fc3eac8b06448f065108,7,Rollup merge of #71783 - estebank:async-block-2015 r=tmandry Detect errors caused by `async` block in 2015 edition Fix #67204.,HEART,2020-07-06T22:40:57Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/71796,MERGED,2020-05-02T10:20:33Z,2020-06-07T00:05:48Z,de-promote Duration::from_secs,RalfJung,64c27f9fee17cf666c31dfdc6161ad0666311cdd,1,Rollup merge of #71796 - RalfJung:from-secs r=nikomatsakis de-promote Duration::from_secs In https://github.com/rust-lang/rust/pull/67531 we removed the `rustc_promotable` attribute from a bunch of `Duration` methods but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value` `INT::max_value` * `std::mem::size_of` `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null` `std::ptr::null_mut` * `RawWaker::new` `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs` which is what this PR does. https://github.com/rust-lang/rust/pull/67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code so I consider it likely the same will be true here but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and https://github.com/rust-lang/const-eval/issues/19 for some of the concerns around promoting function calls.,HEART,2020-05-02T10:37:16Z,oli-obk,NA https://github.com/rust-lang/rust/pull/71796,MERGED,2020-05-02T10:20:33Z,2020-06-07T00:05:48Z,de-promote Duration::from_secs,RalfJung,64c27f9fee17cf666c31dfdc6161ad0666311cdd,1,Rollup merge of #71796 - RalfJung:from-secs r=nikomatsakis de-promote Duration::from_secs In https://github.com/rust-lang/rust/pull/67531 we removed the `rustc_promotable` attribute from a bunch of `Duration` methods but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value` `INT::max_value` * `std::mem::size_of` `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null` `std::ptr::null_mut` * `RawWaker::new` `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs` which is what this PR does. https://github.com/rust-lang/rust/pull/67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code so I consider it likely the same will be true here but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and https://github.com/rust-lang/const-eval/issues/19 for some of the concerns around promoting function calls.,LAUGH,2020-05-02T11:22:24Z,kennytm,NA https://github.com/rust-lang/rust/pull/71796,MERGED,2020-05-02T10:20:33Z,2020-06-07T00:05:48Z,de-promote Duration::from_secs,RalfJung,64c27f9fee17cf666c31dfdc6161ad0666311cdd,1,Rollup merge of #71796 - RalfJung:from-secs r=nikomatsakis de-promote Duration::from_secs In https://github.com/rust-lang/rust/pull/67531 we removed the `rustc_promotable` attribute from a bunch of `Duration` methods but not from `Duration::from_secs`. This makes the current list of promotable functions the following (courtesy of @ecstatic-morse): * `INT::min_value` `INT::max_value` * `std::mem::size_of` `std::mem::align_of` * `RangeInclusive::new` (backing `x..=y`) * `std::ptr::null` `std::ptr::null_mut` * `RawWaker::new` `RawWakerVTable::new` ??? * `Duration::from_secs` I feel like the last one stands out a bit here -- the rest are all very core language primitives and `RawWaker` has a strong motivation for getting a `'static` vtable. But a `&'static Duration`? That seems unlikely. So I propose we no longer promote calls to `Duration::from_secs` which is what this PR does. https://github.com/rust-lang/rust/pull/67531 saw zero regressions and I am not aware of anyone complaining that this broke their (non-cratered) code so I consider it likely the same will be true here but of course we'd do a crater run. See [this document](https://github.com/rust-lang/const-eval/blob/master/promotion.md) for some more background on promotion and https://github.com/rust-lang/const-eval/issues/19 for some of the concerns around promoting function calls.,LAUGH,2020-05-03T02:28:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71804,MERGED,2020-05-02T13:33:02Z,2020-05-30T03:25:46Z,linker: Support `-static-pie` and `-static -shared`,petrochenkov,7aef3a0f6f8c86cc90b4a6b209b7167d2ac34e12,3,"Rollup merge of #71804 - petrochenkov:static-pie r=cuviper linker: Support `-static-pie` and `-static -shared` This PR adds support for passing linker arguments for creating statically linked position-independent executables and ""statically linked"" shared libraries. Therefore it incorporates the majority of https://github.com/rust-lang/rust/pull/70740 except for the linker rerun hack and actually flipping the ""`static-pie` is supported"" switch for musl targets.",THUMBS_UP,2020-05-09T23:00:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71804,MERGED,2020-05-02T13:33:02Z,2020-05-30T03:25:46Z,linker: Support `-static-pie` and `-static -shared`,petrochenkov,7aef3a0f6f8c86cc90b4a6b209b7167d2ac34e12,3,"Rollup merge of #71804 - petrochenkov:static-pie r=cuviper linker: Support `-static-pie` and `-static -shared` This PR adds support for passing linker arguments for creating statically linked position-independent executables and ""statically linked"" shared libraries. Therefore it incorporates the majority of https://github.com/rust-lang/rust/pull/70740 except for the linker rerun hack and actually flipping the ""`static-pie` is supported"" switch for musl targets.",THUMBS_UP,2020-05-23T00:52:44Z,smaeul,samuel@sholland.org https://github.com/rust-lang/rust/pull/71816,CLOSED,2020-05-02T23:50:32Z,2020-06-06T13:14:42Z,Add a `MustUse` trait to complement `#[must_use]`,jonas-schievink,NA,NA,NA,HEART,2020-05-04T16:33:22Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71821,CLOSED,2020-05-03T01:26:41Z,2020-06-19T17:16:04Z,Implement Default for MaybeUninit,upsuper,NA,NA,NA,THUMBS_UP,2021-01-11T22:46:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71821,CLOSED,2020-05-03T01:26:41Z,2020-06-19T17:16:04Z,Implement Default for MaybeUninit,upsuper,NA,NA,NA,THUMBS_UP,2021-02-14T21:37:10Z,jgarvin,joseph.h.garvin@gmail.com https://github.com/rust-lang/rust/pull/71823,CLOSED,2020-05-03T02:56:27Z,2020-08-07T01:02:32Z,Adding constant-propagation tests,felix91gr,NA,NA,NA,HEART,2020-05-03T17:37:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-05-03T04:35:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-05-03T09:41:34Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-05-05T19:02:50Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-06-12T06:27:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-06-15T15:01:10Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/71824,MERGED,2020-05-03T04:22:42Z,2020-06-15T11:40:37Z,Check for live drops in constants after drop elaboration,ecstatic-morse,5c61a8dc34c3e2fc6d7f02cb288c350f0233f944,16,"Rollup merge of #71824 - ecstatic-morse:const-check-post-drop-elab r=oli-obk Check for live drops in constants after drop elaboration Resolves #66753. This PR splits the MIR ""optimization"" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk",HOORAY,2020-06-17T17:40:56Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71825,MERGED,2020-05-03T05:31:08Z,2020-05-11T00:12:34Z,add codegen option strip,contrun,aeb473803d1ead96fab51224ba3e366f44883423,5,Auto merge of #71825 - contrun:cg-option-strip r=petrochenkov add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker PtxLinker MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.,THUMBS_UP,2020-05-03T09:28:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71825,MERGED,2020-05-03T05:31:08Z,2020-05-11T00:12:34Z,add codegen option strip,contrun,aeb473803d1ead96fab51224ba3e366f44883423,5,Auto merge of #71825 - contrun:cg-option-strip r=petrochenkov add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker PtxLinker MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.,THUMBS_UP,2020-05-05T05:27:42Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/71825,MERGED,2020-05-03T05:31:08Z,2020-05-11T00:12:34Z,add codegen option strip,contrun,aeb473803d1ead96fab51224ba3e366f44883423,5,Auto merge of #71825 - contrun:cg-option-strip r=petrochenkov add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker PtxLinker MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.,THUMBS_UP,2020-05-05T11:11:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/71825,MERGED,2020-05-03T05:31:08Z,2020-05-11T00:12:34Z,add codegen option strip,contrun,aeb473803d1ead96fab51224ba3e366f44883423,5,Auto merge of #71825 - contrun:cg-option-strip r=petrochenkov add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker PtxLinker MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.,THUMBS_UP,2020-05-09T16:28:04Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/71825,MERGED,2020-05-03T05:31:08Z,2020-05-11T00:12:34Z,add codegen option strip,contrun,aeb473803d1ead96fab51224ba3e366f44883423,5,Auto merge of #71825 - contrun:cg-option-strip r=petrochenkov add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker PtxLinker MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.,HEART,2020-05-26T19:55:15Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,HOORAY,2020-05-03T11:19:01Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,HOORAY,2020-05-03T16:10:01Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,HOORAY,2020-05-03T22:43:24Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,THUMBS_UP,2020-05-03T22:43:27Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,THUMBS_UP,2020-05-20T19:53:16Z,not-matthias,NA https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,ROCKET,2021-01-13T14:39:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,ROCKET,2021-02-07T08:05:25Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/71827,CLOSED,2020-05-03T08:18:25Z,2022-03-01T21:20:49Z,Better method call error messages,Quantumplation,NA,NA,NA,THUMBS_UP,2021-07-19T14:33:34Z,Zerotask,NA https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,HOORAY,2020-05-13T05:44:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,HOORAY,2020-05-13T22:22:32Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,THUMBS_UP,2020-05-14T06:44:31Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,HOORAY,2020-05-16T09:05:31Z,strohel,matej@laitl.cz https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,HOORAY,2021-07-23T18:19:40Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,THUMBS_UP,2021-10-03T16:48:58Z,davidrusu,NA https://github.com/rust-lang/rust/pull/71839,MERGED,2020-05-03T12:06:48Z,2020-05-09T06:27:26Z,Make BTreeMap::new and BTreeSet::new const,LG3696,f16c27f1c4821a0d763cb4a5a2c1d518126f024b,4,Rollup merge of #71839 - LG3696:master r=cramertj Make BTreeMap::new and BTreeSet::new const,HOORAY,2021-10-03T16:48:59Z,davidrusu,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T14:47:18Z,Diggsey,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T15:20:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T15:21:23Z,taiki-e,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T15:22:55Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T19:41:57Z,panaman67,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-03T23:05:15Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-04T05:16:30Z,felix91gr,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-04T14:20:40Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-06T22:27:19Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-09T12:17:22Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71840,MERGED,2020-05-03T12:19:29Z,2020-05-10T15:23:08Z,Rework MIR drop tree lowering,matthewjasper,62353071af2dd3a731892a951352acb26809eacf,56,Rollup merge of #71840 - matthewjasper:drop-trees r=oli-obk Rework MIR drop tree lowering This PR changes how drops are generated in MIR construction. This is the first half of the fix for #47949. Rather than generating the drops for a given unwind/break/continue/return/generator drop path as soon as they are needed the required drops are recorded and get generated later. The motivation for this is * It simplifies the caching scheme because it's now possible to walk up the currently scheduled drop tree to recover state. * The basic block order for MIR more closely resembles execution order. This PR also: * Highlights cleanup blocks in the graphviz MIR output. * Removes some unnecessary drop flag assignments.,HEART,2020-05-30T09:37:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71841,CLOSED,2020-05-03T13:08:11Z,2020-05-03T16:38:18Z,Use python3 as default executable for x.py,Mark-Simulacrum,NA,NA,NA,HEART,2020-05-03T13:11:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/71841,CLOSED,2020-05-03T13:08:11Z,2020-05-03T16:38:18Z,Use python3 as default executable for x.py,Mark-Simulacrum,NA,NA,NA,HEART,2020-05-04T08:50:03Z,iago-lito,NA https://github.com/rust-lang/rust/pull/71843,MERGED,2020-05-03T13:30:23Z,2020-05-29T11:17:40Z,Tweak and stabilize AtomicN::fetch_update,sfackler,ea5848df4b6150a5d308af643968d54bb510ac03,1,Rollup merge of #71843 - sfackler:cas-loop-cleanup r=dtolnay Tweak and stabilize AtomicN::fetch_update The fetch_update method implements a compare-and-swap loop to update the value in an atomic to an arbitrary value computed by a closure. I've applied a few tweaks suggested by @mystor in this comment on the tracking issue: https://github.com/rust-lang/rust/issues/48655#issuecomment-496036553. Specifically the load and store ordering arguments have been swapped to match with the orderings of `compare_exchange` and the closure has been moved from the first to last argument. Moving the closure to the last argument is a change away from other methods on the atomic types which place the ordering(s) last but matches with the broad convention that closure arguments come last in functions. In particular rustfmt style lays calls with multi-line closures out more cleanly when the closure comes last.,THUMBS_UP,2020-05-08T17:08:43Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/71843,MERGED,2020-05-03T13:30:23Z,2020-05-29T11:17:40Z,Tweak and stabilize AtomicN::fetch_update,sfackler,ea5848df4b6150a5d308af643968d54bb510ac03,1,Rollup merge of #71843 - sfackler:cas-loop-cleanup r=dtolnay Tweak and stabilize AtomicN::fetch_update The fetch_update method implements a compare-and-swap loop to update the value in an atomic to an arbitrary value computed by a closure. I've applied a few tweaks suggested by @mystor in this comment on the tracking issue: https://github.com/rust-lang/rust/issues/48655#issuecomment-496036553. Specifically the load and store ordering arguments have been swapped to match with the orderings of `compare_exchange` and the closure has been moved from the first to last argument. Moving the closure to the last argument is a change away from other methods on the atomic types which place the ordering(s) last but matches with the broad convention that closure arguments come last in functions. In particular rustfmt style lays calls with multi-line closures out more cleanly when the closure comes last.,THUMBS_UP,2020-05-15T06:35:44Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/71843,MERGED,2020-05-03T13:30:23Z,2020-05-29T11:17:40Z,Tweak and stabilize AtomicN::fetch_update,sfackler,ea5848df4b6150a5d308af643968d54bb510ac03,1,Rollup merge of #71843 - sfackler:cas-loop-cleanup r=dtolnay Tweak and stabilize AtomicN::fetch_update The fetch_update method implements a compare-and-swap loop to update the value in an atomic to an arbitrary value computed by a closure. I've applied a few tweaks suggested by @mystor in this comment on the tracking issue: https://github.com/rust-lang/rust/issues/48655#issuecomment-496036553. Specifically the load and store ordering arguments have been swapped to match with the orderings of `compare_exchange` and the closure has been moved from the first to last argument. Moving the closure to the last argument is a change away from other methods on the atomic types which place the ordering(s) last but matches with the broad convention that closure arguments come last in functions. In particular rustfmt style lays calls with multi-line closures out more cleanly when the closure comes last.,THUMBS_UP,2020-05-16T16:27:47Z,elichai,NA https://github.com/rust-lang/rust/pull/71843,MERGED,2020-05-03T13:30:23Z,2020-05-29T11:17:40Z,Tweak and stabilize AtomicN::fetch_update,sfackler,ea5848df4b6150a5d308af643968d54bb510ac03,1,Rollup merge of #71843 - sfackler:cas-loop-cleanup r=dtolnay Tweak and stabilize AtomicN::fetch_update The fetch_update method implements a compare-and-swap loop to update the value in an atomic to an arbitrary value computed by a closure. I've applied a few tweaks suggested by @mystor in this comment on the tracking issue: https://github.com/rust-lang/rust/issues/48655#issuecomment-496036553. Specifically the load and store ordering arguments have been swapped to match with the orderings of `compare_exchange` and the closure has been moved from the first to last argument. Moving the closure to the last argument is a change away from other methods on the atomic types which place the ordering(s) last but matches with the broad convention that closure arguments come last in functions. In particular rustfmt style lays calls with multi-line closures out more cleanly when the closure comes last.,THUMBS_UP,2021-03-28T23:19:51Z,Virgiel,NA https://github.com/rust-lang/rust/pull/71858,MERGED,2020-05-03T18:25:44Z,2020-06-26T02:17:04Z,Print environment variables accessed by rustc as special comments into depinfo files,petrochenkov,1033351a51dd3ca342a83d4be13f7554f0b4fb1e,6,Auto merge of #71858 - petrochenkov:env r=Mark-Simulacrum Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also there are dozens of uses of `(option_)env!` in rustc repo and like half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n` `\r` `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss,HOORAY,2020-05-04T08:39:13Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/71858,MERGED,2020-05-03T18:25:44Z,2020-06-26T02:17:04Z,Print environment variables accessed by rustc as special comments into depinfo files,petrochenkov,1033351a51dd3ca342a83d4be13f7554f0b4fb1e,6,Auto merge of #71858 - petrochenkov:env r=Mark-Simulacrum Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also there are dozens of uses of `(option_)env!` in rustc repo and like half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n` `\r` `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss,HEART,2020-05-06T10:31:06Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71858,MERGED,2020-05-03T18:25:44Z,2020-06-26T02:17:04Z,Print environment variables accessed by rustc as special comments into depinfo files,petrochenkov,1033351a51dd3ca342a83d4be13f7554f0b4fb1e,6,Auto merge of #71858 - petrochenkov:env r=Mark-Simulacrum Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also there are dozens of uses of `(option_)env!` in rustc repo and like half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n` `\r` `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss,HOORAY,2020-05-13T17:39:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71858,MERGED,2020-05-03T18:25:44Z,2020-06-26T02:17:04Z,Print environment variables accessed by rustc as special comments into depinfo files,petrochenkov,1033351a51dd3ca342a83d4be13f7554f0b4fb1e,6,Auto merge of #71858 - petrochenkov:env r=Mark-Simulacrum Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also there are dozens of uses of `(option_)env!` in rustc repo and like half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n` `\r` `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss,HOORAY,2020-05-29T00:15:25Z,estebank,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HEART,2020-05-03T21:54:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-05-03T21:54:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-05-04T07:26:33Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HEART,2020-05-04T10:40:51Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-05-13T22:08:02Z,faern,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HEART,2020-05-20T18:29:45Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-05-30T13:59:21Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-05-31T15:09:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HEART,2020-06-03T22:36:59Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,CONFUSED,2020-06-04T03:16:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,THUMBS_UP,2020-06-04T04:31:22Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-06-04T19:04:56Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-06-05T06:14:53Z,lnicola,NA https://github.com/rust-lang/rust/pull/71862,MERGED,2020-05-03T21:41:39Z,2020-05-30T03:25:42Z,Implement RFC 2585: unsafe blocks in unsafe fn,LeSeulArtichaut,c442e43b3a6acd5f129ec63e02bc2db61f216520,15,Rollup merge of #71862 - LeSeulArtichaut:unsafe-block-in-unsafe-fn r=nikomatsakis Implement RFC 2585: unsafe blocks in unsafe fn Tracking issue: #71668 r? @RalfJung cc @nikomatsakis,HOORAY,2020-06-15T22:05:48Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/71863,MERGED,2020-05-03T22:13:29Z,2020-05-20T22:50:45Z,Suggest fixes and add error recovery for `use foo::self`,mibac138,14c439177b779408452fdf2c8f4fc620f27905d1,12,Rollup merge of #71863 - mibac138:self-import r=estebank Suggest fixes and add error recovery for `use foo::self` Fixes #63741. I have implemented 2 suggestions on how to fix a `use foo::self` import however I feel like showing them both might be too verbose. Additionally I have also implemented error recovery as [menitoned](https://github.com/rust-lang/rust/issues/63741#issuecomment-602391091) by @comex. I believe r? @estebank deals with diagnostics.,HEART,2020-05-16T16:12:16Z,estebank,NA https://github.com/rust-lang/rust/pull/71872,MERGED,2020-05-04T10:36:25Z,2020-05-16T14:15:43Z,Be less aggressive with `DroplessArena`/`TypedArena` growth.,nnethercote,31add7e60709445617ab54a69f6f21cfcb2e3122,1,Auto merge of #71872 - nnethercote:less-aggressive-arena-growth r=oli-obk Be less aggressive with `DroplessArena`/`TypedArena` growth. `DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB the second is 8 KiB and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena` too.,HEART,2020-05-04T10:44:20Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71872,MERGED,2020-05-04T10:36:25Z,2020-05-16T14:15:43Z,Be less aggressive with `DroplessArena`/`TypedArena` growth.,nnethercote,31add7e60709445617ab54a69f6f21cfcb2e3122,1,Auto merge of #71872 - nnethercote:less-aggressive-arena-growth r=oli-obk Be less aggressive with `DroplessArena`/`TypedArena` growth. `DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB the second is 8 KiB and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena` too.,HEART,2020-05-04T16:48:05Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71872,MERGED,2020-05-04T10:36:25Z,2020-05-16T14:15:43Z,Be less aggressive with `DroplessArena`/`TypedArena` growth.,nnethercote,31add7e60709445617ab54a69f6f21cfcb2e3122,1,Auto merge of #71872 - nnethercote:less-aggressive-arena-growth r=oli-obk Be less aggressive with `DroplessArena`/`TypedArena` growth. `DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB the second is 8 KiB and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena` too.,HEART,2020-05-16T14:27:35Z,95th,NA https://github.com/rust-lang/rust/pull/71872,MERGED,2020-05-04T10:36:25Z,2020-05-16T14:15:43Z,Be less aggressive with `DroplessArena`/`TypedArena` growth.,nnethercote,31add7e60709445617ab54a69f6f21cfcb2e3122,1,Auto merge of #71872 - nnethercote:less-aggressive-arena-growth r=oli-obk Be less aggressive with `DroplessArena`/`TypedArena` growth. `DroplessArena` and `TypedArena` use an aggressive growth strategy: the first chunk is 4 KiB the second is 8 KiB and it keeps on doubling indefinitely. DHAT profiles show that sometimes this results in large chunks (e.g. 16-128 MiB) that are barely filled. This commit changes things so that the doubling stops at 2 MiB. This is large enough that chunk allocations are still rare (you might get 100s instead of 10s of them) but avoids lots of unused space in the worst case. It makes the same change to `TypedArena` too.,HEART,2020-05-21T06:53:47Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71886,MERGED,2020-05-04T15:55:50Z,2020-05-19T15:12:47Z,Stabilize saturating_abs and saturating_neg,t-rapp,4c48f5ab692c640ef9d644efa1989ed67db297d5,3,Rollup merge of #71886 - t-rapp:tr-saturating-funcs r=dtolnay Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983,THUMBS_UP,2020-05-05T07:14:44Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/71886,MERGED,2020-05-04T15:55:50Z,2020-05-19T15:12:47Z,Stabilize saturating_abs and saturating_neg,t-rapp,4c48f5ab692c640ef9d644efa1989ed67db297d5,3,Rollup merge of #71886 - t-rapp:tr-saturating-funcs r=dtolnay Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983,THUMBS_UP,2020-05-13T05:49:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/71886,MERGED,2020-05-04T15:55:50Z,2020-05-19T15:12:47Z,Stabilize saturating_abs and saturating_neg,t-rapp,4c48f5ab692c640ef9d644efa1989ed67db297d5,3,Rollup merge of #71886 - t-rapp:tr-saturating-funcs r=dtolnay Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983,THUMBS_UP,2020-05-14T06:51:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/71886,MERGED,2020-05-04T15:55:50Z,2020-05-19T15:12:47Z,Stabilize saturating_abs and saturating_neg,t-rapp,4c48f5ab692c640ef9d644efa1989ed67db297d5,3,Rollup merge of #71886 - t-rapp:tr-saturating-funcs r=dtolnay Stabilize saturating_abs and saturating_neg Stabilizes the following signed integer functions with saturation mechanics: * saturating_abs() * saturating_neg() Closes #59983,THUMBS_UP,2020-05-29T17:40:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-04T19:34:28Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-04T19:47:59Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-05T00:45:35Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-05T03:25:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-05T19:26:29Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/71891,MERGED,2020-05-04T19:06:56Z,2020-05-05T06:01:16Z,¬∃x. ¬y => ∀x. y,lcnr,a93cc0664fee37010385b88918632332d2a4281f,1,Rollup merge of #71891 - lcnr:not-iter-any r=Dylan-DPC ¬∃x. ¬y => ∀x. y,LAUGH,2020-05-15T07:42:07Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/71919,MERGED,2020-05-05T12:14:35Z,2020-05-16T17:44:51Z,Update transitive dependency to work towards removing syn <1.0 dep,Xanewok,9dd7ad3ed2313db6afbfbd385cfa87e11b27bf9f,2,Rollup merge of #71919 - Xanewok:bump-syn-1 r=Xanewok Update transitive dependency to work towards removing syn <1.0 dep This bumps a couple of transitive dependencies in hopes of eventually not transitively depending on syn <1.0 and friends. The only upstream changes that this is blocked on seems to be https://github.com/mattico/elasticlunr-rs/pull/27 and https://github.com/rust-lang/mdBook/pull/1210. While working on https://github.com/rust-lang/rust/pull/71875 I noticed we still use syn 0.15 here and there so this is a drive-by PR which aims to help with things a bit.,HEART,2020-05-05T12:34:22Z,hanna-kruppe,hanna.kruppe@gmail.com https://github.com/rust-lang/rust/pull/71919,MERGED,2020-05-05T12:14:35Z,2020-05-16T17:44:51Z,Update transitive dependency to work towards removing syn <1.0 dep,Xanewok,9dd7ad3ed2313db6afbfbd385cfa87e11b27bf9f,2,Rollup merge of #71919 - Xanewok:bump-syn-1 r=Xanewok Update transitive dependency to work towards removing syn <1.0 dep This bumps a couple of transitive dependencies in hopes of eventually not transitively depending on syn <1.0 and friends. The only upstream changes that this is blocked on seems to be https://github.com/mattico/elasticlunr-rs/pull/27 and https://github.com/rust-lang/mdBook/pull/1210. While working on https://github.com/rust-lang/rust/pull/71875 I noticed we still use syn 0.15 here and there so this is a drive-by PR which aims to help with things a bit.,HEART,2020-05-06T07:51:07Z,mati865,NA https://github.com/rust-lang/rust/pull/71919,MERGED,2020-05-05T12:14:35Z,2020-05-16T17:44:51Z,Update transitive dependency to work towards removing syn <1.0 dep,Xanewok,9dd7ad3ed2313db6afbfbd385cfa87e11b27bf9f,2,Rollup merge of #71919 - Xanewok:bump-syn-1 r=Xanewok Update transitive dependency to work towards removing syn <1.0 dep This bumps a couple of transitive dependencies in hopes of eventually not transitively depending on syn <1.0 and friends. The only upstream changes that this is blocked on seems to be https://github.com/mattico/elasticlunr-rs/pull/27 and https://github.com/rust-lang/mdBook/pull/1210. While working on https://github.com/rust-lang/rust/pull/71875 I noticed we still use syn 0.15 here and there so this is a drive-by PR which aims to help with things a bit.,HEART,2020-05-06T09:23:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71919,MERGED,2020-05-05T12:14:35Z,2020-05-16T17:44:51Z,Update transitive dependency to work towards removing syn <1.0 dep,Xanewok,9dd7ad3ed2313db6afbfbd385cfa87e11b27bf9f,2,Rollup merge of #71919 - Xanewok:bump-syn-1 r=Xanewok Update transitive dependency to work towards removing syn <1.0 dep This bumps a couple of transitive dependencies in hopes of eventually not transitively depending on syn <1.0 and friends. The only upstream changes that this is blocked on seems to be https://github.com/mattico/elasticlunr-rs/pull/27 and https://github.com/rust-lang/mdBook/pull/1210. While working on https://github.com/rust-lang/rust/pull/71875 I noticed we still use syn 0.15 here and there so this is a drive-by PR which aims to help with things a bit.,HEART,2020-05-11T15:15:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71930,MERGED,2020-05-05T20:57:07Z,2020-05-21T22:15:03Z,De-abuse TyKind::Error in exhaustiveness checking,Nadrieril,9310e3bd4f425f84fc27878ebf2bda1f30935a63,4,Auto merge of #71930 - Nadrieril:exhaustiveness-remove-tyerr r=varkor De-abuse TyKind::Error in exhaustiveness checking Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866. In order to remove the use of `TyKind::Error` I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model. As usual I tried to separate commits that shuffle code around from commits that require more thought to review. cc @varkor @Centril,HEART,2020-05-06T00:23:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71930,MERGED,2020-05-05T20:57:07Z,2020-05-21T22:15:03Z,De-abuse TyKind::Error in exhaustiveness checking,Nadrieril,9310e3bd4f425f84fc27878ebf2bda1f30935a63,4,Auto merge of #71930 - Nadrieril:exhaustiveness-remove-tyerr r=varkor De-abuse TyKind::Error in exhaustiveness checking Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866. In order to remove the use of `TyKind::Error` I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model. As usual I tried to separate commits that shuffle code around from commits that require more thought to review. cc @varkor @Centril,ROCKET,2020-05-06T00:23:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71930,MERGED,2020-05-05T20:57:07Z,2020-05-21T22:15:03Z,De-abuse TyKind::Error in exhaustiveness checking,Nadrieril,9310e3bd4f425f84fc27878ebf2bda1f30935a63,4,Auto merge of #71930 - Nadrieril:exhaustiveness-remove-tyerr r=varkor De-abuse TyKind::Error in exhaustiveness checking Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866. In order to remove the use of `TyKind::Error` I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model. As usual I tried to separate commits that shuffle code around from commits that require more thought to review. cc @varkor @Centril,HEART,2020-05-12T21:20:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71931,MERGED,2020-05-05T21:34:46Z,2020-05-26T20:59:33Z,Export ZERO_AR_DATE for macos linker invocations,alexcrichton,5239f5c57bb6eb9e894081727f5aba0a67e89763,2,Auto merge of #71931 - alexcrichton:reproducible-macos r=eddyb Export ZERO_AR_DATE for macos linker invocations This commit attempts to improve reproducibility of builds on macOS by exporting the `ZERO_AR_DATE=1` environment variable for all invocations of the linker. While it looks like this env var is targeted at just the `ar` command (which does actually read this) it appears that recent-ish versions of the linker *also* read this environment variable. This env var forces the linker to set a deterministic zero value for the mtime in the N_OSO field of the object file. Currently it's believe that older versions of the linker will simply ignore this env var while newer versions will read it and produce a deterministic output for compilations with debuginfo. Closes #47086 Closes #66568,HOORAY,2020-05-07T18:02:24Z,luser,NA https://github.com/rust-lang/rust/pull/71932,CLOSED,2020-05-05T21:47:33Z,2020-05-23T20:32:44Z,Convert posix scripts to bash,Daniel-Worrall,NA,NA,NA,CONFUSED,2020-05-06T14:29:40Z,kennytm,NA https://github.com/rust-lang/rust/pull/71942,MERGED,2020-05-06T06:47:15Z,2020-05-09T06:27:16Z,Shrink `LocalDecl`,nnethercote,2b3a114633c23acb96f94ed66b620e74b832c19b,25,Rollup merge of #71942 - nnethercote:shrink-LocalDecl r=matthewjasper Shrink `LocalDecl` `LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit and does some clean-ups as well. r? @matthewjasper,HEART,2020-05-06T19:51:39Z,panaman67,NA https://github.com/rust-lang/rust/pull/71942,MERGED,2020-05-06T06:47:15Z,2020-05-09T06:27:16Z,Shrink `LocalDecl`,nnethercote,2b3a114633c23acb96f94ed66b620e74b832c19b,25,Rollup merge of #71942 - nnethercote:shrink-LocalDecl r=matthewjasper Shrink `LocalDecl` `LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit and does some clean-ups as well. r? @matthewjasper,HEART,2020-05-15T14:10:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71964,MERGED,2020-05-07T00:35:28Z,2020-05-14T16:06:47Z,Fix bootstrap failing on win32,jcotton42,577da45097e439c1aefd853b9ff41f305449b848,1,"Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File ""x.py"" line 11 in bootstrap.main() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 960 in main bootstrap(help_triggered) File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 925 in bootstrap build.build = args.build or build.build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 731 in build_triple return default_build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 184 in default_build_triple ostype = require([""uname"" ""-s""] exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None` as they would be on Windows since `uname` doesn't exist",THUMBS_UP,2020-05-07T21:23:48Z,mibac138,NA https://github.com/rust-lang/rust/pull/71964,MERGED,2020-05-07T00:35:28Z,2020-05-14T16:06:47Z,Fix bootstrap failing on win32,jcotton42,577da45097e439c1aefd853b9ff41f305449b848,1,"Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File ""x.py"" line 11 in bootstrap.main() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 960 in main bootstrap(help_triggered) File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 925 in bootstrap build.build = args.build or build.build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 731 in build_triple return default_build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 184 in default_build_triple ostype = require([""uname"" ""-s""] exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None` as they would be on Windows since `uname` doesn't exist",THUMBS_UP,2020-05-08T20:02:35Z,Daniel-Worrall,Daniel.Worrall@hotmail.co.uk https://github.com/rust-lang/rust/pull/71964,MERGED,2020-05-07T00:35:28Z,2020-05-14T16:06:47Z,Fix bootstrap failing on win32,jcotton42,577da45097e439c1aefd853b9ff41f305449b848,1,"Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File ""x.py"" line 11 in bootstrap.main() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 960 in main bootstrap(help_triggered) File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 925 in bootstrap build.build = args.build or build.build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 731 in build_triple return default_build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 184 in default_build_triple ostype = require([""uname"" ""-s""] exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None` as they would be on Windows since `uname` doesn't exist",THUMBS_UP,2020-05-09T00:49:02Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/71964,MERGED,2020-05-07T00:35:28Z,2020-05-14T16:06:47Z,Fix bootstrap failing on win32,jcotton42,577da45097e439c1aefd853b9ff41f305449b848,1,"Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File ""x.py"" line 11 in bootstrap.main() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 960 in main bootstrap(help_triggered) File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 925 in bootstrap build.build = args.build or build.build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 731 in build_triple return default_build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 184 in default_build_triple ostype = require([""uname"" ""-s""] exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None` as they would be on Windows since `uname` doesn't exist",THUMBS_UP,2020-05-11T11:14:24Z,bdbai,bdbaiapp@163.com https://github.com/rust-lang/rust/pull/71964,MERGED,2020-05-07T00:35:28Z,2020-05-14T16:06:47Z,Fix bootstrap failing on win32,jcotton42,577da45097e439c1aefd853b9ff41f305449b848,1,"Rollup merge of #71964 - jcotton42:bootstrap_decode_none_windows r=Mark-Simulacrum Fix bootstrap failing on win32 ```powershell python x.py -h # or really any x.py command ``` would fail with ``` info: Downloading and building bootstrap before processing --help command. See src/bootstrap/README.md for help with common commands. Updating only changed submodules Submodules updated in 0.15 seconds Traceback (most recent call last): File ""x.py"" line 11 in bootstrap.main() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 960 in main bootstrap(help_triggered) File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 925 in bootstrap build.build = args.build or build.build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 731 in build_triple return default_build_triple() File ""C:\Users\Joshua\Projects\forks\rust\src\bootstrap\bootstrap.py"" line 184 in default_build_triple ostype = require([""uname"" ""-s""] exit=required).decode(default_encoding) AttributeError: 'NoneType' object has no attribute 'decode' ``` This PR defers the `decode` call until after we're sure `ostype` and `cputype` are not `None` as they would be on Windows since `uname` doesn't exist",THUMBS_UP,2020-05-12T06:36:06Z,UtherII,NA https://github.com/rust-lang/rust/pull/71970,MERGED,2020-05-07T05:51:31Z,2020-05-08T23:46:07Z,Improve bitcode generation for Apple platforms,thombles,e3a4ff0d76d6d479e3cc113eadbd8494c2ab89b8,5,Rollup merge of #71970 - thombles:ios-bitcode-improvements r=alexcrichton Improve bitcode generation for Apple platforms Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton This improves Rust's bitcode generation so that provided you have a compatible LLVM version Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE). 1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS` which is far from obvious. 2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS copied directly from the a clang equivalent section. In the context of Apple platforms the predominant purpose of bitcode is App Store submissions so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure. Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.,THUMBS_UP,2020-05-07T09:08:46Z,timothyklim,NA https://github.com/rust-lang/rust/pull/71970,MERGED,2020-05-07T05:51:31Z,2020-05-08T23:46:07Z,Improve bitcode generation for Apple platforms,thombles,e3a4ff0d76d6d479e3cc113eadbd8494c2ab89b8,5,Rollup merge of #71970 - thombles:ios-bitcode-improvements r=alexcrichton Improve bitcode generation for Apple platforms Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton This improves Rust's bitcode generation so that provided you have a compatible LLVM version Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE). 1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS` which is far from obvious. 2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS copied directly from the a clang equivalent section. In the context of Apple platforms the predominant purpose of bitcode is App Store submissions so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure. Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.,LAUGH,2020-05-07T09:21:02Z,delneg,delneg@yandex.ru https://github.com/rust-lang/rust/pull/71970,MERGED,2020-05-07T05:51:31Z,2020-05-08T23:46:07Z,Improve bitcode generation for Apple platforms,thombles,e3a4ff0d76d6d479e3cc113eadbd8494c2ab89b8,5,Rollup merge of #71970 - thombles:ios-bitcode-improvements r=alexcrichton Improve bitcode generation for Apple platforms Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton This improves Rust's bitcode generation so that provided you have a compatible LLVM version Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE). 1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS` which is far from obvious. 2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS copied directly from the a clang equivalent section. In the context of Apple platforms the predominant purpose of bitcode is App Store submissions so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure. Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.,THUMBS_UP,2020-05-09T03:17:07Z,jpsim,jp@jpsim.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-07T09:52:17Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-07T11:16:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-07T11:34:46Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-07T14:02:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-07T22:04:47Z,alexreg,alex@noldorin.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-08T05:31:38Z,felix91gr,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-08T05:31:40Z,felix91gr,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-08T07:22:43Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-08T11:46:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-08T14:33:41Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-08T14:33:43Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-08T15:37:52Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-10T08:04:57Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-10T08:04:59Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-11T20:03:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-12T12:13:07Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-12T13:07:03Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-14T11:17:11Z,darksv,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-14T11:17:14Z,darksv,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-16T23:33:12Z,Demi-Marie,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-17T01:01:11Z,est31,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-18T16:18:06Z,ljedrz,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-19T02:17:20Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-28T13:08:16Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-29T03:53:58Z,L117,l117@l117.xyz https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-05-29T03:53:59Z,L117,l117@l117.xyz https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-05-29T12:59:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-06-05T02:50:41Z,tyler274,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2020-06-05T02:50:42Z,tyler274,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2020-08-26T15:05:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HOORAY,2021-08-30T21:01:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71973,MERGED,2020-05-07T07:25:40Z,2020-05-19T02:16:20Z,Lazy normalization of constants (Reprise),lcnr,c6030c957a2bb4ddb36c9a06df5fcf9c5f626029,56,Rollup merge of #71973 - lcnr:lazy-norm r=nikomatsakis Lazy normalization of constants (Reprise) Continuation of #67890 by @skinny121. Initial implementation of #60471 for constants. Perform normalization/evaluation of constants lazily which is known as lazy normalization. Lazy normalization is only enabled when using `#![feature(lazy_normalization_consts)]` by default constants are still evaluated eagerly as there are currently. Lazy normalization of constants is achieved with a new ConstEquate predicate which type inferences uses to delay checking whether constants are equal to each other until later avoiding cycle errors. Note this doesn't allow the use of generics within repeat count expressions as that is still evaluated during conversion to mir. There are also quite a few other known problems with lazy normalization which will be fixed in future PRs. r? @nikomatsakis fixes #71922 fixes #71986,HEART,2021-08-30T21:02:00Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/71976,MERGED,2020-05-07T08:38:00Z,2020-06-19T05:04:25Z,Improve diagnostics for `let x += 1`,mibac138,39f8784eb6056c21c120bfa93bbec73e19773727,3,Rollup merge of #71976 - mibac138:let-recovery r=estebank Improve diagnostics for `let x += 1` Fixes(?) #66736 The code responsible for the `E0404` errors is [here](https://github.com/rust-lang/rust/blob/master/src/librustc_parse/parser/ty.rs#L399-L424) which I don't think can be easily modified to prevent emitting an error in one specific case. Because of this I couldn't get rid of `E0404` and instead added `E0067` along with a help message which will fix the problem. r? @estebank,HEART,2020-06-25T02:11:34Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/71991,CLOSED,2020-05-07T19:29:20Z,2020-07-22T14:03:58Z,Add Iterator::starts_with,rcoh,NA,NA,NA,THUMBS_UP,2020-07-04T21:37:16Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/71993,MERGED,2020-05-07T20:20:09Z,2020-05-08T16:42:08Z,Remove old `util/liveness.rs` module,ecstatic-morse,681d747b65e1130096412054f3f222cb19fb3124,8,"Rollup merge of #71993 - ecstatic-morse:cleanup-old-liveness r=jonas-schievink Remove old `util/liveness.rs` module The liveness dataflow analysis now lives in the `dataflow` module so this one is no longer necessary. I've copied the relevant bits of the module docs for `util::liveness` to `MaybeLiveLocals`. The example in the docs is now a `mir-dataflow` test: https://github.com/rust-lang/rust/blob/a08c47310c7d49cbdc5d7afb38408ba519967ecd/src/test/ui/mir-dataflow/liveness-ptr.rs#L6-L26 The borrow-checker used the same notion of ""defs"" and ""uses"" so I've moved it into a submodule. I would have moved it to `util/def_use.rs` since it seems generally useful but there's already a slightly [different version](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/util/def_use.rs) of the same abstraction needed for copy propagation.",HOORAY,2020-05-08T06:53:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/71996,MERGED,2020-05-07T21:30:57Z,2020-05-27T22:24:26Z,perf: Revert accidental inclusion of a part of #69218,Marwes,664fcd3f046e2a6824602da0fad81e3e2bb0d409,7,Auto merge of #71996 - Marwes:detach_undo_log r=nikomatsakis perf: Revert accidental inclusion of a part of #69218 This was accidentally included in #69464 after a rebase and given how much `inflate` and `keccak` stresses the obligation forest seems like a likely culprit to the regression in those benchmarks. (It is necessary in #69218 as obligation forest needs to accurately track the root variables or unifications will get lost),HOORAY,2020-05-07T21:33:20Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/71996,MERGED,2020-05-07T21:30:57Z,2020-05-27T22:24:26Z,perf: Revert accidental inclusion of a part of #69218,Marwes,664fcd3f046e2a6824602da0fad81e3e2bb0d409,7,Auto merge of #71996 - Marwes:detach_undo_log r=nikomatsakis perf: Revert accidental inclusion of a part of #69218 This was accidentally included in #69464 after a rebase and given how much `inflate` and `keccak` stresses the obligation forest seems like a likely culprit to the regression in those benchmarks. (It is necessary in #69218 as obligation forest needs to accurately track the root variables or unifications will get lost),HOORAY,2020-05-08T00:29:32Z,mati865,NA https://github.com/rust-lang/rust/pull/71996,MERGED,2020-05-07T21:30:57Z,2020-05-27T22:24:26Z,perf: Revert accidental inclusion of a part of #69218,Marwes,664fcd3f046e2a6824602da0fad81e3e2bb0d409,7,Auto merge of #71996 - Marwes:detach_undo_log r=nikomatsakis perf: Revert accidental inclusion of a part of #69218 This was accidentally included in #69464 after a rebase and given how much `inflate` and `keccak` stresses the obligation forest seems like a likely culprit to the regression in those benchmarks. (It is necessary in #69218 as obligation forest needs to accurately track the root variables or unifications will get lost),HOORAY,2020-05-26T19:00:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72000,MERGED,2020-05-08T00:49:20Z,2020-05-22T08:05:19Z,Move the target libLLVM to llvm-tools-preview,cuviper,c60b675e280fedded8d8487acd051cd342e486f2,2,Auto merge of #72000 - cuviper:dist-llvm r=Mark-Simulacrum Move the target libLLVM to llvm-tools-preview For running the compiler we usually only need LLVM from `$sysroot/lib` which rustup will make available with `LD_LIBRARY_PATH`. We've also been shipping LLVM in the `$target/lib` directory which bloats the download and installed size. The only times we do need the latter are for the RPATH of `llvm-tools-preview` binaries and for linking `rustc-dev` libraries. We'll move it to the `llvm-tools-preview` component directly and `rustc-dev` will have an implicit dependency on it. Here are the dist sizes that I got before and after this change: llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M The installed size should reduce by exactly one `libLLVM.so` (~70-80M) unless you also install `llvm-tools` and then it should be identical. Resolves #70838.,HOORAY,2020-05-23T15:23:29Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/72000,MERGED,2020-05-08T00:49:20Z,2020-05-22T08:05:19Z,Move the target libLLVM to llvm-tools-preview,cuviper,c60b675e280fedded8d8487acd051cd342e486f2,2,Auto merge of #72000 - cuviper:dist-llvm r=Mark-Simulacrum Move the target libLLVM to llvm-tools-preview For running the compiler we usually only need LLVM from `$sysroot/lib` which rustup will make available with `LD_LIBRARY_PATH`. We've also been shipping LLVM in the `$target/lib` directory which bloats the download and installed size. The only times we do need the latter are for the RPATH of `llvm-tools-preview` binaries and for linking `rustc-dev` libraries. We'll move it to the `llvm-tools-preview` component directly and `rustc-dev` will have an implicit dependency on it. Here are the dist sizes that I got before and after this change: llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M The installed size should reduce by exactly one `libLLVM.so` (~70-80M) unless you also install `llvm-tools` and then it should be identical. Resolves #70838.,HOORAY,2020-05-25T10:06:42Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-08T13:10:52Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-08T14:22:07Z,Marwes,marwes91@gmail.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-08T18:19:40Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-10T15:30:30Z,bluss,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-11T14:26:26Z,est31,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-12T08:56:48Z,mzji,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-12T11:45:14Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-13T17:17:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-13T22:06:48Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-19T04:42:24Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-19T14:04:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-19T23:51:32Z,jminer,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-20T10:18:39Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-20T16:52:50Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-21T02:25:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-21T06:57:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-21T21:56:46Z,goodSyntax808,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-22T08:18:42Z,alok,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,THUMBS_UP,2020-05-28T03:28:22Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,THUMBS_UP,2020-05-28T08:04:04Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-05-28T13:09:41Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,THUMBS_UP,2020-06-12T16:24:51Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-08-05T06:51:43Z,simlay,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-08-05T09:43:32Z,tux3,NA https://github.com/rust-lang/rust/pull/72013,MERGED,2020-05-08T13:09:09Z,2020-05-13T17:59:18Z,Make `RawVec::grow` mostly non-generic.,nnethercote,75e1463c52aaea25bd32ed53c73797357e561cce,2,Auto merge of #72013 - nnethercote:make-RawVec-grow-mostly-non-generic r=Amanieu Make `RawVec::grow` mostly non-generic. `cargo-llvm-lines` shows that in various benchmarks `RawVec::grow` is instantiated 10s or 100s of times and accounts for 1-8% of lines of generated LLVM IR. This commit moves most of `RawVec::grow` into a separate function that isn't parameterized by `T` which means it doesn't need to be instantiated many times. This reduces compile time significantly. r? @ghost,HEART,2020-08-05T13:38:55Z,delacian,NA https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,LAUGH,2020-05-08T22:45:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,THUMBS_UP,2020-05-10T07:51:37Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,LAUGH,2020-05-11T22:22:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,LAUGH,2020-05-12T04:19:37Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,LAUGH,2020-07-16T14:43:10Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72014,MERGED,2020-05-08T13:27:43Z,2020-05-12T02:44:55Z,Deprecated emoji,GuillaumeGomez,dd595fade53937fafe3940c83293654e77c78d8f,2,Rollup merge of #72014 - GuillaumeGomez:deprecated-emoji r=kinnison ollie27 Deprecated emoji Fixes #67872. r? @kinnison cc @rust-lang/rustdoc,THUMBS_UP,2020-07-29T21:56:22Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HEART,2020-05-19T18:03:28Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HOORAY,2020-05-20T01:00:24Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HOORAY,2021-01-11T01:26:58Z,camelid,NA https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HEART,2021-01-11T01:26:58Z,camelid,NA https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HOORAY,2021-03-18T18:32:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HOORAY,2021-04-25T22:10:22Z,est31,NA https://github.com/rust-lang/rust/pull/72015,CLOSED,2020-05-08T14:04:02Z,2021-05-04T19:08:17Z,Remove Spans from HIR,cjgillot,NA,NA,NA,HEART,2021-04-25T22:10:23Z,est31,NA https://github.com/rust-lang/rust/pull/72017,MERGED,2020-05-08T15:45:10Z,2020-05-08T23:46:01Z,Work around ICEs during cross-compilation for target ast & attr,ctaggart,827ec49c233f6d0182c83a6123cc3fa639220da2,3,"Rollup merge of #72017 - ctaggart:wasm2 r=ecstatic-morse Work around ICEs during cross-compilation for target ast & attr This applies the fix for #72003 to work around #56935 to three more libraries. With these additional fixes I'm able to use rustfmt_lib from wasm (https://github.com/rust-lang/rustfmt/issues/4132#issuecomment-616587989) which was my goal. To get it working locally and to test I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project: ``` toml [replace] ""rustc-ap-rustc_span:656.0.0"" = { path = ""../rustc-ap-rustc_span"" } ""rustc-ap-rustc_target:656.0.0"" = { path = ""../rustc-ap-rustc_target"" } ""rustc-ap-rustc_ast:656.0.0"" = { path = ""../rustc-ap-rustc_ast"" } ""rustc-ap-rustc_attr:656.0.0"" = { path = ""../rustc-ap-rustc_attr"" } ```",HEART,2020-05-08T16:38:08Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72020,MERGED,2020-05-08T16:31:56Z,2020-05-10T08:25:40Z,Fix disagreeement about CGU reuse and LTO,alexcrichton,b3269536d0a883caa0904cf6589aa1310ff70b5e,4,Auto merge of #72020 - alexcrichton:fix-incremental-linker-plugin-lto r=oli-obk Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006,HEART,2020-05-08T16:52:04Z,ehuss,NA https://github.com/rust-lang/rust/pull/72020,MERGED,2020-05-08T16:31:56Z,2020-05-10T08:25:40Z,Fix disagreeement about CGU reuse and LTO,alexcrichton,b3269536d0a883caa0904cf6589aa1310ff70b5e,4,Auto merge of #72020 - alexcrichton:fix-incremental-linker-plugin-lto r=oli-obk Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes #72006,THUMBS_UP,2020-05-09T01:07:19Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/72031,MERGED,2020-05-08T23:20:01Z,2020-05-09T06:27:07Z,Better documentation for io::Read::read() return value,Elinvynia,4b337d2bf6204f574a9bece504df4de7cb7ed032,1,Rollup merge of #72031 - Elinvynia:master r=Mark-Simulacrum Better documentation for io::Read::read() return value Aims to provide the clarity requested in #70360,HEART,2020-05-10T13:17:25Z,bedax,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HEART,2020-05-09T01:14:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HOORAY,2020-05-09T01:14:19Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,THUMBS_UP,2020-05-09T02:00:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HEART,2020-05-09T07:54:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,THUMBS_UP,2020-05-09T21:36:28Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HOORAY,2020-05-10T11:24:21Z,Keruspe,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,THUMBS_UP,2020-05-11T22:15:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HOORAY,2020-05-12T07:32:35Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,THUMBS_UP,2020-05-12T18:25:16Z,tmandry,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HOORAY,2020-05-14T19:12:26Z,audunhalland,audun.halland@pm.me https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,HOORAY,2020-05-17T23:11:25Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/72035,CLOSED,2020-05-09T00:49:51Z,2020-10-16T00:45:28Z,Add the Stream trait,sfackler,NA,NA,NA,THUMBS_UP,2020-05-18T08:04:33Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/72041,MERGED,2020-05-09T11:36:40Z,2020-05-09T20:55:42Z,Rollup of 5 pull requests,RalfJung,bad3bf622bded50a97c0a54e29350eada2a3a169,380,Auto merge of #72041 - RalfJung:rollup-xivrvy2 r=RalfJung Rollup of 5 pull requests Successful merges: - #69406 (upgrade chalk and use chalk-solve/chalk-ir/chalk-rust-ir) - #71185 (Move tests from `test/run-fail` to UI) - #71234 (rustllvm: Use .init_array rather than .ctors) - #71508 (Simplify the `tcx.alloc_map` API) - #71555 (Remove ast::{Ident Name} reexports.) Failed merges: r? @ghost,HEART,2020-05-09T13:17:17Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/72044,MERGED,2020-05-09T12:00:02Z,2020-05-12T02:44:51Z,use min_specialization for some rustc crates where it requires no changes,RalfJung,eade6f7881b89435fd3019183d76a67f924c32cb,9,Rollup merge of #72044 - RalfJung:min-spec r=matthewjasper use min_specialization for some rustc crates where it requires no changes and add FIXME for the rest Cc @matthewjasper,THUMBS_UP,2020-05-11T22:23:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72045,MERGED,2020-05-09T12:43:58Z,2020-05-16T21:07:30Z,Incomplete features can also be unsound,RalfJung,aecab5e603ad0a904f2f357470b419b2ac6014d8,176,Rollup merge of #72045 - RalfJung:incomplete-unsound r=petrochenkov Incomplete features can also be unsound Some incomplete features do not just ICE they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029 and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue which hopefully should explain what is incomplete/unsound about the feature.,THUMBS_UP,2020-05-09T13:48:22Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72045,MERGED,2020-05-09T12:43:58Z,2020-05-16T21:07:30Z,Incomplete features can also be unsound,RalfJung,aecab5e603ad0a904f2f357470b419b2ac6014d8,176,Rollup merge of #72045 - RalfJung:incomplete-unsound r=petrochenkov Incomplete features can also be unsound Some incomplete features do not just ICE they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029 and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue which hopefully should explain what is incomplete/unsound about the feature.,THUMBS_UP,2020-05-09T22:56:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72045,MERGED,2020-05-09T12:43:58Z,2020-05-16T21:07:30Z,Incomplete features can also be unsound,RalfJung,aecab5e603ad0a904f2f357470b419b2ac6014d8,176,Rollup merge of #72045 - RalfJung:incomplete-unsound r=petrochenkov Incomplete features can also be unsound Some incomplete features do not just ICE they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029 and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue which hopefully should explain what is incomplete/unsound about the feature.,THUMBS_UP,2020-05-10T10:48:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72045,MERGED,2020-05-09T12:43:58Z,2020-05-16T21:07:30Z,Incomplete features can also be unsound,RalfJung,aecab5e603ad0a904f2f357470b419b2ac6014d8,176,Rollup merge of #72045 - RalfJung:incomplete-unsound r=petrochenkov Incomplete features can also be unsound Some incomplete features do not just ICE they are also currently unsound (e.g. https://github.com/rust-lang/rust/pull/72029 and also `specialization` -- which is not yet marked incomplete but [should be](https://github.com/rust-lang/rust/pull/71420)). This makes the message reflect that. While at it I also added a link to the tracking issue which hopefully should explain what is incomplete/unsound about the feature.,THUMBS_UP,2020-05-20T19:11:00Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/72047,MERGED,2020-05-09T14:04:41Z,2020-05-16T21:07:29Z,Literal error reporting cleanup,Julian-Wollersberger,ec5610ff8c41eb0664dab868dc9186a21e2f13b0,6,Rollup merge of #72047 - Julian-Wollersberger:literal_error_reporting_cleanup r=petrochenkov Literal error reporting cleanup While doing some performance work I noticed some code duplication in `librustc_parser/lexer/mod.rs` so I cleaned it up. This PR is probably best reviewed commit by commit. I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed but two are used by clippy so I left them in for now. I could open a PR for Rust-Analyzer when this one lands. But how do I open a PR for clippy? (Git submodules are frustrating to work with),HEART,2020-05-09T21:00:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/72047,MERGED,2020-05-09T14:04:41Z,2020-05-16T21:07:29Z,Literal error reporting cleanup,Julian-Wollersberger,ec5610ff8c41eb0664dab868dc9186a21e2f13b0,6,Rollup merge of #72047 - Julian-Wollersberger:literal_error_reporting_cleanup r=petrochenkov Literal error reporting cleanup While doing some performance work I noticed some code duplication in `librustc_parser/lexer/mod.rs` so I cleaned it up. This PR is probably best reviewed commit by commit. I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed but two are used by clippy so I left them in for now. I could open a PR for Rust-Analyzer when this one lands. But how do I open a PR for clippy? (Git submodules are frustrating to work with),HEART,2020-05-21T06:50:15Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72053,MERGED,2020-05-09T17:27:46Z,2020-07-02T01:00:40Z,Test UI tests for pass=check,Mark-Simulacrum,9491f18c5de3ff1c4bf9c3fdacf52d9859e26f7c,1,Auto merge of #72053 - Mark-Simulacrum:32bitcheck r=pietroalbini Test UI tests for pass=check I'm going to just compare the builder times since I wasn't able to get this working nicely locally (hit some obscure linker error). Fixes part of #69823,HEART,2020-05-09T17:32:00Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72055,MERGED,2020-05-09T17:43:41Z,2020-05-22T01:33:18Z,Intern predicates,lcnr,22438fc22b92506b0afc857a96ff6fba3d3a8e81,61,Rollup merge of #72055 - lcnr:predicate-kind r=nikomatsakis Intern predicates Implements the first step of https://github.com/rust-lang/compiler-team/issues/285 Renames `ty::Predicate` to `ty::PredicateKind` which is now interned. To ease the transition `ty::Predicate` is now a struct containing a reference to `ty::PredicateKind`. r? @ghost,ROCKET,2020-05-09T22:53:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72055,MERGED,2020-05-09T17:43:41Z,2020-05-22T01:33:18Z,Intern predicates,lcnr,22438fc22b92506b0afc857a96ff6fba3d3a8e81,61,Rollup merge of #72055 - lcnr:predicate-kind r=nikomatsakis Intern predicates Implements the first step of https://github.com/rust-lang/compiler-team/issues/285 Renames `ty::Predicate` to `ty::PredicateKind` which is now interned. To ease the transition `ty::Predicate` is now a struct containing a reference to `ty::PredicateKind`. r? @ghost,ROCKET,2020-06-10T09:45:54Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72055,MERGED,2020-05-09T17:43:41Z,2020-05-22T01:33:18Z,Intern predicates,lcnr,22438fc22b92506b0afc857a96ff6fba3d3a8e81,61,Rollup merge of #72055 - lcnr:predicate-kind r=nikomatsakis Intern predicates Implements the first step of https://github.com/rust-lang/compiler-team/issues/285 Renames `ty::Predicate` to `ty::PredicateKind` which is now interned. To ease the transition `ty::Predicate` is now a struct containing a reference to `ty::PredicateKind`. r? @ghost,ROCKET,2020-07-22T18:36:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-05-18T16:49:09Z,ratijas,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-05-20T01:15:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-05-20T13:56:19Z,non-descriptive,unlockmehdp@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-05-20T20:01:40Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-05-21T06:46:11Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-05-21T10:57:18Z,skerkour,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-06-05T07:47:44Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HOORAY,2020-06-10T23:51:05Z,yerke,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-06-10T23:51:06Z,yerke,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-06-13T16:51:27Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-02T19:42:46Z,MrAwesome,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HOORAY,2020-07-02T19:42:48Z,MrAwesome,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-07-02T19:42:49Z,MrAwesome,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-14T06:15:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-16T03:35:02Z,JPTIZ,jpaulotiz@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-07-16T03:35:03Z,JPTIZ,jpaulotiz@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-16T14:39:34Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-07-16T16:44:36Z,musaprg,mail@mssn.dev https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-16T22:25:31Z,Lesmiscore,NA https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2020-07-21T09:02:21Z,morimolymoly,morimolymoly@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HOORAY,2020-07-21T09:02:23Z,morimolymoly,morimolymoly@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-07-21T09:02:23Z,morimolymoly,morimolymoly@gmail.com https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,HEART,2020-08-05T20:52:26Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2021-07-29T04:12:20Z,doodlewind,i@ewind.us https://github.com/rust-lang/rust/pull/72062,MERGED,2020-05-09T20:16:21Z,2020-05-15T06:38:31Z,Add built in PSP target,overdrivenpotato,d01ee6f7f80098bf3550cc46c1a7a24cb83fd762,5,Rollup merge of #72062 - overdrivenpotato:psp r=jonas-schievink Add built in PSP target This adds a new target `mipsel-sony-psp` corresponding to the Sony PSP. The linker script is necessary to handle special sections which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended. The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD. The `stdarch` submodule was also updated in order for `libcore` to build successfully. [rust-psp]: https://github.com/overdrivenpotato/rust-psp [here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in,THUMBS_UP,2022-05-22T09:25:09Z,asmsuechan,suenagaryoutaabc@gmail.com https://github.com/rust-lang/rust/pull/72067,MERGED,2020-05-09T22:34:14Z,2020-05-12T02:44:46Z,Emit a warning when optimization fuel runs out,jonas-schievink,d9c3110ae84919d43004561490d50fac58f36299,5,Rollup merge of #72067 - jonas-schievink:fuel-warn r=varkor Emit a warning when optimization fuel runs out `eprintln!` gets swallowed by Cargo too easily.,THUMBS_UP,2020-05-28T03:16:48Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72079,MERGED,2020-05-10T12:23:45Z,2020-05-16T07:15:06Z,update stacker to 0.1.9 to unbreak build on OpenBSD,semarie,84539360498cab3c70a7c9114c0b8106c8e1b06b,2,Auto merge of #72079 - semarie:openbsd-stacker r=Mark-Simulacrum update stacker to 0.1.9 to unbreak build on OpenBSD the version 0.1.8 of stacker (what is currently pinned in Cargo.lock) doesn't build on OpenBSD (see https://github.com/rust-lang/stacker/pull/34). update the version to 0.1.9,THUMBS_UP,2020-05-10T14:10:01Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T13:20:21Z,mati865,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T13:21:03Z,cynecx,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T13:54:40Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T14:34:41Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T14:50:53Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-10T16:56:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HEART,2020-05-10T16:56:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-11T01:39:09Z,tesuji,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-11T22:26:00Z,jebrosen,jeb@jebrosen.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-13T03:01:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-05-30T15:09:35Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HEART,2020-06-07T14:12:09Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HEART,2020-06-07T15:04:17Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-06-07T15:04:21Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-06-07T19:21:36Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-06-09T11:55:51Z,LU15W1R7H,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-06-09T16:56:09Z,anandijain,NA https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HOORAY,2020-06-15T08:14:39Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/72080,MERGED,2020-05-10T12:39:56Z,2020-06-15T08:10:36Z,Clean up type alias impl trait implementation,matthewjasper,ce6d3a73b514e9649e57cee812ad129bb2112016,99,Auto merge of #72080 - matthewjasper:uniform-impl-trait r=nikomatsakis Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061,HEART,2020-06-15T15:18:11Z,estebank,NA https://github.com/rust-lang/rust/pull/72096,MERGED,2020-05-11T00:23:01Z,2020-05-12T13:59:33Z,Make MIR typeck use `LocalDefId` and fix docs,jonas-schievink,31e5be027e717eaedb51992a4c938f8aa9e7fdd1,4,Rollup merge of #72096 - jonas-schievink:mirck-docs r=matthewjasper Make MIR typeck use `LocalDefId` and fix docs The docs on `fn type_check` were not in sync with the arguments it takes. r? @matthewjasper,HEART,2020-05-11T17:22:35Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72103,MERGED,2020-05-11T08:32:48Z,2020-05-30T03:25:35Z,borrowck `DefId` -> `LocalDefId`,lcnr,e229d6e73b0a665aaad8802b8b9b66c1c4fef499,7,Rollup merge of #72103 - lcnr:borrowck-localdefid r=jonas-schievink borrowck `DefId` -> `LocalDefId` Replaces some `DefId`s which must always be local with `LocalDefId` in `librustc_mir/borrowck`. cc @marmeladema,HEART,2020-05-11T18:06:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72103,MERGED,2020-05-11T08:32:48Z,2020-05-30T03:25:35Z,borrowck `DefId` -> `LocalDefId`,lcnr,e229d6e73b0a665aaad8802b8b9b66c1c4fef499,7,Rollup merge of #72103 - lcnr:borrowck-localdefid r=jonas-schievink borrowck `DefId` -> `LocalDefId` Replaces some `DefId`s which must always be local with `LocalDefId` in `librustc_mir/borrowck`. cc @marmeladema,HEART,2020-05-27T15:54:56Z,estebank,NA https://github.com/rust-lang/rust/pull/72111,MERGED,2020-05-11T15:17:52Z,2020-05-21T15:02:45Z,rustc-book: Document `-Z strip=val` option,petrochenkov,e2c05d1e9cee5f01312ca787ca8afd4179251346,1,Rollup merge of #72111 - petrochenkov:docstrip r=ehuss rustc-book: Document `-Z strip=val` option cc https://github.com/rust-lang/rust/issues/72110,THUMBS_UP,2020-05-13T06:53:27Z,contrun,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-05-11T21:40:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-05-12T06:40:58Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-05-12T17:44:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-05-15T04:50:25Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-05-23T16:19:02Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-06-10T10:01:26Z,mati865,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-06-10T23:28:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-07-14T18:18:33Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-08-03T12:43:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72121,MERGED,2020-05-11T21:32:17Z,2020-07-27T03:40:35Z,Serialize span hygiene data,Aaron1011,fa36f960687c41caf5b260ab7610ebd83a7860dd,46,Auto merge of #72121 - Aaron1011:final-hygiene-rebase r=petrochenkov Serialize span hygiene data Fixes #68686 Fixes #70963 This PR serializies global hygiene data into both the incremental compilation cache and the crate metadata. This allows hygiene information to be preserved across compilation sessions (both incremental and cross-crate). When serializing a `SyntaxContext` we simply write out the raw id from the current compilation session. Whenever we deserialize a `SyntaxContext` we 'remap' the id to a fresh id in our current compilation session and load the associated `SyntaxContextData`. As a result some 'upstream' `SyntaxContextData` will end up getting duplicated in 'downstream' crates. This only happens when we actually need to use an 'upstream' `SyntaxContext` which occurs when we deserialize a `Span` that requires it. We serialize an `ExpnData` into the metadata of the crate which generated it. An `ExpnId` is serialized as a reference into the crate which 'owns' the corresponding `ExpnData` which avoids duplication in downstream crates. I've included a macros 2.0 test which requires hygiene serialization to compile successfully. TODO: - [x] Determine how many additional `DefId`s we end up creating for `ExpnId`s - this may be significant for `libcore` which uses macros heavily. Alternatively we could try to compute a `DefPathHash` without making a corresponding `DefId` - however this might significantly complicate the implementation. (We no longer create `DefId`s) - [x] Investigate the overhead of duplicating `SyntaxContextData` in crate metadata. - [x] Investigate how `resolve_crate_root` behaves with deserialized hygiene data - the current logic may be wrong. - [x] Add additional tests. The effects of this PR are usually only noticeable when working with headache-inducing macro expansions (e.g. macros expanding to macros) so there are lots of corner cases to test. - [x] Determine what to do about this: https://github.com/rust-lang/rust/blob/4774f9b523c942cb5c0236542b5bcac76f6b6b9a/src/librustc_resolve/build_reduced_graph.rs#L892 - [x] Determine if we need to do anything here - I think the fact that `src/test/ui/hygiene/cross_crate_hygiene.rs` passes means that this is working. https://github.com/rust-lang/rust/blob/3d5d0f898c2f3998e50c2180c6202f193c3acdbc/src/librustc_resolve/imports.rs#L1389-L1392,HOORAY,2020-10-13T21:22:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72123,MERGED,2020-05-12T00:26:39Z,2020-05-22T19:09:48Z,Stabilize process_set_argv0 feature for Unix,jsgf,53d0046983228f8f0df77ff6a05ba9bb227e8e33,4,Rollup merge of #72123 - jsgf:stabilize-arg0 r=sfackler Stabilize process_set_argv0 feature for Unix This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows but as far as I know nobody has. That can be done separately. Tracking issue: #66510,THUMBS_DOWN,2020-05-12T03:57:37Z,tesuji,NA https://github.com/rust-lang/rust/pull/72123,MERGED,2020-05-12T00:26:39Z,2020-05-22T19:09:48Z,Stabilize process_set_argv0 feature for Unix,jsgf,53d0046983228f8f0df77ff6a05ba9bb227e8e33,4,Rollup merge of #72123 - jsgf:stabilize-arg0 r=sfackler Stabilize process_set_argv0 feature for Unix This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows but as far as I know nobody has. That can be done separately. Tracking issue: #66510,THUMBS_UP,2020-05-13T21:38:30Z,mati865,NA https://github.com/rust-lang/rust/pull/72123,MERGED,2020-05-12T00:26:39Z,2020-05-22T19:09:48Z,Stabilize process_set_argv0 feature for Unix,jsgf,53d0046983228f8f0df77ff6a05ba9bb227e8e33,4,Rollup merge of #72123 - jsgf:stabilize-arg0 r=sfackler Stabilize process_set_argv0 feature for Unix This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows but as far as I know nobody has. That can be done separately. Tracking issue: #66510,THUMBS_UP,2020-05-28T03:33:37Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72141,MERGED,2020-05-12T15:40:50Z,2020-05-14T23:09:48Z,Warn against thread::sleep in async fn,kornelski,d732aeff914b9c3bf53ba1857ead33745c00c88a,1,Rollup merge of #72141 - kornelski:dontsleep r=joshtriplett Warn against thread::sleep in async fn I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](https://github.com/rust-lang/rust-clippy/issues/4377) but the std docs could warn against it too.,THUMBS_UP,2020-05-12T17:41:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72142,CLOSED,2020-05-12T16:31:17Z,2020-08-14T01:36:51Z,Defunctionalize spans for diagnostics,cjgillot,NA,NA,NA,HEART,2020-05-12T17:01:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72142,CLOSED,2020-05-12T16:31:17Z,2020-08-14T01:36:51Z,Defunctionalize spans for diagnostics,cjgillot,NA,NA,NA,HEART,2020-05-12T17:49:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72142,CLOSED,2020-05-12T16:31:17Z,2020-08-14T01:36:51Z,Defunctionalize spans for diagnostics,cjgillot,NA,NA,NA,HEART,2020-05-12T21:21:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T00:54:06Z,Florob,NA https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T01:55:47Z,comex,NA https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T04:34:20Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T07:53:33Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T10:10:02Z,jamesmcm,jamesmcm03@gmail.com https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T13:19:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-13T13:25:36Z,antonok-edm,NA https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-14T21:54:29Z,LovecraftianHorror,LovecraftianHorror@pm.me https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-18T11:13:11Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/72143,MERGED,2020-05-12T16:43:31Z,2020-05-18T11:11:37Z,make offset must_use,steveklabnik,2a9066479859f4aa22a08c71cd03f9b06ec99b7c,3,Rollup merge of #72143 - rust-lang:steveklabnik-must-use r=sfackler make offset must_use https://djugei.github.io/bad-at-unsafe/ describes an error a user had when trying to use offset: > At first I just assumed that the .add() and .offset() methods on pointers would mutate the pointer. They do not. Instead they return a new pointer which gets dropped silently if you don't use it. Unlike for example Result which is must_use annotated. This PR only adds `offset` because I wanted to float the idea; I'm imagining that there's more than just `add` and `offset` that could use this. I am also very open to re-wording the warning. r? @rust-lang/libs,THUMBS_UP,2020-05-21T06:41:40Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72150,MERGED,2020-05-12T18:20:18Z,2020-05-14T16:06:29Z,Remove UnnormalizedProjection,jackh726,e5f31e0a3eb8d839f1e3b7db8ce7f5c685e4bc0c,39,Rollup merge of #72150 - jackh726:unnorm_projection r=nikomatsakis Remove UnnormalizedProjection This was only used for the old chalk integration with chalk-engine r? @nikomatsakis,HEART,2020-05-12T21:18:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/72152,CLOSED,2020-05-12T18:30:00Z,2020-06-09T09:59:07Z,Fix leaks from panics in drops,matthewjasper,NA,NA,NA,HEART,2020-05-12T22:07:28Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72152,CLOSED,2020-05-12T18:30:00Z,2020-06-09T09:59:07Z,Fix leaks from panics in drops,matthewjasper,NA,NA,NA,THUMBS_UP,2020-05-13T18:43:34Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72152,CLOSED,2020-05-12T18:30:00Z,2020-06-09T09:59:07Z,Fix leaks from panics in drops,matthewjasper,NA,NA,NA,THUMBS_UP,2020-06-06T13:49:50Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/72153,MERGED,2020-05-12T20:30:02Z,2020-05-25T20:54:48Z,exhaustively check `ty::Kind` during structural match checking,lcnr,d5250c160a9bb463d08a0073962fdd68e33391b4,6,Rollup merge of #72153 - lcnr:exhaustively-match r=pnkfelix exhaustively check `ty::Kind` during structural match checking This was prone to errors as we may forget new kinds in the future. I am also not yet sure about some kinds. `ty::GeneratorWitness(..) | ty::Infer(_) | ty::Placeholder(_) | ty::UnnormalizedProjection(..) | ty::Bound(..)` might be unreachable here. We may want to forbid `ty::Projection` similar to `ty::Param`. `ty::Opaque` seems fine afaict should not be possible in a match atm. I believe `ty::Foreign` should not be structurally match as I don't even know what that would actually mean. r? @pnkfelix cc @eddyb,HEART,2020-05-12T20:33:50Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72161,MERGED,2020-05-13T01:50:47Z,2020-05-22T14:49:01Z,Replace fcntl-based file lock with flock,nbdd0121,a8018e224efa8aef9e6a8c9b8a74dc67c225d51d,1,Rollup merge of #72161 - nbdd0121:master r=cuviper Replace fcntl-based file lock with flock WSL1 does not support `fcntl`-based lock and will always report success therefore creating a race condition when multiple rustc processes are modifying shared data such as `search-index.js`. WSL1 does however support `flock`. `flock` is supported by all unix-like platforms. The only caveat is that Linux 2.6.11 or earlier does not support `flock` on NFS mounts but as the minimum supported Linux version is 2.6.18 it is not an issue. Fixes #72157,HEART,2020-05-14T14:04:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72164,CLOSED,2020-05-13T06:18:57Z,2020-06-11T21:05:08Z,[WIP] Run the unused variables lint on the MIR,ecstatic-morse,NA,NA,NA,HOORAY,2020-05-13T08:48:25Z,tesuji,NA https://github.com/rust-lang/rust/pull/72164,CLOSED,2020-05-13T06:18:57Z,2020-06-11T21:05:08Z,[WIP] Run the unused variables lint on the MIR,ecstatic-morse,NA,NA,NA,HEART,2020-05-13T14:50:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72164,CLOSED,2020-05-13T06:18:57Z,2020-06-11T21:05:08Z,[WIP] Run the unused variables lint on the MIR,ecstatic-morse,NA,NA,NA,HOORAY,2020-05-13T17:18:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72164,CLOSED,2020-05-13T06:18:57Z,2020-06-11T21:05:08Z,[WIP] Run the unused variables lint on the MIR,ecstatic-morse,NA,NA,NA,HOORAY,2020-05-13T17:21:02Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/72164,CLOSED,2020-05-13T06:18:57Z,2020-06-11T21:05:08Z,[WIP] Run the unused variables lint on the MIR,ecstatic-morse,NA,NA,NA,HOORAY,2020-05-13T23:44:58Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72166,MERGED,2020-05-13T07:58:36Z,2020-05-16T17:44:33Z,Simpler slice `Iterator` methods,nnethercote,e8f0fb1f1359d042e165b92a9c1053424b77a459,2,Rollup merge of #72166 - nnethercote:simpler-slice-Iterator-methods r=cuviper Simpler slice `Iterator` methods These reduce the amount of LLVM IR generated helping compile times. r? @cuviper,THUMBS_UP,2020-05-13T20:51:11Z,bluss,NA https://github.com/rust-lang/rust/pull/72166,MERGED,2020-05-13T07:58:36Z,2020-05-16T17:44:33Z,Simpler slice `Iterator` methods,nnethercote,e8f0fb1f1359d042e165b92a9c1053424b77a459,2,Rollup merge of #72166 - nnethercote:simpler-slice-Iterator-methods r=cuviper Simpler slice `Iterator` methods These reduce the amount of LLVM IR generated helping compile times. r? @cuviper,HEART,2020-05-14T01:44:52Z,hbina,hanif.ariffin.4326@gmail.com https://github.com/rust-lang/rust/pull/72166,MERGED,2020-05-13T07:58:36Z,2020-05-16T17:44:33Z,Simpler slice `Iterator` methods,nnethercote,e8f0fb1f1359d042e165b92a9c1053424b77a459,2,Rollup merge of #72166 - nnethercote:simpler-slice-Iterator-methods r=cuviper Simpler slice `Iterator` methods These reduce the amount of LLVM IR generated helping compile times. r? @cuviper,HEART,2020-05-20T17:51:57Z,Terkwood,NA https://github.com/rust-lang/rust/pull/72166,MERGED,2020-05-13T07:58:36Z,2020-05-16T17:44:33Z,Simpler slice `Iterator` methods,nnethercote,e8f0fb1f1359d042e165b92a9c1053424b77a459,2,Rollup merge of #72166 - nnethercote:simpler-slice-Iterator-methods r=cuviper Simpler slice `Iterator` methods These reduce the amount of LLVM IR generated helping compile times. r? @cuviper,HEART,2020-05-21T06:51:52Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72170,MERGED,2020-05-13T12:50:48Z,2020-05-14T23:09:44Z,use `require_lang_item` over `unwrap`.,lcnr,62f184030ab9da2c3acd95d3f7f94c4bc1820b07,11,Rollup merge of #72170 - lcnr:lang_item r=oli-obk use `require_lang_item` over `unwrap`. Does not yet replace all uses of `lang_items\(\)\.*\.unwrap\(\)` as there are more than I expected :sweat_smile: Fixes #72099 r? @RalfJung *edit: The goal of this this PR is to change ICE from missing lang items to a fatal error.*,HEART,2020-05-14T19:35:57Z,bjorn3,NA https://github.com/rust-lang/rust/pull/72170,MERGED,2020-05-13T12:50:48Z,2020-05-14T23:09:44Z,use `require_lang_item` over `unwrap`.,lcnr,62f184030ab9da2c3acd95d3f7f94c4bc1820b07,11,Rollup merge of #72170 - lcnr:lang_item r=oli-obk use `require_lang_item` over `unwrap`. Does not yet replace all uses of `lang_items\(\)\.*\.unwrap\(\)` as there are more than I expected :sweat_smile: Fixes #72099 r? @RalfJung *edit: The goal of this this PR is to change ICE from missing lang items to a fatal error.*,HEART,2020-05-14T21:19:36Z,jaybosamiya,NA https://github.com/rust-lang/rust/pull/72178,MERGED,2020-05-13T20:58:55Z,2020-05-17T01:31:22Z,Consistently use LLVM lifetime markers during codegen,tmiasko,0ec4b065243f38f711a55563bff7d0c66eea1b4a,7,Auto merge of #72178 - tmiasko:inliner-lifetimes r=nikic Consistently use LLVM lifetime markers during codegen Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together lifetime markers from one function might invalidate load & stores performed by the other one. Fixes #72154.,HEART,2020-05-14T03:27:25Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-14T21:47:01Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-15T00:18:46Z,mati865,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-15T02:01:10Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-15T02:21:22Z,tesuji,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-15T09:34:32Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-15T12:24:14Z,bugadani,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-15T14:49:58Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-15T16:47:01Z,bluss,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-15T23:03:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-15T23:03:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-16T14:23:54Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-16T14:54:24Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-16T16:01:40Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-16T16:55:37Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-16T17:54:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-17T03:48:40Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-17T05:50:03Z,est31,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-17T05:50:06Z,est31,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-05-17T09:54:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-17T09:59:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-17T16:57:10Z,g2p,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-17T17:28:25Z,RustyYato,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-18T00:21:15Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-18T10:56:41Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-19T11:41:20Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-05-19T11:41:22Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-19T15:26:59Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-20T14:17:09Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-20T14:20:56Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-20T14:21:01Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-20T14:21:01Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-05-20T14:21:04Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-21T10:44:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-21T13:25:57Z,95th,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-21T13:25:58Z,95th,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-05-21T13:26:00Z,95th,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-21T13:26:01Z,95th,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-22T18:12:55Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-23T07:01:38Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-23T16:49:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-28T21:38:24Z,tmandry,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-29T13:47:39Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-29T14:36:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-05-29T14:36:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-29T15:10:56Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-05-30T09:45:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-05-30T09:45:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-30T11:33:04Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-05-31T15:27:02Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-07-13T09:11:00Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",THUMBS_UP,2020-09-20T20:43:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-09-20T20:43:15Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HEART,2020-09-20T20:43:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-09-20T20:43:19Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",HOORAY,2020-09-24T22:02:12Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/72205,MERGED,2020-05-14T17:18:19Z,2020-05-21T10:28:11Z,Dumb NRVO,ecstatic-morse,7f79e98c0356642db62e5113327e436c951e843d,13,"Auto merge of #72205 - ecstatic-morse:nrvo r=oli-obk Dumb NRVO This is a very simple version of an NRVO pass which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place we bail out. This avoids running a full ""reaching definitions"" dataflow analysis. I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges. r? @ghost",ROCKET,2020-09-24T22:02:14Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,HEART,2020-09-03T00:20:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,HEART,2020-09-15T19:21:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,THUMBS_UP,2020-11-02T20:25:19Z,Lokathor,NA https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,HEART,2020-11-30T01:40:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,THUMBS_UP,2021-01-19T15:33:25Z,anderejd,NA https://github.com/rust-lang/rust/pull/72209,MERGED,2020-05-14T19:08:29Z,2021-02-09T08:47:55Z,Add checking for no_mangle to unsafe_code lint,Nemo157,f8b330d9fb114132fb41eccdafbe29b48d386749,3,Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code r=nikomatsakis Add checking for no_mangle to unsafe_code lint fixes #72188 r? `@estebank`,HEART,2021-02-23T21:19:57Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-15T08:04:07Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-15T15:48:45Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-15T16:53:24Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-15T22:59:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-15T22:59:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-16T00:43:50Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-16T00:44:28Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-17T08:57:21Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-18T08:15:37Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-18T20:45:13Z,swarnimarun,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-19T14:08:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-19T20:57:53Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-19T21:01:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-20T13:40:42Z,kirushik,kirill@parity.io https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-27T21:00:52Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-27T21:31:45Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-27T21:31:48Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-28T03:28:31Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-28T08:12:43Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-28T08:12:44Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-28T10:02:33Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-28T13:09:17Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-28T19:17:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-28T22:34:36Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",ROCKET,2020-05-29T03:09:26Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-05-29T17:31:43Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-06-12T16:30:10Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2020-11-17T11:29:34Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/72227,MERGED,2020-05-15T07:20:25Z,2020-05-19T18:32:53Z,Tiny Vecs are dumb.,nnethercote,672b272077561ca7b5027a8aff9ea2957c7d4c21,3,"Auto merge of #72227 - nnethercote:tiny-vecs-are-dumb r=Amanieu Tiny Vecs are dumb. Currently if you repeatedly push to an empty vector the capacity growth sequence is 0 1 2 4 8 16 etc. This commit changes the relevant code (the ""amortized"" growth strategy) to skip 1 and 2 instead using 0 4 8 16 etc. (You can still get a capacity of 1 or 2 using the ""exact"" growth strategy e.g. via `reserve_exact()`.) This idea (along with the phrase ""tiny Vecs are dumb"") comes from the ""doubling"" growth strategy that was removed from `RawVec` in #72013. That strategy was barely ever used -- only when a `VecDeque` was grown oddly enough -- which is why it was removed in #72013. (Fun fact: until just a few days ago I thought the ""doubling"" strategy was used for repeated push case. In other words this commit makes `Vec`s behave the way I always thought they behaved.) This change reduces the number of allocations done by rustc itself by 10% or more. It speeds up rustc and will also speed up any other Rust program that uses `Vec`s a lot. In theory the change could increase memory usage but in practice it doesn't. It would be an unusual program where very small `Vec`s having a capacity of 4 rather than 1 or 2 would make a difference. You'd need a *lot* of very small `Vec`s and/or some very small `Vec`s with very large elements. r? @Amanieu",THUMBS_UP,2022-01-18T15:22:07Z,pro465,NA https://github.com/rust-lang/rust/pull/72234,MERGED,2020-05-15T16:14:40Z,2020-05-16T17:44:27Z,Implement Default for proc_macro::TokenStream,dtolnay,25c91ea20673117e80b1fb8fb1b5bbf227747f68,1,Rollup merge of #72234 - dtolnay:default r=petrochenkov Implement Default for proc_macro::TokenStream Hopefully this is uncontroversial. The only reason we've made it this far without is that proc-macro2 snuck this in for their TokenStream.,THUMBS_UP,2020-05-15T16:17:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72234,MERGED,2020-05-15T16:14:40Z,2020-05-16T17:44:27Z,Implement Default for proc_macro::TokenStream,dtolnay,25c91ea20673117e80b1fb8fb1b5bbf227747f68,1,Rollup merge of #72234 - dtolnay:default r=petrochenkov Implement Default for proc_macro::TokenStream Hopefully this is uncontroversial. The only reason we've made it this far without is that proc-macro2 snuck this in for their TokenStream.,THUMBS_UP,2020-05-23T09:11:38Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/72234,MERGED,2020-05-15T16:14:40Z,2020-05-16T17:44:27Z,Implement Default for proc_macro::TokenStream,dtolnay,25c91ea20673117e80b1fb8fb1b5bbf227747f68,1,Rollup merge of #72234 - dtolnay:default r=petrochenkov Implement Default for proc_macro::TokenStream Hopefully this is uncontroversial. The only reason we've made it this far without is that proc-macro2 snuck this in for their TokenStream.,THUMBS_UP,2020-07-20T08:30:20Z,elichai,NA https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,HEART,2020-05-16T05:27:07Z,panaman67,NA https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,THUMBS_UP,2020-05-16T05:27:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,HEART,2020-05-16T15:56:57Z,estebank,NA https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,THUMBS_UP,2020-05-23T05:54:25Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,THUMBS_UP,2020-05-23T10:04:42Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,HEART,2020-05-28T03:11:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72256,MERGED,2020-05-16T05:12:14Z,2020-05-23T07:18:42Z,Use `once_cell` crate instead of custom data structure,ecstatic-morse,7f940ef5d91b53e889f111f27e00849f2f5ae4a2,43,Auto merge of #72256 - ecstatic-morse:once-cell r=Mark-Simulacrum Use `once_cell` crate instead of custom data structure Internally we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one. This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver` is owned by a well-known community member (cc @matklad) and has a stable release. cc @rust-lang/compiler `once_cell` has a slightly more minimal API than `Once` which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`. r? @Mark-Simulacrum,THUMBS_UP,2020-05-29T17:29:37Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72279,MERGED,2020-05-16T18:20:34Z,2020-06-19T05:04:18Z,add raw_ref macros,RalfJung,49ab0cab618d9d1cb49220d7c253556a56148283,2,Rollup merge of #72279 - RalfJung:raw-ref-macros r=nikomatsakis add raw_ref macros In https://github.com/rust-lang/rust/issues/64490 various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros. I'll create the tracking issue if we're okay moving forward with this.,HEART,2020-06-16T10:53:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/72280,MERGED,2020-05-16T18:45:15Z,2020-06-19T16:02:26Z,Fix up autoderef when reborrowing,nbdd0121,70622db43d5e0a58f8fe66ff15115e4fcbb5c274,10,Rollup merge of #72280 - nbdd0121:typeck r=nikomatsakis Fix up autoderef when reborrowing Currently `(f)()` and `f.call_mut()` behaves differently if expression `f` contains autoderef in it. This causes a weird error in #72225. When `f` is type checked `Deref` is used (this is expected as we can't yet determine if we should use `Fn` or `FnMut`). When subsequently we determine the actual trait to be used when using the `f.call_mut()` syntax the `Deref` is patched to `DerefMut` while for the `(f)()` syntax case it is not. This PR replicates the fixup for the first case. Fixes #72225 Fixes #68590,HEART,2020-05-17T04:06:53Z,estebank,NA https://github.com/rust-lang/rust/pull/72280,MERGED,2020-05-16T18:45:15Z,2020-06-19T16:02:26Z,Fix up autoderef when reborrowing,nbdd0121,70622db43d5e0a58f8fe66ff15115e4fcbb5c274,10,Rollup merge of #72280 - nbdd0121:typeck r=nikomatsakis Fix up autoderef when reborrowing Currently `(f)()` and `f.call_mut()` behaves differently if expression `f` contains autoderef in it. This causes a weird error in #72225. When `f` is type checked `Deref` is used (this is expected as we can't yet determine if we should use `Fn` or `FnMut`). When subsequently we determine the actual trait to be used when using the `f.call_mut()` syntax the `Deref` is patched to `DerefMut` while for the `(f)()` syntax case it is not. This PR replicates the fixup for the first case. Fixes #72225 Fixes #68590,ROCKET,2020-05-17T04:06:55Z,estebank,NA https://github.com/rust-lang/rust/pull/72280,MERGED,2020-05-16T18:45:15Z,2020-06-19T16:02:26Z,Fix up autoderef when reborrowing,nbdd0121,70622db43d5e0a58f8fe66ff15115e4fcbb5c274,10,Rollup merge of #72280 - nbdd0121:typeck r=nikomatsakis Fix up autoderef when reborrowing Currently `(f)()` and `f.call_mut()` behaves differently if expression `f` contains autoderef in it. This causes a weird error in #72225. When `f` is type checked `Deref` is used (this is expected as we can't yet determine if we should use `Fn` or `FnMut`). When subsequently we determine the actual trait to be used when using the `f.call_mut()` syntax the `Deref` is patched to `DerefMut` while for the `(f)()` syntax case it is not. This PR replicates the fixup for the first case. Fixes #72225 Fixes #68590,HEART,2020-05-17T04:22:57Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/72283,MERGED,2020-05-16T21:01:15Z,2020-05-19T02:16:01Z,Drop Elaboration Elaboration,jonas-schievink,4adb9a85c32e56ee4e9bcd48c96b791150b469ad,2,Rollup merge of #72283 - jonas-schievink:elaborate-drop-elaboration r=cramertj Drop Elaboration Elaboration As in adding more documentation to it.,LAUGH,2020-05-16T22:14:52Z,bluss,NA https://github.com/rust-lang/rust/pull/72283,MERGED,2020-05-16T21:01:15Z,2020-05-19T02:16:01Z,Drop Elaboration Elaboration,jonas-schievink,4adb9a85c32e56ee4e9bcd48c96b791150b469ad,2,Rollup merge of #72283 - jonas-schievink:elaborate-drop-elaboration r=cramertj Drop Elaboration Elaboration As in adding more documentation to it.,LAUGH,2020-05-16T22:21:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72283,MERGED,2020-05-16T21:01:15Z,2020-05-19T02:16:01Z,Drop Elaboration Elaboration,jonas-schievink,4adb9a85c32e56ee4e9bcd48c96b791150b469ad,2,Rollup merge of #72283 - jonas-schievink:elaborate-drop-elaboration r=cramertj Drop Elaboration Elaboration As in adding more documentation to it.,LAUGH,2020-05-17T21:14:23Z,CryZe,NA https://github.com/rust-lang/rust/pull/72283,MERGED,2020-05-16T21:01:15Z,2020-05-19T02:16:01Z,Drop Elaboration Elaboration,jonas-schievink,4adb9a85c32e56ee4e9bcd48c96b791150b469ad,2,Rollup merge of #72283 - jonas-schievink:elaborate-drop-elaboration r=cramertj Drop Elaboration Elaboration As in adding more documentation to it.,LAUGH,2020-05-18T16:37:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72287,MERGED,2020-05-17T03:26:36Z,2020-05-25T01:42:35Z,Store tokens inside `ast::Expr`,Aaron1011,62da38d00d8d09dbaaa092c7b5e7ea343fdc2126,16,Auto merge of #72287 - Aaron1011:feature/min-token-collect r=petrochenkov Store tokens inside `ast::Expr` This is a smaller version of #70091. We now store captured tokens inside `ast::Expr` which allows us to avoid some reparsing in `nt_to_tokenstream`. To try to mitigate the performance impact we only collect tokens when we've seen an outer attribute. This makes progress towards solving #43081. There are still many things left to do: * Collect tokens for other AST items. * Come up with a way to handle inner attributes (we need to be collecting tokens by the time we encounter them) * Avoid re-parsing when a `#[cfg]` attr is used. However this is enough to fix spans for a simple example which I've included as a test case.,HEART,2020-05-19T22:15:08Z,estebank,NA https://github.com/rust-lang/rust/pull/72287,MERGED,2020-05-17T03:26:36Z,2020-05-25T01:42:35Z,Store tokens inside `ast::Expr`,Aaron1011,62da38d00d8d09dbaaa092c7b5e7ea343fdc2126,16,Auto merge of #72287 - Aaron1011:feature/min-token-collect r=petrochenkov Store tokens inside `ast::Expr` This is a smaller version of #70091. We now store captured tokens inside `ast::Expr` which allows us to avoid some reparsing in `nt_to_tokenstream`. To try to mitigate the performance impact we only collect tokens when we've seen an outer attribute. This makes progress towards solving #43081. There are still many things left to do: * Collect tokens for other AST items. * Come up with a way to handle inner attributes (we need to be collecting tokens by the time we encounter them) * Avoid re-parsing when a `#[cfg]` attr is used. However this is enough to fix spans for a simple example which I've included as a test case.,HEART,2020-05-19T22:45:20Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72287,MERGED,2020-05-17T03:26:36Z,2020-05-25T01:42:35Z,Store tokens inside `ast::Expr`,Aaron1011,62da38d00d8d09dbaaa092c7b5e7ea343fdc2126,16,Auto merge of #72287 - Aaron1011:feature/min-token-collect r=petrochenkov Store tokens inside `ast::Expr` This is a smaller version of #70091. We now store captured tokens inside `ast::Expr` which allows us to avoid some reparsing in `nt_to_tokenstream`. To try to mitigate the performance impact we only collect tokens when we've seen an outer attribute. This makes progress towards solving #43081. There are still many things left to do: * Collect tokens for other AST items. * Come up with a way to handle inner attributes (we need to be collecting tokens by the time we encounter them) * Avoid re-parsing when a `#[cfg]` attr is used. However this is enough to fix spans for a simple example which I've included as a test case.,HEART,2020-05-20T03:03:34Z,95th,NA https://github.com/rust-lang/rust/pull/72287,MERGED,2020-05-17T03:26:36Z,2020-05-25T01:42:35Z,Store tokens inside `ast::Expr`,Aaron1011,62da38d00d8d09dbaaa092c7b5e7ea343fdc2126,16,Auto merge of #72287 - Aaron1011:feature/min-token-collect r=petrochenkov Store tokens inside `ast::Expr` This is a smaller version of #70091. We now store captured tokens inside `ast::Expr` which allows us to avoid some reparsing in `nt_to_tokenstream`. To try to mitigate the performance impact we only collect tokens when we've seen an outer attribute. This makes progress towards solving #43081. There are still many things left to do: * Collect tokens for other AST items. * Come up with a way to handle inner attributes (we need to be collecting tokens by the time we encounter them) * Avoid re-parsing when a `#[cfg]` attr is used. However this is enough to fix spans for a simple example which I've included as a test case.,HEART,2020-05-21T02:04:50Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/72288,MERGED,2020-05-17T06:32:25Z,2020-05-29T11:17:26Z,Stabilization of weak-into-raw,vorner,d472f8e4624277163f33f9070bf0474669d3844e,2,Rollup merge of #72288 - vorner:stabilize-weak-into-raw r=dtolnay Stabilization of weak-into-raw Closes #60728. There are also two removals of `#![feature(weak_into_raw)]` in the `src/tools/miri` submodule. How should I synchronize the changes with there? * I can ignore it for now and once this gets merged update the tool send a pull request to that one and then reference the changes to rustc. * I could try submitting the changes to miri first but then the build would fail there because the attribute would still be needed. I think the first one is the correct one extrapolating from the contributing guidelines (even though they speak about breaking the tools and this should not break it as extra feature should not hurt).,CONFUSED,2020-06-04T03:26:57Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72292,MERGED,2020-05-17T10:21:50Z,2020-05-23T21:22:04Z,Replace obligation construction with deref_steps(),ldm0,b24030fc3ef21bb0f23a5ea8fc47d9684a4e27a6,2,"Rollup merge of #72292 - ldm0:derefsteps r=estebank Replace obligation construction with deref_steps() 1. Use `probe()` to avoid unwanted binding committing during `deref_steps()`. 2. Fixes #59819 again by using `deref_steps()` make the code cleaner. And if we want to suggest multiple dereferences (like: `consider dereferencing the borrow: ""****a""`) in the future this change will make it easier to achieve.",HEART,2020-05-22T20:05:07Z,estebank,NA https://github.com/rust-lang/rust/pull/72306,MERGED,2020-05-17T19:55:19Z,2020-05-22T14:48:52Z,Break tokens before checking if they are 'probably equal',Aaron1011,62d4e9eedd384c3a32c55dad71dc04c8891d550e,5,Rollup merge of #72306 - Aaron1011:feature/turbo-spacing r=petrochenkov Break tokens before checking if they are 'probably equal' Fixes #68489 Fixes #70987 When checking two `TokenStreams` to see if they are 'probably equal' we ignore the `IsJoint` information associated with each `TokenTree`. However the `IsJoint` information determines whether adjacent tokens will be 'glued' (if possible) when construction the `TokenStream` - e.g. `[Gt Gt]` can be 'glued' to `BinOp(Shr)`. Since we are ignoring the `IsJoint` information 'glued' and 'unglued' tokens are equivalent for determining if two `TokenStreams` are 'probably equal'. Therefore we need to 'unglue' all tokens in the stream to avoid false negatives (which cause us to throw out the cached tokens losing span information).,HEART,2020-05-22T14:56:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/72310,MERGED,2020-05-18T00:27:57Z,2020-05-29T23:44:07Z,Add Peekable::next_if,jyn514,cbcc4c4f05cef62d283d7205bd00ce7d7adcfec6,3,Rollup merge of #72310 - jyn514:peekable-next-if r=dtolnay Add Peekable::next_if Prior art: `rust_analyzer` uses [`Parser::eat`](https://github.com/rust-analyzer/rust-analyzer/blob/50f4ae798b7c54d417ee88455b87fd0477473150/crates/ra_parser/src/parser.rs#L94) which is `next_if` specialized to `|y| self.next_if(|x| x == y)`. Basically every other parser I've run into in Rust has an equivalent of `Parser::eat`; see for example - [cranelift](https://github.com/bytecodealliance/wasmtime/blob/94190d57244b26baf36629c88104b0ba516510cf/cranelift/reader/src/parser.rs#L498) - [rcc](https://github.com/jyn514/rcc/blob/a8159c3904a0c950fbba817bf9109023fad69033/src/parse/mod.rs#L231) - [crunch](https://github.com/Kixiron/crunch-lang/blob/8521874fab8a7d62bfa7dea8bd1da94b63e31be8/crates/crunch-parser/src/parser/mod.rs#L213-L241) Possible extensions: A specialization of `next_if` to using `Eq::eq`. The only difficulty here is the naming - maybe `next_if_eq`? Alternatives: - Instead of `func: impl FnOnce(&I::Item) -> bool` use `func: impl FnOnce(I::Item) -> Option`. This has the advantage that `func` can move the value if necessary but means that there is no guarantee `func` will return the same value it was given. - Instead of `fn next_if(...) -> Option` use `fn next_if(...) -> bool`. This makes the common case of `iter.next_if(f).is_some()` easier but makes the unusual case impossible. Bikeshedding on naming: - `next_if` could be renamed to `consume_if` (to match `eat` but a little more formally) - `next_if_eq` could be renamed to `consume`. This is more concise but less self-explanatory if you haven't written a lot of parsers. - Both of the above but with `consume` replaced by `eat`.,THUMBS_UP,2020-05-18T01:50:55Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/72310,MERGED,2020-05-18T00:27:57Z,2020-05-29T23:44:07Z,Add Peekable::next_if,jyn514,cbcc4c4f05cef62d283d7205bd00ce7d7adcfec6,3,Rollup merge of #72310 - jyn514:peekable-next-if r=dtolnay Add Peekable::next_if Prior art: `rust_analyzer` uses [`Parser::eat`](https://github.com/rust-analyzer/rust-analyzer/blob/50f4ae798b7c54d417ee88455b87fd0477473150/crates/ra_parser/src/parser.rs#L94) which is `next_if` specialized to `|y| self.next_if(|x| x == y)`. Basically every other parser I've run into in Rust has an equivalent of `Parser::eat`; see for example - [cranelift](https://github.com/bytecodealliance/wasmtime/blob/94190d57244b26baf36629c88104b0ba516510cf/cranelift/reader/src/parser.rs#L498) - [rcc](https://github.com/jyn514/rcc/blob/a8159c3904a0c950fbba817bf9109023fad69033/src/parse/mod.rs#L231) - [crunch](https://github.com/Kixiron/crunch-lang/blob/8521874fab8a7d62bfa7dea8bd1da94b63e31be8/crates/crunch-parser/src/parser/mod.rs#L213-L241) Possible extensions: A specialization of `next_if` to using `Eq::eq`. The only difficulty here is the naming - maybe `next_if_eq`? Alternatives: - Instead of `func: impl FnOnce(&I::Item) -> bool` use `func: impl FnOnce(I::Item) -> Option`. This has the advantage that `func` can move the value if necessary but means that there is no guarantee `func` will return the same value it was given. - Instead of `fn next_if(...) -> Option` use `fn next_if(...) -> bool`. This makes the common case of `iter.next_if(f).is_some()` easier but makes the unusual case impossible. Bikeshedding on naming: - `next_if` could be renamed to `consume_if` (to match `eat` but a little more formally) - `next_if_eq` could be renamed to `consume`. This is more concise but less self-explanatory if you haven't written a lot of parsers. - Both of the above but with `consume` replaced by `eat`.,THUMBS_UP,2020-05-22T03:05:40Z,Yurihaia,NA https://github.com/rust-lang/rust/pull/72310,MERGED,2020-05-18T00:27:57Z,2020-05-29T23:44:07Z,Add Peekable::next_if,jyn514,cbcc4c4f05cef62d283d7205bd00ce7d7adcfec6,3,Rollup merge of #72310 - jyn514:peekable-next-if r=dtolnay Add Peekable::next_if Prior art: `rust_analyzer` uses [`Parser::eat`](https://github.com/rust-analyzer/rust-analyzer/blob/50f4ae798b7c54d417ee88455b87fd0477473150/crates/ra_parser/src/parser.rs#L94) which is `next_if` specialized to `|y| self.next_if(|x| x == y)`. Basically every other parser I've run into in Rust has an equivalent of `Parser::eat`; see for example - [cranelift](https://github.com/bytecodealliance/wasmtime/blob/94190d57244b26baf36629c88104b0ba516510cf/cranelift/reader/src/parser.rs#L498) - [rcc](https://github.com/jyn514/rcc/blob/a8159c3904a0c950fbba817bf9109023fad69033/src/parse/mod.rs#L231) - [crunch](https://github.com/Kixiron/crunch-lang/blob/8521874fab8a7d62bfa7dea8bd1da94b63e31be8/crates/crunch-parser/src/parser/mod.rs#L213-L241) Possible extensions: A specialization of `next_if` to using `Eq::eq`. The only difficulty here is the naming - maybe `next_if_eq`? Alternatives: - Instead of `func: impl FnOnce(&I::Item) -> bool` use `func: impl FnOnce(I::Item) -> Option`. This has the advantage that `func` can move the value if necessary but means that there is no guarantee `func` will return the same value it was given. - Instead of `fn next_if(...) -> Option` use `fn next_if(...) -> bool`. This makes the common case of `iter.next_if(f).is_some()` easier but makes the unusual case impossible. Bikeshedding on naming: - `next_if` could be renamed to `consume_if` (to match `eat` but a little more formally) - `next_if_eq` could be renamed to `consume`. This is more concise but less self-explanatory if you haven't written a lot of parsers. - Both of the above but with `consume` replaced by `eat`.,THUMBS_UP,2021-01-15T03:56:11Z,stshine,NA https://github.com/rust-lang/rust/pull/72314,CLOSED,2020-05-18T03:10:01Z,2020-09-23T18:25:54Z,Stability annotations on generic parameters (take 2),Avi-D-coder,NA,NA,NA,HEART,2020-05-21T22:59:36Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/72314,CLOSED,2020-05-18T03:10:01Z,2020-09-23T18:25:54Z,Stability annotations on generic parameters (take 2),Avi-D-coder,NA,NA,NA,EYES,2020-06-09T17:31:15Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/72324,MERGED,2020-05-18T14:19:15Z,2020-05-29T11:17:23Z,Stabilize AtomicN::fetch_min and AtomicN::fetch_max,Amanieu,986c60c78b4aa548aa78570a08b2c51bc16dcbb7,1,Rollup merge of #72324 - Amanieu:atomic_minmax r=dtolnay Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.,HEART,2020-05-18T14:35:54Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/72324,MERGED,2020-05-18T14:19:15Z,2020-05-29T11:17:23Z,Stabilize AtomicN::fetch_min and AtomicN::fetch_max,Amanieu,986c60c78b4aa548aa78570a08b2c51bc16dcbb7,1,Rollup merge of #72324 - Amanieu:atomic_minmax r=dtolnay Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.,HEART,2020-05-19T16:58:54Z,Speedy37,vincent@speedy37.fr https://github.com/rust-lang/rust/pull/72324,MERGED,2020-05-18T14:19:15Z,2020-05-29T11:17:23Z,Stabilize AtomicN::fetch_min and AtomicN::fetch_max,Amanieu,986c60c78b4aa548aa78570a08b2c51bc16dcbb7,1,Rollup merge of #72324 - Amanieu:atomic_minmax r=dtolnay Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.,THUMBS_UP,2020-05-28T03:32:25Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72324,MERGED,2020-05-18T14:19:15Z,2020-05-29T11:17:23Z,Stabilize AtomicN::fetch_min and AtomicN::fetch_max,Amanieu,986c60c78b4aa548aa78570a08b2c51bc16dcbb7,1,Rollup merge of #72324 - Amanieu:atomic_minmax r=dtolnay Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.,THUMBS_UP,2020-06-05T17:45:26Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72324,MERGED,2020-05-18T14:19:15Z,2020-05-29T11:17:23Z,Stabilize AtomicN::fetch_min and AtomicN::fetch_max,Amanieu,986c60c78b4aa548aa78570a08b2c51bc16dcbb7,1,Rollup merge of #72324 - Amanieu:atomic_minmax r=dtolnay Stabilize AtomicN::fetch_min and AtomicN::fetch_max Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.,THUMBS_UP,2020-06-09T03:31:26Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/72338,MERGED,2020-05-18T21:02:54Z,2020-05-19T15:12:14Z,Fix ICE in -Zsave-analysis,doctorn,817880842c268ecedc2ce997dbc158f8722ba4e2,3,Rollup merge of #72338 - doctorn:trait-object-ice r=ecstatic-morse Fix ICE in -Zsave-analysis Puts a short-circuit in to avoid an ICE in `-Zsave-analysis`. r? @ecstatic-morse Resolves #72267,THUMBS_UP,2020-05-19T06:06:06Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72341,CLOSED,2020-05-19T04:18:29Z,2020-05-26T04:20:55Z,Avoid stack overflow when printing unevaluated const,Aaron1011,NA,NA,NA,HOORAY,2020-05-19T18:36:39Z,akofke,akofke@gmail.com https://github.com/rust-lang/rust/pull/72341,CLOSED,2020-05-19T04:18:29Z,2020-05-26T04:20:55Z,Avoid stack overflow when printing unevaluated const,Aaron1011,NA,NA,NA,HOORAY,2020-05-25T17:27:16Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-19T07:58:12Z,mati865,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-19T08:13:54Z,bugadani,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-19T12:10:24Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-19T12:41:23Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-19T21:16:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-20T01:25:38Z,estebank,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-20T06:48:11Z,est31,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-20T21:02:46Z,aaronabramov,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-21T00:17:34Z,izik1,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-21T06:32:10Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-23T02:37:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-26T20:23:40Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-28T12:30:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-28T15:10:30Z,Ms2ger,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-28T20:11:06Z,rrbutani,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-28T22:08:10Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-29T12:58:03Z,gogobook,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-29T20:30:51Z,shenek,stepan+github@henek.name https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-05-30T11:22:07Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2020-11-11T10:03:22Z,mattgathu,NA https://github.com/rust-lang/rust/pull/72342,MERGED,2020-05-19T06:19:03Z,2020-05-27T00:21:43Z,Warn about unused crate deps,jsgf,e38fdda243c890bc8f4ce93eb82fd1bf750ebbe7,17,"Rollup merge of #72342 - jsgf:warn-unused-deps r=petrochenkov Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = ""bar"" }` in `Cargo.toml`) then it will warn about each unused alias. This does not consider crate added by some other means than `--extern` including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates causing spurious warnings. As a result this lint is ""allow"" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.",HEART,2021-09-30T09:15:04Z,vbfox,fox@vbfox.net https://github.com/rust-lang/rust/pull/72347,MERGED,2020-05-19T12:05:10Z,2020-05-22T01:32:56Z,Make intra-link resolve links for both trait and impl items,xliiv,3d5f130aae7554ceaf0601979d0aeb9fc593cbb0,2,Rollup merge of #72347 - xliiv:72340-impl-for-default r=GuillaumeGomez Make intra-link resolve links for both trait and impl items Closes #72340,HOORAY,2020-05-21T15:36:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72348,MERGED,2020-05-19T12:06:14Z,2020-05-27T14:49:09Z,Fix confusing error message for comma typo in multiline statement,chrissimpkins,cbe7b908b124047aaff5f1bed1056a71ca0a6b3b,3,Rollup merge of #72348 - chrissimpkins:fix-72253 r=estebank Fix confusing error message for comma typo in multiline statement Fixes #72253. Expands on the issue with a colon typo check. r? @estebank cc @ehuss,THUMBS_UP,2020-05-19T17:46:09Z,estebank,NA https://github.com/rust-lang/rust/pull/72350,MERGED,2020-05-19T14:00:08Z,2020-05-22T01:32:55Z,Improve documentation of `slice::from_raw_parts`,danielhenrymantilla,261505a0cf7a946fc2e5e8ed84f58e93b871f27b,1,Rollup merge of #72350 - danielhenrymantilla:doc_warn_against_adjacent_slice_concat r=RalfJung Improve documentation of `slice::from_raw_parts` This is to provide a more explicit statement against a code pattern that many people end up coming with since the reason of it being unsound comes from the badly known single-allocation validity rule. Providing that very pattern as a counter-example could help mitigate that. See also: https://internals.rust-lang.org/t/pre-rfc-add-join-seq-method-to-slices-and-strs/11936/13 r? @RalfJung,HEART,2020-05-20T07:05:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-19T18:35:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-19T18:38:45Z,mati865,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-19T18:55:51Z,kpp,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-19T19:07:51Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-19T19:28:00Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-20T00:13:19Z,tesuji,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-20T11:55:48Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-05-20T18:47:20Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-06T03:49:43Z,codars,xiaguo@microsoft.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-15T17:42:51Z,tmandry,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-16T23:59:43Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-17T10:16:57Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-17T11:34:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-18T08:34:11Z,mzji,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,ROCKET,2020-06-24T05:53:22Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HOORAY,2020-06-24T05:53:28Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-24T05:53:35Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-06-25T05:44:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2020-07-03T18:51:15Z,adaszko,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2021-01-13T03:27:14Z,estebank,NA https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,HEART,2021-08-16T21:15:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,THUMBS_UP,2021-09-27T03:29:57Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72357,MERGED,2020-05-19T18:32:52Z,2020-06-15T19:13:27Z,Implement new gdb/lldb pretty-printers,ortem,f315c35a77e40bd11ce81fedc0556be0f410bbf4,59,Auto merge of #72357 - ortem:new-dbg-pretty-printers r=pnkfelix Implement new gdb/lldb pretty-printers Reopened #60826 This PR replaces current gdb and lldb pretty-printers with new ones that were originally written for [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust/tree/master/prettyPrinters). The current state of lldb pretty-printers is poor because [they don't use synthetic children](https://github.com/rust-lang/rust/issues/55586#issuecomment-436610063). When I started to reimplement lldb pretty-printers with synthetic children support I've found current version strange and hard to support. I think `debugger_pretty_printers_common.py` is overkill so I got rid of it. The new pretty-printers have to support all types supported by current pretty-printers and also support `Rc` `Arc` `Cell` `Ref` `RefCell` `RefMut` `HashMap` `HashSet`. Fixes #56252,THUMBS_UP,2021-10-19T19:43:12Z,dwhitz,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-19T20:50:33Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-19T20:52:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-19T20:59:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-20T03:07:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-20T12:50:18Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-20T16:34:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-21T17:45:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-22T20:47:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-24T21:48:00Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-24T22:11:28Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-25T12:21:32Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-25T13:12:30Z,lqd,NA https://github.com/rust-lang/rust/pull/72362,MERGED,2020-05-19T20:46:01Z,2020-05-24T07:46:27Z,Remove ReScope,matthewjasper,52b605c8cb2f730e607de0777a694cd1b9bb3e15,81,Auto merge of #72362 - matthewjasper:remove-rescope r=nikomatsakis Remove ReScope `ReScope` is unnecessary now that AST borrowck is gone and we're erasing the results of region inference in function bodies. This removes about as much of the old regionck code as possible without having to enable NLL fully. cc #68261 r? @nikomatsakis,HOORAY,2020-05-29T17:43:20Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72369,MERGED,2020-05-20T03:51:50Z,2020-07-01T18:55:22Z,Bring net/parser.rs up to modern up to date with modern rust patterns,Lucretiel,33f8ce287a62d8c76c7cea11c5cf67f53d5b8f40,1,"Rollup merge of #72369 - Lucretiel:socketaddr-parse r=dtolnay Bring net/parser.rs up to modern up to date with modern rust patterns The current implementation of IP address parsing is very unidiomatic; it's full of `if` / `return` / `is_some` / `is_none` instead of `?` `loop` with manual index tracking; etc. Went through and did and cleanup to try to bring it in line with modern sensibilities. The obvious concern with making changes like this is ""make sure you understand why it's written that way before changing it"". Looking through the commit history for this file there are several much smaller commits that make similar changes (For instance https://github.com/rust-lang/rust/commit/3024c1434a667425d30e4b0785857381323712aa https://github.com/rust-lang/rust/commit/4f3ab4986ec96d9c93f34dc53d0a4a1279288451 https://github.com/rust-lang/rust/commit/79f876495b2853d1b78ba953ceb3114b8019100f) and there don't seem to be any commits in the history that indicate that this lack of idiomaticity is related to specific performance needs (ie there aren't any commits that replace a `for` loop with a `loop` and a manual index count). In fact the basic shape of the file is essentially unchanged from its initial commit back in 2015. Made the following changes throughout the IP address parser: - Replaced all uses of `is_some()` / `is_none()` with `?`. - ""Upgraded"" loops wherever possible; ie replace `while` with `for` etc. - Removed all cases of manual index tracking / incrementing. - Renamed several single-character variables with more expressive names. - Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`). - Removed `read_seq_3`; replaced with simple sequences of `?`. - Parser now reslices its state when consuming rather than carrying a separate state and index variable. - `read_digit` now uses `char::to_digit`. - Added comments throughout especially in the complex IPv6 parsing logic. - Added comprehensive local unit tests for the parser to validate these changes.",HEART,2020-06-29T06:21:23Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/72371,MERGED,2020-05-20T09:31:35Z,2020-05-21T15:02:20Z,FIX - Char documentation for unexperienced users,Elrendio,0e887129adfe149b1089d9f719475f7c3a1c8e33,1,"Rollup merge of #72371 - Elrendio:char_documentation r=steveklabnik FIX - Char documentation for unexperienced users This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure. **What it does:** - Add an example in the char documentation **Explanation** Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write: ```rust my_string.chars().all(char::is_uppercase) ``` However this will return false for `""HELLO WORLD""` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is: ```rust !my_string.chars().any(char::is_lowercase) ``` The aim of this example is to prevent unexperienced users to make an error which punctuation chars.",THUMBS_UP,2020-05-23T09:33:00Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/72380,MERGED,2020-05-20T14:00:51Z,2020-06-11T14:53:25Z,Fix `is_const_context` update `check_for_cast`,lcnr,298467ee9a7fa1bbc93383c3a67ea569a6e7c22c,9,Rollup merge of #72380 - lcnr:const_context r=estebank Fix `is_const_context` update `check_for_cast` A better version of #71477 Adds `fn enclosing_body_owner` and uses it in `is_const_context`. `is_const_context` now uses the same mechanism as `mir_const_qualif` as it was previously incorrect. Renames `is_const_context` to `is_inside_const_context`. I also updated `check_for_cast` in the second commit so r? @estebank (I removed one lvl of indentation so it might be easier to review by hiding whitespace changes),HEART,2020-06-10T17:25:58Z,estebank,NA https://github.com/rust-lang/rust/pull/72389,MERGED,2020-05-20T17:56:41Z,2020-06-15T11:40:25Z,Explain move errors that occur due to method calls involving `self`,Aaron1011,372cb9b69c76a042d0b9d4b48ff6084f64c84a2c,45,Rollup merge of #72389 - Aaron1011:feature/move-fn-self-msg r=nikomatsakis Explain move errors that occur due to method calls involving `self` When calling a method that takes `self` (e.g. `vec.into_iter()`) the method receiver is moved out of. If the method receiver is used again a move error will be emitted:: ```rust fn main() { let a = vec![true]; a.into_iter(); a; } ``` emits ``` error[E0382]: use of moved value: `a` --> src/main.rs:4:5 | 2 | let a = vec![true]; | - move occurs because `a` has type `std::vec::Vec` which does not implement the `Copy` trait 3 | a.into_iter(); | - value moved here 4 | a; | ^ value used here after move ``` However the error message doesn't make it clear that the move is caused by the call to `into_iter`. This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method:: ``` error[E0382]: use of moved value: `a` --> vec.rs:4:5 | 2 | let a = vec![true]; | - move occurs because `a` has type `std::vec::Vec` which does not implement the `Copy` trait 3 | a.into_iter(); | ------------- value moved due to this method call 4 | a; | ^ value used here after move | note: this function takes `self` which moves the receiver --> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5 | 239 | fn into_iter(self) -> Self::IntoIter; ``` TODO: - [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods - [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`) - [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.,HEART,2020-06-05T16:41:47Z,estebank,NA https://github.com/rust-lang/rust/pull/72389,MERGED,2020-05-20T17:56:41Z,2020-06-15T11:40:25Z,Explain move errors that occur due to method calls involving `self`,Aaron1011,372cb9b69c76a042d0b9d4b48ff6084f64c84a2c,45,Rollup merge of #72389 - Aaron1011:feature/move-fn-self-msg r=nikomatsakis Explain move errors that occur due to method calls involving `self` When calling a method that takes `self` (e.g. `vec.into_iter()`) the method receiver is moved out of. If the method receiver is used again a move error will be emitted:: ```rust fn main() { let a = vec![true]; a.into_iter(); a; } ``` emits ``` error[E0382]: use of moved value: `a` --> src/main.rs:4:5 | 2 | let a = vec![true]; | - move occurs because `a` has type `std::vec::Vec` which does not implement the `Copy` trait 3 | a.into_iter(); | - value moved here 4 | a; | ^ value used here after move ``` However the error message doesn't make it clear that the move is caused by the call to `into_iter`. This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method:: ``` error[E0382]: use of moved value: `a` --> vec.rs:4:5 | 2 | let a = vec![true]; | - move occurs because `a` has type `std::vec::Vec` which does not implement the `Copy` trait 3 | a.into_iter(); | ------------- value moved due to this method call 4 | a; | ^ value used here after move | note: this function takes `self` which moves the receiver --> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5 | 239 | fn into_iter(self) -> Self::IntoIter; ``` TODO: - [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods - [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`) - [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.,HEART,2020-06-17T17:25:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72392,CLOSED,2020-05-20T19:15:43Z,2020-05-20T22:08:37Z,Use Cow instead of &[] for InlineAsm MIR ,Amanieu,NA,NA,NA,HEART,2020-05-20T19:48:47Z,macpp,NA https://github.com/rust-lang/rust/pull/72395,MERGED,2020-05-20T20:18:02Z,2020-05-23T10:47:08Z,Allow rust-highfive to label issues it creates.,Elinvynia,01adfe1bc370af0b16265fc6bebbeb9ffe7f459a,1,Rollup merge of #72395 - Elinvynia:highfive r=Mark-Simulacrum Allow rust-highfive to label issues it creates. This is my first meaningful PR I am unsure how to test this code so any pointers would be welcome! I am about 50% sure it works.,HEART,2020-05-20T20:23:56Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72399,MERGED,2020-05-20T20:56:26Z,2020-05-22T19:09:25Z,Add fast-path optimization for Ipv4Addr::fmt,Lucretiel,37587af8d53b516b5f74a0ff667c83bccd308b8d,1,Rollup merge of #72399 - Lucretiel:ipv4-display-fast r=kennytm Add fast-path optimization for Ipv4Addr::fmt Don't use an intermediary buffer when writing an IPv4 address without any specific alignment options,THUMBS_UP,2020-05-29T13:14:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-07T01:11:55Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-15T01:41:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-15T12:33:39Z,link2xt,NA https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HOORAY,2020-09-15T12:33:44Z,link2xt,NA https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HEART,2020-09-18T15:49:47Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HOORAY,2020-09-19T07:06:20Z,leod,NA https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-22T19:12:15Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HEART,2020-09-24T08:49:50Z,nayato,NA https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-24T21:45:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-09-25T17:08:02Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2020-10-03T21:09:51Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HOORAY,2021-03-15T21:24:28Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,HEART,2021-03-15T21:24:29Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/72412,MERGED,2020-05-21T04:05:49Z,2020-09-18T16:24:09Z,Issue 72408 nested closures exponential,VFLashM,fdc3405c20122fd0f077f5a77addabc873f20e4c,22,Auto merge of #72412 - VFLashM:issue-72408-nested-closures-exponential r=tmandry Issue 72408 nested closures exponential This fixes #72408. Nested closures were resulting in exponential compilation time. This PR is enhancing asymptotic complexity but also increasing the constant so I would love to see perf run results.,ROCKET,2021-03-15T21:24:29Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-21T18:53:11Z,mbrubeck,mbrubeck@limpet.net https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HEART,2020-05-21T21:51:46Z,estebank,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-22T12:24:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-27T06:38:49Z,elpiel,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-28T03:30:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-28T03:35:17Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-05-28T14:13:03Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,THUMBS_UP,2020-05-28T14:13:06Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HEART,2020-06-04T02:22:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-06-04T20:14:57Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-06-05T17:42:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-07-16T15:57:07Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-07-16T16:33:24Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-07-16T17:13:25Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72413,MERGED,2020-05-21T04:57:26Z,2020-05-30T03:25:21Z,impl Step for char (make Range* iterable),CAD97,b965196ce0bb0b484336f1f2ba3a6a72cbfb4f76,2,Rollup merge of #72413 - CAD97:char-range r=dtolnay impl Step for char (make Range* iterable) [[irlo thread]](https://internals.rust-lang.org/t/mini-rfc-make-range-char-work/12392?u=cad97) [[godbolt asm example]](https://rust.godbolt.org/z/fdveKo) Add an implementation of the `Step` trait for `char` which has the effect of making `RangeInclusive` (and the other range types) iterable. I've used the surrogate range magic numbers as magic numbers here rather than e.g. a `const SURROGATE_RANGE = 0xD800..0xE000` because these numbers appear to be used as magic numbers elsewhere and there doesn't exist constants for them yet. These files definitely aren't where surrogate range constants should live. `ExactSizeIterator` is not implemented because `0x10FFFF` is bigger than fits in a `usize == u16`. However given we already provide some `ExactSizeIterator` that are not correct on 16 bit targets we might still want to consider providing it for `Range`[`Inclusive`]`` as it is definitely _very_ convenient. (At the very least we want to make sure `.count()` doesn't bother iterating the range.) The second commit in this PR changes a call to `Step::forward` to use `Step::forward_unchecked` in `RangeInclusive::next`. This is because without this patch iteration over all codepoints (`'\0'..=char::MAX`) does not successfully optimize out the panicking branch. This was mentioned in the PR that updated `Step` to its current design but was deemed not yet necessary as it did not impact codegen for integral types. More of `Range*`'s implementations' calls to `Step` methods will probably want to see if they can use the `_unchecked` version as (if) we open up `Step` to being implemented on more types. --- cc @rust-lang/libs this is insta-stable and a fairly significant addition to `Range*`'s capabilities; this is the first instance of a noncontinuous domain being iterable with `Range` (or well anything other than primitive integers). I don't think this needs a full RFC but it should definitely get some decent eyes on it.,HOORAY,2020-07-18T17:06:59Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T07:46:36Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T08:09:49Z,mati865,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T09:04:32Z,kngwyu,yuji.kngw.80s.revive@gmail.com https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T09:32:50Z,darksv,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T12:31:49Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-21T17:34:44Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-22T04:55:50Z,95th,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-23T07:22:49Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-24T21:45:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-05-30T09:54:01Z,Diamondlord,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-06-07T04:20:32Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-06-30T05:52:53Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-07-07T11:49:49Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-07-18T03:00:15Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-07-18T14:18:44Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2020-07-18T20:52:26Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/72414,MERGED,2020-05-21T05:55:30Z,2020-07-18T16:09:28Z, Add lazy initialization primitives to std,KodrAus,01418bd1aa71a38567b9fea737d74379133d28c0,7,Rollup merge of #72414 - KodrAus:feat/stdlazy r=Mark-Simulacrum Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy` especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally if we're adding these types to `std::lazy` instead of `std::sync` I'd be on-board with not worrying about poisoning in `std::lazy` and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general none of these seem to be really blocking an initial unstable merge so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything or were there any other considerations that have come up since we last looked at this?,HOORAY,2021-09-03T15:43:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72423,CLOSED,2020-05-21T13:45:24Z,2020-05-29T14:55:02Z,submodules: Update RLS and Rustfmt,Xanewok,NA,NA,NA,ROCKET,2020-05-21T22:44:30Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/72431,MERGED,2020-05-21T17:19:23Z,2020-05-23T21:21:50Z,add warning sign to UB examples,RalfJung,d5e3009bd8a2eb934415a1ed1b19b031b6f9c4e2,1,Rollup merge of #72431 - RalfJung:ub-warning r=shepmaster add warning sign to UB examples Just to make it less likely that people miss the fact that these are examples for how to *not* do it.,HEART,2020-05-22T09:26:14Z,doctorn,me@nathancorbyn.com https://github.com/rust-lang/rust/pull/72431,MERGED,2020-05-21T17:19:23Z,2020-05-23T21:21:50Z,add warning sign to UB examples,RalfJung,d5e3009bd8a2eb934415a1ed1b19b031b6f9c4e2,1,Rollup merge of #72431 - RalfJung:ub-warning r=shepmaster add warning sign to UB examples Just to make it less likely that people miss the fact that these are examples for how to *not* do it.,HEART,2020-05-22T10:34:37Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T21:27:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T21:27:59Z,the-emerald,git@anson-cheung.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T21:28:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T21:43:33Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T21:44:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T22:01:02Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-21T22:14:18Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T02:49:17Z,tesuji,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T04:34:52Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T04:38:24Z,95th,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T05:02:44Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T05:14:42Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T06:50:02Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T08:55:07Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T09:45:57Z,darksv,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-22T21:35:07Z,voidc,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-23T08:27:29Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-23T08:36:57Z,mati865,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-24T04:02:48Z,khoek,keeley@hoek.io https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-24T13:24:13Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-24T21:43:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-25T10:32:35Z,CryZe,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-25T22:47:03Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-28T03:36:22Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-28T14:19:33Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-30T08:35:54Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-30T23:31:29Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-05-31T08:56:12Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-01T11:39:51Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-02T16:48:24Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-03T10:01:25Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-04T20:49:15Z,est31,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-08T03:30:45Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-10T02:02:34Z,tyler274,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-11T15:20:45Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-18T12:53:14Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T00:05:08Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T01:51:00Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T05:12:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T07:24:19Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T07:56:36Z,0x4ce66f11,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T07:56:45Z,ratijas,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T08:43:06Z,yerke,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T08:56:44Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T08:59:37Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T10:12:00Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T10:35:26Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T11:29:18Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T11:45:57Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T12:35:52Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T12:51:15Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T14:19:42Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T14:23:13Z,crides,zhuhaoqing@live.cn https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T14:28:48Z,DCRussianDev,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T15:00:56Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T17:40:42Z,frol,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T18:25:33Z,elichai,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-29T21:47:22Z,Angr1st,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-30T16:52:23Z,creativcoder,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-06-30T21:02:56Z,olanti-p,olanti-p@yandex.ru https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-07-01T01:18:47Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-07-01T11:51:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-07-02T03:20:32Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-07-02T21:03:02Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-07-25T23:01:46Z,kawaemon,me@kawaemon.dev https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-05T07:46:09Z,rrbutani,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-10T11:12:33Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-19T16:52:08Z,weihanglo,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-24T21:58:03Z,markazmierczak,mar.kazmierczak@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-25T02:23:51Z,brian-gavin,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-25T07:14:52Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-27T11:14:25Z,YoshiTheChinchilla,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-27T18:52:44Z,jtich,josh@fatt.ist https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-27T19:46:18Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-08-27T21:01:04Z,hoodie,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-09-02T23:05:40Z,yuequan1997,yuequan1997@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2020-09-11T16:44:04Z,igalakhov,igalakhov.nyc@gmail.com https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2021-03-25T23:38:12Z,PaulDance,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2021-12-05T02:20:22Z,kushwahashiv,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2021-12-30T19:04:17Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72437,MERGED,2020-05-21T21:26:16Z,2020-06-29T00:44:03Z,Stabilize `#![feature(const_if_match)]` and `#![feature(const_loop)]`,ecstatic-morse,c977b8775dd72d191ff1d8e8dceaf4b4cd5db86c,129,Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match r=oli-obk Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const` `static` `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally we would resolve :whale: #66753 before this lands on stable so it might be worth pushing this back a release. Also this means we should get the process started for #52000 otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk,HOORAY,2022-05-27T10:21:05Z,billchow98,NA https://github.com/rust-lang/rust/pull/72439,MERGED,2020-05-21T21:56:47Z,2020-05-30T03:25:19Z,NVPTX support for new asm!,westernmagic,37894559abd67dd9544f2d66b0e117573e38119c,5,Rollup merge of #72439 - westernmagic:master r=Amanieu NVPTX support for new asm! This PR implements the new `asm!` syntax for the `nvptx64-nvidia-cuda` target. r? @Amanieu,HEART,2020-05-21T22:03:18Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72441,MERGED,2020-05-21T22:33:20Z,2020-05-30T16:35:57Z,Fix ICE with explicit late-bound lifetimes,doctorn,49ca99de93f8ed26b16ac2ef70c61c7ed2267754,5,Rollup merge of #72441 - doctorn:late-bound-lifetime-ice r=nikomatsakis Fix ICE with explicit late-bound lifetimes Rather than returning an explicit late-bound lifetime as a generic argument count mismatch (which is not necessarily true) this PR propagates the presence of explicit late-bound lifetimes. This avoids an ICE that can occur due to the presence of explicit late-bound lifetimes when building generic substitutions by explicitly ignoring them. r? @varkor cc @davidtwco (this removes a check you introduced in #60892) Resolves #72278,THUMBS_UP,2020-05-22T09:32:56Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T00:09:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T00:10:17Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T00:16:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T01:03:59Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T04:36:36Z,95th,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-05-22T08:48:19Z,harrysarson,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T09:06:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T09:17:35Z,slyedoc,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T09:24:59Z,doctorn,me@nathancorbyn.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T18:09:16Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T22:00:26Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-22T22:22:26Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-23T16:27:52Z,est31,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-24T21:42:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-05-24T21:42:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-05-25T10:26:13Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-25T10:26:13Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-05-26T19:31:50Z,rebo,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-05-26T19:31:53Z,rebo,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-05-29T21:23:46Z,lehmanju,internet@devpi.de https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-06-07T19:08:53Z,lights0123,developer@lights0123.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-06-22T10:59:08Z,ivanschuetz,ivanhp978@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-06-22T10:59:09Z,ivanschuetz,ivanhp978@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-06-23T04:38:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-06-25T17:45:30Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-06-30T15:17:44Z,bjorn3,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HEART,2020-07-02T07:47:31Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-07-10T12:30:20Z,tux3,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-07-15T13:36:54Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-07-29T22:33:55Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",THUMBS_UP,2020-08-25T07:31:15Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-09-29T21:59:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72445,MERGED,2020-05-21T23:53:49Z,2020-07-01T18:55:19Z,Stabilize `#[track_caller]`.,anp,ae79c30d74a52e81687bb35af6481eeeeafaeb84,38,"Rollup merge of #72445 - anp:stabilize-track-caller r=oli-obk Stabilize `#[track_caller]`. # Stabilization Report RFC: [2091] Tracking issue: https://github.com/rust-lang/rust/issues/47809 ## Summary From the [rustc-dev-guide chapter][dev-guide]: > Take this example program: ```rust fn main() { let foo: Option<()> = None; foo.unwrap(); // this should produce a useful panic message! } ``` > Prior to Rust 1.42 panics like this `unwrap()` printed a location in libcore: ``` $ rustc +1.41.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' ...core\macros\mod.rs:15:40 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ``` > As of 1.42 we get a much more helpful message: ``` $ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value' example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` > These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. The attribute adds an implicit caller location argument to the ABI of annotated functions but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator. ## Bottom Line This PR stabilizes the use of `#[track_caller]` everywhere including traits and extern blocks. It also stabilizes `core::panic::Location::caller` although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`. The implementation for the feature already changed the output of panic messages for a number of std functions as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44. ## Tests All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo. Noteworthy cases: * [use of attr in std] * validates user-facing benefit of the feature * [trait attribute inheritance] * covers subtle behavior designed during implementation and not RFC'd * [const/codegen equivalence] * this was the result of a suspected edge case and investigation * [diverging function support] * covers an unresolved question from the RFC * [fn pointers and shims] * covers important potential sources of unsoundness ## Documentation The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide]. I have an [open PR to the reference][attr-reference-pr] documenting the attribute. The intrinsic's [wrapper] includes some examples as well. ## Implementation History * 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](https://github.com/rust-lang/rust/pull/65037) * Picked up the patch that @ayosec had started on the feature gate. * 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](https://github.com/rust-lang/rust/pull/65182) * 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](https://github.com/rust-lang/rust/pull/65258)~~ * Abandoned approach to send location as a MIR argument. * 2019-10-28: [`std::panic::Location` is a lang_item add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](https://github.com/rust-lang/rust/pull/65664) * 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](https://github.com/rust-lang/rust/pull/65881) * 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](https://github.com/rust-lang/rust/pull/67137) * 2020-01-08: [`Option::{expect unwrap}` and `Result::{expect expect_err unwrap unwrap_err}` have `#[track_caller]` #67887](https://github.com/rust-lang/rust/pull/67887) * 2020-01-20: [Fix #[track_caller] and function pointers #68302](https://github.com/rust-lang/rust/pull/68302) (fixed #68178) * 2020-03-23: [#[track_caller] in traits #69251](https://github.com/rust-lang/rust/pull/69251) * 2020-03-24: [#[track_caller] on core::ops::{Index IndexMut}. #70234](https://github.com/rust-lang/rust/pull/70234) * 2020-04-08 [Support `#[track_caller]` on functions in `extern ""Rust"" { ... }` #70916](https://github.com/rust-lang/rust/pull/70916) ## Unresolveds ### From the RFC > Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing > measure. **Resolved.** See the dev-guide documentation and the tests section above. > Diverging functions should be supported. **Resolved.** See the tests section above. > The closure foo::{{closure}} should inherit most attributes applied to the function foo ... **Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation. ### Binary Size I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support. There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the ""right"" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction. ### Specialization There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable but I also think it should be an easy question to resolve. ### Location only points to the start of a call span https://github.com/rust-lang/rust/issues/69977 was resolved by https://github.com/rust-lang/rust/pull/73182 and the next step should probably be to [extend `Location` with a notion of the end of a call](https://github.com/rust-lang/rust/issues/73554). ### Regression of std's panic messages #70963 should be resolved by serializing span hygeine to crate metadata: https://github.com/rust-lang/rust/issues/68686. [2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md [dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html [specialization]: https://github.com/rust-lang/rust/issues/70293 [measure-size]: https://github.com/rust-lang/rust/issues/70579 [mitigate-size]: https://github.com/rust-lang/rust/issues/70580 [attr-reference-pr]: https://github.com/rust-lang/reference/pull/742 [wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller [tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller [const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs [diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs [use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs [fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs [trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs [1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages",HOORAY,2020-12-23T09:09:06Z,Folyd,NA https://github.com/rust-lang/rust/pull/72446,MERGED,2020-05-22T00:17:07Z,2020-05-23T21:21:47Z,Impl Ord for proc_macro::LineColumn,dtolnay,67759b74f44f4d119625115525b5375416e5f8d8,2,Rollup merge of #72446 - dtolnay:ord r=petrochenkov Impl Ord for proc_macro::LineColumn ```rust impl Ord for LineColumn {...} impl PartialOrd for LineColumn {...} ``` for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html. The ordering is the natural one you would get by writing one line after another where we compare line first then compare columns within the same line.,THUMBS_UP,2020-05-23T09:38:00Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/72446,MERGED,2020-05-22T00:17:07Z,2020-05-23T21:21:47Z,Impl Ord for proc_macro::LineColumn,dtolnay,67759b74f44f4d119625115525b5375416e5f8d8,2,Rollup merge of #72446 - dtolnay:ord r=petrochenkov Impl Ord for proc_macro::LineColumn ```rust impl Ord for LineColumn {...} impl PartialOrd for LineColumn {...} ``` for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html. The ordering is the natural one you would get by writing one line after another where we compare line first then compare columns within the same line.,THUMBS_UP,2020-05-29T13:14:54Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72449,MERGED,2020-05-22T02:06:15Z,2020-08-23T21:19:17Z,Const floating point bitcasts and classification,ecstatic-morse,0ec94594dd15afba00635e0ae29d405a38ec1a21,5,Auto merge of #72449 - ecstatic-morse:const-float-bitcast r=RalfJung Const floating point bitcasts and classification Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const. r? @RalfJung,THUMBS_UP,2020-05-22T23:23:08Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72449,MERGED,2020-05-22T02:06:15Z,2020-08-23T21:19:17Z,Const floating point bitcasts and classification,ecstatic-morse,0ec94594dd15afba00635e0ae29d405a38ec1a21,5,Auto merge of #72449 - ecstatic-morse:const-float-bitcast r=RalfJung Const floating point bitcasts and classification Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const. r? @RalfJung,THUMBS_UP,2020-05-23T08:36:17Z,mati865,NA https://github.com/rust-lang/rust/pull/72449,MERGED,2020-05-22T02:06:15Z,2020-08-23T21:19:17Z,Const floating point bitcasts and classification,ecstatic-morse,0ec94594dd15afba00635e0ae29d405a38ec1a21,5,Auto merge of #72449 - ecstatic-morse:const-float-bitcast r=RalfJung Const floating point bitcasts and classification Makes the `f32` and `f64` methods described in #72447 and #72505 unstably const. r? @RalfJung,THUMBS_UP,2020-05-24T21:42:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72453,MERGED,2020-05-22T04:18:00Z,2020-05-23T10:47:00Z,Add flag to open docs: x.py doc --open,dtolnay,3083ce7ab127dfd1cbb453810579ca827dcfd7bb,5,Rollup merge of #72453 - dtolnay:open r=Mark-Simulacrum Add flag to open docs: x.py doc --open This aligns with Cargo's flag `cargo doc --open`. Tested with: ```bash # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro ```,HEART,2020-05-22T04:22:58Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72453,MERGED,2020-05-22T04:18:00Z,2020-05-23T10:47:00Z,Add flag to open docs: x.py doc --open,dtolnay,3083ce7ab127dfd1cbb453810579ca827dcfd7bb,5,Rollup merge of #72453 - dtolnay:open r=Mark-Simulacrum Add flag to open docs: x.py doc --open This aligns with Cargo's flag `cargo doc --open`. Tested with: ```bash # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro ```,HEART,2020-05-22T09:22:57Z,doctorn,me@nathancorbyn.com https://github.com/rust-lang/rust/pull/72453,MERGED,2020-05-22T04:18:00Z,2020-05-23T10:47:00Z,Add flag to open docs: x.py doc --open,dtolnay,3083ce7ab127dfd1cbb453810579ca827dcfd7bb,5,Rollup merge of #72453 - dtolnay:open r=Mark-Simulacrum Add flag to open docs: x.py doc --open This aligns with Cargo's flag `cargo doc --open`. Tested with: ```bash # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro ```,HEART,2020-05-22T13:26:44Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/72453,MERGED,2020-05-22T04:18:00Z,2020-05-23T10:47:00Z,Add flag to open docs: x.py doc --open,dtolnay,3083ce7ab127dfd1cbb453810579ca827dcfd7bb,5,Rollup merge of #72453 - dtolnay:open r=Mark-Simulacrum Add flag to open docs: x.py doc --open This aligns with Cargo's flag `cargo doc --open`. Tested with: ```bash # opens doc/index.html x.py doc --stage 0 --open x.py doc --stage 0 --open src/doc # opens doc/book/index.html x.py doc --stage 0 --open src/doc/book # opens doc/std/index.html x.py doc --stage 0 --open src/libstd # opens doc/proc_macro/index.html x.py doc --stage 0 --open src/libproc_macro # opens both x.py doc --stage 0 --open src/libstd src/libproc_macro ```,HEART,2020-05-22T20:45:47Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72456,MERGED,2020-05-22T06:28:33Z,2020-06-21T02:20:55Z,Try to suggest dereferences on trait selection failed,ldm0,a1404a93f9632d768d7268934e6380a9b9614834,23,Rollup merge of #72456 - ldm0:dereftrait r=estebank Try to suggest dereferences on trait selection failed Fixes #39029 Fixes #62530 This PR consists of two parts: 1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`. 2. Try to suggest dereferences when trait selection failed. The first is needed because: 1. For suggesting dereferences the struct `Autoderef` should be used. But before this PR it is placed in `librustc_typeck` which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection` if we want to use `Autoderef` in it dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`. 2. Before this PR `FnCtxt` is coupled to `Autoderef` and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed. After this PR we can get suggestion like this: ``` error[E0277]: the trait bound `&Baz: Happy` is not satisfied --> $DIR/trait-suggest-deferences-multiple.rs:34:9 | LL | fn foo(_: T) where T: Happy {} | ----- required by this bound in `foo` ... LL | foo(&baz); | ^^^^ | | | the trait `Happy` is not implemented for `&Baz` | help: consider adding dereference here: `&***baz` error: aborting due to previous error For more information about this error try `rustc --explain E0277`. ``` r? @estebank,HEART,2020-05-22T20:03:16Z,estebank,NA https://github.com/rust-lang/rust/pull/72456,MERGED,2020-05-22T06:28:33Z,2020-06-21T02:20:55Z,Try to suggest dereferences on trait selection failed,ldm0,a1404a93f9632d768d7268934e6380a9b9614834,23,Rollup merge of #72456 - ldm0:dereftrait r=estebank Try to suggest dereferences on trait selection failed Fixes #39029 Fixes #62530 This PR consists of two parts: 1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`. 2. Try to suggest dereferences when trait selection failed. The first is needed because: 1. For suggesting dereferences the struct `Autoderef` should be used. But before this PR it is placed in `librustc_typeck` which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection` if we want to use `Autoderef` in it dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`. 2. Before this PR `FnCtxt` is coupled to `Autoderef` and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed. After this PR we can get suggestion like this: ``` error[E0277]: the trait bound `&Baz: Happy` is not satisfied --> $DIR/trait-suggest-deferences-multiple.rs:34:9 | LL | fn foo(_: T) where T: Happy {} | ----- required by this bound in `foo` ... LL | foo(&baz); | ^^^^ | | | the trait `Happy` is not implemented for `&Baz` | help: consider adding dereference here: `&***baz` error: aborting due to previous error For more information about this error try `rustc --explain E0277`. ``` r? @estebank,HEART,2020-05-23T08:48:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72456,MERGED,2020-05-22T06:28:33Z,2020-06-21T02:20:55Z,Try to suggest dereferences on trait selection failed,ldm0,a1404a93f9632d768d7268934e6380a9b9614834,23,Rollup merge of #72456 - ldm0:dereftrait r=estebank Try to suggest dereferences on trait selection failed Fixes #39029 Fixes #62530 This PR consists of two parts: 1. Decouple `Autoderef` with `FnCtxt` and move `Autoderef` to `librustc_trait_selection`. 2. Try to suggest dereferences when trait selection failed. The first is needed because: 1. For suggesting dereferences the struct `Autoderef` should be used. But before this PR it is placed in `librustc_typeck` which depends on `librustc_trait_selection`. But trait selection error emitting happens in `librustc_trait_selection` if we want to use `Autoderef` in it dependency loop is inevitable. So I moved the `Autoderef` to `librustc_trait_selection`. 2. Before this PR `FnCtxt` is coupled to `Autoderef` and `FnCtxt` only exists in `librustc_typeck`. So decoupling is needed. After this PR we can get suggestion like this: ``` error[E0277]: the trait bound `&Baz: Happy` is not satisfied --> $DIR/trait-suggest-deferences-multiple.rs:34:9 | LL | fn foo(_: T) where T: Happy {} | ----- required by this bound in `foo` ... LL | foo(&baz); | ^^^^ | | | the trait `Happy` is not implemented for `&Baz` | help: consider adding dereference here: `&***baz` error: aborting due to previous error For more information about this error try `rustc --explain E0277`. ``` r? @estebank,HEART,2020-06-21T02:43:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,HEART,2020-05-22T16:19:34Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,ROCKET,2020-05-22T22:22:03Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,THUMBS_UP,2020-05-28T20:08:17Z,ltratt,laurie@tratt.net https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,HEART,2020-05-30T03:32:51Z,kpp,NA https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,THUMBS_UP,2020-05-30T12:27:17Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,THUMBS_UP,2020-05-30T23:00:56Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/72465,MERGED,2020-05-22T15:18:00Z,2020-05-29T23:43:55Z,Warn about unused captured variables,tmiasko,9ef62271170cd15a8cbfa8d1d6192d1302e9cce2,12,Rollup merge of #72465 - tmiasko:liveness-upvars r=nikomatsakis Warn about unused captured variables Include captured variables in liveness analysis. Warn when captured variables are unused (but possibly read or written to). Warn about dead assignments to captured variables. Fixes #37707. Fixes #47128. Fixes #63220.,HEART,2020-05-30T23:00:57Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-05-28T03:32:22Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-05-28T17:58:51Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-05-28T19:39:01Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-05-28T21:37:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-05-31T20:30:15Z,red75prime,red75prim@gmail.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-03T18:57:55Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-04T06:30:28Z,pachi,NA https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-04T15:05:04Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-05T07:57:40Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-05T17:06:53Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-06T06:54:52Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-06-06T12:19:15Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-07-07T14:12:48Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/72466,MERGED,2020-05-22T15:34:42Z,2020-05-29T04:05:42Z,Stabilize str_strip feature,tesuji,3bcf6973b65ecd1b09ff5b00df0dd41f6d5938dc,3,Rollup merge of #72466 - lzutao:stabilize_str-strip r=dtolnay Stabilize str_strip feature This PR stabilizes these APIs: ```rust impl str { /// Returns a string slice with the prefix removed. /// /// If the string starts with the pattern `prefix` `Some` is returned with the substring where /// the prefix is removed. Unlike `trim_start_matches` this method removes the prefix exactly /// once. pub fn strip_prefix<'a P: Pattern<'a>>(&'a self prefix: P) -> Option<&'a str>; /// Returns a string slice with the suffix removed. /// /// If the string ends with the pattern `suffix` `Some` is returned with the substring where /// the suffix is removed. Unlike `trim_end_matches` this method removes the suffix exactly /// once. pub fn strip_suffix<'a P>(&'a self suffix: P) -> Option<&'a str> where P: Pattern<'a>

>::Searcher: ReverseSearcher<'a>; } ``` Closes #67302,HOORAY,2020-07-27T22:59:17Z,alexkreidler,NA https://github.com/rust-lang/rust/pull/72472,MERGED,2020-05-22T16:35:03Z,2020-05-25T06:17:23Z,Implement `Sync` for `process::Command on unix and vxworks,LeSeulArtichaut,2679c38fc33b5f69ce3c502c81315aa889035191,3,Auto merge of #72472 - LeSeulArtichaut:sync-command r=dtolnay Implement `Sync` for `process::Command on unix and vxworks Closes #72387. r? @cuviper,HEART,2020-05-25T13:10:28Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72472,MERGED,2020-05-22T16:35:03Z,2020-05-25T06:17:23Z,Implement `Sync` for `process::Command on unix and vxworks,LeSeulArtichaut,2679c38fc33b5f69ce3c502c81315aa889035191,3,Auto merge of #72472 - LeSeulArtichaut:sync-command r=dtolnay Implement `Sync` for `process::Command on unix and vxworks Closes #72387. r? @cuviper,HEART,2020-05-25T13:58:09Z,seanmonstar,sean@seanmonstar.com https://github.com/rust-lang/rust/pull/72479,CLOSED,2020-05-22T20:57:17Z,2020-05-26T00:02:27Z,Resolve UB in Arc/Weak interaction,Diggsey,NA,NA,NA,EYES,2020-05-22T21:49:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72486,MERGED,2020-05-23T04:06:36Z,2020-06-19T12:13:19Z,Fix asinh of negative values,Ralith,99be102a6d18ec05178a0f55ece6c65f65e38c48,2,Rollup merge of #72486 - Ralith:asinh-fix r=dtolnay Fix asinh of negative values Rust's current implementation of asinh has [large errors](https://www.wolframalpha.com/input/?i=arcsinh%28x%29%2C+ln%28x%2B%28x%5E2%2B1%29%5E0.5%29%2C+x+from+-67452095.07139316+to+0) in its negative range. ~These are (mostly) not numerical but rather seem due to an incorrect implementation.~ This appears to be due to avoidable catastrophic cancellation. [Playground before/after](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=bd04ae6d86d06612e4e389a8b95d19ab). [glibc uses](https://github.com/bminor/glibc/blob/81dca813cc35f91414731fdd0ff6b756d5e1827f/sysdeps/ieee754/dbl-64/s_asinh.c#L56) abs here. Many thanks to @danieldeankon for finding this weird behavior @jebrosen for diagnosing it and @toasteater for identifying the probable implementation error!,THUMBS_UP,2020-09-30T02:52:17Z,tillulen,NA https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-07-01T08:11:47Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-07-15T11:13:11Z,rrbutani,NA https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-07-18T10:58:21Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-08-05T18:18:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-08-28T01:32:57Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/72488,MERGED,2020-05-23T05:30:48Z,2020-07-29T17:51:36Z,Stabilize const_type_id feature,KodrAus,6fd4c3f20ff9cc4408400a98dd1c184d924421d7,9,"Auto merge of #72488 - KodrAus:stabilize/const_type_id r=nikomatsakis Stabilize const_type_id feature The tracking issue for `const_type_id` points to the ill-fated #41875. So I'm re-energizing `TypeId` shenanigans by opening this one up to see if there's anything blocking us from stabilizing the constification of type ids. Will wait for CI before pinging teams/groups. ----- This PR stabilizes the `const_type_id` feature which allows `TypeId::of` (and the underlying unstable intrinsic) to be called in constant contexts. There are some [sanity tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/const-typeid-of-rpass.rs) that demonstrate its usage but I’ve included some more below. As a simple example you could create a constant item that contains some type ids: ```rust use std::any::TypeId; const TYPE_IDS: [TypeId; 2] = [ TypeId::of::() TypeId::of::() ]; assert_eq!(TypeId::of::() TYPE_IDS[0]); ``` Type ids can also now appear in associated constants. You could create a trait that associates each type with its constant type id: ```rust trait Any where Self: 'static { const TYPE_ID: TypeId = TypeId::of::(); } impl Any for T { } assert_eq!(TypeId::of::() usize::TYPE_ID); ``` `TypeId::of` is generic which we saw above in the way the generic `Self` argument was used. This has some implications for const evaluation. It means we can make trait impls evaluate differently depending on information that wasn't directly passed through the trait system. This violates the _parametricity_ property which requires all instances of a generic function to behave the same way with respect to its generic parameters. That's not unique to `TypeId::of` other generic const functions based on compiler intrinsics like `mem::align_of` can also violate parametricity. In practice Rust doesn't really have type parametricity anyway since it monomorphizes generics into concrete functions so violating it using type ids isn’t new. As an example of how impls can behave differently you could combine constant type ids with the `const_if_match` feature to dispatch calls based on the type id of the generic `Self` rather than based on information about `Self` that was threaded through trait bounds. It's like a rough-and-ready form of specialization: ```rust #![feature(const_if_match)] trait Specialized where Self: 'static { // An associated constant that determines the function to call // at compile-time based on `TypeId::of::`. const CALL: fn(&Self) = { const USIZE: TypeId = TypeId::of::(); match TypeId::of::() { // Use a closure for `usize` that transmutes the generic `Self` to // a concrete `usize` and dispatches to `Self::usize`. USIZE => |x| Self::usize(unsafe { &*(x as *const Self as *const usize) }) // For other types dispatch to the generic `Self::default`. _ => Self::default } }; fn call(&self) { // Call the function we determined at compile-time (Self::CALL)(self) } fn default(x: &Self); fn usize(x: &usize); } // Implement our `Specialized` trait for any `Debug` type. impl Specialized for T { fn default(x: &Self) { println!(""default: {:?}"" x); } fn usize(x: &usize) { println!(""usize: {:?}"" x); } } // Will print ""usize: 42"" Specialized::call(&42usize); // Will print ""default: ()"" Specialized::call(&()); ``` Type ids have some edges that this stabilization exposes to more contexts. It's possible for type ids to collide (but this is a bug). Since they can change between compiler versions it's never valid to cast a type id to its underlying value.",THUMBS_UP,2020-09-19T22:01:56Z,librelois,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-05-23T11:44:25Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-05-23T12:35:36Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-05-23T14:09:35Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-05-23T19:32:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-05-24T21:01:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2020-06-23T12:09:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2021-08-03T20:39:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2021-08-06T14:01:10Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72493,MERGED,2020-05-23T09:53:31Z,2020-06-23T11:34:59Z, move leak-check to during coherence candidate eval,nikomatsakis,903823c59bcb9890df2a6fadcf7aa22f74eed67f,135,Rollup merge of #72493 - nikomatsakis:move-leak-check r=matthewjasper 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 Trait for fn(&T) { } impl Trait for fn(T) { } // still accepted but warns ```,HEART,2021-09-01T18:32:24Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/72497,MERGED,2020-05-23T11:32:27Z,2020-06-19T12:13:17Z,tag/niche terminology cleanup,RalfJung,5e7eec2eaa8b25d8a607a9ced3ef4df01aab3787,13,"Rollup merge of #72497 - RalfJung:tag-term r=oli-obk tag/niche terminology cleanup The term ""discriminant"" was used in two ways throughout the compiler: * every enum variant has a corresponding discriminant that can be given explicitly with `Variant = N`. * that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called ""discriminant"" even though it is conceptually quite different (e.g. it can be smaller in size or even use niche-filling). After discussion with @eddyb this renames the second term to ""tag"". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`). This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants which surfaced in https://github.com/rust-lang/rust/pull/72419. (There is also a `DiscriminantKind` type in libcore it remains unaffected. I think this corresponds to the discriminant not the tag so that seems all right.) r? @eddyb",THUMBS_UP,2020-05-23T11:43:34Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/72497,MERGED,2020-05-23T11:32:27Z,2020-06-19T12:13:17Z,tag/niche terminology cleanup,RalfJung,5e7eec2eaa8b25d8a607a9ced3ef4df01aab3787,13,"Rollup merge of #72497 - RalfJung:tag-term r=oli-obk tag/niche terminology cleanup The term ""discriminant"" was used in two ways throughout the compiler: * every enum variant has a corresponding discriminant that can be given explicitly with `Variant = N`. * that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called ""discriminant"" even though it is conceptually quite different (e.g. it can be smaller in size or even use niche-filling). After discussion with @eddyb this renames the second term to ""tag"". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`). This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants which surfaced in https://github.com/rust-lang/rust/pull/72419. (There is also a `DiscriminantKind` type in libcore it remains unaffected. I think this corresponds to the discriminant not the tag so that seems all right.) r? @eddyb",THUMBS_UP,2020-05-23T11:45:12Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72497,MERGED,2020-05-23T11:32:27Z,2020-06-19T12:13:17Z,tag/niche terminology cleanup,RalfJung,5e7eec2eaa8b25d8a607a9ced3ef4df01aab3787,13,"Rollup merge of #72497 - RalfJung:tag-term r=oli-obk tag/niche terminology cleanup The term ""discriminant"" was used in two ways throughout the compiler: * every enum variant has a corresponding discriminant that can be given explicitly with `Variant = N`. * that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called ""discriminant"" even though it is conceptually quite different (e.g. it can be smaller in size or even use niche-filling). After discussion with @eddyb this renames the second term to ""tag"". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`). This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants which surfaced in https://github.com/rust-lang/rust/pull/72419. (There is also a `DiscriminantKind` type in libcore it remains unaffected. I think this corresponds to the discriminant not the tag so that seems all right.) r? @eddyb",THUMBS_UP,2020-05-30T12:27:23Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/72497,MERGED,2020-05-23T11:32:27Z,2020-06-19T12:13:17Z,tag/niche terminology cleanup,RalfJung,5e7eec2eaa8b25d8a607a9ced3ef4df01aab3787,13,"Rollup merge of #72497 - RalfJung:tag-term r=oli-obk tag/niche terminology cleanup The term ""discriminant"" was used in two ways throughout the compiler: * every enum variant has a corresponding discriminant that can be given explicitly with `Variant = N`. * that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called ""discriminant"" even though it is conceptually quite different (e.g. it can be smaller in size or even use niche-filling). After discussion with @eddyb this renames the second term to ""tag"". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`). This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants which surfaced in https://github.com/rust-lang/rust/pull/72419. (There is also a `DiscriminantKind` type in libcore it remains unaffected. I think this corresponds to the discriminant not the tag so that seems all right.) r? @eddyb",THUMBS_UP,2020-06-04T14:52:43Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72521,MERGED,2020-05-24T01:06:43Z,2020-05-30T16:35:51Z,Properly handle InlineAsmOperand::SymFn when collecting monomorphized items,Amanieu,43ae54de9c45aff72c293e4a469f0bb9a071979e,3,Rollup merge of #72521 - Amanieu:fix-72484 r=petrochenkov Properly handle InlineAsmOperand::SymFn when collecting monomorphized items Fixes #72484,HEART,2020-05-25T21:19:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72534,MERGED,2020-05-24T12:45:41Z,2020-05-29T11:17:09Z,Improve missing `@` in slice binding pattern diagnostics,chrissimpkins,d19b51e441833630a53a8966e3bc0ed1c94420f7,3,Rollup merge of #72534 - chrissimpkins:fix-72373 r=estebank Improve missing `@` in slice binding pattern diagnostics Closes https://github.com/rust-lang/rust/issues/72373 Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level. Before: ``` --> src/main.rs:5:19 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | -^ | | | expected one of ` ` `@` `]` or `|` | help: missing ` ` error[E0308]: mismatched types --> src/main.rs:5:46 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected slice `[u32]` found `u32` | = note: expected reference `&[u32]` found reference `&u32` error: aborting due to 2 previous errors ``` After: ``` error: expected one of ` ` `@` `]` or `|` found `..` --> src/main.rs:5:20 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected one of ` ` `@` `]` or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts` use `@` | 5 | [h ref ts @ ..] => foo(c n - h) + foo(ts n) | ^ error: aborting due to previous error ``` r? @estebank,HEART,2020-05-24T19:08:43Z,estebank,NA https://github.com/rust-lang/rust/pull/72534,MERGED,2020-05-24T12:45:41Z,2020-05-29T11:17:09Z,Improve missing `@` in slice binding pattern diagnostics,chrissimpkins,d19b51e441833630a53a8966e3bc0ed1c94420f7,3,Rollup merge of #72534 - chrissimpkins:fix-72373 r=estebank Improve missing `@` in slice binding pattern diagnostics Closes https://github.com/rust-lang/rust/issues/72373 Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level. Before: ``` --> src/main.rs:5:19 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | -^ | | | expected one of ` ` `@` `]` or `|` | help: missing ` ` error[E0308]: mismatched types --> src/main.rs:5:46 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected slice `[u32]` found `u32` | = note: expected reference `&[u32]` found reference `&u32` error: aborting due to 2 previous errors ``` After: ``` error: expected one of ` ` `@` `]` or `|` found `..` --> src/main.rs:5:20 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected one of ` ` `@` `]` or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts` use `@` | 5 | [h ref ts @ ..] => foo(c n - h) + foo(ts n) | ^ error: aborting due to previous error ``` r? @estebank,HEART,2020-05-25T04:56:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72534,MERGED,2020-05-24T12:45:41Z,2020-05-29T11:17:09Z,Improve missing `@` in slice binding pattern diagnostics,chrissimpkins,d19b51e441833630a53a8966e3bc0ed1c94420f7,3,Rollup merge of #72534 - chrissimpkins:fix-72373 r=estebank Improve missing `@` in slice binding pattern diagnostics Closes https://github.com/rust-lang/rust/issues/72373 Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level. Before: ``` --> src/main.rs:5:19 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | -^ | | | expected one of ` ` `@` `]` or `|` | help: missing ` ` error[E0308]: mismatched types --> src/main.rs:5:46 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected slice `[u32]` found `u32` | = note: expected reference `&[u32]` found reference `&u32` error: aborting due to 2 previous errors ``` After: ``` error: expected one of ` ` `@` `]` or `|` found `..` --> src/main.rs:5:20 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected one of ` ` `@` `]` or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts` use `@` | 5 | [h ref ts @ ..] => foo(c n - h) + foo(ts n) | ^ error: aborting due to previous error ``` r? @estebank,HEART,2020-05-25T21:17:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72534,MERGED,2020-05-24T12:45:41Z,2020-05-29T11:17:09Z,Improve missing `@` in slice binding pattern diagnostics,chrissimpkins,d19b51e441833630a53a8966e3bc0ed1c94420f7,3,Rollup merge of #72534 - chrissimpkins:fix-72373 r=estebank Improve missing `@` in slice binding pattern diagnostics Closes https://github.com/rust-lang/rust/issues/72373 Includes a new suggestion with `Applicability::MaybeIncorrect` confidence level. Before: ``` --> src/main.rs:5:19 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | -^ | | | expected one of ` ` `@` `]` or `|` | help: missing ` ` error[E0308]: mismatched types --> src/main.rs:5:46 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected slice `[u32]` found `u32` | = note: expected reference `&[u32]` found reference `&u32` error: aborting due to 2 previous errors ``` After: ``` error: expected one of ` ` `@` `]` or `|` found `..` --> src/main.rs:5:20 | 5 | [h ref ts..] => foo(c n - h) + foo(ts n) | ^^ expected one of ` ` `@` `]` or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts` use `@` | 5 | [h ref ts @ ..] => foo(c n - h) + foo(ts n) | ^ error: aborting due to previous error ``` r? @estebank,HEART,2020-05-31T15:15:03Z,tesuji,NA https://github.com/rust-lang/rust/pull/72538,MERGED,2020-05-24T14:10:56Z,2020-05-26T01:43:46Z,Removed all instances of const_field.,rakshith-ravi,b6a8915b2002352d2d10f5477068bebecc968761,6,Rollup merge of #72538 - rakshith-ravi:refactor/remove-const-query r=oli-obk Removed all instances of const_field. Fixes #72264 r? @oli-obk,HEART,2020-05-24T16:29:35Z,panaman67,NA https://github.com/rust-lang/rust/pull/72552,CLOSED,2020-05-24T22:56:10Z,2020-06-12T18:02:26Z,Introduce `LocalDefId` to `HirId` lookup table,marmeladema,NA,NA,NA,THUMBS_UP,2020-05-25T00:56:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72556,MERGED,2020-05-25T01:38:42Z,2020-06-15T11:40:18Z,Fix trait alias inherent impl resolution,matthew-mcallister,3d41252fcc28d9da1005f3207462e95006c232e4,3,Rollup merge of #72556 - matthew-mcallister:trait-alias-inherent-impl r=estebank Fix trait alias inherent impl resolution Fixes #60021 and fixes #72415. Obviously the fix was very easy but getting started with the testing and debugging rust compiler was an interesting experience. Now I can cross it off my bucket list!,ROCKET,2020-05-26T20:32:57Z,estebank,NA https://github.com/rust-lang/rust/pull/72556,MERGED,2020-05-25T01:38:42Z,2020-06-15T11:40:18Z,Fix trait alias inherent impl resolution,matthew-mcallister,3d41252fcc28d9da1005f3207462e95006c232e4,3,Rollup merge of #72556 - matthew-mcallister:trait-alias-inherent-impl r=estebank Fix trait alias inherent impl resolution Fixes #60021 and fixes #72415. Obviously the fix was very easy but getting started with the testing and debugging rust compiler was an interesting experience. Now I can cross it off my bucket list!,ROCKET,2020-06-13T01:02:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/72559,MERGED,2020-05-25T03:45:17Z,2020-06-25T12:44:40Z,Implement associated lang items,Aaron1011,229e5b2640fc5715e77607a989748be588d983f2,7,Auto merge of #72559 - Aaron1011:feature/assoc-lang-items r=oli-obk Implement associated lang items Fixes #70718 This commit allows making associated items (e.g. associated functions and types) into lang items via the `#[lang]` attribute. This allows such items to be accessed directly rather than by iterating over the parent item's associated items. I've added `FnOnce::Output` as a lang item and updated one old usage to use the new lang item. The remaining uses can be updated separately.,HOORAY,2020-05-25T04:07:26Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72559,MERGED,2020-05-25T03:45:17Z,2020-06-25T12:44:40Z,Implement associated lang items,Aaron1011,229e5b2640fc5715e77607a989748be588d983f2,7,Auto merge of #72559 - Aaron1011:feature/assoc-lang-items r=oli-obk Implement associated lang items Fixes #70718 This commit allows making associated items (e.g. associated functions and types) into lang items via the `#[lang]` attribute. This allows such items to be accessed directly rather than by iterating over the parent item's associated items. I've added `FnOnce::Output` as a lang item and updated one old usage to use the new lang item. The remaining uses can be updated separately.,HOORAY,2020-05-25T05:40:48Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/72559,MERGED,2020-05-25T03:45:17Z,2020-06-25T12:44:40Z,Implement associated lang items,Aaron1011,229e5b2640fc5715e77607a989748be588d983f2,7,Auto merge of #72559 - Aaron1011:feature/assoc-lang-items r=oli-obk Implement associated lang items Fixes #70718 This commit allows making associated items (e.g. associated functions and types) into lang items via the `#[lang]` attribute. This allows such items to be accessed directly rather than by iterating over the parent item's associated items. I've added `FnOnce::Output` as a lang item and updated one old usage to use the new lang item. The remaining uses can be updated separately.,HOORAY,2020-05-25T05:52:42Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72559,MERGED,2020-05-25T03:45:17Z,2020-06-25T12:44:40Z,Implement associated lang items,Aaron1011,229e5b2640fc5715e77607a989748be588d983f2,7,Auto merge of #72559 - Aaron1011:feature/assoc-lang-items r=oli-obk Implement associated lang items Fixes #70718 This commit allows making associated items (e.g. associated functions and types) into lang items via the `#[lang]` attribute. This allows such items to be accessed directly rather than by iterating over the parent item's associated items. I've added `FnOnce::Output` as a lang item and updated one old usage to use the new lang item. The remaining uses can be updated separately.,HOORAY,2020-05-25T10:56:30Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T12:32:30Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T13:00:13Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T13:41:17Z,akofke,akofke@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T14:43:55Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T15:31:24Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T17:02:07Z,darksv,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T17:03:23Z,pmarks,pmarks@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T17:04:32Z,hbina,hanif.ariffin.4326@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T17:48:03Z,bluss,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-25T19:29:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-26T08:02:37Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-05-30T02:02:15Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-03T16:59:21Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-03T18:27:28Z,michael-p,michael.partheil@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-03T18:36:45Z,Virgiel,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-03T19:02:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HOORAY,2020-06-03T19:05:34Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T01:25:33Z,CGMossa,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HOORAY,2020-06-04T01:25:33Z,CGMossa,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T02:10:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HOORAY,2020-06-04T02:10:10Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,THUMBS_UP,2020-06-04T03:18:00Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T05:12:36Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T10:03:19Z,hatoo,hato2000@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T14:41:25Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,THUMBS_UP,2020-06-04T15:02:44Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-04T15:23:22Z,EdorianDark,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-05T06:15:47Z,lnicola,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-05T17:09:28Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,THUMBS_UP,2020-06-06T08:42:02Z,ugoa,hoodavy@gmail.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-06-06T23:30:42Z,setepo,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-07-28T14:21:52Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-07-31T01:03:30Z,acshi,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2020-11-18T04:15:09Z,wchargin,NA https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,HEART,2021-04-26T01:16:25Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/72568,MERGED,2020-05-25T11:34:20Z,2020-05-29T23:43:48Z,Implement total_cmp for f32 f64,golddranks,c09f0eb3eb7ca092fdaeacab37bf05fea1e241f8,5,Rollup merge of #72568 - golddranks:add_total_cmp_to_floats r=sfackler Implement total_cmp for f32 f64 # Overview * Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that unlike the standard `partial_cmp` is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate. * The method has an API similar to `cmp`: `pub fn total_cmp(&self other: &Self) -> crate::cmp::Ordering { ... }`. * Implements tests. * Has documentation. # Justification for the API * Total ordering for `f32` and `f64` has been discussed many time before: * https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701 * https://github.com/rust-lang/rfcs/issues/1249 * https://github.com/rust-lang/rust/pull/53938 * https://github.com/rust-lang/rust/issues/5585 * The lack of total ordering leads to frequent complaints especially from people new to Rust. * This is an ergonomics issue that needs to be addressed. * However the default behaviour of implementing only `PartialOrd` is intentional as relaxing it might lead to correctness issues. * Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is however not easy to add because of the large API surface added. * As a minimal step that hopefully proves uncontroversial we can implement a stand-alone method `total_cmp` on floating point types. * I expect adding such methods should be uncontroversial because... * Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day. * It implements functionality that is standardised. (IEEE 754 2008 rev. §5.10 Note that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.) * With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion providing additional helper methods is a minimal way of adding ordering functionality. * Not also does it allow easily using aforementioned APIs it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper if needed.,THUMBS_UP,2022-04-08T07:08:44Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-06-01T22:57:04Z,estebank,NA https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-06-02T13:41:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-06-11T14:36:20Z,jethrogb,NA https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-06-11T18:06:36Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-06-19T09:47:23Z,AlexeiA,NA https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-07-01T21:26:29Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-07-02T12:51:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-07-13T11:42:16Z,95th,NA https://github.com/rust-lang/rust/pull/72569,MERGED,2020-05-25T12:29:15Z,2020-07-02T12:36:17Z,Remove legacy InnoSetup GUI installer,ChrisDenton,fb976e65a0a2e4368fe0f6e80f9efdc18fb125e4,8,"Rollup merge of #72569 - ChrisDenton:remove-innosetup r=nikomatsakis Remove legacy InnoSetup GUI installer On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed. The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very ""legacy"" at this point. Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase. As a result of removing InnoSetup this closes #24397",THUMBS_UP,2020-08-04T14:27:50Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,EYES,2020-05-25T13:26:44Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,LAUGH,2020-05-25T13:31:21Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,LAUGH,2020-05-25T14:13:07Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,LAUGH,2020-05-25T19:32:17Z,mati865,NA https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,EYES,2020-05-25T21:11:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,LAUGH,2020-05-27T00:32:29Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,LAUGH,2020-10-04T18:50:02Z,camelid,NA https://github.com/rust-lang/rust/pull/72571,OPEN,2020-05-25T13:24:31Z,NA,[WIP] Pietro's CI playground,pietroalbini,NA,NA,NA,EYES,2021-07-15T21:21:05Z,tema3210,NA https://github.com/rust-lang/rust/pull/72572,MERGED,2020-05-25T13:33:04Z,2020-05-29T23:43:47Z,Add some regression tests,JohnTitor,89cb4d75a104d772e8f40e43eabb0122e71eacb1,5,Rollup merge of #72572 - JohnTitor:add-tests r=matthewjasper Add some regression tests Closes #68532 Closes #70121 Closes #71042 CC #56445 r? @matthewjasper since they (except for #71042) are related to #72362.,HOORAY,2020-05-27T07:11:55Z,95th,NA https://github.com/rust-lang/rust/pull/72572,MERGED,2020-05-25T13:33:04Z,2020-05-29T23:43:47Z,Add some regression tests,JohnTitor,89cb4d75a104d772e8f40e43eabb0122e71eacb1,5,Rollup merge of #72572 - JohnTitor:add-tests r=matthewjasper Add some regression tests Closes #68532 Closes #70121 Closes #71042 CC #56445 r? @matthewjasper since they (except for #71042) are related to #72362.,HOORAY,2020-05-29T16:44:04Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72583,MERGED,2020-05-25T19:26:15Z,2020-06-08T20:11:01Z,impl AsRef<[T]> for vec::IntoIter,CAD97,b0559bebd800b763700063a6610f6416ea5679c0,1,"Rollup merge of #72583 - CAD97:vec-iter-asref-slice r=dtolnay impl AsRef<[T]> for vec::IntoIter Adds `impl AsRef<[T]> for vec::IntoIter`. This mirrors the same trait impl for [`slice::Iter`](https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html). Both types already offer `fn as_slice(&self) -> &[T]` this just adds the trait impl for `vec::IntoIter`. If/when `fn as_slice(&self) -> &[T]` stabilizes for `vec::Drain` and `slice::IterMut` they should get `AsRef<[T]>` impls as well. As thus tangentially related to #58957. My ultimate goal here: being able to use `for + AsRef<[T]>> I` to refer to `vec::IntoIter` `vec::Drain` and eventually `array::IntoIter` as an approximation of the set of by-value iterators that can be ""previewed"" as by-ref iterators. (Actually expressing that as a trait requires GAT.)",HOORAY,2020-06-10T23:41:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72584,MERGED,2020-05-25T19:40:41Z,2020-06-15T11:40:16Z,Stabilize vec::Drain::as_slice,CAD97,e6510babc786469075f76db94fedfe651072bf25,1,"Rollup merge of #72584 - CAD97:stabilize-58957 r=dtolnay Stabilize vec::Drain::as_slice and add `AsRef<[T]> for Drain<'_ T>`. Tracking issue: #58957. Does not stabilize `slice::IterMut::as_slice` yet. cc @cuviper This PR proposes stabilizing just the `vec::Drain::as_slice` part of that tracking issue. My ultimate goal here: being able to use `for + AsRef<[T]>> I` to refer to `vec::IntoIter` `vec::Drain` and eventually `array::IntoIter` as an approximation of the set of by-value iterators that can be ""previewed"" as by-ref iterators. (Actually expressing that as a trait requires GAT.)",THUMBS_UP,2020-08-25T07:36:32Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72591,MERGED,2020-05-25T22:20:40Z,2020-05-29T23:43:45Z,librustc_middle: Rename upvar_list to closure_captures,null-sleep,ed80e8e3e0d042dbcb5c24ef3593acab55d862e2,7,Rollup merge of #72591 - sexxi-goose:rename_upvar_list-to-closure_captures r=matthewjasper librustc_middle: Rename upvar_list to closure_captures As part of supporting RFC 2229 we will be capturing all the places that are mentioned in a closure. Currently the `upvar_list` field gives access to a `FxIndexMap` map. Eventually this will change with the `upvar_list` having a more general structure that expresses captured paths not just the mentioned `upvars`. We will make those changes in subsequent PRs. This commit modifies the name of the `upvar_list` map to `closure_captures` in `TypeckTables`. r? @matthewjasper,THUMBS_UP,2020-05-26T00:21:01Z,roxelo,NA https://github.com/rust-lang/rust/pull/72591,MERGED,2020-05-25T22:20:40Z,2020-05-29T23:43:45Z,librustc_middle: Rename upvar_list to closure_captures,null-sleep,ed80e8e3e0d042dbcb5c24ef3593acab55d862e2,7,Rollup merge of #72591 - sexxi-goose:rename_upvar_list-to-closure_captures r=matthewjasper librustc_middle: Rename upvar_list to closure_captures As part of supporting RFC 2229 we will be capturing all the places that are mentioned in a closure. Currently the `upvar_list` field gives access to a `FxIndexMap` map. Eventually this will change with the `upvar_list` having a more general structure that expresses captured paths not just the mentioned `upvars`. We will make those changes in subsequent PRs. This commit modifies the name of the `upvar_list` map to `closure_captures` in `TypeckTables`. r? @matthewjasper,THUMBS_UP,2020-05-26T01:53:57Z,arora-aman,NA https://github.com/rust-lang/rust/pull/72591,MERGED,2020-05-25T22:20:40Z,2020-05-29T23:43:45Z,librustc_middle: Rename upvar_list to closure_captures,null-sleep,ed80e8e3e0d042dbcb5c24ef3593acab55d862e2,7,Rollup merge of #72591 - sexxi-goose:rename_upvar_list-to-closure_captures r=matthewjasper librustc_middle: Rename upvar_list to closure_captures As part of supporting RFC 2229 we will be capturing all the places that are mentioned in a closure. Currently the `upvar_list` field gives access to a `FxIndexMap` map. Eventually this will change with the `upvar_list` having a more general structure that expresses captured paths not just the mentioned `upvars`. We will make those changes in subsequent PRs. This commit modifies the name of the `upvar_list` map to `closure_captures` in `TypeckTables`. r? @matthewjasper,THUMBS_UP,2020-05-26T07:31:13Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72591,MERGED,2020-05-25T22:20:40Z,2020-05-29T23:43:45Z,librustc_middle: Rename upvar_list to closure_captures,null-sleep,ed80e8e3e0d042dbcb5c24ef3593acab55d862e2,7,Rollup merge of #72591 - sexxi-goose:rename_upvar_list-to-closure_captures r=matthewjasper librustc_middle: Rename upvar_list to closure_captures As part of supporting RFC 2229 we will be capturing all the places that are mentioned in a closure. Currently the `upvar_list` field gives access to a `FxIndexMap` map. Eventually this will change with the `upvar_list` having a more general structure that expresses captured paths not just the mentioned `upvars`. We will make those changes in subsequent PRs. This commit modifies the name of the `upvar_list` map to `closure_captures` in `TypeckTables`. r? @matthewjasper,THUMBS_UP,2020-05-26T17:27:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72598,MERGED,2020-05-26T01:58:42Z,2020-06-15T11:40:15Z,Display information about captured variable in `FnMut` error,Aaron1011,5193c5d60881e19afdfbab98cbc7ba6b7607ee18,17,Rollup merge of #72598 - Aaron1011:feature/fnmut-capture-span r=nikomatsakis Display information about captured variable in `FnMut` error Fixes #69446 When we encounter a region error involving an `FnMut` closure we display a specialized error message. However we currently do not tell the user which upvar was captured. This makes it difficult to determine the cause of the error especially when the closure is large. This commit records marks constraints involving closure upvars with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame' a `ConstraintCategory::Return` we additionall store the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in the path. When generating an error message we point to relevant spans if we have closure upvar information available. We further customize the message if an `async` closure is being returned to make it clear that the captured variable is being returned indirectly.,HEART,2020-06-15T12:16:16Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72598,MERGED,2020-05-26T01:58:42Z,2020-06-15T11:40:15Z,Display information about captured variable in `FnMut` error,Aaron1011,5193c5d60881e19afdfbab98cbc7ba6b7607ee18,17,Rollup merge of #72598 - Aaron1011:feature/fnmut-capture-span r=nikomatsakis Display information about captured variable in `FnMut` error Fixes #69446 When we encounter a region error involving an `FnMut` closure we display a specialized error message. However we currently do not tell the user which upvar was captured. This makes it difficult to determine the cause of the error especially when the closure is large. This commit records marks constraints involving closure upvars with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame' a `ConstraintCategory::Return` we additionall store the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in the path. When generating an error message we point to relevant spans if we have closure upvar information available. We further customize the message if an `async` closure is being returned to make it clear that the captured variable is being returned indirectly.,THUMBS_UP,2020-07-19T10:30:26Z,95th,NA https://github.com/rust-lang/rust/pull/72598,MERGED,2020-05-26T01:58:42Z,2020-06-15T11:40:15Z,Display information about captured variable in `FnMut` error,Aaron1011,5193c5d60881e19afdfbab98cbc7ba6b7607ee18,17,Rollup merge of #72598 - Aaron1011:feature/fnmut-capture-span r=nikomatsakis Display information about captured variable in `FnMut` error Fixes #69446 When we encounter a region error involving an `FnMut` closure we display a specialized error message. However we currently do not tell the user which upvar was captured. This makes it difficult to determine the cause of the error especially when the closure is large. This commit records marks constraints involving closure upvars with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame' a `ConstraintCategory::Return` we additionall store the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in the path. When generating an error message we point to relevant spans if we have closure upvar information available. We further customize the message if an `async` closure is being returned to make it clear that the captured variable is being returned indirectly.,HEART,2020-07-19T10:30:29Z,95th,NA https://github.com/rust-lang/rust/pull/72600,MERGED,2020-05-26T04:20:29Z,2020-06-20T22:54:33Z,Properly encode AnonConst into crate metadata,Aaron1011,5431ef65303bb1ec71a42910fc55ecfa62b6d781,5,Rollup merge of #72600 - Aaron1011:fix/anon-const-encoding r=varkor Properly encode AnonConst into crate metadata Fixes #68104 Previous we were encoding AnonConst as a regular Const causing us to treat them differently after being deserialized in another compilation session.,HEART,2020-05-26T07:35:02Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72600,MERGED,2020-05-26T04:20:29Z,2020-06-20T22:54:33Z,Properly encode AnonConst into crate metadata,Aaron1011,5431ef65303bb1ec71a42910fc55ecfa62b6d781,5,Rollup merge of #72600 - Aaron1011:fix/anon-const-encoding r=varkor Properly encode AnonConst into crate metadata Fixes #68104 Previous we were encoding AnonConst as a regular Const causing us to treat them differently after being deserialized in another compilation session.,HEART,2020-05-26T16:10:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72600,MERGED,2020-05-26T04:20:29Z,2020-06-20T22:54:33Z,Properly encode AnonConst into crate metadata,Aaron1011,5431ef65303bb1ec71a42910fc55ecfa62b6d781,5,Rollup merge of #72600 - Aaron1011:fix/anon-const-encoding r=varkor Properly encode AnonConst into crate metadata Fixes #68104 Previous we were encoding AnonConst as a regular Const causing us to treat them differently after being deserialized in another compilation session.,HEART,2020-05-26T17:01:03Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/72603,MERGED,2020-05-26T05:42:36Z,2021-02-08T05:05:56Z,Implement `--extern-location`,jsgf,0b7a598e12649d7ab2415a82cbc3fea879fa9dab,37,"Auto merge of #72603 - jsgf:extern-loc r=nikomatsakis Implement `--extern-location` This PR implements `--extern-location` as a followup to #72342 as part of the implementation of #57274. The goal of this PR is to allow rustc in coordination with the build system to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml). EDIT: Updated to current PR state. The location is specified for each named crate - that is for a given `--extern foo[=path]` there can also be `--extern-location foo=`. It supports ~~three~~ two styles of location: ~~1. `--extern-location foo=file::` - a file path and line specification 1. `--extern-location foo=span:::` - a span specified as a file and start and end byte offsets~~ 1. `--extern-location foo=raw:` - a raw string which is included in the output 1. `--extern-location foo=json:` - an arbitrary Json structure which is emitted via Json diagnostics in a `tool_metadata` field. ~~1 & 2 are turned into an internal `Span` so long as the path exists and is readable and the location is meaningful (within the file etc). This is used as the `Span` for a fix suggestion which is reported like other fix suggestions.~~ `raw` and `json` are for the case where the location isn't best expressed as a file and location within that file. For example it could be a rule name and the name of a dependency within that rule. `rustc` makes no attempt to parse the raw string and simply includes it in the output diagnostic text. `json` is only included in json diagnostics. `raw` is emitted as text and also as a json string in `tool_metadata`. If no `--extern-location` option is specified then it will emit a default json structure consisting of `{""name"": name ""path"": path}` corresponding to the name and path in `--extern name=path`. This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well. ~~**NOTE** The first commit in this PR is #72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only presented as a MVP. The second implements the full thing and subsequent commits are incremental fixes.~~ cc `@ehuss` `@est31` `@petrochenkov` `@estebank`",THUMBS_UP,2020-05-26T09:24:26Z,est31,NA https://github.com/rust-lang/rust/pull/72603,MERGED,2020-05-26T05:42:36Z,2021-02-08T05:05:56Z,Implement `--extern-location`,jsgf,0b7a598e12649d7ab2415a82cbc3fea879fa9dab,37,"Auto merge of #72603 - jsgf:extern-loc r=nikomatsakis Implement `--extern-location` This PR implements `--extern-location` as a followup to #72342 as part of the implementation of #57274. The goal of this PR is to allow rustc in coordination with the build system to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml). EDIT: Updated to current PR state. The location is specified for each named crate - that is for a given `--extern foo[=path]` there can also be `--extern-location foo=`. It supports ~~three~~ two styles of location: ~~1. `--extern-location foo=file::` - a file path and line specification 1. `--extern-location foo=span:::` - a span specified as a file and start and end byte offsets~~ 1. `--extern-location foo=raw:` - a raw string which is included in the output 1. `--extern-location foo=json:` - an arbitrary Json structure which is emitted via Json diagnostics in a `tool_metadata` field. ~~1 & 2 are turned into an internal `Span` so long as the path exists and is readable and the location is meaningful (within the file etc). This is used as the `Span` for a fix suggestion which is reported like other fix suggestions.~~ `raw` and `json` are for the case where the location isn't best expressed as a file and location within that file. For example it could be a rule name and the name of a dependency within that rule. `rustc` makes no attempt to parse the raw string and simply includes it in the output diagnostic text. `json` is only included in json diagnostics. `raw` is emitted as text and also as a json string in `tool_metadata`. If no `--extern-location` option is specified then it will emit a default json structure consisting of `{""name"": name ""path"": path}` corresponding to the name and path in `--extern name=path`. This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well. ~~**NOTE** The first commit in this PR is #72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only presented as a MVP. The second implements the full thing and subsequent commits are incremental fixes.~~ cc `@ehuss` `@est31` `@petrochenkov` `@estebank`",THUMBS_UP,2020-10-06T03:08:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72603,MERGED,2020-05-26T05:42:36Z,2021-02-08T05:05:56Z,Implement `--extern-location`,jsgf,0b7a598e12649d7ab2415a82cbc3fea879fa9dab,37,"Auto merge of #72603 - jsgf:extern-loc r=nikomatsakis Implement `--extern-location` This PR implements `--extern-location` as a followup to #72342 as part of the implementation of #57274. The goal of this PR is to allow rustc in coordination with the build system to present a useful diagnostic about how to remove an unnecessary dependency from a dependency specification file (eg Cargo.toml). EDIT: Updated to current PR state. The location is specified for each named crate - that is for a given `--extern foo[=path]` there can also be `--extern-location foo=`. It supports ~~three~~ two styles of location: ~~1. `--extern-location foo=file::` - a file path and line specification 1. `--extern-location foo=span:::` - a span specified as a file and start and end byte offsets~~ 1. `--extern-location foo=raw:` - a raw string which is included in the output 1. `--extern-location foo=json:` - an arbitrary Json structure which is emitted via Json diagnostics in a `tool_metadata` field. ~~1 & 2 are turned into an internal `Span` so long as the path exists and is readable and the location is meaningful (within the file etc). This is used as the `Span` for a fix suggestion which is reported like other fix suggestions.~~ `raw` and `json` are for the case where the location isn't best expressed as a file and location within that file. For example it could be a rule name and the name of a dependency within that rule. `rustc` makes no attempt to parse the raw string and simply includes it in the output diagnostic text. `json` is only included in json diagnostics. `raw` is emitted as text and also as a json string in `tool_metadata`. If no `--extern-location` option is specified then it will emit a default json structure consisting of `{""name"": name ""path"": path}` corresponding to the name and path in `--extern name=path`. This is a prototype/RFC to make some of the earlier conversations more concrete. It doesn't stand on its own - it's only useful if implemented by Cargo and other build systems. There's also a ton of implementation details which I'd appreciate a second eye on as well. ~~**NOTE** The first commit in this PR is #72342 and should be ignored for the purposes of review. The first commit is a very simplistic implementation which is basically raw-only presented as a MVP. The second implements the full thing and subsequent commits are incremental fixes.~~ cc `@ehuss` `@est31` `@petrochenkov` `@estebank`",THUMBS_UP,2021-01-12T01:14:39Z,estebank,NA https://github.com/rust-lang/rust/pull/72621,MERGED,2020-05-26T18:30:53Z,2020-05-30T11:29:27Z,Don't bail out of trait selection when predicate references an error,Aaron1011,7624ac7dc4b44f5ef9d1ee1e9959e251db77d5ab,3,Rollup merge of #72621 - Aaron1011:fix/trait-select-error r=nikomatsakis Don't bail out of trait selection when predicate references an error Fixes #72590 With PR #70551 observing a `ty::Error` guarantees that compilation is going to fail. Therefore there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out we avoid incorrectly determining that types are `!Sized` when a type error is present which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver this change resulted in no diagnostic changes in any of the existing tests.,HEART,2020-05-29T00:34:02Z,estebank,NA https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-05-27T06:40:13Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-05-30T06:22:06Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-05-30T12:59:53Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-06-24T22:06:57Z,estebank,NA https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,THUMBS_UP,2020-06-25T03:46:18Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-06-25T05:48:24Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-06-25T17:48:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/72623,MERGED,2020-05-26T19:21:39Z,2020-06-22T16:39:10Z,Prefer accessible paths in 'use' suggestions,da-x,fdd241f5b39f874b694e70f4f0bf4161af2ee47e,13,Rollup merge of #72623 - da-x:use-suggest-public-path r=petrochenkov 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;` ```,HOORAY,2020-10-13T16:17:23Z,valff,valentine.valyaeff@gmail.com https://github.com/rust-lang/rust/pull/72625,MERGED,2020-05-26T19:48:41Z,2020-05-31T01:08:01Z,Improve inline asm error diagnostics,Amanieu,fadfcb644e3e549b5b080260d4ca4ea2696e7007,29,"Rollup merge of #72625 - Amanieu:asm-srcloc r=petrochenkov Improve inline asm error diagnostics Previously we were just using the raw LLVM error output (with line caret etc) as the diagnostic message which ends up looking rather out of place with our existing diagnostics. The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code. Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate. Fixes #72664 Fixes #71639 r? @petrochenkov ### Old style ```rust #![feature(llvm_asm)] fn main() { unsafe { let _x: i32; llvm_asm!( ""mov $0 $1 invalid_instruction $0 $1 mov $0 $1"" : ""=&r"" (_x) : ""r"" (0) :: ""intel"" ); } } ``` ``` error: :3:14: error: invalid instruction mnemonic 'invalid_instruction' invalid_instruction ecx eax ^~~~~~~~~~~~~~~~~~~ --> src/main.rs:6:9 | 6 | / llvm_asm!( 7 | | ""mov $0 $1 8 | | invalid_instruction $0 $1 9 | | mov $0 $1"" ... | 12 | | :: ""intel"" 13 | | ); | |__________^ ``` ### New style ```rust #![feature(asm)] fn main() { unsafe { asm!( ""mov {0} {1} invalid_instruction {0} {1} mov {0} {1}"" out(reg) _ in(reg) 0i64 ); } } ``` ``` error: invalid instruction mnemonic 'invalid_instruction' --> test.rs:7:14 | 7 | invalid_instruction {0} {1} | ^ | note: instantiated into assembly here --> :3:14 | 3 | invalid_instruction rax rcx | ^^^^^^^^^^^^^^^^^^^ ```",HEART,2020-05-27T18:00:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72625,MERGED,2020-05-26T19:48:41Z,2020-05-31T01:08:01Z,Improve inline asm error diagnostics,Amanieu,fadfcb644e3e549b5b080260d4ca4ea2696e7007,29,"Rollup merge of #72625 - Amanieu:asm-srcloc r=petrochenkov Improve inline asm error diagnostics Previously we were just using the raw LLVM error output (with line caret etc) as the diagnostic message which ends up looking rather out of place with our existing diagnostics. The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code. Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate. Fixes #72664 Fixes #71639 r? @petrochenkov ### Old style ```rust #![feature(llvm_asm)] fn main() { unsafe { let _x: i32; llvm_asm!( ""mov $0 $1 invalid_instruction $0 $1 mov $0 $1"" : ""=&r"" (_x) : ""r"" (0) :: ""intel"" ); } } ``` ``` error: :3:14: error: invalid instruction mnemonic 'invalid_instruction' invalid_instruction ecx eax ^~~~~~~~~~~~~~~~~~~ --> src/main.rs:6:9 | 6 | / llvm_asm!( 7 | | ""mov $0 $1 8 | | invalid_instruction $0 $1 9 | | mov $0 $1"" ... | 12 | | :: ""intel"" 13 | | ); | |__________^ ``` ### New style ```rust #![feature(asm)] fn main() { unsafe { asm!( ""mov {0} {1} invalid_instruction {0} {1} mov {0} {1}"" out(reg) _ in(reg) 0i64 ); } } ``` ``` error: invalid instruction mnemonic 'invalid_instruction' --> test.rs:7:14 | 7 | invalid_instruction {0} {1} | ^ | note: instantiated into assembly here --> :3:14 | 3 | invalid_instruction rax rcx | ^^^^^^^^^^^^^^^^^^^ ```",HEART,2020-05-29T01:17:01Z,estebank,NA https://github.com/rust-lang/rust/pull/72628,MERGED,2020-05-26T20:53:59Z,2020-06-19T05:04:07Z,Add tests for 'impl Default for [T; N]',MikailBag,9262fc2a68133330a8f78c73afa54b3ff09724b5,1,Rollup merge of #72628 - MikailBag:array-default-tests r=shepmaster Add tests for 'impl Default for [T; N]' Related: #71690. This pull request adds two tests: - Even it T::default() panics no leaks occur. - [T; 0] is Default even if T is not. I believe at some moment `Default` impl for arrays will be rewritten to use const generics instead of macros and these tests will help to prevent behavior changes.,HEART,2020-05-27T16:43:21Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72628,MERGED,2020-05-26T20:53:59Z,2020-06-19T05:04:07Z,Add tests for 'impl Default for [T; N]',MikailBag,9262fc2a68133330a8f78c73afa54b3ff09724b5,1,Rollup merge of #72628 - MikailBag:array-default-tests r=shepmaster Add tests for 'impl Default for [T; N]' Related: #71690. This pull request adds two tests: - Even it T::default() panics no leaks occur. - [T; 0] is Default even if T is not. I believe at some moment `Default` impl for arrays will be rewritten to use const generics instead of macros and these tests will help to prevent behavior changes.,HEART,2020-07-05T15:56:36Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-26T21:34:17Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-26T21:34:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-26T21:35:34Z,bugadani,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-26T22:12:04Z,bluss,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-26T22:26:29Z,CryZe,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-26T22:26:32Z,CryZe,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-26T22:35:12Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-26T23:01:49Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-26T23:01:50Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-26T23:05:44Z,darksv,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T00:02:50Z,mati865,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-27T00:02:53Z,mati865,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T00:09:31Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T00:13:39Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T03:23:59Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T08:22:46Z,darksv,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T10:00:09Z,95th,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-27T10:00:11Z,95th,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-27T10:29:35Z,efenniht,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T16:30:15Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-27T16:30:17Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T17:58:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T20:28:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-27T23:30:52Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-28T22:29:42Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-05-29T14:46:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-29T14:46:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-05-30T15:33:22Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,THUMBS_UP,2020-05-30T22:46:39Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-06-05T07:52:07Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,THUMBS_UP,2020-06-09T20:56:56Z,oleid,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,ROCKET,2020-06-25T00:50:31Z,felix91gr,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-06-25T10:42:48Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-07-25T02:15:42Z,localvoid,localvoid@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-07-25T02:15:45Z,localvoid,localvoid@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-08-03T20:52:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-08-21T06:51:10Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HOORAY,2020-09-21T01:15:02Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-09-21T11:43:37Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/72632,MERGED,2020-05-26T21:28:42Z,2020-09-20T04:17:34Z,Implement a generic Destination Propagation optimization on MIR,jonas-schievink,255a4c58f5863ed41c2e68792799125c6c676575,35,Auto merge of #72632 - jonas-schievink:dest-prop r=oli-obk Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in https://github.com/rust-lang/rust/pull/47954 and then explored by me in https://github.com/rust-lang/rust/pull/71003 and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress` which caused trouble in my last attempt but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher if it is too slow to run in debug mode but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine or if not merge the variable's live ranges (or remove these statements entirely – https://github.com/rust-lang/rust/issues/68622). Some benchmarks of the pass were done in https://github.com/rust-lang/rust/pull/72635.,HEART,2020-09-24T17:21:57Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/72635,CLOSED,2020-05-26T22:52:26Z,2020-07-17T21:23:43Z,[perf] Measure Destination Propagation performance,jonas-schievink,NA,NA,NA,EYES,2020-05-27T17:59:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72644,CLOSED,2020-05-27T06:27:33Z,2020-06-02T07:21:50Z,[DO NOT MERGE] [crater experiment] make unaligned_referenced deny-by-default,RalfJung,NA,NA,NA,THUMBS_UP,2020-05-27T07:02:40Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/72656,CLOSED,2020-05-27T14:44:37Z,2020-05-28T16:53:44Z,Remove noisy suggestion of hash_map,ayushmishra2005,NA,NA,NA,EYES,2020-05-27T15:09:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/72674,MERGED,2020-05-27T21:28:44Z,2020-05-29T04:05:18Z,Clippy should always build,Mark-Simulacrum,feaceb2063688c401a41d4d7aafc8f5735afa30a,1,Rollup merge of #72674 - Mark-Simulacrum:clippy-always-test-pass r=oli-obk Clippy should always build This just unwraps clippy's build step instead of skipping tests if clippy didn't build. This matches e.g. cargo's behavior and seems more correct as we always expect clippy to successfully build. I believe this doesn't actually change anything in practice but I feel mildly uncomfortable potentially leaving this hole open.,HEART,2020-05-27T21:37:30Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/72674,MERGED,2020-05-27T21:28:44Z,2020-05-29T04:05:18Z,Clippy should always build,Mark-Simulacrum,feaceb2063688c401a41d4d7aafc8f5735afa30a,1,Rollup merge of #72674 - Mark-Simulacrum:clippy-always-test-pass r=oli-obk Clippy should always build This just unwraps clippy's build step instead of skipping tests if clippy didn't build. This matches e.g. cargo's behavior and seems more correct as we always expect clippy to successfully build. I believe this doesn't actually change anything in practice but I feel mildly uncomfortable potentially leaving this hole open.,HEART,2020-05-28T07:09:48Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72674,MERGED,2020-05-27T21:28:44Z,2020-05-29T04:05:18Z,Clippy should always build,Mark-Simulacrum,feaceb2063688c401a41d4d7aafc8f5735afa30a,1,Rollup merge of #72674 - Mark-Simulacrum:clippy-always-test-pass r=oli-obk Clippy should always build This just unwraps clippy's build step instead of skipping tests if clippy didn't build. This matches e.g. cargo's behavior and seems more correct as we always expect clippy to successfully build. I believe this doesn't actually change anything in practice but I feel mildly uncomfortable potentially leaving this hole open.,HEART,2020-05-28T13:33:05Z,ebroto,NA https://github.com/rust-lang/rust/pull/72674,MERGED,2020-05-27T21:28:44Z,2020-05-29T04:05:18Z,Clippy should always build,Mark-Simulacrum,feaceb2063688c401a41d4d7aafc8f5735afa30a,1,Rollup merge of #72674 - Mark-Simulacrum:clippy-always-test-pass r=oli-obk Clippy should always build This just unwraps clippy's build step instead of skipping tests if clippy didn't build. This matches e.g. cargo's behavior and seems more correct as we always expect clippy to successfully build. I believe this doesn't actually change anything in practice but I feel mildly uncomfortable potentially leaving this hole open.,HEART,2020-05-28T18:01:22Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/72697,MERGED,2020-05-28T15:27:52Z,2020-05-29T04:05:13Z,Remove rustc-ux-guidelines,ehuss,ada9c11489519e9d610b1549e016a94d983ec5f4,1,Rollup merge of #72697 - ehuss:rm-rustc-ux-guidelines r=nikomatsakis Remove rustc-ux-guidelines This is now in the rustc-dev-guide: * https://github.com/rust-lang/rustc-dev-guide/pull/716 * https://github.com/rust-lang/rustc-dev-guide/pull/717 This is a public page but it was not linked to anywhere so I think it is safe to remove. Google searches don't show it being used anywhere.,THUMBS_UP,2020-05-28T16:03:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72700,MERGED,2020-05-28T16:31:14Z,2020-06-25T16:29:42Z,`improper_ctypes_definitions` lint,davidtwco,67db7a2d0553795d004e5e749e3ea73978c6f723,18,"Rollup merge of #72700 - davidtwco:issue-66220-improper-ctypes-declarations r=lcnr varkor `improper_ctypes_definitions` lint Addresses #19834 #66220 and #66373. This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern ""C"" fn` definitions in addition to `extern ""C"" {}` declarations this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern ""C"" fn` definitions. In addition the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220). There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing. cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220) @SimonSapin (#65134 caused problems for Servo want to make sure that this PR doesn't)",HEART,2020-05-28T18:55:01Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/72704,MERGED,2020-05-28T18:59:03Z,2020-06-03T04:42:12Z,Remote testing fixes,tblah,b47896492ce19f911d5585055037e6e9e02ecd34,5,"Rollup merge of #72704 - tblah:remote-testing-fixes r=Mark-Simulacrum Remote testing fixes Improvements for remote testing - Create a `RUST_TEST_TMPDIR` directory on the remote testing host - Verbose mode for remote-test-server - Skip tests which don't support remote testing using `// ignore-remote` To test: - Build `remote-test-server` for the target machine and copy it over - On the target: ``` sh remote-test-server remote ``` - On the build machine ``` sh export TEST_DEVICE_ADDR=""1.2.3.4:12345"" ./x.py test ```",THUMBS_UP,2020-05-31T15:53:54Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/72705,MERGED,2020-05-28T19:05:21Z,2020-06-28T08:27:02Z,Added io forwarding methods to the stdio structs,Lucretiel,3b4a3d68b5d3026bab9d41fcc004439207ecff90,1,Auto merge of #72705 - Lucretiel:stdio-forwarding r=Amanieu Added io forwarding methods to the stdio structs Added methods to forward the `io::Read` and `io::Write` methods of the myriad wrapper structs in `stdio.rs` to their underlying readers / writers. This is especially important for the structs on the outside of a locking boundary to ensure that the lock isn't being dropped and re-acquired in a loop.,HEART,2020-06-28T15:07:43Z,bluss,NA https://github.com/rust-lang/rust/pull/72709,MERGED,2020-05-28T21:35:52Z,2020-06-20T02:23:44Z,`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc,LeSeulArtichaut,55479de2993195bedafdc2104db21e52709ed137,19,Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc r=nikomatsakis `#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065 Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?,HEART,2020-05-28T21:55:49Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72709,MERGED,2020-05-28T21:35:52Z,2020-06-20T02:23:44Z,`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc,LeSeulArtichaut,55479de2993195bedafdc2104db21e52709ed137,19,Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc r=nikomatsakis `#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065 Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?,HEART,2020-05-29T17:13:37Z,mati865,NA https://github.com/rust-lang/rust/pull/72709,MERGED,2020-05-28T21:35:52Z,2020-06-20T02:23:44Z,`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc,LeSeulArtichaut,55479de2993195bedafdc2104db21e52709ed137,19,Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc r=nikomatsakis `#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065 Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?,HEART,2020-05-31T07:20:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72709,MERGED,2020-05-28T21:35:52Z,2020-06-20T02:23:44Z,`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc,LeSeulArtichaut,55479de2993195bedafdc2104db21e52709ed137,19,Rollup merge of #72709 - LeSeulArtichaut:unsafe-liballoc r=nikomatsakis `#[deny(unsafe_op_in_unsafe_fn)]` in liballoc This PR proposes to make use of the new `unsafe_op_in_unsafe_fn` lint i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations. This has been first (partly) suggested by @Mark-Simulacrum in https://github.com/rust-lang/rust/pull/69245#issuecomment-587817065 Tracking issue for the feature: #71668. ~~Blocked on #71862.~~ r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?,HEART,2020-06-05T14:39:44Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/72715,MERGED,2020-05-28T23:33:35Z,2020-05-31T17:15:01Z,Account for trailing comma when suggesting `where` clauses,estebank,b714f5c9acc1732e0e9e0269073272534995bafd,4,Rollup merge of #72715 - estebank:trailing-comma-where r=petrochenkov Account for trailing comma when suggesting `where` clauses Fix #72693.,HEART,2020-05-31T17:22:43Z,jplatte,NA https://github.com/rust-lang/rust/pull/72717,MERGED,2020-05-29T01:07:04Z,2020-06-25T21:27:25Z,Add TryFrom<{int}> for NonZero{int},poliorcetics,50fc24d8a172a853b5dfe40702d6550e3b8562ba,2,"Auto merge of #72717 - poliorcetics:try-from-int-to-nzint r=dtolnay Add TryFrom<{int}> for NonZero{int} Adds `TryFrom<{int}> for NonZero{int}`. It uses the existing `NonZero{int}::new()` and `Option::ok_or()` functions meaning the checks are not repeated. I also added tests I tried to follow the convention I saw in the test file. I also used `#[stable(feature = ""nzint_try_from_int_conv"" since = ""1.46.0"")]` but I have no idea if the feature/version are correctly named or even correct.",THUMBS_UP,2020-08-25T07:35:23Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72720,MERGED,2020-05-29T01:31:34Z,2020-05-29T11:16:47Z,Clarify the documentation of `take`,poliorcetics,fb506af138c40ebc3a62ada931259d60a74a6266,1,Rollup merge of #72720 - poliorcetics:clarify-take-doc r=joshtriplett Clarify the documentation of `take` This PR addresses the concerns of #61222 adding an example for the behaviour of `Iterator::take` when there are less than `n` elements.,HEART,2020-05-29T15:43:13Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72740,MERGED,2020-05-29T16:26:09Z,2020-06-15T15:22:23Z,On recursive ADT provide indirection structured suggestion,estebank,d97e8ca33524399620aef1c0053f8b593bfbf521,28,Rollup merge of #72740 - estebank:recursive-indirection r=matthewjasper On recursive ADT provide indirection structured suggestion,HEART,2020-05-29T17:34:08Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72757,MERGED,2020-05-29T19:58:49Z,2020-05-31T01:07:43Z,rustc_lexer: Optimize shebang detection slightly,petrochenkov,32481bc80ada911e638cde861d17eddc8338d49a,3,Rollup merge of #72757 - petrochenkov:shebang r=varkor rustc_lexer: Optimize shebang detection slightly Sorry I just couldn't resist. It shouldn't make any difference in practice. Also documented a previously unnoticed case with doc comments treated as regular comments during shebang detection.,THUMBS_UP,2020-05-30T13:42:52Z,rcoh,rcoh@rcoh.me https://github.com/rust-lang/rust/pull/72759,MERGED,2020-05-29T20:45:44Z,2020-05-31T13:39:11Z,Update compiler-builtins,alexcrichton,4b1f86adbe41e8dd4864ca2315f43953dd503bb5,2,Auto merge of #72759 - alexcrichton:update-compiler-builtins r=Mark-Simulacrum Update compiler-builtins Pulls in a fix for #72758 more details on the linked issue. [Crate changes included here][changes] [changes]: https://github.com/rust-lang/compiler-builtins/compare/0.1.28...0.1.31 Closes #72758,THUMBS_UP,2021-10-02T16:57:32Z,mverleg,mverleg.noreply@gmail.com https://github.com/rust-lang/rust/pull/72767,MERGED,2020-05-30T03:25:33Z,2020-05-31T20:59:05Z,Track devirtualized filenames,pnkfelix,5fd2f06e99a985dd896684cb2c9f8c7090eca1ab,14,Auto merge of #72767 - pnkfelix:track-devirtualized-filenames-issue-70924 r=eddyb Track devirtualized filenames Split payload of FileName::Real to track both real and virtualized paths. (Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`) This way we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts while still using the devirtualized file path when we want to access the file. Fix #70924,HOORAY,2020-06-02T07:58:45Z,gendx,NA https://github.com/rust-lang/rust/pull/72770,MERGED,2020-05-30T05:20:38Z,2020-06-26T06:11:52Z,Implement mixed script confusable lint.,crlf0710,23c9ac6b730f4e71b47f8714420f2609537b7114,17,Rollup merge of #72770 - crlf0710:mixed_script_confusable r=Manishearth Implement mixed script confusable lint. This implements the mixed script confusable lint defined in RFC 2457. This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13 and will need a Cargo.toml version bump after those are resolved. The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen this is to be added in `unicode-security` crate. r? @Manishearth,HEART,2020-06-02T20:49:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72775,MERGED,2020-05-30T09:50:57Z,2020-06-02T07:54:59Z,Return early to avoid ICE,JohnTitor,8a68fc6ff4f55a7a775a4339de4ca845a68ab43a,5,Rollup merge of #72775 - JohnTitor:await-sugg r=estebank Return early to avoid ICE Fixes #72766,HEART,2020-05-30T10:02:06Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/72775,MERGED,2020-05-30T09:50:57Z,2020-06-02T07:54:59Z,Return early to avoid ICE,JohnTitor,8a68fc6ff4f55a7a775a4339de4ca845a68ab43a,5,Rollup merge of #72775 - JohnTitor:await-sugg r=estebank Return early to avoid ICE Fixes #72766,HEART,2020-05-30T14:22:57Z,doctorn,me@nathancorbyn.com https://github.com/rust-lang/rust/pull/72775,MERGED,2020-05-30T09:50:57Z,2020-06-02T07:54:59Z,Return early to avoid ICE,JohnTitor,8a68fc6ff4f55a7a775a4339de4ca845a68ab43a,5,Rollup merge of #72775 - JohnTitor:await-sugg r=estebank Return early to avoid ICE Fixes #72766,HEART,2020-05-31T00:10:13Z,estebank,NA https://github.com/rust-lang/rust/pull/72784,MERGED,2020-05-30T15:09:34Z,2020-08-27T09:26:18Z,Await on mismatched future types,csmoe,f7cbb7a594658099ebb9d0008779511fe2fbe9ab,8,Auto merge of #72784 - csmoe:issue-61076 r=estebank Await on mismatched future types Closes #61076 This PR suggests to `await` on: 1. `async_fn().bar() => async_fn().await.bar()` 2. `async_fn().field => async_fn().await.field` 3. ` if let x = async() {} => if let x = async().await {}` r? @tmandry @estebank,HEART,2020-08-27T01:38:39Z,tmandry,NA https://github.com/rust-lang/rust/pull/72785,MERGED,2020-05-30T16:07:30Z,2020-06-19T16:02:08Z,linker: MSVC supports linking static libraries as a whole archive,petrochenkov,7cc45183cac5a4cfea21ecf94aa397781b969ea4,1,Rollup merge of #72785 - petrochenkov:wholemsvc r=matthewjasper linker: MSVC supports linking static libraries as a whole archive,THUMBS_UP,2020-06-25T05:34:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T17:10:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T17:36:44Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T17:45:55Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T18:20:00Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T19:54:32Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-30T22:31:04Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-05-31T14:29:51Z,tesuji,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-01T07:18:43Z,Elinvynia,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-04T11:38:11Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-10T10:21:27Z,mati865,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-21T04:32:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-24T00:28:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-25T05:03:48Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-06-25T05:54:36Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-07-01T02:47:10Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-07-02T14:16:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-07-19T16:10:17Z,estebank,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-10-15T16:48:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-12-02T11:45:55Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-12-02T12:03:57Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-12-02T13:33:52Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-12-02T15:39:31Z,jblondin,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2020-12-03T00:04:18Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2021-08-04T10:07:57Z,fwcd,NA https://github.com/rust-lang/rust/pull/72788,MERGED,2020-05-30T17:01:44Z,2020-06-21T02:20:44Z,Projection bound validation,matthewjasper,1a171d0d5b4b76170da94858869e42ebb6e2ced2,86,Rollup merge of #72788 - matthewjasper:projection-bound-validation r=nikomatsakis Projection bound validation During selection we use bounds declared on associated types (e.g. `type X: Copy`) to satisfy trait/projection bounds. This would be fine so long as those bounds are checked on any impls/trait objects. For simple cases they are because the bound `Self::X: Copy` gets normalized when we check the impl. However for default values with specialization and higher-ranked bounds from GATs or otherwise we can't normalize when checking the impl and so we use the bound from the trait to prove that the bound applies to the impl which is clearly unsound. This PR makes 2 fixes for this: 1. Requiring that the bounds on the trait apply to a projection type with the corresponding substs so a bound `for<'a> >::U: Copy` on the trait cannot be used to prove `>::U: Copy`. 2. Actually checking that the bounds that we still allow apply to generic/default associated types. Opening for a crater run. Closes #68641 Closes #68642 Closes #68643 Closes #68644 Closes #68645 Closes #68656 r? @ghost,HOORAY,2021-08-06T14:00:41Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72789,MERGED,2020-05-30T18:13:30Z,2020-06-11T01:27:05Z,resolve: Do not suggest imports from the same module in which we are resolving,petrochenkov,78d08a2269e359aa54f997a0fefe1eb828899a5c,5,Rollup merge of #72789 - petrochenkov:impcand r=davidtwco resolve: Do not suggest imports from the same module in which we are resolving Based on the idea from https://github.com/rust-lang/rust/pull/72623.,HEART,2020-06-11T01:42:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,THUMBS_UP,2020-06-20T20:56:07Z,Lokathor,NA https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,HEART,2020-06-25T06:54:41Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,THUMBS_UP,2020-06-26T18:37:32Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,HEART,2020-06-26T18:37:34Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,THUMBS_UP,2020-07-13T17:27:02Z,mibac138,NA https://github.com/rust-lang/rust/pull/72790,MERGED,2020-05-30T18:59:02Z,2020-06-21T02:20:43Z,core/time: Add Duration methods for zero,jonhoo,c47550f9e405d5817e69eb8d42995c63b60bbd8b,1,Rollup merge of #72790 - jonhoo:duration-is-zero r=LukasKalbertodt core/time: Add Duration methods for zero This patch adds two methods to `Duration`. The first `Duration::zero` provides a `const` constructor for getting an zero-length duration. This is also what `Default` provides (this was clarified in the docs) though `default` is not `const`. The second `Duration::is_zero` returns true if a `Duration` spans no time (i.e. because its components are all zero). Previously the way to do this was either to compare both `as_secs` and `subsec_nanos` to 0 to compare against `Duration::new(0 0)` or to use the `u128` method `as_nanos` none of which were particularly elegant.,THUMBS_UP,2020-11-16T22:46:44Z,tjkirch,NA https://github.com/rust-lang/rust/pull/72791,MERGED,2020-05-30T19:01:20Z,2020-06-20T06:52:46Z,update coerce docs and unify relevant tests,lcnr,c0a25bec9680471a4f1f26d06d5efa11547b6afc,22,Rollup merge of #72791 - lcnr:coerce-refactor r=estebank update coerce docs and unify relevant tests Merges `test/ui/coerce` with `test/ui/coercion`. Updates the documentation of `librustc_typeck/check/coercion.rs`. Adds 2 new coercion tests.,THUMBS_UP,2020-06-02T17:38:39Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/72796,MERGED,2020-05-30T21:47:54Z,2020-06-28T12:19:57Z,MIR sanity check: validate types on assignment,RalfJung,385d85c858863e9dee88c4d65d4016599c4323d7,4,Rollup merge of #72796 - RalfJung:mir-assign-sanity r=matthewjasper MIR sanity check: validate types on assignment This expands the MIR validation added by @jonas-schievink in https://github.com/rust-lang/rust/pull/72093 to also check that on an assignment the types of both sides match. Cc @eddyb @oli-obk,THUMBS_UP,2020-06-22T06:59:33Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/72799,MERGED,2020-05-30T22:47:23Z,2020-06-08T20:10:45Z,Add `-Z span-debug` to allow for easier debugging of proc macros,Aaron1011,e13508786808800b4bc13d49bd5fd1245bc41171,7,Rollup merge of #72799 - Aaron1011:feature/span-debug r=petrochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.,HOORAY,2020-05-31T04:16:43Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/72799,MERGED,2020-05-30T22:47:23Z,2020-06-08T20:10:45Z,Add `-Z span-debug` to allow for easier debugging of proc macros,Aaron1011,e13508786808800b4bc13d49bd5fd1245bc41171,7,Rollup merge of #72799 - Aaron1011:feature/span-debug r=petrochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.,HOORAY,2020-06-11T01:38:10Z,estebank,NA https://github.com/rust-lang/rust/pull/72799,MERGED,2020-05-30T22:47:23Z,2020-06-08T20:10:45Z,Add `-Z span-debug` to allow for easier debugging of proc macros,Aaron1011,e13508786808800b4bc13d49bd5fd1245bc41171,7,Rollup merge of #72799 - Aaron1011:feature/span-debug r=petrochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.,HOORAY,2020-06-17T17:25:00Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72804,MERGED,2020-05-31T03:19:46Z,2020-06-19T05:03:59Z,Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position,estebank,40fd2bdcfec7a30a2cce0d4a2cc08d09e64cabeb,25,Rollup merge of #72804 - estebank:opaque-missing-lts-in-fn-2 r=nikomatsakis Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position * Suggest substituting `'static` lifetime in impl/dyn `Trait + 'static` instead of `Trait + 'static + '_` * When `'static` is explicit also suggest constraining argument with it * Reduce verbosity of suggestion message and mention lifetime in label * Tweak output for overlapping required/captured spans * Give these errors an error code Follow up to #72543. r? @nikomatsakis,HOORAY,2020-06-24T00:03:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72804,MERGED,2020-05-31T03:19:46Z,2020-06-19T05:03:59Z,Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position,estebank,40fd2bdcfec7a30a2cce0d4a2cc08d09e64cabeb,25,Rollup merge of #72804 - estebank:opaque-missing-lts-in-fn-2 r=nikomatsakis Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position * Suggest substituting `'static` lifetime in impl/dyn `Trait + 'static` instead of `Trait + 'static + '_` * When `'static` is explicit also suggest constraining argument with it * Reduce verbosity of suggestion message and mention lifetime in label * Tweak output for overlapping required/captured spans * Give these errors an error code Follow up to #72543. r? @nikomatsakis,HOORAY,2020-06-25T08:17:55Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72807,MERGED,2020-05-31T04:17:04Z,2020-06-01T00:29:49Z,Avoid setting wrong obligation cause span of associated type mismatch,xiaotianrandom,8e83a7e1262e8ff00496e23645e7fec3874b055c,3,Rollup merge of #72807 - xiaotianrandom:fix-assoc-type-diagnostics r=estebank Avoid setting wrong obligation cause span of associated type mismatch Removes code that sets wrong obligation cause span of associated type mismatch. See the linked issue for details. Closes #72806.,HEART,2020-05-31T17:32:58Z,estebank,NA https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",THUMBS_UP,2020-06-02T20:47:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",THUMBS_UP,2020-06-09T16:32:58Z,johnp,johannespfrang@gmail.com https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",THUMBS_UP,2020-07-12T08:47:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",HEART,2020-07-12T20:50:12Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",HEART,2020-07-13T21:16:16Z,kbknapp,NA https://github.com/rust-lang/rust/pull/72808,MERGED,2020-05-31T07:29:55Z,2020-08-29T01:49:59Z,Substantial refactor to the design of LineWriter,Lucretiel,7b1dd61bda6a97bbf3dbeb9a1c1227a6a3934ee1,1,"Auto merge of #72808 - Lucretiel:line-writer-reimpl r=Amanieu Substantial refactor to the design of LineWriter # Preamble This is the first in a series of pull requests designed to move forward with https://github.com/rust-lang/rust/issues/60673 (and the related [5 year old FIXME](https://github.com/rust-lang/rust/blob/ea7181b5f7a888c2cf969ae86de7207fa5fb40aa/src/libstd/io/stdio.rs#L459-L461)) which calls for an update to `Stdout` such that it can be block-buffered rather than line-buffered under certain circumstances (such as a `tty` or a user setting the mode with a function call). This pull request refactors the logic `LineWriter` into a `LineWriterShim` which operates on a `BufWriter` by mutable reference such that it is easy to invoke the line-writing logic on an existing `BufWriter` without having to construct a new `LineWriter`. Additionally fixes #72721 ## A note on flushing Because the word **flush** tends to be pretty overloaded in this discussion I'm going to use the word **unbuffered** to refer to a `BufWriter` sending its data to the wrapped writer via `write` without calling `flush` on it and I'll be using **flushed** when referring to sending data via flush which recursively writes the data all the way to the final sink. For example given a `T = BufWriter>` saying that `T` **unbuffers** its data means that it is sent to the inner `BufWriter` but not necessarily to the `File` whereas saying that `T` **flushes** its data means that causes it (via `Write::flush`) to be delivered all the way to `File`. # Goals Once it became clear (for reasons described below) that the best way to approach this would involve refactoring `LineWriter` to work more directly on `BufWriter`'s internals I established the following design goals for the refactor: - Do not duplicate logic with `BufWriter`. It's great at buffering and then unbuffering data so use the existing logic as much as possible. - Minimize superfluous copying of data into `BufWriter`'s buffer. - Eliminate calls to `BufWriter::flush` and instead do the same thing as `BufWriter::write` which is to only write to the wrapped writer (rather than flushing all the way down to the final data sink). - Uphold the ""at-most 1 write of new data"" convention of `Write::write` - Minimize or eliminate dropping errors (that is eliminate the parts of the old design that threw away errors because `write` *must* report if any bytes were written) - As much as possible attempt to fully flush completed lines and *not* flush partial lines. One of the advantages of this design is that so long as we don't encounter lines larger than the `BufWriter`'s capacity partial lines will never be unbuffered while completed lines will *always* be unbuffered (with subsequent calls to `LineWriter::write` retrying failed writes before processing new data. # Design There are two major & related parts of the design. First a new internal stuct `LineWriterShim` is added. This struct implements all of the actual logic of line-writing in a `Write` implementation but it only operates on an `&mut BufWriter`. This means that this shim can be constructed on-the-fly to apply line writing logic to an existing `BufWriter`. This is in fact how `LineWriter` has been updated to operate and it is also how `Stdout` is being updated in my [development branch](https://github.com/Lucretiel/rust/tree/stdout-block-buffer) to switch which mode it wants to use at runtime. [An example of how this looks in practice](https://github.com/Lucretiel/rust/blob/f24f272df674dc7fa8941b97b45f41ad08b2199b/src/libstd/io/stdio.rs#L479-L484 ) The second major part of the design that the line-buffering logic implemented in `LineWriterShim` has been updated to work slightly more directly on the internals of `BufWriter`. Mostly it makes us of the public interface—particularly `buffer()` and `get_mut()`—but it also controls the flushing of the buffer with `flush_buf` rather than `flush` and it writes to the buffer infallibly with a new `write_to_buffer` method. This has several advantages: - Data no longer has to round trip through the `BufWriter`'s buffer. If the user provides a complete line that line is written directly to the inner writer (after ensuring the existing buffer is flushed). - The conventional contract of `write`—that at-most 1 attempt to write new data is made—is much more cleanly upheld because we don't have to perform fallible flushes and perform semi-complicated logic of trying to pretend errors at different stages didn't happen. Instead after attempting to write lines directly to the buffer we can infallibly add trailing data to the buffer without allowing any attempts to continue writing it to the `inner` writer. - Perhaps most importantly `LineWriter` *no longer performs a full flush on every line.* This makes its behavior much more consistent with `BufWriter` which unbuffers data to its inner writer without trying to flush it all the way to the final device. Previously `LineWriter` had no choice but to use `flush` to ensure that the lines were unbuffered but by writing directly to `inner` via `get_mut()` (when appropriate) we can use a more correct behavior. ## New(ish) line buffering logic The logic for line writing has been cleaned up as described above. It now follows this algorithm for `write` with minor adjustments for `write_all` and `write_vectored`: - Does our input data contain a newline? - If no: - simply use the regular `BufWriter::write` to write it; this will append it to the buffer and/or flush it as necessary based on how full the buffer is and how much input data there is. - additionally if the current buffer ends with `'\n'` attempt to immediately flush it with `flush_buf` before calling `BufWriter::write` This reproduces the old `needs_flush` behavior and ensures completed lines are flushed as soon as possible. The reason we only check if the buffer *ends* with `'\n'` is discussed later. - If yes: - First `flush_buf` - Then use `bufwriter.get_mut().write()` to write the input data directly to the underlying writer up to the last newline. Make at most one attempt at this. - If it errors return the error - If it succeeds with a full write add the remaining data (between the last newline and the end of the input) to the buffer. In order to uphold the ""at-most 1 attempt to write new data"" convention no attempts are made to write this data to the inner writer (though obviously a subsequent write may immediately flush it e.g. if it totally filled the buffer's capacity. - If it only partially succeeds buffer the data only up to the last newline. We do this to try to avoid writing partial lines to the inner writer where possible (that is whenever the lines are shorter than the total buffer capacity). While it was not my intention for this behavior to diverge from this existing `LineWriter` algorithm this updated design emerged very naturally once `LineWriter` wasn't burdened with having to only operate via `BufWriter::flush`. There essentially two main changes to observable behavior: - `flush` is no longer used to unbuffer lines. The are only written to the writer wrapped by `LineWriter`; this inner writer might do its own buffering. This change makes `LineWriter` consistent with the behavior of `BufWriter`. This is probably the most obvious user-visible change; it's the one I most expect to provoke issue reports if any are provoked. - Unless a line exceeds the capacity of the buffer partial lines are not unbuffered (without the user manually calling flush). This is a less surprising behavior and is enabled because `LineWriter` now has more precise control of what data is buffered and when it is unbuffered. I'd be surprised if anyone is relying on `LineWriter` unbuffering or flushing *partial* lines that are shorter than the capacity so I'm not worried about this one. None of these changes are inconsistent with any published documentation of `LineWriter`. Nonetheless like all changes with user-facing behavior changes this design will obviously have to be very carefully scrutinized. # Alternative designs and design rationalle The initial goal of this project was to provide a way for the `LineWriter` logic to be operable directly on a `BufWriter` so that the updated `Stdout` doesn't need to do something convoluted like `enum { BufWriter LineWriter }` (which ends up being ~~impossible~~ difficult to transition between states after being constructed). The design went through several iterations before arriving at the current draft. The major first version simply involved adding methods like `write_line_buffered` to `BufWriter`; these would contain the actual logic of line-buffered writing and would additionally have the advantages (described above) of operating directly on the internals of `BufWriter`. The idea was that `LineWriter` would simply call these methods and the updated `Stdout` would use either `BufWriter::write` or `BufWriter::write_line_buffered` depending on what mode it was in. The major issue with this design is that it loses the ability to take advantage of the `io::Write` trait which provides several useful default implementations of the various io methods such as `write_fmt` and `write_all` just using the core methods. For this reason the `write_line_buffered` design was retained but moved into a separate struct called `LineWriterShim` which operates on an `&mut LineWriter`. As part of this move the logic was lightly retooled to not touch the innards of `BufWriter` directly but instead to make use of the unexported helper methods like `flush_buf`. The other design evolutions were mostly related to answering questions like ""how much data should be buffered"" ""how should partial line writes be handled"" etc. As much as possible I tried to answer these by emulating the current `LineWriter` logic (which for example retries partial line writes on subsequent calls to `write`) while still meeting the refactor design goals. # Next steps ~Currently this design fails a few `LineWriter` tests mostly because they expect `LineWriter` to *fully* flush its content. There are also some changes to the way that `LineWriter` buffers data *after* writing completed lines aimed at ensuring that partial lines are not unbuffered prematurely. I want to make sure I fully understand the intent behind these tests before I either update the test or update this design so that they pass.~ However in the meantime I wanted to get this published so that feedback could start to accumulate on it. There's a lot of errata around how I arrived at this design that didn't really fit in this overlong document so please ask questions about anything that confusing or unclear and hopefully I can explain more of the rationale that led to it. # Test updates This design required some tests to be updated; I've research the intent behind these tests (mostly via `git blame`) and updated them appropriately. Those changes are cataloged here. - `test_line_buffer_fail_flush`: This test was added as a regression test for #32085 and is intended to assure that an errors from `flush` aren't propagated when preceded by a successful `write`. Because type of issue is no longer possible because `write` calls `buffer.get_mut().write()` instead of `buffer.write(); buffer.flush();` I'm simply removing this test entirely. Other similar error invariants related to errors during write-retrying are handled in other test cases. - `erroneous_flush_retried`: This test was added as a regression test for #37807 and was intended to ensure that flush-retrying (via `needs_flush`) and error-ignoring were being handled correctly (ironically this issue was caused by the flush-error-ignoring above). Half of that issue is not possible by design with this refactor because we no longer make fallible i/o calls that might produce errors we have to ignore after unbuffering lines. The `should_flush` behavior is captured by checking for a trailing newline in the `LineWriter` buffer; this test now checks that behavior. - `line_vectored`: changes here were pretty minor mostly related to when partial lines are or aren't written. The old implementation of `write_vectored` used very complicated logic to precisely determine the location of the last newline and precisely write up to that point; this required doing several consecutive fallible writes with all the complex error handling or ignoring issues that come with it. The updated design does at-most one write of a subset of total buffers (that is it doesn't split in the middle of a buffer) even if that means writing partial lines. One of the major advantages of the new design is that the underlying vectored write operation on the device can be taken advantage of even with small writes so long as they include a newline; previously these were unconditionally buffered then written. - `line_vectored_partial_and_errors`: Pretty similiar to `line_vectored` above; this test is for basic error recovery in `write_vectored` for vectored writes. As previously discussed the mocked behavior being tested for (errors ignored under certain circumstances) no occurs so I've simplified the test while doing my best to retain its spirit.",HEART,2020-08-28T09:07:47Z,tmiasko,NA https://github.com/rust-lang/rust/pull/72814,MERGED,2020-05-31T10:16:18Z,2020-06-19T05:03:57Z,remove visit_terminator_kind from MIR visitor,RalfJung,e0b59b2c07adec376b7c57fb3d81726b6bc2822d,27,Rollup merge of #72814 - RalfJung:mir-visir-terminator r=oli-obk remove visit_terminator_kind from MIR visitor For some reason we had both `visit_terminator` and `visit_terminator_kind`. In contrast for `Statement` we just have `visit_statement`. So this cleans things up by removing `visit_terminator_kind` and porting its users to `visit_terminator`.,THUMBS_UP,2020-06-01T04:02:40Z,panaman67,NA https://github.com/rust-lang/rust/pull/72820,MERGED,2020-05-31T14:22:53Z,2020-06-03T04:42:01Z,InstCombine: Don't optimize `&mut *x` into `x`,jonas-schievink,9c3ac0c9bb09d9ddaa15ba618597b6ccb9b66417,4,Rollup merge of #72820 - jonas-schievink:instcombine-uninit r=oli-obk InstCombine: Don't optimize `&mut *x` into `x` Fixes https://github.com/rust-lang/rust/issues/72797,HOORAY,2020-06-03T05:09:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/72823,MERGED,2020-05-31T15:46:00Z,2020-06-01T09:00:04Z,Add descriptions for all queries,matthewjasper,cf4683665f6808bb51c8d760efc953048b090137,19,Rollup merge of #72823 - matthewjasper:describe-queries r=eddyb Add descriptions for all queries This also removes the default description for queries with DefId keys and makes the macro validate that a description is provided. cc #72730 r? @eddyb,THUMBS_UP,2020-05-31T16:13:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72825,MERGED,2020-05-31T17:12:40Z,2020-06-02T07:54:51Z,Clarify errors and warnings about the transition to the new asm!,Amanieu,0007924cd096a26c67bd48bf167adfc59ddf45c0,9,Rollup merge of #72825 - Amanieu:asm-warning r=davidtwco Clarify errors and warnings about the transition to the new asm! Hopefully addresses the concerns from https://github.com/rust-lang/rust/pull/71007#issuecomment-636412905.,THUMBS_UP,2020-06-01T01:20:44Z,samuela,skainsworth@gmail.com https://github.com/rust-lang/rust/pull/72825,MERGED,2020-05-31T17:12:40Z,2020-06-02T07:54:51Z,Clarify errors and warnings about the transition to the new asm!,Amanieu,0007924cd096a26c67bd48bf167adfc59ddf45c0,9,Rollup merge of #72825 - Amanieu:asm-warning r=davidtwco Clarify errors and warnings about the transition to the new asm! Hopefully addresses the concerns from https://github.com/rust-lang/rust/pull/71007#issuecomment-636412905.,THUMBS_UP,2020-06-01T03:11:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72825,MERGED,2020-05-31T17:12:40Z,2020-06-02T07:54:51Z,Clarify errors and warnings about the transition to the new asm!,Amanieu,0007924cd096a26c67bd48bf167adfc59ddf45c0,9,Rollup merge of #72825 - Amanieu:asm-warning r=davidtwco Clarify errors and warnings about the transition to the new asm! Hopefully addresses the concerns from https://github.com/rust-lang/rust/pull/71007#issuecomment-636412905.,HEART,2020-06-01T21:31:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72834,MERGED,2020-05-31T20:05:04Z,2020-06-01T09:00:00Z,Rephrase term 'non-pointer type',JOE1994,16b4dc0489fca20d328c8f6effb8d7a9d1ef944d,1,Rollup merge of #72834 - JOE1994:correct_confusing_term r=sfackler Rephrase term 'non-pointer type' Hello :cat2: If the reader assumes that 'pointer type's include 'smart pointer's the term 'non-pointer type' could mislead the reader to assume that x should not be a smart pointer type. I tried to rephrase the term 'non-pointer type' to remove ambiguity in the doc comments. closes #72335 Thank you for reviewing this PR! :superhero_woman:,THUMBS_UP,2020-06-01T00:50:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/72846,CLOSED,2020-06-01T03:11:00Z,2020-06-08T05:25:24Z,impl TryFrom from native to NonZero,heca-project,NA,NA,NA,HEART,2020-06-06T14:19:45Z,oli-obk,NA https://github.com/rust-lang/rust/pull/72848,MERGED,2020-06-01T03:51:14Z,2020-06-03T04:41:58Z,Correct generic parameter ordering in error note for E0747,camelid,69a1ac3891a36f921bb73095850e6a4a66d9d9de,2,Rollup merge of #72848 - camelid:fix-72815 r=varkor Correct generic parameter ordering in error note for E0747 Fixes #72815. r? @varkor,THUMBS_UP,2020-06-01T04:28:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72876,MERGED,2020-06-01T06:19:08Z,2020-06-24T01:24:44Z,Mention that BTreeMap::new() doesn't allocate,TrolledWoods,317a15142e842656f913d7debd2bc18a367948e4,1,Rollup merge of #72876 - TrolledWoods:patch-2 r=Dylan-DPC Mention that BTreeMap::new() doesn't allocate I think it would be nice to mention this so you don't have to dig through the src to look at the definition of new().,THUMBS_UP,2020-06-02T20:41:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-01T16:25:46Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-01T22:54:11Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-02T10:26:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-02T17:33:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-03T14:09:04Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-03T19:31:35Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-03T23:12:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-25T23:16:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/72882,MERGED,2020-06-01T11:51:18Z,2020-06-04T18:01:08Z,save_analysis: work on HIR tree instead of AST,marmeladema,3d5d0f898c2f3998e50c2180c6202f193c3acdbc,6,Auto merge of #72882 - marmeladema:save-analysis-hir-tree r=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc #50928,HOORAY,2020-06-26T00:51:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72883,MERGED,2020-06-01T12:29:00Z,2020-06-01T19:03:19Z,[stable] 1.44 release,Mark-Simulacrum,49cae55760da0a43428eba73abcb659bb70cf2e4,16,Auto merge of #72883 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] 1.44 release This includes a release notes update as usual and a backport of #72767. r? @ghost,ROCKET,2020-06-01T19:07:10Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/72902,MERGED,2020-06-02T00:56:35Z,2020-06-03T04:41:55Z,Add a test to ensure Fuse stays covariant,cuviper,0050b8817b56484a82a0f78bf4d5e9b7011b75af,1,Rollup merge of #72902 - cuviper:fuse-covariant r=nikomatsakis Add a test to ensure Fuse stays covariant When #70502 attempted to specialize the data types in `Fuse` one of the problems we found was that it broke variance. This was also realized when `Fuse` was first added https://github.com/rust-lang/rust/pull/35656#discussion-diff-74995079 but now this PR adds a test so we don't forget again.,THUMBS_UP,2020-06-04T23:15:13Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/72904,MERGED,2020-06-02T02:21:10Z,2020-06-08T01:26:03Z,Order the Rust and C ABIs first to reduce test churn,shepmaster,6aa1d93c21cffd64f8ede374b49c94e8432506a0,7,Auto merge of #72904 - shepmaster:reduce-abi-symbol-hash-churn r=jonas-schievink RalfJung Order the Rust and C ABIs first to reduce test churn,HEART,2020-06-02T06:22:01Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/72904,MERGED,2020-06-02T02:21:10Z,2020-06-08T01:26:03Z,Order the Rust and C ABIs first to reduce test churn,shepmaster,6aa1d93c21cffd64f8ede374b49c94e8432506a0,7,Auto merge of #72904 - shepmaster:reduce-abi-symbol-hash-churn r=jonas-schievink RalfJung Order the Rust and C ABIs first to reduce test churn,HEART,2020-06-02T12:52:49Z,RalfJung,NA https://github.com/rust-lang/rust/pull/72906,MERGED,2020-06-02T06:11:32Z,2020-06-12T17:01:27Z,Migrate to numeric associated consts,tesuji,c06799e4c4103330c972eb04f08aa72b7c1d5ace,101,Rollup merge of #72906 - lzutao:migrate-numeric-assoc-consts r=dtolnay Migrate to numeric associated consts The deprecation PR is #72885 cc #68490 cc rust-lang/rfcs#2700,HOORAY,2020-06-02T13:24:05Z,faern,NA https://github.com/rust-lang/rust/pull/72923,MERGED,2020-06-02T18:18:46Z,2020-06-04T14:16:22Z,Improve E0433 so that it suggests missing imports,Patryk27,085c16d5529727d3f4068457fd583d9fb17a186d,9,Rollup merge of #72923 - Patryk27:fix/52468 r=estebank Improve E0433 so that it suggests missing imports Closes #52468,THUMBS_UP,2020-06-02T19:30:48Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/72923,MERGED,2020-06-02T18:18:46Z,2020-06-04T14:16:22Z,Improve E0433 so that it suggests missing imports,Patryk27,085c16d5529727d3f4068457fd583d9fb17a186d,9,Rollup merge of #72923 - Patryk27:fix/52468 r=estebank Improve E0433 so that it suggests missing imports Closes #52468,THUMBS_UP,2020-06-02T23:43:39Z,estebank,NA https://github.com/rust-lang/rust/pull/72927,MERGED,2020-06-02T20:36:45Z,2020-06-06T12:26:09Z,Rename all remaining compiler crates to use the `rustc_foo` pattern,petrochenkov,118b50524b79e565f017e08bce9b90a16c63634f,91,Auto merge of #72927 - petrochenkov:rustc r=Mark-Simulacrum Rename all remaining compiler crates to use the `rustc_foo` pattern libarena -> librustc_arena libfmt_macros -> librustc_parse_format libgraphviz -> librustc_graphviz libserialize -> librustc_serialize Closes https://github.com/rust-lang/rust/issues/71177 in particular.,ROCKET,2020-06-02T20:38:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72927,MERGED,2020-06-02T20:36:45Z,2020-06-06T12:26:09Z,Rename all remaining compiler crates to use the `rustc_foo` pattern,petrochenkov,118b50524b79e565f017e08bce9b90a16c63634f,91,Auto merge of #72927 - petrochenkov:rustc r=Mark-Simulacrum Rename all remaining compiler crates to use the `rustc_foo` pattern libarena -> librustc_arena libfmt_macros -> librustc_parse_format libgraphviz -> librustc_graphviz libserialize -> librustc_serialize Closes https://github.com/rust-lang/rust/issues/71177 in particular.,ROCKET,2020-06-02T20:40:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72927,MERGED,2020-06-02T20:36:45Z,2020-06-06T12:26:09Z,Rename all remaining compiler crates to use the `rustc_foo` pattern,petrochenkov,118b50524b79e565f017e08bce9b90a16c63634f,91,Auto merge of #72927 - petrochenkov:rustc r=Mark-Simulacrum Rename all remaining compiler crates to use the `rustc_foo` pattern libarena -> librustc_arena libfmt_macros -> librustc_parse_format libgraphviz -> librustc_graphviz libserialize -> librustc_serialize Closes https://github.com/rust-lang/rust/issues/71177 in particular.,ROCKET,2020-06-02T20:41:36Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/72927,MERGED,2020-06-02T20:36:45Z,2020-06-06T12:26:09Z,Rename all remaining compiler crates to use the `rustc_foo` pattern,petrochenkov,118b50524b79e565f017e08bce9b90a16c63634f,91,Auto merge of #72927 - petrochenkov:rustc r=Mark-Simulacrum Rename all remaining compiler crates to use the `rustc_foo` pattern libarena -> librustc_arena libfmt_macros -> librustc_parse_format libgraphviz -> librustc_graphviz libserialize -> librustc_serialize Closes https://github.com/rust-lang/rust/issues/71177 in particular.,ROCKET,2020-06-03T18:52:16Z,estebank,NA https://github.com/rust-lang/rust/pull/72932,MERGED,2020-06-02T21:33:44Z,2020-06-13T19:39:05Z,Clarify the behaviour of Pattern when used with methods like str::contains,poliorcetics,2cc267245dc1df5920190e7b3555a13bfacb11c5,1,Rollup merge of #72932 - poliorcetics:pattern-contains-behaviour r=hanna-kruppe Clarify the behaviour of Pattern when used with methods like str::contains Fixes #45507. I used the previous work by @Emerentius (thanks !) added a paragraph and checked the links (they work for me but I'm not against someone else checking them too).,HEART,2020-06-03T00:02:14Z,Emerentius,NA https://github.com/rust-lang/rust/pull/72936,MERGED,2020-06-03T02:02:48Z,2020-06-21T21:06:29Z,Upgrade Chalk,jackh726,a8cf3991177f30694200002cd9479ffbbe6d9a1a,24,Auto merge of #72936 - jackh726:chalk-more r=nikomatsakis 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,HEART,2020-06-03T07:30:55Z,marmeladema,NA https://github.com/rust-lang/rust/pull/72936,MERGED,2020-06-03T02:02:48Z,2020-06-21T21:06:29Z,Upgrade Chalk,jackh726,a8cf3991177f30694200002cd9479ffbbe6d9a1a,24,Auto merge of #72936 - jackh726:chalk-more r=nikomatsakis 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,HEART,2020-06-07T21:40:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72936,MERGED,2020-06-03T02:02:48Z,2020-06-21T21:06:29Z,Upgrade Chalk,jackh726,a8cf3991177f30694200002cd9479ffbbe6d9a1a,24,Auto merge of #72936 - jackh726:chalk-more r=nikomatsakis 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,HEART,2020-06-20T11:12:43Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/72936,MERGED,2020-06-03T02:02:48Z,2020-06-21T21:06:29Z,Upgrade Chalk,jackh726,a8cf3991177f30694200002cd9479ffbbe6d9a1a,24,Auto merge of #72936 - jackh726:chalk-more r=nikomatsakis 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,HEART,2020-06-22T01:34:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2020-06-05T03:21:29Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2020-06-05T09:09:29Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2020-06-09T23:05:27Z,jgrund,grundjoseph@gmail.com https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,HOORAY,2020-06-16T13:40:09Z,remi-dupre,remi@dupre.io https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2020-06-17T18:58:38Z,robjtede,NA https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,HOORAY,2020-06-24T02:40:15Z,hugwijst,NA https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,HOORAY,2020-06-24T12:35:57Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2020-06-25T05:56:30Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,HOORAY,2022-02-13T12:29:20Z,kraktus,NA https://github.com/rust-lang/rust/pull/72938,MERGED,2020-06-03T08:42:22Z,2020-06-15T15:22:14Z,Stabilize Option::zip,tesuji,89eb74dcac7d92d215e6fe821a2b8b187cb02292,4,Rollup merge of #72938 - lzutao:stabilize_option_zip r=dtolnay Stabilize Option::zip This PR stabilizes the following API: ```rust impl Option { pub fn zip(self other: Option) -> Option<(T U)>; } ``` This API has real world usage as seen in . The `zip_with` method is left unstably as this API is kinda niche and it hasn't received much usage in Rust repositories on GitHub. cc #70086,THUMBS_UP,2022-02-13T12:29:20Z,kraktus,NA https://github.com/rust-lang/rust/pull/72941,MERGED,2020-06-03T11:33:03Z,2020-06-11T14:52:58Z,Ensure stack when building MIR for matches,nagisa,adc92becf0b0116d289e03d8d06556aa70121cf4,2,Rollup merge of #72941 - nagisa:ensure-stack-for-match r=oli-obk Ensure stack when building MIR for matches In particular matching on complex types such as strings will cause deep recursion to happen. Fixes #72933 r? @matthewjasper @oli-obk,EYES,2020-06-03T16:33:44Z,mati865,NA https://github.com/rust-lang/rust/pull/72962,MERGED,2020-06-03T22:03:15Z,2020-06-16T09:42:27Z,store `ObligationCause` on the heap ,lcnr,c8a9c340de32cb70c8bad8af1a4474f805c5a969,10,Auto merge of #72962 - lcnr:ObligationCause-lrc r=ecstatic-morse store `ObligationCause` on the heap Stores `ObligationCause` on the heap using an `Rc`. This PR trades off some transient memory allocations to reduce the size of–and thus the number of instructions required to memcpy–a few widely used data structures in trait solving.,HEART,2020-06-25T14:55:28Z,estebank,NA https://github.com/rust-lang/rust/pull/72968,MERGED,2020-06-04T01:26:36Z,2020-06-19T05:03:52Z,Only highlight doc search results via mouseover if mouse has moved,carols10cents,bf59152c01d9ffc4ceeb982e26b3df2354ebede6,1,Rollup merge of #72968 - integer32llc:docs-arrow-keys r=GuillaumeGomez Only highlight doc search results via mouseover if mouse has moved ## What happens - Go to https://doc.rust-lang.org/stable/std/index.html - Put your mouse cursor somewhere in the middle where search results will appear and then don't move the mouse - Press 's' to focus the search box - Type a query that brings up enough search results to go under where your mouse cursor is - Press the down arrow - The search result that is one below where your mouse cursor is will be highlighted. ## What I expected When not currently using the mouse I expect doing a search and then pressing the down arrow to always highlight the first search result immediately below the search box. ## The fix This feels a bit hacky to me; I'm open to other solutions. This introduces a global JS var that keeps track of whether the person searching has moved their mouse after doing a search or not and only uses the mouse position to highlight search results if the person HAS moved the mouse AFTER doing a search.,HEART,2020-06-04T02:23:43Z,ehuss,NA https://github.com/rust-lang/rust/pull/72968,MERGED,2020-06-04T01:26:36Z,2020-06-19T05:03:52Z,Only highlight doc search results via mouseover if mouse has moved,carols10cents,bf59152c01d9ffc4ceeb982e26b3df2354ebede6,1,Rollup merge of #72968 - integer32llc:docs-arrow-keys r=GuillaumeGomez Only highlight doc search results via mouseover if mouse has moved ## What happens - Go to https://doc.rust-lang.org/stable/std/index.html - Put your mouse cursor somewhere in the middle where search results will appear and then don't move the mouse - Press 's' to focus the search box - Type a query that brings up enough search results to go under where your mouse cursor is - Press the down arrow - The search result that is one below where your mouse cursor is will be highlighted. ## What I expected When not currently using the mouse I expect doing a search and then pressing the down arrow to always highlight the first search result immediately below the search box. ## The fix This feels a bit hacky to me; I'm open to other solutions. This introduces a global JS var that keeps track of whether the person searching has moved their mouse after doing a search or not and only uses the mouse position to highlight search results if the person HAS moved the mouse AFTER doing a search.,HEART,2020-06-04T16:37:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72970,MERGED,2020-06-04T03:19:31Z,2020-06-07T17:55:37Z,Properly handle feature-gated lints,OddCoincidence,1ff0ba03ef71abf1f744d9acba6d9b3c82c9764b,4,Rollup merge of #72970 - OddCoincidence:feature-gated-lints r=petrochenkov Properly handle feature-gated lints Closes #72694,THUMBS_UP,2020-06-05T15:30:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72972,MERGED,2020-06-04T04:51:26Z,2020-06-10T00:49:00Z,Pull changes from rust-lang/rust-clippy,tesuji,283522400b5c13dfdf2b7e608e63a70ee8e3d7af,143,Auto merge of #72972 - lzutao:clippy r=Manishearth Pull changes from rust-lang/rust-clippy,THUMBS_UP,2020-06-04T09:17:19Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-05T16:06:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-06T00:05:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-11T16:29:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-26T23:45:27Z,sajattack,NA https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-30T18:35:57Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-30T19:37:01Z,imheresamir,samirshetty23@gmail.com https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-06-30T20:22:39Z,yerke,NA https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-07-15T13:40:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/72973,MERGED,2020-06-04T05:31:35Z,2020-07-16T06:26:15Z,RISC-V GNU/Linux as host platform,msizanoen1,af3d4cb936592ba53593ba869213c1af61b4166f,10,Rollup merge of #72973 - msizanoen1:riscv-host r=pietroalbini RISC-V GNU/Linux as host platform This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux. r? @alexcrichton,HOORAY,2020-12-06T11:17:32Z,huynhtrankhanh,qcdz9r6wpcbh59@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T12:08:30Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T12:28:51Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T13:11:20Z,mati865,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T13:16:15Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T13:53:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T14:53:19Z,iago-lito,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T16:37:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-04T17:12:53Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-05T00:32:32Z,weirane,gh@ruo-chen.wang https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-05T04:52:46Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-05T08:04:16Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-05T09:01:31Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-07T02:14:19Z,softprops,d.tangren@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-07T05:49:59Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-07T08:25:00Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-11T06:20:56Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-19T22:14:43Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-06-21T09:40:08Z,tommket,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-04T11:51:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-04T16:12:18Z,kjeremy,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-04T16:36:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-05T15:43:15Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-08T18:00:00Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-08T18:22:52Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-08T20:11:14Z,GrayJack,NA https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-08T21:00:07Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-09T08:39:19Z,imp,cyril.plisko@mountall.com https://github.com/rust-lang/rust/pull/72978,MERGED,2020-06-04T12:07:17Z,2020-07-04T09:08:35Z,ship rust analyzer,matklad,0cd7ff7ddfb75a38dca81ad3e76b1e984129e939,10,Auto merge of #72978 - matklad:ship-rust-analyzer r=Mark-Simulacrum ship rust analyzer This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-),HOORAY,2020-07-11T11:05:59Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T14:31:16Z,vultix,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T14:31:28Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T14:37:01Z,orium,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T14:54:28Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T14:55:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T15:11:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T15:26:55Z,abalmos,andrew@balmos.org https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T15:26:56Z,abalmos,andrew@balmos.org https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T15:36:44Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T15:41:58Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,CONFUSED,2020-06-04T15:51:45Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T15:58:37Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T15:58:37Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T16:13:41Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T16:13:41Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HEART,2020-06-04T16:14:37Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T16:28:43Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HEART,2020-06-04T17:21:14Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T17:21:16Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-04T17:21:17Z,idubrov,dubrov.ivan@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-04T18:57:52Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-05T05:49:25Z,zoni,nick@groenen.me https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-05T05:49:29Z,zoni,nick@groenen.me https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-05T14:00:45Z,killercup,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-07T12:04:17Z,jk-gan,junkai@hey.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-15T05:47:35Z,danclive,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-06-26T21:43:41Z,tbodt,tblodt@icloud.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-26T21:43:42Z,tbodt,tblodt@icloud.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-27T15:16:59Z,dennis-hamester,dennis.hamester@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-28T20:31:35Z,Caduser2020,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-29T14:13:13Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-06-30T15:08:23Z,ngugc,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-07-03T22:18:35Z,alexkreidler,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-07-20T03:12:59Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-07-30T01:21:29Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-08-01T09:30:13Z,theduke,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-08-04T22:00:24Z,jbr,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-08-05T23:53:46Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-08-14T16:33:18Z,ljedrz,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-09-08T17:04:43Z,chmln,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-09-26T12:50:19Z,fulmicoton,paul.masurel@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-10-24T12:11:07Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-10-24T12:11:08Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-11-05T07:46:52Z,innobead,innobead@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-11-12T16:38:04Z,trevyn,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-11-19T21:54:53Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-11-20T02:05:16Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-11-22T16:30:46Z,taiki-e,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-11-22T21:17:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2020-12-02T12:16:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2020-12-02T12:16:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2021-03-12T15:46:00Z,yerke,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2021-03-12T15:46:01Z,yerke,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2021-03-15T13:41:41Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2021-06-13T11:57:17Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,THUMBS_UP,2022-01-16T20:36:09Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HOORAY,2022-01-16T20:36:11Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72981,OPEN,2020-06-04T14:16:58Z,NA,Stabilize the backtrace feature.,withoutboats,NA,NA,NA,HEART,2022-01-16T20:36:12Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/72982,MERGED,2020-06-04T15:02:14Z,2020-06-05T22:50:47Z,resolve: Sort E0408 errors by Symbol str,tblah,826cb062a659f7b719a8a0ab1497a78229318aab,29,Auto merge of #72982 - tblah:riscv-ui-tests r=estebank resolve: Sort E0408 errors by Symbol str This is a request for comments implementing my suggested solution to https://github.com/rust-lang/rust/issues/72913 Previously errors were sorted by Symbol index instead of the string. The indexes are not the same between architectures because Symbols for architecture extensions (e.g. x86 AVX or RISC-V d) are interned before the source file is parsed. RISC-V's naming of extensions after single letters led to it having errors sorted differently for test cases using single letter variable names. Instead sort the errors by the Symbol string so that it is stable across architectures. While I was at it there's also 8edb05c2 skipping some ui tests which I think are irrelevant for risc-v.,THUMBS_UP,2020-07-01T15:04:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/72988,CLOSED,2020-06-04T18:18:13Z,2020-07-25T16:12:49Z,Expand libstd struct case misspelling diagnostics,chrissimpkins,NA,NA,NA,HOORAY,2020-06-13T17:41:45Z,estebank,NA https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2020-06-05T18:19:04Z,bluss,NA https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2020-06-11T02:16:48Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2020-06-12T07:33:05Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2020-06-12T12:53:07Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2021-10-06T20:43:09Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2021-10-07T04:59:45Z,wookietreiber,NA https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_DOWN,2022-02-17T21:05:57Z,Ten0,NA https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_DOWN,2022-02-17T21:06:01Z,Elrendio,NA https://github.com/rust-lang/rust/pull/73001,MERGED,2020-06-04T21:07:38Z,2020-06-08T20:10:30Z,Free `default()` forwarding to `Default::default()`,ilya-bobyr,244465dbb8b0e49d741bc1f93925d037020cb1f1,3,Rollup merge of #73001 - ilya-bobyr:master r=dtolnay Free `default()` forwarding to `Default::default()` It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance. Especially so compared to Haskell where the same functionality is called `def`. Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation. The trait is still there so if someone wants to be explicit and to say `Default::default()` - it still works but if imported as `std::default::default;` then the free function reduces typing and visual noise.,THUMBS_UP,2022-05-27T16:17:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/73005,MERGED,2020-06-04T23:39:04Z,2020-06-11T01:26:52Z,Don't create impl candidates when obligation contains errors,Aaron1011,024f025934a40056364be4a4da4f7e078b419f68,6,"Rollup merge of #73005 - Aaron1011:fix/error-overflow r=estebank Don't create impl candidates when obligation contains errors Fixes #72839 In PR #72621 trait selection was modified to no longer bail out early when an error type was encountered. This allowed us treat `ty::Error` as `Sized` causing us to avoid emitting a spurious ""not sized"" error after a type error had already occured. However this means that we may now try to match an impl candidate against the error type. Since the error type will unify with almost anything this can cause us to infinitely recurse (eventually triggering an overflow) when trying to verify certain `where` clauses. This commit causes us to skip generating any impl candidates when an error type is involved.",THUMBS_UP,2020-06-05T00:13:45Z,estebank,NA https://github.com/rust-lang/rust/pull/73005,MERGED,2020-06-04T23:39:04Z,2020-06-11T01:26:52Z,Don't create impl candidates when obligation contains errors,Aaron1011,024f025934a40056364be4a4da4f7e078b419f68,6,"Rollup merge of #73005 - Aaron1011:fix/error-overflow r=estebank Don't create impl candidates when obligation contains errors Fixes #72839 In PR #72621 trait selection was modified to no longer bail out early when an error type was encountered. This allowed us treat `ty::Error` as `Sized` causing us to avoid emitting a spurious ""not sized"" error after a type error had already occured. However this means that we may now try to match an impl candidate against the error type. Since the error type will unify with almost anything this can cause us to infinitely recurse (eventually triggering an overflow) when trying to verify certain `where` clauses. This commit causes us to skip generating any impl candidates when an error type is involved.",THUMBS_UP,2020-06-11T01:46:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/73007,MERGED,2020-06-05T00:02:34Z,2020-06-23T04:03:58Z,impl ToSocketAddrs for (String u16),yoshuawuyts,dcd470fe1be03136a8e1794b7e2cc6179bbd9d92,1,Auto merge of #73007 - yoshuawuyts:socketaddr-from-string-u16 r=sfackler 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!,EYES,2020-06-15T02:49:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T03:11:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T03:23:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T06:08:47Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T09:21:27Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T22:26:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-05T22:36:16Z,adetaylor,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-06T09:01:58Z,manuel-woelker,github@manuel.woelker.org https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-08T02:53:56Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-08T18:13:07Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-08T21:27:10Z,tmandry,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-11T04:36:44Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-15T21:49:18Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-22T22:28:41Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-23T11:37:50Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-23T14:02:22Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-06-28T12:52:26Z,jschwe,NA https://github.com/rust-lang/rust/pull/73011,MERGED,2020-06-05T02:31:55Z,2020-06-19T16:02:00Z,first stage of implementing LLVM code coverage,richkadel,1dc6c3c4ad2d08cc8d8d414cd04cbf0350e2bb14,25,Rollup merge of #73011 - richkadel:llvm-count-from-mir-pass r=tmandry first stage of implementing LLVM code coverage This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST). This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation. This initial version only injects counters at the top of each function and does not yet implement the required coverage map. Upcoming PRs will add the coverage map and add more counters and/or counter expressions for each conditional code branch. Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation ***[I put together some development notes here under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***,THUMBS_UP,2020-10-06T00:02:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73023,MERGED,2020-06-05T10:59:08Z,2020-06-11T01:26:50Z,Remove noisy suggestion of hash_map ,ayushmishra2005,e1cd8c41a559276a2a8ff62085ded220cccb88f3,8,Rollup merge of #73023 - ayushmishra2005:remove_noisy_suggestion r=davidtwco Remove noisy suggestion of hash_map Remove noisy suggestion of hash_map #72642 fixes #72642,THUMBS_UP,2020-06-05T11:07:32Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73023,MERGED,2020-06-05T10:59:08Z,2020-06-11T01:26:50Z,Remove noisy suggestion of hash_map ,ayushmishra2005,e1cd8c41a559276a2a8ff62085ded220cccb88f3,8,Rollup merge of #73023 - ayushmishra2005:remove_noisy_suggestion r=davidtwco Remove noisy suggestion of hash_map Remove noisy suggestion of hash_map #72642 fixes #72642,THUMBS_UP,2020-06-05T15:08:37Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/73032,MERGED,2020-06-05T14:43:56Z,2020-06-29T04:35:06Z,stabilize leading_trailing_ones,yoshuawuyts,c86039b33343de264d8b3b1a9e3591b10d5615e8,2,Auto merge of #73032 - yoshuawuyts:stabilize-leading_trailing_ones r=Amanieu stabilize leading_trailing_ones This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year and hasn't had any issues since. It seems unlikely we'll want to change this so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks! cc/ @djc @rust-lang/libs,THUMBS_UP,2020-06-05T15:02:31Z,djc,NA https://github.com/rust-lang/rust/pull/73032,MERGED,2020-06-05T14:43:56Z,2020-06-29T04:35:06Z,stabilize leading_trailing_ones,yoshuawuyts,c86039b33343de264d8b3b1a9e3591b10d5615e8,2,Auto merge of #73032 - yoshuawuyts:stabilize-leading_trailing_ones r=Amanieu stabilize leading_trailing_ones This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year and hasn't had any issues since. It seems unlikely we'll want to change this so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks! cc/ @djc @rust-lang/libs,HOORAY,2020-06-25T17:42:22Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-05T15:57:48Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-05T16:04:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-05T16:35:02Z,Dash83,NA https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-24T00:03:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-25T03:47:35Z,DianaNites,NA https://github.com/rust-lang/rust/pull/73034,MERGED,2020-06-05T15:53:06Z,2020-06-19T05:03:47Z,Export `#[inline]` fns with extern indicators,doctorn,0e332e9e3c4a33458cac1801f59c2d0a3ca28484,7,"Rollup merge of #73034 - doctorn:nomangle-inline-linkage r=matthewjasper Export `#[inline]` fns with extern indicators In ancient history (#36280) we stopped `#[inline]` fns being codegened if they weren't used. However - #72944 - #72463 observe that when writing something like ```rust #![crate_type = ""cdylib""] #[no_mangle] #[inline] pub extern ""C"" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves #72944 resolves #72463 (and maybe some more)",HOORAY,2020-06-25T05:49:45Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73036,MERGED,2020-06-05T17:17:10Z,2020-06-12T01:28:55Z,std: Enable atomic.fence emission on wasm32,alexcrichton,3b41e54799754fcdc7ae0429bd8fd64b5bd5a1fd,1,Rollup merge of #73036 - alexcrichton:update-wasm-fence r=Mark-Simulacrum std: Enable atomic.fence emission on wasm32 This commit removes the `#[cfg]` guards in `atomic::fence` on wasm targets. Since these guards were originally added the upstream wasm specification for threads gained an `atomic.fence` instruction so LLVM no longer panics on these intrinsics. Although there aren't a ton of tests in-repo for this right now I've tested locally and all of these fences generate `atomic.fence` instructions in wasm. Closes #65687 Closes #72997,THUMBS_UP,2020-06-07T08:55:56Z,est31,NA https://github.com/rust-lang/rust/pull/73036,MERGED,2020-06-05T17:17:10Z,2020-06-12T01:28:55Z,std: Enable atomic.fence emission on wasm32,alexcrichton,3b41e54799754fcdc7ae0429bd8fd64b5bd5a1fd,1,Rollup merge of #73036 - alexcrichton:update-wasm-fence r=Mark-Simulacrum std: Enable atomic.fence emission on wasm32 This commit removes the `#[cfg]` guards in `atomic::fence` on wasm targets. Since these guards were originally added the upstream wasm specification for threads gained an `atomic.fence` instruction so LLVM no longer panics on these intrinsics. Although there aren't a ton of tests in-repo for this right now I've tested locally and all of these fences generate `atomic.fence` instructions in wasm. Closes #65687 Closes #72997,THUMBS_UP,2020-06-12T01:56:29Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/73046,MERGED,2020-06-05T23:42:53Z,2020-06-08T07:45:43Z,save_analysis: fix some ICEs,marmeladema,73558160933b2764ed9a84b1b2b647e128eac3f8,5,Auto merge of #73046 - marmeladema:save-analysis-fix-path r=Xanewok save_analysis: fix some ICEs Fixes #73020 Fixes #73022 Fixes #73041,THUMBS_UP,2020-06-07T10:01:02Z,whizsid,whizsid@aol.com https://github.com/rust-lang/rust/pull/73046,MERGED,2020-06-05T23:42:53Z,2020-06-08T07:45:43Z,save_analysis: fix some ICEs,marmeladema,73558160933b2764ed9a84b1b2b647e128eac3f8,5,Auto merge of #73046 - marmeladema:save-analysis-fix-path r=Xanewok save_analysis: fix some ICEs Fixes #73020 Fixes #73022 Fixes #73041,THUMBS_UP,2020-06-08T18:33:35Z,danii,himself@danii.dev https://github.com/rust-lang/rust/pull/73055,MERGED,2020-06-06T10:09:04Z,2020-06-20T22:54:18Z,remove leftover mentions of `skol` and `int` from the compiler,lcnr,b015b28359c7c94ef756b48d9046282153af9288,18,Rollup merge of #73055 - lcnr:skol-no-more r=matthewjasper remove leftover mentions of `skol` and `int` from the compiler This PR mostly changes `skol` -> `placeholder` and all cases where `int` is used as a type to `i32`.,HEART,2020-06-20T14:39:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73056,CLOSED,2020-06-06T10:47:08Z,2020-06-11T06:23:12Z,Allow unused arguments in asm!,Amanieu,NA,NA,NA,HEART,2020-06-10T14:20:17Z,unageek,NA https://github.com/rust-lang/rust/pull/73066,MERGED,2020-06-06T17:34:54Z,2020-06-13T19:38:55Z,Querify whether a type has structural equality (Take 2),ecstatic-morse,6ad8cbdc7d3e8f3abf4dc002d441940e1e24efc3,6,Rollup merge of #73066 - ecstatic-morse:query-structural-eq2 r=pnkfelix Querify whether a type has structural equality (Take 2) Alternative to #72177. Unlike in #72177 this helper method works for all types falling back to a query for `TyKind::Adt`s that determines whether the `{Partial }StructuralEq` traits are implemented. This is my preferred interface for this method. I think this is better than just documenting that the helper only works for ADTs. If others disagree we can just merge #72177 with the fixes applied. This has already taken far too long.,HEART,2020-06-10T02:43:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73072,MERGED,2020-06-06T19:34:21Z,2020-06-07T09:52:15Z,Update LLVM submodule to include lld NOLOAD fix,arcnmx,a2fc33e0c87a258542cd12d6ffae52c43aa3785a,1,Auto merge of #73072 - arcnmx:lld-noload r=nikic Update LLVM submodule to include lld NOLOAD fix > Rust nightly 2020-05-22 and later ships lld with a regression related to linker scripts: NOLOAD sections incorrectly generate sections filled with 0s. This causes gdb and other elf loaders to write to reserved or otherwise invalid addresses (gdb also seems confused by the resulting ELF files and spits out a warning about the sections). This is particularly a problem for embedded rust projects that use lld by default and have affected linker scripts (cortex-m-rt based projects for instance). https://github.com/rust-lang/llvm-project/pull/64 Note that this also pulls in llvm changes from #72937,HOORAY,2020-06-06T19:35:57Z,bugadani,NA https://github.com/rust-lang/rust/pull/73072,MERGED,2020-06-06T19:34:21Z,2020-06-07T09:52:15Z,Update LLVM submodule to include lld NOLOAD fix,arcnmx,a2fc33e0c87a258542cd12d6ffae52c43aa3785a,1,Auto merge of #73072 - arcnmx:lld-noload r=nikic Update LLVM submodule to include lld NOLOAD fix > Rust nightly 2020-05-22 and later ships lld with a regression related to linker scripts: NOLOAD sections incorrectly generate sections filled with 0s. This causes gdb and other elf loaders to write to reserved or otherwise invalid addresses (gdb also seems confused by the resulting ELF files and spits out a warning about the sections). This is particularly a problem for embedded rust projects that use lld by default and have affected linker scripts (cortex-m-rt based projects for instance). https://github.com/rust-lang/llvm-project/pull/64 Note that this also pulls in llvm changes from #72937,HOORAY,2020-06-06T19:36:16Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73077,CLOSED,2020-06-06T22:15:06Z,2020-07-15T05:24:22Z,Stabilize Option::expect_none(msg) and Option::unwrap_none(),aeubanks,NA,NA,NA,CONFUSED,2020-07-07T13:19:03Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/73097,MERGED,2020-06-07T14:08:13Z,2020-06-11T21:36:46Z,Try_run must only be used if toolstate is populated,Mark-Simulacrum,8d620999de52ed62c16f6417d407b0f966e912fd,1,Rollup merge of #73097 - Mark-Simulacrum:clippy-fail r=oli-obk Try_run must only be used if toolstate is populated Clippy's tests were failing the build but that failure was ignored in favor of checking toolstate. This is the correct behavior for toolstate-checked tools but Clippy no longer updates its toolstate status as it should always build. The previous PR of this kind didn't catch this as I expected x.py failures to always lead to a non-successful build in CI but that's not the case specifically for tool testing.,HOORAY,2020-06-07T23:22:05Z,mati865,NA https://github.com/rust-lang/rust/pull/73103,CLOSED,2020-06-07T20:27:22Z,2020-06-22T17:22:26Z,Preserve `Expr`s that have `DefId`s in `ReplaceBodyWithLoop`,ecstatic-morse,NA,NA,NA,HEART,2020-06-07T23:14:27Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73103,CLOSED,2020-06-07T20:27:22Z,2020-06-22T17:22:26Z,Preserve `Expr`s that have `DefId`s in `ReplaceBodyWithLoop`,ecstatic-morse,NA,NA,NA,HOORAY,2020-06-07T23:14:32Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73103,CLOSED,2020-06-07T20:27:22Z,2020-06-22T17:22:26Z,Preserve `Expr`s that have `DefId`s in `ReplaceBodyWithLoop`,ecstatic-morse,NA,NA,NA,HEART,2020-06-08T13:44:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73142,MERGED,2020-06-08T19:08:18Z,2020-06-19T12:12:52Z,Ensure std benchmarks get tested.,ehuss,78f3e9c3446425f01a2ec32056852b949f186ec2,4,Rollup merge of #73142 - ehuss:std-benches r=dtolnay Ensure std benchmarks get tested. This ensures that the std benchmarks don't break in the future. Currently they aren't compiled or tested on CI so they can easily bitrot. Testing a benchmark runs it with one iteration. Adding these should only add a few seconds to CI. Closes #54176 Closes #61913,THUMBS_UP,2020-06-08T22:01:05Z,the8472,NA https://github.com/rust-lang/rust/pull/73169,MERGED,2020-06-09T13:42:31Z,2020-06-11T21:36:41Z,Handle assembler warnings properly,Amanieu,b34111591c6d70bb074e6812697b381048292c7b,9,Rollup merge of #73169 - Amanieu:asm-warnings r=petrochenkov Handle assembler warnings properly Previously all inline asm diagnostics were treated as errors but LLVM sometimes emits warnings and notes as well. Fixes #73160 r? @petrochenkov,EYES,2020-06-09T18:38:02Z,jethrogb,NA https://github.com/rust-lang/rust/pull/73172,MERGED,2020-06-09T16:54:54Z,2020-06-11T14:52:37Z,Fix more clippy warnings,matthiaskrgr,2ac1598d83d03f80345bf17e0df84508e39025f8,18,Rollup merge of #73172 - matthiaskrgr:cl9ppy r=Dylan-DPC Fix more clippy warnings Fixes more of: clippy::unused_unit clippy::op_ref clippy::useless_format clippy::needless_return clippy::useless_conversion clippy::bind_instead_of_map clippy::into_iter_on_ref clippy::redundant_clone clippy::nonminimal_bool clippy::redundant_closure clippy::option_as_ref_deref clippy::len_zero clippy::iter_cloned_collect clippy::filter_next r? @Dylan-DPC,HEART,2020-06-09T18:04:28Z,panaman67,NA https://github.com/rust-lang/rust/pull/73176,MERGED,2020-06-09T19:21:41Z,2020-08-16T20:53:12Z,Add `TyCtxtAt::{ty_error ty_error_with_message}`,LeSeulArtichaut,9b4db695b0ab13885a61deb1b2e4d6599b8c5bbc,1,Auto merge of #73176 - LeSeulArtichaut:tyctxtat-err r=eddyb Add `TyCtxtAt::{ty_error ty_error_with_message}` ~~Only e2d957d was added the rest comes from #70551.~~ I was unsure where to put the implementation for those methods please tell me if there is a better place for it. Closes #72619 ~~blocked on #70551~~. r? @eddyb cc @mark-i-m maybe this should be part of #70551? If so feel free to cherry-pick or ask me to file a PR against your fork.,HEART,2020-06-09T20:53:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73181,MERGED,2020-06-09T21:13:39Z,2020-06-11T14:52:34Z,Automatically prioritize unsoundness issues,LeSeulArtichaut,6cc757e698ec7994411ef327f463726b070a3410,1,Rollup merge of #73181 - LeSeulArtichaut:patch-1 r=spastorino Automatically prioritize unsoundness issues r? @spastorino cc @Mark-Simulacrum @rust-lang/wg-prioritization,THUMBS_UP,2020-06-09T23:43:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/73181,MERGED,2020-06-09T21:13:39Z,2020-06-11T14:52:34Z,Automatically prioritize unsoundness issues,LeSeulArtichaut,6cc757e698ec7994411ef327f463726b070a3410,1,Rollup merge of #73181 - LeSeulArtichaut:patch-1 r=spastorino Automatically prioritize unsoundness issues r? @spastorino cc @Mark-Simulacrum @rust-lang/wg-prioritization,THUMBS_UP,2020-06-10T02:38:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73181,MERGED,2020-06-09T21:13:39Z,2020-06-11T14:52:34Z,Automatically prioritize unsoundness issues,LeSeulArtichaut,6cc757e698ec7994411ef327f463726b070a3410,1,Rollup merge of #73181 - LeSeulArtichaut:patch-1 r=spastorino Automatically prioritize unsoundness issues r? @spastorino cc @Mark-Simulacrum @rust-lang/wg-prioritization,THUMBS_UP,2020-06-10T13:59:16Z,iago-lito,NA https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-10T01:05:21Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-10T20:18:15Z,estebank,NA https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-12T04:15:58Z,est31,NA https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-17T02:53:54Z,tesuji,NA https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-17T17:28:17Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73182,MERGED,2020-06-09T21:15:00Z,2020-06-11T21:36:38Z,Track span of function in method calls and use this in #[track_caller],Aaron1011,84b9145076657579afb09c04b8653bf25b86f59d,92,Rollup merge of #73182 - Aaron1011:feature/call-fn-span r=matthewjasper Track span of function in method calls and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()` each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call` where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990,HEART,2020-06-23T04:40:06Z,tmandry,NA https://github.com/rust-lang/rust/pull/73183,MERGED,2020-06-09T21:16:44Z,2020-06-11T14:52:33Z,Support proc macros in intra doc link resolution,Manishearth,d9cf7a178446ea0da1842de83c84dc687f6b2d6f,3,Rollup merge of #73183 - Manishearth:intra-doc-macro r=GuillaumeGomez Support proc macros in intra doc link resolution The feature was written pre-proc macro resolution so it only supported the wacky MBE resolution rules. This adds support for proc macros as well. cc @GuillaumeGomez Fixes #73173,HEART,2020-06-10T01:57:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/73183,MERGED,2020-06-09T21:16:44Z,2020-06-11T14:52:33Z,Support proc macros in intra doc link resolution,Manishearth,d9cf7a178446ea0da1842de83c84dc687f6b2d6f,3,Rollup merge of #73183 - Manishearth:intra-doc-macro r=GuillaumeGomez Support proc macros in intra doc link resolution The feature was written pre-proc macro resolution so it only supported the wacky MBE resolution rules. This adds support for proc macros as well. cc @GuillaumeGomez Fixes #73173,HEART,2020-06-17T17:27:49Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73188,MERGED,2020-06-09T22:51:05Z,2020-06-14T06:42:49Z,Use preinstalled msys2,mati865,d3d3a14f2f17ae71d3e691743aadd62254d6521d,5,Auto merge of #73188 - mati865:use-preinstalled-msys2 r=pietroalbini Use preinstalled msys2 Fixes https://github.com/rust-lang/rust/issues/65767,HEART,2020-06-12T07:24:49Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73188,MERGED,2020-06-09T22:51:05Z,2020-06-14T06:42:49Z,Use preinstalled msys2,mati865,d3d3a14f2f17ae71d3e691743aadd62254d6521d,5,Auto merge of #73188 - mati865:use-preinstalled-msys2 r=pietroalbini Use preinstalled msys2 Fixes https://github.com/rust-lang/rust/issues/65767,HEART,2020-06-14T02:44:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73194,MERGED,2020-06-10T01:21:21Z,2020-06-13T19:38:47Z,Prefer the associated constants for pattern matching error,tesuji,f738423e6bec663e94fa16e5f9e5bec964678f83,23,Rollup merge of #73194 - lzutao:INT-patterns r=dtolnay Prefer the associated constants for pattern matching error Resolved this comment: https://github.com/rust-lang/rust/issues/68490#issuecomment-641614383,THUMBS_UP,2020-06-10T07:15:34Z,faern,NA https://github.com/rust-lang/rust/pull/73194,MERGED,2020-06-10T01:21:21Z,2020-06-13T19:38:47Z,Prefer the associated constants for pattern matching error,tesuji,f738423e6bec663e94fa16e5f9e5bec964678f83,23,Rollup merge of #73194 - lzutao:INT-patterns r=dtolnay Prefer the associated constants for pattern matching error Resolved this comment: https://github.com/rust-lang/rust/issues/68490#issuecomment-641614383,THUMBS_UP,2020-06-10T19:15:25Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/73194,MERGED,2020-06-10T01:21:21Z,2020-06-13T19:38:47Z,Prefer the associated constants for pattern matching error,tesuji,f738423e6bec663e94fa16e5f9e5bec964678f83,23,Rollup merge of #73194 - lzutao:INT-patterns r=dtolnay Prefer the associated constants for pattern matching error Resolved this comment: https://github.com/rust-lang/rust/issues/68490#issuecomment-641614383,THUMBS_UP,2020-06-13T19:35:11Z,estebank,NA https://github.com/rust-lang/rust/pull/73194,MERGED,2020-06-10T01:21:21Z,2020-06-13T19:38:47Z,Prefer the associated constants for pattern matching error,tesuji,f738423e6bec663e94fa16e5f9e5bec964678f83,23,Rollup merge of #73194 - lzutao:INT-patterns r=dtolnay Prefer the associated constants for pattern matching error Resolved this comment: https://github.com/rust-lang/rust/issues/68490#issuecomment-641614383,THUMBS_UP,2020-06-20T16:26:12Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-10T02:00:39Z,tesuji,NA https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-10T12:41:01Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-10T18:02:12Z,estebank,NA https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-10T19:11:08Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-10T19:42:30Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/73195,MERGED,2020-06-10T01:24:01Z,2020-06-12T01:28:42Z,Provide suggestion to convert numeric op LHS rather than unwrapping RHS,ayazhafiz,7bdf7d09b03f8664e02cd1d80972ea7b1c96a4d5,8,"Rollup merge of #73195 - ayazhafiz:i/73145 r=estebank Provide suggestion to convert numeric op LHS rather than unwrapping RHS Given a code ```rust fn foo(x: u8 y: u32) -> bool { x > y } fn main() {} ``` it could be more helpful to provide a suggestion to do ""u32::from(x)"" rather than ""y.try_into().unwrap()"" since the latter may panic. We do this by passing the LHS of a binary expression up the stack into the coercion checker. Closes #73145",HEART,2020-06-17T17:40:33Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73197,MERGED,2020-06-10T02:16:19Z,2020-07-21T01:24:58Z,Impl Default for ranges,c410-f3r,241374a93b4fe45daf2783b78415ba9a7928c790,1,Rollup merge of #73197 - c410-f3r:ranges r=dtolnay Impl Default for ranges Couldn't find an issue about it. `Range` and friends probably can implement `Default` if `Idx: Default`. For example the following would be possible: ```rust #[derive(Default)] struct Foo(core::ops::RangeToInclusive); let _ = [1 2 3].get(core::ops::Range::default()); core::ops::RangeFrom::::default().take(20).for_each(|x| { dbg!(x); }); fn stuff() { let instance = T::default(); ... more stuff } stuff::>(); ``` Maybe there are some concerns about safety or misunderstandings?,EYES,2020-06-10T02:17:08Z,tesuji,NA https://github.com/rust-lang/rust/pull/73197,MERGED,2020-06-10T02:16:19Z,2020-07-21T01:24:58Z,Impl Default for ranges,c410-f3r,241374a93b4fe45daf2783b78415ba9a7928c790,1,Rollup merge of #73197 - c410-f3r:ranges r=dtolnay Impl Default for ranges Couldn't find an issue about it. `Range` and friends probably can implement `Default` if `Idx: Default`. For example the following would be possible: ```rust #[derive(Default)] struct Foo(core::ops::RangeToInclusive); let _ = [1 2 3].get(core::ops::Range::default()); core::ops::RangeFrom::::default().take(20).for_each(|x| { dbg!(x); }); fn stuff() { let instance = T::default(); ... more stuff } stuff::>(); ``` Maybe there are some concerns about safety or misunderstandings?,EYES,2020-06-10T06:45:12Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73197,MERGED,2020-06-10T02:16:19Z,2020-07-21T01:24:58Z,Impl Default for ranges,c410-f3r,241374a93b4fe45daf2783b78415ba9a7928c790,1,Rollup merge of #73197 - c410-f3r:ranges r=dtolnay Impl Default for ranges Couldn't find an issue about it. `Range` and friends probably can implement `Default` if `Idx: Default`. For example the following would be possible: ```rust #[derive(Default)] struct Foo(core::ops::RangeToInclusive); let _ = [1 2 3].get(core::ops::Range::default()); core::ops::RangeFrom::::default().take(20).for_each(|x| { dbg!(x); }); fn stuff() { let instance = T::default(); ... more stuff } stuff::>(); ``` Maybe there are some concerns about safety or misunderstandings?,EYES,2020-06-26T20:20:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73197,MERGED,2020-06-10T02:16:19Z,2020-07-21T01:24:58Z,Impl Default for ranges,c410-f3r,241374a93b4fe45daf2783b78415ba9a7928c790,1,Rollup merge of #73197 - c410-f3r:ranges r=dtolnay Impl Default for ranges Couldn't find an issue about it. `Range` and friends probably can implement `Default` if `Idx: Default`. For example the following would be possible: ```rust #[derive(Default)] struct Foo(core::ops::RangeToInclusive); let _ = [1 2 3].get(core::ops::Range::default()); core::ops::RangeFrom::::default().take(20).for_each(|x| { dbg!(x); }); fn stuff() { let instance = T::default(); ... more stuff } stuff::>(); ``` Maybe there are some concerns about safety or misunderstandings?,THUMBS_UP,2021-09-05T18:44:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/73198,MERGED,2020-06-10T02:56:43Z,2020-06-11T04:58:50Z,Update cargo,ehuss,e93cb961ba67c73815401291ab42b81e3e5733ae,2,Auto merge of #73198 - ehuss:update-cargo r=ehuss Update cargo 15 commits in 40ebd52206e25c7a576ee42c137cc06a745a167a..1ec223effbbbf9fddd3453cdcae3a96a967608eb 2020-06-01 22:35:00 +0000 to 2020-06-09 20:03:14 +0000 - Default values for `readme` if not specified (rust-lang/cargo#8277) - Fix tree completions. (rust-lang/cargo#8342) - Support `{prefix}` and `{lowerprefix}` markers in `config.json` `dl` key (rust-lang/cargo#8267) - Add environment variables to identify the binary and crate name (rust-lang/cargo#8270) - Bump to 0.47.0 update changelog (rust-lang/cargo#8336) - Nits: Remove unneeded mut and loop (rust-lang/cargo#8334) - 1.45 beta backports (rust-lang/cargo#8331) - Better error message when passing in relative path to Workspace::new (rust-lang/cargo#8321) - Don't hash executable filenames on apple platforms. (rust-lang/cargo#8329) - fix clippy warnings (rust-lang/cargo#8324) - Require latest libgit2 to pull in bugfixes (rust-lang/cargo#8320) - Fix an accidental raw access of field (rust-lang/cargo#8319) - Use mem::take to replace with Default values (rust-lang/cargo#8314) - Allow Windows dylibs without dll suffix. (rust-lang/cargo#8310) - Show alias in help message (rust-lang/cargo#8307),THUMBS_UP,2020-06-10T06:19:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-06-10T12:30:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-06-10T12:41:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-06-11T13:48:01Z,matprec,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-07-22T20:18:40Z,lqd,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-10-16T08:38:14Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-10-16T13:53:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-10-21T20:59:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-12-24T11:12:36Z,tux3,NA https://github.com/rust-lang/rust/pull/73210,MERGED,2020-06-10T12:15:56Z,2020-12-15T11:31:07Z,[mir-opt] Allow debuginfo to be generated for a constant or a Place,wesleywiser,e99a89c7c0b6865a680a2d6169847ec8acc001d3,16,Auto merge of #73210 - wesleywiser:consts_in_debuginfo r=oli-obk [mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.,HEART,2020-12-24T20:06:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73213,MERGED,2020-06-10T13:24:55Z,2020-06-10T21:25:57Z,Fix emcc failure for wasm32.,ehuss,449e8eaa286e407c9cd8cac655b77998fd53db6b,1,Auto merge of #73213 - ehuss:fix-emsdk r=Mark-Simulacrum Fix emcc failure for wasm32. The wasm32 job is currently failing on CI with the error `ERROR: llc executable not found at /usr/bin/llc`. The issue is that https://github.com/emscripten-core/emsdk/pull/472 has changed how emsdk discovers its configuration. We were relying on the global behavior that would use a configuration from the home directory. However it looks like emsdk is moving away from that approach. This change adds the necessary env var for emcc to find the correct configuration. There are a few alternate approaches this could take. The `--no-embedded` option could be passed to `emsdk activate` to use the old behavior but it seems like they want to move away from that. Another option is to source `emsdk_env.sh` which is how these env vars normally get set. I'm not entirely sure how to do that easily in a Dockerfile though.,HOORAY,2020-06-10T17:29:57Z,mati865,NA https://github.com/rust-lang/rust/pull/73230,MERGED,2020-06-11T06:22:58Z,2020-06-11T21:36:33Z,Suggest including unused asm arguments in a comment to avoid error,Amanieu,8650df5dea7a27852a7fa6bd2585905abb521db7,5,Rollup merge of #73230 - Amanieu:asm-unused2 r=petrochenkov Suggest including unused asm arguments in a comment to avoid error We require all arguments to an `asm!` to be used in the template string just like format strings. However in some cases (e.g. `black_box`) it may be desirable to have `asm!` arguments that are not used in the template string. Currently this is a hard error rather than a lint since `#[allow]` does not work on macros (#63221) so this PR suggests using the unused arguments in an asm comment as a workaround. r? @petrochenkov,HEART,2020-06-11T06:53:22Z,unageek,NA https://github.com/rust-lang/rust/pull/73230,MERGED,2020-06-11T06:22:58Z,2020-06-11T21:36:33Z,Suggest including unused asm arguments in a comment to avoid error,Amanieu,8650df5dea7a27852a7fa6bd2585905abb521db7,5,Rollup merge of #73230 - Amanieu:asm-unused2 r=petrochenkov Suggest including unused asm arguments in a comment to avoid error We require all arguments to an `asm!` to be used in the template string just like format strings. However in some cases (e.g. `black_box`) it may be desirable to have `asm!` arguments that are not used in the template string. Currently this is a hard error rather than a lint since `#[allow]` does not work on macros (#63221) so this PR suggests using the unused arguments in an asm comment as a workaround. r? @petrochenkov,HEART,2020-06-17T17:27:32Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73237,MERGED,2020-06-11T13:07:35Z,2020-06-16T18:23:54Z,Check for overflow in DroplessArena and align returned memory,tmiasko,c65f39dac4114052eee2a900a287d767d8b678c6,2,Rollup merge of #73237 - tmiasko:arena r=nnethercote Check for overflow in DroplessArena and align returned memory * Check for overflow when calculating the slice start & end position. * Align the pointer obtained from the allocator ensuring that it satisfies user requested alignment (the allocator is only asked for layout compatible with u8 slice). * Remove an incorrect assertion from DroplessArena::align. * Avoid forming references to an uninitialized memory in DroplessArena. Helps with #73007 #72624.,HEART,2020-07-07T16:12:18Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/73248,MERGED,2020-06-11T18:10:45Z,2020-06-20T02:23:23Z,save_analysis: improve handling of enum struct variant,marmeladema,186640a158d732ec6de0a0a9dc79803c47be551d,1,Rollup merge of #73248 - marmeladema:save-analysis-various-fixes r=Xanewok save_analysis: improve handling of enum struct variant Fixes #61385,HEART,2020-06-12T08:50:25Z,est31,NA https://github.com/rust-lang/rust/pull/73261,MERGED,2020-06-12T00:42:07Z,2020-06-20T02:23:22Z,Suggest `?Sized` when applicable for ADTs,estebank,4910206b4a5b36ce0d82e08f1e33e72875fd28df,17,Rollup merge of #73261 - estebank:generics-sized r=nikomatsakis Suggest `?Sized` when applicable for ADTs Address #71790 fix #27964.,HEART,2020-06-12T06:26:38Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73261,MERGED,2020-06-12T00:42:07Z,2020-06-20T02:23:22Z,Suggest `?Sized` when applicable for ADTs,estebank,4910206b4a5b36ce0d82e08f1e33e72875fd28df,17,Rollup merge of #73261 - estebank:generics-sized r=nikomatsakis Suggest `?Sized` when applicable for ADTs Address #71790 fix #27964.,HEART,2020-06-12T23:09:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-06-14T21:46:30Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-06-18T16:32:59Z,ollie27,NA https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-07-01T00:53:15Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-07-01T08:41:54Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-07-01T08:41:57Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-07-02T16:47:44Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-07-03T05:47:35Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-07-28T08:07:51Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-07-28T12:26:01Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-08-07T22:25:07Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-08-15T01:33:16Z,DianaNites,NA https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-08-15T01:33:17Z,DianaNites,NA https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HOORAY,2020-08-20T20:52:38Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73265,MERGED,2020-06-12T02:34:22Z,2020-07-28T03:01:26Z,mv std libs to library/,mark-i-m,ac48e62db85e6db4bbe026490381ab205f4a614d,875,"Auto merge of #73265 - mark-i-m:mv-std r=Mark-Simulacrum mark-i-m mv std libs to library/ This is the first step in refactoring the directory layout of this repository with further followup steps planned (but not done yet). Background: currently all crates are under src/ without nested src directories and with the unconventional `lib*` prefixes (e.g. `src/libcore/lib.rs`). This directory structures is not idiomatic and makes the `src/` directory rather overwhelming. To improve contributor experience and make things a bit more approachable we are reorganizing the repo a bit. In this PR we move the standard libs (basically anything that is ""runtime"" as opposed to part of the compiler build system or one of the tools etc). The new layout moves these libraries to a new `library/` directory in the root of the repo. Additionally we remove the `lib*` prefixes and add nested `src/` directories. The other crates/tools in this repo are not touched. So in summary: ``` library//src/*.rs src/ // unchanged ``` where `` is: - core - alloc - std - test - proc_macro - panic_abort - panic_unwind - profiler_builtins - term - unwind - rtstartup - backtrace - rustc-std-workspace-* There was a lot of discussion about this and a few rounds of compiler team approvals FCPs MCPs and nominations. The original MCP is https://github.com/rust-lang/compiler-team/issues/298. The final approval of the compiler team was given here: https://github.com/rust-lang/rust/pull/73265#issuecomment-659498446. The name `library` was chosen to complement a later move of the compiler crates to a `compiler/` directory. There was a lot of discussion around adding the nested `src/` directories. Note that this does increase the nesting depth (plausibly important for manual traversal of the tree e.g. through GitHub's UI or `cd`) but this is deemed to be better as it fits the standard layout of Rust crates throughout most of the ecosystem though there is some debate about how much this should apply to multi-crate projects. Overall there seem to be more people in favor of nested `src/` than against. After this PR there are no dependencies out of the `library/` directory except on the `build_helper` (or crates.io crates).",HEART,2020-08-20T20:52:39Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HEART,2020-06-21T15:00:07Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HOORAY,2020-06-23T22:29:40Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HOORAY,2020-07-07T06:46:00Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HOORAY,2020-07-08T18:08:37Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HEART,2020-07-20T09:17:27Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HEART,2020-07-24T09:51:40Z,jdrouet,NA https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HOORAY,2020-07-24T09:51:40Z,jdrouet,NA https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HEART,2020-07-29T21:42:08Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/73270,MERGED,2020-06-12T07:14:32Z,2020-07-22T12:29:22Z,[AVR] Correctly set the pointer address space when constructing pointers to functions,dylanmckay,e22b61bff0bdd08be7665607cb7be3748c8a35d2,11,"Auto merge of #73270 - dylanmckay:avr-use-correct-addrspace r=nagisa [AVR] Correctly set the pointer address space when constructing pointers to functions NOTE: Pull request iterations: * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.0 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.1 * https://github.com/dylanmckay/rust/releases/tag/avr-use-correct-addrspace.2 This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch the `type_i8p` method implcitily assumed the default address space which is not a safe transformation on all targets namely AVR. The Rust compiler already has support for tracking the ""instruction address space"" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch the address space is always either 1) explicitly preserved from the input type or 2) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there or 3) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default ""data"" address space.",HOORAY,2020-07-30T15:57:33Z,Thiez,NA https://github.com/rust-lang/rust/pull/73277,MERGED,2020-06-12T10:36:17Z,2020-06-13T04:38:40Z,fix caller_location intrinsic for Miri,RalfJung,1fb612bd15bb3ef098fd24c20d0727de573b4410,2,Auto merge of #73277 - RalfJung:miri-caller-location r=oli-obk fix caller_location intrinsic for Miri Fixes https://github.com/rust-lang/rust/issues/73272 r? @oli-obk Cc @Aaron1011,HEART,2020-06-12T11:54:38Z,est31,NA https://github.com/rust-lang/rust/pull/73277,MERGED,2020-06-12T10:36:17Z,2020-06-13T04:38:40Z,fix caller_location intrinsic for Miri,RalfJung,1fb612bd15bb3ef098fd24c20d0727de573b4410,2,Auto merge of #73277 - RalfJung:miri-caller-location r=oli-obk fix caller_location intrinsic for Miri Fixes https://github.com/rust-lang/rust/issues/73272 r? @oli-obk Cc @Aaron1011,HEART,2020-06-12T15:41:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-06-27T12:54:43Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-06-27T18:04:25Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-07-18T15:51:15Z,msdinit,NA https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,ROCKET,2020-07-31T02:20:03Z,flyq,flyq951@gmail.com https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-08-01T10:15:31Z,georglauterbach,NA https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,ROCKET,2020-08-06T21:04:04Z,digizeph,NA https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-08-06T21:04:05Z,digizeph,NA https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-08-27T17:26:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-09-05T13:59:54Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/73293,MERGED,2020-06-12T21:55:26Z,2020-06-24T05:10:22Z,Always capture tokens for `macro_rules!` arguments,Aaron1011,3c90ae8404b6b83bc3cba35840ddf7edd500cc86,9,Auto merge of #73293 - Aaron1011:feature/macro-rules-arg-capture r=petrochenkov Always capture tokens for `macro_rules!` arguments When we invoke a proc-macro the `TokenStream` we pass to it may contain 'interpolated' AST fragments represented by `rustc_ast::token::Nonterminal`. In order to correctly pass a `Nonterminal` to a proc-macro we need to have 'captured' its `TokenStream` at the time the AST was parsed. Currently we perform this capturing when attributes are present on items and expressions since we will end up using a `Nonterminal` to pass the item/expr to any proc-macro attributes it is annotated with. However `Nonterminal`s are also introduced by the expansion of metavariables in `macro_rules!` macros. Since these metavariables may be passed to proc-macros we need to have tokens available to avoid the need to pretty-print and reparse (see https://github.com/rust-lang/rust/issues/43081). This PR unconditionally performs token capturing for AST items and expressions that are passed to a `macro_rules!` invocation. We cannot know in advance if captured item/expr will be passed to proc-macro so this is needed to ensure that tokens will always be available when they are needed. This ensures that proc-macros will receive tokens with proper `Spans` (both location and hygiene) in more cases. Like all work on https://github.com/rust-lang/rust/issues/43081 this will cause regressions in proc-macros that were relying on receiving tokens with dummy spans. In this case Crater revealed only one regression: the [Pear](https://github.com/SergioBenitez/Pear) crate (a helper for [rocket](https://github.com/SergioBenitez/Rocket)) which was previously [fixed](https://github.com/SergioBenitez/Pear/pull/25) as part of https://github.com/rust-lang/rust/pull/73084. This regression manifests itself as the following error: ``` [INFO] [stdout] error: proc macro panicked [INFO] [stdout] --> /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34 [INFO] [stdout] | [INFO] [stdout] 119 | let path_and_query = pear_try!(path_and_query(is_pchar)); [INFO] [stdout] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [INFO] [stdout] | [INFO] [stdout] = help: message: called `Option::unwrap()` on a `None` value [INFO] [stdout] = note: this error originates in a macro (in Nightly builds run with -Z macro-backtrace for more info) ``` It can be fixed by running `cargo update -p pear` which updates your `Cargo.lock` to use the latest version of Pear (which includes a bugfix for the regression). Split out from https://github.com/rust-lang/rust/pull/73084/,HEART,2020-10-27T18:09:46Z,linusbeff,NA https://github.com/rust-lang/rust/pull/73297,MERGED,2020-06-12T22:56:29Z,2020-06-26T14:07:29Z,Support configurable deny-warnings for all in-tree crates.,ehuss,10d655bb474c2437e38e2926fc3f4d792bd7f7e9,22,Rollup merge of #73297 - ehuss:tool-warnings r=Mark-Simulacrum Support configurable deny-warnings for all in-tree crates. This removes the hard-coded `deny(warnings)` on all in-tree tools and allows it to be configured from the config. This is just a personal preference as I find `deny(warnings)` frustrating during development or doing small tests. This also fixes some regressions in terms of warning handling. Warnings used to be dependent on `SourceType` but in #64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings. Fixes #64523,HEART,2020-06-12T23:20:37Z,mati865,NA https://github.com/rust-lang/rust/pull/73297,MERGED,2020-06-12T22:56:29Z,2020-06-26T14:07:29Z,Support configurable deny-warnings for all in-tree crates.,ehuss,10d655bb474c2437e38e2926fc3f4d792bd7f7e9,22,Rollup merge of #73297 - ehuss:tool-warnings r=Mark-Simulacrum Support configurable deny-warnings for all in-tree crates. This removes the hard-coded `deny(warnings)` on all in-tree tools and allows it to be configured from the config. This is just a personal preference as I find `deny(warnings)` frustrating during development or doing small tests. This also fixes some regressions in terms of warning handling. Warnings used to be dependent on `SourceType` but in #64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings. Fixes #64523,HEART,2020-06-13T07:58:53Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/73297,MERGED,2020-06-12T22:56:29Z,2020-06-26T14:07:29Z,Support configurable deny-warnings for all in-tree crates.,ehuss,10d655bb474c2437e38e2926fc3f4d792bd7f7e9,22,Rollup merge of #73297 - ehuss:tool-warnings r=Mark-Simulacrum Support configurable deny-warnings for all in-tree crates. This removes the hard-coded `deny(warnings)` on all in-tree tools and allows it to be configured from the config. This is just a personal preference as I find `deny(warnings)` frustrating during development or doing small tests. This also fixes some regressions in terms of warning handling. Warnings used to be dependent on `SourceType` but in #64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings. Fixes #64523,HEART,2020-06-26T14:10:36Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73305,MERGED,2020-06-13T05:29:23Z,2020-06-19T12:12:43Z,Disallow loading crates with non-ascii identifier name.,crlf0710,3b4bec24ab5ca14ba238b7921321a493d63dcd44,5,Rollup merge of #73305 - crlf0710:disallow_loading_monsters r=petrochenkov Disallow loading crates with non-ascii identifier name. This turns off external crate loading with non-ascii identifier names. cc #55467.,THUMBS_UP,2020-06-16T20:02:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73305,MERGED,2020-06-13T05:29:23Z,2020-06-19T12:12:43Z,Disallow loading crates with non-ascii identifier name.,crlf0710,3b4bec24ab5ca14ba238b7921321a493d63dcd44,5,Rollup merge of #73305 - crlf0710:disallow_loading_monsters r=petrochenkov Disallow loading crates with non-ascii identifier name. This turns off external crate loading with non-ascii identifier names. cc #55467.,THUMBS_UP,2020-06-25T03:45:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/73305,MERGED,2020-06-13T05:29:23Z,2020-06-19T12:12:43Z,Disallow loading crates with non-ascii identifier name.,crlf0710,3b4bec24ab5ca14ba238b7921321a493d63dcd44,5,Rollup merge of #73305 - crlf0710:disallow_loading_monsters r=petrochenkov Disallow loading crates with non-ascii identifier name. This turns off external crate loading with non-ascii identifier names. cc #55467.,THUMBS_UP,2020-06-25T05:47:08Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73314,MERGED,2020-06-13T13:01:30Z,2021-09-14T19:18:47Z,"Rename ""--display-warnings"" to ""--display-doctest-warnings""",GuillaumeGomez,c3c0f80d6081092faff801542dd82f0e2420152b,9,"Auto merge of #73314 - GuillaumeGomez:display-warnings r=jyn514 Rename ""--display-warnings"" to ""--display-doctest-warnings"" Fixes #41574. cc `@ollie27` r? `@kinnison`",THUMBS_UP,2020-06-13T14:34:06Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/73314,MERGED,2020-06-13T13:01:30Z,2021-09-14T19:18:47Z,"Rename ""--display-warnings"" to ""--display-doctest-warnings""",GuillaumeGomez,c3c0f80d6081092faff801542dd82f0e2420152b,9,"Auto merge of #73314 - GuillaumeGomez:display-warnings r=jyn514 Rename ""--display-warnings"" to ""--display-doctest-warnings"" Fixes #41574. cc `@ollie27` r? `@kinnison`",HOORAY,2020-06-16T03:29:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73316,MERGED,2020-06-13T14:47:58Z,2020-06-13T19:38:32Z,Rollup of 8 pull requests,Dylan-DPC-zz,06e47688bf15d0215edbe05b21603062f6d2eb5d,38,Auto merge of #73316 - Dylan-DPC:rollup-zgouwou r=Dylan-DPC Rollup of 8 pull requests Successful merges: - #72932 (Clarify the behaviour of Pattern when used with methods like str::contains) - #73066 (Querify whether a type has structural equality (Take 2)) - #73194 (Prefer the associated constants for pattern matching error) - #73241 (Add/update comments about MinGW late_link_args) - #73267 (Use the built cargo for cargotest.) - #73290 (Fix links when pinging notification groups) - #73302 (Adjusted some doctests in libcore to use `should_panic`.) - #73308 (pretty/asm.rs should only be tested for x86_64 and not AArch64) Failed merges: r? @ghost,HOORAY,2020-06-13T19:42:01Z,yerke,NA https://github.com/rust-lang/rust/pull/73334,MERGED,2020-06-13T23:38:50Z,2020-06-20T02:23:16Z,Note numeric literals that can never fit in an expected type,ayazhafiz,b285d68f36435b8ee75fc516be85b21eaa6c78c1,4,Rollup merge of #73334 - ayazhafiz:err/num-type-cannot-fit r=estebank Note numeric literals that can never fit in an expected type re https://github.com/rust-lang/rust/pull/72380#discussion_r438289385 Given the toy code ```rust fn is_positive(n: usize) { n > -1_isize; } ``` We currently get a type mismatch error like the following: ``` error[E0308]: mismatched types --> src/main.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit | 2 | n > (-1_isize).try_into().unwrap(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` But clearly `-1` can never fit into a `usize` so the suggestion will always panic. A more useful message would tell the user that the value can never fit in the expected type: ``` error[E0308]: mismatched types --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | note: `-1_isize` can never fit into `usize` --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ ``` Which is what this commit implements. I only added this check for negative literals because - Currently we can only perform such a check for literals (constant value propagation is outside the scope of the typechecker at this point) - A lint error for out-of-range numeric literals is already emitted IMO it makes more sense to put this check in librustc_lint but as far as I can tell the typecheck pass happens before the lint pass so I've added it here. r? @estebank,HEART,2020-06-14T01:23:19Z,tesuji,NA https://github.com/rust-lang/rust/pull/73334,MERGED,2020-06-13T23:38:50Z,2020-06-20T02:23:16Z,Note numeric literals that can never fit in an expected type,ayazhafiz,b285d68f36435b8ee75fc516be85b21eaa6c78c1,4,Rollup merge of #73334 - ayazhafiz:err/num-type-cannot-fit r=estebank Note numeric literals that can never fit in an expected type re https://github.com/rust-lang/rust/pull/72380#discussion_r438289385 Given the toy code ```rust fn is_positive(n: usize) { n > -1_isize; } ``` We currently get a type mismatch error like the following: ``` error[E0308]: mismatched types --> src/main.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit | 2 | n > (-1_isize).try_into().unwrap(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` But clearly `-1` can never fit into a `usize` so the suggestion will always panic. A more useful message would tell the user that the value can never fit in the expected type: ``` error[E0308]: mismatched types --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | note: `-1_isize` can never fit into `usize` --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ ``` Which is what this commit implements. I only added this check for negative literals because - Currently we can only perform such a check for literals (constant value propagation is outside the scope of the typechecker at this point) - A lint error for out-of-range numeric literals is already emitted IMO it makes more sense to put this check in librustc_lint but as far as I can tell the typecheck pass happens before the lint pass so I've added it here. r? @estebank,THUMBS_UP,2020-06-14T06:23:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/73334,MERGED,2020-06-13T23:38:50Z,2020-06-20T02:23:16Z,Note numeric literals that can never fit in an expected type,ayazhafiz,b285d68f36435b8ee75fc516be85b21eaa6c78c1,4,Rollup merge of #73334 - ayazhafiz:err/num-type-cannot-fit r=estebank Note numeric literals that can never fit in an expected type re https://github.com/rust-lang/rust/pull/72380#discussion_r438289385 Given the toy code ```rust fn is_positive(n: usize) { n > -1_isize; } ``` We currently get a type mismatch error like the following: ``` error[E0308]: mismatched types --> src/main.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | help: you can convert an `isize` to `usize` and panic if the converted value wouldn't fit | 2 | n > (-1_isize).try_into().unwrap(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` But clearly `-1` can never fit into a `usize` so the suggestion will always panic. A more useful message would tell the user that the value can never fit in the expected type: ``` error[E0308]: mismatched types --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ expected `usize` found `isize` | note: `-1_isize` can never fit into `usize` --> test.rs:2:9 | 2 | n > -1_isize; | ^^^^^^^^ ``` Which is what this commit implements. I only added this check for negative literals because - Currently we can only perform such a check for literals (constant value propagation is outside the scope of the typechecker at this point) - A lint error for out-of-range numeric literals is already emitted IMO it makes more sense to put this check in librustc_lint but as far as I can tell the typecheck pass happens before the lint pass so I've added it here. r? @estebank,HEART,2020-06-15T16:41:58Z,estebank,NA https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-14T20:20:22Z,est31,NA https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-14T21:22:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-15T12:48:16Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-15T15:41:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-15T17:42:17Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-16T03:24:55Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,ROCKET,2020-06-16T03:24:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-16T19:23:06Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,ROCKET,2020-06-16T19:23:07Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HOORAY,2020-06-16T19:51:53Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HEART,2020-06-19T06:57:54Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73352,MERGED,2020-06-14T18:36:31Z,2020-06-19T16:01:37Z,Speed up bootstrap a little.,ehuss,61c8925310f5a8eb5b0faaf582c435de326a8e7f,6,Rollup merge of #73352 - ehuss:bootstrap-metadata r=Mark-Simulacrum Speed up bootstrap a little. The bootstrap script was calling `cargo metadata` 3 times (or 6 with `-v`). This is a very expensive operation and this attempts to avoid the extra calls. On my system a simple command like `./x.py test -h -v` goes from about 3 seconds to 0.4. An overview of the changes: - Call `cargo metadata` only once with `--no-deps`. Optional dependencies are filtered in `in_tree_crates` (handling `profiler_builtins` and `rustc_codegen_llvm` which are driven by the config). - Remove a duplicate call to `metadata::build` when using `-v`. I'm not sure why it was there it looks like a mistake or vestigial from previous behavior. - Remove check for `_shim` I believe all the `_shim` crates are now gone. - Remove check for `rustc_` and `*san` for `test::Crate::should_run` these are no longer dependencies in the `test` tree. - Use relative paths in `./x.py test -h -v` output. - Some code cleanup (remove unnecessary `find_compiler_crates` etc.). - Show suite paths (`src/test/ui/...`) in `./x.py test -h -v` output. - Some doc comments.,HEART,2020-06-19T15:57:15Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/73354,MERGED,2020-06-14T19:08:24Z,2020-07-14T08:56:30Z,Update RELEASES.md for 1.45.0,XAMPPRocky,aa29e3de31a2af8cb96ecc87194f5884a1b64259,1,Rollup merge of #73354 - XAMPPRocky:relnotes-1.45.0 r=Mark-Simulacrum Update RELEASES.md for 1.45.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-1.45.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HOORAY,2020-07-10T13:58:30Z,Lokathor,NA https://github.com/rust-lang/rust/pull/73354,MERGED,2020-06-14T19:08:24Z,2020-07-14T08:56:30Z,Update RELEASES.md for 1.45.0,XAMPPRocky,aa29e3de31a2af8cb96ecc87194f5884a1b64259,1,Rollup merge of #73354 - XAMPPRocky:relnotes-1.45.0 r=Mark-Simulacrum Update RELEASES.md for 1.45.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-1.45.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,ROCKET,2020-07-10T13:58:32Z,Lokathor,NA https://github.com/rust-lang/rust/pull/73354,MERGED,2020-06-14T19:08:24Z,2020-07-14T08:56:30Z,Update RELEASES.md for 1.45.0,XAMPPRocky,aa29e3de31a2af8cb96ecc87194f5884a1b64259,1,Rollup merge of #73354 - XAMPPRocky:relnotes-1.45.0 r=Mark-Simulacrum Update RELEASES.md for 1.45.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-1.45.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-07-10T13:58:34Z,Lokathor,NA https://github.com/rust-lang/rust/pull/73357,MERGED,2020-06-14T21:41:07Z,2020-06-20T02:23:14Z,Use `LocalDefId` for import IDs in trait map,petrochenkov,65c33ed7986d76fdefee6cf93081f77fdec2e0c8,13,Rollup merge of #73357 - petrochenkov:tmap r=davidtwco Use `LocalDefId` for import IDs in trait map cc https://github.com/rust-lang/rust/pull/73291#discussion_r439734867,THUMBS_UP,2020-06-14T22:41:36Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73359,MERGED,2020-06-14T21:52:32Z,2020-06-20T06:52:22Z,shim.rs: avoid creating `Call` terminators calling `Self`,jonas-schievink,fe4b4858ca95f1b3af60af05036b25eeef3ef45c,6,Rollup merge of #73359 - jonas-schievink:do-the-shimmy r=matthewjasper shim.rs: avoid creating `Call` terminators calling `Self` Also contains some cleanup and doc comment additions so I could make sense of the code. Fixes https://github.com/rust-lang/rust/issues/73109 Closes https://github.com/rust-lang/rust/pull/73175 r? @matthewjasper,HEART,2020-06-14T22:05:08Z,doctorn,me@nathancorbyn.com https://github.com/rust-lang/rust/pull/73359,MERGED,2020-06-14T21:52:32Z,2020-06-20T06:52:22Z,shim.rs: avoid creating `Call` terminators calling `Self`,jonas-schievink,fe4b4858ca95f1b3af60af05036b25eeef3ef45c,6,Rollup merge of #73359 - jonas-schievink:do-the-shimmy r=matthewjasper shim.rs: avoid creating `Call` terminators calling `Self` Also contains some cleanup and doc comment additions so I could make sense of the code. Fixes https://github.com/rust-lang/rust/issues/73109 Closes https://github.com/rust-lang/rust/pull/73175 r? @matthewjasper,HEART,2020-06-14T22:07:01Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/73359,MERGED,2020-06-14T21:52:32Z,2020-06-20T06:52:22Z,shim.rs: avoid creating `Call` terminators calling `Self`,jonas-schievink,fe4b4858ca95f1b3af60af05036b25eeef3ef45c,6,Rollup merge of #73359 - jonas-schievink:do-the-shimmy r=matthewjasper shim.rs: avoid creating `Call` terminators calling `Self` Also contains some cleanup and doc comment additions so I could make sense of the code. Fixes https://github.com/rust-lang/rust/issues/73109 Closes https://github.com/rust-lang/rust/pull/73175 r? @matthewjasper,HEART,2020-06-14T22:10:12Z,mati865,NA https://github.com/rust-lang/rust/pull/73359,MERGED,2020-06-14T21:52:32Z,2020-06-20T06:52:22Z,shim.rs: avoid creating `Call` terminators calling `Self`,jonas-schievink,fe4b4858ca95f1b3af60af05036b25eeef3ef45c,6,Rollup merge of #73359 - jonas-schievink:do-the-shimmy r=matthewjasper shim.rs: avoid creating `Call` terminators calling `Self` Also contains some cleanup and doc comment additions so I could make sense of the code. Fixes https://github.com/rust-lang/rust/issues/73109 Closes https://github.com/rust-lang/rust/pull/73175 r? @matthewjasper,HEART,2020-06-15T07:11:05Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73359,MERGED,2020-06-14T21:52:32Z,2020-06-20T06:52:22Z,shim.rs: avoid creating `Call` terminators calling `Self`,jonas-schievink,fe4b4858ca95f1b3af60af05036b25eeef3ef45c,6,Rollup merge of #73359 - jonas-schievink:do-the-shimmy r=matthewjasper shim.rs: avoid creating `Call` terminators calling `Self` Also contains some cleanup and doc comment additions so I could make sense of the code. Fixes https://github.com/rust-lang/rust/issues/73109 Closes https://github.com/rust-lang/rust/pull/73175 r? @matthewjasper,HEART,2020-06-15T07:33:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73374,MERGED,2020-06-15T14:56:32Z,2020-06-30T01:45:03Z,rustbuild: Move compiler-builtins build logic to manifest,alexcrichton,a1528c432e45339d9b5602a19ac3571e2900d37b,3,Auto merge of #73374 - alexcrichton:compiler-bulitins-debug-assertions r=Mark-Simulacrum rustbuild: Move compiler-builtins build logic to manifest This commit moves the compiler-builtins-specific build logic from `src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s `[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can ensure that Cargo knows about debug assertions settings and it can also be configured to specifically disable debug assertions unconditionally for compiler-builtins. This should improve rebuild logic when debug-assertions settings change and also improve build-std integration where Cargo externally now has an avenue to learn how to build compiler-builtins as well.,THUMBS_UP,2020-06-15T16:11:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73374,MERGED,2020-06-15T14:56:32Z,2020-06-30T01:45:03Z,rustbuild: Move compiler-builtins build logic to manifest,alexcrichton,a1528c432e45339d9b5602a19ac3571e2900d37b,3,Auto merge of #73374 - alexcrichton:compiler-bulitins-debug-assertions r=Mark-Simulacrum rustbuild: Move compiler-builtins build logic to manifest This commit moves the compiler-builtins-specific build logic from `src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s `[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can ensure that Cargo knows about debug assertions settings and it can also be configured to specifically disable debug assertions unconditionally for compiler-builtins. This should improve rebuild logic when debug-assertions settings change and also improve build-std integration where Cargo externally now has an avenue to learn how to build compiler-builtins as well.,HEART,2020-06-28T07:13:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73384,MERGED,2020-06-15T20:19:27Z,2020-06-18T07:52:27Z,linker: Never pass `-no-pie` to non-gnu linkers,petrochenkov,e55d3f9c5213fe1a25366450127bdff67ad1eca2,1,Auto merge of #73384 - petrochenkov:gnulink r=cuviper linker: Never pass `-no-pie` to non-gnu linkers Fixes https://github.com/rust-lang/rust/issues/73370,THUMBS_UP,2020-06-15T21:31:31Z,xMAC94x,marcel._.maertens@web.de https://github.com/rust-lang/rust/pull/73384,MERGED,2020-06-15T20:19:27Z,2020-06-18T07:52:27Z,linker: Never pass `-no-pie` to non-gnu linkers,petrochenkov,e55d3f9c5213fe1a25366450127bdff67ad1eca2,1,Auto merge of #73384 - petrochenkov:gnulink r=cuviper linker: Never pass `-no-pie` to non-gnu linkers Fixes https://github.com/rust-lang/rust/issues/73370,THUMBS_UP,2020-06-25T05:34:51Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/73398,MERGED,2020-06-16T08:44:20Z,2020-06-23T11:34:33Z,A way forward for pointer equality in const eval,oli-obk,ae38698e7fca180d612dc11be12023076e23236c,39,Rollup merge of #73398 - oli-obk:const_raw_ptr_cmp r=varkor RalfJung nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc #53020,HOORAY,2020-06-16T15:40:04Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73398,MERGED,2020-06-16T08:44:20Z,2020-06-23T11:34:33Z,A way forward for pointer equality in const eval,oli-obk,ae38698e7fca180d612dc11be12023076e23236c,39,Rollup merge of #73398 - oli-obk:const_raw_ptr_cmp r=varkor RalfJung nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc #53020,HOORAY,2020-06-16T19:50:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73398,MERGED,2020-06-16T08:44:20Z,2020-06-23T11:34:33Z,A way forward for pointer equality in const eval,oli-obk,ae38698e7fca180d612dc11be12023076e23236c,39,Rollup merge of #73398 - oli-obk:const_raw_ptr_cmp r=varkor RalfJung nagisa A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc #53020,HOORAY,2020-07-01T00:10:04Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/73411,MERGED,2020-06-16T15:53:03Z,2020-06-21T02:20:19Z,Update bootstrap to rustc 1.45.0-beta.2 (1dc0f6d8e 2020-06-15),ehuss,9a82736e940a022e4f071dc3b55be6b902503820,2,Rollup merge of #73411 - ehuss:bump-stage0 r=Mark-Simulacrum Update bootstrap to rustc 1.45.0-beta.2 (1dc0f6d8e 2020-06-15) Pulls in changes from #73326. Closes #73286,HEART,2020-06-21T08:20:04Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2020-06-16T19:23:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2020-06-30T21:41:13Z,DianaNites,NA https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2020-07-01T07:37:29Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2020-07-02T21:13:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2020-09-03T09:10:22Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/73418,MERGED,2020-06-16T17:49:44Z,2020-06-26T06:11:34Z,Add unstable `core::mem::variant_count` intrinsic,doctorn,c50d9816c7b8fee1a7fa2fb7c6c47fc9b9ddd83f,8,Rollup merge of #73418 - doctorn:variants-intrinsic r=kennytm Add unstable `core::mem::variant_count` intrinsic Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`. I've shown this to a couple of people and they invariably ask 'why on earth?' but there's actually a very neat use case: At the moment if you want to create an opaque array type that's indexed by an `enum` with one element for each variant you either have to hard-code the number of variants add a `LENGTH` variant or use a `Vec` none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic it becomes possible to write the following: ```rust #[derive(Copy Clone)] enum OpaqueIndex { A = 0 B C } struct OpaqueVec(Box<[T; std::mem::num_variants::()]>); impl std::ops::Index for OpaqueVec { type Output = T; fn index(&self idx: OpaqueIndex) -> &Self::Output { &self.0[idx as usize] } } ``` (We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.),THUMBS_UP,2021-12-16T17:29:11Z,nestordemeure,nestordemeure@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T14:51:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T14:55:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T15:04:17Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T15:12:47Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T15:27:23Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-17T15:27:24Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T15:27:25Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T15:34:35Z,mati865,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-17T15:34:35Z,mati865,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T15:34:37Z,mati865,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T15:57:05Z,sfackler,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T16:13:36Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T16:13:36Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-17T16:13:37Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T16:16:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-17T16:16:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T16:45:12Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T16:54:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T17:15:18Z,ehuss,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-17T19:08:21Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-17T20:06:35Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-18T00:25:08Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-18T00:25:09Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-18T00:25:09Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-18T01:20:01Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-18T07:51:47Z,xd009642,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-18T10:27:50Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-18T12:44:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-18T18:31:00Z,JakubOnderka,ahoj@jakubonderka.cz https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-19T19:24:32Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-06-19T21:34:23Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-20T07:24:47Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-26T10:24:14Z,rhysd,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-26T10:24:15Z,rhysd,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-06-26T14:56:35Z,est31,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-06-26T14:56:37Z,est31,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-04T20:38:27Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-07-04T20:38:29Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-07-04T20:38:31Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-05T05:33:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-09T03:57:18Z,light4,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-10T13:11:26Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-13T14:11:11Z,lexxvir,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-07-15T18:26:45Z,tmiasko,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",ROCKET,2020-07-17T15:08:13Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-07-17T22:31:35Z,tmandry,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-07-19T16:34:37Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HEART,2020-07-25T16:37:24Z,theduke,NA https://github.com/rust-lang/rust/pull/73441,MERGED,2020-06-17T14:48:17Z,2020-07-18T19:29:39Z,std: Switch from libbacktrace to gimli,alexcrichton,1fa54ad9680cc82e7301f8ed4e9b7402dfd6ce0e,13,"Auto merge of #73441 - alexcrichton:backtrace-gimli r=Mark-Simulacrum std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called ""libbacktrace"". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time unfortunately though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate by default uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note however that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly but a dependency of `addr2line`. * `adler32`- not used directly either but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293 #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away but correctness and performance may still have bugs arise. The gimli and `backtrace` crates however are actively maintained unlike libbacktrace so this should enable us to at least efficiently apply fixes as situations come up. --- I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR however: * [ ] `gimli` needs to be published to crates.io * [ ] `addr2line` needs a publish * [ ] `miniz_oxide` needs a publish * [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing * [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349) * [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325 https://github.com/rust-lang/backtrace-rs/issues/326 https://github.com/rust-lang/backtrace-rs/issues/350 https://github.com/rust-lang/backtrace-rs/issues/351 Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy. In any case this is a pretty major change so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR) but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this so I'm hoping others can help me figure that out!",HOORAY,2020-07-28T21:14:20Z,estebank,NA https://github.com/rust-lang/rust/pull/73449,MERGED,2020-06-17T18:13:02Z,2020-07-02T12:35:55Z,Provide more information on duplicate lang item error.,ehuss,6b57050b17de7055ca2345867ee4eb8c5b5f1fa9,10,Rollup merge of #73449 - ehuss:duplicate-lang-item r=matthewjasper Provide more information on duplicate lang item error. This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing and this might help in diagnosing what has happened. Here's an example when hitting a bug with Cargo's build-std: ``` error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`. | = note: the lang item is first defined in crate `core` (which `z10` depends on) = note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta = note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta ```,HEART,2020-06-30T16:19:19Z,tmiasko,NA https://github.com/rust-lang/rust/pull/73459,MERGED,2020-06-17T23:35:25Z,2020-06-19T12:12:27Z,Reduce pointer casts in Box::into_boxed_slice,cuviper,fc2ce7cfef1d6f239304ecde52e532fee6045369,1,Rollup merge of #73459 - cuviper:into_boxed_slice-unicast r=dtolnay Reduce pointer casts in Box::into_boxed_slice We only need to cast the pointer once to change `Box` to an array `Box<[T; 1]>` then we can let unsized coercion return `Box<[T]>`.,HEART,2020-06-17T23:58:24Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/73459,MERGED,2020-06-17T23:35:25Z,2020-06-19T12:12:27Z,Reduce pointer casts in Box::into_boxed_slice,cuviper,fc2ce7cfef1d6f239304ecde52e532fee6045369,1,Rollup merge of #73459 - cuviper:into_boxed_slice-unicast r=dtolnay Reduce pointer casts in Box::into_boxed_slice We only need to cast the pointer once to change `Box` to an array `Box<[T; 1]>` then we can let unsized coercion return `Box<[T]>`.,HEART,2020-06-21T09:33:48Z,elichai,NA https://github.com/rust-lang/rust/pull/73460,MERGED,2020-06-17T23:45:33Z,2020-06-26T06:11:32Z,Emit line info for generator variants,tmandry,3f5b8c800e546809b374aecad992689712ab00d6,13,"Rollup merge of #73460 - tmandry:variant-lineinfo r=oli-obk Emit line info for generator variants Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually this could grow into an ""async stack trace"" feature of sorts. While no debugger support this for Rust today this PR adds the debuginfo necessary for that support to exist. [This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet: ``` 0x00000986: DW_TAG_variant DW_AT_discr_value (0x03) 0x00000988: DW_TAG_member DW_AT_name (""3"") DW_AT_type (0x000009bc ""Suspend0"") DW_AT_decl_file (""/home/tmandry/code/playground/generator-simple.rs"") DW_AT_decl_line (6) DW_AT_alignment (8) DW_AT_data_member_location (0x00) ``` The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await) because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically but that can be done independently of this change.) Debuggers don't know how to use this kind of info yet. However we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb. r? @oli-obk cc @eddyb @jonas-schievink Part of #73524.",HOORAY,2020-06-18T19:27:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73460,MERGED,2020-06-17T23:45:33Z,2020-06-26T06:11:32Z,Emit line info for generator variants,tmandry,3f5b8c800e546809b374aecad992689712ab00d6,13,"Rollup merge of #73460 - tmandry:variant-lineinfo r=oli-obk Emit line info for generator variants Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually this could grow into an ""async stack trace"" feature of sorts. While no debugger support this for Rust today this PR adds the debuginfo necessary for that support to exist. [This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet: ``` 0x00000986: DW_TAG_variant DW_AT_discr_value (0x03) 0x00000988: DW_TAG_member DW_AT_name (""3"") DW_AT_type (0x000009bc ""Suspend0"") DW_AT_decl_file (""/home/tmandry/code/playground/generator-simple.rs"") DW_AT_decl_line (6) DW_AT_alignment (8) DW_AT_data_member_location (0x00) ``` The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await) because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically but that can be done independently of this change.) Debuggers don't know how to use this kind of info yet. However we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb. r? @oli-obk cc @eddyb @jonas-schievink Part of #73524.",HOORAY,2020-06-19T01:30:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/73460,MERGED,2020-06-17T23:45:33Z,2020-06-26T06:11:32Z,Emit line info for generator variants,tmandry,3f5b8c800e546809b374aecad992689712ab00d6,13,"Rollup merge of #73460 - tmandry:variant-lineinfo r=oli-obk Emit line info for generator variants Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually this could grow into an ""async stack trace"" feature of sorts. While no debugger support this for Rust today this PR adds the debuginfo necessary for that support to exist. [This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet: ``` 0x00000986: DW_TAG_variant DW_AT_discr_value (0x03) 0x00000988: DW_TAG_member DW_AT_name (""3"") DW_AT_type (0x000009bc ""Suspend0"") DW_AT_decl_file (""/home/tmandry/code/playground/generator-simple.rs"") DW_AT_decl_line (6) DW_AT_alignment (8) DW_AT_data_member_location (0x00) ``` The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await) because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically but that can be done independently of this change.) Debuggers don't know how to use this kind of info yet. However we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb. r? @oli-obk cc @eddyb @jonas-schievink Part of #73524.",HOORAY,2020-08-19T20:19:31Z,betamos,didrik.nordstrom@gmail.com https://github.com/rust-lang/rust/pull/73461,MERGED,2020-06-18T00:00:14Z,2020-09-12T23:49:28Z,Validate built-in attribute placement,calebzulawski,dbb73f8f79ab176a897d5a95e696adb71b957cbe,18,Auto merge of #73461 - calebzulawski:validate-attribute-placement r=matthewjasper Validate built-in attribute placement Closes #54584 closes #47725 closes #54044. I've changed silently ignoring some incorrectly placed attributes to errors. I'm not sure what the policy is since this can theoretically break code (should they be warnings instead? does it warrant a crater run?).,THUMBS_UP,2020-08-12T16:45:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/73461,MERGED,2020-06-18T00:00:14Z,2020-09-12T23:49:28Z,Validate built-in attribute placement,calebzulawski,dbb73f8f79ab176a897d5a95e696adb71b957cbe,18,Auto merge of #73461 - calebzulawski:validate-attribute-placement r=matthewjasper Validate built-in attribute placement Closes #54584 closes #47725 closes #54044. I've changed silently ignoring some incorrectly placed attributes to errors. I'm not sure what the policy is since this can theoretically break code (should they be warnings instead? does it warrant a crater run?).,THUMBS_UP,2020-11-01T03:53:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/73466,MERGED,2020-06-18T03:03:48Z,2020-07-01T18:54:56Z,impl From for String,matthiaskrgr,b7d13c0604f31791ff13558d76942395c29e3348,2,Rollup merge of #73466 - matthiaskrgr:char_into_string r=dtolnay impl From for String This allows us to write ````rust fn char_to_string() -> String { 'a'.into() } ```` which was not possible before.,THUMBS_UP,2020-08-25T07:34:29Z,iago-lito,NA https://github.com/rust-lang/rust/pull/73486,MERGED,2020-06-18T22:21:06Z,2020-06-19T05:03:07Z,Rollup of 17 pull requests,Manishearth,a39c7787ba246353178e099373b9240be0d9e603,197,"Auto merge of #73486 - Manishearth:rollup-11iyqpc r=Manishearth Rollup of 17 pull requests Successful merges: - #70551 (Make all uses of ty::Error delay a span bug) - #71338 (Expand ""recursive opaque type"" diagnostic) - #71976 (Improve diagnostics for `let x += 1`) - #72279 (add raw_ref macros) - #72628 (Add tests for 'impl Default for [T; N]') - #72804 (Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position) - #72814 (remove visit_terminator_kind from MIR visitor) - #72836 (Complete the std::time documentation to warn about the inconsistencies between OS) - #72968 (Only highlight doc search results via mouseover if mouse has moved) - #73034 (Export `#[inline]` fns with extern indicators) - #73315 (Clean up some weird command strings) - #73320 (Make new type param suggestion more targetted) - #73361 (Tweak ""non-primitive cast"" error) - #73425 (Mention functions pointers in the documentation) - #73428 (Fix typo in librustc_ast docs) - #73447 (Improve document for `Result::as_deref(_mut)` methods) - #73476 (Added tooltip for should_panic code examples) Failed merges: r? @ghost",EYES,2020-06-18T22:33:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73490,MERGED,2020-06-19T01:59:12Z,2020-07-14T12:35:03Z,Use step_unchecked more liberally in range iter impls,CAD97,c724b67e1b474262917a5154d74e7072267593fe,1,Auto merge of #73490 - CAD97:range-unchecked-stepping r=Amanieu Use step_unchecked more liberally in range iter impls Without these `_unchecked` these operations on iterators of `char` fail to optimize out the unreachable panicking condition on overflow. cc @cuviper https://github.com/rayon-rs/rayon/pull/771 where this was discovered.,THUMBS_UP,2020-06-19T18:06:25Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/73500,CLOSED,2020-06-19T09:40:36Z,2020-07-24T01:07:35Z,Make lang items private,doctorn,NA,NA,NA,HEART,2020-06-19T13:55:19Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-06-19T12:40:25Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-06-19T15:08:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-06-19T18:27:44Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-06-20T18:36:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-07-22T18:37:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-07-26T02:39:56Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73503,MERGED,2020-06-19T12:05:05Z,2020-07-27T22:14:41Z,convert higher ranked `Predicate`s to `PredicateKind::ForAll`,lcnr,76e83339bb619aba206e5590b1e4b813a154b199,61,Auto merge of #73503 - lcnr:forall-predicate-what-and-why-2 r=nikomatsakis convert higher ranked `Predicate`s to `PredicateKind::ForAll` implements step 2 of https://github.com/rust-lang/compiler-team/issues/285 r? @nikomatsakis,HOORAY,2020-07-27T23:19:09Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/73506,MERGED,2020-06-19T13:53:39Z,2020-06-20T06:52:03Z,Bump Rustfmt and RLS,Xanewok,3e40cca65ab5b0f862a5c538a3aec5c55683688b,3,Rollup merge of #73506 - Xanewok:update-rls r=Xanewok Bump Rustfmt and RLS Fixes #73406 Fixes #73199 Fixes #73407 Fixes #73200 cc @calebcartwright @topecongiro r? @ghost Let's see what CI says first,HEART,2020-06-19T14:01:16Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/73506,MERGED,2020-06-19T13:53:39Z,2020-06-20T06:52:03Z,Bump Rustfmt and RLS,Xanewok,3e40cca65ab5b0f862a5c538a3aec5c55683688b,3,Rollup merge of #73506 - Xanewok:update-rls r=Xanewok Bump Rustfmt and RLS Fixes #73406 Fixes #73199 Fixes #73407 Fixes #73200 cc @calebcartwright @topecongiro r? @ghost Let's see what CI says first,HEART,2020-06-19T14:45:24Z,mati865,NA https://github.com/rust-lang/rust/pull/73506,MERGED,2020-06-19T13:53:39Z,2020-06-20T06:52:03Z,Bump Rustfmt and RLS,Xanewok,3e40cca65ab5b0f862a5c538a3aec5c55683688b,3,Rollup merge of #73506 - Xanewok:update-rls r=Xanewok Bump Rustfmt and RLS Fixes #73406 Fixes #73199 Fixes #73407 Fixes #73200 cc @calebcartwright @topecongiro r? @ghost Let's see what CI says first,HEART,2020-06-19T15:33:24Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73513,MERGED,2020-06-19T17:21:45Z,2020-06-26T18:23:31Z,Show the values and computation that would overflow a const evaluation or propagation,oli-obk,7750c3d46bc19784adb1ee6e37a5ec7e4cd7e772,202,Auto merge of #73513 - oli-obk:const_binop_overflow r=estebank Show the values and computation that would overflow a const evaluation or propagation Fixes #71134 In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics. cc @shepmaster The way this is implemented it is also fairly easy to do the same for overflow panics at runtime but that should be done in a separate PR since it may have runtime performance implications.,HEART,2020-06-19T19:14:48Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/73513,MERGED,2020-06-19T17:21:45Z,2020-06-26T18:23:31Z,Show the values and computation that would overflow a const evaluation or propagation,oli-obk,7750c3d46bc19784adb1ee6e37a5ec7e4cd7e772,202,Auto merge of #73513 - oli-obk:const_binop_overflow r=estebank Show the values and computation that would overflow a const evaluation or propagation Fixes #71134 In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics. cc @shepmaster The way this is implemented it is also fairly easy to do the same for overflow panics at runtime but that should be done in a separate PR since it may have runtime performance implications.,HEART,2020-06-19T19:49:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73513,MERGED,2020-06-19T17:21:45Z,2020-06-26T18:23:31Z,Show the values and computation that would overflow a const evaluation or propagation,oli-obk,7750c3d46bc19784adb1ee6e37a5ec7e4cd7e772,202,Auto merge of #73513 - oli-obk:const_binop_overflow r=estebank Show the values and computation that would overflow a const evaluation or propagation Fixes #71134 In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics. cc @shepmaster The way this is implemented it is also fairly easy to do the same for overflow panics at runtime but that should be done in a separate PR since it may have runtime performance implications.,HEART,2020-06-19T22:17:14Z,estebank,NA https://github.com/rust-lang/rust/pull/73513,MERGED,2020-06-19T17:21:45Z,2020-06-26T18:23:31Z,Show the values and computation that would overflow a const evaluation or propagation,oli-obk,7750c3d46bc19784adb1ee6e37a5ec7e4cd7e772,202,Auto merge of #73513 - oli-obk:const_binop_overflow r=estebank Show the values and computation that would overflow a const evaluation or propagation Fixes #71134 In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics. cc @shepmaster The way this is implemented it is also fairly easy to do the same for overflow panics at runtime but that should be done in a separate PR since it may have runtime performance implications.,HEART,2020-06-20T05:21:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/73515,MERGED,2020-06-19T20:07:42Z,2020-06-23T11:34:23Z,Add second message for LiveDrop errors,pvdrz,0f9a6edc095048f29829d7e501008140fdfe54fd,14,Rollup merge of #73515 - christianpoveda:livedrop-diagnostics r=oli-obk Add second message for LiveDrop errors This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this ``` error[E0493]: destructors cannot be evaluated at compile-time --> src/lib.rs:7:9 | 7 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors error: aborting due to previous error ``` to this ``` error[E0493]: destructors cannot be evaluated at compile-time --> foo.rs:6:9 | 6 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors ... 10 | always_returned = never_returned; | --------------- value is dropped here error: aborting due to previous error ``` r? @RalfJung @ecstatic-morse,HEART,2020-06-19T23:57:01Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73515,MERGED,2020-06-19T20:07:42Z,2020-06-23T11:34:23Z,Add second message for LiveDrop errors,pvdrz,0f9a6edc095048f29829d7e501008140fdfe54fd,14,Rollup merge of #73515 - christianpoveda:livedrop-diagnostics r=oli-obk Add second message for LiveDrop errors This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this ``` error[E0493]: destructors cannot be evaluated at compile-time --> src/lib.rs:7:9 | 7 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors error: aborting due to previous error ``` to this ``` error[E0493]: destructors cannot be evaluated at compile-time --> foo.rs:6:9 | 6 | let mut always_returned = None; | ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors ... 10 | always_returned = never_returned; | --------------- value is dropped here error: aborting due to previous error ``` r? @RalfJung @ecstatic-morse,HEART,2020-06-20T03:28:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/73516,MERGED,2020-06-19T20:39:09Z,2020-06-25T16:29:14Z,Allow dynamic linking for iOS/tvOS targets,Absolucy,d6c674bc14910b2bd2831adfb03726bbe7c8cea3,1,Rollup merge of #73516 - Crabapple-iOS:feature/apple-dynamic-linking r=nikomatsakis Allow dynamic linking for iOS/tvOS targets During the development and testing of the [Crabapple project](https://github.com/Crabapple-iOS/Crabapple) one obstacle was the lack of `cdylib` target support for iOS. Surprisingly once `dynamic_linking` was enabled for iOS targets it worked seemingly flawlessly. I could not find any information on why this was initially or still is disabled.,THUMBS_UP,2020-08-27T17:08:23Z,extrawurst,NA https://github.com/rust-lang/rust/pull/73516,MERGED,2020-06-19T20:39:09Z,2020-06-25T16:29:14Z,Allow dynamic linking for iOS/tvOS targets,Absolucy,d6c674bc14910b2bd2831adfb03726bbe7c8cea3,1,Rollup merge of #73516 - Crabapple-iOS:feature/apple-dynamic-linking r=nikomatsakis Allow dynamic linking for iOS/tvOS targets During the development and testing of the [Crabapple project](https://github.com/Crabapple-iOS/Crabapple) one obstacle was the lack of `cdylib` target support for iOS. Surprisingly once `dynamic_linking` was enabled for iOS targets it worked seemingly flawlessly. I could not find any information on why this was initially or still is disabled.,THUMBS_UP,2020-09-03T17:43:24Z,jadhavajay,NA https://github.com/rust-lang/rust/pull/73516,MERGED,2020-06-19T20:39:09Z,2020-06-25T16:29:14Z,Allow dynamic linking for iOS/tvOS targets,Absolucy,d6c674bc14910b2bd2831adfb03726bbe7c8cea3,1,Rollup merge of #73516 - Crabapple-iOS:feature/apple-dynamic-linking r=nikomatsakis Allow dynamic linking for iOS/tvOS targets During the development and testing of the [Crabapple project](https://github.com/Crabapple-iOS/Crabapple) one obstacle was the lack of `cdylib` target support for iOS. Surprisingly once `dynamic_linking` was enabled for iOS targets it worked seemingly flawlessly. I could not find any information on why this was initially or still is disabled.,THUMBS_UP,2020-10-11T19:05:52Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/73525,MERGED,2020-06-20T00:31:47Z,2020-06-28T12:19:38Z,Prepare for LLVM 11,cuviper,45ec25e088efeabd21c793bde8ab7a05103cc8d2,8,Rollup merge of #73525 - cuviper:llvm11 r=nikic Prepare for LLVM 11 These are just the code changes needed to build with the current LLVM master (version 11). r? @nikic,HEART,2020-06-20T18:28:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73525,MERGED,2020-06-20T00:31:47Z,2020-06-28T12:19:38Z,Prepare for LLVM 11,cuviper,45ec25e088efeabd21c793bde8ab7a05103cc8d2,8,Rollup merge of #73525 - cuviper:llvm11 r=nikic Prepare for LLVM 11 These are just the code changes needed to build with the current LLVM master (version 11). r? @nikic,HEART,2020-10-02T13:00:17Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-06-20T18:29:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-07-28T20:40:20Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-08-05T06:44:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-08-26T16:43:08Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-02T12:59:56Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-08T13:49:57Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-08T13:51:20Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-08T14:10:48Z,edward-mcfarlane-cko,NA https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-08T22:52:36Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HOORAY,2020-10-09T11:05:48Z,iago-lito,NA https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-09T14:36:59Z,Miezhiko,Miezhiko@gmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-10-09T18:24:37Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HOORAY,2020-10-23T05:34:42Z,tanhaipeng,tanhp@outlook.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HEART,2020-11-18T23:39:31Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HOORAY,2020-11-18T23:40:22Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/73526,MERGED,2020-06-20T00:33:34Z,2020-08-23T05:57:59Z,Upgrade to LLVM 11 (rc2),cuviper,7ce71c362be9a89e7897ac066aba6e3e6f747800,7,Auto merge of #73526 - cuviper:rust-llvm11 r=nikic Upgrade to LLVM 11 (rc2) This builds on #73525 to try actually moving rust-lang/llvm-project to LLVM 11.,HOORAY,2021-01-08T11:03:56Z,35359595,35359595i@gmail.com https://github.com/rust-lang/rust/pull/73534,MERGED,2020-06-20T05:45:47Z,2020-06-26T06:11:26Z,Provide suggestions for some moved value errors,estebank,4a245aeec5e7ef71002f91ef9e00eb24646c6ea4,17,Rollup merge of #73534 - estebank:borrowck-suggestions r=matthewjasper Provide suggestions for some moved value errors When encountering an used moved value where the previous move happened in a `match` or `if let` pattern suggest using `ref`. Fix #63988. When encountering a `&mut` value that is used in multiple iterations of a loop suggest reborrowing it with `&mut *`. Fix #62112.,HEART,2020-06-20T08:55:45Z,mati865,NA https://github.com/rust-lang/rust/pull/73555,CLOSED,2020-06-20T17:44:38Z,2020-08-01T12:26:48Z,Document unsafety in `src/libcore/slice/mod.rs`,LeSeulArtichaut,NA,NA,NA,HOORAY,2020-06-20T19:48:32Z,ratijas,NA https://github.com/rust-lang/rust/pull/73555,CLOSED,2020-06-20T17:44:38Z,2020-08-01T12:26:48Z,Document unsafety in `src/libcore/slice/mod.rs`,LeSeulArtichaut,NA,NA,NA,HOORAY,2020-06-20T22:07:47Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/73561,CLOSED,2020-06-20T21:23:22Z,2020-06-22T23:26:51Z,Attempt to fix infinite loop miscompilation from LLVM side,sfanxiang,NA,NA,NA,HEART,2020-06-20T21:37:37Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73561,CLOSED,2020-06-20T21:23:22Z,2020-06-22T23:26:51Z,Attempt to fix infinite loop miscompilation from LLVM side,sfanxiang,NA,NA,NA,HEART,2020-06-22T18:59:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73565,MERGED,2020-06-20T22:15:58Z,2020-08-21T00:58:25Z,Use min_specialization in libcore,matthewjasper,d9d4d39612aae0b8398340bd83d592cafad8e4ec,8,Auto merge of #73565 - matthewjasper:core-min-spec r=nagisa Use min_specialization in libcore Getting `TrustedRandomAccess` to work is the main interesting thing here. - `get_unchecked` is now an unstable hidden method on `Iterator` - The contract for `TrustedRandomAccess` is made clearer in documentation - Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl - Added tests for the side effects of `next_back` and `nth`. closes #68536,HEART,2020-06-22T23:55:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73565,MERGED,2020-06-20T22:15:58Z,2020-08-21T00:58:25Z,Use min_specialization in libcore,matthewjasper,d9d4d39612aae0b8398340bd83d592cafad8e4ec,8,Auto merge of #73565 - matthewjasper:core-min-spec r=nagisa Use min_specialization in libcore Getting `TrustedRandomAccess` to work is the main interesting thing here. - `get_unchecked` is now an unstable hidden method on `Iterator` - The contract for `TrustedRandomAccess` is made clearer in documentation - Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl - Added tests for the side effects of `next_back` and `nth`. closes #68536,HEART,2020-06-23T08:26:17Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73565,MERGED,2020-06-20T22:15:58Z,2020-08-21T00:58:25Z,Use min_specialization in libcore,matthewjasper,d9d4d39612aae0b8398340bd83d592cafad8e4ec,8,Auto merge of #73565 - matthewjasper:core-min-spec r=nagisa Use min_specialization in libcore Getting `TrustedRandomAccess` to work is the main interesting thing here. - `get_unchecked` is now an unstable hidden method on `Iterator` - The contract for `TrustedRandomAccess` is made clearer in documentation - Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl - Added tests for the side effects of `next_back` and `nth`. closes #68536,HEART,2020-08-15T19:31:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73565,MERGED,2020-06-20T22:15:58Z,2020-08-21T00:58:25Z,Use min_specialization in libcore,matthewjasper,d9d4d39612aae0b8398340bd83d592cafad8e4ec,8,Auto merge of #73565 - matthewjasper:core-min-spec r=nagisa Use min_specialization in libcore Getting `TrustedRandomAccess` to work is the main interesting thing here. - `get_unchecked` is now an unstable hidden method on `Iterator` - The contract for `TrustedRandomAccess` is made clearer in documentation - Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl - Added tests for the side effects of `next_back` and `nth`. closes #68536,HEART,2020-08-27T18:01:33Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/73565,MERGED,2020-06-20T22:15:58Z,2020-08-21T00:58:25Z,Use min_specialization in libcore,matthewjasper,d9d4d39612aae0b8398340bd83d592cafad8e4ec,8,Auto merge of #73565 - matthewjasper:core-min-spec r=nagisa Use min_specialization in libcore Getting `TrustedRandomAccess` to work is the main interesting thing here. - `get_unchecked` is now an unstable hidden method on `Iterator` - The contract for `TrustedRandomAccess` is made clearer in documentation - Fixed a bug where `Debug` would create aliasing references when using the specialized zip impl - Added tests for the side effects of `next_back` and `nth`. closes #68536,HEART,2021-01-05T18:09:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2020-06-22T15:02:39Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2020-06-22T15:11:40Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2020-07-09T15:11:19Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",HEART,2020-07-09T19:17:51Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2020-07-16T20:07:25Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",HEART,2020-09-17T20:27:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",HEART,2020-09-17T22:48:27Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2020-09-18T11:58:18Z,clux,NA https://github.com/rust-lang/rust/pull/73566,MERGED,2020-06-20T22:33:20Z,2020-07-16T22:24:10Z,Don't run `everybody_loops` for rustdoc; instead ignore resolution errors,jyn514,c23f045a8b10c92eef5b1fbefea7696065e5977c,27,"Rollup merge of #73566 - jyn514:name-resolve-first r=eddyb Don't run `everybody_loops` for rustdoc; instead ignore resolution errors r? @eddyb cc @petrochenkov @GuillaumeGomez @Manishearth @ecstatic-morse @marmeladema ~~Blocked on https://github.com/rust-lang/rust/pull/73743~~ Merged. ~~Blocked on crater run.~~ Crater popped up some ICEs ([now fixed](https://github.com/rust-lang/rust/pull/73566#issuecomment-656934851)). See [crater run](https://crater-reports.s3.amazonaws.com/pr-73566/index.html) [ICEs](https://github.com/rust-lang/rust/pull/73566#issuecomment-653619212). ~~Blocked on #74070 so that we don't make typeck_tables_of public when it shouldn't be.~~ Merged. Closes #71820 closes #71104 closes #65863. ## What is the motivation for this change? As seen from a lengthy trail of PRs and issues (https://github.com/rust-lang/rust/pull/73532 https://github.com/rust-lang/rust/pull/73103 https://github.com/rust-lang/rust/issues/71820 https://github.com/rust-lang/rust/issues/71104) `everybody_loops` is causing bugs in rustdoc. The main issue is that it does not preserve the validity of the `DefId` tree meaning that operations on DefIds may unexpectedly fail when called later. This is blocking intra-doc links (see https://github.com/rust-lang/rust/pull/73101). This PR starts by removing `everybody_loops` fixing #71104 and #71820. However that brings back the bugs seen originally in https://github.com/rust-lang/rust/pull/43348: Since libstd documents items for all platforms the function bodies sometimes do not type check. Here are the errors from documenting `libstd` with `everybody_loops` disabled and no other changes: ```rust error[E0433]: failed to resolve: could not find `handle` in `sys` --> src/libstd/sys/windows/ext/process.rs:13:27 | 13 | let handle = sys::handle::Handle::new(handle as *mut _); | ^^^^^^ could not find `handle` in `sys` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:544:14 | 544 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() false) | ^^^^^^^^^^^^^ not found in `sys::fs` error[E0425]: cannot find function `symlink_inner` in module `sys::fs` --> src/libstd/sys/windows/ext/fs.rs:564:14 | 564 | sys::fs::symlink_inner(src.as_ref() dst.as_ref() true) | ^^^^^^^^^^^^^ not found in `sys::fs` ``` ## Why does this need changes to `rustc_resolve`? Normally this could be avoided by simply not calling the `typeck_item_bodies` pass. However the errors above happen before type checking in name resolution itself. Since name resolution is intermingled with macro expansion and rustdoc needs expansion to happen before it knows all items to be documented there needs to be someway to ignore _resolution_ errors in function bodies. An alternative solution suggested by @petrochenkov was to not run `everybody_loops` on anything containing a nested `DefId`. This would solve some of the immediate issues but isn't bullet-proof: the following functions still could not be documented if the items in the body failed to resolve: - Functions containing a nested `DefId` (https://github.com/rust-lang/rust/issues/71104) - ~~Functions returning `impl Trait` (https://github.com/rust-lang/rust/pull/43878)~~ These ended up not resolving anyway with this PR. - ~~`const fn` because `loop {}` in `const fn` is unstable (https://github.com/rust-lang/rust/issues/43636)~~ `const_loop` was just stabilized. This also isn't exactly what rustdoc wants which is to avoid looking at function bodies in the first place. ## What changes were made? The hack implemented in this PR is to add an option to ignore all resolution errors in function bodies. This is enabled only for rustdoc. Since resolution errors are ignored the MIR generated will be invalid as can be seen in the following ICE: ```rust error: internal compiler error: broken MIR in DefId(0:11 ~ doc_cfg[8787]::uses_target_feature[0]) (""return type""): bad type [type error] --> /home/joshua/src/rust/src/test/rustdoc/doc-cfg.rs:51:1 | 51 | / pub unsafe fn uses_target_feature() { 52 | | content::should::be::irrelevant(); 53 | | } | |_^ ``` Fortunately rustdoc does not need to access MIR in order to generate documentation. Therefore this also removes the call to `analyze()` in `rustdoc::run_core`. This has the side effect of not generating all lints by default. Most lints are safe to ignore (does rustdoc really need to run liveness analysis?) but `missing_docs` in particular is disabled when it should not be. Re-running `missing_docs` specifically does not help because it causes the typechecking pass to be run bringing back the errors from #24658: ``` error[E0599]: no method named `into_handle` found for struct `sys::unix::pipe::AnonPipe` in the current scope --> src/libstd/sys/windows/ext/process.rs:71:27 | 71 | self.into_inner().into_handle().into_raw() as *mut _ | ^^^^^^^^^^^ method not found in `sys::unix::pipe::AnonPipe` | ``` Because of #73743 we only run typeck on demand. So this only causes an issue for functions returning `impl Trait` which were already special cased by `ReplaceFunctionWithBody`. However it now considers `async fn f() -> T` to be considered `impl Future` where before it was considered to have a concrete `T` type. ## How will this affect future changes to rustdoc? - Any new changes to rustdoc will not be able to perform type checking without bringing back resolution errors in function bodies. + As a corollary any new lints cannot require or perform type checking. In some cases this may require refactoring other parts of the compiler to perform type-checking only on-demand see for example #73743. + As a corollary rustdoc can never again call `tcx.analysis()` unless this PR is reverted altogether. ## Current status - ~~I am not yet sure how to bring back `missing_docs` without running typeck. @eddyb suggested allowing lints to opt-out of type-checking which would probably be another rabbit hole.~~ The opt-out was implemented in https://github.com/rust-lang/rust/pull/73743. However of the rustc lints now _only_ missing_docs is run and no other lints: https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058. We need a team decision on whether that's an acceptable tradeoff. Note that all rustdoc lints are still run (`intra_doc_link_resolution_failure` etc). **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~The implementation of optional errors in `rustc_resolve` is very brute force it should probably be moved from `LateResolver` to `Resolver` to avoid duplicating the logic in many places.~~ I'm mostly happy with it now. - This no longer allows errors in `async fn f() -> T`. This caused breakage in 50 crates out of a full crater run all of which (that I looked at) didn't compile when run with rustc directly. In other words it used to be that they could not be compiled but could still be documented; now they can't be documented either. This needs a decision from the rustdoc team on whether this is acceptable breakage. **UPDATE**: This was deemed acceptable in https://github.com/rust-lang/rust/pull/73566#issuecomment-655750237 - ~~This makes `fn typeck_tables_of` in `rustc_typeck` public. This is not desired behavior but needs the changes from https://github.com/rust-lang/rust/pull/74070 in order to be fixed.~~ Reverted.",THUMBS_UP,2021-02-13T09:26:29Z,bb010g,NA https://github.com/rust-lang/rust/pull/73577,MERGED,2020-06-21T09:11:52Z,2020-06-28T20:48:16Z,Add partition_point,VillSnow,ec4898977a849fc73c8d3198e45c6f17c2bf177a,3,Rollup merge of #73577 - VillSnow:master r=Amanieu Add partition_point Add partition_point in C++. Although existing binary_search in rust does not suitable when the slice has multiple hits this function returns exact point of partition. The definition of this function is very clear and able to accept general matter therefore you can easily get index which you want like lower/upper_bound. https://github.com/rust-lang/rfcs/issues/2184,THUMBS_UP,2020-06-27T12:42:33Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/73587,MERGED,2020-06-21T17:10:57Z,2020-06-24T01:24:12Z,Move remaining `NodeId` APIs from `Definitions` to `Resolver`,marmeladema,045761c8d0cf39e637c3a5cc69fcb25fe2043d71,16,Rollup merge of #73587 - marmeladema:hir-id-ification-final r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov,HOORAY,2020-06-22T00:06:27Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/73587,MERGED,2020-06-21T17:10:57Z,2020-06-24T01:24:12Z,Move remaining `NodeId` APIs from `Definitions` to `Resolver`,marmeladema,045761c8d0cf39e637c3a5cc69fcb25fe2043d71,16,Rollup merge of #73587 - marmeladema:hir-id-ification-final r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov,HOORAY,2020-06-22T01:24:20Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73587,MERGED,2020-06-21T17:10:57Z,2020-06-24T01:24:12Z,Move remaining `NodeId` APIs from `Definitions` to `Resolver`,marmeladema,045761c8d0cf39e637c3a5cc69fcb25fe2043d71,16,Rollup merge of #73587 - marmeladema:hir-id-ification-final r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov,HOORAY,2020-06-22T10:26:04Z,ljedrz,NA https://github.com/rust-lang/rust/pull/73587,MERGED,2020-06-21T17:10:57Z,2020-06-24T01:24:12Z,Move remaining `NodeId` APIs from `Definitions` to `Resolver`,marmeladema,045761c8d0cf39e637c3a5cc69fcb25fe2043d71,16,Rollup merge of #73587 - marmeladema:hir-id-ification-final r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov,HOORAY,2020-06-22T19:51:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73587,MERGED,2020-06-21T17:10:57Z,2020-06-24T01:24:12Z,Move remaining `NodeId` APIs from `Definitions` to `Resolver`,marmeladema,045761c8d0cf39e637c3a5cc69fcb25fe2043d71,16,Rollup merge of #73587 - marmeladema:hir-id-ification-final r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov,HOORAY,2020-06-24T17:00:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73621,MERGED,2020-06-22T14:29:08Z,2020-06-26T06:11:18Z,Document the mut keyword,poliorcetics,f91330abfa4771fe924a178210d2998adc1b77f3,1,Rollup merge of #73621 - poliorcetics:mut-keyword r=steveklabnik Document the mut keyword Partial fix for #34601. Documentation for the `mut` keyword. I think it's okay for it to be quite short this is not the book not the reference but if you find something is missing do not hesitate to tell me.,HEART,2020-06-22T15:10:16Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73622,MERGED,2020-06-22T15:33:50Z,2020-07-02T16:33:32Z,Deny unsafe ops in unsafe fns in libcore,LeSeulArtichaut,500634bf1073248bb5b8561da3720a0820b09869,38,Rollup merge of #73622 - LeSeulArtichaut:unsafe-libcore r=nikomatsakis Deny unsafe ops in unsafe fns in libcore After `liballoc` It's time for `libcore` :D I planned to do this bit by bit to avoid having a big chunk of diffs so to make reviews easier and to make the unsafe blocks narrower and take the time to document them properly. r? @nikomatsakis cc @RalfJung,HEART,2020-06-22T23:49:27Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73622,MERGED,2020-06-22T15:33:50Z,2020-07-02T16:33:32Z,Deny unsafe ops in unsafe fns in libcore,LeSeulArtichaut,500634bf1073248bb5b8561da3720a0820b09869,38,Rollup merge of #73622 - LeSeulArtichaut:unsafe-libcore r=nikomatsakis Deny unsafe ops in unsafe fns in libcore After `liballoc` It's time for `libcore` :D I planned to do this bit by bit to avoid having a big chunk of diffs so to make reviews easier and to make the unsafe blocks narrower and take the time to document them properly. r? @nikomatsakis cc @RalfJung,HEART,2020-09-08T22:14:45Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/73638,MERGED,2020-06-23T03:03:44Z,2020-06-24T19:22:14Z,Remove unused crate imports in 2018 edition crates,nn1ks,38c85b739314e2b5dedf8ff11feec53463261de4,16,Rollup merge of #73638 - yuqio:remove-unused-crate-imports r=nikomatsakis Remove unused crate imports in 2018 edition crates Closes #73570,ROCKET,2021-01-23T07:15:22Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/73638,MERGED,2020-06-23T03:03:44Z,2020-06-24T19:22:14Z,Remove unused crate imports in 2018 edition crates,nn1ks,38c85b739314e2b5dedf8ff11feec53463261de4,16,Rollup merge of #73638 - yuqio:remove-unused-crate-imports r=nikomatsakis Remove unused crate imports in 2018 edition crates Closes #73570,ROCKET,2021-02-18T16:43:00Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/73645,MERGED,2020-06-23T08:49:36Z,2020-07-25T01:44:58Z,Document the ref keyword,poliorcetics,1e55f584b3bfafc335a1a819ddd1ee6f97b7a59e,1,Auto merge of #73645 - poliorcetics:ref-keyword r=jyn514 Document the ref keyword Partial fix for #34601. This documents the `ref` keyword with two examples one failing to compile because the `ref` keyword is missing and the same example fixed with the keyword inserted in the correct place. It also explains (very *very* rapidly) the differences between `&` and `ref`. I put a link to the best place I could find in the Reference but there may be something better that I didn't find.,THUMBS_UP,2020-06-23T10:38:25Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73645,MERGED,2020-06-23T08:49:36Z,2020-07-25T01:44:58Z,Document the ref keyword,poliorcetics,1e55f584b3bfafc335a1a819ddd1ee6f97b7a59e,1,Auto merge of #73645 - poliorcetics:ref-keyword r=jyn514 Document the ref keyword Partial fix for #34601. This documents the `ref` keyword with two examples one failing to compile because the `ref` keyword is missing and the same example fixed with the keyword inserted in the correct place. It also explains (very *very* rapidly) the differences between `&` and `ref`. I put a link to the best place I could find in the Reference but there may be something better that I didn't find.,THUMBS_UP,2020-07-10T09:35:48Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73650,MERGED,2020-06-23T10:47:12Z,2020-07-04T01:09:37Z,Add Docker image to run AArch64 Linux tests,pietroalbini,9a13ef2251531d5856ca62dd8822c9b8139f479a,120,Auto merge of #73650 - pietroalbini:ci-aarch64-gnu r=Mark-Simulacrum Add Docker image to run AArch64 Linux tests This PR adds a Docker image to run the AArch64 Linux test suite on a native AArch64 host platform which will be used in the future to run the test suite in our CI. The image will also be useful for ARM folks to ensure internally that the bugfixes they submit work. This will be the first Docker image designed to run on a non-x86_64 host platform and to prevent surprising behavior this PR moves all images requiring a x86_64 host in the `src/ci/docker/host-x86_64` directory. Paths and scripts are changed accordingly and a helpful error message is added when someone tries to run an image on the wrong architecture: ``` Invalid image: aarch64-gnu Note: the image exists for the aarch64 host architecture Note: the current host architecture is x86_64 ``` The old emulated and disabled `aarch64-gnu` builder is also removed in this PR. This PR is best reviewed commit-by-commit. r? @Mark-Simulacrum,HOORAY,2020-06-23T12:29:14Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73650,MERGED,2020-06-23T10:47:12Z,2020-07-04T01:09:37Z,Add Docker image to run AArch64 Linux tests,pietroalbini,9a13ef2251531d5856ca62dd8822c9b8139f479a,120,Auto merge of #73650 - pietroalbini:ci-aarch64-gnu r=Mark-Simulacrum Add Docker image to run AArch64 Linux tests This PR adds a Docker image to run the AArch64 Linux test suite on a native AArch64 host platform which will be used in the future to run the test suite in our CI. The image will also be useful for ARM folks to ensure internally that the bugfixes they submit work. This will be the first Docker image designed to run on a non-x86_64 host platform and to prevent surprising behavior this PR moves all images requiring a x86_64 host in the `src/ci/docker/host-x86_64` directory. Paths and scripts are changed accordingly and a helpful error message is added when someone tries to run an image on the wrong architecture: ``` Invalid image: aarch64-gnu Note: the image exists for the aarch64 host architecture Note: the current host architecture is x86_64 ``` The old emulated and disabled `aarch64-gnu` builder is also removed in this PR. This PR is best reviewed commit-by-commit. r? @Mark-Simulacrum,HOORAY,2020-07-02T18:43:04Z,mati865,NA https://github.com/rust-lang/rust/pull/73652,MERGED,2020-06-23T11:17:43Z,2020-06-24T19:22:10Z,Add re-exports to use suggestions,da-x,2a6e660ae17f399d93ad9104d8b9a6075d2e84ce,7,Rollup merge of #73652 - da-x:add-reexported-to-use-suggestions r=petrochenkov Add re-exports to use suggestions In the following example an inaccessible path is suggested via `use foo::bar::X;` whereas an accessible public exported path can be suggested instead. ```rust mod foo { mod bar { pub struct X; } pub use self::bar::X; } fn main() { X; } ``` This fixes the issue.,HOORAY,2020-06-23T12:09:22Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/73655,MERGED,2020-06-23T12:36:12Z,2020-07-22T18:17:58Z,va_args implementation for AAPCS.,JamieCunliffe,dade0f1f6c25dde9974b61b76f0e9dc01cf3ea68,4,Rollup merge of #73655 - JamieCunliffe:jamie_va-args-c r=nikic va_args implementation for AAPCS. Implement the va args in codegen for AAPCS this will be used as the default va_args implementation for AArch64 rather than the va_args llvm-ir as it currently is. This should fix the following issues: https://github.com/rust-lang/rust/issues/56475 https://github.com/rust-lang/rust/issues/72579,HEART,2020-07-15T17:26:10Z,dlrobertson,dan@dlrobertson.com https://github.com/rust-lang/rust/pull/73655,MERGED,2020-06-23T12:36:12Z,2020-07-22T18:17:58Z,va_args implementation for AAPCS.,JamieCunliffe,dade0f1f6c25dde9974b61b76f0e9dc01cf3ea68,4,Rollup merge of #73655 - JamieCunliffe:jamie_va-args-c r=nikic va_args implementation for AAPCS. Implement the va args in codegen for AAPCS this will be used as the default va_args implementation for AArch64 rather than the va_args llvm-ir as it currently is. This should fix the following issues: https://github.com/rust-lang/rust/issues/56475 https://github.com/rust-lang/rust/issues/72579,HEART,2020-07-19T19:32:23Z,daira,NA https://github.com/rust-lang/rust/pull/73656,MERGED,2020-06-23T13:30:46Z,2020-08-11T17:33:47Z,move Deaggregate pass to post_borrowck_cleanup,oli-obk,cbe7c5ce705896d4e22bf6096590bc1f17993b78,40,"Auto merge of #73656 - oli-obk:deaggregate-is-cleanup r=wesleywiser move Deaggregate pass to post_borrowck_cleanup Reopen of #71946 Only the second commit is from this PR the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done In #70073 MIR pass handling got reorganized but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass while conceptually more of a ""cleanup"" pass (and one that should be run before optimizations) was run in the middle of the optimization chain. Likely this is an accident of history so I suggest we try and clean that up by making it a proper cleanup pass. This does change mir-opt output because deaggregation now runs before const-prop instead of after. r? @wesleywiser @rust-lang/wg-mir-opt cc @RalfJung",THUMBS_UP,2020-06-23T17:06:47Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73667,MERGED,2020-06-23T18:09:53Z,2020-06-24T19:22:08Z,Update BTreeMap::new() doc,nrabulinski,c4e15b5c5a727af73758246396f42616099deb90,1,Rollup merge of #73667 - nrabulinski:master r=Dylan-DPC Update BTreeMap::new() doc Updates the documentation according to [this comment](https://github.com/rust-lang/rust/pull/72876/files/0c5c644c91edf6ed949cfa5ffc524f43369df604#r433232581) on #72876,HEART,2020-06-23T21:53:00Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-24T23:19:37Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T08:49:30Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T11:26:29Z,CryZe,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T11:30:27Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T12:19:11Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T13:11:05Z,vultix,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T14:35:21Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T15:54:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T16:47:00Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,ROCKET,2020-06-25T18:36:22Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T18:36:30Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T21:19:17Z,Gijsvs,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T23:20:04Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-25T23:45:38Z,yerke,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T00:23:21Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T01:47:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T02:39:01Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T04:37:02Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HEART,2020-06-26T15:19:08Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T17:09:37Z,banool,danielporteous1@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T20:12:41Z,zphixon,zphixon@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-26T22:31:48Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-27T16:38:39Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-06-30T19:21:02Z,OddCoincidence,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-08T20:07:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HEART,2020-07-08T20:07:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,ROCKET,2020-07-08T20:08:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-08T22:42:15Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-09T02:47:00Z,samlh,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-09T08:10:19Z,fiahil,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-09T08:20:34Z,B4dM4n,fabianm88@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-10T12:22:11Z,tux3,NA https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2020-07-10T23:47:36Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/73670,MERGED,2020-06-23T21:47:55Z,2020-07-04T04:55:06Z,Add `format_args_capture` feature,davidhewitt,4a8d9ea80ff8d7ec4dcc6da7d36fe60ecaa55539,13,Rollup merge of #73670 - davidhewitt:format-args-capture r=varkor Add `format_args_capture` feature This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795). Note that as dicussed in the tracking issue (#67984) the feature gate has been called `format_args_capture`. Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.,HOORAY,2021-05-16T18:30:46Z,Exodus,alvaradoma@gmail.com https://github.com/rust-lang/rust/pull/73674,MERGED,2020-06-24T00:32:34Z,2020-06-26T06:11:11Z,Tweak binop errors,estebank,7fb7765cdab6bd9d0dddd5275dd73775938af299,14,Rollup merge of #73674 - estebank:op-trait-bound-suggestion r=davidtwco Tweak binop errors * Suggest potentially missing binop trait bound (fix #73416) * Use structured suggestion for dereference in binop,HEART,2020-06-24T01:42:41Z,tesuji,NA https://github.com/rust-lang/rust/pull/73678,MERGED,2020-06-24T02:47:15Z,2020-07-01T18:54:46Z,Update Box::from_raw example to generalize better,Keno,6556f269918124b43db67367867c6930cb3189c9,1,Rollup merge of #73678 - Keno:patch-1 r=LukasKalbertodt Update Box::from_raw example to generalize better I know very little about rust so I saw the example here ``` use std::alloc::{alloc Layout}; unsafe { let ptr = alloc(Layout::new::()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing ``` let layout = Layout::new::(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T` which ended up crashing with SIGSEGV because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file which use `.write`. I also added a comment to explain it but I'm not too attached to that and can see it being too verbose in this place.,HEART,2020-06-24T16:29:29Z,ararslan,NA https://github.com/rust-lang/rust/pull/73678,MERGED,2020-06-24T02:47:15Z,2020-07-01T18:54:46Z,Update Box::from_raw example to generalize better,Keno,6556f269918124b43db67367867c6930cb3189c9,1,Rollup merge of #73678 - Keno:patch-1 r=LukasKalbertodt Update Box::from_raw example to generalize better I know very little about rust so I saw the example here ``` use std::alloc::{alloc Layout}; unsafe { let ptr = alloc(Layout::new::()) as *mut i32; *ptr = 5; let x = Box::from_raw(ptr); } ``` and tried to generalize it by writing ``` let layout = Layout::new::(); let new_obj = unsafe { let ptr = alloc(layout) as *mut T; *ptr = obj; Box::from_raw(ptr) }; ``` for some more complicated `T` which ended up crashing with SIGSEGV because it tried to `drop_in_place` the previous object in `ptr` which is of course garbage. I think that changing this example to use `.write` instead would be a good idea to suggest the correct generalization. It is also more consistent with other documentation items in this file which use `.write`. I also added a comment to explain it but I'm not too attached to that and can see it being too verbose in this place.,HEART,2020-06-28T16:44:35Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/73684,MERGED,2020-06-24T08:00:14Z,2020-07-02T16:33:30Z,add spans to injected coverage counters extract with CoverageData query,richkadel,dc762cea33a8b2f46c362d75f3d3327c88d1afe6,27,Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2 r=wesleywiser add spans to injected coverage counters extract with CoverageData query This is the next iteration on the Rust Coverage implementation and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you I can quickly expand on this to build a separate IndexVec for counter expressions using a separate call that will be ignored during code generation but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation,HEART,2020-06-29T20:10:13Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/73684,MERGED,2020-06-24T08:00:14Z,2020-07-02T16:33:30Z,add spans to injected coverage counters extract with CoverageData query,richkadel,dc762cea33a8b2f46c362d75f3d3327c88d1afe6,27,Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2 r=wesleywiser add spans to injected coverage counters extract with CoverageData query This is the next iteration on the Rust Coverage implementation and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you I can quickly expand on this to build a separate IndexVec for counter expressions using a separate call that will be ignored during code generation but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation,HEART,2020-10-10T16:16:38Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/73693,MERGED,2020-06-24T12:50:36Z,2020-07-04T04:55:05Z,Use exhaustive match in const_prop.rs,wesleywiser,50dcefca7813a2985c0f1c1863efbe5ce7958815,1,Rollup merge of #73693 - wesleywiser:const_prop_exhaustive_match r=oli-obk Use exhaustive match in const_prop.rs Addresses a comment left by @RalfJung on #73613 r? @RalfJung,HEART,2020-06-24T12:59:21Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73726,MERGED,2020-06-25T15:49:59Z,2020-07-03T03:12:55Z,resolve: disallow labelled breaks/continues through closures/async blocks,davidtwco,2d83cbb8b68d6a83a9f0559d89904a6a1e0bb9e3,26,Rollup merge of #73726 - davidtwco:issue-73541-labelled-break-through-closure-async r=petrochenkov resolve: disallow labelled breaks/continues through closures/async blocks Fixes #73541. This PR modifies name resolution to prohibit labelled breaks/continues through closures or async blocks fixing an ICE. In addition it improves the diagnostics surrounding labelled breaks/continues through closures or async blocks by informing the user if the label exists in an parent scope and telling them that won't work. r? @petrochenkov (resolve) cc @estebank (diagnostic changes) @tmandry (issue is from `wg-async-foundations`),HEART,2020-06-25T15:56:53Z,estebank,NA https://github.com/rust-lang/rust/pull/73743,MERGED,2020-06-26T00:46:54Z,2020-06-26T10:11:50Z,rustc_lint: only query `typeck_tables_of` when a lint needs it.,eddyb,14e65d5e95da0f7e4f9127cf1598fa46f33972e8,106,"Auto merge of #73743 - eddyb:lint-on-demand-typeck-tables r=Manishearth rustc_lint: only query `typeck_tables_of` when a lint needs it. This was prompted by @jyn514 running into a situation where `rustdoc` wants to run the `unused_doc` lint without triggering type-checking (as an alternative to the ""everybody loops"" approach - type-checking may error/ICE because of the `rustdoc` feature of allowing multi-platform docs where the actual bodies of functions may refer to APIs for different platforms). There was also this comment in the source: ```rust // FIXME: Make this lazy to avoid running the TypeckTables query? ``` The main effect of this is for lint authors who now need to use `cx.tables()` to get `&TypeckTables` as opposed to having them always available in `cx.tables`. r? @oli-obk or @Manishearth",HEART,2020-06-26T00:52:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73743,MERGED,2020-06-26T00:46:54Z,2020-06-26T10:11:50Z,rustc_lint: only query `typeck_tables_of` when a lint needs it.,eddyb,14e65d5e95da0f7e4f9127cf1598fa46f33972e8,106,"Auto merge of #73743 - eddyb:lint-on-demand-typeck-tables r=Manishearth rustc_lint: only query `typeck_tables_of` when a lint needs it. This was prompted by @jyn514 running into a situation where `rustdoc` wants to run the `unused_doc` lint without triggering type-checking (as an alternative to the ""everybody loops"" approach - type-checking may error/ICE because of the `rustdoc` feature of allowing multi-platform docs where the actual bodies of functions may refer to APIs for different platforms). There was also this comment in the source: ```rust // FIXME: Make this lazy to avoid running the TypeckTables query? ``` The main effect of this is for lint authors who now need to use `cx.tables()` to get `&TypeckTables` as opposed to having them always available in `cx.tables`. r? @oli-obk or @Manishearth",HEART,2020-06-26T01:04:35Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/73743,MERGED,2020-06-26T00:46:54Z,2020-06-26T10:11:50Z,rustc_lint: only query `typeck_tables_of` when a lint needs it.,eddyb,14e65d5e95da0f7e4f9127cf1598fa46f33972e8,106,"Auto merge of #73743 - eddyb:lint-on-demand-typeck-tables r=Manishearth rustc_lint: only query `typeck_tables_of` when a lint needs it. This was prompted by @jyn514 running into a situation where `rustdoc` wants to run the `unused_doc` lint without triggering type-checking (as an alternative to the ""everybody loops"" approach - type-checking may error/ICE because of the `rustdoc` feature of allowing multi-platform docs where the actual bodies of functions may refer to APIs for different platforms). There was also this comment in the source: ```rust // FIXME: Make this lazy to avoid running the TypeckTables query? ``` The main effect of this is for lint authors who now need to use `cx.tables()` to get `&TypeckTables` as opposed to having them always available in `cx.tables`. r? @oli-obk or @Manishearth",HEART,2020-06-26T03:25:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/73767,MERGED,2020-06-26T13:56:43Z,2020-07-30T00:18:36Z,Refactor librustdoc html backend,P1n3appl3,6b269e44322cfca727fd0e793d3a60bd371cbcae,15,Auto merge of #73767 - P1n3appl3:rustdoc-formats r=tmandry Refactor librustdoc html backend This PR moves several types out of the librustdoc::html module so that they can be used by a future json backend. These changes are a re-implementation of [some work done 6 months ago](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:multiple-output-formats) by @GuillaumeGomez. I'm currently working on said json backend and will put up an RFC soon with the proposed implementation. There are a couple of changes that are more substantial than relocating structs to a different module: 1. The `Cache` is no longer part of the `html::render::Context` type and therefor it needs to be explicitly passed to any functions that access it. 2. The driving function `html::render::run` has been rewritten to use the `FormatRenderer` trait which should allow different backends to re-use the driving code. r? @GuillaumeGomez cc @tmandry @betamos,HEART,2020-06-26T18:33:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73767,MERGED,2020-06-26T13:56:43Z,2020-07-30T00:18:36Z,Refactor librustdoc html backend,P1n3appl3,6b269e44322cfca727fd0e793d3a60bd371cbcae,15,Auto merge of #73767 - P1n3appl3:rustdoc-formats r=tmandry Refactor librustdoc html backend This PR moves several types out of the librustdoc::html module so that they can be used by a future json backend. These changes are a re-implementation of [some work done 6 months ago](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:multiple-output-formats) by @GuillaumeGomez. I'm currently working on said json backend and will put up an RFC soon with the proposed implementation. There are a couple of changes that are more substantial than relocating structs to a different module: 1. The `Cache` is no longer part of the `html::render::Context` type and therefor it needs to be explicitly passed to any functions that access it. 2. The driving function `html::render::run` has been rewritten to use the `FormatRenderer` trait which should allow different backends to re-use the driving code. r? @GuillaumeGomez cc @tmandry @betamos,HEART,2020-06-29T02:34:35Z,rrbutani,NA https://github.com/rust-lang/rust/pull/73767,MERGED,2020-06-26T13:56:43Z,2020-07-30T00:18:36Z,Refactor librustdoc html backend,P1n3appl3,6b269e44322cfca727fd0e793d3a60bd371cbcae,15,Auto merge of #73767 - P1n3appl3:rustdoc-formats r=tmandry Refactor librustdoc html backend This PR moves several types out of the librustdoc::html module so that they can be used by a future json backend. These changes are a re-implementation of [some work done 6 months ago](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:multiple-output-formats) by @GuillaumeGomez. I'm currently working on said json backend and will put up an RFC soon with the proposed implementation. There are a couple of changes that are more substantial than relocating structs to a different module: 1. The `Cache` is no longer part of the `html::render::Context` type and therefor it needs to be explicitly passed to any functions that access it. 2. The driving function `html::render::run` has been rewritten to use the `FormatRenderer` trait which should allow different backends to re-use the driving code. r? @GuillaumeGomez cc @tmandry @betamos,HEART,2020-07-03T07:05:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73767,MERGED,2020-06-26T13:56:43Z,2020-07-30T00:18:36Z,Refactor librustdoc html backend,P1n3appl3,6b269e44322cfca727fd0e793d3a60bd371cbcae,15,Auto merge of #73767 - P1n3appl3:rustdoc-formats r=tmandry Refactor librustdoc html backend This PR moves several types out of the librustdoc::html module so that they can be used by a future json backend. These changes are a re-implementation of [some work done 6 months ago](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:multiple-output-formats) by @GuillaumeGomez. I'm currently working on said json backend and will put up an RFC soon with the proposed implementation. There are a couple of changes that are more substantial than relocating structs to a different module: 1. The `Cache` is no longer part of the `html::render::Context` type and therefor it needs to be explicitly passed to any functions that access it. 2. The driving function `html::render::run` has been rewritten to use the `FormatRenderer` trait which should allow different backends to re-use the driving code. r? @GuillaumeGomez cc @tmandry @betamos,HEART,2020-07-06T21:45:49Z,tmandry,NA https://github.com/rust-lang/rust/pull/73771,MERGED,2020-06-26T16:26:29Z,2020-07-16T22:24:05Z,Don't pollute docs/suggestions with libstd deps,alexcrichton,a8bb2458e1798891112e53b08fe72477fdb75070,2,"Rollup merge of #73771 - alexcrichton:ignore-unstable r=estebank GuillaumeGomez Don't pollute docs/suggestions with libstd deps Currently dependency crates of the standard library can sometimes leak into error messages such as when traits to import are suggested. Additionally they can leak into documentation such as in the list of ""all traits implemented by `u32`"". The dependencies of the standard library however are intended to be private. The dependencies of the standard library can't actually be stabl-y imported nor is the documentation that relevant since you can't import them on stable either. This commit updates both the compiler and rustdoc to ignore unstable traits in these two scenarios. Specifically the suggestion for traits to import ignore unstable traits and similarly the list of traits implemented by a type excludes unstable traits. This commit is extracted from #73441 where the addition of some new dependencies to the standard library was showed to leak into various error messages and documentation. The intention here is to go ahead and land these changes ahead of that since it will likely take some time to land.",THUMBS_UP,2020-07-06T15:06:16Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/73771,MERGED,2020-06-26T16:26:29Z,2020-07-16T22:24:05Z,Don't pollute docs/suggestions with libstd deps,alexcrichton,a8bb2458e1798891112e53b08fe72477fdb75070,2,"Rollup merge of #73771 - alexcrichton:ignore-unstable r=estebank GuillaumeGomez Don't pollute docs/suggestions with libstd deps Currently dependency crates of the standard library can sometimes leak into error messages such as when traits to import are suggested. Additionally they can leak into documentation such as in the list of ""all traits implemented by `u32`"". The dependencies of the standard library however are intended to be private. The dependencies of the standard library can't actually be stabl-y imported nor is the documentation that relevant since you can't import them on stable either. This commit updates both the compiler and rustdoc to ignore unstable traits in these two scenarios. Specifically the suggestion for traits to import ignore unstable traits and similarly the list of traits implemented by a type excludes unstable traits. This commit is extracted from #73441 where the addition of some new dependencies to the standard library was showed to leak into various error messages and documentation. The intention here is to go ahead and land these changes ahead of that since it will likely take some time to land.",THUMBS_UP,2020-07-10T00:03:56Z,estebank,NA https://github.com/rust-lang/rust/pull/73778,MERGED,2020-06-26T20:40:02Z,2020-07-01T18:54:37Z,Make `likely` and `unlikely` const gated by feature `const_unlikely`,nbdd0121,ec41d01d4f7c668a75eff1ba724b8a67c7ec90b4,6,Rollup merge of #73778 - nbdd0121:const_likely r=oli-obk Make `likely` and `unlikely` const gated by feature `const_unlikely` This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`. cc @RalfJung @nagisa r? @oli-obk,THUMBS_UP,2020-07-10T22:33:31Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/73782,CLOSED,2020-06-27T01:31:13Z,2020-07-19T14:25:38Z,ci: Update dist-{i686 x86_64}-linux to CentOS 6,cuviper,NA,NA,NA,HOORAY,2020-06-27T08:45:11Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/73782,CLOSED,2020-06-27T01:31:13Z,2020-07-19T14:25:38Z,ci: Update dist-{i686 x86_64}-linux to CentOS 6,cuviper,NA,NA,NA,HOORAY,2020-06-28T07:42:38Z,mati865,NA https://github.com/rust-lang/rust/pull/73796,MERGED,2020-06-27T11:39:18Z,2020-06-28T12:19:19Z,replace more `DefId`s with `LocalDefId`,lcnr,800d2e3a00de4d8e34371c1c1cb9d86cf7074c40,19,Rollup merge of #73796 - lcnr:LocalDefId r=matthewjasper replace more `DefId`s with `LocalDefId` part of https://github.com/rust-lang/rust/issues/70853,HEART,2020-06-27T16:44:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73800,MERGED,2020-06-27T13:44:10Z,2020-06-28T20:48:00Z,Forward Hash::write_iN to Hash::write_uN,nikic,95da53f7fd7434f2cb13b069d4e26b961879cf65,1,Rollup merge of #73800 - nikic:hash_i r=kennytm Forward Hash::write_iN to Hash::write_uN The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()` because some Hasher implementations implement only the `write_uN()` variants with the expectation that `write_iN()` will use the same implementation. Most notably this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself. This used to be the case previously but was broken in #59982. As the PR description makes no mention of this particular change I assume it was unintentional. In a local test this mitigates the regression from #73526 on at least one test-case (cc @cuviper) because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.,THUMBS_UP,2020-06-27T16:19:59Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/73806,MERGED,2020-06-27T18:02:47Z,2020-07-01T18:54:32Z,Use an 'approximate' universal upper bound when reporting region errors,Aaron1011,f213957c2e01067ab20ba74f71371093ed0b43bb,9,Rollup merge of #73806 - Aaron1011:feature/approx-universal-upper r=estebank Use an 'approximate' universal upper bound when reporting region errors Fixes #67765 When reporting errors during MIR region inference we sometimes use `universal_upper_bound` to obtain a named universal region that we can display to the user. However this is not always possible - in a case like `fn foo<'a 'b>() { .. }` the only upper bound for a region containing `'a` and `'b` is `'static`. When displaying diagnostics it's usually better to display *some* named region (even if there are multiple involved) rather than fall back to a generic error involving `'static`. This commit adds a new `approx_universal_upper_bound` method which uses the lowest-numbered universal region if the only alternative is to return `'static`.,HEART,2020-06-28T11:18:06Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73810,CLOSED,2020-06-27T19:14:17Z,2020-07-09T15:33:56Z,Add docs for intra-doc-links,Manishearth,NA,NA,NA,HEART,2020-06-27T19:42:57Z,mcarton,NA https://github.com/rust-lang/rust/pull/73810,CLOSED,2020-06-27T19:14:17Z,2020-07-09T15:33:56Z,Add docs for intra-doc-links,Manishearth,NA,NA,NA,HEART,2020-06-28T01:31:12Z,ehuss,NA https://github.com/rust-lang/rust/pull/73810,CLOSED,2020-06-27T19:14:17Z,2020-07-09T15:33:56Z,Add docs for intra-doc-links,Manishearth,NA,NA,NA,HEART,2020-06-29T12:42:56Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73813,MERGED,2020-06-27T20:58:30Z,2020-06-28T20:47:57Z,Rename two `Resolver` traits,petrochenkov,dd811399271d9812d73d11c656c58947adfafa57,13,Rollup merge of #73813 - petrochenkov:restrait r=davidtwco Rename two `Resolver` traits `trait Resolver` -> `trait ResolverExpand` for the resolver interface available from expansion. `trait Resolver` -> `trait ResolverAstLowering` for the resolver interface available from AST lowering. Addresses https://github.com/rust-lang/rust/pull/73587#discussion_r443242556,THUMBS_UP,2020-06-28T11:15:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73815,CLOSED,2020-06-27T21:14:05Z,2020-10-06T13:34:38Z,correctly dedup `ExistentialPredicate`s,lcnr,NA,NA,NA,HOORAY,2020-06-27T21:45:20Z,estebank,NA https://github.com/rust-lang/rust/pull/73815,CLOSED,2020-06-27T21:14:05Z,2020-10-06T13:34:38Z,correctly dedup `ExistentialPredicate`s,lcnr,NA,NA,NA,HOORAY,2020-06-28T01:39:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/73819,MERGED,2020-06-27T23:44:45Z,2020-09-03T21:21:47Z,rustdoc: do not use plain summary for trait impls,euclio,62dad457bc73804891c6ac9a31f90de19cbb59a3,12,Auto merge of #73819 - euclio:rustdoc-summaries r=jyn514 GuillaumeGomez rustdoc: do not use plain summary for trait impls Fixes #38386. Fixes #48332. Fixes #49430. Fixes #62741. Fixes #73474. Unfortunately this is not quite ready to go because the newly-working links trigger a bunch of linkcheck failures. The failures are tough to fix because the links are resolved relative to the implementor which could be anywhere in the module hierarchy. (In the current docs these links end up rendering as uninterpreted markdown syntax so I don't think these failures are any worse than the status quo. It might be acceptable to just add them to the linkchecker whitelist.) Ideally this could be fixed with intra-doc links ~~but it isn't working for me: I am currently investigating if it's possible to solve it this way.~~ Opened #73829. EDIT: This is now ready!,THUMBS_UP,2020-09-04T01:19:19Z,tesuji,NA https://github.com/rust-lang/rust/pull/73821,CLOSED,2020-06-27T23:52:17Z,2020-06-28T01:21:05Z,Rollup of 7 pull requests,Dylan-DPC-zz,NA,NA,NA,HOORAY,2020-06-27T23:54:07Z,tema3210,NA https://github.com/rust-lang/rust/pull/73828,MERGED,2020-06-28T05:10:27Z,2020-07-01T18:54:30Z,Fix wording for anonymous parameter name help,nop,db900d4ef35ac185811d5694b08b86cbc8412bea,7,"Rollup merge of #73828 - nop:fix/parameter-name-help r=estebank Fix wording for anonymous parameter name help ``` --> exercises/functions/functions2.rs:8:15 | 8 | fn call_me(num) { | ^ expected one of `:` `@` or `|` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) help: if this is a `self` type give it a parameter name | 8 | fn call_me(self: num) { | ^^^^^^^^^ help: if this was a parameter name give it a type | 8 | fn call_me(num: TypeName) { | ^^^^^^^^^^^^^ help: if this is a type explicitly ignore the parameter name | 8 | fn call_me(_: num) { | ``` This commit changes ""if this was a parameter name"" to ""if this is a parameter name"" to match the wording of similar errors.",HEART,2020-06-29T06:41:48Z,estebank,NA https://github.com/rust-lang/rust/pull/73841,MERGED,2020-06-28T16:44:24Z,2020-07-02T12:35:33Z,Remove defunct `-Z print-region-graph`,tmiasko,e04070a351f83c6ef89be5344dbcfdee2bfe7180,2,Rollup merge of #73841 - tmiasko:print-region-graph r=Mark-Simulacrum Remove defunct `-Z print-region-graph`,HEART,2020-06-28T20:58:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/73851,MERGED,2020-06-28T22:09:25Z,2020-08-15T03:02:00Z,Remove most specialization use in serialization,matthewjasper,668a34e0f438d4a950b9440239656d6755ad963c,137,Auto merge of #73851 - matthewjasper:serialize-not-special r=oli-obk Remove most specialization use in serialization Switching from specialization to min_specialization in the compiler made the unsoundness of how we used these traits pretty clear. This changes how the `Encodable` and `Decodable` traits work to be more friendly for types need a `TyCtxt` to deserialize. The alternative design of having both `Encodable` and `TyEncodable` traits was considered but doesn't really work because the following impls would conflict: ``` impl TyEncodable for Encodable impl TyEncodable for [E] ``` ## How-to guide - `Rustc(De|En)codable` is now spelled `Ty(De|En)coable` in `rustc_middle` `Metadata(En|De)codable` in `rustc_metadata` where needed and `(De|En)codable` everywhere else. - Manual implementations of `(De|En)codable` shouldn't be much different. - If you're adding a new interned type that needs to be en/decodable then the simplest thing way to handle this is: - Have the type be a wrapper around a reference to the interned data (i.e. do what `ty::Predicate` does and not what all of the other interned types do) - Derive `Ty(En|De)codable` on the inner type - Implement `Encodable` by forwarding to the inner type. - Implement `Decodable` by decoding the inner type and then creating the wrapper around that (using the `tcx` from the decoder as needed). cc @rust-lang/compiler for opinions on this change r? @oli-obk,HOORAY,2020-06-28T22:14:23Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/73851,MERGED,2020-06-28T22:09:25Z,2020-08-15T03:02:00Z,Remove most specialization use in serialization,matthewjasper,668a34e0f438d4a950b9440239656d6755ad963c,137,Auto merge of #73851 - matthewjasper:serialize-not-special r=oli-obk Remove most specialization use in serialization Switching from specialization to min_specialization in the compiler made the unsoundness of how we used these traits pretty clear. This changes how the `Encodable` and `Decodable` traits work to be more friendly for types need a `TyCtxt` to deserialize. The alternative design of having both `Encodable` and `TyEncodable` traits was considered but doesn't really work because the following impls would conflict: ``` impl TyEncodable for Encodable impl TyEncodable for [E] ``` ## How-to guide - `Rustc(De|En)codable` is now spelled `Ty(De|En)coable` in `rustc_middle` `Metadata(En|De)codable` in `rustc_metadata` where needed and `(De|En)codable` everywhere else. - Manual implementations of `(De|En)codable` shouldn't be much different. - If you're adding a new interned type that needs to be en/decodable then the simplest thing way to handle this is: - Have the type be a wrapper around a reference to the interned data (i.e. do what `ty::Predicate` does and not what all of the other interned types do) - Derive `Ty(En|De)codable` on the inner type - Implement `Encodable` by forwarding to the inner type. - Implement `Decodable` by decoding the inner type and then creating the wrapper around that (using the `tcx` from the decoder as needed). cc @rust-lang/compiler for opinions on this change r? @oli-obk,HOORAY,2020-06-29T23:22:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73857,CLOSED,2020-06-29T01:30:49Z,2020-07-10T06:50:29Z,Add comparison functions that return both the min and the max value,timvermeulen,NA,NA,NA,THUMBS_UP,2020-06-30T10:18:23Z,mcarton,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T11:02:51Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T11:47:11Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T13:19:23Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T14:05:33Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T14:15:22Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T16:21:24Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T21:34:48Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,HOORAY,2020-06-29T23:20:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-29T23:28:51Z,est31,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-30T00:12:21Z,rrbutani,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,HOORAY,2020-06-30T00:12:22Z,rrbutani,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,LAUGH,2020-06-30T07:25:23Z,oli-obk,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-06-30T07:25:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-03T02:33:40Z,HalidOdat,halidodat@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-17T13:34:28Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-17T14:42:22Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-22T20:52:37Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-23T15:37:01Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-27T15:31:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,HOORAY,2020-07-27T23:22:15Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-07-30T09:59:59Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-10-08T14:47:00Z,bertptrs,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,LAUGH,2020-10-08T15:28:57Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,HOORAY,2020-10-08T15:28:58Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-10-09T06:59:16Z,libkluid,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-10-09T08:09:31Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/73858,MERGED,2020-06-29T07:33:22Z,2020-07-27T18:13:41Z,Make more primitive integer methods const,tspiteri,7864c3f5fa709b854aeee4c45fd00f834ed75449,8,Rollup merge of #73858 - tspiteri:const-methods r=oli-obk Make more primitive integer methods const Now that #72437 has been merged and `const_if_match` is stable these methods can be stabilized const. The methods are grouped in commits according to feature names: * `const_nonzero_int_methods` - `NonZero*::new` * some `const_checked_int_methods` - `{i* u*}::checked_add` - `{i* u*}::checked_sub` - `{i* u*}::checked_mul` - `{i* u*}::checked_neg` - `{i* u*}::checked_shl` - `{i* u*}::checked_shr` - `i*::checked_abs` * `const_saturating_int_methods` - `{i* u*}::saturating_add` - `{i* u*}::saturating_sub` - `{i* u*}::saturating_mul` - `i*::saturating_neg` - `i*::saturating_abs` * `const_int_sign` - `i*::signum` * `const_ascii_ctype_on_intrinsics` - `{char u8}::is_ascii_alphabetic` - `{char u8}::is_ascii_uppercase` - `{char u8}::is_ascii_lowercase` - `{char u8}::is_ascii_alphanumeric` - `{char u8}::is_ascii_digit` - `{char u8}::is_ascii_hexdigit` - `{char u8}::is_ascii_punctuation` - `{char u8}::is_ascii_graphic` - `{char u8}::is_ascii_whitespace` - `{char u8}::is_ascii_control`,THUMBS_UP,2020-10-11T18:47:55Z,lukechu10,NA https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-06-29T15:10:53Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-06-29T16:27:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-06-29T16:54:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-06-29T23:16:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-06-29T23:38:18Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-07-01T18:13:46Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-07-08T20:16:11Z,GrayJack,NA https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-07-08T21:28:40Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-07-11T21:44:33Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,THUMBS_UP,2020-07-11T22:22:36Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/73862,MERGED,2020-06-29T15:07:05Z,2020-07-11T10:25:45Z,Stabilize casts and coercions to `&[T]` in const fn,oli-obk,f4f969027c6378264be509ba5ae512e35258f2e5,7,Rollup merge of #73862 - oli-obk:const_array_to_slice r=RalfJung Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`) while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger possibly longer. r? @rust-lang/lang,HEART,2020-08-25T07:15:37Z,iago-lito,NA https://github.com/rust-lang/rust/pull/73863,MERGED,2020-06-29T15:21:18Z,2020-07-01T14:27:45Z,"Revert ""ci: allow gating gha on everything but macOS""",pietroalbini,1505c1239554fd8c9a5f7a6f4823c7384a0c29e3,2,"Auto merge of #73863 - pietroalbini:revert-8bc3122311d r=Mark-Simulacrum Revert ""ci: allow gating gha on everything but macOS"" The macOS issue on GHA's side seems to be fixed so this is not needed anymore. r? @Mark-Simulacrum",HOORAY,2020-06-29T22:22:24Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/73868,MERGED,2020-06-29T18:17:16Z,2020-07-23T02:58:57Z,Advertise correct stable version for const control flow,ecstatic-morse,da449a9c1b018c5f57ce324c6fe02366bf3a868b,1,Rollup merge of #73868 - ecstatic-morse:fix-stable-version r=jonas-schievink Advertise correct stable version for const control flow #72437 was opened before the 1.45 release but merged afterwards. These will be stable in 1.46.,THUMBS_UP,2020-06-29T23:17:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73882,MERGED,2020-06-30T04:44:08Z,2020-07-03T07:09:50Z,Avoid `unwrap_or_else` in `RawVec::allocate_in`.,nnethercote,cd1a46d644791c79433db934ad4e6131c577efcc,1,Auto merge of #73882 - nnethercote:avoid-unwrap_or_else-in-allocate_in r=Amanieu Avoid `unwrap_or_else` in `RawVec::allocate_in`. This reduces the amount of LLVM IR generated by up to 1 or 2%. r? @Amanieu,THUMBS_UP,2020-07-01T17:50:45Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73883,MERGED,2020-06-30T05:41:04Z,2020-07-02T16:33:12Z,Compile rustdoc less often.,ehuss,7b2f44a57b6814c250373bf19fb71e5e733e8044,4,"Rollup merge of #73883 - ehuss:rustdoc-stage-previous r=Mark-Simulacrum Compile rustdoc less often. Previously rustdoc was built 3 times with `x.py test`: 1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1). 3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools). This PR removes the majority of number 3 where it will instead use the stage1 compiler which will share the artifacts from number 1. This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2. At `-j2` the last build step goes from about 300s to 70s on my machine. It's not a huge win but shaving 4 minutes isn't bad. The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history) and compiletests use the top stage very intentionally. Unfortunately the linkchecker builds all docs at stage2 (stage2-tools) which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc` there doesn't seem to be any control over the stages). --- For `x.py doc` rustdoc was previously built three times (with compiler-docs): 1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for compiler-docs 3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools) This PR combines these so that they consistently use the ""top stage"" rustdoc. I don't know why the compiler-docs was written to use stage minus one but it seems better to be consistent across the doc steps. --- I've tried to test this with a variety of commands (`x.py doc` `x.py test` different `--stage` flags `full-bootstrap` setting `--target` etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables and this stuff is difficult for me to fully understand. Closes #70799 (I think)",HEART,2020-06-30T15:00:54Z,mati865,NA https://github.com/rust-lang/rust/pull/73883,MERGED,2020-06-30T05:41:04Z,2020-07-02T16:33:12Z,Compile rustdoc less often.,ehuss,7b2f44a57b6814c250373bf19fb71e5e733e8044,4,"Rollup merge of #73883 - ehuss:rustdoc-stage-previous r=Mark-Simulacrum Compile rustdoc less often. Previously rustdoc was built 3 times with `x.py test`: 1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1). 3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools). This PR removes the majority of number 3 where it will instead use the stage1 compiler which will share the artifacts from number 1. This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2. At `-j2` the last build step goes from about 300s to 70s on my machine. It's not a huge win but shaving 4 minutes isn't bad. The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history) and compiletests use the top stage very intentionally. Unfortunately the linkchecker builds all docs at stage2 (stage2-tools) which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc` there doesn't seem to be any control over the stages). --- For `x.py doc` rustdoc was previously built three times (with compiler-docs): 1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2). 2. stage1 (using stage0 compiler) for compiler-docs 3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools) This PR combines these so that they consistently use the ""top stage"" rustdoc. I don't know why the compiler-docs was written to use stage minus one but it seems better to be consistent across the doc steps. --- I've tried to test this with a variety of commands (`x.py doc` `x.py test` different `--stage` flags `full-bootstrap` setting `--target` etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables and this stuff is difficult for me to fully understand. Closes #70799 (I think)",HEART,2020-06-30T15:48:17Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/73887,MERGED,2020-06-30T08:56:25Z,2020-07-11T10:25:43Z,stabilize const mem::forget,DutchGhost,efda2b58b095306d068a3a165de62acd1e94911b,3,Rollup merge of #73887 - DutchGhost:master r=oli-obk stabilize const mem::forget Stabilizes const `mem::forget` as implemented in https://github.com/rust-lang/rust/pull/69617 and tracked in https://github.com/rust-lang/rust/issues/69616. Closes https://github.com/rust-lang/rust/issues/69616,THUMBS_UP,2020-07-17T01:27:12Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/73887,MERGED,2020-06-30T08:56:25Z,2020-07-11T10:25:43Z,stabilize const mem::forget,DutchGhost,efda2b58b095306d068a3a165de62acd1e94911b,3,Rollup merge of #73887 - DutchGhost:master r=oli-obk stabilize const mem::forget Stabilizes const `mem::forget` as implemented in https://github.com/rust-lang/rust/pull/69617 and tracked in https://github.com/rust-lang/rust/issues/69616. Closes https://github.com/rust-lang/rust/issues/69616,HEART,2020-08-27T16:33:13Z,cristaloleg,oleg@hey.com https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-06-30T20:48:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,ROCKET,2020-06-30T20:48:15Z,anp,lol@anp.lol https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-06-30T22:02:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-07-01T05:52:05Z,oli-obk,NA https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-07-01T07:50:08Z,mati865,NA https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-07-01T11:09:56Z,est31,NA https://github.com/rust-lang/rust/pull/73902,CLOSED,2020-06-30T20:44:32Z,2021-03-10T17:16:22Z,[WIP] Bring rust-semverver in-tree and test that it builds.,eddyb,NA,NA,NA,HOORAY,2020-07-01T13:26:56Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73903,CLOSED,2020-06-30T21:24:20Z,2020-07-02T14:25:41Z,Changes required for rustc/cargo to build for iOS targets,Absolucy,NA,NA,NA,THUMBS_UP,2020-07-02T01:39:38Z,yerke,NA https://github.com/rust-lang/rust/pull/73903,CLOSED,2020-06-30T21:24:20Z,2020-07-02T14:25:41Z,Changes required for rustc/cargo to build for iOS targets,Absolucy,NA,NA,NA,HOORAY,2020-07-02T01:39:41Z,yerke,NA https://github.com/rust-lang/rust/pull/73903,CLOSED,2020-06-30T21:24:20Z,2020-07-02T14:25:41Z,Changes required for rustc/cargo to build for iOS targets,Absolucy,NA,NA,NA,HOORAY,2020-07-02T05:26:49Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/73903,CLOSED,2020-06-30T21:24:20Z,2020-07-02T14:25:41Z,Changes required for rustc/cargo to build for iOS targets,Absolucy,NA,NA,NA,THUMBS_UP,2020-07-02T05:26:50Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-01T01:04:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-01T22:55:45Z,marmeladema,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-02T03:33:45Z,cynecx,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-03T09:15:07Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-04T11:45:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-04T14:43:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-07T21:04:10Z,estebank,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-07-28T19:25:23Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-08-07T23:06:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-08-08T00:03:40Z,kettle11,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-13T16:28:26Z,tamird,tamird@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-19T02:52:18Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-23T01:23:00Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-23T06:42:00Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-27T02:02:53Z,ishitatsuyuki,ishitatsuyuki@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-27T13:07:17Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-29T00:52:19Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-09-29T19:30:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-06T15:10:48Z,novacrazy,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T02:33:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T05:56:30Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T07:01:53Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T07:48:13Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T10:27:00Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T13:51:51Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T14:38:15Z,nikitavoloboev,mail@nikiv.dev https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T15:44:58Z,jspencer,jason@typi.ca https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T17:32:08Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T21:03:31Z,nnethercote,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-07T21:38:12Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-15T16:47:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-10-20T12:15:44Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2020-12-03T19:07:46Z,keithmss,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2021-01-30T11:11:36Z,bluss,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2021-02-04T10:48:14Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2021-08-04T10:08:04Z,fwcd,NA https://github.com/rust-lang/rust/pull/73905,MERGED,2020-06-30T21:58:22Z,2020-10-06T14:53:40Z,Separate projection bounds and predicates,matthewjasper,08e2d4616613716362b4b49980ff303f2b9ae654,259,Auto merge of #73905 - matthewjasper:projection-bounds-2 r=nikomatsakis Separate projection bounds and predicates Follow up to #72788. - Rename `projection_predicates` to `item_bounds` - Separate bounds on associated types (the things after the `:` in `type X: ...`) and opaque types (the things after `impl`) from predicates. - Projection candidates now have the correct nested obligations - Trait object candidates now check that the associated types on the trait object satisfy their bounds as nested obligations - Type alias impl trait types are now checked (#73035) - `feature(generic_associated_types)` no longer changes how we handle bounds (#73816) Opening for a perf and crater runs. r? `@nikomatsakis`,HEART,2021-08-06T14:00:47Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/73906,MERGED,2020-07-01T00:36:39Z,2020-07-02T12:35:18Z,Add missing backtick in `ty_error_with_message`,JohnTitor,9046f230fde97f5538971ee56c00dea5511822c5,1,Rollup merge of #73906 - JohnTitor:missing-bt r=jonas-schievink Add missing backtick in `ty_error_with_message`,HEART,2020-07-01T01:50:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73925,MERGED,2020-07-01T15:03:12Z,2020-07-04T04:54:46Z,Improve comments from #72617 as suggested by RalfJung,eduardosm,9d0ca3806ff5a3faee2299b6a1a2248d180aae4e,1,Rollup merge of #73925 - eduardosm:improve-pr72617-comments r=RalfJung Improve comments from #72617 as suggested by RalfJung r? @RalfJung,HEART,2020-07-02T06:53:47Z,RalfJung,NA https://github.com/rust-lang/rust/pull/73943,MERGED,2020-07-01T21:15:19Z,2020-08-15T00:46:29Z,Document the unsafe keyword,poliorcetics,f163ec5b18209bf8b58d3dbe6e9b48cfb07e8390,1,Rollup merge of #73943 - poliorcetics:unsafe-keyword r=steveklabnik Document the unsafe keyword Partial fix of #34601 (just one more and it will be done 😄). I tried to be concise and redirect as much as possible on other longer resources exposing only the strict necessary. I also used `SAFETY:` comments to promote good documentation. I would like a thorough review to ensure I did not introduce mistakes that would confuse people or worse lead them to write unsound code. @rustbot modify labels: T-doc C-enhancement Edit: this is now the last PR for the original issue: fixes #34601.,THUMBS_UP,2020-07-19T11:45:44Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/73945,MERGED,2020-07-02T01:14:14Z,2021-04-04T20:10:59Z,Add an unstable --json=unused-externs flag to print unused externs,est31,a1c34493d4d733fedf2a8609d7426a425eb7cf84,9,"Rollup merge of #73945 - est31:unused_externs r=Mark-Simulacrum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: https://github.com/rust-lang/cargo/pull/8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: #57274 #72342 #72603 The feature builds upon the internal datastructures added by #72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled rustc will print json messages like: ``` {""unused_extern_names"":[""byteorder"" ""openssl"" ""webpki""]} ``` For a crate that got passed byteorder openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the ""n warnings emitted"" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example it would be hard for rustc to emit warnings like ""dependency foo is only used by dev targets"" suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always even if no warning or error is emitted. At that point even this tiny difference in ""noise"" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta` but rustc will only ever use one of those paths. Also paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement but that's not its job. For detecting unused `extern crate foo` statements there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc ```@jsgf``` ```@ehuss``` ```@petrochenkov``` ```@estebank```",THUMBS_UP,2020-07-02T02:35:39Z,jsgf,jeremy@goop.org https://github.com/rust-lang/rust/pull/73945,MERGED,2020-07-02T01:14:14Z,2021-04-04T20:10:59Z,Add an unstable --json=unused-externs flag to print unused externs,est31,a1c34493d4d733fedf2a8609d7426a425eb7cf84,9,"Rollup merge of #73945 - est31:unused_externs r=Mark-Simulacrum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: https://github.com/rust-lang/cargo/pull/8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: #57274 #72342 #72603 The feature builds upon the internal datastructures added by #72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled rustc will print json messages like: ``` {""unused_extern_names"":[""byteorder"" ""openssl"" ""webpki""]} ``` For a crate that got passed byteorder openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the ""n warnings emitted"" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example it would be hard for rustc to emit warnings like ""dependency foo is only used by dev targets"" suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always even if no warning or error is emitted. At that point even this tiny difference in ""noise"" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta` but rustc will only ever use one of those paths. Also paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement but that's not its job. For detecting unused `extern crate foo` statements there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc ```@jsgf``` ```@ehuss``` ```@petrochenkov``` ```@estebank```",THUMBS_UP,2020-08-30T11:08:46Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/73945,MERGED,2020-07-02T01:14:14Z,2021-04-04T20:10:59Z,Add an unstable --json=unused-externs flag to print unused externs,est31,a1c34493d4d733fedf2a8609d7426a425eb7cf84,9,"Rollup merge of #73945 - est31:unused_externs r=Mark-Simulacrum Add an unstable --json=unused-externs flag to print unused externs This adds an unstable flag to print a list of the extern names not used by cargo. This PR will enable cargo to collect unused dependencies from all units and provide warnings. The companion PR to cargo is: https://github.com/rust-lang/cargo/pull/8437 The goal is eventual stabilization of this flag in rustc as well as in cargo. Discussion of this feature is mostly contained inside these threads: #57274 #72342 #72603 The feature builds upon the internal datastructures added by #72342 Externs are uniquely identified by name and the information is sufficient for cargo. If the mode is enabled rustc will print json messages like: ``` {""unused_extern_names"":[""byteorder"" ""openssl"" ""webpki""]} ``` For a crate that got passed byteorder openssl and webpki dependencies but needed none of them. ### Q: Why not pass -Wunused-crate-dependencies? A: See [ehuss's comment here](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) TLDR: it's cleaner. Rust's warning system wasn't built to be filtered or edited by cargo. Even a basic implementation of the feature would have to change the ""n warnings emitted"" line that rustc prints at the end. Cargo ideally wants to synthesize its own warnings anyways. For example it would be hard for rustc to emit warnings like ""dependency foo is only used by dev targets"" suggesting to make it a dev-dependency instead. ### Q: Make rustc emit used or unused externs? A: Emitting used externs has the advantage that it simplifies cargo's collection job. However emitting unused externs creates less data to be communicated between rustc and cargo. Often you want to paste a cargo command obtained from `cargo build -vv` for doing something completely unrelated. The message is emitted always even if no warning or error is emitted. At that point even this tiny difference in ""noise"" matters. That's why I went with emitting unused externs. ### Q: One json msg per extern or a collective json msg? A: Same as above the data format should be concise. Having 30 lines for the 30 crates a crate uses would be disturbing to readers. Also it helps the cargo implementation to know that there aren't more unused deps coming. ### Q: Why use names of externs instead of e.g. paths? A: Names are both sufficient as well as neccessary to uniquely identify a passed `--extern` arg. Names are sufficient because you *must* pass a name when passing an `--extern` arg. Passing a path is optional on the other hand so rustc might also figure out a crate's location from the file system. You can also put multiple paths for the same extern name via e.g. `--extern hello=/usr/lib/hello.rmeta --extern hello=/usr/local/lib/hello.rmeta` but rustc will only ever use one of those paths. Also paths don't identify a dependency uniquely as it is possible to have multiple different extern names point to the same path. So paths are ill-suited for identification. ### Q: What about 2015 edition crates? A: They are fully supported. Even on the 2015 edition an explicit `--extern` flag is is required to enable `extern crate foo;` to work (outside of sysroot crates which this flag doesn't warn about anyways). So the lint would still fire on 2015 edition crates if you haven't included a dependency specified in Cargo.toml using `extern crate foo;` or similar. The lint won't fire if your sole use in the crate is through a `extern crate foo;` statement but that's not its job. For detecting unused `extern crate foo` statements there is the `unused_extern_crates` lint which can be enabled by `#![warn(unused_extern_crates)]` or similar. cc ```@jsgf``` ```@ehuss``` ```@petrochenkov``` ```@estebank```",HEART,2020-11-17T03:14:14Z,camelid,NA https://github.com/rust-lang/rust/pull/73949,MERGED,2020-07-02T02:59:03Z,2020-07-04T04:54:43Z,[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass,wesleywiser,60cad20b41d93c94c247cd32873e5c176effc7d2,12,Rollup merge of #73949 - wesleywiser:simplify_try_fixes r=oli-obk [mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass This does not yet attempt re-enabling the pass but it does resolve a number of issues with the pass. r? @oli-obk I believe this closes #73223.,HEART,2020-07-02T03:01:47Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73949,MERGED,2020-07-02T02:59:03Z,2020-07-04T04:54:43Z,[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass,wesleywiser,60cad20b41d93c94c247cd32873e5c176effc7d2,12,Rollup merge of #73949 - wesleywiser:simplify_try_fixes r=oli-obk [mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass This does not yet attempt re-enabling the pass but it does resolve a number of issues with the pass. r? @oli-obk I believe this closes #73223.,HEART,2020-07-02T07:26:56Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/73949,MERGED,2020-07-02T02:59:03Z,2020-07-04T04:54:43Z,[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass,wesleywiser,60cad20b41d93c94c247cd32873e5c176effc7d2,12,Rollup merge of #73949 - wesleywiser:simplify_try_fixes r=oli-obk [mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass This does not yet attempt re-enabling the pass but it does resolve a number of issues with the pass. r? @oli-obk I believe this closes #73223.,HEART,2020-07-03T11:31:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/73953,MERGED,2020-07-02T06:40:16Z,2020-07-07T05:04:21Z,Audit hidden/short code suggestions,JohnTitor,e74ab50d07a8b21e8d03ebfb0da8dae6583b1e67,153,Rollup merge of #73953 - JohnTitor:audit-hidden-sugg r=estebank Audit hidden/short code suggestions Should fix #73641. Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes. r? @estebank,HEART,2020-07-04T05:19:45Z,estebank,NA https://github.com/rust-lang/rust/pull/73964,MERGED,2020-07-02T13:14:25Z,2020-07-28T17:08:08Z,Improve defaults in x.py,jyn514,7b3a7819371cef92a187e9bac8f7810ccde15216,31,Auto merge of #73964 - jyn514:sane-defaults r=Mark-Simulacrum Improve defaults in x.py - Make the default stage dependent on the subcommand - Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want use x.py build --stage 2 instead which gives you a working libstd. - Change default debuginfo when debug = true from 2 to 1 I tried to fix CI to use `--stage 2` everywhere it currently has no stage but I might have missed a spot. This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR. See individual commits for a detailed rationale of each change. See also the MCP: https://github.com/rust-lang/compiler-team/issues/326 r? @Mark-Simulacrum but anyone is free to give an opinion.,EYES,2020-07-02T15:31:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73964,MERGED,2020-07-02T13:14:25Z,2020-07-28T17:08:08Z,Improve defaults in x.py,jyn514,7b3a7819371cef92a187e9bac8f7810ccde15216,31,Auto merge of #73964 - jyn514:sane-defaults r=Mark-Simulacrum Improve defaults in x.py - Make the default stage dependent on the subcommand - Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want use x.py build --stage 2 instead which gives you a working libstd. - Change default debuginfo when debug = true from 2 to 1 I tried to fix CI to use `--stage 2` everywhere it currently has no stage but I might have missed a spot. This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR. See individual commits for a detailed rationale of each change. See also the MCP: https://github.com/rust-lang/compiler-team/issues/326 r? @Mark-Simulacrum but anyone is free to give an opinion.,EYES,2020-07-02T15:55:19Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/73964,MERGED,2020-07-02T13:14:25Z,2020-07-28T17:08:08Z,Improve defaults in x.py,jyn514,7b3a7819371cef92a187e9bac8f7810ccde15216,31,Auto merge of #73964 - jyn514:sane-defaults r=Mark-Simulacrum Improve defaults in x.py - Make the default stage dependent on the subcommand - Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want use x.py build --stage 2 instead which gives you a working libstd. - Change default debuginfo when debug = true from 2 to 1 I tried to fix CI to use `--stage 2` everywhere it currently has no stage but I might have missed a spot. This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR. See individual commits for a detailed rationale of each change. See also the MCP: https://github.com/rust-lang/compiler-team/issues/326 r? @Mark-Simulacrum but anyone is free to give an opinion.,THUMBS_UP,2020-07-21T05:21:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/73964,MERGED,2020-07-02T13:14:25Z,2020-07-28T17:08:08Z,Improve defaults in x.py,jyn514,7b3a7819371cef92a187e9bac8f7810ccde15216,31,Auto merge of #73964 - jyn514:sane-defaults r=Mark-Simulacrum Improve defaults in x.py - Make the default stage dependent on the subcommand - Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want use x.py build --stage 2 instead which gives you a working libstd. - Change default debuginfo when debug = true from 2 to 1 I tried to fix CI to use `--stage 2` everywhere it currently has no stage but I might have missed a spot. This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR. See individual commits for a detailed rationale of each change. See also the MCP: https://github.com/rust-lang/compiler-team/issues/326 r? @Mark-Simulacrum but anyone is free to give an opinion.,THUMBS_UP,2020-07-26T05:35:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73964,MERGED,2020-07-02T13:14:25Z,2020-07-28T17:08:08Z,Improve defaults in x.py,jyn514,7b3a7819371cef92a187e9bac8f7810ccde15216,31,Auto merge of #73964 - jyn514:sane-defaults r=Mark-Simulacrum Improve defaults in x.py - Make the default stage dependent on the subcommand - Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want use x.py build --stage 2 instead which gives you a working libstd. - Change default debuginfo when debug = true from 2 to 1 I tried to fix CI to use `--stage 2` everywhere it currently has no stage but I might have missed a spot. This does not update much of the documentation - most of it is in https://github.com/rust-lang/rustc-dev-guide/ or https://github.com/rust-lang/rust-forge and will need a separate PR. See individual commits for a detailed rationale of each change. See also the MCP: https://github.com/rust-lang/compiler-team/issues/326 r? @Mark-Simulacrum but anyone is free to give an opinion.,THUMBS_UP,2020-10-09T11:00:46Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/73968,CLOSED,2020-07-02T15:11:02Z,2020-07-04T17:49:18Z,Improve `assert_eq` message,a1phyr,NA,NA,NA,THUMBS_UP,2020-07-03T20:06:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73968,CLOSED,2020-07-02T15:11:02Z,2020-07-04T17:49:18Z,Improve `assert_eq` message,a1phyr,NA,NA,NA,CONFUSED,2020-07-03T22:14:22Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/73978,MERGED,2020-07-03T01:03:52Z,2020-07-07T00:56:57Z,Shrink ParamEnv to 16 bytes,Mark-Simulacrum,8981dbbc36f1575b0a417b6849767bde29e7c6b4,24,Auto merge of #73978 - Mark-Simulacrum:shrink-paramenv r=nnethercote Shrink ParamEnv to 16 bytes r? @nnethercote x.py check passes but I haven't tried running perf or tests,HEART,2020-07-15T01:06:17Z,estebank,NA https://github.com/rust-lang/rust/pull/73978,MERGED,2020-07-03T01:03:52Z,2020-07-07T00:56:57Z,Shrink ParamEnv to 16 bytes,Mark-Simulacrum,8981dbbc36f1575b0a417b6849767bde29e7c6b4,24,Auto merge of #73978 - Mark-Simulacrum:shrink-paramenv r=nnethercote Shrink ParamEnv to 16 bytes r? @nnethercote x.py check passes but I haven't tried running perf or tests,HEART,2020-07-16T14:24:29Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73983,CLOSED,2020-07-03T07:13:01Z,2020-08-23T23:45:07Z,Eliminate `ObligationCauseData`.,nnethercote,NA,NA,NA,HEART,2020-07-03T08:13:08Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/73985,MERGED,2020-07-03T09:45:23Z,2020-07-04T04:54:36Z,"Fix ""getting started"" link",e00E,e4c505b8792dc5593f37e23e2fb145d99b2a8619,2,"Rollup merge of #73985 - e00E:fix-getting-started-link r=jonas-schievink Fix ""getting started"" link The previous link is 404.",HEART,2020-07-03T20:02:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73989,MERGED,2020-07-03T11:24:27Z,2020-07-11T10:25:35Z,adjust ub-enum test to be endianess-independent,RalfJung,ef3dc09fa7078d36ea5831ee9a3eb5c335cdb2f3,2,"Rollup merge of #73989 - RalfJung:ub-enum-test r=oli-obk adjust ub-enum test to be endianess-independent @cuviper noted that our test fails on ""other"" endianess systems (I never know which is which^^) so let's fix that.",HEART,2020-07-03T16:10:22Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-03T15:13:57Z,estebank,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-03T15:28:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-03T20:00:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-06T07:49:25Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-09T21:22:17Z,aturon,aturon@fastly.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-09T21:34:19Z,acfoltzer,acfoltzer@acfoltzer.net https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-10T11:18:43Z,varkor,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-10T17:43:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-12T02:03:43Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-13T08:35:50Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-13T09:06:05Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-13T21:30:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-13T23:11:11Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-14T23:47:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-16T08:34:23Z,iago-lito,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-22T18:06:32Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-24T15:43:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-07-25T09:14:55Z,Agrailag,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-07-25T21:50:51Z,lights0123,developer@lights0123.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-07-29T19:29:26Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-08-03T12:24:45Z,jplatte,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-01T22:39:23Z,darksv,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-01T22:39:23Z,darksv,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-01T22:42:52Z,DianaNites,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-01T22:53:51Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-02T03:23:57Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-02T05:27:36Z,LiHRaM,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-02T08:48:24Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-02T10:35:01Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-02T12:19:01Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-02T19:58:37Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-02T21:49:09Z,havk64,alexandro.oliveira@holbertonschool.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-04T15:45:22Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-04T15:51:37Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-04T18:20:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-04T20:05:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-04T20:05:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-04T21:33:35Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-09-04T21:33:37Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-04T21:33:38Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-09-04T22:09:10Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-05T08:08:44Z,Erutuon,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-05T08:39:04Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-05T18:12:58Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2020-09-06T14:16:59Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-09-06T14:17:00Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-06T14:17:02Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-06T16:11:59Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-07T20:44:04Z,harrier-lcc,mmu20046f03@yahoo.com.hk https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-11T11:23:24Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-17T06:34:30Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-09-18T15:20:53Z,lnicola,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-18T15:44:42Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-22T13:04:36Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-22T13:16:00Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-09-22T13:43:24Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-22T13:43:25Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2020-09-30T07:28:40Z,henild,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2020-12-04T12:57:56Z,najamelan,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2021-01-09T03:44:06Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2021-02-21T21:12:34Z,camelid,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2021-02-21T21:12:35Z,camelid,NA https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2021-04-26T13:21:57Z,DesmondWillowbrook,sendtokartavya@gmail.com https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HOORAY,2022-02-06T23:55:07Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,HEART,2022-02-06T23:55:10Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/73996,MERGED,2020-07-03T14:52:01Z,2020-09-04T01:32:26Z,diagnostics: shorten paths of unique symbols,da-x,af3c6e733a40e671550e0f0f5aeecaa13772ba56,1316,Auto merge of #73996 - da-x:short-unique-paths r=petrochenkov diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for #50310 and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in #21934 that an RFC for this is not needed and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions it's rather simple logic and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place and as long as it was not glob-imported anywhere in the current crate we can trim its printed path to the last component. This has wide implications on error messages with types for example shortening `std::vec::Vec` to just `Vec` as long as there is no other `Vec` importable from anywhere.,THUMBS_UP,2022-02-06T23:55:11Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/74005,MERGED,2020-07-03T17:46:15Z,2020-08-11T01:39:34Z,Clean up errors in typeck and resolve,estebank,3bb5a863c8d60029abce0d56c5c303b5097b6070,26,Auto merge of #74005 - estebank:type-ascription-redux r=petrochenkov Clean up errors in typeck and resolve * Tweak ordering of suggestions * Do not suggest similarly named enclosing item * Point at item definition in foreign crates * Add missing primary label CC #34255.,HEART,2020-07-03T19:58:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74009,MERGED,2020-07-03T19:09:53Z,2020-07-18T00:28:26Z,Fix MinGW `run-make-fulldeps` tests,mati865,be3b972820c1e4793f246746d815eeea5e736dc9,11,Rollup merge of #74009 - mati865:mingw-tests-implib r=nikomatsakis Fix MinGW `run-make-fulldeps` tests `compiler-rt-works-on-mingw` and `libs-search-path` were not ran because `only-mingw` doesn't match any target. Enabled and verified few ignored tests with `windows-gnu` toolchain. They are still ignored on MSVC since I'm not experienced with this target.,HEART,2020-07-03T19:14:59Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74017,MERGED,2020-07-03T21:59:54Z,2020-07-25T03:38:59Z,Document the where keyword,poliorcetics,c4e173472beb073ce3759525a15ed429b032787a,1,Auto merge of #74017 - poliorcetics:where-keyword r=jyn514 Document the where keyword Partial fix of #34601 (and last PR for it 🎉). This documents the `where` keyword. @rustbot modify labels: T-doc C-enhancement,HOORAY,2020-07-04T06:16:50Z,pierwill,NA https://github.com/rust-lang/rust/pull/74017,MERGED,2020-07-03T21:59:54Z,2020-07-25T03:38:59Z,Document the where keyword,poliorcetics,c4e173472beb073ce3759525a15ed429b032787a,1,Auto merge of #74017 - poliorcetics:where-keyword r=jyn514 Document the where keyword Partial fix of #34601 (and last PR for it 🎉). This documents the `where` keyword. @rustbot modify labels: T-doc C-enhancement,HOORAY,2020-07-09T19:23:41Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74017,MERGED,2020-07-03T21:59:54Z,2020-07-25T03:38:59Z,Document the where keyword,poliorcetics,c4e173472beb073ce3759525a15ed429b032787a,1,Auto merge of #74017 - poliorcetics:where-keyword r=jyn514 Document the where keyword Partial fix of #34601 (and last PR for it 🎉). This documents the `where` keyword. @rustbot modify labels: T-doc C-enhancement,HOORAY,2020-07-23T03:37:07Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74017,MERGED,2020-07-03T21:59:54Z,2020-07-25T03:38:59Z,Document the where keyword,poliorcetics,c4e173472beb073ce3759525a15ed429b032787a,1,Auto merge of #74017 - poliorcetics:where-keyword r=jyn514 Document the where keyword Partial fix of #34601 (and last PR for it 🎉). This documents the `where` keyword. @rustbot modify labels: T-doc C-enhancement,HOORAY,2020-07-23T07:03:34Z,iago-lito,NA https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",ROCKET,2021-03-11T22:20:04Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",ROCKET,2021-03-12T22:19:41Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",ROCKET,2021-04-26T10:38:05Z,everettjf,everettjf@live.com https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",ROCKET,2021-04-26T14:26:55Z,Binlogo,binboy@live.com https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",THUMBS_UP,2021-04-26T14:26:57Z,Binlogo,binboy@live.com https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",ROCKET,2022-03-01T09:38:17Z,JmPotato,github@ipotato.me https://github.com/rust-lang/rust/pull/74024,MERGED,2020-07-04T08:52:31Z,2021-03-05T23:16:10Z,Improve slice.binary_search_by()'s best-case performance to O(1),Folyd,caca2121ffe4cb47d8ea2d9469c493995f57e0b5,3,"Auto merge of #74024 - Folyd:master r=m-ou-se Improve slice.binary_search_by()'s best-case performance to O(1) This PR aimed to improve the [slice.binary_search_by()](https://doc.rust-lang.org/std/primitive.slice.html#method.binary_search_by)'s best-case performance to O(1). # Noticed I don't know why the docs of `binary_search_by` said `""If there are multiple matches then any one of the matches could be returned.""` but the implementation isn't the same thing. Actually it returns the **last one** if multiple matches found. Then we got two options: ## If returns the last one is the correct or desired result Then I can rectify the docs and revert my changes. ## If the docs are correct or desired result Then my changes can be merged after fully reviewed. However if my PR gets merged another issue raised: this could be a **breaking change** since if multiple matches found the returning order no longer the last one instead of it could be any one. For example: ```rust let mut s = vec![0 1 1 1 1 2 3 5 8 13 21 34 55]; let num = 1; let idx = s.binary_search(&num); s.insert(idx 2); // Old implementations assert_eq!(s [0 1 1 1 1 2 2 3 5 8 13 21 34 42 55]); // New implementations assert_eq!(s [0 1 1 1 2 1 2 3 5 8 13 21 34 42 55]); ``` # Benchmarking **Old implementations** ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 4) test slice::binary_search_l1_with_dups ... bench: 59 ns/iter (+/- 3) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 5) test slice::binary_search_l2_with_dups ... bench: 77 ns/iter (+/- 17) test slice::binary_search_l3 ... bench: 183 ns/iter (+/- 23) test slice::binary_search_l3_with_dups ... bench: 185 ns/iter (+/- 19) ``` **New implementations (1)** Implemented by this PR. ```rust if cmp == Equal { return Ok(mid); } else if cmp == Less { base = mid } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 58 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 4) test slice::binary_search_l2 ... bench: 76 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 6) test slice::binary_search_l3 ... bench: 200 ns/iter (+/- 30) test slice::binary_search_l3_with_dups ... bench: 157 ns/iter (+/- 6) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 8) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 2) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l3 ... bench: 198 ns/iter (+/- 21) test slice::binary_search_l3_with_dups ... bench: 158 ns/iter (+/- 11) ``` **New implementations (2)** Suggested by `@nbdd0121` in [comment](https://github.com/rust-lang/rust/pull/74024#issuecomment-665430239). ```rust base = if cmp == Greater { base } else { mid }; if cmp == Equal { break } ``` ```sh $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 59 ns/iter (+/- 7) test slice::binary_search_l1_with_dups ... bench: 37 ns/iter (+/- 5) test slice::binary_search_l2 ... bench: 75 ns/iter (+/- 3) test slice::binary_search_l2_with_dups ... bench: 56 ns/iter (+/- 3) test slice::binary_search_l3 ... bench: 195 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 7) $ ./x.py bench --stage 1 library/libcore test slice::binary_search_l1 ... bench: 57 ns/iter (+/- 2) test slice::binary_search_l1_with_dups ... bench: 38 ns/iter (+/- 2) test slice::binary_search_l2 ... bench: 77 ns/iter (+/- 11) test slice::binary_search_l2_with_dups ... bench: 57 ns/iter (+/- 4) test slice::binary_search_l3 ... bench: 194 ns/iter (+/- 15) test slice::binary_search_l3_with_dups ... bench: 151 ns/iter (+/- 18) ``` I run some benchmarking testings against on two implementations. The new implementation has a lot of improvement in duplicates cases while in `binary_search_l3` case it's a little bit slower than the old one.",THUMBS_DOWN,2022-06-20T15:31:02Z,liningpan,lining.pan@yale.edu https://github.com/rust-lang/rust/pull/74026,CLOSED,2020-07-04T10:56:42Z,2020-07-05T13:20:09Z,remove LengthAtMost32 on AsRef/Borrow impl for array,burrbull,NA,NA,NA,HEART,2020-07-05T03:25:41Z,lain-dono,NA https://github.com/rust-lang/rust/pull/74026,CLOSED,2020-07-04T10:56:42Z,2020-07-05T13:20:09Z,remove LengthAtMost32 on AsRef/Borrow impl for array,burrbull,NA,NA,NA,HEART,2020-07-05T19:18:40Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/74026,CLOSED,2020-07-04T10:56:42Z,2020-07-05T13:20:09Z,remove LengthAtMost32 on AsRef/Borrow impl for array,burrbull,NA,NA,NA,HEART,2020-08-28T01:33:24Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/74027,MERGED,2020-07-04T12:37:57Z,2020-07-06T03:21:44Z,Convert more `DefId`s to `LocalDefId`s,lcnr,a1c076fa7519a69a7eedbc5c6307e2565a76e9be,11,Rollup merge of #74027 - lcnr:ConstCx-local-def-id r=varkor Convert more `DefId`s to `LocalDefId`s,THUMBS_UP,2020-07-04T20:43:16Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-04T16:39:10Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-04T19:06:34Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-04T23:44:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-05T05:04:22Z,est31,NA https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-06T07:25:17Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-09T11:40:09Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-09T13:35:38Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-09T15:45:31Z,pachi,NA https://github.com/rust-lang/rust/pull/74033,MERGED,2020-07-04T14:29:06Z,2020-07-17T03:30:58Z,Add build support for Cargo's build-std feature.,ehuss,5751c7f1db9aced9aae5a1327fcdf67438aad59e,42,"Rollup merge of #74033 - ehuss:std-compile-all-platforms r=Mark-Simulacrum Add build support for Cargo's build-std feature. This makes some changes to the standard library to make it easier to use with Cargo's build-std feature. The primary goal is to make it so that Cargo and its users do not need to know which crates to build and which features to use for every platform. Conditional cfgs are adjusted so that there is usually a fall-through for unsupported platforms. Additionally there is a ""restricted-std"" feature to mark `std` as unstable when used with build-std on no_std platforms. There is no intent to stabilize this feature for the foreseeable future. This borrows some of the implementation for wasm which already does what this needs. More code sharing can be done with some other platforms (there is a lot of duplication with cloudabi hermit and sgx) but I figure that can be done in a future PR. There are some small changes to stable behavior in this PR: - `std::env::consts::ARCH` on asmjs now reports ""wasm32"" to match its actual architecture. - Some of the wasm error messages for unsupported features report a slightly different error message so that the code can be reused. There should otherwise not be any changes to how std is built for distribution via bootstrap. This does not yet support all platforms when used with build-std. - It doesn't work with 16-bit targets (hashbrown does not support that). - It does not work with JSON spec targets. - In particular all target triple snooping will need to be replaced with appropriate target option checking. - Switching to gimli (#73441) will make cross-building *much* easier. - There are still a ton of issues on the Cargo side to resolve. A big one is panic strategy support. Future PRs are intended to address some of these issues.",HEART,2020-07-10T05:46:27Z,dbdr,NA https://github.com/rust-lang/rust/pull/74040,MERGED,2020-07-04T18:39:15Z,2020-09-21T15:07:51Z,fix unification of const variables,lcnr,e0bf356f9e5f6a8cca1eb656e900ffba79340fa1,18,Auto merge of #74040 - lcnr:const-occurs-check r=nikomatsakis fix unification of const variables r? `@nikomatsakis` `@varkor` `@eddyb` let's just ping everyone here :sweat_smile:,LAUGH,2020-11-17T15:19:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74044,CLOSED,2020-07-04T22:11:04Z,2020-10-09T10:36:11Z,Add slice::contains_ref to supplement slice::contains,poliorcetics,NA,NA,NA,THUMBS_UP,2020-08-25T05:15:31Z,creekorful,lunamicard@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-05T19:45:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-06T07:11:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-07T09:58:16Z,varkor,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-07T12:28:54Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-07T15:32:05Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-07T16:49:03Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-12T03:19:34Z,ljedrz,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-13T21:28:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-14T23:18:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-14T23:26:43Z,mcarton,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T02:30:32Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T07:27:14Z,prestwich,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T07:38:58Z,95th,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T07:51:26Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T08:03:47Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T08:25:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T09:09:58Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T09:26:22Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T11:09:04Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T12:38:00Z,dvtkrlbs,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T14:26:29Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T15:48:02Z,est31,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T17:00:36Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T17:27:16Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-15T17:27:18Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-15T21:04:41Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-15T21:04:41Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T10:02:08Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T13:30:23Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T14:01:31Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-16T14:01:33Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T14:17:58Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-16T14:20:40Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-16T14:20:45Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T15:00:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-16T17:00:06Z,ash2x3zb9cy,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-16T18:18:53Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T19:08:36Z,Avarel,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T21:31:39Z,mgostIH,dennizmodesti@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-16T22:17:23Z,delacian,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-17T16:04:34Z,Purpzie,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-17T16:04:34Z,Purpzie,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-17T16:04:35Z,Purpzie,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-17T17:24:15Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-17T17:24:16Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-17T19:58:51Z,bschaffn2,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-17T21:45:44Z,Dherse,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-18T11:01:06Z,95th,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-18T11:01:07Z,95th,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-19T14:44:17Z,daira,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-19T14:44:18Z,daira,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-19T14:44:18Z,daira,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-21T12:40:58Z,adwhit,adwhit@fastmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-22T21:10:42Z,kotauskas,v.toncharov@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-23T04:35:12Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-23T08:14:07Z,elichai,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-23T08:14:08Z,elichai,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-23T08:14:08Z,elichai,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-25T02:30:13Z,Peohta,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-25T02:30:27Z,Peohta,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-25T22:58:08Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-26T07:38:55Z,lnicola,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-26T15:45:36Z,busimus,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-26T16:01:02Z,DarrienG,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-26T16:01:03Z,DarrienG,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-26T17:36:58Z,eopb,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-27T03:50:51Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-27T03:50:52Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-27T03:50:52Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-07-27T14:50:23Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-27T14:50:24Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-07-31T06:37:46Z,dbdr,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-07-31T14:49:21Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-08-02T12:52:46Z,joseluis,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-08-03T03:16:34Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-08-04T07:48:56Z,moshg,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-08-28T01:33:14Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-08-28T01:33:17Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-08-29T21:13:06Z,yerke,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-08-29T21:13:07Z,yerke,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-09-03T12:59:01Z,marioortizmanero,marioortizmanero@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-09-03T15:26:23Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-09-03T19:38:53Z,jabedude,sinisterpatrician@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-09-08T07:09:54Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-09-08T07:09:56Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-09-08T07:10:28Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-09-08T07:10:29Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-09-08T07:10:29Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-03T06:14:24Z,Maxdis,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-05T19:08:55Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-05T19:08:55Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-05T19:08:56Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-06T11:42:53Z,chirsz-ever,chirsz@foxmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-06T12:40:22Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-06T12:40:22Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-06T12:40:23Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-06T13:50:17Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-06T21:20:42Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-06T22:36:21Z,johnthagen,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T04:52:39Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T04:52:41Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T04:52:42Z,marcianx,marcianx@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T13:14:27Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T13:14:28Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T14:28:39Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T14:28:40Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T14:28:41Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T14:47:30Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T14:47:34Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T14:47:35Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T15:24:06Z,Kestrer,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T15:24:07Z,Kestrer,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T15:24:07Z,Kestrer,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T17:48:38Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T17:48:45Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-07T20:39:26Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-07T20:39:27Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-07T22:02:44Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T01:43:36Z,yodaldevoid,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T12:51:24Z,robjtede,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-08T13:51:33Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T14:07:20Z,lights0123,developer@lights0123.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-08T14:22:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-08T14:22:44Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-08T15:51:23Z,l1h3r,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-08T15:51:25Z,l1h3r,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T15:51:26Z,l1h3r,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T16:01:21Z,h4x3rotab,h4x3rotab@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T17:02:50Z,nganhkhoa,mail.nganhkhoa@gmail.com https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T18:08:24Z,vallentin,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-08T18:26:40Z,wrmsr,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-09T09:23:56Z,robatipoor,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-09T11:03:19Z,iago-lito,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-09T11:03:19Z,iago-lito,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-10-09T16:33:50Z,Voronar,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-26T21:09:02Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-10-29T10:09:59Z,sdbondi,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-10-29T10:09:59Z,sdbondi,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2020-11-17T20:04:33Z,Limeth,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HOORAY,2020-11-17T20:04:33Z,Limeth,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,HEART,2020-11-17T20:04:33Z,Limeth,NA https://github.com/rust-lang/rust/pull/74060,MERGED,2020-07-05T13:08:43Z,2020-07-26T07:38:42Z,Remove trait LengthAtMost32,kpp,461707c5a119cc33c5d7df585ddb6cbec4a081bf,30,Auto merge of #74060 - kpp:remove_length_at_most_32 r=dtolnay Remove trait LengthAtMost32 This is a continuation of https://github.com/rust-lang/rust/pull/74026 preserving the original burrbull's commit. I talked to @burrbull he suggested me to finish his PR.,THUMBS_UP,2021-06-08T16:02:37Z,zohnannor,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-05T17:49:28Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-15T08:08:05Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-16T09:57:32Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-19T15:37:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-20T05:46:06Z,cpeterso,cpeterson@mozilla.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-20T06:42:48Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2020-07-20T09:14:21Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-20T13:31:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HOORAY,2020-07-21T02:11:16Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HOORAY,2020-07-21T05:46:38Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2020-07-21T05:46:39Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-07-21T05:46:40Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,EYES,2020-10-15T01:15:40Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HOORAY,2020-10-21T12:56:28Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2020-10-21T12:56:28Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2020-10-21T12:56:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,EYES,2020-10-21T12:56:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2021-04-15T18:03:25Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2021-04-15T18:03:29Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HOORAY,2021-05-09T20:29:20Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2021-05-09T20:29:23Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2021-05-09T20:29:41Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HOORAY,2022-02-10T20:45:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,HEART,2022-02-10T20:45:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74066,MERGED,2020-07-05T17:28:02Z,2020-07-12T12:09:53Z,Optimize is_ascii for str and [u8].,thomcc,1979fa86f9fd8cc53384d2dabe775bcbf012a5ad,5,Rollup merge of #74066 - thomcc:optimize-is-ascii r=nagisa Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version and `is_ascii_slice_libcore` is the new. I tried to document the code well so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now I tried to `debug_assert` all the safety invariants I'm depending on. (Of course none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway thanks. Let me know if you have questions/desired changes.,ROCKET,2022-02-10T20:45:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74067,MERGED,2020-07-05T17:38:15Z,2020-07-07T05:04:06Z,rustdoc: Restore underline text decoration on hover for FQN in header,rye,3199aeb6546add874f48bc89daa3fbcca8f74417,1,"Rollup merge of #74067 - rye:rustdoc-fqn-hover-underline r=GuillaumeGomez rustdoc: Restore underline text decoration on hover for FQN in header This causes the components of FQN's (e.g. `std` `net` and `Ipv4Addr` of the FQN `std::net::Ipv4Addr`) to behave similarly to other links in the contents of rustdoc-styled pages. When the user hovers over them more clearly indicating that they can be used for navigation. I (and I hope others at least in part) have found the prior design to be somewhat confusing as it is not clear (upon hovering) that the various parts of the FQN are actually links that the user can navigate to.

📸 Before mouse hovered over ""net"" in the FQN
📸 After mouse hovered over ""net"" in the FQN
",THUMBS_UP,2020-07-05T22:25:14Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/74071,MERGED,2020-07-05T20:20:44Z,2020-07-19T07:25:36Z,rustc_metadata: Make crate loading fully speculative,petrochenkov,43ba8409d7c7f93d6f0b3c22fe1b193788ff6162,16,Rollup merge of #74071 - petrochenkov:cload3 r=matthewjasper rustc_metadata: Make crate loading fully speculative Instead of reporting `span_err`s on the spot crate loading errors are now wrapped into the `CrateError` enum and returned so they are reported only at the top level `resolve_crate` call and not reported at all if we are resolving speculatively with `maybe_resolve_crate`. As a result we can attempt loading crates for error recovery (e.g. import suggestions) without any risk of producing extra errors. Also this means better separation between error reporting and actual logic. Fixes https://github.com/rust-lang/rust/issues/55103 Fixes https://github.com/rust-lang/rust/issues/56590,HEART,2020-07-05T23:18:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/74071,MERGED,2020-07-05T20:20:44Z,2020-07-19T07:25:36Z,rustc_metadata: Make crate loading fully speculative,petrochenkov,43ba8409d7c7f93d6f0b3c22fe1b193788ff6162,16,Rollup merge of #74071 - petrochenkov:cload3 r=matthewjasper rustc_metadata: Make crate loading fully speculative Instead of reporting `span_err`s on the spot crate loading errors are now wrapped into the `CrateError` enum and returned so they are reported only at the top level `resolve_crate` call and not reported at all if we are resolving speculatively with `maybe_resolve_crate`. As a result we can attempt loading crates for error recovery (e.g. import suggestions) without any risk of producing extra errors. Also this means better separation between error reporting and actual logic. Fixes https://github.com/rust-lang/rust/issues/55103 Fixes https://github.com/rust-lang/rust/issues/56590,HEART,2020-07-06T22:56:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74071,MERGED,2020-07-05T20:20:44Z,2020-07-19T07:25:36Z,rustc_metadata: Make crate loading fully speculative,petrochenkov,43ba8409d7c7f93d6f0b3c22fe1b193788ff6162,16,Rollup merge of #74071 - petrochenkov:cload3 r=matthewjasper rustc_metadata: Make crate loading fully speculative Instead of reporting `span_err`s on the spot crate loading errors are now wrapped into the `CrateError` enum and returned so they are reported only at the top level `resolve_crate` call and not reported at all if we are resolving speculatively with `maybe_resolve_crate`. As a result we can attempt loading crates for error recovery (e.g. import suggestions) without any risk of producing extra errors. Also this means better separation between error reporting and actual logic. Fixes https://github.com/rust-lang/rust/issues/55103 Fixes https://github.com/rust-lang/rust/issues/56590,HEART,2020-07-14T22:31:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74074,MERGED,2020-07-05T23:08:53Z,2020-07-07T05:04:04Z,Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.,sunfishcode,86f8c5350f172efd5fb98d83c4fb51900fd4abe6,1,Rollup merge of #74074 - sunfishcode:windows-openoptionsext-return-type r=LukasKalbertodt Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`. This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags` to be consistent with the other functions in the trait.,THUMBS_UP,2020-07-06T20:16:31Z,kubkon,kubkon@jakubkonka.com https://github.com/rust-lang/rust/pull/74077,MERGED,2020-07-06T00:24:54Z,2020-07-10T01:24:10Z,Use relative path for local links to primitives,sethp,07301e3d549f3f41a3d0a9f31aade293a3b9a3af,5,Rollup merge of #74077 - sethp:docs/fix-intra-doc-primitive-link r=jyn514 Use relative path for local links to primitives Else links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`. Split out from #73804.,THUMBS_UP,2020-07-06T00:46:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74079,MERGED,2020-07-06T01:27:23Z,2020-07-10T01:24:09Z,"Eliminate confusing ""globals"" terminology.",nnethercote,89c9e970ddbe47622bcc52b135d35508510daa55,25,"Rollup merge of #74079 - nnethercote:session-globals r=nikomatsakis Eliminate confusing ""globals"" terminology. There are some structures that are called ""globals"" but are they global to a compilation session and not truly global. I have always found this highly confusing so this commit renames them as ""session globals"" and adds a comment explaining things. Also the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs` r? @Aaron1011",HEART,2020-07-06T09:00:07Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/74079,MERGED,2020-07-06T01:27:23Z,2020-07-10T01:24:09Z,"Eliminate confusing ""globals"" terminology.",nnethercote,89c9e970ddbe47622bcc52b135d35508510daa55,25,"Rollup merge of #74079 - nnethercote:session-globals r=nikomatsakis Eliminate confusing ""globals"" terminology. There are some structures that are called ""globals"" but are they global to a compilation session and not truly global. I have always found this highly confusing so this commit renames them as ""session globals"" and adds a comment explaining things. Also the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs` r? @Aaron1011",HEART,2020-07-06T13:33:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-06T13:34:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-06T17:16:05Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-07T08:18:45Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-07T09:20:46Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",EYES,2020-07-07T09:20:52Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-07T12:08:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-11T03:45:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-13T20:32:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-14T14:07:57Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74091,MERGED,2020-07-06T09:15:30Z,2020-07-19T10:46:59Z,Generating the coverage map,richkadel,47ea6d90b073ab977cf072e2f5f46d63de532cc6,52,"Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4 r=tmandry Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE=""main.profraw"" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation",HOORAY,2020-07-14T23:41:08Z,tmandry,NA https://github.com/rust-lang/rust/pull/74113,MERGED,2020-07-06T22:07:47Z,2020-07-15T16:48:20Z,Support const args in type dependent paths (Take 2),lcnr,7e11379f3b4c376fbb9a6c4d44f3286ccc28d149,101,Auto merge of #74113 - lcnr:type-dependent-consts-2 r=eddyb Support const args in type dependent paths (Take 2) once more except it is sound this time :smiling_face_with_three_hearts: previously #71154 ----- ```rust #![feature(const_generics)] struct A; impl A { fn foo(&self) -> usize { N } } struct B; impl B { fn foo(&self) -> usize { 42 } } fn main() { let a = A; a.foo::<7>(); } ``` When calling `type_of` for generic const arguments we now use the `TypeckTables` of the surrounding body to get the expected type. This alone causes cycle errors though as we now have `typeck_tables_of(main)` -> `...` -> `type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290) To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by calling `type_of(param_def_id)` instead. We have to somehow remember the `DefId` of the param through all of typeck which is done using the struct `ty::WithOptConstParam` which replaces `DefId` where needed and contains an `Option` to be able to store the const parameter in case it exists. Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached) with `query_name_of_const_arg` taking a pair `(did param_did): (LocalDefId DefId)`. For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`. r? @eddyb @varkor,HEART,2020-11-19T15:29:47Z,varkor,NA https://github.com/rust-lang/rust/pull/74113,MERGED,2020-07-06T22:07:47Z,2020-07-15T16:48:20Z,Support const args in type dependent paths (Take 2),lcnr,7e11379f3b4c376fbb9a6c4d44f3286ccc28d149,101,Auto merge of #74113 - lcnr:type-dependent-consts-2 r=eddyb Support const args in type dependent paths (Take 2) once more except it is sound this time :smiling_face_with_three_hearts: previously #71154 ----- ```rust #![feature(const_generics)] struct A; impl A { fn foo(&self) -> usize { N } } struct B; impl B { fn foo(&self) -> usize { 42 } } fn main() { let a = A; a.foo::<7>(); } ``` When calling `type_of` for generic const arguments we now use the `TypeckTables` of the surrounding body to get the expected type. This alone causes cycle errors though as we now have `typeck_tables_of(main)` -> `...` -> `type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290) To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by calling `type_of(param_def_id)` instead. We have to somehow remember the `DefId` of the param through all of typeck which is done using the struct `ty::WithOptConstParam` which replaces `DefId` where needed and contains an `Option` to be able to store the const parameter in case it exists. Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached) with `query_name_of_const_arg` taking a pair `(did param_did): (LocalDefId DefId)`. For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`. r? @eddyb @varkor,HEART,2021-06-07T18:53:51Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-07T17:24:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:27:11Z,ratijas,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:33:26Z,tyranron,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:34:10Z,nev3rfail,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:35:42Z,r4v3n6101,raven6107@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-07T20:35:46Z,Hirrolot,hirrolot@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:37:47Z,Uzere,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:40:02Z,AlexStrNik,alex.str.nik@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:40:37Z,npv3s,npv3s@skopa.dev https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:45:23Z,demkom58,demkom58@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:47:15Z,dmitrijza,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:51:01Z,mati865,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:52:10Z,Dmitry-Borodin,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:52:54Z,CryZe,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:55:43Z,SHADOWDANCH,chdanilpro@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T20:57:32Z,Kinrany,kinrany@yandex.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:09:24Z,Mnwa,mikhail@panfilov.tech https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:11:21Z,mersinvald,git@mkl.dev https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:18:25Z,nlinker,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:21:07Z,olozovoi,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:24:42Z,maybe-hello-world,maybe.hello.world@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:36:06Z,rushter,gh@rushter.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T21:39:50Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-07T21:39:52Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T23:22:59Z,BigRedEye,mail@bigredeye.me https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T23:50:37Z,maxwase,max.vvase@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T23:53:47Z,sergeysova,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-07T23:58:09Z,dmitri-f,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:15:52Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:17:47Z,protheory8,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T16:21:41Z,bschaffn2,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:24:12Z,ljedrz,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:35:42Z,tiger10050,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:37:12Z,ericmartinezr,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-08T16:37:13Z,ericmartinezr,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:38:19Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-08T16:46:27Z,X-Ryl669,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",EYES,2020-07-08T16:53:59Z,coolshaurya,me@shauryashubham.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T16:59:40Z,Sominemo,me@sominemo.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:01:57Z,gsedometov,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T17:03:39Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-08T17:03:43Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:22:03Z,traverseda,traverse.da@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:23:35Z,Tarinu,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:31:23Z,haikutech,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T17:40:38Z,tomMoulard,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:42:32Z,jrakow,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:48:15Z,nkconnor,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:48:27Z,alvinhochun,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:50:21Z,delehef,github@odena.eu https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T17:57:25Z,doorgan,dorgandash@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:08:19Z,Owez,root@ogriffiths.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:09:29Z,luizfls,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:13:33Z,pferreir,ilzogoiby@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:13:59Z,lnicola,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:25:43Z,trha,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:27:34Z,htrefil,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:28:33Z,teymour-aldridge,teymour@reasoning.page https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:31:18Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:34:53Z,DDoSolitary,DDoSolitary@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:39:37Z,Pratyush,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:43:55Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:50:28Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T18:51:57Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-08T18:52:09Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T18:57:32Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-08T18:57:35Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-08T18:58:26Z,Agrailag,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T19:03:20Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:04:21Z,Agrailag,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-08T19:09:06Z,a1phyr,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:12:41Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T19:18:40Z,valerie-makes,v@valbailey.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:21:23Z,Miserlou,miserlou@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:21:25Z,astrovityanka,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-08T19:21:27Z,astrovityanka,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:53:50Z,marianocordoba,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:55:25Z,bogdanbankov,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T19:57:41Z,sschueller,sschueller@techdroid.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T20:01:07Z,llogiq,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T20:33:01Z,Dherse,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-08T20:56:07Z,demkom58,demkom58@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T21:22:56Z,B14m3m3,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T21:25:55Z,firegodjr,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T21:26:49Z,dialnco,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-08T21:42:35Z,estebank,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",EYES,2020-07-08T22:07:34Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T22:10:07Z,BartWillems,bwillems@protonmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T22:18:38Z,EdShaw,edwardshaw9+github@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T22:45:47Z,andresrama,and-yrama@live.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-08T23:16:02Z,jonathangoodmanFC,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",EYES,2020-07-08T23:22:07Z,Qwertie-,luke@picciau.me https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T23:25:45Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-08T23:38:28Z,ms-jpq,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T00:01:01Z,luanraithz,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T00:19:53Z,skrater,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T01:08:13Z,noc7c9,noc7c9@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-09T01:08:17Z,noc7c9,noc7c9@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T01:23:36Z,guihkx,guih.rox@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T01:37:40Z,jtr109,conbas2019@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T02:24:02Z,MementoVile,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T04:01:09Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T04:18:39Z,rednithin,reddy.nithinpg@live.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T04:34:52Z,rokit,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T05:27:18Z,comex,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T06:05:04Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-09T06:05:07Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T07:57:49Z,calops,calops@tocards.net https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T08:08:59Z,natasky,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T08:21:31Z,v--,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-09T08:21:36Z,v--,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T11:16:11Z,pkuphy,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T11:25:37Z,nano-bot,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T12:39:51Z,anderejd,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T13:13:58Z,LizardWizzard,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T13:47:07Z,nacardin,nickcardin@gatech.edu https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-09T14:29:15Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T14:29:16Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T14:41:01Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T14:45:51Z,MythicManiac,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T15:53:34Z,DoumanAsh,douman@gmx.se https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",LAUGH,2020-07-09T15:53:47Z,srid,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-09T16:06:15Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-09T16:06:19Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T16:48:43Z,shilangyu,xmarcinmarcin@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-09T20:01:11Z,aymanapatel,ayman.patel97@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-10T01:54:04Z,jsephfroot,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T01:59:23Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-10T02:41:30Z,AZanellato,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T02:42:26Z,Austaras,austaras@outlook.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-10T03:33:02Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T04:49:56Z,axelf4,axelsfor@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T05:57:32Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",HEART,2020-07-10T06:35:08Z,crepererum,marco@crepererum.net https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T09:49:55Z,plazmoid,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T09:51:27Z,Simeon979,adegbolasimeon@gmail.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T13:00:14Z,Bytekeeper,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_UP,2020-07-10T13:59:25Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T16:30:59Z,weregeld,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-10T16:31:14Z,weregeld,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T16:51:47Z,charlesdeepk,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T16:56:35Z,Fallyx,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T17:11:30Z,TundraFizz,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-10T17:42:02Z,theamazingwaffle,pavel.buranov@vk.com https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-11T03:08:39Z,novacrazy,NA https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",THUMBS_DOWN,2020-07-11T06:58:07Z,meain,mail@meain.io https://github.com/rust-lang/rust/pull/74127,MERGED,2020-07-07T15:16:12Z,2020-07-11T10:25:15Z,"Avoid ""whitelist""",tamird,d2f8c30951581fa35bde0dbdd3260c5019b50421,55,"Rollup merge of #74127 - tamird:allowlist r=oli-obk Avoid ""whitelist"" Other terms are more inclusive and precise.",CONFUSED,2020-07-11T10:21:30Z,playXE,pr.adelprokurov@yandex.ru https://github.com/rust-lang/rust/pull/74130,CLOSED,2020-07-07T17:24:31Z,2020-11-07T11:26:40Z,Permit evaluation of assoc items on `Self` by avoiding cycle error,estebank,NA,NA,NA,HOORAY,2020-07-07T18:59:25Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74130,CLOSED,2020-07-07T17:24:31Z,2020-11-07T11:26:40Z,Permit evaluation of assoc items on `Self` by avoiding cycle error,estebank,NA,NA,NA,HOORAY,2020-07-07T22:46:46Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74130,CLOSED,2020-07-07T17:24:31Z,2020-11-07T11:26:40Z,Permit evaluation of assoc items on `Self` by avoiding cycle error,estebank,NA,NA,NA,HOORAY,2020-07-16T09:52:56Z,aschampion,andrew.champion@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:01:00Z,ljedrz,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:18:48Z,salpalvv,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:21:55Z,tiger10050,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:34:28Z,CryZe,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:37:44Z,wdroz,william.droz.ch@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T14:37:54Z,smmalis37,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T14:44:45Z,orion-git,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",LAUGH,2020-07-08T14:46:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T14:46:32Z,SunnyWar,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-07-08T15:14:46Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T15:25:54Z,Owez,root@ogriffiths.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T15:26:37Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T15:29:24Z,mati865,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T15:31:43Z,IRSmoh,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T16:13:28Z,protheory8,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T16:28:37Z,bschaffn2,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T16:38:18Z,ericmartinezr,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",LAUGH,2020-07-08T16:38:19Z,ericmartinezr,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",EYES,2020-07-08T16:54:15Z,coolshaurya,me@shauryashubham.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T17:07:10Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T17:22:47Z,ratijas,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",LAUGH,2020-07-08T17:22:48Z,ratijas,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-07-08T17:22:49Z,ratijas,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",EYES,2020-07-08T17:22:49Z,ratijas,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T17:54:10Z,alvinhochun,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T18:08:07Z,newpavlov,newpavlov@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T18:14:24Z,lnicola,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T18:35:23Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T18:49:39Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T19:03:16Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",HEART,2020-07-08T19:03:21Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T19:11:05Z,Agrailag,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T19:20:27Z,astrovityanka,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T19:22:32Z,nlinker,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-07-08T19:22:34Z,nlinker,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",LAUGH,2020-07-08T19:22:35Z,nlinker,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T22:24:41Z,raggy-rs,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T22:26:44Z,nkconnor,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-08T23:15:10Z,jonathangoodmanFC,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-08T23:24:30Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-09T00:15:33Z,SimonImbrogno,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-09T02:21:11Z,MementoVile,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-09T06:07:58Z,evanjs,evanjsx@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-09T14:54:55Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-09T15:53:21Z,DoumanAsh,douman@gmx.se https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",HEART,2020-07-09T18:47:06Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-10T01:56:33Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-10T10:01:03Z,plazmoid,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-10T17:04:19Z,weregeld,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-07-13T08:24:26Z,MaxNanasy,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-07-13T16:56:12Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-07-13T16:56:18Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",HEART,2020-08-23T20:39:42Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_UP,2020-08-23T20:39:44Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-08-26T09:46:54Z,Fogapod,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-08-26T09:50:19Z,Fogapod,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-08-28T15:33:44Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",CONFUSED,2020-08-28T15:33:50Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-09-01T02:26:58Z,masonsha,NA https://github.com/rust-lang/rust/pull/74150,MERGED,2020-07-08T13:56:03Z,2020-07-10T01:23:53Z,"Avoid ""blacklist""",tamird,d4d11118ef55501a73d423651e45c0102afd0209,63,"Rollup merge of #74150 - tamird:blocklist r=nikomatsakis Avoid ""blacklist"" Other terms are more inclusive and precise. Clippy still has a lint named ""blacklisted-name"" but renaming it would be a breaking change so is left for future work. The target configuration option ""abi-blacklist"" has been depreciated and renamed to ""unsupported-abis"". The old name continues to work.",THUMBS_DOWN,2020-09-01T14:48:00Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/74175,MERGED,2020-07-09T06:57:50Z,2020-07-15T03:32:59Z,More static symbols,nnethercote,567ad7455d5f25f6b38d2fded1cb621e0c34a48b,67,Auto merge of #74175 - nnethercote:more-static-symbols r=oli-obk More static symbols These commits add some more static symbols and convert lots of places to use them. r? @oli-obk,HEART,2020-07-09T09:48:26Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,LAUGH,2020-07-09T15:46:09Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,HOORAY,2020-07-09T15:46:12Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,EYES,2020-07-09T15:46:16Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,ROCKET,2020-07-09T15:46:18Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-09T17:19:50Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-11T22:23:02Z,tinaun,NA https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-12T01:29:10Z,eric-unc,NA https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-12T01:31:16Z,SizableShrimp,sizableshrimp@sizableshrimp.me https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-13T17:40:35Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-14T09:15:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-07-16T09:24:47Z,aaronfranke,arnfranke@yahoo.com https://github.com/rust-lang/rust/pull/74178,CLOSED,2020-07-09T10:03:36Z,2020-08-13T00:12:32Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-10-03T04:03:06Z,xCrypt0r,legacy5877@gmail.com https://github.com/rust-lang/rust/pull/74181,MERGED,2020-07-09T13:11:59Z,2020-07-10T17:25:03Z,Gate GHA on everything but macOS,pietroalbini,daecab3a784f28082df90cebb204998051f3557d,2,Auto merge of #74181 - pietroalbini:ci-gha-fallible-macos r=Mark-Simulacrum Gate GHA on everything but macOS The macOS spurious failure started happening again. As we discussed during the infra team meeting this gates on everything but macOS. r? @Mark-Simulacrum,ROCKET,2020-07-27T14:54:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74192,MERGED,2020-07-09T18:18:32Z,2020-08-15T00:46:22Z,Improve documentation on process::Child.std* fields,xkr47,dae020d49116dc684b92b0f7d7c10b29520411f2,1,Rollup merge of #74192 - xkr47:patch-1 r=Mark-Simulacrum Improve documentation on process::Child.std* fields As a relative beginner it took a while for me to figure out I could just steal the references to avoid partially moving the child and thus retain ability to call functions on it (and store it in structs etc).,THUMBS_UP,2020-07-24T09:23:48Z,mendess,pedro.mendes.26@gmail.com https://github.com/rust-lang/rust/pull/74194,MERGED,2020-07-09T18:23:13Z,2020-10-07T03:12:37Z,Add PartialEq impls for Vec <-> slice,mbrubeck,5779815f896fa6e21c04a5efb378aa6ba009a471,2,Auto merge of #74194 - mbrubeck:slice-eq r=sfackler Add PartialEq impls for Vec <-> slice This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls: ``` impl PartialEq<[B]> for Vec where A: PartialEq { .. } impl PartialEq> for [A] where A: PartialEq { .. } ``` Since this is insta-stable it should go through the `@rust-lang/libs` FCP process. Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.,HOORAY,2020-10-15T04:46:54Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74194,MERGED,2020-07-09T18:23:13Z,2020-10-07T03:12:37Z,Add PartialEq impls for Vec <-> slice,mbrubeck,5779815f896fa6e21c04a5efb378aa6ba009a471,2,Auto merge of #74194 - mbrubeck:slice-eq r=sfackler Add PartialEq impls for Vec <-> slice This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls: ``` impl PartialEq<[B]> for Vec where A: PartialEq { .. } impl PartialEq> for [A] where A: PartialEq { .. } ``` Since this is insta-stable it should go through the `@rust-lang/libs` FCP process. Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.,HOORAY,2020-10-15T05:17:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74194,MERGED,2020-07-09T18:23:13Z,2020-10-07T03:12:37Z,Add PartialEq impls for Vec <-> slice,mbrubeck,5779815f896fa6e21c04a5efb378aa6ba009a471,2,Auto merge of #74194 - mbrubeck:slice-eq r=sfackler Add PartialEq impls for Vec <-> slice This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls: ``` impl PartialEq<[B]> for Vec where A: PartialEq { .. } impl PartialEq> for [A] where A: PartialEq { .. } ``` Since this is insta-stable it should go through the `@rust-lang/libs` FCP process. Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.,HOORAY,2020-10-15T19:27:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/74194,MERGED,2020-07-09T18:23:13Z,2020-10-07T03:12:37Z,Add PartialEq impls for Vec <-> slice,mbrubeck,5779815f896fa6e21c04a5efb378aa6ba009a471,2,Auto merge of #74194 - mbrubeck:slice-eq r=sfackler Add PartialEq impls for Vec <-> slice This is a follow-up to #71660 and rust-lang/rfcs#2917 to add two more missing vec/slice PartialEq impls: ``` impl PartialEq<[B]> for Vec where A: PartialEq { .. } impl PartialEq> for [A] where A: PartialEq { .. } ``` Since this is insta-stable it should go through the `@rust-lang/libs` FCP process. Note that I used version 1.47.0 for the `stable` attribute because I assume this will not merge before the 1.46.0 branch is cut next week.,HOORAY,2020-11-20T00:31:51Z,tmandry,NA https://github.com/rust-lang/rust/pull/74228,MERGED,2020-07-11T01:15:15Z,2020-07-14T23:42:30Z,Provide structured suggestion on unsized fields and fn params,estebank,a364c0a782948e48333e296bcb089119394de9e5,131,Rollup merge of #74228 - estebank:unsized-param r=davidtwco Provide structured suggestion on unsized fields and fn params * Suggest borrowing or boxing unsized fields * Suggest borrowing fn parameters * Remove some verbosity of unsized errors * Remove `on_unimplemented` note from `trait Sized` Fix #23286 fix #28653. r? @davidtwco,THUMBS_UP,2020-07-15T02:55:22Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/74237,MERGED,2020-07-11T08:47:07Z,2020-07-22T18:17:36Z,compiletest: Rewrite extract_*_version functions,tesuji,216ed3c4ab88f666d5a883b66e31b8fdaa48f211,13,Rollup merge of #74237 - lzutao:compiletest r=Mark-Simulacrum compiletest: Rewrite extract_*_version functions This makes extract_lldb_version has the same version type like extract_gdb_version.,HEART,2020-07-12T00:43:32Z,panaman67,NA https://github.com/rust-lang/rust/pull/74238,MERGED,2020-07-11T11:22:41Z,2020-08-23T16:44:22Z,stabilize ptr_offset_from,RalfJung,9d606d939a61c2f4c7bb4d89d959b60a53f50241,10,"Auto merge of #74238 - RalfJung:offset_from r=oli-obk stabilize ptr_offset_from This stabilizes ptr::offset_from and closes https://github.com/rust-lang/rust/issues/41079. It also removes the deprecated `wrapping_offset_from`. This function was deprecated 19 days ago and was never stable; given an FCP of 10 days and some waiting time until FCP starts that leaves at least a month between deprecation and removal which I think is fine for a nightly-only API. Regarding the open questions in https://github.com/rust-lang/rust/issues/41079: * Should offset_from abort instead of panic on ZSTs? -- As far as I know there is no precedent for such aborts. We could however declare this UB. Given that the size is always known statically and the check thus rather cheap UB seems excessive. * Should there be more methods like this with different restrictions (to allow nuw/nsw perhaps) or that return usize (like how isize-taking offset is more conveniently done with usize-taking add these days)? -- No reason to block stabilization on that we can always add such methods later. Also nominating the lang team because this exposes an intrinsic. The stabilized method is best described [by its doc-comment](https://github.com/RalfJung/rust/blob/56d4b2d69abb93e4f0ca79471deca7aaaaeca214/src/libcore/ptr/const_ptr.rs#L227). The documentation forgot to mention the requirement that both pointers must ""have the same provenance"" aka ""be derived from pointers to the same allocation"" which I am adding in this PR. This is a precondition that [Miri already implements](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a3b9d0a07a01321f5202cd99e9613480) and that should LLVM ever obtain a `psub` operation to subtract pointers will likely be required for that operation (following the semantics in [this paper](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf)).",THUMBS_UP,2020-07-18T10:55:47Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/74254,CLOSED,2020-07-11T19:35:47Z,2020-10-31T12:57:28Z,Default for arrays via const generics,MikailBag,NA,NA,NA,THUMBS_UP,2020-07-11T20:38:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74254,CLOSED,2020-07-11T19:35:47Z,2020-10-31T12:57:28Z,Default for arrays via const generics,MikailBag,NA,NA,NA,THUMBS_UP,2020-07-12T09:23:08Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74254,CLOSED,2020-07-11T19:35:47Z,2020-10-31T12:57:28Z,Default for arrays via const generics,MikailBag,NA,NA,NA,THUMBS_UP,2020-07-14T00:57:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74254,CLOSED,2020-07-11T19:35:47Z,2020-10-31T12:57:28Z,Default for arrays via const generics,MikailBag,NA,NA,NA,THUMBS_UP,2020-07-17T12:11:15Z,95th,NA https://github.com/rust-lang/rust/pull/74254,CLOSED,2020-07-11T19:35:47Z,2020-10-31T12:57:28Z,Default for arrays via const generics,MikailBag,NA,NA,NA,THUMBS_UP,2020-09-09T11:56:32Z,frol,NA https://github.com/rust-lang/rust/pull/74271,MERGED,2020-07-12T16:59:46Z,2020-07-14T23:42:25Z,process_unix: prefer i32::*_be_bytes over manually shifting bytes,tesuji,7b1247c34fe40f397053344b2f98a51fcc45f2a2,1,Rollup merge of #74271 - lzutao:cmdbytes r=LukasKalbertodt process_unix: prefer i32::*_be_bytes over manually shifting bytes This PR makes it more clear about the intend of the code.,THUMBS_UP,2020-07-12T18:14:22Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/74275,MERGED,2020-07-12T19:51:19Z,2020-08-25T20:55:58Z,Refactor the partitioning module to make it easier to introduce new algorithms,wesleywiser,8ba22504e8e5dcbbe136d97f63c1280dabc523d0,5,Auto merge of #74275 - wesleywiser:break_up_partitioning_rs r=pnkfelix Refactor the partitioning module to make it easier to introduce new algorithms I've split the `librustc_mir::monomorphize::partitioning` module into a few files and introduced a `Partitioner` trait which allows us to decouple the partitioning algorithm from the code which integrates it into the query system. This should allow us to introduce new partitioning algorithms much more easily. I've also gone ahead and added a `-Z` flag to control which algorithm is used (currently there is only the `default`). I left a few comments in places where things might be improved further. r? @pnkfelix cc @rust-lang/wg-incr-comp,HOORAY,2020-07-13T10:44:01Z,mati865,NA https://github.com/rust-lang/rust/pull/74283,CLOSED,2020-07-13T00:21:53Z,2020-08-16T17:46:29Z,Compute `query::Providers` almost entirely at compile-time.,eddyb,NA,NA,NA,ROCKET,2020-07-13T09:07:51Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/74283,CLOSED,2020-07-13T00:21:53Z,2020-08-16T17:46:29Z,Compute `query::Providers` almost entirely at compile-time.,eddyb,NA,NA,NA,ROCKET,2020-07-14T00:19:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74283,CLOSED,2020-07-13T00:21:53Z,2020-08-16T17:46:29Z,Compute `query::Providers` almost entirely at compile-time.,eddyb,NA,NA,NA,ROCKET,2020-07-14T07:28:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74283,CLOSED,2020-07-13T00:21:53Z,2020-08-16T17:46:29Z,Compute `query::Providers` almost entirely at compile-time.,eddyb,NA,NA,NA,ROCKET,2020-07-27T23:24:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74285,MERGED,2020-07-13T05:01:11Z,2020-07-14T08:55:33Z,#71669: add ui codegen tests for volatile + nearby int intrinsics,theo-lw,fa4ada1a862f6ba0a2953e899f472cc358de3533,5,Rollup merge of #74285 - wangtheo:issue-71669 r=lcnr #71669: add ui codegen tests for volatile + nearby int intrinsics Added some tests for intrinsics. See https://github.com/rust-lang/rust/issues/71669.,HEART,2020-07-13T09:25:30Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74304,MERGED,2020-07-13T20:46:45Z,2021-02-05T02:09:01Z,Stabilize the Wake trait,yoshuawuyts,d20d09712550c820c2d67a9b3ed2a3f9debb9393,3,Rollup merge of #74304 - yoshuawuyts:stabilize-wake r=KodrAus Stabilize the Wake trait This PR proposes stabilizing the `wake_trait` feature tracking issue https://github.com/rust-lang/rust/issues/69912. ## Motivation The surface area this trait introduces is small and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this. Personally I would love to have this available on stable since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended. ## Implementation notes This PR itself fixes a link in the docs and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting but is intended to serve as a teaching device for both `task::Wake` and futures alike.,THUMBS_UP,2020-11-23T23:35:33Z,cdecompilador,NA https://github.com/rust-lang/rust/pull/74304,MERGED,2020-07-13T20:46:45Z,2021-02-05T02:09:01Z,Stabilize the Wake trait,yoshuawuyts,d20d09712550c820c2d67a9b3ed2a3f9debb9393,3,Rollup merge of #74304 - yoshuawuyts:stabilize-wake r=KodrAus Stabilize the Wake trait This PR proposes stabilizing the `wake_trait` feature tracking issue https://github.com/rust-lang/rust/issues/69912. ## Motivation The surface area this trait introduces is small and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this. Personally I would love to have this available on stable since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended. ## Implementation notes This PR itself fixes a link in the docs and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting but is intended to serve as a teaching device for both `task::Wake` and futures alike.,HEART,2020-12-10T13:42:03Z,mleonhard,michael@leonhardllc.com https://github.com/rust-lang/rust/pull/74304,MERGED,2020-07-13T20:46:45Z,2021-02-05T02:09:01Z,Stabilize the Wake trait,yoshuawuyts,d20d09712550c820c2d67a9b3ed2a3f9debb9393,3,Rollup merge of #74304 - yoshuawuyts:stabilize-wake r=KodrAus Stabilize the Wake trait This PR proposes stabilizing the `wake_trait` feature tracking issue https://github.com/rust-lang/rust/issues/69912. ## Motivation The surface area this trait introduces is small and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this. Personally I would love to have this available on stable since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended. ## Implementation notes This PR itself fixes a link in the docs and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting but is intended to serve as a teaching device for both `task::Wake` and futures alike.,THUMBS_UP,2020-12-10T15:50:25Z,sagebind,me@stephencoakley.com https://github.com/rust-lang/rust/pull/74325,MERGED,2020-07-14T13:45:57Z,2020-07-16T22:23:24Z,Focus on the current file in the source file sidebar,GuillaumeGomez,196243ed9bf37e907c0a9904fd7f48e8af8c358a,1,Rollup merge of #74325 - GuillaumeGomez:focus-source-file-sidebar r=kinnison Focus on the current file in the source file sidebar Fixes #73360. r? @kinnison cc @rust-lang/rustdoc,HEART,2020-07-14T13:50:03Z,tesuji,NA https://github.com/rust-lang/rust/pull/74326,CLOSED,2020-07-14T14:00:10Z,2020-07-15T07:27:10Z,[perf] implement `Default` using const generics,lcnr,NA,NA,NA,EYES,2020-07-14T14:01:35Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/74328,MERGED,2020-07-14T14:05:26Z,2020-09-12T04:00:59Z,Stabilize core::future::{pending ready},yoshuawuyts,94a7ea271f0996848f8fa03c61067620736b1242,6,Auto merge of #74328 - yoshuawuyts:stabilize-future-readiness-fns r=sfackler Stabilize core::future::{pending ready} This PR stabilizes `core::future::{pending ready}` tracking issue https://github.com/rust-lang/rust/issues/70921. ## Motivation These functions have been on nightly for three months now and have lived as part of the futures ecosystem for several years. In that time these functions have undergone several iterations with [the `async-std` impls](https://docs.rs/async-std/1.6.2/async_std/future/index.html) probably diverging the most (using `async fn` which in hindsight was a mistake). It seems the space around these functions has been _thoroughly_ explored over the last couple of years and the ecosystem has settled on the current shape of the functions. It seems highly unlikely we'd want to make any further changes to these functions so I propose we stabilize. ## Implementation notes This stabilization PR was fairly straightforward; this feature has already thoroughly been reviewed by the libs team already in https://github.com/rust-lang/rust/pull/70834. So all this PR does is remove the feature gate.,HEART,2020-09-17T03:16:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74337,MERGED,2020-07-14T17:39:22Z,2020-07-16T06:25:14Z,Handle case of incomplete local ty more gracefully,estebank,f4bbd0e607d3f302342b835999105d4a2ad4025d,3,"Rollup merge of #74337 - estebank:ty-parse-recovery r=varkor Handle case of incomplete local ty more gracefully When encountering a local binding with a type that isn't completed the parser will reach a `=` token. When this happen consider the type ""complete"" as far as the parser is concerned to avoid further errors being emitted by parse recovery logic.",HEART,2020-07-15T08:46:08Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74344,MERGED,2020-07-14T23:08:26Z,2020-07-16T06:25:13Z,Remove string comparison and use diagnostic item instead,estebank,bee28990d3d3c43f1c6dd83e4623cfa3e5f65caf,3,Rollup merge of #74344 - estebank:stringly-wobbly r=eddyb Remove string comparison and use diagnostic item instead r? @eddyb,THUMBS_UP,2020-07-15T05:45:25Z,da-x,NA https://github.com/rust-lang/rust/pull/74344,MERGED,2020-07-14T23:08:26Z,2020-07-16T06:25:13Z,Remove string comparison and use diagnostic item instead,estebank,bee28990d3d3c43f1c6dd83e4623cfa3e5f65caf,3,Rollup merge of #74344 - estebank:stringly-wobbly r=eddyb Remove string comparison and use diagnostic item instead r? @eddyb,THUMBS_UP,2020-07-15T13:16:27Z,tesuji,NA https://github.com/rust-lang/rust/pull/74351,MERGED,2020-07-15T04:01:21Z,2020-07-17T03:30:38Z,Do not render unstable items for rustc doc,tesuji,0e70884083f8161e2abbb4a326a0dd0413e06f38,5,Rollup merge of #74351 - lzutao:remove-rustc-internal-compiler-warns r=Mark-Simulacrum Do not render unstable items for rustc doc See the zulip conversion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc.20doc.3A.20.22internal.20compiler.20API.22.20warns.20are.20everywhere!/near/203850782 Before: ![image](https://user-images.githubusercontent.com/15225902/87501971-9cff8780-c68a-11ea-93b4-ea53ce18a77b.png) After: ![image](https://user-images.githubusercontent.com/15225902/87501985-a7218600-c68a-11ea-81c0-a6b5b120832c.png) Nothing changes in unstable items of std: Before: ![image](https://user-images.githubusercontent.com/15225902/87502004-b7d1fc00-c68a-11ea-9224-a27a1d2a81d6.png) After: ![image](https://user-images.githubusercontent.com/15225902/87502018-c0c2cd80-c68a-11ea-9773-4c63158025cb.png) Closes #54682,HEART,2020-07-17T04:01:39Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/74361,MERGED,2020-07-15T12:15:22Z,2020-07-24T13:59:11Z,Improve doc theme logo display,GuillaumeGomez,38b295699f891d05d7b3dfefca3ee4a50e63d759,3,Rollup merge of #74361 - GuillaumeGomez:theme-logo r=Manishearth Improve doc theme logo display Fixes #74350. The first commit cleans up the whitespaces and converts them to tabs. We should definitely write a tidy check for this (will do it in another PR). Screenshots: ![Screenshot from 2020-07-15 14-08-25](https://user-images.githubusercontent.com/3050060/87543748-8581c800-c6a5-11ea-8417-cbf98ebbfd10.png) ![Screenshot from 2020-07-15 14-11-59](https://user-images.githubusercontent.com/3050060/87543747-84e93180-c6a5-11ea-8cea-976b1470e809.png) ![Screenshot from 2020-07-15 14-12-12](https://user-images.githubusercontent.com/3050060/87543745-84509b00-c6a5-11ea-8324-c3c46ab2d9ef.png) r? @lzutao cc @Cldfire,THUMBS_UP,2020-07-15T12:18:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/74361,MERGED,2020-07-15T12:15:22Z,2020-07-24T13:59:11Z,Improve doc theme logo display,GuillaumeGomez,38b295699f891d05d7b3dfefca3ee4a50e63d759,3,Rollup merge of #74361 - GuillaumeGomez:theme-logo r=Manishearth Improve doc theme logo display Fixes #74350. The first commit cleans up the whitespaces and converts them to tabs. We should definitely write a tidy check for this (will do it in another PR). Screenshots: ![Screenshot from 2020-07-15 14-08-25](https://user-images.githubusercontent.com/3050060/87543748-8581c800-c6a5-11ea-8417-cbf98ebbfd10.png) ![Screenshot from 2020-07-15 14-11-59](https://user-images.githubusercontent.com/3050060/87543747-84e93180-c6a5-11ea-8cea-976b1470e809.png) ![Screenshot from 2020-07-15 14-12-12](https://user-images.githubusercontent.com/3050060/87543745-84509b00-c6a5-11ea-8324-c3c46ab2d9ef.png) r? @lzutao cc @Cldfire,THUMBS_UP,2020-07-15T12:39:18Z,Cldfire,NA https://github.com/rust-lang/rust/pull/74361,MERGED,2020-07-15T12:15:22Z,2020-07-24T13:59:11Z,Improve doc theme logo display,GuillaumeGomez,38b295699f891d05d7b3dfefca3ee4a50e63d759,3,Rollup merge of #74361 - GuillaumeGomez:theme-logo r=Manishearth Improve doc theme logo display Fixes #74350. The first commit cleans up the whitespaces and converts them to tabs. We should definitely write a tidy check for this (will do it in another PR). Screenshots: ![Screenshot from 2020-07-15 14-08-25](https://user-images.githubusercontent.com/3050060/87543748-8581c800-c6a5-11ea-8417-cbf98ebbfd10.png) ![Screenshot from 2020-07-15 14-11-59](https://user-images.githubusercontent.com/3050060/87543747-84e93180-c6a5-11ea-8cea-976b1470e809.png) ![Screenshot from 2020-07-15 14-12-12](https://user-images.githubusercontent.com/3050060/87543745-84509b00-c6a5-11ea-8324-c3c46ab2d9ef.png) r? @lzutao cc @Cldfire,THUMBS_UP,2020-07-15T14:24:32Z,UtherII,NA https://github.com/rust-lang/rust/pull/74361,MERGED,2020-07-15T12:15:22Z,2020-07-24T13:59:11Z,Improve doc theme logo display,GuillaumeGomez,38b295699f891d05d7b3dfefca3ee4a50e63d759,3,Rollup merge of #74361 - GuillaumeGomez:theme-logo r=Manishearth Improve doc theme logo display Fixes #74350. The first commit cleans up the whitespaces and converts them to tabs. We should definitely write a tidy check for this (will do it in another PR). Screenshots: ![Screenshot from 2020-07-15 14-08-25](https://user-images.githubusercontent.com/3050060/87543748-8581c800-c6a5-11ea-8417-cbf98ebbfd10.png) ![Screenshot from 2020-07-15 14-11-59](https://user-images.githubusercontent.com/3050060/87543747-84e93180-c6a5-11ea-8cea-976b1470e809.png) ![Screenshot from 2020-07-15 14-12-12](https://user-images.githubusercontent.com/3050060/87543745-84509b00-c6a5-11ea-8324-c3c46ab2d9ef.png) r? @lzutao cc @Cldfire,EYES,2020-07-15T15:45:32Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74361,MERGED,2020-07-15T12:15:22Z,2020-07-24T13:59:11Z,Improve doc theme logo display,GuillaumeGomez,38b295699f891d05d7b3dfefca3ee4a50e63d759,3,Rollup merge of #74361 - GuillaumeGomez:theme-logo r=Manishearth Improve doc theme logo display Fixes #74350. The first commit cleans up the whitespaces and converts them to tabs. We should definitely write a tidy check for this (will do it in another PR). Screenshots: ![Screenshot from 2020-07-15 14-08-25](https://user-images.githubusercontent.com/3050060/87543748-8581c800-c6a5-11ea-8417-cbf98ebbfd10.png) ![Screenshot from 2020-07-15 14-11-59](https://user-images.githubusercontent.com/3050060/87543747-84e93180-c6a5-11ea-8cea-976b1470e809.png) ![Screenshot from 2020-07-15 14-12-12](https://user-images.githubusercontent.com/3050060/87543745-84509b00-c6a5-11ea-8324-c3c46ab2d9ef.png) r? @lzutao cc @Cldfire,THUMBS_UP,2020-07-15T15:45:33Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74366,MERGED,2020-07-15T14:29:48Z,2020-09-07T13:31:06Z,Implement Seek::stream_position() for BufReader,t-rapp,9fe551ae49289ce6f693ca0dabf4c9c15164f67d,2,Auto merge of #74366 - t-rapp:tr-bufreader-pos r=LukasKalbertodt Implement Seek::stream_position() for BufReader Optimization over `BufReader::seek()` for getting the current position without flushing the internal buffer. Related to #31100. Based on the code in #70577.,HOORAY,2020-09-10T04:27:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74371,MERGED,2020-07-15T16:24:14Z,2020-07-17T03:30:34Z,Improve ayu rustdoc theme,Aloso,874097c8c7e376b2a101e69cad6a29de151eca8a,1,Rollup merge of #74371 - Aloso:patch-1 r=GuilliameGomez Improve ayu rustdoc theme This PR changes the following: * It makes some lines darker * It gives the crate selector and search bar a border * The search bar's border turns blue when focused * ~~Gives the logo a bright shadow.~~ For standard library crates it would be better to invert the logo but that would be bad for crates with a colored logo e.g. [async-std](https://docs.rs/async-std/1.6.2/async_std/). Before: ![old](https://user-images.githubusercontent.com/15658558/87576611-ed4e0800-c6d1-11ea-9667-3924702f79e2.png) After (note that this PR no longer includes the white shadow of the logo): ![new](https://user-images.githubusercontent.com/15658558/87576621-ef17cb80-c6d1-11ea-8e15-5d7f8b180c07.png),THUMBS_UP,2020-07-16T01:59:43Z,tesuji,NA https://github.com/rust-lang/rust/pull/74371,MERGED,2020-07-15T16:24:14Z,2020-07-17T03:30:34Z,Improve ayu rustdoc theme,Aloso,874097c8c7e376b2a101e69cad6a29de151eca8a,1,Rollup merge of #74371 - Aloso:patch-1 r=GuilliameGomez Improve ayu rustdoc theme This PR changes the following: * It makes some lines darker * It gives the crate selector and search bar a border * The search bar's border turns blue when focused * ~~Gives the logo a bright shadow.~~ For standard library crates it would be better to invert the logo but that would be bad for crates with a colored logo e.g. [async-std](https://docs.rs/async-std/1.6.2/async_std/). Before: ![old](https://user-images.githubusercontent.com/15658558/87576611-ed4e0800-c6d1-11ea-9667-3924702f79e2.png) After (note that this PR no longer includes the white shadow of the logo): ![new](https://user-images.githubusercontent.com/15658558/87576621-ef17cb80-c6d1-11ea-8e15-5d7f8b180c07.png),THUMBS_UP,2020-07-17T22:05:38Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T17:08:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T17:19:57Z,darksv,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T17:20:55Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T17:29:18Z,jplatte,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T18:21:25Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T18:48:08Z,pitdicker,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-15T19:10:35Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T05:54:46Z,vincent-herlemont,vincent@herlemont.fr https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T08:42:47Z,95th,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T14:16:16Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T14:26:33Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T14:56:36Z,Byron,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T14:56:40Z,elihunter173,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T15:00:27Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T15:07:06Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T15:31:31Z,sd2k,ben@bsull.io https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T15:53:06Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T18:03:19Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-16T19:29:48Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-17T05:02:26Z,coolshaurya,me@shauryashubham.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-17T05:58:48Z,wayneashleyberry,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-17T12:13:02Z,peterjoel,peterjoel@gmail.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-20T05:53:51Z,yaymukund,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-22T17:33:39Z,ritobanrc,ritobanrc@gmail.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-22T23:16:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-23T08:10:21Z,elichai,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-23T17:44:17Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-28T05:48:24Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-30T05:38:35Z,Folyd,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-30T09:46:36Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-30T12:07:33Z,RustyYato,NA https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-07-30T14:19:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-08-02T20:30:25Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2020-08-05T21:58:25Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/74373,MERGED,2020-07-15T17:05:45Z,2020-08-01T09:25:36Z,add `slice::array_chunks` to std,lcnr,b5eae9c44d713779a08e6db352088d45cad3e9b6,5,Auto merge of #74373 - lcnr:array_chunks r=withoutboats add `slice::array_chunks` to std Now that #74113 has landed these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735,HEART,2021-02-15T09:30:57Z,oilaba,NA https://github.com/rust-lang/rust/pull/74389,CLOSED,2020-07-16T08:27:20Z,2020-07-24T09:03:55Z,WIP: move the 'record all toolstates' list into rustbuild,RalfJung,NA,NA,NA,HEART,2020-07-16T09:41:56Z,mati865,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:17:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:19:35Z,lnicola,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:23:09Z,darksv,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:28:59Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:44:39Z,pachi,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T11:46:32Z,RalfJung,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T12:00:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T12:29:33Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T12:54:09Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T14:32:43Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-16T15:15:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-17T00:58:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-17T06:17:45Z,robinvd,NA https://github.com/rust-lang/rust/pull/74392,MERGED,2020-07-16T11:16:37Z,2020-07-16T22:23:12Z,const generics triage,lcnr,c354524254ca0d4e84b29a2d515a355c061cd220,13,Rollup merge of #74392 - lcnr:const-generics-update r=varkor const generics triage I went through all const generics issues and closed all issues which are already fixed. Some issues already have a regression test but were not closed. Also doing this as part of this PR. uff r? @eddyb @varkor closes #61936 closes #62878 closes #63695 closes #67144 closes #68596 closes #69816 closes #70217 closes #70507 closes #70586 closes #71348 closes #71805 closes #73120 closes #73508 closes #73730 closes #74255,HEART,2020-07-17T15:08:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/74399,MERGED,2020-07-16T15:22:51Z,2020-08-16T23:52:19Z,Move DelaySpanBugEmitted to ty::context,mark-i-m,54c74345b4cffbe2c490b79cfda5647897084d00,4,Rollup merge of #74399 - mark-i-m:ty-err-4 r=eddyb Move DelaySpanBugEmitted to ty::context This makes it even hard to abuse. r? @eddyb cc @LeSeulArtichaut as this will probably conflict with your PR :/,HEART,2020-07-17T17:03:34Z,estebank,NA https://github.com/rust-lang/rust/pull/74411,MERGED,2020-07-16T21:11:12Z,2020-07-18T00:27:56Z,Don't assign `()` to `!` MIR locals,jonas-schievink,87d01d11e17e497b3ec43559cbeee3ad704603ee,2,Rollup merge of #74411 - jonas-schievink:unbreak-mir r=matthewjasper Don't assign `()` to `!` MIR locals Implements the fix described in https://github.com/rust-lang/rust/issues/73860#issuecomment-651731893. Fixes https://github.com/rust-lang/rust/issues/73860 r? @matthewjasper,HOORAY,2020-07-17T17:01:19Z,estebank,NA https://github.com/rust-lang/rust/pull/74411,MERGED,2020-07-16T21:11:12Z,2020-07-18T00:27:56Z,Don't assign `()` to `!` MIR locals,jonas-schievink,87d01d11e17e497b3ec43559cbeee3ad704603ee,2,Rollup merge of #74411 - jonas-schievink:unbreak-mir r=matthewjasper Don't assign `()` to `!` MIR locals Implements the fix described in https://github.com/rust-lang/rust/issues/73860#issuecomment-651731893. Fixes https://github.com/rust-lang/rust/issues/73860 r? @matthewjasper,HOORAY,2020-07-22T09:37:26Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74412,CLOSED,2020-07-16T22:42:18Z,2020-07-17T07:47:12Z,Rollup of 9 pull requests,Manishearth,NA,NA,NA,ROCKET,2020-07-16T22:43:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74415,CLOSED,2020-07-16T22:56:19Z,2020-07-17T00:10:10Z,Rollup of 9 pull requests,Manishearth,NA,NA,NA,ROCKET,2020-07-16T22:58:03Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HEART,2020-07-17T00:08:30Z,estebank,NA https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HOORAY,2020-07-17T07:56:43Z,iago-lito,NA https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HEART,2020-07-17T19:36:59Z,parasyte,jay@kodewerx.org https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HEART,2020-07-19T21:35:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HOORAY,2020-10-04T05:26:40Z,yerke,NA https://github.com/rust-lang/rust/pull/74419,MERGED,2020-07-16T23:31:24Z,2020-07-19T18:22:14Z,Add a thumbv4t-none-eabi target,Lokathor,90164587dcd7290ba46ac7b5ae054c849bc8c551,2,Rollup merge of #74419 - Lokathor:gba-target r=jonas-schievink Add a thumbv4t-none-eabi target (cc @ketsuban one of the few other Rust users who programs for GBA.) --- **EDIT:** This is now a more general `thumbv4t-none-eabi` PR! See [this comment](https://github.com/rust-lang/rust/pull/74419#issuecomment-660391579) --- Now that the PSP officially has an official target within Rust well as the lead of the `gba` crate I can't _not_ add a GBA target as well. I know that the [target tier policy](https://github.com/rust-lang/rfcs/pull/2803) isn't ratified and official but I'll use it as an outline (cc @joshtriplett): * Designated Developer: Lokathor * Naming consistent with any existing targets * Doesn't create Rust project legal issues. * No license issues * Uses the standard Apache/mit license. * Rust tooling users don't have to accept any new licensing requirements * Does not support hosting rust tooling. * Doesn't require linking in proprietary code to obtain a functional binary. However you will need to do some post-build steps to turn the ELF file into a usable GBA ROM (either for an emulator or for the actual hardware). * This is a `no_std` environment without even a standard global allocator so this adds no new code to `alloc` or `std`. * The process of building for this target is documented in the `gba` crate ([link](https://rust-console.github.io/gba/development-setup.html)). Well the docs there are currently a little out of date they're back on using `cargo-xbuild` but the crate docs there will get updated once this target is available. * This places no new burden on any other targets * Does not break any existing targets. I'm not fully confident in specifying the same linker script for all possible projects so I'm currently just not giving a linker script at all and users can continue to select their own linker script by using `-C` to provide a linker arg. I added the file and added it to the `supported_targets!` macro usage and I think that's all there is to do.,HEART,2020-10-04T05:26:40Z,yerke,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T07:20:46Z,killercup,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T07:20:59Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T08:31:48Z,Heliozoa,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T09:33:55Z,mcarton,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-07-17T09:43:29Z,killercup,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T09:51:30Z,pragmatrix,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T10:50:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T11:05:32Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T12:41:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-07-17T13:07:35Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T13:55:17Z,jonnadal,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T13:56:24Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-07-17T18:54:23Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T19:01:39Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-17T23:46:12Z,tmandry,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-19T07:20:43Z,bugadani,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-19T21:18:29Z,mitsuhiko,armin.ronacher@active-4.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-07-19T23:31:50Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-19T23:31:51Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,EYES,2020-07-19T23:31:52Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,EYES,2020-07-20T23:29:52Z,QuietMisdreavus,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-21T00:14:51Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-07-21T09:08:55Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-27T03:03:29Z,billyrieger,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-07-31T11:32:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-01T22:49:43Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-08-01T22:49:43Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,EYES,2020-08-01T22:49:44Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-03T02:43:54Z,karlmdavis,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-05T07:49:27Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-08-05T07:49:31Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-06T08:38:16Z,slinkydeveloper,francescoguard@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-27T20:04:05Z,est31,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-08-27T21:25:57Z,yaymukund,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-08-27T21:25:58Z,yaymukund,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,EYES,2020-09-02T13:19:25Z,rostyslavb,rostyslav.db@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-03T18:48:03Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-03T19:18:03Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-04T12:16:01Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-09-04T12:16:04Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-04T12:34:48Z,Owez,root@ogriffiths.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-06T02:21:06Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-09T17:01:06Z,Purpzie,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-11T19:38:19Z,Yura52,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,ROCKET,2020-09-14T01:25:46Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-09-14T01:25:49Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-14T01:42:25Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-09-16T06:40:34Z,alexlapa,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-17T04:06:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-09-17T04:06:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-09-17T13:35:47Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-10-06T02:45:50Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-10-12T02:48:31Z,camelid,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-11-19T20:09:02Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-11-19T20:09:02Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,ROCKET,2020-11-19T20:09:03Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HEART,2020-12-18T13:36:33Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/74430,MERGED,2020-07-17T07:19:52Z,2020-09-24T05:58:43Z,Stabilize intra-doc links,Manishearth,78a089487b5f6d5e4205ac4500410b442857bced,5,Auto merge of #74430 - Manishearth:stabilize-intra-doc r=Manishearth Stabilize intra-doc links Fixes https://github.com/rust-lang/rust/issues/43466 Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed I think we're now in a position to stabilize this feature. The tracking issue currently has two unresolved issues: - behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365 which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway. - Non-identifier primitive types like slices: This was not a part of the original RFC anyway and is a pretty niche use case The feature itself sans https://github.com/rust-lang/rust/issues/65983 has been shipped on nightly for three years now with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve and we did not want to stabilize something that had such a potentially unfixable bug. Given that we've fixed it I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems however we _have_ done crater runs of some of the crucial parts. Furthermore that's what the release trains are for we will have a solid three months to let it ride the trains before it actually hits the stable compiler. r? `@rust-lang/rustdoc`,HOORAY,2020-12-18T13:36:34Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/74438,MERGED,2020-07-17T13:04:23Z,2020-07-18T00:27:51Z,warn about uninitialized multi-variant enums (invalid_value lint),RalfJung,cdedae82cc51c3f9a022643dfdc46584b77651f1,3,Rollup merge of #74438 - RalfJung:uninit-lint r=davidtwco warn about uninitialized multi-variant enums Fixes https://github.com/rust-lang/rust/issues/73608,HEART,2020-07-17T13:36:06Z,tesuji,NA https://github.com/rust-lang/rust/pull/74444,MERGED,2020-07-17T14:46:30Z,2020-07-18T16:08:31Z,Add regression test for #69414,Alexendoo,378f46d1f2908014aa908f5c9823a44fd0a57c80,2,Rollup merge of #74444 - Alexendoo:test-69414 r=nikomatsakis Add regression test for #69414 Closes #69414 (no longer ICEs after #74159),HEART,2020-07-17T17:21:25Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-07-18T18:27:49Z,YohDeadfall,yoh.deadfall@hotmail.com https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-07-18T20:19:05Z,emmanuelantony2000,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-07-24T12:25:09Z,krircc,krircc@qq.com https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-07-28T03:30:35Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-17T22:24:33Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-18T04:12:01Z,glitzflitz,ameynarkhede03@gmail.com https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-18T04:51:22Z,95th,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-18T11:17:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-18T15:47:16Z,repi,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-18T23:35:33Z,brian-gavin,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-23T04:55:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-23T16:44:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-24T11:16:45Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/74480,MERGED,2020-07-18T15:47:32Z,2020-10-18T04:32:39Z,Add `std::thread::available_concurrency`,yoshuawuyts,c38ddb8040edce1b05bc09a0e8439472e9f67623,4,"Auto merge of #74480 - yoshuawuyts:hardware_threads r=dtolnay Add std::thread::available_concurrency This PR adds a counterpart to [C++'s `std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) to Rust tracking issue https://github.com/rust-lang/rust/issues/74479. cc/ `@rust-lang/libs` ## Motivation Being able to know how many hardware threads a platform supports is a core part of building multi-threaded code. In C++ 11 this has become available through the [`std::thread::hardware_concurrency`](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency) API. Currently in Rust most of the ecosystem depends on the [`num_cpus` crate](https://docs.rs/num_cpus/1.13.0/num_cpus/) ([no.35 in top 500 crates](https://docs.google.com/spreadsheets/d/1wwahRMHG3buvnfHjmPQFU4Kyfq15oTwbfsuZpwHUKc4/edit#gid=1253069234)) to provide this functionality. This PR proposes an API to provide access to the number of hardware threads available on a given platform. __edit (2020-07-24):__ The purpose of this PR is to provide a hint for how many threads to spawn to saturate the processor. There's value in introducing APIs for NUMA and Windows processor groups but those are intentionally out of scope for this PR. See: https://github.com/rust-lang/rust/pull/74480#issuecomment-662116186. ## Naming Discussing the naming of the API on Zulip surfaced two options: - `std::thread::hardware_concurrency` - `std::thread::hardware_threads` Both options seemed acceptable but overall people seem to gravitate the most towards `hardware_threads`. Additionally `@jonas-schievink` pointed out that the ""hardware threads"" terminology is well-established and is used in among other the [RISC-V specification](https://riscv.org/specifications/isa-spec-pdf/) (page 20): > A component is termed a core if it contains an independent instruction fetch unit. A RISC-V-compatible core might support multiple RISC-V-compatible __hardware threads__ or harts through multithreading. It's also worth noting that [the original paper introducing C++'s `std::thread` submodule](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2320.html) unfortunately doesn't feature any discussion on the naming of `hardware_concurrency` so we can't use that to help inform our decision here. ## Return type An important consideration `@joshtriplett` brought up is that we don't want to default to `1` for platforms where the number of available threads cannot be retrieved. Instead we want to inform the users of the fact that we don't know and allow them to handle that case. Which is why this PR uses `Option` as its return type where `None` is returned on platforms where we don't know the number of hardware threads available. The reasoning for `NonZeroUsize` vs `usize` is that if the number of threads for a platform are known they'll always be at least 1. As evidenced by the example the `NonZero*` family of APIs may currently not be the most ergonomic to use but improving the ergonomics of them is something that I think we can address separately. ## Implementation `@Mark-Simulacrum` pointed out that most of the code we wanted to expose here was already available under `libtest`. So this PR mostly moves the internal code of libtest into a public API.",HEART,2020-10-28T20:28:28Z,alexlapa,NA https://github.com/rust-lang/rust/pull/74491,MERGED,2020-07-18T22:53:04Z,2020-07-24T20:01:07Z,Optimize away BitAnd and BitOr when possible,xldenis,e59effed3037701aadab11d4ea0ddddf2eedbf3b,7,Rollup merge of #74491 - xldenis:constant-binop-opt r=oli-obk Optimize away BitAnd and BitOr when possible This PR lets `const_prop` optimize away `a | true == true` `a & false == false` and `a * 0 = 0`. While I was writing this I've realized that constant propagation misses a lot of opportunities. For example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2a4b45e772f214210a36749b27223bb0 Constant propagation doesn't seem to... propagate constants additionally the way constant propagation is currently setup makes it tricky to add cases like `a | false == a`. I tried to organize `eval_rvalue_with_identities` to make the pattern of the optimizations easier to see but it still obscurs what should be a simple peephole optmization. cc @oli-obk,HOORAY,2020-07-31T01:43:37Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,ROCKET,2020-07-19T09:54:46Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,ROCKET,2020-07-19T20:58:20Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,ROCKET,2020-07-23T08:23:57Z,elichai,NA https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,ROCKET,2020-08-08T13:37:28Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,HEART,2020-08-08T13:37:30Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,ROCKET,2021-07-19T19:36:26Z,lukechu10,NA https://github.com/rust-lang/rust/pull/74492,CLOSED,2020-07-18T23:06:06Z,2020-09-11T14:12:18Z,Support `#[track_caller]` on closures.,anp,NA,NA,NA,HEART,2021-07-19T19:36:26Z,lukechu10,NA https://github.com/rust-lang/rust/pull/74505,MERGED,2020-07-19T06:02:22Z,2020-07-21T01:24:10Z,Fix search input focus in ayu theme,Cldfire,6467f6f494b79cf2125204b6d192ace5cc3c1e87,1,Rollup merge of #74505 - Cldfire:fix-search-focus r=GuillaumeGomez Fix search input focus in ayu theme Closes #74496. Before: ![image](https://user-images.githubusercontent.com/13814214/87868463-d0c8fe80-c963-11ea-9003-aa578d869e98.png) After: ![image](https://user-images.githubusercontent.com/13814214/87868467-dc1c2a00-c963-11ea-89a8-1280f68ff9df.png),THUMBS_UP,2020-07-19T06:18:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/74505,MERGED,2020-07-19T06:02:22Z,2020-07-21T01:24:10Z,Fix search input focus in ayu theme,Cldfire,6467f6f494b79cf2125204b6d192ace5cc3c1e87,1,Rollup merge of #74505 - Cldfire:fix-search-focus r=GuillaumeGomez Fix search input focus in ayu theme Closes #74496. Before: ![image](https://user-images.githubusercontent.com/13814214/87868463-d0c8fe80-c963-11ea-9003-aa578d869e98.png) After: ![image](https://user-images.githubusercontent.com/13814214/87868467-dc1c2a00-c963-11ea-89a8-1280f68ff9df.png),HEART,2020-07-19T08:01:49Z,MajorBreakfast,NA https://github.com/rust-lang/rust/pull/74505,MERGED,2020-07-19T06:02:22Z,2020-07-21T01:24:10Z,Fix search input focus in ayu theme,Cldfire,6467f6f494b79cf2125204b6d192ace5cc3c1e87,1,Rollup merge of #74505 - Cldfire:fix-search-focus r=GuillaumeGomez Fix search input focus in ayu theme Closes #74496. Before: ![image](https://user-images.githubusercontent.com/13814214/87868463-d0c8fe80-c963-11ea-9003-aa578d869e98.png) After: ![image](https://user-images.githubusercontent.com/13814214/87868467-dc1c2a00-c963-11ea-89a8-1280f68ff9df.png),THUMBS_UP,2020-07-20T01:48:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74512,MERGED,2020-07-19T12:06:30Z,2020-08-13T01:24:35Z,Put panic code path from `copy_from_slice` into cold function,LukasKalbertodt,847ba835ce411d47364a93ddf0b4a5c0f27928a9,2,Auto merge of #74512 - LukasKalbertodt:debloat-copy-from-slice r=KodrAus Put panic code path from `copy_from_slice` into cold function The previous `assert_eq` generated quite some code which is especially problematic when this call is inlined. This commit also slightly improves the panic message from: assertion failed: `(left == right)` left: `3` right: `2`: destination and source slices have different lengths ...to: source slice length (2) does not match destination slice length (3) You can see the code bloat in assembly [here](https://rust.godbolt.org/z/74a3qo).,HEART,2020-07-19T12:50:29Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74512,MERGED,2020-07-19T12:06:30Z,2020-08-13T01:24:35Z,Put panic code path from `copy_from_slice` into cold function,LukasKalbertodt,847ba835ce411d47364a93ddf0b4a5c0f27928a9,2,Auto merge of #74512 - LukasKalbertodt:debloat-copy-from-slice r=KodrAus Put panic code path from `copy_from_slice` into cold function The previous `assert_eq` generated quite some code which is especially problematic when this call is inlined. This commit also slightly improves the panic message from: assertion failed: `(left == right)` left: `3` right: `2`: destination and source slices have different lengths ...to: source slice length (2) does not match destination slice length (3) You can see the code bloat in assembly [here](https://rust.godbolt.org/z/74a3qo).,THUMBS_UP,2020-07-19T13:00:08Z,tesuji,NA https://github.com/rust-lang/rust/pull/74512,MERGED,2020-07-19T12:06:30Z,2020-08-13T01:24:35Z,Put panic code path from `copy_from_slice` into cold function,LukasKalbertodt,847ba835ce411d47364a93ddf0b4a5c0f27928a9,2,Auto merge of #74512 - LukasKalbertodt:debloat-copy-from-slice r=KodrAus Put panic code path from `copy_from_slice` into cold function The previous `assert_eq` generated quite some code which is especially problematic when this call is inlined. This commit also slightly improves the panic message from: assertion failed: `(left == right)` left: `3` right: `2`: destination and source slices have different lengths ...to: source slice length (2) does not match destination slice length (3) You can see the code bloat in assembly [here](https://rust.godbolt.org/z/74a3qo).,THUMBS_UP,2020-07-20T09:30:17Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74512,MERGED,2020-07-19T12:06:30Z,2020-08-13T01:24:35Z,Put panic code path from `copy_from_slice` into cold function,LukasKalbertodt,847ba835ce411d47364a93ddf0b4a5c0f27928a9,2,Auto merge of #74512 - LukasKalbertodt:debloat-copy-from-slice r=KodrAus Put panic code path from `copy_from_slice` into cold function The previous `assert_eq` generated quite some code which is especially problematic when this call is inlined. This commit also slightly improves the panic message from: assertion failed: `(left == right)` left: `3` right: `2`: destination and source slices have different lengths ...to: source slice length (2) does not match destination slice length (3) You can see the code bloat in assembly [here](https://rust.godbolt.org/z/74a3qo).,THUMBS_UP,2020-08-21T06:52:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74533,MERGED,2020-07-19T19:04:21Z,2020-08-08T15:20:28Z,Emit == null instead of <= null for niche check,nikic,2bac92bba14f3b260b337d2a51c77c0780456e65,2,"Auto merge of #74533 - nikic:issue-74425 r=eddyb Emit == null instead of <= null for niche check When the niche maximum is zero emit a ""== zero"" check instead of a ""<= zero"" check. In particular this avoids the awkward case of ""<= null"". While LLVM does canonicalize this to ""== null"" this apparently doesn't happen for constant expressions leading to the issue in #74425. While that can be addressed on the LLVM side it still seems prudent to emit sensible IR here because this will allow null checks to be optimized earlier in the pipeline. Fixes #74425.",ROCKET,2020-07-19T22:44:01Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74533,MERGED,2020-07-19T19:04:21Z,2020-08-08T15:20:28Z,Emit == null instead of <= null for niche check,nikic,2bac92bba14f3b260b337d2a51c77c0780456e65,2,"Auto merge of #74533 - nikic:issue-74425 r=eddyb Emit == null instead of <= null for niche check When the niche maximum is zero emit a ""== zero"" check instead of a ""<= zero"" check. In particular this avoids the awkward case of ""<= null"". While LLVM does canonicalize this to ""== null"" this apparently doesn't happen for constant expressions leading to the issue in #74425. While that can be addressed on the LLVM side it still seems prudent to emit sensible IR here because this will allow null checks to be optimized earlier in the pipeline. Fixes #74425.",ROCKET,2020-07-20T14:42:36Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/74533,MERGED,2020-07-19T19:04:21Z,2020-08-08T15:20:28Z,Emit == null instead of <= null for niche check,nikic,2bac92bba14f3b260b337d2a51c77c0780456e65,2,"Auto merge of #74533 - nikic:issue-74425 r=eddyb Emit == null instead of <= null for niche check When the niche maximum is zero emit a ""== zero"" check instead of a ""<= zero"" check. In particular this avoids the awkward case of ""<= null"". While LLVM does canonicalize this to ""== null"" this apparently doesn't happen for constant expressions leading to the issue in #74425. While that can be addressed on the LLVM side it still seems prudent to emit sensible IR here because this will allow null checks to be optimized earlier in the pipeline. Fixes #74425.",THUMBS_UP,2020-07-20T14:43:43Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/74533,MERGED,2020-07-19T19:04:21Z,2020-08-08T15:20:28Z,Emit == null instead of <= null for niche check,nikic,2bac92bba14f3b260b337d2a51c77c0780456e65,2,"Auto merge of #74533 - nikic:issue-74425 r=eddyb Emit == null instead of <= null for niche check When the niche maximum is zero emit a ""== zero"" check instead of a ""<= zero"" check. In particular this avoids the awkward case of ""<= null"". While LLVM does canonicalize this to ""== null"" this apparently doesn't happen for constant expressions leading to the issue in #74425. While that can be addressed on the LLVM side it still seems prudent to emit sensible IR here because this will allow null checks to be optimized earlier in the pipeline. Fixes #74425.",ROCKET,2020-08-02T07:09:44Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74533,MERGED,2020-07-19T19:04:21Z,2020-08-08T15:20:28Z,Emit == null instead of <= null for niche check,nikic,2bac92bba14f3b260b337d2a51c77c0780456e65,2,"Auto merge of #74533 - nikic:issue-74425 r=eddyb Emit == null instead of <= null for niche check When the niche maximum is zero emit a ""== zero"" check instead of a ""<= zero"" check. In particular this avoids the awkward case of ""<= null"". While LLVM does canonicalize this to ""== null"" this apparently doesn't happen for constant expressions leading to the issue in #74425. While that can be addressed on the LLVM side it still seems prudent to emit sensible IR here because this will allow null checks to be optimized earlier in the pipeline. Fixes #74425.",THUMBS_UP,2020-08-02T07:09:45Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74535,CLOSED,2020-07-19T21:17:38Z,2020-10-17T13:57:48Z,[WIP] Tracking all the unsolved variables that was assigned `!` type because of fallback,blitzerr,NA,NA,NA,HOORAY,2020-07-21T21:42:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-20T01:19:24Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-07-20T01:43:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-07-20T02:27:59Z,yerke,NA https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-20T02:28:03Z,yerke,NA https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HEART,2020-07-20T10:24:54Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-07-20T10:35:49Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-20T15:26:36Z,raw-bin,NA https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HEART,2020-07-20T16:01:29Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-20T20:41:41Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-07-20T20:41:42Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HEART,2020-07-20T20:41:42Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-21T07:12:14Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-07-21T07:12:15Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HEART,2020-07-21T07:12:16Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-07-22T06:58:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-10-15T17:52:47Z,rail-ka,r@33.run https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,THUMBS_UP,2020-11-19T15:24:33Z,styfle,NA https://github.com/rust-lang/rust/pull/74541,MERGED,2020-07-20T00:58:09Z,2020-07-23T02:58:22Z,Add the aarch64-apple-darwin target ,shepmaster,8114dc7a4ad24315389ea3199a37abc6208ca876,5,Rollup merge of #74541 - shepmaster:aarch64-apple-darwin-target r=nagisa Add the aarch64-apple-darwin target This is a basic copy-paste-modify from the existing x86_64-apple-darwin target.,HOORAY,2020-11-19T15:24:34Z,styfle,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-20T12:03:58Z,waldyrious,waldyrious@gmail.com https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-20T12:07:08Z,khyperia,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-20T12:20:12Z,winston-yallow,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-20T12:47:40Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-20T14:30:11Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-21T01:27:42Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-22T20:14:27Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-07-22T20:27:50Z,lqd,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-08-19T11:16:31Z,Aurora2500,NA https://github.com/rust-lang/rust/pull/74552,MERGED,2020-07-20T12:01:54Z,2020-07-21T01:24:02Z,Stabilize TAU constant.,m-ou-se,810d322366bd5c0b04ee509db03311a36636c5a2,2,Rollup merge of #74552 - fusion-engineering-forks:stabilize-tau r=dtolnay Stabilize TAU constant. Closes #66770.,HOORAY,2020-08-22T12:12:49Z,anderejd,NA https://github.com/rust-lang/rust/pull/74555,MERGED,2020-07-20T12:41:34Z,2020-07-21T01:24:00Z,"Improve ""important traits"" popup display on mobile",GuillaumeGomez,963b837a837a4c49086bb2f3b5d2ac0789dcf69c,1,"Rollup merge of #74555 - GuillaumeGomez:important-traits-popup r=Manishearth Improve ""important traits"" popup display on mobile I implemented what @XAMPPRocky suggested in the [internals thread topic](https://internals.rust-lang.org/t/feedback-on-important-traits-rustdoc-feature/12752/18). I can confirm it works nicely. r? @Manishearth @Manishearth: By the way: I realized that when you click on the ""i"" you have to click again to make the popup disappear. Do you want me to extend the popup removal to any click outside the popup?",THUMBS_UP,2020-07-20T13:54:09Z,XAMPPRocky,NA https://github.com/rust-lang/rust/pull/74559,MERGED,2020-07-20T14:00:34Z,2020-09-01T20:04:56Z,Stabilize deque_make_contiguous,jonhoo,eb9e7c357e26bf41c47661720e46f4498de32b83,1,Auto merge of #74559 - jonhoo:stabilize-vecdeque-make_contiguous r=dtolnay Stabilize deque_make_contiguous Closes #70929. /cc @Amanieu,HEART,2020-07-20T14:06:53Z,95th,NA https://github.com/rust-lang/rust/pull/74559,MERGED,2020-07-20T14:00:34Z,2020-09-01T20:04:56Z,Stabilize deque_make_contiguous,jonhoo,eb9e7c357e26bf41c47661720e46f4498de32b83,1,Auto merge of #74559 - jonhoo:stabilize-vecdeque-make_contiguous r=dtolnay Stabilize deque_make_contiguous Closes #70929. /cc @Amanieu,HOORAY,2020-07-20T14:06:56Z,95th,NA https://github.com/rust-lang/rust/pull/74559,MERGED,2020-07-20T14:00:34Z,2020-09-01T20:04:56Z,Stabilize deque_make_contiguous,jonhoo,eb9e7c357e26bf41c47661720e46f4498de32b83,1,Auto merge of #74559 - jonhoo:stabilize-vecdeque-make_contiguous r=dtolnay Stabilize deque_make_contiguous Closes #70929. /cc @Amanieu,HOORAY,2020-07-21T06:12:59Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/74559,MERGED,2020-07-20T14:00:34Z,2020-09-01T20:04:56Z,Stabilize deque_make_contiguous,jonhoo,eb9e7c357e26bf41c47661720e46f4498de32b83,1,Auto merge of #74559 - jonhoo:stabilize-vecdeque-make_contiguous r=dtolnay Stabilize deque_make_contiguous Closes #70929. /cc @Amanieu,HOORAY,2020-09-10T04:26:11Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74559,MERGED,2020-07-20T14:00:34Z,2020-09-01T20:04:56Z,Stabilize deque_make_contiguous,jonhoo,eb9e7c357e26bf41c47661720e46f4498de32b83,1,Auto merge of #74559 - jonhoo:stabilize-vecdeque-make_contiguous r=dtolnay Stabilize deque_make_contiguous Closes #70929. /cc @Amanieu,HEART,2020-09-10T04:26:12Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74562,MERGED,2020-07-20T15:14:34Z,2020-08-17T01:58:37Z,Remove branch in optimized is_ascii,pickfire,4bb4b96ee7eef87134293ff7e4c02f699b805d5e,1,Auto merge of #74562 - pickfire:is_ascii_branchless r=nagisa Remove branch in optimized is_ascii Performs slightly better in short or medium bytes by eliminating the last branch check on `byte_pos == len` and always check the last byte as it is always at most one `usize`. Benchmark before `libcore` after `libcore_new`. It improves medium and short by 1ns but regresses unaligned_tail by 2ns either way we can get unaligned_tail have a tiny chance of 1/8 on a 64 bit machine. I don't think we should bet on that the probability is worse than dice. ``` test long::case00_libcore ... bench: 38 ns/iter (+/- 1) = 183947 MB/s test long::case00_libcore_new ... bench: 38 ns/iter (+/- 1) = 183947 MB/s test long::case01_iter_all ... bench: 227 ns/iter (+/- 6) = 30792 MB/s test long::case02_align_to ... bench: 40 ns/iter (+/- 1) = 174750 MB/s test long::case03_align_to_unrolled ... bench: 19 ns/iter (+/- 1) = 367894 MB/s test medium::case00_libcore ... bench: 5 ns/iter (+/- 0) = 6400 MB/s test medium::case00_libcore_new ... bench: 4 ns/iter (+/- 0) = 8000 MB/s test medium::case01_iter_all ... bench: 20 ns/iter (+/- 1) = 1600 MB/s test medium::case02_align_to ... bench: 6 ns/iter (+/- 0) = 5333 MB/s test medium::case03_align_to_unrolled ... bench: 5 ns/iter (+/- 0) = 6400 MB/s test short::case00_libcore ... bench: 7 ns/iter (+/- 0) = 1000 MB/s test short::case00_libcore_new ... bench: 6 ns/iter (+/- 0) = 1166 MB/s test short::case01_iter_all ... bench: 5 ns/iter (+/- 0) = 1400 MB/s test short::case02_align_to ... bench: 5 ns/iter (+/- 0) = 1400 MB/s test short::case03_align_to_unrolled ... bench: 5 ns/iter (+/- 1) = 1400 MB/s test unaligned_both::case00_libcore ... bench: 4 ns/iter (+/- 0) = 7500 MB/s test unaligned_both::case00_libcore_new ... bench: 4 ns/iter (+/- 0) = 7500 MB/s test unaligned_both::case01_iter_all ... bench: 26 ns/iter (+/- 0) = 1153 MB/s test unaligned_both::case02_align_to ... bench: 13 ns/iter (+/- 2) = 2307 MB/s test unaligned_both::case03_align_to_unrolled ... bench: 11 ns/iter (+/- 0) = 2727 MB/s test unaligned_head::case00_libcore ... bench: 5 ns/iter (+/- 0) = 6200 MB/s test unaligned_head::case00_libcore_new ... bench: 5 ns/iter (+/- 0) = 6200 MB/s test unaligned_head::case01_iter_all ... bench: 19 ns/iter (+/- 1) = 1631 MB/s test unaligned_head::case02_align_to ... bench: 10 ns/iter (+/- 0) = 3100 MB/s test unaligned_head::case03_align_to_unrolled ... bench: 14 ns/iter (+/- 0) = 2214 MB/s test unaligned_tail::case00_libcore ... bench: 3 ns/iter (+/- 0) = 10333 MB/s test unaligned_tail::case00_libcore_new ... bench: 5 ns/iter (+/- 0) = 6200 MB/s test unaligned_tail::case01_iter_all ... bench: 19 ns/iter (+/- 0) = 1631 MB/s test unaligned_tail::case02_align_to ... bench: 10 ns/iter (+/- 0) = 3100 MB/s test unaligned_tail::case03_align_to_unrolled ... bench: 13 ns/iter (+/- 0) = 2384 MB/s ``` Rough (unfair) maths on improvements for fun: 1ns * 7/8 - 2ns * 1/8 = 0.625ns Inspired by fish and zsh clever trick to highlight missing linefeeds (⏎) and branchless implementation of binary_search in rust. cc @thomcc https://github.com/rust-lang/rust/pull/74066 r? @nagisa,ROCKET,2020-07-21T05:48:54Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/74565,MERGED,2020-07-20T15:47:11Z,2020-07-22T02:52:06Z,Upload builds from GHA instead of Azure Pipelines,pietroalbini,aca77cdd8ff05218318a7ba7f750984ba48eb1f3,5,Auto merge of #74565 - pietroalbini:build-on-gha r=Mark-Simulacrum Upload builds from GHA instead of Azure Pipelines This PR does two things: * Enables RLA comments on PRs (needed after the switch to GHA in RLA). * Switches GitHub Actions as the CI authorized to upload non-macOS builds. Note that Docker/LLVM caches will likely be busted. r? @Mark-Simulacrum,HOORAY,2020-07-21T21:34:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74565,MERGED,2020-07-20T15:47:11Z,2020-07-22T02:52:06Z,Upload builds from GHA instead of Azure Pipelines,pietroalbini,aca77cdd8ff05218318a7ba7f750984ba48eb1f3,5,Auto merge of #74565 - pietroalbini:build-on-gha r=Mark-Simulacrum Upload builds from GHA instead of Azure Pipelines This PR does two things: * Enables RLA comments on PRs (needed after the switch to GHA in RLA). * Switches GitHub Actions as the CI authorized to upload non-macOS builds. Note that Docker/LLVM caches will likely be busted. r? @Mark-Simulacrum,HOORAY,2020-07-21T21:46:30Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/74565,MERGED,2020-07-20T15:47:11Z,2020-07-22T02:52:06Z,Upload builds from GHA instead of Azure Pipelines,pietroalbini,aca77cdd8ff05218318a7ba7f750984ba48eb1f3,5,Auto merge of #74565 - pietroalbini:build-on-gha r=Mark-Simulacrum Upload builds from GHA instead of Azure Pipelines This PR does two things: * Enables RLA comments on PRs (needed after the switch to GHA in RLA). * Switches GitHub Actions as the CI authorized to upload non-macOS builds. Note that Docker/LLVM caches will likely be busted. r? @Mark-Simulacrum,HOORAY,2020-07-22T13:57:25Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74565,MERGED,2020-07-20T15:47:11Z,2020-07-22T02:52:06Z,Upload builds from GHA instead of Azure Pipelines,pietroalbini,aca77cdd8ff05218318a7ba7f750984ba48eb1f3,5,Auto merge of #74565 - pietroalbini:build-on-gha r=Mark-Simulacrum Upload builds from GHA instead of Azure Pipelines This PR does two things: * Enables RLA comments on PRs (needed after the switch to GHA in RLA). * Switches GitHub Actions as the CI authorized to upload non-macOS builds. Note that Docker/LLVM caches will likely be busted. r? @Mark-Simulacrum,HOORAY,2020-07-27T14:54:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74566,MERGED,2020-07-20T16:55:18Z,2020-08-22T18:12:39Z,Gate if-let guard feature,tesuji,5528caf91442729b47b8f818be0a0ddfd0c17ffb,7,Auto merge of #74566 - lzutao:guard r=petrochenkov Gate if-let guard feature Enhanced on #74315. That PR is in crater queue so I don't want to push to it. Close #74232 cc #51114,THUMBS_UP,2020-07-20T19:08:05Z,estebank,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-20T17:26:57Z,jam1garner,jam@jam1.re https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-20T18:16:38Z,Tarnadas,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-20T18:18:09Z,jakibaki,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-20T18:22:46Z,friedkeenan,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-21T04:23:22Z,dylanhilton,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-07-21T23:11:37Z,XorTroll,NA https://github.com/rust-lang/rust/pull/74567,CLOSED,2020-07-20T17:20:12Z,2020-11-03T04:47:07Z,Add aarch64-unknown-switch-libnx target,leo60228,NA,NA,NA,THUMBS_UP,2020-09-06T08:51:52Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/74570,MERGED,2020-07-20T19:31:34Z,2020-07-22T18:17:11Z,Use forge links for prioritization procedure,spastorino,2bf54990a45dcf85626f2a2ab609770558107884,1,Rollup merge of #74570 - spastorino:fix-prioritization-procedures-links r=Mark-Simulacrum Use forge links for prioritization procedure r? @Mark-Simulacrum cc @rust-lang/wg-prioritization,THUMBS_UP,2020-07-20T20:00:28Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74572,MERGED,2020-07-20T20:34:48Z,2020-07-24T13:58:58Z,Internally unify rustc_deprecated and deprecated,Mark-Simulacrum,0651dd4aab491709ad8387190f3b3f2b8457f7a3,10,"Rollup merge of #74572 - Mark-Simulacrum:unify-rustc-depr r=petrochenkov Internally unify rustc_deprecated and deprecated This PR intentionally tries to be ""featureless"" in that the behavior is not altered for either attribute though it more clearly exposes cases where that is the case in the code.",HEART,2020-07-20T20:45:29Z,panaman67,NA https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T06:07:51Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T06:08:07Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T06:50:30Z,oeble,NA https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T07:18:03Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T12:10:24Z,dheatovwil,ttay0007@student.monash.edu https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T13:18:24Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-21T22:14:52Z,jamestmartin,james@jtmar.me https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-22T10:34:04Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-07-22T22:54:19Z,Caduser2020,NA https://github.com/rust-lang/rust/pull/74578,MERGED,2020-07-21T02:51:30Z,2020-07-22T05:50:01Z,Fix rust-src component.,ehuss,4825e12fc9c79954aa0fe18f5521efa6c19c7539,1,Auto merge of #74578 - ehuss:fix-rust-src r=Mark-Simulacrum Fix rust-src component. The rust-src component could not be installed by rustup because it included some symbolic links. #74520 added the backtrace directory which included some symlinks. Since the rust-src component doesn't need most of the files in the `backtrace` submodule this changes it to only include the minimum necessary. Tested with cargo's build-std that it can build from the resulting tarball. Fixes #74577,THUMBS_UP,2020-08-10T23:57:55Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74582,MERGED,2020-07-21T09:33:26Z,2020-08-01T11:25:54Z,Rename HAIR to THIR (Typed HIR).,Lezzz,dfe1e3b641abbede6230e3931d14f0d43e5b8e54,36,Auto merge of #74582 - Lezzz:rename-hair r=nikomatsakis Rename HAIR to THIR (Typed HIR). r? @nikomatsakis Originally suggested by @eddyb,THUMBS_UP,2020-07-21T14:52:40Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74582,MERGED,2020-07-21T09:33:26Z,2020-08-01T11:25:54Z,Rename HAIR to THIR (Typed HIR).,Lezzz,dfe1e3b641abbede6230e3931d14f0d43e5b8e54,36,Auto merge of #74582 - Lezzz:rename-hair r=nikomatsakis Rename HAIR to THIR (Typed HIR). r? @nikomatsakis Originally suggested by @eddyb,THUMBS_UP,2020-07-21T21:11:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74582,MERGED,2020-07-21T09:33:26Z,2020-08-01T11:25:54Z,Rename HAIR to THIR (Typed HIR).,Lezzz,dfe1e3b641abbede6230e3931d14f0d43e5b8e54,36,Auto merge of #74582 - Lezzz:rename-hair r=nikomatsakis Rename HAIR to THIR (Typed HIR). r? @nikomatsakis Originally suggested by @eddyb,THUMBS_UP,2020-07-21T23:30:12Z,estebank,NA https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-07-21T21:55:32Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-07-21T22:20:41Z,Lucretiel,NA https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-07-22T10:19:57Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-07-31T19:01:33Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-09-02T00:00:31Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-09-05T17:39:05Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/74605,MERGED,2020-07-21T21:36:09Z,2020-08-02T01:05:19Z,Stabilize Vec::leak as a method,SimonSapin,5ef872f9619ed78a349c1407ebac719a980209ee,1,Auto merge of #74605 - rust-lang:vec-leak r=Amanieu Stabilize Vec::leak as a method Closes https://github.com/rust-lang/rust/issues/62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own different `leak` method) does not apply.,ROCKET,2020-09-29T06:09:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,ROCKET,2020-07-22T15:11:38Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HOORAY,2020-07-22T15:11:40Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HOORAY,2020-07-23T07:54:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HEART,2020-07-23T07:54:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HOORAY,2020-08-05T05:44:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HEART,2020-10-30T14:20:33Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/74606,MERGED,2020-07-21T21:37:46Z,2020-07-23T10:44:43Z,Remove Linux workarounds for missing CLOEXEC support,cuviper,8909ac97d52a8b099fd334d84db1073839e16b16,6,Rollup merge of #74606 - cuviper:cloexec r=sfackler Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32 we can assume the availability of APIs that open file descriptors that are already set to close on exec including the flags `O_CLOEXEC` `SOCK_CLOEXEC` and `F_DUPFD_CLOEXEC`. Closes #74519.,HOORAY,2020-10-30T14:20:34Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T09:44:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T12:57:01Z,mati865,NA https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T13:56:46Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T15:04:46Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T15:15:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T16:32:23Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74620,MERGED,2020-07-22T08:58:26Z,2020-07-22T15:30:00Z,Disable Azure Pipelines except for macOS,pietroalbini,69d68f90964a46e479eec02a4d9c45aaaa45b411,4,Auto merge of #74620 - rust-lang:remove-most-azure r=Mark-Simulacrum Disable Azure Pipelines except for macOS Following up on https://github.com/rust-lang/rust/pull/74565 this PR disables most of Azure Pipelines except for macOS auto builds practically switching us to GitHub Actions :tada: r? @Mark-Simulacrum,HOORAY,2020-07-22T18:41:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74621,MERGED,2020-07-22T09:46:08Z,2020-08-11T06:01:20Z,Improve `f32` and `f64` primitive documentation,LukasKalbertodt,a9025c571e81ea9adad4dbee0614f1ca37338328,1,Auto merge of #74621 - LukasKalbertodt:float-docs r=GuillaumeGomez Improve `f32` and `f64` primitive documentation I noticed that the docs for the primitive floats were fairly short. I first only wanted to add the IEEE specification information (compare [the reference](https://doc.rust-lang.org/reference/types/numeric.html)) but then also added some more beginner-friendly docs. Let me know what you think! Random doc team assign: r? @rylev,THUMBS_UP,2020-07-28T05:47:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/74622,MERGED,2020-07-22T10:21:35Z,2020-10-31T19:34:29Z,Add std::panic::panic_any.,m-ou-se,76b8b00b4ff09b958e9ebcaa851f5dcb7b827f8a,1,Rollup merge of #74622 - fusion-engineering-forks:panic-box r=KodrAus Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any` because it allows for any (`Any + Send`) type. _Tracking issue: #78500_,THUMBS_UP,2020-07-22T14:22:45Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/74622,MERGED,2020-07-22T10:21:35Z,2020-10-31T19:34:29Z,Add std::panic::panic_any.,m-ou-se,76b8b00b4ff09b958e9ebcaa851f5dcb7b827f8a,1,Rollup merge of #74622 - fusion-engineering-forks:panic-box r=KodrAus Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any` because it allows for any (`Any + Send`) type. _Tracking issue: #78500_,THUMBS_UP,2020-10-27T17:35:01Z,dlight,NA https://github.com/rust-lang/rust/pull/74622,MERGED,2020-07-22T10:21:35Z,2020-10-31T19:34:29Z,Add std::panic::panic_any.,m-ou-se,76b8b00b4ff09b958e9ebcaa851f5dcb7b827f8a,1,Rollup merge of #74622 - fusion-engineering-forks:panic-box r=KodrAus Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any` because it allows for any (`Any + Send`) type. _Tracking issue: #78500_,THUMBS_UP,2020-10-28T18:24:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74622,MERGED,2020-07-22T10:21:35Z,2020-10-31T19:34:29Z,Add std::panic::panic_any.,m-ou-se,76b8b00b4ff09b958e9ebcaa851f5dcb7b827f8a,1,Rollup merge of #74622 - fusion-engineering-forks:panic-box r=KodrAus Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any` because it allows for any (`Any + Send`) type. _Tracking issue: #78500_,THUMBS_UP,2020-10-31T20:17:15Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74622,MERGED,2020-07-22T10:21:35Z,2020-10-31T19:34:29Z,Add std::panic::panic_any.,m-ou-se,76b8b00b4ff09b958e9ebcaa851f5dcb7b827f8a,1,Rollup merge of #74622 - fusion-engineering-forks:panic-box r=KodrAus Add std::panic::panic_any. The discussion of #67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`. Alternative names: - `panic_with!(..)` - ~~`start_unwind(..)`~~ (panicking doesn't always unwind) - `throw!(..)` - `panic_throwing!(..)` - `panic_with_value(..)` - `panic_value(..)` - `panic_with(..)` - `panic_box(..)` - `panic(..)` The equivalent (private unstable) function in `libstd` is called `std::panicking::begin_panic`. I suggest `panic_any` because it allows for any (`Any + Send`) type. _Tracking issue: #78500_,THUMBS_UP,2020-12-17T04:33:40Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/74627,MERGED,2020-07-22T12:17:05Z,2020-08-07T15:28:44Z,"rustc_ast: Stop using ""string typing"" for doc comment tokens",petrochenkov,64f99b4cfbf01c8fda1d4fe16e9b37b11096b7c3,25,"Auto merge of #74627 - petrochenkov:docbeauty2 r=Aaron1011 rustc_ast: Stop using ""string typing"" for doc comment tokens Explicitly store their kind and style retrieved during lexing in the `token::DocComment`. Also don't ""beautify"" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural). The trimming of empty lines lines containing only `*`s etc is purely a rustdoc's job as a part of its presentation of doc strings to users rustc must not do this and must pass tokens as precisely as possible internally.",THUMBS_UP,2020-08-05T09:17:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74627,MERGED,2020-07-22T12:17:05Z,2020-08-07T15:28:44Z,"rustc_ast: Stop using ""string typing"" for doc comment tokens",petrochenkov,64f99b4cfbf01c8fda1d4fe16e9b37b11096b7c3,25,"Auto merge of #74627 - petrochenkov:docbeauty2 r=Aaron1011 rustc_ast: Stop using ""string typing"" for doc comment tokens Explicitly store their kind and style retrieved during lexing in the `token::DocComment`. Also don't ""beautify"" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural). The trimming of empty lines lines containing only `*`s etc is purely a rustdoc's job as a part of its presentation of doc strings to users rustc must not do this and must pass tokens as precisely as possible internally.",THUMBS_UP,2020-08-13T14:49:19Z,95th,NA https://github.com/rust-lang/rust/pull/74631,MERGED,2020-07-22T13:43:12Z,2020-07-23T02:58:10Z,rustc_target: Add a target spec option for disabling `--eh-frame-hdr`,petrochenkov,7b28e7bf6bd209b76639748b1ab15ac65b586e22,14,Rollup merge of #74631 - petrochenkov:ehdr2 r=jonas-schievink rustc_target: Add a target spec option for disabling `--eh-frame-hdr` Disable `--eh-frame-hdr` for targets that use an `ld`-like linker but don't support that option. Do it through a target spec option rather than through hard-coding in `linker.rs`. The option is still enabled by default though. cc https://github.com/rust-lang/rust/pull/73564 Fixes https://github.com/rust-lang/rust/pull/73564#issuecomment-657011004 Fixes https://github.com/rust-lang/rust/pull/74625 Fixes https://github.com/rust-embedded/msp430-rt/issues/12,THUMBS_UP,2020-07-26T10:02:34Z,stianeklund,NA https://github.com/rust-lang/rust/pull/74643,MERGED,2020-07-22T17:12:28Z,2020-07-23T02:58:08Z,build: Remove unnecessary `cargo:rerun-if-env-changed` annotations,petrochenkov,b32383ca901b01192e8110afab8421a20062caa4,21,Rollup merge of #74643 - petrochenkov:noenvrerun r=Mark-Simulacrum build: Remove unnecessary `cargo:rerun-if-env-changed` annotations ... and a couple of related cleanups. rustc and cargo now track the majority of env var dependencies automatically (https://github.com/rust-lang/cargo/pull/8421) so the annotations are no longer necessary.,THUMBS_UP,2020-07-22T19:19:14Z,ehuss,NA https://github.com/rust-lang/rust/pull/74653,MERGED,2020-07-22T20:49:37Z,2020-07-27T07:40:46Z,proc_macro: Add API for tracked access to environment variables,petrochenkov,1841fb97e17f5e41c609cd11ab114c7ac1f3de2a,8,Auto merge of #74653 - petrochenkov:pmenv r=dtolnay proc_macro: Add API for tracked access to environment variables Continuation of https://github.com/rust-lang/rust/pull/71858. `proc_macro::tracked_env::var` is similar to regular `env::var` called from a proc macro except that it also adds the accessed variable to depinfo.,THUMBS_UP,2020-07-23T00:45:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74659,MERGED,2020-07-22T22:06:28Z,2020-07-23T10:44:36Z,Improve codegen for unchecked float casts on wasm,alexcrichton,8f02f2c1abd6c3fbd3053da5bb6759a4698a949e,4,Rollup merge of #74659 - alexcrichton:wasm-codegen r=varkor Improve codegen for unchecked float casts on wasm This commit improves codegen for unchecked casts on WebAssembly targets to use the singluar `iNN.trunc_fMM_{u s}` instructions. Previously rustc would codegen a bare `fptosi` and `fptoui` for float casts but for WebAssembly targets the codegen for these instructions is quite large. This large codegen is due to the fact that LLVM can speculate these instructions so the trapping behavior of WebAssembly needs to be protected against in case they're speculated. The change here is to update the codegen for the unchecked cast intrinsics to have a wasm-specific case where they call the appropriate LLVM intrinsic to generate the right wasm instruction. The intrinsic is explicitly opting-in to undefined behavior so a trap here for out-of-bounds inputs on wasm should be acceptable. cc #73591,THUMBS_UP,2020-07-22T22:15:25Z,DzmitryFil,NA https://github.com/rust-lang/rust/pull/74661,MERGED,2020-07-22T23:33:54Z,2020-07-24T20:00:54Z,Refactor `region_name`: add `RegionNameHighlight`,SNCPlay42,ceaef731a9eb7156766ffb74f2bd6bec761adfc3,3,Rollup merge of #74661 - SNCPlay42:lifetime-names-refactor r=estebank Refactor `region_name`: add `RegionNameHighlight` This PR does not change any diagnostics itself rather it enables further code changes but I would like to get approval for the refactoring first before making use of it. In `rustc_mir::borrow_check::diagnostics::region_name` there is code that allows for when giving a synthesized name like `'1` to an anonymous lifetime pointing at e.g. the exact '`&`' that introduces the lifetime. This PR decouples that code from the specific case of arguments adding a new enum `RegionNameHighlight` enabling future changes to use it in other places. This allows: * We could change the other `AnonRegionFrom*` variants to use `RegionNameHighlight` to precisely point at where lifetimes are introduced in other locations when they have type annotations e.g. a closure return `|...| -> &i32`. * Because of how async functions are lowered this affects async functions as well see #74072 * for #74597 we could add a second optional `RegionNameHighlight` to the `AnonRegionFromArgument` variant that highlights a lifetime in the return type of a function when due to elision this is the same as the argument lifetime. * in https://github.com/rust-lang/rust/issues/74497#issuecomment-6606229707 I noticed that a diagnostic was trying to introduce a lifetime `'2` in the opaque type `impl std::future::Future`. The code for the case of arguments has [code to handle cases like this](https://github.com/rust-lang/rust/blob/bbebe7351fcd29af1eb9a35e315369b15887ea09/src/librustc_mir/borrow_check/diagnostics/region_name.rs#L365) but not the others. This refactoring would allow the same code path to handle this. * It might be appropriate to add another variant of `RegionNameHighlight` to say something like `lifetime '1 appears in the opaque type impl std::future::Future`. These are quite a few changes so I thought I would make sure the refactoring is OK before I start making changes that rely on it. :),HEART,2020-07-23T22:17:47Z,tmandry,NA https://github.com/rust-lang/rust/pull/74668,MERGED,2020-07-23T07:54:47Z,2020-08-31T01:29:43Z,cleanup: Remove duplicate library names from `Cargo.toml`s,petrochenkov,022e1fe235ec40248cd8f6b5ba8f37d7e14d656e,7,Auto merge of #74668 - petrochenkov:noname r=mark-i-m cleanup: Remove duplicate library names from `Cargo.toml`s,THUMBS_UP,2020-08-28T04:04:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74670,MERGED,2020-07-23T08:44:44Z,2020-07-26T01:20:21Z,Normalize bounds fully when checking defaulted types,tmandry,bb85981a3ac31c32d2f5924eb812c0a71baabf38,2,Auto merge of #74670 - tmandry:issue-73818 r=matthewjasper Normalize bounds fully when checking defaulted types When checking that the default type for `::Y` is valid in this example: ``` trait X { type Y: PartialEq<::Y> } impl X for T { default type Y = S; } ``` We will have to prove the bound `S: PartialEq<::Y>`. In this case we want `::Y` to normalize to `S`. This is valid because we are checking the default value specifically here. Add `::Y = S` to the ParamEnv for normalization _of the bound we are checking_ only. Fixes #73818. --- I noticed that adding this to the env for bounds checking didn't break any tests. Not sure if this is because we can't rely on it to prove anything or because of missing test coverage. r? @matthewjasper @nikomatsakis,THUMBS_UP,2020-07-23T21:44:41Z,betamos,didrik.nordstrom@gmail.com https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,THUMBS_UP,2020-07-23T09:43:35Z,raw-bin,NA https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,THUMBS_UP,2020-07-23T09:44:07Z,Stammark,NA https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,THUMBS_UP,2020-07-23T09:54:17Z,JamieCunliffe,NA https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,THUMBS_UP,2020-07-23T10:36:24Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,ROCKET,2020-07-24T05:12:52Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74675,MERGED,2020-07-23T09:34:59Z,2020-08-02T16:02:27Z,Add fallible AArch64 CI builder,pietroalbini,e8876ae2c11f341565059b900eeae1254a9accf1,4,Auto merge of #74675 - pietroalbini:aarch64-ci-fallible r=Mark-Simulacrum Add fallible AArch64 CI builder This adds the `aarch64-gnu` CI builder to the `auto-fallible` job as a first step in the process of actually gating on it. r? @Mark-Simulacrum,HOORAY,2020-07-24T05:12:54Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74676,MERGED,2020-07-23T10:44:27Z,2020-07-24T16:00:07Z,correctly deal with unsorted generic parameters,lcnr,cfb6114b2a20e04e3212ed030bc68d23faf8048f,5,Auto merge of #74676 - lcnr:generics-no-sort r=varkor correctly deal with unsorted generic parameters We now stop sorting generic params and instead correctly handle unsorted params in the rest of the compiler. We still restrict const params to come after type params though so this PR does not change anything which is visible to users. This might slightly influence perf so let's prevent any unintentional rollups. @bors rollup=never r? @varkor,HEART,2020-07-24T10:31:39Z,varkor,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T15:16:54Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T16:05:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T16:33:02Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T17:09:41Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T18:51:46Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-23T21:59:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-24T00:37:29Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-24T06:49:14Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-24T15:38:34Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-25T17:32:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-27T04:52:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-28T17:01:56Z,eggyal,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-28T21:45:45Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-28T22:24:34Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-29T03:57:08Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-29T15:07:22Z,uonr,me@yuru.me https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-29T17:11:31Z,InquisitivePenguin,inquisitivepenguin@protonmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-30T02:34:43Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-07-30T18:54:53Z,slonopotamus,marat@slonopotamus.org https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-08-05T06:40:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-08-05T16:30:24Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-09-26T03:49:44Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-09-26T04:14:29Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-09-26T11:12:18Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-09-26T15:05:09Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74682,MERGED,2020-07-23T14:29:13Z,2020-07-31T02:21:03Z,std: Switch from libbacktrace to gimli (take 2),alexcrichton,c058a8b8dc5dea0ed9b33e14da9e317e2749fcd7,14,Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2 r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take. Closes #71060,HEART,2020-11-18T06:40:28Z,bb010g,NA https://github.com/rust-lang/rust/pull/74687,MERGED,2020-07-23T16:36:17Z,2020-07-25T20:05:39Z,Detect turbofish missing surrounding angle brackets,estebank,f06e8e157cc86538eacb76a65073787b0e46c396,5,Auto merge of #74687 - estebank:bracketless-turbofish r=matthewjasper Detect turbofish missing surrounding angle brackets Fix #74065.,THUMBS_UP,2020-07-31T14:05:29Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/74692,MERGED,2020-07-23T18:37:42Z,2020-07-24T20:00:50Z,delay_span_bug instead of silent ignore,Mark-Simulacrum,db83a21de1c5b5a3b2e5fbbecd03d70daa4ce331,1,Rollup merge of #74692 - Mark-Simulacrum:delay-bug r=pnkfelix delay_span_bug instead of silent ignore This is a follow-up to #74557. r? @pnkfelix,THUMBS_UP,2020-07-24T08:49:21Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",THUMBS_UP,2020-07-23T22:39:01Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",THUMBS_UP,2020-07-23T23:24:56Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",HEART,2020-07-24T07:33:37Z,harrysarson,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",THUMBS_UP,2020-07-24T10:39:47Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",HEART,2020-07-24T10:46:19Z,RalfJung,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",HEART,2020-07-25T17:31:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",HEART,2020-12-10T15:23:51Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",THUMBS_UP,2020-12-10T15:23:51Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",THUMBS_UP,2020-12-11T23:03:03Z,luben,NA https://github.com/rust-lang/rust/pull/74699,MERGED,2020-07-23T22:15:18Z,2020-12-20T19:33:03Z,Mark `-1` as an available niche for file descriptors,notriddle,b0e5c7d1fee37f1890455b977495bfe262716701,4,"Auto merge of #74699 - notriddle:fd-non-negative r=m-ou-se Mark `-1` as an available niche for file descriptors Based on discussion from the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen particularly on Linux but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the ""upper"" bound which is actually -1 to be expressed in two's complement.",HEART,2021-02-09T20:09:48Z,worstpractice,NA https://github.com/rust-lang/rust/pull/74703,MERGED,2020-07-24T00:53:54Z,2020-07-24T13:58:40Z,Fix ICE while building MIR with type errors,tmandry,01b069db67f7f7d4d75e8bf492446e0ce9f7a6a8,3,Rollup merge of #74703 - tmandry:issue-74047 r=oli-obk Fix ICE while building MIR with type errors See https://github.com/rust-lang/rust/issues/74047#issuecomment-663290913 for background. Replacing a binding with `PatKind::Wild` (introduced in #51789 and later refactored in #67439) caused an ICE downstream while building MIR. I noticed that taking this code out no longer triggers the ICEs it was added to prevent. I'm not sure what else changed or if this change is _correct_ but it does seem to be passing ui tests at least. r? @oli-obk cc @estebank Fixes #74047.,THUMBS_UP,2020-07-24T00:55:29Z,estebank,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-07-24T10:27:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-07-26T06:56:30Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-08-05T18:28:04Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-08-05T23:56:03Z,kawogi,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-08-07T01:59:27Z,calebsander,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-08-25T03:06:04Z,usagi,the@usagi.network https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2020-12-05T05:41:21Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/74707,MERGED,2020-07-24T08:03:02Z,2020-07-29T04:59:57Z,Add str::[r]split_once,matklad,6968b75bd0524915d3fcf6b201b41827d4695603,3,Rollup merge of #74707 - matklad:split_once r=dtolnay Add str::[r]split_once This is useful for quick&dirty parsing of key: value config pairs. Used a bunch in Cargo and rust-analyzer: * https://github.com/rust-lang/cargo/search?q=splitn%282&unscoped_q=splitn%282 * https://github.com/rust-analyzer/rust-analyzer/search?q=split_delim&unscoped_q=split_delim In theory once const-generics are done this functionality could be achieved without a dedicated method with ```rust match s.splitn(delimier 2).collect_array::<2>() { Some([prefix suffix]) => todo!() None => todo!() } ``` Even in that world having a dedicated method seems clearer on the intention. I am not sure about naming -- this is something I've just came up with yesterday I don't know off the top of my head analogs in other languages. If T-libs thinks this is a reasonable API to have I'll open a tracking issue and add more thorough tests.,THUMBS_UP,2021-01-24T13:53:20Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/74715,MERGED,2020-07-24T13:54:58Z,2020-07-24T20:00:46Z,Add a system for creating diffs across multiple mir optimizations.,oli-obk,5d1d94e7b8feeed42447a8922105462969dd9e81,5,Rollup merge of #74715 - oli-obk:mir_pass_diff r=wesleywiser Add a system for creating diffs across multiple mir optimizations. r? @wesleywiser,HEART,2020-07-24T15:54:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74715,MERGED,2020-07-24T13:54:58Z,2020-07-24T20:00:46Z,Add a system for creating diffs across multiple mir optimizations.,oli-obk,5d1d94e7b8feeed42447a8922105462969dd9e81,5,Rollup merge of #74715 - oli-obk:mir_pass_diff r=wesleywiser Add a system for creating diffs across multiple mir optimizations. r? @wesleywiser,HEART,2020-07-31T01:25:01Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/74726,MERGED,2020-07-24T19:01:03Z,2020-08-01T22:29:50Z,Move from `log` to `tracing`,oli-obk,05762e3d6f5facafdd47efdf4203021fadf61bb1,41,Auto merge of #74726 - oli-obk:tracing r=Mark-Simulacrum Move from `log` to `tracing` The only visible change is that we now get timestamps in our logs: ``` Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: skipping replace of Rvalue::Use(const () because it is already a const Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: propagated into _2 Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: visit_constant: const () ``` This PR was explicitly designed to be as low-impact as possible. We can now move to using the name `tracing` insteads of `log` on a crate-by-crate basis and use any of the other tracing features where desirable. As far as I can tell this will allow tools to seamlessly keep working (since they are using `rustc_driver::init_log...`). This is the first half of step 1 of the accepted `tracing` MCP (https://github.com/rust-lang/compiler-team/issues/331),THUMBS_UP,2020-08-01T02:46:38Z,MOZGIII,NA https://github.com/rust-lang/rust/pull/74728,MERGED,2020-07-25T01:14:53Z,2020-07-26T03:03:24Z,Fix rustc docs typo.,16yuki0702,8e5489ca6760420af33ffa361d5c706eb9badf48,1,Auto merge of #74728 - 16yuki0702:fix_typo r=jonas-schievink Fix rustc docs typo.,THUMBS_UP,2020-07-25T20:05:23Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/74728,MERGED,2020-07-25T01:14:53Z,2020-07-26T03:03:24Z,Fix rustc docs typo.,16yuki0702,8e5489ca6760420af33ffa361d5c706eb9badf48,1,Auto merge of #74728 - 16yuki0702:fix_typo r=jonas-schievink Fix rustc docs typo.,ROCKET,2020-07-25T20:05:26Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/74733,MERGED,2020-07-25T05:43:20Z,2020-07-29T22:25:00Z,Fixed coverage map issues; better aligned with LLVM APIs,richkadel,db0492ace429cfeb3567e2c04e300be7df9972ff,14,Auto merge of #74733 - richkadel:llvm-coverage-map-gen-5 r=tmandry Fixed coverage map issues; better aligned with LLVM APIs Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat resulting in less code overall expanded coverage of LLVM Coverage Map capabilities and much closer alignment with LLVM data structures APIs and naming. This should be easier to follow and easier to maintain. r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation,HOORAY,2020-07-25T08:20:19Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74733,MERGED,2020-07-25T05:43:20Z,2020-07-29T22:25:00Z,Fixed coverage map issues; better aligned with LLVM APIs,richkadel,db0492ace429cfeb3567e2c04e300be7df9972ff,14,Auto merge of #74733 - richkadel:llvm-coverage-map-gen-5 r=tmandry Fixed coverage map issues; better aligned with LLVM APIs Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat resulting in less code overall expanded coverage of LLVM Coverage Map capabilities and much closer alignment with LLVM data structures APIs and naming. This should be easier to follow and easier to maintain. r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation,HOORAY,2020-07-25T14:25:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74735,MERGED,2020-07-25T06:13:03Z,2020-07-26T04:47:35Z,Use the proper span when WF-checking an impl self type,Aaron1011,a4dd850720369d9e5b9df91820b23cddb2badc06,7,Auto merge of #74735 - Aaron1011:fix/wf-impl-self-type r=estebank Use the proper span when WF-checking an impl self type,HEART,2020-07-25T17:18:39Z,estebank,NA https://github.com/rust-lang/rust/pull/74744,MERGED,2020-07-25T14:40:09Z,2020-08-11T14:40:08Z,Update RELEASES.md for 1.46.0,XAMPPRocky,fa853f3df0ec7b9bf86770bda85f764e9791e4ac,1,Rollup merge of #74744 - XAMPPRocky:relnotes-1.46.0 r=Mark-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,ROCKET,2020-07-25T17:20:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74744,MERGED,2020-07-25T14:40:09Z,2020-08-11T14:40:08Z,Update RELEASES.md for 1.46.0,XAMPPRocky,fa853f3df0ec7b9bf86770bda85f764e9791e4ac,1,Rollup merge of #74744 - XAMPPRocky:relnotes-1.46.0 r=Mark-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,HEART,2020-07-26T22:42:05Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/74744,MERGED,2020-07-25T14:40:09Z,2020-08-11T14:40:08Z,Update RELEASES.md for 1.46.0,XAMPPRocky,fa853f3df0ec7b9bf86770bda85f764e9791e4ac,1,Rollup merge of #74744 - XAMPPRocky:relnotes-1.46.0 r=Mark-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,HEART,2020-07-27T19:52:29Z,ehuss,NA https://github.com/rust-lang/rust/pull/74748,MERGED,2020-07-25T15:59:05Z,2020-08-17T20:52:48Z,MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant,simonvandel,33c96b4d9782cf6364e47cb2c904e66b06c22bb4,10,Auto merge of #74748 - simonvandel:simplify-discriminant-arm r=wesleywiser MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant Modifies SimplifyBranchSame so that it can see that the statements can be considered equal in the following example `_0 = _1` and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum.,ROCKET,2020-07-26T07:33:18Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74748,MERGED,2020-07-25T15:59:05Z,2020-08-17T20:52:48Z,MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant,simonvandel,33c96b4d9782cf6364e47cb2c904e66b06c22bb4,10,Auto merge of #74748 - simonvandel:simplify-discriminant-arm r=wesleywiser MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant Modifies SimplifyBranchSame so that it can see that the statements can be considered equal in the following example `_0 = _1` and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum.,ROCKET,2020-08-08T23:37:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74748,MERGED,2020-07-25T15:59:05Z,2020-08-17T20:52:48Z,MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant,simonvandel,33c96b4d9782cf6364e47cb2c904e66b06c22bb4,10,Auto merge of #74748 - simonvandel:simplify-discriminant-arm r=wesleywiser MIR-OPT: Make SimplifyBranchSame able to remove identity match with fieldless variant Modifies SimplifyBranchSame so that it can see that the statements can be considered equal in the following example `_0 = _1` and `discriminant(_0) = discriminant(0)` are considered equal if 0 is a fieldless variant of an enum.,ROCKET,2020-08-18T01:14:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/74750,MERGED,2020-07-25T16:38:47Z,2020-07-27T12:50:55Z,Clean up some uses of logging in ui tests,oli-obk,72aad3564910a017994dfdb11fb731515011c753,11,Rollup merge of #74750 - oli-obk:logging_and_test_cleanups r=JohnTitor Clean up some uses of logging in ui tests The removed test can't possibly trigger anything today as we don't have logging in libstd. The `exec-env` flag was mistakenly used for adding env vars to rustc invocations both in test and in the test suite and there were some accidental renames from RUST_LOG to RUSTC_LOG that I reverted.,HEART,2020-07-25T21:14:41Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-08-06T01:22:43Z,tmandry,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-08-18T10:09:04Z,elichai,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-08-18T10:11:45Z,elichai,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-08-30T18:30:17Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-08-30T18:30:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-09-04T23:27:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-09-04T23:27:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-09-05T17:16:35Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-09-05T17:16:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-09-15T23:47:13Z,cramertj,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-09-17T10:48:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,THUMBS_UP,2020-11-23T01:10:21Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-11-23T01:10:23Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2020-11-25T23:40:15Z,akiross,NA https://github.com/rust-lang/rust/pull/74754,MERGED,2020-07-25T18:17:58Z,2020-11-10T13:26:37Z,Add `#[cfg(panic = '...')]`,davidhewitt,46bce9f8efbd4c57a23e822588650250d1e74b26,15,Rollup merge of #74754 - davidhewitt:cfg-panic r=ecstatic-morse Add `#[cfg(panic = '...')]` This PR adds conditional compilation according to the panic strategy. I've come across a need for a flag like this a couple of times while writing tests: #74301 https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031 I'm not sure if I need to add a feature gate for this flag?,HOORAY,2021-04-06T19:22:20Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,EYES,2020-07-26T13:24:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,THUMBS_UP,2020-07-27T10:20:20Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,THUMBS_UP,2020-07-27T16:17:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,HEART,2020-07-27T16:17:08Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,THUMBS_UP,2020-08-04T21:43:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,THUMBS_UP,2020-08-13T04:59:42Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/74759,MERGED,2020-07-25T20:30:25Z,2020-08-04T03:49:02Z,add `unsigned_abs` to signed integers,carbotaniuman,cc0ac7eecebd57278974329d3610bb2512740ef8,1,Rollup merge of #74759 - carbotaniuman:uabs r=shepmaster add `unsigned_abs` to signed integers Mentioned on rust-lang/rfcs#2914 This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.,THUMBS_UP,2020-11-24T14:01:20Z,zhongzc,zhongzc_arch@outlook.com https://github.com/rust-lang/rust/pull/74760,MERGED,2020-07-25T21:28:52Z,2020-07-25T23:37:05Z,Update rustfmt and rls,tmandry,d6953df14657f5932270ad2b33bccafe6f39fad4,3,Auto merge of #74760 - tmandry:roll r=tmandry Update rustfmt and rls Closes #74080 #74081. rls changes: - deps: update racer and cargo rustfmt changes: - preparation for potential rustfmt 1.4.19 (#4283) - chore: backport 8157a3f0afe978d3e953420577f8344db7e905bf - deps: bump rustc-ap to v669 - deps: bump rustc-ap-* to v668 - deps: bump rustc-ap* to v666 - Use correct span for match arms with the leading pipe and attributes (#3975),HEART,2020-07-25T22:17:33Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/74787,MERGED,2020-07-26T17:48:00Z,2020-09-10T05:54:19Z,Move `rustllvm` into `compiler/rustc_llvm`,petrochenkov,f09372ab609236510187bd61ab1c6b30cfa69014,17,Rollup merge of #74787 - petrochenkov:rustllvm r=cuviper Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name but something like `llvm-adapter` would work as well other suggestions are welcome. To make things more confusing the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project` `rustllvm` `librustc_llvm` `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`) a FFI crate (`rustc_llvm` kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).,HEART,2020-07-26T21:08:27Z,mati865,NA https://github.com/rust-lang/rust/pull/74787,MERGED,2020-07-26T17:48:00Z,2020-09-10T05:54:19Z,Move `rustllvm` into `compiler/rustc_llvm`,petrochenkov,f09372ab609236510187bd61ab1c6b30cfa69014,17,Rollup merge of #74787 - petrochenkov:rustllvm r=cuviper Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name but something like `llvm-adapter` would work as well other suggestions are welcome. To make things more confusing the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project` `rustllvm` `librustc_llvm` `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`) a FFI crate (`rustc_llvm` kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).,HEART,2020-07-26T21:19:51Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74787,MERGED,2020-07-26T17:48:00Z,2020-09-10T05:54:19Z,Move `rustllvm` into `compiler/rustc_llvm`,petrochenkov,f09372ab609236510187bd61ab1c6b30cfa69014,17,Rollup merge of #74787 - petrochenkov:rustllvm r=cuviper Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name but something like `llvm-adapter` would work as well other suggestions are welcome. To make things more confusing the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project` `rustllvm` `librustc_llvm` `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`) a FFI crate (`rustc_llvm` kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).,HEART,2020-07-26T21:55:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74787,MERGED,2020-07-26T17:48:00Z,2020-09-10T05:54:19Z,Move `rustllvm` into `compiler/rustc_llvm`,petrochenkov,f09372ab609236510187bd61ab1c6b30cfa69014,17,Rollup merge of #74787 - petrochenkov:rustllvm r=cuviper Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name but something like `llvm-adapter` would work as well other suggestions are welcome. To make things more confusing the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project` `rustllvm` `librustc_llvm` `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`) a FFI crate (`rustc_llvm` kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).,HEART,2020-08-07T00:01:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74807,CLOSED,2020-07-27T04:23:32Z,2020-08-17T02:38:09Z,Encode trait impls using nested Tables,Aaron1011,NA,NA,NA,HEART,2020-07-27T10:04:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74826,MERGED,2020-07-27T13:19:15Z,2020-08-02T22:07:47Z,Introduce NonterminalKind for more type-safe mbe parsing,matklad,f042d749b0fc212bff6bdc44b84e134b878bff64,11,Auto merge of #74826 - matklad:mbe-fragment r=petrochenkov Introduce NonterminalKind for more type-safe mbe parsing It encapsulate the (part of) the interface between the parser and macro by example (macro_rules) parser. The second bit is somewhat more general `parse_ast_fragment` which is the reason why we keep some `parse_xxx` functions as public.,HEART,2020-07-27T17:10:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74839,MERGED,2020-07-27T20:59:23Z,2020-10-01T12:42:16Z,Implement multiple return terminator optimization,alarsyo,9cba260df0f1c67ea3690035cd5611a7465a1560,12,Auto merge of #74839 - alarsyo:multiple_return_terminators r=oli-obk Implement multiple return terminator optimization Closes #72022,ROCKET,2020-10-01T12:59:12Z,ambroisie,NA https://github.com/rust-lang/rust/pull/74846,MERGED,2020-07-27T22:22:53Z,2020-08-21T04:34:04Z,Capture tokens for Pat used in macro_rules! argument,Aaron1011,ff5e0f1dc8c5534406169903b3b9da029d3bada5,13,Auto merge of #74846 - Aaron1011:fix/pat-token-capture r=petrochenkov Capture tokens for Pat used in macro_rules! argument This extends PR #73293 to handle patterns (Pat). Unlike expressions patterns do not support custom attributes so we only need to capture tokens during macro_rules! argument parsing.,THUMBS_UP,2020-08-14T18:02:53Z,estebank,NA https://github.com/rust-lang/rust/pull/74853,CLOSED,2020-07-28T01:12:49Z,2020-08-25T12:40:18Z,New name for hint::black_box: pretend_used,jonhoo,NA,NA,NA,THUMBS_UP,2020-07-28T02:59:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/74853,CLOSED,2020-07-28T01:12:49Z,2020-08-25T12:40:18Z,New name for hint::black_box: pretend_used,jonhoo,NA,NA,NA,THUMBS_UP,2020-07-28T06:10:22Z,DenialAdams,brick@brick.codes https://github.com/rust-lang/rust/pull/74853,CLOSED,2020-07-28T01:12:49Z,2020-08-25T12:40:18Z,New name for hint::black_box: pretend_used,jonhoo,NA,NA,NA,THUMBS_UP,2020-07-28T09:01:38Z,pitdicker,NA https://github.com/rust-lang/rust/pull/74853,CLOSED,2020-07-28T01:12:49Z,2020-08-25T12:40:18Z,New name for hint::black_box: pretend_used,jonhoo,NA,NA,NA,CONFUSED,2020-07-29T07:30:04Z,CryZe,NA https://github.com/rust-lang/rust/pull/74853,CLOSED,2020-07-28T01:12:49Z,2020-08-25T12:40:18Z,New name for hint::black_box: pretend_used,jonhoo,NA,NA,NA,THUMBS_UP,2020-07-29T13:13:15Z,petertodd,pete@petertodd.org https://github.com/rust-lang/rust/pull/74860,CLOSED,2020-07-28T04:01:37Z,2021-01-15T13:06:11Z,[android] Add support for android's file descriptor ownership tagging to libstd.,jmgao,NA,NA,NA,THUMBS_UP,2020-11-14T08:46:41Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/74862,MERGED,2020-07-28T04:37:01Z,2020-08-30T17:41:56Z,Move almost all compiler crates to compiler/,mark-i-m,85fbf49ce0e2274d0acf798f6e703747674feec3,1686,Auto merge of #74862 - mark-i-m:mv-compiler r=petrochenkov Move almost all compiler crates to compiler/ This PR implements https://github.com/rust-lang/compiler-team/issues/336 and moves all `rustc_*` crates from `src` to the new `compiler` directory. `librustc_foo` directories are renamed to `rustc_foo`. `src` directories are introduced inside `rustc_*` directories to mirror the scheme already use for `library` crates.,HEART,2020-08-30T18:01:08Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/74862,MERGED,2020-07-28T04:37:01Z,2020-08-30T17:41:56Z,Move almost all compiler crates to compiler/,mark-i-m,85fbf49ce0e2274d0acf798f6e703747674feec3,1686,Auto merge of #74862 - mark-i-m:mv-compiler r=petrochenkov Move almost all compiler crates to compiler/ This PR implements https://github.com/rust-lang/compiler-team/issues/336 and moves all `rustc_*` crates from `src` to the new `compiler` directory. `librustc_foo` directories are renamed to `rustc_foo`. `src` directories are introduced inside `rustc_*` directories to mirror the scheme already use for `library` crates.,HEART,2020-08-31T14:07:58Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/74864,MERGED,2020-07-28T05:07:40Z,2020-07-29T04:59:41Z,ayu theme: Change doccomment color to `#a1ac88`,tesuji,1de0211d8e1398ff87a466708f65613afbe7ee3d,1,Rollup merge of #74864 - lzutao:ayu-doccolor r=GuillaumeGomez ayu theme: Change doccomment color to `#a1ac88` Before: ![image](https://user-images.githubusercontent.com/15225902/88621499-d1cbff80-d0ca-11ea-99c3-5e2632709274.png) After: ![image](https://user-images.githubusercontent.com/15225902/88621471-bf51c600-d0ca-11ea-9455-9c297f50f15f.png) Close #74788,THUMBS_UP,2020-07-28T10:27:49Z,petertodd,pete@petertodd.org https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-07-28T18:17:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-07-30T03:27:18Z,rphmeier,rphmeier@gmail.com https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-07-30T03:31:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-08-05T18:26:31Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-08-05T18:31:55Z,Inky-developer,NA https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-08-30T17:32:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,HEART,2020-10-05T05:17:41Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-10-07T09:19:50Z,iago-lito,NA https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-10-08T22:05:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-10-10T18:03:37Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/74869,MERGED,2020-07-28T11:30:11Z,2020-07-30T02:06:00Z,Make closures and generators a must use types,tmiasko,4230f96bbe45468a34dfdb0ca4204620be0b5686,36,Rollup merge of #74869 - tmiasko:must-use-closures r=ecstatic-morse Make closures and generators a must use types Warn about unused expressions with closure or generator type. This follows existing precedence of must use annotations present on `FnOnce` `FnMut` `Fn` traits which already indirectly apply to closures in some cases e.g. : ```rust fn f() -> impl FnOnce() { || {} } fn main() { // an existing warning: unused implementer of `std::ops::FnOnce` that must be used: f(); // a new warning: unused closure that must be used: || {}; } ``` Closes #74691.,THUMBS_UP,2020-10-31T10:29:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T14:29:47Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T15:01:53Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T15:03:16Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T15:05:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T15:15:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T15:59:57Z,darksv,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T17:08:29Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T17:17:37Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T17:20:24Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,ROCKET,2020-07-28T17:45:27Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-07-28T17:45:30Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T18:54:46Z,mcarton,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-07-28T18:54:47Z,mcarton,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-07-28T18:58:22Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,ROCKET,2020-07-28T18:58:24Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T18:58:26Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-28T22:37:21Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-29T03:57:07Z,95th,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-07-29T03:57:09Z,95th,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-29T08:52:06Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,ROCKET,2020-07-29T08:52:33Z,95th,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-07-29T20:00:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-29T20:00:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,ROCKET,2020-07-29T20:00:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-07-30T07:58:15Z,CryZe,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-08-01T20:01:27Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,THUMBS_UP,2020-08-01T20:01:29Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,ROCKET,2020-08-01T20:01:33Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,EYES,2020-08-01T20:01:36Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-08-07T07:54:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-08-07T12:43:14Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-08-12T20:14:00Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,THUMBS_UP,2020-08-12T20:14:00Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-08-12T20:14:00Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,THUMBS_UP,2020-08-12T21:27:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-08-12T21:27:22Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-08-13T17:05:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HOORAY,2020-08-13T17:05:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/74877,MERGED,2020-07-28T14:28:47Z,2020-08-08T03:55:00Z,Implement the `min_const_generics` feature gate,lcnr,f9c2177ddc605f9c75ca1a3e6ddb33835b8a178d,48,Auto merge of #74877 - lcnr:min_const_generics r=oli-obk Implement the `min_const_generics` feature gate Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers `bool` or `char`. We do allow arbitrary expressions in associated consts though meaning that the following is allowed even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats,HEART,2020-08-13T20:49:01Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/74902,MERGED,2020-07-29T09:03:09Z,2020-07-30T02:05:56Z,Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions,SimonSapin,0f9b7bd80fbb96c7743b86b154f8882918b5737f,3,Rollup merge of #74902 - rust-lang:into_raw_non_null r=dtolnay Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions FCP: https://github.com/rust-lang/rust/issues/47336#issuecomment-619369613,THUMBS_UP,2020-07-29T12:15:03Z,RalfJung,NA https://github.com/rust-lang/rust/pull/74902,MERGED,2020-07-29T09:03:09Z,2020-07-30T02:05:56Z,Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions,SimonSapin,0f9b7bd80fbb96c7743b86b154f8882918b5737f,3,Rollup merge of #74902 - rust-lang:into_raw_non_null r=dtolnay Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions FCP: https://github.com/rust-lang/rust/issues/47336#issuecomment-619369613,THUMBS_UP,2020-07-29T12:33:19Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/74902,MERGED,2020-07-29T09:03:09Z,2020-07-30T02:05:56Z,Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions,SimonSapin,0f9b7bd80fbb96c7743b86b154f8882918b5737f,3,Rollup merge of #74902 - rust-lang:into_raw_non_null r=dtolnay Remove deprecated unstable `{Box Rc Arc}::into_raw_non_null` functions FCP: https://github.com/rust-lang/rust/issues/47336#issuecomment-619369613,HEART,2020-07-29T15:08:51Z,dwijnand,dale.wijnand@gmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-29T19:11:25Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-29T19:39:52Z,mati865,NA https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-29T19:54:03Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-29T21:38:55Z,panaman67,NA https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-30T02:45:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-30T03:21:47Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-07-31T21:03:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-08-02T16:06:56Z,Caduser2020,NA https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-08-30T00:44:18Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-11-17T19:16:47Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-11-19T17:53:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_UP,2020-12-21T02:14:57Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/74922,MERGED,2020-07-29T18:43:19Z,2020-08-29T07:53:50Z,Set ninja=true by default,joshtriplett,d8424f6b426f91ae39dbeacd631a82aad5d733f4,42,Auto merge of #74922 - joshtriplett:ninja-by-default r=Mark-Simulacrum Set ninja=true by default Ninja substantially improves LLVM build time. On a 96-way system using Make took 248s and using Ninja took 161s a 35% improvement. We already require a variety of tools to build Rust. If someone wants to build without Ninja (for instance to minimize the set of packages required to bootstrap a new target) they can easily set `ninja=false` in `config.toml`. Our defaults should help people build Rust (and LLVM) faster to speed up development.,THUMBS_DOWN,2021-02-14T07:10:35Z,tioteath,NA https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-07-30T07:35:10Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-07-30T11:31:09Z,mati865,NA https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-07-30T12:34:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-07-31T03:17:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-08-02T20:40:32Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74932,MERGED,2020-07-30T03:05:30Z,2020-08-08T07:46:31Z,Remove `librustc_ast` session globals,nnethercote,e61621c3078f25365d58cb508cda745007e64d85,121,Auto merge of #74932 - nnethercote:rm-ast-session-globals r=petrochenkov Remove `librustc_ast` session globals By moving the data onto `Session`. r? @petrochenkov,HEART,2020-08-08T10:05:25Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/74941,MERGED,2020-07-30T11:13:53Z,2020-08-27T17:49:17Z,[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target,dylanmckay,3d0c847d3353e319ed82598a106e28fd490caa6b,9,Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target r=oli-obk [AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features silently skip linking runtime libraries etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu` as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended and the avr-unknown-unknown target could never pass the linking step anyway.,THUMBS_UP,2020-07-30T11:26:39Z,mati865,NA https://github.com/rust-lang/rust/pull/74941,MERGED,2020-07-30T11:13:53Z,2020-08-27T17:49:17Z,[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target,dylanmckay,3d0c847d3353e319ed82598a106e28fd490caa6b,9,Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target r=oli-obk [AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features silently skip linking runtime libraries etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu` as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended and the avr-unknown-unknown target could never pass the linking step anyway.,THUMBS_UP,2020-07-31T16:32:31Z,Rahix,rahix@rahix.de https://github.com/rust-lang/rust/pull/74941,MERGED,2020-07-30T11:13:53Z,2020-08-27T17:49:17Z,[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target,dylanmckay,3d0c847d3353e319ed82598a106e28fd490caa6b,9,Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target r=oli-obk [AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features silently skip linking runtime libraries etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu` as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended and the avr-unknown-unknown target could never pass the linking step anyway.,THUMBS_UP,2020-08-01T19:29:49Z,insipx,aplaza@liquidthink.net https://github.com/rust-lang/rust/pull/74941,MERGED,2020-07-30T11:13:53Z,2020-08-27T17:49:17Z,[AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target,dylanmckay,3d0c847d3353e319ed82598a106e28fd490caa6b,9,Auto merge of #74941 - dylanmckay:replace-broken-avr-unknown-unknown-target r=oli-obk [AVR] Replace broken 'avr-unknown-unknown' target with 'avr-unknown-gnu-atmega328' target The `avr-unknown-unknown` target has never worked correctly always trying to invoke the host linker and failing. It aimed to be a mirror of AVR-GCC's default handling of the `avr-unknown-unknown' triple (assume bare minimum chip features silently skip linking runtime libraries etc). This behaviour is broken-by-default as it will cause a miscompiled executable when flashed. This patch improves the AVR builtin target specifications to instead expose only a 'avr-unknown-gnu-atmega328' target. This target system is `gnu` as it uses the AVR-GCC frontend along with avr-binutils. The target triple ABI is 'atmega328'. In the future it should be possible to replace the dependency on AVR-GCC and binutils by using the in-progress AVR LLD and compiler-rt support. Perhaps at that point it would make sense to add an 'avr-unknown-unknown-atmega328' target as a better default when implemented. There is no current intention to add in-tree AVR target specifications for other AVR microcontrollers - this one can serve as a reference implementation for other devices via `rustc --print target-spec-json avr-unknown-gnu-atmega328p`. There should be no users of the existing 'avr-unknown-unknown' Rust target as a custom target specification JSON has always been recommended and the avr-unknown-unknown target could never pass the linking step anyway.,THUMBS_UP,2020-08-27T19:11:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/74948,MERGED,2020-07-30T15:58:45Z,2020-08-03T01:50:35Z,Stabilize `Result::as_deref` and `as_deref_mut`,tesuji,19ecce332e56941ea0dd2a805270faa102acdb14,13,Auto merge of #74948 - lzutao:stalize-result-as-deref r=dtolnay Stabilize `Result::as_deref` and `as_deref_mut` FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400. This PR stabilizes two new APIs for `std::result::Result`: ```rust fn as_deref(&self) -> Result<&T::Target &E> where T: Deref; fn as_deref_mut(&mut self) -> Result<&mut T::Target &mut E> where T: DerefMut; ``` This PR also removes two rarely used unstable APIs from `Result`: ```rust fn as_deref_err(&self) -> Result<&T &E::Target> where E: Deref; fn as_deref_mut_err(&mut self) -> Result<&mut T &mut E::Target> where E: DerefMut; ``` Closes #50264,HEART,2020-08-01T12:07:56Z,RalfJung,NA https://github.com/rust-lang/rust/pull/74948,MERGED,2020-07-30T15:58:45Z,2020-08-03T01:50:35Z,Stabilize `Result::as_deref` and `as_deref_mut`,tesuji,19ecce332e56941ea0dd2a805270faa102acdb14,13,Auto merge of #74948 - lzutao:stalize-result-as-deref r=dtolnay Stabilize `Result::as_deref` and `as_deref_mut` FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400. This PR stabilizes two new APIs for `std::result::Result`: ```rust fn as_deref(&self) -> Result<&T::Target &E> where T: Deref; fn as_deref_mut(&mut self) -> Result<&mut T::Target &mut E> where T: DerefMut; ``` This PR also removes two rarely used unstable APIs from `Result`: ```rust fn as_deref_err(&self) -> Result<&T &E::Target> where E: Deref; fn as_deref_mut_err(&mut self) -> Result<&mut T &mut E::Target> where E: DerefMut; ``` Closes #50264,HEART,2020-08-03T13:43:47Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/74948,MERGED,2020-07-30T15:58:45Z,2020-08-03T01:50:35Z,Stabilize `Result::as_deref` and `as_deref_mut`,tesuji,19ecce332e56941ea0dd2a805270faa102acdb14,13,Auto merge of #74948 - lzutao:stalize-result-as-deref r=dtolnay Stabilize `Result::as_deref` and `as_deref_mut` FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400. This PR stabilizes two new APIs for `std::result::Result`: ```rust fn as_deref(&self) -> Result<&T::Target &E> where T: Deref; fn as_deref_mut(&mut self) -> Result<&mut T::Target &mut E> where T: DerefMut; ``` This PR also removes two rarely used unstable APIs from `Result`: ```rust fn as_deref_err(&self) -> Result<&T &E::Target> where E: Deref; fn as_deref_mut_err(&mut self) -> Result<&mut T &mut E::Target> where E: DerefMut; ``` Closes #50264,HEART,2020-08-05T20:17:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74951,MERGED,2020-07-30T18:39:51Z,2020-07-30T23:18:29Z,Cherry-pick the release notes for 1.45.1,cuviper,9eb50260bd06fa005f7f146702565dfdc7c3b4de,1,Rollup merge of #74951 - cuviper:relnotes-1.45.1 r=jonas-schievink Cherry-pick the release notes for 1.45.1,HOORAY,2020-07-30T18:52:30Z,yerke,NA https://github.com/rust-lang/rust/pull/74951,MERGED,2020-07-30T18:39:51Z,2020-07-30T23:18:29Z,Cherry-pick the release notes for 1.45.1,cuviper,9eb50260bd06fa005f7f146702565dfdc7c3b4de,1,Rollup merge of #74951 - cuviper:relnotes-1.45.1 r=jonas-schievink Cherry-pick the release notes for 1.45.1,HOORAY,2020-07-31T03:51:55Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/74953,MERGED,2020-07-30T18:58:48Z,2020-08-10T17:13:17Z,Remove restriction on type parameters preceding consts w/ feature const-generics,JulianKnodt,08324fe6f7ac24be4c8bfcab42b12ee447635c80,18,Auto merge of #74953 - JulianKnodt:master r=lcnr Remove restriction on type parameters preceding consts w/ feature const-generics Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled. Builds on #74676 which deals with unsorted generic parameters. This just lifts the check in lowering the AST to HIR that permits consts and types to be reordered with respect to each other. Lifetimes still must precede both This change is not intended for min-const-generics and is gated behind the `#![feature(const_generics)]`. One thing is that it also permits type parameters without a default to come after consts which I expected to not work and was hoping to get more guidance on whether that should be permitted or how to prevent it otherwise. I did not go through the RFC process for this pull request because there was prior work to get this feature added. In the previous PR that was cited work was done to enable this change. r? @lcnr,HEART,2020-07-30T19:41:46Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/74953,MERGED,2020-07-30T18:58:48Z,2020-08-10T17:13:17Z,Remove restriction on type parameters preceding consts w/ feature const-generics,JulianKnodt,08324fe6f7ac24be4c8bfcab42b12ee447635c80,18,Auto merge of #74953 - JulianKnodt:master r=lcnr Remove restriction on type parameters preceding consts w/ feature const-generics Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled. Builds on #74676 which deals with unsorted generic parameters. This just lifts the check in lowering the AST to HIR that permits consts and types to be reordered with respect to each other. Lifetimes still must precede both This change is not intended for min-const-generics and is gated behind the `#![feature(const_generics)]`. One thing is that it also permits type parameters without a default to come after consts which I expected to not work and was hoping to get more guidance on whether that should be permitted or how to prevent it otherwise. I did not go through the RFC process for this pull request because there was prior work to get this feature added. In the previous PR that was cited work was done to enable this change. r? @lcnr,HEART,2020-08-13T17:04:57Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/74955,MERGED,2020-07-30T19:14:54Z,2020-07-31T06:35:16Z,Add `--output-format json` for Rustdoc on nightly,P1n3appl3,66b97dca3c8ab51f8af7b2db7ae4c8061fbf5e9b,3,Auto merge of #74955 - P1n3appl3:rustdoc-formats r=GuillaumeGomez Add `--output-format json` for Rustdoc on nightly This enables the previously deprecated `--output-format` flag so it can be used on nightly to host the experimental implementation of [rfc/2963](https://github.com/rust-lang/rfcs/pull/2963). The actual implementation will come in later PRs so for now there's just a stub that gives you an ICE. I'm _pretty_ sure that the logic I added makes it inaccessible from stable but someone should double check that. @tmandry @jyn514,ROCKET,2020-07-30T20:21:42Z,rrbutani,NA https://github.com/rust-lang/rust/pull/74955,MERGED,2020-07-30T19:14:54Z,2020-07-31T06:35:16Z,Add `--output-format json` for Rustdoc on nightly,P1n3appl3,66b97dca3c8ab51f8af7b2db7ae4c8061fbf5e9b,3,Auto merge of #74955 - P1n3appl3:rustdoc-formats r=GuillaumeGomez Add `--output-format json` for Rustdoc on nightly This enables the previously deprecated `--output-format` flag so it can be used on nightly to host the experimental implementation of [rfc/2963](https://github.com/rust-lang/rfcs/pull/2963). The actual implementation will come in later PRs so for now there's just a stub that gives you an ICE. I'm _pretty_ sure that the logic I added makes it inaccessible from stable but someone should double check that. @tmandry @jyn514,ROCKET,2020-07-30T21:52:37Z,tmandry,NA https://github.com/rust-lang/rust/pull/74955,MERGED,2020-07-30T19:14:54Z,2020-07-31T06:35:16Z,Add `--output-format json` for Rustdoc on nightly,P1n3appl3,66b97dca3c8ab51f8af7b2db7ae4c8061fbf5e9b,3,Auto merge of #74955 - P1n3appl3:rustdoc-formats r=GuillaumeGomez Add `--output-format json` for Rustdoc on nightly This enables the previously deprecated `--output-format` flag so it can be used on nightly to host the experimental implementation of [rfc/2963](https://github.com/rust-lang/rfcs/pull/2963). The actual implementation will come in later PRs so for now there's just a stub that gives you an ICE. I'm _pretty_ sure that the logic I added makes it inaccessible from stable but someone should double check that. @tmandry @jyn514,ROCKET,2020-09-03T16:07:40Z,MOZGIII,NA https://github.com/rust-lang/rust/pull/74955,MERGED,2020-07-30T19:14:54Z,2020-07-31T06:35:16Z,Add `--output-format json` for Rustdoc on nightly,P1n3appl3,66b97dca3c8ab51f8af7b2db7ae4c8061fbf5e9b,3,Auto merge of #74955 - P1n3appl3:rustdoc-formats r=GuillaumeGomez Add `--output-format json` for Rustdoc on nightly This enables the previously deprecated `--output-format` flag so it can be used on nightly to host the experimental implementation of [rfc/2963](https://github.com/rust-lang/rfcs/pull/2963). The actual implementation will come in later PRs so for now there's just a stub that gives you an ICE. I'm _pretty_ sure that the logic I added makes it inaccessible from stable but someone should double check that. @tmandry @jyn514,ROCKET,2020-12-02T01:07:57Z,tjkirch,NA https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,THUMBS_UP,2020-07-30T20:07:16Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,THUMBS_UP,2020-07-30T22:38:29Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,THUMBS_UP,2020-07-31T04:18:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,THUMBS_UP,2020-08-06T17:31:55Z,eopb,NA https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,EYES,2020-08-07T02:22:10Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/74956,MERGED,2020-07-30T19:36:02Z,2020-07-31T10:16:59Z,Make `Option::unwrap` unstably const,ecstatic-morse,3a92b9987abd01c4b7e59c870e85beb9dd4d4aa2,4,Auto merge of #74956 - ecstatic-morse:const-option-unwrap r=oli-obk Make `Option::unwrap` unstably const This is lumped into the `const_option` feature gate (#67441) which enables a potpourri of `Option` methods. cc @rust-lang/wg-const-eval r? @oli-obk,HOORAY,2020-09-01T07:03:39Z,faern,NA https://github.com/rust-lang/rust/pull/74959,MERGED,2020-07-30T20:25:28Z,2020-07-31T08:26:33Z,Rust function-level coverage now works on external crates,richkadel,ac91673d895a0c578ed773e1280bdde8adb87b8c,2,"Auto merge of #74959 - richkadel:llvm-coverage-map-gen-5.1 r=tmandry Rust function-level coverage now works on external crates Follow-up to a known issue discussed (post-merge) in #74733: Resolves a known issue in the coverage map where some regions had nonsensical source code locations. External crate functions are already included in their own coverage maps per library and don't need to also be added to the importing crate's coverage map. (In fact their source start and end byte positions are not relevant to the importing crate's SourceMap.) The fix was to simply skip trying to add imported coverage info to the coverage map if the instrumented function is not ""local"". The injected counters are still relevant however and the LLVM `instrprof.increment` intrinsic call parameters will map those counters to the external crates' coverage maps when generating runtime coverage data. Now Rust Coverage can cleanly instrument and analyze coverage on an entire crate and its dependencies. Example (instrumenting https://github.com/google/json5format): ```bash $ ./x.py build rust-demangler # make sure the demangler is built $ cd ~/json5format $ RUSTC=$HOME/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ RUSTFLAGS=""-Zinstrument-coverage"" \ cargo build --example formatjson5 $ LLVM_PROFILE_FILE=""formatjson5.profraw"" \ ./target/debug/examples/formatjson5 session_manager.cml $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-profdata merge \ -sparse formatjson5.profraw -o formatjson5.profdata $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-cov show --use-color \ --instr-profile=formatjson5.profdata target/debug/examples/formatjson5 \ --show-line-counts-or-regions \ --Xdemangler=$HOME/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/rust-demangler \ --show-instantiations \ 2>&1 | less -R ``` (Scan forward for some of the non-zero coverage results with `/^....[0-9]\| *[^ |0]`.) ",HOORAY,2020-07-30T21:23:53Z,tmandry,NA https://github.com/rust-lang/rust/pull/74959,MERGED,2020-07-30T20:25:28Z,2020-07-31T08:26:33Z,Rust function-level coverage now works on external crates,richkadel,ac91673d895a0c578ed773e1280bdde8adb87b8c,2,"Auto merge of #74959 - richkadel:llvm-coverage-map-gen-5.1 r=tmandry Rust function-level coverage now works on external crates Follow-up to a known issue discussed (post-merge) in #74733: Resolves a known issue in the coverage map where some regions had nonsensical source code locations. External crate functions are already included in their own coverage maps per library and don't need to also be added to the importing crate's coverage map. (In fact their source start and end byte positions are not relevant to the importing crate's SourceMap.) The fix was to simply skip trying to add imported coverage info to the coverage map if the instrumented function is not ""local"". The injected counters are still relevant however and the LLVM `instrprof.increment` intrinsic call parameters will map those counters to the external crates' coverage maps when generating runtime coverage data. Now Rust Coverage can cleanly instrument and analyze coverage on an entire crate and its dependencies. Example (instrumenting https://github.com/google/json5format): ```bash $ ./x.py build rust-demangler # make sure the demangler is built $ cd ~/json5format $ RUSTC=$HOME/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ RUSTFLAGS=""-Zinstrument-coverage"" \ cargo build --example formatjson5 $ LLVM_PROFILE_FILE=""formatjson5.profraw"" \ ./target/debug/examples/formatjson5 session_manager.cml $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-profdata merge \ -sparse formatjson5.profraw -o formatjson5.profdata $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-cov show --use-color \ --instr-profile=formatjson5.profdata target/debug/examples/formatjson5 \ --show-line-counts-or-regions \ --Xdemangler=$HOME/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/rust-demangler \ --show-instantiations \ 2>&1 | less -R ``` (Scan forward for some of the non-zero coverage results with `/^....[0-9]\| *[^ |0]`.) ",HOORAY,2020-07-30T21:45:53Z,marmeladema,NA https://github.com/rust-lang/rust/pull/74959,MERGED,2020-07-30T20:25:28Z,2020-07-31T08:26:33Z,Rust function-level coverage now works on external crates,richkadel,ac91673d895a0c578ed773e1280bdde8adb87b8c,2,"Auto merge of #74959 - richkadel:llvm-coverage-map-gen-5.1 r=tmandry Rust function-level coverage now works on external crates Follow-up to a known issue discussed (post-merge) in #74733: Resolves a known issue in the coverage map where some regions had nonsensical source code locations. External crate functions are already included in their own coverage maps per library and don't need to also be added to the importing crate's coverage map. (In fact their source start and end byte positions are not relevant to the importing crate's SourceMap.) The fix was to simply skip trying to add imported coverage info to the coverage map if the instrumented function is not ""local"". The injected counters are still relevant however and the LLVM `instrprof.increment` intrinsic call parameters will map those counters to the external crates' coverage maps when generating runtime coverage data. Now Rust Coverage can cleanly instrument and analyze coverage on an entire crate and its dependencies. Example (instrumenting https://github.com/google/json5format): ```bash $ ./x.py build rust-demangler # make sure the demangler is built $ cd ~/json5format $ RUSTC=$HOME/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ RUSTFLAGS=""-Zinstrument-coverage"" \ cargo build --example formatjson5 $ LLVM_PROFILE_FILE=""formatjson5.profraw"" \ ./target/debug/examples/formatjson5 session_manager.cml $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-profdata merge \ -sparse formatjson5.profraw -o formatjson5.profdata $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-cov show --use-color \ --instr-profile=formatjson5.profdata target/debug/examples/formatjson5 \ --show-line-counts-or-regions \ --Xdemangler=$HOME/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/rust-demangler \ --show-instantiations \ 2>&1 | less -R ``` (Scan forward for some of the non-zero coverage results with `/^....[0-9]\| *[^ |0]`.) ",HOORAY,2020-07-31T02:11:54Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/74959,MERGED,2020-07-30T20:25:28Z,2020-07-31T08:26:33Z,Rust function-level coverage now works on external crates,richkadel,ac91673d895a0c578ed773e1280bdde8adb87b8c,2,"Auto merge of #74959 - richkadel:llvm-coverage-map-gen-5.1 r=tmandry Rust function-level coverage now works on external crates Follow-up to a known issue discussed (post-merge) in #74733: Resolves a known issue in the coverage map where some regions had nonsensical source code locations. External crate functions are already included in their own coverage maps per library and don't need to also be added to the importing crate's coverage map. (In fact their source start and end byte positions are not relevant to the importing crate's SourceMap.) The fix was to simply skip trying to add imported coverage info to the coverage map if the instrumented function is not ""local"". The injected counters are still relevant however and the LLVM `instrprof.increment` intrinsic call parameters will map those counters to the external crates' coverage maps when generating runtime coverage data. Now Rust Coverage can cleanly instrument and analyze coverage on an entire crate and its dependencies. Example (instrumenting https://github.com/google/json5format): ```bash $ ./x.py build rust-demangler # make sure the demangler is built $ cd ~/json5format $ RUSTC=$HOME/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ RUSTFLAGS=""-Zinstrument-coverage"" \ cargo build --example formatjson5 $ LLVM_PROFILE_FILE=""formatjson5.profraw"" \ ./target/debug/examples/formatjson5 session_manager.cml $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-profdata merge \ -sparse formatjson5.profraw -o formatjson5.profdata $ ~/rust/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-cov show --use-color \ --instr-profile=formatjson5.profdata target/debug/examples/formatjson5 \ --show-line-counts-or-regions \ --Xdemangler=$HOME/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/rust-demangler \ --show-instantiations \ 2>&1 | less -R ``` (Scan forward for some of the non-zero coverage results with `/^....[0-9]\| *[^ |0]`.) ",HOORAY,2020-07-31T15:03:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/74960,MERGED,2020-07-30T20:35:00Z,2020-08-12T06:39:13Z,Fix regionck failure when converting Index to IndexMut,nbdd0121,43babed7e2ecebc401a6dd792e52700afbe0ec5c,2,Rollup merge of #74960 - nbdd0121:typeck r=nikomatsakis Fix regionck failure when converting Index to IndexMut Fixes #74933 Consider an overloaded index expression `base[index]`. Without knowing whether it will be mutated this will initially be desugared into `>::index(&base index)` for some `U` and `T`. Let `V` be the `expr_ty_adjusted` of `index`. If this expression ends up being used in any mutable context (or used in a function call with `&mut self` receiver before #72280) we will need to fix it up. The current code will rewrite it to `>::index_mut(&mut base index)`. In most cases this is fine as `V` will be equal to `T` however this is not always true when `V/T` are references as they may have different region. This issue is quite subtle before #72280 as this code path is only used to fixup function receivers but after #72280 we've made this a common path. The solution is basically just rewrite it to `>::index_mut(&mut base index)`. `T` can retrieved in the fixup path using `node_substs`.,THUMBS_UP,2020-07-31T04:34:19Z,estebank,NA https://github.com/rust-lang/rust/pull/74963,MERGED,2020-07-30T22:41:41Z,2020-08-02T19:48:54Z,Fix ICEs with `@ ..` binding,JohnTitor,19cefa68640843956eedd86227ddc1d35dbc6754,13,Auto merge of #74963 - JohnTitor:ptn-ice r=petrochenkov Fix ICEs with `@ ..` binding This reverts #74557 and introduces an alternative fix while ensuring that #74954 is not broken. The diagnostics are verbose though it fixes three related issues. cc #74954 #74539 and #74702,THUMBS_UP,2020-07-31T17:37:33Z,estebank,NA https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-07-31T09:47:15Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-07-31T17:13:59Z,tesuji,NA https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-08-02T06:55:09Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-08-06T19:52:14Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-08-27T13:41:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,HOORAY,2020-11-22T21:27:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74967,MERGED,2020-07-31T03:44:24Z,2020-12-01T16:53:24Z,Implement lazy decoding of DefPathTable during incremental compilation,Aaron1011,4cbda829c00af2c3ac362c979fa97ea90be0be7d,11,Auto merge of #74967 - Aaron1011:feature/incr-def-path-table r=pnkfelix Implement lazy decoding of DefPathTable during incremental compilation PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However it requires decoding the entire `DefPathTable` when incremental compilation is active so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate. This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active. When we load the incremental cache and dep graph we need the ability to map a `DefPathHash` to a `DefId` in the current compilation session (if the corresponding definition still exists). This is accomplished by storing the old `DefId` (that is the `DefId` from the previous compilation session) for each `DefPathHash` we need to remap. Since a `DefPathHash` includes the owning crate the old crate is guaranteed to be the right one (if the definition still exists). We then use the old `DefIndex` as an initial guess which we validate by comparing the expected and actual `DefPathHash`es. In most cases foreign crates will be completely unchanged which means that we our guess will be correct. If our guess is wrong we fall back to decoding the entire `DefPathTable` for the foreign crate. This still represents an improvement over the status quo since we can skip decoding the entire `DefPathTable` for other crates (where all of our guesses were correct).,ROCKET,2020-11-22T21:27:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/74969,MERGED,2020-07-31T05:40:50Z,2020-08-03T03:37:41Z,Remove `GCX_PTR`.,nnethercote,8244b1b11488a336a485f07fd6550b973009a931,9,Auto merge of #74969 - nnethercote:rm-GCX_PTR r=Mark-Simulacrum Remove `GCX_PTR`. We store an `ImplicitCtxt` pointer in a thread-local value (TLV). This allows implicit access to a `GlobalCtxt` and some other things. We also store a `GlobalCtxt` pointer in `GCX_PTR`. This is always the same `GlobalCtxt` as the one within the `ImplicitCtxt` pointer in TLV. `GCX_PTR` is only used in the parallel compiler's `handle_deadlock()` function. This commit does the following. - It removes `GCX_PTR`. - It also adds `ImplicitCtxt::new()` which constructs an `ImplicitCtxt` from a `GlobalCtxt`. `ImplicitCtxt::new()` + `tls::enter_context()` is now equivalent to the old `tls::enter_global()`. - Makes `tls::get_tlv()` public for the parallel compiler because it's now used in `handle_deadlock()`. r? @petrochenkov,THUMBS_UP,2020-07-31T05:49:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/74971,CLOSED,2020-07-31T08:23:00Z,2020-09-24T00:03:46Z,Separate unsized fn params from unsized locals,JohnTitor,NA,NA,NA,HEART,2020-08-05T13:00:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/74971,CLOSED,2020-07-31T08:23:00Z,2020-09-24T00:03:46Z,Separate unsized fn params from unsized locals,JohnTitor,NA,NA,NA,HEART,2020-08-11T05:59:18Z,estebank,NA https://github.com/rust-lang/rust/pull/74986,MERGED,2020-07-31T19:26:52Z,2020-08-01T02:48:00Z,"fix part of comparison that would always evaluate to ""true"" probably an oversight",matthiaskrgr,ff5ccc82eb58d76f5f4335dad4642becd1c69539,1,"Rollup merge of #74986 - matthiaskrgr:cmp_true r=oli-obk fix part of comparison that would always evaluate to ""true"" probably an oversight cc @jumbatm",HEART,2020-07-31T22:04:40Z,jumbatm,NA https://github.com/rust-lang/rust/pull/74988,MERGED,2020-07-31T20:11:30Z,2020-07-31T23:52:38Z,[stable] Update to 1.45.2,Mark-Simulacrum,d3fb005a39e62501b8b0b356166e515ae24e2e54,1,Auto merge of #74988 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] Update to 1.45.2 This just bumps the release number which I forgot to do in the previous PR (#74958). r? @ghost,LAUGH,2020-07-31T20:24:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",HEART,2020-07-31T23:07:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",EYES,2020-08-01T01:25:21Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",HEART,2020-08-05T17:07:43Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",HEART,2020-09-09T22:11:09Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",HEART,2020-09-10T04:42:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",EYES,2020-09-10T04:42:11Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",THUMBS_UP,2020-09-10T06:41:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",THUMBS_UP,2020-11-18T09:48:59Z,GrayJack,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",THUMBS_UP,2020-11-26T17:03:06Z,robatipoor,NA https://github.com/rust-lang/rust/pull/74989,MERGED,2020-07-31T20:30:42Z,2020-11-17T01:15:04Z,Implement `Index` and `IndexMut` for arrays,pubfnbar,4cdd22062580b46cbb6cf97ca56d59ebeb1e91b7,1,"Rollup merge of #74989 - pubfnbar:impl-array-indexing r=KodrAus Implement `Index` and `IndexMut` for arrays Adds implementations of `Index` and `IndexMut` for arrays that simply forward to the slice indexing implementation in order to fix the following problem: If you implement `Index` for an array you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about: ```rust use std::ops::Index; pub enum MyIndexType { _0 _1 _2 _3 _4 _5 _6 _7 } impl Index for [T; 8] { type Output = T; fn index(&self index: MyIndexType) -> &T { unsafe { self.get_unchecked(index as usize) } } } fn main() { let array = [11u8; 8]; println!(""{:?}"" array[MyIndexType::_0]); // OK println!(""{:?}"" array[0usize]); // error[E0277] // ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize` } ```",THUMBS_UP,2020-12-29T15:56:21Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/75005,MERGED,2020-08-01T12:32:54Z,2020-08-05T19:56:54Z,Limit I/O vector count on Unix,adamreichold,52b179b4b51e3d1bbc5d687f8680c38321678830,1,Auto merge of #75005 - adamreichold:limit-vector-count r=Amanieu Limit I/O vector count on Unix Unix systems enforce limits on the vector count when performing vectored I/O via the readv and writev system calls and return EINVAL when these limits are exceeded. This changes the standard library to handle those limits as short reads and writes to avoid forcing its users to query these limits using platform specific mechanisms. Fixes #68042,THUMBS_UP,2020-08-01T12:43:23Z,ctz,NA https://github.com/rust-lang/rust/pull/75005,MERGED,2020-08-01T12:32:54Z,2020-08-05T19:56:54Z,Limit I/O vector count on Unix,adamreichold,52b179b4b51e3d1bbc5d687f8680c38321678830,1,Auto merge of #75005 - adamreichold:limit-vector-count r=Amanieu Limit I/O vector count on Unix Unix systems enforce limits on the vector count when performing vectored I/O via the readv and writev system calls and return EINVAL when these limits are exceeded. This changes the standard library to handle those limits as short reads and writes to avoid forcing its users to query these limits using platform specific mechanisms. Fixes #68042,HOORAY,2020-08-13T05:54:34Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/75008,MERGED,2020-08-01T13:31:09Z,2020-08-06T05:11:38Z,rustc_metadata: track the simplified Self type for every trait impl.,eddyb,3cfc7fe78eccc754b16981704a098d7bd520e2fd,6,"Auto merge of #75008 - eddyb:rmeta-indexed-trait-impls r=nikomatsakis rustc_metadata: track the simplified Self type for every trait impl. For the `traits_impls_of` query we index the impls by `fast_reject::SimplifiedType` (a ""shallow type"") which allows some simple cases like `impl Trait<..> for Foo<..>` to be efficiently iterated over by e.g. `for_each_relevant_impl`. This PR encodes the `fast_reject::SimplifiedType` cross-crate to avoid needing to deserialize the `Self` type of every `impl` in order to simplify it - the simplification itself should be cheap but the deserialization is less so. We could go further from here and make loading the list of impls lazy for a given simplified `Self` type but that would have more complicated implications for performance and this PR doesn't do anything in that regard. r? @nikomatsakis cc @Mark-Simulacrum",ROCKET,2020-08-03T23:12:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75008,MERGED,2020-08-01T13:31:09Z,2020-08-06T05:11:38Z,rustc_metadata: track the simplified Self type for every trait impl.,eddyb,3cfc7fe78eccc754b16981704a098d7bd520e2fd,6,"Auto merge of #75008 - eddyb:rmeta-indexed-trait-impls r=nikomatsakis rustc_metadata: track the simplified Self type for every trait impl. For the `traits_impls_of` query we index the impls by `fast_reject::SimplifiedType` (a ""shallow type"") which allows some simple cases like `impl Trait<..> for Foo<..>` to be efficiently iterated over by e.g. `for_each_relevant_impl`. This PR encodes the `fast_reject::SimplifiedType` cross-crate to avoid needing to deserialize the `Self` type of every `impl` in order to simplify it - the simplification itself should be cheap but the deserialization is less so. We could go further from here and make loading the list of impls lazy for a given simplified `Self` type but that would have more complicated implications for performance and this PR doesn't do anything in that regard. r? @nikomatsakis cc @Mark-Simulacrum",ROCKET,2020-08-05T06:42:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75010,MERGED,2020-08-01T14:15:27Z,2020-08-02T17:55:00Z,Update elasticlunr-rs and ammonia transitive deps,Aaron1011,21ebf6900d2cbe68169df7436636c2c7f3dc158a,2,Rollup merge of #75010 - Aaron1011:feature/remove-old-deps r=Mark-Simulacrum Update elasticlunr-rs and ammonia transitive deps This removes all dependencies on pre-1.0 proc-macro ecosystem crates (syn quote and proc-macro2),HEART,2020-08-01T16:03:12Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75010,MERGED,2020-08-01T14:15:27Z,2020-08-02T17:55:00Z,Update elasticlunr-rs and ammonia transitive deps,Aaron1011,21ebf6900d2cbe68169df7436636c2c7f3dc158a,2,Rollup merge of #75010 - Aaron1011:feature/remove-old-deps r=Mark-Simulacrum Update elasticlunr-rs and ammonia transitive deps This removes all dependencies on pre-1.0 proc-macro ecosystem crates (syn quote and proc-macro2),HEART,2020-08-01T16:32:21Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75010,MERGED,2020-08-01T14:15:27Z,2020-08-02T17:55:00Z,Update elasticlunr-rs and ammonia transitive deps,Aaron1011,21ebf6900d2cbe68169df7436636c2c7f3dc158a,2,Rollup merge of #75010 - Aaron1011:feature/remove-old-deps r=Mark-Simulacrum Update elasticlunr-rs and ammonia transitive deps This removes all dependencies on pre-1.0 proc-macro ecosystem crates (syn quote and proc-macro2),HEART,2020-08-01T17:04:48Z,panaman67,NA https://github.com/rust-lang/rust/pull/75010,MERGED,2020-08-01T14:15:27Z,2020-08-02T17:55:00Z,Update elasticlunr-rs and ammonia transitive deps,Aaron1011,21ebf6900d2cbe68169df7436636c2c7f3dc158a,2,Rollup merge of #75010 - Aaron1011:feature/remove-old-deps r=Mark-Simulacrum Update elasticlunr-rs and ammonia transitive deps This removes all dependencies on pre-1.0 proc-macro ecosystem crates (syn quote and proc-macro2),HEART,2020-08-02T02:39:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/75015,MERGED,2020-08-01T16:06:48Z,2020-08-02T03:47:32Z,Add Vec::spare_capacity_mut,Amanieu,d544e21dc3fbae5b62acb0dfc8151ed1c8500e2e,1,Rollup merge of #75015 - Amanieu:vec_spare r=sfackler Add Vec::spare_capacity_mut Returns the remaining spare capacity of the vector as a slice of `MaybeUninit`. As suggested by @sfackler in https://github.com/rust-lang/rust/pull/70967#issuecomment-612659006. r? @sfackler,THUMBS_UP,2020-08-06T12:11:19Z,Thomasdezeeuw,thomasdezeeuw@gmail.com https://github.com/rust-lang/rust/pull/75020,MERGED,2020-08-01T17:25:46Z,2020-11-02T10:44:26Z,Avoid complex diagnostics in snippets which contain newlines,JohnTitor,234099d1d12bef9d6e81a296222fbc272dc51d89,4,Auto merge of #75020 - JohnTitor:fix-multispan r=estebank tmandry Avoid complex diagnostics in snippets which contain newlines Fixes #70935 r? `@estebank` `@tmandry`,THUMBS_UP,2020-08-02T02:42:30Z,estebank,NA https://github.com/rust-lang/rust/pull/75023,MERGED,2020-08-01T19:03:09Z,2020-10-16T02:29:54Z,ensure arguments are included in count mismatch span,euclio,075f2bfc393c0c4efc8d18d839c0d91c496dbaba,21,"Rollup merge of #75023 - euclio:argument-span r=estebank ensure arguments are included in count mismatch span The current diagnostic isn't very helpful if the function header spans multiple lines. Lines comprising the function signature may be elided to keep the diagnostic short but these lines are essential to fixing the error. This is made worse when the function has a body because the last two lines of the span are then dedicated to showing the end of the body which is irrelevant. This PR changes the span to be a multispan made up of the header and the the arguments ensuring they won't be elided. It also discards the function body from the span. [Old](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f92d9f81a8c9416f0f04e4e09923b6d4): ``` error[E0061]: this function takes 6 arguments but 1 argument was supplied --> src/main.rs:18:5 | 1 | / fn bar( 2 | | a: i32 3 | | b: i32 4 | | c: i32 ... | 14 | | println!(""{}"" f); 15 | | } | |_- defined here ... 18 | bar(1); | ^^^ - supplied 1 argument | | | expected 6 arguments ``` New: ``` error[E0061]: this function takes 6 arguments but 1 argument was supplied --> $DIR/not-enough-arguments.rs:28:3 | LL | bar(1); | ^^^ - supplied 1 argument | | | expected 6 arguments | note: function defined here --> $DIR/not-enough-arguments.rs:9:1 | LL | / fn bar( LL | | a: i32 | | ^^^^^^^ LL | | b: i32 | | ^^^^^^^ LL | | c: i32 | | ^^^^^^^ LL | | d: i32 | | ^^^^^^^ LL | | e: i32 | | ^^^^^^^ LL | | f: i32 | | ^^^^^^^ LL | | ) { | |_^ ```",THUMBS_UP,2020-08-01T20:33:33Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75023,MERGED,2020-08-01T19:03:09Z,2020-10-16T02:29:54Z,ensure arguments are included in count mismatch span,euclio,075f2bfc393c0c4efc8d18d839c0d91c496dbaba,21,"Rollup merge of #75023 - euclio:argument-span r=estebank ensure arguments are included in count mismatch span The current diagnostic isn't very helpful if the function header spans multiple lines. Lines comprising the function signature may be elided to keep the diagnostic short but these lines are essential to fixing the error. This is made worse when the function has a body because the last two lines of the span are then dedicated to showing the end of the body which is irrelevant. This PR changes the span to be a multispan made up of the header and the the arguments ensuring they won't be elided. It also discards the function body from the span. [Old](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f92d9f81a8c9416f0f04e4e09923b6d4): ``` error[E0061]: this function takes 6 arguments but 1 argument was supplied --> src/main.rs:18:5 | 1 | / fn bar( 2 | | a: i32 3 | | b: i32 4 | | c: i32 ... | 14 | | println!(""{}"" f); 15 | | } | |_- defined here ... 18 | bar(1); | ^^^ - supplied 1 argument | | | expected 6 arguments ``` New: ``` error[E0061]: this function takes 6 arguments but 1 argument was supplied --> $DIR/not-enough-arguments.rs:28:3 | LL | bar(1); | ^^^ - supplied 1 argument | | | expected 6 arguments | note: function defined here --> $DIR/not-enough-arguments.rs:9:1 | LL | / fn bar( LL | | a: i32 | | ^^^^^^^ LL | | b: i32 | | ^^^^^^^ LL | | c: i32 | | ^^^^^^^ LL | | d: i32 | | ^^^^^^^ LL | | e: i32 | | ^^^^^^^ LL | | f: i32 | | ^^^^^^^ LL | | ) { | |_^ ```",THUMBS_UP,2020-08-02T20:39:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,THUMBS_UP,2020-08-01T20:54:28Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,HEART,2020-08-01T20:54:59Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,HEART,2020-08-01T23:51:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,THUMBS_UP,2020-08-01T23:51:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,HEART,2020-08-02T12:18:38Z,janriemer,NA https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,THUMBS_UP,2020-08-02T12:18:39Z,janriemer,NA https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,EYES,2020-08-11T16:20:37Z,billyrieger,NA https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,THUMBS_UP,2020-08-14T00:26:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75026,MERGED,2020-08-01T20:38:49Z,2020-09-16T22:38:09Z,Add array_windows fn,JulianKnodt,23a677787e4e36894fa8bd94c8d525f2a7d936f8,7,Rollup merge of #75026 - JulianKnodt:array_windows r=Amanieu Add array_windows fn This mimicks the functionality added by array_chunks and implements a const-generic form of `windows`. It makes egregious use of `unsafe` but by necessity because the array must be re-interpreted as a slice of arrays and unlike array_chunks this cannot be done by casting the original array once since each time the index is advanced it needs to move one element not `N`. I'm planning on adding more tests but this should be good enough as a premise for the functionality. Notably: should there be more functions overwritten for the iterator implementation/in general? ~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows` but it's based of off `array_chunks`.~~ Edit: See Issue #75027 created by @lcnr for tracking issue ~~Do not merge until I add more tests please.~~ r? @lcnr,HEART,2020-09-16T19:22:00Z,tmandry,NA https://github.com/rust-lang/rust/pull/75037,MERGED,2020-08-02T04:20:29Z,2020-08-05T06:56:00Z,Completes support for coverage in external crates,richkadel,dab2ae0404014b4fbc5a32a8c954fe6068b25f71,15,Auto merge of #75037 - richkadel:llvm-coverage-map-gen-5.2 r=wesleywiser Completes support for coverage in external crates Follow-up to #74959 : The prior PR corrected for errors encountered when trying to generate the coverage map on source code inlined from external crates (including macros and generics) by avoiding adding external DefIds to the coverage map. This made it possible to generate a coverage report including external crates but the external crate coverage was incomplete (did not include coverage for the DefIds that were eliminated. The root issue was that the coverage map was converting Span locations to source file and locations using the SourceMap for the current crate and this would not work for spans from external crates (compliled with a different SourceMap). The solution was to convert the Spans to filename and location during MIR generation instead so precompiled external crates would already have the correct source code locations embedded in their MIR when imported into another crate. @wesleywiser FYI r? @tmandry,THUMBS_UP,2020-08-03T01:24:04Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75037,MERGED,2020-08-02T04:20:29Z,2020-08-05T06:56:00Z,Completes support for coverage in external crates,richkadel,dab2ae0404014b4fbc5a32a8c954fe6068b25f71,15,Auto merge of #75037 - richkadel:llvm-coverage-map-gen-5.2 r=wesleywiser Completes support for coverage in external crates Follow-up to #74959 : The prior PR corrected for errors encountered when trying to generate the coverage map on source code inlined from external crates (including macros and generics) by avoiding adding external DefIds to the coverage map. This made it possible to generate a coverage report including external crates but the external crate coverage was incomplete (did not include coverage for the DefIds that were eliminated. The root issue was that the coverage map was converting Span locations to source file and locations using the SourceMap for the current crate and this would not work for spans from external crates (compliled with a different SourceMap). The solution was to convert the Spans to filename and location during MIR generation instead so precompiled external crates would already have the correct source code locations embedded in their MIR when imported into another crate. @wesleywiser FYI r? @tmandry,THUMBS_UP,2020-08-03T09:44:49Z,jschwe,NA https://github.com/rust-lang/rust/pull/75037,MERGED,2020-08-02T04:20:29Z,2020-08-05T06:56:00Z,Completes support for coverage in external crates,richkadel,dab2ae0404014b4fbc5a32a8c954fe6068b25f71,15,Auto merge of #75037 - richkadel:llvm-coverage-map-gen-5.2 r=wesleywiser Completes support for coverage in external crates Follow-up to #74959 : The prior PR corrected for errors encountered when trying to generate the coverage map on source code inlined from external crates (including macros and generics) by avoiding adding external DefIds to the coverage map. This made it possible to generate a coverage report including external crates but the external crate coverage was incomplete (did not include coverage for the DefIds that were eliminated. The root issue was that the coverage map was converting Span locations to source file and locations using the SourceMap for the current crate and this would not work for spans from external crates (compliled with a different SourceMap). The solution was to convert the Spans to filename and location during MIR generation instead so precompiled external crates would already have the correct source code locations embedded in their MIR when imported into another crate. @wesleywiser FYI r? @tmandry,THUMBS_UP,2020-08-11T15:35:33Z,Speedy37,vincent@speedy37.fr https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-08-04T19:32:15Z,mati865,NA https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-09-15T16:10:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-06T14:13:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-08T14:23:03Z,TethysSvensson,NA https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-08T16:02:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-08T22:05:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-09T09:25:21Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/75048,MERGED,2020-08-02T12:54:54Z,2020-08-08T01:48:58Z,Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away,eggyal,f3a9de9b08659e20ce7c282ed77bc43ddd149107,6,Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame r=Mark-Simulacrum Prevent `__rust_begin_short_backtrace` frames from being tail-call optimised away I've stumbled across some situations where there (unexpectedly) was no `__rust_begin_short_backtrace` frame on the stack during unwinding. On closer examination it appeared that the calls to that function had been tail-call optimised away. This PR follows [@bjorn3's suggestion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Disabling.20tail.20call.20optimisation.3F/near/205699133) by adding calls to `black_box` that hint to rustc not to perform TCO. Fixes #47429,HEART,2020-10-17T06:59:53Z,ali5h,NA https://github.com/rust-lang/rust/pull/75064,MERGED,2020-08-02T17:46:31Z,2020-08-02T23:55:11Z,compiletest: Support ignoring tests requiring missing LLVM components,petrochenkov,0bf2dcf059e4c344d9a9c54cffe4d51543deb2ee,15,"Rollup merge of #75064 - petrochenkov:llvmtarg r=Mark-Simulacrum compiletest: Support ignoring tests requiring missing LLVM components This PR implements a more principled solution to the problem described in https://github.com/rust-lang/rust/pull/66084. Builds of LLVM backends take a lot of time and disk space. So it usually makes sense to build rustc with ```toml [llvm] targets = ""X86"" experimental-targets = """" ``` unless you are working on some target-specific tasks. A few tests however require non-x86 backends to be built. A new test directive `// needs-llvm-components: component1 component2 component3` makes such tests to be automatically ignored if one of the listed components is missing in the provided LLVM (this is determined through `llvm-config --components`). As a result the test suite now fully passes with LLVM built only with the x86 backend. The component list in this case is ``` aggressiveinstcombine all all-targets analysis asmparser asmprinter binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mirparser native nativecodegen objcarcopts object objectyaml option orcerror orcjit passes profiledata remarks runtimedyld scalaropts selectiondag support symbolize tablegen target textapi transformutils vectorize windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray ``` (With the default target list it's much larger.) ``` aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcerror orcjit passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray ``` https://github.com/rust-lang/rust/pull/66084 is also reverted now. r? @Mark-Simulacrum",HEART,2020-08-02T18:34:47Z,mati865,NA https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_DOWN,2020-08-02T18:19:07Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_UP,2020-08-03T03:07:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_UP,2020-08-03T03:11:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_DOWN,2020-08-05T06:50:41Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_DOWN,2020-08-05T07:08:51Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_DOWN,2020-08-12T05:20:38Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/75065,CLOSED,2020-08-02T17:59:05Z,2021-01-28T08:45:07Z,"Format Duration microseconds with ""us"" suffix without Unicode",joshtriplett,NA,NA,NA,THUMBS_DOWN,2020-11-12T23:22:44Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/75066,MERGED,2020-08-02T18:05:06Z,2020-08-12T16:31:18Z,Document unsafety in library/core/src/slice/mod.rs,poliorcetics,ded20c98be8585b2a9fe4eeadd1be5524f6ffb17,1,Auto merge of #75066 - poliorcetics:document-unsafety-in-core-slice r=LukasKalbertodt Document unsafety in library/core/src/slice/mod.rs Restart where #73555 left off helping with #66219.,HEART,2020-08-07T08:21:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/75077,MERGED,2020-08-02T23:11:28Z,2020-09-04T19:06:39Z,Refractor ty.kind -> ty.kind() and ty.flags -> ty.flags(),LeSeulArtichaut,d2454643e137bde519786ee9e650c455d7ad6f34,250,"Auto merge of #75077 - LeSeulArtichaut:tys-kind r=nikomatsakis Refractor ty.kind -> ty.kind() and ty.flags -> ty.flags() First step for the [""shared library to represent Rust types""](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2020-03-12-shared-library-for-types/) work (rust-lang/wg-traits#16). This PR makes the `TyS::kind` field private and adds a `kind()` method to access it. As noted [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/Looking.20to.20contribute/near/205185412) this refractoring might require a MCP. I am perfectly fine with having to wait until MCP is accepted and resolving the conflicts that pop up afterwards. r? @nikomatsakis",THUMBS_UP,2020-08-03T16:38:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75077,MERGED,2020-08-02T23:11:28Z,2020-09-04T19:06:39Z,Refractor ty.kind -> ty.kind() and ty.flags -> ty.flags(),LeSeulArtichaut,d2454643e137bde519786ee9e650c455d7ad6f34,250,"Auto merge of #75077 - LeSeulArtichaut:tys-kind r=nikomatsakis Refractor ty.kind -> ty.kind() and ty.flags -> ty.flags() First step for the [""shared library to represent Rust types""](https://rust-lang.github.io/compiler-team/minutes/design-meeting/2020-03-12-shared-library-for-types/) work (rust-lang/wg-traits#16). This PR makes the `TyS::kind` field private and adds a `kind()` method to access it. As noted [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/Looking.20to.20contribute/near/205185412) this refractoring might require a MCP. I am perfectly fine with having to wait until MCP is accepted and resolving the conflicts that pop up afterwards. r? @nikomatsakis",HEART,2020-08-29T15:09:28Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75086,MERGED,2020-08-03T05:45:10Z,2020-08-06T16:18:39Z,Use u32::from_ne_bytes to fix a FIXME and add comment about that,tesuji,c15bae53b5c40db2682211836f892a5a44065e10,1,Auto merge of #75086 - lzutao:u32const r=oli-obk Use u32::from_ne_bytes to fix a FIXME and add comment about that `u32::from_ne_bytes` has been const stable since 1.44.,HEART,2020-08-05T03:47:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/75114,CLOSED,2020-08-03T17:49:24Z,2020-11-30T22:52:04Z,JSON backend experimental impl,P1n3appl3,NA,NA,NA,HOORAY,2020-11-29T23:17:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75120,MERGED,2020-08-03T21:58:02Z,2020-08-18T01:12:16Z,rust_ast::ast => rustc_ast,JulianKnodt,668ef72f4429059240ee361a2f0f748558a5326f,217,Auto merge of #75120 - JulianKnodt:rm_reps r=oli-obk rust_ast::ast => rustc_ast Rework of #71199 which is a rework #70621 Still working on this but just made the PR to track progress r? @Dylan-DPC,THUMBS_UP,2020-08-18T00:11:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75127,MERGED,2020-08-04T01:13:58Z,2020-08-10T21:47:59Z,Fix async-std by special-casing rustdoc in typeck,jyn514,d495ef527c6ab41c837ff13ed74f648bacee921f,23,Auto merge of #75127 - jyn514:impl-trait r=pnkfelix Fix async-std by special-casing rustdoc in typeck https://github.com/rust-lang/rust/issues/75100,THUMBS_UP,2021-02-13T09:31:27Z,bb010g,NA https://github.com/rust-lang/rust/pull/75132,MERGED,2020-08-04T06:21:37Z,2020-08-25T07:37:38Z,Stabilize Range[Inclusive]::is_empty,scottmcm,c30341ddec0b99bb3bd8bb5fd8c8451778c78330,9,Auto merge of #75132 - scottmcm:stabilize-range-is-empty r=dtolnay Stabilize Range[Inclusive]::is_empty I would like to propose these two simple methods for stabilization: - Knowing that a range is exhausted isn't otherwise trivial - Clippy would like to suggest them but had to do extra work to disable that path because they're unstable - These work on `PartialOrd` consistently with the stable `contains` method and are thus more general than iterator-based approaches that need `Step` - They've been unchanged for some time and have picked up uses in the compiler - Stabilizing them doesn't block any future iterator-based `is_empty` plans as these inherent ones are preferred in name resolution https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty Closes #48111,HEART,2020-08-05T06:46:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75132,MERGED,2020-08-04T06:21:37Z,2020-08-25T07:37:38Z,Stabilize Range[Inclusive]::is_empty,scottmcm,c30341ddec0b99bb3bd8bb5fd8c8451778c78330,9,Auto merge of #75132 - scottmcm:stabilize-range-is-empty r=dtolnay Stabilize Range[Inclusive]::is_empty I would like to propose these two simple methods for stabilization: - Knowing that a range is exhausted isn't otherwise trivial - Clippy would like to suggest them but had to do extra work to disable that path because they're unstable - These work on `PartialOrd` consistently with the stable `contains` method and are thus more general than iterator-based approaches that need `Step` - They've been unchanged for some time and have picked up uses in the compiler - Stabilizing them doesn't block any future iterator-based `is_empty` plans as these inherent ones are preferred in name resolution https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty Closes #48111,HEART,2020-08-09T17:29:34Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/75132,MERGED,2020-08-04T06:21:37Z,2020-08-25T07:37:38Z,Stabilize Range[Inclusive]::is_empty,scottmcm,c30341ddec0b99bb3bd8bb5fd8c8451778c78330,9,Auto merge of #75132 - scottmcm:stabilize-range-is-empty r=dtolnay Stabilize Range[Inclusive]::is_empty I would like to propose these two simple methods for stabilization: - Knowing that a range is exhausted isn't otherwise trivial - Clippy would like to suggest them but had to do extra work to disable that path because they're unstable - These work on `PartialOrd` consistently with the stable `contains` method and are thus more general than iterator-based approaches that need `Step` - They've been unchanged for some time and have picked up uses in the compiler - Stabilizing them doesn't block any future iterator-based `is_empty` plans as these inherent ones are preferred in name resolution https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty Closes #48111,HEART,2020-08-28T01:32:44Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/75138,MERGED,2020-08-04T09:35:06Z,2020-09-08T03:23:40Z,Add derive macro for specifying diagnostics using attributes.,jumbatm,71569e420107ab034910a4687f382385975fa0b3,19,"Auto merge of #75138 - jumbatm:session-diagnostic-derive r=oli-obk Add derive macro for specifying diagnostics using attributes. Introduces `#[derive(SessionDiagnostic)]` a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently the following attributes have been implemented: - `#[code = ""...""]` -- this sets the Diagnostic's error code and must be provided on the struct iself (ie not on a field). Equivalent to calling `code`. - `#[message = ""...""]` -- this sets the Diagnostic's primary error message. - `#[label = ""...""]` -- this must be applied to fields of type `Span` and is equivalent to `span_label` - `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span Applicability)` and is equivalent to calling `span_suggestion`. Valid arguments are: - `message = ""...""` -- this sets the suggestion message. - (Optional) `code = ""...""` -- this suggests code for the suggestion. Defaults to empty. `suggestion`also comes with other variants: `#[suggestion_short(..)]` `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys. Within the strings passed to each attribute fields can be referenced without needing to be passed explicitly into the format string -- eg `#[error = ""{ident} already declared""] ` will set the error message to `format!(""{} already declared"" &self.ident)`. Any fields on the struct can be referenced in this way. Additionally for any of these attributes Option fields can be used to only optionally apply the decoration -- for example: ```rust #[derive(SessionDiagnostic)] #[code = ""E0123""] struct SomeKindOfError { ... #[suggestion(message = ""informative error message"")] opt_sugg: Option<(Span Applicability)> ... } ``` will not emit a suggestion if `opt_sugg` is `None`. We plan on iterating on this macro further; this PR is a start. Closes #61132. r? `@oli-obk`",THUMBS_UP,2020-08-04T10:16:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/75138,MERGED,2020-08-04T09:35:06Z,2020-09-08T03:23:40Z,Add derive macro for specifying diagnostics using attributes.,jumbatm,71569e420107ab034910a4687f382385975fa0b3,19,"Auto merge of #75138 - jumbatm:session-diagnostic-derive r=oli-obk Add derive macro for specifying diagnostics using attributes. Introduces `#[derive(SessionDiagnostic)]` a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently the following attributes have been implemented: - `#[code = ""...""]` -- this sets the Diagnostic's error code and must be provided on the struct iself (ie not on a field). Equivalent to calling `code`. - `#[message = ""...""]` -- this sets the Diagnostic's primary error message. - `#[label = ""...""]` -- this must be applied to fields of type `Span` and is equivalent to `span_label` - `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span Applicability)` and is equivalent to calling `span_suggestion`. Valid arguments are: - `message = ""...""` -- this sets the suggestion message. - (Optional) `code = ""...""` -- this suggests code for the suggestion. Defaults to empty. `suggestion`also comes with other variants: `#[suggestion_short(..)]` `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys. Within the strings passed to each attribute fields can be referenced without needing to be passed explicitly into the format string -- eg `#[error = ""{ident} already declared""] ` will set the error message to `format!(""{} already declared"" &self.ident)`. Any fields on the struct can be referenced in this way. Additionally for any of these attributes Option fields can be used to only optionally apply the decoration -- for example: ```rust #[derive(SessionDiagnostic)] #[code = ""E0123""] struct SomeKindOfError { ... #[suggestion(message = ""informative error message"")] opt_sugg: Option<(Span Applicability)> ... } ``` will not emit a suggestion if `opt_sugg` is `None`. We plan on iterating on this macro further; this PR is a start. Closes #61132. r? `@oli-obk`",THUMBS_UP,2020-08-04T10:27:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75138,MERGED,2020-08-04T09:35:06Z,2020-09-08T03:23:40Z,Add derive macro for specifying diagnostics using attributes.,jumbatm,71569e420107ab034910a4687f382385975fa0b3,19,"Auto merge of #75138 - jumbatm:session-diagnostic-derive r=oli-obk Add derive macro for specifying diagnostics using attributes. Introduces `#[derive(SessionDiagnostic)]` a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently the following attributes have been implemented: - `#[code = ""...""]` -- this sets the Diagnostic's error code and must be provided on the struct iself (ie not on a field). Equivalent to calling `code`. - `#[message = ""...""]` -- this sets the Diagnostic's primary error message. - `#[label = ""...""]` -- this must be applied to fields of type `Span` and is equivalent to `span_label` - `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span Applicability)` and is equivalent to calling `span_suggestion`. Valid arguments are: - `message = ""...""` -- this sets the suggestion message. - (Optional) `code = ""...""` -- this suggests code for the suggestion. Defaults to empty. `suggestion`also comes with other variants: `#[suggestion_short(..)]` `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys. Within the strings passed to each attribute fields can be referenced without needing to be passed explicitly into the format string -- eg `#[error = ""{ident} already declared""] ` will set the error message to `format!(""{} already declared"" &self.ident)`. Any fields on the struct can be referenced in this way. Additionally for any of these attributes Option fields can be used to only optionally apply the decoration -- for example: ```rust #[derive(SessionDiagnostic)] #[code = ""E0123""] struct SomeKindOfError { ... #[suggestion(message = ""informative error message"")] opt_sugg: Option<(Span Applicability)> ... } ``` will not emit a suggestion if `opt_sugg` is `None`. We plan on iterating on this macro further; this PR is a start. Closes #61132. r? `@oli-obk`",THUMBS_UP,2020-08-04T15:47:25Z,estebank,NA https://github.com/rust-lang/rust/pull/75138,MERGED,2020-08-04T09:35:06Z,2020-09-08T03:23:40Z,Add derive macro for specifying diagnostics using attributes.,jumbatm,71569e420107ab034910a4687f382385975fa0b3,19,"Auto merge of #75138 - jumbatm:session-diagnostic-derive r=oli-obk Add derive macro for specifying diagnostics using attributes. Introduces `#[derive(SessionDiagnostic)]` a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently the following attributes have been implemented: - `#[code = ""...""]` -- this sets the Diagnostic's error code and must be provided on the struct iself (ie not on a field). Equivalent to calling `code`. - `#[message = ""...""]` -- this sets the Diagnostic's primary error message. - `#[label = ""...""]` -- this must be applied to fields of type `Span` and is equivalent to `span_label` - `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span Applicability)` and is equivalent to calling `span_suggestion`. Valid arguments are: - `message = ""...""` -- this sets the suggestion message. - (Optional) `code = ""...""` -- this suggests code for the suggestion. Defaults to empty. `suggestion`also comes with other variants: `#[suggestion_short(..)]` `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys. Within the strings passed to each attribute fields can be referenced without needing to be passed explicitly into the format string -- eg `#[error = ""{ident} already declared""] ` will set the error message to `format!(""{} already declared"" &self.ident)`. Any fields on the struct can be referenced in this way. Additionally for any of these attributes Option fields can be used to only optionally apply the decoration -- for example: ```rust #[derive(SessionDiagnostic)] #[code = ""E0123""] struct SomeKindOfError { ... #[suggestion(message = ""informative error message"")] opt_sugg: Option<(Span Applicability)> ... } ``` will not emit a suggestion if `opt_sugg` is `None`. We plan on iterating on this macro further; this PR is a start. Closes #61132. r? `@oli-obk`",THUMBS_UP,2020-08-04T19:15:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75145,MERGED,2020-08-04T14:16:10Z,2020-08-17T23:16:39Z,Reference lang items during AST lowering,davidtwco,792c645ca7d11a8d254df307d019c5bf01445c37,61,Auto merge of #75145 - davidtwco:issue-60607-preallocate-defid-for-lang-items r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct they compile but attempting to run tests through `./x.py` produced failures which appeared spurious so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef` as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper,THUMBS_UP,2020-08-04T14:24:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75145,MERGED,2020-08-04T14:16:10Z,2020-08-17T23:16:39Z,Reference lang items during AST lowering,davidtwco,792c645ca7d11a8d254df307d019c5bf01445c37,61,Auto merge of #75145 - davidtwco:issue-60607-preallocate-defid-for-lang-items r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct they compile but attempting to run tests through `./x.py` produced failures which appeared spurious so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef` as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper,THUMBS_UP,2020-08-04T14:24:35Z,oli-obk,NA https://github.com/rust-lang/rust/pull/75145,MERGED,2020-08-04T14:16:10Z,2020-08-17T23:16:39Z,Reference lang items during AST lowering,davidtwco,792c645ca7d11a8d254df307d019c5bf01445c37,61,Auto merge of #75145 - davidtwco:issue-60607-preallocate-defid-for-lang-items r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct they compile but attempting to run tests through `./x.py` produced failures which appeared spurious so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef` as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper,THUMBS_UP,2020-08-04T14:32:53Z,tesuji,NA https://github.com/rust-lang/rust/pull/75145,MERGED,2020-08-04T14:16:10Z,2020-08-17T23:16:39Z,Reference lang items during AST lowering,davidtwco,792c645ca7d11a8d254df307d019c5bf01445c37,61,Auto merge of #75145 - davidtwco:issue-60607-preallocate-defid-for-lang-items r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct they compile but attempting to run tests through `./x.py` produced failures which appeared spurious so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef` as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper,HEART,2020-08-04T17:01:52Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/75145,MERGED,2020-08-04T14:16:10Z,2020-08-17T23:16:39Z,Reference lang items during AST lowering,davidtwco,792c645ca7d11a8d254df307d019c5bf01445c37,61,Auto merge of #75145 - davidtwco:issue-60607-preallocate-defid-for-lang-items r=petrochenkov Reference lang items during AST lowering Fixes #60607 and fixes #61019. This PR introduces `QPath::LangItem` to the HIR and uses it in AST lowering instead of constructing a `hir::Path` from a slice of symbols: - Credit for much of this work goes to @matthewjasper I basically just [rebased their earlier work](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#diff-c0f791ead38d2d02916faaad0f56f41d). - ~~Changes to Clippy might not be correct they compile but attempting to run tests through `./x.py` produced failures which appeared spurious so I didn't run any clippy tests.~~ - Changes to save analysis might not be correct - tests pass but I don't have a lot of confidence in those changes being correct. - I've used `GenericBounds::LangItemTrait` rather than changing `PolyTraitRef` as suggested by @matthewjasper [in this comment](https://github.com/matthewjasper/rust/commit/a227c706b7809ff07021baf3856b7540d5b57f8a#r40107992) but I'd prefer that be left for a follow-up. - I've split things into smaller commits fairly arbitrarily to make the diff easier to review each commit should compile but might not pass tests until the final commit. r? @oli-obk cc @matthewjasper,THUMBS_UP,2020-08-04T18:37:07Z,lqd,NA https://github.com/rust-lang/rust/pull/75148,MERGED,2020-08-04T14:57:44Z,2020-09-15T19:05:53Z,Implementation of peer credentials for Unix sockets,joechrisellis,a874956d940ecb3ed524b6176a171219ac4787ea,4,Auto merge of #75148 - joechrisellis:master r=Amanieu Implementation of peer credentials for Unix sockets The code in `ucred.rs` is based on the work done in [PR 13](https://github.com/tokio-rs/tokio-uds/pull/13) in the tokio-uds repository on GitHub. This commit is effectively a port to the stdlib so credit to Martin Habovštiak (`@Kixunil)` and contributors for the meat of this work. 🥇 Happy to make changes as needed. 🙂,HEART,2020-08-04T17:31:06Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/75148,MERGED,2020-08-04T14:57:44Z,2020-09-15T19:05:53Z,Implementation of peer credentials for Unix sockets,joechrisellis,a874956d940ecb3ed524b6176a171219ac4787ea,4,Auto merge of #75148 - joechrisellis:master r=Amanieu Implementation of peer credentials for Unix sockets The code in `ucred.rs` is based on the work done in [PR 13](https://github.com/tokio-rs/tokio-uds/pull/13) in the tokio-uds repository on GitHub. This commit is effectively a port to the stdlib so credit to Martin Habovštiak (`@Kixunil)` and contributors for the meat of this work. 🥇 Happy to make changes as needed. 🙂,HOORAY,2020-08-05T10:13:51Z,hug-dev,hugues.de-valon@einride.tech https://github.com/rust-lang/rust/pull/75148,MERGED,2020-08-04T14:57:44Z,2020-09-15T19:05:53Z,Implementation of peer credentials for Unix sockets,joechrisellis,a874956d940ecb3ed524b6176a171219ac4787ea,4,Auto merge of #75148 - joechrisellis:master r=Amanieu Implementation of peer credentials for Unix sockets The code in `ucred.rs` is based on the work done in [PR 13](https://github.com/tokio-rs/tokio-uds/pull/13) in the tokio-uds repository on GitHub. This commit is effectively a port to the stdlib so credit to Martin Habovštiak (`@Kixunil)` and contributors for the meat of this work. 🥇 Happy to make changes as needed. 🙂,HOORAY,2020-08-05T11:23:39Z,ionut-arm,ionut.mihalcea@arm.com https://github.com/rust-lang/rust/pull/75155,MERGED,2020-08-04T17:28:29Z,2020-08-05T09:09:22Z,polymorphization: various improvements,davidtwco,7f8ff84b510e3ff04865cfdd5ef95e677227e0c8,7,Auto merge of #75155 - davidtwco:polymorphization-incr-comp-optimisations r=lcnr polymorphization: various improvements This PR includes a handful of polymorphisation-related changes: - @Mark-Simulacrum's suggestions [from this comment](https://github.com/rust-lang/rust/pull/74633#issuecomment-668684433): - Use a `FiniteBitSet` over a `FiniteBitSet` as most functions won't have 64 generic parameters. - Don't encode polymorphisation results in metadata when every parameter is used (in this case just invoking polymorphisation will probably be quicker). - @lcnr's suggestion [from this comment](https://github.com/rust-lang/rust/pull/74717#discussion_r463690015). - Add an debug assertion in `ensure_monomorphic_enough` to make sure that polymorphisation did what we expect. r? @lcnr,HEART,2020-08-04T19:12:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75157,MERGED,2020-08-04T17:43:35Z,2020-08-14T16:27:25Z,Constified str::from_utf8_unchecked,rodrimati1992,55b9adfafa11b2ced5c0477c949fd875b19b3877,1,Auto merge of #75157 - rodrimati1992:patch-1 r=oli-obk Constified str::from_utf8_unchecked This would be useful for const code to use an array to construct a string using guaranteed utf8 inputs and then create a `&str` from it.,HEART,2020-08-05T06:44:40Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75157,MERGED,2020-08-04T17:43:35Z,2020-08-14T16:27:25Z,Constified str::from_utf8_unchecked,rodrimati1992,55b9adfafa11b2ced5c0477c949fd875b19b3877,1,Auto merge of #75157 - rodrimati1992:patch-1 r=oli-obk Constified str::from_utf8_unchecked This would be useful for const code to use an array to construct a string using guaranteed utf8 inputs and then create a `&str` from it.,THUMBS_UP,2020-08-07T04:22:18Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/75171,MERGED,2020-08-05T01:20:28Z,2020-08-22T20:41:23Z,New zeroed slice,amosonn,663d2f5cd3163f17eddb74ee1e028d542255f21a,3,Auto merge of #75171 - amosonn:new_zeroed_slice r=Amanieu New zeroed slice Add to #63291 the methods ```rust impl Box<[T]> { pub fn new_zeroed_slice(len: usize) -> Box<[MaybeUninit]> {…} } impl Rc<[T]> { pub fn new_zeroed_slice(len: usize) -> Rc<[MaybeUninit]> {…} } impl Arc<[T]> { pub fn new_zeroed_slice(len: usize) -> Arc<[MaybeUninit]> {…} } ``` as suggested in https://github.com/rust-lang/rust/issues/63291#issuecomment-605511675 . Also optimize `{Rc Arc}::new_zeroed` to use `alloc_zeroed` otherwise they are no more efficient than using `new_uninit` and zeroing the memory manually (which was the original implementation).,THUMBS_UP,2020-08-13T19:43:38Z,Cataractar,NA https://github.com/rust-lang/rust/pull/75171,MERGED,2020-08-05T01:20:28Z,2020-08-22T20:41:23Z,New zeroed slice,amosonn,663d2f5cd3163f17eddb74ee1e028d542255f21a,3,Auto merge of #75171 - amosonn:new_zeroed_slice r=Amanieu New zeroed slice Add to #63291 the methods ```rust impl Box<[T]> { pub fn new_zeroed_slice(len: usize) -> Box<[MaybeUninit]> {…} } impl Rc<[T]> { pub fn new_zeroed_slice(len: usize) -> Rc<[MaybeUninit]> {…} } impl Arc<[T]> { pub fn new_zeroed_slice(len: usize) -> Arc<[MaybeUninit]> {…} } ``` as suggested in https://github.com/rust-lang/rust/issues/63291#issuecomment-605511675 . Also optimize `{Rc Arc}::new_zeroed` to use `alloc_zeroed` otherwise they are no more efficient than using `new_uninit` and zeroing the memory manually (which was the original implementation).,THUMBS_UP,2020-08-27T04:42:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75172,CLOSED,2020-08-05T01:55:06Z,2020-10-23T04:03:19Z,Capture output from threads spawned in tests,tmandry,NA,NA,NA,HOORAY,2020-08-16T19:52:52Z,mystor,nika@thelayzells.com https://github.com/rust-lang/rust/pull/75172,CLOSED,2020-08-05T01:55:06Z,2020-10-23T04:03:19Z,Capture output from threads spawned in tests,tmandry,NA,NA,NA,HOORAY,2020-08-19T04:54:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75172,CLOSED,2020-08-05T01:55:06Z,2020-10-23T04:03:19Z,Capture output from threads spawned in tests,tmandry,NA,NA,NA,HOORAY,2020-09-24T16:15:05Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/75173,MERGED,2020-08-05T02:37:38Z,2020-09-05T04:16:42Z,Upgrade Chalk to 0.21,jackh726,c3364780d2cfddfe329f62a3ec138fd4f9a60e27,11,Auto merge of #75173 - jackh726:chalk-0.21 r=nikomatsakis Upgrade Chalk to 0.21 Two commits here. First commit actually does the upgrade. Second commit has some changes to make more tests in compare-mode=chalk pass. The `PlaceholdersCollector` and `RegionsSubstitutor` bits are bit a hacky but only insomuch as `ParamsSubstitutor` is. These won't be needed eventually. r? @nikomatsakis,HEART,2020-08-05T02:38:50Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75173,MERGED,2020-08-05T02:37:38Z,2020-09-05T04:16:42Z,Upgrade Chalk to 0.21,jackh726,c3364780d2cfddfe329f62a3ec138fd4f9a60e27,11,Auto merge of #75173 - jackh726:chalk-0.21 r=nikomatsakis Upgrade Chalk to 0.21 Two commits here. First commit actually does the upgrade. Second commit has some changes to make more tests in compare-mode=chalk pass. The `PlaceholdersCollector` and `RegionsSubstitutor` bits are bit a hacky but only insomuch as `ParamsSubstitutor` is. These won't be needed eventually. r? @nikomatsakis,HEART,2020-08-05T16:30:08Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/75173,MERGED,2020-08-05T02:37:38Z,2020-09-05T04:16:42Z,Upgrade Chalk to 0.21,jackh726,c3364780d2cfddfe329f62a3ec138fd4f9a60e27,11,Auto merge of #75173 - jackh726:chalk-0.21 r=nikomatsakis Upgrade Chalk to 0.21 Two commits here. First commit actually does the upgrade. Second commit has some changes to make more tests in compare-mode=chalk pass. The `PlaceholdersCollector` and `RegionsSubstitutor` bits are bit a hacky but only insomuch as `ParamsSubstitutor` is. These won't be needed eventually. r? @nikomatsakis,HEART,2020-08-07T06:35:04Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/75175,MERGED,2020-08-05T03:05:29Z,2020-08-07T03:04:55Z,Make doctests of Ipv4Addr::from(u32) easier to read,tesuji,c9c7048038d3776815f0952dcb15a7290297f8f5,1,Rollup merge of #75175 - lzutao:doctest-ipv4-fromu32 r=cuviper Make doctests of Ipv4Addr::from(u32) easier to read There are many zeroes in `0x0d0c0b0au32` which makes it hard to read.,HEART,2020-08-05T06:41:18Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75180,MERGED,2020-08-05T06:53:03Z,2021-01-25T01:59:59Z,Implement Error for &(impl Error),KodrAus,5a1f2ecdd7847bae36608651429ef1698890a69f,1,"Rollup merge of #75180 - KodrAus:feat/error-by-ref r=m-ou-se Implement Error for &(impl Error) Opening this up just to see what it breaks. It's unfortunate that `&(impl Error)` doesn't actually implement `Error`. If this direct approach doesn't work out then I'll try something different like an `Error::by_ref` method. **EDIT:** This is a super low-priority experiment so feel free to cancel it for more important crater runs! 🙂 ----- # Stabilization Report ## Why? We've been working for the last few years to try ""fix"" the `Error` trait which is probably one of the most fundamental in the whole standard library. One of its issues is that we commonly expect you to work with abstract errors through `dyn Trait` but references and smart pointers over `dyn Trait` don't actually implement the `Error` trait. If you have a `&dyn Error` or a `Box` you simply can't pass it to a method that wants a `impl Error`. ## What does this do? This stabilizes the following trait impl: ```rust impl<'a T: Error + ?Sized + 'static> Error for &'a T; ``` This means that `&dyn Error` will now satisfy a `impl Error` bound. It doesn't do anything with `Box` directly. We discussed how we could do `Box` in the thread here (and elsewhere in the past) but it seems like we need something like lattice-based specialization or a sprinkling of snowflake compiler magic to make that work. Having said that with this new impl you _can_ now get a `impl Error` from a `Box` by dereferencing it. ## What breaks? A crater run revealed a few crates broke with something like the following: ```rust // where e: &'short &'long dyn Error err.source() ``` previously we'd auto-deref that `&'short &'long dyn Error` to return a `Option<&'long dyn Error>` from `source` but now will call directly on `&'short impl Error` so will return a `Option<&'short dyn Error>`. The fix is to manually deref: ```rust // where e: &'short &'long dyn Error (*err).source() ``` In the recent Libs meeting we considered this acceptable breakage.",EYES,2020-10-14T17:38:27Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/75180,MERGED,2020-08-05T06:53:03Z,2021-01-25T01:59:59Z,Implement Error for &(impl Error),KodrAus,5a1f2ecdd7847bae36608651429ef1698890a69f,1,"Rollup merge of #75180 - KodrAus:feat/error-by-ref r=m-ou-se Implement Error for &(impl Error) Opening this up just to see what it breaks. It's unfortunate that `&(impl Error)` doesn't actually implement `Error`. If this direct approach doesn't work out then I'll try something different like an `Error::by_ref` method. **EDIT:** This is a super low-priority experiment so feel free to cancel it for more important crater runs! 🙂 ----- # Stabilization Report ## Why? We've been working for the last few years to try ""fix"" the `Error` trait which is probably one of the most fundamental in the whole standard library. One of its issues is that we commonly expect you to work with abstract errors through `dyn Trait` but references and smart pointers over `dyn Trait` don't actually implement the `Error` trait. If you have a `&dyn Error` or a `Box` you simply can't pass it to a method that wants a `impl Error`. ## What does this do? This stabilizes the following trait impl: ```rust impl<'a T: Error + ?Sized + 'static> Error for &'a T; ``` This means that `&dyn Error` will now satisfy a `impl Error` bound. It doesn't do anything with `Box` directly. We discussed how we could do `Box` in the thread here (and elsewhere in the past) but it seems like we need something like lattice-based specialization or a sprinkling of snowflake compiler magic to make that work. Having said that with this new impl you _can_ now get a `impl Error` from a `Box` by dereferencing it. ## What breaks? A crater run revealed a few crates broke with something like the following: ```rust // where e: &'short &'long dyn Error err.source() ``` previously we'd auto-deref that `&'short &'long dyn Error` to return a `Option<&'long dyn Error>` from `source` but now will call directly on `&'short impl Error` so will return a `Option<&'short dyn Error>`. The fix is to manually deref: ```rust // where e: &'short &'long dyn Error (*err).source() ``` In the recent Libs meeting we considered this acceptable breakage.",EYES,2020-11-12T12:26:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75183,MERGED,2020-08-05T09:04:30Z,2020-08-07T03:04:51Z,Label rustfmt toolstate issues with A-rustfmt,Aaron1011,5542fba2d329724fe972c8da91909ad1ddfdfd3d,1,Rollup merge of #75183 - Aaron1011:toolstate/a-rustfmt r=nikomatsakis Label rustfmt toolstate issues with A-rustfmt This makes it easier to filter toolstate issues by the tool involved.,THUMBS_UP,2020-08-05T12:16:39Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-05T11:01:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-05T13:46:44Z,mati865,NA https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-05T15:07:01Z,tesuji,NA https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-06T04:34:49Z,cynecx,NA https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-07T03:54:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-07T06:44:05Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-11T15:01:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-14T11:35:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-08-21T11:55:46Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2020-09-09T20:01:45Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/75185,OPEN,2020-08-05T09:55:43Z,NA,[WIP] polymorphisation: re-enable,davidtwco,NA,NA,NA,HOORAY,2021-03-17T05:49:35Z,codingonHP,vishal_24_anand@hotmail.com https://github.com/rust-lang/rust/pull/75188,MERGED,2020-08-05T12:00:40Z,2020-08-07T03:04:49Z,Handle fieldless tuple structs in diagnostic code,Aaron1011,665138c977842c47c022e0a7a8eaf09d74148ada,3,Rollup merge of #75188 - Aaron1011:fix/fieldless-tuple-error r=varkor Handle fieldless tuple structs in diagnostic code Fixes #75062,ROCKET,2020-08-06T04:03:18Z,jhwgh1968,NA https://github.com/rust-lang/rust/pull/75199,MERGED,2020-08-05T20:44:25Z,2020-11-07T19:19:40Z,Re-enable debug and LLVM assertions,Mark-Simulacrum,b2d115f6db5172c961dfeb50de15f35784dbc7c9,6,Auto merge of #75199 - Mark-Simulacrum:debug-asserts r=pietroalbini Re-enable debug and LLVM assertions Historically we've disabled these assertions on a number of platforms with the goal of speeding up CI. Now though having migrated to GitHub actions CI is already pretty fast and these debug assertions do bring us some value. This does leave in some debug assertions that are performance-related: macOS currently hovers at just under 2 hours. There are also some other builders which have debug and LLVM assertions disabled: llvm-8 PR builder: In one view this builder tests our support for older LLVMs. But in reality a lot of our tests already disable themselves on older LLVMs and I think our general stance is that we really only support the in-tree LLVM. Plus we really want CI times on this builder to be really low as it's run on *every* PR -- that's a lot of CI time. test-various: This disables debug asserts still -- as noted in the Dockerfile we test code size and we need debug asserts off for that to work well. Helps with #59637 -- but doesn't close it macOS still has asserts off. r? `@pietroalbini`,HEART,2020-08-05T21:22:29Z,mati865,NA https://github.com/rust-lang/rust/pull/75199,MERGED,2020-08-05T20:44:25Z,2020-11-07T19:19:40Z,Re-enable debug and LLVM assertions,Mark-Simulacrum,b2d115f6db5172c961dfeb50de15f35784dbc7c9,6,Auto merge of #75199 - Mark-Simulacrum:debug-asserts r=pietroalbini Re-enable debug and LLVM assertions Historically we've disabled these assertions on a number of platforms with the goal of speeding up CI. Now though having migrated to GitHub actions CI is already pretty fast and these debug assertions do bring us some value. This does leave in some debug assertions that are performance-related: macOS currently hovers at just under 2 hours. There are also some other builders which have debug and LLVM assertions disabled: llvm-8 PR builder: In one view this builder tests our support for older LLVMs. But in reality a lot of our tests already disable themselves on older LLVMs and I think our general stance is that we really only support the in-tree LLVM. Plus we really want CI times on this builder to be really low as it's run on *every* PR -- that's a lot of CI time. test-various: This disables debug asserts still -- as noted in the Dockerfile we test code size and we need debug asserts off for that to work well. Helps with #59637 -- but doesn't close it macOS still has asserts off. r? `@pietroalbini`,HEART,2020-09-03T22:29:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75207,MERGED,2020-08-06T02:39:06Z,2020-09-04T14:33:22Z,Add `slice::check_range`,dylni,ef55a0a92f3cb6572ef67d99f4aefbdeb7b6b804,7,Auto merge of #75207 - dylni:add-slice-check-range r=KodrAus Add `slice::check_range` This method is useful for [`RangeBounds`] parameters. It's even been [rewritten](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/src/librustc_data_structures/sorted_map.rs#L214) [many](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/library/alloc/src/vec.rs#L1299) [times](https://github.com/rust-lang/rust/blob/22ee68dc586440f96b76b32fbd6087507c6afdb9/library/core/src/slice/mod.rs#L2441) in the standard library sometimes assuming that the bounds won't be [`usize::MAX`]. For example [`Vec::drain`] creates an empty iterator when [`usize::MAX`] is used as an inclusive end bound: ```rust assert!(vec![1].drain(..=usize::max_value()).eq(iter::empty())); ``` If this PR is merged I'll create another to use it for those methods. [`RangeBounds`]: https://doc.rust-lang.org/std/ops/trait.RangeBounds.html [`usize::MAX`]: https://doc.rust-lang.org/std/primitive.usize.html#associatedconstant.MAX [`Vec::drain`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.drain,THUMBS_UP,2020-09-06T13:10:24Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/75209,MERGED,2020-08-06T05:58:21Z,2020-10-16T22:55:31Z,Suggest imports of unresolved macros,Hirrolot,7581bb7c02f9960fba66add3e4c7c62874c60c7f,6,Rollup merge of #75209 - Hirrolot:suggest-macro-imports r=estebank Suggest imports of unresolved macros Closes https://github.com/rust-lang/rust/issues/75191.,HEART,2020-08-07T12:03:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75209,MERGED,2020-08-06T05:58:21Z,2020-10-16T22:55:31Z,Suggest imports of unresolved macros,Hirrolot,7581bb7c02f9960fba66add3e4c7c62874c60c7f,6,Rollup merge of #75209 - Hirrolot:suggest-macro-imports r=estebank Suggest imports of unresolved macros Closes https://github.com/rust-lang/rust/issues/75191.,HEART,2020-08-25T16:31:31Z,estebank,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-06T11:54:22Z,est31,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-06T12:24:29Z,CryZe,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-07T00:21:57Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-07T02:53:24Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-07T03:48:39Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-07T07:19:48Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-07T10:54:55Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-11T07:13:11Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-13T16:11:24Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-13T16:12:21Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-13T16:57:24Z,Limeth,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-13T17:48:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-19T21:59:51Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-19T23:16:43Z,Virgiel,NA https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-20T00:09:06Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-20T04:21:49Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-08-25T06:14:25Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2020-12-22T01:24:06Z,nat-rix,jan.zwerschke@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2021-07-09T03:56:39Z,lemmih,lemmih@gmail.com https://github.com/rust-lang/rust/pull/75212,MERGED,2020-08-06T07:53:27Z,2020-08-13T15:03:59Z,Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)`,JulianKnodt,a0c290f951076d781b0ff08370445517446cee05,9,Auto merge of #75212 - JulianKnodt:array_map r=LukasKalbertodt Add `array` lang item and `[T; N]::map(f: FnMut(T) -> S)` This introduces an `array` lang item so functions can be defined on top of `[T; N]`. This was previously not done because const-generics was not complete enough to allow for this. Now it is in a state that is usable enough to start adding functions. The function added is a monadic (I think?) map from `[T; N] -> [S; N]`. Until transmute can function on arrays it also allocates an extra temporary array but this can be removed at some point. r? @lcnr,THUMBS_UP,2022-02-23T12:46:25Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/75228,MERGED,2020-08-06T19:41:03Z,2020-08-06T23:25:39Z,Keep stdout open in limit_vector_count test,tmiasko,71f8d0c8f1060bbe74100f29cc6f2da63d697c28,1,Auto merge of #75228 - tmiasko:keep-stdout-open r=ecstatic-morse Keep stdout open in limit_vector_count test,HEART,2020-08-06T20:38:18Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75228,MERGED,2020-08-06T19:41:03Z,2020-08-06T23:25:39Z,Keep stdout open in limit_vector_count test,tmiasko,71f8d0c8f1060bbe74100f29cc6f2da63d697c28,1,Auto merge of #75228 - tmiasko:keep-stdout-open r=ecstatic-morse Keep stdout open in limit_vector_count test,HEART,2020-08-06T20:40:01Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/75228,MERGED,2020-08-06T19:41:03Z,2020-08-06T23:25:39Z,Keep stdout open in limit_vector_count test,tmiasko,71f8d0c8f1060bbe74100f29cc6f2da63d697c28,1,Auto merge of #75228 - tmiasko:keep-stdout-open r=ecstatic-morse Keep stdout open in limit_vector_count test,THUMBS_UP,2020-08-06T21:07:21Z,adamreichold,NA https://github.com/rust-lang/rust/pull/75228,MERGED,2020-08-06T19:41:03Z,2020-08-06T23:25:39Z,Keep stdout open in limit_vector_count test,tmiasko,71f8d0c8f1060bbe74100f29cc6f2da63d697c28,1,Auto merge of #75228 - tmiasko:keep-stdout-open r=ecstatic-morse Keep stdout open in limit_vector_count test,HEART,2020-08-07T01:28:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/75249,MERGED,2020-08-07T09:25:04Z,2020-08-11T03:29:40Z,Only add a border for the rust logo,GuillaumeGomez,2ad7c1687fcc09d5e72ddb22c926e86a078ec2e6,4,Rollup merge of #75249 - GuillaumeGomez:rust-logo-border r=Manishearth Only add a border for the rust logo ![Screenshot from 2020-08-07 11-22-51](https://user-images.githubusercontent.com/3050060/89631113-9dadc700-d8a0-11ea-8063-ad40207decaa.png) ![Screenshot from 2020-08-07 11-19-47](https://user-images.githubusercontent.com/3050060/89631114-9e465d80-d8a0-11ea-96ba-1d6926c8e7a9.png) ![Screenshot from 2020-08-07 11-19-41](https://user-images.githubusercontent.com/3050060/89631117-9edef400-d8a0-11ea-9c66-0df3d8c1ac2d.png) I didn't add a border for the light theme though as I felt it as unnecessary. r? @Manishearth,THUMBS_UP,2020-08-07T12:50:06Z,Cldfire,NA https://github.com/rust-lang/rust/pull/75249,MERGED,2020-08-07T09:25:04Z,2020-08-11T03:29:40Z,Only add a border for the rust logo,GuillaumeGomez,2ad7c1687fcc09d5e72ddb22c926e86a078ec2e6,4,Rollup merge of #75249 - GuillaumeGomez:rust-logo-border r=Manishearth Only add a border for the rust logo ![Screenshot from 2020-08-07 11-22-51](https://user-images.githubusercontent.com/3050060/89631113-9dadc700-d8a0-11ea-8063-ad40207decaa.png) ![Screenshot from 2020-08-07 11-19-47](https://user-images.githubusercontent.com/3050060/89631114-9e465d80-d8a0-11ea-96ba-1d6926c8e7a9.png) ![Screenshot from 2020-08-07 11-19-41](https://user-images.githubusercontent.com/3050060/89631117-9edef400-d8a0-11ea-9c66-0df3d8c1ac2d.png) I didn't add a border for the light theme though as I felt it as unnecessary. r? @Manishearth,THUMBS_UP,2020-08-11T04:20:30Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/75255,MERGED,2020-08-07T12:36:08Z,2020-08-07T19:51:02Z,instance: polymorphize upvar closures/generators,davidtwco,09f4c9f5082f78b0adcee83d3ab4337e000cd28e,9,Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures r=lcnr instance: polymorphize upvar closures/generators This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized. With the new symbol mangling a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However when that polymorphised closure captures another closure as an upvar then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue we just didn't have a way to notice). See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008). r? @eddyb cc @lcnr,HEART,2020-08-07T13:29:40Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75255,MERGED,2020-08-07T12:36:08Z,2020-08-07T19:51:02Z,instance: polymorphize upvar closures/generators,davidtwco,09f4c9f5082f78b0adcee83d3ab4337e000cd28e,9,Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures r=lcnr instance: polymorphize upvar closures/generators This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized. With the new symbol mangling a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However when that polymorphised closure captures another closure as an upvar then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue we just didn't have a way to notice). See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008). r? @eddyb cc @lcnr,HEART,2020-08-07T13:59:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/75255,MERGED,2020-08-07T12:36:08Z,2020-08-07T19:51:02Z,instance: polymorphize upvar closures/generators,davidtwco,09f4c9f5082f78b0adcee83d3ab4337e000cd28e,9,Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures r=lcnr instance: polymorphize upvar closures/generators This PR modifies how instances are polymorphized so that closures and generators have any closures or generators captured within their upvars also polymorphized. With the new symbol mangling a fully polymorphised closure will produce the same symbol regardless of what it was instantiated with. However when that polymorphised closure captures another closure as an upvar then the type of that other closure in the upvar substitution wouldn't have been polymorphised. The other closure will still refer to the initial substitutions. Therefore the polymorphised closure will end up hashing differently but producing the same symbol - triggering `assert_symbols_are_distinct` in MIR partitioning. The old mangling scheme had a hash at the end that meant this didn't happen (this would still have been an issue we just didn't have a way to notice). See [this Zulip discussion for further elaboration](https://rust-lang.zulipchat.com/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation/near/206152008). r? @eddyb cc @lcnr,HEART,2021-02-17T09:45:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75260,MERGED,2020-08-07T15:26:12Z,2020-08-08T18:15:58Z,polymorphize: unevaluated constants,davidtwco,3f091baba4fa656adb4c1a57b64aa831002d801d,8,Auto merge of #75260 - davidtwco:polymorphization-promoted-substs r=lcnr polymorphize: unevaluated constants This PR makes polymorphization visit the promoted MIR of unevaluated constants with available promoted MIR instead of visiting the substitutions of that constant - which will mark all of the generic parameters as used; in addition polymorphization will now visit non-promoted unevaluated constants rather than visit their substs. r? @lcnr,ROCKET,2020-08-07T16:43:01Z,lqd,NA https://github.com/rust-lang/rust/pull/75260,MERGED,2020-08-07T15:26:12Z,2020-08-08T18:15:58Z,polymorphize: unevaluated constants,davidtwco,3f091baba4fa656adb4c1a57b64aa831002d801d,8,Auto merge of #75260 - davidtwco:polymorphization-promoted-substs r=lcnr polymorphize: unevaluated constants This PR makes polymorphization visit the promoted MIR of unevaluated constants with available promoted MIR instead of visiting the substitutions of that constant - which will mark all of the generic parameters as used; in addition polymorphization will now visit non-promoted unevaluated constants rather than visit their substs. r? @lcnr,ROCKET,2020-08-09T01:54:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/75265,MERGED,2020-08-07T18:34:09Z,2020-10-16T02:29:49Z,Add `str::{Split RSplit SplitN RSplitN SplitTerminator RSplitTerminator SplitInclusive}::as_str` methods,WaffleLapkin,977df43c4a7fae07a5623ad851190181a274b54d,2,"Rollup merge of #75265 - WaffleLapkin:str_split_as_str r=dtolnay Add `str::{Split RSplit SplitN RSplitN SplitTerminator RSplitTerminator SplitInclusive}::as_str` methods tl;dr this allows viewing unyelded part of str-split-iterators like so: ```rust let mut split = ""Mary had a little lamb"".split(' '); assert_eq!(split.as_str() ""Mary had a little lamb""); split.next(); assert_eq!(split.as_str() ""had a little lamb""); split.by_ref().for_each(drop); assert_eq!(split.as_str() """"); ``` -------------- This PR adds semi-identical `as_str` methods to most str-split-iterators with signatures like `&'_ Split<'a P: Pattern<'a>> -> &'a str` (Note: output `&str` lifetime is bound to the `'a` not the `'_`). The methods are similar to [`Chars::as_str`] `SplitInclusive::as_str` is under `""str_split_inclusive_as_str""` feature gate all other methods are under `""str_split_as_str""` feature gate. Before this PR you had to sum `len`s of all yielded parts or collect into `String` to emulate `as_str`. [`Chars::as_str`]: https://doc.rust-lang.org/core/str/struct.Chars.html#method.as_str",THUMBS_UP,2020-10-16T08:45:04Z,mikevoronov,NA https://github.com/rust-lang/rust/pull/75271,MERGED,2020-08-07T21:11:26Z,2020-08-08T23:06:00Z,Simplify array::IntoIter,cuviper,ceedf1d5febd65b012b8bcd513d70a0a6a091210,1,Auto merge of #75271 - cuviper:array-iter r=LukasKalbertodt Simplify array::IntoIter - Initialization can use `transmute_copy` to do the bitwise copy. - `as_slice` can use `get_unchecked` and `MaybeUninit::slice_get_ref` and `as_mut_slice` can do similar. - `next` and `next_back` can use the corresponding `Range` methods. - `Clone` doesn't need any unsafety and we can dynamically update the new range to get partial drops if `T::clone` panics. r? @LukasKalbertodt,HOORAY,2020-08-13T16:53:24Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-10-17T09:12:39Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-10-24T07:44:00Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-11-08T16:10:55Z,mati865,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-11-20T05:01:33Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-11-20T08:33:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-11-20T09:12:59Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-11-20T14:34:34Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2020-12-04T23:10:22Z,Catfish-Man,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2021-11-01T23:08:08Z,whentze,NA https://github.com/rust-lang/rust/pull/75272,MERGED,2020-08-07T23:07:45Z,2020-11-14T14:35:03Z,specialize io::copy to use copy_file_range splice or sendfile,the8472,30e49a9ead550551e879af64ba91a0316da1c422,11,"Auto merge of #75272 - the8472:spec-copy r=KodrAus specialize io::copy to use copy_file_range splice or sendfile Fixes #74426. Also covers #60689 but only as an optimization instead of an official API. The specialization only covers std-owned structs so it should avoid the problems with #71091 Currently linux-only but it should be generalizable to other unix systems that have sendfile/sosplice and similar. There is a bit of optimization potential around the syscall count. Right now it may end up doing more syscalls than the naive copy loop when doing short (<8KiB) copies between file descriptors. The test case executes the following: ``` [pid 103776] statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_ALL|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=17 ...}) = 0 [pid 103776] write(4 ""wxyz"" 4) = 4 [pid 103776] write(4 ""iklmn"" 5) = 5 [pid 103776] copy_file_range(3 NULL 4 NULL 5 0) = 5 ``` 0-1 `stat` calls to identify the source file type. 0 if the type can be inferred from the struct from which the FD was extracted 𝖬 `write` to drain the `BufReader`/`BufWriter` wrappers. only happen when buffers are present. 𝖬 ≾ number of wrappers present. If there is a write buffer it may absorb the read buffer contents first so only result in a single write. Vectored writes would also be an option but that would require more invasive changes to `BufWriter`. 𝖭 `copy_file_range`/`splice`/`sendfile` until file size EOF or the byte limit from `Take` is reached. This should generally be *much* more efficient than the read-write loop and also have other benefits such as DMA offload or extent sharing. ## Benchmarks ``` OLD test io::tests::bench_file_to_file_copy ... bench: 21 002 ns/iter (+/- 750) = 6240 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 35 704 ns/iter (+/- 1 108) = 3671 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 57 002 ns/iter (+/- 4 205) = 2299 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 142 640 ns/iter (+/- 77 851) = 918 MB/s NEW test io::tests::bench_file_to_file_copy ... bench: 14 745 ns/iter (+/- 519) = 8889 MB/s [ext4] test io::tests::bench_file_to_file_copy ... bench: 6 128 ns/iter (+/- 227) = 21389 MB/s [btrfs] test io::tests::bench_file_to_socket_copy ... bench: 13 767 ns/iter (+/- 3 767) = 9520 MB/s test io::tests::bench_socket_pipe_socket_copy ... bench: 26 471 ns/iter (+/- 6 412) = 4951 MB/s ```",HEART,2022-02-15T17:59:05Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/75280,MERGED,2020-08-08T06:17:49Z,2020-08-09T05:00:27Z,Add back unwinding support for Sony PSP,overdrivenpotato,f50f1c8e17a34ccaa0263c637e9686492b79477f,2,Auto merge of #75280 - overdrivenpotato:psp-unwind r=dtolnay Add back unwinding support for Sony PSP This PR adds back unwinding support for the Sony PSP. The `mipsel-sony-psp` target works well with unwinding. In [rust-psp] we use the `panic_unwind` crate along with LLVM's libunwind to catch panics run destructors and print them to the debug screen without aborting all threads. [rust-psp]: https://github.com/overdrivenpotato/rust-psp,LAUGH,2020-08-08T16:15:45Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/75280,MERGED,2020-08-08T06:17:49Z,2020-08-09T05:00:27Z,Add back unwinding support for Sony PSP,overdrivenpotato,f50f1c8e17a34ccaa0263c637e9686492b79477f,2,Auto merge of #75280 - overdrivenpotato:psp-unwind r=dtolnay Add back unwinding support for Sony PSP This PR adds back unwinding support for the Sony PSP. The `mipsel-sony-psp` target works well with unwinding. In [rust-psp] we use the `panic_unwind` crate along with LLVM's libunwind to catch panics run destructors and print them to the debug screen without aborting all threads. [rust-psp]: https://github.com/overdrivenpotato/rust-psp,LAUGH,2020-08-13T05:45:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75293,MERGED,2020-08-08T12:39:42Z,2020-08-09T14:29:47Z,Move to intra-doc links in library/std/src/path.rs,poliorcetics,8bc801b05019cd3e0ef19e6c4c028d55baa645d2,1,Auto merge of #75293 - poliorcetics:intra-doc-links-std-path r=jyn514 Move to intra-doc links in library/std/src/path.rs Helps with #75080. @rustbot modify labels: T-doc A-intra-doc-links T-rustdoc Known issue: The following links are broken (they are inside trait impls undocumented in this file inheriting from the original doc): - [`Hasher`] - [`Self`] (referencing `../primitive.slice.html`) - [`Ordering`],THUMBS_UP,2020-08-09T14:31:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/75298,CLOSED,2020-08-08T16:17:47Z,2020-09-01T18:26:37Z,Add the convenience method `Option::is_some_and`,LukasKalbertodt,NA,NA,NA,THUMBS_UP,2020-08-14T11:55:55Z,qnighy,NA https://github.com/rust-lang/rust/pull/75302,MERGED,2020-08-08T18:22:56Z,2020-08-25T23:14:15Z,Be consistent when describing a move as a 'partial' in diagnostics,Aaron1011,bf4342114e357f2934d59e12e31e94532ddb2adf,31,"Auto merge of #75302 - Aaron1011:feature/partial-move-diag r=estebank Be consistent when describing a move as a 'partial' in diagnostics When an error occurs due to a partial move we would use the world ""partial"" in some parts of the error message but not in others. This commit ensures that we use the word 'partial' in either all or none of the diagnostic messages. Additionally we no longer describe a move out of a `Box` via `*` as a 'partial move'. This was a pre-existing issue but became more noticable when the word 'partial' is used in more places.",THUMBS_UP,2020-08-09T02:47:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/75306,MERGED,2020-08-08T20:29:04Z,2020-08-09T03:06:58Z,Update hashbrown to 0.8.2,Amanieu,aced185592b6f99a21190965a7fecfcd72d954dc,1,Auto merge of #75306 - Amanieu:hashbrown8 r=Mark-Simulacrum Update hashbrown to 0.8.2 Includes: - Avoid closures to improve compile times (https://github.com/rust-lang/hashbrown/pull/183) - Do not iterate to drop if empty (https://github.com/rust-lang/hashbrown/pull/182) r? @Mark-Simulacrum,HEART,2020-08-09T01:56:29Z,nnethercote,NA https://github.com/rust-lang/rust/pull/75309,CLOSED,2020-08-08T21:58:01Z,2020-08-31T20:20:18Z,rustc_span: Generate keyword classification functions automatically,petrochenkov,NA,NA,NA,THUMBS_UP,2020-08-09T02:01:17Z,nnethercote,NA https://github.com/rust-lang/rust/pull/75320,MERGED,2020-08-09T03:54:25Z,2020-08-10T02:08:38Z,Detect likely `for foo of bar` JS syntax,estebank,d8ac403fd1c68660b6898777546cc191616cd48d,5,Rollup merge of #75320 - estebank:js-for-i-of-x r=davidtwco Detect likely `for foo of bar` JS syntax Fix #75311.,HEART,2020-08-09T04:31:34Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75320,MERGED,2020-08-09T03:54:25Z,2020-08-10T02:08:38Z,Detect likely `for foo of bar` JS syntax,estebank,d8ac403fd1c68660b6898777546cc191616cd48d,5,Rollup merge of #75320 - estebank:js-for-i-of-x r=davidtwco Detect likely `for foo of bar` JS syntax Fix #75311.,HEART,2020-08-09T08:35:33Z,Frizi,NA https://github.com/rust-lang/rust/pull/75320,MERGED,2020-08-09T03:54:25Z,2020-08-10T02:08:38Z,Detect likely `for foo of bar` JS syntax,estebank,d8ac403fd1c68660b6898777546cc191616cd48d,5,Rollup merge of #75320 - estebank:js-for-i-of-x r=davidtwco Detect likely `for foo of bar` JS syntax Fix #75311.,HEART,2020-08-20T00:04:03Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/75320,MERGED,2020-08-09T03:54:25Z,2020-08-10T02:08:38Z,Detect likely `for foo of bar` JS syntax,estebank,d8ac403fd1c68660b6898777546cc191616cd48d,5,Rollup merge of #75320 - estebank:js-for-i-of-x r=davidtwco Detect likely `for foo of bar` JS syntax Fix #75311.,HEART,2020-08-25T05:40:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75321,MERGED,2020-08-09T04:18:22Z,2020-08-12T10:44:13Z,Detect JS-style `===` and `!==` and recover,estebank,5989bf48724031b72326a5b731a15fca101339e2,6,Auto merge of #75321 - estebank:js-goes-gaga r=davidtwco Detect JS-style `===` and `!==` and recover Fix #75312.,HEART,2020-08-09T04:30:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/75321,MERGED,2020-08-09T04:18:22Z,2020-08-12T10:44:13Z,Detect JS-style `===` and `!==` and recover,estebank,5989bf48724031b72326a5b731a15fca101339e2,6,Auto merge of #75321 - estebank:js-goes-gaga r=davidtwco Detect JS-style `===` and `!==` and recover Fix #75312.,HEART,2020-08-09T21:52:42Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/75321,MERGED,2020-08-09T04:18:22Z,2020-08-12T10:44:13Z,Detect JS-style `===` and `!==` and recover,estebank,5989bf48724031b72326a5b731a15fca101339e2,6,Auto merge of #75321 - estebank:js-goes-gaga r=davidtwco Detect JS-style `===` and `!==` and recover Fix #75312.,HEART,2020-08-13T12:09:13Z,95th,NA https://github.com/rust-lang/rust/pull/75321,MERGED,2020-08-09T04:18:22Z,2020-08-12T10:44:13Z,Detect JS-style `===` and `!==` and recover,estebank,5989bf48724031b72326a5b731a15fca101339e2,6,Auto merge of #75321 - estebank:js-goes-gaga r=davidtwco Detect JS-style `===` and `!==` and recover Fix #75312.,HEART,2020-08-25T05:41:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75321,MERGED,2020-08-09T04:18:22Z,2020-08-12T10:44:13Z,Detect JS-style `===` and `!==` and recover,estebank,5989bf48724031b72326a5b731a15fca101339e2,6,Auto merge of #75321 - estebank:js-goes-gaga r=davidtwco Detect JS-style `===` and `!==` and recover Fix #75312.,HEART,2020-08-26T12:51:37Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75328,MERGED,2020-08-09T11:16:22Z,2020-08-10T02:08:36Z,Cleanup E0749,GuillaumeGomez,f6c41fbed7cc2087512faec1877667e77b47ea3a,2,Rollup merge of #75328 - GuillaumeGomez:cleanup-e0749 r=Dylan-DPC Cleanup E0749 r? @pickfire,CONFUSED,2020-08-09T20:14:53Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/75328,MERGED,2020-08-09T11:16:22Z,2020-08-10T02:08:36Z,Cleanup E0749,GuillaumeGomez,f6c41fbed7cc2087512faec1877667e77b47ea3a,2,Rollup merge of #75328 - GuillaumeGomez:cleanup-e0749 r=Dylan-DPC Cleanup E0749 r? @pickfire,LAUGH,2020-08-10T03:05:54Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75330,MERGED,2020-08-09T12:24:23Z,2020-08-28T12:23:18Z,Improve rendering of crate features via doc(cfg),Nemo157,8730c2beb742e406bcd8a1a846ad520322e1e132,3,"Rollup merge of #75330 - Nemo157:improve-doc-cfg-features r=GuillaumeGomez Improve rendering of crate features via doc(cfg) The current rendering of crate features with `doc(cfg(feature = ""..""))` is verbose and unwieldy for users `doc(cfg(target_feature = ""..""))` is special-cased to make it render nicely and a similar rendering can be applied to `doc(cfg(feature))` to make it easier for users to read. I also added special casing of `all`/`any` cfgs consisting of just `feature`/`target-feature` to remove the repetitive ""target/crate feature"" prefix. The downside of this current rendering is that there is no distinction between `feature` and `target_feature` in the shorthand display. IMO this is ok or if anything `target_feature` should have a more verbose shorthand because `doc(cfg(feature = ""..""))` usage is going to vastly outstrip `doc(cfg(target_feature = ""..""))` usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates using `cfg_attr(docsrs)` like constructs). ## Previously ## Now cc #43781",THUMBS_UP,2020-09-05T10:17:56Z,lnicola,NA https://github.com/rust-lang/rust/pull/75330,MERGED,2020-08-09T12:24:23Z,2020-08-28T12:23:18Z,Improve rendering of crate features via doc(cfg),Nemo157,8730c2beb742e406bcd8a1a846ad520322e1e132,3,"Rollup merge of #75330 - Nemo157:improve-doc-cfg-features r=GuillaumeGomez Improve rendering of crate features via doc(cfg) The current rendering of crate features with `doc(cfg(feature = ""..""))` is verbose and unwieldy for users `doc(cfg(target_feature = ""..""))` is special-cased to make it render nicely and a similar rendering can be applied to `doc(cfg(feature))` to make it easier for users to read. I also added special casing of `all`/`any` cfgs consisting of just `feature`/`target-feature` to remove the repetitive ""target/crate feature"" prefix. The downside of this current rendering is that there is no distinction between `feature` and `target_feature` in the shorthand display. IMO this is ok or if anything `target_feature` should have a more verbose shorthand because `doc(cfg(feature = ""..""))` usage is going to vastly outstrip `doc(cfg(target_feature = ""..""))` usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates using `cfg_attr(docsrs)` like constructs). ## Previously ## Now cc #43781",THUMBS_UP,2020-09-05T17:15:24Z,DianaNites,NA https://github.com/rust-lang/rust/pull/75330,MERGED,2020-08-09T12:24:23Z,2020-08-28T12:23:18Z,Improve rendering of crate features via doc(cfg),Nemo157,8730c2beb742e406bcd8a1a846ad520322e1e132,3,"Rollup merge of #75330 - Nemo157:improve-doc-cfg-features r=GuillaumeGomez Improve rendering of crate features via doc(cfg) The current rendering of crate features with `doc(cfg(feature = ""..""))` is verbose and unwieldy for users `doc(cfg(target_feature = ""..""))` is special-cased to make it render nicely and a similar rendering can be applied to `doc(cfg(feature))` to make it easier for users to read. I also added special casing of `all`/`any` cfgs consisting of just `feature`/`target-feature` to remove the repetitive ""target/crate feature"" prefix. The downside of this current rendering is that there is no distinction between `feature` and `target_feature` in the shorthand display. IMO this is ok or if anything `target_feature` should have a more verbose shorthand because `doc(cfg(feature = ""..""))` usage is going to vastly outstrip `doc(cfg(target_feature = ""..""))` usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates using `cfg_attr(docsrs)` like constructs). ## Previously ## Now cc #43781",THUMBS_UP,2021-09-04T22:51:24Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/75330,MERGED,2020-08-09T12:24:23Z,2020-08-28T12:23:18Z,Improve rendering of crate features via doc(cfg),Nemo157,8730c2beb742e406bcd8a1a846ad520322e1e132,3,"Rollup merge of #75330 - Nemo157:improve-doc-cfg-features r=GuillaumeGomez Improve rendering of crate features via doc(cfg) The current rendering of crate features with `doc(cfg(feature = ""..""))` is verbose and unwieldy for users `doc(cfg(target_feature = ""..""))` is special-cased to make it render nicely and a similar rendering can be applied to `doc(cfg(feature))` to make it easier for users to read. I also added special casing of `all`/`any` cfgs consisting of just `feature`/`target-feature` to remove the repetitive ""target/crate feature"" prefix. The downside of this current rendering is that there is no distinction between `feature` and `target_feature` in the shorthand display. IMO this is ok or if anything `target_feature` should have a more verbose shorthand because `doc(cfg(feature = ""..""))` usage is going to vastly outstrip `doc(cfg(target_feature = ""..""))` usage in non-stdlib crates when it eventually stabilizes (or even before that given the number of crates using `cfg_attr(docsrs)` like constructs). ## Previously ## Now cc #43781",THUMBS_UP,2021-09-14T13:08:38Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/75346,MERGED,2020-08-09T19:12:30Z,2020-09-20T06:21:32Z,shim: monomorphic `FnPtrShim`s during construction,davidtwco,a3bc0e752fad96f537b73f4e9bc805a73d404f7b,3,Auto merge of #75346 - davidtwco:issue-69925-polymorphic-instancedef-fnptrshim r=nikomatsakis shim: monomorphic `FnPtrShim`s during construction Fixes #69925. This PR adjusts MIR shim construction so that substitutions are applied to function pointer shims during construction rather than during codegen (as determined by `substs_for_mir_body`). r? `@eddyb`,HEART,2020-08-10T08:04:24Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75346,MERGED,2020-08-09T19:12:30Z,2020-09-20T06:21:32Z,shim: monomorphic `FnPtrShim`s during construction,davidtwco,a3bc0e752fad96f537b73f4e9bc805a73d404f7b,3,Auto merge of #75346 - davidtwco:issue-69925-polymorphic-instancedef-fnptrshim r=nikomatsakis shim: monomorphic `FnPtrShim`s during construction Fixes #69925. This PR adjusts MIR shim construction so that substitutions are applied to function pointer shims during construction rather than during codegen (as determined by `substs_for_mir_body`). r? `@eddyb`,HEART,2020-08-10T18:00:25Z,felix91gr,NA https://github.com/rust-lang/rust/pull/75347,MERGED,2020-08-09T19:28:52Z,2020-08-11T14:39:28Z,Rustdoc: Fix natural ordering to look at all numbers.,m-ou-se,a75bdfa230c3ff410693580ddc0ce1a6f2075fe7,2,Rollup merge of #75347 - fusion-engineering-forks:rustdoc-nat-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. ![image](https://user-images.githubusercontent.com/783247/89740226-28e8b180-da87-11ea-885d-77a7c8a6ba00.png),THUMBS_UP,2020-08-11T20:06:23Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/75358,CLOSED,2020-08-10T09:52:03Z,2020-08-24T12:26:54Z,Minimize the cost of write_fmt without arguments,tesuji,NA,NA,NA,THUMBS_UP,2020-08-10T10:36:44Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75358,CLOSED,2020-08-10T09:52:03Z,2020-08-24T12:26:54Z,Minimize the cost of write_fmt without arguments,tesuji,NA,NA,NA,THUMBS_UP,2020-08-10T10:57:31Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75366,MERGED,2020-08-10T14:54:05Z,2020-08-11T03:29:26Z,Add help button,GuillaumeGomez,51ed33d8c2b84cef48adb0a0b1ac8e88b4767a32,6,Rollup merge of #75366 - GuillaumeGomez:help-button r=jyn514 Add help button Part of #75197. Here is a screenshot of the result: ![Screenshot from 2020-08-10 16-53-20](https://user-images.githubusercontent.com/3050060/89796547-14112a00-db2a-11ea-9f25-57b30ab68f9b.png) r? @jyn514,THUMBS_UP,2020-08-10T15:47:39Z,Cldfire,NA https://github.com/rust-lang/rust/pull/75366,MERGED,2020-08-10T14:54:05Z,2020-08-11T03:29:26Z,Add help button,GuillaumeGomez,51ed33d8c2b84cef48adb0a0b1ac8e88b4767a32,6,Rollup merge of #75366 - GuillaumeGomez:help-button r=jyn514 Add help button Part of #75197. Here is a screenshot of the result: ![Screenshot from 2020-08-10 16-53-20](https://user-images.githubusercontent.com/3050060/89796547-14112a00-db2a-11ea-9f25-57b30ab68f9b.png) r? @jyn514,THUMBS_UP,2020-08-11T04:19:38Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/75366,MERGED,2020-08-10T14:54:05Z,2020-08-11T03:29:26Z,Add help button,GuillaumeGomez,51ed33d8c2b84cef48adb0a0b1ac8e88b4767a32,6,Rollup merge of #75366 - GuillaumeGomez:help-button r=jyn514 Add help button Part of #75197. Here is a screenshot of the result: ![Screenshot from 2020-08-10 16-53-20](https://user-images.githubusercontent.com/3050060/89796547-14112a00-db2a-11ea-9f25-57b30ab68f9b.png) r? @jyn514,THUMBS_UP,2020-10-12T15:57:25Z,worstpractice,NA https://github.com/rust-lang/rust/pull/75370,MERGED,2020-08-10T18:44:16Z,2020-08-29T14:37:25Z,New pass to optimize `if`conditions on integrals to switches on the integer,simonvandel,286a346d00ea534985195f3d72f4e1c5f3b07e2e,13,Auto merge of #75370 - simonvandel:optimize-if-condition-on-int-to-switch r=oli-obk New pass to optimize `if`conditions on integrals to switches on the integer Fixes #75144 Pass to convert `if` conditions on integrals into switches on the integral. For an example it turns something like ``` _3 = Eq(move _4 const 43i32); StorageDead(_4); switchInt(_3) -> [false: bb2 otherwise: bb3]; ``` into: ``` switchInt(_4) -> [43i32: bb3 otherwise: bb2]; ```,THUMBS_UP,2020-08-11T00:00:57Z,tesuji,NA https://github.com/rust-lang/rust/pull/75370,MERGED,2020-08-10T18:44:16Z,2020-08-29T14:37:25Z,New pass to optimize `if`conditions on integrals to switches on the integer,simonvandel,286a346d00ea534985195f3d72f4e1c5f3b07e2e,13,Auto merge of #75370 - simonvandel:optimize-if-condition-on-int-to-switch r=oli-obk New pass to optimize `if`conditions on integrals to switches on the integer Fixes #75144 Pass to convert `if` conditions on integrals into switches on the integral. For an example it turns something like ``` _3 = Eq(move _4 const 43i32); StorageDead(_4); switchInt(_3) -> [false: bb2 otherwise: bb3]; ``` into: ``` switchInt(_4) -> [43i32: bb3 otherwise: bb2]; ```,THUMBS_UP,2020-08-11T09:03:17Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/75370,MERGED,2020-08-10T18:44:16Z,2020-08-29T14:37:25Z,New pass to optimize `if`conditions on integrals to switches on the integer,simonvandel,286a346d00ea534985195f3d72f4e1c5f3b07e2e,13,Auto merge of #75370 - simonvandel:optimize-if-condition-on-int-to-switch r=oli-obk New pass to optimize `if`conditions on integrals to switches on the integer Fixes #75144 Pass to convert `if` conditions on integrals into switches on the integral. For an example it turns something like ``` _3 = Eq(move _4 const 43i32); StorageDead(_4); switchInt(_3) -> [false: bb2 otherwise: bb3]; ``` into: ``` switchInt(_4) -> [43i32: bb3 otherwise: bb2]; ```,THUMBS_UP,2020-08-19T22:28:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75370,MERGED,2020-08-10T18:44:16Z,2020-08-29T14:37:25Z,New pass to optimize `if`conditions on integrals to switches on the integer,simonvandel,286a346d00ea534985195f3d72f4e1c5f3b07e2e,13,Auto merge of #75370 - simonvandel:optimize-if-condition-on-int-to-switch r=oli-obk New pass to optimize `if`conditions on integrals to switches on the integer Fixes #75144 Pass to convert `if` conditions on integrals into switches on the integral. For an example it turns something like ``` _3 = Eq(move _4 const 43i32); StorageDead(_4); switchInt(_3) -> [false: bb2 otherwise: bb3]; ``` into: ``` switchInt(_4) -> [43i32: bb3 otherwise: bb2]; ```,THUMBS_UP,2020-09-05T08:54:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75370,MERGED,2020-08-10T18:44:16Z,2020-08-29T14:37:25Z,New pass to optimize `if`conditions on integrals to switches on the integer,simonvandel,286a346d00ea534985195f3d72f4e1c5f3b07e2e,13,Auto merge of #75370 - simonvandel:optimize-if-condition-on-int-to-switch r=oli-obk New pass to optimize `if`conditions on integrals to switches on the integer Fixes #75144 Pass to convert `if` conditions on integrals into switches on the integral. For an example it turns something like ``` _3 = Eq(move _4 const 43i32); StorageDead(_4); switchInt(_3) -> [false: bb2 otherwise: bb3]; ``` into: ``` switchInt(_4) -> [43i32: bb3 otherwise: bb2]; ```,THUMBS_UP,2020-09-06T17:12:40Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/75372,MERGED,2020-08-10T19:32:32Z,2020-08-13T04:21:10Z,Fix suggestion to use lifetime in type and in assoc const,estebank,d90a4b8ae9c6283bfae537f65e0cee41a69ed5f7,10,Rollup merge of #75372 - estebank:lt-sugg-in-type r=lcnr Fix suggestion to use lifetime in type and in assoc const _Do not merge until #75363 has landed as it has the test case for this._ * Account for associated types * Associated `const`s can't have generics (fix #74264) * Do not suggest duplicate lifetimes and suggest `for<'a>` more (fix #72404),HEART,2020-08-11T06:35:47Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75376,MERGED,2020-08-10T20:25:12Z,2020-08-15T05:06:19Z,Set CMAKE_SYSTEM_NAME when cross-compiling,tmiasko,29b6b5feaa86969dc97b42f72fe5837b0d8b523e,1,Rollup merge of #75376 - tmiasko:cmake-system-name r=Mark-Simulacrum Set CMAKE_SYSTEM_NAME when cross-compiling Configure CMAKE_SYSTEM_NAME when cross-compiling in `configure_cmake` to tell CMake about target system. Previously this was done only for LLVM step and now applies more generally to steps using cmake. Helps with #74576.,THUMBS_UP,2020-08-13T10:24:13Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/75377,MERGED,2020-08-10T21:10:11Z,2020-10-03T00:43:24Z,Fix Debug implementations of some of the HashMap and BTreeMap iterator types,canova,1118ab99301025f371f03c1345a5212c3068cf56,2,"Rollup merge of #75377 - canova:map_debug_impl r=dtolnay Fix Debug implementations of some of the HashMap and BTreeMap iterator types HashMap's `ValuesMut` BTreeMaps `ValuesMut` IntoValues and `IntoKeys` structs were printing both keys and values on their Debug implementations. But they are iterators over either keys or values. Irrelevant values should not be visible. With this PR they only show relevant fields. This fixes #75297. [Here's an example code.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0c79356ed860e347a0c1a205616f93b7) This prints this on nightly: ``` ValuesMut { inner: IterMut { range: [(1 ""hello"") (2 ""goodbye"")] length: 2 } } IntoKeys { inner: [(1 ""hello"") (2 ""goodbye"")] } IntoValues { inner: [(1 ""hello"") (2 ""goodbye"")] } [(2 ""goodbye"") (1 ""hello"")] ``` After the patch this example prints these instead: ``` [""hello"" ""goodbye""] [""hello"" ""goodbye""] [1 2] [""hello"" ""goodbye""] ``` I didn't add test cases for them since I couldn't see any tests for Debug implementations anywhere. But please let me know if I should add it to a specific place. r? @dtolnay",THUMBS_UP,2020-10-02T04:45:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75382,MERGED,2020-08-10T23:14:33Z,2020-08-13T21:36:15Z,First iteration of simplify match branches,JulianKnodt,5e3f1b148db5bfa27fee52464ae1f5d34c49d77b,5,Auto merge of #75382 - JulianKnodt:match_branches r=oli-obk First iteration of simplify match branches This is a simple MIR pass that attempts to convert ``` bb0: { StorageLive(_2); _3 = discriminant(_1); switchInt(move _3) -> [0isize: bb2 otherwise: bb1]; } bb1: { _2 = const false; goto -> bb3; } bb2: { _2 = const true; goto -> bb3; } ``` into ``` bb0: { StorageLive(_2); _3 = discriminant(_1); _2 = _3 == 0; goto -> bb3; } ``` There are still missing components(like checking if the assignments are bools). Was hoping that this could get some review though. Handles #75141 r? @oli-obk,THUMBS_UP,2020-08-13T19:40:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75389,MERGED,2020-08-11T07:43:06Z,2020-08-18T03:05:19Z,attempt to improve span_label docs,RalfJung,381a841d8d44696358c77645f593997139ca80f3,2,Rollup merge of #75389 - RalfJung:span_label r=davidtwco attempt to improve span_label docs I was still confused by the `span_label` docs so I did some more digging. However this needs careful checking as I have no idea if any of this is correct.,THUMBS_UP,2020-08-18T00:24:45Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75389,MERGED,2020-08-11T07:43:06Z,2020-08-18T03:05:19Z,attempt to improve span_label docs,RalfJung,381a841d8d44696358c77645f593997139ca80f3,2,Rollup merge of #75389 - RalfJung:span_label r=davidtwco attempt to improve span_label docs I was still confused by the `span_label` docs so I did some more digging. However this needs careful checking as I have no idea if any of this is correct.,THUMBS_UP,2020-08-18T05:48:18Z,estebank,NA https://github.com/rust-lang/rust/pull/75393,MERGED,2020-08-11T09:31:29Z,2020-08-11T21:23:07Z,"Fully handle ""?"" shortcut",GuillaumeGomez,a4211977d7814e2036f2a3e470bca17da81a01bf,1,"Rollup merge of #75393 - GuillaumeGomez:fix-help-shortcut r=pickfire Fully handle ""?"" shortcut Fixes #75386. cc @runiq",HEART,2020-08-11T09:34:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/75406,MERGED,2020-08-11T14:15:58Z,2020-10-13T16:11:26Z,Enable ASLR for windows-gnu,mati865,d65c08e9cc164b7b44de53503fae859a4fafd976,3,Auto merge of #75406 - mati865:mingw-aslr r=Mark-Simulacrum Enable ASLR for windows-gnu Fixes https://github.com/rust-lang/rust/issues/16514 Fixes https://github.com/rust-lang/rust/issues/16593 Fixes https://github.com/rust-lang/rust/issues/17684 Passes the tests for me with x86_64 toolchain.,HEART,2020-08-11T14:22:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75406,MERGED,2020-08-11T14:15:58Z,2020-10-13T16:11:26Z,Enable ASLR for windows-gnu,mati865,d65c08e9cc164b7b44de53503fae859a4fafd976,3,Auto merge of #75406 - mati865:mingw-aslr r=Mark-Simulacrum Enable ASLR for windows-gnu Fixes https://github.com/rust-lang/rust/issues/16514 Fixes https://github.com/rust-lang/rust/issues/16593 Fixes https://github.com/rust-lang/rust/issues/17684 Passes the tests for me with x86_64 toolchain.,HEART,2020-08-11T19:38:43Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/75406,MERGED,2020-08-11T14:15:58Z,2020-10-13T16:11:26Z,Enable ASLR for windows-gnu,mati865,d65c08e9cc164b7b44de53503fae859a4fafd976,3,Auto merge of #75406 - mati865:mingw-aslr r=Mark-Simulacrum Enable ASLR for windows-gnu Fixes https://github.com/rust-lang/rust/issues/16514 Fixes https://github.com/rust-lang/rust/issues/16593 Fixes https://github.com/rust-lang/rust/issues/17684 Passes the tests for me with x86_64 toolchain.,HEART,2020-08-11T23:29:51Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/75406,MERGED,2020-08-11T14:15:58Z,2020-10-13T16:11:26Z,Enable ASLR for windows-gnu,mati865,d65c08e9cc164b7b44de53503fae859a4fafd976,3,Auto merge of #75406 - mati865:mingw-aslr r=Mark-Simulacrum Enable ASLR for windows-gnu Fixes https://github.com/rust-lang/rust/issues/16514 Fixes https://github.com/rust-lang/rust/issues/16593 Fixes https://github.com/rust-lang/rust/issues/17684 Passes the tests for me with x86_64 toolchain.,HEART,2020-10-11T01:06:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-11T23:36:30Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T01:56:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T02:19:46Z,ehuss,NA https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T03:37:23Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T04:48:23Z,branan,branan@gmail.com https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T07:42:29Z,cynecx,NA https://github.com/rust-lang/rust/pull/75427,MERGED,2020-08-11T23:27:20Z,2020-08-12T04:43:39Z,Update RLS and Rustfmt,Xanewok,840dbe7654bf3e803d0b447960bd9c120661cd1d,3,Auto merge of #75427 - Xanewok:update-rls r=Dylan-DPC Update RLS and Rustfmt Closes #74811 Closes #74812 r? @calebcartwright,HEART,2020-08-12T15:35:47Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/75428,MERGED,2020-08-11T23:31:52Z,2020-09-05T21:03:11Z,Workarounds for copy_file_range issues,the8472,de921ab3c3aa25d65b1476d77285da1ca99af397,1,Auto merge of #75428 - the8472:fix-copy-eopnotsupp r=joshtriplett Workarounds for copy_file_range issues fixes #75387 fixes #75446,THUMBS_UP,2020-08-25T16:04:35Z,sjackman,sjackman@gmail.com https://github.com/rust-lang/rust/pull/75428,MERGED,2020-08-11T23:31:52Z,2020-09-05T21:03:11Z,Workarounds for copy_file_range issues,the8472,de921ab3c3aa25d65b1476d77285da1ca99af397,1,Auto merge of #75428 - the8472:fix-copy-eopnotsupp r=joshtriplett Workarounds for copy_file_range issues fixes #75387 fixes #75446,THUMBS_UP,2021-06-30T02:28:55Z,kubo39,NA https://github.com/rust-lang/rust/pull/75431,MERGED,2020-08-12T01:00:24Z,2020-08-13T08:24:04Z,Move platform support to the rustc book.,ehuss,d69b0997d7dcc99a188d5cb19137dedc4fc05d25,9,Auto merge of #75431 - ehuss:platform-support r=Mark-Simulacrum Move platform support to the rustc book. This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this: * The forge is not really oriented towards end-users (it mostly contains infrastructure governance and policy internal team pages etc.). This platform support page is useful to user to know which targets are supported. * This page can now be updated in-sync with any PRs that add or remove a target or change its status. * This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry but more sophisticated checks could be added in the future. I'm not 100% certain this is the best location but I think it fits. I'd like to see the rustc guide continue to grow including things like linking information and more platform-specific details.,ROCKET,2020-08-12T03:30:05Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/75431,MERGED,2020-08-12T01:00:24Z,2020-08-13T08:24:04Z,Move platform support to the rustc book.,ehuss,d69b0997d7dcc99a188d5cb19137dedc4fc05d25,9,Auto merge of #75431 - ehuss:platform-support r=Mark-Simulacrum Move platform support to the rustc book. This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this: * The forge is not really oriented towards end-users (it mostly contains infrastructure governance and policy internal team pages etc.). This platform support page is useful to user to know which targets are supported. * This page can now be updated in-sync with any PRs that add or remove a target or change its status. * This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry but more sophisticated checks could be added in the future. I'm not 100% certain this is the best location but I think it fits. I'd like to see the rustc guide continue to grow including things like linking information and more platform-specific details.,ROCKET,2020-08-12T20:01:48Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/75431,MERGED,2020-08-12T01:00:24Z,2020-08-13T08:24:04Z,Move platform support to the rustc book.,ehuss,d69b0997d7dcc99a188d5cb19137dedc4fc05d25,9,Auto merge of #75431 - ehuss:platform-support r=Mark-Simulacrum Move platform support to the rustc book. This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this: * The forge is not really oriented towards end-users (it mostly contains infrastructure governance and policy internal team pages etc.). This platform support page is useful to user to know which targets are supported. * This page can now be updated in-sync with any PRs that add or remove a target or change its status. * This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry but more sophisticated checks could be added in the future. I'm not 100% certain this is the best location but I think it fits. I'd like to see the rustc guide continue to grow including things like linking information and more platform-specific details.,THUMBS_UP,2020-08-13T01:14:40Z,tmandry,NA https://github.com/rust-lang/rust/pull/75431,MERGED,2020-08-12T01:00:24Z,2020-08-13T08:24:04Z,Move platform support to the rustc book.,ehuss,d69b0997d7dcc99a188d5cb19137dedc4fc05d25,9,Auto merge of #75431 - ehuss:platform-support r=Mark-Simulacrum Move platform support to the rustc book. This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this: * The forge is not really oriented towards end-users (it mostly contains infrastructure governance and policy internal team pages etc.). This platform support page is useful to user to know which targets are supported. * This page can now be updated in-sync with any PRs that add or remove a target or change its status. * This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry but more sophisticated checks could be added in the future. I'm not 100% certain this is the best location but I think it fits. I'd like to see the rustc guide continue to grow including things like linking information and more platform-specific details.,THUMBS_UP,2020-08-13T01:56:17Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-08-13T05:23:09Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-08-14T04:18:32Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-09-15T04:12:20Z,Lokathor,NA https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-09-20T09:11:38Z,LiHRaM,NA https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-09-20T10:31:07Z,gmosx,george.moschovitis@gmail.com https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,HEART,2020-09-20T14:21:50Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/75435,CLOSED,2020-08-12T02:11:25Z,2020-11-11T17:22:55Z,Add `std::io::input` simple input function.,sHaDoW-54,NA,NA,NA,THUMBS_UP,2020-11-12T17:05:36Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/75443,MERGED,2020-08-12T07:09:48Z,2020-08-13T17:22:48Z,allow escaping bound vars when normalizing `ty::Opaque`,lcnr,0a49057dd35d9bd2fcc9760a054809c30eee2a58,3,Auto merge of #75443 - lcnr:opaque-normalize r=nikomatsakis allow escaping bound vars when normalizing `ty::Opaque` implements https://github.com/rust-lang/rust/issues/75313#issuecomment-672216146 and fixes #75313 cc @eddyb @RalfJung r? @nikomatsakis,THUMBS_UP,2020-08-12T08:34:52Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/75448,MERGED,2020-08-12T10:29:56Z,2020-08-15T05:06:14Z,merge `as_local_hir_id` with `local_def_id_to_hir_id`,lcnr,28b11abc2f336288379b6e635e65e23809616487,82,Rollup merge of #75448 - lcnr:rn-as_local_hir_id r=davidtwco merge `as_local_hir_id` with `local_def_id_to_hir_id` `as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing. Don't really care about which of these 2 methods we want to keep. Does this require an MCP considering that these methods are fairly frequently used?,THUMBS_UP,2020-08-12T11:16:21Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75452,MERGED,2020-08-12T12:49:00Z,2020-08-14T05:18:40Z,self-profile: Cache more query key strings when doing self-profiling.,michaelwoerister,6f964f0a077c1eed1ee51f46cbb506341e4407b4,1,Rollup merge of #75452 - michaelwoerister:sp-cache-more-query-keys r=lcnr self-profile: Cache more query key strings when doing self-profiling. This PR adds optimized `SpecIntoSelfProfilingString` implementations for two common query key types (`LocalDefId` and `WithOptConstParam`). This makes raw self-profiling data on disk 8-9% smaller for my two test cases (`regex` and `cargo`). The on-disk format is not affected so no tooling updates need to happen. I also tried adding an impl for `Ty<'tcx>` (which should reduce size quite a bit) but the compiler did not allow me to add a specialized impl parameterized with `'tcx`. I don't know if there is an actual problem with that or if the implementation of specialization just doesn't support it yet. cc @wesleywiser @Mark-Simulacrum,HEART,2020-08-12T13:20:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75452,MERGED,2020-08-12T12:49:00Z,2020-08-14T05:18:40Z,self-profile: Cache more query key strings when doing self-profiling.,michaelwoerister,6f964f0a077c1eed1ee51f46cbb506341e4407b4,1,Rollup merge of #75452 - michaelwoerister:sp-cache-more-query-keys r=lcnr self-profile: Cache more query key strings when doing self-profiling. This PR adds optimized `SpecIntoSelfProfilingString` implementations for two common query key types (`LocalDefId` and `WithOptConstParam`). This makes raw self-profiling data on disk 8-9% smaller for my two test cases (`regex` and `cargo`). The on-disk format is not affected so no tooling updates need to happen. I also tried adding an impl for `Ty<'tcx>` (which should reduce size quite a bit) but the compiler did not allow me to add a specialized impl parameterized with `'tcx`. I don't know if there is an actual problem with that or if the implementation of specialization just doesn't support it yet. cc @wesleywiser @Mark-Simulacrum,HEART,2020-08-13T14:46:24Z,lqd,NA https://github.com/rust-lang/rust/pull/75455,MERGED,2020-08-12T14:17:21Z,2020-08-13T04:20:58Z,Use explicit path link in place for doc in time,pickfire,9ea03ddd0b189fda850ae646057349c49f4ce7e4,1,Rollup merge of #75455 - pickfire:patch-3 r=jyn514 Use explicit path link in place for doc in time r? @jyn514 More worth for your time. :P,LAUGH,2020-08-12T14:29:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75465,MERGED,2020-08-12T21:20:01Z,2020-08-23T10:26:11Z,Use smaller def span for functions,Aaron1011,d5ba3efed1e7e25014671fb9da5f23b98358d994,107,"Auto merge of #75465 - Aaron1011:feature/short-fn-def-span r=estebank Use smaller def span for functions Currently the def span of a function encompasses the entire function signature and body. However this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions `impl`-block methods and `trait`-block methods) to be the span of the signature. For example the function ```rust pub fn foo(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); } ``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope=""in this scope"")]` attribute points the entire scope body. All of these cases work only with local items so we don't need to add anything extra to crate metadata.",THUMBS_UP,2020-08-13T01:18:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/75465,MERGED,2020-08-12T21:20:01Z,2020-08-23T10:26:11Z,Use smaller def span for functions,Aaron1011,d5ba3efed1e7e25014671fb9da5f23b98358d994,107,"Auto merge of #75465 - Aaron1011:feature/short-fn-def-span r=estebank Use smaller def span for functions Currently the def span of a function encompasses the entire function signature and body. However this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions `impl`-block methods and `trait`-block methods) to be the span of the signature. For example the function ```rust pub fn foo(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); } ``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope=""in this scope"")]` attribute points the entire scope body. All of these cases work only with local items so we don't need to add anything extra to crate metadata.",THUMBS_UP,2020-08-21T23:39:23Z,estebank,NA https://github.com/rust-lang/rust/pull/75472,MERGED,2020-08-12T22:43:55Z,2020-08-16T18:48:36Z,Add option to use the new symbol mangling in rustc/std,Mark-Simulacrum,009551f758d1d007ad0f7b652bfa8ddba0738117,3,Auto merge of #75472 - Mark-Simulacrum:mangling-config r=eddyb Add option to use the new symbol mangling in rustc/std I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it though. cc @nnethercote r? @eddyb,HOORAY,2020-08-12T22:57:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75472,MERGED,2020-08-12T22:43:55Z,2020-08-16T18:48:36Z,Add option to use the new symbol mangling in rustc/std,Mark-Simulacrum,009551f758d1d007ad0f7b652bfa8ddba0738117,3,Auto merge of #75472 - Mark-Simulacrum:mangling-config r=eddyb Add option to use the new symbol mangling in rustc/std I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it though. cc @nnethercote r? @eddyb,HOORAY,2020-08-12T23:07:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/75472,MERGED,2020-08-12T22:43:55Z,2020-08-16T18:48:36Z,Add option to use the new symbol mangling in rustc/std,Mark-Simulacrum,009551f758d1d007ad0f7b652bfa8ddba0738117,3,Auto merge of #75472 - Mark-Simulacrum:mangling-config r=eddyb Add option to use the new symbol mangling in rustc/std I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it though. cc @nnethercote r? @eddyb,HOORAY,2020-08-13T00:07:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75472,MERGED,2020-08-12T22:43:55Z,2020-08-16T18:48:36Z,Add option to use the new symbol mangling in rustc/std,Mark-Simulacrum,009551f758d1d007ad0f7b652bfa8ddba0738117,3,Auto merge of #75472 - Mark-Simulacrum:mangling-config r=eddyb Add option to use the new symbol mangling in rustc/std I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it though. cc @nnethercote r? @eddyb,HOORAY,2020-08-13T08:23:02Z,mati865,NA https://github.com/rust-lang/rust/pull/75472,MERGED,2020-08-12T22:43:55Z,2020-08-16T18:48:36Z,Add option to use the new symbol mangling in rustc/std,Mark-Simulacrum,009551f758d1d007ad0f7b652bfa8ddba0738117,3,Auto merge of #75472 - Mark-Simulacrum:mangling-config r=eddyb Add option to use the new symbol mangling in rustc/std I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it though. cc @nnethercote r? @eddyb,HOORAY,2020-08-16T18:17:48Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/75483,MERGED,2020-08-13T11:51:01Z,2020-08-15T18:01:14Z,Add LLD flags for MinGW,mati865,5addb135edc2653b07670482a430aac9b655a86b,6,"Auto merge of #75483 - mati865:mingw-lld-flags r=petrochenkov Add LLD flags for MinGW Tested locally and this now works: - `RUSTFLAGS=""-Zlink-self-contained=yes -Clinker=rust-lld"" cargo b` - `RUSTFLAGS=""-Zlink-self-contained=no -Clinker=rust-lld -Zpre-link-arg=-Ld:/msys64/mingw64/x86_64-w64-mingw32/lib -Zpre-link-arg=-Ld:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.0 -Zpre-link-arg=crt2.o"" cargo b` This is ""harmless"" part of the changes to make possible linking with bare LLD with windows-gnu target. More debatable changes should follow in next PRs soon.",HOORAY,2020-08-14T12:52:56Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2020-08-13T19:31:11Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2021-01-15T06:16:57Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2021-01-15T11:44:21Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2021-01-16T07:46:02Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2022-02-23T12:46:38Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/75490,MERGED,2020-08-13T15:47:33Z,2021-01-11T21:32:58Z,Add `[T; N]::each_ref` and `[T; N]::each_mut`,LukasKalbertodt,c5eae562935922f712edec56a45591bc2f8ded1c,1,Auto merge of #75490 - LukasKalbertodt:add-basic-array-methods r=dtolnay Add `[T; N]::each_ref` and `[T; N]::each_mut` This PR adds the methods `each_ref` and `each_mut` to `[T; N]`. The ability to add methods to arrays was added in #75212. These two methods are particularly useful with `map` which was also added in that PR. Tracking issue: #76118 ```rust impl [T; N] { pub fn each_ref(&self) -> [&T; N]; pub fn each_mut(&mut self) -> [&mut T; N]; } ```,HEART,2022-05-19T17:56:10Z,RuvenSalamon,ruven.salamon@gmail.com https://github.com/rust-lang/rust/pull/75496,MERGED,2020-08-13T20:07:40Z,2020-08-14T05:18:29Z,Prioritization WG: Open Zulip topics only for `I-prioritize` issues,spastorino,912b5b3067699618ae89d88a75f7d2afcc3f70ef,1,Rollup merge of #75496 - spastorino:prioritization-zulip-topics r=Mark-Simulacrum Prioritization WG: Open Zulip topics only for `I-prioritize` issues This was discussed in https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/nominations.20and.20other.20automatically.20opened.20topics Is not being helpful to open topics on any of these events and it's even causing more work for the group. @LeSeulArtichaut ... I think this is all that's needed to get rid of this right?. r? @Mark-Simulacrum cc @rust-lang/wg-prioritization @bors rollup=always,THUMBS_UP,2020-08-13T20:09:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75496,MERGED,2020-08-13T20:07:40Z,2020-08-14T05:18:29Z,Prioritization WG: Open Zulip topics only for `I-prioritize` issues,spastorino,912b5b3067699618ae89d88a75f7d2afcc3f70ef,1,Rollup merge of #75496 - spastorino:prioritization-zulip-topics r=Mark-Simulacrum Prioritization WG: Open Zulip topics only for `I-prioritize` issues This was discussed in https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/nominations.20and.20other.20automatically.20opened.20topics Is not being helpful to open topics on any of these events and it's even causing more work for the group. @LeSeulArtichaut ... I think this is all that's needed to get rid of this right?. r? @Mark-Simulacrum cc @rust-lang/wg-prioritization @bors rollup=always,THUMBS_UP,2020-08-13T20:25:49Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75502,MERGED,2020-08-13T21:25:15Z,2020-09-19T13:32:47Z,Use implicit (not explicit) rules for promotability by default in `const fn`,ecstatic-morse,f62ba52f5c100eadd658d6685e680518b71cdb77,1,Rollup merge of #75502 - ecstatic-morse:implicit-promotion-in-const-fn r=RalfJung Use implicit (not explicit) rules for promotability by default in `const fn` For crater run. See https://github.com/rust-lang/const-eval/pull/54#discussion_r469995552. cc #75586,HEART,2020-08-14T06:08:52Z,RalfJung,NA https://github.com/rust-lang/rust/pull/75502,MERGED,2020-08-13T21:25:15Z,2020-09-19T13:32:47Z,Use implicit (not explicit) rules for promotability by default in `const fn`,ecstatic-morse,f62ba52f5c100eadd658d6685e680518b71cdb77,1,Rollup merge of #75502 - ecstatic-morse:implicit-promotion-in-const-fn r=RalfJung Use implicit (not explicit) rules for promotability by default in `const fn` For crater run. See https://github.com/rust-lang/const-eval/pull/54#discussion_r469995552. cc #75586,HEART,2020-09-10T04:32:44Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75503,MERGED,2020-08-13T22:02:36Z,2020-08-14T11:30:27Z,Clean up some mir transform passes,JulianKnodt,6b2ca8457a0f6450896c669caf880090a18d1541,5,Auto merge of #75503 - JulianKnodt:opt_opt r=oli-obk Clean up some mir transform passes I noticed a few places where there were intermediates being created in MIR optimization passes so I removed them. I also changed some `Some(..)` into just `..` and wrap `Some(..)` at the function end doing early returns for `None`. I was generally looking for some easy optimizations in theses passes and hopefully these should improve the runtime of these passes by a tinnnyyyyy bit. r? @oli-obk,HEART,2020-08-14T00:43:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/75505,MERGED,2020-08-13T22:50:55Z,2020-08-24T10:29:49Z,Add Arc::new_cyclic,Dylan-DPC-zz,9d7456243244141808b39ee8ed32767a7a1dc7d7,3,Auto merge of #75505 - Dylan-DPC:feature/arc_new r=KodrAus Add Arc::new_cyclic Rework of #72443 References #75861 cc @Diggsey @RalfJung r? @KodrAus,HOORAY,2020-08-27T04:42:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75505,MERGED,2020-08-13T22:50:55Z,2020-08-24T10:29:49Z,Add Arc::new_cyclic,Dylan-DPC-zz,9d7456243244141808b39ee8ed32767a7a1dc7d7,3,Auto merge of #75505 - Dylan-DPC:feature/arc_new r=KodrAus Add Arc::new_cyclic Rework of #72443 References #75861 cc @Diggsey @RalfJung r? @KodrAus,HOORAY,2020-08-29T19:42:35Z,max-heller,max_heller@brown.edu https://github.com/rust-lang/rust/pull/75511,MERGED,2020-08-14T01:30:25Z,2020-08-15T00:45:19Z,Do not emit E0228 when it is implied by E0106,estebank,0c8c3b9079bb5213d846cc592e36d6f851d01bb7,3,Rollup merge of #75511 - estebank:elide-trait-object-lt-error r=lcnr Do not emit E0228 when it is implied by E0106 Emit E0288 (lifetime bound for trait object cannot be deduced) only on bare trait objects. When the trait object is in the form of `&dyn Trait` E0106 (missing lifetime specifier) will have been emitted making the former redundant.,HEART,2020-08-14T13:03:29Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75513,MERGED,2020-08-14T04:16:10Z,2020-08-15T05:06:07Z,Recover gracefully from `struct` parse errors,estebank,e38eaf22d247644e5554d0c200e6df756e469b0a,5,Rollup merge of #75513 - estebank:confused-parser r=davidtwco Recover gracefully from `struct` parse errors Currently the parser tries to recover from finding a keyword where a field name was expected but this causes extra knock down parse errors that are completely irrelevant. Instead bail out early in the parsing of the field and consume the remaining tokens in the block. This can reduce output significantly. _Improvements based on the narrative in https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust_,HEART,2020-08-14T14:09:06Z,jplatte,NA https://github.com/rust-lang/rust/pull/75516,MERGED,2020-08-14T09:28:11Z,2020-08-18T22:48:47Z,Promote missing_fragment_specifier to hard error,matklad,30f0a07684f6c1f5df62d69e9519d82e13d6bf2d,18,Auto merge of #75516 - matklad:remove-deprecation r=petrochenkov Promote missing_fragment_specifier to hard error It has been deny_by_default since 2017 (and warned for some time before that) so it seems reasonable to promote it. The specific technical motivation to do this now is to remove a field from `ParseSess` -- it is a global state and global state makes extracting libraries annoying. Closes #40107,THUMBS_UP,2020-08-14T11:07:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75534,MERGED,2020-08-14T18:34:53Z,2020-11-01T19:18:22Z,Implement rustc side of report-future-incompat,Aaron1011,b2025326088b54fb3f083bebeba14e0a15bf00d3,28,Auto merge of #75534 - Aaron1011:feature/new-future-breakage r=pnkfelix Implement rustc side of report-future-incompat cc https://github.com/rust-lang/rust/issues/71249 This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ). My approach outputs the entire original `Diagnostic` in a way that is compatible with incremental compilation. This is not yet integrated with compiletest but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`. Several changes are made to support this feature: * The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`. * The `Lint` struct is extended with an `Option`. When present it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently a `date` field indicating when the crate will stop compiling). * A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place while still discarding them before they are passed to the `Emitter`. * `DiagnosticId::Lint` is extended with a `has_future_breakage` field indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report). * `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint` to retrieve the `FutureBreakage` data. Currently `FutureBreakage.date` is always set to `None`. However this could potentially be interpreted by Cargo in the future. I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself. cc `@pnkfelix`,HOORAY,2020-08-26T21:29:13Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/75534,MERGED,2020-08-14T18:34:53Z,2020-11-01T19:18:22Z,Implement rustc side of report-future-incompat,Aaron1011,b2025326088b54fb3f083bebeba14e0a15bf00d3,28,Auto merge of #75534 - Aaron1011:feature/new-future-breakage r=pnkfelix Implement rustc side of report-future-incompat cc https://github.com/rust-lang/rust/issues/71249 This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ). My approach outputs the entire original `Diagnostic` in a way that is compatible with incremental compilation. This is not yet integrated with compiletest but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`. Several changes are made to support this feature: * The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`. * The `Lint` struct is extended with an `Option`. When present it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently a `date` field indicating when the crate will stop compiling). * A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place while still discarding them before they are passed to the `Emitter`. * `DiagnosticId::Lint` is extended with a `has_future_breakage` field indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report). * `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint` to retrieve the `FutureBreakage` data. Currently `FutureBreakage.date` is always set to `None`. However this could potentially be interpreted by Cargo in the future. I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself. cc `@pnkfelix`,HOORAY,2020-08-26T21:40:35Z,est31,NA https://github.com/rust-lang/rust/pull/75536,MERGED,2020-08-14T19:09:20Z,2020-08-16T13:15:53Z,Tweak output of E0225,estebank,97ba0c7171c4d2d9b899a2bd8e40a8974c47b86d,11,Auto merge of #75536 - estebank:e0255-suggestion r=varkor Tweak output of E0225 When encountering multiple non-auto trait bounds suggest creating a new trait and explain what auto-traits are. _Inspired by https://fasterthanli.me/articles/frustrated-its-not-you-its-rust_,HEART,2020-08-14T22:04:49Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75560,MERGED,2020-08-15T11:17:09Z,2020-08-15T19:51:43Z,Add rustc-docs as a component,Mark-Simulacrum,f9d17312c9e51e6f9da86db4c6aa7210397ca5f6,1,Auto merge of #75560 - Mark-Simulacrum:rustc-docs r=matthiaskrgr Add rustc-docs as a component Previously it was listed as a package but wasn't available in the component lists in rustup so wasn't actually installable. rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll also be shipped for aarch64-gnu with current CI configuration but that builder isn't quite up and running yet. We probably want to ship compiler docs for other platforms as well though but this commit doesn't enable that quite yet. A future PR may do so by adding --enable-compiler-docs to the relevant builders (but it would also need to decide the set of builders which we'd ship on). r? @matthiaskrgr,THUMBS_UP,2020-08-15T16:08:11Z,lnicola,NA https://github.com/rust-lang/rust/pull/75560,MERGED,2020-08-15T11:17:09Z,2020-08-15T19:51:43Z,Add rustc-docs as a component,Mark-Simulacrum,f9d17312c9e51e6f9da86db4c6aa7210397ca5f6,1,Auto merge of #75560 - Mark-Simulacrum:rustc-docs r=matthiaskrgr Add rustc-docs as a component Previously it was listed as a package but wasn't available in the component lists in rustup so wasn't actually installable. rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll also be shipped for aarch64-gnu with current CI configuration but that builder isn't quite up and running yet. We probably want to ship compiler docs for other platforms as well though but this commit doesn't enable that quite yet. A future PR may do so by adding --enable-compiler-docs to the relevant builders (but it would also need to decide the set of builders which we'd ship on). r? @matthiaskrgr,THUMBS_UP,2020-08-15T16:40:19Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75561,MERGED,2020-08-15T11:39:43Z,2020-08-16T08:45:52Z,Doc: String isn't a collection,kornelski,243c725c2401e00c83ac68e80fa18d3b0dd3f551,1,Auto merge of #75561 - kornelski:stringcol r=Dylan-DPC Doc: String isn't a collection On forums one user was confused by this text interpreting it as saying that `String` is a `Vec` literally rather than figuratively for the purpose of collect. I've reworded that paragraph.,THUMBS_UP,2020-08-15T14:01:38Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/75566,MERGED,2020-08-15T16:16:50Z,2020-08-18T09:44:39Z,Suppress verbose MIR comments for trivial types,alasher,4717cf2fcbde585d81c47417b1fb921572a3c537,132,Auto merge of #75566 - alasher:master r=oli-obk Suppress verbose MIR comments for trivial types Addresses #74508 This is my first contribution to the Rust project! Please let me know if anything needs revising I'm happy to make changes.,THUMBS_UP,2020-08-16T09:06:22Z,tesuji,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,HOORAY,2020-08-15T20:31:27Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,HOORAY,2020-08-16T09:01:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-08-18T03:42:28Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-08-29T03:32:23Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-08-29T16:42:15Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,HOORAY,2020-08-31T16:17:06Z,mati865,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-09-08T11:51:46Z,taiki-e,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-09-10T18:45:10Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,THUMBS_UP,2020-09-16T22:46:45Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/75573,MERGED,2020-08-15T20:27:43Z,2020-09-10T08:08:39Z,Add CONST_ITEM_MUTATION lint,Aaron1011,88197214b8a9099bb3da559a3bd7bf4867c10c5f,22,Auto merge of #75573 - Aaron1011:feature/const-mutation-lint r=oli-obk Add CONST_ITEM_MUTATION lint Fixes #74053 Fixes #55721 This PR adds a new lint `CONST_ITEM_MUTATION`. Given an item `const FOO: SomeType = ..` this lint fires on: * Attempting to write directly to a field (`FOO.field = some_val`) or array entry (`FOO.array_field[0] = val`) * Taking a mutable reference to the `const` item (`&mut FOO`) including through an autoderef `FOO.some_mut_self_method()` The lint message explains that since each use of a constant creates a new temporary the original `const` item will not be modified.,HOORAY,2020-09-27T16:01:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75608,MERGED,2020-08-16T20:49:03Z,2020-09-14T21:44:14Z,More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions,estebank,41dc3942eb33e8e882b6e4782a9bd9d2b8970647,9,Auto merge of #75608 - estebank:suggest-boxed-match-exprs r=lcnr varkor More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions When encountering a `match` or `if` as a tail expression where the different arms do not have the same type *and* the return type of that `fn` is an `impl Trait` check whether those arms can implement `Trait` and if so suggest using boxed trait objects. Use structured suggestion for `impl T` to `Box`. Fix https://github.com/rust-lang/rust/issues/69107,THUMBS_UP,2020-09-23T20:36:02Z,adamreichold,NA https://github.com/rust-lang/rust/pull/75611,MERGED,2020-08-16T23:54:41Z,2020-09-11T10:45:47Z,Add help note when using type in place of const,JulianKnodt,a7425476e81207c7ff3d229b69172e78a732da5d,3,Auto merge of #75611 - JulianKnodt:cg_enum_err r=lcnr Add help note when using type in place of const This adds a small help note when it might be possible that wrapping a parameter in braces might resolve the issue of having a type where a const was expected. Currently I am displaying the `HirId` and I'm not particularly sure where to get the currently displayed path(?). r? `@lcnr`,HEART,2020-08-21T07:38:58Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75615,CLOSED,2020-08-17T06:04:59Z,2020-10-23T00:24:26Z,Add Polly Support,namibj,NA,NA,NA,HOORAY,2020-08-17T11:54:07Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2020-11-04T01:00:41Z,est31,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-05-28T10:53:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-06-04T12:00:22Z,CryZe,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-06-04T13:56:03Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-06-04T15:27:56Z,DaTa-,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-07-27T19:52:26Z,branpk,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-08-20T00:26:23Z,delacian,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-08-22T13:56:56Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,EYES,2021-09-25T03:08:08Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-09T03:19:37Z,DianaNites,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-11T14:02:34Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-11T15:10:57Z,loovjo,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-12T00:56:15Z,Folyd,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-12T06:56:37Z,aslynatilla,antonio.natilla30@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,HOORAY,2021-10-12T20:02:17Z,dmgolembiowski,david@dgolembiowski.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-12T20:02:18Z,dmgolembiowski,david@dgolembiowski.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-14T12:25:59Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-14T16:33:48Z,Esper89,esperenzathomson@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,EYES,2021-10-14T16:33:51Z,Esper89,esperenzathomson@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,HOORAY,2021-10-14T22:28:27Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-15T02:58:03Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,HOORAY,2021-10-15T06:01:42Z,kawogi,NA https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-15T11:05:50Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,THUMBS_UP,2021-10-16T12:08:24Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/75644,MERGED,2020-08-17T18:52:29Z,2021-10-09T19:05:11Z,Add 'core::array::from_fn' and 'core::array::try_from_fn',c410-f3r,86bf3ce8591343bcc2442e95d6432f3b78e07cc5,3,Rollup merge of #75644 - c410-f3r:array r=yaahc Add 'core::array::from_fn' and 'core::array::try_from_fn' These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`. ```rust // Foo doesn't implement Default struct Foo(usize); let _array = core::array::from_fn::<_ _ 2>(|idx| Foo(idx)); ``` Different from `FromIterator` it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios however the creation of an **element** can fail and that is why the `try_from_fn` function is also provided. ```rust #[derive(Debug PartialEq)] enum SomeError { Foo } let array = core::array::try_from_fn(|i| Ok::<_ SomeError>(i)); assert_eq!(array Ok([0 1 2 3 4])); let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo)); assert_eq!(another_array Err(SomeError::Foo)); ```,EYES,2021-12-06T01:52:51Z,g-berthiaume,NA https://github.com/rust-lang/rust/pull/75648,MERGED,2020-08-17T21:57:01Z,2020-08-19T20:20:40Z,Make OnceCell transparent to dropck,matklad,4123237fa16776b9806c2f7da721e8adc50ce43d,2,Rollup merge of #75648 - matklad:lazy-dropck r=KodrAus Make OnceCell transparent to dropck See the failed build in https://github.com/rust-lang/rust/pull/75555#issuecomment-675016718 for an example where we need this in real life r? @ghost,EYES,2020-08-19T10:23:42Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/75658,MERGED,2020-08-18T08:22:45Z,2020-08-19T09:10:37Z,"Don't emit ""is not a logical operator"" error outside of associative expressions",tgnottingham,e6fe5232df75246921f8b89d0161e4508f1cc535,7,"Rollup merge of #75658 - tgnottingham:issue-75599 r=estebank Don't emit ""is not a logical operator"" error outside of associative expressions Avoid showing this error where it doesn't make sense by not assuming ""and"" and ""or"" were intended to mean ""&&"" and ""||"" until after we decide to continue parsing input as an associative expression. Note that the decision of whether or not to continue parsing input as an associative expression doesn't actually depend on this assumption. Fixes #75599 --- First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)",HEART,2020-08-19T10:31:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/75666,MERGED,2020-08-18T11:37:52Z,2020-08-25T03:05:19Z,hir: consistent use and naming of lang items,davidtwco,3e041cec75c45e78730972194db3401af06b72ef,43,"Auto merge of #75666 - davidtwco:tidy-lang-items r=varkor hir: consistent use and naming of lang items This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or ""LangItem"". In addition lang item variants are no longer exported from the `lang_items` module. This is certainly subjective and while I think this is an improvement if many in the team don't then we can just close this.",THUMBS_UP,2020-08-18T14:34:10Z,tesuji,NA https://github.com/rust-lang/rust/pull/75666,MERGED,2020-08-18T11:37:52Z,2020-08-25T03:05:19Z,hir: consistent use and naming of lang items,davidtwco,3e041cec75c45e78730972194db3401af06b72ef,43,"Auto merge of #75666 - davidtwco:tidy-lang-items r=varkor hir: consistent use and naming of lang items This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or ""LangItem"". In addition lang item variants are no longer exported from the `lang_items` module. This is certainly subjective and while I think this is an improvement if many in the team don't then we can just close this.",THUMBS_UP,2020-08-20T07:17:12Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75666,MERGED,2020-08-18T11:37:52Z,2020-08-25T03:05:19Z,hir: consistent use and naming of lang items,davidtwco,3e041cec75c45e78730972194db3401af06b72ef,43,"Auto merge of #75666 - davidtwco:tidy-lang-items r=varkor hir: consistent use and naming of lang items This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or ""LangItem"". In addition lang item variants are no longer exported from the `lang_items` module. This is certainly subjective and while I think this is an improvement if many in the team don't then we can just close this.",THUMBS_UP,2020-08-23T19:03:49Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,THUMBS_UP,2020-08-18T16:44:40Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,HEART,2020-08-18T17:53:25Z,estebank,NA https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,HEART,2020-08-19T16:31:43Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,HEART,2020-11-17T20:56:32Z,DianaNites,NA https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,THUMBS_UP,2020-11-17T20:56:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/75671,MERGED,2020-08-18T16:14:50Z,2020-10-28T01:41:39Z,Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc,nathanwhit,90e6d0d46bae511aecea04ac5eeb3c387f0c04f4,15,Auto merge of #75671 - nathanwhit:cstring-temp-lint r=oli-obk Uplift `temporary-cstring-as-ptr` lint from `clippy` into rustc The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc. The diagnostic message might need some tweaking as I'm not sure the use of second-person perspective matches the rest of rustc but I'd like to hear others' thoughts on that. (cc #53224). r? `@oli-obk`,THUMBS_UP,2021-04-08T10:06:48Z,gwy15,gwy15thu@gmail.com https://github.com/rust-lang/rust/pull/75675,MERGED,2020-08-18T18:31:29Z,2020-10-16T02:29:42Z,mangling: mangle impl params w/ v0 scheme,davidtwco,1643fd86a727d84cf14db9c71cd8951196fb53d7,8,Rollup merge of #75675 - davidtwco:symbol-mangling-impl-params r=eddyb mangling: mangle impl params w/ v0 scheme This PR modifies v0 symbol mangling to include all generic parameters from impl blocks (not just those used in the self type) - an alternative fix to #75326. ``` original: _RNCNvXCs4fqI2P2rA04_19impl_param_manglingINtB4_3FooppENtNtNtNtCsfnEnqCNU58Z_4core4iter6traits8iterator8Iterator4next0B4_ // |------------ B4_ ----------------| // _R (N C (N v (X (C ((s 4fqI2p2rA04_) 19impl_param_mangling)) (I (N t B4_ 3Foo) pp E) (N t (N t (N t (N t (C ((s fnEnqCNU58Z_) 4core)) 4iter) 6traits) 8iterator) 8Iterator)) 4next) 0) B4_ modified: _RNvXINICs4fqI2P2rA04_11issue_753260pppEINtB5_3FooppENtNtNtNtCsfnEnqCNU58Z_4core4iter6traits8iterator8Iterator4nextB5_ // _R (N v (X (I (N I (C ((s 4fqI2P2rA04_) 11issue_75326)) 0) ppp E) (I (N t B5_ 3Foo) pp E) (N t (N t (N t (N t (C ((s fnEnqCNU58Z_) 4core)) 4iter) 6traits) 8iterator) 8Iterator)) 4next) B5_ // | ^ | // | | | // | new impl namespace | ``` ~~Submitted as a draft as after some discussion w/ @eddyb I'm going to do some investigation into (yet more alternative) changes to polymorphization that might remove the necessity for this.~~ r? @eddyb,HEART,2020-08-18T20:38:02Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75675,MERGED,2020-08-18T18:31:29Z,2020-10-16T02:29:42Z,mangling: mangle impl params w/ v0 scheme,davidtwco,1643fd86a727d84cf14db9c71cd8951196fb53d7,8,Rollup merge of #75675 - davidtwco:symbol-mangling-impl-params r=eddyb mangling: mangle impl params w/ v0 scheme This PR modifies v0 symbol mangling to include all generic parameters from impl blocks (not just those used in the self type) - an alternative fix to #75326. ``` original: _RNCNvXCs4fqI2P2rA04_19impl_param_manglingINtB4_3FooppENtNtNtNtCsfnEnqCNU58Z_4core4iter6traits8iterator8Iterator4next0B4_ // |------------ B4_ ----------------| // _R (N C (N v (X (C ((s 4fqI2p2rA04_) 19impl_param_mangling)) (I (N t B4_ 3Foo) pp E) (N t (N t (N t (N t (C ((s fnEnqCNU58Z_) 4core)) 4iter) 6traits) 8iterator) 8Iterator)) 4next) 0) B4_ modified: _RNvXINICs4fqI2P2rA04_11issue_753260pppEINtB5_3FooppENtNtNtNtCsfnEnqCNU58Z_4core4iter6traits8iterator8Iterator4nextB5_ // _R (N v (X (I (N I (C ((s 4fqI2P2rA04_) 11issue_75326)) 0) ppp E) (I (N t B5_ 3Foo) pp E) (N t (N t (N t (N t (C ((s fnEnqCNU58Z_) 4core)) 4iter) 6traits) 8iterator) 8Iterator)) 4next) B5_ // | ^ | // | | | // | new impl namespace | ``` ~~Submitted as a draft as after some discussion w/ @eddyb I'm going to do some investigation into (yet more alternative) changes to polymorphization that might remove the necessity for this.~~ r? @eddyb,HEART,2020-08-21T02:08:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75677,MERGED,2020-08-18T18:58:49Z,2020-08-19T04:50:43Z,Don't panic in Vec::shrink_to_fit,cuviper,c03c213daf5fe3b52c768b4f145e45d8994d87ea,2,Auto merge of #75677 - cuviper:shrink-towel r=Mark-Simulacrum Don't panic in Vec::shrink_to_fit We can help the compiler see that `Vec::shrink_to_fit` will never reach the panic case in `RawVec::shrink_to_fit` just by guarding the call only for cases where the capacity is strictly greater. A capacity less than the length is only possible through an unsafe call to `set_len` which would break the `Vec` invariants so `shrink_to_fit` can just ignore that. This removes the panicking code from the examples in both #71861 and #75636.,THUMBS_UP,2020-08-27T03:55:59Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/75687,MERGED,2020-08-19T04:49:03Z,2020-08-26T13:11:05Z,Allow reallocation to different alignment in `AllocRef`,TimDiekmann,ffd59bf9c62125813abae8ca52f0ac3a67459e8f,5,Auto merge of #75687 - TimDiekmann:realloc-align r=Amanieu Allow reallocation to different alignment in `AllocRef` The allocator-wg [has decided](https://github.com/rust-lang/wg-allocators/issues/5#issuecomment-672591112) to support reallocating to a different alignment in `AllocRef`. For more details please see the linked issue. r? @Amanieu closes https://github.com/rust-lang/wg-allocators/issues/5,HEART,2020-08-27T19:46:47Z,TiagodePAlves,t187679@dac.unicamp.br https://github.com/rust-lang/rust/pull/75695,MERGED,2020-08-19T08:22:20Z,2020-09-05T17:19:18Z,Add a regression test for issue-72793,JohnTitor,cb33a15c3ef2567168cbe33232fd3702d3705e21,1,Rollup merge of #75695 - JohnTitor:regression-test r=Dylan-DPC Add a regression test for issue-72793 Adds a regression test for #72793 which is fixed by #75443. Note that this won't close the issue as the snippet still shows ICE with `-Zmir-opt-level=2`. But it makes sense to add a test anyway.,THUMBS_UP,2020-08-19T08:25:14Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/75699,MERGED,2020-08-19T10:32:59Z,2020-10-04T06:49:41Z,Uplift drop-bounds lint from clippy,notriddle,b654555a32baa44872587ac170fe02af14db0b74,15,Rollup merge of #75699 - notriddle:drop-bounds-lint r=petrochenkov Uplift drop-bounds lint from clippy Bounds on `T: Drop` do nothing so they should warn.,HEART,2020-08-19T10:39:05Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75699,MERGED,2020-08-19T10:32:59Z,2020-10-04T06:49:41Z,Uplift drop-bounds lint from clippy,notriddle,b654555a32baa44872587ac170fe02af14db0b74,15,Rollup merge of #75699 - notriddle:drop-bounds-lint r=petrochenkov Uplift drop-bounds lint from clippy Bounds on `T: Drop` do nothing so they should warn.,HEART,2020-08-19T21:15:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75699,MERGED,2020-08-19T10:32:59Z,2020-10-04T06:49:41Z,Uplift drop-bounds lint from clippy,notriddle,b654555a32baa44872587ac170fe02af14db0b74,15,Rollup merge of #75699 - notriddle:drop-bounds-lint r=petrochenkov Uplift drop-bounds lint from clippy Bounds on `T: Drop` do nothing so they should warn.,HEART,2020-08-19T21:30:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/75703,MERGED,2020-08-19T12:40:30Z,2020-08-20T20:27:29Z,Enable stack-overflow detection on musl for non-main threads,tmiasko,7ac126ec563cd1b987dd1aa49d4a3b9288c03771,3,Rollup merge of #75703 - tmiasko:stack-overflow-musl r=cuviper Enable stack-overflow detection on musl for non-main threads,HOORAY,2020-08-19T13:10:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/75703,MERGED,2020-08-19T12:40:30Z,2020-08-20T20:27:29Z,Enable stack-overflow detection on musl for non-main threads,tmiasko,7ac126ec563cd1b987dd1aa49d4a3b9288c03771,3,Rollup merge of #75703 - tmiasko:stack-overflow-musl r=cuviper Enable stack-overflow detection on musl for non-main threads,HOORAY,2020-08-19T13:56:49Z,mati865,NA https://github.com/rust-lang/rust/pull/75717,CLOSED,2020-08-19T19:14:12Z,2020-09-26T13:28:12Z,add `array::FillError` similar to `array::IntoIter`,lcnr,NA,NA,NA,HEART,2020-08-19T19:23:14Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/75717,CLOSED,2020-08-19T19:14:12Z,2020-09-26T13:28:12Z,add `array::FillError` similar to `array::IntoIter`,lcnr,NA,NA,NA,HEART,2020-08-19T20:50:30Z,lperlaki,lperlaki@icloud.com https://github.com/rust-lang/rust/pull/75720,MERGED,2020-08-19T21:09:26Z,2020-08-20T05:06:54Z,Update books,ehuss,f6049b60dbbc267a69b5c5f1d335f8f54bac2173,5,Auto merge of #75720 - ehuss:update-books r=ehuss Update books ## nomicon 2 commits in bfe1ab96d717d1dda50e499b360f2e2f57e1750a..25854752549d44d76fbd7650e17cb4f167a0b8fb 2020-06-05 13:19:42 -0400 to 2020-08-19 16:41:48 -0400 - Follow-up of rust-lang/rust#75152 (rust-lang-nursery/nomicon#235) - Follow-up for rust-lang/rust#74850 (rust-lang-nursery/nomicon#233) ## reference 7 commits in c9b2736a059469043177e1e4ed41a55d7c63ac28..1b6c4b0afab97c0230433466c97167bbbe8445f6 2020-08-03 03:34:03 -0700 to 2020-08-18 17:04:28 -0700 - Some constant/static updates. (rust-lang-nursery/reference#867) - Add casting rules from function items to other types (rust-lang-nursery/reference#878) - Apply joshtriplett's suggestion - Add note clarifying 16-bit support. - Document min pointer width. - Update to `dyn Trait` syntax in a couple places (rust-lang-nursery/reference#875) - mention that `#[track_caller]` on `fn main` is forbidden (rust-lang-nursery/reference#872) ## book 2 commits in 363293c1c5ce9e84ea3935a5e29ce8624801208a..c0a6a61b8205da14ac955425f74258ffd8ee065d 2020-08-03 15:56:30 -0500 to 2020-08-14 14:21:49 -0500 - Correct listing 11-10: Take tests module out of main function. (rust-lang/book#2427) - Update link to russian translation (rust-lang/book#2423) ## rust-by-example 5 commits in 2e9271981adc32613365810f3428334c07095215..80a10e22140e28392b99d24ed02f4c6d8cb770a0 2020-07-27 13:39:16 -0500 to 2020-08-08 09:56:46 -0300 - Add tuple `..` operator example (rust-lang/rust-by-example#1368) - Clarify wording (rust-lang/rust-by-example#1366) - Include arc (rust-lang/rust-by-example#1365) - Modify supertraits sample code (rust-lang/rust-by-example#1361) - Remove mention of `try!` in `Display` example (rust-lang/rust-by-example#1357) ## embedded-book 3 commits in b5256448a2a4c1bec68b93c0847066f92f2ff5a9..0cd2ca116274b915924c3a7e07c1e046b6f19b77 2020-07-24 23:09:29 +0000 to 2020-08-19 10:33:15 +0000 - Ignore unused argument in closure (rust-embedded/book#261) - Fix broken sentence (rust-embedded/book#260) - Add additional command to try when verifying installation. (rust-embedded/book#259),HEART,2020-08-19T21:20:44Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/75728,MERGED,2020-08-20T01:32:05Z,2020-10-26T09:13:14Z,Optimise align_offset for stride=1 further,nagisa,69e68cf550fb7ba6137b167c17d0fcbe7ea06ce2,1,Auto merge of #75728 - nagisa:improve_align_offset_2 r=Mark-Simulacrum Optimise align_offset for stride=1 further `stride == 1` case can be computed more efficiently through `-p (mod a)`. That then translates to a nice and short sequence of LLVM instructions: %address = ptrtoint i8* %p to i64 %negptr = sub i64 0 %address %offset = and i64 %negptr %a_minus_one And produces pretty much ideal code-gen when this function is used in isolation. Typical use of this function will however involve use of the result to offset a pointer i.e. %aligned = getelementptr inbounds i8 i8* %p i64 %offset This still looks very good but LLVM does not really translate that to what would be considered ideal machine code (on any target). For example that's the codegen we obtain for an unknown alignment: ; x86_64 dec rsi mov rax rdi neg rax and rax rsi add rax rdi In particular negating a pointer is not something that’s going to be optimised for in the design of CISC architectures like x86_64. They are much better at offsetting pointers. And so we’d love to utilize this ability and produce code that's more like this: ; x86_64 lea rax [rsi + rdi - 1] neg rsi and rax rsi To achieve this we need to give LLVM an opportunity to apply its various peep-hole optimisations that it does during DAG selection. In particular the `and` instruction appears to be a major inhibitor here. We cannot sadly get rid of this load-bearing operation but we can reorder operations such that LLVM has more to work with around this instruction. One such ordering is proposed in #75579 and results in LLVM IR that looks broadly like this: ; using add enables `lea` and similar CISCisms %offset_ptr = add i64 %address %a_minus_one %mask = sub i64 0 %a %masked = and i64 %offset_ptr %mask ; can be folded with `gepi` that may follow %offset = sub i64 %masked %address …and generates the intended x86_64 machine code. One might also wonder how the increased amount of code would impact a RISC target. Turns out not much: ; aarch64 previous ; aarch64 new sub x8 x1 #1 add x8 x1 x0 neg x9 x0 sub x8 x8 #1 and x8 x9 x8 neg x9 x1 add x0 x0 x8 and x0 x8 x9 (and similarly for ppc sparc mips riscv etc) The only target that seems to do worse is… wasm32. Onto actual measurements – the best way to evaluate snipets like these is to use llvm-mca. Much like Aarch64 assembly would allow to suspect there isn’t any performance difference to be found. Both snippets execute in same number of cycles for the CPUs I tried. On x86_64 we get throughput improvement of >50%! Fixes #75579,HEART,2020-08-24T17:45:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/75728,MERGED,2020-08-20T01:32:05Z,2020-10-26T09:13:14Z,Optimise align_offset for stride=1 further,nagisa,69e68cf550fb7ba6137b167c17d0fcbe7ea06ce2,1,Auto merge of #75728 - nagisa:improve_align_offset_2 r=Mark-Simulacrum Optimise align_offset for stride=1 further `stride == 1` case can be computed more efficiently through `-p (mod a)`. That then translates to a nice and short sequence of LLVM instructions: %address = ptrtoint i8* %p to i64 %negptr = sub i64 0 %address %offset = and i64 %negptr %a_minus_one And produces pretty much ideal code-gen when this function is used in isolation. Typical use of this function will however involve use of the result to offset a pointer i.e. %aligned = getelementptr inbounds i8 i8* %p i64 %offset This still looks very good but LLVM does not really translate that to what would be considered ideal machine code (on any target). For example that's the codegen we obtain for an unknown alignment: ; x86_64 dec rsi mov rax rdi neg rax and rax rsi add rax rdi In particular negating a pointer is not something that’s going to be optimised for in the design of CISC architectures like x86_64. They are much better at offsetting pointers. And so we’d love to utilize this ability and produce code that's more like this: ; x86_64 lea rax [rsi + rdi - 1] neg rsi and rax rsi To achieve this we need to give LLVM an opportunity to apply its various peep-hole optimisations that it does during DAG selection. In particular the `and` instruction appears to be a major inhibitor here. We cannot sadly get rid of this load-bearing operation but we can reorder operations such that LLVM has more to work with around this instruction. One such ordering is proposed in #75579 and results in LLVM IR that looks broadly like this: ; using add enables `lea` and similar CISCisms %offset_ptr = add i64 %address %a_minus_one %mask = sub i64 0 %a %masked = and i64 %offset_ptr %mask ; can be folded with `gepi` that may follow %offset = sub i64 %masked %address …and generates the intended x86_64 machine code. One might also wonder how the increased amount of code would impact a RISC target. Turns out not much: ; aarch64 previous ; aarch64 new sub x8 x1 #1 add x8 x1 x0 neg x9 x0 sub x8 x8 #1 and x8 x9 x8 neg x9 x1 add x0 x0 x8 and x0 x8 x9 (and similarly for ppc sparc mips riscv etc) The only target that seems to do worse is… wasm32. Onto actual measurements – the best way to evaluate snipets like these is to use llvm-mca. Much like Aarch64 assembly would allow to suspect there isn’t any performance difference to be found. Both snippets execute in same number of cycles for the CPUs I tried. On x86_64 we get throughput improvement of >50%! Fixes #75579,HEART,2020-08-27T03:51:25Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/75728,MERGED,2020-08-20T01:32:05Z,2020-10-26T09:13:14Z,Optimise align_offset for stride=1 further,nagisa,69e68cf550fb7ba6137b167c17d0fcbe7ea06ce2,1,Auto merge of #75728 - nagisa:improve_align_offset_2 r=Mark-Simulacrum Optimise align_offset for stride=1 further `stride == 1` case can be computed more efficiently through `-p (mod a)`. That then translates to a nice and short sequence of LLVM instructions: %address = ptrtoint i8* %p to i64 %negptr = sub i64 0 %address %offset = and i64 %negptr %a_minus_one And produces pretty much ideal code-gen when this function is used in isolation. Typical use of this function will however involve use of the result to offset a pointer i.e. %aligned = getelementptr inbounds i8 i8* %p i64 %offset This still looks very good but LLVM does not really translate that to what would be considered ideal machine code (on any target). For example that's the codegen we obtain for an unknown alignment: ; x86_64 dec rsi mov rax rdi neg rax and rax rsi add rax rdi In particular negating a pointer is not something that’s going to be optimised for in the design of CISC architectures like x86_64. They are much better at offsetting pointers. And so we’d love to utilize this ability and produce code that's more like this: ; x86_64 lea rax [rsi + rdi - 1] neg rsi and rax rsi To achieve this we need to give LLVM an opportunity to apply its various peep-hole optimisations that it does during DAG selection. In particular the `and` instruction appears to be a major inhibitor here. We cannot sadly get rid of this load-bearing operation but we can reorder operations such that LLVM has more to work with around this instruction. One such ordering is proposed in #75579 and results in LLVM IR that looks broadly like this: ; using add enables `lea` and similar CISCisms %offset_ptr = add i64 %address %a_minus_one %mask = sub i64 0 %a %masked = and i64 %offset_ptr %mask ; can be folded with `gepi` that may follow %offset = sub i64 %masked %address …and generates the intended x86_64 machine code. One might also wonder how the increased amount of code would impact a RISC target. Turns out not much: ; aarch64 previous ; aarch64 new sub x8 x1 #1 add x8 x1 x0 neg x9 x0 sub x8 x8 #1 and x8 x9 x8 neg x9 x1 add x0 x0 x8 and x0 x8 x9 (and similarly for ppc sparc mips riscv etc) The only target that seems to do worse is… wasm32. Onto actual measurements – the best way to evaluate snipets like these is to use llvm-mca. Much like Aarch64 assembly would allow to suspect there isn’t any performance difference to be found. Both snippets execute in same number of cycles for the CPUs I tried. On x86_64 we get throughput improvement of >50%! Fixes #75579,HEART,2020-09-03T18:30:43Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/75728,MERGED,2020-08-20T01:32:05Z,2020-10-26T09:13:14Z,Optimise align_offset for stride=1 further,nagisa,69e68cf550fb7ba6137b167c17d0fcbe7ea06ce2,1,Auto merge of #75728 - nagisa:improve_align_offset_2 r=Mark-Simulacrum Optimise align_offset for stride=1 further `stride == 1` case can be computed more efficiently through `-p (mod a)`. That then translates to a nice and short sequence of LLVM instructions: %address = ptrtoint i8* %p to i64 %negptr = sub i64 0 %address %offset = and i64 %negptr %a_minus_one And produces pretty much ideal code-gen when this function is used in isolation. Typical use of this function will however involve use of the result to offset a pointer i.e. %aligned = getelementptr inbounds i8 i8* %p i64 %offset This still looks very good but LLVM does not really translate that to what would be considered ideal machine code (on any target). For example that's the codegen we obtain for an unknown alignment: ; x86_64 dec rsi mov rax rdi neg rax and rax rsi add rax rdi In particular negating a pointer is not something that’s going to be optimised for in the design of CISC architectures like x86_64. They are much better at offsetting pointers. And so we’d love to utilize this ability and produce code that's more like this: ; x86_64 lea rax [rsi + rdi - 1] neg rsi and rax rsi To achieve this we need to give LLVM an opportunity to apply its various peep-hole optimisations that it does during DAG selection. In particular the `and` instruction appears to be a major inhibitor here. We cannot sadly get rid of this load-bearing operation but we can reorder operations such that LLVM has more to work with around this instruction. One such ordering is proposed in #75579 and results in LLVM IR that looks broadly like this: ; using add enables `lea` and similar CISCisms %offset_ptr = add i64 %address %a_minus_one %mask = sub i64 0 %a %masked = and i64 %offset_ptr %mask ; can be folded with `gepi` that may follow %offset = sub i64 %masked %address …and generates the intended x86_64 machine code. One might also wonder how the increased amount of code would impact a RISC target. Turns out not much: ; aarch64 previous ; aarch64 new sub x8 x1 #1 add x8 x1 x0 neg x9 x0 sub x8 x8 #1 and x8 x9 x8 neg x9 x1 add x0 x0 x8 and x0 x8 x9 (and similarly for ppc sparc mips riscv etc) The only target that seems to do worse is… wasm32. Onto actual measurements – the best way to evaluate snipets like these is to use llvm-mca. Much like Aarch64 assembly would allow to suspect there isn’t any performance difference to be found. Both snippets execute in same number of cycles for the CPUs I tried. On x86_64 we get throughput improvement of >50%! Fixes #75579,HEART,2020-11-06T18:40:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/75736,CLOSED,2020-08-20T09:50:49Z,2020-08-20T12:07:11Z,RawVec: do not inline panics,lcnr,NA,NA,NA,THUMBS_UP,2020-08-20T11:44:56Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/75737,CLOSED,2020-08-20T10:45:23Z,2021-10-04T09:57:01Z,polymorphize: remove predicate logic,davidtwco,NA,NA,NA,HOORAY,2020-08-21T02:08:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/75737,CLOSED,2020-08-20T10:45:23Z,2021-10-04T09:57:01Z,polymorphize: remove predicate logic,davidtwco,NA,NA,NA,HOORAY,2020-11-27T11:59:04Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/75737,CLOSED,2020-08-20T10:45:23Z,2021-10-04T09:57:01Z,polymorphize: remove predicate logic,davidtwco,NA,NA,NA,HOORAY,2021-05-17T04:45:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75741,MERGED,2020-08-20T11:53:33Z,2020-09-05T17:19:15Z,Refactor byteorder to std in rustc_middle,workingjubilee,e160d2b3e0fe110562062bc9aff9e1ef977db2d9,4,Rollup merge of #75741 - workingjubilee:refactor-byteorder r=matthewjasper Refactor byteorder to std in rustc_middle Use std::io::{Read Write} and {to from}_{le be}_bytes methods in order to remove byteorder from librustc_middle's dependency graph.,HEART,2020-08-20T12:22:36Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",THUMBS_UP,2020-08-21T00:39:40Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",THUMBS_UP,2020-08-21T12:44:30Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",HEART,2020-08-21T12:55:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",THUMBS_UP,2020-08-26T21:48:21Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",HEART,2020-08-28T02:35:43Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",THUMBS_UP,2021-01-19T12:47:56Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/75752,MERGED,2020-08-20T22:30:51Z,2020-11-29T07:05:51Z,libtest: Print the total time taken to execute a test suite,jakoschiko,6add378d6b77a727697f2920a9cc85a63766297e,43,"Auto merge of #75752 - jakoschiko:test-suite-time r=m-ou-se libtest: Print the total time taken to execute a test suite Print the total time taken to execute a test suite by default without any kind of flag. Closes #75660 # Example ``` anon@anon:~/code/rust/example$ cargo test Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.18s Running target/debug/deps/example-745b64d3885c3565 running 3 tests test tests::foo ... ok test tests::bar ... ok test tests::baz ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests test src/lib.rs - foo (line 3) ... ok test src/lib.rs - bar (line 11) ... ok test src/lib.rs - baz (line 19) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format terse Finished test [unoptimized + debuginfo] target(s) in 0.08s Running target/debug/deps/example-745b64d3885c3565 running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s Doc-tests example running 3 tests ... test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s ``` ``` anon@anon:~/code/rust/example$ cargo test -- --format json -Z unstable-options Compiling example v0.1.0 (/home/anon/code/rust/example) Finished test [unoptimized + debuginfo] target(s) in 0.25s Running target/debug/deps/example-745b64d3885c3565 { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::bar"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::baz"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""tests::foo"" } { ""type"": ""test"" ""name"": ""tests::foo"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::bar"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""tests::baz"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.2s"" } Doc-tests example { ""type"": ""suite"" ""event"": ""started"" ""test_count"": 3 } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - bar (line 11)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - baz (line 19)"" } { ""type"": ""test"" ""event"": ""started"" ""name"": ""src/lib.rs - foo (line 3)"" } { ""type"": ""test"" ""name"": ""src/lib.rs - foo (line 3)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - bar (line 11)"" ""event"": ""ok"" } { ""type"": ""test"" ""name"": ""src/lib.rs - baz (line 19)"" ""event"": ""ok"" } { ""type"": ""suite"" ""event"": ""ok"" ""passed"": 3 ""failed"": 0 ""allowed_fail"": 0 ""ignored"": 0 ""measured"": 0 ""filtered_out"": 0 ""exec_time"": ""1.3s"" } ```",THUMBS_UP,2021-02-13T02:39:42Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75756,MERGED,2020-08-20T23:46:56Z,2020-09-12T07:46:21Z,Improve suggestions for broken intra-doc links,jyn514,0f5c76951327b912c8e92e83235430ebd9b349d9,18,"Auto merge of #75756 - jyn514:diagnostic-suggestions r=estebank Improve suggestions for broken intra-doc links ~~Depends on #74489 and should not be merged before that PR.~~ Merged 🎉 ~~Depends on #75916 and should not be merged before.~~ Merged Fixes https://github.com/rust-lang/rust/issues/75305. This does a lot of different things 😆. - Add `PerNS::into_iter()` so I didn't have to keep rewriting hacks around it. Also add `PerNS::iter()` for consistency. Let me know if this should be `impl IntoIterator` instead. - Make `ResolutionFailure` an enum instead of a unit variant. This was most of the changes: everywhere that said `ErrorKind::ResolutionFailure` now has to say _why_ the link failed to resolve. - Store the resolution in case of an anchor failure. Previously this was implemented as variants on `AnchorFailure` which was prone to typos and had inconsistent output compared to the rest of the diagnostics. - Turn some `Err`ors into unwrap() or panic()s because they're rustdoc bugs and not user error. These have comments as to why they're bugs (in particular this would have caught #76073 as a bug a while ago). - If an item is not in scope at all say the first segment in the path that failed to resolve - If an item exists but not in the current namespaces say that and suggests linking to that namespace. - If there is a partial resolution for an item (part of the segments resolved but not all of them) say the partial resolution and why the following segment didn't resolve. - Add the `DefId` of associated items to `kind_side_channel` so it can be used for diagnostics (tl;dr of the hack: the rest of rustdoc expects the id of the item but for diagnostics we need the associated item). - No longer suggests escaping the brackets for every link that failed to resolve; this was pretty obnoxious. Now it only suggests `\[ \]` if no segment resolved and there is no `::` in the link. - Add `Suggestion` which says _what_ to prefix the link with not just 'prefix with the item kind'. Places where this is currently buggy:
All outdated ~~1. When the link has the wrong namespace:~~ Now fixed.
```rust /// [type@S::h] impl S { pub fn h() {} } /// [type@T::g] pub trait T { fn g() {} } ``` ``` error: unresolved link to `T::g` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:53:6 | 53 | /// [type@T::g] | ^^^^^^^^^ | = note: this link partially resolves to the trait `T` = note: `T` has no field variant or associated item named `g` error: unresolved link to `S::h` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:48:6 | 48 | /// [type@S::h] | ^^^^^^^^^ | = note: this link partially resolves to the struct `S` = note: `S` has no field variant or associated item named `h` ``` Instead it should suggest changing the disambiguator the way it currently does for macros: ``` error: unresolved link to `S` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:38:6 | 38 | /// [S!] | ^^ help: to link to the unit struct use its disambiguator: `value@S` | = note: this link resolves to the unit struct `S` which is not in the macro namespace ```
2. ~~Associated items for values. It says that the value isn't in scope; instead it should say that values can't have associated items.~~ Fixed.
``` error: unresolved link to `f::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:14:6 | 14 | /// [f::A] | ^^^^ | = note: no item named `f` is in scope = help: to escape `[` and `]` characters add '\' before them like `\[` or `\]` ``` This is _mostly_ fixed it now says ```rust warning: unresolved link to `f::A` --> /home/joshua/test-rustdoc/f.rs:1:6 | 1 | /// [f::A] | ^^^^ | = note: this link partially resolves to the function `f` = note: `f` is a function not a module ``` 'function not a module' seems awfully terse when what I actually mean is '`::` isn't allowed here' though.
It looks a lot nicer now it says ``` error: unresolved link to `f::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:13:6 | 13 | /// [f::A] | ^^^^ | = note: `f` is a function not a module or type and cannot have associated items ``` 3. ~~I'm also not very happy with the second note for this error:~~
``` error: unresolved link to `S::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:19:6 | 19 | /// [S::A] | ^^^^ | = note: this link partially resolves to the struct `S` = note: `S` has no field variant or associated item named `A` ``` but I'm not sure how better to word it. I ended up going with 'no `A` in `S`' to match `rustc_resolve` but that seems terse as well.
This now says ``` error: unresolved link to `S::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:17:6 | 17 | /// [S::A] | ^^^^ | = note: the struct `S` has no field or associated item named `A` ``` which I think looks pretty good :) 4. This is minor but it would be nice to say that `path` wasn't found instead of the full thing: ``` error: unresolved link to `path::to::nonexistent::module` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:8:6 | 8 | /// [path::to::nonexistent::module] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` It will now look at most 3 paths up (so it reports `path::to` as not in scope) but it doesn't work with arbitrarily many paths.
~~I recommend only reviewing the last few commits - the first 7 are all from #74489.~~ Rebased so that only the relevant commits are shown. Let me know if I should squash the history some more. r? `@estebank`",HEART,2020-08-29T20:17:33Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/75756,MERGED,2020-08-20T23:46:56Z,2020-09-12T07:46:21Z,Improve suggestions for broken intra-doc links,jyn514,0f5c76951327b912c8e92e83235430ebd9b349d9,18,"Auto merge of #75756 - jyn514:diagnostic-suggestions r=estebank Improve suggestions for broken intra-doc links ~~Depends on #74489 and should not be merged before that PR.~~ Merged 🎉 ~~Depends on #75916 and should not be merged before.~~ Merged Fixes https://github.com/rust-lang/rust/issues/75305. This does a lot of different things 😆. - Add `PerNS::into_iter()` so I didn't have to keep rewriting hacks around it. Also add `PerNS::iter()` for consistency. Let me know if this should be `impl IntoIterator` instead. - Make `ResolutionFailure` an enum instead of a unit variant. This was most of the changes: everywhere that said `ErrorKind::ResolutionFailure` now has to say _why_ the link failed to resolve. - Store the resolution in case of an anchor failure. Previously this was implemented as variants on `AnchorFailure` which was prone to typos and had inconsistent output compared to the rest of the diagnostics. - Turn some `Err`ors into unwrap() or panic()s because they're rustdoc bugs and not user error. These have comments as to why they're bugs (in particular this would have caught #76073 as a bug a while ago). - If an item is not in scope at all say the first segment in the path that failed to resolve - If an item exists but not in the current namespaces say that and suggests linking to that namespace. - If there is a partial resolution for an item (part of the segments resolved but not all of them) say the partial resolution and why the following segment didn't resolve. - Add the `DefId` of associated items to `kind_side_channel` so it can be used for diagnostics (tl;dr of the hack: the rest of rustdoc expects the id of the item but for diagnostics we need the associated item). - No longer suggests escaping the brackets for every link that failed to resolve; this was pretty obnoxious. Now it only suggests `\[ \]` if no segment resolved and there is no `::` in the link. - Add `Suggestion` which says _what_ to prefix the link with not just 'prefix with the item kind'. Places where this is currently buggy:
All outdated ~~1. When the link has the wrong namespace:~~ Now fixed.
```rust /// [type@S::h] impl S { pub fn h() {} } /// [type@T::g] pub trait T { fn g() {} } ``` ``` error: unresolved link to `T::g` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:53:6 | 53 | /// [type@T::g] | ^^^^^^^^^ | = note: this link partially resolves to the trait `T` = note: `T` has no field variant or associated item named `g` error: unresolved link to `S::h` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:48:6 | 48 | /// [type@S::h] | ^^^^^^^^^ | = note: this link partially resolves to the struct `S` = note: `S` has no field variant or associated item named `h` ``` Instead it should suggest changing the disambiguator the way it currently does for macros: ``` error: unresolved link to `S` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:38:6 | 38 | /// [S!] | ^^ help: to link to the unit struct use its disambiguator: `value@S` | = note: this link resolves to the unit struct `S` which is not in the macro namespace ```
2. ~~Associated items for values. It says that the value isn't in scope; instead it should say that values can't have associated items.~~ Fixed.
``` error: unresolved link to `f::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:14:6 | 14 | /// [f::A] | ^^^^ | = note: no item named `f` is in scope = help: to escape `[` and `]` characters add '\' before them like `\[` or `\]` ``` This is _mostly_ fixed it now says ```rust warning: unresolved link to `f::A` --> /home/joshua/test-rustdoc/f.rs:1:6 | 1 | /// [f::A] | ^^^^ | = note: this link partially resolves to the function `f` = note: `f` is a function not a module ``` 'function not a module' seems awfully terse when what I actually mean is '`::` isn't allowed here' though.
It looks a lot nicer now it says ``` error: unresolved link to `f::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:13:6 | 13 | /// [f::A] | ^^^^ | = note: `f` is a function not a module or type and cannot have associated items ``` 3. ~~I'm also not very happy with the second note for this error:~~
``` error: unresolved link to `S::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:19:6 | 19 | /// [S::A] | ^^^^ | = note: this link partially resolves to the struct `S` = note: `S` has no field variant or associated item named `A` ``` but I'm not sure how better to word it. I ended up going with 'no `A` in `S`' to match `rustc_resolve` but that seems terse as well.
This now says ``` error: unresolved link to `S::A` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:17:6 | 17 | /// [S::A] | ^^^^ | = note: the struct `S` has no field or associated item named `A` ``` which I think looks pretty good :) 4. This is minor but it would be nice to say that `path` wasn't found instead of the full thing: ``` error: unresolved link to `path::to::nonexistent::module` --> /home/joshua/rustc/src/test/rustdoc-ui/intra-link-errors.rs:8:6 | 8 | /// [path::to::nonexistent::module] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` It will now look at most 3 paths up (so it reports `path::to` as not in scope) but it doesn't work with arbitrarily many paths.
~~I recommend only reviewing the last few commits - the first 7 are all from #74489.~~ Rebased so that only the relevant commits are shown. Let me know if I should squash the history some more. r? `@estebank`",HEART,2020-09-11T16:44:32Z,estebank,NA https://github.com/rust-lang/rust/pull/75771,MERGED,2020-08-21T12:02:22Z,2020-08-22T02:38:13Z,Extend normalization in const-eval-query-stack test,tmiasko,d8262297ad5b9a69f17ba026d7041e50233d1bc1,2,Rollup merge of #75771 - tmiasko:const-eval-query-stack-normalize r=jonas-schievink Extend normalization in const-eval-query-stack test Builds with debuginfo have additional information in backtrace.,THUMBS_UP,2020-08-21T13:52:42Z,ThibsG,NA https://github.com/rust-lang/rust/pull/75771,MERGED,2020-08-21T12:02:22Z,2020-08-22T02:38:13Z,Extend normalization in const-eval-query-stack test,tmiasko,d8262297ad5b9a69f17ba026d7041e50233d1bc1,2,Rollup merge of #75771 - tmiasko:const-eval-query-stack-normalize r=jonas-schievink Extend normalization in const-eval-query-stack test Builds with debuginfo have additional information in backtrace.,THUMBS_UP,2020-08-21T14:38:28Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/75773,MERGED,2020-08-21T12:33:30Z,2020-08-25T11:53:19Z,Introduce expect snapshot testing library into rustc,matklad,c35007dbbe4846c641b5edad9fddf3f72a5a035a,6,Auto merge of #75773 - matklad:snapshot-tests r=Mark-Simulacrum Introduce expect snapshot testing library into rustc Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use `expect_test` provides an `expect!` macro which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer where we use it for most of our tests. There are some other more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so tests can be written as functions rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie no `cargo insta`) See rust-analyzer/rust-analyzer#5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment rustc is mainly tested via integrated UI tests. But in the library-ified world unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high it probably makes sense to just see if this flies!,ROCKET,2020-08-21T12:59:37Z,mati865,NA https://github.com/rust-lang/rust/pull/75773,MERGED,2020-08-21T12:33:30Z,2020-08-25T11:53:19Z,Introduce expect snapshot testing library into rustc,matklad,c35007dbbe4846c641b5edad9fddf3f72a5a035a,6,Auto merge of #75773 - matklad:snapshot-tests r=Mark-Simulacrum Introduce expect snapshot testing library into rustc Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use `expect_test` provides an `expect!` macro which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer where we use it for most of our tests. There are some other more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so tests can be written as functions rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie no `cargo insta`) See rust-analyzer/rust-analyzer#5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment rustc is mainly tested via integrated UI tests. But in the library-ified world unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high it probably makes sense to just see if this flies!,ROCKET,2020-08-24T21:40:21Z,yerke,NA https://github.com/rust-lang/rust/pull/75776,MERGED,2020-08-21T16:07:20Z,2020-08-22T08:54:32Z,Missing doc examples lint improvements,GuillaumeGomez,b1bb8aa3ff3bf3040d9973edeb96b8c9ebf81d31,4,Auto merge of #75776 - GuillaumeGomez:missing-doc-examples-lint-improvements r=jyn514 Missing doc examples lint improvements Fixes #75719. To be merged after #75718 (only the two last commits are from this PR). Since you already reviewed #75718 I'll set you as reviewer here as well. :) r? @jyn514,LAUGH,2020-08-21T16:12:01Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75780,MERGED,2020-08-21T17:52:00Z,2020-08-27T02:51:30Z,Unconfuse Unpin docs a bit,matklad,a79f9af290ad69cd4fb32a3e1b5e610a21262717,1,Rollup merge of #75780 - matklad:unconfuseunpindocs r=KodrAus Unconfuse Unpin docs a bit * Don't say that Unpin is used to prevent moves because it is used to *allow* moves * Be more precise about kindedness of things it is `Pin>` rather than just `Pin`.,THUMBS_UP,2020-08-22T01:22:36Z,rw,NA https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-08-21T20:24:01Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-08-21T21:06:41Z,iulianR,iulian.radu67@gmail.com https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-08-22T00:16:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-08-22T07:00:04Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-09-05T14:58:20Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/75784,CLOSED,2020-08-21T19:58:39Z,2020-10-30T20:20:54Z,Add Iterator::intersperse,jonas-schievink,NA,NA,NA,HEART,2020-09-12T07:33:16Z,Pratyush,NA https://github.com/rust-lang/rust/pull/75800,MERGED,2020-08-22T02:33:03Z,2020-09-11T04:51:32Z,Attach tokens to all AST types used in `Nonterminal`,Aaron1011,94b4de0e0793c8921d30e0fb886be712d17db6e5,50,Auto merge of #75800 - Aaron1011:feature/full-nt-tokens r=petrochenkov Attach tokens to all AST types used in `Nonterminal` We perform token capturing when we have outer attributes (for nonterminals that support attributes - e.g. `Stmt`) or when we parse a `Nonterminal` for a `macro_rules!` argument. The full list of `Nonterminals` affected by this PR is: * `NtBlock` * `NtStmt` * `NtTy` * `NtMeta` * `NtPath` * `NtVis` * `NtLiteral` Of these nonterminals only `NtStmt` and `NtLiteral` (which is actually just an `Expr`) support outer attributes - the rest only ever have token capturing perform when they match a `macro_rules!` argument. This makes progress towards solving https://github.com/rust-lang/rust/issues/43081 - we now collect tokens for everything that might need them. However we still need to handle `#[cfg]` inner attributes and misc pretty-printing issues (e.g. #75734) I've separated the changes into (mostly) independent commits which could be split into individual PRs for each `Nonterminal` variant. The purpose of having them all in one PR is to do a single Crater run for all of them. Most of the changes in this PR are trivial (adding `tokens: None` everywhere we construct the various AST structs). The significant changes are: * `ast::Visibility` is changed from `type Visibility = Spanned` to a `struct Visibility { kind span tokens }`. * `maybe_collect_tokens` is made generic and used for both `ast::Expr` and `ast::Stmt`. * Some of the statement-parsing functions are refactored so that we can capture the trailing semicolon. * `Nonterminal` and `Expr` both grew by 8 bytes as some of the structs which are stored inline (rather than behind a `P`) now have an `Option` field. Hopefully the performance impact of doing this is negligible.,HOORAY,2020-08-24T16:54:09Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/75813,MERGED,2020-08-22T18:26:28Z,2020-08-23T08:14:22Z,Lazy decoding of DefPathTable from crate metadata (non-incremental case),petrochenkov,d5abc8d3b2e14c8793182b427520497a90b6de83,10,Auto merge of #75813 - petrochenkov:feature/incr-def-path-table r=Aaron1011 Lazy decoding of DefPathTable from crate metadata (non-incremental case) The is the half of https://github.com/rust-lang/rust/pull/74967 that doesn't touch incremental-related structures. We are still decoding def path hashes eagerly if we are in incremental mode. The incremental part of https://github.com/rust-lang/rust/pull/74967 feels hacky but I'm not qualified enough to suggest improvements. I'll reassign it so someone else once this PR lands. @Aaron1011 I wasn't asking you to do this split because I wasn't sure that it's feasible (or simple to do). r? @Aaron1011,HOORAY,2020-08-23T04:30:18Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/75828,CLOSED,2020-08-23T06:51:19Z,2020-08-27T21:40:18Z,[Draft] Tools and tests to experimentally add more counters per function,richkadel,NA,NA,NA,HEART,2020-08-24T07:45:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/75828,CLOSED,2020-08-23T06:51:19Z,2020-08-27T21:40:18Z,[Draft] Tools and tests to experimentally add more counters per function,richkadel,NA,NA,NA,HEART,2020-08-24T11:17:26Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/75828,CLOSED,2020-08-23T06:51:19Z,2020-08-27T21:40:18Z,[Draft] Tools and tests to experimentally add more counters per function,richkadel,NA,NA,NA,HEART,2020-08-24T16:02:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/75828,CLOSED,2020-08-23T06:51:19Z,2020-08-27T21:40:18Z,[Draft] Tools and tests to experimentally add more counters per function,richkadel,NA,NA,NA,HEART,2020-08-27T01:44:14Z,tmandry,NA https://github.com/rust-lang/rust/pull/75844,MERGED,2020-08-23T18:31:58Z,2020-08-24T06:05:04Z,publish-toolstate: show more context on HTTP error,ehuss,d6de9616a16fa5c078836fb0b39173a1d0cc9d58,1,Rollup merge of #75844 - ehuss:publish-toolstate-httperror r=Mark-Simulacrum publish-toolstate: show more context on HTTP error The default display for HTTPError in Python does not include the request body. For GitHub API the body includes more details about the error (like rate limiting). This could help diagnosing errors like this: https://github.com/rust-lang/rust/pull/75815#issuecomment-678798158,HEART,2020-08-23T18:33:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/75857,MERGED,2020-08-23T23:11:15Z,2020-09-10T21:26:49Z,Syntactically permit unsafety on mods,dtolnay,5aed4957ff893823d353fe3f1d2e4a80ebe35007,17,"Rollup merge of #75857 - dtolnay:unsafe r=nagisa Syntactically permit unsafety on mods Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust. ```rust #[mymacro] unsafe mod m { ... } #[mymacro] unsafe extern ""C++"" { ... } ``` The intention is that this might be used as a kind of ""item-level unsafe"" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx. In the absence of a procedural macro rewriting them to something else they'll continue to be rejected at compile time though with a better error message than before. ### Before: ```console error: expected item found keyword `unsafe` --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ expected item ``` ### After: ```console error: module cannot be declared unsafe --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ error: extern block cannot be declared unsafe --> src/main.rs:4:1 | 4 | unsafe extern ""C++"" { | ^^^^^^ ``` Closes #68048.",THUMBS_UP,2020-09-11T21:32:13Z,estebank,NA https://github.com/rust-lang/rust/pull/75857,MERGED,2020-08-23T23:11:15Z,2020-09-10T21:26:49Z,Syntactically permit unsafety on mods,dtolnay,5aed4957ff893823d353fe3f1d2e4a80ebe35007,17,"Rollup merge of #75857 - dtolnay:unsafe r=nagisa Syntactically permit unsafety on mods Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust. ```rust #[mymacro] unsafe mod m { ... } #[mymacro] unsafe extern ""C++"" { ... } ``` The intention is that this might be used as a kind of ""item-level unsafe"" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx. In the absence of a procedural macro rewriting them to something else they'll continue to be rejected at compile time though with a better error message than before. ### Before: ```console error: expected item found keyword `unsafe` --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ expected item ``` ### After: ```console error: module cannot be declared unsafe --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ error: extern block cannot be declared unsafe --> src/main.rs:4:1 | 4 | unsafe extern ""C++"" { | ^^^^^^ ``` Closes #68048.",THUMBS_UP,2020-11-17T09:45:57Z,iago-lito,NA https://github.com/rust-lang/rust/pull/75857,MERGED,2020-08-23T23:11:15Z,2020-09-10T21:26:49Z,Syntactically permit unsafety on mods,dtolnay,5aed4957ff893823d353fe3f1d2e4a80ebe35007,17,"Rollup merge of #75857 - dtolnay:unsafe r=nagisa Syntactically permit unsafety on mods Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust. ```rust #[mymacro] unsafe mod m { ... } #[mymacro] unsafe extern ""C++"" { ... } ``` The intention is that this might be used as a kind of ""item-level unsafe"" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx. In the absence of a procedural macro rewriting them to something else they'll continue to be rejected at compile time though with a better error message than before. ### Before: ```console error: expected item found keyword `unsafe` --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ expected item ``` ### After: ```console error: module cannot be declared unsafe --> src/main.rs:1:1 | 1 | unsafe mod m { | ^^^^^^ error: extern block cannot be declared unsafe --> src/main.rs:4:1 | 4 | unsafe extern ""C++"" { | ^^^^^^ ``` Closes #68048.",THUMBS_UP,2020-12-25T17:53:33Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/75859,MERGED,2020-08-23T23:40:08Z,2020-08-24T06:04:59Z,doc: Fix typo in std::process::Child documentation,jrheard,47a03d9815d7099a7555323d62a4cec7ba05dad6,1,Rollup merge of #75859 - jrheard:patch-2 r=jonas-schievink doc: Fix typo in std::process::Child documentation Nearly done reading stdlib docs found another small typo here's a PR! r? @steveklabnik,THUMBS_UP,2020-08-24T00:50:37Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/75863,CLOSED,2020-08-24T01:48:54Z,2020-09-02T10:38:29Z,impl Add for Option,zcesur,NA,NA,NA,EYES,2020-08-24T10:25:51Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75863,CLOSED,2020-08-24T01:48:54Z,2020-09-02T10:38:29Z,impl Add for Option,zcesur,NA,NA,NA,THUMBS_DOWN,2020-09-01T04:10:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/75866,CLOSED,2020-08-24T03:13:11Z,2020-12-10T02:44:25Z,"Resurrect #70477: ""Use the niche optimization if other variant are small enough""",erikdesjardins,NA,NA,NA,ROCKET,2020-08-24T10:30:40Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/75866,CLOSED,2020-08-24T03:13:11Z,2020-12-10T02:44:25Z,"Resurrect #70477: ""Use the niche optimization if other variant are small enough""",erikdesjardins,NA,NA,NA,ROCKET,2020-08-24T16:18:09Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/75866,CLOSED,2020-08-24T03:13:11Z,2020-12-10T02:44:25Z,"Resurrect #70477: ""Use the niche optimization if other variant are small enough""",erikdesjardins,NA,NA,NA,ROCKET,2020-09-08T00:36:41Z,SkylerLipthay,sl@skylerlipthay.com https://github.com/rust-lang/rust/pull/75870,MERGED,2020-08-24T08:41:25Z,2020-08-27T02:51:21Z,Unify theme choices border color in ayu theme,GuillaumeGomez,c1cb46e9064d3d34ed27bc7b8ffe7d3082f21fd3,1,Rollup merge of #75870 - GuillaumeGomez:unify-border-color-theme-ayu r=pickfire Unify theme choices border color in ayu theme There was a slight color difference in the theme choice menu borders: ![Screenshot from 2020-08-24 10-37-05](https://user-images.githubusercontent.com/3050060/91022913-22654880-e5f6-11ea-8165-302b2d4e701e.png) ![Screenshot from 2020-08-24 10-37-58](https://user-images.githubusercontent.com/3050060/91022918-242f0c00-e5f6-11ea-989a-e26a28196d09.png) r? @Cldfire,THUMBS_UP,2020-08-24T12:48:28Z,Cldfire,NA https://github.com/rust-lang/rust/pull/75877,MERGED,2020-08-24T13:48:01Z,2020-08-29T03:37:15Z,Update compiler-builtins,vigoux,360a372f2ca809a844915b2d80299d96cf90ae9a,2,Auto merge of #75877 - vigoux:master r=Amanieu Update compiler-builtins Update the compiler-builtins dependency to include latest changes. This allows for `aarch64-unknown-linux-musl` to pass all tests. Fixes #57820 and fixes #46651,THUMBS_UP,2020-08-24T17:01:54Z,casept,davids.paskevics@gmail.com https://github.com/rust-lang/rust/pull/75886,MERGED,2020-08-24T17:22:26Z,2020-09-16T03:07:28Z,Test that bounds checks are elided for [..index] after .position(),erikdesjardins,056c7b09ff6485051fd883988b1e729c3500dc42,1,Rollup merge of #75886 - erikdesjardins:index r=nikic Test that bounds checks are elided for [..index] after .position() Closes #73396. This was fixed by the LLVM 11 update in #73526.,HEART,2020-08-24T18:27:23Z,scottmcm,NA https://github.com/rust-lang/rust/pull/75886,MERGED,2020-08-24T17:22:26Z,2020-09-16T03:07:28Z,Test that bounds checks are elided for [..index] after .position(),erikdesjardins,056c7b09ff6485051fd883988b1e729c3500dc42,1,Rollup merge of #75886 - erikdesjardins:index r=nikic Test that bounds checks are elided for [..index] after .position() Closes #73396. This was fixed by the LLVM 11 update in #73526.,HEART,2020-08-24T23:21:58Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/75886,MERGED,2020-08-24T17:22:26Z,2020-09-16T03:07:28Z,Test that bounds checks are elided for [..index] after .position(),erikdesjardins,056c7b09ff6485051fd883988b1e729c3500dc42,1,Rollup merge of #75886 - erikdesjardins:index r=nikic Test that bounds checks are elided for [..index] after .position() Closes #73396. This was fixed by the LLVM 11 update in #73526.,HEART,2020-08-25T01:49:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/75894,CLOSED,2020-08-25T02:25:35Z,2020-09-29T01:52:48Z,Use `str::to_owned` when `format!` has no formatting arguments,tesuji,NA,NA,NA,HOORAY,2020-09-09T22:01:07Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/75911,CLOSED,2020-08-25T16:12:10Z,2020-11-01T15:57:35Z,Add `Arc::unwrap_or_drop` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2020-09-02T15:14:27Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/75911,CLOSED,2020-08-25T16:12:10Z,2020-11-01T15:57:35Z,Add `Arc::unwrap_or_drop` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2020-10-22T17:00:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/75911,CLOSED,2020-08-25T16:12:10Z,2020-11-01T15:57:35Z,Add `Arc::unwrap_or_drop` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2021-03-08T21:45:38Z,stevenengler,NA https://github.com/rust-lang/rust/pull/75914,MERGED,2020-08-25T17:46:03Z,2020-10-12T12:14:26Z,Promote aarch64-pc-windows-msvc to Tier 2 Development Platform,arlosi,d9b931669b9c480b60f0abcaa7834758ba8761a2,4,Auto merge of #75914 - arlosi:aarch64-ci r=pietroalbini Promote aarch64-pc-windows-msvc to Tier 2 Development Platform Adds a GitHub Actions CI build for `aarch64-pc-windows-msvc` via cross-compilation on an x86_64 host. This promotes `aarch64-pc-windows-msvc` from a Tier 2 Compilation Target (std) to a Tier 2 Development Platform (std+rustc+cargo+tools). Fixes #72881 r? `@pietroalbini`,THUMBS_UP,2020-09-02T09:14:47Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/75914,MERGED,2020-08-25T17:46:03Z,2020-10-12T12:14:26Z,Promote aarch64-pc-windows-msvc to Tier 2 Development Platform,arlosi,d9b931669b9c480b60f0abcaa7834758ba8761a2,4,Auto merge of #75914 - arlosi:aarch64-ci r=pietroalbini Promote aarch64-pc-windows-msvc to Tier 2 Development Platform Adds a GitHub Actions CI build for `aarch64-pc-windows-msvc` via cross-compilation on an x86_64 host. This promotes `aarch64-pc-windows-msvc` from a Tier 2 Compilation Target (std) to a Tier 2 Development Platform (std+rustc+cargo+tools). Fixes #72881 r? `@pietroalbini`,THUMBS_UP,2020-10-02T21:56:54Z,Alovchin91,NA https://github.com/rust-lang/rust/pull/75914,MERGED,2020-08-25T17:46:03Z,2020-10-12T12:14:26Z,Promote aarch64-pc-windows-msvc to Tier 2 Development Platform,arlosi,d9b931669b9c480b60f0abcaa7834758ba8761a2,4,Auto merge of #75914 - arlosi:aarch64-ci r=pietroalbini Promote aarch64-pc-windows-msvc to Tier 2 Development Platform Adds a GitHub Actions CI build for `aarch64-pc-windows-msvc` via cross-compilation on an x86_64 host. This promotes `aarch64-pc-windows-msvc` from a Tier 2 Compilation Target (std) to a Tier 2 Development Platform (std+rustc+cargo+tools). Fixes #72881 r? `@pietroalbini`,THUMBS_UP,2020-10-05T13:25:46Z,Stammark,NA https://github.com/rust-lang/rust/pull/75931,MERGED,2020-08-26T03:29:02Z,2020-09-01T02:09:37Z,Suggest `if let x = y` when encountering `if x = y`,estebank,d824b2351449714dc685d90e298c9d630ad6c437,11,Auto merge of #75931 - estebank:suggest-if-let r=petrochenkov Suggest `if let x = y` when encountering `if x = y` Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.,HEART,2020-08-27T05:55:04Z,arora-aman,NA https://github.com/rust-lang/rust/pull/75931,MERGED,2020-08-26T03:29:02Z,2020-09-01T02:09:37Z,Suggest `if let x = y` when encountering `if x = y`,estebank,d824b2351449714dc685d90e298c9d630ad6c437,11,Auto merge of #75931 - estebank:suggest-if-let r=petrochenkov Suggest `if let x = y` when encountering `if x = y` Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.,HEART,2020-09-10T04:20:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/75931,MERGED,2020-08-26T03:29:02Z,2020-09-01T02:09:37Z,Suggest `if let x = y` when encountering `if x = y`,estebank,d824b2351449714dc685d90e298c9d630ad6c437,11,Auto merge of #75931 - estebank:suggest-if-let r=petrochenkov Suggest `if let x = y` when encountering `if x = y` Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.,HEART,2020-09-11T11:25:52Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/75931,MERGED,2020-08-26T03:29:02Z,2020-09-01T02:09:37Z,Suggest `if let x = y` when encountering `if x = y`,estebank,d824b2351449714dc685d90e298c9d630ad6c437,11,Auto merge of #75931 - estebank:suggest-if-let r=petrochenkov Suggest `if let x = y` when encountering `if x = y` Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.,HEART,2020-09-11T20:07:54Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/75933,MERGED,2020-08-26T06:11:27Z,2020-08-27T19:59:59Z,Point to a move-related span when pointing to closure upvars,Aaron1011,132f5fc2e5247cf5dab74e5a4408135056852c30,12,Auto merge of #75933 - Aaron1011:feature/closure-move-err r=oli-obk Point to a move-related span when pointing to closure upvars Fixes #75904 When emitting move/borrow errors we may point into a closure to indicate why an upvar is used in the closure. However we use the 'upvar span' which is just an arbitrary usage of the upvar. If the upvar is used in multiple places (e.g. a borrow and a move) we may end up pointing to the borrow. If the overall error is a move error this can be confusing. This PR tracks the span that caused an upvar to become captured by-value instead of by-ref (assuming that it's not a `move` closure). We use this span instead of the 'upvar' span when we need to point to an upvar usage during borrow checking.,HEART,2020-08-27T10:47:54Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/75933,MERGED,2020-08-26T06:11:27Z,2020-08-27T19:59:59Z,Point to a move-related span when pointing to closure upvars,Aaron1011,132f5fc2e5247cf5dab74e5a4408135056852c30,12,Auto merge of #75933 - Aaron1011:feature/closure-move-err r=oli-obk Point to a move-related span when pointing to closure upvars Fixes #75904 When emitting move/borrow errors we may point into a closure to indicate why an upvar is used in the closure. However we use the 'upvar span' which is just an arbitrary usage of the upvar. If the upvar is used in multiple places (e.g. a borrow and a move) we may end up pointing to the borrow. If the overall error is a move error this can be confusing. This PR tracks the span that caused an upvar to become captured by-value instead of by-ref (assuming that it's not a `move` closure). We use this span instead of the 'upvar' span when we need to point to an upvar usage during borrow checking.,HEART,2021-04-27T22:13:41Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/75943,MERGED,2020-08-26T14:06:47Z,2020-08-28T12:22:41Z,Fix potential UB in align_offset doc examples,elichai,be1b304ea4dec58255d76eca98442270ef17578a,2,Rollup merge of #75943 - elichai:2020-align_offset-docs r=RalfJung Fix potential UB in align_offset doc examples Currently it takes a pointer only to the first element in the array this changes the code to take a pointer to the whole array. miri can't catch this right now because it later calls `x.len()` which re-tags the pointer for the whole array. https://github.com/rust-lang/miri/issues/1526#issuecomment-680897144,THUMBS_UP,2020-08-26T22:36:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/75947,MERGED,2020-08-26T16:07:14Z,2020-08-27T11:36:55Z,Bump version to 1.48 and update cfg(bootstrap)s,pietroalbini,118860a7e76daaac3564c7655d46ac65a14fc612,17,Auto merge of #75947 - pietroalbini:bootstrap-update r=Mark-Simulacrum Bump version to 1.48 and update cfg(bootstrap)s r? @Mark-Simulacrum,HOORAY,2020-08-26T20:22:44Z,camelid,NA https://github.com/rust-lang/rust/pull/75972,MERGED,2020-08-27T03:26:24Z,2020-08-28T12:22:35Z,Fix ICE due to carriage return w/ multibyte char,JulianKnodt,cd77b62174432003d7637518de903b27735ec520,3,Rollup merge of #75972 - JulianKnodt:i70381 r=rollup Fix ICE due to carriage return w/ multibyte char Based off of this [commit](https://github.com/kfitch/rust/commit/972560b83f80e1219b5735ff3d751c034115b08e) Fixes #70381 CC: @Dylan-DPC,HEART,2020-08-27T17:01:34Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/75984,MERGED,2020-08-27T14:00:00Z,2020-09-10T00:11:36Z,Improve unresolved use error message,kornelski,5ea55518bcd168517d7e5b526e94e0d09470cb11,52,"Rollup merge of #75984 - kornelski:typeormodule r=matthewjasper Improve unresolved use error message ""use of undeclared type or module `foo`"" doesn't mention that it could be a crate. This error can happen when users forget to add a dependency to `Cargo.toml` so I think it's important to mention that it could be a missing crate. I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.",THUMBS_UP,2020-08-27T16:41:26Z,estebank,NA https://github.com/rust-lang/rust/pull/75984,MERGED,2020-08-27T14:00:00Z,2020-09-10T00:11:36Z,Improve unresolved use error message,kornelski,5ea55518bcd168517d7e5b526e94e0d09470cb11,52,"Rollup merge of #75984 - kornelski:typeormodule r=matthewjasper Improve unresolved use error message ""use of undeclared type or module `foo`"" doesn't mention that it could be a crate. This error can happen when users forget to add a dependency to `Cargo.toml` so I think it's important to mention that it could be a missing crate. I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.",THUMBS_UP,2020-08-29T08:33:49Z,marmeladema,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,HOORAY,2020-10-14T18:33:13Z,stuartcarnie,stuart.carnie@gmail.com https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,ROCKET,2020-10-19T15:57:11Z,igxactly,igxactly@gmail.com https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,HOORAY,2020-11-18T15:09:47Z,punkeel,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,ROCKET,2021-01-12T18:30:15Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,HOORAY,2021-01-12T18:30:15Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,ROCKET,2021-02-09T19:18:08Z,timleg002,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,HOORAY,2021-02-09T19:18:09Z,timleg002,NA https://github.com/rust-lang/rust/pull/75991,MERGED,2020-08-27T18:02:22Z,2020-10-12T02:21:36Z,Set up CI for aarch64-apple-darwin,shepmaster,576e2277acda16dff6293b5c180e7851e6b17d5c,5,Auto merge of #75991 - shepmaster:silicon-ci r=pietroalbini Set up CI for aarch64-apple-darwin,HOORAY,2021-03-08T10:23:23Z,zlliang,zlliang96@outlook.com https://github.com/rust-lang/rust/pull/76000,MERGED,2020-08-27T19:31:47Z,2020-08-28T12:22:29Z,Adds --bless support to test/run-make-fulldeps,richkadel,0106ad4e27389671bbf411ab6cdf8faa926ce0ae,1,"Rollup merge of #76000 - richkadel:llvm-coverage-map-gen-6b.2 r=wesleywiser Adds --bless support to test/run-make-fulldeps The ability to ""bless"" output for some of these tests is critical to making it practical to adapt tests to unrelated changes. This is needed for new coverage tests as shown in PR #76004 . r? @tmandry FYI: @wesleywiser",THUMBS_UP,2020-08-28T00:44:13Z,tmandry,NA https://github.com/rust-lang/rust/pull/76015,MERGED,2020-08-28T06:34:25Z,2020-08-30T02:36:38Z,Fix loading pretty-printers in rust-lldb script,ortem,063313bca632aef60e3482749ed6c00d46933917,3,Rollup merge of #76015 - ortem:fix-lldb-script r=Mark-Simulacrum Fix loading pretty-printers in rust-lldb script Pretty-printers loading in `rust-lldb` script was broken in https://github.com/rust-lang/rust/pull/72357 This fixes https://github.com/rust-lang/rust/issues/76006,HEART,2020-08-29T10:44:38Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76017,MERGED,2020-08-28T08:16:14Z,2020-10-04T04:34:38Z,Use less divisions in display u128/i128,JulianKnodt,4cf3dc19a1e59ffdebe3d8ca106e5b7f2d6d212e,2,Auto merge of #76017 - JulianKnodt:fmt_fast r=nagisa Use less divisions in display u128/i128 This PR is an absolute mess and I need to test if it improves the speed of fmt::Display for u128/i128 but I think it's correct. It hopefully is more efficient by cutting u128 into at most 2 u64s and also chunks by 1e16 instead of just 1e4. Also I specialized the implementations for uints to always be non-false because it bothered me that it was checked at all Do not merge until I benchmark it and also clean up the god awful mess of spaghetti. Based on prior work in #44583 cc: `@Dylan-DPC` Due to work on `itoa` and suggestion in original issue: r? `@dtolnay`,HEART,2020-08-28T19:56:00Z,Dylan-DPC-zz,NA https://github.com/rust-lang/rust/pull/76027,MERGED,2020-08-28T14:11:13Z,2020-08-31T07:17:49Z,ty: remove obsolete pretty printer,davidtwco,8ed5cb56b5e5cc216eb6820a44dd4f7ef65107b0,44,Auto merge of #76027 - davidtwco:issue-61139-remove-obsolete-pretty-printer r=eddyb ty: remove obsolete pretty printer Fixes #61139. This PR removes the obsolete printer and replaces all uses of it with `FmtPrinter`. Of the replaced uses all but one use was in `debug!` logging two cases were notable: - `MonoItem::to_string` is used in `-Z print-mono-items` and therefore affects the output of all codegen-units tests (which have been updated). - `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs` with `LLVMStructCreateNamed` and that'll now get different values but nothing will break as a result of this. cc @eddyb (whom I've discussed this with),HEART,2020-08-28T15:58:06Z,panaman67,NA https://github.com/rust-lang/rust/pull/76027,MERGED,2020-08-28T14:11:13Z,2020-08-31T07:17:49Z,ty: remove obsolete pretty printer,davidtwco,8ed5cb56b5e5cc216eb6820a44dd4f7ef65107b0,44,Auto merge of #76027 - davidtwco:issue-61139-remove-obsolete-pretty-printer r=eddyb ty: remove obsolete pretty printer Fixes #61139. This PR removes the obsolete printer and replaces all uses of it with `FmtPrinter`. Of the replaced uses all but one use was in `debug!` logging two cases were notable: - `MonoItem::to_string` is used in `-Z print-mono-items` and therefore affects the output of all codegen-units tests (which have been updated). - `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs` with `LLVMStructCreateNamed` and that'll now get different values but nothing will break as a result of this. cc @eddyb (whom I've discussed this with),HEART,2020-08-28T18:17:10Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76028,MERGED,2020-08-28T15:05:41Z,2020-09-17T06:06:43Z,Improve E0118,aticu,95386b656e91168bf53e2ab63c6b992cae591fe7,7,"Auto merge of #76028 - aticu:improve_e0118 r=estebank jyn514 GuillaumeGomez Improve E0118 - Changes the ""base type"" terminology to ""nominal type"" (according to the [reference](https://doc.rust-lang.org/stable/reference/items/implementations.html#inherent-implementations)). - Suggests removing a reference if one is present on the type. - Clarify what is meant by a ""nominal type"". closes #69392 This is my first not-entirely-trivial PR so please let me know if I missed anything or if something could be improved. Though I probably won't be able to fix anything in the upcoming week.",THUMBS_UP,2020-08-29T06:14:21Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/76028,MERGED,2020-08-28T15:05:41Z,2020-09-17T06:06:43Z,Improve E0118,aticu,95386b656e91168bf53e2ab63c6b992cae591fe7,7,"Auto merge of #76028 - aticu:improve_e0118 r=estebank jyn514 GuillaumeGomez Improve E0118 - Changes the ""base type"" terminology to ""nominal type"" (according to the [reference](https://doc.rust-lang.org/stable/reference/items/implementations.html#inherent-implementations)). - Suggests removing a reference if one is present on the type. - Clarify what is meant by a ""nominal type"". closes #69392 This is my first not-entirely-trivial PR so please let me know if I missed anything or if something could be improved. Though I probably won't be able to fix anything in the upcoming week.",THUMBS_UP,2020-09-16T22:03:26Z,estebank,NA https://github.com/rust-lang/rust/pull/76030,MERGED,2020-08-28T15:31:21Z,2020-08-31T20:03:54Z,cg_llvm: `fewer_names` in `uncached_llvm_type`,davidtwco,1d22f75c9f75cad2e408a145861904898ac982dd,1,Auto merge of #76030 - davidtwco:fewer-names-llvm-type-of r=eddyb cg_llvm: `fewer_names` in `uncached_llvm_type` This PR changes `uncached_llvm_type` so that a named struct type (with an empty name) is always created when the `fewer_names` option is enabled. By skipping the generation of names we can improve perf. Giving `LLVMStructCreateNamed` an empty name works because LLVM will perform random renames to avoid collisions. Needs a perf run! cc @eddyb (whom I've discussed this with),ROCKET,2020-08-28T18:27:29Z,mati865,NA https://github.com/rust-lang/rust/pull/76030,MERGED,2020-08-28T15:31:21Z,2020-08-31T20:03:54Z,cg_llvm: `fewer_names` in `uncached_llvm_type`,davidtwco,1d22f75c9f75cad2e408a145861904898ac982dd,1,Auto merge of #76030 - davidtwco:fewer-names-llvm-type-of r=eddyb cg_llvm: `fewer_names` in `uncached_llvm_type` This PR changes `uncached_llvm_type` so that a named struct type (with an empty name) is always created when the `fewer_names` option is enabled. By skipping the generation of names we can improve perf. Giving `LLVMStructCreateNamed` an empty name works because LLVM will perform random renames to avoid collisions. Needs a perf run! cc @eddyb (whom I've discussed this with),ROCKET,2020-08-28T20:29:38Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76030,MERGED,2020-08-28T15:31:21Z,2020-08-31T20:03:54Z,cg_llvm: `fewer_names` in `uncached_llvm_type`,davidtwco,1d22f75c9f75cad2e408a145861904898ac982dd,1,Auto merge of #76030 - davidtwco:fewer-names-llvm-type-of r=eddyb cg_llvm: `fewer_names` in `uncached_llvm_type` This PR changes `uncached_llvm_type` so that a named struct type (with an empty name) is always created when the `fewer_names` option is enabled. By skipping the generation of names we can improve perf. Giving `LLVMStructCreateNamed` an empty name works because LLVM will perform random renames to avoid collisions. Needs a perf run! cc @eddyb (whom I've discussed this with),ROCKET,2020-11-19T17:52:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/76041,CLOSED,2020-08-28T20:18:58Z,2020-11-22T09:27:39Z,impl ops::Try for Ordering,calebsander,NA,NA,NA,THUMBS_UP,2020-09-02T21:05:02Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/76043,CLOSED,2020-08-28T21:58:17Z,2020-12-19T20:49:02Z,Provide appropriate types in turbofish suggestions,estebank,NA,NA,NA,HEART,2020-08-29T06:46:54Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/76043,CLOSED,2020-08-28T21:58:17Z,2020-12-19T20:49:02Z,Provide appropriate types in turbofish suggestions,estebank,NA,NA,NA,HEART,2020-12-18T03:33:32Z,camelid,NA https://github.com/rust-lang/rust/pull/76044,MERGED,2020-08-28T23:31:29Z,2020-09-07T23:43:28Z,Support dataflow problems on arbitrary lattices,ecstatic-morse,0e2c1281e909ca38479b97962fc9248f75d66412,23,"Auto merge of #76044 - ecstatic-morse:dataflow-lattice r=oli-obk Support dataflow problems on arbitrary lattices This PR implements last of the proposed extensions I mentioned in the design meeting for the original dataflow refactor. It extends the current dataflow framework to work with arbitrary lattices not just `BitSet`s. This is a prerequisite for dataflow-enabled MIR const-propagation. Personally I am skeptical of the usefulness of doing const-propagation pre-monomorphization since many useful constants only become known after monomorphization (e.g. `size_of::()`) and users have a natural tendency to hand-optimize the rest. It's probably worth exprimenting with however and others have shown interest cc `@rust-lang/wg-mir-opt.` The `Idx` associated type is moved from `AnalysisDomain` to `GenKillAnalysis` and replaced with an associated `Domain` type that must implement `JoinSemiLattice`. Like before each `Analysis` defines the ""bottom value"" for its domain but can no longer override the dataflow join operator. Analyses that want to use set intersection must now use the `lattice::Dual` newtype. `GenKillAnalysis` impls have an additional requirement that `Self::Domain: BorrowMut>` which effectively means that they must use `BitSet` or `lattice::Dual>` as their domain. Most of these changes were mechanical. However because a `Domain` is no longer always a powerset of some index type we can no longer use an `IndexVec>>` to store cached block transfer functions. Instead we use a boxed `dyn Fn` trait object. I discuss a few alternatives to the current approach in a commit message. The majority of new lines of code are to preserve existing Graphviz diagrams for those unlucky enough to have to debug dataflow analyses. I find these diagrams incredibly useful when things are going wrong and considered regressing them unacceptable especially the pretty-printing of `MovePathIndex`s which are used in many dataflow analyses. This required a parallel `fmt` trait used only for printing dataflow domains as well as a refactoring of the `graphviz` module now that we cannot expect the domain to be a `BitSet`. Some features did have to be removed such as the gen/kill display mode (which I didn't use but existed to mirror the output of the old dataflow framework) and line wrapping. Since I had to rewrite much of it anyway I took the opportunity to switch to a `Visitor` for printing dataflow state diffs instead of using cursors which are error prone for code that must be generic over both forward and backward analyses. As a side-effect of this change we no longer have quadratic behavior when writing graphviz diagrams for backward dataflow analyses. r? `@pnkfelix`",HEART,2020-08-30T09:00:38Z,felix91gr,NA https://github.com/rust-lang/rust/pull/76047,MERGED,2020-08-29T01:07:18Z,2020-09-01T07:26:40Z,rename get_{ref mut} to assume_init_{ref mut} in Maybeuninit,Dylan-DPC-zz,d9cd4a33f53689bc0847775669a14f666a138fd7,4,Auto merge of #76047 - Dylan-DPC:rename/maybe r=RalfJung rename get_{ref mut} to assume_init_{ref mut} in Maybeuninit References #63568 Rework with comments addressed from #66174 Have replaced most of the occurrences I've found hopefully didn't miss out anything r? @RalfJung (thanks @danielhenrymantilla for the initial work on this),HEART,2020-08-29T17:40:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76047,MERGED,2020-08-29T01:07:18Z,2020-09-01T07:26:40Z,rename get_{ref mut} to assume_init_{ref mut} in Maybeuninit,Dylan-DPC-zz,d9cd4a33f53689bc0847775669a14f666a138fd7,4,Auto merge of #76047 - Dylan-DPC:rename/maybe r=RalfJung rename get_{ref mut} to assume_init_{ref mut} in Maybeuninit References #63568 Rework with comments addressed from #66174 Have replaced most of the occurrences I've found hopefully didn't miss out anything r? @RalfJung (thanks @danielhenrymantilla for the initial work on this),THUMBS_UP,2020-08-30T09:30:29Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/76048,MERGED,2020-08-29T02:28:06Z,2020-09-16T03:07:23Z,Initial support for riscv32gc_unknown_linux_gnu,alistair23,db228987ac3ff97cf243bca20213179a4127e649,3,Rollup merge of #76048 - alistair23:alistair/rv32-linux r=Amanieu Initial support for riscv32gc_unknown_linux_gnu Now that RISC-V 32-bit (RV32) support is in upstream glibc let's add support for userspace Rust.,THUMBS_UP,2020-09-15T08:39:40Z,denisvasilik,contact@denisvasilik.com https://github.com/rust-lang/rust/pull/76048,MERGED,2020-08-29T02:28:06Z,2020-09-16T03:07:23Z,Initial support for riscv32gc_unknown_linux_gnu,alistair23,db228987ac3ff97cf243bca20213179a4127e649,3,Rollup merge of #76048 - alistair23:alistair/rv32-linux r=Amanieu Initial support for riscv32gc_unknown_linux_gnu Now that RISC-V 32-bit (RV32) support is in upstream glibc let's add support for userspace Rust.,THUMBS_UP,2020-09-15T11:34:00Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/76048,MERGED,2020-08-29T02:28:06Z,2020-09-16T03:07:23Z,Initial support for riscv32gc_unknown_linux_gnu,alistair23,db228987ac3ff97cf243bca20213179a4127e649,3,Rollup merge of #76048 - alistair23:alistair/rv32-linux r=Amanieu Initial support for riscv32gc_unknown_linux_gnu Now that RISC-V 32-bit (RV32) support is in upstream glibc let's add support for userspace Rust.,THUMBS_UP,2020-09-24T14:45:53Z,tux3,NA https://github.com/rust-lang/rust/pull/76048,MERGED,2020-08-29T02:28:06Z,2020-09-16T03:07:23Z,Initial support for riscv32gc_unknown_linux_gnu,alistair23,db228987ac3ff97cf243bca20213179a4127e649,3,Rollup merge of #76048 - alistair23:alistair/rv32-linux r=Amanieu Initial support for riscv32gc_unknown_linux_gnu Now that RISC-V 32-bit (RV32) support is in upstream glibc let's add support for userspace Rust.,THUMBS_UP,2020-09-26T11:23:03Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/76048,MERGED,2020-08-29T02:28:06Z,2020-09-16T03:07:23Z,Initial support for riscv32gc_unknown_linux_gnu,alistair23,db228987ac3ff97cf243bca20213179a4127e649,3,Rollup merge of #76048 - alistair23:alistair/rv32-linux r=Amanieu Initial support for riscv32gc_unknown_linux_gnu Now that RISC-V 32-bit (RV32) support is in upstream glibc let's add support for userspace Rust.,THUMBS_UP,2020-10-31T07:14:15Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/76074,MERGED,2020-08-29T18:18:30Z,2020-09-02T03:17:58Z,Add new `-Z dump-mir-spanview` option,richkadel,5f28831a40477a0d564368e11fe6c5d6a26cd56f,11,Rollup merge of #76074 - richkadel:llvm-coverage-map-gen-6b.5.1 r=wesleywiser Add new `-Z dump-mir-spanview` option Similar to `-Z dump-mir-graphviz` this adds the option to write HTML+CSS files that allow users to analyze the spans associated with MIR elements (by individual statement just terminator or overall basic block). This PR was split out from PR #76004 and exposes an API for spanview HTML+CSS files that is also used to analyze code regions chosen for coverage instrumentation (in a follow-on PR). Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation r? @tmandry FYI @wesleywiser,ROCKET,2020-08-31T19:06:59Z,tmandry,NA https://github.com/rust-lang/rust/pull/76074,MERGED,2020-08-29T18:18:30Z,2020-09-02T03:17:58Z,Add new `-Z dump-mir-spanview` option,richkadel,5f28831a40477a0d564368e11fe6c5d6a26cd56f,11,Rollup merge of #76074 - richkadel:llvm-coverage-map-gen-6b.5.1 r=wesleywiser Add new `-Z dump-mir-spanview` option Similar to `-Z dump-mir-graphviz` this adds the option to write HTML+CSS files that allow users to analyze the spans associated with MIR elements (by individual statement just terminator or overall basic block). This PR was split out from PR #76004 and exposes an API for spanview HTML+CSS files that is also used to analyze code regions chosen for coverage instrumentation (in a follow-on PR). Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation r? @tmandry FYI @wesleywiser,HEART,2020-10-21T20:21:53Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-08-30T18:47:07Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-08-31T11:26:47Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-08-31T11:46:50Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-08-31T14:45:17Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-09-04T09:02:32Z,achanda,NA https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-09-18T14:31:28Z,folex,NA https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-09-20T08:00:04Z,kurnevsky,kurnevsky@gmail.com https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,HEART,2020-11-10T17:51:53Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/76098,CLOSED,2020-08-30T02:40:17Z,2021-05-17T04:02:47Z,"Stabilize the ""IP"" feature",caass,NA,NA,NA,THUMBS_UP,2020-12-03T12:52:23Z,anniekatlin,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-08-30T08:53:24Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-08-30T08:56:41Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-08-30T18:35:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-08-31T17:14:28Z,flosse,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-09-02T16:30:52Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-10-04T05:22:04Z,yerke,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,ROCKET,2020-10-04T05:22:07Z,yerke,NA https://github.com/rust-lang/rust/pull/76101,MERGED,2020-08-30T08:52:28Z,2020-10-02T21:45:56Z,Update RELEASES.md for 1.47.0,XAMPPRocky,17c9b710b535f2a35b0a1e6270ca5bf31a0ba188,1,Rollup merge of #76101 - XAMPPRocky:relnotes-.1.47.0 r=Mark-Simulacrum Update RELEASES.md for 1.47.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-.1.47.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release,HOORAY,2020-10-04T05:22:10Z,yerke,NA https://github.com/rust-lang/rust/pull/76104,CLOSED,2020-08-30T11:27:55Z,2022-02-14T15:40:51Z,Switch `mutable_borrow_reservation_conflict` lint to deny by default,marmeladema,NA,NA,NA,HOORAY,2020-09-02T02:45:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76104,CLOSED,2020-08-30T11:27:55Z,2022-02-14T15:40:51Z,Switch `mutable_borrow_reservation_conflict` lint to deny by default,marmeladema,NA,NA,NA,HOORAY,2020-09-15T19:30:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76104,CLOSED,2020-08-30T11:27:55Z,2022-02-14T15:40:51Z,Switch `mutable_borrow_reservation_conflict` lint to deny by default,marmeladema,NA,NA,NA,HOORAY,2020-09-20T20:34:10Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-08-30T14:11:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-08-30T18:36:48Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-08-30T20:20:18Z,est31,NA https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-09-15T16:17:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-09-24T09:53:29Z,jplatte,NA https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-09-27T22:37:30Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-10-01T02:28:46Z,taiki-e,NA https://github.com/rust-lang/rust/pull/76107,MERGED,2020-08-30T14:09:34Z,2020-10-03T00:43:04Z,Write manifest for MAJOR.MINOR channel to enable rustup convenience,carols10cents,ca0ff934e939969e09abcc2d17f0cff89b8147ee,1,"Rollup merge of #76107 - integer32llc:manifest-alias r=pietroalbini Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to https://github.com/rust-lang/rustup/issues/794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release we write duplicate manifests to `stable`. With this change only when we're doing a stable release also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request say `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of ""1.45.2"" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes so that we're not committing to anything before we know it works.",HOORAY,2020-10-02T10:44:47Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/76114,MERGED,2020-08-30T17:48:24Z,2020-09-12T11:20:42Z,Add saturating methods for `Duration`,marmeladema,7344f930c053395909a965c413a906415e5a5d8f,5,Rollup merge of #76114 - marmeladema:duration-saturating-ops r=shepmaster Add saturating methods for `Duration` In some project I needed a `saturating_add` method for `Duration`. I implemented it myself but i thought it would be a nice addition to the standard library as it matches closely with the integers types. 3 new methods have been introduced and are gated by the new `duration_saturating_ops` unstable feature: * `Duration::saturating_add` * `Duration::saturating_sub` * `Duration::saturating_mul` If have left the tracking issue to `none` for now as I want first to understand if those methods would be acceptable at all. If agreed I'll update the PR with the tracking issue. Further more to match the behavior of integers types I introduced 2 associated constants: * `Duration::MIN`: this one is somehow a duplicate from `Duration::zero()` method but at the time this method was added `MIN` was rejected as it was considered a different semantic (see https://github.com/rust-lang/rust/pull/72790#issuecomment-636511743). * `Duration::MAX` Both have been gated by the already existing unstable feature `duration_constants` I can introduce a new unstable feature if needed or just re-use the `duration_saturating_ops`. We might have to decide whether: * `MIN` should be replaced by `ZERO`? * associated constants over methods?,THUMBS_UP,2020-09-06T22:26:50Z,RazerM,frazer@frazermclean.co.uk https://github.com/rust-lang/rust/pull/76115,MERGED,2020-08-30T18:11:22Z,2020-08-31T15:25:28Z,Restore public visibility on some parsing functions for rustfmt,calebcartwright,d8eb30127b77c0138528d9defd5b825d5ae93092,2,Rollup merge of #76115 - calebcartwright:parser-fn-visibility r=matklad Restore public visibility on some parsing functions for rustfmt In #74826 the visibility of several parsing functions was reduced. However rustfmt is an external consumer of some of these functions as well and needs the visibility to be public similar to other elements in rustc_parse such as `parse_ident` https://github.com/rust-lang/rust/blob/db534b3ac286cf45688c3bbae6aa6e77439e52d2/src/librustc_parse/parser/mod.rs#L433-L436,THUMBS_UP,2020-08-30T19:49:23Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-08-30T19:14:53Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-08-30T19:14:55Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-08-30T19:14:58Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-08-30T19:16:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-09-03T13:07:57Z,rhysd,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-09-03T13:07:59Z,rhysd,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-09-06T12:26:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-09-09T21:57:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-09-11T21:53:44Z,tema3210,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-09-17T04:05:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-09-17T04:05:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-09-17T04:05:15Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-09-17T04:05:15Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-09-17T14:20:11Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-09-25T17:15:53Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-09-27T22:38:02Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-09-30T11:18:06Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-10-05T20:32:34Z,alexander-irbis,irbis.labs@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-29T12:04:03Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-12-29T12:04:04Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-12-29T20:55:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-12-29T20:55:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-29T20:55:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-29T20:55:33Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-30T02:03:02Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-30T07:58:50Z,foresterre,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-12-30T17:26:01Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-30T17:26:06Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-12-30T17:26:07Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-30T17:26:07Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-31T01:25:49Z,camelid,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-12-31T01:25:50Z,camelid,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T10:57:55Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2020-12-31T10:57:57Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-12-31T10:57:57Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",ROCKET,2020-12-31T10:57:58Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2020-12-31T15:22:20Z,adrian5,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T15:27:05Z,Dietr1ch,dietr1ch@acm.org https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T15:51:19Z,tversteeg,t@versteeg.email https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T16:53:26Z,Michael-J-Ward,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T17:10:06Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2020-12-31T17:44:20Z,dimitarvp,mitko.p@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2021-01-01T01:22:51Z,gus3inov,gus3inov@yandex.ru https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-01T03:27:54Z,equt,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-01T04:53:07Z,uuttff8,sassanid18@gmail.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2021-01-01T14:58:33Z,nwn,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-01T14:58:34Z,nwn,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2021-01-01T21:15:54Z,dzmitry-lahoda,dzmitry@lahoda.pro https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2021-01-02T20:12:42Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-02T20:12:42Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",THUMBS_UP,2021-01-03T12:50:17Z,oilaba,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-04T13:13:55Z,iago-lito,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HEART,2021-01-04T13:13:55Z,iago-lito,NA https://github.com/rust-lang/rust/pull/76119,MERGED,2020-08-30T19:07:32Z,2020-10-16T02:29:31Z,Stabilize move_ref_pattern,Amjad50,85dbb034909793f7f6387a668ce1c5da8bae6432,50,"Rollup merge of #76119 - Amjad50:stabilizing-move_ref_pattern r=nikomatsakis Stabilize move_ref_pattern # Implementation - Initially the rule was added in the run-up to 1.0. The AST-based borrow checker was having difficulty correctly enforcing match expressions that combined ref and move bindings and so it was decided to simplify forbid the combination out right. - The move to MIR-based borrow checking made it possible to enforce the rules in a finer-grained level but we kept the rule in place in an effort to be conservative in our changes. - In #68376 @Centril lifted the restriction but required a feature-gate. - This PR removes the feature-gate. Tracking issue: #68354. # Description This PR is to stabilize the feature `move_ref_pattern` which allows patterns containing both `by-ref` and `by-move` bindings at the same time. For example: `Foo(ref x y)` where `x` is `by-ref` and `y` is `by-move`. The rules of moving a variable also apply here when moving *part* of a variable such as it can't be referenced or moved before. If this pattern is used it would result in *partial move* which means that part of the variable is moved. The variable that was partially moved from cannot be used as a whole in this case only the parts that are still not moved can be used. ## Documentation - The reference (rust-lang/reference#881) - Rust by example (rust-lang/rust-by-example#1377) ## Tests There are many tests but I think one of the comperhensive ones: - [borrowck-move-ref-pattern-pass.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern-pass.rs) - [borrowck-move-ref-pattern.rs](https://github.com/Centril/rust/blob/85fbf49ce0e2274d0acf798f6e703747674feec3/src/test/ui/pattern/move-ref-patterns/borrowck-move-ref-pattern.rs) # Examples ```rust #[derive(PartialEq Eq)] struct Finished {} #[derive(PartialEq Eq)] struct Processing { status: ProcessStatus } #[derive(PartialEq Eq)] enum ProcessStatus { One Two Three } #[derive(PartialEq Eq)] enum Status { Finished(Finished) Processing(Processing) } fn check_result(_url: &str) -> Status { // fetch status from some server Status::Processing(Processing { status: ProcessStatus::One }) } fn wait_for_result(url: &str) -> Finished { let mut previous_status = None; loop { match check_result(url) { Status::Finished(f) => return f Status::Processing(p) => { match (&mut previous_status p.status) { (None status) => previous_status = Some(status) // first status (Some(previous) status) if *previous == status => {} // no change ignore (Some(previous) status) => { // Now it can be used // new status *previous = status; } } } } } } ``` Before we would have used: ```rust match (&previous_status p.status) { (Some(previous) status) if *previous == status => {} // no change ignore (_ status) => { // new status previous_status = Some(status); } } ``` Demonstrating *partial move* ```rust fn main() { #[derive(Debug)] struct Person { name: String age: u8 } let person = Person { name: String::from(""Alice"") age: 20 }; // `name` is moved out of person but `age` is referenced let Person { name ref age } = person; println!(""The person's age is {}"" age); println!(""The person's name is {}"" name); // Error! borrow of partially moved value: `person` partial move occurs //println!(""The person struct is {:?}"" person); // `person` cannot be used but `person.age` can be used as it is not moved println!(""The person's age from person struct is {}"" person.age); } ```",HOORAY,2021-01-07T20:06:35Z,Elrendio,NA https://github.com/rust-lang/rust/pull/76120,MERGED,2020-08-30T19:11:43Z,2020-09-03T02:15:35Z,Add `[T; N]::as_[mut_]slice`,LukasKalbertodt,10aa3d3f89195f6cab93700f2514744c814a4881,4,Rollup merge of #76120 - LukasKalbertodt:add-as-slice-method-to-array r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods like slices already have. The ability to add methods to arrays were added in #75212. Tracking issue: #76118 This adds: ```rust impl [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.,HOORAY,2020-08-31T09:15:45Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/76120,MERGED,2020-08-30T19:11:43Z,2020-09-03T02:15:35Z,Add `[T; N]::as_[mut_]slice`,LukasKalbertodt,10aa3d3f89195f6cab93700f2514744c814a4881,4,Rollup merge of #76120 - LukasKalbertodt:add-as-slice-method-to-array r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods like slices already have. The ability to add methods to arrays were added in #75212. Tracking issue: #76118 This adds: ```rust impl [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.,HOORAY,2020-09-10T04:26:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76120,MERGED,2020-08-30T19:11:43Z,2020-09-03T02:15:35Z,Add `[T; N]::as_[mut_]slice`,LukasKalbertodt,10aa3d3f89195f6cab93700f2514744c814a4881,4,Rollup merge of #76120 - LukasKalbertodt:add-as-slice-method-to-array r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods like slices already have. The ability to add methods to arrays were added in #75212. Tracking issue: #76118 This adds: ```rust impl [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.,THUMBS_UP,2020-09-10T06:36:01Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/76120,MERGED,2020-08-30T19:11:43Z,2020-09-03T02:15:35Z,Add `[T; N]::as_[mut_]slice`,LukasKalbertodt,10aa3d3f89195f6cab93700f2514744c814a4881,4,Rollup merge of #76120 - LukasKalbertodt:add-as-slice-method-to-array r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods like slices already have. The ability to add methods to arrays were added in #75212. Tracking issue: #76118 This adds: ```rust impl [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.,THUMBS_UP,2020-09-21T20:27:26Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76120,MERGED,2020-08-30T19:11:43Z,2020-09-03T02:15:35Z,Add `[T; N]::as_[mut_]slice`,LukasKalbertodt,10aa3d3f89195f6cab93700f2514744c814a4881,4,Rollup merge of #76120 - LukasKalbertodt:add-as-slice-method-to-array r=Mark-Simulacrum Add `[T; N]::as_[mut_]slice` Part of me trying to populate arrays with a couple of basic useful methods like slices already have. The ability to add methods to arrays were added in #75212. Tracking issue: #76118 This adds: ```rust impl [T; N] { pub fn as_slice(&self) -> &[T]; pub fn as_mut_slice(&mut self) -> &mut [T]; } ``` These methods are like the ones on `std::array::FixedSizeArray` and in the crate `arraytools`.,THUMBS_UP,2021-07-26T19:02:36Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/76130,CLOSED,2020-08-30T22:04:52Z,2021-01-04T15:30:28Z,[WIP] Token-based outer attributes handling,Aaron1011,NA,NA,NA,THUMBS_UP,2020-11-12T14:20:44Z,thiolliere,NA https://github.com/rust-lang/rust/pull/76133,CLOSED,2020-08-30T23:11:18Z,2020-10-23T00:03:16Z,[WIP] Remove some `FatalError.raise()`s in StringReader,LeSeulArtichaut,NA,NA,NA,HOORAY,2020-09-10T23:15:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76135,MERGED,2020-08-31T00:26:30Z,2020-09-21T12:53:13Z,Stabilize some Option methods as const,CDirkx,c3abb8290879d3b5f5a34aba243defbb74cfdc6c,7,Rollup merge of #76135 - CDirkx:const-option r=dtolnay oli-obk Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: #67441). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463). Related: #76225,HOORAY,2020-09-01T07:06:07Z,faern,NA https://github.com/rust-lang/rust/pull/76135,MERGED,2020-08-31T00:26:30Z,2020-09-21T12:53:13Z,Stabilize some Option methods as const,CDirkx,c3abb8290879d3b5f5a34aba243defbb74cfdc6c,7,Rollup merge of #76135 - CDirkx:const-option r=dtolnay oli-obk Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: #67441). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463). Related: #76225,HOORAY,2020-09-10T04:32:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76135,MERGED,2020-08-31T00:26:30Z,2020-09-21T12:53:13Z,Stabilize some Option methods as const,CDirkx,c3abb8290879d3b5f5a34aba243defbb74cfdc6c,7,Rollup merge of #76135 - CDirkx:const-option r=dtolnay oli-obk Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: #67441). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463). Related: #76225,HOORAY,2020-09-10T22:11:14Z,DianaNites,NA https://github.com/rust-lang/rust/pull/76135,MERGED,2020-08-31T00:26:30Z,2020-09-21T12:53:13Z,Stabilize some Option methods as const,CDirkx,c3abb8290879d3b5f5a34aba243defbb74cfdc6c,7,Rollup merge of #76135 - CDirkx:const-option r=dtolnay oli-obk Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: #67441). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463). Related: #76225,HOORAY,2020-09-23T23:08:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76135,MERGED,2020-08-31T00:26:30Z,2020-09-21T12:53:13Z,Stabilize some Option methods as const,CDirkx,c3abb8290879d3b5f5a34aba243defbb74cfdc6c,7,Rollup merge of #76135 - CDirkx:const-option r=dtolnay oli-obk Stabilize some Option methods as const Stabilize the following methods of `Option` as const: - `is_some` - `is_none` - `as_ref` These methods are currently const under the unstable feature `const_option` (tracking issue: #67441). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463). Related: #76225,HOORAY,2020-10-09T11:51:28Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/76136,MERGED,2020-08-31T00:53:37Z,2020-09-20T15:13:36Z,Stabilize some Result methods as const,CDirkx,b873fa6d42cf305131d2583d03b84686e5e40f2e,10,Auto merge of #76136 - CDirkx:const-result r=dtolnay Stabilize some Result methods as const Stabilize the following methods of Result as const: - `is_ok` - `is_err` - `as_ref` A test is also included analogous to the test for `const_option`. These methods are currently const under the unstable feature `const_result` (tracking issue: #67520). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135). Note: these methods are the only methods currently under the `const_result` feature thus this PR results in the removal of the feature. Related: #76225,THUMBS_UP,2020-09-02T03:45:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76136,MERGED,2020-08-31T00:53:37Z,2020-09-20T15:13:36Z,Stabilize some Result methods as const,CDirkx,b873fa6d42cf305131d2583d03b84686e5e40f2e,10,Auto merge of #76136 - CDirkx:const-result r=dtolnay Stabilize some Result methods as const Stabilize the following methods of Result as const: - `is_ok` - `is_err` - `as_ref` A test is also included analogous to the test for `const_option`. These methods are currently const under the unstable feature `const_result` (tracking issue: #67520). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135). Note: these methods are the only methods currently under the `const_result` feature thus this PR results in the removal of the feature. Related: #76225,THUMBS_UP,2020-09-10T04:32:21Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76136,MERGED,2020-08-31T00:53:37Z,2020-09-20T15:13:36Z,Stabilize some Result methods as const,CDirkx,b873fa6d42cf305131d2583d03b84686e5e40f2e,10,Auto merge of #76136 - CDirkx:const-result r=dtolnay Stabilize some Result methods as const Stabilize the following methods of Result as const: - `is_ok` - `is_err` - `as_ref` A test is also included analogous to the test for `const_option`. These methods are currently const under the unstable feature `const_result` (tracking issue: #67520). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135). Note: these methods are the only methods currently under the `const_result` feature thus this PR results in the removal of the feature. Related: #76225,THUMBS_UP,2020-09-10T22:11:04Z,DianaNites,NA https://github.com/rust-lang/rust/pull/76136,MERGED,2020-08-31T00:53:37Z,2020-09-20T15:13:36Z,Stabilize some Result methods as const,CDirkx,b873fa6d42cf305131d2583d03b84686e5e40f2e,10,Auto merge of #76136 - CDirkx:const-result r=dtolnay Stabilize some Result methods as const Stabilize the following methods of Result as const: - `is_ok` - `is_err` - `as_ref` A test is also included analogous to the test for `const_option`. These methods are currently const under the unstable feature `const_result` (tracking issue: #67520). I believe these methods to be eligible for stabilization because of the stabilization of #49146 (Allow if and match in constants) and the trivial implementations see also: [PR#75463](https://github.com/rust-lang/rust/pull/75463) and [PR#76135](https://github.com/rust-lang/rust/pull/76135). Note: these methods are the only methods currently under the `const_result` feature thus this PR results in the removal of the feature. Related: #76225,THUMBS_UP,2020-09-23T23:08:20Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76161,MERGED,2020-08-31T14:10:32Z,2020-09-01T05:16:14Z,Remove notrust in rustc_middle,pickfire,9df193b6b28a692349b8c547bb2b563944c61fdf,1,Rollup merge of #76161 - pickfire:patch-3 r=pickfire Remove notrust in rustc_middle Fix #19599 This confuse people no trust or not rust? Or not rust no trust? Only trust rust ^^ Superseeds https://github.com/rust-lang/rust/pull/76063 r? @matklad,LAUGH,2020-09-01T02:21:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/76171,MERGED,2020-08-31T17:25:00Z,2020-09-15T12:16:35Z,Detect turbofish with multiple type params missing leading `::`,estebank,90b1f5ae59291dd69d72fad41a22277df19dc953,4,Auto merge of #76171 - estebank:turbofish-the-revenge r=davidtwco Detect turbofish with multiple type params missing leading `::` Fix #76072.,THUMBS_UP,2020-09-01T00:52:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/76189,CLOSED,2020-09-01T05:13:01Z,2020-09-30T00:13:41Z,Implement PartialOrd and PartialEq for UTF-8 strings and FFI Strings,lopopolo,NA,NA,NA,HOORAY,2020-09-01T15:34:17Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/76196,MERGED,2020-09-01T12:44:24Z,2020-10-13T06:35:15Z,rustdoc: skip #[allow(missing docs)] for docs in coverage report,r-52,4d63435aaef3bdfec37ddf957b3f6e66e771ee2c,5,Auto merge of #76196 - r-52:r-coverage-allow-missing-docs r=jyn514 rustdoc: skip #[allow(missing docs)] for docs in coverage report During the document coverage reporting with: ```bash rustdoc something.rs -Z unstable-options --show-coverage ``` the coverage report counts code that is marked with `#[allow(missing_docs)]` for the calculation which outputs lower numbers in the coverage report even though these parts should be ignored for the calculation. Right now I'm not sure how this can be tested (CI)? (I verified it by hand and ran the unit tests) r? `@jyn514` **Reference:** Fixes #76121,HEART,2020-09-01T12:46:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76198,MERGED,2020-09-01T13:51:07Z,2020-09-16T03:07:14Z,Make some Ordering methods const,CDirkx,69ac07608e5f6b2e7608108a0665ead8df5da88e,2,Rollup merge of #76198 - CDirkx:const-ordering r=dtolnay Make some Ordering methods const Resubmission of [PR#75463](https://github.com/rust-lang/rust/pull/75463) as per [PR#76172](https://github.com/rust-lang/rust/pull/76172). Constify the following methods of `core::cmp::Ordering`: - `reverse` - `then` Insta-stabilizes these methods as const under the `const_ordering` feature as their implementation is a trivial match and the recent stabilization of #49146 (Allow `if` and `match` in constants). Note: the `const_ordering` feature has never actually been used as these methods have not been `#[rustc_const_unstable]`. Tracking issue: #76113,THUMBS_UP,2020-09-09T23:16:54Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/76198,MERGED,2020-09-01T13:51:07Z,2020-09-16T03:07:14Z,Make some Ordering methods const,CDirkx,69ac07608e5f6b2e7608108a0665ead8df5da88e,2,Rollup merge of #76198 - CDirkx:const-ordering r=dtolnay Make some Ordering methods const Resubmission of [PR#75463](https://github.com/rust-lang/rust/pull/75463) as per [PR#76172](https://github.com/rust-lang/rust/pull/76172). Constify the following methods of `core::cmp::Ordering`: - `reverse` - `then` Insta-stabilizes these methods as const under the `const_ordering` feature as their implementation is a trivial match and the recent stabilization of #49146 (Allow `if` and `match` in constants). Note: the `const_ordering` feature has never actually been used as these methods have not been `#[rustc_const_unstable]`. Tracking issue: #76113,THUMBS_UP,2020-09-10T04:31:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76198,MERGED,2020-09-01T13:51:07Z,2020-09-16T03:07:14Z,Make some Ordering methods const,CDirkx,69ac07608e5f6b2e7608108a0665ead8df5da88e,2,Rollup merge of #76198 - CDirkx:const-ordering r=dtolnay Make some Ordering methods const Resubmission of [PR#75463](https://github.com/rust-lang/rust/pull/75463) as per [PR#76172](https://github.com/rust-lang/rust/pull/76172). Constify the following methods of `core::cmp::Ordering`: - `reverse` - `then` Insta-stabilizes these methods as const under the `const_ordering` feature as their implementation is a trivial match and the recent stabilization of #49146 (Allow `if` and `match` in constants). Note: the `const_ordering` feature has never actually been used as these methods have not been `#[rustc_const_unstable]`. Tracking issue: #76113,THUMBS_UP,2020-09-14T01:12:48Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2020-09-01T14:25:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2020-09-01T15:13:48Z,digama0,NA https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2020-09-17T04:02:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2021-01-01T03:27:44Z,zphixon,zphixon@gmail.com https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2021-01-01T13:42:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HEART,2021-01-04T13:13:26Z,iago-lito,NA https://github.com/rust-lang/rust/pull/76199,MERGED,2020-09-01T14:04:59Z,2020-10-17T04:09:02Z,Permit uninhabited enums to cast into ints,Mark-Simulacrum,496e2feed684afc3eb43a3e4ac933fc61a5a8305,4,Rollup merge of #76199 - Mark-Simulacrum:void-zero r=nikomatsakis Permit uninhabited enums to cast into ints This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced and I suspect no one remembers. The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case). Fixes #75647.,HOORAY,2021-01-04T13:13:29Z,iago-lito,NA https://github.com/rust-lang/rust/pull/76203,CLOSED,2020-09-01T16:35:47Z,2020-10-28T00:42:04Z,Raise noncontinuable exception when aborting on earlier Windows versions,nxtn,NA,NA,NA,THUMBS_UP,2020-09-02T06:04:40Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/76204,MERGED,2020-09-01T16:46:21Z,2020-09-03T02:15:24Z,Rename and expose LoopState as ControlFlow,NoraCodes,d059f2619fa5d09844c1b66e351cf2cdbf781fa5,6,Rollup merge of #76204 - NoraCodes:nora/control_flow_enum r=scottmcm Rename and expose LoopState as ControlFlow Basic PR for #75744. Addresses everything there except for documentation; lots of examples are probably a good idea.,HOORAY,2020-09-02T06:44:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76206,MERGED,2020-09-01T17:05:09Z,2020-09-02T03:17:37Z,Make all methods of `std::net::Ipv6Addr` const,CDirkx,11ff32f9ecabb0806140d5e950b5c19698cc5efc,3,Rollup merge of #76206 - CDirkx:const-ipv6 r=ecstatic-morse Make all methods of `std::net::Ipv6Addr` const Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` This would make all methods of `Ipv6Addr` const. Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==` all other methods did not require a change. All these methods are dependent on `segments` the current implementation of which requires unstable `const_fn_transmute` ([PR#75085](https://github.com/rust-lang/rust/pull/75085)). Part of #76205,HEART,2020-09-01T17:31:04Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/76206,MERGED,2020-09-01T17:05:09Z,2020-09-02T03:17:37Z,Make all methods of `std::net::Ipv6Addr` const,CDirkx,11ff32f9ecabb0806140d5e950b5c19698cc5efc,3,Rollup merge of #76206 - CDirkx:const-ipv6 r=ecstatic-morse Make all methods of `std::net::Ipv6Addr` const Make the following methods of `std::net::Ipv6Addr` unstable const under the `const_ipv6` feature: - `segments` - `is_unspecified` - `is_loopback` - `is_global` (unstable) - `is_unique_local` - `is_unicast_link_local_strict` - `is_documentation` - `multicast_scope` - `is_multicast` - `to_ipv4_mapped` - `to_ipv4` This would make all methods of `Ipv6Addr` const. Changed the implementation of `is_unspecified` and `is_loopback` to use a `match` instead of `==` all other methods did not require a change. All these methods are dependent on `segments` the current implementation of which requires unstable `const_fn_transmute` ([PR#75085](https://github.com/rust-lang/rust/pull/75085)). Part of #76205,HEART,2020-09-01T19:09:33Z,panaman67,NA https://github.com/rust-lang/rust/pull/76223,CLOSED,2020-09-01T23:03:08Z,2020-09-17T16:35:09Z,Clean up rustdoc tests by moving them into one place,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2020-09-02T07:51:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/76223,CLOSED,2020-09-01T23:03:08Z,2020-09-17T16:35:09Z,Clean up rustdoc tests by moving them into one place,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2020-09-03T16:40:33Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/76227,MERGED,2020-09-02T00:37:28Z,2020-11-08T16:16:05Z,Stabilize `Poll::is_ready` and `is_pending` as const,CDirkx,bdeace9f4edd2f8c1f06d147940a07550f133f42,3,Rollup merge of #76227 - CDirkx:const-poll r=KodrAus Stabilize `Poll::is_ready` and `is_pending` as const Insta-stabilize the methods `is_ready` and `is_pending` of `std::task::Poll` as const in the same way as [PR#76198](https://github.com/rust-lang/rust/pull/76198). Possible because of the recent stabilization of const control flow. Part of #76225.,HEART,2020-10-23T12:32:10Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76244,MERGED,2020-09-02T11:38:02Z,2020-09-13T18:16:41Z,Removing the `def_id` field from hot `ParamEnv` to make it smaller,vandenheuvel,7402a394471a6738a40fea7d4f1891666e5a80c5,35,Auto merge of #76244 - vandenheuvel:remove__paramenv__def_id r=nikomatsakis Removing the `def_id` field from hot `ParamEnv` to make it smaller This PR addresses https://github.com/rust-lang/rust/issues/74865.,HEART,2020-09-13T23:47:59Z,nnethercote,NA https://github.com/rust-lang/rust/pull/76256,MERGED,2020-09-02T18:57:12Z,2020-11-12T18:06:03Z,incr-comp: hash and serialize span end line/column,tgnottingham,9722952f0bed5815cb22cb4878be09fb39f92804,5,Auto merge of #76256 - tgnottingham:issue-74890 r=nikomatsakis incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length for example then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span but we only hash the end location. So hash both. Fix #46744 fix #59954 fix #63161 fix #73640 fix #73967 fix #74890 fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.,HEART,2020-09-02T19:01:27Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/76256,MERGED,2020-09-02T18:57:12Z,2020-11-12T18:06:03Z,incr-comp: hash and serialize span end line/column,tgnottingham,9722952f0bed5815cb22cb4878be09fb39f92804,5,Auto merge of #76256 - tgnottingham:issue-74890 r=nikomatsakis incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length for example then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span but we only hash the end location. So hash both. Fix #46744 fix #59954 fix #63161 fix #73640 fix #73967 fix #74890 fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.,HEART,2020-09-02T19:50:15Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/76256,MERGED,2020-09-02T18:57:12Z,2020-11-12T18:06:03Z,incr-comp: hash and serialize span end line/column,tgnottingham,9722952f0bed5815cb22cb4878be09fb39f92804,5,Auto merge of #76256 - tgnottingham:issue-74890 r=nikomatsakis incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length for example then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span but we only hash the end location. So hash both. Fix #46744 fix #59954 fix #63161 fix #73640 fix #73967 fix #74890 fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.,HEART,2020-10-06T14:01:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76256,MERGED,2020-09-02T18:57:12Z,2020-11-12T18:06:03Z,incr-comp: hash and serialize span end line/column,tgnottingham,9722952f0bed5815cb22cb4878be09fb39f92804,5,Auto merge of #76256 - tgnottingham:issue-74890 r=nikomatsakis incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length for example then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span but we only hash the end location. So hash both. Fix #46744 fix #59954 fix #63161 fix #73640 fix #73967 fix #74890 fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.,HEART,2020-11-12T21:25:51Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/76256,MERGED,2020-09-02T18:57:12Z,2020-11-12T18:06:03Z,incr-comp: hash and serialize span end line/column,tgnottingham,9722952f0bed5815cb22cb4878be09fb39f92804,5,Auto merge of #76256 - tgnottingham:issue-74890 r=nikomatsakis incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length for example then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span but we only hash the end location. So hash both. Fix #46744 fix #59954 fix #63161 fix #73640 fix #73967 fix #74890 fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.,HEART,2020-12-15T00:11:21Z,Mromson,NA https://github.com/rust-lang/rust/pull/76258,MERGED,2020-09-02T20:53:11Z,2020-09-05T17:18:39Z,x.py check checks tests/examples/benches,Mark-Simulacrum,45bdee8fde3a47dd0316e1b2bc30641102ea7912,2,Rollup merge of #76258 - Mark-Simulacrum:check-tests r=ehuss x.py check checks tests/examples/benches This also adds a check for bootstrap to x.py. r? @ehuss,HEART,2020-09-02T21:42:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76258,MERGED,2020-09-02T20:53:11Z,2020-09-05T17:18:39Z,x.py check checks tests/examples/benches,Mark-Simulacrum,45bdee8fde3a47dd0316e1b2bc30641102ea7912,2,Rollup merge of #76258 - Mark-Simulacrum:check-tests r=ehuss x.py check checks tests/examples/benches This also adds a check for bootstrap to x.py. r? @ehuss,HEART,2020-09-03T06:38:41Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76258,MERGED,2020-09-02T20:53:11Z,2020-09-05T17:18:39Z,x.py check checks tests/examples/benches,Mark-Simulacrum,45bdee8fde3a47dd0316e1b2bc30641102ea7912,2,Rollup merge of #76258 - Mark-Simulacrum:check-tests r=ehuss x.py check checks tests/examples/benches This also adds a check for bootstrap to x.py. r? @ehuss,HEART,2020-09-03T17:09:03Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76260,MERGED,2020-09-02T21:33:30Z,2020-10-09T02:28:34Z,Implementation of RFC2867,xd009642,03ef8a081ef713609a65e71ed41c6775aeb138aa,22,Auto merge of #76260 - xd009642:rfc/2867 r=jonas-schievink Implementation of RFC2867 https://github.com/rust-lang/rust/issues/74727 So I've started work on this I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:,HEART,2020-10-09T02:58:07Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/76260,MERGED,2020-09-02T21:33:30Z,2020-10-09T02:28:34Z,Implementation of RFC2867,xd009642,03ef8a081ef713609a65e71ed41c6775aeb138aa,22,Auto merge of #76260 - xd009642:rfc/2867 r=jonas-schievink Implementation of RFC2867 https://github.com/rust-lang/rust/issues/74727 So I've started work on this I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:,HEART,2020-10-09T07:53:54Z,karroffel,NA https://github.com/rust-lang/rust/pull/76269,MERGED,2020-09-03T01:49:42Z,2020-10-27T18:58:36Z,added a lint against function item references,ayrtonm,07e968b640e8ff76fa8be4b48b70ab80ea577800,7,Auto merge of #76269 - ayrtonm:function-reference-lint r=oli-obk added a lint against function references this lint suggests casting function references to `*const ()` closes #75239 r? `@RalfJung`,HEART,2020-09-03T02:51:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76269,MERGED,2020-09-03T01:49:42Z,2020-10-27T18:58:36Z,added a lint against function item references,ayrtonm,07e968b640e8ff76fa8be4b48b70ab80ea577800,7,Auto merge of #76269 - ayrtonm:function-reference-lint r=oli-obk added a lint against function references this lint suggests casting function references to `*const ()` closes #75239 r? `@RalfJung`,HEART,2020-09-05T09:48:28Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76269,MERGED,2020-09-03T01:49:42Z,2020-10-27T18:58:36Z,added a lint against function item references,ayrtonm,07e968b640e8ff76fa8be4b48b70ab80ea577800,7,Auto merge of #76269 - ayrtonm:function-reference-lint r=oli-obk added a lint against function references this lint suggests casting function references to `*const ()` closes #75239 r? `@RalfJung`,HEART,2020-09-05T13:37:28Z,elichai,NA https://github.com/rust-lang/rust/pull/76273,MERGED,2020-09-03T05:45:43Z,2020-09-07T02:21:15Z,Move some Vec UI tests into alloc unit tests,CraftSpider,e488c4f187be7f561ff24fcbdc8427767be79f1f,7,Rollup merge of #76273 - CraftSpider:master r=matklad Move some Vec UI tests into alloc unit tests A bit of work towards #76268 makes a number of the Vec UI tests that are simply running code into unit tests. Ensured that they are being run when testing liballoc locally.,HEART,2020-09-03T06:36:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76273,MERGED,2020-09-03T05:45:43Z,2020-09-07T02:21:15Z,Move some Vec UI tests into alloc unit tests,CraftSpider,e488c4f187be7f561ff24fcbdc8427767be79f1f,7,Rollup merge of #76273 - CraftSpider:master r=matklad Move some Vec UI tests into alloc unit tests A bit of work towards #76268 makes a number of the Vec UI tests that are simply running code into unit tests. Ensured that they are being run when testing liballoc locally.,HEART,2020-09-03T10:50:28Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76291,MERGED,2020-09-03T15:23:38Z,2020-09-10T10:07:05Z,Rename IsJoint -> Spacing ,matklad,a18b34d9793a88142c122f83fe53683f58f26ecc,11,Auto merge of #76291 - matklad:spacing r=petrochenkov Rename IsJoint -> Spacing Builds on #76286 and might conflict with #76285 r? `@petrochenkov`,HEART,2020-09-10T15:18:25Z,95th,NA https://github.com/rust-lang/rust/pull/76295,MERGED,2020-09-03T18:21:41Z,2020-09-21T03:03:43Z,Remove MMX from Rust ,mati865,0f9f0b384a0a3c997c1ea8f838f5591f12f96633,12,"Auto merge of #76295 - mati865:remove-mmx r=Amanieu oli-obk Remove MMX from Rust Follow-up to https://github.com/rust-lang/stdarch/pull/890 This removes most of MMX from Rust (tests pass with small changes) keeping stable `is_x86_feature_detected!(""mmx"")` working.",HEART,2020-09-03T21:28:10Z,panaman67,NA https://github.com/rust-lang/rust/pull/76295,MERGED,2020-09-03T18:21:41Z,2020-09-21T03:03:43Z,Remove MMX from Rust ,mati865,0f9f0b384a0a3c997c1ea8f838f5591f12f96633,12,"Auto merge of #76295 - mati865:remove-mmx r=Amanieu oli-obk Remove MMX from Rust Follow-up to https://github.com/rust-lang/stdarch/pull/890 This removes most of MMX from Rust (tests pass with small changes) keeping stable `is_x86_feature_detected!(""mmx"")` working.",HOORAY,2020-09-03T21:28:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/76297,MERGED,2020-09-03T19:37:53Z,2020-09-12T11:20:30Z,rustdoc: fix min_const_generics with ty::Param,lcnr,5d90d6ee903d547cbb708b059c3b18b81fb7827c,2,Rollup merge of #76297 - lcnr:const-ty-alias r=varkor rustdoc: fix min_const_generics with ty::Param fixes #75913 r? @varkor cc @jyn514,HEART,2020-09-03T19:42:48Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76299,MERGED,2020-09-03T20:11:06Z,2020-09-07T02:21:09Z,Make `Ipv4Addr` and `Ipv6Addr` const tests unit tests under `library`,CDirkx,2c62189db1def0d47a0e55218bbbe305cbea18bc,3,Rollup merge of #76299 - CDirkx:ip-tests r=matklad Make `Ipv4Addr` and `Ipv6Addr` const tests unit tests under `library` These tests are about the standard library not the compiler itself thus should live in `library` see #76268.,HEART,2020-09-03T20:38:08Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76309,MERGED,2020-09-04T02:52:47Z,2020-09-07T02:21:04Z,Indent a note to make folding work nicer,tesuji,8ff13f4fd268dbd3cd7dd6d0b9680114df03f70c,3,Rollup merge of #76309 - lzutao:indent-note r=jyn514 Indent a note to make folding work nicer Sublime Text folds code based on indentation. It maybe an unnecessary change but does it look nicer after that ?,THUMBS_UP,2020-09-04T03:11:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",HEART,2020-09-04T10:12:11Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",THUMBS_UP,2020-09-05T09:41:01Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",HEART,2020-09-10T04:31:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",THUMBS_UP,2020-09-10T04:31:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",HEART,2020-09-11T06:31:30Z,eopb,NA https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",THUMBS_UP,2020-09-24T18:37:11Z,elichai,NA https://github.com/rust-lang/rust/pull/76310,MERGED,2020-09-04T03:10:17Z,2020-09-19T13:32:17Z,Add `[T; N]: TryFrom>` (insta-stable),scottmcm,bac2f393504309e505a08c0e66a0e8d66467cf32,1,"Rollup merge of #76310 - scottmcm:array-try_from-vec r=dtolnay Add `[T; N]: TryFrom>` (insta-stable) This is very similar to the [existing](https://doc.rust-lang.org/nightly/std/convert/trait.TryFrom.html#impl-TryFrom%3CBox%3C%5BT%5D%3E%3E) `Box<[T; N]>: TryFrom>` but allows avoiding the `shrink_to_fit` if you have a vector and not a boxed slice. Like the slice equivalents of this it fails if the length of the vector is not exactly `N`. This uses `Vec` as the `Error` type to return the input like how the `Rc<[T]> -> Rc<[T; N]>` (and Arc) ones also reflect the input directly in the error type. ```rust #[stable(feature = ""array_try_from_vec"" since = ""1.47.0"")] impl TryFrom> for [T; N] { type Error = Vec; fn try_from(mut vec: Vec) -> Result<[T; N] Vec>; } ``` Inspired by this zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/APIs.20for.20getting.20stuff.20from.20a.20Vec.20by.20owned/near/209048103",THUMBS_UP,2020-10-26T08:41:21Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/76311,MERGED,2020-09-04T03:49:58Z,2020-09-15T14:23:07Z,Split `core::slice` to smaller mods,tesuji,4c1966f97e192d6282be935baa163fb58f9b8b27,9,"Auto merge of #76311 - lzutao:split_core-slice r=lcnr Split `core::slice` to smaller mods Unfortunately the `#[lang = ""slice""]` is too big (3003 lines) I cannot split it further. Note for reviewer: * I split to multiple commits for easier reviewing but I could git squash them all to one if requested. * Recommend pulling this change locally and using advanced git diff viewer or this command: ``` git show --reverse --color-moved=dimmed-zebra master.. ``` --- I split core/slice/mod.rs to these modules: * `ascii`: For operations on `[u8]`. * `cmp`: For comparison operations on `[T]` like PartialEq and SliceContains impl. * `index`: For indexing operations like Index/IndexMut and SliceIndex. * `iter`: For Iterator definitions and implementation on `[T]`. - `macros`: For iterator! and forward_iterator! macros. * `raw`: For free function to create `&[T]` or `&mut [T]` from pointer + length or a reference. The heapsort wrapper in mod.rs is removed in favor of reexport from `sort::heapsort`.",EYES,2020-09-04T15:34:53Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/76313,MERGED,2020-09-04T05:25:24Z,2020-09-10T00:11:12Z,Improved the MIR spanview output,richkadel,bab09684b4c39605ca50e5512403020ab010bb8e,7,"Rollup merge of #76313 - richkadel:mir-spanview-2 r=wesleywiser Improved the MIR spanview output * Adds missing ""tail"" spans (spans that continue beyond the end of overlapping spans) * Adds a caret to highlight empty spans associated with MIR elements that have a position but otherwise would not be visible. * Adds visual pointing brackets at the beginning and end of each span r? @tmandry FYI: @wesleywiser",THUMBS_UP,2020-09-09T21:55:03Z,tmandry,NA https://github.com/rust-lang/rust/pull/76327,MERGED,2020-09-04T14:31:34Z,2020-09-19T18:45:38Z,Split `core/num/mod.rs` to smaller mods,tesuji,59fb88d061544a035f3043b47594b34789204cee,20,Auto merge of #76327 - lzutao:split-core-num r=SimonSapin Split `core/num/mod.rs` to smaller mods Note for reviewer: * I split to multiple commits for easier reviewing but I could git squash them all to one if requested. * Recommend pulling this change locally and using advanced git diff viewer or this command: ``` git show --reverse --color-moved=dimmed-zebra master.. ``` --- I split `core/num/mod.rs` to these modules: * `error`: For error structs like `ParseIntError`. * blanket `shells` dir: For dummy number type modules: std::i32 std::f32 and the likes. Why? See below. * `int_macros` and `uint_macros`: Real implementation of all integer types via `int_impl` and `uint_impl` * `nonzero`: For `NonZero*` types and their implementations. * `wrapping`: For `Wrapping` types.,HEART,2020-09-17T11:28:06Z,varkor,NA https://github.com/rust-lang/rust/pull/76332,MERGED,2020-09-04T18:00:03Z,2020-09-08T18:00:13Z,Add rust-dev component to support rustc development,Mark-Simulacrum,5099914a16a215794ad243df0cc7a05d91d168e0,2,Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm r=pietroalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one since we want a master build with the full CI LLVM to be available for easier testing.,HEART,2020-09-05T02:19:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/76332,MERGED,2020-09-04T18:00:03Z,2020-09-08T18:00:13Z,Add rust-dev component to support rustc development,Mark-Simulacrum,5099914a16a215794ad243df0cc7a05d91d168e0,2,Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm r=pietroalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one since we want a master build with the full CI LLVM to be available for easier testing.,HEART,2020-09-05T02:26:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76332,MERGED,2020-09-04T18:00:03Z,2020-09-08T18:00:13Z,Add rust-dev component to support rustc development,Mark-Simulacrum,5099914a16a215794ad243df0cc7a05d91d168e0,2,Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm r=pietroalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one since we want a master build with the full CI LLVM to be available for easier testing.,HEART,2020-09-07T19:10:11Z,camelid,NA https://github.com/rust-lang/rust/pull/76332,MERGED,2020-09-04T18:00:03Z,2020-09-08T18:00:13Z,Add rust-dev component to support rustc development,Mark-Simulacrum,5099914a16a215794ad243df0cc7a05d91d168e0,2,Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm r=pietroalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one since we want a master build with the full CI LLVM to be available for easier testing.,THUMBS_UP,2020-09-16T23:23:35Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/76332,MERGED,2020-09-04T18:00:03Z,2020-09-08T18:00:13Z,Add rust-dev component to support rustc development,Mark-Simulacrum,5099914a16a215794ad243df0cc7a05d91d168e0,2,Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm r=pietroalbini Add rust-dev component to support rustc development This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date and carries all necessary patches. This is a separate PR from #76349 because it needs to land before that one since we want a master build with the full CI LLVM to be available for easier testing.,HEART,2020-09-17T16:53:53Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/76335,MERGED,2020-09-04T18:19:19Z,2020-09-16T08:55:04Z,Make all methods of `Duration` unstably const,CDirkx,22dd07d5556eec3e3f98d490827720e45fa27c64,4,Rollup merge of #76335 - CDirkx:const-duration r=ecstatic-morse Make all methods of `Duration` unstably const Make the following methods of `Duration` unstable const under `duration_const_2`: - `from_secs_f64` - `from_secs_f32` - `mul_f64` - `mul_f32` - `div_f64` - `div_f32` This results in all methods of `Duration` being (unstable) const. Moved the tests to `library` as part of #76268. Possible because of #72449 which made the relevant `f32` and `f64` methods const. Tracking issue: #72440 r? @ecstatic-morse,THUMBS_UP,2020-09-05T09:17:19Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76335,MERGED,2020-09-04T18:19:19Z,2020-09-16T08:55:04Z,Make all methods of `Duration` unstably const,CDirkx,22dd07d5556eec3e3f98d490827720e45fa27c64,4,Rollup merge of #76335 - CDirkx:const-duration r=ecstatic-morse Make all methods of `Duration` unstably const Make the following methods of `Duration` unstable const under `duration_const_2`: - `from_secs_f64` - `from_secs_f32` - `mul_f64` - `mul_f32` - `div_f64` - `div_f32` This results in all methods of `Duration` being (unstable) const. Moved the tests to `library` as part of #76268. Possible because of #72449 which made the relevant `f32` and `f64` methods const. Tracking issue: #72440 r? @ecstatic-morse,THUMBS_UP,2020-09-09T21:59:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76340,MERGED,2020-09-04T20:25:33Z,2020-09-07T02:20:56Z,Remove unused duplicated `trivial_dropck_outlives`,jonas-schievink,1db9290a83985f3000aa3af6ccf529275e29be6e,1,Rollup merge of #76340 - jonas-schievink:rm-dupe r=Mark-Simulacrum Remove unused duplicated `trivial_dropck_outlives` The copy that is actually in use now lives here: https://github.com/rust-lang/rust/blob/d2454643e137bde519786ee9e650c455d7ad6f34/compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs#L84,HEART,2020-09-04T20:47:15Z,panaman67,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-09-05T15:03:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-09-09T22:03:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HOORAY,2020-09-09T22:03:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",ROCKET,2020-09-09T22:03:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-09-13T08:07:15Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-09-13T09:07:30Z,Wodann,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-09-17T04:00:09Z,est31,NA https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HOORAY,2020-09-18T03:44:16Z,Finchiedev,developer.finchie@gmail.com https://github.com/rust-lang/rust/pull/76349,MERGED,2020-09-04T23:01:49Z,2020-09-13T04:02:10Z,Download LLVM from CI to bootstrap (linux-only to start),Mark-Simulacrum,04b72b469781b811655b0d5eb7d4c3c53fe1241d,6,"Auto merge of #76349 - Mark-Simulacrum:dl-llvm r=alexcrichton Download LLVM from CI to bootstrap (linux-only to start) This follows #76332 adding support for using CI-built LLVM rather than building it locally. This should essentially ""just work "" but is left off by default in this PR. While we can support downloading LLVM for multiple host triples this currently only downloads it for the build triple. That said it should be possible to expand this relatively easily should multiple host triples be desired. Most people shouldn't be adjusting host/target triples though so this should cover most use cases. Currently this downloads LLVM for the last bors-authored commit in the `git log`. This is a bit suboptimal -- we want the last bors-authored commit that touched the llvm-project submodule in basically all cases. But for now this just adds an extra ~20 MB download when rebasing atop latest master. Once we have a submodule bump landing after #76332 we can fix this behavior to reduce downloads further.",HEART,2020-10-07T08:54:18Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/76356,MERGED,2020-09-05T01:04:32Z,2020-10-06T17:08:04Z,Add a command to install a git hook to automatically run `x.py test tidy --bless`,caass,9fdaeb393a16951f6fdef087193fef576e36aba6,3,Auto merge of #76356 - caass:hooks r=jyn514 Add a command to install a git hook to automatically run `x.py test tidy --bless` Some folks (such as myself) would probably find a lot of convenience in a pre-commit hook that automatically runs tidy before committing to avoid burning CI time learning that your commit wasn't tidy. I'm absolutely positive I have missed some stuff. I basically just got this to where you can run `./x.py run install-git-hook` and then clicked the commit button. Please let me know what else you'd like me to add before this can be merged! [rustc-dev-guide companion PR](https://github.com/rust-lang/rustc-dev-guide/pull/848),THUMBS_UP,2020-10-04T01:17:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76370,MERGED,2020-09-05T12:10:39Z,2020-09-06T12:30:25Z,Fix dropck issue of SyncOnceCell.,m-ou-se,23e49ddafbe6765d117d3c7e2485d7ac73d9d79e,1,Auto merge of #76370 - fusion-engineering-forks:synconcecell-soundness r=nagisa Fix dropck issue of SyncOnceCell. Fixes #76367.,HEART,2020-09-05T12:16:31Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76370,MERGED,2020-09-05T12:10:39Z,2020-09-06T12:30:25Z,Fix dropck issue of SyncOnceCell.,m-ou-se,23e49ddafbe6765d117d3c7e2485d7ac73d9d79e,1,Auto merge of #76370 - fusion-engineering-forks:synconcecell-soundness r=nagisa Fix dropck issue of SyncOnceCell. Fixes #76367.,HEART,2020-09-05T16:16:21Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76370,MERGED,2020-09-05T12:10:39Z,2020-09-06T12:30:25Z,Fix dropck issue of SyncOnceCell.,m-ou-se,23e49ddafbe6765d117d3c7e2485d7ac73d9d79e,1,Auto merge of #76370 - fusion-engineering-forks:synconcecell-soundness r=nagisa Fix dropck issue of SyncOnceCell. Fixes #76367.,HEART,2020-09-06T09:02:17Z,pitdicker,NA https://github.com/rust-lang/rust/pull/76376,MERGED,2020-09-05T14:28:38Z,2020-09-05T17:18:20Z,Rollup of 11 pull requests,Dylan-DPC-zz,7d289aeade481c03d42e7f6d31bc6b64a73cfa45,31,Auto merge of #76376 - Dylan-DPC:rollup-8chsbw9 r=Dylan-DPC Rollup of 11 pull requests Successful merges: - #75695 (Add a regression test for issue-72793) - #75741 (Refactor byteorder to std in rustc_middle) - #75954 (Unstable Book: add links to tracking issues for FFI features) - #75994 (`impl Rc::new_cyclic`) - #76060 (Link vec doc to & reference) - #76078 (Remove disambiguators from intra doc link text) - #76082 (Fix intra-doc links on pub re-exports) - #76254 (Fold length constant in Rvalue::Repeat) - #76258 (x.py check checks tests/examples/benches) - #76263 (inliner: Check for codegen fn attributes compatibility) - #76285 (Move jointness censoring to proc_macro) Failed merges: r? @ghost,HOORAY,2020-09-06T02:34:12Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76381,MERGED,2020-09-05T17:55:55Z,2020-09-11T08:40:21Z,rustbuild: Do not use `rust-mingw` component when bootstrapping windows-gnu targets,petrochenkov,f5b7dd8181b0f483a890f8f3c19d08d6de03a444,1,Auto merge of #76381 - petrochenkov:nomingwcomp r=Mark-Simulacrum rustbuild: Do not use `rust-mingw` component when bootstrapping windows-gnu targets Addresses https://github.com/rust-lang/rust/pull/76326#issuecomment-687273473 (ancient `x86_64-w64-mingw32-gcc` is selected as a linker wrapper which is not usable in `use_lld=true` mode). Perhaps the comment about incompatible mingw was true in the past but many things changed since then. With this change I was able to build everything successfully locally using a newer mingw toolchain if it passes through the older toolchain on CI then it should be good I think.,THUMBS_UP,2020-09-07T06:53:39Z,mati865,NA https://github.com/rust-lang/rust/pull/76385,MERGED,2020-09-05T19:05:28Z,2020-09-06T01:47:23Z,Update RLS and Rustfmt,calebcartwright,d39b076489a8686961204721001ccd9a9e9a5e0a,4,Auto merge of #76385 - calebcartwright:update-rls-rustfmt r=Xanewok Update RLS and Rustfmt Fixes #76145 and fixes #76146 cc @Xanewok @topecongiro,HEART,2020-09-06T01:50:35Z,topecongiro,topecongiro@fastmail.com https://github.com/rust-lang/rust/pull/76394,CLOSED,2020-09-05T23:40:04Z,2020-09-06T13:20:16Z,Rollup of 11 pull requests,Dylan-DPC-zz,NA,NA,NA,HEART,2020-09-05T23:49:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76420,MERGED,2020-09-06T19:45:06Z,2020-09-16T20:18:52Z,Add aarch64-unknown-linux-musl host builds,Gelbpunkt,ff806b87167a9b4f38b9e3d2f6e9c4e621df6a77,5,"Auto merge of #76420 - Gelbpunkt:aarch64-linux-musl r=pietroalbini Add aarch64-unknown-linux-musl host builds This adds aarch64-unknown-linux-musl to the hosts list and adds the build to the dist-arm-linux builder as `@Mark-Simulacrum` suggested to me in Zulip. `@jyn514` requested to be mentioned :smile: I had to update the config for crosstool-ng as it had a prompt about the glibc version. I ran `src/ci/docker/run.sh dist-arm-linux` to test it. ``` Build completed successfully in 1:31:50 Compile requests 8180 Compile requests executed 8135 Cache hits 287 Cache misses 7848 Cache timeouts 0 Cache read errors 0 Forced recaches 0 Cache write errors 0 Compilation failures 0 Cache errors 0 Non-cacheable compilations 0 Non-cacheable calls 36 Non-compilation calls 9 Unsupported compiler calls 0 Average cache write 0.000 s Average cache read miss 6.389 s Average cache read hit 0.000 s Cache location Local disk: ""/sccache"" Cache size 202 MiB Max cache size 10 GiB == clock drift check == local time: Sun Sep 6 19:30:17 UTC 2020 network time: Sun 06 Sep 2020 19:30:17 GMT == end clock drift check == ``` Only errors were in miri due to struct fields being private (already been reported [here](https://github.com/rust-lang/rust/issues/76337)) Edit: Maybe it is helpful if I add that it is a working compiler ```sh /rust-nightly-aarch64-unknown-linux-musl # ash install.sh install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh install: installing component 'rustc' install: installing component 'cargo' install: installing component 'rls-preview' install: installing component 'rust-analyzer-preview' install: installing component 'clippy-preview' install: installing component 'rustfmt-preview' install: installing component 'llvm-tools-preview' install: installing component 'rust-analysis-aarch64-unknown-linux-musl' install: installing component 'rust-std-aarch64-unknown-linux-musl' install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error Rust is ready to roll. / # cat test.rs fn main() { println!(""hello world""); } / # rustc test.rs / # ./test hello world # file test test: ELF 64-bit LSB executable ARM aarch64 version 1 (SYSV) statically linked not stripped ```",HOORAY,2020-09-17T22:08:02Z,yerke,NA https://github.com/rust-lang/rust/pull/76423,MERGED,2020-09-06T23:45:12Z,2020-09-08T09:11:47Z,Make bootstrap build on beta,Mark-Simulacrum,35fc8359868e65a0970094f648ba87fce634e8c7,3,"Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap r=jyn514 Make bootstrap build on beta This is generally a good idea and will help with being able to build bootstrap without Python over time as it means we can ""just"" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step but a necessary one on that road. r? `@jyn514`",HEART,2020-09-07T00:07:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76423,MERGED,2020-09-06T23:45:12Z,2020-09-08T09:11:47Z,Make bootstrap build on beta,Mark-Simulacrum,35fc8359868e65a0970094f648ba87fce634e8c7,3,"Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap r=jyn514 Make bootstrap build on beta This is generally a good idea and will help with being able to build bootstrap without Python over time as it means we can ""just"" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step but a necessary one on that road. r? `@jyn514`",HEART,2020-09-07T00:15:43Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76423,MERGED,2020-09-06T23:45:12Z,2020-09-08T09:11:47Z,Make bootstrap build on beta,Mark-Simulacrum,35fc8359868e65a0970094f648ba87fce634e8c7,3,"Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap r=jyn514 Make bootstrap build on beta This is generally a good idea and will help with being able to build bootstrap without Python over time as it means we can ""just"" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step but a necessary one on that road. r? `@jyn514`",HEART,2020-09-07T06:46:07Z,mati865,NA https://github.com/rust-lang/rust/pull/76423,MERGED,2020-09-06T23:45:12Z,2020-09-08T09:11:47Z,Make bootstrap build on beta,Mark-Simulacrum,35fc8359868e65a0970094f648ba87fce634e8c7,3,"Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap r=jyn514 Make bootstrap build on beta This is generally a good idea and will help with being able to build bootstrap without Python over time as it means we can ""just"" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step but a necessary one on that road. r? `@jyn514`",HEART,2020-09-11T12:17:31Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76423,MERGED,2020-09-06T23:45:12Z,2020-09-08T09:11:47Z,Make bootstrap build on beta,Mark-Simulacrum,35fc8359868e65a0970094f648ba87fce634e8c7,3,"Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap r=jyn514 Make bootstrap build on beta This is generally a good idea and will help with being able to build bootstrap without Python over time as it means we can ""just"" build with cargo +beta build rather than needing the user to set environment variables. This is a minor step but a necessary one on that road. r? `@jyn514`",HEART,2020-09-12T01:27:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76443,CLOSED,2020-09-07T13:10:56Z,2020-10-12T21:12:54Z,Add format specifier suggestion,macdonaldo,NA,NA,NA,HEART,2020-09-08T02:01:17Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76443,CLOSED,2020-09-07T13:10:56Z,2020-10-12T21:12:54Z,Add format specifier suggestion,macdonaldo,NA,NA,NA,THUMBS_UP,2020-09-12T00:02:29Z,estebank,NA https://github.com/rust-lang/rust/pull/76448,MERGED,2020-09-07T14:34:39Z,2020-10-04T11:03:46Z,Implement Make `handle_alloc_error` default to panic (for no_std + liballoc),haraldh,0d37dca25a51fb900a402c94c8818ad1c2789e30,12,Auto merge of #76448 - haraldh:default_alloc_error_handler_reduced r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: https://github.com/rust-lang/rust/issues/66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.,HOORAY,2020-09-15T21:31:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76448,MERGED,2020-09-07T14:34:39Z,2020-10-04T11:03:46Z,Implement Make `handle_alloc_error` default to panic (for no_std + liballoc),haraldh,0d37dca25a51fb900a402c94c8818ad1c2789e30,12,Auto merge of #76448 - haraldh:default_alloc_error_handler_reduced r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: https://github.com/rust-lang/rust/issues/66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.,HOORAY,2020-10-05T08:39:53Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/76448,MERGED,2020-09-07T14:34:39Z,2020-10-04T11:03:46Z,Implement Make `handle_alloc_error` default to panic (for no_std + liballoc),haraldh,0d37dca25a51fb900a402c94c8818ad1c2789e30,12,Auto merge of #76448 - haraldh:default_alloc_error_handler_reduced r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: https://github.com/rust-lang/rust/issues/66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.,HOORAY,2020-10-08T12:49:32Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/76448,MERGED,2020-09-07T14:34:39Z,2020-10-04T11:03:46Z,Implement Make `handle_alloc_error` default to panic (for no_std + liballoc),haraldh,0d37dca25a51fb900a402c94c8818ad1c2789e30,12,Auto merge of #76448 - haraldh:default_alloc_error_handler_reduced r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: https://github.com/rust-lang/rust/issues/66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.,HOORAY,2020-10-10T15:26:40Z,tux3,NA https://github.com/rust-lang/rust/pull/76448,MERGED,2020-09-07T14:34:39Z,2020-10-04T11:03:46Z,Implement Make `handle_alloc_error` default to panic (for no_std + liballoc),haraldh,0d37dca25a51fb900a402c94c8818ad1c2789e30,12,Auto merge of #76448 - haraldh:default_alloc_error_handler_reduced r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: https://github.com/rust-lang/rust/issues/66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.,HOORAY,2022-02-12T21:42:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76458,MERGED,2020-09-07T23:30:14Z,2020-09-10T05:53:11Z,Add drain_filter method to HashMap and HashSet,mbrubeck,fa56cf537ffbb5a1614692422c4f0c728eea037f,11,Rollup merge of #76458 - mbrubeck:hash_drain_filter r=Amanieu Add drain_filter method to HashMap and HashSet Add `HashMap::drain_filter` and `HashSet::drain_filter` implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is #59618. The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter` except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`. This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`. (Both are themselves wrappers around `hashbrown::HashMap` so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change we would need to duplicate much more code to implement `HashSet::drain_filter`. This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0 whose only change is compatibility with `hashbrown` 0.9.0.,THUMBS_UP,2020-09-08T10:06:19Z,DutchGhost,NA https://github.com/rust-lang/rust/pull/76458,MERGED,2020-09-07T23:30:14Z,2020-09-10T05:53:11Z,Add drain_filter method to HashMap and HashSet,mbrubeck,fa56cf537ffbb5a1614692422c4f0c728eea037f,11,Rollup merge of #76458 - mbrubeck:hash_drain_filter r=Amanieu Add drain_filter method to HashMap and HashSet Add `HashMap::drain_filter` and `HashSet::drain_filter` implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is #59618. The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter` except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`. This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`. (Both are themselves wrappers around `hashbrown::HashMap` so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change we would need to duplicate much more code to implement `HashSet::drain_filter`. This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0 whose only change is compatibility with `hashbrown` 0.9.0.,THUMBS_UP,2020-09-10T12:52:49Z,marmeladema,NA https://github.com/rust-lang/rust/pull/76458,MERGED,2020-09-07T23:30:14Z,2020-09-10T05:53:11Z,Add drain_filter method to HashMap and HashSet,mbrubeck,fa56cf537ffbb5a1614692422c4f0c728eea037f,11,Rollup merge of #76458 - mbrubeck:hash_drain_filter r=Amanieu Add drain_filter method to HashMap and HashSet Add `HashMap::drain_filter` and `HashSet::drain_filter` implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is #59618. The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter` except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`. This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`. (Both are themselves wrappers around `hashbrown::HashMap` so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change we would need to duplicate much more code to implement `HashSet::drain_filter`. This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0 whose only change is compatibility with `hashbrown` 0.9.0.,THUMBS_UP,2020-09-17T03:34:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76458,MERGED,2020-09-07T23:30:14Z,2020-09-10T05:53:11Z,Add drain_filter method to HashMap and HashSet,mbrubeck,fa56cf537ffbb5a1614692422c4f0c728eea037f,11,Rollup merge of #76458 - mbrubeck:hash_drain_filter r=Amanieu Add drain_filter method to HashMap and HashSet Add `HashMap::drain_filter` and `HashSet::drain_filter` implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is #59618. The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter` except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`. This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`. (Both are themselves wrappers around `hashbrown::HashMap` so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change we would need to duplicate much more code to implement `HashSet::drain_filter`. This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0 whose only change is compatibility with `hashbrown` 0.9.0.,THUMBS_UP,2020-09-21T20:27:11Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76468,MERGED,2020-09-08T05:33:26Z,2020-11-10T13:26:16Z,Improve lifetime name annotations for closures & async functions,SNCPlay42,99f16e637b47fb9de3b88e8df6dbc68be180cd96,7,"Rollup merge of #76468 - SNCPlay42:lifetime-names r=Mark-Simulacrum Improve lifetime name annotations for closures & async functions * Don't refer to async functions as ""generators"" in error output * Where possible emit annotations pointing exactly at the `&` in the return type of closures (when they have explicit return types) and async functions like we do for arguments. Addresses #74072 but I wouldn't call that *closed* until annotations are identical for async and non-async functions. * Emit a better annotation when the lifetime doesn't appear in the full name type which currently happens for opaque types like `impl Future`. Addresses #74497 but further improves could probably be made (why *doesn't* it appear in the type as `impl Future + '1`?) This is included in the same PR because the changes to `give_name_if_anonymous_region_appears_in_output` would introduce ICE otherwise (it would return `None` in cases where it didn't previously which then gets `unwrap`ped)",HEART,2020-12-17T05:37:43Z,tmandry,NA https://github.com/rust-lang/rust/pull/76474,MERGED,2020-09-08T11:59:57Z,2020-09-28T20:15:52Z,Add option to pass a custom codegen backend from a driver,bjorn3,6a8cdbd285eca75024809ac12b8badb7f38128b7,8,Rollup merge of #76474 - bjorn3:driver_selected_codegen r=oli-obk Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri),HEART,2020-09-08T12:16:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76474,MERGED,2020-09-08T11:59:57Z,2020-09-28T20:15:52Z,Add option to pass a custom codegen backend from a driver,bjorn3,6a8cdbd285eca75024809ac12b8badb7f38128b7,8,Rollup merge of #76474 - bjorn3:driver_selected_codegen r=oli-obk Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri),HEART,2020-09-08T12:40:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/76474,MERGED,2020-09-08T11:59:57Z,2020-09-28T20:15:52Z,Add option to pass a custom codegen backend from a driver,bjorn3,6a8cdbd285eca75024809ac12b8badb7f38128b7,8,Rollup merge of #76474 - bjorn3:driver_selected_codegen r=oli-obk Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri),HEART,2020-09-21T13:54:20Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76474,MERGED,2020-09-08T11:59:57Z,2020-09-28T20:15:52Z,Add option to pass a custom codegen backend from a driver,bjorn3,6a8cdbd285eca75024809ac12b8badb7f38128b7,8,Rollup merge of #76474 - bjorn3:driver_selected_codegen r=oli-obk Add option to pass a custom codegen backend from a driver This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process. This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen. cc @nbaksalyar (headcrab) cc @RalfJung (miri),HEART,2020-09-29T10:53:43Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/76481,MERGED,2020-09-08T15:46:24Z,2020-09-10T00:10:56Z,Convert repetitive target_pointer_width checks to const solution.,moonheart08,0d20cf8568114986c4ed8eddcb91c5a998383ad7,1,Rollup merge of #76481 - moonheart08:vec_deque_constify r=sfackler Convert repetitive target_pointer_width checks to const solution. Simply a quick code tidying change. Not sure if more needs to be said.,THUMBS_UP,2020-09-08T16:28:59Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/76485,MERGED,2020-09-08T17:24:22Z,2020-09-26T12:20:41Z,Point at named argument not found when using `format_args_capture` instead of whole format string,estebank,6f9a8a7f9b9732c55511d2a2a3914e8feafc7c52,3,Auto merge of #76485 - estebank:format_arg_capture_spans r=davidtwco Point at named argument not found when using `format_args_capture` instead of whole format string,THUMBS_UP,2020-09-08T18:01:45Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-08T19:52:26Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-08T19:55:31Z,moonheart08,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-08T20:32:03Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-08T22:09:30Z,mati865,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-09T09:47:08Z,CryZe,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-09T21:56:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-20T20:45:43Z,tavianator,tavianator@tavianator.com https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-09-28T20:52:55Z,myrrlyn,self@myrrlyn.dev https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-10-01T06:55:58Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-10-03T00:35:07Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-10-06T20:03:27Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2020-12-14T20:10:47Z,wcampbell0x2a,wcampbell1995@gmail.com https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-01-02T16:25:07Z,ryanavella,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-01-04T06:20:45Z,nashley,nick@shley.us https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-01-29T03:09:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-02-05T05:41:31Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-03-02T00:01:42Z,yannbolliger,yann@bolliger.io https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-03-12T15:31:02Z,mkj,matt@ucc.asn.au https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-03-19T11:13:33Z,dhardy,github1@dhardy.name https://github.com/rust-lang/rust/pull/76492,MERGED,2020-09-08T19:40:33Z,2020-09-19T13:32:04Z,Add associated constant `BITS` to all integer types,m-ou-se,fef332404341e89e4fe09416d01d82a99f7e8c5f,18,Rollup merge of #76492 - fusion-engineering-forks:int-bits r=dtolnay Add associated constant `BITS` to all integer types Recently I've regularly come across this snippet (in a few different crates including `core` and `std`): ```rust std::mem::size_of() * 8 ``` I think it's time for a `usize::BITS`.,THUMBS_UP,2021-05-24T23:34:15Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/76493,MERGED,2020-09-08T20:01:29Z,2020-09-10T00:10:53Z,Remove a stray ignore-tidy-undocumented-unsafe,moonheart08,342b40628542a5a505e4ac0a8e747edad99a2081,1,Rollup merge of #76493 - moonheart08:unique-quick r=jyn514 Remove a stray ignore-tidy-undocumented-unsafe There were no undocumented unsafe blocks in the file. This shouldn't require any special review.,THUMBS_UP,2020-09-08T20:59:26Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76499,MERGED,2020-09-08T22:20:18Z,2020-09-11T21:54:40Z,Give better diagnostic when using a private tuple struct constructor,guswynn,bc57bd8c7e3e28f8bed4fced3973bfe04949918f,9,Auto merge of #76499 - guswynn:priv_des r=petrochenkov Give better diagnostic when using a private tuple struct constructor Fixes #75907 Some notes: 1. This required some deep changes including removing a Copy impl for PatKind. If some tests fail I would still appreciate review on the overall approach 2. this only works with basic patterns (no wildcards for example) and fails if there is any problems getting the visibility of the fields (i am not sure what the failure that can happen in resolve_visibility_speculative but we check the length of our fields in both cases against each other so if anything goes wrong we fall back to the worse error. This could be extended to more patterns 3. this does not yet deal with #75906 but I believe it will be similar 4. let me know if you want more tests 5. doesn't yet at the suggestion that `@yoshuawuyts` suggested at the end of their issue but that could be added relatively easily (i believe),THUMBS_UP,2020-09-08T22:39:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76499,MERGED,2020-09-08T22:20:18Z,2020-09-11T21:54:40Z,Give better diagnostic when using a private tuple struct constructor,guswynn,bc57bd8c7e3e28f8bed4fced3973bfe04949918f,9,Auto merge of #76499 - guswynn:priv_des r=petrochenkov Give better diagnostic when using a private tuple struct constructor Fixes #75907 Some notes: 1. This required some deep changes including removing a Copy impl for PatKind. If some tests fail I would still appreciate review on the overall approach 2. this only works with basic patterns (no wildcards for example) and fails if there is any problems getting the visibility of the fields (i am not sure what the failure that can happen in resolve_visibility_speculative but we check the length of our fields in both cases against each other so if anything goes wrong we fall back to the worse error. This could be extended to more patterns 3. this does not yet deal with #75906 but I believe it will be similar 4. let me know if you want more tests 5. doesn't yet at the suggestion that `@yoshuawuyts` suggested at the end of their issue but that could be added relatively easily (i believe),THUMBS_UP,2020-09-11T17:37:36Z,estebank,NA https://github.com/rust-lang/rust/pull/76500,MERGED,2020-09-08T23:14:34Z,2020-09-10T05:53:05Z,Add -Zgraphviz_dark_mode and monospace font fix,richkadel,ba6e2b3a31c3f63db69880b8d74eae3faf73947d,5,"Rollup merge of #76500 - richkadel:mir-graphviz-dark r=tmandry Add -Zgraphviz_dark_mode and monospace font fix Many developers use a dark theme with editors and IDEs but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs. Also fixed the monospace font for common graphviz renders (e.g. VS Code extensions) as described in https://github.com/rust-lang/rust/pull/76500#issuecomment-689837948 **Before:** **Now with fix:** ",HEART,2020-09-09T23:39:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/76500,MERGED,2020-09-08T23:14:34Z,2020-09-10T05:53:05Z,Add -Zgraphviz_dark_mode and monospace font fix,richkadel,ba6e2b3a31c3f63db69880b8d74eae3faf73947d,5,"Rollup merge of #76500 - richkadel:mir-graphviz-dark r=tmandry Add -Zgraphviz_dark_mode and monospace font fix Many developers use a dark theme with editors and IDEs but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs. Also fixed the monospace font for common graphviz renders (e.g. VS Code extensions) as described in https://github.com/rust-lang/rust/pull/76500#issuecomment-689837948 **Before:** **Now with fix:** ",HEART,2020-09-10T00:16:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-09-09T12:09:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,LAUGH,2020-09-09T12:55:17Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-09-09T15:11:54Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,LAUGH,2020-09-09T22:51:53Z,mati865,NA https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,LAUGH,2020-09-10T06:48:31Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,HEART,2020-09-10T06:48:33Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,HOORAY,2020-09-10T12:06:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,LAUGH,2020-09-10T14:05:39Z,eduardobull,eduardo.bull@gmail.com https://github.com/rust-lang/rust/pull/76516,MERGED,2020-09-09T11:55:51Z,2020-09-10T00:10:49Z,Enable GitHub Releases synchronization,pietroalbini,09a364e9842d3a2852a10664bd0989fdbb82fdde,1,Rollup merge of #76516 - pietroalbini:github-releases r=Mark-Simulacrum Enable GitHub Releases synchronization This PR enables the triagebot feature to automatically populate [GitHub Releases](https://github.com/rust-lang/rust/releases) for this repository based on the changelog. See https://github.com/rust-lang/triagebot/pull/811 for the implementation of this feature on triagebot's side and more insights on how it works. Note: once this lands people subscribed to the ~~firehose~~ rust-lang/rust repository will probably receive a ton of notifications for all the releases being created but this should be a one-time thing. r? @Mark-Simulacrum cc @rust-lang/release,LAUGH,2020-09-10T14:08:12Z,dyc3,NA https://github.com/rust-lang/rust/pull/76523,MERGED,2020-09-09T15:04:05Z,2020-09-10T00:10:46Z,Remove unused PlaceContext::NonUse(NonUseContext::Coverage),tmiasko,32714eb6bc3cbfe48774e85472ad8431fba3c7c8,3,Rollup merge of #76523 - tmiasko:non-use-context-coverage r=wesleywiser Remove unused PlaceContext::NonUse(NonUseContext::Coverage) r? @richkadel / @wesleywiser,HEART,2020-09-09T15:45:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/76524,MERGED,2020-09-09T15:04:30Z,2020-09-10T21:26:08Z,typeck: don't suggest inaccessible private fields,davidtwco,9f8a7827a111140f112a424f8bf8f36740865fbd,7,Rollup merge of #76524 - davidtwco:issue-76077-inaccessible-private-fields r=estebank typeck: don't suggest inaccessible private fields Fixes #76077. This PR adjusts the missing field diagnostic logic in typeck so that when none of the missing fields in a struct expr are accessible then the error is less confusing. r? @estebank,HEART,2020-09-10T17:46:40Z,estebank,NA https://github.com/rust-lang/rust/pull/76524,MERGED,2020-09-09T15:04:30Z,2020-09-10T21:26:08Z,typeck: don't suggest inaccessible private fields,davidtwco,9f8a7827a111140f112a424f8bf8f36740865fbd,7,Rollup merge of #76524 - davidtwco:issue-76077-inaccessible-private-fields r=estebank typeck: don't suggest inaccessible private fields Fixes #76077. This PR adjusts the missing field diagnostic logic in typeck so that when none of the missing fields in a struct expr are accessible then the error is less confusing. r? @estebank,HEART,2020-09-10T23:47:43Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76533,CLOSED,2020-09-09T18:54:11Z,2020-09-24T13:53:33Z,Use a separate workspace for the library crates,bjorn3,NA,NA,NA,HEART,2020-09-09T19:03:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76533,CLOSED,2020-09-09T18:54:11Z,2020-09-24T13:53:33Z,Use a separate workspace for the library crates,bjorn3,NA,NA,NA,HEART,2020-09-11T01:48:42Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76533,CLOSED,2020-09-09T18:54:11Z,2020-09-24T13:53:33Z,Use a separate workspace for the library crates,bjorn3,NA,NA,NA,HEART,2020-09-13T07:37:02Z,Luro02,NA https://github.com/rust-lang/rust/pull/76533,CLOSED,2020-09-09T18:54:11Z,2020-09-24T13:53:33Z,Use a separate workspace for the library crates,bjorn3,NA,NA,NA,HEART,2020-09-21T05:15:54Z,lnicola,NA https://github.com/rust-lang/rust/pull/76538,MERGED,2020-09-09T20:35:17Z,2020-09-12T19:56:19Z,Warn for #[unstable] on trait impls when it has no effect.,m-ou-se,989190874fe2a0e9877ce4f02a6c60641e3d42a3,7,"Auto merge of #76538 - fusion-engineering-forks:check-useless-unstable-trait-impl r=lcnr Warn for #[unstable] on trait impls when it has no effect. Earlier today I sent a PR with an `#[unstable]` attribute on a trait `impl` but was informed that this attribute has no effect there. (comment: https://github.com/rust-lang/rust/pull/76525#issuecomment-689678895 issue: https://github.com/rust-lang/rust/issues/55436) This PR adds a warning for this situation. Trait `impl` blocks with `#[unstable]` where both the type and the trait are stable will result in a warning: ``` warning: An `#[unstable]` annotation here has no effect. See issue #55436 for more information. --> library/std/src/panic.rs:235:1 | 235 | #[unstable(feature = ""integer_atomics"" issue = ""32976"")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` --- It detects three problems in the existing code: 1. A few `RefUnwindSafe` implementations for the atomic integer types in `library/std/src/panic.rs`. Example: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/panic.rs#L235-L236 2. An implementation of `Error` for `LayoutErr` in `library/std/srd/error.rs`: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/error.rs#L392-L397 3. `From` implementations for `Waker` and `RawWaker` in `library/alloc/src/task.rs`. Example: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/alloc/src/task.rs#L36-L37 Case 3 interesting: It has a bound with an `#[unstable]` trait (`W: Wake`) so appears to have much effect on stable code. It does however break similar blanket implementations. It would also have immediate effect if `Wake` was implemented for any stable type. (Which is not the case right now but there are no warnings in place to prevent it.) Whether this case is a problem or not is not clear to me. If it isn't adding a simple `c.visit_generics(..);` to this PR will stop the warning for this case.",HEART,2020-09-10T00:25:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/76538,MERGED,2020-09-09T20:35:17Z,2020-09-12T19:56:19Z,Warn for #[unstable] on trait impls when it has no effect.,m-ou-se,989190874fe2a0e9877ce4f02a6c60641e3d42a3,7,"Auto merge of #76538 - fusion-engineering-forks:check-useless-unstable-trait-impl r=lcnr Warn for #[unstable] on trait impls when it has no effect. Earlier today I sent a PR with an `#[unstable]` attribute on a trait `impl` but was informed that this attribute has no effect there. (comment: https://github.com/rust-lang/rust/pull/76525#issuecomment-689678895 issue: https://github.com/rust-lang/rust/issues/55436) This PR adds a warning for this situation. Trait `impl` blocks with `#[unstable]` where both the type and the trait are stable will result in a warning: ``` warning: An `#[unstable]` annotation here has no effect. See issue #55436 for more information. --> library/std/src/panic.rs:235:1 | 235 | #[unstable(feature = ""integer_atomics"" issue = ""32976"")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` --- It detects three problems in the existing code: 1. A few `RefUnwindSafe` implementations for the atomic integer types in `library/std/src/panic.rs`. Example: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/panic.rs#L235-L236 2. An implementation of `Error` for `LayoutErr` in `library/std/srd/error.rs`: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/std/src/error.rs#L392-L397 3. `From` implementations for `Waker` and `RawWaker` in `library/alloc/src/task.rs`. Example: https://github.com/rust-lang/rust/blob/d92155bf6ae0b7d79fc83cbeeb0cc0c765353471/library/alloc/src/task.rs#L36-L37 Case 3 interesting: It has a bound with an `#[unstable]` trait (`W: Wake`) so appears to have much effect on stable code. It does however break similar blanket implementations. It would also have immediate effect if `Wake` was implemented for any stable type. (Which is not the case right now but there are no warnings in place to prevent it.) Whether this case is a problem or not is not clear to me. If it isn't adding a simple `c.visit_generics(..);` to this PR will stop the warning for this case.",HEART,2020-09-12T01:43:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HEART,2020-09-09T22:53:21Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HOORAY,2020-09-09T22:53:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HEART,2020-09-10T06:54:57Z,mati865,NA https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HOORAY,2020-09-11T01:46:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HEART,2020-09-11T01:46:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HEART,2020-09-14T22:18:14Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HOORAY,2020-09-20T20:20:41Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HEART,2020-09-20T20:20:47Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76544,MERGED,2020-09-09T22:49:19Z,2020-09-21T00:13:47Z,De-couple Python and bootstrap slightly,Mark-Simulacrum,7467d17bb94d388a056526dd143ce43612296ce6,9,Auto merge of #76544 - Mark-Simulacrum:less-python r=alexcrichton De-couple Python and bootstrap slightly This revises rustbuild's entry points from Python to rely less on magic environment variables preferring to use Cargo-provided environment variables where feasible. Notably BUILD_DIR and BOOTSTRAP_CONFIG are *not* moved because both more-or-less have some non-trivial discovery logic and replicating it in rustbuild seems unfortunate; if it moved to Cargo that would be a different story. Best reviewed by-commit.,HOORAY,2020-09-21T03:18:50Z,tmandry,NA https://github.com/rust-lang/rust/pull/76552,CLOSED,2020-09-10T01:58:17Z,2020-10-28T04:10:54Z,Optimize option clone,ridiculousfish,NA,NA,NA,EYES,2020-09-10T07:56:50Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76552,CLOSED,2020-09-10T01:58:17Z,2020-10-28T04:10:54Z,Optimize option clone,ridiculousfish,NA,NA,NA,EYES,2020-09-22T11:17:24Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/76559,MERGED,2020-09-10T07:01:01Z,2020-09-10T21:26:02Z,add the `const_evaluatable_checked` feature,lcnr,ac85a4d71eaf73ad0b729dbdbbf3623695c2dd6f,9,Rollup merge of #76559 - lcnr:const-evaluatable r=oli-obk add the `const_evaluatable_checked` feature Implements a rather small subset of https://github.com/rust-lang/compiler-team/issues/340 Unlike the MCP this does not try to compare different constant but instead only adds the constants found in where clauses to the predicates of a function. This PR adds the feature gate `const_evaluatable_checked` without which nothing should change. r? @oli-obk @eddyb,HEART,2020-09-13T13:02:01Z,varkor,NA https://github.com/rust-lang/rust/pull/76564,MERGED,2020-09-10T11:07:00Z,2020-09-10T18:32:51Z,ci: avoid moving the build directory on GHA,pietroalbini,8c35a9279ca50d3e5a6f33d80a7191454fd89cbe,1,Auto merge of #76564 - pietroalbini:ci-avoid-wasting-10-minutes r=Mark-Simulacrum ci: avoid moving the build directory on GHA While waiting for a PR job to start testing my code I noticed the symlink-build-dir step took 10 minutes to complete so I investigated what caused that. It seems like something changed in the build environment between version 20200901.1 (where the step took 45 seconds) and version 20200908.1 (where the step took 10 minutes). At the time of writing this commit the rust-lang organization is on vertsion 20200908.1 while the rust-lang-ci organization is at version 20200901.1 (and is not affected by this yet). There is no need for this step anymore on GHA as our XL builders got an increase in the root paritition size so this commit removes the code that moved stuff around on GHA (while keeping it on Azure). For the record at the time of writing this the disk situation is: ``` Filesystem Size Used Avail Use% Mounted on /dev/sda1 667G 60G 607G 9% / /dev/sdb1 110G 4.1G 101G 4% /mnt ``` r? `@Mark-Simulacrum`,LAUGH,2020-09-10T15:14:41Z,mati865,NA https://github.com/rust-lang/rust/pull/76569,CLOSED,2020-09-10T12:56:57Z,2020-09-15T14:32:28Z,Online def-use analysis for copy propagation pass,tmiasko,NA,NA,NA,HEART,2020-09-10T13:46:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/76569,CLOSED,2020-09-10T12:56:57Z,2020-09-15T14:32:28Z,Online def-use analysis for copy propagation pass,tmiasko,NA,NA,NA,HEART,2020-09-10T15:33:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76569,CLOSED,2020-09-10T12:56:57Z,2020-09-15T14:32:28Z,Online def-use analysis for copy propagation pass,tmiasko,NA,NA,NA,HEART,2020-09-10T18:37:57Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/76569,CLOSED,2020-09-10T12:56:57Z,2020-09-15T14:32:28Z,Online def-use analysis for copy propagation pass,tmiasko,NA,NA,NA,HEART,2020-09-11T07:33:38Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",EYES,2020-09-10T17:35:17Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2020-09-10T21:59:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",EYES,2020-09-14T15:38:01Z,macpp,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2020-12-05T12:37:41Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",EYES,2020-12-07T07:09:26Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2020-12-07T07:09:28Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2020-12-24T07:19:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2021-01-02T04:09:39Z,etaoins,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2021-01-26T18:36:57Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2021-02-26T00:58:23Z,sunjay,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2021-03-12T03:49:11Z,DianaNites,NA https://github.com/rust-lang/rust/pull/76570,MERGED,2020-09-10T13:19:04Z,2021-03-10T19:13:00Z,"Implement RFC 2945: ""C-unwind"" ABI ",cratelyn,17a07d71bfd692f9b2dad2a566aff52bf3d4bfe2,43,"Auto merge of #76570 - cratelyn:implement-rfc-2945-c-unwind-abi r=Amanieu Implement RFC 2945: ""C-unwind"" ABI ## Implement RFC 2945: ""C-unwind"" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is #74990. The feature gate for the issue is `#![feature(c_unwind)]`. This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19. ### Changes Further details will be provided in commit messages but a high-level overview of the changes follows: * A boolean `unwind` payload is added to the `C` `System` `Stdcall` and `Thiscall` variants marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind` `system-unwind` `stdcall-unwind` and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. * This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/` which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. * We adjust the `rustc_middle::ty::layout::fn_can_unwind` function used to compute whether or not a `FnAbi` object represents a function that should be able to unwind when `panic=unwind` is in use. * Changes are also made to `rustc_mir_build::build::should_abort_on_panic` so that the function ABI is used to determind whether it should abort assuming that the `panic=unwind` strategy is being used and no explicit unwind attribute was provided. [RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md",HOORAY,2021-03-15T11:04:28Z,daira,NA https://github.com/rust-lang/rust/pull/76575,MERGED,2020-09-10T16:16:19Z,2020-09-18T19:13:40Z,compare generic constants using `AbstractConst`s,lcnr,9f8ac718f44e280edb1a7b3266f2c26106ec11a0,29,Auto merge of #76575 - lcnr:abstract-const r=oli-obk compare generic constants using `AbstractConst`s This is a MVP of rust-lang/compiler-team#340. The changes in this PR should only be relevant if `feature(const_evaluatable_checked)` is enabled. ~~currently based on top of #76559 so blocked on that.~~ r? `@oli-obk` cc `@varkor` `@eddyb`,HOORAY,2020-09-10T19:02:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76575,MERGED,2020-09-10T16:16:19Z,2020-09-18T19:13:40Z,compare generic constants using `AbstractConst`s,lcnr,9f8ac718f44e280edb1a7b3266f2c26106ec11a0,29,Auto merge of #76575 - lcnr:abstract-const r=oli-obk compare generic constants using `AbstractConst`s This is a MVP of rust-lang/compiler-team#340. The changes in this PR should only be relevant if `feature(const_evaluatable_checked)` is enabled. ~~currently based on top of #76559 so blocked on that.~~ r? `@oli-obk` cc `@varkor` `@eddyb`,HOORAY,2020-09-12T18:48:45Z,varkor,NA https://github.com/rust-lang/rust/pull/76580,MERGED,2020-09-10T17:45:19Z,2021-01-12T05:51:47Z,Suggest async {} for async || {},rokob,467f5e99a541db94235f0c173bdffc8aeb177522,5,Auto merge of #76580 - rokob:iss76011 r=estebank Suggest async {} for async || {} Fixes #76011 This adds support for adding help diagnostics to the feature gating checks and then uses it for the async_closure gate to add the extra bit of help information as described in the issue.,THUMBS_UP,2020-09-11T17:40:37Z,estebank,NA https://github.com/rust-lang/rust/pull/76580,MERGED,2020-09-10T17:45:19Z,2021-01-12T05:51:47Z,Suggest async {} for async || {},rokob,467f5e99a541db94235f0c173bdffc8aeb177522,5,Auto merge of #76580 - rokob:iss76011 r=estebank Suggest async {} for async || {} Fixes #76011 This adds support for adding help diagnostics to the feature gating checks and then uses it for the async_closure gate to add the extra bit of help information as described in the issue.,THUMBS_UP,2020-10-15T04:03:52Z,trevyn,NA https://github.com/rust-lang/rust/pull/76580,MERGED,2020-09-10T17:45:19Z,2021-01-12T05:51:47Z,Suggest async {} for async || {},rokob,467f5e99a541db94235f0c173bdffc8aeb177522,5,Auto merge of #76580 - rokob:iss76011 r=estebank Suggest async {} for async || {} Fixes #76011 This adds support for adding help diagnostics to the feature gating checks and then uses it for the async_closure gate to add the extra bit of help information as described in the issue.,THUMBS_UP,2021-01-22T09:53:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76585,MERGED,2020-09-10T20:24:27Z,2020-09-13T07:21:40Z,Ignore `|` and `+` tokens during proc-macro pretty-print check,Aaron1011,dd33766e4a9a918058c3447d42491e874e21f7cc,5,Auto merge of #76585 - Aaron1011:ignore-vert-plus r=petrochenkov Ignore `|` and `+` tokens during proc-macro pretty-print check Fixes #76182 This is an alternative to PR #76188 These tokens are not preserved in the AST in certain cases (e.g. a leading `|` in a pattern or a trailing `+` in a trait bound). This PR ignores them entirely during the pretty-print/reparse check to avoid spuriously using the re-parsed tokenstream.,HEART,2020-09-13T17:17:48Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/76628,MERGED,2020-09-12T04:45:02Z,2020-09-21T12:52:53Z,Add sample defaults for config.toml ,jyn514,8fa75a2b3a7cb83f44a282ae671e0f1eb8e67a67,9,"Rollup merge of #76628 - jyn514:default-config-files r=Mark-Simulacrum Add sample defaults for config.toml - Allow including defaults in `src/bootstrap/defaults` using `profile = ""...""`. - Add default config files with a README noting they're experimental and asking you to open an issue if you run into trouble. The config files have comments explaining why the defaults are set. - Combine config files using the `merge` dependency. This introduces a new dependency on `merge` that hasn't yet been vetted. I want to improve the output when `include = ""x""` isn't found: ``` thread 'main' panicked at 'fs::read_to_string(&file) failed with No such file or directory (os error 2) (""configuration file did not exist"")' src/bootstrap/config.rs:522:28 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failed to run: /home/joshua/rustc/build/bootstrap/debug/bootstrap test tidy Build completed unsuccessfully in 0:00:00 ``` However that seems like it could be fixed in a follow-up. Closes #76619",HEART,2020-09-21T06:41:41Z,est31,NA https://github.com/rust-lang/rust/pull/76631,MERGED,2020-09-12T06:34:54Z,2020-09-26T19:53:44Z,Add `x.py setup`,jyn514,c39598aeea81c4147b9cff1dfde6bae95c9a38a4,8,Rollup merge of #76631 - jyn514:x.py-setup r=Mark-Simulacrum Add `x.py setup` Closes #76503. - Suggest `x.py setup` if config.toml doesn't exist yet - Prompt for a profile if not given on the command line - Print the configuration that will be used - Print helpful starting commands after setup - Link to the dev-guide after finishing,HEART,2020-10-06T20:44:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76635,MERGED,2020-09-12T08:18:07Z,2020-10-27T04:03:18Z,Add [T]::as_chunks(_mut),scottmcm,13e88d63662f682eb672ae21a99b4ca4ffffc7dd,2,Rollup merge of #76635 - scottmcm:slice-as-chunks r=LukasKalbertodt Add [T]::as_chunks(_mut) Allows getting the slices directly rather than just through an iterator as in `array_chunks(_mut)`. The constructors for those iterators are then written in terms of these methods so the iterator constructors no longer have any `unsafe` of their own. Unstable of course. #74985,THUMBS_UP,2020-09-15T18:21:25Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/76635,MERGED,2020-09-12T08:18:07Z,2020-10-27T04:03:18Z,Add [T]::as_chunks(_mut),scottmcm,13e88d63662f682eb672ae21a99b4ca4ffffc7dd,2,Rollup merge of #76635 - scottmcm:slice-as-chunks r=LukasKalbertodt Add [T]::as_chunks(_mut) Allows getting the slices directly rather than just through an iterator as in `array_chunks(_mut)`. The constructors for those iterators are then written in terms of these methods so the iterator constructors no longer have any `unsafe` of their own. Unstable of course. #74985,THUMBS_UP,2020-10-04T10:31:08Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/76635,MERGED,2020-09-12T08:18:07Z,2020-10-27T04:03:18Z,Add [T]::as_chunks(_mut),scottmcm,13e88d63662f682eb672ae21a99b4ca4ffffc7dd,2,Rollup merge of #76635 - scottmcm:slice-as-chunks r=LukasKalbertodt Add [T]::as_chunks(_mut) Allows getting the slices directly rather than just through an iterator as in `array_chunks(_mut)`. The constructors for those iterators are then written in terms of these methods so the iterator constructors no longer have any `unsafe` of their own. Unstable of course. #74985,THUMBS_UP,2022-06-13T15:03:05Z,robinhundt,NA https://github.com/rust-lang/rust/pull/76677,MERGED,2020-09-13T16:55:35Z,2020-09-14T00:26:41Z,note that test_stable_pointers does not reflect a stable guarantee,RalfJung,fe716d0447208825de8ddb815b31905d905950c7,1,Rollup merge of #76677 - RalfJung:stable-pointers r=jonas-schievink note that test_stable_pointers does not reflect a stable guarantee Just to be sure...,THUMBS_UP,2020-09-13T17:22:02Z,dylni,NA https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-09-13T20:07:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-09-13T23:47:28Z,nnethercote,NA https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-09-25T19:22:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-10-13T06:32:28Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-11-17T21:11:08Z,HactarCE,NA https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-11-19T17:54:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/76680,MERGED,2020-09-13T20:00:00Z,2020-09-21T19:52:42Z,Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines,Julian-Wollersberger,b01326ab033e41986d4a5c8b96ce4f40f3b38e30,2,"Auto merge of #76680 - Julian-Wollersberger:nongeneric_ensure_sufficient_stack r=jyn514 Make `ensure_sufficient_stack()` non-generic using cargo-llvm-lines Inspired by [this blog post](https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/) from `@nnethercote ` I used [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines/) on the rust compiler itself to improve it's compile time. This PR contains only one low-hanging fruit but I also want to share some measurements. The function `ensure_sufficient_stack()` was monomorphized 1500 times and with it the `stacker` and `psm` crates for a total of 1.5% of all llvm IR lines. With some trickery I convert the generic closure into a dynamic one and thus all that code is only monomorphized once. # Measurements Getting these numbers took some fiddling with CLI flags and I [modified](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/src/main.rs#L115) cargo-llvm-lines to read from a folder instead of invoking cargo. Commands I used: ``` ./x.py clean RUSTFLAGS=""--emit=llvm-ir -C link-args=-fuse-ld=lld -Z self-profile=profile"" CARGOFLAGS_BOOTSTRAP=""-Ztimings"" RUSTC_BOOTSTRAP=1 ./x.py build -i --stage 1 library/std # Then manually copy all .ll files into a folder I hardcoded in cargo-llvm-lines in main.rs#L115 cd ../cargo-llvm-lines cargo run llvm-lines ``` The result is this list (see [first 500 lines](https://github.com/Julian-Wollersberger/cargo-llvm-lines/blob/master/llvm-lines-rustc-before.txt) ) before the change: ``` Lines Copies Function name ----- ------ ------------- 16894211 (100%) 58417 (100%) (TOTAL) 2223855 (13.2%) 502 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (7.9%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 774434 (4.6%) 12043 (20.6%) core::ptr::drop_in_place 294170 (1.7%) 499 (0.9%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl 245410 (1.5%) 1552 (2.7%) psm::on_stack::with_on_stack 210311 (1.2%) 1 (0.0%) rustc_target::spec::load_specific 200962 (1.2%) 513 (0.9%) rustc_query_system::query::plumbing::get_query_impl 190704 (1.1%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings 180272 (1.1%) 468 (0.8%) rustc_query_system::query::plumbing::load_from_disk_and_cache_in_memory 177396 (1.1%) 114 (0.2%) rustc_query_system::query::plumbing::force_query_impl 161134 (1.0%) 445 (0.8%) rustc_query_system::dep_graph::graph::DepGraph::with_anon_task 141551 (0.8%) 186 (0.3%) rustc_query_system::query::plumbing::incremental_verify_ich 110191 (0.7%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} 108590 (0.6%) 420 (0.7%) core::ops::function::FnOnce::call_once 88488 (0.5%) 21 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::try_mark_previous_green 86368 (0.5%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats 85654 (0.5%) 3973 (6.8%) <&T as core::fmt::Debug>::fmt 84475 (0.5%) 1 (0.0%) rustc_middle::ty::query::Queries::try_collect_active_jobs 81220 (0.5%) 862 (1.5%) as core::iter::traits::iterator::Iterator>::next 77636 (0.5%) 54 (0.1%) core::slice::sort::recurse 66484 (0.4%) 461 (0.8%) as core::iter::traits::iterator::Iterator>::next ``` All `.ll` files together had 4.4GB. After my change they had 4.2GB. So a few percent less code LLVM has to process. Hurray! Sadly I couldn't measure an actual wall-time improvement. Watching YouTube while compiling added to much noise... Here is the top of the list after the change: ``` 16460866 (100%) 58341 (100%) (TOTAL) 1903085 (11.6%) 504 (0.9%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} 1331918 (8.1%) 1287 (2.2%) hashbrown::raw::RawTable::reserve_rehash 777796 (4.7%) 12031 (20.6%) core::ptr::drop_in_place 551462 (3.4%) 1519 (2.6%) rustc_data_structures::stack::ensure_sufficient_stack::{{closure}} ``` Note that the total was reduced by 430 000 lines and `psm::on_stack::with_on_stack` has disappeared. Instead `rustc_data_structures::stack::ensure_sufficient_stack::{{closure}}` appeared. I'm confused about that one but it seems to consist of inlined calls to `rustc_query_system::*` stuff. Further note the other two big culprits in this list: `rustc_query_system` and `hashbrown`. These two are monomorphized many times the query system summing to more than 20% of all lines not even counting code that's probably inlined elsewhere. Assuming compile times scale linearly with llvm-lines that means a possible 20% compile time reduction. Reducing eg. `get_query_impl` would probably need a major refactoring of the qery system though. _Everything_ in there is generic over multiple types has associated types and passes generic Self arguments by value. Which means you can't simply make things `dyn`. --------------------------------------- This PR is a small step to make rustc compile faster and thus make contributing to rustc less painful. Nonetheless I love Rust and I find the work around rustc fascinating :)",HEART,2020-11-26T12:44:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/76689,MERGED,2020-09-14T00:20:18Z,2020-09-16T03:06:43Z,Upgrade to pulldown-cmark 0.8.0,jyn514,1fd22fc34e52fa2c59b5acad216732cf774a87be,5,Rollup merge of #76689 - jyn514:update-pulldown r=GuillaumeGomez Upgrade to pulldown-cmark 0.8.0 Thanks to marcusklaas' hard work in https://github.com/raphlinus/pulldown-cmark/pull/469 this fixes a lot of rustdoc bugs! - Get rid of unnecessary `RefCell` - Fix duplicate warnings for broken implicit reference link - Remove unnecessary copy of links Closes https://github.com/rust-lang/rust/issues/73264 closes https://github.com/rust-lang/rust/issues/76687. r? @euclio I'm not sure if the switch away from `locate` fixes any open bugs - euclio mentioned some in https://github.com/raphlinus/pulldown-cmark/issues/165 but I didn't see any related issues open for rustdoc. Let me know if I missed one.,HOORAY,2020-09-16T08:38:35Z,marcusklaas,mail@marcusklaas.nl https://github.com/rust-lang/rust/pull/76695,MERGED,2020-09-14T04:13:41Z,2020-09-16T17:23:14Z,fix syntax error in suggesting generic constraint in trait parameter,iximeow,54d77285fcba0ab3d9d5ad8ff8a02bd6187bcf58,5,Rollup merge of #76695 - iximeow:trait-generic-bound-suggestion r=estebank fix syntax error in suggesting generic constraint in trait parameter suggest `where T: Foo` for the first bound on a trait then suggest ` T: Foo` when the suggested bound would add to an existing set of `where` clauses. `where T: Foo` may be the first bound if `T` has a default because we'd rather suggest ``` trait A where T: Copy ``` than ``` trait A ``` for legibility reasons. the test case i added here is derived from [this reproduction](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0bf3ace9f2a183d0bdbd748c6b8e3971): ``` struct B { t: T } trait A { fn returns_constrained_type(&self t: T) -> B { B { t } } } ``` where the suggested fix ``` trait A T: Copy { ... } ``` is in fact invalid syntax! i also found an error in the existing suggestion for `trait Base: Super` where rustc would suggest `trait Base: Super T: Copy` but `T: Copy` is the first of the trait's `where` clauses and should be `where T: Copy` as well. the test for that suggestion expects invalid syntax and has been revised to a compiler-pleasing `trait Base: Super where T: Copy`. judging by https://github.com/rust-lang/rust/pull/70009 i'll.. cc @estebank ?,HEART,2020-09-14T19:59:39Z,estebank,NA https://github.com/rust-lang/rust/pull/76699,MERGED,2020-09-14T07:49:35Z,2020-09-16T17:23:13Z,improve const infer error,lcnr,3f9e7fc0497a08983078cbe987af79f131da6419,11,Rollup merge of #76699 - lcnr:const-infer-err r=varkor improve const infer error cc #72328 reduces it from ``` error[E0282]: type annotations needed --> src/main.rs:17:5 | 17 | Foo.bar().bar().bar().bar().baz(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: unable to infer the value of a const parameter ``` to ``` error[E0282]: type annotations needed --> $DIR/method-chain.rs:21:33 | LL | Foo.bar().bar().bar().bar().baz(); | ^^^ | = note: cannot infer the value of the const parameter `N` ``` r? @varkor,HEART,2020-09-14T14:32:03Z,varkor,NA https://github.com/rust-lang/rust/pull/76699,MERGED,2020-09-14T07:49:35Z,2020-09-16T17:23:13Z,improve const infer error,lcnr,3f9e7fc0497a08983078cbe987af79f131da6419,11,Rollup merge of #76699 - lcnr:const-infer-err r=varkor improve const infer error cc #72328 reduces it from ``` error[E0282]: type annotations needed --> src/main.rs:17:5 | 17 | Foo.bar().bar().bar().bar().baz(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: unable to infer the value of a const parameter ``` to ``` error[E0282]: type annotations needed --> $DIR/method-chain.rs:21:33 | LL | Foo.bar().bar().bar().bar().baz(); | ^^^ | = note: cannot infer the value of the const parameter `N` ``` r? @varkor,HEART,2020-09-17T02:19:22Z,tesuji,NA https://github.com/rust-lang/rust/pull/76711,MERGED,2020-09-14T14:23:44Z,2020-09-28T20:15:45Z,diag: improve closure/generic parameter mismatch,davidtwco,88ae20d8aa44f1f0fadddfa5c529784732d7b101,4,Rollup merge of #76711 - davidtwco:issue-51154-param-closure r=estebank diag: improve closure/generic parameter mismatch Fixes #51154. This PR improves the diagnostic when a type parameter is expected and a closure is found noting that each closure has a distinct type and therefore could not always match the caller-chosen type of the parameter. r? @estebank,THUMBS_UP,2020-09-28T07:40:42Z,estebank,NA https://github.com/rust-lang/rust/pull/76711,MERGED,2020-09-14T14:23:44Z,2020-09-28T20:15:45Z,diag: improve closure/generic parameter mismatch,davidtwco,88ae20d8aa44f1f0fadddfa5c529784732d7b101,4,Rollup merge of #76711 - davidtwco:issue-51154-param-closure r=estebank diag: improve closure/generic parameter mismatch Fixes #51154. This PR improves the diagnostic when a type parameter is expected and a closure is found noting that each closure has a distinct type and therefore could not always match the caller-chosen type of the parameter. r? @estebank,THUMBS_UP,2020-12-17T23:01:21Z,TianyiShi2001,tianyi.shi@oriel.ox.ac.uk https://github.com/rust-lang/rust/pull/76721,MERGED,2020-09-14T22:39:49Z,2020-09-16T22:37:04Z,Use intra-doc links in `core::mem`,camelid,153fb91d374b3e054ab779952eb69c62022a9a80,1,Rollup merge of #76721 - camelid:intra-doc-links-for-core-mem r=jyn514 Use intra-doc links in `core::mem` Part of #75080. Last one for now! --- @rustbot modify labels: A-intra-doc-links T-doc,HOORAY,2020-09-14T22:59:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76721,MERGED,2020-09-14T22:39:49Z,2020-09-16T22:37:04Z,Use intra-doc links in `core::mem`,camelid,153fb91d374b3e054ab779952eb69c62022a9a80,1,Rollup merge of #76721 - camelid:intra-doc-links-for-core-mem r=jyn514 Use intra-doc links in `core::mem` Part of #75080. Last one for now! --- @rustbot modify labels: A-intra-doc-links T-doc,ROCKET,2020-09-14T22:59:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-15T02:19:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,ROCKET,2020-09-15T02:20:17Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-15T06:34:43Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,THUMBS_UP,2020-09-15T08:09:26Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-15T13:42:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-15T21:27:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-15T21:41:00Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,ROCKET,2020-09-18T10:32:31Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-18T20:09:34Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,ROCKET,2020-09-18T20:09:40Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,ROCKET,2020-09-21T10:12:23Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,THUMBS_UP,2020-09-21T10:12:25Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-09-21T10:12:26Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2020-10-22T22:16:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2021-01-01T23:37:02Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2021-01-06T02:08:03Z,camelid,NA https://github.com/rust-lang/rust/pull/76723,CLOSED,2020-09-15T00:39:36Z,2021-01-15T12:09:48Z,I can't stop writing copy propagation passes,jonas-schievink,NA,NA,NA,LAUGH,2021-01-13T00:55:00Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/76739,MERGED,2020-09-15T12:28:52Z,2020-10-02T21:45:37Z,resolve: prohibit anon const non-static lifetimes,davidtwco,c8eb2059dae70b99576352ded93592e6462daafc,4,Rollup merge of #76739 - davidtwco:issue-75323-non-static-lifetime-in-anonconst r=varkor resolve: prohibit anon const non-static lifetimes Fixes #75323 fixes #74447 and fixes #73375. This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so `to_region_vid`'s `bug!` had to be changed into a delayed bug which unfortunately required providing it a `TyCtxt`.~~ --- ~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const` emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked but it didn't silence the ICE either. To silence the ICE I changed it to a delayed bug which worked but was more invasive that I would have liked and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary but I wasn't sure where that would be and wanted to get some feedback first.~~ The approach taken by this PR has been changed to implement the error in name resolution which ended up being much simpler. cc @rust-lang/wg-const-eval r? @lcnr,HEART,2020-09-15T12:41:43Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/76739,MERGED,2020-09-15T12:28:52Z,2020-10-02T21:45:37Z,resolve: prohibit anon const non-static lifetimes,davidtwco,c8eb2059dae70b99576352ded93592e6462daafc,4,Rollup merge of #76739 - davidtwco:issue-75323-non-static-lifetime-in-anonconst r=varkor resolve: prohibit anon const non-static lifetimes Fixes #75323 fixes #74447 and fixes #73375. This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so `to_region_vid`'s `bug!` had to be changed into a delayed bug which unfortunately required providing it a `TyCtxt`.~~ --- ~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const` emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked but it didn't silence the ICE either. To silence the ICE I changed it to a delayed bug which worked but was more invasive that I would have liked and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary but I wasn't sure where that would be and wanted to get some feedback first.~~ The approach taken by this PR has been changed to implement the error in name resolution which ended up being much simpler. cc @rust-lang/wg-const-eval r? @lcnr,HEART,2020-09-15T13:01:34Z,hameerabbasi,NA https://github.com/rust-lang/rust/pull/76739,MERGED,2020-09-15T12:28:52Z,2020-10-02T21:45:37Z,resolve: prohibit anon const non-static lifetimes,davidtwco,c8eb2059dae70b99576352ded93592e6462daafc,4,Rollup merge of #76739 - davidtwco:issue-75323-non-static-lifetime-in-anonconst r=varkor resolve: prohibit anon const non-static lifetimes Fixes #75323 fixes #74447 and fixes #73375. This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so `to_region_vid`'s `bug!` had to be changed into a delayed bug which unfortunately required providing it a `TyCtxt`.~~ --- ~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const` emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked but it didn't silence the ICE either. To silence the ICE I changed it to a delayed bug which worked but was more invasive that I would have liked and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary but I wasn't sure where that would be and wanted to get some feedback first.~~ The approach taken by this PR has been changed to implement the error in name resolution which ended up being much simpler. cc @rust-lang/wg-const-eval r? @lcnr,HEART,2020-09-16T19:43:27Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76741,MERGED,2020-09-15T13:02:30Z,2020-09-16T22:36:59Z,Avoid printing dry run timings,Mark-Simulacrum,233937419a0ed5ae602188a60e7ce187b6faaec9,1,Rollup merge of #76741 - Mark-Simulacrum:no-dry-run-timing r=alexcrichton Avoid printing dry run timings This avoids a wall of text on CI with 0.000 as the likely time. r? @alexcrichton,THUMBS_UP,2020-09-15T13:17:00Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76749,MERGED,2020-09-15T17:00:20Z,2020-09-19T13:31:49Z,give *even better* suggestion when matching a const range,guswynn,5631b5d6843164a776b939cf8ebac7b8ea5e582a,3,"Rollup merge of #76749 - guswynn:hir_ranges r=estebank give *even better* suggestion when matching a const range notice that the err already has ""constant defined here"" so this is now *exceedingly clear* extension to #76222 r? @estebank",HEART,2020-09-15T17:37:12Z,estebank,NA https://github.com/rust-lang/rust/pull/76749,MERGED,2020-09-15T17:00:20Z,2020-09-19T13:31:49Z,give *even better* suggestion when matching a const range,guswynn,5631b5d6843164a776b939cf8ebac7b8ea5e582a,3,"Rollup merge of #76749 - guswynn:hir_ranges r=estebank give *even better* suggestion when matching a const range notice that the err already has ""constant defined here"" so this is now *exceedingly clear* extension to #76222 r? @estebank",HEART,2020-09-24T19:50:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76750,MERGED,2020-09-15T17:25:04Z,2020-10-09T00:30:45Z,Don't discourage implementing `core::fmt::Write`,camelid,2766b725d3aabee4788943d25b60413b34db570b,1,Rollup merge of #76750 - camelid:dont-discourage-core-fmt-write r=Mark-Simulacrum Don't discourage implementing `core::fmt::Write` Fixes #76729. Explain when you should use it and when you should not.,THUMBS_UP,2022-01-28T23:50:39Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/76755,MERGED,2020-09-15T19:58:14Z,2020-09-16T00:56:13Z,Gate macOS on both Azure and GHA,pietroalbini,9f04c9065764e56c91cbe567f78d2b207f546ba7,2,Auto merge of #76755 - pietroalbini:gha-macos r=Mark-Simulacrum Gate macOS on both Azure and GHA As discussed in the previous infrastructure team meeting this PR gates macOS builds on both GHA and Azure. Once this is merged we'll wait a week or two to see if there is a troublesome rate of spurious failures and if not we'll remove the builds on the Azure side. r? `@Mark-Simulacrum` cc #71988,HOORAY,2020-09-15T20:16:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76755,MERGED,2020-09-15T19:58:14Z,2020-09-16T00:56:13Z,Gate macOS on both Azure and GHA,pietroalbini,9f04c9065764e56c91cbe567f78d2b207f546ba7,2,Auto merge of #76755 - pietroalbini:gha-macos r=Mark-Simulacrum Gate macOS on both Azure and GHA As discussed in the previous infrastructure team meeting this PR gates macOS builds on both GHA and Azure. Once this is merged we'll wait a week or two to see if there is a troublesome rate of spurious failures and if not we'll remove the builds on the Azure side. r? `@Mark-Simulacrum` cc #71988,HOORAY,2020-09-15T21:25:46Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76765,MERGED,2020-09-15T22:01:36Z,2020-11-11T04:02:12Z,Make it more clear what an about async fn's returns when referring to what it returns,guswynn,9596e34ad49325c0711b56e9d0797768ee6c907f,13,Rollup merge of #76765 - guswynn:async_return r=tmandry Make it more clear what an about async fn's returns when referring to what it returns see #76547 This is *likely* not the ONLY place that this happens to be unclear but we can move this fn to rustc_middle or something like that and reuse it if need be to apply it to more diagnostics One outstanding question I have is if the fn returns () should I make the message more clear (what about `fn f()` vs `fn f() -> ()` can you tell those apart in the hir?) R? `@tmandry` `@rustbot` modify labels +A-diagnostics +T-compiler,HEART,2020-09-16T22:27:23Z,estebank,NA https://github.com/rust-lang/rust/pull/76766,MERGED,2020-09-15T22:17:59Z,2020-09-20T13:07:45Z,Extract some intrinsics out of rustc_codegen_llvm,khyperia,2911b8cb30cf4fed41a6d6dba4fb0076b6a82e93,4,"Rollup merge of #76766 - khyperia:generic_intrinsics r=eddyb Extract some intrinsics out of rustc_codegen_llvm A significant amount of intrinsics do not actually need backend-specific behaviors to be implemented instead relying on methods already in rustc_codegen_ssa. So extract those methods out to rustc_codegen_ssa so that each backend doesn't need to reimplement the same code. Almost everything should be a pretty direct translation. A notable not-direct-translation is `add_with_overflow` and friends being changed to `bx.checked_binop` but it's pretty simple. I could have been a lot more aggressive here and pulled out way more methods and add a few new methods in the rustc_codegen_ssa ""API"". However because this is my second rustc PR I thought that moving those to a follow-up PR and doing more incremental changes here would be better (and I guess ask if this work is even desired in the first place). I'm hoping to eventually remove the mess of intrinsic handling in the backend entirely which would be hecking fantastic :sparkles:",THUMBS_UP,2020-09-16T05:40:16Z,bjorn3,NA https://github.com/rust-lang/rust/pull/76769,CLOSED,2020-09-15T23:17:44Z,2020-11-04T19:59:21Z,Collect statistics about MIR optimizations,tmiasko,NA,NA,NA,HEART,2020-09-16T19:41:50Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76769,CLOSED,2020-09-15T23:17:44Z,2020-11-04T19:59:21Z,Collect statistics about MIR optimizations,tmiasko,NA,NA,NA,HEART,2020-09-17T20:19:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76769,CLOSED,2020-09-15T23:17:44Z,2020-11-04T19:59:21Z,Collect statistics about MIR optimizations,tmiasko,NA,NA,NA,HEART,2020-09-20T18:12:12Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/76769,CLOSED,2020-09-15T23:17:44Z,2020-11-04T19:59:21Z,Collect statistics about MIR optimizations,tmiasko,NA,NA,NA,HEART,2020-09-23T14:11:40Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76769,CLOSED,2020-09-15T23:17:44Z,2020-11-04T19:59:21Z,Collect statistics about MIR optimizations,tmiasko,NA,NA,NA,HEART,2020-10-08T23:47:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76808,MERGED,2020-09-16T21:24:07Z,2021-05-08T02:57:42Z,Improve diagnostics for functions in `struct` definitions,LeSeulArtichaut,eb36bc666a4e1e8b6f54f50f275ae10a4c22c77f,4,"Rollup merge of #76808 - LeSeulArtichaut:diagnose-functions-struct r=jackh726 Improve diagnostics for functions in `struct` definitions Tries to implement #76421. This is probably going to need unit tests but I wanted to hear from review all the cases tests should cover. I'd like to follow up with the ""mechanically applicable suggestion here that adds an impl block"" step but I'd need guidance. My idea for now would be to try to parse a function and if that succeeds create a dummy `ast::Item` impl block to then format it using `pprust`. Would that be a viable approach? Is there a better alternative? r? `@matklad` cc `@estebank`",HEART,2020-09-16T22:53:48Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76808,MERGED,2020-09-16T21:24:07Z,2021-05-08T02:57:42Z,Improve diagnostics for functions in `struct` definitions,LeSeulArtichaut,eb36bc666a4e1e8b6f54f50f275ae10a4c22c77f,4,"Rollup merge of #76808 - LeSeulArtichaut:diagnose-functions-struct r=jackh726 Improve diagnostics for functions in `struct` definitions Tries to implement #76421. This is probably going to need unit tests but I wanted to hear from review all the cases tests should cover. I'd like to follow up with the ""mechanically applicable suggestion here that adds an impl block"" step but I'd need guidance. My idea for now would be to try to parse a function and if that succeeds create a dummy `ast::Item` impl block to then format it using `pprust`. Would that be a viable approach? Is there a better alternative? r? `@matklad` cc `@estebank`",HEART,2021-02-01T00:33:06Z,camelid,NA https://github.com/rust-lang/rust/pull/76820,MERGED,2020-09-17T04:04:04Z,2020-09-24T15:12:47Z,Preserve doc-comments when generating queries,jyn514,893fadd11a52aa26fc19c67ee1b79f03d6a1bed3,2,Auto merge of #76820 - jyn514:query-comments r=davidtwco Preserve doc-comments when generating queries Closes https://github.com/rust-lang/rust/issues/76812,THUMBS_UP,2020-09-17T04:33:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/76821,MERGED,2020-09-17T05:50:38Z,2020-09-20T13:07:35Z,Remove redundant nightly features,est31,4322e1b92df83e9e8e84aac3f5f8f3545341fd3a,14,Rollup merge of #76821 - est31:remove_redundant_nightly_features r=oli-obk Mark-Simulacrum Remove redundant nightly features Removes a bunch of redundant/outdated nightly features. The first commit removes a `core_intrinsics` use for which a stable wrapper has been provided since. The second commit replaces the `const_generics` feature with `min_const_generics` which might get stabilized this year. The third commit is the result of a trial/error run of removing every single feature and then adding it back if compile failed. A bunch of unused features are the result that the third commit removes.,THUMBS_UP,2020-09-17T06:16:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76821,MERGED,2020-09-17T05:50:38Z,2020-09-20T13:07:35Z,Remove redundant nightly features,est31,4322e1b92df83e9e8e84aac3f5f8f3545341fd3a,14,Rollup merge of #76821 - est31:remove_redundant_nightly_features r=oli-obk Mark-Simulacrum Remove redundant nightly features Removes a bunch of redundant/outdated nightly features. The first commit removes a `core_intrinsics` use for which a stable wrapper has been provided since. The second commit replaces the `const_generics` feature with `min_const_generics` which might get stabilized this year. The third commit is the result of a trial/error run of removing every single feature and then adding it back if compile failed. A bunch of unused features are the result that the third commit removes.,THUMBS_UP,2020-09-17T18:15:26Z,panaman67,NA https://github.com/rust-lang/rust/pull/76821,MERGED,2020-09-17T05:50:38Z,2020-09-20T13:07:35Z,Remove redundant nightly features,est31,4322e1b92df83e9e8e84aac3f5f8f3545341fd3a,14,Rollup merge of #76821 - est31:remove_redundant_nightly_features r=oli-obk Mark-Simulacrum Remove redundant nightly features Removes a bunch of redundant/outdated nightly features. The first commit removes a `core_intrinsics` use for which a stable wrapper has been provided since. The second commit replaces the `const_generics` feature with `min_const_generics` which might get stabilized this year. The third commit is the result of a trial/error run of removing every single feature and then adding it back if compile failed. A bunch of unused features are the result that the third commit removes.,THUMBS_UP,2020-09-26T23:59:21Z,yerke,NA https://github.com/rust-lang/rust/pull/76821,MERGED,2020-09-17T05:50:38Z,2020-09-20T13:07:35Z,Remove redundant nightly features,est31,4322e1b92df83e9e8e84aac3f5f8f3545341fd3a,14,Rollup merge of #76821 - est31:remove_redundant_nightly_features r=oli-obk Mark-Simulacrum Remove redundant nightly features Removes a bunch of redundant/outdated nightly features. The first commit removes a `core_intrinsics` use for which a stable wrapper has been provided since. The second commit replaces the `const_generics` feature with `min_const_generics` which might get stabilized this year. The third commit is the result of a trial/error run of removing every single feature and then adding it back if compile failed. A bunch of unused features are the result that the third commit removes.,HOORAY,2020-09-26T23:59:23Z,yerke,NA https://github.com/rust-lang/rust/pull/76825,MERGED,2020-09-17T07:36:29Z,2020-09-20T13:07:33Z,use `array_windows` instead of `windows` in the compiler,lcnr,50d56bc774f9ecb2b43640651401f3cb346c1b89,11,Rollup merge of #76825 - lcnr:array-windows-apply r=varkor use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics where inferring constants adds an additional complexity which users have to learn and keep in mind.,HOORAY,2020-09-17T08:08:13Z,rrbutani,NA https://github.com/rust-lang/rust/pull/76825,MERGED,2020-09-17T07:36:29Z,2020-09-20T13:07:33Z,use `array_windows` instead of `windows` in the compiler,lcnr,50d56bc774f9ecb2b43640651401f3cb346c1b89,11,Rollup merge of #76825 - lcnr:array-windows-apply r=varkor use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics where inferring constants adds an additional complexity which users have to learn and keep in mind.,HOORAY,2020-09-17T08:09:57Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/76825,MERGED,2020-09-17T07:36:29Z,2020-09-20T13:07:33Z,use `array_windows` instead of `windows` in the compiler,lcnr,50d56bc774f9ecb2b43640651401f3cb346c1b89,11,Rollup merge of #76825 - lcnr:array-windows-apply r=varkor use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics where inferring constants adds an additional complexity which users have to learn and keep in mind.,HEART,2020-09-17T11:21:26Z,varkor,NA https://github.com/rust-lang/rust/pull/76825,MERGED,2020-09-17T07:36:29Z,2020-09-20T13:07:33Z,use `array_windows` instead of `windows` in the compiler,lcnr,50d56bc774f9ecb2b43640651401f3cb346c1b89,11,Rollup merge of #76825 - lcnr:array-windows-apply r=varkor use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics where inferring constants adds an additional complexity which users have to learn and keep in mind.,HEART,2020-09-17T16:06:04Z,eopb,NA https://github.com/rust-lang/rust/pull/76825,MERGED,2020-09-17T07:36:29Z,2020-09-20T13:07:33Z,use `array_windows` instead of `windows` in the compiler,lcnr,50d56bc774f9ecb2b43640651401f3cb346c1b89,11,Rollup merge of #76825 - lcnr:array-windows-apply r=varkor use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics where inferring constants adds an additional complexity which users have to learn and keep in mind.,HOORAY,2020-09-18T20:06:08Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/76829,MERGED,2020-09-17T09:26:58Z,2020-11-23T19:01:23Z,stabilize const_int_pow,tspiteri,703f176d5708c2aefc7c995bf938517dbe289f79,5,Rollup merge of #76829 - tspiteri:const-int-pow r=oli-obk stabilize const_int_pow This also requires stabilizing constctlz for const ctlz_nonzero.,HOORAY,2020-11-19T21:02:45Z,DianaNites,NA https://github.com/rust-lang/rust/pull/76839,MERGED,2020-09-17T15:32:50Z,2020-09-27T19:38:35Z,Add asm! support for MIPS,tesuji,ec1766c5b6ec6e714bc9f976229586187b304720,5,Rollup merge of #76839 - lzutao:mips-asm r=Amanieu Add asm! support for MIPS For now I only add support for mips32. mips64 may come in future PRs if I could learn more about the target.,HEART,2020-09-25T21:58:03Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/76839,MERGED,2020-09-17T15:32:50Z,2020-09-27T19:38:35Z,Add asm! support for MIPS,tesuji,ec1766c5b6ec6e714bc9f976229586187b304720,5,Rollup merge of #76839 - lzutao:mips-asm r=Amanieu Add asm! support for MIPS For now I only add support for mips32. mips64 may come in future PRs if I could learn more about the target.,HEART,2020-09-26T00:06:24Z,est31,NA https://github.com/rust-lang/rust/pull/76839,MERGED,2020-09-17T15:32:50Z,2020-09-27T19:38:35Z,Add asm! support for MIPS,tesuji,ec1766c5b6ec6e714bc9f976229586187b304720,5,Rollup merge of #76839 - lzutao:mips-asm r=Amanieu Add asm! support for MIPS For now I only add support for mips32. mips64 may come in future PRs if I could learn more about the target.,HEART,2020-09-27T06:07:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76844,MERGED,2020-09-17T17:18:23Z,2020-09-25T06:24:25Z,Fix #76803 miscompilation,simonvandel,9d74efe32eb8e1053d9e00f604d4c5760be9382f,4,Auto merge of #76844 - simonvandel:fix-76803 r=wesleywiser Fix #76803 miscompilation Fixes #76803 Seems like it was an oversight that the discriminant value being set was not compared to the target value from the SwitchInt as a comment says this is a requirement for the optimization to be sound. r? `@wesleywiser` since you are probably familiar with the optimization and made #76837 to workaround the bug,THUMBS_UP,2020-09-19T18:25:08Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76851,MERGED,2020-09-17T19:58:58Z,2020-10-02T03:07:06Z,Fix 'FIXME' about using NonZeroU32 instead of u32.,m-ou-se,1fa5f8f05b85a22bb9fb94e5d2f026b124c514f8,4,Rollup merge of #76851 - fusion-engineering-forks:fixme-nonzero r=petrochenkov Fix 'FIXME' about using NonZeroU32 instead of u32. It was blocked by #58732 (const fn NonZeroU32::new) which is fixed now.,THUMBS_UP,2020-09-18T17:24:58Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/76856,MERGED,2020-09-17T22:19:34Z,2020-09-19T06:28:44Z,Distribute rustc sources as part of `rustc-dev`,jonas-schievink,ac19c3bda18ed5b692668725f7acac988f0aa2be,1,Auto merge of #76856 - jonas-schievink:dist-rustc-src r=Mark-Simulacrum Distribute rustc sources as part of `rustc-dev` They can be used to provide IDE features when working on rustc plugins/backends/etc without having to locate a separate Rust checkout. r? `@Mark-Simulacrum`,HOORAY,2020-09-18T10:14:25Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/76856,MERGED,2020-09-17T22:19:34Z,2020-09-19T06:28:44Z,Distribute rustc sources as part of `rustc-dev`,jonas-schievink,ac19c3bda18ed5b692668725f7acac988f0aa2be,1,Auto merge of #76856 - jonas-schievink:dist-rustc-src r=Mark-Simulacrum Distribute rustc sources as part of `rustc-dev` They can be used to provide IDE features when working on rustc plugins/backends/etc without having to locate a separate Rust checkout. r? `@Mark-Simulacrum`,HOORAY,2020-09-18T11:01:22Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/76856,MERGED,2020-09-17T22:19:34Z,2020-09-19T06:28:44Z,Distribute rustc sources as part of `rustc-dev`,jonas-schievink,ac19c3bda18ed5b692668725f7acac988f0aa2be,1,Auto merge of #76856 - jonas-schievink:dist-rustc-src r=Mark-Simulacrum Distribute rustc sources as part of `rustc-dev` They can be used to provide IDE features when working on rustc plugins/backends/etc without having to locate a separate Rust checkout. r? `@Mark-Simulacrum`,HOORAY,2020-09-18T12:30:53Z,ebroto,NA https://github.com/rust-lang/rust/pull/76859,MERGED,2020-09-18T02:06:04Z,2020-10-11T22:42:40Z,Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse,Aaron1011,c71248b70870960af9993de4f31d3cba9bbce7e8,6,Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse r=davidtwco nikic Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse During incremental ThinLTO compilation we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO it may look at other information from the 'module index' such as whether a (non-imported!) global variable is used. If this information changes between compilation runs we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately LLVM implements its own ThinLTO module cache which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made.,THUMBS_UP,2020-09-18T14:00:46Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/76864,MERGED,2020-09-18T04:23:40Z,2020-09-23T13:19:45Z,Don't download/sync llvm-project submodule if download-ci-llvm is set,est31,33aa8be8b5fa6872186a94d9e1fa5088da386e4b,1,Auto merge of #76864 - est31:downloaded_llvm_no_clone_sources r=Mark-Simulacrum Don't download/sync llvm-project submodule if download-ci-llvm is set llvm-project takes > 1GB storage space and a long time to download. It's better to not download it unless needed.,HEART,2020-09-18T22:55:29Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76864,MERGED,2020-09-18T04:23:40Z,2020-09-23T13:19:45Z,Don't download/sync llvm-project submodule if download-ci-llvm is set,est31,33aa8be8b5fa6872186a94d9e1fa5088da386e4b,1,Auto merge of #76864 - est31:downloaded_llvm_no_clone_sources r=Mark-Simulacrum Don't download/sync llvm-project submodule if download-ci-llvm is set llvm-project takes > 1GB storage space and a long time to download. It's better to not download it unless needed.,HEART,2020-09-19T21:16:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76878,MERGED,2020-09-18T13:04:38Z,2020-09-20T17:18:52Z,Move the version number to a plaintext file,pietroalbini,24980b7d8deba77963917c0e00d6f22cde7c9c70,8,Rollup merge of #76878 - pietroalbini:version r=Mark-Simulacrum Move the version number to a plaintext file The Rust version number is currently embedded in bootstrap's source code which makes it hard to update it automatically or access it outside of ./x.py (as you'd have to parse the source code). This PR moves the version number to a standalone plaintext file which makes accessing or updating it trivial. r? @Mark-Simulacrum,THUMBS_UP,2020-09-18T14:41:57Z,est31,NA https://github.com/rust-lang/rust/pull/76881,MERGED,2020-09-18T14:07:02Z,2021-04-02T20:06:26Z,Add allocation information to undefined behaviour errors.,hameerabbasi,23fa5360502be2554382c9d860e6438d3b822858,74,Auto merge of #76881 - hameerabbasi:issue-53325 r=oli-obk Add allocation information to undefined behaviour errors. So far I'm looking on information on whether the error messages are suitable. Fixes #53325.,THUMBS_UP,2020-09-21T16:24:01Z,estebank,NA https://github.com/rust-lang/rust/pull/76894,CLOSED,2020-09-18T20:46:14Z,2021-05-24T18:25:31Z,Lint for unused borrows as part of `UNUSED_MUST_USE`,ecstatic-morse,NA,NA,NA,HEART,2020-10-05T05:18:51Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/76894,CLOSED,2020-09-18T20:46:14Z,2021-05-24T18:25:31Z,Lint for unused borrows as part of `UNUSED_MUST_USE`,ecstatic-morse,NA,NA,NA,HEART,2020-10-25T00:08:21Z,Jdender,jdenderplays@gmail.com https://github.com/rust-lang/rust/pull/76894,CLOSED,2020-09-18T20:46:14Z,2021-05-24T18:25:31Z,Lint for unused borrows as part of `UNUSED_MUST_USE`,ecstatic-morse,NA,NA,NA,HEART,2020-10-30T06:48:35Z,camelid,NA https://github.com/rust-lang/rust/pull/76894,CLOSED,2020-09-18T20:46:14Z,2021-05-24T18:25:31Z,Lint for unused borrows as part of `UNUSED_MUST_USE`,ecstatic-morse,NA,NA,NA,HEART,2021-02-05T20:03:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76894,CLOSED,2020-09-18T20:46:14Z,2021-05-24T18:25:31Z,Lint for unused borrows as part of `UNUSED_MUST_USE`,ecstatic-morse,NA,NA,NA,ROCKET,2021-02-19T12:37:18Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/76897,MERGED,2020-09-19T01:12:17Z,2020-09-26T23:03:00Z,Encode less metadata for proc-macro crates,Aaron1011,623fb90b5a1f324e0ec44085116bf858cef19a00,4,Auto merge of #76897 - Aaron1011:feature/min-proc-macro-metadata r=petrochenkov Encode less metadata for proc-macro crates Currently we serialize the same crate metadata for proc-macro crates as we do for normal crates. This is quite wasteful - almost none of this metadata is ever used and much of it can't even be deserialized (if it contains a foreign `CrateNum`). This PR changes metadata encoding to skip encoding the majority of crate metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left completetly empty while the non-lazy fields are left as-is. Additionally proc-macros now have a def span that does not include their body. This was done for normal functions in #75465 but was missed for proc-macros. As a result of this PR we should only ever encode local `CrateNum`s when encoding proc-macro crates. I've added a specialized serialization impl for `CrateNum` to assert this.,THUMBS_UP,2020-09-19T02:30:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/76899,MERGED,2020-09-19T02:09:32Z,2020-09-28T18:03:16Z,[mir-opt] Introduce a new flag to enable experimental/unsound mir opts,wesleywiser,d62d3f7fa9a91d933213cc10e20e740608983f64,11,"Auto merge of #76899 - wesleywiser:experimental_unsound_mir_opts_flag r=oli-obk [mir-opt] Introduce a new flag to enable experimental/unsound mir opts This implements part of https://github.com/rust-lang/compiler-team/issues/319. The exact name of this flag was not decided as part of that MCP and some people expressed that it should include ""unsound"" in some way. I've chosen to use `enable-experimental-unsound-mir-opts` as the name. While long I don't think that matters too much as really it will only be used by some mir-opt tests. If you object or have a better name please leave a comment! r? `@oli-obk` cc `@rust-lang/wg-mir-opt` `@RalfJung`",HEART,2020-09-19T07:50:07Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/76899,MERGED,2020-09-19T02:09:32Z,2020-09-28T18:03:16Z,[mir-opt] Introduce a new flag to enable experimental/unsound mir opts,wesleywiser,d62d3f7fa9a91d933213cc10e20e740608983f64,11,"Auto merge of #76899 - wesleywiser:experimental_unsound_mir_opts_flag r=oli-obk [mir-opt] Introduce a new flag to enable experimental/unsound mir opts This implements part of https://github.com/rust-lang/compiler-team/issues/319. The exact name of this flag was not decided as part of that MCP and some people expressed that it should include ""unsound"" in some way. I've chosen to use `enable-experimental-unsound-mir-opts` as the name. While long I don't think that matters too much as really it will only be used by some mir-opt tests. If you object or have a better name please leave a comment! r? `@oli-obk` cc `@rust-lang/wg-mir-opt` `@RalfJung`",HEART,2020-09-19T21:15:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HOORAY,2020-09-19T21:14:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HEART,2020-09-19T21:14:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HOORAY,2020-09-20T09:01:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HOORAY,2020-09-23T16:30:37Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HOORAY,2020-11-30T08:50:45Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HOORAY,2021-07-15T18:46:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76901,CLOSED,2020-09-19T03:19:01Z,2021-07-26T07:51:23Z,Implement RFC 2500 Needle API (Part 1),crlf0710,NA,NA,NA,HEART,2021-07-15T18:46:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76902,CLOSED,2020-09-19T04:11:37Z,2020-11-30T16:51:27Z,add `slice::replace`,izik1,NA,NA,NA,EYES,2020-09-19T04:21:05Z,tesuji,NA https://github.com/rust-lang/rust/pull/76902,CLOSED,2020-09-19T04:11:37Z,2020-11-30T16:51:27Z,add `slice::replace`,izik1,NA,NA,NA,HEART,2020-09-19T19:56:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76909,MERGED,2020-09-19T09:04:57Z,2020-10-01T03:28:43Z,Add Iterator::advance_by and DoubleEndedIterator::advance_back_by,timvermeulen,8bd4ed9f95a9c7228ec10988550ec0808b1a4e75,5,Rollup merge of #76909 - timvermeulen:advance_by r=Amanieu Add Iterator::advance_by and DoubleEndedIterator::advance_back_by This PR adds the iterator method ```rust fn advance_by(&mut self n: usize) -> Result<() usize> ``` that advances the iterator by `n` elements returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`. Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because - it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator - it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395) - the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next` which this PR also does This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons. I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back` but those still need tests so I'll add them in a later PR. cc @cuviper @scottmcm @Amanieu,THUMBS_UP,2020-09-19T20:27:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/76909,MERGED,2020-09-19T09:04:57Z,2020-10-01T03:28:43Z,Add Iterator::advance_by and DoubleEndedIterator::advance_back_by,timvermeulen,8bd4ed9f95a9c7228ec10988550ec0808b1a4e75,5,Rollup merge of #76909 - timvermeulen:advance_by r=Amanieu Add Iterator::advance_by and DoubleEndedIterator::advance_back_by This PR adds the iterator method ```rust fn advance_by(&mut self n: usize) -> Result<() usize> ``` that advances the iterator by `n` elements returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`. Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because - it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator - it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395) - the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next` which this PR also does This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons. I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back` but those still need tests so I'll add them in a later PR. cc @cuviper @scottmcm @Amanieu,THUMBS_UP,2020-10-08T08:47:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76909,MERGED,2020-09-19T09:04:57Z,2020-10-01T03:28:43Z,Add Iterator::advance_by and DoubleEndedIterator::advance_back_by,timvermeulen,8bd4ed9f95a9c7228ec10988550ec0808b1a4e75,5,Rollup merge of #76909 - timvermeulen:advance_by r=Amanieu Add Iterator::advance_by and DoubleEndedIterator::advance_back_by This PR adds the iterator method ```rust fn advance_by(&mut self n: usize) -> Result<() usize> ``` that advances the iterator by `n` elements returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`. Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because - it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator - it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395) - the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next` which this PR also does This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons. I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back` but those still need tests so I'll add them in a later PR. cc @cuviper @scottmcm @Amanieu,THUMBS_UP,2020-10-09T22:50:13Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/76910,MERGED,2020-09-19T09:10:07Z,2020-09-20T17:18:44Z,transmute: use diagnostic item,lcnr,7ff17c13bc26e2cf20beea35a5757f8c548ac5f2,4,Rollup merge of #76910 - lcnr:foreign-item-like r=oli-obk transmute: use diagnostic item closes #66075 we now have no remaining uses of `match_def_path` in the compiler while some uses still remain in `clippy`. cc @RalfJung,HEART,2020-09-19T22:53:59Z,estebank,NA https://github.com/rust-lang/rust/pull/76919,MERGED,2020-09-19T13:18:07Z,2020-10-01T15:40:06Z,Use futex-based thread::park/unpark on Linux.,m-ou-se,782013564efc06ef02614ba35a4e67dee4fcb8e7,7,Auto merge of #76919 - fusion-engineering-forks:thread-parker r=dtolnay Use futex-based thread::park/unpark on Linux. This moves the parking/unparking logic out of `thread/mod.rs` into a module named `thread_parker` in `sys_common`. The current implementation is moved to `sys_common/thread_parker/generic.rs` and the new implementation using futexes is added in `sys_common/thread_parker/futex.rs`.,HEART,2020-09-20T14:36:53Z,tmiasko,NA https://github.com/rust-lang/rust/pull/76919,MERGED,2020-09-19T13:18:07Z,2020-10-01T15:40:06Z,Use futex-based thread::park/unpark on Linux.,m-ou-se,782013564efc06ef02614ba35a4e67dee4fcb8e7,7,Auto merge of #76919 - fusion-engineering-forks:thread-parker r=dtolnay Use futex-based thread::park/unpark on Linux. This moves the parking/unparking logic out of `thread/mod.rs` into a module named `thread_parker` in `sys_common`. The current implementation is moved to `sys_common/thread_parker/generic.rs` and the new implementation using futexes is added in `sys_common/thread_parker/futex.rs`.,HEART,2020-10-04T20:48:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76919,MERGED,2020-09-19T13:18:07Z,2020-10-01T15:40:06Z,Use futex-based thread::park/unpark on Linux.,m-ou-se,782013564efc06ef02614ba35a4e67dee4fcb8e7,7,Auto merge of #76919 - fusion-engineering-forks:thread-parker r=dtolnay Use futex-based thread::park/unpark on Linux. This moves the parking/unparking logic out of `thread/mod.rs` into a module named `thread_parker` in `sys_common`. The current implementation is moved to `sys_common/thread_parker/generic.rs` and the new implementation using futexes is added in `sys_common/thread_parker/futex.rs`.,HEART,2020-10-05T13:12:47Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/76919,MERGED,2020-09-19T13:18:07Z,2020-10-01T15:40:06Z,Use futex-based thread::park/unpark on Linux.,m-ou-se,782013564efc06ef02614ba35a4e67dee4fcb8e7,7,Auto merge of #76919 - fusion-engineering-forks:thread-parker r=dtolnay Use futex-based thread::park/unpark on Linux. This moves the parking/unparking logic out of `thread/mod.rs` into a module named `thread_parker` in `sys_common`. The current implementation is moved to `sys_common/thread_parker/generic.rs` and the new implementation using futexes is added in `sys_common/thread_parker/futex.rs`.,HEART,2020-10-06T01:19:18Z,emmanuelantony2000,NA https://github.com/rust-lang/rust/pull/76928,MERGED,2020-09-19T15:30:30Z,2020-09-23T01:11:55Z,cache types during normalization,lcnr,6d3acf5129767db78a3d9d62e814ec86b8870d75,7,"Auto merge of #76928 - lcnr:opaque-types-cache r=tmandry cache types during normalization partially fixes #75992 reduces the following test from 14 to 3 seconds locally. cc `@Mark-Simulacrum` would it make sense to add that test to `perf`? ```rust #![recursion_limit=""2048""] #![type_length_limit=""112457564""] pub async fn h0(v: &String x: &u64) { println!(""{} {}"" v x) } pub async fn h1(v: &String x: &u64) { h0(v x).await } pub async fn h2(v: &String x: &u64) { h1(v x).await } pub async fn h3(v: &String x: &u64) { h2(v x).await } pub async fn h4(v: &String x: &u64) { h3(v x).await } pub async fn h5(v: &String x: &u64) { h4(v x).await } pub async fn h6(v: &String x: &u64) { h5(v x).await } pub async fn h7(v: &String x: &u64) { h6(v x).await } pub async fn h8(v: &String x: &u64) { h7(v x).await } pub async fn h9(v: &String x: &u64) { h8(v x).await } pub async fn h10(v: &String x: &u64) { h9(v x).await } pub async fn h11(v: &String x: &u64) { h10(v x).await } pub async fn h12(v: &String x: &u64) { h11(v x).await } pub async fn h13(v: &String x: &u64) { h12(v x).await } pub async fn h14(v: &String x: &u64) { h13(v x).await } pub async fn h15(v: &String x: &u64) { h14(v x).await } pub async fn h16(v: &String x: &u64) { h15(v x).await } pub async fn h17(v: &String x: &u64) { h16(v x).await } pub async fn h18(v: &String x: &u64) { h17(v x).await } pub async fn h19(v: &String x: &u64) { h18(v x).await } macro_rules! async_recursive { (29 $inner:expr) => { async { async_recursive!(28 $inner) }.await }; (28 $inner:expr) => { async { async_recursive!(27 $inner) }.await }; (27 $inner:expr) => { async { async_recursive!(26 $inner) }.await }; (26 $inner:expr) => { async { async_recursive!(25 $inner) }.await }; (25 $inner:expr) => { async { async_recursive!(24 $inner) }.await }; (24 $inner:expr) => { async { async_recursive!(23 $inner) }.await }; (23 $inner:expr) => { async { async_recursive!(22 $inner) }.await }; (22 $inner:expr) => { async { async_recursive!(21 $inner) }.await }; (21 $inner:expr) => { async { async_recursive!(20 $inner) }.await }; (20 $inner:expr) => { async { async_recursive!(19 $inner) }.await }; (19 $inner:expr) => { async { async_recursive!(18 $inner) }.await }; (18 $inner:expr) => { async { async_recursive!(17 $inner) }.await }; (17 $inner:expr) => { async { async_recursive!(16 $inner) }.await }; (16 $inner:expr) => { async { async_recursive!(15 $inner) }.await }; (15 $inner:expr) => { async { async_recursive!(14 $inner) }.await }; (14 $inner:expr) => { async { async_recursive!(13 $inner) }.await }; (13 $inner:expr) => { async { async_recursive!(12 $inner) }.await }; (12 $inner:expr) => { async { async_recursive!(11 $inner) }.await }; (11 $inner:expr) => { async { async_recursive!(10 $inner) }.await }; (10 $inner:expr) => { async { async_recursive!(9 $inner) }.await }; (9 $inner:expr) => { async { async_recursive!(8 $inner) }.await }; (8 $inner:expr) => { async { async_recursive!(7 $inner) }.await }; (7 $inner:expr) => { async { async_recursive!(6 $inner) }.await }; (6 $inner:expr) => { async { async_recursive!(5 $inner) }.await }; (5 $inner:expr) => { async { async_recursive!(4 $inner) }.await }; (4 $inner:expr) => { async { async_recursive!(3 $inner) }.await }; (3 $inner:expr) => { async { async_recursive!(2 $inner) }.await }; (2 $inner:expr) => { async { async_recursive!(1 $inner) }.await }; (1 $inner:expr) => { async { async_recursive!(0 $inner) }.await }; (0 $inner:expr) => { async { h19(&String::from(""owo"") &0).await; $inner }.await }; } async fn f() { async_recursive!(14 println!(""hello"")); } fn main() { let _ = f(); } ``` r? `@eddyb` requires a perf run.",HEART,2020-09-22T21:47:18Z,tmandry,NA https://github.com/rust-lang/rust/pull/76931,MERGED,2020-09-19T17:00:20Z,2020-11-03T18:59:19Z,Properly handle lint spans after MIR inlining,oli-obk,5cdf5b882da9e8b7c73b5cadeb7745cb68f6ff63,40,Auto merge of #76931 - oli-obk:const_prop_inline_lint_madness r=wesleywiser Properly handle lint spans after MIR inlining The first commit shows what happens when we apply mir inlining and then cause lints on the inlined MIR. The second commit fixes that. r? `@wesleywiser`,HEART,2020-09-19T18:36:07Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/76934,MERGED,2020-09-19T18:52:55Z,2020-10-10T23:28:20Z,Allow generic parameters in intra-doc links,camelid,b1af43bc63bc7417938df056f7f25d456cc11b0e,12,Auto merge of #76934 - camelid:rustdoc-allow-generic-params r=jyn514 Allow generic parameters in intra-doc links Fixes #62834. --- The contents of the generics will be mostly ignored (except for warning if fully-qualified syntax is used which is currently unsupported in intra-doc links - see issue #74563). * Allow links like `Vec` `Result` and `Option>` * Allow links like `Vec::::new()` * Warn on * Unbalanced angle brackets (e.g. `Vec>`) * Missing type to apply generics to (`` or `>`) * Use of fully-qualified syntax (`::into_iter`) * Invalid path separator (`Vec::new`) * Too many angle brackets (`Vec<>`) * Empty angle brackets (`Vec<>`) Note that this implementation *does* allow some constructs that aren't valid in the actual Rust syntax for example `Box::new()`. That may not be supported in rustdoc in the future; it is an implementation detail.,HEART,2021-03-28T19:16:59Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/76939,MERGED,2020-09-19T20:25:36Z,2020-09-24T00:43:29Z,emit errors during AbstractConst building,lcnr,98e5ee7df02c7812441ac31338819cb3f788f4f9,10,Rollup merge of #76939 - lcnr:const-evaluatable-cont r=oli-obk emit errors during AbstractConst building There changes are currently still untested so I don't expect this to pass CI :laughing: It seems to me like this is the direction we want to go in though we didn't have too much of a discussion about this. r? @oli-obk,THUMBS_UP,2020-09-20T08:30:28Z,oli-obk,NA https://github.com/rust-lang/rust/pull/76941,MERGED,2020-09-19T20:34:29Z,2020-11-23T02:25:15Z,Add f{32 64}::is_subnormal,clarfonthey,9b98f1d226305913c7c205bd98b6ea6b9fe3b8ce,2,Rollup merge of #76941 - clarfonthey:is_subnormal r=m-ou-se Add f{32 64}::is_subnormal The docs recommend that you use dedicated methods instead of calling `classify` directly although there isn't actually a way of checking if a number is subnormal without calling classify. There are dedicated methods for all other forms excluding `is_zero` (which is just `== 0.0` anyway).,HEART,2020-11-23T07:42:17Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/76967,MERGED,2020-09-20T10:55:30Z,2020-09-21T17:33:08Z,Revert adding Atomic::from_mut.,m-ou-se,b0c2eab66a4a59a66575e8afbfb9e707de2d7bd8,1,Rollup merge of #76967 - fusion-engineering-forks:revert-atomic-from-mut r=kodrAus Revert adding Atomic::from_mut. This reverts #74532 which made too many assumptions about platforms breaking some things. Will need to be added later with a better way of gating on proper alignment without hardcoding cfg(target_arch)s. --- To be merged if fixing from_mut (#76965) takes too long. r? @ghost,HEART,2020-09-20T11:02:15Z,RalfJung,NA https://github.com/rust-lang/rust/pull/76967,MERGED,2020-09-20T10:55:30Z,2020-09-21T17:33:08Z,Revert adding Atomic::from_mut.,m-ou-se,b0c2eab66a4a59a66575e8afbfb9e707de2d7bd8,1,Rollup merge of #76967 - fusion-engineering-forks:revert-atomic-from-mut r=kodrAus Revert adding Atomic::from_mut. This reverts #74532 which made too many assumptions about platforms breaking some things. Will need to be added later with a better way of gating on proper alignment without hardcoding cfg(target_arch)s. --- To be merged if fixing from_mut (#76965) takes too long. r? @ghost,HEART,2020-09-20T13:57:40Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/76969,MERGED,2020-09-20T11:22:22Z,2020-10-01T17:45:18Z,Make RawFd implement the RawFd traits,withoutboats,2ad6187ce51eb3a304ca448b8676870f95ab5b11,3,Auto merge of #76969 - withoutboats:rawfd-refexive-traits r=dtolnay Make RawFd implement the RawFd traits This PR makes `RawFd` implement `AsRawFd` `IntoRawFd` and `FromRawFd` so it can be passed to interfaces that use one of those traits as a bound.,HEART,2020-09-24T20:02:34Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76969,MERGED,2020-09-20T11:22:22Z,2020-10-01T17:45:18Z,Make RawFd implement the RawFd traits,withoutboats,2ad6187ce51eb3a304ca448b8676870f95ab5b11,3,Auto merge of #76969 - withoutboats:rawfd-refexive-traits r=dtolnay Make RawFd implement the RawFd traits This PR makes `RawFd` implement `AsRawFd` `IntoRawFd` and `FromRawFd` so it can be passed to interfaces that use one of those traits as a bound.,HEART,2020-09-26T11:25:19Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/76973,MERGED,2020-09-20T13:50:39Z,2020-09-25T21:44:59Z,Unstably allow assume intrinsic in const contexts,tesuji,1b8c939a8d7bcfdb8e3336526927544321bc6602,10,Rollup merge of #76973 - lzutao:unstably-const-assume r=oli-obk Unstably allow assume intrinsic in const contexts Not sure much about this usage because there are concerns about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic in inline functions. But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221 here we are. [1]: https://github.com/rust-lang/rust/pull/54995#issuecomment-429302709 [2]: https://github.com/rust-lang/rust/issues/49572#issuecomment-589615423,HEART,2020-09-20T14:24:23Z,est31,NA https://github.com/rust-lang/rust/pull/76979,MERGED,2020-09-20T14:12:59Z,2020-10-02T03:07:01Z,Improve std::sys::windows::compat,m-ou-se,00b3450bbcd1c745eb2f4e6c1ddd9f480da2b584,3,Rollup merge of #76979 - fusion-engineering-forks:windows-fallback-check r=dtolnay Improve std::sys::windows::compat Improves the compat_fn macro in sys::windows which is used for conditionally loading APIs that might not be available. - The module (dll) name can now be any string not just an ident. (Not all Windows api modules are valid Rust identifiers. E.g. `WaitOnAddress` comes from `API-MS-Win-Core-Synch-l1-2-0.dll`.) - Adds `FuncName::is_available()` for checking if a function is really available without having to do a duplicate lookup. - Add comment explaining the lack of locking. - Use `$_:block` to simplify the macro_rules. - Apply `allow(unused_variables)` only to the fallback instead of everything. --- The second point (`is_available()`) simplifies code that needs to pick an implementation depening on what is available like `sys/windows/mutex.rs`. Before this change it'd do its own lookup and keep its own `AtomicUsize` to track the result. Now it can just use `c::AcquireSRWLockExclusive::is_available()` directly. This will also be useful when park/unpark/CondVar/etc. get improved implementations (e.g. from parking_lot or something else) as the best APIs for those are not available before Windows 8.,THUMBS_UP,2020-09-20T14:38:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T00:34:56Z,yerke,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T01:55:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T02:08:04Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T03:43:29Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T04:56:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T06:31:50Z,DianaNites,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T06:42:57Z,est31,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T06:55:53Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T11:05:24Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T13:04:02Z,harrysarson,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T16:21:51Z,estebank,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-21T22:43:21Z,rrbutani,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-23T14:05:46Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-26T16:35:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-09-29T13:46:05Z,bluss,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",THUMBS_UP,2020-10-01T02:53:13Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T03:36:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T05:44:54Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T06:52:13Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",THUMBS_UP,2020-10-01T06:52:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T10:24:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T14:43:33Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T19:18:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-01T23:00:38Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-02T17:05:14Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2020-10-06T16:01:05Z,moshg,NA https://github.com/rust-lang/rust/pull/76986,MERGED,2020-09-20T22:34:40Z,2020-09-27T04:51:06Z,Return values up to 128 bits in registers,jonas-schievink,62fe055aba3ddac5e5d113920cf5fd80522104e2,3,"Auto merge of #76986 - jonas-schievink:ret-in-reg r=nagisa Return values up to 128 bits in registers This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers just like the System V ABI. The result is that these methods from the comment linked above now generate the same code making the Rust ABI as efficient as the `""C""` ABI: ```rust pub struct Stats { x: u32 y: u32 z: u32 } pub extern ""C"" fn sum_c(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } pub fn sum_rust(a: &Stats b: &Stats) -> Stats { return Stats {x: a.x + b.x y: a.y + b.y z: a.z + b.z }; } ``` ```asm sum_rust: movl (%rsi) %eax addl (%rdi) %eax movl 4(%rsi) %ecx addl 4(%rdi) %ecx movl 8(%rsi) %edx addl 8(%rdi) %edx shlq $32 %rcx orq %rcx %rax retq ```",HOORAY,2022-04-15T19:19:46Z,CatCode79,andrea.postal@gmail.com https://github.com/rust-lang/rust/pull/77009,MERGED,2020-09-21T10:15:46Z,2020-09-21T17:32:58Z,Dogfood total_cmp in the test crate,est31,fb3cb14af680b2940955c491f79f3293bd9a060b,2,Rollup merge of #77009 - est31:dogfood_total_cmp r=lcnr Dogfood total_cmp in the test crate,THUMBS_UP,2020-09-21T10:19:17Z,mati865,NA https://github.com/rust-lang/rust/pull/77016,MERGED,2020-09-21T14:53:26Z,2020-11-10T13:26:05Z,Test clippy on PR CI on changes,Mark-Simulacrum,391136ed582432855a4e316dadd37089158b698a,1,Rollup merge of #77016 - Mark-Simulacrum:clippy-tests r=pietroalbini Test clippy on PR CI on changes This runs the tools builder (which builds and tests tools including clippy) when the clippy submodule changes. This essentially returns us to the prior state when clippy was a submodule; it makes sense for us to test it on CI when it changes. It might make sense for it to be tested regardless of changing but it is somewhat rare for it to fail and we don't want to add to CI time for the majority of PRs which don't affect it. Fixes #76999.,HEART,2020-09-21T14:56:08Z,ebroto,NA https://github.com/rust-lang/rust/pull/77021,CLOSED,2020-09-21T17:29:42Z,2020-10-15T14:33:44Z,Make char::is_ascii_whitespace branchless on 32 and 64-bit targets,lnicola,NA,NA,NA,THUMBS_UP,2020-09-21T18:20:29Z,stanciuadrian,NA https://github.com/rust-lang/rust/pull/77029,MERGED,2020-09-21T21:01:23Z,2020-10-02T10:05:28Z,Add accessors to Command.,ehuss,154f1f544dd68f7b53ff8d9952811e855f4c2d7c,8,"Auto merge of #77029 - ehuss:command-access r=dtolnay Add accessors to Command. This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo. Possible concerns about the API: - Values with NULs on Unix will be returned as `""""`. I don't think it is practical to avoid this since otherwise a whole separate copy of all the values would need to be kept in `Command`. - Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it it can be added to `CommandExt` as a separate method. - Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone. - Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak though. Also the API could be a little awkward (return a `Option>`?). - `get_envs` could skip ""cleared"" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command and I only intend it to be roughly equivalent to the actual execution and I probably won't display `None` entries. I erred on the side of providing extra information but I suspect many situations will just filter out the `None`s. - Could implement more iterator stuff (like `DoubleEndedIterator`). I have not implemented new std items before so I'm uncertain if the existing issue should be reused or if a new tracking issue is needed. cc #44434",THUMBS_UP,2020-11-30T09:03:32Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-09-22T00:02:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-09-23T17:32:34Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-09-24T14:39:30Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-10-09T17:45:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-12-24T07:01:21Z,Havvy,NA https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-12-24T11:06:30Z,tux3,NA https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2020-12-24T20:04:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77035,MERGED,2020-09-21T23:27:03Z,2020-12-19T04:32:46Z,Gracefully handle mistyping -> as => in function return type,mibac138,d1741e59cb87d3c8c794eebf6d5430d1b383f51f,14,Auto merge of #77035 - mibac138:fn-fat-arrow-return r=davidtwco Gracefully handle mistyping -> as => in function return type Fixes #77019,HEART,2021-01-01T14:02:30Z,owst,owen@owenstephens.co.uk https://github.com/rust-lang/rust/pull/77051,CLOSED,2020-09-22T11:48:10Z,2020-11-11T09:45:45Z,[DO NOT MERGE] Measure cost of per function section,bjorn3,NA,NA,NA,EYES,2020-09-22T12:27:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77051,CLOSED,2020-09-22T11:48:10Z,2020-11-11T09:45:45Z,[DO NOT MERGE] Measure cost of per function section,bjorn3,NA,NA,NA,ROCKET,2020-09-22T15:07:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/77051,CLOSED,2020-09-22T11:48:10Z,2020-11-11T09:45:45Z,[DO NOT MERGE] Measure cost of per function section,bjorn3,NA,NA,NA,EYES,2020-09-22T17:11:58Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/77063,MERGED,2020-09-22T17:11:26Z,2020-09-23T05:15:51Z,Rebase LLVM onto 11.0.0-rc3,cuviper,e62323df22ecf9c163023132d17b7114f68b72e8,2,Auto merge of #77063 - cuviper:llvm-11.0.0-rc3 r=nikic Rebase LLVM onto 11.0.0-rc3 r? `@nikic`,HOORAY,2020-09-22T23:28:52Z,mati865,NA https://github.com/rust-lang/rust/pull/77065,CLOSED,2020-09-22T17:44:41Z,2021-01-19T06:01:17Z,Take 2: Add `take_...` functions to slices,timvermeulen,NA,NA,NA,THUMBS_UP,2020-09-22T18:52:41Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/77065,CLOSED,2020-09-22T17:44:41Z,2021-01-19T06:01:17Z,Take 2: Add `take_...` functions to slices,timvermeulen,NA,NA,NA,THUMBS_UP,2020-09-28T19:40:39Z,cramertj,NA https://github.com/rust-lang/rust/pull/77065,CLOSED,2020-09-22T17:44:41Z,2021-01-19T06:01:17Z,Take 2: Add `take_...` functions to slices,timvermeulen,NA,NA,NA,THUMBS_UP,2020-11-12T19:00:59Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/77074,MERGED,2020-09-22T19:38:26Z,2020-09-25T04:17:30Z,add array::from_ref,lcnr,09b0bd6022d1e029e5745ed588af311056437c17,4,Rollup merge of #77074 - lcnr:array-from-ref r=SimonSapin add array::from_ref mirrors the methods in `std::slice` with the same name. I guess this method previously didn't exist as there was close to no reason to create an array of size `1`. This will change due to const generics in the near future.,HEART,2020-09-22T20:31:54Z,est31,NA https://github.com/rust-lang/rust/pull/77074,MERGED,2020-09-22T19:38:26Z,2020-09-25T04:17:30Z,add array::from_ref,lcnr,09b0bd6022d1e029e5745ed588af311056437c17,4,Rollup merge of #77074 - lcnr:array-from-ref r=SimonSapin add array::from_ref mirrors the methods in `std::slice` with the same name. I guess this method previously didn't exist as there was close to no reason to create an array of size `1`. This will change due to const generics in the near future.,HEART,2020-09-23T08:20:30Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/77074,MERGED,2020-09-22T19:38:26Z,2020-09-25T04:17:30Z,add array::from_ref,lcnr,09b0bd6022d1e029e5745ed588af311056437c17,4,Rollup merge of #77074 - lcnr:array-from-ref r=SimonSapin add array::from_ref mirrors the methods in `std::slice` with the same name. I guess this method previously didn't exist as there was close to no reason to create an array of size `1`. This will change due to const generics in the near future.,HEART,2020-09-23T08:28:05Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/77074,MERGED,2020-09-22T19:38:26Z,2020-09-25T04:17:30Z,add array::from_ref,lcnr,09b0bd6022d1e029e5745ed588af311056437c17,4,Rollup merge of #77074 - lcnr:array-from-ref r=SimonSapin add array::from_ref mirrors the methods in `std::slice` with the same name. I guess this method previously didn't exist as there was close to no reason to create an array of size `1`. This will change due to const generics in the near future.,HEART,2020-09-23T18:08:44Z,emilazy,hello@emily.moe https://github.com/rust-lang/rust/pull/77079,MERGED,2020-09-22T22:34:02Z,2020-09-25T04:17:28Z,Use `Self` in docs when possible,poliorcetics,dc4f39c43f0f798c414474263b8d3e5b90c32e27,6,Rollup merge of #77079 - poliorcetics:more-self-in-docs r=jyn514 Use `Self` in docs when possible Fixes #76542. I used `rg '\s*//[!/]\s+fn [\w_]+\(&?self ' .` in `library/` to find instances I found some with that and some by manually checking. @rustbot modify labels: C-enhancement T-doc,THUMBS_UP,2020-09-22T23:06:31Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",HEART,2020-09-23T19:02:42Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",EYES,2020-09-23T19:37:43Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",HOORAY,2020-10-05T00:41:03Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",HOORAY,2020-10-05T19:51:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",HOORAY,2020-10-07T12:01:04Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/77080,MERGED,2020-09-22T22:41:47Z,2020-10-05T21:50:35Z,Working branch-level code coverage,richkadel,a1dfd2490a6cb456b92e469fa550dc217e20ad6d,151,"Auto merge of #77080 - richkadel:llvm-coverage-counters-2 r=tmandry Working branch-level code coverage Add a generalized implementation for computing branch-level coverage spans. This iteration resolves some of the challenges I had identified a few weeks ago. I've tried to implement a solution that is general enough to work for a lot of different graphs/patterns. It's encouraging to see the results on fairly large and complex crates seem to meet my expectations. This may be a ""functionally complete"" implementation. Except for bug fixes or edge cases I haven't run into yet the next and essentially final step I think is to replace some Counters with CounterExpressions (where their counter values can be computed by adding or subtracting other counters/expressions). Examples of branch-level coverage support enabled in this PR: * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_drop_trait.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_if_else.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_loop.txt * https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-cov-reports-base/expected_show_coverage.coverage_of_simple_match.txt * ... _and others in the same directory_ Examples of coverage analysis results (MIR spanview files) used to inject counters in the right `BasicBlocks`: * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_drop_trait/coverage_of_drop_trait.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if/coverage_of_if.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_if_else/coverage_of_if_else.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_loop/coverage_of_simple_loop.main.-------.InstrumentCoverage.0.html * https://htmlpreview.github.io/?https://github.com/richkadel/rust/blob/llvm-coverage-counters-2/src/test/run-make-fulldeps/instrument-coverage-mir-cov-html-base/expected_mir_dump.coverage_of_simple_match/coverage_of_simple_match.main.-------.InstrumentCoverage.0.html * ... _and others in the same directory_ Here is some sample coverage output after compiling a few real-world crates with the new branch-level coverage features: r? `@tmandry` FYI: `@wesleywiser`",HEART,2020-10-07T12:01:05Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/77083,MERGED,2020-09-22T23:51:50Z,2020-09-24T02:58:21Z,revert const_type_id stabilization,KodrAus,7b240a1262c467a5a0f9d5dcad9a500a56b67d34,7,Auto merge of #77083 - KodrAus:revert/const-type-id r=RalfJung revert const_type_id stabilization This reverts #72488 which is currently on beta and scheduled to stabilize in `1.47.0` based on https://github.com/rust-lang/rust/pull/75923#issuecomment-696676511 It turns out we might not be quite ready to stabilize `TypeId` in const contexts before having a chance to rework its internals. Since `TypeId` is a bit of an oddity we want to be careful about how those internals are currently being relied on while making changes. That will be easier to do without having to also consider compile-time contexts. r? `@eddyb`,EYES,2020-09-23T00:17:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77083,MERGED,2020-09-22T23:51:50Z,2020-09-24T02:58:21Z,revert const_type_id stabilization,KodrAus,7b240a1262c467a5a0f9d5dcad9a500a56b67d34,7,Auto merge of #77083 - KodrAus:revert/const-type-id r=RalfJung revert const_type_id stabilization This reverts #72488 which is currently on beta and scheduled to stabilize in `1.47.0` based on https://github.com/rust-lang/rust/pull/75923#issuecomment-696676511 It turns out we might not be quite ready to stabilize `TypeId` in const contexts before having a chance to rework its internals. Since `TypeId` is a bit of an oddity we want to be careful about how those internals are currently being relied on while making changes. That will be easier to do without having to also consider compile-time contexts. r? `@eddyb`,EYES,2020-10-01T18:50:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77087,MERGED,2020-09-23T02:27:55Z,2020-10-11T01:26:49Z,Provide structured suggestions when finding structs when expecting a trait,estebank,08764ad1638d49ee8303a8e5b1a9e439cbbc87f6,7,Auto merge of #77087 - estebank:issue-45817 r=matthewjasper Provide structured suggestions when finding structs when expecting a trait When finding an ADT in a trait object definition provide some solutions. Fix #45817. Given `::Assoc: Ty` suggest `Param: Trait`. Fix #75829.,HEART,2020-09-23T17:59:31Z,PotHix,pothix@pothix.com https://github.com/rust-lang/rust/pull/77087,MERGED,2020-09-23T02:27:55Z,2020-10-11T01:26:49Z,Provide structured suggestions when finding structs when expecting a trait,estebank,08764ad1638d49ee8303a8e5b1a9e439cbbc87f6,7,Auto merge of #77087 - estebank:issue-45817 r=matthewjasper Provide structured suggestions when finding structs when expecting a trait When finding an ADT in a trait object definition provide some solutions. Fix #45817. Given `::Assoc: Ty` suggest `Param: Trait`. Fix #75829.,HEART,2020-09-24T07:20:02Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/77087,MERGED,2020-09-23T02:27:55Z,2020-10-11T01:26:49Z,Provide structured suggestions when finding structs when expecting a trait,estebank,08764ad1638d49ee8303a8e5b1a9e439cbbc87f6,7,Auto merge of #77087 - estebank:issue-45817 r=matthewjasper Provide structured suggestions when finding structs when expecting a trait When finding an ADT in a trait object definition provide some solutions. Fix #45817. Given `::Assoc: Ty` suggest `Param: Trait`. Fix #75829.,HEART,2020-09-25T11:59:41Z,ohadravid,NA https://github.com/rust-lang/rust/pull/77106,MERGED,2020-09-23T13:48:28Z,2020-09-25T21:44:45Z,clarify that `changelog-seen = 1` goes to the beginning of config.toml,matthiaskrgr,8621ef1159d2a3fa30afb3ec65e5f678232f5723,1,Rollup merge of #77106 - matthiaskrgr:changelog_seen r=Mark-Simulacrum clarify that `changelog-seen = 1` goes to the beginning of config.toml Fixes #77105,THUMBS_UP,2020-09-25T15:14:29Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T17:09:40Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-23T17:09:51Z,lqd,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T17:09:53Z,lqd,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,ROCKET,2020-09-23T17:09:58Z,lqd,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T17:23:15Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,ROCKET,2020-09-23T17:30:32Z,tesuji,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-23T18:41:25Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T18:41:28Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,ROCKET,2020-09-23T19:04:13Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T19:06:25Z,est31,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-23T19:06:26Z,est31,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,ROCKET,2020-09-23T19:06:27Z,est31,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T20:09:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-23T20:09:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-23T23:20:22Z,mati865,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-24T04:02:25Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2020-09-24T04:02:26Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-09-24T12:16:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-10-28T00:45:12Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-12-16T16:59:25Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-12-16T20:39:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HOORAY,2020-12-21T18:44:11Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2021-02-17T10:47:32Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,HEART,2022-07-04T13:15:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77117,MERGED,2020-09-23T17:08:06Z,2020-12-16T15:39:44Z,cg_llvm: split dwarf support,davidtwco,2ba7ca2bbbff6cd424aebc654308febc00b9497a,22,Auto merge of #77117 - davidtwco:issue-34651-split-dwarf r=nagisa cg_llvm: split dwarf support cc #34651 This PR adds initial support for Split DWARF to rustc based on the implementation in Clang. ##### Current Status This PR currently has functioning split-dwarf running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary which contains the linked dwarf objects. ```shell-session $ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs $ ls foo* foo foo.belfx9afw9cmv8.rcgu.dwo foo.belfx9afw9cmv8.rcgu.o foo.foo.7rcbfp3g-cgu.0.rcgu.dwo foo.foo.7rcbfp3g-cgu.0.rcgu.o foo.foo.7rcbfp3g-cgu.1.rcgu.dwo foo.foo.7rcbfp3g-cgu.1.rcgu.o foo.foo.7rcbfp3g-cgu.2.rcgu.dwo foo.foo.7rcbfp3g-cgu.2.rcgu.o foo.foo.7rcbfp3g-cgu.3.rcgu.dwo foo.foo.7rcbfp3g-cgu.3.rcgu.o foo.foo.7rcbfp3g-cgu.4.rcgu.dwo foo.foo.7rcbfp3g-cgu.4.rcgu.o foo.foo.7rcbfp3g-cgu.5.rcgu.dwo foo.foo.7rcbfp3g-cgu.5.rcgu.o foo.foo.7rcbfp3g-cgu.6.rcgu.dwo foo.foo.7rcbfp3g-cgu.6.rcgu.o foo.foo.7rcbfp3g-cgu.7.rcgu.dwo foo.foo.7rcbfp3g-cgu.7.rcgu.o foo.dwp foo.rs $ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o # ... Compilation Unit @ offset 0x90: Length: 0x2c (32-bit) Version: 4 Abbrev Offset: 0x5b Pointer Size: 8 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit) <9c> DW_AT_stmt_list : 0xe8 DW_AT_comp_dir : (indirect string offset: 0x13b): /home/david/Projects/rust/rust0 DW_AT_GNU_dwo_name: (indirect string offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo DW_AT_GNU_dwo_id : 0x357472a2b032d7b9 DW_AT_low_pc : 0x0 DW_AT_ranges : 0x40 DW_AT_GNU_addr_base: 0x0 # ... ``` ##### To-Do I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit. - [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense. - [x] Determine whether or not there should be a single `dwo` output from rustc or one per codegen-unit as exists currently. - [x] Add tests. - [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile` which is correct but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file). r? `@nagisa` cc `@michaelwoerister` `@eddyb` `@alexcrichton` `@rust-lang/wg-incr-comp`,ROCKET,2022-07-04T13:15:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-23T18:23:13Z,varkor,NA https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-23T18:35:38Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-23T18:49:03Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-23T21:17:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-23T21:40:34Z,Avi-D-coder,avi.the.coder@gmail.com https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-24T00:19:45Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2020-09-28T12:51:45Z,Wodann,NA https://github.com/rust-lang/rust/pull/77118,MERGED,2020-09-23T18:12:26Z,2020-09-27T14:47:02Z, Stability annotations on generic parameters (take 2.5),exrook,d902752866cbbdb331e3cf28ff6bba86ab0f6c62,9,Auto merge of #77118 - exrook:stability-generic-parameters-2 r=varkor Stability annotations on generic parameters (take 2.5) Rebase of #72314 + more tests Implements rust-lang/wg-allocators#2.,HEART,2021-07-26T21:08:10Z,tema3210,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-23T21:54:27Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-23T22:43:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-24T07:01:57Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-24T09:17:28Z,darksv,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-24T15:31:23Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-24T21:01:11Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-29T02:01:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-29T04:37:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-30T11:00:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-09-30T19:05:35Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-06T22:40:52Z,lqd,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,ROCKET,2020-10-06T23:09:54Z,lqd,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-16T21:22:46Z,fmease,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,ROCKET,2020-10-16T21:22:53Z,fmease,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-17T20:14:37Z,ebroto,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-19T16:43:34Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,ROCKET,2020-10-19T16:43:35Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-19T17:06:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-10-19T17:13:30Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2020-11-05T22:31:50Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,HEART,2021-05-25T21:14:47Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/77124,MERGED,2020-09-23T21:43:21Z,2020-10-17T16:58:12Z,Implement const expressions and patterns (RFC 2920),spastorino,6af9846fcc8797bf97e9fb387385208c2219f3d0,48,Auto merge of #77124 - spastorino:const-exprs-rfc-2920 r=oli-obk Implement const expressions and patterns (RFC 2920) cc `@ecstatic-morse` `@lcnr` `@oli-obk` `@petrochenkov`,ROCKET,2021-05-25T21:14:49Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/77126,MERGED,2020-09-23T23:07:14Z,2020-09-25T21:44:40Z,Invalidate local LLVM cache less often,Mark-Simulacrum,61dc57c85a64bbc96226902136b8374df2c30ab6,2,Rollup merge of #77126 - Mark-Simulacrum:llvm-less-often r=alexcrichton Invalidate local LLVM cache less often This avoids a download of LLVM after every rebase. The downside to this is that if we land some patch affecting LLVM built in CI that breaks this option but that PR does not update the LLVM submodule we'll likely not notice until the next update -- but this seems unlikely to happen in practice and I am not personally worried about it. r? @alexcrichton,THUMBS_UP,2020-09-23T23:24:58Z,est31,NA https://github.com/rust-lang/rust/pull/77126,MERGED,2020-09-23T23:07:14Z,2020-09-25T21:44:40Z,Invalidate local LLVM cache less often,Mark-Simulacrum,61dc57c85a64bbc96226902136b8374df2c30ab6,2,Rollup merge of #77126 - Mark-Simulacrum:llvm-less-often r=alexcrichton Invalidate local LLVM cache less often This avoids a download of LLVM after every rebase. The downside to this is that if we land some patch affecting LLVM built in CI that breaks this option but that PR does not update the LLVM submodule we'll likely not notice until the next update -- but this seems unlikely to happen in practice and I am not personally worried about it. r? @alexcrichton,HEART,2020-09-23T23:57:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HEART,2020-09-24T16:38:30Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HEART,2020-09-24T17:03:31Z,est31,NA https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HEART,2020-09-24T17:30:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HEART,2020-09-26T06:06:51Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HOORAY,2020-09-26T09:26:49Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HOORAY,2020-11-02T06:13:14Z,archseer,NA https://github.com/rust-lang/rust/pull/77154,MERGED,2020-09-24T16:13:24Z,2020-09-27T07:15:17Z,Remove std::io::lazy::Lazy in favour of SyncOnceCell,m-ou-se,c9e5e6a53aef5cd1b939ecfa18f56bdf5bf0451c,5,Auto merge of #77154 - fusion-engineering-forks:lazy-stdio r=dtolnay Remove std::io::lazy::Lazy in favour of SyncOnceCell The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit and mark the streams as 'closed'. Using the stream afterwards would result in a panic. Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown to make sure no buffered output is lost. It also forbids access to stdout afterwards since the buffer is already flushed and gone. Stdin uses a BufReader which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin the atexit() function's only effect is making stdin inaccessible to the program such that later accesses result in a panic. This is uncessary as it'd have been safe to access stdin during shutdown of the program. --- This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did. However SyncOnceCell does not use atexit() to drop the contained object during shutdown. As noted above this is not a problem for stdin. It simply means stdin is now usable during shutdown. The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer making print!() available during shutdown without panicking. --- In addition because the contents of the SyncOnceCell are no longer dropped we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()` since Lazy effectively stored a `Box>` and SyncOnceCell stores the `T` directly.,HEART,2021-11-15T17:45:04Z,CodesInChaos,NA https://github.com/rust-lang/rust/pull/77157,MERGED,2020-09-24T17:43:12Z,2020-09-25T19:35:39Z,Remove duplicated SimplifyCfg pass,tmiasko,10ef7f9ebf8a497fe2ef8aa0d32b3776e85134a1,1,Auto merge of #77157 - tmiasko:simplify-cfg-dup r=jonas-schievink Remove duplicated SimplifyCfg pass,THUMBS_UP,2020-09-25T01:15:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77162,CLOSED,2020-09-24T18:36:08Z,2021-02-28T22:58:50Z,[experiment/perf] Disable jemalloc's time-delayed purging for extra determinism.,eddyb,NA,NA,NA,EYES,2020-09-24T18:38:42Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77162,CLOSED,2020-09-24T18:36:08Z,2021-02-28T22:58:50Z,[experiment/perf] Disable jemalloc's time-delayed purging for extra determinism.,eddyb,NA,NA,NA,EYES,2020-09-24T19:22:23Z,puckipedia,NA https://github.com/rust-lang/rust/pull/77168,CLOSED,2020-09-24T22:04:42Z,2020-12-18T11:46:49Z,Add Linux-specific pidfd process extensions,Aaron1011,NA,NA,NA,THUMBS_UP,2020-09-29T18:49:38Z,voidc,NA https://github.com/rust-lang/rust/pull/77170,MERGED,2020-09-24T23:31:46Z,2020-09-28T20:15:17Z,Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`,ecstatic-morse,85a59d40f102015d3493e9af301e48a6f083ef48,39,"Rollup merge of #77170 - ecstatic-morse:const-fn-ptr r=oli-obk Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]` `rustc_allow_const_fn_ptr` was a hack to work around the lack of an escape hatch for the ""min `const fn`"" checks in const-stable functions. Now that we have co-opted `allow_internal_unstable` for this purpose we no longer need a bespoke attribute. Now this functionality is gated under `const_fn_fn_ptr_basics` (how concise!) and `#[allow_internal_unstable(const_fn_fn_ptr_basics)]` replaces `#[rustc_allow_const_fn_ptr]`. `const_fn_fn_ptr_basics` allows function pointer types to appear in the arguments and locals of a `const fn` as well as function pointer casts to be performed inside a `const fn`. Both of these were allowed in constants and statics already. Notably this does **not** allow users to invoke function pointers in a const context. Presumably we will use a nicer name for that (`const_fn_ptr`?). r? @oli-obk",THUMBS_UP,2020-09-26T09:46:53Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/77170,MERGED,2020-09-24T23:31:46Z,2020-09-28T20:15:17Z,Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`,ecstatic-morse,85a59d40f102015d3493e9af301e48a6f083ef48,39,"Rollup merge of #77170 - ecstatic-morse:const-fn-ptr r=oli-obk Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]` `rustc_allow_const_fn_ptr` was a hack to work around the lack of an escape hatch for the ""min `const fn`"" checks in const-stable functions. Now that we have co-opted `allow_internal_unstable` for this purpose we no longer need a bespoke attribute. Now this functionality is gated under `const_fn_fn_ptr_basics` (how concise!) and `#[allow_internal_unstable(const_fn_fn_ptr_basics)]` replaces `#[rustc_allow_const_fn_ptr]`. `const_fn_fn_ptr_basics` allows function pointer types to appear in the arguments and locals of a `const fn` as well as function pointer casts to be performed inside a `const fn`. Both of these were allowed in constants and statics already. Notably this does **not** allow users to invoke function pointers in a const context. Presumably we will use a nicer name for that (`const_fn_ptr`?). r? @oli-obk",THUMBS_UP,2020-10-08T08:39:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,HOORAY,2020-09-25T11:42:46Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,THUMBS_UP,2020-09-25T11:42:48Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,HEART,2020-09-25T12:33:19Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,HOORAY,2020-09-25T13:17:37Z,est31,NA https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,THUMBS_UP,2020-09-25T13:18:13Z,est31,NA https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,THUMBS_UP,2021-03-01T12:37:40Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77180,CLOSED,2020-09-25T11:38:38Z,2020-10-01T08:14:04Z,[experiment] Add MustClone and impl Copy+MustClone on Range{ From Inclusive}.,eddyb,NA,NA,NA,HOORAY,2021-03-01T12:37:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-09-25T14:53:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-09-26T03:52:32Z,exrook,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-05T22:54:28Z,dkaste,darrenkaste@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-11T15:30:41Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-13T02:53:38Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-13T04:59:56Z,tesuji,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-13T15:35:31Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-23T23:44:02Z,delacian,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T00:19:02Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T00:41:33Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T03:19:41Z,naftulikay,me@naftuli.wtf https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T03:48:14Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T04:03:14Z,unrealhoang,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T04:47:40Z,ohadravid,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T05:44:39Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T05:52:03Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T06:21:11Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T06:25:06Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T08:23:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T08:43:26Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T08:47:04Z,fmease,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T08:52:20Z,myst6re,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T09:09:20Z,Virgiel,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T09:13:32Z,peterjoel,peterjoel@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T10:10:27Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T10:54:15Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T11:04:13Z,dungdm93,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T12:55:29Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T14:39:18Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T16:45:05Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T17:48:13Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T19:12:22Z,avrong,avrong@avrong.me https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-24T20:16:14Z,sirgl,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-25T09:40:11Z,darksv,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-26T07:10:52Z,Meralis40,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-26T07:18:04Z,gensmusic,gensmusic@163.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-26T15:22:08Z,oceanicdev,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T01:31:14Z,fifteen42,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T02:31:47Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T02:55:23Z,breezewish,breezewish@pingcap.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T16:16:49Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T16:17:59Z,ralfbiedert,rb@xr.io https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T17:39:10Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-27T22:38:43Z,declanvk,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-10-29T01:44:25Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-11-01T09:13:46Z,caelunshun,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-11-02T14:48:35Z,aclysma,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-11-04T09:53:23Z,elichai,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-11-21T07:06:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2020-11-30T09:17:48Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2021-02-01T05:50:13Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2021-02-13T10:10:23Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2021-02-18T18:21:17Z,0xpr03,NA https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2021-06-15T16:13:54Z,Akaito,chris@codesaru.com https://github.com/rust-lang/rust/pull/77187,MERGED,2020-09-25T14:52:47Z,2020-10-26T23:23:39Z,Support custom allocators in `Box`,TimDiekmann,fd542592f08ca0d1f7255600115c2eafdf6b5da7,30,Auto merge of #77187 - TimDiekmann:box-alloc r=Amanieu Support custom allocators in `Box` r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873 - #58457 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate Currently blocked on: - ~#77118~ - ~https://github.com/rust-lang/chalk/issues/615 (#77515)~,HOORAY,2022-07-03T01:52:57Z,rowan-sl,NA https://github.com/rust-lang/rust/pull/77195,MERGED,2020-09-25T16:07:39Z,2020-10-10T21:20:42Z,Link to documentation-specific guidelines.,follower,1b134430ef110f99f0a280c9cf604dd54275b543,1,"Rollup merge of #77195 - follower:patch-2 r=jyn514 Link to documentation-specific guidelines. Changed contribution information URL because it's not obvious how to get from the current URL to the documentation-specific content. The current URL points to this ""Getting Started"" page which contains nothing specific about documentation[*] and instead launches into how to *build* `rustc` which is not a strict prerequisite for contributing documentation fixes: * https://rustc-dev-guide.rust-lang.org/getting-started.html [*] The most specific content is a ""Writing documentation"" bullet point which is not itself a link to anything (I guess a patch for that might be helpful too). ### Why? Making this change will make it easier for people who wish to make small ""drive by"" documentation fixes (and read contribution guidelines ;) ) which I find are often how I start contributing to a project. (Exhibit A: https://github.com/rust-lang/rust/pull/77050 :) ) ### Background My impression is the change of content linked is an unintentional change due to a couple of other changes: * Originally the link pointed to `contributing.md` which started with a ""table of contents"" linking to each section. But the content in `contributing.md` was removed and replaced with a link to the ""Getting Started"" section here: * https://github.com/rust-lang/rust/commit/3f6928f1f6eff367e6ddbfb63ebc5e568ffe0eb1#diff-6a3371457528722a734f3c51d9238c13L1 But the changed link doesn't actually point to the equivalent content which is now located here: * https://rustc-dev-guide.rust-lang.org/contributing.html (If the ""Guide to Rustc Development"" is now considered the canonical location of ""How to Contribute"" content it might be a good idea to merge some of the ""Contributing"" Introduction section into the ""Getting Started"" section.) * This was then compounded by changing the link from `contributing.md` to `contributing.html` here: * https://github.com/rust-lang/rust/pull/74037/files#diff-242481015141f373dcb178e93cffa850L88 In order to even find the new location of the previous `contributing.md` content I ended up needing to do a GitHub search of the `rust-lang` org for the phrase ""Documentation improvements are very welcome"". :D",THUMBS_UP,2020-09-25T16:21:06Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77202,MERGED,2020-09-25T20:04:32Z,2020-10-01T03:28:27Z,Defer Apple SDKROOT detection to link time.,ehuss,37df40bd1c9374ca91112f2d1ea0e27127130c09,12,Rollup merge of #77202 - ehuss:defer-apple-sdkroot r=petrochenkov Defer Apple SDKROOT detection to link time. This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster. This also removes the note in the platform support documentation about these targets being missing. When I wrote it I misunderstood how the SDKROOT stuff worked. Notes: * This means that JSON spec targets can't explicitly override these flags. I think that is probably fine as I believe the value is generally required and can be set with the SDKROOT environment variable. * This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also `x86_64-apple-tvos` seems broken in general and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements). * I'm tempted to remove the use of `Result` for built-in target definitions since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980 but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now or not. Fixes #36156 Fixes #76584,HEART,2020-09-25T21:54:44Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/77202,MERGED,2020-09-25T20:04:32Z,2020-10-01T03:28:27Z,Defer Apple SDKROOT detection to link time.,ehuss,37df40bd1c9374ca91112f2d1ea0e27127130c09,12,Rollup merge of #77202 - ehuss:defer-apple-sdkroot r=petrochenkov Defer Apple SDKROOT detection to link time. This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster. This also removes the note in the platform support documentation about these targets being missing. When I wrote it I misunderstood how the SDKROOT stuff worked. Notes: * This means that JSON spec targets can't explicitly override these flags. I think that is probably fine as I believe the value is generally required and can be set with the SDKROOT environment variable. * This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also `x86_64-apple-tvos` seems broken in general and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements). * I'm tempted to remove the use of `Result` for built-in target definitions since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980 but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now or not. Fixes #36156 Fixes #76584,HEART,2020-09-26T16:50:46Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77202,MERGED,2020-09-25T20:04:32Z,2020-10-01T03:28:27Z,Defer Apple SDKROOT detection to link time.,ehuss,37df40bd1c9374ca91112f2d1ea0e27127130c09,12,Rollup merge of #77202 - ehuss:defer-apple-sdkroot r=petrochenkov Defer Apple SDKROOT detection to link time. This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster. This also removes the note in the platform support documentation about these targets being missing. When I wrote it I misunderstood how the SDKROOT stuff worked. Notes: * This means that JSON spec targets can't explicitly override these flags. I think that is probably fine as I believe the value is generally required and can be set with the SDKROOT environment variable. * This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also `x86_64-apple-tvos` seems broken in general and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements). * I'm tempted to remove the use of `Result` for built-in target definitions since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980 but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now or not. Fixes #36156 Fixes #76584,HEART,2020-09-27T02:26:43Z,simlay,NA https://github.com/rust-lang/rust/pull/77202,MERGED,2020-09-25T20:04:32Z,2020-10-01T03:28:27Z,Defer Apple SDKROOT detection to link time.,ehuss,37df40bd1c9374ca91112f2d1ea0e27127130c09,12,Rollup merge of #77202 - ehuss:defer-apple-sdkroot r=petrochenkov Defer Apple SDKROOT detection to link time. This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster. This also removes the note in the platform support documentation about these targets being missing. When I wrote it I misunderstood how the SDKROOT stuff worked. Notes: * This means that JSON spec targets can't explicitly override these flags. I think that is probably fine as I believe the value is generally required and can be set with the SDKROOT environment variable. * This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also `x86_64-apple-tvos` seems broken in general and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements). * I'm tempted to remove the use of `Result` for built-in target definitions since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980 but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now or not. Fixes #36156 Fixes #76584,HEART,2020-10-01T07:32:33Z,bbqsrc,NA https://github.com/rust-lang/rust/pull/77211,MERGED,2020-09-25T23:26:24Z,2020-09-26T19:52:56Z,Remove unused #[allow(...)] statements from compiler/,est31,9e02642fb3f1f78793c24bbad9c39368e2024968,21,Rollup merge of #77211 - est31:remove_unused_allow r=oli-obk Remove unused #[allow(...)] statements from compiler/,THUMBS_UP,2020-09-26T04:23:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/77211,MERGED,2020-09-25T23:26:24Z,2020-09-26T19:52:56Z,Remove unused #[allow(...)] statements from compiler/,est31,9e02642fb3f1f78793c24bbad9c39368e2024968,21,Rollup merge of #77211 - est31:remove_unused_allow r=oli-obk Remove unused #[allow(...)] statements from compiler/,THUMBS_UP,2020-09-26T09:11:52Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/77213,MERGED,2020-09-26T00:38:28Z,2020-10-29T06:19:31Z,rustdoc options to set default theme (and other settings),ijackson,2008d1bb0b185286d376d8e1f1093fa9ec070156,8,Rollup merge of #77213 - ijackson:wip-rustdoc-settings r=jyn514 GuillaumeGomez rustdoc options to set default theme (and other settings) Hi. This is the MR I promised in #77024 It is a little more general than I envisaged there. Once I had found the settings-handling machinery it seemed foolish to add this feature just for the theme. Closes #77024,HEART,2020-09-30T14:26:55Z,Cldfire,NA https://github.com/rust-lang/rust/pull/77229,MERGED,2020-09-26T13:42:05Z,2020-09-27T21:54:53Z,Small improvements in liveness pass,tmiasko,7f7a1cbfd3b55daee191247770627afab09eece2,4,Auto merge of #77229 - tmiasko:liveness r=lcnr Small improvements in liveness pass * Remove redundant debug logging (`add_variable` already contains logging). * Remove redundant fields for a number of live nodes and variables. * Delay conversion from a symbol to a string until linting. * Inline contents of specials struct. * Remove unnecessary local variable exit_ln. * Use newtype_index for Variable and LiveNode. * Access live nodes directly through self.lnks[ln]. No functional changes intended (except those related to the logging).,HEART,2020-09-26T17:26:17Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77229,MERGED,2020-09-26T13:42:05Z,2020-09-27T21:54:53Z,Small improvements in liveness pass,tmiasko,7f7a1cbfd3b55daee191247770627afab09eece2,4,Auto merge of #77229 - tmiasko:liveness r=lcnr Small improvements in liveness pass * Remove redundant debug logging (`add_variable` already contains logging). * Remove redundant fields for a number of live nodes and variables. * Delay conversion from a symbol to a string until linting. * Inline contents of specials struct. * Remove unnecessary local variable exit_ln. * Use newtype_index for Variable and LiveNode. * Access live nodes directly through self.lnks[ln]. No functional changes intended (except those related to the logging).,HEART,2020-09-27T08:33:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/77231,MERGED,2020-09-26T14:28:09Z,2020-09-27T02:35:15Z,Move helper function for `missing_const_for_fn` out of rustc to clippy,oli-obk,aa35c527fd4257d0eddfbd7837e87d6c2d1e75bb,5,Rollup merge of #77231 - oli-obk:clippy_const_fn r=Manishearth Move helper function for `missing_const_for_fn` out of rustc to clippy cc @rust-lang/clippy @ecstatic-morse #76618 r? @Manishearth I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work. This means we'll now have to maintain this ourselves in clippy but that's how most lints work anyway so...,HEART,2020-09-26T17:33:58Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77231,MERGED,2020-09-26T14:28:09Z,2020-09-27T02:35:15Z,Move helper function for `missing_const_for_fn` out of rustc to clippy,oli-obk,aa35c527fd4257d0eddfbd7837e87d6c2d1e75bb,5,Rollup merge of #77231 - oli-obk:clippy_const_fn r=Manishearth Move helper function for `missing_const_for_fn` out of rustc to clippy cc @rust-lang/clippy @ecstatic-morse #76618 r? @Manishearth I also removed all support for suggesting a function could be `const fn` when that would require feature gates to actually work. This means we'll now have to maintain this ourselves in clippy but that's how most lints work anyway so...,HEART,2020-09-26T21:33:12Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77236,MERGED,2020-09-26T17:34:25Z,2020-09-28T15:06:51Z,Compute underlying type of impl trait types later in compilation,matthewjasper,535d27ac9a3d45dd92769f4d4c7b9f454d1077ea,33,Auto merge of #77236 - matthewjasper:defer-typeof-impl-trait r=davidtwco Compute underlying type of impl trait types later in compilation Also change a `bug!` to `delay_span_bug` Closes #74018,HOORAY,2020-09-27T14:28:40Z,vandenheuvel,NA https://github.com/rust-lang/rust/pull/77249,MERGED,2020-09-27T01:38:53Z,2020-09-27T19:38:06Z,Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints,jyn514,2a90d31423f3b896a8ab7fd3648c09b1b16a0dab,9,Rollup merge of #77249 - jyn514:private-links r=Manishearth Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints This is not ideal because it means `deny(broken_intra_doc_links)` will no longer `deny(private_intra_doc_links)`. However it can't be fixed with a new lint group because `broken` is already in the `rustdoc` lint group; there would need to be a way to nest groups somehow. This also removes the early `return` so that the link will be generated even though it gives a warning. r? @Manishearth cc @ecstatic-morse (https://github.com/rust-lang/rust/pull/77242#issuecomment-699565095),HEART,2020-09-27T01:46:24Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77257,MERGED,2020-09-27T04:23:39Z,2020-09-29T04:54:46Z,Optimize `IntRange::from_pat` then shrink `ParamEnv`,ecstatic-morse,48cab6744786cdc5cb5428d2b64efc967ae90496,4,Auto merge of #77257 - ecstatic-morse:optimize-int-range-from-pat r=Mark-Simulacrum Optimize `IntRange::from_pat` then shrink `ParamEnv` Resolves #77058. r? `@Mark-Simulacrum` cc `@vandenheuvel` Looking at the output of `perf report` for #76244 the hot instructions seemed to be around the call to `pat_constructor` in `IntRange::from_pat`. I carried out an obvious optimization but it actually made the instruction count higher (see #77075). However it seems to have mitigated whatever was causing the pipeline stalls so when combined with #76244 it's a net win. As you can see below the regression in #76244 seems to have originated from something measured by `stalled-cycles-backend`. I'll try to collect some finer-grained stats to see if I can isolate it. I wish I had a better idea of what was going on here. I'd like to prevent the regression from reappearing in the future due to small changes in unrelated code.
Current `master`: ``` Performance counter stats for 'cargo +baseline-stage1 check': 2 275.67 msec task-clock:u # 0.998 CPUs utilized 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 49 826 page-faults:u # 0.022 M/sec 5 117 221 678 cycles:u # 2.249 GHz 299 655 943 stalled-cycles-frontend:u # 5.86% frontend cycles idle 2 284 213 395 stalled-cycles-backend:u # 44.64% backend cycles idle 8 051 871 959 instructions:u # 1.57 insn per cycle # 0.28 stalled cycles per insn 1 359 589 402 branches:u # 597.447 M/sec 7 359 347 branch-misses:u # 0.54% of all branches 2.281030026 seconds time elapsed 2.108197000 seconds user 0.164183000 seconds sys ```
Shrink `ParamEnv` without changing `IntRange::from_pat`: ``` Performance counter stats for 'cargo +perf-stage1 check': 2 751.79 msec task-clock:u # 0.996 CPUs utilized 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 50 103 page-faults:u # 0.018 M/sec 6 260 590 019 cycles:u # 2.275 GHz 317 355 920 stalled-cycles-frontend:u # 5.07% frontend cycles idle 3 397 743 582 stalled-cycles-backend:u # 54.27% backend cycles idle 8 276 224 367 instructions:u # 1.32 insn per cycle # 0.41 stalled cycles per insn 1 370 453 386 branches:u # 498.023 M/sec 7 281 031 branch-misses:u # 0.53% of all branches 2.763265838 seconds time elapsed 2.544578000 seconds user 0.204548000 seconds sys ```
Shrink `ParamEnv` and change `IntRange::from_pat`: ``` Performance counter stats for 'cargo +perf-stage1 check': 2 295.57 msec task-clock:u # 0.996 CPUs utilized 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 49 959 page-faults:u # 0.022 M/sec 5 151 407 066 cycles:u # 2.244 GHz 324 517 829 stalled-cycles-frontend:u # 6.30% frontend cycles idle 2 301 671 001 stalled-cycles-backend:u # 44.68% backend cycles idle 8 130 868 329 instructions:u # 1.58 insn per cycle # 0.28 stalled cycles per insn 1 356 618 512 branches:u # 590.972 M/sec 7 323 800 branch-misses:u # 0.54% of all branches 2.304509653 seconds time elapsed 2.128090000 seconds user 0.163909000 seconds sys ```
,HEART,2020-09-27T04:26:00Z,jackh726,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T14:13:52Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T14:22:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T14:29:01Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T14:38:42Z,JosephLing,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T14:43:25Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T15:00:26Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T15:11:47Z,DarrienG,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T15:45:05Z,passy,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T16:24:56Z,estebank,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T18:19:08Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T19:52:01Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-27T23:31:00Z,occanowey,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-28T11:23:08Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-28T12:57:00Z,romac,NA https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-28T18:19:47Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-09-28T18:41:20Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2020-10-06T00:50:12Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/77264,MERGED,2020-09-27T13:38:23Z,2020-10-03T00:42:19Z,Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. ,m-ou-se,01ca8299d48df39a1567ec39f9768d8fcb69ce7f,2,Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio r=dtolnay Only use LOCAL_{STDOUT STDERR} when set_{print/panic} is used. The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However every program will check these variables on every print even outside of testing. This involves allocating a thread local key and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So effectively only in test and benchmark runs.) When this flag is off these thread locals are not even looked at and therefore will not be initialized on the first output on every thread which also means no thread local destructors will be registered. --- Together with https://github.com/rust-lang/rust/pull/77154 this should make output a little bit more efficient.,HEART,2022-02-09T20:59:00Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/77276,MERGED,2020-09-27T19:24:30Z,2020-10-09T23:44:22Z,Warn on broken intra-doc links added to cross-crate re-exports,GuillaumeGomez,38d911dfc55a7a1eea1c80139113ed2ff0151087,12,Auto merge of #77276 - GuillaumeGomez:reexported-item-lints r=jyn514 ollie27 Warn on broken intra-doc links added to cross-crate re-exports This emits `broken_intra_doc_links` for docs applied to pub use statements that point to external items and are inlined. Does not address #77200 - any existing broken links from the original crate will not show warnings. r? `@jyn514`,HOORAY,2020-09-27T19:25:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77277,CLOSED,2020-09-27T20:28:23Z,2020-11-12T05:17:33Z,Remove intra-doc link disambiguation prefix aliases,chris-morgan,NA,NA,NA,LAUGH,2020-09-27T20:55:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77277,CLOSED,2020-09-27T20:28:23Z,2020-11-12T05:17:33Z,Remove intra-doc link disambiguation prefix aliases,chris-morgan,NA,NA,NA,LAUGH,2020-11-08T19:26:08Z,kw-fn,NA https://github.com/rust-lang/rust/pull/77277,CLOSED,2020-09-27T20:28:23Z,2020-11-12T05:17:33Z,Remove intra-doc link disambiguation prefix aliases,chris-morgan,NA,NA,NA,LAUGH,2020-11-08T19:42:49Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77280,MERGED,2020-09-27T21:24:29Z,2020-09-30T23:04:33Z,Ensure that all LLVM components requested by tests are available on CI,petrochenkov,a4dc8dae02ad78499c0c176227eb39071e1d0dd2,2,Rollup merge of #77280 - petrochenkov:llvmcomp r=Mark-Simulacrum Ensure that all LLVM components requested by tests are available on CI Addresses https://github.com/rust-lang/rust/pull/75064#issuecomment-667722652 I used an environment variable because passing a command line option all the way from CI to compiletest would be just too much hassle for this task. I added a new variable but any of the already existing ones defined by CI could be used instead. r? @Mark-Simulacrum,THUMBS_UP,2020-09-27T21:40:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77281,MERGED,2020-09-27T22:17:08Z,2020-09-30T15:03:21Z,Liveness analysis for everybody,tmiasko,939cc3e445db1eaf8b3834984e274f8c2267d9c5,8,Auto merge of #77281 - tmiasko:liveness-everybody r=oli-obk Liveness analysis for everybody Perform liveness analysis for every body instead of limiting it to fns. Fixes #77169.,HEART,2020-09-28T15:39:25Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77281,MERGED,2020-09-27T22:17:08Z,2020-09-30T15:03:21Z,Liveness analysis for everybody,tmiasko,939cc3e445db1eaf8b3834984e274f8c2267d9c5,8,Auto merge of #77281 - tmiasko:liveness-everybody r=oli-obk Liveness analysis for everybody Perform liveness analysis for every body instead of limiting it to fns. Fixes #77169.,HEART,2020-09-28T17:36:43Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77281,MERGED,2020-09-27T22:17:08Z,2020-09-30T15:03:21Z,Liveness analysis for everybody,tmiasko,939cc3e445db1eaf8b3834984e274f8c2267d9c5,8,Auto merge of #77281 - tmiasko:liveness-everybody r=oli-obk Liveness analysis for everybody Perform liveness analysis for every body instead of limiting it to fns. Fixes #77169.,HEART,2020-10-01T02:11:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/77281,MERGED,2020-09-27T22:17:08Z,2020-09-30T15:03:21Z,Liveness analysis for everybody,tmiasko,939cc3e445db1eaf8b3834984e274f8c2267d9c5,8,Auto merge of #77281 - tmiasko:liveness-everybody r=oli-obk Liveness analysis for everybody Perform liveness analysis for every body instead of limiting it to fns. Fixes #77169.,HEART,2020-10-08T08:37:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77281,MERGED,2020-09-27T22:17:08Z,2020-09-30T15:03:21Z,Liveness analysis for everybody,tmiasko,939cc3e445db1eaf8b3834984e274f8c2267d9c5,8,Auto merge of #77281 - tmiasko:liveness-everybody r=oli-obk Liveness analysis for everybody Perform liveness analysis for every body instead of limiting it to fns. Fixes #77169.,HEART,2020-10-10T15:52:20Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-28T03:58:14Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-28T06:47:21Z,mati865,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-28T10:54:01Z,toothbrush7777777,toothbrush7777777@gmail.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-28T13:11:15Z,MabezDev,scott@mabez.dev https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-28T23:51:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-29T01:12:15Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-29T04:07:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-09-29T06:18:04Z,AxlLind,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2020-09-29T06:18:06Z,AxlLind,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-10-01T10:47:10Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2020-10-04T14:09:11Z,toothbrush7777777,toothbrush7777777@gmail.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-10-08T08:36:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2020-10-08T08:36:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2020-11-12T22:06:17Z,vinc,v@vinc.cc https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2020-11-12T22:06:19Z,vinc,v@vinc.cc https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2021-03-02T20:41:22Z,ycd,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2021-03-02T20:41:24Z,ycd,NA https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HOORAY,2021-06-27T03:13:15Z,kksh3ll,kksh3ll@gmail.com https://github.com/rust-lang/rust/pull/77284,MERGED,2020-09-28T03:32:34Z,2020-09-30T23:04:31Z,"library: Forward compiler-builtins ""mem"" feature",josephlr,87387fd23ead4ca4d2dcc3ea6e4e6dbc925d6914,2,"Rollup merge of #77284 - josephlr:mem r=Mark-Simulacrum library: Forward compiler-builtins ""mem"" feature This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53 Now users will be able to do: ``` cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem ``` and correctly get the Rust implemenations for `memcpy` and friends. Signed-off-by: Joe Richey ",HEART,2021-06-27T03:13:24Z,kksh3ll,kksh3ll@gmail.com https://github.com/rust-lang/rust/pull/77296,MERGED,2020-09-28T14:02:56Z,2020-09-30T23:04:30Z,liveness: Use Option::None to represent absent live nodes,tmiasko,d4add198be2c7cc8285673ca724b330067fa2f57,1,Rollup merge of #77296 - tmiasko:liveness-option r=ecstatic-morse liveness: Use Option::None to represent absent live nodes No functional changes intended.,HEART,2020-09-28T17:06:39Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77298,MERGED,2020-09-28T14:30:55Z,2020-09-30T17:16:39Z,Don't warn if the config file is somewhere other than `config.toml`,jyn514,d92d28e523bf056ab4eb752510ec52fe4f1c6311,1,"Auto merge of #77298 - jyn514:bootstrap-config r=Mark-Simulacrum Don't warn if the config file is somewhere other than `config.toml` Previously `config.config` was always hardcoded as `""config.toml""`. I thought that it was being overridden with the actual value later but it turns out `flags.config` was being completely discarded. This keeps `config.config` in sync with `flags.config`. Fixes https://github.com/rust-lang/rust/issues/77293 r? `@Mark-Simulacrum` cc `@davidtwco`",THUMBS_UP,2020-09-28T14:31:49Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/77306,MERGED,2020-09-28T19:00:17Z,2020-10-18T18:26:07Z,normalize substs while inlining,lcnr,4d247ad7d3d2a9f72cd60e281f39b5d85bd6a463,5,Auto merge of #77306 - lcnr:inline-ok r=eddyb normalize substs while inlining fixes #68347 or more precisely this fixes the same ICE in rust analyser as veloren is pinned to a specific nightly and had an error with the current one. I didn't look into creating an MVCE here as that seems fairly annoying will spend a few minutes doing so rn. (failed) r? `@eddyb` cc `@bjorn3`,HEART,2020-10-11T14:17:53Z,tmiasko,NA https://github.com/rust-lang/rust/pull/77307,CLOSED,2020-09-28T19:26:36Z,2021-01-16T18:34:14Z,always try inlining functions which do not call other functions,lcnr,NA,NA,NA,HOORAY,2020-09-28T19:31:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77307,CLOSED,2020-09-28T19:26:36Z,2021-01-16T18:34:14Z,always try inlining functions which do not call other functions,lcnr,NA,NA,NA,HOORAY,2020-09-28T19:33:59Z,mati865,NA https://github.com/rust-lang/rust/pull/77307,CLOSED,2020-09-28T19:26:36Z,2021-01-16T18:34:14Z,always try inlining functions which do not call other functions,lcnr,NA,NA,NA,HOORAY,2020-09-28T20:20:06Z,lqd,NA https://github.com/rust-lang/rust/pull/77307,CLOSED,2020-09-28T19:26:36Z,2021-01-16T18:34:14Z,always try inlining functions which do not call other functions,lcnr,NA,NA,NA,HOORAY,2020-10-02T00:25:23Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77307,CLOSED,2020-09-28T19:26:36Z,2021-01-16T18:34:14Z,always try inlining functions which do not call other functions,lcnr,NA,NA,NA,THUMBS_UP,2020-10-06T23:35:45Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/77308,MERGED,2020-09-28T19:44:40Z,2020-09-29T02:29:16Z,[beta] backports,Mark-Simulacrum,9f0e6fa94be6f97c736e51811d7b58904edfa8cb,18,Auto merge of #77308 - Mark-Simulacrum:beta-next r=Mark-Simulacrum [beta] backports This backports the following: * revert const_type_id stabilization #77083 * [mir-opt] Disable the `ConsideredEqual` logic in SimplifyBranchSame opt #76837 * Rename Iterator::get_unchecked #77201 (manually because of file renaming and other issues on master causing literal cherry-pick to fail) * Rebase LLVM onto 11.0.0-rc3 #77063 (bumping direct to master see https://github.com/rust-lang/rust/pull/77063#issuecomment-700231036). The last two have not yet been approved by compiler team but I'm posting this now and going to go ahead and approve as I expect both to get approved and we want testing as much as possible before release in ~2 weeks. r? `@ghost`,THUMBS_UP,2020-09-28T19:51:51Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/77326,CLOSED,2020-09-29T05:24:08Z,2021-02-17T09:25:45Z,Stabilize `Option::unwrap_none` and `Option::expect_none`,Aaron1011,NA,NA,NA,HEART,2020-12-08T15:24:17Z,dcormier,NA https://github.com/rust-lang/rust/pull/77326,CLOSED,2020-09-29T05:24:08Z,2021-02-17T09:25:45Z,Stabilize `Option::unwrap_none` and `Option::expect_none`,Aaron1011,NA,NA,NA,HEART,2020-12-09T09:00:04Z,Urhengulas,johann.hemmann@code.berlin https://github.com/rust-lang/rust/pull/77326,CLOSED,2020-09-29T05:24:08Z,2021-02-17T09:25:45Z,Stabilize `Option::unwrap_none` and `Option::expect_none`,Aaron1011,NA,NA,NA,HEART,2021-01-23T17:07:13Z,booleancoercion,NA https://github.com/rust-lang/rust/pull/77326,CLOSED,2020-09-29T05:24:08Z,2021-02-17T09:25:45Z,Stabilize `Option::unwrap_none` and `Option::expect_none`,Aaron1011,NA,NA,NA,HEART,2021-02-22T04:34:42Z,trevyn,NA https://github.com/rust-lang/rust/pull/77332,CLOSED,2020-09-29T12:11:03Z,2020-09-29T16:26:44Z,No-op PR for perf testing,Mark-Simulacrum,NA,NA,NA,HEART,2020-09-29T14:17:48Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77336,MERGED,2020-09-29T14:19:15Z,2020-10-10T09:08:13Z,Always use the Rust version in package names,pietroalbini,1661f77e7b38546547207158bff2488411dd6697,4,"Auto merge of #77336 - pietroalbini:pkgname r=Mark-Simulacrum Always use the Rust version in package names The format of the tarballs produced by CI is roughly the following: {component}-{release}-{target}.{ext} While on the beta and nightly channels `{release}` is just the channel name on the stable channel is either the Rust version or the version of the component we're shipping: cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz ... This makes it really hard to get the package URL without having access to the manifest (and there is no manifest on ci-artifacts.rlo) as there is no consistent version number to use. This PR addresses the problem by always using the Rust version number as `{release}` for the stable channel regardless of the version number of the component we're shipping. I chose that instead of ""stable"" to avoid breaking the URL scheme *that* much. Rustup should not be affected by this change as it fetches the URLs from the manifest. Unfortunately we don't have a way to test other clients before making a stable release as this change only affects the stable channel. r? `@Mark-Simulacrum`",THUMBS_UP,2020-09-29T14:24:13Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77339,MERGED,2020-09-29T14:39:52Z,2020-10-23T12:02:30Z,Implement TryFrom between NonZero types.,m-ou-se,8e373304edeb5c0a3354d0152f322aec16ef6400,1,Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero r=dtolnay Implement TryFrom between NonZero types. This will instantly be stable as trait implementations for stable types and traits can not be `#[unstable]`. Closes #77258. @rustbot modify labels: +T-libs,THUMBS_UP,2020-09-29T17:45:15Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/77339,MERGED,2020-09-29T14:39:52Z,2020-10-23T12:02:30Z,Implement TryFrom between NonZero types.,m-ou-se,8e373304edeb5c0a3354d0152f322aec16ef6400,1,Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero r=dtolnay Implement TryFrom between NonZero types. This will instantly be stable as trait implementations for stable types and traits can not be `#[unstable]`. Closes #77258. @rustbot modify labels: +T-libs,HEART,2020-10-01T01:36:11Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77339,MERGED,2020-09-29T14:39:52Z,2020-10-23T12:02:30Z,Implement TryFrom between NonZero types.,m-ou-se,8e373304edeb5c0a3354d0152f322aec16ef6400,1,Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero r=dtolnay Implement TryFrom between NonZero types. This will instantly be stable as trait implementations for stable types and traits can not be `#[unstable]`. Closes #77258. @rustbot modify labels: +T-libs,HEART,2020-10-01T06:44:14Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/77339,MERGED,2020-09-29T14:39:52Z,2020-10-23T12:02:30Z,Implement TryFrom between NonZero types.,m-ou-se,8e373304edeb5c0a3354d0152f322aec16ef6400,1,Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero r=dtolnay Implement TryFrom between NonZero types. This will instantly be stable as trait implementations for stable types and traits can not be `#[unstable]`. Closes #77258. @rustbot modify labels: +T-libs,THUMBS_UP,2020-10-29T11:43:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77339,MERGED,2020-09-29T14:39:52Z,2020-10-23T12:02:30Z,Implement TryFrom between NonZero types.,m-ou-se,8e373304edeb5c0a3354d0152f322aec16ef6400,1,Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero r=dtolnay Implement TryFrom between NonZero types. This will instantly be stable as trait implementations for stable types and traits can not be `#[unstable]`. Closes #77258. @rustbot modify labels: +T-libs,HEART,2020-10-29T11:43:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77341,MERGED,2020-09-29T16:03:17Z,2020-10-07T17:32:20Z,"resolve: improve ""try using the enum's variant""",davidtwco,deec53052312ac709f6a37110b59ada486bea0bd,5,"Auto merge of #77341 - davidtwco:issue-73427-you-might-have-meant-variant r=estebank resolve: improve ""try using the enum's variant"" Fixes #73427. This PR improves the ""try using the enum's variant"" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation. r? `@estebank`",THUMBS_UP,2020-10-07T17:23:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77360,MERGED,2020-09-30T08:41:34Z,2020-10-01T03:28:08Z,References to ZSTs may be at arbitrary aligned addresses,oli-obk,cc1513b860900f87a1077193f0a1dd4e1beeb577,2,Rollup merge of #77360 - oli-obk:zst_const_pat_regression r=RalfJung References to ZSTs may be at arbitrary aligned addresses fixes #77320 r? @RalfJung,HEART,2020-10-08T08:38:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77369,MERGED,2020-09-30T17:00:22Z,2020-10-02T19:42:17Z,#NAME?,jonas-schievink,be3808108e15d84881f07af85b3145bcdd626e48,2,Auto merge of #77369 - jonas-schievink:validate-storage-liveness r=wesleywiser -Zvalidate-mir: Assert that storage is allocated on local use This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`. The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests of course).,HEART,2020-09-30T17:07:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77369,MERGED,2020-09-30T17:00:22Z,2020-10-02T19:42:17Z,#NAME?,jonas-schievink,be3808108e15d84881f07af85b3145bcdd626e48,2,Auto merge of #77369 - jonas-schievink:validate-storage-liveness r=wesleywiser -Zvalidate-mir: Assert that storage is allocated on local use This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`. The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests of course).,HEART,2020-09-30T17:27:19Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77369,MERGED,2020-09-30T17:00:22Z,2020-10-02T19:42:17Z,#NAME?,jonas-schievink,be3808108e15d84881f07af85b3145bcdd626e48,2,Auto merge of #77369 - jonas-schievink:validate-storage-liveness r=wesleywiser -Zvalidate-mir: Assert that storage is allocated on local use This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`. The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests of course).,HEART,2020-09-30T21:07:13Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/77369,MERGED,2020-09-30T17:00:22Z,2020-10-02T19:42:17Z,#NAME?,jonas-schievink,be3808108e15d84881f07af85b3145bcdd626e48,2,Auto merge of #77369 - jonas-schievink:validate-storage-liveness r=wesleywiser -Zvalidate-mir: Assert that storage is allocated on local use This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`. The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs. I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests of course).,HEART,2020-10-24T12:54:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77373,MERGED,2020-09-30T19:33:22Z,2020-10-17T19:40:08Z,Remove the old copy propagation pass,jonas-schievink,ffeeb20398bb9a25c1f75599b942f57c85a2140d,15,Auto merge of #77373 - jonas-schievink:rm-rf-copy-prop r=oli-obk Remove the old copy propagation pass This pass was added a long time ago and has not really seen much improvement since (apart from some great work in https://github.com/rust-lang/rust/pull/76569 that unfortunately ran into preexisting soundness issues). It is slow and unsound and we now have a destination propagation pass that performs a related optimization and could be extended. Closes https://github.com/rust-lang/rust/issues/36673 Closes https://github.com/rust-lang/rust/issues/73717 Closes https://github.com/rust-lang/rust/issues/76740,HOORAY,2020-09-30T19:39:54Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77373,MERGED,2020-09-30T19:33:22Z,2020-10-17T19:40:08Z,Remove the old copy propagation pass,jonas-schievink,ffeeb20398bb9a25c1f75599b942f57c85a2140d,15,Auto merge of #77373 - jonas-schievink:rm-rf-copy-prop r=oli-obk Remove the old copy propagation pass This pass was added a long time ago and has not really seen much improvement since (apart from some great work in https://github.com/rust-lang/rust/pull/76569 that unfortunately ran into preexisting soundness issues). It is slow and unsound and we now have a destination propagation pass that performs a related optimization and could be extended. Closes https://github.com/rust-lang/rust/issues/36673 Closes https://github.com/rust-lang/rust/issues/73717 Closes https://github.com/rust-lang/rust/issues/76740,HOORAY,2020-10-01T17:27:04Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77373,MERGED,2020-09-30T19:33:22Z,2020-10-17T19:40:08Z,Remove the old copy propagation pass,jonas-schievink,ffeeb20398bb9a25c1f75599b942f57c85a2140d,15,Auto merge of #77373 - jonas-schievink:rm-rf-copy-prop r=oli-obk Remove the old copy propagation pass This pass was added a long time ago and has not really seen much improvement since (apart from some great work in https://github.com/rust-lang/rust/pull/76569 that unfortunately ran into preexisting soundness issues). It is slow and unsound and we now have a destination propagation pass that performs a related optimization and could be extended. Closes https://github.com/rust-lang/rust/issues/36673 Closes https://github.com/rust-lang/rust/issues/73717 Closes https://github.com/rust-lang/rust/issues/76740,HOORAY,2020-10-02T06:40:52Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77373,MERGED,2020-09-30T19:33:22Z,2020-10-17T19:40:08Z,Remove the old copy propagation pass,jonas-schievink,ffeeb20398bb9a25c1f75599b942f57c85a2140d,15,Auto merge of #77373 - jonas-schievink:rm-rf-copy-prop r=oli-obk Remove the old copy propagation pass This pass was added a long time ago and has not really seen much improvement since (apart from some great work in https://github.com/rust-lang/rust/pull/76569 that unfortunately ran into preexisting soundness issues). It is slow and unsound and we now have a destination propagation pass that performs a related optimization and could be extended. Closes https://github.com/rust-lang/rust/issues/36673 Closes https://github.com/rust-lang/rust/issues/73717 Closes https://github.com/rust-lang/rust/issues/76740,HOORAY,2020-10-22T22:16:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77375,MERGED,2020-09-30T20:07:19Z,2020-10-02T03:06:33Z,rustc_metadata: Do not forget to encode inherent impls for foreign types,petrochenkov,b97334f65ed5092e0172fd2fa01fd6c47e5a1841,3,Rollup merge of #77375 - petrochenkov:inherext r=oli-obk rustc_metadata: Do not forget to encode inherent impls for foreign types So I tried to move FFI interface for LLVM from `rustc_codegen_llvm` to `rustc_llvm` and immediately encountered this fascinating issue. Fixes https://github.com/rust-lang/rust/issues/46665.,HEART,2020-09-30T22:55:59Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/77380,MERGED,2020-09-30T23:44:48Z,2020-10-04T08:56:26Z,Unbox mutexes and condvars on some platforms,m-ou-se,32cbc65e6bf793d99dc609d11f4a4c93176cdbe2,20,Auto merge of #77380 - fusion-engineering-forks:unbox-the-mutex r=dtolnay Unbox mutexes and condvars on some platforms Both mutexes and condition variables contained a Box containing the actual os-specific object. This was done because moving these objects may cause undefined behaviour on some platforms. However this is not needed on Windows[1] Wasm[2] cloudabi[2] and 'unsupported'[3] were the box was only needlessly making them less efficient. This change gets rid of the box on those platforms. On those platforms `Condvar` can no longer verify it is only used with one `Mutex` as mutexes no longer have a stable address. This was addressed and considered acceptable in #76932. [1]\: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializesrwlock [2]\: These are just a single atomic integer together with futex wait/wake calls/instructions. [3]\: The `unsupported` platform doesn't support multiple threads at all.,THUMBS_UP,2020-10-08T05:07:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-10-01T02:46:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-10-02T19:16:45Z,Pratyush,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-10-09T18:06:04Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-10-13T21:19:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-10-17T08:00:13Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2020-11-24T17:22:22Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-01-18T20:25:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,THUMBS_UP,2021-01-20T09:24:05Z,trevyn,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-01-20T09:24:08Z,trevyn,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-02-16T18:35:16Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,THUMBS_UP,2021-02-16T18:35:17Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,THUMBS_UP,2021-03-12T15:48:37Z,yerke,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-03-12T15:48:38Z,yerke,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-03-26T01:43:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-04-02T19:49:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-04-30T12:14:21Z,CDirkx,christiaan@dirkx.email https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-06-23T22:39:39Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/77384,CLOSED,2020-10-01T02:43:54Z,2022-02-18T19:44:52Z,Start working on proof of concept for exposing Backtrace in core,yaahc,NA,NA,NA,HEART,2021-07-06T14:12:56Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-01T15:13:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-01T18:05:38Z,est31,NA https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-01T23:13:24Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-02T09:33:44Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-07T07:03:30Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-10-07T16:36:10Z,NilsIrl,nils@nilsand.re https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-11-19T20:10:21Z,marcelbuesing,NA https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-11-20T14:16:05Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-11-20T14:49:42Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-11-21T14:26:33Z,jabedude,sinisterpatrician@gmail.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-12-03T20:36:43Z,FallenWarrior2k,github@sl.fallenwarrior.dev https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2020-12-10T03:29:27Z,daxmc99,dax@sourcegraph.com https://github.com/rust-lang/rust/pull/77386,MERGED,2020-10-01T04:29:36Z,2020-10-06T23:07:39Z,Support static linking with glibc and target-feature=+crt-static,joshtriplett,98edd1fbf8a68977a2a7c1312eb1ebff80515a92,9,Auto merge of #77386 - joshtriplett:static-glibc r=petrochenkov Support static linking with glibc and target-feature=+crt-static With this change it's possible to build on a linux-gnu target and pass RUSTFLAGS='-C target-feature=+crt-static' or the equivalent via a `.cargo/config.toml` file and get a statically linked executable. Update to libc 0.2.78 which adds support for static linking with glibc. Add `crt_static_respected` to the `linux_base` target spec. Update `android_base` and `linux_musl_base` accordingly. Avoid enabling crt_static_respected on Android platforms since that hasn't been tested. Closes https://github.com/rust-lang/rust/issues/65447.,HOORAY,2022-01-15T09:33:06Z,whalehub,admin@datahoarder.dev https://github.com/rust-lang/rust/pull/77390,CLOSED,2020-10-01T07:39:18Z,2020-10-20T09:56:50Z,Fully destructure slice and array constants into patterns,oli-obk,NA,NA,NA,ROCKET,2020-10-01T08:09:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-01T09:59:34Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-01T10:28:17Z,Enet4,NA https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-01T11:15:42Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-01T12:19:59Z,trentj,NA https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-01T13:15:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-06T01:51:48Z,fmease,NA https://github.com/rust-lang/rust/pull/77392,MERGED,2020-10-01T09:21:46Z,2020-10-24T18:22:27Z,add `insert` to `Option`,Canop,d7c635b3a514159afd3a61064772ec17cc1c44c2,1,"Rollup merge of #77392 - Canop:option_insert r=m-ou-se add `insert` to `Option` This removes a cause of `unwrap` and code complexity. This allows replacing ``` option_value = Some(build()); option_value.as_mut().unwrap() ``` with ``` option_value.insert(build()) ``` It's also useful in contexts not requiring the mutability of the reference. Here's a typical cache example: ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => { cache = Some(compute_cache_entry()); // unwrap is OK because we just filled the option &cache.as_ref().unwrap().content } }; ``` It can be changed into ``` let checked_cache = cache.as_ref().filter(|e| e.is_valid()); let content = match checked_cache { Some(e) => &e.content None => &cache.insert(compute_cache_entry()).content }; ``` *(edited: I removed `insert_with`)*",THUMBS_UP,2020-10-25T17:40:59Z,mcarton,NA https://github.com/rust-lang/rust/pull/77396,MERGED,2020-10-01T11:48:53Z,2020-10-02T13:22:33Z,Disable the SimplifyArmIdentity mir-opt,wesleywiser,4dedf5edd51d0e0b1b45a61403842f8406e13b2c,13,Auto merge of #77396 - wesleywiser:disable-simplifyarmidentity r=oli-obk Disable the SimplifyArmIdentity mir-opt The optimization still has some bugs that need to be worked out such as #77359. We can try re-enabling this again after the known issues are resolved. r? `@oli-obk`,HEART,2020-10-01T12:06:33Z,lqd,NA https://github.com/rust-lang/rust/pull/77398,MERGED,2020-10-01T12:37:13Z,2020-10-25T07:04:54Z,Upgrade to measureme 9.0.0,wesleywiser,17cc9b6256c95c31944591aec683884fead4e3b6,5,Auto merge of #77398 - wesleywiser:measureme_0_8 r=Mark-Simulacrum Upgrade to measureme 9.0.0 I believe I did this correctly but there's still a reference to `measureme@0.7.1` coming from `rustc-ap-rustc_data_structures` and I'm not sure how to resolve that. r? `@Mark-Simulacrum` We'll also need to deploy the new version of the tools on perf.rlo.,HEART,2020-10-23T09:52:31Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/77403,MERGED,2020-10-01T14:50:18Z,2020-10-01T22:37:01Z,[beta][clippy] backport multiple FP fixes for a warn-by-default lint,flip1995,e28d2bd09330ae0493caff3760e787bf4713f549,3,Auto merge of #77403 - flip1995:beta r=pietroalbini [beta][clippy] backport multiple FP fixes for a warn-by-default lint This backports the PR https://github.com/rust-lang/rust-clippy/pull/6016 fixing multiple FPs: https://github.com/rust-lang/rust-clippy/issues/5902 https://github.com/rust-lang/rust-clippy/issues/5979 https://github.com/rust-lang/rust-clippy/issues/5985 We didn't have any complaints about this lint since me merged this PR. cc `@ebroto` (sorry I forgot about this since we talked about the backport 3 weeks ago 😐) r? `@pietroalbini`,THUMBS_UP,2020-10-01T22:37:53Z,ebroto,NA https://github.com/rust-lang/rust/pull/77419,MERGED,2020-10-01T18:15:53Z,2020-10-04T06:48:33Z,Create E0777 error code for invalid argument in derive,GuillaumeGomez,830d1a0e32c7ad6d34e22e07d498f4f0eda6fb5b,6,Rollup merge of #77419 - GuillaumeGomez:create-e0777 r=jyn514 Create E0777 error code for invalid argument in derive The second commit is to fix a nit reported by @jyn514 [here](https://github.com/rust-lang/rust/pull/76406/files#r485186592).,THUMBS_UP,2020-10-01T18:37:32Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77434,MERGED,2020-10-01T22:32:46Z,2020-10-04T01:54:27Z,Returns values up to 2*usize by value,jonas-schievink,bad9ad06c00141114900c41750e961574f2ecc15,2,Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo r=nagisa Returns values up to 2*usize by value Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets. This matches what we do for functions returning `&[T]` and other fat pointers so it should be Harmless™,ROCKET,2020-10-01T23:04:50Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/77434,MERGED,2020-10-01T22:32:46Z,2020-10-04T01:54:27Z,Returns values up to 2*usize by value,jonas-schievink,bad9ad06c00141114900c41750e961574f2ecc15,2,Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo r=nagisa Returns values up to 2*usize by value Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets. This matches what we do for functions returning `&[T]` and other fat pointers so it should be Harmless™,ROCKET,2020-10-01T23:07:15Z,mati865,NA https://github.com/rust-lang/rust/pull/77434,MERGED,2020-10-01T22:32:46Z,2020-10-04T01:54:27Z,Returns values up to 2*usize by value,jonas-schievink,bad9ad06c00141114900c41750e961574f2ecc15,2,Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo r=nagisa Returns values up to 2*usize by value Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets. This matches what we do for functions returning `&[T]` and other fat pointers so it should be Harmless™,THUMBS_UP,2020-10-02T01:03:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77434,MERGED,2020-10-01T22:32:46Z,2020-10-04T01:54:27Z,Returns values up to 2*usize by value,jonas-schievink,bad9ad06c00141114900c41750e961574f2ecc15,2,Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo r=nagisa Returns values up to 2*usize by value Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets. This matches what we do for functions returning `&[T]` and other fat pointers so it should be Harmless™,ROCKET,2020-10-02T05:58:32Z,est31,NA https://github.com/rust-lang/rust/pull/77434,MERGED,2020-10-01T22:32:46Z,2020-10-04T01:54:27Z,Returns values up to 2*usize by value,jonas-schievink,bad9ad06c00141114900c41750e961574f2ecc15,2,Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo r=nagisa Returns values up to 2*usize by value Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets. This matches what we do for functions returning `&[T]` and other fat pointers so it should be Harmless™,ROCKET,2020-10-04T13:06:28Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,HOORAY,2020-10-28T20:11:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,HOORAY,2021-03-28T08:39:06Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,THUMBS_UP,2021-03-28T08:39:11Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,HOORAY,2021-06-27T10:57:17Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,HOORAY,2022-03-29T01:14:27Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/77438,CLOSED,2020-10-02T01:11:20Z,2022-06-12T06:31:41Z,BTreeMap: Support custom allocators,exrook,NA,NA,NA,THUMBS_UP,2022-05-04T05:42:59Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/77439,MERGED,2020-10-02T01:22:35Z,2020-10-05T04:59:22Z,Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics`,varkor,e032bb7c65d5444a44bda9bd7db5c42b4931b0aa,74,Rollup merge of #77439 - varkor:min_const_generics-tests r=lcnr estebank Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics` Closes https://github.com/rust-lang/rust/issues/61410. Adds `min_const_generics` tests for: - https://github.com/rust-lang/rust/issues/73727 - https://github.com/rust-lang/rust/issues/72293 - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 Adds `const_generics` tests for: - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 (I only added separate `min_const_generics` and `const_generics` tests if they were handled differently by the two features.) We need to figure out how to deduplicate when `const_generics` is stabilised but we can discuss that later. For now we should be checking neither feature breaks so require regression tests for both. I've given them identical names when I've added both which should make it easier to spot them later. r? @lcnr,HEART,2020-10-02T01:49:32Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/77439,MERGED,2020-10-02T01:22:35Z,2020-10-05T04:59:22Z,Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics`,varkor,e032bb7c65d5444a44bda9bd7db5c42b4931b0aa,74,Rollup merge of #77439 - varkor:min_const_generics-tests r=lcnr estebank Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics` Closes https://github.com/rust-lang/rust/issues/61410. Adds `min_const_generics` tests for: - https://github.com/rust-lang/rust/issues/73727 - https://github.com/rust-lang/rust/issues/72293 - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 Adds `const_generics` tests for: - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 (I only added separate `min_const_generics` and `const_generics` tests if they were handled differently by the two features.) We need to figure out how to deduplicate when `const_generics` is stabilised but we can discuss that later. For now we should be checking neither feature breaks so require regression tests for both. I've given them identical names when I've added both which should make it easier to spot them later. r? @lcnr,HEART,2020-10-02T02:06:10Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/77439,MERGED,2020-10-02T01:22:35Z,2020-10-05T04:59:22Z,Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics`,varkor,e032bb7c65d5444a44bda9bd7db5c42b4931b0aa,74,Rollup merge of #77439 - varkor:min_const_generics-tests r=lcnr estebank Fix missing diagnostic span for `impl Trait` with const generics and add various tests for `min_const_generics` and `const_generics` Closes https://github.com/rust-lang/rust/issues/61410. Adds `min_const_generics` tests for: - https://github.com/rust-lang/rust/issues/73727 - https://github.com/rust-lang/rust/issues/72293 - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 Adds `const_generics` tests for: - https://github.com/rust-lang/rust/issues/67375 - https://github.com/rust-lang/rust/issues/75153 - https://github.com/rust-lang/rust/issues/71922 - https://github.com/rust-lang/rust/issues/69913 - https://github.com/rust-lang/rust/issues/67945 - https://github.com/rust-lang/rust/issues/69239 (I only added separate `min_const_generics` and `const_generics` tests if they were handled differently by the two features.) We need to figure out how to deduplicate when `const_generics` is stabilised but we can discuss that later. For now we should be checking neither feature breaks so require regression tests for both. I've given them identical names when I've added both which should make it easier to spot them later. r? @lcnr,HEART,2020-10-02T14:02:14Z,jplatte,NA https://github.com/rust-lang/rust/pull/77452,MERGED,2020-10-02T13:44:07Z,2020-10-03T00:42:01Z,Permit ty::Bool in const generics for v0 mangling,Mark-Simulacrum,eff63980142872227dcd66bf429f7337b1b68c31,2,Rollup merge of #77452 - Mark-Simulacrum:fix-symbol-v0 r=eddyb Permit ty::Bool in const generics for v0 mangling This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway). Fixes #76365 (well it will but seems fine to close as soon as we have support) r? @eddyb (for mangling) but I'm okay with some other reviewer too :),HEART,2020-10-02T13:55:55Z,varkor,NA https://github.com/rust-lang/rust/pull/77453,MERGED,2020-10-02T14:18:38Z,2020-10-02T21:44:47Z,Stop running macOS builds on Azure Pipelines,pietroalbini,0c5f0b1c690d108df0951333b1c24f6ebc02dc0c,2,Rollup merge of #77453 - pietroalbini:ci-no-more-azure r=Mark-Simulacrum Stop running macOS builds on Azure Pipelines The Infrastructure Team agreed to migrate macOS builds to GitHub Actions so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket. We can't still fully remove the Azure Pipelines configuration as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged. r? @Mark-Simulacrum,HOORAY,2020-10-02T16:09:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77466,MERGED,2020-10-02T20:34:41Z,2020-10-05T02:49:52Z,Re-land PR #71840 (Rework MIR drop tree lowering),Aaron1011,ced813fec0fb9e883906f18b76d618baf9f5bc08,81,Auto merge of #77466 - Aaron1011:reland-drop-tree r=matthewjasper Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526) so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output) making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`,EYES,2020-10-02T20:50:24Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/77466,MERGED,2020-10-02T20:34:41Z,2020-10-05T02:49:52Z,Re-land PR #71840 (Rework MIR drop tree lowering),Aaron1011,ced813fec0fb9e883906f18b76d618baf9f5bc08,81,Auto merge of #77466 - Aaron1011:reland-drop-tree r=matthewjasper Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526) so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output) making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`,HOORAY,2020-10-02T21:11:12Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/77466,MERGED,2020-10-02T20:34:41Z,2020-10-05T02:49:52Z,Re-land PR #71840 (Rework MIR drop tree lowering),Aaron1011,ced813fec0fb9e883906f18b76d618baf9f5bc08,81,Auto merge of #77466 - Aaron1011:reland-drop-tree r=matthewjasper Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526) so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output) making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`,HOORAY,2020-10-02T21:53:30Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77466,MERGED,2020-10-02T20:34:41Z,2020-10-05T02:49:52Z,Re-land PR #71840 (Rework MIR drop tree lowering),Aaron1011,ced813fec0fb9e883906f18b76d618baf9f5bc08,81,Auto merge of #77466 - Aaron1011:reland-drop-tree r=matthewjasper Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526) so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output) making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`,HOORAY,2020-10-04T15:20:58Z,mati865,NA https://github.com/rust-lang/rust/pull/77466,MERGED,2020-10-02T20:34:41Z,2020-10-05T02:49:52Z,Re-land PR #71840 (Rework MIR drop tree lowering),Aaron1011,ced813fec0fb9e883906f18b76d618baf9f5bc08,81,Auto merge of #77466 - Aaron1011:reland-drop-tree r=matthewjasper Re-land PR #71840 (Rework MIR drop tree lowering) PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526) so let's try re-landing this PR. I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output) making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those. r? `@matthewjasper`,HOORAY,2020-10-06T17:34:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,HEART,2020-10-02T21:19:16Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,ROCKET,2020-10-02T21:19:18Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,ROCKET,2020-10-03T03:41:34Z,tesuji,NA https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,HEART,2020-10-03T19:48:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,HEART,2020-11-25T11:03:32Z,robinmoussu,NA https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,HEART,2020-11-25T17:31:25Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/77467,MERGED,2020-10-02T20:38:22Z,2020-11-26T18:51:48Z,Normalize `::T` for rustdoc,jyn514,65ecc481fac7ceced57d973a580d0a7ccbdcb192,4,Auto merge of #77467 - jyn514:query-docs r=oli-obk Normalize `::T` for rustdoc - Only run for `QPath::Resolved` with `Some` self parameter (`::T`) - Fall back to the previous behavior if the path can't be resolved The first commit is a pure refactor and should probably be reviewed by `@GuillaumeGomez.` I recommend reviewing the second commit on its own. Fixes https://github.com/rust-lang/rust/issues/77459. r? `@eddyb` cc `@danielhenrymantilla` `@lcnr`,ROCKET,2020-11-25T17:31:25Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/77469,MERGED,2020-10-02T21:37:23Z,2020-10-04T06:48:26Z,Improve rustdoc error for failed intra-doc link resolution,camelid,0ed4849a3e71f19c68d612b77bbe06c2d5b256c5,8,Rollup merge of #77469 - camelid:rustdoc-better-failed-res-error r=jyn514 Improve rustdoc error for failed intra-doc link resolution The previous error was confusing since it made it sound like you can't link to items that are defined outside the current module. Also suggested importing the item. r? @jyn514,THUMBS_UP,2020-10-03T13:46:32Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/77473,MERGED,2020-10-02T23:54:07Z,2020-10-04T06:48:24Z,Make --all-targets in x.py check opt-in,Mark-Simulacrum,69f2cf5ad9f472facb25b6057d4f6fa05a2d3bab,5,Rollup merge of #77473 - Mark-Simulacrum:check-limited r=ecstatic-morse Make --all-targets in x.py check opt-in In particular due to #76822 making this the default is currently suboptimal. r? @ecstatic-morse,HEART,2020-10-03T09:14:12Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77480,CLOSED,2020-10-03T07:45:44Z,2020-10-05T04:57:36Z,Add `try_remove` to `Vec`,ohsayan,NA,NA,NA,THUMBS_UP,2020-11-04T11:02:20Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/77486,CLOSED,2020-10-03T13:09:44Z,2020-12-08T09:51:30Z,New mir-opt pass to simplify gotos with const values,simonvandel,NA,NA,NA,HEART,2020-10-03T14:23:34Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77486,CLOSED,2020-10-03T13:09:44Z,2020-12-08T09:51:30Z,New mir-opt pass to simplify gotos with const values,simonvandel,NA,NA,NA,HEART,2020-10-04T16:55:43Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/77486,CLOSED,2020-10-03T13:09:44Z,2020-12-08T09:51:30Z,New mir-opt pass to simplify gotos with const values,simonvandel,NA,NA,NA,HEART,2020-10-05T12:48:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77486,CLOSED,2020-10-03T13:09:44Z,2020-12-08T09:51:30Z,New mir-opt pass to simplify gotos with const values,simonvandel,NA,NA,NA,HEART,2020-10-06T04:02:58Z,rrbutani,NA https://github.com/rust-lang/rust/pull/77486,CLOSED,2020-10-03T13:09:44Z,2020-12-08T09:51:30Z,New mir-opt pass to simplify gotos with const values,simonvandel,NA,NA,NA,HEART,2020-10-08T05:18:23Z,est31,NA https://github.com/rust-lang/rust/pull/77491,MERGED,2020-10-03T14:42:35Z,2020-11-25T07:25:24Z,Proposal to add Peekable::peek_mut,lukaslueg,b387f62d4d0e9aa109660c6ede426ec48cb67d53,3,"Auto merge of #77491 - lukaslueg:peek_mut r=m-ou-se Proposal to add Peekable::peek_mut A ""peekable"" iterator has a `peek()`-method which provides an immutable reference to the next item. We currently do not have a method to modify that item which we could easily add via a `peek_mut()`. See the test for a use-case (alike to my original use case) where a ""pristine"" iterator is passed on after modifying its state via `peek_mut()`. If there is interest in this I can expand on the tests and docs.",THUMBS_UP,2020-10-03T21:55:59Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/77491,MERGED,2020-10-03T14:42:35Z,2020-11-25T07:25:24Z,Proposal to add Peekable::peek_mut,lukaslueg,b387f62d4d0e9aa109660c6ede426ec48cb67d53,3,"Auto merge of #77491 - lukaslueg:peek_mut r=m-ou-se Proposal to add Peekable::peek_mut A ""peekable"" iterator has a `peek()`-method which provides an immutable reference to the next item. We currently do not have a method to modify that item which we could easily add via a `peek_mut()`. See the test for a use-case (alike to my original use case) where a ""pristine"" iterator is passed on after modifying its state via `peek_mut()`. If there is interest in this I can expand on the tests and docs.",THUMBS_UP,2020-10-04T00:43:35Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/77491,MERGED,2020-10-03T14:42:35Z,2020-11-25T07:25:24Z,Proposal to add Peekable::peek_mut,lukaslueg,b387f62d4d0e9aa109660c6ede426ec48cb67d53,3,"Auto merge of #77491 - lukaslueg:peek_mut r=m-ou-se Proposal to add Peekable::peek_mut A ""peekable"" iterator has a `peek()`-method which provides an immutable reference to the next item. We currently do not have a method to modify that item which we could easily add via a `peek_mut()`. See the test for a use-case (alike to my original use case) where a ""pristine"" iterator is passed on after modifying its state via `peek_mut()`. If there is interest in this I can expand on the tests and docs.",THUMBS_UP,2020-10-30T20:06:40Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/77491,MERGED,2020-10-03T14:42:35Z,2020-11-25T07:25:24Z,Proposal to add Peekable::peek_mut,lukaslueg,b387f62d4d0e9aa109660c6ede426ec48cb67d53,3,"Auto merge of #77491 - lukaslueg:peek_mut r=m-ou-se Proposal to add Peekable::peek_mut A ""peekable"" iterator has a `peek()`-method which provides an immutable reference to the next item. We currently do not have a method to modify that item which we could easily add via a `peek_mut()`. See the test for a use-case (alike to my original use case) where a ""pristine"" iterator is passed on after modifying its state via `peek_mut()`. If there is interest in this I can expand on the tests and docs.",THUMBS_UP,2020-11-25T11:47:19Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77492,CLOSED,2020-10-03T14:47:17Z,2022-02-07T00:26:40Z,Set `deny-warnings = false` in contributor defaults,jyn514,NA,NA,NA,THUMBS_UP,2020-12-26T11:11:32Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/77500,MERGED,2020-10-03T17:48:39Z,2020-10-03T20:43:25Z,update Miri,RalfJung,25c8c53dd994acb3f4f7c02fe6bb46076393f8b0,1,Auto merge of #77500 - RalfJung:miri r=RalfJung update Miri Fixes https://github.com/rust-lang/rust/issues/77406 r? `@ghost` Cc `@rust-lang/miri`,HOORAY,2020-10-03T18:47:17Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/77502,MERGED,2020-10-03T18:37:03Z,2020-10-27T11:44:20Z,Suggest that expressions that look like const generic arguments should be enclosed in brackets,varkor,20b1e05a8d0e1773dc840a3286aa37916e87d84b,19,Auto merge of #77502 - varkor:const-generics-suggest-enclosing-braces r=petrochenkov Suggest that expressions that look like const generic arguments should be enclosed in brackets I pulled out the changes for const expressions from https://github.com/rust-lang/rust/pull/71592 (without the trait object diagnostic changes) and made some small changes; the implementation is `@estebank's.` We're also going to want to make some changes separately to account for trait objects (they result in poor diagnostics as is evident from one of the test cases here) such as an adaption of https://github.com/rust-lang/rust/pull/72273. Fixes https://github.com/rust-lang/rust/issues/70753. r? `@petrochenkov`,HEART,2020-10-03T18:43:48Z,estebank,NA https://github.com/rust-lang/rust/pull/77502,MERGED,2020-10-03T18:37:03Z,2020-10-27T11:44:20Z,Suggest that expressions that look like const generic arguments should be enclosed in brackets,varkor,20b1e05a8d0e1773dc840a3286aa37916e87d84b,19,Auto merge of #77502 - varkor:const-generics-suggest-enclosing-braces r=petrochenkov Suggest that expressions that look like const generic arguments should be enclosed in brackets I pulled out the changes for const expressions from https://github.com/rust-lang/rust/pull/71592 (without the trait object diagnostic changes) and made some small changes; the implementation is `@estebank's.` We're also going to want to make some changes separately to account for trait objects (they result in poor diagnostics as is evident from one of the test cases here) such as an adaption of https://github.com/rust-lang/rust/pull/72273. Fixes https://github.com/rust-lang/rust/issues/70753. r? `@petrochenkov`,HEART,2020-10-22T17:18:58Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77511,MERGED,2020-10-03T21:34:30Z,2021-03-10T04:06:54Z,Add StatementKind::CopyNonOverlapping,JulianKnodt,25fd50412ed119fae398b6a31c59c6c6a9a5b94b,26,Rollup merge of #77511 - JulianKnodt:st_kind_cpy r=oli-obk Add StatementKind::CopyNonOverlapping Implements https://github.com/rust-lang/compiler-team/issues/348 r? `@nagisa`,THUMBS_UP,2021-02-14T10:57:35Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/77514,MERGED,2020-10-03T23:53:45Z,2020-10-05T04:59:13Z,Replace some once(x).chain(once(y)) with [x y] IntoIter,scottmcm,9dbc9ed870a3956d938c823338ac8943377845e8,7,Rollup merge of #77514 - scottmcm:less-once-chain-once r=estebank Replace some once(x).chain(once(y)) with [x y] IntoIter Now that we have by-value array iterators that are [already used](https://github.com/rust-lang/rust/blob/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/compiler/rustc_hir/src/def.rs#L305-L307)... For example ```diff - once(self.type_ns).chain(once(self.value_ns)).chain(once(self.macro_ns)).filter_map(|it| it) + IntoIter::new([self.type_ns self.value_ns self.macro_ns]).filter_map(|it| it) ```,HOORAY,2020-10-04T00:11:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77514,MERGED,2020-10-03T23:53:45Z,2020-10-05T04:59:13Z,Replace some once(x).chain(once(y)) with [x y] IntoIter,scottmcm,9dbc9ed870a3956d938c823338ac8943377845e8,7,Rollup merge of #77514 - scottmcm:less-once-chain-once r=estebank Replace some once(x).chain(once(y)) with [x y] IntoIter Now that we have by-value array iterators that are [already used](https://github.com/rust-lang/rust/blob/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/compiler/rustc_hir/src/def.rs#L305-L307)... For example ```diff - once(self.type_ns).chain(once(self.value_ns)).chain(once(self.macro_ns)).filter_map(|it| it) + IntoIter::new([self.type_ns self.value_ns self.macro_ns]).filter_map(|it| it) ```,HOORAY,2020-10-04T21:57:41Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/77514,MERGED,2020-10-03T23:53:45Z,2020-10-05T04:59:13Z,Replace some once(x).chain(once(y)) with [x y] IntoIter,scottmcm,9dbc9ed870a3956d938c823338ac8943377845e8,7,Rollup merge of #77514 - scottmcm:less-once-chain-once r=estebank Replace some once(x).chain(once(y)) with [x y] IntoIter Now that we have by-value array iterators that are [already used](https://github.com/rust-lang/rust/blob/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/compiler/rustc_hir/src/def.rs#L305-L307)... For example ```diff - once(self.type_ns).chain(once(self.value_ns)).chain(once(self.macro_ns)).filter_map(|it| it) + IntoIter::new([self.type_ns self.value_ns self.macro_ns]).filter_map(|it| it) ```,HOORAY,2020-10-05T05:13:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/77524,MERGED,2020-10-04T11:27:11Z,2021-01-13T23:24:50Z,Rework diagnostics for wrong number of generic args (fixes #66228 and #71924),Patryk27,a62a76047ea24aad7639f14eb3ce0e620b77bdb7,121,Auto merge of #77524 - Patryk27:fixes/66228 r=estebank Rework diagnostics for wrong number of generic args (fixes #66228 and #71924) This PR reworks the `wrong number of {} arguments` message so that it provides more details and contextual hints.,HEART,2020-11-25T02:18:49Z,estebank,NA https://github.com/rust-lang/rust/pull/77524,MERGED,2020-10-04T11:27:11Z,2021-01-13T23:24:50Z,Rework diagnostics for wrong number of generic args (fixes #66228 and #71924),Patryk27,a62a76047ea24aad7639f14eb3ce0e620b77bdb7,121,Auto merge of #77524 - Patryk27:fixes/66228 r=estebank Rework diagnostics for wrong number of generic args (fixes #66228 and #71924) This PR reworks the `wrong number of {} arguments` message so that it provides more details and contextual hints.,HOORAY,2021-01-15T13:41:31Z,sietse,NA https://github.com/rust-lang/rust/pull/77526,MERGED,2020-10-04T13:39:32Z,2020-10-25T04:49:29Z,stop promoting union field accesses in 'const',RalfJung,36a74944cbf7fd29da9ddfb13a0feb485d4ca934,3,"Auto merge of #77526 - RalfJung:dont-promote-unions r=lcnr stop promoting union field accesses in 'const' Turns out that promotion of union field accesses is the only difference between ""promotion in `const`/`static` bodies"" and ""explicit promotion"". So if we can remove this we have finally achieved what I thought to already be the case -- that the bodies of `const`/`static` initializers behave the same as explicit promotion contexts. The reason we do not want to promote union field accesses is that they can introduce UB i.e. they can go wrong. We want to [minimize the ways promoteds can fail to evaluate](https://github.com/rust-lang/const-eval/issues/53). Also this change makes things more consistent overall removing a special case that was added without much consideration (as far as I can tell). Cc `@rust-lang/wg-const-eval`",THUMBS_UP,2020-10-04T16:06:06Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77526,MERGED,2020-10-04T13:39:32Z,2020-10-25T04:49:29Z,stop promoting union field accesses in 'const',RalfJung,36a74944cbf7fd29da9ddfb13a0feb485d4ca934,3,"Auto merge of #77526 - RalfJung:dont-promote-unions r=lcnr stop promoting union field accesses in 'const' Turns out that promotion of union field accesses is the only difference between ""promotion in `const`/`static` bodies"" and ""explicit promotion"". So if we can remove this we have finally achieved what I thought to already be the case -- that the bodies of `const`/`static` initializers behave the same as explicit promotion contexts. The reason we do not want to promote union field accesses is that they can introduce UB i.e. they can go wrong. We want to [minimize the ways promoteds can fail to evaluate](https://github.com/rust-lang/const-eval/issues/53). Also this change makes things more consistent overall removing a special case that was added without much consideration (as far as I can tell). Cc `@rust-lang/wg-const-eval`",THUMBS_UP,2020-10-15T05:25:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77545,CLOSED,2020-10-04T20:20:54Z,2020-10-04T23:00:07Z,Use `RTLD_DEEPBIND` for loading dylibs/proc-macros,jonas-schievink,NA,NA,NA,HEART,2020-10-04T20:29:25Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2020-10-05T08:09:52Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2020-10-05T16:26:01Z,cramertj,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2020-10-08T01:44:11Z,fmease,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2020-10-08T09:45:34Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2020-10-08T09:45:35Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2020-10-12T21:58:30Z,comex,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2020-10-15T13:42:08Z,sandmor,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2020-11-26T08:39:04Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2020-12-17T22:29:22Z,bluss,NA https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2020-12-29T12:03:38Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,THUMBS_UP,2021-01-01T13:37:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77547,MERGED,2020-10-04T20:56:54Z,2020-10-16T22:54:28Z,stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union',RalfJung,3356ad7c26d11deef6b6da50ac21905e422bf4fb,33,Rollup merge of #77547 - RalfJung:stable-union-drop r=matthewjasper stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union' As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020) this PR proposes to stabilize parts of the `untagged_union` feature gate: * It will be possible to have a union with field type `ManuallyDrop` for any `T`. * While at it I propose we also stabilize `impl Drop for Union`; to my knowledge there are no open concerns around this feature. In the RFC discussion we also talked about allowing `&mut T` as another non-`Copy` non-dropping type but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case. Some things remain unstable and still require the `untagged_union` feature gate: * Union with fields that do not drop are not `Copy` and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as to my knowledge the borrow checker will exploit the non-dropping nature of any type but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.) Due to this quite a few tests still need the `untagged_union` feature but I think the ones where I could remove the feature flag provide good test coverage for the stable part. Cc @rust-lang/lang,HOORAY,2021-01-01T13:37:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77552,MERGED,2020-10-04T22:57:25Z,2020-10-05T11:42:01Z,Replace `(Body DefId)` with `Body` where possible,ecstatic-morse,62bfcfd8a3b1603e2b5f5e2c011aa0f35f117af1,34,"Auto merge of #77552 - ecstatic-morse:body-def-id r=lcnr Replace `(Body DefId)` with `Body` where possible Follow-up to #77430. I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId` so it's possible that I missed some cases but this should be pretty complete. Most of these changes were mechanical but there's a few places where I started calling things ""caller"" and ""callee"" when multiple `DefId`s were in-scope at once. Also we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.",THUMBS_UP,2020-10-05T08:28:18Z,marmeladema,NA https://github.com/rust-lang/rust/pull/77552,MERGED,2020-10-04T22:57:25Z,2020-10-05T11:42:01Z,Replace `(Body DefId)` with `Body` where possible,ecstatic-morse,62bfcfd8a3b1603e2b5f5e2c011aa0f35f117af1,34,"Auto merge of #77552 - ecstatic-morse:body-def-id r=lcnr Replace `(Body DefId)` with `Body` where possible Follow-up to #77430. I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId` so it's possible that I missed some cases but this should be pretty complete. Most of these changes were mechanical but there's a few places where I started calling things ""caller"" and ""callee"" when multiple `DefId`s were in-scope at once. Also we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.",HEART,2020-10-15T08:09:09Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77555,MERGED,2020-10-04T23:58:09Z,2020-10-06T10:17:51Z,Allow anyone to set regression labels,camelid,2b5049b5ea4c4c1af74286a5872d7cbdcf2aa98b,1,Rollup merge of #77555 - camelid:patch-8 r=Mark-Simulacrum Allow anyone to set regression labels Cc https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/improve.20reporting.20of.20regressions/near/212245535 r? @Mark-Simulacrum,THUMBS_UP,2020-10-05T00:15:01Z,tmandry,NA https://github.com/rust-lang/rust/pull/77555,MERGED,2020-10-04T23:58:09Z,2020-10-06T10:17:51Z,Allow anyone to set regression labels,camelid,2b5049b5ea4c4c1af74286a5872d7cbdcf2aa98b,1,Rollup merge of #77555 - camelid:patch-8 r=Mark-Simulacrum Allow anyone to set regression labels Cc https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/improve.20reporting.20of.20regressions/near/212245535 r? @Mark-Simulacrum,THUMBS_UP,2020-10-05T05:59:42Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/77555,MERGED,2020-10-04T23:58:09Z,2020-10-06T10:17:51Z,Allow anyone to set regression labels,camelid,2b5049b5ea4c4c1af74286a5872d7cbdcf2aa98b,1,Rollup merge of #77555 - camelid:patch-8 r=Mark-Simulacrum Allow anyone to set regression labels Cc https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/improve.20reporting.20of.20regressions/near/212245535 r? @Mark-Simulacrum,THUMBS_UP,2020-10-05T20:06:59Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/77566,MERGED,2020-10-05T08:55:14Z,2021-03-18T13:44:54Z,feat: Update hashbrown to instantiate less llvm IR,Marwes,0464f638af99a7c0876e9b8f96db5bbf917e3fe2,5,Auto merge of #77566 - Marwes:smaller_hashmap r=Amanieu feat: Update hashbrown to instantiate less llvm IR Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`,THUMBS_UP,2020-10-05T11:41:14Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/77566,MERGED,2020-10-05T08:55:14Z,2021-03-18T13:44:54Z,feat: Update hashbrown to instantiate less llvm IR,Marwes,0464f638af99a7c0876e9b8f96db5bbf917e3fe2,5,Auto merge of #77566 - Marwes:smaller_hashmap r=Amanieu feat: Update hashbrown to instantiate less llvm IR Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`,HEART,2020-10-05T13:11:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77566,MERGED,2020-10-05T08:55:14Z,2021-03-18T13:44:54Z,feat: Update hashbrown to instantiate less llvm IR,Marwes,0464f638af99a7c0876e9b8f96db5bbf917e3fe2,5,Auto merge of #77566 - Marwes:smaller_hashmap r=Amanieu feat: Update hashbrown to instantiate less llvm IR Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`,HEART,2021-01-20T21:31:42Z,tmiasko,NA https://github.com/rust-lang/rust/pull/77566,MERGED,2020-10-05T08:55:14Z,2021-03-18T13:44:54Z,feat: Update hashbrown to instantiate less llvm IR,Marwes,0464f638af99a7c0876e9b8f96db5bbf917e3fe2,5,Auto merge of #77566 - Marwes:smaller_hashmap r=Amanieu feat: Update hashbrown to instantiate less llvm IR Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`,HEART,2021-01-22T09:10:14Z,bluss,NA https://github.com/rust-lang/rust/pull/77566,MERGED,2020-10-05T08:55:14Z,2021-03-18T13:44:54Z,feat: Update hashbrown to instantiate less llvm IR,Marwes,0464f638af99a7c0876e9b8f96db5bbf917e3fe2,5,Auto merge of #77566 - Marwes:smaller_hashmap r=Amanieu feat: Update hashbrown to instantiate less llvm IR Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`,HEART,2021-02-04T07:58:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77578,MERGED,2020-10-05T16:27:21Z,2020-10-09T06:15:22Z,suggest `MAX` constant if -1 is assigned to unsigned type,euclio,2359ecc71fc912e84d37913b854030157fac3046,4,Auto merge of #77578 - euclio:max-suggestion r=davidtwco suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.,HEART,2020-10-06T00:32:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77578,MERGED,2020-10-05T16:27:21Z,2020-10-09T06:15:22Z,suggest `MAX` constant if -1 is assigned to unsigned type,euclio,2359ecc71fc912e84d37913b854030157fac3046,4,Auto merge of #77578 - euclio:max-suggestion r=davidtwco suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.,HEART,2020-10-06T01:06:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77578,MERGED,2020-10-05T16:27:21Z,2020-10-09T06:15:22Z,suggest `MAX` constant if -1 is assigned to unsigned type,euclio,2359ecc71fc912e84d37913b854030157fac3046,4,Auto merge of #77578 - euclio:max-suggestion r=davidtwco suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.,THUMBS_UP,2020-10-06T07:56:27Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/77578,MERGED,2020-10-05T16:27:21Z,2020-10-09T06:15:22Z,suggest `MAX` constant if -1 is assigned to unsigned type,euclio,2359ecc71fc912e84d37913b854030157fac3046,4,Auto merge of #77578 - euclio:max-suggestion r=davidtwco suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.,HEART,2020-10-07T15:28:47Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/77578,MERGED,2020-10-05T16:27:21Z,2020-10-09T06:15:22Z,suggest `MAX` constant if -1 is assigned to unsigned type,euclio,2359ecc71fc912e84d37913b854030157fac3046,4,Auto merge of #77578 - euclio:max-suggestion r=davidtwco suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.,THUMBS_UP,2020-10-17T10:18:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/77597,MERGED,2020-10-05T22:00:54Z,2020-10-08T01:37:35Z,perf: UninhabitedEnumBranching avoid n^2,simonvandel,e055f87cdfcac1f4da6c518a547dee459de0aa26,1,Auto merge of #77597 - simonvandel:uninhabited-hashset r=jonas-schievink perf: UninhabitedEnumBranching avoid n^2 Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants I have only profiled locally against `match-stress-enum` so we should have it perf tested to make sure it does not regress other crates.,HEART,2020-10-06T00:30:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77597,MERGED,2020-10-05T22:00:54Z,2020-10-08T01:37:35Z,perf: UninhabitedEnumBranching avoid n^2,simonvandel,e055f87cdfcac1f4da6c518a547dee459de0aa26,1,Auto merge of #77597 - simonvandel:uninhabited-hashset r=jonas-schievink perf: UninhabitedEnumBranching avoid n^2 Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants I have only profiled locally against `match-stress-enum` so we should have it perf tested to make sure it does not regress other crates.,HEART,2020-10-06T13:42:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77597,MERGED,2020-10-05T22:00:54Z,2020-10-08T01:37:35Z,perf: UninhabitedEnumBranching avoid n^2,simonvandel,e055f87cdfcac1f4da6c518a547dee459de0aa26,1,Auto merge of #77597 - simonvandel:uninhabited-hashset r=jonas-schievink perf: UninhabitedEnumBranching avoid n^2 Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants I have only profiled locally against `match-stress-enum` so we should have it perf tested to make sure it does not regress other crates.,HEART,2020-10-15T16:05:27Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/77597,MERGED,2020-10-05T22:00:54Z,2020-10-08T01:37:35Z,perf: UninhabitedEnumBranching avoid n^2,simonvandel,e055f87cdfcac1f4da6c518a547dee459de0aa26,1,Auto merge of #77597 - simonvandel:uninhabited-hashset r=jonas-schievink perf: UninhabitedEnumBranching avoid n^2 Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants I have only profiled locally against `match-stress-enum` so we should have it perf tested to make sure it does not regress other crates.,HEART,2020-10-15T16:46:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77610,MERGED,2020-10-06T09:50:37Z,2020-10-25T00:25:41Z,revise Hermit's mutex interface to support the behaviour of StaticMutex,stlankes,e34263d86a41dc896d025dc767c8d7c77afe219b,8,Rollup merge of #77610 - hermitcore:dtors r=m-ou-se revise Hermit's mutex interface to support the behaviour of StaticMutex rust-lang/rust#77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the new behavior of StaticMutex we move part of the mutex implementation into libstd. The interface to the OS changed. Consequently I removed a few functions which aren't longer needed.,ROCKET,2020-10-06T15:50:45Z,kamyuentse,kevin.xjy@gmail.com https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T16:27:27Z,Agrailag,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T16:37:55Z,timvermeulen,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T16:47:39Z,SLAVONchick,viacheslavkoryagin@gmail.com https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T16:53:54Z,nlinker,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T17:42:16Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",HEART,2020-10-06T17:43:45Z,panaman67,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T18:23:29Z,Apostoln,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T20:01:38Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-06T22:24:50Z,marmeladema,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",HEART,2020-10-07T03:07:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-07T06:35:48Z,ratijas,NA https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-07T15:49:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77617,MERGED,2020-10-06T15:48:29Z,2020-10-07T19:24:03Z,Eliminate bounds checking in slice::Windows,AnthonyMikh,28928c750c2c82b1bf27bd6100542f01a377e748,3,"Auto merge of #77617 - AnthonyMikh:slice_windows_no_bounds_checking r=lcnr Eliminate bounds checking in slice::Windows This is how `::next` looks right now: ```rust fn next(&mut self) -> Option<&'a [T]> { if self.size > self.v.len() { None } else { let ret = Some(&self.v[..self.size]); self.v = &self.v[1..]; ret } } ``` The line with `self.v = &self.v[1..];` relies on assumption that `self.v` is definitely not empty at this point. Else branch is taken when `self.size <= self.v.len()` so `self.v` can be empty if `self.size` is zero. In practice since `Windows` is never created directly but rather trough `[T]::windows` which panics when `size` is zero `self.size` is never zero. However the compiler doesn't know about this check so it keeps the code which checks bounds and panics. Using `NonZeroUsize` lets the compiler know about this invariant and reliably eliminate bounds checking without `unsafe` on `-O2`. Here is assembly of `Windows<'a u32>::next` before and after this change ([goldbolt](https://godbolt.org/z/xrefzx)):
Before ``` example::next: push rax mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax pop rcx ret .LBB0_2: test rcx rcx je .LBB0_5 mov rax qword ptr [rdi] mov rsi rax add rsi 4 add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx pop rcx ret .LBB0_5: lea rdx [rip + .L__unnamed_1] mov edi 1 xor esi esi call qword ptr [rip + core::slice::slice_index_order_fail@GOTPCREL] ud2 .L__unnamed_2: .ascii ""./example.rs"" .L__unnamed_1: .quad .L__unnamed_2 .asciz ""\f\000\000\000\000\000\000\000\016\000\000\000\027\000\000"" ```
After ``` example::next: mov rcx qword ptr [rdi + 8] mov rdx qword ptr [rdi + 16] cmp rdx rcx jbe .LBB0_2 xor eax eax ret .LBB0_2: mov rax qword ptr [rdi] lea rsi [rax + 4] add rcx -1 mov qword ptr [rdi] rsi mov qword ptr [rdi + 8] rcx ret ```
Note the lack of call to `core::slice::slice_index_order_fail` in second snippet. #### Possible reasons _not_ to merge this PR: * this changes the error message on panic in `[T]::windows`. However AFAIK this messages are not covered by backwards compatibility policy.",THUMBS_UP,2020-10-08T11:37:26Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77618,MERGED,2020-10-06T16:49:16Z,2020-12-14T19:08:00Z,Add fast WaitOnAddress-based thread parker for Windows.,m-ou-se,fa416394275d2468d104b8f72ac31b1ddf7ee52e,5,Auto merge of #77618 - fusion-engineering-forks:windows-parker r=Amanieu Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent) depending on which is available. Together this makes this thread parker work for Windows XP and up. Before this change park()/unpark() did not work on Windows XP: it needs condition variables which only exist since Windows Vista. --- Unfortunately NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine ReactOs and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely see all previous points) this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals Part 1 ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core) but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called) this implementation has a fast path that returns without even checking which waiting/waking API to use as the same atomic variable with compatible states is used in all cases.,HOORAY,2020-10-16T18:59:28Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/77618,MERGED,2020-10-06T16:49:16Z,2020-12-14T19:08:00Z,Add fast WaitOnAddress-based thread parker for Windows.,m-ou-se,fa416394275d2468d104b8f72ac31b1ddf7ee52e,5,Auto merge of #77618 - fusion-engineering-forks:windows-parker r=Amanieu Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent) depending on which is available. Together this makes this thread parker work for Windows XP and up. Before this change park()/unpark() did not work on Windows XP: it needs condition variables which only exist since Windows Vista. --- Unfortunately NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine ReactOs and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely see all previous points) this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals Part 1 ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core) but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called) this implementation has a fast path that returns without even checking which waiting/waking API to use as the same atomic variable with compatible states is used in all cases.,HOORAY,2020-10-19T10:41:14Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77618,MERGED,2020-10-06T16:49:16Z,2020-12-14T19:08:00Z,Add fast WaitOnAddress-based thread parker for Windows.,m-ou-se,fa416394275d2468d104b8f72ac31b1ddf7ee52e,5,Auto merge of #77618 - fusion-engineering-forks:windows-parker r=Amanieu Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent) depending on which is available. Together this makes this thread parker work for Windows XP and up. Before this change park()/unpark() did not work on Windows XP: it needs condition variables which only exist since Windows Vista. --- Unfortunately NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine ReactOs and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely see all previous points) this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals Part 1 ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core) but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called) this implementation has a fast path that returns without even checking which waiting/waking API to use as the same atomic variable with compatible states is used in all cases.,HOORAY,2020-10-29T10:03:04Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77618,MERGED,2020-10-06T16:49:16Z,2020-12-14T19:08:00Z,Add fast WaitOnAddress-based thread parker for Windows.,m-ou-se,fa416394275d2468d104b8f72ac31b1ddf7ee52e,5,Auto merge of #77618 - fusion-engineering-forks:windows-parker r=Amanieu Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent) depending on which is available. Together this makes this thread parker work for Windows XP and up. Before this change park()/unpark() did not work on Windows XP: it needs condition variables which only exist since Windows Vista. --- Unfortunately NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine ReactOs and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely see all previous points) this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals Part 1 ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core) but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called) this implementation has a fast path that returns without even checking which waiting/waking API to use as the same atomic variable with compatible states is used in all cases.,HOORAY,2020-12-24T11:27:13Z,tux3,NA https://github.com/rust-lang/rust/pull/77618,MERGED,2020-10-06T16:49:16Z,2020-12-14T19:08:00Z,Add fast WaitOnAddress-based thread parker for Windows.,m-ou-se,fa416394275d2468d104b8f72ac31b1ddf7ee52e,5,Auto merge of #77618 - fusion-engineering-forks:windows-parker r=Amanieu Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent) depending on which is available. Together this makes this thread parker work for Windows XP and up. Before this change park()/unpark() did not work on Windows XP: it needs condition variables which only exist since Windows Vista. --- Unfortunately NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine ReactOs and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely see all previous points) this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals Part 1 ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core) but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called) this implementation has a fast path that returns without even checking which waiting/waking API to use as the same atomic variable with compatible states is used in all cases.,HOORAY,2020-12-24T20:13:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77629,MERGED,2020-10-06T21:07:01Z,2020-10-10T21:20:17Z,Cleanup of `eat_while()` in lexer,Julian-Wollersberger,c14c9bafcd984fba40114917334e60fac6939683,1,Rollup merge of #77629 - Julian-Wollersberger:recomputeRawStrError r=varkor Cleanup of `eat_while()` in lexer The size of a lexer Token was inflated by the largest `TokenKind` variants `LiteralKind::RawStr` and `RawByteStr` because * it used `usize` although `u32` is sufficient in rustc since crates must be smaller than 4GB * and it stored the 20 bytes big `RawStrError` enum for error reporting. If a raw string is invalid it now needs to be reparsed to get the `RawStrError` data but that is a very cold code path. Technically this breaks other tools that depend on rustc_lexer because they are now also restricted to a max file size of 4GB. But this shouldn't matter in practice and rustc_lexer isn't stable anyway. Can I also get a perf run? Edit: This makes no difference in performance. The PR now only contains a small cleanup.,HEART,2020-10-07T03:04:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77629,MERGED,2020-10-06T21:07:01Z,2020-10-10T21:20:17Z,Cleanup of `eat_while()` in lexer,Julian-Wollersberger,c14c9bafcd984fba40114917334e60fac6939683,1,Rollup merge of #77629 - Julian-Wollersberger:recomputeRawStrError r=varkor Cleanup of `eat_while()` in lexer The size of a lexer Token was inflated by the largest `TokenKind` variants `LiteralKind::RawStr` and `RawByteStr` because * it used `usize` although `u32` is sufficient in rustc since crates must be smaller than 4GB * and it stored the 20 bytes big `RawStrError` enum for error reporting. If a raw string is invalid it now needs to be reparsed to get the `RawStrError` data but that is a very cold code path. Technically this breaks other tools that depend on rustc_lexer because they are now also restricted to a max file size of 4GB. But this shouldn't matter in practice and rustc_lexer isn't stable anyway. Can I also get a perf run? Edit: This makes no difference in performance. The PR now only contains a small cleanup.,HEART,2020-10-07T14:00:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77639,MERGED,2020-10-07T02:11:46Z,2020-10-13T08:26:23Z,Stabilize slice_partition_at_index,jagill,ec40181913b89006a0f071be75c109162de02fd2,2,Auto merge of #77639 - jagill:stabilize-slice_partition_at_index r=Amanieu Stabilize slice_partition_at_index This stabilizes slice_partition_at_index including renaming `partition_at_index*` -> `select_nth_unstable*`. Closes #55300 r? `@Amanieu`,HEART,2020-10-07T03:02:31Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77644,MERGED,2020-10-07T09:33:28Z,2020-10-08T09:50:46Z,Fix tooltip text display,GuillaumeGomez,1565699830e59a6c3c9c4e911da0ee4ea97ae560,1,Auto merge of #77644 - GuillaumeGomez:fix-tooltip-text-display r=jyn514 Fix tooltip text display Currently when we hover the icon the text doesn't show up: ![Screenshot from 2020-10-07 11-30-44](https://user-images.githubusercontent.com/3050060/95313768-cc402200-0890-11eb-95a4-a1ae8e38aee1.png) The bug was spotted by `@Nemo157` r? `@jyn514`,THUMBS_UP,2020-10-07T09:37:38Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/77651,CLOSED,2020-10-07T13:57:30Z,2020-10-08T08:11:16Z,Allow `blur` to work even when `rustdoc` is not the main ``,GuillaumeGomez,NA,NA,NA,HEART,2020-10-07T13:58:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77657,MERGED,2020-10-07T16:25:04Z,2020-10-16T02:28:32Z,Cleanup cloudabi mutexes and condvars,m-ou-se,9b8c0eb107f75cf154b814cee10113c0359fefcf,3,Rollup merge of #77657 - fusion-engineering-forks:cleanup-cloudabi-sync r=dtolnay Cleanup cloudabi mutexes and condvars This gets rid of lots of unnecessary unsafety. All the AtomicU32s were wrapped in UnsafeCell or UnsafeCell and raw pointers were used to get to the AtomicU32 inside. This change cleans that up by using AtomicU32 directly. Also replaces a UnsafeCell by a safer Cell. @rustbot modify labels: +C-cleanup,THUMBS_UP,2020-10-07T17:14:31Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/77665,CLOSED,2020-10-07T19:08:32Z,2020-11-25T15:11:21Z,Add a MIR pass manager,ecstatic-morse,NA,NA,NA,HEART,2020-10-07T20:14:42Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/77665,CLOSED,2020-10-07T19:08:32Z,2020-11-25T15:11:21Z,Add a MIR pass manager,ecstatic-morse,NA,NA,NA,HEART,2020-10-08T03:09:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77665,CLOSED,2020-10-07T19:08:32Z,2020-11-25T15:11:21Z,Add a MIR pass manager,ecstatic-morse,NA,NA,NA,HEART,2020-10-08T09:44:07Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77665,CLOSED,2020-10-07T19:08:32Z,2020-11-25T15:11:21Z,Add a MIR pass manager,ecstatic-morse,NA,NA,NA,HEART,2020-10-08T12:30:45Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77665,CLOSED,2020-10-07T19:08:32Z,2020-11-25T15:11:21Z,Add a MIR pass manager,ecstatic-morse,NA,NA,NA,HEART,2020-10-09T21:32:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-07T19:09:44Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-07T19:41:01Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-08T14:29:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-08T15:11:10Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-14T19:23:00Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/77666,MERGED,2020-10-07T19:09:02Z,2020-10-16T09:59:24Z,Vxworks / Unix deduplication,m-ou-se,95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3,43,"Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup r=dtolnay Vxworks / Unix deduplication `sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes so are deleted. I've added some minor `cfg(target_os = ""vxworks"")`-specific things to `sys/unix` to allow for deduplication. Before this change the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`. It's probably good to merge `sys/vxworks` entirely into `sys/unix` but it might be better to to that in a follow-up PR. `@rustbot` modify labels: +T-libs +C-cleanup",HOORAY,2020-10-22T23:58:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HOORAY,2020-10-07T21:48:17Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HOORAY,2020-10-07T21:48:25Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HOORAY,2020-10-07T22:27:55Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HEART,2020-10-08T00:23:13Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HOORAY,2020-10-15T16:31:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HOORAY,2020-11-01T09:51:14Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/77672,MERGED,2020-10-07T21:14:45Z,2020-10-16T02:28:30Z,Simplify doc-cfg rendering based on the current context,Nemo157,71b0ea62354686553d180ad6f192c234c97501f2,6,Rollup merge of #77672 - Nemo157:simplify-cfg r=jyn514 Simplify doc-cfg rendering based on the current context For sub-items on a page don't show cfg that has already been rendered on a parent item. At its simplest this means not showing anything that is shown in the portability message at the top of the page but also for things like fields of an enum variant if that variant itself is cfg-gated then don't repeat those cfg on each field of the variant. This does not touch trait implementation rendering as that is more complex and there are existing issues around how it deals with doc-cfg that need to be fixed first. ### Screenshots left is current right is new: ![image](https://user-images.githubusercontent.com/81079/95387261-c2e6a200-08f0-11eb-90d4-0a9734acd922.png) ![image](https://user-images.githubusercontent.com/81079/95387458-06411080-08f1-11eb-81f7-5dd7f37695dd.png) ![image](https://user-images.githubusercontent.com/81079/95387702-6637b700-08f1-11eb-82f4-46b6cd9b24f2.png) ![image](https://user-images.githubusercontent.com/81079/95387905-b9aa0500-08f1-11eb-8d95-8b618d31d419.png) ![image](https://user-images.githubusercontent.com/81079/95388300-5bc9ed00-08f2-11eb-9ac9-b92cbdb60b89.png) cc #43781,HEART,2021-09-04T22:56:22Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/77680,CLOSED,2020-10-07T23:10:08Z,2020-10-11T13:12:53Z,Turn on UnreachablePropagation by default,jonas-schievink,NA,NA,NA,ROCKET,2020-10-07T23:20:24Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77688,CLOSED,2020-10-08T02:04:21Z,2020-12-28T10:36:45Z,Add built-in implementations of `Default` for function definition and…,Diggsey,NA,NA,NA,THUMBS_DOWN,2020-10-28T20:50:09Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/77688,CLOSED,2020-10-08T02:04:21Z,2020-12-28T10:36:45Z,Add built-in implementations of `Default` for function definition and…,Diggsey,NA,NA,NA,THUMBS_DOWN,2020-11-20T09:57:51Z,stijnh,s.heldens@esciencecenter.nl https://github.com/rust-lang/rust/pull/77688,CLOSED,2020-10-08T02:04:21Z,2020-12-28T10:36:45Z,Add built-in implementations of `Default` for function definition and…,Diggsey,NA,NA,NA,THUMBS_DOWN,2020-12-10T11:12:05Z,AlexStrNik,alex.str.nik@gmail.com https://github.com/rust-lang/rust/pull/77690,MERGED,2020-10-08T04:19:37Z,2020-10-09T15:18:53Z,Simplify some code in rustc_llvm/build.rs now that LLVM 8 is required,est31,53a4c3b0baed8fb224e19380c576c86c12c38d8c,1,Auto merge of #77690 - est31:llvm_8_required r=matthewjasper Simplify some code in rustc_llvm/build.rs now that LLVM 8 is required LLVM 8 is required since 8506bb006040cf8e8cb004202706c81e62ddacee so this is safe to do.,HEART,2020-10-08T14:46:59Z,panaman67,NA https://github.com/rust-lang/rust/pull/77691,MERGED,2020-10-08T05:13:24Z,2020-11-17T01:15:02Z,Rename/Deprecate LayoutErr in favor of LayoutError,exrook,5bbf75da78393343b155c8bfcf1ef9c0234d9ab1,5,Rollup merge of #77691 - exrook:rename-layouterr r=KodrAus Rename/Deprecate LayoutErr in favor of LayoutError Implements rust-lang/wg-allocators#73. This patch renames LayoutErr to LayoutError and uses a type alias to support users using the old name. The new name will be instantly stable in release 1.49 (current nightly) the type alias will become deprecated in release 1.51 (so that when the current nightly is 1.51 1.49 will be stable). This is the only error type in `std` that ends in `Err` rather than `Error` if this PR lands all stdlib error types will end in `Error` :smiling_face_with_three_hearts:,EYES,2020-10-08T13:10:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/77691,MERGED,2020-10-08T05:13:24Z,2020-11-17T01:15:02Z,Rename/Deprecate LayoutErr in favor of LayoutError,exrook,5bbf75da78393343b155c8bfcf1ef9c0234d9ab1,5,Rollup merge of #77691 - exrook:rename-layouterr r=KodrAus Rename/Deprecate LayoutErr in favor of LayoutError Implements rust-lang/wg-allocators#73. This patch renames LayoutErr to LayoutError and uses a type alias to support users using the old name. The new name will be instantly stable in release 1.49 (current nightly) the type alias will become deprecated in release 1.51 (so that when the current nightly is 1.51 1.49 will be stable). This is the only error type in `std` that ends in `Err` rather than `Error` if this PR lands all stdlib error types will end in `Error` :smiling_face_with_three_hearts:,EYES,2020-11-03T01:53:00Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77692,MERGED,2020-10-08T05:22:36Z,2020-12-24T10:27:20Z,Added better error message for shared borrow treated as unique for purposes of lifetimes,PankajChaudhary5,c34c015fe2710caf53ba7ae9d1644f9ba65a6f74,8,Auto merge of #77692 - PankajChaudhary5:issue-76630 r=davidtwco Added better error message for shared borrow treated as unique for purposes of lifetimes Part of Issue #76630 r? `@jyn514`,EYES,2020-10-08T13:33:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/77699,MERGED,2020-10-08T11:28:46Z,2020-10-12T21:03:57Z,Add word wrap for short descriptions,GuillaumeGomez,a6cc660774354d51d2a1a11c24a9bfee0c3f97aa,1,Rollup merge of #77699 - GuillaumeGomez:word-wrap r=XAMPPRocky Add word wrap for short descriptions Fixes #77652 ![Screenshot from 2020-10-08 13-26-18](https://user-images.githubusercontent.com/3050060/95452770-11845280-096a-11eb-80da-723da85261fa.png) cc @WaffleLapkin r? @jyn514,HEART,2020-10-08T14:58:18Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/77704,MERGED,2020-10-08T13:32:27Z,2021-04-22T18:17:32Z,Implement indexing slices with pairs of core::ops::Bound,AnthonyMikh,ccf171242bb00dd17ac4b844e6afe77fabd04b78,2,Auto merge of #77704 - AnthonyMikh:slice_index_with_ops_bound_pair r=m-ou-se Implement indexing slices with pairs of core::ops::Bound Closes #49976. I am not sure about code duplication between `check_range` and `into_maybe_range`. Should be former implemented in terms of the latter? Also this PR doesn't address code duplication between `impl SliceIndex for Range*`.,HEART,2020-10-11T06:50:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77704,MERGED,2020-10-08T13:32:27Z,2021-04-22T18:17:32Z,Implement indexing slices with pairs of core::ops::Bound,AnthonyMikh,ccf171242bb00dd17ac4b844e6afe77fabd04b78,2,Auto merge of #77704 - AnthonyMikh:slice_index_with_ops_bound_pair r=m-ou-se Implement indexing slices with pairs of core::ops::Bound Closes #49976. I am not sure about code duplication between `check_range` and `into_maybe_range`. Should be former implemented in terms of the latter? Also this PR doesn't address code duplication between `impl SliceIndex for Range*`.,EYES,2020-12-10T21:15:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77704,MERGED,2020-10-08T13:32:27Z,2021-04-22T18:17:32Z,Implement indexing slices with pairs of core::ops::Bound,AnthonyMikh,ccf171242bb00dd17ac4b844e6afe77fabd04b78,2,Auto merge of #77704 - AnthonyMikh:slice_index_with_ops_bound_pair r=m-ou-se Implement indexing slices with pairs of core::ops::Bound Closes #49976. I am not sure about code duplication between `check_range` and `into_maybe_range`. Should be former implemented in terms of the latter? Also this PR doesn't address code duplication between `impl SliceIndex for Range*`.,HEART,2021-01-24T18:11:13Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/77706,CLOSED,2020-10-08T13:47:46Z,2020-10-10T11:28:05Z,Remove SimplifyBranchSame MIR optimization,tmiasko,NA,NA,NA,HEART,2020-10-08T14:45:25Z,panaman67,NA https://github.com/rust-lang/rust/pull/77706,CLOSED,2020-10-08T13:47:46Z,2020-10-10T11:28:05Z,Remove SimplifyBranchSame MIR optimization,tmiasko,NA,NA,NA,HEART,2020-10-08T14:48:25Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/77716,MERGED,2020-10-08T19:23:43Z,2020-10-24T18:22:10Z,"Revert ""Allow dynamic linking for iOS/tvOS targets.""",francesca64,fb92b70f95205f98a8f863cdf94734b9647ff20d,1,"Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking r=jonas-schievink Revert ""Allow dynamic linking for iOS/tvOS targets."" This reverts PR #73516. On macOS I compile static libs for iOS automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile) which has worked smoothly for the past 2 years. However upon updating to Rust 1.46.0 I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above. For most projects tested apps now immediately crash with a message like this: ``` dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example Reason: image not found dyld: launch loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib ``` This can be reproduced by using cargo-mobile to generate a winit example project and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`). In our projects that depend on DisplayLink the build instead fails with a linker error: ``` = note: Undefined symbols for architecture arm64: ""_CACurrentMediaTime"" referenced from: display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) ld: symbol(s) not found for architecture arm64 ``` After reverting the change to enable dynamic linking on iOS everything works the same as it did on Rust 1.45.2 for me. In the future would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production so I'd gladly provide testing. cc @aspenluxxxy",THUMBS_DOWN,2020-10-15T14:18:34Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/77716,MERGED,2020-10-08T19:23:43Z,2020-10-24T18:22:10Z,"Revert ""Allow dynamic linking for iOS/tvOS targets.""",francesca64,fb92b70f95205f98a8f863cdf94734b9647ff20d,1,"Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking r=jonas-schievink Revert ""Allow dynamic linking for iOS/tvOS targets."" This reverts PR #73516. On macOS I compile static libs for iOS automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile) which has worked smoothly for the past 2 years. However upon updating to Rust 1.46.0 I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above. For most projects tested apps now immediately crash with a message like this: ``` dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example Reason: image not found dyld: launch loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib ``` This can be reproduced by using cargo-mobile to generate a winit example project and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`). In our projects that depend on DisplayLink the build instead fails with a linker error: ``` = note: Undefined symbols for architecture arm64: ""_CACurrentMediaTime"" referenced from: display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) ld: symbol(s) not found for architecture arm64 ``` After reverting the change to enable dynamic linking on iOS everything works the same as it did on Rust 1.45.2 for me. In the future would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production so I'd gladly provide testing. cc @aspenluxxxy",THUMBS_DOWN,2021-05-28T20:33:43Z,Diatrus,NA https://github.com/rust-lang/rust/pull/77716,MERGED,2020-10-08T19:23:43Z,2020-10-24T18:22:10Z,"Revert ""Allow dynamic linking for iOS/tvOS targets.""",francesca64,fb92b70f95205f98a8f863cdf94734b9647ff20d,1,"Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking r=jonas-schievink Revert ""Allow dynamic linking for iOS/tvOS targets."" This reverts PR #73516. On macOS I compile static libs for iOS automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile) which has worked smoothly for the past 2 years. However upon updating to Rust 1.46.0 I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above. For most projects tested apps now immediately crash with a message like this: ``` dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example Reason: image not found dyld: launch loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib ``` This can be reproduced by using cargo-mobile to generate a winit example project and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`). In our projects that depend on DisplayLink the build instead fails with a linker error: ``` = note: Undefined symbols for architecture arm64: ""_CACurrentMediaTime"" referenced from: display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o) ld: symbol(s) not found for architecture arm64 ``` After reverting the change to enable dynamic linking on iOS everything works the same as it did on Rust 1.45.2 for me. In the future would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production so I'd gladly provide testing. cc @aspenluxxxy",THUMBS_DOWN,2022-03-27T23:27:07Z,nyuszika7h,NA https://github.com/rust-lang/rust/pull/77722,MERGED,2020-10-08T21:12:04Z,2020-10-14T00:27:17Z,Remove unsafety from sys/unsupported and add deny(unsafe_op_in_unsafe_fn).,m-ou-se,cc5a1aad4e2d45ab4da71a1807da9aa6f9e846aa,6,Rollup merge of #77722 - fusion-engineering-forks:safe-unsupported-locks r=Mark-Simulacrum Remove unsafety from sys/unsupported and add deny(unsafe_op_in_unsafe_fn). Replacing `UnsafeCell`s by a `Cell`s simplifies things and makes the mutex and rwlock implementations safe. Other than that only unsafety in strlen() contained unsafe code. @rustbot modify labels: +F-unsafe-block-in-unsafe-fn +C-cleanup,HEART,2020-10-09T00:42:09Z,panaman67,NA https://github.com/rust-lang/rust/pull/77726,MERGED,2020-10-08T22:01:02Z,2020-10-21T13:39:40Z,Add Pin::static_ref static_mut.,m-ou-se,ff3c8cb5182ae5ffee4cd47dbabbe981f859c40f,1,Rollup merge of #77726 - fusion-engineering-forks:static-pin r=dtolnay Add Pin::static_ref static_mut. This adds `Pin::static_ref` and `Pin::static_mut` which convert a static reference to a pinned static reference. Static references are effectively already pinned as what they refer to has to live forever and can never be moved. --- Context: I want to update the `sys` and `sys_common` mutexes/rwlocks/condvars to use `Pin<&self>` in their functions instead of only warning in the unsafety comments that they may not be moved. That should make them a little bit less dangerous to use. Putting such an object in a `static` (e.g. through `sys_common::StaticMutex`) fulfills the requirements about never moving it but right now there's no safe way to get a `Pin<&T>` to a `static`. This solves that.,HOORAY,2020-10-30T09:40:09Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77748,MERGED,2020-10-09T11:25:22Z,2020-10-10T21:20:02Z,Dead code cleanup in windows-gnu std,mati865,83685880b6de32e9781bea09d3d54decd195a9dd,3,Rollup merge of #77748 - mati865:dead-code-cleanup r=petrochenkov Dead code cleanup in windows-gnu std Closes https://github.com/rust-lang/rust/issues/77622 This is the only leftover I could find.,HEART,2020-10-09T18:44:21Z,panaman67,NA https://github.com/rust-lang/rust/pull/77750,CLOSED,2020-10-09T11:37:09Z,2020-11-16T09:17:44Z,[stable] Backport Clippy ICE fix to stable,flip1995,NA,NA,NA,HOORAY,2020-10-09T12:15:22Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/77761,MERGED,2020-10-09T18:16:48Z,2020-10-20T05:27:54Z,Assert that pthread mutex initialization succeeded,tmiasko,b09ef114bbd5f057803fc99f0b78a01e7c1138fa,3,Rollup merge of #77761 - tmiasko:pthread-mutex r=cuviper Assert that pthread mutex initialization succeeded If pthread mutex initialization fails the failure will go unnoticed unless debug assertions are enabled. Any subsequent use of mutex will also silently fail since return values from lock & unlock operations are similarly checked only through debug assertions. In some implementations the mutex initialization requires a memory allocation and so it does fail in practice. Assert that initialization succeeds to ensure that mutex guarantees mutual exclusion. Fixes #34966.,HOORAY,2020-10-20T00:17:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77761,MERGED,2020-10-09T18:16:48Z,2020-10-20T05:27:54Z,Assert that pthread mutex initialization succeeded,tmiasko,b09ef114bbd5f057803fc99f0b78a01e7c1138fa,3,Rollup merge of #77761 - tmiasko:pthread-mutex r=cuviper Assert that pthread mutex initialization succeeded If pthread mutex initialization fails the failure will go unnoticed unless debug assertions are enabled. Any subsequent use of mutex will also silently fail since return values from lock & unlock operations are similarly checked only through debug assertions. In some implementations the mutex initialization requires a memory allocation and so it does fail in practice. Assert that initialization succeeds to ensure that mutex guarantees mutual exclusion. Fixes #34966.,HOORAY,2020-10-20T05:33:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/77768,CLOSED,2020-10-09T21:07:46Z,2020-10-21T21:17:41Z,Rename ty::TyKind to ty::TyData Ty::kind to Ty::data,vandenheuvel,NA,NA,NA,CONFUSED,2020-10-10T10:19:15Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/77769,MERGED,2020-10-09T21:13:00Z,2020-10-11T09:50:33Z,Auto-prioritize issues with `regression-untriaged`,camelid,c6bebc14a14de81848f24353227244860f2ecdaf,1,Auto merge of #77769 - camelid:regression-untriaged r=jyn514 Auto-prioritize issues with `regression-untriaged` This auto-prioritizes issues with the `regression-untriaged` label. (I just added it per .) Cc #77725 r? `@Mark-Simulacrum`,THUMBS_UP,2020-10-09T21:49:48Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/77780,MERGED,2020-10-10T04:48:22Z,2020-10-16T02:28:21Z,rustc_parse: fix spans on cast and range exprs with attrs,calebcartwright,9d8bf44409b5892525264f0b67179fa42e57c2f0,1,Rollup merge of #77780 - calebcartwright:cast-expr-attr-span r=oli-obk rustc_parse: fix spans on cast and range exprs with attrs Currently the span for cast and range expressions does not include the span of attributes associated to the lhs which is causing some issues for us in rustfmt. ```rust fn foo() -> i64 { #[attr] 1u64 as i64 } fn bar() -> Range { #[attr] 1..2 } ``` This corrects the span for cast and range expressions to fully include the span of child nodes,THUMBS_UP,2020-10-16T03:10:31Z,tesuji,NA https://github.com/rust-lang/rust/pull/77781,CLOSED,2020-10-10T08:36:06Z,2020-10-16T08:48:24Z,Feature request move part of std::io into core::io to be used by rust-libc such as relibc,lygstate,NA,NA,NA,EYES,2020-10-10T14:46:33Z,tesuji,NA https://github.com/rust-lang/rust/pull/77781,CLOSED,2020-10-10T08:36:06Z,2020-10-16T08:48:24Z,Feature request move part of std::io into core::io to be used by rust-libc such as relibc,lygstate,NA,NA,NA,CONFUSED,2020-10-10T16:47:45Z,the8472,NA https://github.com/rust-lang/rust/pull/77781,CLOSED,2020-10-10T08:36:06Z,2020-10-16T08:48:24Z,Feature request move part of std::io into core::io to be used by rust-libc such as relibc,lygstate,NA,NA,NA,CONFUSED,2020-10-16T03:09:52Z,lygstate,luoyonggang@gmail.com https://github.com/rust-lang/rust/pull/77786,MERGED,2020-10-10T13:57:19Z,2020-10-14T00:27:08Z,Mention rustdoc in `x.py setup`,jyn514,ec0cabd0fe711683e32df497df9e831292ed2c6d,1,Rollup merge of #77786 - jyn514:rustdoc r=Mark-Simulacrum Mention rustdoc in `x.py setup` This lets new contributors know which option they should pick; previously it wasn't clear 'compiler' also included rustdoc. Unresolved questions: should this say 'compiler and tools' instead? I don't know of any tools that are modified in-tree other than rustdoc though. r? @Mark-Simulacrum,THUMBS_UP,2020-10-10T13:59:02Z,nasso,NA https://github.com/rust-lang/rust/pull/77788,MERGED,2020-10-10T14:23:15Z,2020-10-14T05:03:04Z,BTreeMap: fix gdb provider on BTreeMap with ZST keys or values,ssomers,9c365a256158bdd029465cfe1644417d606bd3f0,2,Rollup merge of #77788 - ssomers:btree_cleanup_gdb r=Mark-Simulacrum BTreeMap: fix gdb provider on BTreeMap with ZST keys or values Avoid error when gdb is asked to inspect a BTreeMap or BTreeSet with a zero-sized type as key or value. And clean up. r? @Mark-Simulacrum,HEART,2020-10-23T06:20:51Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/77792,MERGED,2020-10-10T14:51:02Z,2020-10-13T00:57:12Z,Use tracing spans in rustc_trait_selection,matthewjasper,abbdec3be6cfce1175d0dc6737a2999cf43b530d,5,Auto merge of #77792 - matthewjasper:instrument-trait-selection r=oli-obk Use tracing spans in rustc_trait_selection Spans are very helpful when debugging this code. It's also hot enough to make a good benchmark. r? `@oli-obk`,HOORAY,2020-10-12T14:15:33Z,oli-obk,NA https://github.com/rust-lang/rust/pull/77795,MERGED,2020-10-10T15:14:20Z,2020-10-14T05:03:04Z,Codegen backend interface refactor,bjorn3,17ee28b71f452dc914528786f7b535837ac95f85,9,Rollup merge of #77795 - bjorn3:codegen_backend_interface_refactor r=oli-obk Codegen backend interface refactor This moves several things away from the codegen backend to rustc_interface. There are a few behavioral changes where previously the incremental cache (incorrectly) wouldn't get finalized but now it does. See the individual commit messages.,HEART,2020-12-28T14:26:37Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/77796,MERGED,2020-10-10T15:46:56Z,2020-10-13T02:49:12Z,Refactor how SwitchInt stores jump targets,jonas-schievink,afb4514c099fde6e3102373602bea9e6dacd4f88,22,Auto merge of #77796 - jonas-schievink:switchint-refactor r=oli-obk Refactor how SwitchInt stores jump targets Closes https://github.com/rust-lang/rust/issues/65693,HOORAY,2020-10-12T19:16:21Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/77801,MERGED,2020-10-10T18:51:08Z,2020-12-11T02:25:31Z,Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio,m-ou-se,8cef65fde3f92a84218fc338de6ab967fafd1820,5,Auto merge of #77801 - fusion-engineering-forks:pin-mutex r=Mark-Simulacrum Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio A `sys_common::ReentrantMutex` may not be moved after initializing it with `.init()`. This was not enforced but only stated as a requirement in the comments on the unsafe functions. This change enforces this no-moving rule using `Pin` by changing `&self` to a `Pin` in the `init()` and `lock()` functions. This uncovered a bug I introduced in #77154: stdio.rs (the only user of ReentrantMutex) called `init()` on its ReentrantMutexes while constructing them in the intializer of `SyncOnceCell::get_or_init` which would move them afterwards. Interestingly the ReentrantMutex unit tests already had the same bug so this invalid usage has been tested on all (CI-tested) platforms for a long time. Apparently this doesn't break badly on any of the major platforms but it does break the rules.\* To be able to keep using SyncOnceCell this adds a `SyncOnceCell::get_or_init_pin` function which makes it possible to work with pinned values inside a (pinned) SyncOnceCell. Whether this function should be public or not and what its exact behaviour and interface should be if it would be public is something I'd like to leave for a separate issue or PR. In this PR this function is internal-only and marked with `pub(crate)`. \* Note: That bug is now included in 1.48 while this patch can only make it to ~~1.49~~ 1.50. We should consider the implications of 1.48 shipping with a wrong usage of `pthread_mutex_t` / `CRITICAL_SECTION` / .. which technically invokes UB according to their specification. The risk is very low considering the objects are not 'used' (locked) before the move and the ReentrantMutex unit tests have verified this works fine in practice. Edit: This has been backported and included in 1.48. And soon 1.49 too. --- In future changes I want to push this usage of Pin further inside `sys` instead of only `sys_common` and apply it to all 'unmovable' objects there (`Mutex` `Condvar` `RwLock`). Also while `sys_common`'s mutexes and condvars are already taken care of by #77147 and #77648 its `RwLock` should still be made movable or get pinned.,HEART,2020-12-17T08:38:27Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2020-10-10T21:11:26Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,HOORAY,2020-10-10T21:11:28Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,HEART,2020-10-11T08:51:12Z,RalfJung,NA https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2020-10-12T06:53:19Z,hsivonen,hsivonen@hsivonen.fi https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2020-10-16T22:56:12Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,HEART,2020-10-19T21:12:38Z,estebank,NA https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2020-10-23T17:59:52Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2020-12-24T14:44:20Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,THUMBS_UP,2021-01-14T23:42:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77802,MERGED,2020-10-10T19:01:16Z,2020-11-15T15:41:01Z,Allow making `RUSTC_BOOTSTRAP` conditional on the crate name,jyn514,8825942e86e4c73a70b5bd18c5ca5b5c005b28e6,26,Rollup merge of #77802 - jyn514:bootstrap-specific r=nikomatsakis Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`) then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name` not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()` which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build` a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`,HEART,2021-01-14T23:42:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",ROCKET,2020-10-11T01:45:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",ROCKET,2020-10-11T15:07:12Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",ROCKET,2020-10-11T18:37:50Z,Cldfire,NA https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",ROCKET,2020-10-11T19:24:36Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",ROCKET,2020-10-12T15:13:43Z,nasso,NA https://github.com/rust-lang/rust/pull/77809,MERGED,2020-10-11T01:31:32Z,2020-10-16T12:09:59Z,Add settings to rustdoc to use the system theme,nasso,6999ff33c9234b04cf5273497546b6a878bdb349,4,"Auto merge of #77809 - nasso:master r=jyn514 guillaumegomez Add settings to rustdoc to use the system theme This PR adds new settings to `rustdoc` to use the operating system color scheme. ![click](https://user-images.githubusercontent.com/11479594/95668052-bf604e80-0b6e-11eb-8a17-473aaae510c9.gif) `rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121) but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page. I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)). Since there's now more than one official """"dark"""" theme in `rustdoc` (and also to support custom/third-party themes) the preferred dark and light themes can be configured in the settings page (the defaults are just ""dark"" and ""light""). This is also my very first ""proper"" PR to Rust! Please let me know if I did anything wrong :).",HEART,2020-10-13T22:06:11Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77816,CLOSED,2020-10-11T11:43:29Z,2020-10-13T13:07:59Z,[DO NOT MERGE] Experiment: disable the niche optimization for most enums,ogoffart,NA,NA,NA,EYES,2020-10-11T12:19:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77816,CLOSED,2020-10-11T11:43:29Z,2020-10-13T13:07:59Z,[DO NOT MERGE] Experiment: disable the niche optimization for most enums,ogoffart,NA,NA,NA,EYES,2020-10-11T17:30:30Z,kennytm,NA https://github.com/rust-lang/rust/pull/77825,MERGED,2020-10-11T18:24:24Z,2020-10-14T00:27:03Z,`min_const_generics` diagnostics improvements,eopb,c44cc7e236b00b361f2ffc133c3c0b6d0f3066e0,56,Rollup merge of #77825 - ethanboxx:min_const_generics_diagnostic r=lcnr `min_const_generics` diagnostics improvements As disscussed in [zulip/project-const-generics/non-trivial anonymous constant](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/non-trivial.20anonymous.20constants). This is my first PR on the compiler. @lcnr is mentoring me on this PR. Related to #60551.,HEART,2020-10-12T08:20:37Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/77825,MERGED,2020-10-11T18:24:24Z,2020-10-14T00:27:03Z,`min_const_generics` diagnostics improvements,eopb,c44cc7e236b00b361f2ffc133c3c0b6d0f3066e0,56,Rollup merge of #77825 - ethanboxx:min_const_generics_diagnostic r=lcnr `min_const_generics` diagnostics improvements As disscussed in [zulip/project-const-generics/non-trivial anonymous constant](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/non-trivial.20anonymous.20constants). This is my first PR on the compiler. @lcnr is mentoring me on this PR. Related to #60551.,HEART,2020-10-12T12:58:07Z,varkor,NA https://github.com/rust-lang/rust/pull/77825,MERGED,2020-10-11T18:24:24Z,2020-10-14T00:27:03Z,`min_const_generics` diagnostics improvements,eopb,c44cc7e236b00b361f2ffc133c3c0b6d0f3066e0,56,Rollup merge of #77825 - ethanboxx:min_const_generics_diagnostic r=lcnr `min_const_generics` diagnostics improvements As disscussed in [zulip/project-const-generics/non-trivial anonymous constant](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/non-trivial.20anonymous.20constants). This is my first PR on the compiler. @lcnr is mentoring me on this PR. Related to #60551.,HEART,2020-10-13T06:08:03Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77830,MERGED,2020-10-11T20:16:22Z,2020-10-25T00:25:29Z,Simplify query proc-macros,cjgillot,4d72939af14b20a79232dbe4533875b15d264003,6,Rollup merge of #77830 - cjgillot:remacro r=oli-obk Simplify query proc-macros The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`. This PR removes unused capabilities of the proc-macros and tend to use regular macros for the logic.,EYES,2020-10-11T21:00:55Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77830,MERGED,2020-10-11T20:16:22Z,2020-10-25T00:25:29Z,Simplify query proc-macros,cjgillot,4d72939af14b20a79232dbe4533875b15d264003,6,Rollup merge of #77830 - cjgillot:remacro r=oli-obk Simplify query proc-macros The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`. This PR removes unused capabilities of the proc-macros and tend to use regular macros for the logic.,EYES,2020-10-12T14:06:25Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77830,MERGED,2020-10-11T20:16:22Z,2020-10-25T00:25:29Z,Simplify query proc-macros,cjgillot,4d72939af14b20a79232dbe4533875b15d264003,6,Rollup merge of #77830 - cjgillot:remacro r=oli-obk Simplify query proc-macros The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`. This PR removes unused capabilities of the proc-macros and tend to use regular macros for the logic.,THUMBS_UP,2020-10-19T17:11:55Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/77844,MERGED,2020-10-12T08:17:19Z,2020-11-21T22:46:52Z,clarify rules for ZST Boxes,RalfJung,6cd02a85f1e40f8feac4f09c987baba0821b7756,2,"Rollup merge of #77844 - RalfJung:zst-box r=nikomatsakis clarify rules for ZST Boxes LLVM's rules around `getelementptr inbounds` with offset 0 are a bit annoying and as a consequence we have no choice but say that a `Box<()>` pointing to previously allocated memory that has since been freed is UB. Clarify the docs to reflect this. This is based on conversations on the LLVM mailing list. * Here's my initial mail: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html * The first email of the March part of that thread: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html * First email of the April part: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html The conclusion for me at least was that `getelementptr inbounds` with offset 0 is *not* the identity function but can sometimes return `poison` even when the input is a regular pointer -- specifically it returns `poison` when this pointer points into something that LLVM ""knows has been deallocated"" i.e. a former LLVM-managed allocation. It is however the identity function on pointers obtained by casting integers. Note that there [are formal proposals](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf) for LLVM semantics where `getelementptr inbounds` with offset 0 isn't quite the identity function but never returns `poison` (it affects the provenance of the pointer but in a way that doesn't matter if this pointer is never used for memory accesses) and indeed this is likely necessary to consistently describe LLVM semantics. But with the informal LLVM LangRef that we have right now and with LLVM devs insisting otherwise it seems unwise to rely on this.",ROCKET,2020-10-12T15:22:45Z,elichai,NA https://github.com/rust-lang/rust/pull/77853,MERGED,2020-10-12T15:37:53Z,2021-01-07T18:20:20Z,Stabilize slice::strip_prefix and slice::strip_suffix,ijackson,8f0b945cfcc3d084583bc27a7ed23b27b1246751,2,Auto merge of #77853 - ijackson:slice-strip-stab r=Amanieu Stabilize slice::strip_prefix and slice::strip_suffix These two methods are useful. The corresponding methods on `str` are already stable. I believe that stablising these now would not get in the way of in the future extending these to take a richer pattern API a la `str`'s patterns. Tracking PR: #73413. I also have an outstanding PR to improve the docs for these two functions and the corresponding ones on `str`: #75078 I have tried to follow the [instructions in the dev guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr). The part to do with `compiler/rustc_feature` did not seem applicable. I assume that's because these are just library features so there is no corresponding machinery in rustc.,THUMBS_UP,2020-12-31T09:56:44Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/77853,MERGED,2020-10-12T15:37:53Z,2021-01-07T18:20:20Z,Stabilize slice::strip_prefix and slice::strip_suffix,ijackson,8f0b945cfcc3d084583bc27a7ed23b27b1246751,2,Auto merge of #77853 - ijackson:slice-strip-stab r=Amanieu Stabilize slice::strip_prefix and slice::strip_suffix These two methods are useful. The corresponding methods on `str` are already stable. I believe that stablising these now would not get in the way of in the future extending these to take a richer pattern API a la `str`'s patterns. Tracking PR: #73413. I also have an outstanding PR to improve the docs for these two functions and the corresponding ones on `str`: #75078 I have tried to follow the [instructions in the dev guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr). The part to do with `compiler/rustc_feature` did not seem applicable. I assume that's because these are just library features so there is no corresponding machinery in rustc.,THUMBS_UP,2021-01-15T06:16:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77855,MERGED,2020-10-12T16:23:37Z,2020-10-16T22:54:07Z,"resolve: further improvements to ""try using the enum's variant"" diagnostic",davidtwco,75ef735d4a2e159e083889a22902a40d8265fced,5,"Rollup merge of #77855 - davidtwco:pr-77341-follow-up-non-constructable-variants r=estebank resolve: further improvements to ""try using the enum's variant"" diagnostic Follow-up on https://github.com/rust-lang/rust/pull/77341#issuecomment-702738281. This PR improves the diagnostic modified in #77341 to suggest not only those variants which do not have fields but those with fields (by suggesting with placeholders). In addition the wording of the tuple-variant-only case is improved slightly. I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant I have no information on how many fields were provided; and in the case of pattern matching I only have a slice of spans and would need to check for things like `..` in those spans which doesn't seem worth it). r? @estebank",THUMBS_UP,2020-10-14T19:25:53Z,estebank,NA https://github.com/rust-lang/rust/pull/77856,MERGED,2020-10-12T16:31:12Z,2020-11-06T07:00:41Z,Add non_autolinks lint,GuillaumeGomez,f92b931045dabb00b892519d3451cb41d41f2d31,34,Auto merge of #77856 - GuillaumeGomez:automatic-links-lint r=jyn514 ollie27 Add non_autolinks lint Part of #77501. r? `@jyn514`,THUMBS_UP,2020-10-14T19:37:37Z,estebank,NA https://github.com/rust-lang/rust/pull/77862,MERGED,2020-10-12T18:04:01Z,2021-01-10T08:01:23Z,Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path,danielhenrymantilla,7a193921a024e910262ff90bfb028074fddf20d0,6,Auto merge of #77862 - danielhenrymantilla:rustdoc/fix-macros_2_0-paths r=jyn514 petrochenkov Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path Fixes #74355 - ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~ - ~~dummy items may avoid the first `?` ~~ - ~~but within the module traversal some tests did fail (hence the second `?`) meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~ r? `@jyn514`,HEART,2021-01-10T08:02:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/77862,MERGED,2020-10-12T18:04:01Z,2021-01-10T08:01:23Z,Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path,danielhenrymantilla,7a193921a024e910262ff90bfb028074fddf20d0,6,Auto merge of #77862 - danielhenrymantilla:rustdoc/fix-macros_2_0-paths r=jyn514 petrochenkov Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path Fixes #74355 - ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~ - ~~dummy items may avoid the first `?` ~~ - ~~but within the module traversal some tests did fail (hence the second `?`) meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~ r? `@jyn514`,HEART,2021-01-11T15:19:22Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77868,MERGED,2020-10-12T20:05:06Z,2020-10-14T00:26:56Z,Include `llvm-dis` `llc` and `opt` in `llvm-tools-preview` component,Aaron1011,c82478719bc2cd5ef2c1bf9d493d871fa6b59384,1,Rollup merge of #77868 - Aaron1011:llvm-tools-opt-llc r=Mark-Simulacrum Include `llvm-dis` `llc` and `opt` in `llvm-tools-preview` component Fixes #55890 It's useful to have `llc` and `opt` available when debugging an LLVM miscompilation .,HEART,2020-10-13T01:22:35Z,tmandry,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-12T22:47:58Z,kevincox,kevincox@kevincox.ca https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-12T23:22:40Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-12T23:28:10Z,lberrymage,logan@lberrymage.dev https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-12T23:35:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-12T23:35:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-13T08:35:05Z,lnicola,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-13T11:47:22Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-13T22:46:46Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-14T18:11:07Z,EdorianDark,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-15T22:40:02Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-15T22:40:03Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-16T05:31:05Z,kennytm,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-18T04:54:03Z,vultix,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-22T17:24:19Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-22T18:00:19Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-22T19:23:00Z,manuthambi,manu@meshcapital.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-22T20:02:58Z,TheV360,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-23T08:01:36Z,johansigfrids,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-23T15:49:55Z,bash,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-24T21:45:56Z,jamwaffles,james@wapl.es https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-24T21:45:57Z,jamwaffles,james@wapl.es https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-25T17:40:48Z,alexxbb,hou.alexx@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-28T07:19:30Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-29T21:38:26Z,twe4ked,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-29T21:38:27Z,twe4ked,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-30T05:37:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-10-30T05:37:08Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-10-30T09:35:53Z,faern,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-02T14:01:21Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-11-05T00:04:15Z,Virgiel,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-05T00:04:15Z,Virgiel,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-11T18:24:09Z,nwn,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-11-12T02:23:35Z,lain-dono,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-12T02:29:44Z,Dr-Emann,dremann@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-12T03:43:16Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-11-12T03:43:18Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-11-12T03:43:19Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-11-12T05:01:32Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-12T07:34:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-11-12T11:01:26Z,Virgiel,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-12T12:22:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-11-12T12:22:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-11-12T12:22:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2020-11-15T20:04:42Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-11-15T20:04:44Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-15T20:04:45Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-11-26T12:16:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2020-12-18T02:45:42Z,jannik4,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2020-12-31T20:16:38Z,MrSeran,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2021-01-01T04:47:27Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2021-01-01T04:47:31Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2021-01-01T04:47:31Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2021-01-01T08:44:37Z,rokit,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,THUMBS_UP,2021-02-08T15:53:05Z,MaxVerevkin,NA https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2021-02-11T06:11:02Z,mkj,matt@ucc.asn.au https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HOORAY,2021-02-23T16:48:48Z,Cogitri,oss@cogitri.dev https://github.com/rust-lang/rust/pull/77872,MERGED,2020-10-12T21:11:52Z,2020-11-22T13:10:18Z,Stabilize clamp,Xaeroxe,5d5ff84130da0d74c6ece368dbe821d8f83fa526,4,Auto merge of #77872 - Xaeroxe:stabilize-clamp r=scottmcm Stabilize clamp Tracking issue: https://github.com/rust-lang/rust/issues/44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?,HEART,2021-03-07T02:19:39Z,ekimekim,NA https://github.com/rust-lang/rust/pull/77878,CLOSED,2020-10-12T23:30:19Z,2020-10-13T11:09:19Z,Remove `canonicalize_hr_query_hack`,bugadani,NA,NA,NA,HEART,2020-10-12T23:34:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/77948,MERGED,2020-10-14T19:30:19Z,2020-10-15T08:50:40Z,Rebase LLVM onto 11.0.0 final,cuviper,596b0d5027bfb1b5835e17a25f56b00a1f6ff95f,2,Auto merge of #77948 - cuviper:rust-llvm11 r=nikic Rebase LLVM onto 11.0.0 final,THUMBS_UP,2020-10-14T19:36:13Z,est31,NA https://github.com/rust-lang/rust/pull/77948,MERGED,2020-10-14T19:30:19Z,2020-10-15T08:50:40Z,Rebase LLVM onto 11.0.0 final,cuviper,596b0d5027bfb1b5835e17a25f56b00a1f6ff95f,2,Auto merge of #77948 - cuviper:rust-llvm11 r=nikic Rebase LLVM onto 11.0.0 final,THUMBS_UP,2020-10-15T00:02:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77948,MERGED,2020-10-14T19:30:19Z,2020-10-15T08:50:40Z,Rebase LLVM onto 11.0.0 final,cuviper,596b0d5027bfb1b5835e17a25f56b00a1f6ff95f,2,Auto merge of #77948 - cuviper:rust-llvm11 r=nikic Rebase LLVM onto 11.0.0 final,THUMBS_UP,2020-10-15T08:06:27Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/77948,MERGED,2020-10-14T19:30:19Z,2020-10-15T08:50:40Z,Rebase LLVM onto 11.0.0 final,cuviper,596b0d5027bfb1b5835e17a25f56b00a1f6ff95f,2,Auto merge of #77948 - cuviper:rust-llvm11 r=nikic Rebase LLVM onto 11.0.0 final,THUMBS_UP,2020-10-15T14:47:20Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/77950,MERGED,2020-10-14T20:06:55Z,2020-11-03T21:19:21Z,Add support for SHA256 source file hashing,arlosi,52405f7c0cc3e8cc52293ea19b78da88eb79af2d,10,Rollup merge of #77950 - arlosi:sha256 r=eddyb Add support for SHA256 source file hashing Adds support for `-Z src-hash-algorithm sha256` which became available in LLVM 11. Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256. r? `@eddyb` cc #70401 `@est31`,THUMBS_UP,2020-10-14T20:24:13Z,est31,NA https://github.com/rust-lang/rust/pull/77950,MERGED,2020-10-14T20:06:55Z,2020-11-03T21:19:21Z,Add support for SHA256 source file hashing,arlosi,52405f7c0cc3e8cc52293ea19b78da88eb79af2d,10,Rollup merge of #77950 - arlosi:sha256 r=eddyb Add support for SHA256 source file hashing Adds support for `-Z src-hash-algorithm sha256` which became available in LLVM 11. Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256. r? `@eddyb` cc #70401 `@est31`,THUMBS_UP,2020-10-15T03:16:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/77962,MERGED,2020-10-15T07:09:03Z,2020-10-16T06:48:31Z,Remove arena's dependency on `rustc_data_structures`,bugadani,8e6f69afc9b0943003ce51a53d1f59611e6601a3,3,"Auto merge of #77962 - bugadani:arena2 r=Mark-Simulacrum Remove arena's dependency on `rustc_data_structures` `rustc_arena` currently has a dependency on `rustc_data_structures` because of a trivial ""don't inline me"" function. This PR copies that function and removes the dependency.",THUMBS_UP,2020-10-15T08:07:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/77962,MERGED,2020-10-15T07:09:03Z,2020-10-16T06:48:31Z,Remove arena's dependency on `rustc_data_structures`,bugadani,8e6f69afc9b0943003ce51a53d1f59611e6601a3,3,"Auto merge of #77962 - bugadani:arena2 r=Mark-Simulacrum Remove arena's dependency on `rustc_data_structures` `rustc_arena` currently has a dependency on `rustc_data_structures` because of a trivial ""don't inline me"" function. This PR copies that function and removes the dependency.",THUMBS_UP,2020-10-15T10:57:01Z,est31,NA https://github.com/rust-lang/rust/pull/77962,MERGED,2020-10-15T07:09:03Z,2020-10-16T06:48:31Z,Remove arena's dependency on `rustc_data_structures`,bugadani,8e6f69afc9b0943003ce51a53d1f59611e6601a3,3,"Auto merge of #77962 - bugadani:arena2 r=Mark-Simulacrum Remove arena's dependency on `rustc_data_structures` `rustc_arena` currently has a dependency on `rustc_data_structures` because of a trivial ""don't inline me"" function. This PR copies that function and removes the dependency.",HEART,2020-10-15T12:07:56Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77962,MERGED,2020-10-15T07:09:03Z,2020-10-16T06:48:31Z,Remove arena's dependency on `rustc_data_structures`,bugadani,8e6f69afc9b0943003ce51a53d1f59611e6601a3,3,"Auto merge of #77962 - bugadani:arena2 r=Mark-Simulacrum Remove arena's dependency on `rustc_data_structures` `rustc_arena` currently has a dependency on `rustc_data_structures` because of a trivial ""don't inline me"" function. This PR copies that function and removes the dependency.",THUMBS_UP,2020-10-15T19:42:24Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T13:44:58Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T14:05:23Z,korken89,emil.fresk@gmail.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T14:13:31Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T14:30:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T16:04:37Z,Sympatron,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-15T23:56:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-16T13:30:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-17T23:53:24Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-18T01:08:57Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-18T07:29:06Z,ebroto,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-18T07:53:36Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-18T11:22:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-18T19:17:13Z,Peohta,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2020-10-20T18:09:34Z,adamgreig,adam@adamgreig.com https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2021-01-02T14:53:01Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/77972,MERGED,2020-10-15T13:43:17Z,2020-10-16T16:26:01Z,Prevent miscompilation in trivial loop {},Mark-Simulacrum,a78a62fc996ba16f7a111c99520b23f77029f4eb,5,Auto merge of #77972 - Mark-Simulacrum:side-effect-loop r=nagisa Prevent miscompilation in trivial loop {} Ideally we would want to handle a broader set of cases to fully fix the underlying bug here. That is currently relatively expensive at compile and runtime so we don't do that for now. Performance results indicate this is not a major regression if at all so it should be safe to land. cc #28728,HEART,2021-01-24T14:13:08Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T14:04:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T14:05:32Z,malbarbo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T14:08:18Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T14:13:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T14:43:26Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T15:23:33Z,lqd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T16:05:06Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T17:39:01Z,matprec,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-15T19:24:53Z,est31,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-16T13:37:04Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-16T19:05:08Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-17T14:29:59Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-22T05:33:45Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-24T12:06:16Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-25T23:48:44Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:20:15Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:26:20Z,djc,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:40:49Z,BuggStream,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:43:40Z,nevi-me,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:45:49Z,Jake-Shadle,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:46:17Z,darksv,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T19:51:55Z,tux3,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:02:18Z,soupertonic,felix.scholz.box@outlook.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:07:09Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:13:32Z,pudnax,k.a.komissar@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:24:27Z,lnicola,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:33:47Z,ajyoon,andrew@nothing-to-say.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:33:50Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:36:59Z,SorteKanin,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:39:15Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:45:25Z,tronta,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:45:30Z,l4l,mail@kitsu.me https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:48:33Z,max-frai,me@maxfrai.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:52:06Z,daniel5151,danielprilik@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T20:54:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:07:57Z,ecumene,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:09:00Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:09:43Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:10:15Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:12:09Z,MrAS04,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:14:37Z,lukechu10,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:27:17Z,kornholi,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:44:11Z,nbaksalyar,nikita.baksalyar@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T21:53:45Z,Aberdeener,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:03:30Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:13:58Z,Agrailag,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-26T22:14:04Z,Agrailag,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:38:04Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:40:02Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-26T22:40:03Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-26T22:40:08Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:47:29Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-26T22:55:00Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-26T22:55:00Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T22:55:03Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:03:37Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:08:03Z,francesca64,franlovebloom@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:15:19Z,estebank,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:26:43Z,aravind-pg,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:37:35Z,delacian,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-26T23:41:48Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T00:02:41Z,ZeWaka,zewakagamer@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T00:17:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T00:17:27Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T00:17:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T00:37:02Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T00:44:45Z,simonsan,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T00:55:23Z,aheart,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T00:58:16Z,darvesh,hello@darve.sh https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T00:58:16Z,darvesh,hello@darve.sh https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T01:13:06Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T02:10:56Z,jagt,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T02:12:09Z,qezz,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T02:38:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T02:44:23Z,joshuajbouw,joshua@aurora.dev https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T02:44:27Z,joshuajbouw,joshua@aurora.dev https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T03:17:33Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T03:23:56Z,kanishkarj,kanishkarj@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T03:23:57Z,kanishkarj,kanishkarj@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T03:23:58Z,kanishkarj,kanishkarj@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T03:29:06Z,whilestevego,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T04:15:02Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T05:33:18Z,naim94a,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T06:27:09Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T07:14:50Z,zeroows,zeroows@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T08:03:10Z,YaLTeR,yalterz@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T08:11:16Z,marcogroppo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T08:34:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T08:34:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T08:34:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T08:43:50Z,joealden,me@joealden.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T08:45:16Z,numToStr,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T09:38:25Z,gimpf,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T10:41:04Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T11:04:55Z,theduke,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T11:15:29Z,davidlattimore,dvdlttmr@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T11:22:06Z,ufoscout,ufoscout@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T12:45:32Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T13:01:09Z,gnieto,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T13:19:39Z,caioraposo,caioraposo@tutanota.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T13:27:57Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T13:27:57Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T13:27:57Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T13:44:52Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T13:44:53Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T13:44:54Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T13:46:44Z,mikialex,18516340862@163.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T15:07:28Z,eminence,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T15:07:30Z,eminence,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T15:07:31Z,eminence,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T15:51:24Z,Ravenslofty,dan.ravensloft@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T16:16:07Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T16:43:53Z,pierreyoda,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T17:41:14Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T18:00:05Z,alyssarosenzweig,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T18:04:33Z,mwilliammyers,mwilliammyers@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T18:04:39Z,wiktor-k,wiktor@metacode.biz https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T18:04:39Z,wiktor-k,wiktor@metacode.biz https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T18:04:39Z,wiktor-k,wiktor@metacode.biz https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T18:06:09Z,CohenArthur,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T18:10:57Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T18:37:00Z,adamreichold,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T18:51:39Z,binaryfields,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T19:15:48Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T19:50:47Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T20:01:02Z,bes,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T20:28:51Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T20:46:57Z,fabianschuiki,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T21:10:16Z,Tarnadas,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T21:25:49Z,ThouCheese,luuk.wester@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T21:29:36Z,gliderkite,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T21:38:42Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T21:50:58Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T22:17:19Z,petr-tik,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T22:17:22Z,petr-tik,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-27T22:40:18Z,yerke,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-27T22:40:19Z,yerke,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-27T22:40:20Z,yerke,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-28T00:03:18Z,WilliamTCarroll,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-28T01:51:05Z,fifteen42,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-28T01:59:42Z,tkbrigham,thomas@thomasbrigham.me https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-28T09:23:30Z,elichai,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-28T12:31:35Z,moshg,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-28T14:46:57Z,WShiBin,15519900807@qq.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-28T15:50:27Z,cdmistman,colton@donn.io https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T02:15:26Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T02:15:28Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T05:51:44Z,lynnux,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T07:33:40Z,matthiasbeyer,mail@beyermatthias.de https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T07:46:47Z,cisen,csacxc@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T07:46:52Z,cisen,csacxc@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T08:10:29Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T08:10:31Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T08:27:39Z,JermineHu,jermine.hu@qq.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-29T08:27:41Z,JermineHu,jermine.hu@qq.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T08:27:44Z,JermineHu,jermine.hu@qq.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T08:51:34Z,hzqd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-29T08:51:35Z,hzqd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-29T08:51:44Z,hzqd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T11:33:21Z,xen0n,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-29T22:35:49Z,cfallin,chris@cfallin.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-31T09:09:45Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-10-31T09:09:45Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-10-31T09:09:46Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-10-31T11:34:03Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-01T12:28:42Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-01T13:36:16Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-01T13:36:17Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-01T13:36:18Z,Xunjin,xunjin.coder@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-02T09:52:23Z,ljedrz,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T07:58:18Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T10:51:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-06T10:51:15Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-06T10:51:16Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-06T12:42:38Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T15:37:00Z,Ltrlg,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T19:02:21Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-06T19:02:23Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-06T19:02:25Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T19:07:50Z,fluxxu,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-06T21:36:57Z,gurpreetshanky,kakar.shanky@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-06T21:36:57Z,gurpreetshanky,kakar.shanky@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-06T21:36:58Z,gurpreetshanky,kakar.shanky@hotmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-07T01:54:10Z,declanvk,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-07T02:19:22Z,nwn,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-07T11:56:53Z,boozook,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-07T11:56:55Z,boozook,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-07T11:56:55Z,boozook,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-07T11:59:59Z,fundon,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-10T23:50:28Z,darnuria,axel.viala+github@darnuria.eu https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-11T17:00:24Z,0x29a,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-11T21:59:13Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-12T11:16:38Z,Rasphino,im.lihh@outlook.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-16T09:07:27Z,iago-lito,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T22:18:21Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T22:57:43Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-17T22:58:32Z,lxe,lxe@lxe.co https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:00:18Z,Congee,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-17T23:09:12Z,reneklacan,rene@klacan.sk https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:18:45Z,SomeoneToIgnore,mail4score@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-17T23:18:46Z,SomeoneToIgnore,mail4score@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:18:47Z,SomeoneToIgnore,mail4score@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-17T23:19:34Z,it-is-wednesday,git@avocadosh.xyz https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:19:38Z,it-is-wednesday,git@avocadosh.xyz https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:33:31Z,ionut-arm,ionut.mihalcea@arm.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:40:53Z,pojntfx,felicitas@pojtinger.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:41:00Z,thushan,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:41:02Z,pojntfx,felicitas@pojtinger.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-17T23:43:39Z,baptistemanson,baptiste.manson@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:43:42Z,baptistemanson,baptiste.manson@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:45:50Z,fwip,jemma.s.nelson@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:45:51Z,fwip,jemma.s.nelson@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:49:41Z,kcmannem,krishna@mannem.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:55:22Z,woodruffw,william@yossarian.net https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-17T23:58:32Z,paulstey,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-17T23:58:33Z,paulstey,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-17T23:58:33Z,paulstey,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:58:34Z,paulstey,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-17T23:58:36Z,ehiggs,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-17T23:58:37Z,ehiggs,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T00:05:03Z,bpierre,hi@bpier.re https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T00:12:26Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T00:21:47Z,varkor,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-18T00:44:05Z,zsherman,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T00:44:05Z,zsherman,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T00:44:06Z,zsherman,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T00:44:06Z,zsherman,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T01:11:20Z,danbruder,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-18T01:36:40Z,r8913,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T01:44:00Z,kristianpaul,paul@kristianpaul.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T01:44:01Z,kristianpaul,paul@kristianpaul.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T01:44:02Z,kristianpaul,paul@kristianpaul.org https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-18T01:49:06Z,Linoonphan,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T02:59:45Z,MitsuhaMiyamizu,gnchenmed@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T03:04:35Z,Fullstop000,fullstop1005@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T03:15:20Z,jordan-simonovski,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T03:32:06Z,mlvzk,mlvzk@protonmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T03:32:07Z,mlvzk,mlvzk@protonmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T03:32:08Z,mlvzk,mlvzk@protonmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T04:00:11Z,kassens,jan@kassens.net https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T04:16:47Z,jcpst,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T06:24:22Z,rbruggem,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-18T06:45:36Z,DerekCrosson,derekcrosson18@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-18T07:44:07Z,tbobm,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-18T07:44:08Z,tbobm,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-18T09:01:42Z,paginabianca,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-18T16:40:14Z,sivizius,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-19T19:44:54Z,westrik,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-19T19:44:55Z,westrik,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-20T07:17:25Z,tekakutli,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-21T06:58:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-21T06:58:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-24T02:31:40Z,bzEq,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-24T05:25:27Z,ficapy,c4d@outlook.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-24T08:20:04Z,unseddd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2020-11-24T08:20:05Z,unseddd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-24T08:20:06Z,unseddd,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-11-25T00:23:36Z,toiglak,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2020-11-25T00:23:39Z,toiglak,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2020-12-02T16:22:52Z,jakubadamw,mail@jakubw.eu https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-12-06T14:41:26Z,jesserwright,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2020-12-29T13:34:28Z,tekakutli,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2021-02-18T17:12:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2021-02-18T17:12:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2021-02-18T17:12:38Z,weihanglo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2021-02-18T17:12:38Z,weihanglo,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2021-02-18T18:25:31Z,Cons-Cat,wgooch2000@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2021-02-18T18:25:32Z,Cons-Cat,wgooch2000@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2021-04-22T09:46:23Z,zoechi,guenter@gzoechbauer.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2021-05-21T15:01:50Z,dyedgreen,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2021-06-23T21:28:01Z,yerke,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2022-02-26T15:09:41Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,THUMBS_UP,2022-04-15T21:10:50Z,ERAGON007,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HOORAY,2022-04-15T21:10:51Z,ERAGON007,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,ROCKET,2022-04-15T21:10:53Z,ERAGON007,NA https://github.com/rust-lang/rust/pull/77975,MERGED,2020-10-15T14:02:29Z,2020-10-26T18:50:58Z,Add cg_clif as optional codegen backend,bjorn3,35debd4c111610317346f46d791f32551d449bd8,98,Auto merge of #77975 - bjorn3:cg_clif_subtree3 r=Mark-Simulacrum Add cg_clif as optional codegen backend Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases. This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`. MCP: https://github.com/rust-lang/compiler-team/issues/270 r? `@Mark-Simulacrum`,HEART,2022-04-15T21:10:56Z,ERAGON007,NA https://github.com/rust-lang/rust/pull/77980,MERGED,2020-10-15T15:56:59Z,2020-10-16T02:27:58Z,Fix intra doc link for needs_drop,Manishearth,e688b4d51cc9b41b18b240f5f6358daa8179e8fa,1,Rollup merge of #77980 - Manishearth:needs-drop-intra r=jyn514 Fix intra doc link for needs_drop It currently links to itself. Oops. r? @jyn514,LAUGH,2020-10-15T16:01:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/77984,MERGED,2020-10-15T18:23:24Z,2020-10-25T14:18:03Z,Compute proper module parent during resolution,Aaron1011,569d29d55c240eea3ff35d0a16572c2b81dd40bf,5,"Rollup merge of #77984 - Aaron1011:fix/macro-mod-weird-parent r=petrochenkov Compute proper module parent during resolution Fixes #75982 The direct parent of a module may not be a module (e.g. `const _: () = { #[path = ""foo.rs""] mod foo; };`). To find the parent of a module for purposes of resolution we need to walk up the tree until we hit a module or a crate root.",THUMBS_UP,2020-10-16T16:13:16Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/77996,MERGED,2020-10-15T21:13:45Z,2020-11-13T17:36:53Z,Doc change: Remove mention of `fnv` in HashMap,tkaitchuck,ef32ef7baf2d36c4571f75ba124ae55b904f6142,1,Rollup merge of #77996 - tkaitchuck:master r=m-ou-se Doc change: Remove mention of `fnv` in HashMap Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash). This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate as an alternative `Hasher` implementation. ### Why Fnv [has poor hash quality](https://github.com/rurban/smhasher) is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed) and does not provide dos resistance because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)). Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 . Because regardless of which dimension you value there are better alternatives it does not make sense for anyone to consider using `fnv`. The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153 https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks) [possible](https://github.com/tkaitchuck/aHash#speed) [choice](http://cglab.ca/~abeinges/blah/hash-rs/).) I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed) is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality) and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern) Signed-off-by: Tom Kaitchuck ,HEART,2020-11-14T01:26:16Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/77996,MERGED,2020-10-15T21:13:45Z,2020-11-13T17:36:53Z,Doc change: Remove mention of `fnv` in HashMap,tkaitchuck,ef32ef7baf2d36c4571f75ba124ae55b904f6142,1,Rollup merge of #77996 - tkaitchuck:master r=m-ou-se Doc change: Remove mention of `fnv` in HashMap Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash). This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate as an alternative `Hasher` implementation. ### Why Fnv [has poor hash quality](https://github.com/rurban/smhasher) is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed) and does not provide dos resistance because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)). Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 . Because regardless of which dimension you value there are better alternatives it does not make sense for anyone to consider using `fnv`. The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153 https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks) [possible](https://github.com/tkaitchuck/aHash#speed) [choice](http://cglab.ca/~abeinges/blah/hash-rs/).) I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed) is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality) and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern) Signed-off-by: Tom Kaitchuck ,HEART,2021-01-11T17:24:06Z,weihanglo,NA https://github.com/rust-lang/rust/pull/77997,MERGED,2020-10-15T21:37:43Z,2020-10-17T01:05:15Z,Remove shrink_to_fit from default ToString::to_string implementation.,m-ou-se,f1b97ee7f8ffb1a814944b85c7e05a1555a7eda5,1,Auto merge of #77997 - fusion-engineering-forks:to-string-no-shrink r=joshtriplett Remove shrink_to_fit from default ToString::to_string implementation. As suggested by `@scottmcm` on Zulip. shrink_to_fit() seems like the wrong thing to do here in most use cases of to_string(). Would be intereseting to see if it makes any difference in a timer run. r? `@joshtriplett`,ROCKET,2020-12-31T19:10:29Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78026,MERGED,2020-10-16T19:09:19Z,2020-11-09T02:58:53Z,Define `fs::hard_link` to not follow symlinks.,sunfishcode,41134be153ec0e152b0bb5cf79731abdde7c4e04,3,Rollup merge of #78026 - sunfishcode:symlink-hard-link r=dtolnay Define `fs::hard_link` to not follow symlinks. POSIX leaves it [implementation-defined] whether `link` follows symlinks. In practice for example on Linux it does not and on FreeBSD it does. So switch to `linkat` so that we can pick a behavior rather than depending on OS defaults. Pick the option to not follow symlinks. This is somewhat arbitrary but seems the less surprising choice because hard linking is a very low-level feature which requires the source and destination to be on the same mounted filesystem and following a symbolic link could end up in a different mounted filesystem. [implementation-defined]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html,THUMBS_UP,2020-10-30T17:31:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78039,MERGED,2020-10-17T06:03:46Z,2020-10-17T14:44:52Z,Remove unused cached_unreachable_block from MIR builder,tmiasko,dda2b5e3e260c14b868c494008af1c8981eaa5a8,1,Auto merge of #78039 - tmiasko:unreachable-block r=Mark-Simulacrum Remove unused cached_unreachable_block from MIR builder,THUMBS_UP,2020-10-17T21:33:39Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78048,MERGED,2020-10-17T12:07:33Z,2020-10-17T21:59:05Z,Suggest correct place to add `self` parameter when inside closure,blyxxyz,57e38dd4fbd45483c0bb0a7569c97a7031114664,5,Rollup merge of #78048 - blyxxyz:e0424-improve-self-placement r=lcnr Suggest correct place to add `self` parameter when inside closure It would incorrectly suggest adding it as a parameter to the closure instead of the containing function. [For example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1936bcd1e5f981573386e0cee985c3c0): ``` help: add a `self` receiver parameter to make the associated `fn` a method | 5 | let _ = || self&self; | ^^^^^ ``` `DiagnosticMetadata.current_function` is only used for these messages so tweaking its behavior should be ok.,HEART,2020-10-17T20:16:01Z,estebank,NA https://github.com/rust-lang/rust/pull/78062,CLOSED,2020-10-17T23:12:50Z,2020-10-18T16:45:46Z,crate rhymes with u8 now compiles in 2018 edition,s-e,NA,NA,NA,EYES,2020-10-17T23:15:53Z,tesuji,NA https://github.com/rust-lang/rust/pull/78062,CLOSED,2020-10-17T23:12:50Z,2020-10-18T16:45:46Z,crate rhymes with u8 now compiles in 2018 edition,s-e,NA,NA,NA,EYES,2020-10-17T23:19:38Z,s-e,sam.evaskitas@gmail.com https://github.com/rust-lang/rust/pull/78063,MERGED,2020-10-18T03:05:49Z,2020-10-21T13:39:17Z,"Improve wording of ""cannot multiply"" type error",camelid,89c98cd6b4d92e0237a91eb18754d03dbe64fb6a,18,"Rollup merge of #78063 - camelid:improve-cannot-multiply-error r=estebank Improve wording of ""cannot multiply"" type error For example if you had this code: fn foo(x: i32 y: f32) -> f32 { x * y } You would get this error: error[E0277]: cannot multiply `f32` to `i32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32` However that's not usually how people describe multiplication. People usually describe multiplication like how the division error words it: error[E0277]: cannot divide `i32` by `f32` --> src/lib.rs:2:7 | 2 | x / y | ^ no implementation for `i32 / f32` | = help: the trait `Div` is not implemented for `i32` So that's what this change does. It changes this: error[E0277]: cannot multiply `f32` to `i32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32` To this: error[E0277]: cannot multiply `i32` by `f32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32`",THUMBS_UP,2020-10-19T17:18:31Z,estebank,NA https://github.com/rust-lang/rust/pull/78063,MERGED,2020-10-18T03:05:49Z,2020-10-21T13:39:17Z,"Improve wording of ""cannot multiply"" type error",camelid,89c98cd6b4d92e0237a91eb18754d03dbe64fb6a,18,"Rollup merge of #78063 - camelid:improve-cannot-multiply-error r=estebank Improve wording of ""cannot multiply"" type error For example if you had this code: fn foo(x: i32 y: f32) -> f32 { x * y } You would get this error: error[E0277]: cannot multiply `f32` to `i32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32` However that's not usually how people describe multiplication. People usually describe multiplication like how the division error words it: error[E0277]: cannot divide `i32` by `f32` --> src/lib.rs:2:7 | 2 | x / y | ^ no implementation for `i32 / f32` | = help: the trait `Div` is not implemented for `i32` So that's what this change does. It changes this: error[E0277]: cannot multiply `f32` to `i32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32` To this: error[E0277]: cannot multiply `i32` by `f32` --> src/lib.rs:2:7 | 2 | x * y | ^ no implementation for `i32 * f32` | = help: the trait `Mul` is not implemented for `i32`",THUMBS_UP,2020-10-21T13:40:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2020-10-18T12:00:44Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,HEART,2020-10-18T13:25:45Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2020-10-18T16:07:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2020-10-26T19:35:57Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2020-11-22T19:20:34Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2021-02-09T14:35:12Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2021-02-10T16:17:25Z,Lokathor,NA https://github.com/rust-lang/rust/pull/78068,MERGED,2020-10-18T11:58:08Z,2020-12-15T14:22:28Z,consider assignments of union field of ManuallyDrop type safe,RalfJung,99baddb57c0a950c1af8d125dc470894ddf052a7,6,Auto merge of #78068 - RalfJung:union-safe-assign r=nikomatsakis consider assignments of union field of ManuallyDrop type safe Assigning to `Copy` union fields is safe because that assignment will never drop anything. However with https://github.com/rust-lang/rust/pull/77547 unions may also have `ManuallyDrop` fields and their assignments are currently still unsafe. That seems unnecessary though as assigning `ManuallyDrop` does not drop anything either and is thus safe even for union fields. I assume this will at least require FCP.,THUMBS_UP,2021-02-12T12:44:58Z,oilaba,NA https://github.com/rust-lang/rust/pull/78072,MERGED,2020-10-18T13:25:54Z,2020-10-25T00:25:14Z,Cleanup constant matching in exhaustiveness checking,Nadrieril,e12e97223f9f0bb0f2806334029aec1d9790f074,12,Rollup merge of #78072 - Nadrieril:cleanup-constant-matching r=varkor Cleanup constant matching in exhaustiveness checking This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work. I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed #78071,HEART,2020-10-21T17:53:54Z,varkor,NA https://github.com/rust-lang/rust/pull/78072,MERGED,2020-10-18T13:25:54Z,2020-10-25T00:25:14Z,Cleanup constant matching in exhaustiveness checking,Nadrieril,e12e97223f9f0bb0f2806334029aec1d9790f074,12,Rollup merge of #78072 - Nadrieril:cleanup-constant-matching r=varkor Cleanup constant matching in exhaustiveness checking This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work. I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed #78071,LAUGH,2021-05-31T13:34:57Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/78072,MERGED,2020-10-18T13:25:54Z,2020-10-25T00:25:14Z,Cleanup constant matching in exhaustiveness checking,Nadrieril,e12e97223f9f0bb0f2806334029aec1d9790f074,12,Rollup merge of #78072 - Nadrieril:cleanup-constant-matching r=varkor Cleanup constant matching in exhaustiveness checking This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work. I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed #78071,HEART,2021-05-31T13:34:58Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-18T17:34:13Z,est31,NA https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-19T15:55:26Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-19T22:03:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-21T20:35:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-22T02:52:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-29T08:13:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-29T15:38:25Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-30T05:27:26Z,camelid,NA https://github.com/rust-lang/rust/pull/78077,MERGED,2020-10-18T16:48:58Z,2020-10-21T22:37:41Z,Calculate visibilities once in resolve,petrochenkov,1eaadebb3dee31669c7649b32747381d11614fae,26,Auto merge of #78077 - petrochenkov:qvis r=davidtwco Calculate visibilities once in resolve Then use them through a query based on resolver outputs. Item visibilities were previously calculated in three places - initially in `rustc_resolve` then in `rustc_privacy` during type privacy checkin and then in `rustc_metadata` during metadata encoding. The visibility logic is not entirely trivial especially for things like constructors or enum variants and all of it was duplicated. This PR deduplicates all the visibility calculations visibilities are determined once during early name resolution and then stored in `ResolverOutputs` and are later available through `tcx` as a query `tcx.visibility(def_id)`. (This query existed previously but only worked for other crates.) Some special cases (e.g. visibilities for closure types which are needed for type privacy checking) are not processed in resolve but deferred and performed directly in the query instead.,HEART,2020-10-30T10:27:02Z,0x29a,NA https://github.com/rust-lang/rust/pull/78082,CLOSED,2020-10-18T19:37:01Z,2020-12-18T16:26:47Z,[WIP] Get rid of rustdoc::doctree,jyn514,NA,NA,NA,HEART,2020-10-19T00:08:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/78082,CLOSED,2020-10-18T19:37:01Z,2020-12-18T16:26:47Z,[WIP] Get rid of rustdoc::doctree,jyn514,NA,NA,NA,HEART,2020-10-19T04:30:12Z,camelid,NA https://github.com/rust-lang/rust/pull/78082,CLOSED,2020-10-18T19:37:01Z,2020-12-18T16:26:47Z,[WIP] Get rid of rustdoc::doctree,jyn514,NA,NA,NA,HEART,2020-10-19T16:00:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78082,CLOSED,2020-10-18T19:37:01Z,2020-12-18T16:26:47Z,[WIP] Get rid of rustdoc::doctree,jyn514,NA,NA,NA,HEART,2020-11-17T09:27:06Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78083,MERGED,2020-10-18T19:56:34Z,2020-12-19T10:13:55Z,Stabilize or_insert_with_key,ChaiTRex,0765536c0be31100eaa4bf6d00274bbad280621c,3,Rollup merge of #78083 - ChaiTRex:master r=m-ou-se Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)` avoiding the need to copy or clone the key.,HEART,2020-10-24T10:30:49Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/78083,MERGED,2020-10-18T19:56:34Z,2020-12-19T10:13:55Z,Stabilize or_insert_with_key,ChaiTRex,0765536c0be31100eaa4bf6d00274bbad280621c,3,Rollup merge of #78083 - ChaiTRex:master r=m-ou-se Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)` avoiding the need to copy or clone the key.,THUMBS_UP,2020-10-28T11:16:29Z,a1phyr,NA https://github.com/rust-lang/rust/pull/78083,MERGED,2020-10-18T19:56:34Z,2020-12-19T10:13:55Z,Stabilize or_insert_with_key,ChaiTRex,0765536c0be31100eaa4bf6d00274bbad280621c,3,Rollup merge of #78083 - ChaiTRex:master r=m-ou-se Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)` avoiding the need to copy or clone the key.,HEART,2020-11-06T15:38:24Z,Eh2406,JFinkelm@amazon.com https://github.com/rust-lang/rust/pull/78083,MERGED,2020-10-18T19:56:34Z,2020-12-19T10:13:55Z,Stabilize or_insert_with_key,ChaiTRex,0765536c0be31100eaa4bf6d00274bbad280621c,3,Rollup merge of #78083 - ChaiTRex:master r=m-ou-se Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)` avoiding the need to copy or clone the key.,HEART,2020-12-10T21:17:57Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78083,MERGED,2020-10-18T19:56:34Z,2020-12-19T10:13:55Z,Stabilize or_insert_with_key,ChaiTRex,0765536c0be31100eaa4bf6d00274bbad280621c,3,Rollup merge of #78083 - ChaiTRex:master r=m-ou-se Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)` avoiding the need to copy or clone the key.,THUMBS_UP,2020-12-10T21:18:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78084,MERGED,2020-10-18T19:58:31Z,2020-10-22T04:05:48Z,Greatly improve display for small mobile devices screens,GuillaumeGomez,d9cf1f20508fd27fb3bd79df3fd2a3ba8d141b05,1,"Rollup merge of #78084 - GuillaumeGomez:improve-mobile-display r=jyn514 Nemo157 Greatly improve display for small mobile devices screens Fixes #78014. The biggest change being the ""search bar"". Instead of having everything on one line I decided to move the search input on its own: ![Screenshot from 2020-10-18 21-54-26](https://user-images.githubusercontent.com/3050060/96378530-c863a800-118c-11eb-8e82-a43fce312b5b.png) Another change is that now we ""break words"" in the listing so that they don't grow too big: ![Screenshot from 2020-10-18 21-57-17](https://user-images.githubusercontent.com/3050060/96378555-ffd25480-118c-11eb-8a71-8f116c7edd93.png) r? @jyn514",HEART,2020-10-29T08:57:03Z,redwarp,NA https://github.com/rust-lang/rust/pull/78084,MERGED,2020-10-18T19:58:31Z,2020-10-22T04:05:48Z,Greatly improve display for small mobile devices screens,GuillaumeGomez,d9cf1f20508fd27fb3bd79df3fd2a3ba8d141b05,1,"Rollup merge of #78084 - GuillaumeGomez:improve-mobile-display r=jyn514 Nemo157 Greatly improve display for small mobile devices screens Fixes #78014. The biggest change being the ""search bar"". Instead of having everything on one line I decided to move the search input on its own: ![Screenshot from 2020-10-18 21-54-26](https://user-images.githubusercontent.com/3050060/96378530-c863a800-118c-11eb-8e82-a43fce312b5b.png) Another change is that now we ""break words"" in the listing so that they don't grow too big: ![Screenshot from 2020-10-18 21-57-17](https://user-images.githubusercontent.com/3050060/96378555-ffd25480-118c-11eb-8a71-8f116c7edd93.png) r? @jyn514",HEART,2020-10-29T15:36:41Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78084,MERGED,2020-10-18T19:58:31Z,2020-10-22T04:05:48Z,Greatly improve display for small mobile devices screens,GuillaumeGomez,d9cf1f20508fd27fb3bd79df3fd2a3ba8d141b05,1,"Rollup merge of #78084 - GuillaumeGomez:improve-mobile-display r=jyn514 Nemo157 Greatly improve display for small mobile devices screens Fixes #78014. The biggest change being the ""search bar"". Instead of having everything on one line I decided to move the search input on its own: ![Screenshot from 2020-10-18 21-54-26](https://user-images.githubusercontent.com/3050060/96378530-c863a800-118c-11eb-8e82-a43fce312b5b.png) Another change is that now we ""break words"" in the listing so that they don't grow too big: ![Screenshot from 2020-10-18 21-57-17](https://user-images.githubusercontent.com/3050060/96378555-ffd25480-118c-11eb-8a71-8f116c7edd93.png) r? @jyn514",HEART,2020-11-02T02:12:34Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78084,MERGED,2020-10-18T19:58:31Z,2020-10-22T04:05:48Z,Greatly improve display for small mobile devices screens,GuillaumeGomez,d9cf1f20508fd27fb3bd79df3fd2a3ba8d141b05,1,"Rollup merge of #78084 - GuillaumeGomez:improve-mobile-display r=jyn514 Nemo157 Greatly improve display for small mobile devices screens Fixes #78014. The biggest change being the ""search bar"". Instead of having everything on one line I decided to move the search input on its own: ![Screenshot from 2020-10-18 21-54-26](https://user-images.githubusercontent.com/3050060/96378530-c863a800-118c-11eb-8e82-a43fce312b5b.png) Another change is that now we ""break words"" in the listing so that they don't grow too big: ![Screenshot from 2020-10-18 21-57-17](https://user-images.githubusercontent.com/3050060/96378555-ffd25480-118c-11eb-8a71-8f116c7edd93.png) r? @jyn514",THUMBS_DOWN,2020-11-04T11:54:01Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/78084,MERGED,2020-10-18T19:58:31Z,2020-10-22T04:05:48Z,Greatly improve display for small mobile devices screens,GuillaumeGomez,d9cf1f20508fd27fb3bd79df3fd2a3ba8d141b05,1,"Rollup merge of #78084 - GuillaumeGomez:improve-mobile-display r=jyn514 Nemo157 Greatly improve display for small mobile devices screens Fixes #78014. The biggest change being the ""search bar"". Instead of having everything on one line I decided to move the search input on its own: ![Screenshot from 2020-10-18 21-54-26](https://user-images.githubusercontent.com/3050060/96378530-c863a800-118c-11eb-8e82-a43fce312b5b.png) Another change is that now we ""break words"" in the listing so that they don't grow too big: ![Screenshot from 2020-10-18 21-57-17](https://user-images.githubusercontent.com/3050060/96378555-ffd25480-118c-11eb-8a71-8f116c7edd93.png) r? @jyn514",THUMBS_UP,2020-11-05T10:51:18Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78085,MERGED,2020-10-18T20:34:35Z,2020-10-25T14:17:57Z,MIR validation should check `SwitchInt` values are valid for the type,wesleywiser,dbdc61f9f91e39003cf18131c9eb3dfa5eccfd50,1,Rollup merge of #78085 - wesleywiser:mir_validation_switch_int r=oli-obk MIR validation should check `SwitchInt` values are valid for the type Fixes #75440,HEART,2020-10-18T23:16:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-10-19T18:50:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-10-19T18:59:40Z,estebank,NA https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-10-26T13:26:25Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",HEART,2020-10-29T17:04:51Z,estebank,NA https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-10-30T00:07:10Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",HEART,2020-10-30T00:07:16Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-11-11T17:12:15Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78088,MERGED,2020-10-18T21:39:05Z,2020-11-20T06:01:50Z,"Add lint for panic!(""{}"")",m-ou-se,74285eb3a83eac639f9c54ba8c4ccf9879b3b00a,22,"Auto merge of #78088 - fusion-engineering-forks:panic-fmt-lint r=estebank Add lint for panic!(""{}"") This adds a lint that warns about `panic!(""{}"")`. `panic!(msg)` invocations with a single argument use their argument as panic payload literally without using it as a format string. The same holds for `assert!(expr msg)`. This lints checks if `msg` is a string literal (after expansion) and warns in case it contained braces. It suggests to insert `""{}"" ` to use the message literally or to add arguments to use it as a format string. ![image](https://user-images.githubusercontent.com/783247/96643867-79eb1080-1328-11eb-8d4e-a5586837c70a.png) This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.",THUMBS_UP,2020-11-26T07:39:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78094,MERGED,2020-10-19T01:24:38Z,2020-10-21T13:39:10Z,rustdoc: Show the correct source filename in page titles without `.html`,camelid,72ae00bc1df1e2f5b9a68d608347a0aa9b0dede5,1,Rollup merge of #78094 - camelid:rustdoc-fix-source-title r=jyn514 rustdoc: Show the correct source filename in page titles without `.html` Previously the title would be lib.rs.html -- source if `lib.rs` was the actual source filename. Now the title is lib.rs - source,CONFUSED,2020-10-19T02:56:47Z,fmease,NA https://github.com/rust-lang/rust/pull/78103,MERGED,2020-10-19T11:47:23Z,2020-10-19T20:27:07Z,Add link to rustdoc book in rustdoc help popup,GuillaumeGomez,cbcf8d4235148836a109d2038467c9a27f0f4be2,5,Rollup merge of #78103 - GuillaumeGomez:rustdoc-book r=jyn514 Add link to rustdoc book in rustdoc help popup Part of #75520. It looks like this: ![Screenshot from 2020-10-19 13-46-02](https://user-images.githubusercontent.com/3050060/96446334-934d6900-1211-11eb-8fdc-133fecc8c30d.png) ![Screenshot from 2020-10-19 13-43-46](https://user-images.githubusercontent.com/3050060/96446335-947e9600-1211-11eb-955c-68af5292aecc.png) ![Screenshot from 2020-10-19 13-37-26](https://user-images.githubusercontent.com/3050060/96446337-947e9600-1211-11eb-9a2e-399b99178a65.png) r? @jyn514,THUMBS_UP,2020-10-19T12:08:15Z,Cldfire,NA https://github.com/rust-lang/rust/pull/78103,MERGED,2020-10-19T11:47:23Z,2020-10-19T20:27:07Z,Add link to rustdoc book in rustdoc help popup,GuillaumeGomez,cbcf8d4235148836a109d2038467c9a27f0f4be2,5,Rollup merge of #78103 - GuillaumeGomez:rustdoc-book r=jyn514 Add link to rustdoc book in rustdoc help popup Part of #75520. It looks like this: ![Screenshot from 2020-10-19 13-46-02](https://user-images.githubusercontent.com/3050060/96446334-934d6900-1211-11eb-8fdc-133fecc8c30d.png) ![Screenshot from 2020-10-19 13-43-46](https://user-images.githubusercontent.com/3050060/96446335-947e9600-1211-11eb-955c-68af5292aecc.png) ![Screenshot from 2020-10-19 13-37-26](https://user-images.githubusercontent.com/3050060/96446337-947e9600-1211-11eb-9a2e-399b99178a65.png) r? @jyn514,THUMBS_UP,2020-10-19T14:11:50Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78107,CLOSED,2020-10-19T16:31:02Z,2020-11-21T08:42:25Z,Try not to copy when allocating from iterators take 3,bugadani,NA,NA,NA,HEART,2020-10-20T13:37:25Z,est31,NA https://github.com/rust-lang/rust/pull/78111,MERGED,2020-10-19T17:11:19Z,2020-10-20T05:27:20Z,Trait predicate ambiguities are not always in `Self`,SNCPlay42,3f1c637db4ba835a7a79a84566dae4a1b1e4a1ac,8,Rollup merge of #78111 - SNCPlay42:not-always-self r=lcnr Trait predicate ambiguities are not always in `Self` When reporting ambiguities in trait predicates the compiler incorrectly assumed the ambiguity was always in the type the trait should be implemented on and never the generic parameters of the trait. This caused silly suggestions for predicates like `>` such as giving explicit types to completely unrelated variables that happened to be of type `KnownType`. This also reverts #73027 which worked around this issue in some cases and does not appear to be necessary any more. fixes #77982 fixes #78055,HEART,2020-10-19T18:28:18Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78111,MERGED,2020-10-19T17:11:19Z,2020-10-20T05:27:20Z,Trait predicate ambiguities are not always in `Self`,SNCPlay42,3f1c637db4ba835a7a79a84566dae4a1b1e4a1ac,8,Rollup merge of #78111 - SNCPlay42:not-always-self r=lcnr Trait predicate ambiguities are not always in `Self` When reporting ambiguities in trait predicates the compiler incorrectly assumed the ambiguity was always in the type the trait should be implemented on and never the generic parameters of the trait. This caused silly suggestions for predicates like `>` such as giving explicit types to completely unrelated variables that happened to be of type `KnownType`. This also reverts #73027 which worked around this issue in some cases and does not appear to be necessary any more. fixes #77982 fixes #78055,HEART,2020-10-20T04:15:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-10-19T21:29:37Z,est31,NA https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-10-20T04:40:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-10-25T08:09:05Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-10-26T18:51:45Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-11-08T06:09:44Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78119,MERGED,2020-10-19T20:39:07Z,2020-10-25T00:25:10Z,"Throw core::panic!(""message"") as &str instead of String.",m-ou-se,e3808edeeea28c137129c0c5bf70c24562e794f5,3,"Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str r=Amanieu Throw core::panic!(""message"") as &str instead of String. This makes `core::panic!(""message"")` consistent with `std::panic!(""message"")` which throws a `&str` and not a `String`. This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String` which includes compiler-generated panics such as the panics generated for `mem::zeroed()`. --- Demonstration: ```rust use std::panic; use std::any::Any; fn main() { panic::set_hook(Box::new(|panic_info| check(panic_info.payload()))); check(&*panic::catch_unwind(|| core::panic!(""core"")).unwrap_err()); check(&*panic::catch_unwind(|| std::panic!(""std"")).unwrap_err()); } fn check(msg: &(dyn Any + Send)) { if let Some(s) = msg.downcast_ref::() { println!(""Got a String: {:?}"" s); } else if let Some(s) = msg.downcast_ref::<&str>() { println!(""Got a &str: {:?}"" s); } } ``` Before: ``` Got a String: ""core"" Got a String: ""core"" Got a &str: ""std"" Got a &str: ""std"" ``` After: ``` Got a &str: ""core"" Got a &str: ""core"" Got a &str: ""std"" Got a &str: ""std"" ```",HEART,2020-12-07T14:44:18Z,LunarLambda,NA https://github.com/rust-lang/rust/pull/78121,MERGED,2020-10-19T21:24:37Z,2020-10-20T05:27:18Z,Do not ICE on pattern that uses a binding multiple times in generator,LeSeulArtichaut,21df410a621950ee8ef50afd96a599c82c952882,2,Rollup merge of #78121 - LeSeulArtichaut:issue-78115 r=tmandry Do not ICE on pattern that uses a binding multiple times in generator Fixes #78115. r? @tmandry,HEART,2020-10-19T21:48:22Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-19T22:23:49Z,bugadani,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-19T22:36:08Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-19T23:05:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-20T05:45:04Z,ds84182,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",THUMBS_UP,2020-10-20T08:39:14Z,qwerty19106,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-20T09:01:44Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",ROCKET,2020-10-21T12:12:01Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",THUMBS_UP,2020-10-26T15:42:13Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-10-27T05:56:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",ROCKET,2020-10-28T06:48:03Z,laizy,aochyi@126.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-11-22T07:52:01Z,qarmin,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",ROCKET,2020-11-30T22:50:18Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-11-30T22:50:20Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-12-10T06:43:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",HEART,2020-12-10T10:45:11Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",THUMBS_UP,2020-12-10T10:45:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78122,MERGED,2020-10-19T22:14:54Z,2020-11-30T01:42:15Z,Avoid panic_bounds_check in fmt::write.,m-ou-se,cf9bfdb8726c07974c8db93f70ee7213ee20c563,3,"Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary because indexing used in fmt::write would generate code using panic_bounds_check which prints the index and length. These bounds checks are not necessary as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked to reduce the amount of generated code which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary:
Source code ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = ""c"")] extern ""C"" { #[allow(improper_ctypes)] fn write(fd: i32 s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self s: &str) -> fmt::Result { unsafe { write(1 s) }; Ok(()) } } #[start] fn main(_argc: isize _argv: *const *const u8) -> isize { let _ = writeln!(Stdout ""Hello World""); 0 } #[lang = ""eh_personality""] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ```
Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T ::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001ce0 T core::fmt::num::imp::::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip::new 0000000000001c90 t core::iter::adapters::zip::Zip::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip::new 0000000000001660 t core::iter::adapters::zip::Zip::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```",ROCKET,2020-12-10T10:45:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78131,MERGED,2020-10-20T07:16:05Z,2020-10-22T07:04:28Z,Package more llvm-* tools in the rust-dev component for run-make-fulldeps tests,SimonSapin,8f0fa9d51ff4ad2c0869e660856cd327e79915e9,3,Auto merge of #78131 - SimonSapin:ar r=Mark-Simulacrum Package more llvm-* tools in the rust-dev component for run-make-fulldeps tests Fixes https://github.com/rust-lang/rust/issues/78110,THUMBS_UP,2020-10-20T16:26:33Z,est31,NA https://github.com/rust-lang/rust/pull/78133,MERGED,2020-10-20T08:40:42Z,2020-10-20T23:33:41Z,Add some MIR-related regression tests,JohnTitor,a8a424f4aad4444a89f1d40d97ef9da824f7d015,5,Rollup merge of #78133 - JohnTitor:mir-tests r=lcnr Add some MIR-related regression tests Closes #68841 Closes #75053 Closes #76375 Closes #77911 I think they're fixed by #77306.,HEART,2020-10-20T09:27:31Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78134,MERGED,2020-10-20T09:30:16Z,2020-10-22T09:31:06Z,Use `DroplessArena` where we know the type doesn't need drop,bugadani,6b9fbf212a06944ff23325d2d63215805dc3c6c3,3,Auto merge of #78134 - bugadani:arena-nodrop r=lcnr Use `DroplessArena` where we know the type doesn't need drop This PR uses a single `DroplessArena` in resolve instead of three separate `TypedArena`s. `DroplessArena` checks that the type indeed doesn't need drop so in case the types change this will result in visible failures.,THUMBS_UP,2020-10-20T13:44:29Z,est31,NA https://github.com/rust-lang/rust/pull/78151,MERGED,2020-10-20T16:35:14Z,2020-10-20T19:25:31Z,Disable MatchBranchSimplification,tmiasko,981346fc07dd5ef414c5b1b21999f7604cece006,7,Auto merge of #78151 - tmiasko:disable-match-branch-simplification r=wesleywiser Disable MatchBranchSimplification This optimization can result in unsoundness because it introduces additional uses of a place holding the discriminant value without ensuring that it is valid to do so. Found by validation from #77369 / #78147.,THUMBS_UP,2020-10-20T16:49:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78153,MERGED,2020-10-20T17:04:39Z,2020-10-23T12:01:38Z,Sync LLVM submodule if it has been initialized,est31,025481a5eb519f3f9e34e61cd67bbbcc2591e1a8,1,Rollup merge of #78153 - est31:downloaded_llvm_maybe_sync r=Mark-Simulacrum Sync LLVM submodule if it has been initialized Since having enabled the download-ci-llvm option and having rebased on top of #76864 I've noticed that I had to update the llvm-project submodule manually if it was checked out. Orignally the submodule update logic was introduced to reduce the friction for contributors to manage the submodules or in other words to prevent getting PRs that have unwanted submodule rollbacks because the contributors didn't run git submodule update. This commit adds logic to ensure there is no inadvertent LLVM submodule rollback in a PR if download-ci-llvm (or llvm-config) is enabled. It will detect whether the llvm-project submodule is initialized and if so update it in any case. If it is not initialized behaviour is kept to not do any update/initialization. An alternative to the chosen implementation would be to not pass the --init command line arg to `git submodule update` for the src/llvm-project submodule. This would show a confusing error message however on all builds with an uninitialized repo. We could pass the --silent param but we still want it to print something if it is initialized and has to update something. So we just do a manual check for whether the submodule is initialized.,THUMBS_UP,2020-10-20T17:34:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-20T22:00:36Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-20T22:21:08Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-21T01:34:53Z,est31,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-21T20:04:20Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HEART,2020-10-22T11:06:31Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-22T11:17:57Z,varkor,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-10-29T21:25:15Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-11-07T23:31:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-11-07T23:41:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,EYES,2020-11-10T11:45:07Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,EYES,2020-11-11T09:47:53Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HEART,2020-11-21T07:10:41Z,JeanMertz,git@jeanmertz.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-11-22T21:19:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-11-27T21:51:00Z,Eucladia,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,CONFUSED,2020-12-09T17:22:58Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-12-20T13:13:42Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2020-12-22T02:51:05Z,camelid,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-02T00:32:03Z,RustyYato,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-02T03:55:41Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HEART,2021-01-02T15:47:04Z,branpk,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-02T15:47:04Z,branpk,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-02T17:30:43Z,joseluis,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-04T11:58:34Z,aldanor,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,EYES,2021-01-04T11:58:36Z,aldanor,NA https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-10T07:13:04Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/78166,CLOSED,2020-10-20T21:56:40Z,2021-02-19T15:36:54Z,Support `pub` on `macro_rules`,petrochenkov,NA,NA,NA,HOORAY,2021-01-11T18:45:46Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78182,MERGED,2020-10-21T12:33:57Z,2020-10-31T01:35:19Z,TypeVisitor: use `std::ops::ControlFlow` instead of `bool`,LeSeulArtichaut,0d033dee3eff6e30c15c4c51958e219134dcc7bc,38,Auto merge of #78182 - LeSeulArtichaut:ty-visitor-contolflow r=lcnr oli-obk TypeVisitor: use `std::ops::ControlFlow` instead of `bool` Implements MCP rust-lang/compiler-team#374. Blocked on FCP in rust-lang/compiler-team#374. r? `@lcnr` cc `@jonas-schievink`,HEART,2020-10-21T14:12:03Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78182,MERGED,2020-10-21T12:33:57Z,2020-10-31T01:35:19Z,TypeVisitor: use `std::ops::ControlFlow` instead of `bool`,LeSeulArtichaut,0d033dee3eff6e30c15c4c51958e219134dcc7bc,38,Auto merge of #78182 - LeSeulArtichaut:ty-visitor-contolflow r=lcnr oli-obk TypeVisitor: use `std::ops::ControlFlow` instead of `bool` Implements MCP rust-lang/compiler-team#374. Blocked on FCP in rust-lang/compiler-team#374. r? `@lcnr` cc `@jonas-schievink`,HEART,2020-10-21T16:13:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78182,MERGED,2020-10-21T12:33:57Z,2020-10-31T01:35:19Z,TypeVisitor: use `std::ops::ControlFlow` instead of `bool`,LeSeulArtichaut,0d033dee3eff6e30c15c4c51958e219134dcc7bc,38,Auto merge of #78182 - LeSeulArtichaut:ty-visitor-contolflow r=lcnr oli-obk TypeVisitor: use `std::ops::ControlFlow` instead of `bool` Implements MCP rust-lang/compiler-team#374. Blocked on FCP in rust-lang/compiler-team#374. r? `@lcnr` cc `@jonas-schievink`,HEART,2020-10-21T18:54:20Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78182,MERGED,2020-10-21T12:33:57Z,2020-10-31T01:35:19Z,TypeVisitor: use `std::ops::ControlFlow` instead of `bool`,LeSeulArtichaut,0d033dee3eff6e30c15c4c51958e219134dcc7bc,38,Auto merge of #78182 - LeSeulArtichaut:ty-visitor-contolflow r=lcnr oli-obk TypeVisitor: use `std::ops::ControlFlow` instead of `bool` Implements MCP rust-lang/compiler-team#374. Blocked on FCP in rust-lang/compiler-team#374. r? `@lcnr` cc `@jonas-schievink`,HEART,2021-06-17T16:39:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-10-21T21:38:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-10-22T12:21:13Z,mati865,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-10-22T13:51:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-10-22T16:18:30Z,bdonlan,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-06T19:16:18Z,lqd,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-12T06:58:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-12T10:58:28Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-12T23:17:24Z,tmandry,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-13T04:35:04Z,guilt,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,THUMBS_UP,2020-11-13T06:13:51Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-11-13T15:25:46Z,alarsyo,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,THUMBS_UP,2020-12-31T19:24:02Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2020-12-31T19:24:03Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2021-01-05T02:35:35Z,worstpractice,NA https://github.com/rust-lang/rust/pull/78201,MERGED,2020-10-21T19:56:48Z,2020-11-09T13:51:00Z,Compile rustc crates with the initial-exec TLS model,joshtriplett,25f6938da459a57b43bdf16ed6bdad3225b2a3ce,2,Auto merge of #78201 - joshtriplett:rustc-tls-model r=Mark-Simulacrum Compile rustc crates with the initial-exec TLS model This should produce more efficient code with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen but that shouldn't be a problem for rustc's internal libraries.,HEART,2021-02-18T23:37:26Z,dmilith,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2020-10-21T22:16:26Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2020-10-22T04:22:03Z,estebank,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2020-10-22T09:01:17Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-22T11:02:07Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-22T21:11:00Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-22T21:11:18Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-22T21:16:39Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-23T23:38:00Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,ROCKET,2020-10-23T23:38:03Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2020-10-23T23:50:29Z,Emerentius,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,CONFUSED,2020-10-24T15:26:51Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,EYES,2020-10-25T00:19:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2020-10-26T13:48:46Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2020-10-26T21:41:08Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,EYES,2020-10-27T02:08:12Z,tesuji,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,CONFUSED,2020-10-27T02:08:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2021-01-14T18:59:02Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2021-03-18T04:11:12Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2021-03-18T04:11:14Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,ROCKET,2021-03-18T04:11:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2021-03-18T23:42:50Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,HEART,2021-03-19T01:03:02Z,tux3,NA https://github.com/rust-lang/rust/pull/78204,CLOSED,2020-10-21T20:36:07Z,2021-03-22T17:57:09Z,impl IntoIterator for (A B) as Zip,cuviper,NA,NA,NA,THUMBS_UP,2021-03-23T13:50:28Z,GoldsteinE,root@goldstein.rs https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-10-22T07:47:36Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-10-22T11:51:34Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-10-24T06:40:55Z,est31,NA https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-10-27T23:41:39Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-10-28T11:46:30Z,faern,NA https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-11-04T09:49:38Z,elichai,NA https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",HEART,2020-11-08T19:28:23Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78216,MERGED,2020-10-22T04:29:08Z,2020-11-12T00:34:40Z,Duration::zero() -> Duration::ZERO,workingjubilee,62f0a78056a8b994f6bbe57c8349f1a0704713c3,4,"Rollup merge of #78216 - workingjubilee:duration-zero r=m-ou-se Duration::zero() -> Duration::ZERO In review for #72790 whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO which would be reason enough. ZERO also ""makes sense"" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const which could hurt discoverability of the associated constants overall. Elsewhere in `std` methods for obtaining a constant value were even deprecated as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly ZERO costs less to use. A match supports a const pattern but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value ""can"" is not ""will"". Only const contexts have a strong promise of such. Even without that in mind the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use may cost less to optimize and seems to have more of a community consensus for it the associated const seems best. r? ```@LukasKalbertodt```",THUMBS_UP,2020-11-11T16:39:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78227,MERGED,2020-10-22T10:26:07Z,2020-10-27T13:58:11Z,Capture output from threads spawned in tests,SergioBenitez,56d288fa46e04cd5faf53d369a1a640a97e2bb08,14,Auto merge of #78227 - SergioBenitez:test-stdout-threading r=m-ou-se Capture output from threads spawned in tests This is revival of #75172. Original text: > Fixes #42474. > > r? `@​dtolnay` since you expressed interest in this but feel free to redirect if you aren't the right person anymore. --- Closes #75172.,HEART,2020-12-28T23:13:24Z,tmandry,NA https://github.com/rust-lang/rust/pull/78227,MERGED,2020-10-22T10:26:07Z,2020-10-27T13:58:11Z,Capture output from threads spawned in tests,SergioBenitez,56d288fa46e04cd5faf53d369a1a640a97e2bb08,14,Auto merge of #78227 - SergioBenitez:test-stdout-threading r=m-ou-se Capture output from threads spawned in tests This is revival of #75172. Original text: > Fixes #42474. > > r? `@​dtolnay` since you expressed interest in this but feel free to redirect if you aren't the right person anymore. --- Closes #75172.,HEART,2020-12-31T19:10:37Z,rrbutani,NA https://github.com/rust-lang/rust/pull/78227,MERGED,2020-10-22T10:26:07Z,2020-10-27T13:58:11Z,Capture output from threads spawned in tests,SergioBenitez,56d288fa46e04cd5faf53d369a1a640a97e2bb08,14,Auto merge of #78227 - SergioBenitez:test-stdout-threading r=m-ou-se Capture output from threads spawned in tests This is revival of #75172. Original text: > Fixes #42474. > > r? `@​dtolnay` since you expressed interest in this but feel free to redirect if you aren't the right person anymore. --- Closes #75172.,THUMBS_UP,2021-02-22T20:44:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T10:44:57Z,mati865,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T11:10:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T11:19:15Z,JamieCunliffe,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T11:23:56Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T13:06:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T14:19:17Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T16:17:42Z,bdonlan,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T18:53:08Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T19:17:20Z,est31,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T22:04:33Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-22T22:06:36Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-10-22T22:08:08Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-23T04:35:03Z,vigoux,contact@vigoux.giize.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-10-29T21:29:13Z,yerke,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-10-29T21:29:14Z,yerke,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,THUMBS_UP,2020-10-29T21:29:16Z,yerke,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-02T22:34:43Z,Stammark,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-09T00:40:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-09T00:40:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-09T11:21:57Z,elichai,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-09T12:09:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-09T13:22:15Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-09T14:22:19Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-09T15:12:58Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-09T15:13:05Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-09T18:19:19Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-09T23:45:51Z,nn1ks,niklas@n1ks.net https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-10T03:41:57Z,nicklauri,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,THUMBS_UP,2020-11-10T03:41:59Z,nicklauri,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-10T07:49:33Z,Hywan,ivan@mnt.io https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-10T13:36:54Z,raw-bin,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-10T15:26:12Z,chrish42,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-10T15:26:13Z,chrish42,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-10T21:39:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-10T21:39:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,THUMBS_UP,2020-11-10T21:39:10Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-11T16:34:02Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-16T17:33:32Z,WardBenjamin,github@blward.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2020-11-25T09:10:37Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-11-25T09:10:38Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,THUMBS_UP,2020-11-25T09:10:38Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HEART,2020-11-25T09:10:40Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2020-12-10T20:07:24Z,a1phyr,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HEART,2020-12-31T14:33:28Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,THUMBS_UP,2021-01-10T10:18:13Z,Voronar,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HOORAY,2021-01-10T10:18:15Z,Voronar,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,HEART,2021-01-10T10:18:16Z,Voronar,NA https://github.com/rust-lang/rust/pull/78228,MERGED,2020-10-22T10:33:07Z,2020-11-09T02:58:43Z,Promote aarch64-unknown-linux-gnu to Tier 1,pietroalbini,50086afb5d02f2e4d3913c9b008e76136771326a,5,Rollup merge of #78228 - pietroalbini:finally r=Mark-Simulacrum Promote aarch64-unknown-linux-gnu to Tier 1 This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1 as proposed by [RFC 2959]: * The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`. * The platform support documentation is updated uplifting the target to Tiert 1 with a note about missing stack probes support. * Building the documentation is enabled for the target as we produce the `rust-docs` component for all Tier 1 platforms. [RFC 2959]: https://github.com/rust-lang/rfcs/pull/2959,ROCKET,2021-01-10T10:18:16Z,Voronar,NA https://github.com/rust-lang/rust/pull/78231,MERGED,2020-10-22T12:00:32Z,2020-10-23T12:01:25Z,Make closures inherit the parent function's target features,LeSeulArtichaut,00c4dcdbb456964cfda35a1d447a0ee630b79c39,2,Rollup merge of #78231 - LeSeulArtichaut:closure-target_feature r=nikomatsakis Make closures inherit the parent function's target features r? @ghost Closes #73631,HEART,2020-10-22T17:36:33Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78231,MERGED,2020-10-22T12:00:32Z,2020-10-23T12:01:25Z,Make closures inherit the parent function's target features,LeSeulArtichaut,00c4dcdbb456964cfda35a1d447a0ee630b79c39,2,Rollup merge of #78231 - LeSeulArtichaut:closure-target_feature r=nikomatsakis Make closures inherit the parent function's target features r? @ghost Closes #73631,HEART,2020-10-23T16:15:18Z,calebzulawski,NA https://github.com/rust-lang/rust/pull/78235,MERGED,2020-10-22T13:48:35Z,2020-10-23T12:01:24Z,Explain where the closure return type was inferred,Aaron1011,3f462c22b53ee5ae2f56e2b268a15fd4dab9d22c,4,Rollup merge of #78235 - Aaron1011:closure-ret-infer r=varkor Explain where the closure return type was inferred Fixes #78193,HEART,2020-10-30T17:28:05Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78249,MERGED,2020-10-22T21:11:40Z,2020-10-24T18:21:32Z,improve const infer error,lcnr,77cd5b5485a9ba13ff291cc993cff44cf81e1901,2,Rollup merge of #78249 - lcnr:ct-infer-origin r=varkor improve const infer error For type inference we probably have to be careful about subtyping and stuff but considering that subtyping shouldn't be relevant for constants I don't really see a reason why we may not want to reuse the const origin here. r? `@varkor`,HEART,2020-10-22T21:54:13Z,varkor,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-23T00:18:16Z,Hoverbear,operator@hoverbear.org https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-23T02:29:12Z,moose-consulting,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-23T15:05:12Z,estebank,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-23T18:19:22Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-23T21:08:15Z,punkeel,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-24T01:04:45Z,arora-aman,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-29T08:48:43Z,sthiele,sthiele78@gmail.com https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-29T09:30:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-29T11:19:19Z,jamwaffles,james@wapl.es https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-29T12:23:09Z,tux3,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-29T23:56:19Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-31T07:18:04Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-10-31T18:11:02Z,hpatjens,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-11-01T10:57:57Z,kirikaza,NA https://github.com/rust-lang/rust/pull/78255,MERGED,2020-10-22T23:40:22Z,2020-10-23T12:01:20Z,Reduce diagram mess in 'match arms have incompatible types' error,dtolnay,7ba519ec50cf2c48bae64eead90c3fda9110920b,5,"Rollup merge of #78255 - dtolnay:match r=lcnr Reduce diagram mess in 'match arms have incompatible types' error I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span. This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline. **Before:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |    _________________________- 121 |   |             Transform::Function(t) => {     |  _|_______________________________________- 122 | | |                 filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | | |                     futures::stream::iter(match v { 124 | | |                         Err(e) => { ...   | | 139 | | |                 .compat(); 140 | | |             }     | |_|_____________- this is found to be of type `()` 141 |   |             Transform::Task(t) => t     |  _|___________________________________^ 142 | | |                 .transform(filter_event_type(input_rx  input_type)) 143 | | |                 .forward(output) 144 | | |                 .map(|_| debug!(""Finished"")) 145 | | |                 .compat()      | |_|_________________________^ expected `()`  found struct `futures::compat::Compat01As03` 146 |   |         };     |   |_________- `match` arms have incompatible types     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
**After:** 
 error[E0308]: `match` arms have incompatible types    --> src/topology/builder.rs:141:35     | 120 |             let transform = match transform {     |                             --------------- `match` arms have incompatible types 121 |                 Transform::Function(t) => {     |  _________________________________________- 122 | |                   filter_event_type(input_rx  input_type).compat().flat_map(|v| { 123 | |                       futures::stream::iter(match v { 124 | |                           Err(e) => { ...   | 139 | |                   .compat(); 140 | |               }     | |_______________- this is found to be of type `()` 141 |                 Transform::Task(t) => t     |  _____________________________________^ 142 | |                   .transform(filter_event_type(input_rx  input_type)) 143 | |                   .forward(output) 144 | |                   .map(|_| debug!(""Finished"")) 145 | |                   .compat()      | |___________________________^ expected `()`  found struct `futures::compat::Compat01As03`     |     = note: expected type `()`              found struct `futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = ()  Item = event::Event> + std::marker::Send>  topology::fanout::Fanout>  [closure@src/topology/builder.rs:144:22: 144:44]>>`
FYI @Hoverbear",THUMBS_UP,2020-11-02T02:06:21Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78259,MERGED,2020-10-23T04:31:17Z,2021-01-14T11:28:44Z,Fix #49660 - Adds checks to ensure existence of arithmetic trait implementations,plaflamme,a4f022e1099c712fdcc8555fd10caccb1a631877,3,Auto merge of #78259 - plaflamme:fix-49660 r=KodrAus Fix #49660 - Adds checks to ensure existence of arithmetic trait implementations The first 2 commits fix an issue with the existing `wrapping.rs` tests. It wasn't referred to from the module so the file was being ignored. This is fixed in https://github.com/rust-lang/rust/pull/78259/commits/872dc60ed203d16d43140c1d1623474cf8a9aedc This surfaced a bug in its macro which is fixed in https://github.com/rust-lang/rust/pull/78259/commits/8ddad18283e304753e09ef651209b4a6b54148b0 Lastly commit https://github.com/rust-lang/rust/pull/78259/commits/64d695b753bfe09797b5f95c7b9b72948da01710 is the actual tests for fixing #49660 The following checks are done: * `Add` `Sub` `Mul` `Div` `Rem` * `T op T` `T op &T` `&T op T` and `&T op &T` * for all integer and floating point types * `AddAssign` `SubAssign` `MulAssign` `DivAssign` `RemAssign` * `&mut T op T` and `&mut T op &T` * for all integer and floating point types * `Neg` * `op T` and `op &T` * for all signed integer and floating point types * `Not` * `op T` and `op &T` * for `bool` * `BitAnd` `BitOr` `BitXor` * `T op T` `T op &T` `&T op T` and `&T op &T` * for all integer types and bool * `BitAndAssign` `BitOrAssign` `BitXorAssign` * `&mut T op T` and `&mut T op &T` * for all integer types and bool * `Shl` `Shr` * `L op R` `L op &R` `&L op R` and `&L op &R` * for all pairs of integer types * `ShlAssign` `ShrAssign` * `&mut L op R` `&mut L op &R` * for all pairs of integer types NOTE: I'd like some feedback on improving the macros. I'm not familiar with the idioms and patterns there and composing them has been a challenge for me. [EDIT]: updated links to commits after rebase.,HEART,2020-10-23T19:30:32Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78264,MERGED,2020-10-23T07:15:17Z,2020-10-24T18:21:29Z,Add regression test for issue-77475,JohnTitor,27cb587edcdc38a2e91102dd66f1e5f986a97f99,1,Rollup merge of #78264 - JohnTitor:macro-test r=petrochenkov Add regression test for issue-77475 Closes #77475,HEART,2020-10-23T07:21:23Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78272,MERGED,2020-10-23T10:20:24Z,2020-10-25T00:24:55Z,const_evaluatable_checked: deal with unused nodes + div,lcnr,5ed8ac45d493698c0715ba02a90d7310298a9da0,4,Rollup merge of #78272 - lcnr:abstract-const-unused-node r=oli-obk const_evaluatable_checked: deal with unused nodes + div r? @oli-obk,HEART,2020-10-23T10:21:27Z,oli-obk,NA https://github.com/rust-lang/rust/pull/78274,MERGED,2020-10-23T11:14:51Z,2020-10-24T18:21:28Z,Update description of Empty Enum for accuracy,Enet4,eaa982305d56f1925a74511a64c0802761684b4c,1,Rollup merge of #78274 - Enet4:patch-1 r=jonas-schievink Update description of Empty Enum for accuracy An empty enum is similar to the never type `!` rather than the unit type `()`.,HEART,2020-10-23T19:29:33Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78275,CLOSED,2020-10-23T11:35:21Z,2020-10-28T10:40:16Z,[Draft] Move query definitions into `rustc_query_system`,Julian-Wollersberger,NA,NA,NA,HEART,2020-10-23T11:41:29Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78275,CLOSED,2020-10-23T11:35:21Z,2020-10-28T10:40:16Z,[Draft] Move query definitions into `rustc_query_system`,Julian-Wollersberger,NA,NA,NA,HEART,2020-10-23T14:49:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78275,CLOSED,2020-10-23T11:35:21Z,2020-10-28T10:40:16Z,[Draft] Move query definitions into `rustc_query_system`,Julian-Wollersberger,NA,NA,NA,HEART,2020-10-24T01:06:42Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78275,CLOSED,2020-10-23T11:35:21Z,2020-10-28T10:40:16Z,[Draft] Move query definitions into `rustc_query_system`,Julian-Wollersberger,NA,NA,NA,HEART,2020-10-25T21:26:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78293,MERGED,2020-10-23T17:04:04Z,2020-10-24T18:21:24Z,Always store Rustdoc theme when it's changed,nasso,a07fc3d86508c43476a7721c091482243544bfcf,1,Rollup merge of #78293 - nasso:master r=GuillaumeGomez Always store Rustdoc theme when it's changed `switchTheme` (too) lazily updated the value of `rustdoc-theme` in `localStorage` leading to an incorrect stored value when the system theme is the same as the default (`light`) theme. Fixes #78273,HEART,2020-10-23T17:21:55Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/78293,MERGED,2020-10-23T17:04:04Z,2020-10-24T18:21:24Z,Always store Rustdoc theme when it's changed,nasso,a07fc3d86508c43476a7721c091482243544bfcf,1,Rollup merge of #78293 - nasso:master r=GuillaumeGomez Always store Rustdoc theme when it's changed `switchTheme` (too) lazily updated the value of `rustdoc-theme` in `localStorage` leading to an incorrect stored value when the system theme is the same as the default (`light`) theme. Fixes #78273,HEART,2020-10-24T02:07:21Z,Cldfire,NA https://github.com/rust-lang/rust/pull/78293,MERGED,2020-10-23T17:04:04Z,2020-10-24T18:21:24Z,Always store Rustdoc theme when it's changed,nasso,a07fc3d86508c43476a7721c091482243544bfcf,1,Rollup merge of #78293 - nasso:master r=GuillaumeGomez Always store Rustdoc theme when it's changed `switchTheme` (too) lazily updated the value of `rustdoc-theme` in `localStorage` leading to an incorrect stored value when the system theme is the same as the default (`light`) theme. Fixes #78273,HEART,2020-10-26T23:45:56Z,jhgg,me@jh.gg https://github.com/rust-lang/rust/pull/78298,MERGED,2020-10-23T18:14:34Z,2020-10-27T04:02:16Z,Add test for bad NLL higher-ranked subtype,Aaron1011,9d7db4891bf6a8445b05a50cddb2d45883e2cb41,2,Rollup merge of #78298 - Aaron1011:fix/nll-ranked-test r=Mark-Simulacrum Add test for bad NLL higher-ranked subtype Fixes #57642,HEART,2020-10-23T22:46:54Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78299,CLOSED,2020-10-23T18:58:09Z,2021-01-13T23:41:51Z,Expose Frames Iterator for the Backtrace Type,seanchen1991,NA,NA,NA,THUMBS_UP,2020-10-23T20:21:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78299,CLOSED,2020-10-23T18:58:09Z,2021-01-13T23:41:51Z,Expose Frames Iterator for the Backtrace Type,seanchen1991,NA,NA,NA,EYES,2020-10-24T05:05:56Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/78299,CLOSED,2020-10-23T18:58:09Z,2021-01-13T23:41:51Z,Expose Frames Iterator for the Backtrace Type,seanchen1991,NA,NA,NA,THUMBS_UP,2021-08-01T16:13:02Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78306,CLOSED,2020-10-23T21:16:48Z,2020-10-25T17:28:36Z,Fix inconsistencies in handling of inert attributes on statements,Aaron1011,NA,NA,NA,HEART,2020-10-23T21:45:38Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78307,MERGED,2020-10-23T21:29:23Z,2020-10-24T18:21:20Z,"Revert ""Set .llvmbc and .llvmcmd sections as allocatable""",tmandry,1ac137be93feb476ab14b9d9924c880a53cc3b91,1,"Rollup merge of #78307 - rust-lang:revert-77961-embed-bitcode r=tmandry Revert ""Set .llvmbc and .llvmcmd sections as allocatable"" Reverts rust-lang/rust#77961 see discussion starting from https://github.com/rust-lang/rust/pull/77961#issuecomment-712313902",HEART,2020-10-23T22:02:07Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/78307,MERGED,2020-10-23T21:29:23Z,2020-10-24T18:21:20Z,"Revert ""Set .llvmbc and .llvmcmd sections as allocatable""",tmandry,1ac137be93feb476ab14b9d9924c880a53cc3b91,1,"Rollup merge of #78307 - rust-lang:revert-77961-embed-bitcode r=tmandry Revert ""Set .llvmbc and .llvmcmd sections as allocatable"" Reverts rust-lang/rust#77961 see discussion starting from https://github.com/rust-lang/rust/pull/77961#issuecomment-712313902",HEART,2020-10-23T22:19:27Z,betamos,didrik.nordstrom@gmail.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-10-24T17:46:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-10-24T20:07:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-10-25T09:44:51Z,arora-aman,NA https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-10-27T05:37:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-10-29T05:48:03Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-11-05T16:00:53Z,seeplusplus,caleb@codingthemsoftly.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-12-24T15:43:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-12-24T20:07:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78317,MERGED,2020-10-24T08:54:50Z,2020-12-20T22:52:04Z,Turn quadratic time on number of impl blocks into linear time,est31,c609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9,5,Auto merge of #78317 - est31:linear_in_impl_count r=matthewjasper Turn quadratic time on number of impl blocks into linear time Previously if you had a lot of inherent impl blocks on a type like: ```Rust struct Foo; impl Foo { fn foo_1() {} } // ... impl Foo { fn foo_100_000() {} } ``` The compiler would be very slow at processing it because an internal algorithm would run in O(n^2) where n is the number of impl blocks. Now we add a new algorithm that allocates but is faster asymptotically. Comparing rustc nightly with a local build of rustc as of this PR (results in seconds): | N | real time before | real time after | | - | - | - | | 4_000 | 0.57 | 0.46 | | 8_000 | 1.31 | 0.84 | | 16_000 | 3.56 | 1.69 | | 32_000 | 10.60 | 3.73 | I've tuned up the numbers to make the effect larger than the startup noise of rustc but the asymptotic difference should hold for smaller n as well. Note: current state of the PR omits error messages if there are other errors present already. For now I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!,HEART,2020-12-25T23:33:24Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/78318,MERGED,2020-10-24T09:55:44Z,2020-10-25T00:24:49Z,TyCtxt: generate single impl block with `slice_interners` macro,bugadani,a8ff5a4e03a4f0fc7cb87bc3fdb4a1e0144e6e73,1,Rollup merge of #78318 - bugadani:tyctx-impl r=petrochenkov TyCtxt: generate single impl block with `slice_interners` macro Reduces the work needed to check overlapping impls a bit.,THUMBS_UP,2020-10-24T12:15:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/78320,MERGED,2020-10-24T12:31:24Z,2020-10-25T14:17:34Z,Link to cargo's `build-std` feature instead of `xargo` in custom target docs,phil-opp,63e48cd4100619550af142471543f1969bfeb8c0,1,Rollup merge of #78320 - phil-opp:patch-5 r=GuillaumeGomez alexcrichton Link to cargo's `build-std` feature instead of `xargo` in custom target docs The `xargo` tool is in maintenance mode since 2018 and the `build-std` feature of cargo already works reasonably well for most use cases.,THUMBS_UP,2020-10-24T23:05:44Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/78335,CLOSED,2020-10-24T21:01:11Z,2020-10-25T22:01:08Z,Formally deprecate the constants superseded by RFC 2700,bstrie,NA,NA,NA,HOORAY,2020-10-24T22:15:01Z,faern,NA https://github.com/rust-lang/rust/pull/78335,CLOSED,2020-10-24T21:01:11Z,2020-10-25T22:01:08Z,Formally deprecate the constants superseded by RFC 2700,bstrie,NA,NA,NA,HOORAY,2020-10-25T00:08:19Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/78335,CLOSED,2020-10-24T21:01:11Z,2020-10-25T22:01:08Z,Formally deprecate the constants superseded by RFC 2700,bstrie,NA,NA,NA,HOORAY,2020-10-25T17:31:02Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78338,CLOSED,2020-10-24T23:18:53Z,2020-11-20T22:08:33Z,[EXPERIMENT] Forbid derive attributes on invalid targets,Aaron1011,NA,NA,NA,THUMBS_UP,2020-10-25T01:45:26Z,estebank,NA https://github.com/rust-lang/rust/pull/78343,MERGED,2020-10-25T01:40:16Z,2020-11-24T00:30:29Z,Qualify `panic!` as `core::panic!` in non-built-in `core` macros,camelid,f32a0cce2fd5aaf5f361192af59cf1f2afa5f0ac,16,Auto merge of #78343 - camelid:macros-qualify-panic r=m-ou-se Qualify `panic!` as `core::panic!` in non-built-in `core` macros Fixes #78333. ----- Otherwise code like this #![no_implicit_prelude] fn main() { ::std::todo!(); ::std::unimplemented!(); } will fail to compile which is unfortunate and presumably unintended. This changes many invocations of `panic!` in a `macro_rules!` definition to invocations of `$crate::panic!` which makes the invocations hygienic. Note that this does not make the built-in macro `assert!` hygienic.,HEART,2020-11-27T07:50:12Z,phlopsi,NA https://github.com/rust-lang/rust/pull/78345,MERGED,2020-10-25T06:41:50Z,2020-11-09T02:58:39Z,Fix handling of item names for HIR,jyn514,12c5f786ea2a754000f3947895c22adda480a1c1,3,Rollup merge of #78345 - jyn514:proper-names r=varkor Fix handling of item names for HIR - Handle variants fields macros in `Node::ident()` - Handle the crate root in `opt_item_name` - Rewrite `item_name` in terms of `opt_item_name` I need this for both https://github.com/rust-lang/rust/pull/77820 and https://github.com/rust-lang/rust/pull/78082 so splitting it out into a separate PR so it can land early.,HEART,2020-10-25T07:45:41Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78361,MERGED,2020-10-25T16:16:05Z,2020-11-18T20:36:44Z,Updated the list of white-listed target features for x86,DevJPM,c7e9029b8064a48a983040937bae056617729980,3,Rollup merge of #78361 - DevJPM:master r=workingjubilee Updated the list of white-listed target features for x86 This PR both adds in-source documentation on what to look out for when adding a new (X86) feature set and [adds all that are detectable at run-time in Rust stable as of 1.27.0](https://github.com/rust-lang/stdarch/blob/master/crates/std_detect/src/detect/arch/x86.rs). This should only enable the use of the corresponding LLVM intrinsics. Actual intrinsics need to be added separately in rust-lang/stdarch. It also re-orders the run-time-detect test statements to be more consistent with the actual list of intrinsics whitelisted and removes underscores not present in the actual names (which might be mistaken as being part of the name) The reference for LLVM's feature names used is [this file](https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/X86TargetParser.def). This PR was motivated as the compiler end's part for allowing #67329 to be adressed over on rust-lang/stdarch,THUMBS_UP,2020-11-08T02:25:56Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-25T19:21:24Z,ehuss,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-25T20:23:58Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-25T21:22:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-26T00:38:30Z,camelid,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-26T08:38:03Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2020-10-26T08:38:07Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-26T19:02:47Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2020-10-28T16:20:50Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-28T16:20:52Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-10-29T16:30:07Z,flosse,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-11-16T09:38:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-11-16T12:38:07Z,smmalis37,NA https://github.com/rust-lang/rust/pull/78364,MERGED,2020-10-25T17:11:45Z,2020-11-17T01:15:01Z,Update RELEASES.md for 1.48.0,XAMPPRocky,c75f21008de0679d15ee412043dacd14cee0cdb4,1,Rollup merge of #78364 - XAMPPRocky:relnote-1.48.0 r=pietroalbini Update RELEASES.md for 1.48.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnote-1.48.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2020-12-24T03:01:23Z,xilec,NA https://github.com/rust-lang/rust/pull/78367,CLOSED,2020-10-25T17:28:26Z,2020-12-17T18:16:04Z,Apply `unused_doc_comments` lint to inner items,Aaron1011,NA,NA,NA,THUMBS_UP,2020-12-07T11:36:04Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78367,CLOSED,2020-10-25T17:28:26Z,2020-12-17T18:16:04Z,Apply `unused_doc_comments` lint to inner items,Aaron1011,NA,NA,NA,THUMBS_UP,2020-12-10T14:30:21Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78370,CLOSED,2020-10-25T19:26:14Z,2021-03-29T15:24:09Z,Add get_pin_ref and get_pin_mut methods to slice,taiki-e,NA,NA,NA,THUMBS_UP,2020-11-21T16:40:06Z,sfackler,NA https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HOORAY,2020-10-25T21:26:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HOORAY,2020-10-26T09:28:14Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HOORAY,2020-10-26T12:23:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HEART,2020-11-30T21:05:05Z,tmiasko,NA https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HEART,2020-12-05T11:23:46Z,RalfJung,NA https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HOORAY,2020-12-06T12:44:39Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/78373,MERGED,2020-10-25T20:58:32Z,2020-12-05T15:57:53Z,Don't leak return value after panic in drop,matthewjasper,9122b769c8306b1cb3c8d1f96fca3ea3e208e22e,32,Auto merge of #78373 - matthewjasper:drop-on-into r=pnkfelix Don't leak return value after panic in drop Closes #47949,HOORAY,2020-12-10T06:47:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78380,MERGED,2020-10-25T22:36:05Z,2020-11-29T16:39:25Z,Update tests to remove old numeric constants,bstrie,af780e569d6581a7ba2fb56f7cbbbff5a1d6b895,106,Auto merge of #78380 - bstrie:rm-old-num-const-from-tests r=jyn514 Update tests to remove old numeric constants Part of #68490. Care has been taken to leave the old consts where appropriate for testing backcompat regressions module shadowing etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64 which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros. For places which have legitimate uses of the old consts deprecated attributes have been optimistically inserted. Although currently unnecessary they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.,THUMBS_UP,2020-10-25T22:41:11Z,faern,NA https://github.com/rust-lang/rust/pull/78399,MERGED,2020-10-26T13:39:21Z,2020-12-16T00:47:55Z,make MIR graphviz generation use gsgdt,vn-ki,4031f7b0a8047653f2f989f2d8579bf5650e71ca,7,Auto merge of #78399 - vn-ki:gsgdt-graphviz r=oli-obk make MIR graphviz generation use gsgdt gsgdt [https://crates.io/crates/gsgdt] is a crate which provides an interface for stringly typed graphs. It also provides generation of graphviz dot format from said graph. This is the first in a series of PRs on moving graphviz code out of rustc into normal crates and then implementating graph diffing on top of these crates. r? `@oli-obk`,EYES,2020-10-26T14:35:02Z,tesuji,NA https://github.com/rust-lang/rust/pull/78400,MERGED,2020-10-26T14:12:39Z,2020-11-03T09:18:54Z,Fix unindent in doc comments,GuillaumeGomez,e731a5a7f55b77e75573068d788ce61033b9bb62,4,Rollup merge of #78400 - GuillaumeGomez:fix-unindent r=jyn514 Fix unindent in doc comments Fixes #70732 r? ``@jyn514``,HEART,2020-11-03T10:51:21Z,Luro02,NA https://github.com/rust-lang/rust/pull/78400,MERGED,2020-10-26T14:12:39Z,2020-11-03T09:18:54Z,Fix unindent in doc comments,GuillaumeGomez,e731a5a7f55b77e75573068d788ce61033b9bb62,4,Rollup merge of #78400 - GuillaumeGomez:fix-unindent r=jyn514 Fix unindent in doc comments Fixes #70732 r? ``@jyn514``,HEART,2020-11-17T01:45:52Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78401,MERGED,2020-10-26T14:59:18Z,2020-10-28T03:58:42Z,resolve: private fields in tuple struct ctor diag,davidtwco,c9279c845d58db9b78e41d07de8436ab22839679,13,Rollup merge of #78401 - davidtwco:issue-75906-tuple-construct-private-field r=estebank resolve: private fields in tuple struct ctor diag Fixes #75906. This PR improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. r? @estebank,HEART,2020-10-26T17:16:31Z,estebank,NA https://github.com/rust-lang/rust/pull/78401,MERGED,2020-10-26T14:59:18Z,2020-10-28T03:58:42Z,resolve: private fields in tuple struct ctor diag,davidtwco,c9279c845d58db9b78e41d07de8436ab22839679,13,Rollup merge of #78401 - davidtwco:issue-75906-tuple-construct-private-field r=estebank resolve: private fields in tuple struct ctor diag Fixes #75906. This PR improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. r? @estebank,HEART,2020-10-28T11:58:36Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/78401,MERGED,2020-10-26T14:59:18Z,2020-10-28T03:58:42Z,resolve: private fields in tuple struct ctor diag,davidtwco,c9279c845d58db9b78e41d07de8436ab22839679,13,Rollup merge of #78401 - davidtwco:issue-75906-tuple-construct-private-field r=estebank resolve: private fields in tuple struct ctor diag Fixes #75906. This PR improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. r? @estebank,HEART,2020-12-16T13:56:38Z,nicmue,nicomuerdter@gmail.com https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,THUMBS_UP,2020-10-29T05:12:01Z,aramperes,aram.peres@wavy.fm https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,HOORAY,2020-11-08T14:23:55Z,trevyn,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,THUMBS_UP,2020-11-08T14:23:58Z,trevyn,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,THUMBS_UP,2020-11-08T16:02:42Z,kpp,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,HEART,2020-11-08T16:02:44Z,kpp,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,THUMBS_UP,2020-11-12T07:00:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,HEART,2020-11-12T15:41:36Z,spearsandshields,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,THUMBS_UP,2020-11-19T20:36:56Z,gliderkite,NA https://github.com/rust-lang/rust/pull/78410,MERGED,2020-10-26T19:57:01Z,2020-11-08T13:49:54Z,revert #75443 update mir validator,lcnr,87a0997ef9c0bfad0ba362741afa601d8fb285b8,4,Auto merge of #78410 - lcnr:revert75443 r=nikomatsakis revert #75443 update mir validator This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313. Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE. Note that rust-lang#72793 was also fixed by rust-lang#75443 but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue. rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions but I hope that this is a purely theoretical concern. See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this. r? `@nikomatsakis` `@eddyb` `@RalfJung`,HOORAY,2020-11-19T21:08:29Z,DrLuke,NA https://github.com/rust-lang/rust/pull/78414,MERGED,2020-10-26T21:21:46Z,2020-10-28T20:04:19Z,Implement -Z function-sections=yes|no,nox,3dddf6ac1e194deb3d927064e7c6d50bc9325dd0,3,Auto merge of #78414 - nox:function-sections r=nagisa bjorn3 Implement -Z function-sections=yes|no This lets rustc users tweak whether all functions should be put in their own TEXT section using whatever default value the target defines if the flag is missing. I'm having fun experimenting with musl libc and trying to implement the start symbol in Rust that means avoiding code that requires relocations and AFAIK putting everything in its own section makes the toolchain generate `GOTPCREL` relocations for symbols that could use plain old PC-relative addressing (at least on `x86_64`) if they were all in the same section.,THUMBS_UP,2020-10-27T08:19:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78429,MERGED,2020-10-27T02:26:50Z,2021-02-26T02:58:25Z,[librustdoc] Only split lang string on ` ` ` ` and `\t`,casey,d95d30486180387a875b14633aea4e4dd8f960da,6,"Auto merge of #78429 - casey:doctest-attribute-splitting r=jyn514 [librustdoc] Only split lang string on ` ` ` ` and `\t` Split markdown lang strings into tokens on ` `. The previous behavior was to split lang strings into tokens on any character that wasn't a `_` `_` or alphanumeric. This is a potentially breaking change so please scrutinize! See discussion in #78344. I noticed some test cases that made me wonder if there might have been some reason for the original behavior: ``` t(""{.no_run .example}"" false true Ignore::None true false false false v() None); t(""{.sh .should_panic}"" true false Ignore::None false false false false v() None); t(""{.example .rust}"" false false Ignore::None true false false false v() None); t(""{.test_harness .rust}"" false false Ignore::None true true false false v() None); ``` It seemed pretty peculiar to specifically test lang strings in braces with all the tokens prefixed by `.`. I did some digging and it looks like the test cases were added way back in [this commit from 2014](https://github.com/rust-lang/rust/commit/3fef7a74ca9a) by `@skade.` It looks like they were added just to make sure that the splitting was permissive and aren't testing that those strings in particular are accepted. Closes https://github.com/rust-lang/rust/issues/78344.",HEART,2020-11-28T01:51:11Z,camelid,NA https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-10-27T14:43:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-10-27T17:17:49Z,varkor,NA https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-10-27T22:51:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-10-29T12:28:47Z,tesuji,NA https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-11-06T14:23:46Z,djc,NA https://github.com/rust-lang/rust/pull/78430,MERGED,2020-10-27T03:31:47Z,2020-10-29T03:58:04Z,Clarify main code paths in exhaustiveness checking,Nadrieril,f9187adaef2005b903f666bf323ac675cadf8407,4,Auto merge of #78430 - Nadrieril:taking-constructors-seriously2 r=varkor Clarify main code paths in exhaustiveness checking This PR massively clarifies the main code paths of exhaustiveness checking by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year but the complexity of matching consts had prevented me. Behold a massive simplification :D. This in particular removes a fair amount of duplication between various parts localizes code into methods of relevant types when applicable makes some implicit assumptions explicit and overall improves legibility a lot (or so I hope). Additionally after my changes undoing #76918 turned out to be a noticeable perf gain. As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented but I tend to forget how complex this file is; I'm happy to clarify things as needed. My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-11-06T18:47:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78434,MERGED,2020-10-27T10:00:21Z,2020-10-27T16:00:19Z,"Disable ""optimization to avoid load of address"" in InstCombine",jonas-schievink,2a71e45411881dda12a704d7491428d8a23347c0,5,"Auto merge of #78434 - jonas-schievink:disable-miropt r=wesleywiser Disable ""optimization to avoid load of address"" in InstCombine Same as #78195 fixes https://github.com/rust-lang/rust/issues/78192 (again).",THUMBS_UP,2020-10-27T10:10:57Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,ROCKET,2020-10-27T23:40:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,ROCKET,2020-10-28T00:14:42Z,est31,NA https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,ROCKET,2020-10-28T11:10:27Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,THUMBS_UP,2020-10-28T15:46:59Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,ROCKET,2020-11-06T06:37:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,THUMBS_UP,2020-11-06T06:37:25Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78448,MERGED,2020-10-27T16:45:44Z,2020-11-03T06:57:13Z,foreign_modules query hash table lookups,rylev,7b5a9e9cd27f01311b5e19cefa1fb574d086d3da,7,Auto merge of #78448 - rylev:cache-foreign_modules r=wesleywiser foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.,ROCKET,2020-11-06T18:45:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78455,MERGED,2020-10-27T23:26:44Z,2021-01-16T23:15:45Z,Introduce {Ref RefMut}::try_map for optional projections in RefCell,udoprog,6bb06f4f2387e2369d98cf87d79b772f99ae979f,1,Rollup merge of #78455 - udoprog:refcell-opt-map r=KodrAus Introduce {Ref RefMut}::try_map for optional projections in RefCell This fills a usability gap of `RefCell` I've personally encountered to perform optional projections mostly into collections such as `RefCell>` or `RefCell>`: > This kind of API was briefly featured under Open questions in #10514 back in 2013 (!) ```rust let values = RefCell::new(vec![1 2 3 4]); let b = Ref::opt_map(values.borrow() |vec| vec.get(2)); ``` It primarily avoids this alternative approach to accomplish the same kind of projection which is both rather noisy and panicky: ```rust let values = RefCell::new(vec![1 2 3 4]); let b = if values.get(2).is_some() { Some(Ref::map(values.borrow() |vec| vec.get(2).unwrap())) } else { None }; ``` ### Open questions The naming `opt_map` is preliminary. I'm not aware of prior art in std to lean on here but this name should probably be improved if this functionality is desirable. Since `opt_map` consumes the guard and alternative syntax might be more appropriate which instead *tries* to perform the projection allowing the original borrow to be recovered in case it fails: ```rust pub fn try_map(orig: Ref<'b T> f: F) -> Result Self> where F: FnOnce(&T) -> Option<&U>; ``` This would be more in line with the `try_map` method [provided by parking lot](https://docs.rs/lock_api/0/lock_api/struct.RwLockWriteGuard.html#method.try_map).,EYES,2020-10-27T23:40:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-28T01:43:28Z,est31,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-28T06:20:43Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-28T08:04:18Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-28T20:10:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-29T00:05:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-29T00:05:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-29T05:41:37Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-10-29T07:10:34Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-01T17:28:37Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-08T19:19:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-16T14:23:39Z,lqd,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-16T17:56:24Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-18T21:59:57Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T02:04:44Z,yerke,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T03:43:03Z,imranmaj,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T03:50:40Z,jbit,jbit@jbit.net https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T05:54:49Z,Inphi,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T05:55:53Z,caelunshun,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T07:42:15Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T08:11:20Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T08:24:29Z,sirgl,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T08:38:32Z,joshuajbouw,joshua@aurora.dev https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T08:45:12Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T09:04:22Z,weihanglo,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T09:28:03Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T09:36:05Z,kpp,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T09:55:23Z,jD91mZM2,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T09:58:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T10:12:38Z,gliderkite,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T10:12:59Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T11:56:54Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HEART,2020-11-22T12:10:34Z,berkus,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T12:26:29Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HEART,2020-11-22T12:26:29Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T14:25:51Z,brainplot,gianluca.recchia@protonmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T16:08:15Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HEART,2020-11-22T16:08:17Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,THUMBS_UP,2020-11-22T16:08:19Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T17:14:16Z,DianaNites,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T18:24:26Z,tux3,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T19:41:10Z,NeverGivinUp,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-22T23:07:55Z,dicej,joel.dice@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-23T00:49:28Z,cab,conner@amps.io https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-23T14:01:33Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,CONFUSED,2020-11-26T03:31:47Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-26T15:46:03Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-26T16:58:03Z,robatipoor,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,THUMBS_UP,2020-11-26T16:58:05Z,robatipoor,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-27T10:27:42Z,rrbutani,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-11-30T09:17:53Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2020-12-03T11:31:17Z,95th,NA https://github.com/rust-lang/rust/pull/78461,MERGED,2020-10-28T01:06:08Z,2020-11-22T01:09:04Z,Add support for custom allocators in `Vec`,TimDiekmann,a1a13b2bc4fa6370b9501135d97c5fe0bc401894,13,Auto merge of #78461 - TimDiekmann:vec-alloc r=Amanieu Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate,HOORAY,2021-06-21T22:45:39Z,DzmitryFil,NA https://github.com/rust-lang/rust/pull/78462,MERGED,2020-10-28T01:11:59Z,2020-10-30T00:28:43Z,Use unwrapDIPtr because the Scope may be null.,danielframpton,38c34098b10a6311b63db96c3542664843232148,1,Rollup merge of #78462 - danielframpton:fixnullisa r=nagisa Use unwrapDIPtr because the Scope may be null. I ran into an assertion when using debug information on Windows with LLVM assertions enabled. It seems like we are using unwrap here (which in turn calls isa and requires the pointer to be non-null) but we expect the value to be null because that is what we are passing from rustc. This change uses unwrapDIPtr which explicitly allows nullptr. The FFI prototype for this method on the rust side has the `LLVMMetadataRef` parameter as `Scope: Option<&'a DIScope>` and we always pass `None` when `msvc_like_names` is true.,THUMBS_UP,2020-10-28T01:26:27Z,arlosi,arsiem@microsoft.com https://github.com/rust-lang/rust/pull/78480,MERGED,2020-10-28T11:11:41Z,2020-11-10T13:25:13Z,BTreeMap: fix pointer provenance rules,ssomers,2187f3c7f2a1bf1d6e4f9a1e634a887f9118532d,3,Rollup merge of #78480 - ssomers:btree-alias r=Mark-Simulacrum BTreeMap: fix pointer provenance rules Fixes #78477 and includes #78476 r? `@Mark-Simulacrum`,HEART,2020-10-28T11:28:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/78489,MERGED,2020-10-28T16:25:15Z,2020-11-03T13:46:35Z,Minor cleanup around incremental compilation,bugadani,8e8939b8045b7af6076fb718e2e298844aaf4650,5,Auto merge of #78489 - bugadani:array r=estebank Minor cleanup around incremental compilation * Remove some short lived vectors * Fix some typos * Avoid some reallocations,THUMBS_UP,2020-10-28T16:44:41Z,estebank,NA https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,EYES,2020-10-29T01:48:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-10-29T02:17:14Z,Welziewagers2015,NA https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-10-29T09:17:00Z,rylev,NA https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-10-29T10:46:40Z,est31,NA https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-10-29T11:07:22Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-10-29T15:18:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78508,MERGED,2020-10-29T01:22:15Z,2020-10-29T20:56:29Z,[resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path,wesleywiser,6bdae9edd0cc099daa6038bca469dc09b6fc078a,1,Auto merge of #78508 - wesleywiser:optimize_visit_scopes r=petrochenkov [resolve] Use `unwrap_or_else` instead of `unwrap_or` in a hot path This improves the performance of the `resolve_crate` function by 30% for a very large single file crate with auto-generated C bindings. cc `@rylev`,ROCKET,2020-11-06T18:44:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T10:02:29Z,jplatte,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T12:18:57Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T12:22:47Z,canadaduane,duane.johnson@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T13:41:16Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T16:02:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-29T20:29:19Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2020-10-30T06:06:16Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-03-19T06:20:21Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-04-13T08:56:12Z,r00ster91,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-04-22T16:44:58Z,ricvelozo,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-06-30T14:11:12Z,bestouff,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-07-05T20:12:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2021-09-13T14:26:28Z,cole-miller,NA https://github.com/rust-lang/rust/pull/78515,OPEN,2020-10-29T04:23:48Z,NA,Switchable buffering for Stdout,Lucretiel,NA,NA,NA,HEART,2022-01-29T03:05:03Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/78534,CLOSED,2020-10-29T17:51:24Z,2020-12-14T10:05:23Z,Try to reuse temp vectors in arena,bugadani,NA,NA,NA,HEART,2020-10-30T03:13:27Z,est31,NA https://github.com/rust-lang/rust/pull/78535,CLOSED,2020-10-29T17:57:08Z,2020-11-10T20:42:28Z,[Experiment] Crater run with deny(panic_fmt),m-ou-se,NA,NA,NA,THUMBS_UP,2020-10-29T19:09:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78545,MERGED,2020-10-29T22:48:01Z,2020-10-30T12:47:01Z,Make anonymous binders start at 0,jackh726,05f80f03a973471cd1f7470d5f496db0541791f6,12,Rollup merge of #78545 - jackh726:anonymous r=oli-obk Make anonymous binders start at 0 A few changes to some test outputs but these actually look *more* correct to me.,THUMBS_UP,2020-10-30T08:54:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78550,MERGED,2020-10-30T01:25:03Z,2020-10-31T19:32:50Z,x.py setup: Create config.toml in the current directory not the top-level directory,jyn514,c0f356d28fb2ea1712ee3b5b8cd4918933e3860e,1,Rollup merge of #78550 - jyn514:setup r=Mark-Simulacrum x.py setup: Create config.toml in the current directory not the top-level directory See https://github.com/rust-lang/rust/issues/78509 for discussion. r? @pnkfelix cc @cuviper @Mark-Simulacrum,THUMBS_UP,2020-10-30T01:57:07Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-10-30T17:15:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-10-30T20:41:38Z,Keruspe,NA https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-10-31T20:09:34Z,pmarks,pmarks@gmail.com https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-09T13:52:52Z,g2p,NA https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-09T16:15:06Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-09T18:03:17Z,tux3,NA https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-09T23:47:19Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-10T00:18:58Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-10T00:53:51Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,HEART,2020-11-10T00:53:53Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-10T03:32:41Z,BudiNverse,me@inve.rs https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-11-20T08:30:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,THUMBS_UP,2020-12-16T18:48:35Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/78566,MERGED,2020-10-30T10:41:19Z,2020-11-10T13:25:07Z,Enable LLVM Polly via llvm-args.,JRF63,7ac079f047ad9857a32593bc7607115183d13560,3,Rollup merge of #78566 - JRF63:polly r=Mark-Simulacrum Enable LLVM Polly via llvm-args. I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them. ![results](https://user-images.githubusercontent.com/7283601/97695555-338f7180-1adf-11eb-82bd-5130e0e6fa89.png) [Benchmark](https://gist.github.com/JRF63/9a6268b91720958e90dbe7abffe20298) I noticed that `-lto` seems to interfere with polly in this specific microbenchmark as enabling it causes the perf to drop to that of non-polly builds. Other related PRs: #75615,HEART,2021-03-05T10:10:14Z,Corallus-Caninus,NA https://github.com/rust-lang/rust/pull/78569,MERGED,2020-10-30T12:06:03Z,2020-11-21T01:30:35Z,Arena: use specialization to avoid copying data,bugadani,432d116a5c2565774bae4c42fcacab8b685608b5,1,Auto merge of #78569 - bugadani:arena-spec r=Mark-Simulacrum Arena: use specialization to avoid copying data In several cases a `Vec` or `SmallVec` is passed to `Arena::alloc_from_iter` directly. This PR makes sure those cases don't copy their data unnecessarily by specializing the `alloc_from_iter` implementation.,HEART,2020-10-30T12:48:58Z,est31,NA https://github.com/rust-lang/rust/pull/78576,CLOSED,2020-10-30T15:31:26Z,2020-10-31T00:11:06Z,refactor: Implement RawVec::grow_amortized in terms of grow_exact,Marwes,NA,NA,NA,HEART,2020-10-30T15:41:00Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78588,MERGED,2020-10-31T00:44:09Z,2020-11-21T03:57:56Z,Reworks Sccc computation to iteration instead of recursion,HeroicKatora,8cfa7b4ec9d314a412f79c1748bd2dfa7575b2e3,2,Auto merge of #78588 - HeroicKatora:sccc r=nikomatsakis Reworks Sccc computation to iteration instead of recursion Linear graphs producing as many scc's as nodes would recurse once for every node when entered from the start of the list. This adds a test that exhausted the stack at least on my machine with error: ``` thread 'graph::scc::tests::test_deep_linear' has overflowed its stack fatal runtime error: stack overflow ``` This may or may not be connected to #78567. I was only reminded that I started this rework some time ago. It might be plausible as borrow checking a long function with many borrow regions around each other—((((((…))))))— may produce the linear list setup to trigger this stack overflow ? I don't know enough about borrow check to say for sure. This is best read in two separate commits. The first addresses only `find_state` internally. This is classical union phase from union-find. There's also a common solution of using the parent pointers in the (virtual) linked list to track the backreferences while traversing upwards and then following them backwards in a second path compression phase. The second is more involved as it rewrites the mutually recursive `walk_node` and `walk_unvisited_node`. Firstly the caller is required to handle the unvisited case of `walk_node` so a new `start_walk_from` method is added to handle that by walking the unvisited node if necessary. Then `walk_unvisited_node` where we would previously recurse into in the missing case is rewritten to construct a manual stack of its frames. The state fields consist of the previous stack slots.,HEART,2020-11-07T01:15:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78599,MERGED,2020-10-31T14:07:52Z,2020-11-01T14:37:10Z,Add note to process::arg[s] that args shouldn't be escaped or quoted,panstromek,f281a76f838161a5e95fd0bba82847feb0a29435,1,"Rollup merge of #78599 - panstromek:master r=m-ou-se Add note to process::arg[s] that args shouldn't be escaped or quoted This came out of discussion on [forum](https://users.rust-lang.org/t/how-to-get-full-output-from-command/50626) where I recently asked a question and it turned out that the problem was redundant quotation: ```rust Command::new(""rg"") .arg(""\""pattern\"""") // this will look for ""pattern"" with quotes included ``` This is something that has bitten me few times already (in multiple languages actually) so It'd be grateful to have it in the docs even though it's not sctrictly Rust specific problem. Other users also agreed. This can be really annoying to debug because in many cases (inluding mine) quotes can be legal part of the argument so the command doesn't fail it just behaves unexpectedly. Not everybody (including me) knows that quotes around arguments are part of the shell and not part of the called program. Coincidentally somoene had the same problem [yesterday](https://www.reddit.com/r/rust/comments/jkxelc/going_crazy_over_running_a_curl_process_from_rust/) on reddit. I am not a native speaker so I welcome any corrections or better formulation I don't expect this to be merged as is. I was also reminded that this is platform/shell specific behaviour but I didn't find a good way to formulate that briefly any ideas welcome. It's also my first PR here so I am not sure I did everything correctly I did this just from Github UI.",HEART,2020-10-31T17:28:03Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/78599,MERGED,2020-10-31T14:07:52Z,2020-11-01T14:37:10Z,Add note to process::arg[s] that args shouldn't be escaped or quoted,panstromek,f281a76f838161a5e95fd0bba82847feb0a29435,1,"Rollup merge of #78599 - panstromek:master r=m-ou-se Add note to process::arg[s] that args shouldn't be escaped or quoted This came out of discussion on [forum](https://users.rust-lang.org/t/how-to-get-full-output-from-command/50626) where I recently asked a question and it turned out that the problem was redundant quotation: ```rust Command::new(""rg"") .arg(""\""pattern\"""") // this will look for ""pattern"" with quotes included ``` This is something that has bitten me few times already (in multiple languages actually) so It'd be grateful to have it in the docs even though it's not sctrictly Rust specific problem. Other users also agreed. This can be really annoying to debug because in many cases (inluding mine) quotes can be legal part of the argument so the command doesn't fail it just behaves unexpectedly. Not everybody (including me) knows that quotes around arguments are part of the shell and not part of the called program. Coincidentally somoene had the same problem [yesterday](https://www.reddit.com/r/rust/comments/jkxelc/going_crazy_over_running_a_curl_process_from_rust/) on reddit. I am not a native speaker so I welcome any corrections or better formulation I don't expect this to be merged as is. I was also reminded that this is platform/shell specific behaviour but I didn't find a good way to formulate that briefly any ideas welcome. It's also my first PR here so I am not sure I did everything correctly I did this just from Github UI.",HEART,2021-12-26T01:06:19Z,kalradivyanshu,NA https://github.com/rust-lang/rust/pull/78608,MERGED,2020-10-31T18:12:40Z,2020-11-23T02:25:13Z,Stabilize refcell_take,ThinkChaos,b249844c33f5327cbba7a13d34eaaf290f0ec776,2,Rollup merge of #78608 - ThinkChaos:stabilize_refcell_take r=m-ou-se Stabilize refcell_take Tracking Issue: #71395 ``@KodrAus`` nominated this for FCP so here's a PR! I've never made a stabilization PR so please mention if there's anything I can improve thanks.,THUMBS_UP,2020-11-09T13:16:40Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78616,MERGED,2020-10-31T23:42:34Z,2020-11-03T09:18:37Z,Document -Zinstrument-coverage,richkadel,416dd6757b42089d63e3f2899adfcfe1e25bd0fd,2,Rollup merge of #78616 - richkadel:unstable-book-instr-cov r=tmandry Document -Zinstrument-coverage r? ``@tmandry`` FYI ``@wesleywiser`` Here is my proposed document for LLVM source-based code coverage. I based it on the `profile.md` page in the same directory and on the Clang guide for LLVM source-based coverage.,HEART,2020-11-02T09:31:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78616,MERGED,2020-10-31T23:42:34Z,2020-11-03T09:18:37Z,Document -Zinstrument-coverage,richkadel,416dd6757b42089d63e3f2899adfcfe1e25bd0fd,2,Rollup merge of #78616 - richkadel:unstable-book-instr-cov r=tmandry Document -Zinstrument-coverage r? ``@tmandry`` FYI ``@wesleywiser`` Here is my proposed document for LLVM source-based code coverage. I based it on the `profile.md` page in the same directory and on the Clang guide for LLVM source-based coverage.,HEART,2020-11-02T20:17:47Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T01:17:47Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T02:38:26Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T05:17:43Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2020-11-01T07:36:28Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T09:45:26Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T15:46:12Z,kw-fn,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2020-11-01T15:46:43Z,kw-fn,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2020-11-01T15:46:48Z,kw-fn,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T15:52:05Z,tavianator,tavianator@tavianator.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T21:24:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2020-11-01T22:47:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2020-11-01T22:47:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-01T22:47:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-02T15:42:49Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2020-11-02T15:42:52Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2020-11-08T19:12:51Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2020-11-12T20:00:30Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-18T02:02:01Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-03-18T02:02:02Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2021-03-18T02:02:02Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HOORAY,2021-03-18T02:02:06Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",EYES,2021-03-18T02:02:08Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-18T21:10:00Z,richli,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-03-19T00:58:22Z,tux3,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-19T02:27:29Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-20T06:14:02Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-25T06:45:48Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-03-27T13:43:34Z,Urgau,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2021-03-27T13:44:29Z,bluss,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-03-27T15:57:40Z,sthagen,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-04-06T14:32:02Z,Bond-009,bond.009@outlook.com https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-06-17T15:42:43Z,zohnannor,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HOORAY,2021-06-17T15:42:43Z,zohnannor,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",ROCKET,2021-06-17T15:42:43Z,zohnannor,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",EYES,2021-06-17T15:42:44Z,zohnannor,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-06-17T15:42:45Z,zohnannor,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",HEART,2021-11-08T10:30:10Z,iago-lito,NA https://github.com/rust-lang/rust/pull/78618,MERGED,2020-11-01T01:00:17Z,2021-03-27T13:25:21Z,Add IEEE 754 compliant fmt/parse of -0 infinity NaN,workingjubilee,aef11409b43a533f4e59ffb9b0efcb619c6e6879,10,"Auto merge of #78618 - workingjubilee:ieee754-fmt r=m-ou-se Add IEEE 754 compliant fmt/parse of -0 infinity NaN This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values namely signed zero the infinities and NaN. It also adds IEEE 754 compliance tests that while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks. This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074 and closes #24623. The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers i.e. not the extended reals (where floats live) IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition the vast majority of other programming languages not only output `-0` but output `-0.0` here. While IEEE 754 offers a broad leeway in how to handle producing what it calls a ""decimal character sequence"" it is clear that the operations a language provides should be capable of round tripping and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character but it prints ""+0"" instead if given such (which was what led to the opening of #24623). There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard as well as other well-documented challenges on the arithmetic level but I hope that this can be the beginning of motion towards solving those challenges.",THUMBS_UP,2021-11-08T10:30:11Z,iago-lito,NA https://github.com/rust-lang/rust/pull/78626,MERGED,2020-11-01T12:14:27Z,2020-11-03T21:18:45Z,Improve errors about #[deprecated] attribute,m-ou-se,f0112928cb13dbf8936c79d31badf3b684bdda10,8,"Rollup merge of #78626 - fusion-engineering-forks:deprecated-trait-impl r=estebank Improve errors about #[deprecated] attribute This change: 1. Turns `#[deprecated]` on a trait impl block into an error which fixes #78625; 2. Changes these and other errors about `#[deprecated]` to use the span of the attribute instead of the item; and 3. Turns this error into a lint to make sure it can be capped with `--cap-lints` and doesn't break any existing dependencies. Can be reviewed per commit. --- Example: ```rust struct X; #[deprecated = ""a""] impl Default for X { #[deprecated = ""b""] fn default() -> Self { X } } ``` Before: ``` error: This deprecation annotation is useless --> src/main.rs:6:5 | 6 | / fn default() -> Self { 7 | | X 8 | | } | |_____^ ``` After: ``` error: this `#[deprecated]' annotation has no effect --> src/main.rs:3:1 | 3 | #[deprecated = ""a""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute | = note: `#[deny(useless_deprecated)]` on by default error: this `#[deprecated]' annotation has no effect --> src/main.rs:5:5 | 5 | #[deprecated = ""b""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute ```",HEART,2020-11-01T21:16:27Z,camelid,NA https://github.com/rust-lang/rust/pull/78626,MERGED,2020-11-01T12:14:27Z,2020-11-03T21:18:45Z,Improve errors about #[deprecated] attribute,m-ou-se,f0112928cb13dbf8936c79d31badf3b684bdda10,8,"Rollup merge of #78626 - fusion-engineering-forks:deprecated-trait-impl r=estebank Improve errors about #[deprecated] attribute This change: 1. Turns `#[deprecated]` on a trait impl block into an error which fixes #78625; 2. Changes these and other errors about `#[deprecated]` to use the span of the attribute instead of the item; and 3. Turns this error into a lint to make sure it can be capped with `--cap-lints` and doesn't break any existing dependencies. Can be reviewed per commit. --- Example: ```rust struct X; #[deprecated = ""a""] impl Default for X { #[deprecated = ""b""] fn default() -> Self { X } } ``` Before: ``` error: This deprecation annotation is useless --> src/main.rs:6:5 | 6 | / fn default() -> Self { 7 | | X 8 | | } | |_____^ ``` After: ``` error: this `#[deprecated]' annotation has no effect --> src/main.rs:3:1 | 3 | #[deprecated = ""a""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute | = note: `#[deny(useless_deprecated)]` on by default error: this `#[deprecated]' annotation has no effect --> src/main.rs:5:5 | 5 | #[deprecated = ""b""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute ```",HEART,2020-11-01T23:50:26Z,estebank,NA https://github.com/rust-lang/rust/pull/78626,MERGED,2020-11-01T12:14:27Z,2020-11-03T21:18:45Z,Improve errors about #[deprecated] attribute,m-ou-se,f0112928cb13dbf8936c79d31badf3b684bdda10,8,"Rollup merge of #78626 - fusion-engineering-forks:deprecated-trait-impl r=estebank Improve errors about #[deprecated] attribute This change: 1. Turns `#[deprecated]` on a trait impl block into an error which fixes #78625; 2. Changes these and other errors about `#[deprecated]` to use the span of the attribute instead of the item; and 3. Turns this error into a lint to make sure it can be capped with `--cap-lints` and doesn't break any existing dependencies. Can be reviewed per commit. --- Example: ```rust struct X; #[deprecated = ""a""] impl Default for X { #[deprecated = ""b""] fn default() -> Self { X } } ``` Before: ``` error: This deprecation annotation is useless --> src/main.rs:6:5 | 6 | / fn default() -> Self { 7 | | X 8 | | } | |_____^ ``` After: ``` error: this `#[deprecated]' annotation has no effect --> src/main.rs:3:1 | 3 | #[deprecated = ""a""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute | = note: `#[deny(useless_deprecated)]` on by default error: this `#[deprecated]' annotation has no effect --> src/main.rs:5:5 | 5 | #[deprecated = ""b""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute ```",HEART,2020-11-02T12:06:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78626,MERGED,2020-11-01T12:14:27Z,2020-11-03T21:18:45Z,Improve errors about #[deprecated] attribute,m-ou-se,f0112928cb13dbf8936c79d31badf3b684bdda10,8,"Rollup merge of #78626 - fusion-engineering-forks:deprecated-trait-impl r=estebank Improve errors about #[deprecated] attribute This change: 1. Turns `#[deprecated]` on a trait impl block into an error which fixes #78625; 2. Changes these and other errors about `#[deprecated]` to use the span of the attribute instead of the item; and 3. Turns this error into a lint to make sure it can be capped with `--cap-lints` and doesn't break any existing dependencies. Can be reviewed per commit. --- Example: ```rust struct X; #[deprecated = ""a""] impl Default for X { #[deprecated = ""b""] fn default() -> Self { X } } ``` Before: ``` error: This deprecation annotation is useless --> src/main.rs:6:5 | 6 | / fn default() -> Self { 7 | | X 8 | | } | |_____^ ``` After: ``` error: this `#[deprecated]' annotation has no effect --> src/main.rs:3:1 | 3 | #[deprecated = ""a""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute | = note: `#[deny(useless_deprecated)]` on by default error: this `#[deprecated]' annotation has no effect --> src/main.rs:5:5 | 5 | #[deprecated = ""b""] | ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute ```",THUMBS_UP,2022-02-09T14:26:17Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/78627,MERGED,2020-11-01T13:32:16Z,2020-11-02T13:07:05Z,Point out that total_cmp is no strict superset of partial comparison,est31,fb7948e7c1aa0ff6ce4cbde45cde2384d1d1ba10,2,Rollup merge of #78627 - est31:total_cmp_no_superset r=m-ou-se Point out that total_cmp is no strict superset of partial comparison Partial comparison and total_cmp are not equal. This helps preventing the mistake of creating float wrappers that base their Ord impl on total_cmp and their PartialOrd impl on the PartialOrd impl of the float type. PartialOrd and Ord [are required to agree with each other](https://doc.rust-lang.org/std/cmp/trait.Ord.html#how-can-i-implement-ord).,THUMBS_UP,2020-11-01T14:24:58Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/78627,MERGED,2020-11-01T13:32:16Z,2020-11-02T13:07:05Z,Point out that total_cmp is no strict superset of partial comparison,est31,fb7948e7c1aa0ff6ce4cbde45cde2384d1d1ba10,2,Rollup merge of #78627 - est31:total_cmp_no_superset r=m-ou-se Point out that total_cmp is no strict superset of partial comparison Partial comparison and total_cmp are not equal. This helps preventing the mistake of creating float wrappers that base their Ord impl on total_cmp and their PartialOrd impl on the PartialOrd impl of the float type. PartialOrd and Ord [are required to agree with each other](https://doc.rust-lang.org/std/cmp/trait.Ord.html#how-can-i-implement-ord).,THUMBS_UP,2020-11-01T15:24:50Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78627,MERGED,2020-11-01T13:32:16Z,2020-11-02T13:07:05Z,Point out that total_cmp is no strict superset of partial comparison,est31,fb7948e7c1aa0ff6ce4cbde45cde2384d1d1ba10,2,Rollup merge of #78627 - est31:total_cmp_no_superset r=m-ou-se Point out that total_cmp is no strict superset of partial comparison Partial comparison and total_cmp are not equal. This helps preventing the mistake of creating float wrappers that base their Ord impl on total_cmp and their PartialOrd impl on the PartialOrd impl of the float type. PartialOrd and Ord [are required to agree with each other](https://doc.rust-lang.org/std/cmp/trait.Ord.html#how-can-i-implement-ord).,THUMBS_UP,2020-11-08T19:13:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78634,CLOSED,2020-11-01T17:28:25Z,2021-02-23T10:17:34Z,Implement PartialEq for proc_macro::Ident == strings,dtolnay,NA,NA,NA,THUMBS_UP,2020-11-01T17:57:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78634,CLOSED,2020-11-01T17:28:25Z,2021-02-23T10:17:34Z,Implement PartialEq for proc_macro::Ident == strings,dtolnay,NA,NA,NA,THUMBS_UP,2020-11-01T18:36:12Z,est31,NA https://github.com/rust-lang/rust/pull/78634,CLOSED,2020-11-01T17:28:25Z,2021-02-23T10:17:34Z,Implement PartialEq for proc_macro::Ident == strings,dtolnay,NA,NA,NA,THUMBS_UP,2020-11-04T09:46:50Z,elichai,NA https://github.com/rust-lang/rust/pull/78634,CLOSED,2020-11-01T17:28:25Z,2021-02-23T10:17:34Z,Implement PartialEq for proc_macro::Ident == strings,dtolnay,NA,NA,NA,ROCKET,2020-11-19T22:58:54Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/78634,CLOSED,2020-11-01T17:28:25Z,2021-02-23T10:17:34Z,Implement PartialEq for proc_macro::Ident == strings,dtolnay,NA,NA,NA,THUMBS_UP,2021-01-29T16:56:54Z,Kestrer,NA https://github.com/rust-lang/rust/pull/78636,MERGED,2020-11-01T17:51:02Z,2020-11-24T03:12:22Z,Add PartialEq for proc_macro::Punct,dtolnay,cb5b87133a9b1d4489c1326a5cc3942e4345fcf9,2,Auto merge of #78636 - dtolnay:puncteq r=petrochenkov Add PartialEq for proc_macro::Punct `punct.as_char() == '░'` is pervasive when parsing anything involving punct. I think `punct == '░'` is sufficiently unambiguous that it makes sense to provide the impl. https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L79 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L83 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/suggestions/auxiliary/issue-61963.rs#L26 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/proc-macro/auxiliary/three-equals.rs#L23,THUMBS_UP,2020-11-01T17:57:02Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78636,MERGED,2020-11-01T17:51:02Z,2020-11-24T03:12:22Z,Add PartialEq for proc_macro::Punct,dtolnay,cb5b87133a9b1d4489c1326a5cc3942e4345fcf9,2,Auto merge of #78636 - dtolnay:puncteq r=petrochenkov Add PartialEq for proc_macro::Punct `punct.as_char() == '░'` is pervasive when parsing anything involving punct. I think `punct == '░'` is sufficiently unambiguous that it makes sense to provide the impl. https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L79 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L83 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/suggestions/auxiliary/issue-61963.rs#L26 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/proc-macro/auxiliary/three-equals.rs#L23,THUMBS_UP,2020-11-01T18:34:55Z,est31,NA https://github.com/rust-lang/rust/pull/78636,MERGED,2020-11-01T17:51:02Z,2020-11-24T03:12:22Z,Add PartialEq for proc_macro::Punct,dtolnay,cb5b87133a9b1d4489c1326a5cc3942e4345fcf9,2,Auto merge of #78636 - dtolnay:puncteq r=petrochenkov Add PartialEq for proc_macro::Punct `punct.as_char() == '░'` is pervasive when parsing anything involving punct. I think `punct == '░'` is sufficiently unambiguous that it makes sense to provide the impl. https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L79 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L83 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/suggestions/auxiliary/issue-61963.rs#L26 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/proc-macro/auxiliary/three-equals.rs#L23,THUMBS_UP,2020-11-19T18:04:56Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/78636,MERGED,2020-11-01T17:51:02Z,2020-11-24T03:12:22Z,Add PartialEq for proc_macro::Punct,dtolnay,cb5b87133a9b1d4489c1326a5cc3942e4345fcf9,2,Auto merge of #78636 - dtolnay:puncteq r=petrochenkov Add PartialEq for proc_macro::Punct `punct.as_char() == '░'` is pervasive when parsing anything involving punct. I think `punct == '░'` is sufficiently unambiguous that it makes sense to provide the impl. https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L79 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/library/proc_macro/src/quote.rs#L83 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/suggestions/auxiliary/issue-61963.rs#L26 https://github.com/rust-lang/rust/blob/1899c489d4c30b2640d30b77ac04f0a548834d81/src/test/ui/proc-macro/auxiliary/three-equals.rs#L23,THUMBS_UP,2021-01-01T06:55:51Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/78638,MERGED,2020-11-01T18:43:09Z,2020-11-05T17:19:30Z,reverse binding order in matches to allow the subbinding of copyable fields in bindings after @,vn-ki,b1d9f31e043d0ba2782a4bb7416f18c4ba1c9044,22,Auto merge of #78638 - vn-ki:bindigs-after-at-issue-69971 r=oli-obk reverse binding order in matches to allow the subbinding of copyable fields in bindings after @ Fixes #69971 ### TODO - [x] Regression tests r? `@oli-obk`,THUMBS_UP,2020-11-13T06:07:17Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/78641,MERGED,2020-11-01T19:28:33Z,2021-02-01T19:22:40Z,Let io::copy reuse BufWriter buffers,the8472,a7a6f013a20fbdf21d77e8ed16f0d8c7b70a7899,4,Rollup merge of #78641 - the8472:buffered-copy r=sfackler Let io::copy reuse BufWriter buffers This optimization will allow users to implicitly set the buffer size for io::copy by wrapping the writer into a `BufWriter` if the default block size is insufficient which should fix #49921 Due to min_specialization limitations this approach only works with `BufWriter` but not for `BufReader` since `R` is unconstrained and thus the necessary specialization on `R: Read` is not always applicable. Once specialization becomes more powerful this optimization could be extended to look at the reader and writer side and use whichever buffer is larger.,THUMBS_UP,2020-11-05T03:26:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/78648,CLOSED,2020-11-02T00:19:50Z,2020-11-04T15:07:16Z,Make Vec::len() and Vec::is_empty() const,jplatte,NA,NA,NA,LAUGH,2020-11-02T12:56:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/78659,MERGED,2020-11-02T03:50:37Z,2020-11-03T21:18:41Z,Corrected suggestion for generic parameters in `function_item_references` lint,ayrtonm,f347dab47c2c29640747d8200e00f6a5de3c7b7b,3,Rollup merge of #78659 - ayrtonm:fn-ref-lint-fix r=oli-obk Corrected suggestion for generic parameters in `function_item_references` lint This commit handles functions with generic type parameters like you pointed out as well as const generics. Also this is probably a minor thing but the type alias you used in the example doesn't show up so the suggestion right now would be `size_of::<[u8; 16]> as fn() ->`. This is because the lint checker works with MIR instead of HIR. I don't think we can get the alias at that point but let me know if I'm wrong and there's a way to fix this. Also I put you as the reviewer but I'm not sure if you want to review it or if it makes more sense to ask one of the original reviewers of this lint. closes #78571,THUMBS_UP,2020-11-02T04:12:45Z,tesuji,NA https://github.com/rust-lang/rust/pull/78669,MERGED,2020-11-02T13:58:39Z,2020-11-11T04:01:05Z,Use check-pass instead of build-pass in some consts ui test suits,sasurau4,3a2cbe6b830c28709076a5ce632fbfd447c5fe31,4,Rollup merge of #78669 - sasurau4:test/check-pass-consts r=jyn514 Use check-pass instead of build-pass in some consts ui test suits Helps with #62277 Changed tests modified by https://github.com/rust-lang/rust/pull/57175 because of the stabilization `#![feature(const_let)]`. They should be compile-fail because the feature gate checking disallow the feature before stabilization. So the feature gate checking have nothing to do with codegen according to https://rustc-dev-guide.rust-lang.org/feature-gate-ck.html.,THUMBS_UP,2020-11-10T12:53:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78676,MERGED,2020-11-02T18:25:23Z,2020-11-03T09:18:29Z,add mipsel-unknown-none target,kiffie,1cb137b3e955375115c76d2d66e9881435adfada,3,Rollup merge of #78676 - kiffie:embedded-bare-mipsr2 r=jonas-schievink add mipsel-unknown-none target This adds a target for bare MIPS32r2 little endian softfloat. This target can be used for PIC32 microcontrollers (or possibly for other devices that have a MIPS MCU core such as the M4K core). Tried to find a name for the target that is in line with the naming scheme apparently used for the other MIPS targets. r? `@jonas-schievink`,HEART,2021-07-04T05:03:21Z,chrish42,NA https://github.com/rust-lang/rust/pull/78677,MERGED,2020-11-02T18:25:49Z,2020-11-04T13:54:31Z,Use reparsed `TokenStream` if we captured any inner attributes,Aaron1011,601c13c6fda6a7db423c974797e36c79a9a0c0ac,4,Auto merge of #78677 - Aaron1011:fix/capture-inner-attrs r=petrochenkov Use reparsed `TokenStream` if we captured any inner attributes Fixes #78675 We now bail out of `prepend_attrs` if we ended up capturing any inner attributes (which can happen in several places due to token capturing for `macro_rules!` arguments.,THUMBS_UP,2020-11-02T18:29:11Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/78681,MERGED,2020-11-02T19:52:11Z,2021-04-23T02:48:18Z,Improve rebuilding behaviour of BinaryHeap::retain.,m-ou-se,f4a8cf0a00580eeb093774681db74e5f2ba57c85,2,Auto merge of #78681 - m-ou-se:binary-heap-retain r=Amanieu Improve rebuilding behaviour of BinaryHeap::retain. This changes `BinaryHeap::retain` such that it doesn't always fully rebuild the heap but only rebuilds the parts for which that's necessary. This makes use of the fact that retain gives out `&T`s and not `&mut T`s. Retaining every element or removing only elements at the end results in no rebuilding at all. Retaining most elements results in only reordering the elements that got moved (those after the first removed element) using the same logic as was already used for `append`. cc `@KodrAus` `@sfackler` - We briefly discussed this possibility in the meeting last week while we talked about stabilization of this function (#71503).,ROCKET,2020-11-03T09:41:36Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/78681,MERGED,2020-11-02T19:52:11Z,2021-04-23T02:48:18Z,Improve rebuilding behaviour of BinaryHeap::retain.,m-ou-se,f4a8cf0a00580eeb093774681db74e5f2ba57c85,2,Auto merge of #78681 - m-ou-se:binary-heap-retain r=Amanieu Improve rebuilding behaviour of BinaryHeap::retain. This changes `BinaryHeap::retain` such that it doesn't always fully rebuild the heap but only rebuilds the parts for which that's necessary. This makes use of the fact that retain gives out `&T`s and not `&mut T`s. Retaining every element or removing only elements at the end results in no rebuilding at all. Retaining most elements results in only reordering the elements that got moved (those after the first removed element) using the same logic as was already used for `append`. cc `@KodrAus` `@sfackler` - We briefly discussed this possibility in the meeting last week while we talked about stabilization of this function (#71503).,ROCKET,2020-11-30T10:37:03Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78681,MERGED,2020-11-02T19:52:11Z,2021-04-23T02:48:18Z,Improve rebuilding behaviour of BinaryHeap::retain.,m-ou-se,f4a8cf0a00580eeb093774681db74e5f2ba57c85,2,Auto merge of #78681 - m-ou-se:binary-heap-retain r=Amanieu Improve rebuilding behaviour of BinaryHeap::retain. This changes `BinaryHeap::retain` such that it doesn't always fully rebuild the heap but only rebuilds the parts for which that's necessary. This makes use of the fact that retain gives out `&T`s and not `&mut T`s. Retaining every element or removing only elements at the end results in no rebuilding at all. Retaining most elements results in only reordering the elements that got moved (those after the first removed element) using the same logic as was already used for `append`. cc `@KodrAus` `@sfackler` - We briefly discussed this possibility in the meeting last week while we talked about stabilization of this function (#71503).,ROCKET,2021-04-29T20:36:33Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/78684,MERGED,2020-11-02T21:32:38Z,2020-12-01T23:44:29Z,Add wasm32 support to inline asm,devsnek,6645da366eed0c61258a04265bea513e94df7ea6,8,Auto merge of #78684 - devsnek:inline-asm-wasm r=Amanieu Add wasm32 support to inline asm There is some contention around inline asm and wasm and I really only made this to figure out the process of hacking on rustc but I figured as long as the code existed it was worth uploading. cc `@Amanieu`,EYES,2020-11-03T13:31:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78684,MERGED,2020-11-02T21:32:38Z,2020-12-01T23:44:29Z,Add wasm32 support to inline asm,devsnek,6645da366eed0c61258a04265bea513e94df7ea6,8,Auto merge of #78684 - devsnek:inline-asm-wasm r=Amanieu Add wasm32 support to inline asm There is some contention around inline asm and wasm and I really only made this to figure out the process of hacking on rustc but I figured as long as the code existed it was worth uploading. cc `@Amanieu`,HOORAY,2021-01-23T21:28:40Z,rrbutani,NA https://github.com/rust-lang/rust/pull/78705,MERGED,2020-11-03T15:46:06Z,2020-11-06T19:01:26Z,Print a summary of which test suite failed,Mark-Simulacrum,3f5723c6c59d902987bf19cba51a71ce87df1b26,4,Rollup merge of #78705 - Mark-Simulacrum:nicer-failure-compiletest r=jyn514 Print a summary of which test suite failed Especially on CI where cross-compiling is common and single builder may end up with multiple hosts and multiple targets it can be annoying to scroll back to the nearest start of test marker. This prints out a summary of the test suite being run directly in compiletest. For example on a mir-opt failure this would show something like this: ``` failures: [mir-opt] mir-opt/while-storage.rs test result: FAILED. 140 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out Some tests failed in compiletest suite=mir-opt mode=mir-opt host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu ``` Fixes #78517,HEART,2020-11-06T19:06:43Z,camelid,NA https://github.com/rust-lang/rust/pull/78714,MERGED,2020-11-03T23:52:18Z,2020-11-17T01:15:01Z,Simplify output capturing,m-ou-se,11ce918c75b05d065ce3bf98b20d62465b5afc55,16,"Rollup merge of #78714 - m-ou-se:simplify-local-streams r=KodrAus Simplify output capturing This is a sequence of incremental improvements to the unstable/internal `set_panic` and `set_print` mechanism used by the `test` crate: 1. Remove the `LocalOutput` trait and use `Arc>` instead of `Box`. In practice all implementations of `LocalOutput` were just `Arc>`. This simplifies some logic and removes all custom `Sink` implementations such as `library/test/src/helpers/sink.rs`. Also removes a layer of indirection as the outermost `Box` is now gone. It also means that locking now happens per `write_fmt` not per individual `write` within. (So `""{} {}\n""` now results in one `lock()` not four or more.) 2. Since in all cases the `dyn Write`s were just `Vec`s replace the type with `Arc>>`. This simplifies things more as error handling and flushing can be removed now. This also removes the hack needed in the default panic handler to make this work with `::realstd` as (unlike `Write`) `Vec` is from `alloc` not `std`. 3. Replace the `RefCell`s by regular `Cell`s. The `RefCell`s were mostly used as `mem::replace(&mut *cell.borrow_mut() something)` which is just `Cell::replace`. This removes an unecessary bookkeeping and makes the code a bit easier to read. 4. Merge `set_panic` and `set_print` into a single `set_output_capture`. Neither the test crate nor rustc (the only users of this feature) have a use for using these separately. Merging them simplifies things even more. This uses a new function name and feature name to make it clearer this is internal and not supposed to be used by other crates. Might be easier to review per commit.",HEART,2020-11-04T02:19:25Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78714,MERGED,2020-11-03T23:52:18Z,2020-11-17T01:15:01Z,Simplify output capturing,m-ou-se,11ce918c75b05d065ce3bf98b20d62465b5afc55,16,"Rollup merge of #78714 - m-ou-se:simplify-local-streams r=KodrAus Simplify output capturing This is a sequence of incremental improvements to the unstable/internal `set_panic` and `set_print` mechanism used by the `test` crate: 1. Remove the `LocalOutput` trait and use `Arc>` instead of `Box`. In practice all implementations of `LocalOutput` were just `Arc>`. This simplifies some logic and removes all custom `Sink` implementations such as `library/test/src/helpers/sink.rs`. Also removes a layer of indirection as the outermost `Box` is now gone. It also means that locking now happens per `write_fmt` not per individual `write` within. (So `""{} {}\n""` now results in one `lock()` not four or more.) 2. Since in all cases the `dyn Write`s were just `Vec`s replace the type with `Arc>>`. This simplifies things more as error handling and flushing can be removed now. This also removes the hack needed in the default panic handler to make this work with `::realstd` as (unlike `Write`) `Vec` is from `alloc` not `std`. 3. Replace the `RefCell`s by regular `Cell`s. The `RefCell`s were mostly used as `mem::replace(&mut *cell.borrow_mut() something)` which is just `Cell::replace`. This removes an unecessary bookkeeping and makes the code a bit easier to read. 4. Merge `set_panic` and `set_print` into a single `set_output_capture`. Neither the test crate nor rustc (the only users of this feature) have a use for using these separately. Merging them simplifies things even more. This uses a new function name and feature name to make it clearer this is internal and not supposed to be used by other crates. Might be easier to review per commit.",HEART,2020-11-04T04:24:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/78714,MERGED,2020-11-03T23:52:18Z,2020-11-17T01:15:01Z,Simplify output capturing,m-ou-se,11ce918c75b05d065ce3bf98b20d62465b5afc55,16,"Rollup merge of #78714 - m-ou-se:simplify-local-streams r=KodrAus Simplify output capturing This is a sequence of incremental improvements to the unstable/internal `set_panic` and `set_print` mechanism used by the `test` crate: 1. Remove the `LocalOutput` trait and use `Arc>` instead of `Box`. In practice all implementations of `LocalOutput` were just `Arc>`. This simplifies some logic and removes all custom `Sink` implementations such as `library/test/src/helpers/sink.rs`. Also removes a layer of indirection as the outermost `Box` is now gone. It also means that locking now happens per `write_fmt` not per individual `write` within. (So `""{} {}\n""` now results in one `lock()` not four or more.) 2. Since in all cases the `dyn Write`s were just `Vec`s replace the type with `Arc>>`. This simplifies things more as error handling and flushing can be removed now. This also removes the hack needed in the default panic handler to make this work with `::realstd` as (unlike `Write`) `Vec` is from `alloc` not `std`. 3. Replace the `RefCell`s by regular `Cell`s. The `RefCell`s were mostly used as `mem::replace(&mut *cell.borrow_mut() something)` which is just `Cell::replace`. This removes an unecessary bookkeeping and makes the code a bit easier to read. 4. Merge `set_panic` and `set_print` into a single `set_output_capture`. Neither the test crate nor rustc (the only users of this feature) have a use for using these separately. Merging them simplifies things even more. This uses a new function name and feature name to make it clearer this is internal and not supposed to be used by other crates. Might be easier to review per commit.",HEART,2020-11-05T19:59:00Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78714,MERGED,2020-11-03T23:52:18Z,2020-11-17T01:15:01Z,Simplify output capturing,m-ou-se,11ce918c75b05d065ce3bf98b20d62465b5afc55,16,"Rollup merge of #78714 - m-ou-se:simplify-local-streams r=KodrAus Simplify output capturing This is a sequence of incremental improvements to the unstable/internal `set_panic` and `set_print` mechanism used by the `test` crate: 1. Remove the `LocalOutput` trait and use `Arc>` instead of `Box`. In practice all implementations of `LocalOutput` were just `Arc>`. This simplifies some logic and removes all custom `Sink` implementations such as `library/test/src/helpers/sink.rs`. Also removes a layer of indirection as the outermost `Box` is now gone. It also means that locking now happens per `write_fmt` not per individual `write` within. (So `""{} {}\n""` now results in one `lock()` not four or more.) 2. Since in all cases the `dyn Write`s were just `Vec`s replace the type with `Arc>>`. This simplifies things more as error handling and flushing can be removed now. This also removes the hack needed in the default panic handler to make this work with `::realstd` as (unlike `Write`) `Vec` is from `alloc` not `std`. 3. Replace the `RefCell`s by regular `Cell`s. The `RefCell`s were mostly used as `mem::replace(&mut *cell.borrow_mut() something)` which is just `Cell::replace`. This removes an unecessary bookkeeping and makes the code a bit easier to read. 4. Merge `set_panic` and `set_print` into a single `set_output_capture`. Neither the test crate nor rustc (the only users of this feature) have a use for using these separately. Merging them simplifies things even more. This uses a new function name and feature name to make it clearer this is internal and not supposed to be used by other crates. Might be easier to review per commit.",HEART,2020-11-10T22:42:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78714,MERGED,2020-11-03T23:52:18Z,2020-11-17T01:15:01Z,Simplify output capturing,m-ou-se,11ce918c75b05d065ce3bf98b20d62465b5afc55,16,"Rollup merge of #78714 - m-ou-se:simplify-local-streams r=KodrAus Simplify output capturing This is a sequence of incremental improvements to the unstable/internal `set_panic` and `set_print` mechanism used by the `test` crate: 1. Remove the `LocalOutput` trait and use `Arc>` instead of `Box`. In practice all implementations of `LocalOutput` were just `Arc>`. This simplifies some logic and removes all custom `Sink` implementations such as `library/test/src/helpers/sink.rs`. Also removes a layer of indirection as the outermost `Box` is now gone. It also means that locking now happens per `write_fmt` not per individual `write` within. (So `""{} {}\n""` now results in one `lock()` not four or more.) 2. Since in all cases the `dyn Write`s were just `Vec`s replace the type with `Arc>>`. This simplifies things more as error handling and flushing can be removed now. This also removes the hack needed in the default panic handler to make this work with `::realstd` as (unlike `Write`) `Vec` is from `alloc` not `std`. 3. Replace the `RefCell`s by regular `Cell`s. The `RefCell`s were mostly used as `mem::replace(&mut *cell.borrow_mut() something)` which is just `Cell::replace`. This removes an unecessary bookkeeping and makes the code a bit easier to read. 4. Merge `set_panic` and `set_print` into a single `set_output_capture`. Neither the test crate nor rustc (the only users of this feature) have a use for using these separately. Merging them simplifies things even more. This uses a new function name and feature name to make it clearer this is internal and not supposed to be used by other crates. Might be easier to review per commit.",HEART,2020-11-15T01:34:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78715,CLOSED,2020-11-03T23:59:08Z,2020-12-08T18:38:31Z,Add #[must_bind] attribute and lint,vi,NA,NA,NA,THUMBS_UP,2020-11-09T01:24:15Z,jtgeibel,NA https://github.com/rust-lang/rust/pull/78727,MERGED,2020-11-04T10:48:47Z,2020-11-05T12:48:20Z,(rustdoc) fix test for trait impl display,liketechnik,9bbb052af8150c054e3fbb9875bf018490805305,1,Rollup merge of #78727 - liketechnik:issue-55201 r=GuillaumeGomez (rustdoc) fix test for trait impl display The test checks that parameters and return values with `impl Trait` types are correctly generated in rustdoc's output. In essence the previous version of the test checked the absence of values that would never be generated by rustdoc so it could basically never fail. These values were adjusted to the expected output and are now required to exist in rustdoc's output. See https://github.com/rust-lang/rust/issues/55201#issuecomment-716182474 for a detailed explanation of the reasoning behind the changes. Note that the output of rustdoc for `impl Trait`s in parameters and return values did not change since the inital test creation so this PR only modifies the test. Closes #55201,THUMBS_UP,2020-11-05T15:08:55Z,Munksgaard,philip@munksgaard.me https://github.com/rust-lang/rust/pull/78739,MERGED,2020-11-04T15:33:39Z,2020-11-05T12:48:15Z,Fix ICE on type error in async function,hameerabbasi,171d29c9c5bb6fb7cc60702d9c24bee8558c622a,4,Rollup merge of #78739 - hameerabbasi:issue-78654 r=nikomatsakis Fix ICE on type error in async function Fixes #78654,HOORAY,2020-11-05T01:33:53Z,tmandry,NA https://github.com/rust-lang/rust/pull/78746,MERGED,2020-11-04T17:50:49Z,2020-11-10T13:24:53Z,Demote i686-unknown-freebsd to tier 2 compiler target,pietroalbini,4e0695b79fbe5acc5ef1df82166b283368a643ac,5,Rollup merge of #78746 - pietroalbini:i686-freebsd r=Mark-Simulacrum Demote i686-unknown-freebsd to tier 2 compiler target While technically the `i686-unknown-freebsd` target has been a tier 2 development platform for a long time with full toolchain tarballs available on static.rust-lang.org due to a bug in the manifest generation the target was never available for download through rustup. The infrastructure team privately inquired the FreeBSD package maintainers and they weren't relying on those tarballs either so it's a fair assumption to say practically nobody is using those tarballs. This PR then removes the CI builder that produces full tarballs for the target and moves the compilation of `rust-std` for the target in `dist-various-2`. The `x86_64-unknown-freebsd` target is *not* affected. cc `@rust-lang/infra` `@rust-lang/compiler` `@rust-lang/release` r? `@Mark-Simulacrum`,THUMBS_UP,2020-11-05T15:32:04Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-04T19:19:05Z,varkor,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-04T19:54:58Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-04T20:10:53Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-04T20:53:43Z,sandmor,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-05T09:02:09Z,oli-obk,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-05T10:37:15Z,ostwilkens,carl@ostwilkens.se https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-05T10:46:46Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-05T13:17:13Z,cynecx,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-05T23:23:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-06T06:24:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-07T01:08:23Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-07T08:23:41Z,stevenxxiu,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-07T23:29:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-08T19:15:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-09T13:52:33Z,teohhanhui,teohhanhui@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,ROCKET,2020-11-09T13:52:36Z,teohhanhui,teohhanhui@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2020-11-09T13:52:39Z,teohhanhui,teohhanhui@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-12T02:24:26Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-12T06:43:01Z,serak,sirak2010@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-12T07:29:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,ROCKET,2020-11-12T10:57:44Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-12T10:57:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2020-11-12T10:57:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2020-11-12T12:11:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2020-11-12T12:13:47Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-12T22:19:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2020-11-16T15:53:13Z,Kylebrown9,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-16T15:53:13Z,Kylebrown9,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-18T02:43:18Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2020-11-19T13:39:23Z,abhikjain360,abhik@abhikjain.xyz https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HOORAY,2021-08-01T18:49:58Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2021-08-01T18:49:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,ROCKET,2021-08-01T18:50:00Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78748,MERGED,2020-11-04T19:11:59Z,2020-11-09T02:58:13Z,Implement destructuring assignment for tuples,fanzier,abaa78baeb456d1517c94013ecf125c5dff83731,23,Rollup merge of #78748 - fanzier:tuple-assignment r=petrochenkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909 tracking issue: #71126). This PR is the first part of #71156 which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a b) = (1 2) ``` ... becomes ... ```rust { let (lhs0 lhs1) = (1 2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation particularly around default binding modes. r? `@petrochenkov`,HEART,2021-08-31T08:02:32Z,AA1HSHH,NA https://github.com/rust-lang/rust/pull/78775,MERGED,2020-11-05T16:00:34Z,2020-11-08T16:14:45Z,Bump Rustfmt and RLS,ghedo,04859e5ddcf09bd907e2d440b3c4f92683c5a8e9,4,Rollup merge of #78775 - ghedo:bump-rustfmt-rls r=Mark-Simulacrum Bump Rustfmt and RLS Should hopefully fix #78341 and fix #78340.,HEART,2020-11-07T18:47:15Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/78775,MERGED,2020-11-05T16:00:34Z,2020-11-08T16:14:45Z,Bump Rustfmt and RLS,ghedo,04859e5ddcf09bd907e2d440b3c4f92683c5a8e9,4,Rollup merge of #78775 - ghedo:bump-rustfmt-rls r=Mark-Simulacrum Bump Rustfmt and RLS Should hopefully fix #78341 and fix #78340.,HOORAY,2020-11-08T16:38:26Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/78779,MERGED,2020-11-05T17:14:57Z,2020-11-17T14:43:43Z,Introduce `TypeVisitor::BreakTy`,LeSeulArtichaut,e0ef0fc392963438af5f0343bf7caa46fb9c3ec3,32,Auto merge of #78779 - LeSeulArtichaut:ty-visitor-return r=oli-obk Introduce `TypeVisitor::BreakTy` Implements MCP rust-lang/compiler-team#383. r? `@ghost` cc `@lcnr` `@oli-obk` ~~Blocked on FCP in rust-lang/compiler-team#383.~~,HEART,2020-11-06T21:46:38Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-05T18:25:27Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-05T19:28:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-05T19:45:02Z,Urgau,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-05T19:51:35Z,kw-fn,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-05T19:57:50Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",EYES,2020-11-05T20:04:35Z,the8472,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",HEART,2020-11-07T01:09:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",ROCKET,2020-11-07T01:09:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78781,MERGED,2020-11-05T17:45:01Z,2022-06-14T16:18:38Z,Integrate measureme's hardware performance counter support.,eddyb,872503d918b2c3266d828f85e42951df74f5e303,6,"Auto merge of #78781 - eddyb:measureme-rdpmc r=oli-obk Integrate measureme's hardware performance counter support. *Note: this is a companion to https://github.com/rust-lang/measureme/pull/143 and duplicates some information with it for convenience* **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. ## Credits I'd like to start by thanking `@alyssais ` `@cuviper ` `@edef1c ` `@glandium ` `@jix ` `@Mark-Simulacrum ` `@m-ou-se ` `@mystor ` `@nagisa ` `@puckipedia ` and `@yorickvP ` for all of their help with testing and valuable insight and suggestions. Getting here wouldn't have been possible without you! (If I've forgotten anyone please let me know I'm going off memory here plus some discussion logs) ## Summary This PR adds support to `-Z self-profile` for counting hardware events such as ""instructions retired"" (as opposed to being limited to time measurements) using the `rdpmc` instruction on `x86_64` Linux. While other OSes may eventually be supported preliminary research suggests some kind of kernel extension/driver is required to enable this whereas on Linux any user can profile (at least) their own threads. Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters) and was mostly not done due to a lack of readily available test hardware. That said 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused). A new flag `-Z self-profile-counter` was added to control which of the named `measureme` counters is used and which defaults to `wall-time` in order to keep `-Z self-profile`'s current functionality unchanged (at least for now). The named counters so far are: * `wall-time`: the existing time measurement * name chosen for consistency with `perf.rust-lang.org` * continues to use `std::time::Instant` for a nanosecond-precision ""monotonic clock"" * `instructions:u`: the hardware performance counter usually referred to as ""Instructions retired"" * here ""retired"" (roughly) means ""fully executed"" * the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing and therefore counts no kernel instructions * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead* * `instructions-minus-irqs:u`: same as `instructions:u` except the count of hardware interrupts (""IRQs"" here for brevity) is subtracted * *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`* * `instructions-minus-r0420:u`: experimental counter same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs * the `rXXXX` notation is again from Linux `perf` and indicates a ""raw"" counter with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is * this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far * *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does* --- There are also some additional commits: * ~~see [Challenges/Rebasing *shouldn't* affect the results right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious and probably shouldn't be merged or not as-is)~~ * **EDIT**: the effects of these are no long quantifiable the PR includes reverts for them * ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~ * this is also separately found in #77162 and we probably want to avoid doing it by default ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running which I'm not sure about) * **EDIT**: until we can do this based on `-Z` flags this commit has also been reverted * the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects --- **(much later) EDIT**: take any numbers with a grain of salt they may have changed since initial PR open. #### Write-up / report Because of how extensive the full report ended up being I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) but for convenient access here are all the sections (with individual links): (someone suggested I'd make a backup so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up) * [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation) * [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results) * [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead) *Preview (see the report itself for more details):* |Counter|Total
`instructions-minus-irqs:u`|Overhead from ""Baseline""
(for all 1903881
counter reads)|Overhead from ""Baseline""
(per each counter read)| |-|-|-|-| |Baseline|63637621286 ±6|| |`instructions:u`|63658815885 ±2|  +21194599 ±8|  +11| |`instructions-minus-irqs:u`|63680307361 ±13|  +42686075 ±19|  +22| |`wall-time`|63951958376 ±10275|+314337090 ±10281|+165| * [**""Macro"" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time)) *Preview (see the report itself for more details):* || `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u` -: | -: | -: | -: `typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%) `expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%) `mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%) `mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%) `resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%) * [**""Micro"" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals)) * [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats) * [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR) * [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros) * [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) * [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads) * [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges) * [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters) * [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy) * [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction) * [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted) * [**AMD patented time-travel and dubbed it `SpecLockMap`
        or: ""how we accidentally unlocked `rr` on AMD Zen""**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”) * [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) * [**Rebasing *shouldn't* affect the results right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results -right) * [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)",ROCKET,2020-11-14T09:16:35Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78782,MERGED,2020-11-05T19:12:24Z,2020-11-12T03:00:07Z,Do not collect tokens for doc comments,petrochenkov,5a6a41e7847ff5f85a31b87431ce2af29c567f1d,17,Auto merge of #78782 - petrochenkov:nodoctok r=Aaron1011 Do not collect tokens for doc comments Doc comment is a single token and AST has all the information to re-create it precisely. Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0` cc https://github.com/rust-lang/rust/pull/78736). (I also moved token collection into `fn parse_attribute` to deduplicate code a bit.) r? `@Aaron1011`,THUMBS_UP,2020-11-05T19:57:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78782,MERGED,2020-11-05T19:12:24Z,2020-11-12T03:00:07Z,Do not collect tokens for doc comments,petrochenkov,5a6a41e7847ff5f85a31b87431ce2af29c567f1d,17,Auto merge of #78782 - petrochenkov:nodoctok r=Aaron1011 Do not collect tokens for doc comments Doc comment is a single token and AST has all the information to re-create it precisely. Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0` cc https://github.com/rust-lang/rust/pull/78736). (I also moved token collection into `fn parse_attribute` to deduplicate code a bit.) r? `@Aaron1011`,THUMBS_UP,2020-11-05T20:02:36Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78782,MERGED,2020-11-05T19:12:24Z,2020-11-12T03:00:07Z,Do not collect tokens for doc comments,petrochenkov,5a6a41e7847ff5f85a31b87431ce2af29c567f1d,17,Auto merge of #78782 - petrochenkov:nodoctok r=Aaron1011 Do not collect tokens for doc comments Doc comment is a single token and AST has all the information to re-create it precisely. Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0` cc https://github.com/rust-lang/rust/pull/78736). (I also moved token collection into `fn parse_attribute` to deduplicate code a bit.) r? `@Aaron1011`,THUMBS_UP,2020-11-05T22:26:04Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78782,MERGED,2020-11-05T19:12:24Z,2020-11-12T03:00:07Z,Do not collect tokens for doc comments,petrochenkov,5a6a41e7847ff5f85a31b87431ce2af29c567f1d,17,Auto merge of #78782 - petrochenkov:nodoctok r=Aaron1011 Do not collect tokens for doc comments Doc comment is a single token and AST has all the information to re-create it precisely. Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0` cc https://github.com/rust-lang/rust/pull/78736). (I also moved token collection into `fn parse_attribute` to deduplicate code a bit.) r? `@Aaron1011`,THUMBS_UP,2020-11-06T02:16:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78788,MERGED,2020-11-05T21:54:40Z,2020-11-08T16:14:42Z,Correct unsigned equivalent of isize to be usize,jhpratt,3541280753329392b76891074979abb42ff86287,1,Rollup merge of #78788 - jhpratt:isize-impl-fix r=m-ou-se Correct unsigned equivalent of isize to be usize See [#74913 (comment)](https://github.com/rust-lang/rust/issues/74913#issuecomment-722334456) for why this matters. Apparently it hasn't been used anywhere else though CI will tell for sure.,THUMBS_UP,2020-11-06T18:54:35Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/78788,MERGED,2020-11-05T21:54:40Z,2020-11-08T16:14:42Z,Correct unsigned equivalent of isize to be usize,jhpratt,3541280753329392b76891074979abb42ff86287,1,Rollup merge of #78788 - jhpratt:isize-impl-fix r=m-ou-se Correct unsigned equivalent of isize to be usize See [#74913 (comment)](https://github.com/rust-lang/rust/issues/74913#issuecomment-722334456) for why this matters. Apparently it hasn't been used anywhere else though CI will tell for sure.,THUMBS_UP,2020-11-09T11:05:59Z,ssomers,git@steinsomers.be https://github.com/rust-lang/rust/pull/78790,MERGED,2020-11-05T22:25:24Z,2020-11-11T19:12:15Z,Vendor libtest's dependencies in the rust-src component,Gankra,7afc5172305cdae588a0318ce545749cf4ed947d,2,Auto merge of #78790 - Gankra:rust-src-vendor r=Mark-Simulacrum Vendor libtest's dependencies in the rust-src component This is the Rust side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23 Note that this won't produce a useful result for `cargo -Zbuild-std` if there are multiple versions of a crate vendored but will otherwise produce a valid vendor dir. See https://github.com/rust-lang/cargo/pull/8834 for the other half of this change.,HEART,2020-11-06T16:17:40Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T10:38:01Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T11:32:17Z,tesuji,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T11:33:18Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T12:11:50Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T12:22:11Z,est31,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T16:43:30Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T17:11:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-06T20:04:05Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-07T01:11:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-07T01:11:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-07T03:06:26Z,null-sleep,dhruvjhr@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-07T03:06:28Z,null-sleep,dhruvjhr@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-07T14:38:38Z,lqd,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-07T16:30:12Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-08T07:31:45Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-08T07:31:47Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-08T15:50:53Z,roxelo,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-08T15:50:55Z,roxelo,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-14T01:43:16Z,camelid,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-14T01:43:17Z,camelid,NA https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-14T08:53:15Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HOORAY,2020-11-15T10:40:19Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-16T20:25:12Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/78801,MERGED,2020-11-06T06:54:41Z,2020-11-17T06:38:06Z,RFC-2229: Implement Precise Capture Analysis,arora-aman,b5c37e86ff1782923e3abfbf5491dd383fcf827d,37,Auto merge of #78801 - sexxi-goose:min_capture r=nikomatsakis RFC-2229: Implement Precise Capture Analysis ### This PR introduces - Feature gate for RFC-2229 (incomplete) `capture_disjoint_field` - Rustc Attribute to print out the capture analysis `rustc_capture_analysis` - Precise capture analysis ### Description of the analysis 1. If the feature gate is not set then all variables that are not local to the closure will be added to the list of captures. (This is for backcompat) 2. The rest of the analysis is based entirely on how the captured `Place`s are used within the closure. Precise information (i.e. projections) about the `Place` is maintained throughout. 3. To reduce the amount of information we need to keep track of we do a minimization step. In this step we determine a list such that no Place within this list represents an ancestor path to another entry in the list. Check rust-lang/project-rfc-2229#9 for more detailed examples. 4. To keep the compiler functional as before we implement a Bridge between the results of this new analysis to existing data structures used for closure captures. Note the new capture analysis results are only part of MaybeTypeckTables that is the information is only available during typeck-ing. ### Known issues - Statements like `let _ = x` will make the compiler ICE when used within a closure with the feature enabled. More generally speaking the issue is caused by `let` statements that create no bindings and are init'ed using a Place expression. ### Testing We removed the code that would handle the case where the feature gate is not set to enable the feature as default and did a bors try and perf run. More information here: #78762 ### Thanks This has been slowly in the works for a while now. I want to call out `@Azhng` `@ChrisPardy` `@null-sleep` `@jenniferwills` `@logmosier` `@roxelo` for working on this and the previous PRs that led up to this `@nikomatsakis` for guiding us. Closes rust-lang/project-rfc-2229#7 Closes rust-lang/project-rfc-2229#9 Closes rust-lang/project-rfc-2229#6 Closes rust-lang/project-rfc-2229#19 r? `@nikomatsakis`,HEART,2020-11-17T01:41:43Z,est31,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T10:56:01Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T12:07:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T12:49:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T13:00:03Z,est31,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T13:42:10Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2020-11-06T17:06:24Z,a1phyr,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T17:32:23Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-06T17:55:03Z,panaman67,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-07T05:29:35Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-07T07:59:46Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2020-11-07T08:04:06Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-07T08:04:08Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2020-11-07T09:29:15Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-11-08T06:37:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2020-11-08T06:40:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2020-11-09T12:03:23Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2020-11-22T14:31:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2020-12-03T01:03:50Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-12-03T01:03:54Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-12-03T02:26:08Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2020-12-03T14:26:53Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2020-12-10T02:03:45Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2020-12-14T01:42:22Z,awulkan,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-01-01T12:53:45Z,anniekatlin,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-01-01T12:53:47Z,anniekatlin,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-01-01T12:56:48Z,anniekatlin,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-01-01T12:56:51Z,anniekatlin,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-01-10T05:48:25Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-02-17T20:22:59Z,lygstate,luoyonggang@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-02-18T00:50:59Z,jplatte,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-02-18T12:19:31Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-02-18T12:19:32Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-02-18T12:19:33Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-03-21T19:27:58Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-03-21T19:28:00Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-03-21T19:28:01Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-03-21T19:28:02Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-04-08T14:39:05Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-04-22T01:49:12Z,cynecx,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-04-23T13:55:48Z,ljedrz,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-05-18T09:15:05Z,r00ster91,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-05-18T09:15:05Z,r00ster91,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-08-11T09:35:12Z,gliderkite,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-08-11T17:57:56Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2021-09-15T11:21:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2021-09-15T11:21:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-11-25T15:30:47Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-11-25T15:30:48Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2021-11-29T16:48:09Z,r00ster91,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2021-11-29T16:48:09Z,r00ster91,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-01-14T00:26:32Z,mati865,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-01-14T00:26:34Z,mati865,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-01-15T00:09:44Z,tux3,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-01-15T00:09:45Z,tux3,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-01-15T00:09:46Z,tux3,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2022-01-15T00:09:47Z,tux3,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-01-24T10:10:53Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-01-24T10:10:56Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-02-12T00:30:04Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-04-08T16:42:41Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-04-08T16:42:42Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-05-25T01:36:57Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-05-28T21:35:59Z,yerke,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-05-28T21:36:00Z,yerke,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-05-28T21:36:01Z,yerke,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2022-05-28T21:36:01Z,yerke,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-06-24T10:18:23Z,dlon,dv.lnh.d@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-06-26T10:25:39Z,8573,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-06-29T11:05:25Z,EAimTY,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-07-05T13:16:35Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-07T05:23:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2022-07-07T08:33:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-07-07T08:33:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-07-07T09:02:52Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-07-07T09:02:53Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-07T09:02:53Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2022-07-07T09:02:54Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-07-07T14:16:43Z,inflation,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-07T17:38:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-07-08T04:22:58Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-08T06:15:50Z,kkysen,kkysen@gmail.com https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,THUMBS_UP,2022-07-08T15:14:22Z,alenpaul2001,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HOORAY,2022-07-08T15:14:24Z,alenpaul2001,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-08T15:14:25Z,alenpaul2001,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,ROCKET,2022-07-08T15:14:25Z,alenpaul2001,NA https://github.com/rust-lang/rust/pull/78802,OPEN,2020-11-06T07:52:13Z,NA,Implement network primitives with ideal Rust layout not C system layout,faern,NA,NA,NA,HEART,2022-07-08T21:56:05Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/78818,MERGED,2020-11-06T22:00:16Z,2021-01-17T08:44:16Z,Add `as_rchunks` (and friends) to slices,scottmcm,49d7889da4b97b63f4d3e793a27b78a78326c1cd,2,"Auto merge of #78818 - scottmcm:as_rchunks r=KodrAus Add `as_rchunks` (and friends) to slices `@est31` mentioned (https://github.com/rust-lang/rust/issues/76354#issuecomment-717027175) that for completeness there needed to be an `as_chunks`-like method that chunks from the end (with the remainder at the beginning) like `rchunks` does. So here's a PR for `as_rchunks: &[T] -> (&[T] &[[T; N]])` and `as_rchunks_mut: &mut [T] -> (&mut [T] &mut [[T; N]])`. But as I was doing this and copy-pasting `from_raw_parts` calls I thought that I should extract that into an unsafe method. It started out a private helper but it seemed like `as_chunks_unchecked` could be reasonable as a ""real"" method so I added docs and made it public. Let me know if you think it doesn't pull its weight.",HEART,2020-11-06T22:11:00Z,est31,NA https://github.com/rust-lang/rust/pull/78826,MERGED,2020-11-06T23:45:04Z,2020-11-13T08:22:48Z,resolve: Collapse `macro_rules` scope chains on the fly,petrochenkov,a38f8fb674e6a0a6fc358655c6ce6069235f621a,6,Auto merge of #78826 - petrochenkov:mrscopes2 r=eddyb resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815,HEART,2020-11-07T00:20:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/78826,MERGED,2020-11-06T23:45:04Z,2020-11-13T08:22:48Z,resolve: Collapse `macro_rules` scope chains on the fly,petrochenkov,a38f8fb674e6a0a6fc358655c6ce6069235f621a,6,Auto merge of #78826 - petrochenkov:mrscopes2 r=eddyb resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815,HEART,2020-11-07T01:32:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78826,MERGED,2020-11-06T23:45:04Z,2020-11-13T08:22:48Z,resolve: Collapse `macro_rules` scope chains on the fly,petrochenkov,a38f8fb674e6a0a6fc358655c6ce6069235f621a,6,Auto merge of #78826 - petrochenkov:mrscopes2 r=eddyb resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815,HEART,2020-11-09T09:46:04Z,rylev,NA https://github.com/rust-lang/rust/pull/78826,MERGED,2020-11-06T23:45:04Z,2020-11-13T08:22:48Z,resolve: Collapse `macro_rules` scope chains on the fly,petrochenkov,a38f8fb674e6a0a6fc358655c6ce6069235f621a,6,Auto merge of #78826 - petrochenkov:mrscopes2 r=eddyb resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815,HEART,2020-12-01T03:18:07Z,estebank,NA https://github.com/rust-lang/rust/pull/78826,MERGED,2020-11-06T23:45:04Z,2020-11-13T08:22:48Z,resolve: Collapse `macro_rules` scope chains on the fly,petrochenkov,a38f8fb674e6a0a6fc358655c6ce6069235f621a,6,Auto merge of #78826 - petrochenkov:mrscopes2 r=eddyb resolve: Collapse `macro_rules` scope chains on the fly Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports. Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815,HEART,2021-09-29T18:00:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78830,MERGED,2020-11-07T10:57:40Z,2020-11-10T13:24:44Z,fix `super_visit_with` for `Terminator`,lcnr,7924ecc341d5e7dcdaff22bfd16e76da136c9112,1,Rollup merge of #78830 - lcnr:mir-folder r=oli-obk fix `super_visit_with` for `Terminator` fixes https://github.com/rust-lang/rust/pull/78182#discussion_r509265149 r? `@oli-obk` cc `@LeSeulArtichaut`,THUMBS_UP,2020-11-07T14:35:27Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-07T16:30:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-07T16:32:24Z,varkor,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-07T17:37:12Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HOORAY,2020-11-07T17:37:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-07T18:56:05Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-08T17:17:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-20T08:29:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2020-11-20T18:55:43Z,samsartor,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HOORAY,2021-08-01T18:50:19Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78836,MERGED,2020-11-07T16:15:27Z,2020-11-13T02:05:14Z,Implement destructuring assignment for structs and slices,fanzier,755dd14e00fd9007a67779b129e81b47c6435113,32,Rollup merge of #78836 - fanzier:struct-and-slice-destructuring r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the second part of #71156 which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged I totally understand of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this the following *parser change* was necessary: struct expressions are not required to have a base expression i.e. `Struct { a: 1 .. }` becomes legal (in order to act like a struct pattern). Unfortunately this PR slightly regresses the diagnostics implemented in #77283. However it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation particularly around the struct rest changes. r? ``@petrochenkov``,HEART,2021-08-01T18:50:20Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-11-07T17:57:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-11-07T19:55:09Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2020-11-08T01:04:33Z,dtolnay,dtolnay@gmail.com https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-11-08T03:52:59Z,trevyn,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2020-11-17T23:23:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-11-17T23:23:12Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-11-17T23:30:07Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HEART,2020-11-18T05:19:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HEART,2020-11-23T15:09:23Z,Enet4,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2020-11-27T19:44:59Z,vallentin,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2020-12-01T18:43:15Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2020-12-10T04:32:47Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2020-12-18T20:09:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HEART,2020-12-30T21:24:10Z,camelid,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2021-01-11T04:08:10Z,trevyn,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2021-05-04T18:43:34Z,DianaNites,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2021-08-22T23:06:48Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HOORAY,2021-08-22T23:06:49Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",HEART,2021-08-22T23:06:50Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/78837,MERGED,2020-11-07T16:52:04Z,2020-12-10T03:11:29Z,Accept arbitrary expressions in key-value attributes at parse time,petrochenkov,58d2bad9f7ab0971495247b6c94978848760ca9d,24,"Auto merge of #78837 - petrochenkov:keyvalexpr r=davidtwco Accept arbitrary expressions in key-value attributes at parse time Continuation of https://github.com/rust-lang/rust/pull/77271. We now support arbitrary expressions in values of key-value attributes at parse time. ``` #[my_attr = EXPR] ``` Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted. There are two immediate motivational cases for this: - External doc strings (`#[doc = include_str!(""my_doc.md"")]` eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom). - Paths (`#[namespace = foo::bar] extern ""C++"" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734. If the attribute in question survives expansion then the value is still restricted to unsuffixed literals by a semantic check. This restriction doesn't prevent the use cases listed above so this PR keeps it in place for now. Closes https://github.com/rust-lang/rust/issues/52607. Previous attempt - https://github.com/rust-lang/rust/pull/67121. Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455. Tracking issue - https://github.com/rust-lang/rust/issues/78835.",THUMBS_UP,2021-11-23T13:02:41Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/78843,MERGED,2020-11-07T19:02:18Z,2020-11-08T16:14:33Z,Less verbose debug logging from inlining integrator,tmiasko,e5230fdf9630a672ada85d6848b47819e8c868ee,1,Rollup merge of #78843 - tmiasko:inline-trace r=wesleywiser Less verbose debug logging from inlining integrator The inlining integrator produces relatively verbose and uninteresting logs. Move them from a debug log level to a trace level so that they can be easily isolated from others.,THUMBS_UP,2020-11-07T20:51:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78848,MERGED,2020-11-07T20:06:24Z,2020-11-15T04:51:12Z,Bump minimal supported LLVM version to 9,DevJPM,ae7020fcb4254714d8dbe6246cc0a11fdf9c9de7,13,Rollup merge of #78848 - DevJPM:ci-llvm-9 r=nikic Bump minimal supported LLVM version to 9 This bumps the minimal tested llvm version to 9. This should enable supporting newer LLVM features (and CPU extensions). This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet. This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859). Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.,HEART,2020-11-07T20:07:13Z,panaman67,NA https://github.com/rust-lang/rust/pull/78848,MERGED,2020-11-07T20:06:24Z,2020-11-15T04:51:12Z,Bump minimal supported LLVM version to 9,DevJPM,ae7020fcb4254714d8dbe6246cc0a11fdf9c9de7,13,Rollup merge of #78848 - DevJPM:ci-llvm-9 r=nikic Bump minimal supported LLVM version to 9 This bumps the minimal tested llvm version to 9. This should enable supporting newer LLVM features (and CPU extensions). This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet. This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859). Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.,HEART,2020-11-08T02:21:06Z,marmeladema,NA https://github.com/rust-lang/rust/pull/78848,MERGED,2020-11-07T20:06:24Z,2020-11-15T04:51:12Z,Bump minimal supported LLVM version to 9,DevJPM,ae7020fcb4254714d8dbe6246cc0a11fdf9c9de7,13,Rollup merge of #78848 - DevJPM:ci-llvm-9 r=nikic Bump minimal supported LLVM version to 9 This bumps the minimal tested llvm version to 9. This should enable supporting newer LLVM features (and CPU extensions). This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet. This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859). Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.,HEART,2020-11-13T17:26:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78848,MERGED,2020-11-07T20:06:24Z,2020-11-15T04:51:12Z,Bump minimal supported LLVM version to 9,DevJPM,ae7020fcb4254714d8dbe6246cc0a11fdf9c9de7,13,Rollup merge of #78848 - DevJPM:ci-llvm-9 r=nikic Bump minimal supported LLVM version to 9 This bumps the minimal tested llvm version to 9. This should enable supporting newer LLVM features (and CPU extensions). This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet. This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859). Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.,HEART,2021-01-06T05:34:55Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-08T00:27:39Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-09T22:34:19Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-14T01:17:23Z,estebank,NA https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-15T22:00:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-19T15:12:53Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2020-11-23T12:19:53Z,rrbutani,NA https://github.com/rust-lang/rust/pull/78849,CLOSED,2020-11-07T20:12:19Z,2020-11-16T02:11:58Z,Syntactically permit postfix macros to reject them later,est31,NA,NA,NA,HEART,2021-07-18T16:45:33Z,d4h0,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-07T23:03:20Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-07T23:56:51Z,darksv,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-08T05:50:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-08T06:09:53Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-08T19:05:37Z,panaman67,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-19T17:47:35Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-19T21:02:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-20T08:35:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78857,MERGED,2020-11-07T22:04:53Z,2020-11-13T02:05:11Z,Improve BinaryHeap performance,SkiFire13,40889819ee8bf53aa880bace5ae472bdb84c797d,1,Rollup merge of #78857 - SkiFire13:bheap-opt r=KodrAus Improve BinaryHeap performance By changing the condition in the loops from `child < end` to `child < end - 1` we're guaranteed that `right = child + 1 < end` and since finding the index of the biggest sibling can be done with an arithmetic operation we can remove a branch from the loop body. The case where there's no right child i.e. `child == end - 1` is instead handled outside the loop after it ends; note that if the loops ends early we can use `return` instead of `break` since the check `child == end - 1` will surely fail. I've also removed a call to `<[T]>::swap` that was hiding a bound check that [wasn't being optimized by LLVM](https://godbolt.org/z/zrhdGM). A quick benchmarks on my pc shows that the gains are pretty significant: |name |before ns/iter |after ns/iter |diff ns/iter |diff % |speedup | |---------------------|----------------|---------------|--------------|----------|--------| |find_smallest_1000 | 352 565 | 260 098 | -92 467 | -26.23% | x 1.36 | |from_vec | 676 795 | 473 934 | -202 861 | -29.97% | x 1.43 | |into_sorted_vec | 469 511 | 304 275 | -165 236 | -35.19% | x 1.54 | |pop | 483 198 | 373 778 | -109 420 | -22.64% | x 1.29 | The other 2 benchmarks for `BinaryHeap` (`peek_mut_deref_mut` and `push`) weren't impacted and as such didn't show any significant change.,ROCKET,2020-11-20T19:07:53Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/78860,MERGED,2020-11-07T22:52:09Z,2020-11-08T16:14:30Z,rustc_resolve: Use `#![feature(format_args_capture)]`,petrochenkov,829e88032a66bc7fc7593d3ea2dfb849477a713f,3,Rollup merge of #78860 - petrochenkov:resolvefmt r=Mark-Simulacrum rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.),HEART,2020-11-07T22:59:43Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78860,MERGED,2020-11-07T22:52:09Z,2020-11-08T16:14:30Z,rustc_resolve: Use `#![feature(format_args_capture)]`,petrochenkov,829e88032a66bc7fc7593d3ea2dfb849477a713f,3,Rollup merge of #78860 - petrochenkov:resolvefmt r=Mark-Simulacrum rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.),HEART,2020-11-07T23:34:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78860,MERGED,2020-11-07T22:52:09Z,2020-11-08T16:14:30Z,rustc_resolve: Use `#![feature(format_args_capture)]`,petrochenkov,829e88032a66bc7fc7593d3ea2dfb849477a713f,3,Rollup merge of #78860 - petrochenkov:resolvefmt r=Mark-Simulacrum rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.),HEART,2020-11-07T23:55:54Z,darksv,NA https://github.com/rust-lang/rust/pull/78860,MERGED,2020-11-07T22:52:09Z,2020-11-08T16:14:30Z,rustc_resolve: Use `#![feature(format_args_capture)]`,petrochenkov,829e88032a66bc7fc7593d3ea2dfb849477a713f,3,Rollup merge of #78860 - petrochenkov:resolvefmt r=Mark-Simulacrum rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.),HEART,2020-11-08T12:27:49Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/78860,MERGED,2020-11-07T22:52:09Z,2020-11-08T16:14:30Z,rustc_resolve: Use `#![feature(format_args_capture)]`,petrochenkov,829e88032a66bc7fc7593d3ea2dfb849477a713f,3,Rollup merge of #78860 - petrochenkov:resolvefmt r=Mark-Simulacrum rustc_resolve: Use `#![feature(format_args_capture)]` This is the best new sugar for quite some time. (I only changed places that already used named arguments.),HEART,2020-11-08T18:18:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-08T01:37:08Z,calebzulawski,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-08T06:45:15Z,bjorn3,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-08T16:54:41Z,darksv,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HEART,2020-11-08T19:07:49Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T00:37:40Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T00:38:42Z,zkat,kzm@zkat.tech https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T01:18:30Z,rrbutani,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T09:31:50Z,LukeMathWalker,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T11:16:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HEART,2020-11-11T11:16:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-11-11T13:33:49Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HEART,2020-11-11T13:33:50Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/78863,MERGED,2020-11-08T01:00:12Z,2020-11-29T11:37:42Z,Support repr(simd) on ADTs containing a single array field,KodrAus,760430e6fdd70cdb09b5b6d696905c0ee0ea27c8,17,Auto merge of #78863 - KodrAus:feat/simd-array r=oli-obk Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1([f32; N]); #[repr(simd)] struct S2([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.,HOORAY,2020-12-04T08:49:58Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/78873,MERGED,2020-11-08T11:20:45Z,2020-11-12T00:34:06Z,Add flags customizing behaviour of MIR inlining,tmiasko,919177f7e42f7585bbc8353b942a0feb1b67705e,5,Rollup merge of #78873 - tmiasko:inline-opts r=oli-obk Add flags customizing behaviour of MIR inlining * `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint. Having those as configurable flags makes it possible to experiment with with different inlining thresholds and substantially increase test coverage of MIR inlining when used with increased thresholds (for example necessary to test #78844).,HEART,2020-11-08T12:25:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/78873,MERGED,2020-11-08T11:20:45Z,2020-11-12T00:34:06Z,Add flags customizing behaviour of MIR inlining,tmiasko,919177f7e42f7585bbc8353b942a0feb1b67705e,5,Rollup merge of #78873 - tmiasko:inline-opts r=oli-obk Add flags customizing behaviour of MIR inlining * `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint. Having those as configurable flags makes it possible to experiment with with different inlining thresholds and substantially increase test coverage of MIR inlining when used with increased thresholds (for example necessary to test #78844).,HEART,2020-11-08T19:07:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/78873,MERGED,2020-11-08T11:20:45Z,2020-11-12T00:34:06Z,Add flags customizing behaviour of MIR inlining,tmiasko,919177f7e42f7585bbc8353b942a0feb1b67705e,5,Rollup merge of #78873 - tmiasko:inline-opts r=oli-obk Add flags customizing behaviour of MIR inlining * `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint. Having those as configurable flags makes it possible to experiment with with different inlining thresholds and substantially increase test coverage of MIR inlining when used with increased thresholds (for example necessary to test #78844).,HEART,2020-11-21T15:10:45Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2020-11-09T15:30:45Z,tavianator,tavianator@tavianator.com https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2020-11-10T11:42:00Z,IsaacWoods,NA https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-02-11T10:17:22Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-02-12T07:56:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-02-13T03:01:38Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-02-20T17:32:07Z,tux3,NA https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-03-06T22:08:37Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/78880,MERGED,2020-11-08T15:02:30Z,2021-04-18T22:45:14Z,Add `Unsupported` to `std::io::ErrorKind`,CDirkx,5a4ab26459a1ccf17ef5bb4c841d3ae5517b2890,20,"Auto merge of #78880 - CDirkx:not_supported r=joshtriplett Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just ""an unspecified error occurred"" which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms which I think is not covered by the stability guarantees of the std? User code could depend on this behavior expecting `ErrorKind::Other` however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics e.g. a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago) but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]` however because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.",THUMBS_UP,2021-04-19T13:42:01Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/78884,CLOSED,2020-11-08T18:17:02Z,2020-12-18T03:46:10Z,Avoid no-op when truncating a vector to same size.,flotts,NA,NA,NA,THUMBS_UP,2020-11-08T19:51:14Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/78884,CLOSED,2020-11-08T18:17:02Z,2020-12-18T03:46:10Z,Avoid no-op when truncating a vector to same size.,flotts,NA,NA,NA,THUMBS_UP,2020-11-09T18:33:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78901,MERGED,2020-11-09T17:01:54Z,2021-01-13T07:39:05Z,diagnostics: Note capturing closures can't be coerced to fns,arora-aman,45ba015357b5b2f131c98c83984341640857a650,10,Rollup merge of #78901 - arora-aman:fix_closure_coerce r=estebank diagnostics: Note capturing closures can't be coerced to fns Fixes #72457 fixes #71895 r? `@estebank`,HEART,2020-11-09T18:00:46Z,estebank,NA https://github.com/rust-lang/rust/pull/78901,MERGED,2020-11-09T17:01:54Z,2021-01-13T07:39:05Z,diagnostics: Note capturing closures can't be coerced to fns,arora-aman,45ba015357b5b2f131c98c83984341640857a650,10,Rollup merge of #78901 - arora-aman:fix_closure_coerce r=estebank diagnostics: Note capturing closures can't be coerced to fns Fixes #72457 fixes #71895 r? `@estebank`,HEART,2020-11-27T01:47:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78901,MERGED,2020-11-09T17:01:54Z,2021-01-13T07:39:05Z,diagnostics: Note capturing closures can't be coerced to fns,arora-aman,45ba015357b5b2f131c98c83984341640857a650,10,Rollup merge of #78901 - arora-aman:fix_closure_coerce r=estebank diagnostics: Note capturing closures can't be coerced to fns Fixes #72457 fixes #71895 r? `@estebank`,HEART,2021-01-13T07:40:02Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/78908,MERGED,2020-11-09T19:17:57Z,2020-11-11T04:00:36Z,(rustdoc) [src] link for types defined by macros shows invocation not defintion,liketechnik,a5f549eeb57da430ed48eac4d50256e8579af898,4,Rollup merge of #78908 - liketechnik:fix_macro_expand_src_link r=jyn514 (rustdoc) [src] link for types defined by macros shows invocation not defintion Previously the [src] link on types defined by a macro pointed to the macro definition. This pr makes the Clean-Implementation for Spans aware of macro defined types so that the link points to the invocation instead. I'm not totally sure if it's okay to add the 'macro awareness' in the Clean-Implementation because it erases that knowledge for all following code. Maybe it would be more sensible to add the check only for the link generation at https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/src/librustdoc/html/render/mod.rs#L1619 Closes #39726.,THUMBS_UP,2020-11-09T23:36:48Z,tesuji,NA https://github.com/rust-lang/rust/pull/78908,MERGED,2020-11-09T19:17:57Z,2020-11-11T04:00:36Z,(rustdoc) [src] link for types defined by macros shows invocation not defintion,liketechnik,a5f549eeb57da430ed48eac4d50256e8579af898,4,Rollup merge of #78908 - liketechnik:fix_macro_expand_src_link r=jyn514 (rustdoc) [src] link for types defined by macros shows invocation not defintion Previously the [src] link on types defined by a macro pointed to the macro definition. This pr makes the Clean-Implementation for Spans aware of macro defined types so that the link points to the invocation instead. I'm not totally sure if it's okay to add the 'macro awareness' in the Clean-Implementation because it erases that knowledge for all following code. Maybe it would be more sensible to add the check only for the link generation at https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/src/librustdoc/html/render/mod.rs#L1619 Closes #39726.,THUMBS_UP,2020-11-10T04:14:22Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78912,MERGED,2020-11-09T22:35:35Z,2020-11-11T04:00:35Z,Add macro test for min-const-generics,JulianKnodt,fa4d0f232799a4f83490fc6f2d748dbf62c536c9,3,Rollup merge of #78912 - JulianKnodt:mcg_macro r=lcnr Add macro test for min-const-generics Adds a test which uses a macro inside a block for a const-expression as per #78433 r? `@lcnr`,HEART,2020-11-09T22:45:03Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/78914,CLOSED,2020-11-10T01:15:02Z,2020-11-28T12:25:27Z,Improve wording of error for lifetime that is too short,camelid,NA,NA,NA,THUMBS_UP,2020-11-11T02:40:02Z,arniu,NA https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HEART,2020-11-10T10:31:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HEART,2020-11-10T16:38:01Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,THUMBS_UP,2020-11-10T16:38:04Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HEART,2020-11-10T18:38:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HOORAY,2020-11-10T18:38:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HOORAY,2020-11-11T06:04:59Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HEART,2020-11-11T06:06:17Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/78916,MERGED,2020-11-10T08:50:15Z,2020-11-12T15:34:19Z,extend const generics test suite,lcnr,0cd118d9671f718ce06c8797da6bffb8813a43a6,23,Rollup merge of #78916 - lcnr:const-generics-tests r=varkor extend const generics test suite should implement most of #78433 especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue. r? ``@varkor``,HEART,2020-11-16T22:27:26Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/78923,MERGED,2020-11-10T16:11:51Z,2020-11-12T00:34:02Z,Cleanup and comment intra-doc link pass,jyn514,a8a0c652297c73228a29be7a91c51fa5d6974706,1,Rollup merge of #78923 - jyn514:intra-doc-comments r=Manishearth Cleanup and comment intra-doc link pass r? ```@Manishearth``` cc ```@seeplusplus```,HOORAY,2020-11-10T18:00:46Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78924,MERGED,2020-11-10T18:30:32Z,2020-11-17T09:19:53Z,Make the libstd build script smaller,bjorn3,54508a26eb0595eb8417a4643f2ee572d6ca33d3,5,Auto merge of #78924 - bjorn3:less_sysroot_build_scripts r=Mark-Simulacrum Make the libstd build script smaller Of all sysroot crates currently only compiler_builtins miniz_oxide and std require a build script. compiler_builtins uses to conditionally enable certain features and possibly compile a C version ([source](https://github.com/rust-lang/compiler-builtins/blob/63ccaf11f08fb5d0b39cc33884c5a1a63f547ace/build.rs)) miniz_oxide only uses it to detect if liballoc is supported as the MSRV is 1.34.0 instead of the 1.36.0 which stabilized liballoc ([source](https://github.com/Frommi/miniz_oxide/blob/28514ec09f0b1ce74bfb2d561de52a6652ce377a/miniz_oxide/build.rs)). std now only uses it to enable `freebsd12` when the `RUST_STD_FREEBSD_12_ABI` env var is set to determine if `restricted-std` should be set to set the `STD_ENV_ARCH` env var identical to `CARGO_CFG_TARGET_ARCH` and to unconditionally enable `backtrace_in_libstd`. If all build scripts were to be removed it would be possible for rustc to completely compile it's own sysroot. It currently requires a rustc version that already has an available libstd to compile the build scripts. If rustc can completely compile it's own sysroot rustbuild could be simplified to not forcefully use the bootstrap compiler for build scripts. `@rustbot` modify labels: +T-compiler +libs-impl,THUMBS_UP,2020-11-10T19:12:28Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/78924,MERGED,2020-11-10T18:30:32Z,2020-11-17T09:19:53Z,Make the libstd build script smaller,bjorn3,54508a26eb0595eb8417a4643f2ee572d6ca33d3,5,Auto merge of #78924 - bjorn3:less_sysroot_build_scripts r=Mark-Simulacrum Make the libstd build script smaller Of all sysroot crates currently only compiler_builtins miniz_oxide and std require a build script. compiler_builtins uses to conditionally enable certain features and possibly compile a C version ([source](https://github.com/rust-lang/compiler-builtins/blob/63ccaf11f08fb5d0b39cc33884c5a1a63f547ace/build.rs)) miniz_oxide only uses it to detect if liballoc is supported as the MSRV is 1.34.0 instead of the 1.36.0 which stabilized liballoc ([source](https://github.com/Frommi/miniz_oxide/blob/28514ec09f0b1ce74bfb2d561de52a6652ce377a/miniz_oxide/build.rs)). std now only uses it to enable `freebsd12` when the `RUST_STD_FREEBSD_12_ABI` env var is set to determine if `restricted-std` should be set to set the `STD_ENV_ARCH` env var identical to `CARGO_CFG_TARGET_ARCH` and to unconditionally enable `backtrace_in_libstd`. If all build scripts were to be removed it would be possible for rustc to completely compile it's own sysroot. It currently requires a rustc version that already has an available libstd to compile the build scripts. If rustc can completely compile it's own sysroot rustbuild could be simplified to not forcefully use the bootstrap compiler for build scripts. `@rustbot` modify labels: +T-compiler +libs-impl,EYES,2020-11-11T00:41:46Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/78924,MERGED,2020-11-10T18:30:32Z,2020-11-17T09:19:53Z,Make the libstd build script smaller,bjorn3,54508a26eb0595eb8417a4643f2ee572d6ca33d3,5,Auto merge of #78924 - bjorn3:less_sysroot_build_scripts r=Mark-Simulacrum Make the libstd build script smaller Of all sysroot crates currently only compiler_builtins miniz_oxide and std require a build script. compiler_builtins uses to conditionally enable certain features and possibly compile a C version ([source](https://github.com/rust-lang/compiler-builtins/blob/63ccaf11f08fb5d0b39cc33884c5a1a63f547ace/build.rs)) miniz_oxide only uses it to detect if liballoc is supported as the MSRV is 1.34.0 instead of the 1.36.0 which stabilized liballoc ([source](https://github.com/Frommi/miniz_oxide/blob/28514ec09f0b1ce74bfb2d561de52a6652ce377a/miniz_oxide/build.rs)). std now only uses it to enable `freebsd12` when the `RUST_STD_FREEBSD_12_ABI` env var is set to determine if `restricted-std` should be set to set the `STD_ENV_ARCH` env var identical to `CARGO_CFG_TARGET_ARCH` and to unconditionally enable `backtrace_in_libstd`. If all build scripts were to be removed it would be possible for rustc to completely compile it's own sysroot. It currently requires a rustc version that already has an available libstd to compile the build scripts. If rustc can completely compile it's own sysroot rustbuild could be simplified to not forcefully use the bootstrap compiler for build scripts. `@rustbot` modify labels: +T-compiler +libs-impl,THUMBS_UP,2020-11-15T17:12:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78948,MERGED,2020-11-11T15:52:53Z,2020-11-15T04:51:05Z,test: add `()=()=()=...` to weird-exprs.rs,slanterns,7f7fa9786afe019dec3629093fe7260303a4e4aa,1,Rollup merge of #78948 - slanterns:master r=varkor test: add `()=()=()=...` to weird-exprs.rs Idea from https://github.com/rust-lang/rust/pull/71156#discussion_r410953972 😄 Builds on nightly since https://github.com/rust-lang/rust/pull/78748 has been merged.,LAUGH,2020-11-15T05:18:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/78950,MERGED,2020-11-11T16:53:19Z,2020-11-13T02:05:05Z,Add asm register information for SPIR-V,khyperia,76fa5f25abc02d1e3d97c105a24ecaed619deaf6,3,"Rollup merge of #78950 - khyperia:spirv-asm r=Amanieu Add asm register information for SPIR-V As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture) we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm) at which point the rust-gpu backend can do all the parsing and codegen that is needed. This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway so here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along. I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684) which unfortunately this PR conflicts with that one quite a bit sorry for any merge conflict pain :( --- Some open questions: - What do we call the register class? Some context SPIR-V is an SSA-based IR there are ""instructions"" that create IDs (referred to as `` in the spec) which can be referenced by other instructions. So `reg` isn't exactly accurate they're SSA IDs not re-assignable registers. - What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!` but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point maybe there's a check that prevents the `spirv` target from even reaching that codepath.",ROCKET,2020-11-25T23:39:31Z,akiross,NA https://github.com/rust-lang/rust/pull/78970,MERGED,2020-11-12T03:32:20Z,2020-11-13T02:05:02Z,update rustfmt to v1.4.25,calebcartwright,a2e8fb540dec5616c686b98e5a953e816df4eb5a,2,Rollup merge of #78970 - calebcartwright:update-rustfmt r=Aaron1011 update rustfmt to v1.4.25 Contains changes from https://github.com/rust-lang/rustfmt/pull/4507 r? ``@Aaron1011``,HEART,2020-11-12T04:01:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-12T17:23:19Z,cynecx,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-13T03:08:54Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-18T12:19:58Z,nyuichi,yuichi.nishiwaki@icloud.com https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-23T16:50:08Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-26T20:29:11Z,bobbygebert,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-27T00:24:00Z,taiki-e,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-28T12:59:31Z,vandenheuvel,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-11-30T20:12:14Z,ronlobo,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2020-12-25T23:13:43Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2021-02-09T08:21:20Z,Virgiel,NA https://github.com/rust-lang/rust/pull/78978,CLOSED,2020-11-12T10:53:24Z,2020-12-01T11:55:29Z,WIP Generic associated types in trait paths,b-naber,NA,NA,NA,HOORAY,2021-08-03T20:40:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/78980,MERGED,2020-11-12T12:04:44Z,2020-11-15T04:50:58Z,Fix rustc_ast_pretty print_qpath resulting in invalid macro input,thiolliere,4fcb617cbe6a92dabac763bd38862d2c40b4d247,2,Rollup merge of #78980 - thiolliere:gui-fix-qpath r=estebank Fix rustc_ast_pretty print_qpath resulting in invalid macro input related https://github.com/rust-lang/rust/issues/76874 (third case) ### Issue: The input for a procedural macro is incorrect for the rust code: ```rust mod m { pub trait Tr { type Ts: super::Tu; } } trait Tu { fn dummy() { } } #[may_proc_macro] fn foo() { ::Ts::dummy(); } ``` the macro will get the input: ```rust fn foo() { ::dummy(); } ``` Thus `Ts` has disappeared. ### Fix: This is due to invalid pretty print of qpath. This PR fix it.,THUMBS_UP,2020-11-13T04:47:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/78995,MERGED,2020-11-12T18:23:01Z,2020-11-18T23:45:01Z,Handle empty matches cleanly in exhaustiveness checking,Nadrieril,8256379832b5ecb7f71e8c5e2018446482223c12,9,Auto merge of #78995 - Nadrieril:clean-empty-match r=varkor Handle empty matches cleanly in exhaustiveness checking This removes the special-casing of empty matches that was done in `check_match`. This fixes most of https://github.com/rust-lang/rust/issues/55123. Somewhat unrelatedly I also made `_match.rs` more self-contained because I think it's cleaner. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-11-16T22:09:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79000,MERGED,2020-11-12T20:05:47Z,2020-11-26T16:31:16Z,Move lev_distance to rustc_ast make non-generic,sivadeilra,6fcd589025366e8ae548e039d77a960c337a68c9,16,Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance r=wesleywiser Move lev_distance to rustc_ast make non-generic rustc_ast currently has a few dependencies on rustc_lexer. Ideally an AST would not have any dependency its lexer for minimizing design-time dependencies. Breaking this dependency would also have practical benefits since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency but it does remove one of the sources of this dependency which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol it is easy to move it to rustc_span. It might even be best to move it to a separate crate since other tools such as Cargo use the same algorithm and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries and this function was duplicated for nearly every call site because most call sites used short-lived iterator chains generic over Map and such. But there's no good reason for a function like this to be generic since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket but we have to start reducing binary size and beginning to tame over-use of generics is part of that.,HEART,2020-11-12T20:08:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79000,MERGED,2020-11-12T20:05:47Z,2020-11-26T16:31:16Z,Move lev_distance to rustc_ast make non-generic,sivadeilra,6fcd589025366e8ae548e039d77a960c337a68c9,16,Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance r=wesleywiser Move lev_distance to rustc_ast make non-generic rustc_ast currently has a few dependencies on rustc_lexer. Ideally an AST would not have any dependency its lexer for minimizing design-time dependencies. Breaking this dependency would also have practical benefits since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency but it does remove one of the sources of this dependency which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol it is easy to move it to rustc_span. It might even be best to move it to a separate crate since other tools such as Cargo use the same algorithm and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries and this function was duplicated for nearly every call site because most call sites used short-lived iterator chains generic over Map and such. But there's no good reason for a function like this to be generic since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket but we have to start reducing binary size and beginning to tame over-use of generics is part of that.,HEART,2020-11-24T20:34:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79000,MERGED,2020-11-12T20:05:47Z,2020-11-26T16:31:16Z,Move lev_distance to rustc_ast make non-generic,sivadeilra,6fcd589025366e8ae548e039d77a960c337a68c9,16,Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance r=wesleywiser Move lev_distance to rustc_ast make non-generic rustc_ast currently has a few dependencies on rustc_lexer. Ideally an AST would not have any dependency its lexer for minimizing design-time dependencies. Breaking this dependency would also have practical benefits since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency but it does remove one of the sources of this dependency which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol it is easy to move it to rustc_span. It might even be best to move it to a separate crate since other tools such as Cargo use the same algorithm and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries and this function was duplicated for nearly every call site because most call sites used short-lived iterator chains generic over Map and such. But there's no good reason for a function like this to be generic since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket but we have to start reducing binary size and beginning to tame over-use of generics is part of that.,HEART,2020-11-26T01:40:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79000,MERGED,2020-11-12T20:05:47Z,2020-11-26T16:31:16Z,Move lev_distance to rustc_ast make non-generic,sivadeilra,6fcd589025366e8ae548e039d77a960c337a68c9,16,Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance r=wesleywiser Move lev_distance to rustc_ast make non-generic rustc_ast currently has a few dependencies on rustc_lexer. Ideally an AST would not have any dependency its lexer for minimizing design-time dependencies. Breaking this dependency would also have practical benefits since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency but it does remove one of the sources of this dependency which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol it is easy to move it to rustc_span. It might even be best to move it to a separate crate since other tools such as Cargo use the same algorithm and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries and this function was duplicated for nearly every call site because most call sites used short-lived iterator chains generic over Map and such. But there's no good reason for a function like this to be generic since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket but we have to start reducing binary size and beginning to tame over-use of generics is part of that.,HEART,2020-11-26T07:17:22Z,lnicola,NA https://github.com/rust-lang/rust/pull/79000,MERGED,2020-11-12T20:05:47Z,2020-11-26T16:31:16Z,Move lev_distance to rustc_ast make non-generic,sivadeilra,6fcd589025366e8ae548e039d77a960c337a68c9,16,Rollup merge of #79000 - sivadeilra:user/ardavis/lev_distance r=wesleywiser Move lev_distance to rustc_ast make non-generic rustc_ast currently has a few dependencies on rustc_lexer. Ideally an AST would not have any dependency its lexer for minimizing design-time dependencies. Breaking this dependency would also have practical benefits since modifying rustc_lexer would not trigger a rebuild of rustc_ast. This commit does not remove the rustc_ast --> rustc_lexer dependency but it does remove one of the sources of this dependency which is the code that handles fuzzy matching between symbol names for making suggestions in diagnostics. Since that code depends only on Symbol it is easy to move it to rustc_span. It might even be best to move it to a separate crate since other tools such as Cargo use the same algorithm and have simply contain a duplicate of the code. This changes the signature of find_best_match_for_name so that it is no longer generic over its input. I checked the optimized binaries and this function was duplicated for nearly every call site because most call sites used short-lived iterator chains generic over Map and such. But there's no good reason for a function like this to be generic since all it does is immediately convert the generic input (the Iterator impl) to a concrete Vec. This has all of the costs of generics (duplicated method bodies) with no benefit. Changing find_best_match_for_name to be non-generic removed about 10KB of code from the optimized binary. I know it's a drop in the bucket but we have to start reducing binary size and beginning to tame over-use of generics is part of that.,HEART,2020-11-29T22:48:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79001,CLOSED,2020-11-12T20:55:03Z,2022-03-03T20:30:51Z,Pretty print assertion failures in tests,de-vri-es,NA,NA,NA,THUMBS_UP,2021-01-11T09:26:26Z,jakoschiko,jakob.schikowski@gmx.de https://github.com/rust-lang/rust/pull/79001,CLOSED,2020-11-12T20:55:03Z,2022-03-03T20:30:51Z,Pretty print assertion failures in tests,de-vri-es,NA,NA,NA,THUMBS_UP,2021-07-19T14:30:46Z,Zerotask,NA https://github.com/rust-lang/rust/pull/79006,CLOSED,2020-11-12T22:17:09Z,2020-11-13T22:17:40Z,Add #[must_use] to Option and Result overlap methods,bobrippling,NA,NA,NA,CONFUSED,2020-11-13T08:30:34Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,THUMBS_UP,2020-12-11T09:51:43Z,aschampion,andrew.champion@gmail.com https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,THUMBS_UP,2020-12-11T15:32:28Z,fintelia,fintelia@gmail.com https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,HEART,2021-02-02T11:30:01Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,THUMBS_UP,2021-02-02T13:13:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,THUMBS_UP,2021-07-27T18:26:45Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79015,MERGED,2020-11-13T10:01:21Z,2021-02-02T12:02:55Z,add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate,WaffleLapkin,f6cb45ad01a4518f615926f39801996622f46179,4,Auto merge of #79015 - WaffleLapkin:vec_append_from_within r=KodrAus add `Vec::extend_from_within` method under `vec_extend_from_within` feature gate Implement ### tl;dr This PR adds a `extend_from_within` method to `Vec` which allows copying elements from a range to the end: ```rust #![feature(vec_extend_from_within)] let mut vec = vec![0 1 2 3 4]; vec.extend_from_within(2..); assert_eq!(vec [0 1 2 3 4 2 3 4]); vec.extend_from_within(..2); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1]); vec.extend_from_within(4..8); assert_eq!(vec [0 1 2 3 4 2 3 4 0 1 4 2 3 4]); ``` ### Implementation notes Originally I've copied `@Shnatsel's` [implementation](https://github.com/WanzenBug/rle-decode-helper/blob/690742a0de158d391b7bde1a0c71cccfdad33ab3/src/lib.rs#L74) with some minor changes to support other ranges: ```rust pub fn append_from_within(&mut self src: R) where T: Copy R: RangeBounds { let len = self.len(); let Range { start end } = src.assert_len(len);; let count = end - start; self.reserve(count); unsafe { // This is safe because `reserve()` above succeeded // so `self.len() + count` did not overflow usize ptr::copy_nonoverlapping( self.get_unchecked(src.start) self.as_mut_ptr().add(len) count ); self.set_len(len + count); } } ``` But then I've realized that this duplicates most of the code from (private) `Vec::append_elements` so I've used it instead. Then I've applied `@KodrAus` suggestions from https://github.com/rust-lang/rust/pull/79015#issuecomment-727200852.,HEART,2021-07-27T18:26:46Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HEART,2020-11-13T11:12:45Z,varkor,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-13T13:03:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-13T17:29:55Z,cynecx,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-13T19:30:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-14T19:17:08Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-15T18:44:54Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-16T07:32:13Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-11-20T08:29:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2020-12-20T13:30:42Z,hoodie,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2021-08-01T18:50:26Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HEART,2021-08-01T18:50:27Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79016,MERGED,2020-11-13T10:35:11Z,2020-11-15T15:40:10Z,Make `_` an expression to discard values in destructuring assignments,fanzier,f66af286411956386da9dbb3ca1527ae271ab618,27,Rollup merge of #79016 - fanzier:underscore-expressions r=petrochenkov Make `_` an expression to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909 tracking issue: #71126). This PR is the third and final part of #71156 which was split up to allow for easier review. With this PR an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value similarly to the wildcard `_` in patterns. For instance ```rust (a _) = (1 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation particularly around pre-expansion gating. r? ````@petrochenkov````,HOORAY,2022-06-13T23:47:49Z,rooooooooob,NA https://github.com/rust-lang/rust/pull/79022,MERGED,2020-11-13T17:08:29Z,2020-12-26T06:43:58Z,stabilize deque_range,SpyrosRoum,d30dac2d839293f2c48e18ebfea1082819115d08,2,Auto merge of #79022 - SpyrosRoum:stabilize-deque_range r=m-ou-se stabilize deque_range Make #74217 stable stabilizing `VecDeque::range` and `VecDeque::range_mut`. Pr: #74099 r? `@m-ou-se`,HOORAY,2020-12-31T04:25:33Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T18:29:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T18:29:12Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T18:40:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T18:52:32Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T19:02:36Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T20:03:28Z,LukeMathWalker,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-13T23:24:51Z,jbr,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T02:32:36Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T09:30:41Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-14T09:30:43Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2020-11-14T09:30:45Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-14T09:30:47Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",LAUGH,2020-11-14T09:30:51Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T11:41:39Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-14T11:41:41Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T15:45:05Z,Keruspe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2020-11-14T15:45:06Z,Keruspe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T17:53:47Z,de-sh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-14T18:39:36Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",LAUGH,2020-11-14T18:39:38Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-14T18:39:41Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-14T18:39:42Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2020-11-14T18:39:43Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",EYES,2020-11-14T18:39:50Z,szagi3891,szeligagrzegorz@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-14T20:44:10Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-14T21:15:24Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-15T20:57:52Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-15T22:00:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-15T22:35:32Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",LAUGH,2020-11-15T22:35:32Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-15T22:35:33Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-15T22:35:34Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",EYES,2020-11-15T22:35:36Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2020-11-15T22:35:37Z,kennetpostigo,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-16T02:04:56Z,uvd,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-16T18:45:28Z,Nashenas88,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2020-11-18T18:01:40Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2020-11-19T18:01:36Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-19T23:25:40Z,estebank,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-26T05:21:43Z,leaxoy,lixiaohui0812@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2020-11-27T06:43:38Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-11-30T08:38:03Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-12-14T12:10:03Z,dyc3,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-12-18T23:31:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2020-12-23T18:55:41Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-06T08:40:18Z,agourlay,arnaud.gourlay@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-01-30T15:17:09Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-30T15:36:33Z,CrockAgile,crockagile@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-30T16:45:24Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-30T17:28:59Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-30T17:29:00Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-30T19:24:26Z,nilslice,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-30T19:24:27Z,nilslice,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-30T22:34:55Z,cbourjau,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-31T02:33:52Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-01-31T04:39:54Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-31T05:30:23Z,numToStr,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-01-31T08:40:34Z,peddermaster2,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-31T12:03:39Z,616b2f,616b2f@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-01-31T14:00:46Z,lostintime,lostintime.dev@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-02-01T07:03:25Z,Folyd,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-02-01T14:41:32Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-02-03T05:12:15Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-03T05:12:17Z,msathis,sathis62@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-03T17:43:29Z,SilvanCodes,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-04T18:26:43Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",EYES,2021-02-04T21:29:27Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-04T21:29:28Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",LAUGH,2021-02-04T21:29:30Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-02-04T21:29:31Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-02-04T21:29:33Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-02-04T21:29:34Z,chertov,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-05T00:15:05Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-02-05T05:40:46Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-02-05T10:48:54Z,teh-cmc,cr.rey.clement@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-05T11:08:40Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-02-08T17:26:27Z,robjtede,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-09T07:33:31Z,mibo-fdc,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-02-09T07:33:35Z,mibo-fdc,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-19T19:25:54Z,trevyn,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-02-22T15:06:15Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-02-22T15:06:16Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-02-22T15:06:16Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-02-22T15:06:16Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",EYES,2021-02-22T15:06:17Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-04-01T00:14:37Z,brainstorm,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-04-01T00:14:38Z,brainstorm,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-09-14T18:57:34Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HOORAY,2021-09-14T18:57:36Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",HEART,2021-09-14T18:57:37Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-09-14T18:57:38Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",THUMBS_UP,2021-10-13T05:32:58Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/79023,MERGED,2020-11-13T17:56:35Z,2021-01-30T13:58:15Z,Add `core::stream::Stream`,yoshuawuyts,ecd7cb1c3ab5d7e7b10f934a561b8a6958bcd1b0,7,"Rollup merge of #79023 - yoshuawuyts:stream r=KodrAus Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html) [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html) and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as ""infinite streams"" and ""laziness"" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = ""future_trait""]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream Next}` and re-exports it from `std` as `std::stream::{Stream Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````",ROCKET,2021-10-13T05:33:02Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-11-13T18:31:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-11-13T20:43:12Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-11-20T02:16:59Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-11-20T08:35:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-11-20T19:39:21Z,jplatte,NA https://github.com/rust-lang/rust/pull/79026,MERGED,2020-11-13T18:30:02Z,2020-11-15T15:40:08Z,Implement BTreeMap::retain and BTreeSet::retain,mbrubeck,aa685e2024874860c71887c4e18d916f1d989af8,4,Rollup merge of #79026 - mbrubeck:btree_retain r=m-ou-se Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain` which were implemented in #39560 and stabilized in #36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable behind the `btree_retain` feature gate with tracking issue #79025. See also rust-lang/rfcs#1338.,HEART,2020-12-14T15:44:13Z,leoschwarz,NA https://github.com/rust-lang/rust/pull/79043,CLOSED,2020-11-14T13:58:47Z,2020-11-15T00:05:26Z,Build the compiler with -Ctarget-cpu=x86-64-v2,est31,NA,NA,NA,THUMBS_UP,2020-11-14T15:24:05Z,mati865,NA https://github.com/rust-lang/rust/pull/79046,CLOSED,2020-11-14T16:12:22Z,2021-01-07T22:35:02Z,Move stable hasher out of rustc_middle,cjgillot,NA,NA,NA,HEART,2020-11-15T11:09:49Z,est31,NA https://github.com/rust-lang/rust/pull/79046,CLOSED,2020-11-14T16:12:22Z,2021-01-07T22:35:02Z,Move stable hasher out of rustc_middle,cjgillot,NA,NA,NA,HEART,2020-11-15T17:34:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-14T17:29:20Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-14T17:57:31Z,mati865,NA https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-15T00:26:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-15T12:43:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-15T22:59:14Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-11-20T06:39:19Z,tesuji,NA https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2020-12-22T12:31:35Z,lqd,NA https://github.com/rust-lang/rust/pull/79049,MERGED,2020-11-14T17:16:51Z,2020-11-15T00:47:46Z,Lower intrinsics calls: forget size_of unreachable wrapping_*,tmiasko,361c4ea22486557ec50c4fc6a93d60e7476ecbea,10,Auto merge of #79049 - tmiasko:lower-intrinsics r=jonas-schievink Lower intrinsics calls: forget size_of unreachable wrapping_* This allows constant propagation to evaluate `size_of` and `wrapping_*` and unreachable propagation to propagate a call to `unreachable`. The lowering is performed as a MIR optimization rather than during MIR building to preserve the special status of intrinsics with respect to unsafety checks and promotion. Currently enabled by default to determine the performance impact (no significant impact expected). In practice only useful when combined with inlining since intrinsics are rarely used directly (with exception of `unreachable` and `discriminant_value` used by built-in derive macros). Closes #32716.,HOORAY,2021-11-01T09:49:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-16T00:28:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-16T07:34:48Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-16T12:03:15Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-18T09:14:15Z,hrkz,hugo.frezat@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-18T12:26:39Z,JeanCASPAR,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-18T14:31:14Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,THUMBS_UP,2020-11-18T14:31:16Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-19T08:24:25Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-19T12:21:06Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-22T21:15:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-11-26T14:15:29Z,Azorlogh,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-10T06:51:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-19T00:59:08Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-21T18:43:06Z,varkor,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-22T11:12:10Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HEART,2020-12-22T11:12:13Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-24T07:14:45Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-25T07:57:33Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HOORAY,2020-12-30T01:33:29Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,THUMBS_UP,2021-01-10T10:22:34Z,trevyn,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,THUMBS_UP,2022-06-06T22:39:32Z,jeroen-meijer,NA https://github.com/rust-lang/rust/pull/79051,MERGED,2020-11-14T19:14:05Z,2020-12-17T06:00:21Z,Implement if-let match guards,LeSeulArtichaut,1e1ba7c936ac3c83c3831b493ab138b7e180a0b6,27,Rollup merge of #79051 - LeSeulArtichaut:if-let-guard r=matthewjasper Implement if-let match guards Implements rust-lang/rfcs#2294 (tracking issue: #51114). I probably should do a few more things before this can be merged: - [x] Add tests (added basic tests more advanced tests could be done in the future?) - [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements) - [x] Fix clippy However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs. Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this? r? `@ghost` for now,HEART,2022-06-06T22:39:34Z,jeroen-meijer,NA https://github.com/rust-lang/rust/pull/79064,MERGED,2020-11-15T01:58:33Z,2020-11-15T18:21:51Z,Fix displaying errors when rustbook tests fail.,ehuss,603ab5bd6e0ffefafa7411cd8bd23a6ca82bcff0,3,Auto merge of #79064 - ehuss:rustbook-logs r=Mark-Simulacrum Fix displaying errors when rustbook tests fail. This ensures that output from mdbook is displayed when running the rustbook wrapper. I believe this was a regression as a result of #69115 where it was changed from running `rustdoc` directly to using rustbook.,HEART,2020-11-15T02:02:36Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-15T14:08:16Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-15T16:42:19Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-15T19:31:40Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-16T06:06:00Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-16T18:52:33Z,estebank,NA https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,THUMBS_UP,2020-11-26T03:29:55Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79072,MERGED,2020-11-15T13:05:28Z,2020-11-17T17:50:23Z,Fix exhaustiveness in case a byte string literal is used at slice type,oli-obk,b6f52410bbdb3cc48abba8d7010db9c9c6fdc570,7,Rollup merge of #79072 - oli-obk:byte_str_pat r=estebank Fix exhaustiveness in case a byte string literal is used at slice type fixes #79048,HOORAY,2020-11-28T12:40:49Z,tesuji,NA https://github.com/rust-lang/rust/pull/79073,MERGED,2020-11-15T13:36:26Z,2020-12-19T07:23:40Z,passes: prohibit invalid attrs on generic params,davidtwco,3d9ada686fb42bd036b3a4916526f413f1d5d1f8,6,Auto merge of #79073 - davidtwco:issue-78957-const-param-attrs r=lcnr passes: prohibit invalid attrs on generic params Fixes #78957. This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity. r? `@lcnr`,HEART,2020-11-15T17:37:41Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/79073,MERGED,2020-11-15T13:36:26Z,2020-12-19T07:23:40Z,passes: prohibit invalid attrs on generic params,davidtwco,3d9ada686fb42bd036b3a4916526f413f1d5d1f8,6,Auto merge of #79073 - davidtwco:issue-78957-const-param-attrs r=lcnr passes: prohibit invalid attrs on generic params Fixes #78957. This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity. r? `@lcnr`,HEART,2020-12-17T03:57:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79073,MERGED,2020-11-15T13:36:26Z,2020-12-19T07:23:40Z,passes: prohibit invalid attrs on generic params,davidtwco,3d9ada686fb42bd036b3a4916526f413f1d5d1f8,6,Auto merge of #79073 - davidtwco:issue-78957-const-param-attrs r=lcnr passes: prohibit invalid attrs on generic params Fixes #78957. This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity. r? `@lcnr`,HEART,2020-12-18T18:50:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79074,MERGED,2020-11-15T14:01:47Z,2020-11-16T03:22:13Z,Install CI llvm into the library directory,Mark-Simulacrum,f4d014cee77f9112b2582d86085631c74413eb1e,1,Auto merge of #79074 - Mark-Simulacrum:fix-ci-llvm r=jyn514 Install CI llvm into the library directory In other words my concern in https://github.com/rust-lang/rust/issues/78932#issuecomment-725781767 was perfectly justified by something we were already doing. For now just special case CI LLVM but in the future we may want a more general fix. Fixes #79071. r? `@alexcrichton`,HEART,2020-11-15T23:52:43Z,est31,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-11-19T04:09:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-11-19T06:56:59Z,est31,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-11-30T21:43:54Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-11-30T21:44:56Z,estebank,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-12-02T14:51:00Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-12-04T08:56:41Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2020-12-20T13:09:29Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-05T18:57:02Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-09T16:05:06Z,varkor,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-11T18:46:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-28T07:40:40Z,bstrie,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-28T08:40:02Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-28T09:21:14Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-01-29T03:03:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-02T18:16:15Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-04T12:25:46Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-04T19:56:32Z,tux3,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-04T22:06:10Z,lukechu10,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-06T17:27:16Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-09T10:13:46Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-02-11T02:39:16Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79078,MERGED,2020-11-15T19:33:14Z,2021-02-07T22:25:15Z,expand/resolve: Turn `#[derive]` into a regular macro attribute,petrochenkov,9778068cbc1e06cc3685422323ff38a2f397de26,65,"Auto merge of #79078 - petrochenkov:derattr r=Aaron1011 expand/resolve: Turn `#[derive]` into a regular macro attribute This PR turns `#[derive]` into a regular attribute macro declared in libcore and defined in `rustc_builtin_macros` like it was previously done with other ""active"" attributes in https://github.com/rust-lang/rust/pull/62086 https://github.com/rust-lang/rust/pull/62735 and other PRs. This PR is also a continuation of #65252 #69870 and other PRs linked from them which layed the ground for converting `#[derive]` specifically. `#[derive]` still asks `rustc_resolve` to resolve paths inside `derive(...)` and `rustc_expand` gets those resolution results through some backdoor (which I'll try to address later) but otherwise `#[derive]` is treated as any other macro attributes which simplifies the resolution-expansion infra pretty significantly. The change has several observable effects on language and library. Some of the language changes are **feature-gated** by [`feature(macro_attributes_in_derive_output)`](https://github.com/rust-lang/rust/issues/81119). #### Library - `derive` is now available through standard library as `{core std}::prelude::v1::derive`. #### Language - `derive` now goes through name resolution so it can now be renamed - `use derive as my_derive; #[my_derive(Debug)] struct S;`. - `derive` now goes through name resolution so this resolution can fail in corner cases. Crater found one such regression where import `use foo as derive` goes into a cycle with `#[derive(Something)]`. - **[feature-gated]** `#[derive]` is now expanded as any other attributes in left-to-right order. This allows to remove the restriction on other macro attributes following `#[derive]` (https://github.com/rust-lang/reference/issues/566). The following macro attributes become a part of the derive's input (this is not a change non-macro attributes following `#[derive]` were treated in the same way previously). - `#[derive]` is now expanded as any other attributes in left-to-right order. This means two derive attributes `#[derive(Foo)] #[derive(Bar)]` are now expanded separately rather than together. It doesn't generally make difference except for esoteric cases. For example `#[derive(Foo)]` can now produce an import bringing `Bar` into scope but previously both `Foo` and `Bar` were required to be resolved before expanding any of them. - **[feature-gated]** `#[derive()]` (with empty list in parentheses) actually becomes useful. For historical reasons `#[derive]` *fully configures* its input eagerly evaluating `cfg` everywhere in its target for example on fields. Expansion infra doesn't do that for other attributes but now when macro attributes attributes are allowed to be written after `#[derive]` it means that derive can *fully configure* items for them. ```rust #[derive()] #[my_attr] struct S { #[cfg(FALSE)] // this field in removed by `#[derive()]` and not observed by `#[my_attr]` field: u8 } ``` - `#[derive]` on some non-item targets is now prohibited. This was accidentally allowed as noop in the past but was warned about since early 2018 (#50092) despite that crater found a few such cases in unmaintained crates. - Derive helper attributes used before their introduction are now reported with a deprecation lint. This change is long overdue (since macro modularization https://github.com/rust-lang/rust/issues/52226#issuecomment-422605033) but it was hard to do without fixing expansion order for derives. The deprecation is tracked by #79202. ```rust #[trait_helper] // warning: derive helper attribute is used before it is introduced #[derive(Trait)] struct S {} ``` Crater analysis: https://github.com/rust-lang/rust/pull/79078#issuecomment-731436821",HOORAY,2021-05-31T16:00:32Z,MihirLuthra,luthramihir708@gmail.com https://github.com/rust-lang/rust/pull/79088,MERGED,2020-11-16T03:41:15Z,2020-11-17T12:01:48Z,clarify `span_label` documentation,euclio,c459ab3a0f6ddb980d03abf68ed08ffd1bf41307,1,Rollup merge of #79088 - euclio:span-label-doc r=estebank clarify `span_label` documentation Fixes #71857. r? ``@estebank`` cc ``@RalfJung``,HEART,2020-11-16T09:48:47Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79088,MERGED,2020-11-16T03:41:15Z,2020-11-17T12:01:48Z,clarify `span_label` documentation,euclio,c459ab3a0f6ddb980d03abf68ed08ffd1bf41307,1,Rollup merge of #79088 - euclio:span-label-doc r=estebank clarify `span_label` documentation Fixes #71857. r? ``@estebank`` cc ``@RalfJung``,HEART,2020-11-16T19:48:20Z,estebank,NA https://github.com/rust-lang/rust/pull/79091,MERGED,2020-11-16T09:52:59Z,2020-11-16T12:25:45Z,Rust 1.48.0 stable release,pietroalbini,e619caf2c9257f2e3408e67c725b699547c4bfd5,5,Auto merge of #79091 - pietroalbini:stable-next r=pietroalbini Rust 1.48.0 stable release This PR bumps the 1.48 beta branch to the 1.48 stable branch and applies these last minute backports: * #77939 - Ensure that the source code display is working with DOS backline * #77508 - Fix capitalization in blog post name * #78559 - Add LLVM upgrades from 7 to 10 to RELEASES.md * #78364 - Update RELEASES.md for 1.48.0 r? `@ghost` cc `@rust-lang/release`,HOORAY,2020-11-16T10:37:21Z,smmalis37,NA https://github.com/rust-lang/rust/pull/79091,MERGED,2020-11-16T09:52:59Z,2020-11-16T12:25:45Z,Rust 1.48.0 stable release,pietroalbini,e619caf2c9257f2e3408e67c725b699547c4bfd5,5,Auto merge of #79091 - pietroalbini:stable-next r=pietroalbini Rust 1.48.0 stable release This PR bumps the 1.48 beta branch to the 1.48 stable branch and applies these last minute backports: * #77939 - Ensure that the source code display is working with DOS backline * #77508 - Fix capitalization in blog post name * #78559 - Add LLVM upgrades from 7 to 10 to RELEASES.md * #78364 - Update RELEASES.md for 1.48.0 r? `@ghost` cc `@rust-lang/release`,HOORAY,2020-11-16T10:51:33Z,trevyn,NA https://github.com/rust-lang/rust/pull/79091,MERGED,2020-11-16T09:52:59Z,2020-11-16T12:25:45Z,Rust 1.48.0 stable release,pietroalbini,e619caf2c9257f2e3408e67c725b699547c4bfd5,5,Auto merge of #79091 - pietroalbini:stable-next r=pietroalbini Rust 1.48.0 stable release This PR bumps the 1.48 beta branch to the 1.48 stable branch and applies these last minute backports: * #77939 - Ensure that the source code display is working with DOS backline * #77508 - Fix capitalization in blog post name * #78559 - Add LLVM upgrades from 7 to 10 to RELEASES.md * #78364 - Update RELEASES.md for 1.48.0 r? `@ghost` cc `@rust-lang/release`,HOORAY,2020-11-16T13:28:34Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79091,MERGED,2020-11-16T09:52:59Z,2020-11-16T12:25:45Z,Rust 1.48.0 stable release,pietroalbini,e619caf2c9257f2e3408e67c725b699547c4bfd5,5,Auto merge of #79091 - pietroalbini:stable-next r=pietroalbini Rust 1.48.0 stable release This PR bumps the 1.48 beta branch to the 1.48 stable branch and applies these last minute backports: * #77939 - Ensure that the source code display is working with DOS backline * #77508 - Fix capitalization in blog post name * #78559 - Add LLVM upgrades from 7 to 10 to RELEASES.md * #78364 - Update RELEASES.md for 1.48.0 r? `@ghost` cc `@rust-lang/release`,HOORAY,2020-11-16T19:09:27Z,camelid,NA https://github.com/rust-lang/rust/pull/79094,MERGED,2020-11-16T11:08:32Z,2020-11-19T19:50:24Z,Add //ignore-macos to pretty-std-collections.rs,est31,552d8c5cb1371c7d3793e8907f9cbc868e509031,1,Rollup merge of #79094 - est31:ignore_macos r=pietroalbini Add //ignore-macos to pretty-std-collections.rs On macOS the test is flaky and sometimes fails sometimes succeeds on CI. This is no fix for the underlying issue but I feel the workaround is worth it as the issue makes it harder to get things merged into master. cc #78665,THUMBS_UP,2020-11-16T11:13:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/79094,MERGED,2020-11-16T11:08:32Z,2020-11-19T19:50:24Z,Add //ignore-macos to pretty-std-collections.rs,est31,552d8c5cb1371c7d3793e8907f9cbc868e509031,1,Rollup merge of #79094 - est31:ignore_macos r=pietroalbini Add //ignore-macos to pretty-std-collections.rs On macOS the test is flaky and sometimes fails sometimes succeeds on CI. This is no fix for the underlying issue but I feel the workaround is worth it as the issue makes it harder to get things merged into master. cc #78665,THUMBS_UP,2020-11-19T03:42:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79100,MERGED,2020-11-16T15:00:37Z,2021-02-21T08:22:13Z,Improve assert_eq! and assert_ne!,a1phyr,ed58a2b03b6284b070fae2349898b16df98b7765,15,Auto merge of #79100 - a1phyr:better_assert_eq r=m-ou-se Improve assert_eq! and assert_ne! This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function. It does not change the fast path but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining. Moreover the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code. Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \ Updated: https://rust.godbolt.org/z/bzE84x,ROCKET,2021-02-22T09:12:58Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/79100,MERGED,2020-11-16T15:00:37Z,2021-02-21T08:22:13Z,Improve assert_eq! and assert_ne!,a1phyr,ed58a2b03b6284b070fae2349898b16df98b7765,15,Auto merge of #79100 - a1phyr:better_assert_eq r=m-ou-se Improve assert_eq! and assert_ne! This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function. It does not change the fast path but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining. Moreover the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code. Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \ Updated: https://rust.godbolt.org/z/bzE84x,THUMBS_UP,2021-02-25T14:52:03Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79100,MERGED,2020-11-16T15:00:37Z,2021-02-21T08:22:13Z,Improve assert_eq! and assert_ne!,a1phyr,ed58a2b03b6284b070fae2349898b16df98b7765,15,Auto merge of #79100 - a1phyr:better_assert_eq r=m-ou-se Improve assert_eq! and assert_ne! This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function. It does not change the fast path but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining. Moreover the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code. Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \ Updated: https://rust.godbolt.org/z/bzE84x,HEART,2021-02-26T12:22:17Z,krdln,NA https://github.com/rust-lang/rust/pull/79100,MERGED,2020-11-16T15:00:37Z,2021-02-21T08:22:13Z,Improve assert_eq! and assert_ne!,a1phyr,ed58a2b03b6284b070fae2349898b16df98b7765,15,Auto merge of #79100 - a1phyr:better_assert_eq r=m-ou-se Improve assert_eq! and assert_ne! This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function. It does not change the fast path but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining. Moreover the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code. Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \ Updated: https://rust.godbolt.org/z/bzE84x,HEART,2021-03-14T21:35:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79110,MERGED,2020-11-16T19:44:54Z,2020-11-19T19:50:24Z,Remove redundant notes in E0275,estebank,470f768c97ff50c3e317bbeb02f83e6fddc075aa,6,Rollup merge of #79110 - estebank:issue-58964 r=oli-obk Remove redundant notes in E0275 Fix #58964.,HEART,2020-11-16T19:46:31Z,camelid,NA https://github.com/rust-lang/rust/pull/79110,MERGED,2020-11-16T19:44:54Z,2020-11-19T19:50:24Z,Remove redundant notes in E0275,estebank,470f768c97ff50c3e317bbeb02f83e6fddc075aa,6,Rollup merge of #79110 - estebank:issue-58964 r=oli-obk Remove redundant notes in E0275 Fix #58964.,HEART,2020-11-19T09:34:52Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79114,MERGED,2020-11-16T22:06:18Z,2020-11-18T20:36:42Z,add trailing_zeros and leading_zeros to non zero types,andjo403,126d88bd12b1519847dc86a5f74d11ce5136f599,4,Rollup merge of #79114 - andjo403:nonzero_leading_trailing_zeros r=m-ou-se add trailing_zeros and leading_zeros to non zero types as a way towards being able to use the optimized intrinsics ctlz_nonzero and cttz_nonzero from stable. have not crated any tracking issue if this is not a solution that is wanted,THUMBS_UP,2020-11-16T22:12:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79114,MERGED,2020-11-16T22:06:18Z,2020-11-18T20:36:42Z,add trailing_zeros and leading_zeros to non zero types,andjo403,126d88bd12b1519847dc86a5f74d11ce5136f599,4,Rollup merge of #79114 - andjo403:nonzero_leading_trailing_zeros r=m-ou-se add trailing_zeros and leading_zeros to non zero types as a way towards being able to use the optimized intrinsics ctlz_nonzero and cttz_nonzero from stable. have not crated any tracking issue if this is not a solution that is wanted,THUMBS_UP,2020-11-17T09:25:16Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79114,MERGED,2020-11-16T22:06:18Z,2020-11-18T20:36:42Z,add trailing_zeros and leading_zeros to non zero types,andjo403,126d88bd12b1519847dc86a5f74d11ce5136f599,4,Rollup merge of #79114 - andjo403:nonzero_leading_trailing_zeros r=m-ou-se add trailing_zeros and leading_zeros to non zero types as a way towards being able to use the optimized intrinsics ctlz_nonzero and cttz_nonzero from stable. have not crated any tracking issue if this is not a solution that is wanted,THUMBS_UP,2020-11-17T18:06:33Z,trevyn,NA https://github.com/rust-lang/rust/pull/79115,MERGED,2020-11-16T22:12:47Z,2020-11-21T18:05:08Z,x.py: allow a custom string appended to the version,cuviper,d806d656578c2d6b34cf96809862e8cffb293a68,4,Auto merge of #79115 - cuviper:rust-description r=Mark-Simulacrum x.py: allow a custom string appended to the version This adds `rust.description` to the config as a descriptive string to be appended to `rustc --version` output which is also used in places like debuginfo `DW_AT_producer`. This may be useful for supplementary build information like distro-specific package versions. For example in Fedora 33 `gcc --version` outputs: gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6) With this change we can add similar vendor info to `rustc --version`.,THUMBS_UP,2020-11-20T07:46:00Z,mati865,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-11-20T04:50:59Z,CDirkx,christiaan@dirkx.email https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,HEART,2020-11-20T07:23:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-11T16:45:36Z,SOF3,sofe2038@gmail.com https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-17T03:54:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,HEART,2020-12-17T03:54:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,EYES,2020-12-17T04:42:21Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-20T23:16:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-23T01:43:09Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,HEART,2020-12-25T18:00:48Z,daboross,daboross@daboross.net https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-26T09:50:34Z,thomasheartman,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-30T13:24:47Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2020-12-31T07:59:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,HEART,2020-12-31T11:51:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,THUMBS_UP,2021-04-22T01:54:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79134,MERGED,2020-11-17T12:34:34Z,2020-12-27T16:03:06Z,Add `impl Div for u{0}` which cannot panic,ohadravid,2fab3214352e13046c808c066672770df8427d97,2,Auto merge of #79134 - ohadravid:nzint-div r=dtolnay Add `impl Div for u{0}` which cannot panic Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)): ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y.get() } ``` which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor i:(fontScale:14 j:1 lang:rust selection:(endColumn:2 endLineNumber:6 positionColumn:2 positionLineNumber:6 selectionStartColumn:2 selectionStartLineNumber:6 startColumn:2 startLineNumber:6) source:%27pub+fn+div(x:+u32 +y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32 +y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27) l:%275%27 n:%270%27 o:%27Rust+source+%231%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27) (g:!((h:compiler i:(compiler:r1470 filters:(b:%270%27 binary:%271%27 commentOnly:%270%27 demangle:%270%27 directives:%270%27 execute:%271%27 intel:%270%27 libraryCode:%271%27 trim:%271%27) fontScale:14 j:1 lang:rust libs:!() options:%27-O%27 selection:(endColumn:1 endLineNumber:1 positionColumn:1 positionLineNumber:1 selectionStartColumn:1 selectionStartLineNumber:1 startColumn:1 startLineNumber:1) source:1) l:%275%27 n:%270%27 o:%27rustc+1.47.0+(Editor+%231 +Compiler+%231)+Rust%27 t:%270%27)) k:50 l:%274%27 n:%270%27 o:%27%27 s:0 t:%270%27)) l:%272%27 n:%270%27 o:%27%27 t:%270%27)) version:4). Avoiding the `panic` currently requires `unsafe` code. This PR adds an `impl Div for u{0}` (and `impl Rem for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks making the following code compile: ``` pub fn safe_div(x: u32 y: std::num::NonZeroU32) -> u32 { x / y } pub fn safe_rem(x: u32 y: std::num::NonZeroU32) -> u32 { x % y } ``` The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460). I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed. Following `@dtolnay` template from a similar issue: this adds the following **stable** impls which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge: ``` impl Div for u8 { type Output = u8; } impl Rem for u8 { type Output = u8; } ``` and equivalent for u16 u32 u64 u128 usize but **not** for i8 i16 i32 i64 i128 isize (since -1/MIN is undefined). r? `@dtolnay`,HEART,2021-04-22T01:54:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:06:02Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:06:04Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:08:15Z,jbit,jbit@jbit.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:08:18Z,jbit,jbit@jbit.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:12:47Z,Randl,zheltonozhskiy@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:13:26Z,varkor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:14:50Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:14:50Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:18:20Z,CryZe,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:18:21Z,CryZe,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:20:57Z,est31,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:20:58Z,est31,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:24:35Z,korken89,emil.fresk@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:24:36Z,korken89,emil.fresk@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:25:31Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:25:32Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:25:35Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:25:38Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T13:25:41Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:25:42Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:31:04Z,bugadani,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:31:24Z,ordian,noreply@reusable.software https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:32:10Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:32:11Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:32:12Z,burdges,burdges@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:32:14Z,darksv,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:32:16Z,darksv,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:32:18Z,darksv,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T13:32:19Z,darksv,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:33:14Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:33:25Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:35:20Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:41:14Z,jplatte,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:41:15Z,jplatte,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:41:18Z,jplatte,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:41:55Z,joseluis,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:42:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:42:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T13:45:54Z,arniu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:45:56Z,arniu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:46:04Z,arniu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:46:15Z,arniu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T13:47:45Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T13:47:46Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:47:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T13:47:47Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T13:50:01Z,bes,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T13:52:53Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T14:00:44Z,fluxxu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:00:45Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:00:46Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T14:00:46Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:00:48Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:03:57Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T14:03:59Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:04:00Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:04:01Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:08:57Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:11:48Z,diondokter,diondokter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:11:54Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:11:56Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:11:56Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:17:19Z,Cupnfish,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:21:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:21:20Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:21:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:32:14Z,Yatekii,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:32:18Z,Yatekii,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:42:03Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:42:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:42:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T14:42:07Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:43:13Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:43:15Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:43:17Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T14:43:18Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:47:40Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:49:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:49:17Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T14:49:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T14:55:29Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T14:55:30Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:01:04Z,lqd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T15:01:06Z,lqd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:01:08Z,lqd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:04:30Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:04:32Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:05:06Z,Muqito,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T15:05:08Z,Muqito,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:05:10Z,Muqito,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:05:32Z,NieDzejkob,kuba@kadziolka.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:06:40Z,light4,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:13:56Z,pvdrz,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T15:14:44Z,huitseeker,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T15:19:22Z,Halbeard,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:19:29Z,Halbeard,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:27:57Z,rth,roman.yurchak@symerio.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:33:34Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T15:33:36Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:33:37Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:42:15Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T15:42:16Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T15:42:17Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:42:17Z,withoutboats,saoirse@without.boats https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:46:13Z,bpot,bobby.potter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T15:54:51Z,mattjohnruss,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T15:54:54Z,mattjohnruss,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:54:54Z,mattjohnruss,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T15:54:55Z,mattjohnruss,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T15:58:24Z,adwhit,adwhit@fastmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:01:06Z,cwfitzgerald,connorwadefitzgerald@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:02:47Z,est31,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T16:02:49Z,est31,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:09:13Z,DevJPM,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T16:09:14Z,DevJPM,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:10:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T16:10:28Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:10:29Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:10:30Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:12:04Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:12:11Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:18:36Z,alexkirsz,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:18:37Z,alexkirsz,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:20:15Z,basile-henry,bjm.henry@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:21:13Z,caemor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:21:14Z,caemor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:25:59Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:26:00Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:48:50Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T16:49:10Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T16:49:12Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T16:49:13Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T16:49:14Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:04:46Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:04:48Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:05:15Z,icewind1991,robin@icewind.nl https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:07:36Z,TehPers,tehperz@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:12:00Z,tux3,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:12:04Z,tux3,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:12:06Z,tux3,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:14:47Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:14:47Z,infinityb,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:14:49Z,infinityb,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:20:05Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:20:05Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:20:08Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:20:09Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:20:57Z,cdstanford,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:20:58Z,cdstanford,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:20:59Z,cdstanford,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:30:15Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:30:17Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:30:18Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:30:19Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:30:29Z,cynecx,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:30:30Z,cynecx,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:30:31Z,cynecx,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:30:31Z,cynecx,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:40:50Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:40:50Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:40:50Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:40:53Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:41:57Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:41:57Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:42:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:42:03Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:43:10Z,trevyn,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:43:11Z,trevyn,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:43:34Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:43:35Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:44:49Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T17:44:54Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:44:55Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:44:56Z,simonvandel,simon.vandel@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:45:24Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:45:27Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T17:45:30Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:53:26Z,jackh726,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T17:53:34Z,jackh726,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T17:55:50Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:00:20Z,Pratyush,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:00:21Z,Pratyush,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:00:22Z,Pratyush,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:07:35Z,eopb,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:09:58Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:10:00Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:10:34Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:10:36Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:10:38Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:12:29Z,kurayama,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:14:16Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:14:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:25:59Z,Niederb,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T18:27:26Z,cramertj,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:27:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:27:27Z,cramertj,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:27:28Z,cramertj,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:29:24Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:29:39Z,ids1024,ian@iandouglasscott.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:32:55Z,bdonlan,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:37:37Z,EmilHernvall,emil@c0la.se https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:37:38Z,EmilHernvall,emil@c0la.se https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T18:37:42Z,EmilHernvall,emil@c0la.se https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:43:29Z,gmosx,george.moschovitis@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:50:31Z,Cldfire,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:51:48Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:51:48Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:52:45Z,declanvk,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T18:54:38Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T18:54:39Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T18:54:39Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T18:54:40Z,Kestrer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T18:57:15Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:03:34Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:03:36Z,gyscos,alexandre.bury@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:07:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:09:29Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T19:09:29Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:09:30Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:09:32Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:09:35Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T19:13:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:13:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:13:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:13:17Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:17:04Z,kianenigma,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:17:05Z,kianenigma,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:20:19Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T19:22:28Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:22:29Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:22:31Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:22:32Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:34:51Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:34:53Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:39:21Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:49:16Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T19:49:17Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:49:19Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T19:49:19Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T19:52:41Z,egilburg,eugene.gilburg@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T19:52:43Z,egilburg,eugene.gilburg@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T19:52:44Z,egilburg,eugene.gilburg@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:00:37Z,alvinhochun,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:01:10Z,alistair23,alistair@alistair23.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:02:43Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:03:19Z,jonaias,jonas.dourado@sunpowercorp.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:03:20Z,jonaias,jonas.dourado@sunpowercorp.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:05:27Z,regexident,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:05:28Z,regexident,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:05:29Z,regexident,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:05:30Z,regexident,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:09:16Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:09:16Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:09:17Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:09:17Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:09:29Z,thedodd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:09:30Z,thedodd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:23:36Z,yerke,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:23:37Z,yerke,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:23:38Z,yerke,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:23:39Z,yerke,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:26:56Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:26:58Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:26:58Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:26:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:26:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:27:00Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:27:00Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:27:00Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:31:39Z,fmease,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:31:39Z,fmease,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:31:40Z,fmease,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:31:41Z,fmease,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T20:46:49Z,HactarCE,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T20:46:50Z,HactarCE,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T20:46:52Z,HactarCE,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T20:46:56Z,HactarCE,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T21:01:49Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T21:01:50Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T21:01:51Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T21:01:52Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T21:08:07Z,MarcoIeni,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T21:27:50Z,maplant,maplant95@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T21:27:51Z,maplant,maplant95@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T21:27:51Z,maplant,maplant95@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T21:27:52Z,maplant,maplant95@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T21:50:04Z,cauebs,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T22:13:53Z,green-s,sam.green81@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T22:58:47Z,Avarel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T23:11:04Z,richli,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T23:21:51Z,pachi,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T23:25:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-17T23:42:59Z,elichai,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-17T23:42:59Z,elichai,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-17T23:43:00Z,elichai,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-17T23:43:02Z,elichai,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T00:32:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T00:32:45Z,Folyd,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T00:36:55Z,goodmanjonathan,goodmanjonathan@sbcglobal.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T01:27:31Z,hulloitskai,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T01:31:36Z,tesuji,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T02:28:50Z,mikialex,18516340862@163.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T02:40:07Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T02:40:08Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T02:40:09Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T02:40:10Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T02:48:46Z,mleonhard,michael@leonhardllc.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T03:04:19Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T03:04:21Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T03:04:25Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T03:04:28Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T03:40:44Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T04:12:59Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T04:33:29Z,Dispersia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T04:33:29Z,Dispersia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T04:33:30Z,Dispersia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T04:33:31Z,Dispersia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T05:03:45Z,cksac,cs.cksac@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T05:41:27Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T05:41:28Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T05:41:29Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T05:41:29Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T06:03:01Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T06:03:02Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T06:04:31Z,KeenS,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T06:22:12Z,pudnax,k.a.komissar@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T06:22:13Z,pudnax,k.a.komissar@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T06:22:13Z,pudnax,k.a.komissar@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T06:22:17Z,pudnax,k.a.komissar@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T06:46:29Z,dnaka91,dnaka91@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T06:46:31Z,dnaka91,dnaka91@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T06:46:33Z,dnaka91,dnaka91@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T06:46:33Z,dnaka91,dnaka91@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T07:24:50Z,Dengjianping,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T07:27:14Z,spaarmann,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T07:50:35Z,egilburg,eugene.gilburg@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:13:34Z,lperlaki,lperlaki@icloud.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T09:15:12Z,jeanmanguy,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:18:18Z,Fi3,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T09:20:33Z,harrysarson,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:21:32Z,harrysarson,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:32:06Z,TonalidadeHidrica,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:34:33Z,kristoff3r,k.soeholm@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T09:56:03Z,thibault-martinez,thibault@iota.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T10:16:56Z,numToStr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T10:21:24Z,OussamaDanba,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T10:37:07Z,dlight,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T10:48:01Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T10:48:02Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T10:48:04Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T11:42:51Z,krtab,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T11:42:53Z,krtab,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T11:45:22Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T11:45:23Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T11:45:24Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T11:45:26Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T12:43:01Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T13:03:54Z,elsuizo,mnoblia@disroot.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T14:20:55Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T14:46:59Z,Peohta,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T14:47:14Z,Peohta,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T15:13:44Z,fifteen42,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T15:23:24Z,MortenLohne,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T15:37:18Z,oh-wind,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T15:54:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T15:54:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T15:54:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T15:54:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T17:23:12Z,a1phyr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T17:23:17Z,a1phyr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-18T18:26:21Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-18T18:26:21Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T18:26:22Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-18T18:26:22Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-18T19:41:15Z,daira,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-19T07:40:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-19T08:06:27Z,hrektts,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-19T08:22:15Z,chirsz-ever,chirsz@foxmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-19T21:16:02Z,noslaver,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-19T22:06:24Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-19T22:06:25Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-19T22:33:19Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-20T04:31:45Z,newAM,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-20T04:53:54Z,CDirkx,christiaan@dirkx.email https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-20T06:08:40Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T06:08:42Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-20T06:08:43Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-20T06:08:44Z,ChosunOne,ChosunOne@protonmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T09:18:30Z,benediktwerner,1benediktwerner@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-20T09:18:31Z,benediktwerner,1benediktwerner@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-20T10:37:46Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T11:27:45Z,delacian,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-20T11:27:49Z,delacian,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-20T11:27:50Z,delacian,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-20T11:27:51Z,delacian,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T12:27:26Z,LiuYuHui,liuyuhui002@foxmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T14:11:00Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-20T14:11:01Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T19:09:30Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-20T19:55:22Z,janriemer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-20T19:55:23Z,janriemer,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-21T02:31:51Z,tamasfe,me@tamasfe.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-21T19:02:09Z,TheButlah,thebutlah@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-21T19:02:11Z,TheButlah,thebutlah@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-22T10:04:40Z,RustyYato,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-22T10:04:44Z,RustyYato,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-22T14:52:56Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-22T14:52:56Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-23T08:51:30Z,lamafab,fabio.lama@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-23T08:51:32Z,lamafab,fabio.lama@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-23T08:51:33Z,lamafab,fabio.lama@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-23T08:51:33Z,lamafab,fabio.lama@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-23T21:00:25Z,cdecompilador,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-25T23:38:08Z,sophie-h,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-25T23:38:15Z,sophie-h,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-27T10:26:04Z,FlorianFranzen,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-11-28T17:08:15Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-11-28T17:08:16Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-28T17:08:16Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-28T17:08:19Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-30T23:07:24Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-11-30T23:07:46Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-11-30T23:07:47Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-09T11:14:57Z,mbStavola,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-10T15:28:18Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-11T09:39:09Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-11T09:39:12Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-11T09:39:13Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-11T09:39:14Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-12T01:21:48Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-12T01:21:50Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-12T01:21:52Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-12T01:21:54Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-15T18:40:34Z,felix91gr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-15T18:40:37Z,felix91gr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-16T12:34:23Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-16T16:03:01Z,digama0,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-17T14:06:02Z,hello-wahyu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-17T14:06:04Z,hello-wahyu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-19T21:56:04Z,ilyavenner,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-19T22:56:47Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-19T22:56:48Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-19T22:56:48Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-19T22:56:49Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-20T04:31:34Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-20T04:31:36Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-20T04:31:37Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-20T04:31:38Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-20T21:22:45Z,tuankiet65,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-21T16:29:44Z,mati865,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-21T17:10:15Z,Eucladia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-21T17:10:16Z,Eucladia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-21T17:10:16Z,Eucladia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-21T17:10:17Z,Eucladia,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-23T18:04:45Z,LU15W1R7H,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-24T01:33:55Z,kyle-silver,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-24T01:33:59Z,kyle-silver,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-25T15:16:03Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-25T23:46:26Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-26T09:52:11Z,thomasheartman,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-26T14:29:52Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-26T23:20:35Z,usbalbin,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-26T23:20:40Z,usbalbin,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T10:43:00Z,Dherse,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T10:43:02Z,Dherse,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T10:43:04Z,Dherse,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T10:52:58Z,schulzch,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T11:13:16Z,audacioustux,audacioustux@icloud.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T11:13:17Z,audacioustux,audacioustux@icloud.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T11:13:18Z,audacioustux,audacioustux@icloud.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T12:30:31Z,not-matthias,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T12:30:31Z,not-matthias,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T12:30:31Z,not-matthias,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T12:30:32Z,not-matthias,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T12:51:57Z,bluss,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T14:57:49Z,quanlou,manhquan110@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T14:57:52Z,quanlou,manhquan110@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T14:58:46Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T14:58:47Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T14:58:48Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T14:58:48Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T15:04:27Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T15:04:27Z,acdenisSK,acdenissk69@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T15:07:52Z,hpatjens,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T15:18:28Z,CodesInChaos,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T16:18:57Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T16:18:58Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T16:18:58Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T16:18:59Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T16:37:55Z,MordragT,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T16:42:25Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T16:45:44Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T16:45:45Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T16:45:46Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T16:51:50Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T18:13:07Z,alice-i-cecile,alice.i.cecile@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T18:27:09Z,agluszak,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T19:02:04Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T19:02:09Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T19:02:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-27T19:02:22Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T19:22:05Z,vcapra1,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T19:22:07Z,vcapra1,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-27T20:12:02Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-27T21:59:08Z,Spoonbender,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-27T22:33:15Z,Philipp-M,philipp@mildenberger.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-28T01:40:27Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-28T01:40:27Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T01:40:31Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-28T01:40:34Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-28T01:41:39Z,GeorgeHahn,George.Hahn.VHS@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T02:30:11Z,gifnksm,makoto.nksm+github@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T04:17:16Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-28T04:46:32Z,varranvar,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T06:12:40Z,EyeOfPython,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T06:28:55Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-28T06:36:29Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T06:36:46Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T11:21:28Z,alamb,andrew@nerdnetworks.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-28T13:20:05Z,Urhengulas,johann.hemmann@code.berlin https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-29T02:49:46Z,longfangsong,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-29T14:04:45Z,ash2x3zb9cy,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-29T16:41:40Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-30T00:55:28Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-30T00:55:28Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-31T07:50:56Z,Brdnl,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-31T11:09:24Z,Yura52,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2020-12-31T13:13:18Z,rendaardy,renda_ardy@tutanota.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-31T13:13:20Z,rendaardy,renda_ardy@tutanota.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2020-12-31T13:13:25Z,rendaardy,renda_ardy@tutanota.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2020-12-31T13:13:28Z,rendaardy,renda_ardy@tutanota.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-31T14:47:01Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-31T16:23:53Z,Noviv,mwebbmwebb@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2020-12-31T20:44:38Z,safinsingh,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-01T14:08:01Z,ivovanderlans,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-02T17:56:21Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-01-02T17:56:22Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-02T17:56:27Z,HadrienG2,knights_of_ni@gmx.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-02T20:51:04Z,Guara92,guarascio.daniele@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-04T06:00:25Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-01-04T22:16:57Z,hello-wahyu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-01-04T22:16:59Z,hello-wahyu,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-05T01:42:58Z,Nukesor,github@arne.beer https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-05T21:49:53Z,botika,mhpoin@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-01-07T17:44:31Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-07T17:44:32Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-07T17:44:32Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-01-07T17:44:33Z,MarkMcCaskey,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-01-07T22:11:12Z,wrmsr0,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-07T22:11:15Z,wrmsr0,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-07T22:11:15Z,wrmsr0,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-01-07T22:11:16Z,wrmsr0,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-01-08T22:46:25Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-08T22:46:27Z,DasEtwas,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-09T07:58:35Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-09T07:58:35Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-01-21T07:55:57Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-01-21T07:55:57Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-01-21T07:55:58Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-02-02T11:48:15Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-02-02T11:48:16Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-02-02T11:48:17Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-02-02T11:48:17Z,Troxid,Troksid@yandex.ru https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-02-07T01:23:13Z,zlliang,zlliang96@outlook.com https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-02-08T04:57:02Z,rationalis,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-02-22T22:25:39Z,tema3210,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-02-22T22:25:40Z,tema3210,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-02-22T22:25:40Z,tema3210,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-02-23T02:37:46Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-02-23T02:37:48Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-02-23T02:37:50Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-03-07T12:58:27Z,uael,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-03-24T04:47:15Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-03-24T06:57:45Z,azdavis,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-03-25T11:28:04Z,strohel,matej@laitl.cz https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-03-25T14:08:17Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-03-25T14:08:18Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-03-25T14:08:18Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-03-25T14:08:18Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-03-26T01:06:23Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-03-26T01:06:26Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-03-26T01:06:29Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-04-13T01:46:06Z,ccqpein,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-05-03T08:18:17Z,Zhormos,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-07-13T19:15:36Z,bb010g,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-07-16T17:16:37Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-07-16T17:16:39Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-08-18T12:36:27Z,arogyad,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-09-22T02:44:06Z,guissalustiano,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-12-08T14:31:25Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-12-08T14:31:27Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-12-08T14:31:28Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-12-08T14:31:30Z,chrissimpkins,chris@sourcefoundry.org https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,THUMBS_UP,2021-12-30T19:03:27Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HOORAY,2021-12-30T19:03:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,HEART,2021-12-30T19:03:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79135,MERGED,2020-11-17T13:02:27Z,2020-12-27T09:55:59Z,stabilize `#![feature(min_const_generics)]` in 1.51,lcnr,1d517afcd0929450ded8f644fa8e8da3776db68b,478,Auto merge of #79135 - lcnr:the-paleogenesis-of-generic-germination r=varkor stabilize `#![feature(min_const_generics)]` in 1.51 *A new Kind* *A Sort long Prophesized* *Once Fragile now Eternal* blocked on #79073. # Stabilization report This is the stabilization report for `#![feature(min_const_generics)]` (tracking issue #74878) a subset of `#![feature(const_generics)]` (tracking issue #44580) based on rust-lang/rfcs#2000. The [version target](https://forge.rust-lang.org/#current-release-versions) is ~~1.50 (2020-12-31 => beta 2021-02-11 => stable)~~ 1.51 (2021-02-111 => beta 2021-03-25 => stable). This report is a collaborative effort of `@varkor ` `@shepmaster` and `@lcnr.` ## Summary It is currently possible to parameterize functions type aliases types traits and implementations by types and lifetimes. With `#![feature(min_const_generics)]` it becomes possible in addition to parameterize these by constants. This is done using the syntax `const IDENT: Type` in the parameter listing. Unlike full const generics `min_const_generics` is limited to parameterization by integers and constants of type `char` or `bool`. We already use `#![feature(min_const_generics)]` on stable to implement many common traits for arrays. See [the documentation](https://doc.rust-lang.org/nightly/std/primitive.array.html) for specific examples. Generic const arguments for now are not permitted to involve computations depending on generic parameters. This means that const parameters may only be instantiated using either: 1. const expressions that do not depend on any generic parameters e.g. `{ foo() + 1 }` where `foo` is a `const fn` 1. standalone const parameters e.g. `{N}` ### Example ```rust #![feature(min_const_generics)] trait Foo { fn method(&mut self arr: [[u8; M]; N]); } struct Bar { inner: [T; N] } impl Foo for Bar { fn method(&mut self arr: [[u8; M]; N]) { for (elem s) in self.inner.iter_mut().zip(arr.iter()) { for &x in s { *elem &= x; } } } } fn function() -> u16 { // Const parameters can be used freely inside of functions. (N + 1) / 2 * N } fn main() { let mut bar = Bar { inner: [0xff; 3] }; // This infers the value of `M` from the type of the function argument. bar.method([[0b11_00 0b01_00] [0b00_11 0b00_01] [0b11_00 0b00_11]]); assert_eq!(bar.inner [0b01_00 0b00_01 0b00_00]); // You can also explicitly specify the value of `N`. assert_eq!(function::<17>() 153); } ``` ## Motivation Rust has the built-in array type which is parametric over a constant. Without const generics this type can be quite cumbersome to use as it is not possible to generically implement a trait for arrays of different lengths. For example this meant that for a long time the standard library only contained trait implementations for arrays up to a length of 32. This restriction has since been lifted through the use of const generics. Const parameters allow users to naturally specify variants of a generic type which are more naturally parameterized by values rather than by types. For example using const generics many of the uses of the crate [typenum](https://crates.io/crates/typenum) may now be replaced with const parameters improving compilation time as well as code readability and diagnostics. The subset described by `min_const_generics` is self-contained but extensive enough to help with the most frequent issues: implementing traits for arrays and using arbitrarily-sized arrays inside of other types. Furthermore it extends naturally to full `const_generics` once the remaining design and implementation questions have been resolved. ## In-depth feature description ### Declaring const parameters *Const parameters* are allowed in all places where types and lifetimes are supported. They use the syntax `const IDENT: Type`. Currently const parameters must be declared after lifetime and type parameters. Their scope is equal to the scope of other generic parameters. They live in the value namespace. `Type` must be one of `u8` `u16` `u32` `u64` `u128` `usize` `i8` `i16` `i32` `i64` `i128` `isize` `char` and `bool`. This restriction is implemented in two places: 1. during name resolution where we forbid generic parameters 1. during well-formedness checking where we only allow the types listed above The updated syntax of parameter listings is: ``` GenericParams: (OuterAttr* LifetimeParam) * (OuterAttr* TypeParam) * (OuterAttr* ConstParam) * OuterAttr: '#[' ... ']' LifetimeParam: ... TypeParam: ... ConstParam: 'const' IDENT ':' Type ``` Unlike type and lifetime parameters const parameters of types can be used without being mentioned inside of a parameterized type because const parameters do not have issues concerning variance. This means that the following types are allowed: ```rust struct Foo; enum Bar { A B } ``` ### Const arguments Const parameters are instantiated using *const arguments*. Any concrete const expression or const parameter as a standalone argument can be used. When applying an expression as const parameter most expressions must be contained within a block with two exceptions: 1. literals and single-segment path expressions 1. array lengths This syntactic restriction is necessary to avoid ambiguity or requiring infinite lookahead when parsing an expression as a generic argument. In the cases where a generic argument could be resolved as either a type or const argument we always interpret it as a type. This causes the following test to fail: ```rust type N = u32; struct Foo; fn foo() -> Foo { todo!() } // ERR ``` To circumvent this the user may wrap the const parameter with braces at which point it is unambiguously accepted. ```rust type N = u32; struct Foo; fn bar() -> Foo<{ N }> { todo!() } // ok ``` Operations depending on generic parameters are **not** allowed which is enforced during well-formedness checking. Allowing generic unevaluated constants would require a way to check if they would always evaluate successfully to prevent errors that are not caught at declaration time. This ability forms part of `#![feature(const_evaluatable_checked)]` which is not yet being stabilised. Since we are not yet stabilizing `#![feature(lazy_normalization_consts)]` we must not supply the parent generics to anonymous constants except for repeat expressions. Doing so can cause cycle errors for arrays used in `where`-bounds. Not supplying the parent generics can however lead to ICEs occurring before well-formedness checking when trying to use a generic parameter. See #56445 for details. Since we expect cases like this to occur more frequently once `min_const_generics` is stabilized we have chosen to forbid generic parameters in anonymous constants during name resolution. While this changes the ICE in the situation above to an ordinary error this is theoretically a breaking change as early-bound lifetimes were previously permitted in repeat expressions but now are disallowed causing the following snippet to break: ```rust fn late_bound<'a>() { let _ = [0; { let _: &'a (); // ICE ==> ERR 3 }]; } fn early_bound<'a>() where &'a (): Sized { let _ = [0; { let _: &'a (); // ok ==> ERR 3 }]; } ``` ### Using const parameters Const parameters can be used almost everywhere ordinary constants are allowed except that they may not be used in the construction of consts statics functions or types inside a function body and are subject to the generic argument restrictions mentioned above. Expressions containing const parameters are eligible for promotion: ```rust fn test() -> &'static usize { &(3 + N) } ``` ### Symbol mangling See the [Rust symbol name mangling RFC](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html) for an overview. Generic const parameters take the form `K[type][value]` when the value is known or `Kp` where the value is not known where: - `[type]` is any integral type `bool` or `char`. - `[value]` is the unsigned hex value for integers preceded by `n` when negative; is `0` or `1` for `bool`; is the hex value for `char`. ### Exhaustiveness checking We do not check the exhaustiveness of impls meaning that the following example does **not** compile: ```rust struct Foo; trait Bar {} impl Bar for Foo {} impl Bar for Foo {} fn needs_bar(_: impl Bar) {} fn generic() { let v = Foo::; needs_bar(v); } ``` ### Type inference The value of const parameters can be inferred during typeck. One interesting case is the length of generic arrays which can also be inferred from patterns (implemented in #70562). Practical usage of this can be seen in #76825. ### Equality of constants `#![feature(min_const_generics)]` only permits generic parameters to be used as standalone generic arguments. We compare two parameters to be equal if they are literally the same generic parameter. ### Associated constants Associated constants can use const parameters without restriction see https://github.com/rust-lang/rust/pull/79135#issuecomment-748299774 for more details. ## Future work As this is a limited subset of rust-lang/rfcs#2000 there are quite a few extensions we will be looking into next. ### Lazy normalization of constants Stabilizing `#![feature(lazy_normalization_consts)]` (tracking issue #72219) will remove some special cases that are currently necessary for `min_const_generics` and unblocks operations on const parameters. ### Relaxing ordering requirements between const and type parameters We currently restrict the order of generic parameters so that types must come before consts. We could relax this as is currently done with `const_generics`. Without this it is not possible to use both type defaults and const parameters at the same time. Unrestricting the order will require us to improve some diagnostics that expect there to be a strict order between type and const parameters. ### Allowing more parameter types We would like to support const parameters of more types especially`&str` and user-defined types. Both are blocked on [valtrees]. There are also open questions regarding the design of `structural_match` concerning the latter. Supporting generic const parameter types such as `struct Foo` will be a lot harder and is unlikely to be implemented in the near future. ### Default values of const parameters We do not yet support default values for const parameters. There is work in progress to enable this on nightly (see https://github.com/rust-lang/rust/pull/75384). ### Generic const operations With `#![feature(min_const_generics)]` only concrete const expressions and parameters as standalone arguments are allowed in types and repeat expressions. However supporting generic const operations such as `N + 1` or `std::mem::size_of::()` is highly desirable. This feature is in early development under `#![feature(const_evaluatable_checked)]`. ## Implementation history Many people have contributed to the design and implementation of const generics over the last three years. See https://github.com/rust-lang/rust/issues/44580#issuecomment-728913127 for a summary. Once again thank you to everybody who helped out here! [valtrees]: https://github.com/rust-lang/rust/issues/72396 --- r? `@varkor`,ROCKET,2021-12-30T19:03:56Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79145,MERGED,2020-11-17T20:17:27Z,2020-11-18T20:36:42Z,Fix handling of panic calls,camelid,20fbe22a64dcf0e2acbd80dbda50f492f2164760,9,Rollup merge of #79145 - camelid:clippy-fix-panics r=flip1995 Fix handling of panic calls This should make Clippy more resilient and will unblock #78343. This PR is made against rust-lang/rust to avoid the need for a subtree sync at ``@flip1995's`` suggestion in rust-lang/rust-clippy#6310. r? ``@flip1995`` cc ``@m-ou-se``,HOORAY,2020-11-17T20:17:37Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79145,MERGED,2020-11-17T20:17:27Z,2020-11-18T20:36:42Z,Fix handling of panic calls,camelid,20fbe22a64dcf0e2acbd80dbda50f492f2164760,9,Rollup merge of #79145 - camelid:clippy-fix-panics r=flip1995 Fix handling of panic calls This should make Clippy more resilient and will unblock #78343. This PR is made against rust-lang/rust to avoid the need for a subtree sync at ``@flip1995's`` suggestion in rust-lang/rust-clippy#6310. r? ``@flip1995`` cc ``@m-ou-se``,HEART,2020-11-17T20:17:40Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2020-11-17T23:14:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2020-11-17T23:22:14Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2020-11-17T23:23:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2020-11-18T05:27:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2020-11-18T05:27:21Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HEART,2020-12-30T21:50:58Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2021-01-04T11:50:01Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HEART,2021-01-04T11:50:02Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HEART,2021-01-08T03:17:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2021-01-08T04:11:24Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HEART,2021-01-08T10:51:41Z,tux3,NA https://github.com/rust-lang/rust/pull/79150,MERGED,2020-11-17T23:04:49Z,2020-12-31T09:07:56Z,Remove all doc_comment!{} hacks by using #[doc = expr] where needed.,m-ou-se,8b002d5c3489a21db2c16e5af63cf5d234f6972c,8,"Auto merge of #79150 - m-ou-se:bye-bye-doc-comment-hack r=jyn514 Remove all doc_comment!{} hacks by using #[doc = expr] where needed. This replaces about 200 cases of `````rust doc_comment! { concat!(""The smallest value that can be represented by this integer type. # Examples Basic usage: ``` "" $Feature ""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"" $EndFeature "" ```"") #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; } ````` by ```rust /// The smallest value that can be represented by this integer type. /// /// # Examples /// /// Basic usage: /// /// ``` #[doc = concat!(""assert_eq!("" stringify!($SelfT) ""::MIN "" stringify!($Min) "");"")] /// ``` #[stable(feature = ""assoc_int_consts"" since = ""1.43.0"")] pub const MIN: Self = !0 ^ ((!0 as $UnsignedT) >> 1) as Self; ``` --- **Note:** For a usable diff make sure to enable 'ignore whitspace': https://github.com/rust-lang/rust/pull/79150/files?diff=unified&w=1",HOORAY,2021-01-14T01:41:21Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79158,MERGED,2020-11-18T09:48:53Z,2020-11-18T20:36:42Z,type is too big -> values of the type are too big,lcnr,43d13e2d584c32b125d61f055e6e7127a77b1d54,19,Rollup merge of #79158 - lcnr:lazy-norm-coerce r=oli-obk type is too big -> values of the type are too big strictly speaking `[u8; usize::MAX]` or even `[[[u128; usize::MAX]; usize::MAX]; usize::MAX]` are absolutely fine types as long as you don't try to deal with any values of it. This error message seems to cause some confusion imo for example in https://github.com/rust-lang/rust/pull/79135#issuecomment-729361380 so I would prefer us to be more precise here. See the added test case which uses one of these types without causing an error. r? ``@oli-obk``,THUMBS_UP,2020-11-18T09:52:35Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79159,MERGED,2020-11-18T10:23:34Z,2020-11-18T12:55:03Z,Revert #79132,pietroalbini,7d747db0d5dd8f08f2efb073e2e77a34553465a7,4,Auto merge of #79159 - pietroalbini:woops r=pietroalbini Revert #79132 The beta promotion release was mistakenly landed on master instead of beta. Ugh. r? `@ghost` cc `@rust-lang/release`,HEART,2020-11-18T11:26:01Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/79164,MERGED,2020-11-18T12:57:07Z,2020-11-19T19:50:24Z,Permit standalone generic parameters as const generic arguments in macros,varkor,b5fffdc12be138ddf5fbd0f20d31026597d86d4e,5,Rollup merge of #79164 - varkor:unbraced-single-segment-const-arguments r=petrochenkov Permit standalone generic parameters as const generic arguments in macros Fixes https://github.com/rust-lang/rust/issues/79127. r? ```@petrochenkov```,HEART,2020-11-18T13:01:56Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/79169,MERGED,2020-11-18T16:38:58Z,2020-12-12T15:03:07Z,Create `rustc_type_ir`,LeSeulArtichaut,3f2088aa603d2cd3f43c20795872de9cd6ec7735,6,Auto merge of #79169 - LeSeulArtichaut:ty-lib r=nikomatsakis Create `rustc_type_ir` Decided to start small 😄 This PR creates a `rustc_type_ir` crate as part of the WG-Traits plan to create a shared type library. ~~There already exists a `rustc_ty` crate so I named the new crate `rustc_ty_library`. However I think it would make sense to rename the current `rustc_ty` to something else (e.g. `rustc_ty_passes`) to free the name for this new crate.~~ r? `@jackh726`,HOORAY,2020-12-18T20:10:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79171,CLOSED,2020-11-18T17:16:20Z,2021-03-10T17:17:24Z,rustc_target: don't limit SPIR-V inline asm! types to a fixed subset.,eddyb,NA,NA,NA,THUMBS_UP,2020-11-19T10:35:15Z,Tobski,NA https://github.com/rust-lang/rust/pull/79171,CLOSED,2020-11-18T17:16:20Z,2021-03-10T17:17:24Z,rustc_target: don't limit SPIR-V inline asm! types to a fixed subset.,eddyb,NA,NA,NA,THUMBS_UP,2020-12-09T15:33:30Z,msiglreith,NA https://github.com/rust-lang/rust/pull/79172,MERGED,2020-11-18T17:17:08Z,2020-11-23T04:47:24Z,Add #[cold] attribute to `std::process::abort` and `alloc::alloc::handle_alloc_error`,a1phyr,f32459c7ba767e7f26e3c4c4bd6be326d83bcb78,2,Auto merge of #79172 - a1phyr:cold_abort r=Mark-Simulacrum Add #[cold] attribute to `std::process::abort` and `alloc::alloc::handle_alloc_error`,THUMBS_UP,2020-11-26T03:33:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79174,MERGED,2020-11-18T18:52:11Z,2021-01-25T01:59:58Z,Make std::future a re-export of core::future,taiki-e,13b88c21d002bdd84395cb30c28bc6460afc2315,2,Rollup merge of #79174 - taiki-e:std-future r=Mark-Simulacrum Make std::future a re-export of core::future After 1a764a7ef59b9cb2eb31658625a6a7dacc3d819b there are no `std::future`-specific items (except for `cfg(bootstrap)` items removed in 93eed402adbe9e7a532995500d50716d52eefee9). So instead of defining `std` own module we can re-export the `core::future` directly.,EYES,2020-11-18T21:21:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79174,MERGED,2020-11-18T18:52:11Z,2021-01-25T01:59:58Z,Make std::future a re-export of core::future,taiki-e,13b88c21d002bdd84395cb30c28bc6460afc2315,2,Rollup merge of #79174 - taiki-e:std-future r=Mark-Simulacrum Make std::future a re-export of core::future After 1a764a7ef59b9cb2eb31658625a6a7dacc3d819b there are no `std::future`-specific items (except for `cfg(bootstrap)` items removed in 93eed402adbe9e7a532995500d50716d52eefee9). So instead of defining `std` own module we can re-export the `core::future` directly.,EYES,2020-11-19T17:55:17Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79174,MERGED,2020-11-18T18:52:11Z,2021-01-25T01:59:58Z,Make std::future a re-export of core::future,taiki-e,13b88c21d002bdd84395cb30c28bc6460afc2315,2,Rollup merge of #79174 - taiki-e:std-future r=Mark-Simulacrum Make std::future a re-export of core::future After 1a764a7ef59b9cb2eb31658625a6a7dacc3d819b there are no `std::future`-specific items (except for `cfg(bootstrap)` items removed in 93eed402adbe9e7a532995500d50716d52eefee9). So instead of defining `std` own module we can re-export the `core::future` directly.,EYES,2020-11-20T21:00:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79181,MERGED,2020-11-18T21:58:09Z,2020-11-20T03:33:46Z,rustdoc: add [src] links to methods on a trait's page,aDotInTheVoid,192ed76cb98a06a18c880604d97d36e25f42e5ae,3,Rollup merge of #79181 - aDotInTheVoid:provided-method-source-link r=jyn514 GuillaumeGomez rustdoc: add [src] links to methods on a trait's page Closes #45150 ![image](https://user-images.githubusercontent.com/28781354/99565541-aba4d500-29c3-11eb-99c7-11c1f91584e9.png) ### Caveats - The way I've implemented it links are also provided for required methods that just link to the signature in the code. I'm not sure if this is the desired behaviour. ![image](https://user-images.githubusercontent.com/28781354/99566222-849ad300-29c4-11eb-9897-08cc5842954f.png) - I'm not sure if the css changes are correct. I inspected them visualy on firefox on desktop and they seem to be fine. - I can't tell how `src/librustdoc/html/render/mod.rs` is structured so I probably,THUMBS_UP,2020-11-19T06:38:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/79181,MERGED,2020-11-18T21:58:09Z,2020-11-20T03:33:46Z,rustdoc: add [src] links to methods on a trait's page,aDotInTheVoid,192ed76cb98a06a18c880604d97d36e25f42e5ae,3,Rollup merge of #79181 - aDotInTheVoid:provided-method-source-link r=jyn514 GuillaumeGomez rustdoc: add [src] links to methods on a trait's page Closes #45150 ![image](https://user-images.githubusercontent.com/28781354/99565541-aba4d500-29c3-11eb-99c7-11c1f91584e9.png) ### Caveats - The way I've implemented it links are also provided for required methods that just link to the signature in the code. I'm not sure if this is the desired behaviour. ![image](https://user-images.githubusercontent.com/28781354/99566222-849ad300-29c4-11eb-9897-08cc5842954f.png) - I'm not sure if the css changes are correct. I inspected them visualy on firefox on desktop and they seem to be fine. - I can't tell how `src/librustdoc/html/render/mod.rs` is structured so I probably,THUMBS_UP,2020-11-20T03:58:09Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79181,MERGED,2020-11-18T21:58:09Z,2020-11-20T03:33:46Z,rustdoc: add [src] links to methods on a trait's page,aDotInTheVoid,192ed76cb98a06a18c880604d97d36e25f42e5ae,3,Rollup merge of #79181 - aDotInTheVoid:provided-method-source-link r=jyn514 GuillaumeGomez rustdoc: add [src] links to methods on a trait's page Closes #45150 ![image](https://user-images.githubusercontent.com/28781354/99565541-aba4d500-29c3-11eb-99c7-11c1f91584e9.png) ### Caveats - The way I've implemented it links are also provided for required methods that just link to the signature in the code. I'm not sure if this is the desired behaviour. ![image](https://user-images.githubusercontent.com/28781354/99566222-849ad300-29c4-11eb-9897-08cc5842954f.png) - I'm not sure if the css changes are correct. I inspected them visualy on firefox on desktop and they seem to be fine. - I can't tell how `src/librustdoc/html/render/mod.rs` is structured so I probably,HEART,2021-01-19T10:43:32Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79182,MERGED,2020-11-18T22:27:54Z,2020-11-21T22:46:50Z,Fix links to extern types in rustdoc (fixes #78777),lochsh,5d428cae7d5926d5b53098436ebcc53d0dadb228,3,"Rollup merge of #79182 - lochsh:78777-fix-extern-types-ref r=jyn514 Fix links to extern types in rustdoc (fixes #78777) r? `@jyn514` Fixes #78777. The initial fix we tried was: ```diff diff --git a/src/librustdoc/passes/collect_intra_doc_links.rs b/src/librustdoc/passes/collect_intra_doc_links.rs index 8be9482acff..c4b7086fdb1 100644 --- a/src/librustdoc/passes/collect_intra_doc_links.rs +++ b/src/librustdoc/passes/collect_intra_doc_links.rs `@@` -433 8 +433 9 `@@` impl<'a 'tcx> LinkCollector<'a 'tcx> { Res::PrimTy(prim) => Some( self.resolve_primitive_associated_item(prim ns module_id item_name item_str) ) - Res::Def(DefKind::Struct | DefKind::Union | DefKind::Enum | DefKind::TyAlias did) => { + Res::Def(kind did) if kind.ns() == Some(Namespace::TypeNS) => { debug!(""looking for associated item named {} for item {:?}"" item_name did); + // Checks if item_name belongs to `impl SomeItem` let assoc_item = cx .tcx ``` However this caused traits to be matched resulting in a panic when `resolve_associated_trait_item` is called further down in this function. This PR also adds an error message for that panic. Currently it will look something like: ```rust thread 'rustc' panicked at 'Not a type: DefIndex(8624)' compiler/rustc_metadata/src/rmeta/decoder.rs:951:32 ``` I wasn't sure how to get a better debug output than `DefIndex(...)` and am open to suggestions.",HEART,2020-11-18T22:30:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79183,MERGED,2020-11-18T22:44:20Z,2020-11-20T03:33:46Z,Make compiletest testing use the local sysroot,cuviper,d5ee4edee10e1d39e205341eeace4f9ba26d389a,1,Rollup merge of #79183 - cuviper:compiletest-test-sysroot r=Mark-Simulacrum Make compiletest testing use the local sysroot We already set `compiletest` to use the local sysroot in #68019 but that missed the configuration for testing `compiletest` itself.,HOORAY,2020-11-18T22:47:58Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/79183,MERGED,2020-11-18T22:44:20Z,2020-11-20T03:33:46Z,Make compiletest testing use the local sysroot,cuviper,d5ee4edee10e1d39e205341eeace4f9ba26d389a,1,Rollup merge of #79183 - cuviper:compiletest-test-sysroot r=Mark-Simulacrum Make compiletest testing use the local sysroot We already set `compiletest` to use the local sysroot in #68019 but that missed the configuration for testing `compiletest` itself.,HEART,2020-11-18T22:54:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79184,MERGED,2020-11-18T22:49:13Z,2020-12-01T14:30:02Z,Stop adding '*' at the end of slice and str typenames for MSVC case,nanguye2496,08b171726cf978ce27b00190f22140dde0dcfccf,1,Rollup merge of #79184 - nanguye2496:nanguye2496/fix_slice_and_str_type_name r=varkor Stop adding '*' at the end of slice and str typenames for MSVC case When computing debug info for MSVC debuggers Rust compiler emits C++ style type names for compatibility with .natvis visualizers. All Ref types are treated as equivalences of C++ pointers in this process and as a result their type names end with a '\*'. Since Slice and Str are treated as Ref by the compiler their type names also end with a '\*'. This causes the .natvis engine for WinDbg fails to display data of Slice and Str objects. We addressed this problem simply by removing the '*' at the end of type names for Slice and Str types. Debug info in WinDbg before the fix: ![image](https://user-images.githubusercontent.com/74681961/99594120-9a4dcf80-29a7-11eb-8cce-aedaf1da6d21.png) Debug info in WinDbg after the fix: ![image](https://user-images.githubusercontent.com/74681961/99597173-717c0900-29ac-11eb-861e-98143a9177cf.png) This change has also been tested with debuggers for Visual Studio VS Code C++ and VS Code LLDB to make sure that it does not affect the behavior of other kinds of debugger.,HEART,2020-11-19T00:21:18Z,sivadeilra,NA https://github.com/rust-lang/rust/pull/79184,MERGED,2020-11-18T22:49:13Z,2020-12-01T14:30:02Z,Stop adding '*' at the end of slice and str typenames for MSVC case,nanguye2496,08b171726cf978ce27b00190f22140dde0dcfccf,1,Rollup merge of #79184 - nanguye2496:nanguye2496/fix_slice_and_str_type_name r=varkor Stop adding '*' at the end of slice and str typenames for MSVC case When computing debug info for MSVC debuggers Rust compiler emits C++ style type names for compatibility with .natvis visualizers. All Ref types are treated as equivalences of C++ pointers in this process and as a result their type names end with a '\*'. Since Slice and Str are treated as Ref by the compiler their type names also end with a '\*'. This causes the .natvis engine for WinDbg fails to display data of Slice and Str objects. We addressed this problem simply by removing the '*' at the end of type names for Slice and Str types. Debug info in WinDbg before the fix: ![image](https://user-images.githubusercontent.com/74681961/99594120-9a4dcf80-29a7-11eb-8cce-aedaf1da6d21.png) Debug info in WinDbg after the fix: ![image](https://user-images.githubusercontent.com/74681961/99597173-717c0900-29ac-11eb-861e-98143a9177cf.png) This change has also been tested with debuggers for Visual Studio VS Code C++ and VS Code LLDB to make sure that it does not affect the behavior of other kinds of debugger.,HEART,2020-11-26T00:24:30Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/79184,MERGED,2020-11-18T22:49:13Z,2020-12-01T14:30:02Z,Stop adding '*' at the end of slice and str typenames for MSVC case,nanguye2496,08b171726cf978ce27b00190f22140dde0dcfccf,1,Rollup merge of #79184 - nanguye2496:nanguye2496/fix_slice_and_str_type_name r=varkor Stop adding '*' at the end of slice and str typenames for MSVC case When computing debug info for MSVC debuggers Rust compiler emits C++ style type names for compatibility with .natvis visualizers. All Ref types are treated as equivalences of C++ pointers in this process and as a result their type names end with a '\*'. Since Slice and Str are treated as Ref by the compiler their type names also end with a '\*'. This causes the .natvis engine for WinDbg fails to display data of Slice and Str objects. We addressed this problem simply by removing the '*' at the end of type names for Slice and Str types. Debug info in WinDbg before the fix: ![image](https://user-images.githubusercontent.com/74681961/99594120-9a4dcf80-29a7-11eb-8cce-aedaf1da6d21.png) Debug info in WinDbg after the fix: ![image](https://user-images.githubusercontent.com/74681961/99597173-717c0900-29ac-11eb-861e-98143a9177cf.png) This change has also been tested with debuggers for Visual Studio VS Code C++ and VS Code LLDB to make sure that it does not affect the behavior of other kinds of debugger.,HEART,2021-03-07T07:08:32Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/79185,MERGED,2020-11-18T22:59:21Z,2020-11-20T03:33:46Z,"expand/resolve: Pre-requisites to ""Turn `#[derive]` into a regular macro attribute""",petrochenkov,8216b359e542d6d842bc3ed3fba3c67de5ad60fa,33,"Rollup merge of #79185 - petrochenkov:derattr2 r=Aaron1011 expand/resolve: Pre-requisites to ""Turn `#[derive]` into a regular macro attribute"" Miscellaneous refactorings and error reporting changes extracted from https://github.com/rust-lang/rust/pull/79078. Unlike https://github.com/rust-lang/rust/pull/79078 this PR doesn't make any observable changes to the language or library. r? ```@Aaron1011```",HEART,2020-11-19T06:56:46Z,est31,NA https://github.com/rust-lang/rust/pull/79186,MERGED,2020-11-18T23:04:17Z,2020-11-23T16:33:06Z,Change slice::to_vec to not use extend_from_slice,JulianKnodt,40cf72108edb9b8633a9d284b238988309204494,3,Auto merge of #79186 - JulianKnodt:str_from r=Mark-Simulacrum Change slice::to_vec to not use extend_from_slice I saw this [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/String.3A.3Afrom%28.26str%29.20wonky.20codegen/near/216164455) and didn't see any update from it so I thought I'd try to fix it. This converts `to_vec` to no longer use `extend_from_slice` but relies on knowing that the allocated capacity is the same size as the input. [Godbolt new v1](https://rust.godbolt.org/z/1bcWKG) [Godbolt new v2 w/ drop guard](https://rust.godbolt.org/z/5jn76K) [Godbolt old version](https://rust.godbolt.org/z/e4ePav) After some amount of iteration there are now two specializations for `to_vec` one for `Copy` types that use memcpy and one for clone types which is the original from this PR. This is then used inside of `impl FromIterator> for Vec` which is essentially equivalent to `&[T] -> Vec` instead of previous specialization of the `extend` function. This is because extend has to reason more about existing capacity by calling `reserve` on an existing vec and thus produces worse asm. Downsides: This allocates the exact capacity so I think if many items are added to this `Vec` after it might need to allocate whereas extending may not. I also noticed the number of faults went up in the benchmarks but not sure where from exactly.,THUMBS_UP,2020-12-01T11:07:44Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79188,CLOSED,2020-11-19T00:04:53Z,2020-12-18T03:34:40Z,Made matches! more useful by adding mapping support,zesterer,NA,NA,NA,EYES,2020-11-19T06:38:21Z,tesuji,NA https://github.com/rust-lang/rust/pull/79188,CLOSED,2020-11-19T00:04:53Z,2020-12-18T03:34:40Z,Made matches! more useful by adding mapping support,zesterer,NA,NA,NA,EYES,2020-11-20T07:53:34Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79188,CLOSED,2020-11-19T00:04:53Z,2020-12-18T03:34:40Z,Made matches! more useful by adding mapping support,zesterer,NA,NA,NA,EYES,2020-12-10T07:57:46Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/79188,CLOSED,2020-11-19T00:04:53Z,2020-12-18T03:34:40Z,Made matches! more useful by adding mapping support,zesterer,NA,NA,NA,CONFUSED,2020-12-11T17:11:37Z,olehmisar,NA https://github.com/rust-lang/rust/pull/79188,CLOSED,2020-11-19T00:04:53Z,2020-12-18T03:34:40Z,Made matches! more useful by adding mapping support,zesterer,NA,NA,NA,THUMBS_UP,2021-01-19T14:21:38Z,Tails,NA https://github.com/rust-lang/rust/pull/79194,MERGED,2020-11-19T07:30:24Z,2020-11-20T03:33:46Z,Make as{_mut }_slice on array::IntoIter public,est31,169e2212d9adcaa5684548a2f094dea15d49860e,1,Rollup merge of #79194 - est31:array_into_iter_slice r=scottmcm Make as{_mut }_slice on array::IntoIter public The functions are useful in cases where you want to move data out of the IntoIter in bulk by transmute_copy'ing the slice and then forgetting the IntoIter. In the compiler this is useful for providing a sped up IntoIter implementation. One can alternatively provide a separate allocate_array function but one can avoid duplicating some logic by passing everything through the generic iterator using interface. As per suggestion in https://github.com/rust-lang/rust/pull/78569/files#r526506964,HEART,2020-11-19T08:53:58Z,bugadani,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-19T17:51:27Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-19T17:56:57Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-19T20:43:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-20T08:44:21Z,Ltrlg,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-21T04:23:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-23T16:38:24Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-11-27T17:41:30Z,RustyYato,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2020-12-16T19:36:16Z,l4l,mail@kitsu.me https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-01-15T12:58:23Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-01-23T07:12:35Z,reynoldsbd,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-13T06:07:44Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-19T03:46:43Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-19T03:58:46Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-19T17:24:39Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-25T07:23:53Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-25T09:20:11Z,mzji,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-26T21:39:32Z,wackbyte,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-02-27T01:06:06Z,faern,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-03-04T16:28:27Z,mohe2015,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-03-10T20:08:38Z,jrvanwhy,jrvanwhy@google.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-04-12T17:02:10Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-05-06T19:05:15Z,mcarton,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-05-28T03:26:44Z,worstpractice,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-06-01T18:10:46Z,qm3ster,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-06-28T14:40:35Z,omppye,omppye@gmail.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-06-28T23:42:42Z,yerke,NA https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-07-13T00:00:16Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-08-18T20:19:41Z,JakubKoralewski,contact@jcubed.me https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2021-08-19T14:42:33Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2022-02-08T10:25:00Z,ia0,github@ia0.eu https://github.com/rust-lang/rust/pull/79208,MERGED,2020-11-19T17:47:46Z,2021-03-10T04:06:54Z,Stabilize `unsafe_op_in_unsafe_fn` lint,LeSeulArtichaut,c46f948a8056c9da728969dcc30e4c132d4b4bbb,13,"Rollup merge of #79208 - LeSeulArtichaut:stable-unsafe_op_in_unsafe_fn r=nikomatsakis Stabilize `unsafe_op_in_unsafe_fn` lint This makes it possible to override the level of the `unsafe_op_in_unsafe_fn` as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896. Tracking issue: #71668 r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung``` # Stabilization report This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`. ## Summary Currently the body of unsafe functions is an unsafe block i.e. you can perform unsafe operations inside. The `unsafe_op_in_unsafe_fn` lint stabilized here can be used to change this behavior so performing unsafe operations in unsafe functions requires an unsafe block. For now the lint is allow-by-default which means that this PR does not change anything without overriding the lint level. For more information see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md) ### Example ```rust // An `unsafe fn` for demonstration purposes. // Calling this is an unsafe operation. unsafe fn unsf() {} // #[allow(unsafe_op_in_unsafe_fn)] by default // the behavior of `unsafe fn` is unchanged unsafe fn allowed() { // Here no `unsafe` block is needed to // perform unsafe operations... unsf(); // ...and any `unsafe` block is considered // unused and is warned on by the compiler. unsafe { unsf(); } } #[warn(unsafe_op_in_unsafe_fn)] unsafe fn warned() { // Removing this `unsafe` block will // cause the compiler to emit a warning. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } #[deny(unsafe_op_in_unsafe_fn)] unsafe fn denied() { // Removing this `unsafe` block will // cause a compilation error. // (Also no ""unused unsafe"" warning will be emitted here.) unsafe { unsf(); } } ```",HEART,2022-03-25T23:14:08Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/79209,MERGED,2020-11-19T17:52:48Z,2020-11-29T23:14:38Z,Allow Trait inheritance with cycles on associated types,spastorino,349b3b324dade7ca638091db93ba08bbc443c63d,28,Auto merge of #79209 - spastorino:trait-inheritance-self r=nikomatsakis Allow Trait inheritance with cycles on associated types Fixes #35237 r? `@nikomatsakis` cc `@estebank`,ROCKET,2020-11-30T20:34:17Z,estebank,NA https://github.com/rust-lang/rust/pull/79209,MERGED,2020-11-19T17:52:48Z,2020-11-29T23:14:38Z,Allow Trait inheritance with cycles on associated types,spastorino,349b3b324dade7ca638091db93ba08bbc443c63d,28,Auto merge of #79209 - spastorino:trait-inheritance-self r=nikomatsakis Allow Trait inheritance with cycles on associated types Fixes #35237 r? `@nikomatsakis` cc `@estebank`,ROCKET,2021-01-01T06:56:38Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79209,MERGED,2020-11-19T17:52:48Z,2020-11-29T23:14:38Z,Allow Trait inheritance with cycles on associated types,spastorino,349b3b324dade7ca638091db93ba08bbc443c63d,28,Auto merge of #79209 - spastorino:trait-inheritance-self r=nikomatsakis Allow Trait inheritance with cycles on associated types Fixes #35237 r? `@nikomatsakis` cc `@estebank`,HOORAY,2021-01-01T06:56:44Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79209,MERGED,2020-11-19T17:52:48Z,2020-11-29T23:14:38Z,Allow Trait inheritance with cycles on associated types,spastorino,349b3b324dade7ca638091db93ba08bbc443c63d,28,Auto merge of #79209 - spastorino:trait-inheritance-self r=nikomatsakis Allow Trait inheritance with cycles on associated types Fixes #35237 r? `@nikomatsakis` cc `@estebank`,EYES,2021-01-01T06:56:48Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79211,MERGED,2020-11-19T20:24:10Z,2020-12-19T10:13:54Z,"Add ""promise"" doc alias to async keyword",yoshuawuyts,60aad47c1369e72e0ac4f297b710d2a19d2d202b,1,"Rollup merge of #79211 - yoshuawuyts:future-doc-alias r=Mark-Simulacrum Add the ""async"" and ""promise"" doc aliases to `core::future::Future` Adds the ""async"" and ""promise"" doc aliases to `core::future::Future`. This enables people who search for ""async"" or ""promise"" to find `Future` which is Rust's core primitive for async programming. Thanks!",HEART,2020-11-19T20:29:31Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79211,MERGED,2020-11-19T20:24:10Z,2020-12-19T10:13:54Z,"Add ""promise"" doc alias to async keyword",yoshuawuyts,60aad47c1369e72e0ac4f297b710d2a19d2d202b,1,"Rollup merge of #79211 - yoshuawuyts:future-doc-alias r=Mark-Simulacrum Add the ""async"" and ""promise"" doc aliases to `core::future::Future` Adds the ""async"" and ""promise"" doc aliases to `core::future::Future`. This enables people who search for ""async"" or ""promise"" to find `Future` which is Rust's core primitive for async programming. Thanks!",HEART,2020-11-19T20:54:08Z,dermoumi,NA https://github.com/rust-lang/rust/pull/79211,MERGED,2020-11-19T20:24:10Z,2020-12-19T10:13:54Z,"Add ""promise"" doc alias to async keyword",yoshuawuyts,60aad47c1369e72e0ac4f297b710d2a19d2d202b,1,"Rollup merge of #79211 - yoshuawuyts:future-doc-alias r=Mark-Simulacrum Add the ""async"" and ""promise"" doc aliases to `core::future::Future` Adds the ""async"" and ""promise"" doc aliases to `core::future::Future`. This enables people who search for ""async"" or ""promise"" to find `Future` which is Rust's core primitive for async programming. Thanks!",HEART,2020-11-19T21:04:25Z,bilelmoussaoui,bil.elmoussaoui@gmail.com https://github.com/rust-lang/rust/pull/79212,MERGED,2020-11-19T20:40:46Z,2020-11-20T03:33:46Z,Move `rustc_ty` -> `rustc_ty_utils`,LeSeulArtichaut,95da42559316b4b399750eaffb4cc708ea22c430,11,Rollup merge of #79212 - LeSeulArtichaut:rustc-ty r=jonas-schievink Move `rustc_ty` -> `rustc_ty_utils` Implements MCP rust-lang/compiler-team#387. r? `@jonas-schievink`,THUMBS_UP,2020-11-19T20:50:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-11-20T00:13:16Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-11-20T07:49:59Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,ROCKET,2020-11-28T22:44:44Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-07T09:59:51Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,ROCKET,2020-12-07T09:59:51Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,HEART,2020-12-08T11:09:25Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,ROCKET,2020-12-10T11:55:55Z,bluss,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-10T14:33:11Z,rednaz1337,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-10T21:17:23Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,HEART,2020-12-27T12:19:53Z,agnipau,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-29T00:56:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,HEART,2020-12-29T00:56:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,ROCKET,2020-12-29T00:56:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-29T12:28:20Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,ROCKET,2020-12-29T12:28:24Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-31T04:41:39Z,tux3,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2020-12-31T13:41:21Z,Folyd,NA https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2021-01-03T13:39:57Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/79213,MERGED,2020-11-19T20:42:47Z,2020-12-25T08:17:06Z,Stabilize `core::slice::fill`,yoshuawuyts,21d36e0dafb49b6acd0975205042bc424b94fe26,2,Rollup merge of #79213 - yoshuawuyts:stabilize-slice-fill r=m-ou-se Stabilize `core::slice::fill` Tracking issue https://github.com/rust-lang/rust/issues/70758 Stabilizes the `core::slice::fill` API in Rust 1.50 adding a `memset` doc alias so people coming from C/C++ looking for this operation can find it in the docs. This API hasn't seen any changes since we changed the signature in https://github.com/rust-lang/rust/pull/71165/ and it seems like the right time to propose stabilization. Thanks! r? `@m-ou-se`,THUMBS_UP,2021-01-04T00:45:56Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79217,MERGED,2020-11-19T20:54:51Z,2020-11-20T03:33:46Z,"Add the ""memcpy"" doc alias to slice::copy_from_slice",yoshuawuyts,5adc00fbb8a40ecc685b26abfce0a4b619eb4c88,1,"Rollup merge of #79217 - yoshuawuyts:copy_from_slice-alias r=Mark-Simulacrum Add the ""memcpy"" doc alias to slice::copy_from_slice [RFC1419](https://github.com/rust-lang/rfcs/pull/1419) describes `slice::copy_from_slice` as a ""safe memcpy"". This enables people searching for `memcpy` to find the `slice::copy_from_slice` method. Thanks! ## Screenshots This is currently the output when searching for ""memcpy"" -- `copy_from_slice` is safe and should be part of this list. ![Screenshot_2020-11-19 Results for memcpy - Rust](https://user-images.githubusercontent.com/2467194/99722964-c9e8fe80-2ab1-11eb-82a5-4afe703a0eea.png)",THUMBS_UP,2020-11-19T21:09:17Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79217,MERGED,2020-11-19T20:54:51Z,2020-11-20T03:33:46Z,"Add the ""memcpy"" doc alias to slice::copy_from_slice",yoshuawuyts,5adc00fbb8a40ecc685b26abfce0a4b619eb4c88,1,"Rollup merge of #79217 - yoshuawuyts:copy_from_slice-alias r=Mark-Simulacrum Add the ""memcpy"" doc alias to slice::copy_from_slice [RFC1419](https://github.com/rust-lang/rfcs/pull/1419) describes `slice::copy_from_slice` as a ""safe memcpy"". This enables people searching for `memcpy` to find the `slice::copy_from_slice` method. Thanks! ## Screenshots This is currently the output when searching for ""memcpy"" -- `copy_from_slice` is safe and should be part of this list. ![Screenshot_2020-11-19 Results for memcpy - Rust](https://user-images.githubusercontent.com/2467194/99722964-c9e8fe80-2ab1-11eb-82a5-4afe703a0eea.png)",THUMBS_UP,2020-11-19T21:21:17Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79217,MERGED,2020-11-19T20:54:51Z,2020-11-20T03:33:46Z,"Add the ""memcpy"" doc alias to slice::copy_from_slice",yoshuawuyts,5adc00fbb8a40ecc685b26abfce0a4b619eb4c88,1,"Rollup merge of #79217 - yoshuawuyts:copy_from_slice-alias r=Mark-Simulacrum Add the ""memcpy"" doc alias to slice::copy_from_slice [RFC1419](https://github.com/rust-lang/rfcs/pull/1419) describes `slice::copy_from_slice` as a ""safe memcpy"". This enables people searching for `memcpy` to find the `slice::copy_from_slice` method. Thanks! ## Screenshots This is currently the output when searching for ""memcpy"" -- `copy_from_slice` is safe and should be part of this list. ![Screenshot_2020-11-19 Results for memcpy - Rust](https://user-images.githubusercontent.com/2467194/99722964-c9e8fe80-2ab1-11eb-82a5-4afe703a0eea.png)",THUMBS_UP,2020-12-06T05:29:55Z,tux3,NA https://github.com/rust-lang/rust/pull/79222,MERGED,2020-11-20T00:47:41Z,2020-11-21T10:42:26Z,Add `core::slice::fill_with`,yoshuawuyts,29a74e62857bc8c51723402dee5873ef0fe2cd83,1,Auto merge of #79222 - yoshuawuyts:slice-fill-with r=m-ou-se Add `core::slice::fill_with` Tracking issue https://github.com/rust-lang/rust/issues/79221. As suggested by `@m-ou-se` in https://github.com/rust-lang/rust/issues/70758#issuecomment-726838099 this implements `slice::fill_with` as a counterpart to `slice::fill`. This mirrors `Vec::resize` and `Vec::resize_with`. Thanks! r? `@m-ou-se`,HEART,2020-11-20T07:44:47Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79222,MERGED,2020-11-20T00:47:41Z,2020-11-21T10:42:26Z,Add `core::slice::fill_with`,yoshuawuyts,29a74e62857bc8c51723402dee5873ef0fe2cd83,1,Auto merge of #79222 - yoshuawuyts:slice-fill-with r=m-ou-se Add `core::slice::fill_with` Tracking issue https://github.com/rust-lang/rust/issues/79221. As suggested by `@m-ou-se` in https://github.com/rust-lang/rust/issues/70758#issuecomment-726838099 this implements `slice::fill_with` as a counterpart to `slice::fill`. This mirrors `Vec::resize` and `Vec::resize_with`. Thanks! r? `@m-ou-se`,HEART,2020-11-20T09:38:34Z,darksv,NA https://github.com/rust-lang/rust/pull/79222,MERGED,2020-11-20T00:47:41Z,2020-11-21T10:42:26Z,Add `core::slice::fill_with`,yoshuawuyts,29a74e62857bc8c51723402dee5873ef0fe2cd83,1,Auto merge of #79222 - yoshuawuyts:slice-fill-with r=m-ou-se Add `core::slice::fill_with` Tracking issue https://github.com/rust-lang/rust/issues/79221. As suggested by `@m-ou-se` in https://github.com/rust-lang/rust/issues/70758#issuecomment-726838099 this implements `slice::fill_with` as a counterpart to `slice::fill`. This mirrors `Vec::resize` and `Vec::resize_with`. Thanks! r? `@m-ou-se`,HEART,2020-11-20T10:36:22Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79232,CLOSED,2020-11-20T14:08:42Z,2021-01-29T11:43:40Z,Add doc aliases for print macros,yoshuawuyts,NA,NA,NA,HOORAY,2020-11-20T14:32:57Z,luser,NA https://github.com/rust-lang/rust/pull/79232,CLOSED,2020-11-20T14:08:42Z,2021-01-29T11:43:40Z,Add doc aliases for print macros,yoshuawuyts,NA,NA,NA,HOORAY,2020-11-20T17:37:04Z,Frando,NA https://github.com/rust-lang/rust/pull/79232,CLOSED,2020-11-20T14:08:42Z,2021-01-29T11:43:40Z,Add doc aliases for print macros,yoshuawuyts,NA,NA,NA,HOORAY,2020-11-20T19:11:46Z,Lokathor,NA https://github.com/rust-lang/rust/pull/79243,MERGED,2020-11-20T20:02:08Z,2020-11-22T21:00:48Z,Consolidate exhaustiveness-related tests,Nadrieril,c643dd2ec8fed2852f5eee8f776d657293a6a8f2,71,Auto merge of #79243 - Nadrieril:consolidate-tests r=varkor Consolidate exhaustiveness-related tests I hunted for tests that only exercised the match exhaustiveness algorithm and regrouped them. I also improved integer-range tests since I had found them lacking while hacking around. The interest is mainly so that one can pass `--test-args patterns` and catch most relevant tests. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-11-21T06:45:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79259,CLOSED,2020-11-21T10:51:31Z,2020-11-21T21:09:49Z,Avoid generating realloc call in []::to_vec.,m-ou-se,NA,NA,NA,HEART,2020-11-21T11:51:44Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2020-11-21T13:15:43Z,bbqsrc,NA https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2020-12-18T04:30:02Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2020-12-31T04:28:22Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2021-01-28T09:56:59Z,Folyd,NA https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2021-02-09T19:53:03Z,worstpractice,NA https://github.com/rust-lang/rust/pull/79261,MERGED,2020-11-21T12:25:51Z,2020-12-23T12:25:07Z,Deprecate atomic compare_and_swap method,faern,87eecd40e87cf7e77cee9cfdc79900c83baf6d8f,17,Auto merge of #79261 - faern:deprecate-compare-and-swap r=Amanieu Deprecate atomic compare_and_swap method Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443). It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find and even if this PR does not go through it can act as a place where people can find out about the decision being reverted. Atomic operations are hard to understand very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better. Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes but I wanted to start somewhere. Most of it is just copied from the RFC. The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations. The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.,THUMBS_UP,2021-02-11T15:26:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",THUMBS_UP,2020-11-22T09:44:34Z,RustyYato,NA https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",THUMBS_UP,2020-11-23T18:22:02Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",ROCKET,2020-12-10T17:07:19Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",THUMBS_UP,2021-02-09T14:35:03Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",ROCKET,2021-02-09T20:03:10Z,worstpractice,NA https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",THUMBS_UP,2021-02-11T15:49:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",THUMBS_UP,2021-02-12T05:30:05Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79270,MERGED,2020-11-21T17:17:53Z,2020-12-21T16:10:22Z,Acknowledge that `[CONST; N]` is stable,RalfJung,11c94a197726b6a981828cb1837d7c3eed1b841d,2,"Auto merge of #79270 - RalfJung:array-repeat-consts r=oli-obk Acknowledge that `[CONST; N]` is stable When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749 accidentally the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable: ```rust const EMPTY: Vec = Vec::new(); pub const fn bar() -> [Vec; 2] { [EMPTY; 2] } fn main() { let x = bar(); } ``` In contrast if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY ).0`) this would have failed. We could take back this stabilization as it was clearly accidental. However I propose we instead just officially accept this and stabilize a small subset of RFC 2203 while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)) so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities does not rely on promotion and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them possibly using associated consts if generics are involved). Well I said ""no semantic ambiguities"" that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]` or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor it should run in the former case (but currently doesn't due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all the `let`-expansion does *not* work in general for `N > 1`. Cc `@rust-lang/lang` `@rust-lang/wg-const-eval` Cc https://github.com/rust-lang/rust/issues/49147",ROCKET,2021-02-12T05:30:06Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-21T23:57:49Z,camelid,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-22T12:03:57Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-22T18:24:53Z,est31,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-26T19:59:31Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-26T20:22:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2020-11-28T23:01:54Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,ROCKET,2020-11-29T23:35:10Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-01-02T21:14:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-01-08T13:14:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-01-13T16:39:56Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-02-05T02:42:23Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,ROCKET,2021-02-05T02:42:24Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-18T12:03:32Z,95th,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,ROCKET,2021-03-18T12:03:34Z,95th,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,ROCKET,2021-03-22T20:11:19Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-24T09:18:55Z,eopb,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-25T04:39:41Z,Folyd,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-25T09:51:05Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-25T15:22:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-25T23:48:41Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-27T09:59:29Z,gifnksm,makoto.nksm+github@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-27T18:20:13Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-03-30T02:13:35Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-04-15T06:08:41Z,lukechu10,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-04-26T07:06:08Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-05T22:04:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-16T08:04:15Z,gemhung,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-16T15:56:36Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-16T15:56:49Z,arilotter,arilotter@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-16T21:42:11Z,bm-w,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-06-17T07:55:44Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-07-04T06:25:19Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/79278,MERGED,2020-11-21T21:29:21Z,2021-03-22T22:56:42Z,Stabilize or_patterns (RFC 2535 2530 2175),mark-i-m,5d04957a4b4714f71d38326fc96a0b0ef6dc5800,128,Auto merge of #79278 - mark-i-m:stabilize-or-pattern r=nikomatsakis Stabilize or_patterns (RFC 2535 2530 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177,HOORAY,2021-07-31T20:02:56Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T03:05:49Z,scottjmaddox,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T04:12:17Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T07:22:21Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T07:41:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T09:57:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T10:10:55Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T10:16:49Z,gliderkite,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-22T14:37:09Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-23T13:25:15Z,95th,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-11-25T17:46:41Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79286,MERGED,2020-11-22T01:18:39Z,2020-12-04T22:19:31Z,Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`,TimDiekmann,3ff10e74a74ed093fcabac1de27fe1cd65bbbb4a,27,Auto merge of #79286 - TimDiekmann:rename-allocref r=Lokathor Wodann m-ou-se Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate` Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76. closes https://github.com/rust-lang/wg-allocators/issues/76 r? `@KodrAus` `@rustbot` modify labels: +A-allocators +T-libs `@rustbot` ping wg-allocators,THUMBS_UP,2020-12-04T12:18:20Z,Wodann,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,THUMBS_UP,2020-11-22T04:48:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-11-22T06:07:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T08:20:52Z,darksv,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T13:03:53Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-11-22T13:09:42Z,vn-ki,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T13:32:30Z,Emerentius,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T13:38:19Z,est31,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T15:02:22Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T15:38:20Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-11-22T17:58:00Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-22T18:03:50Z,jplatte,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-11-22T22:19:24Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-11-23T04:15:40Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,THUMBS_UP,2020-11-26T01:05:18Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-12-03T07:48:48Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-03T10:32:20Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-03T15:02:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-03T15:41:03Z,Peohta,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-03T19:18:22Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-04T16:08:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-05T01:24:59Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-05T01:52:53Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2020-12-07T02:09:53Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2020-12-30T15:23:44Z,NathanHuisman,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,HEART,2021-01-05T10:43:57Z,peterjoel,peterjoel@gmail.com https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,THUMBS_UP,2021-05-26T11:20:30Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/79287,MERGED,2020-11-22T03:25:26Z,2020-11-23T19:01:20Z,Allow using generic trait methods in `const fn`,jonas-schievink,c7a67209c8abbba40d5736eb10975988d99960bc,22,Rollup merge of #79287 - jonas-schievink:const-trait-impl r=oli-obk Allow using generic trait methods in `const fn` Next step for https://github.com/rust-lang/rust/issues/67792 this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self _: &S) -> bool { true } } const fn equals_self(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection in particular through `ParamCandidate` and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate to avoid ambiguities when both a const and a non-const bound is present.,EYES,2021-05-26T11:20:30Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-11-22T15:13:28Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-22T15:13:30Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2020-11-22T15:13:31Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-11-22T17:09:09Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-22T17:09:10Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2020-11-22T17:09:14Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-22T18:27:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-11-22T18:51:39Z,8573,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2020-11-22T20:25:44Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-24T09:27:15Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-11-25T01:11:36Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-26T08:53:21Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-11-28T05:36:02Z,panarch,taehoon.moon@outlook.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-12-08T01:47:53Z,naiveai,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-12-14T20:41:49Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-12-14T20:41:50Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2020-12-14T20:41:50Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-12-16T07:27:41Z,nwn,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2020-12-21T12:52:04Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2020-12-21T12:52:05Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2021-01-23T21:29:26Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2021-01-23T21:29:27Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2021-03-08T03:56:17Z,notshridhar,shridhar.me.003@gmail.com https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,THUMBS_UP,2021-06-09T09:38:45Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,HOORAY,2021-06-09T09:38:45Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79299,MERGED,2020-11-22T13:26:13Z,2020-11-23T02:25:12Z,Stabilise `then`,varkor,41c033b2f7b2eb770bb9b4169e0bbaf051c6c7b1,6,Rollup merge of #79299 - varkor:stabilise-then r=m-ou-se Stabilise `then` Stabilises the lazy variant of https://github.com/rust-lang/rust/issues/64260 now that the FCP [has ended](https://github.com/rust-lang/rust/issues/64260#issuecomment-731636203). I've kept the original feature gate `bool_to_option` for the strict variant (`then_some`) and created a new insta-stable feature gate `lazy_bool_to_option` for `then`.,ROCKET,2021-06-09T09:38:46Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79311,CLOSED,2020-11-22T18:18:59Z,2020-11-23T22:29:57Z,Unify ty::AssocKind with hir::AssocItemKind.,cjgillot,NA,NA,NA,EYES,2020-11-22T18:24:33Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79328,MERGED,2020-11-23T00:44:44Z,2021-01-14T17:27:11Z,Reintroduce hir::ExprKind::If,c410-f3r,d03fe84169d50a4b96cdef7b2f862217ab634055,139,"Auto merge of #79328 - c410-f3r:hir-if r=matthewjasper Reintroduce hir::ExprKind::If Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not ""wrong"". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not ""wrong"". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)",THUMBS_UP,2020-12-03T03:29:32Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/79328,MERGED,2020-11-23T00:44:44Z,2021-01-14T17:27:11Z,Reintroduce hir::ExprKind::If,c410-f3r,d03fe84169d50a4b96cdef7b2f862217ab634055,139,"Auto merge of #79328 - c410-f3r:hir-if r=matthewjasper Reintroduce hir::ExprKind::If Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not ""wrong"". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not ""wrong"". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)",THUMBS_UP,2020-12-18T05:18:13Z,cynecx,NA https://github.com/rust-lang/rust/pull/79328,MERGED,2020-11-23T00:44:44Z,2021-01-14T17:27:11Z,Reintroduce hir::ExprKind::If,c410-f3r,d03fe84169d50a4b96cdef7b2f862217ab634055,139,"Auto merge of #79328 - c410-f3r:hir-if r=matthewjasper Reintroduce hir::ExprKind::If Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not ""wrong"". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not ""wrong"". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)",THUMBS_UP,2021-01-14T15:56:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79328,MERGED,2020-11-23T00:44:44Z,2021-01-14T17:27:11Z,Reintroduce hir::ExprKind::If,c410-f3r,d03fe84169d50a4b96cdef7b2f862217ab634055,139,"Auto merge of #79328 - c410-f3r:hir-if r=matthewjasper Reintroduce hir::ExprKind::If Basically copied and paste #59288/https://github.com/rust-lang/rust-clippy/pull/4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not ""wrong"". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not ""wrong"". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)",THUMBS_UP,2021-04-28T03:50:14Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/79342,MERGED,2020-11-23T13:09:10Z,2020-12-19T16:06:31Z,Stabilize all stable methods of `Ipv4Addr` `Ipv6Addr` and `IpAddr` as const,CDirkx,bd2f1cb2785f87177249e2bdb628ed782fcd8def,1,Auto merge of #79342 - CDirkx:ipaddr-const r=oli-obk Stabilize all stable methods of `Ipv4Addr` `Ipv6Addr` and `IpAddr` as const This PR stabilizes all currently stable methods of `Ipv4Addr` `Ipv6Addr` and `IpAddr` as const. Tracking issue: #76205 `Ipv4Addr` (`const_ipv4`): - `octets` - `is_loopback` - `is_private` - `is_link_local` - `is_multicast` - `is_broadcast` - `is_docmentation` - `to_ipv6_compatible` - `to_ipv6_mapped` `Ipv6Addr` (`const_ipv6`): - `segments` - `is_unspecified` - `is_loopback` - `is_multicast` - `to_ipv4` `IpAddr` (`const_ip`): - `is_unspecified` - `is_loopback` - `is_multicast` ## Motivation The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September after the necessary const integer arithmetic was stabilized. There is currently a PR open (#78802) to change the internal representation of `IpAddr{4 6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods. ## Implementation Most of the stabilizations are straightforward with the exception of `Ipv6Addr::segments` which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code but this leads to worse code generation (#75085). This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]` like the already const-stable `Ipv6Addr::new` the justification being that a const-stable alternative implementation exists https://github.com/rust-lang/rust/pull/76206#issuecomment-685044184. ## Future posibilities This PR const-stabilizes all currently stable ip methods however there are also a number of unstable methods under the `ip` feature (#27709). These methods are already unstable const. There is a PR open (#76098) to stabilize those methods which could include const-stabilization. However stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).,THUMBS_UP,2020-11-29T21:41:14Z,faern,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T04:43:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T10:09:01Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T10:11:28Z,tesuji,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T10:41:56Z,faern,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T10:48:32Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T11:02:26Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T11:24:06Z,lo48576,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T12:08:28Z,tema3210,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T12:25:35Z,aznhe21,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T12:29:27Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-11-24T14:31:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T16:09:42Z,a1phyr,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T17:34:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T17:44:07Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-24T17:48:53Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-11-24T20:55:38Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-26T00:18:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-26T06:31:17Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-26T07:58:11Z,honsunrise,honsun@linux.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T11:52:03Z,derekdreery,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T13:44:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T16:15:25Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,EYES,2020-11-27T16:17:01Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T16:54:38Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T18:47:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T18:47:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,EYES,2020-11-27T18:48:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T19:41:58Z,elichai,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-27T19:41:59Z,elichai,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-11-29T19:19:41Z,branan,branan@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-01T13:28:06Z,95th,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-12-01T13:28:08Z,95th,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-02T19:10:25Z,cdmistman,colton@donn.io https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-03T05:06:31Z,TOETOE55,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-03T15:53:45Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-08T17:45:52Z,cramertj,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2020-12-08T17:45:56Z,cramertj,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-18T23:27:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2020-12-19T02:52:43Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2021-01-21T02:50:57Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2021-04-28T09:00:12Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HOORAY,2021-09-22T17:56:33Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79366,CLOSED,2020-11-23T23:28:55Z,2021-03-19T16:16:43Z,conditional fallback for the `!` type,nikomatsakis,NA,NA,NA,HEART,2021-09-22T17:56:33Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79389,CLOSED,2020-11-24T21:05:27Z,2020-11-25T02:09:48Z,"Revert ""linux: try to use libc getrandom to allow interposition""",jyn514,NA,NA,NA,HEART,2020-11-24T21:27:31Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79389,CLOSED,2020-11-24T21:05:27Z,2020-11-25T02:09:48Z,"Revert ""linux: try to use libc getrandom to allow interposition""",jyn514,NA,NA,NA,HEART,2020-11-25T01:00:00Z,Aglais-Io,NA https://github.com/rust-lang/rust/pull/79391,CLOSED,2020-11-24T21:39:27Z,2020-11-25T02:39:59Z,"Revert ""Enable AVX512 *epi64 variants by updating stdarch""",Mark-Simulacrum,NA,NA,NA,HEART,2020-11-24T21:43:17Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/79403,CLOSED,2020-11-25T08:32:35Z,2021-01-18T12:21:10Z,Updated the help message to reduce the error iterations,bishtpawan,NA,NA,NA,EYES,2020-11-30T11:24:14Z,tesuji,NA https://github.com/rust-lang/rust/pull/79423,MERGED,2020-11-25T20:33:25Z,2021-02-23T07:19:45Z,Enable smart punctuation,camelid,1c2a949736a85810127b73dbc1006565689d6fe4,5,Rollup merge of #79423 - camelid:smart-punct r=jyn514 Enable smart punctuation Closes #76690.,THUMBS_DOWN,2021-05-06T18:08:16Z,tjkirch,NA https://github.com/rust-lang/rust/pull/79423,MERGED,2020-11-25T20:33:25Z,2021-02-23T07:19:45Z,Enable smart punctuation,camelid,1c2a949736a85810127b73dbc1006565689d6fe4,5,Rollup merge of #79423 - camelid:smart-punct r=jyn514 Enable smart punctuation Closes #76690.,HEART,2021-05-13T09:21:34Z,mgeisler,martin@geisler.net https://github.com/rust-lang/rust/pull/79427,MERGED,2020-11-25T21:11:56Z,2020-11-26T14:15:05Z,Resolve inference variables before trying to remove overloaded indexing,Aaron1011,aefcf1f3427a5e522a8c665d7e25529cf971bc93,2,Auto merge of #79427 - Aaron1011:fix/const-array-index r=oli-obk Resolve inference variables before trying to remove overloaded indexing Fixes #79152 This code was already set up to handle indexing an array. However it appears that we never end up with an inference variable for the slice case so the missing call to `resolve_vars_if_possible` had no effect until now.,HOORAY,2020-12-18T00:25:22Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79443,MERGED,2020-11-26T13:05:53Z,2020-11-29T04:54:18Z,Improve rustdoc JS tests error output,GuillaumeGomez,d5d60364786f88bcea9d940ec056bb020c12aa5b,1,"Rollup merge of #79443 - GuillaumeGomez:improve-rustdoc-js-error-output r=jyn514 Improve rustdoc JS tests error output It's pretty common when starting to add new tests for rustdoc-js to have issues to understand the errors. With this it should make things a bit simpler. So now in case of an error it displays: ``` ---- [js-doc-test] rustdoc-js/basic.rs stdout ---- error: rustdoc-js test failed! failed to decode compiler output as json: line: { output: Checking ""basic"" ... FAILED ==> Result not found in 'others': '{""path"":""basic"" ""name"":""Fo""}' Diff of first error: { ""path"": ""basic"" - ""name"": ""Fo"" + ""name"": ""Foo"" } thread '[js-doc-test] rustdoc-js/basic.rs' panicked at 'explicit panic' src/tools/compiletest/src/json.rs:126:21 ``` I think it was ``@camelid`` who asked about it a few days ago? r? ``@jyn514``",HEART,2020-11-26T13:14:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79443,MERGED,2020-11-26T13:05:53Z,2020-11-29T04:54:18Z,Improve rustdoc JS tests error output,GuillaumeGomez,d5d60364786f88bcea9d940ec056bb020c12aa5b,1,"Rollup merge of #79443 - GuillaumeGomez:improve-rustdoc-js-error-output r=jyn514 Improve rustdoc JS tests error output It's pretty common when starting to add new tests for rustdoc-js to have issues to understand the errors. With this it should make things a bit simpler. So now in case of an error it displays: ``` ---- [js-doc-test] rustdoc-js/basic.rs stdout ---- error: rustdoc-js test failed! failed to decode compiler output as json: line: { output: Checking ""basic"" ... FAILED ==> Result not found in 'others': '{""path"":""basic"" ""name"":""Fo""}' Diff of first error: { ""path"": ""basic"" - ""name"": ""Fo"" + ""name"": ""Foo"" } thread '[js-doc-test] rustdoc-js/basic.rs' panicked at 'explicit panic' src/tools/compiletest/src/json.rs:126:21 ``` I think it was ``@camelid`` who asked about it a few days ago? r? ``@jyn514``",HEART,2020-11-26T19:52:24Z,camelid,NA https://github.com/rust-lang/rust/pull/79448,CLOSED,2020-11-26T17:14:24Z,2020-12-01T17:01:42Z,Switch x64 windows msvc target to use `lld` by default.,crlf0710,NA,NA,NA,HEART,2020-11-26T18:03:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79448,CLOSED,2020-11-26T17:14:24Z,2020-12-01T17:01:42Z,Switch x64 windows msvc target to use `lld` by default.,crlf0710,NA,NA,NA,HEART,2020-11-26T18:15:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79451,MERGED,2020-11-26T21:54:10Z,2020-12-22T16:10:11Z,Added [T; N]::zip(),usbalbin,0fe1dc6ac214d443369134177940b4d0111e1df6,1,Auto merge of #79451 - usbalbin:array_zip r=m-ou-se Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right or at least close :) --- This is PR adds the array method `[T; N]::zip()` which in my mind is a natural extension to #75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) `@jplatte` mentioned in [#75490](https://github.com/rust-lang/rust/pull/75490#issuecomment-677790758) `zip_with()` > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :)),HEART,2020-11-27T00:59:39Z,jplatte,NA https://github.com/rust-lang/rust/pull/79451,MERGED,2020-11-26T21:54:10Z,2020-12-22T16:10:11Z,Added [T; N]::zip(),usbalbin,0fe1dc6ac214d443369134177940b4d0111e1df6,1,Auto merge of #79451 - usbalbin:array_zip r=m-ou-se Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right or at least close :) --- This is PR adds the array method `[T; N]::zip()` which in my mind is a natural extension to #75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) `@jplatte` mentioned in [#75490](https://github.com/rust-lang/rust/pull/75490#issuecomment-677790758) `zip_with()` > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :)),HEART,2020-12-07T13:24:45Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79451,MERGED,2020-11-26T21:54:10Z,2020-12-22T16:10:11Z,Added [T; N]::zip(),usbalbin,0fe1dc6ac214d443369134177940b4d0111e1df6,1,Auto merge of #79451 - usbalbin:array_zip r=m-ou-se Added [T; N]::zip() This is my first PR to rust so I hope I have done everything right or at least close :) --- This is PR adds the array method `[T; N]::zip()` which in my mind is a natural extension to #75212. My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic thus no need for the dropguard seen in the `map()`-function? The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip) `@jplatte` mentioned in [#75490](https://github.com/rust-lang/rust/pull/75490#issuecomment-677790758) `zip_with()` > zip and zip_with seem like they would be useful :) is this something I should add (assuming there is interest for this PR at all :)),HEART,2022-02-23T12:46:17Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79455,MERGED,2020-11-26T23:45:57Z,2020-11-29T09:28:11Z,Remove doctree::Macro and distinguish between `macro_rules!` and `pub macro`,CraftSpider,3cbb56f80b2fbf5a3b405212665918dbffc44d39,5,Auto merge of #79455 - CraftSpider:master r=jyn514 Remove doctree::Macro and distinguish between `macro_rules!` and `pub macro` This is a part of #78082 removing doctree::Macro. Uses the changes in #79372 Fixes #76761,HOORAY,2020-11-27T01:15:26Z,camelid,NA https://github.com/rust-lang/rust/pull/79455,MERGED,2020-11-26T23:45:57Z,2020-11-29T09:28:11Z,Remove doctree::Macro and distinguish between `macro_rules!` and `pub macro`,CraftSpider,3cbb56f80b2fbf5a3b405212665918dbffc44d39,5,Auto merge of #79455 - CraftSpider:master r=jyn514 Remove doctree::Macro and distinguish between `macro_rules!` and `pub macro` This is a part of #78082 removing doctree::Macro. Uses the changes in #79372 Fixes #76761,HEART,2020-11-27T01:44:05Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79464,MERGED,2020-11-27T13:31:14Z,2020-11-29T04:54:18Z,Extend doc keyword feature by allowing any ident,GuillaumeGomez,ca8a1b05c62d05d82fb6d5480dc9e4b4fdad1ce4,5,"Rollup merge of #79464 - GuillaumeGomez:doc-keyword-ident r=jyn514 Extend doc keyword feature by allowing any ident Part of #51315. As suggested by ``@danielhenrymantilla`` in [this comment](https://github.com/rust-lang/rust/issues/51315#issuecomment-733879934) this PR extends `#[doc(keyword = ""..."")]` to allow any ident to be used as keyword. The final goal is to allow (proc-)macro crates' owners to write documentation of the keywords they might introduce. r? ``@jyn514``",HEART,2020-11-27T13:54:10Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T16:15:30Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T16:54:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T17:54:05Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T22:37:50Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-27T22:38:06Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-28T03:47:08Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-29T20:38:41Z,faern,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-30T00:51:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-11-30T11:26:27Z,mati865,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-12-01T13:28:45Z,95th,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-12-13T19:35:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-12-14T15:34:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2020-12-29T12:16:16Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2021-01-12T20:59:00Z,estebank,NA https://github.com/rust-lang/rust/pull/79470,CLOSED,2020-11-27T15:39:10Z,2021-03-30T15:26:31Z,[WIP] Experiment: stabilize never type,nikomatsakis,NA,NA,NA,HEART,2021-02-15T12:50:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79472,MERGED,2020-11-27T17:34:27Z,2020-12-30T09:51:48Z,Replace pretty-print/compare/retokenize hack with targeted workarounds,Aaron1011,b9c403be11bef38638b38012be80444ad3f09dde,8,Auto merge of #79472 - Aaron1011:new-remove-pretty-print-hack r=petrochenkov Replace pretty-print/compare/retokenize hack with targeted workarounds Based on https://github.com/rust-lang/rust/pull/78296 cc https://github.com/rust-lang/rust/issues/43081 The 'pretty-print/compare/retokenize' hack is used to try to avoid passing an outdated `TokenStream` to a proc-macro when the underlying AST is modified in some way (e.g. cfg-stripping before derives). Unfortunately retokenizing throws away spans (including hygiene information) which causes issues of its own. Every improvement to the accuracy of the pretty-print/retokenize comparison has resulted in non-trivial ecosystem breakage due to hygiene changes. In extreme cases users deliberately wrote unhygienic `macro_rules!` macros (likely because they did not realize that the compiler's behavior was a bug). Additionaly the comparison between the original and pretty-printed/retoknized token streams comes at a non-trivial runtime cost as shown by https://github.com/rust-lang/rust/pull/79338 This PR removes the pretty-print/compare/retokenize logic from `nt_to_tokenstream`. We only discard the original `TokenStream` under two circumstances: * Inner attributes are used (detected by examining the AST) * `cfg`/`cfg_attr` processing modifies the AST. This is detected by making the visitor update a flag when it performs a modification instead of trying to detect the modification after-the-fact. Note that a 'matching' `cfg` (e.g. `#[cfg(not(FALSE)]`) does not actually get removed from the AST allowing us to preserve the original `TokenStream`. In all other cases we preserve the original `TokenStream`. This could use a bit of refactoring/renaming - opening for a Crater run. r? `@ghost`,HOORAY,2020-11-27T17:47:09Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,HEART,2020-11-27T19:38:33Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-11-27T22:38:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-11-28T14:29:06Z,EdorianDark,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-11-28T23:16:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-11-29T17:38:00Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,HEART,2020-11-29T17:38:02Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,HEART,2020-12-10T05:34:41Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-12-10T05:34:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-12-10T14:27:11Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,HEART,2020-12-17T03:51:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-12-17T03:51:46Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-12-24T20:12:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79473,MERGED,2020-11-27T18:26:34Z,2020-12-20T00:50:43Z,Move {f32 f64}::clamp to core.,m-ou-se,c1d58436614ad522e4db9113ac56d90ec4a95448,4,Auto merge of #79473 - m-ou-se:clamp-in-core r=m-ou-se Move {f32 f64}::clamp to core. `clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`) the versions for the `f32` and `f64` primitives were added in `std` (together with `floor` `sin` etc.) not in `core` (together with `min` `max` `from_bits` etc.). This change moves them to `core` such that `clamp` on floats is available in `no_std` programs as well.,THUMBS_UP,2020-12-30T13:19:23Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/79476,MERGED,2020-11-27T20:05:44Z,2020-11-28T17:24:09Z,Sync rustc_codegen_cranelift,bjorn3,dd0f9533786ddede9307cb57839ca5039669a6e8,33,Rollup merge of #79476 - bjorn3:sync_cg_clif-2020-11-27 r=bjorn3 Sync rustc_codegen_cranelift This implements a few extra simd intrinsics fixes yet another 128bit bug and updates a few dependencies. It also fixes an cg_clif subtree update that did compile but that caused a panic when compiling libcore. Other than that this is mostly cleanups. `@rustbot` modify labels: +A-codegen +A-cranelift +T-compiler,HEART,2020-11-28T03:43:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79476,MERGED,2020-11-27T20:05:44Z,2020-11-28T17:24:09Z,Sync rustc_codegen_cranelift,bjorn3,dd0f9533786ddede9307cb57839ca5039669a6e8,33,Rollup merge of #79476 - bjorn3:sync_cg_clif-2020-11-27 r=bjorn3 Sync rustc_codegen_cranelift This implements a few extra simd intrinsics fixes yet another 128bit bug and updates a few dependencies. It also fixes an cg_clif subtree update that did compile but that caused a panic when compiling libcore. Other than that this is mostly cleanups. `@rustbot` modify labels: +A-codegen +A-cranelift +T-compiler,HEART,2020-11-28T05:44:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79476,MERGED,2020-11-27T20:05:44Z,2020-11-28T17:24:09Z,Sync rustc_codegen_cranelift,bjorn3,dd0f9533786ddede9307cb57839ca5039669a6e8,33,Rollup merge of #79476 - bjorn3:sync_cg_clif-2020-11-27 r=bjorn3 Sync rustc_codegen_cranelift This implements a few extra simd intrinsics fixes yet another 128bit bug and updates a few dependencies. It also fixes an cg_clif subtree update that did compile but that caused a panic when compiling libcore. Other than that this is mostly cleanups. `@rustbot` modify labels: +A-codegen +A-cranelift +T-compiler,HEART,2020-11-28T07:14:27Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/79476,MERGED,2020-11-27T20:05:44Z,2020-11-28T17:24:09Z,Sync rustc_codegen_cranelift,bjorn3,dd0f9533786ddede9307cb57839ca5039669a6e8,33,Rollup merge of #79476 - bjorn3:sync_cg_clif-2020-11-27 r=bjorn3 Sync rustc_codegen_cranelift This implements a few extra simd intrinsics fixes yet another 128bit bug and updates a few dependencies. It also fixes an cg_clif subtree update that did compile but that caused a panic when compiling libcore. Other than that this is mostly cleanups. `@rustbot` modify labels: +A-codegen +A-cranelift +T-compiler,HEART,2020-12-02T16:30:53Z,95th,NA https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2020-11-28T08:10:18Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2020-11-28T23:58:26Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2021-01-08T01:41:57Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2021-01-08T21:53:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2021-01-09T15:26:25Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/79479,MERGED,2020-11-27T22:48:14Z,2020-12-31T00:23:17Z,Add `Iterator::intersperse`,camelid,9cf24388d1d72cb0c5712b656556b6c1930d755d,8,Rollup merge of #79479 - camelid:intersperse r=m-ou-se Add `Iterator::intersperse` This is a rebase of #75784. I'm hoping to push this past the finish line! cc `@jonas-schievink`,HOORAY,2021-01-11T12:33:02Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/79484,MERGED,2020-11-28T00:42:08Z,2020-11-29T04:54:18Z,add enable-full-tools to freebsd builds to prevent occasional link er…,sreehax,c9c81d92a96531d72782fb24f923e972facab6f4,1,Rollup merge of #79484 - sreehax:master r=Mark-Simulacrum add enable-full-tools to freebsd builds to prevent occasional link er… On FreeBSD there is sometimes an issue where linking a rust program will fail due to rust not finding a linker even though lld is included in the base system. This seems to mostly affect bare metal/cross compilation things such as wasm builds and arm/riscv bare metal work (eg. when trying to compile [this](https://github.com/quantumscraps/scraps)). On Linux and other operating systems full tools are enabled for builds of rust so there are no linking issues. This pr should enable fully functional builds on FreeBSD assuming rust builds correctly with these options.,THUMBS_UP,2021-02-11T17:36:56Z,khng300,NA https://github.com/rust-lang/rust/pull/79484,MERGED,2020-11-28T00:42:08Z,2020-11-29T04:54:18Z,add enable-full-tools to freebsd builds to prevent occasional link er…,sreehax,c9c81d92a96531d72782fb24f923e972facab6f4,1,Rollup merge of #79484 - sreehax:master r=Mark-Simulacrum add enable-full-tools to freebsd builds to prevent occasional link er… On FreeBSD there is sometimes an issue where linking a rust program will fail due to rust not finding a linker even though lld is included in the base system. This seems to mostly affect bare metal/cross compilation things such as wasm builds and arm/riscv bare metal work (eg. when trying to compile [this](https://github.com/quantumscraps/scraps)). On Linux and other operating systems full tools are enabled for builds of rust so there are no linking issues. This pr should enable fully functional builds on FreeBSD assuming rust builds correctly with these options.,THUMBS_UP,2021-02-11T18:36:39Z,dmilith,NA https://github.com/rust-lang/rust/pull/79484,MERGED,2020-11-28T00:42:08Z,2020-11-29T04:54:18Z,add enable-full-tools to freebsd builds to prevent occasional link er…,sreehax,c9c81d92a96531d72782fb24f923e972facab6f4,1,Rollup merge of #79484 - sreehax:master r=Mark-Simulacrum add enable-full-tools to freebsd builds to prevent occasional link er… On FreeBSD there is sometimes an issue where linking a rust program will fail due to rust not finding a linker even though lld is included in the base system. This seems to mostly affect bare metal/cross compilation things such as wasm builds and arm/riscv bare metal work (eg. when trying to compile [this](https://github.com/quantumscraps/scraps)). On Linux and other operating systems full tools are enabled for builds of rust so there are no linking issues. This pr should enable fully functional builds on FreeBSD assuming rust builds correctly with these options.,HEART,2021-02-12T00:33:14Z,dmilith,NA https://github.com/rust-lang/rust/pull/79485,MERGED,2020-11-28T01:03:47Z,2020-12-18T14:31:08Z,Stabilize `unsafe_cell_get_mut`,BoxyUwU,6340607acaab10eed3cf11ef7ad3564db58ec981,2,Auto merge of #79485 - EllenNyan:stabilize_unsafe_cell_get_mut r=m-ou-se Stabilize `unsafe_cell_get_mut` Tracking issue: #76943 r? `@m-ou-se`,HOORAY,2020-11-30T11:25:08Z,a1phyr,NA https://github.com/rust-lang/rust/pull/79485,MERGED,2020-11-28T01:03:47Z,2020-12-18T14:31:08Z,Stabilize `unsafe_cell_get_mut`,BoxyUwU,6340607acaab10eed3cf11ef7ad3564db58ec981,2,Auto merge of #79485 - EllenNyan:stabilize_unsafe_cell_get_mut r=m-ou-se Stabilize `unsafe_cell_get_mut` Tracking issue: #76943 r? `@m-ou-se`,HOORAY,2020-12-17T03:51:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,THUMBS_UP,2020-11-28T11:43:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,ROCKET,2020-11-28T13:13:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,ROCKET,2021-06-04T23:13:23Z,chrisprobst,NA https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,THUMBS_UP,2021-06-04T23:13:25Z,chrisprobst,NA https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,ROCKET,2021-07-01T07:20:49Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,THUMBS_UP,2021-08-04T05:52:42Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/79500,OPEN,2020-11-28T10:48:50Z,NA,Add support for custom allocator for `(C)String`,TimDiekmann,NA,NA,NA,THUMBS_UP,2022-01-12T02:28:57Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/79511,MERGED,2020-11-28T17:14:32Z,2020-11-29T01:04:44Z,Do not visit ForeignItemRef for HIR indexing and validation.,cjgillot,914d07ae5f90f01f138e66807873295fceaa9a26,3,Auto merge of #79511 - cjgillot:fitem-2 r=lcnr Do not visit ForeignItemRef for HIR indexing and validation. Similarly to what is done for ImplItemRef and TraitItemRef. Fixes #79487 r? `@lcnr`,THUMBS_UP,2020-11-28T17:40:06Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2020-11-28T22:01:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2021-01-10T21:48:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2021-01-11T01:14:31Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2021-01-11T01:25:07Z,camelid,NA https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,HEART,2021-01-11T01:25:10Z,camelid,NA https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,HEART,2021-01-26T19:46:34Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2021-03-11T15:01:18Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/79519,MERGED,2020-11-28T20:51:03Z,2021-03-10T11:21:58Z,Store HIR attributes in a side table,cjgillot,dff1edf919198aa4dea106e63b7d1899f1061fe0,88,Auto merge of #79519 - cjgillot:noattr r=wesleywiser Store HIR attributes in a side table Same idea as #72015 but for attributes. The objective is to reduce incr-comp invalidations due to modified attributes. Notably those due to modified doc comments. Implementation: - collect attributes during AST->HIR lowering in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables; - access the attributes through a `hir_owner_attrs` query; - local refactorings to use this access; - remove `attrs` from HIR data structures one-by-one. Change in behaviour: - the HIR visitor traverses all attributes at once instead of parent-by-parent; - attribute arrays are sometimes duplicated: for statements and variant constructors; - as a consequence attributes are marked as used after unused-attribute lint emission to avoid duplicate lints. ~~Current bug: the lint level is not correctly applied in `std::backtrace_rs` triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~,ROCKET,2021-03-18T18:33:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79522,MERGED,2020-11-28T21:41:50Z,2020-12-01T14:30:01Z,Validate lint docs separately.,ehuss,36ce8db2290c32e1d1f2acc422d5ddb28ed9a9a9,7,Rollup merge of #79522 - ehuss:lint-check-validate r=Mark-Simulacrum Validate lint docs separately. This addresses some concerns raised in https://github.com/rust-lang/rust/pull/76549#issuecomment-727638552 about errors with the lint docs being confusing and cumbersome. Errors from validating the lint documentation were being generated during `x.py doc` (and `x.py dist`) since extraction and validation are being done in a single step. This changes it so that extraction and validation are separated so that `x.py doc` will not error if there is a validation problem and tests are moved to `x.py test src/tools/lint-docs`. This includes the following changes: * Separate validation to `x.py test`. * Added some more documentation on how to more easily modify and test the docs. * Added more help to the error messages to hopefully provide more information on how to fix things. The first commit just moves the code around so you may consider looking at the other commits for a smaller diff.,HEART,2020-11-28T22:09:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,HEART,2020-11-29T01:47:16Z,varkor,NA https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,THUMBS_UP,2020-11-29T07:43:56Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,HEART,2020-11-29T15:45:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,THUMBS_UP,2020-11-29T15:45:22Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,THUMBS_UP,2020-12-10T06:42:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79523,MERGED,2020-11-28T22:11:20Z,2020-11-29T21:04:24Z,Fix overlap detection of `usize`/`isize` range patterns,Nadrieril,b776d1c3e3db8befabb123ebb1e46c3531eaed46,4,Auto merge of #79523 - Nadrieril:fix-usize-ranges r=varkor Fix overlap detection of `usize`/`isize` range patterns `usize` and `isize` are a bit of a special case in the match usefulness algorithm because the range of values they contain depends on the platform. Specifically we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges i.e. with limited cleverness. This means we didn't catch the following as unreachable: ```rust match 0usize { 0..10 => {} 10..20 => {} 5..15 => {} // oops should be detected as unreachable _ => {} } ``` This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive. r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,HEART,2021-02-04T08:20:31Z,langurmonkey,NA https://github.com/rust-lang/rust/pull/79536,MERGED,2020-11-29T15:32:40Z,2020-12-10T17:49:47Z,ci: use 20.04 on x86_64-gnu-nopt builder,davidtwco,80cc2ecf1070728a7d006026e0d532d9fc48621c,1,Auto merge of #79536 - davidtwco:focal-fossa-ci r=pietroalbini ci: use 20.04 on x86_64-gnu-nopt builder Switch the `x86_64-gnu-nopt` builder to use Ubuntu 20.04. Ubuntu 20.04 has a more recent gdb version than Ubuntu 16.04 (9.1 vs 7.11.1) which is required for rust-lang/rust#77177 as 16.04's gdb 7.11.1 crashes in some cases with Split DWARF. `x86_64-gnu-nopt` is chosen because it runs compare modes which is how Split DWARF testing is implemented in rust-lang/rust#77177. I've not confirmed that the issue is resolved with gdb 9.1 (Feb 2020) but system was using gdb 9.2 (May 2020) and that was fine and it seems more likely to me that the bug was resolved between gdb 7.11.1 (May 2016) and gdb 9.1. Updating a builder to use 20.04 was suggested by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/pull/77117#issuecomment-731846170. I'm not sure if this is the only change that is required - if more are necessary then I'm happy to do that. r? `@pietroalbini` cc `@Mark-Simulacrum`,THUMBS_UP,2020-11-29T16:48:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79536,MERGED,2020-11-29T15:32:40Z,2020-12-10T17:49:47Z,ci: use 20.04 on x86_64-gnu-nopt builder,davidtwco,80cc2ecf1070728a7d006026e0d532d9fc48621c,1,Auto merge of #79536 - davidtwco:focal-fossa-ci r=pietroalbini ci: use 20.04 on x86_64-gnu-nopt builder Switch the `x86_64-gnu-nopt` builder to use Ubuntu 20.04. Ubuntu 20.04 has a more recent gdb version than Ubuntu 16.04 (9.1 vs 7.11.1) which is required for rust-lang/rust#77177 as 16.04's gdb 7.11.1 crashes in some cases with Split DWARF. `x86_64-gnu-nopt` is chosen because it runs compare modes which is how Split DWARF testing is implemented in rust-lang/rust#77177. I've not confirmed that the issue is resolved with gdb 9.1 (Feb 2020) but system was using gdb 9.2 (May 2020) and that was fine and it seems more likely to me that the bug was resolved between gdb 7.11.1 (May 2016) and gdb 9.1. Updating a builder to use 20.04 was suggested by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/pull/77117#issuecomment-731846170. I'm not sure if this is the only change that is required - if more are necessary then I'm happy to do that. r? `@pietroalbini` cc `@Mark-Simulacrum`,THUMBS_UP,2020-11-29T20:20:46Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-11-29T23:17:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HEART,2020-11-30T01:03:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-11-30T20:54:19Z,tmandry,NA https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-11-30T22:48:12Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-01T09:57:34Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HEART,2020-12-01T09:57:36Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-01T09:57:50Z,rrbutani,NA https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-01T23:38:07Z,dsherret,NA https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-10T06:46:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-16T07:37:52Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/79539,MERGED,2020-11-29T20:53:24Z,2020-12-03T02:01:01Z,Rustdoc: JSON backend experimental impl with new tests.,aDotInTheVoid,7dc1e852d43cb8c9e77dc1e53014f0eb85d2ebfb,14,Auto merge of #79539 - aDotInTheVoid:json-mvp r=jyn514 Rustdoc: JSON backend experimental impl with new tests. Based on #75114 by `@P1n3appl3` The first commit is all of #75114 but squased to 1 commit as that was much easier to rebase onto master. The git history is a mess but I think I'll edit it after review so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish) but stuff like [not using a hashmap](https://github.com/rust-lang/rust/pull/75114#discussion_r519474420) and [using `CRATE_DEF_INDEX` ](https://github.com/rust-lang/rust/pull/75114#discussion_r519470764) hasn't) I'm also sure how many of these we need to do before landing on nightly as it would be nice to get this in tree so it isn't effected by churn like #79125 #79041 #79061 r? `@jyn514`,HOORAY,2020-12-21T14:56:08Z,lpil,louis@lpil.uk https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-11-29T22:03:46Z,camelid,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-11-29T23:16:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2020-11-29T23:16:09Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-11-30T03:02:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-12-03T23:14:30Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-12-09T16:52:49Z,sasurau4,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-12-23T19:42:14Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2020-12-23T19:42:19Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2020-12-27T11:37:05Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2020-12-27T11:37:06Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2020-12-27T19:08:21Z,camelid,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2020-12-29T19:58:08Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-01-01T15:20:26Z,moshg,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-02-09T15:11:23Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-02-10T01:00:19Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-02-10T03:26:53Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2021-02-10T03:26:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-02-10T05:09:57Z,amadeusine,NA https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-02-18T17:22:37Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HOORAY,2021-09-29T07:01:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79540,MERGED,2020-11-29T21:11:36Z,2021-02-09T18:37:55Z,Allow building rustdoc without first building rustc (MVP),jyn514,185de5f41a64e1b790524d5873dc1f7e368f64ab,7,Auto merge of #79540 - jyn514:no-xpy r=Mark-Simulacrum Allow building rustdoc without first building rustc (MVP) ## Motivation The compile times for rustc are extremely long and a major issue for recruiting new contributors to rustdoc. People interested in joining often give up after running into issues with submodules or python versions. stage1 rustdoc fundamentally doesn't care about bootstrapping or stages it just needs `rustc_private` available. ## Summary of Changes - Add an opt-in `[rust] download_rustc` option - Determine the version of the compiler to download using `log --author=bors` - Do no work for any component other than `Rustdoc` for any stage. Instead copy the CI artifacts from the downloaded sysroot stage0/ to stage0-sysroot/ or stage1/ in `Sysroot`. This is done with an `ENABLE_DOWNLOAD_STAGE1` constant which is off by default. - Don't download different versions of rustfmt or cargo - those should still use the beta version (rustfmt especially). The vast majority of work is done in bootstrap.py which downloads the artifacts and extracts them to stage0/ in place of the beta compiler. Rustbuild just takes care of copying the artifacts to stage1 if necessary. ## Future work - I turned off verification for the commit tarballs because the .sha256 URLs gave a 404. This seems not ideal it would be nice to start signing them. - This will break if you rebase an old enough branch (I think commits are kept at most 160 days?). This doesn't need to be supported but it would be nice to give a reasonable error. https://github.com/rust-lang/rust/pull/79540#issuecomment-751481291 - Right now every time you rebase stage0 tools (bootstrap tidy ...) will have to be recompiled. Additionally running `x.py setup tools` will compile rustbuild twice. Instead this should download a separate beta compiler for stage0 and only use CI artifacts for stage1 onward. https://github.com/rust-lang/rust/pull/79540#issuecomment-757047321 - Add `x.py setup tools` to enable this conveniently (it doesn't make sense to use this for compiler developers). https://github.com/jyn514/rust/commit/cb5d8c85226c501bf9deb39082a08af0ebfae850 - Compile a new version of tracing so that rustdoc still gets debug logging (since CI artifacts always disable `debug` and `trace` logging). https://github.com/rust-lang/rust/pull/79540#issuecomment-742756411 https://github.com/jyn514/rust/commit/6a5d5124209bec7652e745725a995bd77bb3f881 - Right now only rustdoc is ever rebuilt. This is not ideal and should probably at least compile compiler tools (rustfmt clippy miri). https://github.com/rust-lang/rust/pull/79540#issuecomment-775634693 - Using `git log --author=bors` sometimes breaks. This should use `git merge-base` instead. https://github.com/rust-lang/rust/pull/79540#discussion_r572572280 - It would be nice to support cross-compiling the standard library. Right now this gives an assertion failure I think. Some of this work has already been done in (the history for) https://github.com/jyn514/rust/commit/673476c785bc1fbff175cb7f49ad487c7a2b0337.,HEART,2021-09-29T07:01:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2020-11-30T02:04:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2020-11-30T08:50:05Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2020-11-30T11:24:56Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2020-11-30T11:28:28Z,a1phyr,NA https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2021-02-11T20:51:11Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/79548,MERGED,2020-11-30T02:03:25Z,2020-12-01T14:30:01Z,Show since when a function is const in stdlib,CraftSpider,33d7b8c65c6180143dfddbc4c7556c910fe1b9c8,7,Rollup merge of #79548 - CraftSpider:76998 r=jyn514 Show since when a function is const in stdlib Fixes #76998 This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const alongside what version they were declared stable. Example from `Result`: ![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png) r? ``@jyn514``,HEART,2021-10-27T09:57:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79553,MERGED,2020-11-30T07:08:53Z,2020-12-12T02:40:20Z,Capture precise paths in THIR and MIR,arora-aman,5bd9b60333b3dc0a51e7a5607cd1e0d537a9f718,41,Auto merge of #79553 - sexxi-goose:mir_min_cap_writeback r=nikomatsakis Capture precise paths in THIR and MIR This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths To achieve we: - Writeback min capture results to TypeckResults - Move handling upvars to PlaceBuilder in mir_build - Lower precise paths in THIR build by reading min_captures - Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar Closes: https://github.com/rust-lang/project-rfc-2229/issues/10 Partly implements: rust-lang/project-rfc-2229#18 Work that remains (not in this PR): - [ ] [Known bugs when feature gate is enabled](https://github.com/rust-lang/project-rfc-2229/projects/1?card_filter_query=label%3Abug) - [ ] Use min_capure_map for - [ ] Liveness analysis - [ ] rustc_mir/interpret/validity.rs - [ ] regionck - [ ] rust-lang/project-rfc-2229#8 - [ ] remove closure_captures and upvar_capture_map r? `@ghost`,HEART,2020-12-11T23:07:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-11-30T12:52:22Z,yasammez,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-11-30T13:48:08Z,cynecx,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-01T11:08:36Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-01T20:05:21Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-06T09:28:23Z,M-Adoo,Adoo@outlook.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-16T15:55:39Z,vultix,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-21T21:47:01Z,fakeshadow,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-24T11:37:41Z,mzji,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2020-12-24T11:37:44Z,mzji,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2020-12-24T11:38:19Z,mzji,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-25T23:03:47Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2020-12-26T02:40:17Z,lord,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-03T02:26:58Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-03T15:08:51Z,cynecx,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2021-02-03T22:18:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-03T22:18:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-03T22:18:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-06T08:16:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-06T09:22:17Z,Enet4,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-06T09:22:17Z,Enet4,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HEART,2021-02-06T11:22:10Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-06T12:05:47Z,RustyYato,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-08T02:15:20Z,kornholi,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-09T11:41:18Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2021-02-09T14:19:55Z,gliderkite,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-10T01:28:39Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-02-11T10:24:30Z,rhysd,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-02-11T10:24:31Z,rhysd,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-03-11T01:18:10Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-08-03T20:38:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2021-08-04T10:08:12Z,fwcd,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-08-04T10:08:12Z,fwcd,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HEART,2021-08-04T10:08:13Z,fwcd,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2021-08-06T14:00:51Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HOORAY,2021-08-06T14:00:52Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,HEART,2021-08-06T14:00:53Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,ROCKET,2021-08-06T14:00:54Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,EYES,2021-08-07T08:09:40Z,becherling,NA https://github.com/rust-lang/rust/pull/79554,MERGED,2020-11-30T09:07:58Z,2021-02-05T14:53:01Z,Generic associated types in trait paths,b-naber,deec6a96d428d20250bfad2317c00fc67e4b70f0,43,Rollup merge of #79554 - b-naber:generic-associated-types-in-trait-paths r=jackh726 Generic associated types in trait paths This is the second part of https://github.com/rust-lang/rust/pull/78978 This should fix: Fixes #67510 Fixes #68648 Fixes #68649 Fixes #68650 Fixes #68652 Fixes #74684 Fixes #76535 Fixes #79422 Fixes #80433 and implement the remaining functionality needed for https://github.com/rust-lang/rust/issues/44265 r? ``@matthewjasper``,THUMBS_UP,2021-09-23T11:26:18Z,Voronar,NA https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2020-11-30T18:20:52Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-01-10T00:59:48Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-01-20T16:14:56Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-01-23T21:02:50Z,tux3,NA https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-01-31T19:54:00Z,dvdplm,dvdplm@gmail.com https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-02-04T07:50:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79570,MERGED,2020-11-30T16:46:19Z,2021-01-29T04:06:44Z,rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`,alexcrichton,d9e56f48c5ed6d40fff4e3277735df605e143791,21,Rollup merge of #79570 - alexcrichton:split-debuginfo r=bjorn3 rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361 but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default but that's a problem left to get tackled another day. Closes #79361,HEART,2021-09-23T15:22:55Z,TrAyZeN,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-11-30T20:05:19Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-11-30T20:09:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-11-30T20:39:28Z,camelid,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-01T00:45:21Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-01T00:45:22Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-01T04:21:12Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-01T04:21:13Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-01T05:36:56Z,liigo,liigo@qq.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-01T08:59:40Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-01T08:59:41Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-01T09:26:23Z,kellytk,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-01T11:45:07Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-02T08:21:54Z,trevyn,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-02T17:06:59Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-04T11:33:23Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-19T02:15:55Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-19T02:15:56Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2020-12-19T02:16:00Z,meteor-lsw,chenkun_lws@126.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-23T00:33:32Z,yerke,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-23T00:33:33Z,yerke,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2020-12-23T00:33:34Z,yerke,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",ROCKET,2020-12-23T00:33:37Z,yerke,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-24T10:30:50Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2020-12-24T21:38:27Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2020-12-27T23:46:24Z,arora-aman,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-08T01:57:41Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2021-01-08T02:08:07Z,weihanglo,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-08T03:27:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-01-08T03:27:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2021-01-08T05:55:50Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-08T05:55:50Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-01-08T05:55:52Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",ROCKET,2021-01-08T05:55:52Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-08T08:46:42Z,robatipoor,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-08T20:54:26Z,chrish42,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2021-01-09T12:08:20Z,gentoid,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-01-09T12:08:21Z,gentoid,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-09T12:08:23Z,gentoid,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-09T20:28:09Z,GabrielMajeri,gabriel.majeri6@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-10T14:57:10Z,LU15W1R7H,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-12T23:47:45Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-01-12T23:47:46Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2021-01-14T17:50:41Z,fuszenecker,NA https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-22T05:47:51Z,rendaardy,renda_ardy@tutanota.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-29T22:46:53Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",THUMBS_UP,2021-01-31T12:59:18Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-01-31T12:59:19Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-01-31T12:59:21Z,no111u3,no111u3@gmail.com https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HOORAY,2021-02-14T15:53:06Z,Lynnesbian,lynne@bune.city https://github.com/rust-lang/rust/pull/79576,MERGED,2020-11-30T19:55:15Z,2021-01-01T07:46:12Z,Add edition 2021.,m-ou-se,f8ab56bf3201b0638e44caf5a484041f22e32d65,17,"Auto merge of #79576 - m-ou-se:2021 r=Mark-Simulacrum Add edition 2021. :fireworks: Happy new ~~year~~ Rust. :champagne: This adds --edition=2021 and updates suggestions about 2018 to say ""2018 *or later*"". Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922 --- Edit: This adds the new edition as *unstable*. Without `-Z unstable-options` `--edition=2021` results in: ``` $ rustc --edition=2021 error: edition 2021 is unstable and only available with -Z unstable-options. ```",HEART,2021-03-05T01:28:59Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/79585,CLOSED,2020-12-01T03:21:18Z,2020-12-01T08:17:11Z,Do not expose PollFn struct,win-t,NA,NA,NA,CONFUSED,2020-12-01T03:26:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79588,MERGED,2020-12-01T08:12:50Z,2021-01-13T07:39:04Z,Provide more information for HRTB lifetime errors involving closures,estebank,11bca6b07fc7b21e1c0ac9a011988b43468e9fe6,18,Rollup merge of #79588 - estebank:issue-79187 r=oli-obk Provide more information for HRTB lifetime errors involving closures,THUMBS_UP,2020-12-02T17:30:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-01T15:56:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-01T17:49:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-01T23:17:48Z,nnethercote,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-02T20:33:43Z,lqd,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-02T23:04:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-03T03:43:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-03T21:14:31Z,camelid,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-22T22:36:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-31T04:35:08Z,tux3,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-31T07:57:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2020-12-31T11:49:55Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/79589,MERGED,2020-12-01T08:22:59Z,2020-12-24T04:02:25Z,rustc_query_system: reduce dependency graph memory usage,tgnottingham,49b315123e6adb35024437ef7ba408456771c062,3,"Auto merge of #79589 - tgnottingham:shared_dep_graph r=michaelwoerister rustc_query_system: reduce dependency graph memory usage This change implements at a high level two space optimizations to the dependency graph. The first optimization is sharing graph data with the previous dependency graph. Whenever we intern a node we know whether that node is new (not in the previous graph) or not and if not the color of the node in the previous graph. Red and green nodes have their `DepNode` present in the previous graph so for that piece of node data we can just store the index of the node in the previous graph rather than duplicate the `DepNode`. Green nodes additionally have the the same result `Fingerprint` so we can avoid duplicating that too. Finally we distinguish between ""light"" and ""dark"" green nodes where the latter are nodes that were marked green because all of their dependencies were marked green. These nodes can additionally share edges with the previous graph because we know that their set of dependencies is the same (technically light green and red nodes can have the same dependencies too but we don't try to figure out whether or not that's the case). Also some effort is made to pack data tightly and to avoid storing `DepNode`s as map keys more than once. The second optimization is storing edges in a more compact representation as in the `SerializedDepGraph` that is in a single vector rather than one `EdgesVec` per node. An `EdgesVec` is a `SmallVec` with an inline buffer for 8 elements. Each `EdgesVec` is at minimum 40 bytes and has a per-node overhead of up to 40 bytes. In the ideal case of exactly 8 edges then 32 bytes are used for edges and the overhead is 8 bytes. But most of the time the overhead is higher. In contrast using a single vector to store all edges and having each node specify its start and end elements as 4 byte indices into the vector has a constant overhead of 8 bytes--the best case scenario for the per-node `EdgesVec` approach. The downside of this approach is that `EdgesVec`s built up during query execution have to be copied into the vector whereas before we could just take ownership over them. However we mostly make up for this because the single vector representation enables a more efficient implementation of `DepGraph::serialize`.",HEART,2021-01-02T21:55:16Z,wildbook,NA https://github.com/rust-lang/rust/pull/79594,MERGED,2020-12-01T10:11:53Z,2020-12-03T12:14:34Z,add const_allocate intrinsic,vn-ki,d015f0d92144f0e72735a918aee8510b0fe2cff5,28,Auto merge of #79594 - vn-ki:const-eval-intrinsic r=oli-obk add const_allocate intrinsic r? `@oli-obk` fixes #75390,HEART,2020-12-01T13:00:17Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79594,MERGED,2020-12-01T10:11:53Z,2020-12-03T12:14:34Z,add const_allocate intrinsic,vn-ki,d015f0d92144f0e72735a918aee8510b0fe2cff5,28,Auto merge of #79594 - vn-ki:const-eval-intrinsic r=oli-obk add const_allocate intrinsic r? `@oli-obk` fixes #75390,HEART,2021-05-26T14:49:41Z,Zymlex,NA https://github.com/rust-lang/rust/pull/79594,MERGED,2020-12-01T10:11:53Z,2020-12-03T12:14:34Z,add const_allocate intrinsic,vn-ki,d015f0d92144f0e72735a918aee8510b0fe2cff5,28,Auto merge of #79594 - vn-ki:const-eval-intrinsic r=oli-obk add const_allocate intrinsic r? `@oli-obk` fixes #75390,THUMBS_UP,2021-05-26T14:49:45Z,Zymlex,NA https://github.com/rust-lang/rust/pull/79599,CLOSED,2020-12-01T13:49:39Z,2020-12-08T22:05:51Z,Adding diesel to the cargetest suite,weiznich,NA,NA,NA,HEART,2020-12-02T11:34:17Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79600,MERGED,2020-12-01T13:58:59Z,2020-12-02T02:07:44Z,std::io: Use sendfile for UnixStream,nicokoch,9e26fc60b1a91e28e799fd3ed33f8b93db13be2a,2,Rollup merge of #79600 - nicokoch:kernel_copy_unixstream r=m-ou-se std::io: Use sendfile for UnixStream `UnixStream` was forgotten in #75272 . Benchmark yields the following results. Before: `running 1 test test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 54 399 ns/iter (+/- 6 817) = 2409 MB/s` After: `running 1 test test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 18 627 ns/iter (+/- 6 007) = 7036 MB/s`,THUMBS_UP,2020-12-01T15:41:23Z,the8472,NA https://github.com/rust-lang/rust/pull/79600,MERGED,2020-12-01T13:58:59Z,2020-12-02T02:07:44Z,std::io: Use sendfile for UnixStream,nicokoch,9e26fc60b1a91e28e799fd3ed33f8b93db13be2a,2,Rollup merge of #79600 - nicokoch:kernel_copy_unixstream r=m-ou-se std::io: Use sendfile for UnixStream `UnixStream` was forgotten in #75272 . Benchmark yields the following results. Before: `running 1 test test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 54 399 ns/iter (+/- 6 817) = 2409 MB/s` After: `running 1 test test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 18 627 ns/iter (+/- 6 007) = 7036 MB/s`,THUMBS_UP,2020-12-10T06:45:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79607,MERGED,2020-12-01T20:26:44Z,2020-12-16T09:13:22Z,MaybeUninit::copy/clone_from_slice,DrMeepster,ddbc6176de780987025c2cf22eb63922bc0c6253,3,Auto merge of #79607 - DrMeepster:maybe_uninit_write_slice r=m-ou-se MaybeUninit::copy/clone_from_slice This PR adds 2 new methods to MaybeUninit under the feature of `maybe_uninit_write_slice`: `copy_from_slice` and `clone_from_slice`. These are useful for initializing uninitialized buffers (such as the one returned by `Vec::spare_capacity_mut` for example) with initialized data. The methods behave similarly to the methods on slices but the destination is uninitialized and they return the destination slice as an initialized slice.,HOORAY,2020-12-10T14:24:37Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/79607,MERGED,2020-12-01T20:26:44Z,2020-12-16T09:13:22Z,MaybeUninit::copy/clone_from_slice,DrMeepster,ddbc6176de780987025c2cf22eb63922bc0c6253,3,Auto merge of #79607 - DrMeepster:maybe_uninit_write_slice r=m-ou-se MaybeUninit::copy/clone_from_slice This PR adds 2 new methods to MaybeUninit under the feature of `maybe_uninit_write_slice`: `copy_from_slice` and `clone_from_slice`. These are useful for initializing uninitialized buffers (such as the one returned by `Vec::spare_capacity_mut` for example) with initialized data. The methods behave similarly to the methods on slices but the destination is uninitialized and they return the destination slice as an initialized slice.,HOORAY,2021-04-15T20:21:19Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-01T20:43:17Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-01T23:55:20Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-02T12:35:36Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-02T21:37:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-06T14:49:11Z,tux3,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-08T15:02:37Z,aquarhead,aquarhead@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-14T06:48:07Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-15T12:31:48Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-15T13:03:20Z,asherkin,asherkin@limetech.io https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-15T13:41:33Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-15T15:17:11Z,kbknapp,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-15T15:17:16Z,kbknapp,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-15T16:10:11Z,schuermannator,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-15T16:33:16Z,icewind1991,robin@icewind.nl https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-15T17:50:02Z,devinus,d@devinus.io https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-15T17:50:04Z,devinus,d@devinus.io https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2020-12-15T17:50:07Z,devinus,d@devinus.io https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-17T08:57:49Z,innobead,innobead@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-24T05:09:12Z,zeroqn,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-24T05:09:14Z,zeroqn,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2020-12-26T02:50:35Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2020-12-26T02:50:39Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-01-01T00:06:31Z,bryandmc,bryan.mccoid@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-01-01T00:06:37Z,bryandmc,bryan.mccoid@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2021-01-01T00:06:38Z,bryandmc,bryan.mccoid@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-01-10T03:30:50Z,dvc94ch,david@craven.ch https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2021-01-10T03:30:53Z,dvc94ch,david@craven.ch https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-01-10T03:41:41Z,dvc94ch,david@craven.ch https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-03-08T01:11:34Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-10T13:21:45Z,iamyulong,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-06-10T13:21:47Z,iamyulong,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-11T02:15:15Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-11T12:25:47Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-06-11T12:25:48Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2021-06-12T09:42:23Z,thangchung,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-15T14:50:22Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-06-15T14:50:23Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2021-06-15T14:50:23Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HEART,2021-06-15T14:50:28Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HOORAY,2021-06-15T14:50:32Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-17T04:26:42Z,lambdabear,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-22T12:25:26Z,fanatid,fanatid@ya.ru https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-24T12:33:36Z,ken109,kensukekubo19@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HOORAY,2021-06-25T08:57:39Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HEART,2021-06-29T21:40:57Z,garious,greg@solana.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,EYES,2021-06-29T21:40:59Z,garious,greg@solana.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-06-29T21:40:59Z,garious,greg@solana.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-06-29T21:41:01Z,garious,greg@solana.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HOORAY,2021-06-29T21:41:02Z,garious,greg@solana.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,ROCKET,2021-07-26T22:02:10Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-08-07T05:18:13Z,microidea,huangbeidu@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-09-10T02:48:57Z,tonyluj,tonyluj@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-11-25T16:17:15Z,kakkoyun,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HEART,2021-11-25T16:17:16Z,kakkoyun,NA https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,THUMBS_UP,2021-12-09T05:44:56Z,lwintermelon,returnhs@gmail.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HEART,2022-01-09T01:15:59Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/79608,MERGED,2020-12-01T20:38:15Z,2021-06-06T03:29:39Z,BPF target support,alessandrod,f434217aab9abf583ebc928b97ab4116921137aa,33,Auto merge of #79608 - alessandrod:bpf r=nagisa BPF target support This adds `bpfel-unknown-none` and `bpfeb-unknown-none` two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker. I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.,HEART,2022-05-30T20:54:04Z,v-thakkar,NA https://github.com/rust-lang/rust/pull/79611,MERGED,2020-12-01T22:15:01Z,2020-12-04T07:11:31Z,Use more std:: instead of core:: in docs for consistency,poliorcetics,88f0c72dc693cd1391fab4f60df861b245db5d12,7,Rollup merge of #79611 - poliorcetics:use-std-in-docs r=jyn514 Use more std:: instead of core:: in docs for consistency ``@rustbot`` label T-doc Some cleanup work to use `std::` instead of `core::` in docs as much as possible. This helps with terminology and consistency especially for newcomers from other languages that have often heard of `std` to describe the standard library but not of `core`. Edit: I also added more intra doc links when I saw the opportunity.,LAUGH,2020-12-01T22:52:07Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79611,MERGED,2020-12-01T22:15:01Z,2020-12-04T07:11:31Z,Use more std:: instead of core:: in docs for consistency,poliorcetics,88f0c72dc693cd1391fab4f60df861b245db5d12,7,Rollup merge of #79611 - poliorcetics:use-std-in-docs r=jyn514 Use more std:: instead of core:: in docs for consistency ``@rustbot`` label T-doc Some cleanup work to use `std::` instead of `core::` in docs as much as possible. This helps with terminology and consistency especially for newcomers from other languages that have often heard of `std` to describe the standard library but not of `core`. Edit: I also added more intra doc links when I saw the opportunity.,CONFUSED,2020-12-01T23:30:02Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79620,MERGED,2020-12-02T02:43:02Z,2020-12-03T21:14:21Z,Tweak diagnostics on shadowing lifetimes/labels,JohnTitor,5be3f9f10e9fd59ea03816840a6051413fbdefae,13,Auto merge of #79620 - JohnTitor:label-name-sugg r=davidtwco Tweak diagnostics on shadowing lifetimes/labels Fixes #79610 Skip adding a new test assuming we have already sufficient tests.,HEART,2020-12-04T10:43:05Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/79621,MERGED,2020-12-02T02:50:14Z,2020-12-10T12:52:26Z,Constier maybe uninit,usbalbin,39b841dfe36f90a7cd111e7f0c55f32594f6e578,12,Auto merge of #79621 - usbalbin:constier_maybe_uninit r=RalfJung Constier maybe uninit I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited()` and therefore `MaybeUninit::assume_init` not being `const`? --- I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done? Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?,HEART,2020-12-02T09:52:59Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79621,MERGED,2020-12-02T02:50:14Z,2020-12-10T12:52:26Z,Constier maybe uninit,usbalbin,39b841dfe36f90a7cd111e7f0c55f32594f6e578,12,Auto merge of #79621 - usbalbin:constier_maybe_uninit r=RalfJung Constier maybe uninit I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited()` and therefore `MaybeUninit::assume_init` not being `const`? --- I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done? Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?,ROCKET,2020-12-02T10:40:26Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79621,MERGED,2020-12-02T02:50:14Z,2020-12-10T12:52:26Z,Constier maybe uninit,usbalbin,39b841dfe36f90a7cd111e7f0c55f32594f6e578,12,Auto merge of #79621 - usbalbin:constier_maybe_uninit r=RalfJung Constier maybe uninit I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited()` and therefore `MaybeUninit::assume_init` not being `const`? --- I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done? Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?,EYES,2020-12-02T11:02:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/79621,MERGED,2020-12-02T02:50:14Z,2020-12-10T12:52:26Z,Constier maybe uninit,usbalbin,39b841dfe36f90a7cd111e7f0c55f32594f6e578,12,Auto merge of #79621 - usbalbin:constier_maybe_uninit r=RalfJung Constier maybe uninit I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited()` and therefore `MaybeUninit::assume_init` not being `const`? --- I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done? Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?,HEART,2020-12-17T03:43:24Z,GrayJack,NA https://github.com/rust-lang/rust/pull/79627,MERGED,2020-12-02T06:39:34Z,2020-12-04T07:11:31Z,Update cargo,ehuss,aef5edddc6956d3b487137bc71a68f1f694f690c,1,"Rollup merge of #79627 - ehuss:update-cargo r=ehuss Update cargo 12 commits in bfca1cd22bf514d5f2b6c1089b0ded0ba7dfaa6e..63d0fe43449adcb316d34d98a982b597faca4178 2020-11-24 16:33:21 +0000 to 2020-12-02 01:44:30 +0000 - Add ""--workspace"" to update command (rust-lang/cargo#8725) - Add an FAQ for ""Why is my crate rebuilt?"" (rust-lang/cargo#8927) - Set docs.rs as the default extern-map for crates.io (rust-lang/cargo#8877) - remove extra whitespace when running cargo -Z help (rust-lang/cargo#8924) - Remove version from dev-dependencies to make it easier to publish. (rust-lang/cargo#8920) - update dependency queue to consider cost for each node (rust-lang/cargo#8908) - Fix some rustdoc warnings. (rust-lang/cargo#8911) - Bump miow dependency to not invalidly assume memory layout (rust-lang/cargo#8909) - Remove unnecessary trailing semicolons (rust-lang/cargo#8906) - Fix custom_target_dependency test. (rust-lang/cargo#8907) - fix: we don't ignore `version` for `git`/`path` deps now (rust-lang/cargo#8900) - doc (book): add ""Getting Started"" subsection: ""Essential Terminology"" (rust-lang/cargo#8855)",THUMBS_UP,2020-12-02T16:21:17Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79637,MERGED,2020-12-02T15:22:02Z,2020-12-03T04:13:45Z,"Revert ""Auto merge of #79209",spastorino,b4def89d76896eec73b4af33642ba7e5eb53c567,28,"Auto merge of #79637 - spastorino:revert-trait-inheritance-self r=Mark-Simulacrum Revert ""Auto merge of #79209 r? `@nikomatsakis` This has caused some issues (#79560) so better to revert and try to come up with a proper fix without rush.",THUMBS_UP,2020-12-02T16:54:28Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79637,MERGED,2020-12-02T15:22:02Z,2020-12-03T04:13:45Z,"Revert ""Auto merge of #79209",spastorino,b4def89d76896eec73b4af33642ba7e5eb53c567,28,"Auto merge of #79637 - spastorino:revert-trait-inheritance-self r=Mark-Simulacrum Revert ""Auto merge of #79209 r? `@nikomatsakis` This has caused some issues (#79560) so better to revert and try to come up with a proper fix without rush.",THUMBS_UP,2020-12-02T19:07:39Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/79659,CLOSED,2020-12-03T11:09:18Z,2021-04-02T12:22:37Z,Add Iterator::collect_array method,matklad,NA,NA,NA,THUMBS_UP,2021-01-24T13:58:30Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/79659,CLOSED,2020-12-03T11:09:18Z,2021-04-02T12:22:37Z,Add Iterator::collect_array method,matklad,NA,NA,NA,THUMBS_UP,2021-01-31T08:59:35Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/79659,CLOSED,2020-12-03T11:09:18Z,2021-04-02T12:22:37Z,Add Iterator::collect_array method,matklad,NA,NA,NA,THUMBS_UP,2021-02-13T15:41:01Z,taiki-e,NA https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2020-12-03T16:04:59Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2020-12-04T00:07:38Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,HOORAY,2020-12-04T00:07:40Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2020-12-06T11:51:19Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,HOORAY,2020-12-06T11:51:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79665,CLOSED,2020-12-03T16:00:09Z,2021-03-01T02:16:50Z,Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.,steffahn,NA,NA,NA,THUMBS_UP,2021-03-08T21:45:56Z,stevenengler,NA https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",HEART,2020-12-03T19:53:11Z,camelid,NA https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",ROCKET,2020-12-03T19:53:13Z,camelid,NA https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",HOORAY,2020-12-03T20:13:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",HEART,2020-12-03T23:13:08Z,varkor,NA https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",HEART,2020-12-05T23:43:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79670,MERGED,2020-12-03T19:31:04Z,2021-01-13T01:40:52Z,Turn type inhabitedness into a query to fix `exhaustive_patterns` perf,Nadrieril,058a71016553f267ae80b90276ef79956457d51a,15,"Auto merge of #79670 - Nadrieril:uninhabited-query r=estebank Turn type inhabitedness into a query to fix `exhaustive_patterns` perf We measured in https://github.com/rust-lang/rust/pull/79394 that enabling the [`exhaustive_patterns` feature](https://github.com/rust-lang/rust/issues/51085) causes significant perf degradation. It was conjectured that the culprit is type inhabitedness checking and [I hypothesized](https://github.com/rust-lang/rust/pull/79394#issuecomment-733861149) that turning this computation into a query would solve most of the problem. This PR turns `tcx.is_ty_uninhabited_from` into a query and I measured a 25% perf gain on the benchmark that stress-tests `exhaustiveness_patterns`. This more than compensates for the 30% perf hit I measured [when creating it](https://github.com/rust-lang/rustc-perf/pull/801). We'll have to measure enabling the feature again but I suspect this fixes the perf regression entirely. I'd like a perf run on this PR obviously. I made small atomic commits to help reviewing. The first one is just me discovering the ""revisions"" feature of the testing framework. I believe there's a push to move things out of `rustc_middle` because it's huge. I guess `inhabitedness/mod.rs` could be moved out but it's quite small. `DefIdForest` might be movable somewhere too. I don't know what the policy is for that. Ping `@camelid` since you were interested in following along `@rustbot` modify labels: +A-exhaustiveness-checking",ROCKET,2021-01-12T01:00:52Z,estebank,NA https://github.com/rust-lang/rust/pull/79675,MERGED,2020-12-03T20:56:21Z,2021-01-08T05:58:55Z,Make sure rust-call errors occur correctly for traits,CraftSpider,0afd72e313ed6837f3a150619475a0a480b91802,3,Rollup merge of #79675 - CraftSpider:79669 r=estebank Make sure rust-call errors occur correctly for traits Fixes #79669 Adds trait method resolution to the error and adds UI tests to ensure it doesn't happen again. Opening as draft because I'm getting weird link errors from unrelated code on my machine and want to see what CI thinks.,HEART,2021-01-08T02:06:14Z,estebank,NA https://github.com/rust-lang/rust/pull/79677,CLOSED,2020-12-03T21:35:07Z,2021-12-10T02:43:31Z,Add warning sections in rustdoc,GuillaumeGomez,NA,NA,NA,HOORAY,2020-12-03T23:07:03Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/79677,CLOSED,2020-12-03T21:35:07Z,2021-12-10T02:43:31Z,Add warning sections in rustdoc,GuillaumeGomez,NA,NA,NA,HOORAY,2020-12-03T23:09:35Z,Cldfire,NA https://github.com/rust-lang/rust/pull/79680,MERGED,2020-12-03T22:48:16Z,2020-12-04T14:02:38Z,Fix perf regression caused by #79284,Nadrieril,2218520b8adf8b8e64b817537d9eb0a84840e2f1,1,Auto merge of #79680 - Nadrieril:fix-regression-79284 r=jonas-schievink Fix perf regression caused by #79284 https://github.com/rust-lang/rust/pull/79284 only moved code around but this changed inlining and caused a large perf regression. This fixes it for me though I'm less confident than usual because the regression was not observable with my usual (i.e. incremental) compilation settings. r? `@Mark-Simulacrum`,HEART,2020-12-04T09:33:09Z,rylev,NA https://github.com/rust-lang/rust/pull/79684,MERGED,2020-12-04T01:57:39Z,2020-12-30T15:31:00Z,Make copy[_nonoverlapping] const,usbalbin,bbcaed03bf5505f3fed351887769ed1531599502,12,Auto merge of #79684 - usbalbin:const_copy r=oli-obk Make copy[_nonoverlapping] const Constifies * `intrinsics::copy` and `intrinsics::copy_nonoverlapping` * `ptr::read` and `ptr::read_unaligned` * `*const T::read` and `*const T::read_unaligned` * `*mut T::read` and `*mut T::read_unaligned` * `MaybeUninit::assume_init_read`,EYES,2020-12-04T04:25:40Z,tesuji,NA https://github.com/rust-lang/rust/pull/79684,MERGED,2020-12-04T01:57:39Z,2020-12-30T15:31:00Z,Make copy[_nonoverlapping] const,usbalbin,bbcaed03bf5505f3fed351887769ed1531599502,12,Auto merge of #79684 - usbalbin:const_copy r=oli-obk Make copy[_nonoverlapping] const Constifies * `intrinsics::copy` and `intrinsics::copy_nonoverlapping` * `ptr::read` and `ptr::read_unaligned` * `*const T::read` and `*const T::read_unaligned` * `*mut T::read` and `*mut T::read_unaligned` * `MaybeUninit::assume_init_read`,THUMBS_UP,2021-01-08T02:01:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79689,MERGED,2020-12-04T05:33:26Z,2021-01-14T20:21:26Z,"Update tests of ""unused_lifetimes"" lint for async functions and corresponding source code",Vooblin,4275ef6c9d994bb6d0e2f42e0ee0aa1603a3c8a6,3,"Auto merge of #79689 - Vooblin:patch1 r=tmandry Update tests of ""unused_lifetimes"" lint for async functions and corresponding source code Before this PR the following code would cause an error: ``` #![deny(unused_lifetimes)] async fn f<'a>(_: &'a i32) {} fn main() {} ``` It was happening because of the desugaring of return type in async functions. As a result of the desugaring the return type contains all lifetimes involved in the function signature. And these lifetimes were interpreted separately from the same in the function scope => so they are unused. Now all lifetimes from the return type are interpreted as used. It is also not perfect but at least this lint doesn't cause wrong errors now. This PR connected to issues #78522 #77217",HEART,2021-01-14T21:20:03Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/79695,CLOSED,2020-12-04T08:44:44Z,2021-02-14T15:44:31Z,[const_panic] Report const_panic diagnostics identically to compiler_error invocations,mehcode,NA,NA,NA,HOORAY,2020-12-04T11:48:23Z,oli-obk,NA https://github.com/rust-lang/rust/pull/79695,CLOSED,2020-12-04T08:44:44Z,2021-02-14T15:44:31Z,[const_panic] Report const_panic diagnostics identically to compiler_error invocations,mehcode,NA,NA,NA,HOORAY,2020-12-04T19:56:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79695,CLOSED,2020-12-04T08:44:44Z,2021-02-14T15:44:31Z,[const_panic] Report const_panic diagnostics identically to compiler_error invocations,mehcode,NA,NA,NA,HEART,2020-12-23T13:22:18Z,jplatte,NA https://github.com/rust-lang/rust/pull/79697,MERGED,2020-12-04T10:39:13Z,2020-12-06T01:15:37Z,A slightly clearer diagnostic when misusing const,rylev,bb0d481b5a9e78145f5644ec46015065fa83b4cc,15,"Auto merge of #79697 - rylev:clearer-const-diagnostic r=oli-obk A slightly clearer diagnostic when misusing const Fixes #79598 This produces the following diagnostic: ""expected one of `>` a const expression lifetime or type found keyword `const`"" Instead of the previous more confusing: ""expected one of `>` const lifetime or type found keyword `const`"" This might not be completely clear as some users might not understand what a const expression is but I do believe this is an improvement.",THUMBS_UP,2020-12-05T17:46:57Z,fmease,NA https://github.com/rust-lang/rust/pull/79698,MERGED,2020-12-04T11:20:41Z,2020-12-11T07:54:29Z,Add tracking issue template for library features.,m-ou-se,8b9a59cb905f2f22c7de7713e38756b20289e0b9,1,Rollup merge of #79698 - m-ou-se:libs-tracking-issue-template r=KodrAus Add tracking issue template for library features. This adds a issue template for a library tracking issue. There's already a template for tracking issues but it's mostly geared towards compiler/language features. A separate template makes it a bit easier to make sure it matches with the process we use for library changes. Main differences: - Added a note about how small library features can be added without RFC and removed the parts that assume there's an RFC. - Merged the 'Steps' and 'History' sections: Library features are often small enough that there's no multiple steps planned ahead of time. - Removed the section about avoiding large discussions and opening separate issues for problems with the feature. Library features are usually focussed enough that the discussion about a feature is best kept together in the tracking issue. - Removed links to the rustc-dev-guide which are specific to changes in the compiler and language.,HEART,2020-12-04T17:33:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79698,MERGED,2020-12-04T11:20:41Z,2020-12-11T07:54:29Z,Add tracking issue template for library features.,m-ou-se,8b9a59cb905f2f22c7de7713e38756b20289e0b9,1,Rollup merge of #79698 - m-ou-se:libs-tracking-issue-template r=KodrAus Add tracking issue template for library features. This adds a issue template for a library tracking issue. There's already a template for tracking issues but it's mostly geared towards compiler/language features. A separate template makes it a bit easier to make sure it matches with the process we use for library changes. Main differences: - Added a note about how small library features can be added without RFC and removed the parts that assume there's an RFC. - Merged the 'Steps' and 'History' sections: Library features are often small enough that there's no multiple steps planned ahead of time. - Removed the section about avoiding large discussions and opening separate issues for problems with the feature. Library features are usually focussed enough that the discussion about a feature is best kept together in the tracking issue. - Removed links to the rustc-dev-guide which are specific to changes in the compiler and language.,HEART,2020-12-10T22:20:07Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-04T21:16:27Z,est31,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HOORAY,2020-12-04T21:16:29Z,est31,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-04T21:16:34Z,est31,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-05T03:11:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-05T18:15:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-08T17:59:45Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-08T17:59:46Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HOORAY,2020-12-08T17:59:48Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-09T23:27:45Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HOORAY,2020-12-09T23:27:46Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-09T23:27:46Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-29T11:22:56Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-30T19:23:55Z,yerke,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HOORAY,2020-12-30T19:23:56Z,yerke,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-30T19:23:57Z,yerke,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HEART,2020-12-31T19:22:39Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,THUMBS_UP,2020-12-31T19:22:41Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79706,CLOSED,2020-12-04T18:56:13Z,2021-01-23T09:34:47Z,[DO NOT MERGE] Enable parallel compiler by default,bjorn3,NA,NA,NA,HOORAY,2020-12-31T19:22:58Z,xsoheilalizadeh,NA https://github.com/rust-lang/rust/pull/79707,CLOSED,2020-12-04T19:54:49Z,2020-12-05T22:30:04Z,[Experiment] Add `never` as a type alias for `!`,Julian-Wollersberger,NA,NA,NA,THUMBS_DOWN,2020-12-04T20:51:50Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/79707,CLOSED,2020-12-04T19:54:49Z,2020-12-05T22:30:04Z,[Experiment] Add `never` as a type alias for `!`,Julian-Wollersberger,NA,NA,NA,THUMBS_DOWN,2020-12-04T21:10:13Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/79707,CLOSED,2020-12-04T19:54:49Z,2020-12-05T22:30:04Z,[Experiment] Add `never` as a type alias for `!`,Julian-Wollersberger,NA,NA,NA,THUMBS_UP,2020-12-05T00:35:47Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/79707,CLOSED,2020-12-04T19:54:49Z,2020-12-05T22:30:04Z,[Experiment] Add `never` as a type alias for `!`,Julian-Wollersberger,NA,NA,NA,THUMBS_UP,2020-12-05T03:27:16Z,tesuji,NA https://github.com/rust-lang/rust/pull/79707,CLOSED,2020-12-04T19:54:49Z,2020-12-05T22:30:04Z,[Experiment] Add `never` as a type alias for `!`,Julian-Wollersberger,NA,NA,NA,THUMBS_DOWN,2020-12-05T15:32:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/79718,CLOSED,2020-12-05T03:01:57Z,2020-12-31T00:51:38Z,Move `ui/issues` tests to some subdirectories by issue number,JohnTitor,NA,NA,NA,THUMBS_DOWN,2020-12-05T10:35:30Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-09T02:38:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-09T13:02:38Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-09T21:50:58Z,sharnoff,github@max.sharnoff.org https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-09T22:20:41Z,camelid,NA https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-11T15:09:41Z,yujingaya,NA https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-16T06:37:03Z,avitex,NA https://github.com/rust-lang/rust/pull/79721,MERGED,2020-12-05T03:17:34Z,2020-12-09T16:36:18Z,Properly re-use def path hash in incremental mode,Aaron1011,fa55f668e5ea5388ec98b9340969527252239151,6,Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash r=wesleywiser Properly re-use def path hash in incremental mode Fixes #79661 In incremental compilation mode we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However PR #74967 didn't do this in all cases leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.,HEART,2020-12-18T20:08:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79722,CLOSED,2020-12-05T03:24:42Z,2020-12-09T15:54:34Z,Reduce duplication for arena-spec,pickfire,NA,NA,NA,EYES,2020-12-05T07:43:46Z,bugadani,NA https://github.com/rust-lang/rust/pull/79722,CLOSED,2020-12-05T03:24:42Z,2020-12-09T15:54:34Z,Reduce duplication for arena-spec,pickfire,NA,NA,NA,EYES,2020-12-08T17:59:33Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79728,CLOSED,2020-12-05T11:01:17Z,2021-04-11T16:20:56Z,Carry index of InvalidDigit on IntErrorKind,eopb,NA,NA,NA,THUMBS_UP,2020-12-05T18:35:24Z,raleighlittles,raleighlittles@gmail.com https://github.com/rust-lang/rust/pull/79728,CLOSED,2020-12-05T11:01:17Z,2021-04-11T16:20:56Z,Carry index of InvalidDigit on IntErrorKind,eopb,NA,NA,NA,EYES,2020-12-08T16:01:21Z,MehranSattar,NA https://github.com/rust-lang/rust/pull/79728,CLOSED,2020-12-05T11:01:17Z,2021-04-11T16:20:56Z,Carry index of InvalidDigit on IntErrorKind,eopb,NA,NA,NA,THUMBS_UP,2021-02-07T05:02:36Z,therealbstern,NA https://github.com/rust-lang/rust/pull/79730,CLOSED,2020-12-05T12:09:33Z,2021-02-22T14:19:14Z,Permit Coercions in Type Ascriptions,b-naber,NA,NA,NA,HOORAY,2020-12-07T00:44:41Z,cynecx,NA https://github.com/rust-lang/rust/pull/79730,CLOSED,2020-12-05T12:09:33Z,2021-02-22T14:19:14Z,Permit Coercions in Type Ascriptions,b-naber,NA,NA,NA,HOORAY,2020-12-07T10:45:00Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/79730,CLOSED,2020-12-05T12:09:33Z,2021-02-22T14:19:14Z,Permit Coercions in Type Ascriptions,b-naber,NA,NA,NA,HOORAY,2020-12-08T12:28:49Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/79730,CLOSED,2020-12-05T12:09:33Z,2021-02-22T14:19:14Z,Permit Coercions in Type Ascriptions,b-naber,NA,NA,NA,HOORAY,2021-02-14T02:36:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/79737,MERGED,2020-12-05T15:42:39Z,2020-12-06T08:08:13Z,Update RLS and Rustfmt,Xanewok,5957f208a5def92a5ee85e71b01f75904c1ba4ff,4,Auto merge of #79737 - Xanewok:update-rls r=calebcartwright Update RLS and Rustfmt Fixes #79406 Fixes #79407 This does pull 1.4.28 version of Rustfmt. Do you want me to pull the 1.4.29 while we're at it? r? `@calebcartwright`,HEART,2020-12-05T18:06:42Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/79746,CLOSED,2020-12-05T20:08:00Z,2021-04-04T16:41:22Z,Give a better diagnostic for keywords with incorrect capitalization,hosseind88,NA,NA,NA,THUMBS_UP,2020-12-05T21:10:32Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/79746,CLOSED,2020-12-05T20:08:00Z,2021-04-04T16:41:22Z,Give a better diagnostic for keywords with incorrect capitalization,hosseind88,NA,NA,NA,HEART,2020-12-06T16:14:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79753,CLOSED,2020-12-05T23:35:57Z,2021-02-02T01:43:59Z,unix: Non-mutable bufs in send_vectored_with_ancillary_to,lukaslihotzki,NA,NA,NA,THUMBS_UP,2020-12-18T18:32:13Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/79757,MERGED,2020-12-06T00:48:22Z,2021-01-12T11:20:40Z,Replace tabs earlier in diagnostics,jryans,86b900a3eaaf84b48f080dab14b7994385bd19b8,4,Rollup merge of #79757 - jryans:long-line-tab-handling-early-expand r=estebank Replace tabs earlier in diagnostics This replaces tabs earlier in the diagnostics emitting process which allows various margin calculations to ignore the existence of tabs. It does add a string copy for the source lines that are emitted. Fixes https://github.com/rust-lang/rust/issues/78438 r? `@estebank`,HEART,2020-12-06T04:45:29Z,est31,NA https://github.com/rust-lang/rust/pull/79757,MERGED,2020-12-06T00:48:22Z,2021-01-12T11:20:40Z,Replace tabs earlier in diagnostics,jryans,86b900a3eaaf84b48f080dab14b7994385bd19b8,4,Rollup merge of #79757 - jryans:long-line-tab-handling-early-expand r=estebank Replace tabs earlier in diagnostics This replaces tabs earlier in the diagnostics emitting process which allows various margin calculations to ignore the existence of tabs. It does add a string copy for the source lines that are emitted. Fixes https://github.com/rust-lang/rust/issues/78438 r? `@estebank`,HEART,2020-12-08T02:28:55Z,estebank,NA https://github.com/rust-lang/rust/pull/79757,MERGED,2020-12-06T00:48:22Z,2021-01-12T11:20:40Z,Replace tabs earlier in diagnostics,jryans,86b900a3eaaf84b48f080dab14b7994385bd19b8,4,Rollup merge of #79757 - jryans:long-line-tab-handling-early-expand r=estebank Replace tabs earlier in diagnostics This replaces tabs earlier in the diagnostics emitting process which allows various margin calculations to ignore the existence of tabs. It does add a string copy for the source lines that are emitted. Fixes https://github.com/rust-lang/rust/issues/78438 r? `@estebank`,HEART,2020-12-09T01:44:05Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79757,MERGED,2020-12-06T00:48:22Z,2021-01-12T11:20:40Z,Replace tabs earlier in diagnostics,jryans,86b900a3eaaf84b48f080dab14b7994385bd19b8,4,Rollup merge of #79757 - jryans:long-line-tab-handling-early-expand r=estebank Replace tabs earlier in diagnostics This replaces tabs earlier in the diagnostics emitting process which allows various margin calculations to ignore the existence of tabs. It does add a string copy for the source lines that are emitted. Fixes https://github.com/rust-lang/rust/issues/78438 r? `@estebank`,HEART,2021-01-12T11:54:28Z,tesuji,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-07T20:46:38Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-08T07:12:18Z,est31,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-08T07:13:48Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-08T11:18:03Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-08T12:32:46Z,jagill,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-08T14:27:37Z,Br1ght0ne,brightspam@duck.com https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-09T09:55:04Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2020-12-16T08:48:35Z,darksv,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-01-27T18:15:21Z,old-mibmo,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-02-11T07:39:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-02-11T12:50:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-02-11T13:15:26Z,NULLx76,NA https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-02-11T23:06:35Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79805,MERGED,2020-12-07T20:29:07Z,2021-02-05T02:09:00Z,Rename Iterator::fold_first to reduce and stabilize it,m-ou-se,5b0acfd049ca205a5a43adde9882f59a97107afd,4,Rollup merge of #79805 - m-ou-se:iterator-reduce r=KodrAus Rename Iterator::fold_first to reduce and stabilize it This stabilizes `#![feature(iterator_fold_self)]`. The name for this function (originally `fold_first`) was still an open question but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.,HOORAY,2021-02-12T23:31:13Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/79809,MERGED,2020-12-07T21:31:42Z,2020-12-11T07:54:29Z,Dogfood `str_split_once()`,Eric-Arellano,17ec4b8258b3f59ded7b2cfae8484be976c658af,22,"Rollup merge of #79809 - Eric-Arellano:split-once r=matklad Dogfood `str_split_once()` Part of https://github.com/rust-lang/rust/issues/74773. Beyond increased clarity this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()` regardless of the delimiter and even if the value is empty. Given this code: ```rust fn main() { let val = ""...""; let mut iter = val.splitn(2 '='); println!(""Input: {:?} first: {:?} second: {:?}"" val iter.next() iter.next()); } ``` We get: ``` Input: ""no_delimiter"" first: Some(""no_delimiter"") second: None Input: ""k=v"" first: Some(""k"") second: Some(""v"") Input: ""="" first: Some("""") second: Some("""") ``` Using `str_split_once()` makes more clear what happens when the delimiter is not found.",HEART,2020-12-08T10:07:55Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/79812,MERGED,2020-12-07T23:19:22Z,2020-12-30T12:43:15Z,Lint on redundant trailing semicolon after item,Aaron1011,3fe423663b18b95c0695ac112493e23d2d77a1a1,8,Rollup merge of #79812 - Aaron1011:lint-item-trailing-semi r=oli-obk Lint on redundant trailing semicolon after item We now lint on code like this: ```rust fn main() { fn foo() {}; struct Bar {}; } ``` Previously this caused warnings in Cargo so it was disabled.,HEART,2021-01-06T06:25:18Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/79814,MERGED,2020-12-07T23:30:24Z,2020-12-10T20:14:41Z,fix soundness issue in `make_contiguous`,lcnr,d32c320d7eee56706486fef6be778495303afe9e,2,Auto merge of #79814 - lcnr:deque-f r=Mark-Simulacrum fix soundness issue in `make_contiguous` fixes #79808,HEART,2020-12-09T03:58:13Z,95th,NA https://github.com/rust-lang/rust/pull/79815,MERGED,2020-12-07T23:48:02Z,2020-12-28T18:50:19Z,Update RELEASES.md for 1.49.0,XAMPPRocky,d3c43ac244741221393b685423ce771e88e0ac7e,1,Rollup merge of #79815 - XAMPPRocky:relnotes-1.49.0 r=Mark-Simulacrum Update RELEASES.md for 1.49.0 ### [Rendered](https://github.com/XAMPPRocky/rust/tree/relnotes-1.49.0/RELEASES.md) r? ``@Mark-Simulacrum`` cc ``@rust-lang/release``,HEART,2020-12-18T09:21:05Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/79834,MERGED,2020-12-08T19:58:09Z,2020-12-13T06:25:47Z,Remove deprecated linked_list_extras methods.,m-ou-se,89051d81b95bdf0cd11c5c05dc3013cf95f0dda3,1,Rollup merge of #79834 - m-ou-se:bye-linked-list-extras r=Mark-Simulacrum Remove deprecated linked_list_extras methods. https://github.com/rust-lang/rust/issues/27794#issuecomment-667524201: > I'd say give it about 2 weeks then remove them. It's been 18 weeks. Time to remove them. :) Closes #27794.,HEART,2020-12-08T21:57:49Z,panaman67,NA https://github.com/rust-lang/rust/pull/79834,MERGED,2020-12-08T19:58:09Z,2020-12-13T06:25:47Z,Remove deprecated linked_list_extras methods.,m-ou-se,89051d81b95bdf0cd11c5c05dc3013cf95f0dda3,1,Rollup merge of #79834 - m-ou-se:bye-linked-list-extras r=Mark-Simulacrum Remove deprecated linked_list_extras methods. https://github.com/rust-lang/rust/issues/27794#issuecomment-667524201: > I'd say give it about 2 weeks then remove them. It's been 18 weeks. Time to remove them. :) Closes #27794.,HEART,2020-12-09T11:58:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/79840,MERGED,2020-12-08T22:18:51Z,2020-12-17T12:02:38Z,Remove memoization leftovers from constant evaluation machine,dvtkrlbs,001bd7762c9fc0d032b502b6a50ad67694c30b2c,3,Auto merge of #79840 - dvtkrlbs:issue-79667 r=oli-obk Remove memoization leftovers from constant evaluation machine Closes #79667,HEART,2020-12-08T23:08:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/79840,MERGED,2020-12-08T22:18:51Z,2020-12-17T12:02:38Z,Remove memoization leftovers from constant evaluation machine,dvtkrlbs,001bd7762c9fc0d032b502b6a50ad67694c30b2c,3,Auto merge of #79840 - dvtkrlbs:issue-79667 r=oli-obk Remove memoization leftovers from constant evaluation machine Closes #79667,HEART,2020-12-09T09:07:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,THUMBS_UP,2021-05-20T04:55:55Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,ROCKET,2021-05-21T05:01:44Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,HEART,2021-05-21T05:01:50Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,THUMBS_UP,2021-05-25T01:32:54Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,THUMBS_UP,2021-06-13T16:47:35Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79850,CLOSED,2020-12-09T06:00:10Z,2021-05-24T17:55:27Z,Allow unused variables with todo!,charles-r-earp,NA,NA,NA,HEART,2021-06-13T16:47:36Z,iago-lito,NA https://github.com/rust-lang/rust/pull/79862,MERGED,2020-12-09T19:50:20Z,2020-12-10T00:42:15Z,Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs,GuillaumeGomez,f74f3b2f37aaad4d78b85404ec1cc5e525c550d1,1,Rollup merge of #79862 - GuillaumeGomez:tab-lock r=Manishearth Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs Fixes https://github.com/rust-lang/rust/issues/65212 What took the longest time was to update the help popup in the end. r? `@Manishearth`,HEART,2021-01-01T07:09:58Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/79883,MERGED,2020-12-10T04:56:46Z,2021-01-02T09:52:26Z,Enable ASan TSan UBSan for aarch64-apple-darwin.,frewsxcv,5986dd878f3e432025eb1946149e3241d3998b1b,8,Auto merge of #79883 - frewsxcv:frewsxcv-san r=shepmaster Enable ASan TSan UBSan for aarch64-apple-darwin. I confirmed ASan TSan UBSan all work for me locally with `clang` on my new Macbook Air. ~This requires https://github.com/rust-lang/llvm-project/pull/86~,HEART,2020-12-12T23:09:08Z,enfipy,enfipy@gmail.com https://github.com/rust-lang/rust/pull/79883,MERGED,2020-12-10T04:56:46Z,2021-01-02T09:52:26Z,Enable ASan TSan UBSan for aarch64-apple-darwin.,frewsxcv,5986dd878f3e432025eb1946149e3241d3998b1b,8,Auto merge of #79883 - frewsxcv:frewsxcv-san r=shepmaster Enable ASan TSan UBSan for aarch64-apple-darwin. I confirmed ASan TSan UBSan all work for me locally with `clang` on my new Macbook Air. ~This requires https://github.com/rust-lang/llvm-project/pull/86~,HEART,2020-12-16T01:57:50Z,awulkan,NA https://github.com/rust-lang/rust/pull/79883,MERGED,2020-12-10T04:56:46Z,2021-01-02T09:52:26Z,Enable ASan TSan UBSan for aarch64-apple-darwin.,frewsxcv,5986dd878f3e432025eb1946149e3241d3998b1b,8,Auto merge of #79883 - frewsxcv:frewsxcv-san r=shepmaster Enable ASan TSan UBSan for aarch64-apple-darwin. I confirmed ASan TSan UBSan all work for me locally with `clang` on my new Macbook Air. ~This requires https://github.com/rust-lang/llvm-project/pull/86~,HEART,2020-12-16T20:00:26Z,zoosky,NA https://github.com/rust-lang/rust/pull/79883,MERGED,2020-12-10T04:56:46Z,2021-01-02T09:52:26Z,Enable ASan TSan UBSan for aarch64-apple-darwin.,frewsxcv,5986dd878f3e432025eb1946149e3241d3998b1b,8,Auto merge of #79883 - frewsxcv:frewsxcv-san r=shepmaster Enable ASan TSan UBSan for aarch64-apple-darwin. I confirmed ASan TSan UBSan all work for me locally with `clang` on my new Macbook Air. ~This requires https://github.com/rust-lang/llvm-project/pull/86~,HEART,2020-12-29T12:54:51Z,EwoutH,E.M.terHoeven@student.tudelft.nl https://github.com/rust-lang/rust/pull/79883,MERGED,2020-12-10T04:56:46Z,2021-01-02T09:52:26Z,Enable ASan TSan UBSan for aarch64-apple-darwin.,frewsxcv,5986dd878f3e432025eb1946149e3241d3998b1b,8,Auto merge of #79883 - frewsxcv:frewsxcv-san r=shepmaster Enable ASan TSan UBSan for aarch64-apple-darwin. I confirmed ASan TSan UBSan all work for me locally with `clang` on my new Macbook Air. ~This requires https://github.com/rust-lang/llvm-project/pull/86~,HEART,2021-01-01T10:48:54Z,sebastiencs,NA https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-10T18:38:55Z,uberjay,huber@paradoxical.net https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-10T21:09:19Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-11T11:09:24Z,jihchi,NA https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-26T10:28:02Z,Ten0,NA https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-30T20:00:29Z,camelid,NA https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2020-12-31T12:49:02Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/79895,MERGED,2020-12-10T10:28:47Z,2020-12-31T14:52:27Z,The return of the GroupBy and GroupByMut iterators on slice,Kerollmops,b33e234155b33ab6bce280fb2445b62b68622b61,7,Auto merge of #79895 - Kerollmops:slice-group-by r=m-ou-se The return of the GroupBy and GroupByMut iterators on slice According to https://github.com/rust-lang/rfcs/pull/2477#issuecomment-742034372 I am opening this PR again this time I implemented it in safe Rust only it is therefore much easier to read and is completely safe. This PR proposes to add two new methods to the slice the `group_by` and `group_by_mut`. These two methods provide a way to iterate over non-overlapping sub-slices of a base slice that are separated by the predicate given by the user (e.g. `Partial::eq` `|a b| a.abs() < b.abs()`). ```rust let slice = &[1 1 1 3 3 2 2 2]; let mut iter = slice.group_by(|a b| a == b); assert_eq!(iter.next() Some(&[1 1 1][..])); assert_eq!(iter.next() Some(&[3 3][..])); assert_eq!(iter.next() Some(&[2 2 2][..])); assert_eq!(iter.next() None); ``` [An RFC](https://github.com/rust-lang/rfcs/pull/2477) was open 2 years ago but wasn't necessary.,HEART,2021-05-13T10:37:03Z,zohnannor,NA https://github.com/rust-lang/rust/pull/79915,MERGED,2020-12-10T21:05:14Z,2020-12-11T12:30:06Z,Use `def_path_hash_to_def_id` when re-using a `RawDefId`,Aaron1011,19eb1c4c526071c430c05fffc64da71ac057a3d5,5,Auto merge of #79915 - Aaron1011:fix/fix-reuse-def-path-hash r=petrochenkov Use `def_path_hash_to_def_id` when re-using a `RawDefId` Fixes #79890 Previously we just copied a `RawDefId` from the 'old' map to the 'new' map. However the `RawDefId` for a given `DefPathHash` may be different in the current compilation session. Using `def_path_hash_to_def_id` ensures that the `RawDefId` we use is valid in the current session.,THUMBS_UP,2020-12-11T05:49:04Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/79930,MERGED,2020-12-11T08:31:39Z,2021-05-06T22:29:41Z,Optimize BufWriter,tgnottingham,676ee14729462585b969bbc52f32c307403f4126,1,Auto merge of #79930 - tgnottingham:bufwriter_performance r=m-ou-se Optimize BufWriter,ROCKET,2020-12-12T09:26:37Z,mati865,NA https://github.com/rust-lang/rust/pull/79930,MERGED,2020-12-11T08:31:39Z,2021-05-06T22:29:41Z,Optimize BufWriter,tgnottingham,676ee14729462585b969bbc52f32c307403f4126,1,Auto merge of #79930 - tgnottingham:bufwriter_performance r=m-ou-se Optimize BufWriter,ROCKET,2020-12-13T07:54:02Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/79930,MERGED,2020-12-11T08:31:39Z,2021-05-06T22:29:41Z,Optimize BufWriter,tgnottingham,676ee14729462585b969bbc52f32c307403f4126,1,Auto merge of #79930 - tgnottingham:bufwriter_performance r=m-ou-se Optimize BufWriter,ROCKET,2021-05-14T03:49:58Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/79930,MERGED,2020-12-11T08:31:39Z,2021-05-06T22:29:41Z,Optimize BufWriter,tgnottingham,676ee14729462585b969bbc52f32c307403f4126,1,Auto merge of #79930 - tgnottingham:bufwriter_performance r=m-ou-se Optimize BufWriter,ROCKET,2021-05-14T07:03:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79930,MERGED,2020-12-11T08:31:39Z,2021-05-06T22:29:41Z,Optimize BufWriter,tgnottingham,676ee14729462585b969bbc52f32c307403f4126,1,Auto merge of #79930 - tgnottingham:bufwriter_performance r=m-ou-se Optimize BufWriter,ROCKET,2021-06-06T20:29:50Z,r00ster91,NA https://github.com/rust-lang/rust/pull/79931,MERGED,2020-12-11T10:31:28Z,2020-12-12T05:04:33Z,make redundant StorageLive UB,RalfJung,602899cd012cf44165abf8f5e665ed93974f4ad8,2,Auto merge of #79931 - RalfJung:no-redundant-storage-live r=oli-obk make redundant StorageLive UB The interesting behavior of StorageLive in loops (https://github.com/rust-lang/rust/issues/42371) has been fixed so we can now finally make it a hard error to mark a local as live that is already live. :) r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/42371,EYES,2020-12-11T17:42:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79940,MERGED,2020-12-11T18:22:17Z,2020-12-13T06:25:46Z,fix more clippy::complexity findings,matthiaskrgr,1b81f08d4cc817548f0b503f33c8b665455d60a6,15,Rollup merge of #79940 - matthiaskrgr:cl15ppy r=Dylan-DPC fix more clippy::complexity findings fix clippy::unnecessary_filter_map use if let Some(x) = .. instead of ...map(|x|) to conditionally run fns that return () (clippy::option_map_unit_fn) fix clippy::{needless_bool manual_unwrap_or} don't clone types that are copy (clippy::clone_on_copy) don't convert types into identical types with .into() (clippy::useless_conversion) use strip_prefix over slicing (clippy::manual_strip) r? ``@Dylan-DPC``,EYES,2020-12-11T18:28:03Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79944,MERGED,2020-12-11T19:38:57Z,2020-12-14T09:25:12Z,Improve error handling in `symbols` proc-macro,sivadeilra,331e74014a0a2bf18aae7f02495f97958bf9767d,3,Auto merge of #79944 - sivadeilra:syms_proc_macro_testing r=petrochenkov Improve error handling in `symbols` proc-macro This improves how the `symbols` proc-macro handles errors. If it finds an error in its input the macro does not panic. Instead it still produces an output token stream. That token stream will contain `compile_error!(...)` macro invocations. This will still cause compilation to fail (which is what we want) but it will prevent meaningless errors caused by the output not containing symbols that the macro normally generates. This solves a small (but annoying) problem. When you're editing rustc_span/src/symbol.rs and you get something wrong (dup symbol name misordered symbol) you want to get only the errors that are relevant not a burst of errors that are irrelevant. This change also uses the correct Span when reporting errors so you get errors that point to the correct place in rustc_span/src/symbol.rs where something is wrong. This also adds several unit tests which test the `symbols` proc-macro. This commit also makes it easy to run the `symbols` proc-macro as an ordinary Cargo test. Just run `cargo test`. This makes it easier to do development on the macro itself such as running it under a debugger. This commit also uses the `Punctuated` type in `syn` for parsing comma-separated lists rather than doing it manually. The output of the macro is not changed at all by this commit so rustc should be completely unchanged. This just improves quality of life during development.,HEART,2020-12-11T20:20:36Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79957,MERGED,2020-12-12T04:11:55Z,2020-12-12T22:13:09Z,[rustdoc] Calculate span information on demand instead of storing it ahead of time,jyn514,7efc097c4fe6e97f54a44cee91c56189e9ddb41c,11,Auto merge of #79957 - jyn514:smaller-span r=GuillaumeGomez [rustdoc] Calculate span information on demand instead of storing it ahead of time This brings `size_of()` down from over 100 bytes (!!) to only 12 the same as rustc. It brings `Item` down even more from `784` to `680`. ~~TODO: I need to figure out how to do this for the JSON backend too. That uses `From` impls everywhere which don't allow passing in the `Session` as an argument. `@P1n3appl3 ` `@tmandry ` maybe one of you have ideas?~~ Figured it out fortunately only two functions needed to be changed. I like the `convert_x()` format better than `From` everywhere but I'm open to feedback. Helps with #79103,THUMBS_UP,2020-12-12T10:13:50Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/79958,MERGED,2020-12-12T05:47:36Z,2020-12-15T18:40:53Z,Fixes reported bugs in Rust Coverage,richkadel,5de0c5f63f11e4ec283841fb98d24c00e3e02bd8,16,Rollup merge of #79958 - richkadel:llvm-coverage-counters-2.2.0 r=tmandry Fixes reported bugs in Rust Coverage Fixes: #79569 Fixes: #79566 Fixes: #79565 For the first issue (#79569) I got hit a `debug_assert!()` before encountering the reported error message (because I have `debug = true` enabled in my config.toml). The assertion showed me that some `SwitchInt`s can have more than one target pointing to the same `BasicBlock`. I had thought that was invalid but since it seems to be possible I'm allowing this now. I added a new test for this. ---- In the last two cases above both tests (intentionally) fail to compile but the `InstrumentCoverage` pass is invoked anyway. The MIR starts with an `Unreachable` `BasicBlock` which I hadn't encountered before. (I had assumed the `InstrumentCoverage` pass would only be invoked with MIRs from successful compilations.) I don't have test infrastructure set up to test coverage on files that fail to compile so I didn't add a new test. r? `@tmandry` FYI: `@wesleywiser`,HEART,2020-12-12T10:52:35Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/79963,MERGED,2020-12-12T15:15:02Z,2020-12-13T06:25:46Z,Fix typo in `DebruijnIndex` documentation,LeSeulArtichaut,e4a663cbaaf3b04ecf14bfa17e2fa0699ecb5a78,1,Rollup merge of #79963 - LeSeulArtichaut:debruijn-typo r=Dylan-DPC Fix typo in `DebruijnIndex` documentation Suggested in https://github.com/rust-lang/rust/pull/79169#discussion_r541564114. r? ``@lqd``,HEART,2020-12-12T20:33:42Z,lqd,NA https://github.com/rust-lang/rust/pull/79965,MERGED,2020-12-12T15:19:13Z,2021-07-03T06:53:45Z,More ErrorKinds for common errnos,ijackson,fdd9a071474d898556891d5146fd9e8d1a10a077,5,Auto merge of #79965 - ijackson:moreerrnos r=joshtriplett More ErrorKinds for common errnos From the commit message of the main commit here (as revised): ``` There are a number of IO error situations which it would be very useful for Rust code to be able to recognise without having to resort to OS-specific code. Taking some Unix examples `ENOTEMPTY` and `EXDEV` have obvious recovery strategies. Recently I was surprised to discover that `ENOSPC` came out as `ErrorKind::Other`. Since I am familiar with Unix I reviwed the list of errno values in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Here I add those that most clearly seem to be needed. `@CraftSpider` provided information about Windows and references which I have tried to take into account. This has to be insta-stable because we can't sensibly have a different set of ErrorKinds depending on a std feature flag. I have *not* added these to the mapping tables for any operating systems other than Unix and Windows. I hope that it is OK to add them now for Unix and Windows now and maybe add them to other OS's mapping tables as and when someone on that OS is able to consider the situation. I adopted the general principle that it was usually a bad idea to map two distinct error values to the same Rust error code. I notice that this principle is already violated in the case of `EACCES` and `EPERM` which both map to `PermissionDenied`. I think this was probably a mistake but it would be quite hard to change now so I don't propose to do anything about that. However for Windows there are sometimes different error codes for identical situations. Eg there are WSA* versions of some error codes as well as ERROR_* ones. Also Windows seems to have a great many more erorr codes. I don't know precisely what best practice would be for Windows. ``` ``` Errno values I wasn't sure about so *haven't* included: EMFILE ENFILE ENOBUFS ENOLCK: These are all fairly Unix-specific resource exhaustion situations. In practice it seemed not very likely to me that anyone would want to handle these differently to `Other`. ENOMEM ERANGE EDOM EOVERFLOW Normally these don't get exposed to the Rust callers I hope. They don't tend to come out of filesystem APIs. EILSEQ Hopefully Rust libraries open files in binary mode and do the converstion in Rust. So Rust code ought not to be exposed to EILSEQ. EIO The range of things that could cause this is troublesome. I found it difficult to describe. I do think it would be useful to add this at some point because EIO on a filesystem operation is much more serious than most other errors. ENETDOWN I wasn't sure if this was useful or indeed if any modern systems use it. ENOEXEC It is not clear to me how a Rust program could respond to this. It seems rather niche. EPROTO ENETRESET ENODATA ENOMSG ENOPROTOOPT ENOSR ENOSTR ETIME ENOTRECOVERABLE EOWNERDEAD EBADMSG EPROTONOSUPPORT EPROTOTYPE EIDRM These are network or STREAMS related errors which I have never in my own Unix programming found the need to do anything with. I think someone who understands these better should be the one to try to find good Rust names and descriptions for them. ENOTTY ENXIO ENODEV EOPNOTSUPP ESRCH EALREADY ECANCELED ECHILD EINPROGRESS These are very hard to get unless you're already doing something very Unix-specific in which case the raw_os_error interface is probably more suitable than relying on the Rust ErrorKind mapping. EFAULT EBADF These would seem to be the result of application UB. ``` (omitted errnos are discussed below especially in https://github.com/rust-lang/rust/pull/79965#issuecomment-810468334),HEART,2021-05-01T18:53:01Z,bluss,NA https://github.com/rust-lang/rust/pull/79965,MERGED,2020-12-12T15:19:13Z,2021-07-03T06:53:45Z,More ErrorKinds for common errnos,ijackson,fdd9a071474d898556891d5146fd9e8d1a10a077,5,Auto merge of #79965 - ijackson:moreerrnos r=joshtriplett More ErrorKinds for common errnos From the commit message of the main commit here (as revised): ``` There are a number of IO error situations which it would be very useful for Rust code to be able to recognise without having to resort to OS-specific code. Taking some Unix examples `ENOTEMPTY` and `EXDEV` have obvious recovery strategies. Recently I was surprised to discover that `ENOSPC` came out as `ErrorKind::Other`. Since I am familiar with Unix I reviwed the list of errno values in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Here I add those that most clearly seem to be needed. `@CraftSpider` provided information about Windows and references which I have tried to take into account. This has to be insta-stable because we can't sensibly have a different set of ErrorKinds depending on a std feature flag. I have *not* added these to the mapping tables for any operating systems other than Unix and Windows. I hope that it is OK to add them now for Unix and Windows now and maybe add them to other OS's mapping tables as and when someone on that OS is able to consider the situation. I adopted the general principle that it was usually a bad idea to map two distinct error values to the same Rust error code. I notice that this principle is already violated in the case of `EACCES` and `EPERM` which both map to `PermissionDenied`. I think this was probably a mistake but it would be quite hard to change now so I don't propose to do anything about that. However for Windows there are sometimes different error codes for identical situations. Eg there are WSA* versions of some error codes as well as ERROR_* ones. Also Windows seems to have a great many more erorr codes. I don't know precisely what best practice would be for Windows. ``` ``` Errno values I wasn't sure about so *haven't* included: EMFILE ENFILE ENOBUFS ENOLCK: These are all fairly Unix-specific resource exhaustion situations. In practice it seemed not very likely to me that anyone would want to handle these differently to `Other`. ENOMEM ERANGE EDOM EOVERFLOW Normally these don't get exposed to the Rust callers I hope. They don't tend to come out of filesystem APIs. EILSEQ Hopefully Rust libraries open files in binary mode and do the converstion in Rust. So Rust code ought not to be exposed to EILSEQ. EIO The range of things that could cause this is troublesome. I found it difficult to describe. I do think it would be useful to add this at some point because EIO on a filesystem operation is much more serious than most other errors. ENETDOWN I wasn't sure if this was useful or indeed if any modern systems use it. ENOEXEC It is not clear to me how a Rust program could respond to this. It seems rather niche. EPROTO ENETRESET ENODATA ENOMSG ENOPROTOOPT ENOSR ENOSTR ETIME ENOTRECOVERABLE EOWNERDEAD EBADMSG EPROTONOSUPPORT EPROTOTYPE EIDRM These are network or STREAMS related errors which I have never in my own Unix programming found the need to do anything with. I think someone who understands these better should be the one to try to find good Rust names and descriptions for them. ENOTTY ENXIO ENODEV EOPNOTSUPP ESRCH EALREADY ECANCELED ECHILD EINPROGRESS These are very hard to get unless you're already doing something very Unix-specific in which case the raw_os_error interface is probably more suitable than relying on the Rust ErrorKind mapping. EFAULT EBADF These would seem to be the result of application UB. ``` (omitted errnos are discussed below especially in https://github.com/rust-lang/rust/pull/79965#issuecomment-810468334),HEART,2021-06-20T10:23:05Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/79965,MERGED,2020-12-12T15:19:13Z,2021-07-03T06:53:45Z,More ErrorKinds for common errnos,ijackson,fdd9a071474d898556891d5146fd9e8d1a10a077,5,Auto merge of #79965 - ijackson:moreerrnos r=joshtriplett More ErrorKinds for common errnos From the commit message of the main commit here (as revised): ``` There are a number of IO error situations which it would be very useful for Rust code to be able to recognise without having to resort to OS-specific code. Taking some Unix examples `ENOTEMPTY` and `EXDEV` have obvious recovery strategies. Recently I was surprised to discover that `ENOSPC` came out as `ErrorKind::Other`. Since I am familiar with Unix I reviwed the list of errno values in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html Here I add those that most clearly seem to be needed. `@CraftSpider` provided information about Windows and references which I have tried to take into account. This has to be insta-stable because we can't sensibly have a different set of ErrorKinds depending on a std feature flag. I have *not* added these to the mapping tables for any operating systems other than Unix and Windows. I hope that it is OK to add them now for Unix and Windows now and maybe add them to other OS's mapping tables as and when someone on that OS is able to consider the situation. I adopted the general principle that it was usually a bad idea to map two distinct error values to the same Rust error code. I notice that this principle is already violated in the case of `EACCES` and `EPERM` which both map to `PermissionDenied`. I think this was probably a mistake but it would be quite hard to change now so I don't propose to do anything about that. However for Windows there are sometimes different error codes for identical situations. Eg there are WSA* versions of some error codes as well as ERROR_* ones. Also Windows seems to have a great many more erorr codes. I don't know precisely what best practice would be for Windows. ``` ``` Errno values I wasn't sure about so *haven't* included: EMFILE ENFILE ENOBUFS ENOLCK: These are all fairly Unix-specific resource exhaustion situations. In practice it seemed not very likely to me that anyone would want to handle these differently to `Other`. ENOMEM ERANGE EDOM EOVERFLOW Normally these don't get exposed to the Rust callers I hope. They don't tend to come out of filesystem APIs. EILSEQ Hopefully Rust libraries open files in binary mode and do the converstion in Rust. So Rust code ought not to be exposed to EILSEQ. EIO The range of things that could cause this is troublesome. I found it difficult to describe. I do think it would be useful to add this at some point because EIO on a filesystem operation is much more serious than most other errors. ENETDOWN I wasn't sure if this was useful or indeed if any modern systems use it. ENOEXEC It is not clear to me how a Rust program could respond to this. It seems rather niche. EPROTO ENETRESET ENODATA ENOMSG ENOPROTOOPT ENOSR ENOSTR ETIME ENOTRECOVERABLE EOWNERDEAD EBADMSG EPROTONOSUPPORT EPROTOTYPE EIDRM These are network or STREAMS related errors which I have never in my own Unix programming found the need to do anything with. I think someone who understands these better should be the one to try to find good Rust names and descriptions for them. ENOTTY ENXIO ENODEV EOPNOTSUPP ESRCH EALREADY ECANCELED ECHILD EINPROGRESS These are very hard to get unless you're already doing something very Unix-specific in which case the raw_os_error interface is probably more suitable than relying on the Rust ErrorKind mapping. EFAULT EBADF These would seem to be the result of application UB. ``` (omitted errnos are discussed below especially in https://github.com/rust-lang/rust/pull/79965#issuecomment-810468334),HEART,2021-07-07T12:27:49Z,niklaslong,NA https://github.com/rust-lang/rust/pull/79968,MERGED,2020-12-12T16:06:53Z,2021-01-10T10:48:48Z,Improve core::ptr::drop_in_place debuginfo,bjorn3,f90c7f0f42dbebbb85d9699b5826b0b103b0fbde,1,Rollup merge of #79968 - bjorn3:better_drop_glue_debuginfo r=matthewjasper Improve core::ptr::drop_in_place debuginfo * Use span of the dropped type as function span when possible. * Rename symbol from `core::ptr::drop_in_place::$hash` to `{{drop}}::<$TYPE>::$hash`. Fixes #77465 (I haven't yet updated the tests),HOORAY,2020-12-14T02:59:52Z,ds84182,NA https://github.com/rust-lang/rust/pull/79968,MERGED,2020-12-12T16:06:53Z,2021-01-10T10:48:48Z,Improve core::ptr::drop_in_place debuginfo,bjorn3,f90c7f0f42dbebbb85d9699b5826b0b103b0fbde,1,Rollup merge of #79968 - bjorn3:better_drop_glue_debuginfo r=matthewjasper Improve core::ptr::drop_in_place debuginfo * Use span of the dropped type as function span when possible. * Rename symbol from `core::ptr::drop_in_place::$hash` to `{{drop}}::<$TYPE>::$hash`. Fixes #77465 (I haven't yet updated the tests),HEART,2020-12-15T20:30:18Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/79968,MERGED,2020-12-12T16:06:53Z,2021-01-10T10:48:48Z,Improve core::ptr::drop_in_place debuginfo,bjorn3,f90c7f0f42dbebbb85d9699b5826b0b103b0fbde,1,Rollup merge of #79968 - bjorn3:better_drop_glue_debuginfo r=matthewjasper Improve core::ptr::drop_in_place debuginfo * Use span of the dropped type as function span when possible. * Rename symbol from `core::ptr::drop_in_place::$hash` to `{{drop}}::<$TYPE>::$hash`. Fixes #77465 (I haven't yet updated the tests),HOORAY,2021-01-22T11:17:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/79981,MERGED,2020-12-12T21:53:07Z,2021-02-17T22:37:50Z,Add 'consider using' message to overflowing_literals,camelid,ec007845cfe6a3c54aa44468df9ff2be05fe25b8,10,Rollup merge of #79981 - camelid:overflowing_literals-inference-error r=lcnr Add 'consider using' message to overflowing_literals Fixes #79744. Ironically the `overflowing_literals` handler for binary or hex already had this message! You would think it would be the other way around :) cc ```@scottmcm```,HEART,2021-02-17T22:48:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/79985,MERGED,2020-12-12T22:32:13Z,2020-12-13T06:25:46Z,Fixes submit event of the search input,GuillaumeGomez,3213089c0292a5e3a1c0eae1ef845964eb91c51c,1,"Rollup merge of #79985 - GuillaumeGomez:fix-submit-event r=jyn514 Fixes submit event of the search input Fixes https://github.com/rust-lang/rust/issues/79960 It's a very funny corner case: In HTML when a button follows an input (in a `form`) if the enter keep is pressed on the input instead of sending the submit event to the input it'll create a click event on the button following it which in this case made the help popup show up whenever ""enter"" was pressed. cc `@camelid` r? `@jyn514`",THUMBS_UP,2020-12-12T22:34:41Z,camelid,NA https://github.com/rust-lang/rust/pull/79985,MERGED,2020-12-12T22:32:13Z,2020-12-13T06:25:46Z,Fixes submit event of the search input,GuillaumeGomez,3213089c0292a5e3a1c0eae1ef845964eb91c51c,1,"Rollup merge of #79985 - GuillaumeGomez:fix-submit-event r=jyn514 Fixes submit event of the search input Fixes https://github.com/rust-lang/rust/issues/79960 It's a very funny corner case: In HTML when a button follows an input (in a `form`) if the enter keep is pressed on the input instead of sending the submit event to the input it'll create a click event on the button following it which in this case made the help popup show up whenever ""enter"" was pressed. cc `@camelid` r? `@jyn514`",HEART,2020-12-12T22:34:50Z,camelid,NA https://github.com/rust-lang/rust/pull/79989,CLOSED,2020-12-12T23:52:30Z,2021-03-08T02:17:26Z,Stop generating code in mem::forget,scottmcm,NA,NA,NA,LAUGH,2020-12-13T00:34:28Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/79989,CLOSED,2020-12-12T23:52:30Z,2021-03-08T02:17:26Z,Stop generating code in mem::forget,scottmcm,NA,NA,NA,LAUGH,2020-12-14T00:14:24Z,DemiMarie,demiobenour@gmail.com https://github.com/rust-lang/rust/pull/79997,MERGED,2020-12-13T03:40:10Z,2021-01-12T02:56:40Z,Add a -Zwasi-exec-model codegen option for emitting WASI reactors,coolreader18,1d83f9828f9dfb5d752c8f0e3e71a9029a917de7,9,"Rollup merge of #79997 - coolreader18:wasm-reactor r=alexcrichton Emit a reactor for cdylib target on wasi Fixes #79199 and relevant to #73432 Implements wasi reactors as described in WebAssembly/WASI#13 and [`design/application-abi.md`](https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md) Empty `lib.rs` `lib.crate-type = [""cdylib""]`: ```shell $ cargo +reactor build --release --target wasm32-wasi Compiling wasm-reactor v0.1.0 (/home/coolreader18/wasm-reactor) Finished release [optimized] target(s) in 0.08s $ wasm-dis target/wasm32-wasi/release/wasm_reactor.wasm >reactor.wat ``` `reactor.wat`: ```wat (module (type $none_=>_none (func)) (type $i32_=>_none (func (param i32))) (type $i32_i32_=>_i32 (func (param i32 i32) (result i32))) (type $i32_=>_i32 (func (param i32) (result i32))) (type $i32_i32_i32_=>_i32 (func (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_get"" (func $__wasi_fd_prestat_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_dir_name"" (func $__wasi_fd_prestat_dir_name (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""proc_exit"" (func $__wasi_proc_exit (param i32))) (import ""wasi_snapshot_preview1"" ""environ_sizes_get"" (func $__wasi_environ_sizes_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""environ_get"" (func $__wasi_environ_get (param i32 i32) (result i32))) (memory $0 17) (table $0 1 1 funcref) (global $global$0 (mut i32) (i32.const 1048576)) (global $global$1 i32 (i32.const 1049096)) (global $global$2 i32 (i32.const 1049096)) (export ""memory"" (memory $0)) (export ""_initialize"" (func $_initialize)) (export ""__data_end"" (global $global$1)) (export ""__heap_base"" (global $global$2)) (func $__wasm_call_ctors (call $__wasilibc_initialize_environ_eagerly) (call $__wasilibc_populate_preopens) ) (func $_initialize (call $__wasm_call_ctors) ) (func $malloc (param $0 i32) (result i32) (call $dlmalloc (local.get $0) ) ) ;; lots of dlmalloc memset/memcpy & libpreopen code ) ``` I went with repurposing cdylib because I figured that it doesn't make much sense to have a wasi shared library that can't be initialized and even if someone was using it adding an `_initialize` export is a very small change.",EYES,2020-12-13T10:50:46Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/79997,MERGED,2020-12-13T03:40:10Z,2021-01-12T02:56:40Z,Add a -Zwasi-exec-model codegen option for emitting WASI reactors,coolreader18,1d83f9828f9dfb5d752c8f0e3e71a9029a917de7,9,"Rollup merge of #79997 - coolreader18:wasm-reactor r=alexcrichton Emit a reactor for cdylib target on wasi Fixes #79199 and relevant to #73432 Implements wasi reactors as described in WebAssembly/WASI#13 and [`design/application-abi.md`](https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md) Empty `lib.rs` `lib.crate-type = [""cdylib""]`: ```shell $ cargo +reactor build --release --target wasm32-wasi Compiling wasm-reactor v0.1.0 (/home/coolreader18/wasm-reactor) Finished release [optimized] target(s) in 0.08s $ wasm-dis target/wasm32-wasi/release/wasm_reactor.wasm >reactor.wat ``` `reactor.wat`: ```wat (module (type $none_=>_none (func)) (type $i32_=>_none (func (param i32))) (type $i32_i32_=>_i32 (func (param i32 i32) (result i32))) (type $i32_=>_i32 (func (param i32) (result i32))) (type $i32_i32_i32_=>_i32 (func (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_get"" (func $__wasi_fd_prestat_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_dir_name"" (func $__wasi_fd_prestat_dir_name (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""proc_exit"" (func $__wasi_proc_exit (param i32))) (import ""wasi_snapshot_preview1"" ""environ_sizes_get"" (func $__wasi_environ_sizes_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""environ_get"" (func $__wasi_environ_get (param i32 i32) (result i32))) (memory $0 17) (table $0 1 1 funcref) (global $global$0 (mut i32) (i32.const 1048576)) (global $global$1 i32 (i32.const 1049096)) (global $global$2 i32 (i32.const 1049096)) (export ""memory"" (memory $0)) (export ""_initialize"" (func $_initialize)) (export ""__data_end"" (global $global$1)) (export ""__heap_base"" (global $global$2)) (func $__wasm_call_ctors (call $__wasilibc_initialize_environ_eagerly) (call $__wasilibc_populate_preopens) ) (func $_initialize (call $__wasm_call_ctors) ) (func $malloc (param $0 i32) (result i32) (call $dlmalloc (local.get $0) ) ) ;; lots of dlmalloc memset/memcpy & libpreopen code ) ``` I went with repurposing cdylib because I figured that it doesn't make much sense to have a wasi shared library that can't be initialized and even if someone was using it adding an `_initialize` export is a very small change.",HOORAY,2020-12-14T10:40:33Z,arendjr,NA https://github.com/rust-lang/rust/pull/79997,MERGED,2020-12-13T03:40:10Z,2021-01-12T02:56:40Z,Add a -Zwasi-exec-model codegen option for emitting WASI reactors,coolreader18,1d83f9828f9dfb5d752c8f0e3e71a9029a917de7,9,"Rollup merge of #79997 - coolreader18:wasm-reactor r=alexcrichton Emit a reactor for cdylib target on wasi Fixes #79199 and relevant to #73432 Implements wasi reactors as described in WebAssembly/WASI#13 and [`design/application-abi.md`](https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md) Empty `lib.rs` `lib.crate-type = [""cdylib""]`: ```shell $ cargo +reactor build --release --target wasm32-wasi Compiling wasm-reactor v0.1.0 (/home/coolreader18/wasm-reactor) Finished release [optimized] target(s) in 0.08s $ wasm-dis target/wasm32-wasi/release/wasm_reactor.wasm >reactor.wat ``` `reactor.wat`: ```wat (module (type $none_=>_none (func)) (type $i32_=>_none (func (param i32))) (type $i32_i32_=>_i32 (func (param i32 i32) (result i32))) (type $i32_=>_i32 (func (param i32) (result i32))) (type $i32_i32_i32_=>_i32 (func (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_get"" (func $__wasi_fd_prestat_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_dir_name"" (func $__wasi_fd_prestat_dir_name (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""proc_exit"" (func $__wasi_proc_exit (param i32))) (import ""wasi_snapshot_preview1"" ""environ_sizes_get"" (func $__wasi_environ_sizes_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""environ_get"" (func $__wasi_environ_get (param i32 i32) (result i32))) (memory $0 17) (table $0 1 1 funcref) (global $global$0 (mut i32) (i32.const 1048576)) (global $global$1 i32 (i32.const 1049096)) (global $global$2 i32 (i32.const 1049096)) (export ""memory"" (memory $0)) (export ""_initialize"" (func $_initialize)) (export ""__data_end"" (global $global$1)) (export ""__heap_base"" (global $global$2)) (func $__wasm_call_ctors (call $__wasilibc_initialize_environ_eagerly) (call $__wasilibc_populate_preopens) ) (func $_initialize (call $__wasm_call_ctors) ) (func $malloc (param $0 i32) (result i32) (call $dlmalloc (local.get $0) ) ) ;; lots of dlmalloc memset/memcpy & libpreopen code ) ``` I went with repurposing cdylib because I figured that it doesn't make much sense to have a wasi shared library that can't be initialized and even if someone was using it adding an `_initialize` export is a very small change.",HOORAY,2020-12-18T00:04:57Z,pchickey,pat@moreproductive.org https://github.com/rust-lang/rust/pull/79997,MERGED,2020-12-13T03:40:10Z,2021-01-12T02:56:40Z,Add a -Zwasi-exec-model codegen option for emitting WASI reactors,coolreader18,1d83f9828f9dfb5d752c8f0e3e71a9029a917de7,9,"Rollup merge of #79997 - coolreader18:wasm-reactor r=alexcrichton Emit a reactor for cdylib target on wasi Fixes #79199 and relevant to #73432 Implements wasi reactors as described in WebAssembly/WASI#13 and [`design/application-abi.md`](https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md) Empty `lib.rs` `lib.crate-type = [""cdylib""]`: ```shell $ cargo +reactor build --release --target wasm32-wasi Compiling wasm-reactor v0.1.0 (/home/coolreader18/wasm-reactor) Finished release [optimized] target(s) in 0.08s $ wasm-dis target/wasm32-wasi/release/wasm_reactor.wasm >reactor.wat ``` `reactor.wat`: ```wat (module (type $none_=>_none (func)) (type $i32_=>_none (func (param i32))) (type $i32_i32_=>_i32 (func (param i32 i32) (result i32))) (type $i32_=>_i32 (func (param i32) (result i32))) (type $i32_i32_i32_=>_i32 (func (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_get"" (func $__wasi_fd_prestat_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""fd_prestat_dir_name"" (func $__wasi_fd_prestat_dir_name (param i32 i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""proc_exit"" (func $__wasi_proc_exit (param i32))) (import ""wasi_snapshot_preview1"" ""environ_sizes_get"" (func $__wasi_environ_sizes_get (param i32 i32) (result i32))) (import ""wasi_snapshot_preview1"" ""environ_get"" (func $__wasi_environ_get (param i32 i32) (result i32))) (memory $0 17) (table $0 1 1 funcref) (global $global$0 (mut i32) (i32.const 1048576)) (global $global$1 i32 (i32.const 1049096)) (global $global$2 i32 (i32.const 1049096)) (export ""memory"" (memory $0)) (export ""_initialize"" (func $_initialize)) (export ""__data_end"" (global $global$1)) (export ""__heap_base"" (global $global$2)) (func $__wasm_call_ctors (call $__wasilibc_initialize_environ_eagerly) (call $__wasilibc_populate_preopens) ) (func $_initialize (call $__wasm_call_ctors) ) (func $malloc (param $0 i32) (result i32) (call $dlmalloc (local.get $0) ) ) ;; lots of dlmalloc memset/memcpy & libpreopen code ) ``` I went with repurposing cdylib because I figured that it doesn't make much sense to have a wasi shared library that can't be initialized and even if someone was using it adding an `_initialize` export is a very small change.",HOORAY,2021-01-12T08:47:59Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/79998,MERGED,2020-12-13T04:34:33Z,2021-01-12T02:56:40Z,Use correct ABI for wasm32 by default,devsnek,edcfe7b6296aff0cf5c52f0c8bc972b0b156616d,1,Rollup merge of #79998 - devsnek:wasm32-bindgen-compat r=alexcrichton Use correct ABI for wasm32 by default Introduces `wasm32-unknown-bindgen` for those wishing to use the bindgen compat abi. `wasm32-*` now uses the correct abi by default. Fixes https://github.com/rustwasm/team/issues/291,HOORAY,2021-01-10T08:26:47Z,elichai,NA https://github.com/rust-lang/rust/pull/79998,MERGED,2020-12-13T04:34:33Z,2021-01-12T02:56:40Z,Use correct ABI for wasm32 by default,devsnek,edcfe7b6296aff0cf5c52f0c8bc972b0b156616d,1,Rollup merge of #79998 - devsnek:wasm32-bindgen-compat r=alexcrichton Use correct ABI for wasm32 by default Introduces `wasm32-unknown-bindgen` for those wishing to use the bindgen compat abi. `wasm32-*` now uses the correct abi by default. Fixes https://github.com/rustwasm/team/issues/291,HOORAY,2021-03-24T20:29:13Z,bjorn3,NA https://github.com/rust-lang/rust/pull/80011,MERGED,2020-12-13T14:17:19Z,2021-02-06T07:55:29Z,Stabilize `peekable_next_if`,Stupremee,cc882fc3bedec5047f055e5ff5a1908e730130bb,3,Rollup merge of #80011 - Stupremee:stabilize-peekable-next-if r=dtolnay Stabilize `peekable_next_if` This PR stabilizes the `peekable_next_if` feature Resolves #72480,HEART,2021-01-28T08:35:31Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/80011,MERGED,2020-12-13T14:17:19Z,2021-02-06T07:55:29Z,Stabilize `peekable_next_if`,Stupremee,cc882fc3bedec5047f055e5ff5a1908e730130bb,3,Rollup merge of #80011 - Stupremee:stabilize-peekable-next-if r=dtolnay Stabilize `peekable_next_if` This PR stabilizes the `peekable_next_if` feature Resolves #72480,HEART,2021-01-29T02:54:06Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80011,MERGED,2020-12-13T14:17:19Z,2021-02-06T07:55:29Z,Stabilize `peekable_next_if`,Stupremee,cc882fc3bedec5047f055e5ff5a1908e730130bb,3,Rollup merge of #80011 - Stupremee:stabilize-peekable-next-if r=dtolnay Stabilize `peekable_next_if` This PR stabilizes the `peekable_next_if` feature Resolves #72480,HEART,2021-02-01T05:57:08Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/80011,MERGED,2020-12-13T14:17:19Z,2021-02-06T07:55:29Z,Stabilize `peekable_next_if`,Stupremee,cc882fc3bedec5047f055e5ff5a1908e730130bb,3,Rollup merge of #80011 - Stupremee:stabilize-peekable-next-if r=dtolnay Stabilize `peekable_next_if` This PR stabilizes the `peekable_next_if` feature Resolves #72480,HEART,2021-03-11T18:04:42Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/80013,MERGED,2020-12-13T16:49:53Z,2020-12-14T16:05:21Z,Refactor test_lang_string_parse to make it clearer,poliorcetics,2169094ab8209c563756c478603b0c8637348aa9,1,Rollup merge of #80013 - poliorcetics:rustdoc-test-refactor r=jyn514 Refactor test_lang_string_parse to make it clearer Follows https://github.com/rust-lang/rust/pull/79454#discussion_r540190949 A small PR made to refactor a test in rustdoc that was becoming unwieldy. ``@rustbot`` label T-rustdoc r? ``@jyn514``,HEART,2020-12-13T16:54:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80029,CLOSED,2020-12-14T16:16:10Z,2021-01-01T21:20:19Z,Publicly expose the allocated representation of Rc and Arc,ggriffiniii,NA,NA,NA,THUMBS_UP,2020-12-18T09:48:08Z,brandenburg,bbb@mpi-sws.org https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-14T18:59:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-15T02:04:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-17T12:43:26Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-17T13:04:06Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-17T15:09:58Z,lqd,NA https://github.com/rust-lang/rust/pull/80033,CLOSED,2020-12-14T18:52:18Z,2020-12-19T15:13:16Z,Implement basic support for PGO in rustbuild for rustc,Mark-Simulacrum,NA,NA,NA,HOORAY,2020-12-17T19:09:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80035,MERGED,2020-12-14T19:01:52Z,2020-12-17T14:53:01Z,Optimization for bool's PartialOrd impl,ChayimFriedman2,93f1c67e91939e7f0f933194cb2168ca76c19068,1,Rollup merge of #80035 - ChayimFriedman2:patch-1 r=nagisa Optimization for bool's PartialOrd impl Fix #80034.,THUMBS_UP,2020-12-16T06:40:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80036,MERGED,2020-12-14T19:48:55Z,2020-12-18T05:55:25Z,Stop using intermediate macros in definition of symbols,sivadeilra,8d006c06b571d4db9fb2ef5b5eb1af28f4ef3574,2,Auto merge of #80036 - sivadeilra:syms_no_macro r=petrochenkov Stop using intermediate macros in definition of symbols Currently the rustc_macros::symbols macro generates two `macro_rules!` macros as its output. These two macros are used in rustc_span/src/symbol.rs. This means that each Symbol that we define is represented in the AST of rustc_symbols twice: once in the definition of the `define_symbols!` macro (similarly for the `keywords! macro) and once in the rustc_span::symbols definition. That would be OK if there were only a handful of symbols but currently we define over 1100 symbols. The definition of the `define_symbols!` macro contains the expanded definition of each symbol so that's a lot of AST storage wasted on a macro that is used exactly once. This commit removes the `define_symbols` macro and simply allows the proc macro to directly generate the `rustc_symbols::symbol::sym` module. The benefit is mainly in reducing memory wasted during compilation of rustc itself. It should also reduce memory used by Rust Analyzer. This commit also reduces the size of the AST for symbol definitions by moving two `#[allow(...)]` attributes from the symbol constants to the `sym` module. This eliminates 2200+ attribute nodes. This commit also eliminates the need for the `digits_array` constant. There's no need to store an array of Symbol values for digits. We can simply define a constant of the base value and add to that base value. I left the `sym::integer` function in rustc_span/src/symbol.rs instead of moving it into rustc_macros/src/symbols.rs for two reasons. First because it's human-written code; it doesn't need to be generated by the proc-macro. Second because I didn't want the `#[allow(...)]` attributes that I moved to the `sym` module scope to apply to this function. The `sym` module re-exports the `integer` function from its parent module.,HEART,2020-12-14T22:17:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80036,MERGED,2020-12-14T19:48:55Z,2020-12-18T05:55:25Z,Stop using intermediate macros in definition of symbols,sivadeilra,8d006c06b571d4db9fb2ef5b5eb1af28f4ef3574,2,Auto merge of #80036 - sivadeilra:syms_no_macro r=petrochenkov Stop using intermediate macros in definition of symbols Currently the rustc_macros::symbols macro generates two `macro_rules!` macros as its output. These two macros are used in rustc_span/src/symbol.rs. This means that each Symbol that we define is represented in the AST of rustc_symbols twice: once in the definition of the `define_symbols!` macro (similarly for the `keywords! macro) and once in the rustc_span::symbols definition. That would be OK if there were only a handful of symbols but currently we define over 1100 symbols. The definition of the `define_symbols!` macro contains the expanded definition of each symbol so that's a lot of AST storage wasted on a macro that is used exactly once. This commit removes the `define_symbols` macro and simply allows the proc macro to directly generate the `rustc_symbols::symbol::sym` module. The benefit is mainly in reducing memory wasted during compilation of rustc itself. It should also reduce memory used by Rust Analyzer. This commit also reduces the size of the AST for symbol definitions by moving two `#[allow(...)]` attributes from the symbol constants to the `sym` module. This eliminates 2200+ attribute nodes. This commit also eliminates the need for the `digits_array` constant. There's no need to store an array of Symbol values for digits. We can simply define a constant of the base value and add to that base value. I left the `sym::integer` function in rustc_span/src/symbol.rs instead of moving it into rustc_macros/src/symbols.rs for two reasons. First because it's human-written code; it doesn't need to be generated by the proc-macro. Second because I didn't want the `#[allow(...)]` attributes that I moved to the `sym` module scope to apply to this function. The `sym` module re-exports the `integer` function from its parent module.,HEART,2020-12-15T05:26:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/80036,MERGED,2020-12-14T19:48:55Z,2020-12-18T05:55:25Z,Stop using intermediate macros in definition of symbols,sivadeilra,8d006c06b571d4db9fb2ef5b5eb1af28f4ef3574,2,Auto merge of #80036 - sivadeilra:syms_no_macro r=petrochenkov Stop using intermediate macros in definition of symbols Currently the rustc_macros::symbols macro generates two `macro_rules!` macros as its output. These two macros are used in rustc_span/src/symbol.rs. This means that each Symbol that we define is represented in the AST of rustc_symbols twice: once in the definition of the `define_symbols!` macro (similarly for the `keywords! macro) and once in the rustc_span::symbols definition. That would be OK if there were only a handful of symbols but currently we define over 1100 symbols. The definition of the `define_symbols!` macro contains the expanded definition of each symbol so that's a lot of AST storage wasted on a macro that is used exactly once. This commit removes the `define_symbols` macro and simply allows the proc macro to directly generate the `rustc_symbols::symbol::sym` module. The benefit is mainly in reducing memory wasted during compilation of rustc itself. It should also reduce memory used by Rust Analyzer. This commit also reduces the size of the AST for symbol definitions by moving two `#[allow(...)]` attributes from the symbol constants to the `sym` module. This eliminates 2200+ attribute nodes. This commit also eliminates the need for the `digits_array` constant. There's no need to store an array of Symbol values for digits. We can simply define a constant of the base value and add to that base value. I left the `sym::integer` function in rustc_span/src/symbol.rs instead of moving it into rustc_macros/src/symbols.rs for two reasons. First because it's human-written code; it doesn't need to be generated by the proc-macro. Second because I didn't want the `#[allow(...)]` attributes that I moved to the `sym` module scope to apply to this function. The `sym` module re-exports the `integer` function from its parent module.,HEART,2020-12-15T21:11:57Z,univerz,NA https://github.com/rust-lang/rust/pull/80040,MERGED,2020-12-14T23:22:53Z,2020-12-17T14:53:01Z,Always run intrinsics lowering pass,tmiasko,1f5d8de0627738ee7b0d5bcf5bcc9080a519f2f0,9,Rollup merge of #80040 - tmiasko:always-lower-intrinsics r=Dylan-DPC Always run intrinsics lowering pass Move intrinsics lowering pass from the optimization phase (where it would not run if -Zmir-opt-level=0) to the drop lowering phase where it runs unconditionally. The implementation of those intrinsics in code generation and interpreter is unnecessary. Remove it.,HEART,2020-12-15T19:22:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80042,MERGED,2020-12-14T23:52:50Z,2021-01-12T02:56:40Z,Split a func into cold/hot parts reducing binary size,sivadeilra,56504a00f2ea183653beb0a06393343c99cdf6e2,1,Rollup merge of #80042 - sivadeilra:cold_bits r=oli-obk Split a func into cold/hot parts reducing binary size I noticed that the Size::bits function is called in many places and is inlined into them. On x86_64-pc-windows-msvc this function is inlined 527 times and compiled separately (non-inlined) 3 times. Each of those inlined calls contains code that panics. This commit moves the `panic!` call into a separate function and marks that function with `#[cold]`. This reduces binary size by 24 KB. Not much but it's something. Changes like this often reduce pressure on instruction-caches since it reduces the amount of code that is inlined into hot code paths. Or more precisely it removes cold code from hot cache lines.,THUMBS_UP,2020-12-15T01:23:49Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80042,MERGED,2020-12-14T23:52:50Z,2021-01-12T02:56:40Z,Split a func into cold/hot parts reducing binary size,sivadeilra,56504a00f2ea183653beb0a06393343c99cdf6e2,1,Rollup merge of #80042 - sivadeilra:cold_bits r=oli-obk Split a func into cold/hot parts reducing binary size I noticed that the Size::bits function is called in many places and is inlined into them. On x86_64-pc-windows-msvc this function is inlined 527 times and compiled separately (non-inlined) 3 times. Each of those inlined calls contains code that panics. This commit moves the `panic!` call into a separate function and marks that function with `#[cold]`. This reduces binary size by 24 KB. Not much but it's something. Changes like this often reduce pressure on instruction-caches since it reduces the amount of code that is inlined into hot code paths. Or more precisely it removes cold code from hot cache lines.,THUMBS_UP,2021-01-22T16:27:35Z,tiby312,NA https://github.com/rust-lang/rust/pull/80042,MERGED,2020-12-14T23:52:50Z,2021-01-12T02:56:40Z,Split a func into cold/hot parts reducing binary size,sivadeilra,56504a00f2ea183653beb0a06393343c99cdf6e2,1,Rollup merge of #80042 - sivadeilra:cold_bits r=oli-obk Split a func into cold/hot parts reducing binary size I noticed that the Size::bits function is called in many places and is inlined into them. On x86_64-pc-windows-msvc this function is inlined 527 times and compiled separately (non-inlined) 3 times. Each of those inlined calls contains code that panics. This commit moves the `panic!` call into a separate function and marks that function with `#[cold]`. This reduces binary size by 24 KB. Not much but it's something. Changes like this often reduce pressure on instruction-caches since it reduces the amount of code that is inlined into hot code paths. Or more precisely it removes cold code from hot cache lines.,THUMBS_UP,2021-01-23T17:29:27Z,tux3,NA https://github.com/rust-lang/rust/pull/80050,CLOSED,2020-12-15T10:44:03Z,2020-12-17T13:21:29Z,Only derive PartialOrd::partial_cmp when also deriving PartialEq,rylev,NA,NA,NA,HOORAY,2020-12-15T14:05:17Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/80050,CLOSED,2020-12-15T10:44:03Z,2020-12-17T13:21:29Z,Only derive PartialOrd::partial_cmp when also deriving PartialEq,rylev,NA,NA,NA,HOORAY,2020-12-15T17:22:14Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/80050,CLOSED,2020-12-15T10:44:03Z,2020-12-17T13:21:29Z,Only derive PartialOrd::partial_cmp when also deriving PartialEq,rylev,NA,NA,NA,HEART,2020-12-15T19:25:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80050,CLOSED,2020-12-15T10:44:03Z,2020-12-17T13:21:29Z,Only derive PartialOrd::partial_cmp when also deriving PartialEq,rylev,NA,NA,NA,HEART,2020-12-15T20:12:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HOORAY,2020-12-16T22:05:07Z,efx,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HOORAY,2020-12-17T18:22:12Z,PaulDance,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HOORAY,2021-01-29T02:53:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HOORAY,2021-02-01T08:18:49Z,iago-lito,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HEART,2021-02-01T08:18:51Z,iago-lito,NA https://github.com/rust-lang/rust/pull/80053,MERGED,2020-12-15T13:10:28Z,2021-01-31T05:58:24Z,stabilise `cargo test -- --include-ignored`,gilescope,b28a1b29511ebbc13021165a96163d32a98bb7e7,2,Rollup merge of #80053 - gilescope:include-ignore r=m-ou-se stabilise `cargo test -- --include-ignored` stabilise `cargo test -- --include-ignored` On stable there's no way to run ignored tests as well as the normal tests. An example use case where stabilising this would help: Exercism has some initial tests and then some additional ignored tests that people run currently with --ignore but currently they can't run all the tests in one go without being on nightly. It would be a little more ergonomic if this flag was stablilised. ( Fixes #65770 ) I built with ./x.py build -i library/test - but as libtest is a dylib is there an easy way to invoke it manually to check it's working as expected? (I've updated the automated tests.),HEART,2021-03-25T14:33:45Z,rafaelalvessa,rafael@rafael.me.uk https://github.com/rust-lang/rust/pull/80065,MERGED,2020-12-15T22:02:46Z,2021-01-23T09:18:48Z,Improve diagnostics when parsing angle args,b-naber,1986b58c646a9523d0a8a0fa8a0bd20492e7795d,17,Auto merge of #80065 - b-naber:parse-angle-arg-diagnostics r=petrochenkov Improve diagnostics when parsing angle args https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32 _ _) = vec![]` which outputs an incorrectly parsed equality constraint error as noted by `@cynecx.` This PR tries to provide better error messages in such cases. r? `@petrochenkov`,HOORAY,2020-12-15T23:27:53Z,cynecx,NA https://github.com/rust-lang/rust/pull/80065,MERGED,2020-12-15T22:02:46Z,2021-01-23T09:18:48Z,Improve diagnostics when parsing angle args,b-naber,1986b58c646a9523d0a8a0fa8a0bd20492e7795d,17,Auto merge of #80065 - b-naber:parse-angle-arg-diagnostics r=petrochenkov Improve diagnostics when parsing angle args https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32 _ _) = vec![]` which outputs an incorrectly parsed equality constraint error as noted by `@cynecx.` This PR tries to provide better error messages in such cases. r? `@petrochenkov`,HOORAY,2021-01-29T02:44:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80073,MERGED,2020-12-16T09:45:48Z,2020-12-17T06:00:18Z,Add support for target aliases,kulikjak,0b1e71899e611e495042db29bfd69e79718105a6,2,Rollup merge of #80073 - kulikjak:add-target-alias-support r=varkor Add support for target aliases Closes #68214 see that for more info. `@varkor`,HEART,2020-12-16T10:30:12Z,varkor,NA https://github.com/rust-lang/rust/pull/80080,MERGED,2020-12-16T16:31:23Z,2021-06-10T23:13:59Z,Allow qualified paths in struct construction (both expressions and patterns),rylev,16e18395ce33ca1ebfe60a591fb2f9317a75d822,38,Auto merge of #80080 - rylev:qpath-on-struct r=petrochenkov Allow qualified paths in struct construction (both expressions and patterns) Fixes #79658,THUMBS_UP,2020-12-18T23:22:06Z,estebank,NA https://github.com/rust-lang/rust/pull/80080,MERGED,2020-12-16T16:31:23Z,2021-06-10T23:13:59Z,Allow qualified paths in struct construction (both expressions and patterns),rylev,16e18395ce33ca1ebfe60a591fb2f9317a75d822,38,Auto merge of #80080 - rylev:qpath-on-struct r=petrochenkov Allow qualified paths in struct construction (both expressions and patterns) Fixes #79658,THUMBS_UP,2021-04-01T08:45:24Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/80087,MERGED,2020-12-16T19:18:29Z,2020-12-16T22:24:32Z,bootstrap: include llvm-dwp in CI LLVM,davidtwco,b32e6e6ac8921035177256ab6806e6ab0d4b9b94,1,Auto merge of #80087 - davidtwco:issue-80086-llvm-dwp-in-ci-llvm r=Mark-Simulacrum bootstrap: include llvm-dwp in CI LLVM Fixes #80086. This PR includes the `llvm-dwp` tool in the CI LLVM (which rustc developers can download instead of building LLVM locally) - `llvm-dwp` is required by Split DWARF which landed in PR #77117. r? `@Mark-Simulacrum`,HEART,2020-12-16T19:19:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80087,MERGED,2020-12-16T19:18:29Z,2020-12-16T22:24:32Z,bootstrap: include llvm-dwp in CI LLVM,davidtwco,b32e6e6ac8921035177256ab6806e6ab0d4b9b94,1,Auto merge of #80087 - davidtwco:issue-80086-llvm-dwp-in-ci-llvm r=Mark-Simulacrum bootstrap: include llvm-dwp in CI LLVM Fixes #80086. This PR includes the `llvm-dwp` tool in the CI LLVM (which rustc developers can download instead of building LLVM locally) - `llvm-dwp` is required by Split DWARF which landed in PR #77117. r? `@Mark-Simulacrum`,HEART,2020-12-16T19:26:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/80097,MERGED,2020-12-16T23:15:53Z,2020-12-17T06:00:18Z,Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.,SimonSapin,e4735ddec01551d3f7b3d4d76527d2d0bb70e242,3,"Rollup merge of #80097 - SimonSapin:popcount r=m-ou-se Add `popcount` and `popcnt` as doc aliases for `count_ones` methods. Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures that intrinsic is translated as a corresponding CPU instruction know as ""popcount"" or ""popcnt"". This PR makes it so that searching for those names in rustdoc shows those methods. CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases",THUMBS_UP,2020-12-17T00:01:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80097,MERGED,2020-12-16T23:15:53Z,2020-12-17T06:00:18Z,Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.,SimonSapin,e4735ddec01551d3f7b3d4d76527d2d0bb70e242,3,"Rollup merge of #80097 - SimonSapin:popcount r=m-ou-se Add `popcount` and `popcnt` as doc aliases for `count_ones` methods. Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures that intrinsic is translated as a corresponding CPU instruction know as ""popcount"" or ""popcnt"". This PR makes it so that searching for those names in rustdoc shows those methods. CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases",THUMBS_UP,2020-12-17T08:31:21Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/80097,MERGED,2020-12-16T23:15:53Z,2020-12-17T06:00:18Z,Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.,SimonSapin,e4735ddec01551d3f7b3d4d76527d2d0bb70e242,3,"Rollup merge of #80097 - SimonSapin:popcount r=m-ou-se Add `popcount` and `popcnt` as doc aliases for `count_ones` methods. Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures that intrinsic is translated as a corresponding CPU instruction know as ""popcount"" or ""popcnt"". This PR makes it so that searching for those names in rustdoc shows those methods. CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases",THUMBS_UP,2020-12-18T14:40:03Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80100,MERGED,2020-12-17T00:12:16Z,2020-12-20T07:01:02Z,or_patterns: implement :pat edition-specific behavior,mark-i-m,29e32120c33d30ff526fc7f4d94ec9fce0dc10c9,14,Auto merge of #80100 - mark-i-m:pattORns-2 r=petrochenkov or_patterns: implement :pat edition-specific behavior cc #54883 `@joshtriplett` This PR implements the edition-specific behavior of `:pat` wrt or-patterns as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090. I believe this can unblock stabilization of or_patterns. r? `@petrochenkov`,HEART,2020-12-20T09:02:13Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/80100,MERGED,2020-12-17T00:12:16Z,2020-12-20T07:01:02Z,or_patterns: implement :pat edition-specific behavior,mark-i-m,29e32120c33d30ff526fc7f4d94ec9fce0dc10c9,14,Auto merge of #80100 - mark-i-m:pattORns-2 r=petrochenkov or_patterns: implement :pat edition-specific behavior cc #54883 `@joshtriplett` This PR implements the edition-specific behavior of `:pat` wrt or-patterns as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090. I believe this can unblock stabilization of or_patterns. r? `@petrochenkov`,HEART,2020-12-24T10:53:10Z,fmease,NA https://github.com/rust-lang/rust/pull/80104,MERGED,2020-12-17T02:11:35Z,2020-12-19T21:57:38Z,Improve and fix diagnostics of exhaustiveness checking,Nadrieril,1f5bc176b0e54a8e464704adcd7e571700207fe9,12,Auto merge of #80104 - Nadrieril:usefulness-merging r=varkor Improve and fix diagnostics of exhaustiveness checking Primarily this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics: ```rust match &[][..] { [true] => {} [true // detected as unreachable but that's not true | false ..] => {} _ => {} } match (true None) { (true Some(_)) => {} (false Some(true)) => {} (true | false None | Some(true // should be detected as unreachable | false)) => {} } ``` I did not measure any perf impact. However I suspect that [`616ba9f`](https://github.com/rust-lang/rust/pull/80104/commits/616ba9f9f7f5845777a36e1a41a515e6c33a8776) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed. EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x) r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,HEART,2020-12-19T13:27:39Z,varkor,NA https://github.com/rust-lang/rust/pull/80104,MERGED,2020-12-17T02:11:35Z,2020-12-19T21:57:38Z,Improve and fix diagnostics of exhaustiveness checking,Nadrieril,1f5bc176b0e54a8e464704adcd7e571700207fe9,12,Auto merge of #80104 - Nadrieril:usefulness-merging r=varkor Improve and fix diagnostics of exhaustiveness checking Primarily this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics: ```rust match &[][..] { [true] => {} [true // detected as unreachable but that's not true | false ..] => {} _ => {} } match (true None) { (true Some(_)) => {} (false Some(true)) => {} (true | false None | Some(true // should be detected as unreachable | false)) => {} } ``` I did not measure any perf impact. However I suspect that [`616ba9f`](https://github.com/rust-lang/rust/pull/80104/commits/616ba9f9f7f5845777a36e1a41a515e6c33a8776) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed. EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x) r? `@varkor` `@rustbot` label +A-exhaustiveness-checking,HEART,2020-12-19T21:08:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80119,MERGED,2020-12-17T15:25:37Z,2020-12-18T08:44:49Z,Continue String to Symbol conversion in rustdoc (1),GuillaumeGomez,fee693d08e98d25f566075cbed73e12236c05abd,9,Auto merge of #80119 - GuillaumeGomez:str-to-symbol r=jyn514 Continue String to Symbol conversion in rustdoc Follow-up of https://github.com/rust-lang/rust/pull/80091. This PR is already big enough so I'll stop here before the next one. r? `@jyn514`,LAUGH,2020-12-17T16:05:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80121,MERGED,2020-12-17T16:13:46Z,2020-12-18T19:09:20Z,Change the message for `if_let_guard` feature gate,LeSeulArtichaut,ea6cc5aab5bec6fd48783b7d6ba08688b8497ca6,3,Rollup merge of #80121 - LeSeulArtichaut:if-let-experimental r=davidtwco Change the message for `if_let_guard` feature gate `if-let` guards are now implemented by #79051 🎉 Thanks ``@camelid`` for pointing this out 🙂,HEART,2020-12-17T22:27:19Z,camelid,NA https://github.com/rust-lang/rust/pull/80141,CLOSED,2020-12-18T01:06:04Z,2021-01-15T13:40:36Z,WIP: Implement core::ops::{AddAssign SubAssign} for Atomic*Int-types,dns2utf8,NA,NA,NA,CONFUSED,2020-12-18T20:20:20Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/80149,OPEN,2020-12-18T09:31:30Z,NA,Use getrandom for generating HashMap seed,newpavlov,NA,NA,NA,HOORAY,2020-12-18T15:18:08Z,pitdicker,NA https://github.com/rust-lang/rust/pull/80149,OPEN,2020-12-18T09:31:30Z,NA,Use getrandom for generating HashMap seed,newpavlov,NA,NA,NA,HOORAY,2021-01-05T11:09:58Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/80149,OPEN,2020-12-18T09:31:30Z,NA,Use getrandom for generating HashMap seed,newpavlov,NA,NA,NA,HOORAY,2021-10-15T15:47:07Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/80160,MERGED,2020-12-18T16:41:33Z,2020-12-25T08:17:04Z,Implemented a compiler diagnostic for move async mistake,diondokter,299c2fc69554998e8991715d09a611376a5b9cf3,5,Rollup merge of #80160 - diondokter:move_async_fix r=davidtwco Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing so I hope I'm doing everything right. (If not please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||` found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄,HEART,2020-12-29T01:53:40Z,tmandry,NA https://github.com/rust-lang/rust/pull/80160,MERGED,2020-12-18T16:41:33Z,2020-12-25T08:17:04Z,Implemented a compiler diagnostic for move async mistake,diondokter,299c2fc69554998e8991715d09a611376a5b9cf3,5,Rollup merge of #80160 - diondokter:move_async_fix r=davidtwco Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing so I hope I'm doing everything right. (If not please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||` found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄,HEART,2020-12-31T07:56:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80160,MERGED,2020-12-18T16:41:33Z,2020-12-25T08:17:04Z,Implemented a compiler diagnostic for move async mistake,diondokter,299c2fc69554998e8991715d09a611376a5b9cf3,5,Rollup merge of #80160 - diondokter:move_async_fix r=davidtwco Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing so I hope I'm doing everything right. (If not please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||` found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄,HEART,2021-01-01T12:17:08Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/80160,MERGED,2020-12-18T16:41:33Z,2020-12-25T08:17:04Z,Implemented a compiler diagnostic for move async mistake,diondokter,299c2fc69554998e8991715d09a611376a5b9cf3,5,Rollup merge of #80160 - diondokter:move_async_fix r=davidtwco Implemented a compiler diagnostic for move async mistake Fixes #79694 First time contributing so I hope I'm doing everything right. (If not please correct me!) This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it. Checked code: ```rust fn main() { move async { }; } ``` Previous output: ```txt PS C:\Repos\move_async_test> cargo build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: expected one of `|` or `||` found keyword `async` --> src\main.rs:2:10 | 2 | move async { }; | ^^^^^ expected one of `|` or `||` error: aborting due to previous error error: could not compile `move_async_test` ``` New output: ```txt PS C:\Repos\move_async_test> cargo +dev build Compiling move_async_test v0.1.0 (C:\Repos\move_async_test) error: the order of `move` and `async` is incorrect --> src\main.rs:2:13 | 2 | let _ = move async { }; | ^^^^^^^^^^ | help: try switching the order | 2 | let _ = async move { }; | ^^^^^^^^^^ error: aborting due to previous error error: could not compile `move_async_test` ``` Is there a file/module where these kind of things are tested? Would love some feedback 😄,HEART,2021-01-05T06:40:11Z,MoreTacos,NA https://github.com/rust-lang/rust/pull/80177,MERGED,2020-12-19T03:06:32Z,2020-12-22T21:51:09Z,rustc_query_system: explicitly register reused dep nodes,tgnottingham,bb1fbbf84455fbad9afd26c17e0f725019322655,6,Auto merge of #80177 - tgnottingham:foreign_defpathhash_registration r=Aaron1011 rustc_query_system: explicitly register reused dep nodes Register nodes that we've reused from the previous session explicitly with `OnDiskCache`. Previously we relied on this happening as a side effect of accessing the nodes in the `PreviousDepGraph`. For the sake of performance and avoiding unintended side effects register explictily.,THUMBS_UP,2020-12-19T08:04:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80193,MERGED,2020-12-19T15:26:43Z,2021-03-22T06:45:35Z,stabilize `feature(osstring_ascii)`,zseri,e9398bcc4d7dd3b5ccdd705dc4ba8d29bbb96354,1,Rollup merge of #80193 - zseri:stabilize-osstring-ascii r=m-ou-se stabilize `feature(osstring_ascii)` This PR stabilizes `feature(osstring_ascii)`. Fixes #70516.,THUMBS_UP,2021-01-10T00:56:49Z,dreamer,dreamer.tan@gmail.com https://github.com/rust-lang/rust/pull/80193,MERGED,2020-12-19T15:26:43Z,2021-03-22T06:45:35Z,stabilize `feature(osstring_ascii)`,zseri,e9398bcc4d7dd3b5ccdd705dc4ba8d29bbb96354,1,Rollup merge of #80193 - zseri:stabilize-osstring-ascii r=m-ou-se stabilize `feature(osstring_ascii)` This PR stabilizes `feature(osstring_ascii)`. Fixes #70516.,THUMBS_UP,2021-02-02T13:05:36Z,jplatte,NA https://github.com/rust-lang/rust/pull/80193,MERGED,2020-12-19T15:26:43Z,2021-03-22T06:45:35Z,stabilize `feature(osstring_ascii)`,zseri,e9398bcc4d7dd3b5ccdd705dc4ba8d29bbb96354,1,Rollup merge of #80193 - zseri:stabilize-osstring-ascii r=m-ou-se stabilize `feature(osstring_ascii)` This PR stabilizes `feature(osstring_ascii)`. Fixes #70516.,THUMBS_UP,2021-03-25T06:30:13Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/80200,MERGED,2020-12-19T19:43:59Z,2021-01-07T06:00:03Z,Optimize DST field access,mahkoh,dfdfaa1f0442dac516ba87d274d832c00464b3c2,1,"Auto merge of #80200 - mahkoh:dst-offset r=nagisa Optimize DST field access For struct X(T) struct Y(u8 T) the offset of the unsized field is 0 mem::align_of_val(&self.1) respectively. This patch changes the expression used to compute these offsets so that the optimizer can perform this optimization. Consider ```rust fn f(x: &X) -> &dyn Any { &x.0 } ``` Before: ```asm test: movq %rsi %rdx movq 16(%rsi) %rax leaq -1(%rax) %rcx negq %rax andq %rcx %rax addq %rdi %rax retq ``` After: ```asm test: movq %rsi %rdx movq %rdi %rax retq ```",THUMBS_UP,2021-01-07T01:21:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/80200,MERGED,2020-12-19T19:43:59Z,2021-01-07T06:00:03Z,Optimize DST field access,mahkoh,dfdfaa1f0442dac516ba87d274d832c00464b3c2,1,"Auto merge of #80200 - mahkoh:dst-offset r=nagisa Optimize DST field access For struct X(T) struct Y(u8 T) the offset of the unsized field is 0 mem::align_of_val(&self.1) respectively. This patch changes the expression used to compute these offsets so that the optimizer can perform this optimization. Consider ```rust fn f(x: &X) -> &dyn Any { &x.0 } ``` Before: ```asm test: movq %rsi %rdx movq 16(%rsi) %rax leaq -1(%rax) %rcx negq %rax andq %rcx %rax addq %rdi %rax retq ``` After: ```asm test: movq %rsi %rdx movq %rdi %rax retq ```",THUMBS_UP,2021-01-15T18:09:56Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80200,MERGED,2020-12-19T19:43:59Z,2021-01-07T06:00:03Z,Optimize DST field access,mahkoh,dfdfaa1f0442dac516ba87d274d832c00464b3c2,1,"Auto merge of #80200 - mahkoh:dst-offset r=nagisa Optimize DST field access For struct X(T) struct Y(u8 T) the offset of the unsized field is 0 mem::align_of_val(&self.1) respectively. This patch changes the expression used to compute these offsets so that the optimizer can perform this optimization. Consider ```rust fn f(x: &X) -> &dyn Any { &x.0 } ``` Before: ```asm test: movq %rsi %rdx movq 16(%rsi) %rax leaq -1(%rax) %rcx negq %rax andq %rcx %rax addq %rdi %rax retq ``` After: ```asm test: movq %rsi %rdx movq %rdi %rax retq ```",THUMBS_UP,2021-01-15T19:58:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80200,MERGED,2020-12-19T19:43:59Z,2021-01-07T06:00:03Z,Optimize DST field access,mahkoh,dfdfaa1f0442dac516ba87d274d832c00464b3c2,1,"Auto merge of #80200 - mahkoh:dst-offset r=nagisa Optimize DST field access For struct X(T) struct Y(u8 T) the offset of the unsized field is 0 mem::align_of_val(&self.1) respectively. This patch changes the expression used to compute these offsets so that the optimizer can perform this optimization. Consider ```rust fn f(x: &X) -> &dyn Any { &x.0 } ``` Before: ```asm test: movq %rsi %rdx movq 16(%rsi) %rax leaq -1(%rax) %rcx negq %rax andq %rcx %rax addq %rdi %rax retq ``` After: ```asm test: movq %rsi %rdx movq %rdi %rax retq ```",THUMBS_UP,2021-01-17T22:32:12Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/80200,MERGED,2020-12-19T19:43:59Z,2021-01-07T06:00:03Z,Optimize DST field access,mahkoh,dfdfaa1f0442dac516ba87d274d832c00464b3c2,1,"Auto merge of #80200 - mahkoh:dst-offset r=nagisa Optimize DST field access For struct X(T) struct Y(u8 T) the offset of the unsized field is 0 mem::align_of_val(&self.1) respectively. This patch changes the expression used to compute these offsets so that the optimizer can perform this optimization. Consider ```rust fn f(x: &X) -> &dyn Any { &x.0 } ``` Before: ```asm test: movq %rsi %rdx movq 16(%rsi) %rax leaq -1(%rax) %rcx negq %rax andq %rcx %rax addq %rdi %rax retq ``` After: ```asm test: movq %rsi %rdx movq %rdi %rax retq ```",THUMBS_UP,2021-01-20T11:13:18Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80203,MERGED,2020-12-19T22:10:44Z,2020-12-23T03:35:34Z,Edit rustc_middle::lint::LintSource docs,pierwill,f84ec97485f34bc8e0f6e194f7b48ce463c9098a,1,Rollup merge of #80203 - pierwill:pierwill-rustcmiddle-lint r=oli-obk Edit rustc_middle::lint::LintSource docs Edit punctuation in doc comment for [rustc_middle::lint::LintSource::CommandLine](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html#variant.CommandLine).,THUMBS_UP,2020-12-21T10:40:17Z,oli-obk,NA https://github.com/rust-lang/rust/pull/80217,MERGED,2020-12-20T04:38:49Z,2021-01-14T23:07:37Z,Add a `std::io::read_to_string` function,camelid,9fc298ca894204fc9699f8989b2d3f1bf425d583,1,Rollup merge of #80217 - camelid:io-read_to_string r=m-ou-se Add a `std::io::read_to_string` function I recognize that you're usually supposed to open an issue first but the implementation is very small so it's okay if this is closed and it was 'wasted work' :) ----- The equivalent of `std::fs::read_to_string` but generalized to all `Read` impls. As the documentation on `std::io::read_to_string` says the advantage of this function is that it means you don't have to create a variable first and it provides more type safety since you can only get the buffer out if there were no errors. If you use `Read::read_to_string` you have to remember to check whether the read succeeded because otherwise your buffer will be empty. It's friendlier to newcomers and better in most cases to use an explicit return value instead of an out parameter.,HEART,2021-03-03T01:29:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80217,MERGED,2020-12-20T04:38:49Z,2021-01-14T23:07:37Z,Add a `std::io::read_to_string` function,camelid,9fc298ca894204fc9699f8989b2d3f1bf425d583,1,Rollup merge of #80217 - camelid:io-read_to_string r=m-ou-se Add a `std::io::read_to_string` function I recognize that you're usually supposed to open an issue first but the implementation is very small so it's okay if this is closed and it was 'wasted work' :) ----- The equivalent of `std::fs::read_to_string` but generalized to all `Read` impls. As the documentation on `std::io::read_to_string` says the advantage of this function is that it means you don't have to create a variable first and it provides more type safety since you can only get the buffer out if there were no errors. If you use `Read::read_to_string` you have to remember to check whether the read succeeded because otherwise your buffer will be empty. It's friendlier to newcomers and better in most cases to use an explicit return value instead of an out parameter.,HEART,2021-06-11T06:03:28Z,DesmondWillowbrook,sendtokartavya@gmail.com https://github.com/rust-lang/rust/pull/80235,MERGED,2020-12-20T14:54:01Z,2020-12-25T21:19:13Z,validate promoteds,RalfJung,bb178237c5539c75e1b85ab78a8ab902b1f333d5,2,Auto merge of #80235 - RalfJung:validate-promoteds r=oli-obk validate promoteds Turn on const-value validation for promoteds. This is made possible now that https://github.com/rust-lang/rust/issues/67534 is resolved. I don't think this is a breaking change. We don't promote any unsafe operation any more (since https://github.com/rust-lang/rust/pull/77526 landed). We *do* promote `const fn` calls under some circumstances (in `const`/`static` initializers) but union field access and similar operations are not allowed in `const fn`. So now is a perfect time to add this check. :D r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/67465,HEART,2020-12-20T16:45:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/80242,MERGED,2020-12-20T17:59:01Z,2020-12-23T00:41:48Z,Clarify constructor splitting in exhaustiveness checking,Nadrieril,969b42d8c0e44c6b895ab4582b5ae0a0ce319fdf,4,Auto merge of #80242 - Nadrieril:explain-and-factor-splitting r=varkor Clarify constructor splitting in exhaustiveness checking I reworked the explanation of the algorithm completely to make it properly account for the various extensions we've added. This includes constructor splitting which was previously not clearly included in the algorithm. This makes wildcards less magical; I added some detailed examples; and this distinguishes clearly between constructors that only make sense in patterns (like ranges) and those that make sense for values (like `Some`). This reformulation had been floating around in my mind for a while and I'm quite happy with how it turned out. Let me know how you feel about it. I also factored out all three cases of splitting (wildcards ranges and slices) into dedicated structs to encapsulate the complicated bits. I measured no perf impact but I don't trust my local measurements for refactors since https://github.com/rust-lang/rust/pull/79284. r? `@varkor` `@rustbot` modify labels: +A-exhaustiveness-checking,HEART,2020-12-22T15:56:03Z,varkor,NA https://github.com/rust-lang/rust/pull/80248,MERGED,2020-12-20T22:09:58Z,2020-12-23T03:35:33Z,Remove `I-prioritize` from Zulip topic,camelid,805c8ac90c5fd2bc1e49495d4ce294013ca8cd72,1,Rollup merge of #80248 - camelid:prioritize-zulip-topic r=Mark-Simulacrum Remove `I-prioritize` from Zulip topic It doesn't add anything since every topic in `t-compiler/wg-prioritization/alerts` is about prioritization. And it makes it harder to see the issue title which is what the topic is actually about. cc ``@rust-lang/wg-prioritization``,THUMBS_UP,2020-12-20T22:12:25Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/80248,MERGED,2020-12-20T22:09:58Z,2020-12-23T03:35:33Z,Remove `I-prioritize` from Zulip topic,camelid,805c8ac90c5fd2bc1e49495d4ce294013ca8cd72,1,Rollup merge of #80248 - camelid:prioritize-zulip-topic r=Mark-Simulacrum Remove `I-prioritize` from Zulip topic It doesn't add anything since every topic in `t-compiler/wg-prioritization/alerts` is about prioritization. And it makes it harder to see the issue title which is what the topic is actually about. cc ``@rust-lang/wg-prioritization``,THUMBS_UP,2020-12-20T22:12:41Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/80248,MERGED,2020-12-20T22:09:58Z,2020-12-23T03:35:33Z,Remove `I-prioritize` from Zulip topic,camelid,805c8ac90c5fd2bc1e49495d4ce294013ca8cd72,1,Rollup merge of #80248 - camelid:prioritize-zulip-topic r=Mark-Simulacrum Remove `I-prioritize` from Zulip topic It doesn't add anything since every topic in `t-compiler/wg-prioritization/alerts` is about prioritization. And it makes it harder to see the issue title which is what the topic is actually about. cc ``@rust-lang/wg-prioritization``,THUMBS_UP,2020-12-21T00:32:04Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/80254,MERGED,2020-12-21T02:10:54Z,2021-01-15T12:26:01Z,Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`,Aaron1011,0dedc6c0546c709087ebad1dc1f9d85b183b2f09,2,Rollup merge of #80254 - Aaron1011:rustdoc-auto-param-env r=estebank Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv` Fixes #80233 We already have logic in `evaluate_predicates` that tries to add unimplemented predicates to our `ParamEnv`. Trying to add a predicate that already holds can lead to errors later on since projection will prefer trait candidates from the `ParamEnv` to predicates from an impl.,HEART,2020-12-21T03:32:32Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-21T14:50:58Z,lqd,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-21T14:51:00Z,lqd,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-21T16:31:46Z,mati865,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-21T17:35:13Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-21T18:22:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),THUMBS_UP,2020-12-22T04:35:48Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-22T07:27:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-22T23:38:07Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-28T16:00:03Z,a1phyr,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-31T07:54:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2020-12-31T10:57:44Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-31T11:46:47Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),ROCKET,2020-12-31T14:48:16Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/80262,MERGED,2020-12-21T13:19:47Z,2020-12-23T15:50:39Z,Utilize PGO for rustc linux dist builds,Mark-Simulacrum,3ffea60dd5a2260004cc4f487401ae7c7db1aa0e,8,Auto merge of #80262 - Mark-Simulacrum:pgo-rustc r=pietroalbini Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore cargo (and its dependencies) and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI though so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially in the future on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others),HOORAY,2021-01-21T15:33:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80272,MERGED,2020-12-21T19:52:01Z,2020-12-23T03:35:33Z,rustc_span: Provide a reserved identifier check for a specific edition,petrochenkov,aa7cb4ff0024a3445d61e10c2afcedac26ce96d1,1,Rollup merge of #80272 - petrochenkov:kwed r=oli-obk rustc_span: Provide a reserved identifier check for a specific edition while keeping edition evaluation lazy because it may be expensive. Needed for https://github.com/rust-lang/rust/pull/80226.,THUMBS_UP,2020-12-21T19:57:01Z,ThePuzzlemaker,tpzker@thepuzzlemaker.info https://github.com/rust-lang/rust/pull/80273,CLOSED,2020-12-21T22:26:13Z,2021-05-06T13:30:28Z,[RFC] Add allocators for zero-copy conversion from Box into Rc,mahkoh,NA,NA,NA,EYES,2021-02-01T21:31:26Z,the8472,NA https://github.com/rust-lang/rust/pull/80274,MERGED,2020-12-21T22:33:29Z,2020-12-25T08:17:04Z,Rename rustc_middle::lint::LintSource,pierwill,b295b8e67b6e35cc74ca9706d4b9938ad8379419,5,Rollup merge of #80274 - pierwill:lintlevelsource r=petrochenkov Rename rustc_middle::lint::LintSource Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`. This enum represents the source of a *lint level* not a lint. This should improve code readability. Update: Also documents `rustc_middle::lint::LevelSource` to clarify.,THUMBS_UP,2020-12-21T22:36:05Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/80279,MERGED,2020-12-22T00:25:46Z,2021-01-31T05:58:24Z,Implement missing `AsMut` for `str`,Yaulendil,054c29d22ca171ea8565cc5c53dbbf0d473f05eb,1,Rollup merge of #80279 - Yaulendil:str-as-mut r=m-ou-se Implement missing `AsMut` for `str` Allows `&mut str` to be taken by a Generic which requires `T` such that `T: AsMut`. Motivating example: ```rust impl<'i T> From for StructImmut<'i> where T: AsRef + 'i { fn from(asref: T) -> Self { let string: &str = asref.as_ref(); // ... } } impl<'i T> From for StructMut<'i> where T: AsMut + 'i { fn from(mut asmut: T) -> Self { let string: &mut str = asmut.as_mut(); // ... } } ``` The Immutable form of this structure can be constructed by `StructImmut::from(s)` where `s` may be a `&String` or a `&str` because `AsRef` is implemented for `str`. However the mutable form of the structure can be constructed in the same way **only** with a `&mut String` and **not** with a `&mut str`. This change does have some precedent because as can be seen in [the Implementors](https://doc.rust-lang.org/std/convert/trait.AsMut.html#implementors) `AsMut<[T]>` is implemented for `[T]` as well as for `Vec` but `AsMut` is implemented only for `String`. This would complete the symmetry. As a trait implementation this should be immediately stable.,THUMBS_UP,2020-12-25T07:03:54Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/80279,MERGED,2020-12-22T00:25:46Z,2021-01-31T05:58:24Z,Implement missing `AsMut` for `str`,Yaulendil,054c29d22ca171ea8565cc5c53dbbf0d473f05eb,1,Rollup merge of #80279 - Yaulendil:str-as-mut r=m-ou-se Implement missing `AsMut` for `str` Allows `&mut str` to be taken by a Generic which requires `T` such that `T: AsMut`. Motivating example: ```rust impl<'i T> From for StructImmut<'i> where T: AsRef + 'i { fn from(asref: T) -> Self { let string: &str = asref.as_ref(); // ... } } impl<'i T> From for StructMut<'i> where T: AsMut + 'i { fn from(mut asmut: T) -> Self { let string: &mut str = asmut.as_mut(); // ... } } ``` The Immutable form of this structure can be constructed by `StructImmut::from(s)` where `s` may be a `&String` or a `&str` because `AsRef` is implemented for `str`. However the mutable form of the structure can be constructed in the same way **only** with a `&mut String` and **not** with a `&mut str`. This change does have some precedent because as can be seen in [the Implementors](https://doc.rust-lang.org/std/convert/trait.AsMut.html#implementors) `AsMut<[T]>` is implemented for `[T]` as well as for `Vec` but `AsMut` is implemented only for `String`. This would complete the symmetry. As a trait implementation this should be immediately stable.,THUMBS_UP,2021-01-22T10:40:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80284,MERGED,2020-12-22T02:52:05Z,2020-12-28T18:50:18Z,Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121,ThePuzzlemaker,12ac31235151bbce00be0e0324904c3803e5083d,3,Rollup merge of #80284 - ThePuzzlemaker:issue-80179-fix r=varkor Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121 Previously using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example: ```rust fn f() -> i32 { 0 } fn fn_ptr() -> _ { f } fn closure() -> _ { || 0 } ``` would result in this diagnostic: ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32 {f}` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `[closure@:3:21: 3:25]` error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally closures cause a papercut as unique closure types (notated in this case as `[closure@:3:21: 3:25]`) are not valid syntax either. Instead this PR implements this version of the diagnostic (this example is for the same code featured above): ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ not allowed in type signatures | = help: consider using an `Fn` `FnMut` or `FnOnce` trait bound = note: for more information on `Fn` traits and closure types see https://doc.rust-lang.org/book/ch13-01-closures.html error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen in this diagnostic the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures it's suggested to use an `Fn` `FnMut` or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment therefore someone in the future may want to implement that. Also it's possible to use either `impl Trait` syntax generics or generics with a `where` clause and some users may not want to use `impl Trait` syntax for their own reasons. This PR fixes #80179.,HOORAY,2020-12-22T03:21:32Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/80284,MERGED,2020-12-22T02:52:05Z,2020-12-28T18:50:18Z,Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121,ThePuzzlemaker,12ac31235151bbce00be0e0324904c3803e5083d,3,Rollup merge of #80284 - ThePuzzlemaker:issue-80179-fix r=varkor Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121 Previously using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example: ```rust fn f() -> i32 { 0 } fn fn_ptr() -> _ { f } fn closure() -> _ { || 0 } ``` would result in this diagnostic: ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32 {f}` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `[closure@:3:21: 3:25]` error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally closures cause a papercut as unique closure types (notated in this case as `[closure@:3:21: 3:25]`) are not valid syntax either. Instead this PR implements this version of the diagnostic (this example is for the same code featured above): ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ not allowed in type signatures | = help: consider using an `Fn` `FnMut` or `FnOnce` trait bound = note: for more information on `Fn` traits and closure types see https://doc.rust-lang.org/book/ch13-01-closures.html error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen in this diagnostic the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures it's suggested to use an `Fn` `FnMut` or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment therefore someone in the future may want to implement that. Also it's possible to use either `impl Trait` syntax generics or generics with a `where` clause and some users may not want to use `impl Trait` syntax for their own reasons. This PR fixes #80179.,HOORAY,2020-12-31T03:59:01Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/80284,MERGED,2020-12-22T02:52:05Z,2020-12-28T18:50:18Z,Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121,ThePuzzlemaker,12ac31235151bbce00be0e0324904c3803e5083d,3,Rollup merge of #80284 - ThePuzzlemaker:issue-80179-fix r=varkor Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121 Previously using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example: ```rust fn f() -> i32 { 0 } fn fn_ptr() -> _ { f } fn closure() -> _ { || 0 } ``` would result in this diagnostic: ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32 {f}` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `[closure@:3:21: 3:25]` error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally closures cause a papercut as unique closure types (notated in this case as `[closure@:3:21: 3:25]`) are not valid syntax either. Instead this PR implements this version of the diagnostic (this example is for the same code featured above): ```rust error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :2:16 | 2 | fn fn_ptr() -> _ { f } | ^ | | | not allowed in type signatures | help: replace with the correct return type: `fn() -> i32` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> :3:17 | 3 | fn closure() -> _ { || 0 } | ^ not allowed in type signatures | = help: consider using an `Fn` `FnMut` or `FnOnce` trait bound = note: for more information on `Fn` traits and closure types see https://doc.rust-lang.org/book/ch13-01-closures.html error: aborting due to 2 previous errors For more information about this error try `rustc --explain E0121`. ``` As can be seen in this diagnostic the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures it's suggested to use an `Fn` `FnMut` or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment therefore someone in the future may want to implement that. Also it's possible to use either `impl Trait` syntax generics or generics with a `where` clause and some users may not want to use `impl Trait` syntax for their own reasons. This PR fixes #80179.,HOORAY,2020-12-31T07:56:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80290,MERGED,2020-12-22T12:08:21Z,2021-01-16T20:26:22Z,implement ptr::write without dedicated intrinsic,RalfJung,492b83c6971c390af7a42932869502224ef55ef7,11,Auto merge of #80290 - RalfJung:less-intrinsic-write r=lcnr implement ptr::write without dedicated intrinsic This makes `ptr::write` more consistent with `ptr::write_unaligned` `ptr::read` `ptr::read_unaligned` all of which are implemented in terms of `copy_nonoverlapping`. This means we can also remove `move_val_init` implementations in codegen and Miri and its special handling in the borrow checker. Also see [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/ptr.3A.3Aread.20vs.20ptr.3A.3Awrite).,HOORAY,2021-01-16T21:33:49Z,kpp,NA https://github.com/rust-lang/rust/pull/80308,CLOSED,2020-12-22T21:22:31Z,2021-02-11T21:17:53Z,Add `as_{ mut_}ptr` methods to `Option`,nvzqz,NA,NA,NA,THUMBS_UP,2020-12-22T21:31:24Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/80308,CLOSED,2020-12-22T21:22:31Z,2021-02-11T21:17:53Z,Add `as_{ mut_}ptr` methods to `Option`,nvzqz,NA,NA,NA,THUMBS_UP,2020-12-22T21:57:00Z,AlieGG,NA https://github.com/rust-lang/rust/pull/80308,CLOSED,2020-12-22T21:22:31Z,2021-02-11T21:17:53Z,Add `as_{ mut_}ptr` methods to `Option`,nvzqz,NA,NA,NA,THUMBS_UP,2020-12-22T22:38:26Z,Hermitter,hi@jellyapple.com https://github.com/rust-lang/rust/pull/80308,CLOSED,2020-12-22T21:22:31Z,2021-02-11T21:17:53Z,Add `as_{ mut_}ptr` methods to `Option`,nvzqz,NA,NA,NA,THUMBS_UP,2020-12-25T09:40:37Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2020-12-23T05:35:25Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2020-12-24T00:14:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2020-12-26T01:49:28Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2020-12-31T20:31:20Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-01T20:37:31Z,de-sh,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-01T22:06:03Z,yerke,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-01T22:06:13Z,Lokathor,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-02T00:03:07Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-02T15:35:49Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-02T19:20:14Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-08T10:52:12Z,tux3,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-14T01:43:49Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-01-15T17:44:23Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-02-18T11:40:11Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-02-27T09:25:01Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-03-29T22:10:36Z,jumpnbrownweasel,NA https://github.com/rust-lang/rust/pull/80310,MERGED,2020-12-22T21:50:22Z,2021-01-01T13:17:49Z,Add fallible Box Arc and Rc allocator APIs,Manishearth,18d27b2c94cff9a5f6d8e4d2ea45f6f2e434e5f6,3,Auto merge of #80310 - Manishearth:box-try-alloc r=kennytm Add fallible Box Arc and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`,HOORAY,2021-05-11T23:46:22Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/80311,MERGED,2020-12-22T22:11:35Z,2020-12-30T18:24:27Z,Improvements to NatVis support,sivadeilra,88b198b727d79c04d35c43feaabaa9e3d1a94f0c,6,Rollup merge of #80311 - sivadeilra:natvis r=petrochenkov Improvements to NatVis support NatVis files describe how to display types in some Windows debuggers such as Visual Studio WinDbg and VS Code. This commit makes several improvements: * Adds visualizers for Rc Weak and Arc. * Changes [size] to [len] for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None` which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type) rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length. * The visualizers for `str` and `String` now place the character data array under a synthetic `[chars]` node. When expanding a `String` node users rarely want to see an array of characters. This just places them behind one expansion node / level.,HEART,2021-02-27T13:01:09Z,lnicola,NA https://github.com/rust-lang/rust/pull/80311,MERGED,2020-12-22T22:11:35Z,2020-12-30T18:24:27Z,Improvements to NatVis support,sivadeilra,88b198b727d79c04d35c43feaabaa9e3d1a94f0c,6,Rollup merge of #80311 - sivadeilra:natvis r=petrochenkov Improvements to NatVis support NatVis files describe how to display types in some Windows debuggers such as Visual Studio WinDbg and VS Code. This commit makes several improvements: * Adds visualizers for Rc Weak and Arc. * Changes [size] to [len] for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None` which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type) rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length. * The visualizers for `str` and `String` now place the character data array under a synthetic `[chars]` node. When expanding a `String` node users rarely want to see an array of characters. This just places them behind one expansion node / level.,HEART,2021-03-07T07:09:17Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/80315,MERGED,2020-12-23T00:01:33Z,2020-12-27T18:55:33Z,Ignore proc-macros when assembling rustc libdir,tmiasko,76188b6830897a875a1289809c12b5c5d69bb7ef,1,Auto merge of #80315 - tmiasko:ignore-proc-macros r=Mark-Simulacrum Ignore proc-macros when assembling rustc libdir Fixes #80294.,HOORAY,2020-12-23T00:35:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80316,MERGED,2020-12-23T00:35:08Z,2020-12-26T12:25:25Z,Include rustdoc in the compiler docs index.,ehuss,1f5beec3b111560be181283009ef96da6ac5e7a7,1,Auto merge of #80316 - ehuss:rustdoc-index r=Mark-Simulacrum Include rustdoc in the compiler docs index. This should help ensure that the index page at https://doc.rust-lang.org/nightly/nightly-rustc/ includes a link to the rustdoc docs as well. Fixes #80307,HEART,2020-12-27T00:23:20Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/80319,MERGED,2020-12-23T01:31:55Z,2020-12-25T08:17:04Z,Fix elided lifetimes shown as `'_` on async functions,jyn514,d837407339d1eedd3320fa9c25962c3f20b15811,2,Rollup merge of #80319 - jyn514:async-lifetimes r=tmandry Fix elided lifetimes shown as `'_` on async functions Closes https://github.com/rust-lang/rust/issues/63037. r? `@tmandry` on the implementation `@Darksonn` on the test cases.,ROCKET,2020-12-24T03:42:38Z,tmandry,NA https://github.com/rust-lang/rust/pull/80331,MERGED,2020-12-23T15:25:49Z,2020-12-28T18:50:18Z,Add more comments to trait queries,jyn514,3f8c979c4ba5ad7f749bbd883ad6f97747e2c07e,1,Rollup merge of #80331 - jyn514:docs r=varkor Add more comments to trait queries This also adds back a comment that was mistakenly removed in ac9dfc3e7785c9bba96ebac4fd51726189e1bf91.,HEART,2020-12-24T04:46:23Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/80347,CLOSED,2020-12-24T10:31:28Z,2021-08-29T13:44:04Z,Generate metadata by iterating on DefId instead of traversing the HIR tree,cjgillot,NA,NA,NA,EYES,2020-12-24T21:09:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/80347,CLOSED,2020-12-24T10:31:28Z,2021-08-29T13:44:04Z,Generate metadata by iterating on DefId instead of traversing the HIR tree,cjgillot,NA,NA,NA,EYES,2020-12-24T23:56:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-04-28T03:50:29Z,F001,changchun.fan@qq.com https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-05-01T20:07:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-05-13T14:28:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-05-21T06:24:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-07-31T13:36:21Z,HKalbasi,NA https://github.com/rust-lang/rust/pull/80357,MERGED,2020-12-24T20:19:17Z,2021-08-16T03:12:48Z,Introduce `hir::ExprKind::Let` - Take 2,c410-f3r,2a6fb9a4c0e5ca7a81999065943b211c226fe9d8,129,Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper Introduce `hir::ExprKind::Let` - Take 2 Builds on #68577 and depends on #79328. cc #53667,THUMBS_UP,2021-08-16T10:32:17Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/80362,MERGED,2020-12-25T01:26:26Z,2020-12-28T18:50:17Z,Document rustc_macros on nightly-rustc,jyn514,18be436550b7e6df8ce079a5294c2b9adaf885af,1,Rollup merge of #80362 - jyn514:rustc-macros r=ehuss Document rustc_macros on nightly-rustc Fixes https://github.com/rust-lang/rust/issues/80345. ![image](https://user-images.githubusercontent.com/23638587/103113442-b7ba2d00-4628-11eb-8a4d-c542f2d170e1.png) ![image](https://user-images.githubusercontent.com/23638587/103113448-bc7ee100-4628-11eb-8657-2d72e88de656.png) r? ``@ehuss``,HEART,2020-12-25T18:32:12Z,camelid,NA https://github.com/rust-lang/rust/pull/80367,MERGED,2020-12-25T18:54:45Z,2021-07-27T22:42:18Z,Combine two loops in `check_match`,camelid,2faabf579323f5252329264cc53ba9ff803429a3,1,Auto merge of #80367 - camelid:check_match-combine-loop r=Nadrieril Combine two loops in `check_match` Suggested by Nadrieril in https://github.com/rust-lang/rust/pull/79051#discussion_r548778186. Opening to get a perf run. Hopefully this code doesn't require everything in the first loop to be done before running the second! (It shouldn't though.) cc `@Nadrieril`,THUMBS_UP,2020-12-25T20:28:01Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/80372,MERGED,2020-12-26T00:07:51Z,2021-01-08T05:58:54Z,Don't panic when an external crate can't be resolved,jyn514,901b9a2d7b936d3b217236df5ff1f57ef2deb6df,3,Rollup merge of #80372 - jyn514:fix-panics r=Manishearth Don't panic when an external crate can't be resolved This isn't actually a bug it can occur when rustdoc tries to resolve a crate that isn't used in the main code. Fixes #72381. r? `@kinnison` if you have time otherwise `@Manishearth`,THUMBS_UP,2020-12-26T12:56:02Z,chayleaf,chayleaf-git@pavluk.org https://github.com/rust-lang/rust/pull/80372,MERGED,2020-12-26T00:07:51Z,2021-01-08T05:58:54Z,Don't panic when an external crate can't be resolved,jyn514,901b9a2d7b936d3b217236df5ff1f57ef2deb6df,3,Rollup merge of #80372 - jyn514:fix-panics r=Manishearth Don't panic when an external crate can't be resolved This isn't actually a bug it can occur when rustdoc tries to resolve a crate that isn't used in the main code. Fixes #72381. r? `@kinnison` if you have time otherwise `@Manishearth`,THUMBS_UP,2020-12-30T13:52:56Z,inodentry,NA https://github.com/rust-lang/rust/pull/80373,CLOSED,2020-12-26T00:13:19Z,2020-12-27T17:37:08Z,Add a static analysis that prevents references to inner mutability only in the trailing expression of a constant,oli-obk,NA,NA,NA,THUMBS_UP,2021-08-21T04:51:55Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/80393,MERGED,2020-12-26T21:43:58Z,2020-12-29T03:01:43Z,Add links to the source for the rustc and rustdoc books.,ehuss,bae6475443ff7ebc54e438cfa827ce7107a8b2c1,2,Rollup merge of #80393 - ehuss:doc-git-link r=jyn514 Add links to the source for the rustc and rustdoc books. This adds a little icon in the upper-right corner of the books so that readers can find the source if they want to make changes or file issues. This is already included in several of the other books.,HEART,2020-12-26T23:01:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80402,MERGED,2020-12-27T01:58:55Z,2020-12-29T03:01:43Z,Document `InferTy` & co.,camelid,803b37597edf4d4dee88124c24aca54cc9b7a475,1,Rollup merge of #80402 - camelid:inferty-docs r=matthewjasper Document `InferTy` & co. I finally figured out what `TyVid` means! The name is quite opaque so I decided to document it and related types. I don't know that much about `InferTy` & co. but I was able to *infer* ( :) ) from the names and what I know generally about type inference to add some basic documentation.,HEART,2020-12-27T21:28:17Z,pierwill,NA https://github.com/rust-lang/rust/pull/80402,MERGED,2020-12-27T01:58:55Z,2020-12-29T03:01:43Z,Document `InferTy` & co.,camelid,803b37597edf4d4dee88124c24aca54cc9b7a475,1,Rollup merge of #80402 - camelid:inferty-docs r=matthewjasper Document `InferTy` & co. I finally figured out what `TyVid` means! The name is quite opaque so I decided to document it and related types. I don't know that much about `InferTy` & co. but I was able to *infer* ( :) ) from the names and what I know generally about type inference to add some basic documentation.,HEART,2020-12-29T11:15:47Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/80404,MERGED,2020-12-27T02:35:24Z,2021-02-01T02:42:21Z,Remove const_in_array_repeat,JulianKnodt,99f2f5a830df02c0c26ec046dbf979daa190b2f2,27,Rollup merge of #80404 - JulianKnodt:arr_ref r=oli-obk Remove const_in_array_repeat Fixes #80371. Fixes #81315. Fixes #80767. Fixes #75682. I thought there might be some issue with `Repeats(_ 0)` but if you increase the items in the array it still ICEs. I'm not sure if this is the best fix but it does fix the given issue.,THUMBS_UP,2021-02-01T02:52:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/80404,MERGED,2020-12-27T02:35:24Z,2021-02-01T02:42:21Z,Remove const_in_array_repeat,JulianKnodt,99f2f5a830df02c0c26ec046dbf979daa190b2f2,27,Rollup merge of #80404 - JulianKnodt:arr_ref r=oli-obk Remove const_in_array_repeat Fixes #80371. Fixes #81315. Fixes #80767. Fixes #75682. I thought there might be some issue with `Repeats(_ 0)` but if you increase the items in the array it still ICEs. I'm not sure if this is the best fix but it does fix the given issue.,THUMBS_UP,2021-02-02T05:50:13Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/80405,CLOSED,2020-12-27T07:10:36Z,2021-01-18T11:03:36Z,fix calling method on generic const fn in impl block,vn-ki,NA,NA,NA,THUMBS_UP,2020-12-27T07:10:59Z,nesscx,NA https://github.com/rust-lang/rust/pull/80405,CLOSED,2020-12-27T07:10:36Z,2021-01-18T11:03:36Z,fix calling method on generic const fn in impl block,vn-ki,NA,NA,NA,HOORAY,2020-12-27T12:46:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/80405,CLOSED,2020-12-27T07:10:36Z,2021-01-18T11:03:36Z,fix calling method on generic const fn in impl block,vn-ki,NA,NA,NA,HOORAY,2020-12-27T20:49:04Z,usbalbin,NA https://github.com/rust-lang/rust/pull/80407,CLOSED,2020-12-27T09:08:17Z,2021-01-06T22:31:47Z,Weak refcounted pointers can dangle,CAD97,NA,NA,NA,THUMBS_UP,2020-12-27T22:55:45Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HOORAY,2020-12-27T09:55:53Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HEART,2020-12-27T09:55:56Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HOORAY,2021-01-08T07:27:08Z,edwin0cheng,NA https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HEART,2021-01-08T09:06:16Z,tux3,NA https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HEART,2021-01-08T18:33:24Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80408,MERGED,2020-12-27T09:38:53Z,2020-12-28T18:50:17Z,Sync rustc_codegen_cranelift,bjorn3,55b52ee33908f0ede42c549417093750530f9b1e,28,Rollup merge of #80408 - bjorn3:sync_cg_clif-2020-12-27 r=bjorn3 Sync rustc_codegen_cranelift The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120 In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler,HOORAY,2021-01-08T18:33:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80412,MERGED,2020-12-27T15:30:19Z,2021-01-02T21:02:11Z,Fix search section position on small devices,GuillaumeGomez,fde692739576089729885b7f79aa2232cb9778c5,1,"Auto merge of #80412 - GuillaumeGomez:fix-search-section-pos r=jyn514 Fix search section position on small devices Fixes #79526. This is exactly the same issue fixed in 9c36491538476dd3ff5ec834944aacdaceb12f30 (in https://github.com/rust-lang/rust/pull/79936) but applied to the search section. When the width becomes too small the search input goes on its own line to get more space making it go ""under"" the section following (so either ""main"" or ""search""). The fix is to simply make the section go more under so that it doesn't go over the search input. r? `@jyn514`",HEART,2020-12-27T23:48:07Z,camelid,NA https://github.com/rust-lang/rust/pull/80412,MERGED,2020-12-27T15:30:19Z,2021-01-02T21:02:11Z,Fix search section position on small devices,GuillaumeGomez,fde692739576089729885b7f79aa2232cb9778c5,1,"Auto merge of #80412 - GuillaumeGomez:fix-search-section-pos r=jyn514 Fix search section position on small devices Fixes #79526. This is exactly the same issue fixed in 9c36491538476dd3ff5ec834944aacdaceb12f30 (in https://github.com/rust-lang/rust/pull/79936) but applied to the search section. When the width becomes too small the search input goes on its own line to get more space making it go ""under"" the section following (so either ""main"" or ""search""). The fix is to simply make the section go more under so that it doesn't go over the search input. r? `@jyn514`",HEART,2021-01-03T05:39:17Z,tesuji,NA https://github.com/rust-lang/rust/pull/80412,MERGED,2020-12-27T15:30:19Z,2021-01-02T21:02:11Z,Fix search section position on small devices,GuillaumeGomez,fde692739576089729885b7f79aa2232cb9778c5,1,"Auto merge of #80412 - GuillaumeGomez:fix-search-section-pos r=jyn514 Fix search section position on small devices Fixes #79526. This is exactly the same issue fixed in 9c36491538476dd3ff5ec834944aacdaceb12f30 (in https://github.com/rust-lang/rust/pull/79936) but applied to the search section. When the width becomes too small the search input goes on its own line to get more space making it go ""under"" the section following (so either ""main"" or ""search""). The fix is to simply make the section go more under so that it doesn't go over the search input. r? `@jyn514`",HEART,2021-01-21T23:20:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/80415,MERGED,2020-12-27T17:12:27Z,2021-01-06T03:47:50Z,Compute parent module when collecting hir::MacroDef.,cjgillot,41601ef39442bca19bc6ac8ef72e5d89335e92d7,3,Auto merge of #80415 - cjgillot:issue-77828 r=petrochenkov Compute parent module when collecting hir::MacroDef. Fixes #77828. r? `@jyn514`,HEART,2020-12-27T17:19:52Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80415,MERGED,2020-12-27T17:12:27Z,2021-01-06T03:47:50Z,Compute parent module when collecting hir::MacroDef.,cjgillot,41601ef39442bca19bc6ac8ef72e5d89335e92d7,3,Auto merge of #80415 - cjgillot:issue-77828 r=petrochenkov Compute parent module when collecting hir::MacroDef. Fixes #77828. r? `@jyn514`,ROCKET,2020-12-27T17:20:23Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/80415,MERGED,2020-12-27T17:12:27Z,2021-01-06T03:47:50Z,Compute parent module when collecting hir::MacroDef.,cjgillot,41601ef39442bca19bc6ac8ef72e5d89335e92d7,3,Auto merge of #80415 - cjgillot:issue-77828 r=petrochenkov Compute parent module when collecting hir::MacroDef. Fixes #77828. r? `@jyn514`,HOORAY,2020-12-27T17:20:26Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/80415,MERGED,2020-12-27T17:12:27Z,2021-01-06T03:47:50Z,Compute parent module when collecting hir::MacroDef.,cjgillot,41601ef39442bca19bc6ac8ef72e5d89335e92d7,3,Auto merge of #80415 - cjgillot:issue-77828 r=petrochenkov Compute parent module when collecting hir::MacroDef. Fixes #77828. r? `@jyn514`,HEART,2021-01-06T10:43:28Z,RalfJung,NA https://github.com/rust-lang/rust/pull/80422,MERGED,2020-12-27T23:49:16Z,2020-12-28T02:50:02Z,de-stabilize unsized raw ptr methods for Weak,RalfJung,6c523a7a0ef121fe97ad6a367a3f3b92f80dc3f0,4,Auto merge of #80422 - RalfJung:weak-no-unsized-raw r=Mark-Simulacrum de-stabilize unsized raw ptr methods for Weak `@Mark-Simulacrum` this is the patch re: https://github.com/rust-lang/rust/pull/80407. I couldn't figure out the branch it needs to go on though stable is still the old stable but beta already the new beta...?,THUMBS_UP,2020-12-27T23:50:24Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/80432,CLOSED,2020-12-28T08:54:46Z,2021-04-21T21:30:12Z,Add some doc aliases to Vec,xfix,NA,NA,NA,THUMBS_UP,2021-01-01T14:38:23Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80435,MERGED,2020-12-28T12:34:32Z,2020-12-31T03:17:49Z,Only produce .xz tarballs on CI,pietroalbini,f0073a59cffebcf4f31e2bfa690a18f4f1dfd608,7,Auto merge of #80435 - pietroalbini:compression-formats r=Mark-Simulacrum Only produce .xz tarballs on CI This PR adds a `./configure` option to choose which tarball compression formats to produce and changes our CI configuration to only produce `.xz` tarballs. The release process will then recompress everything into `.gz` when producing a release. This will drastically reduce our storage costs for CI artifacts as we'd stop storing the same data twice. **Stable beta and nightly releases will not be affected by this at all.** Before landing this we'll need to increase the VM size of our release process to recompress everything in a reasonable amount of time. r? `@Mark-Simulacrum`,HEART,2020-12-28T18:10:39Z,est31,NA https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,LAUGH,2020-12-28T13:43:57Z,nintha,ninthakeey@hotmail.com https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,LAUGH,2020-12-28T13:52:02Z,TOETOE55,NA https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,LAUGH,2020-12-28T14:59:10Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,THUMBS_UP,2020-12-28T20:37:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,THUMBS_UP,2021-02-19T03:13:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/80438,MERGED,2020-12-28T12:50:17Z,2021-02-10T06:21:55Z,Add `Box::into_inner`.,crlf0710,a28f2afbeb341a5d59730091af4d59e953f9e767,1,Rollup merge of #80438 - crlf0710:box_into_inner r=m-ou-se Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future. r? `@m-ou-se`,HOORAY,2021-02-21T22:39:36Z,faern,NA https://github.com/rust-lang/rust/pull/80442,MERGED,2020-12-28T16:08:14Z,2021-01-05T05:55:04Z,Mention Arc::make_mut and Rc::make_mut in the documentation of Cow,steffahn,bdf8bbde1db65b2800b4c688c16ae6d029b3ffc8,1,Rollup merge of #80442 - steffahn:mention_arc_in_cow r=Mark-Simulacrum Mention Arc::make_mut and Rc::make_mut in the documentation of Cow Following this discussion: https://users.rust-lang.org/t/should-the-cow-documentation-mention-arc/53341 _Rendered (the last paragraph is new):_ ![Screenshot_20201228_171551](https://user-images.githubusercontent.com/3986214/103228135-5d72e200-4930-11eb-89e1-38b5c86b08c7.png) `@rustbot` modify labels: T-doc T-libs,THUMBS_UP,2020-12-29T17:55:28Z,vi,vi0oss@gmail.com https://github.com/rust-lang/rust/pull/80442,MERGED,2020-12-28T16:08:14Z,2021-01-05T05:55:04Z,Mention Arc::make_mut and Rc::make_mut in the documentation of Cow,steffahn,bdf8bbde1db65b2800b4c688c16ae6d029b3ffc8,1,Rollup merge of #80442 - steffahn:mention_arc_in_cow r=Mark-Simulacrum Mention Arc::make_mut and Rc::make_mut in the documentation of Cow Following this discussion: https://users.rust-lang.org/t/should-the-cow-documentation-mention-arc/53341 _Rendered (the last paragraph is new):_ ![Screenshot_20201228_171551](https://user-images.githubusercontent.com/3986214/103228135-5d72e200-4930-11eb-89e1-38b5c86b08c7.png) `@rustbot` modify labels: T-doc T-libs,THUMBS_UP,2021-01-04T09:42:14Z,ChrisJefferson,NA https://github.com/rust-lang/rust/pull/80452,CLOSED,2020-12-28T19:35:44Z,2021-02-20T21:54:58Z,Refactorings in preparation for #70951,cjgillot,NA,NA,NA,HOORAY,2020-12-29T06:10:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80453,MERGED,2020-12-28T19:58:23Z,2020-12-30T02:14:51Z,Remove `compile-fail` test suite,petrochenkov,f3eead1c69d5ce9cb128a9068250581ad28103f0,116,Auto merge of #80453 - petrochenkov:nocfail r=Mark-Simulacrum Remove `compile-fail` test suite By moving all of its tests to `ui` test suite. Now we have directives like `// dont-check-compiler-stderr` that allow to disable `.stderr` comparison for platform-dependent tests without introducing a whole new test suite.,EYES,2020-12-28T20:27:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80453,MERGED,2020-12-28T19:58:23Z,2020-12-30T02:14:51Z,Remove `compile-fail` test suite,petrochenkov,f3eead1c69d5ce9cb128a9068250581ad28103f0,116,Auto merge of #80453 - petrochenkov:nocfail r=Mark-Simulacrum Remove `compile-fail` test suite By moving all of its tests to `ui` test suite. Now we have directives like `// dont-check-compiler-stderr` that allow to disable `.stderr` comparison for platform-dependent tests without introducing a whole new test suite.,HOORAY,2020-12-28T20:42:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/80453,MERGED,2020-12-28T19:58:23Z,2020-12-30T02:14:51Z,Remove `compile-fail` test suite,petrochenkov,f3eead1c69d5ce9cb128a9068250581ad28103f0,116,Auto merge of #80453 - petrochenkov:nocfail r=Mark-Simulacrum Remove `compile-fail` test suite By moving all of its tests to `ui` test suite. Now we have directives like `// dont-check-compiler-stderr` that allow to disable `.stderr` comparison for platform-dependent tests without introducing a whole new test suite.,HOORAY,2020-12-29T06:09:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80453,MERGED,2020-12-28T19:58:23Z,2020-12-30T02:14:51Z,Remove `compile-fail` test suite,petrochenkov,f3eead1c69d5ce9cb128a9068250581ad28103f0,116,Auto merge of #80453 - petrochenkov:nocfail r=Mark-Simulacrum Remove `compile-fail` test suite By moving all of its tests to `ui` test suite. Now we have directives like `// dont-check-compiler-stderr` that allow to disable `.stderr` comparison for platform-dependent tests without introducing a whole new test suite.,HOORAY,2021-11-08T20:38:37Z,estebank,NA https://github.com/rust-lang/rust/pull/80463,MERGED,2020-12-29T02:41:26Z,2021-01-12T08:38:56Z,Serialize incr comp structures to file via fixed-size buffer,tgnottingham,8234db5bc7b122dd9e39d738c30bcae005a96568,11,Auto merge of #80463 - tgnottingham:incr_comp_serial_mem_usage r=oli-obk Serialize incr comp structures to file via fixed-size buffer Reduce a large memory spike that happens during serialization by writing the incr comp structures to file by way of a fixed-size buffer rather than an unbounded vector. Effort was made to keep the instruction count close to that of the previous implementation. However buffered writing to a file inherently has more overhead than writing to a vector because each write may result in a handleable error. To reduce this overhead arrangements are made so that each LEB128-encoded integer can be written to the buffer with only one capacity and error check. Higher-level optimizations in which entire composite structures can be written with one capacity and error check are possible but would require much more work. The performance is mostly on par with the previous implementation with small to moderate instruction count regressions. The memory reduction is significant however so it seems like a worth-while trade-off.,HEART,2020-12-29T05:56:05Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80463,MERGED,2020-12-29T02:41:26Z,2021-01-12T08:38:56Z,Serialize incr comp structures to file via fixed-size buffer,tgnottingham,8234db5bc7b122dd9e39d738c30bcae005a96568,11,Auto merge of #80463 - tgnottingham:incr_comp_serial_mem_usage r=oli-obk Serialize incr comp structures to file via fixed-size buffer Reduce a large memory spike that happens during serialization by writing the incr comp structures to file by way of a fixed-size buffer rather than an unbounded vector. Effort was made to keep the instruction count close to that of the previous implementation. However buffered writing to a file inherently has more overhead than writing to a vector because each write may result in a handleable error. To reduce this overhead arrangements are made so that each LEB128-encoded integer can be written to the buffer with only one capacity and error check. Higher-level optimizations in which entire composite structures can be written with one capacity and error check are possible but would require much more work. The performance is mostly on par with the previous implementation with small to moderate instruction count regressions. The memory reduction is significant however so it seems like a worth-while trade-off.,HEART,2020-12-29T06:07:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80463,MERGED,2020-12-29T02:41:26Z,2021-01-12T08:38:56Z,Serialize incr comp structures to file via fixed-size buffer,tgnottingham,8234db5bc7b122dd9e39d738c30bcae005a96568,11,Auto merge of #80463 - tgnottingham:incr_comp_serial_mem_usage r=oli-obk Serialize incr comp structures to file via fixed-size buffer Reduce a large memory spike that happens during serialization by writing the incr comp structures to file by way of a fixed-size buffer rather than an unbounded vector. Effort was made to keep the instruction count close to that of the previous implementation. However buffered writing to a file inherently has more overhead than writing to a vector because each write may result in a handleable error. To reduce this overhead arrangements are made so that each LEB128-encoded integer can be written to the buffer with only one capacity and error check. Higher-level optimizations in which entire composite structures can be written with one capacity and error check are possible but would require much more work. The performance is mostly on par with the previous implementation with small to moderate instruction count regressions. The memory reduction is significant however so it seems like a worth-while trade-off.,HEART,2020-12-29T18:03:19Z,cjgillot,NA https://github.com/rust-lang/rust/pull/80463,MERGED,2020-12-29T02:41:26Z,2021-01-12T08:38:56Z,Serialize incr comp structures to file via fixed-size buffer,tgnottingham,8234db5bc7b122dd9e39d738c30bcae005a96568,11,Auto merge of #80463 - tgnottingham:incr_comp_serial_mem_usage r=oli-obk Serialize incr comp structures to file via fixed-size buffer Reduce a large memory spike that happens during serialization by writing the incr comp structures to file by way of a fixed-size buffer rather than an unbounded vector. Effort was made to keep the instruction count close to that of the previous implementation. However buffered writing to a file inherently has more overhead than writing to a vector because each write may result in a handleable error. To reduce this overhead arrangements are made so that each LEB128-encoded integer can be written to the buffer with only one capacity and error check. Higher-level optimizations in which entire composite structures can be written with one capacity and error check are possible but would require much more work. The performance is mostly on par with the previous implementation with small to moderate instruction count regressions. The memory reduction is significant however so it seems like a worth-while trade-off.,HEART,2021-01-08T23:09:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2020-12-29T12:18:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2020-12-29T14:01:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2020-12-29T14:20:06Z,SkiFire13,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2020-12-30T12:04:43Z,tesuji,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2020-12-30T21:29:25Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2020-12-30T21:29:26Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2020-12-31T21:39:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-21T03:59:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-01-21T03:59:10Z,taiki-e,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-22T10:39:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-01-22T10:39:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-01-22T16:38:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-22T17:53:53Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-01-22T19:13:05Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-22T19:13:05Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-23T20:57:22Z,tux3,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-01-28T09:13:48Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-28T09:13:49Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-01-31T14:53:18Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-01T23:46:13Z,bluss,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-03T16:15:27Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-04T09:46:36Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-04T12:11:23Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-02-04T12:11:24Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,THUMBS_UP,2021-02-04T14:00:31Z,SomeoneToIgnore,mail4score@gmail.com https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-04T14:53:08Z,kvark,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-04T19:07:52Z,eskimor,NA https://github.com/rust-lang/rust/pull/80470,MERGED,2020-12-29T08:28:34Z,2021-01-31T05:58:24Z,Stabilize by-value `[T; N]` iterator `core::array::IntoIter`,SimonSapin,1e99f26894a766f5861ae2805c13e915e74493f0,11,Rollup merge of #80470 - SimonSapin:array-intoiter-type r=m-ou-se Stabilize by-value `[T; N]` iterator `core::array::IntoIter` Tracking issue: https://github.com/rust-lang/rust/issues/65798 This is unblocked now that `min_const_generics` has been stabilized in https://github.com/rust-lang/rust/pull/79135. This PR does *not* include the corresponding `IntoIterator` impl which is https://github.com/rust-lang/rust/pull/65819. Instead an iterator can be constructed through the `new` method. `new` would become unnecessary when `IntoIterator` is implemented and might be deprecated then although it will stay stable.,HOORAY,2021-02-12T10:28:48Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/80492,MERGED,2020-12-29T22:36:17Z,2020-12-30T18:24:27Z,remove empty wraps don't return Results from from infallible functions,matthiaskrgr,07083739fb2b971fa174d5443ab3e675d363fa1a,12,Rollup merge of #80492 - matthiaskrgr:tasty_wraps r=varkor remove empty wraps don't return Results from from infallible functions This makes code easier to understand because it is more obvious when a function actually can't fail (return Err or None) Make functions that only ever return Some(x) return x directly Remove return type from functions that return Option<() Err> but would only ever return Ok(()). Found with `clippy::unnecessary_wraps`,HEART,2020-12-30T01:17:28Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80495,MERGED,2020-12-30T01:29:16Z,2020-12-31T00:23:15Z,Rename kw::Invalid -> kw::Empty,jyn514,9e8edc8c22adb1d89e73cd876e08baaab5121572,27,Rollup merge of #80495 - jyn514:rename-empty r=petrochenkov Rename kw::Invalid -> kw::Empty See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471 for context. r? `@petrochenkov`,THUMBS_UP,2020-12-31T04:58:42Z,pierwill,NA https://github.com/rust-lang/rust/pull/80497,CLOSED,2020-12-30T01:55:17Z,2021-01-15T19:02:05Z,Add 'integer' as integer data types doc alias,pickfire,NA,NA,NA,THUMBS_UP,2020-12-30T03:03:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80514,MERGED,2020-12-30T15:21:59Z,2021-01-01T03:41:36Z,Fix broken ./x.py install,pietroalbini,5bffc265b0da4fda4f80f2f81697beef0289ef6c,4,Rollup merge of #80514 - pietroalbini:fix-install r=Mark-Simulacrum Fix broken ./x.py install During my tarball refactorings in https://github.com/rust-lang/rust/pull/79788 I changed the directory layout used by the tarball generation code and that broke the other parts of rustbuild which hardcoded the paths of those directories. Namely `./x.py install` relied on the uncompressed copy of the tarball left behind by `fabricate`/`rust-installer` causing https://github.com/rust-lang/rust/issues/80494. While the easy fix for https://github.com/rust-lang/rust/issues/80494 would've been to just update the hardcoded paths to match the new structure that fix would leave us in the same situation if we were to change the directory layout again in the future. Instead I refactored the code to return a `GeneratedTarball` struct as the output of all the dist steps and I put all the paths the rest of rustbuild needs to care about in its fields. That way future changes to `src/bootstrap/tarball.rs` will not break other stuff. This PR is best reviewed commit-by-commit. r? `@Mark-Simulacrum` `@rustbot` modify labels: beta-nominated beta-accepted T-release,HEART,2020-12-30T18:47:40Z,tmandry,NA https://github.com/rust-lang/rust/pull/80515,MERGED,2020-12-30T15:39:02Z,2021-01-16T03:10:53Z,Improve JS performance by storing length before comparing to it in loops,GuillaumeGomez,033faf9499d4241e40152515e6ad85ba184062a1,2,Rollup merge of #80515 - GuillaumeGomez:js-for-loop-perf r=Nemo157 jyn514 Improve JS performance by storing length before comparing to it in loops Since https://github.com/rust-lang/rust/pull/79052 is quite complicated to review I suggested to split into smaller parts. This first part is mostly about saving the array length into a variable (I tried to not change anything else as much as possible :smiley: ). r? `@jyn514`,HEART,2020-12-30T16:04:56Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80519,MERGED,2020-12-30T16:47:14Z,2021-01-01T03:41:36Z,Take type defaults into account in suggestions to reorder generic parameters,max-heller,1f431f906612478807997d18660d1c4b9c76b335,9,Rollup merge of #80519 - max-heller:issue-80512-fix r=varkor Take type defaults into account in suggestions to reorder generic parameters Fixes #80512,HEART,2020-12-30T17:57:59Z,varkor,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2020-12-30T18:32:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2020-12-31T00:28:48Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-01-01T22:33:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-02-12T21:02:03Z,tmiasko,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-05-13T14:13:10Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-05-31T19:38:58Z,bjorn3,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-05-31T21:42:44Z,usbalbin,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-06-02T12:36:15Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-08-15T00:46:17Z,kw-fn,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-08-23T10:20:56Z,tema3210,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-08-31T20:59:48Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-09-01T20:21:40Z,camelid,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-09-01T20:35:22Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-09-09T04:16:45Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/80522,MERGED,2020-12-30T18:18:48Z,2021-09-08T23:52:38Z,Split rustc_mir,cjgillot,97032a6dfacdd3548e4bff98c90a6b3875a14077,200,Auto merge of #80522 - cjgillot:borrowcrate r=oli-obk Split rustc_mir The `rustc_mir` crate is the second largest in the compiler. This PR splits it up into 5 crates: - rustc_borrowck; - rustc_const_eval; - rustc_mir_dataflow; - rustc_mir_transform; - rustc_monomorphize.,HEART,2021-09-17T06:01:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80525,MERGED,2020-12-30T19:05:54Z,2021-04-05T03:55:12Z,wasm64 support,devsnek,0d12422f2d82e4ec47d4b85660caed70b78ea44c,19,Rollup merge of #80525 - devsnek:wasm64 r=nagisa wasm64 support There is still some upstream llvm work needed before this can land.,EYES,2020-12-30T19:21:55Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80527,MERGED,2020-12-30T19:26:44Z,2021-03-04T14:00:50Z,Make rustdoc lints a tool lint instead of built-in,jyn514,f898aa3f5b4b7b85b71c4bb5447d0b7cef6deeaf,86,Rollup merge of #80527 - jyn514:rustdoc-lints r=GuillaumeGomez Make rustdoc lints a tool lint instead of built-in - Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently though). - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests - Move lint machinery into a separate file - Add `declare_rustdoc_lint!` macro Unblocks https://github.com/rust-lang/rust/pull/80300 https://github.com/rust-lang/rust/pull/79816 https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786. ## Current status This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519),HOORAY,2020-12-30T19:28:27Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/80527,MERGED,2020-12-30T19:26:44Z,2021-03-04T14:00:50Z,Make rustdoc lints a tool lint instead of built-in,jyn514,f898aa3f5b4b7b85b71c4bb5447d0b7cef6deeaf,86,Rollup merge of #80527 - jyn514:rustdoc-lints r=GuillaumeGomez Make rustdoc lints a tool lint instead of built-in - Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently though). - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests - Move lint machinery into a separate file - Add `declare_rustdoc_lint!` macro Unblocks https://github.com/rust-lang/rust/pull/80300 https://github.com/rust-lang/rust/pull/79816 https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786. ## Current status This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519),THUMBS_UP,2020-12-30T19:40:18Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/80527,MERGED,2020-12-30T19:26:44Z,2021-03-04T14:00:50Z,Make rustdoc lints a tool lint instead of built-in,jyn514,f898aa3f5b4b7b85b71c4bb5447d0b7cef6deeaf,86,Rollup merge of #80527 - jyn514:rustdoc-lints r=GuillaumeGomez Make rustdoc lints a tool lint instead of built-in - Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently though). - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests - Move lint machinery into a separate file - Add `declare_rustdoc_lint!` macro Unblocks https://github.com/rust-lang/rust/pull/80300 https://github.com/rust-lang/rust/pull/79816 https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786. ## Current status This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519),HOORAY,2021-01-05T14:46:59Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/80527,MERGED,2020-12-30T19:26:44Z,2021-03-04T14:00:50Z,Make rustdoc lints a tool lint instead of built-in,jyn514,f898aa3f5b4b7b85b71c4bb5447d0b7cef6deeaf,86,Rollup merge of #80527 - jyn514:rustdoc-lints r=GuillaumeGomez Make rustdoc lints a tool lint instead of built-in - Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently though). - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests - Move lint machinery into a separate file - Add `declare_rustdoc_lint!` macro Unblocks https://github.com/rust-lang/rust/pull/80300 https://github.com/rust-lang/rust/pull/79816 https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786. ## Current status This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519),HOORAY,2021-02-25T11:33:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80527,MERGED,2020-12-30T19:26:44Z,2021-03-04T14:00:50Z,Make rustdoc lints a tool lint instead of built-in,jyn514,f898aa3f5b4b7b85b71c4bb5447d0b7cef6deeaf,86,Rollup merge of #80527 - jyn514:rustdoc-lints r=GuillaumeGomez Make rustdoc lints a tool lint instead of built-in - Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently though). - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests - Move lint machinery into a separate file - Add `declare_rustdoc_lint!` macro Unblocks https://github.com/rust-lang/rust/pull/80300 https://github.com/rust-lang/rust/pull/79816 https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786. ## Current status This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519),THUMBS_UP,2021-03-04T06:58:37Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/80534,MERGED,2020-12-30T22:34:46Z,2021-02-25T18:14:56Z,Use #[doc = include_str!()] in std,LeSeulArtichaut,cb2b4ff7142935ebaaec2fe2782d0f53af87be6d,4,Rollup merge of #80534 - LeSeulArtichaut:doc-include r=jyn514 Use #[doc = include_str!()] in std cc https://github.com/rust-lang/rust/issues/78835#issuecomment-742531894 r? `````@jyn514`````,HEART,2020-12-30T22:41:00Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80534,MERGED,2020-12-30T22:34:46Z,2021-02-25T18:14:56Z,Use #[doc = include_str!()] in std,LeSeulArtichaut,cb2b4ff7142935ebaaec2fe2782d0f53af87be6d,4,Rollup merge of #80534 - LeSeulArtichaut:doc-include r=jyn514 Use #[doc = include_str!()] in std cc https://github.com/rust-lang/rust/issues/78835#issuecomment-742531894 r? `````@jyn514`````,HEART,2021-01-11T04:27:53Z,trevyn,NA https://github.com/rust-lang/rust/pull/80535,MERGED,2020-12-30T22:42:02Z,2021-01-08T12:34:34Z,Add a note for `*` and `{}` usage on `use`,JohnTitor,3d8608a8638fabc46e83acc0626d4cf2782f0702,5,Auto merge of #80535 - JohnTitor:improve-use-diag r=estebank Add a note for `*` and `{}` usage on `use` Closes #80333,THUMBS_UP,2020-12-31T05:07:44Z,pymongo,os.popen@gmail.com https://github.com/rust-lang/rust/pull/80535,MERGED,2020-12-30T22:42:02Z,2021-01-08T12:34:34Z,Add a note for `*` and `{}` usage on `use`,JohnTitor,3d8608a8638fabc46e83acc0626d4cf2782f0702,5,Auto merge of #80535 - JohnTitor:improve-use-diag r=estebank Add a note for `*` and `{}` usage on `use` Closes #80333,THUMBS_UP,2021-01-08T01:01:44Z,estebank,NA https://github.com/rust-lang/rust/pull/80535,MERGED,2020-12-30T22:42:02Z,2021-01-08T12:34:34Z,Add a note for `*` and `{}` usage on `use`,JohnTitor,3d8608a8638fabc46e83acc0626d4cf2782f0702,5,Auto merge of #80535 - JohnTitor:improve-use-diag r=estebank Add a note for `*` and `{}` usage on `use` Closes #80333,THUMBS_UP,2021-01-09T17:26:54Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80537,MERGED,2020-12-30T23:18:34Z,2021-01-18T02:43:19Z,Don't use posix_spawn_file_actions_addchdir_np on macOS.,ehuss,c4df63f47f37cfb8fff80919be560e4d51ae9a44,2,"Auto merge of #80537 - ehuss:macos-posix-spawn-chdir r=dtolnay Don't use posix_spawn_file_actions_addchdir_np on macOS. There is a bug on macOS where using `posix_spawn_file_actions_addchdir_np` with a relative executable path will cause `posix_spawnp` to return ENOENT even though it successfully spawned the process in the given directory. `posix_spawn_file_actions_addchdir_np` was introduced in macOS 10.15 first released in Oct 2019. I have tested macOS 10.15.7 and 11.0.1. Example offending program: ```rust use std::fs; use std::os::unix::fs::PermissionsExt; use std::process::*; fn main() { fs::create_dir_all(""bar"").unwrap(); fs::create_dir_all(""foo"").unwrap(); fs::write(""foo/foo.sh"" ""#!/bin/sh\necho hello ${PWD}\n"").unwrap(); let perms = fs::Permissions::from_mode(0o755); fs::set_permissions(""foo/foo.sh"" perms).unwrap(); let c = Command::new(""../foo/foo.sh"").current_dir(""bar"").spawn(); eprintln!(""{:?}"" c); } ``` This prints: ``` Err(Os { code: 2 kind: NotFound message: ""No such file or directory"" }) hello /Users/eric/Temp/bar ``` I wanted to open this PR to get some feedback on possible solutions. Alternatives: * Do nothing. * Document the bug. * Try to detect if the executable is a relative path on macOS and avoid using `posix_spawn_file_actions_addchdir_np` only in that case. I looked at the [XNU source code](https://opensource.apple.com/source/xnu/xnu-6153.141.1/bsd/kern/kern_exec.c.auto.html) but I didn't see anything obvious that would explain the behavior. The actual chdir succeeds it is something else further down that fails but I couldn't see where. EDIT: I forgot to mention relative exe paths with `current_dir` in general are discouraged (see #37868). I don't know if #37868 is fixable since normalizing it would change the semantics for some platforms. Another option is to convert the executable to an absolute path with something like joining the cwd with the new cwd and the executable but I'm uncertain about that.",THUMBS_UP,2021-01-12T19:36:58Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/80543,MERGED,2020-12-31T01:26:18Z,2021-08-29T17:46:29Z,Notify when an `I-prioritize` issue is closed or reopened,LeSeulArtichaut,8eb50ce1f44d254399a2ff7d3b444a267838cd41,1,Rollup merge of #80543 - LeSeulArtichaut:notify-close r=spastorino Notify when an `I-prioritize` issue is closed or reopened Companion PR to rust-lang/triagebot#1078 blocked on that PR. r? ``@spastorino`` cc ``@rust-lang/wg-prioritization``,HEART,2020-12-31T01:27:52Z,camelid,NA https://github.com/rust-lang/rust/pull/80543,MERGED,2020-12-31T01:26:18Z,2021-08-29T17:46:29Z,Notify when an `I-prioritize` issue is closed or reopened,LeSeulArtichaut,8eb50ce1f44d254399a2ff7d3b444a267838cd41,1,Rollup merge of #80543 - LeSeulArtichaut:notify-close r=spastorino Notify when an `I-prioritize` issue is closed or reopened Companion PR to rust-lang/triagebot#1078 blocked on that PR. r? ``@spastorino`` cc ``@rust-lang/wg-prioritization``,THUMBS_UP,2020-12-31T01:35:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80551,MERGED,2020-12-31T09:57:43Z,2021-01-01T03:41:35Z,support pattern as const parents in type_of,lcnr,96c11f98d7148f5d49cb1600101c7f9ce057c08b,5,Rollup merge of #80551 - lcnr:const-arg-wildcard r=varkor support pattern as const parents in type_of nice to know that there's still stuff about rust i didn't know about :laughing: fixes #80531 r? `@varkor`,HEART,2020-12-31T12:56:38Z,varkor,NA https://github.com/rust-lang/rust/pull/80551,MERGED,2020-12-31T09:57:43Z,2021-01-01T03:41:35Z,support pattern as const parents in type_of,lcnr,96c11f98d7148f5d49cb1600101c7f9ce057c08b,5,Rollup merge of #80551 - lcnr:const-arg-wildcard r=varkor support pattern as const parents in type_of nice to know that there's still stuff about rust i didn't know about :laughing: fixes #80531 r? `@varkor`,HEART,2020-12-31T18:25:11Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/80551,MERGED,2020-12-31T09:57:43Z,2021-01-01T03:41:35Z,support pattern as const parents in type_of,lcnr,96c11f98d7148f5d49cb1600101c7f9ce057c08b,5,Rollup merge of #80551 - lcnr:const-arg-wildcard r=varkor support pattern as const parents in type_of nice to know that there's still stuff about rust i didn't know about :laughing: fixes #80531 r? `@varkor`,HEART,2021-01-01T01:20:14Z,camelid,NA https://github.com/rust-lang/rust/pull/80567,MERGED,2020-12-31T21:24:55Z,2021-01-14T23:07:37Z,Add Iterator::intersperse_with,lukaslueg,446ed771244812f9012ea78a48d6b932e34dad3a,5,Rollup merge of #80567 - lukaslueg:intersperse_with r=m-ou-se Add Iterator::intersperse_with This is a follow-up to #79479 tracking in #79524 as discussed https://github.com/rust-lang/rust/pull/79479#issuecomment-752671731. ~~Note that I had to manually implement `Clone` and `Debug` because `derive` insists on placing a `Clone`-bound on the struct-definition which is too narrow. There is a long-standing issue # for this somewhere around here :-)~~ Also note that I refactored the guts of `Intersperse` into private functions and re-used them in `IntersperseWith` so I also went light on duplicating all the tests. If this is suitable to be merged the tracking issue should be updated since it only mentions `intersperse`. Happy New Year! r? ``@m-ou-se``,THUMBS_UP,2021-01-11T12:33:44Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/80567,MERGED,2020-12-31T21:24:55Z,2021-01-14T23:07:37Z,Add Iterator::intersperse_with,lukaslueg,446ed771244812f9012ea78a48d6b932e34dad3a,5,Rollup merge of #80567 - lukaslueg:intersperse_with r=m-ou-se Add Iterator::intersperse_with This is a follow-up to #79479 tracking in #79524 as discussed https://github.com/rust-lang/rust/pull/79479#issuecomment-752671731. ~~Note that I had to manually implement `Clone` and `Debug` because `derive` insists on placing a `Clone`-bound on the struct-definition which is too narrow. There is a long-standing issue # for this somewhere around here :-)~~ Also note that I refactored the guts of `Intersperse` into private functions and re-used them in `IntersperseWith` so I also went light on duplicating all the tests. If this is suitable to be merged the tracking issue should be updated since it only mentions `intersperse`. Happy New Year! r? ``@m-ou-se``,HOORAY,2021-01-13T17:41:28Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/80567,MERGED,2020-12-31T21:24:55Z,2021-01-14T23:07:37Z,Add Iterator::intersperse_with,lukaslueg,446ed771244812f9012ea78a48d6b932e34dad3a,5,Rollup merge of #80567 - lukaslueg:intersperse_with r=m-ou-se Add Iterator::intersperse_with This is a follow-up to #79479 tracking in #79524 as discussed https://github.com/rust-lang/rust/pull/79479#issuecomment-752671731. ~~Note that I had to manually implement `Clone` and `Debug` because `derive` insists on placing a `Clone`-bound on the struct-definition which is too narrow. There is a long-standing issue # for this somewhere around here :-)~~ Also note that I refactored the guts of `Intersperse` into private functions and re-used them in `IntersperseWith` so I also went light on duplicating all the tests. If this is suitable to be merged the tracking issue should be updated since it only mentions `intersperse`. Happy New Year! r? ``@m-ou-se``,THUMBS_UP,2021-01-13T17:41:28Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/80567,MERGED,2020-12-31T21:24:55Z,2021-01-14T23:07:37Z,Add Iterator::intersperse_with,lukaslueg,446ed771244812f9012ea78a48d6b932e34dad3a,5,Rollup merge of #80567 - lukaslueg:intersperse_with r=m-ou-se Add Iterator::intersperse_with This is a follow-up to #79479 tracking in #79524 as discussed https://github.com/rust-lang/rust/pull/79479#issuecomment-752671731. ~~Note that I had to manually implement `Clone` and `Debug` because `derive` insists on placing a `Clone`-bound on the struct-definition which is too narrow. There is a long-standing issue # for this somewhere around here :-)~~ Also note that I refactored the guts of `Intersperse` into private functions and re-used them in `IntersperseWith` so I also went light on duplicating all the tests. If this is suitable to be merged the tracking issue should be updated since it only mentions `intersperse`. Happy New Year! r? ``@m-ou-se``,THUMBS_UP,2021-01-13T19:31:27Z,cynecx,NA https://github.com/rust-lang/rust/pull/80567,MERGED,2020-12-31T21:24:55Z,2021-01-14T23:07:37Z,Add Iterator::intersperse_with,lukaslueg,446ed771244812f9012ea78a48d6b932e34dad3a,5,Rollup merge of #80567 - lukaslueg:intersperse_with r=m-ou-se Add Iterator::intersperse_with This is a follow-up to #79479 tracking in #79524 as discussed https://github.com/rust-lang/rust/pull/79479#issuecomment-752671731. ~~Note that I had to manually implement `Clone` and `Debug` because `derive` insists on placing a `Clone`-bound on the struct-definition which is too narrow. There is a long-standing issue # for this somewhere around here :-)~~ Also note that I refactored the guts of `Intersperse` into private functions and re-used them in `IntersperseWith` so I also went light on duplicating all the tests. If this is suitable to be merged the tracking issue should be updated since it only mentions `intersperse`. Happy New Year! r? ``@m-ou-se``,HOORAY,2021-03-02T09:02:32Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/80572,MERGED,2021-01-01T02:21:31Z,2021-02-18T04:22:22Z,Add a `Result::into_ok_or_err` method to extract a `T` from `Result`,thomcc,40e3af5a2131f0f211e2f247faceae4008c94ec9,3,Rollup merge of #80572 - thomcc:ok_or_err r=m-ou-se Add a `Result::into_ok_or_err` method to extract a `T` from `Result` When updating code to handle the semi-recent deprecation of `compare_and_swap` in favor of `compare_exchange` which returns `Result` I wanted this. I've also wanted it with code using `slice::binary_search` before. The name (and perhaps the documentation) is the hardest part here but this name seems consistent with the other Result methods and equivalently memorable.,THUMBS_UP,2021-01-01T03:09:42Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/80572,MERGED,2021-01-01T02:21:31Z,2021-02-18T04:22:22Z,Add a `Result::into_ok_or_err` method to extract a `T` from `Result`,thomcc,40e3af5a2131f0f211e2f247faceae4008c94ec9,3,Rollup merge of #80572 - thomcc:ok_or_err r=m-ou-se Add a `Result::into_ok_or_err` method to extract a `T` from `Result` When updating code to handle the semi-recent deprecation of `compare_and_swap` in favor of `compare_exchange` which returns `Result` I wanted this. I've also wanted it with code using `slice::binary_search` before. The name (and perhaps the documentation) is the hardest part here but this name seems consistent with the other Result methods and equivalently memorable.,EYES,2021-01-01T03:09:44Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/80572,MERGED,2021-01-01T02:21:31Z,2021-02-18T04:22:22Z,Add a `Result::into_ok_or_err` method to extract a `T` from `Result`,thomcc,40e3af5a2131f0f211e2f247faceae4008c94ec9,3,Rollup merge of #80572 - thomcc:ok_or_err r=m-ou-se Add a `Result::into_ok_or_err` method to extract a `T` from `Result` When updating code to handle the semi-recent deprecation of `compare_and_swap` in favor of `compare_exchange` which returns `Result` I wanted this. I've also wanted it with code using `slice::binary_search` before. The name (and perhaps the documentation) is the hardest part here but this name seems consistent with the other Result methods and equivalently memorable.,THUMBS_UP,2021-01-01T06:33:38Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/80572,MERGED,2021-01-01T02:21:31Z,2021-02-18T04:22:22Z,Add a `Result::into_ok_or_err` method to extract a `T` from `Result`,thomcc,40e3af5a2131f0f211e2f247faceae4008c94ec9,3,Rollup merge of #80572 - thomcc:ok_or_err r=m-ou-se Add a `Result::into_ok_or_err` method to extract a `T` from `Result` When updating code to handle the semi-recent deprecation of `compare_and_swap` in favor of `compare_exchange` which returns `Result` I wanted this. I've also wanted it with code using `slice::binary_search` before. The name (and perhaps the documentation) is the hardest part here but this name seems consistent with the other Result methods and equivalently memorable.,EYES,2021-01-01T06:33:39Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/80572,MERGED,2021-01-01T02:21:31Z,2021-02-18T04:22:22Z,Add a `Result::into_ok_or_err` method to extract a `T` from `Result`,thomcc,40e3af5a2131f0f211e2f247faceae4008c94ec9,3,Rollup merge of #80572 - thomcc:ok_or_err r=m-ou-se Add a `Result::into_ok_or_err` method to extract a `T` from `Result` When updating code to handle the semi-recent deprecation of `compare_and_swap` in favor of `compare_exchange` which returns `Result` I wanted this. I've also wanted it with code using `slice::binary_search` before. The name (and perhaps the documentation) is the hardest part here but this name seems consistent with the other Result methods and equivalently memorable.,ROCKET,2021-01-01T06:33:41Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/80578,MERGED,2021-01-01T13:46:08Z,2021-01-02T15:31:50Z,improve unconditional_panic description,RalfJung,bb703058b71244d547a7b866258249f9e7e1b93b,1,Rollup merge of #80578 - RalfJung:panic-lint-description r=lcnr improve unconditional_panic description The fact that the lint is triggered by the ConstProp pass is an implementation detail I do not think that this should be mentioned in the description. Cc `@oli-obk` `@ehuss`,THUMBS_UP,2021-01-01T17:01:28Z,ehuss,NA https://github.com/rust-lang/rust/pull/80591,MERGED,2021-01-01T18:45:04Z,2021-01-03T20:24:16Z,remove allow(incomplete_features) from std,lcnr,2072e117304da97ea1c7df052519f6dc3777b7ff,2,Rollup merge of #80591 - lcnr:incomplete-features r=RalfJung remove allow(incomplete_features) from std cc https://github.com/rust-lang/rust/pull/80349#issuecomment-753357123 > Now I am somewhat concerned that the standard library uses some of these features... I think it is theoretically ok to use incomplete features in the standard library or the compiler if we know that there is an already working subset and we explicitly document what we have to be careful about. Though at that point it is probably better to try and split the incomplete feature into two separate ones similar to `min_specialization`. Will be interesting once `feature(const_evaluatable_checked)` works well enough to imo be used in the compiler but not yet well enough to be removed from `INCOMPLETE_FEATURES`. r? `@RalfJung`,THUMBS_UP,2021-01-02T08:22:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80591,MERGED,2021-01-01T18:45:04Z,2021-01-03T20:24:16Z,remove allow(incomplete_features) from std,lcnr,2072e117304da97ea1c7df052519f6dc3777b7ff,2,Rollup merge of #80591 - lcnr:incomplete-features r=RalfJung remove allow(incomplete_features) from std cc https://github.com/rust-lang/rust/pull/80349#issuecomment-753357123 > Now I am somewhat concerned that the standard library uses some of these features... I think it is theoretically ok to use incomplete features in the standard library or the compiler if we know that there is an already working subset and we explicitly document what we have to be careful about. Though at that point it is probably better to try and split the incomplete feature into two separate ones similar to `min_specialization`. Will be interesting once `feature(const_evaluatable_checked)` works well enough to imo be used in the compiler but not yet well enough to be removed from `INCOMPLETE_FEATURES`. r? `@RalfJung`,THUMBS_UP,2021-01-02T13:43:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80592,MERGED,2021-01-01T18:48:05Z,2021-01-03T00:55:31Z,Suggest renaming or escaping when fixing non-snake-case identifiers which would conflict with keywords,Skynoodle,c7d6c3dfdca64e604838f40573d82561b580a98a,3,Auto merge of #80592 - Skynoodle:snake-case-lint-reserved-identifier r=davidtwco Suggest renaming or escaping when fixing non-snake-case identifiers which would conflict with keywords Fixes #80575,THUMBS_UP,2021-01-02T01:42:56Z,Havvy,NA https://github.com/rust-lang/rust/pull/80592,MERGED,2021-01-01T18:48:05Z,2021-01-03T00:55:31Z,Suggest renaming or escaping when fixing non-snake-case identifiers which would conflict with keywords,Skynoodle,c7d6c3dfdca64e604838f40573d82561b580a98a,3,Auto merge of #80592 - Skynoodle:snake-case-lint-reserved-identifier r=davidtwco Suggest renaming or escaping when fixing non-snake-case identifiers which would conflict with keywords Fixes #80575,THUMBS_UP,2021-01-02T15:06:31Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/80600,MERGED,2021-01-01T21:42:37Z,2021-01-12T11:20:39Z,Add `MaybeUninit` method `array_assume_init`,joboet,babfdafb10cb77f980b11eb7e2ccf0ccdb72b8a1,3,Rollup merge of #80600 - CoffeeBlend:maybe_uninit_array_assume_init r=dtolnay Add `MaybeUninit` method `array_assume_init` When initialising an array element-by-element the conversion to the initialised array is done through `mem::transmute` which is both ugly and does not work with const generics (see #61956). This PR proposes the associated method `array_assume_init` matching the style of `slice_assume_init_*`: ```rust unsafe fn array_assume_init(array: [MaybeUninit; N]) -> [T; N]; ``` Example: ```rust let mut array: [MaybeUninit; 3] = MaybeUninit::uninit_array(); array[0].write(0); array[1].write(1); array[2].write(2); // SAFETY: Now safe as we initialised all elements let array: [i32; 3] = unsafe { MaybeUninit::array_assume_init(array) }; ``` Things I'm unsure about: * Should this be a method of array instead? * Should the function be const?,THUMBS_UP,2021-01-01T23:37:08Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/80600,MERGED,2021-01-01T21:42:37Z,2021-01-12T11:20:39Z,Add `MaybeUninit` method `array_assume_init`,joboet,babfdafb10cb77f980b11eb7e2ccf0ccdb72b8a1,3,Rollup merge of #80600 - CoffeeBlend:maybe_uninit_array_assume_init r=dtolnay Add `MaybeUninit` method `array_assume_init` When initialising an array element-by-element the conversion to the initialised array is done through `mem::transmute` which is both ugly and does not work with const generics (see #61956). This PR proposes the associated method `array_assume_init` matching the style of `slice_assume_init_*`: ```rust unsafe fn array_assume_init(array: [MaybeUninit; N]) -> [T; N]; ``` Example: ```rust let mut array: [MaybeUninit; 3] = MaybeUninit::uninit_array(); array[0].write(0); array[1].write(1); array[2].write(2); // SAFETY: Now safe as we initialised all elements let array: [i32; 3] = unsafe { MaybeUninit::array_assume_init(array) }; ``` Things I'm unsure about: * Should this be a method of array instead? * Should the function be const?,THUMBS_UP,2021-01-02T05:21:20Z,est31,NA https://github.com/rust-lang/rust/pull/80600,MERGED,2021-01-01T21:42:37Z,2021-01-12T11:20:39Z,Add `MaybeUninit` method `array_assume_init`,joboet,babfdafb10cb77f980b11eb7e2ccf0ccdb72b8a1,3,Rollup merge of #80600 - CoffeeBlend:maybe_uninit_array_assume_init r=dtolnay Add `MaybeUninit` method `array_assume_init` When initialising an array element-by-element the conversion to the initialised array is done through `mem::transmute` which is both ugly and does not work with const generics (see #61956). This PR proposes the associated method `array_assume_init` matching the style of `slice_assume_init_*`: ```rust unsafe fn array_assume_init(array: [MaybeUninit; N]) -> [T; N]; ``` Example: ```rust let mut array: [MaybeUninit; 3] = MaybeUninit::uninit_array(); array[0].write(0); array[1].write(1); array[2].write(2); // SAFETY: Now safe as we initialised all elements let array: [i32; 3] = unsafe { MaybeUninit::array_assume_init(array) }; ``` Things I'm unsure about: * Should this be a method of array instead? * Should the function be const?,THUMBS_UP,2021-01-02T23:31:19Z,usbalbin,NA https://github.com/rust-lang/rust/pull/80600,MERGED,2021-01-01T21:42:37Z,2021-01-12T11:20:39Z,Add `MaybeUninit` method `array_assume_init`,joboet,babfdafb10cb77f980b11eb7e2ccf0ccdb72b8a1,3,Rollup merge of #80600 - CoffeeBlend:maybe_uninit_array_assume_init r=dtolnay Add `MaybeUninit` method `array_assume_init` When initialising an array element-by-element the conversion to the initialised array is done through `mem::transmute` which is both ugly and does not work with const generics (see #61956). This PR proposes the associated method `array_assume_init` matching the style of `slice_assume_init_*`: ```rust unsafe fn array_assume_init(array: [MaybeUninit; N]) -> [T; N]; ``` Example: ```rust let mut array: [MaybeUninit; 3] = MaybeUninit::uninit_array(); array[0].write(0); array[1].write(1); array[2].write(2); // SAFETY: Now safe as we initialised all elements let array: [i32; 3] = unsafe { MaybeUninit::array_assume_init(array) }; ``` Things I'm unsure about: * Should this be a method of array instead? * Should the function be const?,THUMBS_UP,2021-02-09T18:39:37Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/80601,MERGED,2021-01-01T22:02:23Z,2021-01-21T15:50:41Z,Improve grammar in documentation of format strings,steffahn,8be36b1b3ac4cfe538ef8d32faeb1021407f55b2,1,Rollup merge of #80601 - steffahn:improve_format_string_grammar r=m-ou-se Improve grammar in documentation of format strings The docs previously were * using some weird `<` and `>` around some nonterminals * _correct me if these **did** have any meaning_ * using of a (not explicitly defined) `text` nonterminal that didn’t explicitly disallow productions containing `'{'` or `'}'` * incorrect in not allowing for `x?` and `X?` productions of `type` * unnecessarily ambiguous both * allowing `type` to be `''` and * using an optional `[type]` * using inconsistent underscore/hyphenation style between `format_string` and `format_spec` vs `maybe-format` _Rendered:_ ![Screenshot_20210101_230901](https://user-images.githubusercontent.com/3986214/103447038-69d7a180-4c86-11eb-8fa0-0a6160a7ff7a.png) _(current docs: https://doc.rust-lang.org/nightly/std/fmt/#syntax)_ ```@rustbot``` modify labels: T-doc,THUMBS_UP,2021-01-02T03:32:48Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/80602,MERGED,2021-01-01T22:25:02Z,2021-01-16T00:13:37Z,Remove DepKind::CrateMetadata and pre-allocation of DepNodes,tgnottingham,fcbd305ee93f49f19313b9bbeaa25ba8837030d9,10,Auto merge of #80602 - tgnottingham:cratemetadata_you_aint_special r=michaelwoerister Remove DepKind::CrateMetadata and pre-allocation of DepNodes Remove much of the special-case handling around crate metadata dependency tracking by replacing `DepKind::CrateMetadata` and the pre-allocation of corresponding `DepNodes` with on-demand invocation of the `crate_hash` query.,THUMBS_UP,2021-01-02T15:00:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80613,MERGED,2021-01-02T10:07:29Z,2021-01-02T15:31:50Z,Diag: print enum variant instead of enum type,bugadani,4172756c80abb79ccd8b6f43d37a797691414bcf,3,Rollup merge of #80613 - bugadani:issue-80607 r=matthewjasper Diag: print enum variant instead of enum type Closes #80607,THUMBS_UP,2021-01-08T01:49:32Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/80613,MERGED,2021-01-02T10:07:29Z,2021-01-02T15:31:50Z,Diag: print enum variant instead of enum type,bugadani,4172756c80abb79ccd8b6f43d37a797691414bcf,3,Rollup merge of #80613 - bugadani:issue-80607 r=matthewjasper Diag: print enum variant instead of enum type Closes #80607,THUMBS_UP,2021-01-08T02:28:58Z,tesuji,NA https://github.com/rust-lang/rust/pull/80614,MERGED,2021-01-02T11:24:12Z,2021-01-16T23:15:43Z,Explain why borrows can't be held across yield point in async blocks,1000teslas,af5b0d9883b7e6b8f27b431e5471bf658f3e0db0,4,Rollup merge of #80614 - 1000teslas:issue-78938-fix r=tmandry Explain why borrows can't be held across yield point in async blocks For https://github.com/rust-lang/rust/issues/78938.,THUMBS_UP,2021-01-02T17:19:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80614,MERGED,2021-01-02T11:24:12Z,2021-01-16T23:15:43Z,Explain why borrows can't be held across yield point in async blocks,1000teslas,af5b0d9883b7e6b8f27b431e5471bf658f3e0db0,4,Rollup merge of #80614 - 1000teslas:issue-78938-fix r=tmandry Explain why borrows can't be held across yield point in async blocks For https://github.com/rust-lang/rust/issues/78938.,THUMBS_UP,2021-01-12T02:30:02Z,estebank,NA https://github.com/rust-lang/rust/pull/80625,MERGED,2021-01-02T18:35:57Z,2021-01-15T15:26:06Z,Choose the version of python at runtime (portable version),jyn514,18ec4a9a74731ddc6a453ca29c0836f61dbcb8d4,1,Auto merge of #80625 - jyn514:python-what-python r=Mark-Simulacrum Choose the version of python at runtime (portable version) r? `@Mark-Simulacrum` Fixed version of https://github.com/rust-lang/rust/pull/80585. The goal is to avoid giving 'error: python3 required' when downloading LLVM from CI and instead default to python3 where possible. This has some minor overhead when you have `python` as python2 but almost nothing compared to actually running the build.,HEART,2021-01-06T14:51:11Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/80632,MERGED,2021-01-02T23:14:42Z,2021-02-07T19:36:12Z,Identify unreachable subpatterns more reliably,Nadrieril,36ecbc94eb6be90bc38b2d0fdd4bfac3f34d9923,6,Auto merge of #80632 - Nadrieril:fix-80501 r=varkor Identify unreachable subpatterns more reliably In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea. Instead this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex but thankfully self-contained; the rest of the code does not need to know anything about it. Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral. r? `@varkor`,HEART,2021-01-04T01:14:34Z,varkor,NA https://github.com/rust-lang/rust/pull/80632,MERGED,2021-01-02T23:14:42Z,2021-02-07T19:36:12Z,Identify unreachable subpatterns more reliably,Nadrieril,36ecbc94eb6be90bc38b2d0fdd4bfac3f34d9923,6,Auto merge of #80632 - Nadrieril:fix-80501 r=varkor Identify unreachable subpatterns more reliably In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea. Instead this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex but thankfully self-contained; the rest of the code does not need to know anything about it. Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral. r? `@varkor`,HEART,2021-01-05T04:02:34Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80632,MERGED,2021-01-02T23:14:42Z,2021-02-07T19:36:12Z,Identify unreachable subpatterns more reliably,Nadrieril,36ecbc94eb6be90bc38b2d0fdd4bfac3f34d9923,6,Auto merge of #80632 - Nadrieril:fix-80501 r=varkor Identify unreachable subpatterns more reliably In https://github.com/rust-lang/rust/pull/80104 I used `Span`s to identify unreachable sub-patterns in the presence of or-patterns during exhaustiveness checking. In https://github.com/rust-lang/rust/issues/80501 it was revealed that `Span`s are complicated and that this was not a good idea. Instead this PR identifies subpatterns logically: as a path in the tree of subpatterns of a given pattern. I made a struct that captures a set of such subpatterns. This is a bit complex but thankfully self-contained; the rest of the code does not need to know anything about it. Fixes https://github.com/rust-lang/rust/issues/80501. I think I managed to keep the perf neutral. r? `@varkor`,HEART,2021-02-07T17:14:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80635,MERGED,2021-01-03T02:26:37Z,2021-01-17T17:51:52Z,Improve diagnostics when closure doesn't meet trait bound,roxelo,19f97802cacd60b68a3fdcbda198cbe3d3c6878f,16,Rollup merge of #80635 - sexxi-goose:use-place-instead-of-symbol r=nikomatsakis` Improve diagnostics when closure doesn't meet trait bound Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled. Closes rust-lang/project-rfc-2229/issues/21 r? ```@nikomatsakis```,THUMBS_UP,2021-01-22T11:04:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80641,MERGED,2021-01-03T07:41:01Z,2021-02-01T22:21:22Z,Add visitors for checking #[inline],Danue1,d4e3570db4c007089035b833cc20c7fc2f8cb32f,9,Auto merge of #80641 - Danue1:patch-1 r=oli-obk Add visitors for checking #[inline] For #80564,HEART,2021-01-03T12:20:10Z,oli-obk,NA https://github.com/rust-lang/rust/pull/80641,MERGED,2021-01-03T07:41:01Z,2021-02-01T22:21:22Z,Add visitors for checking #[inline],Danue1,d4e3570db4c007089035b833cc20c7fc2f8cb32f,9,Auto merge of #80641 - Danue1:patch-1 r=oli-obk Add visitors for checking #[inline] For #80564,HEART,2021-01-03T13:12:55Z,AkiaCode,NA https://github.com/rust-lang/rust/pull/80652,MERGED,2021-01-03T15:42:02Z,2021-02-08T01:13:36Z,Improve SIMD type element count validation,calebzulawski,bb587b1a1737738658d2eaecd4c8c1cab555257a,28,"Auto merge of #80652 - calebzulawski:simd-lanes r=nagisa Improve SIMD type element count validation Resolves rust-lang/stdsimd#53. These changes are motivated by `stdsimd` moving in the direction of const generic vectors e.g.: ```rust #[repr(simd)] struct SimdF32([f32; N]); ``` This makes a few changes: * Establishes a maximum SIMD lane count of 2^16 (65536). This value is arbitrary but attempts to validate lane count before hitting potential errors in the backend. It's not clear what LLVM's maximum lane count is but cranelift's appears to be much less than `usize::MAX` at least. * Expands some SIMD intrinsics to support arbitrary lane counts. This resolves the ICE in the linked issue. * Attempts to catch invalid-sized vectors during typeck when possible. Unresolved questions: * Generic-length vectors can't be validated in typeck and are only validated after monomorphization while computing layout. This ""works"" but the errors simply bail out with no context beyond the name of the type. Should these errors instead return `LayoutError` or otherwise provide context in some way? As it stands users of `stdsimd` could trivially produce monomorphization errors by making zero-length vectors. cc `@bjorn3`",THUMBS_UP,2021-01-06T20:59:30Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,EYES,2021-01-03T15:54:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-01-04T13:16:48Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-01-05T04:00:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-01-09T01:04:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-02-03T13:00:25Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,EYES,2021-02-03T13:00:27Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-02-13T02:33:00Z,tmandry,NA https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-03-15T12:13:57Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/80653,MERGED,2021-01-03T15:54:05Z,2021-01-08T15:21:52Z,Recursively document methods via `Deref` traits,jryans,937f629535f38c655267f1ed21ce6830f592f5df,7,Auto merge of #80653 - jryans:doc-deref-recursive r=jyn514 GuillaumeGomez Recursively document methods via `Deref` traits This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) Fixes https://github.com/rust-lang/rust/issues/26207 Fixes https://github.com/rust-lang/rust/issues/53038 Fixes https://github.com/rust-lang/rust/issues/71640 r? `@jyn514`,HOORAY,2021-03-25T14:52:44Z,DianaNites,NA https://github.com/rust-lang/rust/pull/80670,MERGED,2021-01-04T00:12:49Z,2021-01-16T23:15:43Z,TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips,the8472,d8843d9d82950eeb27bdce496f6179b085549d29,3,Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition r=m-ou-se TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips I found this while working on improvements for TRA. After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed. If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier. Included test fails on nightly [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f),THUMBS_UP,2021-01-04T09:18:21Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/80670,MERGED,2021-01-04T00:12:49Z,2021-01-16T23:15:43Z,TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips,the8472,d8843d9d82950eeb27bdce496f6179b085549d29,3,Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition r=m-ou-se TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips I found this while working on improvements for TRA. After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed. If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier. Included test fails on nightly [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f),THUMBS_UP,2021-01-05T13:24:27Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/80670,MERGED,2021-01-04T00:12:49Z,2021-01-16T23:15:43Z,TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips,the8472,d8843d9d82950eeb27bdce496f6179b085549d29,3,Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition r=m-ou-se TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips I found this while working on improvements for TRA. After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed. If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier. Included test fails on nightly [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f),THUMBS_UP,2021-01-18T09:35:12Z,bluss,NA https://github.com/rust-lang/rust/pull/80670,MERGED,2021-01-04T00:12:49Z,2021-01-16T23:15:43Z,TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips,the8472,d8843d9d82950eeb27bdce496f6179b085549d29,3,Rollup merge of #80670 - the8472:fix-zip-trusted-random-access-composition r=m-ou-se TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips I found this while working on improvements for TRA. After partially consuming a Zip adapter and then wrapping it into another Zip where the adapters use their `TrustedRandomAccess` specializations leads to the outer adapter returning elements which should have already been consumed. If the optimizer gets tripped up by the addition this might affect performance for chained `zip()` iterators even when the inner one is not partially advanced but it would require more extensive fixes to `TrustedRandomAccess` to communicate those offsets earlier. Included test fails on nightly [playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=24fa1edf8a104ff31f5a24830593b01f),THUMBS_UP,2021-02-04T07:30:17Z,Qwaz,qwazpia@gmail.com https://github.com/rust-lang/rust/pull/80681,MERGED,2021-01-04T09:35:46Z,2021-01-16T23:15:43Z,Clarify what the effects of a 'logic error' are,ChrisJefferson,40d2506cab20cfd7df17f390ec662b22f166f0a6,5,"Rollup merge of #80681 - ChrisJefferson:logic-error-doc r=m-ou-se Clarify what the effects of a 'logic error' are This clarifies what a 'logic error' is (which is a term used to describe what happens if you put things in a hash table or btree and then use something like a refcell to break the internal ordering). This tries to be as vague as possible as we don't really want to promise what happens except ""bad things but not UB"". This was discussed in #80657",HEART,2021-01-14T03:18:41Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/80686,MERGED,2021-01-04T14:07:14Z,2021-01-05T11:29:34Z,Error when #[doc(alias)] has same name as the item,GuillaumeGomez,f4b9d32ef53c0629732ee131b640920ae12d1edb,5,Auto merge of #80686 - GuillaumeGomez:error-doc-alias-same-name r=jyn514 Error when #[doc(alias)] has same name as the item Something I came across when reviewing some doc alias PRs. r? `@jyn514`,THUMBS_UP,2021-01-04T14:27:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80689,CLOSED,2021-01-04T15:28:10Z,2021-02-27T20:11:03Z,[WIP] Implement token-based handling of attributes,Aaron1011,NA,NA,NA,HOORAY,2021-01-19T02:10:06Z,varkor,NA https://github.com/rust-lang/rust/pull/80689,CLOSED,2021-01-04T15:28:10Z,2021-02-27T20:11:03Z,[WIP] Implement token-based handling of attributes,Aaron1011,NA,NA,NA,HOORAY,2021-01-19T05:30:35Z,emmanueltouzery,NA https://github.com/rust-lang/rust/pull/80709,MERGED,2021-01-05T01:23:24Z,2021-01-08T00:20:12Z,Limit target endian to an enum instead of free string,tesuji,e02b0f4a5540ed22053f18f917b9a18291280bc5,29,Auto merge of #80709 - lzutao:target-enumerate r=petrochenkov Limit target endian to an enum instead of free string This is #77604 revived.,THUMBS_UP,2021-01-05T11:49:34Z,arniu,NA https://github.com/rust-lang/rust/pull/80715,MERGED,2021-01-05T06:18:17Z,2021-01-23T13:12:28Z,Change branching in `iter.skip()`,JulianKnodt,4153fa82ff8403bde877b52d35bf1ef99e54a4a2,2,Auto merge of #80715 - JulianKnodt:skip_opt r=nagisa Change branching in `iter.skip()` Optimize branching in `Skip` which was brought up in #80416. This assumes that if `next` is called it's likely that there will be more calls to `next` and the branch for skip will only be hit once thus it's unlikely to take that path. Even w/o the `unlikely` intrinsic it compiles more efficiently I believe because the path where `next` is called is always taken. It should be noted there are very few places in the compiler where `Skip` is used so probably won't have a noticeable perf impact. [New impl](https://godbolt.org/z/85rdj4) [Old impl](https://godbolt.org/z/Wc74rh) [Some additional asm examples](https://godbolt.org/z/feKzoz) although they really don't have a ton of difference between them.,THUMBS_UP,2021-01-05T09:02:15Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,THUMBS_UP,2021-01-05T21:05:15Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,THUMBS_UP,2021-01-06T19:35:32Z,lqd,NA https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,THUMBS_UP,2021-01-08T12:59:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,ROCKET,2021-01-22T06:22:57Z,cauebs,NA https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,THUMBS_UP,2021-01-22T11:11:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80718,MERGED,2021-01-05T08:25:21Z,2021-01-13T20:36:05Z,Consistently avoid constructing optimized MIR when not doing codegen,tmiasko,9bc8b00b4a4e38ccbc3aeec2c123538973c67eba,1,Auto merge of #80718 - tmiasko:skip-opt-mir r=oli-obk Consistently avoid constructing optimized MIR when not doing codegen The optimized MIR for closures is being encoded unconditionally while being unnecessary for cargo check. This turns out to be especially costly with MIR inlining enabled since it triggers computation of optimized MIR for all callees that are being examined for inlining purposes https://github.com/rust-lang/rust/pull/77307#issuecomment-751915450. Skip encoding of optimized MIR for closures enum constructors struct constructors and trait fns when not doing codegen like it is already done for other items since 49433.,THUMBS_UP,2021-02-13T02:38:19Z,tmandry,NA https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-01-05T15:28:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-01-05T15:28:47Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-01-07T01:58:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-01-07T20:35:16Z,estebank,NA https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-01-13T00:42:55Z,tesuji,NA https://github.com/rust-lang/rust/pull/80723,MERGED,2021-01-05T15:26:08Z,2021-03-05T16:31:33Z,Implement NOOP_METHOD_CALL lint,rylev,e6a6df5daad01472e93f19802b0ce25f7a9b020c,20,Rollup merge of #80723 - rylev:noop-lint-pass r=estebank Implement NOOP_METHOD_CALL lint Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g calling `<&T as Clone>::clone()` when `T: !Clone`). This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs: * [ ] No UFCS support * [ ] The warning message is pretty plain * [ ] Doesn't work for `ToOwned` The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance it expects substitutions to have happened which haven't yet performed but we check first for `needs_subst` to ensure we're dealing with a monomorphic type. Thank you to ```@davidtwco ``` ```@Aaron1011 ``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.,HEART,2021-03-02T18:11:49Z,camelid,NA https://github.com/rust-lang/rust/pull/80726,MERGED,2021-01-05T15:39:51Z,2021-02-05T14:53:00Z,relax adt unsizing requirements,lcnr,676ff77fb7bd45aaa56ff636fdaee3a084c23c1f,7,Rollup merge of #80726 - lcnr:unsize-query r=oli-obk relax adt unsizing requirements Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change. This change is currently insta stable and changes the language so it at least requires a lang fcp. I feel like the current state is fairly unintuitive. An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967 ```rust struct A(T B); // previously ERR // struct A(T B<[u32; 1] U>); // ok struct B(T U); fn main() { let x = A([0; 1] B([0; 1] [0; 1])); let y: &A<[u32; 1] [u32]> = &x; assert_eq!(y.1.1.len() 1); } ```,THUMBS_UP,2021-01-05T16:14:31Z,fmease,NA https://github.com/rust-lang/rust/pull/80726,MERGED,2021-01-05T15:39:51Z,2021-02-05T14:53:00Z,relax adt unsizing requirements,lcnr,676ff77fb7bd45aaa56ff636fdaee3a084c23c1f,7,Rollup merge of #80726 - lcnr:unsize-query r=oli-obk relax adt unsizing requirements Changes unsizing of structs in case the last struct field shares generic params with other adt fields which do not change. This change is currently insta stable and changes the language so it at least requires a lang fcp. I feel like the current state is fairly unintuitive. An example for what's now allowed would be https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6dd331d23f5c9ffc8c978175aae2e967 ```rust struct A(T B); // previously ERR // struct A(T B<[u32; 1] U>); // ok struct B(T U); fn main() { let x = A([0; 1] B([0; 1] [0; 1])); let y: &A<[u32; 1] [u32]> = &x; assert_eq!(y.1.1.len() 1); } ```,THUMBS_UP,2021-11-12T11:36:53Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/80732,MERGED,2021-01-05T20:17:35Z,2021-02-09T08:47:53Z,Allow Trait inheritance with cycles on associated types take 2,spastorino,44e526b2c38c81c732dd3e640f3cc06acc8f69bb,30,Rollup merge of #80732 - spastorino:trait-inheritance-self2 r=nikomatsakis Allow Trait inheritance with cycles on associated types take 2 This reverts the revert of #79209 and fixes the ICEs that's occasioned by that PR exposing some problems that are addressed in #80648 and #79811. For easier review I'd say check only the last commit the first one is just a revert of the revert of #79209 which was already approved. This also could be considered part or the actual fix of #79560 but I guess for that to be closed and fixed completely we would need to land #80648 and #79811 too. r? `@nikomatsakis` cc `@Aaron1011`,THUMBS_UP,2021-01-08T18:46:54Z,swarnimarun,NA https://github.com/rust-lang/rust/pull/80732,MERGED,2021-01-05T20:17:35Z,2021-02-09T08:47:53Z,Allow Trait inheritance with cycles on associated types take 2,spastorino,44e526b2c38c81c732dd3e640f3cc06acc8f69bb,30,Rollup merge of #80732 - spastorino:trait-inheritance-self2 r=nikomatsakis Allow Trait inheritance with cycles on associated types take 2 This reverts the revert of #79209 and fixes the ICEs that's occasioned by that PR exposing some problems that are addressed in #80648 and #79811. For easier review I'd say check only the last commit the first one is just a revert of the revert of #79209 which was already approved. This also could be considered part or the actual fix of #79560 but I guess for that to be closed and fixed completely we would need to land #80648 and #79811 too. r? `@nikomatsakis` cc `@Aaron1011`,THUMBS_UP,2021-01-16T14:11:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80734,MERGED,2021-01-05T21:55:34Z,2021-03-02T08:02:22Z,check that first arg to `panic!()` in const is `&str`,abonander,865cf0c3b69540f236f95e0cd0ecf939f4834b6c,8,Rollup merge of #80734 - abonander:ab/issue-66693 r=oli-obk check that first arg to `panic!()` in const is `&str` closes #66693 ~~TODO: regression test~~ cc `@RalfJung` for error message wording,HOORAY,2021-03-02T00:32:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80736,MERGED,2021-01-06T00:18:30Z,2021-01-13T07:39:03Z,use Once instead of Mutex to manage capture resolution,KodrAus,e73ee1dde270cf1f7dc0e3f3eb3366c6fdc391c6,2,Rollup merge of #80736 - KodrAus:feat/lazy-resolve r=dtolnay use Once instead of Mutex to manage capture resolution For #78299 This allows us to return borrows of the captured backtrace frames that are tied to a borrow of the Backtrace itself instead of to some short-lived Mutex guard. We could alternatively share `&Mutex`s and lock on-demand but then we could potentially forget to call `resolve()` before working with the capture. It also makes it semantically clearer what synchronization is needed on the capture. cc `@seanchen1991` `@rust-lang/project-error-handling`,ROCKET,2021-01-06T15:45:18Z,seanchen1991,seanchen11235@gmail.com https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,EYES,2021-01-06T03:51:13Z,tesuji,NA https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,EYES,2021-01-06T05:59:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,CONFUSED,2021-01-06T08:42:30Z,CryZe,NA https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,CONFUSED,2021-01-15T06:13:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,THUMBS_UP,2021-01-15T21:34:31Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/80741,CLOSED,2021-01-06T01:37:44Z,2021-01-08T23:39:55Z,Deprecate std::path::Path's aliases of `std::fs` functions.,sunfishcode,NA,NA,NA,THUMBS_UP,2021-01-17T22:35:57Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-01-06T08:43:41Z,the8472,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-01-06T08:56:14Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-01-09T06:21:10Z,Pratyush,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-01-09T09:36:16Z,bluss,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-03-25T13:54:06Z,Miezhiko,Miezhiko@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-03-25T15:34:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-03-26T03:29:43Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-04-19T09:14:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-04-22T06:41:10Z,poonai,rbalajis25@gmail.com https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-04-27T18:44:10Z,LesnyRumcajs,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-04-30T16:23:47Z,DianaNites,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-05-03T08:22:52Z,Zhormos,NA https://github.com/rust-lang/rust/pull/80749,MERGED,2021-01-06T08:32:24Z,2021-01-09T07:49:02Z,Make target-cpu=native detect individual features,as-com,c87ef0a2fcedaa865ff7713953824d0ea9734720,3,"Auto merge of #80749 - as-com:target-cpu-actually-native r=nagisa Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. ""Haswell"" Pentiums and Celerons that lack support for AVX and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218",THUMBS_UP,2021-05-13T01:29:01Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/80754,MERGED,2021-01-06T16:44:55Z,2021-01-07T00:31:10Z,Optimize away a `fs::metadata` call.,sunfishcode,d7769b9beacc1cd10d98590838975cbbfa1d76a7,1,Auto merge of #80754 - sunfishcode:path-cleanup/rustc-fs-util r=davidtwco Optimize away a `fs::metadata` call. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-06T17:52:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-06T17:53:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-15T05:05:04Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-15T11:40:18Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-15T12:51:51Z,Dr-Emann,dremann@gmail.com https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-15T20:00:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80756,MERGED,2021-01-06T16:54:04Z,2021-01-08T09:51:31Z,Optimize away some `fs::metadata` calls.,sunfishcode,569e542f9f8792268ce02fc1ad7c00b449b965dc,3,Auto merge of #80756 - sunfishcode:path-cleanup/rustc-incremental r=nagisa Optimize away some `fs::metadata` calls. This also eliminates a use of a `Path` convenience function in support of #80741 refactoring `std::path` to focus on pure data structures and algorithms.,THUMBS_UP,2021-01-20T11:27:37Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/80758,MERGED,2021-01-06T17:30:02Z,2021-01-06T21:48:11Z,update Miri,RalfJung,c2de47a9aa4c9812884f341f1852e9c9610f5f7a,1,Auto merge of #80758 - RalfJung:miri r=RalfJung update Miri update Miri to include fix for https://github.com/rust-lang/miri/issues/1643 Cc `@rust-lang/miri` r? `@ghost`,HEART,2021-01-06T17:33:25Z,taiki-e,NA https://github.com/rust-lang/rust/pull/80796,MERGED,2021-01-07T19:36:51Z,2021-01-13T07:39:02Z,Update to LLVM 11.0.1,cuviper,330e196c492ec22f50786bf75676dd837d61b967,3,Rollup merge of #80796 - cuviper:llvm-11.0.1 r=nikic Update to LLVM 11.0.1 This updates to a new LLVM branch rebased on the upstream `llvmorg-11.0.1`. All our patches applied cleanly except the fortanix unwind changes which just needed a small adjustment in cmake files. r? `@nikic` Fixes https://github.com/rust-lang/rust/issues/73722,EYES,2021-01-07T22:31:56Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/80799,MERGED,2021-01-07T22:42:47Z,2021-01-08T05:58:53Z,Get rid of custom pretty-printing in rustdoc,jyn514,dec3dbd36a572222ad96b9f18b39b4f916614fcd,4,Rollup merge of #80799 - jyn514:pretty-print r=CraftSpider Get rid of custom pretty-printing in rustdoc and use rustc_hir_pretty directly instead. Closes https://github.com/rust-lang/rust/issues/79497. r? `@CraftSpider`,THUMBS_UP,2021-01-08T01:26:52Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/80801,MERGED,2021-01-08T00:51:09Z,2021-01-10T10:48:46Z,Use correct span for structured suggestion,estebank,700f3f23d8ac8971d107f26c18cd9f45276cff4d,27,Rollup merge of #80801 - estebank:correct-binding-sugg-span r=petrochenkov Use correct span for structured suggestion On structured suggestion for `let` -> `const` and `const` -> `let` use a proper `Span` and update tests to check the correct application. Follow up to #80012.,THUMBS_UP,2021-01-08T02:00:06Z,sasurau4,NA https://github.com/rust-lang/rust/pull/80824,MERGED,2021-01-08T21:20:46Z,2021-01-13T13:56:29Z,Try to avoid locals when cloning into Box/Rc/Arc,cuviper,116d1a7056830ccf649f74f823de4333ed329392,4,Auto merge of #80824 - cuviper:heap-clones r=kennytm Try to avoid locals when cloning into Box/Rc/Arc For generic `T: Clone` we can allocate an uninitialized box beforehand which gives the optimizer a chance to create the clone directly in the heap. For `T: Copy` we can go further and do a simple memory copy regardless of optimization level. The same applies to `Rc`/`Arc::make_mut` when they must clone the data.,EYES,2021-01-08T23:37:14Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80824,MERGED,2021-01-08T21:20:46Z,2021-01-13T13:56:29Z,Try to avoid locals when cloning into Box/Rc/Arc,cuviper,116d1a7056830ccf649f74f823de4333ed329392,4,Auto merge of #80824 - cuviper:heap-clones r=kennytm Try to avoid locals when cloning into Box/Rc/Arc For generic `T: Clone` we can allocate an uninitialized box beforehand which gives the optimizer a chance to create the clone directly in the heap. For `T: Copy` we can go further and do a simple memory copy regardless of optimization level. The same applies to `Rc`/`Arc::make_mut` when they must clone the data.,HOORAY,2021-01-18T09:44:43Z,bluss,NA https://github.com/rust-lang/rust/pull/80834,MERGED,2021-01-09T09:25:00Z,2021-01-15T12:25:59Z,Remove unreachable panics from VecDeque::{front/back}[_mut],bugadani,1b8fd02daab85e129f0dda9c92ea11aaa14b7485,2,Rollup merge of #80834 - bugadani:vecdeque r=oli-obk Remove unreachable panics from VecDeque::{front/back}[_mut] `VecDeque`'s `front` `front_mut` `back` and `back_mut` methods are implemented in terms of the index operator which causes these functions to contain [unreachable panic calls](https://rust.godbolt.org/z/MTnq1o). This PR reimplements these methods in terms of `get[_mut]` instead.,THUMBS_UP,2021-01-09T11:16:52Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80835,CLOSED,2021-01-09T09:31:58Z,2021-04-01T14:20:53Z,Add Iterator::at_least() and Iterator::at_most() API,Folyd,NA,NA,NA,CONFUSED,2021-01-09T18:02:20Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/80835,CLOSED,2021-01-09T09:31:58Z,2021-04-01T14:20:53Z,Add Iterator::at_least() and Iterator::at_most() API,Folyd,NA,NA,NA,CONFUSED,2021-01-30T13:26:08Z,kennytm,NA https://github.com/rust-lang/rust/pull/80838,MERGED,2021-01-09T15:07:00Z,2021-01-24T12:34:06Z,Target stack-probe support configurable finely,nagisa,72c7b7026742766998655eba95fca984046c0288,35,"Auto merge of #80838 - nagisa:nagisa/stack-probe-type r=cuviper Target stack-probe support configurable finely This adds capability to configure the target's stack probe support in a more precise manner than just on/off. In particular now we allow choosing between always inline-asm always call or either one of those depending on the LLVM version. Note that this removes the ability to turn off the generation of the stack-probe attribute. This is valid to replace it with inline-asm for all targets because `probe-stack=""inline-asm""` will not generate any machine code on targets that do not currently support stack probes. This makes support for stack probes on targets that don't have any right now automatic with LLVM upgrades in the future. (This is valid to do based on the fact that clang unconditionally sets this attribute when `-fstack-clash-protection` is used AFAICT) cc #77885 r? `@cuviper`",HOORAY,2021-01-23T11:21:09Z,ojeda,NA https://github.com/rust-lang/rust/pull/80841,CLOSED,2021-01-09T16:22:03Z,2021-02-01T02:38:20Z,Add `OsStr::display` as a counterpart to `Path::display`,jyn514,NA,NA,NA,HEART,2021-01-17T14:42:50Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/80841,CLOSED,2021-01-09T16:22:03Z,2021-02-01T02:38:20Z,Add `OsStr::display` as a counterpart to `Path::display`,jyn514,NA,NA,NA,HEART,2021-04-21T08:57:07Z,chpio,NA https://github.com/rust-lang/rust/pull/80847,CLOSED,2021-01-09T18:20:04Z,2021-04-04T17:20:01Z,Make E0121's suggestion more robust (+ fix E0308's suggestion),PatchMixolydic,NA,NA,NA,HEART,2021-01-12T00:30:44Z,estebank,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-01-09T19:29:54Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-01-09T19:30:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-01-09T19:57:59Z,Urgau,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-01-09T19:59:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-01-13T15:14:53Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-01-16T00:22:46Z,estebank,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-01-22T09:57:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-01-22T09:57:06Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-04T07:52:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-02-04T11:03:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-04T11:03:19Z,Virgiel,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-04T15:30:46Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-04T18:22:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-05T00:14:37Z,bstrie,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-02-05T05:16:47Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-02-05T14:07:32Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HOORAY,2021-02-05T20:20:58Z,yerke,NA https://github.com/rust-lang/rust/pull/80851,MERGED,2021-01-09T19:12:05Z,2021-02-01T13:26:15Z,Implement Rust 2021 panic,m-ou-se,e0d9f793990d20f8f640097e28556886ba5362f0,26,Auto merge of #80851 - m-ou-se:panic-2021 r=petrochenkov Implement Rust 2021 panic This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007. It does so by replacing `{std core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller. This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: https://github.com/rust-lang/rust/pull/80879/commits/c5273bdfb266c35e8eab9413aa8d58d27fdbe114 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.,HEART,2021-02-05T20:20:59Z,yerke,NA https://github.com/rust-lang/rust/pull/80857,MERGED,2021-01-09T20:38:24Z,2021-01-10T10:48:46Z,Add comment to `Vec::truncate` explaining `>` vs `>=`,camelid,19b8c65e4e0af841a9ecaa99b5e1ae3c73ff9c7f,1,Rollup merge of #80857 - camelid:vec-truncate-comment r=scottmcm Add comment to `Vec::truncate` explaining `>` vs `>=` Hopefully this will prevent people from continuing to ask about this over and over again :) See [this Zulip discussion][1] for more. [1]: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Vec.3A.3Atruncate.20implementation r? ``@scottmcm``,THUMBS_UP,2021-01-09T20:54:20Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/80868,MERGED,2021-01-10T08:03:53Z,2021-01-28T12:09:55Z,Print failure message on all tests that should panic but don't,johanngan,98226638fd014ec7786878a0b102448f3530bcdb,2,Rollup merge of #80868 - johanngan:should-panic-msg-with-expected r=m-ou-se Print failure message on all tests that should panic but don't Fixes #80861. Tests with the `#[should_panic]` attribute should always print a failure message if no panic occurs regardless of whether or not an `expected` panic message is specified.,THUMBS_UP,2021-01-10T14:14:31Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80874,MERGED,2021-01-10T13:51:28Z,2021-03-02T16:02:58Z,Update intra-doc link documentation to match the implementation,jyn514,a9339ed531d888fbc9d68d117cf7fc905926649e,1,Rollup merge of #80874 - jyn514:intra-doc-docs r=Manishearth Update intra-doc link documentation to match the implementation r? `@Manishearth` cc `@camelid` `@m-ou-se` Relevant PRs: - https://github.com/rust-lang/rust/pull/74489 - https://github.com/rust-lang/rust/pull/80181 - https://github.com/rust-lang/rust/pull/76078 - https://github.com/rust-lang/rust/pull/77519 - https://github.com/rust-lang/rust/pull/73101 Relevant issues: - https://github.com/rust-lang/rust/issues/78800 - https://github.com/rust-lang/rust/issues/77200 - https://github.com/rust-lang/rust/issues/77199 / https://github.com/rust-lang/rust/issues/54191/ I haven't documented things that I consider 'just bugs' like https://github.com/rust-lang/rust/issues/77732 but I have documented features that aren't implemented like https://github.com/rust-lang/rust/issues/78800.,THUMBS_UP,2021-01-10T18:29:00Z,Havvy,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,EYES,2021-01-10T14:51:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-01-11T09:59:39Z,joboet,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-01-11T23:13:45Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-01-11T23:27:39Z,marmeladema,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-02-04T09:13:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,EYES,2021-02-04T09:13:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,EYES,2021-02-04T09:44:05Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-02-04T14:51:23Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/80876,MERGED,2021-01-10T14:22:23Z,2021-01-26T22:43:50Z,Add `unwrap_unchecked()` methods for `Option` and `Result`,ojeda,fe6b3a97921eb59502dfca13505e3ef68f5289bb,5,Rollup merge of #80876 - ojeda:option-result-unwrap_unchecked r=m-ou-se Add `unwrap_unchecked()` methods for `Option` and `Result` In particular: - `unwrap_unchecked()` for `Option`. - `unwrap_unchecked()` and `unwrap_err_unchecked()` for `Result`. These complement other `*_unchecked()` methods in `core` etc. Currently there are a couple of places it may be used inside rustc (`LinkedList` `BTree`). It is also easy to find other repositories with similar functionality. Fixes #48278.,THUMBS_UP,2021-02-04T17:09:34Z,tux3,NA https://github.com/rust-lang/rust/pull/80879,CLOSED,2021-01-10T14:50:29Z,2021-01-24T18:46:14Z,Make `std::panic!()` identical to `core::panic!()` on Rust 2021,m-ou-se,NA,NA,NA,HOORAY,2021-01-10T15:24:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80879,CLOSED,2021-01-10T14:50:29Z,2021-01-24T18:46:14Z,Make `std::panic!()` identical to `core::panic!()` on Rust 2021,m-ou-se,NA,NA,NA,HOORAY,2021-01-10T20:44:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/80879,CLOSED,2021-01-10T14:50:29Z,2021-01-24T18:46:14Z,Make `std::panic!()` identical to `core::panic!()` on Rust 2021,m-ou-se,NA,NA,NA,HOORAY,2021-01-11T01:43:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80886,MERGED,2021-01-10T21:13:49Z,2021-01-30T13:58:13Z,Stabilize raw ref macros,RalfJung,b94d84d38a3d306a54c5a23caa54d373a2202b9f,11,Rollup merge of #80886 - RalfJung:stable-raw-ref-macros r=m-ou-se Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394) which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185 I am not particularly happy with the current names of the macros. So I propose we also change them which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394,HOORAY,2021-01-10T22:58:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80886,MERGED,2021-01-10T21:13:49Z,2021-01-30T13:58:13Z,Stabilize raw ref macros,RalfJung,b94d84d38a3d306a54c5a23caa54d373a2202b9f,11,Rollup merge of #80886 - RalfJung:stable-raw-ref-macros r=m-ou-se Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394) which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185 I am not particularly happy with the current names of the macros. So I propose we also change them which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394,THUMBS_UP,2021-01-11T00:59:59Z,kennytm,NA https://github.com/rust-lang/rust/pull/80886,MERGED,2021-01-10T21:13:49Z,2021-01-30T13:58:13Z,Stabilize raw ref macros,RalfJung,b94d84d38a3d306a54c5a23caa54d373a2202b9f,11,Rollup merge of #80886 - RalfJung:stable-raw-ref-macros r=m-ou-se Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394) which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185 I am not particularly happy with the current names of the macros. So I propose we also change them which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394,HOORAY,2021-01-11T11:19:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/80886,MERGED,2021-01-10T21:13:49Z,2021-01-30T13:58:13Z,Stabilize raw ref macros,RalfJung,b94d84d38a3d306a54c5a23caa54d373a2202b9f,11,Rollup merge of #80886 - RalfJung:stable-raw-ref-macros r=m-ou-se Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394) which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185 I am not particularly happy with the current names of the macros. So I propose we also change them which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394,HEART,2021-01-11T21:19:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80886,MERGED,2021-01-10T21:13:49Z,2021-01-30T13:58:13Z,Stabilize raw ref macros,RalfJung,b94d84d38a3d306a54c5a23caa54d373a2202b9f,11,Rollup merge of #80886 - RalfJung:stable-raw-ref-macros r=m-ou-se Stabilize raw ref macros This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394) which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed. However as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185 I am not particularly happy with the current names of the macros. So I propose we also change them which means I am proposing to stabilize the following in `core::ptr`: ```rust pub macro const_addr_of($e:expr) { &raw const $e } pub macro mut_addr_of($e:expr) { &raw mut $e } ``` The macro name change means we need another round of FCP. Cc `````@rust-lang/libs````` Fixes #73394,THUMBS_UP,2021-02-03T05:45:04Z,notgull,NA https://github.com/rust-lang/rust/pull/80889,MERGED,2021-01-10T21:44:40Z,2021-01-11T17:40:52Z,Do not query the HIR directly in `opt_associated_item`.,cjgillot,6526e5c772f2da07db745c94ca6bb0a591a39ba4,1,Auto merge of #80889 - cjgillot:asa r=oli-obk Do not query the HIR directly in `opt_associated_item`. Papercut found by `@Aaron1011.`,HEART,2021-01-10T21:46:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80889,MERGED,2021-01-10T21:44:40Z,2021-01-11T17:40:52Z,Do not query the HIR directly in `opt_associated_item`.,cjgillot,6526e5c772f2da07db745c94ca6bb0a591a39ba4,1,Auto merge of #80889 - cjgillot:asa r=oli-obk Do not query the HIR directly in `opt_associated_item`. Papercut found by `@Aaron1011.`,HEART,2021-01-10T22:03:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/80897,MERGED,2021-01-11T02:14:55Z,2021-01-12T11:20:38Z,driver: Use `atty` instead of rolling our own,camelid,d682a6834d712dff3b9da219f6b2d3a68f0a22fd,3,Rollup merge of #80897 - camelid:atty r=jyn514 driver: Use `atty` instead of rolling our own Fixes #80888. Rationale: - `atty` is widely used in the Rust ecosystem - We already use it (in `rustc_errors` and other places) - We shouldn't be rolling our own TTY detector when there's a widely-used well-tested package that we can use,THUMBS_UP,2021-01-11T13:10:54Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-01-12T09:10:55Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-02-22T18:49:47Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-07T12:32:16Z,zeenix,zeeshanak@gnome.org https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-07T15:44:36Z,ttys3,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-07T19:04:41Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-07T20:38:47Z,yerke,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),ROCKET,2021-07-07T20:38:50Z,yerke,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),HOORAY,2021-07-07T20:38:52Z,yerke,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-07T21:16:00Z,dmilith,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),THUMBS_UP,2021-07-15T18:30:23Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),HOORAY,2021-07-15T18:30:24Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80918,MERGED,2021-01-11T17:01:20Z,2021-07-07T06:12:17Z,Add Integer::log variants,yoshuawuyts,9bbc470e9779436d787ccda9924826176030b714,6,Rollup merge of #80918 - yoshuawuyts:int-log2 r=m-ou-se Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835 which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- This implements `{log log2 log10}` methods for all integer types. The implementation was provided by `@substack` for use in the stdlib. _Note: I'm not big on math so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [`@substack ` 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number but I didn't see any precedent for that. I also didn't know where to best place the tests so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf),ROCKET,2021-07-15T18:30:24Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80945,MERGED,2021-01-12T14:13:51Z,2021-01-31T05:58:23Z,Add Box::downcast() for dyn Any + Send + Sync,sdroege,caf2c0652a2aa2db136abcc0a37c85bfb254e2cb,1,Rollup merge of #80945 - sdroege:downcast-send-sync r=m-ou-se Add Box::downcast() for dyn Any + Send + Sync Looks like a plain omission but unfortunately I just needed that in my code :),THUMBS_UP,2021-01-28T06:04:01Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/80945,MERGED,2021-01-12T14:13:51Z,2021-01-31T05:58:23Z,Add Box::downcast() for dyn Any + Send + Sync,sdroege,caf2c0652a2aa2db136abcc0a37c85bfb254e2cb,1,Rollup merge of #80945 - sdroege:downcast-send-sync r=m-ou-se Add Box::downcast() for dyn Any + Send + Sync Looks like a plain omission but unfortunately I just needed that in my code :),THUMBS_UP,2021-01-29T02:52:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80952,CLOSED,2021-01-12T18:01:46Z,2021-01-16T03:27:22Z,Add `x.py check --stage 1`,jyn514,NA,NA,NA,ROCKET,2021-01-12T18:42:05Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/80958,MERGED,2021-01-12T23:41:26Z,2021-01-21T12:18:37Z,Deprecate-in-future the constants superceded by RFC 2700,bstrie,339e19697a39a78f4d669c217b7d21109215de41,26,"Auto merge of #80958 - bstrie:deptbdnums r=KodrAus Deprecate-in-future the constants superceded by RFC 2700 Successor to #78335 re-opened after addressing the issues tracked in #68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since=""TBD""` see #78381). We might call this *soft deprecation*; unlike with deprecation users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically the libs team has already agreed that they should be deprecated (see https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696).",THUMBS_UP,2021-01-13T01:19:51Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,THUMBS_UP,2021-01-14T17:41:01Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,THUMBS_UP,2021-01-22T10:37:33Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,THUMBS_UP,2021-01-22T17:53:10Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,HEART,2021-01-30T15:49:50Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,THUMBS_UP,2021-03-24T12:43:34Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,HEART,2021-05-03T08:04:01Z,Zhormos,NA https://github.com/rust-lang/rust/pull/80959,MERGED,2021-01-13T01:16:53Z,2021-01-30T13:58:13Z,Stabilize `unsigned_abs`,jhpratt,91ea1cbc177e3ed460c5435092d1cc07e4423428,6,Rollup merge of #80959 - jhpratt:unsigned_abs-stabilization r=m-ou-se Stabilize `unsigned_abs` Resolves #74913. This PR stabilizes the `i*::unsigned_abs()` method which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`. I have gone ahead and used this in a couple locations throughout the repository.,THUMBS_UP,2021-07-11T20:05:37Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-01-28T15:25:04Z,DianaNites,NA https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-01-29T02:51:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-01-30T08:12:26Z,yerke,NA https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-02-04T08:01:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-02-04T09:23:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-02-04T09:49:31Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/80962,MERGED,2021-01-13T02:41:13Z,2021-02-08T07:56:05Z,Stabilize remaining integer methods as `const fn`,jhpratt,4940dd483a8448c0f1ef28d304fad88a9d983c4e,5,Auto merge of #80962 - jhpratt:const_int_fn-stabilization r=dtolnay Stabilize remaining integer methods as `const fn` This pull request stabilizes the following methods as `const fn`: - `i*::checked_div` - `i*::checked_div_euclid` - `i*::checked_rem` - `i*::checked_rem_euclid` - `i*::div_euclid` - `i*::overflowing_div` - `i*::overflowing_div_euclid` - `i*::overflowing_rem` - `i*::overflowing_rem_euclid` - `i*::rem_euclid` - `i*::wrapping_div` - `i*::wrapping_div_euclid` - `i*::wrapping_rem` - `i*::wrapping_rem_euclid` - `u*::checked_div` - `u*::checked_div_euclid` - `u*::checked_rem` - `u*::checked_rem_euclid` - `u*::div_euclid` - `u*::overflowing_div` - `u*::overflowing_div_euclid` - `u*::overflowing_rem` - `u*::overflowing_rem_euclid` - `u*::rem_euclid` - `u*::wrapping_div` - `u*::wrapping_div_euclid` - `u*::wrapping_rem` - `u*::wrapping_rem_euclid` These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below it seems best practice is to stabilize the intrinsics. As such `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable. I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such I believe these methods are ready to be stabilized as `const fn`. This pull request represents the final methods mentioned in #53718. As such this PR closes #53718. `@rustbot` modify labels to +A-const-fn +T-libs,HOORAY,2021-02-08T08:00:59Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/80969,MERGED,2021-01-13T04:55:32Z,2021-01-14T23:07:35Z,Use better ICE message when no MIR is available,camelid,90cc815829acacc1ccb831db4134ef3198cbb3b7,1,Rollup merge of #80969 - camelid:monomorph-ice-msg r=nagisa Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong not what it was trying to do when it failed. cc https://github.com/rust-lang/rust/pull/80952#issuecomment-759198841 cc `````@jyn514`````,HEART,2021-01-13T05:07:43Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/80971,MERGED,2021-01-13T04:59:30Z,2021-01-16T23:15:42Z,Put all feature gate tests under `feature-gates/`,camelid,4a48651b0e9503d1146ba39ebc7da76ce18d7376,3,Rollup merge of #80971 - camelid:feature-gate-testsuite-organization r=Mark-Simulacrum Put all feature gate tests under `feature-gates/` There was one directory that had only a single test and there was also a test in the top-level directory. This moves both of them to `feature-gates/`.,HEART,2021-01-13T06:04:43Z,Havvy,NA https://github.com/rust-lang/rust/pull/80971,MERGED,2021-01-13T04:59:30Z,2021-01-16T23:15:42Z,Put all feature gate tests under `feature-gates/`,camelid,4a48651b0e9503d1146ba39ebc7da76ce18d7376,3,Rollup merge of #80971 - camelid:feature-gate-testsuite-organization r=Mark-Simulacrum Put all feature gate tests under `feature-gates/` There was one directory that had only a single test and there was also a test in the top-level directory. This moves both of them to `feature-gates/`.,HEART,2021-01-15T14:27:54Z,rylev,NA https://github.com/rust-lang/rust/pull/80973,MERGED,2021-01-13T05:39:26Z,2021-01-14T23:07:35Z,Update books,ehuss,3fe37c383076464a929a01792c631f8d188830e6,5,"Rollup merge of #80973 - ehuss:update-books r=ehuss Update books ## nomicon 2 commits in a5a48441d411f61556b57d762b03d6874afe575d..a8584998eacdea7106a1dfafcbf6c1c06fcdf925 2020-12-06 10:39:41 +0900 to 2021-01-06 12:49:49 -0500 - Update vector code examples - Remove outdated information about `jemalloc` ## reference 13 commits in b278478b766178491a8b6f67afa4bcd6b64d977a..50af691f838937c300b47812d0507c6d88c14f97 2020-12-21 18:18:03 -0800 to 2021-01-12 21:19:20 -0800 - Update grammar for parser unification. (rust-lang/reference#927) - Define constraining an implementation (rust-lang/reference#928) - Document extra behavior of #[no_mangle] (rust-lang/reference#930) - Add a float examle without a `.`. (rust-lang/reference#929) - Add more details about const generics. (rust-lang/reference#921) - Fix footnotes. (rust-lang/reference#926) - Add ""Logic errors"" as behavior not considered unsafe (rust-lang/reference#919) - Update grammar for order of parameters/arguments. (rust-lang/reference#920) - Fix formatting in the tuple section (rust-lang/reference#923) - document const generics (rust-lang/reference#901) - Update mdbook (rust-lang/reference#918) - linkage.md: update link to FFI section of the Book. (rust-lang/reference#917) - Document array expression with a const. (rust-lang/reference#914) ## book 8 commits in 5bb44f8b5b0aa105c8b22602e9b18800484afa21..ac57a0ddd23d173b26731ccf939f3ba729753275 2020-12-18 20:07:31 -0500 to 2021-01-09 14:18:45 -0500 - Update version of mdbook we're testing with to 0.4.5 (rust-lang/book#2561) - Fix grammar in ch13-01-closures.md (rust-lang/book#2534) - Merge remote-tracking branch 'origin/pr/2527' - Clarify code example ch6.3 (rust-lang/book#2485) - Fix link added in rust-lang/book#2495 to be relative and at the bottom - Merge remote-tracking branch 'origin/pr/2495' - Update output to match the updated poem punctuation - Fix rust-lang/book#2539 - Remove fancy apostrophes from poem for Windows ## rust-by-example 3 commits in 1cce0737d6a7d3ceafb139b4a206861fb1dcb2ab..03e23af01f0b4f83a3a513da280e1ca92587f2ec 2020-12-21 17:36:29 -0300 to 2021-01-09 10:20:28 -0300 - Replace for loop with iteration (rust-lang/rust-by-example#1404) - Update mdbook (rust-lang/rust-by-example#1402) - Add note for match guards to include catch-all (rust-lang/rust-by-example#1401) ## embedded-book 1 commits in ba34b8a968f9531d38c4dc4411d5568b7c076bfe..ceec19e873be87c6ee5666b030c6bb612f889a96 2020-11-17 00:20:43 +0000 to 2021-01-03 13:13:10 +0000 - book.toml: add link to GitHub repo (rust-embedded/book#276)",HEART,2021-01-13T05:41:12Z,Havvy,NA https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,THUMBS_UP,2021-01-13T13:06:54Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,THUMBS_UP,2021-01-16T13:50:35Z,tesuji,NA https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,HEART,2021-01-16T23:06:55Z,scottmcm,NA https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,THUMBS_UP,2021-01-17T20:52:20Z,0xpr03,NA https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,THUMBS_UP,2021-02-07T05:04:30Z,Folyd,NA https://github.com/rust-lang/rust/pull/80979,CLOSED,2021-01-13T10:18:17Z,2021-10-19T03:30:46Z,Improved documentation of Path::exists,Kixunil,NA,NA,NA,THUMBS_UP,2021-07-18T10:28:39Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/80981,MERGED,2021-01-13T11:17:57Z,2021-01-14T23:07:35Z,Fix -Cpasses=list and llvm version print with -vV,bjorn3,ce3bc76a8662727c70e4894d8e49c4689505d7bc,1,Rollup merge of #80981 - bjorn3:bjorn3-patch-1 r=jonas-schievink Fix -Cpasses=list and llvm version print with -vV cc https://github.com/rust-lang/rust/pull/77975#issuecomment-759362933,THUMBS_UP,2021-01-13T12:08:34Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/81012,MERGED,2021-01-14T14:41:20Z,2021-02-13T05:38:05Z,Stabilize the partition_point feature,VillSnow,8280abc57b50a08b42cbfec39e6a6840f466c33c,2,Rollup merge of #81012 - VillSnow:stabilize_partition_point r=matklad Stabilize the partition_point feature Stabilize the partition_point feature. Tracking Issue: #73831 First PR: #73577,HEART,2021-01-23T12:54:42Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/81012,MERGED,2021-01-14T14:41:20Z,2021-02-13T05:38:05Z,Stabilize the partition_point feature,VillSnow,8280abc57b50a08b42cbfec39e6a6840f466c33c,2,Rollup merge of #81012 - VillSnow:stabilize_partition_point r=matklad Stabilize the partition_point feature Stabilize the partition_point feature. Tracking Issue: #73831 First PR: #73577,HEART,2021-02-19T16:02:32Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81027,MERGED,2021-01-15T00:54:38Z,2021-01-15T04:58:02Z,Update RLS and Rustfmt,Xanewok,3419da89aaaa678f680032fef9764e875aa06026,3,Auto merge of #81027 - Xanewok:update-rls r=calebcartwright Update RLS and Rustfmt Fixes #80576 Updates Rustfmt to use `rustfmt-v1.4.31` branch. Both are updated (along with `racer`) in tandem to pull in the exact same version of rustc-ap-* libraries. r? `@calebcartwright`,THUMBS_UP,2021-01-15T02:09:57Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/81042,MERGED,2021-01-15T13:37:36Z,2021-01-19T02:55:00Z,Add suggestion for impl_candidates with E0283,sasurau4,4ba1aaf35f1ad55ddd094ab751f62dcf227a3185,6,Auto merge of #81042 - sasurau4:fix/unclear-error-with-trait r=estebank Add suggestion for impl_candidates with E0283 Fix #42226,HEART,2021-02-16T08:17:32Z,cafca,mail@vincentahrend.com https://github.com/rust-lang/rust/pull/81046,MERGED,2021-01-15T17:07:23Z,2021-01-21T15:50:40Z,Improve unknown external crate error,rylev,a77c1d836aa669c7faed616d6b53e81cbe65f055,9,Rollup merge of #81046 - rylev:unknown-external-crate r=estebank Improve unknown external crate error This improves error messages when unknown items in the crate root are encountered. Fixes #63799 r? ```@estebank```,HEART,2021-01-15T21:19:55Z,estebank,NA https://github.com/rust-lang/rust/pull/81047,MERGED,2021-01-15T17:23:58Z,2021-04-07T20:18:35Z,Stabilize cmp_min_max_by,glittershark,ef2ef926a53baaa9d7a1b73b516d399af7e9aedb,3,Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by r=kodraus Stabilize cmp_min_max_by I would like to propose cmp::{min_by min_by_key max_by max_by_key} for stabilization. These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now. Closes: #64460,THUMBS_UP,2021-03-01T09:53:26Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/81047,MERGED,2021-01-15T17:23:58Z,2021-04-07T20:18:35Z,Stabilize cmp_min_max_by,glittershark,ef2ef926a53baaa9d7a1b73b516d399af7e9aedb,3,Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by r=kodraus Stabilize cmp_min_max_by I would like to propose cmp::{min_by min_by_key max_by max_by_key} for stabilization. These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now. Closes: #64460,THUMBS_UP,2021-03-28T15:17:43Z,nickmertin,nickmertin@gmail.com https://github.com/rust-lang/rust/pull/81047,MERGED,2021-01-15T17:23:58Z,2021-04-07T20:18:35Z,Stabilize cmp_min_max_by,glittershark,ef2ef926a53baaa9d7a1b73b516d399af7e9aedb,3,Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by r=kodraus Stabilize cmp_min_max_by I would like to propose cmp::{min_by min_by_key max_by max_by_key} for stabilization. These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now. Closes: #64460,THUMBS_UP,2021-04-02T00:14:45Z,b05902132,NA https://github.com/rust-lang/rust/pull/81047,MERGED,2021-01-15T17:23:58Z,2021-04-07T20:18:35Z,Stabilize cmp_min_max_by,glittershark,ef2ef926a53baaa9d7a1b73b516d399af7e9aedb,3,Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by r=kodraus Stabilize cmp_min_max_by I would like to propose cmp::{min_by min_by_key max_by max_by_key} for stabilization. These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now. Closes: #64460,THUMBS_UP,2021-04-02T15:06:34Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81047,MERGED,2021-01-15T17:23:58Z,2021-04-07T20:18:35Z,Stabilize cmp_min_max_by,glittershark,ef2ef926a53baaa9d7a1b73b516d399af7e9aedb,3,Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by r=kodraus Stabilize cmp_min_max_by I would like to propose cmp::{min_by min_by_key max_by max_by_key} for stabilization. These are relatively simple and seemingly uncontroversial functions and have been unchanged in unstable for a while now. Closes: #64460,THUMBS_UP,2021-05-16T16:18:48Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-01-15T18:36:58Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-01-15T18:47:22Z,rrbutani,NA https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-01-16T13:04:24Z,dignifiedquire,NA https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-01-23T13:50:01Z,SabrinaJewson,NA https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-02-02T01:28:14Z,tmandry,NA https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-06-14T11:08:05Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/81050,MERGED,2021-01-15T18:31:33Z,2021-07-29T00:31:13Z,Stabilize core::task::ready!,yoshuawuyts,fef1725c0f60616e62b75342ce96412748544725,3,Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready r=m-ou-se Stabilize core::task::ready! _Tracking issue: https://github.com/rust-lang/rust/issues/70922_ This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886 this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed. The `task::ready!` API has existed in the futures ecosystem for several years and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library. r? ``@tmandry`` cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs`` ## Example ```rust use core::task::{Context Poll}; use core::future::Future; use core::pin::Pin; async fn get_num() -> usize { 42 } pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> { let mut f = get_num(); let f = unsafe { Pin::new_unchecked(&mut f) }; let num = ready!(f.poll(cx)); // ... use num Poll::Ready(()) } ```,HEART,2021-08-05T15:11:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81056,CLOSED,2021-01-15T22:24:57Z,2021-04-16T22:20:53Z,Query-ify needs_gdb_debug_scripts_section,Aaron1011,NA,NA,NA,THUMBS_UP,2021-01-15T23:25:29Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81056,CLOSED,2021-01-15T22:24:57Z,2021-04-16T22:20:53Z,Query-ify needs_gdb_debug_scripts_section,Aaron1011,NA,NA,NA,HEART,2021-01-16T00:37:19Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/81056,CLOSED,2021-01-15T22:24:57Z,2021-04-16T22:20:53Z,Query-ify needs_gdb_debug_scripts_section,Aaron1011,NA,NA,NA,HEART,2021-01-16T08:52:57Z,tmiasko,NA https://github.com/rust-lang/rust/pull/81056,CLOSED,2021-01-15T22:24:57Z,2021-04-16T22:20:53Z,Query-ify needs_gdb_debug_scripts_section,Aaron1011,NA,NA,NA,HEART,2021-01-29T22:43:18Z,bugadani,NA https://github.com/rust-lang/rust/pull/81063,MERGED,2021-01-16T01:38:53Z,2021-01-20T07:15:54Z,Add JsonDocCk Tool for rustdoc-json,CraftSpider,e05409a02c6e73a3dea6da98798468db2910ca59,24,Auto merge of #81063 - CraftSpider:jsondocck r=jyn514 Add JsonDocCk Tool for rustdoc-json Implements a new test system for rustdoc JSON output jsondocck. Modeled after htmldocck this tool reads directives in the test file and checks them against the output. These directives use JSONPath a pair to XPath for json. This obsoletes the old strict subset tool allowing both finer-grained control of what is tested and better errors on failure. Not sure on the changes to Cargo.lock I can back that out if needed. r? `@jyn514`,HEART,2021-01-17T00:09:46Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/81063,MERGED,2021-01-16T01:38:53Z,2021-01-20T07:15:54Z,Add JsonDocCk Tool for rustdoc-json,CraftSpider,e05409a02c6e73a3dea6da98798468db2910ca59,24,Auto merge of #81063 - CraftSpider:jsondocck r=jyn514 Add JsonDocCk Tool for rustdoc-json Implements a new test system for rustdoc JSON output jsondocck. Modeled after htmldocck this tool reads directives in the test file and checks them against the output. These directives use JSONPath a pair to XPath for json. This obsoletes the old strict subset tool allowing both finer-grained control of what is tested and better errors on failure. Not sure on the changes to Cargo.lock I can back that out if needed. r? `@jyn514`,HOORAY,2021-01-17T21:15:01Z,rrbutani,NA https://github.com/rust-lang/rust/pull/81063,MERGED,2021-01-16T01:38:53Z,2021-01-20T07:15:54Z,Add JsonDocCk Tool for rustdoc-json,CraftSpider,e05409a02c6e73a3dea6da98798468db2910ca59,24,Auto merge of #81063 - CraftSpider:jsondocck r=jyn514 Add JsonDocCk Tool for rustdoc-json Implements a new test system for rustdoc JSON output jsondocck. Modeled after htmldocck this tool reads directives in the test file and checks them against the output. These directives use JSONPath a pair to XPath for json. This obsoletes the old strict subset tool allowing both finer-grained control of what is tested and better errors on failure. Not sure on the changes to Cargo.lock I can back that out if needed. r? `@jyn514`,HOORAY,2021-01-17T22:46:25Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/81063,MERGED,2021-01-16T01:38:53Z,2021-01-20T07:15:54Z,Add JsonDocCk Tool for rustdoc-json,CraftSpider,e05409a02c6e73a3dea6da98798468db2910ca59,24,Auto merge of #81063 - CraftSpider:jsondocck r=jyn514 Add JsonDocCk Tool for rustdoc-json Implements a new test system for rustdoc JSON output jsondocck. Modeled after htmldocck this tool reads directives in the test file and checks them against the output. These directives use JSONPath a pair to XPath for json. This obsoletes the old strict subset tool allowing both finer-grained control of what is tested and better errors on failure. Not sure on the changes to Cargo.lock I can back that out if needed. r? `@jyn514`,HEART,2021-01-17T22:46:27Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/81064,MERGED,2021-01-16T03:09:45Z,2021-01-17T17:51:51Z,Support non-stage0 check,Mark-Simulacrum,92dbfb541a2ab1cef3c680fe54c14e6bbc1f43f6,3,Rollup merge of #81064 - Mark-Simulacrum:support-stage1-check r=jyn514 Support non-stage0 check Seems to work locally - a full stage 1 check succeeds building std (because we can't get away with checking it) and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why but it doesn't seem worth digging in in too much detail). Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g. compiler/rustc) explicitly. r? ```@jyn514```,HEART,2021-01-16T14:59:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81076,CLOSED,2021-01-16T12:49:29Z,2021-01-16T13:41:46Z,Rc: try to avoid copying vector,bugadani,NA,NA,NA,THUMBS_UP,2021-01-16T13:33:25Z,marmeladema,NA https://github.com/rust-lang/rust/pull/81079,CLOSED,2021-01-16T13:50:41Z,2021-01-19T08:50:58Z,Try MIR inlining leaf functions by default,tmiasko,NA,NA,NA,HEART,2021-01-16T18:38:09Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/81079,CLOSED,2021-01-16T13:50:41Z,2021-01-19T08:50:58Z,Try MIR inlining leaf functions by default,tmiasko,NA,NA,NA,HEART,2021-01-18T23:24:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81080,MERGED,2021-01-16T15:35:50Z,2021-01-17T17:51:51Z,Force vec![] to expression position only,bugadani,19370a486057b1bc7c7911c869640f3bf8d7977d,9,Rollup merge of #81080 - bugadani:vec-diag r=oli-obk m-ou-se Force vec![] to expression position only r? `@oli-obk` I went with the lazy way of only changing what broke. I moved the test to ui/macros because the diagnostics no longer give suggestions. Closes #61933,HEART,2021-01-16T17:55:19Z,estebank,NA https://github.com/rust-lang/rust/pull/81095,MERGED,2021-01-16T19:19:45Z,2021-01-17T17:51:51Z,Use Option::unwrap_or instead of open-coding it,LingMan,7e2425ab73b40f042975a0911a976220bf62d083,1,Rollup merge of #81095 - LingMan:unwrap r=oli-obk Use Option::unwrap_or instead of open-coding it r? ```@oli-obk``` Noticed this while we were talking about the other PR just now 😆 ```@rustbot``` modify labels +C-cleanup +T-compiler,LAUGH,2021-01-16T19:23:22Z,oli-obk,NA https://github.com/rust-lang/rust/pull/81095,MERGED,2021-01-16T19:19:45Z,2021-01-17T17:51:51Z,Use Option::unwrap_or instead of open-coding it,LingMan,7e2425ab73b40f042975a0911a976220bf62d083,1,Rollup merge of #81095 - LingMan:unwrap r=oli-obk Use Option::unwrap_or instead of open-coding it r? ```@oli-obk``` Noticed this while we were talking about the other PR just now 😆 ```@rustbot``` modify labels +C-cleanup +T-compiler,THUMBS_UP,2021-01-16T19:23:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/81107,MERGED,2021-01-17T03:36:18Z,2021-01-17T17:51:51Z,Add NonZeroUn::is_power_of_two,scottmcm,801684620bd4e0bc12b98a071851e3d3064429e4,1,Rollup merge of #81107 - scottmcm:nonzero-is_power_of_two r=kennytm Add NonZeroUn::is_power_of_two This saves instructions on both new and old machines - On the default x64 target (with no fancy instructions available) it saves a few instructions by not needing to also check for zero. - On newer targets (with BMI1) it uses `BLSR` for super-short assembly. This can be used for things like checks against alignments stored in `NonZeroUsize`.,THUMBS_UP,2021-01-17T19:37:52Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/81107,MERGED,2021-01-17T03:36:18Z,2021-01-17T17:51:51Z,Add NonZeroUn::is_power_of_two,scottmcm,801684620bd4e0bc12b98a071851e3d3064429e4,1,Rollup merge of #81107 - scottmcm:nonzero-is_power_of_two r=kennytm Add NonZeroUn::is_power_of_two This saves instructions on both new and old machines - On the default x64 target (with no fancy instructions available) it saves a few instructions by not needing to also check for zero. - On newer targets (with BMI1) it uses `BLSR` for super-short assembly. This can be used for things like checks against alignments stored in `NonZeroUsize`.,EYES,2021-05-31T05:18:07Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-01-24T10:07:12Z,bluss,NA https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-02-19T06:31:11Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-02-19T15:33:44Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-02-19T18:04:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-02-21T01:17:00Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/81126,MERGED,2021-01-17T17:54:02Z,2021-02-11T07:50:05Z,Optimize Vec::retain,oxalica,1efd8049837aec86f21da1486e8a459a7efd7806,2,Auto merge of #81126 - oxalica:retain-early-drop r=m-ou-se Optimize Vec::retain Use `copy_non_overlapping` instead of `swap` to reduce memory writes like what we've done in #44355 and `String::retain`. #48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`. This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop small-need-drop large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail. I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic the new implementation should be almost always faster than current one. I'm not sure if we should leak on panic since there is indeed an issue (#52267) complains about it before.,HEART,2021-02-24T01:42:52Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/81140,CLOSED,2021-01-17T23:35:19Z,2021-01-21T07:16:24Z,[Experiment] Box the biggest TerminatorKind variants,bugadani,NA,NA,NA,THUMBS_UP,2021-01-17T23:36:44Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81149,MERGED,2021-01-18T01:58:40Z,2021-01-28T15:19:20Z,Avoid describing a method as 'not found' when bounds are unsatisfied,Aaron1011,643a79af3d5a31fa87c8a4c9d7f8bc4ebe2add4b,47,"Auto merge of #81149 - Aaron1011:feature/better-no-method-found-err r=estebank Avoid describing a method as 'not found' when bounds are unsatisfied Fixes #76267 When there is a single applicable method candidate but its trait bounds are not satisfied we avoid saying that the method is ""not found"". Insted we update the error message to directly mention which bounds are not satisfied rather than mentioning them in a note.",THUMBS_UP,2021-01-18T21:14:53Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/81149,MERGED,2021-01-18T01:58:40Z,2021-01-28T15:19:20Z,Avoid describing a method as 'not found' when bounds are unsatisfied,Aaron1011,643a79af3d5a31fa87c8a4c9d7f8bc4ebe2add4b,47,"Auto merge of #81149 - Aaron1011:feature/better-no-method-found-err r=estebank Avoid describing a method as 'not found' when bounds are unsatisfied Fixes #76267 When there is a single applicable method candidate but its trait bounds are not satisfied we avoid saying that the method is ""not found"". Insted we update the error message to directly mention which bounds are not satisfied rather than mentioning them in a note.",THUMBS_UP,2021-01-20T18:35:44Z,Pratyush,NA https://github.com/rust-lang/rust/pull/81149,MERGED,2021-01-18T01:58:40Z,2021-01-28T15:19:20Z,Avoid describing a method as 'not found' when bounds are unsatisfied,Aaron1011,643a79af3d5a31fa87c8a4c9d7f8bc4ebe2add4b,47,"Auto merge of #81149 - Aaron1011:feature/better-no-method-found-err r=estebank Avoid describing a method as 'not found' when bounds are unsatisfied Fixes #76267 When there is a single applicable method candidate but its trait bounds are not satisfied we avoid saying that the method is ""not found"". Insted we update the error message to directly mention which bounds are not satisfied rather than mentioning them in a note.",HOORAY,2021-02-01T14:51:56Z,fmease,NA https://github.com/rust-lang/rust/pull/81152,MERGED,2021-01-18T03:07:48Z,2021-01-22T00:01:59Z,Fix intersperse_fold,tesuji,202720bf483088dbdb343f78c0aa77067fdd8156,2,Auto merge of #81152 - lzutao:intersperse_fold r=m-ou-se Fix intersperse_fold Here is a standalone playground link in case anybody wants to modify code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=626b4d044fb74f044a36098ad907e40f Fixes #81145 cc #79479 `@jonas-schievink`,THUMBS_UP,2021-01-18T03:15:08Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-08-12T13:34:54Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-11-14T06:44:02Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-11-14T06:51:34Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-12-01T00:06:00Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-12-08T07:45:24Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HOORAY,2021-12-09T13:01:16Z,hkratz,NA https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2021-12-09T13:08:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HOORAY,2021-12-09T13:08:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HOORAY,2021-12-09T17:34:40Z,RalfJung,NA https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HOORAY,2021-12-12T12:43:37Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HEART,2021-12-17T07:51:21Z,iago-lito,NA https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HEART,2021-12-17T16:39:10Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,HOORAY,2021-12-19T04:57:06Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/81156,MERGED,2021-01-18T05:48:25Z,2021-12-09T12:57:34Z,Implement most of RFC 2930 providing the ReadBuf abstraction,DrMeepster,3b263ceb5cb89b6d53b5a03b47ec447c3a7f7765,25,Auto merge of #81156 - DrMeepster:read_buf r=joshtriplett Implement most of RFC 2930 providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788 by removing the relevant APIs.,THUMBS_UP,2022-02-24T10:35:13Z,gustav3d,NA https://github.com/rust-lang/rust/pull/81158,MERGED,2021-01-18T08:10:08Z,2021-01-29T04:06:41Z,Point to span of upvar making closure FnMut,1000teslas,4283623bc0ccc8a7b71e54bb068bfb3b7d80d80d,13,Rollup merge of #81158 - 1000teslas:issue-80313-fix r=Aaron1011 Point to span of upvar making closure FnMut For #80313.,THUMBS_UP,2021-01-18T17:45:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81167,MERGED,2021-01-18T13:26:11Z,2021-02-25T18:14:55Z,Make ptr::write const,usbalbin,4b9c213d6fb4d67ac6c28262d2d81e42228a74d3,6,Rollup merge of #81167 - usbalbin:const_write r=oli-obk Make ptr::write const ~~The code in this PR as of right now is not much more than an experiment.~~ ~~This should if I am not mistaken in theory compile and pass the tests once the bootstraping compiler is updated. Thus the PR is blocked on that which should happen some time after the February the 9th. Also we might want to wait for #79989 to avoid regressing performance due to using `mem::forget` over `intrinsics::forget`~~.,THUMBS_UP,2021-01-19T22:03:15Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/81170,MERGED,2021-01-18T16:57:10Z,2021-01-24T00:10:18Z,Avoid hash_slice in VecDeque's Hash implementation,xfix,05a95a43726ff741339205ed4e3fcc0b9b39d415,2,Rollup merge of #81170 - xfix:vecdeque-bug-fix r=sfackler Avoid hash_slice in VecDeque's Hash implementation Fixes #80303.,THUMBS_UP,2021-01-20T02:01:55Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-18T19:48:32Z,RustyYato,NA https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-18T20:01:11Z,Restioson,restiosondev@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-18T20:10:28Z,peterjoel,peterjoel@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-18T20:33:08Z,cjgillot,NA https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-19T09:26:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,HOORAY,2021-01-19T10:14:53Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-20T00:39:49Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-22T09:04:27Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,HOORAY,2021-01-29T14:50:58Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,THUMBS_UP,2021-01-30T02:36:28Z,mzji,NA https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,HOORAY,2021-01-30T02:36:29Z,mzji,NA https://github.com/rust-lang/rust/pull/81172,MERGED,2021-01-18T19:24:46Z,2021-02-18T07:22:36Z,Implement RFC 2580: Pointer metadata & VTable,SimonSapin,d1462d8558cf4551608457f63d9b999185ebf3bf,24,Auto merge of #81172 - SimonSapin:ptr-metadata r=oli-obk Implement RFC 2580: Pointer metadata & VTable RFC: https://github.com/rust-lang/rfcs/pull/2580 ~~Before merging this PR:~~ * [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278). * [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513 * [x] Update `#[unstable]` attributes in the PR with the tracking issue number ---- This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts parameters can be assumed to implement it without a corresponding bound. For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals so careful review is appreciated. This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`: ```rust pub trait Pointee { /// One of `()` `usize` or `DynMetadata` type Metadata: Copy + Send + Sync + Ord + Hash + Unpin; } pub trait Thin = Pointee; pub const fn metadata(ptr: *const T) -> ::Metadata {} pub const fn from_raw_parts(*const () ::Metadata) -> *const T {} pub const fn from_raw_parts_mut(*mut () ::Metadata) -> *mut T {} impl NonNull { pub const fn from_raw_parts(NonNull<()> ::Metadata) -> NonNull {} /// Convenience for `(ptr.cast() metadata(ptr))` pub const fn to_raw_parts(self) -> (NonNull<()> ::Metadata) {} } impl *const T { pub const fn to_raw_parts(self) -> (*const () ::Metadata) {} } impl *mut T { pub const fn to_raw_parts(self) -> (*mut () ::Metadata) {} } /// `::Metadata == DynMetadata` pub struct DynMetadata { // Private pointer to vtable } impl DynMetadata { pub fn size_of(self) -> usize {} pub fn align_of(self) -> usize {} pub fn layout(self) -> crate::alloc::Layout {} } unsafe impl Send for DynMetadata {} unsafe impl Sync for DynMetadata {} impl Debug for DynMetadata {} impl Unpin for DynMetadata {} impl Copy for DynMetadata {} impl Clone for DynMetadata {} impl Eq for DynMetadata {} impl PartialEq for DynMetadata {} impl Ord for DynMetadata {} impl PartialOrd for DynMetadata {} impl Hash for DynMetadata {} ``` API differences from the RFC in areas noted as unresolved questions in the RFC: * Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T` following the precedent of `null` `slice_from_raw_parts` etc. * Added `to_raw_parts`,HOORAY,2021-02-02T01:41:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81176,MERGED,2021-01-18T20:56:38Z,2021-01-29T04:06:41Z,Improve safety of `LateContext::qpath_res`,camsteffen,0c5fccea22f5ead38b4c9521c77af93ddcb55bff,16,Rollup merge of #81176 - camsteffen:qpath-res r=oli-obk Improve safety of `LateContext::qpath_res` This is my first rustc code change inspired by hacking on clippy! The first change is to clear cached `TypeckResults` from `LateContext` when visiting a nested item. I took a hint from [here](https://github.com/rust-lang/rust/blob/5e91c4ecc09312d8b63d250a432b0f3ef83f1df7/compiler/rustc_privacy/src/lib.rs#L1300). Clippy has a `qpath_res` util function to avoid a possible ICE in `LateContext::qpath_res`. But the docs of `LateContext::qpath_res` promise no ICE. So this updates the `LateContext` method to keep its promises and removes the util function. Related: rust-lang/rust-clippy#4545 CC ````````````@eddyb```````````` since you've done related work CC ````````````@flip1995```````````` FYI,HEART,2021-01-19T20:28:19Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/81197,CLOSED,2021-01-19T21:37:53Z,2021-04-23T13:54:19Z,Fix flaky test,jyn514,NA,NA,NA,HEART,2021-01-21T00:18:43Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/81198,MERGED,2021-01-19T22:36:14Z,2021-01-31T05:58:23Z,Remove requirement that forces symmetric and transitive PartialEq impls to exist,dtolnay,13b3294e91664fa039a9999f37f16a2494c72078,1,Rollup merge of #81198 - dtolnay:partialeq r=m-ou-se Remove requirement that forces symmetric and transitive PartialEq impls to exist ### Counterexample of symmetry: If you [have](https://docs.rs/proc-macro2/1.0.24/proc_macro2/struct.Ident.html#impl-PartialEq%3CT%3E) an impl like: ```rust impl PartialEq for Ident where T: ?Sized + AsRef ``` then Rust will not even allow the symmetric impl to exist. ```console error[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Ident`) --> src/main.rs:9:6 | 9 | impl PartialEq for T where T: ?Sized + AsRef { | ^ type parameter `T` must be covered by another type when it appears before the first local type (`Ident`) | = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local and no uncovered type parameters appear before that first local type = note: in this case 'before' refers to the following order: `impl<..> ForeignTrait for T0` where `T0` is the first and `Tn` is the last ```
### Counterexample of transitivity: Consider these two existing impls from `regex` and `clap`: ```rust // regex /// An inline representation of `Option`. pub struct Char(u32); impl PartialEq for Char { fn eq(&self other: &char) -> bool { self.0 == *other as u32 } } ``` ```rust // clap pub(crate) enum KeyType { Short(char) Long(OsString) Position(u64) } impl PartialEq for KeyType { fn eq(&self rhs: &char) -> bool { match self { KeyType::Short(c) => c == rhs _ => false } } } ``` It's nice to be able to add `PartialEq for char` in libproc_macro (https://github.com/rust-lang/rust/pull/80595) but it makes no sense to force an `impl PartialEq for Char` and `impl PartialEq for KeyType` in `regex` and `clap` in code that otherwise has nothing to do with proc macros.
`@rust-lang/libs`,THUMBS_UP,2021-01-29T03:46:02Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/81202,MERGED,2021-01-20T04:33:36Z,2021-01-22T19:00:18Z,Don't prefix 0x for each segments in `dbg!(Ipv6)`,tesuji,950ed27e8bb8952fce24afbaf19dd1afa5368f83,2,Rollup merge of #81202 - lzutao:dbg_ipv6 r=Amanieu Don't prefix 0x for each segments in `dbg!(Ipv6)` Fixes #81182,THUMBS_UP,2021-01-20T07:10:10Z,KSXGitHub,hvksmr1996@gmail.com https://github.com/rust-lang/rust/pull/81202,MERGED,2021-01-20T04:33:36Z,2021-01-22T19:00:18Z,Don't prefix 0x for each segments in `dbg!(Ipv6)`,tesuji,950ed27e8bb8952fce24afbaf19dd1afa5368f83,2,Rollup merge of #81202 - lzutao:dbg_ipv6 r=Amanieu Don't prefix 0x for each segments in `dbg!(Ipv6)` Fixes #81182,THUMBS_UP,2021-01-20T11:32:48Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/81213,CLOSED,2021-01-20T17:24:09Z,2021-03-21T12:54:38Z,Seal all extension traits,m-ou-se,NA,NA,NA,HEART,2021-01-21T13:21:15Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/81213,CLOSED,2021-01-20T17:24:09Z,2021-03-21T12:54:38Z,Seal all extension traits,m-ou-se,NA,NA,NA,HEART,2021-01-21T16:49:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81227,MERGED,2021-01-20T21:51:05Z,2021-01-22T19:00:18Z,Remove doctree::StructType,CraftSpider,2ceee724270f2186e5e85acff49acd35bf8a652a,7,Rollup merge of #81227 - CraftSpider:struct-type-clean r=jyn514 Remove doctree::StructType Also removes it from the Union type as unions can only ever be 'Plain'. Adds a new StructType to JSON 'union' as the easiest way to encode the type of a union there. This leaves only one item in doctree `Module`. r? `@jyn514`,HOORAY,2021-01-21T00:00:11Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/81235,MERGED,2021-01-21T03:38:29Z,2021-02-23T07:19:44Z,Improve suggestion for tuple struct pattern matching errors.,reese,8e51bd4315bad8456c6cabbfc338be97c17f3700,9,Rollup merge of #81235 - reese:rw-tuple-diagnostics r=estebank Improve suggestion for tuple struct pattern matching errors. Closes #80174 This change allows numbers to be parsed as field names when pattern matching on structs which allows us to provide better error messages when tuple structs are matched using a struct pattern. r? ``@estebank``,THUMBS_UP,2021-01-29T19:24:26Z,estebank,NA https://github.com/rust-lang/rust/pull/81235,MERGED,2021-01-21T03:38:29Z,2021-02-23T07:19:44Z,Improve suggestion for tuple struct pattern matching errors.,reese,8e51bd4315bad8456c6cabbfc338be97c17f3700,9,Rollup merge of #81235 - reese:rw-tuple-diagnostics r=estebank Improve suggestion for tuple struct pattern matching errors. Closes #80174 This change allows numbers to be parsed as field names when pattern matching on structs which allows us to provide better error messages when tuple structs are matched using a struct pattern. r? ``@estebank``,THUMBS_UP,2021-02-23T07:24:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/81236,MERGED,2021-01-21T05:06:25Z,2021-01-22T19:00:18Z,Gracefully handle loop labels missing leading `'` in different positions,estebank,3682a06dcff54a6b9188fd4395e26b316c7652f7,33,"Rollup merge of #81236 - estebank:everybody-loop-now r=oli-obk Gracefully handle loop labels missing leading `'` in different positions Fix #81192. * Account for labels when suggesting `loop` instead of `while true` * Suggest `'a` when given `a` only when appropriate * Add loop head span to hir * Tweak error for invalid `break expr` * Add more misspelled label tests * Avoid emitting redundant ""unused label"" lint * Parse loop labels missing a leading `'` Each commit can be reviewed in isolation.",HEART,2021-01-21T05:33:11Z,tesuji,NA https://github.com/rust-lang/rust/pull/81236,MERGED,2021-01-21T05:06:25Z,2021-01-22T19:00:18Z,Gracefully handle loop labels missing leading `'` in different positions,estebank,3682a06dcff54a6b9188fd4395e26b316c7652f7,33,"Rollup merge of #81236 - estebank:everybody-loop-now r=oli-obk Gracefully handle loop labels missing leading `'` in different positions Fix #81192. * Account for labels when suggesting `loop` instead of `while true` * Suggest `'a` when given `a` only when appropriate * Add loop head span to hir * Tweak error for invalid `break expr` * Add more misspelled label tests * Avoid emitting redundant ""unused label"" lint * Parse loop labels missing a leading `'` Each commit can be reviewed in isolation.",HEART,2021-01-21T09:33:56Z,oli-obk,NA https://github.com/rust-lang/rust/pull/81236,MERGED,2021-01-21T05:06:25Z,2021-01-22T19:00:18Z,Gracefully handle loop labels missing leading `'` in different positions,estebank,3682a06dcff54a6b9188fd4395e26b316c7652f7,33,"Rollup merge of #81236 - estebank:everybody-loop-now r=oli-obk Gracefully handle loop labels missing leading `'` in different positions Fix #81192. * Account for labels when suggesting `loop` instead of `while true` * Suggest `'a` when given `a` only when appropriate * Add loop head span to hir * Tweak error for invalid `break expr` * Add more misspelled label tests * Avoid emitting redundant ""unused label"" lint * Parse loop labels missing a leading `'` Each commit can be reviewed in isolation.",HEART,2021-01-29T02:44:21Z,GrayJack,NA https://github.com/rust-lang/rust/pull/81238,MERGED,2021-01-21T08:54:07Z,2021-02-13T23:27:50Z,directly expose copy and copy_nonoverlapping intrinsics,RalfJung,8e54a21139ae96a2aca3129100b057662e2799b9,4,Auto merge of #81238 - RalfJung:copy-intrinsics r=m-ou-se directly expose copy and copy_nonoverlapping intrinsics This effectively un-does https://github.com/rust-lang/rust/pull/57997. That should help with `ptr::read` codegen in debug builds (and any other of these low-level functions that bottoms out at `copy`/`copy_nonoverlapping`) where the wrapper function will not get inlined. See the discussion in https://github.com/rust-lang/rust/pull/80290 and https://github.com/rust-lang/rust/issues/81163. Cc `@bjorn3` `@therealprof`,HEART,2021-01-21T10:50:05Z,tmiasko,NA https://github.com/rust-lang/rust/pull/81238,MERGED,2021-01-21T08:54:07Z,2021-02-13T23:27:50Z,directly expose copy and copy_nonoverlapping intrinsics,RalfJung,8e54a21139ae96a2aca3129100b057662e2799b9,4,Auto merge of #81238 - RalfJung:copy-intrinsics r=m-ou-se directly expose copy and copy_nonoverlapping intrinsics This effectively un-does https://github.com/rust-lang/rust/pull/57997. That should help with `ptr::read` codegen in debug builds (and any other of these low-level functions that bottoms out at `copy`/`copy_nonoverlapping`) where the wrapper function will not get inlined. See the discussion in https://github.com/rust-lang/rust/pull/80290 and https://github.com/rust-lang/rust/issues/81163. Cc `@bjorn3` `@therealprof`,HEART,2021-01-21T11:53:37Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/81238,MERGED,2021-01-21T08:54:07Z,2021-02-13T23:27:50Z,directly expose copy and copy_nonoverlapping intrinsics,RalfJung,8e54a21139ae96a2aca3129100b057662e2799b9,4,Auto merge of #81238 - RalfJung:copy-intrinsics r=m-ou-se directly expose copy and copy_nonoverlapping intrinsics This effectively un-does https://github.com/rust-lang/rust/pull/57997. That should help with `ptr::read` codegen in debug builds (and any other of these low-level functions that bottoms out at `copy`/`copy_nonoverlapping`) where the wrapper function will not get inlined. See the discussion in https://github.com/rust-lang/rust/pull/80290 and https://github.com/rust-lang/rust/issues/81163. Cc `@bjorn3` `@therealprof`,HEART,2021-02-16T18:17:44Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/81244,CLOSED,2021-01-21T18:06:43Z,2021-03-09T18:27:55Z,Update BARE_TRAIT_OBJECTS lint to deny in 2021 edition,rylev,NA,NA,NA,THUMBS_UP,2021-01-21T20:36:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81244,CLOSED,2021-01-21T18:06:43Z,2021-03-09T18:27:55Z,Update BARE_TRAIT_OBJECTS lint to deny in 2021 edition,rylev,NA,NA,NA,HEART,2021-01-27T02:26:03Z,scottmcm,NA https://github.com/rust-lang/rust/pull/81250,MERGED,2021-01-21T21:20:41Z,2021-01-24T15:25:10Z,Remove delay-binding for Win XP and Vista,sivadeilra,9a9477fada5baf69d693e717d6df902e411a73d6,2,"Auto merge of #81250 - sivadeilra:remove_xp_compat r=joshtriplett m-ou-se Remove delay-binding for Win XP and Vista The minimum supported Windows version is now Windows 7. Windows XP and Windows Vista are no longer supported; both are already broken and require extra steps to use. This commit removes the delayed-binding support for Windows API functions that are present on all supported Windows targets. This has several benefits: Removes needless complexity. Removes a load and dynamic call on hot paths in mutex acquire / release. This may have performance benefits. * ""Drop official support for Windows XP"" https://github.com/rust-lang/compiler-team/issues/378 * ""Firefox has ended support for Windows XP and Vista"" https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista",HOORAY,2021-01-21T21:48:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81250,MERGED,2021-01-21T21:20:41Z,2021-01-24T15:25:10Z,Remove delay-binding for Win XP and Vista,sivadeilra,9a9477fada5baf69d693e717d6df902e411a73d6,2,"Auto merge of #81250 - sivadeilra:remove_xp_compat r=joshtriplett m-ou-se Remove delay-binding for Win XP and Vista The minimum supported Windows version is now Windows 7. Windows XP and Windows Vista are no longer supported; both are already broken and require extra steps to use. This commit removes the delayed-binding support for Windows API functions that are present on all supported Windows targets. This has several benefits: Removes needless complexity. Removes a load and dynamic call on hot paths in mutex acquire / release. This may have performance benefits. * ""Drop official support for Windows XP"" https://github.com/rust-lang/compiler-team/issues/378 * ""Firefox has ended support for Windows XP and Vista"" https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista",HOORAY,2021-01-22T02:30:52Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/81250,MERGED,2021-01-21T21:20:41Z,2021-01-24T15:25:10Z,Remove delay-binding for Win XP and Vista,sivadeilra,9a9477fada5baf69d693e717d6df902e411a73d6,2,"Auto merge of #81250 - sivadeilra:remove_xp_compat r=joshtriplett m-ou-se Remove delay-binding for Win XP and Vista The minimum supported Windows version is now Windows 7. Windows XP and Windows Vista are no longer supported; both are already broken and require extra steps to use. This commit removes the delayed-binding support for Windows API functions that are present on all supported Windows targets. This has several benefits: Removes needless complexity. Removes a load and dynamic call on hot paths in mutex acquire / release. This may have performance benefits. * ""Drop official support for Windows XP"" https://github.com/rust-lang/compiler-team/issues/378 * ""Firefox has ended support for Windows XP and Vista"" https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista",HOORAY,2021-01-22T10:48:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/81259,MERGED,2021-01-22T08:14:00Z,2021-01-25T01:59:55Z,Replace version_check dependency with own version parsing code,est31,22dc82fb9db48a9542d3c6b7736665d9a823eb52,5,Rollup merge of #81259 - est31:cfg_version r=petrochenkov Replace version_check dependency with own version parsing code This gives compiler maintainers a better degree of control over how the version gets parsed and is a good way to ensure that there are no changes of behaviour in the future. Also issue a warning if the version is invalid instead of erroring so that we stay forwards compatible with possible future changes of the versioning scheme. Last this improves the present test a little. Fixes #79436 r? `@petrochenkov`,HEART,2021-01-22T08:16:49Z,taiki-e,NA https://github.com/rust-lang/rust/pull/81259,MERGED,2021-01-22T08:14:00Z,2021-01-25T01:59:55Z,Replace version_check dependency with own version parsing code,est31,22dc82fb9db48a9542d3c6b7736665d9a823eb52,5,Rollup merge of #81259 - est31:cfg_version r=petrochenkov Replace version_check dependency with own version parsing code This gives compiler maintainers a better degree of control over how the version gets parsed and is a good way to ensure that there are no changes of behaviour in the future. Also issue a warning if the version is invalid instead of erroring so that we stay forwards compatible with possible future changes of the versioning scheme. Last this improves the present test a little. Fixes #79436 r? `@petrochenkov`,HEART,2021-04-16T18:12:27Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/81277,MERGED,2021-01-22T17:13:13Z,2021-01-28T12:09:54Z,Make more traits of the From/Into family diagnostic items,flip1995,70be5cef699d5dcbe9457f4def66055a9ef6b966,4,Rollup merge of #81277 - flip1995:from_diag_items r=matthewjasper Make more traits of the From/Into family diagnostic items Following traits are now diagnostic items: - `From` (unchanged) - `Into` - `TryFrom` - `TryInto` This also adds symbols for those items: - `into_trait` - `try_from_trait` - `try_into_trait` Related: https://github.com/rust-lang/rust-clippy/pull/6620#discussion_r562482587,THUMBS_UP,2021-01-23T05:14:26Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/81284,MERGED,2021-01-22T19:44:29Z,2021-01-28T12:09:54Z,Make `-Z time-passes` less noisy,jyn514,bb6d1d308658cbec85f4379b5f9678e4c273b0bd,5,Rollup merge of #81284 - jyn514:impl-times r=wesleywiser Make `-Z time-passes` less noisy - Add the module name to `pre_AST_expansion_passes` and don't make it a verbose event (since it normally doesn't take very long and it's emitted many times) - Don't make the following rustdoc events verbose; they're emitted many times. + build_extern_trait_impl + build_local_trait_impl + build_primitive_trait_impl + get_auto_trait_impls + get_blanket_trait_impls - Remove the `get_auto_trait_and_blanket_synthetic_impls` rustdoc event; it's wholly covered by get_{auto blanket}_trait_impls and not very useful. I found this while working on https://github.com/rust-lang/rust/pull/81275 but it's independent of those changes.,HEART,2021-01-22T21:20:20Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/81284,MERGED,2021-01-22T19:44:29Z,2021-01-28T12:09:54Z,Make `-Z time-passes` less noisy,jyn514,bb6d1d308658cbec85f4379b5f9678e4c273b0bd,5,Rollup merge of #81284 - jyn514:impl-times r=wesleywiser Make `-Z time-passes` less noisy - Add the module name to `pre_AST_expansion_passes` and don't make it a verbose event (since it normally doesn't take very long and it's emitted many times) - Don't make the following rustdoc events verbose; they're emitted many times. + build_extern_trait_impl + build_local_trait_impl + build_primitive_trait_impl + get_auto_trait_impls + get_blanket_trait_impls - Remove the `get_auto_trait_and_blanket_synthetic_impls` rustdoc event; it's wholly covered by get_{auto blanket}_trait_impls and not very useful. I found this while working on https://github.com/rust-lang/rust/pull/81275 but it's independent of those changes.,HEART,2021-01-26T17:09:06Z,estebank,NA https://github.com/rust-lang/rust/pull/81302,MERGED,2021-01-23T17:46:33Z,2021-01-25T01:59:55Z,Fix rendering of stabilization version for trait implementors,LeSeulArtichaut,ee4461a996dba7a1c7064fdc04934e9b7f01f7f3,2,Rollup merge of #81302 - LeSeulArtichaut:80777-trait-render r=jyn514 Fix rendering of stabilization version for trait implementors Rustdoc compares an item's stabilization version with its parent's to not render it if they are the same. Here the implementor was compared with itself resulting in the stabilization version never getting shown. This probably needs a test. Fixes #80777. r? `@jyn514`,LAUGH,2021-01-23T17:51:21Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81307,MERGED,2021-01-23T20:49:47Z,2021-02-05T14:52:59Z,Handle `Span`s for byte and raw strings and add more detail ,estebank,8d49ca11a2ec5492626f7a62fe2bef8daefe9e72,35,Rollup merge of #81307 - estebank:invalid-byte-str-span r=petrochenkov Handle `Span`s for byte and raw strings and add more detail CC #81208.,HOORAY,2021-01-24T00:17:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/81310,MERGED,2021-01-23T21:50:06Z,2021-01-25T01:59:55Z,Do not mark unit variants as used when in path pattern,tmiasko,04ddf42218dca9f73edb38919d1dd9caae9b691e,3,Rollup merge of #81310 - tmiasko:in-pattern r=petrochenkov Do not mark unit variants as used when in path pattern Record that we are processing a pattern so that code responsible for handling path resolution can correctly decide whether to mark it as used or not. Closes #76788.,HOORAY,2021-01-25T07:11:47Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/81323,CLOSED,2021-01-24T05:37:36Z,2021-01-24T15:56:33Z,Implementation of `Result::swap` and tests,gymore-io,NA,NA,NA,LAUGH,2021-01-24T05:53:15Z,tesuji,NA https://github.com/rust-lang/rust/pull/81323,CLOSED,2021-01-24T05:37:36Z,2021-01-24T15:56:33Z,Implementation of `Result::swap` and tests,gymore-io,NA,NA,NA,EYES,2021-01-24T05:53:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/81323,CLOSED,2021-01-24T05:37:36Z,2021-01-24T15:56:33Z,Implementation of `Result::swap` and tests,gymore-io,NA,NA,NA,CONFUSED,2021-01-24T12:42:16Z,kennytm,NA https://github.com/rust-lang/rust/pull/81323,CLOSED,2021-01-24T05:37:36Z,2021-01-24T15:56:33Z,Implementation of `Result::swap` and tests,gymore-io,NA,NA,NA,CONFUSED,2021-01-24T15:24:14Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/81325,MERGED,2021-01-24T07:39:05Z,2021-01-26T22:43:49Z,typeck: Don't suggest converting LHS exprs,osa1,71f13fb434b31e51b2df1b651279fe2c35118b49,4,Rollup merge of #81325 - osa1:issue81293 r=estebank typeck: Don't suggest converting LHS exprs Converting LHS of an assignment does not work so avoid suggesting that. Fixes #81293,THUMBS_UP,2021-01-25T08:35:26Z,iago-lito,NA https://github.com/rust-lang/rust/pull/81325,MERGED,2021-01-24T07:39:05Z,2021-01-26T22:43:49Z,typeck: Don't suggest converting LHS exprs,osa1,71f13fb434b31e51b2df1b651279fe2c35118b49,4,Rollup merge of #81325 - osa1:issue81293 r=estebank typeck: Don't suggest converting LHS exprs Converting LHS of an assignment does not work so avoid suggesting that. Fixes #81293,HEART,2021-01-25T08:35:28Z,iago-lito,NA https://github.com/rust-lang/rust/pull/81346,MERGED,2021-01-24T17:25:52Z,2021-02-03T08:46:49Z,Add a new ABI to support cmse_nonsecure_call,hug-dev,b593389edbaa9ea0c90f0ed419283842f534e50a,35,Auto merge of #81346 - hug-dev:nonsecure-call-abi r=jonas-schievink Add a new ABI to support cmse_nonsecure_call This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call. See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928). This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃 I did not yet create a tracking issue but if most of it is fine I can create one and update the various files accordingly (they refer to the other tracking issue now). On the Zulip chat I believe `@jonas-schievink` volunteered to be a reviewer 💯,THUMBS_UP,2021-01-29T02:40:48Z,nihalpasham,NA https://github.com/rust-lang/rust/pull/81354,MERGED,2021-01-24T20:18:01Z,2021-03-28T06:32:34Z,Instruct LLVM that binary_search returns a valid index,SkiFire13,1df20569dd07d91ed270ea9cfc2dbb9f56700703,2,Auto merge of #81354 - SkiFire13:binary-search-assume r=nagisa Instruct LLVM that binary_search returns a valid index This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this not sure if it's the right thing to do (I didn't find anything on the dev guide) but it felt so.,ROCKET,2021-04-01T17:09:54Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81354,MERGED,2021-01-24T20:18:01Z,2021-03-28T06:32:34Z,Instruct LLVM that binary_search returns a valid index,SkiFire13,1df20569dd07d91ed270ea9cfc2dbb9f56700703,2,Auto merge of #81354 - SkiFire13:binary-search-assume r=nagisa Instruct LLVM that binary_search returns a valid index This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this not sure if it's the right thing to do (I didn't find anything on the dev guide) but it felt so.,ROCKET,2021-04-02T22:44:58Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/81356,MERGED,2021-01-24T21:13:24Z,2021-02-08T23:37:24Z,libtest: allow multiple filters,ehuss,b102ea479ddfea0e72757427fc73ec487d69aac1,7,Rollup merge of #81356 - ehuss:libtest-filters r=m-ou-se libtest: allow multiple filters Libtest ignores any filters after the first. This changes it so that if multiple filters are passed it will test against all of them. This also affects compiletest to do the same. Closes #30422,HEART,2021-02-19T16:07:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81356,MERGED,2021-01-24T21:13:24Z,2021-02-08T23:37:24Z,libtest: allow multiple filters,ehuss,b102ea479ddfea0e72757427fc73ec487d69aac1,7,Rollup merge of #81356 - ehuss:libtest-filters r=m-ou-se libtest: allow multiple filters Libtest ignores any filters after the first. This changes it so that if multiple filters are passed it will test against all of them. This also affects compiletest to do the same. Closes #30422,HEART,2021-05-04T11:08:50Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,THUMBS_UP,2021-01-27T08:16:57Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,THUMBS_UP,2021-02-02T16:59:26Z,bluss,NA https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,THUMBS_UP,2021-02-03T07:06:24Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,HEART,2021-02-03T07:06:33Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,THUMBS_UP,2021-02-04T17:30:49Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/81358,MERGED,2021-01-24T22:14:21Z,2021-03-17T14:01:52Z,Add a check for ASCII characters in to_upper and to_lower,mcastorina,0ce0fedb67fa66d50aa819ef8b12f1d89eb22d7d,2,Auto merge of #81358 - mcastorina:to-upper-lower-speed r=joshtriplett Add a check for ASCII characters in to_upper and to_lower This extra check has better performance. See discussion here: https://internals.rust-lang.org/t/to-upper-speed/13896 Thanks to `@gilescope` for helping discover and test this.,THUMBS_UP,2021-02-06T21:35:24Z,NiklasEi,git@nikl.me https://github.com/rust-lang/rust/pull/81360,MERGED,2021-01-24T23:03:54Z,2021-07-10T16:41:28Z,Support forwarding caller location through trait object method call,Aaron1011,3982eb35cabe3a99194d768d34a92347967c3fa2,5,Auto merge of #81360 - Aaron1011:trait-caller-loc r=nagisa Support forwarding caller location through trait object method call Since PR #69251 the `#[track_caller]` attribute has been supported on traits. However it only has an effect on direct (monomorphized) method calls. Calling a `#[track_caller]` method on a trait object will *not* propagate caller location information - instead `Location::caller()` will return the location of the method definition. This PR forwards caller location information when `#[track_caller]` is present on the method definition in the trait. This is possible because `#[track_caller]` in this position is 'inherited' by any impls of that trait so all implementations will have the same ABI. This PR does *not* change the behavior in the case where `#[track_caller]` is present only on the impl of a trait. While all implementations of the method might have an explicit `#[track_caller]` we cannot know this at codegen time since other crates may have impls of the trait. Therefore we keep the current behavior of not forwarding the caller location ensuring that all implementations of the trait will have the correct ABI. See the modified test for examples of how this works,THUMBS_UP,2021-01-26T18:06:24Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/81360,MERGED,2021-01-24T23:03:54Z,2021-07-10T16:41:28Z,Support forwarding caller location through trait object method call,Aaron1011,3982eb35cabe3a99194d768d34a92347967c3fa2,5,Auto merge of #81360 - Aaron1011:trait-caller-loc r=nagisa Support forwarding caller location through trait object method call Since PR #69251 the `#[track_caller]` attribute has been supported on traits. However it only has an effect on direct (monomorphized) method calls. Calling a `#[track_caller]` method on a trait object will *not* propagate caller location information - instead `Location::caller()` will return the location of the method definition. This PR forwards caller location information when `#[track_caller]` is present on the method definition in the trait. This is possible because `#[track_caller]` in this position is 'inherited' by any impls of that trait so all implementations will have the same ABI. This PR does *not* change the behavior in the case where `#[track_caller]` is present only on the impl of a trait. While all implementations of the method might have an explicit `#[track_caller]` we cannot know this at codegen time since other crates may have impls of the trait. Therefore we keep the current behavior of not forwarding the caller location ensuring that all implementations of the trait will have the correct ABI. See the modified test for examples of how this works,THUMBS_UP,2021-06-19T06:48:53Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/81360,MERGED,2021-01-24T23:03:54Z,2021-07-10T16:41:28Z,Support forwarding caller location through trait object method call,Aaron1011,3982eb35cabe3a99194d768d34a92347967c3fa2,5,Auto merge of #81360 - Aaron1011:trait-caller-loc r=nagisa Support forwarding caller location through trait object method call Since PR #69251 the `#[track_caller]` attribute has been supported on traits. However it only has an effect on direct (monomorphized) method calls. Calling a `#[track_caller]` method on a trait object will *not* propagate caller location information - instead `Location::caller()` will return the location of the method definition. This PR forwards caller location information when `#[track_caller]` is present on the method definition in the trait. This is possible because `#[track_caller]` in this position is 'inherited' by any impls of that trait so all implementations will have the same ABI. This PR does *not* change the behavior in the case where `#[track_caller]` is present only on the impl of a trait. While all implementations of the method might have an explicit `#[track_caller]` we cannot know this at codegen time since other crates may have impls of the trait. Therefore we keep the current behavior of not forwarding the caller location ensuring that all implementations of the trait will have the correct ABI. See the modified test for examples of how this works,THUMBS_UP,2021-06-24T07:38:51Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81366,CLOSED,2021-01-25T03:02:50Z,2021-07-18T11:50:09Z,On irrefutable let pattern lint point only at pattern,estebank,NA,NA,NA,HEART,2021-01-25T03:09:56Z,camelid,NA https://github.com/rust-lang/rust/pull/81382,CLOSED,2021-01-25T13:09:15Z,2021-02-27T13:19:37Z,Make `is_sorted[_by_key]` require `Ord` instead of `PartialOrd` and remove `Iterator::is_sorted_by_key`,LukasKalbertodt,NA,NA,NA,THUMBS_UP,2021-01-26T17:41:08Z,Pratyush,NA https://github.com/rust-lang/rust/pull/81384,MERGED,2021-01-25T14:22:31Z,2021-02-09T11:39:05Z,Fix derived PartialOrd operators ,tmiasko,c648bd55580a918d6f26f39bc167913a9da5ae3d,26,Auto merge of #81384 - tmiasko:partial-ord r=petrochenkov Fix derived PartialOrd operators The derived implementation of `partial_cmp` compares matching fields one by one stopping the computation when the result of a comparison is not equal to `Some(Equal)`. On the other hand the derived implementation for `lt` `le` `gt` and `ge` continues the computation when the result of a field comparison is `None` consequently those operators are not transitive and inconsistent with `partial_cmp`. Fix the inconsistency by using the default implementation that fall-backs to the `partial_cmp`. This also avoids creating very deeply nested closures that were quite costly to compile. Fixes #81373. Helps with #81278 #80118.,HEART,2021-02-09T08:48:52Z,tesuji,NA https://github.com/rust-lang/rust/pull/81384,MERGED,2021-01-25T14:22:31Z,2021-02-09T11:39:05Z,Fix derived PartialOrd operators ,tmiasko,c648bd55580a918d6f26f39bc167913a9da5ae3d,26,Auto merge of #81384 - tmiasko:partial-ord r=petrochenkov Fix derived PartialOrd operators The derived implementation of `partial_cmp` compares matching fields one by one stopping the computation when the result of a comparison is not equal to `Some(Equal)`. On the other hand the derived implementation for `lt` `le` `gt` and `ge` continues the computation when the result of a field comparison is `None` consequently those operators are not transitive and inconsistent with `partial_cmp`. Fix the inconsistency by using the default implementation that fall-backs to the `partial_cmp`. This also avoids creating very deeply nested closures that were quite costly to compile. Fixes #81373. Helps with #81278 #80118.,THUMBS_UP,2021-02-19T02:53:48Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/81399,MERGED,2021-01-25T23:11:51Z,2021-01-26T22:43:49Z,Update books,ehuss,9da36082c2d54de74be9679cf63518e11cbc7fa1,4,Rollup merge of #81399 - ehuss:update-books r=ehuss Update books ## nomicon 7 commits in a8584998eacdea7106a1dfafcbf6c1c06fcdf925..bbf06ad39d1f45654047e9596b750cc6e6d1b693 2021-01-06 12:49:49 -0500 to 2021-01-22 07:07:31 -0800 - Fix alloc link in exotic-sizes for local docs (rust-lang-nursery/nomicon#255) - Remove TODO - Fix small punctuation error - Arc revisions (Clone atomic explanation) (pt2/3(+?)) - Fix Arc Clone - Arc revisions (pt1/2(+?)) - Simple Arc implementation (without Weak refs) ## reference 5 commits in 50af691f838937c300b47812d0507c6d88c14f97..f02b09eb6e8af340ad1256a54adb7aae2ff3163e 2021-01-12 21:19:20 -0800 to 2021-01-22 01:53:02 -0800 - Fix missing space (rust-lang-nursery/reference#941) - Start documenting name resolution. (rust-lang-nursery/reference#937) - Fix plural and delete spurious words in comparison ops (rust-lang-nursery/reference#932) - Document execution order (rust-lang-nursery/reference#888) - Compound operator expressions (rust-lang-nursery/reference#915) ## book 3 commits in ac57a0ddd23d173b26731ccf939f3ba729753275..e724bd826580ff95df48a8533af7dec1080693d4 2021-01-09 14:18:45 -0500 to 2021-01-20 08:19:49 -0600 - Fixes rust-lang/book#2417. Get the index from user input instead of a const. (rust-lang/book#2566) - Turn off the playground in a bunch more lib.rs inclusions (rust-lang/book#2569) - Merge pull request rust-lang/book#2567 from rust-lang/rust-1.49 ## rust-by-example 1 commits in 03e23af01f0b4f83a3a513da280e1ca92587f2ec..f633769acef68574427a6fae6c06f13bc2199573 2021-01-09 10:20:28 -0300 to 2021-01-13 20:58:25 -0300 - Fixed styling on closure example (rust-lang/rust-by-example#1405),HOORAY,2021-01-26T01:40:41Z,ThePuzzlemaker,tpzker@thepuzzlemaker.info https://github.com/rust-lang/rust/pull/81400,CLOSED,2021-01-25T23:54:54Z,2021-01-30T14:40:12Z,Box `ast::ItemKind`,jyn514,NA,NA,NA,EYES,2021-01-26T01:46:53Z,ThePuzzlemaker,tpzker@thepuzzlemaker.info https://github.com/rust-lang/rust/pull/81404,CLOSED,2021-01-26T07:08:38Z,2021-06-19T15:34:53Z,Add a parse recovery in array type syntax,osa1,NA,NA,NA,THUMBS_UP,2021-02-14T06:51:21Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/81407,MERGED,2021-01-26T10:13:21Z,2021-01-26T22:43:49Z,"Refine ""remove semicolon"" suggestion in trait selection",osa1,d68570c78f698bd913bfc8dae33ebe81590457b7,3,"Rollup merge of #81407 - osa1:issue81098 r=estebank Refine ""remove semicolon"" suggestion in trait selection Don't suggest it if the last statement doesn't have a semicolon Fixes #81098 See also #54771 for why this suggestion was added",HEART,2021-01-26T17:00:44Z,estebank,NA https://github.com/rust-lang/rust/pull/81409,MERGED,2021-01-26T11:16:47Z,2021-01-30T13:58:12Z,Slight simplification of chars().count(),gilescope,c26dd4d4140202283221c05758b1b1531b2fbb96,1,Rollup merge of #81409 - gilescope:chars_count r=joshtriplett Slight simplification of chars().count() Slight simplification: No need to call len() we can just count the number of non continuation bytes. I can't see any reason not to do this can you?,THUMBS_UP,2021-01-26T19:18:35Z,bluss,NA https://github.com/rust-lang/rust/pull/81414,MERGED,2021-01-26T18:41:16Z,2021-01-28T04:44:15Z,Check for rmeta crates when getting existing crates from cache,rylev,e32f372c4203b2527221b313cf63b05ea178e8a9,1,Auto merge of #81414 - rylev:fetch-rmeta-crates r=petrochenkov Check for rmeta crates when getting existing crates from cache This change makes sure to check for rmeta files when resolving crates instead of always going to disk in that case.,THUMBS_UP,2021-01-28T18:52:40Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/81419,MERGED,2021-01-26T21:30:57Z,2021-01-29T13:10:19Z,Pre-canoncalize ExternLocation::ExactPaths,rylev,c4e33b51c1a2d5e599b949fa3006467b88df253a,5,Auto merge of #81419 - rylev:canocalize-extern-entries r=petrochenkov Pre-canoncalize ExternLocation::ExactPaths This stores pre-canacolized paths inside `ExternLocation::ExactPaths` so that we don't need to canoncalize them every time we want to compare them to source lib paths. This is related to #81414.,HEART,2021-01-27T07:53:11Z,lqd,NA https://github.com/rust-lang/rust/pull/81419,MERGED,2021-01-26T21:30:57Z,2021-01-29T13:10:19Z,Pre-canoncalize ExternLocation::ExactPaths,rylev,c4e33b51c1a2d5e599b949fa3006467b88df253a,5,Auto merge of #81419 - rylev:canocalize-extern-entries r=petrochenkov Pre-canoncalize ExternLocation::ExactPaths This stores pre-canacolized paths inside `ExternLocation::ExactPaths` so that we don't need to canoncalize them every time we want to compare them to source lib paths. This is related to #81414.,HEART,2021-01-28T18:52:12Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/81419,MERGED,2021-01-26T21:30:57Z,2021-01-29T13:10:19Z,Pre-canoncalize ExternLocation::ExactPaths,rylev,c4e33b51c1a2d5e599b949fa3006467b88df253a,5,Auto merge of #81419 - rylev:canocalize-extern-entries r=petrochenkov Pre-canoncalize ExternLocation::ExactPaths This stores pre-canacolized paths inside `ExternLocation::ExactPaths` so that we don't need to canoncalize them every time we want to compare them to source lib paths. This is related to #81414.,HEART,2021-02-04T15:54:20Z,Spoonbender,NA https://github.com/rust-lang/rust/pull/81442,CLOSED,2021-01-27T15:27:31Z,2021-01-27T15:49:12Z,Promote Vec and RawVec functions to const fn,fschutt,NA,NA,NA,EYES,2021-01-27T15:34:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-27T23:58:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-28T00:55:03Z,CryZe,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-28T02:10:18Z,tesuji,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-29T02:50:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-29T03:11:57Z,taiki-e,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-29T10:02:35Z,mati865,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-29T14:06:38Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-01-31T21:50:47Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-02T11:26:40Z,aheart,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-05T00:36:37Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-08T08:30:43Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-12T05:30:33Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-23T11:26:02Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-02-28T12:11:00Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-01T18:38:37Z,Systemcluster,me@systemcluster.me https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-01T19:37:38Z,ccope,github@camcope.me https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-01T23:52:16Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-02T16:03:31Z,tux3,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-02T18:23:15Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T01:53:02Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T19:39:20Z,ZOXEXIVO,zoxexivo@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T22:21:18Z,cbeuw,cbeuw.andy@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T22:23:20Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T22:37:49Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T22:54:12Z,yerke,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T23:02:21Z,Eucladia,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T23:09:26Z,gliderkite,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T23:14:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-04T23:36:42Z,sunjay,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T01:15:52Z,95th,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T04:28:15Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T05:23:25Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T07:56:48Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T08:21:44Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T09:00:21Z,xcaptain,joey.xf@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T10:07:59Z,iago-lito,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T12:08:48Z,RamakrishnaChilaka,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T12:21:06Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T13:05:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T13:45:17Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T14:42:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T16:59:18Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T17:14:46Z,ttys3,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-05T17:53:35Z,DianaNites,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-07T18:52:46Z,Bernd-L,git@bernd.pw https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-11T04:01:12Z,lukechu10,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-12T22:35:17Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-13T15:04:28Z,worstpractice,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-03-15T19:04:04Z,naeu,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-04-02T02:01:30Z,kaigedong,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-04-10T21:35:53Z,ZacharyTalis,zacharytalis@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-05-06T01:49:44Z,gyb997,gyb997@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-05-06T16:27:20Z,r00ster91,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-05-06T20:58:13Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-05-14T17:55:42Z,ggoraa,ggoraa1029@gmail.com https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-05-18T23:50:47Z,copyrighthero,NA https://github.com/rust-lang/rust/pull/81451,MERGED,2021-01-27T20:10:34Z,2021-03-04T19:24:27Z,Upgrade to LLVM 12,nikic,409920873cf8a95739a55dc5fe5adb05e1b4758e,57,Auto merge of #81451 - nikic:llvm-12 r=nagisa Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`,HOORAY,2021-07-13T01:12:02Z,jared-mackey,NA https://github.com/rust-lang/rust/pull/81452,CLOSED,2021-01-27T20:18:05Z,2021-01-30T20:51:18Z,Add #[must_use] to process::Command process::Child and process::ExitStatus,ijackson,NA,NA,NA,HEART,2021-01-28T14:41:27Z,tmiasko,NA https://github.com/rust-lang/rust/pull/81452,CLOSED,2021-01-27T20:18:05Z,2021-01-30T20:51:18Z,Add #[must_use] to process::Command process::Child and process::ExitStatus,ijackson,NA,NA,NA,HEART,2021-05-09T21:49:28Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/81455,MERGED,2021-01-27T23:15:42Z,2021-02-03T03:03:12Z,Add AArch64 big-endian and ILP32 targets,Amanieu,399c0a8e52471ba17292d7538f1fb1fc26a32979,13,Rollup merge of #81455 - Amanieu:aarch64_ilp32 r=sanxiyn Add AArch64 big-endian and ILP32 targets This PR adds 3 new AArch64 targets: - `aarch64_be-unknown-linux-gnu` - `aarch64-unknown-linux-gnu_ilp32` - `aarch64_be-unknown-linux-gnu_ilp32` It also fixes some ABI issues on big-endian ARM and AArch64.,HEART,2021-04-25T11:00:45Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/81466,MERGED,2021-01-28T09:18:00Z,2021-02-10T06:21:54Z,Add suggest mut method for loop,sasurau4,3f09418cbe0cc598e8b0567626c2c800a09cc9cc,3,Rollup merge of #81466 - sasurau4:fix/enhance-sugget-mut-method-for-loop r=oli-obk Add suggest mut method for loop Part of #49839 This PR focus on [the comment case](https://github.com/rust-lang/rust/issues/49839#issuecomment-761930746),THUMBS_UP,2021-02-10T06:38:04Z,tesuji,NA https://github.com/rust-lang/rust/pull/81468,MERGED,2021-01-28T12:29:33Z,2021-01-30T13:58:12Z,cfg(version): treat nightlies as complete,est31,fe27dea4b5f3ae1fe95a16f2bd9c6428fdd116b5,7,Rollup merge of #81468 - est31:cfg_version r=petrochenkov cfg(version): treat nightlies as complete This PR makes cfg(version) treat the nightlies for version 1.n.0 as 1.n.0 even though that nightly version might not have all stabilizations and features of the released 1.n.0. This is done for greater convenience for people who want to test a newly stabilized feature on nightly or in other words give newly stabilized features as many eyeballs as possible. For users who wish to pin nightlies this commit adds a -Z assume-incomplete-release option that they can enable if they run into any issues due to this change. Implements the suggestion in https://github.com/rust-lang/rust/issues/64796#issuecomment-640851454,HOORAY,2021-01-28T15:33:15Z,dekellum,dek-oss@gravitext.com https://github.com/rust-lang/rust/pull/81473,MERGED,2021-01-28T15:00:31Z,2021-01-30T13:58:12Z,Warn write-only fields,sanxiyn,774ba83226d570d2ac4dd072515d3cbd08bd5b3e,4,Rollup merge of #81473 - sanxiyn:write-only-field r=oli-obk Warn write-only fields cc `@Boscop's` example in #49256.,THUMBS_UP,2021-01-29T00:25:23Z,tesuji,NA https://github.com/rust-lang/rust/pull/81473,MERGED,2021-01-28T15:00:31Z,2021-01-30T13:58:12Z,Warn write-only fields,sanxiyn,774ba83226d570d2ac4dd072515d3cbd08bd5b3e,4,Rollup merge of #81473 - sanxiyn:write-only-field r=oli-obk Warn write-only fields cc `@Boscop's` example in #49256.,THUMBS_UP,2021-01-30T14:13:02Z,thehighestend,NA https://github.com/rust-lang/rust/pull/81479,MERGED,2021-01-28T17:25:01Z,2021-02-13T05:38:04Z,Allow casting mut array ref to mut ptr,osa1,fc93e260e914aefb6896a65de025fb34127cccaf,4,Rollup merge of #81479 - osa1:issue24151 r=lcnr Allow casting mut array ref to mut ptr Allow casting mut array ref to mut ptr We now allow two new casts: - mut array reference to mut ptr. Example: let mut x: [usize; 2] = [0 0]; let p = &mut x as *mut usize; We allow casting const array references to const pointers so not allowing mut references to mut pointers was inconsistent. - mut array reference to const ptr. Example: let mut x: [usize; 2] = [0 0]; let p = &mut x as *const usize; This was similarly inconsistent as we allow casting mut references to const pointers. Existing test 'vector-cast-weirdness' updated to test both cases. Fixes #24151,HEART,2021-01-28T17:31:42Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/81479,MERGED,2021-01-28T17:25:01Z,2021-02-13T05:38:04Z,Allow casting mut array ref to mut ptr,osa1,fc93e260e914aefb6896a65de025fb34127cccaf,4,Rollup merge of #81479 - osa1:issue24151 r=lcnr Allow casting mut array ref to mut ptr Allow casting mut array ref to mut ptr We now allow two new casts: - mut array reference to mut ptr. Example: let mut x: [usize; 2] = [0 0]; let p = &mut x as *mut usize; We allow casting const array references to const pointers so not allowing mut references to mut pointers was inconsistent. - mut array reference to const ptr. Example: let mut x: [usize; 2] = [0 0]; let p = &mut x as *const usize; This was similarly inconsistent as we allow casting mut references to const pointers. Existing test 'vector-cast-weirdness' updated to test both cases. Fixes #24151,HEART,2021-05-06T15:47:28Z,zohnannor,NA https://github.com/rust-lang/rust/pull/81480,MERGED,2021-01-28T17:30:51Z,2021-02-01T02:42:20Z,Add suggestion for nested fields,b-naber,991b31377c0a1fc547bc14ab2335cb458a36ece7,6,Rollup merge of #81480 - b-naber:nested_fields_suggestion r=estebank Add suggestion for nested fields Closes https://github.com/rust-lang/rust/issues/81220 r? ```@estebank```,HEART,2021-01-29T00:20:11Z,estebank,NA https://github.com/rust-lang/rust/pull/81480,MERGED,2021-01-28T17:30:51Z,2021-02-01T02:42:20Z,Add suggestion for nested fields,b-naber,991b31377c0a1fc547bc14ab2335cb458a36ece7,6,Rollup merge of #81480 - b-naber:nested_fields_suggestion r=estebank Add suggestion for nested fields Closes https://github.com/rust-lang/rust/issues/81220 r? ```@estebank```,HEART,2021-03-07T08:06:16Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/81489,MERGED,2021-01-28T20:10:24Z,2021-01-30T07:35:06Z,Update Python and Clang on x86 dist images,nikic,cb6787ae82d388045cdf6b5dc73787d828d91feb,6,Auto merge of #81489 - nikic:x86-64-dist-update r=Mark-Simulacrum Update Python and Clang on x86 dist images LLVM 12 no longer builds with Python 2 so install Python 3 in preparation for the upgrade (#81451). However Clang 10 does not build with Python 3 so we need update to Clang 11 as well which supports both. Unfortunately doing so results in errors while linking the libLLVM.so into other binaries: > __morestack: invalid needed version 2 This is fixed by using LLD instead. Possibly this is due to a binutils linker bug but updating to the latest binutils version does not fix it. r? `@Mark-Simulacrum` cc `@cuviper`,LAUGH,2021-01-28T20:26:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81489,MERGED,2021-01-28T20:10:24Z,2021-01-30T07:35:06Z,Update Python and Clang on x86 dist images,nikic,cb6787ae82d388045cdf6b5dc73787d828d91feb,6,Auto merge of #81489 - nikic:x86-64-dist-update r=Mark-Simulacrum Update Python and Clang on x86 dist images LLVM 12 no longer builds with Python 2 so install Python 3 in preparation for the upgrade (#81451). However Clang 10 does not build with Python 3 so we need update to Clang 11 as well which supports both. Unfortunately doing so results in errors while linking the libLLVM.so into other binaries: > __morestack: invalid needed version 2 This is fixed by using LLD instead. Possibly this is due to a binutils linker bug but updating to the latest binutils version does not fix it. r? `@Mark-Simulacrum` cc `@cuviper`,LAUGH,2021-01-29T10:04:40Z,mati865,NA https://github.com/rust-lang/rust/pull/81502,MERGED,2021-01-29T06:11:57Z,2021-02-07T13:57:22Z,Add abi field to `Method`,CraftSpider,ae00b62ceb7eaf1f02f5289ab233bf7e0e8060d5,3,Auto merge of #81502 - CraftSpider:method-abi r=jyn514 Add abi field to `Method` Also bumps version and adds a test (Will conflict with #81500 whichever is merged first) Rationale: It's possible for methods to have an ABI. This should be exposed in the JSON.,THUMBS_UP,2021-01-30T15:21:49Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/81503,MERGED,2021-01-29T06:32:45Z,2021-02-16T05:45:15Z,Suggest to create a new `const` item if the `fn` in the array is a `const fn`,henryboisdequin,f02f7b05b24543f0928f34c75aad2465e20094ca,8,"Rollup merge of #81503 - henryboisdequin:fix-const-fn-arr-err-msg r=estebank Suggest to create a new `const` item if the `fn` in the array is a `const fn` Fixes #73734. If the `fn` in the array repeat expression is a `const fn` suggest creating a new `const` item. On nightly suggest creating an inline `const` block. This PR also removes the `suggest_const_in_array_repeat_expressions` as it is no longer necessary. Example: ```rust fn main() { // Should not compile but hint to create a new const item (stable) or an inline const block (nightly) let strings: [String; 5] = [String::new(); 5]; println!(""{:?}"" strings); } ``` Gives this error: ``` error[E0277]: the trait bound `std::string::String: std::marker::Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:3:32 | 2 | let strings: [String; 5] = [String::new(); 5]; | ^^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `String` | = note: the `Copy` trait is required because the repeated element will be copied ``` With this change this is the error message: ``` error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:3:32 | LL | let strings: [String; 5] = [String::new(); 5]; | ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: moving the function call to a new `const` item will resolve the error ```",THUMBS_UP,2021-01-29T08:16:19Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/81503,MERGED,2021-01-29T06:32:45Z,2021-02-16T05:45:15Z,Suggest to create a new `const` item if the `fn` in the array is a `const fn`,henryboisdequin,f02f7b05b24543f0928f34c75aad2465e20094ca,8,"Rollup merge of #81503 - henryboisdequin:fix-const-fn-arr-err-msg r=estebank Suggest to create a new `const` item if the `fn` in the array is a `const fn` Fixes #73734. If the `fn` in the array repeat expression is a `const fn` suggest creating a new `const` item. On nightly suggest creating an inline `const` block. This PR also removes the `suggest_const_in_array_repeat_expressions` as it is no longer necessary. Example: ```rust fn main() { // Should not compile but hint to create a new const item (stable) or an inline const block (nightly) let strings: [String; 5] = [String::new(); 5]; println!(""{:?}"" strings); } ``` Gives this error: ``` error[E0277]: the trait bound `std::string::String: std::marker::Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:3:32 | 2 | let strings: [String; 5] = [String::new(); 5]; | ^^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `String` | = note: the `Copy` trait is required because the repeated element will be copied ``` With this change this is the error message: ``` error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:3:32 | LL | let strings: [String; 5] = [String::new(); 5]; | ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = help: moving the function call to a new `const` item will resolve the error ```",THUMBS_UP,2021-01-29T14:28:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81504,MERGED,2021-01-29T07:15:46Z,2021-02-01T19:22:37Z,Suggest accessing field when appropriate,hkmatsumoto,853cfd462f629152f808c549c37e09d590a7921c,4,Rollup merge of #81504 - matsujika:suggestion-field-access r=estebank Suggest accessing field when appropriate Fix #81222 r? ``@estebank``,HEART,2021-01-29T18:06:11Z,estebank,NA https://github.com/rust-lang/rust/pull/81520,MERGED,2021-01-29T17:30:51Z,2021-01-30T13:58:11Z,Don't clone LLVM submodule when download-ci-llvm is set,jyn514,31e7634749a737be8118ec8fe92c2dfcd2d10046,1,Rollup merge of #81520 - jyn514:rustc2 r=Mark-Simulacrum Don't clone LLVM submodule when download-ci-llvm is set Previously `downloading_llvm` would check `self.build` while it was still an empty string and think it was always false. This fixes the check. This addresses the worst part of https://github.com/rust-lang/rust/issues/76653. There are still some large submodules being downloaded (in particular `rustc-by-example` is 146 MB and all the submodules combined are 311 MB) but this is a lot better than the whopping 1.4 GB before.,HEART,2021-01-29T17:57:59Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/81536,MERGED,2021-01-29T20:36:02Z,2021-02-01T19:22:37Z,Indicate both start and end of pass RSS in time-passes output,tgnottingham,82b00ec606df7d1dc3237cc05f8431ae43f76b03,4,"Rollup merge of #81536 - tgnottingham:time-passes-rss r=oli-obk Indicate both start and end of pass RSS in time-passes output Previously only the end of pass RSS was indicated. This could easily lead one to believe that the change in RSS from one pass to the next was attributable to the second pass when in fact it occurred between the end of the first pass and the start of the second. Also improve alignment of columns. Sample of output: ``` time: 0.739; rss: 607MB -> 637MB item_types_checking time: 8.429; rss: 637MB -> 775MB item_bodies_checking time: 11.063; rss: 470MB -> 775MB type_check_crate time: 0.232; rss: 775MB -> 777MB match_checking time: 0.139; rss: 777MB -> 779MB liveness_and_intrinsic_checking time: 0.372; rss: 775MB -> 779MB misc_checking_2 time: 8.188; rss: 779MB -> 1019MB MIR_borrow_checking time: 0.062; rss: 1019MB -> 1021MB MIR_effect_checking ```",THUMBS_UP,2021-01-29T20:56:00Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81542,MERGED,2021-01-30T02:15:36Z,2021-02-05T14:52:58Z,Expose correct symlink API on WASI,RReverser,ce1020fc55d901838477ed5626c332c48ca16fd4,1,"Rollup merge of #81542 - RReverser:wasi-symlink r=alexcrichton Expose correct symlink API on WASI As described in https://github.com/rust-lang/rust/issues/68574 the currently exposed API for symlinks is in fact a thin wrapper around the corresponding syscall and not suitable for public usage. The reason is that the 2nd param in the call is expected to be a handle of a ""preopened directory"" (a WASI concept for exposing dirs) and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API which is an implementation detail and definitely not something we want users to call directly. Making matters worse the semantics of this param aren't obvious from its name (`fd`) and easy to misinterpret resulting in people trying to pass a handle of the target file itself (as in https://github.com/vitiral/path_abs/pull/50) which doesn't work as expected. I did a [codesearch among open-source repos](https://sourcegraph.com/search?q=std%3A%3Aos%3A%3Awasi%3A%3Afs%3A%3Asymlink&patternType=literal) and the usage above is so far the only usage of this API at all but we should fix it before more people start using it incorrectly. While this is technically a breaking API change I believe it's a justified one as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API and if someone does use it they're likely doing it wrong like in the example above. The new API does not lead to the same confusion as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file dir}` variants by accepting source/target paths. Fixes #68574. r? ``@alexcrichton``",THUMBS_UP,2021-02-02T16:34:41Z,vitiral,vitiral@gmail.com https://github.com/rust-lang/rust/pull/81544,MERGED,2021-01-30T04:23:01Z,2021-02-03T03:03:12Z,Add better diagnostic for unbounded Abst. Const,JulianKnodt,3aed8b17a89e5ed856eeb5a877cf298761aee757,7,Rollup merge of #81544 - JulianKnodt:sat_where r=lcnr Add better diagnostic for unbounded Abst. Const ~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst: ` instead of requiring a where bound just check that only consts are being substituted in to skip over where check.~~ ~~This is pretty sketchy but I think it works. Presumably if there is checking for type bounds added later it can first check nested requirements and see if they're satisfied by the current `ParamEnv`.~~ Changed the diagnostic to add a better example which is more practical than what was previously proposed. r? ```@lcnr```,THUMBS_UP,2021-01-31T08:19:25Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/81557,MERGED,2021-01-30T16:41:29Z,2021-02-02T03:04:36Z,Fix primitive search in parameters and returned values,GuillaumeGomez,461cbe42d03f55ac331ce9ce23108681411b04f5,7,Auto merge of #81557 - GuillaumeGomez:primitive-search r=ollie27 Fix primitive search in parameters and returned values Part of #60485. Fixes #74780. Replacing #74879. cc `@camelid` `@jyn514` `@CraftSpider` r? `@ollie27`,HEART,2021-01-30T22:46:14Z,camelid,NA https://github.com/rust-lang/rust/pull/81565,MERGED,2021-01-30T18:36:50Z,2021-01-30T23:55:15Z,Revert dist-x86_64-linux update to Clang 11,nikic,04caa632dd10c2bf64b69524c7f9c4c30a436877,6,Auto merge of #81565 - nikic:revert r=nagisa Revert dist-x86_64-linux update to Clang 11 This reverts commit cb6787ae82d388045cdf6b5dc73787d828d91feb reversing changes made to 0248c6f178ab3a4d2ec702b7d418ff8375ab0515. The change causes errors when linking rustc shared objects with the binutils linker. Fixes #81554. r? `@Mark-Simulacrum`,HEART,2021-01-30T18:42:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/81574,MERGED,2021-01-30T22:20:00Z,2021-02-18T13:04:32Z,Precompute ancestors when checking privacy,tmiasko,cb2effd44e667d133e31ef334e30d10195218ce6,1,Auto merge of #81574 - tmiasko:p r=oli-obk Precompute ancestors when checking privacy Precompute ancestors of the old error node set so that check for private types and traits in public interfaces can in constant time determine if the current item has any descendants in the old error set. This removes disparity in compilation time between public and private type aliases reported in #50614 (from 30 s to 5 s in an example making extensive use of private type aliases). No functional changes intended.,HEART,2021-02-15T02:10:03Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/81574,MERGED,2021-01-30T22:20:00Z,2021-02-18T13:04:32Z,Precompute ancestors when checking privacy,tmiasko,cb2effd44e667d133e31ef334e30d10195218ce6,1,Auto merge of #81574 - tmiasko:p r=oli-obk Precompute ancestors when checking privacy Precompute ancestors of the old error node set so that check for private types and traits in public interfaces can in constant time determine if the current item has any descendants in the old error set. This removes disparity in compilation time between public and private type aliases reported in #50614 (from 30 s to 5 s in an example making extensive use of private type aliases). No functional changes intended.,HEART,2021-02-25T10:15:23Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/81679,MERGED,2021-02-02T21:08:38Z,2021-02-03T11:42:09Z,Bind all clean::Type variants and remove FIXME,GuillaumeGomez,de41c58c9fe64661bce1ba3803b95bb96bae3a01,1,Rollup merge of #81679 - GuillaumeGomez:clean-fixme-match-bind r=poliorcetics CraftSpider Bind all clean::Type variants and remove FIXME This is simply a little cleanup. cc `@CraftSpider` r? `@poliorcetics`,ROCKET,2021-02-02T23:56:54Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/81687,MERGED,2021-02-02T23:14:17Z,2021-02-10T06:21:54Z,Make Vec::split_at_spare_mut public,WaffleLapkin,e2765f8cbdfce02816aff7bce4c4d41bfea2c5d4,1,Rollup merge of #81687 - WaffleLapkin:split_at_spare r=KodrAus Make Vec::split_at_spare_mut public This PR introduces a new method to the public API under `vec_split_at_spare` feature gate: ```rust impl impl Vec { pub fn split_at_spare_mut(&mut self) -> (&mut [T] &mut [MaybeUninit]); } ``` The method returns 2 slices one slice references the content of the vector and the other references the remaining spare capacity. The method was previously implemented while adding `Vec::extend_from_within` in #79015 and used to implement `Vec::spare_capacity_mut` (as the later is just a subset of former one). See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335). ## Unresolved questions - [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name - [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa) r? `@KodrAus`,THUMBS_UP,2021-02-03T10:13:31Z,the8472,NA https://github.com/rust-lang/rust/pull/81687,MERGED,2021-02-02T23:14:17Z,2021-02-10T06:21:54Z,Make Vec::split_at_spare_mut public,WaffleLapkin,e2765f8cbdfce02816aff7bce4c4d41bfea2c5d4,1,Rollup merge of #81687 - WaffleLapkin:split_at_spare r=KodrAus Make Vec::split_at_spare_mut public This PR introduces a new method to the public API under `vec_split_at_spare` feature gate: ```rust impl impl Vec { pub fn split_at_spare_mut(&mut self) -> (&mut [T] &mut [MaybeUninit]); } ``` The method returns 2 slices one slice references the content of the vector and the other references the remaining spare capacity. The method was previously implemented while adding `Vec::extend_from_within` in #79015 and used to implement `Vec::spare_capacity_mut` (as the later is just a subset of former one). See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335). ## Unresolved questions - [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name - [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa) r? `@KodrAus`,THUMBS_UP,2021-02-10T16:29:05Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/81687,MERGED,2021-02-02T23:14:17Z,2021-02-10T06:21:54Z,Make Vec::split_at_spare_mut public,WaffleLapkin,e2765f8cbdfce02816aff7bce4c4d41bfea2c5d4,1,Rollup merge of #81687 - WaffleLapkin:split_at_spare r=KodrAus Make Vec::split_at_spare_mut public This PR introduces a new method to the public API under `vec_split_at_spare` feature gate: ```rust impl impl Vec { pub fn split_at_spare_mut(&mut self) -> (&mut [T] &mut [MaybeUninit]); } ``` The method returns 2 slices one slice references the content of the vector and the other references the remaining spare capacity. The method was previously implemented while adding `Vec::extend_from_within` in #79015 and used to implement `Vec::spare_capacity_mut` (as the later is just a subset of former one). See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335). ## Unresolved questions - [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name - [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa) r? `@KodrAus`,THUMBS_UP,2021-02-19T03:09:10Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/81687,MERGED,2021-02-02T23:14:17Z,2021-02-10T06:21:54Z,Make Vec::split_at_spare_mut public,WaffleLapkin,e2765f8cbdfce02816aff7bce4c4d41bfea2c5d4,1,Rollup merge of #81687 - WaffleLapkin:split_at_spare r=KodrAus Make Vec::split_at_spare_mut public This PR introduces a new method to the public API under `vec_split_at_spare` feature gate: ```rust impl impl Vec { pub fn split_at_spare_mut(&mut self) -> (&mut [T] &mut [MaybeUninit]); } ``` The method returns 2 slices one slice references the content of the vector and the other references the remaining spare capacity. The method was previously implemented while adding `Vec::extend_from_within` in #79015 and used to implement `Vec::spare_capacity_mut` (as the later is just a subset of former one). See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335). ## Unresolved questions - [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name - [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa) r? `@KodrAus`,THUMBS_UP,2021-02-19T12:24:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/81687,MERGED,2021-02-02T23:14:17Z,2021-02-10T06:21:54Z,Make Vec::split_at_spare_mut public,WaffleLapkin,e2765f8cbdfce02816aff7bce4c4d41bfea2c5d4,1,Rollup merge of #81687 - WaffleLapkin:split_at_spare r=KodrAus Make Vec::split_at_spare_mut public This PR introduces a new method to the public API under `vec_split_at_spare` feature gate: ```rust impl impl Vec { pub fn split_at_spare_mut(&mut self) -> (&mut [T] &mut [MaybeUninit]); } ``` The method returns 2 slices one slice references the content of the vector and the other references the remaining spare capacity. The method was previously implemented while adding `Vec::extend_from_within` in #79015 and used to implement `Vec::spare_capacity_mut` (as the later is just a subset of former one). See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335). ## Unresolved questions - [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name - [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa) r? `@KodrAus`,THUMBS_UP,2021-02-19T15:57:47Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/81713,MERGED,2021-02-03T16:38:53Z,2021-02-25T18:14:55Z,"Account for associated consts in the ""unstable assoc item name colission"" lint",estebank,c5629131fa23a07a47e9b6a25f687ac6791a843f,6,"Rollup merge of #81713 - estebank:unstable-assoc-item-lint r=oli-obk Account for associated consts in the ""unstable assoc item name colission"" lint Fix #81663.",HEART,2021-02-03T21:15:46Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-02-04T08:37:55Z,bluss,NA https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-02-11T09:12:22Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-02-11T10:44:45Z,adamreichold,NA https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-02-11T21:45:59Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-02-16T01:55:41Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/81730,MERGED,2021-02-03T22:01:50Z,2021-02-05T14:52:58Z,Make `Allocator` object-safe,RustyYato,ff3c85fd65fa875d2fa4bfdd790cf8dcfaba6ba3,2,Rollup merge of #81730 - RustyYato:object-safe-allocator r=Amanieu Make `Allocator` object-safe This allows rust-lang/wg-allocators#83: polymorphic allocators,THUMBS_UP,2021-09-27T07:30:34Z,bb010g,NA https://github.com/rust-lang/rust/pull/81732,MERGED,2021-02-03T23:21:55Z,2021-02-22T06:48:04Z,Use `#[rustc_inherit_overflow_checks]` instead of Add::add etc.,m-ou-se,e952db8fd02090a10024ae63ba9d34e3b9cef898,4,Auto merge of #81732 - m-ou-se:inherit-overflow-checks r=Mark-Simulacrum Use `#[rustc_inherit_overflow_checks]` instead of Add::add etc. See https://github.com/rust-lang/rust/issues/81721,THUMBS_UP,2021-02-04T07:48:17Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/81736,MERGED,2021-02-04T02:56:51Z,2021-02-05T12:11:13Z,rustc_codegen_ssa: tune codegen scheduling to reduce memory usage,tgnottingham,730d6dfdddc0f55d9cbeedb29a14b342f74e2a9d,3,Auto merge of #81736 - tgnottingham:tune-cgu-scheduling-for-memory r=nagisa rustc_codegen_ssa: tune codegen scheduling to reduce memory usage For better throughput during parallel processing by LLVM we used to sort CGUs largest to smallest. This would lead to better thread utilization by for example preventing a large CGU from being processed last and having only one LLVM thread working while the rest remained idle. However this strategy would lead to high memory usage as it meant the LLVM-IR for all of the largest CGUs would be resident in memory at once. Instead we can compromise by ordering CGUs such that the largest and smallest are first second largest and smallest are next etc. If there are large size variations this can reduce memory usage significantly.,HEART,2021-02-04T04:44:32Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81736,MERGED,2021-02-04T02:56:51Z,2021-02-05T12:11:13Z,rustc_codegen_ssa: tune codegen scheduling to reduce memory usage,tgnottingham,730d6dfdddc0f55d9cbeedb29a14b342f74e2a9d,3,Auto merge of #81736 - tgnottingham:tune-cgu-scheduling-for-memory r=nagisa rustc_codegen_ssa: tune codegen scheduling to reduce memory usage For better throughput during parallel processing by LLVM we used to sort CGUs largest to smallest. This would lead to better thread utilization by for example preventing a large CGU from being processed last and having only one LLVM thread working while the rest remained idle. However this strategy would lead to high memory usage as it meant the LLVM-IR for all of the largest CGUs would be resident in memory at once. Instead we can compromise by ordering CGUs such that the largest and smallest are first second largest and smallest are next etc. If there are large size variations this can reduce memory usage significantly.,HEART,2021-02-05T04:46:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81741,MERGED,2021-02-04T08:23:30Z,2021-02-13T05:38:04Z,Increment `self.index` before calling `Iterator::self.a.__iterator_ge…,sdroege,0cfba2fd090834c909d5ed9deccdee8170da791b,1,Rollup merge of #81741 - sdroege:zip-trusted-random-access-specialization-panic-safety r=KodrAus Increment `self.index` before calling `Iterator::self.a.__iterator_ge… …`t_unchecked` in `Zip` `TrustedRandomAccess` specialization Otherwise if `Iterator::self.a.__iterator_get_unchecked` panics the index would not have been incremented yet and another call to `Iterator::next` would read from the same index again which is not allowed according to the API contract of `TrustedRandomAccess` for `!Clone`. Fixes https://github.com/rust-lang/rust/issues/81740,HEART,2021-02-04T15:26:59Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-04T15:21:22Z,est31,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-04T15:21:24Z,est31,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-04T15:21:27Z,est31,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-05T00:54:23Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-05T01:43:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-05T01:43:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-05T01:43:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-05T04:43:39Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-05T04:43:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-05T04:43:41Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-07T01:18:53Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-08T17:40:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T13:07:59Z,taiki-e,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-12T21:26:14Z,esposm03,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T22:11:51Z,yerke,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-12T22:11:52Z,yerke,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-12T22:11:53Z,yerke,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-12T22:13:42Z,Bobo1239,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-12T22:19:33Z,g2p,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T22:32:23Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-12T22:40:09Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T22:40:11Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-12T22:40:12Z,pythoneer,dustin.bensing@googlemail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T22:58:30Z,luukvanderduim,luukvanderduim@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-12T23:11:47Z,jasonwilliams,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-13T00:12:58Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-13T01:40:44Z,Celeo,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-13T02:29:35Z,insertt,null@insertt.dev https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-02-13T02:54:35Z,TDHolmes,tyler@holmesengineering.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-13T18:41:54Z,lqd,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-13T21:53:01Z,Tarnadas,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-02-14T16:43:22Z,theduke,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-02-17T14:35:22Z,batisteo,baptiste.darthenay@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-02-23T17:21:47Z,cole-miller,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-03-19T13:00:46Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-03-30T07:42:28Z,mati865,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-09T20:39:26Z,androm3da,bcain@quicinc.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-09T22:08:30Z,brson,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-09T23:20:37Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-04-09T23:41:39Z,D1plo1d,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-09T23:41:57Z,D1plo1d,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T00:04:46Z,weihanglo,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T00:04:46Z,weihanglo,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T00:04:47Z,weihanglo,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T00:04:47Z,weihanglo,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T01:20:42Z,funbringer,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T02:34:06Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T02:34:08Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T02:34:09Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-04-10T02:34:10Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T02:34:10Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T04:36:20Z,Congee,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T06:42:46Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T08:09:12Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T08:17:56Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T08:17:57Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T08:17:57Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T08:17:58Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-04-10T08:17:59Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T10:06:21Z,Inky-developer,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T10:14:03Z,Agrailag,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T10:14:05Z,Agrailag,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T11:22:56Z,Meralis40,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T11:22:57Z,Meralis40,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-10T11:23:13Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-10T14:16:50Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T14:16:51Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T14:16:52Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-10T17:21:49Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-10T21:52:39Z,harrysarson,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-11T03:08:11Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-11T03:08:12Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-11T06:59:22Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-12T02:44:53Z,pymongo,os.popen@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-13T03:43:14Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-23T13:52:56Z,ljedrz,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-04-27T17:04:23Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-04-27T17:04:24Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-04-27T17:04:24Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-04-27T17:04:25Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-04-27T17:04:26Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-05-01T17:49:54Z,Skgland,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-05-01T21:09:00Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-05-01T21:09:01Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-05-02T17:30:01Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-05-02T17:49:14Z,lynzrand,i@rynco.me https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-05-05T06:05:31Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-05-06T21:06:43Z,macpp,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-05-08T23:39:01Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-05-08T23:40:16Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-05-08T23:40:17Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-05-08T23:40:20Z,ArniDagur,arni@dagur.eu https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-05-31T22:23:35Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-05-31T22:23:35Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-06-14T15:34:59Z,vultix,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-06-14T15:35:00Z,vultix,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-07-17T12:54:42Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-07-18T20:06:43Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-07-18T20:06:44Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-07-25T21:37:40Z,a1phyr,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-07-27T13:19:15Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,EYES,2021-08-09T16:28:18Z,afonso360,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-08-14T19:24:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-08-14T19:24:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-08-14T19:24:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-08-14T19:24:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-09-10T11:22:48Z,dnbln,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-09-10T11:22:51Z,dnbln,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-09-10T11:22:51Z,dnbln,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-10-22T08:30:35Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2021-11-14T20:43:40Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-11-14T20:43:42Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-11-14T20:43:44Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,ROCKET,2021-11-14T20:43:45Z,bytesnake,bytesnake@mailbox.org https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2021-12-02T17:52:22Z,mre,matthias@endler.dev https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2021-12-12T13:55:52Z,teymour-aldridge,teymour@reasoning.page https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2022-01-18T06:43:33Z,yerke,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2022-02-18T21:17:07Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2022-03-24T03:17:08Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2022-05-19T07:29:44Z,Tyestor,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2022-05-27T15:16:30Z,ZetaNumbers,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2022-06-12T11:42:23Z,kamulos,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2022-06-16T23:26:01Z,thisisphan,NA https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2022-06-24T20:58:58Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,THUMBS_UP,2022-06-25T06:52:43Z,theoparis,theoparisdesigns@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HEART,2022-06-25T06:52:44Z,theoparis,theoparisdesigns@gmail.com https://github.com/rust-lang/rust/pull/81746,OPEN,2021-02-04T10:26:21Z,NA,Distribute cg_clif as rustup component on the nightly channel,bjorn3,NA,NA,NA,HOORAY,2022-06-25T06:52:44Z,theoparis,theoparisdesigns@gmail.com https://github.com/rust-lang/rust/pull/81747,CLOSED,2021-02-04T10:33:09Z,2021-03-27T10:13:40Z,Remove unnecessary abstractions from option and result impls,tmiasko,NA,NA,NA,THUMBS_UP,2021-02-04T12:48:38Z,tesuji,NA https://github.com/rust-lang/rust/pull/81747,CLOSED,2021-02-04T10:33:09Z,2021-03-27T10:13:40Z,Remove unnecessary abstractions from option and result impls,tmiasko,NA,NA,NA,THUMBS_UP,2021-02-04T14:16:35Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/81768,MERGED,2021-02-05T01:15:50Z,2021-02-10T12:56:13Z,update RLS and rustfmt,calebcartwright,218bf8d7657e1aadf6f499651078f3710df20c7b,5,Auto merge of #81768 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #81582 and fixes #81583 r? `@Xanewok` I was originally surprised by the size of lockfile diff though after looking at the RLS changes it makes a bit more sense to me now,HEART,2021-02-08T22:48:39Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/81768,MERGED,2021-02-05T01:15:50Z,2021-02-10T12:56:13Z,update RLS and rustfmt,calebcartwright,218bf8d7657e1aadf6f499651078f3710df20c7b,5,Auto merge of #81768 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #81582 and fixes #81583 r? `@Xanewok` I was originally surprised by the size of lockfile diff though after looking at the RLS changes it makes a bit more sense to me now,HEART,2021-02-11T00:15:14Z,ehuss,NA https://github.com/rust-lang/rust/pull/81769,MERGED,2021-02-05T01:37:16Z,2021-02-23T07:19:44Z,Suggest `return`ing tail expressions that match return type,estebank,5d90e89c36468350b9636614b0f9dbf64a4aef80,22,"Rollup merge of #81769 - estebank:tail-expr-as-potential-return r=lcnr Suggest `return`ing tail expressions that match return type Some newcomers are confused by the behavior of tail expressions interpreting that ""leaving out the `;` makes it the return value"". To help them go in the right direction suggest using `return` instead when applicable.",HEART,2021-03-04T17:34:06Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/81771,MERGED,2021-02-05T02:55:02Z,2021-02-05T14:52:58Z,Indicate change in RSS from start to end of pass in time-passes output,tgnottingham,08d8fc14beef6708f04cafda6cd99425cf145b04,1,Rollup merge of #81771 - tgnottingham:time-passes-rss-delta r=oli-obk Indicate change in RSS from start to end of pass in time-passes output Previously this was omitted because it could be misleading but the functionality seems too useful not to include. r? ``@oli-obk``,HEART,2021-02-05T10:02:02Z,oli-obk,NA https://github.com/rust-lang/rust/pull/81782,CLOSED,2021-02-05T10:52:24Z,2021-03-30T06:14:35Z,Replace jemalloc with mimalloc config.toml option,jq-rs,NA,NA,NA,HEART,2021-02-05T18:50:56Z,lnicola,NA https://github.com/rust-lang/rust/pull/81782,CLOSED,2021-02-05T10:52:24Z,2021-03-30T06:14:35Z,Replace jemalloc with mimalloc config.toml option,jq-rs,NA,NA,NA,HEART,2021-03-16T07:11:13Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/81789,CLOSED,2021-02-05T12:55:54Z,2021-05-18T18:19:54Z,Implement new lint for detecting buggy pointer-to-int casts,osa1,NA,NA,NA,HEART,2021-02-26T03:11:24Z,tesuji,NA https://github.com/rust-lang/rust/pull/81797,MERGED,2021-02-05T17:42:22Z,2021-08-04T02:03:57Z,Add `core::stream::from_iter`,yoshuawuyts,ad74828b506866a96c6b25501f64b1262a5693f8,2,"Rollup merge of #81797 - yoshuawuyts:stream_from_iter r=dtolnay Add `core::stream::from_iter` _Tracking issue: https://github.com/rust-lang/rust/issues/81798_ This_ PR implements `std::stream::from_iter` as outlined in the _""Converting an Iterator to a Stream""_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance. r? `@tmandry` cc/ `@rust-lang/libs` `@rust-lang/wg-async-foundations` ## Example Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this: **before** ```rust let mut output = vec![]; for item in my_vec { let out = do_io(item).await?; output.push(out); } ``` **after** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow. ## Implementation Notes This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`. This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method which we can remove as part of stabilization if by any chance we don't have `Stream::next`. ## Alternatives Considered ### `impl IntoStream for T: IntoIterator` An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: ""perhaps but it could cause type issues"". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter` which wouldn't be possible if it was implemented through a catch-all trait. Possibly an alternative such as `impl IntoStream for T: Iterator` could work but it feels somewhat restrictive. In the end converting an iterator to a stream is likely to be a bit of a niche case. And even then **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**. ### Naming The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures) and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`. ## Future Directions ### Stream conversions for collections This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections` `std::vec` and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether: **before** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` **after** ```rust let output = my_vec .stream() .map(async |item| do_io(item).await) .collect()?; ```",THUMBS_UP,2021-02-11T01:17:38Z,tmandry,NA https://github.com/rust-lang/rust/pull/81797,MERGED,2021-02-05T17:42:22Z,2021-08-04T02:03:57Z,Add `core::stream::from_iter`,yoshuawuyts,ad74828b506866a96c6b25501f64b1262a5693f8,2,"Rollup merge of #81797 - yoshuawuyts:stream_from_iter r=dtolnay Add `core::stream::from_iter` _Tracking issue: https://github.com/rust-lang/rust/issues/81798_ This_ PR implements `std::stream::from_iter` as outlined in the _""Converting an Iterator to a Stream""_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance. r? `@tmandry` cc/ `@rust-lang/libs` `@rust-lang/wg-async-foundations` ## Example Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this: **before** ```rust let mut output = vec![]; for item in my_vec { let out = do_io(item).await?; output.push(out); } ``` **after** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow. ## Implementation Notes This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`. This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method which we can remove as part of stabilization if by any chance we don't have `Stream::next`. ## Alternatives Considered ### `impl IntoStream for T: IntoIterator` An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: ""perhaps but it could cause type issues"". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter` which wouldn't be possible if it was implemented through a catch-all trait. Possibly an alternative such as `impl IntoStream for T: Iterator` could work but it feels somewhat restrictive. In the end converting an iterator to a stream is likely to be a bit of a niche case. And even then **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**. ### Naming The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures) and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`. ## Future Directions ### Stream conversions for collections This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections` `std::vec` and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether: **before** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` **after** ```rust let output = my_vec .stream() .map(async |item| do_io(item).await) .collect()?; ```",THUMBS_UP,2021-03-18T22:03:42Z,nellshamrell,nellshamrell@gmail.com https://github.com/rust-lang/rust/pull/81797,MERGED,2021-02-05T17:42:22Z,2021-08-04T02:03:57Z,Add `core::stream::from_iter`,yoshuawuyts,ad74828b506866a96c6b25501f64b1262a5693f8,2,"Rollup merge of #81797 - yoshuawuyts:stream_from_iter r=dtolnay Add `core::stream::from_iter` _Tracking issue: https://github.com/rust-lang/rust/issues/81798_ This_ PR implements `std::stream::from_iter` as outlined in the _""Converting an Iterator to a Stream""_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance. r? `@tmandry` cc/ `@rust-lang/libs` `@rust-lang/wg-async-foundations` ## Example Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this: **before** ```rust let mut output = vec![]; for item in my_vec { let out = do_io(item).await?; output.push(out); } ``` **after** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow. ## Implementation Notes This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`. This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method which we can remove as part of stabilization if by any chance we don't have `Stream::next`. ## Alternatives Considered ### `impl IntoStream for T: IntoIterator` An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: ""perhaps but it could cause type issues"". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter` which wouldn't be possible if it was implemented through a catch-all trait. Possibly an alternative such as `impl IntoStream for T: Iterator` could work but it feels somewhat restrictive. In the end converting an iterator to a stream is likely to be a bit of a niche case. And even then **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**. ### Naming The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures) and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`. ## Future Directions ### Stream conversions for collections This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections` `std::vec` and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether: **before** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` **after** ```rust let output = my_vec .stream() .map(async |item| do_io(item).await) .collect()?; ```",THUMBS_UP,2021-06-23T22:26:43Z,caspervonb,caspervonb@pm.me https://github.com/rust-lang/rust/pull/81797,MERGED,2021-02-05T17:42:22Z,2021-08-04T02:03:57Z,Add `core::stream::from_iter`,yoshuawuyts,ad74828b506866a96c6b25501f64b1262a5693f8,2,"Rollup merge of #81797 - yoshuawuyts:stream_from_iter r=dtolnay Add `core::stream::from_iter` _Tracking issue: https://github.com/rust-lang/rust/issues/81798_ This_ PR implements `std::stream::from_iter` as outlined in the _""Converting an Iterator to a Stream""_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance. r? `@tmandry` cc/ `@rust-lang/libs` `@rust-lang/wg-async-foundations` ## Example Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this: **before** ```rust let mut output = vec![]; for item in my_vec { let out = do_io(item).await?; output.push(out); } ``` **after** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow. ## Implementation Notes This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`. This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method which we can remove as part of stabilization if by any chance we don't have `Stream::next`. ## Alternatives Considered ### `impl IntoStream for T: IntoIterator` An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: ""perhaps but it could cause type issues"". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter` which wouldn't be possible if it was implemented through a catch-all trait. Possibly an alternative such as `impl IntoStream for T: Iterator` could work but it feels somewhat restrictive. In the end converting an iterator to a stream is likely to be a bit of a niche case. And even then **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**. ### Naming The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures) and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`. ## Future Directions ### Stream conversions for collections This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections` `std::vec` and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether: **before** ```rust use std::stream; let output = stream::from_iter(my_vec.iter()) .map(async |item| do_io(item).await) .collect()?; ``` **after** ```rust let output = my_vec .stream() .map(async |item| do_io(item).await) .collect()?; ```",THUMBS_UP,2021-08-11T12:24:17Z,GrayJack,NA https://github.com/rust-lang/rust/pull/81807,CLOSED,2021-02-05T22:12:12Z,2021-11-22T02:51:22Z,io/os: Implement IsTerminal trait on Stdio,mattwilkinsonn,NA,NA,NA,THUMBS_UP,2021-11-01T17:57:33Z,r00ster91,NA https://github.com/rust-lang/rust/pull/81822,MERGED,2021-02-06T12:32:26Z,2021-03-16T19:19:09Z,Added `try_exists()` method to `std::path::Path`,Kixunil,62d38da9fab089520b0e10e71a54be0d30b0490a,1,Rollup merge of #81822 - Kixunil:path_try_exists r=kennytm Added `try_exists()` method to `std::path::Path` This method is similar to the existing `exists()` method except it doesn't silently ignore the errors leading to less error-prone code. This change intentionally does NOT touch the documentation of `exists()` nor recommend people to use this method while it's unstable. Such changes are reserved for stabilization to prevent confusing people. Apart from that it avoids conflicts with #80979. `@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil),THUMBS_UP,2021-02-06T21:14:59Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/81822,MERGED,2021-02-06T12:32:26Z,2021-03-16T19:19:09Z,Added `try_exists()` method to `std::path::Path`,Kixunil,62d38da9fab089520b0e10e71a54be0d30b0490a,1,Rollup merge of #81822 - Kixunil:path_try_exists r=kennytm Added `try_exists()` method to `std::path::Path` This method is similar to the existing `exists()` method except it doesn't silently ignore the errors leading to less error-prone code. This change intentionally does NOT touch the documentation of `exists()` nor recommend people to use this method while it's unstable. Such changes are reserved for stabilization to prevent confusing people. Apart from that it avoids conflicts with #80979. `@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil),THUMBS_UP,2021-07-18T10:25:57Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/81822,MERGED,2021-02-06T12:32:26Z,2021-03-16T19:19:09Z,Added `try_exists()` method to `std::path::Path`,Kixunil,62d38da9fab089520b0e10e71a54be0d30b0490a,1,Rollup merge of #81822 - Kixunil:path_try_exists r=kennytm Added `try_exists()` method to `std::path::Path` This method is similar to the existing `exists()` method except it doesn't silently ignore the errors leading to less error-prone code. This change intentionally does NOT touch the documentation of `exists()` nor recommend people to use this method while it's unstable. Such changes are reserved for stabilization to prevent confusing people. Apart from that it avoids conflicts with #80979. `@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil),THUMBS_UP,2022-03-02T15:15:35Z,edmorley,NA https://github.com/rust-lang/rust/pull/81825,MERGED,2021-02-06T13:24:01Z,2021-08-01T19:04:41Z,Add Linux-specific pidfd process extensions (take 2),voidc,4e21ef2a4eca12180e24a345d66066fc1e4e36da,8,Auto merge of #81825 - voidc:pidfd r=joshtriplett Add Linux-specific pidfd process extensions (take 2) Continuation of #77168. I addressed the following concerns from the original PR: - make `CommandExt` and `ChildExt` sealed traits - wrap file descriptors in `PidFd` struct representing ownership over the fd - add `take_pidfd` to take the fd out of `Child` - close fd when dropped Tracking Issue: #82971,HEART,2021-02-06T20:57:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/81825,MERGED,2021-02-06T13:24:01Z,2021-08-01T19:04:41Z,Add Linux-specific pidfd process extensions (take 2),voidc,4e21ef2a4eca12180e24a345d66066fc1e4e36da,8,Auto merge of #81825 - voidc:pidfd r=joshtriplett Add Linux-specific pidfd process extensions (take 2) Continuation of #77168. I addressed the following concerns from the original PR: - make `CommandExt` and `ChildExt` sealed traits - wrap file descriptors in `PidFd` struct representing ownership over the fd - add `take_pidfd` to take the fd out of `Child` - close fd when dropped Tracking Issue: #82971,HEART,2021-03-13T22:45:03Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/81825,MERGED,2021-02-06T13:24:01Z,2021-08-01T19:04:41Z,Add Linux-specific pidfd process extensions (take 2),voidc,4e21ef2a4eca12180e24a345d66066fc1e4e36da,8,Auto merge of #81825 - voidc:pidfd r=joshtriplett Add Linux-specific pidfd process extensions (take 2) Continuation of #77168. I addressed the following concerns from the original PR: - make `CommandExt` and `ChildExt` sealed traits - wrap file descriptors in `PidFd` struct representing ownership over the fd - add `take_pidfd` to take the fd out of `Child` - close fd when dropped Tracking Issue: #82971,HEART,2021-09-04T16:47:21Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/81833,MERGED,2021-02-06T16:41:43Z,2021-02-21T15:04:45Z,parallelize x.py test tidy,the8472,4c1f195e0b5de82d40da8a1bd6bbbe049d586c6b,1,"Rollup merge of #81833 - the8472:parallel-bootstrap-rustfmt r=Mark-Simulacrum parallelize x.py test tidy Running tidy on individual commits when rewriting git history was somewhat of an annoyance so I have parallelized it a bit. running `time ./x.py test tidy` with warm IO caches: old: ``` real 0m11.123s user 0m14.495s sys 0m5.227s ``` new: ``` real 0m1.834s user 0m13.545s sys 0m3.094s ``` There's further room for improvement (<0.9s should be feasible) but that would require bigger changes.",HEART,2021-02-06T17:48:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/81833,MERGED,2021-02-06T16:41:43Z,2021-02-21T15:04:45Z,parallelize x.py test tidy,the8472,4c1f195e0b5de82d40da8a1bd6bbbe049d586c6b,1,"Rollup merge of #81833 - the8472:parallel-bootstrap-rustfmt r=Mark-Simulacrum parallelize x.py test tidy Running tidy on individual commits when rewriting git history was somewhat of an annoyance so I have parallelized it a bit. running `time ./x.py test tidy` with warm IO caches: old: ``` real 0m11.123s user 0m14.495s sys 0m5.227s ``` new: ``` real 0m1.834s user 0m13.545s sys 0m3.094s ``` There's further room for improvement (<0.9s should be feasible) but that would require bigger changes.",HEART,2021-02-06T20:40:16Z,akraines,NA https://github.com/rust-lang/rust/pull/81833,MERGED,2021-02-06T16:41:43Z,2021-02-21T15:04:45Z,parallelize x.py test tidy,the8472,4c1f195e0b5de82d40da8a1bd6bbbe049d586c6b,1,"Rollup merge of #81833 - the8472:parallel-bootstrap-rustfmt r=Mark-Simulacrum parallelize x.py test tidy Running tidy on individual commits when rewriting git history was somewhat of an annoyance so I have parallelized it a bit. running `time ./x.py test tidy` with warm IO caches: old: ``` real 0m11.123s user 0m14.495s sys 0m5.227s ``` new: ``` real 0m1.834s user 0m13.545s sys 0m3.094s ``` There's further room for improvement (<0.9s should be feasible) but that would require bigger changes.",HEART,2021-02-20T23:55:04Z,camelid,NA https://github.com/rust-lang/rust/pull/81848,CLOSED,2021-02-07T01:42:02Z,2021-03-01T15:04:48Z,Remove rustc-dev-guide submodule,camelid,NA,NA,NA,THUMBS_UP,2021-02-07T06:02:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81849,MERGED,2021-02-07T06:37:36Z,2021-02-09T08:47:51Z,Expand the docs for ops::ControlFlow a bit,scottmcm,a63085dc5e718ad75a4571e9522d8a62a7c18ef1,4,Rollup merge of #81849 - scottmcm:control-flow-comments r=Mark-Simulacrum Expand the docs for ops::ControlFlow a bit Since I was writing some examples for an RFC anyway. And I almost made the mistake of reordering the variants so added a note and a test about that.,HEART,2021-02-09T14:34:19Z,bluss,NA https://github.com/rust-lang/rust/pull/81855,MERGED,2021-02-07T15:25:03Z,2021-02-15T15:14:35Z,Check the result cache before the DepGraph when ensuring queries,cjgillot,d1206f950ffb76c76e1b74a19ae33c2b7d949454,9,Auto merge of #81855 - cjgillot:ensure-cache r=oli-obk Check the result cache before the DepGraph when ensuring queries Split out of https://github.com/rust-lang/rust/pull/70951 Calling `ensure` on already forced queries is a common operation. Looking at the results cache first is faster than checking the DepGraph for a green node.,THUMBS_UP,2021-02-07T17:54:26Z,tesuji,NA https://github.com/rust-lang/rust/pull/81855,MERGED,2021-02-07T15:25:03Z,2021-02-15T15:14:35Z,Check the result cache before the DepGraph when ensuring queries,cjgillot,d1206f950ffb76c76e1b74a19ae33c2b7d949454,9,Auto merge of #81855 - cjgillot:ensure-cache r=oli-obk Check the result cache before the DepGraph when ensuring queries Split out of https://github.com/rust-lang/rust/pull/70951 Calling `ensure` on already forced queries is a common operation. Looking at the results cache first is faster than checking the DepGraph for a green node.,HEART,2021-02-07T18:20:24Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,HEART,2021-03-06T10:15:55Z,akhramov,akhramov@pm.me https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,HEART,2021-04-17T08:00:55Z,Urgau,NA https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,THUMBS_UP,2021-05-16T07:42:02Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,HEART,2021-05-16T17:01:49Z,bluss,NA https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,HEART,2021-05-21T06:37:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/81858,MERGED,2021-02-07T19:02:03Z,2021-05-16T00:54:03Z,Do not allocate or unwind after fork,ijackson,d565c7488749fd0e998d6be21efeb20354e4696d,7,Auto merge of #81858 - ijackson:fork-no-unwind r=m-ou-se Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook` including most `panic!` calls `Option::unwrap` and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs where panic in `pre_exec_hook` is already memory-safe prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe` beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to at runtime switch to having panics abort. This makes it possible to panic without making *any* heap allocations which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370 and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular thanks to `@m-ou-se ` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263 this MR has very substantial changes and additions. Additionally I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`,THUMBS_UP,2021-10-05T18:15:26Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/81866,MERGED,2021-02-07T23:08:49Z,2021-04-03T01:52:39Z,Maintain supported sanitizers as a target property,nagisa,9b6c9b638e0148409b6568b61f763e87dc8fd3bf,24,Auto merge of #81866 - nagisa:nagisa/sanitizer-support-target-prop r=tmiasko Maintain supported sanitizers as a target property In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence this PR moves the configuration to the target options. Perhaps the one notable change made in this PR is this doc-comment: ```rust /// The sanitizers supported by this target /// /// Note that the support here is at a codegen level. If the machine code with sanitizer /// enabled can generated on this target but the necessary supporting libraries are not /// distributed with the target the sanitizer should still appear in this list for the target. ``` Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found. Fixes #81802,THUMBS_UP,2021-02-19T03:30:05Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/81866,MERGED,2021-02-07T23:08:49Z,2021-04-03T01:52:39Z,Maintain supported sanitizers as a target property,nagisa,9b6c9b638e0148409b6568b61f763e87dc8fd3bf,24,Auto merge of #81866 - nagisa:nagisa/sanitizer-support-target-prop r=tmiasko Maintain supported sanitizers as a target property In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence this PR moves the configuration to the target options. Perhaps the one notable change made in this PR is this doc-comment: ```rust /// The sanitizers supported by this target /// /// Note that the support here is at a codegen level. If the machine code with sanitizer /// enabled can generated on this target but the necessary supporting libraries are not /// distributed with the target the sanitizer should still appear in this list for the target. ``` Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found. Fixes #81802,THUMBS_UP,2021-02-22T09:05:56Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/81874,MERGED,2021-02-08T05:19:19Z,2021-02-27T17:35:35Z,Specialize slice::fill with Copy type and u8/i8/bool,tesuji,ec7f8d94df0251532c47330abcb7988d77a1f818,2,Auto merge of #81874 - tesuji:spec_slice_fill r=matthewjasper Specialize slice::fill with Copy type and u8/i8/bool I don't expect rustperf could measure any perf improvements with this changes since `slice::fill` is newly added. Godbolt link for this change: . r? `@matthewjasper` since this patch added new specialization.,HOORAY,2021-02-27T17:46:01Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/81879,MERGED,2021-02-08T12:13:15Z,2021-03-09T12:29:09Z,Added #[repr(transparent)] to core::cmp::Reverse,imbrem,0083e6c989160689858e5f6ae7a570c46f7f4f14,1,Rollup merge of #81879 - imbrem:make-reverse-repr-transparent r=m-ou-se Added #[repr(transparent)] to core::cmp::Reverse I found casting from an `&T` to an `&Reverse` potentially useful but found that `Reverse` was not `#[repr(transparent)]` so after asking about it [on Reddit](https://www.reddit.com/r/rust/comments/le60uv/make_stdcmpreverse_reprtransparent_and_add_a/) I decided to go ahead and make a pull request which simply adds the attribute to the struct.,THUMBS_UP,2021-03-18T18:49:26Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/81888,MERGED,2021-02-08T18:05:09Z,2021-02-09T08:47:51Z,Fix pretty printer macro_rules with semicolon.,ehuss,78c01537576e813e3530cf776f2528bf7c063181,2,Rollup merge of #81888 - ehuss:macro_rules-pp r=petrochenkov Fix pretty printer macro_rules with semicolon. The pretty printer was not including the trailing semicolon for a macro_rules definition that used parenthesis or brackets which results in invalid code. This adds the semicolon in those two cases.,HEART,2021-02-08T23:30:11Z,ElusiveMori,me@mori.dev https://github.com/rust-lang/rust/pull/81891,MERGED,2021-02-08T19:08:24Z,2021-02-15T01:16:30Z,[rustdoc-json] Make `header` a vec of modifiers and FunctionPointer consistent,CraftSpider,641c3785dc875744fae75d5c1db12708a819e235,7,Rollup merge of #81891 - CraftSpider:fn-header r=jyn514 [rustdoc-json] Make `header` a vec of modifiers and FunctionPointer consistent Bumps version number and adds tests this is a breaking change. I can split this into two (`is_unsafe` -> `header` and `header: Vec`) if desired. Rationale: Modifiers are individual notes on a function it makes more sense for them to be a list of an independent enum over a String which is inconsistently exposing the HIR representation (prefix_str vs custom literals). Function pointers currently only support `unsafe` but there has been talk on and off about allowing them to also support `const` and this makes handling their modifiers consistent with handling those of a function allowing better shared code. `@rustbot` modify labels: +A-rustdoc-json +T-rustdoc CC: `@HeroicKatora` r? `@jyn514`,HEART,2021-02-09T07:05:25Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/81913,MERGED,2021-02-09T08:28:39Z,2021-02-10T06:21:53Z,Rename HIR UnOp variants,osa1,a58feb9282c8e7df7f436d2c78147c36c422867c,41,"Rollup merge of #81913 - osa1:rename_unop_variants r=matthewjasper Rename HIR UnOp variants This renames the variants in HIR UnOp from enum UnOp { UnDeref UnNot UnNeg } to enum UnOp { Deref Not Neg } Motivations: - This is more consistent with the rest of the code base where most enum variants don't have a prefix. - These variants are never used without the `UnOp` prefix so the extra `Un` prefix doesn't help with readability. E.g. we don't have any `UnDeref`s in the code we only have `UnOp::UnDeref`. - MIR `UnOp` type variants don't have a prefix so this is more consistent with MIR types. - ""un"" prefix reads like ""inverse"" or ""reverse"" so as a beginner in rustc code base when I see ""UnDeref"" what comes to my mind is something like `&*` instead of just `*`.",THUMBS_UP,2021-02-12T16:27:09Z,camsteffen,NA https://github.com/rust-lang/rust/pull/81914,MERGED,2021-02-09T08:42:39Z,2021-02-15T01:16:30Z,Fixing bad suggestion for `_` in `const` type when a function #81885,kper,a6809d00aed27db9ac99841d2bd34060a77d2708,7,Rollup merge of #81914 - kper:fixing-81885 r=estebank Fixing bad suggestion for `_` in `const` type when a function #81885 Closes #81885 ``` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item_help.rs:13:22 | LL | const TEST4: fn() -> _ = 42; | ^ | | | not allowed in type signatures | help: use type parameters instead: `T` ``` Do not show the suggestion `help: use type parameters instead: T` when `fn`,THUMBS_UP,2021-02-09T10:35:23Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/81914,MERGED,2021-02-09T08:42:39Z,2021-02-15T01:16:30Z,Fixing bad suggestion for `_` in `const` type when a function #81885,kper,a6809d00aed27db9ac99841d2bd34060a77d2708,7,Rollup merge of #81914 - kper:fixing-81885 r=estebank Fixing bad suggestion for `_` in `const` type when a function #81885 Closes #81885 ``` error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item_help.rs:13:22 | LL | const TEST4: fn() -> _ = 42; | ^ | | | not allowed in type signatures | help: use type parameters instead: `T` ``` Do not show the suggestion `help: use type parameters instead: T` when `fn`,THUMBS_UP,2021-02-09T18:12:34Z,estebank,NA https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-02-12T04:22:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-02-22T12:03:03Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-02-22T12:03:06Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-02-23T02:45:42Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-03-01T17:55:38Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/81917,MERGED,2021-02-09T10:29:17Z,2021-03-23T04:49:39Z,Update RELEASES.md for 1.51.0,XAMPPRocky,9cae1fb94a50b768b184248ccccbadf082edf9d6,1,Rollup merge of #81917 - rust-lang:relnotes-1.51.0 r=Mark-Simulacrum Update RELEASES.md for 1.51.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.51.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-03-01T17:55:38Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/81926,MERGED,2021-02-09T13:14:57Z,2021-02-10T06:21:53Z,add suggestion to use the `async_recursion` crate,henryboisdequin,2e8e591a16a2ced9715c4f93cd0c3b3fdf82b712,3,Rollup merge of #81926 - henryboisdequin:fix-81907 r=estebank add suggestion to use the `async_recursion` crate Closes #81907 CC `@estebank`,HEART,2021-02-09T18:06:12Z,estebank,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-02-09T22:53:37Z,rvolgers,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-02-10T08:20:43Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HEART,2021-02-10T08:20:46Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-02-19T13:06:15Z,Johannesd3,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-02-27T01:59:28Z,gwy15,gwy15thu@gmail.com https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HEART,2021-03-30T11:37:47Z,CGMossa,NA https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-04-20T20:30:43Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-07-06T09:04:51Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/81940,MERGED,2021-02-09T22:44:47Z,2021-02-26T21:59:01Z,Stabilize str_split_once,jhpratt,0db8349fff644b0073f3560085c6266e9871bebd,12,Rollup merge of #81940 - jhpratt:stabilize-str_split_once r=m-ou-se Stabilize str_split_once Closes #74773,HOORAY,2021-11-27T09:23:33Z,Zireael07,NA https://github.com/rust-lang/rust/pull/81969,MERGED,2021-02-10T18:37:51Z,2021-02-23T07:19:43Z,Avoid `cfg_if` in `std::os`,jonas-schievink,c3de8ab9082be2c838132f2547d681633c2bb6fc,1,Rollup merge of #81969 - jonas-schievink:no-cfg-if r=Mark-Simulacrum Avoid `cfg_if` in `std::os` rust-analyzer cannot currently load the `cfg_if` crate which means that rust-analyzer is unable to see `std::os::{unix windows linux}` here. This works around that by avoiding `cfg_if`; the `#[cfg]` expressions are simple enough to reasonably write by hand. Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6038,HOORAY,2021-02-22T15:41:30Z,noproto,NA https://github.com/rust-lang/rust/pull/81988,CLOSED,2021-02-11T04:27:45Z,2021-04-21T15:58:38Z,Add doc aliases for a lot of the C standard library,jyn514,NA,NA,NA,ROCKET,2021-02-15T04:03:53Z,lopopolo,NA https://github.com/rust-lang/rust/pull/81988,CLOSED,2021-02-11T04:27:45Z,2021-04-21T15:58:38Z,Add doc aliases for a lot of the C standard library,jyn514,NA,NA,NA,HOORAY,2021-02-23T20:51:58Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/81988,CLOSED,2021-02-11T04:27:45Z,2021-04-21T15:58:38Z,Add doc aliases for a lot of the C standard library,jyn514,NA,NA,NA,HEART,2021-04-07T16:46:31Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/81991,MERGED,2021-02-11T10:02:39Z,2021-02-21T00:19:46Z,Fix panic in 'remove semicolon' when types are not local,osa1,39af0257411b89c93d8cdffeb26a8d58db72efa7,5,"Rollup merge of #81991 - osa1:issue81839 r=estebank Fix panic in 'remove semicolon' when types are not local It's not possible to check if removing a semicolon fixes the type error when checking match arms and one or both of the last arm's and the current arm's return types are imported ""opaque"" types. In these cases we don't generate a ""consider removing semicolon"" suggestions. Fixes #81839 --- I'm not sure how to add a test for this. I think the test would need at least two crates. Do we have any existing tests that do this so that I can take a look?",ROCKET,2021-02-19T01:53:39Z,estebank,NA https://github.com/rust-lang/rust/pull/81995,MERGED,2021-02-11T15:57:14Z,2021-02-13T10:55:20Z,Fix suggestion to introduce explicit lifetime,0yoyoyo,14b217c43e5ad90d881af2957be4fcb0049902a0,4,Rollup merge of #81995 - 0yoyoyo:fix-issue-81650-explicit-lifetime-error r=estebank Fix suggestion to introduce explicit lifetime Addresses #81650 Error message after fix: ``` error[E0311]: the parameter type `T` may not live long enough --> src/main.rs:25:11 | 24 | fn play_with(scope: &Scope animal: T) { | -- help: consider adding an explicit lifetime bound...: `T: 'a +` 25 | scope.spawn(move |_| { | ^^^^^ | note: the parameter type `T` must be valid for the anonymous lifetime #2 defined on the function body at 24:1... --> src/main.rs:24:1 | 24 | fn play_with(scope: &Scope animal: T) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...so that the type `[closure@src/main.rs:25:17: 27:6]` will meet its required lifetime bounds --> src/main.rs:25:11 | 25 | scope.spawn(move |_| { | ^^^^^ ```,HEART,2021-02-11T17:47:22Z,estebank,NA https://github.com/rust-lang/rust/pull/82002,CLOSED,2021-02-11T19:32:48Z,2021-04-19T03:55:06Z,Add `BinaryHeap::contains` and `BinaryHeap::remove`,billyrieger,NA,NA,NA,HEART,2021-02-17T15:15:41Z,est31,NA https://github.com/rust-lang/rust/pull/82009,MERGED,2021-02-11T22:53:35Z,2021-02-16T05:45:14Z,const_generics: Dont evaluate array length const when handling errors,BoxyUwU,6fde3c54385b92711a9087336fb6ab43000e9fad,4,Rollup merge of #82009 - BoxyUwU:idontknooow r=varkor const_generics: Dont evaluate array length const when handling errors Fixes #79518 Fixes #78246 cc ````@lcnr```` This was ICE'ing because we dont pass in the correct ``ParamEnv`` which meant that there was no ``Self: Foo`` predicate to make ``Self::Assoc`` well formed which caused an ICE when trying to normalize ``Self::Assoc`` in the mir interpreter r? ````@varkor````,HEART,2021-02-12T16:57:34Z,varkor,NA https://github.com/rust-lang/rust/pull/82009,MERGED,2021-02-11T22:53:35Z,2021-02-16T05:45:14Z,const_generics: Dont evaluate array length const when handling errors,BoxyUwU,6fde3c54385b92711a9087336fb6ab43000e9fad,4,Rollup merge of #82009 - BoxyUwU:idontknooow r=varkor const_generics: Dont evaluate array length const when handling errors Fixes #79518 Fixes #78246 cc ````@lcnr```` This was ICE'ing because we dont pass in the correct ``ParamEnv`` which meant that there was no ``Self: Foo`` predicate to make ``Self::Assoc`` well formed which caused an ICE when trying to normalize ``Self::Assoc`` in the mir interpreter r? ````@varkor````,HEART,2021-02-12T23:48:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82009,MERGED,2021-02-11T22:53:35Z,2021-02-16T05:45:14Z,const_generics: Dont evaluate array length const when handling errors,BoxyUwU,6fde3c54385b92711a9087336fb6ab43000e9fad,4,Rollup merge of #82009 - BoxyUwU:idontknooow r=varkor const_generics: Dont evaluate array length const when handling errors Fixes #79518 Fixes #78246 cc ````@lcnr```` This was ICE'ing because we dont pass in the correct ``ParamEnv`` which meant that there was no ``Self: Foo`` predicate to make ``Self::Assoc`` well formed which caused an ICE when trying to normalize ``Self::Assoc`` in the mir interpreter r? ````@varkor````,HEART,2021-02-15T04:17:03Z,tesuji,NA https://github.com/rust-lang/rust/pull/82018,MERGED,2021-02-12T04:59:20Z,2021-03-02T08:02:21Z,Remove the dummy cache in `DocContext`; delete RenderInfo,jyn514,b51272edfee1c5b8c0eb8016042d7550c19729c8,19,Rollup merge of #82018 - jyn514:no-dummy-cache r=camelid GuillaumeGomez Remove the dummy cache in `DocContext`; delete RenderInfo The same information is available everywhere; the only reason the dummy cache was needed is because it was previously stored in three different places. This consolidates the info a bit so the cache in `DocContext` is used throughout. As a bonus it also completely removes `RenderInfo`. - Return a `Cache` from `run_global_ctxt` not `RenderInfo` - Remove the unused `render_info` from `run_renderer` - Remove RenderInfo altogether Helps with https://github.com/rust-lang/rust/pull/82014. The next step is to move the `populate()` call before the `collect_intra_doc_links` pass which currently breaks because a) lots of the cache is populated in early passes and b) intra_doc_links itself sets some info with `register_res`. I'm working on separate PR for that to avoid making too many big changes at once. r? `@GuillaumeGomez`,HEART,2021-02-22T01:33:09Z,camelid,NA https://github.com/rust-lang/rust/pull/82020,MERGED,2021-02-12T07:54:40Z,2021-02-19T19:40:00Z,Make `Clean` take &mut DocContext,jyn514,9b471a3f5fe57e5c6e08acf665f2094422415a3d,24,Auto merge of #82020 - jyn514:mut-passes r=camelid GuillaumeGomez Make `Clean` take &mut DocContext - Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics` - Take `&mut DocContext` in most of `clean` - Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad. This combined with https://github.com/rust-lang/rust/pull/82018 should hopefully help with https://github.com/rust-lang/rust/pull/82014 by allowing `cx.cache.exported_traits` to be modified in `register_res`. Previously it had to use interior mutability which required either adding a RefCell to `cache.exported_traits` on *top* of the existing `RefCell` or mixing reads and writes between `cx.exported_traits` and `cx.cache.exported_traits`. I don't currently have that working but I expect it to be reasonably easy to add after this.,HEART,2021-02-13T01:38:20Z,camelid,NA https://github.com/rust-lang/rust/pull/82033,MERGED,2021-02-12T16:26:11Z,2021-02-13T10:55:20Z,Refactor `get_word_attr` to return only `Option`,magurotuna,4c8e38aa60c4dc36b44725bc956cd19ff6e9f6ac,2,Rollup merge of #82033 - magurotuna:issue82016 r=jyn514 Refactor `get_word_attr` to return only `Option` This commit removes `bool` from the return type of `NestedAttributesExt::get_word_attr` so it will return only `Option` for less redundancy. Closes #82016 r? `@jyn514`,HEART,2021-02-12T16:28:38Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82037,MERGED,2021-02-12T18:32:42Z,2021-06-10T05:52:44Z,Make symbols stripping work on MacOS X,calavera,27e84b89dae055fef9fd9e705be65c244b54e4c7,2,Rollup merge of #82037 - calavera:strip_debuginfo_osx r=petrochenkov Make symbols stripping work on MacOS X As reported in the [stabilization issue](https://github.com/rust-lang/rust/issues/72110) MacOS' linker doesn't support the `-s` and `-S` flags to strip symbols anymore. However the os ships a separated tool to perform these operations. This change allows the compiler to use that tool after a target has been compiled to strip symbols. For rationale see: https://github.com/rust-lang/rust/issues/72110#issuecomment-641169818 For option selection see: https://www.unix.com/man-page/osx/1/strip/ Signed-off-by: David Calavera ,HEART,2021-06-08T19:42:52Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/82037,MERGED,2021-02-12T18:32:42Z,2021-06-10T05:52:44Z,Make symbols stripping work on MacOS X,calavera,27e84b89dae055fef9fd9e705be65c244b54e4c7,2,Rollup merge of #82037 - calavera:strip_debuginfo_osx r=petrochenkov Make symbols stripping work on MacOS X As reported in the [stabilization issue](https://github.com/rust-lang/rust/issues/72110) MacOS' linker doesn't support the `-s` and `-S` flags to strip symbols anymore. However the os ships a separated tool to perform these operations. This change allows the compiler to use that tool after a target has been compiled to strip symbols. For rationale see: https://github.com/rust-lang/rust/issues/72110#issuecomment-641169818 For option selection see: https://www.unix.com/man-page/osx/1/strip/ Signed-off-by: David Calavera ,THUMBS_UP,2021-07-22T20:29:34Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/82043,MERGED,2021-02-12T21:17:56Z,2021-03-02T18:49:59Z,Turn may_have_side_effect into an associated constant,tmiasko,795a934b51cb481ea3cb1cc8c3835a043a9e0102,9,Auto merge of #82043 - tmiasko:may-have-side-effect r=kennytm Turn may_have_side_effect into an associated constant The `may_have_side_effect` is an implementation detail of `TrustedRandomAccess` trait. It describes if obtaining an iterator element may have side effects. It is currently implemented as an associated function. Turn `may_have_side_effect` into an associated constant. This makes the value immediately available to the optimizer.,THUMBS_UP,2021-02-15T16:41:12Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/82043,MERGED,2021-02-12T21:17:56Z,2021-03-02T18:49:59Z,Turn may_have_side_effect into an associated constant,tmiasko,795a934b51cb481ea3cb1cc8c3835a043a9e0102,9,Auto merge of #82043 - tmiasko:may-have-side-effect r=kennytm Turn may_have_side_effect into an associated constant The `may_have_side_effect` is an implementation detail of `TrustedRandomAccess` trait. It describes if obtaining an iterator element may have side effects. It is currently implemented as an associated function. Turn `may_have_side_effect` into an associated constant. This makes the value immediately available to the optimizer.,ROCKET,2021-03-04T09:39:12Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82055,MERGED,2021-02-13T07:55:54Z,2021-02-18T10:13:39Z,Add diagnostics for specific cases for const/type mismatch err,JulianKnodt,0c25d154bd5b48819f490ac4a630f28fcfe4d321,6,Rollup merge of #82055 - JulianKnodt:ty_where_const r=estebank Add diagnostics for specific cases for const/type mismatch err For now this adds at least more information so better diagnostics can be emitted for const mismatch errors. I'm not sure what exactly we want to emit so I've left notes there temporarily also to see if this is the right approach r? ```@lcnr``` cc: ```@estebank```,HEART,2021-02-14T02:07:34Z,estebank,NA https://github.com/rust-lang/rust/pull/82057,MERGED,2021-02-13T11:21:50Z,2021-02-27T05:05:48Z,Replace const_cstr with cstr crate,upsuper,cabe97272d782294e0d642135f3d8b13579b2929,11,Rollup merge of #82057 - upsuper-forks:cstr r=davidtwco wesleywiser Replace const_cstr with cstr crate This PR replaces the `const_cstr` macro inside `rustc_data_structures` with `cstr` macro from [cstr](https://crates.io/crates/cstr) crate. The two macros basically serve the same purpose which is to generate `&'static CStr` from a string literal. `cstr` is better because it validates the literal at compile time while the existing `const_cstr` does it at runtime when `debug_assertions` is enabled. In addition the value `cstr` generates can be used in constant context (which is seemingly not needed anywhere currently though).,THUMBS_UP,2021-02-13T12:07:09Z,est31,NA https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-02-13T22:14:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,THUMBS_UP,2021-02-15T12:23:32Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,THUMBS_UP,2021-02-17T12:02:14Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-12T01:32:27Z,estebank,NA https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-20T04:31:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-20T17:54:22Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-21T06:22:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-25T14:02:24Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/82069,MERGED,2021-02-13T19:53:49Z,2021-05-13T02:56:57Z,Show macro name in 'this error originates in macro' message,Aaron1011,9daf546b77dbeab7754a80d7336cd8d00c6746e4,350,Auto merge of #82069 - Aaron1011:verbose-in-macro r=estebank Show macro name in 'this error originates in macro' message When there are multiple macros in use it can be difficult to tell which one was responsible for producing an error.,HEART,2021-05-28T20:47:24Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/82076,MERGED,2021-02-13T23:06:22Z,2021-02-23T10:02:16Z,Update the bootstrap compiler,jyn514,cd64446196a02e593c5f50b8d863161306da43f7,16,Auto merge of #82076 - jyn514:update-bootstrap r=Mark-Simulacrum Update the bootstrap compiler This updates the bootstrap compiler notably leaving out a change to enable semicolon in macro expressions lint because stdarch still depends on the old behavior.,THUMBS_UP,2021-02-18T17:29:04Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,THUMBS_UP,2021-02-13T23:33:29Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,THUMBS_UP,2021-02-19T09:50:24Z,iago-lito,NA https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,THUMBS_UP,2021-02-20T15:00:05Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,HOORAY,2021-03-04T16:33:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,THUMBS_UP,2021-03-04T16:33:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,THUMBS_UP,2021-03-05T01:54:18Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/82078,MERGED,2021-02-13T23:24:54Z,2021-02-25T18:14:54Z,Make char and u8 methods const,lopopolo,f891af9de529f7df8d094e130dd6f35fe07b4d78,2,Rollup merge of #82078 - lopopolo:char-u8-const-fn r=m-ou-se Make char and u8 methods const char methods `len_utf8` `len_utf16` `to_ascii_lowercase` `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase` `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of https://github.com/rust-lang/rust/pull/79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from #79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``,HOORAY,2021-03-05T01:54:21Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/82094,MERGED,2021-02-14T11:47:37Z,2021-02-17T22:37:48Z,To digit simplification,gilescope,253631d73fdb310a437edff1134caee904e28b94,1,Rollup merge of #82094 - gilescope:to_digit_speedup2 r=m-ou-se To digit simplification I found out the other day that all the ascii digits have the first four bits as one would hope them to. (Eg. char `2` ends `0b0010`). There are two bits to indicate it's in the digit range ( `0b0011_0000`). If it is a true digit then all the higher bits aside from these two will be 0 (as ascii is the lowest part of the unicode u32 spectrum). So XORing with `0b11_0000` should mean we either get the number 0-9 or alternativly we get a larger number in the u32 space. If we get something that's not 0-9 then it will be discarded as it will be greater than the radix. The code seems so fast though that there's quite a lot of noise in the benchmarks so it's not that easy to prove conclusively that it's faster as well as less instructions. The non-fast path I was toying with as well wondering if we could do this as then we'd only have one return and less instructions still: ``` match self { 'a'..='z' => self as u32 - 'a' as u32 + 10 'A'..='Z' => self as u32 - 'A' as u32 + 10 _ => { radix = 10; self as u32 ^ ASCII_DIGIT_MASK} } ``` Here's the [godbolt](https://godbolt.org/z/883c9n). ( H/T to ``@byteshadow`` for pointing out xor was what I needed),THUMBS_UP,2021-02-14T13:06:25Z,the8472,NA https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,THUMBS_UP,2021-02-14T15:11:35Z,the8472,NA https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,THUMBS_UP,2021-02-14T16:29:52Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,HOORAY,2021-02-14T19:46:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,THUMBS_UP,2021-02-15T21:17:54Z,bstrie,NA https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,THUMBS_UP,2021-08-14T00:16:04Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/82098,MERGED,2021-02-14T13:57:39Z,2021-02-22T12:14:35Z,Add internal `collect_into_array[_unchecked]` to remove duplicate code,LukasKalbertodt,3cf201fb81458ab6d9181849fd2823fd6d2a4e37,1,Rollup merge of #82098 - LukasKalbertodt:add-collect-into-array r=dtolnay Add internal `collect_into_array[_unchecked]` to remove duplicate code Unlike the similar PRs #69985 #75644 and #79659 this PR only adds private functions and does not propose any new public API. The change is just for the purpose of avoiding duplicate code. Many array methods already contained the same kind of code and there are still many array related methods to come (e.g. `Iterator::{chunks map_windows next_n ...}` `[T; N]::{cloned copied ...}` ...) which all basically need this functionality. Writing custom `unsafe` code for each of those doesn't seem like a good idea. I added two functions in this PR (and not just the `unsafe` version) because I already know that I need the `Option`-returning version for `Iterator::map_windows`. This is closely related to https://github.com/rust-lang/rust/issues/81615. I think that all options listed in that issue can be implemented using the function added in this PR. The only instance where `collect_array_into` might not be general enough is when the caller want to handle incomplete arrays manually. Currently if `iter` yields fewer than `N` items `None` is returned and the already yielded items are dropped. But as this is just a private function it can be made more general in future PRs. And while this was not the goal this seems to lead to better assembly for `array::map`: https://rust.godbolt.org/z/75qKTa (CC ``@JulianKnodt)`` Let me know what you think :) CC ``@matklad`` ``@bstrie``,THUMBS_UP,2021-11-01T09:48:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82113,MERGED,2021-02-14T18:53:19Z,2021-02-23T20:10:05Z,Improve non_fmt_panic lint.,m-ou-se,547b3adfe4afb7cfe3d3603e16faa458913ef56f,5,"Rollup merge of #82113 - m-ou-se:panic-format-lint r=estebank Improve non_fmt_panic lint. This change: - fixes the span used by this lint in the case the panic argument is a single macro expansion (e.g. `panic!(a!())`); - adds a suggestion for `panic!(format!(..))` to remove `format!()` instead of adding `""{}"" ` or using `panic_any` like it does now; and - fixes the incorrect suggestion to replace `panic![123]` by `panic_any(123]`. Fixes #82109. Fixes #82110. Fixes #82111. Example output: ``` warning: panic message is not a string literal --> src/main.rs:8:12 | 8 | panic!(format!(""error: {}"" ""oh no"")); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(non_fmt_panic)]` on by default = note: this is no longer accepted in Rust 2021 = note: the panic!() macro supports formatting so there's no need for the format!() macro here help: remove the `format!(..)` macro call | 8 | panic!(""error: {}"" ""oh no""); | -- -- ``` r? `@estebank`",EYES,2021-02-14T19:30:33Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/82113,MERGED,2021-02-14T18:53:19Z,2021-02-23T20:10:05Z,Improve non_fmt_panic lint.,m-ou-se,547b3adfe4afb7cfe3d3603e16faa458913ef56f,5,"Rollup merge of #82113 - m-ou-se:panic-format-lint r=estebank Improve non_fmt_panic lint. This change: - fixes the span used by this lint in the case the panic argument is a single macro expansion (e.g. `panic!(a!())`); - adds a suggestion for `panic!(format!(..))` to remove `format!()` instead of adding `""{}"" ` or using `panic_any` like it does now; and - fixes the incorrect suggestion to replace `panic![123]` by `panic_any(123]`. Fixes #82109. Fixes #82110. Fixes #82111. Example output: ``` warning: panic message is not a string literal --> src/main.rs:8:12 | 8 | panic!(format!(""error: {}"" ""oh no"")); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(non_fmt_panic)]` on by default = note: this is no longer accepted in Rust 2021 = note: the panic!() macro supports formatting so there's no need for the format!() macro here help: remove the `format!(..)` macro call | 8 | panic!(""error: {}"" ""oh no""); | -- -- ``` r? `@estebank`",HEART,2021-02-14T21:44:56Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/82121,MERGED,2021-02-14T23:12:46Z,2021-03-14T06:35:25Z,Implement Extend and FromIterator for OsString,lopopolo,67bc866e5934e19c37fd7a115cdc8142fcb8c51d,1,"Rollup merge of #82121 - lopopolo:pathbuf-osstring-extend r=joshtriplett Implement Extend and FromIterator for OsString Add the following trait impls: - `impl Extend for OsString` - `impl<'a> Extend<&'a OsStr> for OsString` - `impl FromIterator for OsString` - `impl<'a> FromIterator<&'a OsStr> for OsString` Because `OsString` is a platform string with no particular semantics concatenating them together seems acceptable. I came across a use case for these trait impls in https://github.com/artichoke/artichoke/pull/1089: Artichoke is a Ruby interpreter. Its CLI accepts multiple `-e` switches for executing inline Ruby code like: ```console $ cargo -q run --bin artichoke -- -e '2.times {' -e 'puts ""foo: #{__LINE__}""' -e '}' foo: 2 foo: 2 ``` I use `clap` for command line argument parsing which collects these `-e` commands into a `Vec`. To pass these commands to the interpreter for `Eval` I need to join them together. Combining these impls with `Iterator::intersperse` https://github.com/rust-lang/rust/issues/79524 would enable me to build a single bit of Ruby code. Currently I'm doing something like: ```rust let mut commands = commands.into_iter(); let mut buf = if let Some(command) = commands.next() { command } else { return Ok(Ok(())); }; for command in commands { buf.push(""\n""); buf.push(command); } ``` If there's interest I'd also like to add impls for `Cow<'a OsStr>` which would avoid allocating the `""\n""` `OsString` in the concatenate + intersperse use case.",HEART,2021-03-04T16:35:44Z,tux3,NA https://github.com/rust-lang/rust/pull/82121,MERGED,2021-02-14T23:12:46Z,2021-03-14T06:35:25Z,Implement Extend and FromIterator for OsString,lopopolo,67bc866e5934e19c37fd7a115cdc8142fcb8c51d,1,"Rollup merge of #82121 - lopopolo:pathbuf-osstring-extend r=joshtriplett Implement Extend and FromIterator for OsString Add the following trait impls: - `impl Extend for OsString` - `impl<'a> Extend<&'a OsStr> for OsString` - `impl FromIterator for OsString` - `impl<'a> FromIterator<&'a OsStr> for OsString` Because `OsString` is a platform string with no particular semantics concatenating them together seems acceptable. I came across a use case for these trait impls in https://github.com/artichoke/artichoke/pull/1089: Artichoke is a Ruby interpreter. Its CLI accepts multiple `-e` switches for executing inline Ruby code like: ```console $ cargo -q run --bin artichoke -- -e '2.times {' -e 'puts ""foo: #{__LINE__}""' -e '}' foo: 2 foo: 2 ``` I use `clap` for command line argument parsing which collects these `-e` commands into a `Vec`. To pass these commands to the interpreter for `Eval` I need to join them together. Combining these impls with `Iterator::intersperse` https://github.com/rust-lang/rust/issues/79524 would enable me to build a single bit of Ruby code. Currently I'm doing something like: ```rust let mut commands = commands.into_iter(); let mut buf = if let Some(command) = commands.next() { command } else { return Ok(Ok(())); }; for command in commands { buf.push(""\n""); buf.push(command); } ``` If there's interest I'd also like to add impls for `Cow<'a OsStr>` which would avoid allocating the `""\n""` `OsString` in the concatenate + intersperse use case.",HEART,2021-03-07T14:42:11Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/82127,MERGED,2021-02-15T02:20:18Z,2021-02-23T17:24:37Z,rustc_codegen_ssa: tune codegen according to available concurrency,tgnottingham,019610754363d1d92a8d0f364d2c0909d6f53dfd,3,Auto merge of #82127 - tgnottingham:tune-ahead-of-time-codegen r=varkor rustc_codegen_ssa: tune codegen according to available concurrency This change tunes ahead-of-time codegening according to the amount of concurrency available rather than according to the number of CPUs on the system. This can lower memory usage by reducing the number of compiled LLVM modules in memory at once particularly across several rustc instances. Previously each rustc instance would assume that it should codegen ahead of time to meet the demand of number-of-CPUs workers. But often a rustc instance doesn't have nearly that much concurrency available to it because the concurrency availability is split via the jobserver across all active rustc instances spawned by the driving cargo process and is further limited by the `-j` flag argument. Therefore each rustc might have had several times the number of LLVM modules in memory than it really needed to meet demand. If the modules were large the effect on memory usage would be noticeable. With this change the required amount of ahead-of-time codegen scales up with the actual number of workers running within a rustc instance. Note that the number of workers running can be less than the actual concurrency available to a rustc instance. However if more concurrency is actually available workers are spun up quickly as job tokens are acquired and the ahead-of-time codegen scales up quickly as well.,HEART,2021-02-22T22:24:03Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82130,MERGED,2021-02-15T03:00:24Z,2021-03-07T05:50:07Z,Make some Option Result methods unstably const,jhpratt,0adc1965218bb24290c74f680d94c20799ff8f70,2,Rollup merge of #82130 - jhpratt:const-option-result r=RalfJung Make some Option Result methods unstably const The following methods are now unstably const: - Option::transpose - Option::flatten - Result::flatten While some methods for could likely be made `const` in the future nearly all of them require something to be dropped at compile-time which isn't currently supported. The functions listed above should have a trivial path to stabilization.,ROCKET,2021-02-15T03:49:10Z,lopopolo,NA https://github.com/rust-lang/rust/pull/82159,MERGED,2021-02-15T17:52:35Z,2021-02-25T00:36:08Z,Use correct param_env in conservative_is_privately_uninhabited,BoxyUwU,1fdadbf13aecd190b277ea2aa1b125d2ed986d55,9,Auto merge of #82159 - BoxyUwU:uwu r=varkor Use correct param_env in conservative_is_privately_uninhabited cc `@lcnr` r? `@varkor` since this is your FIXME that was removed ^^,HEART,2021-02-23T21:04:10Z,varkor,NA https://github.com/rust-lang/rust/pull/82159,MERGED,2021-02-15T17:52:35Z,2021-02-25T00:36:08Z,Use correct param_env in conservative_is_privately_uninhabited,BoxyUwU,1fdadbf13aecd190b277ea2aa1b125d2ed986d55,9,Auto merge of #82159 - BoxyUwU:uwu r=varkor Use correct param_env in conservative_is_privately_uninhabited cc `@lcnr` r? `@varkor` since this is your FIXME that was removed ^^,HEART,2021-02-25T02:50:17Z,tesuji,NA https://github.com/rust-lang/rust/pull/82162,MERGED,2021-02-15T20:08:17Z,2021-02-25T03:36:22Z,Expand FlattenCompat folds,cuviper,63bacf14cd06f67171546670f22d8af509c29027,1,Auto merge of #82162 - cuviper:flat-fold r=Mark-Simulacrum Expand FlattenCompat folds The former `chain`+`chain`+`fold` implementation looked nice from a functional-programming perspective but it introduced unnecessary layers of abstraction on every `flat_map`/`flatten` fold. It's straightforward to just fold each part in turn and this makes it look like a simplified version of the existing `try_fold` implementation. For the `iter::bench_flat_map*` benchmarks I get a large improvement in `bench_flat_map_chain_sum` from 1 598 473 ns/iter to 499 889 ns/iter and the rest are unchanged.,HEART,2021-02-16T17:12:25Z,bluss,NA https://github.com/rust-lang/rust/pull/82162,MERGED,2021-02-15T20:08:17Z,2021-02-25T03:36:22Z,Expand FlattenCompat folds,cuviper,63bacf14cd06f67171546670f22d8af509c29027,1,Auto merge of #82162 - cuviper:flat-fold r=Mark-Simulacrum Expand FlattenCompat folds The former `chain`+`chain`+`fold` implementation looked nice from a functional-programming perspective but it introduced unnecessary layers of abstraction on every `flat_map`/`flatten` fold. It's straightforward to just fold each part in turn and this makes it look like a simplified version of the existing `try_fold` implementation. For the `iter::bench_flat_map*` benchmarks I get a large improvement in `bench_flat_map_chain_sum` from 1 598 473 ns/iter to 499 889 ns/iter and the rest are unchanged.,HEART,2021-02-24T10:13:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/82162,MERGED,2021-02-15T20:08:17Z,2021-02-25T03:36:22Z,Expand FlattenCompat folds,cuviper,63bacf14cd06f67171546670f22d8af509c29027,1,Auto merge of #82162 - cuviper:flat-fold r=Mark-Simulacrum Expand FlattenCompat folds The former `chain`+`chain`+`fold` implementation looked nice from a functional-programming perspective but it introduced unnecessary layers of abstraction on every `flat_map`/`flatten` fold. It's straightforward to just fold each part in turn and this makes it look like a simplified version of the existing `try_fold` implementation. For the `iter::bench_flat_map*` benchmarks I get a large improvement in `bench_flat_map_chain_sum` from 1 598 473 ns/iter to 499 889 ns/iter and the rest are unchanged.,HEART,2021-02-25T05:20:35Z,camelid,NA https://github.com/rust-lang/rust/pull/82165,MERGED,2021-02-16T00:16:23Z,2021-02-26T21:59:01Z,Reword labels on E0308 involving async fn return type,nellshamrell,a56bbb134fe98931de92b587c3b98920f6923bc9,12,Rollup merge of #82165 - nellshamrell:nell/fix-80658-B r=estebank Reword labels on E0308 involving async fn return type Fix for #80658. When someone writes code like this: ```rust fn foo() -> u8 { async fn async_fn() -> () {} async_fn() } ``` And they try to compile it they will see an error that looks like this: ```bash error[E0308]: mismatched types --> test.rs:4:5 | 1 | fn foo() -> u8 { | -- expected `u8` because of return type 2 | async fn async_fn() -> () {} | -- checked the `Output` of this `async fn` found opaque type 3 | 4 | async_fn() | ^^^^^^^^^^ expected `u8` found opaque type | = note: while checking the return type of this `async fn` = note: expected type `u8` found opaque type `impl Future` ```,HEART,2021-02-16T02:11:01Z,estebank,NA https://github.com/rust-lang/rust/pull/82179,MERGED,2021-02-16T11:32:23Z,2021-06-15T22:56:32Z,Add functions `Duration::try_from_secs_{f32 f64}`,mbartlett21,1e14d397db323b037a22e6440f85293d938ce6a7,3,Rollup merge of #82179 - mbartlett21:patch-5 r=joshtriplett Add functions `Duration::try_from_secs_{f32 f64}` These functions allow constructing a Duration from a floating point value that could be out of range without panicking. Tracking issue: #83400,THUMBS_UP,2021-02-16T12:18:26Z,marmeladema,NA https://github.com/rust-lang/rust/pull/82179,MERGED,2021-02-16T11:32:23Z,2021-06-15T22:56:32Z,Add functions `Duration::try_from_secs_{f32 f64}`,mbartlett21,1e14d397db323b037a22e6440f85293d938ce6a7,3,Rollup merge of #82179 - mbartlett21:patch-5 r=joshtriplett Add functions `Duration::try_from_secs_{f32 f64}` These functions allow constructing a Duration from a floating point value that could be out of range without panicking. Tracking issue: #83400,THUMBS_UP,2021-05-20T06:24:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-02-16T14:55:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-02-19T18:51:39Z,mati865,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-02-21T03:09:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-03-11T23:29:54Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-03-19T13:53:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-07-20T18:53:41Z,r00ster91,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-08-18T17:52:59Z,cjgillot,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-09-15T21:09:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-09-18T22:04:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82183,MERGED,2021-02-16T13:14:23Z,2021-09-18T17:18:36Z,Simplify lazy DefPathHash decoding by using an on-disk hash table.,michaelwoerister,d6cd2c6c877110748296760aefddc21a0ea1d316,22,Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2 r=wesleywiser Simplify lazy DefPathHash decoding by using an on-disk hash table. This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly i.e. without deserializing the entire table. The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.,HOORAY,2021-09-19T08:59:39Z,Milo123459,NA https://github.com/rust-lang/rust/pull/82191,MERGED,2021-02-16T18:03:20Z,2021-03-18T02:32:34Z,Vec::dedup_by optimization,Soveu,90797ef008a2004e70ff0106c756f24ea63ab236,5,Rollup merge of #82191 - Soveu:dedup r=nagisa Vec::dedup_by optimization Now `Vec::dedup_by` drops items in-place as it goes through them. From my benchmarks it is around 10% faster when T is small with no major regression when otherwise. I used `ptr::copy` instead of conditional `ptr::copy_nonoverlapping` because the latter had some weird performance issues on my ryzen laptop (it was 50% slower on it than on intel/sandybridge laptop) It would be good if someone was able to reproduce these results.,THUMBS_UP,2021-03-26T16:14:30Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/82191,MERGED,2021-02-16T18:03:20Z,2021-03-18T02:32:34Z,Vec::dedup_by optimization,Soveu,90797ef008a2004e70ff0106c756f24ea63ab236,5,Rollup merge of #82191 - Soveu:dedup r=nagisa Vec::dedup_by optimization Now `Vec::dedup_by` drops items in-place as it goes through them. From my benchmarks it is around 10% faster when T is small with no major regression when otherwise. I used `ptr::copy` instead of conditional `ptr::copy_nonoverlapping` because the latter had some weird performance issues on my ryzen laptop (it was 50% slower on it than on intel/sandybridge laptop) It would be good if someone was able to reproduce these results.,THUMBS_UP,2021-03-30T02:15:31Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82196,MERGED,2021-02-16T19:47:47Z,2021-02-17T22:37:48Z,Add caveat to Path::display() about lossiness,Manishearth,8e6bc14f526b4edd2360393f72c8b9467ac62bc6,1,Rollup merge of #82196 - Manishearth:display-caveat r=m-ou-se Add caveat to Path::display() about lossiness It's worth calling out that this API may do a lossy display. r? ```@m-ou-se```,THUMBS_UP,2021-02-16T19:48:02Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82196,MERGED,2021-02-16T19:47:47Z,2021-02-17T22:37:48Z,Add caveat to Path::display() about lossiness,Manishearth,8e6bc14f526b4edd2360393f72c8b9467ac62bc6,1,Rollup merge of #82196 - Manishearth:display-caveat r=m-ou-se Add caveat to Path::display() about lossiness It's worth calling out that this API may do a lossy display. r? ```@m-ou-se```,THUMBS_UP,2021-02-16T19:48:18Z,sunshowers,rain@sunshowers.io https://github.com/rust-lang/rust/pull/82207,MERGED,2021-02-17T03:18:21Z,2021-02-17T22:37:48Z,rustdoc: treat edition 2021 as unstable,ehuss,f97e1121a7b7716ab020f93963d162fb9d703e36,2,Rollup merge of #82207 - ehuss:rustdoc-2021 r=jyn514 rustdoc: treat edition 2021 as unstable This ensures that `--edition=2021` requires `-Z unstable-options` in rustdoc.,HEART,2021-02-17T04:21:39Z,scottmcm,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-02-17T08:51:33Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-02-17T16:19:50Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-02-19T15:54:57Z,r00ster91,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-02-19T22:02:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-03-09T02:23:32Z,camelid,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-04-12T19:07:18Z,cynecx,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-04-27T19:54:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-04-29T10:05:27Z,light4,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-05-03T15:12:01Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-05-05T09:55:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-05-13T17:36:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-05-15T18:12:13Z,SkiFire13,NA https://github.com/rust-lang/rust/pull/82208,MERGED,2021-02-17T03:39:49Z,2021-05-15T17:37:18Z,Convert rustfmt from a submodule to a subtree,jyn514,eac3c7c5bd38ec38062ebde475bd2ea6317d0c09,1276,"Auto merge of #82208 - jyn514:rustfmt-subtree r=Mark-Simulacrum Convert rustfmt from a submodule to a subtree r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum` The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling since now people making breaking changes will be responsible for fixing them. I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history which is not terribly much compared to the 702 MB that already exist. - Add `src/tools/rustfmt` to `x.py check` - Fix CRLF issues with rustfmt tests (see commit for details) - Use `rustc_private` instead of crates.io dependencies This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust. - Add `yansi-term` to the list of allowed dependencies. This is a false positive - rustc doesn't actually use it only rustfmt but because it's activated by the cargo feature of a dependency tidy gets confused. It's fairly innocuous in any case it's used for color printing. This would have happened in the next submodule bump. - Remove rustfmt from the list of toolstate tools. - Give a hard error if testing or building rustfmt fails. - Update log to 0.4.14 This avoids a warning about semicolons in macros; see the commit for details. - Don't add tools to the sysroot when they finish building. This is the only change that could be considered a regression - this avoids a ""colliding StableCrateId"" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details. Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.",HOORAY,2021-05-21T21:59:50Z,RinatValiullov,NA https://github.com/rust-lang/rust/pull/82214,MERGED,2021-02-17T10:19:07Z,2021-02-25T18:14:54Z,Remove redundant to_string calls,est31,00aa3e68806e50431d51fc7f6ce66f2a4548f4cd,2,Rollup merge of #82214 - est31:no_to_string r=oli-obk Remove redundant to_string calls,THUMBS_UP,2021-02-19T12:51:12Z,bugadani,NA https://github.com/rust-lang/rust/pull/82215,MERGED,2021-02-17T10:29:43Z,2021-02-18T22:38:37Z,Replace if-let and while-let with `if let` and `while let`,TaKO8Ki,b3d325127143296de07269da7940a411526df022,18,Rollup merge of #82215 - TaKO8Ki:replace-if-let-while-let r=varkor Replace if-let and while-let with `if let` and `while let` This pull request replaces if-let and while-let with `if let` and `while let`. closes https://github.com/rust-lang/rust/issues/82205,HEART,2021-02-17T12:48:22Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/82215,MERGED,2021-02-17T10:29:43Z,2021-02-18T22:38:37Z,Replace if-let and while-let with `if let` and `while let`,TaKO8Ki,b3d325127143296de07269da7940a411526df022,18,Rollup merge of #82215 - TaKO8Ki:replace-if-let-while-let r=varkor Replace if-let and while-let with `if let` and `while let` This pull request replaces if-let and while-let with `if let` and `while let`. closes https://github.com/rust-lang/rust/issues/82205,HEART,2021-02-18T11:53:54Z,luccafort,NA https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-17T17:19:36Z,jplatte,NA https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-17T17:31:15Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-17T20:01:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-19T16:22:54Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-19T21:36:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-21T07:46:38Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/82217,MERGED,2021-02-17T13:29:49Z,2021-03-10T21:53:58Z,Edition-specific preludes,m-ou-se,759204ffc417f5d1e6b56ca38d28e7c9881ce09a,20,Rollup merge of #82217 - m-ou-se:edition-prelude r=nikomatsakis Edition-specific preludes This changes `{std core}::prelude` to export edition-specific preludes under `rust_2015` `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*` but this allows us to add things to the 2021edition prelude soon. This also changes the compiler to make the automatically injected prelude import dependent on the selected edition. cc `@rust-lang/libs` `@djc`,HOORAY,2021-02-24T10:11:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/82218,MERGED,2021-02-17T14:08:44Z,2021-02-18T22:38:37Z,Make sure pdbs are copied along with exe and dlls when bootstrapping,rylev,01104b5c29fde36b7b55c8ba83c08c4dd97c4484,2,Rollup merge of #82218 - rylev:copy-pdbs r=Mark-Simulacrum Make sure pdbs are copied along with exe and dlls when bootstrapping This makes it easier to find the pdbs when wanting to debug the compiler on Windows.,HEART,2021-02-17T14:14:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/82218,MERGED,2021-02-17T14:08:44Z,2021-02-18T22:38:37Z,Make sure pdbs are copied along with exe and dlls when bootstrapping,rylev,01104b5c29fde36b7b55c8ba83c08c4dd97c4484,2,Rollup merge of #82218 - rylev:copy-pdbs r=Mark-Simulacrum Make sure pdbs are copied along with exe and dlls when bootstrapping This makes it easier to find the pdbs when wanting to debug the compiler on Windows.,HEART,2021-04-19T05:14:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82234,MERGED,2021-02-17T19:30:12Z,2021-02-23T07:19:43Z,Remove query parameters when skipping search results,GuillaumeGomez,8541435e8d238c93cd9c72dae406f4135c162d25,1,"Rollup merge of #82234 - GuillaumeGomez:remove-query-param-on-esc r=Nemo157 Remove query parameters when skipping search results Fixes #81330. This PR changes the following: when pressing ESC and that no other ""action"" was performed (understand: no closing the search result or hiding a menu or something along the line) then we discard the URL query parameters (the `?whatever=dsjfs`). What do you think about this change ```@rust-lang/rustdoc``` ? EDIT: finally we're simply removing the query parameter when we're skipping the search results. r? ```@Nemo157```",THUMBS_UP,2021-02-17T19:56:17Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/82234,MERGED,2021-02-17T19:30:12Z,2021-02-23T07:19:43Z,Remove query parameters when skipping search results,GuillaumeGomez,8541435e8d238c93cd9c72dae406f4135c162d25,1,"Rollup merge of #82234 - GuillaumeGomez:remove-query-param-on-esc r=Nemo157 Remove query parameters when skipping search results Fixes #81330. This PR changes the following: when pressing ESC and that no other ""action"" was performed (understand: no closing the search result or hiding a menu or something along the line) then we discard the URL query parameters (the `?whatever=dsjfs`). What do you think about this change ```@rust-lang/rustdoc``` ? EDIT: finally we're simply removing the query parameter when we're skipping the search results. r? ```@Nemo157```",THUMBS_UP,2021-02-24T12:49:50Z,tesuji,NA https://github.com/rust-lang/rust/pull/82240,MERGED,2021-02-17T22:26:58Z,2021-02-18T10:13:39Z,remove useless ?s (clippy::needless_question_marks),matthiaskrgr,ce6367f47988e6948db830b599d5c365dfa5f973,7,"Rollup merge of #82240 - matthiaskrgr:qmark r=Dylan-DPC remove useless ?s (clippy::needless_question_marks) Example code: ```rust fn opts() -> Option { let s: Option = Some(String::new()); Some(s?) // this can just be ""s"" } ```",THUMBS_UP,2021-02-18T08:59:40Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/82259,MERGED,2021-02-18T14:56:32Z,2021-02-19T11:24:01Z,Fix popping singleton paths in when generating E0433,osa1,cc01bbe8f0cf7b19053c5f0578992cb7d2f4bba8,3,Rollup merge of #82259 - osa1:issue82156 r=petrochenkov Fix popping singleton paths in when generating E0433 Fixes #82156 --- This was introduced with #72923 so pinging `@Patryk27` for reviews.,HOORAY,2021-02-18T15:14:12Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-02-18T20:13:07Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-02-20T01:27:26Z,estebank,NA https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-03-22T23:44:14Z,camelid,NA https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-03-29T06:50:41Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-07-11T02:01:52Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/82271,MERGED,2021-02-18T20:05:48Z,2021-03-23T07:35:33Z,Add `debug-refcell` feature to libcore,Aaron1011,9b6339e4b9747d473270baa42e77e1d2fff39bf4,2,Auto merge of #82271 - Aaron1011:debug-refcell r=m-ou-se Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics to make it easier to track down the source of the issue. Currently we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory so it can easily be implemented in core * Since we are storing the *earliest* active borrow we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location not a full `Backtrace`. Until we get support for `Backtrace` in libcore this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()` this extra information will be lost. To make testing easier I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework and create a separate sysroot. Since this feature will be off-by-default users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26' refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27' refcell_test.rs:18:25 ```,HEART,2021-08-16T12:30:28Z,Maan2003,NA https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-02-18T21:19:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-02-19T20:08:45Z,jackh726,NA https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-02-20T07:13:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-03-05T23:45:14Z,estebank,NA https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-03-09T09:15:58Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-04-28T11:37:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-04-30T06:03:09Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-05-02T08:12:41Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/82272,MERGED,2021-02-18T20:07:50Z,2021-05-11T19:30:03Z,Improve diagnostics for GATs,b-naber,ba8d7e2cb7cfc87070585c17cd0aa4ae7f091a08,113,Auto merge of #82272 - b-naber:gat_diag r=estebank jackh726 Improve diagnostics for GATs Fixes https://github.com/rust-lang/rust/issues/81801 Fixes https://github.com/rust-lang/rust/issues/81961 Fixes https://github.com/rust-lang/rust/issues/81862 r? `@estebank`,HEART,2021-05-20T06:14:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82273,CLOSED,2021-02-18T20:43:19Z,2021-04-09T15:34:35Z,Add round_to_even to floating point types,dsprenkels,NA,NA,NA,THUMBS_UP,2021-02-18T22:05:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82280,CLOSED,2021-02-19T01:41:27Z,2021-12-27T21:10:12Z,[WIP] Test performance of running MIR inliner on inline(always) function calls,wesleywiser,NA,NA,NA,EYES,2021-02-19T01:48:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-19T16:11:50Z,est31,NA https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-19T16:16:42Z,tesuji,NA https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-19T22:02:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-20T01:27:23Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-20T06:29:07Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2021-02-20T16:55:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82296,MERGED,2021-02-19T15:50:02Z,2021-02-23T20:10:05Z,Support `pub` on `macro_rules`,spastorino,e2561c58a41023a14e0e583113dcf55e1ecb236a,14,Rollup merge of #82296 - spastorino:pubrules r=nikomatsakis Support `pub` on `macro_rules` This rebases and updates `since` version of #78166 from ``@petrochenkov`` r? ``@nikomatsakis``,HOORAY,2022-05-05T10:08:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82305,MERGED,2021-02-19T22:33:18Z,2021-02-23T20:10:05Z,Remove many RefCells from DocContext,camelid,8e67fe501118ec161181a4efa1a6b002bb0f5605,12,Rollup merge of #82305 - camelid:no-more-refcell r=jyn514 Remove many RefCells from DocContext I left some of them so this change doesn't balloon in size and because removing the RefCell in `DocContext.resolver` would require compiler changes. Thanks to `@jyn514` for making this a lot easier with #82020! r? `@jyn514`,HEART,2021-02-19T22:38:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82308,MERGED,2021-02-20T01:01:19Z,2021-02-23T20:10:05Z,"Lower condition of `if` expression before it's ""then"" block",estebank,269f39922bd8ac6abd8dee9ca8211fbb354b554b,3,"Rollup merge of #82308 - estebank:issue-82290 r=lcnr Lower condition of `if` expression before it's ""then"" block Fix #82290 fix #82250.",THUMBS_UP,2021-02-20T09:30:28Z,osa1,omeragacan@gmail.com https://github.com/rust-lang/rust/pull/82308,MERGED,2021-02-20T01:01:19Z,2021-02-23T20:10:05Z,"Lower condition of `if` expression before it's ""then"" block",estebank,269f39922bd8ac6abd8dee9ca8211fbb354b554b,3,"Rollup merge of #82308 - estebank:issue-82290 r=lcnr Lower condition of `if` expression before it's ""then"" block Fix #82290 fix #82250.",HOORAY,2021-02-20T09:30:30Z,osa1,omeragacan@gmail.com https://github.com/rust-lang/rust/pull/82308,MERGED,2021-02-20T01:01:19Z,2021-02-23T20:10:05Z,"Lower condition of `if` expression before it's ""then"" block",estebank,269f39922bd8ac6abd8dee9ca8211fbb354b554b,3,"Rollup merge of #82308 - estebank:issue-82290 r=lcnr Lower condition of `if` expression before it's ""then"" block Fix #82290 fix #82250.",THUMBS_UP,2021-02-21T03:56:10Z,qiujiangkun,qiujiangkun@foxmail.com https://github.com/rust-lang/rust/pull/82308,MERGED,2021-02-20T01:01:19Z,2021-02-23T20:10:05Z,"Lower condition of `if` expression before it's ""then"" block",estebank,269f39922bd8ac6abd8dee9ca8211fbb354b554b,3,"Rollup merge of #82308 - estebank:issue-82290 r=lcnr Lower condition of `if` expression before it's ""then"" block Fix #82290 fix #82250.",HOORAY,2021-02-21T03:56:12Z,qiujiangkun,qiujiangkun@foxmail.com https://github.com/rust-lang/rust/pull/82310,MERGED,2021-02-20T01:48:36Z,2021-03-04T14:00:48Z,Load rustdoc's JS search index on-demand.,jsha,36b7bef1cb0fb9d989f6c6e5ae9f001dea1b6a14,3,Rollup merge of #82310 - jsha:rustdoc-search-onfocus r=GuillaumeGomez Load rustdoc's JS search index on-demand. Instead of being loaded on every page the JS search index is now loaded when either (a) there is a `?search=` param or (b) the search input is focused. This saves both CPU and bandwidth. As of Feb 2021 https://doc.rust-lang.org/search-index1.50.0.js is 273 838 bytes gzipped or 2 544 939 bytes uncompressed. Evaluating it takes 445 ms of CPU time in Chrome 88 on a i7-10710U CPU (out of a total ~2 100 ms page reload). Tested on Firefox and Chrome. New: https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html?search=fn Old: https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html?search=fn,HEART,2021-02-21T05:39:11Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/82310,MERGED,2021-02-20T01:48:36Z,2021-03-04T14:00:48Z,Load rustdoc's JS search index on-demand.,jsha,36b7bef1cb0fb9d989f6c6e5ae9f001dea1b6a14,3,Rollup merge of #82310 - jsha:rustdoc-search-onfocus r=GuillaumeGomez Load rustdoc's JS search index on-demand. Instead of being loaded on every page the JS search index is now loaded when either (a) there is a `?search=` param or (b) the search input is focused. This saves both CPU and bandwidth. As of Feb 2021 https://doc.rust-lang.org/search-index1.50.0.js is 273 838 bytes gzipped or 2 544 939 bytes uncompressed. Evaluating it takes 445 ms of CPU time in Chrome 88 on a i7-10710U CPU (out of a total ~2 100 ms page reload). Tested on Firefox and Chrome. New: https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html?search=fn Old: https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html?search=fn,HEART,2021-03-06T01:28:31Z,camelid,NA https://github.com/rust-lang/rust/pull/82310,MERGED,2021-02-20T01:48:36Z,2021-03-04T14:00:48Z,Load rustdoc's JS search index on-demand.,jsha,36b7bef1cb0fb9d989f6c6e5ae9f001dea1b6a14,3,Rollup merge of #82310 - jsha:rustdoc-search-onfocus r=GuillaumeGomez Load rustdoc's JS search index on-demand. Instead of being loaded on every page the JS search index is now loaded when either (a) there is a `?search=` param or (b) the search input is focused. This saves both CPU and bandwidth. As of Feb 2021 https://doc.rust-lang.org/search-index1.50.0.js is 273 838 bytes gzipped or 2 544 939 bytes uncompressed. Evaluating it takes 445 ms of CPU time in Chrome 88 on a i7-10710U CPU (out of a total ~2 100 ms page reload). Tested on Firefox and Chrome. New: https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-demand/std/primitive.slice.html?search=fn Old: https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html https://jacob.hoffman-andrews.com/rust/search-on-load/std/primitive.slice.html?search=fn,HEART,2021-04-23T12:53:18Z,stefnotch,NA https://github.com/rust-lang/rust/pull/82340,MERGED,2021-02-20T19:31:00Z,2021-02-21T12:23:49Z,Fix some Python2→3 error in publish_toolstate.py,kennytm,ef1468822146032d53bc3970ef8382b72923e51f,1,Auto merge of #82340 - kennytm:fix-82254 r=Mark-Simulacrum Fix some Python2→3 error in publish_toolstate.py Fix #82254. The error is primarily due to `data = json.dumps(…)` producing a `str` instead of a `bytes` which are different types on Python 3. But then `urllib.request.urlopen(… data)` cannot accept `data` as a `str` thus the error. This PR added `.encode()` call after `json.dumps()` to ensure we are sending `bytes`. Additionally we added type annotation to ensure things can statically type-check with `mypy` on both Python 2 and 3.,HEART,2021-02-21T12:23:43Z,RalfJung,NA https://github.com/rust-lang/rust/pull/82345,CLOSED,2021-02-20T21:01:42Z,2021-03-06T16:08:23Z,Only keep one dep-graph in memory,cjgillot,NA,NA,NA,EYES,2021-02-20T21:20:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82345,CLOSED,2021-02-20T21:01:42Z,2021-03-06T16:08:23Z,Only keep one dep-graph in memory,cjgillot,NA,NA,NA,EYES,2021-02-20T22:25:40Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/82345,CLOSED,2021-02-20T21:01:42Z,2021-03-06T16:08:23Z,Only keep one dep-graph in memory,cjgillot,NA,NA,NA,EYES,2021-02-21T02:35:46Z,tesuji,NA https://github.com/rust-lang/rust/pull/82347,MERGED,2021-02-20T22:38:04Z,2021-04-04T11:15:12Z,Parallelize tidy,the8472,f98135b7a24a54964f83ca1dc2dfb6bd1d35b1bd,5,Auto merge of #82347 - the8472:parallelize-tidy r=Mark-Simulacrum Parallelize tidy Split off from #81833 While that PR brings wall time of `x.py test tidy` down to 0m2.847s adding this one on top should bring it down to 0m1.673s. r? `@Mark-Simulacrum` Previous concerns can be found at https://github.com/rust-lang/rust/pull/81833#issuecomment-782754685 and https://github.com/rust-lang/rust/pull/81833#discussion_r575194633,HEART,2021-04-10T15:38:57Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82347,MERGED,2021-02-20T22:38:04Z,2021-04-04T11:15:12Z,Parallelize tidy,the8472,f98135b7a24a54964f83ca1dc2dfb6bd1d35b1bd,5,Auto merge of #82347 - the8472:parallelize-tidy r=Mark-Simulacrum Parallelize tidy Split off from #81833 While that PR brings wall time of `x.py test tidy` down to 0m2.847s adding this one on top should bring it down to 0m1.673s. r? `@Mark-Simulacrum` Previous concerns can be found at https://github.com/rust-lang/rust/pull/81833#issuecomment-782754685 and https://github.com/rust-lang/rust/pull/81833#discussion_r575194633,ROCKET,2021-04-10T15:39:00Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82350,MERGED,2021-02-20T23:35:57Z,2021-02-28T12:08:47Z,Add a chapter on the test harness.,ehuss,247337f4093b3177760a25a11b3e1f130882c37c,4,Auto merge of #82350 - ehuss:test-chapter r=jyn514 Add a chapter on the test harness. There isn't really any online documentation on the test harness so this adds a chapter to the rustc book which provides information on how the harness works and details on the command-line options.,HOORAY,2021-02-21T06:17:34Z,trevarj,tmarjeski@gmail.com https://github.com/rust-lang/rust/pull/82350,MERGED,2021-02-20T23:35:57Z,2021-02-28T12:08:47Z,Add a chapter on the test harness.,ehuss,247337f4093b3177760a25a11b3e1f130882c37c,4,Auto merge of #82350 - ehuss:test-chapter r=jyn514 Add a chapter on the test harness. There isn't really any online documentation on the test harness so this adds a chapter to the rustc book which provides information on how the harness works and details on the command-line options.,HEART,2021-02-22T03:41:38Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82354,CLOSED,2021-02-21T01:22:02Z,2021-03-18T03:59:14Z,Remove RefCell from `JsonRenderer.index`,camelid,NA,NA,NA,HEART,2021-02-28T20:12:48Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/82364,MERGED,2021-02-21T10:30:42Z,2021-02-25T18:14:54Z,Improve error msgs when found type is deref of expected,osa1,12ea0f6112d99310ba992f5656c29929da0bc6eb,5,Rollup merge of #82364 - osa1:issue82361 r=estebank Improve error msgs when found type is deref of expected This improves help messages in two cases: - When expected type is `T` and found type is `&T` we now look through blocks and suggest dereferencing the expression of the block rather than the whole block. - In the above case if the expression is an `&` we not suggest removing the `&` instead of adding `*`. Both of these are demonstrated in the regression test. Before this patch the first error in the test would be: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ expected `usize` found `&usize` 9 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 7 | } else *{ 8 | b 9 | }; | Now: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ | | | | | expected `usize` found `&usize` | | help: consider dereferencing the borrow: `*b` 9 | | }; | |_____- `if` and `else` have incompatible types The second error: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^^ expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 13 | } else *{ 14 | &1 15 | }; | now: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^- | | || | | |help: consider removing the `&`: `1` | | expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types Fixes #82361 --- r? ````@estebank````,THUMBS_UP,2021-02-21T12:02:37Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82364,MERGED,2021-02-21T10:30:42Z,2021-02-25T18:14:54Z,Improve error msgs when found type is deref of expected,osa1,12ea0f6112d99310ba992f5656c29929da0bc6eb,5,Rollup merge of #82364 - osa1:issue82361 r=estebank Improve error msgs when found type is deref of expected This improves help messages in two cases: - When expected type is `T` and found type is `&T` we now look through blocks and suggest dereferencing the expression of the block rather than the whole block. - In the above case if the expression is an `&` we not suggest removing the `&` instead of adding `*`. Both of these are demonstrated in the regression test. Before this patch the first error in the test would be: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ expected `usize` found `&usize` 9 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 7 | } else *{ 8 | b 9 | }; | Now: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ | | | | | expected `usize` found `&usize` | | help: consider dereferencing the borrow: `*b` 9 | | }; | |_____- `if` and `else` have incompatible types The second error: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^^ expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 13 | } else *{ 14 | &1 15 | }; | now: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^- | | || | | |help: consider removing the `&`: `1` | | expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types Fixes #82361 --- r? ````@estebank````,THUMBS_UP,2021-02-22T00:21:11Z,estebank,NA https://github.com/rust-lang/rust/pull/82364,MERGED,2021-02-21T10:30:42Z,2021-02-25T18:14:54Z,Improve error msgs when found type is deref of expected,osa1,12ea0f6112d99310ba992f5656c29929da0bc6eb,5,Rollup merge of #82364 - osa1:issue82361 r=estebank Improve error msgs when found type is deref of expected This improves help messages in two cases: - When expected type is `T` and found type is `&T` we now look through blocks and suggest dereferencing the expression of the block rather than the whole block. - In the above case if the expression is an `&` we not suggest removing the `&` instead of adding `*`. Both of these are demonstrated in the regression test. Before this patch the first error in the test would be: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ expected `usize` found `&usize` 9 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 7 | } else *{ 8 | b 9 | }; | Now: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ | | | | | expected `usize` found `&usize` | | help: consider dereferencing the borrow: `*b` 9 | | }; | |_____- `if` and `else` have incompatible types The second error: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^^ expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 13 | } else *{ 14 | &1 15 | }; | now: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^- | | || | | |help: consider removing the `&`: `1` | | expected integer found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types Fixes #82361 --- r? ````@estebank````,HEART,2021-02-26T03:19:20Z,tesuji,NA https://github.com/rust-lang/rust/pull/82372,MERGED,2021-02-21T16:27:05Z,2021-02-22T12:14:34Z,improve UnsafeCell docs,RalfJung,7958166300cc92da90b95a8c13cbf8f469832485,1,"Rollup merge of #82372 - RalfJung:unsafe-cell r=KodrAus improve UnsafeCell docs Sometimes [questions like this come up](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/UnsafeCells.20as.20raw.20pointers) because the UnsafeCell docs say ""it's the only legal way to obtain aliasable data that is considered mutable"". That is not entirely correct since raw pointers also provide that option. So I propose we focus the docs on the interaction of `UnsafeCell` and *shared references* specifically which is really where they are needed.",THUMBS_UP,2021-02-22T09:21:08Z,fpoli,NA https://github.com/rust-lang/rust/pull/82372,MERGED,2021-02-21T16:27:05Z,2021-02-22T12:14:34Z,improve UnsafeCell docs,RalfJung,7958166300cc92da90b95a8c13cbf8f469832485,1,"Rollup merge of #82372 - RalfJung:unsafe-cell r=KodrAus improve UnsafeCell docs Sometimes [questions like this come up](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/UnsafeCells.20as.20raw.20pointers) because the UnsafeCell docs say ""it's the only legal way to obtain aliasable data that is considered mutable"". That is not entirely correct since raw pointers also provide that option. So I propose we focus the docs on the interaction of `UnsafeCell` and *shared references* specifically which is really where they are needed.",THUMBS_UP,2021-02-28T22:39:16Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/82376,MERGED,2021-02-21T20:22:31Z,2021-03-02T16:02:56Z,Add option to enable MIR inlining independently of mir-opt-level,tmiasko,ae5e024194a99bf265c874d64999e6beae916cde,4,Rollup merge of #82376 - tmiasko:inline-options r=oli-obk Add option to enable MIR inlining independently of mir-opt-level Add `-Zinline-mir` option that enables MIR inlining independently of the current MIR opt level. The primary use-case is enabling MIR inlining on the default MIR opt level. Turn inlining thresholds into optional values to make it possible to configure different defaults depending on the current mir-opt-level (although thresholds are yet to be used in such a manner).,HEART,2021-02-22T11:06:41Z,bjorn3,NA https://github.com/rust-lang/rust/pull/82389,CLOSED,2021-02-22T07:42:35Z,2021-02-24T08:36:51Z,[WIP] Jemalloc updated to tikv-jemalloc-sys,jq-rs,NA,NA,NA,THUMBS_UP,2021-02-23T19:02:17Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/82402,MERGED,2021-02-22T14:35:54Z,2021-03-07T05:50:07Z,Remove RefCell around `module_trait_cache`,jyn514,3d762a7f36e1105b3f2988874e00806b8c331d6d,7,Rollup merge of #82402 - jyn514:module-cache-refcell r=GuillaumeGomez Remove RefCell around `module_trait_cache` This builds on https://github.com/rust-lang/rust/pull/82018 and should not be merged before. ## Don't require a `DocContext` for `report_diagnostic` This is needed for the next commit which needs mutable access to the `cx` from within the `decorate` closure. - Change `as_local_hir_id` to an associated function since it only needs a `TyCtxt` - Change `source_span_for_markdown_range` to only take a `TyCtxt` ## Remove RefCell around module_trait_cache This is mostly just changing lots of functions from `&DocContext` to `&mut DocContext`.,HEART,2021-02-24T19:01:55Z,camelid,NA https://github.com/rust-lang/rust/pull/82403,MERGED,2021-02-22T16:24:54Z,2021-03-01T11:53:28Z,rustbuild: print out env vars on verbose rustc invocations,pnkfelix,9720cd1d56c215df87dff7f5d0026c947b5c6c9b,1,"Rollup merge of #82403 - pnkfelix:rustbuild-emit-env-vars-on-verbose-verbose r=Mark-Simulacrum rustbuild: print out env vars on verbose rustc invocations Print out environment variables related to Rust on sufficiently verbose rustc invocations. Output is filtered via heuristic of only printing environment variables whose keys start with ""RUST"" or ""CARGO."" This filtering is mostly motivated by my not caring to see e.g. ""PATH"" in my own output though it is also motivated as a way to try to avoid printing out personal secrets like github keys that people might have stored in their environments for better or for worse especially since build output is often pasted into bug reports or gists. Fix #38686.
Click here to see sample output Sample output looks like: ``` ... Fresh core v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/library/core) rustc env[0]: ""CARGO""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"" rustc env[1]: ""CARGO_CRATE_NAME""=""core"" rustc env[2]: ""CARGO_INCREMENTAL""=""0"" rustc env[3]: ""CARGO_MAKEFLAGS""=""--jobserver-fds=5 6 -j --jobserver-auth=5 6 -j"" rustc env[4]: ""CARGO_MANIFEST_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/library/core"" rustc env[5]: ""CARGO_PKG_AUTHORS""=""The Rust Project Developers"" rustc env[6]: ""CARGO_PKG_DESCRIPTION""="""" rustc env[7]: ""CARGO_PKG_HOMEPAGE""="""" rustc env[8]: ""CARGO_PKG_LICENSE""="""" rustc env[9]: ""CARGO_PKG_LICENSE_FILE""="""" rustc env[10]: ""CARGO_PKG_NAME""=""core"" rustc env[11]: ""CARGO_PKG_REPOSITORY""="""" rustc env[12]: ""CARGO_PKG_VERSION""=""0.0.0"" rustc env[13]: ""CARGO_PKG_VERSION_MAJOR""=""0"" rustc env[14]: ""CARGO_PKG_VERSION_MINOR""=""0"" rustc env[15]: ""CARGO_PKG_VERSION_PATCH""=""0"" rustc env[16]: ""CARGO_PKG_VERSION_PRE""="""" rustc env[17]: ""CARGO_PROFILE_RELEASE_CODEGEN_UNITS""=""256"" rustc env[18]: ""CARGO_PROFILE_RELEASE_DEBUG""=""0"" rustc env[19]: ""CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS""=""false"" rustc env[20]: ""CARGO_TARGET_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std"" rustc env[21]: ""RUSTBUILD_NATIVE_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/native"" rustc env[22]: ""RUSTC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustc"" rustc env[23]: ""RUSTC_BOOTSTRAP""=""1"" rustc env[24]: ""RUSTC_BREAK_ON_ICE""=""1"" rustc env[25]: ""RUSTC_ERROR_METADATA_DST""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/tmp/extended-error-metadata"" rustc env[26]: ""RUSTC_FORCE_UNSTABLE""=""1"" rustc env[27]: ""RUSTC_INSTALL_BINDIR""=""bin"" rustc env[28]: ""RUSTC_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[29]: ""RUSTC_LINT_FLAGS""=""-Wrust_2018_idioms -Wunused_lifetimes -Dwarnings"" rustc env[30]: ""RUSTC_PRINT_STEP_TIMINGS""=""1"" rustc env[31]: ""RUSTC_REAL""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[32]: ""RUSTC_SNAPSHOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[33]: ""RUSTC_SNAPSHOT_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[34]: ""RUSTC_STAGE""=""0"" rustc env[35]: ""RUSTC_SYSROOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-sysroot"" rustc env[36]: ""RUSTC_VERBOSE""=""2"" rustc env[37]: ""RUSTDOC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustdoc"" rustc env[38]: ""RUSTDOCFLAGS""=""--cfg=bootstrap -Dwarnings -Winvalid_codeblock_attributes --crate-version 1.52.0-dev"" rustc env[39]: ""RUSTDOC_REAL""=""/path/to/nowhere/rustdoc/not/required"" rustc env[40]: ""RUSTFLAGS""=""--cfg=bootstrap -Zmacro-backtrace -Clink-args=-Wl -rpath $ORIGIN/../lib -Cprefer-dynamic"" rustc env[41]: ""RUST_COMPILER_RT_ROOT""=""/home/pnkfelix/Dev/Rust/rust.git/src/llvm-project/compiler-rt"" rustc env[42]: ""RUST_TEST_THREADS""=""128"" rustc working directory: /home/pnkfelix/Dev/Rust/rust.git rustc command: ""LD_LIBRARY_PATH""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib:/home/pnkfelix/Dev/Rust/rust.git/objdi\ r-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps:/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" ""/home\ /pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" ""--crate-name"" ""core"" ""--edition=2018"" ""library/core/src/lib.rs"" ""--er\ ror-format=json"" ""--json=diagnostic-rendered-ansi artifacts"" ""--crate-type"" ""lib"" ""--emit=dep-info metadata link"" ""-C"" ""opt-level=3"" ""-C"" ""embed-bitcode=no"" ""-C"" \ ""codegen-units=256"" ""-C"" ""debuginfo=0"" ""-C"" ""metadata=6748933694d8be19"" ""-C"" ""extra-filename=-6748933694d8be19"" ""--out-dir"" ""/home/pnkfelix/Dev/Rust/rust.git/objd\ ir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""--target"" ""x86_64-unknown-linux-gnu"" ""-L"" ""dependency=/home/pnkfelix/\ Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""-L"" ""dependency=/home/pnkfelix/Dev/Rust/rust.gi\ t/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps"" ""--cfg=bootstrap"" ""-Zmacro-backtrace"" ""-Clink-args=-Wl -rpath $ORIGIN/../lib"" ""-Cprefer-d\ ynamic"" ""-Z"" ""binary-dep-depinfo"" ""-Wrust_2018_idioms"" ""-Wunused_lifetimes"" ""-Dwarnings"" ""--sysroot"" ""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64\ -unknown-linux-gnu/stage0-sysroot"" ""-Z"" ""force-unstable-if-unmarked"" ... ```",HEART,2021-02-22T16:39:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82403,MERGED,2021-02-22T16:24:54Z,2021-03-01T11:53:28Z,rustbuild: print out env vars on verbose rustc invocations,pnkfelix,9720cd1d56c215df87dff7f5d0026c947b5c6c9b,1,"Rollup merge of #82403 - pnkfelix:rustbuild-emit-env-vars-on-verbose-verbose r=Mark-Simulacrum rustbuild: print out env vars on verbose rustc invocations Print out environment variables related to Rust on sufficiently verbose rustc invocations. Output is filtered via heuristic of only printing environment variables whose keys start with ""RUST"" or ""CARGO."" This filtering is mostly motivated by my not caring to see e.g. ""PATH"" in my own output though it is also motivated as a way to try to avoid printing out personal secrets like github keys that people might have stored in their environments for better or for worse especially since build output is often pasted into bug reports or gists. Fix #38686.
Click here to see sample output Sample output looks like: ``` ... Fresh core v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/library/core) rustc env[0]: ""CARGO""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"" rustc env[1]: ""CARGO_CRATE_NAME""=""core"" rustc env[2]: ""CARGO_INCREMENTAL""=""0"" rustc env[3]: ""CARGO_MAKEFLAGS""=""--jobserver-fds=5 6 -j --jobserver-auth=5 6 -j"" rustc env[4]: ""CARGO_MANIFEST_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/library/core"" rustc env[5]: ""CARGO_PKG_AUTHORS""=""The Rust Project Developers"" rustc env[6]: ""CARGO_PKG_DESCRIPTION""="""" rustc env[7]: ""CARGO_PKG_HOMEPAGE""="""" rustc env[8]: ""CARGO_PKG_LICENSE""="""" rustc env[9]: ""CARGO_PKG_LICENSE_FILE""="""" rustc env[10]: ""CARGO_PKG_NAME""=""core"" rustc env[11]: ""CARGO_PKG_REPOSITORY""="""" rustc env[12]: ""CARGO_PKG_VERSION""=""0.0.0"" rustc env[13]: ""CARGO_PKG_VERSION_MAJOR""=""0"" rustc env[14]: ""CARGO_PKG_VERSION_MINOR""=""0"" rustc env[15]: ""CARGO_PKG_VERSION_PATCH""=""0"" rustc env[16]: ""CARGO_PKG_VERSION_PRE""="""" rustc env[17]: ""CARGO_PROFILE_RELEASE_CODEGEN_UNITS""=""256"" rustc env[18]: ""CARGO_PROFILE_RELEASE_DEBUG""=""0"" rustc env[19]: ""CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS""=""false"" rustc env[20]: ""CARGO_TARGET_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std"" rustc env[21]: ""RUSTBUILD_NATIVE_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/native"" rustc env[22]: ""RUSTC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustc"" rustc env[23]: ""RUSTC_BOOTSTRAP""=""1"" rustc env[24]: ""RUSTC_BREAK_ON_ICE""=""1"" rustc env[25]: ""RUSTC_ERROR_METADATA_DST""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/tmp/extended-error-metadata"" rustc env[26]: ""RUSTC_FORCE_UNSTABLE""=""1"" rustc env[27]: ""RUSTC_INSTALL_BINDIR""=""bin"" rustc env[28]: ""RUSTC_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[29]: ""RUSTC_LINT_FLAGS""=""-Wrust_2018_idioms -Wunused_lifetimes -Dwarnings"" rustc env[30]: ""RUSTC_PRINT_STEP_TIMINGS""=""1"" rustc env[31]: ""RUSTC_REAL""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[32]: ""RUSTC_SNAPSHOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[33]: ""RUSTC_SNAPSHOT_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[34]: ""RUSTC_STAGE""=""0"" rustc env[35]: ""RUSTC_SYSROOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-sysroot"" rustc env[36]: ""RUSTC_VERBOSE""=""2"" rustc env[37]: ""RUSTDOC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustdoc"" rustc env[38]: ""RUSTDOCFLAGS""=""--cfg=bootstrap -Dwarnings -Winvalid_codeblock_attributes --crate-version 1.52.0-dev"" rustc env[39]: ""RUSTDOC_REAL""=""/path/to/nowhere/rustdoc/not/required"" rustc env[40]: ""RUSTFLAGS""=""--cfg=bootstrap -Zmacro-backtrace -Clink-args=-Wl -rpath $ORIGIN/../lib -Cprefer-dynamic"" rustc env[41]: ""RUST_COMPILER_RT_ROOT""=""/home/pnkfelix/Dev/Rust/rust.git/src/llvm-project/compiler-rt"" rustc env[42]: ""RUST_TEST_THREADS""=""128"" rustc working directory: /home/pnkfelix/Dev/Rust/rust.git rustc command: ""LD_LIBRARY_PATH""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib:/home/pnkfelix/Dev/Rust/rust.git/objdi\ r-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps:/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" ""/home\ /pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" ""--crate-name"" ""core"" ""--edition=2018"" ""library/core/src/lib.rs"" ""--er\ ror-format=json"" ""--json=diagnostic-rendered-ansi artifacts"" ""--crate-type"" ""lib"" ""--emit=dep-info metadata link"" ""-C"" ""opt-level=3"" ""-C"" ""embed-bitcode=no"" ""-C"" \ ""codegen-units=256"" ""-C"" ""debuginfo=0"" ""-C"" ""metadata=6748933694d8be19"" ""-C"" ""extra-filename=-6748933694d8be19"" ""--out-dir"" ""/home/pnkfelix/Dev/Rust/rust.git/objd\ ir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""--target"" ""x86_64-unknown-linux-gnu"" ""-L"" ""dependency=/home/pnkfelix/\ Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""-L"" ""dependency=/home/pnkfelix/Dev/Rust/rust.gi\ t/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps"" ""--cfg=bootstrap"" ""-Zmacro-backtrace"" ""-Clink-args=-Wl -rpath $ORIGIN/../lib"" ""-Cprefer-d\ ynamic"" ""-Z"" ""binary-dep-depinfo"" ""-Wrust_2018_idioms"" ""-Wunused_lifetimes"" ""-Dwarnings"" ""--sysroot"" ""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64\ -unknown-linux-gnu/stage0-sysroot"" ""-Z"" ""force-unstable-if-unmarked"" ... ```",HEART,2021-02-22T16:47:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82403,MERGED,2021-02-22T16:24:54Z,2021-03-01T11:53:28Z,rustbuild: print out env vars on verbose rustc invocations,pnkfelix,9720cd1d56c215df87dff7f5d0026c947b5c6c9b,1,"Rollup merge of #82403 - pnkfelix:rustbuild-emit-env-vars-on-verbose-verbose r=Mark-Simulacrum rustbuild: print out env vars on verbose rustc invocations Print out environment variables related to Rust on sufficiently verbose rustc invocations. Output is filtered via heuristic of only printing environment variables whose keys start with ""RUST"" or ""CARGO."" This filtering is mostly motivated by my not caring to see e.g. ""PATH"" in my own output though it is also motivated as a way to try to avoid printing out personal secrets like github keys that people might have stored in their environments for better or for worse especially since build output is often pasted into bug reports or gists. Fix #38686.
Click here to see sample output Sample output looks like: ``` ... Fresh core v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/library/core) rustc env[0]: ""CARGO""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"" rustc env[1]: ""CARGO_CRATE_NAME""=""core"" rustc env[2]: ""CARGO_INCREMENTAL""=""0"" rustc env[3]: ""CARGO_MAKEFLAGS""=""--jobserver-fds=5 6 -j --jobserver-auth=5 6 -j"" rustc env[4]: ""CARGO_MANIFEST_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/library/core"" rustc env[5]: ""CARGO_PKG_AUTHORS""=""The Rust Project Developers"" rustc env[6]: ""CARGO_PKG_DESCRIPTION""="""" rustc env[7]: ""CARGO_PKG_HOMEPAGE""="""" rustc env[8]: ""CARGO_PKG_LICENSE""="""" rustc env[9]: ""CARGO_PKG_LICENSE_FILE""="""" rustc env[10]: ""CARGO_PKG_NAME""=""core"" rustc env[11]: ""CARGO_PKG_REPOSITORY""="""" rustc env[12]: ""CARGO_PKG_VERSION""=""0.0.0"" rustc env[13]: ""CARGO_PKG_VERSION_MAJOR""=""0"" rustc env[14]: ""CARGO_PKG_VERSION_MINOR""=""0"" rustc env[15]: ""CARGO_PKG_VERSION_PATCH""=""0"" rustc env[16]: ""CARGO_PKG_VERSION_PRE""="""" rustc env[17]: ""CARGO_PROFILE_RELEASE_CODEGEN_UNITS""=""256"" rustc env[18]: ""CARGO_PROFILE_RELEASE_DEBUG""=""0"" rustc env[19]: ""CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS""=""false"" rustc env[20]: ""CARGO_TARGET_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std"" rustc env[21]: ""RUSTBUILD_NATIVE_DIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/native"" rustc env[22]: ""RUSTC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustc"" rustc env[23]: ""RUSTC_BOOTSTRAP""=""1"" rustc env[24]: ""RUSTC_BREAK_ON_ICE""=""1"" rustc env[25]: ""RUSTC_ERROR_METADATA_DST""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/tmp/extended-error-metadata"" rustc env[26]: ""RUSTC_FORCE_UNSTABLE""=""1"" rustc env[27]: ""RUSTC_INSTALL_BINDIR""=""bin"" rustc env[28]: ""RUSTC_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[29]: ""RUSTC_LINT_FLAGS""=""-Wrust_2018_idioms -Wunused_lifetimes -Dwarnings"" rustc env[30]: ""RUSTC_PRINT_STEP_TIMINGS""=""1"" rustc env[31]: ""RUSTC_REAL""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[32]: ""RUSTC_SNAPSHOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" rustc env[33]: ""RUSTC_SNAPSHOT_LIBDIR""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" rustc env[34]: ""RUSTC_STAGE""=""0"" rustc env[35]: ""RUSTC_SYSROOT""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-sysroot"" rustc env[36]: ""RUSTC_VERBOSE""=""2"" rustc env[37]: ""RUSTDOC""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustdoc"" rustc env[38]: ""RUSTDOCFLAGS""=""--cfg=bootstrap -Dwarnings -Winvalid_codeblock_attributes --crate-version 1.52.0-dev"" rustc env[39]: ""RUSTDOC_REAL""=""/path/to/nowhere/rustdoc/not/required"" rustc env[40]: ""RUSTFLAGS""=""--cfg=bootstrap -Zmacro-backtrace -Clink-args=-Wl -rpath $ORIGIN/../lib -Cprefer-dynamic"" rustc env[41]: ""RUST_COMPILER_RT_ROOT""=""/home/pnkfelix/Dev/Rust/rust.git/src/llvm-project/compiler-rt"" rustc env[42]: ""RUST_TEST_THREADS""=""128"" rustc working directory: /home/pnkfelix/Dev/Rust/rust.git rustc command: ""LD_LIBRARY_PATH""=""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib:/home/pnkfelix/Dev/Rust/rust.git/objdi\ r-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps:/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"" ""/home\ /pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"" ""--crate-name"" ""core"" ""--edition=2018"" ""library/core/src/lib.rs"" ""--er\ ror-format=json"" ""--json=diagnostic-rendered-ansi artifacts"" ""--crate-type"" ""lib"" ""--emit=dep-info metadata link"" ""-C"" ""opt-level=3"" ""-C"" ""embed-bitcode=no"" ""-C"" \ ""codegen-units=256"" ""-C"" ""debuginfo=0"" ""-C"" ""metadata=6748933694d8be19"" ""-C"" ""extra-filename=-6748933694d8be19"" ""--out-dir"" ""/home/pnkfelix/Dev/Rust/rust.git/objd\ ir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""--target"" ""x86_64-unknown-linux-gnu"" ""-L"" ""dependency=/home/pnkfelix/\ Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps"" ""-L"" ""dependency=/home/pnkfelix/Dev/Rust/rust.gi\ t/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps"" ""--cfg=bootstrap"" ""-Zmacro-backtrace"" ""-Clink-args=-Wl -rpath $ORIGIN/../lib"" ""-Cprefer-d\ ynamic"" ""-Z"" ""binary-dep-depinfo"" ""-Wrust_2018_idioms"" ""-Wunused_lifetimes"" ""-Dwarnings"" ""--sysroot"" ""/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64\ -unknown-linux-gnu/stage0-sysroot"" ""-Z"" ""force-unstable-if-unmarked"" ... ```",HEART,2021-03-01T17:33:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82415,MERGED,2021-02-22T19:46:08Z,2021-03-08T17:51:49Z,expand: Refactor module loading,petrochenkov,4a4e3e667d22442cbfdd04c9fe0adcf70e497751,15,Rollup merge of #82415 - petrochenkov:modin3 r=davidtwco expand: Refactor module loading This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399 but they can be landed independently. See individual commits for more details. Anyone should be able to review this equally well because all people actually familiar with this code left the project.,LAUGH,2021-02-23T01:24:17Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/82415,MERGED,2021-02-22T19:46:08Z,2021-03-08T17:51:49Z,expand: Refactor module loading,petrochenkov,4a4e3e667d22442cbfdd04c9fe0adcf70e497751,15,Rollup merge of #82415 - petrochenkov:modin3 r=davidtwco expand: Refactor module loading This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399 but they can be landed independently. See individual commits for more details. Anyone should be able to review this equally well because all people actually familiar with this code left the project.,LAUGH,2021-02-23T20:08:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82431,MERGED,2021-02-23T02:08:34Z,2021-02-26T00:17:32Z,Set RUST_BACKTRACE=0 when running `treat-err-as-bug` tests,Aaron1011,239e41df311e5fe29138c8e0ffd8d4326e4a6be0,4,Rollup merge of #82431 - Aaron1011:fix/bug-env r=jyn514 Set RUST_BACKTRACE=0 when running `treat-err-as-bug` tests These ensure that these tests pass regardless of what RUST_BACKTRACE is set to in the user's shell.,THUMBS_UP,2021-02-23T02:18:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HOORAY,2021-02-23T17:38:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,ROCKET,2021-02-23T17:39:28Z,lqd,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HOORAY,2021-02-23T17:46:04Z,tmiasko,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HEART,2021-02-23T18:17:17Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,ROCKET,2021-02-25T20:14:08Z,fmease,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HOORAY,2021-02-27T09:18:00Z,lin7sh,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HEART,2021-02-27T09:18:00Z,lin7sh,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,ROCKET,2021-02-27T09:18:00Z,lin7sh,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HOORAY,2021-02-27T15:57:07Z,bjorn3,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HEART,2021-02-27T15:57:07Z,bjorn3,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,ROCKET,2021-02-27T15:57:09Z,bjorn3,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HEART,2021-02-27T16:06:07Z,RalfJung,NA https://github.com/rust-lang/rust/pull/82447,MERGED,2021-02-23T17:17:21Z,2021-02-25T21:01:05Z,Add #[rustc_legacy_const_generics],Amanieu,98f8cce6db6c6c6660eeffee2b3903104e547ecf,16,Auto merge of #82447 - Amanieu:legacy_const_generics r=oli-obk Add #[rustc_legacy_const_generics] This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a b c)` to `func::<{b}>(a c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead. This new attribute is not intended to ever be stabilized it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`. ```rust #[rustc_legacy_const_generics(1)] pub fn foo(x: usize z: usize) -> [usize; 3] { [x Y z] } fn main() { assert_eq!(foo(0 + 0 1 + 1 2 + 2) [0 2 4]); assert_eq!(foo::<{1 + 1}>(0 + 0 2 + 2) [0 2 4]); } ``` r? `@oli-obk`,HEART,2021-02-28T03:32:28Z,varkor,NA https://github.com/rust-lang/rust/pull/82451,MERGED,2021-02-23T18:13:25Z,2021-04-07T23:14:20Z,Cleanup option parsing and config.toml.example,jyn514,361bfce305b8829eda7f3d133fe82a118685de1f,6,Auto merge of #82451 - jyn514:defaults r=Mark-Simulacrum Cleanup option parsing and config.toml.example - Add an assertion that `link-shared = true` when `thin-lto = true`. Previously link-shared would be silently overwritten. - Get rid of `Option` in bootstrap/config.rs. Set defaults immediately instead of delaying until later in bootstrap. This makes it easier to find what the default value is. - Remove redundant `config.x = false` when the default was already false - Set defaults for `bindir` in `default_opts()` instead of `parse()` - Update `download-ci-llvm = if-supported` option to match bootstrap.py - Remove redundant check for link_shared. Previously it was checked twice. - Update various options in config.toml.example to their defaults. Previously some options showed an example value instead of the default value. - Fix incorrect defaults in config.toml.example + `use-libcxx` defaults to false + Add missing `check-stage = 0` + Update several defaults to be conditional (e.g. `if incremental { 10 } else { 100 }`) - Remove redundant defaults in prose - Use the same comment for the default and target-dependent `musl-root` - Fix typos - Link to `cc_detect` for `cc` and `cxx` since the logic is ... complicated. - Update more defaults to better reflect how they actually get set - Remove ignored `gpg-password-file` option This stopped being used in 7704d35 but was never removed from config.toml. - Remove unused flags from `config.toml` + Disallow `infodir` and `localstatedir` in `config.toml` + Allow the flags in `./configure` but give a warning that they will be ignored. + Fix incorrect comment that `datadir` will be ignored. Example output: ``` $ ./configure --set install.infodir=xxx configure: processing command line configure: configure: install.infodir := xxx configure: build.configure-args := ['--set' 'install.infodir=xxx'] warning: infodir will be ignored configure: configure: writing `config.toml` in current directory configure: configure: run `python /home/joshua/rustc3/x.py --help` configure: ``` - Update CHANGELOG cc https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/bootstrap.20defaults,HEART,2021-10-13T01:24:59Z,tmandry,NA https://github.com/rust-lang/rust/pull/82469,MERGED,2021-02-24T06:49:59Z,2021-03-03T11:05:13Z,Use a crate to produce rustdoc tree comparisons instead of the `diff` command,notriddle,0c7e8983b0e03328b383eb0089474d816631acf3,3,Rollup merge of #82469 - notriddle:bring-our-own-diff r=Mark-Simulacrum Use a crate to produce rustdoc tree comparisons instead of the `diff` command It doesn't come with Windows so bring [our own](https://github.com/notriddle/rust-unified-diff/). Fixes #82409 ![image](https://user-images.githubusercontent.com/1593513/109230755-9a1d5700-7782-11eb-8359-353a506875ab.png),HEART,2021-02-24T16:20:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82489,OPEN,2021-02-24T18:37:43Z,NA,Add #[rustc_per_edition] for edition-dependent type aliases.,m-ou-se,NA,NA,NA,THUMBS_UP,2021-02-24T22:55:16Z,elichai,NA https://github.com/rust-lang/rust/pull/82489,OPEN,2021-02-24T18:37:43Z,NA,Add #[rustc_per_edition] for edition-dependent type aliases.,m-ou-se,NA,NA,NA,THUMBS_UP,2021-02-25T20:04:57Z,fmease,NA https://github.com/rust-lang/rust/pull/82489,OPEN,2021-02-24T18:37:43Z,NA,Add #[rustc_per_edition] for edition-dependent type aliases.,m-ou-se,NA,NA,NA,THUMBS_UP,2021-03-05T16:17:53Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/82490,MERGED,2021-02-24T18:39:14Z,2021-02-27T05:05:47Z,Update cargo,ehuss,a1f75409a6e324064e74ae9efccb48d6d2075cff,1,Rollup merge of #82490 - ehuss:update-cargo r=ehuss Update cargo 11 commits in bf5a5d5e5d3ae842a63bfce6d070dfd438cf6070..572e201536dc2e4920346e28037b63c0f4d88b3c 2021-02-18 15:49:14 +0000 to 2021-02-24 16:51:20 +0000 - Pass the error message format to rustdoc (rust-lang/cargo#9128) - Fix test target_in_environment_contains_lower_case (rust-lang/cargo#9203) - Fix hang on broken stderr. (rust-lang/cargo#9201) - Make it more clear which module is being tested when running cargo test (rust-lang/cargo#9195) - Updates to edition handling. (rust-lang/cargo#9184) - Add --cfg and --rustc-cfg flags to output compiler configuration (rust-lang/cargo#9002) - Run rustdoc doctests relative to the workspace (rust-lang/cargo#9105) - Add support for [env] section in .cargo/config.toml (rust-lang/cargo#9175) - Add schema field and `features2` to the index. (rust-lang/cargo#9161) - Document the default location where cargo install emitting build artifacts (rust-lang/cargo#9189) - Do not exit prematurely if anything failed installing. (rust-lang/cargo#9185),HOORAY,2021-02-25T09:48:19Z,Hazardius,marcin.mateusz.hanc@gmail.com https://github.com/rust-lang/rust/pull/82497,MERGED,2021-02-24T21:25:22Z,2021-04-08T02:43:24Z,Fix handling of `--output-format json` flag,jyn514,cbe3eba99a74144f4f6474c3c6dca5edc2da3f1f,7,Rollup merge of #82497 - jyn514:json r=CraftSpider Fix handling of `--output-format json` flag - Don't treat it as deprecated on stable and beta channels. Before it would give confusing and incorrect output: ``` warning: the 'output-format' flag is considered deprecated | = warning: see issue #44136 for more information error: json output format isn't supported for doc generation ``` Both of those are wrong: output-format isn't deprecated and json output is supported. - Require -Z unstable-options for `--output-format json` Previously it was allowed by default on nightly which made it hard to realize the flag wouldn't be accepted on beta or stable. To get the test working I had to remove `-Z unstable-options` which x.py passed to compiletest unconditionally. It was first added in https://github.com/rust-lang/rust/commit/8c2ec689c159e7f021d5913efb991aff875be967 so `-Z miri` would be allowed. -Z miri is no longer passed unconditionally so hopefully removing it won't break anything. r? ```@aDotInTheVoid``` cc ```@HeroicKatora``` ```@CraftSpider``` Thanks to ```@memoryruins``` for pointing it out on Discord! cc ```@Mark-Simulacrum``` for the change to compiletest.,THUMBS_UP,2021-02-24T21:30:13Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/82497,MERGED,2021-02-24T21:25:22Z,2021-04-08T02:43:24Z,Fix handling of `--output-format json` flag,jyn514,cbe3eba99a74144f4f6474c3c6dca5edc2da3f1f,7,Rollup merge of #82497 - jyn514:json r=CraftSpider Fix handling of `--output-format json` flag - Don't treat it as deprecated on stable and beta channels. Before it would give confusing and incorrect output: ``` warning: the 'output-format' flag is considered deprecated | = warning: see issue #44136 for more information error: json output format isn't supported for doc generation ``` Both of those are wrong: output-format isn't deprecated and json output is supported. - Require -Z unstable-options for `--output-format json` Previously it was allowed by default on nightly which made it hard to realize the flag wouldn't be accepted on beta or stable. To get the test working I had to remove `-Z unstable-options` which x.py passed to compiletest unconditionally. It was first added in https://github.com/rust-lang/rust/commit/8c2ec689c159e7f021d5913efb991aff875be967 so `-Z miri` would be allowed. -Z miri is no longer passed unconditionally so hopefully removing it won't break anything. r? ```@aDotInTheVoid``` cc ```@HeroicKatora``` ```@CraftSpider``` Thanks to ```@memoryruins``` for pointing it out on Discord! cc ```@Mark-Simulacrum``` for the change to compiletest.,HEART,2021-02-24T22:36:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82497,MERGED,2021-02-24T21:25:22Z,2021-04-08T02:43:24Z,Fix handling of `--output-format json` flag,jyn514,cbe3eba99a74144f4f6474c3c6dca5edc2da3f1f,7,Rollup merge of #82497 - jyn514:json r=CraftSpider Fix handling of `--output-format json` flag - Don't treat it as deprecated on stable and beta channels. Before it would give confusing and incorrect output: ``` warning: the 'output-format' flag is considered deprecated | = warning: see issue #44136 for more information error: json output format isn't supported for doc generation ``` Both of those are wrong: output-format isn't deprecated and json output is supported. - Require -Z unstable-options for `--output-format json` Previously it was allowed by default on nightly which made it hard to realize the flag wouldn't be accepted on beta or stable. To get the test working I had to remove `-Z unstable-options` which x.py passed to compiletest unconditionally. It was first added in https://github.com/rust-lang/rust/commit/8c2ec689c159e7f021d5913efb991aff875be967 so `-Z miri` would be allowed. -Z miri is no longer passed unconditionally so hopefully removing it won't break anything. r? ```@aDotInTheVoid``` cc ```@HeroicKatora``` ```@CraftSpider``` Thanks to ```@memoryruins``` for pointing it out on Discord! cc ```@Mark-Simulacrum``` for the change to compiletest.,HEART,2021-04-16T14:53:47Z,rrbutani,NA https://github.com/rust-lang/rust/pull/82506,MERGED,2021-02-25T02:09:05Z,2021-02-26T21:59:00Z,Properly account for non-shorthand pattern field in unused variable lint,estebank,75959fb3566f722dc141d112fab047c4c0dcb5c5,4,Rollup merge of #82506 - estebank:unused_variable_lint r=lcnr Properly account for non-shorthand pattern field in unused variable lint Fix #82488,HEART,2021-02-25T03:29:44Z,tesuji,NA https://github.com/rust-lang/rust/pull/82506,MERGED,2021-02-25T02:09:05Z,2021-02-26T21:59:00Z,Properly account for non-shorthand pattern field in unused variable lint,estebank,75959fb3566f722dc141d112fab047c4c0dcb5c5,4,Rollup merge of #82506 - estebank:unused_variable_lint r=lcnr Properly account for non-shorthand pattern field in unused variable lint Fix #82488,THUMBS_UP,2021-02-25T10:44:27Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82506,MERGED,2021-02-25T02:09:05Z,2021-02-26T21:59:00Z,Properly account for non-shorthand pattern field in unused variable lint,estebank,75959fb3566f722dc141d112fab047c4c0dcb5c5,4,Rollup merge of #82506 - estebank:unused_variable_lint r=lcnr Properly account for non-shorthand pattern field in unused variable lint Fix #82488,THUMBS_UP,2021-02-27T14:27:30Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/82525,MERGED,2021-02-25T18:48:14Z,2021-03-27T22:19:08Z,make unaligned_references future-incompat lint warn-by-default,RalfJung,a900677eb962741bd522c653b7933e97af130f24,25,Rollup merge of #82525 - RalfJung:unaligned-ref-warn r=petrochenkov make unaligned_references future-incompat lint warn-by-default and also remove the safe_packed_borrows lint that it replaces. `std::ptr::addr_of!` has hit beta now and will hit stable in a month so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here. For references to packed fields outside `unsafe` blocks this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes the warning is just worded differently. For references to packed fields inside `unsafe` blocks this PR shows a new future-incompat warning. Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.,THUMBS_UP,2021-02-26T00:40:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82525,MERGED,2021-02-25T18:48:14Z,2021-03-27T22:19:08Z,make unaligned_references future-incompat lint warn-by-default,RalfJung,a900677eb962741bd522c653b7933e97af130f24,25,Rollup merge of #82525 - RalfJung:unaligned-ref-warn r=petrochenkov make unaligned_references future-incompat lint warn-by-default and also remove the safe_packed_borrows lint that it replaces. `std::ptr::addr_of!` has hit beta now and will hit stable in a month so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here. For references to packed fields outside `unsafe` blocks this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes the warning is just worded differently. For references to packed fields inside `unsafe` blocks this PR shows a new future-incompat warning. Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.,THUMBS_UP,2021-02-26T08:13:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82525,MERGED,2021-02-25T18:48:14Z,2021-03-27T22:19:08Z,make unaligned_references future-incompat lint warn-by-default,RalfJung,a900677eb962741bd522c653b7933e97af130f24,25,Rollup merge of #82525 - RalfJung:unaligned-ref-warn r=petrochenkov make unaligned_references future-incompat lint warn-by-default and also remove the safe_packed_borrows lint that it replaces. `std::ptr::addr_of!` has hit beta now and will hit stable in a month so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here. For references to packed fields outside `unsafe` blocks this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes the warning is just worded differently. For references to packed fields inside `unsafe` blocks this PR shows a new future-incompat warning. Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.,THUMBS_UP,2021-02-26T15:39:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82525,MERGED,2021-02-25T18:48:14Z,2021-03-27T22:19:08Z,make unaligned_references future-incompat lint warn-by-default,RalfJung,a900677eb962741bd522c653b7933e97af130f24,25,Rollup merge of #82525 - RalfJung:unaligned-ref-warn r=petrochenkov make unaligned_references future-incompat lint warn-by-default and also remove the safe_packed_borrows lint that it replaces. `std::ptr::addr_of!` has hit beta now and will hit stable in a month so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here. For references to packed fields outside `unsafe` blocks this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes the warning is just worded differently. For references to packed fields inside `unsafe` blocks this PR shows a new future-incompat warning. Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.,THUMBS_UP,2021-03-03T23:59:55Z,tmandry,NA https://github.com/rust-lang/rust/pull/82531,MERGED,2021-02-25T21:06:57Z,2021-03-01T11:53:27Z,Add GUI tests,GuillaumeGomez,a95c3f74b3c07d7ed3f11f322b5ee926c88bd521,2,"Rollup merge of #82531 - GuillaumeGomez:gui-tests-start r=jyn514 Add GUI tests The start of a lot more of GUI tests! \o/ One test is to ensure that the search input can always be selected in all rustdoc ""modes"" (mobile tablet mostly) whereas the second checks the shortcuts. r? `@jyn514`",HOORAY,2021-02-26T09:10:44Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/82532,MERGED,2021-02-25T21:27:10Z,2021-03-01T11:53:27Z,Add `build.print_step_rusage` to config.toml,pnkfelix,1020ed3d5012346fd47bd66c96863354d146cab8,4,Rollup merge of #82532 - pnkfelix:rustbuild-print-step-rusage r=Mark-Simulacrum Add `build.print_step_rusage` to config.toml Adds `build.print_step_rusage` to config.toml which is meant to be an easy way to let compiler developers get feedback on the terminal during bootstrap about resource usage during each step. The output is piggy-backed on `[PRINT-STEP-TIMINGS]` mostly because the functionality seemed to naturally fit there in the overall control-flow and output structure (even if very little is shared between the implementations themselves). Some sample output (from my Linux box where I believe the `max rss` output to be somewhat trust-worthy...): ``` [...] Compiling regex v1.4.3 [RUSTC-TIMING] tempfile test:false 0.323 user: 1.418662 sys: 0.81767 max rss (kb): 182084 page reclaims: 26615 page faults: 0 fs block inputs: 0 fs block outputs: 2160 voluntary ctxt switches: 798 involuntary ctxt switches: 131 Completed tempfile v3.1.0 in 0.3s [RUSTC-TIMING] chalk_ir test:false 1.890 user: 1.893603 sys: 0.99663 max rss (kb): 239432 page reclaims: 32107 page faults: 0 fs block inputs: 0 fs block outputs: 25008 voluntary ctxt switches: 108 involuntary ctxt switches: 183 Completed chalk-ir v0.55.0 in 1.9s Compiling rustc_data_structures v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/compiler/rustc_data_structures) [RUSTC-TIMING] chrono test:false 1.244 user: 3.333198 sys: 0.134963 max rss (kb): 246612 page reclaims: 44857 page faults: 0 fs block inputs: 0 fs block outputs: 11704 voluntary ctxt switches: 1043 involuntary ctxt switches: 326 Completed chrono v0.4.15 in 1.3s [RUSTC-TIMING] rustc_rayon test:false 1.332 user: 1.763912 sys: 0.75996 max rss (kb): 239076 page reclaims: 35285 page faults: 0 fs block inputs: 0 fs block outputs: 19576 voluntary ctxt switches: 359 involuntary ctxt switches: 168 Completed rustc-rayon v0.3.0 in 1.3s Compiling matchers v0.0.1 [RUSTC-TIMING] matchers test:false 0.100 user: 0.94495 sys: 0.15119 max rss (kb): 140076 page reclaims: 8200 page faults: 0 fs block inputs: 0 fs block outputs: 392 voluntary ctxt switches: 43 involuntary ctxt switches: 12 Completed matchers v0.0.1 in 0.1s [...] ```,THUMBS_UP,2021-02-26T01:28:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-02-26T01:53:40Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-02-26T08:15:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-02-26T11:39:28Z,r00ster91,NA https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-03-04T12:54:40Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-03-05T01:05:31Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-03-09T16:37:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/82539,CLOSED,2021-02-26T01:22:16Z,2021-04-16T05:18:32Z,Deprecate `doc(include)`,jyn514,NA,NA,NA,THUMBS_UP,2021-04-18T18:53:44Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/82540,CLOSED,2021-02-26T01:24:56Z,2021-03-20T19:10:42Z,#NAME?,matthiaskrgr,NA,NA,NA,THUMBS_UP,2021-02-26T13:09:13Z,fmease,NA https://github.com/rust-lang/rust/pull/82549,MERGED,2021-02-26T14:01:02Z,2021-02-26T21:59:00Z,"Revert ""Update normalize.css to 8.0.1""",GuillaumeGomez,0da9b474de36bf7954ceb51a0e483cc39e9d60da,1,"Rollup merge of #82549 - rust-lang:revert-82313-update-normalize-css r=apiraino Revert ""Update normalize.css to 8.0.1"" Reverts rust-lang/rust#82313 Fixes #82548 Fixes #82542 ``@jsha:`` I'm reverting until we can come up with a new version which is fully working. r? ``@jyn514``",THUMBS_UP,2021-02-26T16:59:34Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,HOORAY,2021-02-26T17:08:59Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,ROCKET,2021-02-26T17:09:02Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,HOORAY,2021-02-26T17:22:06Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,THUMBS_UP,2021-02-27T13:04:33Z,lnicola,NA https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,THUMBS_UP,2021-02-28T09:42:09Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,HOORAY,2021-02-28T09:42:10Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,THUMBS_UP,2021-03-03T05:40:39Z,yerke,NA https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,HOORAY,2021-03-03T05:40:40Z,yerke,NA https://github.com/rust-lang/rust/pull/82556,CLOSED,2021-02-26T17:03:06Z,2021-04-08T21:16:36Z,add dynamically-linked musl targets,kaniini,NA,NA,NA,ROCKET,2021-03-03T05:40:41Z,yerke,NA https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-02-27T13:00:58Z,lnicola,NA https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-02-28T18:28:35Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-07T07:10:12Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-11T10:53:15Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-11T12:18:07Z,Awpteamoose,awpteamoose@gmail.com https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-11T15:25:01Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-11T17:57:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-11T18:02:02Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/82557,MERGED,2021-02-26T17:21:19Z,2021-03-08T17:51:48Z,Add natvis for Result NonNull CString CStr and Cow,rylev,298c31b04a6d4959a957e24bc9f08ab4742283b0,3,Rollup merge of #82557 - rylev:natvis-improvements r=varkor Add natvis for Result NonNull CString CStr and Cow This adds natvis support (used for Windows debugging) to the following types: `Result` `NonNull` `CString` `CStr` and `Cow`.,HEART,2021-03-13T08:22:46Z,Wumpf,NA https://github.com/rust-lang/rust/pull/82562,MERGED,2021-02-26T21:06:39Z,2021-03-02T23:42:44Z,Optimize counting digits in line numbers during error reporting further,llogiq,35dbef235048f9a2939dc20effe083ca483c37ff,1,Auto merge of #82562 - llogiq:one-up-82248 r=oli-obk Optimize counting digits in line numbers during error reporting further This one-ups #82248 by switching the strategy: Instead of dividing the value by 10 repeatedly we compare with a limit that we multiply by 10 repeatedly. In my benchmarks this took between 50% and 25% of the original time. The reasons for being faster are: 1. While LLVM is able to replace a division by constant with a multiply + shift a plain multiplication is still faster. However this doesn't even factor because 2. Multiplication unlike division is const. We also use a simple for-loop instead of a more complex loop + break which allows 3. rustc to const-fold the whole loop and indeed the assembly output simply shows a series of comparisons.,THUMBS_UP,2021-02-26T21:14:41Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/82562,MERGED,2021-02-26T21:06:39Z,2021-03-02T23:42:44Z,Optimize counting digits in line numbers during error reporting further,llogiq,35dbef235048f9a2939dc20effe083ca483c37ff,1,Auto merge of #82562 - llogiq:one-up-82248 r=oli-obk Optimize counting digits in line numbers during error reporting further This one-ups #82248 by switching the strategy: Instead of dividing the value by 10 repeatedly we compare with a limit that we multiply by 10 repeatedly. In my benchmarks this took between 50% and 25% of the original time. The reasons for being faster are: 1. While LLVM is able to replace a division by constant with a multiply + shift a plain multiplication is still faster. However this doesn't even factor because 2. Multiplication unlike division is const. We also use a simple for-loop instead of a more complex loop + break which allows 3. rustc to const-fold the whole loop and indeed the assembly output simply shows a series of comparisons.,LAUGH,2021-02-26T22:22:19Z,nhwn,NA https://github.com/rust-lang/rust/pull/82562,MERGED,2021-02-26T21:06:39Z,2021-03-02T23:42:44Z,Optimize counting digits in line numbers during error reporting further,llogiq,35dbef235048f9a2939dc20effe083ca483c37ff,1,Auto merge of #82562 - llogiq:one-up-82248 r=oli-obk Optimize counting digits in line numbers during error reporting further This one-ups #82248 by switching the strategy: Instead of dividing the value by 10 repeatedly we compare with a limit that we multiply by 10 repeatedly. In my benchmarks this took between 50% and 25% of the original time. The reasons for being faster are: 1. While LLVM is able to replace a division by constant with a multiply + shift a plain multiplication is still faster. However this doesn't even factor because 2. Multiplication unlike division is const. We also use a simple for-loop instead of a more complex loop + break which allows 3. rustc to const-fold the whole loop and indeed the assembly output simply shows a series of comparisons.,HEART,2021-03-01T20:21:22Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/82562,MERGED,2021-02-26T21:06:39Z,2021-03-02T23:42:44Z,Optimize counting digits in line numbers during error reporting further,llogiq,35dbef235048f9a2939dc20effe083ca483c37ff,1,Auto merge of #82562 - llogiq:one-up-82248 r=oli-obk Optimize counting digits in line numbers during error reporting further This one-ups #82248 by switching the strategy: Instead of dividing the value by 10 repeatedly we compare with a limit that we multiply by 10 repeatedly. In my benchmarks this took between 50% and 25% of the original time. The reasons for being faster are: 1. While LLVM is able to replace a division by constant with a multiply + shift a plain multiplication is still faster. However this doesn't even factor because 2. Multiplication unlike division is const. We also use a simple for-loop instead of a more complex loop + break which allows 3. rustc to const-fold the whole loop and indeed the assembly output simply shows a series of comparisons.,LAUGH,2021-03-04T09:37:56Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82565,MERGED,2021-02-26T21:42:53Z,2021-03-25T13:11:21Z,Revert reverting of stabilizing integer::BITS.,m-ou-se,bba40880c0750f880119b4517821ffe0a96f74d1,9,Auto merge of #82565 - m-ou-se:ununstabilize-bits r=kennytm Revert reverting of stabilizing integer::BITS. Now that `lexical-core` has an updated version that won't break with this stabilization let's try to stabilize this again. See https://github.com/rust-lang/rust/issues/81654#issuecomment-778564715 Tracking issue with FCP: https://github.com/rust-lang/rust/issues/76904,THUMBS_UP,2021-03-12T13:31:10Z,Demiu,NA https://github.com/rust-lang/rust/pull/82570,MERGED,2021-02-26T23:03:52Z,2021-03-20T03:49:10Z,Add `as_str` method for split whitespace str iterators,WaffleLapkin,f7febc8865a2cb2287b034f6588d7617fa0fc6e9,4,Rollup merge of #82570 - WaffleLapkin:split_whitespace_as_str r=m-ou-se Add `as_str` method for split whitespace str iterators This PR adds `as_str` methods to `SplitWhitespace` and `SplitAsciiWhitespace` str iterators. The methods return the remainder similar to `as_str` methods on `Chars` and other split iterators. This PR is a continuation of https://github.com/rust-lang/rust/pull/75265 which added `as_str` for all other str split iterators. The feature gate for new methods is `#![feature(str_split_whitespace_as_str)]`. `SplitWhitespace` and `SplitAsciiWhitespace` use iterators under the hood so to implement `as_str` it's required to either 1. Make fields of some iterators `pub(crate)` 2. Add getter methods (like `into_inner` `inner` `inner_mut`...) to some (all) iterators 3. Completely rewrite `SplitWhitespace` and `SplitAsciiWhitespace` This PR uses the 1. approach since it's easier to implement and requires fewer changes (and no changes to the public API). If you think that's not the right way please tell me. r? `@m-ou-se`,THUMBS_UP,2021-03-18T01:16:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82570,MERGED,2021-02-26T23:03:52Z,2021-03-20T03:49:10Z,Add `as_str` method for split whitespace str iterators,WaffleLapkin,f7febc8865a2cb2287b034f6588d7617fa0fc6e9,4,Rollup merge of #82570 - WaffleLapkin:split_whitespace_as_str r=m-ou-se Add `as_str` method for split whitespace str iterators This PR adds `as_str` methods to `SplitWhitespace` and `SplitAsciiWhitespace` str iterators. The methods return the remainder similar to `as_str` methods on `Chars` and other split iterators. This PR is a continuation of https://github.com/rust-lang/rust/pull/75265 which added `as_str` for all other str split iterators. The feature gate for new methods is `#![feature(str_split_whitespace_as_str)]`. `SplitWhitespace` and `SplitAsciiWhitespace` use iterators under the hood so to implement `as_str` it's required to either 1. Make fields of some iterators `pub(crate)` 2. Add getter methods (like `into_inner` `inner` `inner_mut`...) to some (all) iterators 3. Completely rewrite `SplitWhitespace` and `SplitAsciiWhitespace` This PR uses the 1. approach since it's easier to implement and requires fewer changes (and no changes to the public API). If you think that's not the right way please tell me. r? `@m-ou-se`,HEART,2021-03-26T06:46:42Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/82579,MERGED,2021-02-27T05:15:37Z,2021-03-02T16:02:56Z,Fix turbofish recovery with multiple generic args,osa1,906e53520505acbb3948be594135c60a16b68b81,7,Rollup merge of #82579 - osa1:issue82566 r=estebank Fix turbofish recovery with multiple generic args This consists of two commits each can be individually reviewed. - First commit fixes the issue in [this comment](https://github.com/rust-lang/rust/issues/82566#issuecomment-786924466). - Second commit fixes #82566 --- r? ````@estebank````,HEART,2021-02-27T14:38:14Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/82584,MERGED,2021-02-27T10:41:44Z,2021-02-28T03:56:02Z,Add ARIA role to sidebar toggle in Rustdoc,tazjin,a70be0bec92d59674348b22790b1b3681415d4e3,1,"Rollup merge of #82584 - tazjin:rustdoc-aria r=GuillaumeGomez Add ARIA role to sidebar toggle in Rustdoc This indicates that the div is an interactive element and makes the sidebar toggle ""clickable"" in assistive technologies. Example of Vimium after this change has been applied (see the issue mentioned below for a screenshot of before): ![Screenshot of Vimium link hints on a Rustdoc page indicating that the sidebar toggle is clickable](https://user-images.githubusercontent.com/1552853/109384961-ff935400-78f8-11eb-8199-1d35181aeff0.png) Fixes #82582",HEART,2021-02-28T17:46:03Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82585,MERGED,2021-02-27T11:49:55Z,2021-04-23T05:29:29Z,Added CharIndices::offset function,TrolledWoods,cb81dc535c453ed6e0368fe7b8336ba177950a2d,2,Auto merge of #82585 - TrolledWoods:master r=dtolnay Added CharIndices::offset function The CharIndices iterator has a field internally called front_offset that I think would be very useful to have access to. You can already do something like ``char_indices.next().map(|(offset _)| offset)`` but that is wordy in addition to not handling the case where the iterator has ended where you'd want the offset to be equal to the length. I'm very new to the open source world and the rust repository so I'm sorry if I missed a step or did something weird.,THUMBS_UP,2021-04-23T06:03:16Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/82596,MERGED,2021-02-27T16:19:08Z,2021-02-28T03:56:02Z,clarify RW lock's priority gotcha,matklad,e38b3eb0b56c7314980649d35b21b61e74a41bdc,1,"Rollup merge of #82596 - matklad:rwlock r=sfackler clarify RW lock's priority gotcha In particular the following program works on Linux but deadlocks on mac: ```rust use std::{ sync::{Arc RwLock} thread time::Duration }; fn main() { let lock = Arc::new(RwLock::new(())); let r1 = thread::spawn({ let lock = Arc::clone(&lock); move || { let _rg = lock.read(); eprintln!(""r1/1""); sleep(1000); let _rg = lock.read(); eprintln!(""r1/2""); sleep(5000); } }); sleep(100); let w = thread::spawn({ let lock = Arc::clone(&lock); move || { let _wg = lock.write(); eprintln!(""w""); } }); sleep(100); let r2 = thread::spawn({ let lock = Arc::clone(&lock); move || { let _rg = lock.read(); eprintln!(""r2""); sleep(2000); } }); r1.join().unwrap(); r2.join().unwrap(); w.join().unwrap(); } fn sleep(ms: u64) { std::thread::sleep(Duration::from_millis(ms)) } ``` Context: I was completely mystified by a my CI deadlocking on mac ([here](https://github.com/matklad/xshell/pull/7)) until ``@azdavis`` debugged the issue. See a stand-alone reproduciton here: https://github.com/matklad/xshell/pull/15",THUMBS_UP,2021-02-27T22:20:45Z,azdavis,NA https://github.com/rust-lang/rust/pull/82607,MERGED,2021-02-27T20:04:40Z,2021-02-28T03:56:02Z,Add a getter for Frame.loc,bjorn3,7847f690fd5d2a92cad833564fc05305d85c5634,1,Rollup merge of #82607 - bjorn3:frame_loc_getter r=RalfJung Add a getter for Frame.loc This is necessary for Priroda. For context see https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Frame.3A.3Aloc.20no.20longer.20public/near/228070266 and oli-obk/priroda#27. cc `@DJMcNab` r? `@RalfJung`,ROCKET,2021-02-27T20:27:17Z,DJMcNab,NA https://github.com/rust-lang/rust/pull/82620,MERGED,2021-02-28T05:38:51Z,2021-03-01T23:37:47Z,Apply lint restrictions from renamed lints,jyn514,68088026edcd915b34685cb6e619ef911798ed98,3,Rollup merge of #82620 - jyn514:apply-renamed-lints r=Manishearth Apply lint restrictions from renamed lints Previously if you denied the old name of a renamed lint it would warn about using the new name but otherwise do nothing. Now it will behave the same as if you'd used the new name. Fixes https://github.com/rust-lang/rust/issues/82615. r? `@ehuss`,THUMBS_UP,2021-02-28T07:30:07Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/82620,MERGED,2021-02-28T05:38:51Z,2021-03-01T23:37:47Z,Apply lint restrictions from renamed lints,jyn514,68088026edcd915b34685cb6e619ef911798ed98,3,Rollup merge of #82620 - jyn514:apply-renamed-lints r=Manishearth Apply lint restrictions from renamed lints Previously if you denied the old name of a renamed lint it would warn about using the new name but otherwise do nothing. Now it will behave the same as if you'd used the new name. Fixes https://github.com/rust-lang/rust/issues/82615. r? `@ehuss`,HEART,2021-02-28T18:51:45Z,camelid,NA https://github.com/rust-lang/rust/pull/82653,MERGED,2021-03-01T05:18:44Z,2021-07-21T06:06:58Z,Update all submodules that rustbuild doesn't depend on lazily,jyn514,ac575b64ed8ea2099a074e3e5bd9862a7513b1e4,8,Auto merge of #82653 - jyn514:submodules-on-demand r=Mark-Simulacrum Update all submodules that rustbuild doesn't depend on lazily This only updates the submodules the first time they're needed instead of unconditionally the first time you run x.py. Ideally this would move *all* submodules to rustbuild and not exclude some tools and backtrace. Unfortunately cargo requires all `Cargo.toml` files in the whole workspace to be present to build any crate. On my machine this takes the time for an initial submodule clone (for `x.py --help`) from 55.70 to 15.87 seconds. Helps with https://github.com/rust-lang/rust/issues/76653. Builds on https://github.com/rust-lang/rust/pull/86015 and should not be merged before (only the last commit is relevant).,HEART,2021-03-02T21:32:54Z,CDirkx,christiaan@dirkx.email https://github.com/rust-lang/rust/pull/82655,MERGED,2021-03-01T08:24:20Z,2021-03-02T08:02:19Z,Highlight identifier span instead of whole pattern span in `unused` lint,SkiFire13,d259d1d98a31b299d8c64abf5be429468329dec8,8,Rollup merge of #82655 - SkiFire13:fix-issue-81314 r=estebank Highlight identifier span instead of whole pattern span in `unused` lint Fixes #81314 This pretty much just changes the span highlighted in the lint from `pat_sp` to `ident.span`. There's however an exception which is in patterns with shorthands like `Point { y ref mut x }` where a suggestion to change just `x` would be invalid; in those cases I had to keep the pattern span. Another option would be suggesting something like `Point { y x: ref mut _x }`. I also added a new test since there weren't any test that checked the `unused` lint with optional patterns.,HEART,2021-03-02T18:10:15Z,camelid,NA https://github.com/rust-lang/rust/pull/82659,CLOSED,2021-03-01T15:42:22Z,2021-04-24T16:56:42Z,Added fetch methods to signed and unsigned integers,zesterer,NA,NA,NA,EYES,2021-03-03T11:28:33Z,voidc,NA https://github.com/rust-lang/rust/pull/82684,MERGED,2021-03-01T22:40:17Z,2021-03-08T17:51:48Z,Disable destination propagation on all mir-opt-levels,tmiasko,dd7a606804c4234015ca8bca3fa8453b9016e263,15,Rollup merge of #82684 - tmiasko:dest-prop r=jonas-schievink Disable destination propagation on all mir-opt-levels The new `// compile-flags: -Zunsound-mir-opts` are inserted without an extra newline to avoid introducing a large mir-opt diff.,HEART,2021-03-02T19:10:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/82690,MERGED,2021-03-02T01:09:30Z,2021-03-05T13:34:46Z,Update rustdoc documentation,jyn514,2a5ecb29277d1d951039803b652b5b4645250814,4,Rollup merge of #82690 - jyn514:remove-pass-docs r=Manishearth Update rustdoc documentation - Remove most of the information about passes. Passes are deprecated. - Add `--document-private-items`; it was missing before. - Update `--output-format json`; it was very outdated. - Note that `--input-format` is deprecated. - Move deprecated options to the very end. Closes https://github.com/rust-lang/rust/issues/82675. r? `@Manishearth`,HEART,2021-03-05T20:15:25Z,camelid,NA https://github.com/rust-lang/rust/pull/82695,MERGED,2021-03-02T08:45:41Z,2021-03-03T11:05:12Z,Revert non-power-of-two vector restriction,XAMPPRocky,64b76da4b6ae4418687e737ab1bc4c1e8c5848f1,10,Rollup merge of #82695 - XAMPPRocky:remove-non-power-of-two-limit r=nagisa Revert non-power-of-two vector restriction Removes the power of two restriction from rustc. As discussed in https://github.com/rust-lang/stdsimd/issues/63 r? ```@calebzulawski``` cc ```@workingjubilee``` ```@thomcc```,THUMBS_UP,2021-03-02T11:33:22Z,bjorn3,NA https://github.com/rust-lang/rust/pull/82695,MERGED,2021-03-02T08:45:41Z,2021-03-03T11:05:12Z,Revert non-power-of-two vector restriction,XAMPPRocky,64b76da4b6ae4418687e737ab1bc4c1e8c5848f1,10,Rollup merge of #82695 - XAMPPRocky:remove-non-power-of-two-limit r=nagisa Revert non-power-of-two vector restriction Removes the power of two restriction from rustc. As discussed in https://github.com/rust-lang/stdsimd/issues/63 r? ```@calebzulawski``` cc ```@workingjubilee``` ```@thomcc```,THUMBS_UP,2021-03-02T12:29:34Z,calebzulawski,NA https://github.com/rust-lang/rust/pull/82702,MERGED,2021-03-02T14:44:10Z,2021-03-04T00:23:46Z,Change error about unknown attributes to a warning,jyn514,1c77a1fa3ca574f2a40056f64d498db8efe0d8a8,5,Auto merge of #82702 - jyn514:downgrade-err r=Manishearth Change error about unknown attributes to a warning Hard errors should go through a future-compatibility phase first especially since these attributes only have no effect and don't actively cause bugs. Follow-up to https://github.com/rust-lang/rust/pull/82662. Fixes ecosystem breakage like https://github.com/rust-lang/rust-clippy/issues/6832. r? `@GuillaumeGomez`,HEART,2021-03-11T13:39:57Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82704,MERGED,2021-03-02T19:01:34Z,2021-03-03T13:46:02Z,enable atomic_min/max tests in Miri,RalfJung,939b14334dfec68d85b01b62c1be0172cee03339,2,Auto merge of #82704 - RalfJung:miri-atomic-minmax r=oli-obk enable atomic_min/max tests in Miri Thanks to `@henryboisdequin` and `@GregBowyer ` Miri now supports these intrinsics. :) Also includes the necessary Miri update.,THUMBS_UP,2021-03-02T23:07:46Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82713,MERGED,2021-03-03T00:25:51Z,2021-03-03T11:05:12Z,Update cargo,ehuss,374c90b4c6d9c0c2532b525ac4b4a8d1408e097d,1,Rollup merge of #82713 - ehuss:update-cargo r=ehuss Update cargo 12 commits in 572e201536dc2e4920346e28037b63c0f4d88b3c..c68432f1e5cbbc09833699a951b1b5b059651dff 2021-02-24 16:51:20 +0000 to 2021-03-02 18:26:29 +0000 - Don't panic when printing JSON with non-utf8 paths (rust-lang/cargo#9226) - Detect changes for JSON spec targets. (rust-lang/cargo#9223) - Fix `cargo_target_empty_cfg` test with env var. (rust-lang/cargo#9225) - Correct default cargo new edition (rust-lang/cargo#9202) - Update split-debuginfo docs around the default. (rust-lang/cargo#9224) - Minor update to registry API error messages. (rust-lang/cargo#9213) - Some minor code cleanup. (rust-lang/cargo#9214) - doc: Fix spelling worksapce->workspace (rust-lang/cargo#9212) - Update SPDX version in docs. (rust-lang/cargo#9209) - Throw error if CARGO_TARGET_DIR is an empty string (rust-lang/cargo#8939) - testsuite: Use split debuginfo on macos. (rust-lang/cargo#9207) - testsuite: Improve performance when using rustup. (rust-lang/cargo#9206),HOORAY,2021-03-05T11:36:33Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/82714,MERGED,2021-03-03T00:37:30Z,2021-03-06T02:20:50Z,Detect match arm body without braces,estebank,34b2caa79f4451ff7eede9a578295e1a48db4bf2,4,Rollup merge of #82714 - estebank:missing-braces r=oli-obk Detect match arm body without braces Fix #82524.,HEART,2021-03-03T06:57:36Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/82734,CLOSED,2021-03-03T21:43:33Z,2021-06-27T00:57:31Z,Allow loading of LLVM plugins [when dynamically built rust],wsmoses,NA,NA,NA,HEART,2021-06-05T11:14:37Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/82734,CLOSED,2021-03-03T21:43:33Z,2021-06-27T00:57:31Z,Allow loading of LLVM plugins [when dynamically built rust],wsmoses,NA,NA,NA,THUMBS_UP,2021-06-05T11:14:39Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/82739,MERGED,2021-03-04T02:42:43Z,2021-04-05T13:47:31Z,Use the beta compiler for building bootstrap tools when `download-rustc` is set,jyn514,ca9cbea27a2fc0a3f9c7d820f5bd3eeac1ad25d2,4,Rollup merge of #82739 - jyn514:separate-stage0-stage1 r=Mark-Simulacrum Use the beta compiler for building bootstrap tools when `download-rustc` is set ## Motivation This avoids having to rebuild bootstrap and tidy each time you rebase over master. In particular it makes rebasing and running `x.py fmt` on each commit in a branch significantly faster. It also avoids having to rebuild bootstrap after setting `download-rustc = true`. ## Implementation Instead of extracting the CI artifacts directly to `stage0/` extract them to `ci-rustc/` instead. Continue to copy them to the proper sysroots as necessary for all stages except stage 0. This also requires `bootstrap.py` to download both stage0 and CI artifacts and distinguish between the two when checking stamp files. Note that since tools have to be built by the same compiler that built `rustc-dev` and the standard library the downloaded artifacts can't be reused when building with the beta compiler. To make sure this is still a good user experience warn when building with the beta compiler and default to building with stage 2. I tested this by rebasing this PR from edeee915b1c52f97411e57ef6b1a8bd46548a37a over 1c77a1fa3ca574f2a40056f64d498db8efe0d8a8 and confirming that only the bootstrap library itself had to be rebuilt not any dependencies and not `tidy`. I also tested that a clean build with `x.py build` builds rustdoc exactly once and does no other work and that `touch src/librustdoc/lib.rs && x.py build` works. `x.py check` still behaves as before (checks using the beta compiler even if there are changes to `compiler/`). Helps with https://github.com/rust-lang/rust/issues/81930. r? `@Mark-Simulacrum`,HEART,2021-03-22T20:45:44Z,camelid,NA https://github.com/rust-lang/rust/pull/82751,MERGED,2021-03-04T08:56:49Z,2021-03-07T05:50:06Z,improve offset_from docs,RalfJung,05a2366e82165a20dd352a62873fab84cd8d97cd,2,"Rollup merge of #82751 - RalfJung:offset_from r=dtolnay improve offset_from docs `@thomcc` pointed out that the current docs leave it kind of unclear how one can satisfy the ""no wrapping around `isize` or the address space"" requirement of `offset_from` so make the docs clearer about that. FWIW I don't think I entirely agree with that second paragraph about large objects (that I left mostly unchanged here). LLVM to my knowledge fundamentally assumes that all allocations fit into an `isize::MAX`. So in that sense creating a larger allocation is simply UB. I would expect a guarantee that Rust heap allocation methods will never return allocations larger than `isize::MAX` (or rather Rust heap allocation methods should require that the `Layout` is no larger than `isize::MAX`). However I cannot find any such requirement documented currently. Large allocations are not mentioned at all in the allocator docs which is quite surprising -- even if we say that such allocations are not insta-UB (which I think is incompatible with LLVM) they are still extremely footgunny since `ptr::offset`/`ptr::add` do not support offsetting by more than `isize::MAX` bytes. Furthermore the allocator docs don't even say anything about allocations wrapping around the address space. But that is certainly something allocators must ensure never happens; we cannot expect clients to defend against this. Cc `@rust-lang/wg-allocators`",HOORAY,2021-03-04T08:59:22Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-04T15:13:13Z,RalfJung,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T15:20:27Z,SOF3,sofe2038@gmail.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T15:23:15Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T15:24:35Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-04T15:24:36Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T15:38:01Z,douglascaetano,douglas@douglascaetano.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-04T15:38:05Z,douglascaetano,douglas@douglascaetano.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T15:59:36Z,sollyucko,solly.ucko@gmail.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T16:05:04Z,jplatte,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T17:20:43Z,naiveai,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-04T17:20:44Z,naiveai,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-04T19:40:48Z,marmeladema,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-04T19:40:49Z,marmeladema,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-07T22:10:56Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-11T13:42:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-11T13:42:46Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-12T08:44:49Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-18T06:57:59Z,mb64,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-03-27T11:01:46Z,Elieroz,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-03-27T11:01:51Z,Elieroz,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-04-01T19:27:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-04-01T19:27:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2021-05-07T20:48:39Z,edlanglois,NA https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",HEART,2021-07-23T18:26:00Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/82764,MERGED,2021-03-04T15:10:53Z,2021-03-05T16:31:30Z,Add {BTreeMap HashMap}::try_insert,m-ou-se,232caad39581118619c5168284b15457d1c72900,5,"Rollup merge of #82764 - m-ou-se:map-try-insert r=Amanieu Add {BTreeMap HashMap}::try_insert `{BTreeMap HashMap}::insert(key new_val)` returns `Some(old_val)` if the key was already in the map. It's often useful to assert no duplicate values are inserted. We experimented with `map.insert(key val).unwrap_none()` (https://github.com/rust-lang/rust/issues/62633) but decided that that's not the kind of method we'd like to have on `Option`s. `insert` always succeeds because it replaces the old value if it exists. One could argue that `insert()` is never the right method for panicking on duplicates since already handles that case by replacing the value only allowing you to panic after that already happened. This PR adds a `try_insert` method that instead returns a `Result::Err` when the key already exists. This error contains both the `OccupiedEntry` and the value that was supposed to be inserted. This means that unwrapping that result gives more context: ```rust map.insert(10 ""world"").unwrap_none(); // thread 'main' panicked at 'called `Option::unwrap_none()` on a `Some` value: ""hello""' src/main.rs:8:29 ``` ```rust map.try_insert(10 ""world"").unwrap(); // thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: // OccupiedError { key: 10 old_value: ""hello"" new_value: ""world"" }' src/main.rs:6:33 ``` It also allows handling the failure in any other way as you have full access to the `OccupiedEntry` and the value. `try_insert` returns a reference to the value in case of success making it an alternative to `.entry(key).or_insert(value)`. r? ```@Amanieu``` Fixes https://github.com/rust-lang/rfcs/issues/3092",THUMBS_UP,2022-01-10T08:24:58Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-04T21:11:34Z,ijackson,ijackson@chiark.greenend.org.uk https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-04T23:29:06Z,marmeladema,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-05T12:53:12Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T08:15:30Z,adamreichold,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T08:47:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T10:18:59Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T10:44:40Z,eopb,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T10:54:43Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T12:35:12Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T13:40:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T14:34:35Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-11T23:48:04Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-12T00:26:28Z,arthurprs,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-13T03:36:08Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-16T03:42:55Z,pierd,jakub.jaroszewski@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-16T11:12:27Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-16T23:04:39Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-23T10:54:32Z,hoodie,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-03-25T18:33:04Z,elihunter173,NA https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-04-01T19:28:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-04-03T04:38:16Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-04-07T09:55:11Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-06-15T19:40:48Z,NickNick,nick@astrant.net https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2021-10-23T01:37:39Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/82770,MERGED,2021-03-04T17:15:39Z,2021-03-05T16:31:30Z,Add assert_matches macro.,m-ou-se,04045cc83f59e08be5d12d7ca4ac4d6364a02ff1,3,"Rollup merge of #82770 - m-ou-se:assert-match r=joshtriplett Add assert_matches macro. This adds `assert_matches!(expression pattern)`. Unlike the other asserts this one ~~consumes the expression~~ may consume the expression to be able to match the pattern. (It could add a `&` implicitly but that's noticable in the pattern and will make a consuming guard impossible.) See https://github.com/rust-lang/rust/issues/62633#issuecomment-790737853 This re-uses the same `left: .. right: ..` output as the `assert_eq` and `assert_ne` macros but with the pattern as the right part: assert_eq: ``` assertion failed: `(left == right)` left: `Some(""asdf"")` right: `None` ``` assert_matches: ``` assertion failed: `(left matches right)` left: `Ok(""asdf"")` right: `Err(_)` ``` cc ```@cuviper```",HEART,2022-01-16T00:41:55Z,weihanglo,NA https://github.com/rust-lang/rust/pull/82774,MERGED,2021-03-04T19:33:49Z,2021-03-17T11:11:32Z,Fix bad diagnostics for anon params with ref and/or qualified paths,JohnTitor,a16db3dcda83dec3e7a46f2e6028a5b8eb7cec80,4,Rollup merge of #82774 - JohnTitor:bad-diag-for-anon-params-with-ref r=estebank Fix bad diagnostics for anon params with ref and/or qualified paths Fixes #82729 It's easier to review with hiding whitespace changes.,HEART,2021-03-06T00:01:41Z,estebank,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,HOORAY,2021-03-05T03:45:11Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,CONFUSED,2021-03-05T14:19:45Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,HOORAY,2021-03-07T05:17:24Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-08T02:58:03Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,CONFUSED,2021-03-08T02:58:05Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,CONFUSED,2021-03-09T07:37:40Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,HOORAY,2021-03-10T17:48:37Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-10T17:48:37Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,ROCKET,2021-03-10T17:48:39Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,HEART,2021-03-10T17:48:43Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-10T17:51:05Z,moxian,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,ROCKET,2021-03-10T17:51:06Z,moxian,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-10T17:56:53Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-10T19:07:39Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,CONFUSED,2021-03-15T22:14:18Z,oilaba,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-20T03:09:33Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_DOWN,2021-03-21T05:07:02Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-03-27T22:18:05Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/82786,CLOSED,2021-03-05T02:34:18Z,2021-04-14T19:58:21Z,add the bool::not method.,Lokathor,NA,NA,NA,THUMBS_UP,2021-04-23T19:30:20Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/82800,MERGED,2021-03-05T15:07:19Z,2021-03-09T04:33:51Z,Move rustdoc UI tests into a subdirectory,jyn514,5ff52cbdb772e3d4c33428b2b893b8ef015b81ae,18,Rollup merge of #82800 - jyn514:group-rustdoc-tests r=Mark-Simulacrum Move rustdoc UI tests into a subdirectory Helps with https://github.com/rust-lang/rust/issues/73494.,HEART,2021-03-05T16:10:23Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/82800,MERGED,2021-03-05T15:07:19Z,2021-03-09T04:33:51Z,Move rustdoc UI tests into a subdirectory,jyn514,5ff52cbdb772e3d4c33428b2b893b8ef015b81ae,18,Rollup merge of #82800 - jyn514:group-rustdoc-tests r=Mark-Simulacrum Move rustdoc UI tests into a subdirectory Helps with https://github.com/rust-lang/rust/issues/73494.,THUMBS_UP,2021-03-08T02:33:42Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-06T15:51:54Z,lqd,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-08T03:18:42Z,torokati44,torokati44@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-08T15:42:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-08T16:44:02Z,mati865,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-09T04:37:31Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-09T05:09:34Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-09T17:11:38Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-12T11:29:53Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-12T20:45:03Z,tmandry,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-12T21:03:44Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-13T01:03:25Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,ROCKET,2021-03-13T01:03:28Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-13T06:27:51Z,yuyoyuppe,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-13T22:26:58Z,bluss,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-14T09:53:18Z,Poopooracoocoo,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-15T08:38:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,ROCKET,2021-03-15T08:38:08Z,Virgiel,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-15T10:52:17Z,queer,null@amy.gg https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-15T12:20:44Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-15T16:53:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,ROCKET,2021-03-15T16:53:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-15T17:51:49Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-16T21:31:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-16T22:23:01Z,funbringer,NA https://github.com/rust-lang/rust/pull/82806,MERGED,2021-03-05T17:17:14Z,2021-03-11T20:56:08Z,Enable MemorySSA in MemCpyOpt,nikic,4a8b6f708c38342a6c74aa00cf4323774c7381a6,1,Auto merge of #82806 - nikic:memcpyopt-mssa r=nagisa Enable MemorySSA in MemCpyOpt LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork. Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8 There are improvements on check and debug builds which indicate that rustc itself has become faster. For opt builds this is on average a very minor improvement as well although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores which are now coalesced into a memset slightly later resulting in longer compile-time for intermediate passes.,HOORAY,2021-03-23T06:11:41Z,jhdxr,jhdxr@php.net https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-06T17:42:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-06T19:08:51Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-06T19:24:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-07T14:03:32Z,oilaba,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-08T02:17:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-15T17:42:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-15T21:12:32Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-18T23:39:59Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-21T19:56:05Z,cynecx,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T02:05:29Z,crlf0710,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T08:50:15Z,lnicola,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T09:23:12Z,ThouCheese,luuk.wester@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T09:25:36Z,dfioravanti,fioravanti.diego@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T09:31:07Z,Virgiel,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T09:31:08Z,Virgiel,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T09:35:57Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T09:36:00Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T09:45:12Z,krdln,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T09:58:06Z,josephg,me@josephg.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T10:08:41Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T10:08:41Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T10:08:42Z,wusyong,wusyong9104@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T10:17:53Z,dmitr101,dmytroshynkar@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T10:29:10Z,fmckeogh,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T10:34:48Z,rrbutani,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T10:39:44Z,robinmoussu,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T11:09:02Z,discosultan,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T11:21:30Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T11:21:31Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T11:21:32Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T11:33:22Z,marioortizmanero,marioortizmanero@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T11:33:23Z,marioortizmanero,marioortizmanero@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T11:33:24Z,marioortizmanero,marioortizmanero@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T11:47:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T11:47:23Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T11:47:25Z,DianaNites,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T11:54:22Z,mjgarton,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T12:09:22Z,Chaz6,chaz@chaz6.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T12:10:38Z,flyingmutant,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T12:35:49Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T12:35:50Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T12:35:51Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T12:41:11Z,gabelluardo,gabriele.belluardo@outlook.it https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T13:00:55Z,david0u0,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T13:02:05Z,Sannholm,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T13:07:43Z,radekvit,radekvitr@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T13:54:45Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T13:59:49Z,oleg-andreyev,oleg@andreyev.lv https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T14:21:52Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T14:21:53Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T14:21:54Z,rsaihe,me@rsaihe.dev https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T14:49:57Z,KSXGitHub,hvksmr1996@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T14:49:57Z,KSXGitHub,hvksmr1996@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T14:49:58Z,KSXGitHub,hvksmr1996@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T15:00:17Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T15:00:18Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T15:00:18Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T15:06:58Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T15:11:57Z,PvdBerg1998,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T15:52:39Z,dbalabka,dmitry.balabka@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T16:05:59Z,tux3,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T16:30:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T16:33:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T16:39:24Z,bertptrs,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T16:46:39Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T16:46:40Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T16:46:40Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T16:55:55Z,yerke,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T16:55:56Z,yerke,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T16:55:57Z,yerke,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T17:11:27Z,X3n0m0rph59,x3n0m0rph59@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T17:11:28Z,X3n0m0rph59,x3n0m0rph59@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T17:11:29Z,X3n0m0rph59,x3n0m0rph59@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T17:38:39Z,Ameobea,casey@cprimozic.net https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T17:45:06Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T18:40:19Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T19:03:12Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T20:04:10Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T20:11:34Z,Yatekii,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T20:57:53Z,delbonis,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T21:10:42Z,Avarel,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T21:10:43Z,Avarel,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T21:10:47Z,Avarel,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T21:14:38Z,scullion,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T21:32:39Z,42triangles,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T21:43:27Z,redzic,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T22:15:31Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T22:47:35Z,sakex,alexandre@senges.ch https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-22T23:29:12Z,jbalintbiro,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-22T23:29:16Z,jbalintbiro,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-22T23:29:19Z,jbalintbiro,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T00:11:34Z,ttarikbnr,ttarikbnr@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T00:48:53Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T00:48:54Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T00:48:55Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T01:36:16Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T01:36:17Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T01:36:18Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T03:55:59Z,ClearedFram3,daniel.mon.johns@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T09:12:39Z,bestouff,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T10:57:02Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T10:57:03Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T12:52:06Z,lemunozm,lemunozm@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T13:02:43Z,sehraf,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T13:45:05Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T13:45:06Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T16:06:52Z,mikialex,18516340862@163.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T18:55:33Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T18:55:36Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T18:55:38Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-23T19:10:10Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-23T19:10:11Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-23T19:10:12Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-24T03:48:44Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-25T02:02:15Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-25T04:27:37Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-25T12:21:42Z,vlad20012,beskvlad@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-25T13:09:22Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-25T14:01:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-25T14:02:00Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-25T14:02:02Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HEART,2021-03-25T20:12:37Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-27T09:45:03Z,gifnksm,makoto.nksm+github@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-29T00:01:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-03-29T00:01:01Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HEART,2021-03-29T00:01:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-29T00:01:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-29T07:02:55Z,ammarfaizi2,ammarfaizi2@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-03-29T17:15:17Z,bogeholm,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-03-30T14:55:28Z,cbeuw,cbeuw.andy@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HEART,2021-04-02T23:07:18Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-04-02T23:07:20Z,HMPerson1,hmperson1+github@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-04-05T06:49:02Z,nayuki,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-04-05T06:49:03Z,nayuki,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-04-15T12:33:03Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-04-23T17:15:25Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-05-12T08:04:24Z,Sokom141,mattiapizzolitto141@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-06-21T19:34:41Z,a1phyr,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-07-23T15:38:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-07-23T19:55:05Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-07-29T17:26:31Z,Error1000,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-07-29T19:51:29Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-08-01T06:45:00Z,Wilfred,me@wilfred.me.uk https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-08-05T15:55:07Z,teymour-aldridge,teymour@reasoning.page https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-08-25T17:53:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-09-11T12:27:21Z,tatsuya6502,gh@hibaridb.org https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,THUMBS_UP,2021-09-17T15:20:52Z,bl-ue,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-09-17T15:20:52Z,bl-ue,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HEART,2021-09-17T15:20:53Z,bl-ue,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,ROCKET,2021-09-17T15:20:53Z,bl-ue,NA https://github.com/rust-lang/rust/pull/82834,MERGED,2021-03-06T11:46:22Z,2021-03-22T00:41:07Z,Enable mutable noalias for LLVM >= 12,nikic,97663b6690689379aa0493deb494dfe14627c46b,13,Auto merge of #82834 - nikic:mutable-noalias r=nagisa Enable mutable noalias for LLVM >= 12 Enable mutable noalias by default on LLVM 12 as previously known miscompiles have been resolved. Now it's time to find the next one ;) * The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior. * The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision. * `noalias` is not emitted for types that are `!Unpin` as a heuristic for self-referential structures (see #54878 and #63818).,HOORAY,2021-12-31T01:28:21Z,tjkirch,NA https://github.com/rust-lang/rust/pull/82846,MERGED,2021-03-06T21:04:42Z,2021-03-19T18:23:47Z,rustdoc: allow list syntax for #[doc(alias)] attributes,GuillaumeGomez,61372e1af6a100aedc203d0739073b42f8977e4e,7,"Rollup merge of #82846 - GuillaumeGomez:doc-alias-list r=jyn514 rustdoc: allow list syntax for #[doc(alias)] attributes Fixes https://github.com/rust-lang/rust/issues/81205. It now allows to have: ```rust #[doc(alias = ""x"")] // and: #[doc(alias(""y"" ""z""))] ``` cc ``@jplatte`` r? ``@jyn514``",THUMBS_UP,2021-03-06T21:21:30Z,jplatte,NA https://github.com/rust-lang/rust/pull/82862,MERGED,2021-03-07T15:27:04Z,2021-03-08T17:51:47Z,Generalize Write impl for Vec to Vec,athre0z,3b0a02a26b6db7a2f997cd32ca352e141ec795eb,1,Rollup merge of #82862 - athre0z:generalize-vec-write-impl r=TimDiekmann Generalize Write impl for Vec to Vec As discussed in the [issue tracker for the wg-allocators working group][1] updating this impl for allocator support was most likely just forgotten previously. This PR fixes this. r? `````@TimDiekmann````` [1]: https://github.com/rust-lang/wg-allocators/issues/86,THUMBS_UP,2021-03-07T16:32:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82862,MERGED,2021-03-07T15:27:04Z,2021-03-08T17:51:47Z,Generalize Write impl for Vec to Vec,athre0z,3b0a02a26b6db7a2f997cd32ca352e141ec795eb,1,Rollup merge of #82862 - athre0z:generalize-vec-write-impl r=TimDiekmann Generalize Write impl for Vec to Vec As discussed in the [issue tracker for the wg-allocators working group][1] updating this impl for allocator support was most likely just forgotten previously. This PR fixes this. r? `````@TimDiekmann````` [1]: https://github.com/rust-lang/wg-allocators/issues/86,THUMBS_UP,2021-03-11T13:40:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82862,MERGED,2021-03-07T15:27:04Z,2021-03-08T17:51:47Z,Generalize Write impl for Vec to Vec,athre0z,3b0a02a26b6db7a2f997cd32ca352e141ec795eb,1,Rollup merge of #82862 - athre0z:generalize-vec-write-impl r=TimDiekmann Generalize Write impl for Vec to Vec As discussed in the [issue tracker for the wg-allocators working group][1] updating this impl for allocator support was most likely just forgotten previously. This PR fixes this. r? `````@TimDiekmann````` [1]: https://github.com/rust-lang/wg-allocators/issues/86,THUMBS_UP,2021-03-16T11:13:45Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82868,MERGED,2021-03-07T18:04:08Z,2021-03-18T08:18:09Z,Report missing cases of `bare_trait_objects`,petrochenkov,2aafe452b898aa3fdfb2c5a1a649ed0922e1401d,39,Auto merge of #82868 - petrochenkov:bto r=estebank Report missing cases of `bare_trait_objects` Fixes https://github.com/rust-lang/rust/issues/65371,THUMBS_UP,2021-03-07T18:13:51Z,estebank,NA https://github.com/rust-lang/rust/pull/82873,MERGED,2021-03-07T19:04:23Z,2021-03-26T00:50:21Z,Rework rustdoc const type,GuillaumeGomez,3debe9acb8df363e0b5363f23f8218c2d7919904,11,Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty r=jyn514 Rework rustdoc const type This PR is mostly about two things: 1. Not storing some information in the `clean::Constant` type 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case). Also: I'm very curious of the perf change in here. Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :) r? `@jyn514`,HEART,2021-03-07T22:15:00Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82873,MERGED,2021-03-07T19:04:23Z,2021-03-26T00:50:21Z,Rework rustdoc const type,GuillaumeGomez,3debe9acb8df363e0b5363f23f8218c2d7919904,11,Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty r=jyn514 Rework rustdoc const type This PR is mostly about two things: 1. Not storing some information in the `clean::Constant` type 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case). Also: I'm very curious of the perf change in here. Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :) r? `@jyn514`,HEART,2021-03-09T17:19:57Z,weihanglo,NA https://github.com/rust-lang/rust/pull/82873,MERGED,2021-03-07T19:04:23Z,2021-03-26T00:50:21Z,Rework rustdoc const type,GuillaumeGomez,3debe9acb8df363e0b5363f23f8218c2d7919904,11,Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty r=jyn514 Rework rustdoc const type This PR is mostly about two things: 1. Not storing some information in the `clean::Constant` type 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case). Also: I'm very curious of the perf change in here. Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :) r? `@jyn514`,HEART,2021-03-09T20:14:05Z,fmease,NA https://github.com/rust-lang/rust/pull/82873,MERGED,2021-03-07T19:04:23Z,2021-03-26T00:50:21Z,Rework rustdoc const type,GuillaumeGomez,3debe9acb8df363e0b5363f23f8218c2d7919904,11,Auto merge of #82873 - GuillaumeGomez:rustdoc-const-ty r=jyn514 Rework rustdoc const type This PR is mostly about two things: 1. Not storing some information in the `clean::Constant` type 2. Using `TyCtxt` in the formatting (which we will need in any case as we move forward in any case). Also: I'm very curious of the perf change in here. Thanks a lot `@danielhenrymantilla` for your `Captures` idea! It allowed me to solve the lifetime issue completely. :) r? `@jyn514`,HEART,2021-03-10T02:40:48Z,camelid,NA https://github.com/rust-lang/rust/pull/82874,MERGED,2021-03-07T19:09:21Z,2021-03-09T04:33:51Z,Add codegen tests for some issues closed by LLVM 12,erikdesjardins,a5035c9995a87495267965b3a43bc2e1f66d747d,3,Rollup merge of #82874 - erikdesjardins:cgtests r=nagisa Add codegen tests for some issues closed by LLVM 12 Namely #73031 #75546 and #77812,HOORAY,2021-03-07T23:32:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82877,MERGED,2021-03-07T21:11:44Z,2021-03-09T01:47:40Z,Revert switch of env locking to rwlock to fix deadlock in process spawning,ehuss,eb476b172f12dfbbee386d027b1ad6c0bc203a9b,3,Auto merge of #82877 - ehuss:revert-rwlock r=m-ou-se Revert switch of env locking to rwlock to fix deadlock in process spawning This reverts commit 354f19cf2475148994954b6783341620c7445071 reversing changes made to 0cfba2fd090834c909d5ed9deccdee8170da791b. PR https://github.com/rust-lang/rust/pull/81850 switched the environment lock from a mutex to an rwlock. However process spawning (when not able to use `posix_spawn`) locks the environment before forking and unlocks it after forking (in both the parent and the child). With a mutex this works (although probably not correct even with a mutex). With an rwlock on at least some targets unlocking in the child does not work correctly resulting in a deadlock. This has manifested as CI hangs on i686 Linux; that target doesn't use `posix_spawn` in the CI environment due to the age of the installed C library (currently glibc 2.23). (Switching to `posix_spawn` would just mask this issue though which would still arise in any case that can't use `posix_spawn`.) Some additional cleanup of environment handling around process spawning may help but for now revert the PR and go back to a standard mutex. Fixes #82221,EYES,2021-03-07T21:59:20Z,the8472,NA https://github.com/rust-lang/rust/pull/82884,MERGED,2021-03-08T00:04:09Z,2021-03-10T16:44:08Z,Remove the -Zinsert-sideeffect,nagisa,5fe790e3c40710ecb95ddaadb98b59a3bb4f8326,11,Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts r=nikic Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0 which fixed the forward progress related miscompilations at their root.,HOORAY,2021-03-08T01:10:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82884,MERGED,2021-03-08T00:04:09Z,2021-03-10T16:44:08Z,Remove the -Zinsert-sideeffect,nagisa,5fe790e3c40710ecb95ddaadb98b59a3bb4f8326,11,Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts r=nikic Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0 which fixed the forward progress related miscompilations at their root.,HOORAY,2021-03-08T10:34:50Z,mati865,NA https://github.com/rust-lang/rust/pull/82884,MERGED,2021-03-08T00:04:09Z,2021-03-10T16:44:08Z,Remove the -Zinsert-sideeffect,nagisa,5fe790e3c40710ecb95ddaadb98b59a3bb4f8326,11,Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts r=nikic Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0 which fixed the forward progress related miscompilations at their root.,HOORAY,2021-03-09T01:35:18Z,camelid,NA https://github.com/rust-lang/rust/pull/82884,MERGED,2021-03-08T00:04:09Z,2021-03-10T16:44:08Z,Remove the -Zinsert-sideeffect,nagisa,5fe790e3c40710ecb95ddaadb98b59a3bb4f8326,11,Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts r=nikic Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0 which fixed the forward progress related miscompilations at their root.,HOORAY,2021-03-10T06:40:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82884,MERGED,2021-03-08T00:04:09Z,2021-03-10T16:44:08Z,Remove the -Zinsert-sideeffect,nagisa,5fe790e3c40710ecb95ddaadb98b59a3bb4f8326,11,Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts r=nikic Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0 which fixed the forward progress related miscompilations at their root.,HOORAY,2021-03-11T08:26:02Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82891,MERGED,2021-03-08T07:17:53Z,2021-03-13T15:11:23Z,Make def_key and HIR parenting consistent.,cjgillot,32dce353dec5f9069c941d4cd0c059ecc67b7c2b,11,Auto merge of #82891 - cjgillot:monoparent r=petrochenkov Make def_key and HIR parenting consistent. r? `@petrochenkov`,EYES,2021-03-10T06:39:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T16:36:18Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T16:37:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T16:47:59Z,ljedrz,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T16:56:05Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T17:02:10Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T21:14:34Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T21:23:49Z,Ekleog,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-11T22:48:56Z,nickmertin,nickmertin@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-12T00:09:28Z,CoffmanTaylor,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-12T04:31:13Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-12T04:31:15Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-12T13:17:20Z,ijackson,ijackson@chiark.greenend.org.uk https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-13T12:48:20Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-13T19:54:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-14T07:40:45Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-14T07:40:46Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-15T13:47:34Z,mexus,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-15T13:47:35Z,mexus,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-15T15:47:50Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-15T17:26:18Z,rrbutani,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-16T06:58:40Z,Padrition,padrition@gmail.com https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-16T06:59:02Z,MikailBag,bagishov.mikail@yandex.ru https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-03-16T08:49:09Z,denzp,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-16T08:49:10Z,denzp,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-03-19T01:38:31Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-05-06T08:12:00Z,frjnn,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,ROCKET,2021-05-06T08:12:01Z,frjnn,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,EYES,2021-05-06T08:12:04Z,frjnn,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HOORAY,2021-05-06T08:12:07Z,frjnn,NA https://github.com/rust-lang/rust/pull/82898,MERGED,2021-03-08T13:55:19Z,2021-03-16T06:54:27Z,Add a `min_type_alias_impl_trait` feature gate,oli-obk,195ad4830e11a544391abe296b146450dea8411b,362,Auto merge of #82898 - oli-obk:tait_🧊 r=nikomatsakis Add a `min_type_alias_impl_trait` feature gate This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete as they have various ways to ICE the compiler or cause query cycles where they shouldn't). r? `@nikomatsakis` This is best reviewed commit-by-commit,HEART,2021-05-26T00:48:06Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/82907,MERGED,2021-03-08T15:25:12Z,2021-04-04T22:45:55Z,resolve/expand: Cache intermediate results of `#[derive]` expansion,petrochenkov,c755ee4ce8cae6ea977d65a0288480940db721d9,5,Auto merge of #82907 - petrochenkov:dercache r=Aaron1011 resolve/expand: Cache intermediate results of `#[derive]` expansion Expansion function for `#[derive]` (`rustc_builtin_macros::derive::Expander::expand`) may return an indeterminate result and therefore can be called multiple times. Previously we parsed the `#[derive(Foo Bar)]`'s input and tried to resolve `Foo` and `Bar` on every such call. Now we maintain a cache `Resolver::derive_data` and take all the necessary data from it if it was computed previously. So `Foo Bar` is now parsed at most once and `Foo` and `Bar` are successfully resolved at most once.,HOORAY,2021-03-08T15:26:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82907,MERGED,2021-03-08T15:25:12Z,2021-04-04T22:45:55Z,resolve/expand: Cache intermediate results of `#[derive]` expansion,petrochenkov,c755ee4ce8cae6ea977d65a0288480940db721d9,5,Auto merge of #82907 - petrochenkov:dercache r=Aaron1011 resolve/expand: Cache intermediate results of `#[derive]` expansion Expansion function for `#[derive]` (`rustc_builtin_macros::derive::Expander::expand`) may return an indeterminate result and therefore can be called multiple times. Previously we parsed the `#[derive(Foo Bar)]`'s input and tried to resolve `Foo` and `Bar` on every such call. Now we maintain a cache `Resolver::derive_data` and take all the necessary data from it if it was computed previously. So `Foo Bar` is now parsed at most once and `Foo` and `Bar` are successfully resolved at most once.,HOORAY,2021-04-09T06:52:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/82907,MERGED,2021-03-08T15:25:12Z,2021-04-04T22:45:55Z,resolve/expand: Cache intermediate results of `#[derive]` expansion,petrochenkov,c755ee4ce8cae6ea977d65a0288480940db721d9,5,Auto merge of #82907 - petrochenkov:dercache r=Aaron1011 resolve/expand: Cache intermediate results of `#[derive]` expansion Expansion function for `#[derive]` (`rustc_builtin_macros::derive::Expander::expand`) may return an indeterminate result and therefore can be called multiple times. Previously we parsed the `#[derive(Foo Bar)]`'s input and tried to resolve `Foo` and `Bar` on every such call. Now we maintain a cache `Resolver::derive_data` and take all the necessary data from it if it was computed previously. So `Foo Bar` is now parsed at most once and `Foo` and `Bar` are successfully resolved at most once.,HOORAY,2021-04-13T11:33:59Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-09T08:10:46Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-09T09:03:57Z,bluss,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-09T12:54:41Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-09T12:54:48Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-09T22:37:22Z,camsteffen,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-10T02:38:39Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-10T19:09:28Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-17T23:29:17Z,estebank,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-18T23:48:47Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-19T20:54:50Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-23T10:31:13Z,jplatte,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-24T09:04:55Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_DOWN,2021-03-28T08:28:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-28T20:28:03Z,fmease,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-03-28T20:28:05Z,fmease,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-03-29T12:33:14Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-01T04:40:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-04-01T04:40:38Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-01T06:36:17Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-01T08:48:01Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-01T10:23:00Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-04-01T10:23:03Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-04-01T17:11:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-01T22:03:34Z,calebsander,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-04-02T08:25:29Z,consolero,arandes@programmers.at https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-04T02:00:28Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-04-04T16:45:57Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-04-04T16:45:57Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-07-03T21:16:11Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-07-13T00:09:59Z,tp-m,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-08-17T22:13:33Z,Aleksander-F,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-08-24T12:40:37Z,Folyd,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-09-08T05:26:13Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-09-08T05:26:15Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-10-21T21:47:39Z,shi-rudo,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-11-22T00:55:04Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,HEART,2021-11-22T01:31:07Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2021-11-23T21:18:50Z,Kestrer,NA https://github.com/rust-lang/rust/pull/82917,MERGED,2021-03-08T23:33:33Z,2021-03-27T22:19:08Z,Add function core::iter::zip,cuviper,b2e254318d4a23a07f2f7321c1a17430ba941ee9,111,Rollup merge of #82917 - cuviper:iter-zip r=m-ou-se Add function core::iter::zip This makes it a little easier to `zip` iterators: ```rust for (x y) in zip(xs ys) {} // vs. for (x y) in xs.into_iter().zip(ys) {} ``` You can `zip(&mut xs &ys)` for the conventional `iter_mut()` and `iter()` respectively. This can also support arbitrary nesting where it's easier to see the item layout than with arbitrary `zip` chains: ```rust for ((x y) z) in zip(zip(xs ys) zs) {} for (x (y z)) in zip(xs zip(ys zs)) {} // vs. for ((x y) z) in xs.into_iter().zip(ys).zip(xz) {} for (x (y z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {} ``` It may also format more nicely especially when the first iterator is a longer chain of methods -- for example: ```rust iter::zip( trait_ref.substs.types().skip(1) impl_trait_ref.substs.types().skip(1) ) // vs. trait_ref .substs .types() .skip(1) .zip(impl_trait_ref.substs.types().skip(1)) ``` This replaces the tuple-pair `IntoIterator` in #78204. There is prior art for the utility of this in [`itertools::zip`]. [`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html,THUMBS_UP,2022-02-24T18:17:22Z,sunjay,NA https://github.com/rust-lang/rust/pull/82918,MERGED,2021-03-08T23:49:06Z,2021-04-13T00:52:04Z,Turn old edition lint (anonymous-parameters) into warn-by-default on 2015,Manishearth,11d05284834b95dd39d6fdcad1e7064316800e50,14,Auto merge of #82918 - Manishearth:edition-2015-warn r=oli-obk Turn old edition lint (anonymous-parameters) into warn-by-default on 2015 This makes `anonymous_parameters` and `keyword_idents` warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate` but I feel that case is slightly less clear-cut. Note that this only affects code on the 2015 edition such code is illegal in future editions anyway. This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn) and while the tooling should be free to find its balance on how much to support prior editions it does seem like we should be nudging such code towards the newer edition and we can do that by turning this Allow lint into a Warn. In general I feel like migration lints from an old edition should be made Warn after a year or so and idiom lints for the new edition should be made Warn after a couple months. cc `@m-ou-se ` this is for stuff from the 2015-2018 migration but you might be interested.,THUMBS_UP,2021-03-21T22:30:47Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/82918,MERGED,2021-03-08T23:49:06Z,2021-04-13T00:52:04Z,Turn old edition lint (anonymous-parameters) into warn-by-default on 2015,Manishearth,11d05284834b95dd39d6fdcad1e7064316800e50,14,Auto merge of #82918 - Manishearth:edition-2015-warn r=oli-obk Turn old edition lint (anonymous-parameters) into warn-by-default on 2015 This makes `anonymous_parameters` and `keyword_idents` warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate` but I feel that case is slightly less clear-cut. Note that this only affects code on the 2015 edition such code is illegal in future editions anyway. This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn) and while the tooling should be free to find its balance on how much to support prior editions it does seem like we should be nudging such code towards the newer edition and we can do that by turning this Allow lint into a Warn. In general I feel like migration lints from an old edition should be made Warn after a year or so and idiom lints for the new edition should be made Warn after a couple months. cc `@m-ou-se ` this is for stuff from the 2015-2018 migration but you might be interested.,THUMBS_UP,2021-03-23T18:54:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82918,MERGED,2021-03-08T23:49:06Z,2021-04-13T00:52:04Z,Turn old edition lint (anonymous-parameters) into warn-by-default on 2015,Manishearth,11d05284834b95dd39d6fdcad1e7064316800e50,14,Auto merge of #82918 - Manishearth:edition-2015-warn r=oli-obk Turn old edition lint (anonymous-parameters) into warn-by-default on 2015 This makes `anonymous_parameters` and `keyword_idents` warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate` but I feel that case is slightly less clear-cut. Note that this only affects code on the 2015 edition such code is illegal in future editions anyway. This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn) and while the tooling should be free to find its balance on how much to support prior editions it does seem like we should be nudging such code towards the newer edition and we can do that by turning this Allow lint into a Warn. In general I feel like migration lints from an old edition should be made Warn after a year or so and idiom lints for the new edition should be made Warn after a couple months. cc `@m-ou-se ` this is for stuff from the 2015-2018 migration but you might be interested.,THUMBS_UP,2021-04-09T02:24:56Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/82918,MERGED,2021-03-08T23:49:06Z,2021-04-13T00:52:04Z,Turn old edition lint (anonymous-parameters) into warn-by-default on 2015,Manishearth,11d05284834b95dd39d6fdcad1e7064316800e50,14,Auto merge of #82918 - Manishearth:edition-2015-warn r=oli-obk Turn old edition lint (anonymous-parameters) into warn-by-default on 2015 This makes `anonymous_parameters` and `keyword_idents` warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate` but I feel that case is slightly less clear-cut. Note that this only affects code on the 2015 edition such code is illegal in future editions anyway. This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn) and while the tooling should be free to find its balance on how much to support prior editions it does seem like we should be nudging such code towards the newer edition and we can do that by turning this Allow lint into a Warn. In general I feel like migration lints from an old edition should be made Warn after a year or so and idiom lints for the new edition should be made Warn after a couple months. cc `@m-ou-se ` this is for stuff from the 2015-2018 migration but you might be interested.,THUMBS_UP,2021-04-10T07:41:51Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82918,MERGED,2021-03-08T23:49:06Z,2021-04-13T00:52:04Z,Turn old edition lint (anonymous-parameters) into warn-by-default on 2015,Manishearth,11d05284834b95dd39d6fdcad1e7064316800e50,14,Auto merge of #82918 - Manishearth:edition-2015-warn r=oli-obk Turn old edition lint (anonymous-parameters) into warn-by-default on 2015 This makes `anonymous_parameters` and `keyword_idents` warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate` but I feel that case is slightly less clear-cut. Note that this only affects code on the 2015 edition such code is illegal in future editions anyway. This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn) and while the tooling should be free to find its balance on how much to support prior editions it does seem like we should be nudging such code towards the newer edition and we can do that by turning this Allow lint into a Warn. In general I feel like migration lints from an old edition should be made Warn after a year or so and idiom lints for the new edition should be made Warn after a couple months. cc `@m-ou-se ` this is for stuff from the 2015-2018 migration but you might be interested.,THUMBS_UP,2021-04-13T02:14:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-09T00:30:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-09T15:25:20Z,r00ster91,NA https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-20T06:39:33Z,taiki-e,NA https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-25T02:54:24Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-25T06:30:48Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,HEART,2021-03-25T06:30:50Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,ROCKET,2021-03-25T06:30:52Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,THUMBS_UP,2021-03-29T00:01:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,HEART,2021-03-29T00:01:59Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82919,MERGED,2021-03-08T23:50:59Z,2021-03-20T09:01:34Z,Stabilize `assoc_char_funcs` and `assoc_char_consts`,bstrie,eb9ec311686b6b6d8f8fea6c86468d7ce6fa3d38,2,Auto merge of #82919 - bstrie:stabchar r=dtolnay Stabilize `assoc_char_funcs` and `assoc_char_consts` Stabilizes the following associated items on `char`: * [`char::MAX`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.MAX) * [`char::REPLACEMENT_CHARACTER`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.REPLACEMENT_CHARACTER) * [`char::UNICODE_VERSION`](https://doc.rust-lang.org/std/primitive.char.html#associatedconstant.UNICODE_VERSION) * [`char::decode_utf16`](https://doc.rust-lang.org/std/primitive.char.html#method.decode_utf16) * [`char::from_u32`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32) * [`char::from_u32_unchecked`](https://doc.rust-lang.org/std/primitive.char.html#method.from_u32_unchecked) * [`char::from_digit`](https://doc.rust-lang.org/std/primitive.char.html#method.from_digit) Closes #71763.,ROCKET,2021-03-29T00:02:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/82936,MERGED,2021-03-09T15:23:00Z,2021-03-17T01:38:58Z,Implement (but don't use) valtree and refactor in preparation of use,oli-obk,e655fb62216b6ba64a094b30f116d7988d19322d,56,Auto merge of #82936 - oli-obk:valtree r=RalfJung lcnr matthewjasper Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const` and it is totally possible to have two different representations for the same value),HOORAY,2021-03-09T15:24:46Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/82936,MERGED,2021-03-09T15:23:00Z,2021-03-17T01:38:58Z,Implement (but don't use) valtree and refactor in preparation of use,oli-obk,e655fb62216b6ba64a094b30f116d7988d19322d,56,Auto merge of #82936 - oli-obk:valtree r=RalfJung lcnr matthewjasper Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const` and it is totally possible to have two different representations for the same value),HEART,2021-03-09T15:56:07Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/82936,MERGED,2021-03-09T15:23:00Z,2021-03-17T01:38:58Z,Implement (but don't use) valtree and refactor in preparation of use,oli-obk,e655fb62216b6ba64a094b30f116d7988d19322d,56,Auto merge of #82936 - oli-obk:valtree r=RalfJung lcnr matthewjasper Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const` and it is totally possible to have two different representations for the same value),HOORAY,2021-03-09T20:23:09Z,camelid,NA https://github.com/rust-lang/rust/pull/82936,MERGED,2021-03-09T15:23:00Z,2021-03-17T01:38:58Z,Implement (but don't use) valtree and refactor in preparation of use,oli-obk,e655fb62216b6ba64a094b30f116d7988d19322d,56,Auto merge of #82936 - oli-obk:valtree r=RalfJung lcnr matthewjasper Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const` and it is totally possible to have two different representations for the same value),HOORAY,2021-03-15T16:52:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/82936,MERGED,2021-03-09T15:23:00Z,2021-03-17T01:38:58Z,Implement (but don't use) valtree and refactor in preparation of use,oli-obk,e655fb62216b6ba64a094b30f116d7988d19322d,56,Auto merge of #82936 - oli-obk:valtree r=RalfJung lcnr matthewjasper Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const` and it is totally possible to have two different representations for the same value),HOORAY,2021-03-17T10:20:46Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/82938,MERGED,2021-03-09T16:47:08Z,2021-03-10T04:06:50Z,Bump tracing-tree dependency,oli-obk,56b5393cc2cc0ac5769b00dbccbd34dc9202dd67,3,Rollup merge of #82938 - oli-obk:tracing_tree_bump r=Mark-Simulacrum Bump tracing-tree dependency This bump fixes two small rendering things that were annoying me: * The first level didn't have an opening line * When wraparound happens there was no warning the levels just disappeared. Now there is a line that shows that wraparound is happening See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes,HEART,2021-03-09T20:15:03Z,camelid,NA https://github.com/rust-lang/rust/pull/82949,MERGED,2021-03-09T20:49:19Z,2021-03-10T21:53:56Z,Do not attempt to unlock envlock in child process after a fork.,the8472,d01648b60e74ae12e990b0858e68023504b9bd29,3,Rollup merge of #82949 - the8472:forget-envlock-on-fork r=joshtriplett Do not attempt to unlock envlock in child process after a fork. This implements the first two points from https://github.com/rust-lang/rust/issues/64718#issuecomment-793030479 This is a breaking change for cases where the environment is accessed in a Command::pre_exec closure. Except for single-threaded programs these uses were not correct anyway since they aren't async-signal safe. Note that we had a ui test that explicitly tried `env::set_var` in `pre_exec`. As expected it failed with these changes when I tested locally.,THUMBS_UP,2021-03-10T01:51:54Z,ehuss,NA https://github.com/rust-lang/rust/pull/82958,MERGED,2021-03-10T03:39:44Z,2021-04-08T05:08:10Z,Document `Res` and its friends,camelid,0bbf473151d99e28dd0eb13cdb97a1b0fa6d9a4c,1,Auto merge of #82958 - camelid:res-docs r=petrochenkov Document `Res` and its friends I noticed [this Zulip conversation][z] and thought it would be a good idea to document `Res` and the other types near it. [z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2382516.20-.20Add.20inherent.20associated.20types/near/227914819,HEART,2021-03-10T15:41:04Z,camsteffen,NA https://github.com/rust-lang/rust/pull/82958,MERGED,2021-03-10T03:39:44Z,2021-04-08T05:08:10Z,Document `Res` and its friends,camelid,0bbf473151d99e28dd0eb13cdb97a1b0fa6d9a4c,1,Auto merge of #82958 - camelid:res-docs r=petrochenkov Document `Res` and its friends I noticed [this Zulip conversation][z] and thought it would be a good idea to document `Res` and the other types near it. [z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2382516.20-.20Add.20inherent.20associated.20types/near/227914819,HEART,2021-03-17T22:35:07Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/82962,MERGED,2021-03-10T04:15:47Z,2021-03-10T21:53:55Z,Treat header as first paragraph for shortened markdown descriptions,notriddle,5c62a182a131b16802da9575575c218c712d878d,3,"Rollup merge of #82962 - notriddle:cleanup-index r=jyn514 Treat header as first paragraph for shortened markdown descriptions ""The Rust Standard LibraryThe Rust Standard Library is the …"" is an awful description.",THUMBS_UP,2021-03-10T06:35:49Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/82977,MERGED,2021-03-10T15:08:41Z,2021-03-10T21:53:55Z,Rename `Option::get_or_default` to `get_or_insert_default`,camsteffen,e58313248a413a7119c1737a9bb21db7910f89e4,3,Rollup merge of #82977 - camsteffen:opt-get-insert-def r=m-ou-se Rename `Option::get_or_default` to `get_or_insert_default` ...as [suggested](https://github.com/rust-lang/rust/issues/82901#issuecomment-793548515) by `@m-ou-se.` In hindsight this seems rather obvious at least to me. r? `@joshtriplett`,THUMBS_UP,2021-03-13T22:37:23Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/82980,MERGED,2021-03-10T15:55:49Z,2021-03-26T14:39:05Z,Import small cold functions,tmiasko,e423058751a2b098d3e469a8e6df1b7a8bbd67b6,1,Auto merge of #82980 - tmiasko:import-cold-multiplier r=michaelwoerister Import small cold functions The Rust code is often written under an assumption that for generic methods inline attribute is mostly unnecessary since for optimized builds using ThinLTO a method will be code generated in at least one CGU and available for import. For example deref implementations for Box Vec MutexGuard and MutexGuard are not currently marked as inline neither is identity implementation of From trait. In PGO builds when functions are determined to be cold the default multiplier of zero will stop the import no matter how trivial the implementation. Increase slightly the default multiplier from 0 to 0.1. r? `@ghost`,THUMBS_UP,2021-03-16T09:51:21Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/82989,MERGED,2021-03-10T21:35:45Z,2021-03-15T18:06:00Z,Custom error on literal names from other languages,Smittyvb,4eca4929ec77b34a274a3090310247a1ec485953,3,Rollup merge of #82989 - Smittyvb:other-lang-literal-errors r=varkor Custom error on literal names from other languages This detects all Java literal types and all single word C data types and suggests the corresponding Rust literal type.,THUMBS_UP,2021-03-11T18:59:03Z,slightlyoutofphase,slightlyoutofphase@gmail.com https://github.com/rust-lang/rust/pull/82989,MERGED,2021-03-10T21:35:45Z,2021-03-15T18:06:00Z,Custom error on literal names from other languages,Smittyvb,4eca4929ec77b34a274a3090310247a1ec485953,3,Rollup merge of #82989 - Smittyvb:other-lang-literal-errors r=varkor Custom error on literal names from other languages This detects all Java literal types and all single word C data types and suggests the corresponding Rust literal type.,THUMBS_UP,2021-03-12T20:20:40Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/83001,MERGED,2021-03-11T02:28:45Z,2021-03-12T03:03:53Z,Ignore Vim swap files,camelid,3e6e808aa69001eeb4b65cfeff165832616a7355,1,Rollup merge of #83001 - camelid:gitignore-vim-swap r=Mark-Simulacrum Ignore Vim swap files I got this from [a Stack Overflow answer][so]. (I didn't add `*~` because it was already there.) [so]: https://stackoverflow.com/a/4824199,HEART,2021-03-11T07:44:06Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/83013,MERGED,2021-03-11T10:37:21Z,2021-03-12T03:03:53Z,Adjust some `#[cfg]`s to take non-Unix non-Windows operating systems into account,NA,NA,NA,NA,HOORAY,2021-04-18T07:12:36Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83020,MERGED,2021-03-11T15:44:16Z,2021-03-13T04:38:34Z,Emit the enum range assumption if the range only contains one element,hi-rustin,04e24ae67e48025469601a32c3adf8c7c93ee742,2,Rollup merge of #83020 - hi-rustin:rustin-patch-enum r=lcnr Emit the enum range assumption if the range only contains one element close https://github.com/rust-lang/rust/issues/82871,THUMBS_UP,2021-03-11T15:47:47Z,bugadani,NA https://github.com/rust-lang/rust/pull/83022,MERGED,2021-03-11T18:06:47Z,2021-03-13T02:08:41Z,Don't implement mem::replace with mem::swap.,m-ou-se,46a934a1dc789b9441e5fb5cd043287baddcc5c7,1,Auto merge of #83022 - m-ou-se:mem-replace-no-swap r=nagisa Don't implement mem::replace with mem::swap. `swap` is a complicated operation so this changes the implementation of `replace` to use `read` and `write` instead. See https://github.com/rust-lang/rust/pull/83019. I wrote there: > Implementing the simpler operation (replace) with the much more complicated operation (swap) doesn't make a whole lot of sense. `replace` is just read+write and the primitive for moving out of a `&mut`. `swap` is for doing that to *two* `&mut` at the same time which is both more niche and more complicated (as shown by `swap_nonoverlapping_bytes`). This could be especially interesting for `Option::take()` since swapping such a large structure with `swap_nonoverlapping_bytes` is going to be much less efficient than `ptr::write()`'ing a `None`. But also for small values where `swap` just reads/writes using temporary variable this makes a `replace` or `take` operation simpler: ![image](https://user-images.githubusercontent.com/783247/110839393-c7e6bd80-82a3-11eb-97b7-28acb14deffd.png),HEART,2021-04-06T16:52:09Z,bluss,NA https://github.com/rust-lang/rust/pull/83022,MERGED,2021-03-11T18:06:47Z,2021-03-13T02:08:41Z,Don't implement mem::replace with mem::swap.,m-ou-se,46a934a1dc789b9441e5fb5cd043287baddcc5c7,1,Auto merge of #83022 - m-ou-se:mem-replace-no-swap r=nagisa Don't implement mem::replace with mem::swap. `swap` is a complicated operation so this changes the implementation of `replace` to use `read` and `write` instead. See https://github.com/rust-lang/rust/pull/83019. I wrote there: > Implementing the simpler operation (replace) with the much more complicated operation (swap) doesn't make a whole lot of sense. `replace` is just read+write and the primitive for moving out of a `&mut`. `swap` is for doing that to *two* `&mut` at the same time which is both more niche and more complicated (as shown by `swap_nonoverlapping_bytes`). This could be especially interesting for `Option::take()` since swapping such a large structure with `swap_nonoverlapping_bytes` is going to be much less efficient than `ptr::write()`'ing a `None`. But also for small values where `swap` just reads/writes using temporary variable this makes a `replace` or `take` operation simpler: ![image](https://user-images.githubusercontent.com/783247/110839393-c7e6bd80-82a3-11eb-97b7-28acb14deffd.png),THUMBS_UP,2021-04-16T00:59:30Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83022,MERGED,2021-03-11T18:06:47Z,2021-03-13T02:08:41Z,Don't implement mem::replace with mem::swap.,m-ou-se,46a934a1dc789b9441e5fb5cd043287baddcc5c7,1,Auto merge of #83022 - m-ou-se:mem-replace-no-swap r=nagisa Don't implement mem::replace with mem::swap. `swap` is a complicated operation so this changes the implementation of `replace` to use `read` and `write` instead. See https://github.com/rust-lang/rust/pull/83019. I wrote there: > Implementing the simpler operation (replace) with the much more complicated operation (swap) doesn't make a whole lot of sense. `replace` is just read+write and the primitive for moving out of a `&mut`. `swap` is for doing that to *two* `&mut` at the same time which is both more niche and more complicated (as shown by `swap_nonoverlapping_bytes`). This could be especially interesting for `Option::take()` since swapping such a large structure with `swap_nonoverlapping_bytes` is going to be much less efficient than `ptr::write()`'ing a `None`. But also for small values where `swap` just reads/writes using temporary variable this makes a `replace` or `take` operation simpler: ![image](https://user-images.githubusercontent.com/783247/110839393-c7e6bd80-82a3-11eb-97b7-28acb14deffd.png),HEART,2021-04-21T16:29:34Z,jordens,rj@quartiq.de https://github.com/rust-lang/rust/pull/83022,MERGED,2021-03-11T18:06:47Z,2021-03-13T02:08:41Z,Don't implement mem::replace with mem::swap.,m-ou-se,46a934a1dc789b9441e5fb5cd043287baddcc5c7,1,Auto merge of #83022 - m-ou-se:mem-replace-no-swap r=nagisa Don't implement mem::replace with mem::swap. `swap` is a complicated operation so this changes the implementation of `replace` to use `read` and `write` instead. See https://github.com/rust-lang/rust/pull/83019. I wrote there: > Implementing the simpler operation (replace) with the much more complicated operation (swap) doesn't make a whole lot of sense. `replace` is just read+write and the primitive for moving out of a `&mut`. `swap` is for doing that to *two* `&mut` at the same time which is both more niche and more complicated (as shown by `swap_nonoverlapping_bytes`). This could be especially interesting for `Option::take()` since swapping such a large structure with `swap_nonoverlapping_bytes` is going to be much less efficient than `ptr::write()`'ing a `None`. But also for small values where `swap` just reads/writes using temporary variable this makes a `replace` or `take` operation simpler: ![image](https://user-images.githubusercontent.com/783247/110839393-c7e6bd80-82a3-11eb-97b7-28acb14deffd.png),HEART,2021-04-22T02:46:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/83036,CLOSED,2021-03-11T22:44:35Z,2021-03-17T07:07:00Z,Read incremental files on-demand,cjgillot,NA,NA,NA,HEART,2021-03-12T01:10:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83041,MERGED,2021-03-11T23:22:10Z,2021-03-25T05:07:38Z,stabilize debug_non_exhaustive,guswynn,a6ababb162348e290be52883f43e48bfba5ef9e4,2,Rollup merge of #83041 - guswynn:stable_debug_struct r=m-ou-se stabilize debug_non_exhaustive tracking issue: https://github.com/rust-lang/rust/issues/67364 but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate as this one seems uncontroversial enough to stabilize as is,HOORAY,2021-03-12T14:12:44Z,jder,me@jesserusak.com https://github.com/rust-lang/rust/pull/83041,MERGED,2021-03-11T23:22:10Z,2021-03-25T05:07:38Z,stabilize debug_non_exhaustive,guswynn,a6ababb162348e290be52883f43e48bfba5ef9e4,2,Rollup merge of #83041 - guswynn:stable_debug_struct r=m-ou-se stabilize debug_non_exhaustive tracking issue: https://github.com/rust-lang/rust/issues/67364 but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate as this one seems uncontroversial enough to stabilize as is,HOORAY,2021-03-16T21:35:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83041,MERGED,2021-03-11T23:22:10Z,2021-03-25T05:07:38Z,stabilize debug_non_exhaustive,guswynn,a6ababb162348e290be52883f43e48bfba5ef9e4,2,Rollup merge of #83041 - guswynn:stable_debug_struct r=m-ou-se stabilize debug_non_exhaustive tracking issue: https://github.com/rust-lang/rust/issues/67364 but it is still an open question whether the other `Debug*` struct's should have a similar method. I would guess that would best be put underneath a new feature gate as this one seems uncontroversial enough to stabilize as is,THUMBS_UP,2021-04-03T01:34:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83051,MERGED,2021-03-12T13:27:24Z,2021-03-24T04:13:28Z,Sidebar trait items order,GuillaumeGomez,f134ca3864f8c66d6dd01e576ce9b0125eb58210,3,Rollup merge of #83051 - GuillaumeGomez:sidebar-trait-items-order r=CraftSpider jyn514 Sidebar trait items order We were actually sorting `Symbol` and not `String` creating a completely invalid sort result. I added a test to prevent regressions. r? ``@jyn514``,THUMBS_UP,2021-03-12T15:24:40Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/83051,MERGED,2021-03-12T13:27:24Z,2021-03-24T04:13:28Z,Sidebar trait items order,GuillaumeGomez,f134ca3864f8c66d6dd01e576ce9b0125eb58210,3,Rollup merge of #83051 - GuillaumeGomez:sidebar-trait-items-order r=CraftSpider jyn514 Sidebar trait items order We were actually sorting `Symbol` and not `String` creating a completely invalid sort result. I added a test to prevent regressions. r? ``@jyn514``,THUMBS_UP,2021-04-01T06:52:00Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/83065,MERGED,2021-03-12T23:44:20Z,2021-04-02T22:47:21Z,Rework `std::sys::windows::alloc`,CDirkx,48ebad58b2d1c07769d8bcaae076f760151fefd5,3,Rollup merge of #83065 - CDirkx:win-alloc r=dtolnay Rework `std::sys::windows::alloc` I came across https://github.com/rust-lang/rust/pull/76676#discussion_r488729990 which points out that there was unsound code in the Windows alloc code creating a &mut to possibly uninitialized memory. I reworked the code so that that particular issue does not occur anymore and started adding more documentation and safety comments. Full list of changes: - moved and documented the relevant Windows Heap API functions - refactor `allocate_with_flags` to `allocate` (and remove the other helper functions) which now takes just a `bool` if the memory should be zeroed - add checks for if `GetProcessHeap` returned null - add a test that checks if the size and alignment of a `Header` are indeed <= `MIN_ALIGN` - add `#![deny(unsafe_op_in_unsafe_fn)]` and the necessary unsafe blocks with safety comments I feel like I may have overdone the documenting the unsoundness fix is the most important part; I could spit this PR up in separate parts.,THUMBS_UP,2021-06-15T17:28:34Z,Lokathor,NA https://github.com/rust-lang/rust/pull/83080,MERGED,2021-03-13T11:47:13Z,2021-03-18T02:32:32Z,Make source-based code coverage compatible with MIR inlining,tmiasko,b688b694d083b94ed19c8c93fb321a52ca98d4d9,25,Rollup merge of #83080 - tmiasko:inline-coverage r=wesleywiser Make source-based code coverage compatible with MIR inlining When codegenning code coverage use the instance that coverage data was originally generated for to ensure basic level of compatibility with MIR inlining. Fixes #83061,HOORAY,2021-03-19T01:06:38Z,tmandry,NA https://github.com/rust-lang/rust/pull/83084,MERGED,2021-03-13T14:12:09Z,2021-03-17T08:27:28Z,Adjust `-Ctarget-cpu=native` handling in cg_llvm,nagisa,0c341226ad3780c11b1f29f6da8172b1d653f9ef,7,Auto merge of #83084 - nagisa:nagisa/features-native r=petrochenkov Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native` for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines. cc https://github.com/rust-lang/rust/issues/83027 `@BurntSushi`,HEART,2021-03-14T02:41:38Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/83084,MERGED,2021-03-13T14:12:09Z,2021-03-17T08:27:28Z,Adjust `-Ctarget-cpu=native` handling in cg_llvm,nagisa,0c341226ad3780c11b1f29f6da8172b1d653f9ef,7,Auto merge of #83084 - nagisa:nagisa/features-native r=petrochenkov Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native` for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines. cc https://github.com/rust-lang/rust/issues/83027 `@BurntSushi`,HEART,2022-01-14T12:24:31Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/83088,CLOSED,2021-03-13T17:15:41Z,2021-05-03T10:39:41Z,WIP: ~15% Faster str to int parsing (when base 10),gilescope,NA,NA,NA,EYES,2021-03-22T15:56:30Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83088,CLOSED,2021-03-13T17:15:41Z,2021-05-03T10:39:41Z,WIP: ~15% Faster str to int parsing (when base 10),gilescope,NA,NA,NA,EYES,2021-03-23T11:26:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/83088,CLOSED,2021-03-13T17:15:41Z,2021-05-03T10:39:41Z,WIP: ~15% Faster str to int parsing (when base 10),gilescope,NA,NA,NA,EYES,2021-04-28T09:10:03Z,andriyor,andriyorehov@gmail.com https://github.com/rust-lang/rust/pull/83088,CLOSED,2021-03-13T17:15:41Z,2021-05-03T10:39:41Z,WIP: ~15% Faster str to int parsing (when base 10),gilescope,NA,NA,NA,EYES,2022-04-12T09:31:30Z,eopb,NA https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2021-03-23T22:05:42Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2021-08-12T22:19:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2021-08-27T16:16:15Z,DianaNites,NA https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2021-10-19T22:06:43Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2021-10-22T02:50:46Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83093,MERGED,2021-03-13T20:10:46Z,2021-08-20T21:47:36Z,where available use AtomicU{64 128} instead of mutex for Instant backsliding protection,the8472,a0035916e01d8e644ccd44554c57f0874cef8c8c,3,Auto merge of #83093 - the8472:smaller-instant-hammer r=Amanieu where available use AtomicU{64 128} instead of mutex for Instant backsliding protection This decreases the overhead of backsliding protection on x86 systems with unreliable TSC e.g. windows. And on aarch64 systems where 128bit atomics are available. The following benchmarks were taken on x86_64 linux though by overriding `actually_monotonic()` the numbers may look different on other platforms ``` # actually_monotonic() == true test time::tests::instant_contention_01_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_04_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_08_threads ... bench: 44 ns/iter (+/- 0) test time::tests::instant_contention_16_threads ... bench: 44 ns/iter (+/- 0) # 1x AtomicU64 test time::tests::instant_contention_01_threads ... bench: 65 ns/iter (+/- 0) test time::tests::instant_contention_02_threads ... bench: 157 ns/iter (+/- 20) test time::tests::instant_contention_04_threads ... bench: 281 ns/iter (+/- 53) test time::tests::instant_contention_08_threads ... bench: 555 ns/iter (+/- 77) test time::tests::instant_contention_16_threads ... bench: 883 ns/iter (+/- 107) # mutex test time::tests::instant_contention_01_threads ... bench: 60 ns/iter (+/- 2) test time::tests::instant_contention_02_threads ... bench: 770 ns/iter (+/- 231) test time::tests::instant_contention_04_threads ... bench: 1 347 ns/iter (+/- 45) test time::tests::instant_contention_08_threads ... bench: 2 693 ns/iter (+/- 114) test time::tests::instant_contention_16_threads ... bench: 5 244 ns/iter (+/- 487) ``` Since I don't have an arm machine with 128bit atomics I wasn't able to benchmark the AtomicU128 implementation.,THUMBS_UP,2022-04-07T14:45:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83128,CLOSED,2021-03-14T21:47:53Z,2021-03-15T16:27:56Z,Make `extern_mod_stmt_cnum` into a regular function,Aaron1011,NA,NA,NA,HEART,2021-03-14T21:48:56Z,est31,NA https://github.com/rust-lang/rust/pull/83129,MERGED,2021-03-14T21:53:14Z,2021-05-13T13:30:50Z,Introduce the beginning of a THIR unsafety checker,LeSeulArtichaut,17b60b8738735d8d64d03601d1dad4001d1e5733,60,"Auto merge of #83129 - LeSeulArtichaut:thir-unsafeck r=nikomatsakis Introduce the beginning of a THIR unsafety checker This poses the foundations for the THIR unsafety checker so that it can be implemented incrementally: - implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future) - introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck - implements detection of unsafe functions - adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck This uses a very simple query design where bodies are unsafety-checked on a body per body basis. This however has some big flaws: - the unsafety-checker builds the THIR itself which means a lot of work is duplicated with MIR building constructing its own copy of the THIR - unsafety-checking closures is currently completely wrong: closures should take into account the ""safety context"" in which they are created here we are considering that closures are always a safe context I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound). r? `@nikomatsakis` cc https://github.com/rust-lang/project-thir-unsafeck/issues/3 https://github.com/rust-lang/project-thir-unsafeck/issues/7",HOORAY,2021-03-14T22:54:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83129,MERGED,2021-03-14T21:53:14Z,2021-05-13T13:30:50Z,Introduce the beginning of a THIR unsafety checker,LeSeulArtichaut,17b60b8738735d8d64d03601d1dad4001d1e5733,60,"Auto merge of #83129 - LeSeulArtichaut:thir-unsafeck r=nikomatsakis Introduce the beginning of a THIR unsafety checker This poses the foundations for the THIR unsafety checker so that it can be implemented incrementally: - implements a rudimentary `Visitor` for the THIR (which will definitely need some tweaking in the future) - introduces a new `-Zthir-unsafeck` flag which tells the compiler to use THIR unsafeck instead of MIR unsafeck - implements detection of unsafe functions - adds revisions to the UI tests to test THIR unsafeck alongside MIR unsafeck This uses a very simple query design where bodies are unsafety-checked on a body per body basis. This however has some big flaws: - the unsafety-checker builds the THIR itself which means a lot of work is duplicated with MIR building constructing its own copy of the THIR - unsafety-checking closures is currently completely wrong: closures should take into account the ""safety context"" in which they are created here we are considering that closures are always a safe context I had intended to fix these problems in follow-up PRs since they are always gated under the `-Zthir-unsafeck` flag (which is explicitely noted to be unsound). r? `@nikomatsakis` cc https://github.com/rust-lang/project-thir-unsafeck/issues/3 https://github.com/rust-lang/project-thir-unsafeck/issues/7",HOORAY,2021-03-14T23:54:31Z,camelid,NA https://github.com/rust-lang/rust/pull/83130,MERGED,2021-03-14T22:05:58Z,2021-03-30T03:41:17Z,escape_ascii take 2,clarfonthey,68964d1fc24888b04be492c3f3ba0dae7d6219da,3,Rollup merge of #83130 - clarfonthey:escape r=m-ou-se escape_ascii take 2 The previous PR #73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? ``@m-ou-se``,HEART,2021-03-14T23:54:23Z,camelid,NA https://github.com/rust-lang/rust/pull/83142,CLOSED,2021-03-15T12:01:28Z,2021-06-24T14:40:55Z,Introduce `TyInterner`,zaharidichev,NA,NA,NA,HEART,2021-03-16T20:06:33Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/83142,CLOSED,2021-03-15T12:01:28Z,2021-06-24T14:40:55Z,Introduce `TyInterner`,zaharidichev,NA,NA,NA,HEART,2021-03-16T20:14:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83144,MERGED,2021-03-15T12:28:57Z,2021-03-15T18:06:00Z,Introduce `rustc_interface::interface::Config::parse_sess_created` callback,NA,NA,NA,NA,HEART,2021-03-15T18:31:25Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/83152,MERGED,2021-03-15T16:18:35Z,2021-04-05T23:40:22Z,Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled.,guswynn,d32238532138485c80db4f2cd596372bce214e00,7,Auto merge of #83152 - guswynn:jemallocator_part2 r=Mark-Simulacrum Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled. In https://github.com/rust-lang/rust/pull/81782 it was mentioned that one reason rustc may benefit from minimalloc is it doesn't use the `sdallocx` api from jemalloc. Currently on unix rust uses jemalloc by importing its symbols to use them with the default System (libc) global allocator. This PR switches its global alloc to `tikv-jemallocator` which correctly uses sized deallocation (https://docs.rs/tikv-jemallocator/0.4.1/src/tikv_jemallocator/lib.rs.html#121-126). `tikv-jemallocator` as far as I can tell is a more up-to-date set of bindings to jemalloc than `jemallocator` The perf results of this pr are in large part due to the version upgrade of jemalloc but sized deallocation has a non-trivial improvement particularly to rustdoc. This pr also includes changes to bootstrap to correctly pass the jemalloc feature through to the rustdoc build,THUMBS_UP,2021-03-19T12:19:04Z,tennix,NA https://github.com/rust-lang/rust/pull/83152,MERGED,2021-03-15T16:18:35Z,2021-04-05T23:40:22Z,Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled.,guswynn,d32238532138485c80db4f2cd596372bce214e00,7,Auto merge of #83152 - guswynn:jemallocator_part2 r=Mark-Simulacrum Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled. In https://github.com/rust-lang/rust/pull/81782 it was mentioned that one reason rustc may benefit from minimalloc is it doesn't use the `sdallocx` api from jemalloc. Currently on unix rust uses jemalloc by importing its symbols to use them with the default System (libc) global allocator. This PR switches its global alloc to `tikv-jemallocator` which correctly uses sized deallocation (https://docs.rs/tikv-jemallocator/0.4.1/src/tikv_jemallocator/lib.rs.html#121-126). `tikv-jemallocator` as far as I can tell is a more up-to-date set of bindings to jemalloc than `jemallocator` The perf results of this pr are in large part due to the version upgrade of jemalloc but sized deallocation has a non-trivial improvement particularly to rustdoc. This pr also includes changes to bootstrap to correctly pass the jemalloc feature through to the rustdoc build,HEART,2021-04-06T17:21:47Z,camelid,NA https://github.com/rust-lang/rust/pull/83152,MERGED,2021-03-15T16:18:35Z,2021-04-05T23:40:22Z,Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled.,guswynn,d32238532138485c80db4f2cd596372bce214e00,7,Auto merge of #83152 - guswynn:jemallocator_part2 r=Mark-Simulacrum Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled. In https://github.com/rust-lang/rust/pull/81782 it was mentioned that one reason rustc may benefit from minimalloc is it doesn't use the `sdallocx` api from jemalloc. Currently on unix rust uses jemalloc by importing its symbols to use them with the default System (libc) global allocator. This PR switches its global alloc to `tikv-jemallocator` which correctly uses sized deallocation (https://docs.rs/tikv-jemallocator/0.4.1/src/tikv_jemallocator/lib.rs.html#121-126). `tikv-jemallocator` as far as I can tell is a more up-to-date set of bindings to jemalloc than `jemallocator` The perf results of this pr are in large part due to the version upgrade of jemalloc but sized deallocation has a non-trivial improvement particularly to rustdoc. This pr also includes changes to bootstrap to correctly pass the jemalloc feature through to the rustdoc build,THUMBS_UP,2021-04-26T08:07:23Z,JmPotato,github@ipotato.me https://github.com/rust-lang/rust/pull/83152,MERGED,2021-03-15T16:18:35Z,2021-04-05T23:40:22Z,Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled.,guswynn,d32238532138485c80db4f2cd596372bce214e00,7,Auto merge of #83152 - guswynn:jemallocator_part2 r=Mark-Simulacrum Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled. In https://github.com/rust-lang/rust/pull/81782 it was mentioned that one reason rustc may benefit from minimalloc is it doesn't use the `sdallocx` api from jemalloc. Currently on unix rust uses jemalloc by importing its symbols to use them with the default System (libc) global allocator. This PR switches its global alloc to `tikv-jemallocator` which correctly uses sized deallocation (https://docs.rs/tikv-jemallocator/0.4.1/src/tikv_jemallocator/lib.rs.html#121-126). `tikv-jemallocator` as far as I can tell is a more up-to-date set of bindings to jemalloc than `jemallocator` The perf results of this pr are in large part due to the version upgrade of jemalloc but sized deallocation has a non-trivial improvement particularly to rustdoc. This pr also includes changes to bootstrap to correctly pass the jemalloc feature through to the rustdoc build,THUMBS_UP,2021-09-04T08:40:58Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/83153,MERGED,2021-03-15T16:27:28Z,2021-03-16T03:58:55Z,Mark `extern_mod_stmt_cnum` as `eval_always`,Aaron1011,4c10c84c63bb31d98afad757107970150d691c1e,1,Auto merge of #83153 - Aaron1011:eval-always-extern_mod_stmt_cnum r=michaelwoerister Mark `extern_mod_stmt_cnum` as `eval_always` This query reads from global untracked state so it always needs to be evaluated.,HEART,2021-03-15T16:43:49Z,est31,NA https://github.com/rust-lang/rust/pull/83153,MERGED,2021-03-15T16:27:28Z,2021-03-16T03:58:55Z,Mark `extern_mod_stmt_cnum` as `eval_always`,Aaron1011,4c10c84c63bb31d98afad757107970150d691c1e,1,Auto merge of #83153 - Aaron1011:eval-always-extern_mod_stmt_cnum r=michaelwoerister Mark `extern_mod_stmt_cnum` as `eval_always` This query reads from global untracked state so it always needs to be evaluated.,HEART,2021-03-16T08:34:55Z,b-r-u,NA https://github.com/rust-lang/rust/pull/83156,MERGED,2021-03-15T17:23:54Z,2021-03-16T19:19:08Z,Fall-back to sans-serif if Arial is not available,nagisa,0f6b206ab4eee59298f38d6ae2d25b8386b6ec19,1,Rollup merge of #83156 - nagisa:nagisa/sans-serif-please r=GuillaumeGomez Fall-back to sans-serif if Arial is not available Otherwise on systems where Arial is not available the UA will fallback to a serif font rather than a sans-serif one. This is especially relevant on acessibility-conscious setups (such as is mine) that have web-fonts disabled and a limited set of fonts available on the system. r? ```@GuillaumeGomez``` cc ```@jsha```,THUMBS_UP,2021-03-15T19:26:00Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/83157,MERGED,2021-03-15T17:43:47Z,2021-03-16T19:19:08Z,No background for code in portability snippets,nagisa,896b44ab60f30ae046ce541ceaa125db0a05a3fb,3,Rollup merge of #83157 - nagisa:nagisa/portability-background r=GuillaumeGomez No background for code in portability snippets This better matches the appearance of this kind of snippet in the full item view and is less jarring to read due to repeated foreground-background changes. ![Listing of items in a module with some portability snippets attached to some of the items (light theme). The portability snippet has a light blue background and all of the text in it monospace or not is the same colour – black](https://user-images.githubusercontent.com/679122/111196363-1900f500-85b5-11eb-8f97-e283c59002a4.png) ![Listing of items in a module with some portability snippets attached to some of the items (dark theme). The portability snippet has a light blue background and all of the text in it monospace or not is the same colour – black](https://user-images.githubusercontent.com/679122/111196366-19998b80-85b5-11eb-9914-4d14d9d13ed3.png) There should be no observable changes to the ayu theme.,HOORAY,2021-03-16T02:33:53Z,Cldfire,NA https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,THUMBS_UP,2021-03-15T19:14:20Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,THUMBS_UP,2021-03-15T19:58:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,THUMBS_UP,2021-03-15T22:55:41Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,THUMBS_UP,2021-03-16T15:04:29Z,mati865,NA https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,THUMBS_UP,2021-03-18T10:19:13Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,HEART,2021-03-21T17:00:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/83160,MERGED,2021-03-15T19:03:25Z,2021-03-16T19:19:08Z,Deprecate RustcEncodable and RustcDecodable.,m-ou-se,39af66f6514bd6a477a1b9496de94c9567c6cb42,3,Rollup merge of #83160 - m-ou-se:deprecate-rustc-serialize-derives r=petrochenkov Deprecate RustcEncodable and RustcDecodable. We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude but we can deprecate them.,HEART,2021-07-18T22:47:47Z,bstrie,NA https://github.com/rust-lang/rust/pull/83174,MERGED,2021-03-15T22:20:14Z,2021-12-11T21:57:21Z,Suggest using a temporary variable to fix borrowck errors,camelid,433a13b47347849dbc8c5d5300b98b95be7fb2c9,11,Rollup merge of #83174 - camelid:borrow-help r=oli-obk Suggest using a temporary variable to fix borrowck errors Fixes #77834. In Rust nesting method calls with both require `&mut` access to `self` produces a borrow-check error: error[E0499]: cannot borrow `*self` as mutable more than once at a time --> src/lib.rs:7:14 | 7 | self.foo(self.bar()); | ---------^^^^^^^^^^- | | | | | | | second mutable borrow occurs here | | first borrow later used by call | first mutable borrow occurs here That's because Rust has a left-to-right evaluation order and the method receiver is passed first. Thus the argument to the method cannot then mutate `self`. There's an easy solution to this error: just extract a local variable for the inner argument: let tmp = self.bar(); self.foo(tmp); However the error doesn't give any suggestion of how to solve the problem. As a result new users may assume that it's impossible to express their code correctly and get stuck. This commit adds a (non-structured) suggestion to extract a local variable for the inner argument to solve the error. The suggestion uses heuristics that eliminate most false positives though there are a few false negatives (cases where the suggestion should be emitted but is not). Those other cases can be implemented in a future change.,THUMBS_UP,2021-12-17T17:40:21Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-03-16T14:18:20Z,est31,NA https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-03-16T20:10:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-03-20T18:43:36Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HOORAY,2021-03-20T18:44:20Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,THUMBS_UP,2021-03-20T18:44:24Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HOORAY,2021-03-22T16:32:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HOORAY,2021-03-29T02:44:27Z,camelid,NA https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-03-29T02:44:27Z,camelid,NA https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-04-01T06:59:40Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HOORAY,2021-04-01T19:00:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HOORAY,2021-04-05T01:20:12Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83185,MERGED,2021-03-16T06:02:01Z,2021-03-29T22:27:21Z,Remove (lots of) dead code,jyn514,48691ea6e639640f110b43e33d4aba1f07e7415c,74,Auto merge of #83185 - jyn514:remove-dead-code r=oli-obk Remove (lots of) dead code Builds on - [ ] https://github.com/rust-lang/rust/pull/83161 - [x] https://github.com/rust-lang/rust/pull/83230 - [x] https://github.com/rust-lang/rust/pull/83197. Found with https://github.com/est31/warnalyzer. See https://github.com/rust-lang/rust/pull/77739 for a similar change in the past. Dubious changes: - Maybe some of the dead code in rustc_data_structures should be kept in case someone wants to use it in the future? TODO: - [ ] check if any of the comments on the deleted code should be kept. - [x] update the compiler documentation; right now it fails to build - [x] finish moving `cfg(test)` changes into https://github.com/rust-lang/rust/pull/83197 cc `@est31`,HEART,2021-04-06T17:17:41Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/83203,MERGED,2021-03-16T16:14:25Z,2021-03-17T11:11:31Z,Don't warn about old rustdoc lint names (temporarily),jyn514,42e6d429c6151016e23f0c38d27946e966ffe88c,9,Rollup merge of #83203 - jyn514:rustdoc-warnings r=Manishearth Don't warn about old rustdoc lint names (temporarily) Since https://github.com/rust-lang/rust/pull/80527 rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints they get a hard error on stable compilers because rustc rejects all tool names it doesn't recognize (https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193). If they use the old name they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]` which defeats the whole point of the change: we *want* people to switch to the new name. To avoid people silencing the lint and never migrating to the tool lint this avoids warning about the old name while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel we can change these lints to warn again. This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this. r? `@Manishearth` cc `@rust-lang/rustdoc`,THUMBS_UP,2021-03-16T16:33:58Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/83203,MERGED,2021-03-16T16:14:25Z,2021-03-17T11:11:31Z,Don't warn about old rustdoc lint names (temporarily),jyn514,42e6d429c6151016e23f0c38d27946e966ffe88c,9,Rollup merge of #83203 - jyn514:rustdoc-warnings r=Manishearth Don't warn about old rustdoc lint names (temporarily) Since https://github.com/rust-lang/rust/pull/80527 rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints they get a hard error on stable compilers because rustc rejects all tool names it doesn't recognize (https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193). If they use the old name they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]` which defeats the whole point of the change: we *want* people to switch to the new name. To avoid people silencing the lint and never migrating to the tool lint this avoids warning about the old name while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel we can change these lints to warn again. This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this. r? `@Manishearth` cc `@rust-lang/rustdoc`,HEART,2021-03-16T19:40:30Z,camelid,NA https://github.com/rust-lang/rust/pull/83205,CLOSED,2021-03-16T16:16:48Z,2021-07-28T20:13:18Z,Allow method resolution to work on reference receiver types with Self : Sized bounds with reference trait implementations,b-naber,NA,NA,NA,HOORAY,2021-03-16T22:07:29Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,ROCKET,2021-03-17T00:39:31Z,fmease,NA https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,HEART,2021-03-18T17:50:13Z,estebank,NA https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,HOORAY,2021-03-29T02:41:35Z,camelid,NA https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,ROCKET,2021-04-15T15:22:33Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,HEART,2021-04-27T23:49:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,ROCKET,2021-04-27T23:50:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,HOORAY,2021-04-27T23:50:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83213,MERGED,2021-03-16T20:49:37Z,2021-05-04T10:20:53Z,Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021,rylev,7a0f1781d04662041db5deaef89598a8edd53717,48,Auto merge of #83213 - rylev:update-lints-to-errors r=nikomatsakis Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition. r? `@estebank`,HEART,2021-05-03T15:13:57Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/83214,MERGED,2021-03-16T21:21:52Z,2021-09-07T02:24:17Z,Mmap the incremental data instead of reading it.,cjgillot,11bbb5231349a0a144d86d5c0c21061a06d1969d,5,Auto merge of #83214 - cjgillot:dep-map r=michaelwoerister Mmap the incremental data instead of reading it. Instead of reading the full incremental state using `fs::read_file` we memmap it using a private read-only file-backed map. This allows the system to reclaim any memory we are not using while ensuring we are not polluted by outside modifications to the file. Suggested in https://github.com/rust-lang/rust/pull/83036#issuecomment-800458082 by `@bjorn3`,THUMBS_UP,2021-03-17T11:42:42Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/83215,MERGED,2021-03-16T21:26:09Z,2021-03-19T18:23:45Z,Deprecate std::os::haiku::raw which accidentally wasn't deprecated,bstrie,675ae2e366741caaa90fc4719cd0a8cee377abc3,1,Rollup merge of #83215 - bstrie:dephaikuraw r=joshtriplett Deprecate std::os::haiku::raw which accidentally wasn't deprecated In early 2016 all `std::os::*::raw` modules [were deprecated](https://github.com/rust-lang/rust/commit/aa23c98450063992473d40d707273903f8a3937d) in accordance with [RFC 1415](https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md). However at this same time support for Haiku was being added to libstd landing shortly after the aforementioned commit and due to some crossed wires a `std::os::haiku::raw` module was added and was not marked as deprecated. I have been in correspondence with the author of the Haiku patch ````@nielx ```` who has confirmed that this was simply an oversight and that the definitions from the libc crate should be preferred instead.,THUMBS_UP,2021-03-16T23:07:57Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/83218,CLOSED,2021-03-16T22:33:52Z,2021-03-21T23:53:06Z,Add `Vec::retain_mut`,jonas-schievink,NA,NA,NA,HOORAY,2021-03-17T08:30:29Z,CryZe,NA https://github.com/rust-lang/rust/pull/83218,CLOSED,2021-03-16T22:33:52Z,2021-03-21T23:53:06Z,Add `Vec::retain_mut`,jonas-schievink,NA,NA,NA,HOORAY,2021-05-25T12:14:43Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/83218,CLOSED,2021-03-16T22:33:52Z,2021-03-21T23:53:06Z,Add `Vec::retain_mut`,jonas-schievink,NA,NA,NA,HOORAY,2021-07-21T14:09:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83220,MERGED,2021-03-16T23:32:42Z,2021-03-24T23:39:32Z,Use `EvaluatedToOkModuloRegions` whenever we erase regions,Aaron1011,07e0e2ec268c140e607e1ac7f49f145612d0f597,2,Auto merge of #83220 - Aaron1011:fix/eval-region-cache r=nikomatsakis Use `EvaluatedToOkModuloRegions` whenever we erase regions Fixes #80691 When we evaluate a trait predicate we convert an `EvaluatedToOk` result to `EvaluatedToOkModuloRegions` if we erased any regions. We cache the result under a region-erased 'freshened' predicate so `EvaluatedToOk` may not be correct for other predicates that have the same cache key.,ROCKET,2021-03-31T18:01:39Z,estebank,NA https://github.com/rust-lang/rust/pull/83228,MERGED,2021-03-17T12:50:35Z,2021-03-18T02:32:32Z,Don't show HTML diff if tidy isn't installed for rustdoc tests,GuillaumeGomez,22a9582ca22869df08118c57d32620857e723c7b,2,Rollup merge of #83228 - GuillaumeGomez:no-diff-if-no-tidy r=jyn514 Don't show HTML diff if tidy isn't installed for rustdoc tests The output without the `tidy` tool is just way too big to be of any use. It makes reading the error much more complicated. r? ``@jyn514``,THUMBS_UP,2021-03-17T13:30:03Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83233,MERGED,2021-03-17T16:32:32Z,2021-10-23T09:21:47Z,Implement split_array and split_array_mut,jethrogb,5ea02745637be7c4c0c8ba46407bbfca3b66edcc,5,Rollup merge of #83233 - jethrogb:split_array r=yaahc Implement split_array and split_array_mut This implements `[T]::split_array::() -> (&[T; N] &[T])` and `[T; N]::split_array::() -> (&[T; M] &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing similar to #74373 #75026 etc. Fixes #74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately this is probably not what we want we would want the second return value to be an array of length N-M which will likely be possible with future const generics enhancements. We need to implement the array method now though to immediately shadow the slice method. This way when the slice methods get stabilized calling them on an array will not be automatic through coercion so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually since split_at_unchecked is internal-only it could be changed to be split_array-only.,THUMBS_UP,2021-08-18T10:10:04Z,thomwiggers,NA https://github.com/rust-lang/rust/pull/83233,MERGED,2021-03-17T16:32:32Z,2021-10-23T09:21:47Z,Implement split_array and split_array_mut,jethrogb,5ea02745637be7c4c0c8ba46407bbfca3b66edcc,5,Rollup merge of #83233 - jethrogb:split_array r=yaahc Implement split_array and split_array_mut This implements `[T]::split_array::() -> (&[T; N] &[T])` and `[T; N]::split_array::() -> (&[T; M] &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing similar to #74373 #75026 etc. Fixes #74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately this is probably not what we want we would want the second return value to be an array of length N-M which will likely be possible with future const generics enhancements. We need to implement the array method now though to immediately shadow the slice method. This way when the slice methods get stabilized calling them on an array will not be automatic through coercion so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually since split_at_unchecked is internal-only it could be changed to be split_array-only.,THUMBS_UP,2021-10-28T06:01:27Z,GrayJack,NA https://github.com/rust-lang/rust/pull/83233,MERGED,2021-03-17T16:32:32Z,2021-10-23T09:21:47Z,Implement split_array and split_array_mut,jethrogb,5ea02745637be7c4c0c8ba46407bbfca3b66edcc,5,Rollup merge of #83233 - jethrogb:split_array r=yaahc Implement split_array and split_array_mut This implements `[T]::split_array::() -> (&[T; N] &[T])` and `[T; N]::split_array::() -> (&[T; M] &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing similar to #74373 #75026 etc. Fixes #74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately this is probably not what we want we would want the second return value to be an array of length N-M which will likely be possible with future const generics enhancements. We need to implement the array method now though to immediately shadow the slice method. This way when the slice methods get stabilized calling them on an array will not be automatic through coercion so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually since split_at_unchecked is internal-only it could be changed to be split_array-only.,THUMBS_UP,2021-10-28T19:46:22Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/83233,MERGED,2021-03-17T16:32:32Z,2021-10-23T09:21:47Z,Implement split_array and split_array_mut,jethrogb,5ea02745637be7c4c0c8ba46407bbfca3b66edcc,5,Rollup merge of #83233 - jethrogb:split_array r=yaahc Implement split_array and split_array_mut This implements `[T]::split_array::() -> (&[T; N] &[T])` and `[T; N]::split_array::() -> (&[T; M] &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing similar to #74373 #75026 etc. Fixes #74674. This implements `[T; N]::split_array` returning an array and a slice. Ultimately this is probably not what we want we would want the second return value to be an array of length N-M which will likely be possible with future const generics enhancements. We need to implement the array method now though to immediately shadow the slice method. This way when the slice methods get stabilized calling them on an array will not be automatic through coercion so we won't have trouble stabilizing the array methods later (cf. into_iter debacle). An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually since split_at_unchecked is internal-only it could be changed to be split_array-only.,THUMBS_UP,2021-11-02T04:45:18Z,calebsander,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-03-17T20:03:51Z,lqd,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-03-18T14:26:17Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HEART,2021-07-12T22:38:19Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-07-12T22:38:20Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-07-12T22:39:31Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-07-13T07:05:40Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HOORAY,2021-09-06T15:25:42Z,iago-lito,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-09-06T19:07:07Z,cayv,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-09-06T19:29:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HOORAY,2021-09-06T20:43:15Z,tux3,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HEART,2021-09-06T20:43:15Z,tux3,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-09-06T23:38:54Z,DianaNites,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HOORAY,2021-09-16T13:35:09Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HEART,2021-09-16T13:35:09Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2021-09-16T13:35:10Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HOORAY,2022-02-11T04:47:56Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HOORAY,2022-06-16T08:35:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,HEART,2022-06-16T08:35:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/83234,CLOSED,2021-03-17T16:52:18Z,2021-10-05T10:20:44Z,Use ValTree in all type level constants,oli-obk,NA,NA,NA,ROCKET,2022-06-16T08:35:38Z,Virgiel,NA https://github.com/rust-lang/rust/pull/83239,MERGED,2021-03-17T20:40:43Z,2021-03-27T10:40:24Z,Remove/replace some outdated crates from the dependency tree,JohnTitor,5473b6dcfc4a7d6d7b4408ff992a02948a331298,2,Rollup merge of #83239 - JohnTitor:reduce-deps r=Mark-Simulacrum Remove/replace some outdated crates from the dependency tree - Remove `cloudabi` by updating `parking_lot` to 0.11.1. - Replace `packed_simd` with `packed_simd2` by updating `bytecount` to 0.6.2.,HEART,2021-03-18T15:17:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83244,MERGED,2021-03-17T23:07:33Z,2021-03-20T03:49:09Z,Fix overflowing length in Vec to VecDeque,cuviper,1a0e32f4bc30318f4e15d200039bdbc2ea659fdb,2,"Rollup merge of #83244 - cuviper:vec_deque-zst r=m-ou-se Fix overflowing length in Vec to VecDeque `Vec` can hold up to `usize::MAX` ZST items but `VecDeque` has a lower limit to keep its raw capacity as a power of two so we should check that in `From> for VecDeque`. We can also simplify the capacity check for the remaining non-ZST case. Before this fix the new test would fail on the length: ``` thread 'collections::vec_deque::tests::test_from_vec_zst_overflow' panicked at 'assertion failed: `(left == right)` left: `0` right: `9223372036854775808`' library/alloc/src/collections/vec_deque/tests.rs:474:5 note: panic did not contain expected string panic message: `""assertion failed: `(left == right)`\n left: `0` \n right: `9223372036854775808`""` expected substring: `""capacity overflow""` ``` That was a result of `len()` using a mask `& (size - 1)` with the improper length. Now we do get a ""capacity overflow"" panic as soon as that `VecDeque::from(vec)` is attempted. Fixes #80167.",THUMBS_UP,2021-03-20T07:01:42Z,bluss,NA https://github.com/rust-lang/rust/pull/83245,MERGED,2021-03-17T23:07:47Z,2021-03-27T16:06:29Z,Generalize and inline slice::fill specializations,the8472,101003881418d23fee3fcb1b1721a216a366f2da,2,Auto merge of #83245 - the8472:generalize-slice-fill r=m-ou-se Generalize and inline slice::fill specializations This makes the memset specialization applicable to more types. And since the code now lives in a generic method it is also eligible for cross-crate inlining which should fix #83235,THUMBS_UP,2021-04-03T01:37:20Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83254,MERGED,2021-03-18T09:18:57Z,2021-03-20T03:49:09Z,Include output stream in `panic!()` documentation,jfrimmel,2cc5d727926dd8868ef0f7f62748da9105704402,1,Rollup merge of #83254 - jfrimmel:panic_output-stream r=m-ou-se joshtriplett Include output stream in `panic!()` documentation Fixes #83252.,HEART,2021-03-19T08:49:31Z,osa1,omeragacan@gmail.com https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-18T20:54:14Z,lqd,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-18T21:18:48Z,CryZe,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-18T21:22:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-19T00:26:16Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-19T06:13:09Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-19T14:39:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-19T16:28:11Z,tmiasko,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-03-22T05:35:58Z,TrueDoctor,dennis@kobert.dev https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-04-17T15:48:30Z,Byron,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-04-29T18:45:14Z,hkratz,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-05-14T03:58:54Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-05-14T07:07:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-05-17T21:44:18Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-07-29T01:47:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83278,MERGED,2021-03-18T20:51:34Z,2021-05-08T21:10:24Z,Bump stdarch submodule,Amanieu,881c1ac408d93bb7adaa3a51dabab9266e82eee8,7,Auto merge of #83278 - Amanieu:bump_stdarch r=Mark-Simulacrum Bump stdarch submodule Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - Intrinsics that previously used `#[rustc_args_required_const]` now use const generics. See #83167 for more details. - `std_detect` is now a separate crate instead of a submodule of `std`.,ROCKET,2021-07-29T22:47:02Z,worstpractice,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-03-20T00:29:30Z,tmandry,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HEART,2021-03-23T02:01:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-03-25T00:12:12Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HEART,2021-03-25T00:12:12Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HEART,2021-03-25T08:59:31Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-03-25T08:59:32Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-04-01T08:35:03Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-04-01T17:17:16Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HEART,2021-04-01T17:17:16Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HEART,2021-04-02T14:18:54Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/83307,MERGED,2021-03-19T21:23:41Z,2021-03-25T07:48:56Z,coverage bug fixes and optimization support,richkadel,dbc37a97dcf08984163133cff85af5190af037ca,62,"Auto merge of #83307 - richkadel:cov-unused-functions-1.1 r=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program it increased the size by about 40%. I have not tested large programs but there is anecdotal evidence that profraw files were way too large. This is a good fix regardless but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR comparisons with Clang C++ LLVM IR when compiled with coverage and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance and generates dedicated instances for each unused function. This change and a few other adjustments (similar to what is required for `-C link-dead-code` but with lower impact) makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: ""Unexecuted instantiation:..."" for a generic function from multiple crates Fixed by removing the aforementioned hack. Some ""Unexecuted instantiation"" notices are unavoidable as explained in the `used_crate.rs` test but `-Zinstrument-coverage` has new options to back off support for either unused generics or all unused functions which avoids the notice at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)] and in some cases the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`",HOORAY,2021-04-02T14:18:55Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/83312,MERGED,2021-03-20T00:56:47Z,2021-05-03T13:20:41Z,parser: Remove support for inner attributes on non-block expressions,petrochenkov,c825bc431ee5b815847b9bab693c59c43986fc4b,13,Auto merge of #83312 - petrochenkov:noinner r=Aaron1011 parser: Remove support for inner attributes on non-block expressions Remove support for attributes like ```rust fn attrs() { (#![print_target_and_args(fifth)] 1 2); [#![print_target_and_args(sixth)] 1 2]; [#![print_target_and_args(seventh)] true ; 5]; match 0 { #![print_target_and_args(eighth)] _ => {} } MyStruct { #![print_target_and_args(ninth)] field: true }; } ``` They are - useless - unstable (modulo holes like https://github.com/rust-lang/rust/issues/65860) - pessimize compiler performance namely token collection for macros (cc https://github.com/rust-lang/rust/pull/82608) I still want to run crater on this to check whether the stability holes are exploited in practice and whether such attributes are used at all.,THUMBS_UP,2021-03-20T01:10:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83319,MERGED,2021-03-20T10:22:21Z,2021-07-15T22:41:20Z,Layout error instead of an ICE for packed and aligned types,tmiasko,b1f8e27b74c541d3d555149c8efa4bfe9385cd56,3,Auto merge of #83319 - tmiasko:packed-aligned r=jackh726 Layout error instead of an ICE for packed and aligned types Fixes #83107.,HOORAY,2021-03-20T11:00:59Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/83343,MERGED,2021-03-21T11:32:01Z,2021-03-27T10:40:24Z,Simplify and fix byte skipping in format! string parser,osa1,d7216bae233d8e5f1191ec0c7dcf741789a235b0,3,Rollup merge of #83343 - osa1:issue83340 r=jackh726 Simplify and fix byte skipping in format! string parser Fixes '\\' handling in format strings. Fixes #83340,THUMBS_UP,2021-03-26T18:20:47Z,estebank,NA https://github.com/rust-lang/rust/pull/83348,MERGED,2021-03-21T14:35:33Z,2021-03-27T19:04:34Z,format macro argument parsing fix,osa1,973fb4b77feb589cd8fe4c0f5ee2454b246a1532,4,"Rollup merge of #83348 - osa1:issue83344 r=jackh726 format macro argument parsing fix When the character next to `{}` is ""shifted"" (when mapping a byte index in the format string to span) we should avoid shifting the span end index so first map the index of `}` to span then bump the span instead of first mapping the next byte index to a span (which causes bumping the end span too much). Regression test added. Fixes #83344 --- r? ```@estebank```",THUMBS_UP,2021-03-26T18:20:10Z,estebank,NA https://github.com/rust-lang/rust/pull/83353,MERGED,2021-03-21T19:28:02Z,2021-03-24T04:13:27Z,Add internal io::Error::new_const to avoid allocations.,m-ou-se,a42e62fa0a59d0ba620889f97513929a113a6fbd,41,"Rollup merge of #83353 - m-ou-se:io-error-avoid-alloc r=nagisa Add internal io::Error::new_const to avoid allocations. This makes it possible to have a io::Error containing a message with zero allocations and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind ""message"")`. The function signature isn't perfect because it needs a reference to the `&str`. So for now this is just a `pub(crate)` function. Later we'll be able to use `fn new_const(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.) See https://github.com/rust-lang/rust/issues/83352",HEART,2021-03-23T12:35:41Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/83353,MERGED,2021-03-21T19:28:02Z,2021-03-24T04:13:27Z,Add internal io::Error::new_const to avoid allocations.,m-ou-se,a42e62fa0a59d0ba620889f97513929a113a6fbd,41,"Rollup merge of #83353 - m-ou-se:io-error-avoid-alloc r=nagisa Add internal io::Error::new_const to avoid allocations. This makes it possible to have a io::Error containing a message with zero allocations and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind ""message"")`. The function signature isn't perfect because it needs a reference to the `&str`. So for now this is just a `pub(crate)` function. Later we'll be able to use `fn new_const(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.) See https://github.com/rust-lang/rust/issues/83352",HEART,2021-03-26T17:15:52Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/83353,MERGED,2021-03-21T19:28:02Z,2021-03-24T04:13:27Z,Add internal io::Error::new_const to avoid allocations.,m-ou-se,a42e62fa0a59d0ba620889f97513929a113a6fbd,41,"Rollup merge of #83353 - m-ou-se:io-error-avoid-alloc r=nagisa Add internal io::Error::new_const to avoid allocations. This makes it possible to have a io::Error containing a message with zero allocations and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind ""message"")`. The function signature isn't perfect because it needs a reference to the `&str`. So for now this is just a `pub(crate)` function. Later we'll be able to use `fn new_const(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.) See https://github.com/rust-lang/rust/issues/83352",HEART,2021-03-27T12:12:50Z,bluss,NA https://github.com/rust-lang/rust/pull/83354,CLOSED,2021-03-21T19:58:12Z,2022-01-01T12:09:43Z,[WIP] Expand all attributes in left-to-right order,petrochenkov,NA,NA,NA,HOORAY,2021-04-02T19:50:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83355,CLOSED,2021-03-21T21:41:49Z,2021-03-28T10:01:03Z,[WIP] Start transforming documentation toggles into pure css ones,GuillaumeGomez,NA,NA,NA,HEART,2021-03-21T21:49:17Z,camelid,NA https://github.com/rust-lang/rust/pull/83355,CLOSED,2021-03-21T21:41:49Z,2021-03-28T10:01:03Z,[WIP] Start transforming documentation toggles into pure css ones,GuillaumeGomez,NA,NA,NA,HEART,2021-03-22T08:20:48Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/83355,CLOSED,2021-03-21T21:41:49Z,2021-03-28T10:01:03Z,[WIP] Start transforming documentation toggles into pure css ones,GuillaumeGomez,NA,NA,NA,HEART,2021-03-23T11:24:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/83355,CLOSED,2021-03-21T21:41:49Z,2021-03-28T10:01:03Z,[WIP] Start transforming documentation toggles into pure css ones,GuillaumeGomez,NA,NA,NA,HEART,2021-03-27T01:07:12Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/83357,MERGED,2021-03-21T22:13:55Z,2021-03-30T06:22:33Z,Reduce the impact of Vec::reserve calls that do not cause any allocation,saethlin,32d3276561e88bfdf92cc483cff842a24fdd4b37,1,Auto merge of #83357 - saethlin:vec-reserve-inlining r=dtolnay Reduce the impact of Vec::reserve calls that do not cause any allocation I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`) so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity. This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024` Before: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 580 MB/s 990 MB/s data/citm_catalog.json 720 MB/s 660 MB/s data/twitter.json 570 MB/s 960 MB/s ``` After: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 560 MB/s 1130 MB/s data/citm_catalog.json 710 MB/s 880 MB/s data/twitter.json 530 MB/s 1230 MB/s ``` That's approximately a one-third increase in throughput on two of the benchmarks and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions so I'm not convinced they're meaningful here). This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases. Compiling this simple program demonstrates the change in codegen that causes the perf impact: ```rust fn main() { reserve(&mut Vec::new()); } #[inline(never)] fn reserve(v: &mut Vec) { v.reserve(1234); } ``` Before: ```rust 00000000000069b0 : 69b0: 53 push %rbx 69b1: 48 83 ec 30 sub $0x30 %rsp 69b5: 48 8b 47 08 mov 0x8(%rdi) %rax 69b9: 48 8b 4f 10 mov 0x10(%rdi) %rcx 69bd: 48 89 c2 mov %rax %rdx 69c0: 48 29 ca sub %rcx %rdx 69c3: 48 81 fa d1 04 00 00 cmp $0x4d1 %rdx 69ca: 77 73 ja 6a3f 69cc: 48 81 c1 d2 04 00 00 add $0x4d2 %rcx 69d3: 72 75 jb 6a4a 69d5: 48 89 fb mov %rdi %rbx 69d8: 48 8d 14 00 lea (%rax %rax 1) %rdx 69dc: 48 39 ca cmp %rcx %rdx 69df: 48 0f 47 ca cmova %rdx %rcx 69e3: 48 83 f9 08 cmp $0x8 %rcx 69e7: be 08 00 00 00 mov $0x8 %esi 69ec: 48 0f 47 f1 cmova %rcx %rsi 69f0: 48 85 c0 test %rax %rax 69f3: 74 17 je 6a0c 69f5: 48 8b 0b mov (%rbx) %rcx 69f8: 48 89 0c 24 mov %rcx (%rsp) 69fc: 48 89 44 24 08 mov %rax 0x8(%rsp) 6a01: 48 c7 44 24 10 01 00 movq $0x1 0x10(%rsp) 6a08: 00 00 6a0a: eb 08 jmp 6a14 6a0c: 48 c7 04 24 00 00 00 movq $0x0 (%rsp) 6a13: 00 6a14: 48 8d 7c 24 18 lea 0x18(%rsp) %rdi 6a19: 48 89 e1 mov %rsp %rcx 6a1c: ba 01 00 00 00 mov $0x1 %edx 6a21: e8 9a fe ff ff call 68c0 6a26: 48 8b 7c 24 20 mov 0x20(%rsp) %rdi 6a2b: 48 8b 74 24 28 mov 0x28(%rsp) %rsi 6a30: 48 83 7c 24 18 01 cmpq $0x1 0x18(%rsp) 6a36: 74 0d je 6a45 6a38: 48 89 3b mov %rdi (%rbx) 6a3b: 48 89 73 08 mov %rsi 0x8(%rbx) 6a3f: 48 83 c4 30 add $0x30 %rsp 6a43: 5b pop %rbx 6a44: c3 ret 6a45: 48 85 f6 test %rsi %rsi 6a48: 75 08 jne 6a52 6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490> 6a50: 0f 0b ud2 6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550> 6a58: 0f 0b ud2 6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax %rax 1) ``` After: ```asm 0000000000006910 : 6910: 48 8b 47 08 mov 0x8(%rdi) %rax 6914: 48 8b 77 10 mov 0x10(%rdi) %rsi 6918: 48 29 f0 sub %rsi %rax 691b: 48 3d d1 04 00 00 cmp $0x4d1 %rax 6921: 77 05 ja 6928 6923: e9 e8 fe ff ff jmp 6810 ::reserve::do_reserve_and_handle> 6928: c3 ret 6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) ```,THUMBS_UP,2021-03-22T01:28:17Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/83357,MERGED,2021-03-21T22:13:55Z,2021-03-30T06:22:33Z,Reduce the impact of Vec::reserve calls that do not cause any allocation,saethlin,32d3276561e88bfdf92cc483cff842a24fdd4b37,1,Auto merge of #83357 - saethlin:vec-reserve-inlining r=dtolnay Reduce the impact of Vec::reserve calls that do not cause any allocation I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`) so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity. This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024` Before: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 580 MB/s 990 MB/s data/citm_catalog.json 720 MB/s 660 MB/s data/twitter.json 570 MB/s 960 MB/s ``` After: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 560 MB/s 1130 MB/s data/citm_catalog.json 710 MB/s 880 MB/s data/twitter.json 530 MB/s 1230 MB/s ``` That's approximately a one-third increase in throughput on two of the benchmarks and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions so I'm not convinced they're meaningful here). This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases. Compiling this simple program demonstrates the change in codegen that causes the perf impact: ```rust fn main() { reserve(&mut Vec::new()); } #[inline(never)] fn reserve(v: &mut Vec) { v.reserve(1234); } ``` Before: ```rust 00000000000069b0 : 69b0: 53 push %rbx 69b1: 48 83 ec 30 sub $0x30 %rsp 69b5: 48 8b 47 08 mov 0x8(%rdi) %rax 69b9: 48 8b 4f 10 mov 0x10(%rdi) %rcx 69bd: 48 89 c2 mov %rax %rdx 69c0: 48 29 ca sub %rcx %rdx 69c3: 48 81 fa d1 04 00 00 cmp $0x4d1 %rdx 69ca: 77 73 ja 6a3f 69cc: 48 81 c1 d2 04 00 00 add $0x4d2 %rcx 69d3: 72 75 jb 6a4a 69d5: 48 89 fb mov %rdi %rbx 69d8: 48 8d 14 00 lea (%rax %rax 1) %rdx 69dc: 48 39 ca cmp %rcx %rdx 69df: 48 0f 47 ca cmova %rdx %rcx 69e3: 48 83 f9 08 cmp $0x8 %rcx 69e7: be 08 00 00 00 mov $0x8 %esi 69ec: 48 0f 47 f1 cmova %rcx %rsi 69f0: 48 85 c0 test %rax %rax 69f3: 74 17 je 6a0c 69f5: 48 8b 0b mov (%rbx) %rcx 69f8: 48 89 0c 24 mov %rcx (%rsp) 69fc: 48 89 44 24 08 mov %rax 0x8(%rsp) 6a01: 48 c7 44 24 10 01 00 movq $0x1 0x10(%rsp) 6a08: 00 00 6a0a: eb 08 jmp 6a14 6a0c: 48 c7 04 24 00 00 00 movq $0x0 (%rsp) 6a13: 00 6a14: 48 8d 7c 24 18 lea 0x18(%rsp) %rdi 6a19: 48 89 e1 mov %rsp %rcx 6a1c: ba 01 00 00 00 mov $0x1 %edx 6a21: e8 9a fe ff ff call 68c0 6a26: 48 8b 7c 24 20 mov 0x20(%rsp) %rdi 6a2b: 48 8b 74 24 28 mov 0x28(%rsp) %rsi 6a30: 48 83 7c 24 18 01 cmpq $0x1 0x18(%rsp) 6a36: 74 0d je 6a45 6a38: 48 89 3b mov %rdi (%rbx) 6a3b: 48 89 73 08 mov %rsi 0x8(%rbx) 6a3f: 48 83 c4 30 add $0x30 %rsp 6a43: 5b pop %rbx 6a44: c3 ret 6a45: 48 85 f6 test %rsi %rsi 6a48: 75 08 jne 6a52 6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490> 6a50: 0f 0b ud2 6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550> 6a58: 0f 0b ud2 6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax %rax 1) ``` After: ```asm 0000000000006910 : 6910: 48 8b 47 08 mov 0x8(%rdi) %rax 6914: 48 8b 77 10 mov 0x10(%rdi) %rsi 6918: 48 29 f0 sub %rsi %rax 691b: 48 3d d1 04 00 00 cmp $0x4d1 %rax 6921: 77 05 ja 6928 6923: e9 e8 fe ff ff jmp 6810 ::reserve::do_reserve_and_handle> 6928: c3 ret 6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) ```,THUMBS_UP,2021-04-08T18:18:03Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/83357,MERGED,2021-03-21T22:13:55Z,2021-03-30T06:22:33Z,Reduce the impact of Vec::reserve calls that do not cause any allocation,saethlin,32d3276561e88bfdf92cc483cff842a24fdd4b37,1,Auto merge of #83357 - saethlin:vec-reserve-inlining r=dtolnay Reduce the impact of Vec::reserve calls that do not cause any allocation I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`) so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity. This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024` Before: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 580 MB/s 990 MB/s data/citm_catalog.json 720 MB/s 660 MB/s data/twitter.json 570 MB/s 960 MB/s ``` After: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 560 MB/s 1130 MB/s data/citm_catalog.json 710 MB/s 880 MB/s data/twitter.json 530 MB/s 1230 MB/s ``` That's approximately a one-third increase in throughput on two of the benchmarks and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions so I'm not convinced they're meaningful here). This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases. Compiling this simple program demonstrates the change in codegen that causes the perf impact: ```rust fn main() { reserve(&mut Vec::new()); } #[inline(never)] fn reserve(v: &mut Vec) { v.reserve(1234); } ``` Before: ```rust 00000000000069b0 : 69b0: 53 push %rbx 69b1: 48 83 ec 30 sub $0x30 %rsp 69b5: 48 8b 47 08 mov 0x8(%rdi) %rax 69b9: 48 8b 4f 10 mov 0x10(%rdi) %rcx 69bd: 48 89 c2 mov %rax %rdx 69c0: 48 29 ca sub %rcx %rdx 69c3: 48 81 fa d1 04 00 00 cmp $0x4d1 %rdx 69ca: 77 73 ja 6a3f 69cc: 48 81 c1 d2 04 00 00 add $0x4d2 %rcx 69d3: 72 75 jb 6a4a 69d5: 48 89 fb mov %rdi %rbx 69d8: 48 8d 14 00 lea (%rax %rax 1) %rdx 69dc: 48 39 ca cmp %rcx %rdx 69df: 48 0f 47 ca cmova %rdx %rcx 69e3: 48 83 f9 08 cmp $0x8 %rcx 69e7: be 08 00 00 00 mov $0x8 %esi 69ec: 48 0f 47 f1 cmova %rcx %rsi 69f0: 48 85 c0 test %rax %rax 69f3: 74 17 je 6a0c 69f5: 48 8b 0b mov (%rbx) %rcx 69f8: 48 89 0c 24 mov %rcx (%rsp) 69fc: 48 89 44 24 08 mov %rax 0x8(%rsp) 6a01: 48 c7 44 24 10 01 00 movq $0x1 0x10(%rsp) 6a08: 00 00 6a0a: eb 08 jmp 6a14 6a0c: 48 c7 04 24 00 00 00 movq $0x0 (%rsp) 6a13: 00 6a14: 48 8d 7c 24 18 lea 0x18(%rsp) %rdi 6a19: 48 89 e1 mov %rsp %rcx 6a1c: ba 01 00 00 00 mov $0x1 %edx 6a21: e8 9a fe ff ff call 68c0 6a26: 48 8b 7c 24 20 mov 0x20(%rsp) %rdi 6a2b: 48 8b 74 24 28 mov 0x28(%rsp) %rsi 6a30: 48 83 7c 24 18 01 cmpq $0x1 0x18(%rsp) 6a36: 74 0d je 6a45 6a38: 48 89 3b mov %rdi (%rbx) 6a3b: 48 89 73 08 mov %rsi 0x8(%rbx) 6a3f: 48 83 c4 30 add $0x30 %rsp 6a43: 5b pop %rbx 6a44: c3 ret 6a45: 48 85 f6 test %rsi %rsi 6a48: 75 08 jne 6a52 6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490> 6a50: 0f 0b ud2 6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550> 6a58: 0f 0b ud2 6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax %rax 1) ``` After: ```asm 0000000000006910 : 6910: 48 8b 47 08 mov 0x8(%rdi) %rax 6914: 48 8b 77 10 mov 0x10(%rdi) %rsi 6918: 48 29 f0 sub %rsi %rax 691b: 48 3d d1 04 00 00 cmp $0x4d1 %rax 6921: 77 05 ja 6928 6923: e9 e8 fe ff ff jmp 6810 ::reserve::do_reserve_and_handle> 6928: c3 ret 6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) ```,THUMBS_UP,2021-04-08T23:40:15Z,BlueGhostAlt,NA https://github.com/rust-lang/rust/pull/83357,MERGED,2021-03-21T22:13:55Z,2021-03-30T06:22:33Z,Reduce the impact of Vec::reserve calls that do not cause any allocation,saethlin,32d3276561e88bfdf92cc483cff842a24fdd4b37,1,Auto merge of #83357 - saethlin:vec-reserve-inlining r=dtolnay Reduce the impact of Vec::reserve calls that do not cause any allocation I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`) so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity. This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024` Before: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 580 MB/s 990 MB/s data/citm_catalog.json 720 MB/s 660 MB/s data/twitter.json 570 MB/s 960 MB/s ``` After: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 560 MB/s 1130 MB/s data/citm_catalog.json 710 MB/s 880 MB/s data/twitter.json 530 MB/s 1230 MB/s ``` That's approximately a one-third increase in throughput on two of the benchmarks and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions so I'm not convinced they're meaningful here). This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases. Compiling this simple program demonstrates the change in codegen that causes the perf impact: ```rust fn main() { reserve(&mut Vec::new()); } #[inline(never)] fn reserve(v: &mut Vec) { v.reserve(1234); } ``` Before: ```rust 00000000000069b0 : 69b0: 53 push %rbx 69b1: 48 83 ec 30 sub $0x30 %rsp 69b5: 48 8b 47 08 mov 0x8(%rdi) %rax 69b9: 48 8b 4f 10 mov 0x10(%rdi) %rcx 69bd: 48 89 c2 mov %rax %rdx 69c0: 48 29 ca sub %rcx %rdx 69c3: 48 81 fa d1 04 00 00 cmp $0x4d1 %rdx 69ca: 77 73 ja 6a3f 69cc: 48 81 c1 d2 04 00 00 add $0x4d2 %rcx 69d3: 72 75 jb 6a4a 69d5: 48 89 fb mov %rdi %rbx 69d8: 48 8d 14 00 lea (%rax %rax 1) %rdx 69dc: 48 39 ca cmp %rcx %rdx 69df: 48 0f 47 ca cmova %rdx %rcx 69e3: 48 83 f9 08 cmp $0x8 %rcx 69e7: be 08 00 00 00 mov $0x8 %esi 69ec: 48 0f 47 f1 cmova %rcx %rsi 69f0: 48 85 c0 test %rax %rax 69f3: 74 17 je 6a0c 69f5: 48 8b 0b mov (%rbx) %rcx 69f8: 48 89 0c 24 mov %rcx (%rsp) 69fc: 48 89 44 24 08 mov %rax 0x8(%rsp) 6a01: 48 c7 44 24 10 01 00 movq $0x1 0x10(%rsp) 6a08: 00 00 6a0a: eb 08 jmp 6a14 6a0c: 48 c7 04 24 00 00 00 movq $0x0 (%rsp) 6a13: 00 6a14: 48 8d 7c 24 18 lea 0x18(%rsp) %rdi 6a19: 48 89 e1 mov %rsp %rcx 6a1c: ba 01 00 00 00 mov $0x1 %edx 6a21: e8 9a fe ff ff call 68c0 6a26: 48 8b 7c 24 20 mov 0x20(%rsp) %rdi 6a2b: 48 8b 74 24 28 mov 0x28(%rsp) %rsi 6a30: 48 83 7c 24 18 01 cmpq $0x1 0x18(%rsp) 6a36: 74 0d je 6a45 6a38: 48 89 3b mov %rdi (%rbx) 6a3b: 48 89 73 08 mov %rsi 0x8(%rbx) 6a3f: 48 83 c4 30 add $0x30 %rsp 6a43: 5b pop %rbx 6a44: c3 ret 6a45: 48 85 f6 test %rsi %rsi 6a48: 75 08 jne 6a52 6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490> 6a50: 0f 0b ud2 6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550> 6a58: 0f 0b ud2 6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax %rax 1) ``` After: ```asm 0000000000006910 : 6910: 48 8b 47 08 mov 0x8(%rdi) %rax 6914: 48 8b 77 10 mov 0x10(%rdi) %rsi 6918: 48 29 f0 sub %rsi %rax 691b: 48 3d d1 04 00 00 cmp $0x4d1 %rax 6921: 77 05 ja 6928 6923: e9 e8 fe ff ff jmp 6810 ::reserve::do_reserve_and_handle> 6928: c3 ret 6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) ```,THUMBS_UP,2021-04-09T07:00:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83357,MERGED,2021-03-21T22:13:55Z,2021-03-30T06:22:33Z,Reduce the impact of Vec::reserve calls that do not cause any allocation,saethlin,32d3276561e88bfdf92cc483cff842a24fdd4b37,1,Auto merge of #83357 - saethlin:vec-reserve-inlining r=dtolnay Reduce the impact of Vec::reserve calls that do not cause any allocation I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`) so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity. This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024` Before: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 580 MB/s 990 MB/s data/citm_catalog.json 720 MB/s 660 MB/s data/twitter.json 570 MB/s 960 MB/s ``` After: ``` DOM STRUCT ======= serde_json ======= parse|stringify ===== parse|stringify ==== data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s ======= json-rust ======== parse|stringify ===== parse|stringify ==== data/canada.json 560 MB/s 1130 MB/s data/citm_catalog.json 710 MB/s 880 MB/s data/twitter.json 530 MB/s 1230 MB/s ``` That's approximately a one-third increase in throughput on two of the benchmarks and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions so I'm not convinced they're meaningful here). This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases. Compiling this simple program demonstrates the change in codegen that causes the perf impact: ```rust fn main() { reserve(&mut Vec::new()); } #[inline(never)] fn reserve(v: &mut Vec) { v.reserve(1234); } ``` Before: ```rust 00000000000069b0 : 69b0: 53 push %rbx 69b1: 48 83 ec 30 sub $0x30 %rsp 69b5: 48 8b 47 08 mov 0x8(%rdi) %rax 69b9: 48 8b 4f 10 mov 0x10(%rdi) %rcx 69bd: 48 89 c2 mov %rax %rdx 69c0: 48 29 ca sub %rcx %rdx 69c3: 48 81 fa d1 04 00 00 cmp $0x4d1 %rdx 69ca: 77 73 ja 6a3f 69cc: 48 81 c1 d2 04 00 00 add $0x4d2 %rcx 69d3: 72 75 jb 6a4a 69d5: 48 89 fb mov %rdi %rbx 69d8: 48 8d 14 00 lea (%rax %rax 1) %rdx 69dc: 48 39 ca cmp %rcx %rdx 69df: 48 0f 47 ca cmova %rdx %rcx 69e3: 48 83 f9 08 cmp $0x8 %rcx 69e7: be 08 00 00 00 mov $0x8 %esi 69ec: 48 0f 47 f1 cmova %rcx %rsi 69f0: 48 85 c0 test %rax %rax 69f3: 74 17 je 6a0c 69f5: 48 8b 0b mov (%rbx) %rcx 69f8: 48 89 0c 24 mov %rcx (%rsp) 69fc: 48 89 44 24 08 mov %rax 0x8(%rsp) 6a01: 48 c7 44 24 10 01 00 movq $0x1 0x10(%rsp) 6a08: 00 00 6a0a: eb 08 jmp 6a14 6a0c: 48 c7 04 24 00 00 00 movq $0x0 (%rsp) 6a13: 00 6a14: 48 8d 7c 24 18 lea 0x18(%rsp) %rdi 6a19: 48 89 e1 mov %rsp %rcx 6a1c: ba 01 00 00 00 mov $0x1 %edx 6a21: e8 9a fe ff ff call 68c0 6a26: 48 8b 7c 24 20 mov 0x20(%rsp) %rdi 6a2b: 48 8b 74 24 28 mov 0x28(%rsp) %rsi 6a30: 48 83 7c 24 18 01 cmpq $0x1 0x18(%rsp) 6a36: 74 0d je 6a45 6a38: 48 89 3b mov %rdi (%rbx) 6a3b: 48 89 73 08 mov %rsi 0x8(%rbx) 6a3f: 48 83 c4 30 add $0x30 %rsp 6a43: 5b pop %rbx 6a44: c3 ret 6a45: 48 85 f6 test %rsi %rsi 6a48: 75 08 jne 6a52 6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490> 6a50: 0f 0b ud2 6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550> 6a58: 0f 0b ud2 6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax %rax 1) ``` After: ```asm 0000000000006910 : 6910: 48 8b 47 08 mov 0x8(%rdi) %rax 6914: 48 8b 77 10 mov 0x10(%rdi) %rsi 6918: 48 29 f0 sub %rsi %rax 691b: 48 3d d1 04 00 00 cmp $0x4d1 %rax 6921: 77 05 ja 6928 6923: e9 e8 fe ff ff jmp 6810 ::reserve::do_reserve_and_handle> 6928: c3 ret 6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) ```,THUMBS_UP,2021-04-15T18:55:44Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-04-11T23:51:16Z,marmeladema,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-04-13T23:46:41Z,conradkleinespel,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-04-18T15:00:31Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-04-21T20:30:08Z,jhernandez-at-wiris,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-04T18:44:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-16T14:14:15Z,Kestrer,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-19T09:07:42Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-19T10:24:37Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-19T12:19:21Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-05-19T16:43:21Z,bluss,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-19T19:02:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-19T20:41:26Z,Bernd-L,git@bernd.pw https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-05-19T20:41:27Z,Bernd-L,git@bernd.pw https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-20T02:32:43Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-20T17:39:05Z,QuarticCat,QuarticCat@protonmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-05-25T09:23:40Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-05-27T10:37:10Z,kangalioo,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-05-27T10:37:10Z,kangalioo,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-05-28T13:17:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-07-03T12:26:14Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-07-03T12:26:14Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-07-06T08:13:04Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-07-29T16:33:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-07-29T16:33:58Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-07-29T18:12:17Z,noritada,noritada.kobayashi@gmail.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-07-29T19:19:55Z,juxtaposition,gerardo.duran@globant.com https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-08-02T13:41:18Z,carlocorradini,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",HOORAY,2021-08-04T11:27:45Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/83366,MERGED,2021-03-22T05:38:18Z,2021-05-19T07:25:22Z,Stabilize extended_key_value_attributes,jyn514,3c99dcd82dbe78079901bf84aead3ec1f167a813,17,"Rollup merge of #83366 - jyn514:stabilize-key-value-attrs r=petrochenkov Stabilize extended_key_value_attributes Closes https://github.com/rust-lang/rust/issues/44732. Closes https://github.com/rust-lang/rust/issues/78835. Closes https://github.com/rust-lang/rust/issues/82768 (by making it irrelevant). # Stabilization report ## Summary This stabilizes using macro expansion in key-value attributes like so: ```rust #[doc = include_str!(""my_doc.md"")] struct S; #[path = concat!(env!(""OUT_DIR"") ""/generated.rs"")] mod m; ``` See Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455) for alternatives that were considered and rejected (""why accept no more and no less?"") This has been available on nightly since 1.50 with no major issues. ## Notes ### Accepted syntax The parser accepts arbitrary Rust expressions in this position but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g. `#[doc]`). Note that decorators and the like may be able to observe other expression forms. ### Expansion ordering Expansion of macro expressions in ""inert"" attributes occurs after decorators have executed analogously to macro expressions appearing in the function body or other parts of decorator input. There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion that can work). ## Test cases - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs The feature has also been dogfooded extensively in the compiler and standard library: - https://github.com/rust-lang/rust/pull/83329 - https://github.com/rust-lang/rust/pull/83230 - https://github.com/rust-lang/rust/pull/82641 - https://github.com/rust-lang/rust/pull/80534 ## Implementation history - Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412 - Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121 - Preliminary work to restrict expansion that would conflict with this feature: https://github.com/rust-lang/rust/pull/77271 - Initial implementation: https://github.com/rust-lang/rust/pull/78837 - Fix for an ICE: https://github.com/rust-lang/rust/pull/80563 ## Unresolved Questions ~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns but they have been resolved as of this final report.~~ ## Additional Information There are two workarounds that have a similar effect for `#[doc]` attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons: ```rust macro_rules! forward_inner_docs { ($e:expr => $i:item) => { #[doc = $e] $i }; } forward_inner_docs!(include_str!(""lib.rs"") => struct S {}); ``` This also works for other attributes (like `#[path = concat!(...)]`). The other is to use `doc(include)`: ```rust #![feature(external_doc)] #[doc(include = ""lib.rs"")] struct S {} ``` The first works but is non-trivial for people to discover and difficult to read and maintain. The second is a strange special-case for a particular use of the macro. This generalizes it to work for any use case not just including files. I plan to remove `doc(include)` when this is stabilized (https://github.com/rust-lang/rust/pull/82539). The `forward_inner_docs` workaround will still compile without warnings but I expect it to be used less once it's no longer necessary.",THUMBS_UP,2021-08-10T11:35:02Z,Voronar,NA https://github.com/rust-lang/rust/pull/83367,MERGED,2021-03-22T06:07:01Z,2021-03-22T17:48:31Z,Improve error message for unassigned query provider,richkadel,014a4ee9f5ea67798bbc7a2e815d4acc986967ce,1,Rollup merge of #83367 - richkadel:query-err-msg r=jyn514 Improve error message for unassigned query provider Fixes: #83122 r? `@jyn514` This implements the change we agreed on. Thanks!,HEART,2021-03-22T06:12:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83368,MERGED,2021-03-22T06:35:51Z,2021-04-05T16:39:09Z,"Add `download-rustc = ""if-unchanged""`",jyn514,335a3c4b7f5b64f7c0e3c86db8fa7989fb6a4771,3,"Rollup merge of #83368 - jyn514:download-if-unchanged r=Mark-Simulacrum Add `download-rustc = ""if-unchanged""` This allows keeping the setting to a fixed value without having to toggle it when you want to work on the compiler instead of on tools. This sets `BOOTSTRAP_DOWNLOAD_RUSTC` in bootstrap.py so rustbuild doesn't have to try and replicate its logic. Helps with https://github.com/rust-lang/rust/issues/81930. r? `@Mark-Simulacrum` cc `@camelid`",HEART,2021-03-22T20:45:13Z,camelid,NA https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,THUMBS_UP,2021-05-24T08:33:43Z,r00ster91,NA https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,HEART,2021-05-24T09:31:24Z,eopb,NA https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,THUMBS_UP,2021-05-24T12:48:41Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,HEART,2021-05-24T12:48:42Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,HEART,2021-05-24T13:38:40Z,extrawurst,NA https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,THUMBS_UP,2021-05-24T13:49:31Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,HEART,2021-05-24T13:49:32Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,THUMBS_UP,2021-09-11T22:24:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83371,CLOSED,2021-03-22T08:21:37Z,2021-12-12T03:05:39Z,Faster parsing for lower numbers for radix up to 16,gilescope,NA,NA,NA,HEART,2021-10-10T10:10:14Z,r00ster91,NA https://github.com/rust-lang/rust/pull/83377,MERGED,2021-03-22T14:37:27Z,2021-03-23T02:01:10Z,[stable] 1.51.0 release,Mark-Simulacrum,9bb6d54577665fb3abb6cf27c40ed5247ff3fc7f,6,Auto merge of #83377 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] 1.51.0 release Also includes backports of the release notes as well as: * SplitInclusive is public API #83372 * std: Fix a bug on the wasm32-wasi target opening files #82804 * Fix io::copy specialization using copy_file_range when writer was opened with O_APPEND #82417 r? `@Mark-Simulacrum`,HOORAY,2021-03-23T09:12:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/83388,MERGED,2021-03-22T19:23:29Z,2021-03-27T10:40:23Z,Make # pretty print format easier to discover,alamb,c1432679017cadb3b0dd3c6c7653e8ba138e4c63,1,"Rollup merge of #83388 - alamb:alamb/fmt-dcs r=Mark-Simulacrum Make # pretty print format easier to discover # Rationale: I use (cargo cult?) three formats in rust: `{}` debug `{:?}` and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR As a reminder ""pretty print"" means that where `{:?}` will print something like ``` foo: { b1: 1 b2: 2} ``` `{:#?}` will prints something like ``` foo { b1: 1 b2: 3 } ``` # Changes Add an example to `fmt` to try and make it easier to discover `#`",HOORAY,2021-03-22T20:29:31Z,carols10cents,NA https://github.com/rust-lang/rust/pull/83388,MERGED,2021-03-22T19:23:29Z,2021-03-27T10:40:23Z,Make # pretty print format easier to discover,alamb,c1432679017cadb3b0dd3c6c7653e8ba138e4c63,1,"Rollup merge of #83388 - alamb:alamb/fmt-dcs r=Mark-Simulacrum Make # pretty print format easier to discover # Rationale: I use (cargo cult?) three formats in rust: `{}` debug `{:?}` and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR As a reminder ""pretty print"" means that where `{:?}` will print something like ``` foo: { b1: 1 b2: 2} ``` `{:#?}` will prints something like ``` foo { b1: 1 b2: 3 } ``` # Changes Add an example to `fmt` to try and make it easier to discover `#`",HOORAY,2021-03-22T21:16:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83388,MERGED,2021-03-22T19:23:29Z,2021-03-27T10:40:23Z,Make # pretty print format easier to discover,alamb,c1432679017cadb3b0dd3c6c7653e8ba138e4c63,1,"Rollup merge of #83388 - alamb:alamb/fmt-dcs r=Mark-Simulacrum Make # pretty print format easier to discover # Rationale: I use (cargo cult?) three formats in rust: `{}` debug `{:?}` and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR As a reminder ""pretty print"" means that where `{:?}` will print something like ``` foo: { b1: 1 b2: 2} ``` `{:#?}` will prints something like ``` foo { b1: 1 b2: 3 } ``` # Changes Add an example to `fmt` to try and make it easier to discover `#`",THUMBS_UP,2021-03-22T21:51:56Z,Zerotask,NA https://github.com/rust-lang/rust/pull/83388,MERGED,2021-03-22T19:23:29Z,2021-03-27T10:40:23Z,Make # pretty print format easier to discover,alamb,c1432679017cadb3b0dd3c6c7653e8ba138e4c63,1,"Rollup merge of #83388 - alamb:alamb/fmt-dcs r=Mark-Simulacrum Make # pretty print format easier to discover # Rationale: I use (cargo cult?) three formats in rust: `{}` debug `{:?}` and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR As a reminder ""pretty print"" means that where `{:?}` will print something like ``` foo: { b1: 1 b2: 2} ``` `{:#?}` will prints something like ``` foo { b1: 1 b2: 3 } ``` # Changes Add an example to `fmt` to try and make it easier to discover `#`",HOORAY,2021-03-23T11:08:32Z,domodwyer,dom@itsallbroken.com https://github.com/rust-lang/rust/pull/83388,MERGED,2021-03-22T19:23:29Z,2021-03-27T10:40:23Z,Make # pretty print format easier to discover,alamb,c1432679017cadb3b0dd3c6c7653e8ba138e4c63,1,"Rollup merge of #83388 - alamb:alamb/fmt-dcs r=Mark-Simulacrum Make # pretty print format easier to discover # Rationale: I use (cargo cult?) three formats in rust: `{}` debug `{:?}` and pretty-print debug `{:#?}`. I discovered `{:#?}` in some blog post or guide when I started working in Rust. While `#` is documented I think it is hard to discover. So taking the good advice of ```@carols10cents``` I am trying to improve the docs with a PR As a reminder ""pretty print"" means that where `{:?}` will print something like ``` foo: { b1: 1 b2: 2} ``` `{:#?}` will prints something like ``` foo { b1: 1 b2: 3 } ``` # Changes Add an example to `fmt` to try and make it easier to discover `#`",THUMBS_UP,2021-03-23T16:47:27Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/83405,MERGED,2021-03-23T11:47:28Z,2021-03-24T04:13:27Z,Slight visual improvements to warning boxes in the docs,r00ster91,78437712b5b1ce73ca0244edc7a373e308e7cb07,3,"Rollup merge of #83405 - r00ster91:deprecated_emoji r=GuillaumeGomez Slight visual improvements to warning boxes in the docs First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility). For consistency the microscope has the black border too. Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either. Then I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum. But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue. I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance ""This is available since 1.0.0"". None of the current three box types (unstable deprecated and portability) are that. I think purple is a better fit for it because it's kind of in the middle between ""use it"" and ""don't use it"". Deprecated is definitely ""don't use it"". To illustrate this better here's a color spectrum: Blue = friendly ""use it"". ![image](https://user-images.githubusercontent.com/35064754/112139891-9a6b0f80-8bd3-11eb-94e1-dc747a3d4cf9.png) Red = danger ""don't use it"". And the purple in the middle (the color that the portability box now has) probably represents ""use it if you have to"" so it's not entirely friendly and not entirely a danger. That is why I think it fits. However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes. This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes: ![image](https://user-images.githubusercontent.com/35064754/112139327-ebc6cf00-8bd2-11eb-88ac-25219b43a1a0.png) ![image](https://user-images.githubusercontent.com/35064754/112139392-000acc00-8bd3-11eb-90c2-81feec93c521.png)",THUMBS_UP,2021-03-23T16:38:38Z,Zerotask,NA https://github.com/rust-lang/rust/pull/83407,CLOSED,2021-03-23T11:55:50Z,2021-05-31T05:03:57Z,Recover from `if (let ...)` in parsing instead of lowering,osa1,NA,NA,NA,THUMBS_UP,2021-03-25T15:48:27Z,estebank,NA https://github.com/rust-lang/rust/pull/83416,MERGED,2021-03-23T18:10:35Z,2021-04-16T19:25:27Z,std: Add a variant of thread locals with const init,alexcrichton,0cc00c48d2c8f7344028cf007d1ee551b886b602,6,Auto merge of #83416 - alexcrichton:const-thread-local r=sfackler std: Add a variant of thread locals with const init This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!` which is safe relative to `#[thread_local]` which is not easy to use in a portable fashion.,THUMBS_UP,2021-11-28T05:58:09Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83431,MERGED,2021-03-24T00:20:52Z,2021-03-27T10:40:23Z,Tell GitHub to highlight `config.toml.example` as TOML,camelid,9df2b5f89ca33b99c845ae507e790e78a1e87b9f,1,Rollup merge of #83431 - camelid:config-example-gitattributes r=Mark-Simulacrum Tell GitHub to highlight `config.toml.example` as TOML This should be a nice small quality of life improvement when looking at `config.toml.example` on GitHub or looking at diffs of it in PRs.,THUMBS_UP,2021-03-24T10:28:00Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83433,MERGED,2021-03-24T01:54:34Z,2021-06-07T02:30:27Z,Pass --cfg=bootstrap for proc macros built by stage0,jyn514,85fec06617ec45bb4f941720feb785f5892d4a0b,1,Rollup merge of #83433 - jyn514:cfg-bootstrap-macro r=Mark-Simulacrum Pass --cfg=bootstrap for proc macros built by stage0 Cargo has a bug where it ignores RUSTFLAGS when building proc macro crates (https://github.com/rust-lang/cargo/issues/4423). However sometimes rustc_macro needs to have conditional compilation when there are breaking changes to the `libproc_macro` API (see for example #83363). Previously this wasn't possible because the crate couldn't tell the difference between stage 0 and stage 1. Another alternative is to unconditionally build rustc_macros with the master libstd instead of the beta one (i.e. use `--sysroot stage0-sysroot`) but that led to strange and maddening errors: ``` error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on --> compiler/rustc_macros/src/lib.rs:5:5 | 5 | use synstructure::decl_derive; | ^^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5 | 90 | use proc_macro2::TokenStream; | ^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib ``` r? `@Mark-Simulacrum` cc `@jhpratt`,THUMBS_UP,2021-03-24T13:19:21Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83433,MERGED,2021-03-24T01:54:34Z,2021-06-07T02:30:27Z,Pass --cfg=bootstrap for proc macros built by stage0,jyn514,85fec06617ec45bb4f941720feb785f5892d4a0b,1,Rollup merge of #83433 - jyn514:cfg-bootstrap-macro r=Mark-Simulacrum Pass --cfg=bootstrap for proc macros built by stage0 Cargo has a bug where it ignores RUSTFLAGS when building proc macro crates (https://github.com/rust-lang/cargo/issues/4423). However sometimes rustc_macro needs to have conditional compilation when there are breaking changes to the `libproc_macro` API (see for example #83363). Previously this wasn't possible because the crate couldn't tell the difference between stage 0 and stage 1. Another alternative is to unconditionally build rustc_macros with the master libstd instead of the beta one (i.e. use `--sysroot stage0-sysroot`) but that led to strange and maddening errors: ``` error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on --> compiler/rustc_macros/src/lib.rs:5:5 | 5 | use synstructure::decl_derive; | ^^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5 | 90 | use proc_macro2::TokenStream; | ^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib ``` r? `@Mark-Simulacrum` cc `@jhpratt`,THUMBS_UP,2021-06-03T05:17:37Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/83456,MERGED,2021-03-25T01:45:07Z,2021-03-26T06:30:17Z,Add docs for Vec::from functions,notriddle,827d1ea590643bf65c8a8a6898f8970238eedec7,1,Rollup merge of #83456 - notriddle:vec-from-docs r=JohnTitor Add docs for Vec::from functions Part of #51430,THUMBS_UP,2021-03-25T07:54:45Z,bluss,NA https://github.com/rust-lang/rust/pull/83456,MERGED,2021-03-25T01:45:07Z,2021-03-26T06:30:17Z,Add docs for Vec::from functions,notriddle,827d1ea590643bf65c8a8a6898f8970238eedec7,1,Rollup merge of #83456 - notriddle:vec-from-docs r=JohnTitor Add docs for Vec::from functions Part of #51430,THUMBS_UP,2021-03-25T08:16:03Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/83468,MERGED,2021-03-25T13:44:07Z,2021-04-02T17:39:05Z,add OR_PATTERNS_BACK_COMPAT lint,hi-rustin,36bcf4069717b9dff90270d13b53a3b130329960,7,Auto merge of #83468 - hi-rustin:rustin-patch-lint r=nikomatsakis add OR_PATTERNS_BACK_COMPAT lint close https://github.com/rust-lang/rust/issues/83318,HEART,2021-03-30T19:43:13Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83468,MERGED,2021-03-25T13:44:07Z,2021-04-02T17:39:05Z,add OR_PATTERNS_BACK_COMPAT lint,hi-rustin,36bcf4069717b9dff90270d13b53a3b130329960,7,Auto merge of #83468 - hi-rustin:rustin-patch-lint r=nikomatsakis add OR_PATTERNS_BACK_COMPAT lint close https://github.com/rust-lang/rust/issues/83318,HEART,2021-09-03T22:58:55Z,weihanglo,NA https://github.com/rust-lang/rust/pull/83476,MERGED,2021-03-25T15:26:34Z,2021-04-07T18:02:24Z,Add strong_count mutation methods to Rc,mystor,505846ec07c1303369358a1c3358c7d7ee0ca12e,1,Rollup merge of #83476 - mystor:rc_mutate_strong_count r=m-ou-se Add strong_count mutation methods to Rc The corresponding methods were stabilized on `Arc` in #79285 (tracking: #71983). This patch implements and stabilizes identical methods on the `Rc` types as well.,HEART,2021-03-25T19:37:06Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/83476,MERGED,2021-03-25T15:26:34Z,2021-04-07T18:02:24Z,Add strong_count mutation methods to Rc,mystor,505846ec07c1303369358a1c3358c7d7ee0ca12e,1,Rollup merge of #83476 - mystor:rc_mutate_strong_count r=m-ou-se Add strong_count mutation methods to Rc The corresponding methods were stabilized on `Arc` in #79285 (tracking: #71983). This patch implements and stabilizes identical methods on the `Rc` types as well.,HEART,2021-03-26T12:21:09Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83476,MERGED,2021-03-25T15:26:34Z,2021-04-07T18:02:24Z,Add strong_count mutation methods to Rc,mystor,505846ec07c1303369358a1c3358c7d7ee0ca12e,1,Rollup merge of #83476 - mystor:rc_mutate_strong_count r=m-ou-se Add strong_count mutation methods to Rc The corresponding methods were stabilized on `Arc` in #79285 (tracking: #71983). This patch implements and stabilizes identical methods on the `Rc` types as well.,HEART,2021-04-01T04:41:41Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/83482,MERGED,2021-03-25T18:46:42Z,2021-04-11T22:11:30Z,Allow using `-C force-unwind-tables=no` when `panic=unwind`,NA,NA,NA,NA,THUMBS_UP,2021-03-30T20:39:23Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/83489,MERGED,2021-03-25T20:59:32Z,2021-04-06T02:09:06Z,Properly suggest deref in else block,LeSeulArtichaut,d9f123a5ae88a519bd13600e13a2a71555415467,3,Rollup merge of #83489 - LeSeulArtichaut:deref-else r=davidtwco Properly suggest deref in else block Continues #79755 fixes #79736 r? `@davidtwco`,HEART,2021-03-25T22:35:45Z,camelid,NA https://github.com/rust-lang/rust/pull/83493,OPEN,2021-03-25T21:43:57Z,NA,Add `impl Into for Infallible`,faern,NA,NA,NA,EYES,2021-03-25T22:13:39Z,marmeladema,NA https://github.com/rust-lang/rust/pull/83493,OPEN,2021-03-25T21:43:57Z,NA,Add `impl Into for Infallible`,faern,NA,NA,NA,THUMBS_UP,2021-04-10T09:43:38Z,Schuwi,NA https://github.com/rust-lang/rust/pull/83493,OPEN,2021-03-25T21:43:57Z,NA,Add `impl Into for Infallible`,faern,NA,NA,NA,THUMBS_UP,2021-04-15T22:24:15Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/83493,OPEN,2021-03-25T21:43:57Z,NA,Add `impl Into for Infallible`,faern,NA,NA,NA,EYES,2021-08-19T11:35:43Z,hexagonrecursion,hexagon-recursion@posteo.net https://github.com/rust-lang/rust/pull/83501,MERGED,2021-03-25T23:57:55Z,2021-05-12T01:09:39Z,rustdoc: Add unstable CLI option to show basic type layout information,camelid,40be1d3152542470ec5955a1bd03de4e2c87053d,7,Rollup merge of #83501 - camelid:rustdoc-layout r=jyn514 GuillaumeGomez rustdoc: Add unstable CLI option to show basic type layout information Closes #75988. Right now it just shows the size.,HOORAY,2021-04-22T15:10:48Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83501,MERGED,2021-03-25T23:57:55Z,2021-05-12T01:09:39Z,rustdoc: Add unstable CLI option to show basic type layout information,camelid,40be1d3152542470ec5955a1bd03de4e2c87053d,7,Rollup merge of #83501 - camelid:rustdoc-layout r=jyn514 GuillaumeGomez rustdoc: Add unstable CLI option to show basic type layout information Closes #75988. Right now it just shows the size.,THUMBS_UP,2021-04-22T15:49:57Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83501,MERGED,2021-03-25T23:57:55Z,2021-05-12T01:09:39Z,rustdoc: Add unstable CLI option to show basic type layout information,camelid,40be1d3152542470ec5955a1bd03de4e2c87053d,7,Rollup merge of #83501 - camelid:rustdoc-layout r=jyn514 GuillaumeGomez rustdoc: Add unstable CLI option to show basic type layout information Closes #75988. Right now it just shows the size.,HOORAY,2021-07-06T08:17:35Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83507,MERGED,2021-03-26T04:32:10Z,2021-05-06T17:42:37Z,Implement RFC 2951: Native link modifiers,luqmana,5dcdeb81e16c9debbf142f8e31d635b0c1149255,38,Rollup merge of #83507 - luqmana:native-link-modifiers r=petrochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing https://github.com/rust-lang/rfcs/pull/2951 / https://github.com/rust-lang/compiler-team/issues/356. Tracking Issue: https://github.com/rust-lang/rust/issues/81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed bundle verbatim whole_archive}`). r? `@petrochenkov`,HOORAY,2021-03-26T08:19:05Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/83507,MERGED,2021-03-26T04:32:10Z,2021-05-06T17:42:37Z,Implement RFC 2951: Native link modifiers,luqmana,5dcdeb81e16c9debbf142f8e31d635b0c1149255,38,Rollup merge of #83507 - luqmana:native-link-modifiers r=petrochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing https://github.com/rust-lang/rfcs/pull/2951 / https://github.com/rust-lang/compiler-team/issues/356. Tracking Issue: https://github.com/rust-lang/rust/issues/81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed bundle verbatim whole_archive}`). r? `@petrochenkov`,THUMBS_UP,2021-03-30T19:25:48Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/83507,MERGED,2021-03-26T04:32:10Z,2021-05-06T17:42:37Z,Implement RFC 2951: Native link modifiers,luqmana,5dcdeb81e16c9debbf142f8e31d635b0c1149255,38,Rollup merge of #83507 - luqmana:native-link-modifiers r=petrochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing https://github.com/rust-lang/rfcs/pull/2951 / https://github.com/rust-lang/compiler-team/issues/356. Tracking Issue: https://github.com/rust-lang/rust/issues/81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed bundle verbatim whole_archive}`). r? `@petrochenkov`,THUMBS_UP,2021-04-16T07:35:29Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/83507,MERGED,2021-03-26T04:32:10Z,2021-05-06T17:42:37Z,Implement RFC 2951: Native link modifiers,luqmana,5dcdeb81e16c9debbf142f8e31d635b0c1149255,38,Rollup merge of #83507 - luqmana:native-link-modifiers r=petrochenkov Implement RFC 2951: Native link modifiers A first attempt at implementing https://github.com/rust-lang/rfcs/pull/2951 / https://github.com/rust-lang/compiler-team/issues/356. Tracking Issue: https://github.com/rust-lang/rust/issues/81490 Introduces feature flags for the general syntax (`native_link_modifiers`) and each modifier (`native_link_modifiers_{as_needed bundle verbatim whole_archive}`). r? `@petrochenkov`,HOORAY,2021-10-23T16:20:16Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/83515,MERGED,2021-03-26T14:54:00Z,2021-06-08T03:47:15Z,String::remove_matches O(n^2) -> O(n),tamird,dda4a881e006c808093543eece098565c3142c46,1,Auto merge of #83515 - tamird:string-remove-matches-rev r=m-ou-se String::remove_matches O(n^2) -> O(n) Copy only non-matching bytes. Replace collection of matches into a vector with iteration over rejections exploiting the guarantee that we mutate parts of the haystack that have already been searched over. r? `@joshtriplett`,THUMBS_UP,2021-06-05T15:43:02Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/83515,MERGED,2021-03-26T14:54:00Z,2021-06-08T03:47:15Z,String::remove_matches O(n^2) -> O(n),tamird,dda4a881e006c808093543eece098565c3142c46,1,Auto merge of #83515 - tamird:string-remove-matches-rev r=m-ou-se String::remove_matches O(n^2) -> O(n) Copy only non-matching bytes. Replace collection of matches into a vector with iteration over rejections exploiting the guarantee that we mutate parts of the haystack that have already been searched over. r? `@joshtriplett`,THUMBS_UP,2021-06-07T11:47:38Z,ahlinc,NA https://github.com/rust-lang/rust/pull/83519,MERGED,2021-03-26T16:32:38Z,2021-04-24T20:09:30Z,Implement a lint that highlights all moves larger than a configured limit,oli-obk,e109aa3613f89bd0a440a9a947c405dcfcc0dc28,13,"Rollup merge of #83519 - oli-obk:assign_shrink_your_normal_code r=pnkfelix Implement a lint that highlights all moves larger than a configured limit Tracking issue: #83518 [MCP 420](https://github.com/rust-lang/compiler-team/issues/420) still ~blazing~ in progress r? ```@pnkfelix``` The main open issue I see with this minimal impl of the feature is that the lint is immediately ""stable"" (so it can be named on stable) even if it is never executed on stable. I don't think we have the concept of unstable lint names or hiding lint names without an active feature gate so that would be a bigger change.",EYES,2021-04-07T22:44:31Z,marmeladema,NA https://github.com/rust-lang/rust/pull/83524,MERGED,2021-03-26T18:52:09Z,2021-03-27T10:40:23Z,Document that the SocketAddr memory representation is not stable,faern,d340f63cca38b433b6ccc2a96776e67caeedfda4,1,Rollup merge of #83524 - faern:document-socketaddr-mem-layout r=sfackler Document that the SocketAddr memory representation is not stable Intended to help out with #78802. Work has been put into finding and fixing code that assumes the memory layout of `SocketAddrV4` and `SocketAddrV6`. But it turns out there are cases where new code continues to make the same assumption ([example](https://github.com/spacejam/seaslug/commit/96927dc2b7b918860a79c4eb6336051e52c6137a#diff-917db3d8ca6f862ebf42726b23c72a12b35e584e497ebdb24e474348d7c6ffb6R610-R621)). The memory layout of a type in `std` is never part of the public API. Unless explicitly stated I guess. But since that is invalidly relied upon by a considerable amount of code for these particular types it might make sense to explicitly document this. This can be temporary. Once #78802 lands it does not make sense to rely on the layout any longer and this documentation can also be removed.,THUMBS_UP,2021-03-27T11:41:48Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/83524,MERGED,2021-03-26T18:52:09Z,2021-03-27T10:40:23Z,Document that the SocketAddr memory representation is not stable,faern,d340f63cca38b433b6ccc2a96776e67caeedfda4,1,Rollup merge of #83524 - faern:document-socketaddr-mem-layout r=sfackler Document that the SocketAddr memory representation is not stable Intended to help out with #78802. Work has been put into finding and fixing code that assumes the memory layout of `SocketAddrV4` and `SocketAddrV6`. But it turns out there are cases where new code continues to make the same assumption ([example](https://github.com/spacejam/seaslug/commit/96927dc2b7b918860a79c4eb6336051e52c6137a#diff-917db3d8ca6f862ebf42726b23c72a12b35e584e497ebdb24e474348d7c6ffb6R610-R621)). The memory layout of a type in `std` is never part of the public API. Unless explicitly stated I guess. But since that is invalidly relied upon by a considerable amount of code for these particular types it might make sense to explicitly document this. This can be temporary. Once #78802 lands it does not make sense to rely on the layout any longer and this documentation can also be removed.,THUMBS_UP,2021-03-30T09:50:06Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,THUMBS_UP,2021-03-27T06:00:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,THUMBS_UP,2021-03-27T09:15:26Z,Zerotask,NA https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,THUMBS_UP,2021-03-27T10:48:53Z,est31,NA https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,HEART,2021-03-27T12:25:33Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,HEART,2021-04-01T18:57:31Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,THUMBS_UP,2021-04-03T13:07:44Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,HEART,2021-05-26T13:41:01Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83536,CLOSED,2021-03-26T22:53:32Z,2021-07-03T17:33:17Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,NA,NA,NA,THUMBS_UP,2021-05-26T13:41:03Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83555,MERGED,2021-03-27T11:14:09Z,2021-03-27T22:19:07Z,Add #[inline] to io::Error methods,m-ou-se,7d6af6751c5726d884440d4e8d462a9ee6c5efc1,1,Rollup merge of #83555 - m-ou-se:inline-io-error-new-const r=jackh726 Add #[inline] to io::Error methods Fixes #82812,HEART,2021-03-27T12:25:07Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83555,MERGED,2021-03-27T11:14:09Z,2021-03-27T22:19:07Z,Add #[inline] to io::Error methods,m-ou-se,7d6af6751c5726d884440d4e8d462a9ee6c5efc1,1,Rollup merge of #83555 - m-ou-se:inline-io-error-new-const r=jackh726 Add #[inline] to io::Error methods Fixes #82812,HEART,2021-03-27T13:10:37Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/83558,MERGED,2021-03-27T12:30:18Z,2021-03-27T19:04:33Z,Use DebugStruct::finish_non_exhaustive() in std.,m-ou-se,53cc8065a001e0a488b15e39ada2c01012549988,8,Rollup merge of #83558 - m-ou-se:use-finish-non-exhaustive r=jackh726 Use DebugStruct::finish_non_exhaustive() in std. See https://github.com/rust-lang/rust/issues/67364,ROCKET,2021-04-22T18:03:35Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-03-29T02:43:26Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-03-29T03:42:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-04-01T17:27:14Z,darksv,NA https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-04-03T11:25:58Z,D1mon,NA https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-04-16T00:01:13Z,davystrong,NA https://github.com/rust-lang/rust/pull/83576,CLOSED,2021-03-27T17:55:13Z,2021-05-09T21:36:09Z,Add `core::array::from_fn`,CryZe,NA,NA,NA,THUMBS_UP,2021-05-07T12:55:25Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/83579,MERGED,2021-03-27T18:33:28Z,2021-03-30T14:26:05Z,Improve pointer arithmetic docs,RalfJung,5b67543c981d13233b2f4f2004b7de8abf279d54,3,"Rollup merge of #83579 - RalfJung:ptr-arithmetic r=dtolnay Improve pointer arithmetic docs * Add slightly more detailed definition of ""allocated object"" to the module docs and link it from everywhere. * Clarify the ""remains attached"" wording a bit (at least I hope this is clearer). * Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct. As usual the edit needs to be done in a dozen places to remain consistent I hope I got them all.",THUMBS_UP,2021-03-27T20:55:22Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/83579,MERGED,2021-03-27T18:33:28Z,2021-03-30T14:26:05Z,Improve pointer arithmetic docs,RalfJung,5b67543c981d13233b2f4f2004b7de8abf279d54,3,"Rollup merge of #83579 - RalfJung:ptr-arithmetic r=dtolnay Improve pointer arithmetic docs * Add slightly more detailed definition of ""allocated object"" to the module docs and link it from everywhere. * Clarify the ""remains attached"" wording a bit (at least I hope this is clearer). * Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct. As usual the edit needs to be done in a dozen places to remain consistent I hope I got them all.",HEART,2021-03-27T21:14:02Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/83579,MERGED,2021-03-27T18:33:28Z,2021-03-30T14:26:05Z,Improve pointer arithmetic docs,RalfJung,5b67543c981d13233b2f4f2004b7de8abf279d54,3,"Rollup merge of #83579 - RalfJung:ptr-arithmetic r=dtolnay Improve pointer arithmetic docs * Add slightly more detailed definition of ""allocated object"" to the module docs and link it from everywhere. * Clarify the ""remains attached"" wording a bit (at least I hope this is clearer). * Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct. As usual the edit needs to be done in a dozen places to remain consistent I hope I got them all.",THUMBS_UP,2021-03-28T19:35:01Z,elichai,NA https://github.com/rust-lang/rust/pull/83592,MERGED,2021-03-27T22:51:56Z,2021-04-06T04:35:29Z,Set dso_local for hidden private and local items,nagisa,0c7d4effd71f826abb9651419c316b9b57b8ac97,30,Auto merge of #83592 - nagisa:nagisa/dso_local r=davidtwco Set dso_local for hidden private and local items This should probably have no real effect in most cases as e.g. `hidden` visibility already implies `dso_local` (or at least LLVM IR does not preserve the `dso_local` setting if the item is already `hidden`) but it should fix `-Crelocation-model=static` and improve codegen in executables. Note that this PR does not exhaustively port the logic in [clang] only the portion that is necessary to fix a regression from LLVM 12 that relates to `-Crelocation_model=static`. Fixes #83335 [clang]: https://github.com/llvm/llvm-project/blob/3001d080c813da20b329303bf8f45451480e5905/clang/lib/CodeGen/CodeGenModule.cpp#L945-L1039,HEART,2021-03-31T11:56:09Z,ojeda,NA https://github.com/rust-lang/rust/pull/83592,MERGED,2021-03-27T22:51:56Z,2021-04-06T04:35:29Z,Set dso_local for hidden private and local items,nagisa,0c7d4effd71f826abb9651419c316b9b57b8ac97,30,Auto merge of #83592 - nagisa:nagisa/dso_local r=davidtwco Set dso_local for hidden private and local items This should probably have no real effect in most cases as e.g. `hidden` visibility already implies `dso_local` (or at least LLVM IR does not preserve the `dso_local` setting if the item is already `hidden`) but it should fix `-Crelocation-model=static` and improve codegen in executables. Note that this PR does not exhaustively port the logic in [clang] only the portion that is necessary to fix a regression from LLVM 12 that relates to `-Crelocation_model=static`. Fixes #83335 [clang]: https://github.com/llvm/llvm-project/blob/3001d080c813da20b329303bf8f45451480e5905/clang/lib/CodeGen/CodeGenModule.cpp#L945-L1039,HEART,2021-04-06T07:05:12Z,sthagen,NA https://github.com/rust-lang/rust/pull/83605,MERGED,2021-03-28T10:56:21Z,2021-03-29T02:58:33Z,unaligned_references: align(N) fields in packed(N) structs are fine,RalfJung,cc4103089f40a163f6d143f06359cba7043da29b,7,"Auto merge of #83605 - RalfJung:unaligned r=petrochenkov unaligned_references: align(N) fields in packed(N) structs are fine This removes some false positives from the unaligned_references lint: in a `repr(packed(2))` struct fields of alignment 2 (and less) are guaranteed to be properly aligned so we do not have to consider them ""disaligned"".",HEART,2022-01-19T05:31:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83634,MERGED,2021-03-29T08:17:59Z,2021-04-07T18:02:23Z,Do not emit the advanced diagnostics on macros,JohnTitor,2c55bacfbf5bfdf3f38a21cbda41bd8a3439fdd6,4,Rollup merge of #83634 - JohnTitor:proc-macro-ice r=varkor Do not emit the advanced diagnostics on macros Fixes #83510,THUMBS_UP,2021-03-29T15:48:09Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83637,MERGED,2021-03-29T08:53:07Z,2021-03-29T14:01:45Z,Sync rustc_codegen_cranelift,bjorn3,3aedcf06b73fc36feeebca3d579e1d2a6c40acc5,49,Auto merge of #83637 - bjorn3:sync_cg_clif-2021-03-29 r=bjorn3 Sync rustc_codegen_cranelift The main highlight of this sync is support for cross-compiling to Windows using MinGW. Native compilation with MinGW would also work I think but using the MSVC toolchain is not yet supported as PE TLS is not yet implemented. Another nice improvement is that crate metadata is now loaded using mmap instead of by reading files. This improves compilation time a bit. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler,HOORAY,2021-03-29T15:50:41Z,mati865,NA https://github.com/rust-lang/rust/pull/83640,MERGED,2021-03-29T09:50:02Z,2021-05-14T15:40:30Z,Use the object crate for metadata reading,bjorn3,75da570d784a798a34ff1e5048cd9a6a2fb23170,10,Auto merge of #83640 - bjorn3:shared_metadata_reader r=nagisa Use the object crate for metadata reading This allows sharing the metadata reader between cg_llvm cg_clif and other codegen backends. This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)` The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata but I am not certain. If this happens to not be the case I could keep using LLVM for reading dylib metadata. Marked as WIP for a perf run and as it is based on #83637.,HOORAY,2021-03-29T13:23:06Z,mati865,NA https://github.com/rust-lang/rust/pull/83640,MERGED,2021-03-29T09:50:02Z,2021-05-14T15:40:30Z,Use the object crate for metadata reading,bjorn3,75da570d784a798a34ff1e5048cd9a6a2fb23170,10,Auto merge of #83640 - bjorn3:shared_metadata_reader r=nagisa Use the object crate for metadata reading This allows sharing the metadata reader between cg_llvm cg_clif and other codegen backends. This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)` The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata but I am not certain. If this happens to not be the case I could keep using LLVM for reading dylib metadata. Marked as WIP for a perf run and as it is based on #83637.,HOORAY,2021-05-14T16:38:00Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83646,MERGED,2021-03-29T14:38:05Z,2021-06-05T21:10:03Z,Add a map method to Bound,glittershark,15940767481e82594b7d1c8fb4805521e681f854,1,Rollup merge of #83646 - glittershark:bound-map r=m-ou-se Add a map method to Bound Add a map method to std::ops::range::Bound patterned off of the method of the same name on Option. Have left off creating a tracking issue initially but as soon as I get the go-ahead from a reviewer I'll make that right away 😄,THUMBS_UP,2021-03-29T14:38:49Z,eeeeeta,github@eta.st https://github.com/rust-lang/rust/pull/83647,CLOSED,2021-03-29T15:37:04Z,2021-07-08T20:10:17Z,make `Sized` predicates coinductive,lcnr,NA,NA,NA,LAUGH,2021-03-29T15:45:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/83647,CLOSED,2021-03-29T15:37:04Z,2021-07-08T20:10:17Z,make `Sized` predicates coinductive,lcnr,NA,NA,NA,LAUGH,2021-03-29T22:57:26Z,sivizius,NA https://github.com/rust-lang/rust/pull/83647,CLOSED,2021-03-29T15:37:04Z,2021-07-08T20:10:17Z,make `Sized` predicates coinductive,lcnr,NA,NA,NA,EYES,2021-03-29T22:59:07Z,sivizius,NA https://github.com/rust-lang/rust/pull/83647,CLOSED,2021-03-29T15:37:04Z,2021-07-08T20:10:17Z,make `Sized` predicates coinductive,lcnr,NA,NA,NA,LAUGH,2021-03-30T02:00:16Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2021-03-30T19:04:28Z,Aankhen,NA https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2021-08-08T03:31:11Z,yerke,NA https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2021-08-08T20:24:46Z,kassane,matheus-catarino@hotmail.com https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2021-08-09T10:22:55Z,lcpl96,NA https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2021-08-09T16:26:24Z,iamGBOX,NA https://github.com/rust-lang/rust/pull/83652,MERGED,2021-03-29T17:05:17Z,2021-03-30T22:15:42Z,Disallow octal format in Ipv4 string,xu-cheng,74874a690bc95443292496ff5df5cc5c8cb56e0b,3,Auto merge of #83652 - xu-cheng:ipv4-octal r=sfackler Disallow octal format in Ipv4 string In its original specification leading zero in Ipv4 string is interpreted as octal literals. So a IP address 0127.0.0.1 actually means 87.0.0.1. This confusion can lead to many security vulnerabilities. Therefore in [IETF RFC 6943] it suggests to disallow octal/hexadecimal format in Ipv4 string all together. Existing implementation already disallows hexadecimal numbers. This commit makes Parser reject octal numbers. Fixes #83648. [IETF RFC 6943]: https://tools.ietf.org/html/rfc6943#section-3.1.1,HOORAY,2022-04-19T06:09:14Z,JTellington,jtellington1990@gmail.com https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-03-29T21:34:13Z,bluss,NA https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-03-29T21:40:35Z,aud,NA https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-03-29T22:34:26Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-04-01T11:52:45Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-04-02T06:35:16Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/83663,MERGED,2021-03-29T21:27:13Z,2021-04-02T03:39:32Z,Simplify logical operations CFG,AngelicosPhosphoros,d1065e6cefa41fe6c55c9819552cdd61529096fc,8,Auto merge of #83663 - AngelicosPhosphoros:simplify_binary_and_to_get_better_asm r=nagisa Simplify logical operations CFG This is basically same commit as e38e954a0d249f88d0a55504f70d6055e865a931 which was reverted later in 676953fde9120cda62e4ef2f75a804af7481d6af In both cases this changes weren't benchmarked. e38e954a0d249f88d0a55504f70d6055e865a931 leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/62993) 676953fde9120cda62e4ef2f75a804af7481d6af leads to missed optimization described in [this issue](https://github.com/rust-lang/rust/issues/83623),HEART,2021-04-09T06:57:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-03-30T06:04:58Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-03-30T06:45:13Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-03-30T07:14:22Z,taiki-e,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-03-31T19:27:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-04-07T12:16:08Z,daira,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-04-08T18:48:27Z,tux3,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,HEART,2021-04-08T18:48:31Z,tux3,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-04-09T06:53:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,HEART,2021-04-09T13:53:10Z,jplatte,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-04-09T19:37:50Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,THUMBS_UP,2021-04-10T17:19:21Z,g2p,NA https://github.com/rust-lang/rust/pull/83667,MERGED,2021-03-30T01:25:58Z,2021-03-30T14:26:04Z,Suggest box/pin/arc ing receiver on method calls,estebank,5b467787b625d83d5cf210e70d56487e53ce4255,20,Rollup merge of #83667 - estebank:cool-bears-hot-tip r=lcnr Suggest box/pin/arc ing receiver on method calls _Extracted from https://fasterthanli.me/articles/pin-and-suffering_,HEART,2021-04-10T17:19:24Z,g2p,NA https://github.com/rust-lang/rust/pull/83669,MERGED,2021-03-30T03:08:22Z,2021-04-12T03:13:23Z,Issue 81508 fix,kwj2104,b6780b3a20ad9f482911119eee84b0ad5a495af6,4,Rollup merge of #83669 - kwj2104:issue-81508-fix r=varkor Issue 81508 fix Fix #81508 **Problem**: When variable name is used incorrectly as path error and warning point to undeclared/unused name when in fact the name is used just incorrectly (should be used as a variable not part of a path). **Summary for fix**: When path resolution errs diagnostics checks for variables in ```ValueNS``` that have the same name (e.g. variable rather than path named Foo) and adds additional suggestion that user may actually intend to use the variable name rather than a path. The fix does not suppress or otherwise change the *warning* that results. I did not find a straightforward way in the code to modify this but would love to make changes here as well with any guidance.,HEART,2021-04-12T03:14:20Z,henryboisdequin,boisdequinhenry19@gmail.com https://github.com/rust-lang/rust/pull/83676,CLOSED,2021-03-30T13:26:31Z,2021-04-01T06:02:46Z,Deprecate #![crate_type] and #![crate_name],bjorn3,NA,NA,NA,THUMBS_UP,2021-03-30T13:38:03Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/83684,MERGED,2021-03-30T18:32:55Z,2021-03-31T10:54:49Z,Remove hir::CrateItem.,cjgillot,a5029ac0ab372aec515db2e718da6d7787f3d122,17,Auto merge of #83684 - cjgillot:csp r=petrochenkov Remove hir::CrateItem. The crate span is exactly the crate module's inner span. There is no need to store it twice.,THUMBS_UP,2021-03-30T19:15:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83698,MERGED,2021-03-31T05:35:56Z,2021-08-26T13:30:19Z,Use undef for uninitialized bytes in constants,erikdesjardins,20997f6ad81721542e9ef97bb2f58190903a34d8,9,"Auto merge of #83698 - erikdesjardins:undefconst r=RalfJung oli-obk Use undef for uninitialized bytes in constants Fixes #83657 This generates good code when the const is fully uninit e.g. ```rust #[no_mangle] pub const fn fully_uninit() -> MaybeUninit<[u8; 10]> { const M: MaybeUninit<[u8; 10]> = MaybeUninit::uninit(); M } ``` generates ```asm fully_uninit: ret ``` as you would expect. There is no improvement however when it's partially uninit e.g. ```rust pub struct PartiallyUninit { x: u64 y: MaybeUninit<[u8; 10]> } #[no_mangle] pub const fn partially_uninit() -> PartiallyUninit { const X: PartiallyUninit = PartiallyUninit { x: 0xdeadbeefcafe y: MaybeUninit::uninit() }; X } ``` generates ```asm partially_uninit: mov rax rdi mov rcx qword ptr [rip + .L__unnamed_1+16] mov qword ptr [rdi + 16] rcx movups xmm0 xmmword ptr [rip + .L__unnamed_1] movups xmmword ptr [rdi] xmm0 ret .L__unnamed_1: .asciz ""\376\312\357\276\255\336\000"" .zero 16 .size .L__unnamed_1 24 ``` which copies a bunch of zeros in place of the undef bytes the same as before this change. Edit: generating partially-undef constants isn't viable at the moment anyways due to #84565 so it's disabled",EYES,2021-03-31T08:02:44Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/83698,MERGED,2021-03-31T05:35:56Z,2021-08-26T13:30:19Z,Use undef for uninitialized bytes in constants,erikdesjardins,20997f6ad81721542e9ef97bb2f58190903a34d8,9,"Auto merge of #83698 - erikdesjardins:undefconst r=RalfJung oli-obk Use undef for uninitialized bytes in constants Fixes #83657 This generates good code when the const is fully uninit e.g. ```rust #[no_mangle] pub const fn fully_uninit() -> MaybeUninit<[u8; 10]> { const M: MaybeUninit<[u8; 10]> = MaybeUninit::uninit(); M } ``` generates ```asm fully_uninit: ret ``` as you would expect. There is no improvement however when it's partially uninit e.g. ```rust pub struct PartiallyUninit { x: u64 y: MaybeUninit<[u8; 10]> } #[no_mangle] pub const fn partially_uninit() -> PartiallyUninit { const X: PartiallyUninit = PartiallyUninit { x: 0xdeadbeefcafe y: MaybeUninit::uninit() }; X } ``` generates ```asm partially_uninit: mov rax rdi mov rcx qword ptr [rip + .L__unnamed_1+16] mov qword ptr [rdi + 16] rcx movups xmm0 xmmword ptr [rip + .L__unnamed_1] movups xmmword ptr [rdi] xmm0 ret .L__unnamed_1: .asciz ""\376\312\357\276\255\336\000"" .zero 16 .size .L__unnamed_1 24 ``` which copies a bunch of zeros in place of the undef bytes the same as before this change. Edit: generating partially-undef constants isn't viable at the moment anyways due to #84565 so it's disabled",HEART,2021-03-31T08:56:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/83698,MERGED,2021-03-31T05:35:56Z,2021-08-26T13:30:19Z,Use undef for uninitialized bytes in constants,erikdesjardins,20997f6ad81721542e9ef97bb2f58190903a34d8,9,"Auto merge of #83698 - erikdesjardins:undefconst r=RalfJung oli-obk Use undef for uninitialized bytes in constants Fixes #83657 This generates good code when the const is fully uninit e.g. ```rust #[no_mangle] pub const fn fully_uninit() -> MaybeUninit<[u8; 10]> { const M: MaybeUninit<[u8; 10]> = MaybeUninit::uninit(); M } ``` generates ```asm fully_uninit: ret ``` as you would expect. There is no improvement however when it's partially uninit e.g. ```rust pub struct PartiallyUninit { x: u64 y: MaybeUninit<[u8; 10]> } #[no_mangle] pub const fn partially_uninit() -> PartiallyUninit { const X: PartiallyUninit = PartiallyUninit { x: 0xdeadbeefcafe y: MaybeUninit::uninit() }; X } ``` generates ```asm partially_uninit: mov rax rdi mov rcx qword ptr [rip + .L__unnamed_1+16] mov qword ptr [rdi + 16] rcx movups xmm0 xmmword ptr [rip + .L__unnamed_1] movups xmmword ptr [rdi] xmm0 ret .L__unnamed_1: .asciz ""\376\312\357\276\255\336\000"" .zero 16 .size .L__unnamed_1 24 ``` which copies a bunch of zeros in place of the undef bytes the same as before this change. Edit: generating partially-undef constants isn't viable at the moment anyways due to #84565 so it's disabled",HEART,2021-04-01T00:02:21Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83707,MERGED,2021-03-31T16:15:47Z,2021-04-13T14:03:34Z,Remove `T: Debug` bound on UnsafeCell Debug impl,exrook,1cc4b6de3e43aeae295d4aac70cb41e37201c516,1,Rollup merge of #83707 - exrook:unsafecell r=m-ou-se Remove `T: Debug` bound on UnsafeCell Debug impl Prior art: #65013,THUMBS_UP,2021-04-10T00:09:23Z,GrayJack,NA https://github.com/rust-lang/rust/pull/83707,MERGED,2021-03-31T16:15:47Z,2021-04-13T14:03:34Z,Remove `T: Debug` bound on UnsafeCell Debug impl,exrook,1cc4b6de3e43aeae295d4aac70cb41e37201c516,1,Rollup merge of #83707 - exrook:unsafecell r=m-ou-se Remove `T: Debug` bound on UnsafeCell Debug impl Prior art: #65013,THUMBS_UP,2021-04-12T02:57:23Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83721,MERGED,2021-03-31T20:16:17Z,2021-04-02T15:14:55Z,"Add a button to copy the ""use statement""",GuillaumeGomez,080aa37629c123e0f9096de3726f66d80d635be7,8,"Rollup merge of #83721 - GuillaumeGomez:copy-use r=Nemo157 Add a button to copy the ""use statement"" Fixes https://github.com/rust-lang/rust/issues/50239 When clicking on the button it'll add the elements prepended by ""use "" and will end with a "";"". So in the images below I now have in my clipboard `use std::fs::OpenOptions;`. A screenshot of the newly added button: ![Screenshot from 2021-03-31 22-12-12](https://user-images.githubusercontent.com/3050060/113205430-90e64500-926e-11eb-8538-529829f611ec.png) A screenshot after it was clicked: ![Screenshot from 2021-03-31 22-15-31](https://user-images.githubusercontent.com/3050060/113205532-ad827d00-926e-11eb-893d-35f2f8f92696.png) r? `@Nemo157`",HEART,2021-03-31T20:37:46Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/83721,MERGED,2021-03-31T20:16:17Z,2021-04-02T15:14:55Z,"Add a button to copy the ""use statement""",GuillaumeGomez,080aa37629c123e0f9096de3726f66d80d635be7,8,"Rollup merge of #83721 - GuillaumeGomez:copy-use r=Nemo157 Add a button to copy the ""use statement"" Fixes https://github.com/rust-lang/rust/issues/50239 When clicking on the button it'll add the elements prepended by ""use "" and will end with a "";"". So in the images below I now have in my clipboard `use std::fs::OpenOptions;`. A screenshot of the newly added button: ![Screenshot from 2021-03-31 22-12-12](https://user-images.githubusercontent.com/3050060/113205430-90e64500-926e-11eb-8538-529829f611ec.png) A screenshot after it was clicked: ![Screenshot from 2021-03-31 22-15-31](https://user-images.githubusercontent.com/3050060/113205532-ad827d00-926e-11eb-893d-35f2f8f92696.png) r? `@Nemo157`",HEART,2021-04-01T05:57:35Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/83721,MERGED,2021-03-31T20:16:17Z,2021-04-02T15:14:55Z,"Add a button to copy the ""use statement""",GuillaumeGomez,080aa37629c123e0f9096de3726f66d80d635be7,8,"Rollup merge of #83721 - GuillaumeGomez:copy-use r=Nemo157 Add a button to copy the ""use statement"" Fixes https://github.com/rust-lang/rust/issues/50239 When clicking on the button it'll add the elements prepended by ""use "" and will end with a "";"". So in the images below I now have in my clipboard `use std::fs::OpenOptions;`. A screenshot of the newly added button: ![Screenshot from 2021-03-31 22-12-12](https://user-images.githubusercontent.com/3050060/113205430-90e64500-926e-11eb-8538-529829f611ec.png) A screenshot after it was clicked: ![Screenshot from 2021-03-31 22-15-31](https://user-images.githubusercontent.com/3050060/113205532-ad827d00-926e-11eb-893d-35f2f8f92696.png) r? `@Nemo157`",HEART,2021-04-07T15:52:36Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83721,MERGED,2021-03-31T20:16:17Z,2021-04-02T15:14:55Z,"Add a button to copy the ""use statement""",GuillaumeGomez,080aa37629c123e0f9096de3726f66d80d635be7,8,"Rollup merge of #83721 - GuillaumeGomez:copy-use r=Nemo157 Add a button to copy the ""use statement"" Fixes https://github.com/rust-lang/rust/issues/50239 When clicking on the button it'll add the elements prepended by ""use "" and will end with a "";"". So in the images below I now have in my clipboard `use std::fs::OpenOptions;`. A screenshot of the newly added button: ![Screenshot from 2021-03-31 22-12-12](https://user-images.githubusercontent.com/3050060/113205430-90e64500-926e-11eb-8538-529829f611ec.png) A screenshot after it was clicked: ![Screenshot from 2021-03-31 22-15-31](https://user-images.githubusercontent.com/3050060/113205532-ad827d00-926e-11eb-893d-35f2f8f92696.png) r? `@Nemo157`",HEART,2021-07-11T20:24:06Z,Sparrrgh,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",HEART,2021-04-01T00:06:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-01T02:41:21Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-01T06:48:58Z,oilaba,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-01T14:33:27Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-02T19:41:40Z,connorskees,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-02T22:45:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",HEART,2021-04-29T10:03:30Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-04-29T20:18:45Z,billyfbrain,NA https://github.com/rust-lang/rust/pull/83722,MERGED,2021-03-31T20:30:56Z,2021-04-24T04:54:21Z,On stable suggest removing `#![feature]` for features that have been stabilized,jyn514,a7aba58e9684175c5c5dfef8277c95ebc43f904a,1,"Auto merge of #83722 - jyn514:stable-help r=estebank On stable suggest removing `#![feature]` for features that have been stabilized I don't know how to test this (https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Run.20tests.20without.20enabling.20nightly.20features.3F). I confirmed locally that this gives the appropriate help with `channel = ""beta""`: ``` error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:2:1 | 2 | #![feature(min_const_generics)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove the attribute | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:3:1 | 3 | #![feature(min_const_generics min_specialization)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: the feature `min_const_generics` has been stable since 1.51.0 and no longer requires an attribute to enable error[E0554]: `#![feature]` may not be used on the beta release channel --> src/lib.rs:4:1 | 4 | #![feature(box_patterns)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ ``` Closes https://github.com/rust-lang/rust/issues/83715.",THUMBS_UP,2021-05-04T11:07:33Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83724,OPEN,2021-03-31T21:30:53Z,NA,Add targets that were missing in rustc,Sycration,NA,NA,NA,EYES,2021-04-30T03:24:52Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83724,OPEN,2021-03-31T21:30:53Z,NA,Add targets that were missing in rustc,Sycration,NA,NA,NA,EYES,2021-09-18T19:19:09Z,Sycration,NA https://github.com/rust-lang/rust/pull/83729,MERGED,2021-03-31T23:43:28Z,2021-04-24T02:25:55Z,Add a suggestion when using a type alias instead of trait alias,JohnTitor,8ad0821b035e35aed07ec252c2dd831c15a4e26e,9,Auto merge of #83729 - JohnTitor:issue-43913 r=estebank Add a suggestion when using a type alias instead of trait alias Fixes #43913 r? `@estebank`,THUMBS_UP,2021-04-01T03:28:51Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83736,MERGED,2021-04-01T01:57:54Z,2021-04-01T07:55:09Z,Fix the `unsafe_block_in_unsafe_fn`s stabilized version,JohnTitor,49e1ec09952c5ab7798addd29532d44dc020283f,1,Auto merge of #83736 - JohnTitor:fix-unsafe_block_in_unsafe_fn-stabilized-version r=jyn514 Fix the `unsafe_block_in_unsafe_fn`s stabilized version Fixes #83735,THUMBS_UP,2021-04-01T01:58:55Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/83744,MERGED,2021-04-01T10:17:29Z,2021-12-08T14:28:44Z,Deprecate crate_type and crate_name nested inside #![cfg_attr],bjorn3,da158c04c4945db9cbdf5bc362a5a137590ce455,6,"Rollup merge of #83744 - bjorn3:deprecate_cfg_attr_crate_type_name r=Mark-Simulacrum Deprecate crate_type and crate_name nested inside #![cfg_attr] This implements the proposal in https://github.com/rust-lang/rust/pull/83676#issuecomment-811213956 with a future compatibility lint imposed on usage of crate_type/crate_name inside cfg's. This is a compromise between removing `#![crate_type]` and `#![crate_name]` completely and keeping them as a whole which requires somewhat of a hack in rustc and is impossible to support by gcc-rust. By only removing `#![crate_type]` and `#![crate_name]` nested inside `#![cfg_attr]` it becomes possible to parse them before a big chunk of the compiler has started. Replaces https://github.com/rust-lang/rust/pull/83676 ```rust #![crate_type = ""lib""] // remains working #![cfg_attr(foo crate_type = ""bin"")] // will stop working ``` # Rationale As it currently is it is possible to try to access the stable crate id before it is actually set which will panic. The fact that the Session contains mutable state beyond debugging things also doesn't completely sit well with me. Especially once parallel rustc becomes the default. I think there is currently also a cyclic dependency where you need to set the stable crate id to be able to load crates but you need to load crates to expand proc macro attributes that may define #![crate_name] or #![crate_type]. Currently crate level proc macro attributes are unstable or completely unsupported (can't remember which) so this is not a problem but it may become an issue in the future. Finally if we want to add incremental compilation to macro expansion or even parsing we need the StableCrateId to be created together with the Session or even earlier as incremental compilation determines the incremental compilation session dir based on the StableCrateId.",THUMBS_UP,2021-04-01T21:44:14Z,est31,NA https://github.com/rust-lang/rust/pull/83748,OPEN,2021-04-01T13:09:07Z,NA,Add `dedup` `dedup_by` and `dedup_by_key` to the `Iterator` trait,slerpyyy,NA,NA,NA,HOORAY,2021-04-01T15:42:39Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/83748,OPEN,2021-04-01T13:09:07Z,NA,Add `dedup` `dedup_by` and `dedup_by_key` to the `Iterator` trait,slerpyyy,NA,NA,NA,HOORAY,2021-04-01T21:30:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83748,OPEN,2021-04-01T13:09:07Z,NA,Add `dedup` `dedup_by` and `dedup_by_key` to the `Iterator` trait,slerpyyy,NA,NA,NA,THUMBS_UP,2021-05-29T12:31:50Z,MaxVerevkin,NA https://github.com/rust-lang/rust/pull/83752,CLOSED,2021-04-01T19:32:47Z,2021-05-13T11:28:15Z,Sealed traits for primitive integers,tspiteri,NA,NA,NA,THUMBS_UP,2021-04-02T20:53:17Z,slightlyoutofphase,slightlyoutofphase@gmail.com https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,THUMBS_UP,2021-04-01T20:39:57Z,AngelicosPhosphoros,NA https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,HEART,2021-04-01T21:33:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,HEART,2021-04-02T00:27:49Z,tmandry,NA https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,HEART,2021-04-02T01:46:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,THUMBS_UP,2021-04-02T17:20:24Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/83755,MERGED,2021-04-01T20:27:12Z,2021-04-02T22:47:20Z,Simplify coverage tests,richkadel,70091171bd823cac1d3131cd6aea0f191d99a998,131,Rollup merge of #83755 - richkadel:cov-test-simplify r=tmandry Simplify coverage tests This change reduces the risk of impacting coverage tests on unrelated changes (such as MIR and Span changes) and reduces the burden when blessing coverage changes in case it is necessary. * Remove all spanview tests. The spanview tests were useful during development but they can be generated as needed via compiler command line flags. They aren't critical to confirming coverage results. (The coverage report tests are sufficient.) When spanview regeneration was necessary the diffs were way too hard to read to be useful anyway. So I'm removing them to reduce friction from a feature that is no longer useful. * Remove the requirement for `llvm-cov show --debug` when blessing tests. The `--debug` flag is unfortunately only available if LLVM is built with `optimize = false` (in Rust's config.toml). This adds significant time and resource burdens to the contributor's build. As it turns out for other reasons in the past I wasn't actually using the debug output (counter info) to validate coverage anymore either so it was required for no reason I now realize.,HEART,2021-04-02T17:20:25Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/83774,MERGED,2021-04-02T07:15:29Z,2021-04-03T08:46:07Z,Translate counters from Rust 1-based to LLVM 0-based counter ids,richkadel,836c31742687ba4e2f857b5b698e1e9e6b67619c,11,Auto merge of #83774 - richkadel:zero-based-counters r=tmandry Translate counters from Rust 1-based to LLVM 0-based counter ids A colleague contacted me and asked why Rust's counters start at 1 when Clangs appear to start at 0. There is a reason why Rust's internal counters start at 1 (see the docs) and I tried to keep them consistent when codegenned to LLVM's coverage mapping format. LLVM should be tolerant of missing counters but as my colleague pointed out `llvm-cov` will silently fail to generate a coverage report for a function based on LLVM's assumption that the counters are 0-based. See: https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170 Apparently if for example a function has no branches it would have exactly 1 counter. `CounterValues.size()` would be 1 and (with the 1-based index) the counter ID would be 1. This would fail the check and abort reporting coverage for the function. It turns out that by correcting for this during coverage map generation by subtracting 1 from the Rust Counter ID (both when generating the counter increment intrinsic call and when adding counters to the map) some uncovered functions (including in tests) now appear covered! This corrects the coverage for a few tests! r? `@tmandry` FYI: `@wesleywiser`,THUMBS_UP,2021-04-02T23:18:03Z,tmandry,NA https://github.com/rust-lang/rust/pull/83775,CLOSED,2021-04-02T07:28:18Z,2021-06-27T22:54:46Z,Move rustdoc run-make-fulldeps tests to run-make,jyn514,NA,NA,NA,HOORAY,2021-04-03T18:53:42Z,camelid,NA https://github.com/rust-lang/rust/pull/83775,CLOSED,2021-04-02T07:28:18Z,2021-06-27T22:54:46Z,Move rustdoc run-make-fulldeps tests to run-make,jyn514,NA,NA,NA,HOORAY,2021-04-13T01:56:36Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83776,MERGED,2021-04-02T08:13:40Z,2021-04-12T20:56:30Z,Update stdarch submodule (to before it switched to const generics),jyn514,d0695c9081b16077d0aed368bccaf437d77ff497,5,Auto merge of #83776 - jyn514:update-stdarch-docs r=Amanieu Update stdarch submodule (to before it switched to const generics) https://github.com/rust-lang/rust/pull/83278#issuecomment-812389823: This unblocks #82539. Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - std_detect is now a separate crate instead of a submodule of std. I double-checked and the first use of const generics looks like https://github.com/rust-lang/stdarch/commit/8d5017861ed594a2baf169e632379862d516e013 which isn't included in this PR. r? `@Amanieu`,HOORAY,2021-04-02T12:05:54Z,rrbutani,NA https://github.com/rust-lang/rust/pull/83776,MERGED,2021-04-02T08:13:40Z,2021-04-12T20:56:30Z,Update stdarch submodule (to before it switched to const generics),jyn514,d0695c9081b16077d0aed368bccaf437d77ff497,5,Auto merge of #83776 - jyn514:update-stdarch-docs r=Amanieu Update stdarch submodule (to before it switched to const generics) https://github.com/rust-lang/rust/pull/83278#issuecomment-812389823: This unblocks #82539. Major changes: - More AVX-512 intrinsics. - More ARM & AArch64 NEON intrinsics. - Updated unstable WASM intrinsics to latest draft standards. - std_detect is now a separate crate instead of a submodule of std. I double-checked and the first use of const generics looks like https://github.com/rust-lang/stdarch/commit/8d5017861ed594a2baf169e632379862d516e013 which isn't included in this PR. r? `@Amanieu`,HOORAY,2021-04-12T22:35:13Z,bluss,NA https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,EYES,2021-04-02T16:05:40Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,EYES,2021-04-02T18:18:29Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,HEART,2021-04-08T07:07:32Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,ROCKET,2021-04-08T07:07:36Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,HEART,2021-04-08T08:46:59Z,bluss,NA https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,HEART,2021-04-12T10:21:05Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,HEART,2021-07-10T05:52:45Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/83785,OPEN,2021-04-02T14:59:10Z,NA,[mir-opt] Optimize calls to CopyNonOverlapping,wesleywiser,NA,NA,NA,HEART,2022-01-14T00:01:53Z,mati865,NA https://github.com/rust-lang/rust/pull/83791,MERGED,2021-04-02T18:28:19Z,2021-11-27T17:36:07Z,Weaken guarantee around advancing underlying iterators in zip,the8472,14ef447d1237a2534f3acc19a2f986b217ef274d,1,Rollup merge of #83791 - the8472:relax-zip-side-effect-guarantee r=dtolnay Weaken guarantee around advancing underlying iterators in zip The current guarantee (introduced in #52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this. This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()` because removing it would also affect `next_back()` in more surprising ways. The intent is to be able to remove for example this branch https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/src/iter/adapters/zip.rs#L234-L243 or this test https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/tests/iter/adapters/zip.rs#L177-L188 Solves #82303 by declaring it a non-issue.,HEART,2021-04-02T19:04:23Z,SkiFire13,NA https://github.com/rust-lang/rust/pull/83791,MERGED,2021-04-02T18:28:19Z,2021-11-27T17:36:07Z,Weaken guarantee around advancing underlying iterators in zip,the8472,14ef447d1237a2534f3acc19a2f986b217ef274d,1,Rollup merge of #83791 - the8472:relax-zip-side-effect-guarantee r=dtolnay Weaken guarantee around advancing underlying iterators in zip The current guarantee (introduced in #52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this. This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()` because removing it would also affect `next_back()` in more surprising ways. The intent is to be able to remove for example this branch https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/src/iter/adapters/zip.rs#L234-L243 or this test https://github.com/rust-lang/rust/blob/36bcf4069717b9dff90270d13b53a3b130329960/library/core/tests/iter/adapters/zip.rs#L177-L188 Solves #82303 by declaring it a non-issue.,THUMBS_UP,2021-11-28T19:53:14Z,bluss,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-11T07:53:18Z,Pratyush,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-15T02:35:00Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-18T10:26:10Z,pyfisch,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-18T16:51:52Z,r00ster91,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,THUMBS_UP,2021-04-19T03:22:10Z,Zymlex,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-19T09:39:25Z,mvf,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-19T22:52:55Z,estebank,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-04-22T02:14:59Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,THUMBS_UP,2021-04-22T02:43:27Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-22T10:41:53Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-04-22T21:20:30Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,EYES,2021-04-22T21:20:35Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-04-29T01:25:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-05-16T16:19:06Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-05-20T12:01:46Z,mersinvald,git@mkl.dev https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-05-21T20:42:55Z,bluss,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-06-02T09:26:06Z,green-s,sam.green81@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-06-16T09:04:45Z,Narann,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-06-16T13:23:06Z,vittorioromeo,vittorio.romeo@outlook.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,THUMBS_UP,2021-06-16T14:17:48Z,tomasfarias,tomas@tomasfarias.dev https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,THUMBS_UP,2021-06-16T15:07:26Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-06-16T15:07:26Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-06-16T15:07:27Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,EYES,2021-06-16T15:07:27Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-06-17T10:34:49Z,GoldsteinE,root@goldstein.rs https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,EYES,2021-06-17T16:26:37Z,adrian5,NA https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,HOORAY,2021-06-18T17:05:31Z,bdbai,bdbaiapp@163.com https://github.com/rust-lang/rust/pull/83799,MERGED,2021-04-03T04:46:43Z,2021-04-19T01:59:24Z,Stablize `non-ascii-idents`,crlf0710,c4ba8e3e5fdd9aaf30d82e5a9cc22dcefb75a79d,57,Auto merge of #83799 - crlf0710:stablize_non_ascii_idents r=Manishearth Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`,CONFUSED,2021-06-25T17:07:50Z,jmjoy,918734043@qq.com https://github.com/rust-lang/rust/pull/83809,MERGED,2021-04-03T13:19:14Z,2021-04-04T20:10:56Z,Remove unneeded INITIAL_IDS const,GuillaumeGomez,e62fce32e53478100ef5bffba11fcf4b700849ed,4,Rollup merge of #83809 - GuillaumeGomez:remove-initial-ids r=camelid Remove unneeded INITIAL_IDS const Some IDs inside this map didn't exist anymore some others were duplicates of what we have inside `IdMap`. So instead of keeping the two around and since `INITIAL_IDS` was only used by `IdMap` no need to keep both of them.,HEART,2021-04-03T18:48:13Z,camelid,NA https://github.com/rust-lang/rust/pull/83813,MERGED,2021-04-03T16:45:38Z,2021-05-12T13:33:37Z,Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths,cbeuw,e1ff91f439bc09f566da211c6449821b4e949279,48,"Auto merge of #83813 - cbeuw:remap-std r=michaelwoerister Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths This PR fixes #73167 (""Binaries end up containing path to the rust-src component despite `--remap-path-prefix`"") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped. `RealFileName::Named` introduced in #72767 is now renamed as `LocalPath` because this variant wraps a (most likely) valid local filesystem path. `RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option` as it will be set to `None` before serialisation so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure. When a path is remapped a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously the `local_path` is directly modified which goes against its purpose of ""suitable for reading from the file system on the local host"". `rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)` or if it is a `FileName::Real(RealFileName::LocalPath(_))` then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path virtual_name})` then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`. cc `@eddyb` who implemented `/rustc/...` path devirtualisation",HEART,2021-05-04T11:26:52Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/83816,MERGED,2021-04-03T17:40:39Z,2021-04-07T18:02:23Z,Trigger `unused_doc_comments` on macros at once,JohnTitor,4d5bb1ca222143627674a0da99c5b3f7bd7be77d,6,Rollup merge of #83816 - JohnTitor:unused-doc-comments-on-macros r=varkor Trigger `unused_doc_comments` on macros at once Fixes #83768,HEART,2021-04-03T18:29:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83816,MERGED,2021-04-03T17:40:39Z,2021-04-07T18:02:23Z,Trigger `unused_doc_comments` on macros at once,JohnTitor,4d5bb1ca222143627674a0da99c5b3f7bd7be77d,6,Rollup merge of #83816 - JohnTitor:unused-doc-comments-on-macros r=varkor Trigger `unused_doc_comments` on macros at once Fixes #83768,HEART,2021-04-03T18:50:12Z,camelid,NA https://github.com/rust-lang/rust/pull/83824,CLOSED,2021-04-03T19:59:03Z,2021-07-17T17:46:04Z,Stabilize `#[cfg_eval]` and `feature(macro_attributes_in_derive_output)`,petrochenkov,NA,NA,NA,THUMBS_UP,2021-04-23T07:12:48Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/83828,MERGED,2021-04-03T22:27:39Z,2021-04-07T02:26:27Z,rustdoc: Use `ThinVec` in a few places,camelid,8b53ec677eebde0dfa8cb81fd7d5a84c7c6348bd,1,Auto merge of #83828 - camelid:rustdoc-vec-perf r=jyn514 rustdoc: Use `ThinVec` in a few places Almost every crate has no primitives and no keywords defined in it so using `ThinVec` should make some types smaller.,THUMBS_UP,2021-04-04T12:45:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83835,MERGED,2021-04-04T03:08:27Z,2021-04-06T02:09:05Z,rustdoc: sort search index items for compression,notriddle,12d007da0f6620c8a10448cf5be762ffbb94ffd8,4,Rollup merge of #83835 - notriddle:sort-index r=ollie27 rustdoc: sort search index items for compression This should not affect the appearance of the docs pages themselves. This makes the pre-compressed search index smaller thanks to the empty-string path duplication format and also the gzipped version by giving the algorithm more structure to work with. rust$ wc -c search-index-old.js search-index-new.js 2628334 search-index-old.js 2586181 search-index-new.js 5214515 total rust$ gzip search-index-* rust$ wc -c search-index-old.js.gz search-index-new.js.gz 239486 search-index-old.js.gz 237386 search-index-new.js.gz 476872 total,HOORAY,2021-04-06T16:11:41Z,bluss,NA https://github.com/rust-lang/rust/pull/83835,MERGED,2021-04-04T03:08:27Z,2021-04-06T02:09:05Z,rustdoc: sort search index items for compression,notriddle,12d007da0f6620c8a10448cf5be762ffbb94ffd8,4,Rollup merge of #83835 - notriddle:sort-index r=ollie27 rustdoc: sort search index items for compression This should not affect the appearance of the docs pages themselves. This makes the pre-compressed search index smaller thanks to the empty-string path duplication format and also the gzipped version by giving the algorithm more structure to work with. rust$ wc -c search-index-old.js search-index-new.js 2628334 search-index-old.js 2586181 search-index-new.js 5214515 total rust$ gzip search-index-* rust$ wc -c search-index-old.js.gz search-index-new.js.gz 239486 search-index-old.js.gz 237386 search-index-new.js.gz 476872 total,HOORAY,2021-04-13T01:54:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83850,OPEN,2021-04-04T14:39:34Z,NA,Propagate deref coercion into block,ldm0,NA,NA,NA,HOORAY,2021-07-12T17:26:55Z,Ten0,NA https://github.com/rust-lang/rust/pull/83850,OPEN,2021-04-04T14:39:34Z,NA,Propagate deref coercion into block,ldm0,NA,NA,NA,THUMBS_UP,2021-07-12T17:26:57Z,Ten0,NA https://github.com/rust-lang/rust/pull/83850,OPEN,2021-04-04T14:39:34Z,NA,Propagate deref coercion into block,ldm0,NA,NA,NA,HOORAY,2021-08-18T06:49:21Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83850,OPEN,2021-04-04T14:39:34Z,NA,Propagate deref coercion into block,ldm0,NA,NA,NA,THUMBS_UP,2021-12-14T07:33:31Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/83850,OPEN,2021-04-04T14:39:34Z,NA,Propagate deref coercion into block,ldm0,NA,NA,NA,HOORAY,2022-07-01T23:40:41Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-05T17:01:16Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-05T19:23:17Z,bluss,NA https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-07T00:07:52Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-08T20:05:31Z,tux3,NA https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-09T07:08:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-09T23:43:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/83858,MERGED,2021-04-04T19:08:30Z,2021-04-05T08:33:15Z,Use `#[inline(always)]` on trivial UnsafeCell methods,joshtriplett,58e71896506edb701f276158bd2f47e8788a1133,1,Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline r=Mark-Simulacrum Use `#[inline(always)]` on trivial UnsafeCell methods UnsafeCell is the standard building block for shared mutable data structures. UnsafeCell should add zero overhead compared to using raw pointers directly. Some reports suggest that debug builds or even builds at opt-level 1 may not always be inlining its methods. Mark the methods as `#[inline(always)]` since once inlined the methods should result in no actual code other than field accesses.,HEART,2021-04-10T07:24:30Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/83865,MERGED,2021-04-04T22:36:36Z,2021-04-05T13:47:29Z,Don't report disambiguator error if link would have been ignored,camelid,3ca197e89c9affc76e79f0421e1bb9d65a8ec855,4,Rollup merge of #83865 - camelid:disamb-err-fix r=jyn514 Don't report disambiguator error if link would have been ignored Fixes #83859. This prevents us from warning on links such as ``. Note that we still warn on links such as `` because they have no dots in them. However the links will still work even though a warning is reported. r? ````@jyn514````,THUMBS_UP,2021-04-04T22:37:58Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83870,MERGED,2021-04-05T04:23:17Z,2021-04-09T04:19:30Z,Don't concatenate binders across types,jackh726,cd56e255c43030d583aa0aa09f7eb92f2d8d1d81,4,"Auto merge of #83870 - jackh726:binder-refactor-fix r=nikomatsakis Don't concatenate binders across types Partially addresses #83737 There's actually two issues that I uncovered in #83737. The first is that we are concatenating bound vars across types i.e. in ``` F: Fn(&()) -> &mut (dyn Future + Unpin) ``` the bound vars on `Future` get set as `for` since those are the binders on `Fn(&()`. This is obviously wrong since we should only concatenate directly nested trait refs. This is solved here by introducing a new `TraitRefBoundary` scope that we put around the ""syntactical"" trait refs and basically don't allow concatenation across. Now this alone *shouldn't* be a super terrible problem. At least not until you consider the other issue which is a much more elusive and harder to design a ""perfect"" fix. A repro can be seen in: ``` use core::future::Future; async fn handle(slf: &F) where F: Fn(&()) -> &mut (dyn for<'a> Future + Unpin) { (slf)(&()).await; } ``` Notice the `for<'a>` around `Future`. Here `'a` is unused so the `for<'a>` Binder gets changed to a `for<>` Binder in the generator witness but the ""local decl"" still has it. This has heavy intersections with region anonymization and erasing. Luckily it's not *super* common to find this unique set of circumstances. It only became apparently because of the first issue mentioned here. However this *is* still a problem so I'm leaving #83737 open. r? `@nikomatsakis`",HEART,2021-04-05T19:15:10Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/83894,MERGED,2021-04-05T15:49:08Z,2021-05-09T19:01:05Z,Improve support for NewPM,nikic,7a2f4468892a9bf694b844f1fa1032779320c7e5,14,Auto merge of #83894 - nikic:newpm r=nagisa Improve support for NewPM This adds various missing bits of support for NewPM and allows us to successfully run stage 2 tests with NewPM enabled. This does not yet enable NewPM by default as there are still known issue on LLVM 12 (such as a weak fat LTO pipeline). The plan is to make the switch after we update to LLVM 13.,HEART,2021-04-12T10:14:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83898,MERGED,2021-04-05T18:01:29Z,2021-07-17T00:35:48Z,Add initial implementation of HIR-based WF checking for diagnostics,Aaron1011,32c447e179cb4c3ae34e51b2f37b4390953ff55c,23,Auto merge of #83898 - Aaron1011:feature/hir-wf r=estebank Add initial implementation of HIR-based WF checking for diagnostics During well-formed checking we walk through all types 'nested' in generic arguments. For example WF-checking `Option>` will cause us to check `MyStruct` and `u8`. However this is done on a `rustc_middle::ty::Ty` which has no span information. As a result any errors that occur will have a very general span (e.g. the definintion of an associated item). This becomes a problem when macros are involved. In general an associated type like `type MyType = Option>;` may have completely different spans for each nested type in the HIR. Using the span of the entire associated item might end up pointing to a macro invocation even though a user-provided span is available in one of the nested types. This PR adds a framework for HIR-based well formed checking. This check is only run during error reporting and is used to obtain a more precise span for an existing error. This is accomplished by individually checking each 'nested' type in the HIR for the type allowing us to find the most-specific type (and span) that produces a given error. The majority of the changes are to the error-reporting code. However some of the general trait code is modified to pass through more information. Since this has no soundness implications I've implemented a minimal version to begin with which can be extended over time. In particular this only works for HIR items with a corresponding `DefId` (e.g. it will not work for WF-checking performed within function bodies).,HEART,2021-07-16T18:28:53Z,estebank,NA https://github.com/rust-lang/rust/pull/83900,MERGED,2021-04-05T19:00:02Z,2021-04-20T08:33:57Z,Add stability tags to ImportItem.,torhovland,a70fbf6620ddaacc2ef805fa8c4ac2dc9bf02f3c,7,Auto merge of #83900 - torhovland:issue-83832 r=jyn514 Add stability tags to ImportItem. Fixes #83832.,ROCKET,2021-04-20T08:53:12Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/83908,MERGED,2021-04-05T23:46:46Z,2021-10-11T20:20:45Z,Add enum_intrinsics_non_enums lint,Flying-Toast,5b210643ebf2485aafdf2494de8cf41941a64e95,22,Auto merge of #83908 - Flying-Toast:master r=davidtwco Add enum_intrinsics_non_enums lint There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc given that `discriminant::()` where `T` is a non-enum has an unspecified return value and there are no valid use cases where you'd actually want this. I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662). closes #83899,THUMBS_UP,2021-04-06T07:16:32Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/83908,MERGED,2021-04-05T23:46:46Z,2021-10-11T20:20:45Z,Add enum_intrinsics_non_enums lint,Flying-Toast,5b210643ebf2485aafdf2494de8cf41941a64e95,22,Auto merge of #83908 - Flying-Toast:master r=davidtwco Add enum_intrinsics_non_enums lint There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc given that `discriminant::()` where `T` is a non-enum has an unspecified return value and there are no valid use cases where you'd actually want this. I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662). closes #83899,HEART,2021-04-12T10:13:16Z,scottmcm,NA https://github.com/rust-lang/rust/pull/83908,MERGED,2021-04-05T23:46:46Z,2021-10-11T20:20:45Z,Add enum_intrinsics_non_enums lint,Flying-Toast,5b210643ebf2485aafdf2494de8cf41941a64e95,22,Auto merge of #83908 - Flying-Toast:master r=davidtwco Add enum_intrinsics_non_enums lint There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc given that `discriminant::()` where `T` is a non-enum has an unspecified return value and there are no valid use cases where you'd actually want this. I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662). closes #83899,THUMBS_UP,2021-06-15T21:42:19Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/83908,MERGED,2021-04-05T23:46:46Z,2021-10-11T20:20:45Z,Add enum_intrinsics_non_enums lint,Flying-Toast,5b210643ebf2485aafdf2494de8cf41941a64e95,22,Auto merge of #83908 - Flying-Toast:master r=davidtwco Add enum_intrinsics_non_enums lint There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc given that `discriminant::()` where `T` is a non-enum has an unspecified return value and there are no valid use cases where you'd actually want this. I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662). closes #83899,HEART,2021-10-11T20:30:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/83916,MERGED,2021-04-06T05:05:18Z,2021-04-07T18:02:22Z,Use AnonConst for asm! constants,Amanieu,b81c6cdb570957b5d6d4261b908f7e0364a67d81,37,Rollup merge of #83916 - Amanieu:asm_anonconst r=petrochenkov Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See #83169 for more background. The syntax for `const` operands is still the same as before: `const `. Fixes #83169 Because the implementation is heavily based on inline consts we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.,HEART,2021-04-06T08:00:14Z,RalfJung,NA https://github.com/rust-lang/rust/pull/83916,MERGED,2021-04-06T05:05:18Z,2021-04-07T18:02:22Z,Use AnonConst for asm! constants,Amanieu,b81c6cdb570957b5d6d4261b908f7e0364a67d81,37,Rollup merge of #83916 - Amanieu:asm_anonconst r=petrochenkov Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See #83169 for more background. The syntax for `const` operands is still the same as before: `const `. Fixes #83169 Because the implementation is heavily based on inline consts we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.,HEART,2021-04-06T11:40:25Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/83916,MERGED,2021-04-06T05:05:18Z,2021-04-07T18:02:22Z,Use AnonConst for asm! constants,Amanieu,b81c6cdb570957b5d6d4261b908f7e0364a67d81,37,Rollup merge of #83916 - Amanieu:asm_anonconst r=petrochenkov Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See #83169 for more background. The syntax for `const` operands is still the same as before: `const `. Fixes #83169 Because the implementation is heavily based on inline consts we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.,HEART,2021-04-06T12:01:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-04-06T09:24:24Z,aheart,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-04-07T02:27:50Z,Lokathor,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-04-07T02:48:13Z,bstrie,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-04-07T06:13:14Z,scooter-dangle,scottlsteele@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-04-07T09:37:16Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-04T17:58:15Z,cramertj,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-05T13:24:36Z,dcormier,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-06T14:27:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-07T19:02:47Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-09T22:41:51Z,lukechu10,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-05-10T18:31:54Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-10T19:56:56Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-05-15T08:33:48Z,ahlinc,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-06-30T17:56:56Z,anshul-march,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-07-01T05:44:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-07-01T10:07:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-07-01T16:35:28Z,lukechu10,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-07-02T08:50:48Z,robatipoor,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-07-02T14:49:49Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-07-08T11:06:40Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-07-10T11:23:03Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-07-14T20:35:07Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-07-17T11:43:40Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-08-03T17:33:20Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-08-03T17:33:21Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-09T15:17:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-09-09T15:17:07Z,zohnannor,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-09T15:37:31Z,yerke,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-09-09T15:37:32Z,yerke,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HEART,2021-09-09T15:37:40Z,yerke,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",ROCKET,2021-09-09T15:37:43Z,yerke,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-09T16:59:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-09T17:58:44Z,nanoqsh,nanoqsh@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-10T02:26:34Z,panarch,taehoon.moon@outlook.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-09-10T02:26:34Z,panarch,taehoon.moon@outlook.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-10T02:41:28Z,tonyluj,tonyluj@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-09-10T07:49:10Z,vkatushenok,NA https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",ROCKET,2021-09-10T18:09:15Z,coderaiser,mnemonic.enemy@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-10T18:09:19Z,coderaiser,mnemonic.enemy@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-09-11T06:11:27Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",THUMBS_UP,2021-11-08T23:33:10Z,Idonoghue,isaacdonoghue@live.com https://github.com/rust-lang/rust/pull/83918,MERGED,2021-04-06T07:22:29Z,2021-07-11T08:46:47Z,"Stabilize ""RangeFrom"" patterns in 1.55",workingjubilee,0d76b7374589c45e3e9290309781a1ed9a461951,19,"Auto merge of #83918 - workingjubilee:stable-rangefrom-pat r=joshtriplett Stabilize ""RangeFrom"" patterns in 1.55 Implements a partial stabilization of #67264 and #37854. Reference PR: https://github.com/rust-lang/reference/pull/900 # Stabilization Report This stabilizes the `X..` pattern shown as such offering an exhaustive match for unsigned integers: ```rust match x as u32 { 0 => println!(""zero!"") 1.. => println!(""positive number!"") } ``` Currently if a Rust author wants to write such a match on an integer they must use `1..={integer}::MAX` . By allowing a ""RangeFrom"" style pattern this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match allowing for easier refactoring. This is particularly useful for instances like the above case where different behavior on ""0"" vs. ""1 or any positive number"" is desired and the actual MAX is unimportant. Notably this excepts slice patterns which include half-open ranges from stabilization as the wisdom of those is still subject to some debate. ## Practical Applications Instances of this specific usage have appeared in the compiler: https://github.com/rust-lang/rust/blob/16143d10679537d3fde4247e15334e78ad9d55b9/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L219 https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/compiler/rustc_ty_utils/src/ty.rs#L524 And I have noticed there are also a handful of ""in the wild"" users who have deployed it to similar effect especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match as done in Katholieke Universiteit Leuven's [SCALE and MAMBA project](https://github.com/KULeuven-COSIC/SCALE-MAMBA/blob/05e5db00d553573534258585651c525d0da5f83f/WebAssembly/scale_std/src/fixed_point.rs#L685-L695). ## Tests There were already many tests in [src/test/ui/half-open-range/patterns](https://github.com/rust-lang/rust/tree/90a2e5e3fe59a254d4d707aa291517b3791ea5a6/src/test/ui/half-open-range-patterns) as well as [generic pattern tests that test the `exclusive_range_pattern` feature](https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/pattern/usefulness/integer-ranges/reachability.rs) many dating back to the feature's introduction and remaining standing to this day. However this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is at least a mild diagnostic improvement in some edge cases because before now the pattern `0..=(5+1)` encounters the `half_open_range_patterns` feature gate and can thus emit the request to enable the feature flag while also emitting the ""inclusive range with no end"" diagnostic. There is no intent to allow an `X..=` pattern that I am aware of so removing the flag request is a strict improvement. The arrival of the `J | K` ""or"" pattern also enables some odd formations. Some of the behavior tested for here is derived from experiments in this [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58777b3c715c85165ac4a70d93efeefc) example linked at https://github.com/rust-lang/rust/issues/67264#issuecomment-812770692 which may be useful to reference to observe the current behavior more closely. In addition tests constituting an explanation of the ""slicing range patterns"" syntax issue are included in this PR. ## Desiderata The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors as they make some patterns much more natural to write but there is disagreement regarding the ""closed"" exclusive range pattern or the ""RangeTo"" pattern especially where it creates ""off by one"" gaps in the presence of a ""catch-all"" wildcard case. Also there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on ideally and I think it would be reasonable to consider such a blocker to stabilizing this feature but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the ""point"" of the feature at least from my view is to make it easier to omit wildcard matches: a pattern with such an ""open"" match produces an irrefutable match and does not need the wild card case making it easier to benefit from exhaustiveness checking. ## History - Implemented: - Partially via exclusive ranges: https://github.com/rust-lang/rust/pull/35712 - Fully with half-open ranges: https://github.com/rust-lang/rust/pull/67258 - Unresolved Questions: - The precedence concerns of https://github.com/rust-lang/rust/pull/48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles given https://github.com/rust-lang/rust/issues/67264#issuecomment-720711656 but it is still unknown what changes might be desired - How we want to handle slice patterns in ranges seems to be an open question still as witnessed in the discussion of this PR! I checked but I couldn't actually find an RFC for this and given ""approved provisionally by lang team without an RFC"" I believe this might require an RFC before it can land? Unsure of procedure here on account of this being stabilizing a subset of a feature of syntax. r? `@scottmcm`",HOORAY,2021-11-08T23:33:11Z,Idonoghue,isaacdonoghue@live.com https://github.com/rust-lang/rust/pull/83933,CLOSED,2021-04-06T15:39:44Z,2021-04-07T13:47:56Z,Add copy_sign() as doc alias for f32/f64::copysign(),mqudsi,NA,NA,NA,LAUGH,2021-04-06T18:34:40Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83933,CLOSED,2021-04-06T15:39:44Z,2021-04-07T13:47:56Z,Add copy_sign() as doc alias for f32/f64::copysign(),mqudsi,NA,NA,NA,LAUGH,2021-04-07T09:31:25Z,Pratyush,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-06T20:04:46Z,jstarks,jostarks@microsoft.com https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-04-06T20:20:41Z,sivadeilra,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-07T09:03:33Z,rylev,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-09T13:37:42Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-04-09T13:37:43Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-04-09T14:09:27Z,sabbyX,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-09T14:09:27Z,sabbyX,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-04-09T16:41:00Z,JakubKoralewski,contact@jcubed.me https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-04-09T17:58:56Z,weihanglo,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-09T17:58:57Z,weihanglo,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-04-10T07:52:36Z,rasviitanen,rasviitanen@gmail.com https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-06-16T10:41:33Z,ThrashAbaddon,NA https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,THUMBS_UP,2021-06-17T15:19:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83941,MERGED,2021-04-06T17:59:46Z,2021-04-09T01:50:02Z,Improve debuginfo for closures and async functions on Windows MSVC,wesleywiser,619d19c3181e4793de789302d60a0343f0081139,4,Auto merge of #83941 - wesleywiser:win_dbginfo_closures r=nagisa Improve debuginfo for closures and async functions on Windows MSVC The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure or async fn. This fixes that by creating additional allocas on the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records. I also updated some of our existing tests to run in CDB to cover this case. Before (closure): ![image](https://user-images.githubusercontent.com/831192/113756857-e6dc4200-96df-11eb-8d6d-b7ed7a84aad5.png) After (closure): ![image](https://user-images.githubusercontent.com/831192/113757067-2e62ce00-96e0-11eb-89f7-7dc8ab89b1b8.png) Before (async): ![image](https://user-images.githubusercontent.com/831192/114077916-4e2bfa80-9876-11eb-9f15-e302d1faa652.png) After (async): ![image](https://user-images.githubusercontent.com/831192/114077677-0d33e600-9876-11eb-8ce3-cac20a9ea94a.png) Fixes #83709,HOORAY,2021-06-17T15:19:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/83947,CLOSED,2021-04-06T20:11:25Z,2022-01-30T04:45:06Z,Extend `-Cdebuginfo` with new options and named aliases,jdtatz,NA,NA,NA,THUMBS_UP,2021-05-17T07:43:51Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/83967,CLOSED,2021-04-07T13:47:07Z,2021-04-21T20:02:03Z,Add `free` as a doc alias for `drop`,jyn514,NA,NA,NA,THUMBS_UP,2021-04-08T04:29:46Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83983,CLOSED,2021-04-07T20:28:29Z,2021-04-27T15:46:46Z,call to_owned directly in str::to_string,ibraheemdev,NA,NA,NA,CONFUSED,2021-04-07T21:29:17Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/83992,MERGED,2021-04-08T09:51:51Z,2021-04-08T22:07:47Z,Merge idents when generating source content,GuillaumeGomez,901ada6494438cf7f7c2b041bbaa26b8b0217a89,3,"Rollup merge of #83992 - GuillaumeGomez:merge-idents r=notriddle Merge idents when generating source content The idea here is to not have a span for each part of a path. Currently for `a::b::c` we generate `a::b::c` with this change we will generate `a::b::c`. A nice ""side-effect"" is that it reduces the size of the output HTML too. :) cc `@notriddle`",THUMBS_UP,2021-04-10T19:29:17Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/83992,MERGED,2021-04-08T09:51:51Z,2021-04-08T22:07:47Z,Merge idents when generating source content,GuillaumeGomez,901ada6494438cf7f7c2b041bbaa26b8b0217a89,3,"Rollup merge of #83992 - GuillaumeGomez:merge-idents r=notriddle Merge idents when generating source content The idea here is to not have a span for each part of a path. Currently for `a::b::c` we generate `a::b::c` with this change we will generate `a::b::c`. A nice ""side-effect"" is that it reduces the size of the output HTML too. :) cc `@notriddle`",ROCKET,2021-04-10T19:29:19Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84010,MERGED,2021-04-08T19:29:29Z,2021-04-09T09:20:07Z,Mention missing 1.38.0 change in RELEASES.md,rodrimati1992,bc66b92f7f1114a78b98504a927ca9c0aa12c71a,1,Auto merge of #84010 - rodrimati1992:patch-3 r=Mark-Simulacrum Mention missing 1.38.0 change in RELEASES.md Mention that doc comments on `pub use` statements are prepended to the documentation of the reexported item Fixes #84007,HOORAY,2021-04-13T22:51:24Z,bluss,NA https://github.com/rust-lang/rust/pull/84017,MERGED,2021-04-08T21:33:47Z,2021-05-04T13:07:44Z,Valid underscores in hex/octal/binary literal docs,Smittyvb,a5f164faad4a2fed606b8160fd7ecd2d5cbba381,2,Auto merge of #84017 - Smittyvb:int-literal-underscores r=jyn514 Valid underscores in hex/octal/binary literal docs Currently hex/octal/binary literals with computed values are displayed like `0_xff_fff_fffu32` which is invalid since underscores can't be in the middle of integer prefixes. This properly formats prefixed integers. This causes [`std::u32::MAX`](https://doc.rust-lang.org/std/u32/constant.MAX.html) to be displayed as ```rust pub const MAX: u32 = u32::MAX; // 0_xff_fff_fffu32 ``` This PR changes it to be displayed as: ```rust pub const MAX: u32 = u32::MAX; // 0xffff_ffffu32 ```,THUMBS_UP,2021-04-08T21:47:57Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84017,MERGED,2021-04-08T21:33:47Z,2021-05-04T13:07:44Z,Valid underscores in hex/octal/binary literal docs,Smittyvb,a5f164faad4a2fed606b8160fd7ecd2d5cbba381,2,Auto merge of #84017 - Smittyvb:int-literal-underscores r=jyn514 Valid underscores in hex/octal/binary literal docs Currently hex/octal/binary literals with computed values are displayed like `0_xff_fff_fffu32` which is invalid since underscores can't be in the middle of integer prefixes. This properly formats prefixed integers. This causes [`std::u32::MAX`](https://doc.rust-lang.org/std/u32/constant.MAX.html) to be displayed as ```rust pub const MAX: u32 = u32::MAX; // 0_xff_fff_fffu32 ``` This PR changes it to be displayed as: ```rust pub const MAX: u32 = u32::MAX; // 0xffff_ffffu32 ```,THUMBS_UP,2021-04-09T17:59:38Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84030,MERGED,2021-04-09T13:11:41Z,2021-04-09T16:22:24Z,rustdoc: Don't generate blanket impls when running --show-coverage,jyn514,e43c2005f250b51e24d294da0b228e0a2dc4d9b2,4,Auto merge of #84030 - jyn514:no-blanket-impls r=GuillaumeGomez rustdoc: Don't generate blanket impls when running --show-coverage `get_blanket_impls` is the slowest part of rustdoc and the coverage pass completely ignores blanket impls. This stops running it at all and also removes some unnecessary checks in `calculate_doc_coverage` that ignored the impl anyway. We don't currently measure --show-coverage in perf.rlo but I tested this locally on cargo and it brought the time down from 2.9 to 1.6 seconds. This also adds back a commented-out test; Rustdoc has been able to deal with `impl trait` for almost a year now. r? `@GuillaumeGomez`,THUMBS_UP,2021-04-11T06:19:42Z,heymind,NA https://github.com/rust-lang/rust/pull/84030,MERGED,2021-04-09T13:11:41Z,2021-04-09T16:22:24Z,rustdoc: Don't generate blanket impls when running --show-coverage,jyn514,e43c2005f250b51e24d294da0b228e0a2dc4d9b2,4,Auto merge of #84030 - jyn514:no-blanket-impls r=GuillaumeGomez rustdoc: Don't generate blanket impls when running --show-coverage `get_blanket_impls` is the slowest part of rustdoc and the coverage pass completely ignores blanket impls. This stops running it at all and also removes some unnecessary checks in `calculate_doc_coverage` that ignored the impl anyway. We don't currently measure --show-coverage in perf.rlo but I tested this locally on cargo and it brought the time down from 2.9 to 1.6 seconds. This also adds back a commented-out test; Rustdoc has been able to deal with `impl trait` for almost a year now. r? `@GuillaumeGomez`,HEART,2021-04-11T06:19:46Z,heymind,NA https://github.com/rust-lang/rust/pull/84034,MERGED,2021-04-09T14:00:50Z,2021-04-09T21:14:52Z,Fix perf regression in rustdoc::bare_urls,jyn514,8513e78dbbbdd7cd5eaf2e8eb0bccb8c15a99a25,1,Auto merge of #84034 - jyn514:regex-in-loop r=Mark-Simulacrum Fix perf regression in rustdoc::bare_urls This regressed in #81764. After that PR rustdoc compiled the regex for every single item in the crate: https://perf.rust-lang.org/compare.html?start=125505306744a0a5bb01d62337260a95d9ff8d57&end=2e495d2e845cf27740e3665f718acfd3aa17253e&stat=instructions%3Au This would have been caught by `clippy::declare_interior_mutable_const` (cc https://github.com/rust-lang/rust/issues/77983).,EYES,2021-04-09T17:58:55Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84034,MERGED,2021-04-09T14:00:50Z,2021-04-09T21:14:52Z,Fix perf regression in rustdoc::bare_urls,jyn514,8513e78dbbbdd7cd5eaf2e8eb0bccb8c15a99a25,1,Auto merge of #84034 - jyn514:regex-in-loop r=Mark-Simulacrum Fix perf regression in rustdoc::bare_urls This regressed in #81764. After that PR rustdoc compiled the regex for every single item in the crate: https://perf.rust-lang.org/compare.html?start=125505306744a0a5bb01d62337260a95d9ff8d57&end=2e495d2e845cf27740e3665f718acfd3aa17253e&stat=instructions%3Au This would have been caught by `clippy::declare_interior_mutable_const` (cc https://github.com/rust-lang/rust/issues/77983).,EYES,2021-04-09T18:36:58Z,Soveu,NA https://github.com/rust-lang/rust/pull/84039,MERGED,2021-04-09T16:10:44Z,2021-08-16T09:38:27Z,Uplift the invalid_atomic_ordering lint from clippy to rustc,jyn514,92f3753b073c03184118a315cc0d289116102ae1,28,"Auto merge of #84039 - jyn514:uplift-atomic-ordering r=wesleywiser Uplift the invalid_atomic_ordering lint from clippy to rustc This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below. r? `@lcnr` since you reviewed the last one but feel free to reassign. --- This is an implementation of https://github.com/rust-lang/compiler-team/issues/390. As mentioned in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever. As a result of it having no false positives and the alternative always being strictly wrong it's on as deny by default. This seems right. In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too? --- Some notes on the code for reviewers / others below ## Changes from clippy The code is changed from [the implementation in clippy](https://github.com/rust-lang/rust-clippy/blob/68cf94f6a66e47234e3adefc6dfbe806cd6ad164/clippy_lints/src/atomic_ordering.rs) in the following ways: 1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals. - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol but it did require adding several. 2. The functions are moved to static methods inside the lint struct as a way to namespace them. - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable. 3. Supports unstable AtomicU128/AtomicI128. - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item` which would have complicated an already big macro. - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too but 128-bit atomics are much less common. Regardless the existing tests should be *more* than thorough enough here. 4. Minor changes like: - grammar tweaks (""loads cannot have `Release` **and** `AcqRel` ordering"" => ""loads cannot have `Release` **or** `AcqRel` ordering"") - function renames (`match_ordering_def_path` => `matches_ordering_def_path`) - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper). ## Potential issues (This is just about the code in this PR not conceptual issues with the lint or anything) 1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really so if I should do this some pointers would be appreciated). - It seems possible that failing to do this might possibly mean there are more cases this lint would miss but I don't really know how `match_def_path` works and if it has any pitfalls like that so maybe not. 2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there. - I'm kind of hoping CI will catch if I missed anything since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So honestly no clue. 3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing. 4. It pulls in the `if_chain` crate. This crate was already used in clippy and seems like it's used elsewhere in rustc but I'm willing to rewrite it to not use this if needed (I'd prefer not to all things being equal).",HOORAY,2021-04-11T08:48:06Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/84071,MERGED,2021-04-10T20:15:22Z,2021-04-11T05:23:11Z,Fix NixOS patching,nagisa,ea1252e7e3282fa8a3163ca424d6ed00a9dbe163,1,Auto merge of #84071 - nagisa:nixos-patching-fix r=Mark-Simulacrum Fix NixOS patching Moving the `.nix-deps` has resulted in rpath links being broken and therefore bootstrap on NixOS broken entirely. This PR still produces a `.nix-deps` but only for the purposes of producing a gc root. We rpath a symlink-resolved result instead. For purposes of simplicity we also use joinSymlink to produce a single merged output directory so that we don't need to update multiple locations every time we add a library or something. Fixes a regression from https://github.com/rust-lang/rust/pull/82739.,HEART,2021-04-10T22:12:46Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84082,MERGED,2021-04-11T08:05:24Z,2021-04-13T05:59:11Z,Stabilize nonzero_leading_trailing_zeros,andjo403,7ce470fd9b1b08f71f10ecf084b47c1d93ade0db,6,Auto merge of #84082 - andjo403:stabilize_nonzero_leading_trailing_zeros r=m-ou-se Stabilize nonzero_leading_trailing_zeros Stabilizing nonzero_leading_trailing_zeros and due to this also stabilizing the intrinsic cttz_nonzero FCP finished here: https://github.com/rust-lang/rust/issues/79143#issuecomment-817216153 `@rustbot` modify labels: +T-libs Closes #79143,HOORAY,2021-04-12T09:54:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/84083,MERGED,2021-04-11T08:47:06Z,2022-01-02T03:21:36Z,Clarify the guarantees that ThreadId does and doesn't make.,ltratt,30ec1f0384338351902a22d9d0e7f867f142a1f6,1,Rollup merge of #84083 - ltratt:threadid_doc_tweak r=dtolnay Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.,THUMBS_UP,2021-04-11T09:25:07Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84083,MERGED,2021-04-11T08:47:06Z,2022-01-02T03:21:36Z,Clarify the guarantees that ThreadId does and doesn't make.,ltratt,30ec1f0384338351902a22d9d0e7f867f142a1f6,1,Rollup merge of #84083 - ltratt:threadid_doc_tweak r=dtolnay Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.,THUMBS_UP,2021-12-31T05:30:15Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/84084,MERGED,2021-04-11T09:26:05Z,2021-04-13T14:03:33Z,Stabilize duration_zero.,m-ou-se,3d6a364e33aee66a3126f33e4e9d7157c1b0740d,3,Rollup merge of #84084 - m-ou-se:stabilize-zero r=scottmcm Stabilize duration_zero. FCP here: https://github.com/rust-lang/rust/issues/73544#issuecomment-817201305,HEART,2021-04-12T05:48:56Z,TehPers,tehperz@gmail.com https://github.com/rust-lang/rust/pull/84084,MERGED,2021-04-11T09:26:05Z,2021-04-13T14:03:33Z,Stabilize duration_zero.,m-ou-se,3d6a364e33aee66a3126f33e4e9d7157c1b0740d,3,Rollup merge of #84084 - m-ou-se:stabilize-zero r=scottmcm Stabilize duration_zero. FCP here: https://github.com/rust-lang/rust/issues/73544#issuecomment-817201305,HEART,2021-04-22T05:12:08Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84086,MERGED,2021-04-11T09:48:57Z,2021-04-13T08:40:24Z,Stabilize is_subnormal.,m-ou-se,23aef90b4e28148099485cd4d4bfcd7df5e562c1,2,Auto merge of #84086 - m-ou-se:stabilze-is-subnormal r=dtolnay Stabilize is_subnormal. FCP completed here: https://github.com/rust-lang/rust/issues/79288#issuecomment-817201311,THUMBS_UP,2021-04-12T03:41:50Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84088,MERGED,2021-04-11T09:54:38Z,2021-04-15T15:18:19Z,Stabilize option_insert.,m-ou-se,f1ca558db189690a9774713306c94550681ac590,1,Auto merge of #84088 - m-ou-se:stabilize-option-insert r=m-ou-se Stabilize option_insert. FCP finished here: https://github.com/rust-lang/rust/issues/78271#issuecomment-817201319,HOORAY,2021-04-11T10:35:20Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/84088,MERGED,2021-04-11T09:54:38Z,2021-04-15T15:18:19Z,Stabilize option_insert.,m-ou-se,f1ca558db189690a9774713306c94550681ac590,1,Auto merge of #84088 - m-ou-se:stabilize-option-insert r=m-ou-se Stabilize option_insert. FCP finished here: https://github.com/rust-lang/rust/issues/78271#issuecomment-817201319,HOORAY,2021-04-11T11:23:31Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/84092,MERGED,2021-04-11T12:01:44Z,2021-04-27T01:58:38Z,Add the `try_trait_v2` library basics,scottmcm,61e171566a9c97ec41656e96e4dd23261b812b9d,6,Auto merge of #84092 - scottmcm:try_trait_initial r=yaahc m-ou-se Add the `try_trait_v2` library basics No compiler changes as part of this -- just new unstable traits and impls thereof. The goal here is to add the things that aren't going to break anything to keep the feature implementation simpler in the next PR. (Draft since the FCP won't end until Saturday but I was feeling optimistic today -- and had forgotten that FCP was 10 days not 7 days.),THUMBS_UP,2021-04-13T21:49:35Z,cramertj,NA https://github.com/rust-lang/rust/pull/84092,MERGED,2021-04-11T12:01:44Z,2021-04-27T01:58:38Z,Add the `try_trait_v2` library basics,scottmcm,61e171566a9c97ec41656e96e4dd23261b812b9d,6,Auto merge of #84092 - scottmcm:try_trait_initial r=yaahc m-ou-se Add the `try_trait_v2` library basics No compiler changes as part of this -- just new unstable traits and impls thereof. The goal here is to add the things that aren't going to break anything to keep the feature implementation simpler in the next PR. (Draft since the FCP won't end until Saturday but I was feeling optimistic today -- and had forgotten that FCP was 10 days not 7 days.),THUMBS_UP,2021-04-25T21:47:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84092,MERGED,2021-04-11T12:01:44Z,2021-04-27T01:58:38Z,Add the `try_trait_v2` library basics,scottmcm,61e171566a9c97ec41656e96e4dd23261b812b9d,6,Auto merge of #84092 - scottmcm:try_trait_initial r=yaahc m-ou-se Add the `try_trait_v2` library basics No compiler changes as part of this -- just new unstable traits and impls thereof. The goal here is to add the things that aren't going to break anything to keep the feature implementation simpler in the next PR. (Draft since the FCP won't end until Saturday but I was feeling optimistic today -- and had forgotten that FCP was 10 days not 7 days.),HEART,2021-04-26T18:56:01Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/84092,MERGED,2021-04-11T12:01:44Z,2021-04-27T01:58:38Z,Add the `try_trait_v2` library basics,scottmcm,61e171566a9c97ec41656e96e4dd23261b812b9d,6,Auto merge of #84092 - scottmcm:try_trait_initial r=yaahc m-ou-se Add the `try_trait_v2` library basics No compiler changes as part of this -- just new unstable traits and impls thereof. The goal here is to add the things that aren't going to break anything to keep the feature implementation simpler in the next PR. (Draft since the FCP won't end until Saturday but I was feeling optimistic today -- and had forgotten that FCP was 10 days not 7 days.),HEART,2021-04-26T21:28:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84094,MERGED,2021-04-11T12:40:50Z,2021-04-12T03:13:22Z,Remove FixedSizeArray,tmiasko,3ea5a9f301c6553d3c08774af2a1fd7a7e38fadc,4,Rollup merge of #84094 - tmiasko:remove-fixed-size-array r=m-ou-se Remove FixedSizeArray Remove `FixedSizeArray` trait it has been superseded by const generics. Closes #27778.,HOORAY,2021-04-11T13:49:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84094,MERGED,2021-04-11T12:40:50Z,2021-04-12T03:13:22Z,Remove FixedSizeArray,tmiasko,3ea5a9f301c6553d3c08774af2a1fd7a7e38fadc,4,Rollup merge of #84094 - tmiasko:remove-fixed-size-array r=m-ou-se Remove FixedSizeArray Remove `FixedSizeArray` trait it has been superseded by const generics. Closes #27778.,HOORAY,2021-04-12T04:42:57Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84094,MERGED,2021-04-11T12:40:50Z,2021-04-12T03:13:22Z,Remove FixedSizeArray,tmiasko,3ea5a9f301c6553d3c08774af2a1fd7a7e38fadc,4,Rollup merge of #84094 - tmiasko:remove-fixed-size-array r=m-ou-se Remove FixedSizeArray Remove `FixedSizeArray` trait it has been superseded by const generics. Closes #27778.,HOORAY,2021-04-13T01:52:29Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/84094,MERGED,2021-04-11T12:40:50Z,2021-04-12T03:13:22Z,Remove FixedSizeArray,tmiasko,3ea5a9f301c6553d3c08774af2a1fd7a7e38fadc,4,Rollup merge of #84094 - tmiasko:remove-fixed-size-array r=m-ou-se Remove FixedSizeArray Remove `FixedSizeArray` trait it has been superseded by const generics. Closes #27778.,HOORAY,2021-04-13T08:32:07Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/84096,MERGED,2021-04-11T12:57:32Z,2021-10-15T21:57:16Z,Use BCryptGenRandom instead of RtlGenRandom on Windows.,m-ou-se,c1026539bd22e9d070988deaa47b1360cbc76436,3,Auto merge of #84096 - m-ou-se:windows-bcrypt-random r=dtolnay Use BCryptGenRandom instead of RtlGenRandom on Windows. This removes usage of RtlGenRandom on Windows in favour of BCryptGenRandom. BCryptGenRandom isn't available on XP but we dropped XP support a while ago.,THUMBS_UP,2021-10-15T15:46:35Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-11T20:01:11Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-12T15:55:44Z,kesyog,NA https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-12T18:36:02Z,ehuss,NA https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-12T18:49:01Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-12T23:56:42Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84103,MERGED,2021-04-11T16:45:03Z,2021-04-12T18:29:32Z,update RLS and rustfmt,calebcartwright,1284da34da56a17ae368e4673920ec4120562cbd,4,Auto merge of #84103 - calebcartwright:bump-rls-rustfmt r=Xanewok update RLS and rustfmt Fixes #83460 and fixes #83459 cc `@Xanewok`,HEART,2021-04-15T20:43:06Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84105,MERGED,2021-04-11T19:16:38Z,2021-04-24T20:09:29Z,stabilize `core::array::{from_ref from_mut}` in `1.53.0`,WaffleLapkin,46b67ab0f957fca36baf3ef1a37be593d15063ed,2,Rollup merge of #84105 - WaffleLapkin:stabilize_array_from_ref r=m-ou-se stabilize `core::array::{from_ref from_mut}` in `1.53.0` I didn't get any response in https://github.com/rust-lang/rust/issues/77101#issuecomment-761831104 so I figured out I can try opening stabilization pr. --- This PR stabilizes following functions: ```rust // core::array pub fn from_ref(s: &T) -> &[T; 1]; pub fn from_mut(s: &mut T) -> &mut [T; 1]; ``` Functions are similar to already stabilized `core::slice::{`[`from_ref`](https://doc.rust-lang.org/std/slice/fn.from_ref.html) [`from_mut`](https://doc.rust-lang.org/std/slice/fn.from_mut.html)`}` and were unstable without any problems/questions for a while now. --- resolves #77101 ``@rustbot`` modify labels: +T-libs,THUMBS_UP,2021-05-06T08:31:34Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84110,CLOSED,2021-04-11T22:09:21Z,2022-05-13T11:15:01Z,Remove `#[cfg]` attributes during cfg-expansion,Aaron1011,NA,NA,NA,THUMBS_UP,2021-08-19T15:35:51Z,jplatte,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-15T07:12:53Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-15T09:43:12Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-20T13:10:52Z,theduke,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-20T17:36:29Z,kageru,kageru@encode.moe https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-21T01:30:51Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-22T08:33:22Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-23T19:24:08Z,cramertj,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-26T07:54:31Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-04-27T10:47:38Z,elichai,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-06-23T05:34:00Z,tvallotton,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-01T04:09:43Z,Gilnaa,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-01T07:14:23Z,jplatte,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-01T12:11:49Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-01T15:37:18Z,JonasCir,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-02T08:49:38Z,robatipoor,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-07-08T11:04:28Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-08T11:04:29Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-09T13:55:42Z,kangalioo,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-10T00:45:54Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-17T15:27:41Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-25T00:21:25Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-07-25T00:21:26Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-07-26T08:39:08Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-07-30T08:31:08Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-08-03T17:34:57Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-08-03T17:34:58Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-08-29T13:51:55Z,langzime,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-09-01T03:06:32Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-09-01T06:45:02Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-09-01T16:08:45Z,romanoji,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-09-01T16:08:46Z,romanoji,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-09-05T12:25:50Z,pepoviola,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-09-11T06:08:49Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-12T16:46:37Z,worstpractice,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-10-12T16:46:38Z,worstpractice,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-10-12T16:46:38Z,worstpractice,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-10-18T22:10:46Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-10-19T08:22:38Z,robinhundt,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-10-19T14:26:18Z,plazmoid,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-20T03:04:36Z,danielg1111,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-21T15:47:09Z,gliderkite,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-21T17:51:12Z,tjkirch,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-21T18:03:35Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-10-21T18:03:38Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-10-21T18:03:39Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HEART,2021-10-21T23:23:06Z,dsolartec,contact@danielsolarte.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-10-24T11:32:07Z,bluss,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-25T14:18:13Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2021-10-31T22:52:13Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-10-31T22:52:15Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-11-18T14:44:12Z,arnauorriols,arnau.orriols@iota.org https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,HOORAY,2021-11-18T22:29:57Z,lopopolo,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,ROCKET,2021-12-02T08:45:21Z,mati865,NA https://github.com/rust-lang/rust/pull/84111,MERGED,2021-04-11T23:00:16Z,2021-07-25T01:12:42Z,Stabilize `impl From<[(K V); N]> for HashMap` (and friends),bstrie,2b4196e97736ffe75433235bf586989cdb4221c4,12,Auto merge of #84111 - bstrie:hashfrom r=joshtriplett Stabilize `impl From<[(K V); N]> for HashMap` (and friends) In addition to allowing HashMap to participate in Into/From conversion this adds the long-requested ability to use constructor-like syntax for initializing a HashMap: ```rust let map = HashMap::from([ (1 2) (3 4) (5 6) ]); ``` This addition is highly motivated by existing precedence e.g. it is already possible to similarly construct a Vec from a fixed-size array: ```rust let vec = Vec::from([1 2 3]); ``` ...and it is already possible to collect a Vec of tuples into a HashMap (and vice-versa): ```rust let vec = Vec::from([(1 2)]); let map: HashMap<_ _> = vec.into_iter().collect(); let vec: Vec<(_ _)> = map.into_iter().collect(); ``` ...and of course it is likewise possible to collect a fixed-size array of tuples into a HashMap ([but not vice-versa just yet](https://github.com/rust-lang/rust/issues/81615)): ```rust let arr = [(1 2)]; let map: HashMap<_ _> = std::array::IntoIter::new(arr).collect(); ``` Therefore this addition seems like a no-brainer. As for any impl this would be insta-stable.,THUMBS_UP,2022-01-24T20:59:06Z,bmisiak,wickoo@gmail.com https://github.com/rust-lang/rust/pull/84113,MERGED,2021-04-11T23:14:13Z,2021-04-17T04:48:38Z,Detect when suggested paths enter extern crates more rigorously,SNCPlay42,42e5621c534b9367ae8e8e332d95929206720a23,4,Auto merge of #84113 - SNCPlay42:suggestion-extern-crate r=petrochenkov Detect when suggested paths enter extern crates more rigorously When reporting resolution errors the compiler tries to avoid suggesting importing inaccessible paths from other crates. However the search for suggestions only recognized when it was entering a crate root directly and so failed to recognize a path like `crate::module::private_item` where `module` was imported from another crate with `use other_crate::module` as entering another crate. Fixes #80079 Fixes #84081,HEART,2021-04-22T12:46:21Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/84120,MERGED,2021-04-12T05:13:38Z,2021-04-26T22:40:46Z,Stabilize Duration::MAX,workingjubilee,fb1502d5704fca76e63416663f64c6f89a52942b,1,Rollup merge of #84120 - workingjubilee:stabilize-duration-max r=m-ou-se Stabilize Duration::MAX Following the suggested direction from https://github.com/rust-lang/rust/issues/76416#issuecomment-817278338 this PR proposes that `Duration::MAX` should have been part of the `duration_saturating_ops` feature flag all along having been 0. heavily referenced by that feature flag 1. an odd duck next to most of `duration_constants` as I expressed in https://github.com/rust-lang/rust/issues/57391#issuecomment-717681193 2. introduced in #76114 which added `duration_saturating_ops` and accordingly should be folded into `duration_saturating_ops` and therefore stabilized. r? `@m-ou-se`,THUMBS_UP,2021-04-22T02:19:52Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84130,MERGED,2021-04-12T15:51:02Z,2021-04-14T23:26:31Z,Fix lookahead with None-delimited group,Aaron1011,16bf626a31cb5b121d0bca2baa969b4f67eb0dab,2,Auto merge of #84130 - Aaron1011:fix/none-delim-lookahead r=petrochenkov Fix lookahead with None-delimited group Fixes https://github.com/rust-lang/rust/issues/84162 a regression introduced by https://github.com/rust-lang/rust/pull/82608.,THUMBS_UP,2021-04-14T15:20:10Z,unageek,NA https://github.com/rust-lang/rust/pull/84130,MERGED,2021-04-12T15:51:02Z,2021-04-14T23:26:31Z,Fix lookahead with None-delimited group,Aaron1011,16bf626a31cb5b121d0bca2baa969b4f67eb0dab,2,Auto merge of #84130 - Aaron1011:fix/none-delim-lookahead r=petrochenkov Fix lookahead with None-delimited group Fixes https://github.com/rust-lang/rust/issues/84162 a regression introduced by https://github.com/rust-lang/rust/pull/82608.,THUMBS_UP,2021-04-15T10:11:03Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/84135,MERGED,2021-04-12T18:01:01Z,2021-04-13T16:44:53Z,Improve code example for length comparison,GuillaumeGomez,5c1304205b7bc53a1e9f48cf286a60438351c1ab,1,Auto merge of #84135 - rust-lang:GuillaumeGomez-patch-1 r=kennytm Improve code example for length comparison Small fix/improvement: it's much safer to check that you're under the length of an array rather than chacking that you're equal to it. It's even more true in case you update the length of the array while iterating.,THUMBS_UP,2021-04-12T22:27:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T00:58:39Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T01:09:04Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T03:02:06Z,cynecx,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T08:46:24Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T08:56:23Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T11:51:26Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-13T12:12:00Z,lolgeny,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-13T12:34:03Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-14T08:06:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-14T08:06:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-14T09:29:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-14T11:53:01Z,taiki-e,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T02:43:04Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T02:50:55Z,bstrie,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T07:42:16Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T08:02:06Z,RalfJung,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T09:16:53Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T09:16:54Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T09:41:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T09:41:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T12:06:23Z,RustyYato,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T13:28:07Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T13:46:07Z,pYtoner,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T15:42:58Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T17:00:07Z,tux3,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T17:00:08Z,tux3,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T18:03:38Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-15T18:03:40Z,jjpe,joey.ezechiels@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-15T21:40:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-16T03:33:35Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-16T03:33:35Z,Riey,creeper844@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-16T08:31:57Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-16T14:59:37Z,aznhe21,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-16T18:11:40Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-16T18:11:41Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-04-17T09:16:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-17T15:42:23Z,bluss,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-21T01:13:56Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-22T08:31:26Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-22T09:32:28Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-22T09:38:12Z,jplatte,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-22T13:49:18Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-24T18:10:39Z,trentj,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-24T20:49:36Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-04-25T06:14:00Z,lukechu10,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-25T06:14:01Z,lukechu10,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-25T06:14:02Z,lukechu10,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-25T10:02:36Z,Folyd,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-04-25T13:49:44Z,fmease,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-25T13:49:45Z,fmease,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-04-25T13:49:45Z,fmease,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-26T07:13:52Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-26T22:48:56Z,a1phyr,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-04-29T18:17:17Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-04-29T19:04:39Z,cole-miller,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-05-08T17:02:02Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-05-11T19:14:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-05-11T21:13:04Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-05-11T21:13:05Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-05-11T21:13:06Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,ROCKET,2021-05-16T16:19:20Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-07-11T10:17:09Z,suryaprakaz,suryaprakaz@hotmail.com https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-09-03T22:51:31Z,zohnannor,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,THUMBS_UP,2021-09-03T22:51:32Z,zohnannor,NA https://github.com/rust-lang/rust/pull/84147,MERGED,2021-04-13T00:10:09Z,2021-04-25T09:57:21Z,Cautiously add IntoIterator for arrays by value,cuviper,13a2615883aa28433383a723a764ca9acb43fd48,18,Auto merge of #84147 - cuviper:array-method-dispatch r=nikomatsakis m-ou-se Cautiously add IntoIterator for arrays by value Add the attribute described in #84133 `#[rustc_skip_array_during_method_dispatch]` which effectively hides a trait from method dispatch when the receiver type is an array. Then cherry-pick `IntoIterator for [T; N]` from #65819 and gate it with that attribute. Arrays can now be used as `IntoIterator` normally but `array.into_iter()` has edition-dependent behavior returning `slice::Iter` for 2015 and 2018 editions or `array::IntoIter` for 2021 and later. r? `@nikomatsakis` cc `@LukasKalbertodt` `@rust-lang/libs`,HOORAY,2021-10-28T15:00:51Z,krzentner,NA https://github.com/rust-lang/rust/pull/84168,MERGED,2021-04-13T18:59:15Z,2021-04-19T23:34:38Z,Lower async fn in traits.,cjgillot,e5b5745db14d852df8996d5f5ed53942f396bbd4,3,Rollup merge of #84168 - cjgillot:asi r=davidtwco Lower async fn in traits. An error is already created by AST validation. Fixes #84149,HEART,2021-04-13T20:07:58Z,dwrensha,NA https://github.com/rust-lang/rust/pull/84168,MERGED,2021-04-13T18:59:15Z,2021-04-19T23:34:38Z,Lower async fn in traits.,cjgillot,e5b5745db14d852df8996d5f5ed53942f396bbd4,3,Rollup merge of #84168 - cjgillot:asi r=davidtwco Lower async fn in traits. An error is already created by AST validation. Fixes #84149,HEART,2021-04-14T08:26:40Z,est31,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-13T20:27:51Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-13T20:27:53Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-13T20:57:57Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-13T23:52:32Z,tinaun,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T01:46:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T05:50:32Z,est31,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T05:50:36Z,est31,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T07:26:12Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T07:28:01Z,maroider,maroider@protonmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T07:28:02Z,maroider,maroider@protonmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T09:35:46Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T09:36:27Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T14:01:47Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T14:01:47Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T16:05:58Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-04-14T16:06:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-14T19:02:43Z,ctaggart,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-04-21T17:02:29Z,sivadeilra,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-05-08T00:04:16Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-05-12T02:52:07Z,crlf0710,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",HEART,2021-05-12T02:54:36Z,crlf0710,NA https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-05-20T23:17:26Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84171,MERGED,2021-04-13T20:03:32Z,2021-06-06T06:48:46Z,Partial support for raw-dylib linkage,ricobbe,9a576175cc9a0aecb85d0764a4f66ee29e26e155,27,"Auto merge of #84171 - ricobbe:raw-dylib-via-llvm r=petrochenkov Partial support for raw-dylib linkage First cut of functionality for issue #58713: add support for `#[link(kind = ""raw-dylib"")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions or the `#[link_ordinal]` attribute or `#[link(kind = ""raw-dylib"")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern ""stdcall""` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR. This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.",THUMBS_UP,2021-06-06T00:51:49Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/84176,MERGED,2021-04-13T21:17:42Z,2021-08-06T01:08:04Z,Generate links to definition in rustdoc source code pages,GuillaumeGomez,e2f79572fbcbe103346c950d95d7335f6c804d83,30,Auto merge of #84176 - GuillaumeGomez:src-to-definition r=jyn514 Generate links to definition in rustdoc source code pages ## Description This PR adds an option (disabled by default) to add links in the source code page on ident. So for for example: ```rust mod other_module; struct Foo; fn bar() {} fn x(f: Foo g: other_module::Whatever t: &T) { let f: Foo = Foo; bar(); f.some_method(); } ``` In the example (mostly in the `x` function) `other_module::Trait` `Foo` `other_module::Whatever` `bar` and `some_method` are now links (and `other_module` at the top too). In case there is a type coming from another crate it'll link to its documentation page and not its definition (but you can then click on `[src]` so I guess it's fine). Another important detail: I voluntarily didn't add links for primitive types. I think we can discuss about adding links on them or not in a later PR (adding the support for them would require only a few lines). Here is a video summing up everything I wrote above: https://user-images.githubusercontent.com/3050060/114622354-21307b00-9cae-11eb-834d-f6d8178a37bd.mp4 ## Performance impact So on my computer the performance remains more or less the same (which is quite surprising but that's a nice surprise). Here are the numbers: Without the option: * core: 1m 21s * alloc: 26.78s * std: 27.30s * proc_macro: 4.50s With source to definition links generation (I enabled by default the option): * core: 1m 25s * alloc: 25.76s * std: 27.07s * proc_macro: 4.66s So no real change here (again I'm very surprised by this fact). For the size of the generated source files (only taking into account the `src` folder here since it's the only one impacted) by running `du -shc .` (when I am in the source folder). Without the option: 11.939 MB With the option: 12.611 MB So not a big change here either. In all those docs I ran `grep -nR '(T); struct Wrapper2 { x: T } impl Wrapper2 { 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` in the current scope ... = note: The method was found for Wrapper2. ``` 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 ,THUMBS_UP,2021-05-21T22:26:46Z,estebank,NA https://github.com/rust-lang/rust/pull/84228,MERGED,2021-04-15T21:31:21Z,2021-04-16T08:01:57Z,Suggest to borrow after failing to cast from T to *const/mut T,SkiFire13,710da44e2249873eed123f8960667b88b1334289,4,Auto merge of #84228 - SkiFire13:fix-84213 r=estebank Suggest to borrow after failing to cast from T to *const/mut T Fixes #84213,ROCKET,2021-04-16T04:53:15Z,nschoellhorn,NA https://github.com/rust-lang/rust/pull/84243,MERGED,2021-04-16T14:34:27Z,2021-04-17T07:17:30Z,Builtin derive macros: fix error with const generics default,Soveu,57e28ef86fdf528d1e348312f5b2775d9de2cbd0,2,Auto merge of #84243 - Soveu:fix-derive-macro-const-default r=petrochenkov Builtin derive macros: fix error with const generics default This fixes a bug where builtin derive macros (like Clone Debug) would basically copy-paste the default from a const generic causing a compile error with very confusing message - it would say defaults are not allowed in impl blocks while pointing at struct/enum/union definition.,THUMBS_UP,2021-04-16T22:19:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-17T20:35:47Z,jabedude,sinisterpatrician@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-17T21:16:53Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-17T23:15:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-19T01:08:34Z,bingxio,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-19T13:58:42Z,g2p,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-22T17:49:31Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-22T20:42:40Z,bensadiku,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-22T22:02:32Z,sternenseemann,sternenseemann@systemli.org https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-24T09:16:03Z,iamwwc,qaq1362211689@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-04-25T19:52:45Z,jhartzell42,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-06T04:37:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-06T08:53:44Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-06T12:18:02Z,Zymlex,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-06T12:38:38Z,funbringer,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-07T05:27:30Z,gz,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-24T08:34:45Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-05-27T21:14:18Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-06-17T09:49:14Z,jplatte,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-06-22T13:09:18Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-07-06T16:25:26Z,nathankleyn,nathan@nathankleyn.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-07-06T17:52:07Z,nfriedly,nathan@nfriedly.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-07-06T19:53:39Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-07-06T22:48:37Z,aaronjanse,aaron@ajanse.me https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-11-20T17:44:50Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-12-08T00:55:32Z,Bernd-L,git@bernd.pw https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2021-12-18T04:42:56Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2022-04-27T10:52:50Z,seandewar,NA https://github.com/rust-lang/rust/pull/84266,MERGED,2021-04-17T02:51:02Z,2021-05-06T07:02:18Z,alloc: Add unstable Cfg feature `no_global_oom_handling,Ericson2314,d620ae10709ca3669cda89db8b29afcd9accc188,18,"Auto merge of #84266 - QuiltOS:statically-disallow-global-oom-handling r=Mark-Simulacrum alloc: Add unstable Cfg feature `no-global_oom_handling For certain sorts of systems programming it's deemed essential that all allocation failures be explicitly handled where they occur. For example see Linus Torvald's opinion in [1]. Merely not calling global panic handlers or always `try_reserving` first (for vectors) is not deemed good enough because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc` rolling their own allocation abstractions. But this would in my opinion be a real shame. `alloc` has a few `try_*` methods already and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature but there are currently uncertainties around how std library crate's Cargo features may or not be stable so to avoid any risk of stabilizing by mistake we are going with a more low-level ""raw cfg"" token which cannot be interacted with via Cargo alone. Note also that since there is no notion of ""default cfg tokens"" outside of Cargo features we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility) but it doesn't matter for raw cfg tokens which are not intended to be ""constraint solved"" by Cargo or anything else. To support this use-case we create a new feature ""global-oom-handling"" on by default and put the global OOM handler infra and everything else it that depends on it behind it. By default nothing is changed but users concerned about global handling can make sure it is disabled and be confident that all OOM handling is local and explicit. For this first iteration non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods but are kept anyways since they can be oom-safely created ""from parts"" and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/",THUMBS_UP,2022-06-23T09:07:23Z,bb010g,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-04-17T04:23:56Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-04-17T07:17:38Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-04-23T10:11:40Z,qy3u,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-04-29T16:43:59Z,a1phyr,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-09-17T12:31:00Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-09-18T19:26:54Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-09-19T18:02:47Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-09-23T04:56:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84267,MERGED,2021-04-17T03:58:09Z,2021-10-03T03:22:38Z,Make *const () *mut () okay for FFI,dtolnay,c70b35efd8ed4d2e85a468c6519300c16609cdab,5,"Auto merge of #84267 - dtolnay:ptrunit r=nagisa Make *const () *mut () okay for FFI Pointer-to-() is used occasionally in the standard library to mean ""pointer to none-of-your-business"". Examples: - `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new - `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts I believe it's useful for the same purpose in FFI signatures even while `()` itself is not FFI safe. The following should be allowed: ```rust extern ""C"" { fn demo(pc: *const () pm: *mut ()); } ``` Prior to this PR those pointers were not considered okay for an extern signature. ```console warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:17 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = help: consider using a struct instead = note: tuples have unspecified layout warning: `extern` block uses type `()` which is not FFI-safe --> src/main.rs:2:32 | 2 | fn demo(pc: *const () pm: *mut ()); | ^^^^^^^ not FFI-safe | = help: consider using a struct instead = note: tuples have unspecified layout ```",HEART,2021-10-11T04:42:20Z,yvan-sraka,yvan@sraka.xyz https://github.com/rust-lang/rust/pull/84278,MERGED,2021-04-17T20:01:44Z,2021-05-12T08:38:05Z,Implement span quoting for proc-macros,Aaron1011,c1e7e361f7cddd1fe9b3bfef71a6539d2570e4fb,37,Auto merge of #84278 - Aaron1011:feature/new-proc-macro-meta-span r=estebank Implement span quoting for proc-macros This PR implements span quoting allowing proc-macros to produce spans pointing *into their own crate*. This is used by the unstable `proc_macro::quote!` macro allowing us to get error messages like this: ``` error[E0412]: cannot find type `MissingType` in this scope --> $DIR/auxiliary/span-from-proc-macro.rs:37:20 | LL | pub fn error_from_attribute(_args: TokenStream _input: TokenStream) -> TokenStream { | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]` ... LL | field: MissingType | ^^^^^^^^^^^ not found in this scope | ::: $DIR/span-from-proc-macro.rs:8:1 | LL | #[error_from_attribute] | ----------------------- in this macro invocation ``` Here `MissingType` occurs inside the implementation of the proc-macro `#[error_from_attribute]`. Previosuly this would always result in a span pointing at `#[error_from_attribute]` This will make many proc-macro-related error message much more useful - when a proc-macro generates code containing an error users will get an error message pointing directly at that code (within the macro definition) instead of always getting a span pointing at the macro invocation site. This is implemented as follows: * When a proc-macro crate is being *compiled* it causes the `quote!` macro to get run. This saves all of the sapns in the input to `quote!` into the metadata of *the proc-macro-crate* (which we are currently compiling). The `quote!` macro then expands to a call to `proc_macro::Span::recover_proc_macro_span(id)` where `id` is an opaque identifier for the span in the crate metadata. * When the same proc-macro crate is *run* (e.g. it is loaded from disk and invoked by some consumer crate) the call to `proc_macro::Span::recover_proc_macro_span` causes us to load the span from the proc-macro crate's metadata. The proc-macro then produces a `TokenStream` containing a `Span` pointing into the proc-macro crate itself. The recursive nature of 'quote!' can be difficult to understand at first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows the output of the `quote!` macro which should make this eaier to understand. This PR also supports custom quoting spans in custom quote macros (e.g. the `quote` crate). All span quoting goes through the `proc_macro::quote_span` method which can be called by a custom quote macro to perform span quoting. An example of this usage is provided in `src/test/ui/proc-macro/auxiliary/custom-quote.rs` Custom quoting currently has a few limitations: In order to quote a span we need to generate a call to `proc_macro::Span::recover_proc_macro_span`. However proc-macros support renaming the `proc_macro` crate so we can't simply hardcode this path. Previously the `quote_span` method used the path `crate::Span` - however this only works when it is called by the builtin `quote!` macro in the same crate. To support being called from arbitrary crates we need access to the name of the `proc_macro` crate to generate a path. This PR adds an additional argument to `quote_span` to specify the name of the `proc_macro` crate. Howver this feels kind of hacky and we may want to change this before stabilizing anything quote-related. Additionally using `quote_span` currently requires enabling the `proc_macro_internals` feature. The builtin `quote!` macro has an `#[allow_internal_unstable]` attribute but this won't work for custom quote implementations. This will likely require some additional tricks to apply `allow_internal_unstable` to the span of `proc_macro::Span::recover_proc_macro_span`.,HEART,2021-04-18T00:41:38Z,estebank,NA https://github.com/rust-lang/rust/pull/84278,MERGED,2021-04-17T20:01:44Z,2021-05-12T08:38:05Z,Implement span quoting for proc-macros,Aaron1011,c1e7e361f7cddd1fe9b3bfef71a6539d2570e4fb,37,Auto merge of #84278 - Aaron1011:feature/new-proc-macro-meta-span r=estebank Implement span quoting for proc-macros This PR implements span quoting allowing proc-macros to produce spans pointing *into their own crate*. This is used by the unstable `proc_macro::quote!` macro allowing us to get error messages like this: ``` error[E0412]: cannot find type `MissingType` in this scope --> $DIR/auxiliary/span-from-proc-macro.rs:37:20 | LL | pub fn error_from_attribute(_args: TokenStream _input: TokenStream) -> TokenStream { | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]` ... LL | field: MissingType | ^^^^^^^^^^^ not found in this scope | ::: $DIR/span-from-proc-macro.rs:8:1 | LL | #[error_from_attribute] | ----------------------- in this macro invocation ``` Here `MissingType` occurs inside the implementation of the proc-macro `#[error_from_attribute]`. Previosuly this would always result in a span pointing at `#[error_from_attribute]` This will make many proc-macro-related error message much more useful - when a proc-macro generates code containing an error users will get an error message pointing directly at that code (within the macro definition) instead of always getting a span pointing at the macro invocation site. This is implemented as follows: * When a proc-macro crate is being *compiled* it causes the `quote!` macro to get run. This saves all of the sapns in the input to `quote!` into the metadata of *the proc-macro-crate* (which we are currently compiling). The `quote!` macro then expands to a call to `proc_macro::Span::recover_proc_macro_span(id)` where `id` is an opaque identifier for the span in the crate metadata. * When the same proc-macro crate is *run* (e.g. it is loaded from disk and invoked by some consumer crate) the call to `proc_macro::Span::recover_proc_macro_span` causes us to load the span from the proc-macro crate's metadata. The proc-macro then produces a `TokenStream` containing a `Span` pointing into the proc-macro crate itself. The recursive nature of 'quote!' can be difficult to understand at first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows the output of the `quote!` macro which should make this eaier to understand. This PR also supports custom quoting spans in custom quote macros (e.g. the `quote` crate). All span quoting goes through the `proc_macro::quote_span` method which can be called by a custom quote macro to perform span quoting. An example of this usage is provided in `src/test/ui/proc-macro/auxiliary/custom-quote.rs` Custom quoting currently has a few limitations: In order to quote a span we need to generate a call to `proc_macro::Span::recover_proc_macro_span`. However proc-macros support renaming the `proc_macro` crate so we can't simply hardcode this path. Previously the `quote_span` method used the path `crate::Span` - however this only works when it is called by the builtin `quote!` macro in the same crate. To support being called from arbitrary crates we need access to the name of the `proc_macro` crate to generate a path. This PR adds an additional argument to `quote_span` to specify the name of the `proc_macro` crate. Howver this feels kind of hacky and we may want to change this before stabilizing anything quote-related. Additionally using `quote_span` currently requires enabling the `proc_macro_internals` feature. The builtin `quote!` macro has an `#[allow_internal_unstable]` attribute but this won't work for custom quote implementations. This will likely require some additional tricks to apply `allow_internal_unstable` to the span of `proc_macro::Span::recover_proc_macro_span`.,HEART,2021-05-20T04:28:45Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84278,MERGED,2021-04-17T20:01:44Z,2021-05-12T08:38:05Z,Implement span quoting for proc-macros,Aaron1011,c1e7e361f7cddd1fe9b3bfef71a6539d2570e4fb,37,Auto merge of #84278 - Aaron1011:feature/new-proc-macro-meta-span r=estebank Implement span quoting for proc-macros This PR implements span quoting allowing proc-macros to produce spans pointing *into their own crate*. This is used by the unstable `proc_macro::quote!` macro allowing us to get error messages like this: ``` error[E0412]: cannot find type `MissingType` in this scope --> $DIR/auxiliary/span-from-proc-macro.rs:37:20 | LL | pub fn error_from_attribute(_args: TokenStream _input: TokenStream) -> TokenStream { | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]` ... LL | field: MissingType | ^^^^^^^^^^^ not found in this scope | ::: $DIR/span-from-proc-macro.rs:8:1 | LL | #[error_from_attribute] | ----------------------- in this macro invocation ``` Here `MissingType` occurs inside the implementation of the proc-macro `#[error_from_attribute]`. Previosuly this would always result in a span pointing at `#[error_from_attribute]` This will make many proc-macro-related error message much more useful - when a proc-macro generates code containing an error users will get an error message pointing directly at that code (within the macro definition) instead of always getting a span pointing at the macro invocation site. This is implemented as follows: * When a proc-macro crate is being *compiled* it causes the `quote!` macro to get run. This saves all of the sapns in the input to `quote!` into the metadata of *the proc-macro-crate* (which we are currently compiling). The `quote!` macro then expands to a call to `proc_macro::Span::recover_proc_macro_span(id)` where `id` is an opaque identifier for the span in the crate metadata. * When the same proc-macro crate is *run* (e.g. it is loaded from disk and invoked by some consumer crate) the call to `proc_macro::Span::recover_proc_macro_span` causes us to load the span from the proc-macro crate's metadata. The proc-macro then produces a `TokenStream` containing a `Span` pointing into the proc-macro crate itself. The recursive nature of 'quote!' can be difficult to understand at first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows the output of the `quote!` macro which should make this eaier to understand. This PR also supports custom quoting spans in custom quote macros (e.g. the `quote` crate). All span quoting goes through the `proc_macro::quote_span` method which can be called by a custom quote macro to perform span quoting. An example of this usage is provided in `src/test/ui/proc-macro/auxiliary/custom-quote.rs` Custom quoting currently has a few limitations: In order to quote a span we need to generate a call to `proc_macro::Span::recover_proc_macro_span`. However proc-macros support renaming the `proc_macro` crate so we can't simply hardcode this path. Previously the `quote_span` method used the path `crate::Span` - however this only works when it is called by the builtin `quote!` macro in the same crate. To support being called from arbitrary crates we need access to the name of the `proc_macro` crate to generate a path. This PR adds an additional argument to `quote_span` to specify the name of the `proc_macro` crate. Howver this feels kind of hacky and we may want to change this before stabilizing anything quote-related. Additionally using `quote_span` currently requires enabling the `proc_macro_internals` feature. The builtin `quote!` macro has an `#[allow_internal_unstable]` attribute but this won't work for custom quote implementations. This will likely require some additional tricks to apply `allow_internal_unstable` to the span of `proc_macro::Span::recover_proc_macro_span`.,HEART,2021-05-20T06:14:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84278,MERGED,2021-04-17T20:01:44Z,2021-05-12T08:38:05Z,Implement span quoting for proc-macros,Aaron1011,c1e7e361f7cddd1fe9b3bfef71a6539d2570e4fb,37,Auto merge of #84278 - Aaron1011:feature/new-proc-macro-meta-span r=estebank Implement span quoting for proc-macros This PR implements span quoting allowing proc-macros to produce spans pointing *into their own crate*. This is used by the unstable `proc_macro::quote!` macro allowing us to get error messages like this: ``` error[E0412]: cannot find type `MissingType` in this scope --> $DIR/auxiliary/span-from-proc-macro.rs:37:20 | LL | pub fn error_from_attribute(_args: TokenStream _input: TokenStream) -> TokenStream { | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]` ... LL | field: MissingType | ^^^^^^^^^^^ not found in this scope | ::: $DIR/span-from-proc-macro.rs:8:1 | LL | #[error_from_attribute] | ----------------------- in this macro invocation ``` Here `MissingType` occurs inside the implementation of the proc-macro `#[error_from_attribute]`. Previosuly this would always result in a span pointing at `#[error_from_attribute]` This will make many proc-macro-related error message much more useful - when a proc-macro generates code containing an error users will get an error message pointing directly at that code (within the macro definition) instead of always getting a span pointing at the macro invocation site. This is implemented as follows: * When a proc-macro crate is being *compiled* it causes the `quote!` macro to get run. This saves all of the sapns in the input to `quote!` into the metadata of *the proc-macro-crate* (which we are currently compiling). The `quote!` macro then expands to a call to `proc_macro::Span::recover_proc_macro_span(id)` where `id` is an opaque identifier for the span in the crate metadata. * When the same proc-macro crate is *run* (e.g. it is loaded from disk and invoked by some consumer crate) the call to `proc_macro::Span::recover_proc_macro_span` causes us to load the span from the proc-macro crate's metadata. The proc-macro then produces a `TokenStream` containing a `Span` pointing into the proc-macro crate itself. The recursive nature of 'quote!' can be difficult to understand at first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows the output of the `quote!` macro which should make this eaier to understand. This PR also supports custom quoting spans in custom quote macros (e.g. the `quote` crate). All span quoting goes through the `proc_macro::quote_span` method which can be called by a custom quote macro to perform span quoting. An example of this usage is provided in `src/test/ui/proc-macro/auxiliary/custom-quote.rs` Custom quoting currently has a few limitations: In order to quote a span we need to generate a call to `proc_macro::Span::recover_proc_macro_span`. However proc-macros support renaming the `proc_macro` crate so we can't simply hardcode this path. Previously the `quote_span` method used the path `crate::Span` - however this only works when it is called by the builtin `quote!` macro in the same crate. To support being called from arbitrary crates we need access to the name of the `proc_macro` crate to generate a path. This PR adds an additional argument to `quote_span` to specify the name of the `proc_macro` crate. Howver this feels kind of hacky and we may want to change this before stabilizing anything quote-related. Additionally using `quote_span` currently requires enabling the `proc_macro_internals` feature. The builtin `quote!` macro has an `#[allow_internal_unstable]` attribute but this won't work for custom quote implementations. This will likely require some additional tricks to apply `allow_internal_unstable` to the span of `proc_macro::Span::recover_proc_macro_span`.,HEART,2021-05-25T14:01:23Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/84283,MERGED,2021-04-18T01:26:08Z,2021-04-19T10:14:02Z,rustdoc: Reduce visual weight of attributes.,jsha,62652865b6029b4776a7c03efa13a37b15c9b953,5,Auto merge of #84283 - jsha:de-emphasize-attributes r=GuillaumeGomez rustdoc: Reduce visual weight of attributes. Followup from #83337. As part of that PR we stopped hiding attributes behind a toggle because most things have just zero or one attributes. However this made clear that the current rendering of attributes emphasizes them a lot which distracts from function signatures. This PR changes their color of attributes to be the same as the toggles and reduces their font weight. This also removes `#[lang]` from the list of ALLOWED_ATTRIBUTES. This attribute is an implementation detail rather than part of the public-facing documentation. ![image](https://user-images.githubusercontent.com/220205/115131061-cc407d80-9fa9-11eb-9a77-ad3f3217f391.png) Demo at https://hoffman-andrews.com/rust/de-emph-attr/std/string/struct.String.html#method.trim,THUMBS_UP,2021-04-19T22:05:47Z,bluss,NA https://github.com/rust-lang/rust/pull/84288,MERGED,2021-04-18T06:09:11Z,2021-04-19T04:51:56Z,rustdoc: get rid of CURRENT_DEPTH,notriddle,8108e17faa6b413f9a0fc940b8d1f86608996166,3,Auto merge of #84288 - notriddle:short-links r=jyn514 rustdoc: get rid of CURRENT_DEPTH Fixes #82742,HEART,2021-04-19T04:48:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84289,MERGED,2021-04-18T06:38:53Z,2021-04-22T10:36:53Z,bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs,andersk,88b99dec2a4d103b8153ca9300bf0fbebdf65bda,2,Auto merge of #84289 - andersk:bootstrap-bulk-dir r=Mark-Simulacrum bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs The `--bulk-dirs` argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788) presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown. Fixes #80684. Cc `@pietroalbini.`,HEART,2021-04-18T13:36:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84289,MERGED,2021-04-18T06:38:53Z,2021-04-22T10:36:53Z,bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs,andersk,88b99dec2a4d103b8153ca9300bf0fbebdf65bda,2,Auto merge of #84289 - andersk:bootstrap-bulk-dir r=Mark-Simulacrum bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs The `--bulk-dirs` argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788) presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown. Fixes #80684. Cc `@pietroalbini.`,HEART,2021-04-18T18:08:54Z,daira,NA https://github.com/rust-lang/rust/pull/84289,MERGED,2021-04-18T06:38:53Z,2021-04-22T10:36:53Z,bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs,andersk,88b99dec2a4d103b8153ca9300bf0fbebdf65bda,2,Auto merge of #84289 - andersk:bootstrap-bulk-dir r=Mark-Simulacrum bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs The `--bulk-dirs` argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788) presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown. Fixes #80684. Cc `@pietroalbini.`,THUMBS_UP,2021-04-18T19:08:56Z,mbargull,NA https://github.com/rust-lang/rust/pull/84289,MERGED,2021-04-18T06:38:53Z,2021-04-22T10:36:53Z,bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs,andersk,88b99dec2a4d103b8153ca9300bf0fbebdf65bda,2,Auto merge of #84289 - andersk:bootstrap-bulk-dir r=Mark-Simulacrum bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs The `--bulk-dirs` argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788) presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown. Fixes #80684. Cc `@pietroalbini.`,HEART,2021-05-02T03:45:07Z,ben0x539,NA https://github.com/rust-lang/rust/pull/84289,MERGED,2021-04-18T06:38:53Z,2021-04-22T10:36:53Z,bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs,andersk,88b99dec2a4d103b8153ca9300bf0fbebdf65bda,2,Auto merge of #84289 - andersk:bootstrap-bulk-dir r=Mark-Simulacrum bootstrap: Restore missing --bulk-dirs for rust-docs rustc-docs The `--bulk-dirs` argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788) presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring `--bulk-dirs` reverses this slowdown. Fixes #80684. Cc `@pietroalbini.`,HEART,2021-05-06T12:53:37Z,FlorianFranzen,NA https://github.com/rust-lang/rust/pull/84294,MERGED,2021-04-18T09:34:09Z,2021-04-19T14:43:25Z,Slightly change wording in doc comment and fix typo in vec/mod.rs,WaffleLapkin,41f0e13bc53396852f4f1338ce5d8be0d1125b08,1,Auto merge of #84294 - WaffleLapkin:patch-2 r=jonas-schievink Slightly change wording in doc comment and fix typo in vec/mod.rs Suggested by `@pickfire` in https://github.com/rust-lang/rust/pull/82760,THUMBS_UP,2021-04-19T02:38:44Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84299,MERGED,2021-04-18T13:32:38Z,2021-04-25T16:41:49Z,various const parameter defaults improvements,lcnr,58bdb08947f5b3c18a2fbafc5cf36af7b5677d83,45,Auto merge of #84299 - lcnr:const-generics-defaults-name-res r=varkor various const parameter defaults improvements Actually resolve names in const parameter defaults fixing `struct Foo`. --- Split generic parameter ban rib for types and consts allowing ```rust #![feature(const_generics_defaults)] struct Q; struct Foo(T); ``` --- Remove the type/const ordering restriction if `const_generics_defaults` is active even if `const_generics` is not. allowing us to stabilize and test const param defaults separately. --- Check well formedness of const parameter defaults eagerly emitting an error for `struct Foo` --- Do not forbid const parameters in param defaults allowing `struct Foo(T)` and `struct Foo`. Note that this should not change anything which is stabilized as on stable type parameters must be in front of const parameters which means that type parameter defaults are only allowed if no const parameters exist. We still forbid generic parameters inside of const param types. r? `@varkor` `@petrochenkov`,HEART,2021-04-29T12:27:42Z,jplatte,NA https://github.com/rust-lang/rust/pull/84299,MERGED,2021-04-18T13:32:38Z,2021-04-25T16:41:49Z,various const parameter defaults improvements,lcnr,58bdb08947f5b3c18a2fbafc5cf36af7b5677d83,45,Auto merge of #84299 - lcnr:const-generics-defaults-name-res r=varkor various const parameter defaults improvements Actually resolve names in const parameter defaults fixing `struct Foo`. --- Split generic parameter ban rib for types and consts allowing ```rust #![feature(const_generics_defaults)] struct Q; struct Foo(T); ``` --- Remove the type/const ordering restriction if `const_generics_defaults` is active even if `const_generics` is not. allowing us to stabilize and test const param defaults separately. --- Check well formedness of const parameter defaults eagerly emitting an error for `struct Foo` --- Do not forbid const parameters in param defaults allowing `struct Foo(T)` and `struct Foo`. Note that this should not change anything which is stabilized as on stable type parameters must be in front of const parameters which means that type parameter defaults are only allowed if no const parameters exist. We still forbid generic parameters inside of const param types. r? `@varkor` `@petrochenkov`,HEART,2021-04-29T13:47:35Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/84299,MERGED,2021-04-18T13:32:38Z,2021-04-25T16:41:49Z,various const parameter defaults improvements,lcnr,58bdb08947f5b3c18a2fbafc5cf36af7b5677d83,45,Auto merge of #84299 - lcnr:const-generics-defaults-name-res r=varkor various const parameter defaults improvements Actually resolve names in const parameter defaults fixing `struct Foo`. --- Split generic parameter ban rib for types and consts allowing ```rust #![feature(const_generics_defaults)] struct Q; struct Foo(T); ``` --- Remove the type/const ordering restriction if `const_generics_defaults` is active even if `const_generics` is not. allowing us to stabilize and test const param defaults separately. --- Check well formedness of const parameter defaults eagerly emitting an error for `struct Foo` --- Do not forbid const parameters in param defaults allowing `struct Foo(T)` and `struct Foo`. Note that this should not change anything which is stabilized as on stable type parameters must be in front of const parameters which means that type parameter defaults are only allowed if no const parameters exist. We still forbid generic parameters inside of const param types. r? `@varkor` `@petrochenkov`,HEART,2021-05-14T09:04:03Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/84299,MERGED,2021-04-18T13:32:38Z,2021-04-25T16:41:49Z,various const parameter defaults improvements,lcnr,58bdb08947f5b3c18a2fbafc5cf36af7b5677d83,45,Auto merge of #84299 - lcnr:const-generics-defaults-name-res r=varkor various const parameter defaults improvements Actually resolve names in const parameter defaults fixing `struct Foo`. --- Split generic parameter ban rib for types and consts allowing ```rust #![feature(const_generics_defaults)] struct Q; struct Foo(T); ``` --- Remove the type/const ordering restriction if `const_generics_defaults` is active even if `const_generics` is not. allowing us to stabilize and test const param defaults separately. --- Check well formedness of const parameter defaults eagerly emitting an error for `struct Foo` --- Do not forbid const parameters in param defaults allowing `struct Foo(T)` and `struct Foo`. Note that this should not change anything which is stabilized as on stable type parameters must be in front of const parameters which means that type parameter defaults are only allowed if no const parameters exist. We still forbid generic parameters inside of const param types. r? `@varkor` `@petrochenkov`,HEART,2021-07-13T23:07:06Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/84313,MERGED,2021-04-18T17:41:28Z,2021-04-19T23:34:37Z,fix suggestion for unsized function parameters,lcnr,349fae3a32cfcb650f252104bb5c88ee32d9bebf,25,Rollup merge of #84313 - lcnr:sized-err-msg r=petrochenkov fix suggestion for unsized function parameters taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box,HEART,2021-04-18T21:22:08Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/84313,MERGED,2021-04-18T17:41:28Z,2021-04-19T23:34:37Z,fix suggestion for unsized function parameters,lcnr,349fae3a32cfcb650f252104bb5c88ee32d9bebf,25,Rollup merge of #84313 - lcnr:sized-err-msg r=petrochenkov fix suggestion for unsized function parameters taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box,THUMBS_UP,2021-04-27T01:19:44Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84313,MERGED,2021-04-18T17:41:28Z,2021-04-19T23:34:37Z,fix suggestion for unsized function parameters,lcnr,349fae3a32cfcb650f252104bb5c88ee32d9bebf,25,Rollup merge of #84313 - lcnr:sized-err-msg r=petrochenkov fix suggestion for unsized function parameters taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box,HEART,2021-04-28T07:07:42Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/84313,MERGED,2021-04-18T17:41:28Z,2021-04-19T23:34:37Z,fix suggestion for unsized function parameters,lcnr,349fae3a32cfcb650f252104bb5c88ee32d9bebf,25,Rollup merge of #84313 - lcnr:sized-err-msg r=petrochenkov fix suggestion for unsized function parameters taken from `@fasterthanlime's` article https://fasterthanli.me/articles/whats-in-the-box,HEART,2021-06-06T16:10:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/84323,MERGED,2021-04-18T22:09:53Z,2021-04-20T11:19:45Z,coverage of async function bodies should match non-async,richkadel,6af1e632a974b78b62895e8cb918b889cf613882,5,Auto merge of #84323 - richkadel:uncovered-functions r=tmandry coverage of async function bodies should match non-async This fixes some missing coverage within async function bodies. Commit 1 demonstrates the problem in the fixed issue and commit 2 corrects it. Fixes: #83985,THUMBS_UP,2021-04-19T04:39:25Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84323,MERGED,2021-04-18T22:09:53Z,2021-04-20T11:19:45Z,coverage of async function bodies should match non-async,richkadel,6af1e632a974b78b62895e8cb918b889cf613882,5,Auto merge of #84323 - richkadel:uncovered-functions r=tmandry coverage of async function bodies should match non-async This fixes some missing coverage within async function bodies. Commit 1 demonstrates the problem in the fixed issue and commit 2 corrects it. Fixes: #83985,THUMBS_UP,2021-04-19T20:14:24Z,wpbrown,NA https://github.com/rust-lang/rust/pull/84333,MERGED,2021-04-19T12:56:31Z,2021-08-25T08:12:24Z,Improve liveness analysis for generators,tmiasko,1a9ac38defd67ddb2b830005f8d760861c85a7a3,3,Auto merge of #84333 - tmiasko:liveness-yield r=tmandry Improve liveness analysis for generators Liveness analysis for generators assumes that execution always continues normally after a yield point not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference those variables could be used within a generator or when the generator completes but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point. Fixes #84292.,HEART,2021-04-19T16:13:00Z,Kestrer,NA https://github.com/rust-lang/rust/pull/84333,MERGED,2021-04-19T12:56:31Z,2021-08-25T08:12:24Z,Improve liveness analysis for generators,tmiasko,1a9ac38defd67ddb2b830005f8d760861c85a7a3,3,Auto merge of #84333 - tmiasko:liveness-yield r=tmandry Improve liveness analysis for generators Liveness analysis for generators assumes that execution always continues normally after a yield point not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference those variables could be used within a generator or when the generator completes but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point. Fixes #84292.,HEART,2021-08-14T04:45:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84333,MERGED,2021-04-19T12:56:31Z,2021-08-25T08:12:24Z,Improve liveness analysis for generators,tmiasko,1a9ac38defd67ddb2b830005f8d760861c85a7a3,3,Auto merge of #84333 - tmiasko:liveness-yield r=tmandry Improve liveness analysis for generators Liveness analysis for generators assumes that execution always continues normally after a yield point not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference those variables could be used within a generator or when the generator completes but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point. Fixes #84292.,HEART,2021-09-03T06:23:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84333,MERGED,2021-04-19T12:56:31Z,2021-08-25T08:12:24Z,Improve liveness analysis for generators,tmiasko,1a9ac38defd67ddb2b830005f8d760861c85a7a3,3,Auto merge of #84333 - tmiasko:liveness-yield r=tmandry Improve liveness analysis for generators Liveness analysis for generators assumes that execution always continues normally after a yield point not accounting for the fact that generator could be dropped before completion. If generators captures any variables by reference those variables could be used within a generator or when the generator completes but also after each yield point in the case the generator is dropped. Account for the case when generator is dropped after yielding but before running to the completion. This effectively considers all variables captured by reference to be used after a yield point. Fixes #84292.,HEART,2021-09-03T06:25:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",EYES,2021-04-19T18:10:59Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-20T03:24:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-20T04:51:47Z,CryZe,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",EYES,2021-04-20T06:09:50Z,CryZe,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-20T06:09:52Z,CryZe,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-21T02:47:10Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-21T02:47:11Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-23T19:49:30Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-29T09:25:00Z,Skgland,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-29T10:36:11Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-29T11:36:30Z,t-rapp,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-29T11:38:17Z,extrawurst,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-29T14:41:41Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-29T16:35:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-29T16:35:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",EYES,2021-04-29T16:35:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-30T01:03:12Z,funnyzpc,funnyzpc@gmail.com https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-04-30T19:03:18Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",HOORAY,2021-04-30T19:03:19Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",EYES,2021-04-30T19:03:20Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/84339,MERGED,2021-04-19T18:01:00Z,2021-04-23T21:04:01Z,rustc: Use LLVM's new saturating float-to-int intrinsics,alexcrichton,481ba16439299eb07058a7107352c558fdba7f96,7,"Auto merge of #84339 - alexcrichton:llvm-fptoint-sat r=nagisa rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc with an applicable LLVM version to use LLVM's new `llvm.fpto{u s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64 but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s u}i` instructions which only get used for ""out of bounds is undefined behavior"". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version but that will require sinking the complexity of it into other backends such as Cranelfit.",THUMBS_UP,2021-05-06T08:29:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84353,MERGED,2021-04-20T00:19:38Z,2021-04-20T16:47:01Z,Suggest `.as_ref()` on borrow error involving `Option`/`Result`,estebank,6df26f897cffb2d86880544bb451c6b5f8509b2d,7,Auto merge of #84353 - estebank:as-ref-mir r=davidtwco Suggest `.as_ref()` on borrow error involving `Option`/`Result` When encountering a E0382 borrow error involving an `Option` or `Result` provide a suggestion to use `.as_ref()` on the prior move location to avoid the move. Fix #84165.,HEART,2021-04-29T17:13:34Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-04-20T20:32:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-04-25T22:10:06Z,est31,NA https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-04-28T23:05:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-04-29T18:16:59Z,lqd,NA https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-07-18T00:44:33Z,estebank,NA https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-08-30T19:51:38Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2021-09-13T09:08:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84373,MERGED,2021-04-20T18:32:44Z,2021-09-12T02:36:02Z,Encode spans relative to the enclosing item,cjgillot,547d9374d26f203ab963b3ffe1ed36bd70f16633,68,Auto merge of #84373 - cjgillot:resolve-span r=michaelwoerister petrochenkov Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span` step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning so change the relative span's hash; - dirty `source_span` and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme I believe the dependency tracking to be accurate. For the moment the spans are marked during lowering. I'd rather do this during def-collection but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.,HEART,2022-05-24T13:37:16Z,laurmaedje,laurmaedje@gmail.com https://github.com/rust-lang/rust/pull/84379,MERGED,2021-04-20T21:42:06Z,2021-04-22T07:47:10Z,Add GAT related tests,marmeladema,e7f20335a66cb175a3754391b60c0a202410e5cf,12,Rollup merge of #84379 - marmeladema:test-for-issue-79949 r=jackh726 Add GAT related tests Closes #79949 Closes #79636 Closes #78671 Closes #70303 Closes #70304 Closes #71176,THUMBS_UP,2021-04-22T11:25:23Z,vandenheuvel,NA https://github.com/rust-lang/rust/pull/84379,MERGED,2021-04-20T21:42:06Z,2021-04-22T07:47:10Z,Add GAT related tests,marmeladema,e7f20335a66cb175a3754391b60c0a202410e5cf,12,Rollup merge of #84379 - marmeladema:test-for-issue-79949 r=jackh726 Add GAT related tests Closes #79949 Closes #79636 Closes #78671 Closes #70303 Closes #70304 Closes #71176,THUMBS_UP,2021-04-22T22:57:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84385,OPEN,2021-04-21T05:59:13Z,NA,Enforce that `closure: 'a` requires that `closure_ret_ty: 'a` holds,Aaron1011,NA,NA,NA,HEART,2021-04-21T13:07:18Z,iago-lito,NA https://github.com/rust-lang/rust/pull/84385,OPEN,2021-04-21T05:59:13Z,NA,Enforce that `closure: 'a` requires that `closure_ret_ty: 'a` holds,Aaron1011,NA,NA,NA,HEART,2021-05-04T22:12:55Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-21T16:27:52Z,bluss,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-21T18:06:38Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-22T03:58:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-22T19:19:08Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-29T05:07:47Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-29T06:01:59Z,tux3,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-29T10:55:28Z,dcormier,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-29T15:41:12Z,a1phyr,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-04-30T00:44:17Z,lukechu10,NA https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-05-01T00:45:22Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",HOORAY,2021-05-02T21:58:53Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-05-02T21:58:56Z,CleanCut,cleancut@github.com https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-05-03T19:24:19Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/84390,MERGED,2021-04-21T11:53:40Z,2021-04-22T07:47:09Z,Format `Struct { .. }` on one line even with `{:#?}`.,m-ou-se,49a5c80a3bbe96903be207ec04bb08bfd14cb9e4,2,"Rollup merge of #84390 - m-ou-se:make-debug-non-exhaustive-without-fields-a-little-bit-less-verbose r=kennytm Format `Struct { .. }` on one line even with `{:#?}`. The result of `debug_struct(""A"").finish_non_exhaustive()` before this change: ``` A { .. } ``` And after this change: ``` A { .. } ``` If there's any fields the result stays unchanged: ``` A { field: value .. }",THUMBS_UP,2021-05-05T01:18:46Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84406,MERGED,2021-04-21T19:58:13Z,2021-04-22T07:47:09Z,Remove `delete` alias from `mem::drop`.,m-ou-se,268d29d75d4ba1839e1c288cb7bd594e8bb9662f,1,Rollup merge of #84406 - m-ou-se:drop-delete-alias r=dtolnay Remove `delete` alias from `mem::drop`. See https://github.com/rust-lang/rust/pull/81988#issuecomment-824168459 and https://github.com/rust-lang/rust/pull/81988#issuecomment-824213843,THUMBS_UP,2021-04-22T03:57:55Z,scottmcm,NA https://github.com/rust-lang/rust/pull/84409,MERGED,2021-04-21T20:49:02Z,2021-05-07T03:57:18Z,Ensure TLS destructors run before thread joins in SGX,mzohreva,b30e428689c25a0934def940d397495315b1e62f,3,Rollup merge of #84409 - mzohreva:mz/tls-dtors-before-join r=jethrogb Ensure TLS destructors run before thread joins in SGX The excellent test is from ```@jethrogb``` For context see: https://github.com/rust-lang/rust/pull/83416#discussion_r617282907,HEART,2021-04-23T14:15:27Z,RalfJung,NA https://github.com/rust-lang/rust/pull/84414,CLOSED,2021-04-21T23:28:57Z,2022-04-21T19:38:56Z,Allow struct and enum to contain inner attrs,dtolnay,NA,NA,NA,THUMBS_UP,2021-06-29T05:31:26Z,gheoan,NA https://github.com/rust-lang/rust/pull/84414,CLOSED,2021-04-21T23:28:57Z,2022-04-21T19:38:56Z,Allow struct and enum to contain inner attrs,dtolnay,NA,NA,NA,THUMBS_UP,2022-03-24T06:52:35Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84444,MERGED,2021-04-22T18:31:50Z,2021-04-23T23:44:51Z,"doc: Get rid of ""[+] show undocumented items"" toggle on numeric From impls",notriddle,9ada731c65c7c12f46058cd4badf45af16c96bb5,1,"Rollup merge of #84444 - notriddle:num-docs-from-undocumented-items-toggle r=yaahc doc: Get rid of ""[+] show undocumented items"" toggle on numeric From impls On most From implementations the docstring is attached to the function. This is also how people have been [recommended] to do it. Screenshots: * [before](https://user-images.githubusercontent.com/1593513/115767662-323c5480-a35e-11eb-9918-98aba83e9183.png) * [after](https://user-images.githubusercontent.com/1593513/115767675-35374500-a35e-11eb-964f-c28eeb6c807a.png) [recommended]: https://github.com/rust-lang/rust/issues/51430#issuecomment-398322434",HEART,2021-04-23T07:38:11Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/84448,CLOSED,2021-04-22T20:24:14Z,2022-01-07T16:13:07Z,add env var to override sys::Instant::actually_monotonic() for windows and unix,the8472,NA,NA,NA,THUMBS_UP,2021-06-20T23:34:57Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-04-23T09:40:33Z,Lotterleben,NA https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-04-23T10:05:01Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-04-25T15:18:17Z,Milo123459,NA https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-04-26T02:32:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-05-06T14:32:21Z,estebank,NA https://github.com/rust-lang/rust/pull/84450,MERGED,2021-04-22T20:27:52Z,2021-04-26T01:54:32Z,Give a better error when `std` or `core` are missing,jyn514,379a55c64ef72df1c8272ac33ba730244d1395d4,4,Rollup merge of #84450 - jyn514:missing-std r=petrochenkov Give a better error when `std` or `core` are missing - Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this but it seems harmless enough and it will be a big help. - On nightly suggest using `cargo build -Z build-std` if `CARGO` is set - Add a note about `#![no_std]` if `std` is missing but not core - Add a note that std may be unsupported if `std` is missing but not core Fixes https://github.com/rust-lang/rust/issues/84418. r? `@petrochenkov`,HEART,2021-05-12T01:30:17Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84456,MERGED,2021-04-22T22:53:28Z,2021-04-23T23:44:51Z,Fix ICE if original_span(fn_sig) returns a span not in body sourcefile,richkadel,e07c7b5641893efccc9454a3775a4f34aa32ca0d,2,Rollup merge of #84456 - richkadel:issue-84421 r=tmandry Fix ICE if original_span(fn_sig) returns a span not in body sourcefile Fixes: #84421 r? ````@tmandry```` fyi: ````@wesleywiser```` ````@sdroege```` ````@rajivshah3````,HOORAY,2021-04-22T22:54:56Z,rajivshah3,rajivshah1@icloud.com https://github.com/rust-lang/rust/pull/84456,MERGED,2021-04-22T22:53:28Z,2021-04-23T23:44:51Z,Fix ICE if original_span(fn_sig) returns a span not in body sourcefile,richkadel,e07c7b5641893efccc9454a3775a4f34aa32ca0d,2,Rollup merge of #84456 - richkadel:issue-84421 r=tmandry Fix ICE if original_span(fn_sig) returns a span not in body sourcefile Fixes: #84421 r? ````@tmandry```` fyi: ````@wesleywiser```` ````@sdroege```` ````@rajivshah3````,HEART,2021-04-23T05:42:26Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/84460,MERGED,2021-04-23T00:16:11Z,2021-04-24T20:09:28Z,rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module,jyn514,b566d0ae12aa53bfddfeafa61eaca3057a2c8ab2,8,Rollup merge of #84460 - jyn514:doctree-is-crate r=camelid rustdoc: Remove unnecessary `is_crate` field from doctree::Module and clean::Module It can be calculated on-demand even without a TyCtxt. This also changed `json::conversions::from_item_kind` to take a whole item which avoids having to add more and more parameters. Helps with https://github.com/rust-lang/rust/issues/76382. r? ```@camelid```,HEART,2021-04-26T00:55:49Z,camelid,NA https://github.com/rust-lang/rust/pull/84471,MERGED,2021-04-23T04:34:11Z,2021-05-02T01:28:37Z,Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true`,jyn514,7e717e99be6d3418d44ec510e142484db12fd757,1,Auto merge of #84471 - jyn514:linkcheck-llvm r=Mark-Simulacrum Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true` Previously the LD_LIBRARY_PATH for the linkchecker looked like `build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib` because the linkchecker depends on the master copy of the standard library. This is true but doesn't include the library path for the compiler libraries: ``` /home/joshua/src/rust/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-12-rust-1.53.0-nightly.so: cannot open shared object file: No such file or directory ``` That file is in `build/x86_64-unknown-linux-gnu/stage1/lib/libLLVM-12-rust-1.53.0-nightly.so` which wasn't included in the dynamic path. This adds `build/x86_64-unknown-linux-gnu/stage1/lib` to the dynamic path for the linkchecker.,HEART,2021-04-24T13:12:10Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/84471,MERGED,2021-04-23T04:34:11Z,2021-05-02T01:28:37Z,Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true`,jyn514,7e717e99be6d3418d44ec510e142484db12fd757,1,Auto merge of #84471 - jyn514:linkcheck-llvm r=Mark-Simulacrum Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true` Previously the LD_LIBRARY_PATH for the linkchecker looked like `build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib` because the linkchecker depends on the master copy of the standard library. This is true but doesn't include the library path for the compiler libraries: ``` /home/joshua/src/rust/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-12-rust-1.53.0-nightly.so: cannot open shared object file: No such file or directory ``` That file is in `build/x86_64-unknown-linux-gnu/stage1/lib/libLLVM-12-rust-1.53.0-nightly.so` which wasn't included in the dynamic path. This adds `build/x86_64-unknown-linux-gnu/stage1/lib` to the dynamic path for the linkchecker.,THUMBS_UP,2021-04-24T13:12:12Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/84471,MERGED,2021-04-23T04:34:11Z,2021-05-02T01:28:37Z,Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true`,jyn514,7e717e99be6d3418d44ec510e142484db12fd757,1,Auto merge of #84471 - jyn514:linkcheck-llvm r=Mark-Simulacrum Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true` Previously the LD_LIBRARY_PATH for the linkchecker looked like `build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib` because the linkchecker depends on the master copy of the standard library. This is true but doesn't include the library path for the compiler libraries: ``` /home/joshua/src/rust/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-12-rust-1.53.0-nightly.so: cannot open shared object file: No such file or directory ``` That file is in `build/x86_64-unknown-linux-gnu/stage1/lib/libLLVM-12-rust-1.53.0-nightly.so` which wasn't included in the dynamic path. This adds `build/x86_64-unknown-linux-gnu/stage1/lib` to the dynamic path for the linkchecker.,HOORAY,2021-04-24T13:12:15Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/84480,CLOSED,2021-04-23T14:45:34Z,2021-06-06T14:00:42Z,Add new tool to check HTML,GuillaumeGomez,NA,NA,NA,EYES,2021-04-25T18:50:53Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84484,MERGED,2021-04-23T16:06:46Z,2021-04-29T07:42:30Z,Don't rebuild rustdoc and clippy after checking bootstrap,jyn514,43afe764dea3f3a8c0562c0f85c1cdcc59267cab,4,Rollup merge of #84484 - jyn514:check-tools r=Mark-Simulacrum Don't rebuild rustdoc and clippy after checking bootstrap This works by unconditionally passing -Z unstable-options to the compiler. This has no affect in practice since bootstrap doesn't use `deny(rustc::internal)`. Fixes https://github.com/rust-lang/rust/issues/82461. r? ```@Mark-Simulacrum```,HEART,2021-04-24T08:17:44Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/84498,MERGED,2021-04-23T23:40:20Z,2021-04-28T05:15:12Z,Update grab bag,workingjubilee,537544b1061467ee4b74ef7f552fab3d513e5caf,6,Auto merge of #84498 - workingjubilee:update-grab-bag r=Mark-Simulacrum Update grab bag This PR slides a bunch of crate versions forward until suddenly a bunch of deps fall out of the tree! In doing so this mostly picks up a version bump in the `redox_users` crate which makes most of the features default to optional. crossbeam-utils 0.7 => 0.8.3 (where applicable) https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-utils/CHANGELOG.md directories 3.0.1 => 3.0.2 ignore 0.4.16 => 0.4.17 tempfile 3.0.5 => tempfile 3.2 Removes constant_time_eq from deps exceptions Removes arrayref from deps exceptions And also removes: - blake2b_simd - const_fn (the package not the feature) - constant_time_eq - redox_users 0.3.4 - rust-argon2,HEART,2021-04-23T23:48:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/84498,MERGED,2021-04-23T23:40:20Z,2021-04-28T05:15:12Z,Update grab bag,workingjubilee,537544b1061467ee4b74ef7f552fab3d513e5caf,6,Auto merge of #84498 - workingjubilee:update-grab-bag r=Mark-Simulacrum Update grab bag This PR slides a bunch of crate versions forward until suddenly a bunch of deps fall out of the tree! In doing so this mostly picks up a version bump in the `redox_users` crate which makes most of the features default to optional. crossbeam-utils 0.7 => 0.8.3 (where applicable) https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-utils/CHANGELOG.md directories 3.0.1 => 3.0.2 ignore 0.4.16 => 0.4.17 tempfile 3.0.5 => tempfile 3.2 Removes constant_time_eq from deps exceptions Removes arrayref from deps exceptions And also removes: - blake2b_simd - const_fn (the package not the feature) - constant_time_eq - redox_users 0.3.4 - rust-argon2,HEART,2021-04-24T19:43:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84519,CLOSED,2021-04-24T12:47:53Z,2021-04-30T10:41:01Z,Use `sys::Mutex` instead of `sys_common::StaticMutex` in `sys`,CDirkx,NA,NA,NA,CONFUSED,2021-04-28T15:26:47Z,a1phyr,NA https://github.com/rust-lang/rust/pull/84568,MERGED,2021-04-25T22:57:56Z,2021-05-27T23:55:55Z,feat(libtest): Add JUnit formatter,andoriyu,1c6868aa21981b37cbd3fc95828ee3b0ac22d494,5,"Auto merge of #84568 - andoriyu:libtest/junit_formatter r=yaahc feat(libtest): Add JUnit formatter tracking issue: https://github.com/rust-lang/rust/issues/85563 Add an alternative formatter to `libtest`. Formatter produces valid xml that later can be interpreted as JUnit report. Caveats: - `timestamp` is required by schema but every viewer/parser ignores it. Attribute is not set to avoid depending on chrono; - Running all ""suits"" (unit tests doc-tests and integration tests) will produce a mess; - I couldn't find a way to get integration test binary name so it's just goes by ""integration""; Sample output for unit tests (pretty printed by 3rd party tool): ``` ``` Sample output for integration tests (pretty printed by 3rd party tool): ``` ``` Sample output for Doc-tests (pretty printed by 3rd party tool): ``` ```",HEART,2021-04-26T06:03:33Z,tschuett,NA https://github.com/rust-lang/rust/pull/84571,MERGED,2021-04-26T01:50:28Z,2021-05-17T14:42:59Z,Parse unnamed fields of struct and union type,jedel1043,9964284fed181676300aad693449f5b751e35ff2,19,Auto merge of #84571 - jedel1043:issue-49804-impl r=petrochenkov Parse unnamed fields of struct and union type Added the `unnamed_fields` feature gate. This is a prototype of [RFC 2102](https://github.com/rust-lang/rust/issues/49804) so any suggestions are greatly appreciated. r? `@petrochenkov`,HOORAY,2021-04-29T22:23:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/84601,MERGED,2021-04-26T19:28:01Z,2021-05-01T12:20:53Z,rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand,tdelabro,e30d952d8b8ed43a137f4e8f2286e74097d29ad8,6,Rollup merge of #84601 - tdelabro:rustdoc-get-rid-of-cache-extern_locations r=jyn514 rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand help #84588,HEART,2021-04-26T19:37:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84609,MERGED,2021-04-27T10:03:42Z,2021-04-27T14:50:44Z,Reorder the parameter descriptions of map_or and map_or_else,lefth,1919b3f22706fee0b2c6ac3d42316545900b7734,2,Auto merge of #84609 - lefth:master r=Dylan-DPC Reorder the parameter descriptions of map_or and map_or_else They were described backwards probably leading users to write arguments in the wrong order. Bug: #84608,THUMBS_UP,2021-06-30T20:12:56Z,zhaofengli,hello@zhaofeng.li https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-04-29T08:15:30Z,a1phyr,NA https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-04-29T09:27:23Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-04-29T17:18:37Z,Others,NA https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-04-30T12:21:27Z,Stargateur,NA https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-05-04T16:22:26Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-05-06T15:56:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-05-07T13:43:50Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84612,CLOSED,2021-04-27T12:33:51Z,2021-08-30T21:14:52Z,Use try_reserve and panic in Vec's io::Write,kornelski,NA,NA,NA,THUMBS_UP,2021-05-20T06:21:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84616,MERGED,2021-04-27T13:30:41Z,2021-04-28T10:46:11Z,Fix empty dom toggle,GuillaumeGomez,54ad5cb8f493a9233c70d6bffcc2f662ad2231cc,4,Rollup merge of #84616 - GuillaumeGomez:fix-empty-dom-toggle r=jsha Fix empty dom toggle Currently the empty impl blocks have toggles: ![Screenshot from 2021-04-27 15-15-03](https://user-images.githubusercontent.com/3050060/116249703-5ee0d980-a76d-11eb-9e15-738c06e4fb1b.png) So when you expand it nothing happens: ![Screenshot from 2021-04-27 15-15-07](https://user-images.githubusercontent.com/3050060/116249746-686a4180-a76d-11eb-8dc1-221ca0ac57c5.png) So now in case the impl block is empty we simply don't generate the details/summary wrapping (which also makes DOM lighter yeay!): ![Screenshot from 2021-04-27 15-14-15](https://user-images.githubusercontent.com/3050060/116249825-7a4be480-a76d-11eb-9637-b26151311ebd.png) r? `@jsha`,HOORAY,2021-04-27T16:40:51Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/84616,MERGED,2021-04-27T13:30:41Z,2021-04-28T10:46:11Z,Fix empty dom toggle,GuillaumeGomez,54ad5cb8f493a9233c70d6bffcc2f662ad2231cc,4,Rollup merge of #84616 - GuillaumeGomez:fix-empty-dom-toggle r=jsha Fix empty dom toggle Currently the empty impl blocks have toggles: ![Screenshot from 2021-04-27 15-15-03](https://user-images.githubusercontent.com/3050060/116249703-5ee0d980-a76d-11eb-9e15-738c06e4fb1b.png) So when you expand it nothing happens: ![Screenshot from 2021-04-27 15-15-07](https://user-images.githubusercontent.com/3050060/116249746-686a4180-a76d-11eb-8dc1-221ca0ac57c5.png) So now in case the impl block is empty we simply don't generate the details/summary wrapping (which also makes DOM lighter yeay!): ![Screenshot from 2021-04-27 15-14-15](https://user-images.githubusercontent.com/3050060/116249825-7a4be480-a76d-11eb-9637-b26151311ebd.png) r? `@jsha`,HOORAY,2021-04-27T20:58:24Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T19:37:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T19:39:44Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T20:09:52Z,lqd,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T20:20:27Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T20:31:15Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-27T21:28:26Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-04-27T21:28:28Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-04-27T21:28:31Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-04-27T21:28:33Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-04-27T21:28:35Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-28T02:54:33Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-04-28T02:54:34Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-04-28T02:54:36Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-04-28T02:54:37Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-04-28T02:54:37Z,calldata,jayphbee@163.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-04-28T03:36:47Z,tmandry,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-28T06:58:20Z,hyuuko,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-28T11:37:24Z,taiki-e,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-28T13:40:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-04-28T13:40:53Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-04-28T13:40:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-04-28T14:26:16Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-28T19:10:26Z,estebank,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-29T01:24:47Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-29T07:45:47Z,malthesr,malthe.rasmussen@bio.ku.dk https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-29T13:40:26Z,tema3210,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-04-29T13:40:28Z,tema3210,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-29T21:50:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-04-29T21:58:22Z,denzp,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-29T21:58:26Z,denzp,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-04-29T21:58:27Z,denzp,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-04-29T21:58:28Z,denzp,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-04-29T21:58:29Z,denzp,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-04-30T06:00:41Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-04-30T06:00:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-05-01T15:43:14Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-05-15T16:20:07Z,ljedrz,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-05-24T15:05:30Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-05-25T01:39:08Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-06-08T08:39:52Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-06-08T08:39:53Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-06-08T08:39:54Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-06-08T08:39:58Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-06-08T08:39:59Z,ahlinc,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-06-22T10:33:31Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-16T16:14:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-16T19:19:03Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-07-16T19:19:04Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-07-16T19:19:06Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,EYES,2021-07-16T19:19:07Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-16T21:40:14Z,vkorenev,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-17T00:49:48Z,Ixentus,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-17T01:33:12Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,THUMBS_UP,2021-07-17T07:45:14Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-07-17T07:45:15Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-07-17T07:45:16Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-07-19T09:34:24Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-07-24T15:37:30Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-08-03T00:45:15Z,saolof,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-08-03T00:45:17Z,saolof,NA https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HOORAY,2021-08-03T19:18:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,HEART,2021-08-03T19:18:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84623,MERGED,2021-04-27T18:57:15Z,2021-07-16T19:04:35Z,Make GATs no longer an incomplete feature,jackh726,c49895d9049f67e07e297ee487836a587f69690e,138,Auto merge of #84623 - jackh726:gats-incomplete r=nikomatsakis Make GATs no longer an incomplete feature Blocked on ~#84622~ ~#82272~ ~#76826~ r? `@nikomatsakis`,ROCKET,2021-08-03T19:18:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84624,MERGED,2021-04-27T19:32:55Z,2021-04-28T10:46:11Z,Make sentence in env::args_os' docs plain and simple,r00ster91,0e72e0fb7ff61c9793997a8fc6f57aa12297b0a6,1,Rollup merge of #84624 - r00ster91:patch-5 r=JohnTitor Make sentence in env::args_os' docs plain and simple Follow-up to #84551. See https://github.com/rust-lang/rust/pull/84551#discussion_r620728070 on why this makes more sense.,THUMBS_UP,2021-04-27T22:36:59Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/84636,MERGED,2021-04-27T23:03:46Z,2021-04-29T07:42:29Z,rustdoc: change aliases attribute to data-aliases,notriddle,43068063c041c7f62762fc52536e2b3e497b1789,3,"Rollup merge of #84636 - notriddle:data-aliases r=jyn514 GuillaumeGomez rustdoc: change aliases attribute to data-aliases The ""aliases"" attribute is not listed [on MDN] so it sounds like it's rustdoc-specific. We don't want to conflict with any attributes that are added to the spec in the future. [on MDN]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements",THUMBS_UP,2021-04-28T03:14:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84640,MERGED,2021-04-28T04:27:30Z,2022-01-08T08:55:36Z,Implement `TryFrom` for `u8`,ids1024,83de77dd5e2b853b95a12ac8c6cc202eec81892b,3,Rollup merge of #84640 - ids1024:u8_from_char r=m-ou-se Implement `TryFrom` for `u8` Previously suggested in https://github.com/rust-lang/rfcs/issues/2854. It makes sense to have this since `char` implements `From`. Likewise `u32` `u64` and `u128` (since #79502) implement `From`.,HOORAY,2022-01-14T22:12:21Z,Ten0,NA https://github.com/rust-lang/rust/pull/84640,MERGED,2021-04-28T04:27:30Z,2022-01-08T08:55:36Z,Implement `TryFrom` for `u8`,ids1024,83de77dd5e2b853b95a12ac8c6cc202eec81892b,3,Rollup merge of #84640 - ids1024:u8_from_char r=m-ou-se Implement `TryFrom` for `u8` Previously suggested in https://github.com/rust-lang/rfcs/issues/2854. It makes sense to have this since `char` implements `From`. Likewise `u32` `u64` and `u128` (since #79502) implement `From`.,HOORAY,2022-01-15T00:28:26Z,tux3,NA https://github.com/rust-lang/rust/pull/84640,MERGED,2021-04-28T04:27:30Z,2022-01-08T08:55:36Z,Implement `TryFrom` for `u8`,ids1024,83de77dd5e2b853b95a12ac8c6cc202eec81892b,3,Rollup merge of #84640 - ids1024:u8_from_char r=m-ou-se Implement `TryFrom` for `u8` Previously suggested in https://github.com/rust-lang/rfcs/issues/2854. It makes sense to have this since `char` implements `From`. Likewise `u32` `u64` and `u128` (since #79502) implement `From`.,HOORAY,2022-01-15T07:42:13Z,ibENPC,NA https://github.com/rust-lang/rust/pull/84640,MERGED,2021-04-28T04:27:30Z,2022-01-08T08:55:36Z,Implement `TryFrom` for `u8`,ids1024,83de77dd5e2b853b95a12ac8c6cc202eec81892b,3,Rollup merge of #84640 - ids1024:u8_from_char r=m-ou-se Implement `TryFrom` for `u8` Previously suggested in https://github.com/rust-lang/rfcs/issues/2854. It makes sense to have this since `char` implements `From`. Likewise `u32` `u64` and `u128` (since #79502) implement `From`.,HOORAY,2022-02-14T02:15:32Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84642,MERGED,2021-04-28T06:13:33Z,2021-04-28T10:46:11Z,Stabilize vec_extend_from_within,Amanieu,7ebe5b9e4d3edae756aa50e72d61ce88da5b773c,3,Rollup merge of #84642 - Amanieu:vec_extend_from_within r=dtolnay Stabilize vec_extend_from_within Closes #81656,HOORAY,2021-04-28T07:36:18Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/84642,MERGED,2021-04-28T06:13:33Z,2021-04-28T10:46:11Z,Stabilize vec_extend_from_within,Amanieu,7ebe5b9e4d3edae756aa50e72d61ce88da5b773c,3,Rollup merge of #84642 - Amanieu:vec_extend_from_within r=dtolnay Stabilize vec_extend_from_within Closes #81656,HOORAY,2021-05-06T09:51:23Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/84642,MERGED,2021-04-28T06:13:33Z,2021-04-28T10:46:11Z,Stabilize vec_extend_from_within,Amanieu,7ebe5b9e4d3edae756aa50e72d61ce88da5b773c,3,Rollup merge of #84642 - Amanieu:vec_extend_from_within r=dtolnay Stabilize vec_extend_from_within Closes #81656,HOORAY,2021-07-27T18:26:24Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/84653,CLOSED,2021-04-28T14:20:14Z,2021-04-29T20:39:10Z,Add HAS_RE_LATE_BOUND if there are bound vars,jackh726,NA,NA,NA,HEART,2021-04-28T18:12:02Z,richkadel,NA https://github.com/rust-lang/rust/pull/84662,MERGED,2021-04-28T17:06:06Z,2021-08-01T05:16:55Z,Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core,dtolnay,f381e77d3590bc36f09b0d48cffb504f92febf5e,7,"Auto merge of #84662 - dtolnay:unwindsafe r=Amanieu Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core They were previously only available in std::panic not core::panic. - https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind. ```rust // common library #![no_std] pub struct Thing { pub(crate) x: &'static (dyn SomeTrait + Send + Sync) } pub(crate) trait SomeTrait {...} ``` ```rust // downstream application fn main() { let thing: library::Thing = ...; let _ = std::panic::catch_unwind(|| { let _ = thing; }); // does not work :( } ``` See https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/src/gradient.rs#L7-L15 for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller as the `feature = ""std""` would become non-additive in that case. What happens without the UnwindSafe constraints: ```rust fn main() { let gradient = colorous::VIRIDIS; let _ = std::panic::catch_unwind(|| { let _ = gradient; }); } ``` ```console error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary --> src/main.rs:3:13 | 3 | let _ = std::panic::catch_unwind(|| { let _ = gradient; }); | ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary | ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40 | 430 | pub fn catch_unwind R + UnwindSafe R>(f: F) -> Result { | ---------- required by this bound in `catch_unwind` | = help: within `Gradient` the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `Gradient` = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient` = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]` ```",THUMBS_UP,2021-04-29T02:28:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84662,MERGED,2021-04-28T17:06:06Z,2021-08-01T05:16:55Z,Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core,dtolnay,f381e77d3590bc36f09b0d48cffb504f92febf5e,7,"Auto merge of #84662 - dtolnay:unwindsafe r=Amanieu Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core They were previously only available in std::panic not core::panic. - https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind. ```rust // common library #![no_std] pub struct Thing { pub(crate) x: &'static (dyn SomeTrait + Send + Sync) } pub(crate) trait SomeTrait {...} ``` ```rust // downstream application fn main() { let thing: library::Thing = ...; let _ = std::panic::catch_unwind(|| { let _ = thing; }); // does not work :( } ``` See https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/src/gradient.rs#L7-L15 for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller as the `feature = ""std""` would become non-additive in that case. What happens without the UnwindSafe constraints: ```rust fn main() { let gradient = colorous::VIRIDIS; let _ = std::panic::catch_unwind(|| { let _ = gradient; }); } ``` ```console error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary --> src/main.rs:3:13 | 3 | let _ = std::panic::catch_unwind(|| { let _ = gradient; }); | ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary | ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40 | 430 | pub fn catch_unwind R + UnwindSafe R>(f: F) -> Result { | ---------- required by this bound in `catch_unwind` | = help: within `Gradient` the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `Gradient` = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient` = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]` ```",THUMBS_UP,2021-05-20T06:21:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84662,MERGED,2021-04-28T17:06:06Z,2021-08-01T05:16:55Z,Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core,dtolnay,f381e77d3590bc36f09b0d48cffb504f92febf5e,7,"Auto merge of #84662 - dtolnay:unwindsafe r=Amanieu Move UnwindSafe RefUnwindSafe AssertUnwindSafe to core They were previously only available in std::panic not core::panic. - https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html - https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind. ```rust // common library #![no_std] pub struct Thing { pub(crate) x: &'static (dyn SomeTrait + Send + Sync) } pub(crate) trait SomeTrait {...} ``` ```rust // downstream application fn main() { let thing: library::Thing = ...; let _ = std::panic::catch_unwind(|| { let _ = thing; }); // does not work :( } ``` See https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/src/gradient.rs#L7-L15 for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller as the `feature = ""std""` would become non-additive in that case. What happens without the UnwindSafe constraints: ```rust fn main() { let gradient = colorous::VIRIDIS; let _ = std::panic::catch_unwind(|| { let _ = gradient; }); } ``` ```console error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary --> src/main.rs:3:13 | 3 | let _ = std::panic::catch_unwind(|| { let _ = gradient; }); | ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary | ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40 | 430 | pub fn catch_unwind R + UnwindSafe R>(f: F) -> Result { | ---------- required by this bound in `catch_unwind` | = help: within `Gradient` the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` = note: required because it appears within the type `Gradient` = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient` = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]` ```",THUMBS_UP,2021-08-01T18:36:49Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/84663,MERGED,2021-04-28T17:19:26Z,2021-04-29T07:42:29Z,Remove `DropGuard` in `sys::windows::process` and use `StaticMutex` instead,CDirkx,ccd04a52810c596180486da8a2c2e157e63e3d2f,1,Rollup merge of #84663 - CDirkx:dropguard r=Mark-Simulacrum Remove `DropGuard` in `sys::windows::process` and use `StaticMutex` instead `StaticMutex` is a mutex that when locked provides a guard that unlocks the mutex again when dropped thus provides the exact same functionality as `DropGuard`. `StaticMutex` is used in more places and is thus preferred over an ad-hoc construct like `DropGuard`. ````@rustbot```` label: +T-libs-impl,THUMBS_UP,2021-04-28T22:05:41Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/84695,CLOSED,2021-04-29T14:01:48Z,2021-06-28T09:33:06Z,Add `Option::merge` under `option_merge` feature gate,WaffleLapkin,NA,NA,NA,THUMBS_UP,2021-06-28T15:28:29Z,uvicorn,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T15:36:14Z,jackh726,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T15:46:57Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T15:56:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T16:06:00Z,cramertj,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T16:09:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T19:36:17Z,lqd,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-04-29T21:54:33Z,denzp,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-05-01T18:13:28Z,mehcode,leckey.ryan@gmail.com https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-05-01T20:05:58Z,tmandry,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-05-13T07:16:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-05-18T02:42:45Z,Eucladia,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-05-25T20:07:53Z,ljedrz,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-07-06T08:53:39Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-07-27T07:55:21Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-07-29T22:45:14Z,worstpractice,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-07-30T05:10:57Z,ledyba-z,ryo.hirafuji@gmail.com https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-08-09T10:25:36Z,raghav-deepsource,NA https://github.com/rust-lang/rust/pull/84701,MERGED,2021-04-29T15:26:38Z,2021-05-27T04:08:23Z,stabilize member constraints,nikomatsakis,3530a7895acd495983a9cd6d7c5b2a9773337366,30,"Rollup merge of #84701 - nikomatsakis:stabilize-member-constraints-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/rust#61997](https://github.com/rust-lang/rust/issues/61997) | | Implementation history | [rust-lang/rust#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang/rust#61773] | [rust-lang/rust#61775]: https://github.com/rust-lang/rust/pull/61775 [rust-lang/rust#61773]: https://github.com/rust-lang/rust/issues/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/rust#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>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables described in [rust-lang/rust#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.",HOORAY,2021-08-15T11:08:36Z,kassane,matheus-catarino@hotmail.com https://github.com/rust-lang/rust/pull/84707,MERGED,2021-04-29T19:13:56Z,2021-05-04T23:26:10Z,Get rid of fake `DefId`s in rustdoc,Stupremee,ae8b84bf04cddda2379b36c45a575132e6a44fb0,28,Auto merge of #84707 - Stupremee:remove-fake-defids-in-rustdoc r=jyn514 GuillaumeGomez Get rid of fake `DefId`s in rustdoc Right now there are *many* errors left but I wanted to show the current state since all that is left to do is fixing the errors. Resolves #83183 r? `@jyn514`,HEART,2021-04-29T19:15:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84707,MERGED,2021-04-29T19:13:56Z,2021-05-04T23:26:10Z,Get rid of fake `DefId`s in rustdoc,Stupremee,ae8b84bf04cddda2379b36c45a575132e6a44fb0,28,Auto merge of #84707 - Stupremee:remove-fake-defids-in-rustdoc r=jyn514 GuillaumeGomez Get rid of fake `DefId`s in rustdoc Right now there are *many* errors left but I wanted to show the current state since all that is left to do is fixing the errors. Resolves #83183 r? `@jyn514`,HEART,2021-04-29T20:33:46Z,camelid,NA https://github.com/rust-lang/rust/pull/84707,MERGED,2021-04-29T19:13:56Z,2021-05-04T23:26:10Z,Get rid of fake `DefId`s in rustdoc,Stupremee,ae8b84bf04cddda2379b36c45a575132e6a44fb0,28,Auto merge of #84707 - Stupremee:remove-fake-defids-in-rustdoc r=jyn514 GuillaumeGomez Get rid of fake `DefId`s in rustdoc Right now there are *many* errors left but I wanted to show the current state since all that is left to do is fixing the errors. Resolves #83183 r? `@jyn514`,HEART,2021-04-29T22:01:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/84709,MERGED,2021-04-29T19:47:51Z,2021-05-05T20:07:30Z,Add doc alias for `chdir` to `std::env::set_current_dir`,joshtriplett,4c4b3e81df7c61b99fe1cef2ac581077e38c7467,1,Rollup merge of #84709 - joshtriplett:doc-alias-chdir r=dtolnay Add doc alias for `chdir` to `std::env::set_current_dir` Searching for `chdir` in the Rust documentation produces no useful results. I wrote some code recently that called `libc::chdir` and manually handled errors because I didn't realize that the safe `std::env::set_current_dir` existed. I searched for `chdir` and `change_dir` and `change_directory` (the latter two based on the precedent of unabbreviating set by `create_dir`) and I also read through `std::fs` expecting to potentially find it there. Given that none of those led to `std::env::set_current_dir` I think that provides sufficient justification to add this specific alias.,THUMBS_UP,2021-04-29T19:55:20Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/84709,MERGED,2021-04-29T19:47:51Z,2021-05-05T20:07:30Z,Add doc alias for `chdir` to `std::env::set_current_dir`,joshtriplett,4c4b3e81df7c61b99fe1cef2ac581077e38c7467,1,Rollup merge of #84709 - joshtriplett:doc-alias-chdir r=dtolnay Add doc alias for `chdir` to `std::env::set_current_dir` Searching for `chdir` in the Rust documentation produces no useful results. I wrote some code recently that called `libc::chdir` and manually handled errors because I didn't realize that the safe `std::env::set_current_dir` existed. I searched for `chdir` and `change_dir` and `change_directory` (the latter two based on the precedent of unabbreviating set by `create_dir`) and I also read through `std::fs` expecting to potentially find it there. Given that none of those led to `std::env::set_current_dir` I think that provides sufficient justification to add this specific alias.,THUMBS_UP,2021-05-01T16:44:28Z,dclong,NA https://github.com/rust-lang/rust/pull/84717,MERGED,2021-04-29T20:55:47Z,2021-05-20T10:23:04Z,impl FromStr for proc_macro::Literal,dtolnay,a1ac37289404cef53467e09bd3ff7e13ceb18bb6,7,"Rollup merge of #84717 - dtolnay:literalfromstr r=petrochenkov impl FromStr for proc_macro::Literal Note that unlike `impl FromStr for proc_macro::TokenStream` this impl does not permit whitespace or comments. The input string must consist of nothing but your literal. - `""1"".parse::()` ⟶ ok - `""1.0"".parse::()` ⟶ ok - `""'a'"".parse::()` ⟶ ok - `""\""\n\"""".parse::()` ⟶ ok - `""0 1"".parse::()` ⟶ LexError - `"" 0"".parse::()` ⟶ LexError - `""0 "".parse::()` ⟶ LexError - `""/* comment */0"".parse::()` ⟶ LexError - `""0/* comment */"".parse::()` ⟶ LexError - `""0// comment"".parse::()` ⟶ LexError --- ## Use case ```rust let hex_int: Literal = format!(""0x{:x}"" int).parse().unwrap(); ``` The only way this is expressible in the current API is significantly worse. ```rust let hex_int = match format!(""0x{:x}"" int) .parse::() .unwrap() .into_iter() .next() .unwrap() { TokenTree::Literal(literal) => literal _ => unreachable!() }; ```",THUMBS_UP,2021-04-30T00:44:35Z,taiki-e,NA https://github.com/rust-lang/rust/pull/84717,MERGED,2021-04-29T20:55:47Z,2021-05-20T10:23:04Z,impl FromStr for proc_macro::Literal,dtolnay,a1ac37289404cef53467e09bd3ff7e13ceb18bb6,7,"Rollup merge of #84717 - dtolnay:literalfromstr r=petrochenkov impl FromStr for proc_macro::Literal Note that unlike `impl FromStr for proc_macro::TokenStream` this impl does not permit whitespace or comments. The input string must consist of nothing but your literal. - `""1"".parse::()` ⟶ ok - `""1.0"".parse::()` ⟶ ok - `""'a'"".parse::()` ⟶ ok - `""\""\n\"""".parse::()` ⟶ ok - `""0 1"".parse::()` ⟶ LexError - `"" 0"".parse::()` ⟶ LexError - `""0 "".parse::()` ⟶ LexError - `""/* comment */0"".parse::()` ⟶ LexError - `""0/* comment */"".parse::()` ⟶ LexError - `""0// comment"".parse::()` ⟶ LexError --- ## Use case ```rust let hex_int: Literal = format!(""0x{:x}"" int).parse().unwrap(); ``` The only way this is expressible in the current API is significantly worse. ```rust let hex_int = match format!(""0x{:x}"" int) .parse::() .unwrap() .into_iter() .next() .unwrap() { TokenTree::Literal(literal) => literal _ => unreachable!() }; ```",THUMBS_UP,2021-05-06T06:10:39Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84717,MERGED,2021-04-29T20:55:47Z,2021-05-20T10:23:04Z,impl FromStr for proc_macro::Literal,dtolnay,a1ac37289404cef53467e09bd3ff7e13ceb18bb6,7,"Rollup merge of #84717 - dtolnay:literalfromstr r=petrochenkov impl FromStr for proc_macro::Literal Note that unlike `impl FromStr for proc_macro::TokenStream` this impl does not permit whitespace or comments. The input string must consist of nothing but your literal. - `""1"".parse::()` ⟶ ok - `""1.0"".parse::()` ⟶ ok - `""'a'"".parse::()` ⟶ ok - `""\""\n\"""".parse::()` ⟶ ok - `""0 1"".parse::()` ⟶ LexError - `"" 0"".parse::()` ⟶ LexError - `""0 "".parse::()` ⟶ LexError - `""/* comment */0"".parse::()` ⟶ LexError - `""0/* comment */"".parse::()` ⟶ LexError - `""0// comment"".parse::()` ⟶ LexError --- ## Use case ```rust let hex_int: Literal = format!(""0x{:x}"" int).parse().unwrap(); ``` The only way this is expressible in the current API is significantly worse. ```rust let hex_int = match format!(""0x{:x}"" int) .parse::() .unwrap() .into_iter() .next() .unwrap() { TokenTree::Literal(literal) => literal _ => unreachable!() }; ```",THUMBS_UP,2021-05-06T14:24:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84717,MERGED,2021-04-29T20:55:47Z,2021-05-20T10:23:04Z,impl FromStr for proc_macro::Literal,dtolnay,a1ac37289404cef53467e09bd3ff7e13ceb18bb6,7,"Rollup merge of #84717 - dtolnay:literalfromstr r=petrochenkov impl FromStr for proc_macro::Literal Note that unlike `impl FromStr for proc_macro::TokenStream` this impl does not permit whitespace or comments. The input string must consist of nothing but your literal. - `""1"".parse::()` ⟶ ok - `""1.0"".parse::()` ⟶ ok - `""'a'"".parse::()` ⟶ ok - `""\""\n\"""".parse::()` ⟶ ok - `""0 1"".parse::()` ⟶ LexError - `"" 0"".parse::()` ⟶ LexError - `""0 "".parse::()` ⟶ LexError - `""/* comment */0"".parse::()` ⟶ LexError - `""0/* comment */"".parse::()` ⟶ LexError - `""0// comment"".parse::()` ⟶ LexError --- ## Use case ```rust let hex_int: Literal = format!(""0x{:x}"" int).parse().unwrap(); ``` The only way this is expressible in the current API is significantly worse. ```rust let hex_int = match format!(""0x{:x}"" int) .parse::() .unwrap() .into_iter() .next() .unwrap() { TokenTree::Literal(literal) => literal _ => unreachable!() }; ```",THUMBS_UP,2021-05-31T00:47:55Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84719,MERGED,2021-04-29T21:28:39Z,2021-05-01T00:31:55Z,Move iter_results to dyn FnMut rather than a generic,Mark-Simulacrum,8a9fa3682dcf0de095ec308a29a7b19b0e011ef0,5,Auto merge of #84719 - Mark-Simulacrum:reduce-query-impl r=davidtwco Move iter_results to dyn FnMut rather than a generic This means that we're no longer generating the iteration/locking code for each invocation site of iter_results rather just once per query (roughly) which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold I suspect; the old solution didn't fully monomorphize either.,EYES,2021-04-30T02:46:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84719,MERGED,2021-04-29T21:28:39Z,2021-05-01T00:31:55Z,Move iter_results to dyn FnMut rather than a generic,Mark-Simulacrum,8a9fa3682dcf0de095ec308a29a7b19b0e011ef0,5,Auto merge of #84719 - Mark-Simulacrum:reduce-query-impl r=davidtwco Move iter_results to dyn FnMut rather than a generic This means that we're no longer generating the iteration/locking code for each invocation site of iter_results rather just once per query (roughly) which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold I suspect; the old solution didn't fully monomorphize either.,HEART,2021-04-30T02:47:59Z,camelid,NA https://github.com/rust-lang/rust/pull/84719,MERGED,2021-04-29T21:28:39Z,2021-05-01T00:31:55Z,Move iter_results to dyn FnMut rather than a generic,Mark-Simulacrum,8a9fa3682dcf0de095ec308a29a7b19b0e011ef0,5,Auto merge of #84719 - Mark-Simulacrum:reduce-query-impl r=davidtwco Move iter_results to dyn FnMut rather than a generic This means that we're no longer generating the iteration/locking code for each invocation site of iter_results rather just once per query (roughly) which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold I suspect; the old solution didn't fully monomorphize either.,HEART,2021-04-30T02:48:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84749,MERGED,2021-04-30T14:08:21Z,2021-05-01T12:20:52Z,Sync `rustc_codegen_cranelift`,XAMPPRocky,fc850b6c606ccf67e5ea88e94cf2188af62c67ff,43,Rollup merge of #84749 - XAMPPRocky:cranelift-rebase r=bjorn3 Sync `rustc_codegen_cranelift` Retrying #84746 r? ``@bjorn3`` --- Edit(bjorn3): Since the last sync there have been some refactorings around the driver code in preparation for a planned new feature. In addition ``@mominul`` implemented `-Ctarget-cpu` support and ``@XAMPPRocky`` fixed compilation of cg_clif itself for Windows with the MSVC toolchain.,HOORAY,2021-04-30T17:03:06Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/84751,MERGED,2021-04-30T14:24:44Z,2021-05-15T19:58:59Z,str::is_char_boundary - slight optimization,Soveu,62b834fb9f3e18d54e56d12824a9fa1780a5fc9d,1,Rollup merge of #84751 - Soveu:is_char_boundary_opt r=Amanieu str::is_char_boundary - slight optimization Current `str::is_char_boundary` implementation emits slightly more instructions because it includes an additional branch for `index == s.len()` ```rust pub fn is_char_boundary(s: &str index: usize) -> bool { if index == 0 || index == s.len() { return true; } match s.as_bytes().get(index) { None => false Some(&b) => (b as i8) >= -0x40 } } ``` Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)` ```rust pub fn is_char_boundary2(s: &str index: usize) -> bool { if index == 0 { return true; } match s.as_bytes().get(index) { // For some reason LLVM likes this comparison here more None => index == s.len() // This is bit magic equivalent to: b < 128 || b >= 192 Some(&b) => (b as i8) >= -0x40 } } ``` This one has better codegen on every platform except powerpc
x86 codegen

```nasm example::is_char_boundary: mov al 1 test rdx rdx je .LBB0_5 cmp rsi rdx je .LBB0_5 cmp rsi rdx jbe .LBB0_3 cmp byte ptr [rdi + rdx] -65 setg al .LBB0_5: ret .LBB0_3: xor eax eax ret example::is_char_boundary2: test rdx rdx je .LBB1_1 cmp rsi rdx jbe .LBB1_4 cmp byte ptr [rdi + rdx] -65 setg al ret .LBB1_1: ; technically this branch is the same as LBB1_4 mov al 1 ret .LBB1_4: sete al ret ```

aarch64 codegen

```as example::is_char_boundary: mov x8 x0 mov w0 #1 cbz x2 .LBB0_4 cmp x1 x2 b.eq .LBB0_4 b.ls .LBB0_5 ldrsb w8 [x8 x2] cmn w8 #65 cset w0 gt .LBB0_4: ret .LBB0_5: mov w0 wzr ret example::is_char_boundary2: cbz x2 .LBB1_3 cmp x1 x2 b.ls .LBB1_4 ldrsb w8 [x0 x2] cmn w8 #65 cset w0 gt ret .LBB1_3: mov w0 #1 ret .LBB1_4: cset w0 eq ret ```

riscv64gc codegen

example::is_char_boundary: seqz a3 a2 xor a4 a1 a2 seqz a4 a4 or a4 a4 a3 addi a3 zero 1 bnez a4 .LBB0_3 bgeu a2 a1 .LBB0_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a3 a1 a0 .LBB0_3: mv a0 a3 ret .LBB0_4: mv a0 zero ret example::is_char_boundary2: beqz a2 .LBB1_3 bgeu a2 a1 .LBB1_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a0 a1 a0 ret .LBB1_3: addi a0 zero 1 ret .LBB1_4: xor a0 a1 a2 seqz a0 a0 ret

[Link to godbolt](https://godbolt.org/z/K8avEz8Gr) `@rustbot` label: A-codegen,HEART,2021-05-17T22:10:29Z,bluss,NA https://github.com/rust-lang/rust/pull/84751,MERGED,2021-04-30T14:24:44Z,2021-05-15T19:58:59Z,str::is_char_boundary - slight optimization,Soveu,62b834fb9f3e18d54e56d12824a9fa1780a5fc9d,1,Rollup merge of #84751 - Soveu:is_char_boundary_opt r=Amanieu str::is_char_boundary - slight optimization Current `str::is_char_boundary` implementation emits slightly more instructions because it includes an additional branch for `index == s.len()` ```rust pub fn is_char_boundary(s: &str index: usize) -> bool { if index == 0 || index == s.len() { return true; } match s.as_bytes().get(index) { None => false Some(&b) => (b as i8) >= -0x40 } } ``` Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)` ```rust pub fn is_char_boundary2(s: &str index: usize) -> bool { if index == 0 { return true; } match s.as_bytes().get(index) { // For some reason LLVM likes this comparison here more None => index == s.len() // This is bit magic equivalent to: b < 128 || b >= 192 Some(&b) => (b as i8) >= -0x40 } } ``` This one has better codegen on every platform except powerpc
x86 codegen

```nasm example::is_char_boundary: mov al 1 test rdx rdx je .LBB0_5 cmp rsi rdx je .LBB0_5 cmp rsi rdx jbe .LBB0_3 cmp byte ptr [rdi + rdx] -65 setg al .LBB0_5: ret .LBB0_3: xor eax eax ret example::is_char_boundary2: test rdx rdx je .LBB1_1 cmp rsi rdx jbe .LBB1_4 cmp byte ptr [rdi + rdx] -65 setg al ret .LBB1_1: ; technically this branch is the same as LBB1_4 mov al 1 ret .LBB1_4: sete al ret ```

aarch64 codegen

```as example::is_char_boundary: mov x8 x0 mov w0 #1 cbz x2 .LBB0_4 cmp x1 x2 b.eq .LBB0_4 b.ls .LBB0_5 ldrsb w8 [x8 x2] cmn w8 #65 cset w0 gt .LBB0_4: ret .LBB0_5: mov w0 wzr ret example::is_char_boundary2: cbz x2 .LBB1_3 cmp x1 x2 b.ls .LBB1_4 ldrsb w8 [x0 x2] cmn w8 #65 cset w0 gt ret .LBB1_3: mov w0 #1 ret .LBB1_4: cset w0 eq ret ```

riscv64gc codegen

example::is_char_boundary: seqz a3 a2 xor a4 a1 a2 seqz a4 a4 or a4 a4 a3 addi a3 zero 1 bnez a4 .LBB0_3 bgeu a2 a1 .LBB0_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a3 a1 a0 .LBB0_3: mv a0 a3 ret .LBB0_4: mv a0 zero ret example::is_char_boundary2: beqz a2 .LBB1_3 bgeu a2 a1 .LBB1_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a0 a1 a0 ret .LBB1_3: addi a0 zero 1 ret .LBB1_4: xor a0 a1 a2 seqz a0 a0 ret

[Link to godbolt](https://godbolt.org/z/K8avEz8Gr) `@rustbot` label: A-codegen,HEART,2021-05-22T15:34:58Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/84751,MERGED,2021-04-30T14:24:44Z,2021-05-15T19:58:59Z,str::is_char_boundary - slight optimization,Soveu,62b834fb9f3e18d54e56d12824a9fa1780a5fc9d,1,Rollup merge of #84751 - Soveu:is_char_boundary_opt r=Amanieu str::is_char_boundary - slight optimization Current `str::is_char_boundary` implementation emits slightly more instructions because it includes an additional branch for `index == s.len()` ```rust pub fn is_char_boundary(s: &str index: usize) -> bool { if index == 0 || index == s.len() { return true; } match s.as_bytes().get(index) { None => false Some(&b) => (b as i8) >= -0x40 } } ``` Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)` ```rust pub fn is_char_boundary2(s: &str index: usize) -> bool { if index == 0 { return true; } match s.as_bytes().get(index) { // For some reason LLVM likes this comparison here more None => index == s.len() // This is bit magic equivalent to: b < 128 || b >= 192 Some(&b) => (b as i8) >= -0x40 } } ``` This one has better codegen on every platform except powerpc
x86 codegen

```nasm example::is_char_boundary: mov al 1 test rdx rdx je .LBB0_5 cmp rsi rdx je .LBB0_5 cmp rsi rdx jbe .LBB0_3 cmp byte ptr [rdi + rdx] -65 setg al .LBB0_5: ret .LBB0_3: xor eax eax ret example::is_char_boundary2: test rdx rdx je .LBB1_1 cmp rsi rdx jbe .LBB1_4 cmp byte ptr [rdi + rdx] -65 setg al ret .LBB1_1: ; technically this branch is the same as LBB1_4 mov al 1 ret .LBB1_4: sete al ret ```

aarch64 codegen

```as example::is_char_boundary: mov x8 x0 mov w0 #1 cbz x2 .LBB0_4 cmp x1 x2 b.eq .LBB0_4 b.ls .LBB0_5 ldrsb w8 [x8 x2] cmn w8 #65 cset w0 gt .LBB0_4: ret .LBB0_5: mov w0 wzr ret example::is_char_boundary2: cbz x2 .LBB1_3 cmp x1 x2 b.ls .LBB1_4 ldrsb w8 [x0 x2] cmn w8 #65 cset w0 gt ret .LBB1_3: mov w0 #1 ret .LBB1_4: cset w0 eq ret ```

riscv64gc codegen

example::is_char_boundary: seqz a3 a2 xor a4 a1 a2 seqz a4 a4 or a4 a4 a3 addi a3 zero 1 bnez a4 .LBB0_3 bgeu a2 a1 .LBB0_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a3 a1 a0 .LBB0_3: mv a0 a3 ret .LBB0_4: mv a0 zero ret example::is_char_boundary2: beqz a2 .LBB1_3 bgeu a2 a1 .LBB1_4 add a0 a0 a2 lb a0 0(a0) addi a1 zero -65 slt a0 a1 a0 ret .LBB1_3: addi a0 zero 1 ret .LBB1_4: xor a0 a1 a2 seqz a0 a0 ret

[Link to godbolt](https://godbolt.org/z/K8avEz8Gr) `@rustbot` label: A-codegen,HEART,2021-05-24T03:53:06Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84752,MERGED,2021-04-30T14:29:48Z,2021-05-02T17:20:55Z,Fix debuginfo for generators,lrh2000,25530538282b932472e7d6740142c970038ec222,7,Rollup merge of #84752 - lrh2000:generator-debuginfo r=tmandry Fix debuginfo for generators First all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part which gives an equivalent layout but offers us much better integration with debuggers. Second artificial flags in generator variants should be removed. - Literally variants are not artificial. We have `yield` statements upvars and inner variables in the source code. - Functionally we don't want debuggers to suppress the variants. It contains the state of the generator which is useful when debugging. So they shouldn't be marked artificial. - Debuggers may use artificial flags to find the active variant. In this case marking variants artificial will make debuggers not work properly. Fixes #62572. Fixes #79009. And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.,HEART,2021-05-01T22:47:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84752,MERGED,2021-04-30T14:29:48Z,2021-05-02T17:20:55Z,Fix debuginfo for generators,lrh2000,25530538282b932472e7d6740142c970038ec222,7,Rollup merge of #84752 - lrh2000:generator-debuginfo r=tmandry Fix debuginfo for generators First all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part which gives an equivalent layout but offers us much better integration with debuggers. Second artificial flags in generator variants should be removed. - Literally variants are not artificial. We have `yield` statements upvars and inner variables in the source code. - Functionally we don't want debuggers to suppress the variants. It contains the state of the generator which is useful when debugging. So they shouldn't be marked artificial. - Debuggers may use artificial flags to find the active variant. In this case marking variants artificial will make debuggers not work properly. Fixes #62572. Fixes #79009. And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.,HEART,2021-05-02T17:27:19Z,DianaNites,NA https://github.com/rust-lang/rust/pull/84753,MERGED,2021-04-30T14:43:33Z,2021-04-30T22:21:09Z,Update Miri,NA,NA,NA,NA,HEART,2021-04-30T14:45:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/84756,MERGED,2021-04-30T15:19:55Z,2021-05-01T12:20:52Z,Add a ToC to the Target Tier Policy documentation,badboy,08b2a457b958f2d2b96d7e7005a9ae3f68a20ca4,1,Rollup merge of #84756 - badboy:toc-for-tier-policy r=GuillaumeGomez Add a ToC to the Target Tier Policy documentation The policy document is quite lengthy I figured it might be good to have a quick way to jump to the specific tier policies.,THUMBS_UP,2021-04-30T19:50:06Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/84762,OPEN,2021-04-30T18:52:38Z,NA,Encode spans relative to the enclosing item -- enable by default,cjgillot,NA,NA,NA,HEART,2021-07-07T14:17:40Z,est31,NA https://github.com/rust-lang/rust/pull/84762,OPEN,2021-04-30T18:52:38Z,NA,Encode spans relative to the enclosing item -- enable by default,cjgillot,NA,NA,NA,HEART,2022-06-28T21:14:16Z,lqd,NA https://github.com/rust-lang/rust/pull/84762,OPEN,2021-04-30T18:52:38Z,NA,Encode spans relative to the enclosing item -- enable by default,cjgillot,NA,NA,NA,HEART,2022-06-28T21:15:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-01T16:44:13Z,jackh726,NA https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-01T17:19:14Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-03T03:28:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-04T01:52:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-05T19:01:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-12T16:55:29Z,estebank,NA https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-27T04:54:03Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-05-27T13:54:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/84767,MERGED,2021-04-30T23:41:48Z,2021-05-18T23:09:18Z,Implement the new desugaring from `try_trait_v2`,scottmcm,4e3e6db011c5b482d2bef8ba02274657f93b5e0d,91,Auto merge of #84767 - scottmcm:try_trait_actual r=lcnr Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782 which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things so if you have suggestions for good ways to split it up I'd be happy to hear them. (The combination between the use in the library the compiler changes the corresponding diagnostic differences even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.,HOORAY,2021-08-31T17:26:08Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/84775,CLOSED,2021-05-01T03:32:46Z,2021-05-01T13:27:00Z,Fix `x.py test --stage 0 src/tools/miri`,jyn514,NA,NA,NA,HEART,2021-05-01T11:20:51Z,RalfJung,NA https://github.com/rust-lang/rust/pull/84776,CLOSED,2021-05-01T03:51:39Z,2021-07-12T14:06:09Z,Fix `x.py doc --stage 1 src/tools/error_index_generator`,jyn514,NA,NA,NA,ROCKET,2021-05-01T04:21:05Z,Michael-F-Bryan,michaelfbryan@gmail.com https://github.com/rust-lang/rust/pull/84776,CLOSED,2021-05-01T03:51:39Z,2021-07-12T14:06:09Z,Fix `x.py doc --stage 1 src/tools/error_index_generator`,jyn514,NA,NA,NA,THUMBS_UP,2021-07-04T17:32:07Z,Alexhuszagh,ahuszagh@gmail.com https://github.com/rust-lang/rust/pull/84793,MERGED,2021-05-01T20:03:10Z,2021-05-12T18:55:24Z,Recover from invalid `struct` item syntax,estebank,94617802a154560d82f8dc0745219abcd800ff9b,4,"Rollup merge of #84793 - estebank:parse-struct-field-default r=davidtwco Recover from invalid `struct` item syntax Parse unsupported ""default field const values"": ```rust struct S { field: Type = const_val } ``` Recover from small `:` typo and provide suggestion: ```rust struct S { field; Type field2= Type } ```",THUMBS_UP,2021-05-25T00:52:12Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/84797,MERGED,2021-05-01T22:07:06Z,2021-05-07T12:47:54Z,Report coverage `0` of dead blocks,richkadel,e5f83d24aee866a14753a7cedbb4e301dfe5bef5,21,Auto merge of #84797 - richkadel:cover-unreachable-statements r=tmandry Report coverage `0` of dead blocks Fixes: #84018 With `-Z instrument-coverage` coverage reporting of dead blocks (for example blocks dropped because a conditional branch is dropped based on const evaluation) is now supported. If `instrument-coverage` is enabled `simplify::remove_dead_blocks()` finds all dropped coverage `Statement`s and adds their `code_region`s as `Unreachable` coverage `Statement`s to the `START_BLOCK` so they are still included in the coverage map. Check out the resulting changes in the test coverage reports in this PR (in [commit 1](https://github.com/rust-lang/rust/pull/84797/commits/0b0d293c7c46bdadf80e5304a667e34c53c0cf7e)). r? `@tmandry` cc: `@wesleywiser`,THUMBS_UP,2021-05-03T18:13:52Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84805,MERGED,2021-05-02T00:14:04Z,2021-05-02T11:43:38Z,Avoid generating QueryMap::extend for each key type,Mark-Simulacrum,3a1cd0ed368ea98fc67e8688dba5982a6aae62e0,1,Auto merge of #84805 - Mark-Simulacrum:no-dup-extend r=cjgillot Avoid generating QueryMap::extend for each key type Should be a small win on compile times for rustc_query_impl where this ends up getting codegen'd.,HEART,2021-05-02T03:25:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84806,MERGED,2021-05-02T00:15:51Z,2021-05-07T01:16:09Z,Streamline try_start code,Mark-Simulacrum,777bb2f6129e71a88ba030251eb370ef12fe28af,4,Auto merge of #84806 - Mark-Simulacrum:try-start-entry r=cjgillot Streamline try_start code This shifts some branches around and avoids interleaving parallel and non-parallel versions of the function too much.,HEART,2021-05-02T03:28:09Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84808,MERGED,2021-05-02T00:18:37Z,2021-05-05T20:07:30Z,Account for unsatisfied bounds in E0599,estebank,db77072a254f23b8671b263555ebe3ad88215f1e,3,Rollup merge of #84808 - estebank:issue-84769 r=petrochenkov Account for unsatisfied bounds in E0599 Fix #84769 follow up to #84499 #83667.,THUMBS_UP,2021-05-02T08:46:53Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/84815,MERGED,2021-05-02T09:29:30Z,2021-05-07T10:06:45Z,Update coverage docs and command line help,richkadel,283ef8678461f8052d6ab74d0687c00b4f5c9f9d,5,Rollup merge of #84815 - richkadel:coverage-docs-update-2021-05 r=tmandry Update coverage docs and command line help r? `@tmandry` cc: `@wesleywiser`,THUMBS_UP,2021-05-03T18:22:04Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84818,MERGED,2021-05-02T12:07:24Z,2021-05-03T02:30:03Z,suggestion for unit enum variant when matched with a patern,ABouttefeux,b0c7e64de0d2a7dfb172949c4d1cb01ee144025b,8,"Rollup merge of #84818 - ABouttefeux:enum-suggest r=jackh726 suggestion for unit enum variant when matched with a patern resolve #84700 add suggestion for code like ```rust enum FarmAnimal { Worm Cow Bull Chicken { num_eggs: usize } Dog (String) } fn what_does_the_animal_say(animal: &FarmAnimal) { let noise = match animal { FarmAnimal::Cow(_) => ""moo"".to_string() _ => todo!() }; println!(""{:?} says: {:?}"" animal noise); } ``` ``` error[E0532]: expected tuple struct or tuple variant found unit variant `FarmAnimal::Cow` --> $DIR/issue-84700.rs:15:9 | LL | Cow | --- `FarmAnimal::Cow` defined here ... LL | FarmAnimal::Cow(_) => ""moo"".to_string() | ^^^^^^^^^^^^^^^^^^ help: use this syntax instead: `FarmAnimal::Cow` ```",HOORAY,2021-05-05T04:03:14Z,lukechu10,NA https://github.com/rust-lang/rust/pull/84833,MERGED,2021-05-02T18:07:14Z,2021-05-04T05:40:24Z,const initialized thread locals in rustc,Mark-Simulacrum,0309953232d9957aef4c7c5a24fcb30735b2066b,5,"Auto merge of #84833 - Mark-Simulacrum:thread-local-consts r=varkor ""const"" initialized thread locals in rustc This appears to give a slight speedup on many of our benchmarks.",THUMBS_UP,2021-05-17T09:11:57Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/84834,MERGED,2021-05-02T20:03:43Z,2021-06-03T05:12:40Z,Sidebar unification,GuillaumeGomez,19579c656436d7998289399ca373889b8e6019ce,14,"Auto merge of #84834 - GuillaumeGomez:sidebar-unification r=jsha Sidebar unification This PR does a few things: * Put crates list at all levels (before it was only on the ""top"" items) * Fix bug in module sidebar: the list of items was from the parent module. The other changes (on bootstrap mostly) were to allow to generate multiple crates in a same folder so that we can ensure that clicking on the crates in the sidebar works as expected. I added a rustdoc-gui test to ensure everything is where it should be. r? `@jyn514`",EYES,2021-05-02T20:10:56Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/84852,MERGED,2021-05-03T07:23:53Z,2021-05-03T17:00:19Z,Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar,mautamu,ed1646a785f28306e01a7d505a40e5a40371e733,4,Rollup merge of #84852 - mautamu:master r=GuillaumeGomez Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar Howdy This PR does the following: 1. Updates the grammar of a comment in librustdoc. 2. Replaces a few write!(..\n) macros with writeln!(..\n) for clarity. (Please let me know if there is a reason why this might be wrong!) Best Mautamu,THUMBS_UP,2021-05-03T08:35:25Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/84863,MERGED,2021-05-03T13:09:30Z,2021-06-06T11:31:16Z,Show test type during prints,ABouttefeux,3740ba2a7dd965ca45db500ebf7ad580a7812c07,18,"Auto merge of #84863 - ABouttefeux:libtest r=m-ou-se Show test type during prints Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run. During #83857 I got the feedback that test output can be confusing. For the moment test output is ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) ... ok test $DIR/test-type.rs - f (line 21) ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` I propose to change output by indicating the test type as ``` test $DIR/test-type.rs - f (line 12) ... ignored test $DIR/test-type.rs - f (line 15) - compile ... ok test $DIR/test-type.rs - f (line 21) - compile fail ... ok test $DIR/test-type.rs - f (line 6) ... ok ``` by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the ""..."". ------------ Note: this is a proof of concept the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior maybe `TestType::DocTest` could have fields",THUMBS_UP,2021-05-24T04:02:48Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84886,MERGED,2021-05-03T21:04:10Z,2021-05-05T13:32:22Z,Update RLS and Rustfmt,Xanewok,24acc388da2cdbe1ec79b6933402941b6fffb26b,4,Auto merge of #84886 - Xanewok:update-rls-and-rustfmt r=Xanewok Update RLS and Rustfmt Closes #84537. Closes #84538. I know there's https://github.com/rust-lang/rust/pull/82208 in progress but I'm not sure which we want to land first. Also I'm getting Rustfmt test failures due to inner attributes not permitted:
``` error: an inner attribute is not permitted in this context --> tests/target/issue-3592.rs:4:13 | 4 | #![cfg(unix)] | ^^^^^^^^^^^^^ | = note: inner attributes like `#![no_std]` annotate the item enclosing them and are usually found at the beginning of source files. Outer attributes like `#[test]` annotate the item following them. error: an inner attribute is not permitted in this context --> tests/target/issue-3592.rs:8:13 | 8 | #![cfg(not(unix))] | ^^^^^^^^^^^^^^^^^^ | = note: inner attributes like `#![no_std]` annotate the item enclosing them and are usually found at the beginning of source files. Outer attributes like `#[test]` annotate the item following them. error: an inner attribute is not permitted in this context --> tests/source/match.rs:413:9 | 413 | #![allow(simple_match)] | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: inner attributes like `#![no_std]` annotate the item enclosing them and are usually found at the beginning of source files. Outer attributes like `#[test]` annotate the item following them. error: an inner attribute is not permitted in this context --> tests/target/match.rs:444:9 | 444 | #![allow(simple_match)] | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: inner attributes like `#![no_std]` annotate the item enclosing them and are usually found at the beginning of source files. Outer attributes like `#[test]` annotate the item following them. test test::system_tests ... FAILED test test::idempotence_tests ... FAILED ```
but let's see what CI says first. cc `@calebcartwright`,THUMBS_UP,2021-05-05T13:47:26Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/84888,CLOSED,2021-05-03T21:33:51Z,2021-05-04T00:53:06Z,Update `is_trivially_sized` to know enums are always `Sized`,scottmcm,NA,NA,NA,HEART,2021-05-03T21:39:50Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/84896,MERGED,2021-05-04T06:50:55Z,2021-05-07T03:57:17Z,Handle incorrect placement of parentheses in trait bounds more gracefully,estebank,b44e56f9685fe2ed5386669324cfeb3dbb512d89,3,Rollup merge of #84896 - estebank:issue-84772 r=jackh726 Handle incorrect placement of parentheses in trait bounds more gracefully Fix #84772. CC ``````@jonhoo``````,HEART,2021-05-04T16:43:01Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/84910,MERGED,2021-05-04T14:26:20Z,2021-06-22T12:11:09Z,stabilize `int_error_matching`,eopb,75ed34223adb02c7bbfa5ae5e62c48952ff29914,7,Auto merge of #84910 - eopb:stabilize_int_error_matching r=yaahc stabilize `int_error_matching` closes #22639 > It has been over half a year since https://github.com/rust-lang/rust/pull/77640#pullrequestreview-511263516 and the indexing question is rejected in https://github.com/rust-lang/rust/pull/79728#pullrequestreview-633030341 so I guess we can submit another stabilization attempt? 😉 _Originally posted by `@kennytm` in https://github.com/rust-lang/rust/issues/22639#issuecomment-831738266_,HEART,2021-05-05T10:26:48Z,kennytm,NA https://github.com/rust-lang/rust/pull/84910,MERGED,2021-05-04T14:26:20Z,2021-06-22T12:11:09Z,stabilize `int_error_matching`,eopb,75ed34223adb02c7bbfa5ae5e62c48952ff29914,7,Auto merge of #84910 - eopb:stabilize_int_error_matching r=yaahc stabilize `int_error_matching` closes #22639 > It has been over half a year since https://github.com/rust-lang/rust/pull/77640#pullrequestreview-511263516 and the indexing question is rejected in https://github.com/rust-lang/rust/pull/79728#pullrequestreview-633030341 so I guess we can submit another stabilization attempt? 😉 _Originally posted by `@kennytm` in https://github.com/rust-lang/rust/issues/22639#issuecomment-831738266_,HEART,2021-05-10T20:35:18Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84939,CLOSED,2021-05-05T02:25:06Z,2021-07-28T14:30:22Z,Add doc aliases for BinaryHeap pushpop and heapify implementations,lopopolo,NA,NA,NA,CONFUSED,2021-05-05T11:18:24Z,kennytm,NA https://github.com/rust-lang/rust/pull/84940,MERGED,2021-05-05T02:39:38Z,2021-06-07T02:30:26Z,Don't run sanity checks for `x.py setup`,jyn514,83664bd16bbe776cca3790f8c10ccc752de50e8d,1,Rollup merge of #84940 - jyn514:ninja r=Mark-Simulacrum Don't run sanity checks for `x.py setup` These requirements change as soon as the command finishes running and `setup` doesn't build anything so the check doesn't make sense. Previously `x.py setup` would give hard errors if `ninja` and `cmake` were not installed even if the new profile didn't require them. Fixes https://github.com/rust-lang/rust/issues/84938.,HEART,2021-05-05T02:47:52Z,lopopolo,NA https://github.com/rust-lang/rust/pull/84940,MERGED,2021-05-05T02:39:38Z,2021-06-07T02:30:26Z,Don't run sanity checks for `x.py setup`,jyn514,83664bd16bbe776cca3790f8c10ccc752de50e8d,1,Rollup merge of #84940 - jyn514:ninja r=Mark-Simulacrum Don't run sanity checks for `x.py setup` These requirements change as soon as the command finishes running and `setup` doesn't build anything so the check doesn't make sense. Previously `x.py setup` would give hard errors if `ninja` and `cmake` were not installed even if the new profile didn't require them. Fixes https://github.com/rust-lang/rust/issues/84938.,THUMBS_UP,2021-05-05T16:16:34Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/84959,MERGED,2021-05-05T17:32:29Z,2021-07-20T04:31:41Z,Suggest lint groups,camsteffen,c9aa2595d9ba2313bbfcc8e0244231baa9c5d9e0,4,Auto merge of #84959 - camsteffen:lint-suggest-group r=estebank Suggest lint groups Fixes rust-lang/rust-clippy#6986,THUMBS_UP,2021-06-15T21:05:00Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/84988,MERGED,2021-05-06T15:02:43Z,2021-06-03T08:02:43Z,rustc: Allow safe #[target_feature] on wasm,alexcrichton,016e9b5e33ef1407bffb575ec63d24241912556d,4,Auto merge of #84988 - alexcrichton:safe-target-feature-wasm r=joshtriplett rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly however the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in #74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.,HOORAY,2021-05-06T22:02:32Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/84988,MERGED,2021-05-06T15:02:43Z,2021-06-03T08:02:43Z,rustc: Allow safe #[target_feature] on wasm,alexcrichton,016e9b5e33ef1407bffb575ec63d24241912556d,4,Auto merge of #84988 - alexcrichton:safe-target-feature-wasm r=joshtriplett rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly however the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in #74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.,HOORAY,2021-05-20T11:20:20Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/84988,MERGED,2021-05-06T15:02:43Z,2021-06-03T08:02:43Z,rustc: Allow safe #[target_feature] on wasm,alexcrichton,016e9b5e33ef1407bffb575ec63d24241912556d,4,Auto merge of #84988 - alexcrichton:safe-target-feature-wasm r=joshtriplett rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly however the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in #74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.,HOORAY,2021-05-24T04:04:28Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/84988,MERGED,2021-05-06T15:02:43Z,2021-06-03T08:02:43Z,rustc: Allow safe #[target_feature] on wasm,alexcrichton,016e9b5e33ef1407bffb575ec63d24241912556d,4,Auto merge of #84988 - alexcrichton:safe-target-feature-wasm r=joshtriplett rustc: Allow safe #[target_feature] on wasm This commit updates the compiler's handling of the `#[target_feature]` attribute when applied to functions on WebAssembly-based targets. The compiler in general requires that any functions with `#[target_feature]` are marked as `unsafe` as well but this commit relaxes the restriction for WebAssembly targets where the attribute can be applied to safe functions as well. The reason this is done is that the motivation for this feature of the compiler is not applicable for WebAssembly targets. In general the `#[target_feature]` attribute is used to enhance target CPU features enabled beyond the basic level for the rest of the compilation. If done improperly this means that your program could execute an instruction that the CPU you happen to be running on does not understand. This is considered undefined behavior where it is unknown what will happen (e.g. it's not a deterministic `SIGILL`). For WebAssembly however the target is different. It is not possible for a running WebAssembly program to execute an instruction that the engine does not understand. If this were the case then the program would not have validated in the first place and would not run at all. Even if this were allowed in some hypothetical future where engines have some form of runtime feature detection (which they do not right now) any implementation of such a feature would generate a trap if a module attempts to execute an instruction the module does not understand. This deterministic trap behavior would still not fall into the category of undefined behavior because the trap is deterministic. For these reasons the `#[target_feature]` attribute is now allowed on safe functions but only for WebAssembly targets. This notably enables the wasm-SIMD intrinsics proposed for stabilization in #74372 to be marked as safe generally instead of today where they're all `unsafe` due to the historical implementation of `#[target_feature]` in the compiler.,HOORAY,2021-08-01T21:27:30Z,Lokathor,NA https://github.com/rust-lang/rust/pull/84991,MERGED,2021-05-06T15:52:57Z,2021-05-07T18:53:03Z,rustc: Support Rust-specific features in -Ctarget-feature,alexcrichton,a3fbde4240628b7d83989a22351e39f1242ed209,2,"Rollup merge of #84991 - alexcrichton:target-feature-remap r=nagisa rustc: Support Rust-specific features in -Ctarget-feature Since the beginning of time the `-Ctarget-feature` flag on the command line has largely been passed unmodified to LLVM. Afterwards though the `#[target_feature]` attribute was stabilized and some of the names in this attribute do not match the corresponding LLVM name. This is because Rust doesn't always want to stabilize the exact feature name in LLVM for the equivalent functionality in Rust. This creates a situation however where in Rust you'd write: #[target_feature(enable = ""pclmulqdq"")] unsafe fn foo() { // ... } but on the command line you would write: RUSTFLAGS=""-Ctarget-feature=+pclmul"" cargo build --release This difference is somewhat odd to deal with if you're a newcomer and the situation may be made worse with upcoming features like [WebAssembly SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more prevalent. This commit implements a mapping to translate requests via `-Ctarget-feature` through the same name-mapping functionality that's present for attributes in Rust going to LLVM. This means that `+pclmulqdq` will work on x86 targets where as previously it did not. I've attempted to keep this backwards-compatible where the compiler will just opportunistically attempt to remap features found in `-Ctarget-feature` but if there's something it doesn't understand it gets passed unmodified to LLVM just as it was before.",HEART,2021-05-06T15:55:12Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/84991,MERGED,2021-05-06T15:52:57Z,2021-05-07T18:53:03Z,rustc: Support Rust-specific features in -Ctarget-feature,alexcrichton,a3fbde4240628b7d83989a22351e39f1242ed209,2,"Rollup merge of #84991 - alexcrichton:target-feature-remap r=nagisa rustc: Support Rust-specific features in -Ctarget-feature Since the beginning of time the `-Ctarget-feature` flag on the command line has largely been passed unmodified to LLVM. Afterwards though the `#[target_feature]` attribute was stabilized and some of the names in this attribute do not match the corresponding LLVM name. This is because Rust doesn't always want to stabilize the exact feature name in LLVM for the equivalent functionality in Rust. This creates a situation however where in Rust you'd write: #[target_feature(enable = ""pclmulqdq"")] unsafe fn foo() { // ... } but on the command line you would write: RUSTFLAGS=""-Ctarget-feature=+pclmul"" cargo build --release This difference is somewhat odd to deal with if you're a newcomer and the situation may be made worse with upcoming features like [WebAssembly SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more prevalent. This commit implements a mapping to translate requests via `-Ctarget-feature` through the same name-mapping functionality that's present for attributes in Rust going to LLVM. This means that `+pclmulqdq` will work on x86 targets where as previously it did not. I've attempted to keep this backwards-compatible where the compiler will just opportunistically attempt to remap features found in `-Ctarget-feature` but if there's something it doesn't understand it gets passed unmodified to LLVM just as it was before.",HEART,2021-05-06T16:36:53Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84991,MERGED,2021-05-06T15:52:57Z,2021-05-07T18:53:03Z,rustc: Support Rust-specific features in -Ctarget-feature,alexcrichton,a3fbde4240628b7d83989a22351e39f1242ed209,2,"Rollup merge of #84991 - alexcrichton:target-feature-remap r=nagisa rustc: Support Rust-specific features in -Ctarget-feature Since the beginning of time the `-Ctarget-feature` flag on the command line has largely been passed unmodified to LLVM. Afterwards though the `#[target_feature]` attribute was stabilized and some of the names in this attribute do not match the corresponding LLVM name. This is because Rust doesn't always want to stabilize the exact feature name in LLVM for the equivalent functionality in Rust. This creates a situation however where in Rust you'd write: #[target_feature(enable = ""pclmulqdq"")] unsafe fn foo() { // ... } but on the command line you would write: RUSTFLAGS=""-Ctarget-feature=+pclmul"" cargo build --release This difference is somewhat odd to deal with if you're a newcomer and the situation may be made worse with upcoming features like [WebAssembly SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more prevalent. This commit implements a mapping to translate requests via `-Ctarget-feature` through the same name-mapping functionality that's present for attributes in Rust going to LLVM. This means that `+pclmulqdq` will work on x86 targets where as previously it did not. I've attempted to keep this backwards-compatible where the compiler will just opportunistically attempt to remap features found in `-Ctarget-feature` but if there's something it doesn't understand it gets passed unmodified to LLVM just as it was before.",EYES,2021-05-06T16:38:15Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/84991,MERGED,2021-05-06T15:52:57Z,2021-05-07T18:53:03Z,rustc: Support Rust-specific features in -Ctarget-feature,alexcrichton,a3fbde4240628b7d83989a22351e39f1242ed209,2,"Rollup merge of #84991 - alexcrichton:target-feature-remap r=nagisa rustc: Support Rust-specific features in -Ctarget-feature Since the beginning of time the `-Ctarget-feature` flag on the command line has largely been passed unmodified to LLVM. Afterwards though the `#[target_feature]` attribute was stabilized and some of the names in this attribute do not match the corresponding LLVM name. This is because Rust doesn't always want to stabilize the exact feature name in LLVM for the equivalent functionality in Rust. This creates a situation however where in Rust you'd write: #[target_feature(enable = ""pclmulqdq"")] unsafe fn foo() { // ... } but on the command line you would write: RUSTFLAGS=""-Ctarget-feature=+pclmul"" cargo build --release This difference is somewhat odd to deal with if you're a newcomer and the situation may be made worse with upcoming features like [WebAssembly SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more prevalent. This commit implements a mapping to translate requests via `-Ctarget-feature` through the same name-mapping functionality that's present for attributes in Rust going to LLVM. This means that `+pclmulqdq` will work on x86 targets where as previously it did not. I've attempted to keep this backwards-compatible where the compiler will just opportunistically attempt to remap features found in `-Ctarget-feature` but if there's something it doesn't understand it gets passed unmodified to LLVM just as it was before.",HEART,2021-05-06T18:07:13Z,marmeladema,NA https://github.com/rust-lang/rust/pull/84991,MERGED,2021-05-06T15:52:57Z,2021-05-07T18:53:03Z,rustc: Support Rust-specific features in -Ctarget-feature,alexcrichton,a3fbde4240628b7d83989a22351e39f1242ed209,2,"Rollup merge of #84991 - alexcrichton:target-feature-remap r=nagisa rustc: Support Rust-specific features in -Ctarget-feature Since the beginning of time the `-Ctarget-feature` flag on the command line has largely been passed unmodified to LLVM. Afterwards though the `#[target_feature]` attribute was stabilized and some of the names in this attribute do not match the corresponding LLVM name. This is because Rust doesn't always want to stabilize the exact feature name in LLVM for the equivalent functionality in Rust. This creates a situation however where in Rust you'd write: #[target_feature(enable = ""pclmulqdq"")] unsafe fn foo() { // ... } but on the command line you would write: RUSTFLAGS=""-Ctarget-feature=+pclmul"" cargo build --release This difference is somewhat odd to deal with if you're a newcomer and the situation may be made worse with upcoming features like [WebAssembly SIMD](https://github.com/rust-lang/rust/issues/74372) which may be more prevalent. This commit implements a mapping to translate requests via `-Ctarget-feature` through the same name-mapping functionality that's present for attributes in Rust going to LLVM. This means that `+pclmulqdq` will work on x86 targets where as previously it did not. I've attempted to keep this backwards-compatible where the compiler will just opportunistically attempt to remap features found in `-Ctarget-feature` but if there's something it doesn't understand it gets passed unmodified to LLVM just as it was before.",HEART,2021-05-07T20:50:30Z,bluss,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-06-14T11:26:22Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-08-03T22:23:03Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-08-17T05:43:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-09-09T15:37:53Z,hkratz,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2021-09-23T14:27:29Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-12-07T12:04:44Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2021-12-17T01:02:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2021-12-17T17:29:34Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2021-12-17T17:29:35Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2022-02-20T18:17:02Z,Paulo-21,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2022-02-21T00:55:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2022-02-21T00:55:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",THUMBS_UP,2022-02-23T18:07:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/85013,MERGED,2021-05-06T21:36:40Z,2021-12-07T11:18:34Z,Replace dominators algorithm with simple Lengauer-Tarjan,Mark-Simulacrum,c67497a5da33eb3167a33e938920ce04d2b883a5,2,"Auto merge of #85013 - Mark-Simulacrum:dominators-bitset r=pnkfelix Replace dominators algorithm with simple Lengauer-Tarjan This PR replaces our dominators implementation with that of the simple Lengauer-Tarjan algorithm which is (to my knowledge and research) the currently accepted 'best' algorithm. The more complex variant has higher constant time overheads and Semi-NCA (which is arguably a variant of Lengauer-Tarjan too) is not the preferred variant by the first paper cited in the documentation comments: simple Lengauer-Tarjan ""is less sensitive to pathological instances we think it should be preferred where performance guarantees are important"" - which they are for us. This work originally arose from noting that the keccak benchmark spent a considerable portion of its time (both instructions and cycles) in the dominator computations which sparked an interest in potentially optimizing that code. The current algorithm largely proves slow on long ""parallel"" chains where the nearest common ancestor lookup (i.e. the intersect function) does not quickly identify a root; it is also inherently a pointer-chasing algorithm so is relatively slow on modern CPUs due to needing to hit memory - though usually in cache - in a tight loop which still costs several cycles. This was replaced with a bitset-based algorithm previously studied in literature but implemented directly from dataflow equations in our case which proved to be a significant speed up on the keccak benchmark: 20% instruction count wins as can be seen in [this performance report](https://perf.rust-lang.org/compare.html?start=377d1a984cd2a53327092b90aa1d8b7e22d1e347&end=542da47ff78aa462384062229dad0675792f2638). This algorithm is also relatively simple in comparison to other algorithms and is easy to understand. However these performance results showed a regression on a number of other benchmarks and I was unable to get the bitsets to perform well enough that those regressions could be fully mitigated. The implementation ""attempt"" is seen here in the first commit and is intended to be kept primarily so that future optimizers do not repeat that path (or can easily refer to the attempt). The final version of this PR chooses the simple Lengauer-Tarjan algorithm and implements it along with a number of optimizations found in literature. The current implementation is a slight improvement for many benchmarks with keccak still being an outlier at ~20%. The implementation in this PR first implements the most basic variant of the algorithm directly from the pseudocode on page 16 physical or 28 in the PDF of the first paper (""Linear-Time Algorithms for Dominators and Related Problems""). This is then followed by a number of commits which update the implementation to apply various performance improvements as suggested by the paper. Finally the last commit annotates the implementation with a number of comments mostly drawn from the paper which intend to help readers understand what is going on - these are incomplete without the paper but writing them certainly helped my understanding. They may be helpful if future optimization attempts are attempted so I chose to add them in.",ROCKET,2022-02-23T18:07:37Z,DianaNites,NA https://github.com/rust-lang/rust/pull/85017,MERGED,2021-05-07T02:27:13Z,2021-08-31T19:33:12Z,Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers,clarfonthey,e7a247dba431d6fa505ca0393ffcab5bfc65e9cb,4,"Rollup merge of #85017 - clarfonthey:carrying_widening r=m-ou-se Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers This comes in part from my own attempts to make (crude) big integer implementations and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start I figured I might as well offer them now. I tried looking into intrinsics messed around with a few different implementations and ultimately concluded that these are ""good enough"" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these. For the `carrying_add` and `borrowing_sub` I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub` although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags and thus can only be optimised if they're done one-after-another and thus it would make the most sense to have compact intrinsics that can be merged together easily). For `widening_mul` and `carrying_mul` for now at least I simply cast to the larger type and perform arithmetic that way since we currently have no intrinsic that would work better for 128-bit integers. In the future I also think that some form of intrinsic would work best to cover that case but for now at least I think that they're ""good enough"" for now. The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus these operations alone aren't enough to create big integer implementations although they could help simplify the code required to do so and make it a bit more accessible for the average implementor. That said I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻",THUMBS_UP,2021-05-12T20:42:32Z,vandenheuvel,NA https://github.com/rust-lang/rust/pull/85017,MERGED,2021-05-07T02:27:13Z,2021-08-31T19:33:12Z,Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers,clarfonthey,e7a247dba431d6fa505ca0393ffcab5bfc65e9cb,4,"Rollup merge of #85017 - clarfonthey:carrying_widening r=m-ou-se Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers This comes in part from my own attempts to make (crude) big integer implementations and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start I figured I might as well offer them now. I tried looking into intrinsics messed around with a few different implementations and ultimately concluded that these are ""good enough"" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these. For the `carrying_add` and `borrowing_sub` I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub` although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags and thus can only be optimised if they're done one-after-another and thus it would make the most sense to have compact intrinsics that can be merged together easily). For `widening_mul` and `carrying_mul` for now at least I simply cast to the larger type and perform arithmetic that way since we currently have no intrinsic that would work better for 128-bit integers. In the future I also think that some form of intrinsic would work best to cover that case but for now at least I think that they're ""good enough"" for now. The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus these operations alone aren't enough to create big integer implementations although they could help simplify the code required to do so and make it a bit more accessible for the average implementor. That said I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻",THUMBS_UP,2021-09-01T21:33:15Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/85017,MERGED,2021-05-07T02:27:13Z,2021-08-31T19:33:12Z,Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers,clarfonthey,e7a247dba431d6fa505ca0393ffcab5bfc65e9cb,4,"Rollup merge of #85017 - clarfonthey:carrying_widening r=m-ou-se Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers This comes in part from my own attempts to make (crude) big integer implementations and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start I figured I might as well offer them now. I tried looking into intrinsics messed around with a few different implementations and ultimately concluded that these are ""good enough"" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these. For the `carrying_add` and `borrowing_sub` I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub` although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags and thus can only be optimised if they're done one-after-another and thus it would make the most sense to have compact intrinsics that can be merged together easily). For `widening_mul` and `carrying_mul` for now at least I simply cast to the larger type and perform arithmetic that way since we currently have no intrinsic that would work better for 128-bit integers. In the future I also think that some form of intrinsic would work best to cover that case but for now at least I think that they're ""good enough"" for now. The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus these operations alone aren't enough to create big integer implementations although they could help simplify the code required to do so and make it a bit more accessible for the average implementor. That said I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻",THUMBS_UP,2021-09-09T10:36:54Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85017,MERGED,2021-05-07T02:27:13Z,2021-08-31T19:33:12Z,Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers,clarfonthey,e7a247dba431d6fa505ca0393ffcab5bfc65e9cb,4,"Rollup merge of #85017 - clarfonthey:carrying_widening r=m-ou-se Add carrying_add borrowing_sub widening_mul carrying_mul methods to integers This comes in part from my own attempts to make (crude) big integer implementations and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start I figured I might as well offer them now. I tried looking into intrinsics messed around with a few different implementations and ultimately concluded that these are ""good enough"" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these. For the `carrying_add` and `borrowing_sub` I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub` although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags and thus can only be optimised if they're done one-after-another and thus it would make the most sense to have compact intrinsics that can be merged together easily). For `widening_mul` and `carrying_mul` for now at least I simply cast to the larger type and perform arithmetic that way since we currently have no intrinsic that would work better for 128-bit integers. In the future I also think that some form of intrinsic would work best to cover that case but for now at least I think that they're ""good enough"" for now. The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus these operations alone aren't enough to create big integer implementations although they could help simplify the code required to do so and make it a bit more accessible for the average implementor. That said I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻",THUMBS_UP,2021-09-11T14:16:21Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/85050,MERGED,2021-05-07T19:04:32Z,2021-05-10T17:49:22Z,Fix suggestions for missing return type lifetime specifiers,FabianWolff,0740015d59c8c35c803f5f4a0b2aab112e0531aa,8,Rollup merge of #85050 - FabianWolff:issue-84592 r=jackh726 Fix suggestions for missing return type lifetime specifiers This pull request aims to fix #84592. The issue is that the current code seems to assume that there is only a single relevant span pointing to the missing lifetime and only looks at the first one: https://github.com/rust-lang/rust/blob/e5f83d24aee866a14753a7cedbb4e301dfe5bef5/compiler/rustc_resolve/src/late/lifetimes.rs#L2959 This is incorrect though and leads to incorrect error messages and invalid suggestions. For instance the example from #84592: ```rust struct TwoLifetimes<'x 'y> { x: &'x () y: &'y () } fn two_lifetimes_needed(a: &() b: &()) -> TwoLifetimes<'_ '_> { TwoLifetimes { x: &() y: &() } } ``` currently leads to: ``` error[E0106]: missing lifetime specifiers --> src/main.rs:6:57 | 6 | fn two_lifetimes_needed(a: &() b: &()) -> TwoLifetimes<'_ '_> { | --- --- ^^ expected 2 lifetime parameters | = help: this function's return type contains a borrowed value but the signature does not say whether it is borrowed from `a` or `b` help: consider introducing a named lifetime parameter | 6 | fn two_lifetimes_needed<'a>(a: &'a () b: &'a ()) -> TwoLifetimes<'_<'a 'a> '_> { | ^^^^ ^^^^^^ ^^^^^^ ^^^^^^^^^^ ``` There are two problems: - The error message is wrong. There is only _one_ lifetime parameter expected at the location pointed to by the error message (and another one at a separate location). - The suggestion is incorrect and will not lead to correct code. With the changes in this PR I get the following output: ``` error[E0106]: missing lifetime specifiers --> p.rs:6:57 | 6 | fn two_lifetimes_needed(a: &() b: &()) -> TwoLifetimes<'_ '_> { | --- --- ^^ ^^ expected named lifetime parameter | | | expected named lifetime parameter | = help: this function's return type contains a borrowed value but the signature does not say whether it is borrowed from `a` or `b` help: consider introducing a named lifetime parameter | 6 | fn two_lifetimes_needed<'a>(a: &'a () b: &'a ()) -> TwoLifetimes<'a 'a> { | ^^^^ ^^^^^^ ^^^^^^ ^^ ^^ error: aborting due to previous error For more information about this error try `rustc --explain E0106`. ``` Mainly I changed `add_missing_lifetime_specifiers_label()` to receive a _vector_ of spans (and counts) instead of just one and adjusted its body accordingly.,ROCKET,2021-05-28T20:44:25Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/85051,MERGED,2021-05-07T20:07:34Z,2021-05-11T05:03:18Z,Allow checking miri and RLS with `x.py check src/tools/{miri rls}`,jyn514,d501042cc3cdbbf90c779c4478299a1697089684,2,Rollup merge of #85051 - jyn514:check-miri r=Mark-Simulacrum Allow checking miri and RLS with `x.py check src/tools/{miri rls}` Helps with https://github.com/rust-lang/rust/issues/80639. `@Xanewok` would you find this useful for RLS too?,HEART,2021-05-08T10:16:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/85051,MERGED,2021-05-07T20:07:34Z,2021-05-11T05:03:18Z,Allow checking miri and RLS with `x.py check src/tools/{miri rls}`,jyn514,d501042cc3cdbbf90c779c4478299a1697089684,2,Rollup merge of #85051 - jyn514:check-miri r=Mark-Simulacrum Allow checking miri and RLS with `x.py check src/tools/{miri rls}` Helps with https://github.com/rust-lang/rust/issues/80639. `@Xanewok` would you find this useful for RLS too?,HEART,2021-05-08T14:46:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85053,MERGED,2021-05-07T20:50:04Z,2021-05-10T12:26:47Z,Fix duplicate unknown lint errors,camsteffen,1b30245ea1286df96d673015c4519c861e06977a,5,Auto merge of #85053 - camsteffen:duplicate-lint r=davidtwco Fix duplicate unknown lint errors Fixes rust-lang/rust-clippy#6602,HEART,2021-05-08T11:54:55Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/85058,MERGED,2021-05-07T23:14:35Z,2021-05-08T05:38:47Z,Update RLS,Xanewok,e002ac7e8a1eb04961a722c44b3ffbad575a6caa,1,Auto merge of #85058 - Xanewok:update-rls r=Xanewok Update RLS This mostly just includes https://github.com/rust-lang/rls/commit/e33f4e68496b296dedb100e297dc4451f169b2b3 so that this fixes #85055 (clippy-related breakage).,HEART,2021-05-08T02:37:12Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/85068,MERGED,2021-05-08T08:25:48Z,2021-05-13T18:47:14Z,Fix diagnostic for cross crate private tuple struct constructors,luqmana,3db335b934d31cf3bdaaa248ca34aa25ef67f366,7,Rollup merge of #85068 - luqmana:78708-xcrate-diag r=estebank Fix diagnostic for cross crate private tuple struct constructors Fixes #78708. There was already some limited support for certain cross-crate scenarios but that didn't handle a tuple struct rexported from an inner module for example (e.g. the NonZero* types as seen in #85049). ```Rust ➜ cat bug.rs fn main() { let _x = std::num::NonZeroU32(12); let n = std::num::NonZeroU32::new(1).unwrap(); match n { std::num::NonZeroU32(i) => {} } } ``` **Before:**
```Rust ➜ rustc +nightly bug.rs error[E0423]: expected function tuple struct or tuple variant found struct `std::num::NonZeroU32` --> bug.rs:2:14 | 2 | let _x = std::num::NonZeroU32(12); | ^^^^^^^^^^^^^^^^^^^^^^^^ help: use struct literal syntax instead: `std::num::NonZeroU32 { 0: val }` | ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1 [snip] error[E0532]: expected tuple struct or tuple variant found struct `std::num::NonZeroU32` --> bug.rs:5:9 | 5 | std::num::NonZeroU32(i) => {} | ^^^^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `std::num::NonZeroU32 { 0 }` | ::: /home/luqman/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/nonzero.rs:148:1 [snip] error: aborting due to 2 previous errors Some errors have detailed explanations: E0423 E0532. For more information about an error try `rustc --explain E0423`. ```
**After:**
```Rust ➜ /rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc bug.rs error[E0423]: cannot initialize a tuple struct which contains private fields --> bug.rs:2:14 | 2 | let _x = std::num::NonZeroU32(12); | ^^^^^^^^^^^^^^^^^^^^ | note: constructor is not visible here due to private fields --> /rust/library/core/src/num/nonzero.rs:148:1 [snip] error[E0532]: cannot match against a tuple struct which contains private fields --> bug.rs:5:9 | 5 | std::num::NonZeroU32(i) => {} | ^^^^^^^^^^^^^^^^^^^^ | note: constructor is not visible here due to private fields --> bug.rs:5:30 | 5 | std::num::NonZeroU32(i) => {} | ^ private field error: aborting due to 2 previous errors Some errors have detailed explanations: E0423 E0532. For more information about an error try `rustc --explain E0423`. ```
One question is if we should only collect the needed info for the cross-crate case after encountering an error instead of always doing it. Perf run perhaps to gauge the impact.,THUMBS_UP,2021-05-11T21:47:53Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/85074,MERGED,2021-05-08T12:22:57Z,2021-05-10T06:30:09Z,Migrate top doc and non-exhaustive toggles to details tag,GuillaumeGomez,00f2bf40d6374ec3541a72edb5b481fb1370dbca,5,Auto merge of #85074 - GuillaumeGomez:end-toggle-migration r=jsha Migrate top doc and non-exhaustive toggles to details tag Fixes #83332. r? `@jsha`,HOORAY,2021-05-08T12:41:08Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/85074,MERGED,2021-05-08T12:22:57Z,2021-05-10T06:30:09Z,Migrate top doc and non-exhaustive toggles to details tag,GuillaumeGomez,00f2bf40d6374ec3541a72edb5b481fb1370dbca,5,Auto merge of #85074 - GuillaumeGomez:end-toggle-migration r=jsha Migrate top doc and non-exhaustive toggles to details tag Fixes #83332. r? `@jsha`,HOORAY,2021-05-09T00:29:38Z,camelid,NA https://github.com/rust-lang/rust/pull/85074,MERGED,2021-05-08T12:22:57Z,2021-05-10T06:30:09Z,Migrate top doc and non-exhaustive toggles to details tag,GuillaumeGomez,00f2bf40d6374ec3541a72edb5b481fb1370dbca,5,Auto merge of #85074 - GuillaumeGomez:end-toggle-migration r=jsha Migrate top doc and non-exhaustive toggles to details tag Fixes #83332. r? `@jsha`,HOORAY,2021-05-09T14:23:10Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/85078,MERGED,2021-05-08T14:37:42Z,2021-05-22T20:04:51Z,stabilize const_fn_unsize,RalfJung,f98bd7eeca7f01be426b8ffe73ae6717a9659a82,14,Auto merge of #85078 - RalfJung:const_fn_unsize r=oli-obk stabilize const_fn_unsize I will post a stabilization report and ask for FCP in https://github.com/rust-lang/rust/issues/64992. This PR is for the implementation side of stabilization. r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/64992,HOORAY,2021-07-06T08:10:48Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85078,MERGED,2021-05-08T14:37:42Z,2021-05-22T20:04:51Z,stabilize const_fn_unsize,RalfJung,f98bd7eeca7f01be426b8ffe73ae6717a9659a82,14,Auto merge of #85078 - RalfJung:const_fn_unsize r=oli-obk stabilize const_fn_unsize I will post a stabilization report and ask for FCP in https://github.com/rust-lang/rust/issues/64992. This PR is for the implementation side of stabilization. r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/64992,HOORAY,2021-07-27T07:55:10Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/85086,MERGED,2021-05-08T19:05:30Z,2021-06-06T19:12:08Z,linker: Reorder linker arguments,petrochenkov,5b638c1d3751b7ab31cac9739add516bdf39e10a,2,Auto merge of #85086 - petrochenkov:linkord2 r=nagisa linker: Reorder linker arguments - Split arguments into order-independent and order-dependent to define more precisely what (pre- post- late- )link-args mean. - Add some comments.,HEART,2021-05-10T21:15:11Z,mati865,NA https://github.com/rust-lang/rust/pull/85110,MERGED,2021-05-09T12:25:19Z,2021-05-13T16:06:12Z,Remove rustc_args_required_const attribute,RalfJung,d2df620789cd82a6751320223cd3de87256bf15e,33,Auto merge of #85110 - RalfJung:no-rustc_args_required_const r=oli-obk Remove rustc_args_required_const attribute Now that stdarch no longer needs it (thanks `@Amanieu!) ` we can kill the `rustc_args_required_const` attribute. This means that lifetime extension of references to temporaries is the only remaining job that promotion is performing. :-) r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/69493,HOORAY,2021-05-09T22:24:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85110,MERGED,2021-05-09T12:25:19Z,2021-05-13T16:06:12Z,Remove rustc_args_required_const attribute,RalfJung,d2df620789cd82a6751320223cd3de87256bf15e,33,Auto merge of #85110 - RalfJung:no-rustc_args_required_const r=oli-obk Remove rustc_args_required_const attribute Now that stdarch no longer needs it (thanks `@Amanieu!) ` we can kill the `rustc_args_required_const` attribute. This means that lifetime extension of references to temporaries is the only remaining job that promotion is performing. :-) r? `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/69493,HOORAY,2021-05-11T09:07:55Z,bjorn3,NA https://github.com/rust-lang/rust/pull/85124,MERGED,2021-05-09T20:52:37Z,2021-05-12T01:09:36Z,rustdoc: remove explicit boolean comparisons.,jsha,4ab305031caed3d825616f4d7f131b5700b35810,4,Rollup merge of #85124 - jsha:trust-the-bool r=GuillaumeGomez rustdoc: remove explicit boolean comparisons. For boolean variables it's shorter and more readable to check the value directly or negate it with `!`. In a couple of cases I reordered an if/else pair because it made the initial `if` statement simpler. An example of a style guide recommending this: https://airbnb.io/javascript/#comparison--shortcuts r? `@GuillaumeGomez`,THUMBS_UP,2021-05-10T09:42:22Z,r00ster91,NA https://github.com/rust-lang/rust/pull/85124,MERGED,2021-05-09T20:52:37Z,2021-05-12T01:09:36Z,rustdoc: remove explicit boolean comparisons.,jsha,4ab305031caed3d825616f4d7f131b5700b35810,4,Rollup merge of #85124 - jsha:trust-the-bool r=GuillaumeGomez rustdoc: remove explicit boolean comparisons. For boolean variables it's shorter and more readable to check the value directly or negate it with `!`. In a couple of cases I reordered an if/else pair because it made the initial `if` statement simpler. An example of a style guide recommending this: https://airbnb.io/javascript/#comparison--shortcuts r? `@GuillaumeGomez`,THUMBS_UP,2021-05-23T11:44:47Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/85144,CLOSED,2021-05-10T11:14:40Z,2021-08-28T19:28:35Z,linker: Never use whole-archive linking unless explicitly requested,petrochenkov,NA,NA,NA,THUMBS_UP,2021-05-10T20:17:51Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/85144,CLOSED,2021-05-10T11:14:40Z,2021-08-28T19:28:35Z,linker: Never use whole-archive linking unless explicitly requested,petrochenkov,NA,NA,NA,ROCKET,2021-05-10T21:19:09Z,mati865,NA https://github.com/rust-lang/rust/pull/85152,MERGED,2021-05-10T16:20:35Z,2021-05-10T21:09:32Z,Adjust target search algorithm for rustlib path,nagisa,6ec1de7d4f950c7c0b33bae9858157282416591d,5,Rollup merge of #85152 - nagisa:target-search-rustlib r=Mark-Simulacrum Adjust target search algorithm for rustlib path With this the concerns expressed in #83800 should be addressed. r? `@Mark-Simulacrum`,HEART,2021-05-10T16:42:54Z,Mark-Simulacrum,mark.simulacrum@gmail.com https://github.com/rust-lang/rust/pull/85157,MERGED,2021-05-10T20:02:05Z,2021-12-09T17:51:09Z,replace vec::Drain drop loops with drop_in_place,the8472,0b42deaccc2cbe17a68067aa5fdb76104369e1fd,1,Auto merge of #85157 - the8472:drain-drop-in-place r=Mark-Simulacrum replace vec::Drain drop loops with drop_in_place The `Drain::drop` implementation came up in https://github.com/rust-lang/rust/pull/82185#issuecomment-789584796 as potentially interfering with other optimization work due its widespread use somewhere in `println!` `@rustbot` label T-libs-impl,THUMBS_UP,2021-07-30T18:39:13Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85158,OPEN,2021-05-10T20:40:26Z,NA,Mir-Opt for copying enums with large discrepancies,JulianKnodt,NA,NA,NA,HEART,2021-11-18T23:24:48Z,petrosagg,petrosagg@gmail.com https://github.com/rust-lang/rust/pull/85176,MERGED,2021-05-11T11:05:06Z,2021-05-19T04:44:14Z,Override `clone_from` for some types,a1phyr,3d31363338bc3a4db66237f5be10389cfd01201b,4,Auto merge of #85176 - a1phyr:impl_clone_from r=yaahc Override `clone_from` for some types Override `clone_from` method of the `Clone` trait for: - `cell::RefCell` - `cmp::Reverse` - `io::Cursor` - `mem::ManuallyDrop` This can bring performance improvements.,THUMBS_UP,2021-05-27T16:44:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/85178,MERGED,2021-05-11T13:01:11Z,2021-05-17T04:23:00Z,Remove CrateNum parameter for queries that only work on local crate,cjgillot,3396a383bb1d1fdad8ceeb74f16cf08e0bd62a1b,70,Auto merge of #85178 - cjgillot:local-crate r=oli-obk Remove CrateNum parameter for queries that only work on local crate The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea. Using `()` as query key in those cases avoids having to worry about the validity of the query key.,HEART,2021-05-11T18:00:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85187,MERGED,2021-05-11T16:28:25Z,2021-05-12T01:09:36Z,Use .name_str() to format primitive types in error messages,FabianWolff,c4c654f422e34530f2728c0aa4d89bd837dbfd8b,3,Rollup merge of #85187 - FabianWolff:issue-84976 r=jackh726 Use .name_str() to format primitive types in error messages This pull request fixes #84976. The problem described there is caused by this code https://github.com/rust-lang/rust/blob/506e75cbf8cb5305e49a41326307004ca3976029/compiler/rustc_middle/src/ty/error.rs#L161-L166 using `Debug` formatting (`{:?}`) while the proper solution is to call `name_str()` of `ty::IntTy` `ty::UintTy` and `ty::FloatTy` respectively.,HOORAY,2021-05-12T07:13:42Z,ohadravid,NA https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-05-26T15:04:05Z,jplatte,NA https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-06-12T21:29:59Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-07-12T15:17:04Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-09-13T17:38:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-09-15T15:29:39Z,est31,NA https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",HEART,2021-09-16T23:47:52Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-09-18T11:34:22Z,Skgland,NA https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2021-10-02T09:14:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85200,MERGED,2021-05-11T22:28:55Z,2021-09-11T06:30:47Z,Ignore derived Clone and Debug implementations during dead code analysis,FabianWolff,acfe7c41412808094fd85ba3b9f5ceeabfeea932,54,"Rollup merge of #85200 - FabianWolff:issue-84647 r=nikomatsakis Ignore derived Clone and Debug implementations during dead code analysis This pull request fixes #84647. Derived implementations of `Clone` and `Debug` always trivially read all fields so ""field is never read"" dead code warnings are never triggered. Arguably though a user most likely will only be interested in whether _their_ code ever reads those fields which is the behavior I have implemented here. Note that implementations of `Clone` and `Debug` are only ignored if they are `#[derive(...)]`d; a custom `impl Clone/Debug for ...` will still be analyzed normally (i.e. if a custom `Clone` implementation uses all fields of the struct this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the `&& [impl_]item.span.in_derive_expansion()` in the if conditions). The only thing that I am slightly unsure about is that in #84647 `@matklad` said > Doesn't seem easy to fix though :( However it _was_ pretty straightforward to fix so did I perhaps overlook something obvious? `@matklad ` could you weigh in on this?",THUMBS_UP,2022-02-17T10:46:37Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/85211,MERGED,2021-05-12T04:42:20Z,2021-05-14T19:39:21Z,Preserve `SyntaxContext` for invalid/dummy spans in crate metadata,Aaron1011,1025db84a68b948139b5adcd55da31bce32da8f3,7,Auto merge of #85211 - Aaron1011:metadata-invalid-span r=michaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache we will decode it with a 'dummy' location but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`) the metadata encoder would treat it as a normal span encoding the `SyntaxContext`. As a result the final span encoded to the metadata would change across sessions even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate we execute a foreign query decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location we preserve its `SyntaxContext`. 4. We recompile the second crate again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext` and encode location information for spans with a non-dummy location.,THUMBS_UP,2021-05-12T15:25:05Z,estebank,NA https://github.com/rust-lang/rust/pull/85211,MERGED,2021-05-12T04:42:20Z,2021-05-14T19:39:21Z,Preserve `SyntaxContext` for invalid/dummy spans in crate metadata,Aaron1011,1025db84a68b948139b5adcd55da31bce32da8f3,7,Auto merge of #85211 - Aaron1011:metadata-invalid-span r=michaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache we will decode it with a 'dummy' location but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`) the metadata encoder would treat it as a normal span encoding the `SyntaxContext`. As a result the final span encoded to the metadata would change across sessions even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate we execute a foreign query decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location we preserve its `SyntaxContext`. 4. We recompile the second crate again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext` and encode location information for spans with a non-dummy location.,HEART,2021-05-13T14:26:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85211,MERGED,2021-05-12T04:42:20Z,2021-05-14T19:39:21Z,Preserve `SyntaxContext` for invalid/dummy spans in crate metadata,Aaron1011,1025db84a68b948139b5adcd55da31bce32da8f3,7,Auto merge of #85211 - Aaron1011:metadata-invalid-span r=michaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache we will decode it with a 'dummy' location but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`) the metadata encoder would treat it as a normal span encoding the `SyntaxContext`. As a result the final span encoded to the metadata would change across sessions even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate we execute a foreign query decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location we preserve its `SyntaxContext`. 4. We recompile the second crate again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext` and encode location information for spans with a non-dummy location.,THUMBS_UP,2021-05-13T17:22:02Z,lqd,NA https://github.com/rust-lang/rust/pull/85211,MERGED,2021-05-12T04:42:20Z,2021-05-14T19:39:21Z,Preserve `SyntaxContext` for invalid/dummy spans in crate metadata,Aaron1011,1025db84a68b948139b5adcd55da31bce32da8f3,7,Auto merge of #85211 - Aaron1011:metadata-invalid-span r=michaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache we will decode it with a 'dummy' location but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`) the metadata encoder would treat it as a normal span encoding the `SyntaxContext`. As a result the final span encoded to the metadata would change across sessions even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate we execute a foreign query decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location we preserve its `SyntaxContext`. 4. We recompile the second crate again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext` and encode location information for spans with a non-dummy location.,HEART,2021-05-14T19:48:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85211,MERGED,2021-05-12T04:42:20Z,2021-05-14T19:39:21Z,Preserve `SyntaxContext` for invalid/dummy spans in crate metadata,Aaron1011,1025db84a68b948139b5adcd55da31bce32da8f3,7,Auto merge of #85211 - Aaron1011:metadata-invalid-span r=michaelwoerister Preserve `SyntaxContext` for invalid/dummy spans in crate metadata Fixes #85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache we will decode it with a 'dummy' location but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`) the metadata encoder would treat it as a normal span encoding the `SyntaxContext`. As a result the final span encoded to the metadata would change across sessions even if the crate itself was unchanged. This could lead to an 'unstable fingerprint' ICE under the following conditions: 1. We compile a crate with an invalid span using incremental compilation. The metadata encoder discards the `SyntaxContext` since the span is invalid while the incremental cache encoder preserves the `SyntaxContext` 2. From another crate we execute a foreign query decoding the invalid span from the metadata as `DUMMY_SP` (e.g. with `SyntaxContext::root()`). This span gets hashed into the query fingerprint. So far this has always happened through the `optimized_mir` query. 3. We recompile the first crate using our populated incremental cache without changing anything. We load the (previously) invalid span from our incremental cache - it gets converted to a span with a dummy (but valid) location along with the original `SyntaxContext`. This span gets written out to the crate metadata - since it now has a valid location we preserve its `SyntaxContext`. 4. We recompile the second crate again using a populated incremental cache. We now re-run the foreign query `optimized_mir` - the foreign crate hash is unchanged but we end up decoding a different span (it now ha a non-root `SyntaxContext`). This results in the fingerprint changing resulting in an ICE. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext` and encode location information for spans with a non-dummy location.,THUMBS_UP,2021-05-14T19:48:32Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85212,CLOSED,2021-05-12T05:22:39Z,2021-05-20T16:52:27Z,[WIP] Optimize Token Cursor,JulianKnodt,NA,NA,NA,HOORAY,2021-05-12T05:35:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85236,MERGED,2021-05-12T19:18:16Z,2021-05-14T12:59:00Z,Update LLVM submodule,nikic,36a4d14c7edba21bba14df00b9e6e4a111dfc6f2,1,Auto merge of #85236 - nikic:update-llvm-submodule r=cuviper Update LLVM submodule This merges recent changes from the upstream LLVM 12 branch. One of them is intended to address #84958.,HOORAY,2021-05-12T20:23:03Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85236,MERGED,2021-05-12T19:18:16Z,2021-05-14T12:59:00Z,Update LLVM submodule,nikic,36a4d14c7edba21bba14df00b9e6e4a111dfc6f2,1,Auto merge of #85236 - nikic:update-llvm-submodule r=cuviper Update LLVM submodule This merges recent changes from the upstream LLVM 12 branch. One of them is intended to address #84958.,HOORAY,2021-05-15T21:03:11Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85236,MERGED,2021-05-12T19:18:16Z,2021-05-14T12:59:00Z,Update LLVM submodule,nikic,36a4d14c7edba21bba14df00b9e6e4a111dfc6f2,1,Auto merge of #85236 - nikic:update-llvm-submodule r=cuviper Update LLVM submodule This merges recent changes from the upstream LLVM 12 branch. One of them is intended to address #84958.,HOORAY,2021-05-22T22:55:20Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,THUMBS_UP,2021-05-13T09:09:04Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,THUMBS_UP,2021-05-13T13:39:51Z,bluss,NA https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,HEART,2021-05-14T00:10:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,THUMBS_UP,2021-05-21T18:03:03Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,THUMBS_UP,2021-05-23T06:32:58Z,Esaxiya,NA https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,HEART,2021-05-23T06:37:51Z,Esaxiya,NA https://github.com/rust-lang/rust/pull/85240,MERGED,2021-05-13T01:43:52Z,2021-05-13T18:47:14Z,Don't suggest adding `'static` lifetime to arguments,Aaron1011,3761ada94ebb9693190bc7924951b6035fd9c419,11,Rollup merge of #85240 - Aaron1011:no-suggest-static r=davidtwco Don't suggest adding `'static` lifetime to arguments Fixes #69350 This is almost always the wrong this to do,EYES,2021-05-23T06:37:55Z,Esaxiya,NA https://github.com/rust-lang/rust/pull/85269,MERGED,2021-05-13T19:42:18Z,2021-07-02T20:01:06Z,Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger,dpaoliello,2545459bff0aae43288e2e17bff0d332c49a6353,30,"Auto merge of #85269 - dpaoliello:dpaoliello/DebugSymbols r=michaelwoerister Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger There are several cases where names of types and functions in the debug info are either ambiguous or not helpful such as including ambiguous placeholders (e.g. `{{impl}}` `{{closure}}` or `dyn _'`) or dropping qualifications (e.g. for dynamic types). Instead each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators) and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally when targeting MSVC its debugger treats many command arguments as C++ expressions even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#` `[` `""` `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g. leading return type). * Emit arrays as a synthetic `array$` type. * Include a `$` in all synthetic types as this is a legal character for C++ but not Rust (thus we avoid collisions with user types).",HEART,2021-05-14T11:30:54Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/85269,MERGED,2021-05-13T19:42:18Z,2021-07-02T20:01:06Z,Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger,dpaoliello,2545459bff0aae43288e2e17bff0d332c49a6353,30,"Auto merge of #85269 - dpaoliello:dpaoliello/DebugSymbols r=michaelwoerister Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger There are several cases where names of types and functions in the debug info are either ambiguous or not helpful such as including ambiguous placeholders (e.g. `{{impl}}` `{{closure}}` or `dyn _'`) or dropping qualifications (e.g. for dynamic types). Instead each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators) and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally when targeting MSVC its debugger treats many command arguments as C++ expressions even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#` `[` `""` `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g. leading return type). * Emit arrays as a synthetic `array$` type. * Include a `$` in all synthetic types as this is a legal character for C++ but not Rust (thus we avoid collisions with user types).",HEART,2021-05-14T13:37:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85269,MERGED,2021-05-13T19:42:18Z,2021-07-02T20:01:06Z,Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger,dpaoliello,2545459bff0aae43288e2e17bff0d332c49a6353,30,"Auto merge of #85269 - dpaoliello:dpaoliello/DebugSymbols r=michaelwoerister Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger There are several cases where names of types and functions in the debug info are either ambiguous or not helpful such as including ambiguous placeholders (e.g. `{{impl}}` `{{closure}}` or `dyn _'`) or dropping qualifications (e.g. for dynamic types). Instead each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators) and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally when targeting MSVC its debugger treats many command arguments as C++ expressions even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#` `[` `""` `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g. leading return type). * Emit arrays as a synthetic `array$` type. * Include a `$` in all synthetic types as this is a legal character for C++ but not Rust (thus we avoid collisions with user types).",HEART,2021-07-07T02:30:09Z,Folyd,NA https://github.com/rust-lang/rust/pull/85272,MERGED,2021-05-13T21:49:05Z,2021-08-02T02:33:18Z,Allow leading pipe in `matches!()` patterns.,ChayimFriedman2,24bbf7ac2fd6f5e71f5a4873baa4456e45bd648d,2,Auto merge of #85272 - ChayimFriedman2:matches-leading-pipe r=m-ou-se Allow leading pipe in `matches!()` patterns. This is allowed in `match` statement and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.,CONFUSED,2021-07-15T01:26:03Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/85276,MERGED,2021-05-14T02:38:07Z,2021-05-19T10:11:32Z,Set dso_local for more items,Bobo1239,be8450eec8fa635a9132f799012fed83ba59121e,4,"Auto merge of #85276 - Bobo1239:more_dso_local r=nagisa Set dso_local for more items Related to https://github.com/rust-lang/rust/pull/83592. (cc `@nagisa)` Noticed that on x86_64 with `relocation-model: static` `R_X86_64_GOTPCREL` relocations were still generated in some cases. (related: https://github.com/Rust-for-Linux/linux/issues/135; Rust-for-Linux needs these fixes to successfully build) First time doing anything with LLVM so not sure whether this is correct but the following are some of the things I've tried to convince myself. ## C equivalent Example from clang which also sets `dso_local` in these cases: `clang-12 -fno-PIC -S -emit-llvm test.c` ```C extern int A; int* a() { return &A; } int B; int* b() { return &B; } ``` ``` ; ModuleID = 'test.c' source_filename = ""test.c"" target datalayout = ""e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"" target triple = ""x86_64-unknown-linux-gnu"" `@A` = external dso_local global i32 align 4 `@B` = dso_local global i32 0 align 4 ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32* `@a()` #0 { ret i32* `@A` } ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32* `@b()` #0 { ret i32* `@B` } attributes #0 = { noinline nounwind optnone uwtable ""disable-tail-calls""=""false"" ""frame-pointer""=""all"" ""less-precise-fpmad""=""false"" ""min-legal-vector-width""=""0"" ""no-infs-fp-math""=""false"" ""no-jump-tables""=""false"" ""no-nans-fp-math""=""false"" ""no-signed-zeros-fp-math""=""false"" ""no-trapping-math""=""true"" ""stack-protector-buffer-size""=""8"" ""target-cpu""=""x86-64"" ""target-features""=""+cx8 +fxsr +mmx +sse +sse2 +x87"" ""tune-cpu""=""generic"" ""unsafe-fp-math""=""false"" ""use-soft-float""=""false"" } !llvm.module.flags = !{!0} !llvm.ident = !{!1} !0 = !{i32 1 !""wchar_size"" i32 4} !1 = !{!""clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1)""} ``` `clang-12 -fno-PIC -c test.c` `objdump test.o -r`: ``` test.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000006 R_X86_64_64 A 0000000000000016 R_X86_64_64 B RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text 0000000000000040 R_X86_64_PC32 .text+0x0000000000000010 ``` ## Comparison to pre-LLVM 12 output `rustc --emit=obj llvm-ir --target=x86_64-unknown-none-linuxkernel --crate-type rlib test.rs` ```Rust #![feature(no_core lang_items)] #![no_core] #[lang=""sized""] trait Sized {} #[lang=""sync""] trait Sync {} #[lang = ""drop_in_place""] pub unsafe fn drop_in_place(_: *mut T) {} impl Sync for i32 {} pub static STATIC: i32 = 32; extern { pub static EXT_STATIC: i32; } pub fn a() -> &'static i32 { &STATIC } pub fn b() -> &'static i32 { unsafe {&EXT_STATIC} } ``` `objdump test.o -r` nightly-2021-02-20 (rustc target is `x86_64-linux-kernel`): ``` RELOCATION RECORDS FOR [.text._ZN4test1a17h1024ba65f3424175E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h3adc41a83746c9ffE RELOCATION RECORDS FOR [.text._ZN4test1b17h86a6a80c1190ac8dE]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC ``` nightly-2021-05-10: ``` RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL _ZN4test6STATIC17h5a059515bf3d4968E-0x0000000000000004 RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_GOTPCREL EXT_STATIC-0x0000000000000004 ``` This PR: ``` RELOCATION RECORDS FOR [.text._ZN4test1a17he846f03bf37b2d20E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S _ZN4test6STATIC17h5a059515bf3d4968E RELOCATION RECORDS FOR [.text._ZN4test1b17h7e0f7f80fbd91125E]: OFFSET TYPE VALUE 0000000000000007 R_X86_64_32S EXT_STATIC ```",HEART,2021-05-22T15:47:00Z,ojeda,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-14T14:58:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-14T15:10:11Z,darksv,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-14T16:11:47Z,mibac138,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-15T09:25:31Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-17T07:52:25Z,rylev,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-17T21:57:41Z,dpaoliello,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-25T09:10:44Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-05-28T12:04:05Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-03T18:45:21Z,diondokter,diondokter@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-03T20:02:49Z,djkoloski,djkoloski@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-03T20:42:10Z,bgianfo,b.gianfo@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-03T20:58:15Z,lzybkr,jasonsh@microsoft.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-04T05:17:11Z,wongsyrone,wong.syrone@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-04T07:17:27Z,yerke,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-11T06:02:23Z,Boddlnagg,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-11T11:38:46Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-11T12:27:10Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-17T06:29:58Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-20T23:50:58Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-06-21T00:05:12Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-07-03T12:41:21Z,3131CuNb,NA https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-07-27T11:53:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85292,MERGED,2021-05-14T14:50:51Z,2021-06-03T18:13:38Z,Improve debugging experience for enums on windows-msvc,wesleywiser,257782579915963c9dbe7433102275743837b9a8,9,"Auto merge of #85292 - wesleywiser:enum_debuginfo r=michaelwoerister Improve debugging experience for enums on windows-msvc This PR makes significant improvements over the status quo of debugging enums on the windows-msvc platform with either WinDbg or Visual Studio in three ways: 1. Improves the debugger experience for directly tagged enums. 2. Fixes a bug which caused the debugger to sometimes show the wrong debug info for niche layout enums. For example `Option<&u32>` could sometimes use the debug info for `Option<&f64>` instead leading to nonsensical variable values in the debugger. 3. Significantly improves the debugger experience for niche-layout enums. Let's look at a few examples: ```rust pub enum CStyleEnum { Base = 2 Exponent = 16 } pub enum NicheLayoutEnum { Tag1 Data { my_data: CStyleEnum } Tag2 Tag3 Tag4 } pub enum OtherEnum { Case1(T) Case2(T) } fn main() { let a = Some(CStyleEnum::Base); let b = Option::::None; let c = NicheLayoutEnum::Tag1; let d = NicheLayoutEnum::Data { my_data: CStyleEnum::Exponent }; let e = NicheLayoutEnum::Tag2; let f = Some(&1u32); let g = Option::<&'static u32>::None; let h = Some(&2u64); let i = Option::<&'static u64>::None; let j = Some(12u32); let k = Option::::None; let l = Some(12.34f64); let m = Option::::None; let n = CStyleEnum::Base; let o = CStyleEnum::Exponent; let p = Some(""IAMA optional string!"".to_string()); let q = OtherEnum::Case1(42u32); } ``` This is what WinDbg Preview shows using the latest rustc nightly: ![image](https://user-images.githubusercontent.com/831192/118285353-57c10780-b49f-11eb-97aa-db3abfc09508.png) Most of the variables don't show a meaningful value expect for a few cases that we have targeted natvis definitions covering. Even worse drilling into many of these variables shows information that can be difficult to interpret without an understanding of the layout of Rust types: ![image](https://user-images.githubusercontent.com/831192/118285609-a1a9ed80-b49f-11eb-9c29-b14576984647.png) With the changes in this PR we're able to write two natvis definitions that cover all enum cases generally. After building with these changes WinDbg now shows this instead: ![image](https://user-images.githubusercontent.com/831192/118287730-be472500-b4a1-11eb-8cad-8f6a91c7516b.png) Drilling into the same variables we can see much more useful information: ![image](https://user-images.githubusercontent.com/831192/118287888-e20a6b00-b4a1-11eb-927f-32cf33a31c16.png) Fixes #84670 Fixes #84671",HOORAY,2021-11-03T10:09:06Z,TrolledWoods,NA https://github.com/rust-lang/rust/pull/85296,MERGED,2021-05-14T16:19:55Z,2021-08-12T07:28:28Z,Plugin interface cleanup,bjorn3,eb2226b1f174f3cc644275ef8663be6295a7f704,35,Auto merge of #85296 - bjorn3:plugin_cleanup r=petrochenkov Plugin interface cleanup The first commit performs two uncontroversial cleanups. The second commit removes `#[plugin_registrar]` and instead requires you to export a `__rustc_plugin_registrar` function this will require a change to servo's script_plugins (cc `@jdm)`,HEART,2021-05-14T21:09:18Z,jdm,josh@joshmatthews.net https://github.com/rust-lang/rust/pull/85302,MERGED,2021-05-14T20:08:30Z,2021-05-17T21:56:30Z,Expand WASI abbreviation in docs,r00ster91,8a1403af1e628ca247b7e458747cecab6d28ef6c,1,Rollup merge of #85302 - r00ster91:patch-7 r=joshtriplett Expand WASI abbreviation in docs I was pretty sure this was related to something for WebAssembly but wasn't 100% sure so I checked but even on these top-level docs I couldn't find the abbreviation expanded. I'm normally used to Rust docs being detailed and explanatory and writing abbreviations like this out in full at least once so I thought it was worth the change. Feel free to close this if it's too much.,THUMBS_UP,2021-05-14T21:00:59Z,fmease,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-05-18T18:51:25Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-05-19T04:59:19Z,unageek,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-05-25T12:35:47Z,oberien,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-06-04T14:23:58Z,ahlinc,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HEART,2021-06-17T16:17:48Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-07-08T16:22:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HEART,2021-07-08T16:22:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HOORAY,2021-07-14T20:26:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,THUMBS_UP,2021-07-17T15:19:46Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HEART,2021-09-30T10:03:00Z,luukvanderduim,luukvanderduim@gmail.com https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HOORAY,2021-10-18T16:00:21Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HOORAY,2021-10-19T09:37:02Z,iago-lito,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HEART,2021-10-19T09:37:03Z,iago-lito,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HOORAY,2021-10-22T04:49:03Z,iamhyc,NA https://github.com/rust-lang/rust/pull/85305,MERGED,2021-05-14T21:19:54Z,2021-07-27T08:41:49Z,Stabilize bindings_after_at,MarcusDunn,998cfe5aad7c21eb19a4bca50f05a13354706970,56,Auto merge of #85305 - MarcusDunn:master r=pnkfelix Stabilize bindings_after_at attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490) im pretty new to the whole thing so any pointers are greatly appreciated.,HEART,2021-12-05T13:13:38Z,LowLevelVirtualMan,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-05-14T22:39:16Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-05-15T01:42:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-05-15T02:05:06Z,jumbatm,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,HEART,2021-05-20T16:03:28Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,HEART,2021-06-03T06:33:51Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-06-03T06:33:52Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,HEART,2021-09-05T19:20:47Z,HalfVoxel,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-09-05T19:20:48Z,HalfVoxel,NA https://github.com/rust-lang/rust/pull/85308,CLOSED,2021-05-14T22:26:59Z,2021-09-15T17:13:04Z,[EXPERIMENT] Reduction of monomorphization load through type erasure,cjgillot,NA,NA,NA,ROCKET,2021-09-29T06:53:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85321,MERGED,2021-05-15T09:59:38Z,2022-04-03T10:33:55Z,Use DefPathHash instead of HirId to break inlining cycles.,cjgillot,ec7b753ea91d8a5640388ea74fd231f91394ee9d,1,Auto merge of #85321 - cjgillot:mir-cycle r=bjorn3 Use DefPathHash instead of HirId to break inlining cycles. The `DefPathHash` is stable across incremental compilation sessions so provides a total order on `LocalDefId`. Using it instead of `HirId` ensures the MIR inliner has the same behaviour for incremental and non-incremental compilation. A downside is that the cycle tie break is not as predictable is with `HirId`.,HEART,2022-01-21T01:51:00Z,pierwill,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-15T19:23:23Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-16T08:39:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-20T13:38:01Z,SkiFire13,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-20T16:25:39Z,estebank,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,THUMBS_UP,2021-05-20T16:26:13Z,estebank,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-24T17:30:38Z,bjorn3,NA https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-05-25T01:54:12Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/85343,MERGED,2021-05-15T19:19:28Z,2021-06-06T21:32:43Z,Add variance-related information to lifetime error messages,Aaron1011,35fff69d043b1c0f5c29894e7f4b0da8b039c131,33,Auto merge of #85343 - Aaron1011:variance-diag r=estebank Add variance-related information to lifetime error messages This PR adds a basic framework for displaying variance-related information in error messages. For example: ``` error: lifetime may not live long enough --> $DIR/type-check-pointer-comparisons.rs:12:5 | LL | fn compare_mut<'a 'b>(x: *mut &'a i32 y: *mut &'b i32) { | -- -- lifetime `'b` defined here | | | lifetime `'a` defined here LL | x == y; | ^ requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable pointer to &i32 = note: mutable pointers are invariant over their type parameter = help: see for more information about variance ``` The last three lines are new. This is accomplished by adding a new struct `VarianceDiagInfo` and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`) we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error we use the `VarianceDiagInfo` to add additional information to the error message. This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs. Limitations: * We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice' our variance will never change again after it becomes invariant. Handling contravariance would be trickier since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments we can probably get away without a very fancy message for cases involving contravariance. * `VarianceDiagInfo` currently only handles mutable pointers/references. However user-defined types (structs enums and unions) have the variance of their type parameters inferred so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred. * The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.,HEART,2021-07-06T07:56:54Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85346,MERGED,2021-05-15T21:59:22Z,2021-11-25T08:16:21Z,Account for incorrect `impl Foo {}` syntax,estebank,c6eda7d8a7af3ef51311d3106874a7d8de994edc,10,Auto merge of #85346 - estebank:issue-84946 r=nagisa varkor Account for incorrect `impl Foo {}` syntax Fix #84946,THUMBS_UP,2021-07-06T16:34:23Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/85346,MERGED,2021-05-15T21:59:22Z,2021-11-25T08:16:21Z,Account for incorrect `impl Foo {}` syntax,estebank,c6eda7d8a7af3ef51311d3106874a7d8de994edc,10,Auto merge of #85346 - estebank:issue-84946 r=nagisa varkor Account for incorrect `impl Foo {}` syntax Fix #84946,THUMBS_UP,2021-10-01T01:54:23Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85353,MERGED,2021-05-16T00:07:16Z,2021-05-17T07:34:35Z,Allow `async {}` expressions in const contexts,jonas-schievink,44ec846f4ea68ffa6d06e7d68f078bd3cc59d4ec,10,Auto merge of #85353 - jonas-schievink:async-blocks-in-ctfe r=oli-obk Allow `async {}` expressions in const contexts Gated behind a new `const_async_blocks` feature.,HEART,2021-05-20T17:25:22Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/85353,MERGED,2021-05-16T00:07:16Z,2021-05-17T07:34:35Z,Allow `async {}` expressions in const contexts,jonas-schievink,44ec846f4ea68ffa6d06e7d68f078bd3cc59d4ec,10,Auto merge of #85353 - jonas-schievink:async-blocks-in-ctfe r=oli-obk Allow `async {}` expressions in const contexts Gated behind a new `const_async_blocks` feature.,HEART,2021-05-22T23:05:40Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/85353,MERGED,2021-05-16T00:07:16Z,2021-05-17T07:34:35Z,Allow `async {}` expressions in const contexts,jonas-schievink,44ec846f4ea68ffa6d06e7d68f078bd3cc59d4ec,10,Auto merge of #85353 - jonas-schievink:async-blocks-in-ctfe r=oli-obk Allow `async {}` expressions in const contexts Gated behind a new `const_async_blocks` feature.,HEART,2021-07-06T08:15:33Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85361,MERGED,2021-05-16T08:27:25Z,2021-05-25T13:53:49Z,Use TargetTriple::from_path in rustdoc,bjorn3,6b0b81b098835615d40028680c46d005cfaa9eab,6,Rollup merge of #85361 - bjorn3:rustdoc_target_json_path_canonicalize r=jyn514 Use TargetTriple::from_path in rustdoc This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.,HEART,2021-05-16T14:17:35Z,ojeda,NA https://github.com/rust-lang/rust/pull/85361,MERGED,2021-05-16T08:27:25Z,2021-05-25T13:53:49Z,Use TargetTriple::from_path in rustdoc,bjorn3,6b0b81b098835615d40028680c46d005cfaa9eab,6,Rollup merge of #85361 - bjorn3:rustdoc_target_json_path_canonicalize r=jyn514 Use TargetTriple::from_path in rustdoc This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.,HEART,2021-05-16T23:30:17Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/85361,MERGED,2021-05-16T08:27:25Z,2021-05-25T13:53:49Z,Use TargetTriple::from_path in rustdoc,bjorn3,6b0b81b098835615d40028680c46d005cfaa9eab,6,Rollup merge of #85361 - bjorn3:rustdoc_target_json_path_canonicalize r=jyn514 Use TargetTriple::from_path in rustdoc This fixes the problem reported in https://github.com/Rust-for-Linux/linux/pull/272 where rustdoc requires the absolute path of a target spec json instead of accepting a relative path like rustc.,HEART,2021-05-16T23:46:23Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/85363,MERGED,2021-05-16T10:54:24Z,2021-07-08T15:06:51Z,Support pretty printing slices using GDB,EFanZh,0deb536ff987d7200f5ea35634781e9df9d5b666,7,Auto merge of #85363 - EFanZh:gdb-pretty-print-slices r=michaelwoerister Support pretty printing slices using GDB Support pretty printing `&[T]` `&mut [T]` and `&mut str` types using GDB. Support pretty printing `&mut [T]` and `&mut str` types using LLDB. Fixes #85219.,HEART,2021-06-08T07:23:10Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/85366,CLOSED,2021-05-16T11:19:42Z,2021-12-07T23:01:33Z,Enable some debug info tests,EFanZh,NA,NA,NA,HEART,2021-06-18T14:21:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/85366,CLOSED,2021-05-16T11:19:42Z,2021-12-07T23:01:33Z,Enable some debug info tests,EFanZh,NA,NA,NA,HEART,2021-06-21T13:54:17Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85369,MERGED,2021-05-16T14:36:05Z,2021-05-18T17:30:24Z,Suggest borrowing if a trait implementation is found for &/&mut ,FabianWolff,fad04ff60e36e5638b23f5fb5ce3c4598603119f,10,"Rollup merge of #85369 - FabianWolff:issue-84973 r=jackh726 Suggest borrowing if a trait implementation is found for &/&mut This pull request fixes #84973 by suggesting to borrow if a trait is not implemented for some type `T` but it is for `&T` or `&mut T`. For instance: ```rust trait Ti {} impl Ti for &T {} fn foo(_: T) {} trait Tm {} impl Tm for &mut T {} fn bar(_: T) {} fn main() { let a: i32 = 5; foo(a); let b: Box = Box::new(42); bar(b); } ``` gives on current nightly: ``` error[E0277]: the trait bound `i32: Ti` is not satisfied --> t2.rs:11:9 | 3 | fn foo(_: T) {} | -- required by this bound in `foo` ... 11 | foo(a); | ^ the trait `Ti` is not implemented for `i32` error[E0277]: the trait bound `Box: Tm` is not satisfied --> t2.rs:14:9 | 7 | fn bar(_: T) {} | -- required by this bound in `bar` ... 14 | bar(b); | ^ the trait `Tm` is not implemented for `Box` error: aborting due to 2 previous errors ``` whereas with my changes I get: ``` error[E0277]: the trait bound `i32: Ti` is not satisfied --> t2.rs:11:9 | 3 | fn foo(_: T) {} | -- required by this bound in `foo` ... 11 | foo(a); | ^ | | | expected an implementor of trait `Ti` | help: consider borrowing here: `&a` error[E0277]: the trait bound `Box: Tm` is not satisfied --> t2.rs:14:9 | 7 | fn bar(_: T) {} | -- required by this bound in `bar` ... 14 | bar(b); | ^ | | | expected an implementor of trait `Tm` | help: consider borrowing mutably here: `&mut b` error: aborting due to 2 previous errors ``` In my implementation I have added a ""blacklist"" to make these suggestions flexible. In particular suggesting to borrow can interfere with other suggestions such as to add another trait bound to a generic argument. I have tried to configure this blacklist to cause the least amount of test case failures i.e. to model the current behavior as closely as possible (I only had to change one existing test case and this change was quite clearly an improvement).",HEART,2021-05-30T19:51:32Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85379,MERGED,2021-05-16T19:54:58Z,2021-10-16T01:41:49Z,Add abstract namespace support for Unix domain sockets,mdaverde,6cc0a764e082d9c0abcf37a768d5889247ba13e2,5,"Auto merge of #85379 - mdaverde:uds-abstract r=joshtriplett Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: #85410 Further context: #42048 ## Non-platform specific additions `UnixListener::bind_addr(&SocketAddr) -> Result` `UnixStream::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::bind_addr(&SocketAddr) -> Result` `UnixDatagram::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::send_to_addr(&self &[u8] &SocketAddr) -> Result` ## Platform-specific (Linux) additions `SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr` `SockerAddr::as_abstract_namespace() -> Option<&[u8]>` ## Example ```rust #![feature(unix_socket_abstract)] use std::os::unix::net::{UnixListener SocketAddr}; fn main() -> std::io::Result<()> { let addr = SocketAddr::from_abstract_namespace(b""namespace"")?; // Linux only let listener = match UnixListener::bind_addr(&addr) { Ok(sock) => sock Err(err) => { println!(""Couldn't bind: {:?}"" err); return Err(err); } }; Ok(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](https://github.com/rust-lang/rust/commit/c4db0685b181f12c4285dac3d932f1859bba74f5) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname` `SockerAddr::from_unnamed`). Cheers!",HEART,2021-06-07T20:14:16Z,tjkirch,NA https://github.com/rust-lang/rust/pull/85379,MERGED,2021-05-16T19:54:58Z,2021-10-16T01:41:49Z,Add abstract namespace support for Unix domain sockets,mdaverde,6cc0a764e082d9c0abcf37a768d5889247ba13e2,5,"Auto merge of #85379 - mdaverde:uds-abstract r=joshtriplett Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: #85410 Further context: #42048 ## Non-platform specific additions `UnixListener::bind_addr(&SocketAddr) -> Result` `UnixStream::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::bind_addr(&SocketAddr) -> Result` `UnixDatagram::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::send_to_addr(&self &[u8] &SocketAddr) -> Result` ## Platform-specific (Linux) additions `SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr` `SockerAddr::as_abstract_namespace() -> Option<&[u8]>` ## Example ```rust #![feature(unix_socket_abstract)] use std::os::unix::net::{UnixListener SocketAddr}; fn main() -> std::io::Result<()> { let addr = SocketAddr::from_abstract_namespace(b""namespace"")?; // Linux only let listener = match UnixListener::bind_addr(&addr) { Ok(sock) => sock Err(err) => { println!(""Couldn't bind: {:?}"" err); return Err(err); } }; Ok(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](https://github.com/rust-lang/rust/commit/c4db0685b181f12c4285dac3d932f1859bba74f5) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname` `SockerAddr::from_unnamed`). Cheers!",HEART,2021-10-04T16:05:49Z,LinkTed,link.ted@mailbox.org https://github.com/rust-lang/rust/pull/85379,MERGED,2021-05-16T19:54:58Z,2021-10-16T01:41:49Z,Add abstract namespace support for Unix domain sockets,mdaverde,6cc0a764e082d9c0abcf37a768d5889247ba13e2,5,"Auto merge of #85379 - mdaverde:uds-abstract r=joshtriplett Add abstract namespace support for Unix domain sockets Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts. Feature name: `unix_socket_abstract` Tracking issue: #85410 Further context: #42048 ## Non-platform specific additions `UnixListener::bind_addr(&SocketAddr) -> Result` `UnixStream::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::bind_addr(&SocketAddr) -> Result` `UnixDatagram::connect_addr(&SocketAddr) -> Result<()>` `UnixDatagram::send_to_addr(&self &[u8] &SocketAddr) -> Result` ## Platform-specific (Linux) additions `SocketAddr::from_abstract_namespace(&[u8]) -> SocketAddr` `SockerAddr::as_abstract_namespace() -> Option<&[u8]>` ## Example ```rust #![feature(unix_socket_abstract)] use std::os::unix::net::{UnixListener SocketAddr}; fn main() -> std::io::Result<()> { let addr = SocketAddr::from_abstract_namespace(b""namespace"")?; // Linux only let listener = match UnixListener::bind_addr(&addr) { Ok(sock) => sock Err(err) => { println!(""Couldn't bind: {:?}"" err); return Err(err); } }; Ok(()) } ``` ## Further Details The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](https://github.com/rust-lang/rust/commit/c4db0685b181f12c4285dac3d932f1859bba74f5) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches. A comment I did have was with this change we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname` `SockerAddr::from_unnamed`). Cheers!",HEART,2021-10-16T05:43:23Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/85382,MERGED,2021-05-16T21:19:08Z,2021-05-21T05:20:47Z,Always produce sub-obligations when using cached projection result,Aaron1011,6f5a198ffc0b624783a81e57e1d29c69283949c1,1,Auto merge of #85382 - Aaron1011:project-eval r=nikomatsakis Always produce sub-obligations when using cached projection result See https://github.com/rust-lang/rust/issues/85360 When we skip adding the sub-obligations to the `obligation` list we can affect whether or not the final result is `EvaluatedToOk` or `EvaluatedToOkModuloObligations`. This creates problems for incremental compilation since the projection cache is untracked shared state. To solve this issue we unconditionally process the sub-obligations. Surprisingly this is a slight performance *win* in many cases.,HEART,2021-05-17T03:19:38Z,Imberflur,NA https://github.com/rust-lang/rust/pull/85392,CLOSED,2021-05-17T02:14:00Z,2021-05-17T09:22:13Z,Revert #13871 in a new form.,icefoxen,NA,NA,NA,LAUGH,2021-05-17T02:20:55Z,brendanzab,NA https://github.com/rust-lang/rust/pull/85392,CLOSED,2021-05-17T02:14:00Z,2021-05-17T09:22:13Z,Revert #13871 in a new form.,icefoxen,NA,NA,NA,LAUGH,2021-05-17T02:43:25Z,ThePuzzlemaker,tpzker@thepuzzlemaker.info https://github.com/rust-lang/rust/pull/85392,CLOSED,2021-05-17T02:14:00Z,2021-05-17T09:22:13Z,Revert #13871 in a new form.,icefoxen,NA,NA,NA,LAUGH,2021-05-17T04:18:22Z,SirJosh3917,NA https://github.com/rust-lang/rust/pull/85393,MERGED,2021-05-17T02:27:42Z,2021-05-18T17:30:24Z,Suppress spurious errors inside `async fn`,Aaron1011,5f544bcf70c867f46f6e4766bf7c38cd7f5736f8,3,Rollup merge of #85393 - Aaron1011:async-type-err r=varkor Suppress spurious errors inside `async fn` Fixes #73741,HOORAY,2021-05-27T06:04:47Z,Kestrer,NA https://github.com/rust-lang/rust/pull/85406,MERGED,2021-05-17T10:34:34Z,2021-06-16T01:21:55Z,Integrate binary search codes of binary_search_by and partition_point,VillSnow,684ca335d5620c973345dbc881158fd38402af70,1,Auto merge of #85406 - VillSnow:integrate_binary_search r=JohnTitor Integrate binary search codes of binary_search_by and partition_point For now partition_point has own binary search code piece. It is because binary_search_by had called the comparer more times and the author (=me) wanted to avoid it. However now binary_search_by uses the comparer minimum times. (#74024) So it's time to integrate them. The appearance of the codes are a bit different but both use completely same logic.,THUMBS_UP,2021-05-28T11:55:28Z,Folyd,NA https://github.com/rust-lang/rust/pull/85406,MERGED,2021-05-17T10:34:34Z,2021-06-16T01:21:55Z,Integrate binary search codes of binary_search_by and partition_point,VillSnow,684ca335d5620c973345dbc881158fd38402af70,1,Auto merge of #85406 - VillSnow:integrate_binary_search r=JohnTitor Integrate binary search codes of binary_search_by and partition_point For now partition_point has own binary search code piece. It is because binary_search_by had called the comparer more times and the author (=me) wanted to avoid it. However now binary_search_by uses the comparer minimum times. (#74024) So it's time to integrate them. The appearance of the codes are a bit different but both use completely same logic.,THUMBS_UP,2021-06-24T21:34:41Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/85408,MERGED,2021-05-17T11:31:29Z,2021-05-17T21:56:29Z,remove size field from Allocation,RalfJung,af1ac55cbf8ebf6f1486d7cf55b8f8386188b7f8,23,Rollup merge of #85408 - RalfJung:alloc-size r=oli-obk remove size field from Allocation This is a part of https://github.com/rust-lang/rust/pull/85376 that can be easily split out. r? ``@oli-obk``,HEART,2021-05-17T12:13:54Z,oli-obk,NA https://github.com/rust-lang/rust/pull/85421,MERGED,2021-05-17T21:23:35Z,2021-06-18T17:13:24Z,Remove some last remants of {push pop}_unsafe!,Smittyvb,312b894cc12240a3fcc645474c3daa14f7d568ea,10,Auto merge of #85421 - Smittyvb:rm_pushpop_unsafe r=matthewjasper Remove some last remants of {push pop}_unsafe! These macros have already been removed but there was still some code handling these macros. That code is now removed.,HEART,2021-05-25T06:35:14Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85423,MERGED,2021-05-18T02:10:09Z,2021-05-18T20:50:02Z,Don't require cmake on Windows when LLVM isn't being built,jyn514,aef6848cba1d710704caabc26d451fa8e3535dfc,1,"Rollup merge of #85423 - jyn514:cmake r=Mark-Simulacrum Don't require cmake on Windows when LLVM isn't being built Previously setting `download-ci-llvm = true` when cmake wasn't installed would give the following error: ``` failed to execute command: ""cmake"" ""--help"" error: The system cannot find the file specified. (os error 2) ```",THUMBS_UP,2021-05-18T20:58:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-19T05:55:38Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-19T12:15:07Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-19T19:39:47Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-20T14:08:14Z,taiki-e,NA https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-20T16:59:36Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HEART,2021-05-20T16:59:40Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/85457,MERGED,2021-05-19T01:55:20Z,2021-06-05T06:17:18Z,Remove `doc(include)`,jyn514,2c106885d5763250d3c5d5ca19b8491af816581d,28,Auto merge of #85457 - jyn514:remove-doc-include r=GuillaumeGomez Remove `doc(include)` This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539 but technically it was for deprecating not removing the feature altogether. This should not be merged before #83366. cc `@petrochenkov`,HOORAY,2021-05-21T19:06:15Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/85464,MERGED,2021-05-19T10:42:33Z,2021-05-20T10:23:03Z,Fix UB in documented example for `ptr::swap`,steffahn,2065c4b0960a4726f7d6bf53d53ef76f11555de3,1,Rollup merge of #85464 - steffahn:fix_ub_in_ptr_swap_docs r=dtolnay Fix UB in documented example for `ptr::swap` Compare [this (short) discussion on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Pointers.20to.20overlapping.20arrays) (or [in the archive](https://zulip-archive.rust-lang.org/122651general/92017Pointerstooverlappingarrays.html) if you don’t have an account). ``@rustbot`` label T-doc T-libs,THUMBS_UP,2021-05-19T11:14:08Z,SkiFire13,NA https://github.com/rust-lang/rust/pull/85470,MERGED,2021-05-19T13:47:36Z,2021-05-20T10:23:03Z,Fix invalid CSS rules for a:hover,GuillaumeGomez,b2becf09d36d3d8d7706da1ebfe730eba7862117,3,Rollup merge of #85470 - GuillaumeGomez:fix-css-rules r=jsha Fix invalid CSS rules for a:hover When hovering some links: ![Screenshot from 2021-05-19 15-00-31](https://user-images.githubusercontent.com/3050060/118823585-5f2a4b80-b8b9-11eb-8043-bb7759a178c7.png) ![Screenshot from 2021-05-19 15-00-29](https://user-images.githubusercontent.com/3050060/118823566-5b96c480-b8b9-11eb-8c4e-08e490752fbf.png) It is a side-effect from #84462. r? ```@jsha```,HEART,2021-05-21T19:30:13Z,cynecx,NA https://github.com/rust-lang/rust/pull/85482,MERGED,2021-05-19T20:06:08Z,2021-05-21T16:30:23Z,`#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff,scottmcm,af2ed1b51887ede4d766ee123d3fa216970d1fdd,6,Auto merge of #85482 - scottmcm:more-try-bootstrap r=yaahc `#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff Closes #46871 r? `@yaahc`,HEART,2021-05-19T20:20:08Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85482,MERGED,2021-05-19T20:06:08Z,2021-05-21T16:30:23Z,`#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff,scottmcm,af2ed1b51887ede4d766ee123d3fa216970d1fdd,6,Auto merge of #85482 - scottmcm:more-try-bootstrap r=yaahc `#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff Closes #46871 r? `@yaahc`,ROCKET,2021-05-19T20:20:09Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85482,MERGED,2021-05-19T20:06:08Z,2021-05-21T16:30:23Z,`#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff,scottmcm,af2ed1b51887ede4d766ee123d3fa216970d1fdd,6,Auto merge of #85482 - scottmcm:more-try-bootstrap r=yaahc `#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff Closes #46871 r? `@yaahc`,HOORAY,2021-05-19T20:20:11Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85482,MERGED,2021-05-19T20:06:08Z,2021-05-21T16:30:23Z,`#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff,scottmcm,af2ed1b51887ede4d766ee123d3fa216970d1fdd,6,Auto merge of #85482 - scottmcm:more-try-bootstrap r=yaahc `#[cfg(bootstrap)]` out `NoneError` and other v1 try_trait stuff Closes #46871 r? `@yaahc`,EYES,2021-05-19T21:27:13Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/85496,CLOSED,2021-05-20T01:59:24Z,2021-09-15T17:10:17Z,Copy built tools to stage sysroot,Bobo1239,NA,NA,NA,HEART,2021-05-20T07:16:46Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T02:48:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T03:48:40Z,cynecx,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T07:00:45Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T07:19:19Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-20T07:19:21Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-05-20T07:19:24Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T12:46:36Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T12:51:27Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T12:51:44Z,varkor,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T13:03:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-20T14:08:38Z,r00ster91,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T15:01:52Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T15:22:18Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-20T15:22:20Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-05-20T15:22:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T16:56:59Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T18:16:11Z,darksv,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-20T18:16:11Z,darksv,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-05-20T18:16:12Z,darksv,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-20T19:34:16Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T20:08:29Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-20T22:27:09Z,vultix,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-24T14:09:48Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-25T01:40:07Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-05-25T18:08:51Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-05-27T09:24:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-02T16:15:48Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-04T15:28:45Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-06-04T15:28:46Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-07T20:17:55Z,denzp,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-06-07T20:17:56Z,denzp,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-06-07T20:17:56Z,denzp,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-09T09:13:05Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-09T11:10:49Z,MrAS04,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-10T08:10:26Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-10T21:26:35Z,Frizi,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-11T00:18:11Z,tema3210,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-16T11:06:45Z,mati865,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-20T07:41:14Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-22T14:20:50Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-06-27T22:08:09Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-06-28T19:45:42Z,mbrobbel,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-28T20:57:53Z,ahlinc,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-06-28T20:57:57Z,ahlinc,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-06-28T20:57:57Z,ahlinc,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-06-29T06:52:46Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-07-04T23:36:42Z,camelid,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-07-07T20:18:11Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-07-07T20:18:12Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-07-19T16:50:57Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-07-21T16:50:13Z,Avarel,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-07-23T18:52:20Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-07-23T18:52:22Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-07-30T07:33:21Z,M-Adoo,Adoo@outlook.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-08-06T07:26:42Z,mikialex,18516340862@163.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-09T18:28:57Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-08-23T15:13:07Z,tema3210,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-25T01:23:26Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T08:01:25Z,mkroening,mkroening@posteo.net https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T09:34:43Z,bluss,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T10:16:05Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-08-26T10:16:06Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-26T10:16:08Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-08-26T10:16:11Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T12:17:06Z,DanielBatesJ,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T13:55:34Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-08-26T13:55:38Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-26T13:55:38Z,Ratysz,alexander.sepity@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-26T14:06:22Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T15:09:17Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T20:04:30Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-26T22:48:56Z,elpiel,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-26T22:48:58Z,elpiel,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-27T02:58:43Z,zimond,daizhuoxian@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-27T07:33:37Z,fd,simon.menke@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-27T08:19:03Z,adnahmed,mailtoadnan.ahmed@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-08-27T09:46:13Z,yerke,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-27T09:46:14Z,yerke,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-08-27T09:46:17Z,yerke,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-27T09:46:19Z,yerke,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-08-27T10:06:25Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-08-27T23:54:54Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-09-03T06:24:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-09-03T06:24:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-09-03T06:24:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-09-03T06:24:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-09-08T16:44:08Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-09-08T16:44:08Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-09-08T16:44:09Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-09-08T16:44:10Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-09-08T20:21:07Z,Kestrer,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-09-08T20:21:08Z,Kestrer,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HEART,2021-09-08T20:21:08Z,Kestrer,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,ROCKET,2021-09-08T20:21:10Z,Kestrer,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,HOORAY,2021-09-17T05:12:37Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/85499,MERGED,2021-05-20T02:47:19Z,2021-08-25T22:48:58Z,Normalize projections under binders,jackh726,0afc20860eb98a29d9bbeea80f2acc5be38c6bf3,55,Auto merge of #85499 - jackh726:assoc-type-norm-rebase r=nikomatsakis Normalize projections under binders Fixes #70243 Fixes #70120 Fixes #62529 Fixes #87219 Issues to followup on after (probably fixed but no test added here): #76956 #56556 #79207 #85636 r? `@nikomatsakis`,THUMBS_UP,2021-09-22T03:53:47Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-05-21T13:57:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-05-21T23:27:07Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-05-24T19:48:01Z,mati865,NA https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-05-25T18:11:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-06-20T07:15:04Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/85530,CLOSED,2021-05-20T22:53:10Z,2021-08-08T10:45:10Z,Use Rust Symbol Mangling by default,tmiasko,NA,NA,NA,HOORAY,2021-07-19T21:55:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,THUMBS_UP,2021-05-21T14:41:52Z,VladimirMakaev,vmakaev@gmail.com https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,HEART,2021-05-21T16:13:50Z,alyssaverkade,NA https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,THUMBS_UP,2021-05-21T16:37:28Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,THUMBS_UP,2021-05-21T20:41:40Z,bluss,NA https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,THUMBS_UP,2021-05-25T10:52:38Z,Skgland,NA https://github.com/rust-lang/rust/pull/85535,MERGED,2021-05-21T02:55:42Z,2021-05-26T03:57:56Z,Weak's type parameter may dangle on drop,dtolnay,47a90f452050d4ea484206447babb07dd33c21d5,4,Auto merge of #85535 - dtolnay:weakdangle r=kennytm Weak's type parameter may dangle on drop Way back in https://github.com/rust-lang/rust/commit/34076bc0c9fb9ee718e1cebc407547eef730a080 #\[may_dangle\] was added to Rc\ and Arc\'s Drop impls. That appears to have been because a test added in #28929 used Arc and Rc with dangling references at drop time. However Weak was not covered by that test and therefore no #\[may_dangle\] was forced to be added at the time. As far as dropping Weak has *even less need* to interact with the T than Rc and Arc do. Roughly speaking #\[may_dangle\] describes generic parameters that the outer type's Drop impl does not interact with except by possibly dropping them; no other interaction (such as trait method calls on the generic type) is permissible. It's clear this applies to Rc's and Arc's drop impl which sometimes drop T but otherwise do not interact with one. It applies *even more* to Weak. Dropping a Weak cannot ever cause T's drop impl to run. Either there are strong references still in existence in which case better not drop the T. Or there are no strong references still in existence in which case the T would already have been dropped previously by the drop of the last strong count.,THUMBS_UP,2021-07-06T08:08:37Z,rrbutani,NA https://github.com/rust-lang/rust/pull/85541,MERGED,2021-05-21T10:35:16Z,2021-06-15T07:46:58Z,Update RELEASES.md for 1.53.0,XAMPPRocky,9089771daf6b1f1824446cca3306d7c18084eae0,1,Auto merge of #85541 - XAMPPRocky:relnotes_1.53.0 r=Mark-Simulacrum Update RELEASES.md for 1.53.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes_1.53.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-05-27T15:27:16Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/85541,MERGED,2021-05-21T10:35:16Z,2021-06-15T07:46:58Z,Update RELEASES.md for 1.53.0,XAMPPRocky,9089771daf6b1f1824446cca3306d7c18084eae0,1,Auto merge of #85541 - XAMPPRocky:relnotes_1.53.0 r=Mark-Simulacrum Update RELEASES.md for 1.53.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes_1.53.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-06-04T17:46:38Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85541,MERGED,2021-05-21T10:35:16Z,2021-06-15T07:46:58Z,Update RELEASES.md for 1.53.0,XAMPPRocky,9089771daf6b1f1824446cca3306d7c18084eae0,1,Auto merge of #85541 - XAMPPRocky:relnotes_1.53.0 r=Mark-Simulacrum Update RELEASES.md for 1.53.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes_1.53.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-06-14T18:48:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85556,MERGED,2021-05-21T16:48:24Z,2021-08-24T03:58:22Z,Warn about unreachable code following an expression with an uninhabited type,FabianWolff,5ca596f486707ac1362edad717ad0e9f5b71d0a3,5,"Auto merge of #85556 - FabianWolff:issue-85071 r=estebank jackh726 Warn about unreachable code following an expression with an uninhabited type This pull request fixes #85071. The issue is that liveness analysis currently is ""smarter"" than reachability analysis when it comes to detecting uninhabited types: Unreachable code is detected during type checking where full type information is not yet available. Therefore the check for type inhabitedness is quite crude: https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_typeck/src/check/expr.rs#L202-L205 i.e. it only checks for `!` but not other non-trivially uninhabited types such as empty enums structs containing an uninhabited type etc. By contrast liveness analysis which runs after type checking can benefit from the more sophisticated `tcx.is_ty_uninhabited_from()`: https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L981 https://github.com/rust-lang/rust/blob/fc81ad22c453776de16acf9938976930cf8c9401/compiler/rustc_passes/src/liveness.rs#L996 This can lead to confusing warnings when a variable is reported as unused but the use of the variable is not reported as unreachable. For instance: ```rust enum Foo {} fn f() -> Foo {todo!()} fn main() { let x = f(); let _ = x; } ``` currently leads to ``` warning: unused variable: `x` --> t1.rs:5:9 | 5 | let x = f(); | ^ help: if this is intentional prefix it with an underscore: `_x` | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted ``` which is confusing because `x` _appears_ to be used in line 6. With my changes I get: ``` warning: unreachable expression --> t1.rs:6:13 | 5 | let x = f(); | --- any code following this expression is unreachable 6 | let _ = x; | ^ unreachable expression | = note: `#[warn(unreachable_code)]` on by default note: this expression has type `Foo` which is uninhabited --> t1.rs:5:13 | 5 | let x = f(); | ^^^ warning: unused variable: `x` --> t1.rs:5:9 | 5 | let x = f(); | ^ help: if this is intentional prefix it with an underscore: `_x` | = note: `#[warn(unused_variables)]` on by default warning: 2 warnings emitted ``` My implementation is slightly inelegant because unreachable code warnings can now be issued in two different places (during type checking and during liveness analysis) but I think it is the solution with the least amount of unnecessary code duplication given that the new warning integrates nicely with liveness analysis where unreachable code is already implicitly detected for the purpose of finding unused variables.",HEART,2021-05-24T14:29:49Z,koehlma,mail@koehlma.de https://github.com/rust-lang/rust/pull/85575,MERGED,2021-05-22T04:33:38Z,2021-05-23T05:40:06Z,Fix auto-hide for implementations and implementors.,jsha,85b45b5163ce8c953a4d4857bf3b91748aa63635,3,Rollup merge of #85575 - jsha:fix-toggle-settings r=GuillaumeGomez Fix auto-hide for implementations and implementors. This sets their toggles to be closed in the HTML (matching the default setting) and opens them if the setting indicates to do so. This distinguishes between implementations and implementors based on being descendants of certain named elements. Demo https://hoffman-andrews.com/rust/fix-toggle-settings/std/io/trait.Read.html#implementors and https://hoffman-andrews.com/rust/fix-toggle-settings/std/string/struct.String.html#trait-implementations Fixes #85411 r? `@GuillaumeGomez`,HEART,2021-05-27T17:55:41Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/85577,CLOSED,2021-05-22T06:49:47Z,2021-06-22T07:39:18Z,Add `Box::{reuse set try_set}`,SabrinaJewson,NA,NA,NA,THUMBS_UP,2021-05-26T13:52:35Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/85600,MERGED,2021-05-23T11:50:47Z,2021-08-28T20:58:12Z,build llvm libunwind.a in rustbuild,12101111,926f069950d7211a87fbd81778b420de420daad7,6,Auto merge of #85600 - 12101111:rustbuild-libunwind r=petrochenkov build llvm libunwind.a in rustbuild This PR move the building of llvm-libunwind from build script of libunwind to rustbuild so user don't need a C compiler and recompile this C/C++ library when using build-std and user can use codegen flags `link-self-contained` and cargo flag `build-std-features` to control the behavior of libunwind linking.,THUMBS_UP,2021-06-11T13:16:02Z,nitsky,NA https://github.com/rust-lang/rust/pull/85600,MERGED,2021-05-23T11:50:47Z,2021-08-28T20:58:12Z,build llvm libunwind.a in rustbuild,12101111,926f069950d7211a87fbd81778b420de420daad7,6,Auto merge of #85600 - 12101111:rustbuild-libunwind r=petrochenkov build llvm libunwind.a in rustbuild This PR move the building of llvm-libunwind from build script of libunwind to rustbuild so user don't need a C compiler and recompile this C/C++ library when using build-std and user can use codegen flags `link-self-contained` and cargo flag `build-std-features` to control the behavior of libunwind linking.,THUMBS_UP,2021-08-29T10:39:17Z,sthagen,NA https://github.com/rust-lang/rust/pull/85602,MERGED,2021-05-23T12:38:51Z,2021-05-23T19:42:18Z,Don't hide inherent implementations by default,GuillaumeGomez,d8af907491e20339e41d048d6a32b41ddfa91dfe,1,Auto merge of #85602 - GuillaumeGomez:donthide-inherent-impls r=jsha Don't hide inherent implementations by default Fixes a regression introduced in #85575. r? `@jsha`,HEART,2021-05-27T13:48:51Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-05-23T18:22:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-05-24T00:24:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-05-24T03:47:51Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-05-24T05:35:54Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-05-24T05:35:55Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-05-24T12:40:40Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-05-24T22:23:56Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,EYES,2021-05-30T07:40:40Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-05-31T22:37:04Z,Nufflee,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-05-31T22:37:16Z,Nufflee,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-02T21:40:19Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HOORAY,2021-06-02T21:40:23Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-04T22:39:56Z,wilk10,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-11T13:53:12Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-11T17:52:25Z,CBenoit,bcortier@peculiarz.one https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-11T20:39:37Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-12T07:14:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-12T07:14:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-12T15:36:14Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-12T15:36:17Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,EYES,2021-06-14T03:57:47Z,mooman219,joewcu+git@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-14T03:57:48Z,mooman219,joewcu+git@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-14T03:57:49Z,mooman219,joewcu+git@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HOORAY,2021-06-14T03:57:50Z,mooman219,joewcu+git@gmail.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-16T03:50:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HOORAY,2021-06-24T02:17:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-24T02:17:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,EYES,2021-06-24T02:17:03Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-25T20:50:57Z,a1phyr,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,HEART,2021-06-27T10:32:50Z,thomaseizinger,thomas@eizinger.io https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-06-27T16:12:22Z,snuk182,NA https://github.com/rust-lang/rust/pull/85608,MERGED,2021-05-23T18:16:15Z,2021-06-15T22:56:30Z,Stabilize `ops::ControlFlow` (just the type),scottmcm,5936ecc24f8100b106c2e0cbaa8c1c7d5fef481f,8,Rollup merge of #85608 - scottmcm:stabilize-control-flow-enum-basics r=m-ou-se Stabilize `ops::ControlFlow` (just the type) Tracking issue: https://github.com/rust-lang/rust/issues/75744 (which also tracks items *not* closed by this PR). With the new `?` desugar implemented [it's no longer possible to mix `Result` and `ControlFlow`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13feec97f5c96a9d791d97f7de2d49a6). (At the time of making this PR godbolt was still on the 2021-05-01 nightly where you can see that [the mixing example compiled](https://rust.godbolt.org/z/13Ke54j16).) That resolves the only blocker I know of so I'd like to propose that `ControlFlow` be considered for stabilization. Its basic existence was part of https://github.com/rust-lang/rfcs/pull/3058 where it got a bunch of positive comments (examples [1](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-758277325) [2](https://github.com/rust-lang/rfcs/pull/3058#pullrequestreview-592106494) [3](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-784444155) [4](https://github.com/rust-lang/rfcs/pull/3058#issuecomment-797031584)). Its use in the compiler has been well received (https://github.com/rust-lang/rust/pull/78182#issuecomment-713695594) and there are ecosystem updates interested in using it (https://github.com/rust-itertools/itertools/issues/469#issuecomment-677729589 https://github.com/jonhoo/rust-imap/issues/194). As this will need an FCP picking a libs member manually: r? `@m-ou-se` ## Stabilized APIs ```rust #[derive(Debug Clone Copy PartialEq)] pub enum ControlFlow { /// Exit the operation without running subsequent phases. Break(B) /// Move on to the next phase of the operation as normal. Continue(C) } ``` As well as using `?` on a `ControlFlow` in a function returning `ControlFlow`. (Note in particular that there's no `From::from`-conversion on the `Break` value the way there is for `Err`s.) ## Existing APIs *not* stabilized here All the associated methods and constants: `break_value` `is_continue` `map_break` [`CONTINUE`](https://doc.rust-lang.org/nightly/std/ops/enum.ControlFlow.html#associatedconstant.CONTINUE) etc. Some of the existing methods in nightly seem reasonable some seem like they should be removed and some need more discussion to decide. But none of them are *essential* so [as in the RFC](https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#methods-on-controlflow) they're all omitted from this PR. They can be considered separately later as further usage demonstrates which are important.,THUMBS_UP,2021-07-26T15:12:57Z,vultix,NA https://github.com/rust-lang/rust/pull/85625,MERGED,2021-05-24T10:48:58Z,2021-05-26T16:35:49Z,Prevent double drop in `Vec::dedup_by` if a destructor panics,SkiFire13,27899e3887c1e7c767b51ca5ee5e88ac4a543687,2,Rollup merge of #85625 - SkiFire13:fix-85613-vec-dedup-drop-panics r=nagisa Prevent double drop in `Vec::dedup_by` if a destructor panics Fixes #85613,HEART,2021-05-24T12:36:48Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85625,MERGED,2021-05-24T10:48:58Z,2021-05-26T16:35:49Z,Prevent double drop in `Vec::dedup_by` if a destructor panics,SkiFire13,27899e3887c1e7c767b51ca5ee5e88ac4a543687,2,Rollup merge of #85625 - SkiFire13:fix-85613-vec-dedup-drop-panics r=nagisa Prevent double drop in `Vec::dedup_by` if a destructor panics Fixes #85613,THUMBS_UP,2021-05-24T17:02:09Z,the8472,NA https://github.com/rust-lang/rust/pull/85625,MERGED,2021-05-24T10:48:58Z,2021-05-26T16:35:49Z,Prevent double drop in `Vec::dedup_by` if a destructor panics,SkiFire13,27899e3887c1e7c767b51ca5ee5e88ac4a543687,2,Rollup merge of #85625 - SkiFire13:fix-85613-vec-dedup-drop-panics r=nagisa Prevent double drop in `Vec::dedup_by` if a destructor panics Fixes #85613,THUMBS_UP,2022-01-24T17:48:06Z,Soveu,NA https://github.com/rust-lang/rust/pull/85625,MERGED,2021-05-24T10:48:58Z,2021-05-26T16:35:49Z,Prevent double drop in `Vec::dedup_by` if a destructor panics,SkiFire13,27899e3887c1e7c767b51ca5ee5e88ac4a543687,2,Rollup merge of #85625 - SkiFire13:fix-85613-vec-dedup-drop-panics r=nagisa Prevent double drop in `Vec::dedup_by` if a destructor panics Fixes #85613,HEART,2022-01-24T17:48:10Z,Soveu,NA https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-24T17:48:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-24T18:12:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-25T18:16:50Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-25T18:43:17Z,tmiasko,NA https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-25T19:10:38Z,samlh,NA https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-05-26T18:21:16Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-06-03T14:26:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-06-03T18:13:15Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/85633,MERGED,2021-05-24T14:55:45Z,2021-05-26T16:35:50Z,Post-monomorphization errors traces MVP,lqd,4b0014e3bb586a3aa73a2f5d2de2f1f5bef51778,5,"Rollup merge of #85633 - lqd:stackless_span_stacks r=oli-obk Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in #85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen so only when building code that actually uses these code paths. Check builds don't trigger them neither does unused code) So in this PR we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors we print a diagnostic about the current collection step so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a b 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that #85155 is a reduced version of a case happening in the wild to indirect users of the `rustfft` crate as seen in https://github.com/ejmahler/RustFFT/issues/74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:
``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX ""IMM value not in expected range""); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range' ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0] rows[2] 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self) _mm_permute_pd(self 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error try `rustc --explain E0080`. error: could not compile `rustfft` To learn more run the command again with --verbose. ```
I've developed and discussed this with them so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155 as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli but we decided to not include them in this PR for now)",HEART,2021-06-05T08:50:51Z,Herschel,mwelsh@gmail.com https://github.com/rust-lang/rust/pull/85637,MERGED,2021-05-24T16:19:56Z,2021-06-21T04:04:00Z,document PartialEq PartialOrd Ord requirements more explicitly,RalfJung,e6732e05e4ff7af66084bf2c212a7fbf1ec6a574,1,Rollup merge of #85637 - RalfJung:partial-ord r=m-ou-se document PartialEq PartialOrd Ord requirements more explicitly This is the result of discussion in https://github.com/rust-lang/rust/issues/50230 in particular [this summary comment](https://github.com/rust-lang/rust/issues/50230#issuecomment-392819364). Fixes https://github.com/rust-lang/rust/issues/50230.,HEART,2021-05-24T16:28:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85637,MERGED,2021-05-24T16:19:56Z,2021-06-21T04:04:00Z,document PartialEq PartialOrd Ord requirements more explicitly,RalfJung,e6732e05e4ff7af66084bf2c212a7fbf1ec6a574,1,Rollup merge of #85637 - RalfJung:partial-ord r=m-ou-se document PartialEq PartialOrd Ord requirements more explicitly This is the result of discussion in https://github.com/rust-lang/rust/issues/50230 in particular [this summary comment](https://github.com/rust-lang/rust/issues/50230#issuecomment-392819364). Fixes https://github.com/rust-lang/rust/issues/50230.,HEART,2021-05-24T17:13:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85637,MERGED,2021-05-24T16:19:56Z,2021-06-21T04:04:00Z,document PartialEq PartialOrd Ord requirements more explicitly,RalfJung,e6732e05e4ff7af66084bf2c212a7fbf1ec6a574,1,Rollup merge of #85637 - RalfJung:partial-ord r=m-ou-se document PartialEq PartialOrd Ord requirements more explicitly This is the result of discussion in https://github.com/rust-lang/rust/issues/50230 in particular [this summary comment](https://github.com/rust-lang/rust/issues/50230#issuecomment-392819364). Fixes https://github.com/rust-lang/rust/issues/50230.,HEART,2021-05-24T19:53:05Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/85637,MERGED,2021-05-24T16:19:56Z,2021-06-21T04:04:00Z,document PartialEq PartialOrd Ord requirements more explicitly,RalfJung,e6732e05e4ff7af66084bf2c212a7fbf1ec6a574,1,Rollup merge of #85637 - RalfJung:partial-ord r=m-ou-se document PartialEq PartialOrd Ord requirements more explicitly This is the result of discussion in https://github.com/rust-lang/rust/issues/50230 in particular [this summary comment](https://github.com/rust-lang/rust/issues/50230#issuecomment-392819364). Fixes https://github.com/rust-lang/rust/issues/50230.,HEART,2021-05-24T19:53:49Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/85645,MERGED,2021-05-24T21:34:52Z,2021-05-26T09:51:59Z,Demote `ControlFlow::{from|into}_try` to `pub(crate)`,scottmcm,587de8e5f9ef083b2546311f0c2c36bbad0ed8e3,1,Rollup merge of #85645 - scottmcm:demote-from-into-try r=yaahc Demote `ControlFlow::{from|into}_try` to `pub(crate)` They have mediocre names and non-obvious semantics so personally I don't think they're worth trying to stabilize and thus might as well just be internal (they're used for convenience in iterator adapters) not something shown in the rustdocs. I don't think anyone actually wanted to use them outside `core` -- they just got made public-but-unstable along with the whole type in https://github.com/rust-lang/rust/pull/76204 that promoted `LoopState` from an internal type to the exposed `ControlFlow` type. cc https://github.com/rust-lang/rust/issues/75744 the tracking issue they mention. cc https://github.com/rust-lang/rust/pull/85608 the PR where I'm proposing stabilizing the type.,THUMBS_UP,2021-05-24T22:15:06Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/85645,MERGED,2021-05-24T21:34:52Z,2021-05-26T09:51:59Z,Demote `ControlFlow::{from|into}_try` to `pub(crate)`,scottmcm,587de8e5f9ef083b2546311f0c2c36bbad0ed8e3,1,Rollup merge of #85645 - scottmcm:demote-from-into-try r=yaahc Demote `ControlFlow::{from|into}_try` to `pub(crate)` They have mediocre names and non-obvious semantics so personally I don't think they're worth trying to stabilize and thus might as well just be internal (they're used for convenience in iterator adapters) not something shown in the rustdocs. I don't think anyone actually wanted to use them outside `core` -- they just got made public-but-unstable along with the whole type in https://github.com/rust-lang/rust/pull/76204 that promoted `LoopState` from an internal type to the exposed `ControlFlow` type. cc https://github.com/rust-lang/rust/issues/75744 the tracking issue they mention. cc https://github.com/rust-lang/rust/pull/85608 the PR where I'm proposing stabilizing the type.,THUMBS_UP,2021-05-25T20:19:37Z,bluss,NA https://github.com/rust-lang/rust/pull/85668,MERGED,2021-05-25T13:14:23Z,2021-05-26T09:51:58Z,Fix tasklist example in rustdoc book.,ehuss,1e51afa9bad9340cd4dc7add9ba64d5fd5042a12,1,"Rollup merge of #85668 - ehuss:fix-rustdoc-tasklist r=Mark-Simulacrum Fix tasklist example in rustdoc book. There were a few issues with the tasklist example in the rustdoc book: * Misspelled ""incomplete"" * Checkmarks were backwards * Didn't show the text for each item * Used HTML which renders differently from how markdown renders it (which uses ""disabled"" marks) * Didn't use blockquotes to offset the example like the other extensions do * Missing a colon Before: After: ",THUMBS_UP,2021-05-25T15:20:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85686,MERGED,2021-05-25T17:47:25Z,2021-07-18T04:54:13Z,Add help on reinitialization between move and access,ptrojahn,77d155973c6c22a0e1af49a4a9bac024f697851d,3,Auto merge of #85686 - ptrojahn:loop_reinitialize r=estebank Add help on reinitialization between move and access Fixes #83760,HOORAY,2021-05-26T02:59:24Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85686,MERGED,2021-05-25T17:47:25Z,2021-07-18T04:54:13Z,Add help on reinitialization between move and access,ptrojahn,77d155973c6c22a0e1af49a4a9bac024f697851d,3,Auto merge of #85686 - ptrojahn:loop_reinitialize r=estebank Add help on reinitialization between move and access Fixes #83760,THUMBS_UP,2021-06-14T15:54:43Z,estebank,NA https://github.com/rust-lang/rust/pull/85690,MERGED,2021-05-25T18:49:17Z,2021-08-28T23:39:03Z,Macros 2.0-ify rustc_arena,bstrie,5eacec9ec7e112a0de1011519a57c45586d58414,1,Auto merge of #85690 - bstrie:m2_arena r=jackh726 nagisa Macros 2.0-ify rustc_arena For the purpose of battle-testing macros 2.0 I'm looking to dogfood it in rustc one crate at a time. (Note that there are only 12 changed lines if you ignore whitespace.),THUMBS_UP,2021-05-28T11:59:18Z,fmease,NA https://github.com/rust-lang/rust/pull/85698,MERGED,2021-05-25T21:44:42Z,2021-05-29T21:51:51Z,Don't panic when failing to initialize incremental directory.,ehuss,b663c0f4f6ff84a8c9df0f708e1f8d628330d973,9,Auto merge of #85698 - ehuss:incremental-session-panic r=estebank Don't panic when failing to initialize incremental directory. This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary and there are already plenty of issues reporting this. This has been panicking since 1.22 due to I think #44502 which was a major rework of how things work. Previously things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22 [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today the problem is that it calls [`prepare_session_directory`](https://github.com/rust-lang/rust/blob/fbf1b1a7193cda17008ab590e06ad28d9924023b/compiler/rustc_interface/src/passes.rs#L175-L179) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`. The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails. Some other options: * Ignore directory lock failures. * Print a warning on directory lock failure but otherwise continue with incremental enabled. * Print a warning on directory lock failure and disable incremental. * Provide a different locking mechanism. Cargo ignores lock errors if locking is not supported so that would be a precedent for the first option. These options would require quite a bit more changes but I'm happy to entertain any of them as I think they all have valid justifications. There is more discussion on the many issues where this is reported: #49773 #59224 #66513 #76251. I'm not sure if this can be considered closing any of those though since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.,HEART,2021-05-27T10:17:02Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/85698,MERGED,2021-05-25T21:44:42Z,2021-05-29T21:51:51Z,Don't panic when failing to initialize incremental directory.,ehuss,b663c0f4f6ff84a8c9df0f708e1f8d628330d973,9,Auto merge of #85698 - ehuss:incremental-session-panic r=estebank Don't panic when failing to initialize incremental directory. This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary and there are already plenty of issues reporting this. This has been panicking since 1.22 due to I think #44502 which was a major rework of how things work. Previously things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22 [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today the problem is that it calls [`prepare_session_directory`](https://github.com/rust-lang/rust/blob/fbf1b1a7193cda17008ab590e06ad28d9924023b/compiler/rustc_interface/src/passes.rs#L175-L179) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`. The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails. Some other options: * Ignore directory lock failures. * Print a warning on directory lock failure but otherwise continue with incremental enabled. * Print a warning on directory lock failure and disable incremental. * Provide a different locking mechanism. Cargo ignores lock errors if locking is not supported so that would be a precedent for the first option. These options would require quite a bit more changes but I'm happy to entertain any of them as I think they all have valid justifications. There is more discussion on the many issues where this is reported: #49773 #59224 #66513 #76251. I'm not sure if this can be considered closing any of those though since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.,HEART,2021-05-27T16:11:07Z,estebank,NA https://github.com/rust-lang/rust/pull/85700,MERGED,2021-05-25T22:11:24Z,2021-05-28T17:44:48Z,Fix static relocation model for PowerPC64,Bobo1239,6f9df55a782c5373c75dfa23e6ba50f8b42318ef,6,Auto merge of #85700 - Bobo1239:dso_local_ppc64 r=nagisa Fix static relocation model for PowerPC64 We now also use `should_assume_dso_local()` for declarations and port two additional cases from clang: - Exclude PPC64 [1] - Exclude thread-local variables [2] [1]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 [2]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1048-L1050 Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358)) r? `@nagisa`,HOORAY,2021-05-25T22:26:17Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/85700,MERGED,2021-05-25T22:11:24Z,2021-05-28T17:44:48Z,Fix static relocation model for PowerPC64,Bobo1239,6f9df55a782c5373c75dfa23e6ba50f8b42318ef,6,Auto merge of #85700 - Bobo1239:dso_local_ppc64 r=nagisa Fix static relocation model for PowerPC64 We now also use `should_assume_dso_local()` for declarations and port two additional cases from clang: - Exclude PPC64 [1] - Exclude thread-local variables [2] [1]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 [2]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1048-L1050 Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358)) r? `@nagisa`,ROCKET,2021-05-25T22:26:18Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/85700,MERGED,2021-05-25T22:11:24Z,2021-05-28T17:44:48Z,Fix static relocation model for PowerPC64,Bobo1239,6f9df55a782c5373c75dfa23e6ba50f8b42318ef,6,Auto merge of #85700 - Bobo1239:dso_local_ppc64 r=nagisa Fix static relocation model for PowerPC64 We now also use `should_assume_dso_local()` for declarations and port two additional cases from clang: - Exclude PPC64 [1] - Exclude thread-local variables [2] [1]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 [2]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1048-L1050 Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358)) r? `@nagisa`,HEART,2021-05-25T22:26:20Z,alex,alex.gaynor@gmail.com https://github.com/rust-lang/rust/pull/85700,MERGED,2021-05-25T22:11:24Z,2021-05-28T17:44:48Z,Fix static relocation model for PowerPC64,Bobo1239,6f9df55a782c5373c75dfa23e6ba50f8b42318ef,6,Auto merge of #85700 - Bobo1239:dso_local_ppc64 r=nagisa Fix static relocation model for PowerPC64 We now also use `should_assume_dso_local()` for declarations and port two additional cases from clang: - Exclude PPC64 [1] - Exclude thread-local variables [2] [1]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 [2]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1048-L1050 Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358)) r? `@nagisa`,HEART,2021-05-25T23:07:32Z,ojeda,NA https://github.com/rust-lang/rust/pull/85700,MERGED,2021-05-25T22:11:24Z,2021-05-28T17:44:48Z,Fix static relocation model for PowerPC64,Bobo1239,6f9df55a782c5373c75dfa23e6ba50f8b42318ef,6,Auto merge of #85700 - Bobo1239:dso_local_ppc64 r=nagisa Fix static relocation model for PowerPC64 We now also use `should_assume_dso_local()` for declarations and port two additional cases from clang: - Exclude PPC64 [1] - Exclude thread-local variables [2] [1]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 [2]: https://github.com/llvm/llvm-project/blob/033138ea452f5f493fb5095e5963419905ad12e1/clang/lib/CodeGen/CodeGenModule.cpp#L1048-L1050 Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358)) r? `@nagisa`,HEART,2021-05-26T00:57:38Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/85706,MERGED,2021-05-26T03:19:59Z,2021-06-03T10:43:39Z,Turn off frame pointer elimination on all Apple platforms. ,jrmuizel,9b1e105ade3cb5b467c94411bbb37168981a02ec,6,"Rollup merge of #85706 - jrmuizel:fpe r=nagisa Turn off frame pointer elimination on all Apple platforms. This ends up disabling frame pointer elimination on aarch64_apple_darwin which matches what clang does by default along with the aarch64_apple_ios and x86_64_apple_darwin targets. Further the Apple docs ""Writing ARM64 Code for Apple Platforms"" has a section called ""Respect the Purpose of Specific CPU Registers"" which specifically calls out the frame pointer register (x29): The frame pointer register (x29) must always address a valid frame record. Some functions — such as leaf functions or tail calls — may opt not to create an entry in this list As a result stack traces are always meaningful even without debug information. Other platforms are updated to not override the default.",THUMBS_UP,2021-05-29T02:35:59Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/85706,MERGED,2021-05-26T03:19:59Z,2021-06-03T10:43:39Z,Turn off frame pointer elimination on all Apple platforms. ,jrmuizel,9b1e105ade3cb5b467c94411bbb37168981a02ec,6,"Rollup merge of #85706 - jrmuizel:fpe r=nagisa Turn off frame pointer elimination on all Apple platforms. This ends up disabling frame pointer elimination on aarch64_apple_darwin which matches what clang does by default along with the aarch64_apple_ios and x86_64_apple_darwin targets. Further the Apple docs ""Writing ARM64 Code for Apple Platforms"" has a section called ""Respect the Purpose of Specific CPU Registers"" which specifically calls out the frame pointer register (x29): The frame pointer register (x29) must always address a valid frame record. Some functions — such as leaf functions or tail calls — may opt not to create an entry in this list As a result stack traces are always meaningful even without debug information. Other platforms are updated to not override the default.",CONFUSED,2021-06-10T10:09:14Z,hkratz,NA https://github.com/rust-lang/rust/pull/85707,MERGED,2021-05-26T03:46:15Z,2021-06-22T09:30:19Z,Add `future_prelude_collision` lint,jam1garner,44f4a87d7047db0deff5ef033fd2af820722e9a5,22,Auto merge of #85707 - jam1garner:future_prelude_collision_lint r=nikomatsakis Add `future_prelude_collision` lint Implements #84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits. Things left to implement: * [x] UI tests for lints * [x] Only emit lint for 2015 and 2018 editions * [ ] Lint name/message bikeshedding * [x] Implement for `FromIterator` (from best I can tell the current approach as mentioned from [this comment](https://github.com/rust-lang/rust/issues/84594#issuecomment-847288288) won't work due to `FromIterator` instances not using dot-call syntax but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)* * [x] Add to `rust-2021-migration` group? (See #85512) (added to `rust-2021-compatibility` group) * [ ] Link to edition guide in lint docs *edit: looked into it `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions feel free to chime in.,THUMBS_UP,2021-05-26T20:43:31Z,estebank,NA https://github.com/rust-lang/rust/pull/85707,MERGED,2021-05-26T03:46:15Z,2021-06-22T09:30:19Z,Add `future_prelude_collision` lint,jam1garner,44f4a87d7047db0deff5ef033fd2af820722e9a5,22,Auto merge of #85707 - jam1garner:future_prelude_collision_lint r=nikomatsakis Add `future_prelude_collision` lint Implements #84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits. Things left to implement: * [x] UI tests for lints * [x] Only emit lint for 2015 and 2018 editions * [ ] Lint name/message bikeshedding * [x] Implement for `FromIterator` (from best I can tell the current approach as mentioned from [this comment](https://github.com/rust-lang/rust/issues/84594#issuecomment-847288288) won't work due to `FromIterator` instances not using dot-call syntax but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)* * [x] Add to `rust-2021-migration` group? (See #85512) (added to `rust-2021-compatibility` group) * [ ] Link to edition guide in lint docs *edit: looked into it `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions feel free to chime in.,HEART,2021-05-27T05:47:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85707,MERGED,2021-05-26T03:46:15Z,2021-06-22T09:30:19Z,Add `future_prelude_collision` lint,jam1garner,44f4a87d7047db0deff5ef033fd2af820722e9a5,22,Auto merge of #85707 - jam1garner:future_prelude_collision_lint r=nikomatsakis Add `future_prelude_collision` lint Implements #84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits. Things left to implement: * [x] UI tests for lints * [x] Only emit lint for 2015 and 2018 editions * [ ] Lint name/message bikeshedding * [x] Implement for `FromIterator` (from best I can tell the current approach as mentioned from [this comment](https://github.com/rust-lang/rust/issues/84594#issuecomment-847288288) won't work due to `FromIterator` instances not using dot-call syntax but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)* * [x] Add to `rust-2021-migration` group? (See #85512) (added to `rust-2021-compatibility` group) * [ ] Link to edition guide in lint docs *edit: looked into it `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions feel free to chime in.,THUMBS_UP,2021-07-01T08:38:52Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85709,MERGED,2021-05-26T04:05:18Z,2021-05-30T22:47:53Z,Use correct edition when parsing `:pat` matchers,Aaron1011,bdd70622e2a721b8b384df103e8514372fef1150,5,Rollup merge of #85709 - Aaron1011:fix-pat-crate-edition r=petrochenkov Use correct edition when parsing `:pat` matchers As described in issue #85708 we currently do not properly decode `SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a result when we decode a span from a foreign crate with `SyntaxContext::root()` we end up up considering it to have the edition of the *current* crate instead of the foreign crate where it was originally created. A full fix for this issue will be a fairly significant undertaking. Fortunately it's possible to implement a partial fix which gives us the correct edition-dependent behavior for `:pat` matchers when the macro is loaded from another crate. Since we have the edition of the macro's defining crate available we can 'recover' from seeing a `SyntaxContext::root()` and use the edition of the macro's defining crate. Any solution to issue #85708 must reproduce the behavior of this targeted fix - properly preserving a foreign `SyntaxContext::root()` means (among other things) preserving its edition which by definition is the edition of the foreign crate itself. Therefore this fix moves us closer to the correct overall solution and does not expose any new incorrect behavior to macros.,THUMBS_UP,2021-05-27T13:51:58Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/85721,MERGED,2021-05-26T12:04:15Z,2021-05-26T19:22:17Z,Update RLS,Xanewok,9a700d2947f2d7f97a2c0dfca3117a8dcc255bdd,2,Auto merge of #85721 - Xanewok:update-rls r=Xanewok Update RLS Closes #85453 r? `@ghost`,HEART,2021-05-26T19:26:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85730,MERGED,2021-05-26T21:27:22Z,2021-05-27T21:14:56Z,Mention workaround for floats in Iterator::{min max},Smittyvb,e30192ac5c3ea61d30e2d8070289524975ea7315,1,Rollup merge of #85730 - Smittyvb:iter-min-max-floats r=m-ou-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.,THUMBS_UP,2021-05-26T23:04:22Z,a1phyr,NA https://github.com/rust-lang/rust/pull/85730,MERGED,2021-05-26T21:27:22Z,2021-05-27T21:14:56Z,Mention workaround for floats in Iterator::{min max},Smittyvb,e30192ac5c3ea61d30e2d8070289524975ea7315,1,Rollup merge of #85730 - Smittyvb:iter-min-max-floats r=m-ou-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.,THUMBS_UP,2021-05-28T14:45:19Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/85737,MERGED,2021-05-27T06:23:07Z,2021-05-27T15:46:51Z,Enable Vec's calloc optimization for Option,scottmcm,ea78d1edf364dd3a4b5ff430f76e2bdd3a713a45,1,Auto merge of #85737 - scottmcm:vec-calloc-option-nonzero r=m-ou-se Enable Vec's calloc optimization for Option Someone on discord noticed that `vec![None::; 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?,ROCKET,2021-05-27T06:24:42Z,smmalis37,NA https://github.com/rust-lang/rust/pull/85737,MERGED,2021-05-27T06:23:07Z,2021-05-27T15:46:51Z,Enable Vec's calloc optimization for Option,scottmcm,ea78d1edf364dd3a4b5ff430f76e2bdd3a713a45,1,Auto merge of #85737 - scottmcm:vec-calloc-option-nonzero r=m-ou-se Enable Vec's calloc optimization for Option Someone on discord noticed that `vec![None::; 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?,ROCKET,2021-05-27T08:09:06Z,rbeneyton,NA https://github.com/rust-lang/rust/pull/85737,MERGED,2021-05-27T06:23:07Z,2021-05-27T15:46:51Z,Enable Vec's calloc optimization for Option,scottmcm,ea78d1edf364dd3a4b5ff430f76e2bdd3a713a45,1,Auto merge of #85737 - scottmcm:vec-calloc-option-nonzero r=m-ou-se Enable Vec's calloc optimization for Option Someone on discord noticed that `vec![None::; 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?,ROCKET,2021-06-03T21:11:34Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85745,MERGED,2021-05-27T11:23:25Z,2021-05-28T08:49:47Z,Add #[track_caller] to panic_any,veber-alex,18135ec85be45df013ecd0d1eb4a49128d043e20,1,"Auto merge of #85745 - veber-alex:panic_any r=m-ou-se Add #[track_caller] to panic_any Report the panic location from the user code. ```rust use std::panic; use std::panic::panic_any; fn main() { panic::set_hook(Box::new(|panic_info| { if let Some(location) = panic_info.location() { println!( ""panic occurred in file '{}' at line {}"" location.file() location.line() ); } else { println!(""panic occurred but can't get location information...""); } })); panic_any(42); } ```` Before: `panic occurred in file '/rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904/library/std/src/panic.rs' at line 59` After: `panic occurred in file 'src/main.rs' at line 17`",THUMBS_UP,2021-07-13T14:52:12Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85745,MERGED,2021-05-27T11:23:25Z,2021-05-28T08:49:47Z,Add #[track_caller] to panic_any,veber-alex,18135ec85be45df013ecd0d1eb4a49128d043e20,1,"Auto merge of #85745 - veber-alex:panic_any r=m-ou-se Add #[track_caller] to panic_any Report the panic location from the user code. ```rust use std::panic; use std::panic::panic_any; fn main() { panic::set_hook(Box::new(|panic_info| { if let Some(location) = panic_info.location() { println!( ""panic occurred in file '{}' at line {}"" location.file() location.line() ); } else { println!(""panic occurred but can't get location information...""); } })); panic_any(42); } ```` Before: `panic occurred in file '/rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904/library/std/src/panic.rs' at line 59` After: `panic occurred in file 'src/main.rs' at line 17`",THUMBS_UP,2021-08-22T07:58:40Z,bluss,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HOORAY,2021-05-27T20:48:34Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-05-27T20:48:37Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HOORAY,2021-05-28T08:06:06Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-06-24T08:45:05Z,Ltrlg,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-06-25T20:44:13Z,chrish42,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HOORAY,2021-06-25T20:44:14Z,chrish42,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-07-02T22:46:10Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-09-09T21:17:42Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HEART,2021-09-10T06:13:39Z,zohnannor,NA https://github.com/rust-lang/rust/pull/85746,MERGED,2021-05-27T12:16:38Z,2021-07-02T11:42:43Z,Redefine `ErrorKind::Other` and stop using it in std.,m-ou-se,f9fa13f705bb8b1c57c6b6fe95055ec4995a40f0,24,Auto merge of #85746 - m-ou-se:io-error-other r=joshtriplett Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only* and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change since the user couldn't match on these errors anyway. This way we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`,HOORAY,2021-09-10T06:13:50Z,zohnannor,NA https://github.com/rust-lang/rust/pull/85747,MERGED,2021-05-27T12:29:30Z,2021-06-18T20:11:55Z,Path methods — symlinks improvement ,maxwase,88ba8ad730a124f7e1d4f1bd17f2b14cb18eed3c,2,Auto merge of #85747 - maxwase:path-symlinks-methods r=m-ou-se Path methods — symlinks improvement This PR adds symlink method for the `Path`. Tracking issue: #85748 For the discussion you can see [internals topic](https://internals.rust-lang.org/t/path-methods-symlinks-improvement/14776) P.S. I'm not fully sure about `stable` attribute correct me if I'm wrong.,HOORAY,2021-05-28T10:34:43Z,mexus,NA https://github.com/rust-lang/rust/pull/85747,MERGED,2021-05-27T12:29:30Z,2021-06-18T20:11:55Z,Path methods — symlinks improvement ,maxwase,88ba8ad730a124f7e1d4f1bd17f2b14cb18eed3c,2,Auto merge of #85747 - maxwase:path-symlinks-methods r=m-ou-se Path methods — symlinks improvement This PR adds symlink method for the `Path`. Tracking issue: #85748 For the discussion you can see [internals topic](https://internals.rust-lang.org/t/path-methods-symlinks-improvement/14776) P.S. I'm not fully sure about `stable` attribute correct me if I'm wrong.,EYES,2021-06-01T21:12:12Z,ilyavenner,NA https://github.com/rust-lang/rust/pull/85747,MERGED,2021-05-27T12:29:30Z,2021-06-18T20:11:55Z,Path methods — symlinks improvement ,maxwase,88ba8ad730a124f7e1d4f1bd17f2b14cb18eed3c,2,Auto merge of #85747 - maxwase:path-symlinks-methods r=m-ou-se Path methods — symlinks improvement This PR adds symlink method for the `Path`. Tracking issue: #85748 For the discussion you can see [internals topic](https://internals.rust-lang.org/t/path-methods-symlinks-improvement/14776) P.S. I'm not fully sure about `stable` attribute correct me if I'm wrong.,EYES,2021-06-02T08:03:39Z,kpp,NA https://github.com/rust-lang/rust/pull/85749,MERGED,2021-05-27T14:18:37Z,2021-07-02T14:23:39Z,"Revert ""Don't load all extern crates unconditionally""",GuillaumeGomez,b7654a3258b73002d99c5139a5b40c49245e9695,9,"Rollup merge of #85749 - GuillaumeGomez:revert-smart-extern-crate-load r=jyn514 Revert ""Don't load all extern crates unconditionally"" Fixes https://github.com/rust-lang/rust/issues/84738. This reverts https://github.com/rust-lang/rust/pull/83738. For the ""smart"" load of external crates we need to be able to access their items in order to check their doc comments which seems if not impossible quite complicated using only the AST. For some context I first tried to extend the `IntraLinkCrateLoader` visitor by adding `visit_foreign_item`. Unfortunately it never enters into this call so definitely not the right place... I then added `visit_use_tree` to then check all the imports outside with something like this: ```rust let mut loader = crate::passes::collect_intra_doc_links::IntraLinkCrateLoader::new(resolver); ast::visit::walk_crate(&mut loader krate); let mut items = Vec::new(); for import in &loader.imports_to_check { if let Some(item) = krate.items.iter().find(|i| i.id == *import) { items.push(item); } } for item in items { ast::visit::walk_item(&mut item); for attr in &item.attrs { loader.check_attribute(attr); } } ``` This was of course a failure. We find the items without problems but we still can't go into the external crate to check its items' attributes. Finally `@jyn514` suggested to look into the [`CrateLoader`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CrateLoader.html) but it only seems to provide metadata (I went through [`CStore`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CStore.html) and [`CrateMetadata`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/struct.CrateMetadata.html)). I think we are too limited here (with AST only) to be able to determine the crates we actually need to import but it's very likely that I missed something. Maybe `@petrochenkov` or `@Aaron1011` have an idea? So until we find a way to make it work completely we need to revert it to fix the ICE. Once merged we'll need to re-open #68427. r? `@jyn514`",CONFUSED,2021-05-27T14:23:36Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/85758,MERGED,2021-05-27T18:09:22Z,2021-06-14T13:05:54Z,Revert #85176 addition of `clone_from` for `ManuallyDrop`,petertodd,7510b0ca45d1204f8f0e9dc1bb2dc7d95b279c9a,1,Auto merge of #85758 - petertodd:2021-revert-manuallydrop-clone-from r=m-ou-se Revert #85176 addition of `clone_from` for `ManuallyDrop` Forwarding `clone_from` to the inner value changes the observable behavior as previously the inner value would *not* be dropped by the default implementation. Frankly this is a super-niche case so #85176 is welcome to argue the behavior should be otherwise! But if we overrride it IMO documenting the behavior would be good. Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c5d0856686fa850c1d7ee16891014efb,THUMBS_UP,2021-06-01T07:28:37Z,a1phyr,NA https://github.com/rust-lang/rust/pull/85764,CLOSED,2021-05-27T21:57:14Z,2021-10-23T19:56:47Z,Implement coherence checks for negative trait impls,yaahc,NA,NA,NA,HOORAY,2021-05-30T08:09:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-05-28T02:17:17Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,THUMBS_UP,2021-10-14T20:29:01Z,Purpzie,NA https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-10-20T18:42:52Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,THUMBS_UP,2021-10-20T18:42:53Z,Timmmm,tdhutt@gmail.com https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,THUMBS_UP,2021-10-28T06:13:57Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-10-28T06:13:59Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,THUMBS_UP,2021-10-28T10:00:13Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-10-28T10:00:14Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,THUMBS_UP,2021-11-09T20:16:55Z,AqilCont,aqilcm@gmail.com https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-11-09T20:16:56Z,AqilCont,aqilcm@gmail.com https://github.com/rust-lang/rust/pull/85766,MERGED,2021-05-27T22:31:53Z,2021-11-16T05:19:08Z,Stabilize File::options(),workingjubilee,73ec27d359a30e39e2aad29dfaf5c09438872511,1,Rollup merge of #85766 - workingjubilee:file-options r=yaahc Stabilize File::options() Renames File::with_options to File::options per consensus in rust-lang/rust#65439 and stabilizes it.,ROCKET,2021-11-25T10:49:07Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-05-29T07:54:41Z,phansch,dev@phansch.net https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-05-29T12:04:42Z,RalfJung,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-05-29T17:00:13Z,bjorn3,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-06-03T09:11:04Z,taiki-e,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-06-18T20:30:56Z,eggyal,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-06-18T21:38:15Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-06-18T23:39:02Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-06-18T23:39:03Z,marmeladema,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-06-30T11:23:50Z,phlopsi,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-07-08T16:21:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-07-08T16:21:37Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-07-10T15:06:15Z,neoeinstein,marcus@griep.us https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-07-15T15:24:59Z,DianaNites,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-07-15T15:25:00Z,DianaNites,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-07-28T09:25:36Z,faramozzayw,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-07-29T19:45:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HEART,2021-07-29T19:45:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-08-01T08:33:31Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-09-23T10:45:12Z,Nugine,nugine@foxmail.com https://github.com/rust-lang/rust/pull/85769,MERGED,2021-05-28T00:40:20Z,2021-07-28T03:34:11Z,Stabilize `const_fn_transmute` `const_fn_union`,jhpratt,8b50cc9a2c408caef30a1cf950c948509b2f648e,47,Auto merge of #85769 - jhpratt:stabilize-const-transmute-union r=RalfJung Stabilize `const_fn_transmute` `const_fn_union` This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features. Closes #53605. Closes #51909.,HOORAY,2021-12-22T10:39:33Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/85799,CLOSED,2021-05-29T03:30:38Z,2022-05-31T16:43:41Z,Tweak spans for trait bounds on associated types,estebank,NA,NA,NA,HEART,2021-07-21T19:58:09Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/85799,CLOSED,2021-05-29T03:30:38Z,2022-05-31T16:43:41Z,Tweak spans for trait bounds on associated types,estebank,NA,NA,NA,HEART,2021-12-15T18:41:14Z,camelid,NA https://github.com/rust-lang/rust/pull/85826,MERGED,2021-05-30T05:17:49Z,2021-06-01T14:51:25Z,"Mention ""null pointer optimization"" in option docs.",jsha,f4d3f32f4529adc9709ee11fd062b49332d36096,1,"Rollup merge of #85826 - jsha:npo r=joshtriplett Mention ""null pointer optimization"" in option docs. I had seen people discuss ""null pointer optimization "" but when I tried to find official documentation (using Google) the `std::option` page didn't show up because it doesn't use that term. Hopefully adding the term will help others find it in the future.",HEART,2021-05-31T04:52:57Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/85826,MERGED,2021-05-30T05:17:49Z,2021-06-01T14:51:25Z,"Mention ""null pointer optimization"" in option docs.",jsha,f4d3f32f4529adc9709ee11fd062b49332d36096,1,"Rollup merge of #85826 - jsha:npo r=joshtriplett Mention ""null pointer optimization"" in option docs. I had seen people discuss ""null pointer optimization "" but when I tried to find official documentation (using Google) the `std::option` page didn't show up because it doesn't use that term. Hopefully adding the term will help others find it in the future.",HEART,2021-05-31T08:34:03Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/85826,MERGED,2021-05-30T05:17:49Z,2021-06-01T14:51:25Z,"Mention ""null pointer optimization"" in option docs.",jsha,f4d3f32f4529adc9709ee11fd062b49332d36096,1,"Rollup merge of #85826 - jsha:npo r=joshtriplett Mention ""null pointer optimization"" in option docs. I had seen people discuss ""null pointer optimization "" but when I tried to find official documentation (using Google) the `std::option` page didn't show up because it doesn't use that term. Hopefully adding the term will help others find it in the future.",HEART,2021-06-03T14:38:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-05-30T07:25:06Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-05-30T21:34:18Z,CryZe,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-05-31T04:52:51Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-05-31T08:27:23Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-05-31T16:03:24Z,lqd,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-06-04T17:53:25Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-06-25T09:28:38Z,bluss,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-09T12:05:01Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-09T12:05:02Z,Virgiel,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-09T12:49:16Z,niksaak,niksaak@gmail.com https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-09T15:47:07Z,Kolsky,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-09T15:47:09Z,Kolsky,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-09T20:11:35Z,cayv,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-10T14:09:08Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-15T09:36:19Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-15T18:28:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-15T18:28:03Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-15T21:02:13Z,lukechu10,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-15T21:02:13Z,lukechu10,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-15T22:01:14Z,extrawurst,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-15T22:04:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",EYES,2021-07-15T22:05:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-16T21:41:51Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-17T04:38:07Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/85828,MERGED,2021-05-30T06:45:56Z,2021-07-09T11:57:32Z,Stop generating `alloca`s & `memcmp` for simple short array equality,scottmcm,ee86f96ba176f598d64dc9f3bb7e074d5b8b86b6,15,"Auto merge of #85828 - scottmcm:raw-eq r=oli-obk Stop generating `alloca`s & `memcmp` for simple short array equality Example: ```rust pub fn demo(x: [u16; 6] y: [u16; 6]) -> bool { x == y } ``` Before: ```llvm define zeroext i1 `@_ZN10playground4demo17h48537f7eac23948fE(i96` %0 i96 %1) unnamed_addr #0 { start: %y = alloca [6 x i16] align 8 %x = alloca [6 x i16] align 8 %.0..sroa_cast = bitcast [6 x i16]* %x to i96* store i96 %0 i96* %.0..sroa_cast align 8 %.0..sroa_cast3 = bitcast [6 x i16]* %y to i96* store i96 %1 i96* %.0..sroa_cast3 align 8 %_11.i.i.i = bitcast [6 x i16]* %x to i8* %_14.i.i.i = bitcast [6 x i16]* %y to i8* %bcmp.i.i.i = call i32 `@bcmp(i8*` nonnull dereferenceable(12) %_11.i.i.i i8* nonnull dereferenceable(12) %_14.i.i.i i64 12) #2 !alias.scope !2 %2 = icmp eq i32 %bcmp.i.i.i 0 ret i1 %2 } ``` ```x86 playground::demo: # `@playground::demo` sub rsp 32 mov qword ptr [rsp] rdi mov dword ptr [rsp + 8] esi mov qword ptr [rsp + 16] rdx mov dword ptr [rsp + 24] ecx xor rdi rdx xor esi ecx or rsi rdi sete al add rsp 32 ret ``` After: ```llvm define zeroext i1 `@_ZN4mini4demo17h7a8994aaa314c981E(i96` %0 i96 %1) unnamed_addr #0 { start: %2 = icmp eq i96 %0 %1 ret i1 %2 } ``` ```x86 _ZN4mini4demo17h7a8994aaa314c981E: xor rcx r8 xor edx r9d or rdx rcx sete al ret ```",HOORAY,2021-07-17T11:55:02Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/85829,MERGED,2021-05-30T12:08:31Z,2021-06-01T22:32:02Z,Remove CrateNum::ReservedForIncrCompCache,bjorn3,625d5a693e4697bcafdd34fd1a38c281acabb8e9,7,Auto merge of #85829 - bjorn3:simplify_crate_num r=jackh726 Remove CrateNum::ReservedForIncrCompCache It's only use is easily replaceable with `Option`.,EYES,2021-05-30T12:17:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85829,MERGED,2021-05-30T12:08:31Z,2021-06-01T22:32:02Z,Remove CrateNum::ReservedForIncrCompCache,bjorn3,625d5a693e4697bcafdd34fd1a38c281acabb8e9,7,Auto merge of #85829 - bjorn3:simplify_crate_num r=jackh726 Remove CrateNum::ReservedForIncrCompCache It's only use is easily replaceable with `Option`.,THUMBS_UP,2021-05-30T12:30:46Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/85835,MERGED,2021-05-30T17:17:44Z,2021-08-12T10:13:42Z,Implement Extend<(A B)> for (Extend Extend),Seppel3210,688094b868f4ebe344c06ea2ba5b445ebef6ae67,2,"Rollup merge of #85835 - Seppel3210:master r=yaahc Implement Extend<(A B)> for (Extend Extend) I oriented myself at the implementation of `Iterator::unzip` and also rewrote the impl in terms of `(A B)::extend` after that. Since (A B) now also implements Extend we could also mention in the documentation of unzip that it can do ""nested unzipping"" (you could unzip `Iterator` into `(Vec (Vec Vec))` for example) but I'm not sure of that so I'm asking here 🙂 (P.S. I saw a couple of people asking if there is an unzip3 but there isn't. So this could be a way to get equivalent functionality)",THUMBS_UP,2021-06-01T05:36:34Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/85835,MERGED,2021-05-30T17:17:44Z,2021-08-12T10:13:42Z,Implement Extend<(A B)> for (Extend Extend),Seppel3210,688094b868f4ebe344c06ea2ba5b445ebef6ae67,2,"Rollup merge of #85835 - Seppel3210:master r=yaahc Implement Extend<(A B)> for (Extend Extend) I oriented myself at the implementation of `Iterator::unzip` and also rewrote the impl in terms of `(A B)::extend` after that. Since (A B) now also implements Extend we could also mention in the documentation of unzip that it can do ""nested unzipping"" (you could unzip `Iterator` into `(Vec (Vec Vec))` for example) but I'm not sure of that so I'm asking here 🙂 (P.S. I saw a couple of people asking if there is an unzip3 but there isn't. So this could be a way to get equivalent functionality)",THUMBS_UP,2021-07-29T03:33:34Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85835,MERGED,2021-05-30T17:17:44Z,2021-08-12T10:13:42Z,Implement Extend<(A B)> for (Extend Extend),Seppel3210,688094b868f4ebe344c06ea2ba5b445ebef6ae67,2,"Rollup merge of #85835 - Seppel3210:master r=yaahc Implement Extend<(A B)> for (Extend Extend) I oriented myself at the implementation of `Iterator::unzip` and also rewrote the impl in terms of `(A B)::extend` after that. Since (A B) now also implements Extend we could also mention in the documentation of unzip that it can do ""nested unzipping"" (you could unzip `Iterator` into `(Vec (Vec Vec))` for example) but I'm not sure of that so I'm asking here 🙂 (P.S. I saw a couple of people asking if there is an unzip3 but there isn't. So this could be a way to get equivalent functionality)",THUMBS_UP,2021-08-05T08:58:11Z,Ten0,NA https://github.com/rust-lang/rust/pull/85850,MERGED,2021-05-31T11:02:20Z,2021-06-04T07:10:56Z,Remove unused feature gates,bjorn3,36f1ed6de2266a6304dda286f955b470d3264b9c,24,Rollup merge of #85850 - bjorn3:less_feature_gates r=jyn514 Remove unused feature gates The first commit removes a usage of a feature gate but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`) The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though. The third commit removes (almost) all feature gates from the compiler that weren't used anyway.,THUMBS_UP,2021-06-01T01:13:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/85867,MERGED,2021-05-31T17:28:46Z,2021-06-04T01:26:25Z,Remove unnecessary SpecFromIter impls,steffahn,f1cee2c60e430d4f600afdc7c7aaa6eafc020c14,1,Auto merge of #85867 - steffahn:remove_unnecessary_specfromiter_impls r=Mark-Simulacrum Remove unnecessary SpecFromIter impls Unless I’m missing something these `SpecFromIter<&'a T …> for Vec` implementations were completely unused.,THUMBS_UP,2021-05-31T17:49:27Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/85868,MERGED,2021-05-31T18:23:16Z,2021-09-02T23:56:40Z,Preserve most sub-obligations in the projection cache,Aaron1011,371f3cd3fe523d0b398ed1db1620667c53ba7d02,13,Auto merge of #85868 - Aaron1011:projection-cache r=jackh726 Preserve most sub-obligations in the projection cache Fixes https://github.com/rust-lang/rust/issues/85360 When we evaluate a projection predicate we may produce sub-obligations. During trait evaluation evaluating these sub-obligations might cause us to produce `EvaluatedToOkModuloRegions`. When we cache the result of projection in our projection cache we try to throw away some of the sub-obligations so that we don't need to re-evaluate/process them the next time we need to perform this particular projection. However we may end up throwing away predicates that will (recursively) evaluate to `EvaluatedToOkModuloRegions`. If we do then the result of evaluating a predicate will depend on the state of the predicate cache - this is global untracked state which interacts badly with incremental compilation. To fix this we now only discard global predicates that evaluate to `EvaluatedToOk`. This ensures that any predicates that (may) evaluate to `EvaluatedToOkModuloRegions` are kept in the cache and influence the results of any queries which perform this projection.,HEART,2021-06-18T16:17:47Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/85868,MERGED,2021-05-31T18:23:16Z,2021-09-02T23:56:40Z,Preserve most sub-obligations in the projection cache,Aaron1011,371f3cd3fe523d0b398ed1db1620667c53ba7d02,13,Auto merge of #85868 - Aaron1011:projection-cache r=jackh726 Preserve most sub-obligations in the projection cache Fixes https://github.com/rust-lang/rust/issues/85360 When we evaluate a projection predicate we may produce sub-obligations. During trait evaluation evaluating these sub-obligations might cause us to produce `EvaluatedToOkModuloRegions`. When we cache the result of projection in our projection cache we try to throw away some of the sub-obligations so that we don't need to re-evaluate/process them the next time we need to perform this particular projection. However we may end up throwing away predicates that will (recursively) evaluate to `EvaluatedToOkModuloRegions`. If we do then the result of evaluating a predicate will depend on the state of the predicate cache - this is global untracked state which interacts badly with incremental compilation. To fix this we now only discard global predicates that evaluate to `EvaluatedToOk`. This ensures that any predicates that (may) evaluate to `EvaluatedToOkModuloRegions` are kept in the cache and influence the results of any queries which perform this projection.,THUMBS_UP,2021-06-24T08:26:41Z,MOZGIII,NA https://github.com/rust-lang/rust/pull/85868,MERGED,2021-05-31T18:23:16Z,2021-09-02T23:56:40Z,Preserve most sub-obligations in the projection cache,Aaron1011,371f3cd3fe523d0b398ed1db1620667c53ba7d02,13,Auto merge of #85868 - Aaron1011:projection-cache r=jackh726 Preserve most sub-obligations in the projection cache Fixes https://github.com/rust-lang/rust/issues/85360 When we evaluate a projection predicate we may produce sub-obligations. During trait evaluation evaluating these sub-obligations might cause us to produce `EvaluatedToOkModuloRegions`. When we cache the result of projection in our projection cache we try to throw away some of the sub-obligations so that we don't need to re-evaluate/process them the next time we need to perform this particular projection. However we may end up throwing away predicates that will (recursively) evaluate to `EvaluatedToOkModuloRegions`. If we do then the result of evaluating a predicate will depend on the state of the predicate cache - this is global untracked state which interacts badly with incremental compilation. To fix this we now only discard global predicates that evaluate to `EvaluatedToOk`. This ensures that any predicates that (may) evaluate to `EvaluatedToOkModuloRegions` are kept in the cache and influence the results of any queries which perform this projection.,HEART,2021-06-26T02:34:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/85869,MERGED,2021-05-31T18:29:56Z,2021-06-05T16:38:32Z,Remove special handling of `box_free` from `LocalAnalyzer`,tmiasko,9104c898eb323f9edd205acf87c2b2d6badeddd7,1,Auto merge of #85869 - tmiasko:box-free r=nagisa Remove special handling of `box_free` from `LocalAnalyzer` The special casing of `box_free` predates the use of dominators in analyzer. It is no longer necessary now that analyzer verifies that the first assignment dominates all uses.,THUMBS_UP,2021-05-31T18:43:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85884,MERGED,2021-06-01T07:06:07Z,2021-06-01T12:10:27Z,"Revert ""Reduce the amount of untracked state in TyCtxt""",cjgillot,1160cf864f2a0014e3442367e1b96496bfbeadf4,49,"Auto merge of #85884 - rust-lang:revert-85153-qresolve r=michaelwoerister Revert ""Reduce the amount of untracked state in TyCtxt"" Reverts rust-lang/rust#85153 Fixes https://github.com/rust-lang/rust/issues/85878 The performance hit is massive and was not visible in the in-review perf run. r? `@Aaron1011`",CONFUSED,2021-06-01T07:47:09Z,bjorn3,NA https://github.com/rust-lang/rust/pull/85884,MERGED,2021-06-01T07:06:07Z,2021-06-01T12:10:27Z,"Revert ""Reduce the amount of untracked state in TyCtxt""",cjgillot,1160cf864f2a0014e3442367e1b96496bfbeadf4,49,"Auto merge of #85884 - rust-lang:revert-85153-qresolve r=michaelwoerister Revert ""Reduce the amount of untracked state in TyCtxt"" Reverts rust-lang/rust#85153 Fixes https://github.com/rust-lang/rust/issues/85878 The performance hit is massive and was not visible in the in-review perf run. r? `@Aaron1011`",CONFUSED,2021-06-01T12:14:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85885,MERGED,2021-06-01T08:53:08Z,2021-06-11T18:40:50Z,Don't use a generator for BoxedResolver ,bjorn3,0a8629bff642c3c3b84bb644c0099194f063b627,6,Auto merge of #85885 - bjorn3:remove_box_region r=cjgillot Don't use a generator for BoxedResolver The generator is non-trivial and requires unsafe code anyway. Using regular unsafe code without a generator is much easier to follow. Based on #85810 as it touches rustc_interface too.,HOORAY,2021-06-01T10:06:50Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/85892,MERGED,2021-06-01T14:53:53Z,2021-06-02T13:11:43Z,Miscellaneous inlining improvements,tmiasko,1e13a9bb33debb931d603278b7f1a706b0d11660,17,Auto merge of #85892 - tmiasko:i r=oli-obk Miscellaneous inlining improvements,ROCKET,2021-06-08T16:04:40Z,mati865,NA https://github.com/rust-lang/rust/pull/85897,MERGED,2021-06-01T16:29:12Z,2021-06-03T10:43:38Z,Update I-unsound label for triagebot,steffahn,052a3feeeac8d8f8f0ab0288a5e2931757ce764c,1,Rollup merge of #85897 - steffahn:update_unsound_label_for_triagebot r=Mark-Simulacrum Update I-unsound label for triagebot Following the remaming of the `I-unsound` label (removing the space and the emoji) as discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/A.20way.20to.20self-label.20soundness.20issues.3F/near/240962907) (or [in the archive](https://zulip-archive.rust-lang.org/122651general/88362Awaytoselflabelsoundnessissues.html#240962907)) this change of the `triagebot.toml` is necessary to keep the automatic `I-prioritize` flagging.,THUMBS_UP,2021-06-01T16:31:03Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85918,OPEN,2021-06-01T23:20:06Z,NA,Enable `-Zincremental-verify-ich` when building compiler crates,Aaron1011,NA,NA,NA,THUMBS_UP,2021-06-02T00:12:13Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85918,OPEN,2021-06-01T23:20:06Z,NA,Enable `-Zincremental-verify-ich` when building compiler crates,Aaron1011,NA,NA,NA,THUMBS_UP,2021-06-03T20:31:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-07T14:56:44Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T02:18:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T07:09:26Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T07:30:30Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T12:13:06Z,apppppppple,NA https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T16:04:49Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-24T21:31:28Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-25T06:55:11Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/85925,MERGED,2021-06-02T03:13:01Z,2021-06-18T02:00:24Z,Linear interpolation,clarfonthey,fcac47896696899badc9a436d798d48158895ea3,5,"Rollup merge of #85925 - clarfonthey:lerp r=m-ou-se Linear interpolation #71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author. The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20. To ensure symmetry as a method this breaks the usual ordering of the method from `lerp(a b t)` to `t.lerp(a b)`. This makes the most sense to me personally and there will definitely be discussion before stabilisation anyway. Implementing lerp ""correctly"" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees which I've simplified down to: 1. Exactness: `(0.0).lerp(start end) == start` and `(1.0).lerp(start end) == end` 2. Consistency: `anything.lerp(x x) == x` 3. Monotonicity: once you go up don't go down Fun story: the version provided in that proposal from what I understand isn't actually monotonic. I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by so just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic but I'm sure that people who care deeply about this will be there to discuss before stabilisation. The main reason for using `mul_add` is that in general it ticks more boxes with fewer branches to be ""correct."" Although it will be slower on architectures without the fused `mul_add` that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.",HOORAY,2021-06-30T05:38:43Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/85930,MERGED,2021-06-02T10:25:23Z,2021-06-06T14:00:43Z,Update standard library for IntoIterator implementation of arrays ,mominul,f923f73b9aa80e94565d333f9d1ee6e3c60e83d2,11,Rollup merge of #85930 - mominul:array_into_iter r=m-ou-se Update standard library for IntoIterator implementation of arrays This PR partially resolves issue #84513 of updating the standard library part. I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any? Thanks! r? ```@m-ou-se```,HEART,2021-06-12T07:17:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85930,MERGED,2021-06-02T10:25:23Z,2021-06-06T14:00:43Z,Update standard library for IntoIterator implementation of arrays ,mominul,f923f73b9aa80e94565d333f9d1ee6e3c60e83d2,11,Rollup merge of #85930 - mominul:array_into_iter r=m-ou-se Update standard library for IntoIterator implementation of arrays This PR partially resolves issue #84513 of updating the standard library part. I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any? Thanks! r? ```@m-ou-se```,HEART,2021-06-14T17:30:54Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/85937,MERGED,2021-06-02T16:17:02Z,2021-06-04T07:10:56Z,Fix bad suggestions for code from proc_macro,m-ou-se,99fc56b9dedc18e13942e06c1b964cf93cf5a6e7,4,Rollup merge of #85937 - m-ou-se:macro-ref-suggestions r=estebank Fix bad suggestions for code from proc_macro Fixes #85932 This disables these suggestions for spans from external macros while keeping them for macros defined locally: Before: ``` 3 | #[hello] | ^^^^^^^^ | | | expected `&mut i32` found integer | help: consider mutably borrowing here: `&mut #[hello]` ``` After: ``` 3 | #[hello] | ^^^^^^^^ expected `&mut i32` found integer ``` Unchanged: ``` 26 | macro_rules! bla { () => { x(123); } } | ^^^ | | | expected `&mut i32` found integer | help: consider mutably borrowing here: `&mut 123` ... 29 | bla!(); | ------- in this macro invocation ```,HOORAY,2021-06-02T16:22:56Z,bnjbvr,NA https://github.com/rust-lang/rust/pull/85937,MERGED,2021-06-02T16:17:02Z,2021-06-04T07:10:56Z,Fix bad suggestions for code from proc_macro,m-ou-se,99fc56b9dedc18e13942e06c1b964cf93cf5a6e7,4,Rollup merge of #85937 - m-ou-se:macro-ref-suggestions r=estebank Fix bad suggestions for code from proc_macro Fixes #85932 This disables these suggestions for spans from external macros while keeping them for macros defined locally: Before: ``` 3 | #[hello] | ^^^^^^^^ | | | expected `&mut i32` found integer | help: consider mutably borrowing here: `&mut #[hello]` ``` After: ``` 3 | #[hello] | ^^^^^^^^ expected `&mut i32` found integer ``` Unchanged: ``` 26 | macro_rules! bla { () => { x(123); } } | ^^^ | | | expected `&mut i32` found integer | help: consider mutably borrowing here: `&mut 123` ... 29 | bla!(); | ------- in this macro invocation ```,HOORAY,2021-06-02T19:11:25Z,taiki-e,NA https://github.com/rust-lang/rust/pull/85947,CLOSED,2021-06-02T23:52:34Z,2021-07-20T19:49:53Z,Explain origin of implicit `Sized` obligations and provide suggestions when possible,estebank,NA,NA,NA,THUMBS_UP,2021-06-03T12:25:37Z,fmease,NA https://github.com/rust-lang/rust/pull/85947,CLOSED,2021-06-02T23:52:34Z,2021-07-20T19:49:53Z,Explain origin of implicit `Sized` obligations and provide suggestions when possible,estebank,NA,NA,NA,THUMBS_UP,2021-06-03T14:33:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85953,MERGED,2021-06-03T06:45:04Z,2021-07-11T00:23:28Z,Fix linker error,inquisitivecrystal,dfd7b8d03fb93d0e03147d28b3be6d93260fa94d,10,Auto merge of #85953 - inquisitivecrystal:weak-linkat-in-fs-hardlink r=joshtriplett Fix linker error Currently `fs::hard_link` determines whether platforms have `linkat` based on the OS and uses `link` if they don't. However this heuristic does not work well if a platform provides `linkat` on newer versions but not on older ones. On old MacOS this currently causes a linking error. This commit fixes `fs::hard_link` by telling it to use `weak!` on macOS. This means that on that operating system we now check for `linkat` at runtime and use `link` if it is not available. Fixes #80804. `@rustbot` label T-libs-impl,THUMBS_UP,2021-06-03T10:19:36Z,aeiouaeiouaeiouaeiouaeiouaeiou,NA https://github.com/rust-lang/rust/pull/85958,MERGED,2021-06-03T09:05:33Z,2021-06-03T13:10:10Z,Update Miri,NA,NA,NA,NA,HEART,2021-06-03T09:06:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/85961,MERGED,2021-06-03T10:31:58Z,2021-06-11T05:02:43Z,MVP for using rust-lld as part of cc,1000teslas,72868e017bdade60603a25889e253f556305f996,8,Auto merge of #85961 - 1000teslas:issue-71519-fix r=petrochenkov MVP for using rust-lld as part of cc Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl -v` (thanks to bjorn3 on Zulip) I can see that lld is used but I'm not sure how to inspect that output in a test.,HOORAY,2021-06-05T17:57:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85961,MERGED,2021-06-03T10:31:58Z,2021-06-11T05:02:43Z,MVP for using rust-lld as part of cc,1000teslas,72868e017bdade60603a25889e253f556305f996,8,Auto merge of #85961 - 1000teslas:issue-71519-fix r=petrochenkov MVP for using rust-lld as part of cc Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl -v` (thanks to bjorn3 on Zulip) I can see that lld is used but I'm not sure how to inspect that output in a test.,HOORAY,2021-06-11T05:25:56Z,hkratz,NA https://github.com/rust-lang/rust/pull/85961,MERGED,2021-06-03T10:31:58Z,2021-06-11T05:02:43Z,MVP for using rust-lld as part of cc,1000teslas,72868e017bdade60603a25889e253f556305f996,8,Auto merge of #85961 - 1000teslas:issue-71519-fix r=petrochenkov MVP for using rust-lld as part of cc Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl -v` (thanks to bjorn3 on Zulip) I can see that lld is used but I'm not sure how to inspect that output in a test.,HOORAY,2021-06-11T06:29:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85961,MERGED,2021-06-03T10:31:58Z,2021-06-11T05:02:43Z,MVP for using rust-lld as part of cc,1000teslas,72868e017bdade60603a25889e253f556305f996,8,Auto merge of #85961 - 1000teslas:issue-71519-fix r=petrochenkov MVP for using rust-lld as part of cc Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl -v` (thanks to bjorn3 on Zulip) I can see that lld is used but I'm not sure how to inspect that output in a test.,HOORAY,2021-07-01T13:20:56Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/85961,MERGED,2021-06-03T10:31:58Z,2021-06-11T05:02:43Z,MVP for using rust-lld as part of cc,1000teslas,72868e017bdade60603a25889e253f556305f996,8,Auto merge of #85961 - 1000teslas:issue-71519-fix r=petrochenkov MVP for using rust-lld as part of cc Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl -v` (thanks to bjorn3 on Zulip) I can see that lld is used but I'm not sure how to inspect that output in a test.,HOORAY,2022-04-15T11:10:15Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/85979,MERGED,2021-06-03T22:24:47Z,2021-06-05T00:59:05Z,don't suggest unsized indirection in where-clauses,tlyu,2da42950284116d2b143feaf66b961f924a8a051,3,Rollup merge of #85979 - tlyu:where-no-unsized-indirection r=estebank don't suggest unsized indirection in where-clauses Skip where-clauses when suggesting using indirection in combination with `?Sized` bounds on type parameters. Fixes #85943. `@estebank` I think this doesn't conflict with your work in #85947; please let me know if you'd like me to cherry pick it to a new branch based on yours instead.,HEART,2021-06-04T02:07:55Z,estebank,NA https://github.com/rust-lang/rust/pull/85988,MERGED,2021-06-04T12:32:47Z,2021-06-05T00:59:05Z,Note that `ninja = false` goes under `[llvm]`,jyn514,062e789a73e729ae6a05f724b0b06c357aaa2ebd,1,Rollup merge of #85988 - jyn514:ninja-error r=joshtriplett Note that `ninja = false` goes under `[llvm]` Addresses https://github.com/rust-lang/rust/issues/84938#issuecomment-852448332 - `@kornelski` does this look good? r? `@Mark-Simulacrum` cc `@joshtriplett`,HEART,2021-06-04T15:59:35Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-04T19:22:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-04T19:39:05Z,panaman67,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-04T20:09:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-04T20:59:28Z,mati865,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-05T12:15:39Z,taiki-e,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-06-06T06:34:39Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-07-17T15:04:10Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-07-18T23:21:36Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-08-04T23:56:29Z,est31,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-09-20T14:52:00Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2021-11-30T09:59:31Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-03-08T15:23:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-05-12T03:25:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-06-02T21:34:33Z,cjgillot,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-06-03T20:12:51Z,adsick,adsick@protonmail.com https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-06-03T21:01:20Z,Agrailag,NA https://github.com/rust-lang/rust/pull/85993,MERGED,2021-06-04T16:39:48Z,2022-06-03T20:17:55Z,Remove all json handling from rustc_serialize,bjorn3,7e9b92cb43a489b34e2bcb8d21f36198e02eedbc,48,Auto merge of #85993 - bjorn3:serde_json r=wesleywiser Remove all json handling from rustc_serialize Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation). This allowed for removing and simplifying a lot of code which hopefully results in faster serialization/deserialization and faster compiles of rustc itself. Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format. Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`. Fixes #40177 See also https://github.com/rust-lang/compiler-team/issues/418,HEART,2022-06-04T04:28:41Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/86003,MERGED,2021-06-04T20:14:55Z,2021-06-09T19:28:15Z,Make copy/copy_nonoverlapping fn's again,pnkfelix,eab201df7028ebb6812c0b1a01702ac6ecfcceed,15,Auto merge of #86003 - pnkfelix:issue-84297-revert-81238 r=Mark-Simulacrum Make copy/copy_nonoverlapping fn's again Make copy/copy_nonoverlapping fn's again rather than intrinsics. This a short-term change to address issue #84297. It effectively reverts PRs #81167 #81238 (and part of #82967) #83091 and parts of #79684.,EYES,2021-06-04T20:19:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86003,MERGED,2021-06-04T20:14:55Z,2021-06-09T19:28:15Z,Make copy/copy_nonoverlapping fn's again,pnkfelix,eab201df7028ebb6812c0b1a01702ac6ecfcceed,15,Auto merge of #86003 - pnkfelix:issue-84297-revert-81238 r=Mark-Simulacrum Make copy/copy_nonoverlapping fn's again Make copy/copy_nonoverlapping fn's again rather than intrinsics. This a short-term change to address issue #84297. It effectively reverts PRs #81167 #81238 (and part of #82967) #83091 and parts of #79684.,CONFUSED,2021-06-10T06:13:36Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/86014,MERGED,2021-06-05T00:38:56Z,2021-06-05T21:10:01Z,msp430 linker does not accept -znoexecstack. Set linker_is_gnu to fal…,cr1901,16504f6253e6a49b3896449a5e2e0f48cb1ab3a2,1,Rollup merge of #86014 - cr1901:msp430-link r=jonas-schievink msp430 linker does not accept -znoexecstack. Set linker_is_gnu to fal… …se as workaround for now. Tested locally and works. Closes #85948.,THUMBS_UP,2021-06-05T01:32:23Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/86024,CLOSED,2021-06-05T14:35:40Z,2021-08-07T00:16:02Z,Adding the `expect` attribute (RFC 2383),xFrednet,NA,NA,NA,EYES,2021-07-31T13:46:20Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,LAUGH,2021-06-05T23:04:08Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,LAUGH,2021-06-06T02:29:55Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T04:48:14Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T06:32:01Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,LAUGH,2021-06-06T07:56:27Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T08:43:47Z,meritozh,NA https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T09:19:39Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,LAUGH,2021-06-06T10:54:55Z,rijenkii,NA https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T12:49:09Z,QuarticCat,QuarticCat@protonmail.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-06T14:11:14Z,johnthagen,NA https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,LAUGH,2021-06-06T20:15:42Z,safinsingh,NA https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,CONFUSED,2021-06-14T15:33:37Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,THUMBS_UP,2021-06-14T16:57:16Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/86036,MERGED,2021-06-05T20:21:37Z,2021-06-09T03:15:34Z,[beta] Disable mutable noalias for Rust 1.53,nikic,92752e942235bd886b2670428055c2587be5b09c,2,Auto merge of #86036 - nikic:disable-mutable-noalias r=Mark-Simulacrum [beta] Disable mutable noalias for Rust 1.53 Disable mutable noalias for the upcoming release to give this change more time to bake. I believe that was the consensus and I wanted to make sure we don't forget :) r? `@Mark-Simulacrum`,THUMBS_UP,2021-07-30T17:40:24Z,denisandroid,denis2005991@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-06-07T04:12:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-06-07T08:26:40Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-06-07T22:44:45Z,scottmcm,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-06-13T05:11:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-06-14T09:58:23Z,scalexm,alexandre@scalexm.fr https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-07-07T13:10:14Z,a1phyr,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-07-18T06:20:16Z,crlf0710,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-07-18T06:20:18Z,crlf0710,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-08-17T20:26:23Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-08-18T14:48:39Z,est31,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-09-02T14:20:10Z,estebank,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-10-23T17:05:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-10-23T17:05:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-05T18:53:29Z,Milo123459,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-11-05T18:53:30Z,Milo123459,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-10T12:13:47Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-11-18T03:43:02Z,Josh015,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-18T03:43:03Z,Josh015,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-18T04:03:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HEART,2021-11-18T04:03:57Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-19T01:45:56Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/86041,MERGED,2021-06-05T21:24:17Z,2021-11-09T20:10:02Z,Replace Copy/Clone compiler magic on arrays with library impls,bstrie,d6082292a6f3207cbdacd6633a5b9d1476bb6772,12,Auto merge of #86041 - bstrie:unmagic-array-copy r=jackh726 Replace Copy/Clone compiler magic on arrays with library impls With const generics the compiler no longer needs to fake these impls.,HOORAY,2021-11-19T10:43:04Z,kpp,NA https://github.com/rust-lang/rust/pull/86048,MERGED,2021-06-06T01:37:06Z,2021-07-04T16:59:54Z,core: add unstable no_fp_fmt_parse to disable float formatting code,nbdd0121,90442458ac46b1d5eed752c316da25450f67285b,10,Auto merge of #86048 - nbdd0121:no_floating_point r=Amanieu core: add unstable no_fp_fmt_parse to disable float formatting code In some projects (e.g. kernel) floating point is forbidden. They can disable hardware floating point support and use `+soft-float` to avoid fp instructions from being generated but as libcore contains the formatting code for `f32` and `f64` some fp intrinsics are depended. One could define stubs for these intrinsics that just panic [1] but it means that if any formatting functions are accidentally used mistake can only be caught during the runtime rather than during compile-time or link-time and they consume a lot of space without LTO. This patch provides an unstable cfg `no_fp_fmt_parse` to disable these. A panicking stub is still provided for the `Debug` implementation (unfortunately) because there are some SIMD types that use `#[derive(Debug)]`. [1]: https://lkml.org/lkml/2021/4/14/1028,HEART,2021-07-04T09:00:19Z,ojeda,NA https://github.com/rust-lang/rust/pull/86048,MERGED,2021-06-06T01:37:06Z,2021-07-04T16:59:54Z,core: add unstable no_fp_fmt_parse to disable float formatting code,nbdd0121,90442458ac46b1d5eed752c316da25450f67285b,10,Auto merge of #86048 - nbdd0121:no_floating_point r=Amanieu core: add unstable no_fp_fmt_parse to disable float formatting code In some projects (e.g. kernel) floating point is forbidden. They can disable hardware floating point support and use `+soft-float` to avoid fp instructions from being generated but as libcore contains the formatting code for `f32` and `f64` some fp intrinsics are depended. One could define stubs for these intrinsics that just panic [1] but it means that if any formatting functions are accidentally used mistake can only be caught during the runtime rather than during compile-time or link-time and they consume a lot of space without LTO. This patch provides an unstable cfg `no_fp_fmt_parse` to disable these. A panicking stub is still provided for the `Debug` implementation (unfortunately) because there are some SIMD types that use `#[derive(Debug)]`. [1]: https://lkml.org/lkml/2021/4/14/1028,HEART,2021-07-05T03:02:07Z,d0u9,d0u9.su@outlook.com https://github.com/rust-lang/rust/pull/86048,MERGED,2021-06-06T01:37:06Z,2021-07-04T16:59:54Z,core: add unstable no_fp_fmt_parse to disable float formatting code,nbdd0121,90442458ac46b1d5eed752c316da25450f67285b,10,Auto merge of #86048 - nbdd0121:no_floating_point r=Amanieu core: add unstable no_fp_fmt_parse to disable float formatting code In some projects (e.g. kernel) floating point is forbidden. They can disable hardware floating point support and use `+soft-float` to avoid fp instructions from being generated but as libcore contains the formatting code for `f32` and `f64` some fp intrinsics are depended. One could define stubs for these intrinsics that just panic [1] but it means that if any formatting functions are accidentally used mistake can only be caught during the runtime rather than during compile-time or link-time and they consume a lot of space without LTO. This patch provides an unstable cfg `no_fp_fmt_parse` to disable these. A panicking stub is still provided for the `Debug` implementation (unfortunately) because there are some SIMD types that use `#[derive(Debug)]`. [1]: https://lkml.org/lkml/2021/4/14/1028,HEART,2022-01-04T13:19:25Z,timleg002,NA https://github.com/rust-lang/rust/pull/86048,MERGED,2021-06-06T01:37:06Z,2021-07-04T16:59:54Z,core: add unstable no_fp_fmt_parse to disable float formatting code,nbdd0121,90442458ac46b1d5eed752c316da25450f67285b,10,Auto merge of #86048 - nbdd0121:no_floating_point r=Amanieu core: add unstable no_fp_fmt_parse to disable float formatting code In some projects (e.g. kernel) floating point is forbidden. They can disable hardware floating point support and use `+soft-float` to avoid fp instructions from being generated but as libcore contains the formatting code for `f32` and `f64` some fp intrinsics are depended. One could define stubs for these intrinsics that just panic [1] but it means that if any formatting functions are accidentally used mistake can only be caught during the runtime rather than during compile-time or link-time and they consume a lot of space without LTO. This patch provides an unstable cfg `no_fp_fmt_parse` to disable these. A panicking stub is still provided for the `Debug` implementation (unfortunately) because there are some SIMD types that use `#[derive(Debug)]`. [1]: https://lkml.org/lkml/2021/4/14/1028,THUMBS_UP,2022-06-23T09:08:30Z,bb010g,NA https://github.com/rust-lang/rust/pull/86052,CLOSED,2021-06-06T06:54:40Z,2021-06-09T22:08:46Z,Try evaluating constants eagerly,tmiasko,NA,NA,NA,HOORAY,2021-06-06T08:30:12Z,mati865,NA https://github.com/rust-lang/rust/pull/86052,CLOSED,2021-06-06T06:54:40Z,2021-06-09T22:08:46Z,Try evaluating constants eagerly,tmiasko,NA,NA,NA,HOORAY,2021-06-06T11:13:23Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/86056,OPEN,2021-06-06T11:57:21Z,NA,Remove some eval_always,cjgillot,NA,NA,NA,EYES,2021-06-06T13:13:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86056,OPEN,2021-06-06T11:57:21Z,NA,Remove some eval_always,cjgillot,NA,NA,NA,EYES,2021-06-07T14:16:51Z,mati865,NA https://github.com/rust-lang/rust/pull/86101,MERGED,2021-06-07T15:02:32Z,2021-06-08T09:45:24Z,Correct type signature in doc for Bound::as_mut,glittershark,a416e05d277c18d60f19ae2d149504fd7f9a5ba8,1,Rollup merge of #86101 - glittershark:bound-as-mut-doc-fix r=m-ou-se Correct type signature in doc for Bound::as_mut Thanks to ``@drmason13`` for pointing this out!,HEART,2021-06-14T08:34:22Z,drmason13,NA https://github.com/rust-lang/rust/pull/86107,MERGED,2021-06-07T16:44:38Z,2021-06-09T09:00:16Z,Peephole optimize `x == false` and `x != true`,Smittyvb,d45d205d59bd9eaca352e3a8f18c625f47f5838b,6,Auto merge of #86107 - Smittyvb:peephole-optim-eq-bool r=wesleywiser Peephole optimize `x == false` and `x != true` This adds peephole optimizations to make `x == false` `false == x` `x != true` and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.,HOORAY,2021-06-09T16:28:22Z,bluss,NA https://github.com/rust-lang/rust/pull/86107,MERGED,2021-06-07T16:44:38Z,2021-06-09T09:00:16Z,Peephole optimize `x == false` and `x != true`,Smittyvb,d45d205d59bd9eaca352e3a8f18c625f47f5838b,6,Auto merge of #86107 - Smittyvb:peephole-optim-eq-bool r=wesleywiser Peephole optimize `x == false` and `x != true` This adds peephole optimizations to make `x == false` `false == x` `x != true` and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.,HOORAY,2021-06-13T05:18:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86107,MERGED,2021-06-07T16:44:38Z,2021-06-09T09:00:16Z,Peephole optimize `x == false` and `x != true`,Smittyvb,d45d205d59bd9eaca352e3a8f18c625f47f5838b,6,Auto merge of #86107 - Smittyvb:peephole-optim-eq-bool r=wesleywiser Peephole optimize `x == false` and `x != true` This adds peephole optimizations to make `x == false` `false == x` `x != true` and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.,HOORAY,2021-07-06T07:48:46Z,rrbutani,NA https://github.com/rust-lang/rust/pull/86113,MERGED,2021-06-07T19:23:20Z,2021-06-10T05:52:41Z,build doctests with lld if use-lld = true,the8472,f7aea23bd2df97fdc4a4d31a32cacef4408e03c0,4,Rollup merge of #86113 - the8472:doctest-lld r=Mark-Simulacrum build doctests with lld if use-lld = true results when running `./x.py test library/core --doc --stage 0`: ``` # OLD test result: FAILED. 2844 passed; 6 failed; 28 ignored; 0 measured; 0 filtered out; finished in 21.13s # NEW test result: FAILED. 2844 passed; 6 failed; 28 ignored; 0 measured; 0 filtered out; finished in 11.92s ```,HOORAY,2021-06-07T19:55:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86113,MERGED,2021-06-07T19:23:20Z,2021-06-10T05:52:41Z,build doctests with lld if use-lld = true,the8472,f7aea23bd2df97fdc4a4d31a32cacef4408e03c0,4,Rollup merge of #86113 - the8472:doctest-lld r=Mark-Simulacrum build doctests with lld if use-lld = true results when running `./x.py test library/core --doc --stage 0`: ``` # OLD test result: FAILED. 2844 passed; 6 failed; 28 ignored; 0 measured; 0 filtered out; finished in 21.13s # NEW test result: FAILED. 2844 passed; 6 failed; 28 ignored; 0 measured; 0 filtered out; finished in 11.92s ```,HOORAY,2021-06-08T12:07:55Z,mati865,NA https://github.com/rust-lang/rust/pull/86118,MERGED,2021-06-07T22:21:51Z,2021-06-09T11:24:58Z,Create different inference variables for different defining uses of TAITs,spastorino,c4b540698165f2172dac8562bde84116f65d13bb,21,Auto merge of #86118 - spastorino:tait-soundness-bug r=nikomatsakis Create different inference variables for different defining uses of TAITs Fixes #73481 r? `@nikomatsakis` cc `@oli-obk`,HEART,2021-06-09T13:28:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86123,MERGED,2021-06-08T00:43:18Z,2021-08-19T23:12:36Z,Preserve more spans in internal `rustc_queries!` macro,Aaron1011,def6393a8b707002aa94ee013cee8d0df1a5f38d,1,"Rollup merge of #86123 - Aaron1011:query-span r=cjgillot Preserve more spans in internal `rustc_queries!` macro We now preserve the span of the various query modifiers and use the span of the query's name for the commas that we generate to separate the modifiers. This makes debugging issues with the internal query macro infrastructure much nicer - previously we would get errors messages pointing at the entire call site (the `rustc_queries!` invocation) which isn't very useful. This should have no effect when compilation succeeds. A concrete example of an error message produced after this changed: ``` error: local ambiguity: multiple parsing options: built-in NTs tt ('modifiers') or 1 other option. --> /home/aaron/repos/rust/compiler/rustc_middle/src/query/mod.rs:23:11 | 12 | / rustc_queries! { 13 | | query trigger_delay_span_bug(key: DefId) -> () { 14 | | desc { ""trigger a delay span bug"" } 15 | | } ... | 23 | | query hir_crate(key: ()) -> &'tcx Crate<'tcx> { | | ^^^^^^^^^ ... | 1715 | | } 1716 | | } | |_- in this expansion of `rustc_query_append!` | ::: compiler/rustc_query_impl/src/lib.rs:51:1 | 51 | rustc_query_append! { [define_queries!][<'tcx>] } | ------------------------------------------------- in this macro invocation ``` The particular bug shown in this error message will be fixed in a separate PR.",HEART,2021-06-08T12:16:03Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86123,MERGED,2021-06-08T00:43:18Z,2021-08-19T23:12:36Z,Preserve more spans in internal `rustc_queries!` macro,Aaron1011,def6393a8b707002aa94ee013cee8d0df1a5f38d,1,"Rollup merge of #86123 - Aaron1011:query-span r=cjgillot Preserve more spans in internal `rustc_queries!` macro We now preserve the span of the various query modifiers and use the span of the query's name for the commas that we generate to separate the modifiers. This makes debugging issues with the internal query macro infrastructure much nicer - previously we would get errors messages pointing at the entire call site (the `rustc_queries!` invocation) which isn't very useful. This should have no effect when compilation succeeds. A concrete example of an error message produced after this changed: ``` error: local ambiguity: multiple parsing options: built-in NTs tt ('modifiers') or 1 other option. --> /home/aaron/repos/rust/compiler/rustc_middle/src/query/mod.rs:23:11 | 12 | / rustc_queries! { 13 | | query trigger_delay_span_bug(key: DefId) -> () { 14 | | desc { ""trigger a delay span bug"" } 15 | | } ... | 23 | | query hir_crate(key: ()) -> &'tcx Crate<'tcx> { | | ^^^^^^^^^ ... | 1715 | | } 1716 | | } | |_- in this expansion of `rustc_query_append!` | ::: compiler/rustc_query_impl/src/lib.rs:51:1 | 51 | rustc_query_append! { [define_queries!][<'tcx>] } | ------------------------------------------------- in this macro invocation ``` The particular bug shown in this error message will be fixed in a separate PR.",HEART,2021-06-08T14:04:36Z,taiki-e,NA https://github.com/rust-lang/rust/pull/86123,MERGED,2021-06-08T00:43:18Z,2021-08-19T23:12:36Z,Preserve more spans in internal `rustc_queries!` macro,Aaron1011,def6393a8b707002aa94ee013cee8d0df1a5f38d,1,"Rollup merge of #86123 - Aaron1011:query-span r=cjgillot Preserve more spans in internal `rustc_queries!` macro We now preserve the span of the various query modifiers and use the span of the query's name for the commas that we generate to separate the modifiers. This makes debugging issues with the internal query macro infrastructure much nicer - previously we would get errors messages pointing at the entire call site (the `rustc_queries!` invocation) which isn't very useful. This should have no effect when compilation succeeds. A concrete example of an error message produced after this changed: ``` error: local ambiguity: multiple parsing options: built-in NTs tt ('modifiers') or 1 other option. --> /home/aaron/repos/rust/compiler/rustc_middle/src/query/mod.rs:23:11 | 12 | / rustc_queries! { 13 | | query trigger_delay_span_bug(key: DefId) -> () { 14 | | desc { ""trigger a delay span bug"" } 15 | | } ... | 23 | | query hir_crate(key: ()) -> &'tcx Crate<'tcx> { | | ^^^^^^^^^ ... | 1715 | | } 1716 | | } | |_- in this expansion of `rustc_query_append!` | ::: compiler/rustc_query_impl/src/lib.rs:51:1 | 51 | rustc_query_append! { [define_queries!][<'tcx>] } | ------------------------------------------------- in this macro invocation ``` The particular bug shown in this error message will be fixed in a separate PR.",HEART,2021-08-15T22:30:42Z,camelid,NA https://github.com/rust-lang/rust/pull/86130,MERGED,2021-06-08T07:18:56Z,2021-06-12T11:12:24Z,const_eval_checked: Support as casts in abstract consts,BoxyUwU,d59b80d588368cdcfcc1d54e119374a3d78169ff,10,Auto merge of #86130 - BoxyUwU:abstract_const_as_cast r=oli-obk const_eval_checked: Support as casts in abstract consts,ROCKET,2021-06-10T15:48:12Z,lqd,NA https://github.com/rust-lang/rust/pull/86130,MERGED,2021-06-08T07:18:56Z,2021-06-12T11:12:24Z,const_eval_checked: Support as casts in abstract consts,BoxyUwU,d59b80d588368cdcfcc1d54e119374a3d78169ff,10,Auto merge of #86130 - BoxyUwU:abstract_const_as_cast r=oli-obk const_eval_checked: Support as casts in abstract consts,ROCKET,2021-06-12T19:41:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86131,CLOSED,2021-06-08T07:29:48Z,2021-06-08T15:08:48Z,Stop hashing a `usize` when hashing `[u8; 1]`,scottmcm,NA,NA,NA,HEART,2021-06-08T07:37:10Z,mockersf,mockersf@gmail.com https://github.com/rust-lang/rust/pull/86131,CLOSED,2021-06-08T07:29:48Z,2021-06-08T15:08:48Z,Stop hashing a `usize` when hashing `[u8; 1]`,scottmcm,NA,NA,NA,EYES,2021-06-08T08:28:28Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-08T14:52:20Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-08T15:07:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-08T15:13:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-09T01:36:47Z,taiki-e,NA https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-13T04:05:01Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-17T03:39:10Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86136,MERGED,2021-06-08T14:51:28Z,2021-06-19T04:21:03Z,Stabilize span_open() and span_close().,m-ou-se,aa22799b365ca9b39267eab60a72914170ced369,1,Rollup merge of #86136 - m-ou-se:proc-macro-open-close-span r=m-ou-se Stabilize span_open() and span_close(). This proposes to stabilize `Group::span_open()` and `Group::span_close()`. These are part of the `proc_macro_span` feature gate tracked in https://github.com/rust-lang/rust/issues/54725 Most of the features gated behind `proc_macro_span` are about source location information (file path line and column information) expansion information (parent()) source_text() etc. Those are not ready for stabilizaiton. However getting the span of the `(` and `)` separately instead of only of the entire `(...)` can be very useful in proc macros and doesn't seem blocked on anything that all the other parts of `proc_macro_span` are blocked on. So this renames the feature gate for those two functions to `proc_macro_group_span` and stabilizes them.,THUMBS_UP,2021-06-24T02:16:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86151,MERGED,2021-06-08T21:00:42Z,2021-06-25T09:28:28Z,Add `BuildHasher::hash_one` as unstable,scottmcm,50e0cc59ffcacda5b48f4edb95e5a5c353624fb0,3,"Auto merge of #86151 - scottmcm:simple-hash-of r=joshtriplett Add `BuildHasher::hash_one` as unstable Inspired by https://github.com/rust-lang/rust/pull/86140/files#diff-246941135168fbc44fce120385ee9c3156e08a1c3e2697985b56dcb8d728eedeR2416 where I wanted to write a quick test for a `Hash` implementation and it took more of a dance than I'd hoped. It looks like this would be handy in hashtable implementations too -- a quick look at hashbrown found two places where it needs to do the same dance: https://github.com/rust-lang/hashbrown/blob/6302512a8a514fe5bd442464ebcd78139c82e1e2/src/map.rs#L247-L270 I wanted to get a ""seems plausible"" from a libs member before making a tracking issue so random-sampling the intersection of highfive and governance gave me... r? `@joshtriplett` (As always bikeshed away! And let me know if I missed something obvious again that I should have used instead.)",THUMBS_UP,2021-06-24T11:04:38Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/86153,MERGED,2021-06-08T22:34:53Z,2021-06-12T03:46:37Z,Print dummy spans as `no-location`,tmiasko,79c0559ce154fc18b0d0a4601671484160690dd3,5,Rollup merge of #86153 - tmiasko:dummy-span r=estebank Print dummy spans as `no-location` Fixes #58808.,THUMBS_UP,2021-06-09T22:56:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86153,MERGED,2021-06-08T22:34:53Z,2021-06-12T03:46:37Z,Print dummy spans as `no-location`,tmiasko,79c0559ce154fc18b0d0a4601671484160690dd3,5,Rollup merge of #86153 - tmiasko:dummy-span r=estebank Print dummy spans as `no-location` Fixes #58808.,THUMBS_UP,2021-06-10T11:03:50Z,bjorn3,NA https://github.com/rust-lang/rust/pull/86154,CLOSED,2021-06-08T22:35:59Z,2021-06-25T23:50:19Z,Make [-] invisible in most cases,jsha,NA,NA,NA,CONFUSED,2021-06-09T06:11:28Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86154,CLOSED,2021-06-08T22:35:59Z,2021-06-25T23:50:19Z,Make [-] invisible in most cases,jsha,NA,NA,NA,CONFUSED,2021-06-09T06:33:18Z,CryZe,NA https://github.com/rust-lang/rust/pull/86154,CLOSED,2021-06-08T22:35:59Z,2021-06-25T23:50:19Z,Make [-] invisible in most cases,jsha,NA,NA,NA,THUMBS_DOWN,2021-06-09T07:27:51Z,the8472,NA https://github.com/rust-lang/rust/pull/86155,MERGED,2021-06-08T23:13:36Z,2021-08-04T23:52:55Z,rustc: Fill out remaining parts of C-unwind ABI,alexcrichton,25b764849625cb090e8b81d12d2bb2295d073788,53,"Auto merge of #86155 - alexcrichton:abort-on-unwind r=nikomatsakis rustc: Fill out remaining parts of C-unwind ABI This commit intends to fill out some of the remaining pieces of the C-unwind ABI. This has a number of other changes with it though to move this design space forward a bit. Notably contained within here is: * On `panic=unwind` the `extern ""C""` ABI is now considered as ""may unwind"". This fixes a longstanding soundness issue where if you `panic!()` in an `extern ""C""` function defined in Rust that's actually UB because the LLVM representation for the function has the `nounwind` attribute but then you unwind. * Whether or not a function unwinds now mainly considers the ABI of the function instead of first checking the panic strategy. This fixes a miscompile of `extern ""C-unwind""` with `panic=abort` because that ABI can still unwind. * The aborting stub for non-unwinding ABIs with `panic=unwind` has been reimplemented. Previously this was done as a small tweak during MIR generation but this has been moved to a separate and dedicated MIR pass. This new pass will for appropriate functions and function calls insert a `cleanup` landing pad for any function call that may unwind within a function that is itself not allowed to unwind. Note that this subtly changes some behavior from before where previously on an unwind which was caught-to-abort it would run active destructors in the function and now it simply immediately aborts the process. * The `#[unwind]` attribute has been removed and all users in tests and such are now using `C-unwind` and `#![feature(c_unwind)]`. I think this is largely the last piece of the RFC to implement. Unfortunately I believe this is still not stabilizable as-is because activating the feature gate changes the behavior of the existing `extern ""C""` ABI in a way that has no replacement. My thinking for how to enable this is that we add support for the `C-unwind` ABI on stable Rust first and then after it hits stable we change the behavior of the `C` ABI. That way anyone straddling stable/beta/nightly can switch to `C-unwind` safely.",ROCKET,2021-06-13T21:08:42Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/86155,MERGED,2021-06-08T23:13:36Z,2021-08-04T23:52:55Z,rustc: Fill out remaining parts of C-unwind ABI,alexcrichton,25b764849625cb090e8b81d12d2bb2295d073788,53,"Auto merge of #86155 - alexcrichton:abort-on-unwind r=nikomatsakis rustc: Fill out remaining parts of C-unwind ABI This commit intends to fill out some of the remaining pieces of the C-unwind ABI. This has a number of other changes with it though to move this design space forward a bit. Notably contained within here is: * On `panic=unwind` the `extern ""C""` ABI is now considered as ""may unwind"". This fixes a longstanding soundness issue where if you `panic!()` in an `extern ""C""` function defined in Rust that's actually UB because the LLVM representation for the function has the `nounwind` attribute but then you unwind. * Whether or not a function unwinds now mainly considers the ABI of the function instead of first checking the panic strategy. This fixes a miscompile of `extern ""C-unwind""` with `panic=abort` because that ABI can still unwind. * The aborting stub for non-unwinding ABIs with `panic=unwind` has been reimplemented. Previously this was done as a small tweak during MIR generation but this has been moved to a separate and dedicated MIR pass. This new pass will for appropriate functions and function calls insert a `cleanup` landing pad for any function call that may unwind within a function that is itself not allowed to unwind. Note that this subtly changes some behavior from before where previously on an unwind which was caught-to-abort it would run active destructors in the function and now it simply immediately aborts the process. * The `#[unwind]` attribute has been removed and all users in tests and such are now using `C-unwind` and `#![feature(c_unwind)]`. I think this is largely the last piece of the RFC to implement. Unfortunately I believe this is still not stabilizable as-is because activating the feature gate changes the behavior of the existing `extern ""C""` ABI in a way that has no replacement. My thinking for how to enable this is that we add support for the `C-unwind` ABI on stable Rust first and then after it hits stable we change the behavior of the `C` ABI. That way anyone straddling stable/beta/nightly can switch to `C-unwind` safely.",ROCKET,2021-08-11T12:20:13Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86157,MERGED,2021-06-09T02:06:25Z,2021-06-21T12:21:24Z,Use Tera templates for rustdoc.,jsha,9d93819fa7ae40376ac1f563a858d2ba5f3b0277,10,Auto merge of #86157 - jsha:tera r=jyn514 GuillaumeGomez Use Tera templates for rustdoc. Replaces a format!() call in layout::render with a template expansion. Introduces a `templates` field in SharedContext so parts of rustdoc can share pre-rendered templates. This currently builds in a copy of the single template available like with static files. However future work can make this live-loadable with a perma-unstable flag to make rustdoc developers' work easier. Part of #84419. Demo at https://hoffman-andrews.com/rust/tera/std/string/struct.String.html.,HEART,2021-06-09T08:07:40Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/86157,MERGED,2021-06-09T02:06:25Z,2021-06-21T12:21:24Z,Use Tera templates for rustdoc.,jsha,9d93819fa7ae40376ac1f563a858d2ba5f3b0277,10,Auto merge of #86157 - jsha:tera r=jyn514 GuillaumeGomez Use Tera templates for rustdoc. Replaces a format!() call in layout::render with a template expansion. Introduces a `templates` field in SharedContext so parts of rustdoc can share pre-rendered templates. This currently builds in a copy of the single template available like with static files. However future work can make this live-loadable with a perma-unstable flag to make rustdoc developers' work easier. Part of #84419. Demo at https://hoffman-andrews.com/rust/tera/std/string/struct.String.html.,HEART,2021-06-09T21:58:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86157,MERGED,2021-06-09T02:06:25Z,2021-06-21T12:21:24Z,Use Tera templates for rustdoc.,jsha,9d93819fa7ae40376ac1f563a858d2ba5f3b0277,10,Auto merge of #86157 - jsha:tera r=jyn514 GuillaumeGomez Use Tera templates for rustdoc. Replaces a format!() call in layout::render with a template expansion. Introduces a `templates` field in SharedContext so parts of rustdoc can share pre-rendered templates. This currently builds in a copy of the single template available like with static files. However future work can make this live-loadable with a perma-unstable flag to make rustdoc developers' work easier. Part of #84419. Demo at https://hoffman-andrews.com/rust/tera/std/string/struct.String.html.,HEART,2021-09-13T09:22:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86165,MERGED,2021-06-09T12:51:47Z,2021-09-11T06:30:47Z,Add proc_macro::Span::{before after}.,m-ou-se,000dbd27f146f4fd6ee2fb5e0f3060c440a08898,3,"Rollup merge of #86165 - m-ou-se:proc-macro-span-shrink r=dtolnay Add proc_macro::Span::{before after}. This adds `proc_macro::Span::before()` and `proc_macro::Span::after()` to get a zero width span at the start or end of the span. These are equivalent to rustc's `Span::shrink_to_lo()` and `Span::shrink_to_hi()` but with a less cryptic name. They are useful when generating diagnostlics like ""missing \ after \"". E.g. ```rust syn::Error::new(ident.span().after() ""missing `:` after field name"").into_compile_error() ```",THUMBS_UP,2021-06-13T03:58:13Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/86165,MERGED,2021-06-09T12:51:47Z,2021-09-11T06:30:47Z,Add proc_macro::Span::{before after}.,m-ou-se,000dbd27f146f4fd6ee2fb5e0f3060c440a08898,3,"Rollup merge of #86165 - m-ou-se:proc-macro-span-shrink r=dtolnay Add proc_macro::Span::{before after}. This adds `proc_macro::Span::before()` and `proc_macro::Span::after()` to get a zero width span at the start or end of the span. These are equivalent to rustc's `Span::shrink_to_lo()` and `Span::shrink_to_hi()` but with a less cryptic name. They are useful when generating diagnostlics like ""missing \ after \"". E.g. ```rust syn::Error::new(ident.span().after() ""missing `:` after field name"").into_compile_error() ```",THUMBS_UP,2021-09-10T17:52:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86165,MERGED,2021-06-09T12:51:47Z,2021-09-11T06:30:47Z,Add proc_macro::Span::{before after}.,m-ou-se,000dbd27f146f4fd6ee2fb5e0f3060c440a08898,3,"Rollup merge of #86165 - m-ou-se:proc-macro-span-shrink r=dtolnay Add proc_macro::Span::{before after}. This adds `proc_macro::Span::before()` and `proc_macro::Span::after()` to get a zero width span at the start or end of the span. These are equivalent to rustc's `Span::shrink_to_lo()` and `Span::shrink_to_hi()` but with a less cryptic name. They are useful when generating diagnostlics like ""missing \ after \"". E.g. ```rust syn::Error::new(ident.span().after() ""missing `:` after field name"").into_compile_error() ```",HEART,2021-09-16T04:29:37Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/86166,MERGED,2021-06-09T13:09:36Z,2021-06-21T06:56:56Z,Do not emit alloca for ZST locals with multiple assignments,tmiasko,3824017f8e57ce9dac6d69a1ce07f41c7034f82d,2,Auto merge of #86166 - tmiasko:no-alloca-for-zsts r=nagisa Do not emit alloca for ZST locals with multiple assignments This extends 35566bfd7dd2e316d190078703de54a4dadda062 to additionally stop emitting unnecessary allocas for zero sized locals that are assigned multiple times. When rebuilding the standard library with `-Zbuild-std` this reduces the number of locals that require an allocation from 62315 to 61767.,HEART,2021-06-10T05:07:25Z,scottmcm,NA https://github.com/rust-lang/rust/pull/86166,MERGED,2021-06-09T13:09:36Z,2021-06-21T06:56:56Z,Do not emit alloca for ZST locals with multiple assignments,tmiasko,3824017f8e57ce9dac6d69a1ce07f41c7034f82d,2,Auto merge of #86166 - tmiasko:no-alloca-for-zsts r=nagisa Do not emit alloca for ZST locals with multiple assignments This extends 35566bfd7dd2e316d190078703de54a4dadda062 to additionally stop emitting unnecessary allocas for zero sized locals that are assigned multiple times. When rebuilding the standard library with `-Zbuild-std` this reduces the number of locals that require an allocation from 62315 to 61767.,HEART,2021-07-02T06:02:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86166,MERGED,2021-06-09T13:09:36Z,2021-06-21T06:56:56Z,Do not emit alloca for ZST locals with multiple assignments,tmiasko,3824017f8e57ce9dac6d69a1ce07f41c7034f82d,2,Auto merge of #86166 - tmiasko:no-alloca-for-zsts r=nagisa Do not emit alloca for ZST locals with multiple assignments This extends 35566bfd7dd2e316d190078703de54a4dadda062 to additionally stop emitting unnecessary allocas for zero sized locals that are assigned multiple times. When rebuilding the standard library with `-Zbuild-std` this reduces the number of locals that require an allocation from 62315 to 61767.,HEART,2021-07-03T10:12:52Z,derekdreery,NA https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-06-10T06:23:11Z,tema3210,NA https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-06-14T14:08:58Z,PSeitz,NA https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-06-24T15:32:07Z,E-gy,NA https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-06-29T17:30:40Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-07-28T22:26:23Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-08-02T15:07:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2021-09-29T22:26:03Z,a1phyr,NA https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2022-01-13T14:16:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2022-04-05T22:38:42Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2022-05-19T15:20:02Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/86176,MERGED,2021-06-09T20:01:09Z,2021-08-02T18:24:58Z,Implement a `explicit_generic_args_with_impl_trait` feature gate,nbdd0121,14f3418f79a6cd1ecf5aab1a2275ab8b08785990,10,"Rollup merge of #86176 - nbdd0121:explicit-generic-args r=jackh726 Implement a `explicit_generic_args_with_impl_trait` feature gate Implements #83701 When this gate is enabled explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait` So code like this will be accepted: ```rust #![feature(explicit_generic_args_with_impl_trait)] fn foo(_f: impl AsRef) {} fn main() { foo::("""".to_string()); } ```",HOORAY,2022-06-19T13:07:57Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-10T05:06:09Z,scottmcm,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-10T13:21:02Z,fmease,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-10T19:37:35Z,CryZe,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-11T12:00:28Z,JackThomson2,jackathomson@outlook.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-16T12:07:56Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T06:00:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T07:32:38Z,mlouielu,git@louie.lu https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T11:30:34Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T11:38:01Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T13:59:46Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T21:23:03Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-24T23:02:24Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-25T16:09:12Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-25T19:21:47Z,adamreichold,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-28T11:01:46Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,ROCKET,2021-06-28T12:53:00Z,krdln,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2021-06-28T12:53:02Z,krdln,NA https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,ROCKET,2021-07-07T16:10:59Z,spachava753,spachava753@gmail.com https://github.com/rust-lang/rust/pull/86179,MERGED,2021-06-09T21:32:32Z,2021-06-16T18:13:29Z,optimize Eq implementation for paths,the8472,9fef8d91b4a6c5bfe07c025c434f2d623ad83337,1,Auto merge of #86179 - the8472:revere-path-cmp r=kennytm optimize Eq implementation for paths Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes. quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`: ``` # old test path::tests::bench_path_cmp ... bench: 227 407 ns/iter (+/- 2 162) # new test path::tests::bench_path_cmp ... bench: 64 976 ns/iter (+/- 1 142) ```,HEART,2022-03-18T17:59:03Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/86183,MERGED,2021-06-09T23:28:59Z,2021-08-02T04:59:11Z,Change environment variable getters to error recoverably,inquisitivecrystal,016612dc8d9ed850a066bccd42e4d6f7816f0484,8,Rollup merge of #86183 - inquisitivecrystal:env-nul r=m-ou-se Change environment variable getters to error recoverably This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value. On some platforms it is invalid for environment variable names to contain `'\0'` or `'='` or for their values to contain `'\0'`. Currently the standard library panics when manipulating environment variables with names or values that violate these invariants. However this behavior doesn't make a lot of sense at least in the case of getters. If the environment variable is missing the standard library just returns an error value rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus this PR changes the functions to error recoverably in this case as well. If desired I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them I'm happy to implement the changes. This fixes #86082 an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future. `@rustbot` label +T-libs r? `@joshtriplett`,THUMBS_UP,2021-06-25T08:43:13Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/86183,MERGED,2021-06-09T23:28:59Z,2021-08-02T04:59:11Z,Change environment variable getters to error recoverably,inquisitivecrystal,016612dc8d9ed850a066bccd42e4d6f7816f0484,8,Rollup merge of #86183 - inquisitivecrystal:env-nul r=m-ou-se Change environment variable getters to error recoverably This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value. On some platforms it is invalid for environment variable names to contain `'\0'` or `'='` or for their values to contain `'\0'`. Currently the standard library panics when manipulating environment variables with names or values that violate these invariants. However this behavior doesn't make a lot of sense at least in the case of getters. If the environment variable is missing the standard library just returns an error value rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus this PR changes the functions to error recoverably in this case as well. If desired I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them I'm happy to implement the changes. This fixes #86082 an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future. `@rustbot` label +T-libs r? `@joshtriplett`,THUMBS_UP,2021-08-11T12:23:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86183,MERGED,2021-06-09T23:28:59Z,2021-08-02T04:59:11Z,Change environment variable getters to error recoverably,inquisitivecrystal,016612dc8d9ed850a066bccd42e4d6f7816f0484,8,Rollup merge of #86183 - inquisitivecrystal:env-nul r=m-ou-se Change environment variable getters to error recoverably This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value. On some platforms it is invalid for environment variable names to contain `'\0'` or `'='` or for their values to contain `'\0'`. Currently the standard library panics when manipulating environment variables with names or values that violate these invariants. However this behavior doesn't make a lot of sense at least in the case of getters. If the environment variable is missing the standard library just returns an error value rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus this PR changes the functions to error recoverably in this case as well. If desired I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them I'm happy to implement the changes. This fixes #86082 an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future. `@rustbot` label +T-libs r? `@joshtriplett`,THUMBS_UP,2021-10-11T05:42:02Z,Lokathor,NA https://github.com/rust-lang/rust/pull/86190,MERGED,2021-06-10T03:28:25Z,2021-07-01T09:20:43Z,Fix ICE when `main` is declared in an `extern` block,asquared31415,f8ac8fdacf66b351c6479b0c8313e3e57e571ba4,5,Auto merge of #86190 - asquared31415:extern-main-86110-fix r=varkor Fix ICE when `main` is declared in an `extern` block Changes in #84401 to implement `imported_main` changed how the crate entry point is found and a declared `main` in an `extern` block was detected erroneously. This was causing the ICE described in #86110. This PR adds a check for this case and emits an error instead. Previously a `main` declaration in an `extern` block was not detected as an entry point at all so emitting an error shouldn't break anything that worked previously. In 1.52.1 stable this is demonstrated with a `` `main` function not found`` error. Fixes #86110,THUMBS_UP,2021-06-10T05:19:17Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86194,MERGED,2021-06-10T08:20:46Z,2021-06-19T01:40:37Z,make UB during CTFE a hard error,RalfJung,ec57c60c50de4f601a5dbe80e663388058e6e527,25,Auto merge of #86194 - RalfJung:const-ub-hard-error r=oli-obk make UB during CTFE a hard error This is a next step for https://github.com/rust-lang/rust/issues/71800. `const_err` has been a future-incompatibility lint for 4 months now since https://github.com/rust-lang/rust/pull/80394 (and err-by-default for many years before that) so I think we could try making it a proper hard error at least in some situations. I didn't yet adjust the tests since I first want to gauge the fall-out via crater. Cc `@rust-lang/wg-const-eval`,HEART,2021-06-10T09:06:00Z,oli-obk,NA https://github.com/rust-lang/rust/pull/86194,MERGED,2021-06-10T08:20:46Z,2021-06-19T01:40:37Z,make UB during CTFE a hard error,RalfJung,ec57c60c50de4f601a5dbe80e663388058e6e527,25,Auto merge of #86194 - RalfJung:const-ub-hard-error r=oli-obk make UB during CTFE a hard error This is a next step for https://github.com/rust-lang/rust/issues/71800. `const_err` has been a future-incompatibility lint for 4 months now since https://github.com/rust-lang/rust/pull/80394 (and err-by-default for many years before that) so I think we could try making it a proper hard error at least in some situations. I didn't yet adjust the tests since I first want to gauge the fall-out via crater. Cc `@rust-lang/wg-const-eval`,HEART,2021-06-10T19:35:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86194,MERGED,2021-06-10T08:20:46Z,2021-06-19T01:40:37Z,make UB during CTFE a hard error,RalfJung,ec57c60c50de4f601a5dbe80e663388058e6e527,25,Auto merge of #86194 - RalfJung:const-ub-hard-error r=oli-obk make UB during CTFE a hard error This is a next step for https://github.com/rust-lang/rust/issues/71800. `const_err` has been a future-incompatibility lint for 4 months now since https://github.com/rust-lang/rust/pull/80394 (and err-by-default for many years before that) so I think we could try making it a proper hard error at least in some situations. I didn't yet adjust the tests since I first want to gauge the fall-out via crater. Cc `@rust-lang/wg-const-eval`,HEART,2021-06-16T11:55:29Z,ahlinc,NA https://github.com/rust-lang/rust/pull/86194,MERGED,2021-06-10T08:20:46Z,2021-06-19T01:40:37Z,make UB during CTFE a hard error,RalfJung,ec57c60c50de4f601a5dbe80e663388058e6e527,25,Auto merge of #86194 - RalfJung:const-ub-hard-error r=oli-obk make UB during CTFE a hard error This is a next step for https://github.com/rust-lang/rust/issues/71800. `const_err` has been a future-incompatibility lint for 4 months now since https://github.com/rust-lang/rust/pull/80394 (and err-by-default for many years before that) so I think we could try making it a proper hard error at least in some situations. I didn't yet adjust the tests since I first want to gauge the fall-out via crater. Cc `@rust-lang/wg-const-eval`,HEART,2021-07-09T06:14:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86197,MERGED,2021-06-10T12:54:35Z,2021-08-04T12:58:45Z,Remove unnecessary trailing whitespace from error messages,FabianWolff,87d713ff2b000e3827ebb8be974b280188fac783,125,Auto merge of #86197 - FabianWolff:trailing-whitespace r=JohnTitor Remove unnecessary trailing whitespace from error messages Some error messages currently contain unnecessary trailing whitespace. There are some legitimate reasons for having trailing whitespace in the output such as for uniform indentation of possibly-empty input lines but the whitespace I have addressed here occurs in a line used only for spacing and I see no reason why that should have trailing whitespace (spacing lines inserted in other places also don't have trailing whitespace). I have also removed a superfluous call to `buffer.putc()` which has no effect because the same character is already placed there by `draw_col_separator()`. Use `git diff --ignore-space-at-eol` to see my changes; otherwise the diff is quite large due to the whitespace removed from expected outputs in `src/test/ui/`.,THUMBS_UP,2021-06-19T07:33:49Z,klensy,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-10T19:48:38Z,CryZe,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-10T19:51:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-10T19:58:47Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-10T23:57:46Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T04:06:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T08:35:53Z,Dengjianping,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T14:37:02Z,torokati44,torokati44@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T19:10:05Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T20:07:55Z,neculai-stanciu,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-11T21:56:36Z,fernand,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T04:55:10Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T06:36:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T06:46:56Z,rrbutani,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T06:51:31Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T14:57:01Z,i3abghany,ma.mandourr@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-12T20:44:30Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-14T06:53:46Z,Daniel-Liu-c0deb0t,daniel.liu02@gmail.com https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-06-19T14:46:04Z,Darkspirit,jan@ikenmeyer.eu https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-07-07T16:29:38Z,a1phyr,NA https://github.com/rust-lang/rust/pull/86204,MERGED,2021-06-10T19:39:09Z,2021-06-11T07:45:00Z,std: Stabilize wasm simd intrinsics,alexcrichton,68aa6b2d832579c156bda878a909f1bbb5261b36,5,Auto merge of #86204 - alexcrichton:wasm-simd-stable r=Amanieu std: Stabilize wasm simd intrinsics This commit performs two changes to stabilize Rust support for WebAssembly simd intrinsics: * The stdarch submodule is updated to pull in rust-lang/stdarch#1179. * The `wasm_target_feature` feature gate requirement for the `simd128` feature has been removed stabilizing the name `simd128`. This should conclude the FCP started on #74372 and... Closes #74372,HOORAY,2021-07-17T21:12:16Z,m4dh0rs3,schoeps.benedikt@gmail.com https://github.com/rust-lang/rust/pull/86206,MERGED,2021-06-10T23:34:34Z,2021-06-28T19:11:55Z,Fix type checking of return expressions outside of function bodies,FabianWolff,4afdef07d9edb6fab979b01f510a16ffc27a6ab6,8,Rollup merge of #86206 - FabianWolff:issue-86188 r=Mark-Simulacrum Fix type checking of return expressions outside of function bodies This pull request fixes #86188. The problem is that the current code for type-checking `return` expressions stops if the `return` occurs outside of a function body while the correct behavior is to continue type-checking the return value expression (otherwise an ICE happens later on because variables declared in the return value expression don't have a type). Also I have noticed that it is sometimes not obvious why a `return` is outside of a function body; for instance in the example from #86188 (which currently causes an ICE): ```rust fn main() { [(); return || { let tx; }] } ``` I have changed the error message to also explain why the `return` is considered outside of the function body: ``` error[E0572]: return statement outside of function body --> ice0.rs:2:10 | 1 | / fn main() { 2 | | [(); return || { | |__________^ 3 | || let tx; 4 | || }] | ||_____^ the return is part of this body... 5 | | } | |_- ...not the enclosing function body ```,THUMBS_UP,2021-07-02T03:08:21Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",THUMBS_UP,2021-06-11T11:07:11Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",THUMBS_UP,2021-06-13T09:31:08Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",ROCKET,2021-06-23T17:06:43Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",HEART,2021-07-14T01:21:49Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",HEART,2021-07-14T14:36:53Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",THUMBS_UP,2021-07-15T17:00:28Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",HEART,2021-07-15T17:00:29Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",ROCKET,2021-07-15T17:00:30Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",ROCKET,2021-07-15T20:05:05Z,numToStr,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",ROCKET,2021-07-15T22:13:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",HEART,2021-07-15T22:13:38Z,passy,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",ROCKET,2021-07-15T22:13:38Z,passy,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",HEART,2021-07-15T22:13:39Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86211,MERGED,2021-06-11T03:48:16Z,2021-07-14T07:51:52Z,create method overview docs for core::option and core::result,tlyu,a08f25a7ef2800af5525762e981c24d96c14febe,2,"Auto merge of #86211 - tlyu:option-result-overviews r=joshtriplett create method overview docs for core::option and core::result The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include ""truth tables"" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks for example. This is based on #86209 but those are small changes and unlikely to conflict.",THUMBS_UP,2021-07-15T22:13:39Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86213,MERGED,2021-06-11T06:05:55Z,2021-07-04T14:19:00Z,Stabilize `str::from_utf8_unchecked` as `const`,jhpratt,308fc2322bf00b5dc12454489679de1420320f56,1,Auto merge of #86213 - jhpratt:stabilize-const-from_utf8_unchecked r=JohnTitor Stabilize `str::from_utf8_unchecked` as `const` This stabilizes `unsafe fn str::from_utf8_unchecked` as `const` pending FCP on #75196. By the time FCP finishes the beta will have already been cut so I've set 1.55 as the stable-since version. (should also be +relnotes but I don't have the permission to do that) r? `@m-ou-se` Closes #75196,THUMBS_UP,2021-09-11T06:13:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/86220,MERGED,2021-06-11T13:40:04Z,2021-06-15T22:56:28Z,Improve maybe_uninit_extra docs,est31,e84ee522a927b3564aea4f0c5d61150f0f7c307a,1,Rollup merge of #86220 - est31:maybe-uninit-extra r=RalfJung Improve maybe_uninit_extra docs For reasoning see https://github.com/rust-lang/rust/issues/63567#issuecomment-858640987,HEART,2021-06-12T13:45:13Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86231,MERGED,2021-06-11T20:19:57Z,2021-07-06T16:50:37Z,Replace per-target ABI denylist with an allowlist,nagisa,b09dad3eddfc46c55e45f6c1a00bab09401684b4,101,Auto merge of #86231 - nagisa:nagisa/abi-allowlist r=petrochenkov Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when as far as non-generic ABIs are concerned targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. In this PR we got rid of the per-target ABI denylists and instead compute which ABIs are supported with a simple match based on mostly the `Target::arch` field. Among other things this makes it impossible to forget to consider this problem (in either direction) and forces one to consider what the ABI support looks like when adding an ABI (rarely) rather than target (often) which should hopefully also reduce the cognitive load on both contributors as well as reviewers. Fixes #57182 Sponsored by: standard.ai --- ## Summary for teams One significant user-facing change after this PR is that there's now a future compat warning when building… * `stdcall` `fastcall` `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*; * `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*. Previously these ABIs have been accepted much more broadly even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another. The intention is that this warning becomes a hard error after some time.,HEART,2021-06-11T20:21:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/86240,MERGED,2021-06-12T08:05:15Z,2021-06-12T23:08:16Z,Pretty print generator witness only in `-Zverbose` mode,tmiasko,24bdc6d73a75dce9a7013ebc7c037013ff4ea099,11,Auto merge of #86240 - tmiasko:verbose-generator-witness r=jackh726 Pretty print generator witness only in `-Zverbose` mode In release build of deeply-nested-async benchmark the size of `no-opt.bc` file is reduced from 46MB to 62kB. Helps with #84873 where in one of reported test cases the size of `no-opt.bc` file is reduced from 2.3GB to 799kB.,ROCKET,2021-06-23T23:34:07Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/86251,MERGED,2021-06-12T18:04:46Z,2021-07-28T12:02:44Z,Support -Z unpretty=thir-tree again,Smittyvb,eba3228b2a9875d268ff3990903d04e19f6cdb0c,8,Auto merge of #86251 - Smittyvb:thir-tree-again r=oli-obk Support -Z unpretty=thir-tree again Currently `-Z unpretty=thir-tree` is broken after some THIR refactorings. This re-implements it making it easier to debug THIR-related issues. We have to do analyzes before getting the THIR since trying to create THIR from invalid HIR can ICE. But doing those analyzes requires the THIR to be built and stolen. We work around this by creating a separate query to construct the THIR tree string representation. Closes https://github.com/rust-lang/project-thir-unsafeck/issues/8 fixes #85552.,THUMBS_UP,2021-06-13T18:58:49Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86251,MERGED,2021-06-12T18:04:46Z,2021-07-28T12:02:44Z,Support -Z unpretty=thir-tree again,Smittyvb,eba3228b2a9875d268ff3990903d04e19f6cdb0c,8,Auto merge of #86251 - Smittyvb:thir-tree-again r=oli-obk Support -Z unpretty=thir-tree again Currently `-Z unpretty=thir-tree` is broken after some THIR refactorings. This re-implements it making it easier to debug THIR-related issues. We have to do analyzes before getting the THIR since trying to create THIR from invalid HIR can ICE. But doing those analyzes requires the THIR to be built and stolen. We work around this by creating a separate query to construct the THIR tree string representation. Closes https://github.com/rust-lang/project-thir-unsafeck/issues/8 fixes #85552.,THUMBS_UP,2021-07-25T18:04:19Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86263,MERGED,2021-06-13T09:52:26Z,2021-09-08T20:42:49Z,Rustdoc: Report Layout of enum variants,fee1-dead,2f2aed1de7d7c7f0dd943635188078f810e1d468,2,Rollup merge of #86263 - fee1-dead:rustdoc-layout-variants r=camelid Rustdoc: Report Layout of enum variants Followup of #83501 Fixes #86253. cc `@camelid` `@rustbot` label A-rustdoc,THUMBS_UP,2021-07-10T05:20:04Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-06-13T14:44:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-06-13T19:03:43Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-06-14T11:02:15Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HEART,2021-06-16T11:14:14Z,theduke,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HEART,2021-06-17T10:40:48Z,yigal100,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-06-17T10:40:49Z,yigal100,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-07-19T17:13:51Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HEART,2021-07-19T17:13:51Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-07-27T15:56:02Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HEART,2021-07-27T15:56:02Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-07-29T12:34:55Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HOORAY,2021-07-30T21:18:22Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86264,MERGED,2021-06-13T11:15:02Z,2021-07-31T10:06:57Z,Trait upcasting coercion (part1),crlf0710,7069a8c2b78c5d23205de1cabb4c2a65229dbd8f,20,Auto merge of #86264 - crlf0710:trait_upcasting_part1 r=nikomatsakis Trait upcasting coercion (part1) This revives the first part of earlier PR #60900 . It's not very clear to me which parts of that pr was design decisions so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details. This is the first part it adds feature gates adds feature gates tests and implemented the unsize conversion part. (I hope i have dealt with the `ExistentialTraitRef` values correctly...) The next part will be implementing the pointer casting.,HEART,2021-07-30T21:18:23Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86267,MERGED,2021-06-13T16:50:03Z,2021-06-26T21:44:19Z,Allow loading of llvm plugins on nightly,ZuseZ4,a1411de9de38e0fed728874580218338160eb185,3,"Auto merge of #86267 - ZuseZ4:master r=nagisa Allow loading of llvm plugins on nightly Based on a discussion in #82734 / with `@wsmoses.` Mainly moves [this](https://github.com/wsmoses/rust/commit/0149bc4e7e596005c665b132877abebe5258a0f6) behind a -Z flag so it can only be used on nightly as requested by `@nagisa` in https://github.com/rust-lang/rust/issues/82734#issuecomment-835863940 This change allows loading of llvm plugins like Enzyme. Right now it also requires a shared library LLVM build of rustc for symbol resolution. ```rust // test.rs extern { fn __enzyme_autodiff(_: usize ...) -> f64; } fn square(x : f64) -> f64 { return x * x; } fn main() { unsafe { println!(""Hello world {} {}!"" square(3.0) __enzyme_autodiff(square as usize 3.0)); } } ``` ``` ./rustc test.rs -Z llvm-plugins=""./LLVMEnzyme-12.so"" -C passes=""enzyme"" ./test Hello world 9 6! ``` I will try to figure out how to simplify the usage and get this into stable in a later iteration but having this on nightly will already help testing further steps.",HEART,2021-06-25T16:43:31Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/86273,MERGED,2021-06-13T20:04:56Z,2021-06-14T15:47:02Z,Stabilize `maybe_uninit_ref`,JohnTitor,a216131c3566858b78f45ccc0c36b5578f5c5155,3,Auto merge of #86273 - JohnTitor:stabilize-maybe-uninit-ref r=RalfJung Stabilize `maybe_uninit_ref` This stabilizes `assume_init_{ref mut}`. FCP is complete: https://github.com/rust-lang/rust/issues/63568#issuecomment-590121300 The renaming was done by #76047 and FIXME was resolved by #76241 so I think we can now stabilize them finally 🎉 Still it's const-unstable as `assert_inhabited` is unstable. Closes #63568,HOORAY,2021-06-15T14:10:37Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86275,MERGED,2021-06-13T21:33:41Z,2021-06-14T22:59:49Z,Improve CTFE UB validation error messages,lqd,539d7bd3998d9bfed14c264eacda30097a4ea768,34,Auto merge of #86275 - lqd:ctfe-validation r=RalfJung Improve CTFE UB validation error messages As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors to move the path to the error prefix. From: `type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0` To: `type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.,HEART,2021-06-14T10:31:26Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86277,MERGED,2021-06-13T22:43:52Z,2021-06-15T22:56:28Z,Remove must_use from ALLOWED_ATTRIBUTES,jsha,d921055a5e2069eb61ede4bed7984a094c0136ba,5,Rollup merge of #86277 - jsha:remove-must-use r=Manishearth Remove must_use from ALLOWED_ATTRIBUTES This is a fairly common attribute on methods but is not something you need to know when reading the method docs - the purpose of the attribute is for the compiler to tell you about it if you forget to use a value. Removing reclaims some valuable space in the summary of methods particularly when the attribute has a long string value. As discussed in #84309. Partially addresses #81482. r? ```@Manishearth```,THUMBS_UP,2021-06-14T01:14:58Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-06-16T21:27:22Z,Lokathor,NA https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-06-16T21:47:07Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-06-17T08:25:15Z,elichai,NA https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-06-18T06:35:25Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-06-21T11:26:51Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/86281,CLOSED,2021-06-13T23:34:33Z,2021-08-17T17:02:25Z,Allow limited transmuting between types involving type parameters,illicitonion,NA,NA,NA,THUMBS_UP,2021-07-01T08:03:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,THUMBS_UP,2021-06-14T00:49:54Z,mohe2015,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,THUMBS_UP,2021-06-14T05:28:10Z,jbr,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,HOORAY,2021-06-14T05:28:16Z,jbr,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,THUMBS_UP,2021-06-14T16:09:21Z,fmease,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,HOORAY,2021-06-14T16:09:22Z,fmease,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,THUMBS_UP,2021-06-16T03:29:16Z,ben0x539,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,HOORAY,2021-06-16T03:29:17Z,ben0x539,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,HOORAY,2021-06-16T17:37:14Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86283,CLOSED,2021-06-14T00:37:00Z,2021-06-26T00:09:31Z,rustdoc: design change to separate methods better and improve scanning,jsha,NA,NA,NA,THUMBS_UP,2021-06-16T17:37:59Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86291,MERGED,2021-06-14T10:57:52Z,2021-06-16T10:01:22Z,Refactor vtable codegen,crlf0710,2336406b38db20d1bad30d32914e73af1dd62742,10,Auto merge of #86291 - crlf0710:trait_vtbl_refactor r=bjorn3 Refactor vtable codegen This refactor the codegen of vtables of miri interpreter llvm cranelift codegen backends. This is preparation for the implementation of trait upcasting feature. cc #65991 Note that aside from code reorganization there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots and now the first method is with index 3. cc `@RalfJung` `@bjorn3`,HOORAY,2021-06-15T03:18:41Z,byte1234,NA https://github.com/rust-lang/rust/pull/86291,MERGED,2021-06-14T10:57:52Z,2021-06-16T10:01:22Z,Refactor vtable codegen,crlf0710,2336406b38db20d1bad30d32914e73af1dd62742,10,Auto merge of #86291 - crlf0710:trait_vtbl_refactor r=bjorn3 Refactor vtable codegen This refactor the codegen of vtables of miri interpreter llvm cranelift codegen backends. This is preparation for the implementation of trait upcasting feature. cc #65991 Note that aside from code reorganization there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots and now the first method is with index 3. cc `@RalfJung` `@bjorn3`,HOORAY,2021-06-15T11:22:03Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86291,MERGED,2021-06-14T10:57:52Z,2021-06-16T10:01:22Z,Refactor vtable codegen,crlf0710,2336406b38db20d1bad30d32914e73af1dd62742,10,Auto merge of #86291 - crlf0710:trait_vtbl_refactor r=bjorn3 Refactor vtable codegen This refactor the codegen of vtables of miri interpreter llvm cranelift codegen backends. This is preparation for the implementation of trait upcasting feature. cc #65991 Note that aside from code reorganization there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots and now the first method is with index 3. cc `@RalfJung` `@bjorn3`,HOORAY,2021-06-16T06:08:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86291,MERGED,2021-06-14T10:57:52Z,2021-06-16T10:01:22Z,Refactor vtable codegen,crlf0710,2336406b38db20d1bad30d32914e73af1dd62742,10,Auto merge of #86291 - crlf0710:trait_vtbl_refactor r=bjorn3 Refactor vtable codegen This refactor the codegen of vtables of miri interpreter llvm cranelift codegen backends. This is preparation for the implementation of trait upcasting feature. cc #65991 Note that aside from code reorganization there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots and now the first method is with index 3. cc `@RalfJung` `@bjorn3`,HOORAY,2021-06-16T16:46:57Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86295,MERGED,2021-06-14T15:37:47Z,2021-06-27T15:45:28Z,Revert revert of constness in #86003,usbalbin,49ba9361d87f5d58d54fdd164ef2128cd50ed4b4,10,Auto merge of #86295 - usbalbin:revert_revert_of_constness r=RalfJung Revert revert of constness in #86003 Re-constify `mem::swap` `mem::replace` `ptr::write` which were marked as not `const` in #86003 Once the checks pass this should solve #86236,THUMBS_UP,2021-06-14T20:00:51Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/86327,MERGED,2021-06-15T12:53:59Z,2021-06-16T07:20:31Z,"Don't mark ""safe"" intrinsics as unsafe",GuillaumeGomez,98d58420c1e18f928bed833d54fda818ea5fd8de,2,"Rollup merge of #86327 - GuillaumeGomez:safe-intrinsics r=lqd Don't mark ""safe"" intrinsics as unsafe A good example of this is [intrinsics::abort](https://doc.rust-lang.org/nightly/core/intrinsics/fn.abort.html). Before: ![Screenshot from 2021-06-15 14-58-42](https://user-images.githubusercontent.com/3050060/122056942-65ddad00-cdea-11eb-829e-5f5e258387de.png) After: ![Screenshot from 2021-06-15 14-59-22](https://user-images.githubusercontent.com/3050060/122056956-6aa26100-cdea-11eb-94d8-e18b4956cfa4.png) cc ``@jyn514`` r? ``@lqd``",HEART,2021-06-15T17:27:52Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86327,MERGED,2021-06-15T12:53:59Z,2021-06-16T07:20:31Z,"Don't mark ""safe"" intrinsics as unsafe",GuillaumeGomez,98d58420c1e18f928bed833d54fda818ea5fd8de,2,"Rollup merge of #86327 - GuillaumeGomez:safe-intrinsics r=lqd Don't mark ""safe"" intrinsics as unsafe A good example of this is [intrinsics::abort](https://doc.rust-lang.org/nightly/core/intrinsics/fn.abort.html). Before: ![Screenshot from 2021-06-15 14-58-42](https://user-images.githubusercontent.com/3050060/122056942-65ddad00-cdea-11eb-829e-5f5e258387de.png) After: ![Screenshot from 2021-06-15 14-59-22](https://user-images.githubusercontent.com/3050060/122056956-6aa26100-cdea-11eb-94d8-e18b4956cfa4.png) cc ``@jyn514`` r? ``@lqd``",HEART,2021-06-15T21:10:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86327,MERGED,2021-06-15T12:53:59Z,2021-06-16T07:20:31Z,"Don't mark ""safe"" intrinsics as unsafe",GuillaumeGomez,98d58420c1e18f928bed833d54fda818ea5fd8de,2,"Rollup merge of #86327 - GuillaumeGomez:safe-intrinsics r=lqd Don't mark ""safe"" intrinsics as unsafe A good example of this is [intrinsics::abort](https://doc.rust-lang.org/nightly/core/intrinsics/fn.abort.html). Before: ![Screenshot from 2021-06-15 14-58-42](https://user-images.githubusercontent.com/3050060/122056942-65ddad00-cdea-11eb-829e-5f5e258387de.png) After: ![Screenshot from 2021-06-15 14-59-22](https://user-images.githubusercontent.com/3050060/122056956-6aa26100-cdea-11eb-94d8-e18b4956cfa4.png) cc ``@jyn514`` r? ``@lqd``",HEART,2021-06-16T16:48:35Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86335,MERGED,2021-06-15T19:16:01Z,2021-08-03T04:40:45Z,Commit to not supporting IPv4-in-IPv6 addresses,CDirkx,810b9267f38a398c28dd213bad4acc58dce0199a,1,"Auto merge of #86335 - CDirkx:ipv4-in-ipv6 r=dtolnay Commit to not supporting IPv4-in-IPv6 addresses Stabilization of the `ip` feature has for a long time been blocked on the question of whether Rust should support handling ""IPv4-in-IPv6"" addresses: should the various `Ipv6Address` property methods take IPv4-mapped or IPv4-compatible addresses into account. See also the IPv4-in-IPv6 Address Support issue #85609 and #69772 which originally asked the question. # Overview In the recent PR #85655 I proposed changing `is_loopback` to take IPv4-mapped addresses into account so `::ffff:127.0.0.1` would be recognized as a looback address. However due to the points that came up in that PR I alternatively propose the following: Keeping the current behaviour and commit to not assigning any special meaning for IPv4-in-IPv6 addresses other than what the standards prescribe. This would apply to the stable method `is_loopback` but also to currently unstable methods like `is_global` and `is_documentation` and any future methods. This is implemented in this PR as a change in documentation specifically the following section: > Both types of addresses are not assigned any special meaning by this implementation other than what the relevant standards prescribe. This means that an address like `::ffff:127.0.0.1` while representing an IPv4 loopback address is not itself an IPv6 loopback address; only `::1` is. To handle these so called ""IPv4-in-IPv6"" addresses they have to first be converted to their canonical IPv4 address. # Discussion In the discussion for or against supporting IPv4-in-IPv6 addresses the question what would be least surprising for users of other languages has come up several times. At first it seemed most big other languages supported IPv4-in-IPv6 addresses (or at least considered `::ffff:127.0.0.1` a loopback address). However after further investigation it appears that supporting IPv4-in-IPv6 addresses comes down to how a language represents addresses. .Net and Go do not have a separate type for IPv4 or IPv6 addresses and do consider `::ffff:127.0.0.1` a loopback address. Java and Python which do have separate types do not consider `::ffff:127.0.0.1` a loopback address. Seeing as Rust has the separate `Ipv6Addr` type it would make sense to also not support IPv4-in-IPv6 addresses. Note that this focuses on IPv4-mapped addresses no other language handles IPv4-compatible addresses. Another issue that was raised is how useful supporting these IPv4-in-IPv6 addresses would be in practice. Again with the example of `::ffff:127.0.0.1` considering it a loopback address isn't too useful as to use it with most of the socket APIs it has to be converted to an IPv4 address anyway. From that perspective it would be better to instead provide better ways for doing this conversion like stabilizing `to_ipv4_mapped` or introducing a `to_canonical` method. A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had and that supporting it would require changing already stable functions like `is_loopback`. This also keeps the documentation of these functions simpler as we only have to refer to the relevant definitions in the IPv6 specification. # Decision To make progress on the `ip` feature a decision needs to be made on whether or not to support IPv4-in-IPv6 addresses. There are several options: - Keep the current implementation and commit to never supporting IPv4-in-IPv6 addresses (accept this PR). - Support IPv4-in-IPv6 addresses in some/all `IPv6Addr` methods (accept PR #85655). - Keep the current implementation and but not commit to anything yet (reject both this PR and PR #85655) this entire issue will however come up again in the stabilization of several methods under the `ip` feature. There are more options like supporting IPv4-in-IPv6 addresses in `IpAddr` methods instead but to my knowledge those haven't been seriously argued for by anyone. There is currently an FCP ongoing on PR #85655. I would ask the libs team for an alternative FCP on this PR as well which if completed means the rejection of PR #85655 and the decision to commit to not supporting IPv4-in-IPv6 addresses. If anyone feels there is not enough evidence yet to make the decision for or against supporting IPv4-in-IPv6 addresses let me know and I'll do whatever I can to resolve it.",THUMBS_UP,2021-08-01T05:53:32Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/86336,MERGED,2021-06-15T19:53:19Z,2021-10-31T18:57:15Z,impl Pattern for char array,camsteffen,c7e4740ec18996e082fe6e29ebf7efdc7dda418f,1,Auto merge of #86336 - camsteffen:char-array-pattern r=joshtriplett impl Pattern for char array Closes #39511 Closes #86329,HOORAY,2021-11-04T07:09:35Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/86336,MERGED,2021-06-15T19:53:19Z,2021-10-31T18:57:15Z,impl Pattern for char array,camsteffen,c7e4740ec18996e082fe6e29ebf7efdc7dda418f,1,Auto merge of #86336 - camsteffen:char-array-pattern r=joshtriplett impl Pattern for char array Closes #39511 Closes #86329,HOORAY,2021-11-04T09:39:58Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/86368,MERGED,2021-06-16T15:15:09Z,2021-06-22T17:35:00Z,Disambiguate between SourceFiles from different crates even if they have the same path,michaelwoerister,80926fc409d671e7da13f08c90642b1e71f800d9,4,Auto merge of #86368 - michaelwoerister:lexing-ice r=davidtwco Disambiguate between SourceFiles from different crates even if they have the same path This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate: 1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`. 2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`. 3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents. This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created. Another more involved approach might be to merge the `src` and the `external_src` field. Fixes #85955,HEART,2021-06-16T15:42:30Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/86368,MERGED,2021-06-16T15:15:09Z,2021-06-22T17:35:00Z,Disambiguate between SourceFiles from different crates even if they have the same path,michaelwoerister,80926fc409d671e7da13f08c90642b1e71f800d9,4,Auto merge of #86368 - michaelwoerister:lexing-ice r=davidtwco Disambiguate between SourceFiles from different crates even if they have the same path This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate: 1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`. 2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`. 3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents. This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created. Another more involved approach might be to merge the `src` and the `external_src` field. Fixes #85955,HEART,2021-06-16T16:07:55Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/86368,MERGED,2021-06-16T15:15:09Z,2021-06-22T17:35:00Z,Disambiguate between SourceFiles from different crates even if they have the same path,michaelwoerister,80926fc409d671e7da13f08c90642b1e71f800d9,4,Auto merge of #86368 - michaelwoerister:lexing-ice r=davidtwco Disambiguate between SourceFiles from different crates even if they have the same path This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate: 1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`. 2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`. 3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents. This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created. Another more involved approach might be to merge the `src` and the `external_src` field. Fixes #85955,HEART,2021-07-02T06:04:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86370,MERGED,2021-06-16T15:37:05Z,2021-06-19T04:21:03Z,Fix rustdoc stabilized versions layout,matteo-briani,41bf471950dcf7cee52cf73a9f1ee979b7c39971,2,Rollup merge of #86370 - matteo-briani:fix-rustdoc-stabilized-versions-layout r=GuillaumeGomez Fix rustdoc stabilized versions layout Fixes #86342 r? `@GuillaumeGomez`,HEART,2021-06-17T06:27:59Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86370,MERGED,2021-06-16T15:37:05Z,2021-06-19T04:21:03Z,Fix rustdoc stabilized versions layout,matteo-briani,41bf471950dcf7cee52cf73a9f1ee979b7c39971,2,Rollup merge of #86370 - matteo-briani:fix-rustdoc-stabilized-versions-layout r=GuillaumeGomez Fix rustdoc stabilized versions layout Fixes #86342 r? `@GuillaumeGomez`,THUMBS_UP,2021-06-17T08:41:01Z,paride,paride@legovini.net https://github.com/rust-lang/rust/pull/86383,MERGED,2021-06-16T21:46:24Z,2021-06-22T01:14:33Z,Add MIR pass to lower call to `core::slice::len` into `Len` operand,shamatar,4573a4a879a8e1f773944a8859e4dcd136138af8,8,Auto merge of #86383 - shamatar:slice_len_lowering r=bjorn3 Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len` but I assume it can be eliminated just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip,HEART,2021-06-17T06:33:34Z,est31,NA https://github.com/rust-lang/rust/pull/86383,MERGED,2021-06-16T21:46:24Z,2021-06-22T01:14:33Z,Add MIR pass to lower call to `core::slice::len` into `Len` operand,shamatar,4573a4a879a8e1f773944a8859e4dcd136138af8,8,Auto merge of #86383 - shamatar:slice_len_lowering r=bjorn3 Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len` but I assume it can be eliminated just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip,HEART,2021-06-17T15:14:23Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/86383,MERGED,2021-06-16T21:46:24Z,2021-06-22T01:14:33Z,Add MIR pass to lower call to `core::slice::len` into `Len` operand,shamatar,4573a4a879a8e1f773944a8859e4dcd136138af8,8,Auto merge of #86383 - shamatar:slice_len_lowering r=bjorn3 Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len` but I assume it can be eliminated just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip,HEART,2021-06-22T09:48:47Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/86383,MERGED,2021-06-16T21:46:24Z,2021-06-22T01:14:33Z,Add MIR pass to lower call to `core::slice::len` into `Len` operand,shamatar,4573a4a879a8e1f773944a8859e4dcd136138af8,8,Auto merge of #86383 - shamatar:slice_len_lowering r=bjorn3 Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len` but I assume it can be eliminated just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip,HEART,2021-07-02T06:08:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86415,MERGED,2021-06-17T19:49:36Z,2021-06-24T07:29:50Z,Document associativity of iterator folds.,Kmeakin,0fa4f0ba6207ac8c8d1503f14f284d38b8fef81c,2,Rollup merge of #86415 - Kmeakin:iterator-associativity-docs r=dtolnay Document associativity of iterator folds. Document the associativity of `Iterator::fold` and `DoubleEndedIterator::rfold` and add examples demonstrating this. Add links to direct users to the fold of the opposite associativity.,HEART,2021-06-17T20:28:38Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/86415,MERGED,2021-06-17T19:49:36Z,2021-06-24T07:29:50Z,Document associativity of iterator folds.,Kmeakin,0fa4f0ba6207ac8c8d1503f14f284d38b8fef81c,2,Rollup merge of #86415 - Kmeakin:iterator-associativity-docs r=dtolnay Document associativity of iterator folds. Document the associativity of `Iterator::fold` and `DoubleEndedIterator::rfold` and add examples demonstrating this. Add links to direct users to the fold of the opposite associativity.,HEART,2021-06-18T00:46:04Z,alilleybrinker,abrinker@mitre.org https://github.com/rust-lang/rust/pull/86415,MERGED,2021-06-17T19:49:36Z,2021-06-24T07:29:50Z,Document associativity of iterator folds.,Kmeakin,0fa4f0ba6207ac8c8d1503f14f284d38b8fef81c,2,Rollup merge of #86415 - Kmeakin:iterator-associativity-docs r=dtolnay Document associativity of iterator folds. Document the associativity of `Iterator::fold` and `DoubleEndedIterator::rfold` and add examples demonstrating this. Add links to direct users to the fold of the opposite associativity.,EYES,2021-06-20T14:03:43Z,MacDue,macdue@dueutil.tech https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-06-18T15:37:01Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-06-18T15:59:29Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-06-23T17:33:02Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-06-29T16:33:36Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-07-09T23:38:47Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/86419,MERGED,2021-06-18T01:14:41Z,2021-07-10T01:55:08Z,Add support for raw-dylib with stdcall fastcall functions,ricobbe,8d9d4c87d677552ae52e2d58034e4be199b5a6d2,19,"Auto merge of #86419 - ricobbe:raw-dylib-stdcall r=petrochenkov Add support for raw-dylib with stdcall fastcall functions Next stage of work for #58713: allow `extern ""stdcall""` and `extern ""fastcall""` with `#[link(kind = ""raw-dylib"")]`. I've deliberately omitted support for vectorcall as that doesn't currently work and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet but at first (very cursory) glance it appears that the problem is elsewhere.)",HEART,2021-07-15T22:08:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86426,MERGED,2021-06-18T07:12:50Z,2021-06-19T11:23:55Z,Lint for unused borrows as part of UNUSED_MUST_USE,hi-rustin,39260f6d4994db191f2fca9f12b4930eb3a3c122,24,Auto merge of #86426 - hi-rustin:rustin-patch-lint-warn r=Aaron1011 Lint for unused borrows as part of UNUSED_MUST_USE close https://github.com/rust-lang/rust/issues/76264 base on https://github.com/rust-lang/rust/pull/76894 r? `@RalfJung`,THUMBS_UP,2021-06-18T07:30:37Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/86426,MERGED,2021-06-18T07:12:50Z,2021-06-19T11:23:55Z,Lint for unused borrows as part of UNUSED_MUST_USE,hi-rustin,39260f6d4994db191f2fca9f12b4930eb3a3c122,24,Auto merge of #86426 - hi-rustin:rustin-patch-lint-warn r=Aaron1011 Lint for unused borrows as part of UNUSED_MUST_USE close https://github.com/rust-lang/rust/issues/76264 base on https://github.com/rust-lang/rust/pull/76894 r? `@RalfJung`,THUMBS_UP,2021-06-18T08:22:54Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/86437,MERGED,2021-06-18T15:46:59Z,2021-06-19T16:20:01Z,add various coments to explain how the TAIT code works,nikomatsakis,29cd70d40722930e66a8b726fe58a7bd1d64a22b,3,Auto merge of #86437 - nikomatsakis:tait-docs r=oli-obk add various coments to explain how the TAIT code works r? `@oli-obk`,HEART,2021-06-18T17:13:59Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86437,MERGED,2021-06-18T15:46:59Z,2021-06-19T16:20:01Z,add various coments to explain how the TAIT code works,nikomatsakis,29cd70d40722930e66a8b726fe58a7bd1d64a22b,3,Auto merge of #86437 - nikomatsakis:tait-docs r=oli-obk add various coments to explain how the TAIT code works r? `@oli-obk`,HEART,2021-06-18T20:30:56Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/86447,CLOSED,2021-06-18T21:03:37Z,2022-02-17T15:41:13Z,Windows: Fix `fs::canonicalize` to work with legacy drivers,ChrisDenton,NA,NA,NA,THUMBS_UP,2021-07-03T13:10:59Z,Frago9876543210,NA https://github.com/rust-lang/rust/pull/86450,MERGED,2021-06-18T23:01:01Z,2021-07-27T16:17:13Z,Add flag to configure `large_assignments` lint,tmiasko,99a6474bc45c66823972da3e4e23dc4cf47dd79a,7,"Rollup merge of #86450 - tmiasko:move-size-limit r=pnkfelix Add flag to configure `large_assignments` lint The `large_assignments` lints detects moves over specified limit. The limit is configured through `move_size_limit = ""N""` attribute placed at the root of a crate. When attribute is absent the lint is disabled. Make it possible to enable the lint without making any changes to the source code through a new flag `-Zmove-size-limit=N`. For example to detect moves exceeding 1023 bytes in a cargo crate including all dependencies one could use: ``` $ env RUSTFLAGS=-Zmove-size-limit=1024 cargo build -vv ``` Lint tracking issue #83518.",THUMBS_UP,2021-07-05T22:05:03Z,klensy,NA https://github.com/rust-lang/rust/pull/86455,MERGED,2021-06-19T00:52:45Z,2021-11-16T11:28:47Z,check where-clause for explicit `Sized` before suggesting `?Sized`,tlyu,ebef3ce25ba3d604fa24b4cf5c5670ce551f04f5,5,Rollup merge of #86455 - tlyu:check-where-before-suggesting-unsized r=estebank check where-clause for explicit `Sized` before suggesting `?Sized` Fixes #85945. Based on #86454. ``@rustbot`` label +A-diagnostics +A-traits +A-typesystem +D-papercut +T-compiler,HEART,2021-09-16T15:20:15Z,estebank,NA https://github.com/rust-lang/rust/pull/86462,CLOSED,2021-06-19T03:46:51Z,2021-06-27T03:13:48Z,Use RangeInclusive for fNN::lerp,CAD97,NA,NA,NA,THUMBS_UP,2021-06-19T15:24:06Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/86462,CLOSED,2021-06-19T03:46:51Z,2021-06-27T03:13:48Z,Use RangeInclusive for fNN::lerp,CAD97,NA,NA,NA,THUMBS_DOWN,2021-06-27T04:28:50Z,koalefant,koalefant@fastmail.com https://github.com/rust-lang/rust/pull/86473,MERGED,2021-06-19T16:42:00Z,2021-06-21T22:24:15Z,Rustdoc: Account for const-unstable functions,fee1-dead,f3fe5c3ba14d788d19bf90ccb3dcd9dd636f6094,4,Rollup merge of #86473 - fee1-dead:rustdoc-const-unstable r=jyn514 Rustdoc: Account for const-unstable functions Fixes #86464,THUMBS_UP,2021-06-20T15:40:10Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86473,MERGED,2021-06-19T16:42:00Z,2021-06-21T22:24:15Z,Rustdoc: Account for const-unstable functions,fee1-dead,f3fe5c3ba14d788d19bf90ccb3dcd9dd636f6094,4,Rollup merge of #86473 - fee1-dead:rustdoc-const-unstable r=jyn514 Rustdoc: Account for const-unstable functions Fixes #86464,HEART,2021-06-21T22:30:07Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86478,MERGED,2021-06-20T00:17:05Z,2021-07-15T17:10:20Z,Add -Zfuture-incompat-test to assist with testing future-incompat reports.,ehuss,98130137d95ca130dedd2501c2e6478734658683,8,"Rollup merge of #86478 - ehuss:future-incompat-test r=oli-obk Add -Zfuture-incompat-test to assist with testing future-incompat reports. This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now Cargo relies on using array_into_iter as a test subject. Since the breaking ""future incompatible"" lints are never intended to last forever this means Cargo's testsuite would always need to keep changing to choose different lints (for example #86330 proposed dropping that moniker for array_into_iter). With this flag Cargo's tests can trigger any lint and check for the report.",THUMBS_UP,2021-06-20T00:19:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86478,MERGED,2021-06-20T00:17:05Z,2021-07-15T17:10:20Z,Add -Zfuture-incompat-test to assist with testing future-incompat reports.,ehuss,98130137d95ca130dedd2501c2e6478734658683,8,"Rollup merge of #86478 - ehuss:future-incompat-test r=oli-obk Add -Zfuture-incompat-test to assist with testing future-incompat reports. This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now Cargo relies on using array_into_iter as a test subject. Since the breaking ""future incompatible"" lints are never intended to last forever this means Cargo's testsuite would always need to keep changing to choose different lints (for example #86330 proposed dropping that moniker for array_into_iter). With this flag Cargo's tests can trigger any lint and check for the report.",THUMBS_UP,2021-06-28T00:49:13Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86479,MERGED,2021-06-20T01:06:58Z,2021-10-20T01:16:26Z,Automatic exponential formatting in Debug,ExpHP,ca6798ab073c4f2358f2577e7258108099f29144,4,"Rollup merge of #86479 - exphp-forks:float-debug-exponential r=yaahc Automatic exponential formatting in Debug Context: See [this comment from the libs team](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-853454204) --- Makes `""{:?}""` switch to exponential for floats based on magnitude. The libs team suggested exploring this idea in the discussion thread for RFC rust-lang/rfcs#2729. (**note:** this is **not** an implementation of the RFC; it is an implementation of one of the alternatives) Thresholds chosen were 1e-4 and 1e16. Justification described [here](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-864482954). **This will require a crater run.** --- As mentioned in the commit message of 8731d4dfb47 this behavior will not apply when a precision is supplied because I wanted to preserve the following existing and useful behavior of `{:.PREC?}` (which recursively applies `{:.PREC}` to floats in a struct): ```rust assert_eq!( format!(""{:.2?}"" [100.0 0.000004]) ""[100.00 0.00]"" ) ``` I looked around and am not sure where there are any tests that actually use this in the test suite though? All things considered I'm surprised that this change did not seem to break even a single existing test in `x.py test --stage 2`. (even when I tried a smaller threshold of 1e6)",HEART,2021-10-14T23:47:07Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/86479,MERGED,2021-06-20T01:06:58Z,2021-10-20T01:16:26Z,Automatic exponential formatting in Debug,ExpHP,ca6798ab073c4f2358f2577e7258108099f29144,4,"Rollup merge of #86479 - exphp-forks:float-debug-exponential r=yaahc Automatic exponential formatting in Debug Context: See [this comment from the libs team](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-853454204) --- Makes `""{:?}""` switch to exponential for floats based on magnitude. The libs team suggested exploring this idea in the discussion thread for RFC rust-lang/rfcs#2729. (**note:** this is **not** an implementation of the RFC; it is an implementation of one of the alternatives) Thresholds chosen were 1e-4 and 1e16. Justification described [here](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-864482954). **This will require a crater run.** --- As mentioned in the commit message of 8731d4dfb47 this behavior will not apply when a precision is supplied because I wanted to preserve the following existing and useful behavior of `{:.PREC?}` (which recursively applies `{:.PREC}` to floats in a struct): ```rust assert_eq!( format!(""{:.2?}"" [100.0 0.000004]) ""[100.00 0.00]"" ) ``` I looked around and am not sure where there are any tests that actually use this in the test suite though? All things considered I'm surprised that this change did not seem to break even a single existing test in `x.py test --stage 2`. (even when I tried a smaller threshold of 1e6)",THUMBS_UP,2021-10-20T07:47:03Z,iago-lito,NA https://github.com/rust-lang/rust/pull/86479,MERGED,2021-06-20T01:06:58Z,2021-10-20T01:16:26Z,Automatic exponential formatting in Debug,ExpHP,ca6798ab073c4f2358f2577e7258108099f29144,4,"Rollup merge of #86479 - exphp-forks:float-debug-exponential r=yaahc Automatic exponential formatting in Debug Context: See [this comment from the libs team](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-853454204) --- Makes `""{:?}""` switch to exponential for floats based on magnitude. The libs team suggested exploring this idea in the discussion thread for RFC rust-lang/rfcs#2729. (**note:** this is **not** an implementation of the RFC; it is an implementation of one of the alternatives) Thresholds chosen were 1e-4 and 1e16. Justification described [here](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-864482954). **This will require a crater run.** --- As mentioned in the commit message of 8731d4dfb47 this behavior will not apply when a precision is supplied because I wanted to preserve the following existing and useful behavior of `{:.PREC?}` (which recursively applies `{:.PREC}` to floats in a struct): ```rust assert_eq!( format!(""{:.2?}"" [100.0 0.000004]) ""[100.00 0.00]"" ) ``` I looked around and am not sure where there are any tests that actually use this in the test suite though? All things considered I'm surprised that this change did not seem to break even a single existing test in `x.py test --stage 2`. (even when I tried a smaller threshold of 1e6)",THUMBS_UP,2021-10-28T06:01:59Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86479,MERGED,2021-06-20T01:06:58Z,2021-10-20T01:16:26Z,Automatic exponential formatting in Debug,ExpHP,ca6798ab073c4f2358f2577e7258108099f29144,4,"Rollup merge of #86479 - exphp-forks:float-debug-exponential r=yaahc Automatic exponential formatting in Debug Context: See [this comment from the libs team](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-853454204) --- Makes `""{:?}""` switch to exponential for floats based on magnitude. The libs team suggested exploring this idea in the discussion thread for RFC rust-lang/rfcs#2729. (**note:** this is **not** an implementation of the RFC; it is an implementation of one of the alternatives) Thresholds chosen were 1e-4 and 1e16. Justification described [here](https://github.com/rust-lang/rfcs/pull/2729#issuecomment-864482954). **This will require a crater run.** --- As mentioned in the commit message of 8731d4dfb47 this behavior will not apply when a precision is supplied because I wanted to preserve the following existing and useful behavior of `{:.PREC?}` (which recursively applies `{:.PREC}` to floats in a struct): ```rust assert_eq!( format!(""{:.2?}"" [100.0 0.000004]) ""[100.00 0.00]"" ) ``` I looked around and am not sure where there are any tests that actually use this in the test suite though? All things considered I'm surprised that this change did not seem to break even a single existing test in `x.py test --stage 2`. (even when I tried a smaller threshold of 1e6)",THUMBS_UP,2022-02-10T06:23:44Z,edlanglois,NA https://github.com/rust-lang/rust/pull/86493,MERGED,2021-06-20T18:54:47Z,2021-06-22T04:15:17Z,"Say ""this enum variant takes""/""this struct takes"" instead of ""this function takes""",Smittyvb,4495ce75d975136173dbd4c139f00d1f508a6994,5,"Rollup merge of #86493 - Smittyvb:ctor-typeck-error r=davidtwco Say ""this enum variant takes""/""this struct takes"" instead of ""this function takes"" This makes error messages for functions with incorrect argument counts adapt if they refer to a struct or enum variant: ``` error[E0061]: this enum variant takes 1 argument but 0 arguments were supplied --> $DIR/struct-enum-wrong-args.rs:7:13 | LL | let _ = Ok(); | ^^-- supplied 0 arguments | | | expected 1 argument error[E0061]: this struct takes 1 argument but 0 arguments were supplied --> $DIR/struct-enum-wrong-args.rs:8:13 | LL | let _ = Wrapper(); | ^^^^^^^-- supplied 0 arguments | | | expected 1 argument ``` Fixes #86481.",THUMBS_UP,2021-06-20T19:51:58Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86493,MERGED,2021-06-20T18:54:47Z,2021-06-22T04:15:17Z,"Say ""this enum variant takes""/""this struct takes"" instead of ""this function takes""",Smittyvb,4495ce75d975136173dbd4c139f00d1f508a6994,5,"Rollup merge of #86493 - Smittyvb:ctor-typeck-error r=davidtwco Say ""this enum variant takes""/""this struct takes"" instead of ""this function takes"" This makes error messages for functions with incorrect argument counts adapt if they refer to a struct or enum variant: ``` error[E0061]: this enum variant takes 1 argument but 0 arguments were supplied --> $DIR/struct-enum-wrong-args.rs:7:13 | LL | let _ = Ok(); | ^^-- supplied 0 arguments | | | expected 1 argument error[E0061]: this struct takes 1 argument but 0 arguments were supplied --> $DIR/struct-enum-wrong-args.rs:8:13 | LL | let _ = Wrapper(); | ^^^^^^^-- supplied 0 arguments | | | expected 1 argument ``` Fixes #86481.",THUMBS_UP,2021-06-21T01:23:57Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86497,MERGED,2021-06-20T20:32:39Z,2022-02-08T10:05:18Z,Add {floor ceil}_char_boundary methods to str,clarfonthey,1f841fc5fe4f7c6f6c73de93930c3ee38c5f814b,5,"Rollup merge of #86497 - clarfonthey:nearest_char_boundary r=scottmcm Add {floor ceil}_char_boundary methods to str This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`. Essentially these are two building blocks to allow for approximate string truncation where you want to cut off the string at ""approximately"" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range and because it will make it possible to vectorise. Although this method doesn't take into account graphemes or other properties this would still be a required building block for splitting that takes those into account. For example if you wanted to split at a grapheme boundary you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string. This takes the most conservative approach and just offers the raw indices to the user and they can decide how to use them. That way the methods are as useful as possible despite having as few methods as possible. (Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)",THUMBS_UP,2021-07-01T22:37:23Z,bluss,NA https://github.com/rust-lang/rust/pull/86497,MERGED,2021-06-20T20:32:39Z,2022-02-08T10:05:18Z,Add {floor ceil}_char_boundary methods to str,clarfonthey,1f841fc5fe4f7c6f6c73de93930c3ee38c5f814b,5,"Rollup merge of #86497 - clarfonthey:nearest_char_boundary r=scottmcm Add {floor ceil}_char_boundary methods to str This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`. Essentially these are two building blocks to allow for approximate string truncation where you want to cut off the string at ""approximately"" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range and because it will make it possible to vectorise. Although this method doesn't take into account graphemes or other properties this would still be a required building block for splitting that takes those into account. For example if you wanted to split at a grapheme boundary you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string. This takes the most conservative approach and just offers the raw indices to the user and they can decide how to use them. That way the methods are as useful as possible despite having as few methods as possible. (Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)",THUMBS_UP,2021-10-28T04:32:38Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/86497,MERGED,2021-06-20T20:32:39Z,2022-02-08T10:05:18Z,Add {floor ceil}_char_boundary methods to str,clarfonthey,1f841fc5fe4f7c6f6c73de93930c3ee38c5f814b,5,"Rollup merge of #86497 - clarfonthey:nearest_char_boundary r=scottmcm Add {floor ceil}_char_boundary methods to str This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`. Essentially these are two building blocks to allow for approximate string truncation where you want to cut off the string at ""approximately"" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range and because it will make it possible to vectorise. Although this method doesn't take into account graphemes or other properties this would still be a required building block for splitting that takes those into account. For example if you wanted to split at a grapheme boundary you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string. This takes the most conservative approach and just offers the raw indices to the user and they can decide how to use them. That way the methods are as useful as possible despite having as few methods as possible. (Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)",THUMBS_UP,2022-05-24T20:43:25Z,bluebear94,NA https://github.com/rust-lang/rust/pull/86497,MERGED,2021-06-20T20:32:39Z,2022-02-08T10:05:18Z,Add {floor ceil}_char_boundary methods to str,clarfonthey,1f841fc5fe4f7c6f6c73de93930c3ee38c5f814b,5,"Rollup merge of #86497 - clarfonthey:nearest_char_boundary r=scottmcm Add {floor ceil}_char_boundary methods to str This is technically already used internally by the standard library in the form of `truncate_to_char_boundary`. Essentially these are two building blocks to allow for approximate string truncation where you want to cut off the string at ""approximately"" a given length in bytes but don't know exactly where the character boundaries lie. It's also a good candidate for the standard library as it can easily be done naively but would be difficult to properly optimise. Although the existing code that's done in error messages is done naively this code will explicitly only check a window of 4 bytes since we know that a boundary must lie in that range and because it will make it possible to vectorise. Although this method doesn't take into account graphemes or other properties this would still be a required building block for splitting that takes those into account. For example if you wanted to split at a grapheme boundary you could take your approximate splitting point and then determine the graphemes immediately following and preceeding the split. If you then notice that these two graphemes could be merged you can decide to either include the whole grapheme or exclude it depending on whether you decide splitting should shrink or expand the string. This takes the most conservative approach and just offers the raw indices to the user and they can decide how to use them. That way the methods are as useful as possible despite having as few methods as possible. (Note: I'll add some tests and a tracking issue if it's decided that this is worth including.)",THUMBS_UP,2022-06-23T03:19:12Z,0x5459,NA https://github.com/rust-lang/rust/pull/86513,MERGED,2021-06-21T12:16:54Z,2021-06-25T20:40:09Z,Rustdoc: Do not list impl when trait has doc(hidden),fee1-dead,6be1732e69c2bf4706f0b745941a49b5a328c2f8,4,Rollup merge of #86513 - fee1-dead:cross-crate-doc-hidden r=danielhenrymantilla Rustdoc: Do not list impl when trait has doc(hidden) Fixes #86448.,THUMBS_UP,2021-06-21T21:54:57Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/86517,MERGED,2021-06-21T16:41:16Z,2021-06-22T14:54:04Z,Fix `unused_unsafe` around `await`,camsteffen,8ec4e7dfdd5b90aa8867bf07e4d68f57908b080e,9,Rollup merge of #86517 - camsteffen:unused-unsafe-async r=LeSeulArtichaut Fix `unused_unsafe` around `await` Enables `unused_unsafe` lint for `unsafe { future.await }`. The existing test for this is `unsafe { println!() }` so I assume that `println!` used to contain compiler-generated unsafe but this is no longer true and so the existing test is broken. I replaced the test with `unsafe { ...await }`. I believe `await` is currently the only instance of compiler-generated unsafe. Reverts some parts of #85421 but the issue predates that PR.,THUMBS_UP,2021-06-21T21:31:54Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86521,MERGED,2021-06-21T19:30:35Z,2021-06-23T02:27:16Z,Add comments around code where ordering is important due for panic-safety,the8472,6023ac2c8d10661f7a4f405edf795d956c927620,4,Rollup merge of #86521 - the8472:add-footgun-comments r=RalfJung Add comments around code where ordering is important due for panic-safety Iterators contain arbitrary code which may panic. Unsafe code has to be careful to do its state updates at the right point between calls that may panic. As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948 r? `@RalfJung`,THUMBS_UP,2021-06-21T20:31:07Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/86521,MERGED,2021-06-21T19:30:35Z,2021-06-23T02:27:16Z,Add comments around code where ordering is important due for panic-safety,the8472,6023ac2c8d10661f7a4f405edf795d956c927620,4,Rollup merge of #86521 - the8472:add-footgun-comments r=RalfJung Add comments around code where ordering is important due for panic-safety Iterators contain arbitrary code which may panic. Unsafe code has to be careful to do its state updates at the right point between calls that may panic. As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948 r? `@RalfJung`,HEART,2021-06-22T07:15:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86522,MERGED,2021-06-21T20:40:10Z,2021-06-30T02:21:07Z,Move some UI tests to more suitable subdirs,JohnTitor,0ce21126b295608ab4704f678d53ae8d2e9b60d1,53,Auto merge of #86522 - JohnTitor:move-ui-tests r=petrochenkov Move some UI tests to more suitable subdirs cc #73494 The classified result is here: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427 - issues/issue-27060.rs: misclassified should be packed. - issues/issue-45157.rs: moved to nll. - issues/issue-69532.rs: ~~couldn't figured out the best place placed a new `llvm` dir~~ moved to consts. - fsu-moves-and-copies.rs: moved to borrowck. - issues/issue-36638.rs: misclassified moved to keyword. - issues/issue-48636.rs: moved to parser. - issues/issue-37655.rs: I'm not sure but associated-types shouldn't the best moved to coercion but region may be better. - issues/issue-20005.rs: moved to associated-types. - issues/issue-82869.rs: moved to asm. - issues/issue-24535-allow-mutable-borrow-in-match-guard.rs: moved to nll. - issues/issue-52169.rs: moved to macros. - test-passed.rs: moved to test-attrs along with `test-` prefixed tests. - test-cfg.rs: moved to conditional-compilation. - non-integer-atomic.rs: moved to intrinsics. - issues/issue-54521-2.rs: moved to parser. - issues/issue-17756.rs: moved to consts. - conversion-methods.rs: ~~moved to suggestions~~ moved to typeck. r? `@petrochenkov`,HEART,2021-06-21T20:50:45Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86523,MERGED,2021-06-21T20:49:58Z,2021-06-23T02:27:16Z,Improvements to intra-doc link macro disambiguators,LeSeulArtichaut,f9ebf1edb51f257e73586d429800e3a1914b873a,2,Rollup merge of #86523 - LeSeulArtichaut:macros-disambiguators r=jyn514 Improvements to intra-doc link macro disambiguators A few small improvements around macro disambiguators: - display the link text as it was entered: previously `[macro!()]` would be displayed without the parantheses (fixes #86309) - support `!{}` and `![]` as macro disambiguators (fixes #86310) r? `@jyn514` cc `@Manishearth` `@camelid`,HEART,2021-06-21T22:09:34Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-21T22:26:21Z,est31,NA https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-21T22:26:31Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-21T22:27:51Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-23T02:24:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-24T15:49:38Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-06-26T19:08:22Z,Cons-Cat,wgooch2000@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-07-02T06:14:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-10-06T21:40:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-10-14T05:57:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-10-17T21:11:58Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/86525,MERGED,2021-06-21T22:16:24Z,2021-10-07T14:22:35Z,Array `.len()` MIR optimization pass,shamatar,680ff86391f19e12b485293f01372036e85ba87c,18,Auto merge of #86525 - shamatar:array_len_opt r=oli-obk Array `.len()` MIR optimization pass This pass kind-of works back the `[T; N].len()` call that at the moment is first coerced as `&[T; N]` -> `&[T]` and then uses `&[T].len()`. Depends on #86383,HEART,2021-10-20T15:14:10Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-06-23T01:54:40Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-06-25T02:18:05Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-07-19T14:34:36Z,Zerotask,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-10T17:58:38Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T02:04:16Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-11T02:04:17Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T10:58:43Z,wschella,wout.schellaert@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-11T10:58:44Z,wschella,wout.schellaert@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-11T12:23:32Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T12:23:38Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-11T14:48:06Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T14:48:06Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T15:20:10Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-11T19:03:48Z,0xdeafbeef,hello@0xdeafbeef.dev https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-12T00:11:32Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-12T08:18:46Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-12T08:18:46Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T16:28:00Z,drmason13,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T16:55:24Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T16:55:25Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T16:55:25Z,DenisKolodin,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:05:47Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T17:26:02Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:26:37Z,antonok-edm,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:27:38Z,matheus-consoli,matheus.consoli7@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:30:34Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T17:30:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:34:09Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T17:34:10Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T17:34:10Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T17:42:48Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T17:46:54Z,leeola,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:46:55Z,leeola,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T17:46:56Z,leeola,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T17:48:48Z,Kinrany,kinrany@yandex.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:03:09Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T18:03:10Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:06:37Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T18:06:37Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:06:38Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T18:15:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:15:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:15:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:31:27Z,keithmss,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T18:31:27Z,keithmss,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:31:28Z,keithmss,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:33:13Z,aalhitennf,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:33:17Z,aalhitennf,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:38:30Z,prokopyl,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:38:38Z,ondt,me@ondt.dev https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:38:59Z,reubencornel,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:45:08Z,MaikKlein,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:45:16Z,daniel-buse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:45:18Z,daniel-buse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T18:45:42Z,PSeitz,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T18:58:31Z,repi,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:02:34Z,Geobert,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:08:07Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:13:24Z,DidiBear,adrien.turiot@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:17:42Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T19:17:43Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T19:17:44Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:20:26Z,LeCyberDucky,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:26:49Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:39:47Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T19:47:44Z,m-rsha,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:01:02Z,tomsik68,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:02:20Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:03:57Z,funbringer,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:04:11Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:04:12Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:10:01Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:10:02Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:10:03Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:10:06Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:18:13Z,vladinator1000,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:24:09Z,jonathansharman,jonathan.sharman@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:25:03Z,MarcelGarus,hello@marcelgarus.dev https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:27:38Z,narigama,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:45:56Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:45:58Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:46:04Z,vadixidav,vadixidav@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:47:34Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:47:34Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:47:34Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:53:12Z,praveenperera,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:53:13Z,praveenperera,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:53:15Z,praveenperera,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T20:56:02Z,cmarincia,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T20:56:03Z,cmarincia,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T20:56:04Z,cmarincia,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T21:09:55Z,newAM,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T21:09:56Z,newAM,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:09:57Z,newAM,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T21:10:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:10:45Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T21:10:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T21:22:36Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:22:37Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T21:22:38Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T21:24:03Z,phip1611,phip1611@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:34:35Z,twe4ked,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:38:59Z,mythmon,mythmon@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T21:43:35Z,afonsolage,lage.afonso@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T21:43:36Z,afonsolage,lage.afonso@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T21:43:37Z,afonsolage,lage.afonso@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T21:49:51Z,JonathanBrouwer,jonathantbrouwer@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:07:23Z,vitorenesduarte,vitorenesduarte@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:07:24Z,vitorenesduarte,vitorenesduarte@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:07:42Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:07:43Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T22:07:43Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:09:04Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T22:13:18Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:13:20Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:13:52Z,afd-bai,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:22:46Z,zbraniecki,zibi@braniecki.net https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:27:06Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T22:27:06Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:27:15Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:36:23Z,LAYGATOR,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T22:38:20Z,joseluis,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T22:45:10Z,extrawurst,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:03:24Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:07:25Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:12:20Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T23:12:22Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T23:30:03Z,arzg,aramisnoah@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T23:33:36Z,fmckeogh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T23:33:37Z,fmckeogh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T23:46:22Z,Dherse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:46:22Z,Dherse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:48:14Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:50:22Z,flosse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T23:50:24Z,flosse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T23:50:26Z,flosse,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:50:29Z,psidex,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-16T23:58:29Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-16T23:58:29Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-16T23:58:30Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T00:36:52Z,nordzilla,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T00:47:08Z,sigaloid,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T00:47:08Z,sigaloid,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T00:47:09Z,sigaloid,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T00:51:32Z,troutstick,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T00:55:29Z,sJJdGG,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T01:04:57Z,awoo-civ,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T01:07:56Z,zshift,zshift@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T01:12:30Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T01:45:36Z,Vurich,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T01:45:38Z,Vurich,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T01:59:14Z,f4bio,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T02:04:29Z,Imxset21,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T02:22:59Z,juancampa,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T02:28:45Z,Folyd,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T02:49:44Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T02:49:45Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T02:49:45Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T02:50:26Z,fosskers,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T03:06:07Z,Masynchin,masynchin@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T03:18:01Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T03:21:35Z,mikialex,18516340862@163.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T03:26:37Z,DesmondWillowbrook,sendtokartavya@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T03:29:57Z,Lynnesbian,lynne@bune.city https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T03:36:56Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T03:46:22Z,david0u0,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T03:49:14Z,kkysen,kkysen@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T04:26:09Z,eternaltyro,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T04:26:46Z,sudormrfbin,gokulps15@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T05:36:14Z,ttys3,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T05:42:35Z,aheart,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T06:03:30Z,neonmei,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T06:23:00Z,Dentrax,furkan.turkal@hotmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T06:27:45Z,Agrailag,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T06:34:37Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T06:38:39Z,sneedcat,basedsneedcat@proton.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T06:46:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T06:46:20Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T06:46:21Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:04:18Z,nicomem,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:07:32Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:07:33Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:10:10Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:31:32Z,Selicre,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:31:34Z,Genius3435,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:31:37Z,Genius3435,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T07:31:37Z,Genius3435,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T07:33:45Z,QVSorrow,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:36:26Z,pachi,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:37:39Z,Seppel3210,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:37:41Z,Seppel3210,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:41:31Z,JMLX42,jeanmarc.leroux@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:52:02Z,deities-online,deities.online@icloud.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T07:53:00Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T07:53:02Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T07:53:02Z,severen,severen.redwood@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T08:06:58Z,vitali2y,vitaliyy@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T08:10:56Z,Xiphoseer,hi@dseiler.eu https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T08:40:58Z,vascokk,vasco@vas.io https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T08:47:37Z,kneasle,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T09:21:40Z,5hir0kur0,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T09:41:02Z,joelpalmer,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T09:59:55Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T09:59:56Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T10:17:19Z,rokonio,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T10:28:32Z,iRebbok,irebbok@outlook.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T10:29:04Z,zyansheep,zyansheep@protonmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T10:29:04Z,zyansheep,zyansheep@protonmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T10:29:06Z,zyansheep,zyansheep@protonmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T10:39:50Z,rustatian,piashchynski.valery@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T10:56:07Z,m4dh0rs3,schoeps.benedikt@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T11:08:23Z,Gordon-F,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T11:28:23Z,hyperupcall,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T12:45:14Z,xjkdev,xjk2008@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:02:48Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:07:10Z,modwizcode,irides@irides.network https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T13:07:11Z,modwizcode,irides@irides.network https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T13:07:11Z,modwizcode,irides@irides.network https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:10:14Z,gijs-s,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:37:31Z,met4deu5,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:38:42Z,cbeuw,cbeuw.andy@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T13:44:08Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T13:44:09Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T13:44:09Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T14:05:30Z,soundslocke,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T14:19:46Z,thvdveld,thvdveld@vub.be https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T14:35:29Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T14:35:31Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-17T14:35:34Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T15:57:21Z,dannymcgee,dannymcgee@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T16:11:22Z,glittershark,github@gws.fyi https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T16:15:55Z,spaarmann,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T18:09:11Z,Kesanov,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T18:09:13Z,Kesanov,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-17T21:32:26Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-17T21:32:27Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T02:40:56Z,simonsan,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T02:40:57Z,simonsan,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-18T02:40:58Z,simonsan,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T06:12:27Z,abhijithgopal,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T06:12:27Z,abhijithgopal,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T07:57:24Z,AkiaCode,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T09:09:28Z,elahn,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T11:20:34Z,elkowar,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T12:10:29Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-18T12:10:31Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T12:10:32Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T14:49:51Z,Rejyr,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T14:49:52Z,Rejyr,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T16:16:06Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-18T16:16:07Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-18T16:16:08Z,gatoWololo,leija.this@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-18T20:59:22Z,LhKipp,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T06:01:31Z,mchlrhw,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-19T06:01:32Z,mchlrhw,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-19T06:01:33Z,mchlrhw,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T06:53:37Z,andresovela,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-19T06:53:51Z,andresovela,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-19T06:53:52Z,andresovela,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T07:16:15Z,huxi,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T08:44:55Z,izoslav,dev@izoslav.pl https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T13:03:07Z,pepyakin,s.pepyakin@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-19T22:54:47Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-19T22:54:48Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-19T22:54:48Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-19T23:51:49Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-20T00:37:51Z,Terkwood,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-20T00:37:53Z,Terkwood,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T00:37:54Z,Terkwood,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",ROCKET,2021-08-20T00:37:56Z,Terkwood,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T00:39:36Z,johnthagen,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T09:29:56Z,sundy-li,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T10:25:05Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T10:39:49Z,sanjitako,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-20T10:39:51Z,sanjitako,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-20T10:39:52Z,sanjitako,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-20T12:10:07Z,s0lst1ce,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-20T12:10:08Z,s0lst1ce,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-20T13:58:32Z,tyranron,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T13:58:33Z,tyranron,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-20T17:50:40Z,aaronjanse,aaron@ajanse.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-20T17:50:43Z,aaronjanse,aaron@ajanse.me https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-20T20:17:17Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-21T01:27:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-21T01:27:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-21T02:39:10Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-21T02:39:11Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-21T02:39:12Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",ROCKET,2021-08-21T02:39:14Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-21T06:42:58Z,mmalinin,malinin.work@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-21T10:04:50Z,feds01,alexander.fedotov.uk@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-21T10:05:29Z,feds01,alexander.fedotov.uk@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-08-21T10:05:37Z,Aankhen,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-23T03:53:21Z,Bauxitedev,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-23T06:46:48Z,wmw64,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-25T05:17:14Z,jk-gan,junkai@hey.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-25T18:18:49Z,annapapitto,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-25T22:16:22Z,CatCode79,andrea.postal@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-08-27T04:52:11Z,QuineDot,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-08-27T06:46:30Z,mendess,pedro.mendes.26@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-09-01T04:17:24Z,kaigedong,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-09-04T06:16:26Z,ahlinc,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HOORAY,2021-09-04T06:16:31Z,ahlinc,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-09-04T06:16:32Z,ahlinc,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",ROCKET,2021-09-04T06:16:33Z,ahlinc,NA https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",THUMBS_UP,2021-11-01T08:42:44Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/86532,MERGED,2021-06-22T02:11:33Z,2021-08-11T22:15:44Z,Make deleted code in a suggestion clearer,estebank,ccffcafd55e58f769d4b0efc0064bf65e76998e4,952,"Auto merge of #86532 - estebank:delete-suggestion-underline r=petrochenkov Make deleted code in a suggestion clearer Show suggestions that include deletions in a way similar to `diff`'s output. For changes that do not have deletions use `+` as an underline for additions and `~` as an underline for replacements. For multiline suggestions we now use `~` in the gutter to signal replacements and `+` to signal whole line replacements/additions. In all cases we now use color to highlight the specific spans and snippets.",HEART,2021-11-01T08:42:45Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/86533,MERGED,2021-06-22T02:24:32Z,2021-06-24T07:29:50Z,Support lowercase error codes in `--explain`,inquisitivecrystal,6b618c82ba6e124dbc84419e43670f702735b076,1,Rollup merge of #86533 - inquisitivecrystal:lower-case-error-explain r=petrochenkov Support lowercase error codes in `--explain` This enables `rustc --explain` to accept a lowercase error code. Thus for instance `rustc --explain e0573` would be valid after this change where before a user would have needed to do `rustc --explain E0573`. Although the upper case form of an error code is canonical the user may prefer the easier-to-type lowercase form and there's nothing to be gained by forcing them to type the upper case version. Resolves #86518.,HEART,2021-06-22T15:02:04Z,Skalman,NA https://github.com/rust-lang/rust/pull/86537,MERGED,2021-06-22T07:03:59Z,2021-06-22T14:54:03Z,Mark some edition tests as check-pass,inquisitivecrystal,00a7d5c08c03087f6b968ac641703a863294a1b0,11,Rollup merge of #86537 - inquisitivecrystal:mark-edition-tests-check-pass r=JohnTitor Mark some edition tests as check-pass ## Overview This helps with #62277. In short there are some tests that were marked as `build-pass` when it was unclear whether `check-pass` might be more appropriate. This PR marks some of those tests as `compile-pass` in addition to making some incidental formatting improvements. ## A brief explanation of why this is correct These tests fall into a few buckets. `src/test/ui/dyn-keyword/dyn-2015-edition-keyword-ident-lint.rs` `src/test/ui/dyn-keyword/dyn-2015-idents-in-decl-macros-unlinted.rs` `src/test/ui/dyn-keyword/dyn-2015-idents-in-macros-unlinted.rs` `src/test/ui/dyn-keyword/dyn-2015-no-warnings-without-lints.rs` `src/test/ui/dyn-keyword/issue-56327-dyn-trait-in-macro-is-okay.rs` These test a lint for a keyword added in a new edition and the corresponding changes in keyword rules. `src/test/ui/editions/edition-feature-ok.rs` This checks that a feature related to an edition transition is valid. `src/test/ui/editions/edition-imports-virtual-2015-ambiguity.rs` This checks that imports between editions work correctly. `src/test/ui/editions/edition-keywords-2015-2015-expansion.rs` `src/test/ui/editions/edition-keywords-2018-2015-expansion.rs` This checks the interaction between a change in keyword status over editions and macros. All of the things being tested come before linking and codegen so it is safe to use `check-pass` for them.,HEART,2021-06-22T09:59:48Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86554,CLOSED,2021-06-22T20:38:57Z,2021-07-08T06:46:42Z,"Add ""some"" as a doc alias for ""any"".",cuviper,NA,NA,NA,HEART,2021-06-23T13:03:00Z,joelgallant,code@joelgallant.io https://github.com/rust-lang/rust/pull/86554,CLOSED,2021-06-22T20:38:57Z,2021-07-08T06:46:42Z,"Add ""some"" as a doc alias for ""any"".",cuviper,NA,NA,NA,HEART,2021-06-23T13:30:03Z,tech6hutch,NA https://github.com/rust-lang/rust/pull/86568,MERGED,2021-06-23T05:22:20Z,2021-06-28T19:11:54Z,Don't dist miri or rust-analyzer on stable or beta.,ehuss,daa3ceb22bc63aa67c91af8939ac160757cad11e,1,"Rollup merge of #86568 - ehuss:dist-miri-stable r=Mark-Simulacrum Don't dist miri or rust-analyzer on stable or beta. This prevents miri and rust-analyzer from being built for ""dist"" or ""install"" on the stable/beta channels. It is a nightly-only tool and should not be included. Closes #86286",HEART,2021-06-23T06:55:51Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86568,MERGED,2021-06-23T05:22:20Z,2021-06-28T19:11:54Z,Don't dist miri or rust-analyzer on stable or beta.,ehuss,daa3ceb22bc63aa67c91af8939ac160757cad11e,1,"Rollup merge of #86568 - ehuss:dist-miri-stable r=Mark-Simulacrum Don't dist miri or rust-analyzer on stable or beta. This prevents miri and rust-analyzer from being built for ""dist"" or ""install"" on the stable/beta channels. It is a nightly-only tool and should not be included. Closes #86286",HEART,2021-06-23T10:31:16Z,ojeda,NA https://github.com/rust-lang/rust/pull/86573,MERGED,2021-06-23T14:40:15Z,2021-06-23T21:30:06Z,Bump expat to 2.4.1,Mark-Simulacrum,5a7834050f3a0ebcd117b4ddf0bc1e8459594309,1,Auto merge of #86573 - Mark-Simulacrum:expat-bump r=pietroalbini Bump expat to 2.4.1 Temporary fix as expat 2.3.0 is now renamed presumably due to https://github.com/libexpat/libexpat/blob/R_2_4_1/expat/Changes#L19. r? `@pietroalbini`,THUMBS_UP,2021-06-23T19:04:25Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/86574,MERGED,2021-06-23T16:01:51Z,2021-06-25T03:48:53Z,Don't lint :pat when re-parsing a macro from another crate.,m-ou-se,079aa837d205960592ef479387fb272cba16e2da,5,Auto merge of #86574 - m-ou-se:or-pattern-lint-fix r=petrochenkov Don't lint :pat when re-parsing a macro from another crate. `compile_macro` is used both when compiling the original definition in the crate that defines it and to compile the macro when loading it when compiling a crate that uses it. We should only emit lints in the first case. This adds a `is_definition: bool` to pass this information in so we don't warn about things that only concern the definition site. Fixes #86567,HEART,2021-06-23T17:16:17Z,rylev,NA https://github.com/rust-lang/rust/pull/86586,MERGED,2021-06-23T20:36:24Z,2021-06-26T10:52:14Z,Use HTTPS links where possible,Smittyvb,481971978fda83aa7cf1f1f3c80cfad822377cf2,66,Auto merge of #86586 - Smittyvb:https-everywhere r=petrochenkov Use HTTPS links where possible While looking at #86583 I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead in those cases I upgraded them to their new places (all of which used HTTPS),HEART,2021-06-23T21:11:05Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86586,MERGED,2021-06-23T20:36:24Z,2021-06-26T10:52:14Z,Use HTTPS links where possible,Smittyvb,481971978fda83aa7cf1f1f3c80cfad822377cf2,66,Auto merge of #86586 - Smittyvb:https-everywhere r=petrochenkov Use HTTPS links where possible While looking at #86583 I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead in those cases I upgraded them to their new places (all of which used HTTPS),HEART,2021-06-23T21:15:55Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/86586,MERGED,2021-06-23T20:36:24Z,2021-06-26T10:52:14Z,Use HTTPS links where possible,Smittyvb,481971978fda83aa7cf1f1f3c80cfad822377cf2,66,Auto merge of #86586 - Smittyvb:https-everywhere r=petrochenkov Use HTTPS links where possible While looking at #86583 I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead in those cases I upgraded them to their new places (all of which used HTTPS),HEART,2021-06-26T11:11:26Z,sthagen,NA https://github.com/rust-lang/rust/pull/86593,MERGED,2021-06-24T09:24:15Z,2021-08-02T04:59:11Z,Partially stabilize `const_slice_first_last`,jhpratt,77d568344f58e789000e43bafcd706f099d93de1,1,Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last r=m-ou-se Partially stabilize `const_slice_first_last` This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of. `@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api,THUMBS_UP,2021-06-24T09:25:46Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/86593,MERGED,2021-06-24T09:24:15Z,2021-08-02T04:59:11Z,Partially stabilize `const_slice_first_last`,jhpratt,77d568344f58e789000e43bafcd706f099d93de1,1,Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last r=m-ou-se Partially stabilize `const_slice_first_last` This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of. `@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api,THUMBS_UP,2021-07-05T13:52:42Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/86593,MERGED,2021-06-24T09:24:15Z,2021-08-02T04:59:11Z,Partially stabilize `const_slice_first_last`,jhpratt,77d568344f58e789000e43bafcd706f099d93de1,1,Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last r=m-ou-se Partially stabilize `const_slice_first_last` This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of. `@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api,THUMBS_UP,2021-07-15T18:33:27Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86593,MERGED,2021-06-24T09:24:15Z,2021-08-02T04:59:11Z,Partially stabilize `const_slice_first_last`,jhpratt,77d568344f58e789000e43bafcd706f099d93de1,1,Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last r=m-ou-se Partially stabilize `const_slice_first_last` This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of. `@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api,THUMBS_UP,2021-07-16T00:13:43Z,Skgland,NA https://github.com/rust-lang/rust/pull/86595,MERGED,2021-06-24T12:52:35Z,2021-07-25T21:42:00Z,Add support for custom allocator in `VecDeque`,a1phyr,9c25eb7aa3a71fb951564b0ddf131be59c2c951d,6,Auto merge of #86595 - a1phyr:allocator_api_for_vecdeque r=Amanieu Add support for custom allocator in `VecDeque` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. `@rustbot` modify labels: +A-allocators +T-libs,HOORAY,2021-06-27T10:58:06Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/86595,MERGED,2021-06-24T12:52:35Z,2021-07-25T21:42:00Z,Add support for custom allocator in `VecDeque`,a1phyr,9c25eb7aa3a71fb951564b0ddf131be59c2c951d,6,Auto merge of #86595 - a1phyr:allocator_api_for_vecdeque r=Amanieu Add support for custom allocator in `VecDeque` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. `@rustbot` modify labels: +A-allocators +T-libs,HOORAY,2021-07-29T03:02:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86595,MERGED,2021-06-24T12:52:35Z,2021-07-25T21:42:00Z,Add support for custom allocator in `VecDeque`,a1phyr,9c25eb7aa3a71fb951564b0ddf131be59c2c951d,6,Auto merge of #86595 - a1phyr:allocator_api_for_vecdeque r=Amanieu Add support for custom allocator in `VecDeque` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. `@rustbot` modify labels: +A-allocators +T-libs,HOORAY,2021-07-29T08:12:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86595,MERGED,2021-06-24T12:52:35Z,2021-07-25T21:42:00Z,Add support for custom allocator in `VecDeque`,a1phyr,9c25eb7aa3a71fb951564b0ddf131be59c2c951d,6,Auto merge of #86595 - a1phyr:allocator_api_for_vecdeque r=Amanieu Add support for custom allocator in `VecDeque` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. `@rustbot` modify labels: +A-allocators +T-libs,HOORAY,2021-07-29T13:08:57Z,tux3,NA https://github.com/rust-lang/rust/pull/86598,MERGED,2021-06-24T15:07:42Z,2021-07-04T22:23:07Z,Add examples to the various methods of `core::task::Poll`,yoshuawuyts,b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b,1,"Auto merge of #86598 - yoshuawuyts:poll-method-docs r=JohnTitor Add examples to the various methods of `core::task::Poll` This improves the documentation of the various methods of [`core::task::Poll`](https://doc.rust-lang.org/std/task/enum.Poll.html). These currently have fairly simple docs with no examples. This PR changes these methods to be closer to `core::option::Option` and adds usage examples (and importantly: tests!) to `Poll`'s methods. cc/ `@rust-lang/wg-async-foundations` ## Screenshots
View generated rustdoc page
",HEART,2021-06-24T15:31:12Z,taiki-e,NA https://github.com/rust-lang/rust/pull/86598,MERGED,2021-06-24T15:07:42Z,2021-07-04T22:23:07Z,Add examples to the various methods of `core::task::Poll`,yoshuawuyts,b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b,1,"Auto merge of #86598 - yoshuawuyts:poll-method-docs r=JohnTitor Add examples to the various methods of `core::task::Poll` This improves the documentation of the various methods of [`core::task::Poll`](https://doc.rust-lang.org/std/task/enum.Poll.html). These currently have fairly simple docs with no examples. This PR changes these methods to be closer to `core::option::Option` and adds usage examples (and importantly: tests!) to `Poll`'s methods. cc/ `@rust-lang/wg-async-foundations` ## Screenshots
View generated rustdoc page
",HEART,2021-06-24T15:36:07Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/86598,MERGED,2021-06-24T15:07:42Z,2021-07-04T22:23:07Z,Add examples to the various methods of `core::task::Poll`,yoshuawuyts,b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b,1,"Auto merge of #86598 - yoshuawuyts:poll-method-docs r=JohnTitor Add examples to the various methods of `core::task::Poll` This improves the documentation of the various methods of [`core::task::Poll`](https://doc.rust-lang.org/std/task/enum.Poll.html). These currently have fairly simple docs with no examples. This PR changes these methods to be closer to `core::option::Option` and adds usage examples (and importantly: tests!) to `Poll`'s methods. cc/ `@rust-lang/wg-async-foundations` ## Screenshots
View generated rustdoc page
",THUMBS_UP,2021-06-24T15:36:08Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/86598,MERGED,2021-06-24T15:07:42Z,2021-07-04T22:23:07Z,Add examples to the various methods of `core::task::Poll`,yoshuawuyts,b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b,1,"Auto merge of #86598 - yoshuawuyts:poll-method-docs r=JohnTitor Add examples to the various methods of `core::task::Poll` This improves the documentation of the various methods of [`core::task::Poll`](https://doc.rust-lang.org/std/task/enum.Poll.html). These currently have fairly simple docs with no examples. This PR changes these methods to be closer to `core::option::Option` and adds usage examples (and importantly: tests!) to `Poll`'s methods. cc/ `@rust-lang/wg-async-foundations` ## Screenshots
View generated rustdoc page
",THUMBS_UP,2021-06-24T21:10:56Z,zeenix,zeeshanak@gnome.org https://github.com/rust-lang/rust/pull/86619,MERGED,2021-06-25T12:25:50Z,2021-07-22T12:29:32Z,Profile incremental compilation hashing fingerprints ,rylev,f913a4fe901d6aeb84941fa06c17916d4e6d1dd7,3,Auto merge of #86619 - rylev:incr-hashing-profiling r=wesleywiser Profile incremental compilation hashing fingerprints Adds profiling instrumentation for the hashing of incremental compilation fingerprints per query. This will eventually feed into the `measureme` and `rustc-perf` infrastructure for tracking if computing hashes changes over time. TODOs: * [x] Address the FIXME where we are including node interning in the hash timing. * [ ] Update measureme/summarize to handle this new data: https://github.com/rust-lang/measureme/pull/166 * [ ] ~Update rustc-perf to handle the new data from measureme~ (will be done at a later time) r? `@ghost` cc `@michaelwoerister`,THUMBS_UP,2021-07-20T16:28:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86634,OPEN,2021-06-25T20:02:33Z,NA,Rework `Ipv6Addr::is_global` to check for global reachability rather than global scope,CDirkx,NA,NA,NA,THUMBS_UP,2022-05-04T15:26:17Z,elenaf9,elena.frank@protonmail.com https://github.com/rust-lang/rust/pull/86639,MERGED,2021-06-25T21:37:19Z,2021-07-08T06:46:46Z,Support lint tool names in rustc command line options,eholk,c2d3f5f7725a15fb3ad8ec88fbf89596f3ce9aea,7,Rollup merge of #86639 - eholk:lint-tool r=petrochenkov Support lint tool names in rustc command line options When rustc is running without a lint tool such as clippy enabled options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs such as `#![allow(clippy::foo)]` but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue. Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034. Fixes #86628.,THUMBS_UP,2021-06-26T01:25:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86644,MERGED,2021-06-26T11:58:04Z,2021-07-06T06:55:03Z,rustdoc: Replace `FakeDefId` with new `ItemId` type,Stupremee,9a27044f42ace9eb652781b53f598e25d4e7e918,20,"Auto merge of #86644 - Stupremee:replace-fakedefids-with-itemid r=jyn514 rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from #84707 `@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits normal ids and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no ""fake"" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also we need to represent the new item ids in the JSON backend somehow.",HEART,2021-06-26T14:27:35Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86644,MERGED,2021-06-26T11:58:04Z,2021-07-06T06:55:03Z,rustdoc: Replace `FakeDefId` with new `ItemId` type,Stupremee,9a27044f42ace9eb652781b53f598e25d4e7e918,20,"Auto merge of #86644 - Stupremee:replace-fakedefids-with-itemid r=jyn514 rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from #84707 `@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits normal ids and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no ""fake"" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also we need to represent the new item ids in the JSON backend somehow.",HEART,2021-07-02T16:28:12Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/86644,MERGED,2021-06-26T11:58:04Z,2021-07-06T06:55:03Z,rustdoc: Replace `FakeDefId` with new `ItemId` type,Stupremee,9a27044f42ace9eb652781b53f598e25d4e7e918,20,"Auto merge of #86644 - Stupremee:replace-fakedefids-with-itemid r=jyn514 rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from #84707 `@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits normal ids and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no ""fake"" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also we need to represent the new item ids in the JSON backend somehow.",HEART,2021-07-03T21:45:40Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86650,MERGED,2021-06-26T19:40:08Z,2021-06-30T13:42:59Z,Fix boldness (put it back where needed),GuillaumeGomez,5d34076975cd7661dca4e40e0c66a646a78ad091,4,"Auto merge of #86650 - GuillaumeGomez:fix-boldness r=Nemo157 Fix boldness (put it back where needed) I realized that I created a GUI test that wasn't run because it had "".rs"" extension instead of "".goml"" so I moved its content into `font-weight.goml` (since it was checking font weight).",HEART,2021-06-27T13:25:27Z,cynecx,NA https://github.com/rust-lang/rust/pull/86652,MERGED,2021-06-26T21:38:40Z,2021-07-01T12:03:45Z,Add support for leaf function frame pointer elimination,nagisa,dfd30d7b705f858603ef6d21bdb893297aea37ba,24,Rollup merge of #86652 - nagisa:nagisa/non-leaf-fp r=petrochenkov Add support for leaf function frame pointer elimination This PR adds ability for the target specifications to specify frame pointer emission type that's not just “always” or “whatever cg decides”. In particular there's a new mode that allows omission of the frame pointer for leaf functions (those that don't call any other functions). We then set this new mode for Aarch64-based Apple targets. Fixes #86196,THUMBS_UP,2021-07-01T12:24:30Z,hkratz,NA https://github.com/rust-lang/rust/pull/86655,MERGED,2021-06-27T01:55:22Z,2021-06-27T18:10:16Z,Make `fmt::Arguments::as_str` unstably const,jonas-schievink,9cdb2d3d59bad2843330535a41d0ebbb831fe57e,1,"Auto merge of #86655 - jonas-schievink:const-arguments-as-str r=kennytm Make `fmt::Arguments::as_str` unstably const Motivation: mostly to move ""panic!() in const contexts"" forward making use of `as_str` was mentioned in https://github.com/rust-lang/rust/issues/85194#issuecomment-852345377 and seems like the simplest way forward.",THUMBS_UP,2021-06-27T03:19:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86655,MERGED,2021-06-27T01:55:22Z,2021-06-27T18:10:16Z,Make `fmt::Arguments::as_str` unstably const,jonas-schievink,9cdb2d3d59bad2843330535a41d0ebbb831fe57e,1,"Auto merge of #86655 - jonas-schievink:const-arguments-as-str r=kennytm Make `fmt::Arguments::as_str` unstably const Motivation: mostly to move ""panic!() in const contexts"" forward making use of `as_str` was mentioned in https://github.com/rust-lang/rust/issues/85194#issuecomment-852345377 and seems like the simplest way forward.",THUMBS_UP,2021-06-27T17:18:29Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/86665,MERGED,2021-06-27T13:14:09Z,2021-07-13T06:59:41Z,Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck,FabianWolff,1f0db5e0a315a252946a9e52a76c73579da53dd0,30,Auto merge of #86665 - FabianWolff:layout-field-thir-unsafeck r=oli-obk Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck Since nobody has so far claimed Mutation- and BorrowOfLayoutConstrainedField in rust-lang/project-thir-unsafeck#7 I have taken the liberty of implementing them in thir-unsafeck. r? `@LeSeulArtichaut`,HEART,2021-06-27T14:39:57Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/86676,MERGED,2021-06-27T19:30:38Z,2021-07-17T20:23:58Z,Make expansions stable for incr. comp.,cjgillot,68511b574ffe019a5cb3e9fa92605f80d39167bc,27,Auto merge of #86676 - cjgillot:localexpn r=petrochenkov Make expansions stable for incr. comp. This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions: - the interned identifier `ExpnId` contains a `CrateNum` and a crate-local id; - bidirectional maps `ExpnHash <-> ExpnId` are setup; - incr. comp. on-disk cache saves and reconstructs expansions using their `ExpnHash`. I tried to use as many `LocalExpnId` as I could in the resolver code but I may have missed a few opportunities. All this will allow to use an `ExpnId` as a query key and to force this query without recomputing caller queries. For instance this will be used to implement #85999. r? `@petrochenkov`,THUMBS_UP,2021-06-27T20:47:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86676,MERGED,2021-06-27T19:30:38Z,2021-07-17T20:23:58Z,Make expansions stable for incr. comp.,cjgillot,68511b574ffe019a5cb3e9fa92605f80d39167bc,27,Auto merge of #86676 - cjgillot:localexpn r=petrochenkov Make expansions stable for incr. comp. This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions: - the interned identifier `ExpnId` contains a `CrateNum` and a crate-local id; - bidirectional maps `ExpnHash <-> ExpnId` are setup; - incr. comp. on-disk cache saves and reconstructs expansions using their `ExpnHash`. I tried to use as many `LocalExpnId` as I could in the resolver code but I may have missed a few opportunities. All this will allow to use an `ExpnId` as a query key and to force this query without recomputing caller queries. For instance this will be used to implement #85999. r? `@petrochenkov`,HOORAY,2021-06-28T11:10:39Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86676,MERGED,2021-06-27T19:30:38Z,2021-07-17T20:23:58Z,Make expansions stable for incr. comp.,cjgillot,68511b574ffe019a5cb3e9fa92605f80d39167bc,27,Auto merge of #86676 - cjgillot:localexpn r=petrochenkov Make expansions stable for incr. comp. This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions: - the interned identifier `ExpnId` contains a `CrateNum` and a crate-local id; - bidirectional maps `ExpnHash <-> ExpnId` are setup; - incr. comp. on-disk cache saves and reconstructs expansions using their `ExpnHash`. I tried to use as many `LocalExpnId` as I could in the resolver code but I may have missed a few opportunities. All this will allow to use an `ExpnId` as a query key and to force this query without recomputing caller queries. For instance this will be used to implement #85999. r? `@petrochenkov`,HOORAY,2021-06-30T20:42:30Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86676,MERGED,2021-06-27T19:30:38Z,2021-07-17T20:23:58Z,Make expansions stable for incr. comp.,cjgillot,68511b574ffe019a5cb3e9fa92605f80d39167bc,27,Auto merge of #86676 - cjgillot:localexpn r=petrochenkov Make expansions stable for incr. comp. This PR aims to make expansions stable for incr. comp. by using the same architecture as definitions: - the interned identifier `ExpnId` contains a `CrateNum` and a crate-local id; - bidirectional maps `ExpnHash <-> ExpnId` are setup; - incr. comp. on-disk cache saves and reconstructs expansions using their `ExpnHash`. I tried to use as many `LocalExpnId` as I could in the resolver code but I may have missed a few opportunities. All this will allow to use an `ExpnId` as a query key and to force this query without recomputing caller queries. For instance this will be used to implement #85999. r? `@petrochenkov`,THUMBS_UP,2021-07-22T15:49:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86689,MERGED,2021-06-28T14:50:22Z,2021-06-30T07:28:49Z,Only include lint in future_incompatible lint group if not an edition lint,rylev,51fd129ac12d5bfeca7d216c47b0e337bf13e0c2,3,Auto merge of #86689 - rylev:future-compat-lint-group r=nikomatsakis Only include lint in future_incompatible lint group if not an edition lint A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition. We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though. r? `@nikomatsakis`,THUMBS_UP,2021-06-28T14:54:44Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/86689,MERGED,2021-06-28T14:50:22Z,2021-06-30T07:28:49Z,Only include lint in future_incompatible lint group if not an edition lint,rylev,51fd129ac12d5bfeca7d216c47b0e337bf13e0c2,3,Auto merge of #86689 - rylev:future-compat-lint-group r=nikomatsakis Only include lint in future_incompatible lint group if not an edition lint A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition. We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though. r? `@nikomatsakis`,THUMBS_UP,2021-06-28T14:55:05Z,ehuss,NA https://github.com/rust-lang/rust/pull/86696,MERGED,2021-06-28T18:56:35Z,2021-07-26T14:42:18Z,Update RELEASES.md for 1.54.0,XAMPPRocky,fc24bcead1d401ae061538d011e4a319c4195b56,1,Auto merge of #86696 - rust-lang:relnotes-1.54.0 r=pietroalbini Update RELEASES.md for 1.54.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.54.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-06-28T21:47:58Z,ehuss,NA https://github.com/rust-lang/rust/pull/86696,MERGED,2021-06-28T18:56:35Z,2021-07-26T14:42:18Z,Update RELEASES.md for 1.54.0,XAMPPRocky,fc24bcead1d401ae061538d011e4a319c4195b56,1,Auto merge of #86696 - rust-lang:relnotes-1.54.0 r=pietroalbini Update RELEASES.md for 1.54.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.54.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-06-28T23:42:04Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/86696,MERGED,2021-06-28T18:56:35Z,2021-07-26T14:42:18Z,Update RELEASES.md for 1.54.0,XAMPPRocky,fc24bcead1d401ae061538d011e4a319c4195b56,1,Auto merge of #86696 - rust-lang:relnotes-1.54.0 r=pietroalbini Update RELEASES.md for 1.54.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.54.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-07-05T08:14:19Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/86696,MERGED,2021-06-28T18:56:35Z,2021-07-26T14:42:18Z,Update RELEASES.md for 1.54.0,XAMPPRocky,fc24bcead1d401ae061538d011e4a319c4195b56,1,Auto merge of #86696 - rust-lang:relnotes-1.54.0 r=pietroalbini Update RELEASES.md for 1.54.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.54.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-07-05T18:33:40Z,tschuett,NA https://github.com/rust-lang/rust/pull/86696,MERGED,2021-06-28T18:56:35Z,2021-07-26T14:42:18Z,Update RELEASES.md for 1.54.0,XAMPPRocky,fc24bcead1d401ae061538d011e4a319c4195b56,1,Auto merge of #86696 - rust-lang:relnotes-1.54.0 r=pietroalbini Update RELEASES.md for 1.54.0 ### [Rendered](https://github.com/rust-lang/rust/blob/relnotes-1.54.0/RELEASES.md) r? `@Mark-Simulacrum` cc `@rust-lang/release`,HEART,2021-07-31T03:40:15Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/86698,MERGED,2021-06-28T19:25:23Z,2021-07-18T13:11:40Z,Move OnDiskCache to rustc_query_impl.,cjgillot,18073052d8c3544ccb73effd289ed3acda0d66c0,15,Auto merge of #86698 - cjgillot:modc r=estebank Move OnDiskCache to rustc_query_impl. This should be the last remnant of the query implementation that was still in rustc_middle.,THUMBS_UP,2021-07-18T00:14:34Z,estebank,NA https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-06-28T20:13:28Z,bjorn3,NA https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-06-29T16:22:26Z,tmiasko,NA https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-07-01T14:06:05Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-07-08T14:13:37Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-07-29T03:26:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2021-08-05T11:32:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2022-01-13T23:59:54Z,mati865,NA https://github.com/rust-lang/rust/pull/86699,OPEN,2021-06-28T19:48:08Z,NA,Allow reifying intrinsics to `fn` pointers.,eddyb,NA,NA,NA,HEART,2022-03-28T06:29:15Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-28T20:13:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-28T20:53:41Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-28T22:16:27Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-29T10:33:46Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",THUMBS_UP,2021-06-29T10:33:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",ROCKET,2021-06-29T10:34:01Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-30T15:32:42Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-06-30T20:40:37Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-07-06T19:38:35Z,estebank,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-07-07T11:50:44Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",ROCKET,2021-07-07T11:50:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-07-20T11:45:19Z,oli-obk,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",ROCKET,2021-07-20T11:45:19Z,oli-obk,NA https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-08-16T16:51:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86700,MERGED,2021-06-28T19:55:12Z,2021-08-18T18:39:42Z,"Matthew's work on improving NLL's ""higher-ranked subtype error""s",lqd,3d0774d0dc98084d25d95cc1909a8051ebbd9cb1,63,"Auto merge of #86700 - lqd:matthews-nll-hrtb-errors r=nikomatsakis Matthew's work on improving NLL's ""higher-ranked subtype error""s This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374. These are a blocker to turning full NLLs on and doing some internal cleanups to remove some of the old region code. The goal is so `@nikomatsakis` can take a look at this early and I'll then do my best to help do the changes and followup work to land this work and move closer to turning off the migration mode. I've only updated the branch and made it compile removed a warning or two. r? `@nikomatsakis` (Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)",HOORAY,2021-08-19T00:04:22Z,camelid,NA https://github.com/rust-lang/rust/pull/86705,CLOSED,2021-06-29T01:02:47Z,2021-08-02T22:39:27Z,Nellshamrell/improve async error,nellshamrell,NA,NA,NA,THUMBS_UP,2021-06-29T09:47:51Z,HalfVoxel,NA https://github.com/rust-lang/rust/pull/86705,CLOSED,2021-06-29T01:02:47Z,2021-08-02T22:39:27Z,Nellshamrell/improve async error,nellshamrell,NA,NA,NA,THUMBS_UP,2021-06-29T15:14:23Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/86705,CLOSED,2021-06-29T01:02:47Z,2021-08-02T22:39:27Z,Nellshamrell/improve async error,nellshamrell,NA,NA,NA,THUMBS_UP,2021-06-30T21:59:16Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86705,CLOSED,2021-06-29T01:02:47Z,2021-08-02T22:39:27Z,Nellshamrell/improve async error,nellshamrell,NA,NA,NA,THUMBS_UP,2021-07-24T18:47:02Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86717,MERGED,2021-06-29T15:28:55Z,2021-07-07T06:12:14Z,Rename some Rust 2021 lints to better names ,rylev,7e95290caab37233eebc323351d353ecdb3ce782,69,Rollup merge of #86717 - rylev:rename r=nikomatsakis Rename some Rust 2021 lints to better names Based on conversation in https://github.com/rust-lang/rust/issues/85894. Rename a bunch of Rust 2021 related lints: Lints that are officially renamed because they are already in beta or stable: * `disjoint_capture_migration` => `rust_2021_incompatible_closure_captures` * `or_patterns_back_compat` => `rust_2021_incompatible_or_patterns` * `non_fmt_panic` => `non_fmt_panics` Lints that are renamed but don't require any back -compat work since they aren't yet in stable: * `future_prelude_collision` => `rust_2021_prelude_collisions` * `reserved_prefix` => `rust_2021_token_prefixes` Lints that have been discussed but that I did not rename: * ~`non_fmt_panic` and `bare_trait_object`: is making this plural worth the headache we might cause users?~ * `array_into_iter`: I'm unsure of a good name and whether bothering users with a name change is worth it. r? `@nikomatsakis`,THUMBS_UP,2021-07-02T20:27:27Z,jam1garner,jam@jam1.re https://github.com/rust-lang/rust/pull/86724,MERGED,2021-06-29T18:58:37Z,2021-06-30T05:01:59Z,Upgrade to indexmap 1.7 using hashbrown 0.11,cuviper,9af4bdeab0d971d61ea59a02923944fc80daafcc,1,Auto merge of #86724 - cuviper:indexmap-1.7 r=Mark-Simulacrum Upgrade to indexmap 1.7 using hashbrown 0.11,HOORAY,2021-07-01T09:14:10Z,bluss,NA https://github.com/rust-lang/rust/pull/86725,MERGED,2021-06-29T19:21:15Z,2021-06-29T23:40:08Z,Upgrade normalize.css to v8.0.1,JohnTitor,6d820866a27b1949e237be79b9c8c0145fe728b7,2,Auto merge of #86725 - JohnTitor:normalizecss-8 r=GuillaumeGomez Upgrade normalize.css to v8.0.1 Fixes #86629 this addresses #82548 and #82542 with tweaks. I expect that this changes the style *slightly* but shouldn't have any major changes. Here's some changes I observed I'd say they all are an improvement.
Before ![before 1](https://user-images.githubusercontent.com/25030997/123854746-0fc84800-d95a-11eb-8484-ea86dfe0ae14.png) ![before 2](https://user-images.githubusercontent.com/25030997/123854754-135bcf00-d95a-11eb-8cca-f49994629e08.png)
After ![after 1](https://user-images.githubusercontent.com/25030997/123854809-21115480-d95a-11eb-9dd2-0d3b9ca45edd.png) ![after 2](https://user-images.githubusercontent.com/25030997/123854818-22428180-d95a-11eb-83aa-fb5a698124f9.png)
r? `@jsha`,THUMBS_UP,2021-06-29T22:39:51Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-06-30T11:09:38Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-07-02T06:41:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-07-29T19:45:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-08-05T11:51:22Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,HOORAY,2021-08-06T19:46:37Z,Ewpratten,ewpratten@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-08-06T19:46:39Z,Ewpratten,ewpratten@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,THUMBS_UP,2021-08-14T16:27:33Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,THUMBS_UP,2021-09-05T06:30:18Z,jw,jw@elevenbits.com https://github.com/rust-lang/rust/pull/86735,MERGED,2021-06-30T01:06:02Z,2021-07-28T08:53:57Z,Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute,jhpratt,aea2e446f09b923d513013743b37b43fca7282dc,14,Auto merge of #86735 - jhpratt:rfc-3107 r=petrochenkov Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute This PR implements RFC 3107 which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.,ROCKET,2021-09-26T16:49:33Z,janriemer,NA https://github.com/rust-lang/rust/pull/86750,MERGED,2021-06-30T16:04:15Z,2021-07-01T03:49:50Z,Test cross-crate usage of `feature(const_trait_impl)`,fee1-dead,7714a9a0e347cc34c83bb0971ca918a550988c05,6,Rollup merge of #86750 - fee1-dead:impl-const-test r=jonas-schievink Test cross-crate usage of `feature(const_trait_impl)` This PR does two things: - Fixes metadata not encoded properly for functions in const trait impls. - Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled. AFAIK this means we can now constify some trait impls in the standard library 🎉 See #67792 for the tracking issue cc `@oli-obk`,HOORAY,2021-06-30T16:24:02Z,CDirkx,christiaan@dirkx.email https://github.com/rust-lang/rust/pull/86750,MERGED,2021-06-30T16:04:15Z,2021-07-01T03:49:50Z,Test cross-crate usage of `feature(const_trait_impl)`,fee1-dead,7714a9a0e347cc34c83bb0971ca918a550988c05,6,Rollup merge of #86750 - fee1-dead:impl-const-test r=jonas-schievink Test cross-crate usage of `feature(const_trait_impl)` This PR does two things: - Fixes metadata not encoded properly for functions in const trait impls. - Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled. AFAIK this means we can now constify some trait impls in the standard library 🎉 See #67792 for the tracking issue cc `@oli-obk`,HOORAY,2021-07-02T11:25:01Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/86750,MERGED,2021-06-30T16:04:15Z,2021-07-01T03:49:50Z,Test cross-crate usage of `feature(const_trait_impl)`,fee1-dead,7714a9a0e347cc34c83bb0971ca918a550988c05,6,Rollup merge of #86750 - fee1-dead:impl-const-test r=jonas-schievink Test cross-crate usage of `feature(const_trait_impl)` This PR does two things: - Fixes metadata not encoded properly for functions in const trait impls. - Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled. AFAIK this means we can now constify some trait impls in the standard library 🎉 See #67792 for the tracking issue cc `@oli-obk`,HOORAY,2021-07-03T10:40:09Z,usbalbin,NA https://github.com/rust-lang/rust/pull/86755,MERGED,2021-06-30T17:45:16Z,2021-07-01T03:49:50Z,alloc: `RawVec::shrink` can be in `no_global_oom_handling`.,ojeda,9e007e71ff02e53e5c44906d210201325b627f2a,1,Rollup merge of #86755 - ojeda:shrink r=Mark-Simulacrum alloc: `RawVec::shrink` can be in `no_global_oom_handling`. Found in https://github.com/Rust-for-Linux/linux/pull/402. Signed-off-by: Miguel Ojeda ,HOORAY,2021-06-30T18:38:52Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/86755,MERGED,2021-06-30T17:45:16Z,2021-07-01T03:49:50Z,alloc: `RawVec::shrink` can be in `no_global_oom_handling`.,ojeda,9e007e71ff02e53e5c44906d210201325b627f2a,1,Rollup merge of #86755 - ojeda:shrink r=Mark-Simulacrum alloc: `RawVec::shrink` can be in `no_global_oom_handling`. Found in https://github.com/Rust-for-Linux/linux/pull/402. Signed-off-by: Miguel Ojeda ,HOORAY,2021-07-03T02:40:48Z,yerke,NA https://github.com/rust-lang/rust/pull/86755,MERGED,2021-06-30T17:45:16Z,2021-07-01T03:49:50Z,alloc: `RawVec::shrink` can be in `no_global_oom_handling`.,ojeda,9e007e71ff02e53e5c44906d210201325b627f2a,1,Rollup merge of #86755 - ojeda:shrink r=Mark-Simulacrum alloc: `RawVec::shrink` can be in `no_global_oom_handling`. Found in https://github.com/Rust-for-Linux/linux/pull/402. Signed-off-by: Miguel Ojeda ,THUMBS_UP,2021-07-03T02:41:06Z,yerke,NA https://github.com/rust-lang/rust/pull/86755,MERGED,2021-06-30T17:45:16Z,2021-07-01T03:49:50Z,alloc: `RawVec::shrink` can be in `no_global_oom_handling`.,ojeda,9e007e71ff02e53e5c44906d210201325b627f2a,1,Rollup merge of #86755 - ojeda:shrink r=Mark-Simulacrum alloc: `RawVec::shrink` can be in `no_global_oom_handling`. Found in https://github.com/Rust-for-Linux/linux/pull/402. Signed-off-by: Miguel Ojeda ,ROCKET,2021-07-03T02:41:08Z,yerke,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T21:46:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T22:12:33Z,bugadani,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T22:26:18Z,est31,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T22:35:06Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T23:01:50Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-06-30T23:26:13Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T00:18:39Z,BigRedEye,mail@bigredeye.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T04:17:46Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T06:34:01Z,djc,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T07:20:13Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T10:47:45Z,Urgau,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T14:03:07Z,bluss,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T18:16:07Z,darksv,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-01T21:12:16Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T21:24:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T21:59:19Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-01T22:18:36Z,Hexawolf,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T01:03:26Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T07:09:41Z,aykxt,me@aykut.vip https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T08:09:22Z,Newbytee,newbie13xd@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-02T11:18:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T11:18:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T14:16:41Z,adwhit,adwhit@fastmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T15:40:03Z,cynecx,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-02T18:23:16Z,spaarmann,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-02T18:23:21Z,spaarmann,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-03T14:42:34Z,kaylynn234,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-03T20:31:55Z,varkor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-03T22:34:18Z,soerenmeier,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-05T06:49:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-05T06:49:47Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-05T09:00:39Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-05T10:37:03Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-05T21:57:24Z,mati865,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-06T02:15:36Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-06T20:32:52Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-06T21:02:45Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-06T21:02:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-10T01:02:16Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T01:39:53Z,mohe2015,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T15:01:11Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-17T16:30:00Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T17:14:19Z,aldanor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-17T17:14:19Z,aldanor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T20:03:50Z,Lokathor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-17T20:03:50Z,Lokathor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T20:20:55Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-17T21:15:16Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-17T21:15:17Z,poliorcetics,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T00:31:47Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T00:33:08Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T00:33:09Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T01:15:18Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T01:15:18Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T01:36:15Z,ColdIce1605,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T01:36:16Z,ColdIce1605,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T01:41:41Z,clatour,chandler.latour@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T01:48:30Z,rcarson3,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T01:48:32Z,rcarson3,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T03:55:59Z,Kryptos-FR,nico@fragcolor.xyz https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-18T05:50:04Z,lzralbu,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T06:14:57Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T06:14:58Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T07:24:38Z,Voultapher,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T07:40:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T07:40:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T10:01:45Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T10:01:47Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T10:59:28Z,Cyber28,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T11:03:35Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T11:19:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-18T11:19:29Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T11:19:32Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T13:06:12Z,OnurKader,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T14:07:24Z,malobre,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-18T14:40:28Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-18T16:37:11Z,bogeholm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T17:24:19Z,edgarogh,dev@edgar.bzh https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T17:24:22Z,edgarogh,dev@edgar.bzh https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T18:41:23Z,icewind1991,robin@icewind.nl https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T18:55:57Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-18T20:09:04Z,simdimdim,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-18T20:09:15Z,simdimdim,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-18T20:09:16Z,simdimdim,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-19T05:30:35Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-19T13:25:06Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-20T13:50:43Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-20T13:59:22Z,clarkmoody,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-20T16:38:13Z,apppppppple,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-21T15:31:45Z,mrtnzlml,mrtnzlml+github@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-21T15:31:48Z,mrtnzlml,mrtnzlml+github@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-21T15:31:51Z,mrtnzlml,mrtnzlml+github@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-22T03:05:09Z,cabralski,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-22T03:05:10Z,cabralski,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-22T03:05:10Z,cabralski,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-22T06:04:38Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-22T06:04:38Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-22T06:04:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-22T07:22:17Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-22T12:19:23Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-22T18:04:59Z,tux3,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-22T18:05:01Z,tux3,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-22T18:05:09Z,tux3,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-22T21:16:27Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-23T02:15:28Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-23T03:03:19Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-23T03:03:19Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-23T05:03:23Z,kkocdko,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-23T09:58:04Z,adamreichold,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-23T13:57:29Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-23T18:08:30Z,ahrvoje,ahrvoje@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-24T04:18:02Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-24T04:18:07Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-24T04:18:08Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-25T14:03:44Z,edg-l,git@edgarluque.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-25T14:27:53Z,ritchie46,ritchie46@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-30T00:58:12Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-30T00:58:13Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-30T01:13:48Z,asdrubalini,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-30T05:49:17Z,BudiNverse,me@inve.rs https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-30T16:32:52Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-07-30T16:32:52Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-07-30T16:32:53Z,weihanglo,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-07-30T18:32:00Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-08-03T17:33:34Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-08-30T04:07:24Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-08-31T06:54:26Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-02T18:48:29Z,tmandry,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-04T16:53:41Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-07T00:07:37Z,cole-miller,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-08T07:07:22Z,andrewgazelka,andrew.gazelka@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-08T07:07:23Z,andrewgazelka,andrew.gazelka@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-08T15:39:45Z,andrewgazelka,andrew.gazelka@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T10:40:46Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T10:40:47Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T15:10:12Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T15:14:40Z,awulkan,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T15:21:56Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T15:21:56Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T15:21:57Z,zohnannor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T15:49:38Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T16:06:37Z,KylePDavis,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T16:15:01Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T16:15:02Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T16:15:03Z,rye,kristofer.rye@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T16:24:54Z,floatingatoll,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T16:32:40Z,inashivb,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T16:42:27Z,jojva,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T16:42:28Z,jojva,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T16:59:49Z,Patix0331,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T17:09:10Z,lebensterben,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T17:46:09Z,lnicola,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T17:53:35Z,mvelbaum,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T18:22:07Z,mdedetrich,mdedetrich@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T18:22:08Z,mdedetrich,mdedetrich@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T18:51:39Z,MarcoLugo,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T19:14:47Z,adrian5,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T19:55:57Z,anthonyjchriste,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T19:58:23Z,worstpractice,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T19:58:23Z,worstpractice,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T19:58:24Z,worstpractice,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T20:23:02Z,brainstorm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-09T20:23:04Z,brainstorm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T20:23:04Z,brainstorm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T20:48:43Z,Eugeny,inbox@null.page https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T20:48:46Z,Eugeny,inbox@null.page https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T21:24:52Z,arecvlohe,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T21:37:33Z,nnmm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T21:37:38Z,nnmm,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-09T21:44:56Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-09T22:13:45Z,kevinji,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-10T01:18:23Z,lopopolo,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-10T06:05:23Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-10T06:42:41Z,idMysteries,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-10T14:38:20Z,pierrechevalier83,pierrechevalier83@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-10T14:38:26Z,pierrechevalier83,pierrechevalier83@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-10T18:05:39Z,coderaiser,mnemonic.enemy@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-10T18:05:42Z,coderaiser,mnemonic.enemy@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-10T18:05:47Z,coderaiser,mnemonic.enemy@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-11T15:00:16Z,Enealor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-11T15:21:09Z,abhikjain360,abhik@abhikjain.xyz https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-11T20:43:37Z,Yura52,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-12T02:59:19Z,FulgurIgor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-12T02:59:20Z,FulgurIgor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-12T02:59:20Z,FulgurIgor,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-12T18:23:44Z,markusschaber,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-13T04:54:55Z,iago-lito,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-13T04:54:56Z,iago-lito,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-13T11:38:12Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-13T11:38:13Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-13T11:38:14Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-13T14:18:07Z,stefnotch,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-13T15:33:02Z,bczhc,bczhc0@126.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-15T20:19:19Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-15T20:19:19Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-15T20:19:20Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-16T07:55:19Z,JHenneberg,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-16T07:55:20Z,JHenneberg,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-16T07:55:21Z,JHenneberg,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-17T21:52:06Z,johnthagen,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-18T05:21:58Z,redgvin,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-09-28T05:45:29Z,jeanrick,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-09-28T05:45:30Z,jeanrick,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-09-28T05:45:31Z,jeanrick,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-10-07T15:15:08Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2021-10-20T15:19:48Z,xlxs4,xlxs4@pm.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2021-10-20T15:19:49Z,xlxs4,xlxs4@pm.me https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-11-24T08:51:41Z,ibENPC,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-12-01T04:33:25Z,faptc,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2021-12-04T00:50:29Z,Roms1383,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-01-23T21:53:14Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-02-05T10:15:14Z,lokyhark,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-02-17T17:26:51Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-03-20T13:45:41Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2022-03-20T13:45:42Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",ROCKET,2022-04-16T04:14:34Z,toddmath,tmatheson11186@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-04-16T04:14:41Z,toddmath,tmatheson11186@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2022-04-16T04:14:47Z,toddmath,tmatheson11186@gmail.com https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HOORAY,2022-05-31T21:33:05Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/86761,MERGED,2021-06-30T21:44:32Z,2021-07-17T15:26:26Z,Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm.,Alexhuszagh,f502bd3abd12111bbfae0974db018c165a977c0e,43,"Auto merge of #86761 - Alexhuszagh:master r=estebank Update Rust Float-Parsing Algorithms to use the Eisel-Lemire algorithm. # Summary Rust although it implements a correct float parser has major performance issues in float parsing. Even for common floats the performance can be 3-10x [slower](https://arxiv.org/pdf/2101.11408.pdf) than external libraries such as [lexical](https://github.com/Alexhuszagh/rust-lexical) and [fast-float-rust](https://github.com/aldanor/fast-float-rust). Recently major advances in float-parsing algorithms have been developed by Daniel Lemire along with others and implement a fast performant and correct float parser with speeds up to 1200 MiB/s on Apple's M1 architecture for the [canada](https://github.com/lemire/simple_fastfloat_benchmark/blob/0e2b5d163d4074cc0bde2acdaae78546d6e5c5f1/data/canada.txt) dataset 10x faster than Rust's 130 MiB/s. In addition [edge-cases](https://github.com/rust-lang/rust/issues/85234) in Rust's [dec2flt](https://github.com/rust-lang/rust/tree/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt) algorithm can lead to over a 1600x slowdown relative to efficient algorithms. This is due to the use of Clinger's correct but slow [AlgorithmM and Bellepheron](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.4152&rep=rep1&type=pdf) which have been improved by faster big-integer algorithms and the Eisel-Lemire algorithm respectively. Finally this algorithm provides substantial improvements in the number of floats the Rust core library can parse. Denormal floats with a large number of digits cannot be parsed due to use of the `Big32x40` which simply does not have enough digits to round a float correctly. Using a custom decimal class with much simpler logic we can parse all valid decimal strings of any digit count. ```rust // Issue in Rust's dec2fly. ""2.47032822920623272088284396434110686182e-324"".parse::(); // Err(ParseFloatError { kind: Invalid }) ``` # Solution This pull request implements the Eisel-Lemire algorithm modified from [fast-float-rust](https://github.com/aldanor/fast-float-rust) (which is licensed under Apache 2.0/MIT) along with numerous modifications to make it more amenable to inclusion in the Rust core library. The following describes both features in fast-float-rust and improvements in fast-float-rust for inclusion in core. **Documentation** Extensive documentation has been added to ensure the code base may be maintained by others which explains the algorithms as well as various associated constants and routines. For example two seemingly magical constants include documentation to describe how they were derived as follows: ```rust // Round-to-even only happens for negative values of q // when q ≥ −4 in the 64-bit case and when q ≥ −17 in // the 32-bitcase. // // When q ≥ 0 we have that 5^q ≤ 2m+1. In the 64-bit case we // have 5^q ≤ 2m+1 ≤ 2^54 or q ≤ 23. In the 32-bit case we have // 5^q ≤ 2m+1 ≤ 2^25 or q ≤ 10. // // When q < 0 we have w ≥ (2m+1)×5^−q. We must have that w < 2^64 // so (2m+1)×5^−q < 2^64. We have that 2m+1 > 2^53 (64-bit case) // or 2m+1 > 2^24 (32-bit case). Hence we must have 2^53×5^−q < 2^64 // (64-bit) and 2^24×5^−q < 2^64 (32-bit). Hence we have 5^−q < 2^11 // or q ≥ −4 (64-bit case) and 5^−q < 2^40 or q ≥ −17 (32-bitcase). // // Thus we have that we only need to round ties to even when // we have that q ∈ [−4 23](in the 64-bit case) or q∈[−17 10] // (in the 32-bit case). In both cases the power of five(5^|q|) // fits in a 64-bit word. const MIN_EXPONENT_ROUND_TO_EVEN: i32; const MAX_EXPONENT_ROUND_TO_EVEN: i32; ``` This ensures maintainability of the code base. **Improvements for Disguised Fast-Path Cases** The fast path in float parsing algorithms attempts to use native machine floats to represent both the significant digits and the exponent which is only possible if both can be exactly represented without rounding. In practice this means that the significant digits must be 53-bits or less and the then exponent must be in the range `[-22 22]` (for an f64). This is similar to the existing dec2flt implementation. However disguised fast-path cases exist where there are few significant digits and an exponent above the valid range such as `1.23e25`. In this case powers-of-10 may be shifted from the exponent to the significant digits discussed at length in https://github.com/rust-lang/rust/issues/85198. **Digit Parsing Improvements** Typically integers are parsed from string 1-at-a-time requiring unnecessary multiplications which can slow down parsing. An approach to parse 8 digits at a time using only 3 multiplications is described in length [here](https://johnnylee-sde.github.io/Fast-numeric-string-to-int/). This leads to significant performance improvements and is implemented for both big and little-endian systems. **Unsafe Changes** Relative to fast-float-rust this library makes less use of unsafe functionality and clearly documents it. This includes the refactoring and documentation of numerous unsafe methods undesirably marked as safe. The original code would look something like this which is deceptively marked as safe for unsafe functionality. ```rust impl AsciiStr { #[inline] pub fn step_by(&mut self n: usize) -> &mut Self { unsafe { self.ptr = self.ptr.add(n) }; self } } ... #[inline] fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { // the first character is 'e'/'E' and scientific mode is enabled let start = *s; s.step(); ... } ``` The new code clearly documents safety concerns and does not mark unsafe functionality as safe leading to better safety guarantees. ```rust impl AsciiStr { /// Advance the view by n advancing it in-place to (n..). pub unsafe fn step_by(&mut self n: usize) -> &mut Self { // SAFETY: same as step_by safe as long n is less than the buffer length self.ptr = unsafe { self.ptr.add(n) }; self } } ... /// Parse the scientific notation component of a float. fn parse_scientific(s: &mut AsciiStr<'_>) -> i64 { let start = *s; // SAFETY: the first character is 'e'/'E' and scientific mode is enabled unsafe { s.step(); } ... } ``` This allows us to trivially demonstrate the new implementation of dec2flt is safe. **Inline Annotations Have Been Removed** In the previous implementation of dec2flt inline annotations exist practically nowhere in the entire module. Therefore these annotations have been removed which mostly does not impact [performance](https://github.com/aldanor/fast-float-rust/issues/15#issuecomment-864485157). **Fixed Correctness Tests** Numerous compile errors in `src/etc/test-float-parse` were present due to deprecation of `time.clock()` as well as the crate dependencies with `rand`. The tests have therefore been reworked as a [crate](https://github.com/Alexhuszagh/rust/tree/master/src/etc/test-float-parse) and any errors in `runtests.py` have been patched. **Undefined Behavior** An implementation of `check_len` which relied on undefined behavior (in fast-float-rust) has been refactored to ensure that the behavior is well-defined. The original code is as follows: ```rust #[inline] pub fn check_len(&self n: usize) -> bool { unsafe { self.ptr.add(n) <= self.end } } ``` And the new implementation is as follows: ```rust /// Check if the slice at least `n` length. fn check_len(&self n: usize) -> bool { n <= self.as_ref().len() } ``` Note that this has since been fixed in [fast-float-rust](https://github.com/aldanor/fast-float-rust/pull/29). **Inferring Binary Exponents** Rather than explicitly store binary exponents this new implementation infers them from the decimal exponent reducing the amount of static storage required. This removes the requirement to store [611 i16s](https://github.com/rust-lang/rust/blob/868c702d0c9a471a28fb55f0148eb1e3e8b1dcc5/library/core/src/num/dec2flt/table.rs#L8). # Code Size The code size for all optimizations does not considerably change relative to before for stripped builds however it is **significantly** smaller prior to stripping the resulting binaries. These binary sizes were calculated on x86_64-unknown-linux-gnu. **new** Using rustc version 1.55.0-dev. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|400k|300K 1|396k|292K 2|392k|292K 3|392k|296K s|396k|292K z|396k|292K **old** Using rustc version 1.53.0-nightly. opt-level|size|size(stripped) |:-:|:-:|:-:| 0|3.2M|304K 1|3.2M|292K 2|3.1M|284K 3|3.1M|284K s|3.1M|284K z|3.1M|284K # Correctness The dec2flt implementation passes all of Rust's unittests and comprehensive float parsing tests along with numerous other tests such as Nigel Toa's comprehensive float [tests](https://github.com/nigeltao/parse-number-fxx-test-data) and Hrvoje Abraham [strtod_tests](https://github.com/ahrvoje/numerics/blob/master/strtod/strtod_tests.toml). Therefore it is unlikely that this algorithm will incorrectly round parsed floats. # Issues Addressed This will fix and close the following issues: - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15",HEART,2022-05-31T21:33:06Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/86775,MERGED,2021-07-01T10:48:10Z,2021-07-02T00:16:04Z,Test for const trait impls behind feature gates,fee1-dead,4262598dd4fd7658b2906b94bb784fcab9b2fe72,8,Rollup merge of #86775 - fee1-dead:impl-const-test r=jonas-schievink Test for const trait impls behind feature gates - Make the previous cross-crate tests use revisions instead of being separate files - Added test for gating const trait impls. cc ``@oli-obk`` ``@jonas-schievink``,HOORAY,2021-07-03T10:42:49Z,usbalbin,NA https://github.com/rust-lang/rust/pull/86778,MERGED,2021-07-01T11:33:55Z,2021-07-03T18:53:42Z,Avoid byte to char position conversions in `is_multiline`,tmiasko,96859dbaf6229f131fbd427a32aaa95d4f9cb132,1,Auto merge of #86778 - tmiasko:fast-multiline r=davidtwco Avoid byte to char position conversions in `is_multiline` Converting a byte position into a char position is currently linear in the number of multibyte characters in the source code. Avoid it when checking if a range spans across lines. This makes it feasible to compile source files with a large number of multibyte characters.,HEART,2021-07-08T09:15:05Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/86778,MERGED,2021-07-01T11:33:55Z,2021-07-03T18:53:42Z,Avoid byte to char position conversions in `is_multiline`,tmiasko,96859dbaf6229f131fbd427a32aaa95d4f9cb132,1,Auto merge of #86778 - tmiasko:fast-multiline r=davidtwco Avoid byte to char position conversions in `is_multiline` Converting a byte position into a char position is currently linear in the number of multibyte characters in the source code. Avoid it when checking if a range spans across lines. This makes it feasible to compile source files with a large number of multibyte characters.,HEART,2021-07-08T17:17:58Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86794,MERGED,2021-07-01T22:16:25Z,2021-07-05T21:52:36Z,Stabilize `Seek::rewind()`,inquisitivecrystal,2bc7d4d70acc2fb317c26600e59094c510ac528b,2,Rollup merge of #86794 - inquisitivecrystal:seek-rewind r=m-ou-se Stabilize `Seek::rewind()` This stabilizes `Seek::rewind`. It seemed to fit into one of the existing tests so I extended that test rather than adding a new one. Closes #85149.,HOORAY,2021-07-05T11:06:25Z,de-vri-es,maarten@de-vri.es https://github.com/rust-lang/rust/pull/86794,MERGED,2021-07-01T22:16:25Z,2021-07-05T21:52:36Z,Stabilize `Seek::rewind()`,inquisitivecrystal,2bc7d4d70acc2fb317c26600e59094c510ac528b,2,Rollup merge of #86794 - inquisitivecrystal:seek-rewind r=m-ou-se Stabilize `Seek::rewind()` This stabilizes `Seek::rewind`. It seemed to fit into one of the existing tests so I extended that test rather than adding a new one. Closes #85149.,HOORAY,2021-07-06T17:37:47Z,ijackson,ijackson@chiark.greenend.org.uk https://github.com/rust-lang/rust/pull/86797,MERGED,2021-07-02T00:12:44Z,2021-07-02T14:23:37Z,Stabilize `Bound::cloned()`,inquisitivecrystal,cd3a48fdb650f6ce7c6c8a31d2136073fc3338f5,3,Rollup merge of #86797 - inquisitivecrystal:bound-cloned r=jyn514 Stabilize `Bound::cloned()` This PR stabilizes the function `Bound::cloned()`. Closes #61356.,HEART,2021-07-02T15:18:12Z,glittershark,github@gws.fyi https://github.com/rust-lang/rust/pull/86799,MERGED,2021-07-02T02:05:12Z,2021-07-03T13:23:28Z,add owned locked stdio handles,tlyu,a8b8558f083d86247ef3260ebb4f97b276cdbf73,3,Auto merge of #86799 - tlyu:stdio-locked r=joshtriplett add owned locked stdio handles Add stderr_locked stdin_locked and stdout_locked free functions to obtain owned locked stdio handles in a single step. Also add into_lock methods to consume a stdio handle and return an owned lock. These methods will make it easier to use locked stdio handles without having to deal with lifetime problems or keeping bindings to the unlocked handles around. Fixes #85383; enables #86412. r? `@joshtriplett` `@rustbot` label +A-io +C-enhancement +D-newcomer-roadblock +T-libs-api,THUMBS_UP,2021-07-03T11:41:59Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86812,MERGED,2021-07-02T15:23:52Z,2021-07-08T06:46:45Z,Recover from `&dyn mut ...` parse errors,FabianWolff,165b520b89e9e2f27442a3af793c6d65e76e0981,3,Rollup merge of #86812 - FabianWolff:recover-dyn-mut r=petrochenkov Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!` `(` `;` `=` `?` `for` lifetime or path found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However especially for beginners I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes I get a help message and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```,THUMBS_UP,2021-07-02T15:36:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86812,MERGED,2021-07-02T15:23:52Z,2021-07-08T06:46:45Z,Recover from `&dyn mut ...` parse errors,FabianWolff,165b520b89e9e2f27442a3af793c6d65e76e0981,3,Rollup merge of #86812 - FabianWolff:recover-dyn-mut r=petrochenkov Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!` `(` `;` `=` `?` `for` lifetime or path found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However especially for beginners I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes I get a help message and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```,THUMBS_UP,2021-07-03T20:39:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86812,MERGED,2021-07-02T15:23:52Z,2021-07-08T06:46:45Z,Recover from `&dyn mut ...` parse errors,FabianWolff,165b520b89e9e2f27442a3af793c6d65e76e0981,3,Rollup merge of #86812 - FabianWolff:recover-dyn-mut r=petrochenkov Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!` `(` `;` `=` `?` `for` lifetime or path found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However especially for beginners I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes I get a help message and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```,THUMBS_UP,2021-07-15T21:00:49Z,lukechu10,NA https://github.com/rust-lang/rust/pull/86812,MERGED,2021-07-02T15:23:52Z,2021-07-08T06:46:45Z,Recover from `&dyn mut ...` parse errors,FabianWolff,165b520b89e9e2f27442a3af793c6d65e76e0981,3,Rollup merge of #86812 - FabianWolff:recover-dyn-mut r=petrochenkov Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!` `(` `;` `=` `?` `for` lifetime or path found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However especially for beginners I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes I get a help message and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```,THUMBS_UP,2021-07-16T02:15:46Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/86812,MERGED,2021-07-02T15:23:52Z,2021-07-08T06:46:45Z,Recover from `&dyn mut ...` parse errors,FabianWolff,165b520b89e9e2f27442a3af793c6d65e76e0981,3,Rollup merge of #86812 - FabianWolff:recover-dyn-mut r=petrochenkov Recover from `&dyn mut ...` parse errors Consider this example: ```rust fn main() { let r: &dyn mut Trait; } ``` This currently leads to: ``` error: expected one of `!` `(` `;` `=` `?` `for` lifetime or path found keyword `mut` --> src/main.rs:2:17 | 2 | let r: &dyn mut Trait; | ^^^ expected one of 8 possible tokens error: aborting due to previous error ``` However especially for beginners I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes I get a help message and the parser even recovers: ``` error: `mut` must precede `dyn` --> test.rs:2:12 | 2 | let r: &dyn mut Trait; | ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn` error[E0405]: cannot find trait `Trait` in this scope --> test.rs:2:21 | 2 | let r: &dyn mut Trait; | ^^^^^ not found in this scope error: aborting due to 2 previous errors ```,THUMBS_UP,2021-07-18T20:09:40Z,dobrakmato,dobrakmato+gh@gmail.com https://github.com/rust-lang/rust/pull/86814,MERGED,2021-07-02T16:31:39Z,2021-07-18T10:42:23Z,Recover from a misplaced inner doc comment,Aaron1011,469935f7a46e1e3f33b2c70919c70570acaeeed7,3,Rollup merge of #86814 - Aaron1011:inner-doc-recover r=estebank Recover from a misplaced inner doc comment Fixes #86781,HEART,2021-07-08T11:54:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86816,CLOSED,2021-07-02T17:59:17Z,2021-07-02T21:12:19Z,Optimize and improve the proc_macro RPC interface for cross-thread execution,mystor,NA,NA,NA,ROCKET,2021-07-02T18:04:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/86816,CLOSED,2021-07-02T17:59:17Z,2021-07-02T21:12:19Z,Optimize and improve the proc_macro RPC interface for cross-thread execution,mystor,NA,NA,NA,ROCKET,2022-07-10T03:42:40Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/86821,MERGED,2021-07-02T20:37:20Z,2021-07-03T01:42:11Z,[beta] backports,cuviper,0fa28ce074ef8c458103391d17ad305ed65a1aa2,23,"Auto merge of #86821 - cuviper:beta-next r=Mark-Simulacrum [beta] backports - rustfmt: load nested out-of-line mods correctly #86424 - Re-add support for parsing (and pretty-printing) inner-attributes in match body #85193 - Revert ""List trait impls before methods from deref in the sidebar ..."" #86564 - Revert ""Don't load all extern crates unconditionally"" #85749 r? `@Mark-Simulacrum`",THUMBS_UP,2021-07-02T23:03:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86823,MERGED,2021-07-02T21:23:05Z,2021-07-08T12:25:50Z,Optimize unchecked indexing into chunks and chunks_mut,the8472,0cd0709f19d316c4796fa71c5f52c8612a5f3771,1,Auto merge of #86823 - the8472:opt-chunk-tra r=kennytm Optimize unchecked indexing into chunks and chunks_mut Fixes #53340 ``` # BEFORE $ rustc +nightly -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 3 177.03 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 006 page-faults # 0.310 M/sec 13 092 199 322 cycles # 4.121 GHz (83.29%) 384 543 475 stalled-cycles-frontend # 2.94% frontend cycles idle (83.35%) 7 414 280 722 stalled-cycles-backend # 56.63% backend cycles idle (83.38%) 50 493 980 662 instructions # 3.86 insn per cycle # 0.15 stalled cycles per insn (83.29%) 6 625 375 297 branches # 2085.396 M/sec (83.38%) 3 087 652 branch-misses # 0.05% of all branches (83.31%) 3.178079469 seconds time elapsed 2.327156000 seconds user 0.762041000 seconds sys # AFTER $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 2 705.76 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 005 page-faults # 0.364 M/sec 11 156 763 039 cycles # 4.123 GHz (83.26%) 342 198 882 stalled-cycles-frontend # 3.07% frontend cycles idle (83.37%) 6 486 263 637 stalled-cycles-backend # 58.14% backend cycles idle (83.37%) 40 553 476 617 instructions # 3.63 insn per cycle # 0.16 stalled cycles per insn (83.37%) 6 668 429 113 branches # 2464.532 M/sec (83.37%) 3 099 636 branch-misses # 0.05% of all branches (83.26%) 2.706725288 seconds time elapsed 1.782083000 seconds user 0.848424000 seconds sys ```,ROCKET,2021-07-04T08:56:26Z,bluss,NA https://github.com/rust-lang/rust/pull/86823,MERGED,2021-07-02T21:23:05Z,2021-07-08T12:25:50Z,Optimize unchecked indexing into chunks and chunks_mut,the8472,0cd0709f19d316c4796fa71c5f52c8612a5f3771,1,Auto merge of #86823 - the8472:opt-chunk-tra r=kennytm Optimize unchecked indexing into chunks and chunks_mut Fixes #53340 ``` # BEFORE $ rustc +nightly -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 3 177.03 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 006 page-faults # 0.310 M/sec 13 092 199 322 cycles # 4.121 GHz (83.29%) 384 543 475 stalled-cycles-frontend # 2.94% frontend cycles idle (83.35%) 7 414 280 722 stalled-cycles-backend # 56.63% backend cycles idle (83.38%) 50 493 980 662 instructions # 3.86 insn per cycle # 0.15 stalled cycles per insn (83.29%) 6 625 375 297 branches # 2085.396 M/sec (83.38%) 3 087 652 branch-misses # 0.05% of all branches (83.31%) 3.178079469 seconds time elapsed 2.327156000 seconds user 0.762041000 seconds sys # AFTER $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 2 705.76 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 005 page-faults # 0.364 M/sec 11 156 763 039 cycles # 4.123 GHz (83.26%) 342 198 882 stalled-cycles-frontend # 3.07% frontend cycles idle (83.37%) 6 486 263 637 stalled-cycles-backend # 58.14% backend cycles idle (83.37%) 40 553 476 617 instructions # 3.63 insn per cycle # 0.16 stalled cycles per insn (83.37%) 6 668 429 113 branches # 2464.532 M/sec (83.37%) 3 099 636 branch-misses # 0.05% of all branches (83.26%) 2.706725288 seconds time elapsed 1.782083000 seconds user 0.848424000 seconds sys ```,ROCKET,2021-07-17T07:15:38Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/86823,MERGED,2021-07-02T21:23:05Z,2021-07-08T12:25:50Z,Optimize unchecked indexing into chunks and chunks_mut,the8472,0cd0709f19d316c4796fa71c5f52c8612a5f3771,1,Auto merge of #86823 - the8472:opt-chunk-tra r=kennytm Optimize unchecked indexing into chunks and chunks_mut Fixes #53340 ``` # BEFORE $ rustc +nightly -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 3 177.03 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 006 page-faults # 0.310 M/sec 13 092 199 322 cycles # 4.121 GHz (83.29%) 384 543 475 stalled-cycles-frontend # 2.94% frontend cycles idle (83.35%) 7 414 280 722 stalled-cycles-backend # 56.63% backend cycles idle (83.38%) 50 493 980 662 instructions # 3.86 insn per cycle # 0.15 stalled cycles per insn (83.29%) 6 625 375 297 branches # 2085.396 M/sec (83.38%) 3 087 652 branch-misses # 0.05% of all branches (83.31%) 3.178079469 seconds time elapsed 2.327156000 seconds user 0.762041000 seconds sys # AFTER $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 2 705.76 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 005 page-faults # 0.364 M/sec 11 156 763 039 cycles # 4.123 GHz (83.26%) 342 198 882 stalled-cycles-frontend # 3.07% frontend cycles idle (83.37%) 6 486 263 637 stalled-cycles-backend # 58.14% backend cycles idle (83.37%) 40 553 476 617 instructions # 3.63 insn per cycle # 0.16 stalled cycles per insn (83.37%) 6 668 429 113 branches # 2464.532 M/sec (83.37%) 3 099 636 branch-misses # 0.05% of all branches (83.26%) 2.706725288 seconds time elapsed 1.782083000 seconds user 0.848424000 seconds sys ```,ROCKET,2021-07-17T12:05:14Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/86823,MERGED,2021-07-02T21:23:05Z,2021-07-08T12:25:50Z,Optimize unchecked indexing into chunks and chunks_mut,the8472,0cd0709f19d316c4796fa71c5f52c8612a5f3771,1,Auto merge of #86823 - the8472:opt-chunk-tra r=kennytm Optimize unchecked indexing into chunks and chunks_mut Fixes #53340 ``` # BEFORE $ rustc +nightly -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 3 177.03 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 006 page-faults # 0.310 M/sec 13 092 199 322 cycles # 4.121 GHz (83.29%) 384 543 475 stalled-cycles-frontend # 2.94% frontend cycles idle (83.35%) 7 414 280 722 stalled-cycles-backend # 56.63% backend cycles idle (83.38%) 50 493 980 662 instructions # 3.86 insn per cycle # 0.15 stalled cycles per insn (83.29%) 6 625 375 297 branches # 2085.396 M/sec (83.38%) 3 087 652 branch-misses # 0.05% of all branches (83.31%) 3.178079469 seconds time elapsed 2.327156000 seconds user 0.762041000 seconds sys # AFTER $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc -Copt-level=3 -Ccodegen-units=1 -Clto=fat chunks.rs $ perf stat ./chunks Performance counter stats for './chunks': 2 705.76 msec task-clock # 1.000 CPUs utilized 4 context-switches # 0.001 K/sec 0 cpu-migrations # 0.000 K/sec 984 005 page-faults # 0.364 M/sec 11 156 763 039 cycles # 4.123 GHz (83.26%) 342 198 882 stalled-cycles-frontend # 3.07% frontend cycles idle (83.37%) 6 486 263 637 stalled-cycles-backend # 58.14% backend cycles idle (83.37%) 40 553 476 617 instructions # 3.63 insn per cycle # 0.16 stalled cycles per insn (83.37%) 6 668 429 113 branches # 2464.532 M/sec (83.37%) 3 099 636 branch-misses # 0.05% of all branches (83.26%) 2.706725288 seconds time elapsed 1.782083000 seconds user 0.848424000 seconds sys ```,ROCKET,2021-07-19T11:49:07Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,HOORAY,2021-07-02T21:44:56Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,THUMBS_DOWN,2021-07-02T21:50:13Z,CryZe,NA https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,THUMBS_UP,2021-07-04T23:08:27Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,THUMBS_UP,2021-08-23T09:55:09Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,HOORAY,2021-08-23T09:55:10Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/86826,OPEN,2021-07-02T21:37:21Z,NA,[draft] Store the path in io::Error without extra allocations.,m-ou-se,NA,NA,NA,HOORAY,2022-01-31T07:57:29Z,LukeMathWalker,NA https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,THUMBS_UP,2021-07-03T03:47:06Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,HEART,2021-07-03T08:33:32Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,HEART,2021-07-04T16:03:12Z,usbalbin,NA https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,THUMBS_UP,2021-07-05T16:15:37Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,THUMBS_UP,2021-07-05T22:19:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86830,CLOSED,2021-07-02T22:39:38Z,2021-07-10T12:39:08Z,Make panicking in constants work with the 2021 edition,jonas-schievink,NA,NA,NA,THUMBS_UP,2021-07-06T08:28:12Z,mati865,NA https://github.com/rust-lang/rust/pull/86837,CLOSED,2021-07-03T09:58:10Z,2021-07-05T07:29:36Z,do not promote floating point division by 0,RalfJung,NA,NA,NA,THUMBS_UP,2021-07-04T07:25:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/86839,MERGED,2021-07-03T12:31:43Z,2021-07-29T00:31:10Z,Add doc aliases to fs.rs,D1mon,87c9f32dc48885aa1af9d0926c55f70c4a776ef6,1,Rollup merge of #86839 - D1mon:patch-1 r=JohnTitor Add doc aliases to fs.rs Add aliases for create_dir create_dir_all remove_dir remove_dir_all,THUMBS_UP,2021-07-04T19:49:03Z,r00ster91,NA https://github.com/rust-lang/rust/pull/86839,MERGED,2021-07-03T12:31:43Z,2021-07-29T00:31:10Z,Add doc aliases to fs.rs,D1mon,87c9f32dc48885aa1af9d0926c55f70c4a776ef6,1,Rollup merge of #86839 - D1mon:patch-1 r=JohnTitor Add doc aliases to fs.rs Add aliases for create_dir create_dir_all remove_dir remove_dir_all,HEART,2021-07-27T19:17:22Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-07-03T15:10:08Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,EYES,2021-07-04T19:02:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,EYES,2021-07-09T12:10:47Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-07-09T12:10:47Z,Virgiel,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-08-19T05:44:13Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,EYES,2021-08-19T05:44:14Z,crumblingstatue,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-08-19T13:10:08Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-08-19T23:49:01Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-08-20T13:08:08Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-08-28T13:47:54Z,sthagen,NA https://github.com/rust-lang/rust/pull/86840,MERGED,2021-07-03T12:31:48Z,2021-08-11T01:36:33Z,Constify implementations of `(Try)From` for int types,usbalbin,3b41447a022be4b3612719c4e55d82da944a3d36,5,Rollup merge of #86840 - usbalbin:const_from r=oli-obk Constify implementations of `(Try)From` for int types I believe this to be one of the (many?) things blocking const (Range) iterators. ~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done,HEART,2021-09-15T15:10:55Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/86843,MERGED,2021-07-03T16:04:33Z,2021-07-18T10:42:23Z,Check that const parameters of trait methods have compatible types,FabianWolff,783efd29ae71fccc7dcc220fbca37765423f6e58,3,Rollup merge of #86843 - FabianWolff:issue-86820 r=lcnr Check that const parameters of trait methods have compatible types This PR fixes #86820. The problem is that this currently passes the type checker: ```rust trait Tr { fn foo(self) -> u8; } impl Tr for f32 { fn foo(self) -> u8 { 42 } } ``` i.e. the type checker fails to check whether const parameters in `impl` methods have the same type as the corresponding declaration in the trait. With my changes I get for the above code: ``` error[E0053]: method `foo` has an incompatible const parameter type for trait --> test.rs:6:18 | 6 | fn foo(self) -> u8 { 42 } | ^ | note: the const parameter `N` has type `bool` but the declaration in trait `Tr::foo` has type `u8` --> test.rs:2:18 | 2 | fn foo(self) -> u8; | ^ error: aborting due to previous error ``` This fixes #86820 where an ICE happens later on because the trait method is declared with a const parameter of type `u8` but the `impl` uses one of type `usize`: > `expected int of size 8 but got size 1`,THUMBS_UP,2021-07-14T16:23:04Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/86844,OPEN,2021-07-03T16:07:54Z,NA,Support #[global_allocator] without the allocator shim,bjorn3,NA,NA,NA,HEART,2021-07-04T00:36:54Z,ojeda,NA https://github.com/rust-lang/rust/pull/86844,OPEN,2021-07-03T16:07:54Z,NA,Support #[global_allocator] without the allocator shim,bjorn3,NA,NA,NA,HEART,2021-09-15T17:57:13Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/86844,OPEN,2021-07-03T16:07:54Z,NA,Support #[global_allocator] without the allocator shim,bjorn3,NA,NA,NA,HEART,2022-04-26T15:09:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/86844,OPEN,2021-07-03T16:07:54Z,NA,Support #[global_allocator] without the allocator shim,bjorn3,NA,NA,NA,HEART,2022-05-11T11:37:01Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,HOORAY,2021-09-06T17:15:07Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,THUMBS_UP,2021-09-06T17:15:09Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,HOORAY,2021-09-30T14:07:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,HOORAY,2021-10-08T05:41:15Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,HOORAY,2021-10-10T11:19:52Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/86853,MERGED,2021-07-03T23:07:41Z,2021-09-30T13:23:23Z,Constify ?-operator for Result and Option,usbalbin,c6007fdc7059c677a6c089e8d2915b264c0d1326,7,Auto merge of #86853 - usbalbin:const_try r=oli-obk Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option` see #74935 . Note that the try-operator itself was constified in #87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in #86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - #88674,HOORAY,2022-04-21T13:01:35Z,kraktus,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),ROCKET,2021-07-15T15:23:17Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),HEART,2021-07-15T15:23:19Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),HOORAY,2021-07-15T15:23:21Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-07-15T15:23:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-07-15T18:33:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),HOORAY,2021-07-15T18:33:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),HEART,2021-07-15T18:33:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),ROCKET,2021-07-15T18:33:06Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-07-16T08:45:11Z,liangyongrui,leungyongrui@gmail.com https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-07-16T20:16:43Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-07-22T18:41:35Z,tux3,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-08-19T10:29:25Z,ruuda,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),HEART,2021-09-29T20:05:12Z,kevinaboos,NA https://github.com/rust-lang/rust/pull/86860,MERGED,2021-07-04T07:00:38Z,2021-08-18T03:21:21Z,Stabilize `arbitrary_enum_discriminant`,fee1-dead,02b27f1e70fc60a8f2aa0982e80d7cde5889112e,21,Auto merge of #86860 - fee1-dead:stabilize r=LeSeulArtichaut Stabilize `arbitrary_enum_discriminant` Closes #60553. ---- ## Stabilization Report _copied from https://github.com/rust-lang/rust/issues/60553#issuecomment-865922311_ ### Summary Enables a user to specify *explicit* discriminants on arbitrary enums. Previously this was hard to achieve: ```rust #[repr(u8)] enum Foo { A(u8) = 0 B(i8) = 1 C(bool) = 42 } ``` Someone would need to add 41 hidden variants in between as a workaround with implicit discriminants. In conjunction with [RFC 2195](https://github.com/rust-lang/rfcs/blob/master/text/2195-really-tagged-unions.md) this feature would provide more flexibility for FFI and unsafe code involving enums. ### Test cases Most tests are in [`src/test/ui/enum-discriminant`](https://github.com/rust-lang/rust/tree/master/src/test/ui/enum-discriminant) there are two [historical](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/tag-variant-disr-non-nullary.rs) [tests](https://github.com/rust-lang/rust/blob/master/src/test/ui/parser/issue-17383.rs) that are now covered by the feature (removed by this pr due to them being obsolete). ### Edge cases The feature is well defined and does not have many edge cases. One [edge case](https://github.com/rust-lang/rust/issues/70509) was related to another unstable feature named `repr128` and is resolved. ### Previous PRs The [implementation PR](https://github.com/rust-lang/rust/pull/60732) added documentation to the Unstable Book https://github.com/rust-lang/reference/pull/1055 was opened as a continuation of https://github.com/rust-lang/reference/pull/639. ### Resolution of unresolved questions The questions are resolved in https://github.com/rust-lang/rust/issues/60553#issuecomment-511235271. ---- (someone please add `needs-fcp`),THUMBS_UP,2021-10-11T03:45:34Z,Folyd,NA https://github.com/rust-lang/rust/pull/86873,MERGED,2021-07-04T21:18:36Z,2021-07-10T21:42:39Z,Improve opaque pointers support,nikic,432e145bd5a974c5b6f4dd9b352891bd7502b69d,13,Auto merge of #86873 - nikic:opaque-ptrs r=nagisa Improve opaque pointers support Opaque pointers are coming and rustc is not ready. This adds partial support by passing an explicit load type to LLVM. Two issues I've encountered: * The necessary type was not available at the point where non-temporal copies were generated. I've pushed the code for that upwards out of the memcpy implementation and moved the position of a cast to make do with the types we have available. (I'm not sure that cast is needed at all but have retained it in the interest of conservativeness.) * The `PlaceRef::project_deref()` function used during debuginfo generation seems to be buggy in some way -- though I haven't figured out specifically what it does wrong. Replacing it with `load_operand().deref()` did the trick but I don't really know what I'm doing here.,THUMBS_UP,2021-09-11T06:20:00Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/86876,MERGED,2021-07-05T01:32:41Z,2021-07-15T05:23:07Z,Reuse CrateNum for proc-macro crates even when cross-compiling,jyn514,b9197978a90be6f7570741eabe2da175fec75375,3,Auto merge of #86876 - jyn514:56935-target-crate-num r=petrochenkov Reuse CrateNum for proc-macro crates even when cross-compiling Proc-macros are always compiled for the host so this should be the same in every way as recompiling the crate. I am not sure why the previous code special-cased the target since the compiler properly gives an error when trying to load a crate for a different host: ``` error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu --> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2 | LL | dependency::is_64(); | ^^^^^^^^^^ | = note: the following crate versions were found: crate `dependency` target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so ``` I think another possible fix is to remove the check altogether. But I'm not sure and this fix works so I'm not making the larger change here. Fixes https://github.com/rust-lang/rust/issues/56935. r? `@petrochenkov` cc `@alexcrichton`,HOORAY,2021-07-05T15:51:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86876,MERGED,2021-07-05T01:32:41Z,2021-07-15T05:23:07Z,Reuse CrateNum for proc-macro crates even when cross-compiling,jyn514,b9197978a90be6f7570741eabe2da175fec75375,3,Auto merge of #86876 - jyn514:56935-target-crate-num r=petrochenkov Reuse CrateNum for proc-macro crates even when cross-compiling Proc-macros are always compiled for the host so this should be the same in every way as recompiling the crate. I am not sure why the previous code special-cased the target since the compiler properly gives an error when trying to load a crate for a different host: ``` error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu --> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2 | LL | dependency::is_64(); | ^^^^^^^^^^ | = note: the following crate versions were found: crate `dependency` target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so ``` I think another possible fix is to remove the check altogether. But I'm not sure and this fix works so I'm not making the larger change here. Fixes https://github.com/rust-lang/rust/issues/56935. r? `@petrochenkov` cc `@alexcrichton`,HOORAY,2021-07-07T09:11:10Z,bkchr,NA https://github.com/rust-lang/rust/pull/86876,MERGED,2021-07-05T01:32:41Z,2021-07-15T05:23:07Z,Reuse CrateNum for proc-macro crates even when cross-compiling,jyn514,b9197978a90be6f7570741eabe2da175fec75375,3,Auto merge of #86876 - jyn514:56935-target-crate-num r=petrochenkov Reuse CrateNum for proc-macro crates even when cross-compiling Proc-macros are always compiled for the host so this should be the same in every way as recompiling the crate. I am not sure why the previous code special-cased the target since the compiler properly gives an error when trying to load a crate for a different host: ``` error[E0461]: couldn't find crate `dependency` with expected target triple x86_64-unknown-linux-gnu --> /home/joshua/rustc4/src/test/ui/cfg-dependent.rs:8:2 | LL | dependency::is_64(); | ^^^^^^^^^^ | = note: the following crate versions were found: crate `dependency` target triple i686-unknown-linux-gnu: /home/joshua/rustc4/build/x86_64-unknown-linux-gnu/test/ui/cfg-dependent/auxiliary/libdependency.so ``` I think another possible fix is to remove the check altogether. But I'm not sure and this fix works so I'm not making the larger change here. Fixes https://github.com/rust-lang/rust/issues/56935. r? `@petrochenkov` cc `@alexcrichton`,HOORAY,2021-07-07T09:13:56Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,THUMBS_UP,2021-07-05T12:42:08Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,ROCKET,2021-07-05T12:42:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,ROCKET,2021-08-02T07:52:16Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,ROCKET,2021-08-11T06:42:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,THUMBS_UP,2021-08-11T12:22:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86879,MERGED,2021-07-05T11:45:42Z,2021-08-08T22:17:45Z,Stabilize Vec::shrink_to,YohDeadfall,ad981d58e1ca16bcf4072577934630deb11c5e14,9,Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to r=dtolnay Stabilize Vec::shrink_to This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already and no `panic!` should occur. Closes #56431.,ROCKET,2021-08-11T12:22:19Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86888,MERGED,2021-07-05T16:14:49Z,2021-07-09T15:34:20Z,Fix double warning about illegal floating-point literal pattern,FabianWolff,e916b7cb7708e470be8d0134bdf39479051a5c44,12,Auto merge of #86888 - FabianWolff:issue-86600 r=davidtwco Fix double warning about illegal floating-point literal pattern This PR fixes #86600. The problem is that the `ConstToPat` struct contains a field `include_lint_checks` which determines whether lints should be emitted or not but this field is currently not obeyed at one point leading to a warning being emitted more than once. I have fixed this behavior here.,HEART,2021-07-07T08:24:33Z,rylev,NA https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-07-06T01:23:20Z,Zerotask,NA https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-07-08T15:20:50Z,sassman,sven@d34dl0ck.me https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-07-30T23:56:44Z,greyblake,NA https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-08-06T09:30:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-28T21:45:16Z,Milo123459,NA https://github.com/rust-lang/rust/pull/86892,CLOSED,2021-07-05T20:23:00Z,2021-11-09T10:11:13Z,"Add ""copy to clipboard"" for all code blocks and ""expand"" buttons",GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-10-18T19:02:47Z,mejrs,NA https://github.com/rust-lang/rust/pull/86911,MERGED,2021-07-06T16:52:21Z,2021-07-07T01:03:43Z,Refactor linker code,bjorn3,b20e3ff2af39e1de6280d52aea2e87585e98056d,10,Auto merge of #86911 - bjorn3:crate_info_refactor r=petrochenkov Refactor linker code This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups. See the individual commits for all changes.,THUMBS_UP,2021-07-06T19:38:34Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/86913,MERGED,2021-07-06T17:04:25Z,2021-07-08T20:19:02Z,Document rustdoc with `--document-private-items`,Stupremee,e30eb4d1a2a59ab5a6c2b12a17a1a32b79e9cb44,1,Rollup merge of #86913 - Stupremee:document-rustdoc-private-items r=jyn514 Document rustdoc with `--document-private-items` The `tool_doc` macro introduced in #86737 did not use `false` as the default value for `binary` when it is not provided so the `if` is not even expanded and thus the argument is never provided if the `binary` argument isn't. Resolves #86900 r? ```@Mark-Simulacrum```,HEART,2021-07-07T02:44:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/86927,MERGED,2021-07-07T09:22:36Z,2021-07-08T06:46:45Z,Sync rustc_codegen_cranelift,bjorn3,89638a1ddc07a1da91b293a0e359557bf061c12f,56,Rollup merge of #86927 - bjorn3:sync_cg_clif-2021-07-07 r=bjorn3 Sync rustc_codegen_cranelift The main hightlight this sync is basic support for AArch64. Most things should work on Linux but there does seem to be an ABI incompatibility causing proc-macros to crash see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166) r? ```@ghost``` ```@rustbot``` label +A-codegen +A-cranelift +T-compiler,ROCKET,2021-07-07T11:24:09Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/86927,MERGED,2021-07-07T09:22:36Z,2021-07-08T06:46:45Z,Sync rustc_codegen_cranelift,bjorn3,89638a1ddc07a1da91b293a0e359557bf061c12f,56,Rollup merge of #86927 - bjorn3:sync_cg_clif-2021-07-07 r=bjorn3 Sync rustc_codegen_cranelift The main hightlight this sync is basic support for AArch64. Most things should work on Linux but there does seem to be an ABI incompatibility causing proc-macros to crash see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166) r? ```@ghost``` ```@rustbot``` label +A-codegen +A-cranelift +T-compiler,ROCKET,2021-07-07T16:45:38Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/86927,MERGED,2021-07-07T09:22:36Z,2021-07-08T06:46:45Z,Sync rustc_codegen_cranelift,bjorn3,89638a1ddc07a1da91b293a0e359557bf061c12f,56,Rollup merge of #86927 - bjorn3:sync_cg_clif-2021-07-07 r=bjorn3 Sync rustc_codegen_cranelift The main hightlight this sync is basic support for AArch64. Most things should work on Linux but there does seem to be an ABI incompatibility causing proc-macros to crash see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166) r? ```@ghost``` ```@rustbot``` label +A-codegen +A-cranelift +T-compiler,ROCKET,2021-07-08T08:12:53Z,afonso360,NA https://github.com/rust-lang/rust/pull/86930,MERGED,2021-07-07T11:50:59Z,2021-07-08T22:59:50Z,special case for integer log10,tspiteri,8b87e85394aa583b01e53aef06343dd0749a3324,5,Auto merge of #86930 - tspiteri:int_log10 r=kennytm special case for integer log10 Now that #80918 has been merged this PR provides a faster version of `log10`. The PR also adds some tests for values close to all powers of 10.,HOORAY,2021-07-17T12:06:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/86932,MERGED,2021-07-07T12:28:59Z,2021-07-08T06:46:45Z,Fix ICE when misplaced visibility cannot be properly parsed,rylev,463301aa5a369609d598d2c66902c47a3b1efb51,3,Rollup merge of #86932 - rylev:fix-ice-86895 r=estebank Fix ICE when misplaced visibility cannot be properly parsed Fixes #86895 The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted. The resulting error isn't quite as nice as when the visibility is parsed properly but I'm not sure which error to prioritize here. Displaying both errors might be too confusing. r? ```@estebank```,HEART,2021-07-07T14:44:18Z,dwrensha,NA https://github.com/rust-lang/rust/pull/86977,MERGED,2021-07-08T14:41:38Z,2021-08-17T21:49:26Z,Enable compiler consumers to obtain mir::Body with Polonius facts.,vakaras,30a0a9b694cde95cbab863f7ef4d554f0f46b606,10,Auto merge of #86977 - vakaras:body_with_borrowck_facts r=nikomatsakis Enable compiler consumers to obtain mir::Body with Polonius facts. This PR adds a function (``get_body_with_borrowck_facts``) that can be used by compiler consumers to obtain ``mir::Body`` with accompanying borrow checker information. The most important borrow checker information that [our verifier called Prusti](https://github.com/viperproject/prusti-dev) needs is lifetime constraints. I have not found a reasonable way to compute the lifetime constraints on the Prusti side. In the compiler the constraints are computed during the borrow checking phase and then dropped. This PR adds an additional parameter to the `do_mir_borrowck` function that tells it to return the computed information instead of dropping it. The additionally returned information by `do_mir_borrowck` contains a ``mir::Body`` with non-erased lifetime regions and Polonius facts. I have decided to reuse the Polonius facts because this way I needed fewer changes to the compiler and Polonius facts contains other useful information that we otherwise would need to recompute. Just FYI: up to now Prusti was obtaining this information by [parsing the compiler logs](https://github.com/viperproject/prusti-dev/blob/b58ced8dfd14ef30582b503d517167ccd771eaff/prusti-interface/src/environment/borrowck/regions.rs#L25-L39). This is not only a hacky approach but we also reached its limits. r? `@nikomatsakis`,THUMBS_UP,2021-08-09T20:22:24Z,willcrichton,wcrichto@cs.stanford.edu https://github.com/rust-lang/rust/pull/86977,MERGED,2021-07-08T14:41:38Z,2021-08-17T21:49:26Z,Enable compiler consumers to obtain mir::Body with Polonius facts.,vakaras,30a0a9b694cde95cbab863f7ef4d554f0f46b606,10,Auto merge of #86977 - vakaras:body_with_borrowck_facts r=nikomatsakis Enable compiler consumers to obtain mir::Body with Polonius facts. This PR adds a function (``get_body_with_borrowck_facts``) that can be used by compiler consumers to obtain ``mir::Body`` with accompanying borrow checker information. The most important borrow checker information that [our verifier called Prusti](https://github.com/viperproject/prusti-dev) needs is lifetime constraints. I have not found a reasonable way to compute the lifetime constraints on the Prusti side. In the compiler the constraints are computed during the borrow checking phase and then dropped. This PR adds an additional parameter to the `do_mir_borrowck` function that tells it to return the computed information instead of dropping it. The additionally returned information by `do_mir_borrowck` contains a ``mir::Body`` with non-erased lifetime regions and Polonius facts. I have decided to reuse the Polonius facts because this way I needed fewer changes to the compiler and Polonius facts contains other useful information that we otherwise would need to recompute. Just FYI: up to now Prusti was obtaining this information by [parsing the compiler logs](https://github.com/viperproject/prusti-dev/blob/b58ced8dfd14ef30582b503d517167ccd771eaff/prusti-interface/src/environment/borrowck/regions.rs#L25-L39). This is not only a hacky approach but we also reached its limits. r? `@nikomatsakis`,HEART,2021-08-28T23:00:57Z,RalfJung,NA https://github.com/rust-lang/rust/pull/86983,MERGED,2021-07-08T17:56:50Z,2021-07-16T12:09:39Z,Add or improve natvis definitions for common standard library types,wesleywiser,f4e47ba3f1213dfb4143a078fc3df3a127e4adb6,12,"Rollup merge of #86983 - wesleywiser:natvis_std_types r=michaelwoerister Add or improve natvis definitions for common standard library types Natvis definitions are used by Windows debuggers to provide a better experience when inspecting a value for types with natvis definitions. Many of our standard library types and intrinsic Rust types like slices and `str` already have natvis definitions. This PR adds natvis definitions for missing types (like all of the `Atomic*` types) and improves some of the existing ones (such as showing the ref count on `Arc` and `Rc` and showing the borrow state of `RefCell`). I've also added cdb tests to cover these definitions and updated existing tests with the new visualizations. With this PR the following types now visualize in a much more intuitive way: ### Type: `NonZero{I U}{8 16 32 64 128 size}` `Atomic{I U}{8 16 32 64 size}` `AtomicBool` and `Wrapping`
Example: ```rust let a_u32 = AtomicU32::new(32i32); ``` ``` 0:000> dx a_u32 a_u32 : 32 [Type: core::sync::atomic::AtomicU32] [] [Type: core::sync::atomic::AtomicU32] ```
### Type: `Cell` and `UnsafeCell`
Example: ```rust let cell = Cell::new(123u8); let unsafecell = UnsafeCell::new((42u16 30u16)); ``` ``` 0:000> dx cell cell : 123 [Type: core::cell::Cell] [] [Type: core::cell::Cell] 0:000> dx unsafecell unsafecell : (42 30) [Type: core::cell::UnsafeCell>] [] [Type: core::cell::UnsafeCell>] [0] : 42 [Type: unsigned short] [1] : 30 [Type: unsigned short] ```
### Type: `RefCell`
Example: ```rust let refcell = RefCell::new((123u16 456u32)); ``` ``` 0:000> dx refcell refcell : (123 456) [Type: core::cell::RefCell>] [] [Type: core::cell::RefCell>] [Borrow state] : Unborrowed [0] : 123 [Type: unsigned short] [1] : 456 [Type: unsigned int] ```
### Type: `NonNull` and `Unique`
Example: ```rust let nonnull: NonNull<_> = (&(10 20)).into(); ``` ``` 0:000> dx nonnull nonnull : NonNull(0x7ff6a5d9c390: (10 20)) [Type: core::ptr::non_null::NonNull>] [] [Type: core::ptr::non_null::NonNull>] [0] : 10 [Type: int] [1] : 20 [Type: int] ```
### Type: `Range` `RangeFrom` `RangeInclusive` `RangeTo` and `RangeToInclusive`
Example: ```rust let range = (1..12); let rangefrom = (9..); let rangeinclusive = (32..=80); let rangeto = (..42); let rangetoinclusive = (..=120); ``` ``` 0:000> dx range range : (1..12) [Type: core::ops::range::Range] [] [Type: core::ops::range::Range] 0:000> dx rangefrom rangefrom : (9..) [Type: core::ops::range::RangeFrom] [] [Type: core::ops::range::RangeFrom] 0:000> dx rangeinclusive rangeinclusive : (32..=80) [Type: core::ops::range::RangeInclusive] [] [Type: core::ops::range::RangeInclusive] 0:000> dx rangeto rangeto : (..42) [Type: core::ops::range::RangeTo] [] [Type: core::ops::range::RangeTo] 0:000> dx rangetoinclusive rangetoinclusive : (..=120) [Type: core::ops::range::RangeToInclusive] [] [Type: core::ops::range::RangeToInclusive] ```
### Type: `Duration`
Example: ```rust let duration = Duration::new(5 12); ``` ``` 0:000> dx duration duration : 5s 12ns [Type: core::time::Duration] [] [Type: core::time::Duration] seconds : 5 [Type: unsigned __int64] nanoseconds : 12 [Type: unsigned int] ```
### Type: `ManuallyDrop`
Example: ```rust let manuallydrop = ManuallyDrop::new((123 456)); ``` ``` 0:000> dx manuallydrop manuallydrop : (123 456) [Type: core::mem::manually_drop::ManuallyDrop>] [] [Type: core::mem::manually_drop::ManuallyDrop>] [0] : 123 [Type: int] [1] : 456 [Type: int] ```
### Type: `Pin`
Example: ```rust let mut s = ""this"".to_string(); let pin = Pin::new(&mut s); ``` ``` 0:000> dx pin pin : Pin(0x11a0ff6f0: ""this"") [Type: core::pin::Pin] [] [Type: core::pin::Pin] [len] : 4 [Type: unsigned __int64] [capacity] : 4 [Type: unsigned __int64] [chars] ```
### Type: `Rc` and `Arc`
Example: ```rust let rc = Rc::new(42i8); let rc_weak = Rc::downgrade(&rc); ``` ``` 0:000> dx rc rc : 42 [Type: alloc::rc::Rc] [] [Type: alloc::rc::Rc] [Reference count] : 1 [Type: core::cell::Cell] 0:000> dx rc_weak rc_weak : 42 [Type: alloc::rc::Weak] [] [Type: alloc::rc::Weak] ```
r? ```@michaelwoerister``` cc ```@nanguye2496```",HEART,2021-07-12T13:24:04Z,rylev,NA https://github.com/rust-lang/rust/pull/86983,MERGED,2021-07-08T17:56:50Z,2021-07-16T12:09:39Z,Add or improve natvis definitions for common standard library types,wesleywiser,f4e47ba3f1213dfb4143a078fc3df3a127e4adb6,12,"Rollup merge of #86983 - wesleywiser:natvis_std_types r=michaelwoerister Add or improve natvis definitions for common standard library types Natvis definitions are used by Windows debuggers to provide a better experience when inspecting a value for types with natvis definitions. Many of our standard library types and intrinsic Rust types like slices and `str` already have natvis definitions. This PR adds natvis definitions for missing types (like all of the `Atomic*` types) and improves some of the existing ones (such as showing the ref count on `Arc` and `Rc` and showing the borrow state of `RefCell`). I've also added cdb tests to cover these definitions and updated existing tests with the new visualizations. With this PR the following types now visualize in a much more intuitive way: ### Type: `NonZero{I U}{8 16 32 64 128 size}` `Atomic{I U}{8 16 32 64 size}` `AtomicBool` and `Wrapping`
Example: ```rust let a_u32 = AtomicU32::new(32i32); ``` ``` 0:000> dx a_u32 a_u32 : 32 [Type: core::sync::atomic::AtomicU32] [] [Type: core::sync::atomic::AtomicU32] ```
### Type: `Cell` and `UnsafeCell`
Example: ```rust let cell = Cell::new(123u8); let unsafecell = UnsafeCell::new((42u16 30u16)); ``` ``` 0:000> dx cell cell : 123 [Type: core::cell::Cell] [] [Type: core::cell::Cell] 0:000> dx unsafecell unsafecell : (42 30) [Type: core::cell::UnsafeCell>] [] [Type: core::cell::UnsafeCell>] [0] : 42 [Type: unsigned short] [1] : 30 [Type: unsigned short] ```
### Type: `RefCell`
Example: ```rust let refcell = RefCell::new((123u16 456u32)); ``` ``` 0:000> dx refcell refcell : (123 456) [Type: core::cell::RefCell>] [] [Type: core::cell::RefCell>] [Borrow state] : Unborrowed [0] : 123 [Type: unsigned short] [1] : 456 [Type: unsigned int] ```
### Type: `NonNull` and `Unique`
Example: ```rust let nonnull: NonNull<_> = (&(10 20)).into(); ``` ``` 0:000> dx nonnull nonnull : NonNull(0x7ff6a5d9c390: (10 20)) [Type: core::ptr::non_null::NonNull>] [] [Type: core::ptr::non_null::NonNull>] [0] : 10 [Type: int] [1] : 20 [Type: int] ```
### Type: `Range` `RangeFrom` `RangeInclusive` `RangeTo` and `RangeToInclusive`
Example: ```rust let range = (1..12); let rangefrom = (9..); let rangeinclusive = (32..=80); let rangeto = (..42); let rangetoinclusive = (..=120); ``` ``` 0:000> dx range range : (1..12) [Type: core::ops::range::Range] [] [Type: core::ops::range::Range] 0:000> dx rangefrom rangefrom : (9..) [Type: core::ops::range::RangeFrom] [] [Type: core::ops::range::RangeFrom] 0:000> dx rangeinclusive rangeinclusive : (32..=80) [Type: core::ops::range::RangeInclusive] [] [Type: core::ops::range::RangeInclusive] 0:000> dx rangeto rangeto : (..42) [Type: core::ops::range::RangeTo] [] [Type: core::ops::range::RangeTo] 0:000> dx rangetoinclusive rangetoinclusive : (..=120) [Type: core::ops::range::RangeToInclusive] [] [Type: core::ops::range::RangeToInclusive] ```
### Type: `Duration`
Example: ```rust let duration = Duration::new(5 12); ``` ``` 0:000> dx duration duration : 5s 12ns [Type: core::time::Duration] [] [Type: core::time::Duration] seconds : 5 [Type: unsigned __int64] nanoseconds : 12 [Type: unsigned int] ```
### Type: `ManuallyDrop`
Example: ```rust let manuallydrop = ManuallyDrop::new((123 456)); ``` ``` 0:000> dx manuallydrop manuallydrop : (123 456) [Type: core::mem::manually_drop::ManuallyDrop>] [] [Type: core::mem::manually_drop::ManuallyDrop>] [0] : 123 [Type: int] [1] : 456 [Type: int] ```
### Type: `Pin`
Example: ```rust let mut s = ""this"".to_string(); let pin = Pin::new(&mut s); ``` ``` 0:000> dx pin pin : Pin(0x11a0ff6f0: ""this"") [Type: core::pin::Pin] [] [Type: core::pin::Pin] [len] : 4 [Type: unsigned __int64] [capacity] : 4 [Type: unsigned __int64] [chars] ```
### Type: `Rc` and `Arc`
Example: ```rust let rc = Rc::new(42i8); let rc_weak = Rc::downgrade(&rc); ``` ``` 0:000> dx rc rc : 42 [Type: alloc::rc::Rc] [] [Type: alloc::rc::Rc] [Reference count] : 1 [Type: core::cell::Cell] 0:000> dx rc_weak rc_weak : 42 [Type: alloc::rc::Weak] [] [Type: alloc::rc::Weak] ```
r? ```@michaelwoerister``` cc ```@nanguye2496```",HEART,2021-09-14T11:26:51Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/86984,MERGED,2021-07-08T18:27:49Z,2021-10-21T10:59:28Z,Reject octal zeros in IPv4 addresses,Smittyvb,09de34c10760d31e0781cb506b5b41c649b53e69,3,Rollup merge of #86984 - Smittyvb:ipv4-octal-zero r=m-ou-se Reject octal zeros in IPv4 addresses This fixes #86964 by rejecting octal zeros in IP addresses such that `192.168.00.00000000` is rejected with a parse error since having leading zeros in front of another zero indicates it is a zero written in octal notation which is not allowed in the strict mode specified by RFC 6943 3.1.1. Octal rejection was implemented in #83652 but due to the way it was implemented octal zeros were still allowed.,THUMBS_UP,2021-09-20T23:36:00Z,yescallop,yescallop@gmail.com https://github.com/rust-lang/rust/pull/86984,MERGED,2021-07-08T18:27:49Z,2021-10-21T10:59:28Z,Reject octal zeros in IPv4 addresses,Smittyvb,09de34c10760d31e0781cb506b5b41c649b53e69,3,Rollup merge of #86984 - Smittyvb:ipv4-octal-zero r=m-ou-se Reject octal zeros in IPv4 addresses This fixes #86964 by rejecting octal zeros in IP addresses such that `192.168.00.00000000` is rejected with a parse error since having leading zeros in front of another zero indicates it is a zero written in octal notation which is not allowed in the strict mode specified by RFC 6943 3.1.1. Octal rejection was implemented in #83652 but due to the way it was implemented octal zeros were still allowed.,THUMBS_UP,2021-10-08T06:59:57Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/86984,MERGED,2021-07-08T18:27:49Z,2021-10-21T10:59:28Z,Reject octal zeros in IPv4 addresses,Smittyvb,09de34c10760d31e0781cb506b5b41c649b53e69,3,Rollup merge of #86984 - Smittyvb:ipv4-octal-zero r=m-ou-se Reject octal zeros in IPv4 addresses This fixes #86964 by rejecting octal zeros in IP addresses such that `192.168.00.00000000` is rejected with a parse error since having leading zeros in front of another zero indicates it is a zero written in octal notation which is not allowed in the strict mode specified by RFC 6943 3.1.1. Octal rejection was implemented in #83652 but due to the way it was implemented octal zeros were still allowed.,THUMBS_UP,2021-10-28T06:02:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86993,MERGED,2021-07-09T04:11:00Z,2021-07-16T04:03:20Z,Replace associated item bound vars with placeholders when projecting,jackh726,27e42058811e448b1a7dd8630d86ab247fbfcb9b,19,Auto merge of #86993 - jackh726:project-gat-binders r=nikomatsakis Replace associated item bound vars with placeholders when projecting Fixes #76407 Fixes #76826 Similar but more limited to #85499. This allows us to handle things like `for<'a> ::Assoc<'a>` but not `for<'a> >::Assoc` unblocking GATs. r? `@nikomatsakis`,HEART,2021-07-09T05:38:56Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/86993,MERGED,2021-07-09T04:11:00Z,2021-07-16T04:03:20Z,Replace associated item bound vars with placeholders when projecting,jackh726,27e42058811e448b1a7dd8630d86ab247fbfcb9b,19,Auto merge of #86993 - jackh726:project-gat-binders r=nikomatsakis Replace associated item bound vars with placeholders when projecting Fixes #76407 Fixes #76826 Similar but more limited to #85499. This allows us to handle things like `for<'a> ::Assoc<'a>` but not `for<'a> >::Assoc` unblocking GATs. r? `@nikomatsakis`,HEART,2021-08-03T20:40:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/86993,MERGED,2021-07-09T04:11:00Z,2021-07-16T04:03:20Z,Replace associated item bound vars with placeholders when projecting,jackh726,27e42058811e448b1a7dd8630d86ab247fbfcb9b,19,Auto merge of #86993 - jackh726:project-gat-binders r=nikomatsakis Replace associated item bound vars with placeholders when projecting Fixes #76407 Fixes #76826 Similar but more limited to #85499. This allows us to handle things like `for<'a> ::Assoc<'a>` but not `for<'a> >::Assoc` unblocking GATs. r? `@nikomatsakis`,HEART,2021-08-04T10:08:31Z,fwcd,NA https://github.com/rust-lang/rust/pull/86993,MERGED,2021-07-09T04:11:00Z,2021-07-16T04:03:20Z,Replace associated item bound vars with placeholders when projecting,jackh726,27e42058811e448b1a7dd8630d86ab247fbfcb9b,19,Auto merge of #86993 - jackh726:project-gat-binders r=nikomatsakis Replace associated item bound vars with placeholders when projecting Fixes #76407 Fixes #76826 Similar but more limited to #85499. This allows us to handle things like `for<'a> ::Assoc<'a>` but not `for<'a> >::Assoc` unblocking GATs. r? `@nikomatsakis`,HEART,2021-08-06T14:01:18Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-09T16:08:33Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-09T20:10:55Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-09T21:42:12Z,est31,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-10T23:43:11Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-12T18:29:35Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-18T08:05:52Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-26T09:40:40Z,tema3210,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-28T18:45:10Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-29T06:13:03Z,hkratz,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-07-30T08:31:34Z,CodesInChaos,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-08-05T11:51:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-08-05T12:33:00Z,Kolsky,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-08-05T17:07:53Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-08-06T20:18:32Z,Ewpratten,ewpratten@gmail.com https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",THUMBS_UP,2021-08-14T16:28:36Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/86998,MERGED,2021-07-09T12:10:18Z,2021-07-29T09:35:26Z,"Make const panic!("".."") work in Rust 2021.",m-ou-se,6e0a8bf7901a3fe2e073b1e702e80f58b76d5087,17,"Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str r=oli-obk Make const panic!("".."") work in Rust 2021. During const eval this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`",HOORAY,2021-09-12T09:43:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87004,MERGED,2021-07-09T15:48:20Z,2021-07-19T01:42:02Z,Don't use gc-sections with profile-generate.,JamieCunliffe,b548d9f1c656953c3843693e060302c5c392d149,1,Auto merge of #87004 - JamieCunliffe:pgo-gc-sections r=Mark-Simulacrum Don't use gc-sections with profile-generate. When building with profile-generate don't call gc_sections as this can can sometimes strip out profile data. This missing information in the prof files can then result in missing functions when using the profile information. #78226 r? `@Mark-Simulacrum`,THUMBS_UP,2021-07-09T15:55:58Z,jacobbramley,NA https://github.com/rust-lang/rust/pull/87004,MERGED,2021-07-09T15:48:20Z,2021-07-19T01:42:02Z,Don't use gc-sections with profile-generate.,JamieCunliffe,b548d9f1c656953c3843693e060302c5c392d149,1,Auto merge of #87004 - JamieCunliffe:pgo-gc-sections r=Mark-Simulacrum Don't use gc-sections with profile-generate. When building with profile-generate don't call gc_sections as this can can sometimes strip out profile data. This missing information in the prof files can then result in missing functions when using the profile information. #78226 r? `@Mark-Simulacrum`,HEART,2021-07-12T14:20:02Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/87005,CLOSED,2021-07-09T16:38:10Z,2022-03-30T15:08:29Z,"Make format_args!(""literal"") const.",m-ou-se,NA,NA,NA,HOORAY,2021-11-09T10:15:25Z,mati865,NA https://github.com/rust-lang/rust/pull/87005,CLOSED,2021-07-09T16:38:10Z,2022-03-30T15:08:29Z,"Make format_args!(""literal"") const.",m-ou-se,NA,NA,NA,HEART,2021-11-09T10:15:27Z,mati865,NA https://github.com/rust-lang/rust/pull/87025,CLOSED,2021-07-10T14:05:25Z,2021-07-10T17:17:44Z,Optimize DroplessArena::alloc_from_iter fast path further,the8472,NA,NA,NA,THUMBS_UP,2021-07-10T15:35:53Z,bugadani,NA https://github.com/rust-lang/rust/pull/87026,MERGED,2021-07-10T14:46:23Z,2021-08-04T09:58:26Z,Allow labeled loops as value expressions for `break`,FabianWolff,49ca3d9796030fc0a85089460e9f825ceecc08ed,6,Auto merge of #87026 - FabianWolff:issue-86948 r=estebank Allow labeled loops as value expressions for `break` Fixes #86948. This is currently allowed: ```rust return 'label: loop { break 'label 42; }; break ('label: loop { break 'label 42; }); break 1 + 'label: loop { break 'label 42; }; break 'outer 'inner: loop { break 'inner 42; }; ``` But not this: ```rust break 'label: loop { break 'label 42; }; ``` I have fixed this so that the above now parses as an unlabeled break with a labeled loop as its value expression.,THUMBS_UP,2021-07-10T19:17:51Z,estebank,NA https://github.com/rust-lang/rust/pull/87026,MERGED,2021-07-10T14:46:23Z,2021-08-04T09:58:26Z,Allow labeled loops as value expressions for `break`,FabianWolff,49ca3d9796030fc0a85089460e9f825ceecc08ed,6,Auto merge of #87026 - FabianWolff:issue-86948 r=estebank Allow labeled loops as value expressions for `break` Fixes #86948. This is currently allowed: ```rust return 'label: loop { break 'label 42; }; break ('label: loop { break 'label 42; }); break 1 + 'label: loop { break 'label 42; }; break 'outer 'inner: loop { break 'inner 42; }; ``` But not this: ```rust break 'label: loop { break 'label 42; }; ``` I have fixed this so that the above now parses as an unlabeled break with a labeled loop as its value expression.,THUMBS_UP,2021-07-11T13:46:53Z,LordHavelockVetinari,NA https://github.com/rust-lang/rust/pull/87027,MERGED,2021-07-10T15:06:46Z,2021-07-14T21:17:46Z,expand: Support helper attributes for built-in derive macros,petrochenkov,4d141f5e4c5e09408345cb8fa74f4c2f30cddd5d,6,Rollup merge of #87027 - petrochenkov:builderhelp r=oli-obk expand: Support helper attributes for built-in derive macros This is needed for https://github.com/rust-lang/rust/pull/86735 (derive macro `Default` should have a helper attribute `default`). With this PR we can specify helper attributes for built-in derives using syntax `#[rustc_builtin_macro(MacroName attributes(attr1 attr2 ...))]` which mirrors equivalent syntax for proc macros `#[proc_macro_derive(MacroName attributes(attr1 attr2 ...))]`. Otherwise expansion infra was already ready for this. The attribute parsing code is shared between proc macro derives and built-in macros (`fn parse_macro_name_and_helper_attrs`).,EYES,2021-07-10T15:08:01Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/87027,MERGED,2021-07-10T15:06:46Z,2021-07-14T21:17:46Z,expand: Support helper attributes for built-in derive macros,petrochenkov,4d141f5e4c5e09408345cb8fa74f4c2f30cddd5d,6,Rollup merge of #87027 - petrochenkov:builderhelp r=oli-obk expand: Support helper attributes for built-in derive macros This is needed for https://github.com/rust-lang/rust/pull/86735 (derive macro `Default` should have a helper attribute `default`). With this PR we can specify helper attributes for built-in derives using syntax `#[rustc_builtin_macro(MacroName attributes(attr1 attr2 ...))]` which mirrors equivalent syntax for proc macros `#[proc_macro_derive(MacroName attributes(attr1 attr2 ...))]`. Otherwise expansion infra was already ready for this. The attribute parsing code is shared between proc macro derives and built-in macros (`fn parse_macro_name_and_helper_attrs`).,THUMBS_UP,2021-07-10T17:13:42Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/87028,MERGED,2021-07-10T15:09:14Z,2021-07-10T19:01:41Z,Fix type: `'satic` -> `'static`,aDotInTheVoid,36b142f5c11014090b98028688f2580f1ce4b483,1,Rollup merge of #87028 - aDotInTheVoid:patch-1 r=petrochenkov Fix type: `'satic` -> `'static` Pointed out on discord: https://discord.com/channels/273534239310479360/490356824420122645/863434443170250793 ~~The fact that this compiles is probably a bug.~~ Nope it's `#![feature(in_band_lifetimes)]` (Thanks to [floppy](https://discord.com/channels/273534239310479360/490356824420122645/863437381671059486) ~~[The docs](https://doc.rust-lang.org/stable/nightly-rustc/rustc_mir/transform/inline/struct.Inliner.html#method.check_codegen_attributes) seem to indicate rust thinks this function is generic over the lifetime `'satic`~~ This is because of `in_band_lifetimes`,LAUGH,2021-07-10T15:14:11Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/87028,MERGED,2021-07-10T15:09:14Z,2021-07-10T19:01:41Z,Fix type: `'satic` -> `'static`,aDotInTheVoid,36b142f5c11014090b98028688f2580f1ce4b483,1,Rollup merge of #87028 - aDotInTheVoid:patch-1 r=petrochenkov Fix type: `'satic` -> `'static` Pointed out on discord: https://discord.com/channels/273534239310479360/490356824420122645/863434443170250793 ~~The fact that this compiles is probably a bug.~~ Nope it's `#![feature(in_band_lifetimes)]` (Thanks to [floppy](https://discord.com/channels/273534239310479360/490356824420122645/863437381671059486) ~~[The docs](https://doc.rust-lang.org/stable/nightly-rustc/rustc_mir/transform/inline/struct.Inliner.html#method.check_codegen_attributes) seem to indicate rust thinks this function is generic over the lifetime `'satic`~~ This is because of `in_band_lifetimes`,LAUGH,2021-07-10T15:17:44Z,booleancoercion,NA https://github.com/rust-lang/rust/pull/87028,MERGED,2021-07-10T15:09:14Z,2021-07-10T19:01:41Z,Fix type: `'satic` -> `'static`,aDotInTheVoid,36b142f5c11014090b98028688f2580f1ce4b483,1,Rollup merge of #87028 - aDotInTheVoid:patch-1 r=petrochenkov Fix type: `'satic` -> `'static` Pointed out on discord: https://discord.com/channels/273534239310479360/490356824420122645/863434443170250793 ~~The fact that this compiles is probably a bug.~~ Nope it's `#![feature(in_band_lifetimes)]` (Thanks to [floppy](https://discord.com/channels/273534239310479360/490356824420122645/863437381671059486) ~~[The docs](https://doc.rust-lang.org/stable/nightly-rustc/rustc_mir/transform/inline/struct.Inliner.html#method.check_codegen_attributes) seem to indicate rust thinks this function is generic over the lifetime `'satic`~~ This is because of `in_band_lifetimes`,LAUGH,2021-07-10T15:19:29Z,y21,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T19:09:43Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T19:17:56Z,Virgiel,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T20:30:11Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T20:41:03Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T23:02:47Z,mohe2015,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-10T23:28:00Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,CONFUSED,2021-07-10T23:40:33Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-12T08:01:46Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/87032,CLOSED,2021-07-10T18:09:59Z,2021-07-31T20:47:21Z,Defuse the bomb that is `mem::uninitialized`,bstrie,NA,NA,NA,THUMBS_UP,2021-07-30T23:55:49Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/87052,MERGED,2021-07-11T05:12:46Z,2021-07-30T12:05:53Z,Optimize fmt::PadAdapter::wrap,phlopsi,c25b979db6ee65923e46f8e4dcffcbd3a8381668,1,"Rollup merge of #87052 - phlopsi:patch-1 r=jyn514 Optimize fmt::PadAdapter::wrap After adding the first `write!` usage to my project and printing the result to the console I noticed that my binary contains the strings ""called `Option::unwrap()` on a `None` value`"" and more importantly ""C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs"" with my release build being configured as follows: ``` [profile.release] panic = ""abort"" codegen-units = 1 strip = ""symbols"" # the important bit lto = true ``` I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`. Aside from me suspecting this function to be the culprit the replaced code performs the same operation as `Option::insert` but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore it makes sense to me to use the more optimized version instead. As I don't change any semantics I hope a simple pull request suffices.",THUMBS_UP,2021-07-11T06:49:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87052,MERGED,2021-07-11T05:12:46Z,2021-07-30T12:05:53Z,Optimize fmt::PadAdapter::wrap,phlopsi,c25b979db6ee65923e46f8e4dcffcbd3a8381668,1,"Rollup merge of #87052 - phlopsi:patch-1 r=jyn514 Optimize fmt::PadAdapter::wrap After adding the first `write!` usage to my project and printing the result to the console I noticed that my binary contains the strings ""called `Option::unwrap()` on a `None` value`"" and more importantly ""C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs"" with my release build being configured as follows: ``` [profile.release] panic = ""abort"" codegen-units = 1 strip = ""symbols"" # the important bit lto = true ``` I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`. Aside from me suspecting this function to be the culprit the replaced code performs the same operation as `Option::insert` but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore it makes sense to me to use the more optimized version instead. As I don't change any semantics I hope a simple pull request suffices.",HOORAY,2021-08-02T12:57:29Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/87054,MERGED,2021-07-11T05:56:42Z,2021-12-04T16:29:53Z,Add a `try_reduce` method to the Iterator trait,kit-981,c223a1c10909d7b93fb900fe35fe4bcdc8220246,3,Rollup merge of #87054 - kit-981:master r=scottmcm Add a `try_reduce` method to the Iterator trait Tracking issue: #87053,HEART,2021-09-24T18:28:08Z,kennytm,NA https://github.com/rust-lang/rust/pull/87061,MERGED,2021-07-11T15:35:17Z,2021-07-11T22:14:56Z,Do not suggest adding a semicolon after `?`,FabianWolff,5fcefb1d61bd6380020a68db2b26e94192db881d,3,Rollup merge of #87061 - FabianWolff:issue-87051 r=oli-obk Do not suggest adding a semicolon after `?` Fixes #87051. I have only modified `report_return_mismatched_types()` i.e. my changes only affect suggestions to add `;` for return type mismatches but this never makes sense after `?` because the function cannot return `()` if `?` is used (it has to return a `Result` or an `Option`) and a semicolon won't help if the expected and actual `Err` types differ even if the expected one is `()`.,THUMBS_UP,2021-07-11T18:06:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/87070,MERGED,2021-07-11T21:06:17Z,2021-07-13T04:38:27Z,Simplify future incompatible reporting.,ehuss,8d4293c1d44cbf9adcc72719766581208ea8f027,7,"Rollup merge of #87070 - ehuss:simplify-future-report r=oli-obk Simplify future incompatible reporting. This simplifies the implementation of the future incompatible reporting system. Instead of having a separate field in the future_incompatible definition this reuses the `FutureIncompatibilityReason` enum. It also drops the ""date"" field. Cargo does not use the date field and there isn't much of a need for this to be structured and I am skeptical that the date can be predicted reliably. The date or release version can be listed in the lint text if desired.",THUMBS_UP,2021-07-12T21:27:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87071,MERGED,2021-07-12T00:04:23Z,2021-07-18T08:15:17Z,Add diagnostics for mistyped inclusive range ,inquisitivecrystal,3ab6b60337edeb49339d173853fee1f8569421e0,4,Auto merge of #87071 - inquisitivecrystal:inclusive-range r=estebank Add diagnostics for mistyped inclusive range Inclusive ranges are correctly typed as `..=`. However it's quite easy to think of it as being like `==` and type `..==` instead. This PR adds helpful diagnostics for this case. Resolves #86395 (there are some other cases there but I think those should probably have separate issues). r? `@estebank`,HEART,2021-07-18T00:49:15Z,estebank,NA https://github.com/rust-lang/rust/pull/87073,MERGED,2021-07-12T00:48:11Z,2021-09-12T05:38:26Z,Fix rustdoc handling of primitive items,jyn514,0273e3bce7a0ce49e96a9662163e2380cb87e0be,50,"Auto merge of #87073 - jyn514:primitive-docs r=GuillaumeGomez jyn514 Fix rustdoc handling of primitive items This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing but it would be tricky and I'd rather not unless it's necessary. ## What does this do? - Fixes https://github.com/rust-lang/rust/issues/73423. - Fixes https://github.com/rust-lang/rust/issues/79630. I'm not sure how to test this for the standard library explicitly but you can see from some of the diffs from the `no_std` tests. I also tested it locally and it works correctly: ![image](https://user-images.githubusercontent.com/23638587/125214383-e1fdd000-e284-11eb-8048-76b5df958aad.png) - Fixes https://github.com/rust-lang/rust/issues/83083. ## Why are these changes interconnected? - Allowing anchors (https://github.com/rust-lang/rust/issues/83083) without fixing the online/offline problem (https://github.com/rust-lang/rust/issues/79630) will actually just silently discard the anchors that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through `fn href()` to be fixed. - Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core since rustdoc needs all those primitives to have docs to avoid a fallback and currently `#![no_std]` crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack since otherwise diffs like this will be wrong for some primitives but not others: ```diff `@@` -385 7 +381 7 `@@` fn resolve_primitive_associated_item( ty::AssocKind::Const => ""associatedconstant"" ty::AssocKind::Type => ""associatedtype"" }; - let fragment = format!(""{}#{}.{}"" prim_ty.as_sym() out item_name); + let fragment = format!(""{}.{}"" out item_name); (Res::Primitive(prim_ty) fragment Some((kind.as_def_kind() item.def_id))) }) }) ``` - Adding primitive docs to core without making any other change will cause links to go to `core` instead of `std` even for crates with `extern crate std`. See ""Breaking changes to doc(primitive)"" below for why this is the case. That said I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix https://github.com/rust-lang/rust/issues/73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing. ### Add primitive documentation to libcore This works by reusing the same `include!(""primitive_docs.rs"")` file in both core and std and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's `&str` deref impl or Vec's slice deref impl). Note that this copies the whole file to core to avoid anyone compiling core to have to set `CARGO_PKG_NAME`. See https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Who.20should.20review.20changes.20to.20linkchecker.3F/near/249939598 for more context. It also adds a tidy check to make sure the two files are kept in sync. ### Fix inconsistent online/offline primitive docs This does four things: - Records modules with `doc(primitive)` in `cache.external_paths`. This is necessary for `href()` to find them later. - Makes `cache.primitive_locations` available to the intra-doc link pass by refactoring out a `PrimitiveType::primitive_locations` function that only uses `TyCtxt`. - Special cases modules with `doc(primitive)` to be treated as always public for the purpose of links. - Removes the fragment hack. cc `@notriddle ` I know you added some comments about this in the code (thank you for that!) ### Breaking changes to `doc(primitive)` ""Breaking"" is a little misleading here - these are changes in behavior none of them will cause code to fail to compile. Let me preface this by saying I think stabilizing `doc(primitive)` was a uniquely terrible idea. As far as I can tell it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library and a crater run shows that in fact no one is using it: https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706. I hope to actually make `doc(primitive)` a no-op unless you opt-in with a nightly feature which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now this just subtly changes some of the behavior if you use `doc(primitive)` in a dependency. That said here are the changes: - Refactoring out `primitive_locations()` is technically a change in behavior since it no longer looks for primitives in crates that were passed through `--extern` but not used by the crate; however that seems like such an unlikely edge case it's not worth dealing with. - The precedence given to primitive locations is no longer just arbitrary it can also be inconsistent from run to run. Let me explain that more: previously primitive locations were sorted by the `CrateNum`; the comment on that sort said ""Favor linking to as local extern as possible so iterate all crates in reverse topological order."" Unfortunately that's not actually what CrateNum tracks: it measures the order crates are loaded not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects `extern crate std;` at the top of every crate which ensured it would have the first CrateNum other than the current but every other CrateNum was completely arbitrary (for example `core` often had a later CrateNum than `std`). This now removes the sort on CrateNum completely and special-cases core instead. In particular if you depend on both `std` and a crate which defines a `doc(primitive)` module it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc `@alexcrichton ` you wrote this originally. cc `@rust-lang/rustdoc` cc `@rust-lang/libs` for the addition to `core` (the commit you're interested in is https://github.com/rust-lang/rust/pull/87073/commits/91346c8293bb5f41d8e1d2ec9336433664652c53)",HOORAY,2021-09-12T17:06:35Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87073,MERGED,2021-07-12T00:48:11Z,2021-09-12T05:38:26Z,Fix rustdoc handling of primitive items,jyn514,0273e3bce7a0ce49e96a9662163e2380cb87e0be,50,"Auto merge of #87073 - jyn514:primitive-docs r=GuillaumeGomez jyn514 Fix rustdoc handling of primitive items This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing but it would be tricky and I'd rather not unless it's necessary. ## What does this do? - Fixes https://github.com/rust-lang/rust/issues/73423. - Fixes https://github.com/rust-lang/rust/issues/79630. I'm not sure how to test this for the standard library explicitly but you can see from some of the diffs from the `no_std` tests. I also tested it locally and it works correctly: ![image](https://user-images.githubusercontent.com/23638587/125214383-e1fdd000-e284-11eb-8048-76b5df958aad.png) - Fixes https://github.com/rust-lang/rust/issues/83083. ## Why are these changes interconnected? - Allowing anchors (https://github.com/rust-lang/rust/issues/83083) without fixing the online/offline problem (https://github.com/rust-lang/rust/issues/79630) will actually just silently discard the anchors that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through `fn href()` to be fixed. - Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core since rustdoc needs all those primitives to have docs to avoid a fallback and currently `#![no_std]` crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack since otherwise diffs like this will be wrong for some primitives but not others: ```diff `@@` -385 7 +381 7 `@@` fn resolve_primitive_associated_item( ty::AssocKind::Const => ""associatedconstant"" ty::AssocKind::Type => ""associatedtype"" }; - let fragment = format!(""{}#{}.{}"" prim_ty.as_sym() out item_name); + let fragment = format!(""{}.{}"" out item_name); (Res::Primitive(prim_ty) fragment Some((kind.as_def_kind() item.def_id))) }) }) ``` - Adding primitive docs to core without making any other change will cause links to go to `core` instead of `std` even for crates with `extern crate std`. See ""Breaking changes to doc(primitive)"" below for why this is the case. That said I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix https://github.com/rust-lang/rust/issues/73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing. ### Add primitive documentation to libcore This works by reusing the same `include!(""primitive_docs.rs"")` file in both core and std and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's `&str` deref impl or Vec's slice deref impl). Note that this copies the whole file to core to avoid anyone compiling core to have to set `CARGO_PKG_NAME`. See https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Who.20should.20review.20changes.20to.20linkchecker.3F/near/249939598 for more context. It also adds a tidy check to make sure the two files are kept in sync. ### Fix inconsistent online/offline primitive docs This does four things: - Records modules with `doc(primitive)` in `cache.external_paths`. This is necessary for `href()` to find them later. - Makes `cache.primitive_locations` available to the intra-doc link pass by refactoring out a `PrimitiveType::primitive_locations` function that only uses `TyCtxt`. - Special cases modules with `doc(primitive)` to be treated as always public for the purpose of links. - Removes the fragment hack. cc `@notriddle ` I know you added some comments about this in the code (thank you for that!) ### Breaking changes to `doc(primitive)` ""Breaking"" is a little misleading here - these are changes in behavior none of them will cause code to fail to compile. Let me preface this by saying I think stabilizing `doc(primitive)` was a uniquely terrible idea. As far as I can tell it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library and a crater run shows that in fact no one is using it: https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706. I hope to actually make `doc(primitive)` a no-op unless you opt-in with a nightly feature which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now this just subtly changes some of the behavior if you use `doc(primitive)` in a dependency. That said here are the changes: - Refactoring out `primitive_locations()` is technically a change in behavior since it no longer looks for primitives in crates that were passed through `--extern` but not used by the crate; however that seems like such an unlikely edge case it's not worth dealing with. - The precedence given to primitive locations is no longer just arbitrary it can also be inconsistent from run to run. Let me explain that more: previously primitive locations were sorted by the `CrateNum`; the comment on that sort said ""Favor linking to as local extern as possible so iterate all crates in reverse topological order."" Unfortunately that's not actually what CrateNum tracks: it measures the order crates are loaded not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects `extern crate std;` at the top of every crate which ensured it would have the first CrateNum other than the current but every other CrateNum was completely arbitrary (for example `core` often had a later CrateNum than `std`). This now removes the sort on CrateNum completely and special-cases core instead. In particular if you depend on both `std` and a crate which defines a `doc(primitive)` module it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc `@alexcrichton ` you wrote this originally. cc `@rust-lang/rustdoc` cc `@rust-lang/libs` for the addition to `core` (the commit you're interested in is https://github.com/rust-lang/rust/pull/87073/commits/91346c8293bb5f41d8e1d2ec9336433664652c53)",HEART,2021-09-12T17:06:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87073,MERGED,2021-07-12T00:48:11Z,2021-09-12T05:38:26Z,Fix rustdoc handling of primitive items,jyn514,0273e3bce7a0ce49e96a9662163e2380cb87e0be,50,"Auto merge of #87073 - jyn514:primitive-docs r=GuillaumeGomez jyn514 Fix rustdoc handling of primitive items This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing but it would be tricky and I'd rather not unless it's necessary. ## What does this do? - Fixes https://github.com/rust-lang/rust/issues/73423. - Fixes https://github.com/rust-lang/rust/issues/79630. I'm not sure how to test this for the standard library explicitly but you can see from some of the diffs from the `no_std` tests. I also tested it locally and it works correctly: ![image](https://user-images.githubusercontent.com/23638587/125214383-e1fdd000-e284-11eb-8048-76b5df958aad.png) - Fixes https://github.com/rust-lang/rust/issues/83083. ## Why are these changes interconnected? - Allowing anchors (https://github.com/rust-lang/rust/issues/83083) without fixing the online/offline problem (https://github.com/rust-lang/rust/issues/79630) will actually just silently discard the anchors that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through `fn href()` to be fixed. - Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core since rustdoc needs all those primitives to have docs to avoid a fallback and currently `#![no_std]` crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack since otherwise diffs like this will be wrong for some primitives but not others: ```diff `@@` -385 7 +381 7 `@@` fn resolve_primitive_associated_item( ty::AssocKind::Const => ""associatedconstant"" ty::AssocKind::Type => ""associatedtype"" }; - let fragment = format!(""{}#{}.{}"" prim_ty.as_sym() out item_name); + let fragment = format!(""{}.{}"" out item_name); (Res::Primitive(prim_ty) fragment Some((kind.as_def_kind() item.def_id))) }) }) ``` - Adding primitive docs to core without making any other change will cause links to go to `core` instead of `std` even for crates with `extern crate std`. See ""Breaking changes to doc(primitive)"" below for why this is the case. That said I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix https://github.com/rust-lang/rust/issues/73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing. ### Add primitive documentation to libcore This works by reusing the same `include!(""primitive_docs.rs"")` file in both core and std and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's `&str` deref impl or Vec's slice deref impl). Note that this copies the whole file to core to avoid anyone compiling core to have to set `CARGO_PKG_NAME`. See https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Who.20should.20review.20changes.20to.20linkchecker.3F/near/249939598 for more context. It also adds a tidy check to make sure the two files are kept in sync. ### Fix inconsistent online/offline primitive docs This does four things: - Records modules with `doc(primitive)` in `cache.external_paths`. This is necessary for `href()` to find them later. - Makes `cache.primitive_locations` available to the intra-doc link pass by refactoring out a `PrimitiveType::primitive_locations` function that only uses `TyCtxt`. - Special cases modules with `doc(primitive)` to be treated as always public for the purpose of links. - Removes the fragment hack. cc `@notriddle ` I know you added some comments about this in the code (thank you for that!) ### Breaking changes to `doc(primitive)` ""Breaking"" is a little misleading here - these are changes in behavior none of them will cause code to fail to compile. Let me preface this by saying I think stabilizing `doc(primitive)` was a uniquely terrible idea. As far as I can tell it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library and a crater run shows that in fact no one is using it: https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706. I hope to actually make `doc(primitive)` a no-op unless you opt-in with a nightly feature which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now this just subtly changes some of the behavior if you use `doc(primitive)` in a dependency. That said here are the changes: - Refactoring out `primitive_locations()` is technically a change in behavior since it no longer looks for primitives in crates that were passed through `--extern` but not used by the crate; however that seems like such an unlikely edge case it's not worth dealing with. - The precedence given to primitive locations is no longer just arbitrary it can also be inconsistent from run to run. Let me explain that more: previously primitive locations were sorted by the `CrateNum`; the comment on that sort said ""Favor linking to as local extern as possible so iterate all crates in reverse topological order."" Unfortunately that's not actually what CrateNum tracks: it measures the order crates are loaded not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects `extern crate std;` at the top of every crate which ensured it would have the first CrateNum other than the current but every other CrateNum was completely arbitrary (for example `core` often had a later CrateNum than `std`). This now removes the sort on CrateNum completely and special-cases core instead. In particular if you depend on both `std` and a crate which defines a `doc(primitive)` module it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc `@alexcrichton ` you wrote this originally. cc `@rust-lang/rustdoc` cc `@rust-lang/libs` for the addition to `core` (the commit you're interested in is https://github.com/rust-lang/rust/pull/87073/commits/91346c8293bb5f41d8e1d2ec9336433664652c53)",ROCKET,2021-09-12T17:06:38Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87073,MERGED,2021-07-12T00:48:11Z,2021-09-12T05:38:26Z,Fix rustdoc handling of primitive items,jyn514,0273e3bce7a0ce49e96a9662163e2380cb87e0be,50,"Auto merge of #87073 - jyn514:primitive-docs r=GuillaumeGomez jyn514 Fix rustdoc handling of primitive items This is a complicated PR and does a lot of things. I'm willing to split it up a little more if it would help reviewing but it would be tricky and I'd rather not unless it's necessary. ## What does this do? - Fixes https://github.com/rust-lang/rust/issues/73423. - Fixes https://github.com/rust-lang/rust/issues/79630. I'm not sure how to test this for the standard library explicitly but you can see from some of the diffs from the `no_std` tests. I also tested it locally and it works correctly: ![image](https://user-images.githubusercontent.com/23638587/125214383-e1fdd000-e284-11eb-8048-76b5df958aad.png) - Fixes https://github.com/rust-lang/rust/issues/83083. ## Why are these changes interconnected? - Allowing anchors (https://github.com/rust-lang/rust/issues/83083) without fixing the online/offline problem (https://github.com/rust-lang/rust/issues/79630) will actually just silently discard the anchors that's not a fix. The online/offline problem is directly related to the fragment hack; links need to go through `fn href()` to be fixed. - Technically I could fix the online/offline problem without removing the error on anchors; I am willing to separate that out if it would be helpful for reviewing. However I can't fix the anchor problem without adding docs to core since rustdoc needs all those primitives to have docs to avoid a fallback and currently `#![no_std]` crates don't have docs for primitives. I also can't fix the online/offline problem without removing the fragment hack since otherwise diffs like this will be wrong for some primitives but not others: ```diff `@@` -385 7 +381 7 `@@` fn resolve_primitive_associated_item( ty::AssocKind::Const => ""associatedconstant"" ty::AssocKind::Type => ""associatedtype"" }; - let fragment = format!(""{}#{}.{}"" prim_ty.as_sym() out item_name); + let fragment = format!(""{}.{}"" out item_name); (Res::Primitive(prim_ty) fragment Some((kind.as_def_kind() item.def_id))) }) }) ``` - Adding primitive docs to core without making any other change will cause links to go to `core` instead of `std` even for crates with `extern crate std`. See ""Breaking changes to doc(primitive)"" below for why this is the case. That said I could add some special casing to rustdoc at the same time that would let me separate this change from the others (it would fix https://github.com/rust-lang/rust/issues/73423 but still special-case intra-doc links). I'm willing to separate that out if helpful for reviewing. ### Add primitive documentation to libcore This works by reusing the same `include!(""primitive_docs.rs"")` file in both core and std and then special-casing links in core to use relative links instead of intra-doc links. This doesn't use purely intra-doc links because some of the primitive docs links to items only in std; this doesn't use purely relative links because that introduces new broken links when the docs are re-exported (e.g. String's `&str` deref impl or Vec's slice deref impl). Note that this copies the whole file to core to avoid anyone compiling core to have to set `CARGO_PKG_NAME`. See https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Who.20should.20review.20changes.20to.20linkchecker.3F/near/249939598 for more context. It also adds a tidy check to make sure the two files are kept in sync. ### Fix inconsistent online/offline primitive docs This does four things: - Records modules with `doc(primitive)` in `cache.external_paths`. This is necessary for `href()` to find them later. - Makes `cache.primitive_locations` available to the intra-doc link pass by refactoring out a `PrimitiveType::primitive_locations` function that only uses `TyCtxt`. - Special cases modules with `doc(primitive)` to be treated as always public for the purpose of links. - Removes the fragment hack. cc `@notriddle ` I know you added some comments about this in the code (thank you for that!) ### Breaking changes to `doc(primitive)` ""Breaking"" is a little misleading here - these are changes in behavior none of them will cause code to fail to compile. Let me preface this by saying I think stabilizing `doc(primitive)` was a uniquely terrible idea. As far as I can tell it was stabilized by oversight; it's been stable since 1.0. No one should have need to use it except the standard library and a crater run shows that in fact no one is using it: https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706. I hope to actually make `doc(primitive)` a no-op unless you opt-in with a nightly feature which will keep crates compiling without forcing rustdoc into trying to keep somewhat arbitrary behavior guarantees; but for now this just subtly changes some of the behavior if you use `doc(primitive)` in a dependency. That said here are the changes: - Refactoring out `primitive_locations()` is technically a change in behavior since it no longer looks for primitives in crates that were passed through `--extern` but not used by the crate; however that seems like such an unlikely edge case it's not worth dealing with. - The precedence given to primitive locations is no longer just arbitrary it can also be inconsistent from run to run. Let me explain that more: previously primitive locations were sorted by the `CrateNum`; the comment on that sort said ""Favor linking to as local extern as possible so iterate all crates in reverse topological order."" Unfortunately that's not actually what CrateNum tracks: it measures the order crates are loaded not the number of intermediate crates between that dependency and the root crate. It happened to work as intended before because the compiler injects `extern crate std;` at the top of every crate which ensured it would have the first CrateNum other than the current but every other CrateNum was completely arbitrary (for example `core` often had a later CrateNum than `std`). This now removes the sort on CrateNum completely and special-cases core instead. In particular if you depend on both `std` and a crate which defines a `doc(primitive)` module it's arbitrary whether rustdoc will use the docs from std or the ones from the other crate. cc `@alexcrichton ` you wrote this originally. cc `@rust-lang/rustdoc` cc `@rust-lang/libs` for the addition to `core` (the commit you're interested in is https://github.com/rust-lang/rust/pull/87073/commits/91346c8293bb5f41d8e1d2ec9336433664652c53)",HOORAY,2021-09-13T11:46:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87082,MERGED,2021-07-12T13:34:39Z,2021-07-14T17:59:37Z,Handle non-integer const generic parameters in debuginfo type names.,michaelwoerister,4f0c568785adcc0a123cac9d47047020b7a24821,2,Auto merge of #87082 - michaelwoerister:const-in-debuginfo-type-names-fix r=oli-obk wesleywiser Handle non-integer const generic parameters in debuginfo type names. This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits. The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value. The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully. I'd be interested in ideas on how to do this better. r? `@wesleywiser` cc `@dpaoliello` (do you see any problems with this approach?) cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?) Fixes https://github.com/rust-lang/rust/issues/86893,HEART,2021-07-14T18:00:37Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/87101,MERGED,2021-07-13T11:58:22Z,2021-07-14T15:18:36Z,Suggest a path separator if a stray colon is found in a match arm,FabianWolff,d8943a7d5295e5176ef1cc18e176b2cfe57c4959,7,Rollup merge of #87101 - FabianWolff:issue-87086 r=estebank Suggest a path separator if a stray colon is found in a match arm Attempts to fix #87086. r? `@estebank`,HEART,2021-07-13T16:48:36Z,estebank,NA https://github.com/rust-lang/rust/pull/87101,MERGED,2021-07-13T11:58:22Z,2021-07-14T15:18:36Z,Suggest a path separator if a stray colon is found in a match arm,FabianWolff,d8943a7d5295e5176ef1cc18e176b2cfe57c4959,7,Rollup merge of #87101 - FabianWolff:issue-87086 r=estebank Suggest a path separator if a stray colon is found in a match arm Attempts to fix #87086. r? `@estebank`,HEART,2021-07-14T16:03:27Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/87101,MERGED,2021-07-13T11:58:22Z,2021-07-14T15:18:36Z,Suggest a path separator if a stray colon is found in a match arm,FabianWolff,d8943a7d5295e5176ef1cc18e176b2cfe57c4959,7,Rollup merge of #87101 - FabianWolff:issue-87086 r=estebank Suggest a path separator if a stray colon is found in a match arm Attempts to fix #87086. r? `@estebank`,HEART,2021-07-22T17:58:00Z,tux3,NA https://github.com/rust-lang/rust/pull/87101,MERGED,2021-07-13T11:58:22Z,2021-07-14T15:18:36Z,Suggest a path separator if a stray colon is found in a match arm,FabianWolff,d8943a7d5295e5176ef1cc18e176b2cfe57c4959,7,Rollup merge of #87101 - FabianWolff:issue-87086 r=estebank Suggest a path separator if a stray colon is found in a match arm Attempts to fix #87086. r? `@estebank`,HEART,2021-07-23T13:48:22Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/87117,MERGED,2021-07-13T22:47:17Z,2021-07-14T21:17:46Z,Shrink the CrateStore dynamic interface.,cjgillot,40155f5ea7f284605b7fc95c36d60dabc2f76008,9,Rollup merge of #87117 - cjgillot:cstore r=petrochenkov Shrink the CrateStore dynamic interface. The information is either accessible through queries or by crates which already depend on rustc_metadata.,THUMBS_UP,2021-07-13T23:13:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87117,MERGED,2021-07-13T22:47:17Z,2021-07-14T21:17:46Z,Shrink the CrateStore dynamic interface.,cjgillot,40155f5ea7f284605b7fc95c36d60dabc2f76008,9,Rollup merge of #87117 - cjgillot:cstore r=petrochenkov Shrink the CrateStore dynamic interface. The information is either accessible through queries or by crates which already depend on rustc_metadata.,HEART,2021-07-13T23:29:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87129,MERGED,2021-07-14T13:41:51Z,2021-07-18T01:32:01Z,Warn about useless assignments of variables/fields to themselves,FabianWolff,eb0b95b55a0b38d91e834dd30902b67627ed2eb0,6,Auto merge of #87129 - FabianWolff:issue-75356 r=varkor Warn about useless assignments of variables/fields to themselves This PR fixes #75356. Following `@varkor's` suggestion in https://github.com/rust-lang/rust/issues/75356#issuecomment-700339154 I have implemented this warning as part of the `dead_code` lint. Unlike the `-Wself-assign` implementation in [Clang](https://github.com/llvm/llvm-project/blob/56e6d4742e6909bd7d2db201cc5e0e3e77c6f282/clang/lib/Sema/SemaExpr.cpp#L13875-L13909) my implementation also warns about self-assignments of struct fields (`s.x = s.x`). r? `@varkor`,THUMBS_UP,2021-07-15T08:43:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/87129,MERGED,2021-07-14T13:41:51Z,2021-07-18T01:32:01Z,Warn about useless assignments of variables/fields to themselves,FabianWolff,eb0b95b55a0b38d91e834dd30902b67627ed2eb0,6,Auto merge of #87129 - FabianWolff:issue-75356 r=varkor Warn about useless assignments of variables/fields to themselves This PR fixes #75356. Following `@varkor's` suggestion in https://github.com/rust-lang/rust/issues/75356#issuecomment-700339154 I have implemented this warning as part of the `dead_code` lint. Unlike the `-Wself-assign` implementation in [Clang](https://github.com/llvm/llvm-project/blob/56e6d4742e6909bd7d2db201cc5e0e3e77c6f282/clang/lib/Sema/SemaExpr.cpp#L13875-L13909) my implementation also warns about self-assignments of struct fields (`s.x = s.x`). r? `@varkor`,THUMBS_UP,2021-07-22T07:57:44Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/87150,MERGED,2021-07-15T08:06:50Z,2021-08-04T15:39:32Z,Make wrapping_neg() use wrapping_sub() #[inline(always)],hkratz,7f3dc0464422ebadf3b8647f591bcf6e3107e805,2,Auto merge of #87150 - rusticstuff:simplify_wrapping_neg r=m-ou-se Make wrapping_neg() use wrapping_sub() #[inline(always)] This is a follow-up change to the fix for #75598. It simplifies the implementation of wrapping_neg() for all integer types by just calling 0.wrapping_sub(self) and always inlines it. This leads to much less assembly code being emitted for opt-level≤1 and thus much better performance for debug-compiled code. Background is [this discussion on the internals forum](https://internals.rust-lang.org/t/why-does-rust-generate-10x-as-much-unoptimized-assembly-as-gcc/14930).,THUMBS_UP,2021-07-16T15:06:13Z,Lokathor,NA https://github.com/rust-lang/rust/pull/87150,MERGED,2021-07-15T08:06:50Z,2021-08-04T15:39:32Z,Make wrapping_neg() use wrapping_sub() #[inline(always)],hkratz,7f3dc0464422ebadf3b8647f591bcf6e3107e805,2,Auto merge of #87150 - rusticstuff:simplify_wrapping_neg r=m-ou-se Make wrapping_neg() use wrapping_sub() #[inline(always)] This is a follow-up change to the fix for #75598. It simplifies the implementation of wrapping_neg() for all integer types by just calling 0.wrapping_sub(self) and always inlines it. This leads to much less assembly code being emitted for opt-level≤1 and thus much better performance for debug-compiled code. Background is [this discussion on the internals forum](https://internals.rust-lang.org/t/why-does-rust-generate-10x-as-much-unoptimized-assembly-as-gcc/14930).,THUMBS_UP,2021-08-11T12:22:06Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87153,MERGED,2021-07-15T09:22:49Z,2021-07-19T23:50:37Z,[debuginfo] Emit associated type bindings in trait object type names.,michaelwoerister,014026d1a7ca991f82f12efa95ef4dffb29dc8af,10,Auto merge of #87153 - michaelwoerister:debuginfo-names-dyn-trait-projection-bounds r=wesleywiser [debuginfo] Emit associated type bindings in trait object type names. This PR updates debuginfo type name generation for trait objects to include associated type bindings and auto trait bounds -- so that for example the debuginfo type name of `&dyn Iterator` and `&dyn Iterator` don't both map to just `&dyn Iterator` anymore. The following table shows examples of debuginfo type names before and after the PR: | type | before | after | |------|---------|-------| | `&dyn Iterator>` | `&dyn Iterator` | `&dyn Iterator` | | `&(dyn Iterator> + Sync)` | `&dyn Iterator` | `&(dyn Iterator + Sync)` | | `&(dyn SomeTrait> + Send)` | `&dyn SomeTrait` | `&(dyn SomeTrait> + Send)` | For targets that need C++-like type names we use `assoc$` instead of `Item=u32`: | type | before | after | |------|---------|-------| | `&dyn Iterator>` | `ref$ >` | `ref$ > > >` | | `&(dyn Iterator> + Sync)` | `ref$ >` | `ref$ > Sync> >` | | `&(dyn SomeTrait> + Send)` | `ref$ > >` | `ref$ > > Send> >` | The PR also adds self-profiling measurements for debuginfo type name generation (re. https://github.com/rust-lang/rust/issues/86431). It looks like the compiler spends up to 0.5% of its time in that task so the potential for optimizing it via caching seems limited. However the perf run also shows [the biggest regression](https://perf.rust-lang.org/detailed-query.html?commit=585e91c718b0b2c5319e1fffd0ff1e62aaf7ccc2&base_commit=b9197978a90be6f7570741eabe2da175fec75375&benchmark=tokio-webpush-simple-debug&run_name=incr-unchanged) in a test case that does not even invoke the code in question. This suggests that the length of the names we generate here can affect performance by influencing how much data the linker has to copy around. Fixes https://github.com/rust-lang/rust/issues/86134.,THUMBS_UP,2021-07-16T05:56:19Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87162,MERGED,2021-07-15T16:21:27Z,2021-07-16T12:09:38Z,"Fix type decl layout ""overflow""",GuillaumeGomez,a547abe929b750971f5b909149a0be2a3ec7c366,3,"Rollup merge of #87162 - GuillaumeGomez:type-decl-overflow r=notriddle Fix type decl layout ""overflow"" Before: ![Screenshot from 2021-07-15 17-56-12](https://user-images.githubusercontent.com/3050060/125822644-c4595211-d75e-4dd7-ba44-183197ee836c.png) After: ![Screenshot from 2021-07-15 17-56-17](https://user-images.githubusercontent.com/3050060/125822648-7b363847-e153-4ff3-9fba-59478e32eced.png) cc ```@SergioBenitez``` r? ```@notriddle```",HOORAY,2021-07-15T16:35:36Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87171,MERGED,2021-07-15T21:19:39Z,2021-07-23T23:17:41Z,Remove Option from BufWriter,Alexendoo,2038fa58491d2719ffce0cc72dbe24c446d5cbba,1,Rollup merge of #87171 - Alexendoo:bufwriter-option r=Mark-Simulacrum Remove Option from BufWriter Fixes #72925,HOORAY,2021-07-29T02:58:54Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-16T10:02:44Z,CryZe,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-16T12:41:58Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-16T22:16:42Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-16T22:18:40Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-22T02:25:32Z,rrbutani,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-07-22T03:17:58Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-23T11:42:44Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-23T12:02:16Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-07-23T12:02:16Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-07-23T12:40:26Z,tomlla,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-23T17:29:38Z,gliderkite,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-07-23T23:48:40Z,avindra,aavindraa@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-07-28T11:16:29Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-08-03T17:33:26Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-08-03T17:33:27Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-08-10T16:41:56Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2021-08-19T10:18:11Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,THUMBS_UP,2021-08-19T10:18:11Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/87174,MERGED,2021-07-15T23:34:49Z,2021-07-16T21:54:55Z,Stabilize `[T; N]::map()`,inquisitivecrystal,7c5cabe30f4c6402e06ab0240cdfc066e7c70e8e,2,Rollup merge of #87174 - inquisitivecrystal:array-map r=kennytm Stabilize `[T; N]::map()` This stabilizes the `[T; N]::map()` function gated by the `array_map` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/75243#issuecomment-878448138) Closes #75243.,HOORAY,2022-03-13T16:25:54Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/87175,MERGED,2021-07-16T00:03:39Z,2021-07-23T23:17:41Z,Stabilize `into_parts()` and `into_error()`,inquisitivecrystal,f335bca8a5a8d754cbe3832e80b40165cd7ec6e3,1,Rollup merge of #87175 - inquisitivecrystal:inner-error r=kennytm Stabilize `into_parts()` and `into_error()` This stabilizes `IntoInnerError`'s `into_parts()` and `into_error()` methods currently gated behind the `io_into_inner_error_parts` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/79704#issuecomment-880652967) Closes #79704.,ROCKET,2021-07-16T23:25:10Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/87183,MERGED,2021-07-16T08:35:24Z,2021-07-18T10:42:22Z,fix typo in compile_fail doctest,RalfJung,c1ee9a3a03be7114044fd761110cc97f6cc845e7,1,Rollup merge of #87183 - RalfJung:option-doctest r=jyn514 fix typo in compile_fail doctest Fixes a typo introduced by https://github.com/rust-lang/rust/pull/86211. For some reason this typo makes Miri go all crazy when running libcore doctests (https://github.com/rust-lang/miri/issues/1852). Kudos to ``@hyd-dev`` for noticing the typo. Cc ``@tlyu`` ``@joshtriplett``,HEART,2021-07-16T15:14:13Z,tlyu,tlyu@mit.edu https://github.com/rust-lang/rust/pull/87190,CLOSED,2021-07-16T14:17:13Z,2021-11-13T19:05:42Z,[experiment] Crater 2021 edition rustfix,ehuss,NA,NA,NA,HEART,2021-08-17T11:35:51Z,est31,NA https://github.com/rust-lang/rust/pull/87190,CLOSED,2021-07-16T14:17:13Z,2021-11-13T19:05:42Z,[experiment] Crater 2021 edition rustfix,ehuss,NA,NA,NA,HEART,2021-08-18T04:14:40Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/87194,MERGED,2021-07-16T15:33:47Z,2021-08-26T21:58:53Z,rustc_symbol_mangling: support structural constants and &str in v0.,eddyb,ad02dc46badee510bd3a2c093edf80fcaade91b1,21,"Auto merge of #87194 - eddyb:const-value-mangling r=michaelwoerister oli-obk rustc_symbol_mangling: support structural constants and &str in v0. This PR should unblock #85530 (except for float `const` generics which AFAIK should've never worked). (cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater ""subset"" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats) The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102 tho this PR won't by itself finish #61486 before closing that we'd likely want to move to `@oli-obk's` ""valtrees"" (i.e. #83234 and other associated work).
**EDITs**: 1. switched unit/tuple/braced-with-named-fields `` prefixes from `""u""`/`""T""`/`""""` to `""U""`/`""T""`/`""S""` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921. 2. `rustc-demangle` PR: https://github.com/alexcrichton/rustc-demangle/pull/55 3. RFC amendment PR: https://github.com/rust-lang/rfcs/pull/3161 * also removed the grammar changes included in that PR from this description 4. added tests (temporarily using my fork of `rustc-demangle`)
r? `@michaelwoerister`",HEART,2021-07-19T21:54:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/87194,MERGED,2021-07-16T15:33:47Z,2021-08-26T21:58:53Z,rustc_symbol_mangling: support structural constants and &str in v0.,eddyb,ad02dc46badee510bd3a2c093edf80fcaade91b1,21,"Auto merge of #87194 - eddyb:const-value-mangling r=michaelwoerister oli-obk rustc_symbol_mangling: support structural constants and &str in v0. This PR should unblock #85530 (except for float `const` generics which AFAIK should've never worked). (cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater ""subset"" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats) The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102 tho this PR won't by itself finish #61486 before closing that we'd likely want to move to `@oli-obk's` ""valtrees"" (i.e. #83234 and other associated work).
**EDITs**: 1. switched unit/tuple/braced-with-named-fields `` prefixes from `""u""`/`""T""`/`""""` to `""U""`/`""T""`/`""S""` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921. 2. `rustc-demangle` PR: https://github.com/alexcrichton/rustc-demangle/pull/55 3. RFC amendment PR: https://github.com/rust-lang/rfcs/pull/3161 * also removed the grammar changes included in that PR from this description 4. added tests (temporarily using my fork of `rustc-demangle`)
r? `@michaelwoerister`",HEART,2021-07-22T08:59:28Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/87194,MERGED,2021-07-16T15:33:47Z,2021-08-26T21:58:53Z,rustc_symbol_mangling: support structural constants and &str in v0.,eddyb,ad02dc46badee510bd3a2c093edf80fcaade91b1,21,"Auto merge of #87194 - eddyb:const-value-mangling r=michaelwoerister oli-obk rustc_symbol_mangling: support structural constants and &str in v0. This PR should unblock #85530 (except for float `const` generics which AFAIK should've never worked). (cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater ""subset"" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats) The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102 tho this PR won't by itself finish #61486 before closing that we'd likely want to move to `@oli-obk's` ""valtrees"" (i.e. #83234 and other associated work).
**EDITs**: 1. switched unit/tuple/braced-with-named-fields `` prefixes from `""u""`/`""T""`/`""""` to `""U""`/`""T""`/`""S""` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921. 2. `rustc-demangle` PR: https://github.com/alexcrichton/rustc-demangle/pull/55 3. RFC amendment PR: https://github.com/rust-lang/rfcs/pull/3161 * also removed the grammar changes included in that PR from this description 4. added tests (temporarily using my fork of `rustc-demangle`)
r? `@michaelwoerister`",HEART,2021-08-05T07:07:16Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/87196,MERGED,2021-07-16T16:30:14Z,2021-07-19T09:32:14Z,Mark `Option::insert` as must_use,oxalica,83f08223a90b71f59e5dc5f38e384a49a76c8452,1,Auto merge of #87196 - oxalica:option-insert-must-use r=joshtriplett Mark `Option::insert` as must_use Some people seems misled by the function name and use it in case where a simple assignment just works. If the return value is not used `option = Some(value);` should be preferred instead of `option.insert(value);`,THUMBS_UP,2021-07-16T20:05:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87196,MERGED,2021-07-16T16:30:14Z,2021-07-19T09:32:14Z,Mark `Option::insert` as must_use,oxalica,83f08223a90b71f59e5dc5f38e384a49a76c8452,1,Auto merge of #87196 - oxalica:option-insert-must-use r=joshtriplett Mark `Option::insert` as must_use Some people seems misled by the function name and use it in case where a simple assignment just works. If the return value is not used `option = Some(value);` should be preferred instead of `option.insert(value);`,THUMBS_UP,2021-07-27T11:28:37Z,matthiasbeyer,mail@beyermatthias.de https://github.com/rust-lang/rust/pull/87221,CLOSED,2021-07-17T17:44:00Z,2021-12-10T07:25:02Z,Stabilize built-in attribute macro `#[cfg_eval]`,petrochenkov,NA,NA,NA,THUMBS_UP,2021-08-19T13:45:45Z,jplatte,NA https://github.com/rust-lang/rust/pull/87221,CLOSED,2021-07-17T17:44:00Z,2021-12-10T07:25:02Z,Stabilize built-in attribute macro `#[cfg_eval]`,petrochenkov,NA,NA,NA,THUMBS_UP,2021-08-22T18:37:16Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/87221,CLOSED,2021-07-17T17:44:00Z,2021-12-10T07:25:02Z,Stabilize built-in attribute macro `#[cfg_eval]`,petrochenkov,NA,NA,NA,THUMBS_UP,2021-09-07T20:26:17Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-07-17T23:54:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-09-02T19:40:05Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-09-09T10:33:31Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-09-18T20:08:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-09-20T14:52:09Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/87234,MERGED,2021-07-17T23:52:00Z,2021-09-21T10:33:20Z,Lower only one HIR owner at a time,cjgillot,49c0861ed0fa1d95186d88df0cd4310103e70957,19,Auto merge of #87234 - cjgillot:lower-mono r=petrochenkov Lower only one HIR owner at a time Based on https://github.com/rust-lang/rust/pull/83723 Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by: - moving global analyses to the resolver (item_generics_num_lifetimes proc_macros trait_impls); - removing a few special cases (non-exported macros and use statements); - restricting the amount of available information at any one time; - avoiding back-and-forth between different owners: an item must now be lowered all at once and its parent cannot refer to its nodes. I also removed the sorting of bodies by span. The diagnostic ordering changes marginally since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck. (While these items could logically be in different PRs the dependency between commits and the amount of conflicts force a monolithic PR.),HEART,2021-09-21T16:22:54Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/87235,MERGED,2021-07-17T23:55:34Z,2021-08-09T01:08:52Z,Improve diagnostics for wrongly ordered keywords in function declaration,poliorcetics,74a11c63f85c2b1796852f317358188f9cde236e,13,Auto merge of #87235 - poliorcetics:issue-87217-fn-quali-order r=nagisa Improve diagnostics for wrongly ordered keywords in function declaration Fix #87217 `@rustbot` label A-diagnostics T-compiler,THUMBS_UP,2021-08-11T11:44:35Z,synek317,sasik520@gmail.com https://github.com/rust-lang/rust/pull/87235,MERGED,2021-07-17T23:55:34Z,2021-08-09T01:08:52Z,Improve diagnostics for wrongly ordered keywords in function declaration,poliorcetics,74a11c63f85c2b1796852f317358188f9cde236e,13,Auto merge of #87235 - poliorcetics:issue-87217-fn-quali-order r=nagisa Improve diagnostics for wrongly ordered keywords in function declaration Fix #87217 `@rustbot` label A-diagnostics T-compiler,THUMBS_UP,2021-08-11T16:40:27Z,timvisee,3a4fb3964f@sinenomine.email https://github.com/rust-lang/rust/pull/87235,MERGED,2021-07-17T23:55:34Z,2021-08-09T01:08:52Z,Improve diagnostics for wrongly ordered keywords in function declaration,poliorcetics,74a11c63f85c2b1796852f317358188f9cde236e,13,Auto merge of #87235 - poliorcetics:issue-87217-fn-quali-order r=nagisa Improve diagnostics for wrongly ordered keywords in function declaration Fix #87217 `@rustbot` label A-diagnostics T-compiler,THUMBS_UP,2021-08-12T22:39:17Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2021-07-18T11:44:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2021-07-19T13:14:37Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2021-07-29T01:15:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2021-07-29T16:29:56Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2021-08-02T01:32:06Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87237,MERGED,2021-07-18T01:38:57Z,2021-07-30T14:34:27Z,Add feature gates for `for` and `?` in consts,jonas-schievink,87dc8242484110c75596a91ebd2043a476c09839,19,Auto merge of #87237 - jonas-schievink:const-for-and-try r=oli-obk Add feature gates for `for` and `?` in consts These operations seems *relatively* straightforward to support and only seem to be blocked on `impl const Trait`. I have included a working test for `const_try` but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method so I didn't do that. (both features still need tracking issues before this is merged),HEART,2022-01-19T06:11:38Z,KisaragiEffective,NA https://github.com/rust-lang/rust/pull/87244,MERGED,2021-07-18T06:26:56Z,2021-07-20T13:37:19Z,Better diagnostics with mismatched types due to implicit static lifetime,jackh726,da7d405357600a76f2b93b8aa41fe5ee5da7885d,16,"Auto merge of #87244 - jackh726:issue-71883 r=estebank Better diagnostics with mismatched types due to implicit static lifetime Fixes #78113 I think this is my first diagnostics PR...definitely happy to hear thoughts on the direction/implementation here. I was originally just trying to solve the error above where the lifetime on a GAT was causing a cryptic ""mismatched types"" error. But as I was writing this I realized that this (unintentionally) also applied to a different case: `wf-in-foreign-fn-decls-issue-80468.rs`. I'm not sure if this diagnostic should get a new error code or even reuse an existing one. And there might be some ways to make this even more generalized. Also the error is a bit more lengthy and verbose than probably needed. So thoughts there are welcome too. This PR essentially ended up adding a new nice region error pass that triggers if a type doesn't match the self type of an impl which is selected because of a predicate because of an implicit static bound on that self type. r? `@estebank`",HEART,2021-07-19T18:16:55Z,estebank,NA https://github.com/rust-lang/rust/pull/87247,MERGED,2021-07-18T07:47:16Z,2021-07-20T18:44:52Z,Merge libterm into libtest,crlf0710,39d8d3ab6a880179ef12b5d11414d940711ed422,17,Auto merge of #87247 - crlf0710:merge-libterm-into-libtest r=nagisa Merge libterm into libtest I think it's quite clear at this point that rust won't stablize the current libterm APIs to the outside world. And its only user is libtest. The compiler doesn't use this api at all. So I'm merging the crate into libtest as a module. This also allows me to remove 15% of the libterm code since these APIs are dead-code now.,HEART,2021-07-18T09:04:17Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87254,MERGED,2021-07-18T13:18:30Z,2021-08-11T04:29:42Z,LLVM codegen: Don't emit zero-sized padding for fields,hkratz,47b41b7788a6f85c749049062f1e4eed497cd894,7,Auto merge of #87254 - rusticstuff:rustc_codegen_llvm_dont_emit_zero_sized_padding r=eddyb LLVM codegen: Don't emit zero-sized padding for fields Currently padding is emitted before fields of a struct and at the end of the struct regardless of the ABI. Even if no padding is required zero-sized padding fields are emitted. This is not useful and - more importantly - it make it impossible to generate the exact vector types that LLVM expects for certain ARM SIMD intrinsics. This change should unblock the implementation of many ARM intrinsics using the `unadjusted` ABI see https://github.com/rust-lang/stdarch/issues/1143#issuecomment-827404092. This is a proof of concept only because the field lookup now takes O(number of fields) time compared to O(1) before since it recalculates the mapping at every lookup. I would like to find out how big the performance impact actually is before implementing caching or restricting this behavior to the `unadjusted` ABI. cc `@SparrowLii` `@bjorn3` ([Discussion on internals](https://internals.rust-lang.org/t/feature-request-add-a-way-in-rustc-for-generating-struct-type-llvm-ir-without-paddings/15007)),HOORAY,2021-08-11T09:54:30Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/87259,MERGED,2021-07-18T19:54:56Z,2021-07-19T12:40:49Z,triagebot shortcut config,Llandy3d,5ef6439c8d4df4f54cfdb96e7ff66ebd062e26e9,1,Rollup merge of #87259 - Llandy3d:triagebot_shortcuts r=nikomatsakis triagebot shortcut config Enable the new triagebot shortcuts as per [#1381/triagebot](https://github.com/rust-lang/triagebot/pull/1381),HEART,2021-07-18T20:24:50Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T20:12:22Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T20:16:14Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T20:56:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T21:02:32Z,CryZe,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-18T22:17:06Z,mexus,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T22:17:09Z,mexus,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-18T23:30:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-18T23:30:47Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T04:43:48Z,hkratz,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T04:43:49Z,hkratz,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T06:20:21Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T06:20:23Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T06:32:24Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T07:02:21Z,est31,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T07:12:18Z,Urgau,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T07:35:37Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T07:45:01Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T10:53:21Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T13:57:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T16:26:33Z,bjorn3,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T18:32:49Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T18:32:50Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-19T20:39:05Z,mohe2015,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-19T20:39:06Z,mohe2015,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-20T21:36:43Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-20T21:36:43Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-24T15:51:43Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-24T15:51:44Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-24T15:54:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-25T07:06:02Z,shengsheng,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-25T07:06:07Z,shengsheng,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-07-28T09:17:12Z,vincentdephily,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-29T04:51:49Z,yerke,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-29T04:51:50Z,yerke,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-07-29T04:51:53Z,yerke,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-07-29T04:52:02Z,yerke,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-07-31T05:22:42Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-31T05:22:44Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-07-31T10:56:57Z,realvikas,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-07-31T12:24:32Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-31T12:24:35Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-07-31T18:16:00Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-07-31T18:16:01Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-07-31T18:16:02Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-07-31T18:16:02Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-07-31T18:16:03Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-08-01T23:34:01Z,xero-lib,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-08-01T23:34:02Z,xero-lib,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-08-01T23:34:02Z,xero-lib,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-08-01T23:34:04Z,xero-lib,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-08-01T23:34:05Z,xero-lib,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-08-04T11:27:17Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-08-04T11:27:17Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-08-05T16:54:37Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-08-07T20:04:39Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-08-07T20:04:40Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-08-07T20:04:41Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-08-08T13:30:37Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-08-08T13:31:20Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-08-10T14:44:15Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-08-18T10:24:26Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-08-30T04:16:51Z,DmitryBochkarev,dimabochkarev@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-08-30T04:16:54Z,DmitryBochkarev,dimabochkarev@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-09-16T17:56:52Z,p00f,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-09-16T17:56:53Z,p00f,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-09-28T00:57:38Z,fbernier,frankbernier@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-09-29T14:01:28Z,glaubitz,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-09-30T05:05:30Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-09-30T05:05:31Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-09-30T05:05:34Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-09-30T18:52:11Z,meryacine,omar.yassin00@eng-st.cu.edu.eg https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-09-30T18:52:19Z,meryacine,omar.yassin00@eng-st.cu.edu.eg https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-09-30T18:52:20Z,meryacine,omar.yassin00@eng-st.cu.edu.eg https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-10-11T18:26:57Z,bluss,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-11-29T17:10:17Z,U-C-S,uchanakyasrinivas@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-11-29T17:10:22Z,U-C-S,uchanakyasrinivas@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-12-02T03:24:43Z,tafia,tafia973@gmail.com https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-12-02T15:22:42Z,ljedrz,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-12-02T16:10:25Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-12-02T16:10:30Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-12-02T16:10:31Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-12-02T18:37:21Z,g2p,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-12-02T18:42:49Z,lexxvir,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-12-02T19:58:52Z,nurmohammed840,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-12-02T20:24:39Z,DuckDuckWhale,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-12-05T00:44:28Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2021-12-05T00:44:28Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2021-12-05T00:44:28Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2021-12-05T00:44:29Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-12-05T00:44:29Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,EYES,2021-12-14T05:53:55Z,rben01,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,THUMBS_UP,2021-12-22T10:39:03Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HOORAY,2022-01-27T13:57:57Z,pro465,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,HEART,2022-01-27T13:58:05Z,pro465,NA https://github.com/rust-lang/rust/pull/87260,MERGED,2021-07-18T20:10:33Z,2021-09-29T13:27:20Z,Libgccjit codegen,antoyo,864290472fcb1deee2a4fb09a9df2864ce3bd1a4,80,Rollup merge of #87260 - antoyo:libgccjit-codegen r=Mark-Simulacrum Libgccjit codegen This PR introduces a subtree for a gcc-based codegen backend to the repository per decision in https://github.com/rust-lang/compiler-team/issues/442. We do not yet expect to ship this backend on nightly or run tests in CI but we do verify that the backend checks (i.e. `cargo check`) successfully. Work is expected to progress primarily in https://github.com/rust-lang/rustc_codegen_gcc with semi-regular upstreaming like with other subtrees.,ROCKET,2022-01-27T13:58:10Z,pro465,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-07-19T01:09:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-13T12:47:19Z,ZuseZ4,git@manuel.drehwald.info https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-14T07:51:39Z,Kestrer,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-18T10:27:56Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-18T17:42:13Z,druuimai,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-18T21:14:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-19T01:35:47Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",HOORAY,2021-11-19T01:35:50Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-19T02:25:56Z,pierzchalski,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-20T00:08:35Z,tmandry,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",HOORAY,2021-11-20T08:01:18Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-30T03:56:04Z,AZMCode,adrianozambrana@protonmail.com https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2021-11-30T23:42:44Z,jkelleyrtp,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",HOORAY,2021-11-30T23:42:44Z,jkelleyrtp,NA https://github.com/rust-lang/rust/pull/87264,MERGED,2021-07-19T00:09:07Z,2021-11-13T11:03:38Z,proc_macro: Add an expand_expr method to TokenStream,mystor,3e018ce194ab16125747220676dd8a20aecd5196,8,"Auto merge of #87264 - mystor:expand_literal r=petrochenkov proc_macro: Add an expand_expr method to TokenStream This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters such as the format string as they perform recursive macro expansion while being expanded. This can be especially useful in many cases thanks to helper macros like `concat!` `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code. For now this method only allows expanding macros which produce literals although more expressions will be supported before the method is stabilized. In earlier versions of this PR this method exclusively returned `Literal` and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279) which should allow for more general APIs like ""format_args_implicits"" (https://github.com/rust-lang/rust/issues/67984) to be supported as well. ## API Surface ```rust impl TokenStream { pub fn expand_expr(&self) -> Result; } #[non_exhaustive] pub struct ExpandError; impl Debug for ExpandError { ... } impl Display for ExpandError { ... } impl Error for ExpandError {} impl !Send for ExpandError {} impl !Sync for ExpandError {} ```",THUMBS_UP,2022-01-05T21:23:51Z,camelid,NA https://github.com/rust-lang/rust/pull/87265,MERGED,2021-07-19T02:45:15Z,2021-07-22T10:04:46Z,Support HIR wf checking for function signatures,Aaron1011,7c89e389d00cfc7e86ae7e1b45880da4f5f5c9f5,28,Auto merge of #87265 - Aaron1011:hir-wf-fn r=estebank Support HIR wf checking for function signatures During function type-checking we normalize any associated types in the function signature (argument types + return type) and then create WF obligations for each of the normalized types. The HIR wf code does not currently support this case so any errors that we get have imprecise spans. This commit extends `ObligationCauseCode::WellFormed` to support recording a function parameter allowing us to get the corresponding HIR type if an error occurs. Function typechecking is modified to pass this information during signature normalization and WF checking. The resulting code is fairly verbose due to the fact that we can no longer normalize the entire signature with a single function call. As part of the refactoring we now perform HIR-based WF checking for several other 'typed items' (statics consts and inherent impls). As a result WF and projection errors in a function signature now have a precise span which points directly at the responsible type. If a function signature is constructed via a macro this will allow the error message to point at the code 'most responsible' for the error (e.g. a user-supplied macro argument).,HEART,2021-07-19T15:31:29Z,jackh726,NA https://github.com/rust-lang/rust/pull/87271,MERGED,2021-07-19T10:19:24Z,2021-07-19T18:44:33Z,Update Clippy,flip1995,fad295b299d9e93950c27acd6a12026d100185fe,33,Auto merge of #87271 - flip1995:clippyup r=Manishearth Update Clippy This is an out-of-cycle Clippy update to fix 3 ICEs before the release (This should be merged before beta is branched): rust-lang/rust-clippy#7470 rust-lang/rust-clippy#7471 rust-lang/rust-clippy#7473 cc `@jackh726` `@JohnTitor` rust-lang/rust-clippy#7470 was caused by #86867. I saw the same ICE in the last rustup for Clippy though so this might be a more general problem. Is there something we should check before calling `layout_of`? Should we always check for `ty.has_escaping_bound_vars()` before calling `layout_of`? Or is this overkill? r? `@Manishearth`,THUMBS_UP,2021-07-19T11:46:00Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/87279,MERGED,2021-07-19T14:19:19Z,2021-07-21T16:35:32Z,Add comments explaining the unix command-line argument support.,sunfishcode,eb54ddd123d0c2d14968336189eb5ab9ab169c8e,1,Rollup merge of #87279 - sunfishcode:document-unix-argv r=RalfJung Add comments explaining the unix command-line argument support. Following up on #87236 add comments to the unix command-line argument support explaining that the code doesn't mutate the system-provided argc/argv and that this is why the code doesn't need a lock or special memory ordering. r? ```@RalfJung```,HEART,2021-07-19T14:35:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/87282,MERGED,2021-07-19T14:28:05Z,2021-08-02T04:59:10Z,Ensure `./x.py dist` adheres to `build.tools`,pietroalbini,46f01caab81a4e45b2f04a25c02b0e6c934bc1eb,3,"Rollup merge of #87282 - pietroalbini:refactor-extended r=Mark-Simulacrum Ensure `./x.py dist` adheres to `build.tools` According to `config.toml.example` the way to produce dist artifacts for both the compiler and a *subset* of tools would be to enable the extended build and manually specify the list of tools to build: ```toml [build] extended = true tools = [""cargo"" ""rustfmt""] ``` This works as expected for `./x.py build` and `./x.py install` but *not* for `./x.py dist`. Before this PR `./x.py dist` simply ignored the contents of `build.tools` building just rustc/rustdoc if `build.extended = false` and all of the tools otherwise. This PR does two things: * Changes `./x.py dist extended` to only build the tools defined in `build.tools` if `build.tools` is not empty. The rest of the extended step was refactored to simplify the code. * Changes how dist jobs for tools are gated: instead of `assert!(builder.config.extended)` to prevent tools from being built with `build.extended = false` tools are simply built by default depending on `build.extended` and `build.tools`. This also enables to **explicitly** dist tools even with `build.extended = false`. This PR is best reviewed commit-by-commit. Fixes #86436",HEART,2021-08-02T08:07:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T01:54:29Z,noiob,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T02:03:15Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T02:29:49Z,artemist,github.com@artem.ist https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T03:49:47Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T03:51:29Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T07:21:20Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T08:53:25Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T09:41:08Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T15:48:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T16:03:35Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T18:18:24Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-20T19:30:22Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-21T02:39:13Z,pcwalton,pcwalton@mimiga.net https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-21T17:25:38Z,weihanglo,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:46:29Z,porglezomp,code@witchoflight.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:46:48Z,dustywusty,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:46:55Z,CryZe,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:47:08Z,iximeow,git@iximeow.net https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:47:16Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:47:43Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:48:50Z,ash2x3zb9cy,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:49:11Z,smklein,seanmarionklein@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:49:21Z,Ravenslofty,dan.ravensloft@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:49:21Z,lachlansneff,lachlan@charted.space https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:49:45Z,Alexhuszagh,ahuszagh@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:50:00Z,FiloSottile,github@filippo.io https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:51:43Z,DrMcCoy,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:52:51Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:53:14Z,17cupsofcoffee,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:55:16Z,zseri,zseri.devel@ytrizja.de https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:55:40Z,xerz-one,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:57:24Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:58:47Z,JuanFdS,juan.fernandes@10pines.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T21:59:21Z,CalliEve,me@calli.dev https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:03:04Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:03:11Z,eloydegen,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:03:44Z,snorrwe,littlesnorrboy@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:08:33Z,sunjay,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:09:20Z,antonlogvinenko,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:09:51Z,dconnolly,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:10:33Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:15:41Z,StarToLeft,anton.hagser@epsidel.se https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:18:31Z,ChrisJefferson,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:21:16Z,Dr-Emann,dremann@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:24:55Z,oli-obk,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:31:03Z,asaaki,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:35:00Z,omppye,omppye@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:37:26Z,goyox86,goyox86@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:40:09Z,estebank,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:44:36Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T22:53:22Z,Hoverbear,operator@hoverbear.org https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:02:46Z,Noxime,aaro.peramaa@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:08:26Z,wmww,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:21:10Z,thecaralice,github@alice-carroll.pet https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:31:39Z,nnethercote,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:31:44Z,psinghal20,psinghal20@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-22T23:47:45Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T00:01:42Z,sigod,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T00:08:46Z,reese,reese@reesew.io https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T00:11:57Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T00:39:23Z,jackh726,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T03:19:15Z,mgattozzi,mgattozzi@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T05:11:08Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T05:52:54Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T06:46:28Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T09:35:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T09:50:53Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T10:13:58Z,spaarmann,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T11:08:59Z,nixon-transak,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T14:16:59Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T15:19:33Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T15:52:22Z,bjorn3,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T16:29:52Z,squeaky-pl,showerproof86@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-23T19:02:35Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-24T20:08:08Z,nuew,code@nuew.net https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-25T21:52:13Z,cabralski,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T18:58:40Z,spacejam,t@jujit.su https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T19:00:23Z,imjasonmiller,contact@jasonmiller.nl https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T19:09:28Z,LPGhatguy,me@lpghatguy.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T20:38:44Z,lqd,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T22:50:28Z,dbanetto,davidb@canva.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-07-26T23:57:57Z,al3xtjames,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-08-02T21:22:00Z,komuw,komuw05@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-08-08T14:11:27Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T15:12:55Z,HollayHorvath,hollay.horvath@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T15:30:26Z,Congee,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T16:01:05Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T16:10:46Z,awulkan,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T16:47:17Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T16:57:12Z,yash1th,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T19:12:38Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-09-09T19:23:06Z,aykxt,me@aykut.vip https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-10-17T11:16:21Z,Ryman,NA https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2021-11-05T14:35:48Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/87298,MERGED,2021-07-20T01:45:26Z,2021-07-23T15:14:57Z,memorialize Anna Harren in the bastion of the turbofish,boringcactus,0faf5e0451e8eefd00e21c383c528a5f827d5e42,1,Rollup merge of #87298 - boringcactus:patch-2 r=steveklabnik memorialize Anna Harren in the bastion of the turbofish this seems fitting at least to me.,HEART,2022-03-11T21:34:57Z,ilylily,NA https://github.com/rust-lang/rust/pull/87310,MERGED,2021-07-20T12:54:09Z,2021-07-20T16:03:53Z,Update MIRI,spastorino,5c0ca08c662399c1c864310d1a20867d3ab68027,1,Auto merge of #87310 - spastorino:update_miri r=RalfJung Update MIRI Fixes #87306 r? `@RalfJung`,HEART,2021-07-20T13:04:58Z,RalfJung,NA https://github.com/rust-lang/rust/pull/87315,MERGED,2021-07-20T17:20:07Z,2021-07-28T19:26:04Z,Add docs for raw-dylib to unstable book,ricobbe,911e22b57d05e7514accb55d25ad2083aae54201,1,Rollup merge of #87315 - ricobbe:raw-dylib-unstable-book r=wesleywiser Add docs for raw-dylib to unstable book,HEART,2021-07-21T04:04:45Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87316,OPEN,2021-07-20T17:24:31Z,NA,Error when proc macro derive output doesn't fully parse,m-ou-se,NA,NA,NA,THUMBS_UP,2021-07-20T18:19:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87320,MERGED,2021-07-20T20:43:53Z,2021-09-16T04:41:05Z,Introduce -Z remap-cwd-prefix switch,danakj,84646e9d67a5941d52bfa5a2ae4e4e29e30808fe,5,Rollup merge of #87320 - danakj:debug-compilation-dir r=michaelwoerister Introduce -Z remap-cwd-prefix switch This switch remaps any absolute paths rooted under the current working directory to a new value. This includes remapping the debug info in `DW_AT_comp_dir` and `DW_AT_decl_file`. Importantly this flag does not require passing the current working directory to the compiler such that the command line can be run on any machine (with the same input files) and produce the same results. This is critical property for debugging compiler issues that crop up on remote machines. This is based on adetaylor's https://github.com/rust-lang/rust/commit/dbc4ae7cba0ba8d650b91ddd459b86a02a2d05c5 Major Change Proposal: https://github.com/rust-lang/compiler-team/issues/450 Discussed on #38322. Would resolve issue #87325.,ROCKET,2021-09-14T20:40:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/87320,MERGED,2021-07-20T20:43:53Z,2021-09-16T04:41:05Z,Introduce -Z remap-cwd-prefix switch,danakj,84646e9d67a5941d52bfa5a2ae4e4e29e30808fe,5,Rollup merge of #87320 - danakj:debug-compilation-dir r=michaelwoerister Introduce -Z remap-cwd-prefix switch This switch remaps any absolute paths rooted under the current working directory to a new value. This includes remapping the debug info in `DW_AT_comp_dir` and `DW_AT_decl_file`. Importantly this flag does not require passing the current working directory to the compiler such that the command line can be run on any machine (with the same input files) and produce the same results. This is critical property for debugging compiler issues that crop up on remote machines. This is based on adetaylor's https://github.com/rust-lang/rust/commit/dbc4ae7cba0ba8d650b91ddd459b86a02a2d05c5 Major Change Proposal: https://github.com/rust-lang/compiler-team/issues/450 Discussed on #38322. Would resolve issue #87325.,HEART,2021-09-16T00:32:15Z,kinu,kinuko@chromium.org https://github.com/rust-lang/rust/pull/87320,MERGED,2021-07-20T20:43:53Z,2021-09-16T04:41:05Z,Introduce -Z remap-cwd-prefix switch,danakj,84646e9d67a5941d52bfa5a2ae4e4e29e30808fe,5,Rollup merge of #87320 - danakj:debug-compilation-dir r=michaelwoerister Introduce -Z remap-cwd-prefix switch This switch remaps any absolute paths rooted under the current working directory to a new value. This includes remapping the debug info in `DW_AT_comp_dir` and `DW_AT_decl_file`. Importantly this flag does not require passing the current working directory to the compiler such that the command line can be run on any machine (with the same input files) and produce the same results. This is critical property for debugging compiler issues that crop up on remote machines. This is based on adetaylor's https://github.com/rust-lang/rust/commit/dbc4ae7cba0ba8d650b91ddd459b86a02a2d05c5 Major Change Proposal: https://github.com/rust-lang/compiler-team/issues/450 Discussed on #38322. Would resolve issue #87325.,HEART,2021-09-21T08:02:35Z,hlopko,hlopko@google.com https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,ROCKET,2021-07-21T01:28:05Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-07-21T01:28:07Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-07-21T05:05:52Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-07-21T05:05:56Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-07-21T07:54:12Z,iago-lito,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-07-25T17:35:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-07-25T17:35:12Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-07-28T09:16:19Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-07-28T09:16:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-08-12T19:22:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-08-12T19:22:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-08-26T11:35:21Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-08-27T09:47:53Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-08-27T09:47:53Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,ROCKET,2021-08-27T09:47:55Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HOORAY,2021-08-27T21:36:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,HEART,2021-08-27T21:36:32Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87329,MERGED,2021-07-21T00:39:35Z,2021-08-20T13:41:45Z,I/O safety.,sunfishcode,521734787ecf80ff12df7ca5998f7ec0b3b7b2c9,57,Auto merge of #87329 - sunfishcode:sunfishcode/io-safety r=joshtriplett I/O safety. Introduce `OwnedFd` and `BorrowedFd` and the `AsFd` trait and implementations of `AsFd` `From` and `From for OwnedFd` for relevant types along with Windows counterparts for handles and sockets. Tracking issue: RFC: Highlights: - The doc comments at the top of library/std/src/os/unix/io/mod.rs and library/std/src/os/windows/io/mod.rs - The new types and traits in library/std/src/os/unix/io/fd.rs and library/std/src/os/windows/io/handle.rs - The removal of the `RawHandle` struct the Windows impl which had the same name as the `RawHandle` type alias and its functionality is now folded into `Handle`. Managing five levels of wrapping (File wraps sys::fs::File wraps sys::fs::FileDesc wraps OwnedFd wraps RawFd etc.) made for a fair amount of churn and verbose as/into/from sequences in some places. I've managed to simplify some of them but I'm open to ideas here. r? `@joshtriplett`,ROCKET,2021-08-27T21:36:32Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-07-23T06:20:07Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-07-23T16:32:39Z,hkratz,NA https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-03T11:17:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-12T14:08:22Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-14T10:15:48Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-15T14:13:25Z,DianaNites,NA https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-21T11:31:03Z,Folyd,NA https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-22T14:55:24Z,jswrenn,me@jswrenn.com https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-27T00:59:57Z,mohe2015,NA https://github.com/rust-lang/rust/pull/87339,CLOSED,2021-07-21T03:51:40Z,2021-11-21T21:32:21Z,Make two Paths unequal if they differ in trailing slash,dtolnay,NA,NA,NA,THUMBS_DOWN,2021-10-29T11:28:00Z,maxwase,max.vvase@gmail.com https://github.com/rust-lang/rust/pull/87349,CLOSED,2021-07-21T14:26:04Z,2022-03-20T05:59:41Z,Prefer suggestion paths which are not doc-hidden ,In-line,NA,NA,NA,HEART,2021-09-21T18:26:02Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/87349,CLOSED,2021-07-21T14:26:04Z,2022-03-20T05:59:41Z,Prefer suggestion paths which are not doc-hidden ,In-line,NA,NA,NA,HEART,2021-09-24T18:15:16Z,estebank,NA https://github.com/rust-lang/rust/pull/87349,CLOSED,2021-07-21T14:26:04Z,2022-03-20T05:59:41Z,Prefer suggestion paths which are not doc-hidden ,In-line,NA,NA,NA,HEART,2021-11-21T11:22:45Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/87349,CLOSED,2021-07-21T14:26:04Z,2022-03-20T05:59:41Z,Prefer suggestion paths which are not doc-hidden ,In-line,NA,NA,NA,HEART,2021-12-21T19:23:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87359,MERGED,2021-07-22T02:21:29Z,2021-07-24T20:01:51Z,Remove detection of rustup and cargo in 'missing extern crate' diagnostics,jyn514,bfa0358d2a7d0f0989b3a4374df9077fece170f9,5,Rollup merge of #87359 - jyn514:bless-rustup r=estebank Remove detection of rustup and cargo in 'missing extern crate' diagnostics Previously this would change the test output when RUSTUP_HOME was set: ``` ---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ---- diff of stderr: 1 error[E0463]: can't find crate for `core` 2 | 3 = note: the `thumbv7em-none-eabihf` target may not be installed + = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf` 4 5 error: aborting due to previous error 6 ``` Originally I fixed it by explicitly unsetting RUSTUP_HOME in compiletest. Then I realized that almost no one has RUSTUP_HOME set since rustup doesn't set it itself. It does set RUST_RECURSION_COUNT whenever it launches a proxy though - use that instead. r? ```@estebank``` cc ```@petrochenkov``` ```@kinnison```,HEART,2021-07-22T05:21:43Z,crlf0710,NA https://github.com/rust-lang/rust/pull/87359,MERGED,2021-07-22T02:21:29Z,2021-07-24T20:01:51Z,Remove detection of rustup and cargo in 'missing extern crate' diagnostics,jyn514,bfa0358d2a7d0f0989b3a4374df9077fece170f9,5,Rollup merge of #87359 - jyn514:bless-rustup r=estebank Remove detection of rustup and cargo in 'missing extern crate' diagnostics Previously this would change the test output when RUSTUP_HOME was set: ``` ---- [ui] ui/issues/issue-49851/compiler-builtins-error.rs stdout ---- diff of stderr: 1 error[E0463]: can't find crate for `core` 2 | 3 = note: the `thumbv7em-none-eabihf` target may not be installed + = help: consider downloading the target with `rustup target add thumbv7em-none-eabihf` 4 5 error: aborting due to previous error 6 ``` Originally I fixed it by explicitly unsetting RUSTUP_HOME in compiletest. Then I realized that almost no one has RUSTUP_HOME set since rustup doesn't set it itself. It does set RUST_RECURSION_COUNT whenever it launches a proxy though - use that instead. r? ```@estebank``` cc ```@petrochenkov``` ```@kinnison```,HEART,2021-07-22T09:06:59Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/87375,MERGED,2021-07-22T16:05:06Z,2021-08-14T14:52:37Z,Try filtering out non-const impls when we expect const impls,fee1-dead,136eaa1b25d13635b773a481ecab61a3162cb627,68,Auto merge of #87375 - fee1-dead:move-constness-to-traitpred r=oli-obk Try filtering out non-const impls when we expect const impls **TL;DR**: Associated types on const impls are now bounded; we now disallow calling a const function with bounds when the specified type param only has a non-const impl. r? `@oli-obk`,THUMBS_UP,2021-07-22T17:06:15Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87383,MERGED,2021-07-22T18:45:48Z,2021-07-23T15:14:56Z,Add regression tests for the impl_trait_in_bindings ICEs,Alexendoo,7c0c329635cde6602dc6d49a0f44459ff0c8b544,20,Rollup merge of #87383 - Alexendoo:impl_trait_in_bindings-tests r=oli-obk Add regression tests for the impl_trait_in_bindings ICEs Closes #54600 closes #54840 closes #58504 closes #58956 closes #70971 closes #79099 closes #84919 closes #86201 closes #86642 closes #87295 r? ``@oli-obk``,HEART,2021-07-22T22:15:07Z,oli-obk,NA https://github.com/rust-lang/rust/pull/87383,MERGED,2021-07-22T18:45:48Z,2021-07-23T15:14:56Z,Add regression tests for the impl_trait_in_bindings ICEs,Alexendoo,7c0c329635cde6602dc6d49a0f44459ff0c8b544,20,Rollup merge of #87383 - Alexendoo:impl_trait_in_bindings-tests r=oli-obk Add regression tests for the impl_trait_in_bindings ICEs Closes #54600 closes #54840 closes #58504 closes #58956 closes #70971 closes #79099 closes #84919 closes #86201 closes #86642 closes #87295 r? ``@oli-obk``,HEART,2021-07-26T23:41:34Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/87402,MERGED,2021-07-23T13:28:32Z,2022-03-02T05:32:08Z,Direct users towards using Rust target feature names in CLI,nagisa,39a3b527674c1c8d2b9d3edc0cfae67abe6b3ecb,22,Auto merge of #87402 - nagisa:nagisa/request-feature-requests-for-features r=estebank Direct users towards using Rust target feature names in CLI This PR consists of a couple of changes on how we handle target features. In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed). The other commit I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific or otherwise unknown feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all if users are specifying these features on the command line I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery. And second we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me. Sponsored by: standard.ai,THUMBS_UP,2021-09-25T01:14:26Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-07-23T16:15:14Z,hkratz,NA https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-07-23T16:19:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,HEART,2021-07-23T17:53:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-08-04T03:50:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,HEART,2021-08-04T03:50:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-08-12T19:23:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,HEART,2021-08-12T19:23:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-10-23T20:49:45Z,Sl1mb0,NA https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,HEART,2021-10-23T20:49:46Z,Sl1mb0,NA https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,THUMBS_UP,2021-10-28T06:04:01Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87404,MERGED,2021-07-23T14:29:02Z,2021-10-20T01:16:25Z,Add support for artifact size profiling,rylev,3d9533023004bc05d6bf65e1339e29aceac76f62,8,Rollup merge of #87404 - rylev:artifact-size-profiling r=wesleywiser Add support for artifact size profiling This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with). Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request. This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency. This was worked on together with `@michaelwoerister.` r? `@wesleywiser`,HEART,2021-10-28T06:04:02Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87410,MERGED,2021-07-23T17:05:05Z,2021-07-24T20:01:50Z,Mark `format_args_nl` as `#[doc(hidden)]`,jonas-schievink,e932113c7eb2805154d8ef0419fa5bffdebe38b8,1,Rollup merge of #87410 - jonas-schievink:doc-hidden-format_args_nl r=nagisa Mark `format_args_nl` as `#[doc(hidden)]` It's described as being internal-only and has no tracking issue so hide it from public docs.,HOORAY,2021-07-23T18:02:05Z,lnicola,NA https://github.com/rust-lang/rust/pull/87410,MERGED,2021-07-23T17:05:05Z,2021-07-24T20:01:50Z,Mark `format_args_nl` as `#[doc(hidden)]`,jonas-schievink,e932113c7eb2805154d8ef0419fa5bffdebe38b8,1,Rollup merge of #87410 - jonas-schievink:doc-hidden-format_args_nl r=nagisa Mark `format_args_nl` as `#[doc(hidden)]` It's described as being internal-only and has no tracking issue so hide it from public docs.,HOORAY,2021-07-24T06:13:38Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87431,MERGED,2021-07-24T15:59:29Z,2021-07-27T13:24:29Z,implement fold() on array::IntoIter to improve flatten().collect() perf,the8472,99d6692f6c1cebd6c56a67eb21f6aae26c12a145,2,Auto merge of #87431 - the8472:array-iter-fold r=kennytm implement fold() on array::IntoIter to improve flatten().collect() perf With #87168 flattening `array::IntoIter`s is now `TrustedLen` the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features. This should address the main issue in #87411 ``` # old test vec::bench_flat_map_collect ... bench: 2 244 024 ns/iter (+/- 18 903) # new test vec::bench_flat_map_collect ... bench: 172 863 ns/iter (+/- 2 141) ```,HOORAY,2021-07-24T19:45:55Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/87431,MERGED,2021-07-24T15:59:29Z,2021-07-27T13:24:29Z,implement fold() on array::IntoIter to improve flatten().collect() perf,the8472,99d6692f6c1cebd6c56a67eb21f6aae26c12a145,2,Auto merge of #87431 - the8472:array-iter-fold r=kennytm implement fold() on array::IntoIter to improve flatten().collect() perf With #87168 flattening `array::IntoIter`s is now `TrustedLen` the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features. This should address the main issue in #87411 ``` # old test vec::bench_flat_map_collect ... bench: 2 244 024 ns/iter (+/- 18 903) # new test vec::bench_flat_map_collect ... bench: 172 863 ns/iter (+/- 2 141) ```,HOORAY,2021-07-25T22:48:36Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87431,MERGED,2021-07-24T15:59:29Z,2021-07-27T13:24:29Z,implement fold() on array::IntoIter to improve flatten().collect() perf,the8472,99d6692f6c1cebd6c56a67eb21f6aae26c12a145,2,Auto merge of #87431 - the8472:array-iter-fold r=kennytm implement fold() on array::IntoIter to improve flatten().collect() perf With #87168 flattening `array::IntoIter`s is now `TrustedLen` the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features. This should address the main issue in #87411 ``` # old test vec::bench_flat_map_collect ... bench: 2 244 024 ns/iter (+/- 18 903) # new test vec::bench_flat_map_collect ... bench: 172 863 ns/iter (+/- 2 141) ```,HOORAY,2021-07-27T13:41:33Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87431,MERGED,2021-07-24T15:59:29Z,2021-07-27T13:24:29Z,implement fold() on array::IntoIter to improve flatten().collect() perf,the8472,99d6692f6c1cebd6c56a67eb21f6aae26c12a145,2,Auto merge of #87431 - the8472:array-iter-fold r=kennytm implement fold() on array::IntoIter to improve flatten().collect() perf With #87168 flattening `array::IntoIter`s is now `TrustedLen` the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features. This should address the main issue in #87411 ``` # old test vec::bench_flat_map_collect ... bench: 2 244 024 ns/iter (+/- 18 903) # new test vec::bench_flat_map_collect ... bench: 172 863 ns/iter (+/- 2 141) ```,HOORAY,2021-08-05T11:56:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87431,MERGED,2021-07-24T15:59:29Z,2021-07-27T13:24:29Z,implement fold() on array::IntoIter to improve flatten().collect() perf,the8472,99d6692f6c1cebd6c56a67eb21f6aae26c12a145,2,Auto merge of #87431 - the8472:array-iter-fold r=kennytm implement fold() on array::IntoIter to improve flatten().collect() perf With #87168 flattening `array::IntoIter`s is now `TrustedLen` the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features. This should address the main issue in #87411 ``` # old test vec::bench_flat_map_collect ... bench: 2 244 024 ns/iter (+/- 18 903) # new test vec::bench_flat_map_collect ... bench: 172 863 ns/iter (+/- 2 141) ```,HOORAY,2021-08-05T15:12:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87440,MERGED,2021-07-24T20:30:08Z,2021-10-21T10:59:28Z,Remove unnecessary condition in Barrier::wait(),twetzel59,fb9232b45316c3875e12a242d4250e959c7bc24a,1,"Rollup merge of #87440 - twetzel59:fix-barrier-no-op r=yaahc Remove unnecessary condition in Barrier::wait() This is my first pull request for Rust so feel free to call me out if anything is amiss. After some examination I realized that the second condition of the ""spurious-wakeup-handler"" loop in ``std::sync::Barrier::wait()`` should always evaluate to ``true`` making it redundant in the ``&&`` expression. Here is the affected function before the fix: ```rust #[stable(feature = ""rust1"" since = ""1.0.0"")] pub fn wait(&self) -> BarrierWaitResult { let mut lock = self.lock.lock().unwrap(); let local_gen = lock.generation_id; lock.count += 1; if lock.count < self.num_threads { // We need a while loop to guard against spurious wakeups. // https://en.wikipedia.org/wiki/Spurious_wakeup while local_gen == lock.generation_id && lock.count < self.num_threads { // fixme lock = self.cvar.wait(lock).unwrap(); } BarrierWaitResult(false) } else { lock.count = 0; lock.generation_id = lock.generation_id.wrapping_add(1); self.cvar.notify_all(); BarrierWaitResult(true) } } ``` At first glance it seems that the check that ``lock.count < self.num_threads`` would be necessary in order for a thread A to detect when another thread B has caused the barrier to reach its thread count making thread B the ""leader"". However the control flow implicitly results in an invariant that makes observing ``!(lock.count < self.num_threads)`` i.e. ``lock.count >= self.num_threads`` impossible from thread A. When thread B which will be the leader calls ``.wait()`` on this shared instance of the ``Barrier`` it locks the mutex in the first line and saves the ``MutexGuard`` in the ``lock`` variable. It then increments the value of ``lock.count``. However it then proceeds to check if ``lock.count < self.num_threads``. Since it is the leader it is the case that (after the increment of ``lock.count``) the lock count is *equal* to the number of threads. Thus the second branch is immediately taken and ``lock.count`` is zeroed. Additionally the generation ID is incremented (with wrap). Then the condition variable is signalled. But the other threads are waiting at the line ``lock = self.cvar.wait(lock).unwrap();`` so they cannot resume until thread B's call to ``Barrier::wait()`` returns which drops the ``MutexGuard`` acquired in the first ``let`` statement and unlocks the mutex. The order of events is thus: 1. A thread A calls `.wait()` 2. `.wait()` acquires the mutex increments `lock.count` and takes the first branch 3. Thread A enters the ``while`` loop since the generation ID has not changed and the count is less than the number of threads for the ``Barrier`` 3. Spurious wakeups occur but both conditions hold so the thread A waits on the condition variable 4. This process repeats for N - 2 additional times for non-leader threads A' 5. *Meanwhile* Thread B calls ``Barrier::wait()`` on the same barrier that threads A A' A'' etc. are waiting on. The thread count reaches the number of threads for the ``Barrier`` so all threads should now proceed with B being the leader. B acquires the mutex and increments the value ``lock.count`` only to find that it is not less than ``self.num_threads``. Thus it immediately clamps ``self.num_threads`` back down to 0 and increments the generation. Then it signals the condvar to tell the A (prime) threads that they may continue. 6. The A A' A''... threads wake up and attempt to re-acquire the ``lock`` as per the internal operation of a condition variable. When each A has exclusive access to the mutex it finds that ``lock.generation_id`` no longer matches ``local_generation`` **and the ``&&`` expression short-circuits -- and even if it were to evaluate it ``self.count`` is definitely less than ``self.num_threads`` because it has been reset to ``0`` by thread B *before* B dropped its ``MutexGuard``**. Therefore it my understanding that it would be impossible for the non-leader threads to ever see the second boolean expression evaluate to anything other than ``true``. This PR simply removes that condition. Any input would be appreciated. Sorry if this is terribly verbose. I'm new to the Rust community and concurrency can be hard to explain in words. Thanks!",THUMBS_UP,2021-09-06T18:07:42Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/87440,MERGED,2021-07-24T20:30:08Z,2021-10-21T10:59:28Z,Remove unnecessary condition in Barrier::wait(),twetzel59,fb9232b45316c3875e12a242d4250e959c7bc24a,1,"Rollup merge of #87440 - twetzel59:fix-barrier-no-op r=yaahc Remove unnecessary condition in Barrier::wait() This is my first pull request for Rust so feel free to call me out if anything is amiss. After some examination I realized that the second condition of the ""spurious-wakeup-handler"" loop in ``std::sync::Barrier::wait()`` should always evaluate to ``true`` making it redundant in the ``&&`` expression. Here is the affected function before the fix: ```rust #[stable(feature = ""rust1"" since = ""1.0.0"")] pub fn wait(&self) -> BarrierWaitResult { let mut lock = self.lock.lock().unwrap(); let local_gen = lock.generation_id; lock.count += 1; if lock.count < self.num_threads { // We need a while loop to guard against spurious wakeups. // https://en.wikipedia.org/wiki/Spurious_wakeup while local_gen == lock.generation_id && lock.count < self.num_threads { // fixme lock = self.cvar.wait(lock).unwrap(); } BarrierWaitResult(false) } else { lock.count = 0; lock.generation_id = lock.generation_id.wrapping_add(1); self.cvar.notify_all(); BarrierWaitResult(true) } } ``` At first glance it seems that the check that ``lock.count < self.num_threads`` would be necessary in order for a thread A to detect when another thread B has caused the barrier to reach its thread count making thread B the ""leader"". However the control flow implicitly results in an invariant that makes observing ``!(lock.count < self.num_threads)`` i.e. ``lock.count >= self.num_threads`` impossible from thread A. When thread B which will be the leader calls ``.wait()`` on this shared instance of the ``Barrier`` it locks the mutex in the first line and saves the ``MutexGuard`` in the ``lock`` variable. It then increments the value of ``lock.count``. However it then proceeds to check if ``lock.count < self.num_threads``. Since it is the leader it is the case that (after the increment of ``lock.count``) the lock count is *equal* to the number of threads. Thus the second branch is immediately taken and ``lock.count`` is zeroed. Additionally the generation ID is incremented (with wrap). Then the condition variable is signalled. But the other threads are waiting at the line ``lock = self.cvar.wait(lock).unwrap();`` so they cannot resume until thread B's call to ``Barrier::wait()`` returns which drops the ``MutexGuard`` acquired in the first ``let`` statement and unlocks the mutex. The order of events is thus: 1. A thread A calls `.wait()` 2. `.wait()` acquires the mutex increments `lock.count` and takes the first branch 3. Thread A enters the ``while`` loop since the generation ID has not changed and the count is less than the number of threads for the ``Barrier`` 3. Spurious wakeups occur but both conditions hold so the thread A waits on the condition variable 4. This process repeats for N - 2 additional times for non-leader threads A' 5. *Meanwhile* Thread B calls ``Barrier::wait()`` on the same barrier that threads A A' A'' etc. are waiting on. The thread count reaches the number of threads for the ``Barrier`` so all threads should now proceed with B being the leader. B acquires the mutex and increments the value ``lock.count`` only to find that it is not less than ``self.num_threads``. Thus it immediately clamps ``self.num_threads`` back down to 0 and increments the generation. Then it signals the condvar to tell the A (prime) threads that they may continue. 6. The A A' A''... threads wake up and attempt to re-acquire the ``lock`` as per the internal operation of a condition variable. When each A has exclusive access to the mutex it finds that ``lock.generation_id`` no longer matches ``local_generation`` **and the ``&&`` expression short-circuits -- and even if it were to evaluate it ``self.count`` is definitely less than ``self.num_threads`` because it has been reset to ``0`` by thread B *before* B dropped its ``MutexGuard``**. Therefore it my understanding that it would be impossible for the non-leader threads to ever see the second boolean expression evaluate to anything other than ``true``. This PR simply removes that condition. Any input would be appreciated. Sorry if this is terribly verbose. I'm new to the Rust community and concurrency can be hard to explain in words. Thanks!",THUMBS_UP,2021-11-01T01:10:41Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/87441,MERGED,2021-07-24T21:39:47Z,2021-09-11T06:30:46Z,Emit suggestion when passing byte literal to format macro,ibraheemdev,358a01829229427d9efaf89a05881a0ef86e9e8a,5,Rollup merge of #87441 - ibraheemdev:i-86865 r=cjgillot Emit suggestion when passing byte literal to format macro Closes #86865,HEART,2021-10-05T20:58:31Z,insanitybit,insanitybit@gmail.com https://github.com/rust-lang/rust/pull/87446,MERGED,2021-07-25T05:04:21Z,2021-07-27T16:17:11Z,macos current_exe using directly libc instead.,devnexen,988f617f2a78d4449ecb5fef26fa14825fc8ecc8,3,Rollup merge of #87446 - devnexen:macos_update r=dtolnay macos current_exe using directly libc instead.,THUMBS_UP,2021-07-26T04:09:30Z,hkratz,NA https://github.com/rust-lang/rust/pull/87449,MERGED,2021-07-25T10:30:09Z,2021-08-01T11:56:02Z,more clippy::complexity fixes,matthiaskrgr,aadd6189ad5c81f50d942c584ed1c1b49892765f,32,Auto merge of #87449 - matthiaskrgr:clippyy_v2 r=nagisa more clippy::complexity fixes (also a couple of clippy::perf fixes),THUMBS_UP,2021-07-25T15:46:45Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87451,MERGED,2021-07-25T12:59:05Z,2021-07-29T00:31:10Z,Add support for tuple struct field documentation,GuillaumeGomez,014e22c836b649229023451af79c60fff1185888,6,Rollup merge of #87451 - GuillaumeGomez:tuple-struct-field-doc r=jyn514 Add support for tuple struct field documentation Fixes #42615. This is #80320 updated to new codebase and with added tests. Part of https://github.com/rust-lang/rust/issues/83255. cc ```@camelid``` (since you were involved on the original PR). r? ```@jyn514```,THUMBS_UP,2021-07-25T15:06:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87451,MERGED,2021-07-25T12:59:05Z,2021-07-29T00:31:10Z,Add support for tuple struct field documentation,GuillaumeGomez,014e22c836b649229023451af79c60fff1185888,6,Rollup merge of #87451 - GuillaumeGomez:tuple-struct-field-doc r=jyn514 Add support for tuple struct field documentation Fixes #42615. This is #80320 updated to new codebase and with added tests. Part of https://github.com/rust-lang/rust/issues/83255. cc ```@camelid``` (since you were involved on the original PR). r? ```@jyn514```,HEART,2021-07-26T21:22:09Z,camelid,NA https://github.com/rust-lang/rust/pull/87451,MERGED,2021-07-25T12:59:05Z,2021-07-29T00:31:10Z,Add support for tuple struct field documentation,GuillaumeGomez,014e22c836b649229023451af79c60fff1185888,6,Rollup merge of #87451 - GuillaumeGomez:tuple-struct-field-doc r=jyn514 Add support for tuple struct field documentation Fixes #42615. This is #80320 updated to new codebase and with added tests. Part of https://github.com/rust-lang/rust/issues/83255. cc ```@camelid``` (since you were involved on the original PR). r? ```@jyn514```,THUMBS_UP,2021-08-03T20:02:28Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/87460,MERGED,2021-07-25T18:11:51Z,2021-09-17T18:48:37Z,Point to closure when emitting 'cannot move out' for captured variable,FabianWolff,aed7f000974d240c596f20e562718e3324161fba,13,Rollup merge of #87460 - FabianWolff:issue-87456 r=Aaron1011 Point to closure when emitting 'cannot move out' for captured variable Attempts to fix #87456. The error message now points to the capturing closure but I was not able to explain _why_ the closure implements `Fn` or `FnMut` (`TypeckResults::closure_kind_origins` did not contain anything for the closure in question). cc `@Aaron1011`,THUMBS_UP,2021-07-25T18:15:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87465,MERGED,2021-07-25T23:53:43Z,2021-08-09T03:59:30Z,Simplify typeck/primary_body_of fix comment to match return signature,audunhalland,d3928b183db1023c023f8afb4f5dfbee34994051,1,Auto merge of #87465 - audunhalland:refactor_typeck_primary_body_of r=eddyb Simplify typeck/primary_body_of fix comment to match return signature Hi new contributor here! I'm carefully reading through the various modules just to learn. I noticed this function `primary_body_of` which has gone through a couple of refactors over time adding new `Option`s to its returned tuple. Observations: 1. the `fn`'s documentation was not all up to date with the the current return signature. 2. `FnHeader` and `FnDecl` are always both `Some` or `None`. So I figured it might just return a reference to the full `hir::FnSig` for simplicity and more precise typing. It's a pure refactor. I'm learning better by working with code than just reading it so here goes! If you want to avoid pure refactor PRs that don't really fix anything I can revert the code change to only update the comment instead.,THUMBS_UP,2021-07-27T17:33:06Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87468,MERGED,2021-07-26T04:02:36Z,2021-08-02T04:59:09Z,Update rustfmt,calebcartwright,e95b0ffe74fef7fb06c9b9fdb6e0767a0919c060,39,Rollup merge of #87468 - calebcartwright:update-rustfmt r=Mark-Simulacrum Update rustfmt Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity but going forward will try to get on the same recurring cadence that clippy follows,ROCKET,2021-07-26T15:37:37Z,PsiACE,PsiACE@Outlook.com https://github.com/rust-lang/rust/pull/87468,MERGED,2021-07-26T04:02:36Z,2021-08-02T04:59:09Z,Update rustfmt,calebcartwright,e95b0ffe74fef7fb06c9b9fdb6e0767a0919c060,39,Rollup merge of #87468 - calebcartwright:update-rustfmt r=Mark-Simulacrum Update rustfmt Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity but going forward will try to get on the same recurring cadence that clippy follows,ROCKET,2021-07-29T05:34:48Z,BohuTANG,overred.shuttler@gmail.com https://github.com/rust-lang/rust/pull/87468,MERGED,2021-07-26T04:02:36Z,2021-08-02T04:59:09Z,Update rustfmt,calebcartwright,e95b0ffe74fef7fb06c9b9fdb6e0767a0919c060,39,Rollup merge of #87468 - calebcartwright:update-rustfmt r=Mark-Simulacrum Update rustfmt Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity but going forward will try to get on the same recurring cadence that clippy follows,ROCKET,2021-07-29T06:18:21Z,sundy-li,NA https://github.com/rust-lang/rust/pull/87468,MERGED,2021-07-26T04:02:36Z,2021-08-02T04:59:09Z,Update rustfmt,calebcartwright,e95b0ffe74fef7fb06c9b9fdb6e0767a0919c060,39,Rollup merge of #87468 - calebcartwright:update-rustfmt r=Mark-Simulacrum Update rustfmt Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity but going forward will try to get on the same recurring cadence that clippy follows,ROCKET,2021-07-30T07:04:11Z,Luro02,NA https://github.com/rust-lang/rust/pull/87468,MERGED,2021-07-26T04:02:36Z,2021-08-02T04:59:09Z,Update rustfmt,calebcartwright,e95b0ffe74fef7fb06c9b9fdb6e0767a0919c060,39,Rollup merge of #87468 - calebcartwright:update-rustfmt r=Mark-Simulacrum Update rustfmt Believe this gets everything back in order as both push and pull are working fine again. May do another small sync in the near future for my own sanity but going forward will try to get on the same recurring cadence that clippy follows,ROCKET,2021-07-30T15:18:48Z,LeCyberDucky,NA https://github.com/rust-lang/rust/pull/87471,CLOSED,2021-07-26T07:47:01Z,2021-07-30T17:48:37Z,parse and handle `where T = U` predicate,JulianKnodt,NA,NA,NA,EYES,2021-07-26T10:41:37Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/87471,CLOSED,2021-07-26T07:47:01Z,2021-07-30T17:48:37Z,parse and handle `where T = U` predicate,JulianKnodt,NA,NA,NA,EYES,2021-07-28T02:32:47Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/87471,CLOSED,2021-07-26T07:47:01Z,2021-07-30T17:48:37Z,parse and handle `where T = U` predicate,JulianKnodt,NA,NA,NA,EYES,2021-07-28T13:49:23Z,fmease,NA https://github.com/rust-lang/rust/pull/87471,CLOSED,2021-07-26T07:47:01Z,2021-07-30T17:48:37Z,parse and handle `where T = U` predicate,JulianKnodt,NA,NA,NA,HEART,2021-07-28T13:49:31Z,fmease,NA https://github.com/rust-lang/rust/pull/87476,MERGED,2021-07-26T11:21:15Z,2021-07-26T17:23:21Z,Prepare 1.54.0 release,pietroalbini,a178d0322ce20e33eac124758e837cbd80a6f633,103,Auto merge of #87476 - pietroalbini:stable-next r=Mark-Simulacrum Prepare 1.54.0 release This PR builds the stable artifacts for the 1.54.0 release. Backports included: * https://github.com/rust-lang/rust/pull/86696 * #87167 * #87210 I was *not* able to cherry-pick https://github.com/rust-lang/rust/pull/87390 as that didn't apply cleanly to the stable branch. `@GuillaumeGomez` `@notriddle` could it be possible to get a PR targeting `stable` backporting that fix? Also this **enables** incremental compilation on the stable channel. r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-07-26T11:38:24Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87476,MERGED,2021-07-26T11:21:15Z,2021-07-26T17:23:21Z,Prepare 1.54.0 release,pietroalbini,a178d0322ce20e33eac124758e837cbd80a6f633,103,Auto merge of #87476 - pietroalbini:stable-next r=Mark-Simulacrum Prepare 1.54.0 release This PR builds the stable artifacts for the 1.54.0 release. Backports included: * https://github.com/rust-lang/rust/pull/86696 * #87167 * #87210 I was *not* able to cherry-pick https://github.com/rust-lang/rust/pull/87390 as that didn't apply cleanly to the stable branch. `@GuillaumeGomez` `@notriddle` could it be possible to get a PR targeting `stable` backporting that fix? Also this **enables** incremental compilation on the stable channel. r? `@Mark-Simulacrum` cc `@rust-lang/release`,HOORAY,2021-07-26T12:14:34Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/87487,MERGED,2021-07-26T17:40:54Z,2022-01-10T11:53:21Z,Fixes wrong unreachable_pub lints on nested and glob public reexport,lambinoo,df035a33b228daa700ac50712d9e16509d373e41,19,Auto merge of #87487 - lambinoo:I-64762_unreachable_pub_lint r=petrochenkov Fixes wrong unreachable_pub lints on nested and glob public reexport Linked issues: #64762 & #82064,HEART,2022-01-10T19:12:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-07-26T19:13:32Z,boringcactus,melody@boringcactus.com https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-07-28T08:08:26Z,In-line,Inline0@protonmail.com https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-09-09T15:18:28Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-09-09T15:25:37Z,1t2t3t4t,NA https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-09-09T16:49:46Z,kMeillet,robin.meillet@epitech.eu https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-09-09T22:22:38Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/87491,MERGED,2021-07-26T19:11:06Z,2021-07-29T00:31:09Z,Integrate context into the memorial to Anna,jamesmunns,aa301a06604a0cd541f65deeadc16f9befb24249,1,Rollup merge of #87491 - jamesmunns:integrate-memorial r=Mark-Simulacrum Integrate context into the memorial to Anna This came up after I reviewed https://github.com/rust-lang/rust/pull/87298 but I didn't propose this in time before that PR was merged. If y'all feel this is too much churn on the file no worries feel free to close but I felt this was a more fitting integration of the memorial into the test suite. CC ``@boringcactus.``,HEART,2021-11-05T14:35:41Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/87513,MERGED,2021-07-27T14:28:04Z,2021-07-28T19:26:03Z,bootstrap.py: change `git log` option to indicate desired behavior,hudson-ayers,168238246fa6a6aa1da7e38d38a1977a96f43430,1,Rollup merge of #87513 - hudson-ayers:bootstrap-py-fix r=jyn514 bootstrap.py: change `git log` option to indicate desired behavior When determining which LLVM artifacts to download bootstrap.py calls: `git log --author=bors --format=%H -n1 -m --first-parent -- src/llvm-project src/bootstrap/download-ci-llvm-stamp src/version`. However the `-m` option has no effect per the `git log` help: > -m > This option makes diff output for merge commits to be shown in the > default format. -m will produce the output only if -p is given as > well. The default format could be changed using log.diffMerges > configuration parameter which default value is separate. Accordingly this commit removes use of the -m option in favor of ~~`--diff-merges=off`~~ `--no-patch` since no diff information is needed and in fact the presence of a diff breaks the command. Tested using git 2.32 this does not change the output of the command. The motivation for this change is that some patched versions of git change the behavior of the `-m` flag to imply `-p` rather than to do nothing unless `-p` is passed. These patched versions of git lead to this script not working. Google's corp-provided git is one such example.,HEART,2021-07-29T00:21:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/87530,MERGED,2021-07-27T22:52:30Z,2021-11-09T17:13:56Z,Add comments regarding superfluous `!Sync` impls,bstrie,d638c1d13c8fa82a24ed07e8da9dd7c823cc6f13,2,Rollup merge of #87530 - bstrie:commentsync r=bstrie Add comments regarding superfluous `!Sync` impls,THUMBS_UP,2021-07-30T18:02:26Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/87546,MERGED,2021-07-28T12:24:36Z,2021-08-01T14:16:36Z,Bail on any found recursion when expanding opaque types,hkratz,8d57c0ab2b2e1aae07c1b8638358fb7a909940bc,3,Auto merge of #87546 - rusticstuff:issue87450-take-two r=davidtwco Bail on any found recursion when expanding opaque types Fixes #87450. More of a bandaid because it does not fix the exponential complexity of the type folding used for opaque type expansion.,ROCKET,2021-08-07T01:22:09Z,tmandry,NA https://github.com/rust-lang/rust/pull/87559,MERGED,2021-07-28T17:09:33Z,2021-07-30T22:26:46Z,Tweak borrowing suggestion in `for` loop,estebank,5e2655d27fdd523285856f8bdacbccdc07b4fc6c,5,Rollup merge of #87559 - estebank:consider-borrowing r=oli-obk Tweak borrowing suggestion in `for` loop,ROCKET,2021-08-06T23:48:44Z,lopopolo,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-28T22:35:13Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-28T22:43:57Z,voidc,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-28T23:18:39Z,tmandry,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T01:14:48Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T06:16:15Z,taiki-e,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T06:19:31Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T06:50:11Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T08:09:59Z,hkratz,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T11:00:23Z,mati865,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-29T12:16:11Z,estebank,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-07-30T07:35:17Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-07-30T07:35:24Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-06T17:09:56Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-10T18:05:04Z,bluss,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-12T19:28:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-08-12T19:28:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-17T19:40:03Z,iago-lito,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-27T11:03:34Z,pYtoner,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-27T11:27:06Z,tyranron,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-08-27T11:27:07Z,tyranron,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-27T18:30:05Z,CatCode79,andrea.postal@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-27T21:35:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-08-27T21:35:46Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-08-28T01:51:25Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-09-03T02:58:44Z,jlyonsmith,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-09-29T23:48:01Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-09-30T16:18:23Z,Congee,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-10-18T17:40:55Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,ROCKET,2021-10-18T17:40:58Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-10-19T22:13:03Z,moy2010,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-10-21T16:44:47Z,eduardosalaz,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-10-22T02:27:20Z,Eric-Dunaway,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-10-23T00:18:17Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HEART,2021-10-23T00:18:17Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,ROCKET,2021-10-23T00:18:18Z,worstpractice,NA https://github.com/rust-lang/rust/pull/87570,MERGED,2021-07-28T21:37:00Z,2021-08-21T12:57:02Z,Upgrade to LLVM 13,nikic,db002a06ae9154a35d410550bc5132df883d7baa,30,Auto merge of #87570 - nikic:llvm-13 r=nagisa Upgrade to LLVM 13 Work in progress update to LLVM 13. Main changes: * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler. * Codegen tests are updated for additional attributes. * Some data layouts have changed. * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448 which appears to trigger a bug in older versions of gold. * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement. Upstream issues: * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece. * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94. * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork https://reviews.llvm.org/D107216 posted for upstream revert. * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise and this needs to be properly addressed in the MergeICmps pass. The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed but quite positive as LLVM upgrades go. The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st. r? `@ghost`,HOORAY,2021-10-25T01:59:33Z,bingo-ctrl,feller.he@outlook.com https://github.com/rust-lang/rust/pull/87574,MERGED,2021-07-28T23:49:02Z,2021-07-30T12:05:52Z,Update the examples in `String` and `VecDeque::retain`,cuviper,3bc6c28376e334014c1d2980e9e30f4d1b9abb1b,2,"Rollup merge of #87574 - cuviper:retain-examples r=joshtriplett Update the examples in `String` and `VecDeque::retain` The examples added in #60396 used a ""clever"" post-increment hack unrelated to the actual point of the examples. That hack was found [confusing] in the users forum and #81811 already changed the `Vec` example to use a more direct iterator. This commit changes `String` and `VecDeque` in the same way for consistency. [confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858",THUMBS_UP,2021-07-29T00:28:17Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/87574,MERGED,2021-07-28T23:49:02Z,2021-07-30T12:05:52Z,Update the examples in `String` and `VecDeque::retain`,cuviper,3bc6c28376e334014c1d2980e9e30f4d1b9abb1b,2,"Rollup merge of #87574 - cuviper:retain-examples r=joshtriplett Update the examples in `String` and `VecDeque::retain` The examples added in #60396 used a ""clever"" post-increment hack unrelated to the actual point of the examples. That hack was found [confusing] in the users forum and #81811 already changed the `Vec` example to use a more direct iterator. This commit changes `String` and `VecDeque` in the same way for consistency. [confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858",HEART,2021-07-29T04:17:07Z,delight-aug,NA https://github.com/rust-lang/rust/pull/87580,MERGED,2021-07-29T10:39:04Z,2021-09-02T18:58:15Z,Update Windows Argument Parsing,ChrisDenton,1cf8fdd4f0be26bcfa9e3b1e10d4bf80107ba492,4,Auto merge of #87580 - ChrisDenton:win-arg-parse-2008 r=m-ou-se Update Windows Argument Parsing Fixes #44650 The Windows command line is passed to applications [as a single string](https://docs.microsoft.com/en-us/archive/blogs/larryosterman/the-windows-command-line-is-just-a-string) which the application then parses to get a list of arguments. The standard rules (as used by C/C++) for parsing the command line have slightly changed over the years most recently in 2008 which added new escaping rules. This PR implements the new rules as [described on MSDN](https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160#parsing-c-command-line-arguments) and [further detailed here](https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN). It has been tested against the behaviour of C++ by calling a C++ program that outputs its raw command line and the contents of `argv`. See [my repo](https://github.com/ChrisDenton/winarg/tree/std) if anyone wants to reproduce my work. For an overview of how this PR changes argument parsing behavior and why we feel it is warranted see https://github.com/rust-lang/rust/pull/87580#issuecomment-893833893. For some examples see: https://github.com/rust-lang/rust/pull/87580#issuecomment-894299249,THUMBS_UP,2021-07-29T14:19:29Z,hkratz,NA https://github.com/rust-lang/rust/pull/87580,MERGED,2021-07-29T10:39:04Z,2021-09-02T18:58:15Z,Update Windows Argument Parsing,ChrisDenton,1cf8fdd4f0be26bcfa9e3b1e10d4bf80107ba492,4,Auto merge of #87580 - ChrisDenton:win-arg-parse-2008 r=m-ou-se Update Windows Argument Parsing Fixes #44650 The Windows command line is passed to applications [as a single string](https://docs.microsoft.com/en-us/archive/blogs/larryosterman/the-windows-command-line-is-just-a-string) which the application then parses to get a list of arguments. The standard rules (as used by C/C++) for parsing the command line have slightly changed over the years most recently in 2008 which added new escaping rules. This PR implements the new rules as [described on MSDN](https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160#parsing-c-command-line-arguments) and [further detailed here](https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN). It has been tested against the behaviour of C++ by calling a C++ program that outputs its raw command line and the contents of `argv`. See [my repo](https://github.com/ChrisDenton/winarg/tree/std) if anyone wants to reproduce my work. For an overview of how this PR changes argument parsing behavior and why we feel it is warranted see https://github.com/rust-lang/rust/pull/87580#issuecomment-893833893. For some examples see: https://github.com/rust-lang/rust/pull/87580#issuecomment-894299249,THUMBS_UP,2021-07-29T21:59:49Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-07-31T09:52:09Z,bjorn3,NA https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-01T23:41:48Z,mati865,NA https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-03T19:55:56Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-06T01:41:32Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-08T02:38:18Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-12T19:27:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-13T06:02:02Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87590,MERGED,2021-07-29T15:06:05Z,2021-08-16T00:10:11Z,Deprecate llvm_asm!,Amanieu,2bd17c1d43bba43412cc2f051323a279d6751e43,78,Auto merge of #87590 - Amanieu:deprecate_llvm_asm r=nagisa Deprecate llvm_asm! We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target to add this support to rustc). The only remaining user of `llvm_asm!` in the standard library was `black_box` which has been rewritten to use volatile operations when `asm!` is not available on the current target. cc `@rust-lang/wg-inline-asm` cc `@RalfJung` for the changes to `black_box` which might affect Miri. r? `@nagisa`,HOORAY,2021-08-17T02:22:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/87599,MERGED,2021-07-29T17:36:16Z,2021-12-09T10:12:00Z,Implement concat_bytes!,Smittyvb,3fc5bd7abc2878f65a3c3dbc594874bae369cdf8,12,"Rollup merge of #87599 - Smittyvb:concat_bytes r=Mark-Simulacrum Implement concat_bytes! This implements the unstable `concat_bytes!` macro which has tracking issue #87555. It can be used like: ```rust #![feature(concat_bytes)] fn main() { assert_eq!(concat_bytes!() &[]); assert_eq!(concat_bytes!(b'A' b""BC"" [68 b'E' 70]) b""ABCDEF""); } ``` If strings or characters are used where byte strings or byte characters are required it suggests adding a `b` prefix. If a number is used outside of an array it suggests arrayifying it. If a boolean is used it suggests replacing it with the numeric value of that number. Doubly nested arrays of bytes are disallowed.",HOORAY,2021-07-29T17:59:17Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/87600,MERGED,2021-07-29T17:42:01Z,2021-08-14T12:06:33Z,Move some UI tests to more suitable subdirs,JohnTitor,fa2692990c05652c7823c8d2afae501a00a69050,10,Auto merge of #87600 - JohnTitor:classify-ui-tests r=petrochenkov Move some UI tests to more suitable subdirs The classifui result: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427/e06c42226c6038da91e403c33b9947843420cf44 Some notes: - backtrace-debuginfo.rs: previously I skipped this I'm still not sure what the best dir is. Any ideas? - estr-subtyping.rs: Seems a quite old test so removed shouldn't? - deref-suggestion.rs: moved to inference as `suggestions` is not an ideal dir. - issue-43023.rs: a bit misclassified moved to `derives` cc #73494 r? `@petrochenkov`,THUMBS_UP,2021-08-12T14:29:20Z,estebank,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2021-10-14T07:04:44Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2021-10-14T10:40:28Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,ROCKET,2021-10-14T15:33:21Z,smmalis37,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,ROCKET,2021-10-14T23:14:50Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2021-10-20T15:11:55Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2021-10-22T23:18:23Z,MinusGix,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2022-03-10T06:51:19Z,brendanzab,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,HEART,2022-05-03T16:31:38Z,CGMossa,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,ROCKET,2022-05-03T16:31:39Z,CGMossa,NA https://github.com/rust-lang/rust/pull/87601,MERGED,2021-07-29T17:57:53Z,2021-10-06T23:12:51Z,Add functions to add unsigned and signed integers,a1phyr,3209582a87f7b8e098bac67f66ed58d8d5840dee,6,Rollup merge of #87601 - a1phyr:feature_uint_add_signed r=kennytm Add functions to add unsigned and signed integers This PR adds methods to unsigned integers to add signed integers with good overflow semantics under `#![feature(mixed_integer_ops)]`. The added API is: ```rust // `uX` is `u8` `u16` `u32` `u64` `u128` `usize` impl uX { pub const fn checked_add_signed(self iX) -> Option; pub const fn overflowing_add_signed(self iX) -> (Self bool); pub const fn saturating_add_signed(self iX) -> Self; pub const fn wrapping_add_signed(self iX) -> Self; } impl iX { pub const fn checked_add_unsigned(self uX) -> Option; pub const fn overflowing_add_unsigned(self uX) -> (Self bool); pub const fn saturating_add_unsigned(self uX) -> Self; pub const fn wrapping_add_unsigned(self uX) -> Self; pub const fn checked_sub_unsigned(self uX) -> Option; pub const fn overflowing_sub_unsigned(self uX) -> (Self bool); pub const fn saturating_sub_unsigned(self uX) -> Self; pub const fn wrapping_sub_unsigned(self uX) -> Self; } ``` Maybe it would be interesting to also have `add_signed` that panics in debug and wraps in release ?,ROCKET,2022-06-21T17:40:16Z,danielg1111,NA https://github.com/rust-lang/rust/pull/87609,MERGED,2021-07-29T22:11:50Z,2021-07-30T22:26:46Z,Add docs about performance and `Iterator::map` to `[T; N]::map`,LukasKalbertodt,f4dfb76ea1f1312c6602a0ab24ec64f976c0a281,1,Rollup merge of #87609 - LukasKalbertodt:improve-array-map-docs r=m-ou-se Add docs about performance and `Iterator::map` to `[T; N]::map` This suboptimal code gen for some usages of array::map got a bit of attention by multiple people throughout the community. Some cases: - https://github.com/rust-lang/rust/issues/75243#issuecomment-866051086 - https://github.com/rust-lang/rust/issues/75243#issuecomment-874732134 - https://www.reddit.com/r/rust/comments/oeqqf7/unexpected_high_stack_usage/ My *guess* is that this gets the attention it gets because in JavaScript (and potentially other languages) a `map` function on arrays is very commonly used since in those languages arrays basically take the role of Rust's iterator. I considered explicitly naming JavaScript in the first paragraph I added but I couldn't find precedence of mentioning other languages in standard library doc so I didn't add it. When array::map was stabilized we still wanted to add docs but that somehow did not happen in time. So here we are. Not sure if this sounds crazy but maybe it is worth considering beta backporting this? Only if it's not a lot of work of course! But yeah stabilized array::map is already in beta and if this problem is really as big as it sometimes seems might be worth having the docs in place when 1.55 is released. CC ``@CryZe`` r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization),THUMBS_UP,2021-07-29T23:21:12Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/87609,MERGED,2021-07-29T22:11:50Z,2021-07-30T22:26:46Z,Add docs about performance and `Iterator::map` to `[T; N]::map`,LukasKalbertodt,f4dfb76ea1f1312c6602a0ab24ec64f976c0a281,1,Rollup merge of #87609 - LukasKalbertodt:improve-array-map-docs r=m-ou-se Add docs about performance and `Iterator::map` to `[T; N]::map` This suboptimal code gen for some usages of array::map got a bit of attention by multiple people throughout the community. Some cases: - https://github.com/rust-lang/rust/issues/75243#issuecomment-866051086 - https://github.com/rust-lang/rust/issues/75243#issuecomment-874732134 - https://www.reddit.com/r/rust/comments/oeqqf7/unexpected_high_stack_usage/ My *guess* is that this gets the attention it gets because in JavaScript (and potentially other languages) a `map` function on arrays is very commonly used since in those languages arrays basically take the role of Rust's iterator. I considered explicitly naming JavaScript in the first paragraph I added but I couldn't find precedence of mentioning other languages in standard library doc so I didn't add it. When array::map was stabilized we still wanted to add docs but that somehow did not happen in time. So here we are. Not sure if this sounds crazy but maybe it is worth considering beta backporting this? Only if it's not a lot of work of course! But yeah stabilized array::map is already in beta and if this problem is really as big as it sometimes seems might be worth having the docs in place when 1.55 is released. CC ``@CryZe`` r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization),THUMBS_UP,2021-07-30T09:08:01Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/87609,MERGED,2021-07-29T22:11:50Z,2021-07-30T22:26:46Z,Add docs about performance and `Iterator::map` to `[T; N]::map`,LukasKalbertodt,f4dfb76ea1f1312c6602a0ab24ec64f976c0a281,1,Rollup merge of #87609 - LukasKalbertodt:improve-array-map-docs r=m-ou-se Add docs about performance and `Iterator::map` to `[T; N]::map` This suboptimal code gen for some usages of array::map got a bit of attention by multiple people throughout the community. Some cases: - https://github.com/rust-lang/rust/issues/75243#issuecomment-866051086 - https://github.com/rust-lang/rust/issues/75243#issuecomment-874732134 - https://www.reddit.com/r/rust/comments/oeqqf7/unexpected_high_stack_usage/ My *guess* is that this gets the attention it gets because in JavaScript (and potentially other languages) a `map` function on arrays is very commonly used since in those languages arrays basically take the role of Rust's iterator. I considered explicitly naming JavaScript in the first paragraph I added but I couldn't find precedence of mentioning other languages in standard library doc so I didn't add it. When array::map was stabilized we still wanted to add docs but that somehow did not happen in time. So here we are. Not sure if this sounds crazy but maybe it is worth considering beta backporting this? Only if it's not a lot of work of course! But yeah stabilized array::map is already in beta and if this problem is really as big as it sometimes seems might be worth having the docs in place when 1.55 is released. CC ``@CryZe`` r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization),THUMBS_UP,2021-09-09T16:31:13Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/87624,CLOSED,2021-07-30T11:38:26Z,2021-08-15T17:17:37Z,Update RELEASES.md for 1.55.0,XAMPPRocky,NA,NA,NA,HOORAY,2021-07-30T15:33:02Z,ehuss,NA https://github.com/rust-lang/rust/pull/87624,CLOSED,2021-07-30T11:38:26Z,2021-08-15T17:17:37Z,Update RELEASES.md for 1.55.0,XAMPPRocky,NA,NA,NA,HEART,2021-07-31T11:10:01Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87636,MERGED,2021-07-30T18:18:39Z,2021-08-11T01:36:32Z,Added the `Option::unzip()` method,Kixiron,bdc92f10e73b2e22574d8c7627baebb5013efcbf,3,Rollup merge of #87636 - Kixiron:unzip-option r=scottmcm Added the `Option::unzip()` method * Adds the `Option::unzip()` method to turn an `Option<(T U)>` into `(Option Option)` under the `unzip_option` feature * Adds tests for both `Option::unzip()` and `Option::zip()` I noticed that `.zip()` didn't have any * Adds `#[inline]` to a few of `Option`'s methods that were missing it,CONFUSED,2021-08-19T04:53:13Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/87637,CLOSED,2021-07-30T18:22:27Z,2021-07-30T18:50:28Z,Made `Vec::len()` and `Vec::is_empty()` const,Kixiron,NA,NA,NA,EYES,2021-07-30T18:55:40Z,segeljakt,klasseg@kth.se https://github.com/rust-lang/rust/pull/87644,MERGED,2021-07-30T20:01:52Z,2021-08-02T04:59:09Z,Recommend `swap_remove` in `Vec::remove` docs,Flying-Toast,0c9b35b8c726b679f4c9cb67d2936955515ce614,1,Rollup merge of #87644 - Flying-Toast:vec-remove-note r=the8472 Recommend `swap_remove` in `Vec::remove` docs I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.,THUMBS_UP,2021-07-31T05:52:01Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87644,MERGED,2021-07-30T20:01:52Z,2021-08-02T04:59:09Z,Recommend `swap_remove` in `Vec::remove` docs,Flying-Toast,0c9b35b8c726b679f4c9cb67d2936955515ce614,1,Rollup merge of #87644 - Flying-Toast:vec-remove-note r=the8472 Recommend `swap_remove` in `Vec::remove` docs I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.,THUMBS_UP,2021-07-31T06:22:46Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/87648,MERGED,2021-07-30T22:45:48Z,2022-01-18T13:43:18Z,allow eq constraints on associated constants,JulianKnodt,7bc7be860f99f4a40d45b0f74e2d01b02e072357,83,Auto merge of #87648 - JulianKnodt:const_eq_constrain r=oli-obk allow eq constraints on associated constants Updates #70256 (cc `@varkor ` `@Centril)`,EYES,2022-01-18T18:09:24Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/87648,MERGED,2021-07-30T22:45:48Z,2022-01-18T13:43:18Z,allow eq constraints on associated constants,JulianKnodt,7bc7be860f99f4a40d45b0f74e2d01b02e072357,83,Auto merge of #87648 - JulianKnodt:const_eq_constrain r=oli-obk allow eq constraints on associated constants Updates #70256 (cc `@varkor ` `@Centril)`,EYES,2022-02-28T15:11:16Z,ZoeyR,zoey@dos.cafe https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-07-31T21:04:04Z,bugadani,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-01T15:56:09Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-01T19:01:20Z,davidkern,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-02T23:45:09Z,rtzoeller,rtzoeller@rtzoeller.com https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-03T02:30:35Z,nevi-me,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-10T08:12:44Z,ohadravid,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-11T12:37:26Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-12T07:53:36Z,arnauorriols,arnau.orriols@iota.org https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-12T13:26:35Z,lexxvir,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-08-13T13:32:49Z,branflakes2,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-09-18T00:28:14Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-10-21T14:40:36Z,andresv,andres@vahter.me https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-10-21T16:42:22Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HOORAY,2021-11-17T09:11:12Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",ROCKET,2021-11-17T09:11:14Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-11-21T16:31:16Z,tekjar,raviteja@bytebeam.io https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HOORAY,2021-12-15T09:15:33Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-12-15T09:15:51Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",ROCKET,2021-12-15T09:15:52Z,LinusU,linus@folkdatorn.se https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2021-12-22T09:50:02Z,Voronar,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2022-04-21T23:02:29Z,fabiojmendes,NA https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HOORAY,2022-04-22T21:12:49Z,nim65s,guilhem.saurel@laas.fr https://github.com/rust-lang/rust/pull/87666,MERGED,2021-07-31T15:38:17Z,2021-08-12T13:24:39Z,STD support for the ESP-IDF framework,ivmarkov,6bed1f0bc3cc50c10aab26d5f94b16a00776b8a5,29,"Auto merge of #87666 - ivmarkov:master r=Amanieu STD support for the ESP-IDF framework Dear all This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework which is the open source SDK provided by Espressif for their MCU family (esp32 esp32s2 esp32c3 and all other forthcoming ones). Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support. # Implementation approach The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread` BSD sockets file descriptors and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes which is to be expected of course on bare metal. Therefore the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules in the form of conditional-compilation branches based either on `target_os = ""espidf""` or in a couple of cases - based on `target_env = ""newlib""` (the latter was already there actually and is not part of this patch). The PR also contains two new targets: - `riscv32imc-esp-espidf` - `riscv32imac-esp-espidf` ... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf` but enriched with proper `linker` `linker_flavor` `families` `os` `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used. Since support for atomics is a precondition for libStd the `riscv32imc-esp-espidf` target additionally is configured in such a way so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions which are already implemented in the ESP-IDF framework. If this modification is not acceptable we can also live with only the `riscv32imac-esp-espidf` target as well. While the RiscV chips of Espressif lack native atomics support the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind. # Target maintainers In case this PR eventually gets merged you can list myself as a Target Maintainer. More importantly Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well. **EDIT:** I was hinted (thanks `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below. # Tier 3 Target Policy - answers > A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. Hopefully the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`). > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) `@ivmarkov` `@MabezDev` > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base: * The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`. * `_elf` was removed as the non-bare metal targets seem not to have it * `-newlib` was deliberately NOT added at the end as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say newlib vs musl) is way too small * Finally we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company as they all use the riscv32imc instruction set. By necessity however (disambiguation) it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR even though they would use 1:1 the same LibStd implementation provided here as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.) There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14). > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Agreed. > The target must not introduce license incompatibilities. To the best of our knowledge it doesn't. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). MIT + Apache 2.0 > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Requirements are not changed for any other target. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. The targets are for bare-metal environment which is not hosting build tools or a compiler. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Agreed. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. The targets implement libStd almost in its entirety except for the missing support for process as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return ""not implemented"" errors. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs) there is no need for extensive documentation. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Agreed. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Agreed. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. To the best of our knowledge we believe we are not breaking any other target (be it tier 1 2 or 3). > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. To the best of our knowledge we have not introduced any unconditional use of a feature that affects any other target. > If a tier 3 target stops meeting these requirements or the target maintainers no longer have interest or time or the target shows no signs of activity and has not built for some time or removing the target would improve the quality of the Rust codebase we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target) to check potential interest in improving the situation. Agreed.",HEART,2022-05-27T20:39:18Z,Evanfeenstra,NA https://github.com/rust-lang/rust/pull/87671,MERGED,2021-07-31T18:38:31Z,2021-08-12T10:13:40Z,Warn when an escaped newline skips multiple lines,jesyspa,53a66acbd3b5f2aff302092bf7b3f05549da7427,7,Rollup merge of #87671 - jesyspa:issue-87319-multiple-newlines r=estebank Warn when an escaped newline skips multiple lines Resolves #87319,THUMBS_UP,2021-08-10T16:57:01Z,pierwill,NA https://github.com/rust-lang/rust/pull/87671,MERGED,2021-07-31T18:38:31Z,2021-08-12T10:13:40Z,Warn when an escaped newline skips multiple lines,jesyspa,53a66acbd3b5f2aff302092bf7b3f05549da7427,7,Rollup merge of #87671 - jesyspa:issue-87319-multiple-newlines r=estebank Warn when an escaped newline skips multiple lines Resolves #87319,THUMBS_UP,2021-08-11T09:54:25Z,estebank,NA https://github.com/rust-lang/rust/pull/87677,MERGED,2021-08-01T03:07:51Z,2021-08-17T01:32:24Z,Adding explicit notice of lack of documentation for Tier 2 Platforms,amalik18,84ca374bcb758d50a9c9a6e22eaa212f0d34abf9,1,Rollup merge of #87677 - amalik18:issue-2788-fix r=pietroalbini Adding explicit notice of lack of documentation for Tier 2 Platforms Fixing: https://github.com/rust-lang/rustup/issues/2788,HEART,2021-08-01T10:23:07Z,ethulhu,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-02T03:30:23Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-02T10:00:07Z,darksv,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-02T23:51:15Z,est31,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-03T17:50:35Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-04T15:01:23Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-04T22:57:48Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-05T19:51:24Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-05T21:01:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T00:52:06Z,tmandry,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T06:53:10Z,yamafaktory,yamafaktory@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T09:36:21Z,Stupremee,justus.k@protonmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T12:36:42Z,CPerezz,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-07T12:36:46Z,CPerezz,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T12:37:21Z,dunnock,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T13:26:34Z,PoignardAzur,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-07T13:26:38Z,PoignardAzur,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-07T16:08:08Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-07T17:56:13Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HOORAY,2021-08-07T17:56:15Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HOORAY,2021-08-08T00:48:03Z,Dessix,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-09T13:29:21Z,cdmistman,colton@donn.io https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HOORAY,2021-08-09T17:16:01Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-09T17:16:01Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-09T17:16:04Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-09T17:38:14Z,jix,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-09T18:51:31Z,QuentinPerez,qperez42@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-09T18:51:33Z,QuentinPerez,qperez42@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-10T08:11:02Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HOORAY,2021-08-10T15:14:50Z,MozarellaMan,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-10T15:14:51Z,MozarellaMan,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-11T05:29:39Z,WilsonGramer,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-17T21:19:06Z,danielegarciav,daniel.garcia@mail.utoronto.ca https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-17T21:19:07Z,danielegarciav,daniel.garcia@mail.utoronto.ca https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-22T08:30:02Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-27T21:27:25Z,cayv,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-08-27T23:51:03Z,adamaveray,adam@averay.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-08-31T20:19:37Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-01T16:01:40Z,iwa13,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2021-09-01T21:22:12Z,delacian,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-01T22:24:53Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-06T06:34:59Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-10T04:31:51Z,bruteforcecat,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-10T19:33:23Z,kangalioo,NA https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2021-09-15T06:38:41Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",HEART,2022-04-05T05:58:24Z,aalekhpatel07,aalekh.gwpeck.7998@icloud.com https://github.com/rust-lang/rust/pull/87688,MERGED,2021-08-02T00:31:58Z,2021-09-01T03:43:39Z,Introduce `let...else`,camsteffen,c2a408840ad18f74280805535f0b7193528ff3df,59,"Auto merge of #87688 - camsteffen:let-else r=cjgillot Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..` but I decided against this because when a ""mismatched type"" error is found in typeck there is no way to trace where in the HIR the expected type originated AFAICT. In order to pass down this information I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType` but I left that as a future enhancement. For now I simply assert that the block is `!` with a custom `ObligationCauseCode` and I think this is clear enough at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall I believe this PR is feature-complete with regard to the RFC.",ROCKET,2022-06-16T06:55:26Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/87699,MERGED,2021-08-02T14:42:14Z,2021-08-24T14:56:00Z,Allow specifying an deployment target version for all iOS llvm targets,ubamrein,47ab5f7ce27397310bd8359b8db1504fbf8a9b59,4,Auto merge of #87699 - ubamrein:use-iphone-deployment-target-for-llvm r=petrochenkov Allow specifying an deployment target version for all iOS llvm targets Closes: https://github.com/rust-lang/rust/issues/79408 This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target. This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains but is probably not easy fixable. I realised that something is still not right. Try to fix that. r? `@petrochenkov`,HEART,2021-08-05T01:58:44Z,daltonclaybrook,daltonclaybrook@gmail.com https://github.com/rust-lang/rust/pull/87699,MERGED,2021-08-02T14:42:14Z,2021-08-24T14:56:00Z,Allow specifying an deployment target version for all iOS llvm targets,ubamrein,47ab5f7ce27397310bd8359b8db1504fbf8a9b59,4,Auto merge of #87699 - ubamrein:use-iphone-deployment-target-for-llvm r=petrochenkov Allow specifying an deployment target version for all iOS llvm targets Closes: https://github.com/rust-lang/rust/issues/79408 This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target. This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains but is probably not easy fixable. I realised that something is still not right. Try to fix that. r? `@petrochenkov`,HEART,2021-08-24T01:44:17Z,dcow,dcow@pm.me https://github.com/rust-lang/rust/pull/87699,MERGED,2021-08-02T14:42:14Z,2021-08-24T14:56:00Z,Allow specifying an deployment target version for all iOS llvm targets,ubamrein,47ab5f7ce27397310bd8359b8db1504fbf8a9b59,4,Auto merge of #87699 - ubamrein:use-iphone-deployment-target-for-llvm r=petrochenkov Allow specifying an deployment target version for all iOS llvm targets Closes: https://github.com/rust-lang/rust/issues/79408 This pull requests adds the same procedure to define the iOS-version for the LLVM-target as was used for the simulator target and the desktop target. This then closes the original problem mentioned in the above issue. The problem with incompatible bitcode remains but is probably not easy fixable. I realised that something is still not right. Try to fix that. r? `@petrochenkov`,HEART,2021-08-26T06:12:17Z,ohitsdaniel,NA https://github.com/rust-lang/rust/pull/87712,MERGED,2021-08-03T00:57:48Z,2021-08-04T07:17:43Z,Proc macro spans: make columns 1 based,est31,71ff9b41e9ebd3e336019513917a7a8868d1cc66,4,Auto merge of #87712 - est31:line-column-1-based r=petrochenkov Proc macro spans: make columns 1 based This makes proc macro spans consistent with the `column!()` macro as well as `std::panic::Location` as both are 1-based. https://github.com/rust-lang/rust/issues/54725#issuecomment-497246753,THUMBS_UP,2021-08-04T11:48:10Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/87712,MERGED,2021-08-03T00:57:48Z,2021-08-04T07:17:43Z,Proc macro spans: make columns 1 based,est31,71ff9b41e9ebd3e336019513917a7a8868d1cc66,4,Auto merge of #87712 - est31:line-column-1-based r=petrochenkov Proc macro spans: make columns 1 based This makes proc macro spans consistent with the `column!()` macro as well as `std::panic::Location` as both are 1-based. https://github.com/rust-lang/rust/issues/54725#issuecomment-497246753,THUMBS_UP,2021-08-11T12:21:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87716,MERGED,2021-08-03T03:38:36Z,2021-08-03T13:23:38Z,Allow generic SIMD array element type,calebzulawski,331e78d80422ca779c71b19d9273f5d8ee737643,4,Rollup merge of #87716 - calebzulawski:master r=workingjubilee Allow generic SIMD array element type Fixes the following: ```rust #[repr(simd)] struct V([T; 4]); ``` cc ``@workingjubilee``,HEART,2021-08-13T08:32:09Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/87727,MERGED,2021-08-03T11:44:44Z,2021-08-06T07:43:37Z,explicit_generic_args_with_impl_trait: fix min expected number of generics,SkiFire13,5b4396068744e810d090de038e6f456432d203a2,5,Rollup merge of #87727 - SkiFire13:fix-87718 r=jackh726 explicit_generic_args_with_impl_trait: fix min expected number of generics Fixes #87718 The problem was that `synth_type_param_count` was already subtracted from `named_type_param_count` so this ended up being subtracted again. This caused `expected_min` to overflow and ultimately resulting in weird and wrong behaviour. I've also added another test not present in the original issue but caused by the same bug.,HEART,2021-08-03T12:53:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87727,MERGED,2021-08-03T11:44:44Z,2021-08-06T07:43:37Z,explicit_generic_args_with_impl_trait: fix min expected number of generics,SkiFire13,5b4396068744e810d090de038e6f456432d203a2,5,Rollup merge of #87727 - SkiFire13:fix-87718 r=jackh726 explicit_generic_args_with_impl_trait: fix min expected number of generics Fixes #87718 The problem was that `synth_type_param_count` was already subtracted from `named_type_param_count` so this ended up being subtracted again. This caused `expected_min` to overflow and ultimately resulting in weird and wrong behaviour. I've also added another test not present in the original issue but caused by the same bug.,HEART,2021-08-03T18:15:06Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/87736,MERGED,2021-08-03T19:34:45Z,2021-08-04T18:22:45Z,#[inline] slice::Iter::advance_by,the8472,6fe0886723c9e08b800c9951f1c6f6a57b2bf22c,1,Auto merge of #87736 - the8472:inline-advance-by r=Mark-Simulacrum #[inline] slice::Iter::advance_by https://github.com/rust-lang/rust/pull/87387#issuecomment-891942661 was marked as a regression. One of the methods in the PR was missing an inline annotation unlike all the other methods on slice iterators. Let's see if that makes a difference.,THUMBS_UP,2021-08-04T01:36:05Z,mohe2015,NA https://github.com/rust-lang/rust/pull/87739,MERGED,2021-08-03T20:56:32Z,2021-08-24T06:39:14Z,Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`,Aaron1011,f66e825f73d2bd7f8a763b723983850f891985b0,64,"Auto merge of #87739 - Aaron1011:remove-used-attrs r=wesleywiser Remove `Session.used_attrs` and move logic to `CheckAttrVisitor` Instead of updating global state to mark attributes as used we now explicitly emit a warning when an attribute is used in an unsupported position. As a side effect we are to emit more detailed warning messages (instead of just a generic ""unused"" message). `Session.check_name` is removed since its only purpose was to mark the attribute as used. All of the callers are modified to use `Attribute.has_name` Additionally `AttributeType::AssumedUsed` is removed - an 'assumed used' attribute is implemented by simply not performing any checks in `CheckAttrVisitor` for a particular attribute. We no longer emit unused attribute warnings for the `#[rustc_dummy]` attribute - it's an internal attribute used for tests so it doesn't mark sense to treat it as 'unused'. With this commit a large source of global untracked state is removed.",THUMBS_UP,2021-08-20T17:25:03Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,THUMBS_UP,2021-08-03T23:43:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,THUMBS_UP,2021-08-04T00:55:12Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,HEART,2021-08-05T04:24:06Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,THUMBS_UP,2021-08-05T20:53:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,HEART,2021-08-05T20:53:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87744,MERGED,2021-08-03T22:21:24Z,2021-08-07T20:43:25Z,Add x.py option to --force-rerun compiletest tests,Smittyvb,e862383dbb59147c43a1d23ea1a0c3e9f40484ce,5,Rollup merge of #87744 - Smittyvb:xpy-test-force-rerun r=Mark-Simulacrum Add x.py option to --force-rerun compiletest tests This can be used like `./x.py test src/test/ui/abi/ --force-rerun` and is useful when verifying that newly blessed tests don't change between test runs (such as due to being dependent on the current time or memory layout or RNG) without needing to change the test file or find the right file in `build` to remove.,THUMBS_UP,2021-08-06T06:57:08Z,hkratz,NA https://github.com/rust-lang/rust/pull/87768,MERGED,2021-08-04T16:36:23Z,2021-08-05T20:37:22Z,Core features cleanup,m-ou-se,2f07ae408fce782bf1058e3de808f1b6f9ab60a4,2,Auto merge of #87768 - rust-lang:core-features-cleanup r=dtolnay Core features cleanup This sorts and categorizes the `#![features]` in `core` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(bool_to_option)] -#![feature(char_indices_offset)] -#![feature(pin_deref_mut)] -#![feature(str_split_as_str)] -#![feature(str_split_inclusive_as_str)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(custom_inner_attributes)] -#![feature(nll)] ```,THUMBS_UP,2021-08-04T17:20:00Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87768,MERGED,2021-08-04T16:36:23Z,2021-08-05T20:37:22Z,Core features cleanup,m-ou-se,2f07ae408fce782bf1058e3de808f1b6f9ab60a4,2,Auto merge of #87768 - rust-lang:core-features-cleanup r=dtolnay Core features cleanup This sorts and categorizes the `#![features]` in `core` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(bool_to_option)] -#![feature(char_indices_offset)] -#![feature(pin_deref_mut)] -#![feature(str_split_as_str)] -#![feature(str_split_inclusive_as_str)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(custom_inner_attributes)] -#![feature(nll)] ```,THUMBS_UP,2021-08-04T17:41:04Z,est31,NA https://github.com/rust-lang/rust/pull/87768,MERGED,2021-08-04T16:36:23Z,2021-08-05T20:37:22Z,Core features cleanup,m-ou-se,2f07ae408fce782bf1058e3de808f1b6f9ab60a4,2,Auto merge of #87768 - rust-lang:core-features-cleanup r=dtolnay Core features cleanup This sorts and categorizes the `#![features]` in `core` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(bool_to_option)] -#![feature(char_indices_offset)] -#![feature(pin_deref_mut)] -#![feature(str_split_as_str)] -#![feature(str_split_inclusive_as_str)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(custom_inner_attributes)] -#![feature(nll)] ```,THUMBS_UP,2021-08-04T18:59:44Z,hkratz,NA https://github.com/rust-lang/rust/pull/87768,MERGED,2021-08-04T16:36:23Z,2021-08-05T20:37:22Z,Core features cleanup,m-ou-se,2f07ae408fce782bf1058e3de808f1b6f9ab60a4,2,Auto merge of #87768 - rust-lang:core-features-cleanup r=dtolnay Core features cleanup This sorts and categorizes the `#![features]` in `core` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(bool_to_option)] -#![feature(char_indices_offset)] -#![feature(pin_deref_mut)] -#![feature(str_split_as_str)] -#![feature(str_split_inclusive_as_str)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(custom_inner_attributes)] -#![feature(nll)] ```,THUMBS_UP,2021-08-05T11:31:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87769,MERGED,2021-08-04T17:29:05Z,2021-10-20T01:16:25Z,Alloc features cleanup,m-ou-se,71fcb72307e2bb9512d291d33f2adace2406e65a,1,Rollup merge of #87769 - m-ou-se:alloc-features-cleanup r=yaahc dtolnay Alloc features cleanup This sorts and categorizes the `#![features]` in `alloc` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(cow_is_borrowed)] -#![feature(maybe_uninit_uninit_array)] -#![feature(slice_partition_dedup)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(auto_traits)] -#![feature(box_patterns)] -#![feature(decl_macro)] -#![feature(nll)] ```,THUMBS_UP,2021-08-04T17:41:14Z,est31,NA https://github.com/rust-lang/rust/pull/87769,MERGED,2021-08-04T17:29:05Z,2021-10-20T01:16:25Z,Alloc features cleanup,m-ou-se,71fcb72307e2bb9512d291d33f2adace2406e65a,1,Rollup merge of #87769 - m-ou-se:alloc-features-cleanup r=yaahc dtolnay Alloc features cleanup This sorts and categorizes the `#![features]` in `alloc` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(cow_is_borrowed)] -#![feature(maybe_uninit_uninit_array)] -#![feature(slice_partition_dedup)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(auto_traits)] -#![feature(box_patterns)] -#![feature(decl_macro)] -#![feature(nll)] ```,THUMBS_UP,2021-08-04T18:59:49Z,hkratz,NA https://github.com/rust-lang/rust/pull/87769,MERGED,2021-08-04T17:29:05Z,2021-10-20T01:16:25Z,Alloc features cleanup,m-ou-se,71fcb72307e2bb9512d291d33f2adace2406e65a,1,Rollup merge of #87769 - m-ou-se:alloc-features-cleanup r=yaahc dtolnay Alloc features cleanup This sorts and categorizes the `#![features]` in `alloc` and removes unused ones. This is part of #87766 The following feature attributes were unnecessary and are removed: ```diff // Library features: -#![feature(cow_is_borrowed)] -#![feature(maybe_uninit_uninit_array)] -#![feature(slice_partition_dedup)] // Language features: -#![feature(arbitrary_self_types)] -#![feature(auto_traits)] -#![feature(box_patterns)] -#![feature(decl_macro)] -#![feature(nll)] ```,THUMBS_UP,2021-08-05T11:32:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87776,CLOSED,2021-08-04T22:26:47Z,2021-10-15T05:24:02Z,Add Iterator::array_chunks method,johnschug,NA,NA,NA,THUMBS_UP,2021-08-05T17:27:48Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/87776,CLOSED,2021-08-04T22:26:47Z,2021-10-15T05:24:02Z,Add Iterator::array_chunks method,johnschug,NA,NA,NA,THUMBS_UP,2021-08-06T12:43:04Z,darksv,NA https://github.com/rust-lang/rust/pull/87779,MERGED,2021-08-05T00:42:48Z,2021-08-06T21:22:28Z,Remove special case for statement `NodeId` assignment,Aaron1011,a4262cc9841d91d48ef994b36eab323e615a7083,3,Rollup merge of #87779 - Aaron1011:stmt-ast-id r=petrochenkov Remove special case for statement `NodeId` assignment We now let `noop_flat_map_stmt` assign `NodeId`s (via `visit_id`) just as we do for other AST nodes.,HOORAY,2021-08-05T07:15:37Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/87781,MERGED,2021-08-05T03:45:19Z,2021-08-18T13:24:26Z,Remove box syntax from compiler and tools,est31,ba8cda2fa2c99ed6646f4dfe73bf4edad7e42a2d,72,Auto merge of #87781 - est31:remove_box r=oli-obk Remove box syntax from compiler and tools Removes box syntax from the compiler and tools. In #49733 the future of box syntax is uncertain and the use in the compiler was listed as one of the reasons to keep it. Removal of box syntax [might affect the code generated](https://github.com/rust-lang/rust/pull/49646#issuecomment-379219615) and slow down the compiler so I'd recommend doing a perf run on this.,THUMBS_UP,2021-08-05T04:15:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87781,MERGED,2021-08-05T03:45:19Z,2021-08-18T13:24:26Z,Remove box syntax from compiler and tools,est31,ba8cda2fa2c99ed6646f4dfe73bf4edad7e42a2d,72,Auto merge of #87781 - est31:remove_box r=oli-obk Remove box syntax from compiler and tools Removes box syntax from the compiler and tools. In #49733 the future of box syntax is uncertain and the use in the compiler was listed as one of the reasons to keep it. Removal of box syntax [might affect the code generated](https://github.com/rust-lang/rust/pull/49646#issuecomment-379219615) and slow down the compiler so I'd recommend doing a perf run on this.,THUMBS_UP,2021-08-08T17:19:10Z,r00ster91,NA https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,ROCKET,2021-08-05T14:30:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,ROCKET,2021-08-05T16:57:00Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,ROCKET,2021-08-05T18:36:13Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2021-08-06T10:21:35Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2021-08-06T20:58:03Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2021-08-13T07:07:32Z,iago-lito,NA https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,HEART,2021-08-13T07:07:35Z,iago-lito,NA https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,ROCKET,2021-08-17T17:29:00Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2021-08-26T04:10:43Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,ROCKET,2021-09-14T07:39:28Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,HEART,2021-11-30T23:57:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2021-12-03T09:58:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,HEART,2021-12-03T09:58:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87794,MERGED,2021-08-05T14:18:08Z,2021-09-14T01:07:18Z,Enum should prefer discriminant zero for niche,bonega,9f85cd6f2ab2769c16e89dcdddb3e11d9736b351,3,Auto merge of #87794 - bonega:enum_niche_prefer_zero r=nagisa Enum should prefer discriminant zero for niche Given an enum with unassigned zero-discriminant rust should prefer it for niche selection. Zero as discriminant for `Option` makes it possible for LLVM to optimize resulting asm. - Eliminate branch when expected value coincides. - Use smaller instruction `test eax eax` instead of `cmp eax ?` - Possible interaction with zeroed memory? Example: ```rust pub enum Size { One = 1 Two = 2 Three = 3 } pub fn handle(x: Option) -> u8 { match x { None => {0} Some(size) => {size as u8} } } ``` In this case discriminant zero is available as a niche. Above example on nightly: ```asm mov eax edi cmp al 4 jne .LBB0_2 xor eax eax .LBB0_2: ret ``` PR: ```asm mov eax edi ret ``` I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8. Using an enum instead of `NonZeroU8` [here](https://github.com/bonega/yore/blob/d683304f5dfe2e99f769e6ab8adf8d60a0d1d9b3/src/internal/decoder_incomplete.rs#L90) resulted in a performance regression of about 5%. I consider this to be a somewhat realistic benchmark. Thanks to `@ogoffart` for pointing me in the right direction! Edit: Updated description,THUMBS_UP,2022-05-19T11:31:08Z,jamesmcm,jamesmcm03@gmail.com https://github.com/rust-lang/rust/pull/87795,MERGED,2021-08-05T14:40:52Z,2021-08-13T16:57:23Z,Avoid ICE caused by suggestion,estebank,717f9e37696703670108f47c5dff261ca9d4d834,4,Rollup merge of #87795 - estebank:erase-lifetimes-in-suggestion r=oli-obk Avoid ICE caused by suggestion When suggesting dereferencing something that can be iterable in a `for` loop erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region constraints already solved' panic. Fix #87657 fix #87709 fix #87651.,THUMBS_UP,2021-08-05T18:31:48Z,lqd,NA https://github.com/rust-lang/rust/pull/87795,MERGED,2021-08-05T14:40:52Z,2021-08-13T16:57:23Z,Avoid ICE caused by suggestion,estebank,717f9e37696703670108f47c5dff261ca9d4d834,4,Rollup merge of #87795 - estebank:erase-lifetimes-in-suggestion r=oli-obk Avoid ICE caused by suggestion When suggesting dereferencing something that can be iterable in a `for` loop erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region constraints already solved' panic. Fix #87657 fix #87709 fix #87651.,THUMBS_UP,2021-08-06T02:23:06Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/87795,MERGED,2021-08-05T14:40:52Z,2021-08-13T16:57:23Z,Avoid ICE caused by suggestion,estebank,717f9e37696703670108f47c5dff261ca9d4d834,4,Rollup merge of #87795 - estebank:erase-lifetimes-in-suggestion r=oli-obk Avoid ICE caused by suggestion When suggesting dereferencing something that can be iterable in a `for` loop erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region constraints already solved' panic. Fix #87657 fix #87709 fix #87651.,THUMBS_UP,2021-08-14T06:37:00Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/87830,MERGED,2021-08-06T19:50:11Z,2021-09-21T03:15:13Z,Suggest replacing braces for brackets on array-esque invalid block expr,hkmatsumoto,e7958d35ca2c898a223efe402481e0ecb854310a,3,Auto merge of #87830 - hkmatsumoto:suggest-brackets-for-array-esque-block-expr r=estebank Suggest replacing braces for brackets on array-esque invalid block expr Newcomers may write `{1 2 3}` for making arrays and the current error message is not informative enough to quickly convince them what is needed to fix the error. This PR implements a diagnostic for this case and its output looks like this: ```text error: this code is interpreted as a block expression not an array --> src/lib.rs:1:22 | 1 | const FOO: [u8; 3] = { | ______________________^ 2 | | 1 2 3 3 | | }; | |_^ | = note: to define an array one would use square brackets instead of curly braces help: try using [] instead of {} | 1 | const FOO: [u8; 3] = [ 2 | 1 2 3 3 | ]; | ``` Fix #87672,HEART,2021-08-08T12:52:49Z,chansuke,moonset20@gmail.com https://github.com/rust-lang/rust/pull/87830,MERGED,2021-08-06T19:50:11Z,2021-09-21T03:15:13Z,Suggest replacing braces for brackets on array-esque invalid block expr,hkmatsumoto,e7958d35ca2c898a223efe402481e0ecb854310a,3,Auto merge of #87830 - hkmatsumoto:suggest-brackets-for-array-esque-block-expr r=estebank Suggest replacing braces for brackets on array-esque invalid block expr Newcomers may write `{1 2 3}` for making arrays and the current error message is not informative enough to quickly convince them what is needed to fix the error. This PR implements a diagnostic for this case and its output looks like this: ```text error: this code is interpreted as a block expression not an array --> src/lib.rs:1:22 | 1 | const FOO: [u8; 3] = { | ______________________^ 2 | | 1 2 3 3 | | }; | |_^ | = note: to define an array one would use square brackets instead of curly braces help: try using [] instead of {} | 1 | const FOO: [u8; 3] = [ 2 | 1 2 3 3 | ]; | ``` Fix #87672,HEART,2021-09-17T17:02:14Z,estebank,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-08-07T07:36:50Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-08-07T10:53:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-08-07T21:19:16Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-08-08T20:14:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-08-14T14:34:18Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-11-04T11:48:37Z,EdJoPaTo,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-11-24T22:54:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2021-12-02T01:12:18Z,surechen,chenshuo17@huawei.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HEART,2022-01-17T19:17:31Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HOORAY,2022-02-18T00:35:42Z,nikomatsakis,niko@alum.mit.edu https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2022-03-10T05:00:02Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HOORAY,2022-03-10T05:00:03Z,lukechu10,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2022-03-10T06:14:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HEART,2022-03-10T06:14:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HOORAY,2022-03-10T06:14:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2022-03-10T14:08:37Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HOORAY,2022-03-11T11:57:46Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2022-03-12T03:17:07Z,MinusGix,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,THUMBS_UP,2022-04-28T22:14:02Z,tmandry,NA https://github.com/rust-lang/rust/pull/87835,MERGED,2021-08-07T00:08:28Z,2022-03-03T21:40:37Z,Implementation of the `expect` attribute (RFC 2383),xFrednet,10913c00018c76103b2fd4260d8c02ec728fd244,37,Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids r=wesleywiser Implementation of the `expect` attribute (RFC 2383) This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute. ### Example #### input ```rs // required feature flag #![feature(lint_reasons)] #[expect(unused_mut)] // Will warn about an unfulfilled expectation #[expect(unused_variables)] // Will be fulfilled by x fn main() { let x = 0; } ``` #### output ```txt warning: this lint expectation is unfulfilled --> $DIR/trigger_lint.rs:3:1 | LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation | ^^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default ``` ### Implementation This implementation introduces `Expect` as a new lint level for diagnostics which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query. The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise a new lint message will be emitted. The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage it's not possible to create a stable identifier. The level instead stores an unstable identifier which is later converted to a stable `LintExpectationId`. ### Followup TO-DOs All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them: * [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute. * This should be easily possible but I wanted to get some feedback before putting more work into this. * This could also be done in a new PR to not add to much more code to this one * [ ] Update unstable documentation to reflect this change. * [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics) ### Open questions I also have a few open questions where I would like to get feedback on: 1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091) suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion or was this discarded with the merge of the RFC? 2. How should the expect attribute deal with the new `force-warn` lint level? --- This approach was inspired by a discussion with `@LeSeulArtichaut.` RFC tracking issue: #54503 Mentoring/Implementation issue: #85549 [`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html [`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html [`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels [`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html [`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html,HEART,2022-04-28T22:14:04Z,tmandry,NA https://github.com/rust-lang/rust/pull/87848,MERGED,2021-08-07T15:36:52Z,2021-08-11T01:36:32Z,removed references to parent/child from std::thread documentation,godmar,6412bf98ea65cb0f50959c857088fd77cdc2980f,1,"Rollup merge of #87848 - godmar:@godmar/thread-join-documentation-fix r=joshtriplett removed references to parent/child from std::thread documentation - also clarifies how thread.join and detaching of threads works - the previous prose implied that there is a relationship between a spawning thread and the thread being spawned and that ""child"" threads couldn't outlive their ""parents"" unless detached which is incorrect.",THUMBS_UP,2021-08-08T21:18:50Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HOORAY,2021-08-28T01:58:24Z,riking,NA https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HEART,2021-09-30T19:32:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HOORAY,2021-09-30T19:32:36Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HEART,2021-10-01T13:45:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HOORAY,2021-10-01T13:45:22Z,marmeladema,NA https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HOORAY,2021-10-21T22:12:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87868,MERGED,2021-08-08T17:08:15Z,2021-10-01T20:06:39Z,Added -Z randomize-layout flag,Kixiron,37df2753fc52ff80625430aa7e8cdcdc6f16e362,6,Rollup merge of #87868 - Kixiron:packing-on-the-pounds r=eddyb Added -Z randomize-layout flag An implementation of #77316 it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash` r? ``@eddyb``,HEART,2021-10-21T22:12:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-08T18:50:01Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-09T05:41:31Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-09T12:07:14Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2021-08-09T12:07:16Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-09T13:39:09Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-09T13:50:26Z,vrmiguel,NA https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2021-08-09T13:50:28Z,vrmiguel,NA https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-10T13:23:08Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",EYES,2021-08-10T16:30:55Z,the8472,NA https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2021-08-11T09:54:54Z,hkratz,NA https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2021-08-26T11:56:35Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-08-26T11:56:36Z,bugaevc,bugaevc@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-09-20T11:09:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2021-10-04T05:14:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2021-12-01T13:31:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HOORAY,2022-02-10T20:43:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2022-02-10T20:43:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2022-04-21T15:14:35Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/87869,MERGED,2021-08-08T17:10:18Z,2022-02-07T23:40:37Z,Make io::Error use 64 bits on targets with 64 bit pointers.,thomcc,734368a200904ef9c21db86c595dc04263c87be0,50,"Auto merge of #87869 - thomcc:skinny-io-error r=yaahc Make io::Error use 64 bits on targets with 64 bit pointers. I've wanted this for a long time but didn't see a good way to do it without having extra allocation. When looking at it yesterday it was more clear what to do for some reason. This approach avoids any additional allocations and reduces the size by half (8 bytes down from 16). AFAICT it doesn't come additional runtime cost and the compiler seems to do a better job with code using it. Additionally this `io::Error` has a niche (still) so `io::Result<()>` is *also* 64 bits (8 bytes down from 16) and `io::Result` (used for lots of io trait functions) is 2x64 bits (16 bytes down from 24 — this means on x86_64 it can use the nice rax/rdx 2-reg struct return). More generally it shaves a whole 64 bit integer register off of the size of basically any `io::Result<()>`. (For clarity: Improving `io::Result` (rather than io::Error) was most of the motivation for this) On 32 bit (or other non-64bit) targets we still use something equivalent the old repr — I don't think think there's improving it since one of the fields it stores is a `i32` so we can't get below that and it's already about as close as we can get to it. --- ### Isn't Pointer Tagging Dodgy? The details of the layout and why its implemented the way it is are explained in the header comment of library/std/src/io/error/repr_bitpacked.rs. There's probably more details than there need to be but I didn't trim it down that much since there's a lot of stuff I did deliberately that might have not seemed that way. There's actually only one variant holding a pointer which gets tagged. This one is the (holder for the) user-provided error. I believe the scheme used to tag it is not UB and that it preserves pointer provenance (even though often pointer tagging does not) because the tagging operation is just `core::ptr::add` and untagging is `core::ptr::sub`. The result of both operations lands inside the original allocation so it would follow the safety contract of `core::ptr::{add sub}`. The other pointer this had to encode is not tagged — or rather the tagged repr is equivalent to untagged (it's tagged with 0b00 and has >=4b alignment so we can reuse the bottom bits). And the other variants we encode are just integers which (which can be untagged using bitwise operations without worry — they're integers). CC `@RalfJung` for the stuff in repr_bitpacked.rs as my comments are informed by a lot of the UCG work but it's possible I missed something or got it wrong (even if the implementation is okay there are parts of the header comment that says things like ""We can't do $x"" which could be false). --- ### Why So Many Changes? The repr change was mostly internal but changed one widely used API: I had to switch how `io::Error::new_const` works. This required switching `io::Error::new_const` to take the full message data (including the kind) as a `&'static` rather than just the string. This would have been really tedious but I made a macro that made it much simpler but it was a wide change since `io::Error::new_const` is used everywhere. This included changing files for a lot of targets I don't have easy access to (SGX? Haiku? Windows? Who has heard of these things) so I expect there to be spottiness in CI initially unless luck is on my side. Anyway this large only tangentially-related change is all in the first commit (although that commit also pulls the previous repr out into its own file) whereas the packing stuff is all in commit 2. --- P.S. I haven't looked at all of this since writing it and will do a pass over it again later sorry for any obvious typos or w/e. I also definitely repeat myself in comments and such. (It probably could use more tests too. I did some basic testing and made it so we `debug_assert!` in cases the decode isn't what we encoded but I don't know the degree which I can assume libstd's testing of IO would exercise this. That is: it wouldn't be surprising to me if libstds IO testing were minimal especially around error cases although I have no idea).",HEART,2022-04-29T12:46:36Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/87870,MERGED,2021-08-08T17:49:11Z,2021-10-03T16:22:36Z,Make `<[T]>::split_at_unchecked` and `<[T]>::split_at_mut_unchecked` public,WaffleLapkin,5051904d66b14d7b8dd2750bd30610c8c81cb01d,1,Auto merge of #87870 - WaffleLapkin:pub_split_at_unchecked r=dtolnay Make `<[T]>::split_at_unchecked` and `<[T]>::split_at_mut_unchecked` public The methods were originally added in https://github.com/rust-lang/rust/pull/75936 (https://github.com/sdroege/rust/commit/30dc32b10eb53e4a92c61a42062983db58838217) but for some reason as private. Nevertheless the methods have documentation and even a [tracking issue](https://github.com/rust-lang/rust/issues/76014). It's very weird to have a tracking issue for private methods and these methods may be useful outside of the standard library. As such this PR makes the methods public.,ROCKET,2021-10-08T19:36:58Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/87885,MERGED,2021-08-09T15:48:20Z,2021-08-12T16:17:19Z,Link to edition guide instead of issues for 2021 lints.,m-ou-se,3d733f6785efbda9fa6196c4077df5b31273f1b9,33,Rollup merge of #87885 - m-ou-se:edition-guide-links r=rylev Link to edition guide instead of issues for 2021 lints. This changes the 2021 lints to not link to github issues but to the edition guide instead. Fixes #86996,THUMBS_UP,2021-08-09T20:16:21Z,ehuss,NA https://github.com/rust-lang/rust/pull/87897,CLOSED,2021-08-09T22:11:22Z,2021-08-14T12:28:22Z,Add `PathBuf::with_join`,WilliamVenner,NA,NA,NA,THUMBS_DOWN,2021-08-11T15:50:51Z,camsteffen,NA https://github.com/rust-lang/rust/pull/87907,CLOSED,2021-08-10T04:19:03Z,2021-08-18T20:05:49Z,Switch Instant to use CLOCK_BOOTTIME,maurer,NA,NA,NA,THUMBS_UP,2021-08-10T07:39:24Z,ebarnard,eabarnard@gmail.com https://github.com/rust-lang/rust/pull/87907,CLOSED,2021-08-10T04:19:03Z,2021-08-18T20:05:49Z,Switch Instant to use CLOCK_BOOTTIME,maurer,NA,NA,NA,CONFUSED,2021-08-10T11:05:00Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/87907,CLOSED,2021-08-10T04:19:03Z,2021-08-18T20:05:49Z,Switch Instant to use CLOCK_BOOTTIME,maurer,NA,NA,NA,THUMBS_UP,2021-08-11T15:47:49Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/87907,CLOSED,2021-08-10T04:19:03Z,2021-08-18T20:05:49Z,Switch Instant to use CLOCK_BOOTTIME,maurer,NA,NA,NA,THUMBS_UP,2021-08-12T22:08:33Z,CryZe,NA https://github.com/rust-lang/rust/pull/87907,CLOSED,2021-08-10T04:19:03Z,2021-08-18T20:05:49Z,Switch Instant to use CLOCK_BOOTTIME,maurer,NA,NA,NA,THUMBS_UP,2021-09-23T20:28:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/87910,MERGED,2021-08-10T07:37:16Z,2021-10-04T10:09:18Z,Mark unsafe methods NonZero*::unchecked_(add|mul) as const.,iago-lito,e500f1c1e9de96edc3ac1ce1bccc0f241fa41c0a,1,Rollup merge of #87910 - iago-lito:mark_unsafe_nonzero_arithmetics_as_const r=joshtriplett Mark unsafe methods NonZero*::unchecked_(add|mul) as const. Now that https://github.com/rust-lang/rfcs/pull/3016 has landed these two unstable `std` function can be marked `const` according to this detail of #84186.,THUMBS_UP,2021-08-11T15:54:32Z,Smittyvb,me@smitop.com https://github.com/rust-lang/rust/pull/87915,MERGED,2021-08-10T10:54:07Z,2021-09-13T19:50:13Z,Use smaller spans for some structured suggestions,estebank,9bb77da74dac4768489127d21e32db19b59ada5b,60,Auto merge of #87915 - estebank:fancy-spans r=oli-obk Use smaller spans for some structured suggestions Use more accurate suggestion spans for * argument parse error * fully qualified path * missing code block type * numeric casts,THUMBS_UP,2021-08-10T11:47:00Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/87915,MERGED,2021-08-10T10:54:07Z,2021-09-13T19:50:13Z,Use smaller spans for some structured suggestions,estebank,9bb77da74dac4768489127d21e32db19b59ada5b,60,Auto merge of #87915 - estebank:fancy-spans r=oli-obk Use smaller spans for some structured suggestions Use more accurate suggestion spans for * argument parse error * fully qualified path * missing code block type * numeric casts,HEART,2021-09-16T13:14:55Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/87916,MERGED,2021-08-10T14:33:20Z,2021-08-12T23:48:27Z,Implement `black_box` using intrinsic,nbdd0121,0fa3190394475a84360b34e074e719d519bc40f1,9,Auto merge of #87916 - nbdd0121:black_box r=nagisa Implement `black_box` using intrinsic Introduce `black_box` intrinsic as suggested in https://github.com/rust-lang/rust/pull/87590#discussion_r680468700. This is still codegenned as empty inline assembly for LLVM. For MIR interpretation and cranelift it's treated as identity. cc `@Amanieu` as this is related to inline assembly cc `@bjorn3` for rustc_codegen_cranelift changes cc `@RalfJung` as this affects MIRI r? `@nagisa` I suppose,THUMBS_UP,2021-08-19T04:52:12Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/87918,MERGED,2021-08-10T16:35:01Z,2021-10-08T09:04:10Z,Enable AutoFDO.,mikebenfield,6c2d4bf3f7df75c60b6d81e9206a58aa30b0f8aa,12,Rollup merge of #87918 - mikebenfield:pr-afdo r=nikic Enable AutoFDO. This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Clink-arg='Wl --no-rosegment' -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo The option -Clink-arg='Wl --no-rosegment' is necessary to avoid lld putting an extra RO segment before the executable code which would make the binary silently incompatible with create_llvm_prof.,ROCKET,2021-10-07T05:56:40Z,hkratz,NA https://github.com/rust-lang/rust/pull/87918,MERGED,2021-08-10T16:35:01Z,2021-10-08T09:04:10Z,Enable AutoFDO.,mikebenfield,6c2d4bf3f7df75c60b6d81e9206a58aa30b0f8aa,12,Rollup merge of #87918 - mikebenfield:pr-afdo r=nikic Enable AutoFDO. This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Clink-arg='Wl --no-rosegment' -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo The option -Clink-arg='Wl --no-rosegment' is necessary to avoid lld putting an extra RO segment before the executable code which would make the binary silently incompatible with create_llvm_prof.,ROCKET,2021-10-19T15:44:43Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,HEART,2021-09-03T05:58:09Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,HEART,2021-09-03T06:25:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,HEART,2021-09-03T15:24:05Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,HEART,2021-09-03T17:07:14Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,THUMBS_UP,2021-09-08T15:29:21Z,t-rapp,NA https://github.com/rust-lang/rust/pull/87921,MERGED,2021-08-10T17:23:24Z,2021-08-29T02:21:08Z,Add Saturating type (based on Wrapping type),kellerkindt,677b517e66fe9df0b2ce72f5ec57d52cc0da506e,6,Auto merge of #87921 - kellerkindt:master r=kennytm Add Saturating type (based on Wrapping type) Tracking #87920 ### Unresolved Questions - [x] ~`impl Div for Saturating` falls back on inner integer division - which seems alright?~ - [x] add `saturating_div`? (to respect division by `-1`) - [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl` `ShlAssign` `Shr` and `ShrAssign`? - [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55) - [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~ - [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`? - [x] `Saturating::rotate_left` - [x] `Saturating::rotate_right` - [x] `Not` - [x] `BitXorOr` and `BitXorOrAssign` - [x] `BitOr` and `BitOrAssign` - [x] `BitAnd` and `BitAndAssign` - [x] `Saturating::swap_bytes` - [x] `Saturating::reverse_bits`,THUMBS_UP,2021-09-30T12:11:01Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/87937,MERGED,2021-08-11T14:13:27Z,2021-08-25T16:23:01Z,Don't mark `if_let_guard` as an incomplete feature,LeSeulArtichaut,a992a11913b39a258158646bb1e03528c5aa5060,11,Auto merge of #87937 - LeSeulArtichaut:active-if-let-guards r=nagisa Don't mark `if_let_guard` as an incomplete feature I don't think there is any reason for `if_let_guard` to be an incomplete feature and I think the reason they were marked in the first place was simply because they weren't implemented at all. r? `@pnkfelix` cc tracking issue #51114,EYES,2021-08-11T18:26:13Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/87937,MERGED,2021-08-11T14:13:27Z,2021-08-25T16:23:01Z,Don't mark `if_let_guard` as an incomplete feature,LeSeulArtichaut,a992a11913b39a258158646bb1e03528c5aa5060,11,Auto merge of #87937 - LeSeulArtichaut:active-if-let-guards r=nagisa Don't mark `if_let_guard` as an incomplete feature I don't think there is any reason for `if_let_guard` to be an incomplete feature and I think the reason they were marked in the first place was simply because they weren't implemented at all. r? `@pnkfelix` cc tracking issue #51114,EYES,2021-08-19T18:02:03Z,JakubKoralewski,contact@jcubed.me https://github.com/rust-lang/rust/pull/87942,MERGED,2021-08-11T19:08:54Z,2021-08-12T10:13:40Z,set the executable bit on pre-commit.sh,oconnor663,334f09b90b0a62778ef0d70c8793ede58c5dffde,1,Rollup merge of #87942 - oconnor663:pre_commit_exec r=jyn514 set the executable bit on pre-commit.sh `x.py setup` hardlinks this file into .git/hooks. Prior to this commit that led to the following warning emitted by `git commit`: hint: The '.git/hooks/pre-commit' hook was ignored because it's not set as executable. Making the checked-in script executable fixes this issue as the hardlinked copy uses the same flags. It looks like the file was originally executable but that bit was unset in commit b908905b3defa075d08661dc5916219a870b4856 of https://github.com/rust-lang/rust/pull/85305. It's possible that was unintentional.,HEART,2021-08-12T03:55:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/87944,MERGED,2021-08-11T20:07:44Z,2021-08-25T19:03:47Z,add Cell::as_array_of_cells similar to Cell::as_slice_of_cells,oconnor663,ccefe27670365f86cafbfa5b0776644980e919f0,2,Rollup merge of #87944 - oconnor663:as_array_of_cells r=scottmcm add Cell::as_array_of_cells similar to Cell::as_slice_of_cells I'd like to propose adding `Cell::as_array_of_cells` as a natural analog to `Cell::as_slice_of_cells`. I don't have a specific use case in mind other than that supporting slices but not arrays feels like a gap. Do other folks agree with that intuition? Would this addition be substantial enough to need an RFC? --- Previously converting `&mut [T; N]` to `&[Cell; N]` looks like this: ```rust let array = &mut [1 2 3]; let cells: &[Cell; 3] = Cell::from_mut(&mut array[..]) .as_slice_of_cells() .try_into() .unwrap(); ``` With this new helper method it looks like this: ```rust let array = &mut [1 2 3]; let cells = Cell::from_mut(array).as_array_of_cells(); ```,HOORAY,2021-09-08T14:12:03Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/87954,MERGED,2021-08-12T09:39:15Z,2021-08-13T08:31:42Z,Update Clippy,flip1995,04c9901a0838d20e6ac0bcda94ea1a8c239bb0d7,77,Auto merge of #87954 - flip1995:clippyup r=Manishearth Update Clippy r? `@Manishearth`,HOORAY,2021-08-12T09:45:18Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/87966,MERGED,2021-08-12T12:44:52Z,2021-08-13T16:57:22Z,Fix `command-create-pidfd` test inside unprivileged Docker containers,pietroalbini,fc3a90dc7435d3d2378cc558e06a4600d79e4115,1,Rollup merge of #87966 - pietroalbini:fix-pidfd-test r=m-ou-se Fix `command-create-pidfd` test inside unprivileged Docker containers In `src/test/ui/command/command-create-pidfd.rs` (added #81825) the detection code to skip the test on unsupported platforms doesn't account for unprivileged Docker containers (CI uses privileged containers) which leads to a test failure as you can't call the `clone3` syscall in that environment. This PR enhances the detection code to also consider unprivileged containers.,THUMBS_UP,2021-08-13T09:01:13Z,voidc,NA https://github.com/rust-lang/rust/pull/87969,MERGED,2021-08-12T13:26:14Z,2021-08-13T16:57:22Z,"Revert ""Rollup merge of #87779 - Aaron1011:stmt-ast-id r=petrochenkov""",Aaron1011,96c9dabd1792e45ea426e5459bc56bdcf4bc526e,3,"Rollup merge of #87969 - Aaron1011:revert-stmt-id r=petrochenkov Revert ""Rollup merge of #87779 - Aaron1011:stmt-ast-id r=petrochenkov"" Fixes #87877 This change interacts badly with `noop_flat_map_stmt` which synthesizes multiple statements with the same `NodeId`. I'm working on a better fix that will still allow us to remove this special case. For now let's revert the change to fix the ICE. This reverts commit a4262cc9841d91d48ef994b36eab323e615a7083 reversing changes made to 8ee962f88e1be7e29482b13c7776c26b98a93bf7.",HEART,2021-08-12T19:16:36Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/87971,CLOSED,2021-08-12T14:09:02Z,2021-08-12T14:12:56Z,Fix typo,hkmatsumoto,NA,NA,NA,THUMBS_UP,2021-08-12T14:13:09Z,estebank,NA https://github.com/rust-lang/rust/pull/87974,MERGED,2021-08-12T15:18:23Z,2021-08-15T07:40:52Z,Test and fix `size_hint` for slice’s [r]split* iterators,steffahn,40db258731a912325de612a1fc06d14e6df959ab,2,Auto merge of #87974 - steffahn:slice_split_size_hints r=dtolnay Test and fix `size_hint` for slice’s [r]split* iterators Adds extensive test (of `size_hint`) for all the _[r]split*_ iterators. Fixes `size_hint` upper bound for _split_inclusive*_ iterators which was one higher than necessary for non-empty slices. Fixes `size_hint` lower bound for _[r]splitn*_ iterators when _n == 0_ which was one too high. **Lower bound being one too high was a logic error violating the correctness condition of `size_hint`.** _Edit:_ I’ve opened an issue for that bug so this PR fixes #87978,THUMBS_UP,2021-08-12T18:23:45Z,the8472,NA https://github.com/rust-lang/rust/pull/87983,MERGED,2021-08-12T18:54:46Z,2021-08-19T06:27:10Z,Use more accurate spans when proposing adding lifetime to item,estebank,7449c6edf93d8d68cdaf48252e219c015e42c97e,17,Rollup merge of #87983 - estebank:smaller-lt-spans r=oli-obk Use more accurate spans when proposing adding lifetime to item,HOORAY,2021-08-12T19:19:01Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/87990,MERGED,2021-08-12T21:38:08Z,2021-08-17T04:19:02Z,Include (potentially remapped) working dir in crate hash,Aaron1011,a183141e2d0f0af7f12946ff1a81615fa35e8099,11,Auto merge of #87990 - Aaron1011:moved-src-dir r=cjgillot Include (potentially remapped) working dir in crate hash Fixes #85019 A `SourceFile` created during compilation may have a relative path (e.g. if rustc itself is invoked with a relative path). When we write out crate metadata we convert all relative paths to absolute paths using the current working directory. However the working directory is not included in the crate hash. This means that the crate metadata can change while the crate hash remains the same. Among other problems this can cause a fingerprint mismatch ICE since incremental compilation uses the crate metadata hash to determine if a foreign query is green. This commit moves the field holding the working directory from `Session` to `Options` including it as part of the crate hash. cc `@ohsayan`,THUMBS_UP,2021-08-12T23:31:58Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/87990,MERGED,2021-08-12T21:38:08Z,2021-08-17T04:19:02Z,Include (potentially remapped) working dir in crate hash,Aaron1011,a183141e2d0f0af7f12946ff1a81615fa35e8099,11,Auto merge of #87990 - Aaron1011:moved-src-dir r=cjgillot Include (potentially remapped) working dir in crate hash Fixes #85019 A `SourceFile` created during compilation may have a relative path (e.g. if rustc itself is invoked with a relative path). When we write out crate metadata we convert all relative paths to absolute paths using the current working directory. However the working directory is not included in the crate hash. This means that the crate metadata can change while the crate hash remains the same. Among other problems this can cause a fingerprint mismatch ICE since incremental compilation uses the crate metadata hash to determine if a foreign query is green. This commit moves the field holding the working directory from `Session` to `Options` including it as part of the crate hash. cc `@ohsayan`,HOORAY,2021-08-12T23:32:11Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/87990,MERGED,2021-08-12T21:38:08Z,2021-08-17T04:19:02Z,Include (potentially remapped) working dir in crate hash,Aaron1011,a183141e2d0f0af7f12946ff1a81615fa35e8099,11,Auto merge of #87990 - Aaron1011:moved-src-dir r=cjgillot Include (potentially remapped) working dir in crate hash Fixes #85019 A `SourceFile` created during compilation may have a relative path (e.g. if rustc itself is invoked with a relative path). When we write out crate metadata we convert all relative paths to absolute paths using the current working directory. However the working directory is not included in the crate hash. This means that the crate metadata can change while the crate hash remains the same. Among other problems this can cause a fingerprint mismatch ICE since incremental compilation uses the crate metadata hash to determine if a foreign query is green. This commit moves the field holding the working directory from `Session` to `Options` including it as part of the crate hash. cc `@ohsayan`,THUMBS_UP,2021-08-13T15:08:58Z,firedupmike,NA https://github.com/rust-lang/rust/pull/87990,MERGED,2021-08-12T21:38:08Z,2021-08-17T04:19:02Z,Include (potentially remapped) working dir in crate hash,Aaron1011,a183141e2d0f0af7f12946ff1a81615fa35e8099,11,Auto merge of #87990 - Aaron1011:moved-src-dir r=cjgillot Include (potentially remapped) working dir in crate hash Fixes #85019 A `SourceFile` created during compilation may have a relative path (e.g. if rustc itself is invoked with a relative path). When we write out crate metadata we convert all relative paths to absolute paths using the current working directory. However the working directory is not included in the crate hash. This means that the crate metadata can change while the crate hash remains the same. Among other problems this can cause a fingerprint mismatch ICE since incremental compilation uses the crate metadata hash to determine if a foreign query is green. This commit moves the field holding the working directory from `Session` to `Options` including it as part of the crate hash. cc `@ohsayan`,HOORAY,2021-08-13T15:09:06Z,firedupmike,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,EYES,2021-08-13T00:58:11Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-13T10:31:38Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-13T12:10:45Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-15T16:21:32Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-16T09:27:31Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-21T13:52:09Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-08-21T22:54:45Z,Wodann,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-09-03T05:46:17Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-09-03T06:29:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-09-03T06:29:43Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,EYES,2021-09-03T06:29:44Z,GrayJack,NA https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-10-14T23:19:42Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-10-20T15:15:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,THUMBS_UP,2021-10-20T15:15:43Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-10-22T09:41:12Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/87993,MERGED,2021-08-12T23:31:22Z,2021-10-05T06:54:20Z,Stabilize try_reserve,kornelski,99e6e3ff078162ffec3bb5fd810d54246add2196,16,Rollup merge of #87993 - kornelski:try_reserve_stable r=joshtriplett Stabilize try_reserve Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).,HOORAY,2021-10-29T11:11:17Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/88002,MERGED,2021-08-13T11:10:38Z,2021-08-19T11:54:39Z,Unbox mutexes condvars and rwlocks on hermit,stlankes,a9ab2e55395013de116340e4cbfa0bb0263bb658,5,Auto merge of #88002 - hermitcore:unbox-mutex r=dtolnay Unbox mutexes condvars and rwlocks on hermit [RustyHermit](https://github.com/hermitcore/rusty-hermit) provides now movable synchronization primitives and we are able to unbox mutexes and condvars.,EYES,2021-08-14T21:44:40Z,kw-fn,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-14T08:21:41Z,fmease,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-14T12:07:31Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-14T13:50:21Z,cjgillot,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HOORAY,2021-08-14T16:56:52Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-15T00:33:44Z,camelid,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-19T00:54:10Z,mohe2015,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-22T15:23:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HOORAY,2021-08-23T06:58:36Z,iago-lito,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-23T06:58:38Z,iago-lito,NA https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2021-08-29T00:32:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88019,MERGED,2021-08-14T03:43:26Z,2021-08-28T13:10:26Z,Treat macros as HIR items,inquisitivecrystal,05cccdc9b321e6565b3e62e8b52aec53d106ef2f,46,Auto merge of #88019 - inquisitivecrystal:macro-def r=cjgillot Treat macros as HIR items Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over which I've attempted to lay out below. By normalizing the treatment of macro items this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information see #87406. r? `@cjgillot` ## Backwards incompatibility This is backwards incompatible in one small way. Due to a mistake it was previously possible to apply stability attributes to an exported macro even without enabling the `staged_api` feature. This never should have worked. After this PR it will error as it should. We could make it a warning instead but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates so I'm not thrilled about the idea. ## Notes for reviewers ### Commit seperation I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect but it's better than looking at the combined diff which is quite overwhelming. The compiler and standard library build after each commit although tests do not necessarily pass and tools do not necessarily build till the end of the series. ### Special cases There are a few special cases that remain after this change. Here are the notable ones I remember: 1. Visibility works a bit differently for `macro_rules!` macros than other items since they aren't generally marked with `pub` but instead with `#[macro_export]`. 2. Since `#[macro_export]` macros always have paths at the top level of the crate some additional handling needs to be done on the reexport to top level. ### Performance impact I don't know for sure but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :) ## Issues resolved This resolves #87406 (the tracking issue for this change). It also fixes several bugs: Fixes #59306. Fixes #73754. Fixes #87257.,HEART,2022-06-28T21:44:23Z,dima74,dmitry.murzin@jetbrains.com https://github.com/rust-lang/rust/pull/88040,MERGED,2021-08-15T00:50:18Z,2021-09-01T11:47:23Z,BTree: remove Ord bound from new,nbdd0121,5878780e641239906a7a2986ccae048f7640be87,5,"Rollup merge of #88040 - nbdd0121:btreemap r=m-ou-se BTree: remove Ord bound from new `K: Ord` bound is unnecessary on `BTree{Map Set}::new` and their `Default` impl. No elements exist so there are nothing to compare anyway so I don't think ""future proof"" would be a blocker here. This is analogous to `HashMap::new` not having a `K: Eq + Hash` bound. #79245 originally does this and for some reason drops the change to `new` and `Default`. I can see why changes to other methods like `entry` or `symmetric_difference` need to be careful but I couldn't find out any reason not to do it on `new`. Removing the bound also makes the stabilisation of `const fn new` not depending on const trait bounds. cc `@steffahn` who suggests me to make this PR. r? `@dtolnay`",THUMBS_UP,2021-08-27T04:02:48Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/88040,MERGED,2021-08-15T00:50:18Z,2021-09-01T11:47:23Z,BTree: remove Ord bound from new,nbdd0121,5878780e641239906a7a2986ccae048f7640be87,5,"Rollup merge of #88040 - nbdd0121:btreemap r=m-ou-se BTree: remove Ord bound from new `K: Ord` bound is unnecessary on `BTree{Map Set}::new` and their `Default` impl. No elements exist so there are nothing to compare anyway so I don't think ""future proof"" would be a blocker here. This is analogous to `HashMap::new` not having a `K: Eq + Hash` bound. #79245 originally does this and for some reason drops the change to `new` and `Default`. I can see why changes to other methods like `entry` or `symmetric_difference` need to be careful but I couldn't find out any reason not to do it on `new`. Removing the bound also makes the stabilisation of `const fn new` not depending on const trait bounds. cc `@steffahn` who suggests me to make this PR. r? `@dtolnay`",THUMBS_UP,2021-08-27T08:45:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/88060,MERGED,2021-08-15T18:47:16Z,2021-10-03T09:04:46Z,Optimize unnecessary check in Vec::retain,TennyZhuang,c24c9067eec3aec8dd2013d24f6cd0dff3ecec4c,2,Auto merge of #88060 - TennyZhuang:optimize-vec-retain r=dtolnay Optimize unnecessary check in Vec::retain The function `vec::Vec::retain` only have two stages: 1. Nothing was deleted. 2. Some elements were deleted. Here is an unnecessary check `if g.deleted_cnt > 0` in the loop and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics. I write a special but common bench case for this optimization. I call retain on vec but keep all elements. Before and after this optimization: ``` test vec::bench_retain_whole_100000 ... bench: 84 803 ns/iter (+/- 17 314) ``` ``` test vec::bench_retain_whole_100000 ... bench: 42 638 ns/iter (+/- 16 910) ``` The result is expected there are two `if`s before the optimization and one `if` after.,THUMBS_UP,2021-08-16T07:53:24Z,JmPotato,github@ipotato.me https://github.com/rust-lang/rust/pull/88060,MERGED,2021-08-15T18:47:16Z,2021-10-03T09:04:46Z,Optimize unnecessary check in Vec::retain,TennyZhuang,c24c9067eec3aec8dd2013d24f6cd0dff3ecec4c,2,Auto merge of #88060 - TennyZhuang:optimize-vec-retain r=dtolnay Optimize unnecessary check in Vec::retain The function `vec::Vec::retain` only have two stages: 1. Nothing was deleted. 2. Some elements were deleted. Here is an unnecessary check `if g.deleted_cnt > 0` in the loop and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics. I write a special but common bench case for this optimization. I call retain on vec but keep all elements. Before and after this optimization: ``` test vec::bench_retain_whole_100000 ... bench: 84 803 ns/iter (+/- 17 314) ``` ``` test vec::bench_retain_whole_100000 ... bench: 42 638 ns/iter (+/- 16 910) ``` The result is expected there are two `if`s before the optimization and one `if` after.,THUMBS_UP,2021-08-16T09:23:48Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/88060,MERGED,2021-08-15T18:47:16Z,2021-10-03T09:04:46Z,Optimize unnecessary check in Vec::retain,TennyZhuang,c24c9067eec3aec8dd2013d24f6cd0dff3ecec4c,2,Auto merge of #88060 - TennyZhuang:optimize-vec-retain r=dtolnay Optimize unnecessary check in Vec::retain The function `vec::Vec::retain` only have two stages: 1. Nothing was deleted. 2. Some elements were deleted. Here is an unnecessary check `if g.deleted_cnt > 0` in the loop and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics. I write a special but common bench case for this optimization. I call retain on vec but keep all elements. Before and after this optimization: ``` test vec::bench_retain_whole_100000 ... bench: 84 803 ns/iter (+/- 17 314) ``` ``` test vec::bench_retain_whole_100000 ... bench: 42 638 ns/iter (+/- 16 910) ``` The result is expected there are two `if`s before the optimization and one `if` after.,THUMBS_UP,2021-09-29T21:32:31Z,Milo123459,NA https://github.com/rust-lang/rust/pull/88060,MERGED,2021-08-15T18:47:16Z,2021-10-03T09:04:46Z,Optimize unnecessary check in Vec::retain,TennyZhuang,c24c9067eec3aec8dd2013d24f6cd0dff3ecec4c,2,Auto merge of #88060 - TennyZhuang:optimize-vec-retain r=dtolnay Optimize unnecessary check in Vec::retain The function `vec::Vec::retain` only have two stages: 1. Nothing was deleted. 2. Some elements were deleted. Here is an unnecessary check `if g.deleted_cnt > 0` in the loop and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics. I write a special but common bench case for this optimization. I call retain on vec but keep all elements. Before and after this optimization: ``` test vec::bench_retain_whole_100000 ... bench: 84 803 ns/iter (+/- 17 314) ``` ``` test vec::bench_retain_whole_100000 ... bench: 42 638 ns/iter (+/- 16 910) ``` The result is expected there are two `if`s before the optimization and one `if` after.,THUMBS_UP,2021-10-08T23:09:41Z,MinusGix,NA https://github.com/rust-lang/rust/pull/88060,MERGED,2021-08-15T18:47:16Z,2021-10-03T09:04:46Z,Optimize unnecessary check in Vec::retain,TennyZhuang,c24c9067eec3aec8dd2013d24f6cd0dff3ecec4c,2,Auto merge of #88060 - TennyZhuang:optimize-vec-retain r=dtolnay Optimize unnecessary check in Vec::retain The function `vec::Vec::retain` only have two stages: 1. Nothing was deleted. 2. Some elements were deleted. Here is an unnecessary check `if g.deleted_cnt > 0` in the loop and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics. I write a special but common bench case for this optimization. I call retain on vec but keep all elements. Before and after this optimization: ``` test vec::bench_retain_whole_100000 ... bench: 84 803 ns/iter (+/- 17 314) ``` ``` test vec::bench_retain_whole_100000 ... bench: 42 638 ns/iter (+/- 16 910) ``` The result is expected there are two `if`s before the optimization and one `if` after.,THUMBS_UP,2021-10-10T11:16:21Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-16T06:30:42Z,hkratz,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-16T07:07:23Z,mati865,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-16T11:00:04Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-16T13:55:53Z,jonasbb,jonas@bushart.org https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-16T14:55:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-17T06:27:22Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-08-27T10:26:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-03T02:11:41Z,DianaNites,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-03T11:51:20Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-03T18:51:46Z,tgnottingham,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-04T04:37:26Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-04T19:20:10Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-09-29T17:53:30Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-10-15T22:10:14Z,Throne3d,NA https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-10-21T15:27:03Z,Matthias-Fauconneau,matthias.fauconneau@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2021-10-22T01:00:02Z,mattico,mattico8@gmail.com https://github.com/rust-lang/rust/pull/88069,MERGED,2021-08-16T02:29:07Z,2021-08-26T05:23:37Z,PGO for LLVM builds on x86_64-unknown-linux-gnu in CI,Mark-Simulacrum,c4be230b4a30eb74e3a3908455731ebc2f731d3d,10,Auto merge of #88069 - Mark-Simulacrum:llvm-pgo r=pietroalbini PGO for LLVM builds on x86_64-unknown-linux-gnu in CI This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles on multiple benchmarks and up to 19% wins on the -j1 wall times for rustc self-compilation. We can afford to spend the extra cycles building LLVM essentially once more for the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50 minutes on average and this adds just 10 more minutes. Given the sizeable improvements in compiler performance this is definitely worth it.,ROCKET,2022-05-20T07:24:57Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T06:13:20Z,hawkingrei,hawking.rei@gmail.com https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T09:23:38Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T10:35:44Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T14:56:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T15:26:29Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88075,MERGED,2021-08-16T05:43:43Z,2021-08-22T02:16:36Z,Optimize unnecessary check in VecDeque::retain,Xuanwo,9faa714154dbc03faa174a7d4f72d6bbbfd61f7c,2,Auto merge of #88075 - Xuanwo:vec_deque_retain r=dtolnay Optimize unnecessary check in VecDeque::retain This pr is highly inspired by https://github.com/rust-lang/rust/pull/88060 which shared the same idea: we can split the `for` loop into stages so that we can remove unnecessary checks like `del > 0`. ## Benchmarks Before ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 290 125 ns/iter (+/- 8 717) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 291 588 ns/iter (+/- 9 621) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 287 426 ns/iter (+/- 9 009) ``` After ```rust test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 243 940 ns/iter (+/- 8 563) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 242 768 ns/iter (+/- 3 903) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 202 926 ns/iter (+/- 6 332) ``` Based on the current benchmark this PR will improve the perf of `VecDeque::retain` by around 16%. For special cases the improvement will be up to 30%. Signed-off-by: Xuanwo ,THUMBS_UP,2021-08-16T20:11:09Z,hkratz,NA https://github.com/rust-lang/rust/pull/88096,CLOSED,2021-08-16T22:41:38Z,2021-10-31T07:55:54Z,Duplicate bounds lint,ibraheemdev,NA,NA,NA,THUMBS_UP,2021-08-19T17:09:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2021-08-17T15:05:20Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2021-10-04T13:39:23Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2021-10-06T20:42:18Z,hkratz,NA https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2021-10-07T09:13:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2021-10-21T04:46:53Z,yerke,NA https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,HOORAY,2022-01-04T11:59:05Z,faptc,NA https://github.com/rust-lang/rust/pull/88098,MERGED,2021-08-17T01:11:20Z,2022-03-18T05:26:18Z,Implement -Z oom=panic,Amanieu,d6f3a4ecb48ead838638e902f2fa4e5f3059779b,9,Auto merge of #88098 - Amanieu:oom_panic r=nagisa Implement -Z oom=panic This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596). Perf and binary size tests show negligible impact.,CONFUSED,2022-03-24T06:43:45Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-17T05:36:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-17T09:59:08Z,est31,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-17T17:47:53Z,CryZe,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-17T19:10:16Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-17T23:05:49Z,asquared31415,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-18T17:18:39Z,noproto,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-23T00:31:46Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-30T20:53:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-08-31T03:40:58Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-09-01T04:49:16Z,yerke,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-09-01T04:49:18Z,yerke,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-09-01T04:49:21Z,yerke,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-09-01T04:49:29Z,yerke,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-09-05T05:13:02Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-09-05T05:13:03Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-09-05T05:13:03Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-09T17:03:06Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-10-12T16:30:28Z,russells-crockpot,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-10-12T16:42:55Z,worstpractice,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-10-12T16:42:55Z,worstpractice,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-12T16:42:55Z,worstpractice,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-20T03:22:31Z,ttys3,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-21T15:13:03Z,zohnannor,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-10-21T15:13:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-21T17:46:13Z,PaulDance,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-10-21T21:50:18Z,Cyborus04,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-10-21T21:50:19Z,Cyborus04,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-10-21T21:50:21Z,Cyborus04,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-10-22T06:22:05Z,francis-du,francis@francis.run https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-10-22T06:22:06Z,francis-du,francis@francis.run https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-22T06:22:08Z,francis-du,francis@francis.run https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-10-22T06:22:09Z,francis-du,francis@francis.run https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-10-22T21:56:14Z,antmelnyk,anton.melnyk@printify.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-10-23T00:17:25Z,worstpractice,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-10-24T12:47:59Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-10-24T12:48:03Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2021-12-22T10:39:51Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2021-12-22T10:39:53Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HEART,2021-12-22T10:39:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",ROCKET,2021-12-22T10:39:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",THUMBS_UP,2022-02-03T07:54:58Z,dastanbeksamatov,dastanbeksamatov@gmail.com https://github.com/rust-lang/rust/pull/88100,MERGED,2021-08-17T01:46:58Z,2021-08-31T03:34:23Z,Make Edition 2021 Stable,HTG-YT,56ea5e0ee948999a916ff5f3d78ed79716d1006b,9,"Auto merge of #88100 - HTG-YT:edition2021-compopt-stabilization r=m-ou-se Make Edition 2021 Stable An item of #87959. This is an ""on-demand"" pull request which means it will be merged when it is the right time to.",HOORAY,2022-02-03T07:55:01Z,dastanbeksamatov,dastanbeksamatov@gmail.com https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-17T03:23:18Z,webern,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,HEART,2021-08-17T04:35:43Z,tjkirch,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-17T04:35:46Z,tjkirch,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-17T07:13:00Z,samuelkarp,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,HEART,2021-08-17T07:13:02Z,samuelkarp,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,CONFUSED,2021-08-17T08:07:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-17T10:31:40Z,estebank,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-17T13:51:47Z,hkratz,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2021-08-18T04:12:55Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2022-01-16T20:37:23Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,HEART,2022-01-16T20:37:24Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,THUMBS_UP,2022-05-20T19:42:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88101,CLOSED,2021-08-17T01:58:49Z,2022-06-08T20:14:28Z,[WIP] parameterize `-C prefer-dynamic`,pnkfelix,NA,NA,NA,HEART,2022-05-20T19:42:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88112,CLOSED,2021-08-17T14:18:12Z,2021-09-17T12:49:54Z,Arc locking,SoniEx2,NA,NA,NA,CONFUSED,2021-08-17T14:27:26Z,arniu,NA https://github.com/rust-lang/rust/pull/88112,CLOSED,2021-08-17T14:18:12Z,2021-09-17T12:49:54Z,Arc locking,SoniEx2,NA,NA,NA,CONFUSED,2021-08-17T14:57:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88112,CLOSED,2021-08-17T14:18:12Z,2021-09-17T12:49:54Z,Arc locking,SoniEx2,NA,NA,NA,CONFUSED,2021-08-17T15:36:32Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88112,CLOSED,2021-08-17T14:18:12Z,2021-09-17T12:49:54Z,Arc locking,SoniEx2,NA,NA,NA,CONFUSED,2021-08-18T03:16:30Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/88127,MERGED,2021-08-18T00:38:53Z,2021-08-18T15:55:02Z,Update cargo,ehuss,29d61427ac47dc16c83e1c66b929b1198a3ccc35,2,Auto merge of #88127 - ehuss:update-cargo r=ehuss Update cargo 8 commits in b51439fd8b505d4800a257acfecf3c69f81e35cf..e96bdb0c3d0a418e7fcd7fbd69be08abf830b4bc 2021-08-09 18:40:05 +0000 to 2021-08-17 22:58:47 +0000 - Support using rustbot to ping the Windows group (rust-lang/cargo#9802) - Show information about abnormal `fix` errors. (rust-lang/cargo#9799) - Bump jobserver. (rust-lang/cargo#9798) - Render build-std web links as hyperlinks (rust-lang/cargo#9795) - Teach cargo to failfast on recursive/corecursive aliases (rust-lang/cargo#9791) - Fix value-after-table error with profiles. (rust-lang/cargo#9789) - Fix plugin registrar change. (rust-lang/cargo#9790) - Ability to specify the output name for a bin target different from the crate name (rust-lang/cargo#9627),ROCKET,2021-08-18T09:49:08Z,hkratz,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-18T14:06:12Z,steven-joruk,steven@joruk.com https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-21T13:18:23Z,DavidHusicka,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-22T22:55:39Z,nonetrix,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-26T12:43:13Z,p--b,pb@fourieraudio.com https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-26T15:06:00Z,edmorley,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-08-29T00:37:44Z,ZizhengTai,me@zizheng.me https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-04T05:38:39Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-04T22:14:24Z,hkratz,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-11T10:44:29Z,Fogapod,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-16T18:09:51Z,cryptoquick,cryptoquick@pm.me https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-17T12:04:33Z,estebank,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-09-27T16:06:30Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/88137,MERGED,2021-08-18T12:16:04Z,2021-10-08T09:04:10Z,"On macOS make strip=""symbols"" not pass any options to strip",joshtriplett,cbb561fdab663993e483479db3be612771746b26,1,"Rollup merge of #88137 - joshtriplett:osx-strip-symbols-no-option r=michaelwoerister On macOS make strip=""symbols"" not pass any options to strip This makes the output with `strip=""symbols""` match the result of just calling `strip` on the output binary minimizing the size of the binary.",THUMBS_UP,2021-10-07T21:48:27Z,devnexen,devnexen@gmail.com https://github.com/rust-lang/rust/pull/88149,MERGED,2021-08-19T01:39:54Z,2021-08-21T04:20:32Z,Refactor fallback code to prepare for never type,Mark-Simulacrum,797095a686bdc821143e52ed1db2b98db9d0f3eb,32,Auto merge of #88149 - Mark-Simulacrum:prep-never-type r=jackh726 Refactor fallback code to prepare for never type This PR contains cherry-picks of some of `@nikomatsakis's` work from #79366 and shouldn't (AFAICT) represent any change in behavior. However the refactoring is good regardless of the never type work being landed and will reduce the size of those eventual PR(s) (and rebase pain). I am not personally an expert on this code and the commits are essentially 100% `@nikomatsakis's ` but they do seem reasonable to me by my understanding. Happy to edit with review of course. Commits are best reviewed in sequence rather than all together. r? `@jackh726` perhaps?,THUMBS_UP,2021-08-21T05:34:21Z,crlf0710,NA https://github.com/rust-lang/rust/pull/88163,MERGED,2021-08-19T16:00:53Z,2021-08-22T16:07:14Z,Fix clippy::collapsible_match with let expressions,camsteffen,7481e6d1a415853a96dcec11a052caaa02859b5a,17,Auto merge of #88163 - camsteffen:collapsible-match-fix r=Manishearth Fix clippy::collapsible_match with let expressions This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap. The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR). Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc `@rust-lang/clippy` `@xFrednet` do you want to review this?,THUMBS_UP,2021-08-19T18:06:34Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/88163,MERGED,2021-08-19T16:00:53Z,2021-08-22T16:07:14Z,Fix clippy::collapsible_match with let expressions,camsteffen,7481e6d1a415853a96dcec11a052caaa02859b5a,17,Auto merge of #88163 - camsteffen:collapsible-match-fix r=Manishearth Fix clippy::collapsible_match with let expressions This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap. The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR). Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc `@rust-lang/clippy` `@xFrednet` do you want to review this?,THUMBS_UP,2021-08-19T23:28:15Z,dllu,NA https://github.com/rust-lang/rust/pull/88163,MERGED,2021-08-19T16:00:53Z,2021-08-22T16:07:14Z,Fix clippy::collapsible_match with let expressions,camsteffen,7481e6d1a415853a96dcec11a052caaa02859b5a,17,Auto merge of #88163 - camsteffen:collapsible-match-fix r=Manishearth Fix clippy::collapsible_match with let expressions This fixes rust-lang/rust-clippy#7575 which is a regression from #80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap. The fix is basically to re-generalize `match` and `if let` for the lint implementation (they were split because `if let` no longer desugars to `match` in the HIR). Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc `@rust-lang/clippy` `@xFrednet` do you want to review this?,THUMBS_UP,2021-08-21T12:42:56Z,NiklasEi,git@nikl.me https://github.com/rust-lang/rust/pull/88166,MERGED,2021-08-19T19:07:09Z,2021-08-22T20:23:38Z,canonicalize consts before calling try_unify_abstract_consts query,BoxyUwU,91f9806208834de3fb5f62712356b0d84ec388fd,12,Auto merge of #88166 - BoxyUwU:const-equate-canon r=lcnr canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`,HOORAY,2021-08-21T01:18:45Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/88166,MERGED,2021-08-19T19:07:09Z,2021-08-22T20:23:38Z,canonicalize consts before calling try_unify_abstract_consts query,BoxyUwU,91f9806208834de3fb5f62712356b0d84ec388fd,12,Auto merge of #88166 - BoxyUwU:const-equate-canon r=lcnr canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`,HOORAY,2021-08-22T09:59:20Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/88166,MERGED,2021-08-19T19:07:09Z,2021-08-22T20:23:38Z,canonicalize consts before calling try_unify_abstract_consts query,BoxyUwU,91f9806208834de3fb5f62712356b0d84ec388fd,12,Auto merge of #88166 - BoxyUwU:const-equate-canon r=lcnr canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`,HOORAY,2021-08-23T08:54:48Z,SephVelut,NA https://github.com/rust-lang/rust/pull/88166,MERGED,2021-08-19T19:07:09Z,2021-08-22T20:23:38Z,canonicalize consts before calling try_unify_abstract_consts query,BoxyUwU,91f9806208834de3fb5f62712356b0d84ec388fd,12,Auto merge of #88166 - BoxyUwU:const-equate-canon r=lcnr canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`,HOORAY,2021-08-23T09:02:26Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88166,MERGED,2021-08-19T19:07:09Z,2021-08-22T20:23:38Z,canonicalize consts before calling try_unify_abstract_consts query,BoxyUwU,91f9806208834de3fb5f62712356b0d84ec388fd,12,Auto merge of #88166 - BoxyUwU:const-equate-canon r=lcnr canonicalize consts before calling try_unify_abstract_consts query Fixes #88022 Fixes #86953 Fixes #77708 Fixes #82034 Fixes #85031 these ICEs were all caused by calling the `try_unify_abstract_consts` query with inference vars in substs r? `@lcnr`,HOORAY,2021-10-06T08:24:12Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/88175,MERGED,2021-08-20T02:07:58Z,2021-10-04T00:24:54Z,Add expansion to while desugar spans,camsteffen,e737694a4d66b01308b73d4559a35b43e414faf9,7,Auto merge of #88175 - camsteffen:let-desugar-span r=Manishearth Add expansion to while desugar spans In the same vein as #88163 this reverts a change in Clippy behavior as a result of #80357 (and reverts some `#[allow]`s): This changes `clippy::blocks_in_if_conditions` to not fire on `while` loops. Though we might actually want Clippy to lint those cases we should introduce the change purposefully with tests and possibly under a different lint name. The actual change here is to add a desugaring expansion to the spans when lowering a `while` loop. r? `@Manishearth`,HEART,2021-08-23T09:51:32Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/88176,MERGED,2021-08-20T03:05:09Z,2021-08-20T19:06:47Z,Reenable RemoveZsts,erikdesjardins,914a1e2c517dfbaa23a4ec4a3eebefb3e2c253c2,13,Auto merge of #88176 - erikdesjardins:rezst r=oli-obk Reenable RemoveZsts Now that the underlying issue has been fixed by #88124 we can reland #83417. r? `@oli-obk`,THUMBS_UP,2021-08-20T18:17:01Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/88176,MERGED,2021-08-20T03:05:09Z,2021-08-20T19:06:47Z,Reenable RemoveZsts,erikdesjardins,914a1e2c517dfbaa23a4ec4a3eebefb3e2c253c2,13,Auto merge of #88176 - erikdesjardins:rezst r=oli-obk Reenable RemoveZsts Now that the underlying issue has been fixed by #88124 we can reland #83417. r? `@oli-obk`,THUMBS_UP,2021-08-20T19:00:59Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88177,MERGED,2021-08-20T03:21:42Z,2021-09-02T21:27:04Z,Stabilize std::os::unix::fs::chroot,joshtriplett,e50069ff4f4b8c95443103d747f6aa22e64dc22c,1,Rollup merge of #88177 - joshtriplett:stabilize-chroot r=m-ou-se Stabilize std::os::unix::fs::chroot I've verified that this works as documented and I've tested it in (a nightly build of) production software as a replacement for an unsafe call to `libc::chroot`. It's been available in nightly for a few releases. I think it's ready to stabilize. --- Tracking issue: https://github.com/rust-lang/rust/issues/84715,HOORAY,2021-08-27T09:32:42Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/88177,MERGED,2021-08-20T03:21:42Z,2021-09-02T21:27:04Z,Stabilize std::os::unix::fs::chroot,joshtriplett,e50069ff4f4b8c95443103d747f6aa22e64dc22c,1,Rollup merge of #88177 - joshtriplett:stabilize-chroot r=m-ou-se Stabilize std::os::unix::fs::chroot I've verified that this works as documented and I've tested it in (a nightly build of) production software as a replacement for an unsafe call to `libc::chroot`. It's been available in nightly for a few releases. I think it's ready to stabilize. --- Tracking issue: https://github.com/rust-lang/rust/issues/84715,HOORAY,2021-09-03T06:27:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88177,MERGED,2021-08-20T03:21:42Z,2021-09-02T21:27:04Z,Stabilize std::os::unix::fs::chroot,joshtriplett,e50069ff4f4b8c95443103d747f6aa22e64dc22c,1,Rollup merge of #88177 - joshtriplett:stabilize-chroot r=m-ou-se Stabilize std::os::unix::fs::chroot I've verified that this works as documented and I've tested it in (a nightly build of) production software as a replacement for an unsafe call to `libc::chroot`. It's been available in nightly for a few releases. I think it's ready to stabilize. --- Tracking issue: https://github.com/rust-lang/rust/issues/84715,HOORAY,2021-09-04T14:06:09Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88186,OPEN,2021-08-20T17:54:58Z,NA,Make AST->HIR lowering incremental,cjgillot,NA,NA,NA,HOORAY,2021-08-20T18:54:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88186,OPEN,2021-08-20T17:54:58Z,NA,Make AST->HIR lowering incremental,cjgillot,NA,NA,NA,HOORAY,2021-08-20T18:56:54Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88186,OPEN,2021-08-20T17:54:58Z,NA,Make AST->HIR lowering incremental,cjgillot,NA,NA,NA,HOORAY,2021-09-29T11:12:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88186,OPEN,2021-08-20T17:54:58Z,NA,Make AST->HIR lowering incremental,cjgillot,NA,NA,NA,HOORAY,2022-04-07T14:55:52Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/88186,OPEN,2021-08-20T17:54:58Z,NA,Make AST->HIR lowering incremental,cjgillot,NA,NA,NA,HOORAY,2022-04-28T22:44:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/88196,MERGED,2021-08-20T21:21:23Z,2021-08-25T19:03:47Z,Refactor `named_asm_labels` to a HIR lint,asquared31415,891fa3c5556c964fd4ebe1dab39d87917f1c9c4d,10,Rollup merge of #88196 - asquared31415:named-asm-labels-refactor r=Amanieu Refactor `named_asm_labels` to a HIR lint As discussed on #88169 the `named_asm_labels` lint could be moved to a HIR lint. That allows future lints or custom plugins or clippy lints to more easily access the `asm!` macro's data and create better error messages with the lints.,THUMBS_UP,2021-08-20T21:24:26Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/88218,MERGED,2021-08-22T01:46:45Z,2021-08-25T19:03:47Z,Remove `Session.trait_methods_not_found`,Aaron1011,f2cbbb93a2e0008f2907894ecd9fd9de3b39595b,4,Rollup merge of #88218 - Aaron1011:missing-method-dyn r=nagisa Remove `Session.trait_methods_not_found` Instead avoid registering the problematic well-formed obligation to begin with. This removes global untracked mutable state and avoids potential issues with incremental compilation.,THUMBS_UP,2021-08-23T10:57:43Z,estebank,NA https://github.com/rust-lang/rust/pull/88223,MERGED,2021-08-22T06:52:14Z,2021-08-25T19:03:47Z,Remove the `TryV2` alias,scottmcm,b09c2547df8c0ab832b5b6764f8587e850a12533,6,Rollup merge of #88223 - scottmcm:fix-alias r=yaahc Remove the `TryV2` alias Post-bootstrap-update cleanup. (No more `try_trait_transition` feature.),HOORAY,2021-08-23T19:38:37Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/88226,MERGED,2021-08-22T10:55:00Z,2021-08-25T19:03:47Z,Fix typo “a Rc” → “an Rc” (and a few more),steffahn,cc2a1271d430d633b712dab71e2e58feb959c01b,5,"Rollup merge of #88226 - steffahn:an_rc r=michaelwoerister Fix typo “a Rc” → “an Rc” (and a few more) After stumbling about it in the dev-guide I’ve devided to eliminate all mentions of “a Rc” replacing it with “an Rc”. E.g. ```plain $ rg ""(^|[^'])\ba\b[^\w=:]*\bRc"" compiler/rustc_data_structures/src/owning_ref/mod.rs 1149:/// Typedef of a owning reference that uses a `Rc` as the owner. library/std/src/ffi/os_str.rs 919: /// Converts a [`OsString`] into a [`Rc`]`` without copying or allocating. library/std/src/ffi/c_str.rs 961: /// Converts a [`CString`] into a [`Rc`]`` without copying or allocating. src/doc/rustc-dev-guide/src/query.md 61:are cheaply cloneable; insert a `Rc` if necessary). src/doc/book/src/ch15-06-reference-cycles.md 72:decreases the reference count of the `a` `Rc` instance from 2 to 1 as library/alloc/src/rc.rs 1746: /// Converts a generic type `T` into a `Rc` ``` _(the match in the book is a false positive)_ Since the dev-guide is a submodule it’s getting a separate PR: rust-lang/rustc-dev-guide#1191 I’ve also gone ahead and done the same search for `RwLock` and hit a few cases in the `OwningRef` adaption. Then I couldn’t keep the countless cases of “a owning …” or “a owner” unaddressed which concludes this PR. `@rustbot` label C-cleanup",HEART,2021-08-22T15:11:55Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88230,MERGED,2021-08-22T12:53:36Z,2021-08-23T22:55:22Z,Fix typos “a”→“an”,steffahn,5cf025f076e76d235cc3e795a22499cff9f4fc62,150,Rollup merge of #88230 - steffahn:a_an r=oli-obk Fix typos “a”→“an” Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an. While automation was used to find these every change was checked manually. Changes in submodules get separate PRs: * https://github.com/rust-lang/stdarch/pull/1201 * https://github.com/rust-lang/cargo/pull/9821 * https://github.com/rust-lang/miri/pull/1874 * https://github.com/rust-lang/rls/pull/1746 * https://github.com/rust-analyzer/rust-analyzer/pull/9984 _folks @ rust-analyzer are fast at merging…_ * https://github.com/rust-analyzer/rust-analyzer/pull/9985 * https://github.com/rust-analyzer/rust-analyzer/pull/9987 * https://github.com/rust-analyzer/rust-analyzer/pull/9989 _For `clippy` I don’t know if the changes should better better be moved to a PR to the original repo._
This has some overlap with #88226 but neither is a strict superset of the other. If you want multiple commits I can split it up; in that case make sure to suggest a criterion for splitting.,HEART,2021-08-22T15:08:36Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88232,MERGED,2021-08-22T13:10:12Z,2021-08-23T22:55:22Z,Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.,m-ou-se,c31e02a24caac2a4277475a79eb2934141265dac,8,Rollup merge of #88232 - m-ou-se:macro-name-imported-but-not-macro r=estebank Add notes to macro-not-found diagnostics to point out how things with the same name were not a match. This adds notes like: ``` error: cannot find derive macro `Serialize` in this scope --> $DIR/issue-88206.rs:22:10 | LL | #[derive(Serialize)] | ^^^^^^^^^ | note: `Serialize` is imported here but it is not a derive macro --> $DIR/issue-88206.rs:17:11 | LL | use hey::{Serialize Deserialize}; | ^^^^^^^^^ ``` Fixes https://github.com/rust-lang/rust/issues/88206 Includes https://github.com/rust-lang/rust/pull/88229 r? `@estebank`,HOORAY,2021-08-23T14:46:46Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/88232,MERGED,2021-08-22T13:10:12Z,2021-08-23T22:55:22Z,Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.,m-ou-se,c31e02a24caac2a4277475a79eb2934141265dac,8,Rollup merge of #88232 - m-ou-se:macro-name-imported-but-not-macro r=estebank Add notes to macro-not-found diagnostics to point out how things with the same name were not a match. This adds notes like: ``` error: cannot find derive macro `Serialize` in this scope --> $DIR/issue-88206.rs:22:10 | LL | #[derive(Serialize)] | ^^^^^^^^^ | note: `Serialize` is imported here but it is not a derive macro --> $DIR/issue-88206.rs:17:11 | LL | use hey::{Serialize Deserialize}; | ^^^^^^^^^ ``` Fixes https://github.com/rust-lang/rust/issues/88206 Includes https://github.com/rust-lang/rust/pull/88229 r? `@estebank`,HOORAY,2021-08-25T14:48:23Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-08-25T18:21:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-08-28T11:57:06Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-05T11:35:13Z,mati865,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-12T16:44:14Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-14T17:03:54Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-25T19:12:40Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-29T23:43:14Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-30T02:59:28Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-30T08:35:43Z,tux3,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-30T17:04:36Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-09-30T18:05:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-10-01T00:57:51Z,moy2010,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-10-01T07:08:45Z,ThrashAbaddon,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-10-07T15:13:23Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-10-21T20:32:51Z,bluss,NA https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,HOORAY,2021-11-12T17:20:53Z,adelarsq,adelarsq@gmail.com https://github.com/rust-lang/rust/pull/88243,MERGED,2021-08-22T20:58:35Z,2021-09-25T17:14:41Z,Enable new pass manager with LLVM 13,nikic,63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a,3,Auto merge of #88243 - nikic:newpm-2 r=nagisa Enable new pass manager with LLVM 13 The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15. This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.,THUMBS_UP,2021-11-20T12:57:31Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/88262,MERGED,2021-08-23T16:10:44Z,2021-08-29T20:27:13Z,Cow'ify some pprust methods,klensy,ae0b03bc6b4e1544f43b9a8053bdb0f0ed4a19e1,5,Auto merge of #88262 - klensy:pprust-cow r=nagisa Cow'ify some pprust methods Reduce number of potential needless de/allocations by using `Cow<'static str>` instead of explicit `String` type.,THUMBS_UP,2021-08-24T15:59:33Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88262,MERGED,2021-08-23T16:10:44Z,2021-08-29T20:27:13Z,Cow'ify some pprust methods,klensy,ae0b03bc6b4e1544f43b9a8053bdb0f0ed4a19e1,5,Auto merge of #88262 - klensy:pprust-cow r=nagisa Cow'ify some pprust methods Reduce number of potential needless de/allocations by using `Cow<'static str>` instead of explicit `String` type.,THUMBS_UP,2021-08-25T18:15:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88262,MERGED,2021-08-23T16:10:44Z,2021-08-29T20:27:13Z,Cow'ify some pprust methods,klensy,ae0b03bc6b4e1544f43b9a8053bdb0f0ed4a19e1,5,Auto merge of #88262 - klensy:pprust-cow r=nagisa Cow'ify some pprust methods Reduce number of potential needless de/allocations by using `Cow<'static str>` instead of explicit `String` type.,THUMBS_UP,2021-09-03T06:23:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88266,MERGED,2021-08-23T19:19:07Z,2021-08-24T23:30:46Z,resolve type variables after checking casts,nikomatsakis,b03ccace573bb91e27625c190a0f7807045a1012,11,Auto merge of #88266 - nikomatsakis:issue-87879 r=jackh726 resolve type variables after checking casts r? `@jackh726` Fixes #87814 Fixes #88118 Supercedes #87879 (cc `@ldm0)`,THUMBS_UP,2021-08-24T03:50:26Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/88270,MERGED,2021-08-23T22:34:24Z,2021-08-27T03:48:03Z,Handle type ascription type ops in NLL HRTB diagnostics,lqd,1e94fe1a4553e4fcbbaecd385592f1d277d05e19,7,"Rollup merge of #88270 - lqd:hrtb-type-ascription r=nikomatsakis Handle type ascription type ops in NLL HRTB diagnostics Currently there are still a few cases of the ""higher-ranked subtype error"" of yore 4 of which are related to type ascription. This PR is a follow-up to #86700 adding support for type ascription type ops and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157) or an imprecision in some parts of normalization as [described here](https://github.com/rust-lang/rust/pull/86700#discussion_r689086688)). Since we discussed these recently: - [here](https://github.com/rust-lang/rust/pull/86700#discussion_r689158868) cc ````@matthewjasper ```` - and [here](https://github.com/rust-lang/rust/issues/57374#issuecomment-901500856) cc ````@Aaron1011.```` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ````@estebank```` (so that they shake their fist at NLL's general direction less often) or ````@nikomatsakis```` or matthew or aaron the more the merrier.",THUMBS_UP,2021-08-23T23:36:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88270,MERGED,2021-08-23T22:34:24Z,2021-08-27T03:48:03Z,Handle type ascription type ops in NLL HRTB diagnostics,lqd,1e94fe1a4553e4fcbbaecd385592f1d277d05e19,7,"Rollup merge of #88270 - lqd:hrtb-type-ascription r=nikomatsakis Handle type ascription type ops in NLL HRTB diagnostics Currently there are still a few cases of the ""higher-ranked subtype error"" of yore 4 of which are related to type ascription. This PR is a follow-up to #86700 adding support for type ascription type ops and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157) or an imprecision in some parts of normalization as [described here](https://github.com/rust-lang/rust/pull/86700#discussion_r689086688)). Since we discussed these recently: - [here](https://github.com/rust-lang/rust/pull/86700#discussion_r689158868) cc ````@matthewjasper ```` - and [here](https://github.com/rust-lang/rust/issues/57374#issuecomment-901500856) cc ````@Aaron1011.```` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ````@estebank```` (so that they shake their fist at NLL's general direction less often) or ````@nikomatsakis```` or matthew or aaron the more the merrier.",HEART,2021-08-24T15:01:02Z,estebank,NA https://github.com/rust-lang/rust/pull/88270,MERGED,2021-08-23T22:34:24Z,2021-08-27T03:48:03Z,Handle type ascription type ops in NLL HRTB diagnostics,lqd,1e94fe1a4553e4fcbbaecd385592f1d277d05e19,7,"Rollup merge of #88270 - lqd:hrtb-type-ascription r=nikomatsakis Handle type ascription type ops in NLL HRTB diagnostics Currently there are still a few cases of the ""higher-ranked subtype error"" of yore 4 of which are related to type ascription. This PR is a follow-up to #86700 adding support for type ascription type ops and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157) or an imprecision in some parts of normalization as [described here](https://github.com/rust-lang/rust/pull/86700#discussion_r689086688)). Since we discussed these recently: - [here](https://github.com/rust-lang/rust/pull/86700#discussion_r689158868) cc ````@matthewjasper ```` - and [here](https://github.com/rust-lang/rust/issues/57374#issuecomment-901500856) cc ````@Aaron1011.```` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ````@estebank```` (so that they shake their fist at NLL's general direction less often) or ````@nikomatsakis```` or matthew or aaron the more the merrier.",HEART,2021-08-27T22:19:53Z,camelid,NA https://github.com/rust-lang/rust/pull/88271,MERGED,2021-08-23T22:49:00Z,2021-08-25T02:17:43Z,2229: Consider varaiables mentioned in closure as used,arora-aman,faa0a10406319264e81086fe88fd426cbfa09021,5,Auto merge of #88271 - sexxi-goose:liveness r=nikomatsakis 2229: Consider varaiables mentioned in closure as used Fixes: https://github.com/rust-lang/project-rfc-2229/issues/57 r? `@nikomatsakis`,HOORAY,2021-08-24T00:00:17Z,roxelo,NA https://github.com/rust-lang/rust/pull/88288,OPEN,2021-08-24T11:08:01Z,NA,Experimental new MIR optimization pass: Replace wildcard match with individual matches ,hkratz,NA,NA,NA,HEART,2021-08-24T16:01:04Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88292,MERGED,2021-08-24T15:46:00Z,2021-09-16T22:17:43Z,Enable --generate-link-to-definition for rustc's docs,SkiFire13,0ad800c417e7d4ed7d172c02666cb1da6ba62823,1,Rollup merge of #88292 - SkiFire13:enable-rustdoc-links r=jyn514 Enable --generate-link-to-definition for rustc's docs cc `@jyn514`,THUMBS_UP,2021-09-17T22:32:10Z,weihanglo,NA https://github.com/rust-lang/rust/pull/88293,MERGED,2021-08-24T15:58:49Z,2021-08-25T19:03:47Z,Fix grammar in alloc test,est31,0aabf4bb4b74e9c7dd2c6164f362940dd6e5bf44,1,Rollup merge of #88293 - est31:fix_grammar r=Mark-Simulacrum Fix grammar in alloc test,THUMBS_UP,2021-08-24T16:02:54Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88308,MERGED,2021-08-24T19:17:28Z,2021-08-26T18:05:33Z,Morph `layout_raw` query into `layout_of`.,eddyb,4b9f4b221b92193c7e95b1beb502c6eb32c3b613,9,Auto merge of #88308 - eddyb:cooked-layouts r=nagisa Morph `layout_raw` query into `layout_of`. Before this PR `LayoutCx::layout_of` wrapped the `layout_raw` query to: * normalize the type before attempting to compute the layout * pass the layout to `record_layout_for_printing` for `-Zprint-type-sizes` Moving those two responsibilities into the query may reduce overhead (due to cached calls skipping those steps) but I want to do a perf run to know. One of the changes I had to make was changing the return type of the query to be able to both get out the type produced by normalizing inside the query *and* to match the signature of the old `TyCtxt::layout_of`. This change may be worse perf-wise so that's another reason I want to check. r? `@nagisa` cc `@oli-obk`,THUMBS_UP,2021-08-25T06:50:23Z,oli-obk,NA https://github.com/rust-lang/rust/pull/88308,MERGED,2021-08-24T19:17:28Z,2021-08-26T18:05:33Z,Morph `layout_raw` query into `layout_of`.,eddyb,4b9f4b221b92193c7e95b1beb502c6eb32c3b613,9,Auto merge of #88308 - eddyb:cooked-layouts r=nagisa Morph `layout_raw` query into `layout_of`. Before this PR `LayoutCx::layout_of` wrapped the `layout_raw` query to: * normalize the type before attempting to compute the layout * pass the layout to `record_layout_for_printing` for `-Zprint-type-sizes` Moving those two responsibilities into the query may reduce overhead (due to cached calls skipping those steps) but I want to do a perf run to know. One of the changes I had to make was changing the return type of the query to be able to both get out the type produced by normalizing inside the query *and* to match the signature of the old `TyCtxt::layout_of`. This change may be worse perf-wise so that's another reason I want to check. r? `@nagisa` cc `@oli-obk`,THUMBS_UP,2021-08-25T21:41:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/88308,MERGED,2021-08-24T19:17:28Z,2021-08-26T18:05:33Z,Morph `layout_raw` query into `layout_of`.,eddyb,4b9f4b221b92193c7e95b1beb502c6eb32c3b613,9,Auto merge of #88308 - eddyb:cooked-layouts r=nagisa Morph `layout_raw` query into `layout_of`. Before this PR `LayoutCx::layout_of` wrapped the `layout_raw` query to: * normalize the type before attempting to compute the layout * pass the layout to `record_layout_for_printing` for `-Zprint-type-sizes` Moving those two responsibilities into the query may reduce overhead (due to cached calls skipping those steps) but I want to do a perf run to know. One of the changes I had to make was changing the return type of the query to be able to both get out the type produced by normalizing inside the query *and* to match the signature of the old `TyCtxt::layout_of`. This change may be worse perf-wise so that's another reason I want to check. r? `@nagisa` cc `@oli-obk`,THUMBS_UP,2021-08-26T10:54:55Z,hkratz,NA https://github.com/rust-lang/rust/pull/88310,MERGED,2021-08-25T00:01:55Z,2022-01-01T13:28:15Z,Lock bootstrap (x.py) build directory,worldeva,5a5c9282e04711df07beb883eb463a136f91fbf9,1,Rollup merge of #88310 - worldeva:bootstrap-locking r=Mark-Simulacrum Lock bootstrap (x.py) build directory Closes #76661 closes #80849 `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` because he was one that told me about this~,HOORAY,2021-09-13T15:23:34Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/88310,MERGED,2021-08-25T00:01:55Z,2022-01-01T13:28:15Z,Lock bootstrap (x.py) build directory,worldeva,5a5c9282e04711df07beb883eb463a136f91fbf9,1,Rollup merge of #88310 - worldeva:bootstrap-locking r=Mark-Simulacrum Lock bootstrap (x.py) build directory Closes #76661 closes #80849 `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` because he was one that told me about this~,HEART,2021-12-09T04:32:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88310,MERGED,2021-08-25T00:01:55Z,2022-01-01T13:28:15Z,Lock bootstrap (x.py) build directory,worldeva,5a5c9282e04711df07beb883eb463a136f91fbf9,1,Rollup merge of #88310 - worldeva:bootstrap-locking r=Mark-Simulacrum Lock bootstrap (x.py) build directory Closes #76661 closes #80849 `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` because he was one that told me about this~,HOORAY,2021-12-28T19:45:25Z,Milo123459,NA https://github.com/rust-lang/rust/pull/88310,MERGED,2021-08-25T00:01:55Z,2022-01-01T13:28:15Z,Lock bootstrap (x.py) build directory,worldeva,5a5c9282e04711df07beb883eb463a136f91fbf9,1,Rollup merge of #88310 - worldeva:bootstrap-locking r=Mark-Simulacrum Lock bootstrap (x.py) build directory Closes #76661 closes #80849 `x.py` creates a lock file at `project_root/lock.db` r? `@jyn514` because he was one that told me about this~,HEART,2022-01-15T05:06:50Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/88313,MERGED,2021-08-25T00:57:13Z,2022-02-07T18:30:36Z,Make the pre-commit script pre-push instead,jyn514,aee13fb7c50faba1db567736c1b17cbc4716c74d,3,Rollup merge of #88313 - jyn514:pre-push r=Mark-Simulacrum Make the pre-commit script pre-push instead This should make it substantially less annoying and hopefully more people will find it useful. In particular it will no longer run tidy each time you run `git commit --amend` or rebase a branch. This also warns if you have the old script in pre-commit; see the HACK comment for details. r? ````@Mark-Simulacrum```` cc ````@caass````,HEART,2021-08-27T20:56:58Z,camsteffen,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-25T08:12:22Z,ricky26,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-25T14:07:00Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-25T16:30:35Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-29T13:45:20Z,apiraino,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-29T22:38:21Z,brainstorm,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-08-31T15:11:54Z,reinvantveer,rein@vantveer.me https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-09T08:51:45Z,joetsoi,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-19T19:00:09Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-20T15:00:11Z,Newbytee,newbie13xd@gmail.com https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-21T06:49:50Z,na-g,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-21T15:57:35Z,zenlor,lorenzo@frenzart.com https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-09-21T19:20:07Z,amiga23,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-21T21:16:00Z,bb010g,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-09-21T21:47:02Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-09-22T01:52:57Z,dafyddcrosby,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-09-23T05:37:45Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-09-23T05:58:22Z,m0ppers,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-10-01T03:52:34Z,musha68k,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-10-01T03:52:36Z,musha68k,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-11-06T13:40:02Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-11-06T13:40:02Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HEART,2021-11-28T20:53:56Z,FredrikAleksander,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-12-02T10:22:23Z,mjgarton,NA https://github.com/rust-lang/rust/pull/88321,MERGED,2021-08-25T08:05:25Z,2021-09-20T10:17:12Z,Add initial support for m68k,glaubitz,db1fb85cff63ad5fffe435e17128f99f9e1d970c,18,Auto merge of #88321 - glaubitz:m68k-linux r=wesleywiser Add initial support for m68k This patch series adds initial support for m68k making use of the new M68k backend introduced with LLVM-13. Additional changes will be needed to be able to actually use the backend for this target.,HOORAY,2021-12-25T18:42:24Z,asdf2jkl,NA https://github.com/rust-lang/rust/pull/88325,MERGED,2021-08-25T12:14:03Z,2021-08-25T19:03:47Z,Add mutable-noalias to the release notes for 1.54,jyn514,d9ed23a9130b0941fd1ed4a651cbbec8a6621dd8,1,Rollup merge of #88325 - jyn514:noalias r=XAMPPRocky Add mutable-noalias to the release notes for 1.54 It was enabled in #82834 and disabled in 1.53 by #86036 but it was never disabled on (then) nightly so it still landed in 1.54. This was mentioned on https://github.com/rust-lang/rust/pull/86696 but never made it into the release notes. r? `@XAMPPRocky` cc `@nikic`,THUMBS_UP,2021-08-25T16:27:30Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88340,MERGED,2021-08-25T18:30:08Z,2021-08-27T03:48:03Z,Add `c_size_t` and `c_ssize_t` to `std::os::raw`.,thomcc,e760740c0371fed01b39a530fea5814945b8019f,1,"Rollup merge of #88340 - thomcc:c_size_t r=joshtriplett Add `c_size_t` and `c_ssize_t` to `std::os::raw`. Apparently these aren't guaranteed to be the same and are merely ""always the same in practice"" (see https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60). This is a big footgun but I suspect it can be alleviated if we expose this and start migrating people to it in advance of any platforms that ever have this as different. I'll file a tracking issue after this gets some traction.",THUMBS_DOWN,2021-09-23T08:26:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-26T10:18:42Z,taiki-e,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-26T10:55:35Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-26T11:18:54Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-26T15:56:30Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-26T16:20:57Z,jplatte,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-27T23:06:26Z,tech6hutch,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-08-28T19:49:59Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-09-01T14:06:02Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-09-03T06:27:27Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-09-03T22:11:24Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-09-09T12:19:07Z,tux3,NA https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-09-10T19:03:16Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88353,MERGED,2021-08-26T09:30:17Z,2021-10-04T10:09:17Z,Partially stabilize `array_methods`,jhpratt,70d82e0a6ebc5166ba6745743a0aceac5df1da7e,1,Rollup merge of #88353 - jhpratt:stabilize-array-as-ref r=joshtriplett Partially stabilize `array_methods` This stabilizes `<[T; N]>::as_slice` and `<[T; N]>::as_mut_slice` which is forms part of the `array_methods` feature: #76118. This also makes `<[T; N]>::as_slice` const due to its trivial nature.,HOORAY,2021-12-22T02:54:25Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-08-27T13:10:15Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-08-27T13:17:34Z,ren7995,NA https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-08-27T13:22:43Z,ivanloz,NA https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-11-23T20:47:37Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-12-08T18:32:23Z,ur0,u@umangis.me https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2021-12-18T16:20:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88354,MERGED,2021-08-26T09:48:24Z,2021-12-30T01:47:36Z,Add codegen option for branch protection and pointer authentication on AArch64,Jmc18134,d331cb710f0dd969d779510a49a3bafc7f78a54e,13,Auto merge of #88354 - Jmc18134:hint-space-pauth-opt r=nagisa Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.,HOORAY,2022-01-01T12:01:33Z,pwn0rz,NA https://github.com/rust-lang/rust/pull/88362,MERGED,2021-08-26T13:23:48Z,2021-09-06T18:42:06Z,Pin bootstrap checksums and add a tool to update it automatically,pietroalbini,8ceea01bb442b9746a51b062ce25abbf46d866b2,13,"Auto merge of #88362 - pietroalbini:bump-stage0 r=Mark-Simulacrum Pin bootstrap checksums and add a tool to update it automatically :warning: :warning: This is just a proactive hardening we're performing on the build system and it's not prompted by any known compromise. If you're aware of security issues being exploited please [check out our responsible disclosure page](https://www.rust-lang.org/policies/security). :warning: :warning: --- This PR aims to improve Rust's supply chain security by pinning the checksums of the bootstrap compiler downloaded by `x.py` preventing a compromised `static.rust-lang.org` from affecting building the compiler. The checksums are stored in `src/stage0.json` which replaces `src/stage0.txt`. This PR also adds a tool to automatically update the bootstrap compiler. The changes in this PR were originally discussed in [Zulip](https://zulip-archive.rust-lang.org/stream/241545-t-release/topic/pinning.20stage0.20hashes.html). ## Potential attack Before this PR an attacker who wanted to compromise the bootstrap compiler would ""just"" need to: 1. Gain write access to `static.rust-lang.org` either by compromising DNS or the underlying storage. 2. Upload compromised binaries and corresponding `.sha256` files to `static.rust-lang.org`. There is no signature verification in `x.py` as we don't want the build system to depend on GPG. Also since the checksums were not pinned inside the repository they were downloaded from `static.rust-lang.org` too: this only protected from accidental changes in `static.rust-lang.org` that didn't change the `*.sha256` files. The attack would allow the attacker to compromise past and future invocations of `x.py`. ## Mitigations introduced in this PR This PR adds pinned checksums for all the bootstrap components in `src/stage0.json` instead of downloading the checksums from `static.rust-lang.org`. This changes the attack scenario to: 1. Gain write access to `static.rust-lang.org` either by compromising DNS or the underlying storage. 2. Upload compromised binaries to `static.rust-lang.org`. 3. Land a (reviewed) change in the `rust-lang/rust` repository changing the pinned hashes. Even with a successful attack existing clones of the Rust repository won't be affected and once the attack is detected reverting the pinned hashes changes should be enough to be protected from the attack. This also enables further mitigations to be implemented in following PRs such as verifying signatures when pinning new checksums (removing the trust on first use aspect of this PR) and adding a check in CI making sure a PR updating the checksum has not been tampered with (see the future improvements section). ## Additional changes There are additional changes implemented in this PR to enable the mitigation: * The `src/stage0.txt` file has been replaced with `src/stage0.json`. The reasoning for the change is that there is existing tooling to read and manipulate JSON files compared to the custom format we were using before and the slight challenge of manually editing JSON files (no comments no trailing commas) are not a problem thanks to the new `bump-stage0`. * A new tool has been added to the repository `bump-stage0`. When invoked the tool automatically calculates which release should be used as the bootstrap compiler given the current version and channel gathers all the relevant checksums and updates `src/stage0.json`. The tool can be invoked by running: ``` ./x.py run src/tools/bump-stage0 ``` * Support for downloading releases from `https://dev-static.rust-lang.org` has been removed as it's not possible to verify checksums there (it's customary to replace existing artifacts there if a rebuild is warranted). This will require a change to the release process to avoid bumping the bootstrap compiler on beta before the stable release. ## Future improvements * Add signature verification as part of `bump-stage0` which would require the attacker to also obtain the release signing keys in order to successfully compromise the bootstrap compiler. This would be fine to add now as the burden of installing the tool to verify signatures would only be placed on whoever updates the bootstrap compiler instead of everyone compiling Rust. * Add a check on CI that ensures the checksums in `src/stage0.json` are the expected ones. If a PR changes the stage0 file CI should also run the `bump-stage0` tool and fail if the output in CI doesn't match the committed file. This prevents the PR author from tweaking the output of the tool manually which would otherwise be close to impossible for a human to detect. * Automate creating the PRs bumping the bootstrap compiler by setting up a scheduled job in GitHub Actions that runs the tool and opens a PR. * Investigate whether a similar mitigation can be done for ""download from CI"" components like the prebuilt LLVM. r? `@Mark-Simulacrum`",THUMBS_UP,2021-11-25T06:54:59Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/88369,MERGED,2021-08-26T19:17:42Z,2021-08-31T01:03:59Z,update const generics feature gates,lcnr,6f388bb369ddb6fb64e547009e031598425f773c,613,"Auto merge of #88369 - lcnr:cec-rename r=oli-obk update const generics feature gates **tl;dr: split const generics into three features: `adt_const_params` `const_generics_defaults` and `generic_const_exprs`** continuing the work of `@BoxyUwU` in #88324 this PR - renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`. - completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways. - moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag. - updates tests removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files. I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active. This ordering restriction feels like the only ""real"" use of the current `feature(const_generics)` right now so this change isn't a perfect solution but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future I think this is acceptable for now. --- cc `@rust-lang/project-const-generics` about the new feature names and this change in general. I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands so I don't want this merged yet. Apologies to whoever ends up reviewing this PR :sweat_smile: :heart: r? rust-lang/project-const-generics",LAUGH,2021-08-26T21:20:52Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/88369,MERGED,2021-08-26T19:17:42Z,2021-08-31T01:03:59Z,update const generics feature gates,lcnr,6f388bb369ddb6fb64e547009e031598425f773c,613,"Auto merge of #88369 - lcnr:cec-rename r=oli-obk update const generics feature gates **tl;dr: split const generics into three features: `adt_const_params` `const_generics_defaults` and `generic_const_exprs`** continuing the work of `@BoxyUwU` in #88324 this PR - renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`. - completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways. - moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag. - updates tests removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files. I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active. This ordering restriction feels like the only ""real"" use of the current `feature(const_generics)` right now so this change isn't a perfect solution but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future I think this is acceptable for now. --- cc `@rust-lang/project-const-generics` about the new feature names and this change in general. I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands so I don't want this merged yet. Apologies to whoever ends up reviewing this PR :sweat_smile: :heart: r? rust-lang/project-const-generics",LAUGH,2021-08-26T22:43:13Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/88369,MERGED,2021-08-26T19:17:42Z,2021-08-31T01:03:59Z,update const generics feature gates,lcnr,6f388bb369ddb6fb64e547009e031598425f773c,613,"Auto merge of #88369 - lcnr:cec-rename r=oli-obk update const generics feature gates **tl;dr: split const generics into three features: `adt_const_params` `const_generics_defaults` and `generic_const_exprs`** continuing the work of `@BoxyUwU` in #88324 this PR - renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`. - completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways. - moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag. - updates tests removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files. I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active. This ordering restriction feels like the only ""real"" use of the current `feature(const_generics)` right now so this change isn't a perfect solution but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future I think this is acceptable for now. --- cc `@rust-lang/project-const-generics` about the new feature names and this change in general. I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands so I don't want this merged yet. Apologies to whoever ends up reviewing this PR :sweat_smile: :heart: r? rust-lang/project-const-generics",LAUGH,2021-08-26T23:10:54Z,mati865,NA https://github.com/rust-lang/rust/pull/88387,MERGED,2021-08-27T11:54:24Z,2021-08-29T17:46:26Z,Remove vestigial rustfix tests.,ehuss,1a6e8d769aaeafbf814d9f37ff0a68618dcf2150,20,Rollup merge of #88387 - ehuss:remove-rustfix-tests r=Mark-Simulacrum Remove vestigial rustfix tests. The directory `src/test/rustfix` is not actually tested. It looks like a mistake was made when rustfix tests were originally introduced in #50084. In commit 6f2d023028bbd666be2c211b923b32faf10a41da they were moved to `src/test/ui` but the tests in the original directory weren't deleted.,HEART,2021-08-27T21:57:10Z,camelid,NA https://github.com/rust-lang/rust/pull/88391,MERGED,2021-08-27T13:00:07Z,2021-08-31T19:33:09Z,Fix json tuple struct enum variant ,GuillaumeGomez,f4f5dd518603efdf5783f9c434392c939ae9b821,8,Rollup merge of #88391 - GuillaumeGomez:fix-json-enum-variant r=camelid notriddle Fix json tuple struct enum variant Fixes #87887. cc `@dsherret` `@camelid` r? `@notriddle`,THUMBS_UP,2021-08-27T14:02:45Z,Urgau,NA https://github.com/rust-lang/rust/pull/88401,CLOSED,2021-08-27T19:04:41Z,2021-09-17T04:00:15Z,"Revert ""Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper""",richkadel,NA,NA,NA,CONFUSED,2021-08-27T20:52:39Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/88401,CLOSED,2021-08-27T19:04:41Z,2021-09-17T04:00:15Z,"Revert ""Auto merge of #80357 - c410-f3r:new-hir-let r=matthewjasper""",richkadel,NA,NA,NA,CONFUSED,2021-08-28T10:14:08Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/88407,MERGED,2021-08-27T21:30:18Z,2021-08-29T17:46:25Z,Fix formatting in release notes from 52a988344bce11,nebkor,9ffbd5029454425c012019aa7f06eb4f70bdf343,1,Rollup merge of #88407 - nebkor:release-note-1.55x2 r=Mark-Simulacrum Fix formatting in release notes from 52a988344bce11 I neglected to add a line that allowed the `[cargo/9663]` short-hand to resolve to an actual link in the rendered markdown on github.,HEART,2021-08-29T18:24:41Z,notnotdee,NA https://github.com/rust-lang/rust/pull/88412,MERGED,2021-08-28T00:43:10Z,2021-09-30T07:34:10Z,Remove ignore-tidy-undocumented-unsafe from core::slice::sort,mdsn,e24f52294a7dd1ffc9bebe92bde8102a45496f7b,1,Rollup merge of #88412 - mdsn:slice-sort-safety r=dtolnay Remove ignore-tidy-undocumented-unsafe from core::slice::sort Write down the missing safety arguments to be able to remove `ignore-tidy-undocumented-unsafe` from `core::slice::sort`. Helps with #66219 ``@rustbot`` label C-cleanup T-libs,HOORAY,2021-08-28T13:56:16Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88419,MERGED,2021-08-28T09:45:01Z,2021-08-29T17:46:25Z,Fix code blocks color in Ayu theme,GuillaumeGomez,26feefddc7f6834658ee9ff4671a7b99a040e60b,4,Rollup merge of #88419 - GuillaumeGomez:code-blocks-colors r=camelid notriddle Fix code blocks color in Ayu theme Fixes #88415. cc `@camelid` r? `@notriddle`,THUMBS_UP,2021-08-28T12:52:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88439,MERGED,2021-08-28T21:31:38Z,2021-12-04T09:05:43Z,Unwinding support for inline assembly,cynecx,887999d163bace7e79370b952bdd1f930ff4cdd5,55,Auto merge of #88439 - cynecx:unwind_asm r=Amanieu Unwinding support for inline assembly r? `@Amanieu`,EYES,2021-08-28T22:29:49Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88439,MERGED,2021-08-28T21:31:38Z,2021-12-04T09:05:43Z,Unwinding support for inline assembly,cynecx,887999d163bace7e79370b952bdd1f930ff4cdd5,55,Auto merge of #88439 - cynecx:unwind_asm r=Amanieu Unwinding support for inline assembly r? `@Amanieu`,EYES,2021-08-30T08:44:06Z,puckipedia,NA https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-09-03T07:17:04Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-09-11T04:34:14Z,cynecx,NA https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-10-19T13:51:07Z,ollpu,NA https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-10-21T22:14:39Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-10-23T08:00:49Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-11-03T15:17:12Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/88441,MERGED,2021-08-28T21:51:42Z,2021-11-06T04:15:28Z,Normalize obligations for closure confirmation,jackh726,18cae2680fff914c95a633c468f09b614f385844,17,Auto merge of #88441 - jackh726:closure_norm r=nikomatsakis Normalize obligations for closure confirmation Based on #90017 Fixes #74261 Fixes #71955 Fixes #88459 r? `@nikomatsakis`,HOORAY,2021-11-06T08:12:59Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-08-29T06:52:47Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-08-29T13:34:54Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-08-29T15:09:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-01T14:00:53Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-16T08:58:14Z,Virgiel,NA https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-16T17:41:24Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-16T22:28:48Z,tux3,NA https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-20T20:44:13Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/88448,MERGED,2021-08-29T00:26:42Z,2021-09-07T04:53:49Z,BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance,xu-cheng,ffaf857045f4f4d8bb563e0a5077f9b065f42916,5,Auto merge of #88448 - xu-cheng:btree-blk-build r=Mark-Simulacrum BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3 694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1 033 446 ns/iter (+/- 192 950) test btree::map::from_iter_seq_100 ... bench: 5 689 ns/iter (+/- 1 259) test btree::map::from_iter_seq_10_000 ... bench: 861 033 ns/iter (+/- 118 815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3 033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775 958 ns/iter (+/- 105 152) test btree::map::from_iter_seq_100 ... bench: 2 969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258 292 ns/iter (+/- 29 364) ```,HOORAY,2021-09-21T18:08:23Z,kageru,kageru@encode.moe https://github.com/rust-lang/rust/pull/88449,CLOSED,2021-08-29T00:36:31Z,2021-09-05T14:55:32Z,"Reapply ""cg_llvm: `fewer_names` in `uncached_llvm_type`""",erikdesjardins,NA,NA,NA,THUMBS_UP,2021-08-29T13:45:10Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-08-29T05:09:38Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-08-29T07:31:49Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-08-29T11:35:59Z,fmease,NA https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-08-29T15:04:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-08-30T09:45:47Z,CryZe,NA https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-09-01T13:59:56Z,iorveth,arsen.kondratiev@protonmail.com https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-09-04T22:40:08Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-09-08T20:45:54Z,panaman67,NA https://github.com/rust-lang/rust/pull/88452,MERGED,2021-08-29T02:53:42Z,2021-10-04T23:41:28Z,VecDeque: improve performance for From<[T; N]>,xu-cheng,19d9a147bef8dfaf5c718c0cb4008accd86e7a5e,3,Rollup merge of #88452 - xu-cheng:vecdeque-from-array r=m-ou-se VecDeque: improve performance for From<[T; N]> Create `VecDeque` directly from the array instead of inserting items one-by-one. Benchmark ``` ./x.py bench library/alloc --test-args vec_deque::bench_from_array_1000 ``` * Before ``` test vec_deque::bench_from_array_1000 ... bench: 3 991 ns/iter (+/- 717) ``` * After ``` test vec_deque::bench_from_array_1000 ... bench: 268 ns/iter (+/- 37) ```,HOORAY,2021-09-09T23:58:57Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/88466,MERGED,2021-08-29T19:38:18Z,2021-08-30T21:14:41Z,2229: Handle update to capture kind properly,arora-aman,5d6804469d80aaf26f98090ae016af45e267f58f,2,Auto merge of #88466 - sexxi-goose:issue-88372 r=nikomatsakis 2229: Handle update to capture kind properly Fixes: #88372 r? `@nikomatsakis`,HEART,2021-08-30T21:15:32Z,narpfel,NA https://github.com/rust-lang/rust/pull/88481,MERGED,2021-08-30T08:59:11Z,2021-10-04T10:09:17Z,Remove some feature gates,bjorn3,5215b855b0e4c84cbcaa3c7afa06f8e3d89f7ca8,11,Rollup merge of #88481 - bjorn3:remove_feature_gates r=cjgillot Remove some feature gates The first commit removes various feature gates that are unused. The second commit replaces some `Fn` implementations with `Iterator` implementations which is much cleaner IMO. The third commit replaces an unboxed_closures feature gate with min_specialization. For some reason the unboxed_closures feature gate suppresses the min_specialization feature gate from triggering on an `TrustedStep` impl. The last comment just turns a regular comment into a doc comment as drive by cleanup. I can move it to a separate PR if preferred.,HEART,2021-08-30T15:25:23Z,est31,NA https://github.com/rust-lang/rust/pull/88490,MERGED,2021-08-30T14:50:23Z,2021-09-02T00:12:25Z,Display associated types of implementors,GuillaumeGomez,767edcf61630ee05a19e2be9085a153750b4d102,7,"Auto merge of #88490 - GuillaumeGomez:associated-types-implementors-display r=camelid Manishearth Display associated types of implementors Fixes #86631. Contrary to before it doesn't display methods. I also had to ""resurrect"" the `auto-hide-trait-implementations` setting. :3 Only question at this point: should I move the `render_impl` boolean arguments into one struct? We're starting to have quite a lot of them... cc `@cynecx` r? `@camelid`",THUMBS_UP,2021-08-30T21:46:05Z,cynecx,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T18:26:32Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T19:21:32Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T19:30:37Z,lf-,software@lfcode.ca https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T19:38:50Z,teej,teej.murphy@gmail.com https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T19:40:44Z,kupiakos,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-30T19:41:18Z,benbrittain,ben@brittain.org https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-31T07:01:30Z,vorner,vorner+github@vorner.cz https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-31T08:22:25Z,daira,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-31T12:55:13Z,expectocode,expectocode@gmail.com https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-08-31T16:07:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-09-02T03:47:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-09-18T14:30:14Z,MinusGix,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-10-05T05:16:47Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-10-05T20:04:40Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/88500,CLOSED,2021-08-30T18:25:35Z,2021-12-12T02:57:06Z,Rewrite `Pin

` docs to clarify guarantees and uses,mcy,NA,NA,NA,HEART,2021-11-14T20:33:40Z,RalfJung,NA https://github.com/rust-lang/rust/pull/88502,MERGED,2021-08-30T18:52:13Z,2021-12-01T23:22:54Z,Add slice take methods,ibraheemdev,9f1f42897d0e0ae580f2e49a1b46fad27b60990e,5,Rollup merge of #88502 - ibraheemdev:slice-take r=dtolnay Add slice take methods Revival of #62282 This PR adds the following slice methods: - `take` - `take_mut` - `take_first` - `take_first_mut` - `take_last` - `take_last_mut` r? `@LukasKalbertodt`,THUMBS_UP,2021-12-09T08:14:34Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/88502,MERGED,2021-08-30T18:52:13Z,2021-12-01T23:22:54Z,Add slice take methods,ibraheemdev,9f1f42897d0e0ae580f2e49a1b46fad27b60990e,5,Rollup merge of #88502 - ibraheemdev:slice-take r=dtolnay Add slice take methods Revival of #62282 This PR adds the following slice methods: - `take` - `take_mut` - `take_first` - `take_first_mut` - `take_last` - `take_last_mut` r? `@LukasKalbertodt`,THUMBS_UP,2021-12-10T02:48:32Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/88502,MERGED,2021-08-30T18:52:13Z,2021-12-01T23:22:54Z,Add slice take methods,ibraheemdev,9f1f42897d0e0ae580f2e49a1b46fad27b60990e,5,Rollup merge of #88502 - ibraheemdev:slice-take r=dtolnay Add slice take methods Revival of #62282 This PR adds the following slice methods: - `take` - `take_mut` - `take_first` - `take_first_mut` - `take_last` - `take_last_mut` r? `@LukasKalbertodt`,THUMBS_UP,2022-04-11T09:48:06Z,jamen,me@jamen.dev https://github.com/rust-lang/rust/pull/88528,CLOSED,2021-08-31T09:00:57Z,2021-09-01T16:29:25Z,Update cargo to stabilize Rust 2021.,m-ou-se,NA,NA,NA,ROCKET,2021-08-31T21:58:37Z,scrabsha,NA https://github.com/rust-lang/rust/pull/88546,MERGED,2021-08-31T21:27:14Z,2021-09-11T06:30:45Z,Emit proper errors when on missing closure braces,scrabsha,dc003dd49e5599a0de22653d6bd4aaa8d460234e,7,Rollup merge of #88546 - scrabsha:scrabsha/closure-missing-braces r=estebank Emit proper errors when on missing closure braces This commit focuses on emitting clean errors for the following syntax error: ``` Some(42).map(|a| dbg!(a); a ); ``` Previous implementation tried to recover after parsing the closure body (the `dbg` expression) by replacing the next `;` with a ` ` which made the next expression belong to the next function argument. As such the following errors were emitted (among others): - the semicolon token was not expected - a is not in scope - Option::map is supposed to take one argument not two. This commit allows us to gracefully handle this situation by adding giving the parser the ability to remember when it has just parsed a closure body inside a function call. When this happens we can treat the unexpected `;` specifically and try to parse as much statements as possible in order to eat the whole block. When we can't parse statements anymore we generate a clean error indicating that the braces are missing and return an ExprKind::Err. Closes #88065. r? `@estebank`,HOORAY,2021-09-01T00:05:44Z,chapeupreto,rodiney@gmail.com https://github.com/rust-lang/rust/pull/88546,MERGED,2021-08-31T21:27:14Z,2021-09-11T06:30:45Z,Emit proper errors when on missing closure braces,scrabsha,dc003dd49e5599a0de22653d6bd4aaa8d460234e,7,Rollup merge of #88546 - scrabsha:scrabsha/closure-missing-braces r=estebank Emit proper errors when on missing closure braces This commit focuses on emitting clean errors for the following syntax error: ``` Some(42).map(|a| dbg!(a); a ); ``` Previous implementation tried to recover after parsing the closure body (the `dbg` expression) by replacing the next `;` with a ` ` which made the next expression belong to the next function argument. As such the following errors were emitted (among others): - the semicolon token was not expected - a is not in scope - Option::map is supposed to take one argument not two. This commit allows us to gracefully handle this situation by adding giving the parser the ability to remember when it has just parsed a closure body inside a function call. When this happens we can treat the unexpected `;` specifically and try to parse as much statements as possible in order to eat the whole block. When we can't parse statements anymore we generate a clean error indicating that the braces are missing and return an ExprKind::Err. Closes #88065. r? `@estebank`,HOORAY,2021-09-11T06:37:33Z,edmorley,NA https://github.com/rust-lang/rust/pull/88546,MERGED,2021-08-31T21:27:14Z,2021-09-11T06:30:45Z,Emit proper errors when on missing closure braces,scrabsha,dc003dd49e5599a0de22653d6bd4aaa8d460234e,7,Rollup merge of #88546 - scrabsha:scrabsha/closure-missing-braces r=estebank Emit proper errors when on missing closure braces This commit focuses on emitting clean errors for the following syntax error: ``` Some(42).map(|a| dbg!(a); a ); ``` Previous implementation tried to recover after parsing the closure body (the `dbg` expression) by replacing the next `;` with a ` ` which made the next expression belong to the next function argument. As such the following errors were emitted (among others): - the semicolon token was not expected - a is not in scope - Option::map is supposed to take one argument not two. This commit allows us to gracefully handle this situation by adding giving the parser the ability to remember when it has just parsed a closure body inside a function call. When this happens we can treat the unexpected `;` specifically and try to parse as much statements as possible in order to eat the whole block. When we can't parse statements anymore we generate a clean error indicating that the braces are missing and return an ExprKind::Err. Closes #88065. r? `@estebank`,HEART,2021-09-11T22:52:17Z,schneems,richard.schneeman+no-recruiters@gmail.com https://github.com/rust-lang/rust/pull/88546,MERGED,2021-08-31T21:27:14Z,2021-09-11T06:30:45Z,Emit proper errors when on missing closure braces,scrabsha,dc003dd49e5599a0de22653d6bd4aaa8d460234e,7,Rollup merge of #88546 - scrabsha:scrabsha/closure-missing-braces r=estebank Emit proper errors when on missing closure braces This commit focuses on emitting clean errors for the following syntax error: ``` Some(42).map(|a| dbg!(a); a ); ``` Previous implementation tried to recover after parsing the closure body (the `dbg` expression) by replacing the next `;` with a ` ` which made the next expression belong to the next function argument. As such the following errors were emitted (among others): - the semicolon token was not expected - a is not in scope - Option::map is supposed to take one argument not two. This commit allows us to gracefully handle this situation by adding giving the parser the ability to remember when it has just parsed a closure body inside a function call. When this happens we can treat the unexpected `;` specifically and try to parse as much statements as possible in order to eat the whole block. When we can't parse statements anymore we generate a clean error indicating that the braces are missing and return an ExprKind::Err. Closes #88065. r? `@estebank`,HEART,2021-09-20T11:18:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T00:12:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HEART,2021-09-01T00:12:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T00:50:12Z,camelid,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T02:19:10Z,taiki-e,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HEART,2021-09-01T05:41:56Z,darksv,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T05:41:56Z,darksv,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,THUMBS_UP,2021-09-01T12:24:54Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T12:54:00Z,aznhe21,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-01T14:11:35Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HEART,2021-09-09T16:28:30Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,THUMBS_UP,2021-09-09T18:12:11Z,SnejUgal,contact@snejugal.ru https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HEART,2021-09-10T06:37:38Z,camsteffen,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HEART,2021-09-10T10:33:55Z,MartinKavik,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-10T18:32:53Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,HOORAY,2021-09-11T01:18:30Z,lopopolo,NA https://github.com/rust-lang/rust/pull/88548,MERGED,2021-08-31T21:53:36Z,2021-09-01T11:47:22Z,Stabilize `Iterator::intersperse()`,inquisitivecrystal,f436b6d0a714cca5629f49a547622955da09afd9,6,Rollup merge of #88548 - inquisitivecrystal:intersperse r=m-ou-se Stabilize `Iterator::intersperse()` This PR stabilizes the methods `Iterator::intersperse()` and `Iterator::intersperse_with()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/79524#issuecomment-909663616). Closes #79524.,THUMBS_UP,2021-10-09T17:02:26Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88552,MERGED,2021-09-01T01:47:46Z,2021-09-05T21:40:33Z,Stop allocating vtable entries for non-object-safe methods,nbdd0121,e30b68353fe22b00f40d021e7914eeb78473b3c1,8,Auto merge of #88552 - nbdd0121:vtable r=nagisa Stop allocating vtable entries for non-object-safe methods Current a vtable entry is allocated for all associated fns even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T As a result each vtable for `Iterator`' currently consumes 74 `usize`s. This PR stops allocating vtable entries for those methods reducing vtable size of each `Iterator` vtable to 7 `usize`s. Note that this PR introduces will cause more invocations of `is_vtable_safe_method`. So a perf run might be needed. If result isn't favorable then we might need to query-ify `is_vtable_safe_method`.,HOORAY,2021-09-01T17:09:35Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88552,MERGED,2021-09-01T01:47:46Z,2021-09-05T21:40:33Z,Stop allocating vtable entries for non-object-safe methods,nbdd0121,e30b68353fe22b00f40d021e7914eeb78473b3c1,8,Auto merge of #88552 - nbdd0121:vtable r=nagisa Stop allocating vtable entries for non-object-safe methods Current a vtable entry is allocated for all associated fns even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T As a result each vtable for `Iterator`' currently consumes 74 `usize`s. This PR stops allocating vtable entries for those methods reducing vtable size of each `Iterator` vtable to 7 `usize`s. Note that this PR introduces will cause more invocations of `is_vtable_safe_method`. So a perf run might be needed. If result isn't favorable then we might need to query-ify `is_vtable_safe_method`.,HOORAY,2021-09-01T17:34:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88552,MERGED,2021-09-01T01:47:46Z,2021-09-05T21:40:33Z,Stop allocating vtable entries for non-object-safe methods,nbdd0121,e30b68353fe22b00f40d021e7914eeb78473b3c1,8,Auto merge of #88552 - nbdd0121:vtable r=nagisa Stop allocating vtable entries for non-object-safe methods Current a vtable entry is allocated for all associated fns even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T As a result each vtable for `Iterator`' currently consumes 74 `usize`s. This PR stops allocating vtable entries for those methods reducing vtable size of each `Iterator` vtable to 7 `usize`s. Note that this PR introduces will cause more invocations of `is_vtable_safe_method`. So a perf run might be needed. If result isn't favorable then we might need to query-ify `is_vtable_safe_method`.,HOORAY,2021-09-02T15:59:54Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/88552,MERGED,2021-09-01T01:47:46Z,2021-09-05T21:40:33Z,Stop allocating vtable entries for non-object-safe methods,nbdd0121,e30b68353fe22b00f40d021e7914eeb78473b3c1,8,Auto merge of #88552 - nbdd0121:vtable r=nagisa Stop allocating vtable entries for non-object-safe methods Current a vtable entry is allocated for all associated fns even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T As a result each vtable for `Iterator`' currently consumes 74 `usize`s. This PR stops allocating vtable entries for those methods reducing vtable size of each `Iterator` vtable to 7 `usize`s. Note that this PR introduces will cause more invocations of `is_vtable_safe_method`. So a perf run might be needed. If result isn't favorable then we might need to query-ify `is_vtable_safe_method`.,HOORAY,2021-09-03T19:24:00Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/88553,MERGED,2021-09-01T03:16:23Z,2021-09-08T20:42:47Z,Improve diagnostics for unary plus operators (#88276),theo-lw,77ac329a08b50090c9ac387f3d24ddc46bced92e,9,Rollup merge of #88553 - theo-lw:issue-88276 r=estebank Improve diagnostics for unary plus operators (#88276) This pull request improves the diagnostics emitted on parsing a unary plus operator. See #88276. Before: ``` error: expected expression found `+` --> src/main.rs:2:13 | 2 | let x = +1; | ^ expected expression ``` After: ``` error: leading `+` is not supported --> main.rs:2:13 | 2 | let x = +1; | ^ | | | unexpected `+` | help: try removing the `+` ```,THUMBS_UP,2021-09-01T06:40:20Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/88553,MERGED,2021-09-01T03:16:23Z,2021-09-08T20:42:47Z,Improve diagnostics for unary plus operators (#88276),theo-lw,77ac329a08b50090c9ac387f3d24ddc46bced92e,9,Rollup merge of #88553 - theo-lw:issue-88276 r=estebank Improve diagnostics for unary plus operators (#88276) This pull request improves the diagnostics emitted on parsing a unary plus operator. See #88276. Before: ``` error: expected expression found `+` --> src/main.rs:2:13 | 2 | let x = +1; | ^ expected expression ``` After: ``` error: leading `+` is not supported --> main.rs:2:13 | 2 | let x = +1; | ^ | | | unexpected `+` | help: try removing the `+` ```,THUMBS_UP,2021-09-01T17:41:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88553,MERGED,2021-09-01T03:16:23Z,2021-09-08T20:42:47Z,Improve diagnostics for unary plus operators (#88276),theo-lw,77ac329a08b50090c9ac387f3d24ddc46bced92e,9,Rollup merge of #88553 - theo-lw:issue-88276 r=estebank Improve diagnostics for unary plus operators (#88276) This pull request improves the diagnostics emitted on parsing a unary plus operator. See #88276. Before: ``` error: expected expression found `+` --> src/main.rs:2:13 | 2 | let x = +1; | ^ expected expression ``` After: ``` error: leading `+` is not supported --> main.rs:2:13 | 2 | let x = +1; | ^ | | | unexpected `+` | help: try removing the `+` ```,THUMBS_UP,2021-09-07T04:02:34Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/88558,MERGED,2021-09-01T12:06:40Z,2021-09-15T06:54:56Z,Const drop,fee1-dead,cdeba02ff71416e014f7130f75166890688be986,26,Auto merge of #88558 - fee1-dead:const-drop r=oli-obk Const drop The changes are pretty primitive at this point. But at least it works. ^-^ Problems with the current change that I can think of now: - [x] `~const Drop` shouldn't change anything in the non-const world. - [x] types that do not have drop glues shouldn't fail to satisfy `~const Drop` in const contexts. `struct S { a: u8 b: u16 }` This might not fail for `needs_non_const_drop` but it will fail in `rustc_trait_selection`. - [x] The current change accepts types that have `const Drop` impls but have non-const `Drop` glue. Fixes #88424. Significant Changes: - `~const Drop` is no longer treated as a normal trait bound. In non-const contexts this bound has no effect but in const contexts this restricts the input type and all of its transitive fields to either a) have a `const Drop` impl or b) can be trivially dropped (i.e. no drop glue) - `T: ~const Drop` will not be linted like `T: Drop`. - Instead of recursing and iterating through the type in `rustc_mir::transform::check_consts` we use the trait system to special case `~const Drop`. See [`rustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates`](https://github.com/fee1-dead/rust/blob/const-drop/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L817) and others. Changes not related to `const Drop`ping and/or changes that are insignificant: - `Node.constness_for_typeck` no longer returns `hir::Constness::Const` for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in it is no longer needed. - Removed `is_const_impl_raw` query. We have `impl_constness` and the only existing use of that query uses `HirId` which means we can just operate it with hir. - `ty::Destructor` now has a field `constness` which represents the constness of the destructor. r? `@oli-obk`,HOORAY,2021-09-24T18:59:41Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88558,MERGED,2021-09-01T12:06:40Z,2021-09-15T06:54:56Z,Const drop,fee1-dead,cdeba02ff71416e014f7130f75166890688be986,26,Auto merge of #88558 - fee1-dead:const-drop r=oli-obk Const drop The changes are pretty primitive at this point. But at least it works. ^-^ Problems with the current change that I can think of now: - [x] `~const Drop` shouldn't change anything in the non-const world. - [x] types that do not have drop glues shouldn't fail to satisfy `~const Drop` in const contexts. `struct S { a: u8 b: u16 }` This might not fail for `needs_non_const_drop` but it will fail in `rustc_trait_selection`. - [x] The current change accepts types that have `const Drop` impls but have non-const `Drop` glue. Fixes #88424. Significant Changes: - `~const Drop` is no longer treated as a normal trait bound. In non-const contexts this bound has no effect but in const contexts this restricts the input type and all of its transitive fields to either a) have a `const Drop` impl or b) can be trivially dropped (i.e. no drop glue) - `T: ~const Drop` will not be linted like `T: Drop`. - Instead of recursing and iterating through the type in `rustc_mir::transform::check_consts` we use the trait system to special case `~const Drop`. See [`rustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates`](https://github.com/fee1-dead/rust/blob/const-drop/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L817) and others. Changes not related to `const Drop`ping and/or changes that are insignificant: - `Node.constness_for_typeck` no longer returns `hir::Constness::Const` for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in it is no longer needed. - Removed `is_const_impl_raw` query. We have `impl_constness` and the only existing use of that query uses `HirId` which means we can just operate it with hir. - `ty::Destructor` now has a field `constness` which represents the constness of the destructor. r? `@oli-obk`,HOORAY,2021-09-25T22:11:57Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/88565,MERGED,2021-09-01T16:37:47Z,2021-09-02T21:27:03Z,Add regression test for issue 83190,lqd,e248c4d5d0459fbf2a796e5bb413adca37d37b16,1,Rollup merge of #88565 - lqd:issue-83190 r=spastorino Add regression test for issue 83190 Reduced from `bioyino-metric` by ````@hellow554```` and myself. Closes #83190. r? ````@spastorino````,THUMBS_UP,2021-09-01T17:19:58Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-01T22:05:11Z,camsteffen,NA https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-01T22:25:12Z,tmandry,NA https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-02T00:02:54Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-02T07:23:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-02T10:12:55Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-02T14:25:02Z,estebank,NA https://github.com/rust-lang/rust/pull/88572,MERGED,2021-09-01T21:55:28Z,2021-09-03T23:12:36Z,Fix drop handling for `if let` expressions,matthewjasper,b7404c898a1a6933b71c72428a6dce551bcc1be7,62,Auto merge of #88572 - matthewjasper:if-let-scoping-fix r=oli-obk Fix drop handling for `if let` expressions MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables. Closes #88307 cc `@flip1995` `@richkadel` `@c410-f3r`,HEART,2021-09-03T23:38:48Z,camelid,NA https://github.com/rust-lang/rust/pull/88575,MERGED,2021-09-01T23:16:00Z,2021-09-20T00:10:12Z,Querify `FnAbi::of_{fn_ptr instance}` as `fn_abi_of_{fn_ptr instance}`.,eddyb,91198820d7e697def79177c022b5e98b3d482ddc,23,"Auto merge of #88575 - eddyb:fn-abi-queries r=nagisa Querify `FnAbi::of_{fn_ptr instance}` as `fn_abi_of_{fn_ptr instance}`. *Note: opening this PR as draft because it's based on #88499* This more or less replicates the `LayoutOf::layout_of` setup from #88499 to replace `FnAbi::of_{fn_ptr instance}` with `FnAbiOf::fn_abi_of_{fn_ptr instance}` and also route them through queries (which `layout_of` has used for a while). The two changes at the use sites (other than the names) are: * return type is now wrapped in `&'tcx` * the value *is* interned which may affect performance * the `extra_args` list is now an interned `&'tcx ty::List>` * should be cheap (it's empty for anything other than C variadics) Theoretically a `FnAbiOfHelpers` implementer could choose to keep the `Result<...>` instead of eagerly erroring but the only existing users of these APIs are codegen backends so they don't (want to) take advantage of this. At least miri could make use of this since it prefers propagating errors (it ""just"" doesn't use `FnAbi` yet - cc `@RalfJung).` The way this is done is probably less efficient than what is possible because the queries handle the correctness-oriented API (i.e. the split into `fn` pointers vs instances) whereas a lower-level query could end up with more reuse between different instances with identical signatures. r? `@nagisa` cc `@oli-obk` `@bjorn3`",THUMBS_UP,2021-09-14T19:20:01Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/88588,CLOSED,2021-09-02T10:46:09Z,2022-03-09T21:18:54Z,Make feature key optional for rustc_stable rustc_const_stable attributes,jplatte,NA,NA,NA,THUMBS_UP,2021-09-02T12:42:10Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/88589,MERGED,2021-09-02T13:04:15Z,2021-09-02T21:27:03Z,Correct doc comments inside `use_expr_visitor.rs`,xFrednet,8f88d44b0dbeefb7e5683cfcee38763427e9cb03,1,Rollup merge of #88589 - xFrednet:00000-correct-comment-to-doc r=petrochenkov Correct doc comments inside `use_expr_visitor.rs` Just a simple update. I haven't changed any content inside the comments as they still seem correct. Have a wonderful rest of the day :upside_down_face:,THUMBS_UP,2021-09-02T13:42:44Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/88601,MERGED,2021-09-02T20:02:57Z,2021-11-16T05:19:07Z,Implement `Termination` for `Result`,ibraheemdev,c44455af1de0e8775660ae95538a967f9c8af4ce,1,Rollup merge of #88601 - ibraheemdev:termination-result-infallible r=yaahc Implement `Termination` for `Result` As noted in #43301 `Result` is not usable on stable.,THUMBS_UP,2021-09-03T08:04:34Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/88601,MERGED,2021-09-02T20:02:57Z,2021-11-16T05:19:07Z,Implement `Termination` for `Result`,ibraheemdev,c44455af1de0e8775660ae95538a967f9c8af4ce,1,Rollup merge of #88601 - ibraheemdev:termination-result-infallible r=yaahc Implement `Termination` for `Result` As noted in #43301 `Result` is not usable on stable.,THUMBS_UP,2021-09-03T16:07:09Z,DrMeepster,NA https://github.com/rust-lang/rust/pull/88601,MERGED,2021-09-02T20:02:57Z,2021-11-16T05:19:07Z,Implement `Termination` for `Result`,ibraheemdev,c44455af1de0e8775660ae95538a967f9c8af4ce,1,Rollup merge of #88601 - ibraheemdev:termination-result-infallible r=yaahc Implement `Termination` for `Result` As noted in #43301 `Result` is not usable on stable.,THUMBS_UP,2021-10-28T06:11:03Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88601,MERGED,2021-09-02T20:02:57Z,2021-11-16T05:19:07Z,Implement `Termination` for `Result`,ibraheemdev,c44455af1de0e8775660ae95538a967f9c8af4ce,1,Rollup merge of #88601 - ibraheemdev:termination-result-infallible r=yaahc Implement `Termination` for `Result` As noted in #43301 `Result` is not usable on stable.,HEART,2021-12-02T15:22:00Z,fenhl,fenhl@fenhl.net https://github.com/rust-lang/rust/pull/88624,MERGED,2021-09-03T21:10:51Z,2021-10-22T17:32:26Z,Stabilize feature `saturating_div` for rust 1.58.0,kellerkindt,918f9cc88bf71db79067af325ca00d8cba7309b6,4,Rollup merge of #88624 - kellerkindt:master r=JohnTitor Stabilize feature `saturating_div` for rust 1.58.0 The tracking issue is #89381 This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](https://github.com/rust-lang/rust/pull/87921#issuecomment-899357720) and [here](https://github.com/rust-lang/rust/pull/87921#discussion_r691888556). It extends the list of saturating operations on integer types (like `saturating_add` `saturating_sub` `saturating_mul` ...) by the function `fn saturating_div(self rhs: Self) -> Self`. The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first. Closes #89381,HEART,2021-10-28T06:04:11Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88624,MERGED,2021-09-03T21:10:51Z,2021-10-22T17:32:26Z,Stabilize feature `saturating_div` for rust 1.58.0,kellerkindt,918f9cc88bf71db79067af325ca00d8cba7309b6,4,Rollup merge of #88624 - kellerkindt:master r=JohnTitor Stabilize feature `saturating_div` for rust 1.58.0 The tracking issue is #89381 This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](https://github.com/rust-lang/rust/pull/87921#issuecomment-899357720) and [here](https://github.com/rust-lang/rust/pull/87921#discussion_r691888556). It extends the list of saturating operations on integer types (like `saturating_add` `saturating_sub` `saturating_mul` ...) by the function `fn saturating_div(self rhs: Self) -> Self`. The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first. Closes #89381,THUMBS_UP,2021-10-28T23:54:14Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T13:06:59Z,Urgau,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T13:42:48Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T14:21:10Z,bluss,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T14:28:23Z,camsteffen,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T14:31:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T14:31:29Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T14:32:57Z,leeola,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T14:33:00Z,leeola,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T14:39:42Z,arbitrix,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T14:41:57Z,PikminGuts92,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T14:41:57Z,PikminGuts92,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:05:52Z,EusebioDM,eusebioDM98@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:05:54Z,EusebioDM,eusebioDM98@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:13:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:13:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:20:34Z,voidc,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:20:54Z,IWANABETHATGUY,iwanabethatguy@qq.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:22:16Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:22:16Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:26:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T15:31:37Z,multimeric,michael.r.milton@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:44:21Z,mccolljr,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:44:21Z,mccolljr,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T15:44:22Z,mccolljr,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T15:47:09Z,Waridley,waridley64@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T15:57:20Z,Eraden,adrian.wozniak@ita-prog.pl https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T16:03:01Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T16:03:04Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T16:14:10Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T16:14:11Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T16:14:12Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T16:19:45Z,DesmondWillowbrook,sendtokartavya@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T16:44:48Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T16:50:40Z,Imxset21,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:04:47Z,agluszak,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T17:09:51Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:09:51Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:09:52Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:10:11Z,atcol,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:33:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:33:18Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:40:59Z,cynecx,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:44:40Z,chaichontat,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:44:41Z,chaichontat,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T17:49:35Z,MQuy,mholdb@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:49:36Z,MQuy,mholdb@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T17:54:20Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T18:23:47Z,kennytm,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T18:24:13Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T18:24:13Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T18:26:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T18:26:13Z,DianaNites,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T18:35:00Z,ZippyMagician,zippymagician1@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T18:48:50Z,ArifRoktim,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T19:00:52Z,ClementTsang,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T19:04:37Z,ClementTsang,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T19:06:20Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T19:19:39Z,abreis,andre@brg.rs https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T19:50:17Z,tuguzT,timurka.tugushev@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T19:50:19Z,tuguzT,timurka.tugushev@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T19:58:31Z,foodornt,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-04T19:58:31Z,foodornt,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T19:58:32Z,foodornt,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T20:03:38Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T20:03:41Z,SphericalKat,amolele@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-04T20:17:03Z,iwahbe,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T20:32:47Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T20:52:20Z,dlight,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T21:20:45Z,2deth,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T21:38:40Z,bee-san,github@skerritt.blog https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T21:53:59Z,timClicks,paperless@timmcnamara.co.nz https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T21:54:56Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T21:54:56Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T22:11:53Z,jplatte,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T22:30:26Z,seanpianka,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T22:30:30Z,seanpianka,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-04T23:32:51Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-04T23:37:07Z,zeramorphic,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T00:24:32Z,jakelogemann,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T00:52:58Z,yerke,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T00:52:58Z,yerke,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T01:19:34Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T01:42:38Z,camelid,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T01:42:38Z,camelid,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-05T02:12:57Z,adante111,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-05T02:12:58Z,adante111,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T02:13:01Z,adante111,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T02:20:30Z,Geometrically,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T02:32:41Z,phrohdoh,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T03:31:59Z,slessans,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T03:32:00Z,slessans,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T03:47:25Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T03:47:26Z,pineapplehunter,peshogo+github.com@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T04:47:36Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T04:47:36Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-05T04:47:38Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T06:00:45Z,cegredev,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T06:47:01Z,hcsch,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T09:56:34Z,harrier-lcc,mmu20046f03@yahoo.com.hk https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-05T11:12:41Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T11:12:43Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T11:12:44Z,Mubelotix,mubelotix@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-05T12:07:47Z,flosse,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T12:07:49Z,flosse,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T12:07:50Z,flosse,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-05T12:18:21Z,tema3210,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-05T12:18:23Z,tema3210,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T12:18:23Z,tema3210,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-05T12:18:24Z,tema3210,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T15:59:20Z,stuhood,stuhood@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-05T16:08:25Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T00:46:46Z,arucil,xplzjwz@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T06:56:39Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T07:25:18Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T07:25:19Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T09:35:24Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T09:35:26Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T09:35:27Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T10:05:31Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T11:01:32Z,silvioprog,silvioprog@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-06T11:01:33Z,silvioprog,silvioprog@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T11:01:34Z,silvioprog,silvioprog@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T11:01:35Z,silvioprog,silvioprog@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T12:54:54Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T12:54:55Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T12:54:56Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T13:49:34Z,hrkz,hugo.frezat@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T14:00:05Z,tifennf,tifenn.fl@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T14:00:06Z,tifennf,tifenn.fl@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T14:00:08Z,tifennf,tifenn.fl@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-06T14:00:09Z,tifennf,tifenn.fl@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T17:08:02Z,alecdotninja,hello@alec.ninja https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-06T17:08:06Z,alecdotninja,hello@alec.ninja https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-06T17:11:26Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-06T17:11:27Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-07T02:45:41Z,Eucladia,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-07T09:33:43Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-09-07T09:33:44Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-07T09:33:44Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-07T09:33:45Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-07T12:36:53Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-07T16:04:55Z,3131CuNb,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-08T21:23:17Z,cdmistman,colton@donn.io https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-10T06:55:37Z,Rafferty97,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-10T06:55:39Z,Rafferty97,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-10T09:01:46Z,akavel,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-10T09:01:48Z,akavel,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-10T13:14:33Z,leo60228,leo@60228.dev https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-12T01:17:07Z,jenanwise,jenan@jenanwise.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-12T01:17:12Z,jenanwise,jenan@jenanwise.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-09-20T23:41:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-09-25T20:01:23Z,Rengyr,mail@rengyr.eu https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-09-25T20:01:26Z,Rengyr,mail@rengyr.eu https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-10-04T12:05:46Z,roosephu,roosephu@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-10-16T13:48:43Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2021-10-24T13:33:24Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-10-24T13:33:25Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-10-24T13:33:27Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-10-24T13:33:29Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-10-28T07:56:48Z,pppKin,leoihungkin@outlook.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-11-14T19:12:15Z,ishantheperson,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-11-15T02:04:34Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-11-17T00:18:22Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2021-11-17T00:18:23Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-11-17T00:18:24Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-11-25T17:09:39Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2021-12-05T11:23:33Z,oowekyala,clement.fournier76@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2021-12-22T13:10:46Z,jackos,jackclayto@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-01-02T23:22:28Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2022-01-07T11:52:17Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2022-01-16T20:36:18Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-01-16T20:36:19Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-01-16T20:36:20Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-01-19T00:23:02Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-01-19T18:41:36Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-01-19T18:41:36Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2022-01-19T19:09:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2022-01-20T05:07:28Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-01-21T01:15:30Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-01-23T23:46:00Z,as-com,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-01-27T02:59:36Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,THUMBS_UP,2022-02-01T03:54:25Z,gustav3d,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,LAUGH,2022-02-03T18:27:45Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-02-03T18:27:46Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-02-11T21:21:30Z,nilehmann,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HEART,2022-02-11T21:21:31Z,nilehmann,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-02-28T13:03:40Z,tronta,NA https://github.com/rust-lang/rust/pull/88642,MERGED,2021-09-04T13:01:25Z,2022-01-19T18:18:25Z,Formally implement let chains,c410-f3r,5d2928f7b9eaea9c00ed7695143c0f71c5f53786,31,Rollup merge of #88642 - c410-f3r:let_chains_2 r=matthewjasper Formally implement let chains ## Let chains My longest and hardest contribution since #64010. Thanks to `@Centril` for creating the RFC and special thanks to `@matthewjasper` for helping me since the beginning of this journey. In fact `@matthewjasper` did much of the complicated MIR stuff so it's true to say that this feature wouldn't be possible without him. Thanks again `@matthewjasper!` With the changes proposed in this PR it will be possible to chain let expressions along side local variable declarations or ordinary conditional expressions. In other words do much of what the `if_chain` crate already does. ## Other considerations * `if let guard` and `let ... else` features need special care and should be handled in a following PR. * Irrefutable patterns are allowed within a let chain context * ~~Three Clippy lints were already converted to start dogfooding and help detect possible corner cases~~ cc #53667,HOORAY,2022-04-13T19:41:41Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/88644,MERGED,2021-09-04T15:54:35Z,2021-10-21T10:59:27Z,`AbstractConst` private fields,eopb,6f0acbcbd064d924afb0f3a04480fd0d69c5bc51,3,Rollup merge of #88644 - eopb:abstractconst_leaf_subst r=lcnr `AbstractConst` private fields Calls `subst` in `AbstractConst::root` when `Node` is `Leaf`. r? ``@lcnr``,HEART,2021-09-06T15:13:45Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-07T14:32:05Z,glommer,glommer@gmail.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-08T00:59:09Z,HippoBaro,hippolyte.barraud@gmail.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-08T15:14:50Z,duarten,duarte@fastmail.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-12T16:10:01Z,lbernail,laurent.bernaille@gmail.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-15T18:22:13Z,dmarriner,NA https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-15T18:42:01Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/88652,MERGED,2021-09-04T20:38:41Z,2021-10-17T12:27:55Z,linux/aarch64 Now() should be actually_monotonic(),AGSaidi,1d6f24210c4a8f46f9781a56f819a383e590cccf,2,Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281 #56940) which cause time to not monotonically increase these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.,HEART,2021-09-15T19:20:44Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/88666,MERGED,2021-09-05T15:25:59Z,2021-09-17T18:48:36Z,Improve build command for compiler docs,GuillaumeGomez,765f1533db10a7d31b9d61d1618bf0a199d41562,1,Rollup merge of #88666 - GuillaumeGomez:compiler-docs r=Mark-Simulacrum Improve build command for compiler docs It was rather complicated to document rustc crates. With this you can directly run: ```console x.py doc compiler x.py doc compiler/rustc_hir_pretty ``` The second commit adds the handling of the `--open` flag. r? `@Mark-Simulacrum`,HOORAY,2021-09-05T16:32:45Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2021-09-06T14:53:53Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2021-09-06T17:07:42Z,bugadani,NA https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2021-09-06T17:39:55Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2021-09-06T20:42:51Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2022-04-08T06:52:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88672,MERGED,2021-09-05T19:48:23Z,2022-04-03T07:53:16Z,Suggest `i += 1` when we see `i++` or `++i`,camelid,133859d680ffe31072b80f518377fa0c487359d9,7,Auto merge of #88672 - camelid:inc-parser-sugg r=davidtwco Suggest `i += 1` when we see `i++` or `++i` Closes #83502 (for `i++` and `++i`; `--i` should be covered by #82987 and `i--` is tricky to handle). This is a continuation of #83536. r? `@estebank`,HEART,2022-06-07T13:51:47Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/88675,CLOSED,2021-09-05T21:06:17Z,2021-10-20T00:25:30Z,Only check the compiler and standard library before documenting them,jyn514,NA,NA,NA,HEART,2021-09-05T21:16:36Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/88675,CLOSED,2021-09-05T21:06:17Z,2021-10-20T00:25:30Z,Only check the compiler and standard library before documenting them,jyn514,NA,NA,NA,HEART,2021-09-11T23:10:39Z,camelid,NA https://github.com/rust-lang/rust/pull/88675,CLOSED,2021-09-05T21:06:17Z,2021-10-20T00:25:30Z,Only check the compiler and standard library before documenting them,jyn514,NA,NA,NA,HEART,2021-09-19T21:18:44Z,est31,NA https://github.com/rust-lang/rust/pull/88676,MERGED,2021-09-05T21:28:27Z,2021-09-09T12:35:18Z,update of the CI freebsd toolchain,devnexen,497ee321af3b8496eaccd7af7b437f18bab81abf,1,Auto merge of #88676 - devnexen:fbsd_toolchain_upd r=Mark-Simulacrum update of the CI freebsd toolchain adding libproctsta for the upcoming libc update.,HEART,2021-09-15T13:16:37Z,lnicola,NA https://github.com/rust-lang/rust/pull/88678,MERGED,2021-09-05T22:09:35Z,2021-09-06T13:20:20Z,Change scope of temporaries in match guards,matthewjasper,1c858ba5bf7bd06c1a970efbf77053c8380b3151,10,Auto merge of #88678 - matthewjasper:if-boolean-scoping r=oli-obk Change scope of temporaries in match guards Each pattern in a match arm has its own copy of the match guard in MIR with its own temporary so it has to be dropped before the the guards are joined to the single copy of the arm. This PR changes `then_else_break` to allow it to put the temporary in the innermost scope possible. This change isn't done for `if` expressions because that affects a large number of mir-opt tests and could more significantly affect performance. closes #88649 r? `@oli-obk`,HEART,2021-09-06T16:04:45Z,RalfJung,NA https://github.com/rust-lang/rust/pull/88678,MERGED,2021-09-05T22:09:35Z,2021-09-06T13:20:20Z,Change scope of temporaries in match guards,matthewjasper,1c858ba5bf7bd06c1a970efbf77053c8380b3151,10,Auto merge of #88678 - matthewjasper:if-boolean-scoping r=oli-obk Change scope of temporaries in match guards Each pattern in a match arm has its own copy of the match guard in MIR with its own temporary so it has to be dropped before the the guards are joined to the single copy of the arm. This PR changes `then_else_break` to allow it to put the temporary in the innermost scope possible. This change isn't done for `if` expressions because that affects a large number of mir-opt tests and could more significantly affect performance. closes #88649 r? `@oli-obk`,HEART,2021-09-06T17:14:34Z,camelid,NA https://github.com/rust-lang/rust/pull/88679,MERGED,2021-09-05T23:24:05Z,2022-01-26T12:10:41Z,rustdoc: Pre-calculate traits that are in scope for doc links,petrochenkov,788b1fe5b79a8b74215022f9df49b0eae68a50b9,7,Auto merge of #88679 - petrochenkov:doctrscope r=GuillaumeGomez rustdoc: Pre-calculate traits that are in scope for doc links This eliminates one more late use of resolver (part of #83761). At early doc link resolution time we go through parent modules of items from the current crate reexports of items from other crates trait items and impl items collected by `collect-intra-doc-links` pass determine traits that are in scope in each such module and put those traits into a map used by later rustdoc passes. r? `@jyn514`,HEART,2021-09-06T02:11:37Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/88679,MERGED,2021-09-05T23:24:05Z,2022-01-26T12:10:41Z,rustdoc: Pre-calculate traits that are in scope for doc links,petrochenkov,788b1fe5b79a8b74215022f9df49b0eae68a50b9,7,Auto merge of #88679 - petrochenkov:doctrscope r=GuillaumeGomez rustdoc: Pre-calculate traits that are in scope for doc links This eliminates one more late use of resolver (part of #83761). At early doc link resolution time we go through parent modules of items from the current crate reexports of items from other crates trait items and impl items collected by `collect-intra-doc-links` pass determine traits that are in scope in each such module and put those traits into a map used by later rustdoc passes. r? `@jyn514`,HEART,2022-01-05T11:54:02Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88679,MERGED,2021-09-05T23:24:05Z,2022-01-26T12:10:41Z,rustdoc: Pre-calculate traits that are in scope for doc links,petrochenkov,788b1fe5b79a8b74215022f9df49b0eae68a50b9,7,Auto merge of #88679 - petrochenkov:doctrscope r=GuillaumeGomez rustdoc: Pre-calculate traits that are in scope for doc links This eliminates one more late use of resolver (part of #83761). At early doc link resolution time we go through parent modules of items from the current crate reexports of items from other crates trait items and impl items collected by `collect-intra-doc-links` pass determine traits that are in scope in each such module and put those traits into a map used by later rustdoc passes. r? `@jyn514`,HEART,2022-01-10T13:53:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88681,MERGED,2021-09-06T01:00:46Z,2021-11-22T05:25:02Z,Check for duplicate attributes.,ehuss,f7c48297ce21ac0dc5b36ff730377bdb7be6ece4,15,Auto merge of #88681 - ehuss:duplicate-attributes r=petrochenkov Check for duplicate attributes. This adds some checks for duplicate attributes. In many cases the duplicates were being ignored without error or warning. This adds several kinds of checks (see `AttributeDuplicates` enum). The motivation here is to issue unused warnings with similar reasoning for any unused lint and to error for cases where there are conflicts. This also adds a check for empty attribute lists in a few attributes where this causes the attribute to be ignored. Closes #55112.,THUMBS_UP,2021-09-06T16:46:16Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-06T18:10:08Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-06T21:23:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-07T09:57:11Z,fmease,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-15T09:27:47Z,ratijas,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-15T20:16:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-22T11:02:26Z,michaelkirk,michael.code@endoftheworl.de https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-23T04:41:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-23T06:49:15Z,Darrenmeehan,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-09-24T16:21:01Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-11-30T05:37:00Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-02T16:07:27Z,zohnannor,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-02T17:01:39Z,PooyaEimandar,pooya.eimandar@gmail.com https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-02T20:21:57Z,vojtechkral,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-03T02:45:27Z,iamhyc,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-04T21:03:09Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-05T07:06:07Z,pmnoxx,NA https://github.com/rust-lang/rust/pull/88690,MERGED,2021-09-06T16:26:05Z,2021-09-16T04:41:04Z,Accept `m!{ .. }.method()` and `m!{ .. }?` statements. ,m-ou-se,4b568409ad86ac516ae7397ac31b1b47b0a2e1a7,2,"Rollup merge of #88690 - m-ou-se:macro-braces-dot-question-expr-parse r=nagisa Accept `m!{ .. }.method()` and `m!{ .. }?` statements. This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`: Before: ``` error: expected expression found `.` --> src/lib.rs:6:6 | 4 | quote! { 5 | ... 6 | }.into() | ^ expected expression ``` After: ``` ``` (No output compiles fine.) --- Context: For expressions like `{ 1 }` and `if true { 1 } else { 2 }` we accept them as full statements without a trailing `;` which means the following is not accepted: ```rust { 1 } - 1 // error ``` since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct but the type of `{ 1 }` should be `()` as there is no `;`. However for specifically `.` and `?` after the `}` we do [continue parsing it as an expression](https://github.com/rust-lang/rust/blob/13db8440bbbe42870bc828d4ec3e965b38670277/compiler/rustc_parse/src/parser/expr.rs#L864-L876): ```rust { ""abc"" }.len(); // ok ``` For braced macro invocations we do not do this: ```rust vec![1 2 3].len(); // ok vec!{1 2 3}.len(); // error ``` (It parses `vec!{1 2 3}` as a full statement and then complains about `.len()` not being a valid expression.) This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases since no statement can start with a `.` or `?`.",HEART,2021-12-07T18:31:49Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/88691,MERGED,2021-09-06T16:29:54Z,2021-09-08T20:42:47Z,Add a regression test for #88649,NA,NA,NA,NA,HEART,2021-09-06T17:17:09Z,camelid,NA https://github.com/rust-lang/rust/pull/88702,CLOSED,2021-09-06T18:56:02Z,2021-09-08T17:27:43Z,Give sidebar a z-index,nbdd0121,NA,NA,NA,HEART,2021-09-06T19:19:49Z,m13253,NA https://github.com/rust-lang/rust/pull/88709,MERGED,2021-09-07T01:03:28Z,2021-09-12T16:23:42Z,generic_const_exprs: use thir for abstract consts instead of mir,BoxyUwU,f5ac5cadd3d426cbf9a67dfe1c21a7d404cd2423,35,Rollup merge of #88709 - BoxyUwU:thir-abstract-const r=lcnr generic_const_exprs: use thir for abstract consts instead of mir Changes `AbstractConst` building to use `thir` instead of `mir` so that there's less chance of consts unifying when they shouldn't because lowering to mir dropped information (see `abstract-consts-as-cast-5.rs` test) r? `@lcnr`,ROCKET,2021-09-08T20:07:38Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/88709,MERGED,2021-09-07T01:03:28Z,2021-09-12T16:23:42Z,generic_const_exprs: use thir for abstract consts instead of mir,BoxyUwU,f5ac5cadd3d426cbf9a67dfe1c21a7d404cd2423,35,Rollup merge of #88709 - BoxyUwU:thir-abstract-const r=lcnr generic_const_exprs: use thir for abstract consts instead of mir Changes `AbstractConst` building to use `thir` instead of `mir` so that there's less chance of consts unifying when they shouldn't because lowering to mir dropped information (see `abstract-consts-as-cast-5.rs` test) r? `@lcnr`,ROCKET,2022-01-28T13:17:46Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/88714,OPEN,2021-09-07T07:42:44Z,NA,use CLOCK_BOOTTIME in Instant::now,hellow554,NA,NA,NA,HEART,2022-04-08T07:14:41Z,faern,NA https://github.com/rust-lang/rust/pull/88714,OPEN,2021-09-07T07:42:44Z,NA,use CLOCK_BOOTTIME in Instant::now,hellow554,NA,NA,NA,HEART,2022-05-12T07:33:06Z,g2p,NA https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-09-07T11:10:44Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-09-07T17:33:11Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-09-07T18:36:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-09-08T20:50:31Z,panaman67,NA https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-10-21T06:56:55Z,Rengyr,mail@rengyr.eu https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-10-21T16:47:25Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/88717,MERGED,2021-09-07T10:54:31Z,2021-10-15T15:55:13Z,Optimize VecDeque::append,tabokie,af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27,1,Auto merge of #88717 - tabokie:vecdeque-fast-append r=m-ou-se Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz` the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append` the last two are reverted due to unsoundness or regression see: - https://github.com/rust-lang/rust/pull/52553 reverted in https://github.com/rust-lang/rust/pull/53571 - https://github.com/rust-lang/rust/pull/53564 reverted in https://github.com/rust-lang/rust/pull/54851 Both cases are covered by existing tests. Signed-off-by: tabokie ,ROCKET,2021-11-09T22:42:02Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/88719,MERGED,2021-09-07T12:00:30Z,2021-09-17T01:00:21Z,Point at argument instead of call for their obligations,estebank,e36621057d9f497c822eb800934b5933c10510cf,108,"Auto merge of #88719 - estebank:point-at-arg-for-obligation r=nagisa Point at argument instead of call for their obligations When an obligation is introduced by a specific `fn` argument point at the argument instead of the `fn` call if the obligation fails to be fulfilled. Move the information about pointing at the call argument expression in an unmet obligation span from the `FulfillmentError` to a new `ObligationCauseCode`. When giving an error about an obligation introduced by a function call that an argument doesn't fulfill and that argument is a block add a span_label pointing at the innermost tail expression. Current output: ``` error[E0425]: cannot find value `x` in this scope --> f10.rs:4:14 | 4 | Some(x * 2) | ^ not found in this scope error[E0277]: expected a `FnOnce<({integer} )>` closure found `Option<_>` --> f10.rs:2:31 | 2 | let p = Some(45).and_then({ | ______________________--------_^ | | | | | required by a bound introduced by this call 3 | | |x| println!(""doubling {}"" x); 4 | | Some(x * 2) | | ----------- 5 | | }); | |_____^ expected an `FnOnce<({integer} )>` closure found `Option<_>` | = help: the trait `FnOnce<({integer} )>` is not implemented for `Option<_>` ``` Previous output: ``` error[E0425]: cannot find value `x` in this scope --> f10.rs:4:14 | 4 | Some(x * 2) | ^ not found in this scope error[E0277]: expected a `FnOnce<({integer} )>` closure found `Option<_>` --> f10.rs:2:22 | 2 | let p = Some(45).and_then({ | ^^^^^^^^ expected an `FnOnce<({integer} )>` closure found `Option<_>` | = help: the trait `FnOnce<({integer} )>` is not implemented for `Option<_>` ``` Partially address #27300. Will require rebasing on top of #88546.",EYES,2021-09-07T12:27:31Z,scrabsha,NA https://github.com/rust-lang/rust/pull/88719,MERGED,2021-09-07T12:00:30Z,2021-09-17T01:00:21Z,Point at argument instead of call for their obligations,estebank,e36621057d9f497c822eb800934b5933c10510cf,108,"Auto merge of #88719 - estebank:point-at-arg-for-obligation r=nagisa Point at argument instead of call for their obligations When an obligation is introduced by a specific `fn` argument point at the argument instead of the `fn` call if the obligation fails to be fulfilled. Move the information about pointing at the call argument expression in an unmet obligation span from the `FulfillmentError` to a new `ObligationCauseCode`. When giving an error about an obligation introduced by a function call that an argument doesn't fulfill and that argument is a block add a span_label pointing at the innermost tail expression. Current output: ``` error[E0425]: cannot find value `x` in this scope --> f10.rs:4:14 | 4 | Some(x * 2) | ^ not found in this scope error[E0277]: expected a `FnOnce<({integer} )>` closure found `Option<_>` --> f10.rs:2:31 | 2 | let p = Some(45).and_then({ | ______________________--------_^ | | | | | required by a bound introduced by this call 3 | | |x| println!(""doubling {}"" x); 4 | | Some(x * 2) | | ----------- 5 | | }); | |_____^ expected an `FnOnce<({integer} )>` closure found `Option<_>` | = help: the trait `FnOnce<({integer} )>` is not implemented for `Option<_>` ``` Previous output: ``` error[E0425]: cannot find value `x` in this scope --> f10.rs:4:14 | 4 | Some(x * 2) | ^ not found in this scope error[E0277]: expected a `FnOnce<({integer} )>` closure found `Option<_>` --> f10.rs:2:22 | 2 | let p = Some(45).and_then({ | ^^^^^^^^ expected an `FnOnce<({integer} )>` closure found `Option<_>` | = help: the trait `FnOnce<({integer} )>` is not implemented for `Option<_>` ``` Partially address #27300. Will require rebasing on top of #88546.",THUMBS_UP,2021-09-07T15:26:04Z,jplatte,NA https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-09-07T17:13:47Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-09-07T21:02:37Z,CryZe,NA https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-09-08T11:30:01Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-09-09T15:00:07Z,guimcaballero,guim@caballerocoll.com https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-10-21T22:30:29Z,scottmcm,NA https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-12-16T17:19:01Z,leisim,simonleier@gmail.com https://github.com/rust-lang/rust/pull/88728,CLOSED,2021-09-07T16:56:48Z,2022-06-19T00:08:07Z,Added next_up and next_down for f32/f64.,orlp,NA,NA,NA,HEART,2021-12-30T13:32:44Z,Chris00,christophe.Troestler@umons.ac.be https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-07T18:37:55Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-07T18:40:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-07T19:10:17Z,glittershark,github@gws.fyi https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-07T20:08:32Z,gil0mendes,NA https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-07T20:08:35Z,gil0mendes,NA https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-07T21:47:21Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-07T21:47:22Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-08T02:31:42Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-08T02:31:42Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-08T05:18:24Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-08T08:46:03Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-08T08:46:04Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-08T09:15:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HOORAY,2021-09-23T04:41:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-23T04:42:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88729,MERGED,2021-09-07T17:45:32Z,2021-09-16T22:17:42Z,Recover from `Foo(a: 1 b: 2)`,estebank,2c7d48b9003d7f6f3babd9fa0b3fc1ba94df5ec1,7,Rollup merge of #88729 - estebank:struct-literal-using-parens r=oli-obk Recover from `Foo(a: 1 b: 2)` Detect likely `struct` literal using parentheses as delimiters and emit targeted suggestion instead of type ascription parse error. Fix #61326.,HEART,2021-09-26T07:51:15Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,CONFUSED,2021-09-08T06:10:42Z,marmeladema,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-15T03:24:19Z,lukechu10,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-16T10:53:32Z,nirbheek,nirbheek.chauhan@gmail.com https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-16T16:27:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-16T17:17:04Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-16T18:14:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-16T22:19:52Z,tux3,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-17T03:04:33Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-17T05:50:02Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-17T13:20:41Z,stefee,git@sril.email https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-17T13:23:54Z,rs6g10,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-17T15:18:03Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,HOORAY,2021-09-17T15:18:10Z,ilya-epifanov,NA https://github.com/rust-lang/rust/pull/88733,MERGED,2021-09-07T22:08:25Z,2021-09-11T20:39:53Z,Fix ICE for functions with more than 65535 arguments,Noble-Mushtak,746eb1d84defe2892a2d24a6029e8e7ec478a18f,3,Rollup merge of #88733 - Noble-Mushtak:88577 r=estebank Fix ICE for functions with more than 65535 arguments This pull request fixes #88577 by changing the `param_idx` field in the `Param` variant of `WellFormedLoc` from `u16` to `u32` thus allowing for more than 65 535 arguments in a function. Note that I also added a regression test but needed to add `// ignore-tidy-filelength` because the test is more than 8000 lines long.,LAUGH,2021-09-24T01:44:51Z,tmandry,NA https://github.com/rust-lang/rust/pull/88759,MERGED,2021-09-08T20:14:04Z,2021-09-12T23:49:24Z,Add -Z panic-in-drop={unwind abort} command-line option,Amanieu,51e514c0fb4f9afcaae3b02dd9ccb93e15b30ef8,11,Auto merge of #88759 - Amanieu:panic_in_drop r=nagisa eddyb Add -Z panic-in-drop={unwind abort} command-line option This PR changes `Drop` to abort if an unwinding panic attempts to escape it making the process abort instead. This has several benefits: - The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues but the remaining drops in scope are simply leaked. - A lot of unsafe code doesn't expect drops to unwind which can lead to unsoundness: - https://github.com/servo/rust-smallvec/issues/14 - https://github.com/bluss/arrayvec/issues/3 - There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee which can itself unwind etc. - Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`). One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box` will never unwind. cc https://github.com/rust-lang/lang-team/issues/97,HOORAY,2021-09-08T21:20:14Z,RalfJung,NA https://github.com/rust-lang/rust/pull/88759,MERGED,2021-09-08T20:14:04Z,2021-09-12T23:49:24Z,Add -Z panic-in-drop={unwind abort} command-line option,Amanieu,51e514c0fb4f9afcaae3b02dd9ccb93e15b30ef8,11,Auto merge of #88759 - Amanieu:panic_in_drop r=nagisa eddyb Add -Z panic-in-drop={unwind abort} command-line option This PR changes `Drop` to abort if an unwinding panic attempts to escape it making the process abort instead. This has several benefits: - The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues but the remaining drops in scope are simply leaked. - A lot of unsafe code doesn't expect drops to unwind which can lead to unsoundness: - https://github.com/servo/rust-smallvec/issues/14 - https://github.com/bluss/arrayvec/issues/3 - There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee which can itself unwind etc. - Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`). One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box` will never unwind. cc https://github.com/rust-lang/lang-team/issues/97,HOORAY,2021-09-09T09:54:19Z,Urgau,NA https://github.com/rust-lang/rust/pull/88759,MERGED,2021-09-08T20:14:04Z,2021-09-12T23:49:24Z,Add -Z panic-in-drop={unwind abort} command-line option,Amanieu,51e514c0fb4f9afcaae3b02dd9ccb93e15b30ef8,11,Auto merge of #88759 - Amanieu:panic_in_drop r=nagisa eddyb Add -Z panic-in-drop={unwind abort} command-line option This PR changes `Drop` to abort if an unwinding panic attempts to escape it making the process abort instead. This has several benefits: - The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues but the remaining drops in scope are simply leaked. - A lot of unsafe code doesn't expect drops to unwind which can lead to unsoundness: - https://github.com/servo/rust-smallvec/issues/14 - https://github.com/bluss/arrayvec/issues/3 - There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee which can itself unwind etc. - Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`). One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box` will never unwind. cc https://github.com/rust-lang/lang-team/issues/97,HOORAY,2021-09-09T18:19:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88772,MERGED,2021-09-09T09:50:33Z,2021-10-08T09:04:09Z,Fixed confusing wording on Result::map_or_else.,orlp,2b6d7f75f7f5ac0bce2265b0e33256356441ccba,1,Rollup merge of #88772 - orlp:result-map-or-else-docfix r=yaahc Fixed confusing wording on Result::map_or_else. Fixes https://github.com/rust-lang/rust/issues/88195.,HOORAY,2021-09-09T14:00:13Z,mdsn,NA https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,HEART,2021-10-14T07:00:52Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,HEART,2021-10-14T11:31:51Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,THUMBS_UP,2021-10-15T10:59:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,THUMBS_UP,2021-10-17T21:11:15Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,HEART,2022-04-23T22:08:18Z,nim65s,guilhem.saurel@laas.fr https://github.com/rust-lang/rust/pull/88780,MERGED,2021-09-09T15:00:36Z,2021-10-05T06:54:20Z,Added abs_diff for integer types.,orlp,234fa908788f098b12c2f54181b6133f355fa07e,2,Rollup merge of #88780 - orlp:int-abs-diff r=m-ou-se Added abs_diff for integer types. Closes https://github.com/rust-lang/rust/issues/62111.,HEART,2022-06-22T05:28:25Z,mawillcockson,matthew@willcockson.family https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,HOORAY,2021-09-09T15:49:52Z,rrbutani,NA https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,HOORAY,2021-09-09T17:43:05Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-09-10T07:41:52Z,oli-obk,NA https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-09-13T16:00:57Z,chansuke,moonset20@gmail.com https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-09-14T20:42:48Z,Alexhuszagh,ahuszagh@gmail.com https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-09-14T21:07:44Z,loudermachine,NA https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-09-19T06:20:16Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-11-01T17:29:51Z,est31,NA https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-12-02T22:14:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88781,MERGED,2021-09-09T15:05:48Z,2021-11-25T11:24:11Z,Tokenize emoji as if they were valid identifiers ,estebank,23a436606b118bd2fbb12f64fce21e7f9d355349,13,Auto merge of #88781 - estebank:emoji-idents r=oli-obk Tokenize emoji as if they were valid identifiers In the lexer consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.,LAUGH,2021-12-02T22:59:18Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/88782,MERGED,2021-09-09T15:23:05Z,2021-10-01T06:20:00Z,Fix ICE when `start` lang item has wrong generics,asquared31415,3d86aac990c0310726da05fe1fdb5827ccfc495d,6,Rollup merge of #88782 - asquared31415:issue-79559 r=cjgillot Fix ICE when `start` lang item has wrong generics In my previous pr #87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates. This fixes that by updating the requirement to be exactly one generic type. The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it. I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations. Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided. Fixes #79559 fixes #73584 fixes #83117 (all duplicates) Relevant to #9307 r? ````@cjgillot````,ROCKET,2021-09-09T15:23:33Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-09-09T17:54:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-09-09T21:49:04Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-09-10T15:54:43Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-10-21T16:49:14Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-10-22T22:05:29Z,CatCode79,andrea.postal@gmail.com https://github.com/rust-lang/rust/pull/88788,MERGED,2021-09-09T17:48:23Z,2021-10-12T06:12:40Z,Speedup int log10 branchless,falk-hueffner,ffdf18d1447b57faafded06a887b6dae1f7293c7,5,Auto merge of #88788 - falk-hueffner:speedup-int-log10-branchless r=joshtriplett Speedup int log10 branchless This is achieved with a branchless bit-twiddling implementation of the case x < 100_000 and using this as building block. Benchmark on an Intel i7-8700K (Coffee Lake): ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 165 169 4 2.42% x 0.98 num::int_log::u8_log10_random 438 423 -15 -3.42% x 1.04 num::int_log::u8_log10_random_small 438 423 -15 -3.42% x 1.04 num::int_log::u16_log10_predictable 633 417 -216 -34.12% x 1.52 num::int_log::u16_log10_random 908 471 -437 -48.13% x 1.93 num::int_log::u16_log10_random_small 945 471 -474 -50.16% x 2.01 num::int_log::u32_log10_predictable 1 496 1 340 -156 -10.43% x 1.12 num::int_log::u32_log10_random 1 076 873 -203 -18.87% x 1.23 num::int_log::u32_log10_random_small 1 145 874 -271 -23.67% x 1.31 num::int_log::u64_log10_predictable 4 005 3 171 -834 -20.82% x 1.26 num::int_log::u64_log10_random 1 247 1 021 -226 -18.12% x 1.22 num::int_log::u64_log10_random_small 1 265 921 -344 -27.19% x 1.37 num::int_log::u128_log10_predictable 39 667 39 579 -88 -0.22% x 1.00 num::int_log::u128_log10_random 6 456 6 696 240 3.72% x 0.96 num::int_log::u128_log10_random_small 4 108 3 903 -205 -4.99% x 1.05 ``` Benchmark on an M1 Mac Mini: ``` name old ns/iter new ns/iter diff ns/iter diff % speedup num::int_log::u8_log10_predictable 143 130 -13 -9.09% x 1.10 num::int_log::u8_log10_random 375 325 -50 -13.33% x 1.15 num::int_log::u8_log10_random_small 376 325 -51 -13.56% x 1.16 num::int_log::u16_log10_predictable 500 322 -178 -35.60% x 1.55 num::int_log::u16_log10_random 794 405 -389 -48.99% x 1.96 num::int_log::u16_log10_random_small 1 035 405 -630 -60.87% x 2.56 num::int_log::u32_log10_predictable 1 144 894 -250 -21.85% x 1.28 num::int_log::u32_log10_random 832 786 -46 -5.53% x 1.06 num::int_log::u32_log10_random_small 832 787 -45 -5.41% x 1.06 num::int_log::u64_log10_predictable 2 681 2 057 -624 -23.27% x 1.30 num::int_log::u64_log10_random 1 015 806 -209 -20.59% x 1.26 num::int_log::u64_log10_random_small 1 004 795 -209 -20.82% x 1.26 num::int_log::u128_log10_predictable 56 825 56 526 -299 -0.53% x 1.01 num::int_log::u128_log10_random 9 056 8 861 -195 -2.15% x 1.02 num::int_log::u128_log10_random_small 1 528 1 527 -1 -0.07% x 1.00 ``` The 128 bit case remains ridiculously slow because llvm fails to optimize division by a constant 128-bit value to multiplications. This could be worked around but it seems preferable to fix this in llvm. From u32 up table lookup (like suggested [here](https://github.com/rust-lang/rust/issues/70887#issuecomment-881099813)) is still faster but requires a hardware `leading_zeros` to be viable and might clog up the cache.,ROCKET,2021-11-09T22:41:37Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/88798,MERGED,2021-09-09T22:36:09Z,2021-11-11T15:04:30Z,Fix assertion failures in `OwnedHandle` with `windows_subsystem`.,sunfishcode,d71ba74f0d51459ef10f2b73400c013c7a12d828,1,Auto merge of #88798 - sunfishcode:sunfishcode/windows-null-handles r=joshtriplett Fix assertion failures in `OwnedHandle` with `windows_subsystem`. As discussed in #88576 raw handle values in Windows can be null such as in `windows_subsystem` mode or when consoles are detached from a process. So don't use `NonNull` to hold them don't assert that they're not null and remove `OwnedHandle`'s `repr(transparent)`. Introduce a new `HandleOrNull` type similar to `HandleOrInvalid` to cover the FFI use case. r? `@joshtriplett`,THUMBS_UP,2021-10-25T07:02:59Z,Poopooracoocoo,NA https://github.com/rust-lang/rust/pull/88801,CLOSED,2021-09-09T23:37:58Z,2021-09-17T18:49:16Z,Fix for raw-dylib when linking with MinGW BFD,mati865,NA,NA,NA,HEART,2021-09-11T19:10:16Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/88804,MERGED,2021-09-10T00:28:36Z,2021-09-24T01:48:07Z,Revise never type fallback algorithm,Mark-Simulacrum,900cf5e8905ba8a2a9c99a1dfc9cb2cf4754d77a,30,"Auto merge of #88804 - Mark-Simulacrum:never-algo-v2 r=nikomatsakis jackh726 Revise never type fallback algorithm This is a rebase of https://github.com/rust-lang/rust/pull/84573 but dropping the stabilization of never type (and the accompanying large test diff). Each commit builds & has tests updated alongside it and could be reviewed in a more or less standalone fashion. But it may make more sense to review the PR as a whole I'm not sure. It should be noted that tests being updated isn't really a good indicator of final behavior -- never_type_fallback is not enabled by default in this PR so we can't really see the full effects of the commits here. This combines the work by Niko which is [documented in this gist](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660) with some additional rules largely derived to target specific known patterns that regress with the algorithm solely derived by Niko. We build these from an intuition that: * In general fallback to `()` is *sound* in all cases * But in general we *prefer* fallback to `!` as it accepts more code particularly that written to intentionally use `!` (e.g. Result's with a Infallible/! variant). When evaluating Niko's proposed algorithm we find that there are certain cases where fallback to `!` leads to compilation failures in real-world code and fallback to `()` fixes those errors. In order to allow for stabilization we need to fix a good portion of these patterns. The final rule set this PR proposes is that by default we fallback from `?T` to `!` with the following exceptions: 1. `?T: Foo` and `Bar::Baz = ?T` and `(): Foo` then fallback to `()` 2. Per [Niko's algorithm](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660#proposal-fallback-chooses-between--and--based-on-the-coercion-graph) the ""live"" `?T` also fallback to `()`. The first rule is necessary to address a fairly common pattern which boils down to something like the snippet below. Without rule 1 we do not see the closure's return type as needing a () fallback which leads to compilation failure. ```rust #![feature(never_type_fallback)] trait Bar { } impl Bar for () { } impl Bar for u32 { } fn foo(_: impl Fn() -> R) {} fn main() { foo(|| panic!()); } ``` r? `@jackh726`",THUMBS_UP,2021-09-10T00:43:12Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/88804,MERGED,2021-09-10T00:28:36Z,2021-09-24T01:48:07Z,Revise never type fallback algorithm,Mark-Simulacrum,900cf5e8905ba8a2a9c99a1dfc9cb2cf4754d77a,30,"Auto merge of #88804 - Mark-Simulacrum:never-algo-v2 r=nikomatsakis jackh726 Revise never type fallback algorithm This is a rebase of https://github.com/rust-lang/rust/pull/84573 but dropping the stabilization of never type (and the accompanying large test diff). Each commit builds & has tests updated alongside it and could be reviewed in a more or less standalone fashion. But it may make more sense to review the PR as a whole I'm not sure. It should be noted that tests being updated isn't really a good indicator of final behavior -- never_type_fallback is not enabled by default in this PR so we can't really see the full effects of the commits here. This combines the work by Niko which is [documented in this gist](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660) with some additional rules largely derived to target specific known patterns that regress with the algorithm solely derived by Niko. We build these from an intuition that: * In general fallback to `()` is *sound* in all cases * But in general we *prefer* fallback to `!` as it accepts more code particularly that written to intentionally use `!` (e.g. Result's with a Infallible/! variant). When evaluating Niko's proposed algorithm we find that there are certain cases where fallback to `!` leads to compilation failures in real-world code and fallback to `()` fixes those errors. In order to allow for stabilization we need to fix a good portion of these patterns. The final rule set this PR proposes is that by default we fallback from `?T` to `!` with the following exceptions: 1. `?T: Foo` and `Bar::Baz = ?T` and `(): Foo` then fallback to `()` 2. Per [Niko's algorithm](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660#proposal-fallback-chooses-between--and--based-on-the-coercion-graph) the ""live"" `?T` also fallback to `()`. The first rule is necessary to address a fairly common pattern which boils down to something like the snippet below. Without rule 1 we do not see the closure's return type as needing a () fallback which leads to compilation failure. ```rust #![feature(never_type_fallback)] trait Bar { } impl Bar for () { } impl Bar for u32 { } fn foo(_: impl Fn() -> R) {} fn main() { foo(|| panic!()); } ``` r? `@jackh726`",THUMBS_UP,2021-09-17T18:13:13Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/88804,MERGED,2021-09-10T00:28:36Z,2021-09-24T01:48:07Z,Revise never type fallback algorithm,Mark-Simulacrum,900cf5e8905ba8a2a9c99a1dfc9cb2cf4754d77a,30,"Auto merge of #88804 - Mark-Simulacrum:never-algo-v2 r=nikomatsakis jackh726 Revise never type fallback algorithm This is a rebase of https://github.com/rust-lang/rust/pull/84573 but dropping the stabilization of never type (and the accompanying large test diff). Each commit builds & has tests updated alongside it and could be reviewed in a more or less standalone fashion. But it may make more sense to review the PR as a whole I'm not sure. It should be noted that tests being updated isn't really a good indicator of final behavior -- never_type_fallback is not enabled by default in this PR so we can't really see the full effects of the commits here. This combines the work by Niko which is [documented in this gist](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660) with some additional rules largely derived to target specific known patterns that regress with the algorithm solely derived by Niko. We build these from an intuition that: * In general fallback to `()` is *sound* in all cases * But in general we *prefer* fallback to `!` as it accepts more code particularly that written to intentionally use `!` (e.g. Result's with a Infallible/! variant). When evaluating Niko's proposed algorithm we find that there are certain cases where fallback to `!` leads to compilation failures in real-world code and fallback to `()` fixes those errors. In order to allow for stabilization we need to fix a good portion of these patterns. The final rule set this PR proposes is that by default we fallback from `?T` to `!` with the following exceptions: 1. `?T: Foo` and `Bar::Baz = ?T` and `(): Foo` then fallback to `()` 2. Per [Niko's algorithm](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660#proposal-fallback-chooses-between--and--based-on-the-coercion-graph) the ""live"" `?T` also fallback to `()`. The first rule is necessary to address a fairly common pattern which boils down to something like the snippet below. Without rule 1 we do not see the closure's return type as needing a () fallback which leads to compilation failure. ```rust #![feature(never_type_fallback)] trait Bar { } impl Bar for () { } impl Bar for u32 { } fn foo(_: impl Fn() -> R) {} fn main() { foo(|| panic!()); } ``` r? `@jackh726`",THUMBS_UP,2021-09-30T18:05:28Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88805,MERGED,2021-09-10T00:49:33Z,2022-03-04T05:15:20Z,Clarification of default socket flags,krhancoc,4c7020047605dcabe5d0611bb5b575e8344fe515,1,Rollup merge of #88805 - krhancoc:master r=dtolnay Clarification of default socket flags This PR outlines the decision to disable inheritance of socket objects when possible to child processes in the documentation.,EYES,2021-09-10T22:32:20Z,aidan-waite,NA https://github.com/rust-lang/rust/pull/88805,MERGED,2021-09-10T00:49:33Z,2022-03-04T05:15:20Z,Clarification of default socket flags,krhancoc,4c7020047605dcabe5d0611bb5b575e8344fe515,1,Rollup merge of #88805 - krhancoc:master r=dtolnay Clarification of default socket flags This PR outlines the decision to disable inheritance of socket objects when possible to child processes in the documentation.,THUMBS_UP,2021-09-10T22:32:28Z,aidan-waite,NA https://github.com/rust-lang/rust/pull/88810,MERGED,2021-09-10T03:02:52Z,2021-09-12T16:23:42Z,rustdoc: Cleanup `clean` part 1,camelid,b3af37ac7b9d5bd6dcd747a62382908dcb7c9ca9,6,Rollup merge of #88810 - camelid:cleanup-pt1 r=jyn514 rustdoc: Cleanup `clean` part 1 Split out from #88379. These commits are completely independent of each other and each is a fairly small change (the last few are new commits; they are not from #88379): - Remove unnecessary `Cache.*_did` fields - rustdoc: Get symbol for `TyParam` directly - Create a valid `Res` in `external_path()` - Remove unused `hir_id` parameter from `resolve_type` - Fix redundant arguments in `external_path()` - Remove unnecessary `is_trait` argument - rustdoc: Cleanup a pattern match in `external_generic_args()` r? ``@jyn514``,HEART,2021-09-10T18:38:14Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/88814,CLOSED,2021-09-10T09:10:00Z,2021-09-10T15:06:02Z,No --as-needed for -fuse-ld=lld,1000teslas,NA,NA,NA,CONFUSED,2021-09-10T11:20:04Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88815,CLOSED,2021-09-10T10:25:58Z,2021-09-10T15:16:12Z,Restrict parsing of bare union/struct to field types,estebank,NA,NA,NA,THUMBS_DOWN,2021-09-10T11:58:13Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/88838,MERGED,2021-09-10T23:26:18Z,2021-10-01T11:44:13Z,Do not suggest importing inaccessible items,FabianWolff,9593e61f64233c6c556762060dc5e1cdc636845e,11,Rollup merge of #88838 - FabianWolff:issue-88472 r=estebank Do not suggest importing inaccessible items Fixes #88472. For this example: ```rust mod a { struct Foo; } mod b { type Bar = Foo; } ``` rustc currently emits: ``` error[E0412]: cannot find type `Foo` in this scope --> test.rs:6:16 | 6 | type Bar = Foo; | ^^^ not found in this scope | help: consider importing this struct | 6 | use a::Foo; | ``` this is incorrect as applying this suggestion leads to ``` error[E0603]: struct `Foo` is private --> test.rs:6:12 | 6 | use a::Foo; | ^^^ private struct | note: the struct `Foo` is defined here --> test.rs:2:5 | 2 | struct Foo; | ^^^^^^^^^^^ ``` With my changes I get: ``` error[E0412]: cannot find type `Foo` in this scope --> test.rs:6:16 | 6 | type Bar = Foo; | ^^^ not found in this scope | = note: this struct exists but is inaccessible: a::Foo ``` As for the wildcard mentioned in #88472 I would argue that the warning is actually correct since the import _is_ unused. I think the real issue is the wrong suggestion which I have fixed here.,HEART,2021-09-15T15:20:24Z,estebank,NA https://github.com/rust-lang/rust/pull/88838,MERGED,2021-09-10T23:26:18Z,2021-10-01T11:44:13Z,Do not suggest importing inaccessible items,FabianWolff,9593e61f64233c6c556762060dc5e1cdc636845e,11,Rollup merge of #88838 - FabianWolff:issue-88472 r=estebank Do not suggest importing inaccessible items Fixes #88472. For this example: ```rust mod a { struct Foo; } mod b { type Bar = Foo; } ``` rustc currently emits: ``` error[E0412]: cannot find type `Foo` in this scope --> test.rs:6:16 | 6 | type Bar = Foo; | ^^^ not found in this scope | help: consider importing this struct | 6 | use a::Foo; | ``` this is incorrect as applying this suggestion leads to ``` error[E0603]: struct `Foo` is private --> test.rs:6:12 | 6 | use a::Foo; | ^^^ private struct | note: the struct `Foo` is defined here --> test.rs:2:5 | 2 | struct Foo; | ^^^^^^^^^^^ ``` With my changes I get: ``` error[E0412]: cannot find type `Foo` in this scope --> test.rs:6:16 | 6 | type Bar = Foo; | ^^^ not found in this scope | = note: this struct exists but is inaccessible: a::Foo ``` As for the wildcard mentioned in #88472 I would argue that the warning is actually correct since the import _is_ unused. I think the real issue is the wrong suggestion which I have fixed here.,HEART,2021-09-28T19:28:55Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/88846,MERGED,2021-09-11T03:46:56Z,2021-09-22T06:43:37Z,In suggest_missing_return_type erase late bound regions after normalizing,jackh726,77f4143fa26a1434088f532d2ba7ec51e0a392fd,3,Auto merge of #88846 - jackh726:issue-88360 r=nikomatsakis In suggest_missing_return_type erase late bound regions after normalizing Fixes #88360 There might be some hardening that could be done to not error or avoid erroring with LUBing `ReErased` with `ReEmpty` but this was the most simple fix for this particular case. r? `@nikomatsakis`,HEART,2021-09-11T11:54:22Z,hlb8122,harrybarber@protonmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-13T09:42:49Z,estebank,NA https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-13T18:21:38Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-15T19:41:03Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HEART,2021-09-15T19:41:06Z,LucioFranco,luciofranco14@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-16T19:32:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-17T21:18:47Z,banool,danielporteous1@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-21T03:22:13Z,tmandry,NA https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HEART,2021-09-21T03:22:14Z,tmandry,NA https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2021-09-23T01:20:17Z,rrbutani,NA https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2022-02-04T06:44:15Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/88865,MERGED,2021-09-11T17:43:59Z,2021-09-22T09:32:30Z,Implement `#[must_not_suspend]`,guswynn,ce45663e14dac3f0f58be698cc530bc2e6e21682,27,"Auto merge of #88865 - guswynn:must_not_suspend r=oli-obk Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects) like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time but `must_not_suspend` would need to answer the question: ""for some value X with type T find any fn call that COULD have produced this value"". That would require significant changes to `generator_interior.rs` and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also I am not sure if we should run perf on this r? `@nikomatsakis`",HOORAY,2022-02-04T09:27:50Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/88879,CLOSED,2021-09-12T10:05:36Z,2021-12-09T14:27:39Z,asm/arm: allow r9 when usable make diagnostics more specific,Skirmisher,NA,NA,NA,THUMBS_UP,2021-09-12T14:52:30Z,Lokathor,NA https://github.com/rust-lang/rust/pull/88879,CLOSED,2021-09-12T10:05:36Z,2021-12-09T14:27:39Z,asm/arm: allow r9 when usable make diagnostics more specific,Skirmisher,NA,NA,NA,HOORAY,2021-09-12T14:52:33Z,Lokathor,NA https://github.com/rust-lang/rust/pull/88879,CLOSED,2021-09-12T10:05:36Z,2021-12-09T14:27:39Z,asm/arm: allow r9 when usable make diagnostics more specific,Skirmisher,NA,NA,NA,THUMBS_UP,2021-09-12T22:55:49Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/88895,MERGED,2021-09-12T20:36:08Z,2021-09-26T05:15:18Z,rustdoc: Cleanup `clean` part 2,camelid,7777f952f0905e299dc95e4adfca7d4ef38b7168,8,Rollup merge of #88895 - camelid:cleanup-pt2 r=jyn514 rustdoc: Cleanup `clean` part 2 Split out from #88379. This contains the following commits from that PR: - Remove `Type::ResolvedPath.is_generic` - Rename `is_generic()` to `is_assoc_ty()` r? `@jyn514`,HEART,2021-09-12T22:27:31Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/88899,MERGED,2021-09-12T21:16:02Z,2021-09-17T18:48:36Z,Do not issue E0071 if a type error has already been reported,FabianWolff,307f2ddfa4d0cdbf64a4f2c756566e610853e511,4,"Rollup merge of #88899 - FabianWolff:issue-88844 r=matthewjasper Do not issue E0071 if a type error has already been reported Fixes #88844. A suggested fix is already included in the error message for E0412 so with my changes E0071 is simply not emitted anymore if the type in question is a ""type error"". This makes sense I think because we cannot confidently state that something is ""not a struct"" if we couldn't resolve it properly; and it's unnecessary to pollute the output with this additional error message as it is a direct consequence of the former error. I have also addressed the issue mentioned in https://github.com/rust-lang/rust/issues/88844#issuecomment-917324856 by changing the fixed example in the documentation to more closely match the erroneous code example.",HOORAY,2021-09-18T00:41:40Z,lopopolo,NA https://github.com/rust-lang/rust/pull/88899,MERGED,2021-09-12T21:16:02Z,2021-09-17T18:48:36Z,Do not issue E0071 if a type error has already been reported,FabianWolff,307f2ddfa4d0cdbf64a4f2c756566e610853e511,4,"Rollup merge of #88899 - FabianWolff:issue-88844 r=matthewjasper Do not issue E0071 if a type error has already been reported Fixes #88844. A suggested fix is already included in the error message for E0412 so with my changes E0071 is simply not emitted anymore if the type in question is a ""type error"". This makes sense I think because we cannot confidently state that something is ""not a struct"" if we couldn't resolve it properly; and it's unnecessary to pollute the output with this additional error message as it is a direct consequence of the former error. I have also addressed the issue mentioned in https://github.com/rust-lang/rust/issues/88844#issuecomment-917324856 by changing the fixed example in the documentation to more closely match the erroneous code example.",HEART,2021-09-18T00:41:42Z,lopopolo,NA https://github.com/rust-lang/rust/pull/88906,CLOSED,2021-09-13T13:52:01Z,2021-12-03T11:43:25Z,Implement write() method for Box>,Kixunil,NA,NA,NA,THUMBS_UP,2021-09-13T14:23:07Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/88906,CLOSED,2021-09-13T13:52:01Z,2021-12-03T11:43:25Z,Implement write() method for Box>,Kixunil,NA,NA,NA,THUMBS_UP,2021-09-13T22:03:51Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/88907,MERGED,2021-09-13T14:38:38Z,2021-09-16T04:41:03Z,Highlight the `const fn` if error happened because of a bound on the impl block,WaffleLapkin,e1acdf51bf798bd9a160eb96e48d66f5e5bddd37,3,"Rollup merge of #88907 - WaffleLapkin:targeted_const_fn_with_a_bound_in_impl_block_error r=estebank Highlight the `const fn` if error happened because of a bound on the impl block Currently for the following code the compiler produces the errors like the following: ```rust struct Type(T); impl Type { const fn f() {} } ``` ```text error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable --> ./test.rs:3:6 | 3 | impl Type { | ^ | = note: see issue #57563 for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable ``` This can be confusing (especially to newcomers) since the error mentions ""const fn parameters"" but highlights only the impl. This PR adds function highlighting changing the error to the following: ```text error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable --> ./test.rs:3:6 | 3 | impl Type { | ^ 4 | pub const fn f() {} | ---------------- function declared as const here | = note: see issue #57563 for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable ``` --- I've originally wanted to point directly to `const` token but couldn't find a way to get it's span. It seems like this span is lost during the AST -> HIR lowering. Also since the errors for object casts in `const fn`s (`&T` -> `&dyn Trait`) seem to trigger the same error this PR accidentally changes these errors too. Not sure if it's desired or how to fix this. P.S. it's my first time contributing to diagnostics so feedback is very appreciated! --- r? ```@estebank``` ```@rustbot``` label: +A-diagnostics",HEART,2021-09-14T11:59:27Z,estebank,NA https://github.com/rust-lang/rust/pull/88907,MERGED,2021-09-13T14:38:38Z,2021-09-16T04:41:03Z,Highlight the `const fn` if error happened because of a bound on the impl block,WaffleLapkin,e1acdf51bf798bd9a160eb96e48d66f5e5bddd37,3,"Rollup merge of #88907 - WaffleLapkin:targeted_const_fn_with_a_bound_in_impl_block_error r=estebank Highlight the `const fn` if error happened because of a bound on the impl block Currently for the following code the compiler produces the errors like the following: ```rust struct Type(T); impl Type { const fn f() {} } ``` ```text error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable --> ./test.rs:3:6 | 3 | impl Type { | ^ | = note: see issue #57563 for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable ``` This can be confusing (especially to newcomers) since the error mentions ""const fn parameters"" but highlights only the impl. This PR adds function highlighting changing the error to the following: ```text error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable --> ./test.rs:3:6 | 3 | impl Type { | ^ 4 | pub const fn f() {} | ---------------- function declared as const here | = note: see issue #57563 for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable ``` --- I've originally wanted to point directly to `const` token but couldn't find a way to get it's span. It seems like this span is lost during the AST -> HIR lowering. Also since the errors for object casts in `const fn`s (`&T` -> `&dyn Trait`) seem to trigger the same error this PR accidentally changes these errors too. Not sure if it's desired or how to fix this. P.S. it's my first time contributing to diagnostics so feedback is very appreciated! --- r? ```@estebank``` ```@rustbot``` label: +A-diagnostics",HEART,2021-09-15T09:17:18Z,Agrailag,NA https://github.com/rust-lang/rust/pull/88911,MERGED,2021-09-13T17:43:48Z,2021-09-17T09:44:39Z,Improve error message for type mismatch in generator arguments,FabianWolff,c97ff098f192901b81dc2ad7142195757853964d,4,"Rollup merge of #88911 - FabianWolff:issue-88653 r=petrochenkov Improve error message for type mismatch in generator arguments Fixes #88653. The code example given there is invalid because the `Generator` trait (unlike the `Fn` traits) does not take the generator arguments in tupled-up form (because there can only be one argument from my understanding). Hence the type error in the example in #88653 is correct because the given generator takes a `bool` argument whereas the function's return type talks about a generator with a `(bool )` argument. The error message is both confusing and wrong though: It is wrong because it displays the wrong ""expected signature"" and it is confusing because both the ""expected"" and ""found"" notes point at the same span. With my changes I get the following more helpful output: ``` error[E0631]: type mismatch in generator arguments --> test.rs:5:22 | 5 | fn foo(bar: bool) -> impl Generator<(bool )> { | ^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `fn((bool )) -> _` 6 | |bar| { | ----- found signature of `fn(bool) -> _` ```",THUMBS_UP,2021-09-13T18:59:51Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/88916,CLOSED,2021-09-13T20:01:50Z,2021-10-10T17:49:55Z,Mark `String::clone` as inline-able,notriddle,NA,NA,NA,HEART,2021-09-13T21:57:20Z,SadiinsoSnowfall,NA https://github.com/rust-lang/rust/pull/88945,MERGED,2021-09-14T20:43:14Z,2021-09-17T12:26:31Z,Remove concept of 'completion' from the projection cache,Aaron1011,e0c38af27cb5f6f961809601b717d6afc3b190ee,2,Auto merge of #88945 - Aaron1011:no-projection-completion r=wesleywiser jackh726 Remove concept of 'completion' from the projection cache Fixes #88910 When we initially store a `NormalizedTy` in the projection cache we discard all obligations that we can (while ensuring that we don't cause any issues with incremental compilation). Marking a projection cache entry as 'completed' discards all obligations associated with it. This can only cause problems since any obligations stored in the cache are there for a reason (e.g. they evaluate to `EvaluatedToOkModuloRegions`). This commit removes `complete` and `complete_normalized` entirely.,THUMBS_UP,2021-09-15T00:58:22Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88945,MERGED,2021-09-14T20:43:14Z,2021-09-17T12:26:31Z,Remove concept of 'completion' from the projection cache,Aaron1011,e0c38af27cb5f6f961809601b717d6afc3b190ee,2,Auto merge of #88945 - Aaron1011:no-projection-completion r=wesleywiser jackh726 Remove concept of 'completion' from the projection cache Fixes #88910 When we initially store a `NormalizedTy` in the projection cache we discard all obligations that we can (while ensuring that we don't cause any issues with incremental compilation). Marking a projection cache entry as 'completed' discards all obligations associated with it. This can only cause problems since any obligations stored in the cache are there for a reason (e.g. they evaluate to `EvaluatedToOkModuloRegions`). This commit removes `complete` and `complete_normalized` entirely.,THUMBS_UP,2021-09-15T08:28:57Z,imlvts,NA https://github.com/rust-lang/rust/pull/88945,MERGED,2021-09-14T20:43:14Z,2021-09-17T12:26:31Z,Remove concept of 'completion' from the projection cache,Aaron1011,e0c38af27cb5f6f961809601b717d6afc3b190ee,2,Auto merge of #88945 - Aaron1011:no-projection-completion r=wesleywiser jackh726 Remove concept of 'completion' from the projection cache Fixes #88910 When we initially store a `NormalizedTy` in the projection cache we discard all obligations that we can (while ensuring that we don't cause any issues with incremental compilation). Marking a projection cache entry as 'completed' discards all obligations associated with it. This can only cause problems since any obligations stored in the cache are there for a reason (e.g. they evaluate to `EvaluatedToOkModuloRegions`). This commit removes `complete` and `complete_normalized` entirely.,THUMBS_UP,2021-09-16T01:50:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/88945,MERGED,2021-09-14T20:43:14Z,2021-09-17T12:26:31Z,Remove concept of 'completion' from the projection cache,Aaron1011,e0c38af27cb5f6f961809601b717d6afc3b190ee,2,Auto merge of #88945 - Aaron1011:no-projection-completion r=wesleywiser jackh726 Remove concept of 'completion' from the projection cache Fixes #88910 When we initially store a `NormalizedTy` in the projection cache we discard all obligations that we can (while ensuring that we don't cause any issues with incremental compilation). Marking a projection cache entry as 'completed' discards all obligations associated with it. This can only cause problems since any obligations stored in the cache are there for a reason (e.g. they evaluate to `EvaluatedToOkModuloRegions`). This commit removes `complete` and `complete_normalized` entirely.,THUMBS_UP,2021-09-16T07:24:45Z,MrMuetze,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-15T01:03:48Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-15T04:10:16Z,camelid,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-15T05:48:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-15T12:03:45Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-15T15:47:42Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-19T21:54:53Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HEART,2021-09-20T07:44:24Z,iDawer,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HEART,2021-09-23T22:56:58Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-26T11:05:22Z,varkor,NA https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HEART,2021-09-28T19:27:23Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HOORAY,2021-09-29T15:01:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/88950,MERGED,2021-09-15T00:33:00Z,2021-09-29T03:06:18Z,Add an intermediate representation to exhaustiveness checking,Nadrieril,6df1d82869d06b88ff413e63a1e8efbb311e3b5c,10,Auto merge of #88950 - Nadrieril:deconstruct-pat r=oli-obk Add an intermediate representation to exhaustiveness checking The exhaustiveness checking algorithm keeps deconstructing patterns into a `Constructor` and some `Fields` but does so a bit all over the place. This PR introduces a new representation for patterns that already has that information so we only compute it once at the start. I find this makes code easier to follow. In particular `DeconstructedPat::specialize` is a lot simpler than what happened before and more closely matches the description of the algorithm. I'm also hoping this could help for the project of librarifying exhaustiveness for rust_analyzer since it decouples the algorithm from `rustc_middle::Pat`.,HEART,2021-09-29T15:01:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/88952,MERGED,2021-09-15T01:18:14Z,2021-10-10T11:28:46Z,Add new tier-3 target: armv7-unknown-linux-uclibceabihf,skrap,9e8356c6adf119f983651d533d2b307544086cf9,9,"Auto merge of #88952 - skrap:add-armv7-uclibc r=nagisa Add new tier-3 target: armv7-unknown-linux-uclibceabihf This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org). The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward and graciously allowed me to take it over. Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md) I volunteer to be the ""target maintainer"". This is my first PR to Rust itself so I apologize if I've missed things!",THUMBS_UP,2021-09-29T06:45:07Z,WooDzu,NA https://github.com/rust-lang/rust/pull/88952,MERGED,2021-09-15T01:18:14Z,2021-10-10T11:28:46Z,Add new tier-3 target: armv7-unknown-linux-uclibceabihf,skrap,9e8356c6adf119f983651d533d2b307544086cf9,9,"Auto merge of #88952 - skrap:add-armv7-uclibc r=nagisa Add new tier-3 target: armv7-unknown-linux-uclibceabihf This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org). The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward and graciously allowed me to take it over. Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md) I volunteer to be the ""target maintainer"". This is my first PR to Rust itself so I apologize if I've missed things!",HEART,2021-09-29T06:45:12Z,WooDzu,NA https://github.com/rust-lang/rust/pull/88952,MERGED,2021-09-15T01:18:14Z,2021-10-10T11:28:46Z,Add new tier-3 target: armv7-unknown-linux-uclibceabihf,skrap,9e8356c6adf119f983651d533d2b307544086cf9,9,"Auto merge of #88952 - skrap:add-armv7-uclibc r=nagisa Add new tier-3 target: armv7-unknown-linux-uclibceabihf This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org). The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward and graciously allowed me to take it over. Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md) I volunteer to be the ""target maintainer"". This is my first PR to Rust itself so I apologize if I've missed things!",THUMBS_UP,2021-09-29T07:12:21Z,pgasiorowski-es,NA https://github.com/rust-lang/rust/pull/88952,MERGED,2021-09-15T01:18:14Z,2021-10-10T11:28:46Z,Add new tier-3 target: armv7-unknown-linux-uclibceabihf,skrap,9e8356c6adf119f983651d533d2b307544086cf9,9,"Auto merge of #88952 - skrap:add-armv7-uclibc r=nagisa Add new tier-3 target: armv7-unknown-linux-uclibceabihf This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org). The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward and graciously allowed me to take it over. Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md) I volunteer to be the ""target maintainer"". This is my first PR to Rust itself so I apologize if I've missed things!",THUMBS_UP,2021-10-15T10:57:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-15T08:20:37Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-15T08:26:33Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-15T08:53:17Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-15T15:05:41Z,taiki-e,NA https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-15T15:16:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-16T11:07:06Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/88954,MERGED,2021-09-15T02:41:05Z,2021-09-17T18:48:35Z,"Allow `panic!(""{}"" computed_str)` in const fn.",nbdd0121,eb62779f2d6dc5cfe9208416e13392744b4e76ac,14,"Rollup merge of #88954 - nbdd0121:panic3 r=oli-obk Allow `panic!(""{}"" computed_str)` in const fn. Special-case `panic!(""{}"" arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!(""{}"" arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`",HOORAY,2021-09-23T04:45:41Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88965,MERGED,2021-09-15T13:29:49Z,2021-09-18T03:06:18Z,Fast reject for NeedsNonConstDrop,fee1-dead,8e398f5ba77b283b529c0c61cc2313c4f82d61dd,1,Auto merge of #88965 - fee1-dead:const-drop-1 r=oli-obk Fast reject for NeedsNonConstDrop Hopefully fixes the regression in #88558. I've always wanted to help with the performance of rustc but it doesn't feel the same when you are fixing a regression caused by your own PR... r? `@oli-obk`,LAUGH,2021-09-15T14:27:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88965,MERGED,2021-09-15T13:29:49Z,2021-09-18T03:06:18Z,Fast reject for NeedsNonConstDrop,fee1-dead,8e398f5ba77b283b529c0c61cc2313c4f82d61dd,1,Auto merge of #88965 - fee1-dead:const-drop-1 r=oli-obk Fast reject for NeedsNonConstDrop Hopefully fixes the regression in #88558. I've always wanted to help with the performance of rustc but it doesn't feel the same when you are fixing a regression caused by your own PR... r? `@oli-obk`,LAUGH,2021-09-15T14:44:58Z,oli-obk,NA https://github.com/rust-lang/rust/pull/88965,MERGED,2021-09-15T13:29:49Z,2021-09-18T03:06:18Z,Fast reject for NeedsNonConstDrop,fee1-dead,8e398f5ba77b283b529c0c61cc2313c4f82d61dd,1,Auto merge of #88965 - fee1-dead:const-drop-1 r=oli-obk Fast reject for NeedsNonConstDrop Hopefully fixes the regression in #88558. I've always wanted to help with the performance of rustc but it doesn't feel the same when you are fixing a regression caused by your own PR... r? `@oli-obk`,LAUGH,2021-09-15T19:40:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88965,MERGED,2021-09-15T13:29:49Z,2021-09-18T03:06:18Z,Fast reject for NeedsNonConstDrop,fee1-dead,8e398f5ba77b283b529c0c61cc2313c4f82d61dd,1,Auto merge of #88965 - fee1-dead:const-drop-1 r=oli-obk Fast reject for NeedsNonConstDrop Hopefully fixes the regression in #88558. I've always wanted to help with the performance of rustc but it doesn't feel the same when you are fixing a regression caused by your own PR... r? `@oli-obk`,LAUGH,2021-09-23T09:51:57Z,tux3,NA https://github.com/rust-lang/rust/pull/88973,MERGED,2021-09-15T15:19:14Z,2021-09-26T05:15:19Z,Expose the std_detect env_override feature,lu-zero,f9d4eb0ae3014d5f949c2e088536f8571a967a15,2,Rollup merge of #88973 - lu-zero:std_detect-env_override r=Amanieu Expose the std_detect env_override feature,THUMBS_UP,2021-09-24T20:11:03Z,master-of-zen,NA https://github.com/rust-lang/rust/pull/88973,MERGED,2021-09-15T15:19:14Z,2021-09-26T05:15:19Z,Expose the std_detect env_override feature,lu-zero,f9d4eb0ae3014d5f949c2e088536f8571a967a15,2,Rollup merge of #88973 - lu-zero:std_detect-env_override r=Amanieu Expose the std_detect env_override feature,THUMBS_UP,2021-09-24T20:15:50Z,tdaede,daede003@umn.edu https://github.com/rust-lang/rust/pull/88973,MERGED,2021-09-15T15:19:14Z,2021-09-26T05:15:19Z,Expose the std_detect env_override feature,lu-zero,f9d4eb0ae3014d5f949c2e088536f8571a967a15,2,Rollup merge of #88973 - lu-zero:std_detect-env_override r=Amanieu Expose the std_detect env_override feature,HOORAY,2021-09-24T20:16:28Z,master-of-zen,NA https://github.com/rust-lang/rust/pull/88973,MERGED,2021-09-15T15:19:14Z,2021-09-26T05:15:19Z,Expose the std_detect env_override feature,lu-zero,f9d4eb0ae3014d5f949c2e088536f8571a967a15,2,Rollup merge of #88973 - lu-zero:std_detect-env_override r=Amanieu Expose the std_detect env_override feature,ROCKET,2021-09-24T20:16:29Z,master-of-zen,NA https://github.com/rust-lang/rust/pull/88973,MERGED,2021-09-15T15:19:14Z,2021-09-26T05:15:19Z,Expose the std_detect env_override feature,lu-zero,f9d4eb0ae3014d5f949c2e088536f8571a967a15,2,Rollup merge of #88973 - lu-zero:std_detect-env_override r=Amanieu Expose the std_detect env_override feature,THUMBS_UP,2021-09-24T20:16:34Z,vibhoothi,vbhthi@tcd.ie https://github.com/rust-lang/rust/pull/88988,MERGED,2021-09-15T18:59:50Z,2021-09-18T11:56:27Z,Avoid codegen for Result::into_ok in lang_start,Mark-Simulacrum,6cdd42f9f8dd4e5e5ba0aa816bc4c99ab8b102f9,1,Auto merge of #88988 - Mark-Simulacrum:avoid-into-ok r=nagisa Avoid codegen for Result::into_ok in lang_start This extra codegen seems to be the cause for the regressions in max-rss on #86034. While LLVM will certainly optimize the dead code away avoiding it's generation in the first place seems good particularly when it is so simple. #86034 produced this [diff](https://gist.github.com/Mark-Simulacrum/95c7599883093af3b960c35ffadf4dab#file-86034-diff) for a simple `fn main() {}`. With this PR that diff [becomes limited to just a few extra IR instructions](https://gist.github.com/Mark-Simulacrum/95c7599883093af3b960c35ffadf4dab#file-88988-from-pre-diff) -- no extra functions. Note that these are pre-optimization; LLVM surely will eliminate this during optimization. However that optimization can end up generating more work and bump memory usage and this eliminates that.,THUMBS_UP,2021-09-16T13:49:25Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/88990,CLOSED,2021-09-15T20:57:34Z,2021-10-05T01:32:42Z,core::num::NonZero type alias,dtolnay,NA,NA,NA,THUMBS_UP,2021-09-16T05:13:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/88990,CLOSED,2021-09-15T20:57:34Z,2021-10-05T01:32:42Z,core::num::NonZero type alias,dtolnay,NA,NA,NA,THUMBS_UP,2021-09-28T23:18:05Z,Milo123459,NA https://github.com/rust-lang/rust/pull/88990,CLOSED,2021-09-15T20:57:34Z,2021-10-05T01:32:42Z,core::num::NonZero type alias,dtolnay,NA,NA,NA,THUMBS_UP,2021-10-03T14:48:57Z,lopopolo,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-15T22:33:13Z,Turbo87,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T04:15:27Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T04:34:16Z,kvark,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T05:01:56Z,cwfitzgerald,connorwadefitzgerald@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T05:48:23Z,cart,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T06:47:20Z,erlend-sh,e.soghe@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T09:01:43Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-16T09:01:46Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T11:49:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T12:07:22Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-16T12:07:23Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T13:29:12Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-16T15:01:49Z,r00ster91,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-16T18:27:32Z,kellytk,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-17T22:53:17Z,not-wlan,not-wlan@protonmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-17T22:53:18Z,not-wlan,not-wlan@protonmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-22T00:56:57Z,XorTroll,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-22T00:56:58Z,XorTroll,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-23T04:31:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-23T20:14:41Z,mklan,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-23T20:14:42Z,mklan,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-28T16:41:17Z,estebank,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-29T05:20:25Z,DjDeveloperr,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-29T05:20:26Z,DjDeveloperr,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-29T05:44:39Z,MierenManz,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-09-29T21:37:15Z,Milo123459,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-09-29T21:37:16Z,Milo123459,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-10-22T08:54:52Z,spacemeowx2,spacemeowx2@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-10-22T08:54:53Z,spacemeowx2,spacemeowx2@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-10-22T16:14:12Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-10-22T16:14:13Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-11-11T12:32:20Z,Gordon-F,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-11-24T13:48:40Z,GuilhermeWerner,guilherme.werner@outlook.com https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-12-02T18:04:57Z,dasifefe,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-12-02T18:04:58Z,dasifefe,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-12-03T07:56:56Z,Skirmisher,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-12-03T07:56:57Z,Skirmisher,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-12-04T12:08:17Z,l-Luna,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,ROCKET,2021-12-04T12:08:18Z,l-Luna,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2021-12-04T18:02:52Z,CodingKoopa,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2022-03-23T17:18:27Z,bb010g,NA https://github.com/rust-lang/rust/pull/88991,OPEN,2021-09-15T21:42:28Z,NA,Add Nintendo Switch as tier 3 target,jam1garner,NA,NA,NA,HEART,2022-04-13T19:27:13Z,anmart,andrewrmartinek@gmail.com https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,HOORAY,2021-09-16T10:09:48Z,lu-zero,NA https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,THUMBS_UP,2021-09-16T11:47:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,HOORAY,2021-09-16T14:15:33Z,bjorn3,NA https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,HEART,2021-09-16T14:15:38Z,bjorn3,NA https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,HOORAY,2021-09-17T14:18:22Z,est31,NA https://github.com/rust-lang/rust/pull/89004,CLOSED,2021-09-16T07:54:16Z,2022-01-19T14:06:55Z,Add convenience API to std::process::Command,matklad,NA,NA,NA,HEART,2021-10-06T16:48:26Z,ijackson,ijackson@chiark.greenend.org.uk https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,HEART,2021-09-17T17:18:56Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,HEART,2021-09-17T22:44:19Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,HEART,2021-09-17T22:50:47Z,Kolsky,NA https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,HEART,2021-09-17T22:56:26Z,sschiz,mcldresner@protonmail.com https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,THUMBS_UP,2021-09-17T23:10:08Z,ikrivosheev,py.krivosheev@gmail.com https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,HEART,2021-09-18T06:33:00Z,frol,NA https://github.com/rust-lang/rust/pull/89011,MERGED,2021-09-16T13:31:01Z,2021-09-29T20:51:08Z,Restructure std::rt,bjorn3,11491938f80988c7261a1179cf71a25c379c8783,8,Auto merge of #89011 - bjorn3:restructure_rt r=dtolnay Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.,THUMBS_UP,2021-09-24T07:25:53Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/89012,MERGED,2021-09-16T14:04:34Z,2021-09-17T18:48:35Z,Suggest removing `#![feature]` for library features that have been stabilized,vishadGoyal,101a88f95064b21a3de26f2d3e932408fa9e1c97,2,Rollup merge of #89012 - vishadGoyal:issue-88802-fix r=jyn514 Suggest removing `#![feature]` for library features that have been stabilized Issue: https://github.com/rust-lang/rust/issues/88802 Delayed the check if #![feature] has been used to enable lib features in a non-nightly build to occur after TyCtxt has been constructed.,HEART,2021-09-16T20:27:05Z,est31,NA https://github.com/rust-lang/rust/pull/89012,MERGED,2021-09-16T14:04:34Z,2021-09-17T18:48:35Z,Suggest removing `#![feature]` for library features that have been stabilized,vishadGoyal,101a88f95064b21a3de26f2d3e932408fa9e1c97,2,Rollup merge of #89012 - vishadGoyal:issue-88802-fix r=jyn514 Suggest removing `#![feature]` for library features that have been stabilized Issue: https://github.com/rust-lang/rust/issues/88802 Delayed the check if #![feature] has been used to enable lib features in a non-nightly build to occur after TyCtxt has been constructed.,HEART,2021-09-23T04:44:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89012,MERGED,2021-09-16T14:04:34Z,2021-09-17T18:48:35Z,Suggest removing `#![feature]` for library features that have been stabilized,vishadGoyal,101a88f95064b21a3de26f2d3e932408fa9e1c97,2,Rollup merge of #89012 - vishadGoyal:issue-88802-fix r=jyn514 Suggest removing `#![feature]` for library features that have been stabilized Issue: https://github.com/rust-lang/rust/issues/88802 Delayed the check if #![feature] has been used to enable lib features in a non-nightly build to occur after TyCtxt has been constructed.,THUMBS_UP,2021-09-23T23:41:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89021,MERGED,2021-09-16T18:36:52Z,2021-09-19T13:44:17Z,Add a separate error for `dyn Trait` in `const fn`,WaffleLapkin,61bfe3653b3dd792db589457a7c91a31c3dfa83b,8,"Rollup merge of #89021 - WaffleLapkin:separate_error_for_dyn_trait_in_const_fn r=estebank Add a separate error for `dyn Trait` in `const fn` Previously ""trait bounds other than `Sized` on const fn parameters are unstable"" error was used for both trait bounds (``) and trait objects (`dyn Trait`). This was pretty confusing. This PR adds a separate error for trait objects: ""trait objects in const fn are unstable"". The error for trait bounds is otherwise intact. This is follow up to #88907 r? ``@estebank`` ``@rustbot`` label: +A-diagnostics",THUMBS_UP,2021-09-24T06:46:44Z,thecaralice,github@alice-carroll.pet https://github.com/rust-lang/rust/pull/89025,MERGED,2021-09-16T20:58:04Z,2021-10-08T09:04:09Z,Implement `#[link_ordinal(n)]`,ricobbe,6c17601a2e6fa55e5d2ec7284359bee931c0c61a,20,"Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal r=michaelwoerister Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = ""raw-dylib"")]` allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.",HEART,2021-09-17T12:02:41Z,est31,NA https://github.com/rust-lang/rust/pull/89025,MERGED,2021-09-16T20:58:04Z,2021-10-08T09:04:09Z,Implement `#[link_ordinal(n)]`,ricobbe,6c17601a2e6fa55e5d2ec7284359bee931c0c61a,20,"Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal r=michaelwoerister Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = ""raw-dylib"")]` allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.",HEART,2021-09-19T18:04:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89025,MERGED,2021-09-16T20:58:04Z,2021-10-08T09:04:09Z,Implement `#[link_ordinal(n)]`,ricobbe,6c17601a2e6fa55e5d2ec7284359bee931c0c61a,20,"Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal r=michaelwoerister Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = ""raw-dylib"")]` allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.",HEART,2021-09-20T22:07:30Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/89025,MERGED,2021-09-16T20:58:04Z,2021-10-08T09:04:09Z,Implement `#[link_ordinal(n)]`,ricobbe,6c17601a2e6fa55e5d2ec7284359bee931c0c61a,20,"Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal r=michaelwoerister Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = ""raw-dylib"")]` allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.",HEART,2021-10-20T19:42:48Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/89025,MERGED,2021-09-16T20:58:04Z,2021-10-08T09:04:09Z,Implement `#[link_ordinal(n)]`,ricobbe,6c17601a2e6fa55e5d2ec7284359bee931c0c61a,20,"Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal r=michaelwoerister Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = ""raw-dylib"")]` allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.",HEART,2022-02-11T12:38:18Z,pro465,NA https://github.com/rust-lang/rust/pull/89041,MERGED,2021-09-17T12:25:20Z,2021-09-22T22:38:08Z,Work around invalid DWARF bugs for fat LTO,sticnarf,1deef1f75d0761256578508c1b398718e121d094,3,Rollup merge of #89041 - sticnarf:sticnarf/fat-lto-dwarf r=nagisa Work around invalid DWARF bugs for fat LTO This PR applies the same workaround in #46772 to fat LTO. It seems to fix the bug reported in https://github.com/rust-lang/rust/issues/66118#issuecomment-917434036.,ROCKET,2021-09-17T12:39:23Z,waynexia,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,THUMBS_DOWN,2021-09-17T14:41:10Z,kennytm,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,CONFUSED,2021-09-17T18:35:33Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,THUMBS_DOWN,2021-09-17T18:35:49Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,THUMBS_DOWN,2021-09-17T22:25:59Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,THUMBS_DOWN,2021-09-18T21:54:28Z,connorskees,NA https://github.com/rust-lang/rust/pull/89043,CLOSED,2021-09-17T13:21:55Z,2021-09-24T03:47:41Z,Add Result::check analogous to Option::filter,SoniEx2,NA,NA,NA,CONFUSED,2021-09-23T13:41:13Z,SadiinsoSnowfall,NA https://github.com/rust-lang/rust/pull/89055,MERGED,2021-09-17T20:20:21Z,2021-09-19T13:44:17Z,Suggest better place to add call parentheses for method expressions wrapped in parentheses,Kobzol,441046af978c99e777aacd98d0efc559d72f2195,5,Rollup merge of #89055 - Kobzol:wrapped-method-expr-call-parens r=wesleywiser Suggest better place to add call parentheses for method expressions wrapped in parentheses I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression. Fixes: https://github.com/rust-lang/rust/issues/89044,THUMBS_UP,2021-09-28T05:08:44Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/89056,OPEN,2021-09-17T22:01:38Z,NA,make member constraints pick static if no upper bounds,nikomatsakis,NA,NA,NA,HOORAY,2021-09-17T22:36:58Z,mati865,NA https://github.com/rust-lang/rust/pull/89056,OPEN,2021-09-17T22:01:38Z,NA,make member constraints pick static if no upper bounds,nikomatsakis,NA,NA,NA,THUMBS_UP,2021-09-17T23:33:24Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/89056,OPEN,2021-09-17T22:01:38Z,NA,make member constraints pick static if no upper bounds,nikomatsakis,NA,NA,NA,HOORAY,2021-09-17T23:36:47Z,sfackler,NA https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-18T21:04:16Z,panaman67,NA https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-19T03:02:34Z,MggMuggins,mggmugginsmc@gmail.com https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-19T18:25:04Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-19T19:38:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-20T17:15:27Z,jackpot51,jackpot51@gmail.com https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-09-30T22:23:40Z,npmccallum,nathaniel@mccallum.life https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-10-02T21:40:37Z,GuilhermeWerner,guilherme.werner@outlook.com https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-10-30T09:47:22Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2021-11-02T10:41:07Z,a1phyr,NA https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2022-01-13T19:18:25Z,rrbutani,NA https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2022-01-13T19:55:28Z,DianaNites,NA https://github.com/rust-lang/rust/pull/89062,MERGED,2021-09-18T06:10:17Z,2021-10-31T22:05:50Z,Add new tier 3 target: `x86_64-unknown-none`,mikeleany,ff0e14829e1806ca0d4226595f7fdf3e8658758f,5,"Auto merge of #89062 - mikeleany:new-target r=cjgillot Add new tier 3 target: `x86_64-unknown-none` Adds support for compiling OS kernels or other bare-metal applications for the x86-64 architecture. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. >If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",HEART,2022-01-19T15:50:10Z,GamePad64,alex@shishenko.com https://github.com/rust-lang/rust/pull/89079,MERGED,2021-09-18T20:59:17Z,2021-09-19T01:38:24Z,Update cargo,ehuss,e20a4ec1340f538296b4c81c4b00ef8fa64b7350,2,Auto merge of #89079 - ehuss:update-cargo r=ehuss Update cargo 1 commits in 33ee5f82edb50af87b952c5b28de0f5fb41ebf18..9a28ac83c9eb73e42ffafac552c0a55f00dbf40c 2021-09-17 13:51:54 +0000 to 2021-09-18 15:42:28 -0500 - Temporarily revert curl-sys update. (rust-lang/cargo#9920),HEART,2021-09-19T00:45:28Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/89082,MERGED,2021-09-18T22:27:33Z,2021-10-08T09:04:09Z,Implement #85440 (Random test ordering),smoelius,37f17bca7ccca0b393a58c87bb87bac18f371f61,14,"Rollup merge of #89082 - smoelius:master r=kennytm Implement #85440 (Random test ordering) This PR adds `--shuffle` and `--shuffle-seed` options to `libtest`. The options are similar to the [`-shuffle` option](https://github.com/golang/go/blob/c894b442d1e5e150ad33fa3ce13dbfab1c037b3a/src/testing/testing.go#L1482-L1499) that was recently added to Go. Here are the relevant parts of the help message: ``` --shuffle Run tests in random order --shuffle-seed SEED Run tests in random order; seed the random number generator with SEED ... By default the tests are run in alphabetical order. Use --shuffle or set RUST_TEST_SHUFFLE to run the tests in random order. Pass the generated ""shuffle seed"" to --shuffle-seed (or set RUST_TEST_SHUFFLE_SEED) to run the tests in the same order again. Note that --shuffle and --shuffle-seed do not affect whether the tests are run in parallel. ``` Is an RFC needed for this?",THUMBS_UP,2021-09-19T00:09:44Z,mohe2015,NA https://github.com/rust-lang/rust/pull/89082,MERGED,2021-09-18T22:27:33Z,2021-10-08T09:04:09Z,Implement #85440 (Random test ordering),smoelius,37f17bca7ccca0b393a58c87bb87bac18f371f61,14,"Rollup merge of #89082 - smoelius:master r=kennytm Implement #85440 (Random test ordering) This PR adds `--shuffle` and `--shuffle-seed` options to `libtest`. The options are similar to the [`-shuffle` option](https://github.com/golang/go/blob/c894b442d1e5e150ad33fa3ce13dbfab1c037b3a/src/testing/testing.go#L1482-L1499) that was recently added to Go. Here are the relevant parts of the help message: ``` --shuffle Run tests in random order --shuffle-seed SEED Run tests in random order; seed the random number generator with SEED ... By default the tests are run in alphabetical order. Use --shuffle or set RUST_TEST_SHUFFLE to run the tests in random order. Pass the generated ""shuffle seed"" to --shuffle-seed (or set RUST_TEST_SHUFFLE_SEED) to run the tests in the same order again. Note that --shuffle and --shuffle-seed do not affect whether the tests are run in parallel. ``` Is an RFC needed for this?",THUMBS_UP,2021-10-15T03:35:11Z,lukechu10,NA https://github.com/rust-lang/rust/pull/89083,CLOSED,2021-09-18T22:38:56Z,2022-06-16T07:03:43Z,Upgrade the FreeBSD toolchain to version 12.2,asomers,NA,NA,NA,ROCKET,2021-09-22T15:41:50Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/89083,CLOSED,2021-09-18T22:38:56Z,2022-06-16T07:03:43Z,Upgrade the FreeBSD toolchain to version 12.2,asomers,NA,NA,NA,ROCKET,2022-02-13T09:11:10Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/89086,MERGED,2021-09-19T05:58:13Z,2021-09-22T00:37:53Z,Stabilize `Iterator::map_while`,WaffleLapkin,d7de8d2b53663f67b39f7d428b69f10df1711e05,7,Rollup merge of #89086 - WaffleLapkin:stabilize_iter_map_while r=kennytm Stabilize `Iterator::map_while` Per the FCP: https://github.com/rust-lang/rust/issues/68537#issuecomment-922385035 This PR stabilizes `Iterator::map_while` and `iter::MapWhile` in Rust 1.57.,HOORAY,2021-09-30T08:12:39Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/89086,MERGED,2021-09-19T05:58:13Z,2021-09-22T00:37:53Z,Stabilize `Iterator::map_while`,WaffleLapkin,d7de8d2b53663f67b39f7d428b69f10df1711e05,7,Rollup merge of #89086 - WaffleLapkin:stabilize_iter_map_while r=kennytm Stabilize `Iterator::map_while` Per the FCP: https://github.com/rust-lang/rust/issues/68537#issuecomment-922385035 This PR stabilizes `Iterator::map_while` and `iter::MapWhile` in Rust 1.57.,HOORAY,2021-09-30T18:05:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89086,MERGED,2021-09-19T05:58:13Z,2021-09-22T00:37:53Z,Stabilize `Iterator::map_while`,WaffleLapkin,d7de8d2b53663f67b39f7d428b69f10df1711e05,7,Rollup merge of #89086 - WaffleLapkin:stabilize_iter_map_while r=kennytm Stabilize `Iterator::map_while` Per the FCP: https://github.com/rust-lang/rust/issues/68537#issuecomment-922385035 This PR stabilizes `Iterator::map_while` and `iter::MapWhile` in Rust 1.57.,HOORAY,2021-10-01T00:55:48Z,moy2010,NA https://github.com/rust-lang/rust/pull/89086,MERGED,2021-09-19T05:58:13Z,2021-09-22T00:37:53Z,Stabilize `Iterator::map_while`,WaffleLapkin,d7de8d2b53663f67b39f7d428b69f10df1711e05,7,Rollup merge of #89086 - WaffleLapkin:stabilize_iter_map_while r=kennytm Stabilize `Iterator::map_while` Per the FCP: https://github.com/rust-lang/rust/issues/68537#issuecomment-922385035 This PR stabilizes `Iterator::map_while` and `iter::MapWhile` in Rust 1.57.,HOORAY,2022-01-24T19:42:03Z,UltiRequiem,eliaz.bobadilladev@gmail.com https://github.com/rust-lang/rust/pull/89103,MERGED,2021-09-19T17:56:47Z,2021-09-21T22:07:39Z,Migrate in-tree crates to 2021,Mark-Simulacrum,ac2d9fc509e36d1b32513744adf58c34bcc4f43c,104,"Auto merge of #89103 - Mark-Simulacrum:migrate-2021 r=estebank Migrate in-tree crates to 2021 This replaces #89075 (cherry picking some of the commits from there) and closes #88637 and fixes #89074. It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there. I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first. Originally the intent was to support cargo fix --edition within bootstrap but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation and only resetting sysroots on check. Further it was found that cargo fix doesn't behave too well with ""not quite workspaces"" such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately. It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c877110748296760aefddc21a0ea1d316 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.",HEART,2021-09-19T22:17:05Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/89103,MERGED,2021-09-19T17:56:47Z,2021-09-21T22:07:39Z,Migrate in-tree crates to 2021,Mark-Simulacrum,ac2d9fc509e36d1b32513744adf58c34bcc4f43c,104,"Auto merge of #89103 - Mark-Simulacrum:migrate-2021 r=estebank Migrate in-tree crates to 2021 This replaces #89075 (cherry picking some of the commits from there) and closes #88637 and fixes #89074. It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there. I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first. Originally the intent was to support cargo fix --edition within bootstrap but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation and only resetting sysroots on check. Further it was found that cargo fix doesn't behave too well with ""not quite workspaces"" such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately. It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c877110748296760aefddc21a0ea1d316 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.",HEART,2021-09-20T15:38:18Z,estebank,NA https://github.com/rust-lang/rust/pull/89103,MERGED,2021-09-19T17:56:47Z,2021-09-21T22:07:39Z,Migrate in-tree crates to 2021,Mark-Simulacrum,ac2d9fc509e36d1b32513744adf58c34bcc4f43c,104,"Auto merge of #89103 - Mark-Simulacrum:migrate-2021 r=estebank Migrate in-tree crates to 2021 This replaces #89075 (cherry picking some of the commits from there) and closes #88637 and fixes #89074. It excludes a migration of the library crates for now (see tidy diff) because we have some pending bugs around macro spans to fix there. I instrumented bootstrap during the migration to make sure all crates moved from 2018 to 2021 had the compatibility warnings applied first. Originally the intent was to support cargo fix --edition within bootstrap but this proved fairly difficult to pull off. We'd need to architect the check functionality to support running cargo check and cargo fix within the same x.py invocation and only resetting sysroots on check. Further it was found that cargo fix doesn't behave too well with ""not quite workspaces"" such as Clippy which has several crates. Bootstrap runs with --manifest-path ... for all the tools and this makes cargo fix only attempt migration for that crate. We can't use e.g. --workspace due to needing to maintain sysroots for different phases of compilation appropriately. It is recommended to skip the mass migration of Cargo.toml's to 2021 for review purposes; you can also use `git diff d6cd2c6c877110748296760aefddc21a0ea1d316 -I'^edition = .20...$'` to ignore the edition = 2018/21 lines in the diff.",HEART,2021-09-21T16:31:10Z,mati865,NA https://github.com/rust-lang/rust/pull/89110,MERGED,2021-09-19T22:02:26Z,2021-09-30T04:51:49Z,Use larger span for adjustment THIR expressions,Aaron1011,4aa7879b559ccf7f82bcce2a8e532ea307697ea9,170,Auto merge of #89110 - Aaron1011:adjustment-span r=estebank Use larger span for adjustment THIR expressions Currently we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef autoborrow unsizing). As a result if a borrow generated by an adustment ends up causing a borrowcheck error for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`) rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation this doesn't always get exposed in migration mode but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions. These spans are recoded when we first create the adjustment during typecheck. For example an autoref adjustment triggered by a method call will record the span of the entire method call. The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example in a method call) that produdes a borrowcheck error. For example an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`) when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result several `.nll.stderr` files end up getting removed entirely.,ROCKET,2021-09-30T04:57:22Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/89114,MERGED,2021-09-20T07:08:14Z,2021-09-22T00:37:52Z,Fixes a technicality regarding the size of C's `char` type,dequbed,8a6e9cf07471672f75a24047b48131a547355106,1,"Rollup merge of #89114 - dequbed:c-char r=yaahc Fixes a technicality regarding the size of C's `char` type Specifically ISO/IEC 9899:2018 — better known as ""C18"" — (and at least C11 C99 and C89) do not specify the size of `byte` in bits. Section 3.6 defines ""byte"" as ""addressable unit of data storage"" while section 6.2.5 (""Types"") only defines ""char"" as ""large enough to store any member of the basic execution set"" giving it a lower bound of 7 bit (since there are 96 characters in the basic execution set). With section 6.5.3.4 paragraph 4 ""When sizeof is applied to an operant that has type char […] the result is 1"" you could read this as the size of `char` in bits being defined as exactly the same as the number of bits in a byte but it's also valid to read that as an exception. In general implementations take `char` as the smallest unit of addressable memory which for modern byte-addressed architectures is overwhelmingly 8 bits to the point of this convention being completely cemented into just about all of our software. So is any of this actually relevant at all? I hope not. I sincerely hope that this never ever comes up. But if for some reason a poor rustacean is having to interface with C code running on a Cray X1 that in 2003 is still doing word-addressed memory with 64-bit chars and they trust the docs here blindly it will blow up in her face. And I'll be truly sorry for her to have to deal with … all of that.",THUMBS_UP,2021-09-21T20:01:33Z,est31,NA https://github.com/rust-lang/rust/pull/89114,MERGED,2021-09-20T07:08:14Z,2021-09-22T00:37:52Z,Fixes a technicality regarding the size of C's `char` type,dequbed,8a6e9cf07471672f75a24047b48131a547355106,1,"Rollup merge of #89114 - dequbed:c-char r=yaahc Fixes a technicality regarding the size of C's `char` type Specifically ISO/IEC 9899:2018 — better known as ""C18"" — (and at least C11 C99 and C89) do not specify the size of `byte` in bits. Section 3.6 defines ""byte"" as ""addressable unit of data storage"" while section 6.2.5 (""Types"") only defines ""char"" as ""large enough to store any member of the basic execution set"" giving it a lower bound of 7 bit (since there are 96 characters in the basic execution set). With section 6.5.3.4 paragraph 4 ""When sizeof is applied to an operant that has type char […] the result is 1"" you could read this as the size of `char` in bits being defined as exactly the same as the number of bits in a byte but it's also valid to read that as an exception. In general implementations take `char` as the smallest unit of addressable memory which for modern byte-addressed architectures is overwhelmingly 8 bits to the point of this convention being completely cemented into just about all of our software. So is any of this actually relevant at all? I hope not. I sincerely hope that this never ever comes up. But if for some reason a poor rustacean is having to interface with C code running on a Cray X1 that in 2003 is still doing word-addressed memory with 64-bit chars and they trust the docs here blindly it will blow up in her face. And I'll be truly sorry for her to have to deal with … all of that.",LAUGH,2021-09-25T15:41:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,HEART,2021-09-20T20:24:16Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,HEART,2021-09-20T21:28:43Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2021-09-21T06:41:11Z,Lokathor,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2021-09-21T08:31:11Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2021-09-21T12:06:01Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,EYES,2021-09-23T04:18:31Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2021-10-28T17:41:37Z,danielg1111,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2021-12-21T01:19:26Z,AngelicosPhosphoros,NA https://github.com/rust-lang/rust/pull/89123,OPEN,2021-09-20T18:33:36Z,NA,add Vec::push_within_capacity - fallible does not allocate,the8472,NA,NA,NA,THUMBS_UP,2022-03-14T09:02:03Z,Skgland,NA https://github.com/rust-lang/rust/pull/89124,MERGED,2021-09-20T19:04:23Z,2021-10-18T23:02:55Z,Index and hash HIR as part of lowering,cjgillot,bd41e09da334697c0f993b36685cb599061d9faa,28,Auto merge of #89124 - cjgillot:owner-info r=michaelwoerister Index and hash HIR as part of lowering Part of https://github.com/rust-lang/rust/pull/88186 ~Based on https://github.com/rust-lang/rust/pull/88880 (see merge commit).~ Once HIR is lowered it is later indexed by the `index_hir` query and hashed for `crate_hash`. This PR moves those post-processing steps to lowering itself. As a side objective the HIR crate data structure is refactored as an `IndexVec>>` where `OwnerInfo` stores all the relevant information for an HIR owner. r? `@michaelwoerister` cc `@petrochenkov`,HOORAY,2021-09-20T20:04:35Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/89130,MERGED,2021-09-20T21:08:48Z,2021-09-24T11:54:29Z,Update LLVM submodule,nikic,91d8da1f4ba24679e92b7939a26c681a5d2d3548,1,Auto merge of #89130 - nikic:update-llvm-2 r=cuviper Update LLVM submodule This merges the upstream `release/13.x` branch to pull in the second fix for #88769.,HEART,2021-09-22T05:43:52Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2021-10-01T21:15:18Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2021-10-02T14:37:20Z,Wodann,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,HEART,2021-10-18T07:45:52Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2021-11-06T20:39:43Z,hkratz,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,HEART,2021-12-14T02:17:51Z,woppopo,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2022-01-12T02:27:22Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2022-01-16T20:36:59Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,HEART,2022-01-16T20:37:01Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2022-04-06T08:56:12Z,CyoeeA9e,NA https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2022-05-27T11:50:46Z,topisani,topisani@hamsterpoison.com https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,HEART,2022-05-27T11:50:46Z,topisani,topisani@hamsterpoison.com https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,THUMBS_UP,2022-06-15T10:43:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89132,OPEN,2021-09-20T23:11:10Z,NA,Add support for allocators in `Rc` & `Arc`,Cyborus04,NA,NA,NA,HEART,2022-06-15T10:43:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89145,MERGED,2021-09-21T09:26:53Z,2021-09-27T05:01:00Z,Update stdarch submodule,hkratz,c81c3ea321cfa9e760ba197da667584c234e9272,1,Auto merge of #89145 - rusticstuff:bump_stdarch r=kennytm Update stdarch submodule This is mainly to fix the critical issue of aarch64 store intrinsics overwriting additional memory see https://github.com/rust-lang/stdarch/issues/1220 Changes: * aarch64/armv7: additional vld1/vst1 intrinsics + perf fixes for existing ones * https://github.com/rust-lang/stdarch/pull/1205 * https://github.com/rust-lang/stdarch/pull/1207 * https://github.com/rust-lang/stdarch/pull/1216 * armv7: Make FMA work with vfpv4 and optimize * https://github.com/rust-lang/stdarch/pull/1219 * Non-visible changes to the testing framework * https://github.com/rust-lang/stdarch/pull/1208 * https://github.com/rust-lang/stdarch/pull/1211 * https://github.com/rust-lang/stdarch/pull/1213 * https://github.com/rust-lang/stdarch/pull/1215 * https://github.com/rust-lang/stdarch/pull/1218,HEART,2021-09-24T17:20:06Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/89148,MERGED,2021-09-21T13:41:03Z,2021-09-24T04:51:24Z,Suggest `_` in turbofish if param will be inferred from fn argument,estebank,9e11d1cca4ea724468ec1589c8d424397d7de4bd,4,Rollup merge of #89148 - estebank:used-type-param r=oli-obk Suggest `_` in turbofish if param will be inferred from fn argument,THUMBS_UP,2021-09-21T14:27:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89148,MERGED,2021-09-21T13:41:03Z,2021-09-24T04:51:24Z,Suggest `_` in turbofish if param will be inferred from fn argument,estebank,9e11d1cca4ea724468ec1589c8d424397d7de4bd,4,Rollup merge of #89148 - estebank:used-type-param r=oli-obk Suggest `_` in turbofish if param will be inferred from fn argument,THUMBS_UP,2021-09-23T01:38:36Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-22T10:40:41Z,zohnannor,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-22T11:15:15Z,Folyd,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-22T11:40:00Z,DmitryBochkarev,dimabochkarev@gmail.com https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-22T12:26:23Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,HEART,2021-09-22T15:23:25Z,little-dude,little-dude@mailbox.org https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,HEART,2021-09-22T18:06:22Z,camsteffen,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-23T10:10:17Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-23T13:03:37Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,HEART,2021-09-23T13:03:38Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2021-09-23T21:32:27Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2022-05-18T07:01:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89157,OPEN,2021-09-21T20:52:09Z,NA,Provide doc links at item definitions on source pages,GuillaumeGomez,NA,NA,NA,HEART,2022-05-18T07:01:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89164,MERGED,2021-09-22T02:18:51Z,2021-09-22T22:38:07Z,Document `--show-type-layout` in the rustdoc book,camelid,3cb28de23839f0dbe1088205a8bdc11170cec8bc,2,Rollup merge of #89164 - camelid:show-type-layout-docs r=jyn514 Document `--show-type-layout` in the rustdoc book I also made a few small related changes as separate commits. r? `@jyn514`,HEART,2021-09-22T02:34:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89165,MERGED,2021-09-22T02:55:10Z,2021-10-04T07:25:55Z,Fix read_to_end to not grow an exact size buffer,jkugelman,d25de31a0eeb14ab0c8c4613496fe2d3d9a085dd,3,"Auto merge of #89165 - jkugelman:read-to-end-overallocation r=joshtriplett Fix read_to_end to not grow an exact size buffer If you know how much data to expect and use `Vec::with_capacity` to pre-allocate a buffer of that capacity `Read::read_to_end` will still double its capacity. It needs some space to perform a read even though that read ends up returning `0`. It's a bummer to carefully pre-allocate 1GB to read a 1GB file into memory and end up using 2GB. This fixes that behavior by special casing a full buffer and reading into a small ""probe"" buffer instead. If that read returns `0` then it's confirmed that the buffer was the perfect size. If it doesn't the probe buffer is appended to the normal buffer and the read loop continues. Fixing this allows several workarounds in the standard library to be removed: - `Take` no longer needs to override `Read::read_to_end`. - The `reservation_size` callback that allowed `Take` to inhibit the previous over-allocation behavior isn't needed. - `fs::read` doesn't need to reserve an extra byte in `initial_buffer_size`. Curiously there was a unit test that specifically checked that `Read::read_to_end` *does* over-allocate. I removed that test too.",THUMBS_UP,2021-10-10T11:13:00Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/89165,MERGED,2021-09-22T02:55:10Z,2021-10-04T07:25:55Z,Fix read_to_end to not grow an exact size buffer,jkugelman,d25de31a0eeb14ab0c8c4613496fe2d3d9a085dd,3,"Auto merge of #89165 - jkugelman:read-to-end-overallocation r=joshtriplett Fix read_to_end to not grow an exact size buffer If you know how much data to expect and use `Vec::with_capacity` to pre-allocate a buffer of that capacity `Read::read_to_end` will still double its capacity. It needs some space to perform a read even though that read ends up returning `0`. It's a bummer to carefully pre-allocate 1GB to read a 1GB file into memory and end up using 2GB. This fixes that behavior by special casing a full buffer and reading into a small ""probe"" buffer instead. If that read returns `0` then it's confirmed that the buffer was the perfect size. If it doesn't the probe buffer is appended to the normal buffer and the read loop continues. Fixing this allows several workarounds in the standard library to be removed: - `Take` no longer needs to override `Read::read_to_end`. - The `reservation_size` callback that allowed `Take` to inhibit the previous over-allocation behavior isn't needed. - `fs::read` doesn't need to reserve an extra byte in `initial_buffer_size`. Curiously there was a unit test that specifically checked that `Read::read_to_end` *does* over-allocate. I removed that test too.",THUMBS_UP,2022-01-19T09:34:53Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T06:52:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T07:49:31Z,hkratz,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T13:40:12Z,darleybarreto,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T14:29:27Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T15:41:26Z,unrelentingtech,hello@unrelenting.technology https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T17:38:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T18:55:36Z,cayv,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T19:54:23Z,panaman67,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T23:07:24Z,calebzulawski,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-22T23:57:21Z,Sl1mb0,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T01:03:13Z,Hoverbear,operator@hoverbear.org https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,LAUGH,2021-09-23T04:04:19Z,timClicks,paperless@timmcnamara.co.nz https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T04:04:22Z,timClicks,paperless@timmcnamara.co.nz https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T05:42:39Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T06:48:46Z,bjorn3,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T08:15:02Z,lqd,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-23T11:50:51Z,darksv,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-26T22:20:51Z,a1phyr,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-27T16:31:14Z,ZippyMagician,zippymagician1@gmail.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-28T03:20:13Z,Mygod,contact-github@mygod.be https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-09-30T18:42:24Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-01T23:52:50Z,jamen,me@jamen.dev https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-05T08:03:11Z,KodrAus,kodraus@hey.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-05T13:40:26Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-11T20:24:08Z,ZuseZ4,git@manuel.drehwald.info https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-12T15:22:40Z,Jerboas86,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-18T03:52:23Z,ethanhs,ethan@ethanhs.me https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-22T08:36:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,EYES,2021-10-22T19:41:54Z,macpp,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,LAUGH,2021-10-25T14:26:41Z,pro465,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-10-25T14:26:44Z,pro465,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-12T22:59:29Z,evanrichter,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-13T22:30:09Z,Virgiel,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,LAUGH,2021-11-13T22:30:11Z,Virgiel,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,EYES,2021-11-13T22:30:11Z,Virgiel,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-14T02:22:08Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,HEART,2021-11-15T04:13:13Z,scottmcm,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-15T09:15:26Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,HEART,2021-11-15T23:58:56Z,Jasper-Bekkers,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-17T02:08:48Z,p--b,pb@fourieraudio.com https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-11-17T21:42:10Z,declanvk,NA https://github.com/rust-lang/rust/pull/89167,MERGED,2021-09-22T05:30:25Z,2021-11-13T05:19:46Z,pub use core::simd;,workingjubilee,032dfe43605f4324966933078ffe6f717b77c7c8,89,Auto merge of #89167 - workingjubilee:use-simd r=MarkSimulacrum pub use core::simd; A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust `std::arch` offers explicit SIMD acceleration via compiler intrinsics but it does so at the cost of having to individually maintain each and every single such API and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation including scalar instructions if that is all that is available. `core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets features and optimizations produce the same result so that using this library does not introduce any surprises. As these tests are technically non-deterministic and thus can introduce overly interesting Heisenbugs if included in the rustc CI they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation but these use deterministic asserts. There are multiple unsolved problems with the library at the current moment including a want for better documentation technical issues with LLVM scalarizing and lowering to libm room for improvement for the APIs and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However I thought it would be prudent to open this for review in its current condition as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out. The major types are - `core::simd::Simd` - `core::simd::Mask` There is also the `LaneCount` struct which together with the SimdElement and SupportedLaneCount traits limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.,ROCKET,2021-12-16T23:45:16Z,tmandry,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,ROCKET,2021-09-22T15:39:46Z,hkratz,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,ROCKET,2021-10-12T04:48:34Z,dmitry-zakablukov,dmitriy.zakablukov@gmail.com https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,THUMBS_UP,2021-10-12T04:48:38Z,dmitry-zakablukov,dmitriy.zakablukov@gmail.com https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,ROCKET,2021-10-22T13:50:16Z,KapJI,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,THUMBS_UP,2021-11-02T12:02:46Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,ROCKET,2021-11-02T12:02:47Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,HEART,2021-12-31T20:30:30Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,HEART,2022-01-03T19:02:43Z,Giovanni-Tably,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,THUMBS_UP,2022-01-13T17:33:01Z,lebensterben,NA https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,HEART,2022-01-14T03:16:14Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,THUMBS_UP,2022-01-14T03:16:18Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,ROCKET,2022-01-14T03:16:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89174,MERGED,2021-09-22T13:37:12Z,2021-10-30T10:32:14Z,Automatically convert paths to verbatim for filesystem operations that support it,ChrisDenton,2b643e987173b36cb0279a018579372e31a35776,5,Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths r=dtolnay Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689,THUMBS_UP,2022-05-10T14:06:41Z,FliegendeWurst,2012gdwu+github@posteo.de https://github.com/rust-lang/rust/pull/89199,CLOSED,2021-09-23T08:31:24Z,2021-10-08T08:41:51Z,Add docs to Box conversions,timClicks,NA,NA,NA,HEART,2021-09-23T09:28:24Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/89202,MERGED,2021-09-23T11:38:54Z,2021-10-01T06:19:59Z,Resolve infered types when complaining about unexpected call type ,estebank,b437be45ea74905298b046b521a328b0d7899511,3,Rollup merge of #89202 - estebank:infer-call-type r=oli-obk Resolve infered types when complaining about unexpected call type ``` error[E0618]: expected function found `{integer}` --> $DIR/call-block.rs:2:13 | LL | let _ = {42}(); | ^^^^-- | | | call expression requires function ``` instead of ``` error[E0618]: expected function found `_` --> $DIR/call-block.rs:2:13 | LL | let _ = {42}(); | ^^^^-- | | | call expression requires function ```,HEART,2021-09-23T18:28:31Z,ben0x539,NA https://github.com/rust-lang/rust/pull/89202,MERGED,2021-09-23T11:38:54Z,2021-10-01T06:19:59Z,Resolve infered types when complaining about unexpected call type ,estebank,b437be45ea74905298b046b521a328b0d7899511,3,Rollup merge of #89202 - estebank:infer-call-type r=oli-obk Resolve infered types when complaining about unexpected call type ``` error[E0618]: expected function found `{integer}` --> $DIR/call-block.rs:2:13 | LL | let _ = {42}(); | ^^^^-- | | | call expression requires function ``` instead of ``` error[E0618]: expected function found `_` --> $DIR/call-block.rs:2:13 | LL | let _ = {42}(); | ^^^^-- | | | call expression requires function ```,HEART,2021-09-24T01:33:26Z,Hamled,hamled@hamled.dev https://github.com/rust-lang/rust/pull/89213,CLOSED,2021-09-24T08:54:03Z,2022-07-08T15:07:44Z,WIP: Avoid storing captured upvars in generators twice if possible,Kobzol,NA,NA,NA,THUMBS_UP,2021-11-16T07:08:40Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/89214,MERGED,2021-09-24T09:27:32Z,2021-09-27T21:29:25Z,Pass real crate-level attributes to `pre_expansion_lint`,smoelius,98c8619502093f34ca82f8f26ccf32e753924440,5,"Auto merge of #89214 - smoelius:register_tool r=petrochenkov Pass real crate-level attributes to `pre_expansion_lint` The PR concerns the unstable feature `register_tool` (#66079). The feature's implementation requires the attributes of the crate being compiled so that when attributes like `allow(foo::bar)` are encountered it can be verified that `register_tool(foo)` appears in the crate root. However the crate's attributes are not readily available during early lint passes. Specifically on this line `krate.attrs` appears to be the attributes of the current source file not the attributes of the whole crate: https://github.com/rust-lang/rust/blob/bf642323d621dcefeef1d8ab4711aae36e357615/compiler/rustc_lint/src/context.rs#L815 Consequently ""unknown tool"" errors were being produced when `allow(foo::bar)` appeared in a submodule even though `register_tool(foo)` appeared in the crate root. EDITED: The proposed fix is to obtain the real crate-level attributes in `configure_and_expand` and pass them to `pre_expansion_lint`. (See `@petrochenkov's` [comment](https://github.com/rust-lang/rust/pull/89214#issuecomment-926927072) below.) The original ""prosed fix"" text follows. --- The proposed fix is to add an `error_on_unknown_tool` flag to `LintLevelsBuilder`. The flag controls whether ""unknown tool"" errors are emitted. The flag is set during late passes but not earlier. More specifically this PR contains two commits: * The first adds a `known-tool-in-submodule` UI test that does not currently pass. * The second adds the `error_on_unknown_tool` flag. The new test passes with the addition of this flag. This change has the added benefit of eliminating some errors that were duplicated in existing tests. To the reviewer: please check that I implemented the UI test correctly.",THUMBS_UP,2021-09-24T13:18:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89221,MERGED,2021-09-24T12:39:06Z,2021-09-25T03:06:12Z,Give better error for `macro_rules! name!`,aDotInTheVoid,6f31fa58fd0c4c045f4dd71170868750739e1135,4,Rollup merge of #89221 - aDotInTheVoid:macro-error-1 r=estebank Give better error for `macro_rules! name!` r? ``@estebank`` ``@rustbot`` modify labels: +A-diagnostics +A-parser,THUMBS_UP,2021-09-24T13:24:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89221,MERGED,2021-09-24T12:39:06Z,2021-09-25T03:06:12Z,Give better error for `macro_rules! name!`,aDotInTheVoid,6f31fa58fd0c4c045f4dd71170868750739e1135,4,Rollup merge of #89221 - aDotInTheVoid:macro-error-1 r=estebank Give better error for `macro_rules! name!` r? ``@estebank`` ``@rustbot`` modify labels: +A-diagnostics +A-parser,THUMBS_UP,2021-09-24T14:44:49Z,estebank,NA https://github.com/rust-lang/rust/pull/89224,MERGED,2021-09-24T15:24:48Z,2021-09-26T05:15:18Z,Change the order of imports suggestions,TaKO8Ki,04d3f93a2b5ff2f34ad4921909caf79ab19676c0,2,Rollup merge of #89224 - TaKO8Ki:change-the-order-of-suggestions r=joshtriplett Change the order of imports suggestions closes #83564,THUMBS_UP,2021-09-24T21:58:39Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/89233,MERGED,2021-09-24T20:45:28Z,2021-09-29T13:27:16Z,Hide `<...> defined here` note if the source is not available,FabianWolff,3c60e040b29c6b9cbf0ed1df31d7469d4634ac4d,1,Rollup merge of #89233 - FabianWolff:issue-89159 r=estebank Hide `<...> defined here` note if the source is not available Fixes #89159. Similar to #87088. r? ``@estebank``,HEART,2021-09-25T13:32:45Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/89247,MERGED,2021-09-25T15:59:14Z,2021-10-14T12:57:35Z,Add `const_eval_select` intrinsic ,fee1-dead,c34ac8747ca96d09cb08b8f5adddead826e77c06,22,Auto merge of #89247 - fee1-dead:const-eval-select r=oli-obk Add `const_eval_select` intrinsic Adds an intrinsic that calls a given function when evaluated at compiler time but generates a call to another function when called at runtime. See https://github.com/rust-lang/const-eval/issues/7 for previous discussion. r? `@oli-obk.`,THUMBS_UP,2021-09-25T20:08:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89248,MERGED,2021-09-25T15:59:45Z,2021-10-01T06:19:59Z,Suggest similarly named associated items in trait impls,hkmatsumoto,837ac877091b540d95ee6a75a29e29cb64894d7e,8,Rollup merge of #89248 - hkmatsumoto:suggest-similarly-named-assoc-items r=estebank Suggest similarly named associated items in trait impls Fix #85942 Previously the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions types and constants.,HEART,2021-09-26T16:40:02Z,estebank,NA https://github.com/rust-lang/rust/pull/89248,MERGED,2021-09-25T15:59:45Z,2021-10-01T06:19:59Z,Suggest similarly named associated items in trait impls,hkmatsumoto,837ac877091b540d95ee6a75a29e29cb64894d7e,8,Rollup merge of #89248 - hkmatsumoto:suggest-similarly-named-assoc-items r=estebank Suggest similarly named associated items in trait impls Fix #85942 Previously the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions types and constants.,HEART,2021-09-26T19:00:55Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/89249,MERGED,2021-09-25T16:40:58Z,2021-09-28T00:21:14Z,Improve cause information for NLL higher-ranked errors,Aaron1011,8a12be741290b16c29293f87bdb3e8e5129bd4a9,16,"Auto merge of #89249 - Aaron1011:higher-ranked-cause r=estebank Improve cause information for NLL higher-ranked errors This PR has several interconnected pieces: 1. In some of the NLL region error code we now pass around an `ObligationCause` instead of just a plain `Span`. This gets forwarded into `fulfill_cx.register_predicate_obligation` during error reporting. 2. The general InferCtxt error reporting code is extended to handle `ObligationCauseCode::BindingObligation` 3. A new enum variant `ConstraintCategory::Predicate` is added. We try to avoid using this as the 'best blame constraint' - instead we use it to enhance the `ObligationCause` of the `BlameConstraint` that we do end up choosing. As a result several NLL error messages now contain the same ""the lifetime requirement is introduced here"" message as non-NLL errors. Having an `ObligationCause` available will likely prove useful for future improvements to NLL error messages.",HEART,2021-09-26T16:56:36Z,estebank,NA https://github.com/rust-lang/rust/pull/89249,MERGED,2021-09-25T16:40:58Z,2021-09-28T00:21:14Z,Improve cause information for NLL higher-ranked errors,Aaron1011,8a12be741290b16c29293f87bdb3e8e5129bd4a9,16,"Auto merge of #89249 - Aaron1011:higher-ranked-cause r=estebank Improve cause information for NLL higher-ranked errors This PR has several interconnected pieces: 1. In some of the NLL region error code we now pass around an `ObligationCause` instead of just a plain `Span`. This gets forwarded into `fulfill_cx.register_predicate_obligation` during error reporting. 2. The general InferCtxt error reporting code is extended to handle `ObligationCauseCode::BindingObligation` 3. A new enum variant `ConstraintCategory::Predicate` is added. We try to avoid using this as the 'best blame constraint' - instead we use it to enhance the `ObligationCause` of the `BlameConstraint` that we do end up choosing. As a result several NLL error messages now contain the same ""the lifetime requirement is introduced here"" message as non-NLL errors. Having an `ObligationCause` available will likely prove useful for future improvements to NLL error messages.",HEART,2021-09-26T18:27:10Z,lqd,NA https://github.com/rust-lang/rust/pull/89251,MERGED,2021-09-25T18:24:44Z,2021-10-01T11:44:13Z,Detect when negative literal indices are used and suggest appropriate code,estebank,e77d163e82b2b6680322085c421c438cf60a7bc6,5,Rollup merge of #89251 - estebank:negative-index-literals r=davidtwco Detect when negative literal indices are used and suggest appropriate code,HEART,2021-09-26T09:37:18Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/89251,MERGED,2021-09-25T18:24:44Z,2021-10-01T11:44:13Z,Detect when negative literal indices are used and suggest appropriate code,estebank,e77d163e82b2b6680322085c421c438cf60a7bc6,5,Rollup merge of #89251 - estebank:negative-index-literals r=davidtwco Detect when negative literal indices are used and suggest appropriate code,HEART,2021-09-26T11:14:09Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/89251,MERGED,2021-09-25T18:24:44Z,2021-10-01T11:44:13Z,Detect when negative literal indices are used and suggest appropriate code,estebank,e77d163e82b2b6680322085c421c438cf60a7bc6,5,Rollup merge of #89251 - estebank:negative-index-literals r=davidtwco Detect when negative literal indices are used and suggest appropriate code,HEART,2021-09-26T19:10:56Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/89251,MERGED,2021-09-25T18:24:44Z,2021-10-01T11:44:13Z,Detect when negative literal indices are used and suggest appropriate code,estebank,e77d163e82b2b6680322085c421c438cf60a7bc6,5,Rollup merge of #89251 - estebank:negative-index-literals r=davidtwco Detect when negative literal indices are used and suggest appropriate code,HEART,2021-09-28T18:03:15Z,Phosphorus-M,NA https://github.com/rust-lang/rust/pull/89253,CLOSED,2021-09-25T19:21:20Z,2022-01-16T08:52:11Z,Hide `ToString` specializations behind a private trait,SkiFire13,NA,NA,NA,EYES,2021-09-25T20:42:07Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89253,CLOSED,2021-09-25T19:21:20Z,2022-01-16T08:52:11Z,Hide `ToString` specializations behind a private trait,SkiFire13,NA,NA,NA,EYES,2021-09-27T03:48:25Z,kennytm,NA https://github.com/rust-lang/rust/pull/89257,MERGED,2021-09-25T20:59:49Z,2021-10-22T17:32:25Z,Give better error for `macro_rules name`,aDotInTheVoid,8738d5d61183e7fec36b8645586f148ec36d82c3,4,Rollup merge of #89257 - aDotInTheVoid:macro-error-2 r=estebank Give better error for `macro_rules name` follow up to #89221 r? ``@estebank`` ``@rustbot`` modify labels: +A-diagnostics +A-parser,HEART,2021-09-26T01:00:03Z,camelid,NA https://github.com/rust-lang/rust/pull/89257,MERGED,2021-09-25T20:59:49Z,2021-10-22T17:32:25Z,Give better error for `macro_rules name`,aDotInTheVoid,8738d5d61183e7fec36b8645586f148ec36d82c3,4,Rollup merge of #89257 - aDotInTheVoid:macro-error-2 r=estebank Give better error for `macro_rules name` follow up to #89221 r? ``@estebank`` ``@rustbot`` modify labels: +A-diagnostics +A-parser,HEART,2021-09-26T08:18:42Z,estebank,NA https://github.com/rust-lang/rust/pull/89263,MERGED,2021-09-26T07:25:23Z,2021-09-27T14:07:59Z,Suggest both of immutable and mutable trait implementations,TaKO8Ki,3e8f32e1c52ca493c862facb7a69e7c3f1f97a18,12,Auto merge of #89263 - TaKO8Ki:suggest-both-immutable-and-mutable-trait-implementations r=estebank Suggest both of immutable and mutable trait implementations closes #85865,HEART,2021-09-26T10:12:49Z,estebank,NA https://github.com/rust-lang/rust/pull/89270,MERGED,2021-09-26T13:31:48Z,2021-10-05T06:54:19Z,path.push() should work as expected on windows verbatim paths,seanyoung,7aa9ce55b91726d92770107bfaf5961163cd9388,2,Rollup merge of #89270 - seanyoung:join_fold r=m-ou-se path.push() should work as expected on windows verbatim paths On Windows std::fs::canonicalize() returns an so-called UNC path. UNC paths differ with regular paths because: - This type of path can much longer than a non-UNC path (32k vs 260 characters). - The prefix for a UNC path is ``Component::Prefix(Prefix::DiskVerbatim(..)))`` - No `/` is allowed - No `.` is allowed - No `..` is allowed Rust has poor handling of such paths. If you join a UNC path with a path with any of the above then this will not work. I've implemented a new method `fn join_fold()` which joins paths and also removes any `.` and `..` from it and replaces `/` with `\` on Windows. Using this function it is possible to use UNC paths without issue. In addition this function is useful on Linux too; paths can be appended without having to call `canonicalize()` to remove the `.` and `..`. This PR needs test cases which can I add. I hope this will a start of a discussion.,HOORAY,2021-10-04T13:00:23Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/89277,MERGED,2021-09-26T16:32:53Z,2021-09-28T08:58:51Z,Use the correct edition for syntax highlighting doctests,jyn514,7b10746ef08041885989eccd2dd6cd3c2f6f0f49,4,Auto merge of #89277 - jyn514:codeblock-edition r=GuillaumeGomez Use the correct edition for syntax highlighting doctests Previously it would unconditionally use edition 2015 which was incorrect. Helps with https://github.com/rust-lang/rust/issues/89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is. cc `@Mark-Simulacrum`,HEART,2021-10-05T19:34:45Z,camelid,NA https://github.com/rust-lang/rust/pull/89288,MERGED,2021-09-26T20:56:59Z,2021-10-08T09:04:08Z,Wrapper for `-Z gcc-ld=lld` to invoke rust-lld with the correct flavor,hkratz,1c1c6eda94e9841d0a534ba012034b05173c6a13,7,Rollup merge of #89288 - rusticstuff:lld_wrapper r=Mark-Simulacrum Wrapper for `-Z gcc-ld=lld` to invoke rust-lld with the correct flavor This PR adds an `lld-wrapper` tool which is installed as `ld` and `ld64` in `lib\rustlib\\bin\gcc-ld` directory and whose sole purpose is to invoke `rust-lld` in the parent directory with the correct flavor. Lld decides which flavor to use from either the first two commandline arguments or from the name of the executable (`ld` for GNU/ld flavor `ld64` for Darwin/Macos/ld64 flavor and so on). Symbolic links could not be used as they are not supported by rustup and on Windows. The wrapper replaces full copies of rust-lld which added some significant bloat. On UNIXish operating systems it exec rust-lld on Windows it spawns it as a child process. Fixes #88869. r? ```@Mark-Simulacrum``` cc ```@nagisa``` ```@petrochenkov``` ```@1000teslas```,THUMBS_UP,2021-09-27T00:41:27Z,est31,NA https://github.com/rust-lang/rust/pull/89293,MERGED,2021-09-27T07:34:12Z,2021-09-28T11:50:48Z,Suggest using the path separator for tuple struct,TaKO8Ki,83f147b3baf21acfc367a6da1045d212cd3957e4,3,Auto merge of #89293 - TaKO8Ki:fix-confusing-error-for-path-separator-to-refer-to-an-struct-item r=estebank Suggest using the path separator for tuple struct Fix confusing error message `constructor is not visible here due to private fields` for tuple struct closes #83450,THUMBS_UP,2021-09-27T10:15:28Z,wan-nyan-wan,kazuki.hanai@wan-nyan-wan.net https://github.com/rust-lang/rust/pull/89303,MERGED,2021-09-27T15:46:40Z,2021-10-01T06:19:59Z,Add `#[must_not_suspend]` to some types in std,guswynn,7b40d4240e2b246b13168391234ad7c1ea2a61bc,7,Rollup merge of #89303 - guswynn:std_suspend r=dtolnay Add `#[must_not_suspend]` to some types in std I am not sure what else should have it? `Ref`?,HEART,2021-10-01T06:48:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89303,MERGED,2021-09-27T15:46:40Z,2021-10-01T06:19:59Z,Add `#[must_not_suspend]` to some types in std,guswynn,7b40d4240e2b246b13168391234ad7c1ea2a61bc,7,Rollup merge of #89303 - guswynn:std_suspend r=dtolnay Add `#[must_not_suspend]` to some types in std I am not sure what else should have it? `Ref`?,HEART,2021-10-02T01:33:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/89310,MERGED,2021-09-27T20:28:37Z,2021-11-07T14:58:55Z,Make `std::thread::available_concurrency` support process-limited number of CPUs,joshtriplett,fecfc0e6cc78d74d5898f168cfeee81256ac9ac7,1,Auto merge of #89310 - joshtriplett:available-concurrency-affinity r=m-ou-se Make `std::thread::available_concurrency` support process-limited number of CPUs Use `libc::sched_getaffinity` and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs such as when limited via `taskset` or similar. This also covers cgroup cpusets.,THUMBS_UP,2021-09-27T20:38:59Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/89310,MERGED,2021-09-27T20:28:37Z,2021-11-07T14:58:55Z,Make `std::thread::available_concurrency` support process-limited number of CPUs,joshtriplett,fecfc0e6cc78d74d5898f168cfeee81256ac9ac7,1,Auto merge of #89310 - joshtriplett:available-concurrency-affinity r=m-ou-se Make `std::thread::available_concurrency` support process-limited number of CPUs Use `libc::sched_getaffinity` and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs such as when limited via `taskset` or similar. This also covers cgroup cpusets.,THUMBS_UP,2021-10-06T18:02:58Z,luser,NA https://github.com/rust-lang/rust/pull/89310,MERGED,2021-09-27T20:28:37Z,2021-11-07T14:58:55Z,Make `std::thread::available_concurrency` support process-limited number of CPUs,joshtriplett,fecfc0e6cc78d74d5898f168cfeee81256ac9ac7,1,Auto merge of #89310 - joshtriplett:available-concurrency-affinity r=m-ou-se Make `std::thread::available_concurrency` support process-limited number of CPUs Use `libc::sched_getaffinity` and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs such as when limited via `taskset` or similar. This also covers cgroup cpusets.,THUMBS_UP,2021-11-11T11:14:06Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/89310,MERGED,2021-09-27T20:28:37Z,2021-11-07T14:58:55Z,Make `std::thread::available_concurrency` support process-limited number of CPUs,joshtriplett,fecfc0e6cc78d74d5898f168cfeee81256ac9ac7,1,Auto merge of #89310 - joshtriplett:available-concurrency-affinity r=m-ou-se Make `std::thread::available_concurrency` support process-limited number of CPUs Use `libc::sched_getaffinity` and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs such as when limited via `taskset` or similar. This also covers cgroup cpusets.,THUMBS_UP,2021-11-13T21:42:45Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-28T15:32:11Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-28T16:56:49Z,selectiveduplicate,NA https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-28T18:45:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-28T23:54:50Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-29T15:58:40Z,yaymukund,NA https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-09-29T17:49:36Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/89323,MERGED,2021-09-28T14:49:17Z,2021-10-06T09:04:26Z,Consider unfulfilled obligations in binop errors,estebank,d7539a6af09e5889ed9bcb8b49571b7a59c32e65,27,Auto merge of #89323 - estebank:derive-binop r=petrochenkov Consider unfulfilled obligations in binop errors When encountering a binop where the types would have been accepted if all the predicates had been fulfilled include information about the predicates and suggest appropriate `#[derive]`s if possible. Fix #84515.,HOORAY,2021-10-08T15:20:48Z,MarkDDR,NA https://github.com/rust-lang/rust/pull/89324,MERGED,2021-09-28T14:51:46Z,2021-10-06T23:12:50Z,Rename `std::thread::available_conccurrency` to `std::thread::available_parallelism`,yoshuawuyts,b4615b5bf9e3e722b480190714ad44ecd7fa2ed1,11,"Rollup merge of #89324 - yoshuawuyts:hardware-parallelism r=m-ou-se Rename `std::thread::available_conccurrency` to `std::thread::available_parallelism` _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR renames `std::thread::available_conccurrency` to `std::thread::available_parallelism`. ## Rationale The API was initially named `std::thread::hardware_concurrency` mirroring the [C++ API of the same name](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency). We eventually decided to omit any reference to the word ""hardware"" after [this comment](https://github.com/rust-lang/rust/pull/74480#issuecomment-662045841). And so we ended up with `available_concurrency` instead. --- For a talk I was preparing this week I was reading through [""Understanding and expressing scalable concurrency"" (A. Turon 2013)](http://aturon.github.io/academic/turon-thesis.pdf) and the following passage stood out to me (emphasis mine): > __Concurrency is a system-structuring mechanism.__ An interactive system that deals with disparate asynchronous events is naturally structured by division into concurrent threads with disparate responsibilities. Doing so creates a better fit between problem and solution and can also decrease the average latency of the system by preventing long-running computations from obstructing quicker ones. > __Parallelism is a resource.__ A given machine provides a certain capacity for parallelism i.e. a bound on the number of computations it can perform simultaneously. The goal is to maximize throughput by intelligently using this resource. For interactive systems parallelism can decrease latency as well. _Chapter 2.1: Concurrency is not Parallelism. Page 30._ --- _""Concurrency is a system-structuring mechanism. Parallelism is a resource.""_ — It feels like this accurately captures the way we should be thinking about these APIs. What this API returns is not ""the amount of concurrency available to the program"" which is a property of the program and thus even with just a single thread is effectively unbounded. But instead it returns ""the amount of _parallelism_ available to the program"" which is a resource hard-constrained by the machine's capacity (and can be further restricted by e.g. operating systems). That's why I'd like to propose we rename this API from `available_concurrency` to `available_parallelism`. This still meets the criteria we previously established of not attempting to define what exactly we mean by ""hardware"" ""threads"" and other such words. Instead we only talk about ""concurrency"" as an abstract resource available to our program. r? `@joshtriplett`",THUMBS_UP,2021-10-04T10:28:38Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/89329,MERGED,2021-09-28T17:24:55Z,2021-10-06T23:12:50Z,print-type-sizes: skip field printing for primitives,tmiasko,b87a9a8a7c40484bc94515fd6d51e6e271ad4cb8,3,Rollup merge of #89329 - tmiasko:print-type-sizes-no-fields r=jackh726 print-type-sizes: skip field printing for primitives Fixes #86528.,HEART,2021-10-03T10:37:53Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89329,MERGED,2021-09-28T17:24:55Z,2021-10-06T23:12:50Z,print-type-sizes: skip field printing for primitives,tmiasko,b87a9a8a7c40484bc94515fd6d51e6e271ad4cb8,3,Rollup merge of #89329 - tmiasko:print-type-sizes-no-fields r=jackh726 print-type-sizes: skip field printing for primitives Fixes #86528.,HEART,2021-10-07T16:06:16Z,Skepfyr,jack.rickard@outlook.com https://github.com/rust-lang/rust/pull/89335,MERGED,2021-09-28T19:57:35Z,2021-09-30T07:34:09Z,Optimize is_sorted for Range and RangeInclusive,mbrubeck,8f9f3aa04d0fc5dff13f8e045f30fc96a4928703,1,Rollup merge of #89335 - mbrubeck:range-is-sorted r=cuviper Optimize is_sorted for Range and RangeInclusive The [`Step`] trait guarantees that `Range` yields items in sorted order. We can override `Iterator::is_sorted` based on this guarantee as we already do for `Iterator::min` and `max`. Thank you to ``@fiveseven-lambda`` who pointed this out [on the Rust Users Forum](https://users.rust-lang.org/t/is-sorted-method-in-impl-iterator-for-range/64717). [`Step`]: https://doc.rust-lang.org/stable/std/iter/trait.Step.html,HEART,2021-09-28T21:25:12Z,panaman67,NA https://github.com/rust-lang/rust/pull/89336,MERGED,2021-09-28T20:00:16Z,2021-12-30T14:53:01Z,Refactor variance diagnostics to work with more types,Aaron1011,f8d4ee7c7adcea52dfc62328309f5ef7df000266,25,Auto merge of #89336 - Aaron1011:variance-struct-diag r=cjgillot Refactor variance diagnostics to work with more types Instead of special-casing mutable pointers/references we now support general generic types (currently we handle `ty::Ref` `ty::RawPtr` and `ty::Adt`) When a `ty::Adt` is involved we show an additional note explaining which of the type's generic parameters is invariant (e.g. the `T` in `Cell`). Currently we don't explain *why* a particular generic parameter ends up becoming invariant. In the general case this could require printing a long 'backtrace' of types so doing this would be more suitable for a follow-up PR. We still only handle the case where our variance switches to `ty::Invariant`.,HEART,2021-12-27T00:44:40Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-09-30T18:07:20Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-10-03T07:35:36Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-10-08T12:51:28Z,Patix0331,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-10-14T04:24:36Z,hkratz,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-10-22T11:30:33Z,DianaNites,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,THUMBS_UP,2021-10-28T14:18:48Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-11-30T13:36:58Z,Stargateur,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-12-02T16:15:32Z,zohnannor,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-12-02T18:14:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-12-02T22:08:53Z,sunjay,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,THUMBS_UP,2021-12-03T11:39:43Z,DusterTheFirst,me@dusterthefirst.com https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,THUMBS_UP,2021-12-04T21:22:49Z,dbstratta,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,THUMBS_UP,2021-12-05T00:47:19Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89337,MERGED,2021-09-28T20:26:52Z,2021-10-15T19:04:02Z,Avoid allocations and copying in Vec::leak,mbrubeck,265fef45f20e3b8ed9495201b5d02bab1210f0f9,1,Auto merge of #89337 - mbrubeck:vec-leak r=m-ou-se Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box` we can instead leak the vector without any expensive operations just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However the `Vec::leak` docs explicitly forbid this so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak,HEART,2021-12-05T00:47:20Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89340,MERGED,2021-09-28T22:19:14Z,2021-10-01T20:06:37Z,Improve error message for `printf`-style format strings,FabianWolff,d388428aaad3915c65106a1aae2d09effcdbc034,6,"Rollup merge of #89340 - FabianWolff:issue-89173 r=petrochenkov Improve error message for `printf`-style format strings Fixes #89173. The following is actually supported today: ```rust fn main() { let num = 5; let width = 20; print!(""%*2$x"" num width); } ``` ``` error: multiple unused formatting arguments --> src/main.rs:4:21 | 4 | print!(""%*2$x"" num width); | ------- ^^^ ^^^^^ argument never used | || | | || argument never used | |help: format specifiers use curly braces: `{:1$x}` | multiple missing formatting specifiers | = note: printf formatting not supported; see the documentation for `std::fmt` ``` However as noted in #89173 something like ```rust print!(""%0*x"" width num); ``` does not give a helpful suggestion. I think this is partly intended because there actually _is_ no Rust equivalent to this; you always have to use a positional or named argument to specify the width (instead of just using the ""next"" argument as `printf` or even `.*` as a precision specifier in Rust would). Therefore I have added a note: ``` [...] note: format specifiers use curly braces and you have to use a positional or named parameter for the width --> t2.rs:4:13 | 4 | print!(""%0*x"" width num); | ^^^^ = note: printf formatting not supported; see the documentation for `std::fmt` ``` This is not perfect but it should at least point the user in the right direction instead of issuing no explanation at all. cc ```@lcnr```",HEART,2021-10-02T16:23:54Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/89346,CLOSED,2021-09-29T00:51:51Z,2022-01-30T04:21:22Z,Implement --check-cfg option (RFC 3013),mwkmwkmwk,NA,NA,NA,THUMBS_UP,2021-09-30T17:28:09Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/89346,CLOSED,2021-09-29T00:51:51Z,2022-01-30T04:21:22Z,Implement --check-cfg option (RFC 3013),mwkmwkmwk,NA,NA,NA,THUMBS_UP,2021-10-01T18:10:07Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89347,MERGED,2021-09-29T04:58:55Z,2021-10-14T02:24:52Z,suggestion for typoed crate or module,TaKO8Ki,efac68b93cfac0aa7062169f3b041661fbbdbdbd,5,Rollup merge of #89347 - TaKO8Ki:crate-or-module-typo r=estebank suggestion for typoed crate or module Previously the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules. #76208 before: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ use of undeclared type or module `chono` ``` after: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ | | | use of undeclared crate or module `chono` | help: a similar crate or module exists: `chrono` ```,THUMBS_UP,2021-09-29T21:33:51Z,Milo123459,NA https://github.com/rust-lang/rust/pull/89347,MERGED,2021-09-29T04:58:55Z,2021-10-14T02:24:52Z,suggestion for typoed crate or module,TaKO8Ki,efac68b93cfac0aa7062169f3b041661fbbdbdbd,5,Rollup merge of #89347 - TaKO8Ki:crate-or-module-typo r=estebank suggestion for typoed crate or module Previously the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules. #76208 before: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ use of undeclared type or module `chono` ``` after: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ | | | use of undeclared crate or module `chono` | help: a similar crate or module exists: `chrono` ```,THUMBS_UP,2021-09-30T08:25:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89347,MERGED,2021-09-29T04:58:55Z,2021-10-14T02:24:52Z,suggestion for typoed crate or module,TaKO8Ki,efac68b93cfac0aa7062169f3b041661fbbdbdbd,5,Rollup merge of #89347 - TaKO8Ki:crate-or-module-typo r=estebank suggestion for typoed crate or module Previously the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules. #76208 before: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ use of undeclared type or module `chono` ``` after: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ | | | use of undeclared crate or module `chono` | help: a similar crate or module exists: `chrono` ```,THUMBS_UP,2021-10-01T04:08:59Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/89347,MERGED,2021-09-29T04:58:55Z,2021-10-14T02:24:52Z,suggestion for typoed crate or module,TaKO8Ki,efac68b93cfac0aa7062169f3b041661fbbdbdbd,5,Rollup merge of #89347 - TaKO8Ki:crate-or-module-typo r=estebank suggestion for typoed crate or module Previously the compiler didn't suggest similarly named crates or modules. This pull request adds a suggestion for typoed crates or modules. #76208 before: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ use of undeclared type or module `chono` ``` after: ``` error[E0433]: failed to resolve: use of undeclared type or module `chono` --> src/main.rs:2:5 | 2 | use chono::prelude::*; | ^^^^^ | | | use of undeclared crate or module `chono` | help: a similar crate or module exists: `chrono` ```,THUMBS_UP,2021-10-06T10:38:26Z,estebank,NA https://github.com/rust-lang/rust/pull/89351,MERGED,2021-09-29T09:34:33Z,2021-10-06T01:32:24Z,for signed wrapping remainder do not compare lhs with MIN,tspiteri,e745e098c45771c5d411f55b72efa96cbeb9aca6,1,Rollup merge of #89351 - tspiteri:wrapping_rem r=dtolnay for signed wrapping remainder do not compare lhs with MIN Since the wrapped remainder is going to be 0 for all cases when the rhs is -1 there is no need to compare the lhs with MIN.,HOORAY,2021-09-29T17:57:45Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89359,MERGED,2021-09-29T14:09:01Z,2021-11-25T19:20:52Z,Various fixes for const_trait_impl,fee1-dead,90dd7c03af736447f4340d7b17fe00eef0b27af7,5,Rollup merge of #89359 - fee1-dead:const-it r=oli-obk Various fixes for const_trait_impl A few problems I found while making `Iterator` easier to const-implement. 1. More generous `~const Drop` check. We check for nested fields with caller bounds. For example an ADT type with fields of types `A` `B` `C` check if all of them are either: - Bounded (`A: ~const Drop` `B: Copy`) - Known to be able to destruct at compile time (`C = i32` `struct C(i32)` `C = some_fn`) 2. Don't treat trait functions marked with `#[default_method_body_is_const]` as stable const fns when checking `const_for` and `const_try` feature gates. I think anyone can review this so no r? this time.,THUMBS_UP,2021-11-24T10:16:12Z,mbartlett21,NA https://github.com/rust-lang/rust/pull/89359,MERGED,2021-09-29T14:09:01Z,2021-11-25T19:20:52Z,Various fixes for const_trait_impl,fee1-dead,90dd7c03af736447f4340d7b17fe00eef0b27af7,5,Rollup merge of #89359 - fee1-dead:const-it r=oli-obk Various fixes for const_trait_impl A few problems I found while making `Iterator` easier to const-implement. 1. More generous `~const Drop` check. We check for nested fields with caller bounds. For example an ADT type with fields of types `A` `B` `C` check if all of them are either: - Bounded (`A: ~const Drop` `B: Copy`) - Known to be able to destruct at compile time (`C = i32` `struct C(i32)` `C = some_fn`) 2. Don't treat trait functions marked with `#[default_method_body_is_const]` as stable const fns when checking `const_for` and `const_try` feature gates. I think anyone can review this so no r? this time.,THUMBS_UP,2021-11-26T05:26:46Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,EYES,2021-09-29T18:32:43Z,voteblake,NA https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2021-10-04T09:48:15Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2021-10-27T19:11:23Z,KapJI,NA https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2021-10-28T18:38:12Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2021-11-17T16:45:12Z,Link1J,NA https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2022-01-03T05:08:13Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/89369,CLOSED,2021-09-29T17:50:17Z,2022-05-07T23:55:00Z,Allow use of AddressSanitizer on Windows by linking to existing libraries,danielframpton,NA,NA,NA,HOORAY,2022-02-28T05:10:42Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/89413,MERGED,2021-09-30T20:53:54Z,2021-10-05T06:54:19Z,Correctly handle supertraits for min_specialization,matthewjasper,05b4cd6789bf6eef76744246d54064fe3758123e,20,Rollup merge of #89413 - matthewjasper:spec-marker-fix r=nikomatsakis Correctly handle supertraits for min_specialization Supertraits of specialization markers could circumvent checks for min_specialization. Elaborating predicates prevents this. r? ````@nikomatsakis````,HEART,2021-10-14T05:54:56Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89413,MERGED,2021-09-30T20:53:54Z,2021-10-05T06:54:19Z,Correctly handle supertraits for min_specialization,matthewjasper,05b4cd6789bf6eef76744246d54064fe3758123e,20,Rollup merge of #89413 - matthewjasper:spec-marker-fix r=nikomatsakis Correctly handle supertraits for min_specialization Supertraits of specialization markers could circumvent checks for min_specialization. Elaborating predicates prevents this. r? ````@nikomatsakis````,HEART,2021-10-14T10:15:09Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/89416,MERGED,2021-10-01T06:21:07Z,2021-10-23T09:21:44Z,nice_region_error: Include lifetime placeholders in error output,notriddle,d64b3a703d8e3b76a4bcb75cef94e52eb32bf55c,8,Rollup merge of #89416 - notriddle:notriddle/do-not-elide-lifetimes-in-region-errors r=jackh726 nice_region_error: Include lifetime placeholders in error output As you can see in src/test/ui/traits/self-without-lifetime-constraint.stderr you can get very confusing type names if you don't have this. Fixes #87763,THUMBS_UP,2021-10-01T09:20:41Z,Urgau,NA https://github.com/rust-lang/rust/pull/89433,MERGED,2021-10-01T15:44:55Z,2021-10-14T19:23:11Z,Fix ctrl-c causing reads of stdin to return empty on Windows.,arlosi,d1777917915f59df0407ddeb16aa9e987481784c,1,Rollup merge of #89433 - arlosi:stdin-fix r=joshtriplett Fix ctrl-c causing reads of stdin to return empty on Windows. Pressing ctrl+c (or ctrl+break) on Windows caused a blocking read of stdin to unblock and return empty unlike other platforms which continue to block. On ctrl-c `ReadConsoleW` will return success but also set `LastError` to `ERROR_OPERATION_ABORTED`. This change detects this case and re-tries the call to `ReadConsoleW`. Fixes #89177. See issue for further details. Tested on Windows 7 and Windows 10 with both MSVC and GNU toolchains,HEART,2021-10-14T12:37:58Z,hkratz,NA https://github.com/rust-lang/rust/pull/89441,MERGED,2021-10-01T18:46:30Z,2021-10-02T01:32:52Z,Normalize after substituting via `field.ty()`,Nadrieril,5ab1245303c26d3ae33b1adaa89fef2b8d9fb9ca,5,Rollup merge of #89441 - Nadrieril:fix-89393 r=tmandry Normalize after substituting via `field.ty()` Back in https://github.com/rust-lang/rust/issues/72476 I hadn't understood where the problem was coming from and only worked around the issue. What happens is that calling `field.ty()` on a field of a generic struct substitutes the appropriate generics but doesn't normalize the resulting type. As a consumer of types I'm surprised that one would substitute without normalizing feels like a footgun so I added a comment. Fixes https://github.com/rust-lang/rust/issues/89393.,ROCKET,2021-10-01T19:34:15Z,tmandry,NA https://github.com/rust-lang/rust/pull/89443,MERGED,2021-10-01T19:30:19Z,2021-10-04T23:41:27Z,Include the length in BTree hashes,cuviper,e1478d650d0fdecfb72a341f319efb07bb03265d,2,Rollup merge of #89443 - cuviper:btree-hash-len r=dtolnay Include the length in BTree hashes This change makes it consistent with `Hash` for all other collections.,THUMBS_UP,2021-10-01T19:55:50Z,tczajka,tczajka@gmail.com https://github.com/rust-lang/rust/pull/89443,MERGED,2021-10-01T19:30:19Z,2021-10-04T23:41:27Z,Include the length in BTree hashes,cuviper,e1478d650d0fdecfb72a341f319efb07bb03265d,2,Rollup merge of #89443 - cuviper:btree-hash-len r=dtolnay Include the length in BTree hashes This change makes it consistent with `Hash` for all other collections.,THUMBS_UP,2021-10-02T12:05:48Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/89443,MERGED,2021-10-01T19:30:19Z,2021-10-04T23:41:27Z,Include the length in BTree hashes,cuviper,e1478d650d0fdecfb72a341f319efb07bb03265d,2,Rollup merge of #89443 - cuviper:btree-hash-len r=dtolnay Include the length in BTree hashes This change makes it consistent with `Hash` for all other collections.,THUMBS_UP,2021-10-08T05:38:27Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89443,MERGED,2021-10-01T19:30:19Z,2021-10-04T23:41:27Z,Include the length in BTree hashes,cuviper,e1478d650d0fdecfb72a341f319efb07bb03265d,2,Rollup merge of #89443 - cuviper:btree-hash-len r=dtolnay Include the length in BTree hashes This change makes it consistent with `Hash` for all other collections.,THUMBS_UP,2021-10-08T08:49:17Z,ChrisJefferson,NA https://github.com/rust-lang/rust/pull/89447,MERGED,2021-10-01T21:06:19Z,2021-10-04T23:41:27Z,Improve error message for missing angle brackets in `[_]::method`,FabianWolff,08dd4148f1cdc0ba7fd6729def893bb08e0cd84d,3,Rollup merge of #89447 - FabianWolff:issue-89388 r=davidtwco Improve error message for missing angle brackets in `[_]::method` Fixes #89388.,THUMBS_UP,2021-10-02T16:03:33Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/89453,MERGED,2021-10-02T00:36:56Z,2021-10-04T23:41:27Z,Consistently use 'supertrait'.,waywardmonkeys,2bc89ce0bf2fff897ccbf89c6e7aee71681d7cc1,25,Rollup merge of #89453 - waywardmonkeys:consistent-supertrait-usage r=nagisa Consistently use 'supertrait'. A subset of places referred to 'super-trait' so this changes them to all use 'supertrait'. This matches 'supertype' and some other usages. An exception is 'auto-trait' which is consistently used in that manner.,THUMBS_UP,2021-10-02T10:37:05Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89455,CLOSED,2021-10-02T04:05:22Z,2022-06-19T11:57:37Z,Introduce linter for diagnostic messages,hkmatsumoto,NA,NA,NA,HEART,2021-10-03T10:16:01Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89473,MERGED,2021-10-02T20:40:22Z,2021-10-05T06:54:19Z,Fix extra `non_snake_case` warning for shorthand field bindings,FabianWolff,c2bfe45e660b9c56cb4ef734b30c278bb0414ee7,2,Rollup merge of #89473 - FabianWolff:issue-89469 r=joshtriplett Fix extra `non_snake_case` warning for shorthand field bindings Fixes #89469. The problem is the innermost `if` condition here: https://github.com/rust-lang/rust/blob/d14731cb3ced8318d7fc83cbe838f0e7f2fb3b40/compiler/rustc_lint/src/nonstandard_style.rs#L435-L452 This code runs for every `PatKind::Binding` so if a struct has multiple fields say A and B and both are bound in a pattern using shorthands the call to `self.check_snake_case()` will indeed be skipped in the `check_pat()` call for `A`; but when `check_pat()` is called for `B` the loop will still iterate over `A` and `field.ident (= A) != ident (= B)` will be true. I have fixed this by only looking at non-shorthand bindings and only the binding that `check_pat()` was actually called for.,HEART,2021-10-02T20:47:56Z,cole-miller,NA https://github.com/rust-lang/rust/pull/89479,MERGED,2021-10-03T00:31:35Z,2021-10-03T06:24:04Z,Make diangostic item naming consistent,camsteffen,77f1e504a953efbbd59673a75c3cd530d5b3c530,123,Auto merge of #89479 - camsteffen:diag-naming r=Manishearth Make diangostic item naming consistent Right now there is about a 50/50 split of naming diagnostic items as `vec_type` vs `Vec`. So it is hard to guess a diagnostic item name with confidence. I know it's not great to change these retroactively but I think it will be much easier to maintain consistency after consistency is established.,HEART,2021-10-03T08:10:02Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/89483,MERGED,2021-10-03T06:53:49Z,2021-10-04T23:41:27Z,Practice diagnostic message convention,hkmatsumoto,5352e17df3b2500b4cf92ee86c7dbf002018600f,63,Rollup merge of #89483 - hkmatsumoto:patch-diagnostics-2 r=estebank Practice diagnostic message convention Detected by #89455. r? ```@estebank```,HEART,2021-10-03T10:16:03Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89483,MERGED,2021-10-03T06:53:49Z,2021-10-04T23:41:27Z,Practice diagnostic message convention,hkmatsumoto,5352e17df3b2500b4cf92ee86c7dbf002018600f,63,Rollup merge of #89483 - hkmatsumoto:patch-diagnostics-2 r=estebank Practice diagnostic message convention Detected by #89455. r? ```@estebank```,HEART,2021-10-04T13:08:13Z,estebank,NA https://github.com/rust-lang/rust/pull/89489,MERGED,2021-10-03T13:36:12Z,2021-10-04T12:49:58Z,Fix unsound optimization with explicit variant discriminants,FabianWolff,a4797664ba9c7d71e586122853858eeb6c153bb9,2,Auto merge of #89489 - FabianWolff:issue-89485 r=oli-obk Fix unsound optimization with explicit variant discriminants Fixes #89485.,HOORAY,2021-10-04T13:25:41Z,apiraino,NA https://github.com/rust-lang/rust/pull/89495,MERGED,2021-10-03T16:45:28Z,2021-10-07T09:10:30Z,Add two inline annotations for hot functions,Mark-Simulacrum,ca8078d7b2e40c24a39e5fe2a910afef4c91ebfc,2,Auto merge of #89495 - Mark-Simulacrum:add-inlines r=michaelwoerister Add two inline annotations for hot functions These two functions are essentially no-ops (and compile to just a load and return) but show up in process_obligations profiles with a high call count -- so worthwhile to try and inline them. This is not normally possible as they're non-generic so they don't get offered for inlining by our current algorithm.,HEART,2021-10-06T16:53:38Z,panaman67,NA https://github.com/rust-lang/rust/pull/89502,MERGED,2021-10-03T21:10:06Z,2021-10-06T01:32:23Z,Fix Lower/UpperExp formatting for integers and precision zero,FabianWolff,4e8c853c9e419d70c3017683816af41db2f7a580,2,"Rollup merge of #89502 - FabianWolff:issue-89493 r=joshtriplett Fix Lower/UpperExp formatting for integers and precision zero Fixes the integer part of #89493 (I daren't touch the floating-point formatting code). The issue is that the ""subtracted"" precision essentially behaves like extra trailing zeros but this is not currently reflected in the code properly.",THUMBS_UP,2021-10-03T22:06:01Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-04T07:24:06Z,oli-obk,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-04T15:27:13Z,RalfJung,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-04T15:53:39Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-04T16:32:24Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-04T20:08:08Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-05T00:10:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-05T01:56:48Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-05T02:44:23Z,camelid,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-05T12:54:01Z,crawford,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-06T13:09:42Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-08T05:41:05Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-14T11:00:59Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-14T14:17:06Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-15T04:41:09Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-15T14:00:59Z,DianaNites,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-15T17:12:29Z,Kolsky,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-10-15T17:25:42Z,ratijas,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),THUMBS_UP,2021-10-15T21:08:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-11-20T19:15:32Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-11-29T16:51:41Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-12-01T05:51:30Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-12-01T11:27:30Z,kamulos,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-12-02T16:10:54Z,zohnannor,NA https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),THUMBS_UP,2021-12-03T00:20:01Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/89508,MERGED,2021-10-04T04:37:00Z,2021-10-04T23:41:27Z,Stabilize `const_panic`,jhpratt,9866b090f48fc5f45ca9c80618976e41987fc25d,51,Rollup merge of #89508 - jhpratt:stabilize-const_panic r=joshtriplett Stabilize `const_panic` Closes #51999 FCP completed in #89006 ```@rustbot``` label +A-const-eval +A-const-fn +T-lang cc ```@oli-obk``` for review (not `r?`'ing as not on lang team),HOORAY,2021-12-03T00:20:04Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/89509,MERGED,2021-10-04T05:07:39Z,2021-10-16T09:35:49Z,Stabilize `unreachable_unchecked` as `const fn`,jhpratt,9ae0804859614ff2e76b26f551ef2cdb19e927ef,6,Rollup merge of #89509 - jhpratt:stabilize-const_unreachable_unchecked r=oli-obk Stabilize `unreachable_unchecked` as `const fn` Closes #53188 This PR stabilizes `core::hint::unreachable_unchecked` as `const fn`. MIRI is able to detect when this method is called. Stabilization was delayed until `const_panic` was stabilized so as to avoid users calling this method in its place (thus resulting in runtime UB). With #89508 that is no longer an issue. ````@rustbot```` label +A-const-eval +A-const-fn +T-lang +S-blocked (not sure why it's T-lang but that's what the tracking issue is),THUMBS_UP,2021-10-21T03:24:37Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,ROCKET,2021-10-04T09:59:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,ROCKET,2021-10-04T10:49:14Z,lqd,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,THUMBS_UP,2021-10-04T10:50:46Z,oli-obk,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HEART,2021-10-04T14:36:50Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-04T15:05:26Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HEART,2021-10-04T15:40:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,ROCKET,2021-10-04T15:40:53Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,ROCKET,2021-10-04T15:47:06Z,camelid,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HEART,2021-10-04T15:47:06Z,camelid,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-04T15:47:08Z,camelid,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-04T17:52:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-05T08:17:32Z,mati865,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-10T00:11:16Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-13T11:59:53Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HEART,2021-10-13T11:59:58Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-13T17:54:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HOORAY,2021-10-22T17:05:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89514,MERGED,2021-10-04T09:56:39Z,2021-10-17T15:35:28Z,polymorphization: shims and predicates,davidtwco,6f53ddfa74ac3c10ceb63ad4a7a9c95e55853c87,11,Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates r=lcnr polymorphization: shims and predicates Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on. - #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in. - #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced but it doesn't hurt. - #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675 this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped. - Polymorphization now explicitly checks (and skips) foreign items this is necessary for stage2 bootstrapping to work when polymorphization is enabled. - The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate not the local crate) adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir` so it seemed more reasonable to not change the conditional. - `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally but not with an ICE but it fails in a fresh checkout too so 🤷‍♂️. r? `@lcnr`,HEART,2021-10-22T17:05:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89518,OPEN,2021-10-04T11:28:39Z,NA,Add vectored positioned I/O on Unix,a1phyr,NA,NA,NA,HOORAY,2021-10-04T15:36:06Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89518,OPEN,2021-10-04T11:28:39Z,NA,Add vectored positioned I/O on Unix,a1phyr,NA,NA,NA,HOORAY,2022-01-05T09:05:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89527,MERGED,2021-10-04T19:46:05Z,2021-10-05T02:22:29Z,[beta] Beta rollup,ehuss,e6e620e1c7e7257babdfaed5c3bccbb654e72e83,62,"Auto merge of #89527 - ehuss:beta-backports r=ehuss [beta] Beta rollup * Fix WinUWP std compilation errors due to I/O safety #88587 * Disable RemoveZsts in generators to avoid query cycles #88979 * Disable the evaluation cache when in intercrate mode #88994 * Fix linting when trailing macro expands to a trailing semi #88996 * Don't use projection cache or candidate cache in intercrate mode #89125 * 2229: Mark insignificant dtor in stdlib #89144 * Temporarily rename int_roundings functions to avoid conflicts #89184 * [rfc 2229] Drop fully captured upvars in the same order as the regular drop code #89208 * Use the correct edition for syntax highlighting doctests #89277 * Don't normalize opaque types with escaping late-bound regions #89285 * Update Let's Encrypt ROOT CA certificate in dist-(i686|x86_64)-linux docker images #89486 Cargo update: * - [beta] 1.56 backports (rust-lang/cargo#9958) * - [beta] Revert ""When a dependency does not have a version git or path… (rust-lang/cargo#9912) * - [beta] Fix rustc --profile=dev unstable check. (rust-lang/cargo#9901)",EYES,2021-10-05T00:11:09Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89532,MERGED,2021-10-04T21:16:45Z,2021-10-06T01:32:23Z,Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity,ecstatic-morse,f71b3e2b46505fda8dea7187fa90b80472f7abfa,3,Rollup merge of #89532 - ecstatic-morse:maybe-live-locals-enum r=oli-obk tmiasko Document behavior of `MaybeLiveLocals` regarding enums and field-senstivity This arose from a [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/MaybeLiveLocals.20and.20Discriminants) where a new contributor attempted to implement a dead-store elimination pass using this analysis. They ran into a nasty hack around `SetDiscriminant` the effect of which is to lets handle assignments of literals to enum-typed locals (e.g. `x = Some(4)`) correctly. This took me a while to figure out. Document this oddity so the next person will have an easier time and add a test to enshrine the current behavior. r? ``@tmiasko``,HEART,2021-10-05T13:39:35Z,oli-obk,NA https://github.com/rust-lang/rust/pull/89534,MERGED,2021-10-04T22:02:04Z,2021-10-07T17:17:28Z,Introduce `tcx.get_diagnostic_name`,camsteffen,0157cc977fd71297ce73e2f249321f5ba2555d42,15,"Auto merge of #89534 - camsteffen:diag-name r=oli-obk Introduce `tcx.get_diagnostic_name` Introduces a ""reverse lookup"" for diagnostic items. This is mainly intended for `@rust-lang/clippy` which often does a long series of `is_diagnostic_item` calls for the same `DefId`. r? `@oli-obk`",HEART,2021-10-04T22:12:04Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/89534,MERGED,2021-10-04T22:02:04Z,2021-10-07T17:17:28Z,Introduce `tcx.get_diagnostic_name`,camsteffen,0157cc977fd71297ce73e2f249321f5ba2555d42,15,"Auto merge of #89534 - camsteffen:diag-name r=oli-obk Introduce `tcx.get_diagnostic_name` Introduces a ""reverse lookup"" for diagnostic items. This is mainly intended for `@rust-lang/clippy` which often does a long series of `is_diagnostic_item` calls for the same `DefId`. r? `@oli-obk`",HEART,2021-10-04T22:33:03Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/89534,MERGED,2021-10-04T22:02:04Z,2021-10-07T17:17:28Z,Introduce `tcx.get_diagnostic_name`,camsteffen,0157cc977fd71297ce73e2f249321f5ba2555d42,15,"Auto merge of #89534 - camsteffen:diag-name r=oli-obk Introduce `tcx.get_diagnostic_name` Introduces a ""reverse lookup"" for diagnostic items. This is mainly intended for `@rust-lang/clippy` which often does a long series of `is_diagnostic_item` calls for the same `DefId`. r? `@oli-obk`",HEART,2021-10-05T09:14:52Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/89534,MERGED,2021-10-04T22:02:04Z,2021-10-07T17:17:28Z,Introduce `tcx.get_diagnostic_name`,camsteffen,0157cc977fd71297ce73e2f249321f5ba2555d42,15,"Auto merge of #89534 - camsteffen:diag-name r=oli-obk Introduce `tcx.get_diagnostic_name` Introduces a ""reverse lookup"" for diagnostic items. This is mainly intended for `@rust-lang/clippy` which often does a long series of `is_diagnostic_item` calls for the same `DefId`. r? `@oli-obk`",HEART,2021-10-06T21:38:50Z,estebank,NA https://github.com/rust-lang/rust/pull/89542,MERGED,2021-10-05T03:10:21Z,2021-11-25T02:16:02Z,Partially stabilize `duration_consts_2`,jhpratt,658c148b87d21642cb245ae5ad3318d062d1b6d2,3,Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns r=oli-obk Partially stabilize `duration_consts_2` Methods that were only blocked on `const_panic` have been stabilized. The remaining methods of `duration_consts_2` are all related to floats and as such have been placed behind the `duration_consts_float` feature gate.,THUMBS_UP,2021-10-05T07:03:02Z,marmeladema,NA https://github.com/rust-lang/rust/pull/89542,MERGED,2021-10-05T03:10:21Z,2021-11-25T02:16:02Z,Partially stabilize `duration_consts_2`,jhpratt,658c148b87d21642cb245ae5ad3318d062d1b6d2,3,Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns r=oli-obk Partially stabilize `duration_consts_2` Methods that were only blocked on `const_panic` have been stabilized. The remaining methods of `duration_consts_2` are all related to floats and as such have been placed behind the `duration_consts_float` feature gate.,THUMBS_UP,2021-10-08T06:58:23Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/89542,MERGED,2021-10-05T03:10:21Z,2021-11-25T02:16:02Z,Partially stabilize `duration_consts_2`,jhpratt,658c148b87d21642cb245ae5ad3318d062d1b6d2,3,Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns r=oli-obk Partially stabilize `duration_consts_2` Methods that were only blocked on `const_panic` have been stabilized. The remaining methods of `duration_consts_2` are all related to floats and as such have been placed behind the `duration_consts_float` feature gate.,THUMBS_UP,2021-10-09T01:48:59Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/89542,MERGED,2021-10-05T03:10:21Z,2021-11-25T02:16:02Z,Partially stabilize `duration_consts_2`,jhpratt,658c148b87d21642cb245ae5ad3318d062d1b6d2,3,Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns r=oli-obk Partially stabilize `duration_consts_2` Methods that were only blocked on `const_panic` have been stabilized. The remaining methods of `duration_consts_2` are all related to floats and as such have been placed behind the `duration_consts_float` feature gate.,THUMBS_UP,2021-10-14T05:59:31Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89542,MERGED,2021-10-05T03:10:21Z,2021-11-25T02:16:02Z,Partially stabilize `duration_consts_2`,jhpratt,658c148b87d21642cb245ae5ad3318d062d1b6d2,3,Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns r=oli-obk Partially stabilize `duration_consts_2` Methods that were only blocked on `const_panic` have been stabilized. The remaining methods of `duration_consts_2` are all related to floats and as such have been placed behind the `duration_consts_float` feature gate.,THUMBS_UP,2021-11-07T06:15:44Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/89547,CLOSED,2021-10-05T04:52:04Z,2021-11-09T09:51:56Z,pre-pre-pre-rfc: return tracing for `core::result::Result`,BGR360,NA,NA,NA,LAUGH,2021-10-05T17:45:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/89551,MERGED,2021-10-05T08:56:50Z,2021-11-13T20:12:00Z,Stabilize `const_raw_ptr_deref` for `*const T`,jhpratt,d212d902ae8d29e31b32641096f7848a4bb35522,62,Auto merge of #89551 - jhpratt:stabilize-const_raw_ptr_deref r=oli-obk Stabilize `const_raw_ptr_deref` for `*const T` This stabilizes dereferencing immutable raw pointers in const contexts. It does not stabilize `*mut T` dereferencing. This is behind the same feature gate as mutable references. closes https://github.com/rust-lang/rust/issues/51911,HEART,2021-11-04T12:56:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89551,MERGED,2021-10-05T08:56:50Z,2021-11-13T20:12:00Z,Stabilize `const_raw_ptr_deref` for `*const T`,jhpratt,d212d902ae8d29e31b32641096f7848a4bb35522,62,Auto merge of #89551 - jhpratt:stabilize-const_raw_ptr_deref r=oli-obk Stabilize `const_raw_ptr_deref` for `*const T` This stabilizes dereferencing immutable raw pointers in const contexts. It does not stabilize `*mut T` dereferencing. This is behind the same feature gate as mutable references. closes https://github.com/rust-lang/rust/issues/51911,HEART,2022-03-29T03:47:49Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/89553,OPEN,2021-10-05T10:43:52Z,NA,Add trait object safety information on trait documentation page,GuillaumeGomez,NA,NA,NA,HEART,2021-10-05T21:38:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/89553,OPEN,2021-10-05T10:43:52Z,NA,Add trait object safety information on trait documentation page,GuillaumeGomez,NA,NA,NA,HEART,2021-10-07T17:34:49Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/89553,OPEN,2021-10-05T10:43:52Z,NA,Add trait object safety information on trait documentation page,GuillaumeGomez,NA,NA,NA,HEART,2021-10-08T02:21:49Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/89553,OPEN,2021-10-05T10:43:52Z,NA,Add trait object safety information on trait documentation page,GuillaumeGomez,NA,NA,NA,HEART,2021-10-09T18:54:02Z,bugadani,NA https://github.com/rust-lang/rust/pull/89553,OPEN,2021-10-05T10:43:52Z,NA,Add trait object safety information on trait documentation page,GuillaumeGomez,NA,NA,NA,HEART,2021-10-17T15:46:44Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-10-05T17:10:59Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,THUMBS_UP,2021-10-05T18:03:17Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,THUMBS_UP,2021-10-17T13:30:31Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-10-17T18:05:07Z,mati865,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-09T23:29:34Z,RalfJung,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-10T13:02:11Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-10T14:05:43Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-10T17:28:43Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,THUMBS_UP,2021-11-18T03:59:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-18T03:59:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,THUMBS_UP,2021-11-18T21:11:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,HOORAY,2021-11-18T21:11:58Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89561,MERGED,2021-10-05T15:48:55Z,2021-11-09T23:16:05Z,Type inference for inline consts,nbdd0121,fd74c93403c455187c343f3828274824addc9881,49,Rollup merge of #89561 - nbdd0121:const_typeck r=nikomatsakis Type inference for inline consts Fixes #78132 Fixes #78174 Fixes #81857 Fixes #89964 Perform type checking/inference of inline consts in the same context as the outer def similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available) a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue and it uses extra type params `CK CS U` to capture closure kind input/output signature and upvars. I use a similar approach for inline consts letting it have an extra type param `R` and then `typeof(InlineConst<[paremt generics] R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler,THUMBS_UP,2021-11-27T08:24:46Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-05T18:29:35Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-05T18:58:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-05T21:18:43Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-06T05:49:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-06T11:07:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-06T18:56:44Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-07T15:35:39Z,iDawer,NA https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-08T09:12:27Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-08T16:36:54Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-08T21:08:55Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-10-09T19:01:32Z,camelid,NA https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-11-09T20:13:26Z,AqilCont,aqilcm@gmail.com https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-11-22T14:34:29Z,Agrailag,NA https://github.com/rust-lang/rust/pull/89570,OPEN,2021-10-05T18:28:25Z,NA,[Experiment] Split exhaustiveness logic into its own crate,Nadrieril,NA,NA,NA,HEART,2021-11-29T16:21:37Z,Virgiel,NA https://github.com/rust-lang/rust/pull/89580,MERGED,2021-10-05T23:04:39Z,2021-11-21T10:19:41Z,Point at source of trait bound obligations in more places,estebank,b8e5ab20ed7a7677a998a163ccf7853764b195e6,221,"Auto merge of #89580 - estebank:trait-bounds-are-tricky r=nagisa Point at source of trait bound obligations in more places Be more thorough in using `ItemObligation` and `BindingObligation` when evaluating obligations so that we can point at trait bounds that introduced unfulfilled obligations. We no longer incorrectly point at unrelated trait bounds (`substs-ppaux.verbose.stderr`). In particular we now point at trait bounds on method calls. We no longer point at ""obvious"" obligation sources (we no longer have a note pointing at `Trait` saying ""required by a bound in `Trait`"" like in `associated-types-no-suitable-supertrait*`). We no longer point at associated items (`ImplObligation`) as they didn't add any user actionable information they just added noise. Address part of #89418.",HEART,2021-12-18T01:56:51Z,tmandry,NA https://github.com/rust-lang/rust/pull/89580,MERGED,2021-10-05T23:04:39Z,2021-11-21T10:19:41Z,Point at source of trait bound obligations in more places,estebank,b8e5ab20ed7a7677a998a163ccf7853764b195e6,221,"Auto merge of #89580 - estebank:trait-bounds-are-tricky r=nagisa Point at source of trait bound obligations in more places Be more thorough in using `ItemObligation` and `BindingObligation` when evaluating obligations so that we can point at trait bounds that introduced unfulfilled obligations. We no longer incorrectly point at unrelated trait bounds (`substs-ppaux.verbose.stderr`). In particular we now point at trait bounds on method calls. We no longer point at ""obvious"" obligation sources (we no longer have a note pointing at `Trait` saying ""required by a bound in `Trait`"" like in `associated-types-no-suitable-supertrait*`). We no longer point at associated items (`ImplObligation`) as they didn't add any user actionable information they just added noise. Address part of #89418.",HEART,2022-01-26T23:24:58Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89581,MERGED,2021-10-05T23:33:35Z,2021-10-26T00:39:00Z,Add -Z no-unique-section-names to reduce ELF header bloat.,jblazquez,2f6764760665a2ac776293edf8b6772d17f3e266,6,Rollup merge of #89581 - jblazquez:master r=Mark-Simulacrum Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default when enabling function sections (which is the default for most targets) the LLVM backend will generate different section names for each function. For example a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04) the backend will also generate unique section names for exception handling resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names` and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65 000) that it broke some existing ELF tools which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB which is quite significant.,HOORAY,2021-10-05T23:42:15Z,orbikm,mick.orbik@gmail.com https://github.com/rust-lang/rust/pull/89581,MERGED,2021-10-05T23:33:35Z,2021-10-26T00:39:00Z,Add -Z no-unique-section-names to reduce ELF header bloat.,jblazquez,2f6764760665a2ac776293edf8b6772d17f3e266,6,Rollup merge of #89581 - jblazquez:master r=Mark-Simulacrum Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default when enabling function sections (which is the default for most targets) the LLVM backend will generate different section names for each function. For example a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04) the backend will also generate unique section names for exception handling resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names` and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65 000) that it broke some existing ELF tools which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB which is quite significant.,HOORAY,2021-10-06T07:50:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89581,MERGED,2021-10-05T23:33:35Z,2021-10-26T00:39:00Z,Add -Z no-unique-section-names to reduce ELF header bloat.,jblazquez,2f6764760665a2ac776293edf8b6772d17f3e266,6,Rollup merge of #89581 - jblazquez:master r=Mark-Simulacrum Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default when enabling function sections (which is the default for most targets) the LLVM backend will generate different section names for each function. For example a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04) the backend will also generate unique section names for exception handling resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names` and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65 000) that it broke some existing ELF tools which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB which is quite significant.,HOORAY,2021-10-06T23:51:47Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89581,MERGED,2021-10-05T23:33:35Z,2021-10-26T00:39:00Z,Add -Z no-unique-section-names to reduce ELF header bloat.,jblazquez,2f6764760665a2ac776293edf8b6772d17f3e266,6,Rollup merge of #89581 - jblazquez:master r=Mark-Simulacrum Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default when enabling function sections (which is the default for most targets) the LLVM backend will generate different section names for each function. For example a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04) the backend will also generate unique section names for exception handling resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names` and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65 000) that it broke some existing ELF tools which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB which is quite significant.,HOORAY,2021-10-25T20:21:25Z,Ch0ronomato,schweerian33@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-10-06T19:05:31Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-10-14T12:21:39Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-10-14T15:09:29Z,evanrichter,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-10-14T18:21:15Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-10-15T11:02:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-10-17T07:19:48Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-11-19T11:27:03Z,a1ien,averyanovin@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-11-30T12:55:14Z,Canop,cano.petrole@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-11-30T13:41:27Z,faptc,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T11:29:59Z,steven-joruk,steven@joruk.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-02T13:51:11Z,Lynnesbian,lynne@bune.city https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-02T16:21:01Z,zohnannor,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T16:22:23Z,zohnannor,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T17:01:51Z,tjkirch,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-02T18:14:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T18:14:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T19:37:35Z,rben01,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-02T20:14:25Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-02T20:14:28Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-03T11:42:16Z,DusterTheFirst,me@dusterthefirst.com https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-04T02:04:33Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-04T02:04:34Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",ROCKET,2021-12-04T02:04:35Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2021-12-05T00:53:11Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",THUMBS_UP,2021-12-05T00:53:11Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",ROCKET,2021-12-05T00:53:12Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",HEART,2022-01-04T20:49:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/89582,MERGED,2021-10-06T00:16:36Z,2021-10-09T08:31:28Z,Optimize File::read_to_end and read_to_string,jkugelman,910692de742e9c0b1a57b7c5e467b8b85d903269,5,"Auto merge of #89582 - jkugelman:optimize-file-read-to-end r=joshtriplett Optimize File::read_to_end and read_to_string Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer ""warms up"" and grows to its final size. This is perhaps a necessary evil with generic readers but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file reads its metadata and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests which isn't a big deal but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502. r? `@joshtriplett`",ROCKET,2022-01-04T20:50:00Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/89587,MERGED,2021-10-06T02:51:16Z,2021-10-13T13:41:53Z,"Include rmeta candidates in ""multiple matching crates"" error",camelid,5728bd64b49b0e78d0180efed75ef0870ae60266,16,"Auto merge of #89587 - camelid:all-candidates r=petrochenkov Include rmeta candidates in ""multiple matching crates"" error Only dylib and rlib candidates were included in the error. I think the reason is that at the time this error was originally implemented rmeta crate sources were represented different from dylib and rlib sources. I wrote up more detailed analysis in [this comment][1]. The new version of the code is also a bit easier to read and should be more robust to future changes since it uses `CrateSources::paths()`. I also changed the code to sort the candidates to make the output deterministic; added full stderr tests for the error; and added a long error code explanation. [1]: https://github.com/rust-lang/rust/pull/88675#issuecomment-935282436 cc `@Mark-Simulacrum` `@jyn514`",HEART,2021-10-06T02:53:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-06T13:53:24Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-06T20:31:13Z,DianaNites,NA https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-07T08:31:22Z,eggyal,NA https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-08T01:17:39Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-08T14:44:13Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-08T16:06:37Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-10T16:05:49Z,Thomasdezeeuw,thomasdezeeuw@gmail.com https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-10-11T19:34:19Z,murka,im@murka.me https://github.com/rust-lang/rust/pull/89596,MERGED,2021-10-06T13:42:32Z,2021-10-07T20:26:33Z,Make cfg imply doc(cfg),GuillaumeGomez,e32328bdc5a749d4b7d35297c85337522a07bddf,23,Rollup merge of #89596 - GuillaumeGomez:implicit-doc-cfg r=jyn514 Make cfg imply doc(cfg) This is a reopening of #79341 rebased and modified a bit (we made a lot of refactoring in rustdoc's types so they needed to be reflected in this PR as well): * `hidden_cfg` is now in the `Cache` instead of `DocContext` because `cfg` information isn't stored anymore on `clean::Attributes` type but instead computed on-demand so we need this information in later parts of rustdoc. * I removed the `bool_to_options` feature (which makes the code a bit simpler to read for `SingleExt` trait implementation. * I updated the version for the feature. There is only one thing I couldn't figure out: [this comment](https://github.com/rust-lang/rust/pull/79341#discussion_r561855624) > I think I'll likely scrap the whole `SingleExt` extension trait as the diagnostics for 0 and >1 items should be different. How/why should they differ? EDIT: this part has been solved the current code was fine just needed a little simplification. cc `@Nemo157` r? `@jyn514` Original PR description: This is only active when the `doc_cfg` feature is active. The implicit cfg can be overridden via `#[doc(cfg(...))]` so e.g. to hide a `#[cfg]` you can use something like: ```rust #[cfg(unix)] #[doc(cfg(all()))] pub struct Unix; ``` By adding `#![doc(cfg_hide(foobar))]` to the crate attributes the cfg `#[cfg(foobar)]` (and _only_ that _exact_ cfg) will not be implicitly treated as a `doc(cfg)` to render a message in the documentation.,THUMBS_UP,2021-12-18T15:03:37Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89597,MERGED,2021-10-06T14:28:18Z,2021-10-11T07:27:49Z,Create more accurate debuginfo for vtables.,michaelwoerister,9a757817c352801de8b0593728f8aee21e23cd53,8,"Auto merge of #89597 - michaelwoerister:improve-vtable-debuginfo r=wesleywiser Create more accurate debuginfo for vtables. Before this PR all vtables would have the same name (`""vtable""`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented. This is only one of several possible improvements: - This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits). - The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object. r? `@wesleywiser`",THUMBS_UP,2021-10-15T11:04:17Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89597,MERGED,2021-10-06T14:28:18Z,2021-10-11T07:27:49Z,Create more accurate debuginfo for vtables.,michaelwoerister,9a757817c352801de8b0593728f8aee21e23cd53,8,"Auto merge of #89597 - michaelwoerister:improve-vtable-debuginfo r=wesleywiser Create more accurate debuginfo for vtables. Before this PR all vtables would have the same name (`""vtable""`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented. This is only one of several possible improvements: - This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits). - The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object. r? `@wesleywiser`",THUMBS_UP,2021-12-05T00:44:50Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89603,CLOSED,2021-10-06T16:13:12Z,2022-02-27T19:07:58Z,libcore: add `str::first` `str::split_first` `str::last` and `str::split_last` methods,eduardosm,NA,NA,NA,THUMBS_UP,2021-10-06T19:56:21Z,camsteffen,NA https://github.com/rust-lang/rust/pull/89603,CLOSED,2021-10-06T16:13:12Z,2022-02-27T19:07:58Z,libcore: add `str::first` `str::split_first` `str::last` and `str::split_last` methods,eduardosm,NA,NA,NA,THUMBS_UP,2021-10-06T20:23:19Z,jfrimmel,NA https://github.com/rust-lang/rust/pull/89603,CLOSED,2021-10-06T16:13:12Z,2022-02-27T19:07:58Z,libcore: add `str::first` `str::split_first` `str::last` and `str::split_last` methods,eduardosm,NA,NA,NA,THUMBS_UP,2021-10-06T20:43:53Z,a1phyr,NA https://github.com/rust-lang/rust/pull/89610,MERGED,2021-10-06T20:24:58Z,2021-11-17T20:19:13Z,warn on must_use use on async fn's,guswynn,07342828c5066d6a7763535b9281b5cf021dea5c,3,Rollup merge of #89610 - guswynn:must_use_future r=wesleywiser warn on must_use use on async fn's As referenced in #78149 This only works on `async` fn's for now I can also look into if I can get `Box` and `impl Future` working at this level (hir),THUMBS_UP,2021-10-12T01:58:43Z,tmandry,NA https://github.com/rust-lang/rust/pull/89611,MERGED,2021-10-06T21:01:15Z,2021-11-21T21:20:29Z,libcore: assume the input of `next_code_point` and `next_code_point_reverse` is UTF-8-like,eduardosm,65f3f8b220f020e562c5dd848ff7319257a7ba45,3,"Auto merge of #89611 - eduardosm:next_code_point r=Mark-Simulacrum libcore: assume the input of `next_code_point` and `next_code_point_reverse` is UTF-8-like The functions are now `unsafe` and they use `Option::unwrap_unchecked` instead of `unwrap_or_0` `unwrap_or_0` was added in 42357d772b8a3a1ce4395deeac0a5cf1f66e951d. I guess `unwrap_unchecked` was not available back then. Given this example: ```rust pub fn first_char(s: &str) -> Option { s.chars().next() } ``` Previously the following assembly was produced: ```asm _ZN7example10first_char17ha056ddea6bafad1cE: .cfi_startproc test rsi rsi je .LBB0_1 movzx edx byte ptr [rdi] test dl dl js .LBB0_3 mov eax edx ret .LBB0_1: mov eax 1114112 ret .LBB0_3: lea r8 [rdi + rsi] xor eax eax mov r9 r8 cmp rsi 1 je .LBB0_5 movzx eax byte ptr [rdi + 1] add rdi 2 and eax 63 mov r9 rdi .LBB0_5: mov ecx edx and ecx 31 cmp dl -33 jbe .LBB0_6 cmp r9 r8 je .LBB0_9 movzx esi byte ptr [r9] add r9 1 and esi 63 shl eax 6 or eax esi cmp dl -16 jb .LBB0_12 .LBB0_13: cmp r9 r8 je .LBB0_14 movzx edx byte ptr [r9] and edx 63 jmp .LBB0_16 .LBB0_6: shl ecx 6 or eax ecx ret .LBB0_9: xor esi esi mov r9 r8 shl eax 6 or eax esi cmp dl -16 jae .LBB0_13 .LBB0_12: shl ecx 12 or eax ecx ret .LBB0_14: xor edx edx .LBB0_16: and ecx 7 shl ecx 18 shl eax 6 or eax ecx or eax edx ret ``` After this change the assembly is reduced to: ```asm _ZN7example10first_char17h4318683472f884ccE: .cfi_startproc test rsi rsi je .LBB0_1 movzx ecx byte ptr [rdi] test cl cl js .LBB0_3 mov eax ecx ret .LBB0_1: mov eax 1114112 ret .LBB0_3: mov eax ecx and eax 31 movzx esi byte ptr [rdi + 1] and esi 63 cmp cl -33 jbe .LBB0_4 movzx edx byte ptr [rdi + 2] shl esi 6 and edx 63 or edx esi cmp cl -16 jb .LBB0_7 movzx ecx byte ptr [rdi + 3] and eax 7 shl eax 18 shl edx 6 and ecx 63 or ecx edx or eax ecx ret .LBB0_4: shl eax 6 or eax esi ret .LBB0_7: shl eax 12 or eax edx ret ```",HOORAY,2021-11-22T13:56:30Z,bluss,NA https://github.com/rust-lang/rust/pull/89614,MERGED,2021-10-07T01:13:24Z,2021-10-09T19:05:07Z,Update to Unicode 14.0,cuviper,21a5101e21a770a90f8e322569ac38717d48c0cb,4,"Rollup merge of #89614 - cuviper:unicode-14 r=joshtriplett Update to Unicode 14.0 The Unicode Standard [announced Version 14.0](https://home.unicode.org/announcing-the-unicode-standard-version-14-0/) on September 14 2021 and this pull request updates the generated tables in `core` accordingly. This did require a little prep-work in `unicode-table-generator`. First #81358 had modified the generated file instead of the tool so that change is now reflected in the tool as well. Next I found that the ""Alphabetic"" property in version 14 was panicking when generating a bitset ""cannot pack 264 into 8 bits"". We've been using the skiplist for that anyway so I changed this to fail gracefully. Finally I confirmed that the tool still created the exact same tables for 13 before moving to 14.",THUMBS_UP,2021-10-07T13:26:01Z,r00ster91,NA https://github.com/rust-lang/rust/pull/89614,MERGED,2021-10-07T01:13:24Z,2021-10-09T19:05:07Z,Update to Unicode 14.0,cuviper,21a5101e21a770a90f8e322569ac38717d48c0cb,4,"Rollup merge of #89614 - cuviper:unicode-14 r=joshtriplett Update to Unicode 14.0 The Unicode Standard [announced Version 14.0](https://home.unicode.org/announcing-the-unicode-standard-version-14-0/) on September 14 2021 and this pull request updates the generated tables in `core` accordingly. This did require a little prep-work in `unicode-table-generator`. First #81358 had modified the generated file instead of the tool so that change is now reflected in the tool as well. Next I found that the ""Alphabetic"" property in version 14 was panicking when generating a bitset ""cannot pack 264 into 8 bits"". We've been using the skiplist for that anyway so I changed this to fail gracefully. Finally I confirmed that the tool still created the exact same tables for 13 before moving to 14.",THUMBS_UP,2021-12-02T22:18:58Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89614,MERGED,2021-10-07T01:13:24Z,2021-10-09T19:05:07Z,Update to Unicode 14.0,cuviper,21a5101e21a770a90f8e322569ac38717d48c0cb,4,"Rollup merge of #89614 - cuviper:unicode-14 r=joshtriplett Update to Unicode 14.0 The Unicode Standard [announced Version 14.0](https://home.unicode.org/announcing-the-unicode-standard-version-14-0/) on September 14 2021 and this pull request updates the generated tables in `core` accordingly. This did require a little prep-work in `unicode-table-generator`. First #81358 had modified the generated file instead of the tool so that change is now reflected in the tool as well. Next I found that the ""Alphabetic"" property in version 14 was panicking when generating a bitset ""cannot pack 264 into 8 bits"". We've been using the skiplist for that anyway so I changed this to fail gracefully. Finally I confirmed that the tool still created the exact same tables for 13 before moving to 14.",THUMBS_UP,2021-12-03T11:44:02Z,DusterTheFirst,me@dusterthefirst.com https://github.com/rust-lang/rust/pull/89614,MERGED,2021-10-07T01:13:24Z,2021-10-09T19:05:07Z,Update to Unicode 14.0,cuviper,21a5101e21a770a90f8e322569ac38717d48c0cb,4,"Rollup merge of #89614 - cuviper:unicode-14 r=joshtriplett Update to Unicode 14.0 The Unicode Standard [announced Version 14.0](https://home.unicode.org/announcing-the-unicode-standard-version-14-0/) on September 14 2021 and this pull request updates the generated tables in `core` accordingly. This did require a little prep-work in `unicode-table-generator`. First #81358 had modified the generated file instead of the tool so that change is now reflected in the tool as well. Next I found that the ""Alphabetic"" property in version 14 was panicking when generating a bitset ""cannot pack 264 into 8 bits"". We've been using the skiplist for that anyway so I changed this to fail gracefully. Finally I confirmed that the tool still created the exact same tables for 13 before moving to 14.",THUMBS_UP,2021-12-05T00:54:37Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89619,MERGED,2021-10-07T10:07:18Z,2021-10-08T11:44:50Z,Turn vtable_allocation() into a query,michaelwoerister,44995f7afb18775913618ae50601be31b9f9dead,10,Auto merge of #89619 - michaelwoerister:incr-vtables r=nagisa Turn vtable_allocation() into a query This PR removes the untracked vtable-const-allocation cache from the `tcx` and turns the `vtable_allocation()` method into a query. The change is pretty straightforward and should be backportable without too much effort. Fixes https://github.com/rust-lang/rust/issues/89598.,THUMBS_UP,2021-10-08T08:58:09Z,crlf0710,NA https://github.com/rust-lang/rust/pull/89621,MERGED,2021-10-07T10:33:23Z,2022-01-19T18:18:26Z,doc: guarantee call order for sort_by_cached_key,digama0,2a4381d8eaad4f9f0eb5a4e624e7b154640690f1,1,Rollup merge of #89621 - digama0:patch-2 r=yaahc doc: guarantee call order for sort_by_cached_key `slice::sort_by_cached_key` takes a caching function `f: impl FnMut(&T) -> K` which means that the order that calls to the caching function are made is user-visible. This adds a clause to the documentation to promise the current behavior which is that `f` is called on all elements of the slice from left to right unless the slice has len < 2 in which case `f` is not called. For example this can be used to ensure that the following code is a correct way to involve the index of the element in the sort key: ```rust let mut index = 0; slice.sort_by_cached_key(|x| (my_key(index x) index += 1).0); ```,CONFUSED,2021-10-07T18:50:04Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/89621,MERGED,2021-10-07T10:33:23Z,2022-01-19T18:18:26Z,doc: guarantee call order for sort_by_cached_key,digama0,2a4381d8eaad4f9f0eb5a4e624e7b154640690f1,1,Rollup merge of #89621 - digama0:patch-2 r=yaahc doc: guarantee call order for sort_by_cached_key `slice::sort_by_cached_key` takes a caching function `f: impl FnMut(&T) -> K` which means that the order that calls to the caching function are made is user-visible. This adds a clause to the documentation to promise the current behavior which is that `f` is called on all elements of the slice from left to right unless the slice has len < 2 in which case `f` is not called. For example this can be used to ensure that the following code is a correct way to involve the index of the element in the sort key: ```rust let mut index = 0; slice.sort_by_cached_key(|x| (my_key(index x) index += 1).0); ```,CONFUSED,2022-04-19T08:22:08Z,zirconium-n,NA https://github.com/rust-lang/rust/pull/89630,CLOSED,2021-10-07T14:30:34Z,2021-10-10T20:30:50Z,[crater only] stabilize never type,Mark-Simulacrum,NA,NA,NA,HEART,2021-10-07T14:36:13Z,jackh726,NA https://github.com/rust-lang/rust/pull/89630,CLOSED,2021-10-07T14:30:34Z,2021-10-10T20:30:50Z,[crater only] stabilize never type,Mark-Simulacrum,NA,NA,NA,HEART,2021-10-07T14:54:01Z,tyranron,NA https://github.com/rust-lang/rust/pull/89630,CLOSED,2021-10-07T14:30:34Z,2021-10-10T20:30:50Z,[crater only] stabilize never type,Mark-Simulacrum,NA,NA,NA,EYES,2021-10-07T17:26:31Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/89630,CLOSED,2021-10-07T14:30:34Z,2021-10-10T20:30:50Z,[crater only] stabilize never type,Mark-Simulacrum,NA,NA,NA,EYES,2021-10-08T16:47:51Z,a1phyr,NA https://github.com/rust-lang/rust/pull/89630,CLOSED,2021-10-07T14:30:34Z,2021-10-10T20:30:50Z,[crater only] stabilize never type,Mark-Simulacrum,NA,NA,NA,EYES,2021-10-09T04:45:21Z,kennytm,NA https://github.com/rust-lang/rust/pull/89633,MERGED,2021-10-07T16:06:07Z,2021-10-10T19:05:13Z,Show detailed expected/found types in error message when trait paths are the same,rhysd,68dfa07e3bbbfe9100a9b1047c274717bdf452a1,9,Auto merge of #89633 - rhysd:issue-65230 r=petrochenkov Show detailed expected/found types in error message when trait paths are the same Fixes #65230. ### Issue solved by this PR ```rust trait T { type U; fn f(&self) -> Self::U; } struct X<'a>(&'a mut i32); impl<'a> T for X<'a> { type U = &'a i32; fn f(&self) -> Self::U { self.0 } } fn main() {} ``` Compiler generates the following note: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected `T` found `T` ``` This note is not useful since the expected type and the found type are the same. ### How this PR solve the issue When the expected type and the found type are exactly the same in string representation the note falls back to the detailed string representation of trait ref: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected ` as T>` found ` as T>` ``` So that a user can notice what was different between the expected one and the found one.,THUMBS_UP,2021-10-09T11:26:19Z,denjiry,k.denjiry@gmail.com https://github.com/rust-lang/rust/pull/89633,MERGED,2021-10-07T16:06:07Z,2021-10-10T19:05:13Z,Show detailed expected/found types in error message when trait paths are the same,rhysd,68dfa07e3bbbfe9100a9b1047c274717bdf452a1,9,Auto merge of #89633 - rhysd:issue-65230 r=petrochenkov Show detailed expected/found types in error message when trait paths are the same Fixes #65230. ### Issue solved by this PR ```rust trait T { type U; fn f(&self) -> Self::U; } struct X<'a>(&'a mut i32); impl<'a> T for X<'a> { type U = &'a i32; fn f(&self) -> Self::U { self.0 } } fn main() {} ``` Compiler generates the following note: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected `T` found `T` ``` This note is not useful since the expected type and the found type are the same. ### How this PR solve the issue When the expected type and the found type are exactly the same in string representation the note falls back to the detailed string representation of trait ref: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected ` as T>` found ` as T>` ``` So that a user can notice what was different between the expected one and the found one.,THUMBS_UP,2021-10-09T11:32:45Z,kenoss,keno.ss57@gmail.com https://github.com/rust-lang/rust/pull/89633,MERGED,2021-10-07T16:06:07Z,2021-10-10T19:05:13Z,Show detailed expected/found types in error message when trait paths are the same,rhysd,68dfa07e3bbbfe9100a9b1047c274717bdf452a1,9,Auto merge of #89633 - rhysd:issue-65230 r=petrochenkov Show detailed expected/found types in error message when trait paths are the same Fixes #65230. ### Issue solved by this PR ```rust trait T { type U; fn f(&self) -> Self::U; } struct X<'a>(&'a mut i32); impl<'a> T for X<'a> { type U = &'a i32; fn f(&self) -> Self::U { self.0 } } fn main() {} ``` Compiler generates the following note: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected `T` found `T` ``` This note is not useful since the expected type and the found type are the same. ### How this PR solve the issue When the expected type and the found type are exactly the same in string representation the note falls back to the detailed string representation of trait ref: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected ` as T>` found ` as T>` ``` So that a user can notice what was different between the expected one and the found one.,THUMBS_UP,2021-10-09T11:55:40Z,koka831,koka.code@gmail.com https://github.com/rust-lang/rust/pull/89633,MERGED,2021-10-07T16:06:07Z,2021-10-10T19:05:13Z,Show detailed expected/found types in error message when trait paths are the same,rhysd,68dfa07e3bbbfe9100a9b1047c274717bdf452a1,9,Auto merge of #89633 - rhysd:issue-65230 r=petrochenkov Show detailed expected/found types in error message when trait paths are the same Fixes #65230. ### Issue solved by this PR ```rust trait T { type U; fn f(&self) -> Self::U; } struct X<'a>(&'a mut i32); impl<'a> T for X<'a> { type U = &'a i32; fn f(&self) -> Self::U { self.0 } } fn main() {} ``` Compiler generates the following note: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected `T` found `T` ``` This note is not useful since the expected type and the found type are the same. ### How this PR solve the issue When the expected type and the found type are exactly the same in string representation the note falls back to the detailed string representation of trait ref: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected ` as T>` found ` as T>` ``` So that a user can notice what was different between the expected one and the found one.,THUMBS_UP,2021-10-11T02:06:14Z,kubo39,NA https://github.com/rust-lang/rust/pull/89633,MERGED,2021-10-07T16:06:07Z,2021-10-10T19:05:13Z,Show detailed expected/found types in error message when trait paths are the same,rhysd,68dfa07e3bbbfe9100a9b1047c274717bdf452a1,9,Auto merge of #89633 - rhysd:issue-65230 r=petrochenkov Show detailed expected/found types in error message when trait paths are the same Fixes #65230. ### Issue solved by this PR ```rust trait T { type U; fn f(&self) -> Self::U; } struct X<'a>(&'a mut i32); impl<'a> T for X<'a> { type U = &'a i32; fn f(&self) -> Self::U { self.0 } } fn main() {} ``` Compiler generates the following note: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected `T` found `T` ``` This note is not useful since the expected type and the found type are the same. ### How this PR solve the issue When the expected type and the found type are exactly the same in string representation the note falls back to the detailed string representation of trait ref: ``` note: ...so that the types are compatible --> test.rs:10:28 | 10 | fn f(&self) -> Self::U { | ____________________________^ 11 | | self.0 12 | | } | |_____^ = note: expected ` as T>` found ` as T>` ``` So that a user can notice what was different between the expected one and the found one.,THUMBS_UP,2021-10-11T13:23:39Z,estebank,NA https://github.com/rust-lang/rust/pull/89634,MERGED,2021-10-07T16:23:57Z,2021-10-09T12:41:37Z,rustc_driver: Enable the `WARN` log level by default,hawkw,9d14b6505b3cbe47826c8f4d62f67f0e5e474750,5,Rollup merge of #89634 - hawkw:eliza/enable-err-warn r=oli-obk rustc_driver: Enable the `WARN` log level by default This commit changes the `tracing_subscriber` initialization in `rustc_driver` so that the `WARN` verbosity level is enabled by default when the `RUSTC_LOG` env variable is empty. If the `RUSTC_LOG` env variable is set the filter string in the environment variable is honored instead. Fixes #76824 Closes #89623 cc ``@eddyb `` ``@oli-obk``,THUMBS_UP,2021-10-07T16:36:18Z,oli-obk,NA https://github.com/rust-lang/rust/pull/89637,CLOSED,2021-10-07T17:40:17Z,2021-10-07T17:53:27Z,Use a regex instead of hard coded :: for rustdoc search.,accusitive,NA,NA,NA,THUMBS_UP,2021-10-07T17:40:59Z,AnotherZane,zanedpereira2@gmail.com https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-08T04:01:28Z,taiki-e,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-08T06:43:01Z,Folyd,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-08T12:15:58Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-08T13:55:00Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,HEART,2021-10-08T16:47:32Z,a1phyr,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-09T05:56:55Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-09T10:00:59Z,cynecx,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,HEART,2021-10-11T10:30:48Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-11T21:25:52Z,djc,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-12T03:47:30Z,ast-ral,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,HEART,2021-10-21T14:05:59Z,nappa85,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2021-10-22T04:23:37Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,THUMBS_UP,2022-02-28T21:23:48Z,qm3ster,NA https://github.com/rust-lang/rust/pull/89651,MERGED,2021-10-07T22:15:55Z,2021-10-12T03:18:53Z,Add `Poll::ready` and revert stabilization of `task::ready!`,ibraheemdev,d3984e16bf04f8ff886247cbf684041ba623d6ab,4,Rollup merge of #89651 - ibraheemdev:poll-ready r=dtolnay Add `Poll::ready` and revert stabilization of `task::ready!` This PR adds an inherent `ready` method to `Poll` that can be used with the `?` operator as an alternative to the `task::ready!` macro: ```rust let val = ready!(fut.poll(cx)); let val = fut.poll(cx).ready()?; ``` I think this form is a nice non-breaking middle ground between changing the `impl Try for Poll` and adding a separate macro. It looks better than `ready!` in my opinion and it composes well: ```rust let elem = ready!(fut.poll(cx)).pop().unwrap(); let elem = fut.poll(cx).ready()?.pop().unwrap(); ``` The planned stabilization of `ready!` in 1.56 has been reverted because I think this alternate approach is worth considering. r? rust-lang/libs,HEART,2022-02-28T21:23:48Z,qm3ster,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-10-08T14:43:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-10-08T17:20:43Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-10-17T22:11:39Z,est31,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-10-27T14:07:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-10-28T01:19:32Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-11-04T12:55:03Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2021-11-04T20:19:25Z,Milo123459,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2022-01-13T19:17:31Z,rrbutani,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2022-01-13T19:54:06Z,DianaNites,NA https://github.com/rust-lang/rust/pull/89652,MERGED,2021-10-07T22:50:34Z,2021-10-27T12:27:53Z,Add LLVM CFI support to the Rust compiler,rcvalle,a8f6e614f86be429b5862f30e023063f619aeed2,35,"Auto merge of #89652 - rcvalle:rust-cfi r=nagisa Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code ""mixed binaries"" (i.e. for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e. -Clto). Thank you `@eddyb` and `@pcc ` for all the help!",HOORAY,2022-01-26T23:22:26Z,worstpractice,NA https://github.com/rust-lang/rust/pull/89660,CLOSED,2021-10-08T06:34:35Z,2022-06-05T09:51:10Z,[Experiment] Force to generate drop glue of ADT locally,csmoe,NA,NA,NA,THUMBS_UP,2021-10-08T07:44:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89664,MERGED,2021-10-08T08:41:28Z,2021-10-09T19:05:07Z,Add documentation to boxed conversions,timClicks,9f32ab88af7af95efefe0a3990302c6bc4f78ccd,1,Rollup merge of #89664 - timClicks:51430-document-boxed-conversions r=m-ou-se Add documentation to boxed conversions Among other changes documents whether allocations are necessary to complete the type conversion. Part of #51430 supersedes #89199,THUMBS_UP,2021-10-08T09:55:35Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/89664,MERGED,2021-10-08T08:41:28Z,2021-10-09T19:05:07Z,Add documentation to boxed conversions,timClicks,9f32ab88af7af95efefe0a3990302c6bc4f78ccd,1,Rollup merge of #89664 - timClicks:51430-document-boxed-conversions r=m-ou-se Add documentation to boxed conversions Among other changes documents whether allocations are necessary to complete the type conversion. Part of #51430 supersedes #89199,THUMBS_UP,2021-10-08T11:16:07Z,marmeladema,NA https://github.com/rust-lang/rust/pull/89669,MERGED,2021-10-08T14:54:40Z,2021-10-09T00:08:27Z,Remove special-casing of never primitive in rustdoc-json-types,Urgau,4adc8ea2ac7160a82283cac053c5f1ff5d27c7a9,4,Rollup merge of #89669 - Urgau:json-remove-type-never r=GuillaumeGomez Remove special-casing of never primitive in rustdoc-json-types Fixes https://github.com/rust-lang/rust/issues/89349 r? `@GuillaumeGomez`,HEART,2021-10-08T19:02:34Z,camelid,NA https://github.com/rust-lang/rust/pull/89670,MERGED,2021-10-08T15:27:52Z,2021-10-14T02:24:52Z,Improve `std::thread::available_parallelism` docs,yoshuawuyts,06110c0c466e46d48d0bf01b43cf0ad5a01391b2,1,"Rollup merge of #89670 - yoshuawuyts:available-parallelism-docs r=joshtriplett Improve `std::thread::available_parallelism` docs _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR reworks the documentation of `std::thread::available_parallelism` as requested [here](https://github.com/rust-lang/rust/pull/89324#issuecomment-934343254). ## Changes The following changes are made: - We've removed prior mentions of ""hardware threads"" and instead centers the docs around ""parallelism"" as a resource available to a program. - We now provide examples of when `available_parallelism` may return numbers that differ from the number of CPU cores in the host machine. - We now mention that the amount of available parallelism may change over time. - We make note of which platform components we don't take into account which more advanced users may want to take note of. - The example has been updated which should be a bit easier to use. - We've added a docs alias to `num-cpus` which provides similar functionality to `available_parallelism` and is one of the most popular crates on crates.io. --- Thanks! r? `@BurntSushi`",THUMBS_UP,2021-10-09T00:24:24Z,weihanglo,NA https://github.com/rust-lang/rust/pull/89670,MERGED,2021-10-08T15:27:52Z,2021-10-14T02:24:52Z,Improve `std::thread::available_parallelism` docs,yoshuawuyts,06110c0c466e46d48d0bf01b43cf0ad5a01391b2,1,"Rollup merge of #89670 - yoshuawuyts:available-parallelism-docs r=joshtriplett Improve `std::thread::available_parallelism` docs _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR reworks the documentation of `std::thread::available_parallelism` as requested [here](https://github.com/rust-lang/rust/pull/89324#issuecomment-934343254). ## Changes The following changes are made: - We've removed prior mentions of ""hardware threads"" and instead centers the docs around ""parallelism"" as a resource available to a program. - We now provide examples of when `available_parallelism` may return numbers that differ from the number of CPU cores in the host machine. - We now mention that the amount of available parallelism may change over time. - We make note of which platform components we don't take into account which more advanced users may want to take note of. - The example has been updated which should be a bit easier to use. - We've added a docs alias to `num-cpus` which provides similar functionality to `available_parallelism` and is one of the most popular crates on crates.io. --- Thanks! r? `@BurntSushi`",HEART,2021-10-12T07:12:06Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/89670,MERGED,2021-10-08T15:27:52Z,2021-10-14T02:24:52Z,Improve `std::thread::available_parallelism` docs,yoshuawuyts,06110c0c466e46d48d0bf01b43cf0ad5a01391b2,1,"Rollup merge of #89670 - yoshuawuyts:available-parallelism-docs r=joshtriplett Improve `std::thread::available_parallelism` docs _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR reworks the documentation of `std::thread::available_parallelism` as requested [here](https://github.com/rust-lang/rust/pull/89324#issuecomment-934343254). ## Changes The following changes are made: - We've removed prior mentions of ""hardware threads"" and instead centers the docs around ""parallelism"" as a resource available to a program. - We now provide examples of when `available_parallelism` may return numbers that differ from the number of CPU cores in the host machine. - We now mention that the amount of available parallelism may change over time. - We make note of which platform components we don't take into account which more advanced users may want to take note of. - The example has been updated which should be a bit easier to use. - We've added a docs alias to `num-cpus` which provides similar functionality to `available_parallelism` and is one of the most popular crates on crates.io. --- Thanks! r? `@BurntSushi`",THUMBS_UP,2021-10-12T07:12:14Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/89705,MERGED,2021-10-09T16:11:08Z,2021-10-10T22:01:43Z,Cfg hide no_global_oom_handling and no_fp_fmt_parse,nbdd0121,ce6097dfa41f382eecd7ebf19cc58346339bb008,2,Rollup merge of #89705 - nbdd0121:doc r=GuillaumeGomez Cfg hide no_global_oom_handling and no_fp_fmt_parse These are unstable sysroot customisation cfg options that only projects building their own sysroot will use (e.g. Rust-for-linux). Most users shouldn't care. `no_global_oom_handling` can be especially annoying since it's applied on many commonly used alloc crate methods (e.g. `Box::new` `Vec::push`). r? ```@GuillaumeGomez```,THUMBS_UP,2021-10-09T20:14:32Z,Urgau,NA https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HOORAY,2021-10-09T17:11:26Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HOORAY,2021-10-09T18:24:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HOORAY,2021-10-09T19:07:12Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HEART,2021-10-09T19:15:04Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HOORAY,2021-10-10T13:42:41Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HOORAY,2021-10-29T06:24:03Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/89708,OPEN,2021-10-09T17:06:39Z,NA,Introduce MIR summary to avoid loading large bodies without inlining them,cjgillot,NA,NA,NA,HEART,2022-01-16T00:34:40Z,mati865,NA https://github.com/rust-lang/rust/pull/89710,MERGED,2021-10-09T19:33:03Z,2021-10-12T03:18:53Z,Add long explanation for error E0482,sireliah,57504aafe8ade9964df8600249672dbab45dc47f,3,Rollup merge of #89710 - sireliah:e0482 r=GuillaumeGomez Add long explanation for error E0482 This is longer explanation for error E0482 in the #61137. Please take a look and leave some feedback!,THUMBS_UP,2021-10-10T23:50:21Z,mohe2015,NA https://github.com/rust-lang/rust/pull/89710,MERGED,2021-10-09T19:33:03Z,2021-10-12T03:18:53Z,Add long explanation for error E0482,sireliah,57504aafe8ade9964df8600249672dbab45dc47f,3,Rollup merge of #89710 - sireliah:e0482 r=GuillaumeGomez Add long explanation for error E0482 This is longer explanation for error E0482 in the #61137. Please take a look and leave some feedback!,HEART,2021-10-10T23:50:22Z,mohe2015,NA https://github.com/rust-lang/rust/pull/89741,MERGED,2021-10-10T18:14:16Z,2021-11-21T00:49:38Z,Mark `Arc::from_inner` / `Rc::from_inner` as unsafe,sdroege,09d9c098e0b38fb4b41a22a9bc8d19957be0503d,2,Rollup merge of #89741 - sdroege:arc-rc-from-inner-unsafe r=Mark-Simulacrum Mark `Arc::from_inner` / `Rc::from_inner` as unsafe While it's an internal function it is easy to create invalid Arc/Rcs to a dangling pointer with it. Fixes https://github.com/rust-lang/rust/issues/89740,THUMBS_UP,2021-10-11T01:07:20Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89741,MERGED,2021-10-10T18:14:16Z,2021-11-21T00:49:38Z,Mark `Arc::from_inner` / `Rc::from_inner` as unsafe,sdroege,09d9c098e0b38fb4b41a22a9bc8d19957be0503d,2,Rollup merge of #89741 - sdroege:arc-rc-from-inner-unsafe r=Mark-Simulacrum Mark `Arc::from_inner` / `Rc::from_inner` as unsafe While it's an internal function it is easy to create invalid Arc/Rcs to a dangling pointer with it. Fixes https://github.com/rust-lang/rust/issues/89740,THUMBS_UP,2021-10-11T02:50:27Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/89741,MERGED,2021-10-10T18:14:16Z,2021-11-21T00:49:38Z,Mark `Arc::from_inner` / `Rc::from_inner` as unsafe,sdroege,09d9c098e0b38fb4b41a22a9bc8d19957be0503d,2,Rollup merge of #89741 - sdroege:arc-rc-from-inner-unsafe r=Mark-Simulacrum Mark `Arc::from_inner` / `Rc::from_inner` as unsafe While it's an internal function it is easy to create invalid Arc/Rcs to a dangling pointer with it. Fixes https://github.com/rust-lang/rust/issues/89740,THUMBS_UP,2021-11-25T13:11:39Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,EYES,2021-10-11T13:45:29Z,darksv,NA https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,EYES,2021-10-12T06:07:41Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,ROCKET,2021-10-14T10:00:46Z,aschampion,andrew.champion@gmail.com https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,ROCKET,2021-10-14T19:56:48Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,EYES,2021-10-14T20:27:59Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,ROCKET,2021-10-14T21:16:30Z,aviillouz,NA https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,EYES,2021-10-28T13:48:51Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/89745,CLOSED,2021-10-10T19:49:30Z,2021-11-19T14:09:22Z,enum variant support,zhamlin,NA,NA,NA,ROCKET,2021-10-28T13:48:54Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/89747,MERGED,2021-10-10T20:34:54Z,2022-01-20T23:48:14Z,Add MaybeUninit::(slice_)as_bytes(_mut),Amanieu,98cb33894c87d5a92a19b1b1c38d64caa495a197,1,"Rollup merge of #89747 - Amanieu:maybeuninit_bytes r=m-ou-se Add MaybeUninit::(slice_)as_bytes(_mut) This adds methods to convert between `MaybeUninit` and a slice of `MaybeUninit`. This is safe since `MaybeUninit` can correctly handle padding bytes in any `T`. These methods are added: ```rust impl MaybeUninit { pub fn as_bytes(&self) -> &[MaybeUninit]; pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit]; pub fn slice_as_bytes(this: &[MaybeUninit]) -> &[MaybeUninit]; pub fn slice_as_bytes_mut(this: &mut [MaybeUninit]) -> &mut [MaybeUninit]; } ```",THUMBS_UP,2022-01-27T13:36:27Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/89757,MERGED,2021-10-11T03:38:12Z,2021-10-14T02:24:52Z,Use shallow clones for submodules,jyn514,9f0ef184b815318bf044194e150f612a3d898105,1,Rollup merge of #89757 - jyn514:submodule r=Mark-Simulacrum Use shallow clones for submodules This reduces the amount of git history downloaded for submodules from ~67M to ~11M. For comparison a shallow clone of rust-lang/rust is 103M and a deep clone is 740M so this almost halves the amount of history necessary if you made a shallow clone to start and it's a significant reduction even if not. Closes https://github.com/rust-lang/rust/issues/63978. r? `@Mark-Simulacrum`,THUMBS_UP,2021-10-11T03:38:58Z,Folyd,NA https://github.com/rust-lang/rust/pull/89757,MERGED,2021-10-11T03:38:12Z,2021-10-14T02:24:52Z,Use shallow clones for submodules,jyn514,9f0ef184b815318bf044194e150f612a3d898105,1,Rollup merge of #89757 - jyn514:submodule r=Mark-Simulacrum Use shallow clones for submodules This reduces the amount of git history downloaded for submodules from ~67M to ~11M. For comparison a shallow clone of rust-lang/rust is 103M and a deep clone is 740M so this almost halves the amount of history necessary if you made a shallow clone to start and it's a significant reduction even if not. Closes https://github.com/rust-lang/rust/issues/63978. r? `@Mark-Simulacrum`,THUMBS_UP,2021-10-11T06:50:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89757,MERGED,2021-10-11T03:38:12Z,2021-10-14T02:24:52Z,Use shallow clones for submodules,jyn514,9f0ef184b815318bf044194e150f612a3d898105,1,Rollup merge of #89757 - jyn514:submodule r=Mark-Simulacrum Use shallow clones for submodules This reduces the amount of git history downloaded for submodules from ~67M to ~11M. For comparison a shallow clone of rust-lang/rust is 103M and a deep clone is 740M so this almost halves the amount of history necessary if you made a shallow clone to start and it's a significant reduction even if not. Closes https://github.com/rust-lang/rust/issues/63978. r? `@Mark-Simulacrum`,THUMBS_UP,2021-10-13T16:14:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89759,MERGED,2021-10-11T04:11:32Z,2021-10-14T02:24:52Z,Assemble the compiler when running `x.py build`,jyn514,204bd6e2156c01ba183532294b6dd9366e0c0a04,2,Rollup merge of #89759 - jyn514:x-build-assemble r=Mark-Simulacrum Assemble the compiler when running `x.py build` Previously there was no way to actually get binaries in `build/$TARGET/stage1/bin` without building the standard library. This makes it possible to build just the compiler. This can be useful when the standard library isn't actually necessary for trying out your tests (e.g. a bug that can be reproduced with only a `no_core` crate). Closes https://github.com/rust-lang/rust/issues/73519.,THUMBS_UP,2021-10-17T20:02:01Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/89762,CLOSED,2021-10-11T08:54:24Z,2022-04-29T19:52:03Z,Change default panic strategy to abort for wasm32-unknown-emscripten,nedv-eu,NA,NA,NA,THUMBS_UP,2021-10-26T17:35:38Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/89782,MERGED,2021-10-11T19:32:06Z,2021-10-13T16:42:57Z,Improve CJK font in rustdoc,NA,NA,NA,NA,EYES,2021-10-11T20:25:33Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/89786,MERGED,2021-10-11T20:17:22Z,2021-10-31T15:45:38Z,Add #[must_use] to len and is_empty,jkugelman,88e5ae2dd3cf4a0bbb5af69ef70e80d5dc7b462c,14,Rollup merge of #89786 - jkugelman:must-use-len-and-is_empty r=joshtriplett Add #[must_use] to len and is_empty Parent issue: #89692 r? `@joshtriplett`,THUMBS_UP,2021-10-12T23:59:14Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/89794,MERGED,2021-10-11T23:09:55Z,2021-10-13T16:42:57Z,Add #[must_use] to to_value conversions,jkugelman,c1bde6e4b693b09c3b36c0a2c9f9bab675148fa6,6,Rollup merge of #89794 - jkugelman:must-use-to_value-conversions r=joshtriplett Add #[must_use] to to_value conversions `NonNull::cast` snuck in when I wasn't looking. What a scamp! Parent issue: #89692 r? ````@joshtriplett````,LAUGH,2021-10-12T04:42:43Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89815,MERGED,2021-10-12T13:08:54Z,2021-10-14T05:24:04Z,Associated consts sidebar,GuillaumeGomez,7807a694c2f079fd3f395821bcc357eee8650071,2,Auto merge of #89815 - GuillaumeGomez:associated-consts-sidebar r=notriddle Associated consts sidebar Fixes #89354. A screenshot with `f32`: ![Screenshot from 2021-10-12 15-07-57](https://user-images.githubusercontent.com/3050060/136962078-5faf7b87-7ea5-4d7a-99a4-b2afd77b78e2.png),HEART,2021-10-12T18:05:51Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/89815,MERGED,2021-10-12T13:08:54Z,2021-10-14T05:24:04Z,Associated consts sidebar,GuillaumeGomez,7807a694c2f079fd3f395821bcc357eee8650071,2,Auto merge of #89815 - GuillaumeGomez:associated-consts-sidebar r=notriddle Associated consts sidebar Fixes #89354. A screenshot with `f32`: ![Screenshot from 2021-10-12 15-07-57](https://user-images.githubusercontent.com/3050060/136962078-5faf7b87-7ea5-4d7a-99a4-b2afd77b78e2.png),HEART,2021-10-13T15:20:43Z,taiki-e,NA https://github.com/rust-lang/rust/pull/89815,MERGED,2021-10-12T13:08:54Z,2021-10-14T05:24:04Z,Associated consts sidebar,GuillaumeGomez,7807a694c2f079fd3f395821bcc357eee8650071,2,Auto merge of #89815 - GuillaumeGomez:associated-consts-sidebar r=notriddle Associated consts sidebar Fixes #89354. A screenshot with `f32`: ![Screenshot from 2021-10-12 15-07-57](https://user-images.githubusercontent.com/3050060/136962078-5faf7b87-7ea5-4d7a-99a4-b2afd77b78e2.png),HEART,2021-10-14T03:02:22Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/89815,MERGED,2021-10-12T13:08:54Z,2021-10-14T05:24:04Z,Associated consts sidebar,GuillaumeGomez,7807a694c2f079fd3f395821bcc357eee8650071,2,Auto merge of #89815 - GuillaumeGomez:associated-consts-sidebar r=notriddle Associated consts sidebar Fixes #89354. A screenshot with `f32`: ![Screenshot from 2021-10-12 15-07-57](https://user-images.githubusercontent.com/3050060/136962078-5faf7b87-7ea5-4d7a-99a4-b2afd77b78e2.png),HEART,2021-10-22T01:34:02Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/89815,MERGED,2021-10-12T13:08:54Z,2021-10-14T05:24:04Z,Associated consts sidebar,GuillaumeGomez,7807a694c2f079fd3f395821bcc357eee8650071,2,Auto merge of #89815 - GuillaumeGomez:associated-consts-sidebar r=notriddle Associated consts sidebar Fixes #89354. A screenshot with `f32`: ![Screenshot from 2021-10-12 15-07-57](https://user-images.githubusercontent.com/3050060/136962078-5faf7b87-7ea5-4d7a-99a4-b2afd77b78e2.png),HEART,2021-10-24T03:31:44Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/89817,MERGED,2021-10-12T13:22:15Z,2021-10-13T16:42:57Z,Add #[inline] to int log10 functions.,m-ou-se,59ebfdd7e014c7c9adff21b8d0051408c172b375,1,Rollup merge of #89817 - m-ou-se:int-log-10-inline r=the8472 Add #[inline] to int log10 functions.,HEART,2021-10-12T16:53:13Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/89817,MERGED,2021-10-12T13:22:15Z,2021-10-13T16:42:57Z,Add #[inline] to int log10 functions.,m-ou-se,59ebfdd7e014c7c9adff21b8d0051408c172b375,1,Rollup merge of #89817 - m-ou-se:int-log-10-inline r=the8472 Add #[inline] to int log10 functions.,HEART,2021-10-13T07:30:49Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2021-12-16T18:48:32Z,lqd,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-04T18:36:30Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-04T23:06:45Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-05T04:15:04Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,THUMBS_UP,2022-01-05T04:15:05Z,joshsleeper,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-06T00:06:45Z,faptc,NA https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-10T06:31:41Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,THUMBS_UP,2022-01-10T06:31:44Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/89819,MERGED,2021-10-12T13:38:32Z,2022-01-06T15:30:53Z,cg: split dwarf for crate dependencies,davidtwco,a77cc64af491a31db224109a76b9b81cd26cd07c,18,Auto merge of #89819 - davidtwco:issue-81024-multiple-crates-multiple-dwarves r=nagisa cg: split dwarf for crate dependencies Fixes #81024. - In #79570 `-Z split-dwarf-kind={none single split}` was replaced by `-C split-debuginfo={off packed unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split respectively. On Unix `-C split-debuginfo=packed` will put debuginfo in object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo in dwarf object files and won't package it. In the initial implementation of Split DWARF split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However both split and single modes could be packaged or not the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). In the first commit of this PR I re-introduce a `-Z split-dwarf-kind` flag which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). - Split DWARF packaging requires all of the object files to exist including those in dependencies. ~~Therefore the second commit of this PR makes rustc keep all objects or dwarf objects for unpacked mode and if the crate is a dependency in packed mode (determined by heuristic: if no linking is taking place) then objects or dwarf objects are kept. Objects are kept if `-Z split-dwarf-kind` is `SplitDwarfKind::Single` and dwarf objects if `SplitDwarfKind::Split`.~~ ~~There are other approaches that could be taken to supporting packed Split DWARF with crate dependencies but this seemed like the least complicated and was contained to only rustc. Other potential approaches are described in https://github.com/rust-lang/rust/issues/81024#issuecomment-760478223 I'm happy to change the approach I've taken here if it isn't what we're looking for.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867 for the current approach. - ~~There's still a dependency on `llvm-dwp` after this change which [we probably want to move away from](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/llvm-dwp.20is.20not.20recommended) but that seems out-of-scope for this PR. Ideally Split DWARF (in packed or unpacked modes) will be usable on nightly after this lands. If there aren't any bugs reported then it's possible we could allow Split DWARF to be used on stable after this change it depends whether or not switching away from `llvm-dwp` later would break any guarantees or whether we'd want to change how we handle this cross-crate case in future.~~ See https://github.com/rust-lang/rust/pull/89819#issuecomment-985671867. r? `@nagisa` cc `@alexcrichton`,HOORAY,2022-01-13T22:09:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89823,MERGED,2021-10-12T15:17:20Z,2021-10-14T19:23:10Z,Switch order of terms to prevent overflow,jackh726,29081f95e9c7db9abd52eeeb794472a6636c9778,1,Rollup merge of #89823 - jackh726:project-overflow r=oli-obk Switch order of terms to prevent overflow Fixes #89639 r? ``@pnkfelix``,THUMBS_UP,2021-10-13T02:06:42Z,hkratz,NA https://github.com/rust-lang/rust/pull/89831,MERGED,2021-10-12T21:32:56Z,2021-12-19T06:26:05Z,Re-introduce concept of projection cache 'completion',Aaron1011,d6cffe41b59feaab5fb92bb320e60586202c9950,5,Auto merge of #89831 - Aaron1011:project-caching-speedup r=jackh726 Re-introduce concept of projection cache 'completion' Instead of clearing out the cache entirely we store the intermediate evaluation result into the cache entry. This accomplishes several things: * We avoid the performance hit associated with re-evaluating the sub-obligations * We avoid causing issues with incremental compilation since the final evaluation result is always the same * We avoid affecting other uses of the same `InferCtxt` which might care about 'side effects' from processing the sub-obligations (e g. region constraints). Only code that is specifically aware of the new 'complete' code is affected,THUMBS_UP,2021-10-13T05:11:44Z,nayato,NA https://github.com/rust-lang/rust/pull/89831,MERGED,2021-10-12T21:32:56Z,2021-12-19T06:26:05Z,Re-introduce concept of projection cache 'completion',Aaron1011,d6cffe41b59feaab5fb92bb320e60586202c9950,5,Auto merge of #89831 - Aaron1011:project-caching-speedup r=jackh726 Re-introduce concept of projection cache 'completion' Instead of clearing out the cache entirely we store the intermediate evaluation result into the cache entry. This accomplishes several things: * We avoid the performance hit associated with re-evaluating the sub-obligations * We avoid causing issues with incremental compilation since the final evaluation result is always the same * We avoid affecting other uses of the same `InferCtxt` which might care about 'side effects' from processing the sub-obligations (e g. region constraints). Only code that is specifically aware of the new 'complete' code is affected,THUMBS_UP,2021-10-13T06:21:52Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/89831,MERGED,2021-10-12T21:32:56Z,2021-12-19T06:26:05Z,Re-introduce concept of projection cache 'completion',Aaron1011,d6cffe41b59feaab5fb92bb320e60586202c9950,5,Auto merge of #89831 - Aaron1011:project-caching-speedup r=jackh726 Re-introduce concept of projection cache 'completion' Instead of clearing out the cache entirely we store the intermediate evaluation result into the cache entry. This accomplishes several things: * We avoid the performance hit associated with re-evaluating the sub-obligations * We avoid causing issues with incremental compilation since the final evaluation result is always the same * We avoid affecting other uses of the same `InferCtxt` which might care about 'side effects' from processing the sub-obligations (e g. region constraints). Only code that is specifically aware of the new 'complete' code is affected,HEART,2021-10-17T23:00:35Z,olix0r,ver@buoyant.io https://github.com/rust-lang/rust/pull/89831,MERGED,2021-10-12T21:32:56Z,2021-12-19T06:26:05Z,Re-introduce concept of projection cache 'completion',Aaron1011,d6cffe41b59feaab5fb92bb320e60586202c9950,5,Auto merge of #89831 - Aaron1011:project-caching-speedup r=jackh726 Re-introduce concept of projection cache 'completion' Instead of clearing out the cache entirely we store the intermediate evaluation result into the cache entry. This accomplishes several things: * We avoid the performance hit associated with re-evaluating the sub-obligations * We avoid causing issues with incremental compilation since the final evaluation result is always the same * We avoid affecting other uses of the same `InferCtxt` which might care about 'side effects' from processing the sub-obligations (e g. region constraints). Only code that is specifically aware of the new 'complete' code is affected,THUMBS_UP,2021-10-22T21:32:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89835,MERGED,2021-10-12T23:28:03Z,2021-10-31T12:17:09Z,Add #[must_use] to expensive computations,jkugelman,a26b1d2259ef96977c76d5e3a15a6dbf0371d91c,11,"Rollup merge of #89835 - jkugelman:must-use-expensive-computations r=joshtriplett Add #[must_use] to expensive computations The unifying theme for this commit is weak admittedly. I put together a list of ""expensive"" functions when I originally proposed this whole effort but nobody's cared about that criterion. Still it's a decent way to bite off a not-too-big chunk of work. Given the grab bag nature of this commit the messages I used vary quite a bit. I'm open to wording changes. For some reason clippy flagged four `BTreeSet` methods but didn't say boo about equivalent ones on `HashSet`. I stared at them for a while but I can't figure out the difference so I added the `HashSet` ones in. ```rust // Flagged by clippy. alloc::collections::btree_set::BTreeSet fn difference<'a>(&'a self other: &'a BTreeSet) -> Difference<'a T>; alloc::collections::btree_set::BTreeSet fn symmetric_difference<'a>(&'a self other: &'a BTreeSet) -> SymmetricDifference<'a T> alloc::collections::btree_set::BTreeSet fn intersection<'a>(&'a self other: &'a BTreeSet) -> Intersection<'a T>; alloc::collections::btree_set::BTreeSet fn union<'a>(&'a self other: &'a BTreeSet) -> Union<'a T>; // Ignored by clippy but not by me. std::collections::HashSet fn difference<'a>(&'a self other: &'a HashSet) -> Difference<'a T S>; std::collections::HashSet fn symmetric_difference<'a>(&'a self other: &'a HashSet) -> SymmetricDifference<'a T S> std::collections::HashSet fn intersection<'a>(&'a self other: &'a HashSet) -> Intersection<'a T S>; std::collections::HashSet fn union<'a>(&'a self other: &'a HashSet) -> Union<'a T S>; ``` Parent issue: #89692 r? ```@joshtriplett```",THUMBS_UP,2021-10-13T00:00:06Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/89841,MERGED,2021-10-13T07:52:59Z,2021-12-18T01:12:16Z,Implement let-else type annotations natively,cormacrelf,dde825db464b08d6f572766579dfb629b837368c,46,Auto merge of #89841 - cormacrelf:let-else-typed r=nagisa Implement let-else type annotations natively Tracking issue: #87335 Fixes #89688 fixes #89807 edit: fixes #89960 as well As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082 the previous desugaring moved the let-else scrutinee into a dummy variable which meant if you wanted to refer to it again in the else block it had moved. This introduces a new hir type ~~`hir::LetExpr`~~ `hir::Let` which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body specifically: * `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local` assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other so at least we know they're the same)~~ * It reuses the code in `check_decl_local` to typecheck the `hir::Let` simply returning 'bool' for the expression type after doing that. * ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type` and then imitates check_decl_local's pattern checking~~ * ~~`demand_scrutinee_type` (the blindest change for me please give this extra scrutiny) uses this local type instead of of creating a new one~~ * ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down need to pass the type there too. And apparently this Expectation API already exists.~~ Some other misc notes: * ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~ * in `rustc_ast_lowering/src/block.rs` I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this I don't know.,THUMBS_UP,2021-10-13T12:05:35Z,camsteffen,NA https://github.com/rust-lang/rust/pull/89841,MERGED,2021-10-13T07:52:59Z,2021-12-18T01:12:16Z,Implement let-else type annotations natively,cormacrelf,dde825db464b08d6f572766579dfb629b837368c,46,Auto merge of #89841 - cormacrelf:let-else-typed r=nagisa Implement let-else type annotations natively Tracking issue: #87335 Fixes #89688 fixes #89807 edit: fixes #89960 as well As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082 the previous desugaring moved the let-else scrutinee into a dummy variable which meant if you wanted to refer to it again in the else block it had moved. This introduces a new hir type ~~`hir::LetExpr`~~ `hir::Let` which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body specifically: * `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local` assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other so at least we know they're the same)~~ * It reuses the code in `check_decl_local` to typecheck the `hir::Let` simply returning 'bool' for the expression type after doing that. * ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type` and then imitates check_decl_local's pattern checking~~ * ~~`demand_scrutinee_type` (the blindest change for me please give this extra scrutiny) uses this local type instead of of creating a new one~~ * ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down need to pass the type there too. And apparently this Expectation API already exists.~~ Some other misc notes: * ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~ * in `rustc_ast_lowering/src/block.rs` I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this I don't know.,THUMBS_UP,2021-10-17T07:16:40Z,est31,NA https://github.com/rust-lang/rust/pull/89841,MERGED,2021-10-13T07:52:59Z,2021-12-18T01:12:16Z,Implement let-else type annotations natively,cormacrelf,dde825db464b08d6f572766579dfb629b837368c,46,Auto merge of #89841 - cormacrelf:let-else-typed r=nagisa Implement let-else type annotations natively Tracking issue: #87335 Fixes #89688 fixes #89807 edit: fixes #89960 as well As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082 the previous desugaring moved the let-else scrutinee into a dummy variable which meant if you wanted to refer to it again in the else block it had moved. This introduces a new hir type ~~`hir::LetExpr`~~ `hir::Let` which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body specifically: * `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local` assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other so at least we know they're the same)~~ * It reuses the code in `check_decl_local` to typecheck the `hir::Let` simply returning 'bool' for the expression type after doing that. * ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type` and then imitates check_decl_local's pattern checking~~ * ~~`demand_scrutinee_type` (the blindest change for me please give this extra scrutiny) uses this local type instead of of creating a new one~~ * ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down need to pass the type there too. And apparently this Expectation API already exists.~~ Some other misc notes: * ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~ * in `rustc_ast_lowering/src/block.rs` I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this I don't know.,HEART,2021-12-12T18:37:56Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89865,MERGED,2021-10-13T23:00:08Z,2021-10-14T19:23:10Z,Allow static linking LLVM with ThinLTO,tmandry,0888c6dc7804ac5944d705c6aca1fdecbbefba82,1,Rollup merge of #89865 - tmandry:llvm-static r=Mark-Simulacrum Allow static linking LLVM with ThinLTO There's no reason not to allow this if the user wants it. It works at least in a local build on linux host. For our use case we're happy to spend more time building the compiler if it creates a speedup every time we run it and we've observed speedups like this with clang.,THUMBS_UP,2021-10-13T23:45:22Z,hkratz,NA https://github.com/rust-lang/rust/pull/89876,MERGED,2021-10-14T08:41:30Z,2021-10-30T16:22:50Z,Make most std::ops traits const on numeric types,AlexApps99,20bb93210d1ae4331f8c66efff67ef3e84bd66a2,6,Rollup merge of #89876 - AlexApps99:const_ops r=oli-obk Make most std::ops traits const on numeric types This PR makes existing implementations of `std::ops` traits (`Add` `Sub` etc) [`impl const`](https://github.com/rust-lang/rust/issues/67792) where possible. This affects: - All numeric primitives (`u*` `i*` `f*`) - `NonZero*` - `Wrapping` This is under the `rustc_const_unstable` feature `const_ops`. I will write tests once I know what can and can't be kept for the final version of this PR. Since this is my first PR to rustc (and hopefully one of many) please give me feedback on how to better handle the PR process wherever possible. Thanks [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Const.20std.3A.3Aops.20traits.20PR),HEART,2021-10-14T08:46:01Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/89876,MERGED,2021-10-14T08:41:30Z,2021-10-30T16:22:50Z,Make most std::ops traits const on numeric types,AlexApps99,20bb93210d1ae4331f8c66efff67ef3e84bd66a2,6,Rollup merge of #89876 - AlexApps99:const_ops r=oli-obk Make most std::ops traits const on numeric types This PR makes existing implementations of `std::ops` traits (`Add` `Sub` etc) [`impl const`](https://github.com/rust-lang/rust/issues/67792) where possible. This affects: - All numeric primitives (`u*` `i*` `f*`) - `NonZero*` - `Wrapping` This is under the `rustc_const_unstable` feature `const_ops`. I will write tests once I know what can and can't be kept for the final version of this PR. Since this is my first PR to rustc (and hopefully one of many) please give me feedback on how to better handle the PR process wherever possible. Thanks [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Const.20std.3A.3Aops.20traits.20PR),HEART,2021-11-04T08:16:20Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/89876,MERGED,2021-10-14T08:41:30Z,2021-10-30T16:22:50Z,Make most std::ops traits const on numeric types,AlexApps99,20bb93210d1ae4331f8c66efff67ef3e84bd66a2,6,Rollup merge of #89876 - AlexApps99:const_ops r=oli-obk Make most std::ops traits const on numeric types This PR makes existing implementations of `std::ops` traits (`Add` `Sub` etc) [`impl const`](https://github.com/rust-lang/rust/issues/67792) where possible. This affects: - All numeric primitives (`u*` `i*` `f*`) - `NonZero*` - `Wrapping` This is under the `rustc_const_unstable` feature `const_ops`. I will write tests once I know what can and can't be kept for the final version of this PR. Since this is my first PR to rustc (and hopefully one of many) please give me feedback on how to better handle the PR process wherever possible. Thanks [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Const.20std.3A.3Aops.20traits.20PR),HEART,2021-11-04T12:55:33Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89876,MERGED,2021-10-14T08:41:30Z,2021-10-30T16:22:50Z,Make most std::ops traits const on numeric types,AlexApps99,20bb93210d1ae4331f8c66efff67ef3e84bd66a2,6,Rollup merge of #89876 - AlexApps99:const_ops r=oli-obk Make most std::ops traits const on numeric types This PR makes existing implementations of `std::ops` traits (`Add` `Sub` etc) [`impl const`](https://github.com/rust-lang/rust/issues/67792) where possible. This affects: - All numeric primitives (`u*` `i*` `f*`) - `NonZero*` - `Wrapping` This is under the `rustc_const_unstable` feature `const_ops`. I will write tests once I know what can and can't be kept for the final version of this PR. Since this is my first PR to rustc (and hopefully one of many) please give me feedback on how to better handle the PR process wherever possible. Thanks [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Const.20std.3A.3Aops.20traits.20PR),THUMBS_UP,2022-01-19T14:54:47Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/89876,MERGED,2021-10-14T08:41:30Z,2021-10-30T16:22:50Z,Make most std::ops traits const on numeric types,AlexApps99,20bb93210d1ae4331f8c66efff67ef3e84bd66a2,6,Rollup merge of #89876 - AlexApps99:const_ops r=oli-obk Make most std::ops traits const on numeric types This PR makes existing implementations of `std::ops` traits (`Add` `Sub` etc) [`impl const`](https://github.com/rust-lang/rust/issues/67792) where possible. This affects: - All numeric primitives (`u*` `i*` `f*`) - `NonZero*` - `Wrapping` This is under the `rustc_const_unstable` feature `const_ops`. I will write tests once I know what can and can't be kept for the final version of this PR. Since this is my first PR to rustc (and hopefully one of many) please give me feedback on how to better handle the PR process wherever possible. Thanks [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Const.20std.3A.3Aops.20traits.20PR),HEART,2022-01-19T14:54:50Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/89887,MERGED,2021-10-14T17:40:42Z,2022-02-24T09:37:30Z,Change `char` type in debuginfo to DW_ATE_UTF,arlosi,77a8e60dd7285423815002a747ce24602936f59b,4,Rollup merge of #89887 - arlosi:char-debug r=wesleywiser Change `char` type in debuginfo to DW_ATE_UTF Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`. Clang also uses the DW_ATE_UTF for `char32_t` in C++. This fixes the display of the `char` type in the Windows debuggers. Without this change the variable did not show in the locals window. ![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png) LLDB 13 is also able to display the char value when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8 bit_size = 32` r? `@wesleywiser`,THUMBS_UP,2021-10-14T19:01:18Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/89887,MERGED,2021-10-14T17:40:42Z,2022-02-24T09:37:30Z,Change `char` type in debuginfo to DW_ATE_UTF,arlosi,77a8e60dd7285423815002a747ce24602936f59b,4,Rollup merge of #89887 - arlosi:char-debug r=wesleywiser Change `char` type in debuginfo to DW_ATE_UTF Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`. Clang also uses the DW_ATE_UTF for `char32_t` in C++. This fixes the display of the `char` type in the Windows debuggers. Without this change the variable did not show in the locals window. ![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png) LLDB 13 is also able to display the char value when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8 bit_size = 32` r? `@wesleywiser`,THUMBS_UP,2021-10-15T10:07:36Z,xTachyon,NA https://github.com/rust-lang/rust/pull/89887,MERGED,2021-10-14T17:40:42Z,2022-02-24T09:37:30Z,Change `char` type in debuginfo to DW_ATE_UTF,arlosi,77a8e60dd7285423815002a747ce24602936f59b,4,Rollup merge of #89887 - arlosi:char-debug r=wesleywiser Change `char` type in debuginfo to DW_ATE_UTF Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`. Clang also uses the DW_ATE_UTF for `char32_t` in C++. This fixes the display of the `char` type in the Windows debuggers. Without this change the variable did not show in the locals window. ![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png) LLDB 13 is also able to display the char value when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8 bit_size = 32` r? `@wesleywiser`,THUMBS_UP,2021-10-19T16:49:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/89887,MERGED,2021-10-14T17:40:42Z,2022-02-24T09:37:30Z,Change `char` type in debuginfo to DW_ATE_UTF,arlosi,77a8e60dd7285423815002a747ce24602936f59b,4,Rollup merge of #89887 - arlosi:char-debug r=wesleywiser Change `char` type in debuginfo to DW_ATE_UTF Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`. Clang also uses the DW_ATE_UTF for `char32_t` in C++. This fixes the display of the `char` type in the Windows debuggers. Without this change the variable did not show in the locals window. ![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png) LLDB 13 is also able to display the char value when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8 bit_size = 32` r? `@wesleywiser`,THUMBS_UP,2022-02-24T10:11:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89887,MERGED,2021-10-14T17:40:42Z,2022-02-24T09:37:30Z,Change `char` type in debuginfo to DW_ATE_UTF,arlosi,77a8e60dd7285423815002a747ce24602936f59b,4,Rollup merge of #89887 - arlosi:char-debug r=wesleywiser Change `char` type in debuginfo to DW_ATE_UTF Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`. Clang also uses the DW_ATE_UTF for `char32_t` in C++. This fixes the display of the `char` type in the Windows debuggers. Without this change the variable did not show in the locals window. ![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png) LLDB 13 is also able to display the char value when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8 bit_size = 32` r? `@wesleywiser`,THUMBS_UP,2022-05-17T09:33:33Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/89889,MERGED,2021-10-14T17:58:19Z,2021-10-25T11:31:52Z,"Use the ""nice E0277 errors""[1] for `!Send` `impl Future` from foreign crate",estebank,b25172b5048dce325e44b2e1c381acfe3815f957,3,"Rollup merge of #89889 - estebank:unmet-send-bound-on-foreign-future r=tmandry Use the ""nice E0277 errors""[1] for `!Send` `impl Future` from foreign crate Partly address #78543 by making the error quieter. We don't have access to the `typeck` tables from foreign crates so we used to completely skip the new code when checking foreign crates. Now we carry on and don't provide as nice output (we don't clarify *what* is making the `Future: !Send`) but at least we no longer emit a sea of derived obligations in the output. [1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html r? `@tmandry`",THUMBS_UP,2021-10-28T06:04:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/89891,OPEN,2021-10-14T18:57:13Z,NA,`alloc`: add unstable cfg features `no_rc` and `no_sync`,ojeda,NA,NA,NA,THUMBS_UP,2022-06-23T09:10:36Z,bb010g,NA https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2021-10-14T20:14:28Z,estebank,NA https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2021-10-15T06:04:07Z,C0RR1T,NA https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2021-10-15T08:40:14Z,angelsflyinhell,angelsflyinhell@namespace.media https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2021-10-15T12:16:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2022-02-22T16:35:17Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2022-02-22T18:36:40Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/89892,MERGED,2021-10-14T20:02:34Z,2022-02-19T05:08:23Z,Suggest `impl Trait` return type when incorrectly using a generic return type,Nilstrieb,f8b83a2aa60d60b60386ef460071261963c8b988,7,Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait r=jackh726 Suggest `impl Trait` return type when incorrectly using a generic return type Address #85991 When there is a type mismatch error and the return type is generic and that generic parameter is not used in the function parameters suggest replacing that generic with the `impl Trait` syntax. r? `@estebank`,HEART,2022-02-24T23:29:18Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/89895,MERGED,2021-10-14T21:44:39Z,2021-10-22T17:32:24Z,Don't mark for loop iter expression as desugared,camsteffen,91fb223f5913ff44902e818c8d26b6bf06e666b6,6,Rollup merge of #89895 - camsteffen:for-loop-head-span r=davidtwco Don't mark for loop iter expression as desugared We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.,HEART,2021-10-14T21:50:36Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/89895,MERGED,2021-10-14T21:44:39Z,2021-10-22T17:32:24Z,Don't mark for loop iter expression as desugared,camsteffen,91fb223f5913ff44902e818c8d26b6bf06e666b6,6,Rollup merge of #89895 - camsteffen:for-loop-head-span r=davidtwco Don't mark for loop iter expression as desugared We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.,HEART,2021-10-15T16:32:02Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/89912,MERGED,2021-10-15T15:01:53Z,2021-10-16T09:35:48Z,emitter: current substitution can be multi-line,davidtwco,27a7ced29f952fc73adb25231f52c8b2d9535497,3,Rollup merge of #89912 - davidtwco:issue-89280-split-lines-multiple-lines r=oli-obk emitter: current substitution can be multi-line Fixes #89280. In `splice_lines` there is some arithmetic to compute the required alignment such that future substitutions in a suggestion are aligned correctly. However this assumed that the current substitution's span was only on a single line. In circumstances where this was not true it could result in a arithmetic overflow when the substitution's end column was less than the substitution's start column. r? ````@oli-obk````,HEART,2021-10-15T19:38:08Z,camsteffen,NA https://github.com/rust-lang/rust/pull/89912,MERGED,2021-10-15T15:01:53Z,2021-10-16T09:35:48Z,emitter: current substitution can be multi-line,davidtwco,27a7ced29f952fc73adb25231f52c8b2d9535497,3,Rollup merge of #89912 - davidtwco:issue-89280-split-lines-multiple-lines r=oli-obk emitter: current substitution can be multi-line Fixes #89280. In `splice_lines` there is some arithmetic to compute the required alignment such that future substitutions in a suggestion are aligned correctly. However this assumed that the current substitution's span was only on a single line. In circumstances where this was not true it could result in a arithmetic overflow when the substitution's end column was less than the substitution's start column. r? ````@oli-obk````,HEART,2021-10-15T20:31:56Z,hkratz,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T16:30:25Z,marmeladema,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T16:49:38Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T17:05:33Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T17:58:56Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-15T17:58:59Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-15T18:18:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T18:18:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-15T19:15:22Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-16T21:28:31Z,mati865,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-16T21:28:33Z,mati865,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-17T21:22:45Z,est31,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-17T21:22:45Z,est31,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-18T08:58:02Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-18T18:49:58Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-10-18T18:49:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-10-19T13:40:36Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-11-01T14:59:05Z,pierwill,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2021-11-01T14:59:06Z,pierwill,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2021-11-05T01:36:18Z,tux3,NA https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HEART,2022-03-03T19:02:10Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/89917,OPEN,2021-10-15T16:00:43Z,NA,sess: default to v0 symbol mangling,davidtwco,NA,NA,NA,HOORAY,2022-03-12T18:44:16Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/89920,MERGED,2021-10-15T17:19:40Z,2021-10-23T09:21:44Z,Implement -Z location-detail flag,hudson-ayers,8fb194c86f100a443b6e637f0ff8e4c0148a4f05,13,Rollup merge of #89920 - hudson-ayers:location-detail-control r=davidtwco Implement -Z location-detail flag This PR implements the `-Z location-detail` flag as described in https://github.com/rust-lang/rfcs/pull/2091 . `-Z location-detail=val` controls what location details are tracked when using `caller_location`. This allows users to control what location details are printed as part of panic messages by allowing them to exclude any combination of filenames line numbers and column numbers. This option is intended to provide users with a way to mitigate the size impact of `#[track_caller]`. Some measurements of the savings of this approach on an embedded binary can be found here: https://github.com/rust-lang/rust/issues/70579#issuecomment-942556822 . Closes #70580 (unless people want to leave that open as a place for discussion of further improvements). This is my first real PR to rust so any help correcting mistakes / understanding side effects / improving my tests is appreciated :) I have one question: RFC 2091 specified this as a debugging option (I think that is what -Z implies?). Does that mean this can never be stabilized without a separate MCP? If so do I need to submit an MCP now or is the initial RFC specifying this option sufficient for this to be merged as is and then an MCP would be needed for eventual stabilization?,THUMBS_UP,2021-10-15T17:44:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_DOWN,2021-10-16T08:57:38Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-10-16T10:38:48Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-10-17T10:47:36Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-10-18T16:51:12Z,Lokathor,NA https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,EYES,2021-10-18T18:00:28Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-12-16T14:15:31Z,kangalioo,NA https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,EYES,2021-12-16T18:07:57Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_DOWN,2021-12-16T18:08:06Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-12-16T20:54:06Z,Xaeroxe,kieseljake@gmail.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,EYES,2021-12-17T01:06:00Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,EYES,2021-12-17T02:01:04Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2021-12-17T04:17:14Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-01-07T06:37:43Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-01-16T20:37:18Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-01-31T23:35:14Z,olix0r,ver@buoyant.io https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-04-04T23:06:59Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-04-07T14:43:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89926,MERGED,2021-10-15T22:03:23Z,2022-02-13T09:29:19Z,make `Instant::{duration_since elapsed sub}` saturating and remove workarounds,the8472,92613a25fc2c3a8f563025050c082f49b8a38019,10,Rollup merge of #89926 - the8472:saturate-instant r=Mark-Simulacrum make `Instant::{duration_since elapsed sub}` saturating and remove workarounds This removes all mutex/atomic-based workarounds for non-monotonic clocks and makes the previously panicking methods saturating instead. Additionally `saturating_duration_since` becomes deprecated since `duration_since` now fills that role. Effectively this moves the fixup from `Instant` construction to the comparisons. This has some observable effects especially on platforms without monotonic clocks: * Incorrectly ordered Instant comparisons no longer panic in release mode. This could hide some programming errors but since debug mode still panics tests can still catch them. * `checked_duration_since` will now return `None` in more cases. Previously it only happened when one compared instants obtained in the wrong order or manually created ones. Now it also does on backslides. * non-monotonic intervals will not be transitive i.e. `b.duration_since(a) + c.duration_since(b) != c.duration_since(a)` The upsides are reduced complexity and lower overhead of `Instant::now`. ## Motivation Currently we must choose between two poisons. One is high worst-case latency and jitter of `Instant::now()` due to explicit synchronization; see #83093 for benchmarks the worst-case overhead is > 100x. The other is sporadic panics on specific rare combinations of CPU/hypervisor/operating system due to platform bugs. Use-cases where low-overhead fine-grained timestamps are needed - such as syscall tracing performance profiles or sensor data acquisition (drone flight controllers were mentioned in a libs meeting) in multi-threaded programs - are negatively impacted by the synchronization. The panics are user-visible (program crashes) hard to reproduce and can be triggered by any dependency that might be using Instants for any reason. A solution that is fast _and_ doesn't panic is desirable. ---- closes #84448 closes #86470,THUMBS_UP,2022-04-10T14:08:18Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-16T07:20:13Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-16T09:31:13Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-16T09:38:37Z,jplatte,NA https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-17T01:05:46Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-17T10:47:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-10-19T17:40:40Z,hkratz,NA https://github.com/rust-lang/rust/pull/89933,MERGED,2021-10-16T02:48:03Z,2021-10-19T17:38:52Z,Adopt let_else across the compiler,est31,1af55d19c7a9189374d89472f97dc119659bb67e,54,Auto merge of #89933 - est31:let_else r=michaelwoerister Adopt let_else across the compiler This performs a substitution of code following the pattern: ``` let = if let = ... { identity } else { ... : ! }; ``` To simplify it to: ``` let = ... { identity } else { ... : ! }; ``` By adopting the `let_else` feature (cc #87335). The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet. Note: Generally I'm the person who *removes* usages of unstable features from the compiler not adds more usages of them but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.,HEART,2021-11-02T10:03:17Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/89942,MERGED,2021-10-16T08:02:35Z,2021-11-06T01:12:45Z,Reorder `widening_impl`s to make the doc clearer,JohnTitor,d6f12f76308c75d658df3fcc920a95c6ca87fb35,1,Rollup merge of #89942 - JohnTitor:reorder-widening_impl r=dtolnay Reorder `widening_impl`s to make the doc clearer Fixes #88736 This moves `{widening carrying}_mul`s to the bottom to place consts on the top.,HEART,2021-11-06T17:52:54Z,camelid,NA https://github.com/rust-lang/rust/pull/89946,MERGED,2021-10-16T09:31:14Z,2021-10-17T22:29:31Z,Fix an ICE with TAITs and Future,JohnTitor,0f1ba8d8c786f625934908d7681f9779e21668b5,3,Rollup merge of #89946 - JohnTitor:fix-89686 r=petrochenkov Fix an ICE with TAITs and Future Fixes #89686,HEART,2021-10-18T00:51:00Z,wxb1ank,NA https://github.com/rust-lang/rust/pull/89950,MERGED,2021-10-16T12:14:35Z,2021-10-18T09:52:14Z,bootstrap: tweak verbosity settings,infinity0,b902aa98e580c43ea5b2bb7b15d56ecc02c17856,3,Rollup merge of #89950 - infinity0:master r=Mark-Simulacrum bootstrap: tweak verbosity settings Currently the verbosity settings are: - 2: RUSTC-SHIM envvars get spammed on every invocation O(30) lines cargo is passed -v which outputs CLI invocations O(5) lines - 3: cargo is passed -vv which outputs build script output O(0-10) lines This commit changes it to: - 1: cargo is passed -v O(5) lines - 2: cargo is passed -vv O(10) lines - 3: RUSTC-SHIM envvars get spammed O(30) lines,THUMBS_UP,2021-10-18T08:50:12Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89956,MERGED,2021-10-16T20:08:52Z,2021-10-19T08:13:36Z,Suggest a case insensitive match name regardless of levenshtein distance,JohnTitor,8c8835d277e2b462ebf0584b4eb2db93369603a6,4,Rollup merge of #89956 - JohnTitor:suggest-case-insensitive-match-names r=estebank Suggest a case insensitive match name regardless of levenshtein distance Fixes #86170 Currently `find_best_match_for_name` only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like `Bar` -> `BAR`. That idea is from https://github.com/rust-lang/rust/pull/46347#discussion_r153701834 but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo. Skipped the `candidate != lookup` check because the current (i.e `levenshtein_match`) returns the exact same `Symbol` anyway but it doesn't seem to confuse anything on UI tests. r? ``@estebank``,HOORAY,2021-10-20T07:59:15Z,ben0x539,NA https://github.com/rust-lang/rust/pull/89970,MERGED,2021-10-17T00:05:53Z,2021-11-06T07:15:07Z,Implementation of GATs outlives lint,jackh726,9d39f6ab7dec5b8c6e8d9ce52a1f15b9e656c900,22,Auto merge of #89970 - jackh726:gats_diagnostics r=nikomatsakis Implementation of GATs outlives lint See #87479 for background. Closes #87479 The basic premise of this lint/error is to require the user to write where clauses on a GAT when those bounds can be implied or proven from any function on the trait returning that GAT. ## Intuitive Explanation (Attempt) ## Let's take this trait definition as an example: ```rust trait Iterable { type Item<'x>; fn iter<'a>(&'a self) -> Self::Item<'a>; } ``` Let's focus on the `iter` function. The first thing to realize is that we know that `Self: 'a` because of `&'a self`. If an impl wants `Self::Item` to contain any data with references then those references must be derived from `&'a self`. Thus they must live only as long as `'a`. Furthermore because of the `Self: 'a` implied bound they must live only as long as `Self`. Since it's `'a` is used in place of `'x` it is reasonable to assume that any value of `Self::Item<'x>` and thus `'x` will only be able to live as long as `Self`. Therefore we require this bound on `Item` in the trait. As another example: ```rust trait Deserializer { type Out<'x>; fn deserialize<'a>(&self input: &'a T) -> Self::Out<'a>; } ``` The intuition is similar here except rather than a `Self: 'a` implied bound we have a `T: 'a` implied bound. Thus the data on `Self::Out<'a>` is derived from `&'a T` and thus it is reasonable to expect that the lifetime `'x` will always be less than `T`. ## Implementation Algorithm ## * Given a GAT `>::G` declared as `trait T for A0 { type G; }` used in return type of one associated function `F` * Given env `E` (including implied bounds) for `F` * For each lifetime parameter `'a` in `P0...Pn`: * For each other type parameter `Pi != 'a` in `P0...Pn`: // FIXME: this include of lifetime parameters too * If `E => (P: 'a)`: * Require where clause `Ai: 'a` ## Follow-up questions ## * What should we do when we don't pass params exactly? For this example: ```rust trait Des { type Out<'x D>; fn des<'z T>(&self data: &'z Wrap) -> Self::Out<'z Wrap>; } ``` Should we be requiring a `D: 'x` clause? We pass `Wrap` as `D` and `'z` as `'x` and should be able to prove that `Wrap: 'z`. r? `@nikomatsakis`,THUMBS_UP,2021-11-11T12:28:50Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/89970,MERGED,2021-10-17T00:05:53Z,2021-11-06T07:15:07Z,Implementation of GATs outlives lint,jackh726,9d39f6ab7dec5b8c6e8d9ce52a1f15b9e656c900,22,Auto merge of #89970 - jackh726:gats_diagnostics r=nikomatsakis Implementation of GATs outlives lint See #87479 for background. Closes #87479 The basic premise of this lint/error is to require the user to write where clauses on a GAT when those bounds can be implied or proven from any function on the trait returning that GAT. ## Intuitive Explanation (Attempt) ## Let's take this trait definition as an example: ```rust trait Iterable { type Item<'x>; fn iter<'a>(&'a self) -> Self::Item<'a>; } ``` Let's focus on the `iter` function. The first thing to realize is that we know that `Self: 'a` because of `&'a self`. If an impl wants `Self::Item` to contain any data with references then those references must be derived from `&'a self`. Thus they must live only as long as `'a`. Furthermore because of the `Self: 'a` implied bound they must live only as long as `Self`. Since it's `'a` is used in place of `'x` it is reasonable to assume that any value of `Self::Item<'x>` and thus `'x` will only be able to live as long as `Self`. Therefore we require this bound on `Item` in the trait. As another example: ```rust trait Deserializer { type Out<'x>; fn deserialize<'a>(&self input: &'a T) -> Self::Out<'a>; } ``` The intuition is similar here except rather than a `Self: 'a` implied bound we have a `T: 'a` implied bound. Thus the data on `Self::Out<'a>` is derived from `&'a T` and thus it is reasonable to expect that the lifetime `'x` will always be less than `T`. ## Implementation Algorithm ## * Given a GAT `>::G` declared as `trait T for A0 { type G; }` used in return type of one associated function `F` * Given env `E` (including implied bounds) for `F` * For each lifetime parameter `'a` in `P0...Pn`: * For each other type parameter `Pi != 'a` in `P0...Pn`: // FIXME: this include of lifetime parameters too * If `E => (P: 'a)`: * Require where clause `Ai: 'a` ## Follow-up questions ## * What should we do when we don't pass params exactly? For this example: ```rust trait Des { type Out<'x D>; fn des<'z T>(&self data: &'z Wrap) -> Self::Out<'z Wrap>; } ``` Should we be requiring a `D: 'x` clause? We pass `Wrap` as `D` and `'z` as `'x` and should be able to prove that `Wrap: 'z`. r? `@nikomatsakis`,THUMBS_UP,2021-11-12T12:37:23Z,pYtoner,NA https://github.com/rust-lang/rust/pull/89974,MERGED,2021-10-17T05:06:46Z,2021-10-18T09:52:14Z,Nicer error message if the user attempts to do let...else if,est31,5898c5d88e7a7b7a28ab8fcca360c868b7f65d20,3,"Rollup merge of #89974 - est31:let_else_if_error r=nagisa Nicer error message if the user attempts to do let...else if Gives a nice ""conditional `else if` is not supported for `let...else`"" error when encountering a `let...else if` pattern as suggested in the [let...else tracking issue](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205).",HEART,2021-10-19T07:11:54Z,iago-lito,NA https://github.com/rust-lang/rust/pull/89990,MERGED,2021-10-17T21:02:09Z,2021-10-18T09:52:14Z,rustc_span: `Ident::invalid` -> `Ident::empty`,petrochenkov,2fd765c1d9f5dd7dd0592748cb98815910b9ed60,20,Rollup merge of #89990 - petrochenkov:idempty r=wesleywiser rustc_span: `Ident::invalid` -> `Ident::empty` The equivalent for `Symbol`s was renamed some time ago (`kw::Invalid` -> `kw::Empty`) and it makes sense to do the same thing for `Ident`s as well.,THUMBS_UP,2021-10-18T08:47:11Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/89999,MERGED,2021-10-18T05:44:26Z,2021-12-09T10:11:59Z,Update std::env::temp_dir to use GetTempPath2 on Windows when available.,talagrand,856eefece946994ea76030c756df5fdf669cac9e,3,Rollup merge of #89999 - talagrand:GetTempPath2 r=m-ou-se Update std::env::temp_dir to use GetTempPath2 on Windows when available. As a security measure Windows 11 introduces a new temporary directory API GetTempPath2. When the calling process is running as SYSTEM a separate temporary directory will be returned inaccessible to non-SYSTEM processes. For non-SYSTEM processes the behavior will be the same as before. This can help mitigate against attacks such as this one: https://medium.com/csis-techblog/cve-2020-1088-yet-another-arbitrary-delete-eop-a00b97d8c3e2 Compatibility risk: Software which relies on temporary files to communicate between SYSTEM and non-SYSTEM processes may be affected by this change. In many cases such patterns may be vulnerable to the very attacks the new API was introduced to harden against. I'm unclear on the Rust project's tolerance for such change-of-behavior in the standard library. If anything this PR is meant to raise awareness of the issue and hopefully start the conversation. How tested: Taking the example code from the documentation and running it through psexec (from SysInternals) on Win10 and Win11. On Win10: C:\test>psexec -s C:\test\main.exe <...> Temporary directory: C:\WINDOWS\TEMP\ On Win11: C:\test>psexec -s C:\test\main.exe <...> Temporary directory: C:\Windows\SystemTemp\,THUMBS_UP,2022-02-23T09:50:46Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/89999,MERGED,2021-10-18T05:44:26Z,2021-12-09T10:11:59Z,Update std::env::temp_dir to use GetTempPath2 on Windows when available.,talagrand,856eefece946994ea76030c756df5fdf669cac9e,3,Rollup merge of #89999 - talagrand:GetTempPath2 r=m-ou-se Update std::env::temp_dir to use GetTempPath2 on Windows when available. As a security measure Windows 11 introduces a new temporary directory API GetTempPath2. When the calling process is running as SYSTEM a separate temporary directory will be returned inaccessible to non-SYSTEM processes. For non-SYSTEM processes the behavior will be the same as before. This can help mitigate against attacks such as this one: https://medium.com/csis-techblog/cve-2020-1088-yet-another-arbitrary-delete-eop-a00b97d8c3e2 Compatibility risk: Software which relies on temporary files to communicate between SYSTEM and non-SYSTEM processes may be affected by this change. In many cases such patterns may be vulnerable to the very attacks the new API was introduced to harden against. I'm unclear on the Rust project's tolerance for such change-of-behavior in the standard library. If anything this PR is meant to raise awareness of the issue and hopefully start the conversation. How tested: Taking the example code from the documentation and running it through psexec (from SysInternals) on Win10 and Win11. On Win10: C:\test>psexec -s C:\test\main.exe <...> Temporary directory: C:\WINDOWS\TEMP\ On Win11: C:\test>psexec -s C:\test\main.exe <...> Temporary directory: C:\Windows\SystemTemp\,THUMBS_UP,2022-03-11T07:30:57Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90000,MERGED,2021-10-18T06:13:33Z,2021-10-18T09:52:14Z,Rollup of 8 pull requests,matthiaskrgr,5dab47dcd8267b8769421b46532414ec36d625e3,34,Auto merge of #90000 - matthiaskrgr:rollup-vj7wwur r=matthiaskrgr Rollup of 8 pull requests Successful merges: - #89950 (bootstrap: tweak verbosity settings) - #89965 (Fix ICE with `let...else` and `ref mut`) - #89974 (Nicer error message if the user attempts to do let...else if) - #89987 (Check implementing type for `#[doc(hidden)]`) - #89989 (rustdoc: Add static size assertion for `clean::Type`) - #89990 (rustc_span: `Ident::invalid` -> `Ident::empty`) - #89993 (Remove dead code from `compiletest::json`) - #89996 (Bump backtrace) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HOORAY,2021-10-18T07:35:31Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90000,MERGED,2021-10-18T06:13:33Z,2021-10-18T09:52:14Z,Rollup of 8 pull requests,matthiaskrgr,5dab47dcd8267b8769421b46532414ec36d625e3,34,Auto merge of #90000 - matthiaskrgr:rollup-vj7wwur r=matthiaskrgr Rollup of 8 pull requests Successful merges: - #89950 (bootstrap: tweak verbosity settings) - #89965 (Fix ICE with `let...else` and `ref mut`) - #89974 (Nicer error message if the user attempts to do let...else if) - #89987 (Check implementing type for `#[doc(hidden)]`) - #89989 (rustdoc: Add static size assertion for `clean::Type`) - #89990 (rustc_span: `Ident::invalid` -> `Ident::empty`) - #89993 (Remove dead code from `compiletest::json`) - #89996 (Bump backtrace) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HOORAY,2021-10-18T10:05:44Z,adamgemmell,NA https://github.com/rust-lang/rust/pull/90000,MERGED,2021-10-18T06:13:33Z,2021-10-18T09:52:14Z,Rollup of 8 pull requests,matthiaskrgr,5dab47dcd8267b8769421b46532414ec36d625e3,34,Auto merge of #90000 - matthiaskrgr:rollup-vj7wwur r=matthiaskrgr Rollup of 8 pull requests Successful merges: - #89950 (bootstrap: tweak verbosity settings) - #89965 (Fix ICE with `let...else` and `ref mut`) - #89974 (Nicer error message if the user attempts to do let...else if) - #89987 (Check implementing type for `#[doc(hidden)]`) - #89989 (rustdoc: Add static size assertion for `clean::Type`) - #89990 (rustc_span: `Ident::invalid` -> `Ident::empty`) - #89993 (Remove dead code from `compiletest::json`) - #89996 (Bump backtrace) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HOORAY,2021-10-18T11:27:06Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90000,MERGED,2021-10-18T06:13:33Z,2021-10-18T09:52:14Z,Rollup of 8 pull requests,matthiaskrgr,5dab47dcd8267b8769421b46532414ec36d625e3,34,Auto merge of #90000 - matthiaskrgr:rollup-vj7wwur r=matthiaskrgr Rollup of 8 pull requests Successful merges: - #89950 (bootstrap: tweak verbosity settings) - #89965 (Fix ICE with `let...else` and `ref mut`) - #89974 (Nicer error message if the user attempts to do let...else if) - #89987 (Check implementing type for `#[doc(hidden)]`) - #89989 (rustdoc: Add static size assertion for `clean::Type`) - #89990 (rustc_span: `Ident::invalid` -> `Ident::empty`) - #89993 (Remove dead code from `compiletest::json`) - #89996 (Bump backtrace) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HOORAY,2021-10-18T17:26:01Z,camelid,NA https://github.com/rust-lang/rust/pull/90000,MERGED,2021-10-18T06:13:33Z,2021-10-18T09:52:14Z,Rollup of 8 pull requests,matthiaskrgr,5dab47dcd8267b8769421b46532414ec36d625e3,34,Auto merge of #90000 - matthiaskrgr:rollup-vj7wwur r=matthiaskrgr Rollup of 8 pull requests Successful merges: - #89950 (bootstrap: tweak verbosity settings) - #89965 (Fix ICE with `let...else` and `ref mut`) - #89974 (Nicer error message if the user attempts to do let...else if) - #89987 (Check implementing type for `#[doc(hidden)]`) - #89989 (rustdoc: Add static size assertion for `clean::Type`) - #89990 (rustc_span: `Ident::invalid` -> `Ident::empty`) - #89993 (Remove dead code from `compiletest::json`) - #89996 (Bump backtrace) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HOORAY,2021-10-22T05:19:12Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/90004,MERGED,2021-10-18T07:51:41Z,2021-10-18T12:47:21Z,Rust 1.56.0 stable release,pietroalbini,09c42c45858d5f3aedfa670698275303a3d19afa,5,Auto merge of #90004 - pietroalbini:stable-next r=pietroalbini Rust 1.56.0 stable release This PR bumps 1.56.0 to the stable channel. This also includes a backport for: * Latest changes to the release notes * #89867 r? `@ghost` cc `@rust-lang/release`,HOORAY,2021-10-18T08:07:17Z,a1phyr,NA https://github.com/rust-lang/rust/pull/90004,MERGED,2021-10-18T07:51:41Z,2021-10-18T12:47:21Z,Rust 1.56.0 stable release,pietroalbini,09c42c45858d5f3aedfa670698275303a3d19afa,5,Auto merge of #90004 - pietroalbini:stable-next r=pietroalbini Rust 1.56.0 stable release This PR bumps 1.56.0 to the stable channel. This also includes a backport for: * Latest changes to the release notes * #89867 r? `@ghost` cc `@rust-lang/release`,HOORAY,2021-10-18T08:54:42Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/90004,MERGED,2021-10-18T07:51:41Z,2021-10-18T12:47:21Z,Rust 1.56.0 stable release,pietroalbini,09c42c45858d5f3aedfa670698275303a3d19afa,5,Auto merge of #90004 - pietroalbini:stable-next r=pietroalbini Rust 1.56.0 stable release This PR bumps 1.56.0 to the stable channel. This also includes a backport for: * Latest changes to the release notes * #89867 r? `@ghost` cc `@rust-lang/release`,HOORAY,2021-10-18T09:09:21Z,hkratz,NA https://github.com/rust-lang/rust/pull/90004,MERGED,2021-10-18T07:51:41Z,2021-10-18T12:47:21Z,Rust 1.56.0 stable release,pietroalbini,09c42c45858d5f3aedfa670698275303a3d19afa,5,Auto merge of #90004 - pietroalbini:stable-next r=pietroalbini Rust 1.56.0 stable release This PR bumps 1.56.0 to the stable channel. This also includes a backport for: * Latest changes to the release notes * #89867 r? `@ghost` cc `@rust-lang/release`,HOORAY,2021-10-18T09:29:32Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/90004,MERGED,2021-10-18T07:51:41Z,2021-10-18T12:47:21Z,Rust 1.56.0 stable release,pietroalbini,09c42c45858d5f3aedfa670698275303a3d19afa,5,Auto merge of #90004 - pietroalbini:stable-next r=pietroalbini Rust 1.56.0 stable release This PR bumps 1.56.0 to the stable channel. This also includes a backport for: * Latest changes to the release notes * #89867 r? `@ghost` cc `@rust-lang/release`,HOORAY,2021-10-18T17:27:56Z,camelid,NA https://github.com/rust-lang/rust/pull/90006,OPEN,2021-10-18T09:29:55Z,NA,More accurate error for binop errors after identifying RHS type,estebank,NA,NA,NA,HOORAY,2021-10-18T11:43:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90006,OPEN,2021-10-18T09:29:55Z,NA,More accurate error for binop errors after identifying RHS type,estebank,NA,NA,NA,HOORAY,2021-10-18T18:47:13Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90016,CLOSED,2021-10-18T13:48:21Z,2022-01-30T04:39:36Z,refinement typing go brrrrrr,BoxyUwU,NA,NA,NA,ROCKET,2021-10-18T21:08:08Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/90016,CLOSED,2021-10-18T13:48:21Z,2022-01-30T04:39:36Z,refinement typing go brrrrrr,BoxyUwU,NA,NA,NA,LAUGH,2021-10-20T02:09:25Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/90016,CLOSED,2021-10-18T13:48:21Z,2022-01-30T04:39:36Z,refinement typing go brrrrrr,BoxyUwU,NA,NA,NA,ROCKET,2021-10-25T12:50:10Z,TaitoMagatsu91,NA https://github.com/rust-lang/rust/pull/90016,CLOSED,2021-10-18T13:48:21Z,2022-01-30T04:39:36Z,refinement typing go brrrrrr,BoxyUwU,NA,NA,NA,HEART,2021-10-25T12:50:13Z,TaitoMagatsu91,NA https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-10-18T17:39:42Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-10-19T10:05:24Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-11-08T13:52:24Z,overdrivenpotato,NA https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-12-06T11:48:46Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-12-09T09:29:59Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/90023,MERGED,2021-10-18T16:40:04Z,2021-12-05T03:41:27Z,Postpone the evaluation of constant expressions that depend on inference variables,b-naber,1f2a26e999a4c8e3a053e95f62b1ee403b15faed,11,Rollup merge of #90023 - b-naber:postpone_const_eval_infer_vars r=nikomatsakis Postpone the evaluation of constant expressions that depend on inference variables Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected hence no real error was ever encountered but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring. We now postpone the evaluation of these constants so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present. Fixes https://github.com/rust-lang/rust/issues/89320 Fixes https://github.com/rust-lang/rust/issues/89146 Fixes https://github.com/rust-lang/rust/issues/87964 Fixes https://github.com/rust-lang/rust/issues/87470 Fixes https://github.com/rust-lang/rust/issues/83288 Fixes https://github.com/rust-lang/rust/issues/83249 Fixes https://github.com/rust-lang/rust/issues/90654 I want to thank `@BoxyUwU` for cooperating on this and for providing some help. r? `@lcnr` maybe?,HOORAY,2021-12-11T17:44:36Z,barrowsys,NA https://github.com/rust-lang/rust/pull/90035,MERGED,2021-10-19T03:12:46Z,2021-11-09T23:16:05Z,implement rfc-2528 type_changing-struct-update,SparrowLii,610b4e503ccc5cb6d4ef98bb5016ba42eaf94522,11,Rollup merge of #90035 - SparrowLii:rfc2528 r=jackh726 implement rfc-2528 type_changing-struct-update This PR implement rfc2528-type_changing-struct-update. The main change process is as follows: 1. Move the processing part of `base_expr` into `check_expr_struct_fields` to avoid returning `remaining_fields` (a relatively complex hash table) 2. Before performing the type consistency check(`check_expr_has_type_or_error`) if the `type_changing_struct_update` feature is set enter a different processing flow otherwise keep the original flow 3. In the case of the same structure definition check each field in `remaining_fields`. If the field in `base_expr` is not the suptype of the field in `adt_ty` an error(`FeildMisMatch`) will be reported. The MIR part does not need to be changed because only the items contained in `remaining_fields` will be extracted from `base_expr` when MIR is generated. This means that fields with different types in `base_expr` will not be used Updates #86618 cc `@nikomatsakis`,THUMBS_UP,2021-10-31T03:43:04Z,crlf0710,NA https://github.com/rust-lang/rust/pull/90035,MERGED,2021-10-19T03:12:46Z,2021-11-09T23:16:05Z,implement rfc-2528 type_changing-struct-update,SparrowLii,610b4e503ccc5cb6d4ef98bb5016ba42eaf94522,11,Rollup merge of #90035 - SparrowLii:rfc2528 r=jackh726 implement rfc-2528 type_changing-struct-update This PR implement rfc2528-type_changing-struct-update. The main change process is as follows: 1. Move the processing part of `base_expr` into `check_expr_struct_fields` to avoid returning `remaining_fields` (a relatively complex hash table) 2. Before performing the type consistency check(`check_expr_has_type_or_error`) if the `type_changing_struct_update` feature is set enter a different processing flow otherwise keep the original flow 3. In the case of the same structure definition check each field in `remaining_fields`. If the field in `base_expr` is not the suptype of the field in `adt_ty` an error(`FeildMisMatch`) will be reported. The MIR part does not need to be changed because only the items contained in `remaining_fields` will be extracted from `base_expr` when MIR is generated. This means that fields with different types in `base_expr` will not be used Updates #86618 cc `@nikomatsakis`,THUMBS_UP,2022-02-21T10:05:04Z,Folyd,NA https://github.com/rust-lang/rust/pull/90035,MERGED,2021-10-19T03:12:46Z,2021-11-09T23:16:05Z,implement rfc-2528 type_changing-struct-update,SparrowLii,610b4e503ccc5cb6d4ef98bb5016ba42eaf94522,11,Rollup merge of #90035 - SparrowLii:rfc2528 r=jackh726 implement rfc-2528 type_changing-struct-update This PR implement rfc2528-type_changing-struct-update. The main change process is as follows: 1. Move the processing part of `base_expr` into `check_expr_struct_fields` to avoid returning `remaining_fields` (a relatively complex hash table) 2. Before performing the type consistency check(`check_expr_has_type_or_error`) if the `type_changing_struct_update` feature is set enter a different processing flow otherwise keep the original flow 3. In the case of the same structure definition check each field in `remaining_fields`. If the field in `base_expr` is not the suptype of the field in `adt_ty` an error(`FeildMisMatch`) will be reported. The MIR part does not need to be changed because only the items contained in `remaining_fields` will be extracted from `base_expr` when MIR is generated. This means that fields with different types in `base_expr` will not be used Updates #86618 cc `@nikomatsakis`,THUMBS_UP,2022-02-28T23:47:20Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/90041,MERGED,2021-10-19T06:00:43Z,2021-11-13T08:22:53Z,Re-enable `copy[_nonoverlapping]()` debug-checks,jfrimmel,7594067b69eac2395f7b3b42d519a559dae2d9d9,2,Auto merge of #90041 - jfrimmel:rt_copy_checks r=Mark-Simulacrum Re-enable `copy[_nonoverlapping]()` debug-checks This commit re-enables the debug checks for valid usages of the two functions `copy()` and `copy_nonoverlapping()`. Those checks were commented out in #79684 in order to make the functions const. All that's been left was a FIXME that could not be resolved until there is was way to only do the checks at runtime. Since #89247 there is such a way: `const_eval_select()`. This commit uses that new intrinsic in order to either do nothing (at compile time) or to do the old checks (at runtime). The change itself is rather small: in order to make the checks usable with `const_eval_select` they are moved into a local function (one for `copy` and one for `copy_nonoverlapping` to keep symmetry). The change does not break referential transparency as there is nothing you can do at compile time which you cannot do on runtime without getting undefined behavior. The CTFE-engine won't allow missuses. The other way round is also fine. I've refactored the code to use `#[cfg(debug_assertions)]` on the new items. If that is not desired the second commit can be dropped. I haven't added any checks as I currently don't know how to test this properly. Closes #90012. cc `@rust-lang/lang ` `@rust-lang/libs` and `@rust-lang/wg-const-eval` (as those teams are linked in the issue above).,THUMBS_UP,2021-12-13T19:05:18Z,usbalbin,NA https://github.com/rust-lang/rust/pull/90041,MERGED,2021-10-19T06:00:43Z,2021-11-13T08:22:53Z,Re-enable `copy[_nonoverlapping]()` debug-checks,jfrimmel,7594067b69eac2395f7b3b42d519a559dae2d9d9,2,Auto merge of #90041 - jfrimmel:rt_copy_checks r=Mark-Simulacrum Re-enable `copy[_nonoverlapping]()` debug-checks This commit re-enables the debug checks for valid usages of the two functions `copy()` and `copy_nonoverlapping()`. Those checks were commented out in #79684 in order to make the functions const. All that's been left was a FIXME that could not be resolved until there is was way to only do the checks at runtime. Since #89247 there is such a way: `const_eval_select()`. This commit uses that new intrinsic in order to either do nothing (at compile time) or to do the old checks (at runtime). The change itself is rather small: in order to make the checks usable with `const_eval_select` they are moved into a local function (one for `copy` and one for `copy_nonoverlapping` to keep symmetry). The change does not break referential transparency as there is nothing you can do at compile time which you cannot do on runtime without getting undefined behavior. The CTFE-engine won't allow missuses. The other way round is also fine. I've refactored the code to use `#[cfg(debug_assertions)]` on the new items. If that is not desired the second commit can be dropped. I haven't added any checks as I currently don't know how to test this properly. Closes #90012. cc `@rust-lang/lang ` `@rust-lang/libs` and `@rust-lang/wg-const-eval` (as those teams are linked in the issue above).,THUMBS_UP,2022-01-31T16:01:43Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/90057,CLOSED,2021-10-19T13:45:38Z,2022-01-20T09:00:40Z,[BENCH] prepare mono item collection for polymorphization,lcnr,NA,NA,NA,THUMBS_UP,2021-10-22T15:09:52Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:02:41Z,edmorley,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:03:20Z,eggyal,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:04:00Z,vilgotf,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:04:52Z,AliciaBytes,alicia@aliciabytes.dev https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:09:27Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:10:52Z,Fogapod,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:11:31Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:31:37Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:52:22Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T14:59:40Z,numToStr,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T17:51:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T19:02:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T20:12:32Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-19T23:16:28Z,inflation,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-20T07:51:16Z,hkratz,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-22T03:21:47Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-23T16:55:38Z,remissio,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-10-27T12:31:23Z,ihciah,ihciah@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-01T19:35:31Z,Purpzie,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-04T05:30:51Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-04T06:17:04Z,konstin,konstin@mailbox.org https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-04T08:25:27Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-04T08:34:15Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-04T12:55:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-05T01:40:43Z,tux3,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-05T19:46:36Z,a1phyr,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-11T11:09:36Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-11T12:31:27Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-12T13:25:27Z,rodrigorc,rodrigorivascosta@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-14T15:28:51Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-14T23:07:12Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-15T03:12:00Z,NegaNote,neganote https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-17T03:49:58Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-27T01:38:09Z,lopopolo,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-11-27T09:42:18Z,elichai,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-12-05T16:23:25Z,aml360,aml360esp@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-12-19T00:22:04Z,johnthagen,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2021-12-25T16:58:46Z,ErichDonGubler,erichdongubler@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-04T20:12:48Z,Cpapa97,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-05T14:34:57Z,austinabell,austinabell8+gh@gmail.com https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-13T19:40:48Z,nmoutschen,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-15T08:55:40Z,whalehub,admin@datahoarder.dev https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-15T16:29:39Z,zohnannor,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-01-22T09:15:51Z,zonyitoo,NA https://github.com/rust-lang/rust/pull/90058,MERGED,2021-10-19T13:54:53Z,2021-11-16T05:19:06Z,Stabilize -Z strip as -C strip,joshtriplett,a0dc4abe987edc3ef52b0dc89c50e5e13b3cdbe3,6,Rollup merge of #90058 - joshtriplett:stabilize-strip r=wesleywiser Stabilize -Z strip as -C strip Leave -Z strip available temporarily as an alias to avoid breaking cargo until cargo transitions to using -C strip.,HOORAY,2022-02-04T17:07:24Z,Oliboy50,NA https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-01-11T23:02:38Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-01-12T10:09:55Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-01-13T20:23:32Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-01-13T22:40:38Z,a1phyr,NA https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-01-30T21:16:14Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-04-14T08:20:12Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/90066,MERGED,2021-10-19T18:55:45Z,2022-04-09T07:10:40Z,Add new ThinBox type for 1 stack pointer wide heap allocated trait objects,yaahc,ee8cea8ac48df14c9089720823910a5a8fddbb2c,12,Rollup merge of #90066 - yaahc:thinbox r=joshtriplett Add new ThinBox type for 1 stack pointer wide heap allocated trait objects **Zulip Thread**: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/ThinBox Based on https://github.com/matthieu-m/rfc2580/blob/b58d1d3cba0d4b5e859d3617ea2d0943aaa31329/examples/thin.rs Tracking Issue: https://github.com/rust-lang/rust/issues/92791 Usage Trial: https://github.com/yaahc/pgx/pull/1/files ## TODO - [x] make sure to test with #[repr(align(1024))] structs etc,HOORAY,2022-04-15T08:48:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90070,MERGED,2021-10-19T21:08:38Z,2021-10-23T09:21:43Z,Add edition configuration to compiletest,llogiq,1782d1333cbe35aba7b4326534e8263041b7dac1,3,Rollup merge of #90070 - llogiq:compiletest-config-edition r=Mark-Simulacrum Add edition configuration to compiletest This allows the compiletest configuration to set a default edition that can still be overridden with header annotations. Doing this will make it far easier for clippy to get our tests to the newest edition. r? ```@Manishearth```,THUMBS_UP,2021-10-20T09:51:01Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/90072,MERGED,2021-10-20T00:01:59Z,2021-10-21T08:04:23Z,Don't emit a warning for empty rmeta files.,ehuss,40ebd073829959d47b977c168096968a6ed753f9,1,Auto merge of #90072 - ehuss:empty-rmeta-no-warn r=Mark-Simulacrum Don't emit a warning for empty rmeta files. This avoids displaying a warning when attempting to load an empty rmeta file. Warnings were enabled via #89634 which can cause a lot of noise (for example running `./x.py check`). rustc generates empty rmeta files for things like binaries which can happen when checking libraries as unittests. Closes #89795,ROCKET,2021-10-20T08:33:10Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/90075,MERGED,2021-10-20T00:42:40Z,2021-10-26T11:02:07Z,Edit error messages for `rustc_resolve::AmbiguityKind` variants,pierwill,c7a30c8b6860d1f3459086f7a91074db1b54bc37,38,Auto merge of #90075 - pierwill:fix-79717 r=petrochenkov Edit error messages for `rustc_resolve::AmbiguityKind` variants Edit the language of the ambiguity descriptions for E0659. These strings now appear as notes. Closes #79717.,THUMBS_UP,2021-10-24T21:18:25Z,estebank,NA https://github.com/rust-lang/rust/pull/90075,MERGED,2021-10-20T00:42:40Z,2021-10-26T11:02:07Z,Edit error messages for `rustc_resolve::AmbiguityKind` variants,pierwill,c7a30c8b6860d1f3459086f7a91074db1b54bc37,38,Auto merge of #90075 - pierwill:fix-79717 r=petrochenkov Edit error messages for `rustc_resolve::AmbiguityKind` variants Edit the language of the ambiguity descriptions for E0659. These strings now appear as notes. Closes #79717.,THUMBS_UP,2021-10-24T22:44:18Z,camelid,NA https://github.com/rust-lang/rust/pull/90076,MERGED,2021-10-20T01:43:58Z,2022-03-06T09:30:56Z,Change location of where clause on GATs,jackh726,ad0d1d71d3bc6f85f53d8ab2bf47daa7c8bc2c51,52,Auto merge of #90076 - jackh726:wherethewhere r=nikomatsakis Change location of where clause on GATs Closes #89122 ~Blocked on lang FCP~ r? `@nikomatsakis`,ROCKET,2022-02-15T17:27:11Z,eopb,NA https://github.com/rust-lang/rust/pull/90077,MERGED,2021-10-20T01:50:20Z,2021-10-21T10:59:25Z,Make `From` impls of NonZero integer const.,woppopo,e4cfaa1a7ed336311e281ff188e704d7ef60b1bf,5,Rollup merge of #90077 - woppopo:const_nonzero_from r=oli-obk Make `From` impls of NonZero integer const. I also changed the feature gate added to `From` impls of Atomic integer to `const_num_from_num` from `const_convert`. Tracking issue: #87852,THUMBS_UP,2021-10-21T19:51:12Z,usbalbin,NA https://github.com/rust-lang/rust/pull/90087,MERGED,2021-10-20T05:15:44Z,2021-10-23T09:21:43Z,Sync rustfmt subtree,calebcartwright,c400feeb84f6164edd2d78607218ac8a58754cc3,144,Rollup merge of #90087 - calebcartwright:rustfmt-subtree r=calebcartwright Sync rustfmt subtree There's a large number of small fixes and new features but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20,HOORAY,2021-10-20T11:56:15Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/90099,MERGED,2021-10-20T13:59:58Z,2021-10-21T10:59:25Z,Fix MIRI UB in `Vec::swap_remove`,SkiFire13,3680ecd8a6e8dcac98833bc8bbc349277f780419,1,Rollup merge of #90099 - SkiFire13:fix-vec-swap-remove r=dtolnay Fix MIRI UB in `Vec::swap_remove` Fixes #90055 I find it weird that `Vec::swap_remove` read the last element to the stack just to immediately put it back in the `Vec` in place of the one at index `index`. It seems much more natural to me to just read the element at position `index` and then move the last element in its place. I guess this might also slightly improve codegen.,HEART,2021-10-28T14:22:07Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-20T17:20:00Z,lqd,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-20T17:35:22Z,Urgau,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-20T17:58:51Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-20T20:56:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-22T18:05:16Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-23T22:22:04Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-24T13:18:50Z,PotHix,pothix@pothix.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-25T09:54:48Z,therealprof,daniel.egger@axiros.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-25T15:57:10Z,YohDeadfall,yoh.deadfall@hotmail.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-25T19:14:54Z,yerke,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,ROCKET,2021-10-25T19:14:57Z,yerke,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HOORAY,2021-10-25T19:15:00Z,yerke,NA https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-28T09:46:35Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2021-10-30T09:47:46Z,JDuchniewicz,j.duchniewicz@gmail.com https://github.com/rust-lang/rust/pull/90104,MERGED,2021-10-20T17:18:19Z,2021-10-23T15:53:50Z,Implement coherence checks for negative trait impls,spastorino,aa5740c715001f981515ed46faaddebf67cb9539,38,Auto merge of #90104 - spastorino:coherence-for-negative-trait r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](https://github.com/rust-lang/project-error-handling/issues/3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future and thus prevents the `From` impl in `alloc` that would cause overlap with `From for Box`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error` making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box {} // A impl From for Box where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR #85764. Language team proposal: to https://github.com/rust-lang/lang-team/issues/96,HEART,2022-01-13T02:24:32Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/90127,MERGED,2021-10-21T11:26:39Z,2021-10-25T11:31:51Z,Do not mention a reexported item if it's private,JohnTitor,c734a9e0769de0843b16591a5b3fb9b56ec4417c,3,Rollup merge of #90127 - JohnTitor:fix-90113 r=estebank Do not mention a reexported item if it's private Fixes #90113 The _actual_ regression was introduced in #73652 then #88838 made it worse. This fixes the issue by not counting such an import as a candidate.,HEART,2021-10-21T18:04:07Z,camelid,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2021-10-21T15:17:07Z,marmeladema,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2021-10-21T22:06:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2021-10-25T14:55:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2021-11-05T01:38:26Z,tux3,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2021-11-11T03:54:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2022-01-02T00:39:43Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2022-01-02T19:18:41Z,mati865,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2022-02-21T00:50:11Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2022-02-23T07:42:37Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/90128,MERGED,2021-10-21T12:10:18Z,2022-01-02T18:47:24Z,Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0,joshtriplett,8f3238f898163f09726c3d2b2cc9bafb09da26f3,28,Auto merge of #90128 - joshtriplett:stabilize-symbol-mangling-version r=wesleywiser Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. This does not change the default symbol-mangling-version. See https://github.com/rust-lang/rust/pull/89917 for a pull request changing the default. Rationale from #89917: Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z a-z 0-9 and _. Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers). This pull request allows enabling the new v0 symbol-mangling-version. See #89917 for references to the implementation of v0 and for references to the tool changes to decode Rust symbols.,HEART,2022-03-03T19:01:28Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-21T14:58:20Z,richkadel,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-21T15:22:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-21T20:07:26Z,funbringer,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-21T22:09:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-22T00:16:21Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-22T00:17:02Z,nayato,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-22T00:46:23Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-22T16:25:29Z,tmandry,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-23T11:08:41Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-10-24T03:03:11Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-05T14:49:28Z,arlosi,arsiem@microsoft.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-11T02:24:41Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-13T08:28:50Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-17T13:58:11Z,WCarrollSTO,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-18T03:39:21Z,aznhe21,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-24T01:03:48Z,bcully,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-11-27T01:56:33Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-12-05T03:08:29Z,svenstaro,svenstaro@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2021-12-10T03:16:13Z,cooperwalbrun,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-02T00:41:05Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-18T20:42:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-19T18:47:36Z,SyntaxRules,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-27T14:47:09Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-28T06:01:55Z,evanrichter,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-01-28T22:57:17Z,mati865,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-02-05T11:30:20Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-02-18T12:45:34Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-04-06T21:12:55Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/90132,MERGED,2021-10-21T14:22:41Z,2022-02-05T04:32:46Z,Stabilize `-Z instrument-coverage` as `-C instrument-coverage`,joshtriplett,2fe9a32ed209b93ddd08cab174dfffefc1409a9c,26,Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now but show a deprecation warning for it.) Many many people have tested this support and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized will the compiler flag be updated to -C instrument-coverage? (If so the -Z variant could also be supported for some time to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4) which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage and using an older version of LLVM. Given that LLVM 13 has now been released requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11 nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage` but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.,HEART,2022-05-06T20:10:18Z,matthargett,plaztiksyke@gmail.com https://github.com/rust-lang/rust/pull/90174,CLOSED,2021-10-22T17:27:46Z,2022-01-14T18:26:16Z,Add error::Report type ,seanchen1991,NA,NA,NA,THUMBS_UP,2021-10-22T18:25:04Z,Urgau,NA https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2021-10-23T11:37:50Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2021-10-23T16:57:59Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2021-10-23T16:58:13Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2021-10-23T20:25:54Z,mati865,NA https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2021-10-25T06:11:24Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/90175,MERGED,2021-10-22T17:52:00Z,2021-10-24T00:09:24Z,Update the minimum external LLVM to 12,cuviper,45591408b18e7f93fcf8c09210c9a5a102d84b37,64,Auto merge of #90175 - cuviper:min-llvm-12 r=nagisa Update the minimum external LLVM to 12 With this change we'll have stable support for LLVM 12 and 13. For reference the previous increase to LLVM 10 was #83387 and this replaces the pending increase to LLVM 11 in #90062. r? `@nagisa` `@nikic`,HOORAY,2022-01-13T12:52:22Z,realvikas,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-24T01:22:28Z,estebank,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T00:11:05Z,belkadan,jrose@belkadan.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T00:11:30Z,mkeeter,matt.j.keeter@gmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T00:28:53Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T02:30:03Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T06:52:14Z,Kiiyya,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T07:03:22Z,ravicious,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T10:32:45Z,wbrickner,wgbrickner@gmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T12:08:58Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T13:00:27Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-10-27T16:17:03Z,aslynatilla,antonio.natilla30@gmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-02T23:03:41Z,camelid,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-04T21:49:48Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-06T14:19:02Z,lkbhargav,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-11T07:35:42Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-11T09:36:35Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-11T12:58:55Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-11T21:20:53Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/90179,MERGED,2021-10-22T21:13:02Z,2021-11-04T03:48:47Z,Add beginner friendly lifetime elision hint to E0623,Nilstrieb,e60e19bc6553ba02b8677ab7e397af738c076c8e,11,Auto merge of #90179 - Nilstrieb:lifetime-elision-mismatch-hint r=estebank Add beginner friendly lifetime elision hint to E0623 Address #90170 Suggest adding a new lifetime parameter when two elided lifetimes should match up but don't. Example: ``` error[E0623]: lifetime mismatch --> $DIR/issue-90170-elision-mismatch.rs:2:35 | LL | fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { | --------- --------- these two types are declared with different lifetimes... LL | core::mem::swap(&mut slice_a &mut slice_b); | ^^^^^^^^^^^^ ...but data from `slice_b` flows into `slice_a` here | = note: each elided lifetime in input position becomes a distinct lifetime help: explicitly declare a lifetime and assign it to both | LL | fn foo<'a>(slice_a: &'a mut [u8] slice_b: &'a mut [u8]) { | ++++ ++ ++ ``` for ```rust fn foo(slice_a: &mut [u8] slice_b: &mut [u8]) { core::mem::swap(&mut slice_a &mut slice_b); } ```,HEART,2021-11-13T08:45:51Z,robinmoussu,NA https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2021-10-29T00:41:31Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-10T16:35:06Z,smackysnacks,NA https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-11T17:54:07Z,Jules-Bertholet,NA https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-12T06:42:12Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-13T02:17:21Z,maciej-irl,hi@maciej.ie https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-13T20:57:55Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/90183,MERGED,2021-10-22T22:34:45Z,2021-10-30T22:39:24Z,Show all Deref implementations recursively,GuillaumeGomez,73494404e962f4d61e65e5e204432de5a5128101,9,Rollup merge of #90183 - GuillaumeGomez:recurse-deref r=jyn514 Show all Deref implementations recursively Fixes #87783. This is a re-implementation of #80653 so taking the original PR comment: This changes `rustdoc` to recursively follow `Deref` targets so that methods from all levels are added to the rendered output. This implementation displays the methods from all levels in the expanded state with separate sections for each level. ![image](https://user-images.githubusercontent.com/279572/103482863-46723b00-4ddb-11eb-972b-c463351a425c.png) cc `@camelid` r? `@jyn514`,HEART,2022-01-15T07:10:18Z,ibENPC,NA https://github.com/rust-lang/rust/pull/90204,MERGED,2021-10-23T14:00:37Z,2022-03-31T17:45:37Z,Make lowering pull-based,cjgillot,bd1a8692f6260fd59dba1e0fa187092a1c354b2e,5,Auto merge of #90204 - cjgillot:owner-pull r=michaelwoerister Make lowering pull-based ~Based on https://github.com/rust-lang/rust/pull/90451~ Part of https://github.com/rust-lang/rust/pull/88186 The current lowering code visits all the item-likes in the AST in order and lowers them one by one. This PR changes it to index the AST and then proceed to lowering on-demand. This is closer to the logic of query-based lowering.,HOORAY,2022-04-07T14:55:40Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-10-23T22:30:25Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-10-24T09:10:16Z,voidc,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-10-24T21:36:54Z,vicky5124,vickyf5124@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-10-25T05:00:52Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-10-25T10:14:28Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-11-26T16:23:34Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-11T15:22:52Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-11T17:37:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-11T19:38:22Z,eopb,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-12T11:27:20Z,mbrobbel,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-12T18:12:14Z,burrbull,zgarbul.andrey@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-16T02:32:23Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-16T18:01:20Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-18T22:05:20Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2021-12-21T14:50:14Z,mn-dex,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-04T17:22:37Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-20T15:12:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-23T06:10:45Z,orzogc,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-23T07:33:29Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-23T11:15:54Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-02-23T16:13:26Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90207,MERGED,2021-10-23T16:09:23Z,2021-12-12T17:28:52Z,Stabilise `feature(const_generics_defaults)`,BoxyUwU,753e569c9c2a4e3ef394ef7abd0802bf57f66bce,94,Auto merge of #90207 - BoxyUwU:stabilise_cg_defaults r=lcnr Stabilise `feature(const_generics_defaults)` `feature(const_generics_defaults)` is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation. needs stabilisation report and maybe an RFC :sweat_smile: r? `@lcnr` cc `@rust-lang/project-const-generics`,THUMBS_UP,2022-03-11T07:25:03Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90208,MERGED,2021-10-23T16:13:33Z,2021-10-24T09:38:26Z,Specialize HashStable for [u8] slices,Mark-Simulacrum,bdcb52851231dc14bc6a7915dc62528cae7b8137,1,Auto merge of #90208 - Mark-Simulacrum:hash-bytes-fast r=oli-obk Specialize HashStable for [u8] slices Particularly for ctfe-stress-4 the hashing of byte slices as part of the MIR Allocation is quite hot. Previously we were falling back on byte-by-byte copying of the slice into the SipHash buffer (64 bytes long) before hashing a 64 byte chunk and then doing that again and again; now we use the dedicated byte-slice write.,THUMBS_UP,2021-10-24T09:39:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90208,MERGED,2021-10-23T16:13:33Z,2021-10-24T09:38:26Z,Specialize HashStable for [u8] slices,Mark-Simulacrum,bdcb52851231dc14bc6a7915dc62528cae7b8137,1,Auto merge of #90208 - Mark-Simulacrum:hash-bytes-fast r=oli-obk Specialize HashStable for [u8] slices Particularly for ctfe-stress-4 the hashing of byte slices as part of the MIR Allocation is quite hot. Previously we were falling back on byte-by-byte copying of the slice into the SipHash buffer (64 bytes long) before hashing a 64 byte chunk and then doing that again and again; now we use the dedicated byte-slice write.,THUMBS_UP,2021-10-28T15:00:55Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/90214,MERGED,2021-10-23T20:06:57Z,2021-10-29T12:21:11Z,Consider indirect mutation during const qualification dataflow,tmiasko,37f70a0e1e04086aee7ae57fbefd6d4071953506,5,Auto merge of #90214 - tmiasko:indirect-mutation-qualif r=ecstatic-morse oli-obk Consider indirect mutation during const qualification dataflow Previously a local would be qualified if either one of two separate data flow computations indicated so. First determined if a local could contain the qualif but ignored any forms of indirect mutation. Second determined if a local could be mutably borrowed (and so indirectly mutated) but which in turn ignored the qualif. The end result was incorrect because the effect of indirect mutation was effectivelly ignored in the all but the final stage of computation. In the new implementation the indirect mutation is directly incorporated into the qualif data flow. The local variable becomes immediately qualified once it is mutably borrowed and borrowed place type can contain the qualif. In general we will now reject additional programs program that were prevously unintentionally accepted. There are also some cases which are now accepted but were previously rejected because previous implementation didn't consider whether borrowed place could have the qualif under the consideration. Fixes #90124. r? `@ecstatic-morse`,HEART,2021-10-25T05:56:38Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/90216,CLOSED,2021-10-23T21:19:45Z,2021-10-24T19:38:14Z,Make `thiscall` error if unsupported,ChrisDenton,NA,NA,NA,HEART,2021-10-24T01:40:57Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/90218,MERGED,2021-10-23T22:28:23Z,2021-10-28T19:00:36Z,Fixes incorrect handling of ADT's drop requirements,JakobDegen,85c0558d032e204f4f4ed6137f3119cb92dbc684,2,Auto merge of #90218 - JakobDegen:adt_significant_drop_fix r=nikomatsakis Fixes incorrect handling of ADT's drop requirements Fixes #90024 and a bunch of duplicates. The main issue was just that the contract of `NeedsDropTypes::adt_components` was inconsistent; the list of types it might return were the generic parameters themselves or the fields of the ADT depending on the nature of the drop impl. This meant that the caller could not determine whether a `.subst()` call was still needed on those types; it called `.subst()` in all cases and this led to ICEs when the returned types were the generic params. First contribution of more than a few lines so feedback definitely appreciated.,HEART,2021-10-29T01:01:42Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90218,MERGED,2021-10-23T22:28:23Z,2021-10-28T19:00:36Z,Fixes incorrect handling of ADT's drop requirements,JakobDegen,85c0558d032e204f4f4ed6137f3119cb92dbc684,2,Auto merge of #90218 - JakobDegen:adt_significant_drop_fix r=nikomatsakis Fixes incorrect handling of ADT's drop requirements Fixes #90024 and a bunch of duplicates. The main issue was just that the contract of `NeedsDropTypes::adt_components` was inconsistent; the list of types it might return were the generic parameters themselves or the fields of the ADT depending on the nature of the drop impl. This meant that the caller could not determine whether a `.subst()` call was still needed on those types; it called `.subst()` in all cases and this led to ICEs when the returned types were the generic params. First contribution of more than a few lines so feedback definitely appreciated.,ROCKET,2021-10-29T01:01:43Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90220,CLOSED,2021-10-24T03:12:05Z,2021-10-24T18:42:01Z,Dump sccache log as part of CI,Mark-Simulacrum,NA,NA,NA,THUMBS_UP,2021-10-24T05:36:17Z,hkratz,NA https://github.com/rust-lang/rust/pull/90231,CLOSED,2021-10-24T11:38:24Z,2021-10-24T11:47:07Z,Fix Duration::from_secs_f32,manio,NA,NA,NA,THUMBS_UP,2021-10-26T08:21:53Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/90234,MERGED,2021-10-24T13:42:03Z,2021-10-24T17:07:35Z,Temporarily turn overflow checks off for rustc-rayon-core,hkratz,eee29fd34c9fdc9afddfc3108d8e36199854f0b3,1,Rollup merge of #90234 - rusticstuff:rustc-rayon-core-no-overflow-checks r=Mark-Simulacrum Temporarily turn overflow checks off for rustc-rayon-core The rustc fork of Rayon has deadlock detection code which intermittently causes overflows in the CI (see https://github.com/rust-lang/rust/issues/90227). So as a workaround we unconditionally turn overflow checks off for this crate only. This workaround should be removed once #90227 is fixed. r? `@Mark-Simulacrum` cc `@matthiaskrgr`,THUMBS_UP,2021-10-24T13:49:16Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/90236,CLOSED,2021-10-24T14:11:46Z,2021-10-26T11:17:40Z,Ship an llvm-coverage-tools component with just llvm-cov and llvm-profdata,joshtriplett,NA,NA,NA,HOORAY,2021-10-25T20:35:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90274,CLOSED,2021-10-25T16:52:18Z,2022-01-12T14:20:48Z,Cleanup: Eliminate ConstnessAnd,oli-obk,NA,NA,NA,HEART,2021-10-26T12:37:57Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/90274,CLOSED,2021-10-25T16:52:18Z,2022-01-12T14:20:48Z,Cleanup: Eliminate ConstnessAnd,oli-obk,NA,NA,NA,HEART,2021-11-04T11:10:11Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90281,MERGED,2021-10-25T20:18:17Z,2021-10-28T22:44:47Z,Add BorrowSet to public api,xldenis,c390d69a615f095208ac94841f3310268521b2ee,2,Auto merge of #90281 - xldenis:public-borrow-set r=nikomatsakis Add BorrowSet to public api This PR adds `BorrowSet` to the public api so that verification tools can obtain the activation and reservation points of two phase borrows without having to redo calculations themselves (and thus potentially differently from rustc). Turns out we already can obtain `MoveData` thanks to the public `HasMoveData` trait so constructing a `BorrowSet` should not provide much of an issue. However I can't speak to the soundness of this approach is it safe to take an under-approximation of `MoveData`? r? `@nikomatsakis`,HEART,2021-10-25T22:03:35Z,fpoli,NA https://github.com/rust-lang/rust/pull/90288,MERGED,2021-10-26T00:12:12Z,2021-10-27T21:38:01Z,Add hint for people missing `TryFrom` `TryInto` `FromIterator` import pre-2021,JakobDegen,83d5c240711840202dda6d4581ba1f420c916c21,6,Rollup merge of #90288 - JakobDegen:import_diagnostics r=davidtwco Add hint for people missing `TryFrom` `TryInto` `FromIterator` import pre-2021 Adds a hint anytime a `TryFrom` `TryInto` `FromIterator` import is suggested noting that these traits are automatically imported in Edition 2021.,THUMBS_UP,2021-10-26T07:57:50Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/90296,MERGED,2021-10-26T03:39:58Z,2021-10-26T21:06:43Z,Remove fNN::lerp,CAD97,8871fe8bda9625afc6e39cd9cd73f7bf87233fe9,5,Rollup merge of #90296 - CAD97:rip-lerp r=Mark-Simulacrum Remove fNN::lerp Lerp is [surprisingly complex with multiple tradeoffs depending on what guarantees you want to provide](https://github.com/rust-lang/rust/issues/86269#issuecomment-869108301) (and what you're willing to drop for raw speed) so we don't have consensus on what implementation to use let alone what signature - `t.lerp(a b)` nicely puts `a b` together but makes dispatch to lerp custom types with the same signature basically impossible and major ecosystem crates (e.g. nalgebra glium) use `a.lerp(b t)` which is easily confusable. It was suggested to maybe provide a `Lerp` trait and `t.lerp([a b])` which _could_ be implemented by downstream math libraries for their types but also significantly raises the bar from a simple fNN method to a full trait and does nothing to solve the implementation question. (It also raises the question of whether we'd support higher-order bezier interpolation.) The only consensus we have is the lack of consensus and the [general temperature](https://github.com/rust-lang/rust/issues/86269#issuecomment-951347135) is that we should just remove this method (giving the method space back to 3rd party libs) and revisit this if (and likely only if) IEEE adds lerp to their specification. If people want a lerp they're _probably_ already using (or writing) a math support library which provides a lerp function for its custom math types and can provide the same lerp implementation for the primitive types via an extension trait. See also [previous Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/lerp.20API.20design) cc ``@clarfonthey`` (original PR author) ``@m-ou-se`` (original r+) ``@scottmcm`` (last voice in tracking issue prompted me to post this) Closes #86269 (removed),HEART,2021-10-26T08:34:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/90296,MERGED,2021-10-26T03:39:58Z,2021-10-26T21:06:43Z,Remove fNN::lerp,CAD97,8871fe8bda9625afc6e39cd9cd73f7bf87233fe9,5,Rollup merge of #90296 - CAD97:rip-lerp r=Mark-Simulacrum Remove fNN::lerp Lerp is [surprisingly complex with multiple tradeoffs depending on what guarantees you want to provide](https://github.com/rust-lang/rust/issues/86269#issuecomment-869108301) (and what you're willing to drop for raw speed) so we don't have consensus on what implementation to use let alone what signature - `t.lerp(a b)` nicely puts `a b` together but makes dispatch to lerp custom types with the same signature basically impossible and major ecosystem crates (e.g. nalgebra glium) use `a.lerp(b t)` which is easily confusable. It was suggested to maybe provide a `Lerp` trait and `t.lerp([a b])` which _could_ be implemented by downstream math libraries for their types but also significantly raises the bar from a simple fNN method to a full trait and does nothing to solve the implementation question. (It also raises the question of whether we'd support higher-order bezier interpolation.) The only consensus we have is the lack of consensus and the [general temperature](https://github.com/rust-lang/rust/issues/86269#issuecomment-951347135) is that we should just remove this method (giving the method space back to 3rd party libs) and revisit this if (and likely only if) IEEE adds lerp to their specification. If people want a lerp they're _probably_ already using (or writing) a math support library which provides a lerp function for its custom math types and can provide the same lerp implementation for the primitive types via an extension trait. See also [previous Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/lerp.20API.20design) cc ``@clarfonthey`` (original PR author) ``@m-ou-se`` (original r+) ``@scottmcm`` (last voice in tracking issue prompted me to post this) Closes #86269 (removed),HEART,2021-10-26T16:05:23Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/90297,MERGED,2021-10-26T03:41:02Z,2021-11-06T09:55:50Z,Append .0 to unsuffixed float if it would otherwise become int token,dtolnay,7276a6a11768634c1e7df5605a83a0f117302c50,2,Auto merge of #90297 - dtolnay:dotzero r=petrochenkov Append .0 to unsuffixed float if it would otherwise become int token Previously the unsuffixed f32/f64 constructors of `proc_macro::Literal` would create literal tokens that are definitely not a float: ```rust Literal::f32_unsuffixed(10.0) // 10 Literal::f32_suffixed(10.0) // 10f32 Literal::f64_unsuffixed(10.0) // 10 Literal::f64_suffixed(10.0) // 10f64 ``` Notice that the `10` are actually integer tokens if you were to reparse them not float tokens. This diff updates `Literal::f32_unsuffixed` and `Literal::f64_unsuffixed` to produce tokens that unambiguously parse as a float. This matches longstanding behavior of the proc-macro2 crate's implementation of these APIs dating back at least 3.5 years so it's likely an unobjectionable behavior. ```rust Literal::f32_unsuffixed(10.0) // 10.0 Literal::f32_suffixed(10.0) // 10f32 Literal::f64_unsuffixed(10.0) // 10.0 Literal::f64_suffixed(10.0) // 10f64 ``` Fixes https://github.com/dtolnay/syn/issues/1085.,THUMBS_UP,2021-10-26T12:18:29Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/90297,MERGED,2021-10-26T03:41:02Z,2021-11-06T09:55:50Z,Append .0 to unsuffixed float if it would otherwise become int token,dtolnay,7276a6a11768634c1e7df5605a83a0f117302c50,2,Auto merge of #90297 - dtolnay:dotzero r=petrochenkov Append .0 to unsuffixed float if it would otherwise become int token Previously the unsuffixed f32/f64 constructors of `proc_macro::Literal` would create literal tokens that are definitely not a float: ```rust Literal::f32_unsuffixed(10.0) // 10 Literal::f32_suffixed(10.0) // 10f32 Literal::f64_unsuffixed(10.0) // 10 Literal::f64_suffixed(10.0) // 10f64 ``` Notice that the `10` are actually integer tokens if you were to reparse them not float tokens. This diff updates `Literal::f32_unsuffixed` and `Literal::f64_unsuffixed` to produce tokens that unambiguously parse as a float. This matches longstanding behavior of the proc-macro2 crate's implementation of these APIs dating back at least 3.5 years so it's likely an unobjectionable behavior. ```rust Literal::f32_unsuffixed(10.0) // 10.0 Literal::f32_suffixed(10.0) // 10f32 Literal::f64_unsuffixed(10.0) // 10.0 Literal::f64_suffixed(10.0) // 10f64 ``` Fixes https://github.com/dtolnay/syn/issues/1085.,THUMBS_UP,2021-10-27T00:17:29Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-10-26T21:56:39Z,Enet4,NA https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-10-26T22:53:53Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-10-27T08:16:39Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-10-27T20:01:35Z,jam1garner,jam@jam1.re https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-12-09T00:25:43Z,seritools,git@seri.tools https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2021-12-09T03:40:55Z,lygstate,luoyonggang@gmail.com https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2022-02-11T17:16:17Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90328,CLOSED,2021-10-26T21:43:06Z,2022-06-17T18:17:39Z,Move the Error trait into core (without `fn backtrace`),yaahc,NA,NA,NA,EYES,2022-04-29T15:20:06Z,kraktus,NA https://github.com/rust-lang/rust/pull/90329,MERGED,2021-10-26T22:31:15Z,2021-11-19T06:13:37Z,Try all stable method candidates first before trying unstable ones,nbdd0121,ce3f3a5ffa7452131cde06c003cc2eaa7c729bfb,7,"Auto merge of #90329 - nbdd0121:typeck r=nagisa Try all stable method candidates first before trying unstable ones Currently we try methods in this order in each step: * Stable by value * Unstable by value * Stable autoref * Unstable autoref * ... This PR changes it to first try pick methods without any unstable candidates and if none is found try again to pick unstable ones. Fix #90320 CC #88971 hopefully would allow us to rename the ""unstable_*"" methods for integer impls back. `@rustbot` label T-compiler T-libs-api",HEART,2021-12-18T01:50:11Z,tmandry,NA https://github.com/rust-lang/rust/pull/90329,MERGED,2021-10-26T22:31:15Z,2021-11-19T06:13:37Z,Try all stable method candidates first before trying unstable ones,nbdd0121,ce3f3a5ffa7452131cde06c003cc2eaa7c729bfb,7,"Auto merge of #90329 - nbdd0121:typeck r=nagisa Try all stable method candidates first before trying unstable ones Currently we try methods in this order in each step: * Stable by value * Unstable by value * Stable autoref * Unstable autoref * ... This PR changes it to first try pick methods without any unstable candidates and if none is found try again to pick unstable ones. Fix #90320 CC #88971 hopefully would allow us to rename the ""unstable_*"" methods for integer impls back. `@rustbot` label T-compiler T-libs-api",HOORAY,2022-01-12T14:03:10Z,tspiteri,tspiteri@ieee.org https://github.com/rust-lang/rust/pull/90329,MERGED,2021-10-26T22:31:15Z,2021-11-19T06:13:37Z,Try all stable method candidates first before trying unstable ones,nbdd0121,ce3f3a5ffa7452131cde06c003cc2eaa7c729bfb,7,"Auto merge of #90329 - nbdd0121:typeck r=nagisa Try all stable method candidates first before trying unstable ones Currently we try methods in this order in each step: * Stable by value * Unstable by value * Stable autoref * Unstable autoref * ... This PR changes it to first try pick methods without any unstable candidates and if none is found try again to pick unstable ones. Fix #90320 CC #88971 hopefully would allow us to rename the ""unstable_*"" methods for integer impls back. `@rustbot` label T-compiler T-libs-api",HEART,2022-01-12T22:24:22Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/90345,MERGED,2021-10-27T14:16:36Z,2021-12-21T12:01:17Z,Stabilise entry_insert,passcod,3009dd7c5a6da3c36c61ce89d5320ed8c0922a22,1,Rollup merge of #90345 - passcod:entry-insert r=dtolnay Stabilise entry_insert This stabilises `HashMap:Entry::insert_entry` etc. Tracking issue #65225. It will need an FCP. This was implemented in #64656 two years ago. This PR includes the rename and change discussed in https://github.com/rust-lang/rust/issues/65225#issuecomment-910652430 happy to split if needed.,HEART,2021-12-29T20:05:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-10-28T19:45:31Z,xTachyon,NA https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-10-28T19:47:33Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-11-03T02:10:36Z,jlb6740,johnnie.l.birch.jr@intel.com https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-11-07T17:28:23Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",HEART,2021-11-07T17:28:27Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-11-10T00:31:53Z,syrusakbary,me@syrusakbary.com https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-11-15T20:07:17Z,Agrailag,NA https://github.com/rust-lang/rust/pull/90382,MERGED,2021-10-28T18:00:57Z,2021-11-18T20:23:35Z,std: Get the standard library compiling for wasm64,alexcrichton,b6f580acc0ce233d5c4d1f9680d354fded88b824,31,"Auto merge of #90382 - alexcrichton:wasm64-libstd r=joshtriplett std: Get the standard library compiling for wasm64 This commit goes through and updates various `#[cfg]` as appropriate to get the wasm64-unknown-unknown target behaving similarly to the wasm32-unknown-unknown target. Most of this is just updating various conditions for `target_arch = ""wasm32""` to also account for `target_arch = ""wasm64""` where appropriate. This commit also lists `wasm64` as an allow-listed architecture to not have the `restricted_std` feature enabled enabling experimentation with `-Z build-std` externally. The main goal of this commit is to enable playing around with `wasm64-unknown-unknown` externally via `-Z build-std` in a way that's similar to the `wasm32-unknown-unknown` target. These targets are effectively the same and only differ in their pointer size but wasm64 is much newer and has much less ecosystem/library support so it'll still take time to get wasm64 fully-fledged.",THUMBS_UP,2021-11-26T20:04:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90383,MERGED,2021-10-28T19:45:57Z,2022-01-01T02:03:30Z,Extend check for UnsafeCell in consts to cover unions,tmiasko,ac1060e188bc30800726609ae65b1f1a4ad7291e,4,Rollup merge of #90383 - tmiasko:union-validity r=RalfJung Extend check for UnsafeCell in consts to cover unions A validity companion to changes from #90373. `@rust-lang/wg-const-eval`,HEART,2021-10-28T22:25:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/90389,MERGED,2021-10-29T01:28:39Z,2021-10-29T18:41:20Z,rustdoc: Switch to mainline rayon,camelid,deb45729231561effe503e8be0d0e62ec01a8c1d,3,Auto merge of #90389 - camelid:rustdoc-rayon r=jyn514 rustdoc: Switch to mainline rayon The rustc fork of rayon integrates with Cargo's jobserver to limit the amount of parallelism. However rustdoc's use case is concurrent I/O which is not CPU-heavy so it should be able to use mainline rayon. See [this discussion][1] for more details. [1]: https://github.com/rust-lang/rust/issues/90227#issuecomment-952468618 Note: I chose rayon 1.3.1 so that the rayon version used elsewhere in the workspace does not change. r? `@Mark-Simulacrum` cc `@jyn514`,THUMBS_UP,2021-10-29T08:49:24Z,hkratz,NA https://github.com/rust-lang/rust/pull/90399,MERGED,2021-10-29T12:54:55Z,2021-10-30T22:39:23Z,Skipping verbose diagnostic suggestions when calling .as_ref() on type not implementing AsRef,yuvaldolev,197da45e183097f108c6f5f283a30070845f182d,3,Rollup merge of #90399 - yuvaldolev:as-ref-overly-verbose-diagnostic r=estebank Skipping verbose diagnostic suggestions when calling .as_ref() on type not implementing AsRef Addresses #89806 Skipping suggestions when calling `.as_ref()` for types that do not implement the `AsRef` trait. r? `@estebank`,HEART,2021-10-29T16:20:05Z,estebank,NA https://github.com/rust-lang/rust/pull/90408,MERGED,2021-10-29T21:18:30Z,2021-12-23T01:47:17Z,Remove `PartialOrd` `Ord` from `LocalDefId`,pierwill,e98309298d927307c5184f4869604bd068d26183,13,Auto merge of #90408 - pierwill:untrack-localdefid-90317 r=cjgillot Remove `PartialOrd` `Ord` from `LocalDefId` Part of work on https://github.com/rust-lang/rust/issues/90317.,HOORAY,2021-11-25T20:50:21Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90408,MERGED,2021-10-29T21:18:30Z,2021-12-23T01:47:17Z,Remove `PartialOrd` `Ord` from `LocalDefId`,pierwill,e98309298d927307c5184f4869604bd068d26183,13,Auto merge of #90408 - pierwill:untrack-localdefid-90317 r=cjgillot Remove `PartialOrd` `Ord` from `LocalDefId` Part of work on https://github.com/rust-lang/rust/issues/90317.,HOORAY,2021-12-23T07:51:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:

Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-10-30T13:07:22Z,the8472,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-10-30T14:36:13Z,est31,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-10-30T19:25:37Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-10-30T20:48:36Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-10-31T10:35:01Z,hkratz,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-11-01T10:05:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,HEART,2021-12-05T11:10:42Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2021-12-15T00:40:04Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2022-02-10T06:17:03Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,HEART,2022-02-10T06:17:04Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,HEART,2022-02-10T21:09:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2022-02-10T21:09:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,HEART,2022-02-10T21:18:26Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2022-02-12T15:17:54Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2022-04-18T19:06:31Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,HEART,2022-04-18T19:06:32Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/90414,MERGED,2021-10-30T11:10:43Z,2022-02-06T12:33:59Z,Optimize `core::str::Chars::count`,thomcc,f624427f8771c00819684c783bb841bf72095704,7,Auto merge of #90414 - thomcc:count-chars-faster r=nagisa Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile but never got around to contributing it. I saw it again and so here it is. The implementation is fairly complex but I tried to explain what's happening at both a high level (in the header comment for the file) and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below) for a wide variety of workloads without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code so that they explicitly check text in different languages and of different sizes (err the cross product of language x size). The results of the benchmarks are here:
Benchmark results 
 test str::char_count::emoji_huge::case00_cur_libcore       ... bench:      20 216 ns/iter (+/- 3 673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore       ... bench:     108 851 ns/iter (+/- 12 777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment    ... bench:     329 502 ns/iter (+/- 4 163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len   ... bench:     223 333 ns/iter (+/- 14 167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore      ... bench:         293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore      ... bench:       1 681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment   ... bench:       5 166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len  ... bench:       3 476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore     ... bench:          48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore     ... bench:         217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment  ... bench:         642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench:         445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore      ... bench:          18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore      ... bench:          23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment   ... bench:          66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len  ... bench:          29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore          ... bench:      25 909 ns/iter (+/- 39 260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore          ... bench:     102 887 ns/iter (+/- 3 257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment       ... bench:     166 370 ns/iter (+/- 12 439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len      ... bench:     166 332 ns/iter (+/- 4 262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore         ... bench:         281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore         ... bench:       1 598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment      ... bench:       2 598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len     ... bench:       2 578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore        ... bench:          44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore        ... bench:         201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment     ... bench:         322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len    ... bench:         319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore         ... bench:          15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore         ... bench:          14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment      ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len     ... bench:          30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore          ... bench:      16 439 ns/iter (+/- 3 105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore          ... bench:      89 480 ns/iter (+/- 2 555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment       ... bench:     217 703 ns/iter (+/- 22 185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len      ... bench:     157 330 ns/iter (+/- 19 188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore         ... bench:         243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore         ... bench:       1 384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment      ... bench:       3 381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len     ... bench:       2 423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore        ... bench:          42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore        ... bench:         180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment     ... bench:         402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len    ... bench:         280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore         ... bench:          12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment      ... bench:          19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len     ... bench:          14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore          ... bench:      15 053 ns/iter (+/- 2 640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore          ... bench:      82 622 ns/iter (+/- 3 602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment       ... bench:     230 456 ns/iter (+/- 7 246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len      ... bench:     220 595 ns/iter (+/- 11 624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore         ... bench:         227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore         ... bench:       1 136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment      ... bench:       3 147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len     ... bench:       2 993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore        ... bench:          36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore        ... bench:         142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment     ... bench:         379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len    ... bench:         364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore         ... bench:          11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment      ... bench:          20 ns/iter (+/- 3) = 1650 MB/s
I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s which is surprising given how thorough they are but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066 so I'm going to request review from the same person who reviewed that one. That said am not particularly picky and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`,ROCKET,2022-04-21T11:52:14Z,mustafakibar,mustafa@kibar.pro https://github.com/rust-lang/rust/pull/90420,MERGED,2021-10-30T15:47:12Z,2021-11-25T02:16:01Z,Create rustdoc_internals feature gate,GuillaumeGomez,a6a1d7ca2936ddb33dbaad69ae3a8a47b9208498,22,Rollup merge of #90420 - GuillaumeGomez:rustdoc-internals-feature r=camelid Create rustdoc_internals feature gate As suggested by ``@camelid`` [here](https://github.com/rust-lang/rust/pull/90398#issuecomment-955093851) since `doc_keyword` and `doc_primitive` aren't meant to be stabilized we could put them behind a same feature flag. This is pretty much what it would look like (needs to update the tests too). The tracking issue is https://github.com/rust-lang/rust/issues/90418. What do you think ``@rust-lang/rustdoc`` ?,THUMBS_UP,2021-10-30T18:39:17Z,Manishearth,manishsmail@gmail.com https://github.com/rust-lang/rust/pull/90420,MERGED,2021-10-30T15:47:12Z,2021-11-25T02:16:01Z,Create rustdoc_internals feature gate,GuillaumeGomez,a6a1d7ca2936ddb33dbaad69ae3a8a47b9208498,22,Rollup merge of #90420 - GuillaumeGomez:rustdoc-internals-feature r=camelid Create rustdoc_internals feature gate As suggested by ``@camelid`` [here](https://github.com/rust-lang/rust/pull/90398#issuecomment-955093851) since `doc_keyword` and `doc_primitive` aren't meant to be stabilized we could put them behind a same feature flag. This is pretty much what it would look like (needs to update the tests too). The tracking issue is https://github.com/rust-lang/rust/issues/90418. What do you think ``@rust-lang/rustdoc`` ?,THUMBS_UP,2021-11-10T19:26:55Z,camelid,NA https://github.com/rust-lang/rust/pull/90423,MERGED,2021-10-30T19:15:02Z,2021-12-12T14:24:33Z,Deduplicate projection sub-obligations,Aaron1011,4c9bdf4cbbf1deab0b5da398d4910558a66b332f,1,Auto merge of #90423 - Aaron1011:deduplicate-projection r=jackh726 Deduplicate projection sub-obligations,THUMBS_UP,2021-12-09T00:22:10Z,estebank,NA https://github.com/rust-lang/rust/pull/90439,MERGED,2021-10-31T14:10:43Z,2021-11-02T11:14:06Z,Add JoinHandle::is_running.,m-ou-se,6384dca100f3cedfa031a9204586f94f8612eae5,2,Auto merge of #90439 - m-ou-se:thread-is-running r=Mark-Simulacrum Add JoinHandle::is_running. This adds: ```rust impl JoinHandle { /// Checks if the the associated thread is still running its main function. /// /// This might return `false` for a brief moment after the thread's main /// function has returned but before the thread itself has stopped running. pub fn is_running(&self) -> bool; } ``` The usual way to check if a background thread is still running is to set some atomic flag at the end of its main function. We already do that in the form of dropping an Arc which will reduce the reference counter. So we might as well expose that information. This is useful in applications with a main loop (e.g. a game gui control system ..) where you spawn some background task and check every frame/iteration whether the background task is finished to .join() it in that frame/iteration while keeping the program responsive.,THUMBS_UP,2021-10-31T16:05:45Z,marmeladema,NA https://github.com/rust-lang/rust/pull/90439,MERGED,2021-10-31T14:10:43Z,2021-11-02T11:14:06Z,Add JoinHandle::is_running.,m-ou-se,6384dca100f3cedfa031a9204586f94f8612eae5,2,Auto merge of #90439 - m-ou-se:thread-is-running r=Mark-Simulacrum Add JoinHandle::is_running. This adds: ```rust impl JoinHandle { /// Checks if the the associated thread is still running its main function. /// /// This might return `false` for a brief moment after the thread's main /// function has returned but before the thread itself has stopped running. pub fn is_running(&self) -> bool; } ``` The usual way to check if a background thread is still running is to set some atomic flag at the end of its main function. We already do that in the form of dropping an Arc which will reduce the reference counter. So we might as well expose that information. This is useful in applications with a main loop (e.g. a game gui control system ..) where you spawn some background task and check every frame/iteration whether the background task is finished to .join() it in that frame/iteration while keeping the program responsive.,THUMBS_UP,2021-11-11T03:49:03Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90439,MERGED,2021-10-31T14:10:43Z,2021-11-02T11:14:06Z,Add JoinHandle::is_running.,m-ou-se,6384dca100f3cedfa031a9204586f94f8612eae5,2,Auto merge of #90439 - m-ou-se:thread-is-running r=Mark-Simulacrum Add JoinHandle::is_running. This adds: ```rust impl JoinHandle { /// Checks if the the associated thread is still running its main function. /// /// This might return `false` for a brief moment after the thread's main /// function has returned but before the thread itself has stopped running. pub fn is_running(&self) -> bool; } ``` The usual way to check if a background thread is still running is to set some atomic flag at the end of its main function. We already do that in the form of dropping an Arc which will reduce the reference counter. So we might as well expose that information. This is useful in applications with a main loop (e.g. a game gui control system ..) where you spawn some background task and check every frame/iteration whether the background task is finished to .join() it in that frame/iteration while keeping the program responsive.,THUMBS_UP,2021-11-24T19:13:17Z,riking,NA https://github.com/rust-lang/rust/pull/90439,MERGED,2021-10-31T14:10:43Z,2021-11-02T11:14:06Z,Add JoinHandle::is_running.,m-ou-se,6384dca100f3cedfa031a9204586f94f8612eae5,2,Auto merge of #90439 - m-ou-se:thread-is-running r=Mark-Simulacrum Add JoinHandle::is_running. This adds: ```rust impl JoinHandle { /// Checks if the the associated thread is still running its main function. /// /// This might return `false` for a brief moment after the thread's main /// function has returned but before the thread itself has stopped running. pub fn is_running(&self) -> bool; } ``` The usual way to check if a background thread is still running is to set some atomic flag at the end of its main function. We already do that in the form of dropping an Arc which will reduce the reference counter. So we might as well expose that information. This is useful in applications with a main loop (e.g. a game gui control system ..) where you spawn some background task and check every frame/iteration whether the background task is finished to .join() it in that frame/iteration while keeping the program responsive.,THUMBS_UP,2022-01-21T14:37:30Z,Calandiel,NA https://github.com/rust-lang/rust/pull/90446,MERGED,2021-10-31T17:40:53Z,2021-12-02T02:15:08Z,Lint elided lifetimes in path during lifetime resolution.,cjgillot,76938d64a42304e4413842656c044e9b40a6041b,13,Auto merge of #90446 - cjgillot:late-elided r=jackh726 Lint elided lifetimes in path during lifetime resolution. The lifetime elision lint is known to be brittle and can be redundant with later lifetime resolution errors. This PR aims to remove the redundancy by performing the lint after lifetime resolution. This PR proposes to carry the information that an elision should be linted against by using a special `LifetimeName`. I am not certain this is the best solution but it is certainly the easiest. Fixes https://github.com/rust-lang/rust/issues/60199 Fixes https://github.com/rust-lang/rust/issues/55768 Fixes https://github.com/rust-lang/rust/issues/63110 Fixes https://github.com/rust-lang/rust/issues/71957,HEART,2021-11-14T14:06:58Z,marmeladema,NA https://github.com/rust-lang/rust/pull/90446,MERGED,2021-10-31T17:40:53Z,2021-12-02T02:15:08Z,Lint elided lifetimes in path during lifetime resolution.,cjgillot,76938d64a42304e4413842656c044e9b40a6041b,13,Auto merge of #90446 - cjgillot:late-elided r=jackh726 Lint elided lifetimes in path during lifetime resolution. The lifetime elision lint is known to be brittle and can be redundant with later lifetime resolution errors. This PR aims to remove the redundancy by performing the lint after lifetime resolution. This PR proposes to carry the information that an elision should be linted against by using a special `LifetimeName`. I am not certain this is the best solution but it is certainly the easiest. Fixes https://github.com/rust-lang/rust/issues/60199 Fixes https://github.com/rust-lang/rust/issues/55768 Fixes https://github.com/rust-lang/rust/issues/63110 Fixes https://github.com/rust-lang/rust/issues/71957,HEART,2021-11-17T12:28:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90446,MERGED,2021-10-31T17:40:53Z,2021-12-02T02:15:08Z,Lint elided lifetimes in path during lifetime resolution.,cjgillot,76938d64a42304e4413842656c044e9b40a6041b,13,Auto merge of #90446 - cjgillot:late-elided r=jackh726 Lint elided lifetimes in path during lifetime resolution. The lifetime elision lint is known to be brittle and can be redundant with later lifetime resolution errors. This PR aims to remove the redundancy by performing the lint after lifetime resolution. This PR proposes to carry the information that an elision should be linted against by using a special `LifetimeName`. I am not certain this is the best solution but it is certainly the easiest. Fixes https://github.com/rust-lang/rust/issues/60199 Fixes https://github.com/rust-lang/rust/issues/55768 Fixes https://github.com/rust-lang/rust/issues/63110 Fixes https://github.com/rust-lang/rust/issues/71957,HEART,2021-12-02T02:18:13Z,estebank,NA https://github.com/rust-lang/rust/pull/90451,CLOSED,2021-10-31T18:44:13Z,2021-12-30T17:10:14Z,Decouple rustc_resolve and rustc_ast_lowering,cjgillot,NA,NA,NA,EYES,2021-10-31T18:53:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90472,MERGED,2021-11-01T14:35:07Z,2021-11-03T05:02:46Z,Clarify what to do with accepted feature gates,joshtriplett,bc26dbba1156b7b5cbfc921a3d3884770d11b36d,1,Rollup merge of #90472 - joshtriplett:clarify-feature-acceptance r=jyn514 Clarify what to do with accepted feature gates The documentation only referenced `removed.rs` but feature gates for accepted features move to `accepted.rs`.,THUMBS_UP,2021-11-01T14:56:38Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:30:20Z,CryZe,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:30:38Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:33:20Z,tvallotton,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T15:33:54Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T15:34:39Z,tvallotton,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:40:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:43:21Z,cristicbz,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:44:25Z,darksv,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:52:27Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T15:53:00Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:02:48Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:05:32Z,mrpink76,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T16:06:15Z,mrpink76,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:24:55Z,strohel,matej@laitl.cz https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:34:19Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:35:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T16:35:53Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T16:35:55Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T16:35:56Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T17:42:53Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T17:48:34Z,reillysiemens,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T17:52:35Z,robinhundt,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T17:54:51Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T17:54:53Z,unexge,unexge@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T17:58:33Z,est31,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:18:32Z,arusahni,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T18:18:33Z,arusahni,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:27:08Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T18:27:10Z,rafaelcaricio,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:29:39Z,Fishrock123,fishrock123@rocketmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:30:47Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:42:51Z,repi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T18:55:11Z,msrd0,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T18:55:12Z,msrd0,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T19:04:19Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T19:04:19Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T19:06:02Z,Stargateur,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T19:06:02Z,Stargateur,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T19:38:31Z,nfriedly,nathan@nfriedly.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:01:01Z,pachi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T20:13:05Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:13:06Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:27:08Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:27:50Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:36:54Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T20:36:55Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T20:43:38Z,PhilippGackstatter,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T21:34:18Z,mraerino,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T21:34:21Z,mraerino,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T21:38:41Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T21:38:41Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T22:01:08Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T22:46:31Z,keichinger,kai.eichinger@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T22:46:32Z,keichinger,kai.eichinger@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T22:52:57Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T22:52:57Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T22:57:12Z,Milo123459,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T22:57:13Z,Milo123459,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T23:04:25Z,whentze,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T23:27:24Z,Heliozoa,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T23:29:37Z,yerke,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T23:29:38Z,yerke,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T23:42:37Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T23:42:39Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-01T23:48:53Z,JoelScarfone,joelrscarfone@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-01T23:48:54Z,JoelScarfone,joelrscarfone@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T00:28:58Z,bretzle,johnfish218@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T01:54:36Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T02:00:16Z,insou22,zac.kologlu@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T02:00:18Z,insou22,zac.kologlu@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T02:11:03Z,cshuaimin,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T02:28:24Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T03:00:17Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T03:00:17Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T03:24:40Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T04:06:28Z,micahsnyder,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T05:10:20Z,newcomb-luke,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T08:37:32Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T08:37:34Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T08:54:27Z,numToStr,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T09:21:30Z,DanSnow,dododavid006@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T09:30:42Z,OnurKader,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T09:48:04Z,damszew,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T09:58:07Z,iago-lito,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T09:58:08Z,iago-lito,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T10:37:01Z,Folyd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T10:37:01Z,Folyd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T11:12:56Z,Nugine,nugine@foxmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T11:21:19Z,mati865,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T11:21:20Z,mati865,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T11:33:05Z,Ltrlg,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T11:52:31Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T12:48:50Z,Seppel3210,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T12:48:51Z,Seppel3210,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T15:39:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T16:09:12Z,QuarticCat,QuarticCat@protonmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-02T17:41:32Z,TrevorAC99,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-02T22:16:57Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-03T06:28:55Z,ZeWaka,zewakagamer@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-03T06:28:58Z,ZeWaka,zewakagamer@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-04T06:40:10Z,sebschmi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-04T08:20:39Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-04T19:22:15Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-04T19:22:16Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-04T22:33:41Z,hkratz,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-04T22:33:42Z,hkratz,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-05T01:34:31Z,tux3,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-05T01:34:31Z,tux3,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-05T06:25:21Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-05T06:26:47Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-05T06:26:48Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-05T06:26:53Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-05T06:26:56Z,AurevoirXavier,xavier@inv.cafe https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-05T13:54:48Z,davidhewitt,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-06T22:23:59Z,bstrie,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-08T05:43:43Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-08T05:43:44Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-09T04:44:35Z,al2me6,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-10T13:30:14Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-11T01:48:08Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-11T09:39:44Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-11T12:28:50Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-13T00:47:09Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-13T10:02:04Z,niilz,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-13T19:47:52Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-13T19:47:53Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T05:10:09Z,trevyn,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T05:10:11Z,trevyn,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T05:26:16Z,nathanwhit,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T05:46:17Z,kmurphy4,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T06:06:16Z,ozkriff,ozkriff@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T06:25:57Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T06:25:58Z,dpc,dpc@dpc.pw https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T07:29:15Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T08:19:12Z,Zymlex,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-15T08:19:13Z,Zymlex,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T08:19:15Z,Zymlex,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T09:16:26Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T09:43:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T09:43:40Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T10:11:51Z,altanozlu,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T10:11:52Z,altanozlu,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T10:28:29Z,alsuren,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T11:06:19Z,vallentin,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T11:44:36Z,infamous-711,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T12:14:58Z,iRebbok,irebbok@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T12:14:59Z,iRebbok,irebbok@outlook.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T12:20:41Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-15T12:20:45Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T12:20:47Z,MarkTanashchuk,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T18:14:07Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-15T18:14:07Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-15T18:14:08Z,cgwalters,walters@verbum.org https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T19:42:24Z,npv3s,npv3s@skopa.dev https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T19:42:47Z,K0R0VA,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T19:45:34Z,optozorax,optozorax@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T19:45:41Z,murka,im@murka.me https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-15T21:30:19Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T21:30:20Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-15T21:30:21Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-15T21:30:23Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T21:46:45Z,dani-garcia,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-15T21:57:05Z,angusholder,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-16T01:45:37Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-16T01:45:37Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-16T01:45:38Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-16T01:45:39Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-16T03:47:54Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-16T04:52:41Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-16T04:52:43Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-16T04:52:55Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-16T04:52:56Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-16T20:37:12Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-16T20:37:14Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-17T15:41:37Z,sbeyer,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-17T15:41:40Z,sbeyer,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-17T15:41:41Z,sbeyer,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-18T02:11:59Z,harrier-lcc,mmu20046f03@yahoo.com.hk https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-18T07:21:41Z,joseluis,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-18T12:10:36Z,chdsbd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-18T12:10:37Z,chdsbd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-11-18T12:10:38Z,chdsbd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-18T12:10:38Z,chdsbd,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-18T13:58:54Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-18T19:36:02Z,rben01,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-11-18T22:58:34Z,josephgimenez,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-11-19T10:45:55Z,Yura52,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-11-20T04:36:33Z,seanpianka,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-04T19:00:37Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-12-04T19:00:37Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-12-04T19:00:38Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-12-04T19:00:40Z,andrewbanchich,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-12-04T21:02:20Z,msrd0,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-12-04T21:02:22Z,msrd0,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-12-05T09:15:37Z,Zymlex,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-06T11:14:04Z,hcsch,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-19T00:04:41Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-19T08:19:29Z,nyurik,yuriastrakhan@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-12-29T18:51:59Z,rod-stuchi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-29T18:52:00Z,rod-stuchi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-12-29T18:52:04Z,rod-stuchi,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2021-12-30T01:22:43Z,95th,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2021-12-30T01:22:45Z,95th,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2021-12-30T01:22:45Z,95th,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2021-12-30T01:22:48Z,95th,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-01-05T11:14:30Z,ta3113ta,wuttichai3113@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-07T09:16:57Z,suikodev,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-10T14:00:38Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-12T11:33:51Z,amousset,contact@amousset.me https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-12T18:26:10Z,jaybosamiya,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-12T23:14:21Z,gchudnov,g.chudnov@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-13T11:46:28Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-13T17:23:57Z,ivan-aksamentov,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-13T19:30:50Z,latk,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-13T23:47:47Z,maxwase,max.vvase@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2022-01-13T23:47:49Z,maxwase,max.vvase@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-14T02:37:53Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-14T13:56:17Z,Emerentius,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-14T13:56:19Z,Emerentius,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-01-14T20:27:14Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-14T20:27:14Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-14T20:27:15Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2022-01-14T20:27:16Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-01-14T21:31:39Z,Squidtoon99,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,EYES,2022-01-15T01:49:16Z,nebulaa44,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-15T19:35:16Z,janriemer,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-15T19:35:19Z,janriemer,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-16T18:33:46Z,papricasix,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-17T13:20:56Z,myz-dev,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-20T23:21:13Z,nirvana-msu,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-01-22T10:47:35Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-22T10:47:36Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-22T10:47:36Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2022-01-22T10:47:37Z,aymericbeaumet,hi@aymericbeaumet.com https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-23T12:30:58Z,Matmaus,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-01-26T23:20:09Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-01-26T23:20:09Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-01-26T23:20:10Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2022-01-26T23:20:10Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,EYES,2022-01-26T23:20:11Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-03-02T13:58:44Z,balanceglove2,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,THUMBS_UP,2022-04-19T13:10:48Z,cindRoberta,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HOORAY,2022-04-19T13:10:49Z,cindRoberta,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,HEART,2022-04-19T13:10:49Z,cindRoberta,NA https://github.com/rust-lang/rust/pull/90473,MERGED,2021-11-01T15:24:12Z,2021-11-15T19:14:59Z,stabilize format args capture,joshtriplett,c26746af5a925bad66b7ed4f9e7c3018f00d4010,22,Auto merge of #90473 - joshtriplett:stabilize-format-args-capture r=Mark-Simulacrum stabilize format args capture Works as expected and there are widespread reports of success with it as well as interest in it. RFC: rust-lang/rfcs#2795 Tracking issue: https://github.com/rust-lang/rust/issues/67984 Addressing items from the tracking issue: - We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ). - I've updated the documentation. - `panic!` now supports capture as well. - There are potentially opportunities to further improve diagnostics for invalid usage such as if it looks like the user tried to use an expression rather than a variable. However such cases are all already caught and provide reasonable syntax errors now and we can always provided even friendlier diagnostics in the future.,ROCKET,2022-04-19T13:10:50Z,cindRoberta,NA https://github.com/rust-lang/rust/pull/90475,MERGED,2021-11-01T16:04:44Z,2021-11-04T00:15:53Z,rustdoc: Add `DocVisitor` and use it where possible,camelid,4ff90232a0c0c6adb9d2052da2206b26c3c723e4,13,Auto merge of #90475 - camelid:docvisitor r=notriddle rustdoc: Add `DocVisitor` and use it where possible `DocFolder` allows transforming the docs accomplished by making its methods take and return types by-value. However several of the rustdoc `DocFolder` impls only *visit* the docs; they don't change anything. Passing around types by-value is thus unnecessary confusing and potentially inefficient for those impls. `DocVisitor` is very similar to `DocFolder` except that its methods take shared references and return nothing (i.e. the unit type). This should both be more efficient and make the code clearer. There is an additional reason to add `DocVisitor` too. As part of my cleanup of `external_traits` I'm planning to add a `fn cache(&mut self) -> &mut Cache` method to `DocFolder` so that `external_traits` can be retrieved explicitly from the `Cache` rather than implicitly via `Crate.external_traits` (which is an `Rc>`). However some of the `DocFolder` impls that could be turned into `DocVisitor` impls only have a shared reference to the `Cache` because they are used during rendering. (They have to access the `Cache` via `html::render::Context.shared.cache` which involves an `Rc`.) Since `DocVisitor` does not mutate any of the types it's visiting its equivalent `cache()` method will only need a shared reference to the `Cache` avoiding the problem described above. r? `@GuillaumeGomez` cc `@jyn514`,THUMBS_UP,2021-11-01T16:14:37Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90487,MERGED,2021-11-01T21:47:00Z,2021-11-07T01:43:19Z,Add a chapter on reading Rustdoc output,NoraCodes,de332b52afa45dc60d1fda2b8122241632f7ebb0,2,Rollup merge of #90487 - NoraCodes:nora/how-to-read-rustdoc r=jyn514 Add a chapter on reading Rustdoc output Includes documentation for: - general page structure - navigation - searching - themes - deep-linking Doesn't include docs on the settings page. Per https://github.com/rust-lang/rust/issues/90309,HEART,2021-11-01T21:50:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90487,MERGED,2021-11-01T21:47:00Z,2021-11-07T01:43:19Z,Add a chapter on reading Rustdoc output,NoraCodes,de332b52afa45dc60d1fda2b8122241632f7ebb0,2,Rollup merge of #90487 - NoraCodes:nora/how-to-read-rustdoc r=jyn514 Add a chapter on reading Rustdoc output Includes documentation for: - general page structure - navigation - searching - themes - deep-linking Doesn't include docs on the settings page. Per https://github.com/rust-lang/rust/issues/90309,HEART,2021-11-02T16:00:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2021-11-01T22:58:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,HEART,2021-11-01T22:58:03Z,marmeladema,NA https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2021-11-02T01:56:10Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,HEART,2021-11-02T07:06:18Z,bjorn3,NA https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2021-11-02T12:18:29Z,SadiinsoSnowfall,NA https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2021-11-02T19:14:35Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,HEART,2021-11-03T19:22:11Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2021-11-28T17:32:06Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,THUMBS_UP,2022-02-04T08:09:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90488,CLOSED,2021-11-01T22:45:28Z,2022-06-17T16:28:51Z,More powerful const panic,nbdd0121,NA,NA,NA,HEART,2022-02-04T08:09:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90489,MERGED,2021-11-01T23:04:26Z,2021-11-12T01:05:42Z,rustdoc: Go back to loading all external crates unconditionally,jyn514,14a2fd640e0df9ee8cc1e04280b0c3aff93c42da,8,"Auto merge of #90489 - jyn514:load-all-extern-crates r=petrochenkov rustdoc: Go back to loading all external crates unconditionally This *continues* to cause regressions. This code will be unnecessary once access to the resolver happens fully before creating the tyctxt (#83761) so load all crates unconditionally for now. To minimize churn this leaves in the code for loading crates selectively. ""Fixes"" https://github.com/rust-lang/rust/issues/84738. Previously: https://github.com/rust-lang/rust/pull/83738 https://github.com/rust-lang/rust/pull/85749 https://github.com/rust-lang/rust/pull/88215 r? `@petrochenkov` cc `@camelid` (this should fix the ""index out of bounds"" error you had while looking up `crate_name`).",HEART,2021-11-01T23:06:56Z,camelid,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2021-11-05T08:08:45Z,mati865,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2021-11-24T20:46:51Z,bluss,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2021-12-01T09:30:58Z,lqd,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2021-12-02T22:14:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2022-01-09T19:33:16Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2022-01-12T06:44:05Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90491,MERGED,2021-11-02T02:36:47Z,2021-11-24T18:59:14Z,Optimize live point computation,Mark-Simulacrum,8a48b376d559f26a9b8fc1f1d597acb0bc0a51f9,5,Auto merge of #90491 - Mark-Simulacrum:push-pred-faster r=matthewjasper Optimize live point computation This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks. On the benchmark provided in #90445 with 100 000 array elements walltime for a check build is improved from 143 seconds to 15. I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow too.,ROCKET,2022-01-15T07:13:42Z,ibENPC,NA https://github.com/rust-lang/rust/pull/90498,MERGED,2021-11-02T13:22:01Z,2022-01-18T02:32:44Z,Clarifications in the target tier policy,joshtriplett,67bcbde3c50bdf50a48eb0e6a664cc8d02276d9d,3,"Rollup merge of #90498 - joshtriplett:target-tier-policy-draft-updates r=Mark-Simulacrum Clarifications in the target tier policy We've added several targets since the introduction of the target tier policy. Based on experiences of those adding such targets and discussions around such additions clarify the target tier policy to make it easier to follow and work with. None of these changes substantively change the requirements on targets. (In some cases the changes do direct target submitters to follow specific process requirements for the addition of a target such as how to respond to requirements where to put target-specific documentation or what should appear in that documentation. Those changes are procedural in nature and document the procedures we already direct people to follow.) - Clarify how to quote and respond to the target tier policy requirements. Several times people have seemed unclear on how to respond to some of the policy requirements particularly those that just state things the target developers must *not* do (e.g. not posting to PRs that break the target). Add a note that such requirements just need acknowledgement nothing more. - Clarify dependency requirements in the face of cross-compilation. I previously phrased this confusingly in terms of ""host tools"" since that is the case where an exception applies (allowing proprietary target libraries commonly used by binaries for the target). Rephrase it to apply equally to cross-compilation. This doesn't change the net effect of the requirements since other requirements already cover the dependencies of the Rust toolchain. - Clarify documentation about running binaries. The requirement for target documentation talks about ""running tests"" but tier 3 targets often don't support running the full testsuite and in practice the documentation for how to run an individual binary may be more useful. Change ""running tests"" to ""running binaries or running tests"". - Explain where to place target-specific documentation (a subdirectory of platform-support with a link from the platform-support entry for the target). - Add a template for target-specific documentation.",THUMBS_UP,2021-11-03T14:09:40Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T08:26:06Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T08:45:20Z,iago-lito,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-03T08:45:22Z,iago-lito,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T08:48:21Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T11:46:08Z,Visic,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T11:57:07Z,varkor,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T12:34:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-03T12:34:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T12:53:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-03T12:53:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T12:54:22Z,mati865,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-03T12:54:25Z,mati865,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-03T13:23:06Z,aznhe21,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-06T22:46:02Z,pachi,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-06T23:55:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-06T23:55:38Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-06T23:57:13Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T01:04:50Z,Milo123459,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T01:04:51Z,Milo123459,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T01:09:18Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T01:09:18Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T01:27:29Z,Byron,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T03:05:38Z,jieyouxu,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T04:07:14Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T04:22:09Z,KernelFreeze,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T04:58:47Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T04:58:48Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T05:08:54Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T05:08:55Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T05:51:30Z,yerke,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T05:51:31Z,yerke,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T09:57:13Z,inflation,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T09:46:54Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T11:16:03Z,CGMossa,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T11:16:04Z,CGMossa,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T12:55:14Z,Vam-Jam,dm@vamist.dev https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T12:55:15Z,Vam-Jam,dm@vamist.dev https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T16:50:22Z,funbringer,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T16:50:23Z,funbringer,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-07T18:35:53Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-07T18:35:54Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-12T08:02:31Z,Folyd,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-12T08:57:44Z,Demindiro,david@salt-inc.org https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-13T22:05:42Z,raiguard,ch@raiguard.me https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-11-13T22:05:43Z,raiguard,ch@raiguard.me https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-16T05:35:40Z,ulwlu,ulwlu@icloud.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-11-24T13:06:25Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2021-12-12T10:34:19Z,joseluis,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-12-13T02:47:13Z,Vurv78,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-12-18T00:02:18Z,0e4ef622,0e4ef622@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2021-12-24T22:50:56Z,Purpzie,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-01-04T22:53:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-01-17T10:00:24Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-20T12:47:56Z,mn-dex,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-21T14:06:34Z,3ddi,eddilinn@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2022-02-21T20:13:04Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-22T16:03:44Z,brauliobz,brauliobezerra@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2022-02-22T16:03:44Z,brauliobz,brauliobezerra@gmail.com https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-22T21:45:38Z,I60R,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-23T07:36:24Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-23T10:50:31Z,qthree,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-02-23T16:21:09Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2022-02-23T16:21:13Z,DianaNites,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HOORAY,2022-03-11T07:25:20Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90521,MERGED,2021-11-03T06:55:55Z,2021-12-15T12:41:47Z,Stabilize `destructuring_assignment`,jhpratt,d258e92900739e7798ed4fccfbbb8cb0fe519acd,49,Rollup merge of #90521 - jhpratt:stabilize-destructuring_assignment r=jackh726 pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) - [Completed FCP](https://github.com/rust-lang/rust/issues/71126#issuecomment-954914819) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.,HEART,2022-03-11T07:25:20Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90527,MERGED,2021-11-03T13:17:40Z,2021-11-03T18:13:13Z,Provide standalone libc.a in self-contained for musl and wasi,12101111,7734cb80782e65875994ee4709b7752623ea9ed2,1,Auto merge of #90527 - 12101111:libc_a r=petrochenkov Provide standalone libc.a in self-contained for musl and wasi This is a prerequisites of https://github.com/rust-lang/libc/pull/2272 which in turn fix: - https://github.com/rust-lang/wg-cargo-std-aware/issues/66 - https://github.com/rust-lang/rust/issues/89626,HOORAY,2021-11-03T13:28:59Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/90559,MERGED,2021-11-04T11:08:28Z,2021-11-06T19:30:21Z,Optimize bidi character detection.,hkratz,5ec7d1dad6dead949a49c76c8ca0425a6e46a223,5,Auto merge of #90559 - rusticstuff:optimize-bidi-detection r=davidtwco Optimize bidi character detection. Should fix most of the performance regression of the bidi character detection (#90514) to be confirmed with a perf run.,HEART,2021-11-05T15:56:17Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/90559,MERGED,2021-11-04T11:08:28Z,2021-11-06T19:30:21Z,Optimize bidi character detection.,hkratz,5ec7d1dad6dead949a49c76c8ca0425a6e46a223,5,Auto merge of #90559 - rusticstuff:optimize-bidi-detection r=davidtwco Optimize bidi character detection. Should fix most of the performance regression of the bidi character detection (#90514) to be confirmed with a perf run.,HEART,2021-11-05T22:20:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90559,MERGED,2021-11-04T11:08:28Z,2021-11-06T19:30:21Z,Optimize bidi character detection.,hkratz,5ec7d1dad6dead949a49c76c8ca0425a6e46a223,5,Auto merge of #90559 - rusticstuff:optimize-bidi-detection r=davidtwco Optimize bidi character detection. Should fix most of the performance regression of the bidi character detection (#90514) to be confirmed with a perf run.,HEART,2021-11-08T09:44:37Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/90559,MERGED,2021-11-04T11:08:28Z,2021-11-06T19:30:21Z,Optimize bidi character detection.,hkratz,5ec7d1dad6dead949a49c76c8ca0425a6e46a223,5,Auto merge of #90559 - rusticstuff:optimize-bidi-detection r=davidtwco Optimize bidi character detection. Should fix most of the performance regression of the bidi character detection (#90514) to be confirmed with a perf run.,HEART,2021-11-11T03:50:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90559,MERGED,2021-11-04T11:08:28Z,2021-11-06T19:30:21Z,Optimize bidi character detection.,hkratz,5ec7d1dad6dead949a49c76c8ca0425a6e46a223,5,Auto merge of #90559 - rusticstuff:optimize-bidi-detection r=davidtwco Optimize bidi character detection. Should fix most of the performance regression of the bidi character detection (#90514) to be confirmed with a perf run.,HEART,2021-11-11T16:02:07Z,estebank,NA https://github.com/rust-lang/rust/pull/90575,MERGED,2021-11-04T17:01:49Z,2021-11-20T13:31:26Z,Improve suggestions for compatible variants on type mismatch.,m-ou-se,7354bb331e6a88e63c89a3d92c47dcc5afc274f8,15,Rollup merge of #90575 - m-ou-se:compatible-variant-improvements r=estebank Improve suggestions for compatible variants on type mismatch. Fixes #90553. Before: ![image](https://user-images.githubusercontent.com/783247/140385675-6ff41090-eca2-41bc-b161-99c5dabfec61.png) After: ![image](https://user-images.githubusercontent.com/783247/140385748-20cf26b5-ea96-4e56-8af2-5fe1ab16fd3b.png) r? `````@estebank`````,HEART,2021-11-05T09:06:25Z,gibfahn,gibfahn@gmail.com https://github.com/rust-lang/rust/pull/90575,MERGED,2021-11-04T17:01:49Z,2021-11-20T13:31:26Z,Improve suggestions for compatible variants on type mismatch.,m-ou-se,7354bb331e6a88e63c89a3d92c47dcc5afc274f8,15,Rollup merge of #90575 - m-ou-se:compatible-variant-improvements r=estebank Improve suggestions for compatible variants on type mismatch. Fixes #90553. Before: ![image](https://user-images.githubusercontent.com/783247/140385675-6ff41090-eca2-41bc-b161-99c5dabfec61.png) After: ![image](https://user-images.githubusercontent.com/783247/140385748-20cf26b5-ea96-4e56-8af2-5fe1ab16fd3b.png) r? `````@estebank`````,HEART,2021-11-06T22:19:35Z,camelid,NA https://github.com/rust-lang/rust/pull/90586,MERGED,2021-11-04T20:44:14Z,2021-12-28T01:04:39Z,Relax priv-in-pub lint on generic bounds and where clauses of trait impls.,jswrenn,b57a6b38c5b3ac932cf5bc70558fc2b4d0792e91,9,Rollup merge of #90586 - jswrenn:relax-privacy-lints r=petrochenkov Relax priv-in-pub lint on generic bounds and where clauses of trait impls. The priv-in-pub lint is a legacy mechanism of the compiler supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls. ## Current Behavior On public trait impls it's currently an **error** to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // ERROR {} ``` ...and it's a **warning** to have have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} ``` This lint applies to `where` clauses in other contexts too; e.g. on free functions: ```rust struct Priv(T); pub trait Pub {} impl Pub for Priv {} pub fn function() where Priv: Pub // WARNING {} ``` **These constraints could be relaxed without issue.** ## New Behavior This lint is relaxed for `where` clauses on trait impls such that it's okay to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // OK {} ``` ...and it's okay to have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // OK {} ``` ## Rationale While the priv-in-pub lint is not essential for soundness it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context: ```rust fn callsite() where Priv: Pub // ERROR: omitting this bound is a compile error but including it is too { function::() } ``` ...it cannot do so without repeating `function`'s `where` bound which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful. However this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds you don't need to forward those private bounds you can forward the public trait: ```rust mod upstream { pub trait Trait { fn method(&self) {} } pub struct Type(T); pub struct Pub(T); trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} } mod downstream { use super::upstream::*; fn function(value: Type) where Type: Trait // <- no private deets! { value.method(); } } ``` **This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts including trait definitions inherent impls and function definitions. It doesn't need to exist in those cases either but I figured I'd first target a case where it's mostly pointless. ## Other Notes - See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397). - This PR effectively reverts #79291.,THUMBS_UP,2022-02-23T07:37:52Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/90586,MERGED,2021-11-04T20:44:14Z,2021-12-28T01:04:39Z,Relax priv-in-pub lint on generic bounds and where clauses of trait impls.,jswrenn,b57a6b38c5b3ac932cf5bc70558fc2b4d0792e91,9,Rollup merge of #90586 - jswrenn:relax-privacy-lints r=petrochenkov Relax priv-in-pub lint on generic bounds and where clauses of trait impls. The priv-in-pub lint is a legacy mechanism of the compiler supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls. ## Current Behavior On public trait impls it's currently an **error** to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // ERROR {} ``` ...and it's a **warning** to have have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} ``` This lint applies to `where` clauses in other contexts too; e.g. on free functions: ```rust struct Priv(T); pub trait Pub {} impl Pub for Priv {} pub fn function() where Priv: Pub // WARNING {} ``` **These constraints could be relaxed without issue.** ## New Behavior This lint is relaxed for `where` clauses on trait impls such that it's okay to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // OK {} ``` ...and it's okay to have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // OK {} ``` ## Rationale While the priv-in-pub lint is not essential for soundness it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context: ```rust fn callsite() where Priv: Pub // ERROR: omitting this bound is a compile error but including it is too { function::() } ``` ...it cannot do so without repeating `function`'s `where` bound which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful. However this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds you don't need to forward those private bounds you can forward the public trait: ```rust mod upstream { pub trait Trait { fn method(&self) {} } pub struct Type(T); pub struct Pub(T); trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} } mod downstream { use super::upstream::*; fn function(value: Type) where Type: Trait // <- no private deets! { value.method(); } } ``` **This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts including trait definitions inherent impls and function definitions. It doesn't need to exist in those cases either but I figured I'd first target a case where it's mostly pointless. ## Other Notes - See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397). - This PR effectively reverts #79291.,THUMBS_UP,2022-03-11T07:27:38Z,worstpractice,NA https://github.com/rust-lang/rust/pull/90586,MERGED,2021-11-04T20:44:14Z,2021-12-28T01:04:39Z,Relax priv-in-pub lint on generic bounds and where clauses of trait impls.,jswrenn,b57a6b38c5b3ac932cf5bc70558fc2b4d0792e91,9,Rollup merge of #90586 - jswrenn:relax-privacy-lints r=petrochenkov Relax priv-in-pub lint on generic bounds and where clauses of trait impls. The priv-in-pub lint is a legacy mechanism of the compiler supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls. ## Current Behavior On public trait impls it's currently an **error** to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // ERROR {} ``` ...and it's a **warning** to have have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} ``` This lint applies to `where` clauses in other contexts too; e.g. on free functions: ```rust struct Priv(T); pub trait Pub {} impl Pub for Priv {} pub fn function() where Priv: Pub // WARNING {} ``` **These constraints could be relaxed without issue.** ## New Behavior This lint is relaxed for `where` clauses on trait impls such that it's okay to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // OK {} ``` ...and it's okay to have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // OK {} ``` ## Rationale While the priv-in-pub lint is not essential for soundness it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context: ```rust fn callsite() where Priv: Pub // ERROR: omitting this bound is a compile error but including it is too { function::() } ``` ...it cannot do so without repeating `function`'s `where` bound which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful. However this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds you don't need to forward those private bounds you can forward the public trait: ```rust mod upstream { pub trait Trait { fn method(&self) {} } pub struct Type(T); pub struct Pub(T); trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} } mod downstream { use super::upstream::*; fn function(value: Type) where Type: Trait // <- no private deets! { value.method(); } } ``` **This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts including trait definitions inherent impls and function definitions. It doesn't need to exist in those cases either but I figured I'd first target a case where it's mostly pointless. ## Other Notes - See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397). - This PR effectively reverts #79291.,THUMBS_UP,2022-04-11T09:37:56Z,matthiasbeyer,mail@beyermatthias.de https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-05T08:56:34Z,hkratz,NA https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-05T16:34:45Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-05T22:20:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-11T22:34:32Z,ljedrz,NA https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-18T04:18:43Z,weihanglo,NA https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-18T05:05:53Z,lukechu10,NA https://github.com/rust-lang/rust/pull/90596,MERGED,2021-11-05T00:23:11Z,2021-11-14T18:21:19Z,Optimize Eq and Hash for Path/PathBuf,the8472,c8e94975a6541e947a1bd4971e084c8ba637f2b6,3,Auto merge of #90596 - the8472:path-hash-opt r=Mark-Simulacrum Optimize Eq and Hash for Path/PathBuf ``` # new test path::tests::bench_hash_path_long ... bench: 86 ns/iter (+/- 1) test path::tests::bench_hash_path_short ... bench: 13 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 197 ns/iter (+/- 6) test path::tests::bench_path_hashset_miss ... bench: 94 ns/iter (+/- 4) # old test path::tests::bench_hash_path_long ... bench: 192 ns/iter (+/- 2) test path::tests::bench_hash_path_short ... bench: 33 ns/iter (+/- 1) test path::tests::bench_path_hashset ... bench: 1 121 ns/iter (+/- 24) test path::tests::bench_path_hashset_miss ... bench: 273 ns/iter (+/- 6) ```,ROCKET,2021-11-18T22:45:59Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/90597,MERGED,2021-11-05T01:28:03Z,2021-11-06T01:12:43Z,Warn for variables that are no longer captured,nikomatsakis,4b1cb73f1d45f69e0f00a66754616c61b3166c47,13,Rollup merge of #90597 - nikomatsakis:issue-90465 r=wesleywiser Warn for variables that are no longer captured r? `@wesleywiser` cc `@rust-lang/wg-rfc-2229` Fixes #90465,HEART,2021-11-05T07:56:23Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/90607,MERGED,2021-11-05T12:51:38Z,2021-11-18T23:29:55Z,Make slice->str conversion and related functions `const`,WaffleLapkin,77c985f76564f4d47897b3488f5a609f6a89f3ec,6,Rollup merge of #90607 - WaffleLapkin:const_str_from_utf8 r=oli-obk Make slice->str conversion and related functions `const` This PR marks the following APIs as `const`: ```rust // core::str pub const fn from_utf8(v: &[u8]) -> Result<&str Utf8Error>; pub const fn from_utf8_mut(v: &mut [u8]) -> Result<&mut str Utf8Error>; pub const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str; impl Utf8Error { pub const fn valid_up_to(&self) -> usize; pub const fn error_len(&self) -> Option; } ``` Everything but `from_utf8_unchecked_mut` uses `const_str_from_utf8` feature gate `from_utf8_unchecked_mut` uses `const_str_from_utf8_unchecked_mut` feature gate. --- I'm not sure why `from_utf8_unchecked_mut` was left out being non-`const` considering that `from_utf8_unchecked` is not only `const` but **`const` stable**. --- r? ```@oli-obk``` (performance-only `const_eval_select` use),HEART,2021-11-05T17:39:44Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90617,MERGED,2021-11-05T16:02:12Z,2021-11-06T12:58:14Z,Initialize LLVM time trace profiler on each code generation thread,tmiasko,3cd3bbecc5e498465e89be8a33d2936aaebed0bf,6,Auto merge of #90617 - tmiasko:time-trace-threads r=wesleywiser Initialize LLVM time trace profiler on each code generation thread In https://reviews.llvm.org/D71059 LLVM 11 the time trace profiler was extended to support multiple threads. `timeTraceProfilerInitialize` creates a thread local profiler instance. When a thread finishes `timeTraceProfilerFinishThread` moves a thread local instance into a global collection of instances. Finally when all codegen work is complete `timeTraceProfilerWrite` writes data from the current thread local instance and the instances in global collection of instances. Previously the profiler was intialized on a single thread only. Since this thread performs no code generation on its own the resulting profile was empty. Update LLVM codegen to initialize & finish time trace profiler on each code generation thread. cc `@tmandry` r? `@wesleywiser`,HEART,2021-11-10T00:53:52Z,tmandry,NA https://github.com/rust-lang/rust/pull/90617,MERGED,2021-11-05T16:02:12Z,2021-11-06T12:58:14Z,Initialize LLVM time trace profiler on each code generation thread,tmiasko,3cd3bbecc5e498465e89be8a33d2936aaebed0bf,6,Auto merge of #90617 - tmiasko:time-trace-threads r=wesleywiser Initialize LLVM time trace profiler on each code generation thread In https://reviews.llvm.org/D71059 LLVM 11 the time trace profiler was extended to support multiple threads. `timeTraceProfilerInitialize` creates a thread local profiler instance. When a thread finishes `timeTraceProfilerFinishThread` moves a thread local instance into a global collection of instances. Finally when all codegen work is complete `timeTraceProfilerWrite` writes data from the current thread local instance and the instances in global collection of instances. Previously the profiler was intialized on a single thread only. Since this thread performs no code generation on its own the resulting profile was empty. Update LLVM codegen to initialize & finish time trace profiler on each code generation thread. cc `@tmandry` r? `@wesleywiser`,HEART,2021-11-10T01:36:40Z,scottmcm,NA https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2021-11-05T20:34:24Z,a1phyr,NA https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-02-14T12:37:29Z,Amanieu,amanieu@gmail.com https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-03-11T04:04:52Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-03-15T01:00:27Z,ocxtal,suzuki.hajime.s@gmail.com https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-03-15T10:46:41Z,weihanglo,NA https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-03-25T07:57:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90621,MERGED,2021-11-05T16:40:58Z,2022-03-15T00:32:24Z,Stabilise `aarch64_target_feature`,adamgemmell,0e423932f89baeaa59ea710caeda7a3834506fdd,10,Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature r=Amanieu Stabilise `aarch64_target_feature` This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620,HOORAY,2022-05-18T22:50:34Z,riking,NA https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2021-11-05T20:29:04Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2021-11-05T22:17:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-02-10T07:47:34Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-02-13T21:59:48Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-03-31T13:26:23Z,fmease,NA https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-04-21T09:25:53Z,Hexhu,NA https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-04-21T11:11:02Z,weihanglo,NA https://github.com/rust-lang/rust/pull/90630,MERGED,2021-11-05T19:54:59Z,2022-04-21T04:57:32Z,Create real parser for search queries,GuillaumeGomez,976c6b2d193148ca9df3a505e55c5ba5da22cd96,21,Rollup merge of #90630 - GuillaumeGomez:improve-rustdoc-search r=notriddle Create real parser for search queries You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html). This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems. So about the parser: as you can see in the screenshot it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot). Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument but is much more powerful when there are more than one. When making this change we also removed the support for multi-query. PS: A big part of the PR is tests and test-related code. :) r? `@camelid`,HEART,2022-04-23T03:09:44Z,dns2utf8,NA https://github.com/rust-lang/rust/pull/90637,MERGED,2021-11-05T21:38:21Z,2021-12-31T22:57:52Z,Store liveness in interval sets for region inference,Mark-Simulacrum,cfa3fe5af339e724209b25715282adae0c61628f,7,Auto merge of #90637 - Mark-Simulacrum:liveness-btree r=lqd Store liveness in interval sets for region inference On the 100 000 line test case from https://github.com/rust-lang/rust/issues/90445 this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results though with regular malloc) and yields a 9.4x speedup with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler as results on #90445 illustrate. There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which at some level are a less perfect fit for representing liveness which is almost always composed of contiguous ranges not point locations). Fixes #90445.,THUMBS_UP,2021-11-05T23:25:38Z,hkratz,NA https://github.com/rust-lang/rust/pull/90637,MERGED,2021-11-05T21:38:21Z,2021-12-31T22:57:52Z,Store liveness in interval sets for region inference,Mark-Simulacrum,cfa3fe5af339e724209b25715282adae0c61628f,7,Auto merge of #90637 - Mark-Simulacrum:liveness-btree r=lqd Store liveness in interval sets for region inference On the 100 000 line test case from https://github.com/rust-lang/rust/issues/90445 this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results though with regular malloc) and yields a 9.4x speedup with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler as results on #90445 illustrate. There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which at some level are a less perfect fit for representing liveness which is almost always composed of contiguous ranges not point locations). Fixes #90445.,HOORAY,2021-12-01T07:57:55Z,lqd,NA https://github.com/rust-lang/rust/pull/90637,MERGED,2021-11-05T21:38:21Z,2021-12-31T22:57:52Z,Store liveness in interval sets for region inference,Mark-Simulacrum,cfa3fe5af339e724209b25715282adae0c61628f,7,Auto merge of #90637 - Mark-Simulacrum:liveness-btree r=lqd Store liveness in interval sets for region inference On the 100 000 line test case from https://github.com/rust-lang/rust/issues/90445 this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results though with regular malloc) and yields a 9.4x speedup with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler as results on #90445 illustrate. There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which at some level are a less perfect fit for representing liveness which is almost always composed of contiguous ranges not point locations). Fixes #90445.,THUMBS_UP,2022-01-06T19:05:53Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90637,MERGED,2021-11-05T21:38:21Z,2021-12-31T22:57:52Z,Store liveness in interval sets for region inference,Mark-Simulacrum,cfa3fe5af339e724209b25715282adae0c61628f,7,Auto merge of #90637 - Mark-Simulacrum:liveness-btree r=lqd Store liveness in interval sets for region inference On the 100 000 line test case from https://github.com/rust-lang/rust/issues/90445 this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results though with regular malloc) and yields a 9.4x speedup with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler as results on #90445 illustrate. There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which at some level are a less perfect fit for representing liveness which is almost always composed of contiguous ranges not point locations). Fixes #90445.,HOORAY,2022-01-06T19:05:55Z,Virgiel,NA https://github.com/rust-lang/rust/pull/90637,MERGED,2021-11-05T21:38:21Z,2021-12-31T22:57:52Z,Store liveness in interval sets for region inference,Mark-Simulacrum,cfa3fe5af339e724209b25715282adae0c61628f,7,Auto merge of #90637 - Mark-Simulacrum:liveness-btree r=lqd Store liveness in interval sets for region inference On the 100 000 line test case from https://github.com/rust-lang/rust/issues/90445 this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results though with regular malloc) and yields a 9.4x speedup with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler as results on #90445 illustrate. There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which at some level are a less perfect fit for representing liveness which is almost always composed of contiguous ranges not point locations). Fixes #90445.,HOORAY,2022-01-07T08:07:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90639,MERGED,2021-11-05T23:13:43Z,2022-01-08T18:32:32Z,Add a query for resolving an impl item from the trait item,matthewjasper,488acf86a75c56d30b16822e953c505a9e4901a7,25,Auto merge of #90639 - matthewjasper:leaf-def-cache r=cjgillot Add a query for resolving an impl item from the trait item This makes finding the item in an impl that implements a given trait item a query. This is for a few reasons: - To slightly improve performance - To avoid having to do name resolution during monomorphisation - To make it easier to implement potential future features that create anonymous associated items,EYES,2021-11-06T00:02:10Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90644,MERGED,2021-11-06T05:05:37Z,2021-11-12T22:28:56Z,Extend the const swap feature,est31,70532c4503c91d308bf0a1b1b2e1a3e2f5635ced,2,Rollup merge of #90644 - est31:const_swap r=Mark-Simulacrum Extend the const swap feature Adds the `const_swap` feature gate to three more swap functions. cc tracking issue #83163 ```Rust impl [T] { pub const fn swap(&mut self a: usize b: usize); pub const unsafe fn swap_unchecked(&mut self a: usize b: usize); } impl *mut T { pub const unsafe fn swap(self with: *mut T); },THUMBS_UP,2021-11-06T09:41:08Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/90644,MERGED,2021-11-06T05:05:37Z,2021-11-12T22:28:56Z,Extend the const swap feature,est31,70532c4503c91d308bf0a1b1b2e1a3e2f5635ced,2,Rollup merge of #90644 - est31:const_swap r=Mark-Simulacrum Extend the const swap feature Adds the `const_swap` feature gate to three more swap functions. cc tracking issue #83163 ```Rust impl [T] { pub const fn swap(&mut self a: usize b: usize); pub const unsafe fn swap_unchecked(&mut self a: usize b: usize); } impl *mut T { pub const unsafe fn swap(self with: *mut T); },THUMBS_UP,2021-11-06T10:53:38Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90644,MERGED,2021-11-06T05:05:37Z,2021-11-12T22:28:56Z,Extend the const swap feature,est31,70532c4503c91d308bf0a1b1b2e1a3e2f5635ced,2,Rollup merge of #90644 - est31:const_swap r=Mark-Simulacrum Extend the const swap feature Adds the `const_swap` feature gate to three more swap functions. cc tracking issue #83163 ```Rust impl [T] { pub const fn swap(&mut self a: usize b: usize); pub const unsafe fn swap_unchecked(&mut self a: usize b: usize); } impl *mut T { pub const unsafe fn swap(self with: *mut T); },THUMBS_UP,2021-11-06T19:18:20Z,usbalbin,NA https://github.com/rust-lang/rust/pull/90644,MERGED,2021-11-06T05:05:37Z,2021-11-12T22:28:56Z,Extend the const swap feature,est31,70532c4503c91d308bf0a1b1b2e1a3e2f5635ced,2,Rollup merge of #90644 - est31:const_swap r=Mark-Simulacrum Extend the const swap feature Adds the `const_swap` feature gate to three more swap functions. cc tracking issue #83163 ```Rust impl [T] { pub const fn swap(&mut self a: usize b: usize); pub const unsafe fn swap_unchecked(&mut self a: usize b: usize); } impl *mut T { pub const unsafe fn swap(self with: *mut T); },THUMBS_UP,2021-11-18T04:07:55Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90645,MERGED,2021-11-06T09:35:34Z,2021-11-15T10:04:40Z,Implement diagnostic for String conversion,terrarier2111,d5a0c7cb036032288a4a5443b54ba061ec12ee26,3,Auto merge of #90645 - terrarier2111:master r=estebank Implement diagnostic for String conversion This is my first real contribution to rustc any feedback is highly appreciated. This should fix https://github.com/rust-lang/rust/issues/89856 Thanks to `@estebank` for guiding me.,THUMBS_UP,2021-11-06T09:36:27Z,Milo123459,NA https://github.com/rust-lang/rust/pull/90645,MERGED,2021-11-06T09:35:34Z,2021-11-15T10:04:40Z,Implement diagnostic for String conversion,terrarier2111,d5a0c7cb036032288a4a5443b54ba061ec12ee26,3,Auto merge of #90645 - terrarier2111:master r=estebank Implement diagnostic for String conversion This is my first real contribution to rustc any feedback is highly appreciated. This should fix https://github.com/rust-lang/rust/issues/89856 Thanks to `@estebank` for guiding me.,HEART,2021-11-06T21:56:50Z,estebank,NA https://github.com/rust-lang/rust/pull/90645,MERGED,2021-11-06T09:35:34Z,2021-11-15T10:04:40Z,Implement diagnostic for String conversion,terrarier2111,d5a0c7cb036032288a4a5443b54ba061ec12ee26,3,Auto merge of #90645 - terrarier2111:master r=estebank Implement diagnostic for String conversion This is my first real contribution to rustc any feedback is highly appreciated. This should fix https://github.com/rust-lang/rust/issues/89856 Thanks to `@estebank` for guiding me.,HEART,2021-11-07T11:44:31Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90645,MERGED,2021-11-06T09:35:34Z,2021-11-15T10:04:40Z,Implement diagnostic for String conversion,terrarier2111,d5a0c7cb036032288a4a5443b54ba061ec12ee26,3,Auto merge of #90645 - terrarier2111:master r=estebank Implement diagnostic for String conversion This is my first real contribution to rustc any feedback is highly appreciated. This should fix https://github.com/rust-lang/rust/issues/89856 Thanks to `@estebank` for guiding me.,HEART,2021-11-18T04:00:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90645,MERGED,2021-11-06T09:35:34Z,2021-11-15T10:04:40Z,Implement diagnostic for String conversion,terrarier2111,d5a0c7cb036032288a4a5443b54ba061ec12ee26,3,Auto merge of #90645 - terrarier2111:master r=estebank Implement diagnostic for String conversion This is my first real contribution to rustc any feedback is highly appreciated. This should fix https://github.com/rust-lang/rust/issues/89856 Thanks to `@estebank` for guiding me.,THUMBS_UP,2021-11-18T04:00:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/90646,MERGED,2021-11-06T10:59:17Z,2021-11-07T01:43:19Z,type error go brrrrrrrr,BoxyUwU,43fee0e0a9ffae276d5b0e92e3243a6eccaadcd7,4,Rollup merge of #90646 - BoxyUwU:funky_ice r=estebank type error go brrrrrrrr Fixes #90444 when we relate something like: `fn(fn(() () u32))` with `fn(fn(() () ()))` we relate the inner fn ptrs: `fn(() () u32)` with `fn(() () ())` yielding a `TypeError::ArgumentSorts(_ 2)` which we then use as the `TypeError` for the `fn(fn(..))` which later causes the ICE as the `2` does not correspond to any input or output types in `fn(_)` r? `@estebank`,LAUGH,2021-11-06T17:51:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90646,MERGED,2021-11-06T10:59:17Z,2021-11-07T01:43:19Z,type error go brrrrrrrr,BoxyUwU,43fee0e0a9ffae276d5b0e92e3243a6eccaadcd7,4,Rollup merge of #90646 - BoxyUwU:funky_ice r=estebank type error go brrrrrrrr Fixes #90444 when we relate something like: `fn(fn(() () u32))` with `fn(fn(() () ()))` we relate the inner fn ptrs: `fn(() () u32)` with `fn(() () ())` yielding a `TypeError::ArgumentSorts(_ 2)` which we then use as the `TypeError` for the `fn(fn(..))` which later causes the ICE as the `2` does not correspond to any input or output types in `fn(_)` r? `@estebank`,LAUGH,2021-11-23T06:45:56Z,izik1,NA https://github.com/rust-lang/rust/pull/90650,CLOSED,2021-11-06T15:42:42Z,2022-02-19T20:07:30Z,Document mpsc Sender/Receiver are only Send if T is Send,SebastiaanYN,NA,NA,NA,THUMBS_UP,2021-11-06T18:16:22Z,DarkSeraphim,mark.hendriks@castawaylabs.com https://github.com/rust-lang/rust/pull/90657,MERGED,2021-11-06T18:57:49Z,2021-11-09T04:25:22Z,Fix bug with `#[doc]` string single-character last lines,GuillaumeGomez,d9fc7d10414a3b5fb172482911fc39ba2dd6bb37,3,Rollup merge of #90657 - GuillaumeGomez:one-char-last-line-removed r=jyn514 Fix bug with `#[doc]` string single-character last lines Fixes #90618. This is because `.iter().all(|c| c == '*')` returns `true` if there is no character checked. And in case the last line has only one character it simply returns `true` making the last line behind removed.,HOORAY,2021-12-17T16:47:31Z,mlodato517,NA https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2021-11-09T15:48:50Z,chris-laplante,NA https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2021-11-27T12:17:45Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2021-12-02T15:46:38Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2021-12-28T05:39:54Z,hjiayz,NA https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2022-01-16T20:37:06Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/90666,MERGED,2021-11-07T09:01:03Z,2022-01-23T12:29:13Z,Stabilize arc_new_cyclic,bdbai,59d9ad98b66afdfa2d9e636743dfd323321e5f49,2,Rollup merge of #90666 - bdbai:arc_new_cyclic r=m-ou-se Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api,THUMBS_UP,2022-01-26T10:16:07Z,pickfire,pickfire@riseup.net https://github.com/rust-lang/rust/pull/90677,MERGED,2021-11-07T22:57:57Z,2022-01-28T12:46:20Z,Suggest tuple-parentheses for enum variants,bobrippling,e0e70c0c2c4fc8d150a56c181994e3a3b3e9999a,6,Auto merge of #90677 - bobrippling:suggest-tuple-parens r=camelid Suggest tuple-parentheses for enum variants This follows on from #86493 / #86481 making the parentheses suggestion. To summarise given the following code: ```rust fn f() -> Option<(i32 i8)> { Some(1 2) } ``` The current output is: ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | | | expected 1 argument error: aborting due to previous error For more information about this error try `rustc --explain E0061`. ``` With this change `rustc` will now suggest parentheses when: - The callee is expecting a single tuple argument - The number of arguments passed matches the element count in the above tuple - The arguments' types match the tuple's fields ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | help: use parentheses to construct a tuple | 2 | Some((1 2)) | + + ```,HEART,2021-11-08T03:22:12Z,camelid,NA https://github.com/rust-lang/rust/pull/90677,MERGED,2021-11-07T22:57:57Z,2022-01-28T12:46:20Z,Suggest tuple-parentheses for enum variants,bobrippling,e0e70c0c2c4fc8d150a56c181994e3a3b3e9999a,6,Auto merge of #90677 - bobrippling:suggest-tuple-parens r=camelid Suggest tuple-parentheses for enum variants This follows on from #86493 / #86481 making the parentheses suggestion. To summarise given the following code: ```rust fn f() -> Option<(i32 i8)> { Some(1 2) } ``` The current output is: ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | | | expected 1 argument error: aborting due to previous error For more information about this error try `rustc --explain E0061`. ``` With this change `rustc` will now suggest parentheses when: - The callee is expecting a single tuple argument - The number of arguments passed matches the element count in the above tuple - The arguments' types match the tuple's fields ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | help: use parentheses to construct a tuple | 2 | Some((1 2)) | + + ```,HEART,2021-11-10T17:21:49Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/90677,MERGED,2021-11-07T22:57:57Z,2022-01-28T12:46:20Z,Suggest tuple-parentheses for enum variants,bobrippling,e0e70c0c2c4fc8d150a56c181994e3a3b3e9999a,6,Auto merge of #90677 - bobrippling:suggest-tuple-parens r=camelid Suggest tuple-parentheses for enum variants This follows on from #86493 / #86481 making the parentheses suggestion. To summarise given the following code: ```rust fn f() -> Option<(i32 i8)> { Some(1 2) } ``` The current output is: ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | | | expected 1 argument error: aborting due to previous error For more information about this error try `rustc --explain E0061`. ``` With this change `rustc` will now suggest parentheses when: - The callee is expecting a single tuple argument - The number of arguments passed matches the element count in the above tuple - The arguments' types match the tuple's fields ``` error[E0061]: this enum variant takes 1 argument but 2 arguments were supplied --> b.rs:2:5 | 2 | Some(1 2) | ^^^^ - - supplied 2 arguments | help: use parentheses to construct a tuple | 2 | Some((1 2)) | + + ```,HEART,2022-02-03T13:31:31Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/90687,MERGED,2021-11-08T06:20:17Z,2021-11-17T20:19:11Z,Permit const panics in stable const contexts in stdlib,jhpratt,ec84633b542a7c14e380c8fb77f20a84b12cb2fe,5,"Rollup merge of #90687 - jhpratt:const_panic r=oli-obk Permit const panics in stable const contexts in stdlib Without this change it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code. For example this snippet currently fails to compile: ```rust #[stable(feature = ""foo"" since = ""1.0.0"")] #[rustc_const_stable(feature = ""foo"" since = ""1.0.0"")] const fn foo() { assert!(false); assert!(false ""foo""); } ``` With the addition of `#[rustc_const_unstable]` to `core::panicking::panic` the error no longer occurs. This snippet has been added verbatim in this PR as a UI test. To avoid needing to add `#![feature(core_panic)]` to libcore the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro. I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)",HEART,2021-11-08T11:05:37Z,est31,NA https://github.com/rust-lang/rust/pull/90687,MERGED,2021-11-08T06:20:17Z,2021-11-17T20:19:11Z,Permit const panics in stable const contexts in stdlib,jhpratt,ec84633b542a7c14e380c8fb77f20a84b12cb2fe,5,"Rollup merge of #90687 - jhpratt:const_panic r=oli-obk Permit const panics in stable const contexts in stdlib Without this change it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code. For example this snippet currently fails to compile: ```rust #[stable(feature = ""foo"" since = ""1.0.0"")] #[rustc_const_stable(feature = ""foo"" since = ""1.0.0"")] const fn foo() { assert!(false); assert!(false ""foo""); } ``` With the addition of `#[rustc_const_unstable]` to `core::panicking::panic` the error no longer occurs. This snippet has been added verbatim in this PR as a UI test. To avoid needing to add `#![feature(core_panic)]` to libcore the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro. I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)",HEART,2021-11-08T11:41:23Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90687,MERGED,2021-11-08T06:20:17Z,2021-11-17T20:19:11Z,Permit const panics in stable const contexts in stdlib,jhpratt,ec84633b542a7c14e380c8fb77f20a84b12cb2fe,5,"Rollup merge of #90687 - jhpratt:const_panic r=oli-obk Permit const panics in stable const contexts in stdlib Without this change it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code. For example this snippet currently fails to compile: ```rust #[stable(feature = ""foo"" since = ""1.0.0"")] #[rustc_const_stable(feature = ""foo"" since = ""1.0.0"")] const fn foo() { assert!(false); assert!(false ""foo""); } ``` With the addition of `#[rustc_const_unstable]` to `core::panicking::panic` the error no longer occurs. This snippet has been added verbatim in this PR as a UI test. To avoid needing to add `#![feature(core_panic)]` to libcore the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro. I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)",HEART,2021-11-17T14:24:48Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/90701,MERGED,2021-11-08T16:18:59Z,2021-11-09T23:16:04Z,Record more artifact sizes during self-profiling.,michaelwoerister,fd5a4f42ad425a19c022fcafe482341e2612f29e,4,"Rollup merge of #90701 - michaelwoerister:more-artifact-sizes r=davidtwco Record more artifact sizes during self-profiling. This PR adds artifact size recording for - ""linked artifacts"" (executables RLIBs dylibs static libs) - object files - dwo files - assembly files - crate metadata - LLVM bitcode files - LLVM IR files - codegen unit size estimates Currently the identifiers emitted for these are hard-coded as string literals. Is it worth adding constants to https://github.com/rust-lang/measureme/blob/master/measureme/src/rustc.rs instead? We don't do that for query names and the like -- but artifact kinds might be more stable than query names.",HEART,2021-11-09T17:01:56Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90701,MERGED,2021-11-08T16:18:59Z,2021-11-09T23:16:04Z,Record more artifact sizes during self-profiling.,michaelwoerister,fd5a4f42ad425a19c022fcafe482341e2612f29e,4,"Rollup merge of #90701 - michaelwoerister:more-artifact-sizes r=davidtwco Record more artifact sizes during self-profiling. This PR adds artifact size recording for - ""linked artifacts"" (executables RLIBs dylibs static libs) - object files - dwo files - assembly files - crate metadata - LLVM bitcode files - LLVM IR files - codegen unit size estimates Currently the identifiers emitted for these are hard-coded as string literals. Is it worth adding constants to https://github.com/rust-lang/measureme/blob/master/measureme/src/rustc.rs instead? We don't do that for query names and the like -- but artifact kinds might be more stable than query names.",HOORAY,2021-11-09T17:01:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90709,MERGED,2021-11-08T19:16:15Z,2021-12-08T21:51:13Z,Only shown relevant type params in E0283 label,estebank,7970fab252f1bde4bba96142d0843747c6e9b4ad,5,Rollup merge of #90709 - estebank:erase-known-type-params r=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type erase all the type for ADTs that have been resolved leaving only the ones that could not be inferred. For small shallow types this is not a problem but for big nested types with lots of params this can otherwise cause a lot of unnecessary visual output.,HEART,2021-11-08T19:25:48Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/90709,MERGED,2021-11-08T19:16:15Z,2021-12-08T21:51:13Z,Only shown relevant type params in E0283 label,estebank,7970fab252f1bde4bba96142d0843747c6e9b4ad,5,Rollup merge of #90709 - estebank:erase-known-type-params r=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type erase all the type for ADTs that have been resolved leaving only the ones that could not be inferred. For small shallow types this is not a problem but for big nested types with lots of params this can otherwise cause a lot of unnecessary visual output.,HEART,2021-11-08T20:35:16Z,Skgland,NA https://github.com/rust-lang/rust/pull/90720,MERGED,2021-11-09T08:52:39Z,2021-11-09T17:13:53Z,Update cargo,ehuss,a0d580c12a6a4754bd5019b2e9b931401490e70c,2,Rollup merge of #90720 - ehuss:update-cargo r=ehuss Update cargo 4 commits in 94ca096afbf25f670e76e07dca754fcfe27134be..2e2a16e983f597da62bc132eb191bc3276d4b1bb 2021-10-29 14:45:06 +0000 to 2021-11-08 15:13:38 +0000 - Fix debug panic on download with redirect body. (rust-lang/cargo#10048) - no need to clone (rust-lang/cargo#10051) - Update curl. (rust-lang/cargo#10040) - Fix --scrape-examples-target-crate using package name (with dashes) instead of crate name (with underscores) (rust-lang/cargo#10037),HOORAY,2021-11-12T04:25:14Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/90721,CLOSED,2021-11-09T12:13:51Z,2021-12-06T15:31:38Z,implement aspect-oriented programming (AOP) for Rust,yijunyu,NA,NA,NA,THUMBS_UP,2021-11-12T02:33:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90723,MERGED,2021-11-09T12:43:47Z,2021-11-09T23:16:04Z,Better document `Box` and `alloc::alloc::box_free` connection,asquared31415,9c1aa12ff11257c8a149b76e21e3cccac1893350,1,Rollup merge of #90723 - asquared31415:box_docs r=jyn514 Better document `Box` and `alloc::alloc::box_free` connection The internal `alloc::alloc::box_free` function requires that its signature matches the `owned_box` struct's declaration but previously that connection was only documented on the `box_free` function. This PR makes the documentation two-way to help anyone making theoretical changes to `Box` to see the connection since changes are more likely to originate from `Box`.,THUMBS_UP,2021-11-09T15:13:40Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-11-09T22:49:30Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-11-15T16:39:42Z,estebank,NA https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-11-29T20:00:41Z,lnicola,NA https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-11-29T20:31:40Z,Type1J,NA https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-12-05T16:26:18Z,spacekookie,kookie@spacekookie.de https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-12-06T22:46:11Z,eopb,NA https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2021-12-10T08:25:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90737,MERGED,2021-11-09T21:24:50Z,2021-12-03T22:37:12Z,Reintroduce `into_future` in `.await` desugaring,eholk,532d2b14c05f9bc20b2d27cbb5f4550d28343a36,15,Auto merge of #90737 - eholk:intofuture r=tmandry Reintroduce `into_future` in `.await` desugaring This is a reintroduction of the remaining parts from https://github.com/rust-lang/rust/pull/65244 that have not been relanded yet. This isn't quite ready to merge yet. The last attempt was reverting due to performance regressions so we need to make sure this does not introduce those issues again. Issues #67644 #67982 /cc `@yoshuawuyts`,HEART,2022-01-25T10:49:42Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T01:35:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T06:43:05Z,est31,NA https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T08:16:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T08:33:33Z,iago-lito,NA https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T17:45:20Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-10T21:45:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-11T05:56:31Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2021-11-19T01:48:26Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/90746,MERGED,2021-11-10T01:24:00Z,2021-11-11T21:32:24Z,Optimize pattern matching,nnethercote,936238a92b2f9d6e7afe7dda69b4afd903f96399,1,Auto merge of #90746 - nnethercote:opt-pattern-matching r=Nadrieril Optimize pattern matching These commits speed up the `match-stress-enum` benchmark which is very artificial but the changes are simple enough that it's probably worth doing. r? `@Nadrieril`,HEART,2022-02-25T07:14:25Z,daniellockyer,hi@daniellockyer.com https://github.com/rust-lang/rust/pull/90755,MERGED,2021-11-10T05:45:06Z,2021-11-11T12:07:58Z,Specialize array cloning for Copy types,scottmcm,62efba8a050c64249dab942951bb28f710208bc8,2,"Auto merge of #90755 - scottmcm:spec-array-clone r=jackh726 Specialize array cloning for Copy types Because after PR 86041 the optimizer no longer load-merges at the LLVM IR level which might be part of the perf loss. (I'll run perf and see if this makes a difference.) Also I added a codegen test so this hopefully won't regress in future -- it passes on stable and with my change here but not on the 2021-11-09 nightly. Example on current nightly: ```rust type T = u8; const N: usize = 3; pub fn demo_clone(x: &[T; N]) -> [T; N] { x.clone() } pub fn demo_copy(x: &[T; N]) -> [T; N] { *x } ``` ```llvm-ir ; playground::demo_clone ; Function Attrs: mustprogress nofree nosync nounwind nonlazybind uwtable willreturn define i24 `@_ZN10playground10demo_clone17h98a4f11453d1a753E([3` x i8]* noalias nocapture readonly align 1 dereferenceable(3) %x) unnamed_addr #0 personality i32 (i32 i32 i64 %""unwind::libunwind::_Unwind_Exception""* %""unwind::libunwind::_Unwind_Context""*)* `@rust_eh_personality` { start: %0 = getelementptr [3 x i8] [3 x i8]* %x i64 0 i64 0 %1 = getelementptr inbounds [3 x i8] [3 x i8]* %x i64 0 i64 1 %.val.i.i.i.i.i.i.i.i.i = load i8 i8* %0 align 1 !alias.scope !2 !noalias !9 %2 = getelementptr inbounds [3 x i8] [3 x i8]* %x i64 0 i64 2 %.val.i.i.i.i.i.1.i.i.i.i = load i8 i8* %1 align 1 !alias.scope !2 !noalias !20 %.val.i.i.i.i.i.2.i.i.i.i = load i8 i8* %2 align 1 !alias.scope !2 !noalias !23 %array.sroa.6.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.2.i.i.i.i to i32 %array.sroa.6.0.insert.shift.i.i.i.i = shl nuw nsw i32 %array.sroa.6.0.insert.ext.i.i.i.i 16 %array.sroa.5.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.1.i.i.i.i to i32 %array.sroa.5.0.insert.shift.i.i.i.i = shl nuw nsw i32 %array.sroa.5.0.insert.ext.i.i.i.i 8 %array.sroa.0.0.insert.ext.i.i.i.i = zext i8 %.val.i.i.i.i.i.i.i.i.i to i32 %array.sroa.5.0.insert.insert.i.i.i.i = or i32 %array.sroa.5.0.insert.shift.i.i.i.i %array.sroa.0.0.insert.ext.i.i.i.i %array.sroa.0.0.insert.insert.i.i.i.i = or i32 %array.sroa.5.0.insert.insert.i.i.i.i %array.sroa.6.0.insert.shift.i.i.i.i %.sroa.4.0.extract.trunc.i.i.i.i = trunc i32 %array.sroa.0.0.insert.insert.i.i.i.i to i24 ret i24 %.sroa.4.0.extract.trunc.i.i.i.i } ; playground::demo_copy ; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind readonly uwtable willreturn define i24 `@_ZN10playground9demo_copy17h7817453f9291d746E([3` x i8]* noalias nocapture readonly align 1 dereferenceable(3) %x) unnamed_addr #1 { start: %.sroa.0.0..sroa_cast = bitcast [3 x i8]* %x to i24* %.sroa.0.0.copyload = load i24 i24* %.sroa.0.0..sroa_cast align 1 ret i24 %.sroa.0.0.copyload } ```",THUMBS_UP,2021-11-14T15:01:26Z,bluss,NA https://github.com/rust-lang/rust/pull/90761,MERGED,2021-11-10T11:36:33Z,2021-11-12T22:28:55Z,Shorten Span of unused macro lints,hellow554,640f365bff2101a69dfee8f0f3be3ca5706dd343,7,Rollup merge of #90761 - hellow554:macro_span r=estebank Shorten Span of unused macro lints The span has been reduced to the actual ident of the macro instead of linting the *whole* macro. Closes #90745 r? ``@estebank``,THUMBS_UP,2021-11-10T12:00:15Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/90761,MERGED,2021-11-10T11:36:33Z,2021-11-12T22:28:55Z,Shorten Span of unused macro lints,hellow554,640f365bff2101a69dfee8f0f3be3ca5706dd343,7,Rollup merge of #90761 - hellow554:macro_span r=estebank Shorten Span of unused macro lints The span has been reduced to the actual ident of the macro instead of linting the *whole* macro. Closes #90745 r? ``@estebank``,THUMBS_UP,2021-11-10T14:20:43Z,est31,NA https://github.com/rust-lang/rust/pull/90761,MERGED,2021-11-10T11:36:33Z,2021-11-12T22:28:55Z,Shorten Span of unused macro lints,hellow554,640f365bff2101a69dfee8f0f3be3ca5706dd343,7,Rollup merge of #90761 - hellow554:macro_span r=estebank Shorten Span of unused macro lints The span has been reduced to the actual ident of the macro instead of linting the *whole* macro. Closes #90745 r? ``@estebank``,THUMBS_UP,2021-11-10T23:54:07Z,estebank,NA https://github.com/rust-lang/rust/pull/90772,MERGED,2021-11-10T18:29:00Z,2021-11-17T20:19:11Z,Add Vec::retain_mut,GuillaumeGomez,904dba506640f290c182f5f6e717a82c6e5b8dae,1,Rollup merge of #90772 - GuillaumeGomez:vec-retain-mut r=joshtriplett Add Vec::retain_mut This is to continue the discussion started in #83218. Original comment was: > Take 2 of #34265 since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut` etc. When looking for mutable `retain` I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter` just for the discoverability I think it's worth it. cc ``````@m-ou-se`````` ``````@jonas-schievink`````` ``````@Mark-Simulacrum``````,HOORAY,2021-11-16T15:55:36Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/90772,MERGED,2021-11-10T18:29:00Z,2021-11-17T20:19:11Z,Add Vec::retain_mut,GuillaumeGomez,904dba506640f290c182f5f6e717a82c6e5b8dae,1,Rollup merge of #90772 - GuillaumeGomez:vec-retain-mut r=joshtriplett Add Vec::retain_mut This is to continue the discussion started in #83218. Original comment was: > Take 2 of #34265 since I needed this today. The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut` etc. When looking for mutable `retain` I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter` just for the discoverability I think it's worth it. cc ``````@m-ou-se`````` ``````@jonas-schievink`````` ``````@Mark-Simulacrum``````,HOORAY,2021-11-25T02:45:32Z,upsuper,github@upsuper.org https://github.com/rust-lang/rust/pull/90774,MERGED,2021-11-10T18:58:41Z,2021-11-19T03:00:53Z,std: Tweak expansion of thread-local const,alexcrichton,548c1088eff51fd92ad94d56b8c5b2d48b7088f0,1,Auto merge of #90774 - alexcrichton:tweak-const r=m-ou-se std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298,THUMBS_UP,2021-11-10T21:56:15Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/90777,CLOSED,2021-11-10T19:32:21Z,2021-11-11T00:59:52Z,doc: use U+2212 for minus sign in integer MIN/MAX text,tspiteri,NA,NA,NA,CONFUSED,2021-11-10T19:47:01Z,r00ster91,NA https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2021-11-11T01:00:51Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2021-11-15T02:02:49Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2021-11-16T15:12:04Z,hkratz,NA https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2021-11-23T19:19:45Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2021-12-15T22:45:08Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/90782,MERGED,2021-11-10T20:39:12Z,2022-01-19T02:33:23Z,Implement raw-dylib support for windows-gnu,ricobbe,dd621a4c5cd967815cdf5ffcbe598a6fd9a3b839,24,"Rollup merge of #90782 - ricobbe:binutils-dlltool r=michaelwoerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = ""raw-dylib"")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.",HOORAY,2022-01-05T12:46:50Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/90789,CLOSED,2021-11-11T02:22:02Z,2021-11-11T18:22:28Z,[WIP] Try out alternate CGU merging strategy,Mark-Simulacrum,NA,NA,NA,EYES,2021-11-11T13:42:59Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90803,MERGED,2021-11-11T17:00:43Z,2021-11-16T11:28:44Z,Suggest `&str.chars()` on attempt to `&str.iter()`,TaKO8Ki,b17de50a4182c1e5df1abec5374a09d28dcb387a,3,Rollup merge of #90803 - TaKO8Ki:suggest-chars-on-attempt-to-iter r=estebank Suggest `&str.chars()` on attempt to `&str.iter()` closes #90786,THUMBS_UP,2021-11-12T06:57:08Z,danielg1111,NA https://github.com/rust-lang/rust/pull/90803,MERGED,2021-11-11T17:00:43Z,2021-11-16T11:28:44Z,Suggest `&str.chars()` on attempt to `&str.iter()`,TaKO8Ki,b17de50a4182c1e5df1abec5374a09d28dcb387a,3,Rollup merge of #90803 - TaKO8Ki:suggest-chars-on-attempt-to-iter r=estebank Suggest `&str.chars()` on attempt to `&str.iter()` closes #90786,THUMBS_UP,2021-11-13T01:51:16Z,estebank,NA https://github.com/rust-lang/rust/pull/90803,MERGED,2021-11-11T17:00:43Z,2021-11-16T11:28:44Z,Suggest `&str.chars()` on attempt to `&str.iter()`,TaKO8Ki,b17de50a4182c1e5df1abec5374a09d28dcb387a,3,Rollup merge of #90803 - TaKO8Ki:suggest-chars-on-attempt-to-iter r=estebank Suggest `&str.chars()` on attempt to `&str.iter()` closes #90786,THUMBS_UP,2021-11-26T17:47:14Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T04:58:19Z,est31,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-12T06:01:28Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T07:33:36Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T08:38:06Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T14:01:35Z,bjorn3,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T14:23:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-12T14:23:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-12T14:23:27Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T16:56:59Z,mati865,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-12T16:57:00Z,mati865,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-12T16:57:02Z,mati865,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-12T19:24:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-12T19:24:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-12T19:24:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-13T00:46:05Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-13T01:52:13Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-13T01:52:15Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-14T15:25:39Z,bluss,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HEART,2021-11-14T15:33:06Z,taiki-e,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-14T15:35:50Z,Agrailag,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",ROCKET,2021-11-14T15:35:51Z,Agrailag,NA https://github.com/rust-lang/rust/pull/90821,MERGED,2021-11-12T04:41:13Z,2021-11-15T23:23:49Z,MIRI says `reverse` is UB so replace it with something LLVM can vectorize,scottmcm,891ca5f63c3b3cfe3939710a728671243e881ed6,2,"Auto merge of #90821 - scottmcm:new-slice-reverse r=Mark-Simulacrum MIRI says `reverse` is UB so replace it with something LLVM can vectorize For small types with padding the current implementation is UB because it does integer operations on uninit values. ``` error: Undefined Behavior: using uninitialized data but this operation requires initialized memory --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5 | 836 | / uint_impl! { u32 u32 i32 32 4294967295 8 ""0x10000b3"" ""0xb301"" ""0x12345678"" 837 | | ""0x78563412"" ""0x1e6a2c48"" ""[0x78 0x56 0x34 0x12]"" ""[0x12 0x34 0x56 0x78]"" """" """" } | |________________________________________________________________________________________________^ using uninitialized data but this operation requires initialized memory | = help: this indicates a bug in the program: it performed an invalid operation and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: inside `core::num::::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13 = note: inside `core::slice::::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58 ``` But LLVM has gotten smarter since I wrote the previous implementation in 2017 so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe` and is actually faster to boot! If you're curious to see the codegen: Before: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 940 ns/iter (+/- 481) = 58448 MB/s test slice::reverse_u128 ... bench: 17 758 ns/iter (+/- 205) = 59048 MB/s test slice::reverse_u16 ... bench: 158 234 ns/iter (+/- 6 876) = 6626 MB/s test slice::reverse_u32 ... bench: 62 047 ns/iter (+/- 1 117) = 16899 MB/s test slice::reverse_u64 ... bench: 31 582 ns/iter (+/- 552) = 33201 MB/s test slice::reverse_u8 ... bench: 81 253 ns/iter (+/- 1 510) = 12905 MB/s test slice::reverse_u8x3 ... bench: 270 615 ns/iter (+/- 11 463) = 3874 MB/s ``` After: ``` running 7 tests test slice::reverse_simd_f64x4 ... bench: 17 731 ns/iter (+/- 306) = 59137 MB/s test slice::reverse_u128 ... bench: 17 919 ns/iter (+/- 239) = 58517 MB/s test slice::reverse_u16 ... bench: 43 160 ns/iter (+/- 607) = 24295 MB/s test slice::reverse_u32 ... bench: 21 065 ns/iter (+/- 371) = 49778 MB/s test slice::reverse_u64 ... bench: 21 118 ns/iter (+/- 482) = 49653 MB/s test slice::reverse_u8 ... bench: 76 878 ns/iter (+/- 1 688) = 13639 MB/s test slice::reverse_u8x3 ... bench: 264 723 ns/iter (+/- 5 544) = 3961 MB/s ``` Those are the existing benches ",HOORAY,2021-11-27T04:08:55Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/90834,MERGED,2021-11-12T17:27:03Z,2021-11-16T05:19:04Z,Android is not GNU,cuviper,ed7ed5fc9019f7968502d01270a82a9fa3685ee4,1,"Rollup merge of #90834 - cuviper:android-gnu r=petrochenkov Android is not GNU For a long time the Android targets had `target_env=""""` but this changed to `""gnu""` in Rust 1.49.0. I tracked this down to #77729 which started setting `""gnu""` in the `linux_base` target options and this was inherited by `android_base`. Then #78929 split the env into `linux_gnu_base` but `android_base` was also changed to follow that. Android was not specifically mentioned in either pull request so I believe this was an accident. Moving it back to `linux_base` will use an empty `env` again. r? ````@Mark-Simulacrum```` cc ````@petrochenkov````",THUMBS_UP,2021-11-13T02:46:11Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/90834,MERGED,2021-11-12T17:27:03Z,2021-11-16T05:19:04Z,Android is not GNU,cuviper,ed7ed5fc9019f7968502d01270a82a9fa3685ee4,1,"Rollup merge of #90834 - cuviper:android-gnu r=petrochenkov Android is not GNU For a long time the Android targets had `target_env=""""` but this changed to `""gnu""` in Rust 1.49.0. I tracked this down to #77729 which started setting `""gnu""` in the `linux_base` target options and this was inherited by `android_base`. Then #78929 split the env into `linux_gnu_base` but `android_base` was also changed to follow that. Android was not specifically mentioned in either pull request so I believe this was an accident. Moving it back to `linux_base` will use an empty `env` again. r? ````@Mark-Simulacrum```` cc ````@petrochenkov````",THUMBS_UP,2021-11-15T23:39:23Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90835,MERGED,2021-11-12T17:32:48Z,2021-11-16T05:19:04Z,Rename WASI's `is_character_device` to `is_char_device`.,sunfishcode,96cfc9e73a6f68bde940d68dc069d84e8c8fc6ae,1,Rollup merge of #90835 - sunfishcode:sunfishcode/wasi-char-device r=alexcrichton Rename WASI's `is_character_device` to `is_char_device`. Rename WASI's `FileTypeExt::is_character_device` to `FileTypeExt::is_char_device` for consistency with the Unix `FileTypeExt::is_char_device`. Also add a `FileTypeExt::is_socket` function for consistency with the Unix `FileTypeExt::is_socket` function. r? `@alexcrichton`,THUMBS_UP,2021-11-12T18:55:41Z,Cyborus04,NA https://github.com/rust-lang/rust/pull/90835,MERGED,2021-11-12T17:32:48Z,2021-11-16T05:19:04Z,Rename WASI's `is_character_device` to `is_char_device`.,sunfishcode,96cfc9e73a6f68bde940d68dc069d84e8c8fc6ae,1,Rollup merge of #90835 - sunfishcode:sunfishcode/wasi-char-device r=alexcrichton Rename WASI's `is_character_device` to `is_char_device`. Rename WASI's `FileTypeExt::is_character_device` to `FileTypeExt::is_char_device` for consistency with the Unix `FileTypeExt::is_char_device`. Also add a `FileTypeExt::is_socket` function for consistency with the Unix `FileTypeExt::is_socket` function. r? `@alexcrichton`,THUMBS_UP,2021-11-15T23:45:28Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90846,MERGED,2021-11-12T23:27:35Z,2021-11-27T11:04:26Z,Refactor weak symbols in std::sys::unix,cuviper,0881b3abe424034b0c69b99632b64b355057f203,10,"Auto merge of #90846 - cuviper:weak r=dtolnay Refactor weak symbols in std::sys::unix This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = ""extern_weak""]` symbols so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic but old non-weak symbols can tie the build to new versions too like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does you'll still get unversioned `WEAK DEFAULT UND statx` which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64` `pread64` and `pwrite64` as these were added in API 12 and our baseline is API 14. - Linux can directly use `splice` added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.",HEART,2021-11-16T20:09:03Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/90846,MERGED,2021-11-12T23:27:35Z,2021-11-27T11:04:26Z,Refactor weak symbols in std::sys::unix,cuviper,0881b3abe424034b0c69b99632b64b355057f203,10,"Auto merge of #90846 - cuviper:weak r=dtolnay Refactor weak symbols in std::sys::unix This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = ""extern_weak""]` symbols so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic but old non-weak symbols can tie the build to new versions too like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does you'll still get unversioned `WEAK DEFAULT UND statx` which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64` `pread64` and `pwrite64` as these were added in API 12 and our baseline is API 14. - Linux can directly use `splice` added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.",HEART,2021-11-29T15:17:13Z,mati865,NA https://github.com/rust-lang/rust/pull/90846,MERGED,2021-11-12T23:27:35Z,2021-11-27T11:04:26Z,Refactor weak symbols in std::sys::unix,cuviper,0881b3abe424034b0c69b99632b64b355057f203,10,"Auto merge of #90846 - cuviper:weak r=dtolnay Refactor weak symbols in std::sys::unix This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = ""extern_weak""]` symbols so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic but old non-weak symbols can tie the build to new versions too like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does you'll still get unversioned `WEAK DEFAULT UND statx` which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64` `pread64` and `pwrite64` as these were added in API 12 and our baseline is API 14. - Linux can directly use `splice` added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.",HEART,2021-11-30T14:28:05Z,faptc,NA https://github.com/rust-lang/rust/pull/90846,MERGED,2021-11-12T23:27:35Z,2021-11-27T11:04:26Z,Refactor weak symbols in std::sys::unix,cuviper,0881b3abe424034b0c69b99632b64b355057f203,10,"Auto merge of #90846 - cuviper:weak r=dtolnay Refactor weak symbols in std::sys::unix This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = ""extern_weak""]` symbols so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic but old non-weak symbols can tie the build to new versions too like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does you'll still get unversioned `WEAK DEFAULT UND statx` which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64` `pread64` and `pwrite64` as these were added in API 12 and our baseline is API 14. - Linux can directly use `splice` added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.",HEART,2022-01-02T22:58:55Z,noproto,NA https://github.com/rust-lang/rust/pull/90848,MERGED,2021-11-13T01:05:44Z,2021-11-16T05:19:04Z,Remove bigint_helper_methods for *signed* types,scottmcm,fb96ecc37a99def7236a683b1f39369e701ed765,2,"Rollup merge of #90848 - scottmcm:remove-signed-bigint-helpers r=joshtriplett Remove bigint_helper_methods for *signed* types This PR inspired by `@cuviper's` comment @ https://github.com/rust-lang/rust/issues/90541#issuecomment-967309808 These are working well for *unsigned* types so keep those but for the the *signed* ones there are a bunch of questions about what the semantics and API should be. For the main ""helpers for big integer implementations"" use there's no need for the signed versions anyway. There are plenty of other methods which exist for unsigned types but not signed ones like `next_power_of_two` so this isn't unusual. Fixes #90541 Tracking issue #85532",THUMBS_UP,2021-11-13T09:14:42Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/90848,MERGED,2021-11-13T01:05:44Z,2021-11-16T05:19:04Z,Remove bigint_helper_methods for *signed* types,scottmcm,fb96ecc37a99def7236a683b1f39369e701ed765,2,"Rollup merge of #90848 - scottmcm:remove-signed-bigint-helpers r=joshtriplett Remove bigint_helper_methods for *signed* types This PR inspired by `@cuviper's` comment @ https://github.com/rust-lang/rust/issues/90541#issuecomment-967309808 These are working well for *unsigned* types so keep those but for the the *signed* ones there are a bunch of questions about what the semantics and API should be. For the main ""helpers for big integer implementations"" use there's no need for the signed versions anyway. There are plenty of other methods which exist for unsigned types but not signed ones like `next_power_of_two` so this isn't unusual. Fixes #90541 Tracking issue #85532",THUMBS_UP,2021-11-16T02:39:08Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/90856,MERGED,2021-11-13T07:42:39Z,2021-11-23T23:49:03Z,Suggestion to wrap inner types using 'allocator_api' in tuple,ken-matsui,68a44c8228cc482ac45e2148116ee250b18aefeb,5,Rollup merge of #90856 - ken-matsui:suggestion-to-wrap-vec-allocator-api-in-tuple r=davidtwco Suggestion to wrap inner types using 'allocator_api' in tuple This PR provides a suggestion to wrap the inner types in tuple when being along with 'allocator_api'. Closes https://github.com/rust-lang/rust/issues/83250 ```rust fn main() { let _vec: Vec = vec![]; //~ ERROR use of unstable library feature 'allocator_api' } ``` ```diff error[E0658]: use of unstable library feature 'allocator_api' --> $DIR/suggest-vec-allocator-api.rs:2:23 | LL | let _vec: Vec = vec![]; - | ^ + | ----^ + | | + | help: consider wrapping the inner types in tuple: `(u8 _)` | = note: see issue #32838 for more information = help: add `#![feature(allocator_api)]` to the crate attributes to enable ```,THUMBS_UP,2021-12-11T14:21:13Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/90868,CLOSED,2021-11-13T14:16:34Z,2022-04-11T02:37:39Z,Basic block predecessors in mir textual representation,simonvandel,NA,NA,NA,HEART,2021-11-13T22:20:02Z,scottmcm,NA https://github.com/rust-lang/rust/pull/90868,CLOSED,2021-11-13T14:16:34Z,2022-04-11T02:37:39Z,Basic block predecessors in mir textual representation,simonvandel,NA,NA,NA,HEART,2021-11-19T06:54:50Z,tmiasko,NA https://github.com/rust-lang/rust/pull/90884,MERGED,2021-11-13T23:03:34Z,2021-11-17T20:19:10Z,Fix span for non-satisfied trivial trait bounds,Nilstrieb,23ad7a7697f7e02252cf0c3f7f22641f0adb51e4,8,"Rollup merge of #90884 - Nilstrieb:fix-span-trivial-trait-bound r=estebank Fix span for non-satisfied trivial trait bounds The spans for ""trait bound not satisfied"" errors in trivial trait bounds referenced the entire item (fn impl struct) before. Now they only reference the obligation itself (`String: Copy`) Address #90869",HEART,2021-11-14T00:17:05Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/90895,MERGED,2021-11-14T03:22:31Z,2021-11-18T23:29:54Z,require full validity when determining the discriminant of a value,RalfJung,0a2b7d71d96a22126cce57f0dab5890d060f2259,2,"Rollup merge of #90895 - RalfJung:read-discriminant-valid r=oli-obk require full validity when determining the discriminant of a value This resolves (for now) the semantic question that came up in https://github.com/rust-lang/rust/pull/89764: arguably reading the discriminant of a value is 'using' that value so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just ""doing their job"". The alternative would be to just require that the discriminant itself is valid if any -- but then what do we do for types that do not have a discriminant which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types but I would rather not special case that. I don't think this can be tested in CTFE (since validity is not enforced there) I will add a compile-fail test to Miri: ```rust #[allow(enum_intrinsics_non_enums)] fn main() { let i = 2u8; std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB } ``` (I tried running the check even on the CTFE machines but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp but that simply does not seem worth the effort currently.) r? ``@oli-obk``",HEART,2021-11-15T15:02:44Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/90895,MERGED,2021-11-14T03:22:31Z,2021-11-18T23:29:54Z,require full validity when determining the discriminant of a value,RalfJung,0a2b7d71d96a22126cce57f0dab5890d060f2259,2,"Rollup merge of #90895 - RalfJung:read-discriminant-valid r=oli-obk require full validity when determining the discriminant of a value This resolves (for now) the semantic question that came up in https://github.com/rust-lang/rust/pull/89764: arguably reading the discriminant of a value is 'using' that value so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just ""doing their job"". The alternative would be to just require that the discriminant itself is valid if any -- but then what do we do for types that do not have a discriminant which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types but I would rather not special case that. I don't think this can be tested in CTFE (since validity is not enforced there) I will add a compile-fail test to Miri: ```rust #[allow(enum_intrinsics_non_enums)] fn main() { let i = 2u8; std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB } ``` (I tried running the check even on the CTFE machines but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp but that simply does not seem worth the effort currently.) r? ``@oli-obk``",HEART,2021-11-19T06:55:03Z,tmiasko,NA https://github.com/rust-lang/rust/pull/90901,MERGED,2021-11-14T13:09:07Z,2021-11-17T20:19:11Z,Improve ManuallyDrop suggestion,rukai,469faa2b667dc1d6cb6ca902a1d2c9a116fb096a,6,Rollup merge of #90901 - rukai:improve_manuallydrop_help r=estebank Improve ManuallyDrop suggestion closes https://github.com/rust-lang/rust/issues/90585 * Fixes the recommended change to use ManuallyDrop as per the issue * Changes the note to a help * improves the span so it only points at the type.,THUMBS_UP,2021-11-14T20:26:06Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/90901,MERGED,2021-11-14T13:09:07Z,2021-11-17T20:19:11Z,Improve ManuallyDrop suggestion,rukai,469faa2b667dc1d6cb6ca902a1d2c9a116fb096a,6,Rollup merge of #90901 - rukai:improve_manuallydrop_help r=estebank Improve ManuallyDrop suggestion closes https://github.com/rust-lang/rust/issues/90585 * Fixes the recommended change to use ManuallyDrop as per the issue * Changes the note to a help * improves the span so it only points at the type.,THUMBS_UP,2021-11-15T03:37:30Z,estebank,NA https://github.com/rust-lang/rust/pull/90909,MERGED,2021-11-14T17:27:17Z,2021-11-16T05:19:04Z,disable portable SIMD tests in Miri,RalfJung,35dd1f65e906b5c84260a9c6c4ccd41c7fa2517c,2,Rollup merge of #90909 - RalfJung:miri-no-portable-simd r=workingjubilee disable portable SIMD tests in Miri Until https://github.com/rust-lang/miri/issues/1912 is resolved we'll have to skip these tests in Miri.,THUMBS_UP,2021-11-15T00:00:42Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/90913,CLOSED,2021-11-14T22:52:00Z,2021-11-24T18:36:39Z,Deduplicate obligations in `opt_normalize_projection_type`,the8472,NA,NA,NA,HEART,2021-11-16T03:44:30Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90913,CLOSED,2021-11-14T22:52:00Z,2021-11-24T18:36:39Z,Deduplicate obligations in `opt_normalize_projection_type`,the8472,NA,NA,NA,HEART,2021-11-16T22:35:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/90915,CLOSED,2021-11-15T00:28:09Z,2022-03-20T05:20:06Z,add debug assertion to `unreachable_unchecked`,ibraheemdev,NA,NA,NA,THUMBS_UP,2021-11-15T11:05:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/90915,CLOSED,2021-11-15T00:28:09Z,2022-03-20T05:20:06Z,add debug assertion to `unreachable_unchecked`,ibraheemdev,NA,NA,NA,THUMBS_UP,2021-11-16T02:56:10Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/90933,MERGED,2021-11-15T23:34:41Z,2021-11-17T06:09:19Z,Fix await suggestion on non-future type,compiler-errors,eb9859f00d58d9bbed3db67952ef986e18277f01,3,Rollup merge of #90933 - compiler-errors:master r=estebank Fix await suggestion on non-future type Remove a match block that would suggest to add `.await` in the case where the expected type's `Future::Output` equals the found type. We only want to suggest `.await`ing in the opposite case (the found type's `Future::Output` equals the expected type). The code sample is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6ba6b83d4dddda263553b79dca9f6bcb Before: ``` ➜ ~ rustc --edition=2021 --crate-type=lib test.rs error[E0308]: `match` arms have incompatible types --> test.rs:4:14 | 2 | let x = match 1 { | _____________- 3 | | 1 => other() | | ------- this is found to be of type `impl Future` 4 | | 2 => other().await | | ^^^^^^^^^^^^^ expected opaque type found enum `Result` 5 | | }; | |_____- `match` arms have incompatible types | = note: expected type `impl Future` found enum `Result<() ()>` help: consider `await`ing on the `Future` | 4 | 2 => other().await.await | ++++++ error: aborting due to previous error For more information about this error try `rustc --explain E0308`. ``` After: ``` ➜ ~ rustc +stage1 --edition=2021 --crate-type=lib test.rs error[E0308]: `match` arms have incompatible types --> test.rs:4:14 | 2 | let x = match 1 { | _____________- 3 | | 1 => other() | | ------- this is found to be of type `impl Future` 4 | | 2 => other().await | | ^^^^^^^^^^^^^ expected opaque type found enum `Result` 5 | | }; | |_____- `match` arms have incompatible types | = note: expected type `impl Future` found enum `Result<() ()>` error: aborting due to previous error For more information about this error try `rustc --explain E0308`. ``` Fixes #90931,HEART,2021-11-16T05:14:54Z,estebank,NA https://github.com/rust-lang/rust/pull/90935,MERGED,2021-11-16T00:38:43Z,2021-11-17T06:09:20Z,Alphabetize language features,jhpratt,3f550078c90909f4b23d93cd9302d1691579eb07,4,Rollup merge of #90935 - jhpratt:alphabetize-features r=joshtriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? ````@joshtriplett```` ````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review,HEART,2021-11-16T00:41:11Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90935,MERGED,2021-11-16T00:38:43Z,2021-11-17T06:09:20Z,Alphabetize language features,jhpratt,3f550078c90909f4b23d93cd9302d1691579eb07,4,Rollup merge of #90935 - jhpratt:alphabetize-features r=joshtriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? ````@joshtriplett```` ````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review,HOORAY,2021-11-16T00:41:13Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/90935,MERGED,2021-11-16T00:38:43Z,2021-11-17T06:09:20Z,Alphabetize language features,jhpratt,3f550078c90909f4b23d93cd9302d1691579eb07,4,Rollup merge of #90935 - jhpratt:alphabetize-features r=joshtriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? ````@joshtriplett```` ````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review,THUMBS_UP,2021-11-16T03:50:45Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/90935,MERGED,2021-11-16T00:38:43Z,2021-11-17T06:09:20Z,Alphabetize language features,jhpratt,3f550078c90909f4b23d93cd9302d1691579eb07,4,Rollup merge of #90935 - jhpratt:alphabetize-features r=joshtriplett Alphabetize language features This should significantly reduce the frequency of merge conflicts. r? ````@joshtriplett```` ````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review,HEART,2021-11-16T22:17:23Z,VirrageS,marcinkiewicz.janusz@icloud.com https://github.com/rust-lang/rust/pull/90947,MERGED,2021-11-16T12:19:06Z,2021-11-19T09:03:00Z,Move some tests to more reasonable directories - 9.5,c410-f3r,022709f4790294bed83b71886dbb52b0c48480b2,132,Rollup merge of #90947 - c410-f3r:testsssssss r=petrochenkov Move some tests to more reasonable directories - 9.5 cc #73494 r? `@petrochenkov`,HOORAY,2021-11-16T12:44:13Z,Urgau,NA https://github.com/rust-lang/rust/pull/90947,MERGED,2021-11-16T12:19:06Z,2021-11-19T09:03:00Z,Move some tests to more reasonable directories - 9.5,c410-f3r,022709f4790294bed83b71886dbb52b0c48480b2,132,Rollup merge of #90947 - c410-f3r:testsssssss r=petrochenkov Move some tests to more reasonable directories - 9.5 cc #73494 r? `@petrochenkov`,HOORAY,2021-11-16T18:26:34Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/90954,MERGED,2021-11-16T17:21:01Z,2021-11-17T17:13:47Z,Update llvm submodule,Amanieu,faea820643f9acec1bb787941063393f9508a775,1,Auto merge of #90954 - Amanieu:fix-aarch64-asm r=nikic Update llvm submodule - [DIArgList] Re-unique after changing operands to fix non-determinism - [AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added.,HEART,2021-11-17T11:22:43Z,est31,NA https://github.com/rust-lang/rust/pull/90954,MERGED,2021-11-16T17:21:01Z,2021-11-17T17:13:47Z,Update llvm submodule,Amanieu,faea820643f9acec1bb787941063393f9508a775,1,Auto merge of #90954 - Amanieu:fix-aarch64-asm r=nikic Update llvm submodule - [DIArgList] Re-unique after changing operands to fix non-determinism - [AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added.,HEART,2021-11-17T12:28:53Z,yanok,NA https://github.com/rust-lang/rust/pull/90961,MERGED,2021-11-16T20:40:59Z,2021-11-19T09:03:00Z,Suggest removal of arguments for unit variant not replacement,estebank,c74ff8b563358435fa0da50e949159d043efc1a5,5,Rollup merge of #90961 - estebank:suggest-removal-of-call r=nagisa Suggest removal of arguments for unit variant not replacement,THUMBS_UP,2021-11-16T20:51:42Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/90978,CLOSED,2021-11-17T11:07:11Z,2021-11-17T12:26:36Z,Update LLVM submodule,yanok,NA,NA,NA,HEART,2021-11-17T11:21:40Z,est31,NA https://github.com/rust-lang/rust/pull/90999,MERGED,2021-11-18T03:47:38Z,2021-11-20T04:12:10Z,fix CTFE/Miri simd_insert/extract on array-style repr(simd) types,RalfJung,cf69f9e2206c708cb0c4535cab9e7a64c23add06,5,Rollup merge of #90999 - RalfJung:miri_simd r=oli-obk fix CTFE/Miri simd_insert/extract on array-style repr(simd) types The changed test would previously fail since `place_index` would just return the only field of `f32x4` i.e. the array -- rather than *indexing into* the array which is what we have to do. The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912. r? ``````@oli-obk``````,LAUGH,2021-11-18T05:32:15Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/90999,MERGED,2021-11-18T03:47:38Z,2021-11-20T04:12:10Z,fix CTFE/Miri simd_insert/extract on array-style repr(simd) types,RalfJung,cf69f9e2206c708cb0c4535cab9e7a64c23add06,5,Rollup merge of #90999 - RalfJung:miri_simd r=oli-obk fix CTFE/Miri simd_insert/extract on array-style repr(simd) types The changed test would previously fail since `place_index` would just return the only field of `f32x4` i.e. the array -- rather than *indexing into* the array which is what we have to do. The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912. r? ``````@oli-obk``````,LAUGH,2021-11-18T08:24:57Z,oli-obk,NA https://github.com/rust-lang/rust/pull/91000,CLOSED,2021-11-18T05:52:51Z,2021-12-02T22:30:54Z,Make ptr range iterable,dtolnay,NA,NA,NA,CONFUSED,2021-11-24T20:54:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91000,CLOSED,2021-11-18T05:52:51Z,2021-12-02T22:30:54Z,Make ptr range iterable,dtolnay,NA,NA,NA,HOORAY,2021-11-28T23:50:01Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/91003,MERGED,2021-11-18T09:41:14Z,2021-12-02T06:11:14Z,fix sparc64 ABI for aggregates with floating point members,psumbera,a2b7b7891e4623e716185f3ab62bd206fb4c5182,8,Auto merge of #91003 - psumbera:sparc64-abi r=nagisa fix sparc64 ABI for aggregates with floating point members Fixes #86163,THUMBS_UP,2021-12-02T10:12:59Z,glaubitz,NA https://github.com/rust-lang/rust/pull/91008,MERGED,2021-11-18T11:36:29Z,2021-11-21T13:26:36Z,Adds IEEE 754-2019 minimun and maximum functions for f32/f64,Urgau,789d168e132d3db976394a5d82490c4763c97626,6,"Rollup merge of #91008 - Urgau:float-minimum-maximum r=scottmcm Adds IEEE 754-2019 minimun and maximum functions for f32/f64 IEEE 754-2019 removed the `minNum` (`min` in Rust) and `maxNum` (`max` in Rust) operations in favor of the newly created `minimum` and `maximum` operations due to their [non-associativity](https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf) that cannot be fix in a backwards compatible manner. This PR adds `fN::{minimun maximum}` functions following the new rules. ### IEEE 754-2019 Rules > **minimum(x y)** is x if x < y y if y < x and a quiet NaN if either operand is a NaN according to 6.2. For this operation −0 compares less than +0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. > **maximum(x y)** is x if x > y y if y > x and a quiet NaN if either operand is a NaN according to 6.2. For this operation +0 compares greater than −0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. ""IEEE Standard for Floating-Point Arithmetic "" in IEEE Std 754-2019 (Revision of IEEE 754-2008) vol. no. pp.1-84 22 July 2019 doi: 10.1109/IEEESTD.2019.8766229. ### Implementation This implementation is inspired by the one in [`glibc` ](https://github.com/bminor/glibc/blob/90f0ac10a74b2d43b5a65aab4be40565e359be43/math/s_fminimum_template.c) (it self derived from the C2X draft) expect that: - it doesn't use `copysign` because it's not available in `core` and also because `copysign` is unnecessary (we only want to check the sign no need to create a new float) - it also prefer `other > self` instead of `self < other` like IEEE 754-2019 does I originally tried to implement them [using intrinsics](https://github.com/Urgau/rust/commit/1d8aa13bc39eeef1afba0524dc5ea10d073522e6) but LLVM [error out](https://godbolt.org/z/7sMrxW49a) when trying to lower them to machine intructions GCC doesn't yet have built-ins for them only cranelift support them nativelly (as it doesn't support the nativelly the old sementics). Helps with https://github.com/rust-lang/rust/issues/83984",THUMBS_UP,2021-11-19T20:55:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91008,MERGED,2021-11-18T11:36:29Z,2021-11-21T13:26:36Z,Adds IEEE 754-2019 minimun and maximum functions for f32/f64,Urgau,789d168e132d3db976394a5d82490c4763c97626,6,"Rollup merge of #91008 - Urgau:float-minimum-maximum r=scottmcm Adds IEEE 754-2019 minimun and maximum functions for f32/f64 IEEE 754-2019 removed the `minNum` (`min` in Rust) and `maxNum` (`max` in Rust) operations in favor of the newly created `minimum` and `maximum` operations due to their [non-associativity](https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf) that cannot be fix in a backwards compatible manner. This PR adds `fN::{minimun maximum}` functions following the new rules. ### IEEE 754-2019 Rules > **minimum(x y)** is x if x < y y if y < x and a quiet NaN if either operand is a NaN according to 6.2. For this operation −0 compares less than +0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. > **maximum(x y)** is x if x > y y if y > x and a quiet NaN if either operand is a NaN according to 6.2. For this operation +0 compares greater than −0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. ""IEEE Standard for Floating-Point Arithmetic "" in IEEE Std 754-2019 (Revision of IEEE 754-2008) vol. no. pp.1-84 22 July 2019 doi: 10.1109/IEEESTD.2019.8766229. ### Implementation This implementation is inspired by the one in [`glibc` ](https://github.com/bminor/glibc/blob/90f0ac10a74b2d43b5a65aab4be40565e359be43/math/s_fminimum_template.c) (it self derived from the C2X draft) expect that: - it doesn't use `copysign` because it's not available in `core` and also because `copysign` is unnecessary (we only want to check the sign no need to create a new float) - it also prefer `other > self` instead of `self < other` like IEEE 754-2019 does I originally tried to implement them [using intrinsics](https://github.com/Urgau/rust/commit/1d8aa13bc39eeef1afba0524dc5ea10d073522e6) but LLVM [error out](https://godbolt.org/z/7sMrxW49a) when trying to lower them to machine intructions GCC doesn't yet have built-ins for them only cranelift support them nativelly (as it doesn't support the nativelly the old sementics). Helps with https://github.com/rust-lang/rust/issues/83984",THUMBS_UP,2021-11-19T21:05:33Z,hkratz,NA https://github.com/rust-lang/rust/pull/91008,MERGED,2021-11-18T11:36:29Z,2021-11-21T13:26:36Z,Adds IEEE 754-2019 minimun and maximum functions for f32/f64,Urgau,789d168e132d3db976394a5d82490c4763c97626,6,"Rollup merge of #91008 - Urgau:float-minimum-maximum r=scottmcm Adds IEEE 754-2019 minimun and maximum functions for f32/f64 IEEE 754-2019 removed the `minNum` (`min` in Rust) and `maxNum` (`max` in Rust) operations in favor of the newly created `minimum` and `maximum` operations due to their [non-associativity](https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf) that cannot be fix in a backwards compatible manner. This PR adds `fN::{minimun maximum}` functions following the new rules. ### IEEE 754-2019 Rules > **minimum(x y)** is x if x < y y if y < x and a quiet NaN if either operand is a NaN according to 6.2. For this operation −0 compares less than +0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. > **maximum(x y)** is x if x > y y if y > x and a quiet NaN if either operand is a NaN according to 6.2. For this operation +0 compares greater than −0. Otherwise (i.e. when x = y and signs are the same) it is either x or y. ""IEEE Standard for Floating-Point Arithmetic "" in IEEE Std 754-2019 (Revision of IEEE 754-2008) vol. no. pp.1-84 22 July 2019 doi: 10.1109/IEEESTD.2019.8766229. ### Implementation This implementation is inspired by the one in [`glibc` ](https://github.com/bminor/glibc/blob/90f0ac10a74b2d43b5a65aab4be40565e359be43/math/s_fminimum_template.c) (it self derived from the C2X draft) expect that: - it doesn't use `copysign` because it's not available in `core` and also because `copysign` is unnecessary (we only want to check the sign no need to create a new float) - it also prefer `other > self` instead of `self < other` like IEEE 754-2019 does I originally tried to implement them [using intrinsics](https://github.com/Urgau/rust/commit/1d8aa13bc39eeef1afba0524dc5ea10d073522e6) but LLVM [error out](https://godbolt.org/z/7sMrxW49a) when trying to lower them to machine intructions GCC doesn't yet have built-ins for them only cranelift support them nativelly (as it doesn't support the nativelly the old sementics). Helps with https://github.com/rust-lang/rust/issues/83984",THUMBS_UP,2021-11-25T07:41:58Z,gilescope,gilescope@gmail.com https://github.com/rust-lang/rust/pull/91021,MERGED,2021-11-18T20:32:18Z,2021-11-20T13:31:25Z,Elaborate `Future::Output` when printing opaque `impl Future` type,compiler-errors,3379721a30d87c396df69efa15b1307389d408df,27,"Rollup merge of #91021 - compiler-errors:print_future_output r=estebank Elaborate `Future::Output` when printing opaque `impl Future` type I would love to see the `Output =` type when printing type errors involving opaque `impl Future`. [Test code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a800b481edd31575fbcaf5771a9c3678) Before (cut relevant part of output): ``` note: while checking the return type of the `async fn` --> /home/michael/test.rs:5:19 | 5 | async fn bar() -> usize { | ^^^^^ checked the `Output` of this `async fn` found opaque type = note: expected type `usize` found opaque type `impl Future` ``` After: ``` note: while checking the return type of the `async fn` --> /home/michael/test.rs:5:19 | 5 | async fn bar() -> usize { | ^^^^^ checked the `Output` of this `async fn` found opaque type = note: expected type `usize` found opaque type `impl Future` ``` Note the ""found opaque type `impl Future`"" in the new output. ---- Questions: 1. We skip printing the output type when it's a projection since I have been seeing some types like `impl Future>::Return>` which are not particularly helpful and leak implementation detail. * Am I able to normalize this type within `rustc_middle::ty::print::pretty`? Alternatively can we normalize it when creating the diagnostic? Otherwise I'm fine with skipping it and falling back to the old output. * Should I suppress any other types? I didn't encounter anything other than this generator projection type. 2. Not sure what the formatting of this should be. Do I include spaces in `Output = `?",HEART,2021-11-19T17:30:08Z,estebank,NA https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-11-19T14:53:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-11-19T17:05:36Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-11-22T22:03:37Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-11-26T00:50:05Z,csmoe,csmoe@msn.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-12-02T10:33:04Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-12-15T21:47:25Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2021-12-17T23:31:09Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2022-01-10T16:52:16Z,tmandry,NA https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HOORAY,2022-01-18T02:32:11Z,dingxiangfei2009,NA https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HEART,2022-02-03T22:52:22Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/91032,MERGED,2021-11-19T02:36:31Z,2022-01-21T06:20:21Z,Introduce drop range tracking to generator interior analysis,eholk,3d10c64b26936a5b597bffc983220058a9a250b9,25,"Rollup merge of #91032 - eholk:generator-drop-tracking r=nikomatsakis Introduce drop range tracking to generator interior analysis This PR addresses cases such as this one from #57478: ```rust struct Foo; impl !Send for Foo {} let _: impl Send = || { let guard = Foo; drop(guard); yield; }; ``` Previously the `generator_interior` pass would unnecessarily include the type `Foo` in the generator because it was not aware of the behavior of `drop`. We fix this issue by introducing a drop range analysis that finds portions of the code where a value is guaranteed to be dropped. If a value is dropped at all suspend points then it is no longer included in the generator type. Note that we are using ""dropped"" in a generic sense to include any case in which a value has been moved. That is we do not only look at calls to the `drop` function. There are several phases to the drop tracking algorithm and we'll go into more detail below. 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. 2. `DropRangeVisitor` uses consume and borrow information to gather drop and reinitialization events as well as build a control flow graph. 3. We then propagate drop and reinitialization information through the CFG until we reach a fix point (see `DropRanges::propagate_to_fixpoint`). 4. When recording a type (see `InteriorVisitor::record`) we check the computed drop ranges to see if that value is definitely dropped at the suspend point. If so we skip including it in the type. ## 1. Use `ExprUseVisitor` to find values that are consumed and borrowed. We use `ExprUseVisitor` to identify the places where values are consumed. We track both the `hir_id` of the value and the `hir_id` of the expression that consumes it. For example in the expression `[Foo]` the `Foo` is consumed by the array expression so after the array expression we can consider the `Foo` temporary to be dropped. In this process we also collect values that are borrowed. The reason is that the MIR transform for generators conservatively assumes anything borrowed is live across a suspend point (see `rustc_mir_transform::generator::locals_live_across_suspend_points`). We match this behavior here as well. ## 2. Gather drop events reinitialization events and control flow graph After finding the values of interest we perform a post-order traversal over the HIR tree to find the points where these values are dropped or reinitialized. We use the post-order index of each event because this is how the existing generator interior analysis refers to the position of suspend points and the scopes of variables. During this traversal we also record branching and merging information to handle control flow constructs such as `if` `match` and `loop`. This is necessary because values may be dropped along some control flow paths but not others. ## 3. Iterate to fixed point The previous pass found the interesting events and locations but now we need to find the actual ranges where things are dropped. Upon entry we have a list of nodes ordered by their position in the post-order traversal. Each node has a set of successors. For each node we additionally keep a bitfield with one bit per potentially consumed value. The bit is set if we the value is dropped along all paths entering this node. To compute the drop information we first reverse the successor edges to find each node's predecessors. Then we iterate through each node and for each node we set its dropped value bitfield to the intersection of all incoming dropped value bitfields. If any bitfield for any node changes we re-run the propagation loop again. ## 4. Ignore dropped values across suspend points At this point we have a data structure where we can ask whether a value is guaranteed to be dropped at any post order index for the HIR tree. We use this information in `InteriorVisitor` to check whether a value in question is dropped at a particular suspend point. If it is we do not include that value's type in the generator type. Note that we had to augment the region scope tree to include all yields in scope rather than just the last one as we did before. r? `@nikomatsakis`",HEART,2022-06-17T15:25:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91040,CLOSED,2021-11-19T14:03:34Z,2021-11-23T09:01:03Z,Turned all 0x1b_u8.into() into '\x1b' in the docs,T-O-R-U-S,NA,NA,NA,HEART,2021-11-19T14:23:24Z,r00ster91,NA https://github.com/rust-lang/rust/pull/91047,CLOSED,2021-11-19T18:01:03Z,2022-04-22T21:15:43Z,str: Implement str::trim_newline,ijackson,NA,NA,NA,THUMBS_UP,2021-12-27T00:47:01Z,dylni,NA https://github.com/rust-lang/rust/pull/91057,MERGED,2021-11-19T21:53:35Z,2021-11-27T17:36:03Z,Expand `available_parallelism` docs in anticipation of cgroup quota support,the8472,8fb58e5eced05e493a0431ee291ad955fb32cacf,1,"Rollup merge of #91057 - the8472:clarify-parallelism-steady-state r=dtolnay Expand `available_parallelism` docs in anticipation of cgroup quota support The ""fixed"" in ""fixed steady state limits"" means to exclude load-dependent resource prioritization that would calculate to 100% of capacity on an idle system and less capacity on a loaded system. Additionally I also exclude ""system load"" since it would be silly to try to identify other perhaps higher priority processes hogging some CPU cores that aren't explicitly excluded by masks/quotas/whatever.",THUMBS_UP,2021-11-26T23:08:09Z,strohel,matej@laitl.cz https://github.com/rust-lang/rust/pull/91065,MERGED,2021-11-20T02:03:50Z,2021-12-07T14:23:07Z,Add test for evaluate_obligation: Ok(EvaluatedToOkModuloRegions) ICE,wesleywiser,42d0f8351aafa58755c44f49358675da208c4d51,3,Rollup merge of #91065 - wesleywiser:add_incr_test r=jackh726 Add test for evaluate_obligation: Ok(EvaluatedToOkModuloRegions) ICE Adds the minimial repro test case from #85360. The fix for #85360 was supposed to be #85868 however the repro was resolved in the 2021-07-05 nightly while #85868 didn't land until 2021-09-03. The reason for that is d34a3a401b4e44f289a4d5bf53da83367cbb6aa7 **also** resolves that issue. To test if #85868 actually fixes #85360 I reverted d34a3a401b4e44f289a4d5bf53da83367cbb6aa7 and found that #85868 does indeed resolve #85360. With that question resolved add a test case to our incremental test suite for the original Ok(EvaluatedToOkModuloRegions) ICE. Thanks to ````@lqd```` for helping track this down!,HEART,2021-11-21T18:53:15Z,lqd,NA https://github.com/rust-lang/rust/pull/91070,MERGED,2021-11-20T03:42:43Z,2021-11-21T13:26:36Z,Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`,cuviper,df552b3c24ac364802aaea6e77025110c074ddc7,3,Rollup merge of #91070 - cuviper:insert-global r=nagisa Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable` `Module::getOrInsertGlobal` returns a `Constant*` which is a super class of `GlobalVariable` but if the given type doesn't match an existing declaration it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead. Fixes #91050 fixes #87933 fixes #87813.,THUMBS_UP,2021-11-20T06:13:45Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/91070,MERGED,2021-11-20T03:42:43Z,2021-11-21T13:26:36Z,Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`,cuviper,df552b3c24ac364802aaea6e77025110c074ddc7,3,Rollup merge of #91070 - cuviper:insert-global r=nagisa Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable` `Module::getOrInsertGlobal` returns a `Constant*` which is a super class of `GlobalVariable` but if the given type doesn't match an existing declaration it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead. Fixes #91050 fixes #87933 fixes #87813.,THUMBS_UP,2021-11-20T17:29:23Z,eclipseo,NA https://github.com/rust-lang/rust/pull/91070,MERGED,2021-11-20T03:42:43Z,2021-11-21T13:26:36Z,Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`,cuviper,df552b3c24ac364802aaea6e77025110c074ddc7,3,Rollup merge of #91070 - cuviper:insert-global r=nagisa Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable` `Module::getOrInsertGlobal` returns a `Constant*` which is a super class of `GlobalVariable` but if the given type doesn't match an existing declaration it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead. Fixes #91050 fixes #87933 fixes #87813.,HEART,2021-11-20T17:29:30Z,eclipseo,NA https://github.com/rust-lang/rust/pull/91083,CLOSED,2021-11-20T10:27:49Z,2021-11-20T13:18:29Z,Just a Test,NA,NA,NA,NA,EYES,2021-11-20T10:42:06Z,the8472,NA https://github.com/rust-lang/rust/pull/91083,CLOSED,2021-11-20T10:27:49Z,2021-11-20T13:18:29Z,Just a Test,NA,NA,NA,NA,EYES,2021-11-20T10:55:09Z,hkratz,NA https://github.com/rust-lang/rust/pull/91083,CLOSED,2021-11-20T10:27:49Z,2021-11-20T13:18:29Z,Just a Test,NA,NA,NA,NA,EYES,2021-11-20T11:58:22Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/91086,MERGED,2021-11-20T12:43:16Z,2021-12-13T03:52:56Z,Implement `TryFrom<&'_ mut [T]>` for `[T; N]`,rhysd,42f8d4833f21030fa3dff509a2559dfcb5d5ed72,2,Rollup merge of #91086 - rhysd:issue-91085 r=m-ou-se Implement `TryFrom<&'_ mut [T]>` for `[T; N]` Fixes #91085.,THUMBS_UP,2021-11-20T14:20:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91086,MERGED,2021-11-20T12:43:16Z,2021-12-13T03:52:56Z,Implement `TryFrom<&'_ mut [T]>` for `[T; N]`,rhysd,42f8d4833f21030fa3dff509a2559dfcb5d5ed72,2,Rollup merge of #91086 - rhysd:issue-91085 r=m-ou-se Implement `TryFrom<&'_ mut [T]>` for `[T; N]` Fixes #91085.,THUMBS_UP,2021-11-20T21:25:55Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/91086,MERGED,2021-11-20T12:43:16Z,2021-12-13T03:52:56Z,Implement `TryFrom<&'_ mut [T]>` for `[T; N]`,rhysd,42f8d4833f21030fa3dff509a2559dfcb5d5ed72,2,Rollup merge of #91086 - rhysd:issue-91085 r=m-ou-se Implement `TryFrom<&'_ mut [T]>` for `[T; N]` Fixes #91085.,THUMBS_UP,2021-11-21T06:10:43Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/91089,CLOSED,2021-11-20T17:38:25Z,2021-11-22T20:14:16Z,rustdoc: Skip headers in summaries,camelid,NA,NA,NA,THUMBS_UP,2021-11-21T12:03:33Z,Nemo157,github@nemo157.com https://github.com/rust-lang/rust/pull/91091,MERGED,2021-11-20T19:58:11Z,2021-12-13T03:52:56Z,Stabilize `ControlFlow::{is_break is_continue}`,ecstatic-morse,6227d42928b0caef4ebb258df7247c1f85fb9e83,1,Rollup merge of #91091 - ecstatic-morse:control-flow-enum-is r=m-ou-se Stabilize `ControlFlow::{is_break is_continue}` The type itself was stabilized in 1.55 but using it is not ergonomic without these helper functions. Stabilize them. r? rust-lang/libs-api,THUMBS_UP,2021-11-22T07:06:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91096,MERGED,2021-11-20T23:33:50Z,2021-11-25T19:20:50Z,Print associated types on opaque `impl Trait` types,compiler-errors,6970cf5a23b4b9a3fbe474684e6bec9f0e13ddd4,36,Rollup merge of #91096 - compiler-errors:elaborate_opaque_trait r=estebank Print associated types on opaque `impl Trait` types This PR generalizes #91021 printing associated types for all opaque `impl Trait` types instead of just special-casing for future. before: ``` error[E0271]: type mismatch resolving `::Item == u32` ``` after: ``` error[E0271]: type mismatch resolving ` as Iterator>::Item == u32` ``` --- Questions: 1. I'm kinda lost in binders hell with this one. Is all of the `rebind`ing necessary? 2. Is there a map collection type that will give me a stable iteration order? Doesn't seem like TraitRef is Ord so I can't just sort later.. 3. I removed the logic that suppresses printing generator projection types. It creates outputs like this [gist](https://gist.github.com/compiler-errors/d6f12fb30079feb1ad1d5f1ab39a3a8d). Should I put that back? 4. I also added spaces between traits `impl A+B` -> `impl A + B`. I quite like this change but is there a good reason to keep it like that? r? ````@estebank````,HEART,2021-11-23T19:44:36Z,estebank,NA https://github.com/rust-lang/rust/pull/91098,MERGED,2021-11-21T01:27:21Z,2021-11-21T13:26:36Z,Don't suggest certain fixups (`.field` `.await` etc) when reporting errors while matching on arrays ,compiler-errors,a54eae94a019a4128265413f3799b8d93a81c2e3,4,Rollup merge of #91098 - compiler-errors:issue-91058 r=estebank Don't suggest certain fixups (`.field` `.await` etc) when reporting errors while matching on arrays When we have a type mismatch with a `cause.code` that is an `ObligationCauseCode::Pattern` skip suggesting fixes like adding `.await` or accessing a struct's `.field` if the pattern's `root_ty` differs from the `expected` ty. This occurs in situations like this: ```rust struct S(()); fn main() { let array = [S(())]; match array { [()] => {} _ => {} } } ``` I think what's happening here is a layer of `[_; N]` is peeled off of both types and we end up seeing the mismatch between just `S` and `()` but when we suggest a fixup that applies to the expression with type `root_ty`. --- Questions: 1. Should this check live here above all of the suggestions or should I push this down into every suggestion when we match `ObligationCauseCode`? 2. Any other `ObligationCauseCode`s to check here? 3. Am I overlooking an easier way to get to this same conclusion without pattern matching on `ObligationCauseCode` and comparing `root_ty`? Fixes #91058,HEART,2021-12-10T18:40:14Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2021-11-22T07:04:46Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2021-11-23T12:11:36Z,oli-obk,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2021-11-28T18:00:39Z,Ravenslofty,dan.ravensloft@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-01-05T20:16:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-05T20:16:56Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-18T14:13:44Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-20T06:43:59Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-01-20T08:44:15Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-20T12:42:01Z,jplatte,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-20T20:16:40Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-27T20:31:32Z,CGMossa,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-01-27T20:31:32Z,CGMossa,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-28T03:30:37Z,kaoet,kaoet.ibe@outlook.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-28T20:00:22Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-29T06:18:54Z,ratmice,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-01-29T14:12:42Z,janriemer,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T01:58:44Z,estebank,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T03:06:31Z,Folyd,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T03:28:14Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T04:27:24Z,lukechu10,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T04:47:18Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-02-03T04:47:20Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,HEART,2022-02-03T08:07:03Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T08:08:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-02-03T08:08:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T08:16:58Z,yerke,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-03T22:55:45Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,HEART,2022-02-03T22:55:46Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-02-04T16:31:06Z,miraclx,omiraculous@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-02-04T23:44:18Z,Aurora2500,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,HEART,2022-02-04T23:44:20Z,Aurora2500,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-04T23:45:36Z,Aurora2500,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-07T01:37:39Z,tema3210,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-07T18:39:26Z,XX,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,THUMBS_UP,2022-02-07T18:39:28Z,XX,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-02-07T20:26:53Z,Sympatron,NA https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-04-07T14:50:43Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-04-07T14:56:24Z,AndrielFR,andrielkogama2@gmail.com https://github.com/rust-lang/rust/pull/91122,MERGED,2021-11-22T03:18:14Z,2022-01-23T12:29:13Z,impl Not for !,dtolnay,55a1f8b955df07a421108b1205b96de68cfc7ef0,4,Rollup merge of #91122 - dtolnay:not r=m-ou-se impl Not for ! The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}` even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression which would otherwise be perfectly legal in boolean position the code previously failed to compile with: ```console error[E0600]: cannot apply unary operator `!` to type `!` --> library/core/tests/ops.rs:239:8 | 239 | if !return () {} | ^^^^^^^^^^ cannot apply unary operator `!` ```,LAUGH,2022-04-07T22:23:42Z,alarsyo,NA https://github.com/rust-lang/rust/pull/91140,MERGED,2021-11-22T20:22:11Z,2021-11-23T23:49:02Z,Split inline const to two feature gates and mark expression position inline const complete,nbdd0121,a26c2c7495b6a6d4df49d6dabe3453057804e98e,32,Rollup merge of #91140 - nbdd0121:const_typeck r=oli-obk Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts) so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. ``@rustbot`` label: T-compiler F-inline_const,HEART,2021-11-23T00:10:17Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/91140,MERGED,2021-11-22T20:22:11Z,2021-11-23T23:49:02Z,Split inline const to two feature gates and mark expression position inline const complete,nbdd0121,a26c2c7495b6a6d4df49d6dabe3453057804e98e,32,Rollup merge of #91140 - nbdd0121:const_typeck r=oli-obk Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts) so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. ``@rustbot`` label: T-compiler F-inline_const,HEART,2021-11-23T18:59:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91140,MERGED,2021-11-22T20:22:11Z,2021-11-23T23:49:02Z,Split inline const to two feature gates and mark expression position inline const complete,nbdd0121,a26c2c7495b6a6d4df49d6dabe3453057804e98e,32,Rollup merge of #91140 - nbdd0121:const_typeck r=oli-obk Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with #89561 and other PRs. The only thing left that I am aware of is #90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in #89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts) so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. ``@rustbot`` label: T-compiler F-inline_const,HEART,2021-12-02T22:13:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91141,MERGED,2021-11-22T20:50:04Z,2021-12-19T15:44:31Z,"Revert ""Temporarily rename int_roundings functions to avoid conflicts""",jhpratt,6d2689526b168d0208af0930e46dc2ef360f07fc,4,"Rollup merge of #91141 - jhpratt:int_roundings r=joshtriplett Revert ""Temporarily rename int_roundings functions to avoid conflicts"" This reverts commit 3ece63b64e192146fcdd1724e25856a93d7626aa. This should be okay because #90329 has been merged. r? `@joshtriplett`",HOORAY,2021-11-23T02:22:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91141,MERGED,2021-11-22T20:50:04Z,2021-12-19T15:44:31Z,"Revert ""Temporarily rename int_roundings functions to avoid conflicts""",jhpratt,6d2689526b168d0208af0930e46dc2ef360f07fc,4,"Rollup merge of #91141 - jhpratt:int_roundings r=joshtriplett Revert ""Temporarily rename int_roundings functions to avoid conflicts"" This reverts commit 3ece63b64e192146fcdd1724e25856a93d7626aa. This should be okay because #90329 has been merged. r? `@joshtriplett`",HOORAY,2021-12-19T14:10:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91149,MERGED,2021-11-23T02:59:07Z,2021-11-24T03:00:12Z,fix(doctest): detect extern crate items in statement doctests,notriddle,de4b242e1e2143f549f25ac5a8f7de9d902ef3b4,5,Auto merge of #91149 - notriddle:notriddle/rustdoc-doctest-semicolon r=jyn514 fix(doctest): detect extern crate items in statement doctests This partially reverts #91026 because rustdoc needs to detect the extern statements even when they appear inside implicit `main()`. It does not entirely revert it so the old bug is still fixed by duplicating some of the logic from `parse_mod` instead of trying to use it directly. Fixes #91134,HEART,2021-11-23T14:19:08Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91170,CLOSED,2021-11-24T07:36:09Z,2021-12-03T11:42:58Z,rustdoc: preload fonts,jsha,NA,NA,NA,THUMBS_UP,2021-11-26T19:46:18Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/91181,MERGED,2021-11-24T17:03:48Z,2021-11-26T09:55:22Z,Improve rustdoc-gui CI,GuillaumeGomez,a7836bf885e70aaf1a2e0d4669406b183a79acaa,3,Auto merge of #91181 - GuillaumeGomez:improve-rustdoc-gui-ci r=jsha Improve rustdoc-gui CI As commented [here](https://github.com/rust-lang/rust/pull/91179#discussion_r756023009): When the text isn't displayed the color returned by puppeteer is always `rgba(0 0 0 0)` which is definitely not the right value. To prevent this error from happening again `browser-ui-test` will now fail if a CSS color check is run when the text isn't displayed. Either this PR or #91179 is merged first they'll conflict because I made changes to the same test file. cc `@jyn514` r? `@jsha`,EYES,2021-11-24T17:28:55Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91185,MERGED,2021-11-24T18:28:02Z,2021-11-25T19:20:50Z,Remove `-Z force-overflow-checks`,camelid,984e6444324d45b3f0f41ff9aeac8ab999076d97,6,Rollup merge of #91185 - camelid:rm-force-overflow-checks r=wesleywiser Remove `-Z force-overflow-checks` It was replaced several years ago by the stable option `-C overflow-checks`. The goal was to delete the `-Z` flag once users had migrated [1]. Now that it's been several years it makes sense to delete the old flag. See also the discussion on Zulip [2]. [1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097 [2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224 r? ```@wesleywiser``` cc ```@RalfJung```,THUMBS_UP,2021-11-24T18:37:37Z,RalfJung,NA https://github.com/rust-lang/rust/pull/91185,MERGED,2021-11-24T18:28:02Z,2021-11-25T19:20:50Z,Remove `-Z force-overflow-checks`,camelid,984e6444324d45b3f0f41ff9aeac8ab999076d97,6,Rollup merge of #91185 - camelid:rm-force-overflow-checks r=wesleywiser Remove `-Z force-overflow-checks` It was replaced several years ago by the stable option `-C overflow-checks`. The goal was to delete the `-Z` flag once users had migrated [1]. Now that it's been several years it makes sense to delete the old flag. See also the discussion on Zulip [2]. [1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097 [2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224 r? ```@wesleywiser``` cc ```@RalfJung```,HEART,2021-11-25T14:47:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91189,CLOSED,2021-11-24T19:16:25Z,2021-11-28T17:50:19Z,[beta] [1.57] Disable LLVM newPM by default,nagisa,NA,NA,NA,CONFUSED,2021-11-25T11:15:04Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/91189,CLOSED,2021-11-24T19:16:25Z,2021-11-28T17:50:19Z,[beta] [1.57] Disable LLVM newPM by default,nagisa,NA,NA,NA,CONFUSED,2021-12-02T16:57:50Z,lnicola,NA https://github.com/rust-lang/rust/pull/91195,MERGED,2021-11-24T20:13:25Z,2021-11-25T16:12:12Z,rustdoc: Remove `ResolvedPath.did`,camelid,862962b90e59c5c1e217df74de80d3a81eee42f4,9,Auto merge of #91195 - camelid:path-did r=jyn514 rustdoc: Remove `ResolvedPath.did` `ResolvedPath.did` was not actually the same as `.path.def_id()`. Instead `.did` referred to the `DefId` of the page to be used as a hyperlink target. For example a link to `Struct::method()` would use `Struct`'s `DefId` as its `.did` field. This behavior is confusing easy to accidentally misuse and can instead be obtained on-demand when computing hyperlink targets. It's also likely part of the reason `kind_side_channel` exists. I'm currently working on some experimental refactorings in `collect_intra_doc_links` that I believe require -- or at least benefit from -- removing `.did`. r? `@jyn514`,HEART,2021-11-24T20:18:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91215,MERGED,2021-11-25T10:51:28Z,2021-12-05T03:41:26Z,Implement VecDeque::retain_mut,GuillaumeGomez,4af985ac004fc0578cc6102f8e47844c227d0967,1,Rollup merge of #91215 - GuillaumeGomez:vec-deque-retain-mut r=m-ou-se Implement VecDeque::retain_mut Part of https://github.com/rust-lang/rust/issues/90829. In https://github.com/rust-lang/rust/pull/90772 someone suggested that `retain_mut` should also be implemented on `VecDeque`. I think that it follows the same logic (coherency). So first: is it ok? Second: should I create a new feature for it or can we put it into the same one? r? `@joshtriplett`,THUMBS_UP,2021-12-04T16:03:55Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/91220,CLOSED,2021-11-25T13:33:40Z,2021-11-29T17:12:12Z,[beta][1.57] Disable outline atomics for aarch64-unknown-linux-musl,hkratz,NA,NA,NA,THUMBS_UP,2021-11-29T04:10:32Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/91222,CLOSED,2021-11-25T14:46:39Z,2021-11-27T03:30:40Z,[EXPERIMENT] Don't monomorphize things that are unused due to `if ::CONST`,scottmcm,NA,NA,NA,ROCKET,2021-11-27T08:16:48Z,lqd,NA https://github.com/rust-lang/rust/pull/91223,MERGED,2021-11-25T14:57:33Z,2021-11-27T03:45:44Z,Fix headings indent,GuillaumeGomez,330a558e42abb0fbfc020079754de299aaa409f2,3,Rollup merge of #91223 - GuillaumeGomez:headings-indent r=jsha Fix headings indent Fixes #91200. Screenshots with the fix: ![Screenshot from 2021-11-25 15-32-35](https://user-images.githubusercontent.com/3050060/143462481-f7e9ea13-72d5-46fe-90e0-9527e74599e3.png) ![Screenshot from 2021-11-25 15-32-49](https://user-images.githubusercontent.com/3050060/143462485-c010716a-0276-421b-a777-afff19c81c96.png) If the first element of a top docblock is a heading we still need to keep the indent but only on this one (I added a test to check it). We need it because otherwise the anchor will go over the `[-]` toggle. cc `@camelid` r? `@jsha`,HEART,2021-11-25T20:09:37Z,camelid,NA https://github.com/rust-lang/rust/pull/91224,MERGED,2021-11-25T16:04:45Z,2021-12-07T17:26:46Z,Support AVR for inline asm!,couchand,0b6f079e4987ded15c13a15b734e7cfb8176839f,8,Auto merge of #91224 - couchand:2021-11/avr-asm r=Amanieu Support AVR for inline asm! A first pass at support for the AVR platform in inline `asm!`. Passes the initial compiler tests have not yet done more complete verification. In particular the register classes could use a lot more fleshing out this draft PR so far only includes the most basic. cc `@Amanieu` `@dylanmckay`,THUMBS_UP,2021-12-01T11:24:40Z,dylanmckay,me@dylanmckay.io https://github.com/rust-lang/rust/pull/91229,MERGED,2021-11-25T17:47:17Z,2021-12-05T09:48:39Z,Include `lld` in `rust-dev` package,Aaron1011,6c189bc9c20f501819c67e40b980e287c7e24d10,1,Auto merge of #91229 - Aaron1011:dist-lld r=Mark-Simulacrum Include `lld` in `rust-dev` package Fixes #88941 This will allow using `download-ci-llvm` while still having LLD available.,HEART,2021-11-26T13:18:59Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91230,MERGED,2021-11-25T17:47:32Z,2021-11-28T16:09:47Z,Make `TypeFolder::fold_*` return `Result`,eggyal,e6d2de9483a27f846f003fc745713339a9122473,45,Auto merge of #91230 - eggyal:fallible-type-fold r=jackh726 Make `TypeFolder::fold_*` return `Result` Implements rust-lang/compiler-team#432. Initially this is just a rebase of `@LeSeulArtichaut's` work in #85469 (abandoned; see https://github.com/rust-lang/rust/pull/85485#issuecomment-908781112). At that time it caused a regression in performance that required some further exploration... with this rebased PR bors can hopefully report some perf analysis from which we can investigate further (if the regression is indeed still present). r? `@jackh726` cc `@nikomatsakis`,HEART,2021-11-25T19:35:34Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/91230,MERGED,2021-11-25T17:47:32Z,2021-11-28T16:09:47Z,Make `TypeFolder::fold_*` return `Result`,eggyal,e6d2de9483a27f846f003fc745713339a9122473,45,Auto merge of #91230 - eggyal:fallible-type-fold r=jackh726 Make `TypeFolder::fold_*` return `Result` Implements rust-lang/compiler-team#432. Initially this is just a rebase of `@LeSeulArtichaut's` work in #85469 (abandoned; see https://github.com/rust-lang/rust/pull/85485#issuecomment-908781112). At that time it caused a regression in performance that required some further exploration... with this rebased PR bors can hopefully report some perf analysis from which we can investigate further (if the regression is indeed still present). r? `@jackh726` cc `@nikomatsakis`,HEART,2021-11-25T20:52:18Z,camelid,NA https://github.com/rust-lang/rust/pull/91240,MERGED,2021-11-26T02:24:09Z,2021-11-27T03:45:43Z,Saner formatting for UTF8_CHAR_WIDTH table,dtolnay,3bdf5fbbd8511292717a388e148de22cb6acdee1,1,Rollup merge of #91240 - dtolnay:utf8width r=Mark-Simulacrum Saner formatting for UTF8_CHAR_WIDTH table The way these lines were currently wrapped definitely does not look like someone's intentional formatting. It's likely they got disfigured by rustfmt at some point. This commit rearranges it to a rustfmt-compatible formatting that I find easier to read.,HEART,2021-11-26T08:24:10Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/91240,MERGED,2021-11-26T02:24:09Z,2021-11-27T03:45:43Z,Saner formatting for UTF8_CHAR_WIDTH table,dtolnay,3bdf5fbbd8511292717a388e148de22cb6acdee1,1,Rollup merge of #91240 - dtolnay:utf8width r=Mark-Simulacrum Saner formatting for UTF8_CHAR_WIDTH table The way these lines were currently wrapped definitely does not look like someone's intentional formatting. It's likely they got disfigured by rustfmt at some point. This commit rearranges it to a rustfmt-compatible formatting that I find easier to read.,HEART,2021-11-26T09:22:09Z,Urgau,NA https://github.com/rust-lang/rust/pull/91240,MERGED,2021-11-26T02:24:09Z,2021-11-27T03:45:43Z,Saner formatting for UTF8_CHAR_WIDTH table,dtolnay,3bdf5fbbd8511292717a388e148de22cb6acdee1,1,Rollup merge of #91240 - dtolnay:utf8width r=Mark-Simulacrum Saner formatting for UTF8_CHAR_WIDTH table The way these lines were currently wrapped definitely does not look like someone's intentional formatting. It's likely they got disfigured by rustfmt at some point. This commit rearranges it to a rustfmt-compatible formatting that I find easier to read.,HEART,2021-11-27T14:08:41Z,bluss,NA https://github.com/rust-lang/rust/pull/91245,MERGED,2021-11-26T09:34:07Z,2021-12-09T04:04:05Z,suggest casting between i/u32 and char,cameron1024,2411cd7c7abd3a4d4aba657961ca1f940e1657bd,5,Rollup merge of #91245 - cameron1024:suggest-i32-u32-char-cast r=nagisa suggest casting between i/u32 and char As discussed in https://github.com/rust-lang/rust/issues/91063 this adds a suggestion for converting between i32/u32 <-> char with `as` and a short explanation for why this is safe,HEART,2021-11-27T23:38:22Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/91254,MERGED,2021-11-26T15:18:55Z,2021-11-28T13:04:25Z,Only check for errors in predicate when skipping impl assembly,Aaron1011,9e8dfcffb7a84c01c0210f2c3a6b812e6be00743,6,Rollup merge of #91254 - Aaron1011:impl-candidate-err-ty r=lcnr Only check for errors in predicate when skipping impl assembly Prior to PR #91205 checking for errors in the overall obligation would check checking the `ParamEnv` due to an incorrect `super_visit_with` impl. With this bug fixed we will now bail out of impl candidate assembly if the `ParamEnv` contains any error types. In practice this appears to be overly conservative - when an error occurs early in compilation we end up giving up early for some predicates that we could have successfully evaluated without overflow. By only checking for errors in the predicate itself we avoid causing additional spurious 'type annotations needed' errors after a 'real' error has already occurred. With this PR the diagnostic changes caused by PR #91205 are reverted.,HEART,2021-11-26T18:54:19Z,estebank,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2021-11-26T20:45:52Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2021-11-26T23:21:16Z,camelid,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HEART,2021-11-26T23:21:18Z,camelid,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2021-11-27T17:40:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HEART,2021-11-27T17:40:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2021-11-29T11:49:50Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HEART,2021-12-01T15:01:17Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2022-02-22T21:40:10Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HOORAY,2022-03-09T19:00:04Z,tema3210,NA https://github.com/rust-lang/rust/pull/91255,MERGED,2021-11-26T17:54:16Z,2021-12-01T16:36:18Z,Implement version of normalize_erasing_regions that allows for normalization failure,b-naber,f04a2f4b8e89eac1119061ea2055d33c97e618b4,18,Auto merge of #91255 - b-naber:normalization-ice r=jackh276 Implement version of normalize_erasing_regions that allows for normalization failure Fixes https://github.com/rust-lang/rust/issues/59324 Fixes https://github.com/rust-lang/rust/issues/67684 Fixes https://github.com/rust-lang/rust/issues/69398 Fixes https://github.com/rust-lang/rust/issues/71113 Fixes https://github.com/rust-lang/rust/issues/82079 Fixes #85103 Fixes https://github.com/rust-lang/rust/issues/88856 Fixes #91231 Fixes https://github.com/rust-lang/rust/issues/91234 Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished we introduce a new variant that allows for returning an error.,HEART,2022-03-09T19:00:05Z,tema3210,NA https://github.com/rust-lang/rust/pull/91259,MERGED,2021-11-26T19:01:18Z,2021-11-27T03:45:43Z,Remove `--display-doctest-warnings`,jyn514,092477d8c994ae91dc73f90c086ba00e68674fa8,8,Rollup merge of #91259 - jyn514:doctest-warnings r=GuillaumeGomez Remove `--display-doctest-warnings` `--display-doctest-warnings` can be replicated in full with other existing features there's no need to have a separate option for it. This removes the option and documents the combination of other features to replicate it. This also fixes a bug where `--test-args=--show-output` had no effect. cc `@ollie27 ` https://github.com/rust-lang/rust/pull/73314#issuecomment-668317262 Fixes https://github.com/rust-lang/rust/issues/41574 r? `@GuillaumeGomez`,HEART,2021-11-26T20:31:03Z,camelid,NA https://github.com/rust-lang/rust/pull/91266,MERGED,2021-11-26T21:06:42Z,2021-11-27T17:36:03Z,Use non-generic inner function for pointer formatting,jam1garner,073b1208f0389f89ade1e60401edc99c7a113a50,1,"Rollup merge of #91266 - jam1garner:fmt-ptr-fix r=dtolnay Use non-generic inner function for pointer formatting Previously despite the implementation being type-unaware `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects: * `fmt::Debug` for `*const T` * `fmt::Debug` for `*mut T` * `fmt::Pointer` for `*const T` * `fmt::Pointer` for `*mut T` And since the implementation is non-trivial this results in a large amount of LLVM bitcode being generated. For example with a large bindgen project with Debug implementations enabled it will generate a lot of calls to `fmt::Debug for *const T` which in turn will perform codegen for a copy of this function for every type. For example in a real-world bindgen'd header I've been testing with (4 189 245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
Nightly (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 7256000 (100%) 216544 (100%) (TOTAL) 1815449 (25.0%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 300248 (4.1%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (4.0%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 217746 (3.0%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 123329 (1.7%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.0%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.0%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (0.9%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.5%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.4%) 1493 (0.7%) core::array::::fmt 22290 (0.3%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.2%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
This PR (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 5684504 (100%) 216542 (100%) (TOTAL) 300248 (5.3%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (5.1%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 266265 (4.7%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 217746 (3.8%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 101039 (1.8%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.3%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.3%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (1.2%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.7%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.5%) 1493 (0.7%) core::array::::fmt 22290 (0.4%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.3%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.3%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.3%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
Output generated using `cargo llvm-lines` version 0.4.12. Summary of differences: | rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time | |-|-|-|-| | `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 | | PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 | This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM in this case and is significantly improved by disabling derives for `fmt::Debug` as it prevents generating all this LLVM IR to be handled. Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
nightly (Click to Expand) ``` time: 2.370; rss: 56MB -> 1118MB (+1062MB) parse_crate time: 0.000; rss: 1118MB -> 1118MB ( +0MB) attributes_injection time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_loading time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_registration time: 0.000; rss: 1120MB -> 1120MB ( +0MB) crate_injection time: 13.897; rss: 1120MB -> 3147MB (+2027MB) expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) check_unused_macros time: 13.900; rss: 1120MB -> 3147MB (+2027MB) macro_expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) maybe_building_test_harness time: 0.503; rss: 3147MB -> 3147MB ( +0MB) AST_validation time: 0.000; rss: 3147MB -> 3147MB ( +0MB) maybe_create_a_macro_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) finalize_imports time: 0.502; rss: 3147MB -> 3153MB ( +6MB) finalize_macro_resolutions time: 4.478; rss: 3153MB -> 3574MB ( +420MB) late_resolve_crate time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_main time: 0.332; rss: 3574MB -> 3574MB ( +0MB) resolve_check_unused time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_report_errors time: 0.279; rss: 3574MB -> 3574MB ( +0MB) resolve_postprocess time: 5.595; rss: 3147MB -> 3574MB ( +427MB) resolve_crate time: 0.382; rss: 3574MB -> 3574MB ( +0MB) complete_gated_feature_checking time: 20.526; rss: 1120MB -> 3574MB (+2454MB) configure_and_expand time: 0.000; rss: 3574MB -> 3574MB ( +0MB) prepare_outputs time: 0.000; rss: 3574MB -> 3574MB ( +0MB) blocked_on_dep_graph_loading time: 65.992; rss: 3574MB -> 6317MB (+2743MB) hir_lowering time: 1.117; rss: 6317MB -> 6323MB ( +6MB) early_lint_checks time: 1.447; rss: 6323MB -> 6271MB ( -52MB) drop_ast time: 0.002; rss: 5838MB -> 5838MB ( +0MB) setup_global_ctxt time: 0.000; rss: 5843MB -> 5843MB ( +0MB) looking_for_entry_point time: 0.313; rss: 5843MB -> 5844MB ( +1MB) looking_for_derive_registrar time: 9.652; rss: 5843MB -> 6065MB ( +222MB) misc_checking_1 time: 9.713; rss: 6065MB -> 6769MB ( +704MB) type_collecting time: 0.665; rss: 6769MB -> 6769MB ( +0MB) impl_wf_inference time: 0.064; rss: 6769MB -> 6769MB ( +0MB) unsafety_checking time: 3.095; rss: 6769MB -> 6792MB ( +23MB) coherence_checking time: 21.282; rss: 6792MB -> 7546MB ( +754MB) wf_checking time: 5.404; rss: 7546MB -> 7681MB ( +135MB) item_types_checking time: 79.665; rss: 7681MB -> 8075MB ( +394MB) item_bodies_checking time: 120.166; rss: 6065MB -> 8081MB (+2016MB) type_check_crate time: 2.038; rss: 8081MB -> 8085MB ( +4MB) match_checking time: 1.300; rss: 8085MB -> 8113MB ( +28MB) liveness_and_intrinsic_checking time: 3.338; rss: 8081MB -> 8113MB ( +32MB) misc_checking_2 time: 68.612; rss: 8113MB -> 9285MB (+1172MB) MIR_borrow_checking time: 0.622; rss: 9285MB -> 9301MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9301MB -> 9301MB ( +0MB) layout_testing time: 4.331; rss: 9383MB -> 9510MB ( +127MB) death_checking time: 0.032; rss: 9510MB -> 9510MB ( +0MB) unused_lib_feature_checking time: 4.444; rss: 9510MB -> 9568MB ( +58MB) crate_lints time: 59.563; rss: 9568MB -> 9576MB ( +8MB) module_lints time: 64.006; rss: 9510MB -> 9576MB ( +66MB) lint_checking time: 4.127; rss: 9576MB -> 9639MB ( +62MB) privacy_checking_modules time: 77.984; rss: 9301MB -> 9639MB ( +337MB) misc_checking_3 time: 0.311; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.051; rss: 10357MB -> 10573MB ( +217MB) monomorphization_collector_graph_walk time: 1.759; rss: 10573MB -> 10652MB ( +79MB) partition_and_assert_distinct_symbols time: 28.518; rss: 9639MB -> 10711MB (+1072MB) generate_crate_metadata time: 0.000; rss: 10711MB -> 10711MB ( +0MB) find_cgu_reuse time: 63.408; rss: 10711MB -> 12272MB (+1560MB) codegen_to_LLVM_IR time: 64.916; rss: 10711MB -> 12267MB (+1556MB) codegen_crate time: 0.000; rss: 12261MB -> 12261MB ( +0MB) assert_dep_graph time: 0.000; rss: 12261MB -> 12261MB ( +0MB) check_dirty_clean time: 0.664; rss: 12230MB -> 12210MB ( -20MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 2.111; rss: 12210MB -> 12043MB ( -167MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.108; rss: 12043MB -> 12057MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.004; rss: 12057MB -> 12059MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.665; rss: 12059MB -> 12121MB ( +62MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 16.149; rss: 12121MB -> 12148MB ( +28MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.010; rss: 12148MB -> 12150MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.052; rss: 12150MB -> 12155MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.003; rss: 12155MB -> 12156MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 11.428; rss: 12156MB -> 11748MB ( -408MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 11748MB -> 11748MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.094; rss: 11748MB -> 11756MB ( +8MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.272; rss: 11756MB -> 11778MB ( +22MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.054; rss: 11778MB -> 11778MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 11778MB -> 11779MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.021; rss: 11779MB -> 11784MB ( +5MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.041; rss: 11784MB -> 11786MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.743; rss: 11786MB -> 11815MB ( +29MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.043; rss: 11815MB -> 11816MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.674; rss: 11816MB -> 11840MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11840MB -> 11841MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 33.153; rss: 12232MB -> 11841MB ( -390MB) encode_query_results time: 88.943; rss: 11955MB -> 11783MB ( -173MB) LLVM_passes(crate) time: 38.854; rss: 12259MB -> 10095MB (-2164MB) incr_comp_serialize_result_cache time: 39.030; rss: 12261MB -> 10095MB (-2166MB) incr_comp_persist_result_cache time: 0.000; rss: 10095MB -> 10095MB ( +0MB) incr_comp_persist_dep_graph time: 39.064; rss: 12257MB -> 10095MB (-2162MB) serialize_dep_graph time: 19.047; rss: 10095MB -> 10307MB ( +212MB) free_global_ctxt time: 0.000; rss: 10307MB -> 10307MB ( +0MB) join_worker_thread time: 0.519; rss: 10307MB -> 10307MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.522; rss: 10307MB -> 10307MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10307MB -> 10307MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10307MB -> 10307MB ( +0MB) serialize_work_products time: 0.001; rss: 9542MB -> 9542MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9542MB -> 9542MB ( +0MB) link_binary_check_files_are_writeable time: 7.835; rss: 9542MB -> 9544MB ( +2MB) link_rlib time: 0.000; rss: 9544MB -> 9544MB ( +0MB) link_binary_remove_temps time: 7.872; rss: 9542MB -> 9544MB ( +2MB) link_binary time: 7.944; rss: 9542MB -> 9201MB ( -341MB) link_crate time: 8.495; rss: 10307MB -> 9201MB (-1106MB) link time: 537.014; rss: 33MB -> 3715MB (+3682MB) total ```
This PR (Click to Expand) ``` time: 2.379; rss: 51MB -> 1116MB (+1064MB) parse_crate time: 0.003; rss: 1116MB -> 1116MB ( +0MB) attributes_injection time: 0.002; rss: 1116MB -> 1116MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1116MB -> 1116MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_loading time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_registration time: 0.003; rss: 1118MB -> 1118MB ( +0MB) crate_injection time: 13.376; rss: 1118MB -> 3143MB (+2025MB) expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) check_unused_macros time: 13.379; rss: 1118MB -> 3143MB (+2025MB) macro_expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_building_test_harness time: 0.479; rss: 3143MB -> 3143MB ( +0MB) AST_validation time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_create_a_macro_crate time: 0.005; rss: 3143MB -> 3143MB ( +0MB) finalize_imports time: 0.520; rss: 3143MB -> 3125MB ( -18MB) finalize_macro_resolutions time: 4.446; rss: 3125MB -> 3577MB ( +453MB) late_resolve_crate time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_main time: 0.336; rss: 3577MB -> 3577MB ( +0MB) resolve_check_unused time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_report_errors time: 0.295; rss: 3577MB -> 3578MB ( +0MB) resolve_postprocess time: 5.602; rss: 3143MB -> 3578MB ( +435MB) resolve_crate time: 0.388; rss: 3578MB -> 3578MB ( +0MB) complete_gated_feature_checking time: 20.014; rss: 1116MB -> 3578MB (+2462MB) configure_and_expand time: 0.000; rss: 3578MB -> 3578MB ( +0MB) prepare_outputs time: 0.000; rss: 3578MB -> 3578MB ( +0MB) blocked_on_dep_graph_loading time: 64.219; rss: 3578MB -> 6313MB (+2736MB) hir_lowering time: 1.102; rss: 6313MB -> 6319MB ( +6MB) early_lint_checks time: 1.426; rss: 6319MB -> 6268MB ( -52MB) drop_ast time: 0.005; rss: 5834MB -> 5836MB ( +2MB) setup_global_ctxt time: 0.000; rss: 5838MB -> 5838MB ( +0MB) looking_for_entry_point time: 0.292; rss: 5838MB -> 5840MB ( +1MB) looking_for_derive_registrar time: 9.553; rss: 5838MB -> 6060MB ( +222MB) misc_checking_1 time: 9.949; rss: 6060MB -> 6764MB ( +704MB) type_collecting time: 0.630; rss: 6764MB -> 6764MB ( +0MB) impl_wf_inference time: 0.060; rss: 6764MB -> 6764MB ( +0MB) unsafety_checking time: 3.054; rss: 6764MB -> 6787MB ( +23MB) coherence_checking time: 20.702; rss: 6787MB -> 7533MB ( +746MB) wf_checking time: 5.194; rss: 7533MB -> 7668MB ( +135MB) item_types_checking time: 74.677; rss: 7668MB -> 8062MB ( +394MB) item_bodies_checking time: 114.497; rss: 6060MB -> 8068MB (+2008MB) type_check_crate time: 1.891; rss: 8068MB -> 8072MB ( +4MB) match_checking time: 1.292; rss: 8072MB -> 8100MB ( +28MB) liveness_and_intrinsic_checking time: 3.183; rss: 8068MB -> 8100MB ( +32MB) misc_checking_2 time: 68.845; rss: 8100MB -> 9279MB (+1179MB) MIR_borrow_checking time: 0.587; rss: 9279MB -> 9295MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9295MB -> 9295MB ( +0MB) layout_testing time: 4.443; rss: 9377MB -> 9504MB ( +127MB) death_checking time: 0.034; rss: 9504MB -> 9504MB ( +0MB) unused_lib_feature_checking time: 4.409; rss: 9504MB -> 9562MB ( +58MB) crate_lints time: 56.490; rss: 9562MB -> 9571MB ( +8MB) module_lints time: 60.900; rss: 9504MB -> 9571MB ( +66MB) lint_checking time: 4.147; rss: 9571MB -> 9633MB ( +62MB) privacy_checking_modules time: 75.094; rss: 9295MB -> 9633MB ( +337MB) misc_checking_3 time: 0.315; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.501; rss: 10357MB -> 10571MB ( +215MB) monomorphization_collector_graph_walk time: 1.763; rss: 10571MB -> 10661MB ( +89MB) partition_and_assert_distinct_symbols time: 29.035; rss: 9633MB -> 10706MB (+1073MB) generate_crate_metadata time: 0.000; rss: 10706MB -> 10706MB ( +0MB) find_cgu_reuse time: 30.913; rss: 10706MB -> 12150MB (+1444MB) codegen_to_LLVM_IR time: 31.108; rss: 10706MB -> 12150MB (+1444MB) codegen_crate time: 0.000; rss: 12150MB -> 12150MB ( +0MB) assert_dep_graph time: 0.000; rss: 12150MB -> 12150MB ( +0MB) check_dirty_clean time: 0.416; rss: 12152MB -> 12199MB ( +46MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 1.259; rss: 12199MB -> 12211MB ( +12MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.095; rss: 12211MB -> 12193MB ( -18MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.005; rss: 12193MB -> 12195MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.828; rss: 12195MB -> 12208MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 17.880; rss: 12208MB -> 11987MB ( -222MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.007; rss: 11987MB -> 11988MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.049; rss: 11988MB -> 11992MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.002; rss: 11992MB -> 11994MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 38.049; rss: 11994MB -> 12093MB ( +99MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 12093MB -> 12093MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.024; rss: 12093MB -> 12095MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.372; rss: 12095MB -> 12053MB ( -42MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.015; rss: 12053MB -> 12053MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 12053MB -> 12054MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.003; rss: 12054MB -> 12056MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.037; rss: 12056MB -> 11899MB ( -157MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.667; rss: 11899MB -> 11708MB ( -191MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.045; rss: 11708MB -> 11709MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.295; rss: 11709MB -> 11734MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11734MB -> 11734MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 60.063; rss: 12152MB -> 11734MB ( -418MB) encode_query_results time: 76.745; rss: 12007MB -> 11699MB ( -308MB) LLVM_passes(crate) time: 61.634; rss: 12150MB -> 10557MB (-1593MB) incr_comp_serialize_result_cache time: 61.637; rss: 12150MB -> 10557MB (-1593MB) incr_comp_persist_result_cache time: 0.001; rss: 10557MB -> 10557MB ( +0MB) incr_comp_persist_dep_graph time: 61.641; rss: 12150MB -> 10557MB (-1593MB) serialize_dep_graph time: 15.601; rss: 10557MB -> 10242MB ( -315MB) free_global_ctxt time: 0.000; rss: 10242MB -> 10242MB ( +0MB) join_worker_thread time: 0.368; rss: 10242MB -> 10242MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.375; rss: 10242MB -> 10242MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10242MB -> 10242MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10242MB -> 10242MB ( +0MB) serialize_work_products time: 0.001; rss: 9668MB -> 9668MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9668MB -> 9668MB ( +0MB) link_binary_check_files_are_writeable time: 1.469; rss: 9668MB -> 9671MB ( +3MB) link_rlib time: 0.000; rss: 9671MB -> 9671MB ( +0MB) link_binary_remove_temps time: 1.506; rss: 9668MB -> 9671MB ( +3MB) link_binary time: 1.622; rss: 9668MB -> 9329MB ( -339MB) link_crate time: 2.037; rss: 10242MB -> 9329MB ( -913MB) link time: 502.990; rss: 32MB -> 5888MB (+5855MB) total ```
(6.34% decrease in runtime results are consistent across multiple runs)",HOORAY,2021-11-26T21:55:55Z,the8472,NA https://github.com/rust-lang/rust/pull/91266,MERGED,2021-11-26T21:06:42Z,2021-11-27T17:36:03Z,Use non-generic inner function for pointer formatting,jam1garner,073b1208f0389f89ade1e60401edc99c7a113a50,1,"Rollup merge of #91266 - jam1garner:fmt-ptr-fix r=dtolnay Use non-generic inner function for pointer formatting Previously despite the implementation being type-unaware `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects: * `fmt::Debug` for `*const T` * `fmt::Debug` for `*mut T` * `fmt::Pointer` for `*const T` * `fmt::Pointer` for `*mut T` And since the implementation is non-trivial this results in a large amount of LLVM bitcode being generated. For example with a large bindgen project with Debug implementations enabled it will generate a lot of calls to `fmt::Debug for *const T` which in turn will perform codegen for a copy of this function for every type. For example in a real-world bindgen'd header I've been testing with (4 189 245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
Nightly (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 7256000 (100%) 216544 (100%) (TOTAL) 1815449 (25.0%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 300248 (4.1%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (4.0%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 217746 (3.0%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 123329 (1.7%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.0%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.0%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (0.9%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.5%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.4%) 1493 (0.7%) core::array::::fmt 22290 (0.3%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.2%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
This PR (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 5684504 (100%) 216542 (100%) (TOTAL) 300248 (5.3%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (5.1%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 266265 (4.7%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 217746 (3.8%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 101039 (1.8%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.3%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.3%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (1.2%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.7%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.5%) 1493 (0.7%) core::array::::fmt 22290 (0.4%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.3%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.3%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.3%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
Output generated using `cargo llvm-lines` version 0.4.12. Summary of differences: | rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time | |-|-|-|-| | `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 | | PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 | This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM in this case and is significantly improved by disabling derives for `fmt::Debug` as it prevents generating all this LLVM IR to be handled. Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
nightly (Click to Expand) ``` time: 2.370; rss: 56MB -> 1118MB (+1062MB) parse_crate time: 0.000; rss: 1118MB -> 1118MB ( +0MB) attributes_injection time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_loading time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_registration time: 0.000; rss: 1120MB -> 1120MB ( +0MB) crate_injection time: 13.897; rss: 1120MB -> 3147MB (+2027MB) expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) check_unused_macros time: 13.900; rss: 1120MB -> 3147MB (+2027MB) macro_expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) maybe_building_test_harness time: 0.503; rss: 3147MB -> 3147MB ( +0MB) AST_validation time: 0.000; rss: 3147MB -> 3147MB ( +0MB) maybe_create_a_macro_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) finalize_imports time: 0.502; rss: 3147MB -> 3153MB ( +6MB) finalize_macro_resolutions time: 4.478; rss: 3153MB -> 3574MB ( +420MB) late_resolve_crate time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_main time: 0.332; rss: 3574MB -> 3574MB ( +0MB) resolve_check_unused time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_report_errors time: 0.279; rss: 3574MB -> 3574MB ( +0MB) resolve_postprocess time: 5.595; rss: 3147MB -> 3574MB ( +427MB) resolve_crate time: 0.382; rss: 3574MB -> 3574MB ( +0MB) complete_gated_feature_checking time: 20.526; rss: 1120MB -> 3574MB (+2454MB) configure_and_expand time: 0.000; rss: 3574MB -> 3574MB ( +0MB) prepare_outputs time: 0.000; rss: 3574MB -> 3574MB ( +0MB) blocked_on_dep_graph_loading time: 65.992; rss: 3574MB -> 6317MB (+2743MB) hir_lowering time: 1.117; rss: 6317MB -> 6323MB ( +6MB) early_lint_checks time: 1.447; rss: 6323MB -> 6271MB ( -52MB) drop_ast time: 0.002; rss: 5838MB -> 5838MB ( +0MB) setup_global_ctxt time: 0.000; rss: 5843MB -> 5843MB ( +0MB) looking_for_entry_point time: 0.313; rss: 5843MB -> 5844MB ( +1MB) looking_for_derive_registrar time: 9.652; rss: 5843MB -> 6065MB ( +222MB) misc_checking_1 time: 9.713; rss: 6065MB -> 6769MB ( +704MB) type_collecting time: 0.665; rss: 6769MB -> 6769MB ( +0MB) impl_wf_inference time: 0.064; rss: 6769MB -> 6769MB ( +0MB) unsafety_checking time: 3.095; rss: 6769MB -> 6792MB ( +23MB) coherence_checking time: 21.282; rss: 6792MB -> 7546MB ( +754MB) wf_checking time: 5.404; rss: 7546MB -> 7681MB ( +135MB) item_types_checking time: 79.665; rss: 7681MB -> 8075MB ( +394MB) item_bodies_checking time: 120.166; rss: 6065MB -> 8081MB (+2016MB) type_check_crate time: 2.038; rss: 8081MB -> 8085MB ( +4MB) match_checking time: 1.300; rss: 8085MB -> 8113MB ( +28MB) liveness_and_intrinsic_checking time: 3.338; rss: 8081MB -> 8113MB ( +32MB) misc_checking_2 time: 68.612; rss: 8113MB -> 9285MB (+1172MB) MIR_borrow_checking time: 0.622; rss: 9285MB -> 9301MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9301MB -> 9301MB ( +0MB) layout_testing time: 4.331; rss: 9383MB -> 9510MB ( +127MB) death_checking time: 0.032; rss: 9510MB -> 9510MB ( +0MB) unused_lib_feature_checking time: 4.444; rss: 9510MB -> 9568MB ( +58MB) crate_lints time: 59.563; rss: 9568MB -> 9576MB ( +8MB) module_lints time: 64.006; rss: 9510MB -> 9576MB ( +66MB) lint_checking time: 4.127; rss: 9576MB -> 9639MB ( +62MB) privacy_checking_modules time: 77.984; rss: 9301MB -> 9639MB ( +337MB) misc_checking_3 time: 0.311; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.051; rss: 10357MB -> 10573MB ( +217MB) monomorphization_collector_graph_walk time: 1.759; rss: 10573MB -> 10652MB ( +79MB) partition_and_assert_distinct_symbols time: 28.518; rss: 9639MB -> 10711MB (+1072MB) generate_crate_metadata time: 0.000; rss: 10711MB -> 10711MB ( +0MB) find_cgu_reuse time: 63.408; rss: 10711MB -> 12272MB (+1560MB) codegen_to_LLVM_IR time: 64.916; rss: 10711MB -> 12267MB (+1556MB) codegen_crate time: 0.000; rss: 12261MB -> 12261MB ( +0MB) assert_dep_graph time: 0.000; rss: 12261MB -> 12261MB ( +0MB) check_dirty_clean time: 0.664; rss: 12230MB -> 12210MB ( -20MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 2.111; rss: 12210MB -> 12043MB ( -167MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.108; rss: 12043MB -> 12057MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.004; rss: 12057MB -> 12059MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.665; rss: 12059MB -> 12121MB ( +62MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 16.149; rss: 12121MB -> 12148MB ( +28MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.010; rss: 12148MB -> 12150MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.052; rss: 12150MB -> 12155MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.003; rss: 12155MB -> 12156MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 11.428; rss: 12156MB -> 11748MB ( -408MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 11748MB -> 11748MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.094; rss: 11748MB -> 11756MB ( +8MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.272; rss: 11756MB -> 11778MB ( +22MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.054; rss: 11778MB -> 11778MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 11778MB -> 11779MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.021; rss: 11779MB -> 11784MB ( +5MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.041; rss: 11784MB -> 11786MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.743; rss: 11786MB -> 11815MB ( +29MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.043; rss: 11815MB -> 11816MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.674; rss: 11816MB -> 11840MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11840MB -> 11841MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 33.153; rss: 12232MB -> 11841MB ( -390MB) encode_query_results time: 88.943; rss: 11955MB -> 11783MB ( -173MB) LLVM_passes(crate) time: 38.854; rss: 12259MB -> 10095MB (-2164MB) incr_comp_serialize_result_cache time: 39.030; rss: 12261MB -> 10095MB (-2166MB) incr_comp_persist_result_cache time: 0.000; rss: 10095MB -> 10095MB ( +0MB) incr_comp_persist_dep_graph time: 39.064; rss: 12257MB -> 10095MB (-2162MB) serialize_dep_graph time: 19.047; rss: 10095MB -> 10307MB ( +212MB) free_global_ctxt time: 0.000; rss: 10307MB -> 10307MB ( +0MB) join_worker_thread time: 0.519; rss: 10307MB -> 10307MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.522; rss: 10307MB -> 10307MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10307MB -> 10307MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10307MB -> 10307MB ( +0MB) serialize_work_products time: 0.001; rss: 9542MB -> 9542MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9542MB -> 9542MB ( +0MB) link_binary_check_files_are_writeable time: 7.835; rss: 9542MB -> 9544MB ( +2MB) link_rlib time: 0.000; rss: 9544MB -> 9544MB ( +0MB) link_binary_remove_temps time: 7.872; rss: 9542MB -> 9544MB ( +2MB) link_binary time: 7.944; rss: 9542MB -> 9201MB ( -341MB) link_crate time: 8.495; rss: 10307MB -> 9201MB (-1106MB) link time: 537.014; rss: 33MB -> 3715MB (+3682MB) total ```
This PR (Click to Expand) ``` time: 2.379; rss: 51MB -> 1116MB (+1064MB) parse_crate time: 0.003; rss: 1116MB -> 1116MB ( +0MB) attributes_injection time: 0.002; rss: 1116MB -> 1116MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1116MB -> 1116MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_loading time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_registration time: 0.003; rss: 1118MB -> 1118MB ( +0MB) crate_injection time: 13.376; rss: 1118MB -> 3143MB (+2025MB) expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) check_unused_macros time: 13.379; rss: 1118MB -> 3143MB (+2025MB) macro_expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_building_test_harness time: 0.479; rss: 3143MB -> 3143MB ( +0MB) AST_validation time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_create_a_macro_crate time: 0.005; rss: 3143MB -> 3143MB ( +0MB) finalize_imports time: 0.520; rss: 3143MB -> 3125MB ( -18MB) finalize_macro_resolutions time: 4.446; rss: 3125MB -> 3577MB ( +453MB) late_resolve_crate time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_main time: 0.336; rss: 3577MB -> 3577MB ( +0MB) resolve_check_unused time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_report_errors time: 0.295; rss: 3577MB -> 3578MB ( +0MB) resolve_postprocess time: 5.602; rss: 3143MB -> 3578MB ( +435MB) resolve_crate time: 0.388; rss: 3578MB -> 3578MB ( +0MB) complete_gated_feature_checking time: 20.014; rss: 1116MB -> 3578MB (+2462MB) configure_and_expand time: 0.000; rss: 3578MB -> 3578MB ( +0MB) prepare_outputs time: 0.000; rss: 3578MB -> 3578MB ( +0MB) blocked_on_dep_graph_loading time: 64.219; rss: 3578MB -> 6313MB (+2736MB) hir_lowering time: 1.102; rss: 6313MB -> 6319MB ( +6MB) early_lint_checks time: 1.426; rss: 6319MB -> 6268MB ( -52MB) drop_ast time: 0.005; rss: 5834MB -> 5836MB ( +2MB) setup_global_ctxt time: 0.000; rss: 5838MB -> 5838MB ( +0MB) looking_for_entry_point time: 0.292; rss: 5838MB -> 5840MB ( +1MB) looking_for_derive_registrar time: 9.553; rss: 5838MB -> 6060MB ( +222MB) misc_checking_1 time: 9.949; rss: 6060MB -> 6764MB ( +704MB) type_collecting time: 0.630; rss: 6764MB -> 6764MB ( +0MB) impl_wf_inference time: 0.060; rss: 6764MB -> 6764MB ( +0MB) unsafety_checking time: 3.054; rss: 6764MB -> 6787MB ( +23MB) coherence_checking time: 20.702; rss: 6787MB -> 7533MB ( +746MB) wf_checking time: 5.194; rss: 7533MB -> 7668MB ( +135MB) item_types_checking time: 74.677; rss: 7668MB -> 8062MB ( +394MB) item_bodies_checking time: 114.497; rss: 6060MB -> 8068MB (+2008MB) type_check_crate time: 1.891; rss: 8068MB -> 8072MB ( +4MB) match_checking time: 1.292; rss: 8072MB -> 8100MB ( +28MB) liveness_and_intrinsic_checking time: 3.183; rss: 8068MB -> 8100MB ( +32MB) misc_checking_2 time: 68.845; rss: 8100MB -> 9279MB (+1179MB) MIR_borrow_checking time: 0.587; rss: 9279MB -> 9295MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9295MB -> 9295MB ( +0MB) layout_testing time: 4.443; rss: 9377MB -> 9504MB ( +127MB) death_checking time: 0.034; rss: 9504MB -> 9504MB ( +0MB) unused_lib_feature_checking time: 4.409; rss: 9504MB -> 9562MB ( +58MB) crate_lints time: 56.490; rss: 9562MB -> 9571MB ( +8MB) module_lints time: 60.900; rss: 9504MB -> 9571MB ( +66MB) lint_checking time: 4.147; rss: 9571MB -> 9633MB ( +62MB) privacy_checking_modules time: 75.094; rss: 9295MB -> 9633MB ( +337MB) misc_checking_3 time: 0.315; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.501; rss: 10357MB -> 10571MB ( +215MB) monomorphization_collector_graph_walk time: 1.763; rss: 10571MB -> 10661MB ( +89MB) partition_and_assert_distinct_symbols time: 29.035; rss: 9633MB -> 10706MB (+1073MB) generate_crate_metadata time: 0.000; rss: 10706MB -> 10706MB ( +0MB) find_cgu_reuse time: 30.913; rss: 10706MB -> 12150MB (+1444MB) codegen_to_LLVM_IR time: 31.108; rss: 10706MB -> 12150MB (+1444MB) codegen_crate time: 0.000; rss: 12150MB -> 12150MB ( +0MB) assert_dep_graph time: 0.000; rss: 12150MB -> 12150MB ( +0MB) check_dirty_clean time: 0.416; rss: 12152MB -> 12199MB ( +46MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 1.259; rss: 12199MB -> 12211MB ( +12MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.095; rss: 12211MB -> 12193MB ( -18MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.005; rss: 12193MB -> 12195MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.828; rss: 12195MB -> 12208MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 17.880; rss: 12208MB -> 11987MB ( -222MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.007; rss: 11987MB -> 11988MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.049; rss: 11988MB -> 11992MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.002; rss: 11992MB -> 11994MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 38.049; rss: 11994MB -> 12093MB ( +99MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 12093MB -> 12093MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.024; rss: 12093MB -> 12095MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.372; rss: 12095MB -> 12053MB ( -42MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.015; rss: 12053MB -> 12053MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 12053MB -> 12054MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.003; rss: 12054MB -> 12056MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.037; rss: 12056MB -> 11899MB ( -157MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.667; rss: 11899MB -> 11708MB ( -191MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.045; rss: 11708MB -> 11709MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.295; rss: 11709MB -> 11734MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11734MB -> 11734MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 60.063; rss: 12152MB -> 11734MB ( -418MB) encode_query_results time: 76.745; rss: 12007MB -> 11699MB ( -308MB) LLVM_passes(crate) time: 61.634; rss: 12150MB -> 10557MB (-1593MB) incr_comp_serialize_result_cache time: 61.637; rss: 12150MB -> 10557MB (-1593MB) incr_comp_persist_result_cache time: 0.001; rss: 10557MB -> 10557MB ( +0MB) incr_comp_persist_dep_graph time: 61.641; rss: 12150MB -> 10557MB (-1593MB) serialize_dep_graph time: 15.601; rss: 10557MB -> 10242MB ( -315MB) free_global_ctxt time: 0.000; rss: 10242MB -> 10242MB ( +0MB) join_worker_thread time: 0.368; rss: 10242MB -> 10242MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.375; rss: 10242MB -> 10242MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10242MB -> 10242MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10242MB -> 10242MB ( +0MB) serialize_work_products time: 0.001; rss: 9668MB -> 9668MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9668MB -> 9668MB ( +0MB) link_binary_check_files_are_writeable time: 1.469; rss: 9668MB -> 9671MB ( +3MB) link_rlib time: 0.000; rss: 9671MB -> 9671MB ( +0MB) link_binary_remove_temps time: 1.506; rss: 9668MB -> 9671MB ( +3MB) link_binary time: 1.622; rss: 9668MB -> 9329MB ( -339MB) link_crate time: 2.037; rss: 10242MB -> 9329MB ( -913MB) link time: 502.990; rss: 32MB -> 5888MB (+5855MB) total ```
(6.34% decrease in runtime results are consistent across multiple runs)",HOORAY,2021-11-27T17:39:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91266,MERGED,2021-11-26T21:06:42Z,2021-11-27T17:36:03Z,Use non-generic inner function for pointer formatting,jam1garner,073b1208f0389f89ade1e60401edc99c7a113a50,1,"Rollup merge of #91266 - jam1garner:fmt-ptr-fix r=dtolnay Use non-generic inner function for pointer formatting Previously despite the implementation being type-unaware `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects: * `fmt::Debug` for `*const T` * `fmt::Debug` for `*mut T` * `fmt::Pointer` for `*const T` * `fmt::Pointer` for `*mut T` And since the implementation is non-trivial this results in a large amount of LLVM bitcode being generated. For example with a large bindgen project with Debug implementations enabled it will generate a lot of calls to `fmt::Debug for *const T` which in turn will perform codegen for a copy of this function for every type. For example in a real-world bindgen'd header I've been testing with (4 189 245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
Nightly (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 7256000 (100%) 216544 (100%) (TOTAL) 1815449 (25.0%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 300248 (4.1%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (4.0%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 217746 (3.0%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 123329 (1.7%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.0%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.0%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (0.9%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.5%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.4%) 1493 (0.7%) core::array::::fmt 22290 (0.3%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.2%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
This PR (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 5684504 (100%) 216542 (100%) (TOTAL) 300248 (5.3%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (5.1%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 266265 (4.7%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 217746 (3.8%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 101039 (1.8%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.3%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.3%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (1.2%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.7%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.5%) 1493 (0.7%) core::array::::fmt 22290 (0.4%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.3%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.3%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.3%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
Output generated using `cargo llvm-lines` version 0.4.12. Summary of differences: | rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time | |-|-|-|-| | `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 | | PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 | This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM in this case and is significantly improved by disabling derives for `fmt::Debug` as it prevents generating all this LLVM IR to be handled. Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
nightly (Click to Expand) ``` time: 2.370; rss: 56MB -> 1118MB (+1062MB) parse_crate time: 0.000; rss: 1118MB -> 1118MB ( +0MB) attributes_injection time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_loading time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_registration time: 0.000; rss: 1120MB -> 1120MB ( +0MB) crate_injection time: 13.897; rss: 1120MB -> 3147MB (+2027MB) expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) check_unused_macros time: 13.900; rss: 1120MB -> 3147MB (+2027MB) macro_expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) maybe_building_test_harness time: 0.503; rss: 3147MB -> 3147MB ( +0MB) AST_validation time: 0.000; rss: 3147MB -> 3147MB ( +0MB) maybe_create_a_macro_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) finalize_imports time: 0.502; rss: 3147MB -> 3153MB ( +6MB) finalize_macro_resolutions time: 4.478; rss: 3153MB -> 3574MB ( +420MB) late_resolve_crate time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_main time: 0.332; rss: 3574MB -> 3574MB ( +0MB) resolve_check_unused time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_report_errors time: 0.279; rss: 3574MB -> 3574MB ( +0MB) resolve_postprocess time: 5.595; rss: 3147MB -> 3574MB ( +427MB) resolve_crate time: 0.382; rss: 3574MB -> 3574MB ( +0MB) complete_gated_feature_checking time: 20.526; rss: 1120MB -> 3574MB (+2454MB) configure_and_expand time: 0.000; rss: 3574MB -> 3574MB ( +0MB) prepare_outputs time: 0.000; rss: 3574MB -> 3574MB ( +0MB) blocked_on_dep_graph_loading time: 65.992; rss: 3574MB -> 6317MB (+2743MB) hir_lowering time: 1.117; rss: 6317MB -> 6323MB ( +6MB) early_lint_checks time: 1.447; rss: 6323MB -> 6271MB ( -52MB) drop_ast time: 0.002; rss: 5838MB -> 5838MB ( +0MB) setup_global_ctxt time: 0.000; rss: 5843MB -> 5843MB ( +0MB) looking_for_entry_point time: 0.313; rss: 5843MB -> 5844MB ( +1MB) looking_for_derive_registrar time: 9.652; rss: 5843MB -> 6065MB ( +222MB) misc_checking_1 time: 9.713; rss: 6065MB -> 6769MB ( +704MB) type_collecting time: 0.665; rss: 6769MB -> 6769MB ( +0MB) impl_wf_inference time: 0.064; rss: 6769MB -> 6769MB ( +0MB) unsafety_checking time: 3.095; rss: 6769MB -> 6792MB ( +23MB) coherence_checking time: 21.282; rss: 6792MB -> 7546MB ( +754MB) wf_checking time: 5.404; rss: 7546MB -> 7681MB ( +135MB) item_types_checking time: 79.665; rss: 7681MB -> 8075MB ( +394MB) item_bodies_checking time: 120.166; rss: 6065MB -> 8081MB (+2016MB) type_check_crate time: 2.038; rss: 8081MB -> 8085MB ( +4MB) match_checking time: 1.300; rss: 8085MB -> 8113MB ( +28MB) liveness_and_intrinsic_checking time: 3.338; rss: 8081MB -> 8113MB ( +32MB) misc_checking_2 time: 68.612; rss: 8113MB -> 9285MB (+1172MB) MIR_borrow_checking time: 0.622; rss: 9285MB -> 9301MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9301MB -> 9301MB ( +0MB) layout_testing time: 4.331; rss: 9383MB -> 9510MB ( +127MB) death_checking time: 0.032; rss: 9510MB -> 9510MB ( +0MB) unused_lib_feature_checking time: 4.444; rss: 9510MB -> 9568MB ( +58MB) crate_lints time: 59.563; rss: 9568MB -> 9576MB ( +8MB) module_lints time: 64.006; rss: 9510MB -> 9576MB ( +66MB) lint_checking time: 4.127; rss: 9576MB -> 9639MB ( +62MB) privacy_checking_modules time: 77.984; rss: 9301MB -> 9639MB ( +337MB) misc_checking_3 time: 0.311; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.051; rss: 10357MB -> 10573MB ( +217MB) monomorphization_collector_graph_walk time: 1.759; rss: 10573MB -> 10652MB ( +79MB) partition_and_assert_distinct_symbols time: 28.518; rss: 9639MB -> 10711MB (+1072MB) generate_crate_metadata time: 0.000; rss: 10711MB -> 10711MB ( +0MB) find_cgu_reuse time: 63.408; rss: 10711MB -> 12272MB (+1560MB) codegen_to_LLVM_IR time: 64.916; rss: 10711MB -> 12267MB (+1556MB) codegen_crate time: 0.000; rss: 12261MB -> 12261MB ( +0MB) assert_dep_graph time: 0.000; rss: 12261MB -> 12261MB ( +0MB) check_dirty_clean time: 0.664; rss: 12230MB -> 12210MB ( -20MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 2.111; rss: 12210MB -> 12043MB ( -167MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.108; rss: 12043MB -> 12057MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.004; rss: 12057MB -> 12059MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.665; rss: 12059MB -> 12121MB ( +62MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 16.149; rss: 12121MB -> 12148MB ( +28MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.010; rss: 12148MB -> 12150MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.052; rss: 12150MB -> 12155MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.003; rss: 12155MB -> 12156MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 11.428; rss: 12156MB -> 11748MB ( -408MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 11748MB -> 11748MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.094; rss: 11748MB -> 11756MB ( +8MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.272; rss: 11756MB -> 11778MB ( +22MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.054; rss: 11778MB -> 11778MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 11778MB -> 11779MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.021; rss: 11779MB -> 11784MB ( +5MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.041; rss: 11784MB -> 11786MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.743; rss: 11786MB -> 11815MB ( +29MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.043; rss: 11815MB -> 11816MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.674; rss: 11816MB -> 11840MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11840MB -> 11841MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 33.153; rss: 12232MB -> 11841MB ( -390MB) encode_query_results time: 88.943; rss: 11955MB -> 11783MB ( -173MB) LLVM_passes(crate) time: 38.854; rss: 12259MB -> 10095MB (-2164MB) incr_comp_serialize_result_cache time: 39.030; rss: 12261MB -> 10095MB (-2166MB) incr_comp_persist_result_cache time: 0.000; rss: 10095MB -> 10095MB ( +0MB) incr_comp_persist_dep_graph time: 39.064; rss: 12257MB -> 10095MB (-2162MB) serialize_dep_graph time: 19.047; rss: 10095MB -> 10307MB ( +212MB) free_global_ctxt time: 0.000; rss: 10307MB -> 10307MB ( +0MB) join_worker_thread time: 0.519; rss: 10307MB -> 10307MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.522; rss: 10307MB -> 10307MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10307MB -> 10307MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10307MB -> 10307MB ( +0MB) serialize_work_products time: 0.001; rss: 9542MB -> 9542MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9542MB -> 9542MB ( +0MB) link_binary_check_files_are_writeable time: 7.835; rss: 9542MB -> 9544MB ( +2MB) link_rlib time: 0.000; rss: 9544MB -> 9544MB ( +0MB) link_binary_remove_temps time: 7.872; rss: 9542MB -> 9544MB ( +2MB) link_binary time: 7.944; rss: 9542MB -> 9201MB ( -341MB) link_crate time: 8.495; rss: 10307MB -> 9201MB (-1106MB) link time: 537.014; rss: 33MB -> 3715MB (+3682MB) total ```
This PR (Click to Expand) ``` time: 2.379; rss: 51MB -> 1116MB (+1064MB) parse_crate time: 0.003; rss: 1116MB -> 1116MB ( +0MB) attributes_injection time: 0.002; rss: 1116MB -> 1116MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1116MB -> 1116MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_loading time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_registration time: 0.003; rss: 1118MB -> 1118MB ( +0MB) crate_injection time: 13.376; rss: 1118MB -> 3143MB (+2025MB) expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) check_unused_macros time: 13.379; rss: 1118MB -> 3143MB (+2025MB) macro_expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_building_test_harness time: 0.479; rss: 3143MB -> 3143MB ( +0MB) AST_validation time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_create_a_macro_crate time: 0.005; rss: 3143MB -> 3143MB ( +0MB) finalize_imports time: 0.520; rss: 3143MB -> 3125MB ( -18MB) finalize_macro_resolutions time: 4.446; rss: 3125MB -> 3577MB ( +453MB) late_resolve_crate time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_main time: 0.336; rss: 3577MB -> 3577MB ( +0MB) resolve_check_unused time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_report_errors time: 0.295; rss: 3577MB -> 3578MB ( +0MB) resolve_postprocess time: 5.602; rss: 3143MB -> 3578MB ( +435MB) resolve_crate time: 0.388; rss: 3578MB -> 3578MB ( +0MB) complete_gated_feature_checking time: 20.014; rss: 1116MB -> 3578MB (+2462MB) configure_and_expand time: 0.000; rss: 3578MB -> 3578MB ( +0MB) prepare_outputs time: 0.000; rss: 3578MB -> 3578MB ( +0MB) blocked_on_dep_graph_loading time: 64.219; rss: 3578MB -> 6313MB (+2736MB) hir_lowering time: 1.102; rss: 6313MB -> 6319MB ( +6MB) early_lint_checks time: 1.426; rss: 6319MB -> 6268MB ( -52MB) drop_ast time: 0.005; rss: 5834MB -> 5836MB ( +2MB) setup_global_ctxt time: 0.000; rss: 5838MB -> 5838MB ( +0MB) looking_for_entry_point time: 0.292; rss: 5838MB -> 5840MB ( +1MB) looking_for_derive_registrar time: 9.553; rss: 5838MB -> 6060MB ( +222MB) misc_checking_1 time: 9.949; rss: 6060MB -> 6764MB ( +704MB) type_collecting time: 0.630; rss: 6764MB -> 6764MB ( +0MB) impl_wf_inference time: 0.060; rss: 6764MB -> 6764MB ( +0MB) unsafety_checking time: 3.054; rss: 6764MB -> 6787MB ( +23MB) coherence_checking time: 20.702; rss: 6787MB -> 7533MB ( +746MB) wf_checking time: 5.194; rss: 7533MB -> 7668MB ( +135MB) item_types_checking time: 74.677; rss: 7668MB -> 8062MB ( +394MB) item_bodies_checking time: 114.497; rss: 6060MB -> 8068MB (+2008MB) type_check_crate time: 1.891; rss: 8068MB -> 8072MB ( +4MB) match_checking time: 1.292; rss: 8072MB -> 8100MB ( +28MB) liveness_and_intrinsic_checking time: 3.183; rss: 8068MB -> 8100MB ( +32MB) misc_checking_2 time: 68.845; rss: 8100MB -> 9279MB (+1179MB) MIR_borrow_checking time: 0.587; rss: 9279MB -> 9295MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9295MB -> 9295MB ( +0MB) layout_testing time: 4.443; rss: 9377MB -> 9504MB ( +127MB) death_checking time: 0.034; rss: 9504MB -> 9504MB ( +0MB) unused_lib_feature_checking time: 4.409; rss: 9504MB -> 9562MB ( +58MB) crate_lints time: 56.490; rss: 9562MB -> 9571MB ( +8MB) module_lints time: 60.900; rss: 9504MB -> 9571MB ( +66MB) lint_checking time: 4.147; rss: 9571MB -> 9633MB ( +62MB) privacy_checking_modules time: 75.094; rss: 9295MB -> 9633MB ( +337MB) misc_checking_3 time: 0.315; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.501; rss: 10357MB -> 10571MB ( +215MB) monomorphization_collector_graph_walk time: 1.763; rss: 10571MB -> 10661MB ( +89MB) partition_and_assert_distinct_symbols time: 29.035; rss: 9633MB -> 10706MB (+1073MB) generate_crate_metadata time: 0.000; rss: 10706MB -> 10706MB ( +0MB) find_cgu_reuse time: 30.913; rss: 10706MB -> 12150MB (+1444MB) codegen_to_LLVM_IR time: 31.108; rss: 10706MB -> 12150MB (+1444MB) codegen_crate time: 0.000; rss: 12150MB -> 12150MB ( +0MB) assert_dep_graph time: 0.000; rss: 12150MB -> 12150MB ( +0MB) check_dirty_clean time: 0.416; rss: 12152MB -> 12199MB ( +46MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 1.259; rss: 12199MB -> 12211MB ( +12MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.095; rss: 12211MB -> 12193MB ( -18MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.005; rss: 12193MB -> 12195MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.828; rss: 12195MB -> 12208MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 17.880; rss: 12208MB -> 11987MB ( -222MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.007; rss: 11987MB -> 11988MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.049; rss: 11988MB -> 11992MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.002; rss: 11992MB -> 11994MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 38.049; rss: 11994MB -> 12093MB ( +99MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 12093MB -> 12093MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.024; rss: 12093MB -> 12095MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.372; rss: 12095MB -> 12053MB ( -42MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.015; rss: 12053MB -> 12053MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 12053MB -> 12054MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.003; rss: 12054MB -> 12056MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.037; rss: 12056MB -> 11899MB ( -157MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.667; rss: 11899MB -> 11708MB ( -191MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.045; rss: 11708MB -> 11709MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.295; rss: 11709MB -> 11734MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11734MB -> 11734MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 60.063; rss: 12152MB -> 11734MB ( -418MB) encode_query_results time: 76.745; rss: 12007MB -> 11699MB ( -308MB) LLVM_passes(crate) time: 61.634; rss: 12150MB -> 10557MB (-1593MB) incr_comp_serialize_result_cache time: 61.637; rss: 12150MB -> 10557MB (-1593MB) incr_comp_persist_result_cache time: 0.001; rss: 10557MB -> 10557MB ( +0MB) incr_comp_persist_dep_graph time: 61.641; rss: 12150MB -> 10557MB (-1593MB) serialize_dep_graph time: 15.601; rss: 10557MB -> 10242MB ( -315MB) free_global_ctxt time: 0.000; rss: 10242MB -> 10242MB ( +0MB) join_worker_thread time: 0.368; rss: 10242MB -> 10242MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.375; rss: 10242MB -> 10242MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10242MB -> 10242MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10242MB -> 10242MB ( +0MB) serialize_work_products time: 0.001; rss: 9668MB -> 9668MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9668MB -> 9668MB ( +0MB) link_binary_check_files_are_writeable time: 1.469; rss: 9668MB -> 9671MB ( +3MB) link_rlib time: 0.000; rss: 9671MB -> 9671MB ( +0MB) link_binary_remove_temps time: 1.506; rss: 9668MB -> 9671MB ( +3MB) link_binary time: 1.622; rss: 9668MB -> 9329MB ( -339MB) link_crate time: 2.037; rss: 10242MB -> 9329MB ( -913MB) link time: 502.990; rss: 32MB -> 5888MB (+5855MB) total ```
(6.34% decrease in runtime results are consistent across multiple runs)",HOORAY,2021-11-27T19:36:49Z,nnethercote,NA https://github.com/rust-lang/rust/pull/91266,MERGED,2021-11-26T21:06:42Z,2021-11-27T17:36:03Z,Use non-generic inner function for pointer formatting,jam1garner,073b1208f0389f89ade1e60401edc99c7a113a50,1,"Rollup merge of #91266 - jam1garner:fmt-ptr-fix r=dtolnay Use non-generic inner function for pointer formatting Previously despite the implementation being type-unaware `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects: * `fmt::Debug` for `*const T` * `fmt::Debug` for `*mut T` * `fmt::Pointer` for `*const T` * `fmt::Pointer` for `*mut T` And since the implementation is non-trivial this results in a large amount of LLVM bitcode being generated. For example with a large bindgen project with Debug implementations enabled it will generate a lot of calls to `fmt::Debug for *const T` which in turn will perform codegen for a copy of this function for every type. For example in a real-world bindgen'd header I've been testing with (4 189 245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
Nightly (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 7256000 (100%) 216544 (100%) (TOTAL) 1815449 (25.0%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 300248 (4.1%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (4.0%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 217746 (3.0%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 123329 (1.7%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.0%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.0%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (0.9%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.5%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.4%) 1493 (0.7%) core::array::::fmt 22290 (0.3%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.2%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
This PR (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 5684504 (100%) 216542 (100%) (TOTAL) 300248 (5.3%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (5.1%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 266265 (4.7%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 217746 (3.8%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 101039 (1.8%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.3%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.3%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (1.2%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.7%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.5%) 1493 (0.7%) core::array::::fmt 22290 (0.4%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.3%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.3%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.3%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
Output generated using `cargo llvm-lines` version 0.4.12. Summary of differences: | rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time | |-|-|-|-| | `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 | | PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 | This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM in this case and is significantly improved by disabling derives for `fmt::Debug` as it prevents generating all this LLVM IR to be handled. Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
nightly (Click to Expand) ``` time: 2.370; rss: 56MB -> 1118MB (+1062MB) parse_crate time: 0.000; rss: 1118MB -> 1118MB ( +0MB) attributes_injection time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_loading time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_registration time: 0.000; rss: 1120MB -> 1120MB ( +0MB) crate_injection time: 13.897; rss: 1120MB -> 3147MB (+2027MB) expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) check_unused_macros time: 13.900; rss: 1120MB -> 3147MB (+2027MB) macro_expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) maybe_building_test_harness time: 0.503; rss: 3147MB -> 3147MB ( +0MB) AST_validation time: 0.000; rss: 3147MB -> 3147MB ( +0MB) maybe_create_a_macro_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) finalize_imports time: 0.502; rss: 3147MB -> 3153MB ( +6MB) finalize_macro_resolutions time: 4.478; rss: 3153MB -> 3574MB ( +420MB) late_resolve_crate time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_main time: 0.332; rss: 3574MB -> 3574MB ( +0MB) resolve_check_unused time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_report_errors time: 0.279; rss: 3574MB -> 3574MB ( +0MB) resolve_postprocess time: 5.595; rss: 3147MB -> 3574MB ( +427MB) resolve_crate time: 0.382; rss: 3574MB -> 3574MB ( +0MB) complete_gated_feature_checking time: 20.526; rss: 1120MB -> 3574MB (+2454MB) configure_and_expand time: 0.000; rss: 3574MB -> 3574MB ( +0MB) prepare_outputs time: 0.000; rss: 3574MB -> 3574MB ( +0MB) blocked_on_dep_graph_loading time: 65.992; rss: 3574MB -> 6317MB (+2743MB) hir_lowering time: 1.117; rss: 6317MB -> 6323MB ( +6MB) early_lint_checks time: 1.447; rss: 6323MB -> 6271MB ( -52MB) drop_ast time: 0.002; rss: 5838MB -> 5838MB ( +0MB) setup_global_ctxt time: 0.000; rss: 5843MB -> 5843MB ( +0MB) looking_for_entry_point time: 0.313; rss: 5843MB -> 5844MB ( +1MB) looking_for_derive_registrar time: 9.652; rss: 5843MB -> 6065MB ( +222MB) misc_checking_1 time: 9.713; rss: 6065MB -> 6769MB ( +704MB) type_collecting time: 0.665; rss: 6769MB -> 6769MB ( +0MB) impl_wf_inference time: 0.064; rss: 6769MB -> 6769MB ( +0MB) unsafety_checking time: 3.095; rss: 6769MB -> 6792MB ( +23MB) coherence_checking time: 21.282; rss: 6792MB -> 7546MB ( +754MB) wf_checking time: 5.404; rss: 7546MB -> 7681MB ( +135MB) item_types_checking time: 79.665; rss: 7681MB -> 8075MB ( +394MB) item_bodies_checking time: 120.166; rss: 6065MB -> 8081MB (+2016MB) type_check_crate time: 2.038; rss: 8081MB -> 8085MB ( +4MB) match_checking time: 1.300; rss: 8085MB -> 8113MB ( +28MB) liveness_and_intrinsic_checking time: 3.338; rss: 8081MB -> 8113MB ( +32MB) misc_checking_2 time: 68.612; rss: 8113MB -> 9285MB (+1172MB) MIR_borrow_checking time: 0.622; rss: 9285MB -> 9301MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9301MB -> 9301MB ( +0MB) layout_testing time: 4.331; rss: 9383MB -> 9510MB ( +127MB) death_checking time: 0.032; rss: 9510MB -> 9510MB ( +0MB) unused_lib_feature_checking time: 4.444; rss: 9510MB -> 9568MB ( +58MB) crate_lints time: 59.563; rss: 9568MB -> 9576MB ( +8MB) module_lints time: 64.006; rss: 9510MB -> 9576MB ( +66MB) lint_checking time: 4.127; rss: 9576MB -> 9639MB ( +62MB) privacy_checking_modules time: 77.984; rss: 9301MB -> 9639MB ( +337MB) misc_checking_3 time: 0.311; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.051; rss: 10357MB -> 10573MB ( +217MB) monomorphization_collector_graph_walk time: 1.759; rss: 10573MB -> 10652MB ( +79MB) partition_and_assert_distinct_symbols time: 28.518; rss: 9639MB -> 10711MB (+1072MB) generate_crate_metadata time: 0.000; rss: 10711MB -> 10711MB ( +0MB) find_cgu_reuse time: 63.408; rss: 10711MB -> 12272MB (+1560MB) codegen_to_LLVM_IR time: 64.916; rss: 10711MB -> 12267MB (+1556MB) codegen_crate time: 0.000; rss: 12261MB -> 12261MB ( +0MB) assert_dep_graph time: 0.000; rss: 12261MB -> 12261MB ( +0MB) check_dirty_clean time: 0.664; rss: 12230MB -> 12210MB ( -20MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 2.111; rss: 12210MB -> 12043MB ( -167MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.108; rss: 12043MB -> 12057MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.004; rss: 12057MB -> 12059MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.665; rss: 12059MB -> 12121MB ( +62MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 16.149; rss: 12121MB -> 12148MB ( +28MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.010; rss: 12148MB -> 12150MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.052; rss: 12150MB -> 12155MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.003; rss: 12155MB -> 12156MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 11.428; rss: 12156MB -> 11748MB ( -408MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 11748MB -> 11748MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.094; rss: 11748MB -> 11756MB ( +8MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.272; rss: 11756MB -> 11778MB ( +22MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.054; rss: 11778MB -> 11778MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 11778MB -> 11779MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.021; rss: 11779MB -> 11784MB ( +5MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.041; rss: 11784MB -> 11786MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.743; rss: 11786MB -> 11815MB ( +29MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.043; rss: 11815MB -> 11816MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.674; rss: 11816MB -> 11840MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11840MB -> 11841MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 33.153; rss: 12232MB -> 11841MB ( -390MB) encode_query_results time: 88.943; rss: 11955MB -> 11783MB ( -173MB) LLVM_passes(crate) time: 38.854; rss: 12259MB -> 10095MB (-2164MB) incr_comp_serialize_result_cache time: 39.030; rss: 12261MB -> 10095MB (-2166MB) incr_comp_persist_result_cache time: 0.000; rss: 10095MB -> 10095MB ( +0MB) incr_comp_persist_dep_graph time: 39.064; rss: 12257MB -> 10095MB (-2162MB) serialize_dep_graph time: 19.047; rss: 10095MB -> 10307MB ( +212MB) free_global_ctxt time: 0.000; rss: 10307MB -> 10307MB ( +0MB) join_worker_thread time: 0.519; rss: 10307MB -> 10307MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.522; rss: 10307MB -> 10307MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10307MB -> 10307MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10307MB -> 10307MB ( +0MB) serialize_work_products time: 0.001; rss: 9542MB -> 9542MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9542MB -> 9542MB ( +0MB) link_binary_check_files_are_writeable time: 7.835; rss: 9542MB -> 9544MB ( +2MB) link_rlib time: 0.000; rss: 9544MB -> 9544MB ( +0MB) link_binary_remove_temps time: 7.872; rss: 9542MB -> 9544MB ( +2MB) link_binary time: 7.944; rss: 9542MB -> 9201MB ( -341MB) link_crate time: 8.495; rss: 10307MB -> 9201MB (-1106MB) link time: 537.014; rss: 33MB -> 3715MB (+3682MB) total ```
This PR (Click to Expand) ``` time: 2.379; rss: 51MB -> 1116MB (+1064MB) parse_crate time: 0.003; rss: 1116MB -> 1116MB ( +0MB) attributes_injection time: 0.002; rss: 1116MB -> 1116MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1116MB -> 1116MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_loading time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_registration time: 0.003; rss: 1118MB -> 1118MB ( +0MB) crate_injection time: 13.376; rss: 1118MB -> 3143MB (+2025MB) expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) check_unused_macros time: 13.379; rss: 1118MB -> 3143MB (+2025MB) macro_expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_building_test_harness time: 0.479; rss: 3143MB -> 3143MB ( +0MB) AST_validation time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_create_a_macro_crate time: 0.005; rss: 3143MB -> 3143MB ( +0MB) finalize_imports time: 0.520; rss: 3143MB -> 3125MB ( -18MB) finalize_macro_resolutions time: 4.446; rss: 3125MB -> 3577MB ( +453MB) late_resolve_crate time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_main time: 0.336; rss: 3577MB -> 3577MB ( +0MB) resolve_check_unused time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_report_errors time: 0.295; rss: 3577MB -> 3578MB ( +0MB) resolve_postprocess time: 5.602; rss: 3143MB -> 3578MB ( +435MB) resolve_crate time: 0.388; rss: 3578MB -> 3578MB ( +0MB) complete_gated_feature_checking time: 20.014; rss: 1116MB -> 3578MB (+2462MB) configure_and_expand time: 0.000; rss: 3578MB -> 3578MB ( +0MB) prepare_outputs time: 0.000; rss: 3578MB -> 3578MB ( +0MB) blocked_on_dep_graph_loading time: 64.219; rss: 3578MB -> 6313MB (+2736MB) hir_lowering time: 1.102; rss: 6313MB -> 6319MB ( +6MB) early_lint_checks time: 1.426; rss: 6319MB -> 6268MB ( -52MB) drop_ast time: 0.005; rss: 5834MB -> 5836MB ( +2MB) setup_global_ctxt time: 0.000; rss: 5838MB -> 5838MB ( +0MB) looking_for_entry_point time: 0.292; rss: 5838MB -> 5840MB ( +1MB) looking_for_derive_registrar time: 9.553; rss: 5838MB -> 6060MB ( +222MB) misc_checking_1 time: 9.949; rss: 6060MB -> 6764MB ( +704MB) type_collecting time: 0.630; rss: 6764MB -> 6764MB ( +0MB) impl_wf_inference time: 0.060; rss: 6764MB -> 6764MB ( +0MB) unsafety_checking time: 3.054; rss: 6764MB -> 6787MB ( +23MB) coherence_checking time: 20.702; rss: 6787MB -> 7533MB ( +746MB) wf_checking time: 5.194; rss: 7533MB -> 7668MB ( +135MB) item_types_checking time: 74.677; rss: 7668MB -> 8062MB ( +394MB) item_bodies_checking time: 114.497; rss: 6060MB -> 8068MB (+2008MB) type_check_crate time: 1.891; rss: 8068MB -> 8072MB ( +4MB) match_checking time: 1.292; rss: 8072MB -> 8100MB ( +28MB) liveness_and_intrinsic_checking time: 3.183; rss: 8068MB -> 8100MB ( +32MB) misc_checking_2 time: 68.845; rss: 8100MB -> 9279MB (+1179MB) MIR_borrow_checking time: 0.587; rss: 9279MB -> 9295MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9295MB -> 9295MB ( +0MB) layout_testing time: 4.443; rss: 9377MB -> 9504MB ( +127MB) death_checking time: 0.034; rss: 9504MB -> 9504MB ( +0MB) unused_lib_feature_checking time: 4.409; rss: 9504MB -> 9562MB ( +58MB) crate_lints time: 56.490; rss: 9562MB -> 9571MB ( +8MB) module_lints time: 60.900; rss: 9504MB -> 9571MB ( +66MB) lint_checking time: 4.147; rss: 9571MB -> 9633MB ( +62MB) privacy_checking_modules time: 75.094; rss: 9295MB -> 9633MB ( +337MB) misc_checking_3 time: 0.315; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.501; rss: 10357MB -> 10571MB ( +215MB) monomorphization_collector_graph_walk time: 1.763; rss: 10571MB -> 10661MB ( +89MB) partition_and_assert_distinct_symbols time: 29.035; rss: 9633MB -> 10706MB (+1073MB) generate_crate_metadata time: 0.000; rss: 10706MB -> 10706MB ( +0MB) find_cgu_reuse time: 30.913; rss: 10706MB -> 12150MB (+1444MB) codegen_to_LLVM_IR time: 31.108; rss: 10706MB -> 12150MB (+1444MB) codegen_crate time: 0.000; rss: 12150MB -> 12150MB ( +0MB) assert_dep_graph time: 0.000; rss: 12150MB -> 12150MB ( +0MB) check_dirty_clean time: 0.416; rss: 12152MB -> 12199MB ( +46MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 1.259; rss: 12199MB -> 12211MB ( +12MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.095; rss: 12211MB -> 12193MB ( -18MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.005; rss: 12193MB -> 12195MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.828; rss: 12195MB -> 12208MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 17.880; rss: 12208MB -> 11987MB ( -222MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.007; rss: 11987MB -> 11988MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.049; rss: 11988MB -> 11992MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.002; rss: 11992MB -> 11994MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 38.049; rss: 11994MB -> 12093MB ( +99MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 12093MB -> 12093MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.024; rss: 12093MB -> 12095MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.372; rss: 12095MB -> 12053MB ( -42MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.015; rss: 12053MB -> 12053MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 12053MB -> 12054MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.003; rss: 12054MB -> 12056MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.037; rss: 12056MB -> 11899MB ( -157MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.667; rss: 11899MB -> 11708MB ( -191MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.045; rss: 11708MB -> 11709MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.295; rss: 11709MB -> 11734MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11734MB -> 11734MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 60.063; rss: 12152MB -> 11734MB ( -418MB) encode_query_results time: 76.745; rss: 12007MB -> 11699MB ( -308MB) LLVM_passes(crate) time: 61.634; rss: 12150MB -> 10557MB (-1593MB) incr_comp_serialize_result_cache time: 61.637; rss: 12150MB -> 10557MB (-1593MB) incr_comp_persist_result_cache time: 0.001; rss: 10557MB -> 10557MB ( +0MB) incr_comp_persist_dep_graph time: 61.641; rss: 12150MB -> 10557MB (-1593MB) serialize_dep_graph time: 15.601; rss: 10557MB -> 10242MB ( -315MB) free_global_ctxt time: 0.000; rss: 10242MB -> 10242MB ( +0MB) join_worker_thread time: 0.368; rss: 10242MB -> 10242MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.375; rss: 10242MB -> 10242MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10242MB -> 10242MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10242MB -> 10242MB ( +0MB) serialize_work_products time: 0.001; rss: 9668MB -> 9668MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9668MB -> 9668MB ( +0MB) link_binary_check_files_are_writeable time: 1.469; rss: 9668MB -> 9671MB ( +3MB) link_rlib time: 0.000; rss: 9671MB -> 9671MB ( +0MB) link_binary_remove_temps time: 1.506; rss: 9668MB -> 9671MB ( +3MB) link_binary time: 1.622; rss: 9668MB -> 9329MB ( -339MB) link_crate time: 2.037; rss: 10242MB -> 9329MB ( -913MB) link time: 502.990; rss: 32MB -> 5888MB (+5855MB) total ```
(6.34% decrease in runtime results are consistent across multiple runs)",HOORAY,2021-11-28T10:14:33Z,EkremDincel,NA https://github.com/rust-lang/rust/pull/91266,MERGED,2021-11-26T21:06:42Z,2021-11-27T17:36:03Z,Use non-generic inner function for pointer formatting,jam1garner,073b1208f0389f89ade1e60401edc99c7a113a50,1,"Rollup merge of #91266 - jam1garner:fmt-ptr-fix r=dtolnay Use non-generic inner function for pointer formatting Previously despite the implementation being type-unaware `fmt::Pointer`'s implementation for `*const T` in monomorphized. This affects: * `fmt::Debug` for `*const T` * `fmt::Debug` for `*mut T` * `fmt::Pointer` for `*const T` * `fmt::Pointer` for `*mut T` And since the implementation is non-trivial this results in a large amount of LLVM bitcode being generated. For example with a large bindgen project with Debug implementations enabled it will generate a lot of calls to `fmt::Debug for *const T` which in turn will perform codegen for a copy of this function for every type. For example in a real-world bindgen'd header I've been testing with (4 189 245 lines of bindgen Rust with layout tests disabled) the difference between a slightly old nightly (`rustc 1.58.0-nightly (e249ce6b2 2021-10-30)`) and this PR:
Nightly (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 7256000 (100%) 216544 (100%) (TOTAL) 1815449 (25.0%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 300248 (4.1%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (4.0%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 217746 (3.0%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 123329 (1.7%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.0%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.0%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (0.9%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.5%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.4%) 1493 (0.7%) core::array::::fmt 22290 (0.3%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.2%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
This PR (Click to Expand) ``` Lines Copies Function name ----- ------ ------------- 5684504 (100%) 216542 (100%) (TOTAL) 300248 (5.3%) 29579 (13.7%) <&T as core::fmt::Debug>::fmt 290328 (5.1%) 24194 (11.2%) <*mut T as core::fmt::Pointer>::fmt 266265 (4.7%) 24206 (11.2%) <*const T as core::fmt::Pointer>::fmt 217746 (3.8%) 24194 (11.2%) <*mut T as core::fmt::Debug>::fmt 101039 (1.8%) 1486 (0.7%) core::fmt::builders::DebugList::entries 72790 (1.3%) 1486 (0.7%) core::slice::iter::Iter::post_inc_start 71313 (1.3%) 1486 (0.7%) core::slice::iter::Iter::new 68329 (1.2%) 1486 (0.7%) as core::iter::traits::iterator::Iterator>::next 38636 (0.7%) 1486 (0.7%) <[T] as core::fmt::Debug>::fmt 26874 (0.5%) 1493 (0.7%) core::array::::fmt 22290 (0.4%) 1486 (0.7%) core::slice::index:: for [T]>::index 19407 (0.3%) 1493 (0.7%) core::array:: for [T; N]>::index 19318 (0.3%) 1486 (0.7%) core::slice::::iter 17832 (0.3%) 1486 (0.7%) core::ptr::const_ptr::::offset 17832 (0.3%) 1486 (0.7%) core::ptr::mut_ptr::::offset 16346 (0.3%) 1486 (0.7%) >::index 13374 (0.2%) 1486 (0.7%) ::into_iter 13374 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::add 13371 (0.2%) 1486 (0.7%) core::ptr::const_ptr::::is_null 13371 (0.2%) 1486 (0.7%) core::ptr::mut_ptr::::is_null 11888 (0.2%) 1486 (0.7%) core::slice::::as_ptr 11879 (0.2%) 1486 (0.7%) core::ptr::non_null::NonNull::new_unchecked 7421 (0.1%) 1486 (0.7%) core::ptr::non_null::NonNull::as_ptr ```
Output generated using `cargo llvm-lines` version 0.4.12. Summary of differences: | rustc Version | Total LLVM line count | `*const T as fmt::Pointer` LLVM lines | Compilation Time | |-|-|-|-| | `nightly` | 7256000 | 1815449 (25.0% of binary) | 537.014 | | PR | 5684504 (-21.65%) | 266265 (4.7% of binary) (-85.3% from nightly) | 502.990 | This results in a pretty noticeable as the majority of rustc's time is spent in either codegen or LLVM in this case and is significantly improved by disabling derives for `fmt::Debug` as it prevents generating all this LLVM IR to be handled. Here's a run time comparison with nightly on the same codebase (commit 454cc5fb built from source vs 37c8f25 from my PR built from source):
nightly (Click to Expand) ``` time: 2.370; rss: 56MB -> 1118MB (+1062MB) parse_crate time: 0.000; rss: 1118MB -> 1118MB ( +0MB) attributes_injection time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1118MB -> 1118MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_loading time: 0.000; rss: 1120MB -> 1120MB ( +0MB) plugin_registration time: 0.000; rss: 1120MB -> 1120MB ( +0MB) crate_injection time: 13.897; rss: 1120MB -> 3147MB (+2027MB) expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) check_unused_macros time: 13.900; rss: 1120MB -> 3147MB (+2027MB) macro_expand_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) maybe_building_test_harness time: 0.503; rss: 3147MB -> 3147MB ( +0MB) AST_validation time: 0.000; rss: 3147MB -> 3147MB ( +0MB) maybe_create_a_macro_crate time: 0.002; rss: 3147MB -> 3147MB ( +0MB) finalize_imports time: 0.502; rss: 3147MB -> 3153MB ( +6MB) finalize_macro_resolutions time: 4.478; rss: 3153MB -> 3574MB ( +420MB) late_resolve_crate time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_main time: 0.332; rss: 3574MB -> 3574MB ( +0MB) resolve_check_unused time: 0.000; rss: 3574MB -> 3574MB ( +0MB) resolve_report_errors time: 0.279; rss: 3574MB -> 3574MB ( +0MB) resolve_postprocess time: 5.595; rss: 3147MB -> 3574MB ( +427MB) resolve_crate time: 0.382; rss: 3574MB -> 3574MB ( +0MB) complete_gated_feature_checking time: 20.526; rss: 1120MB -> 3574MB (+2454MB) configure_and_expand time: 0.000; rss: 3574MB -> 3574MB ( +0MB) prepare_outputs time: 0.000; rss: 3574MB -> 3574MB ( +0MB) blocked_on_dep_graph_loading time: 65.992; rss: 3574MB -> 6317MB (+2743MB) hir_lowering time: 1.117; rss: 6317MB -> 6323MB ( +6MB) early_lint_checks time: 1.447; rss: 6323MB -> 6271MB ( -52MB) drop_ast time: 0.002; rss: 5838MB -> 5838MB ( +0MB) setup_global_ctxt time: 0.000; rss: 5843MB -> 5843MB ( +0MB) looking_for_entry_point time: 0.313; rss: 5843MB -> 5844MB ( +1MB) looking_for_derive_registrar time: 9.652; rss: 5843MB -> 6065MB ( +222MB) misc_checking_1 time: 9.713; rss: 6065MB -> 6769MB ( +704MB) type_collecting time: 0.665; rss: 6769MB -> 6769MB ( +0MB) impl_wf_inference time: 0.064; rss: 6769MB -> 6769MB ( +0MB) unsafety_checking time: 3.095; rss: 6769MB -> 6792MB ( +23MB) coherence_checking time: 21.282; rss: 6792MB -> 7546MB ( +754MB) wf_checking time: 5.404; rss: 7546MB -> 7681MB ( +135MB) item_types_checking time: 79.665; rss: 7681MB -> 8075MB ( +394MB) item_bodies_checking time: 120.166; rss: 6065MB -> 8081MB (+2016MB) type_check_crate time: 2.038; rss: 8081MB -> 8085MB ( +4MB) match_checking time: 1.300; rss: 8085MB -> 8113MB ( +28MB) liveness_and_intrinsic_checking time: 3.338; rss: 8081MB -> 8113MB ( +32MB) misc_checking_2 time: 68.612; rss: 8113MB -> 9285MB (+1172MB) MIR_borrow_checking time: 0.622; rss: 9285MB -> 9301MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9301MB -> 9301MB ( +0MB) layout_testing time: 4.331; rss: 9383MB -> 9510MB ( +127MB) death_checking time: 0.032; rss: 9510MB -> 9510MB ( +0MB) unused_lib_feature_checking time: 4.444; rss: 9510MB -> 9568MB ( +58MB) crate_lints time: 59.563; rss: 9568MB -> 9576MB ( +8MB) module_lints time: 64.006; rss: 9510MB -> 9576MB ( +66MB) lint_checking time: 4.127; rss: 9576MB -> 9639MB ( +62MB) privacy_checking_modules time: 77.984; rss: 9301MB -> 9639MB ( +337MB) misc_checking_3 time: 0.311; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.051; rss: 10357MB -> 10573MB ( +217MB) monomorphization_collector_graph_walk time: 1.759; rss: 10573MB -> 10652MB ( +79MB) partition_and_assert_distinct_symbols time: 28.518; rss: 9639MB -> 10711MB (+1072MB) generate_crate_metadata time: 0.000; rss: 10711MB -> 10711MB ( +0MB) find_cgu_reuse time: 63.408; rss: 10711MB -> 12272MB (+1560MB) codegen_to_LLVM_IR time: 64.916; rss: 10711MB -> 12267MB (+1556MB) codegen_crate time: 0.000; rss: 12261MB -> 12261MB ( +0MB) assert_dep_graph time: 0.000; rss: 12261MB -> 12261MB ( +0MB) check_dirty_clean time: 0.664; rss: 12230MB -> 12210MB ( -20MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 2.111; rss: 12210MB -> 12043MB ( -167MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.108; rss: 12043MB -> 12057MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.004; rss: 12057MB -> 12059MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.665; rss: 12059MB -> 12121MB ( +62MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 16.149; rss: 12121MB -> 12148MB ( +28MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 12148MB -> 12148MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.010; rss: 12148MB -> 12150MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.052; rss: 12150MB -> 12155MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.003; rss: 12155MB -> 12156MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 11.428; rss: 12156MB -> 11748MB ( -408MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 11748MB -> 11748MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.094; rss: 11748MB -> 11756MB ( +8MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.272; rss: 11756MB -> 11778MB ( +22MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.054; rss: 11778MB -> 11778MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 11778MB -> 11779MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.021; rss: 11779MB -> 11784MB ( +5MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.041; rss: 11784MB -> 11786MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.743; rss: 11786MB -> 11815MB ( +29MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.043; rss: 11815MB -> 11816MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.674; rss: 11816MB -> 11840MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11840MB -> 11840MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11840MB -> 11841MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 33.153; rss: 12232MB -> 11841MB ( -390MB) encode_query_results time: 88.943; rss: 11955MB -> 11783MB ( -173MB) LLVM_passes(crate) time: 38.854; rss: 12259MB -> 10095MB (-2164MB) incr_comp_serialize_result_cache time: 39.030; rss: 12261MB -> 10095MB (-2166MB) incr_comp_persist_result_cache time: 0.000; rss: 10095MB -> 10095MB ( +0MB) incr_comp_persist_dep_graph time: 39.064; rss: 12257MB -> 10095MB (-2162MB) serialize_dep_graph time: 19.047; rss: 10095MB -> 10307MB ( +212MB) free_global_ctxt time: 0.000; rss: 10307MB -> 10307MB ( +0MB) join_worker_thread time: 0.519; rss: 10307MB -> 10307MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.522; rss: 10307MB -> 10307MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10307MB -> 10307MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10307MB -> 10307MB ( +0MB) serialize_work_products time: 0.001; rss: 9542MB -> 9542MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9542MB -> 9542MB ( +0MB) link_binary_check_files_are_writeable time: 7.835; rss: 9542MB -> 9544MB ( +2MB) link_rlib time: 0.000; rss: 9544MB -> 9544MB ( +0MB) link_binary_remove_temps time: 7.872; rss: 9542MB -> 9544MB ( +2MB) link_binary time: 7.944; rss: 9542MB -> 9201MB ( -341MB) link_crate time: 8.495; rss: 10307MB -> 9201MB (-1106MB) link time: 537.014; rss: 33MB -> 3715MB (+3682MB) total ```
This PR (Click to Expand) ``` time: 2.379; rss: 51MB -> 1116MB (+1064MB) parse_crate time: 0.003; rss: 1116MB -> 1116MB ( +0MB) attributes_injection time: 0.002; rss: 1116MB -> 1116MB ( +0MB) incr_comp_prepare_session_directory time: 0.000; rss: 1116MB -> 1116MB ( +0MB) incr_comp_garbage_collect_session_directories time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_loading time: 0.000; rss: 1116MB -> 1116MB ( +0MB) plugin_registration time: 0.003; rss: 1118MB -> 1118MB ( +0MB) crate_injection time: 13.376; rss: 1118MB -> 3143MB (+2025MB) expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) check_unused_macros time: 13.379; rss: 1118MB -> 3143MB (+2025MB) macro_expand_crate time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_building_test_harness time: 0.479; rss: 3143MB -> 3143MB ( +0MB) AST_validation time: 0.002; rss: 3143MB -> 3143MB ( +0MB) maybe_create_a_macro_crate time: 0.005; rss: 3143MB -> 3143MB ( +0MB) finalize_imports time: 0.520; rss: 3143MB -> 3125MB ( -18MB) finalize_macro_resolutions time: 4.446; rss: 3125MB -> 3577MB ( +453MB) late_resolve_crate time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_main time: 0.336; rss: 3577MB -> 3577MB ( +0MB) resolve_check_unused time: 0.000; rss: 3577MB -> 3577MB ( +0MB) resolve_report_errors time: 0.295; rss: 3577MB -> 3578MB ( +0MB) resolve_postprocess time: 5.602; rss: 3143MB -> 3578MB ( +435MB) resolve_crate time: 0.388; rss: 3578MB -> 3578MB ( +0MB) complete_gated_feature_checking time: 20.014; rss: 1116MB -> 3578MB (+2462MB) configure_and_expand time: 0.000; rss: 3578MB -> 3578MB ( +0MB) prepare_outputs time: 0.000; rss: 3578MB -> 3578MB ( +0MB) blocked_on_dep_graph_loading time: 64.219; rss: 3578MB -> 6313MB (+2736MB) hir_lowering time: 1.102; rss: 6313MB -> 6319MB ( +6MB) early_lint_checks time: 1.426; rss: 6319MB -> 6268MB ( -52MB) drop_ast time: 0.005; rss: 5834MB -> 5836MB ( +2MB) setup_global_ctxt time: 0.000; rss: 5838MB -> 5838MB ( +0MB) looking_for_entry_point time: 0.292; rss: 5838MB -> 5840MB ( +1MB) looking_for_derive_registrar time: 9.553; rss: 5838MB -> 6060MB ( +222MB) misc_checking_1 time: 9.949; rss: 6060MB -> 6764MB ( +704MB) type_collecting time: 0.630; rss: 6764MB -> 6764MB ( +0MB) impl_wf_inference time: 0.060; rss: 6764MB -> 6764MB ( +0MB) unsafety_checking time: 3.054; rss: 6764MB -> 6787MB ( +23MB) coherence_checking time: 20.702; rss: 6787MB -> 7533MB ( +746MB) wf_checking time: 5.194; rss: 7533MB -> 7668MB ( +135MB) item_types_checking time: 74.677; rss: 7668MB -> 8062MB ( +394MB) item_bodies_checking time: 114.497; rss: 6060MB -> 8068MB (+2008MB) type_check_crate time: 1.891; rss: 8068MB -> 8072MB ( +4MB) match_checking time: 1.292; rss: 8072MB -> 8100MB ( +28MB) liveness_and_intrinsic_checking time: 3.183; rss: 8068MB -> 8100MB ( +32MB) misc_checking_2 time: 68.845; rss: 8100MB -> 9279MB (+1179MB) MIR_borrow_checking time: 0.587; rss: 9279MB -> 9295MB ( +17MB) MIR_effect_checking time: 0.000; rss: 9295MB -> 9295MB ( +0MB) layout_testing time: 4.443; rss: 9377MB -> 9504MB ( +127MB) death_checking time: 0.034; rss: 9504MB -> 9504MB ( +0MB) unused_lib_feature_checking time: 4.409; rss: 9504MB -> 9562MB ( +58MB) crate_lints time: 56.490; rss: 9562MB -> 9571MB ( +8MB) module_lints time: 60.900; rss: 9504MB -> 9571MB ( +66MB) lint_checking time: 4.147; rss: 9571MB -> 9633MB ( +62MB) privacy_checking_modules time: 75.094; rss: 9295MB -> 9633MB ( +337MB) misc_checking_3 time: 0.315; rss: 10357MB -> 10357MB ( +0MB) monomorphization_collector_root_collections time: 14.501; rss: 10357MB -> 10571MB ( +215MB) monomorphization_collector_graph_walk time: 1.763; rss: 10571MB -> 10661MB ( +89MB) partition_and_assert_distinct_symbols time: 29.035; rss: 9633MB -> 10706MB (+1073MB) generate_crate_metadata time: 0.000; rss: 10706MB -> 10706MB ( +0MB) find_cgu_reuse time: 30.913; rss: 10706MB -> 12150MB (+1444MB) codegen_to_LLVM_IR time: 31.108; rss: 10706MB -> 12150MB (+1444MB) codegen_crate time: 0.000; rss: 12150MB -> 12150MB ( +0MB) assert_dep_graph time: 0.000; rss: 12150MB -> 12150MB ( +0MB) check_dirty_clean time: 0.416; rss: 12152MB -> 12199MB ( +46MB) encode_query_results_for(rustc_query_impl::queries::type_of) time: 1.259; rss: 12199MB -> 12211MB ( +12MB) encode_query_results_for(rustc_query_impl::queries::generics_of) time: 0.095; rss: 12211MB -> 12193MB ( -18MB) encode_query_results_for(rustc_query_impl::queries::predicates_of) time: 0.005; rss: 12193MB -> 12195MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::mir_const_qualif) time: 0.828; rss: 12195MB -> 12208MB ( +14MB) encode_query_results_for(rustc_query_impl::queries::mir_for_ctfe) time: 17.880; rss: 12208MB -> 11987MB ( -222MB) encode_query_results_for(rustc_query_impl::queries::optimized_mir) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_file_name) time: 0.000; rss: 11987MB -> 11987MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::covered_code_regions) time: 0.007; rss: 11987MB -> 11988MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::promoted_mir) time: 0.049; rss: 11988MB -> 11992MB ( +4MB) encode_query_results_for(rustc_query_impl::queries::unsafety_check_result) time: 0.002; rss: 11992MB -> 11994MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::thir_check_unsafety) time: 38.049; rss: 11994MB -> 12093MB ( +99MB) encode_query_results_for(rustc_query_impl::queries::typeck) time: 0.000; rss: 12093MB -> 12093MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::diagnostic_only_typeck) time: 0.024; rss: 12093MB -> 12095MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::used_trait_imports) time: 0.372; rss: 12095MB -> 12053MB ( -42MB) encode_query_results_for(rustc_query_impl::queries::mir_borrowck) time: 0.015; rss: 12053MB -> 12053MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::eval_to_allocation_raw) time: 0.005; rss: 12053MB -> 12054MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::eval_to_const_value_raw) time: 0.003; rss: 12054MB -> 12056MB ( +2MB) encode_query_results_for(rustc_query_impl::queries::check_match) time: 0.037; rss: 12056MB -> 11899MB ( -157MB) encode_query_results_for(rustc_query_impl::queries::symbol_name) time: 0.667; rss: 11899MB -> 11708MB ( -191MB) encode_query_results_for(rustc_query_impl::queries::codegen_fn_attrs) time: 0.045; rss: 11708MB -> 11709MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::codegen_fulfill_obligation) time: 0.295; rss: 11709MB -> 11734MB ( +25MB) encode_query_results_for(rustc_query_impl::queries::specialization_graph_of) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_drop_tys) time: 0.000; rss: 11734MB -> 11734MB ( +0MB) encode_query_results_for(rustc_query_impl::queries::adt_significant_drop_tys) time: 0.005; rss: 11734MB -> 11734MB ( +1MB) encode_query_results_for(rustc_query_impl::queries::unused_generic_params) time: 60.063; rss: 12152MB -> 11734MB ( -418MB) encode_query_results time: 76.745; rss: 12007MB -> 11699MB ( -308MB) LLVM_passes(crate) time: 61.634; rss: 12150MB -> 10557MB (-1593MB) incr_comp_serialize_result_cache time: 61.637; rss: 12150MB -> 10557MB (-1593MB) incr_comp_persist_result_cache time: 0.001; rss: 10557MB -> 10557MB ( +0MB) incr_comp_persist_dep_graph time: 61.641; rss: 12150MB -> 10557MB (-1593MB) serialize_dep_graph time: 15.601; rss: 10557MB -> 10242MB ( -315MB) free_global_ctxt time: 0.000; rss: 10242MB -> 10242MB ( +0MB) join_worker_thread time: 0.368; rss: 10242MB -> 10242MB ( +0MB) copy_all_cgu_workproducts_to_incr_comp_cache_dir time: 0.375; rss: 10242MB -> 10242MB ( +0MB) finish_ongoing_codegen time: 0.000; rss: 10242MB -> 10242MB ( +0MB) llvm_dump_timing_file time: 0.002; rss: 10242MB -> 10242MB ( +0MB) serialize_work_products time: 0.001; rss: 9668MB -> 9668MB ( +0MB) incr_comp_finalize_session_directory time: 0.000; rss: 9668MB -> 9668MB ( +0MB) link_binary_check_files_are_writeable time: 1.469; rss: 9668MB -> 9671MB ( +3MB) link_rlib time: 0.000; rss: 9671MB -> 9671MB ( +0MB) link_binary_remove_temps time: 1.506; rss: 9668MB -> 9671MB ( +3MB) link_binary time: 1.622; rss: 9668MB -> 9329MB ( -339MB) link_crate time: 2.037; rss: 10242MB -> 9329MB ( -913MB) link time: 502.990; rss: 32MB -> 5888MB (+5855MB) total ```
(6.34% decrease in runtime results are consistent across multiple runs)",HOORAY,2021-12-24T13:28:09Z,Genarito,genarocamele@hotmail.com https://github.com/rust-lang/rust/pull/91277,CLOSED,2021-11-27T01:32:55Z,2022-02-09T16:07:49Z,rustdoc: show trait implementors in sidebar,aDotInTheVoid,NA,NA,NA,HEART,2021-11-27T05:24:30Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/91284,MERGED,2021-11-27T06:53:44Z,2021-12-06T06:58:50Z,Add support for riscv64gc-unknown-freebsd,t6,87dce6e8dfdae605c9c2a713cf0133066a52022a,7,"Auto merge of #91284 - t6:freebsd-riscv64 r=Amanieu Add support for riscv64gc-unknown-freebsd For https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy: * A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) For all Rust targets on FreeBSD it's [rust@FreeBSD.org](mailto:rust@FreeBSD.org). * Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Done. * Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. Done * Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. Done. * The target must not introduce license incompatibilities. Done. * Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). Fine with me. * The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. Done. * If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. Done. * Targets should not require proprietary (non-FOSS) components to link a functional binary or library. Done. * ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. Fine with me. * Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. Ok. * This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Ok. * Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. std is implemented. * The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Building is possible the same way as other Rust on FreeBSD targets. * Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. Ok. * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Ok. * Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. Ok. * In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. Ok.",ROCKET,2021-12-08T03:17:13Z,hewhocannotbetamed,NA https://github.com/rust-lang/rust/pull/91291,MERGED,2021-11-27T13:39:08Z,2021-12-02T09:04:58Z,Fix const deref methods display,GuillaumeGomez,d9baa361902b172be716f96619b909f340802dea,5,Auto merge of #91291 - GuillaumeGomez:const-deref-method r=camelid Fix const deref methods display Fixes https://github.com/rust-lang/rust/issues/90855 (more information in the issue). r? `@camelid`,HEART,2021-11-27T16:50:55Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/91303,MERGED,2021-11-27T23:19:03Z,2021-11-28T13:04:25Z,Miri: fix alignment check in array initialization,RalfJung,7134ae0a8dbab6fbf9920b489a37093643e3aa0c,1,Rollup merge of #91303 - RalfJung:array-init-align r=oli-obk Miri: fix alignment check in array initialization https://github.com/rust-lang/rust/pull/85376 introduced a regression in Miri reported at https://github.com/rust-lang/miri/issues/1919 and https://github.com/rust-lang/miri/issues/1925. This PR fixes that. I will add tests to Miri once this lands. r? `@oli-obk` Fixes https://github.com/rust-lang/miri/issues/1919 Fixes https://github.com/rust-lang/miri/issues/1925,HEART,2021-11-28T07:39:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91308,MERGED,2021-11-28T05:45:13Z,2021-11-28T20:16:40Z,Fix ICE when lowering `trait A where for<'a> Self: 'a`,BGR360,67d175515ffc023343990774624139b679fe267d,3,Rollup merge of #91308 - BGR360:issue-88586 r=jackh726 Fix ICE when lowering `trait A where for<'a> Self: 'a` Fixes #88586. r? `@jackh726` Jack this fix is much smaller in scope than what I think you were proposing in the issue. Let me know if you had a vision for a larger refactor here. cc `@JohnTitor`,HEART,2021-11-28T07:13:00Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/91314,OPEN,2021-11-28T12:58:49Z,NA,Add suggestion to diagnostic when user has array but trait wants slice.,BGR360,NA,NA,NA,HEART,2021-12-13T17:30:44Z,estebank,NA https://github.com/rust-lang/rust/pull/91337,MERGED,2021-11-28T22:19:12Z,2021-12-09T04:04:05Z,Add a suggestion if `macro_rules` is misspelled,FabianWolff,d26fc45e5bf170907cefcaa83c5b8e6cf6cb1351,4,Rollup merge of #91337 - FabianWolff:issue-91227-misspelled-macro r=nagisa Add a suggestion if `macro_rules` is misspelled Fixes #91227.,HEART,2021-11-28T22:23:10Z,booleancoercion,NA https://github.com/rust-lang/rust/pull/91341,MERGED,2021-11-28T23:39:52Z,2021-12-07T14:23:06Z,Add `array::IntoIter::{empty from_raw_parts}`,scottmcm,677f878e36e6b089c3213063508ec6b11c340a1f,2,Rollup merge of #91341 - scottmcm:array-iter-frp r=kennytm Add `array::IntoIter::{empty from_raw_parts}` `array::IntoIter` has a bunch of really handy logic for dealing with partial arrays but it's currently hamstrung by only being creatable from a fully-initialized array. This PR adds two new constructors: - a safe & const `empty` since `[].into_iter()` can only give `IntoIter` not `IntoIter`. - an unsafe `from_raw_parts` to allow experimentation with new uses. (Slice & vec iterators don't need `from_raw_parts` because you `from_raw_parts` the slice or vec instead but there's no useful way to made a `<[T; N]>::from_raw_parts` so I think this is a reasonable place to have one.),THUMBS_UP,2021-11-30T20:12:54Z,mati865,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-11-29T05:47:28Z,hkratz,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-11-29T07:48:21Z,marmeladema,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-11-29T09:00:49Z,iago-lito,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-11-29T13:34:10Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-12-01T07:54:43Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,HEART,2021-12-05T14:30:26Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,CONFUSED,2021-12-09T04:34:06Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,CONFUSED,2021-12-09T05:29:16Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-12-09T08:15:08Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-12-10T02:47:10Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-12-10T05:53:12Z,Folyd,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,HEART,2021-12-10T21:13:53Z,jszwedko,jesse@szwedko.me https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2021-12-10T23:46:22Z,imp,cyril.plisko@mountall.com https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,HEART,2022-01-17T05:05:00Z,cyqsimon,NA https://github.com/rust-lang/rust/pull/91346,MERGED,2021-11-29T04:29:11Z,2021-12-01T12:56:18Z,Add `Option::inspect` and `Result::{inspect inspect_err}`,ibraheemdev,ce197e2bceca00372c172a02a966b96287476c55,2,Rollup merge of #91346 - ibraheemdev:result-inspect r=dtolnay Add `Option::inspect` and `Result::{inspect inspect_err}` ```rust // core::result impl Result { pub fn inspect(self f: F) -> Self; pub fn inspect_err(self f: F) -> Self; } // core::option impl Option { pub fn inspect(self f: F) -> Self; } ```,THUMBS_UP,2022-01-26T23:24:04Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-29T15:25:45Z,CryZe,NA https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-29T15:31:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-29T16:04:00Z,marmeladema,NA https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-29T16:07:21Z,hkratz,NA https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-29T18:40:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-11-30T10:49:32Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/91355,MERGED,2021-11-29T15:24:00Z,2021-12-05T03:41:26Z,std: Stabilize the `thread_local_const_init` feature,alexcrichton,23012b5200ec78dc519969b34c0342bfa53ea3c4,10,Rollup merge of #91355 - alexcrichton:stabilize-thread-local-const r=m-ou-se std: Stabilize the `thread_local_const_init` feature This commit is intended to follow the stabilization disposition of the FCP that has now finished in #84223. This stabilizes the ability to flag thread local initializers as `const` expressions which enables the macro to generate more efficient code for accessing it notably removing runtime checks for initialization. More information can also be found in #84223 as well as the tests where the feature usage was removed in this PR. Closes #84223,HOORAY,2021-12-05T16:31:54Z,bjorn3,NA https://github.com/rust-lang/rust/pull/91356,MERGED,2021-11-29T15:35:10Z,2021-12-05T21:41:08Z,Improve rustdoc layout,GuillaumeGomez,e2116acae59654bfab2a9729a024f3e2fd6d4b02,29,Auto merge of #91356 - GuillaumeGomez:improve-rustdoc-layout r=jsha Improve rustdoc layout This is an overtake of https://github.com/rust-lang/rust/pull/89385 originally written by `@cynecx.` I kept the original commit and simply added the missing fixes into a new one. You can test it online [here](https://rustdoc.crud.net/imperio/improve-rustdoc-layout/std/index.html). r? `@jsha`,HEART,2021-11-29T17:40:29Z,cynecx,NA https://github.com/rust-lang/rust/pull/91356,MERGED,2021-11-29T15:35:10Z,2021-12-05T21:41:08Z,Improve rustdoc layout,GuillaumeGomez,e2116acae59654bfab2a9729a024f3e2fd6d4b02,29,Auto merge of #91356 - GuillaumeGomez:improve-rustdoc-layout r=jsha Improve rustdoc layout This is an overtake of https://github.com/rust-lang/rust/pull/89385 originally written by `@cynecx.` I kept the original commit and simply added the missing fixes into a new one. You can test it online [here](https://rustdoc.crud.net/imperio/improve-rustdoc-layout/std/index.html). r? `@jsha`,HEART,2021-12-02T04:18:29Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/91359,MERGED,2021-11-29T16:53:53Z,2022-01-21T09:32:23Z,Emit simpler code from format_args,dtolnay,0bcacb391b28460f5a50fd627f01f670dfcfc7cc,11,"Auto merge of #91359 - dtolnay:args r=Mark-Simulacrum Emit simpler code from format_args I made this PR so that `cargo expand` dumps a less overwhelming amount of formatting-related code.
`println!(""rust"")` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &match () { _args => [] })); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &[])); }; ``` `println!(""{}"" x)` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &match (&x ) { _args => [::core::fmt::ArgumentV1::new( _args.0 ::core::fmt::Display::fmt )] } )); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &[::core::fmt::ArgumentV1::new(&x ::core::fmt::Display::fmt)] )); }; ```",HOORAY,2022-01-05T17:21:43Z,faptc,NA https://github.com/rust-lang/rust/pull/91359,MERGED,2021-11-29T16:53:53Z,2022-01-21T09:32:23Z,Emit simpler code from format_args,dtolnay,0bcacb391b28460f5a50fd627f01f670dfcfc7cc,11,"Auto merge of #91359 - dtolnay:args r=Mark-Simulacrum Emit simpler code from format_args I made this PR so that `cargo expand` dumps a less overwhelming amount of formatting-related code.
`println!(""rust"")` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &match () { _args => [] })); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &[])); }; ``` `println!(""{}"" x)` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &match (&x ) { _args => [::core::fmt::ArgumentV1::new( _args.0 ::core::fmt::Display::fmt )] } )); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &[::core::fmt::ArgumentV1::new(&x ::core::fmt::Display::fmt)] )); }; ```",HOORAY,2022-01-21T11:25:18Z,MabezDev,scott@mabez.dev https://github.com/rust-lang/rust/pull/91359,MERGED,2021-11-29T16:53:53Z,2022-01-21T09:32:23Z,Emit simpler code from format_args,dtolnay,0bcacb391b28460f5a50fd627f01f670dfcfc7cc,11,"Auto merge of #91359 - dtolnay:args r=Mark-Simulacrum Emit simpler code from format_args I made this PR so that `cargo expand` dumps a less overwhelming amount of formatting-related code.
`println!(""rust"")` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &match () { _args => [] })); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &[])); }; ``` `println!(""{}"" x)` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &match (&x ) { _args => [::core::fmt::ArgumentV1::new( _args.0 ::core::fmt::Display::fmt )] } )); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &[::core::fmt::ArgumentV1::new(&x ::core::fmt::Display::fmt)] )); }; ```",HOORAY,2022-01-27T17:28:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91359,MERGED,2021-11-29T16:53:53Z,2022-01-21T09:32:23Z,Emit simpler code from format_args,dtolnay,0bcacb391b28460f5a50fd627f01f670dfcfc7cc,11,"Auto merge of #91359 - dtolnay:args r=Mark-Simulacrum Emit simpler code from format_args I made this PR so that `cargo expand` dumps a less overwhelming amount of formatting-related code.
`println!(""rust"")` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &match () { _args => [] })); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &[])); }; ``` `println!(""{}"" x)` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &match (&x ) { _args => [::core::fmt::ArgumentV1::new( _args.0 ::core::fmt::Display::fmt )] } )); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &[::core::fmt::ArgumentV1::new(&x ::core::fmt::Display::fmt)] )); }; ```",HOORAY,2022-01-28T16:04:21Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/91359,MERGED,2021-11-29T16:53:53Z,2022-01-21T09:32:23Z,Emit simpler code from format_args,dtolnay,0bcacb391b28460f5a50fd627f01f670dfcfc7cc,11,"Auto merge of #91359 - dtolnay:args r=Mark-Simulacrum Emit simpler code from format_args I made this PR so that `cargo expand` dumps a less overwhelming amount of formatting-related code.
`println!(""rust"")` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &match () { _args => [] })); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1(&[""rust\n""] &[])); }; ``` `println!(""{}"" x)` **Before:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &match (&x ) { _args => [::core::fmt::ArgumentV1::new( _args.0 ::core::fmt::Display::fmt )] } )); }; ``` **After:** ```rust { ::std::io::_print(::core::fmt::Arguments::new_v1( &["""" ""\n""] &[::core::fmt::ArgumentV1::new(&x ::core::fmt::Display::fmt)] )); }; ```",HOORAY,2022-01-29T09:39:47Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/91381,CLOSED,2021-11-30T02:48:31Z,2021-12-03T11:42:12Z,Android: -ldl must appear after -lgcc when linking,Amanieu,NA,NA,NA,THUMBS_UP,2021-12-01T18:38:26Z,msiglreith,NA https://github.com/rust-lang/rust/pull/91381,CLOSED,2021-11-30T02:48:31Z,2021-12-03T11:42:12Z,Android: -ldl must appear after -lgcc when linking,Amanieu,NA,NA,NA,THUMBS_UP,2021-12-03T11:47:35Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/91385,MERGED,2021-11-30T06:18:03Z,2021-12-04T05:59:23Z,Suggest the `pat_param` specifier before `|` on 2021 edition ,ecstatic-morse,2b64476b9c8161974c85d35cb29cfaa5f5cc136d,3,Rollup merge of #91385 - ecstatic-morse:pat-param-spec-suggest r=estebank Suggest the `pat_param` specifier before `|` on 2021 edition Ran into this today after writing some Rust for the first time in a while. r? `@estebank`,HEART,2021-12-02T21:22:51Z,estebank,NA https://github.com/rust-lang/rust/pull/91386,CLOSED,2021-11-30T07:03:38Z,2021-12-03T01:57:14Z,Add a MIR pass manager take 2,ecstatic-morse,NA,NA,NA,LAUGH,2021-11-30T07:10:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/91386,CLOSED,2021-11-30T07:03:38Z,2021-12-03T01:57:14Z,Add a MIR pass manager take 2,ecstatic-morse,NA,NA,NA,THUMBS_UP,2021-11-30T10:47:28Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/91386,CLOSED,2021-11-30T07:03:38Z,2021-12-03T01:57:14Z,Add a MIR pass manager take 2,ecstatic-morse,NA,NA,NA,THUMBS_UP,2021-11-30T18:04:04Z,est31,NA https://github.com/rust-lang/rust/pull/91386,CLOSED,2021-11-30T07:03:38Z,2021-12-03T01:57:14Z,Add a MIR pass manager take 2,ecstatic-morse,NA,NA,NA,THUMBS_UP,2021-11-30T18:08:07Z,lqd,NA https://github.com/rust-lang/rust/pull/91386,CLOSED,2021-11-30T07:03:38Z,2021-12-03T01:57:14Z,Add a MIR pass manager take 2,ecstatic-morse,NA,NA,NA,THUMBS_UP,2021-12-03T15:07:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91387,MERGED,2021-11-30T07:08:43Z,2021-12-03T01:04:11Z,Clarify and tidy up explanation of E0038,graydon,b269213b35f102a22b5a9645de48814fa255f7a2,1,"Rollup merge of #91387 - graydon:E0038-clarification r=wesleywiser Clarify and tidy up explanation of E0038 I ran into E0038 (specifically the `Self:Sized` constraint on object-safety) the other day and it seemed to me that the explanations I found floating around the internet were a bit .. wrong. Like they didn't make sense. And then I went and checked the official explanation here and it didn't make sense either. As far as I can tell (reading through the history of the RFCs) two totally different aspects of object-safety have got tangled up in much of the writing on the subject: - Object-safety related to ""not even theoretically possible"" issues. This includes things like ""methods that take or return Self by value"" which obviously will never work for an unsized type in a world with fixed-size stack frames (and it'd be an opaque type anyways which ugh). This sort of thing was originally decided method-by-method with non-object-safe methods stripped from objects; but in [RFC 0255](https://rust-lang.github.io/rfcs/0255-object-safety.html) this sort of per-impossible-method reasoning was made into a per-trait safety property (with the escape hatch left in where users could mark methods `where Self:Sized` to have them stripped before the trait's object safety is considered). - Object-safety related to ""totally possible but ergonomically a little awkward"" issues. Specifically in a trait with `Trait:Sized` there's no a priori reason why this constraint makes the trait impossible to make into an object -- imagine it had nothing but harmless `&self`-taking methods. No problem! Who cares if the Trait requires its implementing types to be sized? As far as I can tell reading the history here in both RFC 0255 and then later in [RFC 0546](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html) it seems that the motivation for making `Trait:Sized` be non-object-safe has _nothing to do_ with the impossibility of making objects out of such types and everything to do with enabling ""[a trait object SomeTrait to implement the trait SomeTrait](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html#motivation)"". That is since `dyn Trait` is unsized if `Trait:Sized` then you can never have the automatic (and reasonable) ergonomic implicit `impl Trait for dyn Trait`. And the authors of that RFC really wanted that automatic implicit implementation of `Trait` for `dyn Trait`. So they just defined `Trait:Sized` as non-object safe -- no `dyn Trait` can ever exist that the compiler can't synthesize such an impl for. Well enough! However I noticed in my reading-and-reconstruction that lots of documentation on the internet including forum and Q&A site answers and (most worrying) the compiler explanation all kinda grasp at something like the first (""not theoretically possible"") explanation and fail to mention the second (""just an ergonomic constraint"") explanation. So I figured I'd clean up the docs to clarify maybe confuse the next person less (unless of course I'm misreading the history here and misunderstanding motives -- please let me know if so!) While here I also did some cleanups: - Rewrote the preamble trying to help the user get a little better oriented (I found the existing preamble a bit scattered). - Modernized notation (using `dyn Trait`) - Changed the section headings to all be written with the same logical sense: to all be written as ""conditions that violate object safety"" rather than a mix of that and the negated form ""conditions that must not happen in order to ensure object safety"". I think there's a fair bit more to clean up in this doc -- the later sections get a bit rambly and I suspect there should be a completely separated-out section covering the `where Self:Sized` escape hatch for instructing the compiler to ""do the old thing"" and strip methods off traits when turning them into objects (it's a bit buried as a digression in the individual sub-error sections). But I did what I had time for now.",HEART,2021-11-30T16:33:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91387,MERGED,2021-11-30T07:08:43Z,2021-12-03T01:04:11Z,Clarify and tidy up explanation of E0038,graydon,b269213b35f102a22b5a9645de48814fa255f7a2,1,"Rollup merge of #91387 - graydon:E0038-clarification r=wesleywiser Clarify and tidy up explanation of E0038 I ran into E0038 (specifically the `Self:Sized` constraint on object-safety) the other day and it seemed to me that the explanations I found floating around the internet were a bit .. wrong. Like they didn't make sense. And then I went and checked the official explanation here and it didn't make sense either. As far as I can tell (reading through the history of the RFCs) two totally different aspects of object-safety have got tangled up in much of the writing on the subject: - Object-safety related to ""not even theoretically possible"" issues. This includes things like ""methods that take or return Self by value"" which obviously will never work for an unsized type in a world with fixed-size stack frames (and it'd be an opaque type anyways which ugh). This sort of thing was originally decided method-by-method with non-object-safe methods stripped from objects; but in [RFC 0255](https://rust-lang.github.io/rfcs/0255-object-safety.html) this sort of per-impossible-method reasoning was made into a per-trait safety property (with the escape hatch left in where users could mark methods `where Self:Sized` to have them stripped before the trait's object safety is considered). - Object-safety related to ""totally possible but ergonomically a little awkward"" issues. Specifically in a trait with `Trait:Sized` there's no a priori reason why this constraint makes the trait impossible to make into an object -- imagine it had nothing but harmless `&self`-taking methods. No problem! Who cares if the Trait requires its implementing types to be sized? As far as I can tell reading the history here in both RFC 0255 and then later in [RFC 0546](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html) it seems that the motivation for making `Trait:Sized` be non-object-safe has _nothing to do_ with the impossibility of making objects out of such types and everything to do with enabling ""[a trait object SomeTrait to implement the trait SomeTrait](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html#motivation)"". That is since `dyn Trait` is unsized if `Trait:Sized` then you can never have the automatic (and reasonable) ergonomic implicit `impl Trait for dyn Trait`. And the authors of that RFC really wanted that automatic implicit implementation of `Trait` for `dyn Trait`. So they just defined `Trait:Sized` as non-object safe -- no `dyn Trait` can ever exist that the compiler can't synthesize such an impl for. Well enough! However I noticed in my reading-and-reconstruction that lots of documentation on the internet including forum and Q&A site answers and (most worrying) the compiler explanation all kinda grasp at something like the first (""not theoretically possible"") explanation and fail to mention the second (""just an ergonomic constraint"") explanation. So I figured I'd clean up the docs to clarify maybe confuse the next person less (unless of course I'm misreading the history here and misunderstanding motives -- please let me know if so!) While here I also did some cleanups: - Rewrote the preamble trying to help the user get a little better oriented (I found the existing preamble a bit scattered). - Modernized notation (using `dyn Trait`) - Changed the section headings to all be written with the same logical sense: to all be written as ""conditions that violate object safety"" rather than a mix of that and the negated form ""conditions that must not happen in order to ensure object safety"". I think there's a fair bit more to clean up in this doc -- the later sections get a bit rambly and I suspect there should be a completely separated-out section covering the `where Self:Sized` escape hatch for instructing the compiler to ""do the old thing"" and strip methods off traits when turning them into objects (it's a bit buried as a digression in the individual sub-error sections). But I did what I had time for now.",HEART,2021-12-02T21:09:10Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/91387,MERGED,2021-11-30T07:08:43Z,2021-12-03T01:04:11Z,Clarify and tidy up explanation of E0038,graydon,b269213b35f102a22b5a9645de48814fa255f7a2,1,"Rollup merge of #91387 - graydon:E0038-clarification r=wesleywiser Clarify and tidy up explanation of E0038 I ran into E0038 (specifically the `Self:Sized` constraint on object-safety) the other day and it seemed to me that the explanations I found floating around the internet were a bit .. wrong. Like they didn't make sense. And then I went and checked the official explanation here and it didn't make sense either. As far as I can tell (reading through the history of the RFCs) two totally different aspects of object-safety have got tangled up in much of the writing on the subject: - Object-safety related to ""not even theoretically possible"" issues. This includes things like ""methods that take or return Self by value"" which obviously will never work for an unsized type in a world with fixed-size stack frames (and it'd be an opaque type anyways which ugh). This sort of thing was originally decided method-by-method with non-object-safe methods stripped from objects; but in [RFC 0255](https://rust-lang.github.io/rfcs/0255-object-safety.html) this sort of per-impossible-method reasoning was made into a per-trait safety property (with the escape hatch left in where users could mark methods `where Self:Sized` to have them stripped before the trait's object safety is considered). - Object-safety related to ""totally possible but ergonomically a little awkward"" issues. Specifically in a trait with `Trait:Sized` there's no a priori reason why this constraint makes the trait impossible to make into an object -- imagine it had nothing but harmless `&self`-taking methods. No problem! Who cares if the Trait requires its implementing types to be sized? As far as I can tell reading the history here in both RFC 0255 and then later in [RFC 0546](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html) it seems that the motivation for making `Trait:Sized` be non-object-safe has _nothing to do_ with the impossibility of making objects out of such types and everything to do with enabling ""[a trait object SomeTrait to implement the trait SomeTrait](https://rust-lang.github.io/rfcs/0546-Self-not-sized-by-default.html#motivation)"". That is since `dyn Trait` is unsized if `Trait:Sized` then you can never have the automatic (and reasonable) ergonomic implicit `impl Trait for dyn Trait`. And the authors of that RFC really wanted that automatic implicit implementation of `Trait` for `dyn Trait`. So they just defined `Trait:Sized` as non-object safe -- no `dyn Trait` can ever exist that the compiler can't synthesize such an impl for. Well enough! However I noticed in my reading-and-reconstruction that lots of documentation on the internet including forum and Q&A site answers and (most worrying) the compiler explanation all kinda grasp at something like the first (""not theoretically possible"") explanation and fail to mention the second (""just an ergonomic constraint"") explanation. So I figured I'd clean up the docs to clarify maybe confuse the next person less (unless of course I'm misreading the history here and misunderstanding motives -- please let me know if so!) While here I also did some cleanups: - Rewrote the preamble trying to help the user get a little better oriented (I found the existing preamble a bit scattered). - Modernized notation (using `dyn Trait`) - Changed the section headings to all be written with the same logical sense: to all be written as ""conditions that violate object safety"" rather than a mix of that and the negated form ""conditions that must not happen in order to ensure object safety"". I think there's a fair bit more to clean up in this doc -- the later sections get a bit rambly and I suspect there should be a completely separated-out section covering the `where Self:Sized` escape hatch for instructing the compiler to ""do the old thing"" and strip methods off traits when turning them into objects (it's a bit buried as a digression in the individual sub-error sections). But I did what I had time for now.",HEART,2022-02-21T18:04:34Z,vexx32,NA https://github.com/rust-lang/rust/pull/91390,CLOSED,2021-11-30T10:03:32Z,2022-01-22T04:51:02Z,Add a raw pointer iterator,dtolnay,NA,NA,NA,HEART,2021-11-30T20:51:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91390,CLOSED,2021-11-30T10:03:32Z,2022-01-22T04:51:02Z,Add a raw pointer iterator,dtolnay,NA,NA,NA,THUMBS_UP,2021-11-30T21:08:36Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91390,CLOSED,2021-11-30T10:03:32Z,2022-01-22T04:51:02Z,Add a raw pointer iterator,dtolnay,NA,NA,NA,THUMBS_UP,2021-12-02T15:42:30Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/91390,CLOSED,2021-11-30T10:03:32Z,2022-01-22T04:51:02Z,Add a raw pointer iterator,dtolnay,NA,NA,NA,THUMBS_UP,2021-12-04T12:59:07Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,EYES,2021-11-30T17:01:24Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-02T15:34:25Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-03T15:12:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T03:46:15Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,EYES,2021-12-09T03:46:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T04:08:03Z,lukechu10,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T08:52:16Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,EYES,2021-12-09T08:52:16Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T13:27:17Z,maekawatoshiki,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T15:21:01Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-09T21:50:11Z,kangalioo,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-10T08:36:48Z,tux3,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2021-12-12T00:51:20Z,martin-t,NA https://github.com/rust-lang/rust/pull/91393,MERGED,2021-11-30T16:11:24Z,2021-12-03T16:26:09Z,Optimize `rustc_lexer`,Julian-Wollersberger,2a9e0831d6603d87220cedd1b1293e2eb82ef55c,2,Auto merge of #91393 - Julian-Wollersberger:lexer_optimization r=petrochenkov Optimize `rustc_lexer` The `cursor.first()` method in `rustc_lexer` now calls the `chars.next()` method instead of `chars.nth_char(0)`. This allows LLVM to optimize the code better. The biggest win is that `eat_while()` is now fully inlined and generates better assembly. This improves the lexer's performance by 35% in a micro-benchmark I made (Lexing all 18MB of code in the compiler directory). But lexing is only a small part of the overall compilation time so I don't know how significant it is. Big thanks to criterion and `cargo asm`.,HEART,2022-02-03T09:26:33Z,jsh-uon,NA https://github.com/rust-lang/rust/pull/91404,MERGED,2021-11-30T22:36:43Z,2021-12-01T12:56:18Z,Fix bad `NodeId` limit checking.,nnethercote,4f252f1a91e8c46508443ea92c6f221e6de5beb1,1,Rollup merge of #91404 - nnethercote:fix-bad-NodeId-limit-checking r=dtolnay Fix bad `NodeId` limit checking. `Resolver::next_node_id` converts a `u32` to a `usize` (which is possibly bigger) does a checked add and then converts the result back to a `u32`. The `usize` conversion completely subverts the checked add! This commit removes the conversion to/from `usize`.,THUMBS_UP,2021-12-01T00:36:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91424,MERGED,2021-12-01T15:35:41Z,2021-12-01T23:22:51Z,Update LLVM with patches for better llvm-cov diagnostics,richkadel,5fb1886629a083751f3cf979f97d0c09efaaf647,1,Rollup merge of #91424 - richkadel:llvm-patch-instrproferror r=tmandry Update LLVM with patches for better llvm-cov diagnostics Cherry-picks https://github.com/llvm/llvm-project/commit/ee88b8d63e475a75ae525563edfa95f6fcaac83a and https://github.com/llvm/llvm-project/commit/126e7611c70ca41782aa851c2bec132607eb8127 These patches to LLVM were added to help debug occasional errors that cause coverage reporting to fail. Prior to this patch the only messaging was that the coverage data was malformed. Hopefully the improved messaging will help identify the root cause of these errors when they arise so we can make corrections to coverage output from Rust. r? `@tmandry`,EYES,2021-12-01T16:33:04Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/91427,CLOSED,2021-12-01T18:02:38Z,2022-02-11T03:43:53Z,rustdoc: Unify macro intra-doc link resolution with type and value resolution,jyn514,NA,NA,NA,HOORAY,2021-12-01T19:23:04Z,camelid,NA https://github.com/rust-lang/rust/pull/91427,CLOSED,2021-12-01T18:02:38Z,2022-02-11T03:43:53Z,rustdoc: Unify macro intra-doc link resolution with type and value resolution,jyn514,NA,NA,NA,HOORAY,2021-12-02T05:20:46Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/91443,MERGED,2021-12-02T02:56:42Z,2022-02-10T05:08:36Z,Better suggestions when user tries to collect into an unsized `[_]`,compiler-errors,9634559599537e334cbfa854446d048e6ebe5ee9,5,Rollup merge of #91443 - compiler-errors:bad_collect_into_slice r=wesleywiser Better suggestions when user tries to collect into an unsized `[_]` 1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note label etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases. 2. Add a `rustc_on_unimplemented` if we fail on `FromIterator for [A]` which happens when we don't explicitly collect into a `vec` but then pass the return from a `.collect` call into something that takes a slice. Fixes #91423,HEART,2021-12-06T01:51:37Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/91443,MERGED,2021-12-02T02:56:42Z,2022-02-10T05:08:36Z,Better suggestions when user tries to collect into an unsized `[_]`,compiler-errors,9634559599537e334cbfa854446d048e6ebe5ee9,5,Rollup merge of #91443 - compiler-errors:bad_collect_into_slice r=wesleywiser Better suggestions when user tries to collect into an unsized `[_]` 1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note label etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases. 2. Add a `rustc_on_unimplemented` if we fail on `FromIterator for [A]` which happens when we don't explicitly collect into a `vec` but then pass the return from a `.collect` call into something that takes a slice. Fixes #91423,HEART,2022-02-17T03:18:26Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91444,MERGED,2021-12-02T03:50:46Z,2021-12-03T01:04:11Z,disable tests in Miri that take too long,RalfJung,fbfa0030162e5a7afd8b175c8ed496b66adf2875,1,"Rollup merge of #91444 - RalfJung:miri-tests r=dtolnay disable tests in Miri that take too long Comparing slices of length `usize::MAX` diverges in Miri. In fact these tests even diverge in rustc unless `-O` is passed. I tried this code to check that: ```rust #![feature(slice_take)] const EMPTY_MAX: &'static [()] = &[(); usize::MAX]; fn main() { let mut slice: &[_] = &[(); usize::MAX]; println!(""1""); assert_eq!(Some(&[] as _) slice.take(usize::MAX..)); println!(""2""); let remaining: &[_] = EMPTY_MAX; println!(""3""); assert_eq!(remaining slice); println!(""4""); } ``` So disable these tests in Miri for now.",THUMBS_UP,2021-12-02T03:57:14Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/91450,MERGED,2021-12-02T10:37:47Z,2021-12-05T18:35:17Z,Don't suggest types whose inner type is erroneous,hkmatsumoto,609d9a0108d4e6d79279fc6c5901eb5041c7aac7,3,Rollup merge of #91450 - hkmatsumoto:hide-type-error r=estebank Don't suggest types whose inner type is erroneous Currently we check if the returned type equals to `tcx.ty_error()` not to emit erroneous types but this has a pitfall; for example `Option<[type error]> != tcx.ty_error()` holds. Fixes #91371.,HEART,2021-12-02T20:25:06Z,estebank,NA https://github.com/rust-lang/rust/pull/91450,MERGED,2021-12-02T10:37:47Z,2021-12-05T18:35:17Z,Don't suggest types whose inner type is erroneous,hkmatsumoto,609d9a0108d4e6d79279fc6c5901eb5041c7aac7,3,Rollup merge of #91450 - hkmatsumoto:hide-type-error r=estebank Don't suggest types whose inner type is erroneous Currently we check if the returned type equals to `tcx.ty_error()` not to emit erroneous types but this has a pitfall; for example `Option<[type error]> != tcx.ty_error()` holds. Fixes #91371.,HEART,2021-12-07T10:56:43Z,spookyvision,NA https://github.com/rust-lang/rust/pull/91467,MERGED,2021-12-02T21:12:27Z,2021-12-08T14:28:39Z,Emphasise that an OsStr[ing] is not necessarily a platform string,ChrisDenton,bb8a4ab6aed4b96fe2338b0f59f67d4560d4ba11,1,Rollup merge of #91467 - ChrisDenton:confusing-os-string r=Mark-Simulacrum Emphasise that an OsStr[ing] is not necessarily a platform string Fixes #53261 Since that issue was filed #56141 added a further clarification to the `OsString` docs. However the ffi docs may still leave the impression that an `OsStr` is in the platform native form. This PR aims to further emphasise that an `OsStr` is not necessarily a platform string.,THUMBS_UP,2021-12-03T17:02:38Z,a1phyr,NA https://github.com/rust-lang/rust/pull/91475,MERGED,2021-12-02T23:11:10Z,2021-12-05T06:46:57Z,Add a MIR pass manager (Taylor's Version),ecstatic-morse,bdaa9010493d26611079a9de1c8722532e140a24,39,Auto merge of #91475 - ecstatic-morse:mir-pass-manager3 r=oli-obk Add a MIR pass manager (Taylor's Version) The final draft of #91386 and #77665. While the compile-time constraints in #91386 are cool I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today: - Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase. - `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior you can always branch on `body.phase` yourself. - If your pass is solely to emit errors you can use the `MirLint` interface instead which gets a shared reference to `Body` instead of a mutable one. By differentiating the two I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time? - MIR is no longer dumped for passes that aren't enabled or for lints. I tried to check that `-Zvalidate` still works correctly since the MIR phase is now updated as soon as the associated pass is done instead of at the end of all the passes in `run_passes`. However it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors). cc `@oli-obk` `@wesleywiser` r? rust-lang/wg-mir-opt,HEART,2021-12-06T17:30:51Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91475,MERGED,2021-12-02T23:11:10Z,2021-12-05T06:46:57Z,Add a MIR pass manager (Taylor's Version),ecstatic-morse,bdaa9010493d26611079a9de1c8722532e140a24,39,Auto merge of #91475 - ecstatic-morse:mir-pass-manager3 r=oli-obk Add a MIR pass manager (Taylor's Version) The final draft of #91386 and #77665. While the compile-time constraints in #91386 are cool I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today: - Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase. - `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior you can always branch on `body.phase` yourself. - If your pass is solely to emit errors you can use the `MirLint` interface instead which gets a shared reference to `Body` instead of a mutable one. By differentiating the two I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time? - MIR is no longer dumped for passes that aren't enabled or for lints. I tried to check that `-Zvalidate` still works correctly since the MIR phase is now updated as soon as the associated pass is done instead of at the end of all the passes in `run_passes`. However it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors). cc `@oli-obk` `@wesleywiser` r? rust-lang/wg-mir-opt,HEART,2021-12-07T20:22:14Z,mati865,NA https://github.com/rust-lang/rust/pull/91475,MERGED,2021-12-02T23:11:10Z,2021-12-05T06:46:57Z,Add a MIR pass manager (Taylor's Version),ecstatic-morse,bdaa9010493d26611079a9de1c8722532e140a24,39,Auto merge of #91475 - ecstatic-morse:mir-pass-manager3 r=oli-obk Add a MIR pass manager (Taylor's Version) The final draft of #91386 and #77665. While the compile-time constraints in #91386 are cool I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today: - Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase. - `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior you can always branch on `body.phase` yourself. - If your pass is solely to emit errors you can use the `MirLint` interface instead which gets a shared reference to `Body` instead of a mutable one. By differentiating the two I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time? - MIR is no longer dumped for passes that aren't enabled or for lints. I tried to check that `-Zvalidate` still works correctly since the MIR phase is now updated as soon as the associated pass is done instead of at the end of all the passes in `run_passes`. However it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors). cc `@oli-obk` `@wesleywiser` r? rust-lang/wg-mir-opt,HEART,2021-12-13T10:24:09Z,krdln,NA https://github.com/rust-lang/rust/pull/91475,MERGED,2021-12-02T23:11:10Z,2021-12-05T06:46:57Z,Add a MIR pass manager (Taylor's Version),ecstatic-morse,bdaa9010493d26611079a9de1c8722532e140a24,39,Auto merge of #91475 - ecstatic-morse:mir-pass-manager3 r=oli-obk Add a MIR pass manager (Taylor's Version) The final draft of #91386 and #77665. While the compile-time constraints in #91386 are cool I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today: - Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase. - `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior you can always branch on `body.phase` yourself. - If your pass is solely to emit errors you can use the `MirLint` interface instead which gets a shared reference to `Body` instead of a mutable one. By differentiating the two I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time? - MIR is no longer dumped for passes that aren't enabled or for lints. I tried to check that `-Zvalidate` still works correctly since the MIR phase is now updated as soon as the associated pass is done instead of at the end of all the passes in `run_passes`. However it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors). cc `@oli-obk` `@wesleywiser` r? rust-lang/wg-mir-opt,HEART,2022-03-04T22:38:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-03T00:30:23Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-03T01:55:44Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-03T01:56:04Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-03T15:08:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-03T15:08:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-03T22:45:36Z,camelid,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-04T00:29:00Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:18:52Z,CYBAI,cyb.ai.815@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:20:12Z,johnrees,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:20:27Z,spaarmann,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:22:42Z,dunxen,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T11:22:50Z,dunxen,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:24:19Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T11:24:22Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:28:28Z,Woomymy,github@woomy.ovh https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T11:28:29Z,Woomymy,github@woomy.ovh https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:30:50Z,mechie,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T11:58:20Z,parksb,parkgds@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T11:58:20Z,parksb,parkgds@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T12:01:44Z,zmtq05,zmtq05@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T12:47:47Z,HoloTheDrunk,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T12:53:26Z,utybo,matthieu.stombellini@outlook.fr https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T13:07:02Z,yujingaya,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T13:12:00Z,panarch,taehoon.moon@outlook.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T13:12:01Z,panarch,taehoon.moon@outlook.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T13:55:32Z,Turbo87,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T13:59:27Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T14:55:10Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T15:21:28Z,swantzter,svante@swantzter.se https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T15:38:51Z,vimpostor,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T15:47:46Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T15:47:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T15:54:05Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T16:04:41Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T16:04:49Z,jhg,jesushdez@protonmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T16:04:53Z,vyacheslavchulkin,v.n.chulkin@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-15T16:22:54Z,thekitaev,thekitaev@yandex.ru https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T16:25:46Z,mlodato517,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T16:27:11Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T16:29:17Z,TheZoq2,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T16:29:18Z,TheZoq2,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T16:31:16Z,viriuwu,hi@viri.moe https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:03:02Z,crabbo-rave,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T17:03:03Z,crabbo-rave,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-15T17:03:06Z,crabbo-rave,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T17:06:28Z,adetaylor,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:10:29Z,NotNorom,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:24:59Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T17:25:00Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:26:42Z,tjjfvi,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:33:33Z,elichai,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T17:35:49Z,kupiakos,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T17:53:51Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T18:32:59Z,lguenth,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T18:33:00Z,lguenth,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T19:18:52Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T19:20:30Z,0x6D70,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T19:34:25Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T19:34:26Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T19:50:50Z,megahomyak,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T19:53:03Z,zohnannor,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-15T19:53:04Z,zohnannor,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T19:53:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T20:23:39Z,booleancoercion,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T20:23:41Z,booleancoercion,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T20:40:14Z,ticky,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T20:40:40Z,drewtato,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T21:36:14Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T21:43:56Z,Gijsvs,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T22:15:41Z,kaylynn234,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T22:15:41Z,kaylynn234,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T22:47:48Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T22:47:49Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-15T22:47:54Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T22:51:43Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-15T22:51:44Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-15T22:51:44Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-15T23:27:25Z,ShadowJonathan,jonathandejong02@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T01:18:30Z,Widowan,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T02:34:05Z,unbeatable-101,daviswill048@icloud.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T02:34:05Z,unbeatable-101,daviswill048@icloud.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T02:36:14Z,Be-ing,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T02:36:15Z,Be-ing,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T02:49:21Z,Lynnesbian,lynne@bune.city https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T03:20:44Z,mdashlw,mdashlw@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T03:22:04Z,MithicSpirit,rpc01234@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T03:29:30Z,CottageDwellingCat,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T04:47:52Z,madds-h,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-16T05:42:10Z,raisilhamn,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T05:44:00Z,Amolith,amolith@secluded.site https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T05:44:02Z,Amolith,amolith@secluded.site https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T06:49:34Z,siddharth-kulshrestha,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-16T06:49:36Z,YerinAlexey,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-16T06:51:25Z,MetaStag,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T08:17:34Z,AlexanderBand,alex@nlnetlabs.nl https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T08:50:05Z,juxuanu,icar.nin@protonmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T09:32:43Z,HeyBanditoz,hayden@banditoz.io https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T10:06:24Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T10:06:25Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-16T10:06:25Z,msfjarvis,me@msfjarvis.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T11:00:58Z,PattaFeuFeu,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T11:00:59Z,PattaFeuFeu,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T11:45:04Z,soluri,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T12:08:31Z,Lunarmagpie,Bambolambo0@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T12:22:45Z,FCLC,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T12:22:46Z,FCLC,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-16T12:22:46Z,FCLC,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T14:57:05Z,23marabi,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T15:40:32Z,redbrain,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T16:49:19Z,Jamalam360,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T16:49:19Z,Jamalam360,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T17:59:57Z,tibbon,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-16T17:59:57Z,tibbon,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T19:49:24Z,jplatte,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T21:38:43Z,michidk,michael@lohr.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-16T23:10:46Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T04:45:38Z,Dolphin2Point1,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-17T04:45:42Z,Dolphin2Point1,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-17T04:45:43Z,Dolphin2Point1,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T07:26:55Z,ImperatorStorm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-17T07:26:56Z,ImperatorStorm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-17T07:26:57Z,ImperatorStorm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T08:08:14Z,MordechaiHadad,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-17T08:08:15Z,MordechaiHadad,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T10:35:11Z,noslaver,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T12:19:10Z,SpaceClouds42,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-17T12:19:11Z,SpaceClouds42,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T18:29:50Z,kawaemon,me@kawaemon.dev https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-17T22:45:43Z,josemirm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-17T22:45:44Z,josemirm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-18T03:37:23Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-18T13:47:49Z,bjorn3,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-18T15:38:35Z,Recursing,buonanno.lorenzo@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-18T19:48:46Z,richo,richo@psych0tik.net https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-19T17:43:23Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-19T18:23:26Z,ksyx,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-19T18:23:28Z,ksyx,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-20T05:56:38Z,axeoman,axeo@aiven.io https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-20T19:49:39Z,SystematicError,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-20T19:49:45Z,SystematicError,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-20T19:49:46Z,SystematicError,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-23T00:46:20Z,Binlogo,binboy@live.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2021-12-23T04:22:38Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-23T23:35:16Z,tk3369,tk3369@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-24T00:07:25Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-24T07:09:51Z,henry40408,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-24T07:09:52Z,henry40408,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-24T09:50:33Z,c0ntradicti0n,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-25T11:51:18Z,wuyudi,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-25T21:46:20Z,eopb,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-25T21:46:20Z,eopb,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-27T22:09:23Z,Sup3Legacy,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-27T23:25:03Z,tintinnabulate,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-27T23:25:06Z,tintinnabulate,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2021-12-28T18:26:59Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2021-12-29T12:21:14Z,Darruma,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-01-01T22:49:46Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-01-01T22:49:46Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-01-02T22:12:38Z,criemen,cornelius@github.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-01-03T00:53:52Z,MarSavar,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-01-11T07:31:33Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-01-25T12:36:57Z,liamdalg,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-02-03T05:44:02Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-02-04T18:52:42Z,Milo123459,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-02-04T18:52:43Z,Milo123459,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-02-05T00:46:57Z,undersquire,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-02-05T00:46:57Z,undersquire,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-02-11T12:30:20Z,pro465,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-02-28T03:23:16Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-02-28T03:23:19Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-03-01T17:23:02Z,yxqsnz,yxqsnz@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-03-01T17:23:02Z,yxqsnz,yxqsnz@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-03-23T18:09:28Z,FreskyZ,FreskyZ@outlook.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-05-11T21:13:04Z,thedenisnikulin,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-05-11T21:13:09Z,thedenisnikulin,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-03T19:53:52Z,Kilobyte22,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-05T22:48:28Z,DCNick3,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T19:52:38Z,steviegt6,xxlennygamerxx@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T20:55:50Z,the-emerald,git@anson-cheung.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:00:40Z,queer,null@amy.gg https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T21:00:41Z,queer,null@amy.gg https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-25T21:00:42Z,queer,null@amy.gg https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:10:29Z,Masynchin,masynchin@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T21:25:20Z,Cardosaum,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:25:21Z,Cardosaum,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:30:51Z,Yusuto,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T21:41:05Z,ian-fox,iansfox@pm.me https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:41:06Z,ian-fox,iansfox@pm.me https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T21:55:49Z,NathanHuisman,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T21:55:50Z,NathanHuisman,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T22:17:00Z,GoldenStack,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T22:17:01Z,GoldenStack,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-25T22:28:37Z,Yusuto,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T22:28:38Z,Yusuto,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T22:34:57Z,ratulrafsan,ratulrafsan@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T22:36:08Z,m4dh0rs3,schoeps.benedikt@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T22:48:08Z,g-berthiaume,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T22:54:07Z,hfern,hgfern@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-25T23:57:22Z,mrshmllow,marshycity@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-25T23:57:24Z,mrshmllow,marshycity@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T00:01:28Z,pastelmind,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T00:07:30Z,Filip-Tomasko,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T01:25:26Z,Comeza,aaron@geigr.io https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T01:52:44Z,ekzhang,ekzhang1@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T02:17:47Z,VRichardJP,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T02:18:36Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-26T02:18:39Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T02:19:06Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T02:56:33Z,VirtuousCrane,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T03:51:21Z,Misterio77,eu@misterio.me https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T04:37:51Z,EsdrasAmora,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T04:46:49Z,ThatXliner,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T04:46:51Z,ThatXliner,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T06:42:51Z,pro465,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-26T06:42:52Z,pro465,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T09:34:28Z,Occhioverde,rsacchetto@nexxontech.it https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T11:02:04Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T12:03:24Z,zneix,zneix@zneix.eu https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T12:06:30Z,Robert3141,robertaries1@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T13:11:15Z,Rdkang,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T13:45:03Z,Merlin1846,codingwizardgames@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-26T13:45:07Z,Merlin1846,codingwizardgames@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T13:45:08Z,Merlin1846,codingwizardgames@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-06-26T13:45:10Z,Merlin1846,codingwizardgames@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T13:49:55Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T13:55:40Z,elimirks,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T13:55:43Z,elimirks,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T14:00:16Z,A-Walrus,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T16:31:28Z,ahhshm,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-26T16:45:11Z,AldanTanneo,sagaert.cesar@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-26T17:22:46Z,7coil,github@leondrolio.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-27T02:58:08Z,Stumblinbear,stumblinbear@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-27T04:41:16Z,nonl4331,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-27T09:10:10Z,loggeek,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-27T09:12:13Z,loggeek,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-27T13:15:36Z,daudcanugerah,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-06-27T15:03:19Z,leo848,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-27T19:05:19Z,P1n3appl3,Josephryan3.14@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-28T15:09:25Z,Divoolej,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-06-28T15:09:26Z,Divoolej,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-28T15:09:28Z,Divoolej,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-06-28T15:09:30Z,Divoolej,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-28T16:53:43Z,jacobbarssbailey,jacob@barss-bailey.org https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-06-29T09:05:37Z,paurana,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-30T17:54:47Z,dcdunkan,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-06-30T20:59:51Z,Breadinator,br3adina7or@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-01T04:23:08Z,stegaBOB,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-07-01T04:23:09Z,stegaBOB,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-07-01T04:23:09Z,stegaBOB,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-07-01T04:23:10Z,stegaBOB,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-01T06:35:36Z,POMMI3R,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-07-01T08:46:44Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-01T08:46:45Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,EYES,2022-07-01T08:46:48Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-07-01T08:46:49Z,abiriadev,abiria.dev@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-02T06:20:02Z,danielzgtg,danielzgtg.opensource@gmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-07-02T13:01:12Z,aidangilmore,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-07-02T17:20:33Z,wizard-28,wiz28@protonmail.com https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,HEART,2022-07-02T23:09:00Z,RalfJung,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-04T17:09:03Z,JhonnyRice,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,THUMBS_UP,2022-07-04T17:09:07Z,JhonnyRice,NA https://github.com/rust-lang/rust/pull/91476,MERGED,2021-12-03T00:23:07Z,2021-12-09T07:08:37Z,Improve 'cannot contain emoji' error.,m-ou-se,dc834f08ba3ac4dbfade58c8639b933bd81c6a82,4,Rollup merge of #91476 - m-ou-se:ferris-identifier r=estebank Improve 'cannot contain emoji' error. Before: ``` error: identifiers cannot contain emoji: `🦀` --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ ``` After: ``` error: Ferris cannot be used as an identifier --> src/main.rs:2:9 | 2 | let 🦀 = 1; | ^^ help: try using their name instead: `ferris` ``` r? `@estebank`,LAUGH,2022-07-06T08:25:20Z,aatifsyed,NA https://github.com/rust-lang/rust/pull/91479,MERGED,2021-12-03T02:15:19Z,2021-12-15T12:41:47Z,Add `[T]::as_simd(_mut)`,scottmcm,efc49c142a7a9c80841f51cbae92fed6f40adfcc,1,Rollup merge of #91479 - scottmcm:slice-as-simd r=workingjubilee Add `[T]::as_simd(_mut)` SIMD-style optimizations are the most common use for `[T]::align_to(_mut)` but that's `unsafe`. So these are *safe* wrappers around it now that we have the `Simd` type available to make it easier to use. ```rust impl [T] { pub fn as_simd(&self) -> (&[T] &[Simd] &[T]); pub fn as_simd_mut(&mut self) -> (&mut [T] &mut [Simd] &mut [T]); } ``` They're `cfg`'d out for miri because the `simd` module as a whole is unavailable there.,THUMBS_UP,2021-12-22T23:59:55Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/91479,MERGED,2021-12-03T02:15:19Z,2021-12-15T12:41:47Z,Add `[T]::as_simd(_mut)`,scottmcm,efc49c142a7a9c80841f51cbae92fed6f40adfcc,1,Rollup merge of #91479 - scottmcm:slice-as-simd r=workingjubilee Add `[T]::as_simd(_mut)` SIMD-style optimizations are the most common use for `[T]::align_to(_mut)` but that's `unsafe`. So these are *safe* wrappers around it now that we have the `Simd` type available to make it easier to use. ```rust impl [T] { pub fn as_simd(&self) -> (&[T] &[Simd] &[T]); pub fn as_simd_mut(&mut self) -> (&mut [T] &mut [Simd] &mut [T]); } ``` They're `cfg`'d out for miri because the `simd` module as a whole is unavailable there.,THUMBS_UP,2021-12-23T13:41:18Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-01-29T03:33:39Z,ThePuzzlemaker,tpzker@thepuzzlemaker.info https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-01-29T03:37:33Z,wackbyte,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-01-29T23:51:42Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-02-07T17:45:23Z,aloucks,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-02-18T22:17:45Z,daniel5151,danielprilik@gmail.com https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-02-23T18:04:33Z,laurmaedje,laurmaedje@gmail.com https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-12T16:26:08Z,Ten0,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-12T16:38:12Z,bouguerra-khalil,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-27T23:11:32Z,pacak,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-28T00:45:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-28T17:15:05Z,anden3,andre.vennberg@gmail.com https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-29T01:40:05Z,Sinono3,aldo@aael.xyz https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-04-30T11:36:57Z,miam-miam100,NA https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-05-07T00:50:56Z,CobaltCause,charles@computer.surgery https://github.com/rust-lang/rust/pull/91480,MERGED,2021-12-03T02:37:21Z,2022-01-01T02:03:29Z,rustdoc: use smaller number of colors to distinguish items,jsha,72e36d47e830a175815aba937d8a669d72d028fd,9,"Rollup merge of #91480 - jsha:fewer-colors r=GuillaumeGomez rustdoc: use smaller number of colors to distinguish items This reduces visual distractions when reading method signatures. As discussed in https://github.com/rust-lang/rust/issues/59845#issuecomment-974757191 this categorizes items into one of six colors (down from thirteen): - method function (ochre `#AD7C37`) - trait trait alias (dark slate blue `#6E4FC9`) - enum struct type alias union primitive (maroon `#AD378A`) - static module keyword associated type foreign type (steel blue `#3873AD`) - macro (green `#068000`) - generic params self Self (unmarked black `#000000`) I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for ""search-failed""). The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes just their assignment to types. Demo: https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html",THUMBS_DOWN,2022-06-06T18:17:54Z,Benjamin-L,benjamin.fik.lee@gmail.com https://github.com/rust-lang/rust/pull/91484,MERGED,2021-12-03T04:03:11Z,2021-12-08T04:46:42Z,Sync portable-simd to remove autosplats,workingjubilee,11fb21fd0e4c42490d42f1baf6bc51516e5dc5f5,23,"Auto merge of #91484 - workingjubilee:simd-remove-autosplats r=Mark-Simulacrum Sync portable-simd to remove autosplats This PR syncs portable-simd in up to https://github.com/rust-lang/portable-simd/commit/a8385522ade6f67853edac730b5bf164ddb298fd in order to address the type inference breakages documented on nightly in https://github.com/rust-lang/rust/issues/90904 by removing the vector + scalar binary operations (called ""autosplats"" ""broadcasting"" or ""rank promotion"" depending on who you ask) that allow `{scalar} + &'_ {scalar}` to fail in some cases because it becomes possible the programmer may have meant `{scalar} + &'_ {vector}`. A few quality-of-life improvements make their way in as well: - Lane counts can now go to 64 as LLVM seems to have fixed their miscompilation for those. - `{i u}8x64` to `__m512i` is now available. - a bunch of `#[must_use]` notes appear throughout the module. - Some implementations mostly instances of `impl core::ops::{Op} for Simd` that aren't `{vector} + {vector}` (e.g. `{vector} + &'_ {vector}`) leverage some generics and `where` bounds now to make them easier to understand by reducing a dozen implementations into one (and make it possible for people to open the docs on less burly devices). - And some internal-only improvements. None of these changes should affect a beta backport only actual users of `core::simd` (and most aren't even visible in the programmatic sense) though I can extract an even more minimal changeset for beta if necessary. It seemed simpler to just keep moving forward.",THUMBS_UP,2021-12-07T22:17:28Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91495,CLOSED,2021-12-03T16:42:21Z,2021-12-06T12:50:46Z,Add regression test for #91489,SNCPlay42,NA,NA,NA,THUMBS_UP,2021-12-03T16:57:42Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/91500,MERGED,2021-12-03T20:38:35Z,2021-12-08T07:54:33Z,Update mdbook,ehuss,abba5edf480f8ba6be4aa8791bd343dd12efb969,2,Auto merge of #91500 - ehuss:update-mdbook r=Mark-Simulacrum Update mdbook This just includes a few minor fixes: * https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0413 * https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0414,ROCKET,2021-12-27T03:54:07Z,igxactly,igxactly@gmail.com https://github.com/rust-lang/rust/pull/91500,MERGED,2021-12-03T20:38:35Z,2021-12-08T07:54:33Z,Update mdbook,ehuss,abba5edf480f8ba6be4aa8791bd343dd12efb969,2,Auto merge of #91500 - ehuss:update-mdbook r=Mark-Simulacrum Update mdbook This just includes a few minor fixes: * https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0413 * https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0414,EYES,2021-12-27T03:54:10Z,igxactly,igxactly@gmail.com https://github.com/rust-lang/rust/pull/91516,MERGED,2021-12-04T09:39:32Z,2021-12-18T13:27:13Z,Improve suggestion to change struct field to &mut,rukai,57d49f15c9c5285126b15be9ea3762225039fe3f,4,Rollup merge of #91516 - rukai:improve_mut_addition_help r=estebank Improve suggestion to change struct field to &mut r? ``@estebank`` Now displays a proper underline style suggestion instead of including the code change inline with the message.,THUMBS_UP,2021-12-17T02:21:52Z,estebank,NA https://github.com/rust-lang/rust/pull/91519,MERGED,2021-12-04T11:06:38Z,2021-12-30T18:07:00Z,ast: Avoid aborts on fatal errors thrown from mutable AST visitor,petrochenkov,b9f7197ab35f79b4df1f60104b9d8af9e77bb566,2,Rollup merge of #91519 - petrochenkov:cratexp2 r=Aaron1011 ast: Avoid aborts on fatal errors thrown from mutable AST visitor Set the node to some dummy value and rethrow the error instead. When using the old aborting `visit_clobber` in `InvocationCollector::visit_crate` the next tests abort due to fatal errors: ``` ui\modules\path-invalid-form.rs ui\modules\path-macro.rs ui\modules\path-no-file-name.rs ui\parser\issues\issue-5806.rs ui\parser\mod_file_with_path_attr.rs ``` Follow up to https://github.com/rust-lang/rust/pull/91313.,THUMBS_UP,2021-12-04T23:05:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-04T16:31:40Z,hkratz,NA https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-04T16:37:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-04T16:52:18Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-04T17:41:43Z,kageru,kageru@encode.moe https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-24T09:27:34Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/91527,MERGED,2021-12-04T15:22:07Z,2021-12-16T10:51:35Z,Optimize `vec::retain` performance ,the8472,a090c8659c3be0cbc7dc93c4b2c11a9cdbf8b980,2,Auto merge of #91527 - the8472:retain-opt r=dtolnay Optimize `vec::retain` performance This simply moves the loops into the inner function which leads to better results. ``` old: test vec::bench_retain_100000 ... bench: 203 828 ns/iter (+/- 2 101) test vec::bench_retain_iter_100000 ... bench: 63 324 ns/iter (+/- 12 305) test vec::bench_retain_whole_100000 ... bench: 42 989 ns/iter (+/- 291) new: test vec::bench_retain_100000 ... bench: 42 180 ns/iter (+/- 451) test vec::bench_retain_iter_100000 ... bench: 65 167 ns/iter (+/- 11 971) test vec::bench_retain_whole_100000 ... bench: 33 736 ns/iter (+/- 12 404) ``` Measured on x86_64-unknown-linux-gnu Zen2 Fixes #91497,THUMBS_UP,2021-12-26T23:47:42Z,lukechu10,NA https://github.com/rust-lang/rust/pull/91531,MERGED,2021-12-04T18:29:55Z,2021-12-08T14:28:39Z,Do not add `;` to expected tokens list when it's wrong,notriddle,87f2c51dcd67553d4106b414621e7d03f1d43b7a,19,Rollup merge of #91531 - notriddle:notriddle/issue-87647-expected-semicolon r=estebank Do not add `;` to expected tokens list when it's wrong There's a few spots where semicolons are checked for to do error recovery and should not be suggested (or checked for other stuff). Fixes #87647,HEART,2021-12-06T16:55:16Z,estebank,NA https://github.com/rust-lang/rust/pull/91544,MERGED,2021-12-05T03:49:08Z,2021-12-23T05:17:48Z,Fix duplicate derive clone suggestion,rukai,d8bf974df56618f75ecd38d7e61fe0d720a9c8c4,3,Rollup merge of #91544 - rukai:91492 r=wesleywiser Fix duplicate derive clone suggestion closes https://github.com/rust-lang/rust/issues/91492 The addition of: ```rust derives.sort(); derives.dedup(); ``` is what actually solves the problem. The rest is just cleanup. I want to improve the diagnostic message to provide the suggestion as a proper diff but ran into some problems so I'll attempt that again in a follow up PR.,ROCKET,2021-12-05T17:05:19Z,eopb,NA https://github.com/rust-lang/rust/pull/91548,MERGED,2021-12-05T08:34:39Z,2021-12-11T21:57:17Z,Add spin_loop hint for RISC-V architecture,luojia65,60b9f3130d1e41cf6c53ea8159ac44457ea8fe04,2,Rollup merge of #91548 - luojia65:hint-spin-loop-riscv r=Amanieu Add spin_loop hint for RISC-V architecture This commit uses the PAUSE instruction (https://github.com/rust-lang/stdarch/pull/1262) to implement RISC-V spin loop and updates `stdarch` submodule to use the merged PAUSE instruction.,ROCKET,2021-12-16T13:06:41Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/91557,MERGED,2021-12-05T17:33:24Z,2022-04-28T01:37:18Z,Perform lifetime resolution on the AST for lowering,cjgillot,c95346b8ac8f10927b4aec31e61d45c75b10ba74,12,Auto merge of #91557 - cjgillot:ast-lifetimes-named r=petrochenkov Perform lifetime resolution on the AST for lowering Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes and once in the resolve_lifetimes query. However due to the global nature of lifetime resolution and how it interferes with hygiene it is better suited on the AST. This PR implements a first draft of lifetime resolution on the AST. For now we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST. We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics` which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes. r? `@petrochenkov`,EYES,2021-12-06T00:07:45Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/91557,MERGED,2021-12-05T17:33:24Z,2022-04-28T01:37:18Z,Perform lifetime resolution on the AST for lowering,cjgillot,c95346b8ac8f10927b4aec31e61d45c75b10ba74,12,Auto merge of #91557 - cjgillot:ast-lifetimes-named r=petrochenkov Perform lifetime resolution on the AST for lowering Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes and once in the resolve_lifetimes query. However due to the global nature of lifetime resolution and how it interferes with hygiene it is better suited on the AST. This PR implements a first draft of lifetime resolution on the AST. For now we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST. We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics` which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes. r? `@petrochenkov`,EYES,2022-04-01T19:29:20Z,ljedrz,NA https://github.com/rust-lang/rust/pull/91557,MERGED,2021-12-05T17:33:24Z,2022-04-28T01:37:18Z,Perform lifetime resolution on the AST for lowering,cjgillot,c95346b8ac8f10927b4aec31e61d45c75b10ba74,12,Auto merge of #91557 - cjgillot:ast-lifetimes-named r=petrochenkov Perform lifetime resolution on the AST for lowering Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes and once in the resolve_lifetimes query. However due to the global nature of lifetime resolution and how it interferes with hygiene it is better suited on the AST. This PR implements a first draft of lifetime resolution on the AST. For now we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST. We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics` which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes. r? `@petrochenkov`,THUMBS_UP,2022-04-27T23:26:50Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91569,MERGED,2021-12-05T21:36:03Z,2021-12-13T07:30:49Z,Attach range metadata to alignment loads from vtables,erikdesjardins,4a7fb971c939d268abdbd0963cd45d046442f7af,2,Auto merge of #91569 - erikdesjardins:vt-align r=nikic Attach range metadata to alignment loads from vtables ...because alignment is always nonzero[0]. This helps eliminate redundant runtime alignment checks when a DST is a field of a struct whose remaining fields have alignment 1. Fixes #91438. --- [0]: The [reference](https://doc.rust-lang.org/reference/type-layout.html) says that alignment must be at least 1. And in practice the alignment field for all vtables is generated here: https://github.com/rust-lang/rust/blob/772d51f887fa407216860bf8ecf3f1a32fb795b4/compiler/rustc_middle/src/ty/vtable.rs#L68-L90 and is nonzero because [`Align::bytes()`](https://github.com/rust-lang/rust/blob/772d51f887fa407216860bf8ecf3f1a32fb795b4/compiler/rustc_target/src/abi/mod.rs#L547-L549) is always nonzero.,THUMBS_UP,2021-12-05T23:41:03Z,alex65536,NA https://github.com/rust-lang/rust/pull/91569,MERGED,2021-12-05T21:36:03Z,2021-12-13T07:30:49Z,Attach range metadata to alignment loads from vtables,erikdesjardins,4a7fb971c939d268abdbd0963cd45d046442f7af,2,Auto merge of #91569 - erikdesjardins:vt-align r=nikic Attach range metadata to alignment loads from vtables ...because alignment is always nonzero[0]. This helps eliminate redundant runtime alignment checks when a DST is a field of a struct whose remaining fields have alignment 1. Fixes #91438. --- [0]: The [reference](https://doc.rust-lang.org/reference/type-layout.html) says that alignment must be at least 1. And in practice the alignment field for all vtables is generated here: https://github.com/rust-lang/rust/blob/772d51f887fa407216860bf8ecf3f1a32fb795b4/compiler/rustc_middle/src/ty/vtable.rs#L68-L90 and is nonzero because [`Align::bytes()`](https://github.com/rust-lang/rust/blob/772d51f887fa407216860bf8ecf3f1a32fb795b4/compiler/rustc_target/src/abi/mod.rs#L547-L549) is always nonzero.,THUMBS_UP,2021-12-05T23:57:17Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/91570,MERGED,2021-12-05T21:40:55Z,2021-12-08T21:51:11Z,Evaluate inline const pat early and report error if too generic,nbdd0121,67c58327fc6c15ad7e8e15a05c8ff2314cd7ca96,3,Rollup merge of #91570 - nbdd0121:const_typeck r=oli-obk Evaluate inline const pat early and report error if too generic Fix #90150 ````@rustbot```` label: T-compiler F-inline_const,THUMBS_UP,2021-12-06T13:05:35Z,MSxDOS,NA https://github.com/rust-lang/rust/pull/91589,MERGED,2021-12-06T11:27:51Z,2022-02-05T04:32:45Z,impl `Arc::unwrap_or_clone`,derekdreery,6f03bd09ff6ef6402b68b32485f0d25e7f6c0c01,2,Rollup merge of #91589 - derekdreery:arc_unwrap_or_clone r=m-ou-se impl `Arc::unwrap_or_clone` The function gets the inner value cloning only if necessary. The conversation started on [`irlo`](https://internals.rust-lang.org/t/arc-into-inner/15707). If the reviewer think the PR has potential to be merged and does not need an RFC then I will create the corresponding tracking issues and update the PR. ## Alternative names - `into_inner` - `make_owned` - `make_unique` - `take_*` (`take_inner`?),THUMBS_UP,2022-02-02T17:44:00Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/91593,MERGED,2021-12-06T14:29:48Z,2022-01-02T03:21:32Z,Remove unnecessary bounds for some Hash{Map Set} methods,upsuper,5137f7c9db44f2f4b4bb0300506aeb0d7483e35f,2,Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound r=dtolnay Remove unnecessary bounds for some Hash{Map Set} methods This PR moves `HashMap::{into_keys into_values retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys into_values}` on par with `HashMap::{keys values values_mut}` which are not bounded either.,HOORAY,2022-02-23T17:16:36Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91593,MERGED,2021-12-06T14:29:48Z,2022-01-02T03:21:32Z,Remove unnecessary bounds for some Hash{Map Set} methods,upsuper,5137f7c9db44f2f4b4bb0300506aeb0d7483e35f,2,Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound r=dtolnay Remove unnecessary bounds for some Hash{Map Set} methods This PR moves `HashMap::{into_keys into_values retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys into_values}` on par with `HashMap::{keys values values_mut}` which are not bounded either.,HEART,2022-02-23T17:16:39Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91593,MERGED,2021-12-06T14:29:48Z,2022-01-02T03:21:32Z,Remove unnecessary bounds for some Hash{Map Set} methods,upsuper,5137f7c9db44f2f4b4bb0300506aeb0d7483e35f,2,Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound r=dtolnay Remove unnecessary bounds for some Hash{Map Set} methods This PR moves `HashMap::{into_keys into_values retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys into_values}` on par with `HashMap::{keys values values_mut}` which are not bounded either.,HOORAY,2022-02-25T12:58:38Z,weihanglo,NA https://github.com/rust-lang/rust/pull/91593,MERGED,2021-12-06T14:29:48Z,2022-01-02T03:21:32Z,Remove unnecessary bounds for some Hash{Map Set} methods,upsuper,5137f7c9db44f2f4b4bb0300506aeb0d7483e35f,2,Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound r=dtolnay Remove unnecessary bounds for some Hash{Map Set} methods This PR moves `HashMap::{into_keys into_values retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys into_values}` on par with `HashMap::{keys values values_mut}` which are not bounded either.,HOORAY,2022-03-11T02:11:58Z,JarvisCraft,me@progrm-jarvis.ru https://github.com/rust-lang/rust/pull/91604,MERGED,2021-12-06T20:43:03Z,2021-12-08T18:45:11Z,Use object crate for .rustc metadata generation,nikic,f9e77f2b460492013cea459221194318b7fd8204,12,Auto merge of #91604 - nikic:section-flags r=nagisa Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts while .rustc should be part of shared objects but not loaded into memory. The primary motivation for this change is #90326: In LLVM 14 the current way of setting section flags (and in particular preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this but switching to the object crate seems like the most elegant as we already use it for .rmeta and as it makes this independent of the codegen backend. In particular we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well though I have omitted that here as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it and directly produce the compiled module instead. This does not `fix` #90326 by itself yet as .llvmbc will need to be handled separately. r? `@nagisa`,HEART,2021-12-06T22:51:57Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/91604,MERGED,2021-12-06T20:43:03Z,2021-12-08T18:45:11Z,Use object crate for .rustc metadata generation,nikic,f9e77f2b460492013cea459221194318b7fd8204,12,Auto merge of #91604 - nikic:section-flags r=nagisa Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts while .rustc should be part of shared objects but not loaded into memory. The primary motivation for this change is #90326: In LLVM 14 the current way of setting section flags (and in particular preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this but switching to the object crate seems like the most elegant as we already use it for .rmeta and as it makes this independent of the codegen backend. In particular we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well though I have omitted that here as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it and directly produce the compiled module instead. This does not `fix` #90326 by itself yet as .llvmbc will need to be handled separately. r? `@nagisa`,HEART,2021-12-07T12:27:48Z,faptc,NA https://github.com/rust-lang/rust/pull/91604,MERGED,2021-12-06T20:43:03Z,2021-12-08T18:45:11Z,Use object crate for .rustc metadata generation,nikic,f9e77f2b460492013cea459221194318b7fd8204,12,Auto merge of #91604 - nikic:section-flags r=nagisa Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts while .rustc should be part of shared objects but not loaded into memory. The primary motivation for this change is #90326: In LLVM 14 the current way of setting section flags (and in particular preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this but switching to the object crate seems like the most elegant as we already use it for .rmeta and as it makes this independent of the codegen backend. In particular we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well though I have omitted that here as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it and directly produce the compiled module instead. This does not `fix` #90326 by itself yet as .llvmbc will need to be handled separately. r? `@nagisa`,HEART,2021-12-07T15:07:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91604,MERGED,2021-12-06T20:43:03Z,2021-12-08T18:45:11Z,Use object crate for .rustc metadata generation,nikic,f9e77f2b460492013cea459221194318b7fd8204,12,Auto merge of #91604 - nikic:section-flags r=nagisa Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts while .rustc should be part of shared objects but not loaded into memory. The primary motivation for this change is #90326: In LLVM 14 the current way of setting section flags (and in particular preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this but switching to the object crate seems like the most elegant as we already use it for .rmeta and as it makes this independent of the codegen backend. In particular we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well though I have omitted that here as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well and adjusts the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it and directly produce the compiled module instead. This does not `fix` #90326 by itself yet as .llvmbc will need to be handled separately. r? `@nagisa`,HEART,2021-12-11T14:47:46Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/91606,MERGED,2021-12-06T22:12:11Z,2022-01-20T23:48:13Z,Stabilize `-Z print-link-args` as `--print link-args`,joshtriplett,02379e917b2e187997bdabd290e61ecf0744faaf,13,Rollup merge of #91606 - joshtriplett:stabilize-print-link-args r=pnkfelix Stabilize `-Z print-link-args` as `--print link-args` We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments. Add documentation for the new option. In the documentation make it clear that the *exact* format of the output is not a stable guarantee.,THUMBS_UP,2021-12-07T21:30:05Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91606,MERGED,2021-12-06T22:12:11Z,2022-01-20T23:48:13Z,Stabilize `-Z print-link-args` as `--print link-args`,joshtriplett,02379e917b2e187997bdabd290e61ecf0744faaf,13,Rollup merge of #91606 - joshtriplett:stabilize-print-link-args r=pnkfelix Stabilize `-Z print-link-args` as `--print link-args` We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments. Add documentation for the new option. In the documentation make it clear that the *exact* format of the output is not a stable guarantee.,THUMBS_UP,2022-01-18T14:17:25Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/91606,MERGED,2021-12-06T22:12:11Z,2022-01-20T23:48:13Z,Stabilize `-Z print-link-args` as `--print link-args`,joshtriplett,02379e917b2e187997bdabd290e61ecf0744faaf,13,Rollup merge of #91606 - joshtriplett:stabilize-print-link-args r=pnkfelix Stabilize `-Z print-link-args` as `--print link-args` We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments. Add documentation for the new option. In the documentation make it clear that the *exact* format of the output is not a stable guarantee.,THUMBS_UP,2022-01-28T00:25:20Z,tmandry,NA https://github.com/rust-lang/rust/pull/91617,MERGED,2021-12-07T02:58:04Z,2021-12-11T18:56:58Z,Improve the readability of `List`.,nnethercote,1de7815ebb9a001a07625b4bff7518b057b1ac22,1,Rollup merge of #91617 - nnethercote:improve-List-readability r=lcnr Improve the readability of `List`. This commit does the following. - Expands on some of the things already mentioned in comments. - Describes the uniqueness assumption which is critical but wasn't mentioned at all. - Rewrites `empty()` into a clearer form as provided by Daniel Henry-Mantilla on Zulip. - Reorders things slightly so that more important things are higher up and incidental things are lower down which makes reading the code easier. r? ````@lcnr````,THUMBS_UP,2021-12-07T15:29:41Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/91630,MERGED,2021-12-07T14:13:18Z,2021-12-08T21:51:11Z,Add missing whitespace before disabled HTML attribute,GuillaumeGomez,382426be34fe0d5fda38068bb60ed1ac06ebd4c8,1,Rollup merge of #91630 - GuillaumeGomez:missing-whitespace r=notriddle Add missing whitespace before disabled HTML attribute On the [w3c HTML checker](https://validator.w3.org/nu/#textarea) with the current generated HTML we get: ![Screenshot from 2021-12-07 15-10-38](https://user-images.githubusercontent.com/3050060/145044653-b38fb679-da76-4890-853f-b696d8fdc06e.png) The problem was that we were telling tera to remove too many whitespace. r? ````@notriddle````,HEART,2021-12-08T02:32:32Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/91637,MERGED,2021-12-07T19:07:41Z,2021-12-09T04:04:04Z,Add test for packed drops in generators,tmiasko,1aa2007eca41c18930922b4eaa061e7f6183ef56,1,Rollup merge of #91637 - tmiasko:generator-packed-drop r=ecstatic-morse Add test for packed drops in generators r? ```@ecstatic-morse```,THUMBS_UP,2021-12-08T16:19:55Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/91641,MERGED,2021-12-07T21:45:16Z,2022-01-28T01:33:08Z,Define c_char using cfg_if rather than repeating 40-line cfg,dtolnay,4af3930f28d6e508d84664e7f066430284aa9ea1,1,Rollup merge of #91641 - dtolnay:cchar-if r=Mark-Simulacrum Define c_char using cfg_if rather than repeating 40-line cfg Libstd has a 40-line cfg that defines the targets on which `c_char` is unsigned and then repeats the same cfg with `not(…)` for the targets on which `c_char` is signed. This PR replaces it with a `cfg_if!` in which an `else` takes care of the signed case. I confirmed that `x.py doc library/std` inlines the type alias because c_char_definition is not a publicly accessible path: ![Screenshot from 2021-12-07 13-42-07](https://user-images.githubusercontent.com/1940490/145110596-f1058406-9f32-44ff-9a81-1dfd19b4a24f.png),ROCKET,2021-12-08T09:08:29Z,mati865,NA https://github.com/rust-lang/rust/pull/91643,MERGED,2021-12-07T23:48:30Z,2021-12-12T03:50:22Z,asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target,Amanieu,443ed7c6203608def39739b21a50a8e7a0f4e428,7,Rollup merge of #91643 - Amanieu:r9x18 r=joshtriplett asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target This supersedes https://github.com/rust-lang/rust/pull/88879. cc `@Skirmisher` r? `@joshtriplett`,ROCKET,2021-12-07T23:52:49Z,Skirmisher,NA https://github.com/rust-lang/rust/pull/91643,MERGED,2021-12-07T23:48:30Z,2021-12-12T03:50:22Z,asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target,Amanieu,443ed7c6203608def39739b21a50a8e7a0f4e428,7,Rollup merge of #91643 - Amanieu:r9x18 r=joshtriplett asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target This supersedes https://github.com/rust-lang/rust/pull/88879. cc `@Skirmisher` r? `@joshtriplett`,ROCKET,2021-12-08T00:17:29Z,Urgau,NA https://github.com/rust-lang/rust/pull/91645,MERGED,2021-12-08T02:02:12Z,2021-12-09T07:08:37Z,Implement `core::future::join!`,ibraheemdev,90c3e9a2c226a89b5e4b6de3cd4a53a655784295,4,Rollup merge of #91645 - ibraheemdev:future-join r=joshtriplett Implement `core::future::join!` `join!` polls multiple futures concurrently and returns their outputs. ```rust async fn run() { let (a b) = join!(async { 0 } async { 1 }); } ``` cc `@rust-lang/wg-async-foundations`,THUMBS_UP,2021-12-09T20:53:01Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/91645,MERGED,2021-12-08T02:02:12Z,2021-12-09T07:08:37Z,Implement `core::future::join!`,ibraheemdev,90c3e9a2c226a89b5e4b6de3cd4a53a655784295,4,Rollup merge of #91645 - ibraheemdev:future-join r=joshtriplett Implement `core::future::join!` `join!` polls multiple futures concurrently and returns their outputs. ```rust async fn run() { let (a b) = join!(async { 0 } async { 1 }); } ``` cc `@rust-lang/wg-async-foundations`,THUMBS_UP,2021-12-17T00:42:27Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/91654,MERGED,2021-12-08T10:02:54Z,2021-12-13T13:37:57Z,Use module inline assembly to embed bitcode,nikic,a737592a3d8f0f5ec76524c880d226f28bef2c84,1,Auto merge of #91654 - nikic:llvmbc-section-flags r=nagisa Use module inline assembly to embed bitcode In LLVM 14 our current method of setting section flags to avoid embedding the `.llvmbc` section into final compilation artifacts will no longer work see issue #90326. The upstream recommendation is to instead embed the entire bitcode using module-level inline assembly which is what this change does. I've kept the existing code for platforms where we do not need to set section flags but possibly we should always be using the inline asm approach (which would have to look a bit different for MachO). r? `@nagisa`,ROCKET,2021-12-08T12:48:16Z,hkratz,NA https://github.com/rust-lang/rust/pull/91654,MERGED,2021-12-08T10:02:54Z,2021-12-13T13:37:57Z,Use module inline assembly to embed bitcode,nikic,a737592a3d8f0f5ec76524c880d226f28bef2c84,1,Auto merge of #91654 - nikic:llvmbc-section-flags r=nagisa Use module inline assembly to embed bitcode In LLVM 14 our current method of setting section flags to avoid embedding the `.llvmbc` section into final compilation artifacts will no longer work see issue #90326. The upstream recommendation is to instead embed the entire bitcode using module-level inline assembly which is what this change does. I've kept the existing code for platforms where we do not need to set section flags but possibly we should always be using the inline asm approach (which would have to look a bit different for MachO). r? `@nagisa`,ROCKET,2021-12-08T21:07:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91673,MERGED,2021-12-08T21:16:07Z,2022-02-13T14:28:42Z,`std::path::absolute`,ChrisDenton,1f4681ad7a132755452c32a987ad0f0d075aa6aa,7,Auto merge of #91673 - ChrisDenton:path-absolute r=Mark-Simulacrum `std::path::absolute` Implements #59117 by adding a `std::path::absolute` function that creates an absolute path without reading the filesystem. This is intended to be a drop-in replacement for [`std::fs::canonicalize`](https://doc.rust-lang.org/std/fs/fn.canonicalize.html) in cases where it isn't necessary to resolve symlinks. It can be used on paths that don't exist or where resolving symlinks is unwanted. It can also be used to avoid circumstances where `canonicalize` might otherwise fail. On Windows this is a wrapper around [`GetFullPathNameW`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew). On Unix it partially implements the POSIX [pathname resolution](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13) specification stopping just short of actually resolving symlinks.,HEART,2022-02-17T14:05:31Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/91673,MERGED,2021-12-08T21:16:07Z,2022-02-13T14:28:42Z,`std::path::absolute`,ChrisDenton,1f4681ad7a132755452c32a987ad0f0d075aa6aa,7,Auto merge of #91673 - ChrisDenton:path-absolute r=Mark-Simulacrum `std::path::absolute` Implements #59117 by adding a `std::path::absolute` function that creates an absolute path without reading the filesystem. This is intended to be a drop-in replacement for [`std::fs::canonicalize`](https://doc.rust-lang.org/std/fs/fn.canonicalize.html) in cases where it isn't necessary to resolve symlinks. It can be used on paths that don't exist or where resolving symlinks is unwanted. It can also be used to avoid circumstances where `canonicalize` might otherwise fail. On Windows this is a wrapper around [`GetFullPathNameW`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew). On Unix it partially implements the POSIX [pathname resolution](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13) specification stopping just short of actually resolving symlinks.,HEART,2022-02-17T15:47:03Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/91673,MERGED,2021-12-08T21:16:07Z,2022-02-13T14:28:42Z,`std::path::absolute`,ChrisDenton,1f4681ad7a132755452c32a987ad0f0d075aa6aa,7,Auto merge of #91673 - ChrisDenton:path-absolute r=Mark-Simulacrum `std::path::absolute` Implements #59117 by adding a `std::path::absolute` function that creates an absolute path without reading the filesystem. This is intended to be a drop-in replacement for [`std::fs::canonicalize`](https://doc.rust-lang.org/std/fs/fn.canonicalize.html) in cases where it isn't necessary to resolve symlinks. It can be used on paths that don't exist or where resolving symlinks is unwanted. It can also be used to avoid circumstances where `canonicalize` might otherwise fail. On Windows this is a wrapper around [`GetFullPathNameW`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew). On Unix it partially implements the POSIX [pathname resolution](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13) specification stopping just short of actually resolving symlinks.,HEART,2022-02-24T17:00:08Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91673,MERGED,2021-12-08T21:16:07Z,2022-02-13T14:28:42Z,`std::path::absolute`,ChrisDenton,1f4681ad7a132755452c32a987ad0f0d075aa6aa,7,Auto merge of #91673 - ChrisDenton:path-absolute r=Mark-Simulacrum `std::path::absolute` Implements #59117 by adding a `std::path::absolute` function that creates an absolute path without reading the filesystem. This is intended to be a drop-in replacement for [`std::fs::canonicalize`](https://doc.rust-lang.org/std/fs/fn.canonicalize.html) in cases where it isn't necessary to resolve symlinks. It can be used on paths that don't exist or where resolving symlinks is unwanted. It can also be used to avoid circumstances where `canonicalize` might otherwise fail. On Windows this is a wrapper around [`GetFullPathNameW`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew). On Unix it partially implements the POSIX [pathname resolution](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13) specification stopping just short of actually resolving symlinks.,HEART,2022-03-17T10:07:51Z,ajeetdsouza,98ajeet@gmail.com https://github.com/rust-lang/rust/pull/91675,MERGED,2021-12-08T21:34:12Z,2022-02-19T05:08:23Z,Add MemTagSanitizer Support,ivanloz,0bb72a2c66d0daa417baa27eaf2d276d835b87a2,15,"Rollup merge of #91675 - ivanloz:memtagsan r=nagisa Add MemTagSanitizer Support Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html). On hardware which supports it (see caveats below) the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer but with lower overhead. On a tag mismatch a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR. # Usage `-Zsanitizer=memtag -C target-feature=""+mte""` # Comments/Caveats * MemTagSanitizer is only supported on AArch64 targets with hardware support * Requires `-C target-feature=""+mte""` * LLVM MemTagSanitizer currently only performs stack tagging. # TODO * Tests * Example",THUMBS_UP,2021-12-08T21:40:28Z,marmeladema,NA https://github.com/rust-lang/rust/pull/91678,MERGED,2021-12-08T22:40:35Z,2021-12-11T06:58:24Z,Add tests fixed by #90023,b-naber,d6e941778abfb11b4a35fce47c09c68ffab04e5b,8,Rollup merge of #91678 - b-naber:tests-for-postpone-const-eval r=jackh726 Add tests fixed by #90023 The following issues were fixed by https://github.com/rust-lang/rust/pull/90023 Fixes https://github.com/rust-lang/rust/issues/79674 Fixes https://github.com/rust-lang/rust/issues/83765 Fixes https://github.com/rust-lang/rust/issues/86033 Fixes https://github.com/rust-lang/rust/issues/90318 Fixes https://github.com/rust-lang/rust/issues/88468 The following issues were duplicates of https://github.com/rust-lang/rust/issues/90654 Fixes https://github.com/rust-lang/rust/issues/86850 Fixes https://github.com/rust-lang/rust/issues/89022 r? ````@jackh726````,HOORAY,2021-12-08T22:58:10Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/91678,MERGED,2021-12-08T22:40:35Z,2021-12-11T06:58:24Z,Add tests fixed by #90023,b-naber,d6e941778abfb11b4a35fce47c09c68ffab04e5b,8,Rollup merge of #91678 - b-naber:tests-for-postpone-const-eval r=jackh726 Add tests fixed by #90023 The following issues were fixed by https://github.com/rust-lang/rust/pull/90023 Fixes https://github.com/rust-lang/rust/issues/79674 Fixes https://github.com/rust-lang/rust/issues/83765 Fixes https://github.com/rust-lang/rust/issues/86033 Fixes https://github.com/rust-lang/rust/issues/90318 Fixes https://github.com/rust-lang/rust/issues/88468 The following issues were duplicates of https://github.com/rust-lang/rust/issues/90654 Fixes https://github.com/rust-lang/rust/issues/86850 Fixes https://github.com/rust-lang/rust/issues/89022 r? ````@jackh726````,HOORAY,2021-12-09T09:28:35Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/91678,MERGED,2021-12-08T22:40:35Z,2021-12-11T06:58:24Z,Add tests fixed by #90023,b-naber,d6e941778abfb11b4a35fce47c09c68ffab04e5b,8,Rollup merge of #91678 - b-naber:tests-for-postpone-const-eval r=jackh726 Add tests fixed by #90023 The following issues were fixed by https://github.com/rust-lang/rust/pull/90023 Fixes https://github.com/rust-lang/rust/issues/79674 Fixes https://github.com/rust-lang/rust/issues/83765 Fixes https://github.com/rust-lang/rust/issues/86033 Fixes https://github.com/rust-lang/rust/issues/90318 Fixes https://github.com/rust-lang/rust/issues/88468 The following issues were duplicates of https://github.com/rust-lang/rust/issues/90654 Fixes https://github.com/rust-lang/rust/issues/86850 Fixes https://github.com/rust-lang/rust/issues/89022 r? ````@jackh726````,HOORAY,2021-12-09T12:57:17Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/91682,MERGED,2021-12-09T00:10:42Z,2021-12-11T18:56:58Z,rustdoc: Show type layout for type aliases,camelid,33ebf4de9648d3dd8711d518cf5d213886330607,2,"Rollup merge of #91682 - camelid:alias-layout r=jyn514 rustdoc: Show type layout for type aliases Fixes #91265. At first you might think ""Why not just click through to the aliased type?"" But if a type alias instantiates all of the generic parameters of the aliased type then it can show layout info even though the aliased type cannot (because we can't compute layout for generic types). So I think it's useful to show layout info for type aliases. This is a followup of 78d4b453ad2e19d44011b26fc55c949bff5dba3d (originally part of #83501).",HEART,2021-12-17T01:03:19Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/91684,CLOSED,2021-12-09T00:27:01Z,2022-03-20T05:52:43Z,Add `core::stream::pending`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-03-20T12:22:37Z,zeenix,zeeshanak@gnome.org https://github.com/rust-lang/rust/pull/91697,MERGED,2021-12-09T07:14:46Z,2021-12-11T06:58:23Z,Delete Utf8Lossy::from_str,dtolnay,2784051c11c07c204b9ac3891739b20298939a3d,1,"Rollup merge of #91697 - dtolnay:lossyfromstr r=Mark-Simulacrum Delete Utf8Lossy::from_str This whole type is marked as being for str internals only but this constructor is never used by str internals. If you had a &str already and wanted to lossy display it or iterate its lossy utf8 chunks you would simply not use Utf8Lossy because the whole &str is known to be one contiguous valid utf8 chunk. If code really does need to obtain a value of type &Utf8Lossy somewhere and has only a &str `Utf8Lossy::from_bytes(s.as_bytes())` remains available. As currently implemented there is no performance penalty relative to `from_str` i.e. the Utf8Lossy does not ""remember"" that it was constructed using `from_str` to bypass later utf8 decoding.",THUMBS_UP,2021-12-09T20:23:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91715,MERGED,2021-12-09T17:02:45Z,2021-12-11T03:52:10Z,Bump rmeta version to fix rustc_serialize ICE,the8472,82575a1d6f02a3932fcfa36562368f5e095d93ba,1,Auto merge of #91715 - the8472:bump-rmeta-fromat-version r=Mark-Simulacrum Bump rmeta version to fix rustc_serialize ICE #91407 changed the serialization format which leads to ICEs for nightly users such as #91663 and linked issues. The issue can be solved by running `cargo clean`. But bumping the metadata version should lead to the cached files being discarded avoiding the issue entirely.,THUMBS_UP,2021-12-12T21:57:39Z,gakonst,me@gakonst.com https://github.com/rust-lang/rust/pull/91720,MERGED,2021-12-09T18:21:45Z,2021-12-11T09:58:43Z,Don't copy llvm tools to sysroot when using download-ci-llvm,Aaron1011,4a66a704b2c3d30ff07d89380ebb9ba3de3b3182,1,Auto merge of #91720 - Aaron1011:skip-llvm-ci-tools r=Mark-Simulacrum Don't copy llvm tools to sysroot when using download-ci-llvm Fixes #91710,ROCKET,2021-12-10T18:26:15Z,estebank,NA https://github.com/rust-lang/rust/pull/91721,MERGED,2021-12-09T18:42:53Z,2021-12-11T21:57:17Z,Minor improvements to `future::join!`'s implementation,danielhenrymantilla,ed81098fcca409261db3408115725d07729ac39a,3,Rollup merge of #91721 - danielhenrymantilla:patch-1 r=joshtriplett Minor improvements to `future::join!`'s implementation This is a follow-up from #91645 regarding [some remarks I made](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/join!/near/264293660). Mainly: - it hides the recursive munching through a private `macro` to avoid leaking such details (a corollary is getting rid of the need to use ``@`` to disambiguate); - it uses a `match` binding _outside_ the `async move` block to better match the semantics from function-like syntax; - it pre-pins the future before calling into `poll_fn` since `poll_fn` alone cannot guarantee that its capture does not move (to clarify: I believe the previous code was sound thanks to the outer layer of `async`. But I find it clearer / more robust to refactorings this way 🙂). - it uses `@ibraheemdev's` very neat `.ready()?`; - it renames `Took` to `Taken` for consistency with `Done` (tiny nit 😄). ~~TODO~~Done: - [x] Add unit tests to enforce the function-like `:value` semantics are respected. r? `@nrc`,THUMBS_UP,2021-12-09T18:54:50Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/91721,MERGED,2021-12-09T18:42:53Z,2021-12-11T21:57:17Z,Minor improvements to `future::join!`'s implementation,danielhenrymantilla,ed81098fcca409261db3408115725d07729ac39a,3,Rollup merge of #91721 - danielhenrymantilla:patch-1 r=joshtriplett Minor improvements to `future::join!`'s implementation This is a follow-up from #91645 regarding [some remarks I made](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/join!/near/264293660). Mainly: - it hides the recursive munching through a private `macro` to avoid leaking such details (a corollary is getting rid of the need to use ``@`` to disambiguate); - it uses a `match` binding _outside_ the `async move` block to better match the semantics from function-like syntax; - it pre-pins the future before calling into `poll_fn` since `poll_fn` alone cannot guarantee that its capture does not move (to clarify: I believe the previous code was sound thanks to the outer layer of `async`. But I find it clearer / more robust to refactorings this way 🙂). - it uses `@ibraheemdev's` very neat `.ready()?`; - it renames `Took` to `Taken` for consistency with `Done` (tiny nit 😄). ~~TODO~~Done: - [x] Add unit tests to enforce the function-like `:value` semantics are respected. r? `@nrc`,THUMBS_UP,2021-12-09T20:08:04Z,r00ster91,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T00:51:01Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T01:04:34Z,camelid,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T01:20:03Z,mikeleany,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T01:49:36Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T01:58:32Z,asquared31415,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T02:01:15Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T02:07:01Z,ZuseZ4,git@manuel.drehwald.info https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T02:43:49Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T03:01:06Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T03:02:37Z,jackh726,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T03:02:39Z,Eucladia,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T04:06:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T04:29:55Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T06:06:02Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T06:13:15Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T06:40:34Z,panaman67,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T06:41:47Z,faptc,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T07:51:56Z,garasubo,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T08:00:47Z,est31,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T08:24:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-10T08:24:38Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T08:46:10Z,marmeladema,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T09:26:59Z,CryZe,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-10T10:12:30Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T10:21:25Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T11:53:01Z,adamgemmell,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-10T17:55:46Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-11T00:39:19Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T00:42:31Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T00:49:14Z,cynecx,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T01:03:56Z,sfackler,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T02:43:58Z,taiki-e,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T10:45:26Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T10:54:14Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-11T17:43:48Z,sksat,sksat@sksat.net https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-12T04:02:32Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-13T02:13:10Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-13T04:15:25Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-14T12:25:31Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-14T12:25:33Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-14T14:23:58Z,mati865,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-14T14:24:00Z,mati865,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-14T15:43:39Z,pierwill,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-14T15:43:40Z,pierwill,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-14T20:22:53Z,clemenswasser,clemens.wasser@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-14T20:29:40Z,KOBA789,kobahide789@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-16T11:33:54Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-19T22:20:31Z,yerke,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-19T22:20:32Z,yerke,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-19T22:20:36Z,yerke,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-20T07:24:53Z,toku-sa-n,tokusan441@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-21T09:39:01Z,phip1611,phip1611@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-22T08:03:56Z,felix-rs,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T01:39:41Z,tux3,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-23T01:39:42Z,tux3,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-23T01:39:42Z,tux3,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T02:53:47Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T04:13:18Z,DuckDuckWhale,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T08:32:26Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T09:15:53Z,joboet,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T12:12:20Z,aznhe21,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-23T13:02:18Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T13:47:50Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2021-12-23T13:47:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-23T13:47:52Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-23T18:15:26Z,icewind1991,robin@icewind.nl https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2021-12-24T09:06:48Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2021-12-24T13:30:52Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-04T22:53:55Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-01-04T22:53:57Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-05T13:51:02Z,mamins1376,mamins1376@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-01-08T09:00:14Z,Disasm,admin@disasm.info https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-10T19:37:59Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-12T14:54:01Z,unageek,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-13T14:01:54Z,tomaka,pierre.krieger1708@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-01-13T19:53:41Z,pstephens,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-14T21:54:55Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-01-14T21:54:56Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-15T00:28:23Z,uniphil,uniphil@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-17T10:00:32Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-01-17T10:00:33Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-17T12:50:27Z,trickster,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-17T18:30:51Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-01-17T18:30:52Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-01-20T15:04:19Z,pro465,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-01-20T15:04:20Z,pro465,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-01-20T15:04:22Z,pro465,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-01-31T04:35:36Z,dnrusakov,dnrusakov@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-01T13:29:49Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-02T05:35:40Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-02T10:04:25Z,PeterWrighten,peterwrighten@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-09T22:02:39Z,tmandry,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-02-09T22:02:42Z,tmandry,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-02-09T22:02:43Z,tmandry,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-15T03:24:28Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-21T20:13:40Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-22T17:31:00Z,robinhundt,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-23T07:39:32Z,mormahr,contact@mahringer.dev https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-23T10:51:12Z,qthree,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-23T14:05:00Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-02-23T14:05:01Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-23T17:11:04Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-02-23T17:11:05Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-02-23T17:11:06Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HOORAY,2022-02-23T18:03:18Z,iago-lito,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-02-23T18:03:19Z,iago-lito,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,ROCKET,2022-02-23T18:03:21Z,iago-lito,NA https://github.com/rust-lang/rust/pull/91728,MERGED,2021-12-10T00:48:46Z,2021-12-15T00:23:52Z,Stabilize asm! and global_asm!,Amanieu,2f4da6243f817b26c5c8156408911a01b39f9759,141,Auto merge of #91728 - Amanieu:stable_asm r=joshtriplett Stabilize asm! and global_asm! Tracking issue: #72016 It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature! The main changes in this PR are: - Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228. - Stabilizing the `asm` and `global_asm` features. - Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483). - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example. - Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`. - Updating `stdarch` and `compiler-builtins`. - Updating all the tests. r? `@joshtriplett`,HEART,2022-04-08T15:21:58Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/91737,MERGED,2021-12-10T07:57:53Z,2021-12-12T03:50:21Z,Make certain panicky stdlib functions behave better under panic_immediate_abort,Manishearth,90eb610d143e8b81de57ab4f0ade6354e3e26022,3,"Rollup merge of #91737 - Manishearth:panic-immediate-stdlib r=joshtriplett Make certain panicky stdlib functions behave better under panic_immediate_abort The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations. Unfortunately this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()` while the formatting machinery is reduced `expect()` and `unwrap()` both call `unwrap_failed(""msg"" &err)` which has a signature of `fn unwrap_failed(msg: &str error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function. Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused. This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib). I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.",HOORAY,2021-12-10T08:20:00Z,sffc,NA https://github.com/rust-lang/rust/pull/91737,MERGED,2021-12-10T07:57:53Z,2021-12-12T03:50:21Z,Make certain panicky stdlib functions behave better under panic_immediate_abort,Manishearth,90eb610d143e8b81de57ab4f0ade6354e3e26022,3,"Rollup merge of #91737 - Manishearth:panic-immediate-stdlib r=joshtriplett Make certain panicky stdlib functions behave better under panic_immediate_abort The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations. Unfortunately this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()` while the formatting machinery is reduced `expect()` and `unwrap()` both call `unwrap_failed(""msg"" &err)` which has a signature of `fn unwrap_failed(msg: &str error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function. Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused. This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib). I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.",HOORAY,2021-12-10T08:23:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91737,MERGED,2021-12-10T07:57:53Z,2021-12-12T03:50:21Z,Make certain panicky stdlib functions behave better under panic_immediate_abort,Manishearth,90eb610d143e8b81de57ab4f0ade6354e3e26022,3,"Rollup merge of #91737 - Manishearth:panic-immediate-stdlib r=joshtriplett Make certain panicky stdlib functions behave better under panic_immediate_abort The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations. Unfortunately this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()` while the formatting machinery is reduced `expect()` and `unwrap()` both call `unwrap_failed(""msg"" &err)` which has a signature of `fn unwrap_failed(msg: &str error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function. Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused. This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib). I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.",HOORAY,2021-12-10T08:25:41Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/91737,MERGED,2021-12-10T07:57:53Z,2021-12-12T03:50:21Z,Make certain panicky stdlib functions behave better under panic_immediate_abort,Manishearth,90eb610d143e8b81de57ab4f0ade6354e3e26022,3,"Rollup merge of #91737 - Manishearth:panic-immediate-stdlib r=joshtriplett Make certain panicky stdlib functions behave better under panic_immediate_abort The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations. Unfortunately this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()` while the formatting machinery is reduced `expect()` and `unwrap()` both call `unwrap_failed(""msg"" &err)` which has a signature of `fn unwrap_failed(msg: &str error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function. Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused. This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib). I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.",HOORAY,2021-12-10T10:43:24Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/91737,MERGED,2021-12-10T07:57:53Z,2021-12-12T03:50:21Z,Make certain panicky stdlib functions behave better under panic_immediate_abort,Manishearth,90eb610d143e8b81de57ab4f0ade6354e3e26022,3,"Rollup merge of #91737 - Manishearth:panic-immediate-stdlib r=joshtriplett Make certain panicky stdlib functions behave better under panic_immediate_abort The stdlib has a `panic_immediate_abort` feature that turns panics into immediate aborts without any formatting/display logic. This feature was [introduced](https://github.com/rust-lang/rust/pull/55011) primarily for codesize-constrained situations. Unfortunately this win doesn't quite propagate to `Result::expect()` and `Result::unwrap()` while the formatting machinery is reduced `expect()` and `unwrap()` both call `unwrap_failed(""msg"" &err)` which has a signature of `fn unwrap_failed(msg: &str error: &dyn fmt::Debug)` and is `#[inline(never)]`. This means that `unwrap_failed` will unconditionally construct a `dyn Debug` trait object even though the object is never used in the function. Constructing a trait object (even if you never call a method on it!) forces rust to include the vtable and any dependencies. This means that in `panic_immediate_abort` mode calling expect/unwrap on a Result will pull in a whole bunch of formatting code for the error type even if it's completely unused. This PR swaps out the function with one that won't require a trait object such that it won't force the inclusion of vtables in the code. It also gates off `#[inline(never)]` in a bunch of other places where allowing the inlining of an abort may be useful (this kind of thing is already done elsewhere in the stdlib). I don't know how to write a test for this; we don't really seem to have any tests for `panic_immediate_abort` anyway so perhaps it's fine as is.",HOORAY,2021-12-10T14:05:59Z,DianaNites,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-10T12:36:47Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-10T12:43:30Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-10T15:15:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-10T15:27:09Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-10T15:27:12Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-10T16:12:26Z,bugadani,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-10T22:19:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-10T22:19:16Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-11T02:58:49Z,faptc,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-14T14:33:48Z,mati865,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2021-12-14T14:33:49Z,mati865,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2021-12-18T16:22:26Z,bjorn3,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-02-05T17:31:20Z,crlf0710,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-02-05T17:31:27Z,crlf0710,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-02-28T18:54:44Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,THUMBS_UP,2022-05-10T17:38:22Z,Agrailag,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-05-17T21:08:16Z,Agrailag,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-07-03T07:26:59Z,Lokathor,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,THUMBS_UP,2022-07-03T07:27:00Z,Lokathor,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-03T07:27:02Z,Lokathor,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,ROCKET,2022-07-03T07:27:04Z,Lokathor,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,EYES,2022-07-03T07:27:06Z,Lokathor,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-03T07:28:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-07-03T07:28:43Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,ROCKET,2022-07-03T07:28:43Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-07T02:42:22Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,THUMBS_UP,2022-07-07T04:12:05Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-07T04:12:05Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-07-07T04:12:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,ROCKET,2022-07-07T04:12:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,EYES,2022-07-07T04:12:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-07T19:06:44Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-07T23:10:22Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HEART,2022-07-07T23:10:23Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,THUMBS_UP,2022-07-07T23:10:24Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,ROCKET,2022-07-07T23:10:25Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/91743,MERGED,2021-12-10T12:24:10Z,2022-07-02T14:06:31Z,Enable MIR inlining,cjgillot,0075bb4fad68e64b6d1be06bf2db366c30bc75e1,36,Auto merge of #91743 - cjgillot:enable_mir_inlining_inline_all r=oli-obk Enable MIR inlining Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.` #82280 has shown nice compile time wins could be obtained by enabling MIR inlining. Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed except the interaction with polymorphization which is worked around specifically. I believe we can proceed with enabling MIR inlining in the near future (preferably just after beta branching in case we discover new issues). Steps before merging: - [x] figure out the interaction with polymorphization; - [x] figure out how miri should deal with extern types; - [x] silence the extra arithmetic overflow warnings; - [x] remove the codegen fulfilment ICE; - [x] remove the type normalization ICEs while compiling nalgebra; - [ ] tweak the inlining threshold.,HOORAY,2022-07-08T06:42:16Z,rgwood,NA https://github.com/rust-lang/rust/pull/91752,MERGED,2021-12-10T17:38:23Z,2021-12-15T09:32:05Z,Readd track_caller to Result::from_residual,yaahc,df89fd2063aaa060c72c81254db0b930ff379e9a,4,Auto merge of #91752 - yaahc:track-caller-result r=cuviper Readd track_caller to Result::from_residual This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution. As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize. --- ### For - https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types - https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic) where panic provides a location and Result does not pushing some users towards using panic ### Against - https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data --- Personally I want to quantify the performance / bloat impact of re-adding this attribute and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type which would also mean I need `try_trait_v2` to be stabilized cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually. Alternatively I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.,THUMBS_UP,2021-12-10T17:53:07Z,jplatte,NA https://github.com/rust-lang/rust/pull/91752,MERGED,2021-12-10T17:38:23Z,2021-12-15T09:32:05Z,Readd track_caller to Result::from_residual,yaahc,df89fd2063aaa060c72c81254db0b930ff379e9a,4,Auto merge of #91752 - yaahc:track-caller-result r=cuviper Readd track_caller to Result::from_residual This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution. As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize. --- ### For - https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types - https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic) where panic provides a location and Result does not pushing some users towards using panic ### Against - https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data --- Personally I want to quantify the performance / bloat impact of re-adding this attribute and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type which would also mean I need `try_trait_v2` to be stabilized cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually. Alternatively I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.,THUMBS_UP,2021-12-11T05:59:25Z,BGR360,benwolverine2019@gmail.com https://github.com/rust-lang/rust/pull/91752,MERGED,2021-12-10T17:38:23Z,2021-12-15T09:32:05Z,Readd track_caller to Result::from_residual,yaahc,df89fd2063aaa060c72c81254db0b930ff379e9a,4,Auto merge of #91752 - yaahc:track-caller-result r=cuviper Readd track_caller to Result::from_residual This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution. As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize. --- ### For - https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types - https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic) where panic provides a location and Result does not pushing some users towards using panic ### Against - https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data --- Personally I want to quantify the performance / bloat impact of re-adding this attribute and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type which would also mean I need `try_trait_v2` to be stabilized cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually. Alternatively I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.,THUMBS_UP,2021-12-15T20:37:47Z,lilyball,lily@ballards.net https://github.com/rust-lang/rust/pull/91752,MERGED,2021-12-10T17:38:23Z,2021-12-15T09:32:05Z,Readd track_caller to Result::from_residual,yaahc,df89fd2063aaa060c72c81254db0b930ff379e9a,4,Auto merge of #91752 - yaahc:track-caller-result r=cuviper Readd track_caller to Result::from_residual This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution. As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize. --- ### For - https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types - https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic) where panic provides a location and Result does not pushing some users towards using panic ### Against - https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data --- Personally I want to quantify the performance / bloat impact of re-adding this attribute and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type which would also mean I need `try_trait_v2` to be stabilized cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually. Alternatively I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.,THUMBS_UP,2021-12-16T03:29:36Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/91752,MERGED,2021-12-10T17:38:23Z,2021-12-15T09:32:05Z,Readd track_caller to Result::from_residual,yaahc,df89fd2063aaa060c72c81254db0b930ff379e9a,4,Auto merge of #91752 - yaahc:track-caller-result r=cuviper Readd track_caller to Result::from_residual This is a followup on https://github.com/rust-lang/rust/issues/87401 in and an attempt to move the issue towards resolution. As part of the overhaul of the Try trait we removed the ability for errors to grab location information during propagation via `?` with the builtin `std::result::Result`. The previously linked issue has a fair bit of discussion into the reasons for and against the usage of `#[track_caller]` on the `FromResidual` impl on `Result` that I will do my best to summarize. --- ### For - https://github.com/rust-lang/rust/issues/87401#issuecomment-915053533: Difficulties with using non `std::result::Result` like types - https://github.com/rust-lang/rust/issues/87401#issuecomment-978355102: Inconsistency with functionality provided for recoverable (Result) and non-recoverable errors (panic) where panic provides a location and Result does not pushing some users towards using panic ### Against - https://github.com/rust-lang/rust/issues/84277#issuecomment-885322833: concern that this will bloat callers that never use this data --- Personally I want to quantify the performance / bloat impact of re-adding this attribute and fully evaluate the pros and cons before deciding if I need to switch `eyre` to have a custom `Result` type which would also mean I need `try_trait_v2` to be stabilized cc `@scottmcm.` If the performance impact is minor enough in the general case I think I would prefer that the default `Result` type has the ability to track location information for consistency with `panic` error reporting and leave it to applications that need particularly high performance to handle the micro optimizations of introducing their own efficient custom Result type or matching manually. Alternatively I wonder if the performance penalty on code that doesn't use the location information on `FromResidual` could be mitigated via new optimizations.,THUMBS_UP,2021-12-23T13:47:07Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91766,MERGED,2021-12-11T01:32:10Z,2021-12-14T11:30:26Z,Allow `memcmp` for more array comparisons,scottmcm,83b32f27fc6c34b0b411f47be31ab4ae07eafed4,1,Auto merge of #91766 - scottmcm:more-array-raw-eq r=yaahc Allow `memcmp` for more array comparisons This way comparing `[NonZeroU8; 8]` is just as fast as comparing `[u8; 8]`.,THUMBS_UP,2021-12-11T07:45:13Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/91766,MERGED,2021-12-11T01:32:10Z,2021-12-14T11:30:26Z,Allow `memcmp` for more array comparisons,scottmcm,83b32f27fc6c34b0b411f47be31ab4ae07eafed4,1,Auto merge of #91766 - scottmcm:more-array-raw-eq r=yaahc Allow `memcmp` for more array comparisons This way comparing `[NonZeroU8; 8]` is just as fast as comparing `[u8; 8]`.,THUMBS_UP,2021-12-11T07:52:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/91766,MERGED,2021-12-11T01:32:10Z,2021-12-14T11:30:26Z,Allow `memcmp` for more array comparisons,scottmcm,83b32f27fc6c34b0b411f47be31ab4ae07eafed4,1,Auto merge of #91766 - scottmcm:more-array-raw-eq r=yaahc Allow `memcmp` for more array comparisons This way comparing `[NonZeroU8; 8]` is just as fast as comparing `[u8; 8]`.,THUMBS_UP,2021-12-11T08:34:42Z,est31,NA https://github.com/rust-lang/rust/pull/91766,MERGED,2021-12-11T01:32:10Z,2021-12-14T11:30:26Z,Allow `memcmp` for more array comparisons,scottmcm,83b32f27fc6c34b0b411f47be31ab4ae07eafed4,1,Auto merge of #91766 - scottmcm:more-array-raw-eq r=yaahc Allow `memcmp` for more array comparisons This way comparing `[NonZeroU8; 8]` is just as fast as comparing `[u8; 8]`.,THUMBS_UP,2021-12-11T10:11:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91766,MERGED,2021-12-11T01:32:10Z,2021-12-14T11:30:26Z,Allow `memcmp` for more array comparisons,scottmcm,83b32f27fc6c34b0b411f47be31ab4ae07eafed4,1,Auto merge of #91766 - scottmcm:more-array-raw-eq r=yaahc Allow `memcmp` for more array comparisons This way comparing `[NonZeroU8; 8]` is just as fast as comparing `[u8; 8]`.,THUMBS_UP,2021-12-12T13:29:42Z,Nessex,NA https://github.com/rust-lang/rust/pull/91797,MERGED,2021-12-11T16:11:44Z,2021-12-12T03:50:21Z,Fix zero-sized reference to deallocated memory,the8472,9aade508d57d2e18bc1789fc02d5e7fc8dab2cf3,1,Rollup merge of #91797 - the8472:fix-invalid-deref r=Mark-Simulacrum Fix zero-sized reference to deallocated memory fixes #91772 r? `@camelid`,HEART,2021-12-11T23:51:14Z,RalfJung,NA https://github.com/rust-lang/rust/pull/91818,MERGED,2021-12-12T01:59:58Z,2021-12-18T10:20:28Z,Show the unused type for `unused_results` lint,camelid,24b75e711338c2e0f14ed738cf3768105000c988,3,Rollup merge of #91818 - camelid:unused-result-type r=jackh726 Show the unused type for `unused_results` lint I think it's helpful to know what type was unused when looking at these warnings. The type will likely determine whether the result *should* be used or whether it should just be ignored. Including the type also matches the behavior of the `must_use` lint: unused `SomeType` that must be used.,THUMBS_UP,2021-12-12T10:03:12Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/91838,MERGED,2021-12-12T20:58:52Z,2021-12-17T22:12:37Z,Do array-slice equality via array equality rather than always via slices,scottmcm,7abab1efb21617ba6845fa86328dffa16cfcf1dc,3,"Auto merge of #91838 - scottmcm:array-slice-eq-via-arrays-not-slices r=dtolnay Do array-slice equality via array equality rather than always via slices ~~Draft because it needs a rebase after #91766 eventually gets through bors.~~ This enables the optimizations from #85828 to be used for array-to-slice comparisons too not just array-to-array. For example ```rust pub fn demo(x: &[u8] y: [u8; 4]) -> bool { *x == y } ``` Currently writes the array to stack for no reason: ```nasm sub rsp 4 mov dword ptr [rsp] edx cmp rsi 4 jne .LBB0_1 mov eax dword ptr [rdi] cmp eax dword ptr [rsp] sete al add rsp 4 ret .LBB0_1: xor eax eax add rsp 4 ret ``` Whereas with the change in this PR it just compares it directly: ```nasm cmp rsi 4 jne .LBB1_1 cmp dword ptr [rdi] edx sete al ret .LBB1_1: xor eax eax ret ```",THUMBS_UP,2021-12-12T21:08:40Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/91838,MERGED,2021-12-12T20:58:52Z,2021-12-17T22:12:37Z,Do array-slice equality via array equality rather than always via slices,scottmcm,7abab1efb21617ba6845fa86328dffa16cfcf1dc,3,"Auto merge of #91838 - scottmcm:array-slice-eq-via-arrays-not-slices r=dtolnay Do array-slice equality via array equality rather than always via slices ~~Draft because it needs a rebase after #91766 eventually gets through bors.~~ This enables the optimizations from #85828 to be used for array-to-slice comparisons too not just array-to-array. For example ```rust pub fn demo(x: &[u8] y: [u8; 4]) -> bool { *x == y } ``` Currently writes the array to stack for no reason: ```nasm sub rsp 4 mov dword ptr [rsp] edx cmp rsi 4 jne .LBB0_1 mov eax dword ptr [rdi] cmp eax dword ptr [rsp] sete al add rsp 4 ret .LBB0_1: xor eax eax add rsp 4 ret ``` Whereas with the change in this PR it just compares it directly: ```nasm cmp rsi 4 jne .LBB1_1 cmp dword ptr [rdi] edx sete al ret .LBB1_1: xor eax eax ret ```",THUMBS_UP,2021-12-13T05:34:08Z,panaman67,NA https://github.com/rust-lang/rust/pull/91838,MERGED,2021-12-12T20:58:52Z,2021-12-17T22:12:37Z,Do array-slice equality via array equality rather than always via slices,scottmcm,7abab1efb21617ba6845fa86328dffa16cfcf1dc,3,"Auto merge of #91838 - scottmcm:array-slice-eq-via-arrays-not-slices r=dtolnay Do array-slice equality via array equality rather than always via slices ~~Draft because it needs a rebase after #91766 eventually gets through bors.~~ This enables the optimizations from #85828 to be used for array-to-slice comparisons too not just array-to-array. For example ```rust pub fn demo(x: &[u8] y: [u8; 4]) -> bool { *x == y } ``` Currently writes the array to stack for no reason: ```nasm sub rsp 4 mov dword ptr [rsp] edx cmp rsi 4 jne .LBB0_1 mov eax dword ptr [rdi] cmp eax dword ptr [rsp] sete al add rsp 4 ret .LBB0_1: xor eax eax add rsp 4 ret ``` Whereas with the change in this PR it just compares it directly: ```nasm cmp rsi 4 jne .LBB1_1 cmp dword ptr [rdi] edx sete al ret .LBB1_1: xor eax eax ret ```",THUMBS_UP,2021-12-13T08:26:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91847,MERGED,2021-12-13T03:38:48Z,2021-12-13T23:21:47Z,Fix FIXME for `generic_arg_infer` in `create_substs_for_ast_path`,BoxyUwU,f8de2f56e8628ec830d2bfd77a30f681f27bb46a,4,Rollup merge of #91847 - BoxyUwU:generic_arg_infer_fixme r=lcnr Fix FIXME for `generic_arg_infer` in `create_substs_for_ast_path` Fixes a FIXME does some general refactoring of this fn and also fixes a bug where we would use a const params defaults instead of an inference var ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=19456f65ea5dc3fcaa9b696f842ab380)) (lot of stuff in one PR but it was all so close together...) r? `@lcnr` Fixes #91614,ROCKET,2021-12-13T05:51:13Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/91847,MERGED,2021-12-13T03:38:48Z,2021-12-13T23:21:47Z,Fix FIXME for `generic_arg_infer` in `create_substs_for_ast_path`,BoxyUwU,f8de2f56e8628ec830d2bfd77a30f681f27bb46a,4,Rollup merge of #91847 - BoxyUwU:generic_arg_infer_fixme r=lcnr Fix FIXME for `generic_arg_infer` in `create_substs_for_ast_path` Fixes a FIXME does some general refactoring of this fn and also fixes a bug where we would use a const params defaults instead of an inference var ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=19456f65ea5dc3fcaa9b696f842ab380)) (lot of stuff in one PR but it was all so close together...) r? `@lcnr` Fixes #91614,HOORAY,2021-12-13T05:51:19Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/91849,MERGED,2021-12-13T04:33:01Z,2021-12-13T23:21:47Z,GATs outlives lint: Try to prove bounds,jackh726,84878336b05f1dcdff6f2a55b6b66d5fa6f2e82e,7,Rollup merge of #91849 - jackh726:gats-outlives-lint-part2 r=nikomatsakis GATs outlives lint: Try to prove bounds Fixes #91036 Fixes #90888 Fixes #91348 (better error + documentation to be added to linked issue) Instead of checking for bounds directly try to prove them in the associated type environment. Also add a bit of extra information to the error including a link to the relevant discussion issue (#87479). That should be edited to include a brief summary of the current state of the outlives lint including a brief background. It also might or might not be worth it to bump this to a full error code at some point. r? ``@nikomatsakis``,HOORAY,2021-12-13T14:57:13Z,vorot93,artem@vorotnikov.me https://github.com/rust-lang/rust/pull/91861,MERGED,2021-12-13T13:28:38Z,2022-01-27T01:53:35Z,Replace iterator-based construction of collections by `Into`,juniorbassani,1dd0ac1f6a6a769b228825d627e499786fa506d9,3,Rollup merge of #91861 - juniorbassani:use-from-array-in-collections-examples r=yaahc Replace iterator-based construction of collections by `Into` Just a few quality of life improvements in the doc examples. I also removed some `Vec`s in favor of arrays.,THUMBS_UP,2021-12-13T16:51:23Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/91866,OPEN,2021-12-13T17:35:57Z,NA,Enforce that UNTRACKED options are not accessed by queries,pierwill,NA,NA,NA,EYES,2021-12-14T02:37:51Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/91866,OPEN,2021-12-13T17:35:57Z,NA,Enforce that UNTRACKED options are not accessed by queries,pierwill,NA,NA,NA,EYES,2021-12-14T14:49:54Z,mati865,NA https://github.com/rust-lang/rust/pull/91873,MERGED,2021-12-13T20:59:10Z,2022-04-05T04:39:34Z,Mention implementers of unsatisfied trait,estebank,a5c81695a95e2a1a8e2ea4310bf670a9c1734387,136,Rollup merge of #91873 - estebank:mention-impls-for-unsatisfied-trait r=davidtwco Mention implementers of unsatisfied trait When encountering an unsatisfied trait bound if there are no other suggestions mention all the types that *do* implement that trait: ``` error[E0277]: the trait bound `f32: Foo` is not satisfied --> $DIR/impl_wf.rs:22:6 | LL | impl Baz for f32 { } | ^^^^^^^^ the trait `Foo` is not implemented for `f32` | = help: the trait `Foo` is implemented for `i32` note: required by a bound in `Baz` --> $DIR/impl_wf.rs:18:31 | LL | trait Baz where U: Foo { } | ^^^ required by this bound in `Baz` ``` ``` error[E0277]: the trait bound `u32: Foo` is not satisfied --> $DIR/associated-types-path-2.rs:29:5 | LL | f1(2u32 4u32); | ^^ the trait `Foo` is not implemented for `u32` | = help: the trait `Foo` is implemented for `i32` note: required by a bound in `f1` --> $DIR/associated-types-path-2.rs:13:14 | LL | pub fn f1(a: T x: T::A) {} | ^^^ required by this bound in `f1` ``` Suggest dereferencing in more cases. Fix #87437 fix #90970.,HOORAY,2022-03-26T22:58:57Z,edmorley,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-14T11:25:23Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-14T21:07:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-15T04:52:10Z,louy2,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-15T17:11:25Z,bluss,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-23T07:17:24Z,tronta,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-23T13:47:42Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-23T18:48:51Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2021-12-25T15:07:36Z,TieWay59,NA https://github.com/rust-lang/rust/pull/91881,MERGED,2021-12-13T23:35:51Z,2021-12-15T06:33:54Z,Stabilize `iter::zip`,Patrick-Poitras,4e7497bda0ff9e9b803f49d7dbffb870cefb1843,29,Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip r=scottmcm Stabilize `iter::zip` Hello all! As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised I hereby submit this stabilization PR on the issue. As the pull request that introduced the feature (#82917) states the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement it has been integrated into the codebase without any trouble and has been used in many places across the rust compiler and standard library since March without any issues. For more details I would refer to `@cuviper's` original PR or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).,THUMBS_UP,2022-01-04T22:55:17Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/91886,MERGED,2021-12-14T03:27:34Z,2021-12-15T12:41:46Z,core: minor `Option` doc correction,euclio,e6c495dd5996c1c16f67869bf62fa68a210768be,1,Rollup merge of #91886 - euclio:option-doc r=dtolnay core: minor `Option` doc correction,THUMBS_UP,2021-12-14T04:07:26Z,fmease,NA https://github.com/rust-lang/rust/pull/91892,MERGED,2021-12-14T04:38:35Z,2021-12-14T14:42:28Z,Fix HashStable implementation on InferTy,compiler-errors,d0e6bb707663d03e6cbbe3e0c5168327b138a405,2,Rollup merge of #91892 - compiler-errors:fix-inferty-hashtable r=dtolnay Fix HashStable implementation on InferTy HashStable impl forgot to hash the discriminant. Fixes #91807,ROCKET,2021-12-14T04:49:08Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/91892,MERGED,2021-12-14T04:38:35Z,2021-12-14T14:42:28Z,Fix HashStable implementation on InferTy,compiler-errors,d0e6bb707663d03e6cbbe3e0c5168327b138a405,2,Rollup merge of #91892 - compiler-errors:fix-inferty-hashtable r=dtolnay Fix HashStable implementation on InferTy HashStable impl forgot to hash the discriminant. Fixes #91807,EYES,2021-12-19T19:43:05Z,nagisa,github@kazlauskas.me https://github.com/rust-lang/rust/pull/91898,MERGED,2021-12-14T05:23:51Z,2021-12-15T16:18:33Z,Make `TyS::is_suggestable` check for non-suggestable types structually,compiler-errors,b507174e82bf6d54e235c4fe71e8fe216f80ce9f,30,Rollup merge of #91898 - compiler-errors:dont_suggest_closure_return_type r=lcnr Make `TyS::is_suggestable` check for non-suggestable types structually Not sure if I went overboard checking substs in dyn types etc. Let me know if I should simplify this function. Fixes #91832,HEART,2021-12-14T11:57:21Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/91906,MERGED,2021-12-14T12:48:57Z,2021-12-15T12:41:46Z,Removed `in_band_lifetimes` from `library\proc_macro`,anuvratsingh,6c6cfa87c08a7bfb6b27bb01b9337aa3178716a5,4,Rollup merge of #91906 - anuvratsingh:remove_in_band_lifetimes_library_proc_macro r=petrochenkov Removed `in_band_lifetimes` from `library\proc_macro` Issue [#91867](https://github.com/rust-lang/rust/issues/91867) This is my first try I followed the instructions given. Fixed all the errors that were thrown while compiling. Compiled with stage 0 1 and 2 all of them compiled successfully.,HEART,2021-12-15T01:54:53Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-05T09:13:22Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-13T19:24:02Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-13T20:08:59Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-13T20:09:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-13T21:59:25Z,estebank,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-13T22:10:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-14T14:15:55Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-15T00:21:46Z,tux3,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-15T00:21:47Z,tux3,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-15T18:43:39Z,belkadan,jrose@belkadan.com https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-15T20:52:19Z,calebsander,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,HOORAY,2022-01-16T16:36:54Z,adamreichold,NA https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-17T14:32:19Z,adsick,adsick@protonmail.com https://github.com/rust-lang/rust/pull/91907,MERGED,2021-12-14T13:48:35Z,2022-01-05T02:32:37Z,Allow `_` as the length of array types and repeat expressions,lcnr,ac7a8677155b911c27ee28f2f0d1a359686fa774,28,Rollup merge of #91907 - lcnr:const-arg-infer r=BoxyUwU Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`,THUMBS_UP,2022-01-24T21:35:28Z,BlueGhostAlt,NA https://github.com/rust-lang/rust/pull/91919,MERGED,2021-12-14T16:15:51Z,2022-01-08T21:41:47Z,Don't perform any new queries while reading a query result on disk,Aaron1011,a7e2e33960e95d2eb1a2a2aeec169dba5f73de05,2,Auto merge of #91919 - Aaron1011:query-recursive-read r=michaelwoerister Don't perform any new queries while reading a query result on disk In addition to being very confusing this can cause us to add dep node edges between two queries that would not otherwise have an edge. We now panic if any new dep node edges are created during the deserialization of a query result. This requires serializing the full `AdtDef` to disk instead of just serializing the `DefId` and invoking the `adt_def` query during deserialization. I'll probably split this up into several smaller PRs for perf runs.,HEART,2021-12-22T14:59:11Z,pierwill,NA https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,HEART,2021-12-15T23:23:23Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,THUMBS_UP,2021-12-23T12:59:32Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,THUMBS_UP,2021-12-23T13:42:33Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,HEART,2021-12-23T13:42:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,HEART,2021-12-24T09:11:05Z,Lonami,totufals@hotmail.com https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,THUMBS_UP,2021-12-25T22:48:17Z,calebsander,NA https://github.com/rust-lang/rust/pull/91947,MERGED,2021-12-15T01:03:11Z,2021-12-17T02:03:12Z,Add `io::Error::other`,ibraheemdev,b742594f4a5cb73b2b69047625c8b92642c38c24,1,Rollup merge of #91947 - ibraheemdev:io-error-other r=joshtriplett Add `io::Error::other` This PR adds a small utility constructor `io::Error::other` a shorthand for `io::Error::new(io::ErrorKind::Other err)` something I find myself writing often. For some concrete stats a quick search on [grep.app](https://grep.app) shows that more than half of the uses of `io::Error::new` use `ErrorKind::Other`: ``` Error::new\((?:std::)?(?:io::)?ErrorKind:: => 3 898 results Error::new\((?:std::)?(?:io::)?ErrorKind::Other => 2 186 results ```,THUMBS_UP,2022-05-26T21:03:46Z,chloekek,NA https://github.com/rust-lang/rust/pull/91951,MERGED,2021-12-15T02:34:32Z,2021-12-16T14:30:40Z,update stdarch,SparrowLii,435837e9bb4cd4b23fadcc22d925a36f344994a5,1,Rollup merge of #91951 - SparrowLii:master r=Amanieu update stdarch 2 commits in d219ad63c5075098fc224a57deb4852b9734327d..0716b22e902207efabe46879cbf28d0189ab7924 2021-12-9 23:50:37 +0000 to 2021-12-14 16:17:57 +0100 * Fix a bunch of typos ([Fix a bunch of typos stdarch#1267](https://github.com/rust-lang/stdarch/pull/1267)) * Stabilize armv8 neon instruction set on aarch64 ([Stabilize armv8 neon instruction set on aarch64 stdarch#1266](https://github.com/rust-lang/stdarch/pull/1266)) The update stabilizes armv8 neon instructions on aarch64. #90972,EYES,2021-12-15T06:18:55Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/91956,MERGED,2021-12-15T05:45:56Z,2021-12-19T03:33:19Z,fix(rustc_lint): better detect when parens are necessary,notriddle,48915315d2306bbec25c449771fae0ea0538678c,4,Rollup merge of #91956 - notriddle:notriddle/unused-parens-range r=nagisa fix(rustc_lint): better detect when parens are necessary Fixes #90807,HEART,2021-12-19T13:49:54Z,narpfel,NA https://github.com/rust-lang/rust/pull/91965,MERGED,2021-12-15T12:02:52Z,2022-01-22T02:54:34Z,Add more granular `--exclude` in `x.py`,pietroalbini,fc694064e8f2d9553738d4243c13c676327e9779,5,Rollup merge of #91965 - ferrocene:pa-more-granular-exclude r=Mark-Simulacrum Add more granular `--exclude` in `x.py` x.py has support for excluding some steps from the current invocation but unfortunately that's not granular enough: some steps have the same name in different modules and that prevents excluding only *some* of them. As a practical example let's say you need to run everything in `./x.py test` except for the standard library tests as those tests require IPv6 and need to be executed on a separate machine. Before this commit if you were to just run this: ./x.py test --exclude library/std ...the invocation would eventually fail as that would not only exclude running the tests for the standard library (`library/std` in the `test` module) it would also exclude generating its documentation (`library/std` in the `doc` module) breaking linkchecker. This commit adds support to the `--exclude` flag for prefixing paths with the name of the module their step is defined in allowing the user to choose which module to exclude from: ./x.py test --exclude test::library/std This maintains backward compatibility with existing invocations while allowing more ganular exclusion. Examples of the behavior: | `--exclude` | Docs | Tests | | ------------------- | ------- | ------- | | `library/std` | Skipped | Skipped | | `doc::library/std` | Skipped | Run | | `test::library/std` | Run | Skipped | Note that this PR only changes the `--exclude` flag and not in other `x.py` arguments or flags yet. In the implementation I tried to limit the impact this would have with rustbuild as a whole as much as possible. The module name is extracted from the step by parsing the result of `std::any::type_name()`: unfortunately that output can change at any point in time but IMO it's better than having to annotate all the existing and future `Step` implementations with the module name. I added a test to ensure the parsing works as expected so hopefully if anyone makes changes to the output of `std::any::type_name()` they'll also notice they have to update rustbuild. r? `@Mark-Simulacrum`,EYES,2021-12-16T11:12:47Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/91984,MERGED,2021-12-16T00:51:30Z,2021-12-19T15:44:30Z,Remove `in_band_lifetimes` from `rustc_middle`,Aaron1011,4d5ffc487084446261e7d49a7425fc5ff305c857,42,Rollup merge of #91984 - Aaron1011:rustc-middle-lifetime r=oli-obk Remove `in_band_lifetimes` from `rustc_middle` See #91867 This was mostly straightforward. In several places I take advantage of the fact that lifetimes are non-hygenic: a macro declares the 'tcx' lifetime which is then used in types passed in as macro arguments.,HEART,2021-12-16T09:16:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/91986,MERGED,2021-12-16T02:09:22Z,2021-12-16T14:30:40Z,Bump compiler-builtins to 0.1.66,ayrtonm,7391962e31b712d2fb15f5424309b58b8181798d,2,Rollup merge of #91986 - ayrtonm:bump-builtins r=Amanieu Bump compiler-builtins to 0.1.66 Adds intrinsics for truncdfsf2 and truncdfsf2vsp on ARM. r? `@Amanieu`,THUMBS_UP,2021-12-16T04:50:39Z,sajattack,NA https://github.com/rust-lang/rust/pull/91993,MERGED,2021-12-16T05:08:02Z,2022-03-08T12:45:18Z,Tweak output for non-exhaustive `match` expression,estebank,e3ea69f0ce8f833858340d2735b6f763a6ee76bf,69,"Rollup merge of #91993 - estebank:match-span-suggestion r=oli-obk Tweak output for non-exhaustive `match` expression * Provide structured suggestion when missing `match` arms * Move pointing at the missing variants *after* the main error ",HEART,2021-12-22T01:18:30Z,camelid,NA https://github.com/rust-lang/rust/pull/91993,MERGED,2021-12-16T05:08:02Z,2022-03-08T12:45:18Z,Tweak output for non-exhaustive `match` expression,estebank,e3ea69f0ce8f833858340d2735b6f763a6ee76bf,69,"Rollup merge of #91993 - estebank:match-span-suggestion r=oli-obk Tweak output for non-exhaustive `match` expression * Provide structured suggestion when missing `match` arms * Move pointing at the missing variants *after* the main error ",HOORAY,2021-12-22T01:18:48Z,camelid,NA https://github.com/rust-lang/rust/pull/91993,MERGED,2021-12-16T05:08:02Z,2022-03-08T12:45:18Z,Tweak output for non-exhaustive `match` expression,estebank,e3ea69f0ce8f833858340d2735b6f763a6ee76bf,69,"Rollup merge of #91993 - estebank:match-span-suggestion r=oli-obk Tweak output for non-exhaustive `match` expression * Provide structured suggestion when missing `match` arms * Move pointing at the missing variants *after* the main error ",HEART,2022-03-09T02:01:14Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/91998,CLOSED,2021-12-16T10:38:04Z,2022-06-23T06:51:16Z,Specialize len in ExactSizeIterator implementations,ssomers,NA,NA,NA,HEART,2021-12-26T09:18:42Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-01-24T14:16:59Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,HEART,2022-01-24T14:17:05Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,HEART,2022-01-25T21:18:27Z,lqd,NA https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-01-25T21:32:50Z,lqd,NA https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-01-27T05:17:19Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,HEART,2022-01-31T17:22:05Z,mati865,NA https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-02-04T19:07:58Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-02-10T11:16:15Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-02-10T20:41:45Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,HEART,2022-02-10T20:41:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,THUMBS_UP,2022-02-11T12:46:32Z,pro465,NA https://github.com/rust-lang/rust/pull/92007,MERGED,2021-12-16T21:21:10Z,2022-02-08T02:43:54Z,Lazy type-alias-impl-trait,oli-obk,e7cc3bddbe0d0e374d05e7003e662bba1742dbae,359,Auto merge of #92007 - oli-obk:lazy_tait2 r=nikomatsakis Lazy type-alias-impl-trait Previously opaque types were processed by 1. replacing all mentions of them with inference variables 2. memorizing these inference variables in a side-table 3. at the end of typeck resolve the inference variables in the side table and use the resolved type as the hidden type of the opaque type This worked okayish for `impl Trait` in return position but required lots of roundabout type inference hacks and processing. This PR instead stops this process of replacing opaque types with inference variables and just keeps the opaque types around. Whenever an opaque type `O` is compared with another type `T` we make the comparison succeed and record `T` as the hidden type. If `O` is compared to `U` while there is a recorded hidden type for it we grab the recorded type (`T`) and compare that against `U`. This makes implementing * https://github.com/rust-lang/rfcs/pull/2515 much simpler (previous attempts on the inference based scheme were very prone to ICEs and general misbehaviour that was not explainable except by random implementation defined oddities). r? `@nikomatsakis` fixes #93411 fixes #88236,HEART,2022-02-11T12:46:35Z,pro465,NA https://github.com/rust-lang/rust/pull/92020,MERGED,2021-12-17T03:18:02Z,2021-12-19T03:33:19Z,Remove P: Unpin bound on impl Stream for Pin,Folyd,e22aae009f0526414de83933caa33ca8a1847045,1,Rollup merge of #92020 - Folyd:stream-unpin r=m-ou-se Remove P: Unpin bound on impl Stream for Pin Similar to https://github.com/rust-lang/rust/pull/81363.,HEART,2021-12-20T19:04:12Z,estebank,NA https://github.com/rust-lang/rust/pull/92028,MERGED,2021-12-17T07:49:13Z,2021-12-19T15:44:30Z,Sync portable-simd to fix libcore build for AVX-512 enabled targets,petrochenkov,a2db9004cb3404aba0ef7f6816ad99925bfe45b8,4,Rollup merge of #92028 - petrochenkov:psimd r=Mark-Simulacrum Sync portable-simd to fix libcore build for AVX-512 enabled targets Fixes https://github.com/rust-lang/rust/pull/91484#issuecomment-989933534 cc ``@workingjubilee``,THUMBS_UP,2021-12-17T08:24:58Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/92029,MERGED,2021-12-17T10:41:59Z,2021-12-19T20:23:56Z,Explicitly set no ELF flags for .rustc section,nikic,9415c67ae55d6da8640303776e96b68b79c3a0d0,1,Rollup merge of #92029 - nikic:section-flags-fix r=davidtwco Explicitly set no ELF flags for .rustc section For a data section the object crate will set the SHF_ALLOC by default which is exactly what we don't want. Explicitly set sh_flags to zero to avoid this. I checked with `objdump -h` that this produces the right flags for ELF. Fixes #92013.,HEART,2021-12-20T18:09:06Z,tmandry,NA https://github.com/rust-lang/rust/pull/92042,MERGED,2021-12-17T15:59:09Z,2021-12-19T15:44:30Z,Enable `#[thread_local]` for all windows-msvc targets,ChrisDenton,4dbe966fdd9822ff643a04b30b66f295f3f38fe2,21,Rollup merge of #92042 - ChrisDenton:msvc-static-tls r=nagisa Enable `#[thread_local]` for all windows-msvc targets As it stands `#[thread_local]` is enabled haphazardly for msvc. It seems all 64-bit targets have it enabled but not 32-bit targets unless they're also UWP targets (perhaps because UWP was added more recently?). So this PR simply enables it for 32-bit targets as well. I can't think of a reason not to and I've confirmed by running tests locally which pass. See also #91659,THUMBS_UP,2022-01-31T16:16:28Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/92043,OPEN,2021-12-17T16:47:03Z,NA,Implement namespacing for doc comments IDs,GuillaumeGomez,NA,NA,NA,HEART,2022-01-20T12:44:57Z,jplatte,NA https://github.com/rust-lang/rust/pull/92044,OPEN,2021-12-17T17:46:36Z,NA,Discard region-related bounds from `ParamEnv` when predicate is global,Aaron1011,NA,NA,NA,HEART,2021-12-20T16:35:16Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/92044,OPEN,2021-12-17T17:46:36Z,NA,Discard region-related bounds from `ParamEnv` when predicate is global,Aaron1011,NA,NA,NA,HEART,2021-12-20T16:48:46Z,carols10cents,NA https://github.com/rust-lang/rust/pull/92044,OPEN,2021-12-17T17:46:36Z,NA,Discard region-related bounds from `ParamEnv` when predicate is global,Aaron1011,NA,NA,NA,HEART,2021-12-27T15:24:36Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/92044,OPEN,2021-12-17T17:46:36Z,NA,Discard region-related bounds from `ParamEnv` when predicate is global,Aaron1011,NA,NA,NA,HEART,2021-12-28T07:27:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92047,MERGED,2021-12-17T19:06:42Z,2021-12-18T21:17:04Z,Set `RUST_BACKTRACE=0` when running location-detail tests,Aaron1011,fd259040d9990ca695c2f3a65a81ac4d15c25436,7,Rollup merge of #92047 - Aaron1011:location-detail-backtrace r=Mark-Simulacrum Set `RUST_BACKTRACE=0` when running location-detail tests This ensures that the output does not depend on environment variables set in the shell.,HOORAY,2021-12-18T01:24:09Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/92047,MERGED,2021-12-17T19:06:42Z,2021-12-18T21:17:04Z,Set `RUST_BACKTRACE=0` when running location-detail tests,Aaron1011,fd259040d9990ca695c2f3a65a81ac4d15c25436,7,Rollup merge of #92047 - Aaron1011:location-detail-backtrace r=Mark-Simulacrum Set `RUST_BACKTRACE=0` when running location-detail tests This ensures that the output does not depend on environment variables set in the shell.,HOORAY,2021-12-18T10:32:43Z,cjgillot,NA https://github.com/rust-lang/rust/pull/92048,OPEN,2021-12-17T20:03:55Z,NA,Add midpoint function for all integers and floating numbers,Urgau,NA,NA,NA,THUMBS_UP,2021-12-17T20:46:22Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92048,OPEN,2021-12-17T20:03:55Z,NA,Add midpoint function for all integers and floating numbers,Urgau,NA,NA,NA,THUMBS_UP,2022-01-02T17:54:05Z,xfix,github@borowski.pw https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2021-12-17T23:23:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HOORAY,2021-12-17T23:31:36Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2021-12-18T00:58:26Z,camelid,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2021-12-23T05:29:20Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2021-12-27T21:45:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HOORAY,2021-12-27T21:45:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2022-01-31T00:08:13Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HOORAY,2022-01-31T00:08:14Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HEART,2022-05-28T20:05:02Z,mati865,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HOORAY,2022-06-07T11:43:50Z,Virgiel,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,THUMBS_UP,2022-06-07T11:43:50Z,Virgiel,NA https://github.com/rust-lang/rust/pull/92051,OPEN,2021-12-17T23:04:16Z,NA,rustc_mir_transform: Add a local value numbering pass off by default.,pcwalton,NA,NA,NA,HEART,2022-06-07T11:43:51Z,Virgiel,NA https://github.com/rust-lang/rust/pull/92070,MERGED,2021-12-18T14:46:50Z,2022-01-11T17:31:11Z,Replace usages of vec![].into_iter with [].into_iter,rukai,2e2c86eba21a08cf505cd67073736d03ff3887ad,36,Auto merge of #92070 - rukai:replace_vec_into_iter_with_array_into_iter r=Mark-Simulacrum Replace usages of vec![].into_iter with [].into_iter `[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same) So we should change all the implementation documentation and tests to use it. I skipped: * `src/tools` - Those are copied in from upstream * `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it. * any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter` * any case where it looked like we were intentionally using `vec![].into_iter` to test it.,THUMBS_UP,2021-12-18T16:47:53Z,r00ster91,NA https://github.com/rust-lang/rust/pull/92070,MERGED,2021-12-18T14:46:50Z,2022-01-11T17:31:11Z,Replace usages of vec![].into_iter with [].into_iter,rukai,2e2c86eba21a08cf505cd67073736d03ff3887ad,36,Auto merge of #92070 - rukai:replace_vec_into_iter_with_array_into_iter r=Mark-Simulacrum Replace usages of vec![].into_iter with [].into_iter `[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same) So we should change all the implementation documentation and tests to use it. I skipped: * `src/tools` - Those are copied in from upstream * `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it. * any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter` * any case where it looked like we were intentionally using `vec![].into_iter` to test it.,THUMBS_UP,2022-01-09T02:40:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92070,MERGED,2021-12-18T14:46:50Z,2022-01-11T17:31:11Z,Replace usages of vec![].into_iter with [].into_iter,rukai,2e2c86eba21a08cf505cd67073736d03ff3887ad,36,Auto merge of #92070 - rukai:replace_vec_into_iter_with_array_into_iter r=Mark-Simulacrum Replace usages of vec![].into_iter with [].into_iter `[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same) So we should change all the implementation documentation and tests to use it. I skipped: * `src/tools` - Those are copied in from upstream * `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it. * any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter` * any case where it looked like we were intentionally using `vec![].into_iter` to test it.,THUMBS_UP,2022-01-11T17:48:46Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92070,MERGED,2021-12-18T14:46:50Z,2022-01-11T17:31:11Z,Replace usages of vec![].into_iter with [].into_iter,rukai,2e2c86eba21a08cf505cd67073736d03ff3887ad,36,Auto merge of #92070 - rukai:replace_vec_into_iter_with_array_into_iter r=Mark-Simulacrum Replace usages of vec![].into_iter with [].into_iter `[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same) So we should change all the implementation documentation and tests to use it. I skipped: * `src/tools` - Those are copied in from upstream * `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it. * any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter` * any case where it looked like we were intentionally using `vec![].into_iter` to test it.,THUMBS_UP,2022-01-19T12:06:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92076,MERGED,2021-12-18T16:26:51Z,2021-12-28T20:08:14Z,Ignore other `PredicateKind`s in rustdoc auto trait finder,Aaron1011,bec499e08d91a61942e01ac2a747c285e48da2fd,1,Rollup merge of #92076 - Aaron1011:rustdoc-auto-trait-ignore r=cjgillot Ignore other `PredicateKind`s in rustdoc auto trait finder Fixes #92073 There's not really anything we can do with them and they're causing ICEs. I'm not using a wildcard match as we should check that any new `PredicateKind`s are handled properly by rustdoc.,HOORAY,2021-12-18T18:26:55Z,AlexTMjugador,NA https://github.com/rust-lang/rust/pull/92082,MERGED,2021-12-18T17:39:56Z,2021-12-19T03:33:19Z,rustdoc: Write doc-comments directly instead of using FromIterator,jyn514,d486e68ab29a8c5ba2e776a0ff74a760fd3edf19,2,Rollup merge of #92082 - jyn514:remove-from-iterator r=jyn514 rustdoc: Write doc-comments directly instead of using FromIterator The FromIterator impl made the code much harder to understand. The types don't make sense until you realize there's a custom FromIterator impl. This is the first commit from https://github.com/rust-lang/rust/pull/91305; since ``@camelid`` wrote it originally I don't feel bad unilaterally approving it. r? ``@ghost`` ``@bors`` r+ Note that this will conflict with https://github.com/rust-lang/rust/pull/92078.,THUMBS_UP,2021-12-18T20:57:32Z,camelid,NA https://github.com/rust-lang/rust/pull/92123,MERGED,2021-12-20T12:50:50Z,2022-03-05T19:53:48Z,Implement RFC 3184 - thread local cell methods,m-ou-se,ab2bd41ce0da79f82e7bfd281bb746a6eee21346,7,Auto merge of #92123 - m-ou-se:thread-local-cell-methods r=joshtriplett Implement RFC 3184 - thread local cell methods This implements [RFC 3184](https://github.com/rust-lang/rfcs/pull/3184) with `@danielhenrymantilla's` [suggestion](https://github.com/rust-lang/rfcs/pull/3184#issuecomment-965773616) for the `with_` method names. Tracking issue: https://github.com/rust-lang/rust/issues/92122,HOORAY,2021-12-20T13:51:13Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/92123,MERGED,2021-12-20T12:50:50Z,2022-03-05T19:53:48Z,Implement RFC 3184 - thread local cell methods,m-ou-se,ab2bd41ce0da79f82e7bfd281bb746a6eee21346,7,Auto merge of #92123 - m-ou-se:thread-local-cell-methods r=joshtriplett Implement RFC 3184 - thread local cell methods This implements [RFC 3184](https://github.com/rust-lang/rfcs/pull/3184) with `@danielhenrymantilla's` [suggestion](https://github.com/rust-lang/rfcs/pull/3184#issuecomment-965773616) for the `with_` method names. Tracking issue: https://github.com/rust-lang/rust/issues/92122,HOORAY,2022-03-10T13:06:42Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/92123,MERGED,2021-12-20T12:50:50Z,2022-03-05T19:53:48Z,Implement RFC 3184 - thread local cell methods,m-ou-se,ab2bd41ce0da79f82e7bfd281bb746a6eee21346,7,Auto merge of #92123 - m-ou-se:thread-local-cell-methods r=joshtriplett Implement RFC 3184 - thread local cell methods This implements [RFC 3184](https://github.com/rust-lang/rfcs/pull/3184) with `@danielhenrymantilla's` [suggestion](https://github.com/rust-lang/rfcs/pull/3184#issuecomment-965773616) for the `with_` method names. Tracking issue: https://github.com/rust-lang/rust/issues/92122,HOORAY,2022-03-11T11:58:03Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/92131,MERGED,2021-12-20T18:05:33Z,2021-12-21T12:01:14Z,Sync rustc_codegen_cranelift,bjorn3,ee45a532f30dc8d6f373b952f09a265d979a2083,36,Rollup merge of #92131 - bjorn3:sync_cg_clif-2021-12-20 r=bjorn3 Sync rustc_codegen_cranelift The main highlight this sync is improved support for inline assembly. Thanks `@nbdd0121!` Inline assembly is still disabled by default for builds in the main rust repo though. Cranelift will now also be built from the crates.io releases rather than the git repo. Git repos are incompatible with vendoring. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler,HEART,2021-12-20T18:40:01Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/92134,MERGED,2021-12-20T19:28:29Z,2022-01-27T01:53:36Z,Add x86_64-pc-windows-msvc linker-plugin-lto instructions,nico-abram,e249812597cb1a57ff704e340a62fbe2d22c7565,1,Rollup merge of #92134 - nico-abram:patch-1 r=michaelwoerister Add x86_64-pc-windows-msvc linker-plugin-lto instructions I had some trouble getting cross language LTO working for this target in part because the very few links of documentation I could find were linux-centric and because of a few very specific errors I ran into. I'm not sure if this is the correct place to document this but this is one of the first links I found when looking for documentation so it might be the best place for it.,HOORAY,2021-12-21T11:00:55Z,AngelicosPhosphoros,NA https://github.com/rust-lang/rust/pull/92138,MERGED,2021-12-20T21:03:18Z,2022-01-20T10:05:41Z,Improve capacity estimation in Vec::from_iter,AngelicosPhosphoros,74fbbefea8d13683cca5eee62e4740706cb3144a,2,Auto merge of #92138 - AngelicosPhosphoros:try_smarter_vec_from_iter_48994_2 r=Mark-Simulacrum Improve capacity estimation in Vec::from_iter Iterates on the attempt made in #53086. Closes #48994,HEART,2022-01-19T16:06:00Z,camsteffen,NA https://github.com/rust-lang/rust/pull/92138,MERGED,2021-12-20T21:03:18Z,2022-01-20T10:05:41Z,Improve capacity estimation in Vec::from_iter,AngelicosPhosphoros,74fbbefea8d13683cca5eee62e4740706cb3144a,2,Auto merge of #92138 - AngelicosPhosphoros:try_smarter_vec_from_iter_48994_2 r=Mark-Simulacrum Improve capacity estimation in Vec::from_iter Iterates on the attempt made in #53086. Closes #48994,HEART,2022-01-26T05:09:22Z,nnethercote,NA https://github.com/rust-lang/rust/pull/92142,MERGED,2021-12-20T22:09:12Z,2022-01-14T06:29:28Z,[code coverage] Fix missing dead code in modules that are never called,wesleywiser,5e04f513cdb173ed808b4c770d146dd9927df3a0,9,Rollup merge of #92142 - wesleywiser:fix_codecoverage_partitioning r=tmandry [code coverage] Fix missing dead code in modules that are never called The issue here is that the logic used to determine which CGU to put the dead function stubs in doesn't handle cases where a module is never assigned to a CGU (which is what happens when all of the code in the module is dead). The partitioning logic also caused issues in #85461 where inline functions were duplicated into multiple CGUs resulting in duplicate symbols. This commit fixes the issue by removing the complex logic used to assign dead code stubs to CGUs and replaces it with a much simpler model: we pick one CGU to hold all the dead code stubs. We pick a CGU which has exported items which increases the likelihood the linker won't throw away our dead functions and we pick the smallest to minimize the impact on compilation times for crates with very large CGUs. Fixes #91661 Fixes #86177 Fixes #85718 Fixes #79622 r? ```@tmandry``` cc ```@richkadel``` This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁,HEART,2021-12-31T07:22:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/92149,MERGED,2021-12-21T05:27:09Z,2021-12-21T16:04:59Z,Fix bad caching of `~const Drop` bounds,fee1-dead,8ad3c1dd1d47f9ce7dfdf4a14c70c67e1790b0f5,3,Auto merge of #92149 - fee1-dead:cache-fix r=oli-obk Fix bad caching of `~const Drop` bounds Fixes #92111.,THUMBS_UP,2021-12-21T13:05:26Z,Poopooracoocoo,NA https://github.com/rust-lang/rust/pull/92149,MERGED,2021-12-21T05:27:09Z,2021-12-21T16:04:59Z,Fix bad caching of `~const Drop` bounds,fee1-dead,8ad3c1dd1d47f9ce7dfdf4a14c70c67e1790b0f5,3,Auto merge of #92149 - fee1-dead:cache-fix r=oli-obk Fix bad caching of `~const Drop` bounds Fixes #92111.,THUMBS_UP,2021-12-29T20:06:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/92150,MERGED,2021-12-21T05:51:56Z,2022-03-10T14:58:50Z,Improve suggestion when casting usize to (possibly) wide pointer,compiler-errors,7473750b13c2000a1ce04d851906030527d6278a,5,Rollup merge of #92150 - compiler-errors:better_usize_to_wide_ptr_cast r=petrochenkov Improve suggestion when casting usize to (possibly) wide pointer I thought #92125 was a wonderful idea so I went ahead and took a stab at it. Not sure if my approach is the best going forward but I'm happy with the improvement in the error message. Iwill definitely address any changes if people are more opinionated with the wordings or want more features. Also do I need to add a new error code? (Fixes #92125),HEART,2021-12-21T10:18:00Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/92150,MERGED,2021-12-21T05:51:56Z,2022-03-10T14:58:50Z,Improve suggestion when casting usize to (possibly) wide pointer,compiler-errors,7473750b13c2000a1ce04d851906030527d6278a,5,Rollup merge of #92150 - compiler-errors:better_usize_to_wide_ptr_cast r=petrochenkov Improve suggestion when casting usize to (possibly) wide pointer I thought #92125 was a wonderful idea so I went ahead and took a stab at it. Not sure if my approach is the best going forward but I'm happy with the improvement in the error message. Iwill definitely address any changes if people are more opinionated with the wordings or want more features. Also do I need to add a new error code? (Fixes #92125),HEART,2021-12-22T15:02:15Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/92150,MERGED,2021-12-21T05:51:56Z,2022-03-10T14:58:50Z,Improve suggestion when casting usize to (possibly) wide pointer,compiler-errors,7473750b13c2000a1ce04d851906030527d6278a,5,Rollup merge of #92150 - compiler-errors:better_usize_to_wide_ptr_cast r=petrochenkov Improve suggestion when casting usize to (possibly) wide pointer I thought #92125 was a wonderful idea so I went ahead and took a stab at it. Not sure if my approach is the best going forward but I'm happy with the improvement in the error message. Iwill definitely address any changes if people are more opinionated with the wordings or want more features. Also do I need to add a new error code? (Fixes #92125),HEART,2022-03-20T18:56:50Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/92155,MERGED,2021-12-21T09:42:04Z,2021-12-23T08:13:16Z,Use panic() instead of panic!() in some places in core.,m-ou-se,390bb3406d6c15894139830f6a30e16a1e92053f,8,Auto merge of #92155 - m-ou-se:panic-fn r=eddyb Use panic() instead of panic!() in some places in core. See https://github.com/rust-lang/rust/pull/92068 and https://github.com/rust-lang/rust/pull/92140. This avoids the `panic!()` macro in a few potentially hot paths. This becomes more relevant when switching `core` to Rust 2021 as it'll avoid format_args!() and save some compilation time. (It doesn't make a huge difference but still.) (Also the errors in const panic become slightly nicer.),HEART,2021-12-26T01:22:32Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",ROCKET,2022-01-03T22:24:54Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",ROCKET,2022-01-05T13:10:54Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",ROCKET,2022-01-13T07:15:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",HEART,2022-01-20T08:36:43Z,iago-lito,NA https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",THUMBS_UP,2022-01-27T11:33:51Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",HEART,2022-01-27T14:28:18Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",THUMBS_UP,2022-01-27T14:28:21Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",THUMBS_UP,2022-01-27T19:19:39Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",THUMBS_UP,2022-01-30T21:13:02Z,bb010g,NA https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",ROCKET,2022-01-30T21:13:03Z,bb010g,NA https://github.com/rust-lang/rust/pull/92164,MERGED,2021-12-21T15:42:32Z,2022-01-18T02:32:41Z,Implement `#[rustc_must_implement_one_of]` attribute,WaffleLapkin,32d85c0b5ab357a3f7cdba4fb43b8cc678e44c30,17,"Rollup merge of #92164 - WaffleLapkin:rustc_must_implement_one_of_attr r=Aaron1011 Implement `#[rustc_must_implement_one_of]` attribute This PR adds a new attribute — `#[rustc_must_implement_one_of]` that allows changing the ""minimal complete definition"" of a trait. It's similar to GHC's minimal `{-# MINIMAL #-}` pragma though `#[rustc_must_implement_one_of]` is weaker atm. Such attribute was long wanted. It can be for example used in `Read` trait to make transitions to recently added `read_buf` easier: ```rust #[rustc_must_implement_one_of(read read_buf)] pub trait Read { fn read(&mut self buf: &mut [u8]) -> Result { let mut buf = ReadBuf::new(buf); self.read_buf(&mut buf)?; Ok(buf.filled_len()) } fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { default_read_buf(|b| self.read(b) buf) } } impl Read for Ty0 {} //^ This will fail to compile even though all `Read` methods have default implementations // Both of these will compile just fine impl Read for Ty1 { fn read(&mut self buf: &mut [u8]) -> Result { /* ... */ } } impl Read for Ty2 { fn read_buf(&mut self buf: &mut ReadBuf<'_>) -> Result<()> { /* ... */ } } ``` For now this is implemented as an internal attribute to start experimenting on the design of this feature. In the future we may want to extend it: - Allow arbitrary requirements like `a | (b & c)` - Allow multiple requirements like - ```rust #[rustc_must_implement_one_of(a b)] #[rustc_must_implement_one_of(c d)] ``` - Make it appear in rustdoc documentation - Change the syntax? - Etc Eventually we should make an RFC and make this (or rather similar) attribute public. --- I'm fairly new to compiler development and not at all sure if the implementation makes sense but at least it passes tests :)",THUMBS_UP,2022-03-22T09:30:46Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,EYES,2021-12-22T23:36:39Z,ehuss,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,EYES,2021-12-23T03:50:11Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2021-12-26T08:54:42Z,Matthias-Fauconneau,matthias.fauconneau@gmail.com https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2021-12-27T07:48:59Z,js2xxx,development2014@outlook.com https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2021-12-28T20:30:45Z,evanrichter,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,EYES,2021-12-28T20:30:46Z,evanrichter,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,THUMBS_UP,2022-01-01T02:00:14Z,zzlk,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2022-01-01T06:17:13Z,95th,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2022-01-02T04:33:58Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,THUMBS_UP,2022-01-02T04:33:59Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,THUMBS_UP,2022-01-03T13:41:25Z,msrd0,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2022-01-03T13:41:26Z,msrd0,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,EYES,2022-01-03T13:41:27Z,msrd0,NA https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,THUMBS_UP,2022-01-21T03:00:36Z,andrewgazelka,andrew.gazelka@gmail.com https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2022-01-21T03:00:37Z,andrewgazelka,andrew.gazelka@gmail.com https://github.com/rust-lang/rust/pull/92175,MERGED,2021-12-21T20:43:37Z,2021-12-31T19:54:12Z,Import `SourceFile`s from crate before decoding foreign `Span`,Aaron1011,984a6bf9c11b7356f696c685a145d7136fff051c,6,Auto merge of #92175 - Aaron1011:fix-missing-source-file r=cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache we encode all `Span`s we encounter regardless of whether or not their `SourceFile` comes from the local crate or from a foreign crate. When we decode a `Span` we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion when we try to resolve definitions from other crates. In certain cases however we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding we call `imported_source_files()` when we encounter a foreign `CrateNum` which ensure that all `SourceFile`s from that crate are imported into the current session.,HEART,2022-02-15T12:00:36Z,LesnyRumcajs,NA https://github.com/rust-lang/rust/pull/92183,MERGED,2021-12-22T00:43:57Z,2022-01-20T23:48:12Z,Point at correct argument when async fn output type lifetime disagrees with signature,tmandry,413f490677d7d58e6d3a14c9fc5d9be11e5d668d,17,"Rollup merge of #92183 - tmandry:issue-74256 r=estebank Point at correct argument when async fn output type lifetime disagrees with signature Fixes most of #74256. ## Problems fixed This PR fixes a couple of related problems in the error reporting code. ### Highlighting the wrong argument First the error reporting code was looking at the desugared return type of an `async fn` to decide which parameter to highlight. For example a function like ```rust async fn async_fn(self: &Struct f: &u32) -> &u32 { f } ``` desugars to ```rust async fn async_fn<'a 'b>(self: &'a Struct f: &'b u32) -> impl Future + 'a + 'b { f } ``` Since `f: &'b u32` is returned but the output type is `&'a u32` the error would occur when checking that `'a: 'b`. The reporting code would look to see if the ""offending"" lifetime `'b` was included in the return type and because the code was looking at the desugared future type it was included. So it defaulted to reporting that the source of the other lifetime `'a` (the `self` type) was the problem when it was really the type of `f`. (Note that if it had chosen instead to look at `'a` first it too would have been included in the output type and it would have arbitrarily reported the error (correctly this time) on the type of `f`.) Looking at the actual future type isn't useful for this reason; it captures all input lifetimes. Using the written return type for `async fn` solves this problem and results in less confusing error messages for the user. This isn't a perfect fix unfortunately; writing the ""manually desugared"" form of the above function still results in the wrong parameter being highlighted. Looking at the output type of every `impl Future` return type doesn't feel like a very principled approach though it might work. The problem would remain for function signatures that look like the desugared one above but use different traits. There may be deeper changes required to pinpoint which part of each type is conflicting. ### Lying about await point capture causing lifetime conflicts The second issue fixed by this PR is the unnecessary complexity in `try_report_anon_anon_conflict`. It turns out that the root cause I suggested in https://github.com/rust-lang/rust/issues/76547#issuecomment-692863608 wasn't really the root cause. Adding special handling to report that a variable was captured over an await point only made the error messages less correct and pointed to a problem other than the one that actually occurred. Given the above discussion it's easy to see why: `async fn`s capture all input lifetimes in their return type so holding an argument across an await point should never cause a lifetime conflict! Removing the special handling simplified the code and improved the error messages (though they still aren't very good!) ## Future work * Fix error reporting on the ""desugared"" form of this code * Get the `suggest_adding_lifetime_params` suggestion firing on these examples * cc #42703 I think r? `@estebank`",THUMBS_UP,2022-01-10T17:17:09Z,Agrailag,NA https://github.com/rust-lang/rust/pull/92222,MERGED,2021-12-23T06:25:46Z,2021-12-24T01:55:01Z,Remove useless `#[global_allocator]` from rustc and rustdoc.,nnethercote,d6d12b6a5d2c2906ef4e85ce1d50a8684cf43626,2,Auto merge of #92222 - nnethercote:rm-global_allocator-rustc-rustdoc r=alexcrichton Remove useless `#[global_allocator]` from rustc and rustdoc. This was added in #83152 which has several errors in its comments. This commit also fix up the comments which are quite wrong and misleading. r? `@alexcrichton`,EYES,2021-12-23T10:48:47Z,mati865,NA https://github.com/rust-lang/rust/pull/92226,MERGED,2021-12-23T11:08:53Z,2021-12-24T13:15:24Z,Constify `core::intrinsics::black_box` and `core::hint::black_box`.,woppopo,fca4b155a7eec79714a24c262e81edc633263cc9,5,Auto merge of #92226 - woppopo:const_black_box r=joshtriplett Constify `core::intrinsics::black_box` and `core::hint::black_box`. `core::intrinsics::black_box` is already constified but it wasn't marked as const (see: https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/intrinsics.rs#L471). Tracking issue: None,THUMBS_UP,2022-01-31T16:21:16Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/92227,MERGED,2021-12-23T11:09:45Z,2021-12-25T18:00:07Z,Rustdoc: use `is_doc_hidden` method on more places,Kobzol,c096176fb411c90a8b0226901c11e7edd131192f,3,Auto merge of #92227 - Kobzol:rustdoc-doc-hidden r=jyn514 Rustdoc: use `is_doc_hidden` method on more places While profiling `rustdoc` I noticed that finding out if some item is marked with `#[doc(hidden)]` is relatively hot so I tried to optimize it. I noticed that there is already a method called `is_doc_hidden` on `TyCtxt` but it wasn't used much so I replaced the manual calls to `attrs(...).has_word(...)` with this method. Just by doing that perf. was improved locally although I'm not sure if the semantics of the previous calls and this method are the same? As another step I tried to querify `is_doc_hidden` but I didn't include that here until we see the perf. results from the first commit and until I find whether this change is OK at all :) Can I ask for a perf. run? Thanks. r? `@jyn514`,EYES,2021-12-23T15:40:51Z,pierwill,NA https://github.com/rust-lang/rust/pull/92243,CLOSED,2021-12-24T04:02:37Z,2022-01-19T19:54:35Z,Give types to some bool function arguments in pretty printer,dtolnay,NA,NA,NA,HEART,2022-01-10T18:38:06Z,camelid,NA https://github.com/rust-lang/rust/pull/92244,MERGED,2021-12-24T05:17:35Z,2021-12-29T22:34:49Z,rustc_metadata: Encode list of all crate's traits into metadata,petrochenkov,78fd0f633faaa5b6dd254fc1456735f63a1b1238,12,Auto merge of #92244 - petrochenkov:alltraits r=cjgillot rustc_metadata: Encode list of all crate's traits into metadata While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree. This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors which execute the `all_traits` query for better diagnostics).,HEART,2021-12-24T18:34:53Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/92244,MERGED,2021-12-24T05:17:35Z,2021-12-29T22:34:49Z,rustc_metadata: Encode list of all crate's traits into metadata,petrochenkov,78fd0f633faaa5b6dd254fc1456735f63a1b1238,12,Auto merge of #92244 - petrochenkov:alltraits r=cjgillot rustc_metadata: Encode list of all crate's traits into metadata While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree. This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors which execute the `all_traits` query for better diagnostics).,HEART,2021-12-25T03:06:40Z,camelid,NA https://github.com/rust-lang/rust/pull/92244,MERGED,2021-12-24T05:17:35Z,2021-12-29T22:34:49Z,rustc_metadata: Encode list of all crate's traits into metadata,petrochenkov,78fd0f633faaa5b6dd254fc1456735f63a1b1238,12,Auto merge of #92244 - petrochenkov:alltraits r=cjgillot rustc_metadata: Encode list of all crate's traits into metadata While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree. This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors which execute the `all_traits` query for better diagnostics).,HEART,2021-12-25T10:59:07Z,mati865,NA https://github.com/rust-lang/rust/pull/92244,MERGED,2021-12-24T05:17:35Z,2021-12-29T22:34:49Z,rustc_metadata: Encode list of all crate's traits into metadata,petrochenkov,78fd0f633faaa5b6dd254fc1456735f63a1b1238,12,Auto merge of #92244 - petrochenkov:alltraits r=cjgillot rustc_metadata: Encode list of all crate's traits into metadata While working on https://github.com/rust-lang/rust/pull/88679 I noticed that rustdoc is casually doing something quite expensive something that is used only for error reporting in rustc - collecting all traits from all crates in the dependency tree. This PR trades some minor extra time spent by metadata encoder in rustc for major gains for rustdoc (and for rustc runs with errors which execute the `all_traits` query for better diagnostics).,HEART,2021-12-27T21:49:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92256,MERGED,2021-12-24T14:58:15Z,2022-01-27T01:53:35Z,Improve selection errors for `~const` trait bounds,fee1-dead,e2b2bfe10ce5d36e9568173cb6cb9c7456b03a61,27,Rollup merge of #92256 - fee1-dead:improve-selection-err r=oli-obk Improve selection errors for `~const` trait bounds,ROCKET,2022-01-14T17:52:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92259,MERGED,2021-12-24T17:46:24Z,2022-01-04T03:26:13Z,Remove special-cased stable hashing for HIR module,Aaron1011,2b681ac06b1a6b7ea39525e59363ffee0d1a68e5,4,Auto merge of #92259 - Aaron1011:normal-mod-hashing r=michaelwoerister Remove special-cased stable hashing for HIR module All other 'containers' (e.g. `impl` blocks) hashed their contents in the normal order-dependent way. However `Mod` was hashing its contents in a (sort-of) order-independent way. However the exact order is exposed to consumers through `Mod.item_ids` and through query results like `hir_module_items`. Therefore stable hashing needs to take the order of items into account to avoid fingerprint ICEs. Unforuntately I was unable to directly build a reproducer for the ICE due to the behavior of `Fingerprint::combine_commutative`. This operation swaps the upper and lower `u64` when constructing the result which makes the function non-associative. Since we start the hashing of module items by combining `Fingerprint::ZERO` with the first item it's difficult to actually build an example where changing the order of module items leaves the final hash unchanged. However this appears to have been hit in practice in #92218 While we're not able to reproduce it the fact that proc-macros are involved (which can give an entire module the same span preventing any span-related invalidations) makes me confident that the root cause of that issue is our method of hashing module items. This PR removes all of the special handling for `Mod` instead deriving a `HashStable` implementation. This makes `Mod` consistent with other 'contains' like `Impl` which hash their contents through the typical derive of `HashStable`.,LAUGH,2021-12-24T18:57:10Z,Alfriadox,alfriadox@gmail.com https://github.com/rust-lang/rust/pull/92259,MERGED,2021-12-24T17:46:24Z,2022-01-04T03:26:13Z,Remove special-cased stable hashing for HIR module,Aaron1011,2b681ac06b1a6b7ea39525e59363ffee0d1a68e5,4,Auto merge of #92259 - Aaron1011:normal-mod-hashing r=michaelwoerister Remove special-cased stable hashing for HIR module All other 'containers' (e.g. `impl` blocks) hashed their contents in the normal order-dependent way. However `Mod` was hashing its contents in a (sort-of) order-independent way. However the exact order is exposed to consumers through `Mod.item_ids` and through query results like `hir_module_items`. Therefore stable hashing needs to take the order of items into account to avoid fingerprint ICEs. Unforuntately I was unable to directly build a reproducer for the ICE due to the behavior of `Fingerprint::combine_commutative`. This operation swaps the upper and lower `u64` when constructing the result which makes the function non-associative. Since we start the hashing of module items by combining `Fingerprint::ZERO` with the first item it's difficult to actually build an example where changing the order of module items leaves the final hash unchanged. However this appears to have been hit in practice in #92218 While we're not able to reproduce it the fact that proc-macros are involved (which can give an entire module the same span preventing any span-related invalidations) makes me confident that the root cause of that issue is our method of hashing module items. This PR removes all of the special handling for `Mod` instead deriving a `HashStable` implementation. This makes `Mod` consistent with other 'contains' like `Impl` which hash their contents through the typical derive of `HashStable`.,HOORAY,2021-12-24T18:57:13Z,Alfriadox,alfriadox@gmail.com https://github.com/rust-lang/rust/pull/92260,MERGED,2021-12-24T19:10:30Z,2022-03-08T19:25:26Z,Move some more bootstrap logic from python to rust,jyn514,64187b837486be90b897c7014572aa3537dc9b27,10,Auto merge of #92260 - jyn514:less-python-logic r=Mark-Simulacrum Move some more bootstrap logic from python to rust Same rationale as https://github.com/rust-lang/rust/pull/76544; it would be nice to make python entirely optional at some point. This also removes $ROOT as an option for the build directory; I haven't been using it and like Alex said in https://github.com/rust-lang/rust/pull/76544#discussion_r488248930 it seems like a misfeature. This allows running `cargo run` from src/bootstrap although that still gives lots of compile errors if you don't use the beta toolchain. It's not exactly the same as using `x.py` since it won't have `BOOTSTRAP_DOWNLOAD_RUSTC` set but it's pretty close. Doing this from the top-level directory requires https://github.com/rust-lang/cargo/issues/7290 to be fixed or using `cargo run -p bootstrap`. The next steps for making python optional are to move download-ci-llvm and download-rustc support into rustbuild likely be shelling out as the python scripts do today. It would also be nice (although not required) to move submodule support there but that would require taking bootstrap out of the workspace to avoid errors from crates that haven't been cloned yet. r? `@Mark-Simulacrum`,HEART,2021-12-28T14:48:04Z,mati865,NA https://github.com/rust-lang/rust/pull/92260,MERGED,2021-12-24T19:10:30Z,2022-03-08T19:25:26Z,Move some more bootstrap logic from python to rust,jyn514,64187b837486be90b897c7014572aa3537dc9b27,10,Auto merge of #92260 - jyn514:less-python-logic r=Mark-Simulacrum Move some more bootstrap logic from python to rust Same rationale as https://github.com/rust-lang/rust/pull/76544; it would be nice to make python entirely optional at some point. This also removes $ROOT as an option for the build directory; I haven't been using it and like Alex said in https://github.com/rust-lang/rust/pull/76544#discussion_r488248930 it seems like a misfeature. This allows running `cargo run` from src/bootstrap although that still gives lots of compile errors if you don't use the beta toolchain. It's not exactly the same as using `x.py` since it won't have `BOOTSTRAP_DOWNLOAD_RUSTC` set but it's pretty close. Doing this from the top-level directory requires https://github.com/rust-lang/cargo/issues/7290 to be fixed or using `cargo run -p bootstrap`. The next steps for making python optional are to move download-ci-llvm and download-rustc support into rustbuild likely be shelling out as the python scripts do today. It would also be nice (although not required) to move submodule support there but that would require taking bootstrap out of the workspace to avoid errors from crates that haven't been cloned yet. r? `@Mark-Simulacrum`,HEART,2022-01-02T13:28:31Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/92261,CLOSED,2021-12-24T19:19:05Z,2022-02-11T03:39:13Z,Avoid accidentally enabling unstable features in compilers,jyn514,NA,NA,NA,THUMBS_UP,2021-12-26T23:26:28Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T01:48:46Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T01:49:29Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T03:02:10Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T03:02:15Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T03:02:18Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T03:02:21Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T03:02:23Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-25T03:02:26Z,Lokathor,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T03:45:06Z,jackh726,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T03:45:06Z,jackh726,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T03:45:06Z,jackh726,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T03:45:07Z,jackh726,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T03:45:07Z,jackh726,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T05:05:28Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-25T05:05:29Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T05:05:29Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T05:05:30Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T05:05:30Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T05:05:31Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T07:01:51Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T08:41:59Z,slightlyoutofphase,slightlyoutofphase@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-25T08:47:46Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T08:47:47Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T08:47:47Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T08:47:47Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T08:47:48Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T08:47:48Z,darksv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T08:51:42Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T08:51:43Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T08:51:45Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T08:53:55Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T08:53:55Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T09:02:04Z,macpp,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T09:25:58Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T10:54:19Z,oli-obk,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T10:54:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T11:30:18Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T11:30:18Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T11:30:20Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T11:30:20Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T11:30:21Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-25T11:30:21Z,fmease,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T12:05:02Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T12:05:03Z,DevinR528,devin.ragotzy@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-25T13:06:55Z,RalfJung,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T13:37:05Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T18:54:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T18:54:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-25T21:56:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-25T21:56:58Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-25T21:56:59Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-25T21:57:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-25T22:56:28Z,the8472,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-26T11:22:46Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-26T11:22:49Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-26T12:24:15Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-26T12:24:16Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2021-12-26T12:24:17Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-26T13:19:10Z,y21,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2021-12-26T13:19:12Z,y21,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2021-12-26T15:07:16Z,y21,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2021-12-27T06:18:48Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2021-12-27T06:42:13Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2021-12-27T08:50:03Z,pitdicker,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2022-01-01T06:30:31Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2022-01-01T15:21:41Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2022-01-01T15:21:45Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2022-01-03T10:59:16Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2022-01-03T10:59:18Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-01-03T10:59:21Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-01-05T01:17:32Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2022-01-05T01:17:34Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2022-01-05T01:17:35Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2022-01-05T01:17:36Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-01-16T20:36:42Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2022-01-16T20:36:43Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2022-01-16T20:36:44Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2022-01-16T20:36:49Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-01-30T22:12:35Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-02-22T19:40:30Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2022-02-22T19:40:31Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2022-02-22T19:40:51Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,ROCKET,2022-02-22T19:40:53Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2022-02-22T19:40:53Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,EYES,2022-02-22T19:40:54Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-02-23T11:01:13Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,THUMBS_UP,2022-05-06T14:59:34Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,LAUGH,2022-05-19T08:15:28Z,gimbles,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HEART,2022-06-16T18:08:56Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/92268,OPEN,2021-12-25T01:01:06Z,NA,Initial implementation of transmutability trait.,jswrenn,NA,NA,NA,HOORAY,2022-07-03T12:14:20Z,Jesse-Bakker,NA https://github.com/rust-lang/rust/pull/92274,MERGED,2021-12-25T12:14:22Z,2022-01-29T19:11:48Z,Add `intrinsics::const_deallocate`,woppopo,9e86a434a770b453ded7dabd3203efc9c61eb2e5,18,Rollup merge of #92274 - woppopo:const_deallocate r=oli-obk Add `intrinsics::const_deallocate` Tracking issue: #79597 Related: #91884 This allows deallocation of a memory allocated by `intrinsics::const_allocate`. At the moment this can be only used to reduce memory usage but in the future this may be useful to detect memory leaks (If an allocated memory remains after evaluation raise an error...?).,THUMBS_UP,2022-01-28T15:05:27Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/92274,MERGED,2021-12-25T12:14:22Z,2022-01-29T19:11:48Z,Add `intrinsics::const_deallocate`,woppopo,9e86a434a770b453ded7dabd3203efc9c61eb2e5,18,Rollup merge of #92274 - woppopo:const_deallocate r=oli-obk Add `intrinsics::const_deallocate` Tracking issue: #79597 Related: #91884 This allows deallocation of a memory allocated by `intrinsics::const_allocate`. At the moment this can be only used to reduce memory usage but in the future this may be useful to detect memory leaks (If an allocated memory remains after evaluation raise an error...?).,THUMBS_UP,2022-02-03T12:44:36Z,GrayJack,NA https://github.com/rust-lang/rust/pull/92274,MERGED,2021-12-25T12:14:22Z,2022-01-29T19:11:48Z,Add `intrinsics::const_deallocate`,woppopo,9e86a434a770b453ded7dabd3203efc9c61eb2e5,18,Rollup merge of #92274 - woppopo:const_deallocate r=oli-obk Add `intrinsics::const_deallocate` Tracking issue: #79597 Related: #91884 This allows deallocation of a memory allocated by `intrinsics::const_allocate`. At the moment this can be only used to reduce memory usage but in the future this may be useful to detect memory leaks (If an allocated memory remains after evaluation raise an error...?).,THUMBS_UP,2022-02-03T14:57:41Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/92274,MERGED,2021-12-25T12:14:22Z,2022-01-29T19:11:48Z,Add `intrinsics::const_deallocate`,woppopo,9e86a434a770b453ded7dabd3203efc9c61eb2e5,18,Rollup merge of #92274 - woppopo:const_deallocate r=oli-obk Add `intrinsics::const_deallocate` Tracking issue: #79597 Related: #91884 This allows deallocation of a memory allocated by `intrinsics::const_allocate`. At the moment this can be only used to reduce memory usage but in the future this may be useful to detect memory leaks (If an allocated memory remains after evaluation raise an error...?).,THUMBS_UP,2022-02-04T10:02:53Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/92285,MERGED,2021-12-26T06:50:27Z,2022-03-15T03:56:44Z,check ~Projection~ all supertrait bounds when confirming dyn candidate,compiler-errors,984204814e00f60c5e1ec99e2e184f326782a586,6,Auto merge of #92285 - compiler-errors:dyn-proj-bounds r=nikomatsakis check ~Projection~ all supertrait bounds when confirming dyn candidate I'm pretty sure Projection is the only other PredicateKind that we care about enforcing here. Fixes #80800,HEART,2022-01-14T02:43:42Z,estebank,NA https://github.com/rust-lang/rust/pull/92285,MERGED,2021-12-26T06:50:27Z,2022-03-15T03:56:44Z,check ~Projection~ all supertrait bounds when confirming dyn candidate,compiler-errors,984204814e00f60c5e1ec99e2e184f326782a586,6,Auto merge of #92285 - compiler-errors:dyn-proj-bounds r=nikomatsakis check ~Projection~ all supertrait bounds when confirming dyn candidate I'm pretty sure Projection is the only other PredicateKind that we care about enforcing here. Fixes #80800,HEART,2022-02-01T21:02:44Z,scalexm,alexandre@scalexm.fr https://github.com/rust-lang/rust/pull/92285,MERGED,2021-12-26T06:50:27Z,2022-03-15T03:56:44Z,check ~Projection~ all supertrait bounds when confirming dyn candidate,compiler-errors,984204814e00f60c5e1ec99e2e184f326782a586,6,Auto merge of #92285 - compiler-errors:dyn-proj-bounds r=nikomatsakis check ~Projection~ all supertrait bounds when confirming dyn candidate I'm pretty sure Projection is the only other PredicateKind that we care about enforcing here. Fixes #80800,HEART,2022-05-19T23:56:30Z,zohnannor,NA https://github.com/rust-lang/rust/pull/92287,MERGED,2021-12-26T08:48:51Z,2022-04-19T01:59:42Z,Add slice::remainder,JulianKnodt,d5ae66c12c6bdf1a5739ae1fce8057fd76ba0f47,3,Auto merge of #92287 - JulianKnodt:slice_remainder r=yaahc Add slice::remainder This adds a remainder function to the Slice iterator so that a caller can access unused elements if iteration stops. Addresses #91733,THUMBS_UP,2021-12-26T23:18:21Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",EYES,2021-12-27T07:05:30Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",HOORAY,2021-12-27T09:24:19Z,marmeladema,NA https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",THUMBS_UP,2021-12-27T19:46:46Z,lqd,NA https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",HOORAY,2021-12-29T23:33:19Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",HOORAY,2021-12-29T23:34:43Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",HOORAY,2021-12-30T00:33:11Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92306,MERGED,2021-12-27T00:56:03Z,2022-02-09T12:51:58Z,Improve opaque type higher-ranked region error message under NLL,Aaron1011,1f0a96862ac9d4c6ca3e4bb500c8b9eac4d83049,14,"Auto merge of #92306 - Aaron1011:opaque-type-op r=oli-obk Improve opaque type higher-ranked region error message under NLL Currently any higher-ranked region errors involving opaque types fall back to a generic ""higher-ranked subtype error"" message when run under NLL. This PR adds better error message handling for this case giving us the same kinds of error messages that we currently get without NLL: ``` error: implementation of `MyTrait` is not general enough --> $DIR/opaque-hrtb.rs:12:13 | LL | fn foo() -> impl for<'a> MyTrait<&'a str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough | = note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>` for any lifetime `'1`... = note: ...but it actually implements `MyTrait<&'2 str>` for some specific lifetime `'2` error: aborting due to previous error ``` To accomplish this several different refactoring needed to be made: * We now have a dedicated `InstantiateOpaqueType` struct which implements `TypeOp`. This is used to invoke `instantiate_opaque_types` during MIR type checking. * `TypeOp` is refactored to pass around a `MirBorrowckCtxt` which is needed to report opaque type region errors. * We no longer assume that all `TypeOp`s correspond to canonicalized queries. This allows us to properly handle opaque type instantiation (which does not occur in a query) as a `TypeOp`. A new `ErrorInfo` associated type is used to determine what additional information is used during higher-ranked region error handling. * The body of `try_extract_error_from_fulfill_cx` has been moved out to a new function `try_extract_error_from_region_constraints`. This allows us to re-use the same error reporting code between canonicalized queries (which can extract region constraints directly from a fresh `InferCtxt`) and opaque type handling (which needs to take region constraints from the pre-existing `InferCtxt` that we use throughout MIR borrow checking).",HOORAY,2022-04-26T14:01:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92310,MERGED,2021-12-27T04:51:23Z,2022-02-03T18:38:28Z,rustdoc: Fix ICE report,ehuss,9298bd8197ebffac1d310ff90f5845a30a512a23,1,Rollup merge of #92310 - ehuss:rustdoc-ice r=estebank rustdoc: Fix ICE report The ICE report in rustdoc was confusing because it was returning an argument parse error: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic error: Unrecognized option: 'crate-version' ``` This is because the ICE reporter was trying to parse the arguments as rustc not rustdoc. Since an argument error is a fatal error it was early-exiting with the argument error due to unwinding. This changes it to be a more primitive scan of the arguments. The arguments being checked are pretty simple and only have a small handful of forms that are easy to check for. It now looks like this: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.59.0-dev running on x86_64-apple-darwin note: compiler flags: --crate-type lib -Z treat-err-as-bug note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack ``` It still says `rustc` but I can live with that.,HEART,2021-12-27T19:16:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/92310,MERGED,2021-12-27T04:51:23Z,2022-02-03T18:38:28Z,rustdoc: Fix ICE report,ehuss,9298bd8197ebffac1d310ff90f5845a30a512a23,1,Rollup merge of #92310 - ehuss:rustdoc-ice r=estebank rustdoc: Fix ICE report The ICE report in rustdoc was confusing because it was returning an argument parse error: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic error: Unrecognized option: 'crate-version' ``` This is because the ICE reporter was trying to parse the arguments as rustc not rustdoc. Since an argument error is a fatal error it was early-exiting with the argument error due to unwinding. This changes it to be a more primitive scan of the arguments. The arguments being checked are pretty simple and only have a small handful of forms that are easy to check for. It now looks like this: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.59.0-dev running on x86_64-apple-darwin note: compiler flags: --crate-type lib -Z treat-err-as-bug note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack ``` It still says `rustc` but I can live with that.,HEART,2021-12-27T19:43:07Z,camelid,NA https://github.com/rust-lang/rust/pull/92310,MERGED,2021-12-27T04:51:23Z,2022-02-03T18:38:28Z,rustdoc: Fix ICE report,ehuss,9298bd8197ebffac1d310ff90f5845a30a512a23,1,Rollup merge of #92310 - ehuss:rustdoc-ice r=estebank rustdoc: Fix ICE report The ICE report in rustdoc was confusing because it was returning an argument parse error: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic error: Unrecognized option: 'crate-version' ``` This is because the ICE reporter was trying to parse the arguments as rustc not rustdoc. Since an argument error is a fatal error it was early-exiting with the argument error due to unwinding. This changes it to be a more primitive scan of the arguments. The arguments being checked are pretty simple and only have a small handful of forms that are easy to check for. It now looks like this: ``` thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`' compiler/rustc_errors/src/lib.rs:1212:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.59.0-dev running on x86_64-apple-darwin note: compiler flags: --crate-type lib -Z treat-err-as-bug note: some of the compiler flags provided by cargo are hidden query stack during panic: end of query stack ``` It still says `rustc` but I can live with that.,HEART,2022-01-28T14:21:00Z,michidk,michael@lohr.dev https://github.com/rust-lang/rust/pull/92323,OPEN,2021-12-27T17:05:30Z,NA,Sort MonoItems by span instead of DefIndex.,cjgillot,NA,NA,NA,THUMBS_UP,2022-01-12T18:26:09Z,pierwill,NA https://github.com/rust-lang/rust/pull/92334,MERGED,2021-12-27T22:24:46Z,2022-01-14T06:29:28Z,rustdoc: Preserve rendering of macro_rules matchers when possible,dtolnay,ac81a1364038e940ed079e248607ac9bfd6b372a,6,Rollup merge of #92334 - dtolnay:rustdocmatcher r=camelid GuillaumeGomez rustdoc: Preserve rendering of macro_rules matchers when possible Fixes #92331. This approach restores the behavior prior to #86282 **if** the matcher token held by the compiler **and** the matcher token found in the source code are identical TokenTrees. Thus #86208 remains fixed but without regressing formatting for the vast majority of macros which are not macro-generated.,HEART,2022-01-05T00:32:10Z,camelid,NA https://github.com/rust-lang/rust/pull/92349,MERGED,2021-12-28T10:55:12Z,2022-01-06T18:48:53Z,Fix rustdoc::private_doc_tests lint for public re-exported items,avitex,4d0b567efb3407af5bd9c7452ddec193f9792c56,4,Rollup merge of #92349 - avitex:fix-rustdoc-private-doc-tests r=GuillaumeGomez Fix rustdoc::private_doc_tests lint for public re-exported items Closes #72081 This involves changing the lint to check the access level is exported rather than public. The [exported access level](https://github.com/rust-lang/rust/blob/e91ad5fc62bdee4a29c18baa5fad2ca42fc91bf4/compiler/rustc_middle/src/middle/privacy.rs#L24) accounts for public items and items accessible to other crates with the help of `pub use` re-exports. The pattern of re-exporting public items from a private module is usage seen in a number of popular crates.,HEART,2022-01-06T19:01:00Z,sourcefrog,mbp@sourcefrog.net https://github.com/rust-lang/rust/pull/92363,MERGED,2021-12-28T18:09:09Z,2022-01-21T23:53:01Z,Override rustc version in ui and mir-opt tests to get stable hashes,the8472,17d29dcdce9b9e838635eb0adefd9b8b1588410b,37,Auto merge of #92363 - the8472:less-compiletest-normalization r=Mark-Simulacrum Override rustc version in ui and mir-opt tests to get stable hashes Building a dozen separate regexps for each test in compiletest consumes significant amounts of CPU cycles. UI test timings on my machine: OLD: 39.63s NEW: 30.27s,HEART,2022-01-15T02:48:19Z,camelid,NA https://github.com/rust-lang/rust/pull/92363,MERGED,2021-12-28T18:09:09Z,2022-01-21T23:53:01Z,Override rustc version in ui and mir-opt tests to get stable hashes,the8472,17d29dcdce9b9e838635eb0adefd9b8b1588410b,37,Auto merge of #92363 - the8472:less-compiletest-normalization r=Mark-Simulacrum Override rustc version in ui and mir-opt tests to get stable hashes Building a dozen separate regexps for each test in compiletest consumes significant amounts of CPU cycles. UI test timings on my machine: OLD: 39.63s NEW: 30.27s,HEART,2022-01-16T10:41:36Z,tmiasko,NA https://github.com/rust-lang/rust/pull/92363,MERGED,2021-12-28T18:09:09Z,2022-01-21T23:53:01Z,Override rustc version in ui and mir-opt tests to get stable hashes,the8472,17d29dcdce9b9e838635eb0adefd9b8b1588410b,37,Auto merge of #92363 - the8472:less-compiletest-normalization r=Mark-Simulacrum Override rustc version in ui and mir-opt tests to get stable hashes Building a dozen separate regexps for each test in compiletest consumes significant amounts of CPU cycles. UI test timings on my machine: OLD: 39.63s NEW: 30.27s,HEART,2022-01-21T17:46:04Z,pierwill,NA https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_DOWN,2021-12-28T18:45:56Z,Urgau,NA https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2021-12-28T19:56:02Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2021-12-29T00:34:57Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2021-12-29T02:26:29Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2021-12-30T08:38:30Z,DemiMarie,demiobenour@gmail.com https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2022-01-04T18:48:57Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/92365,OPEN,2021-12-28T18:38:59Z,NA,Future deprecation of `env::{set remove}_var`,jhpratt,NA,NA,NA,THUMBS_UP,2022-04-04T22:01:01Z,zohnannor,NA https://github.com/rust-lang/rust/pull/92367,CLOSED,2021-12-28T18:54:08Z,2021-12-28T19:10:14Z,Updated docs for rotate_[left/right],DKenefake,NA,NA,NA,THUMBS_UP,2021-12-28T18:56:13Z,gibsramen,grahman@eng.ucsd.edu https://github.com/rust-lang/rust/pull/92381,MERGED,2021-12-29T01:47:03Z,2022-01-14T20:34:26Z,Suggest `return`ing tail expressions in async functions,ThePuzzlemaker,347c744fe0e464737dbbdc44d148c84fc07568cb,3,"Rollup merge of #92381 - ThePuzzlemaker:issue-92308 r=estebank Suggest `return`ing tail expressions in async functions This PR fixes #92308. Previously the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions as the suggestion checked whether the types were equal disregarding `impl Future` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut. I'm not sure if this is the ""right"" way to do this so if there is a better way then please let me know. I amended an existing test introduced in #81769 to add a regression test for this if you think I should make a separate test I will.",HEART,2022-01-10T16:46:57Z,estebank,NA https://github.com/rust-lang/rust/pull/92381,MERGED,2021-12-29T01:47:03Z,2022-01-14T20:34:26Z,Suggest `return`ing tail expressions in async functions,ThePuzzlemaker,347c744fe0e464737dbbdc44d148c84fc07568cb,3,"Rollup merge of #92381 - ThePuzzlemaker:issue-92308 r=estebank Suggest `return`ing tail expressions in async functions This PR fixes #92308. Previously the suggestion to `return` tail expressions (introduced in #81769) did not apply to `async` functions as the suggestion checked whether the types were equal disregarding `impl Future` syntax sugar for `async` functions. This PR changes that in order to fix a potential papercut. I'm not sure if this is the ""right"" way to do this so if there is a better way then please let me know. I amended an existing test introduced in #81769 to add a regression test for this if you think I should make a separate test I will.",HEART,2022-01-14T21:31:33Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92393,CLOSED,2021-12-29T08:33:27Z,2022-04-08T00:43:50Z,Add `Iterator::array_chunks()`,rossmacarthur,NA,NA,NA,THUMBS_UP,2021-12-29T11:00:49Z,marmeladema,NA https://github.com/rust-lang/rust/pull/92393,CLOSED,2021-12-29T08:33:27Z,2022-04-08T00:43:50Z,Add `Iterator::array_chunks()`,rossmacarthur,NA,NA,NA,THUMBS_UP,2022-01-23T04:35:43Z,kangalioo,NA https://github.com/rust-lang/rust/pull/92411,CLOSED,2021-12-29T18:02:53Z,2022-02-17T20:26:03Z,Add as_slice and as_mut_slice to Option,ChaiTRex,NA,NA,NA,THUMBS_DOWN,2021-12-29T22:53:04Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/92419,MERGED,2021-12-29T20:49:56Z,2022-01-01T16:31:25Z,Mark drop calls in landing pads `cold` instead of `noinline`,erikdesjardins,4f49627c6fe2a32d1fed6310466bb0e1c535c0c0,9,"Auto merge of #92419 - erikdesjardins:coldland r=nagisa Mark drop calls in landing pads `cold` instead of `noinline` Now that deferred inlining has been disabled in LLVM (#92110) this shouldn't cause catastrophic size blowup. I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder because I forgot to make it conditional on LLVM version) r? `@nagisa` cc `@arielb1` (this effectively reverts #42771 ""mark calls in the unwind path as !noinline"") cc `@RalfJung` (fixes #46515) edit: also fixes #87055",ROCKET,2021-12-31T14:42:21Z,lqd,NA https://github.com/rust-lang/rust/pull/92423,MERGED,2021-12-30T00:12:04Z,2021-12-30T18:06:59Z,Add UI test for #92292,weirane,a23ef617b32efee0e761a1ac6f548642e4704361,1,Rollup merge of #92423 - weirane:ui-92292 r=fee1-dead Add UI test for #92292 Closes #92292,HEART,2021-12-30T00:30:06Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/92441,MERGED,2021-12-30T16:43:01Z,2022-01-15T17:51:09Z,Link impl items to corresponding trait items in late resolver.,cjgillot,ec4bcaac450279b029f3480b8b8f1b82ab36a5eb,26,Auto merge of #92441 - cjgillot:resolve-trait-impl-item r=matthewjasper Link impl items to corresponding trait items in late resolver. Hygienically linking trait impl items to declarations in the trait can be done directly by the late resolver. In fact it is already done to diagnose unknown items. This PR uses this resolution work and stores the `DefId` of the trait item in the HIR. This avoids having to do this resolution manually later. r? `@matthewjasper` Related to #90639. The added `trait_item_id` field can be moved to `ImplItemRef` to be used directly by your PR.,HOORAY,2021-12-30T16:49:05Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/92441,MERGED,2021-12-30T16:43:01Z,2022-01-15T17:51:09Z,Link impl items to corresponding trait items in late resolver.,cjgillot,ec4bcaac450279b029f3480b8b8f1b82ab36a5eb,26,Auto merge of #92441 - cjgillot:resolve-trait-impl-item r=matthewjasper Link impl items to corresponding trait items in late resolver. Hygienically linking trait impl items to declarations in the trait can be done directly by the late resolver. In fact it is already done to diagnose unknown items. This PR uses this resolution work and stores the `DefId` of the trait item in the HIR. This avoids having to do this resolution manually later. r? `@matthewjasper` Related to #90639. The added `trait_item_id` field can be moved to `ImplItemRef` to be used directly by your PR.,HOORAY,2021-12-31T09:47:52Z,Agrailag,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",LAUGH,2021-12-30T19:49:41Z,camsteffen,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",LAUGH,2021-12-31T03:51:42Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",LAUGH,2021-12-31T10:53:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",LAUGH,2022-01-01T02:09:39Z,camelid,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",HEART,2022-01-01T02:09:44Z,camelid,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",LAUGH,2022-01-02T11:54:35Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",HEART,2022-01-02T17:45:08Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/92444,MERGED,2021-12-30T19:04:15Z,2022-01-03T17:34:49Z,Consolidate Result's and Option's methods into fewer impl blocks,dtolnay,13e284033e34609f5f911d3df989eddec4af3f1b,6,"Rollup merge of #92444 - dtolnay:coremethods r=joshtriplett Consolidate Result's and Option's methods into fewer impl blocks `Result`'s and `Option`'s methods have historically been separated up into `impl` blocks based on their trait bounds with the bounds specified on type parameters of the impl block. I find this unhelpful because closely related methods like `unwrap_or` and `unwrap_or_default` end up disproportionately far apart in source code and rustdocs: 
 impl<T> Option<T> {     pub fn unwrap_or(self  default: T) -> T {         ...     }       }  impl<T: Default> Option<T> {     pub fn unwrap_or_default(self) -> T {         ...     } }
I'd prefer for method to be in as few impl blocks as possible with the most logical grouping within each impl block. Any bounds needed can be written as `where` clauses on the method instead: ```rust impl Option { pub fn unwrap_or(self default: T) -> T { ... } pub fn unwrap_or_default(self) -> T where T: Default { ... } } ``` *Warning: the end-to-end diff of this PR is computed confusingly by git / rendered confusingly by GitHub; it's practically impossible to review that way. I've broken the PR into commits that move small groups of methods for which git behaves better — these each should be easily individually reviewable.*",HEART,2022-01-03T10:05:21Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/92448,MERGED,2021-12-30T21:59:58Z,2022-01-05T15:28:39Z,Set font size proportional to user's font size,jsha,5bf321f9a42dd0d6492d6a14e46d6c68a29d2e4e,1,"Rollup merge of #92448 - jsha:font-size-access r=GuillaumeGomez Set font size proportional to user's font size According to MDN (https://developer.mozilla.org/en-US/docs/Web/CSS/font-size) > To maximize accessibility it is generally best to use values that are relative to the user's default font size. > Defining font sizes in px is not accessible because the user cannot change the font size in some browsers. Note that changing font size (in browser or OS settings) is distinct from the zoom functionality triggered with Ctrl/Cmd-+. Zoom functionality increases the size of everything on the page effectively applying a multiplier to all pixel sizes. Font size changes apply to just text. For relative font sizes we could use `em` as we do in several places already. However that has a problem of ""compounding"" (see MDN article for details). The compounding problem is nicely solved by `rem` which make font sizes relative to the root element not the parent element. Since we were using a hodge-podge of pixel sizes em rem and percentage sizes before this change switches everything to rem while keeping the same size relative to our old default of 16px. 16px is still the default on most browsers for users that haven't set a larger or smaller font size. Part of #59845. Note: this will conflict with #92404. We should merge that first (once it's done) and I'll resolve the merge conflicts. r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/font-size-access/std/string/struct.String.html",THUMBS_UP,2021-12-30T22:19:42Z,Urgau,NA https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2021-12-31T03:18:54Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2021-12-31T05:30:01Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2021-12-31T10:34:19Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2021-12-31T10:52:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2022-01-01T00:48:15Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2022-01-02T21:16:16Z,Agrailag,NA https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2022-01-11T00:10:42Z,estebank,NA https://github.com/rust-lang/rust/pull/92449,CLOSED,2021-12-30T23:36:52Z,2022-06-03T13:47:08Z,Correctly check auto traits on generator interiors,compiler-errors,NA,NA,NA,HOORAY,2022-04-09T06:11:35Z,puuuuh,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2021-12-31T21:13:03Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2021-12-31T21:46:12Z,Urgau,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2021-12-31T23:13:34Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2021-12-31T23:51:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-01T00:27:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-01T02:04:59Z,camelid,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-01T02:08:12Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-01T03:04:23Z,CryZe,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2022-01-01T03:04:25Z,CryZe,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-01T17:21:48Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2022-01-02T00:43:18Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-02T00:43:18Z,bobbbay,bobbbay.b@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-02T01:19:32Z,jcdyer,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-02T13:34:54Z,llogiq,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-04T18:48:14Z,qm3ster,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2022-01-06T13:28:45Z,LyesSaadi,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-01-06T17:44:42Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2022-01-07T04:06:53Z,foodstuff,NA https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-04-08T20:42:07Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,LAUGH,2022-04-08T20:42:10Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/92463,MERGED,2021-12-31T21:05:24Z,2022-01-02T03:21:30Z,Remove pronunciation guide from Vec,thomcc,aa31c9726da6ba10f76c700a52b4682555e745d9,1,Rollup merge of #92463 - thomcc:thats-not-how-its-pronounced r=joshtriplett Remove pronunciation guide from Vec I performed an extremely scientific poll on twitter and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315,THUMBS_UP,2022-06-20T18:33:18Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-01T09:29:36Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-01T13:34:23Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,LAUGH,2022-01-01T15:19:38Z,Voker57,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-01T15:28:37Z,Kolsky,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-01T15:28:39Z,Kolsky,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-01T15:59:31Z,l29ah,zl29ah@gmail.com https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,LAUGH,2022-01-01T15:59:33Z,l29ah,zl29ah@gmail.com https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-01T15:59:46Z,l29ah,zl29ah@gmail.com https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-01T18:25:17Z,VictorBulba,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-01T21:13:12Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-02T10:06:17Z,Smertig,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-02T16:58:51Z,Mefgalm,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-02T16:58:54Z,Mefgalm,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-04T10:46:35Z,mrThe,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-04T10:47:10Z,mrThe,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-04T13:08:50Z,hatarist,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T11:56:42Z,AnthonyMikh,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,LAUGH,2022-01-24T12:57:36Z,fstirlitz,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T12:57:50Z,jebediahjoo,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T13:41:54Z,Rapptz,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T14:16:32Z,ikbenlike,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T14:36:53Z,kspalaiologos,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T15:07:43Z,clubby789-htb,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T15:22:27Z,Gaarco,NA https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T15:31:24Z,LordMZTE,lord@mzte.de https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,CONFUSED,2022-01-24T15:31:26Z,LordMZTE,lord@mzte.de https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,HEART,2022-01-24T15:45:04Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/92469,MERGED,2022-01-01T05:14:09Z,2022-01-01T13:28:11Z,Make tidy check for magic numbers that spell things,joshtriplett,4bd4e271e44a88cf57d63214716f5c33429cf2d3,6,Rollup merge of #92469 - joshtriplett:test-number-fix r=Mark-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`,THUMBS_DOWN,2022-01-24T15:56:51Z,Rydgel,jerome.mahuet@gmail.com https://github.com/rust-lang/rust/pull/92483,MERGED,2022-01-01T22:20:58Z,2022-01-05T18:44:56Z,Stabilize `result_cloned` and `result_copied`,ksqsf,051d591edff3f771d6aa7fb6c386fdc4177fc5cd,1,Rollup merge of #92483 - ksqsf:master r=dtolnay Stabilize `result_cloned` and `result_copied` Tracking issue: #63168 The FCP is now completed.,HEART,2022-01-02T17:38:37Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/92483,MERGED,2022-01-01T22:20:58Z,2022-01-05T18:44:56Z,Stabilize `result_cloned` and `result_copied`,ksqsf,051d591edff3f771d6aa7fb6c386fdc4177fc5cd,1,Rollup merge of #92483 - ksqsf:master r=dtolnay Stabilize `result_cloned` and `result_copied` Tracking issue: #63168 The FCP is now completed.,HEART,2022-01-06T06:43:13Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/92483,MERGED,2022-01-01T22:20:58Z,2022-01-05T18:44:56Z,Stabilize `result_cloned` and `result_copied`,ksqsf,051d591edff3f771d6aa7fb6c386fdc4177fc5cd,1,Rollup merge of #92483 - ksqsf:master r=dtolnay Stabilize `result_cloned` and `result_copied` Tracking issue: #63168 The FCP is now completed.,HEART,2022-02-22T19:59:13Z,CPerezz,NA https://github.com/rust-lang/rust/pull/92504,MERGED,2022-01-02T22:37:38Z,2022-01-07T02:07:50Z,Exit nonzero on rustc -Wall,dtolnay,844a657bb85dfea37c7fb0a01c927c38fc586b40,1,"Rollup merge of #92504 - dtolnay:wall r=jackh726 Exit nonzero on rustc -Wall Previously `rustc -Wall /dev/null` would print a paragraph explaining that `-Wall` is not a thing in Rust but would then exit 0. I believe exiting 0 is not the right behavior. For something like `rustc --version` or `rustc --help` or `rustc -C help` the user is requesting rustc to print some information; rustc prints that information and exits 0 because what the user requested has been accomplished. In the case of `rustc -Wall path/to/main.rs` I don't find it correct to conceptualize this as ""the user requested rustc to print information about the fact that Wall doesn't exist"". The user requested a particular thing and despite rustc knowing what they probably meant and informing them about that the thing they requested has *not* been accomplished. Thus a nonzero exit code is needed.",HEART,2022-01-02T22:50:48Z,camelid,NA https://github.com/rust-lang/rust/pull/92504,MERGED,2022-01-02T22:37:38Z,2022-01-07T02:07:50Z,Exit nonzero on rustc -Wall,dtolnay,844a657bb85dfea37c7fb0a01c927c38fc586b40,1,"Rollup merge of #92504 - dtolnay:wall r=jackh726 Exit nonzero on rustc -Wall Previously `rustc -Wall /dev/null` would print a paragraph explaining that `-Wall` is not a thing in Rust but would then exit 0. I believe exiting 0 is not the right behavior. For something like `rustc --version` or `rustc --help` or `rustc -C help` the user is requesting rustc to print some information; rustc prints that information and exits 0 because what the user requested has been accomplished. In the case of `rustc -Wall path/to/main.rs` I don't find it correct to conceptualize this as ""the user requested rustc to print information about the fact that Wall doesn't exist"". The user requested a particular thing and despite rustc knowing what they probably meant and informing them about that the thing they requested has *not* been accomplished. Thus a nonzero exit code is needed.",THUMBS_UP,2022-01-03T03:49:50Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92504,MERGED,2022-01-02T22:37:38Z,2022-01-07T02:07:50Z,Exit nonzero on rustc -Wall,dtolnay,844a657bb85dfea37c7fb0a01c927c38fc586b40,1,"Rollup merge of #92504 - dtolnay:wall r=jackh726 Exit nonzero on rustc -Wall Previously `rustc -Wall /dev/null` would print a paragraph explaining that `-Wall` is not a thing in Rust but would then exit 0. I believe exiting 0 is not the right behavior. For something like `rustc --version` or `rustc --help` or `rustc -C help` the user is requesting rustc to print some information; rustc prints that information and exits 0 because what the user requested has been accomplished. In the case of `rustc -Wall path/to/main.rs` I don't find it correct to conceptualize this as ""the user requested rustc to print information about the fact that Wall doesn't exist"". The user requested a particular thing and despite rustc knowing what they probably meant and informing them about that the thing they requested has *not* been accomplished. Thus a nonzero exit code is needed.",THUMBS_UP,2022-01-17T08:08:57Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/92507,MERGED,2022-01-03T04:41:20Z,2022-01-04T23:01:53Z,Suggest single quotes when char expected str provided,chordtoll,25fcc0ef8c4a3b7a8dbfefdb3b198c09cee9f1c4,10,"Rollup merge of #92507 - chordtoll:suggest-single-quotes r=petrochenkov Suggest single quotes when char expected str provided If a type mismatch occurs where a char is expected and a string literal is provided suggest changing the double quotes to single quotes. We already provide this suggestion in the other direction ( ' -> "" ). Especially useful for new rust devs used to a language in which single/double quotes are interchangeable. Fixes #92479.",THUMBS_UP,2022-01-03T08:31:42Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92507,MERGED,2022-01-03T04:41:20Z,2022-01-04T23:01:53Z,Suggest single quotes when char expected str provided,chordtoll,25fcc0ef8c4a3b7a8dbfefdb3b198c09cee9f1c4,10,"Rollup merge of #92507 - chordtoll:suggest-single-quotes r=petrochenkov Suggest single quotes when char expected str provided If a type mismatch occurs where a char is expected and a string literal is provided suggest changing the double quotes to single quotes. We already provide this suggestion in the other direction ( ' -> "" ). Especially useful for new rust devs used to a language in which single/double quotes are interchangeable. Fixes #92479.",THUMBS_UP,2022-01-03T19:26:35Z,danielg1111,NA https://github.com/rust-lang/rust/pull/92508,CLOSED,2022-01-03T05:02:35Z,2022-05-22T02:05:30Z,Refine scopes around temporaries generated in local accesses,dingxiangfei2009,NA,NA,NA,HEART,2022-02-21T17:55:36Z,tema3210,NA https://github.com/rust-lang/rust/pull/92509,MERGED,2022-01-03T05:54:31Z,2022-03-06T15:26:27Z,doc: `Iterator::partition` use partial type hints,Gentoli,d85e4b1e359be89ff6e55b71f54ed84c5a85d1f1,1,Rollup merge of #92509 - Gentoli:partition-ex r=camelid doc: `Iterator::partition` use partial type hints Switch to partial type hints to indicate only the collection type is needed.,THUMBS_UP,2022-01-03T10:53:55Z,fmease,NA https://github.com/rust-lang/rust/pull/92525,MERGED,2022-01-03T17:19:19Z,2022-01-04T23:01:53Z,intra-doc: Make `Receiver::into_iter` into a clickable link,zohnannor,b2d6ff4b6eed1091e38186767523f19fbaa00a72,1,Rollup merge of #92525 - zohnannor:patch-1 r=camelid intra-doc: Make `Receiver::into_iter` into a clickable link The documentation on `std::sync::mpsc::Iter` and `std::sync::mpsc::TryIter` provides links to the corresponding `Receiver` methods unlike `std::sync::mpsc::IntoIter` does. This was left out in c59b188aaeadea32625534250d1f5120420be000 Related to #29377,THUMBS_UP,2022-01-04T23:20:40Z,Saime-0,acc.saime.d@gmail.com https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T17:34:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T17:50:10Z,est31,NA https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T18:05:44Z,weihanglo,NA https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T18:15:01Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T18:23:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-03T23:57:37Z,camelid,NA https://github.com/rust-lang/rust/pull/92526,MERGED,2022-01-03T17:21:28Z,2022-01-13T03:21:46Z,Migrate rustdoc from Tera to Askama,djc,e916815d21e37af5cd85f9eb67cda155d7129fff,13,Auto merge of #92526 - djc:rustdoc-askama r=jsha Migrate rustdoc from Tera to Askama See #84419. Should probably get a benchmarking run to verify if it has the intended effect on rustdoc performance. cc `@jsha` `@jyn514.`,HEART,2022-01-04T08:44:43Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/92533,MERGED,2022-01-03T20:34:58Z,2022-01-12T00:18:30Z,Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`,Aaron1011,72e74d7b9cf1a7901650227e74650f1fcc797600,38,Auto merge of #92533 - Aaron1011:variant-symbol r=petrochenkov Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef` The field is also renamed from `ident` to `name`. In most cases we don't actually need the `Span`. A new `ident` method is added to `VariantDef` and `FieldDef` which constructs the full `Ident` using `tcx.def_ident_span()`. This method is used in the cases where we actually need an `Ident`. This makes incremental compilation properly track changes to the `Span` without all of the invalidations caused by storing a `Span` directly via an `Ident`.,HEART,2022-02-06T22:05:25Z,pierwill,NA https://github.com/rust-lang/rust/pull/92533,MERGED,2022-01-03T20:34:58Z,2022-01-12T00:18:30Z,Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`,Aaron1011,72e74d7b9cf1a7901650227e74650f1fcc797600,38,Auto merge of #92533 - Aaron1011:variant-symbol r=petrochenkov Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef` The field is also renamed from `ident` to `name`. In most cases we don't actually need the `Span`. A new `ident` method is added to `VariantDef` and `FieldDef` which constructs the full `Ident` using `tcx.def_ident_span()`. This method is used in the cases where we actually need an `Ident`. This makes incremental compilation properly track changes to the `Span` without all of the invalidations caused by storing a `Span` directly via an `Ident`.,HEART,2022-02-19T14:35:21Z,oli-obk,NA https://github.com/rust-lang/rust/pull/92533,MERGED,2022-01-03T20:34:58Z,2022-01-12T00:18:30Z,Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`,Aaron1011,72e74d7b9cf1a7901650227e74650f1fcc797600,38,Auto merge of #92533 - Aaron1011:variant-symbol r=petrochenkov Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef` The field is also renamed from `ident` to `name`. In most cases we don't actually need the `Span`. A new `ident` method is added to `VariantDef` and `FieldDef` which constructs the full `Ident` using `tcx.def_ident_span()`. This method is used in the cases where we actually need an `Ident`. This makes incremental compilation properly track changes to the `Span` without all of the invalidations caused by storing a `Span` directly via an `Ident`.,HEART,2022-02-26T14:11:14Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92533,MERGED,2022-01-03T20:34:58Z,2022-01-12T00:18:30Z,Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`,Aaron1011,72e74d7b9cf1a7901650227e74650f1fcc797600,38,Auto merge of #92533 - Aaron1011:variant-symbol r=petrochenkov Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef` The field is also renamed from `ident` to `name`. In most cases we don't actually need the `Span`. A new `ident` method is added to `VariantDef` and `FieldDef` which constructs the full `Ident` using `tcx.def_ident_span()`. This method is used in the cases where we actually need an `Ident`. This makes incremental compilation properly track changes to the `Span` without all of the invalidations caused by storing a `Span` directly via an `Ident`.,THUMBS_UP,2022-02-26T14:11:17Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/92534,MERGED,2022-01-03T20:53:23Z,2022-01-09T19:12:15Z,Hash `Ident` spans in all HIR structures,Aaron1011,092e1c9d23158d81be27bb6f71bdd0c6282478fb,2,Auto merge of #92534 - Aaron1011:hash-hir r=petrochenkov Hash `Ident` spans in all HIR structures This PR removes all of the `#[stable_hasher(project(name))]` attributes used in HIR structs. While these attributes are not known to be causing any issues in practice we need to hash these in order for the incremental system to work correctly - a query could be otherwise be incorrectly marked green when a change occures in one of the `Span`s that it uses.,HOORAY,2022-01-04T17:28:58Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92534,MERGED,2022-01-03T20:53:23Z,2022-01-09T19:12:15Z,Hash `Ident` spans in all HIR structures,Aaron1011,092e1c9d23158d81be27bb6f71bdd0c6282478fb,2,Auto merge of #92534 - Aaron1011:hash-hir r=petrochenkov Hash `Ident` spans in all HIR structures This PR removes all of the `#[stable_hasher(project(name))]` attributes used in HIR structs. While these attributes are not known to be causing any issues in practice we need to hash these in order for the incremental system to work correctly - a query could be otherwise be incorrectly marked green when a change occures in one of the `Span`s that it uses.,HOORAY,2022-02-06T22:04:44Z,pierwill,NA https://github.com/rust-lang/rust/pull/92541,MERGED,2022-01-03T22:18:06Z,2022-03-10T04:58:49Z,Mention intent of `From` trait in its docs,asquared31415,2567d0f8837d351beba9c30545833fdf4bdc7054,1,Rollup merge of #92541 - asquared31415:from-docs r=m-ou-se Mention intent of `From` trait in its docs This pr is a docs modification to add to the documentation of the `From` trait a note about its intent as a perfect conversion. This is already stated in the `TryFrom` docs so this is simply adding that information in a more visible way.,THUMBS_UP,2022-03-10T01:04:52Z,scottmcm,NA https://github.com/rust-lang/rust/pull/92543,CLOSED,2022-01-03T22:57:38Z,2022-01-04T23:02:47Z,`Iterator::cloned`: document side effect behavior,llogiq,NA,NA,NA,THUMBS_DOWN,2022-01-04T03:17:47Z,the8472,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T15:56:29Z,lqd,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T16:03:01Z,programmerjake,programmerjake@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T16:52:03Z,hkratz,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T17:15:49Z,CryZe,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T17:26:43Z,Urgau,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T17:42:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T18:00:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T18:07:46Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T18:16:50Z,cynecx,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T19:06:07Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T20:49:20Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T21:23:41Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T21:37:49Z,kangalioo,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T21:55:43Z,y21,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T22:09:02Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-04T22:49:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T01:16:44Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T10:19:16Z,weihanglo,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T10:58:08Z,taiki-e,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T11:41:44Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T12:46:21Z,darksv,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T18:42:27Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-05T19:42:01Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-06T04:55:45Z,veber-alex,alexveber@gmail.com https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-06T06:40:12Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-07T03:57:10Z,Folyd,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-07T09:09:39Z,mati865,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-10T04:29:28Z,mjguynn,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,THUMBS_UP,2022-01-13T00:00:58Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-22T17:00:25Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-22T20:50:18Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HEART,2022-01-24T07:42:25Z,iago-lito,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-26T07:10:59Z,pangzhenzhou,NA https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HOORAY,2022-01-27T18:05:57Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/92555,MERGED,2022-01-04T15:14:13Z,2022-01-24T02:20:56Z,Implement RFC 3151: Scoped threads.,m-ou-se,bb260e8950293b84d1da4724cc72027328b74a74,2,Rollup merge of #92555 - m-ou-se:scoped-threads r=Amanieu Implement RFC 3151: Scoped threads. This implements https://github.com/rust-lang/rfcs/pull/3151 r? `@Amanieu`,HEART,2022-01-27T18:05:58Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/92566,MERGED,2022-01-05T01:39:04Z,2022-05-03T00:09:06Z,Inline `__iterator_get_unchecked` for some iterator adapters.,the8472,3d0ac7ea23888438752957eeeb5aa2b73b4fda72,6,Auto merge of #92566 - the8472:inline-tra r=m-ou-se Inline `__iterator_get_unchecked` for some iterator adapters. This aligns the inline attributes of existing `__iterator_get_unchecked` with those of `next()` on adapters that have both. It improves the performance of iterators using unchecked access when building in incremental mode (due to the larger CGU count?). It might negatively affect incremental compile times for better runtime results but considering that the equivalent `next()` implementations also are `#[inline]` and usually are more complex this should be ok. ``` ./x.py bench library/core -i --stage 0 --test-args bench_trusted_random_access OLD: 119 172 ns/iter NEW: 17 714 ns/iter ```,HOORAY,2022-01-06T19:34:35Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/92582,MERGED,2022-01-05T10:46:55Z,2022-01-20T23:48:12Z,improve `_` constants in item signature handling,lcnr,db1253f1d29dc71216c1a1f2473fd37f2a5275d0,40,"Rollup merge of #92582 - lcnr:generic-arg-infer r=BoxyUwU improve `_` constants in item signature handling removing the ""type"" from the error messages does slightly worsen the error messages for types but figuring out whether the placeholder is for a type or a constant and correctly dealing with that seemed fairly difficult to me so I took the easy way out :sparkles: Imo the error message is still clear enough. r? `@BoxyUwU` cc `@estebank`",HEART,2022-01-22T01:45:56Z,estebank,NA https://github.com/rust-lang/rust/pull/92584,MERGED,2022-01-05T11:56:49Z,2022-02-01T20:05:51Z,add rustc lint warning when iterating over hashmaps 2,lcnr,741b62af0749ddf88ebbd7cad6ec7a15ab1fc1cb,42,Rollup merge of #92584 - lcnr:query-stable-lint r=estebank add rustc lint warning when iterating over hashmaps 2 first introduced in #89558 and reverted in #90380 due to its perf impact r? ``@estebank``,THUMBS_UP,2022-01-05T12:13:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92584,MERGED,2022-01-05T11:56:49Z,2022-02-01T20:05:51Z,add rustc lint warning when iterating over hashmaps 2,lcnr,741b62af0749ddf88ebbd7cad6ec7a15ab1fc1cb,42,Rollup merge of #92584 - lcnr:query-stable-lint r=estebank add rustc lint warning when iterating over hashmaps 2 first introduced in #89558 and reverted in #90380 due to its perf impact r? ``@estebank``,THUMBS_UP,2022-02-01T01:18:36Z,estebank,NA https://github.com/rust-lang/rust/pull/92600,MERGED,2022-01-06T00:07:27Z,2022-01-08T08:55:32Z,Add some missing `#[must_use]` to some `f{32 64}` operations,asquared31415,d43c9ad5d333e0c2ad770b82d2372c6efb0f36e5,2,Rollup merge of #92600 - asquared31415:float-must-use r=joshtriplett Add some missing `#[must_use]` to some `f{32 64}` operations This PR adds `#[must_use]` to the following methods: - `f32::recip` - `f32::max` - `f32::min` - `f32::maximum` - `f32::minimum` and their equivalents in `f64`. These methods all produce a new value without modifying the original and so are pointless to call without using the result.,THUMBS_UP,2022-01-06T00:11:05Z,Urgau,NA https://github.com/rust-lang/rust/pull/92600,MERGED,2022-01-06T00:07:27Z,2022-01-08T08:55:32Z,Add some missing `#[must_use]` to some `f{32 64}` operations,asquared31415,d43c9ad5d333e0c2ad770b82d2372c6efb0f36e5,2,Rollup merge of #92600 - asquared31415:float-must-use r=joshtriplett Add some missing `#[must_use]` to some `f{32 64}` operations This PR adds `#[must_use]` to the following methods: - `f32::recip` - `f32::max` - `f32::min` - `f32::maximum` - `f32::minimum` and their equivalents in `f64`. These methods all produce a new value without modifying the original and so are pointless to call without using the result.,THUMBS_UP,2022-02-18T11:53:11Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/92602,MERGED,2022-01-06T01:21:13Z,2022-01-10T15:03:43Z,Make source links look cleaner,jsha,a4ac4fae416b18f71a2f7ef2772ca4a4cc871828,20,"Rollup merge of #92602 - jsha:source-link-2 r=GuillaumeGomez Make source links look cleaner Change from syntaxy-looking [src] to the plain word ""source"". Change the syntaxy-looking `[-]` at the top of the page to say ""collapse"". Reduce opacity of rightside content. Part of #59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).",HEART,2022-01-06T01:56:38Z,camelid,NA https://github.com/rust-lang/rust/pull/92602,MERGED,2022-01-06T01:21:13Z,2022-01-10T15:03:43Z,Make source links look cleaner,jsha,a4ac4fae416b18f71a2f7ef2772ca4a4cc871828,20,"Rollup merge of #92602 - jsha:source-link-2 r=GuillaumeGomez Make source links look cleaner Change from syntaxy-looking [src] to the plain word ""source"". Change the syntaxy-looking `[-]` at the top of the page to say ""collapse"". Reduce opacity of rightside content. Part of #59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).",THUMBS_UP,2022-01-06T02:26:39Z,fmease,NA https://github.com/rust-lang/rust/pull/92602,MERGED,2022-01-06T01:21:13Z,2022-01-10T15:03:43Z,Make source links look cleaner,jsha,a4ac4fae416b18f71a2f7ef2772ca4a4cc871828,20,"Rollup merge of #92602 - jsha:source-link-2 r=GuillaumeGomez Make source links look cleaner Change from syntaxy-looking [src] to the plain word ""source"". Change the syntaxy-looking `[-]` at the top of the page to say ""collapse"". Reduce opacity of rightside content. Part of #59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).",HEART,2022-01-06T02:26:44Z,fmease,NA https://github.com/rust-lang/rust/pull/92602,MERGED,2022-01-06T01:21:13Z,2022-01-10T15:03:43Z,Make source links look cleaner,jsha,a4ac4fae416b18f71a2f7ef2772ca4a4cc871828,20,"Rollup merge of #92602 - jsha:source-link-2 r=GuillaumeGomez Make source links look cleaner Change from syntaxy-looking [src] to the plain word ""source"". Change the syntaxy-looking `[-]` at the top of the page to say ""collapse"". Reduce opacity of rightside content. Part of #59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).",THUMBS_DOWN,2022-01-06T05:53:14Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/92602,MERGED,2022-01-06T01:21:13Z,2022-01-10T15:03:43Z,Make source links look cleaner,jsha,a4ac4fae416b18f71a2f7ef2772ca4a4cc871828,20,"Rollup merge of #92602 - jsha:source-link-2 r=GuillaumeGomez Make source links look cleaner Change from syntaxy-looking [src] to the plain word ""source"". Change the syntaxy-looking `[-]` at the top of the page to say ""collapse"". Reduce opacity of rightside content. Part of #59851 r? `@GuillaumeGomez` Demo: https://rustdoc.crud.net/jsha/source-link-2/std/string/struct.String.html [Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/display.20of.20source.20link).",THUMBS_DOWN,2022-01-06T14:36:45Z,faptc,NA https://github.com/rust-lang/rust/pull/92604,MERGED,2022-01-06T02:05:49Z,2022-01-15T10:26:06Z,Optimize `impl_read_unsigned_leb128`,nnethercote,38c22af0153cf8f920c01ef04493e8878401fd18,3,Auto merge of #92604 - nnethercote:optimize-impl_read_unsigned_leb128 r=michaelwoerister Optimize `impl_read_unsigned_leb128` I see instruction count improvements of up to 3.5% locally with these changes mostly on the smaller benchmarks. r? `@michaelwoerister`,THUMBS_UP,2022-01-06T11:29:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92619,MERGED,2022-01-06T17:18:26Z,2022-01-16T20:27:51Z,Add diagnostic items for macros,Alexendoo,cf4549c920a62a0bc71357172d8471bb4182637b,5,Rollup merge of #92619 - Alexendoo:macro-diagnostic-items r=matthewjasper Add diagnostic items for macros For use in Clippy it adds diagnostic items to all the stable public macros Clippy has lints that look for almost all of these (currently by name or path) but there are a few that aren't currently part of any lint I could remove those if it's preferred to add them as needed rather than ahead of time,HEART,2022-01-12T21:43:01Z,camsteffen,NA https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-03-18T22:28:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-04-04T21:02:47Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-04-05T15:25:49Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-04-07T18:50:37Z,zohnannor,NA https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-04-07T23:07:49Z,worstpractice,NA https://github.com/rust-lang/rust/pull/92630,MERGED,2022-01-06T23:42:25Z,2022-01-20T02:14:50Z,Change PhantomData type for `BuildHasherDefault` (and more),steffahn,dfbb6b246da3758911d5625a3b6ec4ecec9a01ab,3,Rollup merge of #92630 - steffahn:lift_bounds_on_BuildHasherDefault r=yaahc Change PhantomData type for `BuildHasherDefault` (and more) Changes `PhantomData` to `PhantomData H>` for `BuildHasherDefault`. This preserves the covariance of `H` while it lifts the currently inferred unnecessary bounds like [`H: Send` for `BuildHasherDefault: Send`](https://doc.rust-lang.org/1.57.0/std/hash/struct.BuildHasherDefault.html#impl-Send) etc. _Edit:_ Also does a similar change for `iter::Empty` and `future::Pending`.,HEART,2022-04-13T13:51:18Z,pro465,NA https://github.com/rust-lang/rust/pull/92636,MERGED,2022-01-07T03:20:38Z,2022-01-10T15:03:43Z,Normalize generator-local types with unevaluated constants,compiler-errors,ca9fc28f0be061ef770bec410d90c5418b6689dd,2,Rollup merge of #92636 - compiler-errors:normalize-generator-const-expr r=oli-obk Normalize generator-local types with unevaluated constants Normalize generator-interior types in addition to (i.e. instead of just) erasing regions since sometimes we collect types with unevaluated const exprs. Fixes #84737 Fixes #88171 Fixes #92091 Fixes #92634 Probably also fixes #73114 but that one has no code I could test. It looks like it's the same issue though.,THUMBS_UP,2022-01-07T22:00:07Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/92651,MERGED,2022-01-07T17:48:02Z,2022-02-06T08:34:50Z,"Remove ""up here"" arrow on item-infos",jsha,05bb32dde2289b5385373af2faaabc4b8498aa50,3,"Rollup merge of #92651 - jsha:impl-spacing r=GuillaumeGomez Remove ""up here"" arrow on item-infos Use spacing to distinguish what is related to a given heading. This was originally introduced in #53043 in response to #51387. The arrow is a little distracting and leads the item-info to not be aligned properly with the text below it. Demo: https://rustdoc.crud.net/jsha/impl-spacing/std/string/struct.String.html r? ``@GuillaumeGomez``",THUMBS_UP,2022-01-07T18:16:11Z,Urgau,NA https://github.com/rust-lang/rust/pull/92651,MERGED,2022-01-07T17:48:02Z,2022-02-06T08:34:50Z,"Remove ""up here"" arrow on item-infos",jsha,05bb32dde2289b5385373af2faaabc4b8498aa50,3,"Rollup merge of #92651 - jsha:impl-spacing r=GuillaumeGomez Remove ""up here"" arrow on item-infos Use spacing to distinguish what is related to a given heading. This was originally introduced in #53043 in response to #51387. The arrow is a little distracting and leads the item-info to not be aligned properly with the text below it. Demo: https://rustdoc.crud.net/jsha/impl-spacing/std/string/struct.String.html r? ``@GuillaumeGomez``",THUMBS_UP,2022-01-07T19:33:04Z,camelid,NA https://github.com/rust-lang/rust/pull/92651,MERGED,2022-01-07T17:48:02Z,2022-02-06T08:34:50Z,"Remove ""up here"" arrow on item-infos",jsha,05bb32dde2289b5385373af2faaabc4b8498aa50,3,"Rollup merge of #92651 - jsha:impl-spacing r=GuillaumeGomez Remove ""up here"" arrow on item-infos Use spacing to distinguish what is related to a given heading. This was originally introduced in #53043 in response to #51387. The arrow is a little distracting and leads the item-info to not be aligned properly with the text below it. Demo: https://rustdoc.crud.net/jsha/impl-spacing/std/string/struct.String.html r? ``@GuillaumeGomez``",THUMBS_UP,2022-04-09T05:28:09Z,faptc,NA https://github.com/rust-lang/rust/pull/92652,CLOSED,2022-01-07T18:28:56Z,2022-01-12T20:03:53Z,Implement `Deref` for `[T; N]` and fix const infer variable canonicalization (fix `Deref` ICEs),compiler-errors,NA,NA,NA,THUMBS_UP,2022-01-07T21:58:46Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/92652,CLOSED,2022-01-07T18:28:56Z,2022-01-12T20:03:53Z,Implement `Deref` for `[T; N]` and fix const infer variable canonicalization (fix `Deref` ICEs),compiler-errors,NA,NA,NA,HOORAY,2022-01-12T17:38:58Z,a1phyr,NA https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,HEART,2022-01-08T11:51:22Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,HEART,2022-01-20T14:20:58Z,fmease,NA https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,HEART,2022-02-04T16:05:24Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,THUMBS_DOWN,2022-02-07T17:42:57Z,aloucks,NA https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,HEART,2022-02-08T04:45:35Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/92660,CLOSED,2022-01-08T00:44:27Z,2022-02-09T19:33:42Z,"Merge ""Structs"" ""Enums"" etc. sections into new ""Types"" section",camelid,NA,NA,NA,THUMBS_UP,2022-02-08T04:45:40Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/92663,MERGED,2022-01-08T02:48:59Z,2022-03-19T05:04:09Z,Implement `Write for Cursor<[u8; N]>` plus `A: Allocator` cursor support,cuviper,e9f63fdf86de2a515da26bb905c1470e6363caf3,2,Rollup merge of #92663 - cuviper:generic-write-cursor r=dtolnay Implement `Write for Cursor<[u8; N]>` plus `A: Allocator` cursor support This implements `Write for Cursor<[u8; N]>` and also adds support for generic `A: Allocator` in `Box` and `Vec` cursors. This was inspired by a user questioning why they couldn't write a `Cursor<[u8; N]>`: https://users.rust-lang.org/t/why-vec-and-not-u8-makes-cursor-have-write/68210 Related history: - #27197 switched `AsRef<[u8]>` for reading and seeking - #67415 tried to use `AsMut<[u8]>` for writing but did not specialize `Vec`.,THUMBS_UP,2022-03-24T07:43:16Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/92669,CLOSED,2022-01-08T12:39:28Z,2022-01-12T01:37:32Z,Draft: Stabilize `#![register_tool]` (#66079),smoelius,NA,NA,NA,EYES,2022-01-08T18:32:12Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92669,CLOSED,2022-01-08T12:39:28Z,2022-01-12T01:37:32Z,Draft: Stabilize `#![register_tool]` (#66079),smoelius,NA,NA,NA,EYES,2022-01-09T02:06:52Z,Miaxos,an.griffon@gmail.com https://github.com/rust-lang/rust/pull/92683,MERGED,2022-01-09T04:37:06Z,2022-02-18T21:58:28Z,Suggest copying trait associated type bounds on lifetime error,jackh726,dd111262b2a18e532d700b67a8062faa286d1a36,12,Rollup merge of #92683 - jackh726:issue-92033 r=estebank Suggest copying trait associated type bounds on lifetime error Closes #92033 Kind of the most simple suggestion to make - we don't try to be fancy. Turns out it's still pretty useful (the couple existing tests that trigger this error end up fixed - for this error - upon applying the fix). r? ``@estebank`` cc ``@nikomatsakis``,THUMBS_UP,2022-02-18T23:23:03Z,chubei-oppen,chubei@oppentech.com https://github.com/rust-lang/rust/pull/92693,MERGED,2022-01-09T16:09:13Z,2022-01-10T15:03:43Z,Release notes: add `Result::unwrap_{ err_}unchecked`,ojeda,80275d66c8e8c6749f71a78cb814ff371417a686,1,Rollup merge of #92693 - ojeda:relnotes r=pietroalbini Release notes: add `Result::unwrap_{ err_}unchecked` They were stabilized together with `Option::unwrap_unchecked` in https://github.com/rust-lang/rust/issues/81383. Signed-off-by: Miguel Ojeda ,EYES,2022-01-09T16:40:37Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/92697,MERGED,2022-01-09T18:51:12Z,2022-03-04T00:05:00Z,Use cgroup quotas for calculating `available_parallelism`,the8472,a638f50d8d742c9a06f4f6d8f753df95bcf5e8ed,2,"Rollup merge of #92697 - the8472:cgroups r=joshtriplett Use cgroup quotas for calculating `available_parallelism` Automated tests for this are possible but would require a bunch of assumptions. It requires root + a recent kernel systemd and maybe docker. And even then it would need a helper binary since the test has to run in a separate process. Limitations * only supports cgroup v2 and assumes it's mounted under `/sys/fs/cgroup` * procfs must be available * the quota gets mixed into `sched_getaffinity` so if the latter doesn't work then quota information gets ignored too Manually tested via ``` // spawn a new cgroup scope for the current user $ sudo systemd-run -p CPUQuota=""300%"" --uid=$(id -u) -tdS // quota.rs #![feature(available_parallelism)] fn main() { println!(""{:?}"" std::thread::available_parallelism()); // prints Ok(3) } ``` strace: ``` sched_getaffinity(3041643 32 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 32 openat(AT_FDCWD ""/proc/self/cgroup"" O_RDONLY|O_CLOEXEC) = 3 statx(0 NULL AT_STATX_SYNC_AS_STAT STATX_ALL NULL) = -1 EFAULT (Bad address) statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""0::/system.slice/run-u31477.serv""... 128) = 36 read(3 """" 92) = 0 close(3) = 0 statx(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cgroup.controllers"" AT_STATX_SYNC_AS_STAT STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""300000 100000\n"" 20) = 14 read(3 """" 6) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""max 100000\n"" 20) = 11 read(3 """" 9) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/cpu.max"" O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) sched_getaffinity(0 128 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 40 ``` r? ```````@joshtriplett``````` cc ```````@yoshuawuyts``````` Tracking issue and previous discussion: #74479",HEART,2022-01-09T19:02:27Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/92697,MERGED,2022-01-09T18:51:12Z,2022-03-04T00:05:00Z,Use cgroup quotas for calculating `available_parallelism`,the8472,a638f50d8d742c9a06f4f6d8f753df95bcf5e8ed,2,"Rollup merge of #92697 - the8472:cgroups r=joshtriplett Use cgroup quotas for calculating `available_parallelism` Automated tests for this are possible but would require a bunch of assumptions. It requires root + a recent kernel systemd and maybe docker. And even then it would need a helper binary since the test has to run in a separate process. Limitations * only supports cgroup v2 and assumes it's mounted under `/sys/fs/cgroup` * procfs must be available * the quota gets mixed into `sched_getaffinity` so if the latter doesn't work then quota information gets ignored too Manually tested via ``` // spawn a new cgroup scope for the current user $ sudo systemd-run -p CPUQuota=""300%"" --uid=$(id -u) -tdS // quota.rs #![feature(available_parallelism)] fn main() { println!(""{:?}"" std::thread::available_parallelism()); // prints Ok(3) } ``` strace: ``` sched_getaffinity(3041643 32 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 32 openat(AT_FDCWD ""/proc/self/cgroup"" O_RDONLY|O_CLOEXEC) = 3 statx(0 NULL AT_STATX_SYNC_AS_STAT STATX_ALL NULL) = -1 EFAULT (Bad address) statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""0::/system.slice/run-u31477.serv""... 128) = 36 read(3 """" 92) = 0 close(3) = 0 statx(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cgroup.controllers"" AT_STATX_SYNC_AS_STAT STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""300000 100000\n"" 20) = 14 read(3 """" 6) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""max 100000\n"" 20) = 11 read(3 """" 9) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/cpu.max"" O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) sched_getaffinity(0 128 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 40 ``` r? ```````@joshtriplett``````` cc ```````@yoshuawuyts``````` Tracking issue and previous discussion: #74479",HEART,2022-02-24T19:26:11Z,mati865,NA https://github.com/rust-lang/rust/pull/92697,MERGED,2022-01-09T18:51:12Z,2022-03-04T00:05:00Z,Use cgroup quotas for calculating `available_parallelism`,the8472,a638f50d8d742c9a06f4f6d8f753df95bcf5e8ed,2,"Rollup merge of #92697 - the8472:cgroups r=joshtriplett Use cgroup quotas for calculating `available_parallelism` Automated tests for this are possible but would require a bunch of assumptions. It requires root + a recent kernel systemd and maybe docker. And even then it would need a helper binary since the test has to run in a separate process. Limitations * only supports cgroup v2 and assumes it's mounted under `/sys/fs/cgroup` * procfs must be available * the quota gets mixed into `sched_getaffinity` so if the latter doesn't work then quota information gets ignored too Manually tested via ``` // spawn a new cgroup scope for the current user $ sudo systemd-run -p CPUQuota=""300%"" --uid=$(id -u) -tdS // quota.rs #![feature(available_parallelism)] fn main() { println!(""{:?}"" std::thread::available_parallelism()); // prints Ok(3) } ``` strace: ``` sched_getaffinity(3041643 32 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 32 openat(AT_FDCWD ""/proc/self/cgroup"" O_RDONLY|O_CLOEXEC) = 3 statx(0 NULL AT_STATX_SYNC_AS_STAT STATX_ALL NULL) = -1 EFAULT (Bad address) statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""0::/system.slice/run-u31477.serv""... 128) = 36 read(3 """" 92) = 0 close(3) = 0 statx(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cgroup.controllers"" AT_STATX_SYNC_AS_STAT STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""300000 100000\n"" 20) = 14 read(3 """" 6) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""max 100000\n"" 20) = 11 read(3 """" 9) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/cpu.max"" O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) sched_getaffinity(0 128 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 40 ``` r? ```````@joshtriplett``````` cc ```````@yoshuawuyts``````` Tracking issue and previous discussion: #74479",HEART,2022-03-02T11:50:48Z,weihanglo,NA https://github.com/rust-lang/rust/pull/92697,MERGED,2022-01-09T18:51:12Z,2022-03-04T00:05:00Z,Use cgroup quotas for calculating `available_parallelism`,the8472,a638f50d8d742c9a06f4f6d8f753df95bcf5e8ed,2,"Rollup merge of #92697 - the8472:cgroups r=joshtriplett Use cgroup quotas for calculating `available_parallelism` Automated tests for this are possible but would require a bunch of assumptions. It requires root + a recent kernel systemd and maybe docker. And even then it would need a helper binary since the test has to run in a separate process. Limitations * only supports cgroup v2 and assumes it's mounted under `/sys/fs/cgroup` * procfs must be available * the quota gets mixed into `sched_getaffinity` so if the latter doesn't work then quota information gets ignored too Manually tested via ``` // spawn a new cgroup scope for the current user $ sudo systemd-run -p CPUQuota=""300%"" --uid=$(id -u) -tdS // quota.rs #![feature(available_parallelism)] fn main() { println!(""{:?}"" std::thread::available_parallelism()); // prints Ok(3) } ``` strace: ``` sched_getaffinity(3041643 32 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 32 openat(AT_FDCWD ""/proc/self/cgroup"" O_RDONLY|O_CLOEXEC) = 3 statx(0 NULL AT_STATX_SYNC_AS_STAT STATX_ALL NULL) = -1 EFAULT (Bad address) statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""0::/system.slice/run-u31477.serv""... 128) = 36 read(3 """" 92) = 0 close(3) = 0 statx(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cgroup.controllers"" AT_STATX_SYNC_AS_STAT STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""300000 100000\n"" 20) = 14 read(3 """" 6) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""max 100000\n"" 20) = 11 read(3 """" 9) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/cpu.max"" O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) sched_getaffinity(0 128 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 40 ``` r? ```````@joshtriplett``````` cc ```````@yoshuawuyts``````` Tracking issue and previous discussion: #74479",HEART,2022-05-19T20:39:55Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/92697,MERGED,2022-01-09T18:51:12Z,2022-03-04T00:05:00Z,Use cgroup quotas for calculating `available_parallelism`,the8472,a638f50d8d742c9a06f4f6d8f753df95bcf5e8ed,2,"Rollup merge of #92697 - the8472:cgroups r=joshtriplett Use cgroup quotas for calculating `available_parallelism` Automated tests for this are possible but would require a bunch of assumptions. It requires root + a recent kernel systemd and maybe docker. And even then it would need a helper binary since the test has to run in a separate process. Limitations * only supports cgroup v2 and assumes it's mounted under `/sys/fs/cgroup` * procfs must be available * the quota gets mixed into `sched_getaffinity` so if the latter doesn't work then quota information gets ignored too Manually tested via ``` // spawn a new cgroup scope for the current user $ sudo systemd-run -p CPUQuota=""300%"" --uid=$(id -u) -tdS // quota.rs #![feature(available_parallelism)] fn main() { println!(""{:?}"" std::thread::available_parallelism()); // prints Ok(3) } ``` strace: ``` sched_getaffinity(3041643 32 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 32 openat(AT_FDCWD ""/proc/self/cgroup"" O_RDONLY|O_CLOEXEC) = 3 statx(0 NULL AT_STATX_SYNC_AS_STAT STATX_ALL NULL) = -1 EFAULT (Bad address) statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""0::/system.slice/run-u31477.serv""... 128) = 36 read(3 """" 92) = 0 close(3) = 0 statx(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cgroup.controllers"" AT_STATX_SYNC_AS_STAT STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0444 stx_size=0 ...}) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/run-u31477.service/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""300000 100000\n"" 20) = 14 read(3 """" 6) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/system.slice/cpu.max"" O_RDONLY|O_CLOEXEC) = 3 statx(3 """" AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH STATX_ALL {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID stx_attributes=0 stx_mode=S_IFREG|0644 stx_size=0 ...}) = 0 lseek(3 0 SEEK_CUR) = 0 read(3 ""max 100000\n"" 20) = 11 read(3 """" 9) = 0 close(3) = 0 openat(AT_FDCWD ""/sys/fs/cgroup/cpu.max"" O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) sched_getaffinity(0 128 [0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]) = 40 ``` r? ```````@joshtriplett``````` cc ```````@yoshuawuyts``````` Tracking issue and previous discussion: #74479",HEART,2022-05-21T21:58:27Z,punkeel,NA https://github.com/rust-lang/rust/pull/92699,MERGED,2022-01-09T20:49:27Z,2022-01-12T21:04:51Z,"rustdoc: Display ""private fields"" instead of ""fields omitted""",camelid,b24b0fdcd0e7c1f003a3441bda83c6f9ece17ab8,4,"Rollup merge of #92699 - camelid:private-fields r=jsha rustdoc: Display ""private fields"" instead of ""fields omitted"" Also: * Always use `/* */` block comments * Use the same message everywhere rather than sometimes prefixing with ""some"" When I first read rustdoc docs I was confused why the fields were being omitted. It was only later that I realized it was because they were private. It's also always bothered me that rustdoc sometimes uses `//` and sometimes uses `/*` comments for these messages so this change makes them all use `/*`. Technically I think fields can be omitted if they are public but `doc(hidden)` too but `doc(hidden)` is analogous to privacy. It's really just used to emulate ""doc privacy"" when -- because of technical limitations -- an item has to be public. So I think it's fine to include this under the category of ""private fields"". r? ```@jsha```",THUMBS_UP,2022-01-09T21:00:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/92699,MERGED,2022-01-09T20:49:27Z,2022-01-12T21:04:51Z,"rustdoc: Display ""private fields"" instead of ""fields omitted""",camelid,b24b0fdcd0e7c1f003a3441bda83c6f9ece17ab8,4,"Rollup merge of #92699 - camelid:private-fields r=jsha rustdoc: Display ""private fields"" instead of ""fields omitted"" Also: * Always use `/* */` block comments * Use the same message everywhere rather than sometimes prefixing with ""some"" When I first read rustdoc docs I was confused why the fields were being omitted. It was only later that I realized it was because they were private. It's also always bothered me that rustdoc sometimes uses `//` and sometimes uses `/*` comments for these messages so this change makes them all use `/*`. Technically I think fields can be omitted if they are public but `doc(hidden)` too but `doc(hidden)` is analogous to privacy. It's really just used to emulate ""doc privacy"" when -- because of technical limitations -- an item has to be public. So I think it's fine to include this under the category of ""private fields"". r? ```@jsha```",THUMBS_UP,2022-01-10T02:22:42Z,fmease,NA https://github.com/rust-lang/rust/pull/92699,MERGED,2022-01-09T20:49:27Z,2022-01-12T21:04:51Z,"rustdoc: Display ""private fields"" instead of ""fields omitted""",camelid,b24b0fdcd0e7c1f003a3441bda83c6f9ece17ab8,4,"Rollup merge of #92699 - camelid:private-fields r=jsha rustdoc: Display ""private fields"" instead of ""fields omitted"" Also: * Always use `/* */` block comments * Use the same message everywhere rather than sometimes prefixing with ""some"" When I first read rustdoc docs I was confused why the fields were being omitted. It was only later that I realized it was because they were private. It's also always bothered me that rustdoc sometimes uses `//` and sometimes uses `/*` comments for these messages so this change makes them all use `/*`. Technically I think fields can be omitted if they are public but `doc(hidden)` too but `doc(hidden)` is analogous to privacy. It's really just used to emulate ""doc privacy"" when -- because of technical limitations -- an item has to be public. So I think it's fine to include this under the category of ""private fields"". r? ```@jsha```",THUMBS_UP,2022-01-10T08:29:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92699,MERGED,2022-01-09T20:49:27Z,2022-01-12T21:04:51Z,"rustdoc: Display ""private fields"" instead of ""fields omitted""",camelid,b24b0fdcd0e7c1f003a3441bda83c6f9ece17ab8,4,"Rollup merge of #92699 - camelid:private-fields r=jsha rustdoc: Display ""private fields"" instead of ""fields omitted"" Also: * Always use `/* */` block comments * Use the same message everywhere rather than sometimes prefixing with ""some"" When I first read rustdoc docs I was confused why the fields were being omitted. It was only later that I realized it was because they were private. It's also always bothered me that rustdoc sometimes uses `//` and sometimes uses `/*` comments for these messages so this change makes them all use `/*`. Technically I think fields can be omitted if they are public but `doc(hidden)` too but `doc(hidden)` is analogous to privacy. It's really just used to emulate ""doc privacy"" when -- because of technical limitations -- an item has to be public. So I think it's fine to include this under the category of ""private fields"". r? ```@jsha```",THUMBS_UP,2022-01-14T12:14:40Z,faptc,NA https://github.com/rust-lang/rust/pull/92706,MERGED,2022-01-09T23:05:31Z,2022-01-16T20:27:50Z,Clarify explicitly that BTree{Map Set} are ordered.,brennanvincent,039d6dc2896366b45cb71cef61dcbbd6cfc518a4,3,Rollup merge of #92706 - umanwizard:btree r=dtolnay Clarify explicitly that BTree{Map Set} are ordered. One of the main reasons one would want to use a BTree{Map Set} rather than a Hash{Map Set} is because they maintain their keys in sorted order; but this was never explicitly stated in the top-level docs (it was only indirectly alluded to there and stated explicitly in the docs for `iter` `values` etc.) This PR states the ordering guarantee more prominently.,THUMBS_UP,2022-01-10T08:54:55Z,marmeladema,NA https://github.com/rust-lang/rust/pull/92714,MERGED,2022-01-10T07:42:30Z,2022-02-25T11:00:38Z,Provide ignore message in the result of test,yanganto,6ec5b056b07359a110513b5c057b9db77ec5b20b,7,Rollup merge of #92714 - yanganto:ignore-message r=Mark-Simulacrum Provide ignore message in the result of test Provide ignore the message in the result of the test. This PR does not need RFC because it is about the presentation of the report of `cargo test`. However the following document listed here helps you to know about PR. - [RFC](https://github.com/rust-lang/rfcs/pull/3217) - [Rendered](https://github.com/yanganto/rfcs/blob/ignore-test-message/text/0000-ignore-test-message.md) - [Previous discussion on IRLO](https://internals.rust-lang.org/t/pre-rfc-provide-ignore-message-when-the-test-ignored/15904) If there is something improper please let me know. Thanks.,HOORAY,2022-02-01T15:19:12Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/92715,MERGED,2022-01-10T07:50:42Z,2022-02-09T04:05:58Z,Do not suggest char literal for zero-length strings,chordtoll,8429dcdb79b35182036e8de574287a7acc4b14d8,3,Rollup merge of #92715 - chordtoll:empty-string r=davidtwco Do not suggest char literal for zero-length strings PR #92507 adds a hint to switch to single quotes when a char is expected and a single-character string literal is provided. The check to ensure the string literal is one character long missed the 0-char case and would incorrectly offer the hint. This PR adds the missing check and a test case to confirm the new behavior.,HEART,2022-01-10T11:50:27Z,fmease,NA https://github.com/rust-lang/rust/pull/92715,MERGED,2022-01-10T07:50:42Z,2022-02-09T04:05:58Z,Do not suggest char literal for zero-length strings,chordtoll,8429dcdb79b35182036e8de574287a7acc4b14d8,3,Rollup merge of #92715 - chordtoll:empty-string r=davidtwco Do not suggest char literal for zero-length strings PR #92507 adds a hint to switch to single quotes when a char is expected and a single-character string literal is provided. The check to ensure the string literal is one character long missed the 0-char case and would incorrectly offer the hint. This PR adds the missing check and a test case to confirm the new behavior.,HEART,2022-02-17T03:20:14Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/92740,MERGED,2022-01-10T19:50:21Z,2022-01-16T11:19:20Z,Update rayon and rustc-rayon,cuviper,42852d7857d2955f19ec333bec1ed107964db200,10,"Auto merge of #92740 - cuviper:update-rayons r=Mark-Simulacrum Update rayon and rustc-rayon This updates rayon for various tools and rustc-rayon for the compiler's parallel mode. - rayon v1.3.1 -> v1.5.1 - rayon-core v1.7.1 -> v1.9.1 - rustc-rayon v0.3.1 -> v0.3.2 - rustc-rayon-core v0.3.1 -> v0.3.2 ... and indirectly this updates all of crossbeam-* to their latest versions. Fixes #92677 by removing crossbeam-queue but there's still a lingering question about how tidy discovers ""runtime"" dependencies. None of this is truly in the standard library's dependency tree at all.",HEART,2022-01-10T20:57:19Z,pierwill,NA https://github.com/rust-lang/rust/pull/92740,MERGED,2022-01-10T19:50:21Z,2022-01-16T11:19:20Z,Update rayon and rustc-rayon,cuviper,42852d7857d2955f19ec333bec1ed107964db200,10,"Auto merge of #92740 - cuviper:update-rayons r=Mark-Simulacrum Update rayon and rustc-rayon This updates rayon for various tools and rustc-rayon for the compiler's parallel mode. - rayon v1.3.1 -> v1.5.1 - rayon-core v1.7.1 -> v1.9.1 - rustc-rayon v0.3.1 -> v0.3.2 - rustc-rayon-core v0.3.1 -> v0.3.2 ... and indirectly this updates all of crossbeam-* to their latest versions. Fixes #92677 by removing crossbeam-queue but there's still a lingering question about how tidy discovers ""runtime"" dependencies. None of this is truly in the standard library's dependency tree at all.",HEART,2022-01-11T01:22:13Z,mati865,NA https://github.com/rust-lang/rust/pull/92740,MERGED,2022-01-10T19:50:21Z,2022-01-16T11:19:20Z,Update rayon and rustc-rayon,cuviper,42852d7857d2955f19ec333bec1ed107964db200,10,"Auto merge of #92740 - cuviper:update-rayons r=Mark-Simulacrum Update rayon and rustc-rayon This updates rayon for various tools and rustc-rayon for the compiler's parallel mode. - rayon v1.3.1 -> v1.5.1 - rayon-core v1.7.1 -> v1.9.1 - rustc-rayon v0.3.1 -> v0.3.2 - rustc-rayon-core v0.3.1 -> v0.3.2 ... and indirectly this updates all of crossbeam-* to their latest versions. Fixes #92677 by removing crossbeam-queue but there's still a lingering question about how tidy discovers ""runtime"" dependencies. None of this is truly in the standard library's dependency tree at all.",THUMBS_UP,2022-01-11T02:28:18Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92740,MERGED,2022-01-10T19:50:21Z,2022-01-16T11:19:20Z,Update rayon and rustc-rayon,cuviper,42852d7857d2955f19ec333bec1ed107964db200,10,"Auto merge of #92740 - cuviper:update-rayons r=Mark-Simulacrum Update rayon and rustc-rayon This updates rayon for various tools and rustc-rayon for the compiler's parallel mode. - rayon v1.3.1 -> v1.5.1 - rayon-core v1.7.1 -> v1.9.1 - rustc-rayon v0.3.1 -> v0.3.2 - rustc-rayon-core v0.3.1 -> v0.3.2 ... and indirectly this updates all of crossbeam-* to their latest versions. Fixes #92677 by removing crossbeam-queue but there's still a lingering question about how tidy discovers ""runtime"" dependencies. None of this is truly in the standard library's dependency tree at all.",HEART,2022-01-11T02:28:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92740,MERGED,2022-01-10T19:50:21Z,2022-01-16T11:19:20Z,Update rayon and rustc-rayon,cuviper,42852d7857d2955f19ec333bec1ed107964db200,10,"Auto merge of #92740 - cuviper:update-rayons r=Mark-Simulacrum Update rayon and rustc-rayon This updates rayon for various tools and rustc-rayon for the compiler's parallel mode. - rayon v1.3.1 -> v1.5.1 - rayon-core v1.7.1 -> v1.9.1 - rustc-rayon v0.3.1 -> v0.3.2 - rustc-rayon-core v0.3.1 -> v0.3.2 ... and indirectly this updates all of crossbeam-* to their latest versions. Fixes #92677 by removing crossbeam-queue but there's still a lingering question about how tidy discovers ""runtime"" dependencies. None of this is truly in the standard library's dependency tree at all.",HEART,2022-01-16T11:44:06Z,taiki-e,NA https://github.com/rust-lang/rust/pull/92746,MERGED,2022-01-10T22:04:52Z,2022-01-16T20:27:50Z,Parse `Ty?` as `Option` and provide structured suggestion,estebank,9323a0d1bef9b0708e25f0a8abaf5e5f88599f8d,12,Rollup merge of #92746 - estebank:question-mark-in-type r=davidtwco Parse `Ty?` as `Option` and provide structured suggestion Swift has specific syntax that desugars to `Option` similar to our `?` operator which means that people might try to use it in Rust. Parse it and gracefully recover.,HEART,2022-01-16T06:44:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/92752,MERGED,2022-01-11T02:47:08Z,2022-01-18T02:32:40Z,Correct minor typos in some long error code explanations,jamestiotio,4de63e7c23320f49114da8b39f675d995b480750,4,Rollup merge of #92752 - jamestiotio:error-codes-typos r=nagisa Correct minor typos in some long error code explanations Just a little nitpick to improve the long explanations of the error codes. 😊,THUMBS_UP,2022-01-11T02:48:34Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92754,MERGED,2022-01-11T03:43:28Z,2022-01-12T21:04:50Z,Update AsmArgs field visibility for rustfmt,ytmimi,a4b808d385c8d712add2a9a532065c62344532a6,1,Rollup merge of #92754 - ytmimi:AsmArgs-field-visibility r=calebcartwright Update AsmArgs field visibility for rustfmt To more easily allow rustfmt to format the ``asm!`` macro as specified in rust-dev-tools/fmt-rfcs#152 certain fields are made public. r? ```@calebcartwright```,THUMBS_UP,2022-01-11T03:47:22Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/92764,MERGED,2022-01-11T12:59:33Z,2022-01-12T21:04:50Z,Fix rust logo style,GuillaumeGomez,05dd1e4a2b6561b6daac38395883be6c782c2de1,4,Rollup merge of #92764 - GuillaumeGomez:fix-rust-logo-style r=jsha Fix rust logo style The style on the rust logo is currently broken: ![Screenshot from 2022-01-11 13-36-30](https://user-images.githubusercontent.com/3050060/148946754-a1a57253-bed0-44cf-a41c-83e0eecbd6b5.png) With this fix we're back to normal: ![Screenshot from 2022-01-11 13-42-07](https://user-images.githubusercontent.com/3050060/148946778-99f44678-aac1-419f-bb8c-ffa837e0c1ee.png) I also used a GUI test to prevent future silent regressions. r? ```@jsha```,HEART,2022-01-11T20:06:28Z,camelid,NA https://github.com/rust-lang/rust/pull/92767,MERGED,2022-01-11T15:47:54Z,2022-01-15T13:56:44Z,Use the new language identifier for Rust in the PDB debug format,arlosi,ff1db43b5041c91cdb781f4e93c64c46c9d46451,1,Rollup merge of #92767 - arlosi:pdbenum r=cuviper Use the new language identifier for Rust in the PDB debug format Rust currently identifies as MASM (Microsoft Assembler) in the PDB debug info format on Windows because no identifier was available. This change pulls in a cherry-pick to Rust's LLVM that includes the change to use the new identifier for Rust. https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang,HOORAY,2022-02-07T21:18:25Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/92768,MERGED,2022-01-11T16:08:19Z,2022-01-14T20:34:25Z,Partially stabilize `maybe_uninit_extra`,ojeda,558da934c1f4133628bccecf9e6c625c360c51f3,4,Rollup merge of #92768 - ojeda:stabilize-maybe_uninit_extra r=Mark-Simulacrum Partially stabilize `maybe_uninit_extra` This covers: ```rust impl MaybeUninit { pub unsafe fn assume_init_read(&self) -> T { ... } pub unsafe fn assume_init_drop(&mut self) { ... } } ``` It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that). FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287. Signed-off-by: Miguel Ojeda ,HEART,2022-01-11T16:13:04Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/92778,MERGED,2022-01-11T19:16:13Z,2022-01-27T01:53:35Z,fs: Use readdir() instead of readdir_r() on Linux and Android,tavianator,253f64c9c692549f73b902b494c573d6a411e0f5,2,Rollup merge of #92778 - tavianator:linux-readdir-no-r r=joshtriplett fs: Use readdir() instead of readdir_r() on Linux and Android See #40021 for more details. Fixes #86649. Fixes #34668.,HEART,2022-01-27T02:00:59Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/92787,MERGED,2022-01-11T21:22:24Z,2022-01-21T17:43:41Z,Remove a `Span` from `hir::ExprKind::MethodCall`,camsteffen,4d8b66aefdc97b91a9b7a4d8dc69beaff1ed2c1d,112,Auto merge of #92787 - camsteffen:methodcall-span r=Mark-Simulacrum Remove a `Span` from `hir::ExprKind::MethodCall` It's just a copy of `MethodCall.0.ident.span`.,THUMBS_UP,2022-01-11T21:50:54Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/92793,OPEN,2022-01-11T22:39:46Z,NA,Deduplicate bounds on associated types when deriving,ecstatic-morse,NA,NA,NA,THUMBS_UP,2022-01-21T09:59:20Z,lqd,NA https://github.com/rust-lang/rust/pull/92795,MERGED,2022-01-11T22:58:49Z,2022-01-17T09:00:48Z,"Link sidebar ""location"" heading to top of page",jsha,869b7bc5e7534acc2a38d0f389e1ef0ef2bb44e6,2,"Rollup merge of #92795 - jsha:link-to-top r=GuillaumeGomez Link sidebar ""location"" heading to top of page This makes it easy when you are scrolled far down in a page to jump back to the top. Demo: https://rustdoc.crud.net/jsha/link-to-top/std/string/struct.String.html r? ``@GuillaumeGomez``",HEART,2022-01-12T10:22:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92797,MERGED,2022-01-11T23:35:03Z,2022-01-19T18:18:22Z,Remove horizontal lines at top of page,jsha,7f2dbcba38c4bcd7f8397b056f2d8ea76447629e,6,Rollup merge of #92797 - jsha:fewer-lines r=GuillaumeGomez Remove horizontal lines at top of page They are not needed to separate the search bar and the title which are visually distinct on their own. Part of #59840 Demo: https://rustdoc.crud.net/jsha/fewer-lines/std/string/struct.String.html r? `@GuillaumeGomez`,HEART,2022-01-12T02:55:05Z,camelid,NA https://github.com/rust-lang/rust/pull/92800,MERGED,2022-01-12T01:03:03Z,2022-01-20T02:14:50Z,Add manifest docs fallback.,ehuss,bcb093efcda31874d73184a15fc04d427b844c50,6,Rollup merge of #92800 - ehuss:docs-fallback r=Mark-Simulacrum Add manifest docs fallback. This adds a fallback so that the rustup manifest will contain the rust-docs component for all hosts. There is a mapping so that the docs that get downloaded are roughly close to the actual host. There inevitably will be things that don't match. Ideally the standard library docs would be the same for every platform (`cfg(doc)` goes a long way towards this) but there are still lots of minor differences. Closes #69525,HEART,2022-01-12T02:22:08Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/92808,MERGED,2022-01-12T04:28:01Z,2022-01-17T09:00:48Z,Fix `try wrapping expression in variant` suggestion with struct field shorthand,compiler-errors,ff1b653cdb1f176bf995b58cec3c7e74965cdac5,5,Rollup merge of #92808 - compiler-errors:wrap-struct-shorthand-field-in-variant r=davidtwco Fix `try wrapping expression in variant` suggestion with struct field shorthand Fixes a broken suggestion: [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=83fe2dbfe1485f8cfca1aef2a6582e77) before: ``` error[E0308]: mismatched types --> src/main.rs:7:19 | 7 | let x = Foo { bar }; | ^^^ expected enum `Option` found integer | = note: expected enum `Option` found type `{integer}` help: try wrapping the expression in `Some` | 7 | let x = Foo { Some(bar) }; | +++++ + ``` after: ``` error[E0308]: mismatched types --> src/main.rs:7:19 | 7 | let x = Foo { bar }; | ^^^ expected enum `Option` found integer | = note: expected enum `Option` found type `{integer}` help: try wrapping the expression in `Some` | 7 | let x = Foo { bar: Some(bar) }; | ~~~~~~~~~~~~~~ ``` r? ``@m-ou-se`` since you touched the code last in #91080,HEART,2022-01-13T00:02:56Z,camelid,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-12T18:40:58Z,marmeladema,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-12T20:42:42Z,oli-obk,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-12T22:03:58Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T00:01:02Z,camelid,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T00:01:18Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T00:22:43Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T06:02:32Z,taiki-e,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T12:54:29Z,harrysarson,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T17:05:39Z,mati865,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-13T17:42:45Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-15T15:37:05Z,nikic,nikic@php.net https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-17T17:14:15Z,bjorn3,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-17T18:27:20Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-20T05:48:11Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HEART,2022-01-20T13:47:28Z,berkus,NA https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-20T18:48:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92816,MERGED,2022-01-12T16:49:51Z,2022-01-17T13:19:40Z,Remove deprecated LLVM-style inline assembly,tmiasko,a34c0797528172ede89480e3033f7a5e71ea4735,171,Auto merge of #92816 - tmiasko:rm-llvm-asm r=Amanieu Remove deprecated LLVM-style inline assembly The `llvm_asm!` was deprecated back in #87590 1.56.0 with intention to remove it once `asm!` was stabilized which already happened in #91728 1.59.0. Now it is time to remove `llvm_asm!` to avoid continued maintenance cost. Closes #70173. Closes #92794. Closes #87612. Closes #82065. cc `@rust-lang/wg-inline-asm` r? `@Amanieu`,HOORAY,2022-01-21T02:08:42Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/92843,MERGED,2022-01-13T06:29:24Z,2022-01-22T02:54:32Z,Improve string concatenation suggestion,camelid,430673f26590f5f40bb6a6587d43136d0b5604dc,6,"Rollup merge of #92843 - camelid:str-concat-sugg r=davidtwco Improve string concatenation suggestion Before: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | 2 | let _x = ""hello"".to_owned() + "" world""; | ~~~~~~~~~~~~~~~~~~ After: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | = note: string concatenation requires an owned `String` on the left help: create an owned `String` from a string reference | 2 | let _x = ""hello"".to_owned() + "" world""; | +++++++++++",THUMBS_UP,2022-01-13T08:58:42Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92843,MERGED,2022-01-13T06:29:24Z,2022-01-22T02:54:32Z,Improve string concatenation suggestion,camelid,430673f26590f5f40bb6a6587d43136d0b5604dc,6,"Rollup merge of #92843 - camelid:str-concat-sugg r=davidtwco Improve string concatenation suggestion Before: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | 2 | let _x = ""hello"".to_owned() + "" world""; | ~~~~~~~~~~~~~~~~~~ After: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | = note: string concatenation requires an owned `String` on the left help: create an owned `String` from a string reference | 2 | let _x = ""hello"".to_owned() + "" world""; | +++++++++++",THUMBS_UP,2022-01-13T10:35:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/92843,MERGED,2022-01-13T06:29:24Z,2022-01-22T02:54:32Z,Improve string concatenation suggestion,camelid,430673f26590f5f40bb6a6587d43136d0b5604dc,6,"Rollup merge of #92843 - camelid:str-concat-sugg r=davidtwco Improve string concatenation suggestion Before: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | 2 | let _x = ""hello"".to_owned() + "" world""; | ~~~~~~~~~~~~~~~~~~ After: error[E0369]: cannot add `&str` to `&str` --> file.rs:2:22 | 2 | let _x = ""hello"" + "" world""; | ------- ^ -------- &str | | | | | `+` cannot be used to concatenate two `&str` strings | &str | = note: string concatenation requires an owned `String` on the left help: create an owned `String` from a string reference | 2 | let _x = ""hello"".to_owned() + "" world""; | +++++++++++",THUMBS_UP,2022-01-28T03:50:56Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/92849,MERGED,2022-01-13T12:22:35Z,2022-01-14T20:34:25Z,Clippyup,flip1995,ccfee3d53b0d7b4855ad17702ca309ccf5eff3ac,224,Rollup merge of #92849 - flip1995:clippyup r=Manishearth Clippyup r? ```@Manishearth```,HEART,2022-01-13T12:29:15Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/92849,MERGED,2022-01-13T12:22:35Z,2022-01-14T20:34:25Z,Clippyup,flip1995,ccfee3d53b0d7b4855ad17702ca309ccf5eff3ac,224,Rollup merge of #92849 - flip1995:clippyup r=Manishearth Clippyup r? ```@Manishearth```,HEART,2022-01-13T12:56:56Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/92854,MERGED,2022-01-13T14:01:52Z,2022-01-14T20:34:25Z,Use the updated Rust logo in rustdoc,Urgau,dae3ef2eb2c49542d7eb802db17f3863f87202b1,7,Rollup merge of #92854 - Urgau:better-rust-logo r=GuillaumeGomez Use the updated Rust logo in rustdoc This pull-request use the updated Rust logo from https://github.com/rust-lang/rust-artwork/pull/9 and also change the logo format from PNG to SVG. | Before | After | | --- | --- | | ![Screenshot 2022-01-13 at 14-33-40 std - Rust](https://user-images.githubusercontent.com/3616612/149342697-7afe4c3e-2be5-444b-86f3-118712b4f7ae.png) | ![Screenshot 2022-01-13 at 14-33-15 std - Rust](https://user-images.githubusercontent.com/3616612/149342705-54ed27c6-0806-4c2d-baa1-4d65ed897e2b.png) | I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each. Fixes https://github.com/rust-lang/rust/issues/92831 r? ```@jsha```,THUMBS_UP,2022-01-13T16:10:08Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/92854,MERGED,2022-01-13T14:01:52Z,2022-01-14T20:34:25Z,Use the updated Rust logo in rustdoc,Urgau,dae3ef2eb2c49542d7eb802db17f3863f87202b1,7,Rollup merge of #92854 - Urgau:better-rust-logo r=GuillaumeGomez Use the updated Rust logo in rustdoc This pull-request use the updated Rust logo from https://github.com/rust-lang/rust-artwork/pull/9 and also change the logo format from PNG to SVG. | Before | After | | --- | --- | | ![Screenshot 2022-01-13 at 14-33-40 std - Rust](https://user-images.githubusercontent.com/3616612/149342697-7afe4c3e-2be5-444b-86f3-118712b4f7ae.png) | ![Screenshot 2022-01-13 at 14-33-15 std - Rust](https://user-images.githubusercontent.com/3616612/149342705-54ed27c6-0806-4c2d-baa1-4d65ed897e2b.png) | I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each. Fixes https://github.com/rust-lang/rust/issues/92831 r? ```@jsha```,HEART,2022-01-13T16:10:12Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/92854,MERGED,2022-01-13T14:01:52Z,2022-01-14T20:34:25Z,Use the updated Rust logo in rustdoc,Urgau,dae3ef2eb2c49542d7eb802db17f3863f87202b1,7,Rollup merge of #92854 - Urgau:better-rust-logo r=GuillaumeGomez Use the updated Rust logo in rustdoc This pull-request use the updated Rust logo from https://github.com/rust-lang/rust-artwork/pull/9 and also change the logo format from PNG to SVG. | Before | After | | --- | --- | | ![Screenshot 2022-01-13 at 14-33-40 std - Rust](https://user-images.githubusercontent.com/3616612/149342697-7afe4c3e-2be5-444b-86f3-118712b4f7ae.png) | ![Screenshot 2022-01-13 at 14-33-15 std - Rust](https://user-images.githubusercontent.com/3616612/149342705-54ed27c6-0806-4c2d-baa1-4d65ed897e2b.png) | I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each. Fixes https://github.com/rust-lang/rust/issues/92831 r? ```@jsha```,HEART,2022-01-13T21:11:21Z,pierwill,NA https://github.com/rust-lang/rust/pull/92854,MERGED,2022-01-13T14:01:52Z,2022-01-14T20:34:25Z,Use the updated Rust logo in rustdoc,Urgau,dae3ef2eb2c49542d7eb802db17f3863f87202b1,7,Rollup merge of #92854 - Urgau:better-rust-logo r=GuillaumeGomez Use the updated Rust logo in rustdoc This pull-request use the updated Rust logo from https://github.com/rust-lang/rust-artwork/pull/9 and also change the logo format from PNG to SVG. | Before | After | | --- | --- | | ![Screenshot 2022-01-13 at 14-33-40 std - Rust](https://user-images.githubusercontent.com/3616612/149342697-7afe4c3e-2be5-444b-86f3-118712b4f7ae.png) | ![Screenshot 2022-01-13 at 14-33-15 std - Rust](https://user-images.githubusercontent.com/3616612/149342705-54ed27c6-0806-4c2d-baa1-4d65ed897e2b.png) | I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each. Fixes https://github.com/rust-lang/rust/issues/92831 r? ```@jsha```,THUMBS_UP,2022-01-13T21:11:22Z,pierwill,NA https://github.com/rust-lang/rust/pull/92860,MERGED,2022-01-13T17:46:59Z,2022-01-21T06:20:20Z,Fix errors on blanket impls by ignoring the children of generated impls,CraftSpider,530c884372cbee0ab81df404c90b0bc3b551a474,2,Rollup merge of #92860 - CraftSpider:rustdoc-json-impl-ice r=jsha Fix errors on blanket impls by ignoring the children of generated impls Related to #83718 We can safely skip the children as they don't contain any new info and may be subtly different for reasons hard to track down in ways that are consistently worse than the actual generic impl.,THUMBS_UP,2022-01-13T17:57:38Z,Urgau,NA https://github.com/rust-lang/rust/pull/92860,MERGED,2022-01-13T17:46:59Z,2022-01-21T06:20:20Z,Fix errors on blanket impls by ignoring the children of generated impls,CraftSpider,530c884372cbee0ab81df404c90b0bc3b551a474,2,Rollup merge of #92860 - CraftSpider:rustdoc-json-impl-ice r=jsha Fix errors on blanket impls by ignoring the children of generated impls Related to #83718 We can safely skip the children as they don't contain any new info and may be subtly different for reasons hard to track down in ways that are consistently worse than the actual generic impl.,ROCKET,2022-01-14T10:54:20Z,scrabsha,NA https://github.com/rust-lang/rust/pull/92873,MERGED,2022-01-13T23:34:21Z,2022-01-15T13:56:43Z,Generate more precise generator names,eholk,85c119cd519150133279d9f3ae8e964d42a93e6e,3,Rollup merge of #92873 - eholk:async-symbol-names r=tmandry Generate more precise generator names Currently all generators are named with a `generator$N` suffix regardless of where they come from. This means an `async fn` shows up as a generator in stack traces which can be surprising to async programmers since they should not need to know that async functions are implementated using generators. This change generators a different name depending on the generator kind allowing us to tell whether the generator is the result of an async block an async closure an async fn or a plain generator. r? `@tmandry` cc `@michaelwoerister` `@wesleywiser` `@dpaoliello`,THUMBS_UP,2022-01-14T16:39:12Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/92875,MERGED,2022-01-14T00:21:48Z,2022-01-15T07:27:36Z,Make `opt_const_param_of` work in the presence of `GenericArg::Infer`,BoxyUwU,6c94f99d83fcb0e6c7e152a5cb8d9e3da9b73ce2,6,Rollup merge of #92875 - BoxyUwU:infer_arg_opt_const_param_of r=lcnr Make `opt_const_param_of` work in the presence of `GenericArg::Infer` highly recommend viewing the first and second commits on their own rather than looking at file changes :rofl: Because we filtered args down to just const args we would ignore `GenericArg::Infer` which made us get a `arg_index` which was wrong by however many const `GenericArg::Infer` came previously [example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=46dba6a53aca6333028a10908ef16e0b) of the [bugs](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a8eebced26eefa4119fc2e7ae0c76de6) fixed. r? ```@lcnr```,HOORAY,2022-01-14T18:59:58Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/92879,MERGED,2022-01-14T04:58:55Z,2022-01-15T13:56:43Z,Add Sync bound to allocator parameter in vec::IntoIter,compiler-errors,784e4ba9a4bcbda44021c6ca8345819c91b45066,1,Rollup merge of #92879 - compiler-errors:into_iter_unsound r=dtolnay Add Sync bound to allocator parameter in vec::IntoIter The `A: Sync` bound was forgotten in https://github.com/rust-lang/rust/commit/8725e4c33749b23f260b2fc46e090c3792b6f97e#diff-b78c3ab6d37f4ede32195707528f8a76c49d4557cc9d3a7a09417b5157729b9fR3132 Similar `unsafe impl Sync` in that commit _do_ include the `A: Sync` bound (and around the alloc lib) so I think this was just an honest mistake. Here's an example of the unsoundness: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=16cbfeff7c934ae72ab632c1476fdd8b `@steffahn` found this I'm just putting up the fix cause nobody else did :^) Fixes #92633,HEART,2022-01-14T06:01:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/92884,MERGED,2022-01-14T07:04:25Z,2022-02-26T07:00:36Z,Suggest adding `{ .. }` around more bad const generic exprs,compiler-errors,7c3331ccf925200b8fb7127db8bae8802edf1b61,4,Auto merge of #92884 - compiler-errors:const-generic-expr-recovery r=jackh726 Suggest adding `{ .. }` around more bad const generic exprs Fixes #92776,HEART,2022-03-03T19:28:35Z,estebank,NA https://github.com/rust-lang/rust/pull/92889,MERGED,2022-01-14T09:44:57Z,2022-01-27T09:32:37Z,Ignore unwinding edges when checking for unconditional recursion,tmiasko,21b4a9cfdcbb1e76f4b36b5c3cfd64d627285093,5,Auto merge of #92889 - tmiasko:unbounded-recursion r=ecstatic-morse Ignore unwinding edges when checking for unconditional recursion The unconditional recursion lint determines if all execution paths eventually lead to a self-recursive call. The implementation always follows unwinding edges which limits its practical utility. For example it would not lint function `f` because a call to `g` might unwind. It also wouldn't lint function `h` because an overflow check preceding the self-recursive call might unwind: ```rust pub fn f() { g(); f(); } pub fn g() { /* ... */ } pub fn h(a: usize) { h(a + 1); } ``` To avoid the issue assume that terminators that might continue execution along non-unwinding edges do so. Fixes #78474.,THUMBS_UP,2022-01-14T22:25:20Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92889,MERGED,2022-01-14T09:44:57Z,2022-01-27T09:32:37Z,Ignore unwinding edges when checking for unconditional recursion,tmiasko,21b4a9cfdcbb1e76f4b36b5c3cfd64d627285093,5,Auto merge of #92889 - tmiasko:unbounded-recursion r=ecstatic-morse Ignore unwinding edges when checking for unconditional recursion The unconditional recursion lint determines if all execution paths eventually lead to a self-recursive call. The implementation always follows unwinding edges which limits its practical utility. For example it would not lint function `f` because a call to `g` might unwind. It also wouldn't lint function `h` because an overflow check preceding the self-recursive call might unwind: ```rust pub fn f() { g(); f(); } pub fn g() { /* ... */ } pub fn h(a: usize) { h(a + 1); } ``` To avoid the issue assume that terminators that might continue execution along non-unwinding edges do so. Fixes #78474.,THUMBS_UP,2022-01-17T17:18:19Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/92892,MERGED,2022-01-14T11:44:11Z,2022-01-15T13:56:43Z,Do not fail evaluation in const blocks,compiler-errors,539175c026c70e32150ca8c5ed2e0bacd3bb12e6,3,Rollup merge of #92892 - compiler-errors:const-param-env-for-const-block r=fee1-dead Do not fail evaluation in const blocks Evaluate const blocks with a const param-env so we properly check `~const` trait bounds. Fixes #92713 (I will fix the poor diagnostics in #92713 and #92712 in a separate PR) cc `@nbdd0121` who wrote the code this PR touches in #89561,THUMBS_UP,2022-01-14T17:48:09Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/92892,MERGED,2022-01-14T11:44:11Z,2022-01-15T13:56:43Z,Do not fail evaluation in const blocks,compiler-errors,539175c026c70e32150ca8c5ed2e0bacd3bb12e6,3,Rollup merge of #92892 - compiler-errors:const-param-env-for-const-block r=fee1-dead Do not fail evaluation in const blocks Evaluate const blocks with a const param-env so we properly check `~const` trait bounds. Fixes #92713 (I will fix the poor diagnostics in #92713 and #92712 in a separate PR) cc `@nbdd0121` who wrote the code this PR touches in #89561,HEART,2022-01-18T10:04:41Z,woppopo,NA https://github.com/rust-lang/rust/pull/92896,MERGED,2022-01-14T14:35:51Z,2022-01-21T13:27:11Z,Update some rustc dependencies to deduplicate them,lqd,84e918971d643c6a33067d5125214ab800ce5307,6,Auto merge of #92896 - lqd:update-deps r=Mark-Simulacrum Update some rustc dependencies to deduplicate them This PR updates `rand` and `itertools` in rustc (not the whole workspace) in order to deduplicate them (and hopefully slightly improve compile times). ~~Currently `object` is still duplicated but https://github.com/rust-lang/thorin/pull/15 and updating `thorin` in the future will remove the use of version 0.27.~~ Update: Thorin 0.2 has now been released and this PR updates `rustc_codegen_ssa` to use it and deduplicate the `object` crate. There's a final tiny rustc dependency `cfg-if` which will be left: as both versions 0.1.x and 1.0 looked to be heavily depended on they will require a few cascading updates to be removed.,HEART,2022-01-15T21:09:45Z,mati865,NA https://github.com/rust-lang/rust/pull/92899,MERGED,2022-01-14T17:43:12Z,2022-01-28T01:33:06Z,Mention std::iter::zip in Iterator::zip docs,cameron1024,54f357836ec5786fa7f6f08626ee5b692ccb2757,1,Rollup merge of #92899 - cameron1024:zip-docs r=dtolnay Mention std::iter::zip in Iterator::zip docs Closes https://github.com/rust-lang/rust/issues/91960 I'm not sure about the wording. I think it's alright but happy to change.,THUMBS_UP,2022-01-14T17:53:18Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92899,MERGED,2022-01-14T17:43:12Z,2022-01-28T01:33:06Z,Mention std::iter::zip in Iterator::zip docs,cameron1024,54f357836ec5786fa7f6f08626ee5b692ccb2757,1,Rollup merge of #92899 - cameron1024:zip-docs r=dtolnay Mention std::iter::zip in Iterator::zip docs Closes https://github.com/rust-lang/rust/issues/91960 I'm not sure about the wording. I think it's alright but happy to change.,HEART,2022-01-16T01:31:41Z,scottmcm,NA https://github.com/rust-lang/rust/pull/92908,MERGED,2022-01-14T21:16:59Z,2022-01-30T20:57:37Z,Render more readable macro matcher tokens in rustdoc,dtolnay,ba013373d8aad473d2b6c6c90bb876cd45f53164,7,Rollup merge of #92908 - dtolnay:rustdoc r=GuillaumeGomez Render more readable macro matcher tokens in rustdoc Follow-up to #92334. This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space. The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice: - In the **before** notice how a couple places break in between `$(....)`↵`*` which is just about the worst possible place that it could break. - In the **before** the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after** we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0 because the matcher itself is indented by 4 relative to the `macro_rules` header). - In the **after** macro_rules metavariables like `$tokens:tt` are kept together which is how just about everybody writing Rust today writes them. ## Before ![Screenshot from 2022-01-14 13-05-53](https://user-images.githubusercontent.com/1940490/149585105-1f182b78-751f-421f-a234-9dbc04fa3bbd.png) ## After ![Screenshot from 2022-01-14 13-06-04](https://user-images.githubusercontent.com/1940490/149585118-d4b52ea7-3e67-4b6e-a12b-31dfb8172f86.png) r? `@camelid`,HEART,2022-01-14T21:58:19Z,fmease,NA https://github.com/rust-lang/rust/pull/92908,MERGED,2022-01-14T21:16:59Z,2022-01-30T20:57:37Z,Render more readable macro matcher tokens in rustdoc,dtolnay,ba013373d8aad473d2b6c6c90bb876cd45f53164,7,Rollup merge of #92908 - dtolnay:rustdoc r=GuillaumeGomez Render more readable macro matcher tokens in rustdoc Follow-up to #92334. This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space. The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice: - In the **before** notice how a couple places break in between `$(....)`↵`*` which is just about the worst possible place that it could break. - In the **before** the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after** we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0 because the matcher itself is indented by 4 relative to the `macro_rules` header). - In the **after** macro_rules metavariables like `$tokens:tt` are kept together which is how just about everybody writing Rust today writes them. ## Before ![Screenshot from 2022-01-14 13-05-53](https://user-images.githubusercontent.com/1940490/149585105-1f182b78-751f-421f-a234-9dbc04fa3bbd.png) ## After ![Screenshot from 2022-01-14 13-06-04](https://user-images.githubusercontent.com/1940490/149585118-d4b52ea7-3e67-4b6e-a12b-31dfb8172f86.png) r? `@camelid`,HEART,2022-01-14T22:12:15Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/92908,MERGED,2022-01-14T21:16:59Z,2022-01-30T20:57:37Z,Render more readable macro matcher tokens in rustdoc,dtolnay,ba013373d8aad473d2b6c6c90bb876cd45f53164,7,Rollup merge of #92908 - dtolnay:rustdoc r=GuillaumeGomez Render more readable macro matcher tokens in rustdoc Follow-up to #92334. This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space. The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice: - In the **before** notice how a couple places break in between `$(....)`↵`*` which is just about the worst possible place that it could break. - In the **before** the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after** we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0 because the matcher itself is indented by 4 relative to the `macro_rules` header). - In the **after** macro_rules metavariables like `$tokens:tt` are kept together which is how just about everybody writing Rust today writes them. ## Before ![Screenshot from 2022-01-14 13-05-53](https://user-images.githubusercontent.com/1940490/149585105-1f182b78-751f-421f-a234-9dbc04fa3bbd.png) ## After ![Screenshot from 2022-01-14 13-06-04](https://user-images.githubusercontent.com/1940490/149585118-d4b52ea7-3e67-4b6e-a12b-31dfb8172f86.png) r? `@camelid`,HEART,2022-01-15T15:07:07Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92908,MERGED,2022-01-14T21:16:59Z,2022-01-30T20:57:37Z,Render more readable macro matcher tokens in rustdoc,dtolnay,ba013373d8aad473d2b6c6c90bb876cd45f53164,7,Rollup merge of #92908 - dtolnay:rustdoc r=GuillaumeGomez Render more readable macro matcher tokens in rustdoc Follow-up to #92334. This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space. The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice: - In the **before** notice how a couple places break in between `$(....)`↵`*` which is just about the worst possible place that it could break. - In the **before** the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after** we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0 because the matcher itself is indented by 4 relative to the `macro_rules` header). - In the **after** macro_rules metavariables like `$tokens:tt` are kept together which is how just about everybody writing Rust today writes them. ## Before ![Screenshot from 2022-01-14 13-05-53](https://user-images.githubusercontent.com/1940490/149585105-1f182b78-751f-421f-a234-9dbc04fa3bbd.png) ## After ![Screenshot from 2022-01-14 13-06-04](https://user-images.githubusercontent.com/1940490/149585118-d4b52ea7-3e67-4b6e-a12b-31dfb8172f86.png) r? `@camelid`,HEART,2022-01-17T10:42:18Z,marmeladema,NA https://github.com/rust-lang/rust/pull/92921,MERGED,2022-01-15T05:19:10Z,2022-01-17T09:00:48Z,Rename Printer constructor from mk_printer() to Printer::new(),dtolnay,216ce7c519c172dbc6f36676c43590c7a79094f0,3,Rollup merge of #92921 - dtolnay:printernew r=wesleywiser Rename Printer constructor from mk_printer() to Printer::new() The original naming is left over from 2011 which was before impl blocks and associated functions existed. https://github.com/rust-lang/rust/blob/21313d623a505086b2973f30c19db4f1d6ec8f61/src/comp/pretty/pp.rs,LAUGH,2022-01-15T08:18:52Z,fmease,NA https://github.com/rust-lang/rust/pull/92921,MERGED,2022-01-15T05:19:10Z,2022-01-17T09:00:48Z,Rename Printer constructor from mk_printer() to Printer::new(),dtolnay,216ce7c519c172dbc6f36676c43590c7a79094f0,3,Rollup merge of #92921 - dtolnay:printernew r=wesleywiser Rename Printer constructor from mk_printer() to Printer::new() The original naming is left over from 2011 which was before impl blocks and associated functions existed. https://github.com/rust-lang/rust/blob/21313d623a505086b2973f30c19db4f1d6ec8f61/src/comp/pretty/pp.rs,LAUGH,2022-01-15T11:37:21Z,faptc,NA https://github.com/rust-lang/rust/pull/92935,MERGED,2022-01-15T16:34:08Z,2022-01-17T02:06:57Z,Update RLS and drop rustc-ap-packages,Xanewok,1fbd6aedb3474d2a5d70839a42c80d869749d8ff,3,Auto merge of #92935 - Xanewok:update-rls r=pietroalbini Update RLS and drop rustc-ap-packages Closes #91543 r? `@pietroalbini` cc `@calebcartwright` `@flip1995`,HEART,2022-01-15T16:37:14Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/92935,MERGED,2022-01-15T16:34:08Z,2022-01-17T02:06:57Z,Update RLS and drop rustc-ap-packages,Xanewok,1fbd6aedb3474d2a5d70839a42c80d869749d8ff,3,Auto merge of #92935 - Xanewok:update-rls r=pietroalbini Update RLS and drop rustc-ap-packages Closes #91543 r? `@pietroalbini` cc `@calebcartwright` `@flip1995`,HOORAY,2022-01-15T16:40:28Z,calebcartwright,NA https://github.com/rust-lang/rust/pull/92935,MERGED,2022-01-15T16:34:08Z,2022-01-17T02:06:57Z,Update RLS and drop rustc-ap-packages,Xanewok,1fbd6aedb3474d2a5d70839a42c80d869749d8ff,3,Auto merge of #92935 - Xanewok:update-rls r=pietroalbini Update RLS and drop rustc-ap-packages Closes #91543 r? `@pietroalbini` cc `@calebcartwright` `@flip1995`,HEART,2022-01-15T19:38:42Z,mati865,NA https://github.com/rust-lang/rust/pull/92935,MERGED,2022-01-15T16:34:08Z,2022-01-17T02:06:57Z,Update RLS and drop rustc-ap-packages,Xanewok,1fbd6aedb3474d2a5d70839a42c80d869749d8ff,3,Auto merge of #92935 - Xanewok:update-rls r=pietroalbini Update RLS and drop rustc-ap-packages Closes #91543 r? `@pietroalbini` cc `@calebcartwright` `@flip1995`,HOORAY,2022-01-15T19:38:43Z,mati865,NA https://github.com/rust-lang/rust/pull/92942,MERGED,2022-01-15T19:50:12Z,2022-04-04T22:32:46Z,stabilize windows_process_extensions_raw_arg,Xaeroxe,c56cbf976c861d28d145549d2aa5736a189a930c,1,Rollup merge of #92942 - Xaeroxe:raw_arg r=dtolnay stabilize windows_process_extensions_raw_arg Stabilizes the feature tracked at https://github.com/rust-lang/rust/issues/92939,THUMBS_UP,2022-03-06T15:48:09Z,rivy,NA https://github.com/rust-lang/rust/pull/92947,MERGED,2022-01-15T22:12:54Z,2022-01-18T09:58:52Z,rustdoc: Use `intersperse` in a `visit_path` function,vacuus,71e5bfed706616ed85efe57244db95cc358716ad,1,Rollup merge of #92947 - vacuus:rustdoc-core-visit-path r=camelid rustdoc: Use `intersperse` in a `visit_path` function (~~Is there a better way to word the title?~~ Eh this works I guess.) I'm surprised that the compiler didn't complain when I left out the `.to_string()` but hey if it works then it works.,THUMBS_UP,2022-01-15T22:22:32Z,mohe2015,NA https://github.com/rust-lang/rust/pull/92953,MERGED,2022-01-16T00:29:59Z,2022-01-17T09:00:47Z,Copy an example to PartialOrd as well,azdavis,775fe37ca9354371eb69c1dc7ee65d941dcafe15,1,Rollup merge of #92953 - azdavis:azdavis-copy-example r=dtolnay Copy an example to PartialOrd as well In https://github.com/rust-lang/rust/pull/88202 I added an example for deriving PartialOrd on enums but only later did I realize that I actually put the example on Ord. This copies the example to PartialOrd as well which is where I intended for it to be. We could also delete the example on Ord but I see there's already some highly similar examples shared between Ord and PartialOrd so I figured we could leave it. I also changed some type annotations in an example from `x : T` to the more common style (in Rust) of `x: T`.,THUMBS_UP,2022-01-16T14:32:00Z,fmease,NA https://github.com/rust-lang/rust/pull/92959,MERGED,2022-01-16T03:46:24Z,2022-02-18T21:58:28Z,Add more info and suggestions to use of #[test] on invalid items,asquared31415,659382fa47e9a7c29451ed407c4062f86dee07b1,7,Rollup merge of #92959 - asquared31415:test-non-fn-help r=estebank Add more info and suggestions to use of #[test] on invalid items This pr changes the diagnostics for using `#[test]` on an item that can't be used as a test to explain that the attribute has no meaningful effect on non-functions and suggests the use of `#[cfg(test)]` for conditional compilation instead. Example change: ```rs #[test] mod test {} ``` previously output ``` error: only functions may be used as tests --> src/lib.rs:2:1 | 2 | mod test {} | ^^^^^^^^^^^ ``` now outputs ``` error: the `#[test]` attribute may only be used on a non-associated function --> $DIR/test-on-not-fn.rs:3:1 | LL | #[test] | ^^^^^^^ LL | mod test {} | ----------- expected a non-associated function found a module | = note: the `#[test]` macro causes a a function to be run on a test and has no effect on non-functions help: replace with conditional compilation to make the item only exist when tests are being run | LL | #[cfg(test)] | ~~~~~~~~~~~~ ```,THUMBS_UP,2022-01-16T12:00:03Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/92962,MERGED,2022-01-16T08:22:06Z,2022-03-20T13:48:24Z,BTreeMap::entry: Avoid allocating if no insertion,frank-king,c7ce69faf2a7ea16c15d922985ca27ba70da30ee,4,Auto merge of #92962 - frank-king:btree_entry_no_insert r=Amanieu BTreeMap::entry: Avoid allocating if no insertion This PR allows the `VacantEntry` to borrow from an empty tree with no root and to lazily allocate a new root node when the user calls `.insert(value)`.,THUMBS_UP,2022-03-24T06:44:52Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/92962,MERGED,2022-01-16T08:22:06Z,2022-03-20T13:48:24Z,BTreeMap::entry: Avoid allocating if no insertion,frank-king,c7ce69faf2a7ea16c15d922985ca27ba70da30ee,4,Auto merge of #92962 - frank-king:btree_entry_no_insert r=Amanieu BTreeMap::entry: Avoid allocating if no insertion This PR allows the `VacantEntry` to borrow from an empty tree with no root and to lazily allocate a new root node when the user calls `.insert(value)`.,HOORAY,2022-03-24T10:07:35Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/92962,MERGED,2022-01-16T08:22:06Z,2022-03-20T13:48:24Z,BTreeMap::entry: Avoid allocating if no insertion,frank-king,c7ce69faf2a7ea16c15d922985ca27ba70da30ee,4,Auto merge of #92962 - frank-king:btree_entry_no_insert r=Amanieu BTreeMap::entry: Avoid allocating if no insertion This PR allows the `VacantEntry` to borrow from an empty tree with no root and to lazily allocate a new root node when the user calls `.insert(value)`.,HOORAY,2022-06-03T10:06:10Z,ssomers,git@steinsomers.be https://github.com/rust-lang/rust/pull/92964,OPEN,2022-01-16T10:44:02Z,NA,Implement Debug Pointer etc on function pointers for all calling conventions,Kampfkarren,NA,NA,NA,THUMBS_UP,2022-02-08T12:04:49Z,matthargett,plaztiksyke@gmail.com https://github.com/rust-lang/rust/pull/92964,OPEN,2022-01-16T10:44:02Z,NA,Implement Debug Pointer etc on function pointers for all calling conventions,Kampfkarren,NA,NA,NA,THUMBS_UP,2022-06-11T16:33:05Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/92972,CLOSED,2022-01-16T16:28:36Z,2022-04-08T16:21:44Z,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-01-16T16:48:58Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/92972,CLOSED,2022-01-16T16:28:36Z,2022-04-08T16:21:44Z,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-01-21T01:20:16Z,camelid,NA https://github.com/rust-lang/rust/pull/92972,CLOSED,2022-01-16T16:28:36Z,2022-04-08T16:21:44Z,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-01-21T07:47:48Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/92972,CLOSED,2022-01-16T16:28:36Z,2022-04-08T16:21:44Z,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-02-23T07:33:02Z,aceArt-GmbH,NA https://github.com/rust-lang/rust/pull/92972,CLOSED,2022-01-16T16:28:36Z,2022-04-08T16:21:44Z,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-02-27T20:18:28Z,mati865,NA https://github.com/rust-lang/rust/pull/92977,MERGED,2022-01-16T17:54:35Z,2022-01-17T09:00:47Z,Docs: recommend VecDeque instead of Vec::remove(0),kornelski,7bdd978c24f728261442dae3ee0104f5360544ec,1,Rollup merge of #92977 - kornelski:popdoc r=dtolnay Docs: recommend VecDeque instead of Vec::remove(0) Suggestion based on a [discussion](https://internals.rust-lang.org/t/should-vec-have-a-try-remove-mut-self-usize-option-t-function/15964/9?u=kornel) where user needlessly struggled with `remove(0)` and accidentally created a quadratic cost.,THUMBS_UP,2022-01-16T18:17:41Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92982,CLOSED,2022-01-16T19:51:01Z,2022-01-19T01:02:40Z,Add Iterator::collect_into and Iterator::collect_with,frengor,NA,NA,NA,HEART,2022-01-16T21:56:58Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/92982,CLOSED,2022-01-16T19:51:01Z,2022-01-19T01:02:40Z,Add Iterator::collect_into and Iterator::collect_with,frengor,NA,NA,NA,HEART,2022-01-17T04:14:43Z,cormacrelf,NA https://github.com/rust-lang/rust/pull/92982,CLOSED,2022-01-16T19:51:01Z,2022-01-19T01:02:40Z,Add Iterator::collect_into and Iterator::collect_with,frengor,NA,NA,NA,HEART,2022-01-17T15:00:06Z,tema3210,NA https://github.com/rust-lang/rust/pull/92997,MERGED,2022-01-17T05:50:46Z,2022-01-18T09:58:51Z,Add `~const` bound test for negative impls,woppopo,baeff67b5fed70a5bf49c050aa901d7a377bc924,2,Rollup merge of #92997 - woppopo:test92114 r=Mark-Simulacrum Add `~const` bound test for negative impls Resolves #92114 which has been fixed in #92892.,HEART,2022-01-17T21:17:00Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93001,MERGED,2022-01-17T10:44:13Z,2022-01-18T06:08:00Z,Out of cycle Clippy update,flip1995,e4ff9031acdb3579f61a67ded2cf0faa00bea3fc,43,Auto merge of #93001 - flip1995:clippyup r=Manishearth Out of cycle Clippy update I want to do an out-of-cycle sync for rust-lang/rust-clippy#8295 and possibly backport this to stable together with https://github.com/rust-lang/rust/issues/92938. If this doesn't get backported to stable then I at least want to backport it to beta. r? `@Manishearth`,HEART,2022-01-17T11:13:50Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/93006,MERGED,2022-01-17T16:40:01Z,2022-01-28T15:44:54Z,Fix debuginfo for pointers/references to unsized types,michaelwoerister,427eba2f0bacdeaebc992a78eb2889564de7d7cf,4,Auto merge of #93006 - michaelwoerister:fix-unsized-ptr-debuginfo r=davidtwco oli-obk Fix debuginfo for pointers/references to unsized types This PR makes the compiler emit fat pointer debuginfo in all cases. Before we sometimes got thin-pointer debuginfo making it impossible to fully interpret the pointed to memory in debuggers. The code is actually cleaner now especially around generation of trait object pointer debuginfo. Fixes https://github.com/rust-lang/rust/issues/92718 ~~Blocked on https://github.com/rust-lang/rust/pull/92729.~~,THUMBS_UP,2022-01-18T03:16:30Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93006,MERGED,2022-01-17T16:40:01Z,2022-01-28T15:44:54Z,Fix debuginfo for pointers/references to unsized types,michaelwoerister,427eba2f0bacdeaebc992a78eb2889564de7d7cf,4,Auto merge of #93006 - michaelwoerister:fix-unsized-ptr-debuginfo r=davidtwco oli-obk Fix debuginfo for pointers/references to unsized types This PR makes the compiler emit fat pointer debuginfo in all cases. Before we sometimes got thin-pointer debuginfo making it impossible to fully interpret the pointed to memory in debuggers. The code is actually cleaner now especially around generation of trait object pointer debuginfo. Fixes https://github.com/rust-lang/rust/issues/92718 ~~Blocked on https://github.com/rust-lang/rust/pull/92729.~~,THUMBS_UP,2022-01-19T13:40:29Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93007,CLOSED,2022-01-17T17:32:23Z,2022-01-18T19:32:34Z,Allocate one vec instead of one per invocation,oli-obk,NA,NA,NA,THUMBS_UP,2022-01-17T18:42:09Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93016,MERGED,2022-01-17T21:07:57Z,2022-01-18T09:58:51Z,Stabilize vec_spare_capacity,Amanieu,83b1a9452ac01291ccc45b226e3e7ac37e31a0f8,5,Rollup merge of #93016 - Amanieu:vec_spare_capacity r=Mark-Simulacrum Stabilize vec_spare_capacity Closes #75017,HOORAY,2022-01-17T21:12:25Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/93016,MERGED,2022-01-17T21:07:57Z,2022-01-18T09:58:51Z,Stabilize vec_spare_capacity,Amanieu,83b1a9452ac01291ccc45b226e3e7ac37e31a0f8,5,Rollup merge of #93016 - Amanieu:vec_spare_capacity r=Mark-Simulacrum Stabilize vec_spare_capacity Closes #75017,HOORAY,2022-01-17T22:46:54Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/93016,MERGED,2022-01-17T21:07:57Z,2022-01-18T09:58:51Z,Stabilize vec_spare_capacity,Amanieu,83b1a9452ac01291ccc45b226e3e7ac37e31a0f8,5,Rollup merge of #93016 - Amanieu:vec_spare_capacity r=Mark-Simulacrum Stabilize vec_spare_capacity Closes #75017,HOORAY,2022-01-18T14:41:11Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/93016,MERGED,2022-01-17T21:07:57Z,2022-01-18T09:58:51Z,Stabilize vec_spare_capacity,Amanieu,83b1a9452ac01291ccc45b226e3e7ac37e31a0f8,5,Rollup merge of #93016 - Amanieu:vec_spare_capacity r=Mark-Simulacrum Stabilize vec_spare_capacity Closes #75017,HOORAY,2022-01-18T22:26:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93019,MERGED,2022-01-17T22:27:30Z,2022-02-01T10:12:02Z,If an integer is entered with an upper-case base prefix (0Xbeef 0O755 0B1010) suggest to make it lowercase,5225225,d7c0b4f706ca1f093845faab62100cec29769bb0,4,Rollup merge of #93019 - 5225225:uppercase-suffix r=wesleywiser If an integer is entered with an upper-case base prefix (0Xbeef 0O755 0B1010) suggest to make it lowercase The current error for this case isn't really great it just complains about the whole thing past the `0` being an invalid suffix.,HEART,2022-01-18T16:28:41Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93019,MERGED,2022-01-17T22:27:30Z,2022-02-01T10:12:02Z,If an integer is entered with an upper-case base prefix (0Xbeef 0O755 0B1010) suggest to make it lowercase,5225225,d7c0b4f706ca1f093845faab62100cec29769bb0,4,Rollup merge of #93019 - 5225225:uppercase-suffix r=wesleywiser If an integer is entered with an upper-case base prefix (0Xbeef 0O755 0B1010) suggest to make it lowercase The current error for this case isn't really great it just complains about the whole thing past the `0` being an invalid suffix.,HEART,2022-02-13T03:22:18Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93026,MERGED,2022-01-18T07:31:34Z,2022-01-19T02:33:20Z,fix typo in `max` description for f32/f64,klensy,63376bb0fabb1599fa39444b60f65bb8ee5bdd06,2,Rollup merge of #93026 - klensy:f-typo r=scottmcm fix typo in `max` description for f32/f64,EYES,2022-01-18T09:14:20Z,Urgau,NA https://github.com/rust-lang/rust/pull/93028,MERGED,2022-01-18T09:52:45Z,2022-01-24T11:20:16Z,Check `const Drop` impls considering `~const` Bounds,compiler-errors,ef119d704d87a05435ea97ef4161529142313a9b,13,Auto merge of #93028 - compiler-errors:const_drop_bounds r=fee1-dead Check `const Drop` impls considering `~const` Bounds This PR adds logic to trait selection to account for `~const` bounds in custom `impl const Drop` for types elaborates the `const Drop` check in `rustc_const_eval` to check those bounds and steals some drop linting fixes from #92922 thanks `@DrMeepster.` r? `@fee1-dead` `@oli-obk` (edit: guess I can't request review from two people lol) since each of you wrote and reviewed #88558 respectively. Since the logic here is more complicated than what existed it's possible that this is a perf regression. But it works correctly with tests and that makes me happy. Fixes #92881,EYES,2022-01-18T09:53:27Z,DrMeepster,NA https://github.com/rust-lang/rust/pull/93028,MERGED,2022-01-18T09:52:45Z,2022-01-24T11:20:16Z,Check `const Drop` impls considering `~const` Bounds,compiler-errors,ef119d704d87a05435ea97ef4161529142313a9b,13,Auto merge of #93028 - compiler-errors:const_drop_bounds r=fee1-dead Check `const Drop` impls considering `~const` Bounds This PR adds logic to trait selection to account for `~const` bounds in custom `impl const Drop` for types elaborates the `const Drop` check in `rustc_const_eval` to check those bounds and steals some drop linting fixes from #92922 thanks `@DrMeepster.` r? `@fee1-dead` `@oli-obk` (edit: guess I can't request review from two people lol) since each of you wrote and reviewed #88558 respectively. Since the logic here is more complicated than what existed it's possible that this is a perf regression. But it works correctly with tests and that makes me happy. Fixes #92881,EYES,2022-01-18T11:19:52Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/93031,CLOSED,2022-01-18T11:16:57Z,2022-05-05T14:51:59Z,Make sure std::panic::Location::caller() gets optimized away.,michaelwoerister,NA,NA,NA,THUMBS_UP,2022-02-02T23:09:16Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/93039,MERGED,2022-01-18T16:09:48Z,2022-01-31T14:23:54Z,Don't suggest inaccessible fields,terrarier2111,71efe90889bd5f91d1e67549b6a19d8a2c795da5,3,Rollup merge of #93039 - terrarier2111:fix-field-help r=nagisa Don't suggest inaccessible fields Fixes: https://github.com/rust-lang/rust/issues/92999,THUMBS_UP,2022-01-18T18:03:12Z,pierwill,NA https://github.com/rust-lang/rust/pull/93039,MERGED,2022-01-18T16:09:48Z,2022-01-31T14:23:54Z,Don't suggest inaccessible fields,terrarier2111,71efe90889bd5f91d1e67549b6a19d8a2c795da5,3,Rollup merge of #93039 - terrarier2111:fix-field-help r=nagisa Don't suggest inaccessible fields Fixes: https://github.com/rust-lang/rust/issues/92999,HEART,2022-02-03T18:14:29Z,estebank,NA https://github.com/rust-lang/rust/pull/93044,CLOSED,2022-01-18T18:28:24Z,2022-07-11T17:05:23Z,Add forwarding impls for Read Write Seek to Arc Rc,eholk,NA,NA,NA,THUMBS_UP,2022-01-18T20:32:03Z,bugadani,NA https://github.com/rust-lang/rust/pull/93047,MERGED,2022-01-18T20:43:33Z,2022-01-23T15:37:44Z,build: dist: defer PlainSourceTarball,matthiaskrgr,1e4067957bd5d0e12c1657e720903209ecc291dc,1,Auto merge of #93047 - matthiaskrgr:defer__dist_PlainSourceTarball r=Mark-Simulacrum build: dist: defer PlainSourceTarball Apparently it changes some tool sources and invalidates their fingerprints forcing us to build them several times (before and after vendoring sources). I have not dug into why vendoring actually invalidates the figreprints but moving the vendoring lower in the pipeline seems to avoid the issue. I could imagine that we somehow write a .cargo/config somewhere which somehow makes subsequent builds use the vendored deps but I was not able to find anything. I checked the sizes of generated archives pre and post patch and their are the same so I hope there is no functional change. Fixes #93033,THUMBS_UP,2022-01-18T20:45:31Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93047,MERGED,2022-01-18T20:43:33Z,2022-01-23T15:37:44Z,build: dist: defer PlainSourceTarball,matthiaskrgr,1e4067957bd5d0e12c1657e720903209ecc291dc,1,Auto merge of #93047 - matthiaskrgr:defer__dist_PlainSourceTarball r=Mark-Simulacrum build: dist: defer PlainSourceTarball Apparently it changes some tool sources and invalidates their fingerprints forcing us to build them several times (before and after vendoring sources). I have not dug into why vendoring actually invalidates the figreprints but moving the vendoring lower in the pipeline seems to avoid the issue. I could imagine that we somehow write a .cargo/config somewhere which somehow makes subsequent builds use the vendored deps but I was not able to find anything. I checked the sizes of generated archives pre and post patch and their are the same so I hope there is no functional change. Fixes #93033,THUMBS_UP,2022-01-18T20:46:14Z,hkratz,NA https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,HEART,2022-01-18T21:59:31Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,HEART,2022-01-18T22:09:36Z,dustypaws,NA https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,CONFUSED,2022-01-19T00:17:00Z,arniu,NA https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,HEART,2022-01-19T07:56:46Z,ShadowJonathan,jonathandejong02@gmail.com https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,CONFUSED,2022-01-27T07:02:11Z,birkenfeld,georg@python.org https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,HEART,2022-01-29T10:07:53Z,arthurprs,NA https://github.com/rust-lang/rust/pull/93051,MERGED,2022-01-18T21:20:34Z,2022-01-19T18:18:21Z,Add Option::is_some_with and Result::is_{ok err}_with,m-ou-se,d5bc168d65dd5d0cbdf138797fe23306867a0e67,2,Rollup merge of #93051 - m-ou-se:is-some-with r=yaahc Add Option::is_some_with and Result::is_{ok err}_with See https://github.com/rust-lang/rust/issues/62358#issuecomment-1015827777,HEART,2022-04-25T14:57:56Z,kekeimiku,kekelanact@gmail.com https://github.com/rust-lang/rust/pull/93057,MERGED,2022-01-19T01:10:38Z,2022-03-10T04:58:49Z,Add Iterator::collect_into,frengor,d5c05fcc8ab7eae499d7bd9bd44d5d005fdc1fc3,3,Rollup merge of #93057 - frengor:iter_collect_into r=m-ou-se Add Iterator::collect_into This PR adds `Iterator::collect_into` as proposed by ``@cormacrelf`` in #48597 (see https://github.com/rust-lang/rust/pull/48597#issuecomment-842083688). Followup of #92982. This adds the following method to the Iterator trait: ```rust fn collect_into>(self collection: &mut E) -> &mut E ```,ROCKET,2022-01-19T03:09:31Z,cormacrelf,NA https://github.com/rust-lang/rust/pull/93066,MERGED,2022-01-19T06:31:02Z,2022-01-23T18:51:07Z,Make `Decodable` and `Decoder` infallible.,nnethercote,84322efad553c7a79c80189f2d1b9197c1aa005f,39,Auto merge of #93066 - nnethercote:infallible-decoder r=bjorn3 Make `Decodable` and `Decoder` infallible. `Decoder` has two impls: - opaque: this impl is already partly infallible i.e. in some places it currently panics on failure (e.g. if the input is too short or on a bad `Result` discriminant) and in some places it returns an error (e.g. on a bad `Option` discriminant). The number of places where either happens is surprisingly small just because the binary representation has very little redundancy and a lot of input reading can occur even on malformed data. - json: this impl is fully fallible but it's only used (a) for the `.rlink` file production and there's a `FIXME` comment suggesting it should change to a binary format and (b) in a few tests in non-fundamental ways. Indeed #85993 is open to remove it entirely. And the top-level places in the compiler that call into decoding just abort on error anyway. So the fallibility is providing little value and getting rid of it leads to some non-trivial performance improvements. Much of this PR is pretty boring and mechanical. Some notes about a few interesting parts: - The commit removes `Decoder::{Error error}`. - `InternIteratorElement::intern_with`: the impl for `T` now has the same optimization for small counts that the impl for `Result` has because it's now much hotter. - Decodable impls for SmallVec LinkedList VecDeque now all use `collect` which is nice; the one for `Vec` uses unsafe code because that gave better perf on some benchmarks. r? `@bjorn3`,HEART,2022-01-19T12:10:45Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/93066,MERGED,2022-01-19T06:31:02Z,2022-01-23T18:51:07Z,Make `Decodable` and `Decoder` infallible.,nnethercote,84322efad553c7a79c80189f2d1b9197c1aa005f,39,Auto merge of #93066 - nnethercote:infallible-decoder r=bjorn3 Make `Decodable` and `Decoder` infallible. `Decoder` has two impls: - opaque: this impl is already partly infallible i.e. in some places it currently panics on failure (e.g. if the input is too short or on a bad `Result` discriminant) and in some places it returns an error (e.g. on a bad `Option` discriminant). The number of places where either happens is surprisingly small just because the binary representation has very little redundancy and a lot of input reading can occur even on malformed data. - json: this impl is fully fallible but it's only used (a) for the `.rlink` file production and there's a `FIXME` comment suggesting it should change to a binary format and (b) in a few tests in non-fundamental ways. Indeed #85993 is open to remove it entirely. And the top-level places in the compiler that call into decoding just abort on error anyway. So the fallibility is providing little value and getting rid of it leads to some non-trivial performance improvements. Much of this PR is pretty boring and mechanical. Some notes about a few interesting parts: - The commit removes `Decoder::{Error error}`. - `InternIteratorElement::intern_with`: the impl for `T` now has the same optimization for small counts that the impl for `Result` has because it's now much hotter. - Decodable impls for SmallVec LinkedList VecDeque now all use `collect` which is nice; the one for `Vec` uses unsafe code because that gave better perf on some benchmarks. r? `@bjorn3`,HEART,2022-02-07T22:38:25Z,lqd,NA https://github.com/rust-lang/rust/pull/93071,MERGED,2022-01-19T09:53:52Z,2022-01-20T15:50:33Z,[stable] Prepare 1.58.1 point release,pietroalbini,0076b17beffa3aca955b5311fcdeb2a1309af865,1,bump cargo to fix spurious failure,THUMBS_UP,2022-01-20T12:02:02Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T20:11:53Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T22:07:10Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T22:23:04Z,adsick,adsick@protonmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T22:42:26Z,bugadani,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-19T22:46:53Z,zamazan4ik,zamazan4ik@tut.by https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T22:57:41Z,Kolsky,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-19T23:35:27Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T09:23:03Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T09:34:55Z,the-eater,#NAME? https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T10:16:55Z,pierd,jakub.jaroszewski@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T12:18:59Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T12:19:00Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T13:44:25Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T14:24:04Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T15:07:03Z,engylemure,jordao.rosario01@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T15:07:04Z,engylemure,jordao.rosario01@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T15:07:04Z,engylemure,jordao.rosario01@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T15:10:27Z,Agrailag,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T15:10:29Z,Agrailag,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T15:10:33Z,Agrailag,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T15:16:09Z,sergeysova,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T15:16:10Z,sergeysova,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T15:51:52Z,ratijas,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T16:14:25Z,Emilgardis,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T16:20:25Z,bmartynov,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T16:20:28Z,bmartynov,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T16:20:28Z,bmartynov,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T16:33:49Z,mexus,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-20T21:28:49Z,Alfriadox,alfriadox@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T21:28:50Z,Alfriadox,alfriadox@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T21:28:50Z,Alfriadox,alfriadox@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-20T22:35:37Z,peter-leonov,gojpeg@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-20T22:35:39Z,peter-leonov,gojpeg@gmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-21T00:02:46Z,CPerezz,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-21T00:55:22Z,rrbutani,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-21T00:55:25Z,rrbutani,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-21T10:10:40Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-22T21:21:03Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-22T21:21:03Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-22T21:21:05Z,slerpyyy,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-01-22T22:02:54Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-22T22:03:09Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-22T22:03:10Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HOORAY,2022-01-23T10:00:39Z,Tehnix,NA https://github.com/rust-lang/rust/pull/93082,CLOSED,2022-01-19T16:20:18Z,2022-02-01T19:50:56Z,Allow `impl Fn() -> impl Trait`,WaffleLapkin,NA,NA,NA,HEART,2022-01-28T15:08:01Z,jwollen,NA https://github.com/rust-lang/rust/pull/93090,MERGED,2022-01-19T19:44:40Z,2022-02-01T10:12:02Z,`impl Display for io::ErrorKind`,jyn514,8604161d7538fd23cb1fe76f4d2f7317c0e8d315,1,Rollup merge of #93090 - jyn514:errorkind-asstr r=dtolnay `impl Display for io::ErrorKind` This avoids having to convert from `ErrorKind` to `Error` just to print the error message.,HEART,2022-01-19T23:12:09Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93090,MERGED,2022-01-19T19:44:40Z,2022-02-01T10:12:02Z,`impl Display for io::ErrorKind`,jyn514,8604161d7538fd23cb1fe76f4d2f7317c0e8d315,1,Rollup merge of #93090 - jyn514:errorkind-asstr r=dtolnay `impl Display for io::ErrorKind` This avoids having to convert from `ErrorKind` to `Error` just to print the error message.,HEART,2022-01-19T23:21:19Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/93090,MERGED,2022-01-19T19:44:40Z,2022-02-01T10:12:02Z,`impl Display for io::ErrorKind`,jyn514,8604161d7538fd23cb1fe76f4d2f7317c0e8d315,1,Rollup merge of #93090 - jyn514:errorkind-asstr r=dtolnay `impl Display for io::ErrorKind` This avoids having to convert from `ErrorKind` to `Error` just to print the error message.,HEART,2022-01-20T14:36:04Z,fmease,NA https://github.com/rust-lang/rust/pull/93090,MERGED,2022-01-19T19:44:40Z,2022-02-01T10:12:02Z,`impl Display for io::ErrorKind`,jyn514,8604161d7538fd23cb1fe76f4d2f7317c0e8d315,1,Rollup merge of #93090 - jyn514:errorkind-asstr r=dtolnay `impl Display for io::ErrorKind` This avoids having to convert from `ErrorKind` to `Error` just to print the error message.,HEART,2022-01-25T13:57:33Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/93090,MERGED,2022-01-19T19:44:40Z,2022-02-01T10:12:02Z,`impl Display for io::ErrorKind`,jyn514,8604161d7538fd23cb1fe76f4d2f7317c0e8d315,1,Rollup merge of #93090 - jyn514:errorkind-asstr r=dtolnay `impl Display for io::ErrorKind` This avoids having to convert from `ErrorKind` to `Error` just to print the error message.,HEART,2022-01-31T16:28:58Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/93095,MERGED,2022-01-19T21:44:53Z,2022-01-25T21:56:21Z,Store a `Symbol` instead of an `Ident` in `AssocItem`,Aaron1011,8cdb3cd94efece1e17cbd8f6edb1dc1a482779a0,28,Auto merge of #93095 - Aaron1011:remove-assoc-ident r=cjgillot Store a `Symbol` instead of an `Ident` in `AssocItem` This is the same idea as #92533 but for `AssocItem` instead of `VariantDef`/`FieldDef`. With this change we no longer have any uses of `#[stable_hasher(project(...))]`,HOORAY,2022-01-19T21:46:18Z,matthewjasper,NA https://github.com/rust-lang/rust/pull/93095,MERGED,2022-01-19T21:44:53Z,2022-01-25T21:56:21Z,Store a `Symbol` instead of an `Ident` in `AssocItem`,Aaron1011,8cdb3cd94efece1e17cbd8f6edb1dc1a482779a0,28,Auto merge of #93095 - Aaron1011:remove-assoc-ident r=cjgillot Store a `Symbol` instead of an `Ident` in `AssocItem` This is the same idea as #92533 but for `AssocItem` instead of `VariantDef`/`FieldDef`. With this change we no longer have any uses of `#[stable_hasher(project(...))]`,HOORAY,2022-02-25T08:47:36Z,pro465,NA https://github.com/rust-lang/rust/pull/93100,CLOSED,2022-01-20T00:07:29Z,2022-01-21T17:30:08Z,`impl PartialEq for io::Error`,ChrisDenton,NA,NA,NA,THUMBS_UP,2022-01-20T01:06:19Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/93100,CLOSED,2022-01-20T00:07:29Z,2022-01-21T17:30:08Z,`impl PartialEq for io::Error`,ChrisDenton,NA,NA,NA,THUMBS_UP,2022-01-20T02:23:00Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93100,CLOSED,2022-01-20T00:07:29Z,2022-01-21T17:30:08Z,`impl PartialEq for io::Error`,ChrisDenton,NA,NA,NA,THUMBS_UP,2022-01-20T08:54:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93100,CLOSED,2022-01-20T00:07:29Z,2022-01-21T17:30:08Z,`impl PartialEq for io::Error`,ChrisDenton,NA,NA,NA,THUMBS_UP,2022-01-21T04:30:14Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93101,MERGED,2022-01-20T02:59:03Z,2022-02-03T01:08:49Z,Support configuring whether to capture backtraces at runtime,Mark-Simulacrum,b3800860e123443ffada615538926beed6bc4f85,7,Auto merge of #93101 - Mark-Simulacrum:library-backtrace r=yaahc Support configuring whether to capture backtraces at runtime Tracking issue: https://github.com/rust-lang/rust/issues/93346 This adds a new API to the `std::panic` module which configures whether and how the default panic hook will emit a backtrace when a panic occurs. After discussion with `@yaahc` on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/backtrace.20lib.20vs.2E.20panic) this PR chooses to avoid adjusting or seeking to provide a similar API for the (currently unstable) std::backtrace API. It seems likely that the users of that API may wish to expose more specific settings rather than just a global one (e.g. emulating the `env_logger` `tracing` per-module configuration) to avoid the cost of capture in hot code. The API added here could plausibly be copied and/or re-exported directly from std::backtrace relatively easily but I don't think that's the right call as of now. ```rust mod panic { #[derive(Copy Clone Debug PartialEq Eq)] #[non_exhaustive] pub enum BacktraceStyle { Short Full Off } fn set_backtrace_style(BacktraceStyle); fn get_backtrace_style() -> Option; } ``` Several unresolved questions: * Do we need to move to a thread-local or otherwise more customizable strategy for whether to capture backtraces? See [this comment](https://github.com/rust-lang/rust/pull/79085#issuecomment-727845826) for some potential use cases for this. * Proposed answer: no leave this for third-party hooks. * Bikeshed on naming of all the options as usual. * Should BacktraceStyle be moved into `std::backtrace`? * It's already somewhat annoying to import and/or re-type the `std::panic::` prefix necessary to use these APIs probably adding a second module to the mix isn't worth it. Note that PR #79085 proposed a much simpler API but particularly in light of the desire to fully replace setting environment variables via `env::set_var` to control the backtrace API a more complete API seems preferable. This PR likely subsumes that one.,HEART,2022-01-21T00:21:15Z,briansmith,brian@briansmith.org https://github.com/rust-lang/rust/pull/93102,MERGED,2022-01-20T03:25:07Z,2022-01-21T06:20:19Z,Pretty printer algorithm revamp step 3,dtolnay,d4ec46444b8e0fc5f4deaf4408cd0cab367178f1,2,"Rollup merge of #93102 - dtolnay:ringbuffer r=lcnr Pretty printer algorithm revamp step 3 This PR follows #93065 as a third chunk of minor modernizations backported from https://github.com/dtolnay/prettyplease into rustc_ast_pretty. I've broken this up into atomic commits that hopefully are sensible in isolation. At every commit the pretty printer is compilable and has runtime behavior that is identical to before and after the PR. None of the refactoring so far changes behavior. This PR is the last chunk of non-behavior-changing cleanup. After this the **next PR** will begin backporting behavior changes from `prettyplease` starting with block indentation: ```rust macro_rules! print_expr { ($expr:expr) => { println!(""{}"" stringify!($expr)); }; } fn main() { print_expr!(Struct { x: 0 y: 0 }); print_expr!(Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 }); } ``` Output currently on master (nowhere near modern Rust style): ```console Struct{x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt{xxxxxxxxx: 0 yyyyyyyyy: 0 } ``` After the upcoming PR for block indentation (based on https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba): ```console Struct { x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 } ``` And the PR after that for intelligent trailing commas (based on https://github.com/dtolnay/prettyplease/commit/e2a0297f1781b787b90bca5aba1bdb4966661882): ```console Struct { x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 } ```",HEART,2022-01-20T04:04:06Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93102,MERGED,2022-01-20T03:25:07Z,2022-01-21T06:20:19Z,Pretty printer algorithm revamp step 3,dtolnay,d4ec46444b8e0fc5f4deaf4408cd0cab367178f1,2,"Rollup merge of #93102 - dtolnay:ringbuffer r=lcnr Pretty printer algorithm revamp step 3 This PR follows #93065 as a third chunk of minor modernizations backported from https://github.com/dtolnay/prettyplease into rustc_ast_pretty. I've broken this up into atomic commits that hopefully are sensible in isolation. At every commit the pretty printer is compilable and has runtime behavior that is identical to before and after the PR. None of the refactoring so far changes behavior. This PR is the last chunk of non-behavior-changing cleanup. After this the **next PR** will begin backporting behavior changes from `prettyplease` starting with block indentation: ```rust macro_rules! print_expr { ($expr:expr) => { println!(""{}"" stringify!($expr)); }; } fn main() { print_expr!(Struct { x: 0 y: 0 }); print_expr!(Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 }); } ``` Output currently on master (nowhere near modern Rust style): ```console Struct{x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt{xxxxxxxxx: 0 yyyyyyyyy: 0 } ``` After the upcoming PR for block indentation (based on https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba): ```console Struct { x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 } ``` And the PR after that for intelligent trailing commas (based on https://github.com/dtolnay/prettyplease/commit/e2a0297f1781b787b90bca5aba1bdb4966661882): ```console Struct { x: 0 y: 0 } Structtttttttttttttttttttttttttttttttttttttttttttttttttt { xxxxxxxxx: 0 yyyyyyyyy: 0 } ```",HEART,2022-01-20T14:35:39Z,fmease,NA https://github.com/rust-lang/rust/pull/93103,MERGED,2022-01-20T04:09:56Z,2022-01-23T12:29:11Z,Tweak `expr.await` desugaring `Span`,estebank,a15252817a11acfbb6127d34a6ec0ede3ad4a7ae,4,Rollup merge of #93103 - estebank:await-span r=nagisa Tweak `expr.await` desugaring `Span` Fix #93074,HEART,2022-01-20T04:25:36Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93103,MERGED,2022-01-20T04:09:56Z,2022-01-23T12:29:11Z,Tweak `expr.await` desugaring `Span`,estebank,a15252817a11acfbb6127d34a6ec0ede3ad4a7ae,4,Rollup merge of #93103 - estebank:await-span r=nagisa Tweak `expr.await` desugaring `Span` Fix #93074,HEART,2022-01-20T05:01:52Z,Friz64,friz64@protonmail.com https://github.com/rust-lang/rust/pull/93103,MERGED,2022-01-20T04:09:56Z,2022-01-23T12:29:11Z,Tweak `expr.await` desugaring `Span`,estebank,a15252817a11acfbb6127d34a6ec0ede3ad4a7ae,4,Rollup merge of #93103 - estebank:await-span r=nagisa Tweak `expr.await` desugaring `Span` Fix #93074,HEART,2022-01-20T22:00:51Z,vitorenesduarte,vitorenesduarte@gmail.com https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,THUMBS_UP,2022-01-20T05:48:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,HEART,2022-01-20T14:05:31Z,woppopo,NA https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,EYES,2022-01-20T17:03:08Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,HEART,2022-01-21T04:41:01Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,HEART,2022-01-27T00:10:43Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,THUMBS_UP,2022-02-12T21:31:23Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93105,CLOSED,2022-01-20T05:45:03Z,2022-02-27T09:10:14Z,Make Box drop through Drop trait,DrMeepster,NA,NA,NA,HEART,2022-02-21T16:40:03Z,tema3210,NA https://github.com/rust-lang/rust/pull/93107,CLOSED,2022-01-20T09:14:07Z,2022-01-21T04:29:02Z,Add #[must_use] to {HashMap HashSet BTreeMap BTreeSet}::insert,safinaskar,NA,NA,NA,EYES,2022-01-20T09:56:08Z,zirconium-n,NA https://github.com/rust-lang/rust/pull/93113,MERGED,2022-01-20T13:24:57Z,2022-01-23T12:29:11Z,Unify search input and buttons size,GuillaumeGomez,74b05ce74642a1ef5cf8e25ce1c259e48b5324ad,5,Rollup merge of #93113 - GuillaumeGomez:unify-sizes r=jsha Unify search input and buttons size Fixes #93060. Here what it looks like: ![Screenshot from 2022-01-20 21-38-19](https://user-images.githubusercontent.com/3050060/150418571-fefd6538-b3ee-4dd2-b77b-77e96bcfa0ed.png) ![Screenshot from 2022-01-20 21-38-22](https://user-images.githubusercontent.com/3050060/150418570-53ba259b-9bd4-4084-8b43-d74a5752d712.png) You can test it [here](https://rustdoc.crud.net/imperio/unify-sizes/std/index.html). r? ``@jsha``,THUMBS_UP,2022-01-20T13:35:46Z,Urgau,NA https://github.com/rust-lang/rust/pull/93113,MERGED,2022-01-20T13:24:57Z,2022-01-23T12:29:11Z,Unify search input and buttons size,GuillaumeGomez,74b05ce74642a1ef5cf8e25ce1c259e48b5324ad,5,Rollup merge of #93113 - GuillaumeGomez:unify-sizes r=jsha Unify search input and buttons size Fixes #93060. Here what it looks like: ![Screenshot from 2022-01-20 21-38-19](https://user-images.githubusercontent.com/3050060/150418571-fefd6538-b3ee-4dd2-b77b-77e96bcfa0ed.png) ![Screenshot from 2022-01-20 21-38-22](https://user-images.githubusercontent.com/3050060/150418570-53ba259b-9bd4-4084-8b43-d74a5752d712.png) You can test it [here](https://rustdoc.crud.net/imperio/unify-sizes/std/index.html). r? ``@jsha``,THUMBS_UP,2022-04-09T05:28:36Z,faptc,NA https://github.com/rust-lang/rust/pull/93114,MERGED,2022-01-20T13:49:21Z,2022-01-21T06:20:19Z,update comment for `ensure_monomorphic_enough`,lcnr,b8df581ef855999fc409ed3c7e8f97d548ac05ad,2,Rollup merge of #93114 - lcnr:mk_array r=RalfJung update comment for `ensure_monomorphic_enough` r? `@RalfJung`,HEART,2022-01-20T14:40:52Z,RalfJung,NA https://github.com/rust-lang/rust/pull/93118,MERGED,2022-01-20T15:25:03Z,2022-01-25T08:18:30Z,Move param count error emission to end of `check_argument_types`,jackh726,c8ede152a522fcf139b35700b36ec3e788617857,3,Rollup merge of #93118 - jackh726:param-heuristics-3 r=estebank Move param count error emission to end of `check_argument_types` The error emission here isn't exactly what is done in #92364 but replicating that is hard . The general move should make for a smaller diff. Also included the `(usize Ty Ty)` to -> `Option<(Ty Ty)>` commit. r? ``@estebank``,HEART,2022-01-20T21:29:22Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93132,MERGED,2022-01-20T21:19:22Z,2022-01-22T22:10:58Z,Increase the format version of rustdoc-json-types,Urgau,45f5f342930f17b6eeca962d0ff25d889f4e6cc6,1,Rollup merge of #93132 - Urgau:fix-rustdoc-json-format-version r=oli-obk Increase the format version of rustdoc-json-types PR https://github.com/rust-lang/rust/pull/87648 changed `rustdoc-json-types` without increasing the format version. https://github.com/rust-lang/rust/commit/e7529d6a3867ed1692818702b40814ee992eba2d#diff-ede26372490522288745c5b3df2b6b2a1cc913dcd09b29af3a49935afe00c7e6 This PR increase the format version by +1 and move the `FORMAT_VERSION` constant to the start of the file to hopefully make it more clear that `rustdoc-json-types` is versioned.,THUMBS_UP,2022-02-06T13:31:03Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/93139,MERGED,2022-01-20T22:54:31Z,2022-01-22T02:54:32Z,rustdoc: fix overflow-wrap for table layouts,jsha,26e9357faed8bf79d9881bafd49c984107485ede,3,Rollup merge of #93139 - jsha:fix-wrapped-names r=Nemo157 rustdoc: fix overflow-wrap for table layouts For all table layouts set overflow-wrap: break-word. Fixes #93135 Demo: https://rustdoc.crud.net/jsha/fix-wrapped-names/std/intrinsics/index.html#functions (Compare vs https://doc.rust-lang.org/nightly/std/intrinsics/index.html - you may have to make your browser narrower to see the effect) r? `@Nemo157`,THUMBS_UP,2022-01-20T23:14:49Z,Urgau,NA https://github.com/rust-lang/rust/pull/93142,MERGED,2022-01-21T00:15:50Z,2022-03-05T04:56:36Z,Do not point at whole file missing `fn main`,estebank,8c93948d6e9e09abfffc53d0b863ece16cde7286,19,Auto merge of #93142 - estebank:missing-main r=wesleywiser Do not point at whole file missing `fn main` Only point at the end of the crate. We could try making it point at the beginning of the crate but that is confused with `DUMMY_SP` causing the output to be *worse*. This change will make it so that VSCode will *not* underline the whole file when `main` is missing so other errors will be visible.,HEART,2022-01-21T04:49:19Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/93142,MERGED,2022-01-21T00:15:50Z,2022-03-05T04:56:36Z,Do not point at whole file missing `fn main`,estebank,8c93948d6e9e09abfffc53d0b863ece16cde7286,19,Auto merge of #93142 - estebank:missing-main r=wesleywiser Do not point at whole file missing `fn main` Only point at the end of the crate. We could try making it point at the beginning of the crate but that is confused with `DUMMY_SP` causing the output to be *worse*. This change will make it so that VSCode will *not* underline the whole file when `main` is missing so other errors will be visible.,THUMBS_UP,2022-01-21T18:31:18Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93142,MERGED,2022-01-21T00:15:50Z,2022-03-05T04:56:36Z,Do not point at whole file missing `fn main`,estebank,8c93948d6e9e09abfffc53d0b863ece16cde7286,19,Auto merge of #93142 - estebank:missing-main r=wesleywiser Do not point at whole file missing `fn main` Only point at the end of the crate. We could try making it point at the beginning of the crate but that is confused with `DUMMY_SP` causing the output to be *worse*. This change will make it so that VSCode will *not* underline the whole file when `main` is missing so other errors will be visible.,THUMBS_UP,2022-01-23T20:54:12Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93142,MERGED,2022-01-21T00:15:50Z,2022-03-05T04:56:36Z,Do not point at whole file missing `fn main`,estebank,8c93948d6e9e09abfffc53d0b863ece16cde7286,19,Auto merge of #93142 - estebank:missing-main r=wesleywiser Do not point at whole file missing `fn main` Only point at the end of the crate. We could try making it point at the beginning of the crate but that is confused with `DUMMY_SP` causing the output to be *worse*. This change will make it so that VSCode will *not* underline the whole file when `main` is missing so other errors will be visible.,THUMBS_UP,2022-03-10T08:09:25Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93142,MERGED,2022-01-21T00:15:50Z,2022-03-05T04:56:36Z,Do not point at whole file missing `fn main`,estebank,8c93948d6e9e09abfffc53d0b863ece16cde7286,19,Auto merge of #93142 - estebank:missing-main r=wesleywiser Do not point at whole file missing `fn main` Only point at the end of the crate. We could try making it point at the beginning of the crate but that is confused with `DUMMY_SP` causing the output to be *worse*. This change will make it so that VSCode will *not* underline the whole file when `main` is missing so other errors will be visible.,THUMBS_UP,2022-03-11T09:20:57Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/93144,MERGED,2022-01-21T02:26:50Z,2022-01-25T08:18:30Z,Work around missing code coverage data causing llvm-cov failures,wesleywiser,8dddc8647731efb6d7f40b176bccdba5cebe46f2,3,Rollup merge of #93144 - wesleywiser:uninhabited_type_code_cov2 r=tmandry Work around missing code coverage data causing llvm-cov failures If we do not add code coverage instrumentation to the `Body` of a function then when we go to generate the function record for it we won't write any data and this later causes llvm-cov to fail when processing data for the entire coverage report. I've identified two main cases where we do not currently add code coverage instrumentation to the `Body` of a function: 1. If the function has a single `BasicBlock` and it ends with a `TerminatorKind::Unreachable`. 2. If the function is created using a proc macro of some kind. For case 1 this is typically not important as this most often occurs as a result of function definitions that take or return uninhabited types. These kinds of functions by definition cannot even be called so they logically should not be counted in code coverage statistics. For case 2 I haven't looked into this very much but I've noticed while testing this patch that (other than functions which are covered by case 1) the skipped function coverage debug message is occasionally triggered in large crate graphs by functions generated from a proc macro. This may have something to do with weird spans being generated by the proc macro but this is just a guess. I think it's reasonable to land this change since currently we fail to generate *any* results from llvm-cov when a function has no coverage instrumentation applied to it. With this change we get coverage data for all functions other than the two cases discussed above. Fixes #93054 which occurs because of uncallable functions which shouldn't have code coverage anyway. I will open an issue for missing code coverage of proc macro generated functions and leave a link here once I have a more minimal repro. r? ``@tmandry`` cc ``@richkadel``,HEART,2022-01-22T09:13:57Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/93144,MERGED,2022-01-21T02:26:50Z,2022-01-25T08:18:30Z,Work around missing code coverage data causing llvm-cov failures,wesleywiser,8dddc8647731efb6d7f40b176bccdba5cebe46f2,3,Rollup merge of #93144 - wesleywiser:uninhabited_type_code_cov2 r=tmandry Work around missing code coverage data causing llvm-cov failures If we do not add code coverage instrumentation to the `Body` of a function then when we go to generate the function record for it we won't write any data and this later causes llvm-cov to fail when processing data for the entire coverage report. I've identified two main cases where we do not currently add code coverage instrumentation to the `Body` of a function: 1. If the function has a single `BasicBlock` and it ends with a `TerminatorKind::Unreachable`. 2. If the function is created using a proc macro of some kind. For case 1 this is typically not important as this most often occurs as a result of function definitions that take or return uninhabited types. These kinds of functions by definition cannot even be called so they logically should not be counted in code coverage statistics. For case 2 I haven't looked into this very much but I've noticed while testing this patch that (other than functions which are covered by case 1) the skipped function coverage debug message is occasionally triggered in large crate graphs by functions generated from a proc macro. This may have something to do with weird spans being generated by the proc macro but this is just a guess. I think it's reasonable to land this change since currently we fail to generate *any* results from llvm-cov when a function has no coverage instrumentation applied to it. With this change we get coverage data for all functions other than the two cases discussed above. Fixes #93054 which occurs because of uncallable functions which shouldn't have code coverage anyway. I will open an issue for missing code coverage of proc macro generated functions and leave a link here once I have a more minimal repro. r? ``@tmandry`` cc ``@richkadel``,HEART,2022-01-23T05:07:03Z,taiki-e,NA https://github.com/rust-lang/rust/pull/93152,MERGED,2022-01-21T08:03:22Z,2022-01-24T17:48:28Z,Fix STD compilation for the ESP-IDF target (regression from CVE-2022-21658),ivmarkov,144aeedcf3ec4720c2635bbd20a5b3b1588547e3,1,"Rollup merge of #93152 - ivmarkov:master r=m-ou-se Fix STD compilation for the ESP-IDF target (regression from CVE-2022-21658) Commit https://github.com/rust-lang/rust/commit/54e22eb7dbb615bd44355028d3fd867aa93c0972 broke the compilation of STD for the ESP-IDF embedded ""unix-like"" Tier 3 target because the fix for [CVE-2022-21658](https://blog.rust-lang.org/2022/01/20/Rust-1.58.1.html) uses [libc flags](https://github.com/esp-rs/esp-idf-svc/runs/4892221554?check_suite_focus=true) which are not supported on the ESP-IDF platform. This PR simply redirects the ESP-IDF compilation to the ""classic"" implementation similar to REDOX. This should be safe because: * Neither of the two filesystems supported by ESP-IDF (spiffs and fatfs) support [symlinks](https://github.com/natevw/fatfs/blob/master/README.md) in the first place * There is no notion of fs permissions at all as the ESP-IDF is an embedded platform that does not have the notion of users groups etc. * Similarly ESP-IDF has just one ""process"" - the firmware itself - which contains the user code and the ""OS"" fused together and running with all permissions",THUMBS_UP,2022-01-21T13:31:07Z,hkratz,NA https://github.com/rust-lang/rust/pull/93153,MERGED,2022-01-21T09:33:28Z,2022-01-22T22:10:58Z,Reject unsupported naked functions,tmiasko,a8f64c04150f239e480aed6245273391d8bc3ea5,9,Rollup merge of #93153 - tmiasko:reject-unsupported-naked-functions r=Amanieu Reject unsupported naked functions Transition unsupported naked functions future incompatibility lint into an error: * Naked functions must contain a single inline assembly block. Introduced as future incompatibility lint in 1.50 #79653. Change into an error fixes a soundness issue described in #32489. * Naked functions must not use any forms of inline attribute. Introduced as future incompatibility lint in 1.56 #87652. Closes #32490. Closes #32489. r? ```@Amanieu``` ```@npmccallum``` ```@joshtriplett```,THUMBS_UP,2022-01-21T17:34:54Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",HEART,2022-01-21T11:59:26Z,bjorn3,NA https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",HEART,2022-01-21T14:20:01Z,fmease,NA https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",ROCKET,2022-01-21T14:20:06Z,fmease,NA https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",HEART,2022-01-21T15:03:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",HEART,2022-01-25T16:55:27Z,camsteffen,NA https://github.com/rust-lang/rust/pull/93155,MERGED,2022-01-21T10:05:05Z,2022-01-31T14:23:54Z,Switch pretty printer to block-based indentation,dtolnay,1cb22e4138ad977c51d66744e40ce2a22d7cd528,22,"Rollup merge of #93155 - dtolnay:blockindent r=nagisa Switch pretty printer to block-based indentation This PR backports https://github.com/dtolnay/prettyplease/commit/401d60c04213e6c66565e0e69a95b4588db5fdba from the `prettyplease` crate into `rustc_ast_pretty`. A before and after: ```diff - let res = - ((::alloc::fmt::format as - for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 - as - fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" - as - &str)] - as - [&str; 1]) - as - &[&str; 1]) - (&([] - as - [ArgumentV1; 0]) - as - &[ArgumentV1; 0])) - as - Arguments)) - as String); + let res = + ((::alloc::fmt::format as + for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1 + as + fn(&[&'static str] &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([(""test"" + as &str)] as [&str; 1]) as + &[&str; 1]) + (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as + Arguments)) as String); ``` Previously the pretty printer would compute indentation always relative to whatever column a block begins at like this: ```rust fn demo(arg1: usize arg2: usize); ``` This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation: ```rust fn demo( arg1: usize arg2: usize ); ``` where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line not the position that the block starts in. By itself this PR doesn't get perfect formatting in all cases but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.",HEART,2022-01-31T21:52:39Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93158,MERGED,2022-01-21T13:29:04Z,2022-01-29T02:20:04Z,wasi: implement `sock_accept` and enable networking,haraldh,9f15c4d08b7d5eec77f6a6e4caa2ee720fbc51c2,10,Rollup merge of #93158 - haraldh:wasi_sock_accept r=dtolnay wasi: implement `sock_accept` and enable networking With the addition of `sock_accept()` to snapshot1 simple networking via a passed `TcpListener` is possible. This PR implements the basics to make a simple server work. See also: * [wasmtime tracking issue](https://github.com/bytecodealliance/wasmtime/issues/3730) * [wasmtime PR](https://github.com/bytecodealliance/wasmtime/pull/3711) TODO: * [ ] Discussion of `SocketAddr` return value for `::accept()` ```rust Ok(( TcpStream::from_inner(unsafe { Socket::from_raw_fd(fd as _) }) // WASI has no concept of SocketAddr yet // return an unspecified IPv4Addr SocketAddr::new(Ipv4Addr::UNSPECIFIED.into() 0) )) ```,THUMBS_UP,2022-02-11T13:39:26Z,innobead,innobead@gmail.com https://github.com/rust-lang/rust/pull/93158,MERGED,2022-01-21T13:29:04Z,2022-01-29T02:20:04Z,wasi: implement `sock_accept` and enable networking,haraldh,9f15c4d08b7d5eec77f6a6e4caa2ee720fbc51c2,10,Rollup merge of #93158 - haraldh:wasi_sock_accept r=dtolnay wasi: implement `sock_accept` and enable networking With the addition of `sock_accept()` to snapshot1 simple networking via a passed `TcpListener` is possible. This PR implements the basics to make a simple server work. See also: * [wasmtime tracking issue](https://github.com/bytecodealliance/wasmtime/issues/3730) * [wasmtime PR](https://github.com/bytecodealliance/wasmtime/pull/3711) TODO: * [ ] Discussion of `SocketAddr` return value for `::accept()` ```rust Ok(( TcpStream::from_inner(unsafe { Socket::from_raw_fd(fd as _) }) // WASI has no concept of SocketAddr yet // return an unspecified IPv4Addr SocketAddr::new(Ipv4Addr::UNSPECIFIED.into() 0) )) ```,THUMBS_UP,2022-03-02T10:15:07Z,b-zee,NA https://github.com/rust-lang/rust/pull/93169,MERGED,2022-01-21T18:15:39Z,2022-01-25T08:18:30Z,rustdoc: Fix inconsistency of local blanket impls,CraftSpider,677126cac0d59c44d7448cc1e41b1e855380c6b3,3,Rollup merge of #93169 - CraftSpider:rustdoc-clean-inconsistency r=GuillaumeGomez Fix inconsistency of local blanket impls When a blanket impl is local go through HIR instead of middle. This fixes inconsistencies with data detected during JSON generation. Expected this change to take longer. I also tried doing the whole item through existing clean architecture but it didn't work out trivially and felt like it would have added more complexity than it removed. Properly fixes #83718,HEART,2022-01-21T18:56:09Z,Urgau,NA https://github.com/rust-lang/rust/pull/93169,MERGED,2022-01-21T18:15:39Z,2022-01-25T08:18:30Z,rustdoc: Fix inconsistency of local blanket impls,CraftSpider,677126cac0d59c44d7448cc1e41b1e855380c6b3,3,Rollup merge of #93169 - CraftSpider:rustdoc-clean-inconsistency r=GuillaumeGomez Fix inconsistency of local blanket impls When a blanket impl is local go through HIR instead of middle. This fixes inconsistencies with data detected during JSON generation. Expected this change to take longer. I also tried doing the whole item through existing clean architecture but it didn't work out trivially and felt like it would have added more complexity than it removed. Properly fixes #83718,HEART,2022-01-25T22:07:19Z,rrbutani,NA https://github.com/rust-lang/rust/pull/93169,MERGED,2022-01-21T18:15:39Z,2022-01-25T08:18:30Z,rustdoc: Fix inconsistency of local blanket impls,CraftSpider,677126cac0d59c44d7448cc1e41b1e855380c6b3,3,Rollup merge of #93169 - CraftSpider:rustdoc-clean-inconsistency r=GuillaumeGomez Fix inconsistency of local blanket impls When a blanket impl is local go through HIR instead of middle. This fixes inconsistencies with data detected during JSON generation. Expected this change to take longer. I also tried doing the whole item through existing clean architecture but it didn't work out trivially and felt like it would have added more complexity than it removed. Properly fixes #83718,HEART,2022-01-27T02:37:55Z,aDotInTheVoid,nixon.emoony@gmail.com https://github.com/rust-lang/rust/pull/93175,MERGED,2022-01-21T21:27:20Z,2022-01-25T08:18:30Z,Implement stable overlap check considering negative traits,spastorino,3d6f276ca71060a189fdbcb61b93750c2cb8c5a7,5,Rollup merge of #93175 - spastorino:negative-traits-coherence-new r=nikomatsakis Implement stable overlap check considering negative traits This PR implement the new disjointness rules for overlap check described in https://rust-lang.github.io/negative-impls-initiative/explainer/coherence-check.html#new-disjointness-rules r? ``@nikomatsakis``,THUMBS_UP,2022-01-21T21:37:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93175,MERGED,2022-01-21T21:27:20Z,2022-01-25T08:18:30Z,Implement stable overlap check considering negative traits,spastorino,3d6f276ca71060a189fdbcb61b93750c2cb8c5a7,5,Rollup merge of #93175 - spastorino:negative-traits-coherence-new r=nikomatsakis Implement stable overlap check considering negative traits This PR implement the new disjointness rules for overlap check described in https://rust-lang.github.io/negative-impls-initiative/explainer/coherence-check.html#new-disjointness-rules r? ``@nikomatsakis``,THUMBS_UP,2022-01-21T22:03:38Z,lqd,NA https://github.com/rust-lang/rust/pull/93175,MERGED,2022-01-21T21:27:20Z,2022-01-25T08:18:30Z,Implement stable overlap check considering negative traits,spastorino,3d6f276ca71060a189fdbcb61b93750c2cb8c5a7,5,Rollup merge of #93175 - spastorino:negative-traits-coherence-new r=nikomatsakis Implement stable overlap check considering negative traits This PR implement the new disjointness rules for overlap check described in https://rust-lang.github.io/negative-impls-initiative/explainer/coherence-check.html#new-disjointness-rules r? ``@nikomatsakis``,THUMBS_UP,2022-01-21T22:44:48Z,fmease,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-21T21:50:38Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T21:51:02Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T21:59:42Z,lqd,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T22:09:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T22:26:39Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-21T22:26:41Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T22:38:19Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T22:42:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T22:44:33Z,cramertj,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T23:25:26Z,tmandry,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-21T23:27:21Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-21T23:27:22Z,raftario,self@raftar.io https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-22T00:13:52Z,ecstatic-morse,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-22T01:29:25Z,taiki-e,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-22T01:47:47Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-22T01:47:47Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-22T08:41:04Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,EYES,2022-01-22T12:16:11Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-24T11:52:21Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-01-24T11:52:22Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-01-25T02:17:16Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-02-16T14:39:54Z,MattiasBuelens,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-02-22T13:09:03Z,aznhe21,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-02-24T03:38:01Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-02-24T10:27:00Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-03-15T15:06:59Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HOORAY,2022-05-04T01:13:58Z,zohnannor,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,HEART,2022-05-04T01:13:58Z,zohnannor,NA https://github.com/rust-lang/rust/pull/93176,MERGED,2022-01-21T21:40:46Z,2022-02-15T11:59:43Z,Add a stack-`pin!`-ning macro to `core::pin`.,danielhenrymantilla,6421a499a50adbaa7b5d0234bdd4817d970f0933,12,Auto merge of #93176 - danielhenrymantilla:stack-pinning-macro r=m-ou-se Add a stack-`pin!`-ning macro to `core::pin`. - https://github.com/rust-lang/rust/issues/93178 `pin!` allows pinning a value to the stack. Thanks to being implemented in the stdlib which gives access to `macro` macros and to the private `.pointer` field of the `Pin` wrapper [it was recently discovered](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/pin!.20.E2.80.94.20the.20.22definitive.22.20edition.20.28a.20rhs-compatible.20pin-nin.2E.2E.2E/near/268731241) ([archive link](https://zulip-archive.rust-lang.org/stream/187312-wg-async-foundations/topic/A.20rhs-compatible.20pin-ning.20macro.html#268731241)) contrary to popular belief that it is actually possible to implement and feature such a macro: ```rust let foo: Pin<&mut PhantomPinned> = pin!(PhantomPinned); stuff(foo); ``` or directly: ```rust stuff(pin!(PhantomPinned)); ``` - For context historically this used to require one of the two following syntaxes: - ```rust let foo = PhantomPinned; pin!(foo); stuff(foo); ``` - ```rust pin! { let foo = PhantomPinned; } stuff(foo); ``` This macro thus allows for instance doing things like: ```diff fn block_on(fut: impl Future) -> T { // Pin the future so it can be polled. - let mut fut = Box::pin(fut); + let mut fut = pin!(fut); // Create a new context to be passed to the future. let t = thread::current(); let waker = Arc::new(ThreadWaker(t)).into(); let mut cx = Context::from_waker(&waker); // Run the future to completion. loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(res) => return res Poll::Pending => thread::park() } } } ``` - _c.f._ https://doc.rust-lang.org/1.58.1/alloc/task/trait.Wake.html And so on and so forth. I don't think such an API can get better than that barring full featured language support (`&pin` references or something) so I see no reason not to start experimenting with featuring this in the stdlib already 🙂 - cc `@rust-lang/wg-async-foundations` \[EDIT: this doesn't seem to have pinged anybody 😩 thanks `@yoshuawuyts` for the real ping\] r? `@joshtriplett` ___ # Docs preview https://user-images.githubusercontent.com/9920355/150605731-1f45c2eb-c9b0-4ce3-b17f-2784fb75786e.mp4 ___ # Implementation The implementation ends up being dead simple (so much it's embarrassing): ```rust pub macro pin($value:expr $( )?) { Pin { pointer: &mut { $value } } } ``` _and voilà_! - The key for it working lies in [the rules governing the scope of anonymous temporaries](https://doc.rust-lang.org/1.58.1/reference/destructors.html#temporary-lifetime-extension).
Comments and context This is `Pin::new_unchecked(&mut { $value })` so for starters let's review such a hypothetical macro (that any user-code could define): ```rust macro_rules! pin {( $value:expr ) => ( match &mut { $value } { at_value => unsafe { // Do not wrap `$value` in an `unsafe` block. $crate::pin::Pin::<&mut _>::new_unchecked(at_value) }} )} ``` Safety: - `type P = &mut _`. There are thus no pathological `Deref{ Mut}` impls that would break `Pin`'s invariants. - `{ $value }` is braced making it a _block expression_ thus **moving** the given `$value` and making it _become an **anonymous** temporary_. By virtue of being anonynomous it can no longer be accessed thus preventing any attemps to `mem::replace` it or `mem::forget` it _etc._ This gives us a `pin!` definition that is sound and which works but only in certain scenarios: - If the `pin!(value)` expression is _directly_ fed to a function call: `let poll = pin!(fut).poll(cx);` - If the `pin!(value)` expression is part of a scrutinee: ```rust match pin!(fut) { pinned_fut => { pinned_fut.as_mut().poll(...); pinned_fut.as_mut().poll(...); }} // <- `fut` is dropped here. ``` Alas it doesn't work for the more straight-forward use-case: `let` bindings. ```rust let pinned_fut = pin!(fut); // <- temporary value is freed at the end of this statement pinned_fut.poll(...) // error[E0716]: temporary value dropped while borrowed // note: consider using a `let` binding to create a longer lived value ``` - Issues such as this one are the ones motivating https://github.com/rust-lang/rfcs/pull/66 This makes such a macro incredibly unergonomic in practice and the reason most macros out there had to take the path of being a statement/binding macro (_e.g._ `pin!(future);`) instead of featuring the more intuitive ergonomics of an expression macro. Luckily there is a way to avoid the problem. Indeed the problem stems from the fact that a temporary is dropped at the end of its enclosing statement when it is part of the parameters given to function call which has precisely been the case with our `Pin::new_unchecked()`! For instance ```rust let p = Pin::new_unchecked(&mut ); ``` becomes: ```rust let p = { let mut anon = ; &mut anon }; ``` However when using a literal braced struct to construct the value references to temporaries can then be taken. This makes Rust change the lifespan of such temporaries so that they are instead dropped _at the end of the enscoping block_. For instance ```rust let p = Pin { pointer: &mut }; ``` becomes: ```rust let mut anon = ; let p = Pin { pointer: &mut anon }; ``` which is *exactly* what we want. Finally we don't hit problems _w.r.t._ the privacy of the `pointer` field or the unqualified `Pin` name thanks to `decl_macro`s being _fully_ hygienic (`def_site` hygiene).
___ # TODO - [x] Add compile-fail tests with attempts to break the `Pin` invariants thanks to the macro (_e.g._ try to access the private `.pointer` field or see what happens if such a pin is used outside its enscoping scope (borrow error)); - [ ] Follow-up stuff: - [ ] Try to experiment with adding `pin!` to the prelude: this may require to be handled with some extra care as it may lead to issues reminiscent of those of `assert_matches!`: https://github.com/rust-lang/rust/issues/82913 - [x] Create the tracking issue.,EYES,2022-05-04T01:13:58Z,zohnannor,NA https://github.com/rust-lang/rust/pull/93181,CLOSED,2022-01-22T00:29:10Z,2022-03-20T05:24:10Z,Suggest `as_mut` when `Pin` is used after move,ibraheemdev,NA,NA,NA,HOORAY,2022-01-22T20:53:19Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/93181,CLOSED,2022-01-22T00:29:10Z,2022-03-20T05:24:10Z,Suggest `as_mut` when `Pin` is used after move,ibraheemdev,NA,NA,NA,HOORAY,2022-01-23T04:28:27Z,taiki-e,NA https://github.com/rust-lang/rust/pull/93181,CLOSED,2022-01-22T00:29:10Z,2022-03-20T05:24:10Z,Suggest `as_mut` when `Pin` is used after move,ibraheemdev,NA,NA,NA,HOORAY,2022-01-23T20:49:40Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93181,CLOSED,2022-01-22T00:29:10Z,2022-03-20T05:24:10Z,Suggest `as_mut` when `Pin` is used after move,ibraheemdev,NA,NA,NA,HOORAY,2022-01-24T06:37:15Z,Folyd,NA https://github.com/rust-lang/rust/pull/93181,CLOSED,2022-01-22T00:29:10Z,2022-03-20T05:24:10Z,Suggest `as_mut` when `Pin` is used after move,ibraheemdev,NA,NA,NA,HOORAY,2022-01-25T11:45:06Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/93186,MERGED,2022-01-22T03:54:18Z,2022-01-24T17:48:28Z,Fix link to CVE-2022-21658,kraai,8491fb3d3f723cb500527c5379f6cc52822309d2,1,Rollup merge of #93186 - kraai:fix-CVE-2022-21658-link r=m-ou-se Fix link to CVE-2022-21658 The link to CVE-2022-21658 contains a trailing bracket which causes it to link to .,THUMBS_UP,2022-01-22T04:18:07Z,pierwill,NA https://github.com/rust-lang/rust/pull/93186,MERGED,2022-01-22T03:54:18Z,2022-01-24T17:48:28Z,Fix link to CVE-2022-21658,kraai,8491fb3d3f723cb500527c5379f6cc52822309d2,1,Rollup merge of #93186 - kraai:fix-CVE-2022-21658-link r=m-ou-se Fix link to CVE-2022-21658 The link to CVE-2022-21658 contains a trailing bracket which causes it to link to .,THUMBS_UP,2022-01-23T18:42:38Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-01T14:27:41Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-03T05:22:06Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-03T10:29:16Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-03T12:46:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-08T13:12:45Z,realAP,NA https://github.com/rust-lang/rust/pull/93208,MERGED,2022-01-22T16:19:36Z,2022-02-07T18:30:32Z,Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0,kellerkindt,e3c972e2524319a1eec1bf905bf8aafa5cda7218,1,Rollup merge of #93208 - kellerkindt:wrapping_int_assign_impl r=m-ou-se Impl {Add Sub Mul Div Rem BitXor BitOr BitAnd}Assign<$t> for Wrapping<$t> for rust 1.60.0 Tracking issue #93204 This is about adding basic integer operations to the `Wrapping` type: ```rust let mut value = Wrapping(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` Because this adds stable impls on a stable type it runs into the following issue if an `#[unstable(...)]` attribute is used: ``` an `#[unstable]` annotation here has no effect note: see issue #55436 for more information ``` This means - if I understood this correctly - the new impls have to be stabilized instantly. Which in turn means this PR has to kick of an FCP on the tracking issue as well? This impl is analog to 1c0dc1810d778bb6fea16aac02cafc5aa2e84b11 #92356 for the `Saturating` type ``@dtolnay`` ``@Mark-Simulacrum``,THUMBS_UP,2022-02-17T08:45:06Z,AndyBarcia,NA https://github.com/rust-lang/rust/pull/93214,MERGED,2022-01-22T20:45:42Z,2022-01-31T14:23:54Z,Respect doc(hidden) when suggesting available fields,ibraheemdev,7de90d5b6506f702c36ea20f46f92c3f8808668a,3,Rollup merge of #93214 - ibraheemdev:issue-93210 r=davidtwco Respect doc(hidden) when suggesting available fields Resolves #93210,HOORAY,2022-01-31T12:14:19Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/93221,MERGED,2022-01-23T00:10:12Z,2022-02-02T22:03:37Z,[borrowck] Fix help on mutating &self in async fns,alyssaverkade,b622552e1002739a279a1e3a151ca2a241c94ead,3,Rollup merge of #93221 - alyssaverkade:fix-93093 r=wesleywiser [borrowck] Fix help on mutating &self in async fns Previously when rustc was provided an async function that tried to mutate through a shared reference to an implicit self (as shown in the ui test) rustc would suggest modifying the parameter signature to `&mut` + the fully qualified name of the ty (in the case of the repro `S`). If a user modified their code to match the suggestion the compiler would not accept it. This commit modifies the suggestion so that when rustc is provided the ui test that is also attached in this commit it suggests (correctly) `&mut self`. We try to be careful about distinguishing between implicit and explicit self annotations since the latter seem to be handled correctly already. This is my first PR here so I'm pretty sure I probably missed something/could use better terminology. I also didn't try to make the match exhaustive since implicit self is the only real special case that I need to handle (that I'm aware of) and I'm pretty sure there's a cleaner way to do this so any advice would be greatly appreciated! (I'm also not terribly confident about how I wrote the ui tests) here is your cc as requested `@compiler-errors` This is an attempt to fix #93093,HEART,2022-02-03T17:58:12Z,tmandry,NA https://github.com/rust-lang/rust/pull/93222,MERGED,2022-01-23T00:54:19Z,2022-03-18T03:01:56Z,Make ErrorReported impossible to construct outside `rustc_errors`,mark-i-m,7e1415ea80bedaf5b27900aaecc0d5cbc8ce7434,104,Rollup merge of #93222 - mark-i-m:errorreported r=oli-obk Make ErrorReported impossible to construct outside `rustc_errors` There are a few places were we have to construct it though and a few places that are more invasive to change. To do this we create a constructor with a long obvious name. cc #69426 `@varkor` `@eddyb` `@estebank` I actually didn't see that I was assigned to this issue until now...,HOORAY,2022-01-23T07:47:28Z,oli-obk,NA https://github.com/rust-lang/rust/pull/93222,MERGED,2022-01-23T00:54:19Z,2022-03-18T03:01:56Z,Make ErrorReported impossible to construct outside `rustc_errors`,mark-i-m,7e1415ea80bedaf5b27900aaecc0d5cbc8ce7434,104,Rollup merge of #93222 - mark-i-m:errorreported r=oli-obk Make ErrorReported impossible to construct outside `rustc_errors` There are a few places were we have to construct it though and a few places that are more invasive to change. To do this we create a constructor with a long obvious name. cc #69426 `@varkor` `@eddyb` `@estebank` I actually didn't see that I was assigned to this issue until now...,HOORAY,2022-03-04T02:28:20Z,estebank,NA https://github.com/rust-lang/rust/pull/93231,MERGED,2022-01-23T09:13:19Z,2022-01-24T17:48:27Z,adjust sidebar link brightness,conradludgate,ed1fea8571134039ed08b708cb3db72e336e05b7,5,Rollup merge of #93231 - conradludgate:doc-link-brightness r=notriddle adjust sidebar link brightness Fairly simple change. I've taken the existing link colour and main body background colours and made sure that the sidebar+link contrast is the same. ayu: - [main content contrast](https://colourcontrast.cc/0f1419/39afd7) - 7.31 - [current sidebar contrast](https://colourcontrast.cc/14191f/39afd7) - 6.97 - [new sidebar contrast](https://colourcontrast.cc/14191f/56b1d9) - 7.30 dark: - [main content contrast](https://colourcontrast.cc/353535/d2991d) - 4.86 - [current sidebar contrast](https://colourcontrast.cc/14191f/d2991d) - 3.19 - [new sidebar contrast](https://colourcontrast.cc/14191f/fdbf35) - 4.87 light: - [main content contrast](https://colourcontrast.cc/ffffff/3873ad) - 4.97 - [current sidebar contrast](https://colourcontrast.cc/f5f5f5/3873ad) - 4.56 - [new sidebar contrast](https://colourcontrast.cc/f5f5f5/356da4) - 4.97,HEART,2022-01-25T00:17:07Z,kafji,k+github@kafji.net https://github.com/rust-lang/rust/pull/93243,OPEN,2022-01-23T17:56:33Z,NA,Use TrustedRandomAccess for loop desugaring,the8472,NA,NA,NA,EYES,2022-01-23T18:02:37Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93244,MERGED,2022-01-23T18:38:38Z,2022-03-02T18:37:40Z,Rename `ErrorReported` -> `ErrorGuaranteed`,mark-i-m,08504c64aa7c4163a51c1982ed10075bb89cec0e,112,Auto merge of #93244 - mark-i-m:doomed r=oli-obk Rename `ErrorReported` -> `ErrorGuaranteed` r? `@eddyb` cc https://github.com/rust-lang/rust/pull/93222 https://github.com/rust-lang/rust/issues/69426 The idea is that we would like to use it for both errors and `delay_span_bug`. Its semantics indicate a _guarantee_ that compilation will fail.,LAUGH,2022-01-23T18:46:13Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93244,MERGED,2022-01-23T18:38:38Z,2022-03-02T18:37:40Z,Rename `ErrorReported` -> `ErrorGuaranteed`,mark-i-m,08504c64aa7c4163a51c1982ed10075bb89cec0e,112,Auto merge of #93244 - mark-i-m:doomed r=oli-obk Rename `ErrorReported` -> `ErrorGuaranteed` r? `@eddyb` cc https://github.com/rust-lang/rust/pull/93222 https://github.com/rust-lang/rust/issues/69426 The idea is that we would like to use it for both errors and `delay_span_bug`. Its semantics indicate a _guarantee_ that compilation will fail.,LAUGH,2022-01-23T18:54:22Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93244,MERGED,2022-01-23T18:38:38Z,2022-03-02T18:37:40Z,Rename `ErrorReported` -> `ErrorGuaranteed`,mark-i-m,08504c64aa7c4163a51c1982ed10075bb89cec0e,112,Auto merge of #93244 - mark-i-m:doomed r=oli-obk Rename `ErrorReported` -> `ErrorGuaranteed` r? `@eddyb` cc https://github.com/rust-lang/rust/pull/93222 https://github.com/rust-lang/rust/issues/69426 The idea is that we would like to use it for both errors and `delay_span_bug`. Its semantics indicate a _guarantee_ that compilation will fail.,LAUGH,2022-01-23T21:59:18Z,lqd,NA https://github.com/rust-lang/rust/pull/93255,CLOSED,2022-01-24T08:14:44Z,2022-03-27T14:48:52Z,Experiment: mark derived Clone impls as const,clarfonthey,NA,NA,NA,ROCKET,2022-01-24T15:49:22Z,fmease,NA https://github.com/rust-lang/rust/pull/93263,MERGED,2022-01-24T13:32:18Z,2022-03-19T05:04:08Z,Consistently present absent stdio handles on Windows as NULL handles.,sunfishcode,fe55eee9a55a1019a2398d22b91bc201e3d4fb94,3,"Rollup merge of #93263 - sunfishcode:sunfishcode/detatched-console-handle r=dtolnay Consistently present absent stdio handles on Windows as NULL handles. This addresses #90964 by making the std API consistent about presenting absent stdio handles on Windows as NULL handles. Stdio handles may be absent due to `#![windows_subsystem = ""windows""]` due to the console being detached or due to a child process having been launched from a parent where stdio handles are absent. Specifically this fixes the case of child processes of parents with absent stdio which previously ended up with `stdin().as_raw_handle()` returning `INVALID_HANDLE_VALUE` which was surprising and which overlapped with an unrelated valid handle value. With this patch `stdin().as_raw_handle()` now returns null in these situation which is consistent with what it does in the parent process. And document this in the ""Windows Portability Considerations"" sections of the relevant documentation.",HEART,2022-01-24T14:08:03Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/93290,MERGED,2022-01-25T07:45:49Z,2022-02-01T20:05:50Z,remove `TyS::same_type`,lcnr,724ce3798fcbc81e67edcacc0944950f74435653,22,Rollup merge of #93290 - lcnr:same_type r=jackh726 remove `TyS::same_type` This function ignored regions and constants in adts but didn't do so for references or any other types. cc https://github.com/rust-lang/rust/pull/93148#discussion_r791408057,THUMBS_UP,2022-01-25T08:46:41Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/93290,MERGED,2022-01-25T07:45:49Z,2022-02-01T20:05:50Z,remove `TyS::same_type`,lcnr,724ce3798fcbc81e67edcacc0944950f74435653,22,Rollup merge of #93290 - lcnr:same_type r=jackh726 remove `TyS::same_type` This function ignored regions and constants in adts but didn't do so for references or any other types. cc https://github.com/rust-lang/rust/pull/93148#discussion_r791408057,THUMBS_UP,2022-01-26T19:18:35Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93292,MERGED,2022-01-25T08:07:18Z,2022-03-13T23:06:15Z,Implement `BITS` constant for non-zero integers,nvzqz,2f9bc56e5a21534326f4483f3f6381175ada2cea,1,Rollup merge of #93292 - nvzqz:nonzero-bits r=dtolnay Implement `BITS` constant for non-zero integers This adds the associated [`BITS`](https://doc.rust-lang.org/stable/std/primitive.usize.html#associatedconstant.BITS) constant to `NonZero{U I}{8 16 32 64 128 size}`. This is useful when a type alias refers to either a regular or non-zero integer.,THUMBS_UP,2022-03-17T00:50:34Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/93292,MERGED,2022-01-25T08:07:18Z,2022-03-13T23:06:15Z,Implement `BITS` constant for non-zero integers,nvzqz,2f9bc56e5a21534326f4483f3f6381175ada2cea,1,Rollup merge of #93292 - nvzqz:nonzero-bits r=dtolnay Implement `BITS` constant for non-zero integers This adds the associated [`BITS`](https://doc.rust-lang.org/stable/std/primitive.usize.html#associatedconstant.BITS) constant to `NonZero{U I}{8 16 32 64 128 size}`. This is useful when a type alias refers to either a regular or non-zero integer.,THUMBS_UP,2022-03-17T08:51:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93292,MERGED,2022-01-25T08:07:18Z,2022-03-13T23:06:15Z,Implement `BITS` constant for non-zero integers,nvzqz,2f9bc56e5a21534326f4483f3f6381175ada2cea,1,Rollup merge of #93292 - nvzqz:nonzero-bits r=dtolnay Implement `BITS` constant for non-zero integers This adds the associated [`BITS`](https://doc.rust-lang.org/stable/std/primitive.usize.html#associatedconstant.BITS) constant to `NonZero{U I}{8 16 32 64 128 size}`. This is useful when a type alias refers to either a regular or non-zero integer.,THUMBS_UP,2022-03-17T12:36:50Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/93301,MERGED,2022-01-25T18:06:41Z,2022-01-26T22:54:30Z,Store hir_id_to_def_id in OwnerInfo.,spastorino,6abb6385b2cb7249f67b9b3ce7522527767dd907,10,Auto merge of #93301 - spastorino:perf-test-1 r=oli-obk Store hir_id_to_def_id in OwnerInfo. This is for perf test purposes only. Related to #89278,ROCKET,2022-01-25T18:25:18Z,estebank,NA https://github.com/rust-lang/rust/pull/93328,CLOSED,2022-01-26T14:21:02Z,2022-01-26T22:03:59Z,Check attributes when needed only for determining overlap mode,spastorino,NA,NA,NA,THUMBS_UP,2022-01-26T15:03:18Z,Agrailag,NA https://github.com/rust-lang/rust/pull/93353,MERGED,2022-01-26T22:50:57Z,2022-01-29T02:20:04Z,Unimpl {Add Sub Mul Div Rem BitXor BitOr BitAnd}<$t> for Saturating<$t>,kellerkindt,25cd639a4b4d67d056e7a8dd3218c89b40af34f4,1,Rollup merge of #93353 - kellerkindt:saturating_int_assign_impl r=joshtriplett Unimpl {Add Sub Mul Div Rem BitXor BitOr BitAnd}<$t> for Saturating<$t> Tracking issue #92354 Analog to 9648b313cc8896970a12f45b3bb5c0593c3d510f #93208 reduce `saturating_int_assign_impl` (#93208) to: ```rust let mut value = Saturating(2u8); value += 3u8; value -= 1u8; value *= 2u8; value /= 2u8; value %= 2u8; value ^= 255u8; value |= 123u8; value &= 2u8; ``` See https://github.com/rust-lang/rust/pull/93208#issuecomment-1022564429,THUMBS_UP,2022-01-28T09:20:11Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/93357,MERGED,2022-01-27T03:04:23Z,2022-01-28T01:33:05Z,Clarify the `usage-of-qualified-ty` error message.,nnethercote,5d79874e79403a1dd629ab82f5f729be2240c5bd,2,Rollup merge of #93357 - nnethercote:clarify-usage-of-qualified-ty r=lcnr Clarify the `usage-of-qualified-ty` error message. I found this message confusing when I encountered it. This commit makes it clearer that you have to import the unqualified type yourself. r? `@lcnr`,THUMBS_UP,2022-01-27T03:30:30Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93359,CLOSED,2022-01-27T03:53:29Z,2022-06-20T06:20:53Z,Add ReadBufRef,DrMeepster,NA,NA,NA,THUMBS_UP,2022-01-27T11:20:54Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/93359,CLOSED,2022-01-27T03:53:29Z,2022-06-20T06:20:53Z,Add ReadBufRef,DrMeepster,NA,NA,NA,THUMBS_UP,2022-01-29T02:56:23Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93361,CLOSED,2022-01-27T05:51:14Z,2022-03-08T03:40:14Z,Normalize possibly un-normalized GAT projections,compiler-errors,NA,NA,NA,THUMBS_UP,2022-01-27T07:03:45Z,skyzh,iskyzh@gmail.com https://github.com/rust-lang/rust/pull/93362,MERGED,2022-01-27T06:45:35Z,2022-01-30T13:38:16Z,Do not register infer var for GAT projection in RPIT,compiler-errors,4484165cbd729907e5ee3a4b09d3012e1908f25c,2,Rollup merge of #93362 - compiler-errors:ice-gat-in-rpit r=oli-obk Do not register infer var for GAT projection in RPIT Fixes #93340 Fixes #91603 r? ```@oli-obk```,THUMBS_UP,2022-01-27T06:59:12Z,skyzh,iskyzh@gmail.com https://github.com/rust-lang/rust/pull/93368,MERGED,2022-01-27T10:43:58Z,2022-02-25T03:16:25Z,"rustc_errors: let `DiagnosticBuilder::emit` return a ""guarantee of emission"".",eddyb,d4de1f230ca30b7ce08fbf453daebf8b2e7ffcc9,134,"Auto merge of #93368 - eddyb:diagbld-guarantee r=estebank rustc_errors: let `DiagnosticBuilder::emit` return a ""guarantee of emission"". That is `DiagnosticBuilder` is now generic over the return type of `.emit()` so we'll now have: * `DiagnosticBuilder` for error (incl. fatal/bug) diagnostics * can only be created via a `const L: Level`-generic constructor that limits allowed variants via a `where` clause so not even `rustc_errors` can accidentally bypass this limitation * asserts `diagnostic.is_error()` on emission just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`) * `.emit()` returns `ErrorReported` as a ""proof"" token that `.emit()` was called (though note that this isn't a real guarantee until after completing the work on #69426) * `DiagnosticBuilder<()>` for everything else (warnings notes etc.) * can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()` This PR is a companion to other ongoing work namely: * #69426 and it's ongoing implementation: #93222 the API changes in this PR are needed to get statically-checked ""only errors produce `ErrorReported` from `.emit()`"" but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes * #93244 would make the choices of API changes (esp. naming) in this PR fit better overall In order to be able to let `.emit()` return anything trustable several changes had to be made: * `Diagnostic`'s `level` field is now private to `rustc_errors` to disallow arbitrary ""downgrade""s from ""some kind of error"" to ""warning"" (or anything else that doesn't cause compilation to fail) * it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder` sadly that's harder to fix but it's unlikely enough that we can paper over it with asserts on `.emit()` * `.cancel()` now consumes `DiagnosticBuilder` preventing `.emit()` calls on a cancelled diagnostic * it's also now done internally through `DiagnosticBuilder`-private state instead of having a `Level::Cancelled` variant that can be read (or worse written) by the user * this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it and even expect to be able to `.emit()` it * warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early) * `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`) * since `.emit()` doesn't consume the `DiagnosticBuilder` (I tried and gave up it's much more work than this PR) we have to make `.emit()` idempotent wrt the guarantees it returns * thankfully `err.emit(); err.emit();` can return `ErrorReported` both times as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission * `&mut Diagnostic` is now used in a lot of function signatures which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic) * the APIs were already mostly identical allowing for low-effort porting to this new setup * only some of the suggestion methods needed some rework to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259) * `.emit()`/`.cancel()` aren't available but IMO calling them from an ""error decorator/annotator"" function isn't a good practice and can lead to strange behavior (from the caller's perspective) * `.downgrade_to_delayed_bug()` was added letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same) This PR should ideally be reviewed commit-by-commit since there is a lot of fallout in each. r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`",HEART,2022-02-17T15:44:00Z,estebank,NA https://github.com/rust-lang/rust/pull/93368,MERGED,2022-01-27T10:43:58Z,2022-02-25T03:16:25Z,"rustc_errors: let `DiagnosticBuilder::emit` return a ""guarantee of emission"".",eddyb,d4de1f230ca30b7ce08fbf453daebf8b2e7ffcc9,134,"Auto merge of #93368 - eddyb:diagbld-guarantee r=estebank rustc_errors: let `DiagnosticBuilder::emit` return a ""guarantee of emission"". That is `DiagnosticBuilder` is now generic over the return type of `.emit()` so we'll now have: * `DiagnosticBuilder` for error (incl. fatal/bug) diagnostics * can only be created via a `const L: Level`-generic constructor that limits allowed variants via a `where` clause so not even `rustc_errors` can accidentally bypass this limitation * asserts `diagnostic.is_error()` on emission just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`) * `.emit()` returns `ErrorReported` as a ""proof"" token that `.emit()` was called (though note that this isn't a real guarantee until after completing the work on #69426) * `DiagnosticBuilder<()>` for everything else (warnings notes etc.) * can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()` This PR is a companion to other ongoing work namely: * #69426 and it's ongoing implementation: #93222 the API changes in this PR are needed to get statically-checked ""only errors produce `ErrorReported` from `.emit()`"" but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes * #93244 would make the choices of API changes (esp. naming) in this PR fit better overall In order to be able to let `.emit()` return anything trustable several changes had to be made: * `Diagnostic`'s `level` field is now private to `rustc_errors` to disallow arbitrary ""downgrade""s from ""some kind of error"" to ""warning"" (or anything else that doesn't cause compilation to fail) * it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder` sadly that's harder to fix but it's unlikely enough that we can paper over it with asserts on `.emit()` * `.cancel()` now consumes `DiagnosticBuilder` preventing `.emit()` calls on a cancelled diagnostic * it's also now done internally through `DiagnosticBuilder`-private state instead of having a `Level::Cancelled` variant that can be read (or worse written) by the user * this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it and even expect to be able to `.emit()` it * warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early) * `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`) * since `.emit()` doesn't consume the `DiagnosticBuilder` (I tried and gave up it's much more work than this PR) we have to make `.emit()` idempotent wrt the guarantees it returns * thankfully `err.emit(); err.emit();` can return `ErrorReported` both times as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission * `&mut Diagnostic` is now used in a lot of function signatures which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic) * the APIs were already mostly identical allowing for low-effort porting to this new setup * only some of the suggestion methods needed some rework to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259) * `.emit()`/`.cancel()` aren't available but IMO calling them from an ""error decorator/annotator"" function isn't a good practice and can lead to strange behavior (from the caller's perspective) * `.downgrade_to_delayed_bug()` was added letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same) This PR should ideally be reviewed commit-by-commit since there is a lot of fallout in each. r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`",HEART,2022-02-23T04:23:46Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93381,MERGED,2022-01-27T16:25:24Z,2022-02-01T00:13:53Z,Check the number of arguments first in `is_recursive_call`,tmiasko,745e9264873ab001a189f739446c86c509e6dc3d,1,Auto merge of #93381 - tmiasko:is-self-recursive r=ecstatic-morse Check the number of arguments first in `is_recursive_call`,THUMBS_UP,2022-01-27T21:30:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,HEART,2022-01-28T01:43:08Z,fmease,NA https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,THUMBS_UP,2022-01-28T01:43:10Z,fmease,NA https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,THUMBS_UP,2022-01-28T13:08:17Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,HEART,2022-01-28T13:08:18Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,THUMBS_UP,2022-01-30T16:56:14Z,est31,NA https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,HEART,2022-01-30T16:56:15Z,est31,NA https://github.com/rust-lang/rust/pull/93394,MERGED,2022-01-27T22:52:14Z,2022-02-07T18:30:32Z,Don't allow {} to refer to implicit captures in format_args.,m-ou-se,4445a8ff84e1d729df1b0320760bd8f5dd618e78,4,Rollup merge of #93394 - m-ou-se:fix-93378 r=estebank Don't allow {} to refer to implicit captures in format_args. Fixes #93378,THUMBS_UP,2022-02-02T22:54:05Z,estebank,NA https://github.com/rust-lang/rust/pull/93395,MERGED,2022-01-27T22:54:11Z,2022-01-31T11:24:09Z,Improve suggestion for escaping reserved keywords,camelid,2f4602a64cf20a3f22d4a4958910d3698401e8cc,51,Rollup merge of #93395 - camelid:reserved-sugg r=davidtwco Improve suggestion for escaping reserved keywords r? `@davidtwco`,HEART,2022-02-03T18:13:40Z,estebank,NA https://github.com/rust-lang/rust/pull/93397,OPEN,2022-01-27T23:35:45Z,NA,Add `[f32]::sort_floats` and `[f64]::sort_floats`,joshtriplett,NA,NA,NA,EYES,2022-02-03T03:29:31Z,jeremyBanks,_@jeremy.ca https://github.com/rust-lang/rust/pull/93402,MERGED,2022-01-28T01:07:23Z,2022-02-04T17:40:08Z,Windows: Disable LLVM crash dialog boxes.,ehuss,f7e0f9763128603d2249d3cb1c41a23f261d6e1e,3,"Rollup merge of #93402 - ehuss:llvm-dialog r=michaelwoerister Windows: Disable LLVM crash dialog boxes. This disables the crash dialog box on Windows. When LLVM hits an assertion it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours). Instead of opening a dialog box it will print a message like this: ``` Assertion failed: isa(Val) && ""cast() argument of incompatible type!"" file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h line 255 ``` Closes #92829",THUMBS_UP,2022-01-28T03:36:26Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93402,MERGED,2022-01-28T01:07:23Z,2022-02-04T17:40:08Z,Windows: Disable LLVM crash dialog boxes.,ehuss,f7e0f9763128603d2249d3cb1c41a23f261d6e1e,3,"Rollup merge of #93402 - ehuss:llvm-dialog r=michaelwoerister Windows: Disable LLVM crash dialog boxes. This disables the crash dialog box on Windows. When LLVM hits an assertion it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours). Instead of opening a dialog box it will print a message like this: ``` Assertion failed: isa(Val) && ""cast() argument of incompatible type!"" file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h line 255 ``` Closes #92829",THUMBS_UP,2022-01-28T04:04:43Z,hkratz,NA https://github.com/rust-lang/rust/pull/93402,MERGED,2022-01-28T01:07:23Z,2022-02-04T17:40:08Z,Windows: Disable LLVM crash dialog boxes.,ehuss,f7e0f9763128603d2249d3cb1c41a23f261d6e1e,3,"Rollup merge of #93402 - ehuss:llvm-dialog r=michaelwoerister Windows: Disable LLVM crash dialog boxes. This disables the crash dialog box on Windows. When LLVM hits an assertion it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours). Instead of opening a dialog box it will print a message like this: ``` Assertion failed: isa(Val) && ""cast() argument of incompatible type!"" file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h line 255 ``` Closes #92829",THUMBS_UP,2022-01-28T09:06:13Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93402,MERGED,2022-01-28T01:07:23Z,2022-02-04T17:40:08Z,Windows: Disable LLVM crash dialog boxes.,ehuss,f7e0f9763128603d2249d3cb1c41a23f261d6e1e,3,"Rollup merge of #93402 - ehuss:llvm-dialog r=michaelwoerister Windows: Disable LLVM crash dialog boxes. This disables the crash dialog box on Windows. When LLVM hits an assertion it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours). Instead of opening a dialog box it will print a message like this: ``` Assertion failed: isa(Val) && ""cast() argument of incompatible type!"" file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h line 255 ``` Closes #92829",HEART,2022-01-29T01:09:59Z,Patrick-Poitras,NA https://github.com/rust-lang/rust/pull/93403,MERGED,2022-01-28T01:31:10Z,2022-01-31T11:24:09Z,review the total_cmp documentation,nagisa,8fd2ff57fa936f1fb24afe1f452e8d2ef9b485d6,2,Rollup merge of #93403 - nagisa:total-cmp-review r=joshtriplett review the total_cmp documentation The documentation has been restructured to split out a brief summary paragraph out from the following elaborating paragraphs. I also attempted my hand at wording improvements and adding articles where I felt them missing but being non-native english speaker these may need more thorough review. cc https://github.com/rust-lang/rust/issues/72599,HEART,2022-01-28T10:40:15Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93403,MERGED,2022-01-28T01:31:10Z,2022-01-31T11:24:09Z,review the total_cmp documentation,nagisa,8fd2ff57fa936f1fb24afe1f452e8d2ef9b485d6,2,Rollup merge of #93403 - nagisa:total-cmp-review r=joshtriplett review the total_cmp documentation The documentation has been restructured to split out a brief summary paragraph out from the following elaborating paragraphs. I also attempted my hand at wording improvements and adding articles where I felt them missing but being non-native english speaker these may need more thorough review. cc https://github.com/rust-lang/rust/issues/72599,HEART,2022-02-26T19:05:09Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/93405,CLOSED,2022-01-28T01:39:17Z,2022-02-01T17:44:33Z,Don't over-optimize the abi layout,Urgau,NA,NA,NA,THUMBS_UP,2022-01-28T10:34:13Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93416,MERGED,2022-01-28T10:33:07Z,2022-02-07T18:30:32Z,remove `allow_fail` test flag,name1e5s,252ff5ead0ee32b2849570bb9cddf64a7f1b1f9c,25,Rollup merge of #93416 - name1e5s:chore/remove_allow_fail r=m-ou-se remove `allow_fail` test flag close #93345,HEART,2022-02-07T20:48:22Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/93434,MERGED,2022-01-28T17:30:41Z,2022-01-29T05:04:48Z,Move tier-2 (without host tools) apple targets to separate builder,Mark-Simulacrum,24ae9960c5116a6d1e827c58327e6d231e4fe174,2,Auto merge of #93434 - Mark-Simulacrum:apple-various r=pietroalbini Move tier-2 (without host tools) apple targets to separate builder One-off (likely fairly unreliable but give some idea) measurements: * dist-apple-various (new): 2h10m * dist-x86_64-apple: 2h55m -> 2h36m (cutting roughly 20 minutes),HEART,2022-01-28T17:32:38Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93434,MERGED,2022-01-28T17:30:41Z,2022-01-29T05:04:48Z,Move tier-2 (without host tools) apple targets to separate builder,Mark-Simulacrum,24ae9960c5116a6d1e827c58327e6d231e4fe174,2,Auto merge of #93434 - Mark-Simulacrum:apple-various r=pietroalbini Move tier-2 (without host tools) apple targets to separate builder One-off (likely fairly unreliable but give some idea) measurements: * dist-apple-various (new): 2h10m * dist-x86_64-apple: 2h55m -> 2h36m (cutting roughly 20 minutes),HEART,2022-01-28T18:10:33Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93434,MERGED,2022-01-28T17:30:41Z,2022-01-29T05:04:48Z,Move tier-2 (without host tools) apple targets to separate builder,Mark-Simulacrum,24ae9960c5116a6d1e827c58327e6d231e4fe174,2,Auto merge of #93434 - Mark-Simulacrum:apple-various r=pietroalbini Move tier-2 (without host tools) apple targets to separate builder One-off (likely fairly unreliable but give some idea) measurements: * dist-apple-various (new): 2h10m * dist-x86_64-apple: 2h55m -> 2h36m (cutting roughly 20 minutes),HEART,2022-01-28T21:43:00Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/93439,MERGED,2022-01-28T19:17:43Z,2022-02-15T23:48:46Z,Add support for control-flow protection,abrown,09cb29c64c2a0e15debf2d6fca2bc7c71a682033,5,Auto merge of #93439 - abrown:cf-protection r=nagisa Add support for control-flow protection This change adds a flag for configuring control-flow protection in the LLVM backend. In Clang this flag is exposed as `-fcf-protection` with options `none|branch|return|full`. This convention is followed for `rustc` though as a codegen option: `rustc -Z cf-protection=`. Tracking issue for future work is #93754.,HOORAY,2022-02-08T21:11:14Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93441,MERGED,2022-01-28T19:24:33Z,2022-01-30T13:38:15Z,rustdoc: load the set of in-scope traits for modules with no docstring,notriddle,605ffd6113dc49a9b10ea2b5aa6ca41a275bb9ad,4,Rollup merge of #93441 - notriddle:notriddle/collect-crate-doc-links-very-early r=petrochenkov rustdoc: load the set of in-scope traits for modules with no docstring Fixes #93428 This fix is a response to a couple of special cases related to the `module_id` which is eventually used for trait candidates: * The module id is always set to the current crate when checking `crate::`. Normally the set of in-scope traits would be set in `load_links_in_attrs` but if there are no doc comments then that loop will never run. * the module id is set to the parent module when resolving a module that is spelled like this: // Notice how we use an outlined doc comment here! // [`Test::my_fn`] mod something { } As with the above problem with `crate::` we need to make sure the module gets its traits in scope resolved even if it has no doc comments of its own.,HEART,2022-01-29T00:17:53Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/93442,MERGED,2022-01-28T21:02:16Z,2022-02-01T23:18:05Z,Change Termination::report return type to ExitCode,yaahc,2681f253bcdb31a274411d2be456e7c6a1c67d62,3,Auto merge of #93442 - yaahc:Termination-abstraction r=Mark-Simulacrum Change Termination::report return type to ExitCode Related to https://github.com/rust-lang/rust/issues/43301 The goal of this change is to minimize the forward compatibility risks in stabilizing Termination. By using the opaque type `ExitCode` instead of an `i32` we leave room for us to evolve the API over time to provide what cross-platform consistency we can / minimize footguns when working with exit codes where as stabilizing on `i32` would limit what changes we could make in the future in how we represent and construct exit codes.,THUMBS_UP,2022-01-28T21:08:42Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93442,MERGED,2022-01-28T21:02:16Z,2022-02-01T23:18:05Z,Change Termination::report return type to ExitCode,yaahc,2681f253bcdb31a274411d2be456e7c6a1c67d62,3,Auto merge of #93442 - yaahc:Termination-abstraction r=Mark-Simulacrum Change Termination::report return type to ExitCode Related to https://github.com/rust-lang/rust/issues/43301 The goal of this change is to minimize the forward compatibility risks in stabilizing Termination. By using the opaque type `ExitCode` instead of an `i32` we leave room for us to evolve the API over time to provide what cross-platform consistency we can / minimize footguns when working with exit codes where as stabilizing on `i32` would limit what changes we could make in the future in how we represent and construct exit codes.,THUMBS_UP,2022-01-29T01:28:05Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/93445,MERGED,2022-01-28T22:09:34Z,2022-02-09T09:41:53Z,Add From for ExitCode,yaahc,ec2fd8a35fcd271458dc5fa462ef74bcb372f6c7,4,Rollup merge of #93445 - yaahc:exitcode-constructor r=dtolnay Add From for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no` so there's some ambiguity there when returning exit codes > 127 but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - https://github.com/rust-lang/rust/issues/48711 - https://github.com/rust-lang/rust/issues/43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization,HEART,2022-01-28T22:53:30Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93445,MERGED,2022-01-28T22:09:34Z,2022-02-09T09:41:53Z,Add From for ExitCode,yaahc,ec2fd8a35fcd271458dc5fa462ef74bcb372f6c7,4,Rollup merge of #93445 - yaahc:exitcode-constructor r=dtolnay Add From for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no` so there's some ambiguity there when returning exit codes > 127 but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - https://github.com/rust-lang/rust/issues/48711 - https://github.com/rust-lang/rust/issues/43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization,HEART,2022-01-29T00:38:36Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93445,MERGED,2022-01-28T22:09:34Z,2022-02-09T09:41:53Z,Add From for ExitCode,yaahc,ec2fd8a35fcd271458dc5fa462ef74bcb372f6c7,4,Rollup merge of #93445 - yaahc:exitcode-constructor r=dtolnay Add From for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no` so there's some ambiguity there when returning exit codes > 127 but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - https://github.com/rust-lang/rust/issues/48711 - https://github.com/rust-lang/rust/issues/43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization,HEART,2022-01-29T01:29:09Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/93445,MERGED,2022-01-28T22:09:34Z,2022-02-09T09:41:53Z,Add From for ExitCode,yaahc,ec2fd8a35fcd271458dc5fa462ef74bcb372f6c7,4,Rollup merge of #93445 - yaahc:exitcode-constructor r=dtolnay Add From for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no` so there's some ambiguity there when returning exit codes > 127 but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - https://github.com/rust-lang/rust/issues/48711 - https://github.com/rust-lang/rust/issues/43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization,HEART,2022-02-01T16:45:32Z,Techie-Pi,NA https://github.com/rust-lang/rust/pull/93445,MERGED,2022-01-28T22:09:34Z,2022-02-09T09:41:53Z,Add From for ExitCode,yaahc,ec2fd8a35fcd271458dc5fa462ef74bcb372f6c7,4,Rollup merge of #93445 - yaahc:exitcode-constructor r=dtolnay Add From for ExitCode This should cover a mostly cross-platform subset of supported exit codes. We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no` so there's some ambiguity there when returning exit codes > 127 but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`. ## Related - Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426 - https://github.com/rust-lang/rust/issues/48711 - https://github.com/rust-lang/rust/issues/43301 - https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization,HEART,2022-02-03T12:45:26Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93460,CLOSED,2022-01-29T18:34:33Z,2022-06-20T21:46:36Z,compiletest: Set RUST_BACKTRACE=1 to make compiler panics easier to debug,joshtriplett,NA,NA,NA,HEART,2022-01-29T18:45:08Z,bjorn3,NA https://github.com/rust-lang/rust/pull/93460,CLOSED,2022-01-29T18:34:33Z,2022-06-20T21:46:36Z,compiletest: Set RUST_BACKTRACE=1 to make compiler panics easier to debug,joshtriplett,NA,NA,NA,HEART,2022-02-27T20:19:16Z,mati865,NA https://github.com/rust-lang/rust/pull/93461,MERGED,2022-01-29T20:39:09Z,2022-01-31T11:24:08Z,Accommodate yield points in the format_args expansion,dtolnay,c1e2948c21398d98ada51f27bd9fa3ada439e03d,2,"Rollup merge of #93461 - dtolnay:fmtyield r=davidtwco Accommodate yield points in the format_args expansion Fixes #93274. For the case `println!(""{} {:?}"" """" async {}.await)` in the issue the expansion before: ```rust ::std::io::_print( ::core::fmt::Arguments::new_v1( &["""" "" "" ""\n""] &[ ::core::fmt::ArgumentV1::new(&"""" ::core::fmt::Display::fmt) ::core::fmt::ArgumentV1::new(&async {}.await ::core::fmt::Debug::fmt) ] ) ); ``` After: ```rust ::std::io::_print( ::core::fmt::Arguments::new_v1( &["""" "" "" ""\n""] &match (&"""" &async {}.await) { _args => [ ::core::fmt::ArgumentV1::new(_args.0 ::core::fmt::Display::fmt) ::core::fmt::ArgumentV1::new(_args.1 ::core::fmt::Debug::fmt) ] } ) ); ```",THUMBS_UP,2022-01-30T03:59:24Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/93472,CLOSED,2022-01-30T02:22:02Z,2022-02-06T15:47:20Z,Fix HashStable implementation on AllocId,compiler-errors,NA,NA,NA,THUMBS_UP,2022-02-01T15:15:40Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/93479,MERGED,2022-01-30T15:35:26Z,2022-02-17T13:08:52Z,Use `optflag` for `--report-time`,smoelius,d855121a44afd0fc9a5f1c2d263af48e9857a5f4,6,Rollup merge of #93479 - smoelius:master r=yaahc Use `optflag` for `--report-time` Essentially what is described here: https://github.com/rust-lang/rust/issues/64888#issuecomment-1008047228 There is one difference. The comment proposes to add a `--report-time-color` option. This change instead uses libtest's existing `--color` option for that purpose.,HEART,2022-02-03T08:41:16Z,popzxc,popzxc@yandex.ru https://github.com/rust-lang/rust/pull/93493,MERGED,2022-01-30T22:50:57Z,2022-02-02T12:37:38Z,Document valid values of the char type,GKFX,a3deca46754448ff3dfbbd0487e249b98e753a11,2,Rollup merge of #93493 - GKFX:char-docs-2 r=scottmcm Document valid values of the char type As discussed at #93392 the current documentation on what constitutes a valid char isn't very detailed and is partly on the MAX constant rather than the type itself. This PR expands on that information stating the actual numerical range giving examples of what won't work and also mentions how a `char` might be a valid USV but still not be a defined character (terminology checked against [Unicode 14.0 table 2-3](https://www.unicode.org/versions/Unicode14.0.0/ch02.pdf#M9.61673.TableTitle.Table.22.Types.of.Code.Points)).,THUMBS_UP,2022-01-30T23:21:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93493,MERGED,2022-01-30T22:50:57Z,2022-02-02T12:37:38Z,Document valid values of the char type,GKFX,a3deca46754448ff3dfbbd0487e249b98e753a11,2,Rollup merge of #93493 - GKFX:char-docs-2 r=scottmcm Document valid values of the char type As discussed at #93392 the current documentation on what constitutes a valid char isn't very detailed and is partly on the MAX constant rather than the type itself. This PR expands on that information stating the actual numerical range giving examples of what won't work and also mentions how a `char` might be a valid USV but still not be a defined character (terminology checked against [Unicode 14.0 table 2-3](https://www.unicode.org/versions/Unicode14.0.0/ch02.pdf#M9.61673.TableTitle.Table.22.Types.of.Code.Points)).,HEART,2022-01-31T02:52:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93503,MERGED,2022-01-31T10:04:49Z,2022-02-10T05:08:34Z,debuginfo: Fix DW_AT_containing_type vtable debuginfo regression,michaelwoerister,6d40850e09966644d7c47742638fa53e4da7af1c,4,Rollup merge of #93503 - michaelwoerister:fix-vtable-holder-debuginfo-regression r=wesleywiser debuginfo: Fix DW_AT_containing_type vtable debuginfo regression This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in #89597. It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers the compiler will now emit a struct type description with a field for each entry of the vtable. r? ``@wesleywiser`` This PR should fix issue https://github.com/rust-lang/rust/issues/93164. ~~The PR is blocked on https://github.com/rust-lang/rust/pull/93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~,HEART,2022-01-31T15:06:14Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93505,MERGED,2022-01-31T11:27:20Z,2022-02-21T19:34:34Z,safely `transmute<&List> &List>>`,lcnr,03a8cc7df1d65554a4d40825b0490c93ac0f0236,64,Auto merge of #93505 - lcnr:substsref-vs-ty-list r=michaelwoerister safely `transmute<&List> &List>>` This PR has 3 relevant steps which are is split in distinct commits. The first commit now interns `List>` and `List>` together potentially reusing memory while allowing free conversions between these two using `List>::as_substs()` and `SubstsRef<'tcx>::try_as_type_list()`. Using this we then use `&'tcx List>` instead of a `SubstsRef<'tcx>` for tuple fields simplifying a bunch of code. Finally as tuple fields and other generic arguments now use a different `TypeFoldable<'tcx>` impl we optimize the impl for `List>` improving perf by slightly less than 1% in tuple heavy benchmarks.,EYES,2022-01-31T16:01:20Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/93505,MERGED,2022-01-31T11:27:20Z,2022-02-21T19:34:34Z,safely `transmute<&List> &List>>`,lcnr,03a8cc7df1d65554a4d40825b0490c93ac0f0236,64,Auto merge of #93505 - lcnr:substsref-vs-ty-list r=michaelwoerister safely `transmute<&List> &List>>` This PR has 3 relevant steps which are is split in distinct commits. The first commit now interns `List>` and `List>` together potentially reusing memory while allowing free conversions between these two using `List>::as_substs()` and `SubstsRef<'tcx>::try_as_type_list()`. Using this we then use `&'tcx List>` instead of a `SubstsRef<'tcx>` for tuple fields simplifying a bunch of code. Finally as tuple fields and other generic arguments now use a different `TypeFoldable<'tcx>` impl we optimize the impl for `List>` improving perf by slightly less than 1% in tuple heavy benchmarks.,EYES,2022-01-31T20:09:45Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93513,MERGED,2022-01-31T19:21:02Z,2022-02-01T10:12:01Z,Allow any pretty printed line to have at least 60 chars,dtolnay,2e39a3f6ec38f7671e10355bba2bb8a78a78b100,4,"Rollup merge of #93513 - dtolnay:linewidth r=nagisa Allow any pretty printed line to have at least 60 chars Follow-up to #93155. The rustc AST pretty printer has a tendency to get stuck in ""vertical smear mode"" when formatting highly nested code where it puts a linebreak at *every possible* linebreak opportunity once the indentation goes beyond the pretty printer's target line width: ```rust ... ((&([(""test"" as &str)] as [&str; 1]) as &[&str; 1]) (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) ... ``` ```rust ... [(1 as i32) (2 as i32) (3 as i32)] as [i32; 3] ... ``` This is less common after #93155 because that PR greatly reduced the total amount of indentation but the ""vertical smear mode"" failure mode is still just as present when you have deeply nested modules functions or trait impls such as in the case of macro-expanded code from `-Zunpretty=expanded`. Vertical smear mode is never the best way to format highly indented code though. It does not prevent the target line width from being exceeded and it produces output that is less readable than just a longer line. This PR makes the pretty printing algorithm allow a minimum of 60 chars on every line independent of indentation. So as code gets more indented the right margin eventually recedes to make room for formatting without vertical smear. ```console ├─────────────────────────────────────┤ ├─────────────────────────────────────┤ ├─────────────────────────────────────┤ ├───────────────────────────────────┤ ├─────────────────────────────────┤ ├───────────────────────────────┤ ├─────────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├─────────────────────────────┤ ├───────────────────────────────┤ ├─────────────────────────────────┤ ├───────────────────────────────────┤ ├─────────────────────────────────────┤ ```",HEART,2022-01-31T20:01:55Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93513,MERGED,2022-01-31T19:21:02Z,2022-02-01T10:12:01Z,Allow any pretty printed line to have at least 60 chars,dtolnay,2e39a3f6ec38f7671e10355bba2bb8a78a78b100,4,"Rollup merge of #93513 - dtolnay:linewidth r=nagisa Allow any pretty printed line to have at least 60 chars Follow-up to #93155. The rustc AST pretty printer has a tendency to get stuck in ""vertical smear mode"" when formatting highly nested code where it puts a linebreak at *every possible* linebreak opportunity once the indentation goes beyond the pretty printer's target line width: ```rust ... ((&([(""test"" as &str)] as [&str; 1]) as &[&str; 1]) (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) ... ``` ```rust ... [(1 as i32) (2 as i32) (3 as i32)] as [i32; 3] ... ``` This is less common after #93155 because that PR greatly reduced the total amount of indentation but the ""vertical smear mode"" failure mode is still just as present when you have deeply nested modules functions or trait impls such as in the case of macro-expanded code from `-Zunpretty=expanded`. Vertical smear mode is never the best way to format highly indented code though. It does not prevent the target line width from being exceeded and it produces output that is less readable than just a longer line. This PR makes the pretty printing algorithm allow a minimum of 60 chars on every line independent of indentation. So as code gets more indented the right margin eventually recedes to make room for formatting without vertical smear. ```console ├─────────────────────────────────────┤ ├─────────────────────────────────────┤ ├─────────────────────────────────────┤ ├───────────────────────────────────┤ ├─────────────────────────────────┤ ├───────────────────────────────┤ ├─────────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├───────────────────────────┤ ├─────────────────────────────┤ ├───────────────────────────────┤ ├─────────────────────────────────┤ ├───────────────────────────────────┤ ├─────────────────────────────────────┤ ```",EYES,2022-02-01T06:53:44Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/93518,OPEN,2022-01-31T20:04:56Z,NA,[rustdoc-json] JSON no longer inlines,CraftSpider,NA,NA,NA,HEART,2022-01-31T20:09:40Z,Urgau,NA https://github.com/rust-lang/rust/pull/93529,CLOSED,2022-01-31T23:17:14Z,2022-07-03T01:52:43Z,[rustdoc-json] Make enum tuple variants match tuple structs,CraftSpider,NA,NA,NA,THUMBS_UP,2022-01-31T23:33:13Z,Urgau,NA https://github.com/rust-lang/rust/pull/93529,CLOSED,2022-01-31T23:17:14Z,2022-07-03T01:52:43Z,[rustdoc-json] Make enum tuple variants match tuple structs,CraftSpider,NA,NA,NA,THUMBS_UP,2022-02-01T05:42:28Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/93542,MERGED,2022-02-01T11:30:57Z,2022-02-02T22:03:36Z,Prevent lifetime elision in type alias,GuillaumeGomez,7e212c1ca9aa715a51ed4e6a60f3b0c837634720,2,Rollup merge of #93542 - GuillaumeGomez:lifetime-elision r=oli-obk Prevent lifetime elision in type alias Fixes #93401. Apparently the problem has been fixed in the compiler. r? `@oli-obk`,HEART,2022-02-03T20:14:48Z,camelid,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-01T14:22:14Z,fmease,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-01T14:22:17Z,fmease,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-01T15:06:58Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-01T15:10:36Z,Pzixel,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-01T16:43:13Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-01T19:33:59Z,JohnDowson,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-01T20:31:13Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-17T03:09:14Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-17T03:09:14Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-25T19:32:51Z,sea212,mail@haraldheckmann.de https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HOORAY,2022-02-25T22:02:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93545,CLOSED,2022-02-01T14:20:04Z,2022-02-25T19:11:37Z,Implement macro meta-variable expressions,c410-f3r,NA,NA,NA,HEART,2022-02-25T22:02:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93556,MERGED,2022-02-01T19:06:16Z,2022-02-06T08:34:49Z,Change struct expr pretty printing to match rustfmt style,dtolnay,59baf4db0f73e60702d1b4b101a0789e63ddce8f,11,"Rollup merge of #93556 - dtolnay:trailingcomma r=cjgillot Change struct expr pretty printing to match rustfmt style This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions. Example: ```rust macro_rules! stringify_expr { ($expr:expr) => { stringify!($expr) }; } fn main() { println!(""{}"" stringify_expr!(Struct { a: Struct { b c } })); println!(""{}"" stringify_expr!(Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } })); } ``` 🤮 Before: ```console Struct{a: Struct{b c } } Struct{aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct{cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ``` After: ```console Struct { a: Struct { b c } } Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ```",THUMBS_UP,2022-02-01T19:45:05Z,Urgau,NA https://github.com/rust-lang/rust/pull/93556,MERGED,2022-02-01T19:06:16Z,2022-02-06T08:34:49Z,Change struct expr pretty printing to match rustfmt style,dtolnay,59baf4db0f73e60702d1b4b101a0789e63ddce8f,11,"Rollup merge of #93556 - dtolnay:trailingcomma r=cjgillot Change struct expr pretty printing to match rustfmt style This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions. Example: ```rust macro_rules! stringify_expr { ($expr:expr) => { stringify!($expr) }; } fn main() { println!(""{}"" stringify_expr!(Struct { a: Struct { b c } })); println!(""{}"" stringify_expr!(Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } })); } ``` 🤮 Before: ```console Struct{a: Struct{b c } } Struct{aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct{cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ``` After: ```console Struct { a: Struct { b c } } Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ```",THUMBS_UP,2022-02-01T20:02:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93556,MERGED,2022-02-01T19:06:16Z,2022-02-06T08:34:49Z,Change struct expr pretty printing to match rustfmt style,dtolnay,59baf4db0f73e60702d1b4b101a0789e63ddce8f,11,"Rollup merge of #93556 - dtolnay:trailingcomma r=cjgillot Change struct expr pretty printing to match rustfmt style This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions. Example: ```rust macro_rules! stringify_expr { ($expr:expr) => { stringify!($expr) }; } fn main() { println!(""{}"" stringify_expr!(Struct { a: Struct { b c } })); println!(""{}"" stringify_expr!(Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } })); } ``` 🤮 Before: ```console Struct{a: Struct{b c } } Struct{aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct{cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ``` After: ```console Struct { a: Struct { b c } } Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ```",THUMBS_UP,2022-02-01T20:06:17Z,fmease,NA https://github.com/rust-lang/rust/pull/93556,MERGED,2022-02-01T19:06:16Z,2022-02-06T08:34:49Z,Change struct expr pretty printing to match rustfmt style,dtolnay,59baf4db0f73e60702d1b4b101a0789e63ddce8f,11,"Rollup merge of #93556 - dtolnay:trailingcomma r=cjgillot Change struct expr pretty printing to match rustfmt style This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions. Example: ```rust macro_rules! stringify_expr { ($expr:expr) => { stringify!($expr) }; } fn main() { println!(""{}"" stringify_expr!(Struct { a: Struct { b c } })); println!(""{}"" stringify_expr!(Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } })); } ``` 🤮 Before: ```console Struct{a: Struct{b c } } Struct{aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct{cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ``` After: ```console Struct { a: Struct { b c } } Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ```",HEART,2022-02-01T20:33:06Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93556,MERGED,2022-02-01T19:06:16Z,2022-02-06T08:34:49Z,Change struct expr pretty printing to match rustfmt style,dtolnay,59baf4db0f73e60702d1b4b101a0789e63ddce8f,11,"Rollup merge of #93556 - dtolnay:trailingcomma r=cjgillot Change struct expr pretty printing to match rustfmt style This PR backports trailing comma support from https://github.com/dtolnay/prettyplease into rustc_ast_pretty and uses it to improve the formatting of struct expressions. Example: ```rust macro_rules! stringify_expr { ($expr:expr) => { stringify!($expr) }; } fn main() { println!(""{}"" stringify_expr!(Struct { a: Struct { b c } })); println!(""{}"" stringify_expr!(Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } })); } ``` 🤮 Before: ```console Struct{a: Struct{b c } } Struct{aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct{cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ``` After: ```console Struct { a: Struct { b c } } Struct { aaaaaaaaaa: AAAAAAAAAA bbbbbbbbbb: Struct { cccccccccc: CCCCCCCCCC dddddddddd: DDDDDDDDDD eeeeeeeeee: EEEEEEEEEE } } ```",THUMBS_UP,2022-02-04T20:48:27Z,Eastwooder,NA https://github.com/rust-lang/rust/pull/93562,MERGED,2022-02-01T22:11:03Z,2022-03-03T12:39:00Z,Update the documentation for `{As Into From}Raw{Fd Handle Socket}`.,sunfishcode,afd6f5c47808c7676014e88d0fda82e95c3a9da0,4,Rollup merge of #93562 - sunfishcode:sunfishcode/io-docs r=joshtriplett Update the documentation for `{As Into From}Raw{Fd Handle Socket}`. This change weakens the descriptions of the `{as into from}_raw_{fd handle socket}` descriptions from saying that they *do* express ownership relations to say that they are *typically used* in ways that express ownership relations. This is needed since for example std's own [`RawFd`] implements `{As From Into}Fd` without any of the ownership relationships. This adds proper `# Safety` comments to `from_raw_{fd handle socket}` adds the requirement that raw handles be not opened with the `FILE_FLAG_OVERLAPPED` flag and merges the `OwnedHandle::from_raw_handle` comment into the main `FromRawHandle::from_raw_handle` comment. And this changes `HandleOrNull` and `HandleOrInvalid` to not implement `FromRawHandle` since they are intended for limited use in FFI situations and not for generic use and they have constraints that are stronger than the those of `FromRawHandle`. [`RawFd`]: https://doc.rust-lang.org/stable/std/os/unix/io/type.RawFd.html,HEART,2022-02-01T22:24:19Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-01T22:34:57Z,Urgau,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-01T22:35:02Z,Urgau,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-01T23:11:49Z,iksuddle,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-01T23:11:50Z,iksuddle,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-01T23:12:51Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-02-01T23:37:55Z,nyanpasu64,nyanpasu64@tuta.io https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-01T23:45:45Z,stearnsc,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T00:17:28Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T00:29:10Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T00:29:10Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T00:34:04Z,mejrs,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T01:16:59Z,mati865,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T03:03:22Z,hkratz,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T03:03:24Z,hkratz,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T04:20:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T04:46:52Z,lnicola,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T05:34:01Z,Lokathor,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T05:34:03Z,Lokathor,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T06:23:11Z,yerke,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T06:23:12Z,yerke,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T06:23:15Z,yerke,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-02T06:23:18Z,yerke,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T07:08:22Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T07:57:24Z,dbrgn,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T08:01:14Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T08:15:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T08:15:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T08:15:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T08:45:43Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T08:50:39Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T08:50:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T08:50:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-02T09:49:17Z,pachi,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T10:14:07Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-02T10:14:08Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T10:14:08Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T10:14:09Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-02-02T10:14:11Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T12:56:43Z,vacuus,rocyu@protonmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T15:32:48Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T15:37:14Z,NotNorom,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T15:37:15Z,NotNorom,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T17:22:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T17:36:13Z,oberien,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T17:36:14Z,oberien,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T17:36:15Z,oberien,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-02T21:29:57Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-02T21:29:57Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-02T21:29:58Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-02T21:29:59Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-02-02T21:30:00Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-03T03:14:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-03T04:44:21Z,tmccombs,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-03T04:44:22Z,tmccombs,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-03T05:18:32Z,n1000,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-03T05:18:35Z,n1000,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-03T15:58:37Z,funbringer,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-02-03T16:16:36Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-04T03:37:08Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-05T13:49:02Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-05T13:49:03Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-05T13:49:05Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-05T13:49:05Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-06T13:26:08Z,Evrey,evrey@hackish.codes https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-06T15:38:03Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-09T15:09:51Z,diondokter,diondokter@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-10T13:24:46Z,Urgau,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-10T23:30:18Z,jonasohland,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-17T01:18:44Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-20T00:44:49Z,Milo123459,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-20T00:46:17Z,evelynmarie,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-24T08:06:23Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-02-24T08:06:24Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-02-24T08:06:27Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-24T08:06:29Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-02-24T08:06:31Z,VitalyAnkh,vitalyankh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-02-27T18:25:47Z,finnbear,finnbearone@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-02-27T18:25:47Z,finnbear,finnbearone@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-03-06T19:58:05Z,Milo123459,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-03-08T21:57:21Z,Zamiell,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-03-11T11:26:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-03-11T11:26:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-03-11T11:27:00Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-03-22T01:32:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-04-01T19:33:56Z,ljedrz,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-04-22T17:33:24Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-04-25T20:16:14Z,wsy2220,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-05-01T17:44:24Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-05-01T17:44:25Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-05-01T17:44:25Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-05-01T17:44:25Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-05-11T17:19:20Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-03T22:43:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-06-03T22:43:40Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-06-03T22:43:40Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-06-03T22:43:41Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,EYES,2022-06-03T22:43:42Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-04T07:52:54Z,alygin,alygin@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-06-04T17:51:21Z,Altair-Bueno,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T12:26:20Z,wtfsck,wtfsckgh@gmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T12:43:03Z,pldubouilh,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T13:30:53Z,kaleidawave,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T14:16:48Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T16:35:52Z,kinddevil,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HEART,2022-06-07T17:04:38Z,nzrq,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-07T17:57:45Z,TheWeirdDev,alirezasnq@protonmail.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,ROCKET,2022-06-16T19:59:43Z,bluss,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-06-28T16:41:15Z,danielg1111,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-06-28T16:41:17Z,danielg1111,NA https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,THUMBS_UP,2022-07-02T17:19:07Z,akiekintveld,akiekintveld@icloud.com https://github.com/rust-lang/rust/pull/93563,OPEN,2022-02-01T22:26:20Z,NA,Merge crossbeam-channel into `std::sync::mpsc`,ibraheemdev,NA,NA,NA,HOORAY,2022-07-02T17:19:08Z,akiekintveld,akiekintveld@icloud.com https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-02-02T08:35:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-02-02T16:41:17Z,est31,NA https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-04-04T16:37:46Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-04-04T21:00:21Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-04-07T15:13:57Z,jackmichalak,NA https://github.com/rust-lang/rust/pull/93566,MERGED,2022-02-02T00:32:02Z,2022-02-03T18:38:26Z,Make rustc use `RUST_BACKTRACE=full` by default,Aaron1011,333d3d624321057ead2ce06fd346c940b9ce97bd,3,Rollup merge of #93566 - Aaron1011:rustc-backtrace r=davidtwco Make rustc use `RUST_BACKTRACE=full` by default Compiler panics should be rare - when they do occur we want the report filed by the user to contain as much information as possible. This is especially important when the panic is due to an incremental compilation bug since we may not have enough information to reproduce it. This PR sets `RUST_BACKTRACE=full` inside `rustc` if the user has not explicitly set `RUST_BACKTRACE`. This is more verbose than `RUST_BACKTRACE=1` but this may make it easier to debug incremental compilation issues. Users who find this too verbose can still manually set `RUST_BACKTRACE` before invoking the compiler. This only affects `rustc` (and any tool using `rustc_driver::install_ice_hook`). It does *not* affect any user crates or the standard library - backtraces will continue to be off by default in any application *compiled* by rustc.,THUMBS_UP,2022-04-10T03:34:08Z,Rinrin0413,NA https://github.com/rust-lang/rust/pull/93576,MERGED,2022-02-02T08:48:09Z,2022-02-05T04:32:42Z,Emit more valid HTML from rustdoc,jsha,3edec8055165d5107bc9695a1f5ded67cdeb7aea,27,"Rollup merge of #93576 - jsha:fix-rustdoc-html r=GuillaumeGomez Emit more valid HTML from rustdoc Previously tidy-html5 (`tidy`) would complain about a few things in our HTML. The main thing is that `` tags can't contain `
`s. That's easily fixed by changing out the `
`s for ``s with `display: block`. However there's also a rule that ``s can't contain heading elements. `` permits only ""phrasing content"" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span and `

` (and friends) are ""Flow content heading content palpable content"". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements We have a wrapping `
` that goes around each `

`/`

` etc. We turn that into a `
` rather than a `` because `
` permits ""flow content"". https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section After this change we get only three warnings from tidy run on struct.String.html: line 6 column 10790 - Warning: trimming empty line 1 column 1118 - Warning: proprietary attribute ""disabled"" line 1 column 1193 - Warning: proprietary attribute ""disabled"" The empty `` is a known issue - there's a span in front of the search box to work around a strange Safari issue. The `` attributes are the non-default stylesheets. We can probably refactor theme application to avoid using this proprietary ""disabled"" attribute. We can suppress those warnings with flags to tidy and get a run that returns 0 (success): ``` tidy -o /dev/null -quiet --drop-empty-elements no --warn-proprietary-attributes no build/x86_64-unknown-linux-gnu/doc/std/string/trait.ToString.html ``` Note: this requires the latest version of tidy-html5 built from https://github.com/htacg/tidy-html5. Older versions (including the default version on Ubuntu 21.10) think `
` can't occur inside ``. Demo: https://rustdoc.crud.net/jsha/fix-rustdoc-html/std/string/struct.String.html r? `@GuillaumeGomez`",HEART,2022-02-06T21:50:35Z,camelid,NA https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-02-12T00:43:08Z,erikdesjardins,NA https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-02-17T15:58:34Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-02-19T14:44:48Z,hkratz,NA https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-02-20T11:35:30Z,cjdsellers,chris@cjdsellers.io https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-02-24T10:15:41Z,phil-opp,contact@phil-opp.com https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-03-22T03:58:32Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-04-05T12:16:33Z,RedsonBr140,redson@riseup.net https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-04-07T23:05:21Z,worstpractice,NA https://github.com/rust-lang/rust/pull/93577,MERGED,2022-02-02T09:40:00Z,2022-02-17T15:38:47Z,Upgrade to LLVM 14,nikic,30b3f35c420694a4f24e5a4df00f06073f4f3a37,13,Auto merge of #93577 - nikic:llvm-14 r=nagisa Upgrade to LLVM 14 LLVM patch state: * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported. * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017. * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream. * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported. * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport. * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream. * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream. * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856. Release timeline: * LLVM 14.0.0 final planned for Mar 15. * Rust 1.60.0 planned for Apr 7. Compile-time: * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864 * A slight improvement on average though no big changes either way. * There are some larger max-rss improvements. r? `@ghost`,ROCKET,2022-05-18T16:47:36Z,TheAwiteb,Awiteb@hotmail.com https://github.com/rust-lang/rust/pull/93580,MERGED,2022-02-02T11:54:14Z,2022-02-20T05:24:56Z,Stabilize pin_static_ref.,m-ou-se,7977af5975cfe90c16da2abf9701daca00e17201,2,Rollup merge of #93580 - m-ou-se:stabilize-pin-static-ref r=scottmcm Stabilize pin_static_ref. FCP finished here: https://github.com/rust-lang/rust/issues/78186#issuecomment-1024987221 Closes #78186,THUMBS_UP,2022-02-04T19:25:30Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-02-02T12:38:36Z,fredlahde,NA https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-02-02T15:27:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-02-02T17:13:29Z,rrbutani,NA https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-02-03T23:04:24Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-04T03:37:59Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,HOORAY,2022-02-04T03:38:02Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-02-11T12:25:27Z,mickdekkers,mickdekkersnl@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-21T16:34:41Z,tema3210,NA https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,EYES,2022-03-19T06:53:43Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-03-31T16:55:37Z,ljedrz,NA https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-04-11T20:56:02Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/93582,OPEN,2022-02-02T12:22:13Z,NA,Allow `impl Fn() -> impl Trait` in return position,WaffleLapkin,NA,NA,NA,ROCKET,2022-05-16T17:12:51Z,aliemjay,NA https://github.com/rust-lang/rust/pull/93587,OPEN,2022-02-02T15:05:55Z,NA,Stabilize naked_functions,bstrie,NA,NA,NA,HEART,2022-05-11T03:13:18Z,Kampfkarren,NA https://github.com/rust-lang/rust/pull/93593,MERGED,2022-02-02T16:45:10Z,2022-02-04T17:40:08Z,Fix ret > 1 bound if shadowed by const,JulianKnodt,92a7f5fa07d3c11e0ee4d3c2e4107add06e3e730,4,Rollup merge of #93593 - JulianKnodt:master r=oli-obk Fix ret > 1 bound if shadowed by const Prior to a change it would only look at types in bounds. When it started looking for consts shadowing type variables with a const would cause an ICE so now defer looking at consts only if there are no types present. cc ``````@compiler-errors`````` Should Fix #93553,HEART,2022-02-02T17:37:37Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93613,MERGED,2022-02-03T10:01:10Z,2022-02-18T21:58:27Z,Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator`,crlf0710,f1c918f1f3166c1cb2624ce2e2783d357e70dc3d,8,Rollup merge of #93613 - crlf0710:rename_to_async_iter r=yaahc Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator` Following amendments in https://github.com/rust-lang/rfcs/pull/3208/. cc #79024 cc ``@yoshuawuyts`` ``@joshtriplett``,HOORAY,2022-02-03T10:13:56Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93613,MERGED,2022-02-03T10:01:10Z,2022-02-18T21:58:27Z,Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator`,crlf0710,f1c918f1f3166c1cb2624ce2e2783d357e70dc3d,8,Rollup merge of #93613 - crlf0710:rename_to_async_iter r=yaahc Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator` Following amendments in https://github.com/rust-lang/rfcs/pull/3208/. cc #79024 cc ``@yoshuawuyts`` ``@joshtriplett``,HOORAY,2022-02-03T10:50:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93613,MERGED,2022-02-03T10:01:10Z,2022-02-18T21:58:27Z,Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator`,crlf0710,f1c918f1f3166c1cb2624ce2e2783d357e70dc3d,8,Rollup merge of #93613 - crlf0710:rename_to_async_iter r=yaahc Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator` Following amendments in https://github.com/rust-lang/rfcs/pull/3208/. cc #79024 cc ``@yoshuawuyts`` ``@joshtriplett``,HOORAY,2022-02-21T13:12:16Z,Folyd,NA https://github.com/rust-lang/rust/pull/93613,MERGED,2022-02-03T10:01:10Z,2022-02-18T21:58:27Z,Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator`,crlf0710,f1c918f1f3166c1cb2624ce2e2783d357e70dc3d,8,Rollup merge of #93613 - crlf0710:rename_to_async_iter r=yaahc Move `{core std}::stream::Stream` to `{core std}::async_iter::AsyncIterator` Following amendments in https://github.com/rust-lang/rfcs/pull/3208/. cc #79024 cc ``@yoshuawuyts`` ``@joshtriplett``,HOORAY,2022-02-21T14:10:06Z,yerke,NA https://github.com/rust-lang/rust/pull/93626,MERGED,2022-02-03T17:40:07Z,2022-02-08T12:50:05Z,Fix HashMap not displaying correctly in VS debugger,wesleywiser,775e480722c7aba6ff4ff3ccec8c1f4639ae7889,1,Auto merge of #93626 - wesleywiser:fix_hashmap_natvis r=michaelwoerister Fix HashMap not displaying correctly in VS debugger The natvis to render HashMaps was not working correctly in Visual Studio because the type names for tuples changed from `tuple$` to `tuple$` (notice the missing space). WinDbg and cdb continued to parse this type name which is why no tests in CI broke. VS however is slightly more strict and this caused the visualizer to break. Since we cannot test the VS debugger in CI I'm not checking in any test changes. Fixes #92286 r? `@michaelwoerister`,HEART,2022-02-04T15:51:00Z,lqd,NA https://github.com/rust-lang/rust/pull/93626,MERGED,2022-02-03T17:40:07Z,2022-02-08T12:50:05Z,Fix HashMap not displaying correctly in VS debugger,wesleywiser,775e480722c7aba6ff4ff3ccec8c1f4639ae7889,1,Auto merge of #93626 - wesleywiser:fix_hashmap_natvis r=michaelwoerister Fix HashMap not displaying correctly in VS debugger The natvis to render HashMaps was not working correctly in Visual Studio because the type names for tuples changed from `tuple$` to `tuple$` (notice the missing space). WinDbg and cdb continued to parse this type name which is why no tests in CI broke. VS however is slightly more strict and this caused the visualizer to break. Since we cannot test the VS debugger in CI I'm not checking in any test changes. Fixes #92286 r? `@michaelwoerister`,HEART,2022-02-17T06:09:17Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/93626,MERGED,2022-02-03T17:40:07Z,2022-02-08T12:50:05Z,Fix HashMap not displaying correctly in VS debugger,wesleywiser,775e480722c7aba6ff4ff3ccec8c1f4639ae7889,1,Auto merge of #93626 - wesleywiser:fix_hashmap_natvis r=michaelwoerister Fix HashMap not displaying correctly in VS debugger The natvis to render HashMaps was not working correctly in Visual Studio because the type names for tuples changed from `tuple$` to `tuple$` (notice the missing space). WinDbg and cdb continued to parse this type name which is why no tests in CI broke. VS however is slightly more strict and this caused the visualizer to break. Since we cannot test the VS debugger in CI I'm not checking in any test changes. Fixes #92286 r? `@michaelwoerister`,HEART,2022-02-19T01:04:28Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/93626,MERGED,2022-02-03T17:40:07Z,2022-02-08T12:50:05Z,Fix HashMap not displaying correctly in VS debugger,wesleywiser,775e480722c7aba6ff4ff3ccec8c1f4639ae7889,1,Auto merge of #93626 - wesleywiser:fix_hashmap_natvis r=michaelwoerister Fix HashMap not displaying correctly in VS debugger The natvis to render HashMaps was not working correctly in Visual Studio because the type names for tuples changed from `tuple$` to `tuple$` (notice the missing space). WinDbg and cdb continued to parse this type name which is why no tests in CI broke. VS however is slightly more strict and this caused the visualizer to break. Since we cannot test the VS debugger in CI I'm not checking in any test changes. Fixes #92286 r? `@michaelwoerister`,HEART,2022-02-20T01:07:38Z,MaulingMonkey,git@maulingmonkey.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:11:12Z,iago-lito,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:12:35Z,rsalmei,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:12:58Z,DrMeepster,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:19:02Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:45:13Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T20:56:46Z,edmorley,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T21:17:03Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T21:39:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T21:45:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-03T21:52:51Z,algesten,martin@algesten.se https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-02-03T21:52:54Z,algesten,martin@algesten.se https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-02-03T23:16:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-02-04T01:03:02Z,mati865,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T01:26:06Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T04:41:46Z,lffg,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T06:13:47Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T06:22:19Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-02-04T06:22:20Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T08:02:20Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T08:03:16Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-04T10:55:45Z,plazmoid,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-05T18:23:07Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-09T15:10:47Z,oaleaf,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-10T17:49:54Z,adamgemmell,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-12T02:51:13Z,falsetru,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-16T06:13:47Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-02-18T12:53:39Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-02-18T12:53:42Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-03-04T04:06:29Z,MolotovCherry,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-03-15T05:24:09Z,jkelleyrtp,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-03-17T00:23:27Z,silverlyra,lyra@hey.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-03-17T00:23:32Z,silverlyra,lyra@hey.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-03-20T09:19:13Z,sudormrfbin,gokulps15@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-04-02T08:52:18Z,Milo123459,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-04-11T09:12:17Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-04-22T04:19:11Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-02T19:44:39Z,jkugelman,john@kugelman.name https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-06-09T03:26:24Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-14T01:47:16Z,qthree,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-14T23:19:19Z,Coder-256,jacob@jacobgreenfield.me https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-15T00:41:19Z,yerke,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-06-15T00:41:20Z,yerke,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,THUMBS_UP,2022-06-15T00:41:24Z,yerke,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,ROCKET,2022-06-15T00:41:26Z,yerke,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-19T16:48:35Z,matux,matias.pequeno@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-06-19T16:48:38Z,matux,matias.pequeno@gmail.com https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,THUMBS_UP,2022-06-21T19:04:55Z,eminence,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,THUMBS_UP,2022-06-23T14:43:09Z,ahlinc,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-23T14:43:10Z,ahlinc,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-06-23T14:43:10Z,ahlinc,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,ROCKET,2022-06-23T14:43:11Z,ahlinc,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,THUMBS_UP,2022-06-23T16:40:27Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-06-23T16:40:29Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,ROCKET,2022-06-23T16:40:30Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-06-23T16:40:33Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HOORAY,2022-07-11T07:29:14Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,THUMBS_UP,2022-07-11T07:29:17Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/93628,OPEN,2022-02-03T19:28:27Z,NA,Stabilize `let else`,est31,NA,NA,NA,HEART,2022-07-11T07:29:19Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/93634,MERGED,2022-02-03T22:15:22Z,2022-02-18T21:58:27Z,compiler: clippy::complexity fixes,matthiaskrgr,a144ea1c4b39bdef608c537b25343674aa2b5bc7,22,Rollup merge of #93634 - matthiaskrgr:clippy_complexity_jan_2022 r=oli-obk compiler: clippy::complexity fixes useless_format map_flatten useless_conversion needless_bool filter_next clone_on_copy needless_option_as_deref,HEART,2022-02-18T22:10:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/93635,MERGED,2022-02-03T22:20:13Z,2022-02-12T01:23:36Z,Add missing platform-specific information on current_dir and set_current_dir,GuillaumeGomez,15d71cff2d6286b0f281485637eace03dbe94916,1,Rollup merge of #93635 - GuillaumeGomez:missing-platform-spec-info r=Amanieu Add missing platform-specific information on current_dir and set_current_dir Fixes #93598.,THUMBS_UP,2022-03-26T15:58:03Z,AustinScola,austinscola@gmail.com https://github.com/rust-lang/rust/pull/93638,MERGED,2022-02-04T00:03:54Z,2022-02-04T17:40:07Z,rustdoc: remove unused Hash impl,notriddle,1426f0e6f03d64902ac75a47eba800cbf82d7d41,1,Rollup merge of #93638 - notriddle:notriddle/unused-hash r=GuillaumeGomez rustdoc: remove unused Hash impl,HEART,2022-02-04T04:09:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/93639,MERGED,2022-02-04T02:33:46Z,2022-02-20T05:24:55Z,Release notes for 1.59,Mark-Simulacrum,4f533de571acce5913d3713062c1f3e44e9a3594,1,Rollup merge of #93639 - Mark-Simulacrum:relnotes r=Mark-Simulacrum Release notes for 1.59 cc `@rust-lang/release` r? `@cuviper`,HEART,2022-02-04T15:10:47Z,mati865,NA https://github.com/rust-lang/rust/pull/93639,MERGED,2022-02-04T02:33:46Z,2022-02-20T05:24:55Z,Release notes for 1.59,Mark-Simulacrum,4f533de571acce5913d3713062c1f3e44e9a3594,1,Rollup merge of #93639 - Mark-Simulacrum:relnotes r=Mark-Simulacrum Release notes for 1.59 cc `@rust-lang/release` r? `@cuviper`,HEART,2022-02-05T02:37:16Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/93643,MERGED,2022-02-04T10:11:15Z,2022-02-07T06:42:23Z,use `fold_list` in `try_super_fold_with` for `SubstsRef`,lcnr,926e7843eaa1794f15948395588eddedfb74a0d8,1,Auto merge of #93643 - lcnr:fold-substs-perf r=michaelwoerister use `fold_list` in `try_super_fold_with` for `SubstsRef` split out from #93505 as this by itself is responsible for most of the perf improvements there r? `@michaelwoerister`,THUMBS_UP,2022-02-04T16:15:38Z,lqd,NA https://github.com/rust-lang/rust/pull/93643,MERGED,2022-02-04T10:11:15Z,2022-02-07T06:42:23Z,use `fold_list` in `try_super_fold_with` for `SubstsRef`,lcnr,926e7843eaa1794f15948395588eddedfb74a0d8,1,Auto merge of #93643 - lcnr:fold-substs-perf r=michaelwoerister use `fold_list` in `try_super_fold_with` for `SubstsRef` split out from #93505 as this by itself is responsible for most of the perf improvements there r? `@michaelwoerister`,THUMBS_UP,2022-02-07T06:20:22Z,bhgomes,bhgomes@pm.me https://github.com/rust-lang/rust/pull/93643,MERGED,2022-02-04T10:11:15Z,2022-02-07T06:42:23Z,use `fold_list` in `try_super_fold_with` for `SubstsRef`,lcnr,926e7843eaa1794f15948395588eddedfb74a0d8,1,Auto merge of #93643 - lcnr:fold-substs-perf r=michaelwoerister use `fold_list` in `try_super_fold_with` for `SubstsRef` split out from #93505 as this by itself is responsible for most of the perf improvements there r? `@michaelwoerister`,THUMBS_UP,2022-02-09T01:02:21Z,nnethercote,NA https://github.com/rust-lang/rust/pull/93653,CLOSED,2022-02-04T17:14:35Z,2022-02-09T21:04:59Z,Added `Box::take()` method,Kixunil,NA,NA,NA,THUMBS_UP,2022-02-04T19:35:33Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93664,OPEN,2022-02-04T21:46:10Z,NA,impl From> for *const T,kupiakos,NA,NA,NA,THUMBS_UP,2022-02-06T09:24:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93666,CLOSED,2022-02-05T00:07:19Z,2022-02-09T04:55:28Z,Fall back to being const-unstable when undeclared,jhpratt,NA,NA,NA,HEART,2022-02-06T12:47:00Z,RalfJung,NA https://github.com/rust-lang/rust/pull/93669,MERGED,2022-02-05T05:05:57Z,2022-02-06T08:34:49Z,Resolve lifetimes for const generic defaults,compiler-errors,cbf4b4664068e255fac92f898b9a0e046680dd08,5,Rollup merge of #93669 - compiler-errors:const-generic-args r=lcnr Resolve lifetimes for const generic defaults We weren't visiting the const generic default argument in `rustc_resolve::late::lifetimes`. This seems to fix the issue and we deny any non-`'static` lifetimes anyways. Fixes #93647,HEART,2022-02-05T10:52:17Z,fmease,NA https://github.com/rust-lang/rust/pull/93669,MERGED,2022-02-05T05:05:57Z,2022-02-06T08:34:49Z,Resolve lifetimes for const generic defaults,compiler-errors,cbf4b4664068e255fac92f898b9a0e046680dd08,5,Rollup merge of #93669 - compiler-errors:const-generic-args r=lcnr Resolve lifetimes for const generic defaults We weren't visiting the const generic default argument in `rustc_resolve::late::lifetimes`. This seems to fix the issue and we deny any non-`'static` lifetimes anyways. Fixes #93647,HEART,2022-02-10T21:51:17Z,estebank,NA https://github.com/rust-lang/rust/pull/93670,MERGED,2022-02-05T06:29:01Z,2022-02-13T02:40:56Z,Apply noundef attribute to &T &mut T Box bool,erikdesjardins,5c30d6568383916ce97cdf20ceb61a8b9e5bb5a8,13,Auto merge of #93670 - erikdesjardins:noundef r=nikic Apply noundef attribute to &T &mut T Box bool This doesn't handle `char` because it's a bit awkward to distinguish it from `u32` at this point in codegen. Note that this _does not_ change whether or not it is UB for `&` `&mut` or `Box` to point to undef. It only applies to the pointer itself not the pointed-to memory. Fixes (partially) #74378. r? `@nikic` cc `@RalfJung`,THUMBS_UP,2022-02-06T01:03:12Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93672,MERGED,2022-02-05T09:47:57Z,2022-02-08T10:05:13Z,update comment wrt const param defaults,lcnr,b7f785092d84a4b4dadb08fc9fdfe86b0b6139e6,1,Rollup merge of #93672 - lcnr:const-param-defaults-xx r=matthewjasper update comment wrt const param defaults after #93669 i looked through all other uses of `GenericParamKind::Const` again to detect if we missed the `default` there as well but afaict we really only missed lifetime resolution '^^ at least i found an outdated comment :3,HEART,2022-02-05T09:51:52Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93678,MERGED,2022-02-05T18:37:08Z,2022-02-20T23:56:01Z,Improve `unused_unsafe` lint,steffahn,45e2c2881d11324d610815bfff097e25c412199e,11,Auto merge of #93678 - steffahn:better_unsafe_diagnostics r=nagisa Improve `unused_unsafe` lint I’m going to add some motivation and explanation below particularly pointing the changes in behavior from this PR. _Edit:_ Looking for existing issues looks like this PR fixes #88260. _Edit2:_ Now also contains code that closes #90776.,HEART,2022-02-18T20:11:34Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/93680,MERGED,2022-02-05T20:17:06Z,2022-02-07T18:30:31Z,Drop json::from_reader,Mark-Simulacrum,bd245facd40f455394d5bd8ee6a1972717f46f79,2,Rollup merge of #93680 - Mark-Simulacrum:drop-json-reader r=bjorn3 Drop json::from_reader Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.,THUMBS_UP,2022-02-06T14:41:10Z,bjorn3,NA https://github.com/rust-lang/rust/pull/93685,MERGED,2022-02-06T01:14:53Z,2022-02-13T17:41:33Z,Drop time dependency from bootstrap,Mark-Simulacrum,05d165233794c48217e2e2bb6de8ee9763ea1084,6,Auto merge of #93685 - Mark-Simulacrum:drop-time r=Mark-Simulacrum Drop time dependency from bootstrap This was only used for the inclusion of 'current' dates into our manpages but it is not clear that this is practically necessary. The manpage is essentially never updated and so we can likely afford to keep a manual date in these files. It also seems possible to just omit it but that may cause other tools trouble so avoid doing that for now. This is largely done to reduce bootstrap complexity; the time crate is not particularly small and in #92480 would have started pulling in num-threads which does runtime thread count detection. I would prefer to avoid that so filing this to just drop the nearly unused dependency entirely. r? `@pietroalbini`,HEART,2022-02-06T14:53:51Z,bjorn3,NA https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",HEART,2022-02-06T12:53:20Z,Yatekii,NA https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",ROCKET,2022-02-06T12:53:25Z,Yatekii,NA https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",HEART,2022-02-24T05:01:49Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",HEART,2022-02-24T23:48:48Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",HEART,2022-02-27T13:49:16Z,mendess,pedro.mendes.26@gmail.com https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",ROCKET,2022-05-26T19:51:29Z,braddunbar,dunbarb2@gmail.com https://github.com/rust-lang/rust/pull/93686,MERGED,2022-02-06T01:34:01Z,2022-02-20T05:24:55Z,core: Implement ASCII trim functions on byte slices,dbrgn,575f6c5cc1779508cd30847ccb9f3f489f5e6c00,1,"Rollup merge of #93686 - dbrgn:trim-on-byte-slices r=joshtriplett core: Implement ASCII trim functions on byte slices Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace which needs to be removed. Because oftentimes drivers will operate on the byte level decoding to unicode and checking for unicode whitespace is unnecessary overhead. This PR adds three new methods to byte slices: - `trim_ascii_start` - `trim_ascii_end` - `trim_ascii` I did not find any pre-existing discussions about this which surprises me a bit. Maybe I'm missing something and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 (""Trim methods on slices"") but that has a different purpose. As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html) this is a proposed implementation without any issue / RFC. If this is the wrong process please let me know. However I thought discussing code is easier than discussing a mere idea and hacking on the stdlib was fun. Tracking issue: https://github.com/rust-lang/rust/issues/94035",HOORAY,2022-05-26T19:51:31Z,braddunbar,dunbarb2@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-06T18:04:20Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-07T12:25:36Z,veber-alex,alexveber@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,HEART,2022-02-08T07:33:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-08T08:57:40Z,honzasp,patek.mail@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,HEART,2022-02-08T08:57:53Z,honzasp,patek.mail@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-08T09:11:51Z,Folyd,NA https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-09T23:45:57Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-15T12:43:28Z,trickster,NA https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,HEART,2022-02-15T12:43:32Z,trickster,NA https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-18T17:31:48Z,FHTMitchell,fhtmitchell@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-02-19T14:40:06Z,WindSoilder,WindSoilder@outlook.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,HEART,2022-02-19T14:40:07Z,WindSoilder,WindSoilder@outlook.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_DOWN,2022-02-19T15:33:35Z,SvetlinZarev,NA https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-03-16T20:21:28Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,HEART,2022-03-23T07:57:34Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/93709,CLOSED,2022-02-06T16:57:25Z,2022-04-13T18:56:20Z,Rename `first*`/`last*` `BTree{Set Map}` methods to `min*`/`max*`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-03-23T07:57:35Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/93717,MERGED,2022-02-06T22:24:57Z,2022-06-05T04:16:04Z,Add build metrics to rustbuild,pietroalbini,6dadfc06fe628d7a381a52b07714a7a849a6223d,10,Auto merge of #93717 - pietroalbini:pa-ci-profiler r=Mark-Simulacrum Add build metrics to rustbuild This PR adds a new module of rustbuild `ci_profiler` whose job is to gather as much information as possible about the CI build as possible and store it in a JSON file uploaded to `ci-artifacts`. Right now for each step it collects: * Type name and debug representation of the `Step` object. * Duration of the step (excluding child steps). * Systemwide CPU stats for the duration of the step (both single core and all cores). * Which child steps were executed. This is capable of replacing both the scripts to collect CPU stats and the `[TIMING]` lines in build logs (not yet removed until we port our tooling to use the CI profiler). The format is also extensible to be able in the future to collect more information. r? `@Mark-Simulacrum`,HEART,2022-02-09T08:58:19Z,mati865,NA https://github.com/rust-lang/rust/pull/93728,MERGED,2022-02-07T05:01:36Z,2022-02-08T10:05:12Z,Add in ValuePair::Term,JulianKnodt,25ce315c7604e6617bd8b5868b45c9a3bd4867af,6,Rollup merge of #93728 - JulianKnodt:toterm r=oli-obk Add in ValuePair::Term This adds in an enum when matching on positions which can either be types or consts. It will default to emitting old special cased error messages for types. r? `@oli-obk` cc `@matthiaskrgr` Fixes #93578,HEART,2022-02-07T05:43:40Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93749,MERGED,2022-02-07T22:43:32Z,2022-03-14T16:24:19Z,Add riscv32im-unknown-none-elf built-in target triple.,ridwanabdillahi,bce19cf7f19ee5729defaccc86b068cc3c206c9c,4,"Auto merge of #93749 - ridwanabdillahi:riscv32im_support r=wesleywiser Add riscv32im-unknown-none-elf built-in target triple. * Add built-in target `riscv32im-unknown-none-elf`. * Update `platform-support.md` to list it as a Tier 3 target. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others with more experience around RISC-V volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",EYES,2022-02-08T20:52:48Z,Daasin,NA https://github.com/rust-lang/rust/pull/93749,MERGED,2022-02-07T22:43:32Z,2022-03-14T16:24:19Z,Add riscv32im-unknown-none-elf built-in target triple.,ridwanabdillahi,bce19cf7f19ee5729defaccc86b068cc3c206c9c,4,"Auto merge of #93749 - ridwanabdillahi:riscv32im_support r=wesleywiser Add riscv32im-unknown-none-elf built-in target triple. * Add built-in target `riscv32im-unknown-none-elf`. * Update `platform-support.md` to list it as a Tier 3 target. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others with more experience around RISC-V volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",THUMBS_UP,2022-02-10T07:56:53Z,danc86,djc@djc.id.au https://github.com/rust-lang/rust/pull/93749,MERGED,2022-02-07T22:43:32Z,2022-03-14T16:24:19Z,Add riscv32im-unknown-none-elf built-in target triple.,ridwanabdillahi,bce19cf7f19ee5729defaccc86b068cc3c206c9c,4,"Auto merge of #93749 - ridwanabdillahi:riscv32im_support r=wesleywiser Add riscv32im-unknown-none-elf built-in target triple. * Add built-in target `riscv32im-unknown-none-elf`. * Update `platform-support.md` to list it as a Tier 3 target. Below are details on how this target meets the requirements for tier 3: > A tier 3 target must have a designated developer or developers (the ""target maintainers"") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I would be willing to be a target maintainer though I would appreciate if others with more experience around RISC-V volunteered to help with that as well. > Targets must use naming consistent with any existing targets; for instance a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains) unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive especially once the target reaches a higher tier so getting the name right is important even for a tier 3 target. Uses the same naming as the LLVM target and the same convention as many other bare-metal targets. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example if the name of the target makes people extremely likely to form incorrect beliefs about what it targets the name should be changed or augmented to disambiguate it. I don't believe there is any ambiguity here. > Tier 3 targets may have unusual requirements to build or use but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. I don't see any legal issues here. > The target must not introduce license incompatibilities. > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository) or whether the dependency is a native library or binary. In other words the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. > If the target supports building host tools (such as rustc or cargo) those host tools must not depend on proprietary (non-FOSS) libraries other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance rustc built for the target may depend on a common proprietary C runtime library or console output library but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations but the Rust project has no interest in maintaining such combinations within the scope of Rust itself even at tier 3. > Targets should not require proprietary (non-FOSS) components to link a functional binary or library. > ""onerous"" here is an intentionally subjective term. At a minimum ""onerous"" legal/licensing terms include but are not limited to: non-disclosure requirements non-compete requirements contributor license agreements (CLAs) or equivalent ""non-commercial""/""research-only""/etc terms requirements conditional on the employer or employment of any particular Rust developers revocable terms any requirements that create liability for the Rust project or its developers or users or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. I see no issues with any of the above. > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target they must recuse themselves from any approval decisions regarding the target's tier status though they may otherwise participate in discussions. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval even if such judgment involves subjective matters or goes beyond the letter of these requirements. Only relevant to those making approval decisions. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets alloc for targets that can support dynamic memory allocation std for targets with an operating system or equivalent layer of system-provided functionality) but may leave some code unimplemented (either unavailable or stubbed out as appropriate) whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. `core` and `alloc` can be used. `std` cannot be used as this is a bare-metal target. > The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation if possible. If the target supports running tests (even if they do not pass) the documentation must explain how to run tests for the target using emulation if possible or dedicated hardware if necessary. Use `--target=x86_64-unknown-none-elf` option to cross compile just like any target. The target does not support running tests. > Tier 3 targets must not impose burden on the authors of pull requests or other developers in the community to maintain the target. In particular do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium including via `@)` to a PR author or others involved with a PR regarding a tier 3 target unless they have opted into such messages. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy within reason. However such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. I don't foresee this being a problem. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > In particular this may come up when working on closely related targets such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection as appropriate to let each target run code supported by that target. No other targets should be affected by the pull request.",THUMBS_UP,2022-03-09T21:29:24Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-08T03:30:16Z,crlf0710,NA https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-08T03:55:37Z,aaronchall,aaronchall@yahoo.com https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-08T10:00:00Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-08T10:25:24Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-15T15:27:03Z,mcarton,NA https://github.com/rust-lang/rust/pull/93753,MERGED,2022-02-08T01:11:24Z,2022-02-10T05:08:34Z,Complete removal of #[main] attribute from compiler,jeremyBanks,84c28041b486f229431b8c88fa24cb03e05fb70c,5,"Rollup merge of #93753 - jeremyBanks:main-conflict r=petrochenkov Complete removal of #[main] attribute from compiler resolves #93786 --- The `#[main]` attribute was mostly removed from the language in #84217 but not completely. It is still recognized as a builtin attribute by the compiler but it has no effect. However this no-op attribute is no longer gated by `#[feature(main)]` (which no longer exists) so it's possible to include it in code *on stable* without any errors which seems unintentional. For example the following code is accepted ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). ```rust #[main] fn main() { println!(""hello world""); } ``` Aside from that oddity the existence of this attribute causes code like the following to fail ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=use%20tokio%3A%3Amain%3B%0A%0A%23%5Bmain%5D%0Afn%20main()%20%7B%0A%20%20%20%20println!(%22hello%20world%22)%3B%0A%7D%0A)). According https://github.com/rust-lang/rust/pull/84062#issuecomment-825038275 the removal of `#[main]` was expected to eliminate this conflict (previously reported as #62127). ```rust use tokio::main; #[main] fn main() { println!(""hello world""); } ``` ``` error[E0659]: `main` is ambiguous --> src/main.rs:3:3 | 3 | #[main] | ^^^^ ambiguous name | = note: ambiguous because of a name conflict with a builtin attribute = note: `main` could refer to a built-in attribute ``` [This error message can be confusing](https://stackoverflow.com/q/71024443/1114) as the mostly-removed `#[main]` attribute is not mentioned in any documentation. Since the current availability of `#[main]` on stable seems unintentional and to needlessly block use of the `main` identifier in the attribute namespace this PR finishes removing the `#[main]` attribute as described in https://github.com/rust-lang/rust/issues/29634#issuecomment-274951753 by deleting it from `builtin_attrs.rs` and adds two test cases to ensure that the attribute is no longer accepted and no longer conflicts with other attributes imported as `main`.",THUMBS_UP,2022-02-18T14:33:38Z,thoerni,NA https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-02-08T07:32:58Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-02-08T12:20:58Z,aedm,korteur@gmail.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,THUMBS_UP,2022-02-10T17:24:33Z,keldonin,eric.devolder@mastercard.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-02-15T03:44:07Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-03-25T01:07:16Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,THUMBS_UP,2022-03-25T08:16:00Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-03-31T08:55:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,THUMBS_UP,2022-03-31T08:55:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-03-31T14:16:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,THUMBS_UP,2022-03-31T14:16:25Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93755,MERGED,2022-02-08T01:53:54Z,2022-03-28T05:09:54Z,Allow comparing `Vec`s with different allocators using `==`,ChayimFriedman2,6ed1a67b3805bdea306ee055e035e298f92a10e4,1,Rollup merge of #93755 - ChayimFriedman2:allow-comparing-vecs-with-different-allocators r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec <=> Vec where T: PartialOrd`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly and even with other allocators you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.,HEART,2022-03-31T17:07:20Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,THUMBS_UP,2022-02-08T20:53:24Z,Daasin,NA https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,ROCKET,2022-02-08T20:54:14Z,Daasin,NA https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,THUMBS_UP,2022-06-20T07:53:02Z,HTG-YT,NA https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,THUMBS_UP,2022-06-20T23:04:59Z,up-to-you,NA https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,ROCKET,2022-06-20T23:04:59Z,up-to-you,NA https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,THUMBS_UP,2022-06-23T07:39:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,ROCKET,2022-06-23T07:39:29Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,ROCKET,2022-06-23T15:09:20Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,ROCKET,2022-06-24T05:47:13Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93765,MERGED,2022-02-08T09:28:26Z,2022-06-20T22:16:02Z,Optimize heapsort,zhangyunhao116,5750a6aa2777382bf421b726f234da23f990a953,1,Auto merge of #93765 - zhangyunhao116:heapsort r=m-ou-se Optimize heapsort The new implementation is about 10% faster than the previous one(sorting random 1000 items).,EYES,2022-06-25T05:20:08Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/93778,MERGED,2022-02-08T15:40:53Z,2022-02-09T04:05:57Z,Rollup of 7 pull requests,matthiaskrgr,9a5a961be97f405e751dd2cf966e1cdb80a612c2,19,Auto merge of #93778 - matthiaskrgr:rollup-yfngdao r=matthiaskrgr Rollup of 7 pull requests Successful merges: - #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`) - #92715 (Do not suggest char literal for zero-length strings) - #92917 (Don't constrain projection predicates with inference vars in GAT substs) - #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file) - #93732 (add fut/back compat tests for implied trait bounds) - #93764 (:arrow_up: rust-analyzer) - #93767 (deduplicate `lcnr` in mailmap) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,HEART,2022-02-08T20:53:53Z,Daasin,NA https://github.com/rust-lang/rust/pull/93778,MERGED,2022-02-08T15:40:53Z,2022-02-09T04:05:57Z,Rollup of 7 pull requests,matthiaskrgr,9a5a961be97f405e751dd2cf966e1cdb80a612c2,19,Auto merge of #93778 - matthiaskrgr:rollup-yfngdao r=matthiaskrgr Rollup of 7 pull requests Successful merges: - #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`) - #92715 (Do not suggest char literal for zero-length strings) - #92917 (Don't constrain projection predicates with inference vars in GAT substs) - #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file) - #93732 (add fut/back compat tests for implied trait bounds) - #93764 (:arrow_up: rust-analyzer) - #93767 (deduplicate `lcnr` in mailmap) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,THUMBS_UP,2022-02-08T20:53:55Z,Daasin,NA https://github.com/rust-lang/rust/pull/93778,MERGED,2022-02-08T15:40:53Z,2022-02-09T04:05:57Z,Rollup of 7 pull requests,matthiaskrgr,9a5a961be97f405e751dd2cf966e1cdb80a612c2,19,Auto merge of #93778 - matthiaskrgr:rollup-yfngdao r=matthiaskrgr Rollup of 7 pull requests Successful merges: - #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`) - #92715 (Do not suggest char literal for zero-length strings) - #92917 (Don't constrain projection predicates with inference vars in GAT substs) - #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file) - #93732 (add fut/back compat tests for implied trait bounds) - #93764 (:arrow_up: rust-analyzer) - #93767 (deduplicate `lcnr` in mailmap) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,EYES,2022-02-08T20:54:00Z,Daasin,NA https://github.com/rust-lang/rust/pull/93783,MERGED,2022-02-08T16:48:55Z,2022-02-09T01:18:11Z,Fix regression from lazy opaque types,oli-obk,cc38176793e9e13bb7b70dde4b951d9371017662,7,Auto merge of #93783 - oli-obk:lazy_tait_regression_fix r=jackh726 Fix regression from lazy opaque types The breakage was found in https://github.com/rust-lang/rust/pull/92007#issuecomment-1032203011 and has not hit nightly yet.,HEART,2022-02-08T16:50:48Z,lqd,NA https://github.com/rust-lang/rust/pull/93789,CLOSED,2022-02-08T21:50:23Z,2022-02-08T22:00:28Z,Create Ejercico1.java,AitorTormo,NA,NA,NA,LAUGH,2022-02-08T21:59:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93790,CLOSED,2022-02-08T22:18:14Z,2022-03-09T02:59:03Z,[testing] rustc_macros experiments,ehuss,NA,NA,NA,HEART,2022-02-08T22:44:04Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93791,CLOSED,2022-02-09T00:12:21Z,2022-04-10T22:02:21Z,Force rlibs to be linked in whole for cdylib and bin,nbdd0121,NA,NA,NA,HOORAY,2022-02-09T02:30:45Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/93805,MERGED,2022-02-09T12:42:19Z,2022-03-06T04:41:25Z,rustdoc: Stop textually replacing `Self` in doc links before resolving them,petrochenkov,1661e4c7e0e68b4297aec095064d80566d4ea2b1,2,Auto merge of #93805 - petrochenkov:doclinkself r=camelid GuillaumeGomez rustdoc: Stop textually replacing `Self` in doc links before resolving them Resolve it directly to a type / def-id instead. Also never pass `Self` to `Resolver` it is useless because it's guaranteed that no resolution will be found. This is a pre-requisite for https://github.com/rust-lang/rust/issues/83761.,HEART,2022-02-09T19:31:33Z,camelid,NA https://github.com/rust-lang/rust/pull/93805,MERGED,2022-02-09T12:42:19Z,2022-03-06T04:41:25Z,rustdoc: Stop textually replacing `Self` in doc links before resolving them,petrochenkov,1661e4c7e0e68b4297aec095064d80566d4ea2b1,2,Auto merge of #93805 - petrochenkov:doclinkself r=camelid GuillaumeGomez rustdoc: Stop textually replacing `Self` in doc links before resolving them Resolve it directly to a type / def-id instead. Also never pass `Self` to `Resolver` it is useless because it's guaranteed that no resolution will be found. This is a pre-requisite for https://github.com/rust-lang/rust/issues/83761.,HEART,2022-02-14T23:37:57Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-09T14:13:07Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-09T14:15:41Z,jackh726,NA https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-09T14:39:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-09T17:11:26Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-09T17:17:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-10T13:58:51Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-10T14:48:27Z,zirconium-n,NA https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-11T03:36:37Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-13T09:53:43Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-16T19:18:09Z,pierwill,NA https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-19T20:36:12Z,plazmoid,NA https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-02-22T11:23:33Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/93810,MERGED,2022-02-09T14:10:29Z,2022-02-13T09:29:16Z,Improve chalk integration,matthewjasper,aff74a16971237f45182843388ac662c1822f960,51,Rollup merge of #93810 - matthewjasper:chalk-and-canonical-universes r=jackh726 Improve chalk integration - Support subtype bounds in chalk lowering - Handle universes in canonicalization - Handle type parameters in chalk responses - Use `chalk_ir::LifetimeData::Empty` for `ty::ReEmpty` - Remove `ignore-compare-mode-chalk` for tests that no longer hang (they may still fail or ICE) This is enough to get a hello world program to compile with `-Zchalk` now. Some of the remaining issues that are needed to get Chalk integration working on larger programs are: - rust-lang/chalk#234 - rust-lang/chalk#548 - rust-lang/chalk#734 - Generators are handled differently in chalk and rustc r? `@jackh726`,HEART,2022-03-02T20:34:12Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/93816,MERGED,2022-02-09T16:23:44Z,2022-02-20T14:25:13Z,Put crate metadata first in the rlib,bjorn3,3b186511f62b0ce20e72ede0e8e13f8787155f02,2,Auto merge of #93816 - bjorn3:rlib_metadata_first r=nagisa Put crate metadata first in the rlib This should make metadata lookup faster Fixes https://github.com/rust-lang/rust/issues/93806,THUMBS_UP,2022-02-25T08:12:51Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/93824,MERGED,2022-02-09T18:15:50Z,2022-02-10T15:29:55Z,Stabilize cfg_target_has_atomic,Amanieu,aa2095936af06baac88a88b2a62c7d77e24c972a,13,Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic r=davidtwco Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976,HOORAY,2022-02-09T18:27:11Z,taiki-e,NA https://github.com/rust-lang/rust/pull/93824,MERGED,2022-02-09T18:15:50Z,2022-02-10T15:29:55Z,Stabilize cfg_target_has_atomic,Amanieu,aa2095936af06baac88a88b2a62c7d77e24c972a,13,Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic r=davidtwco Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976,HOORAY,2022-02-09T20:30:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93824,MERGED,2022-02-09T18:15:50Z,2022-02-10T15:29:55Z,Stabilize cfg_target_has_atomic,Amanieu,aa2095936af06baac88a88b2a62c7d77e24c972a,13,Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic r=davidtwco Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976,HOORAY,2022-02-10T00:11:35Z,gelfand,NA https://github.com/rust-lang/rust/pull/93824,MERGED,2022-02-09T18:15:50Z,2022-02-10T15:29:55Z,Stabilize cfg_target_has_atomic,Amanieu,aa2095936af06baac88a88b2a62c7d77e24c972a,13,Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic r=davidtwco Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976,HOORAY,2022-02-10T09:37:54Z,mati865,NA https://github.com/rust-lang/rust/pull/93824,MERGED,2022-02-09T18:15:50Z,2022-02-10T15:29:55Z,Stabilize cfg_target_has_atomic,Amanieu,aa2095936af06baac88a88b2a62c7d77e24c972a,13,Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic r=davidtwco Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976,HOORAY,2022-02-17T02:12:26Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T19:03:40Z,taiki-e,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T19:05:34Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T19:20:43Z,Pratyush,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T20:07:23Z,oli-obk,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T20:30:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T22:36:55Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-09T23:49:44Z,kennykerr,kenny@kennykerr.ca https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-10T00:13:42Z,CryZe,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-10T14:00:04Z,bradjc,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-10T21:44:10Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-22T18:49:26Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-22T19:00:14Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-02-25T07:51:05Z,zirconium-n,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-02T21:57:52Z,mati865,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-03T04:29:47Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-03-03T07:18:42Z,jplatte,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-03T16:13:07Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-03-03T16:13:13Z,TornaxO7,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-07T20:06:05Z,tema3210,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-07T21:17:37Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-03-08T02:14:50Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-08T02:14:50Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-03-09T01:25:18Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-10T05:57:27Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-03-10T06:17:29Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-10T06:17:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-10T12:22:41Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-11T09:27:00Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-11T11:32:53Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-13T11:39:25Z,joseluis,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-15T21:36:25Z,VladasZ,146100@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-16T14:01:00Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-20T20:35:45Z,Milo123459,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-03-21T17:12:59Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-14T17:27:59Z,harrier-lcc,mmu20046f03@yahoo.com.hk https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-17T09:31:24Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-19T13:46:35Z,eminence,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-19T20:00:10Z,ranfdev,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",THUMBS_UP,2022-05-19T20:47:28Z,8picoz,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-19T20:47:28Z,8picoz,NA https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-20T18:33:32Z,CeleritasCelery,t.macman@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-05-22T09:12:25Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-06-01T07:53:31Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/93827,MERGED,2022-02-09T18:59:59Z,2022-03-07T20:35:07Z,Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait,eholk,9d7166c66f7d2cd7d2e51abae3e42a520fb359e0,104,"Rollup merge of #93827 - eholk:stabilize-const_fn-features r=wesleywiser Stabilize const_fn_fn_ptr_basics const_fn_trait_bound and const_impl_trait # Stabilization Report This PR serves as a request for stabilization for three const evaluation features: 1. `const_fn_fn_ptr_basics` 2. `const_fn_trait_bound` 3. `const_impl_trait` These are being stabilized together because they are relatively minor and related updates to existing functionality. ## `const_fn_fn_ptr_basics` Allows creating passing and casting function pointers in a `const fn`. The following is an example of what is now allowed: ```rust const fn get_function() -> fn() { fn foo() { println!(""Hello World!""); } foo } ``` Casts between function pointer types are allowed as well as transmuting from integers: ```rust const fn get_function() -> fn() { unsafe { std::mem::transmute(0x1234usize) } } ``` However casting from a function pointer to an integer is not allowed: ```rust const fn fn_to_usize(f: fn()) -> usize { f as usize //~ pointers cannot be cast to integers during const eval } ``` Calling function pointers is also not allowed. ```rust const fn call_fn_ptr(f: fn()) { f() //~ function pointers are not allowed in const fn } ``` ### Test Coverage The following tests include code that exercises this feature: - `src/test/ui/consts/issue-37550.rs` - `src/test/ui/consts/issue-46553.rs` - `src/test/ui/consts/issue-56164.rs` - `src/test/ui/consts/min_const_fn/allow_const_fn_ptr_run_pass.rs` - `src/test/ui/consts/min_const_fn/cast_fn.rs` - `src/test/ui/consts/min_const_fn/cmp_fn_pointers.rs` ## `const_fn_trait_bound` Allows trait bounds in `const fn`. Additionally this feature allows creating and passing `dyn Trait` objects. Examples such as the following are allowed by this feature: ```rust const fn do_thing(_x: &T) { // ... } ``` Previously only `Sized` was allowed as a trait bound. There is no way to call methods from the trait because trait methods cannot currently be marked as const. Allowing trait bounds in const functions does allow the const function to use the trait's associated types and constants. This feature also allowes `dyn Trait` types. These work equivalently to non-const code. Similar to other pointers in const code the value of a `dyn Trait` pointer cannot be observed. Note that due to https://github.com/rust-lang/rust/issues/90912 it was already possible to do the example above as follows: ```rust const fn do_thing(_x: &T) where (T ): Foo { // ... } ``` ### Test Coverage The following tests include code that exercises `const_fn_trait_bound`: - `src/test/ui/consts/const-fn.rs` - `src/test/ui/consts/issue-88071.rs` - `src/test/ui/consts/min_const_fn/min_const_fn.rs` - `src/test/ui/consts/min_const_fn/min_const_fn_dyn.rs` - `src/test/ui/nll/issue-55825-const-fn.rs` - Many of the tests in `src/test/ui/rfc-2632-const-trait-impl/` also exercise this feature. ## `const_impl_trait` Allows argument and return position `impl Trait` in a `const fn` such as in the following example: ```rust const fn do_thing(x: impl Foo) -> impl Foo { x } ``` Similar to generic parameters and function pointers this allows the creation of such opaque types but not doing anything with them beyond accessing associated types and constants. ### Test Coverage The following tests exercise this feature: - `src/test/ui/type-alias-impl-trait/issue-53096.rs` - `src/test/ui/type-alias-impl-trait/issue-53678-generator-and-const-fn.rs` ## Documentation These features are documented along with the other const evaluation features in the Rust Reference at https://doc.rust-lang.org/stable/reference/const_eval.html. There is a PR that updates this documentation to reflect the capabilities enabled by these features at https://github.com/rust-lang/reference/pull/1166. Tracking issues: #57563 #63997 #93706",HOORAY,2022-06-28T06:13:24Z,zohnannor,NA https://github.com/rust-lang/rust/pull/93834,CLOSED,2022-02-09T21:49:55Z,2022-02-09T22:29:46Z,Rollup of 6 pull requests,matthiaskrgr,NA,NA,NA,HEART,2022-02-09T21:56:09Z,jeremyBanks,_@jeremy.ca https://github.com/rust-lang/rust/pull/93836,MERGED,2022-02-09T22:30:00Z,2022-02-10T05:08:33Z,Rollup of 6 pull requests,matthiaskrgr,5d6ee0db96aada145725838379f909bbb8aa2312,30,Auto merge of #93836 - matthiaskrgr:rollup-d1ssiwl r=matthiaskrgr Rollup of 6 pull requests Successful merges: - #91443 (Better suggestions when user tries to collect into an unsized `[_]`) - #91504 (`#[used(linker)]` attribute) - #93503 (debuginfo: Fix DW_AT_containing_type vtable debuginfo regression) - #93753 (Complete removal of #[main] attribute from compiler) - #93799 (Fix typo in `std::fmt` docs) - #93813 (Make a few cleanup MIR passes public) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup,EYES,2022-02-09T23:28:01Z,jeremyBanks,_@jeremy.ca https://github.com/rust-lang/rust/pull/93837,MERGED,2022-02-09T22:31:04Z,2022-02-13T20:22:13Z,Update dist-(arm|armv7|armhf)-linux to Ubuntu 20.04,nikic,1a8fa2af1c909ae5c6180f978275894c75a90c44,3,Auto merge of #93837 - nikic:arm-update r=Mark-Simulacrum Update dist-(arm|armv7|armhf)-linux to Ubuntu 20.04 I believe this should be safe as actual artifacts will be produced by a cross toolchain. The build ran through cleanly locally. This came up in https://github.com/rust-lang/rust/pull/93577 where the host GCC ICEd during the LLD build. (Though I wonder why we build LLD for the host at all...) r? `@Mark-Simulacrum`,THUMBS_UP,2022-02-10T19:06:59Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/93837,MERGED,2022-02-09T22:31:04Z,2022-02-13T20:22:13Z,Update dist-(arm|armv7|armhf)-linux to Ubuntu 20.04,nikic,1a8fa2af1c909ae5c6180f978275894c75a90c44,3,Auto merge of #93837 - nikic:arm-update r=Mark-Simulacrum Update dist-(arm|armv7|armhf)-linux to Ubuntu 20.04 I believe this should be safe as actual artifacts will be produced by a cross toolchain. The build ran through cleanly locally. This came up in https://github.com/rust-lang/rust/pull/93577 where the host GCC ICEd during the LLD build. (Though I wonder why we build LLD for the host at all...) r? `@Mark-Simulacrum`,THUMBS_UP,2022-02-10T22:36:57Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/93839,MERGED,2022-02-09T23:22:03Z,2022-02-22T10:47:58Z,Simplify rustc_serialize by dropping support for decoding into JSON,Mark-Simulacrum,58a721af9f818bdf57f86448557b45c5ae19a3ef,15,Auto merge of #93839 - Mark-Simulacrum:delete-json-rust-deserialization r=nnethercote Simplify rustc_serialize by dropping support for decoding into JSON This PR currently bundles two (somewhat separate) tasks. First it removes the JSON Decoder trait impl which permitted going from JSON to Rust structs. For now we keep supporting JSON deserialization but only to `Json` (an equivalent of serde_json::Value). The primary hard to remove user there is for custom targets -- which need some form of JSON deserialization -- but they already have a custom ad-hoc pass for moving from Json to a Rust struct. A [comment](https://github.com/rust-lang/rust/blob/e7aca895980f25f6d2d3c48e10fd04656764d1e4/compiler/rustc_target/src/spec/mod.rs#L1653) there suggests that it would be impractical to move them to a Decodable-based impl at least without backwards compatibility concerns. I suspect that if we were widely breaking compat there it would make sense to use serde_json at this point which would produce better error messages; the types in rustc_target are relatively isolated so we would not particularly suffer from using serde_derive. The second part of the PR (all but the first commit) is to simplify the Decoder API by removing the non-primitive `read_*` functions. These primarily add indirection (through a closure) which doesn't directly cause a performance issue (the unique closure types essentially guarantee monomorphization) but does increase the amount of work rustc and LLVM need to do. This could be split out to a separate PR but is included here in part to help motivate the first part. Future work might consist of: * Specializing enum discriminant encoding to avoid leb128 for small enums (since we know the variant count we can directly use read/write u8 in almost all cases) * Adding new methods to support faster deserialization (e.g. access to the underlying byte stream) * Currently these are somewhat ad-hoc supported by specializations for e.g. `Vec` but other types which could benefit don't today. * Removing the Decoder trait entirely in favor of a concrete type -- today we only really have one impl of it modulo wrappers used for specialization-based dispatch. Highly recommend review with whitespace changes off as the removal of closures frequently causes things to be de-indented.,HEART,2022-02-12T12:57:36Z,bjorn3,NA https://github.com/rust-lang/rust/pull/93839,MERGED,2022-02-09T23:22:03Z,2022-02-22T10:47:58Z,Simplify rustc_serialize by dropping support for decoding into JSON,Mark-Simulacrum,58a721af9f818bdf57f86448557b45c5ae19a3ef,15,Auto merge of #93839 - Mark-Simulacrum:delete-json-rust-deserialization r=nnethercote Simplify rustc_serialize by dropping support for decoding into JSON This PR currently bundles two (somewhat separate) tasks. First it removes the JSON Decoder trait impl which permitted going from JSON to Rust structs. For now we keep supporting JSON deserialization but only to `Json` (an equivalent of serde_json::Value). The primary hard to remove user there is for custom targets -- which need some form of JSON deserialization -- but they already have a custom ad-hoc pass for moving from Json to a Rust struct. A [comment](https://github.com/rust-lang/rust/blob/e7aca895980f25f6d2d3c48e10fd04656764d1e4/compiler/rustc_target/src/spec/mod.rs#L1653) there suggests that it would be impractical to move them to a Decodable-based impl at least without backwards compatibility concerns. I suspect that if we were widely breaking compat there it would make sense to use serde_json at this point which would produce better error messages; the types in rustc_target are relatively isolated so we would not particularly suffer from using serde_derive. The second part of the PR (all but the first commit) is to simplify the Decoder API by removing the non-primitive `read_*` functions. These primarily add indirection (through a closure) which doesn't directly cause a performance issue (the unique closure types essentially guarantee monomorphization) but does increase the amount of work rustc and LLVM need to do. This could be split out to a separate PR but is included here in part to help motivate the first part. Future work might consist of: * Specializing enum discriminant encoding to avoid leb128 for small enums (since we know the variant count we can directly use read/write u8 in almost all cases) * Adding new methods to support faster deserialization (e.g. access to the underlying byte stream) * Currently these are somewhat ad-hoc supported by specializations for e.g. `Vec` but other types which could benefit don't today. * Removing the Decoder trait entirely in favor of a concrete type -- today we only really have one impl of it modulo wrappers used for specialization-based dispatch. Highly recommend review with whitespace changes off as the removal of closures frequently causes things to be de-indented.,HEART,2022-02-17T10:13:30Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/93839,MERGED,2022-02-09T23:22:03Z,2022-02-22T10:47:58Z,Simplify rustc_serialize by dropping support for decoding into JSON,Mark-Simulacrum,58a721af9f818bdf57f86448557b45c5ae19a3ef,15,Auto merge of #93839 - Mark-Simulacrum:delete-json-rust-deserialization r=nnethercote Simplify rustc_serialize by dropping support for decoding into JSON This PR currently bundles two (somewhat separate) tasks. First it removes the JSON Decoder trait impl which permitted going from JSON to Rust structs. For now we keep supporting JSON deserialization but only to `Json` (an equivalent of serde_json::Value). The primary hard to remove user there is for custom targets -- which need some form of JSON deserialization -- but they already have a custom ad-hoc pass for moving from Json to a Rust struct. A [comment](https://github.com/rust-lang/rust/blob/e7aca895980f25f6d2d3c48e10fd04656764d1e4/compiler/rustc_target/src/spec/mod.rs#L1653) there suggests that it would be impractical to move them to a Decodable-based impl at least without backwards compatibility concerns. I suspect that if we were widely breaking compat there it would make sense to use serde_json at this point which would produce better error messages; the types in rustc_target are relatively isolated so we would not particularly suffer from using serde_derive. The second part of the PR (all but the first commit) is to simplify the Decoder API by removing the non-primitive `read_*` functions. These primarily add indirection (through a closure) which doesn't directly cause a performance issue (the unique closure types essentially guarantee monomorphization) but does increase the amount of work rustc and LLVM need to do. This could be split out to a separate PR but is included here in part to help motivate the first part. Future work might consist of: * Specializing enum discriminant encoding to avoid leb128 for small enums (since we know the variant count we can directly use read/write u8 in almost all cases) * Adding new methods to support faster deserialization (e.g. access to the underlying byte stream) * Currently these are somewhat ad-hoc supported by specializations for e.g. `Vec` but other types which could benefit don't today. * Removing the Decoder trait entirely in favor of a concrete type -- today we only really have one impl of it modulo wrappers used for specialization-based dispatch. Highly recommend review with whitespace changes off as the removal of closures frequently causes things to be de-indented.,HEART,2022-02-17T22:23:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93839,MERGED,2022-02-09T23:22:03Z,2022-02-22T10:47:58Z,Simplify rustc_serialize by dropping support for decoding into JSON,Mark-Simulacrum,58a721af9f818bdf57f86448557b45c5ae19a3ef,15,Auto merge of #93839 - Mark-Simulacrum:delete-json-rust-deserialization r=nnethercote Simplify rustc_serialize by dropping support for decoding into JSON This PR currently bundles two (somewhat separate) tasks. First it removes the JSON Decoder trait impl which permitted going from JSON to Rust structs. For now we keep supporting JSON deserialization but only to `Json` (an equivalent of serde_json::Value). The primary hard to remove user there is for custom targets -- which need some form of JSON deserialization -- but they already have a custom ad-hoc pass for moving from Json to a Rust struct. A [comment](https://github.com/rust-lang/rust/blob/e7aca895980f25f6d2d3c48e10fd04656764d1e4/compiler/rustc_target/src/spec/mod.rs#L1653) there suggests that it would be impractical to move them to a Decodable-based impl at least without backwards compatibility concerns. I suspect that if we were widely breaking compat there it would make sense to use serde_json at this point which would produce better error messages; the types in rustc_target are relatively isolated so we would not particularly suffer from using serde_derive. The second part of the PR (all but the first commit) is to simplify the Decoder API by removing the non-primitive `read_*` functions. These primarily add indirection (through a closure) which doesn't directly cause a performance issue (the unique closure types essentially guarantee monomorphization) but does increase the amount of work rustc and LLVM need to do. This could be split out to a separate PR but is included here in part to help motivate the first part. Future work might consist of: * Specializing enum discriminant encoding to avoid leb128 for small enums (since we know the variant count we can directly use read/write u8 in almost all cases) * Adding new methods to support faster deserialization (e.g. access to the underlying byte stream) * Currently these are somewhat ad-hoc supported by specializations for e.g. `Vec` but other types which could benefit don't today. * Removing the Decoder trait entirely in favor of a concrete type -- today we only really have one impl of it modulo wrappers used for specialization-based dispatch. Highly recommend review with whitespace changes off as the removal of closures frequently causes things to be de-indented.,HEART,2022-02-25T20:34:32Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-10T00:14:07Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-10T04:20:10Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-10T09:38:49Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,THUMBS_UP,2022-02-10T10:11:09Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-10T12:20:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HOORAY,2022-02-10T14:52:29Z,KevinMGranger,kgranger@redhat.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HOORAY,2022-02-10T19:32:05Z,iago-lito,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-10T19:32:10Z,iago-lito,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-11T17:16:57Z,DianaNites,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-02-18T02:59:30Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,THUMBS_UP,2022-02-20T22:12:48Z,atlx,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,THUMBS_UP,2022-03-20T22:04:18Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,THUMBS_UP,2022-03-30T22:11:57Z,Lokathor,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-04-11T03:27:15Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,THUMBS_UP,2022-04-11T03:27:17Z,rickvanprim,NA https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HOORAY,2022-05-06T23:14:31Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/93840,MERGED,2022-02-09T23:46:45Z,2022-03-29T23:24:43Z,Stabilize Termination and ExitCode,yaahc,bba2a64d0c5ba20c4153676a09381b8703c197ba,4,Rollup merge of #93840 - yaahc:termination-stabilization-celebration-station r=joshtriplett Stabilize Termination and ExitCode From https://github.com/rust-lang/rust/issues/43301 This PR stabilizes the Termination trait and associated ExitCode type. It also adjusts the ExitCode feature flag to replace the placeholder flag with a more permanent name as well as splitting off the `to_i32` method behind its own permanently unstable feature flag. This PR stabilizes the termination trait with the following signature: ```rust pub trait Termination { fn report(self) -> ExitCode; } ``` The existing impls of `Termination` are effectively already stable due to the prior stabilization of `?` in main. This PR also stabilizes the following APIs on exit code ```rust #[derive(Clone Copy Debug)] pub struct ExitCode(_); impl ExitCode { pub const SUCCESS: ExitCode; pub const FAILURE: ExitCode; } impl From for ExitCode { /* ... */ } ``` --- All of the previous blockers have been resolved. The main ones that were resolved recently are: * The trait's name: We decided against changing this since none of the alternatives seemed particularly compelling. Instead we decided to end the bikeshedding and stick with the current name. ([link to the discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization/near/269793887)) * Issues around platform specific representations: We resolved this issue by changing the return type of `report` from `i32` to the opaque type `ExitCode`. That way we can change the underlying representation without affecting the API letting us offer full support for platform specific exit code APIs in the future. * Custom exit codes: We resolved this by adding `From for ExitCode`. We choose to only support u8 initially because it is the least common denominator between the sets of exit codes supported by our current platforms. In the future we anticipate adding platform specific extension traits to ExitCode for constructors from larger or negative numbers as needed.,HEART,2022-05-17T07:50:22Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93845,MERGED,2022-02-10T03:37:26Z,2022-02-25T16:10:02Z,Remove in band lifetimes,compiler-errors,ec4fc726b0f836c0ab3dcd66cb54ee42dd24121e,71,Rollup merge of #93845 - compiler-errors:in-band-lifetimes r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty and if we should instead do something intermediate for deprecate the feature first. r? `@scottmcm` (or feel free to reassign just saw your last comment on #44524) Closes #44524,HEART,2022-02-10T07:09:14Z,scottmcm,NA https://github.com/rust-lang/rust/pull/93845,MERGED,2022-02-10T03:37:26Z,2022-02-25T16:10:02Z,Remove in band lifetimes,compiler-errors,ec4fc726b0f836c0ab3dcd66cb54ee42dd24121e,71,Rollup merge of #93845 - compiler-errors:in-band-lifetimes r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty and if we should instead do something intermediate for deprecate the feature first. r? `@scottmcm` (or feel free to reassign just saw your last comment on #44524) Closes #44524,HEART,2022-02-11T01:23:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93849,CLOSED,2022-02-10T07:57:20Z,2022-02-12T04:38:17Z,Split `tests/ieee.rs` into smaller files,yerke,NA,NA,NA,CONFUSED,2022-02-10T09:24:39Z,Urgau,NA https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-10T08:42:26Z,kangalioo,NA https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-10T08:43:32Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-10T12:17:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-10T17:10:59Z,euclio,arussell123@gmail.com https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-11T07:03:16Z,worstpractice,NA https://github.com/rust-lang/rust/pull/93851,MERGED,2022-02-10T08:27:06Z,2022-02-13T09:29:16Z,More practical examples for `Option::and_then` & `Result::and_then`,cyqsimon,783b56ba68c5737d9593c6e9bb964b44b6889ddc,2,Rollup merge of #93851 - cyqsimon:option-examples r=scottmcm More practical examples for `Option::and_then` & `Result::and_then` To be blatantly honest I think the current example given for `Option::and_then` is objectively terrible. (No offence to whoever wrote them initially.) ```rust fn sq(x: u32) -> Option { Some(x * x) } fn nope(_: u32) -> Option { None } assert_eq!(Some(2).and_then(sq).and_then(sq) Some(16)); assert_eq!(Some(2).and_then(sq).and_then(nope) None); assert_eq!(Some(2).and_then(nope).and_then(sq) None); assert_eq!(None.and_then(sq).and_then(sq) None); ``` Current example: - does not demonstrate that `and_then` converts `Option` to `Option` - is far removed from any realistic code - generally just causes more confusion than it helps So I replaced them with two blocks: - the first one shows basic usage (including the type conversion) - the second one shows an example of typical usage Same thing with `Result::and_then`. Hopefully this helps with clarity.,THUMBS_UP,2022-02-15T20:00:06Z,edmorley,NA https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-10T18:04:36Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-10T18:55:25Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-10T22:26:57Z,jonaylor89,jonaylor89@gmail.com https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-10T23:48:15Z,dginev,deyan.ginev@gmail.com https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-11T10:39:25Z,tux3,NA https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-11T13:39:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93859,CLOSED,2022-02-10T15:27:39Z,2022-02-14T16:12:28Z,Don't bind hidden types when searching for matching impls,oli-obk,NA,NA,NA,HEART,2022-02-11T18:50:51Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/93870,MERGED,2022-02-10T18:47:14Z,2022-02-26T04:39:15Z,Fix switch on discriminant detection in a presence of coverage counters,tmiasko,0da6dd3e97b720129100ec943bb993eab77c2c11,2,Rollup merge of #93870 - tmiasko:const-precise-live-drops-with-coverage r=ecstatic-morse Fix switch on discriminant detection in a presence of coverage counters Fixes #93848. r? ``@ecstatic-morse``,HEART,2022-02-10T19:28:56Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/93870,MERGED,2022-02-10T18:47:14Z,2022-02-26T04:39:15Z,Fix switch on discriminant detection in a presence of coverage counters,tmiasko,0da6dd3e97b720129100ec943bb993eab77c2c11,2,Rollup merge of #93870 - tmiasko:const-precise-live-drops-with-coverage r=ecstatic-morse Fix switch on discriminant detection in a presence of coverage counters Fixes #93848. r? ``@ecstatic-morse``,HEART,2022-02-19T06:35:00Z,nicholasbishop,nbishop@nbishop.net https://github.com/rust-lang/rust/pull/93888,MERGED,2022-02-11T02:35:11Z,2022-02-12T01:23:35Z,Implement `AsFd` for `&T` and `&mut T`.,sunfishcode,34997f0114e30ebf81e38ab44b1a1e0ce55297ad,4,Rollup merge of #93888 - sunfishcode:sunfishcode/impl-asfd-for-ref r=joshtriplett Implement `AsFd` for `&T` and `&mut T`. Add implementations of `AsFd` for `&T` and `&mut T` so that users can write code like this: ```rust pub fn fchown(fd: F uid: Option gid: Option) -> io::Result<()> { ``` with `fd: F` rather than `fd: &F`. And similar for `AsHandle` and `AsSocket` on Windows. Also adjust the `fchown` example to pass the file by reference. The code can work either way now but passing by reference is more likely to be what users will want to do. This is an alternative to #93869 and is a simpler way to achieve the same goals: users don't need to pass borrowed-`BorrowedFd` arguments and it prevents a pitfall in the case where users write `fd: F` instead of `fd: &F`. r? ```@joshtriplett```,HOORAY,2022-02-11T19:32:17Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93888,MERGED,2022-02-11T02:35:11Z,2022-02-12T01:23:35Z,Implement `AsFd` for `&T` and `&mut T`.,sunfishcode,34997f0114e30ebf81e38ab44b1a1e0ce55297ad,4,Rollup merge of #93888 - sunfishcode:sunfishcode/impl-asfd-for-ref r=joshtriplett Implement `AsFd` for `&T` and `&mut T`. Add implementations of `AsFd` for `&T` and `&mut T` so that users can write code like this: ```rust pub fn fchown(fd: F uid: Option gid: Option) -> io::Result<()> { ``` with `fd: F` rather than `fd: &F`. And similar for `AsHandle` and `AsSocket` on Windows. Also adjust the `fchown` example to pass the file by reference. The code can work either way now but passing by reference is more likely to be what users will want to do. This is an alternative to #93869 and is a simpler way to achieve the same goals: users don't need to pass borrowed-`BorrowedFd` arguments and it prevents a pitfall in the case where users write `fd: F` instead of `fd: &F`. r? ```@joshtriplett```,HEART,2022-02-11T19:32:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T08:10:11Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T08:16:27Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T10:09:54Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T11:30:14Z,ldm0,ldm2993593805@163.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T13:06:52Z,pro465,NA https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T13:37:46Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T13:40:14Z,darksv,NA https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T17:33:52Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,HEART,2022-02-11T18:52:04Z,hawkw,eliza@buoyant.io https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T19:04:11Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,HEART,2022-02-11T20:02:27Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,HEART,2022-02-11T20:29:43Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,HEART,2022-02-11T21:27:31Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T21:27:32Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/93893,MERGED,2022-02-11T07:20:43Z,2022-02-11T20:01:45Z,Revert lazy TAIT PR,oli-obk,6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d,370,Auto merge of #93893 - oli-obk:sad_revert r=oli-obk Revert lazy TAIT PR Revert https://github.com/rust-lang/rust/pull/92306 (sorry `@Aaron1011 ` will include your changes in the fix PR) Revert https://github.com/rust-lang/rust/pull/93783 Revert https://github.com/rust-lang/rust/pull/92007 fixes https://github.com/rust-lang/rust/issues/93788 fixes https://github.com/rust-lang/rust/issues/93794 fixes https://github.com/rust-lang/rust/issues/93821 fixes https://github.com/rust-lang/rust/issues/93831 fixes https://github.com/rust-lang/rust/issues/93841,CONFUSED,2022-02-11T22:17:30Z,mati865,NA https://github.com/rust-lang/rust/pull/93898,MERGED,2022-02-11T11:10:04Z,2022-02-12T14:01:15Z,tidy: Extend error code check,GuillaumeGomez,16f490f3547e0784b1feb8df9cfd82d3b4a1c117,3,Rollup merge of #93898 - GuillaumeGomez:error-code-check r=Mark-Simulacrum tidy: Extend error code check We discovered in https://github.com/rust-lang/rust/pull/93845 that the error code tidy check didn't check everything: if you remove an error code from the listing even if it has an explanation then it should error. It also allowed me to put back `E0192` in that listing as well. r? ```@Mark-Simulacrum```,HOORAY,2022-02-11T12:43:04Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93901,MERGED,2022-02-11T12:26:43Z,2022-03-31T02:53:39Z,Stabilize native library modifier syntax and the `whole-archive` modifier specifically,petrochenkov,b75f384d0b0227000eff393e5d4e11bda56b293f,33,Rollup merge of #93901 - petrochenkov:linkmod r=wesleywiser Stabilize native library modifier syntax and the `whole-archive` modifier specifically Stabilization report: https://github.com/rust-lang/rust/pull/93901#issuecomment-1041325522 cc https://github.com/rust-lang/rust/issues/81490,HOORAY,2022-02-11T15:47:09Z,mati865,NA https://github.com/rust-lang/rust/pull/93901,MERGED,2022-02-11T12:26:43Z,2022-03-31T02:53:39Z,Stabilize native library modifier syntax and the `whole-archive` modifier specifically,petrochenkov,b75f384d0b0227000eff393e5d4e11bda56b293f,33,Rollup merge of #93901 - petrochenkov:linkmod r=wesleywiser Stabilize native library modifier syntax and the `whole-archive` modifier specifically Stabilization report: https://github.com/rust-lang/rust/pull/93901#issuecomment-1041325522 cc https://github.com/rust-lang/rust/issues/81490,THUMBS_UP,2022-02-11T19:27:04Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/93913,MERGED,2022-02-11T19:38:55Z,2022-03-04T05:15:16Z,Remove the everybody loops pass,bjorn3,c1585a17a3c1c969578c788bfe232954f86ef40b,11,Rollup merge of #93913 - bjorn3:remove_everybody_loops r=jackh726 Remove the everybody loops pass It isn't used anymore by rustdoc. Split out of https://github.com/rust-lang/rust/pull/92895. There has been some previous discussion there.,THUMBS_UP,2022-02-12T03:26:33Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/93913,MERGED,2022-02-11T19:38:55Z,2022-03-04T05:15:16Z,Remove the everybody loops pass,bjorn3,c1585a17a3c1c969578c788bfe232954f86ef40b,11,Rollup merge of #93913 - bjorn3:remove_everybody_loops r=jackh726 Remove the everybody loops pass It isn't used anymore by rustdoc. Split out of https://github.com/rust-lang/rust/pull/92895. There has been some previous discussion there.,THUMBS_UP,2022-02-12T20:21:10Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/93913,MERGED,2022-02-11T19:38:55Z,2022-03-04T05:15:16Z,Remove the everybody loops pass,bjorn3,c1585a17a3c1c969578c788bfe232954f86ef40b,11,Rollup merge of #93913 - bjorn3:remove_everybody_loops r=jackh726 Remove the everybody loops pass It isn't used anymore by rustdoc. Split out of https://github.com/rust-lang/rust/pull/92895. There has been some previous discussion there.,THUMBS_UP,2022-02-15T12:18:58Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/93913,MERGED,2022-02-11T19:38:55Z,2022-03-04T05:15:16Z,Remove the everybody loops pass,bjorn3,c1585a17a3c1c969578c788bfe232954f86ef40b,11,Rollup merge of #93913 - bjorn3:remove_everybody_loops r=jackh726 Remove the everybody loops pass It isn't used anymore by rustdoc. Split out of https://github.com/rust-lang/rust/pull/92895. There has been some previous discussion there.,THUMBS_UP,2022-02-17T18:12:41Z,weihanglo,NA https://github.com/rust-lang/rust/pull/93922,MERGED,2022-02-11T22:34:43Z,2022-02-12T21:42:07Z,[beta] backports,Mark-Simulacrum,1945ce6579506787e0b18f0a2ea03fdb4dfc81c7,38,Auto merge of #93922 - Mark-Simulacrum:beta-next r=Mark-Simulacrum [beta] backports This backports: * Complete removal of #[main] attribute from compiler #93753 * Resolve lifetimes for const generic defaults #93669 * backport llvm fix for issue 91671. #93426 * Fix invalid special casing of the unreachable! macro #93179 * Fix hashing for windows paths containing a CurDir component #93697 r? `@Mark-Simulacrum`,HEART,2022-02-11T23:47:21Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93922,MERGED,2022-02-11T22:34:43Z,2022-02-12T21:42:07Z,[beta] backports,Mark-Simulacrum,1945ce6579506787e0b18f0a2ea03fdb4dfc81c7,38,Auto merge of #93922 - Mark-Simulacrum:beta-next r=Mark-Simulacrum [beta] backports This backports: * Complete removal of #[main] attribute from compiler #93753 * Resolve lifetimes for const generic defaults #93669 * backport llvm fix for issue 91671. #93426 * Fix invalid special casing of the unreachable! macro #93179 * Fix hashing for windows paths containing a CurDir component #93697 r? `@Mark-Simulacrum`,HEART,2022-02-12T01:23:25Z,jeremyBanks,_@jeremy.ca https://github.com/rust-lang/rust/pull/93926,MERGED,2022-02-12T00:25:12Z,2022-03-01T05:40:04Z,Lint against more useless `#[must_use]` attributes,PatchMixolydic,daed86445de99e6dfcf128948bf34fff96c733ef,6,Rollup merge of #93926 - PatchMixolydic:bugfix/must_use-on-exprs r=cjgillot Lint against more useless `#[must_use]` attributes This expands the existing `#[must_use]` check in `unused_attributes` to lint against pretty much everything `#[must_use]` doesn't support. Fixes #93906.,HOORAY,2022-02-12T10:09:54Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/93926,MERGED,2022-02-12T00:25:12Z,2022-03-01T05:40:04Z,Lint against more useless `#[must_use]` attributes,PatchMixolydic,daed86445de99e6dfcf128948bf34fff96c733ef,6,Rollup merge of #93926 - PatchMixolydic:bugfix/must_use-on-exprs r=cjgillot Lint against more useless `#[must_use]` attributes This expands the existing `#[must_use]` check in `unused_attributes` to lint against pretty much everything `#[must_use]` doesn't support. Fixes #93906.,HOORAY,2022-03-10T15:14:58Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/93926,MERGED,2022-02-12T00:25:12Z,2022-03-01T05:40:04Z,Lint against more useless `#[must_use]` attributes,PatchMixolydic,daed86445de99e6dfcf128948bf34fff96c733ef,6,Rollup merge of #93926 - PatchMixolydic:bugfix/must_use-on-exprs r=cjgillot Lint against more useless `#[must_use]` attributes This expands the existing `#[must_use]` check in `unused_attributes` to lint against pretty much everything `#[must_use]` doesn't support. Fixes #93906.,HOORAY,2022-03-10T16:15:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/93938,MERGED,2022-02-12T11:37:27Z,2022-02-14T14:47:22Z,Make `Res::SelfTy` a struct variant and update docs,BoxyUwU,b321742c6c27494897a88cd5ac17ac20aa3469a1,27,Auto merge of #93938 - BoxyUwU:fix_res_self_ty r=lcnr Make `Res::SelfTy` a struct variant and update docs I found pattern matching on a `(Option Option<(DefId bool)>)` to not be super readable additionally the doc comments on the types in a tuple variant aren't visible anywhere at use sites as far as I can tell (using rust analyzer + vscode) The docs incorrectly assumed that the `DefId` in `Option<(DefId bool)>` would only ever be for an impl item and I also found the code examples to be somewhat unclear about which `DefId` was being talked about. r? `@lcnr` since you reviewed the last PR changing these docs,HEART,2022-02-12T23:06:20Z,camelid,NA https://github.com/rust-lang/rust/pull/93944,MERGED,2022-02-12T16:53:53Z,2022-02-13T09:29:16Z,Don't relabel to a team if there is already a team label,jackh726,20ea5c50135fd905ad70c38abaa2a3362cf5561a,1,Rollup merge of #93944 - jackh726:team-exclude r=Mark-Simulacrum Don't relabel to a team if there is already a team label Should prevent cases like #93628 where teams have been manually assigned but changes are pushed. We give up adding new labels on *new* changes; but I feel like that is less frequent. r? `@Mark-Simulacrum`,THUMBS_UP,2022-02-13T00:15:01Z,est31,NA https://github.com/rust-lang/rust/pull/93953,MERGED,2022-02-12T23:56:32Z,2022-02-19T05:08:20Z,Add the `known-bug` test directive use it and do some cleanup,jackh726,620b0c5122ee539124ed9442772e4648ac1d8b3f,22,Rollup merge of #93953 - jackh726:known_bug r=Mark-Simulacrum Add the `known-bug` test directive use it and do some cleanup cc rust-lang/compiler-team#476 Now tests can be annotated with `known-bug` which should indicate that the test *should* pass (or at least that the current output is a bug). Adding it relaxes the requirement to add error annotations to the test (though it is still allowed). In the future this could be extended with further relaxations - with the goal to make adding these tests need minimal effort. I've used this attribute for the GAT tests added in #93757. Finally I've also cleaned up `header.rs` in compiletest a bit by extracting out a bit of common logic. I've also split out some of the directives into their own consts. This removes a lot of very similar functions from `Config` and makes `TestProps::load_from` read nicer. I've split these into separate commits so I in theory could split these into separate PRs if they're controversial but I think they're pretty straightforward. r? ``@Mark-Simulacrum``,HOORAY,2022-02-13T13:17:36Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/93954,MERGED,2022-02-13T01:33:24Z,2022-02-19T14:55:56Z,rustdoc-json: buffer output,aDotInTheVoid,554aea90b8e382678de0e87e07210af19f67f0ab,1,"Rollup merge of #93954 - aDotInTheVoid:json-buffer r=Mark-Simulacrum rustdoc-json: buffer output It turns out we were doing syscalls for each part of the json syntax Before: ``` ... [pid 1801267] write(5 ""\"""" 1) = 1 [pid 1801267] write(5 "" "" 1) = 1 [pid 1801267] write(5 ""\"""" 1) = 1 ... ``` After: ``` [pid 1974821] write(5 ""{\""root\"":\""0:0\"" \""crate_version\"":nu""... 1575) = 1575 ``` In one benchmark (one struct almost all time in `std`) this gives ~2x perf r? `@CraftSpider` `@rustbot` modify labels: +A-rustdoc-json +T-rustdoc -A-testsuite",LAUGH,2022-02-13T01:36:01Z,Urgau,NA https://github.com/rust-lang/rust/pull/93954,MERGED,2022-02-13T01:33:24Z,2022-02-19T14:55:56Z,rustdoc-json: buffer output,aDotInTheVoid,554aea90b8e382678de0e87e07210af19f67f0ab,1,"Rollup merge of #93954 - aDotInTheVoid:json-buffer r=Mark-Simulacrum rustdoc-json: buffer output It turns out we were doing syscalls for each part of the json syntax Before: ``` ... [pid 1801267] write(5 ""\"""" 1) = 1 [pid 1801267] write(5 "" "" 1) = 1 [pid 1801267] write(5 ""\"""" 1) = 1 ... ``` After: ``` [pid 1974821] write(5 ""{\""root\"":\""0:0\"" \""crate_version\"":nu""... 1575) = 1575 ``` In one benchmark (one struct almost all time in `std`) this gives ~2x perf r? `@CraftSpider` `@rustbot` modify labels: +A-rustdoc-json +T-rustdoc -A-testsuite",HEART,2022-02-15T16:01:34Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/93954,MERGED,2022-02-13T01:33:24Z,2022-02-19T14:55:56Z,rustdoc-json: buffer output,aDotInTheVoid,554aea90b8e382678de0e87e07210af19f67f0ab,1,"Rollup merge of #93954 - aDotInTheVoid:json-buffer r=Mark-Simulacrum rustdoc-json: buffer output It turns out we were doing syscalls for each part of the json syntax Before: ``` ... [pid 1801267] write(5 ""\"""" 1) = 1 [pid 1801267] write(5 "" "" 1) = 1 [pid 1801267] write(5 ""\"""" 1) = 1 ... ``` After: ``` [pid 1974821] write(5 ""{\""root\"":\""0:0\"" \""crate_version\"":nu""... 1575) = 1575 ``` In one benchmark (one struct almost all time in `std`) this gives ~2x perf r? `@CraftSpider` `@rustbot` modify labels: +A-rustdoc-json +T-rustdoc -A-testsuite",LAUGH,2022-02-24T16:25:14Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/93957,MERGED,2022-02-13T07:47:19Z,2022-03-27T09:19:50Z,Stabilize const_ptr_offset,SaltyKitkat,223b58e484675bedc0fe4ed378e0ce8991fca1f3,21,Auto merge of #93957 - SaltyKitkat:stablize_const_ptr_offset r=dtolnay Stabilize const_ptr_offset Close #71499,THUMBS_UP,2022-02-19T23:21:01Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/93957,MERGED,2022-02-13T07:47:19Z,2022-03-27T09:19:50Z,Stabilize const_ptr_offset,SaltyKitkat,223b58e484675bedc0fe4ed378e0ce8991fca1f3,21,Auto merge of #93957 - SaltyKitkat:stablize_const_ptr_offset r=dtolnay Stabilize const_ptr_offset Close #71499,THUMBS_UP,2022-03-26T21:39:11Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/93957,MERGED,2022-02-13T07:47:19Z,2022-03-27T09:19:50Z,Stabilize const_ptr_offset,SaltyKitkat,223b58e484675bedc0fe4ed378e0ce8991fca1f3,21,Auto merge of #93957 - SaltyKitkat:stablize_const_ptr_offset r=dtolnay Stabilize const_ptr_offset Close #71499,THUMBS_UP,2022-03-31T14:16:49Z,GrayJack,NA https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-02-14T12:01:39Z,faern,NA https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-02-17T03:31:04Z,tlyu,tlyu@mit.edu https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-03-04T22:10:52Z,iwikal,NA https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-04-15T17:04:49Z,Stargateur,NA https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-05-19T20:43:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93965,MERGED,2022-02-13T15:25:33Z,2022-03-04T05:15:16Z,Make regular stdio lock() return 'static handles,Mark-Simulacrum,cdfb39ef07c9ee4c48905db5bf037937a96e2353,3,Rollup merge of #93965 - Mark-Simulacrum:owned-stdio r=dtolnay Make regular stdio lock() return 'static handles This also deletes the unstable API surface area previously added to expose this functionality on new methods rather than built into the current set. Closes #86845 (tracking issue for unstable API needed without this) r? ``````@dtolnay`````` to kick off T-libs-api FCP,HOORAY,2022-05-19T22:08:59Z,Virgiel,NA https://github.com/rust-lang/rust/pull/93966,MERGED,2022-02-13T16:09:31Z,2022-05-25T00:53:01Z,document expectations for Waker::wake,rkuhn,33f45b167e12f6c84f6f8e9dee90676f97c192e3,1,Rollup merge of #93966 - rkuhn:patch-1 r=tmandry document expectations for Waker::wake fixes #93961 Opened PR for a discussion on the precise wording.,EYES,2022-02-14T20:25:00Z,mxinden,mail@max-inden.de https://github.com/rust-lang/rust/pull/93967,MERGED,2022-02-13T16:41:00Z,2022-07-01T22:55:27Z,Shorten def_span for more items.,cjgillot,46b8c23f3eb5e4d0e0aa27eb3f20d5b8fc3ed51f,421,Auto merge of #93967 - cjgillot:short-struct-span r=petrochenkov Shorten def_span for more items. The `def_span` query only returns the signature span for functions. Struct/enum/union definitions can also have a very long body. This PR shortens the associated span.,THUMBS_UP,2022-02-14T09:29:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93967,MERGED,2022-02-13T16:41:00Z,2022-07-01T22:55:27Z,Shorten def_span for more items.,cjgillot,46b8c23f3eb5e4d0e0aa27eb3f20d5b8fc3ed51f,421,Auto merge of #93967 - cjgillot:short-struct-span r=petrochenkov Shorten def_span for more items. The `def_span` query only returns the signature span for functions. Struct/enum/union definitions can also have a very long body. This PR shortens the associated span.,THUMBS_UP,2022-06-26T11:28:01Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/93971,CLOSED,2022-02-13T19:26:34Z,2022-02-22T05:50:03Z,better errors when resolving bad Self in impl block,compiler-errors,NA,NA,NA,HEART,2022-02-13T19:37:56Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/93971,CLOSED,2022-02-13T19:26:34Z,2022-02-22T05:50:03Z,better errors when resolving bad Self in impl block,compiler-errors,NA,NA,NA,HEART,2022-02-13T19:41:14Z,marmeladema,NA https://github.com/rust-lang/rust/pull/93976,MERGED,2022-02-13T22:24:03Z,2022-02-18T02:10:47Z,Add MAIN_SEPARATOR_STR,SUPERCILEX,09350d2cf0bc3d931b47dfc4fdee69e76a0a50ad,1,Rollup merge of #93976 - SUPERCILEX:separator_str r=yaahc Add MAIN_SEPARATOR_STR Currently if someone needs access to the path separator as a str they need to go through this mess: ```rust unsafe { std::str::from_utf8_unchecked(slice::from_ref(&(MAIN_SEPARATOR as u8))) } ``` This PR just re-exports an existing path separator str API.,THUMBS_UP,2022-06-23T22:24:57Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/93977,MERGED,2022-02-13T22:30:07Z,2022-03-15T00:32:23Z,Type params and assoc types have unit metadata if they are sized,compiler-errors,774655da5fabdef01f862c50d1796abbe59efb7d,5,Rollup merge of #93977 - compiler-errors:sized-generic-metadata r=wesleywiser Type params and assoc types have unit metadata if they are sized Extend the logic in `Pointee` projection to ensure that we can satisfy `::Metadata = ()` if `T: Sized`. cc: `@SimonSapin` and #93959,HEART,2022-02-13T23:11:25Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/93977,MERGED,2022-02-13T22:30:07Z,2022-03-15T00:32:23Z,Type params and assoc types have unit metadata if they are sized,compiler-errors,774655da5fabdef01f862c50d1796abbe59efb7d,5,Rollup merge of #93977 - compiler-errors:sized-generic-metadata r=wesleywiser Type params and assoc types have unit metadata if they are sized Extend the logic in `Pointee` projection to ensure that we can satisfy `::Metadata = ()` if `T: Sized`. cc: `@SimonSapin` and #93959,THUMBS_UP,2022-02-14T13:41:02Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/93977,MERGED,2022-02-13T22:30:07Z,2022-03-15T00:32:23Z,Type params and assoc types have unit metadata if they are sized,compiler-errors,774655da5fabdef01f862c50d1796abbe59efb7d,5,Rollup merge of #93977 - compiler-errors:sized-generic-metadata r=wesleywiser Type params and assoc types have unit metadata if they are sized Extend the logic in `Pointee` projection to ensure that we can satisfy `::Metadata = ()` if `T: Sized`. cc: `@SimonSapin` and #93959,THUMBS_UP,2022-02-24T15:41:12Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/93978,CLOSED,2022-02-13T22:46:39Z,2022-03-31T18:40:53Z,Add `to_bits` and `from_bits` to `ptr::NonNull` as well,scottmcm,NA,NA,NA,EYES,2022-02-13T23:08:06Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93981,MERGED,2022-02-14T00:01:27Z,2022-02-17T13:08:51Z,Fix suggestion to slice if scurtinee is a reference to `Result` or `Option`,ChayimFriedman2,2c0df80a2ebf01c7200b17496b29ce3520420068,4,Rollup merge of #93981 - ChayimFriedman2:slice-pat-reference-option-result r=davidtwco Fix suggestion to slice if scurtinee is a reference to `Result` or `Option` Fixes https://github.com/rust-lang/rust/pull/91343#issuecomment-1037718339 and https://github.com/rust-lang/rust/pull/91343#discussion_r761466979.,HEART,2022-02-14T00:14:12Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/93981,MERGED,2022-02-14T00:01:27Z,2022-02-17T13:08:51Z,Fix suggestion to slice if scurtinee is a reference to `Result` or `Option`,ChayimFriedman2,2c0df80a2ebf01c7200b17496b29ce3520420068,4,Rollup merge of #93981 - ChayimFriedman2:slice-pat-reference-option-result r=davidtwco Fix suggestion to slice if scurtinee is a reference to `Result` or `Option` Fixes https://github.com/rust-lang/rust/pull/91343#issuecomment-1037718339 and https://github.com/rust-lang/rust/pull/91343#discussion_r761466979.,HEART,2022-02-15T19:49:09Z,edmorley,NA https://github.com/rust-lang/rust/pull/93984,MERGED,2022-02-14T05:26:58Z,2022-02-23T04:06:59Z,Introduce `ChunkedBitSet` and use it for some dataflow analyses.,nnethercote,bafe8d06e015eb00724d3d497516191d6681943f,14,Auto merge of #93984 - nnethercote:ChunkedBitSet r=Mark-Simulacrum Introduce `ChunkedBitSet` and use it for some dataflow analyses. This reduces peak memory usage significantly for some programs with very large functions. r? `@ghost`,HEART,2022-02-25T07:02:12Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/93984,MERGED,2022-02-14T05:26:58Z,2022-02-23T04:06:59Z,Introduce `ChunkedBitSet` and use it for some dataflow analyses.,nnethercote,bafe8d06e015eb00724d3d497516191d6681943f,14,Auto merge of #93984 - nnethercote:ChunkedBitSet r=Mark-Simulacrum Introduce `ChunkedBitSet` and use it for some dataflow analyses. This reduces peak memory usage significantly for some programs with very large functions. r? `@ghost`,HEART,2022-02-25T09:35:35Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/93984,MERGED,2022-02-14T05:26:58Z,2022-02-23T04:06:59Z,Introduce `ChunkedBitSet` and use it for some dataflow analyses.,nnethercote,bafe8d06e015eb00724d3d497516191d6681943f,14,Auto merge of #93984 - nnethercote:ChunkedBitSet r=Mark-Simulacrum Introduce `ChunkedBitSet` and use it for some dataflow analyses. This reduces peak memory usage significantly for some programs with very large functions. r? `@ghost`,HEART,2022-02-27T05:05:45Z,emtes,edelanuez@pm.me https://github.com/rust-lang/rust/pull/93984,MERGED,2022-02-14T05:26:58Z,2022-02-23T04:06:59Z,Introduce `ChunkedBitSet` and use it for some dataflow analyses.,nnethercote,bafe8d06e015eb00724d3d497516191d6681943f,14,Auto merge of #93984 - nnethercote:ChunkedBitSet r=Mark-Simulacrum Introduce `ChunkedBitSet` and use it for some dataflow analyses. This reduces peak memory usage significantly for some programs with very large functions. r? `@ghost`,HEART,2022-03-03T10:16:50Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/93984,MERGED,2022-02-14T05:26:58Z,2022-02-23T04:06:59Z,Introduce `ChunkedBitSet` and use it for some dataflow analyses.,nnethercote,bafe8d06e015eb00724d3d497516191d6681943f,14,Auto merge of #93984 - nnethercote:ChunkedBitSet r=Mark-Simulacrum Introduce `ChunkedBitSet` and use it for some dataflow analyses. This reduces peak memory usage significantly for some programs with very large functions. r? `@ghost`,HEART,2022-03-25T07:39:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93999,MERGED,2022-02-14T19:28:00Z,2022-02-15T19:03:44Z,suggest using raw strings when invalid escapes appear in literals,barzamin,c6b27db8767a6e070701d22a179caac60592f713,4,"Rollup merge of #93999 - barzamin:suggest-raw-strings r=jackh726 suggest using raw strings when invalid escapes appear in literals i'd guess about 70% of ""bad escape"" cases occur when someone meant to use a raw string literal because they're passing it directly to `Regex::new()`. this emits an advisory (`Applicability::MaybeIncorrect`) `help:` suggestion to the user that they use an `r""""` string on top of the normal notes about looking at the string literal documentation/spec.",THUMBS_UP,2022-02-14T20:00:31Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/93999,MERGED,2022-02-14T19:28:00Z,2022-02-15T19:03:44Z,suggest using raw strings when invalid escapes appear in literals,barzamin,c6b27db8767a6e070701d22a179caac60592f713,4,"Rollup merge of #93999 - barzamin:suggest-raw-strings r=jackh726 suggest using raw strings when invalid escapes appear in literals i'd guess about 70% of ""bad escape"" cases occur when someone meant to use a raw string literal because they're passing it directly to `Regex::new()`. this emits an advisory (`Applicability::MaybeIncorrect`) `help:` suggestion to the user that they use an `r""""` string on top of the normal notes about looking at the string literal documentation/spec.",THUMBS_UP,2022-02-14T20:18:12Z,9999years,rbt@sent.as https://github.com/rust-lang/rust/pull/93999,MERGED,2022-02-14T19:28:00Z,2022-02-15T19:03:44Z,suggest using raw strings when invalid escapes appear in literals,barzamin,c6b27db8767a6e070701d22a179caac60592f713,4,"Rollup merge of #93999 - barzamin:suggest-raw-strings r=jackh726 suggest using raw strings when invalid escapes appear in literals i'd guess about 70% of ""bad escape"" cases occur when someone meant to use a raw string literal because they're passing it directly to `Regex::new()`. this emits an advisory (`Applicability::MaybeIncorrect`) `help:` suggestion to the user that they use an `r""""` string on top of the normal notes about looking at the string literal documentation/spec.",THUMBS_UP,2022-02-14T21:11:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/93999,MERGED,2022-02-14T19:28:00Z,2022-02-15T19:03:44Z,suggest using raw strings when invalid escapes appear in literals,barzamin,c6b27db8767a6e070701d22a179caac60592f713,4,"Rollup merge of #93999 - barzamin:suggest-raw-strings r=jackh726 suggest using raw strings when invalid escapes appear in literals i'd guess about 70% of ""bad escape"" cases occur when someone meant to use a raw string literal because they're passing it directly to `Regex::new()`. this emits an advisory (`Applicability::MaybeIncorrect`) `help:` suggestion to the user that they use an `r""""` string on top of the normal notes about looking at the string literal documentation/spec.",THUMBS_UP,2022-02-15T02:47:57Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),THUMBS_UP,2022-02-15T05:18:40Z,fmease,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),HEART,2022-02-16T02:50:04Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),HEART,2022-02-16T10:18:41Z,marmeladema,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),THUMBS_UP,2022-03-04T06:47:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),HEART,2022-03-06T22:32:59Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),THUMBS_UP,2022-03-06T22:32:59Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),HEART,2022-03-10T15:16:10Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),THUMBS_UP,2022-03-10T15:16:13Z,ebkalderon,NA https://github.com/rust-lang/rust/pull/94009,MERGED,2022-02-15T03:53:16Z,2022-03-04T02:53:45Z,Support GATs in Rustdoc,compiler-errors,6d7684101a51f1c375ec84aef5d2fbdeb214bbc2,15,Auto merge of #94009 - compiler-errors:gat-rustdoc r=GuillaumeGomez Support GATs in Rustdoc Implements: 1. Rendering GATs in trait definitions and impl blocks 2. Rendering GATs in types (e.g. in the return type of a function) Fixes #92341 This is my first rustdoc PR so I have absolutely no idea how to produce tests for this. Advice from the rustdoc team would be wonderful! I tested locally and things looked correct: ![image](https://user-images.githubusercontent.com/3674314/153988325-9732cbf3-0645-4e1a-9e64-ddfd93877b55.png),HEART,2022-06-14T02:45:51Z,rrbutani,NA https://github.com/rust-lang/rust/pull/94011,MERGED,2022-02-15T05:21:55Z,2022-02-18T02:10:47Z,Even more let_else adoptions,est31,637d8b89e8b433f5eb93f9d7ea8e8599a15a6451,26,Rollup merge of #94011 - est31:let_else r=lcnr Even more let_else adoptions Continuation of #89933 #91018 #91481 #93046 #93590.,HEART,2022-02-15T22:02:12Z,bstrie,NA https://github.com/rust-lang/rust/pull/94012,OPEN,2022-02-15T06:02:08Z,NA,Change desugaring of let-else to ensure temporary is dropped earlier,cormacrelf,NA,NA,NA,HEART,2022-02-15T11:56:26Z,est31,NA https://github.com/rust-lang/rust/pull/94012,OPEN,2022-02-15T06:02:08Z,NA,Change desugaring of let-else to ensure temporary is dropped earlier,cormacrelf,NA,NA,NA,HOORAY,2022-02-15T11:57:01Z,est31,NA https://github.com/rust-lang/rust/pull/94012,OPEN,2022-02-15T06:02:08Z,NA,Change desugaring of let-else to ensure temporary is dropped earlier,cormacrelf,NA,NA,NA,HOORAY,2022-07-01T20:42:49Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94015,MERGED,2022-02-15T10:49:33Z,2022-02-16T22:11:32Z,rustdoc --check option documentation,GuillaumeGomez,75a631d4ba6bc1043a6eb0d4807dbceff316a354,1,Rollup merge of #94015 - GuillaumeGomez:check-option r=notriddle rustdoc --check option documentation Part of #92763. r? ```@notriddle```,HOORAY,2022-02-17T15:16:22Z,edmorley,NA https://github.com/rust-lang/rust/pull/94030,MERGED,2022-02-15T21:31:31Z,2022-02-17T13:08:50Z,Correctly mark the span of captured arguments in `format_args!()`,ChayimFriedman2,a1a750b5adce06fc77b22ee32eecd7c83ad2d090,15,Rollup merge of #94030 - ChayimFriedman2:issue-94010 r=petrochenkov Correctly mark the span of captured arguments in `format_args!()` It should not include the braces or misspelling suggestions will be wrong. Fixes #94010.,HEART,2022-02-24T17:19:52Z,estebank,NA https://github.com/rust-lang/rust/pull/94031,MERGED,2022-02-15T21:32:43Z,2022-02-17T13:08:50Z,[diagnostics] Add mentions to `Copy` types being valid for `union` fields,danielhenrymantilla,91f70a8fdf3f39895d72d0b117722cff141015cf,10,"Rollup merge of #94031 - danielhenrymantilla:diagnostics/union-drop-suggest-copy-bound-alternative r=davidtwco [diagnostics] Add mentions to `Copy` types being valid for `union` fields This came up from some user on Discord which was using a `T : PrimitiveInt` generic type and they wanted to use in a `union`. Rather than adding a `Copy` bound they started pondering about the `ManuallyDrop` road and how to correctly use `unsafe` to perform the drops. - [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320) So it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative since in many cases where `union`s are concerned people are dealing with PODs / `Copy` types anyways 🙂 ___ ``@rustbot`` modify labels: +A-diagnostics +D-terse",HEART,2022-02-16T08:12:06Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94031,MERGED,2022-02-15T21:32:43Z,2022-02-17T13:08:50Z,[diagnostics] Add mentions to `Copy` types being valid for `union` fields,danielhenrymantilla,91f70a8fdf3f39895d72d0b117722cff141015cf,10,"Rollup merge of #94031 - danielhenrymantilla:diagnostics/union-drop-suggest-copy-bound-alternative r=davidtwco [diagnostics] Add mentions to `Copy` types being valid for `union` fields This came up from some user on Discord which was using a `T : PrimitiveInt` generic type and they wanted to use in a `union`. Rather than adding a `Copy` bound they started pondering about the `ManuallyDrop` road and how to correctly use `unsafe` to perform the drops. - [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320) So it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative since in many cases where `union`s are concerned people are dealing with PODs / `Copy` types anyways 🙂 ___ ``@rustbot`` modify labels: +A-diagnostics +D-terse",HEART,2022-02-24T23:40:29Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94034,MERGED,2022-02-15T22:52:47Z,2022-04-26T10:14:15Z,Fix incorrect suggestion for trait bounds involving binary operators,willcrichton,d6a57d3730a4e523c433e5528988a2a4f111e94e,10,Auto merge of #94034 - willcrichton:fix-trait-suggestion-for-binops r=estebank Fix incorrect suggestion for trait bounds involving binary operators This PR fixes #93927 #92347 #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path. The downside is that this fix causes some suggestions to not include an `Output=` type reducing their usefulness. Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.,HEART,2022-02-16T18:46:25Z,estebank,NA https://github.com/rust-lang/rust/pull/94034,MERGED,2022-02-15T22:52:47Z,2022-04-26T10:14:15Z,Fix incorrect suggestion for trait bounds involving binary operators,willcrichton,d6a57d3730a4e523c433e5528988a2a4f111e94e,10,Auto merge of #94034 - willcrichton:fix-trait-suggestion-for-binops r=estebank Fix incorrect suggestion for trait bounds involving binary operators This PR fixes #93927 #92347 #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path. The downside is that this fix causes some suggestions to not include an `Output=` type reducing their usefulness. Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.,HEART,2022-02-22T18:37:52Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94034,MERGED,2022-02-15T22:52:47Z,2022-04-26T10:14:15Z,Fix incorrect suggestion for trait bounds involving binary operators,willcrichton,d6a57d3730a4e523c433e5528988a2a4f111e94e,10,Auto merge of #94034 - willcrichton:fix-trait-suggestion-for-binops r=estebank Fix incorrect suggestion for trait bounds involving binary operators This PR fixes #93927 #92347 #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path. The downside is that this fix causes some suggestions to not include an `Output=` type reducing their usefulness. Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.,HEART,2022-05-08T06:14:42Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/94034,MERGED,2022-02-15T22:52:47Z,2022-04-26T10:14:15Z,Fix incorrect suggestion for trait bounds involving binary operators,willcrichton,d6a57d3730a4e523c433e5528988a2a4f111e94e,10,Auto merge of #94034 - willcrichton:fix-trait-suggestion-for-binops r=estebank Fix incorrect suggestion for trait bounds involving binary operators This PR fixes #93927 #92347 #93744 by replacing the bespoke trait-suggestion logic in `op.rs` with a more common code path. The downside is that this fix causes some suggestions to not include an `Output=` type reducing their usefulness. Note that this causes one case in the `missing-bounds.rs` test to fail rustfix. So I would need to move that code into a separate non-fix test if this PR is otherwise acceptable.,HEART,2022-05-18T10:32:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-16T10:13:32Z,marmeladema,NA https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-19T17:38:54Z,pachi,NA https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-24T05:03:30Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-24T07:24:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-25T15:08:20Z,krdln,NA https://github.com/rust-lang/rust/pull/94041,MERGED,2022-02-16T03:40:25Z,2022-02-18T02:10:47Z,Add a `try_collect()` helper method to `Iterator`,a-lafrance,a4be35e3217e85e35693837cac5bdc8285add15a,3,Rollup merge of #94041 - a-lafrance:try-collect r=scottmcm Add a `try_collect()` helper method to `Iterator` Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance). First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced. As the main participant in the internals discussion: r? `@scottmcm`,HEART,2022-02-27T10:06:24Z,aznhe21,NA https://github.com/rust-lang/rust/pull/94043,MERGED,2022-02-16T04:05:05Z,2022-02-18T02:10:47Z,Fix ICE when using Box with pointer sized A,DrMeepster,6dc62f421dcfb14f10a658de40c5140a083b3aed,2,Rollup merge of #94043 - DrMeepster:box_alloc_ice r=oli-obk Fix ICE when using Box with pointer sized A Fixes #78459 Note that using `Box` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.,HEART,2022-02-17T05:48:47Z,woppopo,NA https://github.com/rust-lang/rust/pull/94043,MERGED,2022-02-16T04:05:05Z,2022-02-18T02:10:47Z,Fix ICE when using Box with pointer sized A,DrMeepster,6dc62f421dcfb14f10a658de40c5140a083b3aed,2,Rollup merge of #94043 - DrMeepster:box_alloc_ice r=oli-obk Fix ICE when using Box with pointer sized A Fixes #78459 Note that using `Box` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.,HEART,2022-02-18T11:46:45Z,athre0z,joel@zyantific.com https://github.com/rust-lang/rust/pull/94043,MERGED,2022-02-16T04:05:05Z,2022-02-18T02:10:47Z,Fix ICE when using Box with pointer sized A,DrMeepster,6dc62f421dcfb14f10a658de40c5140a083b3aed,2,Rollup merge of #94043 - DrMeepster:box_alloc_ice r=oli-obk Fix ICE when using Box with pointer sized A Fixes #78459 Note that using `Box` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.,HEART,2022-02-21T09:50:13Z,tema3210,NA https://github.com/rust-lang/rust/pull/94068,MERGED,2022-02-16T23:15:27Z,2022-02-25T11:00:37Z,Consider mutations as borrows in generator drop tracking,eholk,10070118add69bd55d8cb0bec574b4dc920c3531,4,Rollup merge of #94068 - eholk:drop-track-field-assign r=tmandry Consider mutations as borrows in generator drop tracking This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points. r? `@nikomatsakis`,HEART,2022-02-21T17:48:10Z,tema3210,NA https://github.com/rust-lang/rust/pull/94068,MERGED,2022-02-16T23:15:27Z,2022-02-25T11:00:37Z,Consider mutations as borrows in generator drop tracking,eholk,10070118add69bd55d8cb0bec574b4dc920c3531,4,Rollup merge of #94068 - eholk:drop-track-field-assign r=tmandry Consider mutations as borrows in generator drop tracking This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points. r? `@nikomatsakis`,HEART,2022-03-01T18:33:58Z,guswynn,guswynn@gmail.com https://github.com/rust-lang/rust/pull/94068,MERGED,2022-02-16T23:15:27Z,2022-02-25T11:00:37Z,Consider mutations as borrows in generator drop tracking,eholk,10070118add69bd55d8cb0bec574b4dc920c3531,4,Rollup merge of #94068 - eholk:drop-track-field-assign r=tmandry Consider mutations as borrows in generator drop tracking This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points. r? `@nikomatsakis`,HEART,2022-03-03T04:47:04Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-02-17T09:50:34Z,Urgau,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-02-17T12:30:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-02-17T14:07:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-02-17T14:26:13Z,bugadani,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-02-18T00:32:56Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-09T12:09:50Z,krdln,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-09T14:26:17Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-12T09:57:39Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-23T08:17:22Z,SimonSapin,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-23T09:49:10Z,bjorn3,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-03-26T09:57:49Z,oli-obk,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-04-05T13:12:21Z,cynecx,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-04-07T01:33:56Z,archseer,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-04-11T06:29:19Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-04-26T06:44:43Z,mohe2015,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-05T11:36:18Z,oxalica,oxalicc@pm.me https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-08T07:00:37Z,aliemjay,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-09T06:24:02Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-15T02:07:29Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-17T17:10:30Z,SabrinaJewson,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-05-27T05:54:49Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-06-06T23:53:37Z,vacuus,rocyu@protonmail.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-06-10T13:50:59Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-06-16T22:23:01Z,sffc,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-06-22T17:25:44Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-06-27T00:23:34Z,cmpute,NA https://github.com/rust-lang/rust/pull/94075,OPEN,2022-02-17T07:40:53Z,NA,Use niche-filling optimization even when multiple variants have data.,mikebenfield,NA,NA,NA,HEART,2022-07-11T16:24:03Z,moshg,NA https://github.com/rust-lang/rust/pull/94078,MERGED,2022-02-17T10:38:28Z,2022-02-26T14:23:26Z,Suggest a float literal when dividing a floating-point type by `{integer}`,TaKO8Ki,8c9640e34c73dc45bfd38eca49fa1405b11b6cae,12,Auto merge of #94078 - TaKO8Ki:suggest-float-literal-for-float-divided-by-integer r=estebank Suggest a float literal when dividing a floating-point type by `{integer}` closes #93829,THUMBS_UP,2022-02-17T10:42:14Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/94078,MERGED,2022-02-17T10:38:28Z,2022-02-26T14:23:26Z,Suggest a float literal when dividing a floating-point type by `{integer}`,TaKO8Ki,8c9640e34c73dc45bfd38eca49fa1405b11b6cae,12,Auto merge of #94078 - TaKO8Ki:suggest-float-literal-for-float-divided-by-integer r=estebank Suggest a float literal when dividing a floating-point type by `{integer}` closes #93829,THUMBS_UP,2022-02-17T14:49:46Z,danielg1111,NA https://github.com/rust-lang/rust/pull/94078,MERGED,2022-02-17T10:38:28Z,2022-02-26T14:23:26Z,Suggest a float literal when dividing a floating-point type by `{integer}`,TaKO8Ki,8c9640e34c73dc45bfd38eca49fa1405b11b6cae,12,Auto merge of #94078 - TaKO8Ki:suggest-float-literal-for-float-divided-by-integer r=estebank Suggest a float literal when dividing a floating-point type by `{integer}` closes #93829,HEART,2022-02-17T16:50:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94078,MERGED,2022-02-17T10:38:28Z,2022-02-26T14:23:26Z,Suggest a float literal when dividing a floating-point type by `{integer}`,TaKO8Ki,8c9640e34c73dc45bfd38eca49fa1405b11b6cae,12,Auto merge of #94078 - TaKO8Ki:suggest-float-literal-for-float-divided-by-integer r=estebank Suggest a float literal when dividing a floating-point type by `{integer}` closes #93829,HEART,2022-02-24T09:55:34Z,estebank,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-02-17T16:33:25Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-02-17T17:55:22Z,stevemk14ebr,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-02-17T19:04:51Z,Animeshz,animeshsahu19@yahoo.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-02-17T19:33:43Z,panaman67,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,THUMBS_UP,2022-02-17T20:11:12Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-02-17T20:19:47Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-02-18T10:13:42Z,hkratz,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-02-23T23:55:30Z,mati865,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-02-23T23:55:39Z,mati865,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-03-18T11:37:24Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-03-21T11:07:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-03-21T11:07:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-03-25T13:49:27Z,ayrtonm,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-04-16T02:50:50Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-04-21T03:07:37Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-04-21T03:07:38Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,THUMBS_UP,2022-04-21T03:07:40Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HEART,2022-04-21T14:15:02Z,DianaNites,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-04-21T14:15:03Z,DianaNites,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,THUMBS_UP,2022-04-22T13:01:41Z,chrysn,NA https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-04-24T03:09:31Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-04-24T18:30:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-05-03T12:40:13Z,js2xxx,development2014@outlook.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-05-09T06:00:38Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-06-19T14:04:12Z,phip1611,phip1611@gmail.com https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-06-28T19:39:23Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/94079,MERGED,2022-02-17T11:04:48Z,2022-04-15T18:28:17Z,library: Move `CStr` to libcore and `CString` to liballoc,petrochenkov,1e6fe5855a115ef7f17f3e17205fab7340775701,28,Auto merge of #94079 - petrochenkov:cstr r=joshtriplett library: Move `CStr` to libcore and `CString` to liballoc Closes https://github.com/rust-lang/rust/issues/46736 Interesting points: - Stability: - To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.) - Relying on target ABI in libcore is ok: - https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371 - `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode otherwise lang items are used instead) - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 - `strlen` - https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450 Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.,HOORAY,2022-07-11T10:05:13Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T13:59:57Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T14:27:56Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T15:42:19Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T16:00:52Z,darksv,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-17T16:11:33Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-17T16:14:30Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T17:15:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-17T17:15:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-17T21:06:56Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-18T00:06:20Z,mati865,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-18T00:06:23Z,mati865,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-18T05:27:17Z,pro465,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-18T05:27:19Z,pro465,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-21T12:01:03Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-21T15:32:50Z,tema3210,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-21T15:32:52Z,tema3210,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-21T16:17:26Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-21T16:17:28Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-23T13:56:23Z,lqd,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-24T22:57:59Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-25T08:10:33Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-02-25T08:10:34Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-26T19:16:22Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-02-27T15:20:38Z,iceghost,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-08T19:25:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-08T19:25:24Z,cramertj,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-14T09:30:16Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-14T19:24:37Z,ljedrz,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-14T21:43:20Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-14T21:43:22Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-21T10:29:46Z,gtsiam,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-24T01:40:02Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-24T01:40:03Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-24T09:16:01Z,tyranron,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HEART,2022-03-24T14:13:38Z,RalfJung,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-25T05:18:57Z,lukechu10,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-03-30T09:32:18Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-04-07T05:35:18Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-04-10T07:41:57Z,korken89,emil.fresk@gmail.com https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-04-29T13:58:22Z,kraktus,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-05-22T08:40:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-06-28T06:18:50Z,zohnannor,NA https://github.com/rust-lang/rust/pull/94081,MERGED,2022-02-17T13:56:51Z,2022-03-30T07:45:48Z,Lazy type-alias-impl-trait take two,oli-obk,f132bcf3bdf6d3ff9be7d02e8d0088b99007cd5e,419,Auto merge of #94081 - oli-obk:lazy_tait_take_two r=nikomatsakis Lazy type-alias-impl-trait take two ### user visible change 1: RPIT inference from recursive call sites Lazy TAIT has an insta-stable change. The following snippet now compiles because opaque types can now have their hidden type set from wherever the opaque type is mentioned. ```rust fn bar(b: bool) -> impl std::fmt::Debug { if b { return 42 } let x: u32 = bar(false); // this errors on stable 99 } ``` The return type of `bar` stays opaque you can't do `bar(false) + 42` you need to actually mention the hidden type. ### user visible change 2: divergence between RPIT and TAIT in return statements Note that `return` statements and the trailing return expression are special with RPIT (but not TAIT). So ```rust #![feature(type_alias_impl_trait)] type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![42]; } std::iter::empty().collect() //~ ERROR `Foo` cannot be built from an iterator } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![42] } std::iter::empty().collect() // Works magic (accidentally stabilized not intended) } ``` But when we are working with the return value of a recursive call the behavior of RPIT and TAIT is the same: ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { return vec![]; } let mut x = foo(false); x = std::iter::empty().collect(); //~ ERROR `Foo` cannot be built from an iterator vec![] } fn bar(b: bool) -> impl std::fmt::Debug { if b { return vec![]; } let mut x = bar(false); x = std::iter::empty().collect(); //~ ERROR `impl Debug` cannot be built from an iterator vec![] } ``` ### user visible change 3: TAIT does not merge types across branches In contrast to RPIT TAIT does not merge types across branches so the following does not compile. ```rust type Foo = impl std::fmt::Debug; fn foo(b: bool) -> Foo { if b { vec![42_i32] } else { std::iter::empty().collect() //~^ ERROR `Foo` cannot be built from an iterator over elements of type `_` } } ``` It is easy to support but we should make an explicit decision to include the additional complexity in the implementation (it's not much see a721052457cf513487fb4266e3ade65c29b272d2 which needs to be reverted to enable this). ### PR formalities previous attempt: #92007 This PR also includes #92306 and #93783 as they were reverted along with #92007 in #93893 fixes #93411 fixes #88236 fixes #89312 fixes #87340 fixes #86800 fixes #86719 fixes #84073 fixes #83919 fixes #82139 fixes #77987 fixes #74282 fixes #67830 fixes #62742 fixes #54895,HOORAY,2022-06-28T08:20:58Z,gimbles,NA https://github.com/rust-lang/rust/pull/94105,MERGED,2022-02-17T22:30:59Z,2022-02-19T08:24:27Z,Destabilise entry_insert,5225225,cb4ee81ef555126e49b3e9f16ca6f12a3264a451,1,Auto merge of #94105 - 5225225:destabilise-entry-insert r=Mark-Simulacrum Destabilise entry_insert See: https://github.com/rust-lang/rust/pull/90345 I didn't revert the rename that was done in that PR I left it as `entry_insert`. Additionally before that PR `VacantEntry::insert_entry` seemingly had no stability attribute on it? I kept the attribute just made it an unstable one same as the one on `Entry`. There didn't seem to be any mention of this in the RELEASES.md so I don't think there's anything for me to do other than this?,HOORAY,2022-02-17T22:39:48Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94105,MERGED,2022-02-17T22:30:59Z,2022-02-19T08:24:27Z,Destabilise entry_insert,5225225,cb4ee81ef555126e49b3e9f16ca6f12a3264a451,1,Auto merge of #94105 - 5225225:destabilise-entry-insert r=Mark-Simulacrum Destabilise entry_insert See: https://github.com/rust-lang/rust/pull/90345 I didn't revert the rename that was done in that PR I left it as `entry_insert`. Additionally before that PR `VacantEntry::insert_entry` seemingly had no stability attribute on it? I kept the attribute just made it an unstable one same as the one on `Entry`. There didn't seem to be any mention of this in the RELEASES.md so I don't think there's anything for me to do other than this?,HOORAY,2022-02-17T22:42:27Z,lenscas,NA https://github.com/rust-lang/rust/pull/94105,MERGED,2022-02-17T22:30:59Z,2022-02-19T08:24:27Z,Destabilise entry_insert,5225225,cb4ee81ef555126e49b3e9f16ca6f12a3264a451,1,Auto merge of #94105 - 5225225:destabilise-entry-insert r=Mark-Simulacrum Destabilise entry_insert See: https://github.com/rust-lang/rust/pull/90345 I didn't revert the rename that was done in that PR I left it as `entry_insert`. Additionally before that PR `VacantEntry::insert_entry` seemingly had no stability attribute on it? I kept the attribute just made it an unstable one same as the one on `Entry`. There didn't seem to be any mention of this in the RELEASES.md so I don't think there's anything for me to do other than this?,HOORAY,2022-02-21T20:30:12Z,passcod,felix@passcod.name https://github.com/rust-lang/rust/pull/94113,CLOSED,2022-02-18T04:45:03Z,2022-02-21T09:26:07Z,document rustc_middle::mir::Field,Mizobrook-kan,NA,NA,NA,THUMBS_UP,2022-02-18T20:26:07Z,pierwill,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-02-18T15:29:37Z,CryZe,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-02-18T17:58:26Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-02-18T23:49:42Z,Lokathor,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-02-22T15:20:17Z,IsakSundeSingh,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HEART,2022-03-18T07:40:10Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-17T19:20:53Z,MatanHamilis,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-21T16:30:10Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-26T01:31:38Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-27T16:28:22Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-27T21:25:48Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HOORAY,2022-05-27T22:52:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,HEART,2022-05-27T22:52:29Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94119,MERGED,2022-02-18T14:32:35Z,2022-05-22T04:27:11Z,Stabilize `array_from_fn`,c410-f3r,09ea21343a432a4c51b363d6f53bed694f81ea3a,3,Auto merge of #94119 - c410-f3r:array-again-and-again r=scottmcm Stabilize `array_from_fn` ## Overall Stabilizes `core::array::from_fn` ~~and `core::array::try_from_fn`~~ to allow the creation of custom infallible ~~and fallible~~ arrays. Signature proposed for stabilization here tweaked as requested in the meeting: ```rust // in core::array pub fn from_fn(_: F) -> [T; N]; ``` Examples in https://doc.rust-lang.org/nightly/std/array/fn.from_fn.html ## History * On 2020-08-17 implementation was [proposed](https://github.com/rust-lang/rust/pull/75644). * On 2021-09-29 tracking issue was [created](https://github.com/rust-lang/rust/issues/89379). * On 2021-10-09 the proposed implementation was [merged](https://github.com/rust-lang-ci/rust/commit/bc8ad24020a160e1acd7ac9f7671947dcc01264c). * On 2021-12-03 the return type of `try_from_fn` was [changed](https://github.com/rust-lang/rust/pull/91286#issuecomment-985513407). ## Considerations * It is being assumed that indices are useful and shouldn't be removed from the callbacks * The fact that `try_from_fn` returns an unstable type `R: Try` does not prevent stabilization. Although I'm honestly not sure about it. * The addition or not of repeat-like variants is orthogonal to this PR. These considerations are not ways of saying what is better or what is worse. In reality they are an attempt to move things forward anything really. cc https://github.com/rust-lang/rust/issues/89379,THUMBS_UP,2022-05-28T11:42:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/94137,MERGED,2022-02-18T23:34:18Z,2022-02-23T20:59:27Z,rustdoc-json: Better Header Type,aDotInTheVoid,8bb6051317f9972bc077bc003f3b480425bcc913,13,Rollup merge of #94137 - aDotInTheVoid:abi-enum r=CraftSpider rustdoc-json: Better Header Type - Make ABI an enum instead of being stringly typed - Replace Qualifier HashSet with 3 bools - Merge ABI field into header as they always occor together r? ``@CraftSpider`` ``@rustbot`` modify labels: +A-rustdoc-json +T-rustdoc,THUMBS_UP,2022-02-19T10:30:31Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/94178,MERGED,2022-02-20T04:00:27Z,2022-02-22T17:44:14Z,"tidy: fire less ""ignoring file length unneccessarily"" warnings",est31,a53b604fea709deb2434319900fb34918cf72469,1,"Rollup merge of #94178 - est31:tolerant_lines_check r=Mark-Simulacrum tidy: fire less ""ignoring file length unneccessarily"" warnings This avoids a situation where a file is at the border of the limit and alternates between hitting the limit and not hitting it causing a back and forth of addition of the ignore-tidy-linelength directive. As an example consider the ignore-tidy-filelength of compiler/rustc_typeck/src/collect.rs. It was added in 2ca4964db5d263a8f9222846bd70a7f26cf414cf removed in 37354ebc9794b0eb14b08c02177e3094c8fe91cd (a revert of the earlier commit) added again in 448d07683a6defd567996114793a09c9a8aef5df removed in 3171bd5bf54fb91f7f7df7c40df5adc7d8bd5dea added in 438826fd1a9a119d00992ede948cdd479431ecbb and removed in bb0a2f985cb6e980cc026ea952733d53bb868f87. To avoid this back and forth we exempt files from the unneccessary ignoring warning that have length of at least 70% of the limit.",HEART,2022-02-21T08:45:18Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94196,MERGED,2022-02-20T22:44:52Z,2022-02-22T17:44:14Z,compiletest: Print process output info with less whitespace,aDotInTheVoid,1177b30ac9286d05721c8e804867498629e28a6b,1,"Rollup merge of #94196 - aDotInTheVoid:terse-procres-info r=Mark-Simulacrum compiletest: Print process output info with less whitespace Before: ``` error: jsondocck failed! status: exit status: 1 command: ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck"" ""--doc-dir"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait"" ""--template"" ""/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" stdout: ------------------------------------------ ------------------------------------------ stderr: ------------------------------------------ Invalid command: Tried to use the previous path in the first command on line 10 Error: ""Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" ------------------------------------------ Rustdoc Output: status: exit status: 0 command: ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc"" ""-L"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"" ""-L"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary"" ""-o"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait"" ""--deny"" ""warnings"" ""/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" ""--output-format"" ""json"" ""-Zunstable-options"" stdout: ------------------------------------------ ------------------------------------------ stderr: ------------------------------------------ ------------------------------------------ ``` After: ``` error: jsondocck failed! status: exit status: 1 command: ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage0-tools-bin/jsondocck"" ""--doc-dir"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait"" ""--template"" ""/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" stdout: none --- stderr ------------------------------- Invalid command: Tried to use the previous path in the first command on line 10 Error: ""Jsondocck failed for /data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" ------------------------------------------ Rustdoc Output: status: exit status: 0 command: ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc"" ""-L"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"" ""-L"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait/auxiliary"" ""-o"" ""/data/ne321/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-json/traits/supertrait"" ""--deny"" ""warnings"" ""/data/ne321/rust/src/test/rustdoc-json/traits/supertrait.rs"" ""--output-format"" ""json"" ""-Zunstable-options"" stdout: none stderr: none ```",HEART,2022-02-20T23:16:11Z,Urgau,NA https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-05-10T10:07:14Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-05-10T12:57:56Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-05-10T21:50:15Z,pshc,paul@paulcollier.ca https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-05-10T22:44:14Z,yerke,NA https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-06-25T09:04:54Z,kadiwa4,NA https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-06-30T21:13:44Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-07-01T07:37:24Z,reo101,NA https://github.com/rust-lang/rust/pull/94206,MERGED,2022-02-21T03:22:11Z,2022-05-08T03:37:55Z,Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions,PrestonFrom,4d1076c9f918297c97300a7ecf769dd7e6780be6,10,Auto merge of #94206 - PrestonFrom:significant_drop r=flip1995 Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting) which is why this PR is for the rust-lang repo and not the clippy repo. changelog: new lint [`significant_drop_in_scrutinee`],HOORAY,2022-07-03T02:57:12Z,KisaragiEffective,NA https://github.com/rust-lang/rust/pull/94211,MERGED,2022-02-21T08:05:10Z,2022-02-22T02:03:28Z,Better error if the user tries to do assignment ... else,est31,d3649f8d52c9e6d7b1877f6d6781d31c356b76af,3,Rollup merge of #94211 - est31:let_else_destructuring_error r=matthewjasper Better error if the user tries to do assignment ... else If the user tries to do assignment ... else we now issue a more comprehensible error in the parser. closes #93995,THUMBS_UP,2022-02-21T09:12:14Z,iago-lito,NA https://github.com/rust-lang/rust/pull/94212,MERGED,2022-02-21T08:33:24Z,2022-02-25T00:46:08Z,Stop manually SIMDing in `swap_nonoverlapping`,scottmcm,7fb55b4c3a308d09a4926d6d7dcce5c13c64eb7f,6,"Rollup merge of #94212 - scottmcm:swapper r=dtolnay Stop manually SIMDing in `swap_nonoverlapping` Like I previously did for `reverse` (#90821) this leaves it to LLVM to pick how to vectorize it since it can know better the chunk size to use compared to the ""32 bytes always"" approach we currently have. A variety of codegen tests are included to confirm that the various cases are still being vectorized. It does still need logic to type-erase in some cases though as while LLVM is now smart enough to vectorize over slices of things like `[u8; 4]` it fails to do so over slices of `[u8; 3]`. As a bonus this change also means one no longer gets the spurious `memcpy`(s?) at the end up swapping a slice of `__m256`s:
ASM for this example ## Before (from godbolt) note the `push`/`pop`s and `memcpy` ```x86 swap_m256_slice: push r15 push r14 push r13 push r12 push rbx sub rsp 32 cmp rsi rcx jne .LBB0_6 mov r14 rsi shl r14 5 je .LBB0_6 mov r15 rdx mov rbx rdi xor eax eax .LBB0_3: mov rcx rax vmovaps ymm0 ymmword ptr [rbx + rax] vmovaps ymm1 ymmword ptr [r15 + rax] vmovaps ymmword ptr [rbx + rax] ymm1 vmovaps ymmword ptr [r15 + rax] ymm0 add rax 32 add rcx 64 cmp rcx r14 jbe .LBB0_3 sub r14 rax jbe .LBB0_6 add rbx rax add r15 rax mov r12 rsp mov r13 qword ptr [rip + memcpy@GOTPCREL] mov rdi r12 mov rsi rbx mov rdx r14 vzeroupper call r13 mov rdi rbx mov rsi r15 mov rdx r14 call r13 mov rdi r15 mov rsi r12 mov rdx r14 call r13 .LBB0_6: add rsp 32 pop rbx pop r12 pop r13 pop r14 pop r15 vzeroupper ret ``` ## After (from my machine) Note no `rsp` manipulation sorry for different ASM syntax ```x86 swap_m256_slice: cmpq %r9 %rdx jne .LBB1_6 testq %rdx %rdx je .LBB1_6 cmpq $1 %rdx jne .LBB1_7 xorl %r10d %r10d jmp .LBB1_4 .LBB1_7: movq %rdx %r9 andq $-2 %r9 movl $32 %eax xorl %r10d %r10d .p2align 4 0x90 .LBB1_8: vmovaps -32(%rcx %rax) %ymm0 vmovaps -32(%r8 %rax) %ymm1 vmovaps %ymm1 -32(%rcx %rax) vmovaps %ymm0 -32(%r8 %rax) vmovaps (%rcx %rax) %ymm0 vmovaps (%r8 %rax) %ymm1 vmovaps %ymm1 (%rcx %rax) vmovaps %ymm0 (%r8 %rax) addq $2 %r10 addq $64 %rax cmpq %r10 %r9 jne .LBB1_8 .LBB1_4: testb $1 %dl je .LBB1_6 shlq $5 %r10 vmovaps (%rcx %r10) %ymm0 vmovaps (%r8 %r10) %ymm1 vmovaps %ymm1 (%rcx %r10) vmovaps %ymm0 (%r8 %r10) .LBB1_6: vzeroupper retq ```
This does all its copying operations as either the original type or as `MaybeUninit`s so as far as I know there should be no potential abstract machine issues with reading padding bytes as integers.
Perf is essentially unchanged Though perhaps with more target features this would help more if it could pick bigger chunks ## Before ``` running 10 tests test slice::swap_with_slice_4x_usize_30 ... bench: 894 ns/iter (+/- 11) test slice::swap_with_slice_4x_usize_3000 ... bench: 99 476 ns/iter (+/- 2 784) test slice::swap_with_slice_5x_usize_30 ... bench: 1 257 ns/iter (+/- 7) test slice::swap_with_slice_5x_usize_3000 ... bench: 139 922 ns/iter (+/- 959) test slice::swap_with_slice_rgb_30 ... bench: 328 ns/iter (+/- 27) test slice::swap_with_slice_rgb_3000 ... bench: 16 215 ns/iter (+/- 176) test slice::swap_with_slice_u8_30 ... bench: 312 ns/iter (+/- 9) test slice::swap_with_slice_u8_3000 ... bench: 5 401 ns/iter (+/- 123) test slice::swap_with_slice_usize_30 ... bench: 368 ns/iter (+/- 3) test slice::swap_with_slice_usize_3000 ... bench: 28 472 ns/iter (+/- 3 913) ``` ## After ``` running 10 tests test slice::swap_with_slice_4x_usize_30 ... bench: 868 ns/iter (+/- 36) test slice::swap_with_slice_4x_usize_3000 ... bench: 99 642 ns/iter (+/- 1 507) test slice::swap_with_slice_5x_usize_30 ... bench: 1 194 ns/iter (+/- 11) test slice::swap_with_slice_5x_usize_3000 ... bench: 139 761 ns/iter (+/- 5 018) test slice::swap_with_slice_rgb_30 ... bench: 324 ns/iter (+/- 6) test slice::swap_with_slice_rgb_3000 ... bench: 15 962 ns/iter (+/- 287) test slice::swap_with_slice_u8_30 ... bench: 281 ns/iter (+/- 5) test slice::swap_with_slice_u8_3000 ... bench: 5 324 ns/iter (+/- 40) test slice::swap_with_slice_usize_30 ... bench: 275 ns/iter (+/- 5) test slice::swap_with_slice_usize_3000 ... bench: 28 277 ns/iter (+/- 277) ``` ",THUMBS_UP,2022-02-21T10:05:54Z,Urgau,NA https://github.com/rust-lang/rust/pull/94236,MERGED,2022-02-21T23:56:32Z,2022-03-04T19:01:33Z,Add #[track_caller] to track callers when initializing poisoned Once,reez12g,904c6ca95c65b71715491b9e32f634734661db94,3,Rollup merge of #94236 - reez12g:add_track_caller_87707 r=yaahc Add #[track_caller] to track callers when initializing poisoned Once This PR is for this Issue. https://github.com/rust-lang/rust/issues/87707 With this fix we expect to be able to track the caller when poisoned Once is initialized.,THUMBS_UP,2022-03-09T09:15:06Z,qpSHiNqp,NA https://github.com/rust-lang/rust/pull/94248,MERGED,2022-02-22T03:53:40Z,2022-02-28T23:38:10Z,Fix ICE when passing block to while-loop condition,compiler-errors,934079180da6e75ee2398d0342857797df5c7a49,4,Rollup merge of #94248 - compiler-errors:fix-while-loop-bad-delay r=petrochenkov Fix ICE when passing block to while-loop condition We were incorrectly delaying a bug when we passed _any_ block (that evaluated to `()`) to a while loop. This PR makes the check a bit more sophisticated. We should only suppress the error here in cases that are equivalent to those we find in #93574 (i.e. only while loop conditions that have destructuring assignment expressions in them). Fixes #93997 cc `@estebank` who added this code I would not be opposed to removing the delay-bug altogether and just emitting this error always. I much prefer duplicate errors over no errors.,THUMBS_UP,2022-02-22T14:59:54Z,estebank,NA https://github.com/rust-lang/rust/pull/94249,MERGED,2022-02-22T05:30:03Z,2022-03-24T01:43:27Z,Better errors when a Copy impl on a Struct is not self-consistent,compiler-errors,af19a50a2697392e89cdda2b94ab271459e1c729,5,Rollup merge of #94249 - compiler-errors:better-copy-errors r=davidtwco Better errors when a Copy impl on a Struct is not self-consistent As discovered in a Zulip thread with `@nnethercote` and `@Mark-Simulacrum ` it's not immediately obvious why a field on an ADT doesn't implement `Copy`. This PR attempts to give slightly more detailed information by spinning up a fulfillment context to try to dig down and discover transitive fulfillment errors that cause `is_copy_modulo_regions` to fail on a ADT field. The error message still kinda sucks but should only show up in the case that an existing error message was totally missing... so I think it's a good compromise for now?,HEART,2022-02-22T08:09:50Z,nnethercote,NA https://github.com/rust-lang/rust/pull/94249,MERGED,2022-02-22T05:30:03Z,2022-03-24T01:43:27Z,Better errors when a Copy impl on a Struct is not self-consistent,compiler-errors,af19a50a2697392e89cdda2b94ab271459e1c729,5,Rollup merge of #94249 - compiler-errors:better-copy-errors r=davidtwco Better errors when a Copy impl on a Struct is not self-consistent As discovered in a Zulip thread with `@nnethercote` and `@Mark-Simulacrum ` it's not immediately obvious why a field on an ADT doesn't implement `Copy`. This PR attempts to give slightly more detailed information by spinning up a fulfillment context to try to dig down and discover transitive fulfillment errors that cause `is_copy_modulo_regions` to fail on a ADT field. The error message still kinda sucks but should only show up in the case that an existing error message was totally missing... so I think it's a good compromise for now?,HEART,2022-02-23T09:35:45Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/94249,MERGED,2022-02-22T05:30:03Z,2022-03-24T01:43:27Z,Better errors when a Copy impl on a Struct is not self-consistent,compiler-errors,af19a50a2697392e89cdda2b94ab271459e1c729,5,Rollup merge of #94249 - compiler-errors:better-copy-errors r=davidtwco Better errors when a Copy impl on a Struct is not self-consistent As discovered in a Zulip thread with `@nnethercote` and `@Mark-Simulacrum ` it's not immediately obvious why a field on an ADT doesn't implement `Copy`. This PR attempts to give slightly more detailed information by spinning up a fulfillment context to try to dig down and discover transitive fulfillment errors that cause `is_copy_modulo_regions` to fail on a ADT field. The error message still kinda sucks but should only show up in the case that an existing error message was totally missing... so I think it's a good compromise for now?,HEART,2022-03-26T02:45:55Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/94252,MERGED,2022-02-22T09:56:59Z,2022-02-25T16:10:01Z,don't special case `DefKind::Ctor` in encoding,lcnr,133de6e1e1bc90000e260725f9d7679498aa1a29,9,Rollup merge of #94252 - lcnr:def_kind-encoding r=cjgillot don't special case `DefKind::Ctor` in encoding considering that we still use `DefKind::Ctor` for these in `Res` this seems weird and definitely felt like a bug when encountering it while working on #89862. r? `@cjgillot`,THUMBS_UP,2022-02-22T13:34:48Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/94261,MERGED,2022-02-22T15:00:12Z,2022-03-15T13:14:27Z,debuginfo: Refactor debuginfo generation for types,michaelwoerister,040703018c51409ea8c9a0cfb8f829a138d2a411,24,Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor r=wesleywiser debuginfo: Refactor debuginfo generation for types This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482. In particular it - changes names to use `di_node` instead of `metadata` - uniformly names all functions that build new debuginfo nodes `build_xyz_di_node` - renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate) - removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md` - moves `TypeMap` and functions that work directly work with it to a new `type_map` module - moves enum related builder functions to a new `enums` module - splits enum debuginfo building for the native and cpp-like cases since they are mostly separate - uses `SmallVec` instead of `Vec` in many places - removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()` `RecursiveTypeDescription` `set_members_of_composite_type()` `MemberDescription` `MemberDescriptionFactory` `prepare_xyz_metadata()` etc) - adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles - adds many (doc-)comments explaining what's going on - changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them) - fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields - changes cpp-like naming for generator enums so that NatVis works for them - changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of sometimes next to it The following could be done in subsequent PRs: - add caching for `closure_saved_names_of_captured_variables` - add caching for `generator_layout_and_saved_local_names` - fix inconsistent handling of what is considered a C-style enum wrt to debuginfo - rename `metadata` module to `types` - move common generator fields to front instead of appending them This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet. Right now the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too. For now: r? `@ghost` (let's see if this affects compile times),HOORAY,2022-02-22T15:35:24Z,Urgau,NA https://github.com/rust-lang/rust/pull/94261,MERGED,2022-02-22T15:00:12Z,2022-03-15T13:14:27Z,debuginfo: Refactor debuginfo generation for types,michaelwoerister,040703018c51409ea8c9a0cfb8f829a138d2a411,24,Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor r=wesleywiser debuginfo: Refactor debuginfo generation for types This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482. In particular it - changes names to use `di_node` instead of `metadata` - uniformly names all functions that build new debuginfo nodes `build_xyz_di_node` - renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate) - removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md` - moves `TypeMap` and functions that work directly work with it to a new `type_map` module - moves enum related builder functions to a new `enums` module - splits enum debuginfo building for the native and cpp-like cases since they are mostly separate - uses `SmallVec` instead of `Vec` in many places - removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()` `RecursiveTypeDescription` `set_members_of_composite_type()` `MemberDescription` `MemberDescriptionFactory` `prepare_xyz_metadata()` etc) - adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles - adds many (doc-)comments explaining what's going on - changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them) - fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields - changes cpp-like naming for generator enums so that NatVis works for them - changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of sometimes next to it The following could be done in subsequent PRs: - add caching for `closure_saved_names_of_captured_variables` - add caching for `generator_layout_and_saved_local_names` - fix inconsistent handling of what is considered a C-style enum wrt to debuginfo - rename `metadata` module to `types` - move common generator fields to front instead of appending them This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet. Right now the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too. For now: r? `@ghost` (let's see if this affects compile times),HOORAY,2022-02-22T19:46:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94261,MERGED,2022-02-22T15:00:12Z,2022-03-15T13:14:27Z,debuginfo: Refactor debuginfo generation for types,michaelwoerister,040703018c51409ea8c9a0cfb8f829a138d2a411,24,Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor r=wesleywiser debuginfo: Refactor debuginfo generation for types This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482. In particular it - changes names to use `di_node` instead of `metadata` - uniformly names all functions that build new debuginfo nodes `build_xyz_di_node` - renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate) - removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md` - moves `TypeMap` and functions that work directly work with it to a new `type_map` module - moves enum related builder functions to a new `enums` module - splits enum debuginfo building for the native and cpp-like cases since they are mostly separate - uses `SmallVec` instead of `Vec` in many places - removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()` `RecursiveTypeDescription` `set_members_of_composite_type()` `MemberDescription` `MemberDescriptionFactory` `prepare_xyz_metadata()` etc) - adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles - adds many (doc-)comments explaining what's going on - changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them) - fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields - changes cpp-like naming for generator enums so that NatVis works for them - changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of sometimes next to it The following could be done in subsequent PRs: - add caching for `closure_saved_names_of_captured_variables` - add caching for `generator_layout_and_saved_local_names` - fix inconsistent handling of what is considered a C-style enum wrt to debuginfo - rename `metadata` module to `types` - move common generator fields to front instead of appending them This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet. Right now the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too. For now: r? `@ghost` (let's see if this affects compile times),HEART,2022-02-23T14:01:27Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/94261,MERGED,2022-02-22T15:00:12Z,2022-03-15T13:14:27Z,debuginfo: Refactor debuginfo generation for types,michaelwoerister,040703018c51409ea8c9a0cfb8f829a138d2a411,24,Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor r=wesleywiser debuginfo: Refactor debuginfo generation for types This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482. In particular it - changes names to use `di_node` instead of `metadata` - uniformly names all functions that build new debuginfo nodes `build_xyz_di_node` - renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate) - removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md` - moves `TypeMap` and functions that work directly work with it to a new `type_map` module - moves enum related builder functions to a new `enums` module - splits enum debuginfo building for the native and cpp-like cases since they are mostly separate - uses `SmallVec` instead of `Vec` in many places - removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()` `RecursiveTypeDescription` `set_members_of_composite_type()` `MemberDescription` `MemberDescriptionFactory` `prepare_xyz_metadata()` etc) - adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles - adds many (doc-)comments explaining what's going on - changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them) - fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields - changes cpp-like naming for generator enums so that NatVis works for them - changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of sometimes next to it The following could be done in subsequent PRs: - add caching for `closure_saved_names_of_captured_variables` - add caching for `generator_layout_and_saved_local_names` - fix inconsistent handling of what is considered a C-style enum wrt to debuginfo - rename `metadata` module to `types` - move common generator fields to front instead of appending them This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet. Right now the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too. For now: r? `@ghost` (let's see if this affects compile times),HOORAY,2022-04-28T23:18:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/94261,MERGED,2022-02-22T15:00:12Z,2022-03-15T13:14:27Z,debuginfo: Refactor debuginfo generation for types,michaelwoerister,040703018c51409ea8c9a0cfb8f829a138d2a411,24,Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor r=wesleywiser debuginfo: Refactor debuginfo generation for types This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482. In particular it - changes names to use `di_node` instead of `metadata` - uniformly names all functions that build new debuginfo nodes `build_xyz_di_node` - renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate) - removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md` - moves `TypeMap` and functions that work directly work with it to a new `type_map` module - moves enum related builder functions to a new `enums` module - splits enum debuginfo building for the native and cpp-like cases since they are mostly separate - uses `SmallVec` instead of `Vec` in many places - removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()` `RecursiveTypeDescription` `set_members_of_composite_type()` `MemberDescription` `MemberDescriptionFactory` `prepare_xyz_metadata()` etc) - adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles - adds many (doc-)comments explaining what's going on - changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them) - fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields - changes cpp-like naming for generator enums so that NatVis works for them - changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of sometimes next to it The following could be done in subsequent PRs: - add caching for `closure_saved_names_of_captured_variables` - add caching for `generator_layout_and_saved_local_names` - fix inconsistent handling of what is considered a C-style enum wrt to debuginfo - rename `metadata` module to `types` - move common generator fields to front instead of appending them This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet. Right now the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too. For now: r? `@ghost` (let's see if this affects compile times),HEART,2022-04-28T23:18:54Z,tmandry,NA https://github.com/rust-lang/rust/pull/94263,MERGED,2022-02-22T17:28:14Z,2022-02-23T20:59:26Z,Typo fix: Close inline-code backtick,anko,6550671fa517726d5691045884e6ff6b810c4556,1,Rollup merge of #94263 - anko:patch-1 r=GuillaumeGomez Typo fix: Close inline-code backtick A drop in the ocean.,HEART,2022-02-22T17:42:43Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94264,MERGED,2022-02-22T17:46:58Z,2022-02-23T20:59:26Z,Fix typo.,NyantasticUwU,efe6a979b5a7924123141a6864faea6457b8ca6f,1,Rollup merge of #94264 - NyantasticUwU:patch-1 r=yaahc Fix typo. Yeah just a typo (probably some breaking changes in here be careful) :),LAUGH,2022-02-22T19:03:42Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/94264,MERGED,2022-02-22T17:46:58Z,2022-02-23T20:59:26Z,Fix typo.,NyantasticUwU,efe6a979b5a7924123141a6864faea6457b8ca6f,1,Rollup merge of #94264 - NyantasticUwU:patch-1 r=yaahc Fix typo. Yeah just a typo (probably some breaking changes in here be careful) :),LAUGH,2022-02-23T00:55:14Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/94264,MERGED,2022-02-22T17:46:58Z,2022-02-23T20:59:26Z,Fix typo.,NyantasticUwU,efe6a979b5a7924123141a6864faea6457b8ca6f,1,Rollup merge of #94264 - NyantasticUwU:patch-1 r=yaahc Fix typo. Yeah just a typo (probably some breaking changes in here be careful) :),LAUGH,2022-02-23T18:08:46Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/94268,CLOSED,2022-02-22T22:21:42Z,2022-02-23T17:18:25Z,[perf only] Drop incremental compilation support,Mark-Simulacrum,NA,NA,NA,LAUGH,2022-02-22T23:20:19Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/94270,MERGED,2022-02-22T23:53:25Z,2022-02-24T09:37:25Z,Miri: relax fn ptr check,RalfJung,3cd1dc1d6ec80efa2cff237d8494d825ab983da6,4,Rollup merge of #94270 - RalfJung:fn-ptrs r=oli-obk Miri: relax fn ptr check As discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/72#issuecomment-1025407536 the function pointer check done by Miri is currently overeager: contrary to our usual principle of only checking rather uncontroversial validity invariants we actually check that the pointer points to a real function. So this relaxes the check to what the validity invariant probably will be (and what the reference already says it is): the function pointer must be non-null and that's it. The check that CTFE does on the final value of a constant is unchanged -- CTFE recurses through references so it makes some sense to also recurse through function pointers. We might still want to relax this in the future but that would be a separate change. r? `@oli-obk`,THUMBS_UP,2022-02-23T00:48:36Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/94270,MERGED,2022-02-22T23:53:25Z,2022-02-24T09:37:25Z,Miri: relax fn ptr check,RalfJung,3cd1dc1d6ec80efa2cff237d8494d825ab983da6,4,Rollup merge of #94270 - RalfJung:fn-ptrs r=oli-obk Miri: relax fn ptr check As discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/72#issuecomment-1025407536 the function pointer check done by Miri is currently overeager: contrary to our usual principle of only checking rather uncontroversial validity invariants we actually check that the pointer points to a real function. So this relaxes the check to what the validity invariant probably will be (and what the reference already says it is): the function pointer must be non-null and that's it. The check that CTFE does on the final value of a constant is unchanged -- CTFE recurses through references so it makes some sense to also recurse through function pointers. We might still want to relax this in the future but that would be a separate change. r? `@oli-obk`,THUMBS_UP,2022-02-23T01:50:28Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/94270,MERGED,2022-02-22T23:53:25Z,2022-02-24T09:37:25Z,Miri: relax fn ptr check,RalfJung,3cd1dc1d6ec80efa2cff237d8494d825ab983da6,4,Rollup merge of #94270 - RalfJung:fn-ptrs r=oli-obk Miri: relax fn ptr check As discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/72#issuecomment-1025407536 the function pointer check done by Miri is currently overeager: contrary to our usual principle of only checking rather uncontroversial validity invariants we actually check that the pointer points to a real function. So this relaxes the check to what the validity invariant probably will be (and what the reference already says it is): the function pointer must be non-null and that's it. The check that CTFE does on the final value of a constant is unchanged -- CTFE recurses through references so it makes some sense to also recurse through function pointers. We might still want to relax this in the future but that would be a separate change. r? `@oli-obk`,THUMBS_UP,2022-02-23T03:25:53Z,taiki-e,NA https://github.com/rust-lang/rust/pull/94270,MERGED,2022-02-22T23:53:25Z,2022-02-24T09:37:25Z,Miri: relax fn ptr check,RalfJung,3cd1dc1d6ec80efa2cff237d8494d825ab983da6,4,Rollup merge of #94270 - RalfJung:fn-ptrs r=oli-obk Miri: relax fn ptr check As discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/72#issuecomment-1025407536 the function pointer check done by Miri is currently overeager: contrary to our usual principle of only checking rather uncontroversial validity invariants we actually check that the pointer points to a real function. So this relaxes the check to what the validity invariant probably will be (and what the reference already says it is): the function pointer must be non-null and that's it. The check that CTFE does on the final value of a constant is unchanged -- CTFE recurses through references so it makes some sense to also recurse through function pointers. We might still want to relax this in the future but that would be a separate change. r? `@oli-obk`,THUMBS_UP,2022-02-24T10:12:00Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94283,MERGED,2022-02-23T09:45:35Z,2022-02-24T09:37:25Z,remove feature gate in control_flow examples,hellow554,f3433d1b5962681b2e3ef733aeed4adaf9e6a47a,1,Rollup merge of #94283 - hellow554:stable_flow_control r=Dylan-DPC remove feature gate in control_flow examples Stabilization was done in https://github.com/rust-lang/rust/pull/91091 but the two examples weren't updated accordingly. Probably too late to put it into stable but it should be in the next release :),HEART,2022-02-24T09:31:50Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94290,MERGED,2022-02-23T13:13:13Z,2022-02-25T20:53:53Z,Bump bootstrap to 1.60,Mark-Simulacrum,d981633ed6669c6f7b1cb46d1d1a7282e281ca8e,63,Auto merge of #94290 - Mark-Simulacrum:bump-bootstrap r=pietroalbini Bump bootstrap to 1.60 This bumps the bootstrap compiler to 1.60 and cleans up cfgs and Span's rustc_pass_by_value (enabled by the bootstrap bump).,HEART,2022-02-23T19:26:59Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94295,MERGED,2022-02-23T15:01:49Z,2022-03-19T00:51:58Z,Always evaluate all cfg predicate in all() and any(),Urgau,d15006ceca3854e507341dd8b7171a451351b4cd,3,Rollup merge of #94295 - Urgau:cfg-always-eval-all-predicate r=petrochenkov Always evaluate all cfg predicate in all() and any() This pull-request adjust the handling of the `all()` and `any()` to always evaluate every cfg predicate because not doing so result in accepting incorrect `cfg`: ```rust #[cfg(any(unix foo::bar))] // Should error on foo::bar but does not on unix platform (but does on non unix platform) fn foo1() {} #[cfg(all(foo foo::bar))] // Should error on foo::bar but does not fn foo2() {} #[cfg(all(foo::bar foo))] // Correctly error on foo::bar fn foo3() {} #[cfg(any(foo::bar foo))] // Correctly error on foo::bar fn foo4() {} ``` This pull-request take the side to directly turn it into a hard error instead of having a future incompatibility lint because the combination to get this incorrect behavior is unusual and highly probable that some code have this without noticing. A [search](https://cs.github.com/?scopeName=All+repos&scope=&q=lang%3Arust+%2Fany%5C%28%5Ba-zA-Z%5D%2C+%5Ba-zA-Z%5D%2B%3A%3A%5Ba-zA-Z%5D%2B%2F) on Github reveal no such instance nevertheless a Crater run should probably be done before merging this. This was discover in https://github.com/rust-lang/rust/pull/94175 when trying to lint on the second predicate. Also note that this seems to have being introduce with Rust 1.27.0: https://rust.godbolt.org/z/KnfqKv15f. r? `@petrochenkov`,HOORAY,2022-04-29T02:13:08Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/94298,MERGED,2022-02-23T17:35:40Z,2022-03-05T00:15:59Z,Enable conditional compilation checking on the Rust codebase,Urgau,5a7e4c6b5aa8f42bd56365fecf93cd1b6bf1d22f,5,Auto merge of #94298 - Urgau:rustbuild-check-cfg r=Mark-Simulacrum Enable conditional compilation checking on the Rust codebase This pull-request enable conditional compilation checking on every rust project build by the `bootstrap` tool. To be more specific this PR only enable well known names checking + extra names (bootstrap parallel_compiler ...). r? `@Mark-Simulacrum`,HEART,2022-02-23T17:48:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/94298,MERGED,2022-02-23T17:35:40Z,2022-03-05T00:15:59Z,Enable conditional compilation checking on the Rust codebase,Urgau,5a7e4c6b5aa8f42bd56365fecf93cd1b6bf1d22f,5,Auto merge of #94298 - Urgau:rustbuild-check-cfg r=Mark-Simulacrum Enable conditional compilation checking on the Rust codebase This pull-request enable conditional compilation checking on every rust project build by the `bootstrap` tool. To be more specific this PR only enable well known names checking + extra names (bootstrap parallel_compiler ...). r? `@Mark-Simulacrum`,HEART,2022-02-28T02:37:42Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94303,CLOSED,2022-02-23T19:58:55Z,2022-02-23T23:09:53Z,Stop using `exhaustive_patterns` in libcore,scottmcm,NA,NA,NA,THUMBS_DOWN,2022-02-23T20:19:57Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/94309,MERGED,2022-02-23T23:58:13Z,2022-03-18T03:01:55Z,[generator_interior] Be more precise with scopes of borrowed places,eholk,8499a8ba88dafe76d376d2de2394e6816aaa72de,6,Rollup merge of #94309 - eholk:issue-57017 r=tmandry [generator_interior] Be more precise with scopes of borrowed places Previously the generator interior type checking analysis would use the nearest temporary scope as the scope of a borrowed value. This ends up being overly broad for cases such as: ```rust fn status(_client_status: &Client) -> i16 { 200 } fn main() { let client = Client; let g = move || match status(&client) { _status => yield }; assert_send(g); } ``` In this case the borrow `&client` could be considered in scope for the entirety of the `match` expression meaning it would be viewed as live across the `yield` therefore making the generator not `Send`. In most cases we want to use the enclosing expression as the scope for a borrowed value which will be less than or equal to the nearest temporary scope. This PR changes the analysis to use the enclosing expression as the scope for most borrows with the exception of borrowed RValues which are true temporary values that should have the temporary scope. There's one further exception where borrows of a copy such as happens in autoref cases also should be ignored despite being RValues. Joint work with `@nikomatsakis` Fixes #57017 r? `@tmandry`,HEART,2022-03-18T04:29:56Z,jcaesar,NA https://github.com/rust-lang/rust/pull/94309,MERGED,2022-02-23T23:58:13Z,2022-03-18T03:01:55Z,[generator_interior] Be more precise with scopes of borrowed places,eholk,8499a8ba88dafe76d376d2de2394e6816aaa72de,6,Rollup merge of #94309 - eholk:issue-57017 r=tmandry [generator_interior] Be more precise with scopes of borrowed places Previously the generator interior type checking analysis would use the nearest temporary scope as the scope of a borrowed value. This ends up being overly broad for cases such as: ```rust fn status(_client_status: &Client) -> i16 { 200 } fn main() { let client = Client; let g = move || match status(&client) { _status => yield }; assert_send(g); } ``` In this case the borrow `&client` could be considered in scope for the entirety of the `match` expression meaning it would be viewed as live across the `yield` therefore making the generator not `Send`. In most cases we want to use the enclosing expression as the scope for a borrowed value which will be less than or equal to the nearest temporary scope. This PR changes the analysis to use the enclosing expression as the scope for most borrows with the exception of borrowed RValues which are true temporary values that should have the temporary scope. There's one further exception where borrows of a copy such as happens in autoref cases also should be ignored despite being RValues. Joint work with `@nikomatsakis` Fixes #57017 r? `@tmandry`,HEART,2022-03-18T06:05:20Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94309,MERGED,2022-02-23T23:58:13Z,2022-03-18T03:01:55Z,[generator_interior] Be more precise with scopes of borrowed places,eholk,8499a8ba88dafe76d376d2de2394e6816aaa72de,6,Rollup merge of #94309 - eholk:issue-57017 r=tmandry [generator_interior] Be more precise with scopes of borrowed places Previously the generator interior type checking analysis would use the nearest temporary scope as the scope of a borrowed value. This ends up being overly broad for cases such as: ```rust fn status(_client_status: &Client) -> i16 { 200 } fn main() { let client = Client; let g = move || match status(&client) { _status => yield }; assert_send(g); } ``` In this case the borrow `&client` could be considered in scope for the entirety of the `match` expression meaning it would be viewed as live across the `yield` therefore making the generator not `Send`. In most cases we want to use the enclosing expression as the scope for a borrowed value which will be less than or equal to the nearest temporary scope. This PR changes the analysis to use the enclosing expression as the scope for most borrows with the exception of borrowed RValues which are true temporary values that should have the temporary scope. There's one further exception where borrows of a copy such as happens in autoref cases also should be ignored despite being RValues. Joint work with `@nikomatsakis` Fixes #57017 r? `@tmandry`,EYES,2022-07-10T01:37:42Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/94316,MERGED,2022-02-24T07:53:05Z,2022-02-25T00:46:08Z,Improve string literal unescaping,nnethercote,ec44d48ae396e596f07ecc496f95da2b5ec36223,3,Rollup merge of #94316 - nnethercote:improve-string-literal-unescaping r=petrochenkov Improve string literal unescaping Some easy wins that affect a few popular crates. r? ```@matklad```,HOORAY,2022-02-24T08:31:42Z,lqd,NA https://github.com/rust-lang/rust/pull/94316,MERGED,2022-02-24T07:53:05Z,2022-02-25T00:46:08Z,Improve string literal unescaping,nnethercote,ec44d48ae396e596f07ecc496f95da2b5ec36223,3,Rollup merge of #94316 - nnethercote:improve-string-literal-unescaping r=petrochenkov Improve string literal unescaping Some easy wins that affect a few popular crates. r? ```@matklad```,HOORAY,2022-02-24T08:57:07Z,mati865,NA https://github.com/rust-lang/rust/pull/94316,MERGED,2022-02-24T07:53:05Z,2022-02-25T00:46:08Z,Improve string literal unescaping,nnethercote,ec44d48ae396e596f07ecc496f95da2b5ec36223,3,Rollup merge of #94316 - nnethercote:improve-string-literal-unescaping r=petrochenkov Improve string literal unescaping Some easy wins that affect a few popular crates. r? ```@matklad```,HOORAY,2022-02-25T07:16:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94316,MERGED,2022-02-24T07:53:05Z,2022-02-25T00:46:08Z,Improve string literal unescaping,nnethercote,ec44d48ae396e596f07ecc496f95da2b5ec36223,3,Rollup merge of #94316 - nnethercote:improve-string-literal-unescaping r=petrochenkov Improve string literal unescaping Some easy wins that affect a few popular crates. r? ```@matklad```,HOORAY,2022-02-25T07:48:09Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/94316,MERGED,2022-02-24T07:53:05Z,2022-02-25T00:46:08Z,Improve string literal unescaping,nnethercote,ec44d48ae396e596f07ecc496f95da2b5ec36223,3,Rollup merge of #94316 - nnethercote:improve-string-literal-unescaping r=petrochenkov Improve string literal unescaping Some easy wins that affect a few popular crates. r? ```@matklad```,HOORAY,2022-03-03T04:48:09Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94317,CLOSED,2022-02-24T09:03:34Z,2022-04-16T01:22:07Z,Add `Option::inspect_none` & minor example improvements to other new `inspect` methods,cyqsimon,NA,NA,NA,THUMBS_UP,2022-02-24T14:57:02Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/94320,MERGED,2022-02-24T11:19:36Z,2022-03-13T10:25:34Z,Fix sidebar elements display,GuillaumeGomez,7eac19c30c9aa69bc3d85a583c117c37c1579de3,2,Auto merge of #94320 - GuillaumeGomez:sidebar-display r=jsha Fix sidebar elements display The bug can be seen more easily when the javascript is disabled: ![Screenshot from 2022-02-24 12-18-28](https://user-images.githubusercontent.com/3050060/155514578-cbefd3dd-f006-47e9-bc76-7c26d7e823e8.png) r? `@jsha`,LAUGH,2022-03-13T06:52:03Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-24T15:38:47Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HEART,2022-02-24T16:26:45Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-24T17:20:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-24T17:23:41Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-24T19:32:39Z,mati865,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HEART,2022-02-24T19:32:42Z,mati865,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-25T09:51:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HEART,2022-02-25T09:51:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-25T12:36:36Z,ljedrz,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-26T02:37:25Z,lqd,NA https://github.com/rust-lang/rust/pull/94325,CLOSED,2022-02-24T15:15:29Z,2022-03-01T21:09:18Z,Add a basic -Zchalk-migration flag for comparing chalk against the existing trait engine,oli-obk,NA,NA,NA,HOORAY,2022-02-26T20:32:17Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94327,MERGED,2022-02-24T16:31:21Z,2022-02-25T00:46:08Z,Avoid emitting full macro body into JSON errors,Mark-Simulacrum,3bd163f4e8422db4c0de384b2b21bfaaecd2e5c1,1,"Rollup merge of #94327 - Mark-Simulacrum:avoid-macro-sp r=petrochenkov Avoid emitting full macro body into JSON errors While investigating https://github.com/rust-lang/rust/issues/94322 it was noted that currently the JSON diagnostics for macro backtraces include the full def_site span -- the whole macro body. It seems like this shouldn't be necessary so this PR adjusts the span to just be the ""guessed head"" typically the macro name. It doesn't look like we keep enough information to synthesize a nicer span here at this time. Atop #92123 this reduces output for the src/test/ui/suggestions/missing-lifetime-specifier.rs test from 660 KB to 156 KB locally.",THUMBS_UP,2022-02-24T16:45:47Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/94344,MERGED,2022-02-25T00:47:19Z,2022-02-25T16:10:00Z,diagnostic: suggest parens when users want logical ops but get closures,notriddle,731cd3fbeb0e08a44d52c14039fe942c74491f0d,4,Rollup merge of #94344 - notriddle:notriddle/suggest-parens-more r=oli-obk diagnostic: suggest parens when users want logical ops but get closures Fixes #93536,HEART,2022-02-25T03:38:22Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94368,MERGED,2022-02-25T19:11:05Z,2022-03-11T01:51:53Z,[1/2] Implement macro meta-variable expressions,c410-f3r,634a6b0d251f523f6b61a33ea647c9850de1a704,17,Rollup merge of #94368 - c410-f3r:metaaaaaaaaaaaaaaaaaaaaaaaaaaa r=petrochenkov [1/2] Implement macro meta-variable expressions See https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295 The logic behind `length` `index` and `count` was removed but the parsing code is still present i.e. everything is simply ignored like `ignored`. r? ``@petrochenkov``,EYES,2022-02-25T19:56:19Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/94368,MERGED,2022-02-25T19:11:05Z,2022-03-11T01:51:53Z,[1/2] Implement macro meta-variable expressions,c410-f3r,634a6b0d251f523f6b61a33ea647c9850de1a704,17,Rollup merge of #94368 - c410-f3r:metaaaaaaaaaaaaaaaaaaaaaaaaaaa r=petrochenkov [1/2] Implement macro meta-variable expressions See https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295 The logic behind `length` `index` and `count` was removed but the parsing code is still present i.e. everything is simply ignored like `ignored`. r? ``@petrochenkov``,THUMBS_UP,2022-02-25T21:08:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94372,MERGED,2022-02-25T20:21:05Z,2022-03-20T01:13:17Z,Add #[inline] to trivial AsRef/AsMut impls,erikdesjardins,f2661cfe341f88bea919daf52a07015dceaf7a6a,1,Auto merge of #94372 - erikdesjardins:asrefinl r=dtolnay Add #[inline] to trivial AsRef/AsMut impls These appeared uninlined in some perf runs but they're trivial. r? `@ghost`,HEART,2022-02-26T06:12:50Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94375,MERGED,2022-02-25T20:49:21Z,2022-03-03T06:56:26Z,Adt copy suggestions,WaffleLapkin,7537b2036a472e80fce4295eb799a53f61f959c0,8,Rollup merge of #94375 - WaffleLapkin:copy-suggestion r=estebank Adt copy suggestions Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type - Can be copy - All predicates that need to be satisfied for that are based on type params i.e. we will suggest `T: Copy` for `Option` but won't suggest anything for `Option`. An example: ```rust fn duplicate(t: Option) -> (Option Option) { (t t) } ``` New error (current compiler doesn't provide `help`:): ```text error[E0382]: use of moved value: `t` --> t.rs:2:9 | 1 | fn duplicate(t: Option) -> (Option Option) { | - move occurs because `t` has type `Option` which does not implement the `Copy` trait 2 | (t t) | - ^ value used here after move | | | value moved here | help: consider restricting type parameter `T` | 1 | fn duplicate(t: Option) -> (Option Option) { | ++++++ ``` Fixes #93623 r? ``````````@estebank`````````` ``````````@rustbot`````````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement ---- I'm not at all sure if this is the right implementation for this kind of suggestion but it seems to work :'),HEART,2022-02-25T20:58:53Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94375,MERGED,2022-02-25T20:49:21Z,2022-03-03T06:56:26Z,Adt copy suggestions,WaffleLapkin,7537b2036a472e80fce4295eb799a53f61f959c0,8,Rollup merge of #94375 - WaffleLapkin:copy-suggestion r=estebank Adt copy suggestions Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type - Can be copy - All predicates that need to be satisfied for that are based on type params i.e. we will suggest `T: Copy` for `Option` but won't suggest anything for `Option`. An example: ```rust fn duplicate(t: Option) -> (Option Option) { (t t) } ``` New error (current compiler doesn't provide `help`:): ```text error[E0382]: use of moved value: `t` --> t.rs:2:9 | 1 | fn duplicate(t: Option) -> (Option Option) { | - move occurs because `t` has type `Option` which does not implement the `Copy` trait 2 | (t t) | - ^ value used here after move | | | value moved here | help: consider restricting type parameter `T` | 1 | fn duplicate(t: Option) -> (Option Option) { | ++++++ ``` Fixes #93623 r? ``````````@estebank`````````` ``````````@rustbot`````````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement ---- I'm not at all sure if this is the right implementation for this kind of suggestion but it seems to work :'),HEART,2022-02-26T15:32:02Z,estebank,NA https://github.com/rust-lang/rust/pull/94375,MERGED,2022-02-25T20:49:21Z,2022-03-03T06:56:26Z,Adt copy suggestions,WaffleLapkin,7537b2036a472e80fce4295eb799a53f61f959c0,8,Rollup merge of #94375 - WaffleLapkin:copy-suggestion r=estebank Adt copy suggestions Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type - Can be copy - All predicates that need to be satisfied for that are based on type params i.e. we will suggest `T: Copy` for `Option` but won't suggest anything for `Option`. An example: ```rust fn duplicate(t: Option) -> (Option Option) { (t t) } ``` New error (current compiler doesn't provide `help`:): ```text error[E0382]: use of moved value: `t` --> t.rs:2:9 | 1 | fn duplicate(t: Option) -> (Option Option) { | - move occurs because `t` has type `Option` which does not implement the `Copy` trait 2 | (t t) | - ^ value used here after move | | | value moved here | help: consider restricting type parameter `T` | 1 | fn duplicate(t: Option) -> (Option Option) { | ++++++ ``` Fixes #93623 r? ``````````@estebank`````````` ``````````@rustbot`````````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement ---- I'm not at all sure if this is the right implementation for this kind of suggestion but it seems to work :'),HEART,2022-02-26T20:31:51Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,EYES,2022-02-25T22:45:06Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,EYES,2022-02-26T04:32:37Z,Miksel12,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-02-26T05:16:13Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-02-26T16:56:41Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,EYES,2022-02-27T17:20:34Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,EYES,2022-03-01T00:51:56Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-03T14:39:19Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-03T14:40:17Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-03T21:25:38Z,mati865,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-04T18:03:27Z,aaupov,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-05T04:07:45Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-03-10T22:57:02Z,Milo123459,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,EYES,2022-03-10T22:57:04Z,Milo123459,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,ROCKET,2022-04-14T20:06:27Z,lqd,NA https://github.com/rust-lang/rust/pull/94381,OPEN,2022-02-25T22:38:08Z,NA,[WIP] Use BOLT in CI to optimize LLVM,Kobzol,NA,NA,NA,THUMBS_UP,2022-04-14T20:08:47Z,lqd,NA https://github.com/rust-lang/rust/pull/94387,OPEN,2022-02-26T00:43:34Z,NA,Add option to pass environment variables,DrMeepster,NA,NA,NA,ROCKET,2022-02-26T10:15:34Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94387,OPEN,2022-02-26T00:43:34Z,NA,Add option to pass environment variables,DrMeepster,NA,NA,NA,CONFUSED,2022-06-23T14:13:49Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/94391,MERGED,2022-02-26T05:48:25Z,2022-03-25T04:01:01Z,Fix ice when error reporting recursion errors,light4,d1d4613ead1896eff612903edb5da42630821b29,9,Rollup merge of #94391 - light4:issue-90319 r=estebank Fix ice when error reporting recursion errors Fixes: #90319 #92148 #93955,HEART,2022-03-24T18:42:41Z,estebank,NA https://github.com/rust-lang/rust/pull/94391,MERGED,2022-02-26T05:48:25Z,2022-03-25T04:01:01Z,Fix ice when error reporting recursion errors,light4,d1d4613ead1896eff612903edb5da42630821b29,9,Rollup merge of #94391 - light4:issue-90319 r=estebank Fix ice when error reporting recursion errors Fixes: #90319 #92148 #93955,HEART,2022-04-06T21:19:48Z,matheus-consoli,matheus.consoli7@gmail.com https://github.com/rust-lang/rust/pull/94407,CLOSED,2022-02-26T22:41:42Z,2022-04-11T07:32:00Z,Add `with_backlog` functionality to `TcpListener` and `UnixListener`,BartMassey,NA,NA,NA,HEART,2022-02-27T09:27:44Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/94412,MERGED,2022-02-27T03:02:24Z,2022-02-27T20:11:31Z,For MIRI cfg out the swap vectorization logic from 94212,scottmcm,6a705566166debf5eff88c57140df607fa409aaa,3,Auto merge of #94412 - scottmcm:cfg-out-miri-from-swap r=oli-obk For MIRI cfg out the swap vectorization logic from 94212 Because of #69488 the swap logic from #94212 doesn't currently work in MIRI. Copying in smaller pieces is probably much worse for its performance anyway so it'd probably rather just use the simple path regardless. Part of #94371 though another PR will be needed for the CTFE aspect. r? `@oli-obk` cc `@RalfJung`,HEART,2022-02-27T20:28:03Z,RalfJung,NA https://github.com/rust-lang/rust/pull/94413,CLOSED,2022-02-27T08:43:56Z,2022-06-19T07:29:36Z,array zip_map feature,conradludgate,NA,NA,NA,ROCKET,2022-02-28T00:07:44Z,yotamofek,yotam.ofek@gmail.com https://github.com/rust-lang/rust/pull/94414,MERGED,2022-02-27T08:57:21Z,2022-02-28T23:38:10Z,Fix ICE when using Box with large A,DrMeepster,975a0e0141c94a09cf4cba4499ce981da643d07e,3,Rollup merge of #94414 - DrMeepster:box_alloc_ice2 r=tmiasko Fix ICE when using Box with large A A sequel to #94043 that fixes #81270 and #92054 (duplicate).,HOORAY,2022-02-27T18:43:43Z,ds84182,NA https://github.com/rust-lang/rust/pull/94414,MERGED,2022-02-27T08:57:21Z,2022-02-28T23:38:10Z,Fix ICE when using Box with large A,DrMeepster,975a0e0141c94a09cf4cba4499ce981da643d07e,3,Rollup merge of #94414 - DrMeepster:box_alloc_ice2 r=tmiasko Fix ICE when using Box with large A A sequel to #94043 that fixes #81270 and #92054 (duplicate).,HOORAY,2022-02-28T19:32:18Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94414,MERGED,2022-02-27T08:57:21Z,2022-02-28T23:38:10Z,Fix ICE when using Box with large A,DrMeepster,975a0e0141c94a09cf4cba4499ce981da643d07e,3,Rollup merge of #94414 - DrMeepster:box_alloc_ice2 r=tmiasko Fix ICE when using Box with large A A sequel to #94043 that fixes #81270 and #92054 (duplicate).,HOORAY,2022-03-01T01:50:04Z,faptc,NA https://github.com/rust-lang/rust/pull/94414,MERGED,2022-02-27T08:57:21Z,2022-02-28T23:38:10Z,Fix ICE when using Box with large A,DrMeepster,975a0e0141c94a09cf4cba4499ce981da643d07e,3,Rollup merge of #94414 - DrMeepster:box_alloc_ice2 r=tmiasko Fix ICE when using Box with large A A sequel to #94043 that fixes #81270 and #92054 (duplicate).,HOORAY,2022-03-03T04:47:21Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94452,MERGED,2022-02-28T18:31:29Z,2022-03-01T05:40:03Z,Sync portable-simd for bitmasks &c.,workingjubilee,4001d98019c050c22f80ab61b7c62e2cc7c633a0,21,Rollup merge of #94452 - workingjubilee:sync-simd-bitmasks r=workingjubilee Sync portable-simd for bitmasks &c. In the ideal case where everything works easily and nothing has to be rearranged it is as simple as: - `git subtree pull -P library/portable-simd https://github.com/rust-lang/portable-simd - ${branch}` - write the commit message - `python x.py test --stage 1` to make sure it runs - `git push` to your PR-to-rustc branch If anything borks up this flow you can fix it with sufficient git wizardry but you are usually better off going back to the source fixing it and starting over before you open the PR. r? `@calebzulawski`,HOORAY,2022-02-28T20:09:12Z,marmeladema,NA https://github.com/rust-lang/rust/pull/94452,MERGED,2022-02-28T18:31:29Z,2022-03-01T05:40:03Z,Sync portable-simd for bitmasks &c.,workingjubilee,4001d98019c050c22f80ab61b7c62e2cc7c633a0,21,Rollup merge of #94452 - workingjubilee:sync-simd-bitmasks r=workingjubilee Sync portable-simd for bitmasks &c. In the ideal case where everything works easily and nothing has to be rearranged it is as simple as: - `git subtree pull -P library/portable-simd https://github.com/rust-lang/portable-simd - ${branch}` - write the commit message - `python x.py test --stage 1` to make sure it runs - `git push` to your PR-to-rustc branch If anything borks up this flow you can fix it with sufficient git wizardry but you are usually better off going back to the source fixing it and starting over before you open the PR. r? `@calebzulawski`,HOORAY,2022-02-28T22:22:39Z,saik0,NA https://github.com/rust-lang/rust/pull/94455,OPEN,2022-02-28T20:10:04Z,NA,Stabilize `int_roundings`,jhpratt,NA,NA,NA,HOORAY,2022-03-01T01:08:29Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/94455,OPEN,2022-02-28T20:10:04Z,NA,Stabilize `int_roundings`,jhpratt,NA,NA,NA,HOORAY,2022-03-01T16:00:34Z,danburkert,dan@danburkert.com https://github.com/rust-lang/rust/pull/94455,OPEN,2022-02-28T20:10:04Z,NA,Stabilize `int_roundings`,jhpratt,NA,NA,NA,HOORAY,2022-03-08T09:37:28Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94455,OPEN,2022-02-28T20:10:04Z,NA,Stabilize `int_roundings`,jhpratt,NA,NA,NA,HOORAY,2022-03-08T21:35:55Z,anko,antti.korpimaki@gmail.com https://github.com/rust-lang/rust/pull/94455,OPEN,2022-02-28T20:10:04Z,NA,Stabilize `int_roundings`,jhpratt,NA,NA,NA,HOORAY,2022-04-29T21:13:30Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-02-28T21:25:16Z,rami3l,rami3l@outlook.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-03-23T15:20:30Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-10T20:39:59Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-15T11:49:40Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-21T03:06:21Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-21T12:06:14Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-21T14:08:40Z,DianaNites,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-21T20:59:28Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-22T19:46:37Z,rben01,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-24T17:37:29Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-04-25T03:02:17Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-04-25T05:16:35Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-05-23T20:26:20Z,theHamsta,stephan.seitz@fau.de https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-05-23T20:26:21Z,theHamsta,stephan.seitz@fau.de https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-14T13:19:41Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-23T23:50:51Z,lucacavallaro,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-24T21:44:14Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-27T12:00:20Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-27T12:00:21Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-28T10:55:48Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-28T11:11:07Z,PoignardAzur,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-28T12:17:04Z,pragmatrix,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-28T14:55:08Z,sudormrfbin,gokulps15@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-28T16:26:11Z,robinhundt,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-28T18:37:22Z,zohnannor,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-28T20:44:34Z,dmilith,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-29T02:59:15Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-29T02:59:16Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-30T16:48:52Z,butzist,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-06-30T17:53:42Z,zohnannor,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-06-30T21:25:21Z,shekohex,hey@shadykhalifa.me https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,HOORAY,2022-07-02T16:40:49Z,maxwase,max.vvase@gmail.com https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-07-03T01:07:56Z,Xithrius,NA https://github.com/rust-lang/rust/pull/94457,MERGED,2022-02-28T20:39:27Z,2022-04-15T21:14:32Z,Stabilize `derive_default_enum`,jhpratt,27e2d811e67f5fa0658f62aa55538bed250ecb68,16,Rollup merge of #94457 - jhpratt:stabilize-derive_default_enum r=davidtwco Stabilize `derive_default_enum` This stabilizes `#![feature(derive_default_enum)]` as proposed in [RFC 3107](https://github.com/rust-lang/rfcs/pull/3107) and tracked in #87517. In short it permits you to `#[derive(Default)]` on `enum`s indicating what the default should be by placing a `#[default]` attribute on the desired variant (which must be a unit variant in the interest of forward compatibility). ```````@rustbot``````` label +S-waiting-on-review +T-lang,THUMBS_UP,2022-07-06T06:56:25Z,rino2000,NA https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_UP,2022-02-28T23:39:42Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",HEART,2022-02-28T23:39:48Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_UP,2022-02-28T23:49:22Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",HEART,2022-03-01T00:01:08Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_UP,2022-03-01T09:58:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_UP,2022-03-01T17:16:26Z,est31,NA https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_UP,2022-04-14T20:32:27Z,CohenArthur,NA https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",HEART,2022-04-15T04:55:02Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94461,MERGED,2022-02-28T23:36:21Z,2022-04-15T21:14:32Z,Create (unstable) 2024 edition,jhpratt,20bf34f8c597dd860c9e2c043a9b27b458d3d30c,14,"Rollup merge of #94461 - jhpratt:2024-edition r=pnkfelix Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652) there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes I've merged the ""hello"" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team to be honest.",THUMBS_DOWN,2022-06-30T11:47:29Z,AlphaHot,NA https://github.com/rust-lang/rust/pull/94467,OPEN,2022-03-01T01:10:43Z,NA,Add `special_module_name` lint,ibraheemdev,NA,NA,NA,HEART,2022-03-01T10:39:13Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94467,OPEN,2022-03-01T01:10:43Z,NA,Add `special_module_name` lint,ibraheemdev,NA,NA,NA,HEART,2022-05-05T21:09:21Z,Kimundi,loebel.marvin@gmail.com https://github.com/rust-lang/rust/pull/94467,OPEN,2022-03-01T01:10:43Z,NA,Add `special_module_name` lint,ibraheemdev,NA,NA,NA,HEART,2022-05-05T21:09:30Z,mejrs,NA https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-01T02:17:03Z,roblabla,unfiltered@roblab.la https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-01T04:10:02Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-01T09:59:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-01T14:22:06Z,DianaNites,NA https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-02T08:13:26Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-03-06T12:01:11Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/94468,MERGED,2022-03-01T02:00:19Z,2022-04-16T06:55:28Z,Implement sym operands for global_asm!,Amanieu,080d5452e1bb6e18e12a073d4d0283fd9b6dac0b,50,Auto merge of #94468 - Amanieu:global_asm_sym r=nagisa Implement sym operands for global_asm! Tracking issue: #93333 This PR is pretty much a complete rewrite of `sym` operand support for inline assembly so that the same implementation can be shared by `asm!` and `global_asm!`. The main changes are: - At the AST level `sym` is represented as a special `InlineAsmSym` AST node containing a path instead of an `Expr`. - At the HIR level `sym` is split into `SymStatic` and `SymFn` depending on whether the path resolves to a static during AST lowering (defaults to `SynFn` if `get_early_res` fails). - `SymFn` is just an `AnonConst`. It runs through typeck and we just collect the resulting type at the end. An error is emitted if the type is not a `FnDef`. - `SymStatic` directly holds a path and the `DefId` of the `static` that it is pointing to. - The representation at the MIR level is mostly unchanged. There is a minor change to THIR where `SymFn` is a constant instead of an expression. - At the codegen level we need to apply the target's symbol mangling to the result of `tcx.symbol_name()` depending on the target. This is done by calling the LLVM name mangler which handles all of the details. - On Mach-O all symbols have a leading underscore. - On x86 Windows different mangling is used for cdecl stdcall fastcall and vectorcall. - No mangling is needed on other platforms. r? `@nagisa` cc `@eddyb`,HOORAY,2022-04-13T02:57:43Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/94472,MERGED,2022-03-01T05:27:22Z,2022-03-11T21:44:12Z,Use MaybeUninit in VecDeque to remove the undefined behavior of slice,JmPotato,335ffbfa547df94ac236f5c56130cecf99c8d82b,2,Auto merge of #94472 - JmPotato:use_maybeuninit_for_vecdeque r=m-ou-se Use MaybeUninit in VecDeque to remove the undefined behavior of slice Signed-off-by: JmPotato Ref https://github.com/rust-lang/rust/issues/74189. Adjust the code to follow the [doc.rust-lang.org/reference/behavior-considered-undefined.html](https://doc.rust-lang.org/reference/behavior-considered-undefined.html). * Change the return type of `buffer_as_slice` from `&[T]` to `&[MaybeUninit]`. * Add some corresponding safety comments. Benchmark results: master 8d6f527530f4ba974d922269267fe89050188789 ```rust test collections::vec_deque::tests::bench_pop_back_100 ... bench: 47 ns/iter (+/- 1) test collections::vec_deque::tests::bench_pop_front_100 ... bench: 50 ns/iter (+/- 4) test collections::vec_deque::tests::bench_push_back_100 ... bench: 69 ns/iter (+/- 10) test collections::vec_deque::tests::bench_push_front_100 ... bench: 72 ns/iter (+/- 6) test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 145 891 ns/iter (+/- 7 975) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 141 647 ns/iter (+/- 3 711) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 120 132 ns/iter (+/- 4 078) ``` This PR ```rust test collections::vec_deque::tests::bench_pop_back_100 ... bench: 48 ns/iter (+/- 2) test collections::vec_deque::tests::bench_pop_front_100 ... bench: 51 ns/iter (+/- 3) test collections::vec_deque::tests::bench_push_back_100 ... bench: 73 ns/iter (+/- 2) test collections::vec_deque::tests::bench_push_front_100 ... bench: 73 ns/iter (+/- 2) test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 131 796 ns/iter (+/- 5 440) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 137 563 ns/iter (+/- 3 349) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 128 815 ns/iter (+/- 3 289) ```,HOORAY,2022-03-16T14:47:26Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94472,MERGED,2022-03-01T05:27:22Z,2022-03-11T21:44:12Z,Use MaybeUninit in VecDeque to remove the undefined behavior of slice,JmPotato,335ffbfa547df94ac236f5c56130cecf99c8d82b,2,Auto merge of #94472 - JmPotato:use_maybeuninit_for_vecdeque r=m-ou-se Use MaybeUninit in VecDeque to remove the undefined behavior of slice Signed-off-by: JmPotato Ref https://github.com/rust-lang/rust/issues/74189. Adjust the code to follow the [doc.rust-lang.org/reference/behavior-considered-undefined.html](https://doc.rust-lang.org/reference/behavior-considered-undefined.html). * Change the return type of `buffer_as_slice` from `&[T]` to `&[MaybeUninit]`. * Add some corresponding safety comments. Benchmark results: master 8d6f527530f4ba974d922269267fe89050188789 ```rust test collections::vec_deque::tests::bench_pop_back_100 ... bench: 47 ns/iter (+/- 1) test collections::vec_deque::tests::bench_pop_front_100 ... bench: 50 ns/iter (+/- 4) test collections::vec_deque::tests::bench_push_back_100 ... bench: 69 ns/iter (+/- 10) test collections::vec_deque::tests::bench_push_front_100 ... bench: 72 ns/iter (+/- 6) test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 145 891 ns/iter (+/- 7 975) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 141 647 ns/iter (+/- 3 711) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 120 132 ns/iter (+/- 4 078) ``` This PR ```rust test collections::vec_deque::tests::bench_pop_back_100 ... bench: 48 ns/iter (+/- 2) test collections::vec_deque::tests::bench_pop_front_100 ... bench: 51 ns/iter (+/- 3) test collections::vec_deque::tests::bench_push_back_100 ... bench: 73 ns/iter (+/- 2) test collections::vec_deque::tests::bench_push_front_100 ... bench: 73 ns/iter (+/- 2) test collections::vec_deque::tests::bench_retain_half_10000 ... bench: 131 796 ns/iter (+/- 5 440) test collections::vec_deque::tests::bench_retain_odd_10000 ... bench: 137 563 ns/iter (+/- 3 349) test collections::vec_deque::tests::bench_retain_whole_10000 ... bench: 128 815 ns/iter (+/- 3 289) ```,HOORAY,2022-03-18T01:00:00Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/94489,OPEN,2022-03-01T17:08:32Z,NA,Re-enable debuginfo tests that have been ignored,wesleywiser,NA,NA,NA,HOORAY,2022-03-01T21:56:36Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94489,OPEN,2022-03-01T17:08:32Z,NA,Re-enable debuginfo tests that have been ignored,wesleywiser,NA,NA,NA,HOORAY,2022-03-02T15:41:40Z,lqd,NA https://github.com/rust-lang/rust/pull/94493,MERGED,2022-03-01T17:48:35Z,2022-04-19T15:34:30Z,Improved diagnostic on failure to meet send bound on future in a foreign crate,oribenshir,ab59516dfd23feee736693c93f5abbb35f60107e,11,Rollup merge of #94493 - oribenshir:feature/ISSUE-78543_async_fn_in_foreign_crate_diag_2 r=davidtwco Improved diagnostic on failure to meet send bound on future in a foreign crate Provide a better diagnostic on failure to meet send bound on futures in a foreign crate. fixes #78543,HEART,2022-03-02T18:40:56Z,estebank,NA https://github.com/rust-lang/rust/pull/94495,MERGED,2022-03-01T19:41:36Z,2022-03-27T21:36:44Z,Provide suggestion for missing `>` in a type parameter list,estebank,ab0c2e18dceb7140626a158affb983ae81039bd0,20,Auto merge of #94495 - estebank:missing-closing-gt r=jackh726 Provide suggestion for missing `>` in a type parameter list When encountering an inproperly terminated type parameter list provide a suggestion to close it after the last non-constraint type parameter that was successfully parsed. Fix #94058.,HEART,2022-03-02T08:39:11Z,hkmatsumoto,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HOORAY,2022-03-02T00:21:31Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T00:21:34Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,ROCKET,2022-03-02T00:21:35Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HOORAY,2022-03-02T00:34:18Z,Lokathor,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T00:34:19Z,Lokathor,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,ROCKET,2022-03-02T00:34:20Z,Lokathor,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T00:40:38Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T00:51:23Z,mati865,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,ROCKET,2022-03-02T00:51:25Z,mati865,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HOORAY,2022-03-02T00:51:27Z,mati865,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T02:27:54Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,THUMBS_UP,2022-03-02T11:27:58Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-03-02T15:20:38Z,bstrie,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HOORAY,2022-03-03T22:34:06Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,THUMBS_UP,2022-03-15T12:56:09Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-05-09T05:57:56Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HOORAY,2022-06-07T15:45:31Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/94503,MERGED,2022-03-01T22:55:08Z,2022-03-02T08:09:56Z,Provide C FFI types via core::ffi not just in std,joshtriplett,3ea9eebb73d07d81e7bd92ba6ec4a6da37c18ae9,23,Rollup merge of #94503 - joshtriplett:core-ffi-c r=Amanieu Provide C FFI types via core::ffi not just in std Tracking issue: https://github.com/rust-lang/rust/issues/94501 The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi` while leaving them unstable. Historically we didn't do this because these types are target-dependent. However `core` itself is also target-dependent. `core` should not call any OS services but it knows the target and the target's ABI.,HEART,2022-06-07T15:45:32Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/94505,MERGED,2022-03-01T23:00:45Z,2022-03-03T06:56:25Z,Restore the local filter on mono item sorting,cuviper,3e6abf0c35da7e6906033ba6020af45f0dcab28d,2,Rollup merge of #94505 - cuviper:mono-item-sort-local r=michaelwoerister davidtwco Restore the local filter on mono item sorting In `CodegenUnit::items_in_deterministic_order` there's a comment that only local HirIds should be taken into account but #90408 removed the `as_local` call that sets others to None. Restoring that check fixes the s390x hangs seen in [RHBZ 2058803]. [RHBZ 2058803]: https://bugzilla.redhat.com/show_bug.cgi?id=2058803,THUMBS_UP,2022-03-02T05:18:36Z,pierwill,NA https://github.com/rust-lang/rust/pull/94515,MERGED,2022-03-02T04:30:55Z,2022-03-09T11:39:39Z,Tweak move error,estebank,10dccdc7fcbdc64ee9efe2c1ed975ab8c1d61287,21,Auto merge of #94515 - estebank:tweak-move-error r=davidtwco Tweak move error Point at method definition that causes type to be consumed. Fix #94056.,HOORAY,2022-03-10T15:37:25Z,edmorley,NA https://github.com/rust-lang/rust/pull/94524,MERGED,2022-03-02T14:25:55Z,2022-03-04T19:01:33Z,Remove num_cpus dependency from bootstrap build-manifest and rustc_s…,bjorn3,5115bdc2e2829e9c9a7ce10516bd26469049e0a9,9,Rollup merge of #94524 - bjorn3:remove_num_cpus r=Mark-Simulacrum Remove num_cpus dependency from bootstrap build-manifest and rustc_s… …ession `std::threads::available_parallelism` was stabilized in rust 1.59. r? ```````````````````````````@Mark-Simulacrum```````````````````````````,HEART,2022-03-02T15:36:58Z,lqd,NA https://github.com/rust-lang/rust/pull/94552,MERGED,2022-03-03T10:52:15Z,2022-03-07T13:02:31Z,[beta] backport fix for #94502,lcnr,e5effbd0b34c9ede216e21d3f60dcbad0b863676,5,Auto merge of #94552 - lcnr:fix-94502 r=oli-obk [beta] backport fix for #94502 this issue was fixed as part of #93368 so i extracted the change from there closes #94502,HEART,2022-03-03T21:29:50Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94552,MERGED,2022-03-03T10:52:15Z,2022-03-07T13:02:31Z,[beta] backport fix for #94502,lcnr,e5effbd0b34c9ede216e21d3f60dcbad0b863676,5,Auto merge of #94552 - lcnr:fix-94502 r=oli-obk [beta] backport fix for #94502 this issue was fixed as part of #93368 so i extracted the change from there closes #94502,HEART,2022-03-04T23:25:12Z,estebank,NA https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",ROCKET,2022-03-03T15:42:38Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",ROCKET,2022-03-03T22:34:27Z,danielg1111,NA https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",HOORAY,2022-03-04T06:29:09Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",ROCKET,2022-03-05T17:47:20Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",HOORAY,2022-03-05T17:47:21Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",HOORAY,2022-03-09T22:05:50Z,oconnor663,oconnor663@gmail.com https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",HOORAY,2022-03-17T09:06:17Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",ROCKET,2022-03-17T09:06:18Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94559,MERGED,2022-03-03T13:32:38Z,2022-03-08T12:45:16Z,Remove argument from closure in thread::Scope::spawn.,m-ou-se,aec535f8051c7cf00b1e373a05893b2cb580eeac,2,"Rollup merge of #94559 - m-ou-se:thread-scope-spawn-closure-without-arg r=Mark-Simulacrum Remove argument from closure in thread::Scope::spawn. This implements ```@danielhenrymantilla's``` [suggestion](https://github.com/rust-lang/rust/issues/93203#issuecomment-1040798286) for improving the scoped threads interface. Summary: The `Scope` type gets an extra lifetime argument which represents basically its own lifetime that will be used in `&'scope Scope<'scope 'env>`: ```diff - pub struct Scope<'env> { .. }; + pub struct Scope<'scope 'env: 'scope> { .. } pub fn scope<'env F T>(f: F) -> T where - F: FnOnce(&Scope<'env>) -> T; + F: for<'scope> FnOnce(&'scope Scope<'scope 'env>) -> T; ``` This simplifies the `spawn` function which now no longer passes an argument to the closure you give it and now uses the `'scope` lifetime for everything: ```diff - pub fn spawn<'scope F T>(&'scope self f: F) -> ScopedJoinHandle<'scope T> + pub fn spawn(&'scope self f: F) -> ScopedJoinHandle<'scope T> where - F: FnOnce(&Scope<'env>) -> T + Send + 'env + F: FnOnce() -> T + Send + 'scope - T: Send + 'env; + T: Send + 'scope; ``` The only difference the user will notice is that their closure now takes no arguments anymore even when spawning threads from spawned threads: ```diff thread::scope(|s| { - s.spawn(|_| { + s.spawn(|| { ... }); - s.spawn(|s| { + s.spawn(|| { ... - s.spawn(|_| ...); + s.spawn(|| ...); }); }); ```
And as a bonus errors get slightly better because now any lifetime issues point to the outermost s (since there is only one s) rather than the innermost s making it clear that the lifetime lasts for the entire thread::scope. ```diff error[E0373]: closure may outlive the current function but it borrows `a` which is owned by the current function --> src/main.rs:9:21 | - 7 | s.spawn(|s| { - | - has type `&Scope<'1>` + 6 | thread::scope(|s| { + | - lifetime `'1` appears in the type of `s` 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^ - `a` is borrowed here | | | may outlive borrowed value `a` | note: function requires argument type to outlive `'1` --> src/main.rs:9:13 | 9 | s.spawn(|| println!(""{:?}"" a)); // might run after `a` is dropped | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to force the closure to take ownership of `a` (and any other referenced variables) use the `move` keyword | 9 | s.spawn(move || println!(""{:?}"" a)); // might run after `a` is dropped | ++++ "" ```
The downside is that the signature of `scope` and `Scope` gets slightly more complex but in most cases the user wouldn't need to write those as they just use the argument provided by `thread::scope` without having to name its type. Another downside is that this does not work nicely in Rust 2015 and Rust 2018 since in those editions `s` would be captured by reference and not by copy. In those editions the user would need to use `move ||` to capture `s` by copy. (Which is what the compiler suggests in the error.)",THUMBS_UP,2022-03-19T00:14:41Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/94584,MERGED,2022-03-04T00:03:45Z,2022-03-15T06:16:10Z,More robust fallback for `use` suggestion ,pnkfelix,95561b336cf82a8250176eb3c61ea61c90e75d47,27,Auto merge of #94584 - pnkfelix:inject-use-suggestion-sites r=ekuber More robust fallback for `use` suggestion Our old way to suggest where to add `use`s would first look for pre-existing `use`s in the relevant crate/module and if there are *no* uses it would fallback on trying to use another item as the basis for the suggestion. But this was fragile as illustrated in issue #87613 This PR instead identifies span of the first token after any inner attributes and uses *that* as the fallback for the `use` suggestion. Fix #87613,HEART,2022-03-11T01:03:03Z,camelid,NA https://github.com/rust-lang/rust/pull/94590,CLOSED,2022-03-04T01:35:45Z,2022-04-01T02:15:25Z,Clarify semantics of `SetDiscriminant` and change enum deaggregation to match those semantics,JakobDegen,NA,NA,NA,HEART,2022-03-04T08:43:13Z,xldenis,NA https://github.com/rust-lang/rust/pull/94607,CLOSED,2022-03-04T14:22:02Z,2022-05-25T00:26:20Z,Move theme picker button to the right and display it on all pages,GuillaumeGomez,NA,NA,NA,ROCKET,2022-03-04T14:23:08Z,Urgau,NA https://github.com/rust-lang/rust/pull/94607,CLOSED,2022-03-04T14:22:02Z,2022-05-25T00:26:20Z,Move theme picker button to the right and display it on all pages,GuillaumeGomez,NA,NA,NA,HEART,2022-03-04T14:23:10Z,Urgau,NA https://github.com/rust-lang/rust/pull/94607,CLOSED,2022-03-04T14:22:02Z,2022-05-25T00:26:20Z,Move theme picker button to the right and display it on all pages,GuillaumeGomez,NA,NA,NA,HOORAY,2022-03-04T14:23:12Z,Urgau,NA https://github.com/rust-lang/rust/pull/94607,CLOSED,2022-03-04T14:22:02Z,2022-05-25T00:26:20Z,Move theme picker button to the right and display it on all pages,GuillaumeGomez,NA,NA,NA,THUMBS_UP,2022-03-04T14:23:16Z,Urgau,NA https://github.com/rust-lang/rust/pull/94620,MERGED,2022-03-04T19:32:33Z,2022-03-05T07:26:57Z,Edit docs on consistency of `PartialOrd` and `PartialEq`,pierwill,a3fe63e9fe73bea75c2405dd0928d78b5c83daf8,1,Rollup merge of #94620 - pierwill:partialord-constistency r=yaahc Edit docs on consistency of `PartialOrd` and `PartialEq` Use ordered list to make the information about implementations more readable.,THUMBS_UP,2022-03-04T19:47:21Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94633,MERGED,2022-03-05T03:22:40Z,2022-03-05T22:12:54Z,Suggest removing a semicolon after derive attributes,TaKO8Ki,e887e6647cac83371ac3055fa67f18d424be4769,3,Rollup merge of #94633 - TaKO8Ki:suggest-removing-semicolon-after-derive-attribute r=cjgillot Suggest removing a semicolon after derive attributes closes #93942,HEART,2022-03-05T17:49:55Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/94633,MERGED,2022-03-05T03:22:40Z,2022-03-05T22:12:54Z,Suggest removing a semicolon after derive attributes,TaKO8Ki,e887e6647cac83371ac3055fa67f18d424be4769,3,Rollup merge of #94633 - TaKO8Ki:suggest-removing-semicolon-after-derive-attribute r=cjgillot Suggest removing a semicolon after derive attributes closes #93942,HEART,2022-03-10T18:28:19Z,estebank,NA https://github.com/rust-lang/rust/pull/94635,MERGED,2022-03-05T04:02:30Z,2022-03-10T14:58:48Z,Merge `#[deprecated]` and `#[rustc_deprecated]`,jhpratt,313a668234ad7b60fc5df280ba37cf9a39130bd6,42,"Rollup merge of #94635 - jhpratt:merge-deprecated-attrs r=davidtwco Merge `#[deprecated]` and `#[rustc_deprecated]` The first commit makes ""reason"" an alias for ""note"" in `#[rustc_deprecated]` while still prohibiting it in `#[deprecated]`. The second commit changes ""suggestion"" to not just be a feature of `#[rustc_deprecated]`. This is placed behind the new `deprecated_suggestion` feature. This needs a tracking issue; let me know if this PR will be approved and I can create one. The third commit is what permits `#[deprecated]` to be used when `#![feature(staged_api)]` is enabled. This isn't yet used in stdlib (only tests) as it would require duplicating all deprecation attributes until a bootstrap occurs. I intend to submit a follow-up PR that replaces all uses and removes the remaining `#[rustc_deprecated]` code after the next bootstrap. `@rustbot` label +T-libs-api +C-feature-request +A-attributes +S-waiting-on-review",THUMBS_UP,2022-03-05T04:07:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94635,MERGED,2022-03-05T04:02:30Z,2022-03-10T14:58:48Z,Merge `#[deprecated]` and `#[rustc_deprecated]`,jhpratt,313a668234ad7b60fc5df280ba37cf9a39130bd6,42,"Rollup merge of #94635 - jhpratt:merge-deprecated-attrs r=davidtwco Merge `#[deprecated]` and `#[rustc_deprecated]` The first commit makes ""reason"" an alias for ""note"" in `#[rustc_deprecated]` while still prohibiting it in `#[deprecated]`. The second commit changes ""suggestion"" to not just be a feature of `#[rustc_deprecated]`. This is placed behind the new `deprecated_suggestion` feature. This needs a tracking issue; let me know if this PR will be approved and I can create one. The third commit is what permits `#[deprecated]` to be used when `#![feature(staged_api)]` is enabled. This isn't yet used in stdlib (only tests) as it would require duplicating all deprecation attributes until a bootstrap occurs. I intend to submit a follow-up PR that replaces all uses and removes the remaining `#[rustc_deprecated]` code after the next bootstrap. `@rustbot` label +T-libs-api +C-feature-request +A-attributes +S-waiting-on-review",THUMBS_UP,2022-03-05T04:21:28Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94635,MERGED,2022-03-05T04:02:30Z,2022-03-10T14:58:48Z,Merge `#[deprecated]` and `#[rustc_deprecated]`,jhpratt,313a668234ad7b60fc5df280ba37cf9a39130bd6,42,"Rollup merge of #94635 - jhpratt:merge-deprecated-attrs r=davidtwco Merge `#[deprecated]` and `#[rustc_deprecated]` The first commit makes ""reason"" an alias for ""note"" in `#[rustc_deprecated]` while still prohibiting it in `#[deprecated]`. The second commit changes ""suggestion"" to not just be a feature of `#[rustc_deprecated]`. This is placed behind the new `deprecated_suggestion` feature. This needs a tracking issue; let me know if this PR will be approved and I can create one. The third commit is what permits `#[deprecated]` to be used when `#![feature(staged_api)]` is enabled. This isn't yet used in stdlib (only tests) as it would require duplicating all deprecation attributes until a bootstrap occurs. I intend to submit a follow-up PR that replaces all uses and removes the remaining `#[rustc_deprecated]` code after the next bootstrap. `@rustbot` label +T-libs-api +C-feature-request +A-attributes +S-waiting-on-review",HEART,2022-03-06T03:34:41Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/94639,MERGED,2022-03-05T07:18:13Z,2022-05-18T09:53:07Z,Suggest dereferencing non-lval mutable reference on assignment,compiler-errors,64c58a1a4ab6ba68db6d87a6a1f813679875110e,13,Rollup merge of #94639 - compiler-errors:rval-mutref r=wesleywiser Suggest dereferencing non-lval mutable reference on assignment 1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut` 2. Fixes missing deref suggestions for LHS when it isn't a place expr Fixes #46276 Fixes #93980,HEART,2022-05-18T16:09:33Z,estebank,NA https://github.com/rust-lang/rust/pull/94639,MERGED,2022-03-05T07:18:13Z,2022-05-18T09:53:07Z,Suggest dereferencing non-lval mutable reference on assignment,compiler-errors,64c58a1a4ab6ba68db6d87a6a1f813679875110e,13,Rollup merge of #94639 - compiler-errors:rval-mutref r=wesleywiser Suggest dereferencing non-lval mutable reference on assignment 1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut` 2. Fixes missing deref suggestions for LHS when it isn't a place expr Fixes #46276 Fixes #93980,HEART,2022-05-18T20:49:33Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/94639,MERGED,2022-03-05T07:18:13Z,2022-05-18T09:53:07Z,Suggest dereferencing non-lval mutable reference on assignment,compiler-errors,64c58a1a4ab6ba68db6d87a6a1f813679875110e,13,Rollup merge of #94639 - compiler-errors:rval-mutref r=wesleywiser Suggest dereferencing non-lval mutable reference on assignment 1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut` 2. Fixes missing deref suggestions for LHS when it isn't a place expr Fixes #46276 Fixes #93980,HEART,2022-05-26T13:42:25Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94640,MERGED,2022-03-05T11:09:04Z,2022-05-28T11:49:49Z,Partially stabilize `(const_)slice_ptr_len` feature by stabilizing `NonNull::len`,Pointerbender,837cd9e26c5f741d57c19d4ae35253f26b654a1e,1,Rollup merge of #94640 - Pointerbender:issue-71146-partial-stabilization r=yaahc Partially stabilize `(const_)slice_ptr_len` feature by stabilizing `NonNull::len` This PR partially stabilizes features `const_slice_ptr_len` and `slice_ptr_len` by only stabilizing `NonNull::len`. This partial stabilization is tracked under features `slice_ptr_len_nonnull` and `const_slice_ptr_len_nonnull` for which this PR can serve as the tracking issue. To summarize the discussion from #71146 leading up to this partial stabilization request: It's currently a bit footgunny to obtain the length of a raw slice pointer stabilization of `NonNull:len` will help with removing these footguns. Some example footguns are: ```rust /// # Safety /// The caller must ensure that `ptr`: /// 1. does not point to memory that was previously allocated but is now deallocated; /// 2. is within the bounds of a single allocated object; /// 3. does not to point to a slice for which the length exceeds `isize::MAX` bytes; /// 4. points to a properly aligned address; /// 5. does not point to uninitialized memory; /// 6. does not point to a mutably borrowed memory location. pub unsafe fn ptr_len(ptr: core::ptr::NonNull<[T]>) -> usize { (&*ptr.as_ptr()).len() } ``` A slightly less complicated version (but still more complicated than it needs to be): ```rust /// # Safety /// The caller must ensure that the start of `ptr`: /// 1. does not point to memory that was previously allocated but is now deallocated; /// 2. must be within the bounds of a single allocated object. pub unsafe fn ptr_len(ptr: NonNull<[T]>) -> usize { (&*(ptr.as_ptr() as *const [()])).len() } ``` This PR does not stabilize `<*const [T]>::len` and `<*mut [T]>::len` because the tracking issue #71146 list a potential blocker for these methods but this blocker [does not apply](https://github.com/rust-lang/rust/issues/71146#issuecomment-808735714) to `NonNull::len`. We should probably also ping the [Constant Evaluation WG](https://github.com/rust-lang/const-eval) since this PR includes a `#[rustc_allow_const_fn_unstable(const_slice_ptr_len)]`. My instinct here is that this will probably be okay because the pointer is not actually dereferenced and `len()` does not touch the address component of the pointer but would be best to double check :) One potential down-side was raised that stabilizing `NonNull::len` could lead to encouragement of coding patterns like: ``` pub fn ptr_len(ptr: *mut [T]) -> usize { NonNull::new(ptr).unwrap().len() } ``` which unnecessarily assert non-nullness. However these are much less of a footgun than the above examples and this should be resolved when `slice_ptr_len` fully stabilizes eventually.,ROCKET,2022-04-25T09:46:40Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/94644,MERGED,2022-03-05T16:22:40Z,2022-03-10T20:51:54Z,Fix soundness issue in scoped threads.,m-ou-se,f1a677789ae12780fcc49fb449be8b336528b080,3,Rollup merge of #94644 - m-ou-se:scoped-threads-drop-soundness r=joshtriplett Fix soundness issue in scoped threads. This was discovered in https://github.com/rust-lang/rust/pull/94559#discussion_r820116323 The `scope()` function returns when all threads are finished but I accidentally considered a thread 'finished' before dropping their panic payload or ignored return value. So if a thread returned (or panics with) something that in its `Drop` implementation still uses borrowed stuff it goes wrong. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2a1f19ac4676cdabe43e24e536ff9358,HEART,2022-03-06T15:58:02Z,mati865,NA https://github.com/rust-lang/rust/pull/94644,MERGED,2022-03-05T16:22:40Z,2022-03-10T20:51:54Z,Fix soundness issue in scoped threads.,m-ou-se,f1a677789ae12780fcc49fb449be8b336528b080,3,Rollup merge of #94644 - m-ou-se:scoped-threads-drop-soundness r=joshtriplett Fix soundness issue in scoped threads. This was discovered in https://github.com/rust-lang/rust/pull/94559#discussion_r820116323 The `scope()` function returns when all threads are finished but I accidentally considered a thread 'finished' before dropping their panic payload or ignored return value. So if a thread returned (or panics with) something that in its `Drop` implementation still uses borrowed stuff it goes wrong. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2a1f19ac4676cdabe43e24e536ff9358,HEART,2022-03-17T08:51:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94647,MERGED,2022-03-05T17:40:55Z,2022-06-01T17:25:33Z,Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap,Urgau,9ddae155322de3ed2f348629925a18538e96020c,1,Rollup merge of #94647 - Urgau:hash-map-many-mut r=Amanieu Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap This pull-request expose the function [`get_many_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_mut) and [`get_many_unchecked_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_unchecked_mut) from `hashbrown` to the standard library `HashMap` type. They obviously keep the same API and are added under the (new) `map_many_mut` feature. - `get_many_mut`: Attempts to get mutable references to `N` values in the map at once. - `get_many_unchecked_mut`: Attempts to get mutable references to `N` values in the map at once without validating that the values are unique.,THUMBS_UP,2022-06-09T08:58:29Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/94649,MERGED,2022-03-05T18:02:31Z,2022-03-06T15:26:24Z,"Unix path::absolute: Fix leading ""."" component",ChrisDenton,8ea3f236dc45cd4bee67504ae4b1cf64ee5de7ad,2,"Rollup merge of #94649 - ChrisDenton:unix-absolute-fix r=Dylan-DPC Unix path::absolute: Fix leading ""."" component Testing leading `.` and `..` components were missing from the unix tests. This PR adds them and fixes the leading `.` case. It also fixes the test cases so that they do an exact comparison. This problem reported by ``@axetroy``",THUMBS_UP,2022-03-05T18:22:26Z,axetroy,axetroy.dev@gmail.com https://github.com/rust-lang/rust/pull/94655,MERGED,2022-03-06T01:45:24Z,2022-03-25T04:01:01Z,Clarify which kinds of MIR are allowed during which phases.,JakobDegen,c66e0c87267859a46f1a8851f30892985760cfd6,8,Rollup merge of #94655 - JakobDegen:mir-phase-docs r=oli-obk Clarify which kinds of MIR are allowed during which phases. This enhances documentation with these details and extends the validator to check these requirements more thoroughly. Most of these conditions were already being checked. There was also some disagreement between the `MirPhase` docs and validator as to what it meant for the `body.phase` field to have a certain value. This PR resolves those disagreements in favor of the `MirPhase` docs (which is what the pass manager implemented) adjusting the validator accordingly. The result is now that the `DropLowering` phase begins with the end of the elaborate drops pass and lasts until the beginning of the generator lowring pass. This doesn't feel entirely natural to me but as long as it's documented accurately it should be ok. r? rust-lang/mir-opt,HOORAY,2022-03-23T20:05:11Z,scottmcm,NA https://github.com/rust-lang/rust/pull/94657,MERGED,2022-03-06T03:03:53Z,2022-03-10T14:58:47Z,Constify `Index{ Mut}` for `[T]` `str` and `[T; N]`,fee1-dead,fe034cb43baf6fe415ca0f530cd72614df447b70,13,Rollup merge of #94657 - fee1-dead:const_slice_index r=oli-obk Constify `Index{ Mut}` for `[T]` `str` and `[T; N]` Several panic functions were rewired (via `const_eval_select`) to simpler implementations that do not require formatting for compile-time usage. r? ```@oli-obk```,THUMBS_UP,2022-03-06T10:34:24Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/94667,OPEN,2022-03-06T09:32:53Z,NA,Add `Iterator::map_windows`,frank-king,NA,NA,NA,THUMBS_UP,2022-03-07T11:35:30Z,pymongo,os.popen@gmail.com https://github.com/rust-lang/rust/pull/94667,OPEN,2022-03-06T09:32:53Z,NA,Add `Iterator::map_windows`,frank-king,NA,NA,NA,THUMBS_UP,2022-03-07T15:59:32Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/94670,MERGED,2022-03-06T13:39:48Z,2022-03-15T00:32:22Z,Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383),xFrednet,6548a368c8c66c802ba710dd9fede228dc65587e,8,"Rollup merge of #94670 - xFrednet:rfc-2383-expect-impl-after-party r=flip1995 wesleywiser Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383) This PR updates unstable `ExpectationIds` in stashed diagnostics and adds some asserts to ensure that the stored expectations are really empty in the end. Additionally it handles the `#[expect(unfulfilled_lint_expectations)]` case. According to the [Errors and lints docs](https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-levels) the `error` level should only be used _""when the compiler detects a problem that makes it unable to compile the program""_. As this isn't the case with `#[expect(unfulfilled_lint_expectations)]` I decided to only create a warning. To avoid adding a new lint only for this case I simply emit a `unfulfilled_lint_expectations` diagnostic with an additional note. --- r? `@wesleywiser` I'm requesting a review from you since you reviewed the previous PR https://github.com/rust-lang/rust/pull/87835. You are welcome to reassign it if you're busy :upside_down_face: rfc: [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html) tracking issue: https://github.com/rust-lang/rust/issues/85549 cc: `@flip1995` In case you're also interested in this :)",THUMBS_UP,2022-03-07T14:12:45Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/94670,MERGED,2022-03-06T13:39:48Z,2022-03-15T00:32:22Z,Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383),xFrednet,6548a368c8c66c802ba710dd9fede228dc65587e,8,"Rollup merge of #94670 - xFrednet:rfc-2383-expect-impl-after-party r=flip1995 wesleywiser Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383) This PR updates unstable `ExpectationIds` in stashed diagnostics and adds some asserts to ensure that the stored expectations are really empty in the end. Additionally it handles the `#[expect(unfulfilled_lint_expectations)]` case. According to the [Errors and lints docs](https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-levels) the `error` level should only be used _""when the compiler detects a problem that makes it unable to compile the program""_. As this isn't the case with `#[expect(unfulfilled_lint_expectations)]` I decided to only create a warning. To avoid adding a new lint only for this case I simply emit a `unfulfilled_lint_expectations` diagnostic with an additional note. --- r? `@wesleywiser` I'm requesting a review from you since you reviewed the previous PR https://github.com/rust-lang/rust/pull/87835. You are welcome to reassign it if you're busy :upside_down_face: rfc: [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html) tracking issue: https://github.com/rust-lang/rust/issues/85549 cc: `@flip1995` In case you're also interested in this :)",HEART,2022-03-14T13:46:31Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/94684,MERGED,2022-03-06T23:59:35Z,2022-03-07T09:49:16Z,Fix rustdoc for GATs with with anonymous bound regions,compiler-errors,a1119fd6999aa034d026d1d97d4acff8a2662f18,3,Rollup merge of #94684 - compiler-errors:gat-anon-late-bound r=notriddle Fix rustdoc for GATs with with anonymous bound regions Just use the logic that already worked for cleaning trait refs. Fixes #94683,HEART,2022-03-07T00:16:35Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/94684,MERGED,2022-03-06T23:59:35Z,2022-03-07T09:49:16Z,Fix rustdoc for GATs with with anonymous bound regions,compiler-errors,a1119fd6999aa034d026d1d97d4acff8a2662f18,3,Rollup merge of #94684 - compiler-errors:gat-anon-late-bound r=notriddle Fix rustdoc for GATs with with anonymous bound regions Just use the logic that already worked for cleaning trait refs. Fixes #94683,HEART,2022-03-07T00:50:02Z,MingweiSamuel,NA https://github.com/rust-lang/rust/pull/94684,MERGED,2022-03-06T23:59:35Z,2022-03-07T09:49:16Z,Fix rustdoc for GATs with with anonymous bound regions,compiler-errors,a1119fd6999aa034d026d1d97d4acff8a2662f18,3,Rollup merge of #94684 - compiler-errors:gat-anon-late-bound r=notriddle Fix rustdoc for GATs with with anonymous bound regions Just use the logic that already worked for cleaning trait refs. Fixes #94683,HEART,2022-03-07T03:33:59Z,marmeladema,NA https://github.com/rust-lang/rust/pull/94689,MERGED,2022-03-07T02:41:06Z,2022-03-09T00:26:42Z,Use impl substs in `#[rustc_on_unimplemented]`,compiler-errors,568736b98fa6909ae91696b6bd8e1d66f75bfe2d,10,Rollup merge of #94689 - compiler-errors:on-unimplemented-substs r=petrochenkov Use impl substs in `#[rustc_on_unimplemented]` We were using the trait-ref substs instead of impl substs in `rustc_on_unimplemented` even when computing the `rustc_on_unimplemented` attached to an impl block. Let's not do that. This PR also untangles impl and trait def-ids in the logic in `on_unimplemented` a bit. Fixes #94675,THUMBS_UP,2022-03-07T10:59:44Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/94698,MERGED,2022-03-07T12:45:39Z,2022-03-18T03:01:54Z,Remove redundant code from copy-suggestions,WaffleLapkin,a8956e6618370ab766a3c3c79c73a1f1f41130a6,1,Rollup merge of #94698 - WaffleLapkin:simplify-copy-suggestions r=estebank Remove redundant code from copy-suggestions Follow up to #94375 just remove some code that is not necessary anymore. This may make the perf of such suggestions a little bit worse but I don't think this is significant. r? `@estebank`,HEART,2022-03-07T19:45:59Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94698,MERGED,2022-03-07T12:45:39Z,2022-03-18T03:01:54Z,Remove redundant code from copy-suggestions,WaffleLapkin,a8956e6618370ab766a3c3c79c73a1f1f41130a6,1,Rollup merge of #94698 - WaffleLapkin:simplify-copy-suggestions r=estebank Remove redundant code from copy-suggestions Follow up to #94375 just remove some code that is not necessary anymore. This may make the perf of such suggestions a little bit worse but I don't think this is significant. r? `@estebank`,HEART,2022-03-11T21:08:45Z,estebank,NA https://github.com/rust-lang/rust/pull/94708,MERGED,2022-03-07T17:54:52Z,2022-03-08T12:45:15Z,diagnostics: only talk about `Cargo.toml` if running under Cargo,notriddle,98d027cfddae4a10cb4408473dbc9f9b1ce4259d,13,Rollup merge of #94708 - notriddle:notriddle/cargo-toml-warning r=lcnr diagnostics: only talk about `Cargo.toml` if running under Cargo Fixes #94646,HEART,2022-03-07T19:43:26Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94708,MERGED,2022-03-07T17:54:52Z,2022-03-08T12:45:15Z,diagnostics: only talk about `Cargo.toml` if running under Cargo,notriddle,98d027cfddae4a10cb4408473dbc9f9b1ce4259d,13,Rollup merge of #94708 - notriddle:notriddle/cargo-toml-warning r=lcnr diagnostics: only talk about `Cargo.toml` if running under Cargo Fixes #94646,HEART,2022-03-08T21:05:45Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94723,MERGED,2022-03-08T02:54:42Z,2022-03-09T00:26:42Z,Add core::hint::must_use,dtolnay,ff54e34463c1af0025e29d41ebfbc1dfb4083e15,1,"Rollup merge of #94723 - dtolnay:mustuse r=Mark-Simulacrum Add core::hint::must_use The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable. Having this provided by the standard library is especially useful for proc macros even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros so they couldn't make their own `must_use` function for their macro-generated code to call.
## Rendered documentation > An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned stored in a variable etc) by the caller. > > This is primarily intended for use in macro-generated code in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient. > > [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute > > ### Example > > ```rust > #![feature(hint_must_use)] > > use core::fmt; > > pub struct Error(/* ... */); > > #[macro_export] > macro_rules! make_error { > ($($args:expr) *) => { > core::hint::must_use({ > let error = $crate::make_error(core::format_args!($($args) *)); > error > }) > }; > } > > // Implementation detail of make_error! macro. > #[doc(hidden)] > pub fn make_error(args: fmt::Arguments<'_>) -> Error { > Error(/* ... */) > } > > fn demo() -> Option { > if true { > // Oops meant to write `return Some(make_error!(""...""));` > Some(make_error!(""..."")); > } > None > } > ``` > > In the above example we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here so the macro expands using `core::hint::must_use` instead. > > - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning: > > ```rust > fn f(arg: &str) -> Result<() Error> > > #[test] > fn t() { > // Assert that `f` returns error if passed an empty string. > // A value of type `Error` is unused here but that's not a problem. > f("""").unwrap_err(); > } > ``` > > - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error` as keeping them alive past that point can cause autotrait issues in async code: > > ```rust > async fn f() { > // Using `let` inside the make_error expansion causes temporaries like > // `unsync()` to drop at the semicolon of that `let` statement which > // is prior to the await point. They would otherwise stay around until > // the semicolon on *this* statement which is after the await point > // and the enclosing Future would not implement Send. > log(make_error!(""look: {:p}"" unsync())).await; > } > > async fn log(error: Error) {/* ... */} > > // Returns something without a Sync impl. > fn unsync() -> *const () { > 0 as *const () > } > ```",HEART,2022-03-08T03:38:41Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94723,MERGED,2022-03-08T02:54:42Z,2022-03-09T00:26:42Z,Add core::hint::must_use,dtolnay,ff54e34463c1af0025e29d41ebfbc1dfb4083e15,1,"Rollup merge of #94723 - dtolnay:mustuse r=Mark-Simulacrum Add core::hint::must_use The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable. Having this provided by the standard library is especially useful for proc macros even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros so they couldn't make their own `must_use` function for their macro-generated code to call.
## Rendered documentation > An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned stored in a variable etc) by the caller. > > This is primarily intended for use in macro-generated code in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient. > > [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute > > ### Example > > ```rust > #![feature(hint_must_use)] > > use core::fmt; > > pub struct Error(/* ... */); > > #[macro_export] > macro_rules! make_error { > ($($args:expr) *) => { > core::hint::must_use({ > let error = $crate::make_error(core::format_args!($($args) *)); > error > }) > }; > } > > // Implementation detail of make_error! macro. > #[doc(hidden)] > pub fn make_error(args: fmt::Arguments<'_>) -> Error { > Error(/* ... */) > } > > fn demo() -> Option { > if true { > // Oops meant to write `return Some(make_error!(""...""));` > Some(make_error!(""..."")); > } > None > } > ``` > > In the above example we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here so the macro expands using `core::hint::must_use` instead. > > - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning: > > ```rust > fn f(arg: &str) -> Result<() Error> > > #[test] > fn t() { > // Assert that `f` returns error if passed an empty string. > // A value of type `Error` is unused here but that's not a problem. > f("""").unwrap_err(); > } > ``` > > - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error` as keeping them alive past that point can cause autotrait issues in async code: > > ```rust > async fn f() { > // Using `let` inside the make_error expansion causes temporaries like > // `unsync()` to drop at the semicolon of that `let` statement which > // is prior to the await point. They would otherwise stay around until > // the semicolon on *this* statement which is after the await point > // and the enclosing Future would not implement Send. > log(make_error!(""look: {:p}"" unsync())).await; > } > > async fn log(error: Error) {/* ... */} > > // Returns something without a Sync impl. > fn unsync() -> *const () { > 0 as *const () > } > ```",HEART,2022-03-17T08:53:35Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94723,MERGED,2022-03-08T02:54:42Z,2022-03-09T00:26:42Z,Add core::hint::must_use,dtolnay,ff54e34463c1af0025e29d41ebfbc1dfb4083e15,1,"Rollup merge of #94723 - dtolnay:mustuse r=Mark-Simulacrum Add core::hint::must_use The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable. Having this provided by the standard library is especially useful for proc macros even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros so they couldn't make their own `must_use` function for their macro-generated code to call.
## Rendered documentation > An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned stored in a variable etc) by the caller. > > This is primarily intended for use in macro-generated code in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient. > > [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute > > ### Example > > ```rust > #![feature(hint_must_use)] > > use core::fmt; > > pub struct Error(/* ... */); > > #[macro_export] > macro_rules! make_error { > ($($args:expr) *) => { > core::hint::must_use({ > let error = $crate::make_error(core::format_args!($($args) *)); > error > }) > }; > } > > // Implementation detail of make_error! macro. > #[doc(hidden)] > pub fn make_error(args: fmt::Arguments<'_>) -> Error { > Error(/* ... */) > } > > fn demo() -> Option { > if true { > // Oops meant to write `return Some(make_error!(""...""));` > Some(make_error!(""..."")); > } > None > } > ``` > > In the above example we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here so the macro expands using `core::hint::must_use` instead. > > - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning: > > ```rust > fn f(arg: &str) -> Result<() Error> > > #[test] > fn t() { > // Assert that `f` returns error if passed an empty string. > // A value of type `Error` is unused here but that's not a problem. > f("""").unwrap_err(); > } > ``` > > - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error` as keeping them alive past that point can cause autotrait issues in async code: > > ```rust > async fn f() { > // Using `let` inside the make_error expansion causes temporaries like > // `unsync()` to drop at the semicolon of that `let` statement which > // is prior to the await point. They would otherwise stay around until > // the semicolon on *this* statement which is after the await point > // and the enclosing Future would not implement Send. > log(make_error!(""look: {:p}"" unsync())).await; > } > > async fn log(error: Error) {/* ... */} > > // Returns something without a Sync impl. > fn unsync() -> *const () { > 0 as *const () > } > ```",HEART,2022-03-17T12:39:50Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/94723,MERGED,2022-03-08T02:54:42Z,2022-03-09T00:26:42Z,Add core::hint::must_use,dtolnay,ff54e34463c1af0025e29d41ebfbc1dfb4083e15,1,"Rollup merge of #94723 - dtolnay:mustuse r=Mark-Simulacrum Add core::hint::must_use The example code in this documentation is minimized from a real-world situation in the `anyhow` crate where this function would have been valuable. Having this provided by the standard library is especially useful for proc macros even more than for macro_rules. That's because proc macro crates aren't allowed to export anything other than macros so they couldn't make their own `must_use` function for their macro-generated code to call.
## Rendered documentation > An identity function that causes an `unused_must_use` warning to be triggered if the given value is not used (returned stored in a variable etc) by the caller. > > This is primarily intended for use in macro-generated code in which a [`#[must_use]` attribute][must_use] either on a type or a function would not be convenient. > > [must_use]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-must_use-attribute > > ### Example > > ```rust > #![feature(hint_must_use)] > > use core::fmt; > > pub struct Error(/* ... */); > > #[macro_export] > macro_rules! make_error { > ($($args:expr) *) => { > core::hint::must_use({ > let error = $crate::make_error(core::format_args!($($args) *)); > error > }) > }; > } > > // Implementation detail of make_error! macro. > #[doc(hidden)] > pub fn make_error(args: fmt::Arguments<'_>) -> Error { > Error(/* ... */) > } > > fn demo() -> Option { > if true { > // Oops meant to write `return Some(make_error!(""...""));` > Some(make_error!(""..."")); > } > None > } > ``` > > In the above example we'd like an `unused_must_use` lint to apply to the value created by `make_error!`. However neither `#[must_use]` on a struct nor `#[must_use]` on a function is appropriate here so the macro expands using `core::hint::must_use` instead. > > - We wouldn't want `#[must_use]` on the `struct Error` because that would make the following unproblematic code trigger a warning: > > ```rust > fn f(arg: &str) -> Result<() Error> > > #[test] > fn t() { > // Assert that `f` returns error if passed an empty string. > // A value of type `Error` is unused here but that's not a problem. > f("""").unwrap_err(); > } > ``` > > - Using `#[must_use]` on `fn make_error` can't help because the return value *is* used as the right-hand side of a `let` statement. The `let` statement looks useless but is in fact necessary for ensuring that temporaries within the `format_args` expansion are not kept alive past the creation of the `Error` as keeping them alive past that point can cause autotrait issues in async code: > > ```rust > async fn f() { > // Using `let` inside the make_error expansion causes temporaries like > // `unsync()` to drop at the semicolon of that `let` statement which > // is prior to the await point. They would otherwise stay around until > // the semicolon on *this* statement which is after the await point > // and the enclosing Future would not implement Send. > log(make_error!(""look: {:p}"" unsync())).await; > } > > async fn log(error: Error) {/* ... */} > > // Returns something without a Sync impl. > fn unsync() -> *const () { > 0 as *const () > } > ```",HEART,2022-03-20T19:17:11Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94731,MERGED,2022-03-08T08:11:34Z,2022-03-18T03:01:54Z,Suggest adding `{ .. }` around a const function call with arguments,TaKO8Ki,5eb3433ed5201c6180e6bee26c3156fea4b174f0,6,Rollup merge of #94731 - TaKO8Ki:const-generic-expr-recovery r=davidtwco oli-obk Suggest adding `{ .. }` around a const function call with arguments closes #91020,HEART,2022-03-08T17:14:50Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94731,MERGED,2022-03-08T08:11:34Z,2022-03-18T03:01:54Z,Suggest adding `{ .. }` around a const function call with arguments,TaKO8Ki,5eb3433ed5201c6180e6bee26c3156fea4b174f0,6,Rollup merge of #94731 - TaKO8Ki:const-generic-expr-recovery r=davidtwco oli-obk Suggest adding `{ .. }` around a const function call with arguments closes #91020,HEART,2022-03-18T06:51:45Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/94746,MERGED,2022-03-08T19:07:57Z,2022-03-10T14:58:47Z,diagnostics: use rustc_on_unimplemented to recommend `[].iter()`,notriddle,e7281d08de338fc091ce12f90b48d7b4de50a138,11,Rollup merge of #94746 - notriddle:notriddle/method-rustc-on-unimplemented r=davidtwco diagnostics: use rustc_on_unimplemented to recommend `[].iter()` To make this work the `#[rustc_on_unimplemented]` data needs to be used to report method resolution errors which is most of what this commit does. Fixes #94581,HEART,2022-03-09T02:08:23Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94746,MERGED,2022-03-08T19:07:57Z,2022-03-10T14:58:47Z,diagnostics: use rustc_on_unimplemented to recommend `[].iter()`,notriddle,e7281d08de338fc091ce12f90b48d7b4de50a138,11,Rollup merge of #94746 - notriddle:notriddle/method-rustc-on-unimplemented r=davidtwco diagnostics: use rustc_on_unimplemented to recommend `[].iter()` To make this work the `#[rustc_on_unimplemented]` data needs to be used to report method resolution errors which is most of what this commit does. Fixes #94581,HEART,2022-04-04T21:45:53Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/94763,MERGED,2022-03-09T09:20:29Z,2022-03-10T04:58:47Z,Add documentation about lifetimes to thread::scope.,m-ou-se,9e90f8d39bd1b50f0d497793b463840b43e340b4,1,Rollup merge of #94763 - m-ou-se:scoped-threads-lifetime-docs r=Mark-Simulacrum Add documentation about lifetimes to thread::scope. This resolves the last unresolved question of https://github.com/rust-lang/rust/issues/93203 This was brought up in https://github.com/rust-lang/rust/pull/94559#discussion_r820872694 r? `````@Mark-Simulacrum`````,ROCKET,2022-03-09T13:41:27Z,Phosphorus-M,NA https://github.com/rust-lang/rust/pull/94763,MERGED,2022-03-09T09:20:29Z,2022-03-10T04:58:47Z,Add documentation about lifetimes to thread::scope.,m-ou-se,9e90f8d39bd1b50f0d497793b463840b43e340b4,1,Rollup merge of #94763 - m-ou-se:scoped-threads-lifetime-docs r=Mark-Simulacrum Add documentation about lifetimes to thread::scope. This resolves the last unresolved question of https://github.com/rust-lang/rust/issues/93203 This was brought up in https://github.com/rust-lang/rust/pull/94559#discussion_r820872694 r? `````@Mark-Simulacrum`````,HEART,2022-03-09T13:41:31Z,Phosphorus-M,NA https://github.com/rust-lang/rust/pull/94775,MERGED,2022-03-09T17:12:06Z,2022-05-04T15:24:30Z,Fix constants not getting dropped if part of a diverging expression,oli-obk,364bf39e3179e148742466810d0cb9c8ec1c343a,8,Auto merge of #94775 - oli-obk:operand_order r=davidtwco Fix constants not getting dropped if part of a diverging expression fixes https://github.com/rust-lang/rust/issues/90762 cc `@RalfJung`,HEART,2022-03-09T17:30:08Z,RalfJung,NA https://github.com/rust-lang/rust/pull/94776,MERGED,2022-03-09T17:55:03Z,2022-03-11T16:37:58Z,Optimize ascii::escape_default,martingms,cdd6d39eccb687f20113893902eafd8ba81b4acf,1,Rollup merge of #94776 - martingms:optimize-escape-default r=nnethercote Optimize ascii::escape_default `ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data). After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters so that's what this PR implements The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!,HEART,2022-03-09T18:34:47Z,lqd,NA https://github.com/rust-lang/rust/pull/94776,MERGED,2022-03-09T17:55:03Z,2022-03-11T16:37:58Z,Optimize ascii::escape_default,martingms,cdd6d39eccb687f20113893902eafd8ba81b4acf,1,Rollup merge of #94776 - martingms:optimize-escape-default r=nnethercote Optimize ascii::escape_default `ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data). After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters so that's what this PR implements The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!,HEART,2022-03-09T18:50:45Z,torvald,NA https://github.com/rust-lang/rust/pull/94776,MERGED,2022-03-09T17:55:03Z,2022-03-11T16:37:58Z,Optimize ascii::escape_default,martingms,cdd6d39eccb687f20113893902eafd8ba81b4acf,1,Rollup merge of #94776 - martingms:optimize-escape-default r=nnethercote Optimize ascii::escape_default `ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data). After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters so that's what this PR implements The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!,HEART,2022-03-09T19:23:57Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94776,MERGED,2022-03-09T17:55:03Z,2022-03-11T16:37:58Z,Optimize ascii::escape_default,martingms,cdd6d39eccb687f20113893902eafd8ba81b4acf,1,Rollup merge of #94776 - martingms:optimize-escape-default r=nnethercote Optimize ascii::escape_default `ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data). After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters so that's what this PR implements The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!,HEART,2022-03-09T20:31:20Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/94776,MERGED,2022-03-09T17:55:03Z,2022-03-11T16:37:58Z,Optimize ascii::escape_default,martingms,cdd6d39eccb687f20113893902eafd8ba81b4acf,1,Rollup merge of #94776 - martingms:optimize-escape-default r=nnethercote Optimize ascii::escape_default `ascii::escape_default` showed up as a hot function when compiling `deunicode-1.3.1` in `@nnethercote's` [analysis](https://hackmd.io/mxdn4U58Su-UQXwzOHpHag) of `@lqd's` [rustc-benchmarking-data](https://github.com/lqd/rustc-benchmarking-data). After taking a look at the generated assembly it looked like a LUT-based approach could be faster for `hexify()`-ing ascii characters so that's what this PR implements The patch looks like it provides about a 1-2% improvement in instructions for that particular crate. This should definitely be verified with a perf run as I'm still getting used to the `rustc-perf` tooling and might easily have made an error!,HEART,2022-03-10T08:54:48Z,erathe,NA https://github.com/rust-lang/rust/pull/94788,MERGED,2022-03-09T22:47:15Z,2022-03-10T14:58:47Z,Account for suggestions for complete removal of lines,estebank,6bbaca7d030b2c778a7a7b9762f3afb2a2408ff5,3,Rollup merge of #94788 - estebank:removal-suggestion r=petrochenkov Account for suggestions for complete removal of lines Fix #94192.,HEART,2022-03-09T22:55:58Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94796,MERGED,2022-03-10T04:41:33Z,2022-03-10T20:51:54Z,Allow `cargo run` instead of `cargo run -p bootstrap`,jyn514,fa685a54995accf77785e7df5f89b05a9d4c473e,1,Rollup merge of #94796 - jyn514:cargo-run-bootstrap r=Mark-Simulacrum Allow `cargo run` instead of `cargo run -p bootstrap` This was part of `@Mark-Simulacrum` 's original PR in https://github.com/rust-lang/rust/commit/ecb424f12992a4aebace8a153d5efea040327a01 but I missed it when writing #92260. This also has the side effect of allowing `cargo build --bins` instead of `cargo build -p bootstrap --bins`. I'm not sure when you would want to run cargo build/check/test without going through bootstrap but this still allows you to do so as long as you pass `-p` for all the crates you want to build.,HOORAY,2022-03-10T13:04:03Z,mati865,NA https://github.com/rust-lang/rust/pull/94796,MERGED,2022-03-10T04:41:33Z,2022-03-10T20:51:54Z,Allow `cargo run` instead of `cargo run -p bootstrap`,jyn514,fa685a54995accf77785e7df5f89b05a9d4c473e,1,Rollup merge of #94796 - jyn514:cargo-run-bootstrap r=Mark-Simulacrum Allow `cargo run` instead of `cargo run -p bootstrap` This was part of `@Mark-Simulacrum` 's original PR in https://github.com/rust-lang/rust/commit/ecb424f12992a4aebace8a153d5efea040327a01 but I missed it when writing #92260. This also has the side effect of allowing `cargo build --bins` instead of `cargo build -p bootstrap --bins`. I'm not sure when you would want to run cargo build/check/test without going through bootstrap but this still allows you to do so as long as you pass `-p` for all the crates you want to build.,HOORAY,2022-03-10T13:11:53Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/94817,MERGED,2022-03-10T19:36:08Z,2022-04-04T22:32:45Z,Release notes for 1.60.0,cuviper,98168925f6570a8d0292abd493cf20bde89c7663,1,Rollup merge of #94817 - cuviper:relnotes-1.60.0 r=pietroalbini m-ou-se Release notes for 1.60.0,HEART,2022-03-31T17:05:10Z,pthariensflame,alexanderaltman@me.com https://github.com/rust-lang/rust/pull/94827,MERGED,2022-03-10T23:31:37Z,2022-03-12T00:11:14Z,CTFE/Miri: detect out-of-bounds pointers in offset_from,RalfJung,9e70b1a033ec27d618b8e9ffa9412837b7545276,6,Rollup merge of #94827 - RalfJung:offset-from-ub r=oli-obk CTFE/Miri: detect out-of-bounds pointers in offset_from Also I became uneasy with aggressively doing `try_to_int` here -- this will always succeed on Miri leading to the wrong codepath being taken. We should rather try to convert them both to pointers and use the integer path as a fallback so that's what I implemented now. Hiding whitespaces helps with the diff. Fixes https://github.com/rust-lang/miri/issues/1950 r? ``@oli-obk``,HEART,2022-03-11T22:57:16Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/94833,MERGED,2022-03-11T02:28:53Z,2022-03-12T11:57:59Z,[2/2] Implement macro meta-variable expression,c410-f3r,8c87132103e350821bb8f8abbd90f3d6feebecd1,8,Rollup merge of #94833 - c410-f3r:meta-take-2 r=petrochenkov [2/2] Implement macro meta-variable expression Final part of https://github.com/rust-lang/rust/pull/93545#issuecomment-1050963295 r? `@petrochenkov`,HOORAY,2022-03-11T15:52:05Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/94844,MERGED,2022-03-11T11:43:02Z,2022-03-13T23:06:13Z,Reduce rustbuild bloat caused by serde_derive,bjorn3,d14ba9580697aec22b65041e19666624e76a44a2,1,Rollup merge of #94844 - bjorn3:rustbuild_cleanup r=Mark-Simulacrum Reduce rustbuild bloat caused by serde_derive This reduces the size of the `.text` section from 10.1MiB (6.2MiB for just rustbuild code) to 9.3MiB (5.3MiB for just rustbuild code). This also reduces compile time from ~6.1s for incr recompilation to ~5.6s. r? `@Mark-Simulacrum`,HEART,2022-03-11T13:53:34Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/94844,MERGED,2022-03-11T11:43:02Z,2022-03-13T23:06:13Z,Reduce rustbuild bloat caused by serde_derive,bjorn3,d14ba9580697aec22b65041e19666624e76a44a2,1,Rollup merge of #94844 - bjorn3:rustbuild_cleanup r=Mark-Simulacrum Reduce rustbuild bloat caused by serde_derive This reduces the size of the `.text` section from 10.1MiB (6.2MiB for just rustbuild code) to 9.3MiB (5.3MiB for just rustbuild code). This also reduces compile time from ~6.1s for incr recompilation to ~5.6s. r? `@Mark-Simulacrum`,HEART,2022-03-11T19:19:27Z,lqd,NA https://github.com/rust-lang/rust/pull/94844,MERGED,2022-03-11T11:43:02Z,2022-03-13T23:06:13Z,Reduce rustbuild bloat caused by serde_derive,bjorn3,d14ba9580697aec22b65041e19666624e76a44a2,1,Rollup merge of #94844 - bjorn3:rustbuild_cleanup r=Mark-Simulacrum Reduce rustbuild bloat caused by serde_derive This reduces the size of the `.text` section from 10.1MiB (6.2MiB for just rustbuild code) to 9.3MiB (5.3MiB for just rustbuild code). This also reduces compile time from ~6.1s for incr recompilation to ~5.6s. r? `@Mark-Simulacrum`,HEART,2022-03-13T22:13:35Z,est31,NA https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-11T17:48:29Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-11T19:06:05Z,cjgillot,NA https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-11T19:19:20Z,lqd,NA https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HEART,2022-03-11T19:46:26Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-12T08:33:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-12T21:21:22Z,camelid,NA https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HEART,2022-03-12T21:21:23Z,camelid,NA https://github.com/rust-lang/rust/pull/94857,OPEN,2022-03-11T17:34:47Z,NA,[WIP] rustdoc: Stop cloning name resolver,petrochenkov,NA,NA,NA,HOORAY,2022-03-16T16:02:04Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/94868,MERGED,2022-03-11T23:36:04Z,2022-03-16T06:19:34Z,Format core and std macro rules removing needless surrounding blocks,dtolnay,f986c7434ae958567721dfcff336c51cc2bf663d,7,"Rollup merge of #94868 - dtolnay:noblock r=Dylan-DPC Format core and std macro rules removing needless surrounding blocks Many of the asserting and printing macros in `core` and `std` are written with prehistoric-looking formatting like this: https://github.com/rust-lang/rust/blob/335ffbfa547df94ac236f5c56130cecf99c8d82b/library/std/src/macros.rs#L96-L101 In modern Rust style this would conventionally be written as follows instead always using braces and a trailing semicolon on the macro arms: https://github.com/rust-lang/rust/blob/af53809c874e0afb7be966df4d3cfcaa05277c53/library/std/src/macros.rs#L98-L105 Getting rid of the unneeded braces inside the expansion reduces extraneous indentation in macro-expanded code. For example: ```rust println!(""repro {}"" true); ``` ```rust // before: { ::std::io::_print( ::core::fmt::Arguments::new_v1( &[""repro "" ""\n""] &[::core::fmt::ArgumentV1::new_display(&true)] ) ); }; ``` ```rust // after: ::std::io::_print( ::core::fmt::Arguments::new_v1( &[""repro "" ""\n""] &[::core::fmt::ArgumentV1::new_display(&true)] ) ); ```",HEART,2022-03-14T19:41:41Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94868,MERGED,2022-03-11T23:36:04Z,2022-03-16T06:19:34Z,Format core and std macro rules removing needless surrounding blocks,dtolnay,f986c7434ae958567721dfcff336c51cc2bf663d,7,"Rollup merge of #94868 - dtolnay:noblock r=Dylan-DPC Format core and std macro rules removing needless surrounding blocks Many of the asserting and printing macros in `core` and `std` are written with prehistoric-looking formatting like this: https://github.com/rust-lang/rust/blob/335ffbfa547df94ac236f5c56130cecf99c8d82b/library/std/src/macros.rs#L96-L101 In modern Rust style this would conventionally be written as follows instead always using braces and a trailing semicolon on the macro arms: https://github.com/rust-lang/rust/blob/af53809c874e0afb7be966df4d3cfcaa05277c53/library/std/src/macros.rs#L98-L105 Getting rid of the unneeded braces inside the expansion reduces extraneous indentation in macro-expanded code. For example: ```rust println!(""repro {}"" true); ``` ```rust // before: { ::std::io::_print( ::core::fmt::Arguments::new_v1( &[""repro "" ""\n""] &[::core::fmt::ArgumentV1::new_display(&true)] ) ); }; ``` ```rust // after: ::std::io::_print( ::core::fmt::Arguments::new_v1( &[""repro "" ""\n""] &[::core::fmt::ArgumentV1::new_display(&true)] ) ); ```",HEART,2022-07-07T15:48:56Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/94873,MERGED,2022-03-12T01:08:57Z,2022-03-12T16:37:05Z,Fix ICE when using Box again,DrMeepster,ed2a69c4a9f3e5535461484af6266681fd7d90d4,2,Auto merge of #94873 - DrMeepster:box_alloc_ice3 r=oli-obk Fix ICE when using Box again Sequel to #94043 fixes #94835.,LAUGH,2022-03-12T02:29:37Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/94873,MERGED,2022-03-12T01:08:57Z,2022-03-12T16:37:05Z,Fix ICE when using Box again,DrMeepster,ed2a69c4a9f3e5535461484af6266681fd7d90d4,2,Auto merge of #94873 - DrMeepster:box_alloc_ice3 r=oli-obk Fix ICE when using Box again Sequel to #94043 fixes #94835.,THUMBS_UP,2022-03-12T18:05:52Z,exrook,NA https://github.com/rust-lang/rust/pull/94890,OPEN,2022-03-12T18:37:43Z,NA,Support parsing IP addresses from a byte string,marmeladema,NA,NA,NA,THUMBS_DOWN,2022-03-12T19:06:58Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/94897,MERGED,2022-03-12T22:29:09Z,2022-03-13T13:30:16Z,Queryify `is_doc_hidden`,camelid,4800c7816ee1937d028407066d229f74b4673c92,3,Auto merge of #94897 - camelid:query-doc-hidden r=cjgillot Queryify `is_doc_hidden` It came up hot on some profiling of rustdoc I did so hopefully turning it into a query will help.,EYES,2022-03-13T05:13:30Z,pierwill,NA https://github.com/rust-lang/rust/pull/94907,MERGED,2022-03-13T14:11:23Z,2022-03-13T23:06:13Z,Omit stdarch test crates from the rust-src component,bjorn3,c7030d3eb36ffe024e795eb9e6eeba0ebcbb1cd4,1,Rollup merge of #94907 - bjorn3:smaller_rust_src_component r=Mark-Simulacrum Omit stdarch test crates from the rust-src component These crates aren't necessary for building the standard library. This saves 30MB of disk space. Fixes #94906,HEART,2022-07-05T19:47:30Z,cuviper,cuviper@gmail.com https://github.com/rust-lang/rust/pull/94911,MERGED,2022-03-13T16:14:30Z,2022-04-02T20:58:34Z,Make GATs object safe under generic_associated_types_extended feature,jackh726,8f96ef4bb56f5d905ed89ed569ef97f50731c977,19,Auto merge of #94911 - jackh726:gats_extended_2 r=compiler-errors Make GATs object safe under generic_associated_types_extended feature Based on #94869 Let's say we have ```rust trait StreamingIterator { type Item<'a> where Self: 'a; } ``` And `dyn for<'a> StreamingIterator = &'a i32>`. If we ask `(dyn for<'a> StreamingIterator = &'a i32>): StreamingIterator` then we have to prove that `for<'x> (&'x i32): Sized`. So we generate *new* bound vars to subst for the GAT generics. Importantly this doesn't fully verify that these are usable and sound. r? `@nikomatsakis`,HOORAY,2022-03-15T17:17:40Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T10:44:50Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:00:16Z,Urgau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:03:11Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:04:07Z,laurmaedje,laurmaedje@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:24:27Z,hasali19,hasan@hasali.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:29:45Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:31:42Z,Kijewski,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:32:47Z,MDM23,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T11:38:28Z,rodrigocfd,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T11:47:01Z,Folyd,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:08:04Z,Eugeny,inbox@null.page https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:08:05Z,Eugeny,inbox@null.page https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:18:27Z,TENX-S,coldswind@pm.me https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:32:01Z,KaiserKarel,k.l.kubat@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:32:02Z,KaiserKarel,k.l.kubat@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:37:16Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:37:17Z,Nokel81,sebastian@malton.name https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:40:37Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:40:38Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:43:47Z,johannesvollmer,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T12:45:05Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T12:56:17Z,rowenslee,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:00:04Z,Tak-Iwamoto,takiwamotoxxx@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:07:51Z,weihanglo,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:14:06Z,zethra,sasha@noraa.gay https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:14:08Z,zethra,sasha@noraa.gay https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:20:01Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:20:03Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:22:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:22:44Z,GrayJack,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:22:52Z,FlareFlo,mail@flareflo.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:22:52Z,FlareFlo,mail@flareflo.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:26:13Z,fdoyon,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:28:24Z,remi-dupre,remi@dupre.io https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:43:55Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:47:25Z,Gadiguibou,lacroixgabriel@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T13:47:26Z,Gadiguibou,lacroixgabriel@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T13:50:15Z,Follpvosten,wolfi@karpador.xyz https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:03:04Z,lynzrand,i@rynco.me https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:03:05Z,lynzrand,i@rynco.me https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:04:58Z,stanislav-tkach,stanislav.tkach@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:06:36Z,TheOnlyArtz,callcraft456@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:09:25Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:09:25Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:21:11Z,f32by,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:22:31Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:22:31Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-03-14T14:22:34Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:24:22Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:27:16Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:27:58Z,audkar,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:28:01Z,audkar,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:41:40Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T14:41:42Z,Lesiuk,lesiuk@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T14:53:31Z,xgroleau,xavgroleau@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T15:04:26Z,Shatur,genaloner@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T15:04:27Z,Shatur,genaloner@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T15:11:34Z,lostpebble,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T15:52:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T16:04:06Z,JoJoJet,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T16:15:49Z,jafioti,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T16:26:46Z,jaxrtech,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T16:26:48Z,jaxrtech,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T16:40:05Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,EYES,2022-03-14T16:40:08Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T16:52:02Z,Pietro222222,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T16:52:03Z,Pietro222222,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-03-14T16:52:03Z,Pietro222222,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,EYES,2022-03-14T16:52:03Z,Pietro222222,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T17:24:39Z,mayfieldiv,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T17:24:44Z,mayfieldiv,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-14T17:38:08Z,kaimast,kaimast@cs.wisc.edu https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-03-14T17:47:13Z,tbarusseau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,EYES,2022-03-14T17:47:14Z,tbarusseau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T17:47:15Z,tbarusseau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T17:47:15Z,tbarusseau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-14T17:47:17Z,tbarusseau,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T18:01:01Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T18:11:04Z,jackh726,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T18:24:04Z,michaelkirk,michael.code@endoftheworl.de https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T18:35:35Z,fox0430,Shuu.N@protonmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T18:41:29Z,Sh3Rm4n,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T19:04:56Z,sphw,me@saschawise.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T19:17:52Z,sezna,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T19:17:53Z,sezna,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-03-14T19:23:56Z,ljedrz,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T19:43:14Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T19:43:15Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,CONFUSED,2022-03-14T20:29:54Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T20:50:17Z,daniel-buse,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T21:01:43Z,flosse,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T21:04:58Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-14T21:04:59Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T21:17:49Z,geraldwuhoo,gerald@geraldwu.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-14T21:31:11Z,est31,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T01:19:33Z,shangling3,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T01:25:02Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T01:48:11Z,Eucladia,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T02:10:06Z,lukechu10,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T04:08:53Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T04:08:54Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T04:37:16Z,occar421,occar@hotmail.co.jp https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T06:40:43Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T07:31:10Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T07:31:12Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T07:52:10Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T08:09:50Z,akshay-deepsource,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T11:37:43Z,NateLing,magic.ling@live.cn https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T12:06:29Z,Keelar,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-15T12:37:59Z,dandxy89,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T13:07:44Z,luaneko,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-15T14:37:20Z,kkocdko,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-15T14:37:26Z,kkocdko,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T14:37:29Z,kkocdko,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-15T16:18:30Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-17T10:38:27Z,Hocuri,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-03-18T16:11:36Z,plazmoid,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-20T09:09:54Z,sudormrfbin,gokulps15@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-03-24T21:46:44Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-03-24T21:46:45Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,EYES,2022-03-24T21:46:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-11T09:12:46Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-11T09:12:47Z,cherryblossom000,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-12T17:39:48Z,Milo123459,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-04-12T18:09:47Z,estebank,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-13T01:36:14Z,jeremychone,jeremy.chone@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-17T18:40:25Z,cynecx,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-21T12:09:55Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-04-21T12:09:58Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-21T17:18:01Z,lolgeny,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-21T17:18:02Z,lolgeny,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-21T20:16:13Z,LucFauvel,lfauvel@devolutions.net https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-04-21T20:16:14Z,LucFauvel,lfauvel@devolutions.net https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-22T00:08:44Z,as-com,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-22T02:05:59Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-22T10:48:32Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-24T05:04:44Z,xanonid,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-26T12:26:12Z,EriKWDev,erigr@axis.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-26T19:30:02Z,numToStr,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-26T19:35:13Z,AurelienFT,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-26T23:44:46Z,SE2Dev,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-04-27T04:39:58Z,dbstratta,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-04-27T04:39:59Z,dbstratta,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-04-27T04:40:02Z,dbstratta,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-04-27T11:40:37Z,JunichiSugiura,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-05-01T16:05:05Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-05-01T16:05:06Z,Virgiel,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-05T05:04:24Z,cjwcommuny,cjwcommuny@outlook.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-05-10T17:16:57Z,ian-h-chamberlain,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-14T18:47:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-05-14T18:47:55Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-05-14T18:47:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-17T13:34:41Z,msrd0,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-05-17T13:34:42Z,msrd0,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-05-17T13:34:44Z,msrd0,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,ROCKET,2022-05-17T13:34:44Z,msrd0,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-19T07:28:42Z,Tyestor,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-20T10:02:02Z,Debonex,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-05-27T00:19:45Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-05-30T18:33:51Z,assapir,me@ass.af https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-30T18:33:56Z,assapir,me@ass.af https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-06-02T00:38:02Z,JulienGrv,grave.jul@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-06-02T00:38:04Z,JulienGrv,grave.jul@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-06-09T00:38:46Z,kyoto7250,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-06-09T00:38:47Z,kyoto7250,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-06-10T07:34:12Z,XiNiHa,me@xiniha.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-06-10T07:34:12Z,XiNiHa,me@xiniha.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-06-10T07:34:15Z,XiNiHa,me@xiniha.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-06-16T17:31:21Z,nikosmar,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-06-28T02:25:25Z,jon-chuang,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-06-28T02:25:26Z,jon-chuang,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-06-28T17:11:12Z,Rageking8,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-06-28T21:02:40Z,MinnDevelopment,business@minn.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-01T14:48:05Z,federico123579,federico123579@gmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-01T16:01:42Z,tronta,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-04T19:28:19Z,Logarithmus,freesoftware@logarithmus.dev https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-06T12:01:15Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HEART,2022-07-06T12:01:16Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-06T20:48:21Z,bengsparks,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-07T04:22:30Z,Hnasar,NA https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,THUMBS_UP,2022-07-11T18:22:13Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,HOORAY,2022-07-11T18:22:14Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,CONFUSED,2022-07-11T18:22:15Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/94927,OPEN,2022-03-14T10:35:54Z,NA,Stabilize `let_chains` in Rust 1.64,c410-f3r,NA,NA,NA,EYES,2022-07-11T18:22:16Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/94934,MERGED,2022-03-14T15:54:57Z,2022-03-24T22:52:38Z,Separate const prop lints from optimizations,Lireer,63b8f01bb5ca277e7df8d7efe094ed4244c1790c,30,Auto merge of #94934 - Lireer:const-prop-lint r=oli-obk Separate const prop lints from optimizations r? `@oli-obk` Separates lints and optimizations during const prop by moving the lints into their own file and checking them during post borrowck cleanup. Thanks to `@oli-obk` for mentoring me.,HOORAY,2022-03-15T02:08:55Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/94939,MERGED,2022-03-14T18:49:53Z,2022-03-28T00:01:02Z,diagnostics: suggest missing comma in bad FRU syntax,notriddle,726cd737d625a1420e3eed5f00879f6f136f1c83,4,Rollup merge of #94939 - notriddle:notriddle/fru-comma-suggestion r=cjgillot diagnostics: suggest missing comma in bad FRU syntax Fixes #51103,HEART,2022-05-11T19:53:11Z,estebank,NA https://github.com/rust-lang/rust/pull/94946,CLOSED,2022-03-15T00:51:02Z,2022-05-08T02:14:55Z,Stabilize const versions of ptr::slice_from_raw_parts and slice::from_raw_parts.,tobz,NA,NA,NA,HOORAY,2022-04-29T01:09:54Z,kupiakos,NA https://github.com/rust-lang/rust/pull/94951,MERGED,2022-03-15T04:32:00Z,2022-03-16T06:19:34Z,Extend the irrefutable_let_patterns lint to let chains,est31,2bd5c44e9395d2ea185d58f651097cd9d0b43afc,5,Rollup merge of #94951 - est31:irrefutable_let_chain_patterns r=estebank Extend the irrefutable_let_patterns lint to let chains Implements the suggestion from https://github.com/rust-lang/rust/pull/94927#issuecomment-1067078300 We only look for complete suffixes or prefixes of irrefutable let patterns so that an irrefutable let pattern in a chain surrounded by refutable ones is not linted as it is an useful pattern that has no low-cost replacement (unlike suffixes or prefixes which can just be copied outside of the `if`: either into the `if`'s block or the block surrounding the `if`). If all patterns in a let chain are irrefutable we lint as well. Depends on #94958 ~~so I included it into the PR for now~~ *which has been merged since*. r? `@estebank` cc `@joshtriplett` `@c410-f3r`,THUMBS_UP,2022-03-15T15:10:27Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/94951,MERGED,2022-03-15T04:32:00Z,2022-03-16T06:19:34Z,Extend the irrefutable_let_patterns lint to let chains,est31,2bd5c44e9395d2ea185d58f651097cd9d0b43afc,5,Rollup merge of #94951 - est31:irrefutable_let_chain_patterns r=estebank Extend the irrefutable_let_patterns lint to let chains Implements the suggestion from https://github.com/rust-lang/rust/pull/94927#issuecomment-1067078300 We only look for complete suffixes or prefixes of irrefutable let patterns so that an irrefutable let pattern in a chain surrounded by refutable ones is not linted as it is an useful pattern that has no low-cost replacement (unlike suffixes or prefixes which can just be copied outside of the `if`: either into the `if`'s block or the block surrounding the `if`). If all patterns in a let chain are irrefutable we lint as well. Depends on #94958 ~~so I included it into the PR for now~~ *which has been merged since*. r? `@estebank` cc `@joshtriplett` `@c410-f3r`,THUMBS_UP,2022-03-15T21:28:05Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94954,MERGED,2022-03-15T09:33:06Z,2022-05-25T16:39:41Z,Extend ptr::null and null_mut to all thin (including extern) types,SimonSapin,9fed13030c2a2ebd79bfb1fd8be4f768cbe8c9d9,3,Auto merge of #94954 - SimonSapin:null-thin3 r=yaahc Extend ptr::null and null_mut to all thin (including extern) types Fixes https://github.com/rust-lang/rust/issues/93959 This change was accepted in https://rust-lang.github.io/rfcs/2580-ptr-meta.html Note that this changes the signature of **stable** functions. The change should be backward-compatible but it is **insta-stable** since it cannot (easily at all?) be made available only through a `#![feature(…)]` opt-in. The RFC also proposed the same change for `NonNull::dangling` which makes sense it terms of its signature but not in terms of its implementation. `dangling` uses `align_of()` as an address. But what `align_of()` should be for extern types or whether it should be allowed at all remains an open question. This commit depends on https://github.com/rust-lang/rust/pull/93977 which is not yet part of the bootstrap compiler. So `#[cfg]` is used to only apply the change in stage 1+. As far a I know bounds cannot be made conditional with `#[cfg]` so the entire functions are duplicated. This is unfortunate but temporary. Since this duplication makes it less obvious in the diff the new definitions differ in: * More permissive bounds (`Thin` instead of implied `Sized`) * Different implementation * Having `rustc_allow_const_fn_unstable(const_fn_trait_bound)` * Having `rustc_allow_const_fn_unstable(ptr_metadata)`,THUMBS_UP,2022-03-16T13:48:56Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/94954,MERGED,2022-03-15T09:33:06Z,2022-05-25T16:39:41Z,Extend ptr::null and null_mut to all thin (including extern) types,SimonSapin,9fed13030c2a2ebd79bfb1fd8be4f768cbe8c9d9,3,Auto merge of #94954 - SimonSapin:null-thin3 r=yaahc Extend ptr::null and null_mut to all thin (including extern) types Fixes https://github.com/rust-lang/rust/issues/93959 This change was accepted in https://rust-lang.github.io/rfcs/2580-ptr-meta.html Note that this changes the signature of **stable** functions. The change should be backward-compatible but it is **insta-stable** since it cannot (easily at all?) be made available only through a `#![feature(…)]` opt-in. The RFC also proposed the same change for `NonNull::dangling` which makes sense it terms of its signature but not in terms of its implementation. `dangling` uses `align_of()` as an address. But what `align_of()` should be for extern types or whether it should be allowed at all remains an open question. This commit depends on https://github.com/rust-lang/rust/pull/93977 which is not yet part of the bootstrap compiler. So `#[cfg]` is used to only apply the change in stage 1+. As far a I know bounds cannot be made conditional with `#[cfg]` so the entire functions are duplicated. This is unfortunate but temporary. Since this duplication makes it less obvious in the diff the new definitions differ in: * More permissive bounds (`Thin` instead of implied `Sized`) * Different implementation * Having `rustc_allow_const_fn_unstable(const_fn_trait_bound)` * Having `rustc_allow_const_fn_unstable(ptr_metadata)`,THUMBS_UP,2022-03-28T22:36:48Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/94963,MERGED,2022-03-15T16:04:40Z,2022-03-30T15:10:01Z,allow arbitrary inherent impls for builtin types in core,lcnr,3e7514670db841a7f0d7656f3b13b1c8b2c11599,66,Auto merge of #94963 - lcnr:inherent-impls-std r=oli-obk m-ou-se allow arbitrary inherent impls for builtin types in core Part of https://github.com/rust-lang/compiler-team/issues/487. Slightly adjusted after some talks with `@m-ou-se` about the requirements of `t-libs-api`. This adds a crate attribute `#![rustc_coherence_is_core]` which allows arbitrary impls for builtin types in core. For other library crates impls for builtin types should be avoided if possible. We do have to allow the existing stable impls however. To prevent us from accidentally adding more of these in the future there is a second attribute `#[rustc_allow_incoherent_impl]` which has to be added to **all impl items**. This only supports impls for builtin types but can easily be extended to additional types in a future PR. This implementation does not check for overlaps in these impls. Perfectly checking that requires us to check the coherence of these incoherent impls in every crate as two distinct dependencies may add overlapping methods. It should be easy enough to detect if it goes wrong and the attribute is only intended for use inside of std. The first two commits are mostly unrelated cleanups.,HOORAY,2022-04-03T21:28:39Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/94974,MERGED,2022-03-15T20:01:54Z,2022-03-16T06:19:34Z,Ensure that `let_else` does not interact with `let_chains`,c410-f3r,aaf2255379c22f93e53c5fad14453ac7a791ae9e,2,Rollup merge of #94974 - c410-f3r:let-chain-dashufwrqwemkf-let-else r=joshtriplett Ensure that `let_else` does not interact with `let_chains` As requested on https://github.com/rust-lang/rust/pull/94927. cc `@joshtriplett` `@estebank`,THUMBS_UP,2022-03-15T21:27:14Z,estebank,NA https://github.com/rust-lang/rust/pull/94984,MERGED,2022-03-16T00:29:22Z,2022-03-19T05:04:05Z,add `CStr` method that accepts any slice containing a nul-terminated string,ericseppanen,30b4182fa7ff8718335771b80a7687acb86f498a,2,Rollup merge of #94984 - ericseppanen:cstr_from_bytes r=Mark-Simulacrum add `CStr` method that accepts any slice containing a nul-terminated string I haven't created an issue (tracking or otherwise) for this yet; apologies if my approach isn't correct. This is my first code contribution. This change adds a member fn that converts a slice into a `CStr`; it is intended to be safer than `from_ptr` (which is unsafe and may read out of bounds) and more useful than `from_bytes_with_nul` (which requires that the caller already know where the nul byte is). The reason I find this useful is for situations like this: ```rust let mut buffer = [0u8; 32]; unsafe { some_c_function(buffer.as_mut_ptr() buffer.len()); } let result = CStr::from_bytes_with_nul(&buffer).unwrap(); ``` This code above returns an error with `kind = InteriorNul` because `from_bytes_with_nul` expects that the caller has passed in a slice with the NUL byte at the end of the slice. But if I just got back a nul-terminated string from some FFI function I probably don't know where the NUL byte is. I would wish for a `CStr` constructor with the following properties: - Accept `&[u8]` as input - Scan for the first NUL byte and return the `CStr` that spans the correct sub-slice (see [future note below](https://github.com/rust-lang/rust/pull/94984#issuecomment-1070754281)). - Return an error if no NUL byte is found within the input slice I asked on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/CStr.20from.20.26.5Bu8.5D.20without.20knowing.20the.20NUL.20location.3F) whether this sounded like a good idea and got a couple of positive-sounding responses from ``@joshtriplett`` and ``@AzureMarker.`` This is my first draft so feedback is welcome. A few issues that definitely need feedback: 1. Naming. ``@joshtriplett`` called this `from_bytes_with_internal_nul` on Zulip but after staring at all of the available methods I believe that this function is probably what end users want (rather than the existing fn `from_bytes_with_nul`). Giving it a simpler name (**`from_bytes`**) implies that this should be their first choice. 2. Should I add a similar method on `CString` that accepts `Vec`? I'd assume the answer is probably yes but I figured I'd try to get early feedback before making this change bigger. 3. What should the error type look like? I made a unit struct since `CStr::from_bytes` can only fail in one obvious way but if I need to do this for `CString` as well then that one may want to return `FromVecWithNulError`. And maybe that should dictate the shape of the `CStr` error type also? Also cc ``@poliorcetics`` who wrote #73139 containing similar fns.,THUMBS_UP,2022-03-16T20:03:19Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/94991,MERGED,2022-03-16T04:59:48Z,2022-03-19T19:41:13Z,Make Weak::new const,CAD97,6a730246617d7c40ed8fe71e50654cbef3d379c2,2,Rollup merge of #94991 - CAD97:const-weak-new r=dtolnay Make Weak::new const Simple enough. This is const creation of an allocating container but no actual allocation is done because it's defined to.,THUMBS_UP,2022-03-17T03:22:00Z,mbartlett21,NA https://github.com/rust-lang/rust/pull/94996,OPEN,2022-03-16T09:36:50Z,NA,Suggest using an appropriate keyword for `struct` and `enum`,TaKO8Ki,NA,NA,NA,THUMBS_UP,2022-03-22T01:31:16Z,estebank,NA https://github.com/rust-lang/rust/pull/95000,MERGED,2022-03-16T10:51:21Z,2022-03-18T03:01:54Z,Fixed wrong type name in comment,fee1-dead,4493826d07bf38cca058b4d9e75bce14ceeeaab9,0,Rollup merge of #95000 - fee1-dead:fee1-dead-patch-1 r=Mark-Simulacrum Fixed wrong type name in comment 95kth issue/pr!,LAUGH,2022-03-16T19:01:49Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95008,MERGED,2022-03-16T13:48:10Z,2022-04-12T00:18:53Z,[`let_chains`] Forbid `let` inside parentheses,c410-f3r,2ad701e45036fb2ccab8d4b4e23f9a3325e12817,6,"Rollup merge of #95008 - c410-f3r:let-chains-paren r=wesleywiser [`let_chains`] Forbid `let` inside parentheses Parenthesizes are mostly a no-op in let chains in other words they are mostly ignored. ```rust let opt = Some(Some(1i32)); if (let Some(a) = opt && (let Some(b) = a)) && b == 1 { println!(""`b` is declared inside but used outside""); } ``` As seen above such behavior can lead to confusion. A proper fix or nested encapsulation would probably require research time and a modified MIR graph so in this PR I simply denied any `let` inside parentheses. Non-let stuff are still allowed. ```rust fn main() { let fun = || true; if let true = (true && fun()) && (true) { println!(""Allowed""); } } ``` It is worth noting that `let ...` is not an expression and the RFC did not mention this specific situation. cc `@matthewjasper`",THUMBS_UP,2022-03-16T23:26:24Z,est31,NA https://github.com/rust-lang/rust/pull/95016,MERGED,2022-03-16T16:34:38Z,2022-03-28T05:09:52Z,Docs: make Vec::from_raw_parts documentation less strict,janpaul123,d88c03c0f1082d01294ef8cf5d14194d5d1284fa,1,Rollup merge of #95016 - janpaul123:patch-1 r=dtolnay Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict since we don't require `T` to have the same size just `size_of::() * capacity` to be the same since that is what results in `Layout::size` being the same in `dealloc` which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts` which I think is useful advise that could also be mentioned in the docs so I added that too. Let me know what you think! :),HEART,2022-03-17T09:47:00Z,RustyYato,NA https://github.com/rust-lang/rust/pull/95016,MERGED,2022-03-16T16:34:38Z,2022-03-28T05:09:52Z,Docs: make Vec::from_raw_parts documentation less strict,janpaul123,d88c03c0f1082d01294ef8cf5d14194d5d1284fa,1,Rollup merge of #95016 - janpaul123:patch-1 r=dtolnay Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict since we don't require `T` to have the same size just `size_of::() * capacity` to be the same since that is what results in `Layout::size` being the same in `dealloc` which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts` which I think is useful advise that could also be mentioned in the docs so I added that too. Let me know what you think! :),HEART,2022-03-18T23:21:42Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/95016,MERGED,2022-03-16T16:34:38Z,2022-03-28T05:09:52Z,Docs: make Vec::from_raw_parts documentation less strict,janpaul123,d88c03c0f1082d01294ef8cf5d14194d5d1284fa,1,Rollup merge of #95016 - janpaul123:patch-1 r=dtolnay Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict since we don't require `T` to have the same size just `size_of::() * capacity` to be the same since that is what results in `Layout::size` being the same in `dealloc` which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts` which I think is useful advise that could also be mentioned in the docs so I added that too. Let me know what you think! :),HEART,2022-03-19T12:30:16Z,taiki-e,NA https://github.com/rust-lang/rust/pull/95016,MERGED,2022-03-16T16:34:38Z,2022-03-28T05:09:52Z,Docs: make Vec::from_raw_parts documentation less strict,janpaul123,d88c03c0f1082d01294ef8cf5d14194d5d1284fa,1,Rollup merge of #95016 - janpaul123:patch-1 r=dtolnay Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict since we don't require `T` to have the same size just `size_of::() * capacity` to be the same since that is what results in `Layout::size` being the same in `dealloc` which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts` which I think is useful advise that could also be mentioned in the docs so I added that too. Let me know what you think! :),THUMBS_UP,2022-03-25T08:13:08Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95016,MERGED,2022-03-16T16:34:38Z,2022-03-28T05:09:52Z,Docs: make Vec::from_raw_parts documentation less strict,janpaul123,d88c03c0f1082d01294ef8cf5d14194d5d1284fa,1,Rollup merge of #95016 - janpaul123:patch-1 r=dtolnay Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict since we don't require `T` to have the same size just `size_of::() * capacity` to be the same since that is what results in `Layout::size` being the same in `dealloc` which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts` which I think is useful advise that could also be mentioned in the docs so I added that too. Let me know what you think! :),HEART,2022-05-19T20:43:51Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95020,MERGED,2022-03-16T18:55:08Z,2022-03-18T00:35:27Z,erase late-bound regions in dyn projection types for debuginfo,compiler-errors,4ca56d2b7bbe275bc6c9f3cd698c6e0719a07182,2,Auto merge of #95020 - compiler-errors:late-debuginfo r=jackh726 erase late-bound regions in dyn projection types for debuginfo simply skipping the binder leaves late-bound regions that will cause debug assertions to fail when checking the layout of the projection ty so let's erase the regions instead. sorry for taking so long to put this up had trouble getting rustc set up on a new computer. fixes #94998,HEART,2022-03-16T19:07:33Z,lqd,NA https://github.com/rust-lang/rust/pull/95020,MERGED,2022-03-16T18:55:08Z,2022-03-18T00:35:27Z,erase late-bound regions in dyn projection types for debuginfo,compiler-errors,4ca56d2b7bbe275bc6c9f3cd698c6e0719a07182,2,Auto merge of #95020 - compiler-errors:late-debuginfo r=jackh726 erase late-bound regions in dyn projection types for debuginfo simply skipping the binder leaves late-bound regions that will cause debug assertions to fail when checking the layout of the projection ty so let's erase the regions instead. sorry for taking so long to put this up had trouble getting rustc set up on a new computer. fixes #94998,HEART,2022-03-16T19:36:51Z,djkoloski,djkoloski@gmail.com https://github.com/rust-lang/rust/pull/95020,MERGED,2022-03-16T18:55:08Z,2022-03-18T00:35:27Z,erase late-bound regions in dyn projection types for debuginfo,compiler-errors,4ca56d2b7bbe275bc6c9f3cd698c6e0719a07182,2,Auto merge of #95020 - compiler-errors:late-debuginfo r=jackh726 erase late-bound regions in dyn projection types for debuginfo simply skipping the binder leaves late-bound regions that will cause debug assertions to fail when checking the layout of the projection ty so let's erase the regions instead. sorry for taking so long to put this up had trouble getting rustc set up on a new computer. fixes #94998,HEART,2022-03-16T19:39:41Z,tmandry,NA https://github.com/rust-lang/rust/pull/95020,MERGED,2022-03-16T18:55:08Z,2022-03-18T00:35:27Z,erase late-bound regions in dyn projection types for debuginfo,compiler-errors,4ca56d2b7bbe275bc6c9f3cd698c6e0719a07182,2,Auto merge of #95020 - compiler-errors:late-debuginfo r=jackh726 erase late-bound regions in dyn projection types for debuginfo simply skipping the binder leaves late-bound regions that will cause debug assertions to fail when checking the layout of the projection ty so let's erase the regions instead. sorry for taking so long to put this up had trouble getting rustc set up on a new computer. fixes #94998,HEART,2022-03-16T23:57:48Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/95020,MERGED,2022-03-16T18:55:08Z,2022-03-18T00:35:27Z,erase late-bound regions in dyn projection types for debuginfo,compiler-errors,4ca56d2b7bbe275bc6c9f3cd698c6e0719a07182,2,Auto merge of #95020 - compiler-errors:late-debuginfo r=jackh726 erase late-bound regions in dyn projection types for debuginfo simply skipping the binder leaves late-bound regions that will cause debug assertions to fail when checking the layout of the projection ty so let's erase the regions instead. sorry for taking so long to put this up had trouble getting rustc set up on a new computer. fixes #94998,HEART,2022-03-17T09:13:42Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/95024,MERGED,2022-03-16T21:20:12Z,2022-03-28T16:15:29Z,rustdoc: add 🔒 to items with restricted visibility,koehlma,2d37f38f872859b2b096772765a7987199c852c4,2,"Auto merge of #95024 - koehlma:rustdoc-private-items r=GuillaumeGomez camelid jsha rustdoc: add 🔒 to items with restricted visibility This change marks items with restricted visibility with 🔒 when building with `--document-private-items`: There also appears a “Restricted Visibility” tooltip when hovering over the emoji. --- The original PR for reference: This change makes private items slightly transparent (similar to `unstable` items in rustc): I found myself using `--document-private-items` a lot recently because I find the documentation of private internals quite helpful when working on a larger project. However not being able to distinguish private from public items (see #87785) when looking at the documentation makes this somewhat cumbersome. This PR addresses the third suggestion of issue #87785 by marking private items typographically. It seems to me that the other suggestions are more involved but this is at least a first step. A private item is also made slightly transparent in the path displayed in the header of a page: I am looking forward to feedback and suggestions.",HEART,2022-03-31T12:50:04Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95024,MERGED,2022-03-16T21:20:12Z,2022-03-28T16:15:29Z,rustdoc: add 🔒 to items with restricted visibility,koehlma,2d37f38f872859b2b096772765a7987199c852c4,2,"Auto merge of #95024 - koehlma:rustdoc-private-items r=GuillaumeGomez camelid jsha rustdoc: add 🔒 to items with restricted visibility This change marks items with restricted visibility with 🔒 when building with `--document-private-items`: There also appears a “Restricted Visibility” tooltip when hovering over the emoji. --- The original PR for reference: This change makes private items slightly transparent (similar to `unstable` items in rustc): I found myself using `--document-private-items` a lot recently because I find the documentation of private internals quite helpful when working on a larger project. However not being able to distinguish private from public items (see #87785) when looking at the documentation makes this somewhat cumbersome. This PR addresses the third suggestion of issue #87785 by marking private items typographically. It seems to me that the other suggestions are more involved but this is at least a first step. A private item is also made slightly transparent in the path displayed in the header of a page: I am looking forward to feedback and suggestions.",HEART,2022-03-31T12:53:55Z,fmease,NA https://github.com/rust-lang/rust/pull/95025,OPEN,2022-03-16T21:50:14Z,NA,Implement #[deprecated_safe],skippy10110,NA,NA,NA,THUMBS_UP,2022-05-08T00:11:23Z,Cyborus04,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HEART,2022-03-17T01:25:58Z,mati865,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-03-17T01:26:02Z,mati865,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-03-18T22:10:18Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-03-25T20:52:00Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-03-25T20:52:08Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-04-04T09:09:07Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-04-07T15:04:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-05-19T15:09:53Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HEART,2022-05-19T15:09:54Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-05-19T15:09:54Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-05-19T15:22:00Z,Razican,razican@protonmail.ch https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,CONFUSED,2022-05-19T16:26:56Z,jam1garner,jam@jam1.re https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-05-19T22:44:03Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-05-19T23:26:40Z,zekefast,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,CONFUSED,2022-05-23T13:34:11Z,jangorecki,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-05-25T12:32:55Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HEART,2022-05-25T12:32:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-05-25T12:32:57Z,schneiderfelipe,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HEART,2022-06-06T18:14:24Z,ettoredn,ettore@ettoredelnegro.me https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,CONFUSED,2022-06-06T18:14:25Z,ettoredn,ettore@ettoredelnegro.me https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-06-06T18:14:27Z,ettoredn,ettore@ettoredelnegro.me https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-06-06T18:14:28Z,ettoredn,ettore@ettoredelnegro.me https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-06-24T17:09:31Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HEART,2022-06-24T17:09:32Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,ROCKET,2022-06-24T17:09:32Z,SirMishaa,NA https://github.com/rust-lang/rust/pull/95026,OPEN,2022-03-16T22:18:08Z,NA,Increase the minimum linux-gnu versions,cuviper,NA,NA,NA,HOORAY,2022-07-08T07:55:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95032,MERGED,2022-03-17T10:08:27Z,2022-04-01T20:33:31Z,Clean up categorize and sort unstable features in std.,m-ou-se,3cb5925660f06b5e0b5bed5675edde9597a4c4ee,1,Rollup merge of #95032 - m-ou-se:std-features r=yaahc Clean up categorize and sort unstable features in std.,HEART,2022-03-30T13:09:30Z,mati865,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-17T13:05:07Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-17T16:20:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-03-18T13:34:28Z,pitdicker,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-18T23:00:21Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-03-18T23:00:22Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-19T09:31:41Z,mati865,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-03-19T09:31:41Z,mati865,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-24T08:20:26Z,hkratz,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-03-24T08:20:27Z,hkratz,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-28T23:48:22Z,panaman67,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-29T00:49:01Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-31T04:30:16Z,luojia65,me@luojia.cc https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-03-31T04:30:44Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-01T02:37:28Z,autumnontape,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-04T12:54:12Z,Thomasdezeeuw,thomasdezeeuw@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-05T23:46:20Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-04-14T04:39:09Z,Virgiel,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-14T04:39:09Z,Virgiel,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-14T04:39:10Z,Virgiel,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-14T06:04:18Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-14T09:44:51Z,jakoschiko,jakob.schikowski@gmx.de https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-14T17:18:51Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-04-15T10:01:54Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-04-17T16:44:31Z,theduke,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-18T07:05:49Z,lenstr,ilenstr@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-04-19T11:47:46Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-27T21:59:17Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-04-30T12:40:03Z,steffahn,fdsteffahn@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-03T18:55:41Z,yerke,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-03T18:55:43Z,yerke,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-03T18:55:43Z,yerke,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-03T19:21:13Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-03T19:21:14Z,KokaKiwi,kokakiwi+github@kokakiwi.net https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-03T20:37:15Z,advilm,amohi9046@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-03T20:53:07Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-03T22:24:29Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-04T02:10:23Z,ccqpein,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-04T02:10:24Z,ccqpein,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-04T02:10:26Z,ccqpein,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-04T02:10:26Z,ccqpein,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-04T02:13:49Z,Nessex,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-04T03:03:49Z,pjtatlow,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-04T05:51:34Z,chrishna1,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-04T11:57:43Z,PeterWrighten,peterwrighten@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-04T16:00:20Z,imxood,Imxood@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-04T16:00:21Z,imxood,Imxood@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-04T16:00:24Z,imxood,Imxood@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-04T16:00:26Z,imxood,Imxood@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-04T17:33:55Z,wbrickner,wgbrickner@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-05T07:40:56Z,matyunin,free.all.bums@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T08:17:55Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-05T09:40:30Z,nulladdict,nulladdicted@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T09:40:32Z,nulladdict,nulladdicted@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T10:11:37Z,mateusfreira,mateus.freira@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-05T10:12:22Z,joseluisq,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-05T11:43:14Z,amrhassan,amr.hassan@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-05T11:43:15Z,amrhassan,amr.hassan@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T15:11:45Z,omid,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-05-05T16:12:46Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T16:12:47Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-05T16:12:50Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-05-05T16:12:51Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-05-05T23:20:33Z,redwarp,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-06T01:26:50Z,othmanabdulsalam,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-06T02:13:21Z,liangyongrui,leungyongrui@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-06T05:51:44Z,adam-wyluda,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-06T09:20:42Z,js2xxx,development2014@outlook.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-05-06T14:27:44Z,ehsanmok,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-12T09:17:10Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-22T17:19:37Z,kadiwa4,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-29T09:29:50Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-30T17:57:04Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-30T17:57:05Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-30T17:57:05Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-06-30T17:57:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-30T22:01:36Z,phip1611,phip1611@gmail.com https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-07-01T00:50:06Z,rustbomber,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-07-02T15:13:10Z,ritbl,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-07-02T15:13:11Z,ritbl,NA https://github.com/rust-lang/rust/pull/95035,MERGED,2022-03-17T11:31:05Z,2022-04-05T22:42:11Z,Replace Linux Mutex and Condvar with futex based ones.,m-ou-se,306ba8357fb36212b7d30efb9eb9e41659ac1445,5,Auto merge of #95035 - m-ou-se:futex-locks-on-linux r=Amanieu Replace Linux Mutex and Condvar with futex based ones. Tracking issue: https://github.com/rust-lang/rust/issues/93740,ROCKET,2022-07-02T15:13:11Z,ritbl,NA https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,EYES,2022-03-17T19:19:28Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,LAUGH,2022-03-17T23:16:35Z,faptc,NA https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,EYES,2022-03-18T03:53:27Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,LAUGH,2022-03-18T12:19:34Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,LAUGH,2022-03-19T09:28:03Z,mati865,NA https://github.com/rust-lang/rust/pull/95049,OPEN,2022-03-17T18:42:06Z,NA,[crater only] Stabilize never type always falling back to !,Mark-Simulacrum,NA,NA,NA,EYES,2022-03-19T09:28:11Z,mati865,NA https://github.com/rust-lang/rust/pull/95050,MERGED,2022-03-17T18:46:31Z,2022-03-17T21:33:24Z,Fix cmake build.,ehuss,58f11791af4f97572e7afd83f11cffe04bbbd12f,1,Auto merge of #95050 - ehuss:fix-cmake-build r=Mark-Simulacrum Fix cmake build. This is an attempt to fix the cmake build. For some reason it has recently started failing with a permission denied trying to overwrite `/tmp/build.log`. This file exists from the `build-toolchains.sh` step which is owned by the rustbuild user. I think there is some behavior where a sticky `/tmp` directory doesn't allow overwriting files owned by other users even when running as root. I do not know why this has suddenly started and I can't reproduce locally with my own docker setup. However this fix seems to work on CI.,HEART,2022-03-17T18:47:52Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95050,MERGED,2022-03-17T18:46:31Z,2022-03-17T21:33:24Z,Fix cmake build.,ehuss,58f11791af4f97572e7afd83f11cffe04bbbd12f,1,Auto merge of #95050 - ehuss:fix-cmake-build r=Mark-Simulacrum Fix cmake build. This is an attempt to fix the cmake build. For some reason it has recently started failing with a permission denied trying to overwrite `/tmp/build.log`. This file exists from the `build-toolchains.sh` step which is owned by the rustbuild user. I think there is some behavior where a sticky `/tmp` directory doesn't allow overwriting files owned by other users even when running as root. I do not know why this has suddenly started and I can't reproduce locally with my own docker setup. However this fix seems to work on CI.,HEART,2022-03-17T18:52:06Z,djkoloski,djkoloski@gmail.com https://github.com/rust-lang/rust/pull/95050,MERGED,2022-03-17T18:46:31Z,2022-03-17T21:33:24Z,Fix cmake build.,ehuss,58f11791af4f97572e7afd83f11cffe04bbbd12f,1,Auto merge of #95050 - ehuss:fix-cmake-build r=Mark-Simulacrum Fix cmake build. This is an attempt to fix the cmake build. For some reason it has recently started failing with a permission denied trying to overwrite `/tmp/build.log`. This file exists from the `build-toolchains.sh` step which is owned by the rustbuild user. I think there is some behavior where a sticky `/tmp` directory doesn't allow overwriting files owned by other users even when running as root. I do not know why this has suddenly started and I can't reproduce locally with my own docker setup. However this fix seems to work on CI.,HEART,2022-03-17T19:24:59Z,hkratz,NA https://github.com/rust-lang/rust/pull/95051,OPEN,2022-03-17T19:44:03Z,NA,vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods,dpaoliello,NA,NA,NA,HEART,2022-03-30T01:35:00Z,Raekye,NA https://github.com/rust-lang/rust/pull/95051,OPEN,2022-03-17T19:44:03Z,NA,vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods,dpaoliello,NA,NA,NA,HEART,2022-04-15T19:43:54Z,ojeda,NA https://github.com/rust-lang/rust/pull/95051,OPEN,2022-03-17T19:44:03Z,NA,vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods,dpaoliello,NA,NA,NA,HEART,2022-05-11T20:41:08Z,Ericson2314,inquire@JohnEricson.me https://github.com/rust-lang/rust/pull/95051,OPEN,2022-03-17T19:44:03Z,NA,vec: add try_* methods and a try_vec! macro to make Vec usable in without infallible allocation methods,dpaoliello,NA,NA,NA,HEART,2022-06-14T06:36:43Z,jschwe,NA https://github.com/rust-lang/rust/pull/95063,MERGED,2022-03-18T02:45:46Z,2022-03-20T07:12:08Z,Fix debuginfo tests with GDB 11.2,tromey,499d4a56840e3760905fbda95550553281828dc6,3,Auto merge of #95063 - tromey:fix-94458-gdb-char r=Mark-Simulacrum Fix debuginfo tests with GDB 11.2 GDB 11.2 added support for DW_ATE_UTF which caused some test failures. This fixes these tests by changing the format that is used and adds a new test to verify that characters are emitted as something that GDB can print in a char-like way. Fixes #94458,THUMBS_UP,2022-03-18T08:48:22Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/95071,MERGED,2022-03-18T12:50:37Z,2022-03-20T16:29:15Z,Miri: implement arbitrary-self dyn receivers,RalfJung,9bd53718e2537d95d8c092609618c2dcd6f05127,1,Auto merge of #95071 - RalfJung:arbitrary-self-dyn r=oli-obk Miri: implement arbitrary-self dyn receivers Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809). Fixes https://github.com/rust-lang/miri/issues/1038 r? `@oli-obk` Cc `@eddyb`,HEART,2022-03-18T12:52:14Z,taiki-e,NA https://github.com/rust-lang/rust/pull/95071,MERGED,2022-03-18T12:50:37Z,2022-03-20T16:29:15Z,Miri: implement arbitrary-self dyn receivers,RalfJung,9bd53718e2537d95d8c092609618c2dcd6f05127,1,Auto merge of #95071 - RalfJung:arbitrary-self-dyn r=oli-obk Miri: implement arbitrary-self dyn receivers Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809). Fixes https://github.com/rust-lang/miri/issues/1038 r? `@oli-obk` Cc `@eddyb`,HEART,2022-03-18T16:36:01Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/95071,MERGED,2022-03-18T12:50:37Z,2022-03-20T16:29:15Z,Miri: implement arbitrary-self dyn receivers,RalfJung,9bd53718e2537d95d8c092609618c2dcd6f05127,1,Auto merge of #95071 - RalfJung:arbitrary-self-dyn r=oli-obk Miri: implement arbitrary-self dyn receivers Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809). Fixes https://github.com/rust-lang/miri/issues/1038 r? `@oli-obk` Cc `@eddyb`,HEART,2022-03-18T23:15:02Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/95071,MERGED,2022-03-18T12:50:37Z,2022-03-20T16:29:15Z,Miri: implement arbitrary-self dyn receivers,RalfJung,9bd53718e2537d95d8c092609618c2dcd6f05127,1,Auto merge of #95071 - RalfJung:arbitrary-self-dyn r=oli-obk Miri: implement arbitrary-self dyn receivers Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809). Fixes https://github.com/rust-lang/miri/issues/1038 r? `@oli-obk` Cc `@eddyb`,HEART,2022-03-19T21:33:10Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95071,MERGED,2022-03-18T12:50:37Z,2022-03-20T16:29:15Z,Miri: implement arbitrary-self dyn receivers,RalfJung,9bd53718e2537d95d8c092609618c2dcd6f05127,1,Auto merge of #95071 - RalfJung:arbitrary-self-dyn r=oli-obk Miri: implement arbitrary-self dyn receivers Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809). Fixes https://github.com/rust-lang/miri/issues/1038 r? `@oli-obk` Cc `@eddyb`,HEART,2022-03-20T17:17:26Z,quininer,quininer@live.com https://github.com/rust-lang/rust/pull/95072,MERGED,2022-03-18T13:31:28Z,2022-03-19T19:41:12Z,Re-enable parallel debuginfo tests,tromey,7de48eafa179b299edd1c19c33a86d89653ac78d,1,Rollup merge of #95072 - tromey:parallel-debug-tests r=tmiasko Re-enable parallel debuginfo tests Debuginfo tests are serialized due to some older version of LLDB. However that comment was last touched in 2014 so presumably these older versions are long since obsolete. Partially fixes bug #72719.,HEART,2022-04-29T01:20:13Z,tmandry,NA https://github.com/rust-lang/rust/pull/95085,MERGED,2022-03-18T19:10:57Z,2022-03-21T23:00:25Z,Return err instead of ICE,ouz-a,e41e510c7f2ef36b324bf9bfe4947383a290baf8,4,Rollup merge of #95085 - ouz-a:master5 r=jackh726 Return err instead of ICE Having `escaping_bound_vars` results in ICE when trying to create `ty::Binder::dummy` to avoid it we return err like the line above. I think this requires a more sophisticated fix I would love to investigate if mentorship is available 🤓 Fixes #95023 and #85350,HOORAY,2022-03-18T19:22:43Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,THUMBS_UP,2022-03-19T00:13:59Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,THUMBS_UP,2022-03-19T16:13:57Z,lqd,NA https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,THUMBS_UP,2022-03-19T21:32:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,THUMBS_UP,2022-03-23T21:22:53Z,camelid,NA https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,THUMBS_UP,2022-03-30T00:15:53Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95096,MERGED,2022-03-19T00:04:31Z,2022-03-29T15:19:04Z,Remove header field from clean::Function,GuillaumeGomez,11909e3588319235e28e99294e17cca11db1d7e2,7,Auto merge of #95096 - GuillaumeGomez:rm-header-fn-field r=camelid Remove header field from clean::Function Fixes https://github.com/rust-lang/rust/issues/89673. This is another take on https://github.com/rust-lang/rust/issues/89673 (compared to https://github.com/rust-lang/rust/pull/91217) but very different on the approach: I moved the header call in one place but still require to have the `clean::Item` so I can use the `DefId` to get what is missing. cc `@jyn514` (you reviewed the original so maybe you want to take a look?) r? `@camelid`,HOORAY,2022-03-30T00:16:03Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95098,MERGED,2022-03-19T00:34:23Z,2022-03-28T05:09:52Z,impl From<&[T; N]> and From<&mut [T; N]> for Vec,shepmaster,8bfc03fde037ba4b64c29d14c00b04586dc909cf,1,"Rollup merge of #95098 - shepmaster:vec-from-array-ref r=dtolnay impl From<&[T; N]> and From<&mut [T; N]> for Vec I really wanted to write: ```rust fn example(a: impl Into>) {} fn main() { example(b""raw""); } ```",THUMBS_UP,2022-03-25T08:12:04Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95104,MERGED,2022-03-19T04:22:59Z,2022-03-21T04:50:28Z,suggest removing type ascription in bad parsing position,compiler-errors,051d1176b786aadd7d7c048f822cb6bfab00fe03,2,Auto merge of #95104 - compiler-errors:remove-ascription r=davidtwco suggest removing type ascription in bad parsing position Not sure how to test this with the non-nightly suggestion. Didn't add a new UI test because it already manifests in an existing UI test. Fixes #95014,HEART,2022-03-22T01:19:49Z,estebank,NA https://github.com/rust-lang/rust/pull/95115,OPEN,2022-03-19T15:39:21Z,NA,`Clone` suggestions,WaffleLapkin,NA,NA,NA,HEART,2022-03-20T01:09:35Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95115,OPEN,2022-03-19T15:39:21Z,NA,`Clone` suggestions,WaffleLapkin,NA,NA,NA,HEART,2022-03-22T01:35:58Z,estebank,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-03-21T23:47:22Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-05-11T15:56:17Z,notgull,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-05-15T21:58:56Z,Miksel12,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-06-15T20:37:02Z,A6GibKm,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-06-15T20:57:41Z,Virgiel,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,THUMBS_UP,2022-06-15T23:18:38Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/95118,MERGED,2022-03-19T19:17:28Z,2022-06-15T13:45:19Z,Implement stabilization of `#[feature(io_safety)]`.,sunfishcode,40912e12f1eb35434fc5489adb6ddcb9b976a7e4,13,Rollup merge of #95118 - sunfishcode:sunfishcode/stabilize-io-safety r=joshtriplett Implement stabilization of `#[feature(io_safety)]`. Implement stabilization of [I/O safety] aka `#[feature(io_safety)]`. Fixes #87074. [I/O safety]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md,HOORAY,2022-06-17T07:19:02Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/95119,MERGED,2022-03-19T20:09:04Z,2022-04-04T15:30:32Z,Improve method name suggestions,OliverMD,d5139f44690e7765df801ca33a7f627d128ac9e2,9,Auto merge of #95119 - OliverMD:method_suggestions r=davidtwco Improve method name suggestions Attempts to improve method name suggestions when a matching method name is not found. The approach taken is use the Levenshtein distance and account for substrings having a high distance but can sometimes be very close to the intended method (eg. empty vs is_empty). resolves #94747,HEART,2022-04-04T06:16:00Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95119,MERGED,2022-03-19T20:09:04Z,2022-04-04T15:30:32Z,Improve method name suggestions,OliverMD,d5139f44690e7765df801ca33a7f627d128ac9e2,9,Auto merge of #95119 - OliverMD:method_suggestions r=davidtwco Improve method name suggestions Attempts to improve method name suggestions when a matching method name is not found. The approach taken is use the Levenshtein distance and account for substrings having a high distance but can sometimes be very close to the intended method (eg. empty vs is_empty). resolves #94747,HEART,2022-06-14T13:16:38Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/95119,MERGED,2022-03-19T20:09:04Z,2022-04-04T15:30:32Z,Improve method name suggestions,OliverMD,d5139f44690e7765df801ca33a7f627d128ac9e2,9,Auto merge of #95119 - OliverMD:method_suggestions r=davidtwco Improve method name suggestions Attempts to improve method name suggestions when a matching method name is not found. The approach taken is use the Levenshtein distance and account for substrings having a high distance but can sometimes be very close to the intended method (eg. empty vs is_empty). resolves #94747,HEART,2022-06-14T16:23:49Z,pro465,NA https://github.com/rust-lang/rust/pull/95119,MERGED,2022-03-19T20:09:04Z,2022-04-04T15:30:32Z,Improve method name suggestions,OliverMD,d5139f44690e7765df801ca33a7f627d128ac9e2,9,Auto merge of #95119 - OliverMD:method_suggestions r=davidtwco Improve method name suggestions Attempts to improve method name suggestions when a matching method name is not found. The approach taken is use the Levenshtein distance and account for substrings having a high distance but can sometimes be very close to the intended method (eg. empty vs is_empty). resolves #94747,HEART,2022-06-17T08:19:12Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95159,MERGED,2022-03-21T00:20:19Z,2022-03-23T00:27:47Z,Introduce `TtParser`,nnethercote,a4a5e79814fb4d1568fb0ea5ca50f810b071ae12,7,Auto merge of #95159 - nnethercote:TtParser r=petrochenkov Introduce `TtParser` These commits make a number of changes to declarative macro expansion resulting in code that is shorter simpler and faster. Best reviewed one commit at a time. r? `@petrochenkov`,HOORAY,2022-03-21T07:32:04Z,lqd,NA https://github.com/rust-lang/rust/pull/95159,MERGED,2022-03-21T00:20:19Z,2022-03-23T00:27:47Z,Introduce `TtParser`,nnethercote,a4a5e79814fb4d1568fb0ea5ca50f810b071ae12,7,Auto merge of #95159 - nnethercote:TtParser r=petrochenkov Introduce `TtParser` These commits make a number of changes to declarative macro expansion resulting in code that is shorter simpler and faster. Best reviewed one commit at a time. r? `@petrochenkov`,HOORAY,2022-03-21T07:42:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95189,MERGED,2022-03-22T00:02:52Z,2022-04-07T12:20:57Z,Stop flagging unexpected inner attributes as outer ones in certain diagnostics,fmease,648d644c602406eb003dde56e7fd48effce07f15,7,Rollup merge of #95189 - fmease:fix-issue-94340 r=estebank Stop flagging unexpected inner attributes as outer ones in certain diagnostics Fixes #94340. In the issue to-be-fixed I write that the general message _an inner attribute is not permitted in this context_ should be more specific noting that the “context” is the `include` macro. This however cannot be achieved without touching a lot of things and passing a flag to the `parse_expr` and `parse_item` calls in `expand_include`. This seems rather hacky to me. That's why I left it as it. `Span::from_expansion` does not apply either AFAIK. `@rustbot` label A-diagnostics T-compiler,THUMBS_UP,2022-04-05T17:32:45Z,estebank,NA https://github.com/rust-lang/rust/pull/95195,CLOSED,2022-03-22T02:28:17Z,2022-03-27T02:05:29Z,Add PeekableIterator trait as an experiment,clarfonthey,NA,NA,NA,THUMBS_UP,2022-03-23T00:59:43Z,mohe2015,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T10:24:55Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T10:37:49Z,bugadani,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T10:40:30Z,Urgau,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T15:08:56Z,crazyboycjr,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T16:39:51Z,tema3210,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T17:04:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T18:53:35Z,yaahc,jlusby42@gmail.com https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T19:35:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T19:58:00Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T20:22:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T20:38:44Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T21:08:34Z,Dante-Broggi,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T23:23:33Z,arichardson,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-22T23:37:11Z,brooksdavis,brooks@one-eyed-alien.net https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-23T03:11:45Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-23T03:43:07Z,Miksel12,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-23T05:14:41Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95199,CLOSED,2022-03-22T05:30:58Z,2022-03-23T17:35:20Z,WIP PROOF-OF-CONCEPT: experiment with very strict pointer provenance,Gankra,NA,NA,NA,HEART,2022-03-23T22:13:09Z,digama0,NA https://github.com/rust-lang/rust/pull/95209,OPEN,2022-03-22T15:03:45Z,NA,Enable -Z panic-in-drop=abort by default,Amanieu,NA,NA,NA,HOORAY,2022-03-25T07:30:27Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95238,MERGED,2022-03-23T13:15:31Z,2022-03-24T01:43:25Z,Stop emitting E0026 for struct enums with underscores,TaKO8Ki,fab7a6a9fd68b66f7ecd2fd1b2f6cfa0277b4413,3,Rollup merge of #95238 - TaKO8Ki:stop-emitting-E0026-for-struct-enum-with-underscore r=estebank Stop emitting E0026 for struct enums with underscores This patch resolves a part of #83263; r? `@estebank`,HEART,2022-03-23T21:09:27Z,estebank,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-03-23T16:34:45Z,solson,scott@solson.me https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-03-24T01:27:40Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-03-25T09:21:56Z,pitdicker,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-03-28T18:35:58Z,arichardson,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-03-30T00:45:55Z,NotAFile,NotAFile@gmail.com https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-04-06T02:47:22Z,carlpaten,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-04-06T07:59:20Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-04-06T21:26:52Z,smbl64,smbl64@gmail.com https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-04-07T06:55:47Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-04-07T22:47:27Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-05-04T00:35:02Z,rasuto5,NA https://github.com/rust-lang/rust/pull/95241,MERGED,2022-03-23T15:44:10Z,2022-03-30T12:29:02Z,Strict Provenance MVP,Gankra,e50ff9b4521234e56ff46f8ed0372d5cb5689654,39,"Auto merge of #95241 - Gankra:cleaned-provenance r=workingjubilee Strict Provenance MVP This patch series examines the question: how bad would it be if we adopted an extremely strict pointer provenance model that completely banished all int<->ptr casts. The key insight to making this approach even *vaguely* pallatable is the ptr.with_addr(addr) -> ptr function which takes a pointer and an address and creates a new pointer with that address and the provenance of the input pointer. In this way the ""chain of custody"" is completely and dynamically restored making the model suitable even for dynamic checkers like CHERI and Miri. This is not a formal model but lots of the docs discussing the model have been updated to try to the *concept* of this design in the hopes that it can be iterated on. See #95228",THUMBS_UP,2022-05-08T22:22:47Z,crazyboycjr,NA https://github.com/rust-lang/rust/pull/95247,MERGED,2022-03-23T19:02:51Z,2022-03-23T23:02:20Z,Update to LLVM 14.0.0 final,cuviper,9f4dc0b4db892271cd0dada6e072775b5b5d6b1e,2,Auto merge of #95247 - cuviper:llvm14 r=nikic Update to LLVM 14.0.0 final This is a simple rebase of the submodule onto the `llvmorg-14.0.0` release tag. r? `@nikic`,HOORAY,2022-03-23T19:07:08Z,ZuseZ4,git@manuel.drehwald.info https://github.com/rust-lang/rust/pull/95247,MERGED,2022-03-23T19:02:51Z,2022-03-23T23:02:20Z,Update to LLVM 14.0.0 final,cuviper,9f4dc0b4db892271cd0dada6e072775b5b5d6b1e,2,Auto merge of #95247 - cuviper:llvm14 r=nikic Update to LLVM 14.0.0 final This is a simple rebase of the submodule onto the `llvmorg-14.0.0` release tag. r? `@nikic`,HOORAY,2022-03-24T07:49:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95251,MERGED,2022-03-23T21:45:15Z,2022-03-31T02:53:38Z,Reduce max hash in raw strings from u16 to u8,GrishaVar,86388f617178875af0b6a585479efa4f09abd630,6,Rollup merge of #95251 - GrishaVar:hashes-u16-to-u8 r=dtolnay Reduce max hash in raw strings from u16 to u8 [Relevant discussion](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/Max.20raw.20string.20delimiters),ROCKET,2022-03-26T20:17:35Z,NetsaiMeklit,NA https://github.com/rust-lang/rust/pull/95254,MERGED,2022-03-23T23:32:36Z,2022-04-10T06:28:39Z,Fix `cargo run` on Windows,jyn514,f7b4824731483df9ac911cb5b60fe85f04162ad0,1,Auto merge of #95254 - jyn514:fix-windows-builds r=Mark-Simulacrum Fix `cargo run` on Windows Fixes the following error: ``` error: failed to run custom build command for `bootstrap v0.0.0 (C:\Users\Walther\git\rust\src\bootstrap)` Caused by: process didn't exit successfully: `C:\Users\Walther\git\rust\target\debug\build\bootstrap-7757a4777dec0f86\build-script-build` (exit code: 101) --- stdout cargo:rerun-if-changed=build.rs cargo:rerun-if-env-changed=RUSTC cargo:rustc-env=BUILD_TRIPLE=x86_64-pc-windows-msvc cargo:rerun-if-env-changed=PATH --- stderr thread 'main' panicked at 'assertion failed: rustc.is_absolute()' src\bootstrap\build.rs:22:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace warning: build failed waiting for other jobs to finish... error: build failed ``` The problem was that the `dir.join` check only works with `rustc.exe` not `rustc`. Thanks `@Walther` for the help testing the fix! Helps with https://github.com/rust-lang/rust/issues/94829.,HOORAY,2022-03-24T08:58:50Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/95255,MERGED,2022-03-24T00:14:24Z,2022-03-25T14:16:21Z,resolve: Do not build expensive suggestions if they are not actually used,petrochenkov,903427b2e807cb1292388940b3f44f3b061cfebf,25,Auto merge of #95255 - petrochenkov:suggresolve r=michaelwoerister resolve: Do not build expensive suggestions if they are not actually used And remove a bunch of (conditionally) unused parameters from path resolution functions. This helps with performance issues in https://github.com/rust-lang/rust/pull/94857 and should be helpful in general even without that.,HEART,2022-03-24T02:10:52Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95255,MERGED,2022-03-24T00:14:24Z,2022-03-25T14:16:21Z,resolve: Do not build expensive suggestions if they are not actually used,petrochenkov,903427b2e807cb1292388940b3f44f3b061cfebf,25,Auto merge of #95255 - petrochenkov:suggresolve r=michaelwoerister resolve: Do not build expensive suggestions if they are not actually used And remove a bunch of (conditionally) unused parameters from path resolution functions. This helps with performance issues in https://github.com/rust-lang/rust/pull/94857 and should be helpful in general even without that.,HEART,2022-03-24T09:59:20Z,mati865,NA https://github.com/rust-lang/rust/pull/95255,MERGED,2022-03-24T00:14:24Z,2022-03-25T14:16:21Z,resolve: Do not build expensive suggestions if they are not actually used,petrochenkov,903427b2e807cb1292388940b3f44f3b061cfebf,25,Auto merge of #95255 - petrochenkov:suggresolve r=michaelwoerister resolve: Do not build expensive suggestions if they are not actually used And remove a bunch of (conditionally) unused parameters from path resolution functions. This helps with performance issues in https://github.com/rust-lang/rust/pull/94857 and should be helpful in general even without that.,HEART,2022-03-25T13:41:45Z,lqd,NA https://github.com/rust-lang/rust/pull/95256,MERGED,2022-03-24T00:22:42Z,2022-03-29T23:24:41Z,Ensure io::Error's bitpacked repr doesn't accidentally impl UnwindSafe,thomcc,3208ed7b21b8b8f035b8a6bb3172be0763cf45ab,1,Rollup merge of #95256 - thomcc:fix-unwind-safe r=m-ou-se Ensure io::Error's bitpacked repr doesn't accidentally impl UnwindSafe Sadly I'm not sure how to easily test that we don't impl a trait though (or can libstd use `where io::Error: !UnwindSafe` or something). Fixes #95203,HEART,2022-03-24T00:46:38Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95263,MERGED,2022-03-24T05:50:21Z,2022-03-31T07:40:33Z,Restore `impl Future` to async blocks,compiler-errors,4ce6567daa7aab5618aa27f69ceff779cbe2bd7d,13,"Rollup merge of #95263 - compiler-errors:async-block-pretty r=jackh726 Restore `impl Future` to async blocks I was sad when I undid some of the code I wrote in #91096 in the PR #95225 so I fixed it here to not print `[async output]`. This PR ""manually"" normalizes the associated type `<[generator] as Generator>::Return` type which appears very frequently in `impl Future` types that result from async block desugaring.",HEART,2022-03-24T13:26:09Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95290,OPEN,2022-03-24T22:49:21Z,NA,Document that `OsString` and `OsStr` are bytes; provide conversions to bytes,joshtriplett,NA,NA,NA,HEART,2022-03-25T08:17:09Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/95290,OPEN,2022-03-24T22:49:21Z,NA,Document that `OsString` and `OsStr` are bytes; provide conversions to bytes,joshtriplett,NA,NA,NA,HEART,2022-04-21T18:08:25Z,tux3,NA https://github.com/rust-lang/rust/pull/95290,OPEN,2022-03-24T22:49:21Z,NA,Document that `OsString` and `OsStr` are bytes; provide conversions to bytes,joshtriplett,NA,NA,NA,HEART,2022-05-25T17:56:41Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/95290,OPEN,2022-03-24T22:49:21Z,NA,Document that `OsString` and `OsStr` are bytes; provide conversions to bytes,joshtriplett,NA,NA,NA,HEART,2022-05-29T00:14:19Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/95292,OPEN,2022-03-25T00:36:56Z,NA,Allow specialized const trait impls.,BGR360,NA,NA,NA,HEART,2022-03-25T13:47:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95295,MERGED,2022-03-25T05:01:51Z,2022-07-10T11:35:18Z,Enforce that layout size fits in isize in Layout,CAD97,4ec97d991b1bd86dc89fee761d79ac8e85239a08,4,"Auto merge of #95295 - CAD97:layout-isize r=scottmcm Enforce that layout size fits in isize in Layout As it turns out enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to ""allow"" sizes which (when rounded up) would overflow `isize` but these are now declared as library UB for `Layout` meaning that consumers of `Layout` no longer have to check this before making an allocation. (Note that this is ""immediate library UB;"" IOW it is valid for a future release to make this immediate ""language UB "" and there is an extant patch to do so to allow Miri to catch this misuse.) See also #95252 [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule). Fixes https://github.com/rust-lang/rust/issues/95334 Some relevant quotes: `@eddyb ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078513769 > [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io: > > 1. **`Layout` ""producers"" / `GlobalAlloc` ""users""**: smart pointers (including `alloc::rc` copies with small tweaks) collections etc. > 2. **`Layout` ""consumers"" / `GlobalAlloc` ""providers""**: perhaps fewer of these but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks > > IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout` which: > > * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB > * frees both ""producers"" and ""consumers"" of `Layout` from manually reimplementing the checks > * manual checks can be risky e.g. if the final size passed to the allocator isn't the one being checked > * this applies retroactively fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory making a ""choke point"") > > > Feel free to quote this comment onto any relevant issue I might not be able to keep track of developments. `@Gankra ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078556371 > As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it. > > We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any ""regressions"" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them. cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252 those potential failure points should almost certainly still get nicer panics than just ""unwrap failed"" (which they would get by this PR). It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation and then `panic!` from a single location at the end of `Layout` manipulation to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big. Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further and the UCG document says this hasn't been RFCd) and a crater run. Ideally no code exists that will start failing with this addition; if it does it was _likely_ (but not certainly) causing UB. Changes the raw_vec allocation path thus deserves a perf run as well. I suggest hiding whitespace-only changes in the diff view.",HEART,2022-03-25T05:12:54Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/95295,MERGED,2022-03-25T05:01:51Z,2022-07-10T11:35:18Z,Enforce that layout size fits in isize in Layout,CAD97,4ec97d991b1bd86dc89fee761d79ac8e85239a08,4,"Auto merge of #95295 - CAD97:layout-isize r=scottmcm Enforce that layout size fits in isize in Layout As it turns out enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to ""allow"" sizes which (when rounded up) would overflow `isize` but these are now declared as library UB for `Layout` meaning that consumers of `Layout` no longer have to check this before making an allocation. (Note that this is ""immediate library UB;"" IOW it is valid for a future release to make this immediate ""language UB "" and there is an extant patch to do so to allow Miri to catch this misuse.) See also #95252 [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule). Fixes https://github.com/rust-lang/rust/issues/95334 Some relevant quotes: `@eddyb ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078513769 > [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io: > > 1. **`Layout` ""producers"" / `GlobalAlloc` ""users""**: smart pointers (including `alloc::rc` copies with small tweaks) collections etc. > 2. **`Layout` ""consumers"" / `GlobalAlloc` ""providers""**: perhaps fewer of these but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks > > IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout` which: > > * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB > * frees both ""producers"" and ""consumers"" of `Layout` from manually reimplementing the checks > * manual checks can be risky e.g. if the final size passed to the allocator isn't the one being checked > * this applies retroactively fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory making a ""choke point"") > > > Feel free to quote this comment onto any relevant issue I might not be able to keep track of developments. `@Gankra ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078556371 > As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it. > > We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any ""regressions"" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them. cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252 those potential failure points should almost certainly still get nicer panics than just ""unwrap failed"" (which they would get by this PR). It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation and then `panic!` from a single location at the end of `Layout` manipulation to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big. Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further and the UCG document says this hasn't been RFCd) and a crater run. Ideally no code exists that will start failing with this addition; if it does it was _likely_ (but not certainly) causing UB. Changes the raw_vec allocation path thus deserves a perf run as well. I suggest hiding whitespace-only changes in the diff view.",HEART,2022-03-25T05:23:12Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/95295,MERGED,2022-03-25T05:01:51Z,2022-07-10T11:35:18Z,Enforce that layout size fits in isize in Layout,CAD97,4ec97d991b1bd86dc89fee761d79ac8e85239a08,4,"Auto merge of #95295 - CAD97:layout-isize r=scottmcm Enforce that layout size fits in isize in Layout As it turns out enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to ""allow"" sizes which (when rounded up) would overflow `isize` but these are now declared as library UB for `Layout` meaning that consumers of `Layout` no longer have to check this before making an allocation. (Note that this is ""immediate library UB;"" IOW it is valid for a future release to make this immediate ""language UB "" and there is an extant patch to do so to allow Miri to catch this misuse.) See also #95252 [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule). Fixes https://github.com/rust-lang/rust/issues/95334 Some relevant quotes: `@eddyb ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078513769 > [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io: > > 1. **`Layout` ""producers"" / `GlobalAlloc` ""users""**: smart pointers (including `alloc::rc` copies with small tweaks) collections etc. > 2. **`Layout` ""consumers"" / `GlobalAlloc` ""providers""**: perhaps fewer of these but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks > > IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout` which: > > * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB > * frees both ""producers"" and ""consumers"" of `Layout` from manually reimplementing the checks > * manual checks can be risky e.g. if the final size passed to the allocator isn't the one being checked > * this applies retroactively fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory making a ""choke point"") > > > Feel free to quote this comment onto any relevant issue I might not be able to keep track of developments. `@Gankra ` https://github.com/rust-lang/rust/pull/95252#issuecomment-1078556371 > As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it. > > We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any ""regressions"" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them. cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252 those potential failure points should almost certainly still get nicer panics than just ""unwrap failed"" (which they would get by this PR). It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation and then `panic!` from a single location at the end of `Layout` manipulation to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big. Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further and the UCG document says this hasn't been RFCd) and a crater run. Ideally no code exists that will start failing with this addition; if it does it was _likely_ (but not certainly) causing UB. Changes the raw_vec allocation path thus deserves a perf run as well. I suggest hiding whitespace-only changes in the diff view.",HEART,2022-04-03T20:41:12Z,vexx32,NA https://github.com/rust-lang/rust/pull/95296,MERGED,2022-03-25T05:40:08Z,2022-03-26T08:24:34Z,Prettify rustc_session with recent conveniences,workingjubilee,2882c2023d6e1dee4128611e89fcde0cf6199f6d,9,Auto merge of #95296 - workingjubilee:pretty-session r=Dylan-DPC Prettify rustc_session with recent conveniences No functional changes. I felt like making something beautiful.,HOORAY,2022-03-25T23:34:19Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95296,MERGED,2022-03-25T05:40:08Z,2022-03-26T08:24:34Z,Prettify rustc_session with recent conveniences,workingjubilee,2882c2023d6e1dee4128611e89fcde0cf6199f6d,9,Auto merge of #95296 - workingjubilee:pretty-session r=Dylan-DPC Prettify rustc_session with recent conveniences No functional changes. I felt like making something beautiful.,HEART,2022-03-26T19:28:07Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/95296,MERGED,2022-03-25T05:40:08Z,2022-03-26T08:24:34Z,Prettify rustc_session with recent conveniences,workingjubilee,2882c2023d6e1dee4128611e89fcde0cf6199f6d,9,Auto merge of #95296 - workingjubilee:pretty-session r=Dylan-DPC Prettify rustc_session with recent conveniences No functional changes. I felt like making something beautiful.,HEART,2022-03-26T23:45:13Z,robert-chiniquy,rchiniquy@yahoo.com https://github.com/rust-lang/rust/pull/95296,MERGED,2022-03-25T05:40:08Z,2022-03-26T08:24:34Z,Prettify rustc_session with recent conveniences,workingjubilee,2882c2023d6e1dee4128611e89fcde0cf6199f6d,9,Auto merge of #95296 - workingjubilee:pretty-session r=Dylan-DPC Prettify rustc_session with recent conveniences No functional changes. I felt like making something beautiful.,HEART,2022-03-27T00:08:25Z,maximeborges,contact@maximeborg.es https://github.com/rust-lang/rust/pull/95296,MERGED,2022-03-25T05:40:08Z,2022-03-26T08:24:34Z,Prettify rustc_session with recent conveniences,workingjubilee,2882c2023d6e1dee4128611e89fcde0cf6199f6d,9,Auto merge of #95296 - workingjubilee:pretty-session r=Dylan-DPC Prettify rustc_session with recent conveniences No functional changes. I felt like making something beautiful.,HEART,2022-03-27T07:45:28Z,hdhoang,code@hdhoang.space https://github.com/rust-lang/rust/pull/95302,CLOSED,2022-03-25T11:20:29Z,2022-03-28T06:07:16Z,[DO NOT MERGE] default x64 linux target to x64-v2 for perf test,lqd,NA,NA,NA,EYES,2022-03-25T14:50:38Z,mati865,NA https://github.com/rust-lang/rust/pull/95302,CLOSED,2022-03-25T11:20:29Z,2022-03-28T06:07:16Z,[DO NOT MERGE] default x64 linux target to x64-v2 for perf test,lqd,NA,NA,NA,EYES,2022-03-25T23:30:45Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95302,CLOSED,2022-03-25T11:20:29Z,2022-03-28T06:07:16Z,[DO NOT MERGE] default x64 linux target to x64-v2 for perf test,lqd,NA,NA,NA,EYES,2022-03-26T02:21:45Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/95308,MERGED,2022-03-25T15:20:16Z,2022-04-09T13:15:27Z,Reduce the amount of unstable features used in libproc_macro,bjorn3,e232cb42e692e8bca56fbb98f9a3fbc1de8fbbd8,5,Rollup merge of #95308 - bjorn3:more_stable_proc_macro r=Mark-Simulacrum Reduce the amount of unstable features used in libproc_macro This makes it easier to adapt the source for stable when copying it into rust-analyzer to load rustc compiled proc macros.,HEART,2022-03-25T16:20:41Z,est31,NA https://github.com/rust-lang/rust/pull/95308,MERGED,2022-03-25T15:20:16Z,2022-04-09T13:15:27Z,Reduce the amount of unstable features used in libproc_macro,bjorn3,e232cb42e692e8bca56fbb98f9a3fbc1de8fbbd8,5,Rollup merge of #95308 - bjorn3:more_stable_proc_macro r=Mark-Simulacrum Reduce the amount of unstable features used in libproc_macro This makes it easier to adapt the source for stable when copying it into rust-analyzer to load rustc compiled proc macros.,HEART,2022-03-25T17:04:05Z,jonas-schievink,NA https://github.com/rust-lang/rust/pull/95308,MERGED,2022-03-25T15:20:16Z,2022-04-09T13:15:27Z,Reduce the amount of unstable features used in libproc_macro,bjorn3,e232cb42e692e8bca56fbb98f9a3fbc1de8fbbd8,5,Rollup merge of #95308 - bjorn3:more_stable_proc_macro r=Mark-Simulacrum Reduce the amount of unstable features used in libproc_macro This makes it easier to adapt the source for stable when copying it into rust-analyzer to load rustc compiled proc macros.,HEART,2022-03-25T17:21:07Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/95309,MERGED,2022-03-25T15:32:46Z,2022-05-20T13:18:41Z,rewrite `ensure_drop_params_and_item_params_correspond`,lcnr,512a328e2fb32bddd206461770a2c058368519cc,9,Auto merge of #95309 - lcnr:dropck-cleanup r=nikomatsakis rewrite `ensure_drop_params_and_item_params_correspond` actually relating types here seems like it's overkill,EYES,2022-03-25T21:44:16Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95312,MERGED,2022-03-25T17:28:45Z,2022-04-28T21:58:16Z,Ensure that `'_` and GAT yields errors,marmeladema,d665a5ea4a68a6bc793c267c1a110f01aa946b4f,2,Rollup merge of #95312 - marmeladema:tests-for-issue-95305 r=jackh726 Ensure that `'_` and GAT yields errors Fixes #95305 ```@bors``` r? ```@jackh726```,HEART,2022-03-25T19:09:44Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95317,OPEN,2022-03-25T20:40:24Z,NA,Add `round_ties_even` to `f32` and `f64`,Jules-Bertholet,NA,NA,NA,THUMBS_UP,2022-03-26T10:57:16Z,tjallingt,NA https://github.com/rust-lang/rust/pull/95317,OPEN,2022-03-25T20:40:24Z,NA,Add `round_ties_even` to `f32` and `f64`,Jules-Bertholet,NA,NA,NA,HEART,2022-04-23T12:04:40Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/95317,OPEN,2022-03-25T20:40:24Z,NA,Add `round_ties_even` to `f32` and `f64`,Jules-Bertholet,NA,NA,NA,HEART,2022-05-04T06:55:24Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95317,OPEN,2022-03-25T20:40:24Z,NA,Add `round_ties_even` to `f32` and `f64`,Jules-Bertholet,NA,NA,NA,THUMBS_UP,2022-05-05T15:36:04Z,dsprenkels,daan@dsprenkels.com https://github.com/rust-lang/rust/pull/95317,OPEN,2022-03-25T20:40:24Z,NA,Add `round_ties_even` to `f32` and `f64`,Jules-Bertholet,NA,NA,NA,HEART,2022-05-09T05:37:42Z,golddranks,pyry.kontio@drasa.eu https://github.com/rust-lang/rust/pull/95318,MERGED,2022-03-25T20:54:10Z,2022-03-28T21:08:48Z,diagnostics: correct generic bounds with doubled colon,notriddle,e10d5039bcc5648ae44390968ebc7568ff9db1ac,8,Rollup merge of #95318 - rust-lang:notriddle/issue-95208 r=wesleywiser diagnostics: correct generic bounds with doubled colon Fixes #95208,HEART,2022-03-25T21:13:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95318,MERGED,2022-03-25T20:54:10Z,2022-03-28T21:08:48Z,diagnostics: correct generic bounds with doubled colon,notriddle,e10d5039bcc5648ae44390968ebc7568ff9db1ac,8,Rollup merge of #95318 - rust-lang:notriddle/issue-95208 r=wesleywiser diagnostics: correct generic bounds with doubled colon Fixes #95208,HEART,2022-03-28T15:28:26Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/95318,MERGED,2022-03-25T20:54:10Z,2022-03-28T21:08:48Z,diagnostics: correct generic bounds with doubled colon,notriddle,e10d5039bcc5648ae44390968ebc7568ff9db1ac,8,Rollup merge of #95318 - rust-lang:notriddle/issue-95208 r=wesleywiser diagnostics: correct generic bounds with doubled colon Fixes #95208,HEART,2022-04-01T17:41:39Z,ijackson,ijackson@chiark.greenend.org.uk https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",THUMBS_UP,2022-03-26T00:57:32Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HEART,2022-03-26T00:57:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HOORAY,2022-03-26T00:57:35Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",ROCKET,2022-03-26T00:57:38Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HEART,2022-03-26T02:48:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HEART,2022-03-26T09:24:37Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HEART,2022-03-26T10:44:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95320,MERGED,2022-03-26T00:33:18Z,2022-04-12T13:06:57Z,Document the current MIR semantics that are clear from existing code,JakobDegen,1d3517907727ecd6fea3fc7132c4ae55b2d06958,7,"Rollup merge of #95320 - JakobDegen:mir-docs r=oli-obk Document the current MIR semantics that are clear from existing code This PR adds documentation to places operands rvalues statementkinds and terminatorkinds that describes their existing semantics and requirements. In many places the semantics depend on the Rust memory model or other T-Lang decisions - when this is the case it is just noted as such with links to UCG issues where possible. I'm hopeful that none of the documentation added here can be used to justify optimizations that depend on the memory model. The documentation for places and operands probably comes closest to running afoul of this - if people think that it cannot be merged as is it can definitely also be taken out. The goal here is to only document parts of MIR that seem to be decided already or are at least depended on by existing code. That leaves quite a number of open questions - those are marked as ""needs clarification."" I'm not sure what to do with those in this PR - we obviously can't decide all these questions here. Should I just leave them in as is? Take them out? Keep them in but as `//` instead of `///` comments? If this is too big to review at once I can split this up. r? rust-lang/mir-opt",HEART,2022-07-07T20:45:04Z,pierwill,NA https://github.com/rust-lang/rust/pull/95335,MERGED,2022-03-26T15:51:09Z,2022-03-27T07:01:17Z,Move resolve_path to rustc_builtin_macros and make it private,Badel2,979c8e885edfdac7f16c47a56d538dbb3018c4cb,2,Rollup merge of #95335 - Badel2:resolve-path r=Dylan-DPC Move resolve_path to rustc_builtin_macros and make it private Fixing a FIXME introduced by `@jyn514` in #85457,HEART,2022-03-26T16:38:29Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95337,MERGED,2022-03-26T17:22:55Z,2022-04-05T06:59:54Z,rustdoc: Fix resolution of `crate`-relative paths in doc links,petrochenkov,949b98cab8a186b98bf87e64374b8d0848c55271,6,Auto merge of #95337 - petrochenkov:doclink3 r=camelid rustdoc: Fix resolution of `crate`-relative paths in doc links Resolve `crate::foo` paths transparently to rustdoc so their resolution no longer affects diagnostics and modules used for determining traits in scope. The proper solution is to account for the current `module_id`/`parent_scope` in `fn resolve_crate_root` but it's a slightly larger compiler changes. This PR moves the code closer to it but keeps it rustdoc-specific. Fixes https://github.com/rust-lang/rust/issues/78696 Fixes https://github.com/rust-lang/rust/issues/94924,HEART,2022-03-26T17:27:23Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95337,MERGED,2022-03-26T17:22:55Z,2022-04-05T06:59:54Z,rustdoc: Fix resolution of `crate`-relative paths in doc links,petrochenkov,949b98cab8a186b98bf87e64374b8d0848c55271,6,Auto merge of #95337 - petrochenkov:doclink3 r=camelid rustdoc: Fix resolution of `crate`-relative paths in doc links Resolve `crate::foo` paths transparently to rustdoc so their resolution no longer affects diagnostics and modules used for determining traits in scope. The proper solution is to account for the current `module_id`/`parent_scope` in `fn resolve_crate_root` but it's a slightly larger compiler changes. This PR moves the code closer to it but keeps it rustdoc-specific. Fixes https://github.com/rust-lang/rust/issues/78696 Fixes https://github.com/rust-lang/rust/issues/94924,HEART,2022-03-26T18:38:58Z,pitaj,p.jaszkow@gmail.com https://github.com/rust-lang/rust/pull/95337,MERGED,2022-03-26T17:22:55Z,2022-04-05T06:59:54Z,rustdoc: Fix resolution of `crate`-relative paths in doc links,petrochenkov,949b98cab8a186b98bf87e64374b8d0848c55271,6,Auto merge of #95337 - petrochenkov:doclink3 r=camelid rustdoc: Fix resolution of `crate`-relative paths in doc links Resolve `crate::foo` paths transparently to rustdoc so their resolution no longer affects diagnostics and modules used for determining traits in scope. The proper solution is to account for the current `module_id`/`parent_scope` in `fn resolve_crate_root` but it's a slightly larger compiler changes. This PR moves the code closer to it but keeps it rustdoc-specific. Fixes https://github.com/rust-lang/rust/issues/78696 Fixes https://github.com/rust-lang/rust/issues/94924,HEART,2022-03-27T20:50:56Z,camelid,NA https://github.com/rust-lang/rust/pull/95337,MERGED,2022-03-26T17:22:55Z,2022-04-05T06:59:54Z,rustdoc: Fix resolution of `crate`-relative paths in doc links,petrochenkov,949b98cab8a186b98bf87e64374b8d0848c55271,6,Auto merge of #95337 - petrochenkov:doclink3 r=camelid rustdoc: Fix resolution of `crate`-relative paths in doc links Resolve `crate::foo` paths transparently to rustdoc so their resolution no longer affects diagnostics and modules used for determining traits in scope. The proper solution is to account for the current `module_id`/`parent_scope` in `fn resolve_crate_root` but it's a slightly larger compiler changes. This PR moves the code closer to it but keeps it rustdoc-specific. Fixes https://github.com/rust-lang/rust/issues/78696 Fixes https://github.com/rust-lang/rust/issues/94924,HEART,2022-04-05T09:14:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",EYES,2022-03-26T19:56:55Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-26T21:13:28Z,est31,NA https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-26T21:19:59Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-26T21:38:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-27T00:37:34Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-27T06:14:51Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-03-27T11:36:43Z,bugadani,NA https://github.com/rust-lang/rust/pull/95342,MERGED,2022-03-26T19:56:00Z,2022-04-06T23:32:27Z,"Ignore ""format the world"" commit in git blame",jyn514,86ddbf236e3fa891822cb31d7ca2b0b51f164146,1,"Rollup merge of #95342 - jyn514:ignore-revs r=Mark-Simulacrum Ignore ""format the world"" commit in git blame This tells github to hide it in its blame view: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view It can also be used locally by running `git config blame.ignorerevsfile .git-blame-ignore-revs` (although it's advised to avoid `--global` since git gives a hard error when the file doesn't exist). We may want to add more commits in later PRs but this should be a good start. Before: ![image](https://user-images.githubusercontent.com/23638587/160255130-d7283cc4-4d33-4a7d-bc70-f9ce6820293c.png) After: ![image](https://user-images.githubusercontent.com/23638587/160255138-90d0325a-e063-4e0e-8cfb-732724bf6c60.png) cc https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Hide.20some.20commits.20in.20GitHub.20blame",HEART,2022-04-04T22:17:39Z,camelid,NA https://github.com/rust-lang/rust/pull/95345,MERGED,2022-03-26T21:14:33Z,2022-03-27T18:56:00Z,Debug print char 0 as '\0' rather than '\u{0}',dtolnay,d7aca22e7fd9fdfdc60e30117e54ed479fd7bf7a,5,"Auto merge of #95345 - dtolnay:escape0 r=Dylan-DPC Debug print char 0 as '\0' rather than '\u{0}' ```rust println!(""{:?}"" ""foo\0""); ``` - **Before:** `""foo\u{0}""` - **After:** `""foo\0""` ```rust println!(""{:?}"" '\0'); ``` - **Before:** `'\u{0}'` - **After:** `'\0'` `'\0'` will be more recognizable to everyone than `'\u{0}'` because it's how we talk about character 0 in all of our docs and example code such as https://doc.rust-lang.org/std/ffi/index.html https://doc.rust-lang.org/std/ffi/struct.CStr.html https://doc.rust-lang.org/std/ffi/struct.CString.html.",HEART,2022-03-26T21:37:44Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95345,MERGED,2022-03-26T21:14:33Z,2022-03-27T18:56:00Z,Debug print char 0 as '\0' rather than '\u{0}',dtolnay,d7aca22e7fd9fdfdc60e30117e54ed479fd7bf7a,5,"Auto merge of #95345 - dtolnay:escape0 r=Dylan-DPC Debug print char 0 as '\0' rather than '\u{0}' ```rust println!(""{:?}"" ""foo\0""); ``` - **Before:** `""foo\u{0}""` - **After:** `""foo\0""` ```rust println!(""{:?}"" '\0'); ``` - **Before:** `'\u{0}'` - **After:** `'\0'` `'\0'` will be more recognizable to everyone than `'\u{0}'` because it's how we talk about character 0 in all of our docs and example code such as https://doc.rust-lang.org/std/ffi/index.html https://doc.rust-lang.org/std/ffi/struct.CStr.html https://doc.rust-lang.org/std/ffi/struct.CString.html.",HEART,2022-03-26T21:58:55Z,danielg1111,NA https://github.com/rust-lang/rust/pull/95345,MERGED,2022-03-26T21:14:33Z,2022-03-27T18:56:00Z,Debug print char 0 as '\0' rather than '\u{0}',dtolnay,d7aca22e7fd9fdfdc60e30117e54ed479fd7bf7a,5,"Auto merge of #95345 - dtolnay:escape0 r=Dylan-DPC Debug print char 0 as '\0' rather than '\u{0}' ```rust println!(""{:?}"" ""foo\0""); ``` - **Before:** `""foo\u{0}""` - **After:** `""foo\0""` ```rust println!(""{:?}"" '\0'); ``` - **Before:** `'\u{0}'` - **After:** `'\0'` `'\0'` will be more recognizable to everyone than `'\u{0}'` because it's how we talk about character 0 in all of our docs and example code such as https://doc.rust-lang.org/std/ffi/index.html https://doc.rust-lang.org/std/ffi/struct.CStr.html https://doc.rust-lang.org/std/ffi/struct.CString.html.",THUMBS_UP,2022-03-26T22:15:15Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95345,MERGED,2022-03-26T21:14:33Z,2022-03-27T18:56:00Z,Debug print char 0 as '\0' rather than '\u{0}',dtolnay,d7aca22e7fd9fdfdc60e30117e54ed479fd7bf7a,5,"Auto merge of #95345 - dtolnay:escape0 r=Dylan-DPC Debug print char 0 as '\0' rather than '\u{0}' ```rust println!(""{:?}"" ""foo\0""); ``` - **Before:** `""foo\u{0}""` - **After:** `""foo\0""` ```rust println!(""{:?}"" '\0'); ``` - **Before:** `'\u{0}'` - **After:** `'\0'` `'\0'` will be more recognizable to everyone than `'\u{0}'` because it's how we talk about character 0 in all of our docs and example code such as https://doc.rust-lang.org/std/ffi/index.html https://doc.rust-lang.org/std/ffi/struct.CStr.html https://doc.rust-lang.org/std/ffi/struct.CString.html.",THUMBS_UP,2022-03-27T00:36:32Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95345,MERGED,2022-03-26T21:14:33Z,2022-03-27T18:56:00Z,Debug print char 0 as '\0' rather than '\u{0}',dtolnay,d7aca22e7fd9fdfdc60e30117e54ed479fd7bf7a,5,"Auto merge of #95345 - dtolnay:escape0 r=Dylan-DPC Debug print char 0 as '\0' rather than '\u{0}' ```rust println!(""{:?}"" ""foo\0""); ``` - **Before:** `""foo\u{0}""` - **After:** `""foo\0""` ```rust println!(""{:?}"" '\0'); ``` - **Before:** `'\u{0}'` - **After:** `'\0'` `'\0'` will be more recognizable to everyone than `'\u{0}'` because it's how we talk about character 0 in all of our docs and example code such as https://doc.rust-lang.org/std/ffi/index.html https://doc.rust-lang.org/std/ffi/struct.CStr.html https://doc.rust-lang.org/std/ffi/struct.CString.html.",HEART,2022-03-27T07:49:14Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/95346,MERGED,2022-03-26T22:24:53Z,2022-04-17T03:08:59Z,"Stablize `const_extern_fn` for ""Rust"" and ""C""",Aaron1011,bd334984e217235b2b2089f3008e1d4be79b6deb,4,"Rollup merge of #95346 - Aaron1011:stablize-const-extern-fn r=pnkfelix Stablize `const_extern_fn` for ""Rust"" and ""C"" All other ABIs are left unstable for now. cc #64926",HEART,2022-04-21T03:06:30Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95346,MERGED,2022-03-26T22:24:53Z,2022-04-17T03:08:59Z,"Stablize `const_extern_fn` for ""Rust"" and ""C""",Aaron1011,bd334984e217235b2b2089f3008e1d4be79b6deb,4,"Rollup merge of #95346 - Aaron1011:stablize-const-extern-fn r=pnkfelix Stablize `const_extern_fn` for ""Rust"" and ""C"" All other ABIs are left unstable for now. cc #64926",HEART,2022-06-08T08:40:23Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/95348,CLOSED,2022-03-26T23:33:03Z,2022-03-27T04:24:04Z,Make `#[used]` statics have external linkage,carbotaniuman,NA,NA,NA,ROCKET,2022-03-27T00:23:24Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/95352,MERGED,2022-03-27T03:53:47Z,2022-04-07T07:34:07Z,[bootstrap] Print the full relative path to failed tests,jyn514,f7499a892ea5dde8057fce3f92d4398adf57255d,1,Rollup merge of #95352 - jyn514:full-relative-path r=Mark-Simulacrum [bootstrap] Print the full relative path to failed tests Before: ``` failures: [ui] rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` After: ``` failures: [ui] src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` This allows copy pasting the path or using Ctrl+Click in IDEs to go directly to the file instead of having to edit the filename first.,HEART,2022-03-27T06:14:02Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95352,MERGED,2022-03-27T03:53:47Z,2022-04-07T07:34:07Z,[bootstrap] Print the full relative path to failed tests,jyn514,f7499a892ea5dde8057fce3f92d4398adf57255d,1,Rollup merge of #95352 - jyn514:full-relative-path r=Mark-Simulacrum [bootstrap] Print the full relative path to failed tests Before: ``` failures: [ui] rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` After: ``` failures: [ui] src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` This allows copy pasting the path or using Ctrl+Click in IDEs to go directly to the file instead of having to edit the filename first.,HEART,2022-03-27T08:48:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95352,MERGED,2022-03-27T03:53:47Z,2022-04-07T07:34:07Z,[bootstrap] Print the full relative path to failed tests,jyn514,f7499a892ea5dde8057fce3f92d4398adf57255d,1,Rollup merge of #95352 - jyn514:full-relative-path r=Mark-Simulacrum [bootstrap] Print the full relative path to failed tests Before: ``` failures: [ui] rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` After: ``` failures: [ui] src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.rs test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 163 filtered out; finished in 0.45s ``` This allows copy pasting the path or using Ctrl+Click in IDEs to go directly to the file instead of having to edit the filename first.,HEART,2022-03-27T15:35:18Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95353,MERGED,2022-03-27T04:09:21Z,2022-04-06T23:32:27Z,[bootstrap] Give a hard error when filtering tests for a file that does not exist,jyn514,76cd8f8bf0cb68febbe2c967db1ca4bc6eabf3aa,1,"Rollup merge of #95353 - jyn514:invalid-filter-hard-error r=Mark-Simulacrum [bootstrap] Give a hard error when filtering tests for a file that does not exist A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead. See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest. This is especially bad when using `--bless` which will modify all `.stderr` files. Change bootstrap to require valid filters instead of discarding invalid filters and continuing. Before: ``` Warning: Skipping ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": not a regular file or directory Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu)) running 163 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163 ............................................................... test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s finished in 7.248 seconds Build completed successfully in 0:00:08 ``` After: ``` thread 'main' panicked at 'Invalid test suite filter ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": file or directory does not exist' src/bootstrap/util.rs:311: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Build completed unsuccessfully in 0:00:08 ```",HEART,2022-03-27T04:17:48Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/95353,MERGED,2022-03-27T04:09:21Z,2022-04-06T23:32:27Z,[bootstrap] Give a hard error when filtering tests for a file that does not exist,jyn514,76cd8f8bf0cb68febbe2c967db1ca4bc6eabf3aa,1,"Rollup merge of #95353 - jyn514:invalid-filter-hard-error r=Mark-Simulacrum [bootstrap] Give a hard error when filtering tests for a file that does not exist A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead. See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest. This is especially bad when using `--bless` which will modify all `.stderr` files. Change bootstrap to require valid filters instead of discarding invalid filters and continuing. Before: ``` Warning: Skipping ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": not a regular file or directory Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu)) running 163 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163 ............................................................... test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s finished in 7.248 seconds Build completed successfully in 0:00:08 ``` After: ``` thread 'main' panicked at 'Invalid test suite filter ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": file or directory does not exist' src/bootstrap/util.rs:311: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Build completed unsuccessfully in 0:00:08 ```",HEART,2022-03-27T06:13:50Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95353,MERGED,2022-03-27T04:09:21Z,2022-04-06T23:32:27Z,[bootstrap] Give a hard error when filtering tests for a file that does not exist,jyn514,76cd8f8bf0cb68febbe2c967db1ca4bc6eabf3aa,1,"Rollup merge of #95353 - jyn514:invalid-filter-hard-error r=Mark-Simulacrum [bootstrap] Give a hard error when filtering tests for a file that does not exist A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead. See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest. This is especially bad when using `--bless` which will modify all `.stderr` files. Change bootstrap to require valid filters instead of discarding invalid filters and continuing. Before: ``` Warning: Skipping ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": not a regular file or directory Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu)) running 163 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163 ............................................................... test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s finished in 7.248 seconds Build completed successfully in 0:00:08 ``` After: ``` thread 'main' panicked at 'Invalid test suite filter ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": file or directory does not exist' src/bootstrap/util.rs:311: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Build completed unsuccessfully in 0:00:08 ```",HEART,2022-03-27T08:48:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95353,MERGED,2022-03-27T04:09:21Z,2022-04-06T23:32:27Z,[bootstrap] Give a hard error when filtering tests for a file that does not exist,jyn514,76cd8f8bf0cb68febbe2c967db1ca4bc6eabf3aa,1,"Rollup merge of #95353 - jyn514:invalid-filter-hard-error r=Mark-Simulacrum [bootstrap] Give a hard error when filtering tests for a file that does not exist A common issue people run into when running compiletest is that filtering for files that don't exist is only a warning and not an error; running the whole test suite instead. See for example https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Question.20about.20compiletest. This is especially bad when using `--bless` which will modify all `.stderr` files. Change bootstrap to require valid filters instead of discarding invalid filters and continuing. Before: ``` Warning: Skipping ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": not a regular file or directory Check compiletest suite=rustdoc-ui mode=ui (x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) -> x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu)) running 163 tests iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.......................... 100/163 ............................................................... test result: ok. 89 passed; 0 failed; 74 ignored; 0 measured; 0 filtered out; finished in 7.20s finished in 7.248 seconds Build completed successfully in 0:00:08 ``` After: ``` thread 'main' panicked at 'Invalid test suite filter ""/home/jnelson/rust-lang/rust/src/test/rustdoc-ui/intra-doc/feature-gate-intra-doc-pointers.r"": file or directory does not exist' src/bootstrap/util.rs:311: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Build completed unsuccessfully in 0:00:08 ```",HEART,2022-03-27T14:33:08Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95354,MERGED,2022-03-27T04:11:50Z,2022-04-02T04:59:18Z,Handle rustc_const_stable attribute in library feature collector,dtolnay,d7a24003d865cb3e17f82073c1ba8cbe6e7dea02,21,"Rollup merge of #95354 - dtolnay:rustc_const_stable r=lcnr Handle rustc_const_stable attribute in library feature collector The library feature collector in [compiler/rustc_passes/src/lib_features.rs](https://github.com/rust-lang/rust/blob/551b4fa395fa588d91cbecfb0cdfe1baa02670cf/compiler/rustc_passes/src/lib_features.rs) has only been looking at `#[stable(…)]` `#[unstable(…)]` and `#[rustc_const_unstable(…)]` attributes while ignoring `#[rustc_const_stable(…)]`. The consequences of this were: - When any const feature got stabilized (changing one or more `rustc_const_unstable` to `rustc_const_stable`) users who had previously enabled that unstable feature using `#![feature(…)]` would get told ""unknown feature"" rather than rustc's nicer ""the feature … has been stable since … and no longer requires an attribute to enable"". This can be seen in the way that https://github.com/rust-lang/rust/pull/93957#issuecomment-1079794660 failed after rebase: ```console error[E0635]: unknown feature `const_ptr_offset` --> $DIR/offset_from_ub.rs:1:35 | LL | #![feature(const_ptr_offset_from const_ptr_offset)] | ^^^^^^^^^^^^^^^^ ``` - We weren't enforcing that a particular feature is either stable everywhere or unstable everywhere and that a feature that has been stabilized has the same stabilization version everywhere both of which we enforce for the other stability attributes. This PR updates the library feature collector to handle `rustc_const_stable` and fixes places in the standard library and test suite where `rustc_const_stable` was being used in a way that does not meet the rules for a stability attribute.",HEART,2022-03-27T06:18:57Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95359,MERGED,2022-03-27T07:20:13Z,2022-05-05T19:28:49Z,Update `int_roundings` methods from feedback,jhpratt,47801413d941ac5f4badcd64dc82cb505c8bef1c,14,Rollup merge of #95359 - jhpratt:int_roundings r=joshtriplett Update `int_roundings` methods from feedback This updates `#![feature(int_roundings)]` (#88581) from feedback. All methods now take `NonZeroX`. The documentation makes clear that they panic in debug mode and wrap in release mode. r? `@joshtriplett` `@rustbot` label +T-libs +T-libs-api +S-waiting-on-review,HEART,2022-03-27T08:51:34Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95362,MERGED,2022-03-27T08:05:35Z,2022-05-01T03:18:55Z,Support arrays of zeros in Vec's __rust_alloc_zeroed optimization,scottmcm,bf611439e3239ad3f74bd76cc46a4e89b87d8219,1,Auto merge of #95362 - scottmcm:calloc-arrays r=Mark-Simulacrum Support arrays of zeros in Vec's __rust_alloc_zeroed optimization I happened to notice in https://users.rust-lang.org/t/any-advantage-of-box-u64-16-16-16-over-vec-u64/73500/3?u=scottmcm that the calloc optimization wasn't applying to vectors-of-arrays so here's the easy fix for that.,THUMBS_UP,2022-03-27T08:48:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95362,MERGED,2022-03-27T08:05:35Z,2022-05-01T03:18:55Z,Support arrays of zeros in Vec's __rust_alloc_zeroed optimization,scottmcm,bf611439e3239ad3f74bd76cc46a4e89b87d8219,1,Auto merge of #95362 - scottmcm:calloc-arrays r=Mark-Simulacrum Support arrays of zeros in Vec's __rust_alloc_zeroed optimization I happened to notice in https://users.rust-lang.org/t/any-advantage-of-box-u64-16-16-16-over-vec-u64/73500/3?u=scottmcm that the calloc optimization wasn't applying to vectors-of-arrays so here's the easy fix for that.,THUMBS_UP,2022-05-06T07:58:03Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/95365,MERGED,2022-03-27T12:15:29Z,2022-05-14T08:14:54Z,Use default alloc_error_handler for hermit,mkroening,6c6958b5315961deb569505b97db34abd5d7f392,1,Rollup merge of #95365 - mkroening:hermit-alloc-error-handler r=joshtriplett Use default alloc_error_handler for hermit Hermit now properly separates kernel from userspace. Applications for hermit can now use Rust's default `alloc_error_handler` instead of calling the kernel's `__rg_oom`. CC: ``@stlankes``,THUMBS_UP,2022-03-28T08:15:49Z,stlankes,NA https://github.com/rust-lang/rust/pull/95371,OPEN,2022-03-27T15:45:48Z,NA,Suggest implementing `#[derive(PartialEq)]` for types in vectors and arrays,TaKO8Ki,NA,NA,NA,THUMBS_UP,2022-04-02T21:07:10Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95371,OPEN,2022-03-27T15:45:48Z,NA,Suggest implementing `#[derive(PartialEq)]` for types in vectors and arrays,TaKO8Ki,NA,NA,NA,HEART,2022-04-23T23:53:13Z,estebank,NA https://github.com/rust-lang/rust/pull/95371,OPEN,2022-03-27T15:45:48Z,NA,Suggest implementing `#[derive(PartialEq)]` for types in vectors and arrays,TaKO8Ki,NA,NA,NA,THUMBS_UP,2022-06-20T17:07:50Z,Vurv78,NA https://github.com/rust-lang/rust/pull/95372,MERGED,2022-03-27T16:45:28Z,2022-04-16T11:43:36Z,make unaligned_references lint deny-by-default and make it show up in future-breakage report,RalfJung,49a31cdc1df848e9de07687af5c1d3d6fa5edb66,17,Rollup merge of #95372 - RalfJung:unaligned_references r=oli-obk make unaligned_references lint deny-by-default This lint has been warn-by-default for a year now (since https://github.com/rust-lang/rust/pull/82525) so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed so we really don't want people to write code like this.,THUMBS_UP,2022-03-28T04:57:59Z,estebank,NA https://github.com/rust-lang/rust/pull/95372,MERGED,2022-03-27T16:45:28Z,2022-04-16T11:43:36Z,make unaligned_references lint deny-by-default and make it show up in future-breakage report,RalfJung,49a31cdc1df848e9de07687af5c1d3d6fa5edb66,17,Rollup merge of #95372 - RalfJung:unaligned_references r=oli-obk make unaligned_references lint deny-by-default This lint has been warn-by-default for a year now (since https://github.com/rust-lang/rust/pull/82525) so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed so we really don't want people to write code like this.,THUMBS_UP,2022-04-15T06:06:55Z,taiki-e,NA https://github.com/rust-lang/rust/pull/95372,MERGED,2022-03-27T16:45:28Z,2022-04-16T11:43:36Z,make unaligned_references lint deny-by-default and make it show up in future-breakage report,RalfJung,49a31cdc1df848e9de07687af5c1d3d6fa5edb66,17,Rollup merge of #95372 - RalfJung:unaligned_references r=oli-obk make unaligned_references lint deny-by-default This lint has been warn-by-default for a year now (since https://github.com/rust-lang/rust/pull/82525) so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed so we really don't want people to write code like this.,THUMBS_UP,2022-06-28T09:57:11Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95376,OPEN,2022-03-27T18:30:51Z,NA,Add `vec::Drain{ Filter}::keep_rest`,WaffleLapkin,NA,NA,NA,HEART,2022-03-27T22:07:57Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95376,OPEN,2022-03-27T18:30:51Z,NA,Add `vec::Drain{ Filter}::keep_rest`,WaffleLapkin,NA,NA,NA,HOORAY,2022-03-27T22:08:09Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95376,OPEN,2022-03-27T18:30:51Z,NA,Add `vec::Drain{ Filter}::keep_rest`,WaffleLapkin,NA,NA,NA,HEART,2022-03-28T10:02:20Z,Tamschi,NA https://github.com/rust-lang/rust/pull/95380,MERGED,2022-03-27T20:46:58Z,2022-05-04T01:16:35Z,Fix unit struct/enum variant in destructuring assignment,compiler-errors,1b2e0b60cc5aec81b48835bfc322c426e2f07cd1,4,"Auto merge of #95380 - compiler-errors:unit-destructure-assign r=nikomatsakis Fix unit struct/enum variant in destructuring assignment See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation ""including **unit** and tuple structs"" Fixes #94319",HOORAY,2022-03-27T21:55:06Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95380,MERGED,2022-03-27T20:46:58Z,2022-05-04T01:16:35Z,Fix unit struct/enum variant in destructuring assignment,compiler-errors,1b2e0b60cc5aec81b48835bfc322c426e2f07cd1,4,"Auto merge of #95380 - compiler-errors:unit-destructure-assign r=nikomatsakis Fix unit struct/enum variant in destructuring assignment See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation ""including **unit** and tuple structs"" Fixes #94319",HOORAY,2022-06-30T17:56:06Z,zohnannor,NA https://github.com/rust-lang/rust/pull/95380,MERGED,2022-03-27T20:46:58Z,2022-05-04T01:16:35Z,Fix unit struct/enum variant in destructuring assignment,compiler-errors,1b2e0b60cc5aec81b48835bfc322c426e2f07cd1,4,"Auto merge of #95380 - compiler-errors:unit-destructure-assign r=nikomatsakis Fix unit struct/enum variant in destructuring assignment See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation ""including **unit** and tuple structs"" Fixes #94319",HOORAY,2022-06-30T21:13:18Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95380,MERGED,2022-03-27T20:46:58Z,2022-05-04T01:16:35Z,Fix unit struct/enum variant in destructuring assignment,compiler-errors,1b2e0b60cc5aec81b48835bfc322c426e2f07cd1,4,"Auto merge of #95380 - compiler-errors:unit-destructure-assign r=nikomatsakis Fix unit struct/enum variant in destructuring assignment See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation ""including **unit** and tuple structs"" Fixes #94319",HOORAY,2022-07-01T12:08:42Z,paulip1792,NA https://github.com/rust-lang/rust/pull/95380,MERGED,2022-03-27T20:46:58Z,2022-05-04T01:16:35Z,Fix unit struct/enum variant in destructuring assignment,compiler-errors,1b2e0b60cc5aec81b48835bfc322c426e2f07cd1,4,"Auto merge of #95380 - compiler-errors:unit-destructure-assign r=nikomatsakis Fix unit struct/enum variant in destructuring assignment See https://github.com/rust-lang/rfcs/blob/master/text/2909-destructuring-assignment.md#guide-level-explanation ""including **unit** and tuple structs"" Fixes #94319",HOORAY,2022-07-03T23:07:16Z,HarmoGlace,NA https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,HEART,2022-03-27T22:32:43Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,LAUGH,2022-03-27T22:32:46Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,HEART,2022-03-28T02:10:41Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,CONFUSED,2022-03-28T06:15:36Z,kennytm,NA https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,LAUGH,2022-03-30T11:05:35Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95385,OPEN,2022-03-27T22:25:28Z,NA,Add `mem::conjure_zst` for creating ZSTs out of nothing,scottmcm,NA,NA,NA,LAUGH,2022-04-06T01:36:39Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/95395,MERGED,2022-03-28T02:46:14Z,2022-04-25T00:40:31Z,Better error message for `_` in function signature in `impl Trait for Ty`,compiler-errors,76aa9e5202070731aca982ab5d6922f211afd691,7,Rollup merge of #95395 - compiler-errors:infer-on-impl-for-trait r=oli-obk Better error message for `_` in function signature in `impl Trait for Ty` Provides a replacement suggestion for when `_` is present in the function signature for `impl Trait for Ty` using the substitutions from the trait to compute the exact type. Fixes #95097,HEART,2022-04-23T23:52:51Z,estebank,NA https://github.com/rust-lang/rust/pull/95397,MERGED,2022-03-28T04:10:40Z,2022-03-28T21:08:48Z,Link to std::io's platform-specific behavior disclaimer,dtolnay,4c8bc046b9ca828784cf9d6d48bbabb28c2ec7ec,2,Rollup merge of #95397 - dtolnay:disclaimer r=m-ou-se Link to std::io's platform-specific behavior disclaimer This PR adds some links in standard library documentation to point to https://doc.rust-lang.org/std/io/index.html#platform-specific-behavior. > ### Platform-specific behavior > > Many I/O functions throughout the standard library are documented to indicate what various library or syscalls they are delegated to. This is done to help applications both understand what’s happening under the hood as well as investigate any possibly unclear semantics. Note however that this is informative not a binding contract. The implementation of many of these functions are subject to change over time and may call fewer or more syscalls/library functions. Many of the `std::fs` APIs already link to this disclaimer when discussing system calls.,THUMBS_UP,2022-03-28T07:33:28Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/95399,MERGED,2022-03-28T09:22:31Z,2022-04-12T08:20:13Z,Faster parsing for lower numbers for radix up to 16 (cont.),gilescope,4e1927db3c399fa34dc71992bd5dbec09f945c3d,3,Auto merge of #95399 - gilescope:plan_b r=scottmcm Faster parsing for lower numbers for radix up to 16 (cont.) ( Continuation of https://github.com/rust-lang/rust/pull/83371 ) With LingMan's change I think this is potentially ready.,HOORAY,2022-04-12T09:31:37Z,eopb,NA https://github.com/rust-lang/rust/pull/95399,MERGED,2022-03-28T09:22:31Z,2022-04-12T08:20:13Z,Faster parsing for lower numbers for radix up to 16 (cont.),gilescope,4e1927db3c399fa34dc71992bd5dbec09f945c3d,3,Auto merge of #95399 - gilescope:plan_b r=scottmcm Faster parsing for lower numbers for radix up to 16 (cont.) ( Continuation of https://github.com/rust-lang/rust/pull/83371 ) With LingMan's change I think this is potentially ready.,HOORAY,2022-04-21T03:23:24Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95415,MERGED,2022-03-28T18:57:55Z,2022-03-29T20:29:31Z,diagnostics: regression test for HashMap iter_mut suggestion,notriddle,eceb173de9ee0cad205a139249a4d043fe251e0e,4,Rollup merge of #95415 - notriddle:notriddle/issue-82081 r=Dylan-DPC diagnostics: regression test for HashMap iter_mut suggestion Closes #82081,HEART,2022-03-30T16:06:28Z,estebank,NA https://github.com/rust-lang/rust/pull/95425,MERGED,2022-03-29T06:45:02Z,2022-03-30T21:34:30Z,Yet more `parse_tt` improvements,nnethercote,c5cf08d37b85f953b132951e868df5b924250fdc,3,Auto merge of #95425 - nnethercote:yet-more-parse_tt-improvements r=petrochenkov Yet more `parse_tt` improvements Including lots of comment improvements and an overhaul of how `matches` work that gives big speedups. r? `@petrochenkov`,ROCKET,2022-03-30T07:43:08Z,lqd,NA https://github.com/rust-lang/rust/pull/95425,MERGED,2022-03-29T06:45:02Z,2022-03-30T21:34:30Z,Yet more `parse_tt` improvements,nnethercote,c5cf08d37b85f953b132951e868df5b924250fdc,3,Auto merge of #95425 - nnethercote:yet-more-parse_tt-improvements r=petrochenkov Yet more `parse_tt` improvements Including lots of comment improvements and an overhaul of how `matches` work that gives big speedups. r? `@petrochenkov`,ROCKET,2022-04-07T05:58:22Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95425,MERGED,2022-03-29T06:45:02Z,2022-03-30T21:34:30Z,Yet more `parse_tt` improvements,nnethercote,c5cf08d37b85f953b132951e868df5b924250fdc,3,Auto merge of #95425 - nnethercote:yet-more-parse_tt-improvements r=petrochenkov Yet more `parse_tt` improvements Including lots of comment improvements and an overhaul of how `matches` work that gives big speedups. r? `@petrochenkov`,ROCKET,2022-04-07T15:19:48Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/95425,MERGED,2022-03-29T06:45:02Z,2022-03-30T21:34:30Z,Yet more `parse_tt` improvements,nnethercote,c5cf08d37b85f953b132951e868df5b924250fdc,3,Auto merge of #95425 - nnethercote:yet-more-parse_tt-improvements r=petrochenkov Yet more `parse_tt` improvements Including lots of comment improvements and an overhaul of how `matches` work that gives big speedups. r? `@petrochenkov`,ROCKET,2022-04-07T22:35:27Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95425,MERGED,2022-03-29T06:45:02Z,2022-03-30T21:34:30Z,Yet more `parse_tt` improvements,nnethercote,c5cf08d37b85f953b132951e868df5b924250fdc,3,Auto merge of #95425 - nnethercote:yet-more-parse_tt-improvements r=petrochenkov Yet more `parse_tt` improvements Including lots of comment improvements and an overhaul of how `matches` work that gives big speedups. r? `@petrochenkov`,ROCKET,2022-04-13T11:50:53Z,Patix0331,NA https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-04-04T14:30:28Z,AlexanderEkdahl,NA https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-04-05T20:03:37Z,fosskers,NA https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-04-07T09:57:12Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-04-07T19:59:14Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,THUMBS_UP,2022-04-10T00:01:19Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-06-04T04:30:23Z,nzrq,NA https://github.com/rust-lang/rust/pull/95431,MERGED,2022-03-29T12:48:45Z,2022-04-04T22:32:43Z,Stabilize total_cmp,golddranks,73148eee31b14694272751c6ab52da06af8c7744,4,Rollup merge of #95431 - golddranks:stabilize_total_cmp r=scottmcm Stabilize total_cmp Stabilises `total_cmp` for Rust 1.61.0. Tracking issue: https://github.com/rust-lang/rust/issues/72599,HOORAY,2022-06-16T21:42:38Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:01:06Z,osa1,omeragacan@gmail.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:01:15Z,Lokathor,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:01:18Z,bstrie,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-29T18:01:20Z,Lokathor,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:10:49Z,haraldh,harald@hoyer.xyz https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-29T18:10:51Z,haraldh,harald@hoyer.xyz https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:13:10Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-29T18:24:05Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HEART,2022-03-29T18:38:02Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-29T18:53:40Z,chrysn,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-29T21:48:48Z,Rahix,rahix@rahix.de https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-30T06:53:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T06:53:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T12:46:52Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T12:51:13Z,adamgreig,adam@adamgreig.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-30T19:41:50Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HEART,2022-03-30T19:41:51Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T19:41:52Z,twitchyliquid64,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-30T21:39:54Z,finnbear,finnbearone@gmail.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T21:39:57Z,finnbear,finnbearone@gmail.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-30T22:38:54Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-30T22:39:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-03-31T00:55:43Z,sfackler,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-31T01:09:16Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,HOORAY,2022-03-31T05:50:20Z,taiki-e,NA https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-04-03T19:00:33Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95438,MERGED,2022-03-29T17:47:36Z,2022-04-04T22:32:43Z,Add SyncUnsafeCell.,m-ou-se,4d7d9d422b90c81b9e1ca347a1c139622d950f11,3,Rollup merge of #95438 - m-ou-se:sync-unsafe-cell r=joshtriplett Add SyncUnsafeCell. This adds `SyncUnsafeCell` which is just `UnsafeCell` except it implements `Sync`. This was first proposed under the name `RacyUnsafeCell` here: https://github.com/rust-lang/rust/issues/53639#issuecomment-415515748 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-432741659 and here: https://github.com/rust-lang/rust/issues/53639#issuecomment-888435728 It allows you to create an UnsafeCell that is Sync without having to wrap it in a struct first (and then implement Sync for that struct). E.g. `static X: SyncUnsafeCell`. Using a regular `UnsafeCell` as `static` is not possible because it isn't `Sync`. We have a language workaround for it called `static mut` but it's nice to be able to use the proper type for such unsafety instead. It also makes implementing synchronization primitives based on unsafe cells slightly less verbose because by using `SyncUnsafeCell` for `UnsafeCell`s that are shared between threads you don't need a separate `impl<..> Sync for ..`. Using this type also clearly documents that the cell is expected to be accessed from multiple threads.,THUMBS_UP,2022-04-07T05:46:41Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95469,MERGED,2022-03-30T12:05:13Z,2022-04-06T03:45:40Z,Fix unsound `File` methods,ChrisDenton,26b5e0cbb95ce5b1cbf91d49fb45d122479e3363,3,Auto merge of #95469 - ChrisDenton:unsound-read-write r=joshtriplett Fix unsound `File` methods This is a draft attempt to fix #81357. *EDIT*: this PR now tackles `read()` `write()` `read_at()` `write_at()` and `read_buf`. Still needs more testing though. cc `@jstarks ` can you confirm the the Windows team is ok with the Rust stdlib using `NtReadFile` and `NtWriteFile`? ~Also I'm provisionally using `CancelIo` in a last ditch attempt to recover but I'm not sure that this is actually a good idea. Especially as getting into this state would be a programmer error so aborting the process is justified in any case.~ *EDIT*: removed see comments.,THUMBS_UP,2022-04-14T09:46:26Z,pravic,ehysta@gmail.com https://github.com/rust-lang/rust/pull/95471,MERGED,2022-03-30T13:19:01Z,2022-03-31T07:40:32Z,Don't ICE when opaque types get their hidden type constrained again.,oli-obk,64a3767fee24bfca0534edf596d96659dee68b29,2,Rollup merge of #95471 - oli-obk:tait_ice r=estebank Don't ICE when opaque types get their hidden type constrained again. Contrary to popular belief `codegen_fulfill_obligation` does not get used solely in codegen so we cannot rely on `param_env` being set to RevealAll and thus revealing the hidden types instead of constraining them. Fixes #89312 (for real this time),HEART,2022-03-30T13:31:54Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/95473,MERGED,2022-03-30T13:37:36Z,2022-04-06T01:22:58Z,track individual proc-macro expansions in the self-profiler,lqd,c5e7e952925be74fc7dd6a2fac8e16df9e2044f6,2,Rollup merge of #95473 - lqd:macro-expansion r=petrochenkov track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190) users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally,HEART,2022-03-30T14:16:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95473,MERGED,2022-03-30T13:37:36Z,2022-04-06T01:22:58Z,track individual proc-macro expansions in the self-profiler,lqd,c5e7e952925be74fc7dd6a2fac8e16df9e2044f6,2,Rollup merge of #95473 - lqd:macro-expansion r=petrochenkov track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190) users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally,HEART,2022-03-30T14:48:36Z,ehuss,NA https://github.com/rust-lang/rust/pull/95473,MERGED,2022-03-30T13:37:36Z,2022-04-06T01:22:58Z,track individual proc-macro expansions in the self-profiler,lqd,c5e7e952925be74fc7dd6a2fac8e16df9e2044f6,2,Rollup merge of #95473 - lqd:macro-expansion r=petrochenkov track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190) users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally,HEART,2022-03-30T16:34:22Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95473,MERGED,2022-03-30T13:37:36Z,2022-04-06T01:22:58Z,track individual proc-macro expansions in the self-profiler,lqd,c5e7e952925be74fc7dd6a2fac8e16df9e2044f6,2,Rollup merge of #95473 - lqd:macro-expansion r=petrochenkov track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190) users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally,HEART,2022-03-30T17:48:53Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95474,OPEN,2022-03-30T14:14:13Z,NA,Neither require nor imply lifetime bounds on opaque type for well formedness,oli-obk,NA,NA,NA,THUMBS_UP,2022-05-17T16:09:56Z,estebank,NA https://github.com/rust-lang/rust/pull/95474,OPEN,2022-03-30T14:14:13Z,NA,Neither require nor imply lifetime bounds on opaque type for well formedness,oli-obk,NA,NA,NA,HEART,2022-05-18T16:04:05Z,aliemjay,NA https://github.com/rust-lang/rust/pull/95474,OPEN,2022-03-30T14:14:13Z,NA,Neither require nor imply lifetime bounds on opaque type for well formedness,oli-obk,NA,NA,NA,HOORAY,2022-05-18T16:04:10Z,aliemjay,NA https://github.com/rust-lang/rust/pull/95474,OPEN,2022-03-30T14:14:13Z,NA,Neither require nor imply lifetime bounds on opaque type for well formedness,oli-obk,NA,NA,NA,HEART,2022-06-15T17:32:12Z,estebank,NA https://github.com/rust-lang/rust/pull/95485,CLOSED,2022-03-30T17:49:50Z,2022-05-06T01:58:30Z,Add `Iterator::checked_{sum product}`,aDotInTheVoid,NA,NA,NA,HEART,2022-03-30T17:50:44Z,tarcieri,bascule@gmail.com https://github.com/rust-lang/rust/pull/95491,MERGED,2022-03-30T18:32:34Z,2022-03-31T07:40:31Z,Stabilize feature vec_retain_mut on Vec and VecDeque,faern,c90a94707f19c69a9ef5cecb016e08f771e5b294,2,Rollup merge of #95491 - faern:stabilize-vec_retain_mut r=yaahc Stabilize feature vec_retain_mut on Vec and VecDeque Closes #90829,HEART,2022-03-31T01:15:15Z,archseer,NA https://github.com/rust-lang/rust/pull/95491,MERGED,2022-03-30T18:32:34Z,2022-03-31T07:40:31Z,Stabilize feature vec_retain_mut on Vec and VecDeque,faern,c90a94707f19c69a9ef5cecb016e08f771e5b294,2,Rollup merge of #95491 - faern:stabilize-vec_retain_mut r=yaahc Stabilize feature vec_retain_mut on Vec and VecDeque Closes #90829,HEART,2022-04-07T19:59:00Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95491,MERGED,2022-03-30T18:32:34Z,2022-03-31T07:40:31Z,Stabilize feature vec_retain_mut on Vec and VecDeque,faern,c90a94707f19c69a9ef5cecb016e08f771e5b294,2,Rollup merge of #95491 - faern:stabilize-vec_retain_mut r=yaahc Stabilize feature vec_retain_mut on Vec and VecDeque Closes #90829,THUMBS_UP,2022-04-10T00:01:02Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95491,MERGED,2022-03-30T18:32:34Z,2022-03-31T07:40:31Z,Stabilize feature vec_retain_mut on Vec and VecDeque,faern,c90a94707f19c69a9ef5cecb016e08f771e5b294,2,Rollup merge of #95491 - faern:stabilize-vec_retain_mut r=yaahc Stabilize feature vec_retain_mut on Vec and VecDeque Closes #90829,HEART,2022-05-19T09:27:35Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/95495,MERGED,2022-03-30T19:14:56Z,2022-03-31T15:21:08Z,Remove unneeded `to_string` call,GuillaumeGomez,57206d79d9043bf656ed10018143c5e863306f49,1,Rollup merge of #95495 - GuillaumeGomez:rm-unneeded-to-string r=notriddle Remove unneeded `to_string` call Fixes a confusion I made when reading `@camelid's` comment [here](https://github.com/rust-lang/rust/pull/95096#discussion_r838851170). r? `@notriddle`,THUMBS_UP,2022-03-30T20:48:40Z,camelid,NA https://github.com/rust-lang/rust/pull/95503,MERGED,2022-03-30T22:39:42Z,2022-07-06T01:53:25Z,bootstrap: Allow building individual crates,jyn514,0a7f2c3a025c8bab1e10ccec6208a4c19b057b26,9,Rollup merge of #95503 - jyn514:build-single-crate r=Mark-Simulacrum bootstrap: Allow building individual crates This aims to be as unintrusive as possible but did still require adding a new `tail_args` field to all `Rustc` and `Std` steps. New library and compiler crates are added to the sysroot as they are built since it's useful to have e.g. just alloc and not std. Fixes https://github.com/rust-lang/rust/issues/44293.,HEART,2022-04-07T11:14:06Z,bjorn3,NA https://github.com/rust-lang/rust/pull/95505,MERGED,2022-03-31T01:08:39Z,2022-03-31T15:21:08Z,Fix library/std compilation on openbsd.,sunfishcode,0b71ca84b0e622b370d5e98d307d95052b6245d9,1,Rollup merge of #95505 - sunfishcode:sunfishcode/fix-openbsd r=dtolnay Fix library/std compilation on openbsd. Fix a minor typo from #95241 which prevented compilation on x86_64-unknown-openbsd.,THUMBS_UP,2022-04-01T00:24:27Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",ROCKET,2022-03-31T12:28:31Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-03-31T12:28:35Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",ROCKET,2022-03-31T12:39:28Z,Urgau,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-03-31T12:48:31Z,pitdicker,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-03-31T15:27:18Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-03-31T15:39:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",ROCKET,2022-03-31T15:39:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-04-01T18:19:37Z,estebank,NA https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-04-13T04:24:51Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-04-15T16:35:35Z,araruna,araruna@gmail.com https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HEART,2022-04-16T02:14:07Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HOORAY,2022-04-16T17:14:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",ROCKET,2022-04-16T17:14:52Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/95512,MERGED,2022-03-31T12:21:42Z,2022-04-05T12:11:42Z,diagnostics: translation infrastructure,davidtwco,d4730244d7be72b2c1f0e528bb3c41a91ebdf924,101,"Rollup merge of #95512 - davidtwco:diagnostic-translation r=oli-obk diagnostics: translation infrastructure An implementation of the infrastructure required to have translatable diagnostic messages. - Introduces a `DiagnosticMessage` type which can represent both the current non-translatable messages and identifiers for [Fluent](https://projectfluent.org/). - Modifies current diagnostic API so that existing calls still work but `DiagnosticMessage`s can be provided too. - Adds support for always loading a ""fallback bundle"" containing the English diagnostic messages which are used when a `DiagnosticMessage::FluentIdentifier` is used in a diagnostic being emitted. - Adds support for loading a ""primary bundle"" which contains the user's preferred language translation and is used preferentially when it contains a diagnostic message being emitted. Primary bundles are loaded either from the path provided to `-Ztranslate-alternate-ftl` (for testing) or from the sysroot at `$sysroot/locale/$locale/*.ftl` given a locale with `-Ztranslate-lang` (which is parsed as a language identifier). - Adds ""diagnostic args"" which enable normally-interpolated variables to be made available as variables for Fluent messages to use. - Updates `#[derive(SessionDiagnostic)]` so that it can only be used for translatable diagnostics and update the handful of diagnostics which used the derive to be translatable. For example the following diagnostic... ```rust #[derive(SessionDiagnostic)] #[error = ""E0195""] pub struct LifetimesOrBoundsMismatchOnTrait { #[message = ""lifetime parameters or bounds on {item_kind} `{ident}` do not match the trait declaration""] #[label = ""lifetimes do not match {item_kind} in trait""] pub span: Span #[label = ""lifetimes in impl do not match this {item_kind} in trait""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ...becomes... ```rust #[derive(SessionDiagnostic)] #[error(code = ""E0195"" slug = ""typeck-lifetimes-or-bounds-mismatch-on-trait"")] pub struct LifetimesOrBoundsMismatchOnTrait { #[primary_span] #[label] pub span: Span #[label = ""generics-label""] pub generics_span: Option pub item_kind: &'static str pub ident: Ident } ``` ```fluent typeck-lifetimes-or-bounds-mismatch-on-trait = lifetime parameters or bounds on {$item_kind} `{$ident}` do not match the trait declaration .label = lifetimes do not match {$item_kind} in trait .generics-label = lifetimes in impl do not match this {$item_kind} in trait ``` r? `@estebank` cc `@oli-obk` `@Manishearth`",HEART,2022-04-16T17:14:52Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/95514,CLOSED,2022-03-31T12:55:53Z,2022-04-04T13:36:06Z,Default to running python3 for x.py,djc,NA,NA,NA,HEART,2022-03-31T16:14:24Z,panaman67,NA https://github.com/rust-lang/rust/pull/95525,MERGED,2022-03-31T15:10:11Z,2022-04-05T16:46:19Z,Suggest derivable trait on E0277 error,ohno418,661b0e5b325429db17501bbe79168dc360cabf37,61,Rollup merge of #95525 - ohno418:suggest-derivable-trait-E0277 r=compiler-errors Suggest derivable trait on E0277 error Closes https://github.com/rust-lang/rust/issues/95099 .,HEART,2022-04-05T17:01:34Z,estebank,NA https://github.com/rust-lang/rust/pull/95525,MERGED,2022-03-31T15:10:11Z,2022-04-05T16:46:19Z,Suggest derivable trait on E0277 error,ohno418,661b0e5b325429db17501bbe79168dc360cabf37,61,Rollup merge of #95525 - ohno418:suggest-derivable-trait-E0277 r=compiler-errors Suggest derivable trait on E0277 error Closes https://github.com/rust-lang/rust/issues/95099 .,HEART,2022-04-05T17:47:46Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/95537,MERGED,2022-03-31T19:04:14Z,2022-04-02T14:41:53Z,Improve TyCtxt::type_of documentation,GuillaumeGomez,fbc45b650a9c517ca87b0af8f108efbf50689299,1,Auto merge of #95537 - GuillaumeGomez:type_of-doc r=Dylan-DPC Improve TyCtxt::type_of documentation r? `@oli-obk`,THUMBS_UP,2022-03-31T19:09:29Z,lqd,NA https://github.com/rust-lang/rust/pull/95537,MERGED,2022-03-31T19:04:14Z,2022-04-02T14:41:53Z,Improve TyCtxt::type_of documentation,GuillaumeGomez,fbc45b650a9c517ca87b0af8f108efbf50689299,1,Auto merge of #95537 - GuillaumeGomez:type_of-doc r=Dylan-DPC Improve TyCtxt::type_of documentation r? `@oli-obk`,THUMBS_UP,2022-03-31T19:18:21Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95542,MERGED,2022-03-31T21:06:43Z,2022-05-09T02:25:36Z,Support tool lints with the `#[expect]` attribute (RFC 2383),xFrednet,a57117982aa99f410f6efcba511998c1161adfb8,18,Auto merge of #95542 - xFrednet:rfc-2383-expect-query r=wesleywiser Support tool lints with the `#[expect]` attribute (RFC 2383) This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional. Additionally it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints. The number of changes comes from the long test file. This may look like a monster PR this may smell like a monster PR and this may be a monster PR but it's a harmless monster. :sauropod: --- Closes: https://github.com/rust-lang/rust/issues/94953 cc: https://github.com/rust-lang/rust/issues/85549 r? `@wesleywiser` cc: `@rust-lang/rustdoc`,HEART,2022-03-31T21:27:01Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95542,MERGED,2022-03-31T21:06:43Z,2022-05-09T02:25:36Z,Support tool lints with the `#[expect]` attribute (RFC 2383),xFrednet,a57117982aa99f410f6efcba511998c1161adfb8,18,Auto merge of #95542 - xFrednet:rfc-2383-expect-query r=wesleywiser Support tool lints with the `#[expect]` attribute (RFC 2383) This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional. Additionally it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints. The number of changes comes from the long test file. This may look like a monster PR this may smell like a monster PR and this may be a monster PR but it's a harmless monster. :sauropod: --- Closes: https://github.com/rust-lang/rust/issues/94953 cc: https://github.com/rust-lang/rust/issues/85549 r? `@wesleywiser` cc: `@rust-lang/rustdoc`,HEART,2022-03-31T22:06:53Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/95542,MERGED,2022-03-31T21:06:43Z,2022-05-09T02:25:36Z,Support tool lints with the `#[expect]` attribute (RFC 2383),xFrednet,a57117982aa99f410f6efcba511998c1161adfb8,18,Auto merge of #95542 - xFrednet:rfc-2383-expect-query r=wesleywiser Support tool lints with the `#[expect]` attribute (RFC 2383) This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional. Additionally it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints. The number of changes comes from the long test file. This may look like a monster PR this may smell like a monster PR and this may be a monster PR but it's a harmless monster. :sauropod: --- Closes: https://github.com/rust-lang/rust/issues/94953 cc: https://github.com/rust-lang/rust/issues/85549 r? `@wesleywiser` cc: `@rust-lang/rustdoc`,THUMBS_UP,2022-05-12T01:10:10Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95542,MERGED,2022-03-31T21:06:43Z,2022-05-09T02:25:36Z,Support tool lints with the `#[expect]` attribute (RFC 2383),xFrednet,a57117982aa99f410f6efcba511998c1161adfb8,18,Auto merge of #95542 - xFrednet:rfc-2383-expect-query r=wesleywiser Support tool lints with the `#[expect]` attribute (RFC 2383) This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional. Additionally it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints. The number of changes comes from the long test file. This may look like a monster PR this may smell like a monster PR and this may be a monster PR but it's a harmless monster. :sauropod: --- Closes: https://github.com/rust-lang/rust/issues/94953 cc: https://github.com/rust-lang/rust/issues/85549 r? `@wesleywiser` cc: `@rust-lang/rustdoc`,HEART,2022-05-14T18:05:49Z,Ewpratten,ewpratten@gmail.com https://github.com/rust-lang/rust/pull/95545,OPEN,2022-03-31T23:12:44Z,NA,Build LLVM with support for compression,jonhoo,NA,NA,NA,THUMBS_UP,2022-04-01T14:25:51Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95547,MERGED,2022-04-01T01:18:08Z,2022-04-06T01:22:58Z,caution against ptr-to-int transmutes,RalfJung,e597d06144f356f58cf16a15ac7f21bc0d4d3628,1,Rollup merge of #95547 - RalfJung:ptr-int-transmutes r=scottmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB or they don't round-trip properly or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`,HOORAY,2022-04-01T23:38:24Z,bgeron,bgeron@gmail.com https://github.com/rust-lang/rust/pull/95547,MERGED,2022-04-01T01:18:08Z,2022-04-06T01:22:58Z,caution against ptr-to-int transmutes,RalfJung,e597d06144f356f58cf16a15ac7f21bc0d4d3628,1,Rollup merge of #95547 - RalfJung:ptr-int-transmutes r=scottmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB or they don't round-trip properly or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`,HOORAY,2022-04-02T15:22:16Z,Lokathor,NA https://github.com/rust-lang/rust/pull/95547,MERGED,2022-04-01T01:18:08Z,2022-04-06T01:22:58Z,caution against ptr-to-int transmutes,RalfJung,e597d06144f356f58cf16a15ac7f21bc0d4d3628,1,Rollup merge of #95547 - RalfJung:ptr-int-transmutes r=scottmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB or they don't round-trip properly or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`,HOORAY,2022-04-11T22:28:34Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95547,MERGED,2022-04-01T01:18:08Z,2022-04-06T01:22:58Z,caution against ptr-to-int transmutes,RalfJung,e597d06144f356f58cf16a15ac7f21bc0d4d3628,1,Rollup merge of #95547 - RalfJung:ptr-int-transmutes r=scottmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB or they don't round-trip properly or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`,HEART,2022-04-13T09:25:45Z,iago-lito,NA https://github.com/rust-lang/rust/pull/95547,MERGED,2022-04-01T01:18:08Z,2022-04-06T01:22:58Z,caution against ptr-to-int transmutes,RalfJung,e597d06144f356f58cf16a15ac7f21bc0d4d3628,1,Rollup merge of #95547 - RalfJung:ptr-int-transmutes r=scottmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB or they don't round-trip properly or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`,HOORAY,2022-04-13T10:15:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95548,OPEN,2022-04-01T03:15:27Z,NA,Add fine-grained LLVM CFI support to the Rust compiler,rcvalle,NA,NA,NA,HOORAY,2022-04-01T16:59:06Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95553,MERGED,2022-04-01T05:42:11Z,2022-04-03T23:42:31Z,Don't emit non-asm contents error for naked function composed of errors,jam1garner,19a90c70180d5ba9d825b66773ce0980d7804a36,3,"Rollup merge of #95553 - jam1garner:naked-function-compile-error r=tmiasko Don't emit non-asm contents error for naked function composed of errors ## Motivation For naked functions an error is emitted when they are composed of anything other than a single asm!() block. However this error triggers in a couple situations in which it adds no additional information or is actively misleading. One example is if you do have an asm!() block but simply one with a syntax error: ```rust #[naked] unsafe extern ""C"" fn compiler_errors() { asm!(invalid_syntax) } ``` This results in two errors one for the syntax error itself and another telling you that you need an asm block in your function: ```rust error[E0787]: naked functions must contain a single asm block --> src/main.rs:6:1 | 6 | / unsafe extern ""C"" fn naked_compile_error() { 7 | | asm!(blah) 8 | | } | |_^ ``` This issue also comes up when [utilizing `compile_error!()` for improving your diagnostics](https://twitter.com/steveklabnik/status/1509538243020218372) such as raising a compiler error when compiling for an unsupported target. ## Implementation The rules this PR implements are as follows: 1. If any non-erroneous non-asm statement is included an error will still occur 2. If multiple asm statements are included an error will still occur 3. If 0 or 1 asm statements are present as well as any non-zero number of erroneous statements then this error will *not* be raised as it is likely either redundant or incorrect The rule of thumb is effectively ""if an error is present and its correction could change things don't raise an error"".",HEART,2022-04-01T06:49:48Z,steveklabnik,steve@steveklabnik.com https://github.com/rust-lang/rust/pull/95553,MERGED,2022-04-01T05:42:11Z,2022-04-03T23:42:31Z,Don't emit non-asm contents error for naked function composed of errors,jam1garner,19a90c70180d5ba9d825b66773ce0980d7804a36,3,"Rollup merge of #95553 - jam1garner:naked-function-compile-error r=tmiasko Don't emit non-asm contents error for naked function composed of errors ## Motivation For naked functions an error is emitted when they are composed of anything other than a single asm!() block. However this error triggers in a couple situations in which it adds no additional information or is actively misleading. One example is if you do have an asm!() block but simply one with a syntax error: ```rust #[naked] unsafe extern ""C"" fn compiler_errors() { asm!(invalid_syntax) } ``` This results in two errors one for the syntax error itself and another telling you that you need an asm block in your function: ```rust error[E0787]: naked functions must contain a single asm block --> src/main.rs:6:1 | 6 | / unsafe extern ""C"" fn naked_compile_error() { 7 | | asm!(blah) 8 | | } | |_^ ``` This issue also comes up when [utilizing `compile_error!()` for improving your diagnostics](https://twitter.com/steveklabnik/status/1509538243020218372) such as raising a compiler error when compiling for an unsupported target. ## Implementation The rules this PR implements are as follows: 1. If any non-erroneous non-asm statement is included an error will still occur 2. If multiple asm statements are included an error will still occur 3. If 0 or 1 asm statements are present as well as any non-zero number of erroneous statements then this error will *not* be raised as it is likely either redundant or incorrect The rule of thumb is effectively ""if an error is present and its correction could change things don't raise an error"".",HEART,2022-04-01T08:16:34Z,rrbutani,NA https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-01T07:02:23Z,lqd,NA https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-01T07:10:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-05T14:51:13Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-07T05:42:07Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-07T14:58:21Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-07T22:32:00Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95555,MERGED,2022-04-01T06:54:22Z,2022-04-04T19:51:52Z,A new matcher representation for use in `parse_tt`,nnethercote,6a9080b25e73d26aae94c3f6a13b31de58e66b5a,2,Auto merge of #95555 - nnethercote:parse_tt-new-representation r=petrochenkov A new matcher representation for use in `parse_tt` By transforming the matcher into a different form `parse_tt` can run faster and be easier to understand. r? `@petrochenkov`,HOORAY,2022-04-13T06:04:09Z,Brian-Williams,NA https://github.com/rust-lang/rust/pull/95557,MERGED,2022-04-01T08:46:57Z,2022-04-02T04:59:17Z,Fix `thread_local!` macro to be compatible with `no_implicit_prelude`,niluxv,dc11de63e087542e41c5cb8fa1bc51d550c25b69,2,Rollup merge of #95557 - niluxv:issue-95533 r=dtolnay Fix `thread_local!` macro to be compatible with `no_implicit_prelude` Fixes issue #95533.,THUMBS_UP,2022-04-01T10:06:07Z,Urgau,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-01T16:59:44Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-01T17:39:52Z,marmeladema,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-01T19:30:57Z,ljedrz,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-04-01T21:42:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-04-02T02:15:48Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-02T09:51:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-04-02T09:52:10Z,mati865,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-04-03T18:22:25Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-04-06T16:28:51Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-21T14:59:58Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-04-27T03:51:36Z,panaman67,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-04-28T08:32:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-04-28T08:32:05Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-04-28T08:32:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-04T09:11:56Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-05-04T09:11:57Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-05-04T09:11:57Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-05-04T09:11:58Z,weihanglo,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-17T21:14:18Z,Agrailag,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-27T01:01:37Z,vacuus,rocyu@protonmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-05-27T01:01:42Z,vacuus,rocyu@protonmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-05-27T15:47:32Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-27T15:47:33Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-27T18:02:29Z,lukechu10,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-05-27T18:02:31Z,lukechu10,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-05-27T18:02:32Z,lukechu10,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-05-27T18:02:33Z,lukechu10,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-05-28T07:48:04Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-05-28T07:48:09Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-05-29T01:28:26Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-02T22:34:25Z,tmandry,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-04T16:03:02Z,izik1,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-06-07T05:00:21Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-07T05:00:24Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-07T13:12:18Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-07T13:12:18Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-06-07T13:12:22Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-06-07T13:12:24Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-08T18:02:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-08T18:47:27Z,yerke,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-08T18:47:29Z,yerke,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-06-08T18:47:30Z,yerke,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-06-08T18:47:31Z,yerke,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-08T20:32:06Z,LowLevelVirtualMan,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-08T20:36:26Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-08T20:38:02Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-09T00:24:13Z,rukai,rubickent@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-10T16:20:25Z,IWANABETHATGUY,iwanabethatguy@qq.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-10T16:58:32Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-10T19:00:46Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-10T19:00:47Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-10T19:06:44Z,joshuamegnauth54,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-10T22:54:41Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-06-10T22:54:42Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-10T22:54:42Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-12T15:07:01Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-12T18:33:23Z,iDawer,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-06-12T18:33:30Z,iDawer,NA https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",THUMBS_UP,2022-06-14T12:36:21Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HOORAY,2022-06-14T12:36:21Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",HEART,2022-06-14T12:36:22Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-06-14T12:36:22Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/95565,MERGED,2022-04-01T15:54:04Z,2022-06-07T07:45:10Z,Remove migrate borrowck mode,jackh726,bb55bd449e65e611da928560d948982d73e50027,985,"Auto merge of #95565 - jackh726:remove-borrowck-mode r=nikomatsakis Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors then MIR borrowck (NLL) never occurs. If there *aren't* any errors then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program this should not break any programs. It does however change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta 2022-08-11 => stable). ## Motivation Over time the Rust borrow checker has become ""smarter"" and thus allowed more programs to compile. There have been three different implementations: AST borrowck MIR borrowck and polonius (well in progress). Additionally there is the ""lexical region resolver"" which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017 work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017 for the most part. During 2018 efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into ""migrate"" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019 migrate mode was turned on by default in the 2015 edition as well but with MIR borrowck errors emitted as warnings. By late 2019 these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics) those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously this does not fundamentally change the landscape of accepted programs. However there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)` but not otherwise. There are two notable patterns that are ""fixed"" by this stabilization. First the `scoped_threads` feature which is a continutation of a pre-1.0 API can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second actually seen in the standard library. In the `Extend` impl for `HashMap` there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before there are a large number of diagnostic differences. Most of them are better but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general ""lifetime may not live long enough"" error. While this may *seem* bad the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however on paper they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14 [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20 [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29 [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16 [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20 [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07 [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27 [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22 [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26 [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27 [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)",ROCKET,2022-06-30T18:14:21Z,ndelvalle,nicolas.delvalle@gmail.com https://github.com/rust-lang/rust/pull/95573,MERGED,2022-04-01T21:50:21Z,2022-07-07T20:55:40Z,Make lowering a query,cjgillot,0f573a0c5474ad65bc9f0b0fd3a94d1b06dcfdfa,37,Auto merge of #95573 - cjgillot:lower-query r=michaelwoerister Make lowering a query Split from https://github.com/rust-lang/rust/pull/88186. This PR refactors the relationship between lowering and the resolver outputs in order to make lowering itself a query. In a first part lowering is changed to avoid modifying resolver outputs by maintaining its own data structures for creating new `NodeId`s and so. Then the `TyCtxt` is modified to allow creating new `LocalDefId`s from inside it. This is done by: - enclosing `Definitions` in a lock so as to allow modification; - creating a query `register_def` whose purpose is to declare a `LocalDefId` to the query system. See `TyCtxt::create_def` and `TyCtxt::iter_local_def_id` for more detailed explanations of the design.,HOORAY,2022-04-07T14:56:26Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/95573,MERGED,2022-04-01T21:50:21Z,2022-07-07T20:55:40Z,Make lowering a query,cjgillot,0f573a0c5474ad65bc9f0b0fd3a94d1b06dcfdfa,37,Auto merge of #95573 - cjgillot:lower-query r=michaelwoerister Make lowering a query Split from https://github.com/rust-lang/rust/pull/88186. This PR refactors the relationship between lowering and the resolver outputs in order to make lowering itself a query. In a first part lowering is changed to avoid modifying resolver outputs by maintaining its own data structures for creating new `NodeId`s and so. Then the `TyCtxt` is modified to allow creating new `LocalDefId`s from inside it. This is done by: - enclosing `Definitions` in a lock so as to allow modification; - creating a query `register_def` whose purpose is to declare a `LocalDefId` to the query system. See `TyCtxt::create_def` and `TyCtxt::iter_local_def_id` for more detailed explanations of the design.,HOORAY,2022-06-15T10:42:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-07T11:45:32Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-19T09:09:01Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-19T11:33:43Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-19T12:10:18Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-27T02:31:06Z,exrook,NA https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-04-28T06:37:46Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-05-14T21:41:19Z,cjgillot,NA https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-05-19T08:29:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-05-22T19:07:53Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/95576,MERGED,2022-04-01T22:36:59Z,2022-06-21T13:41:41Z,Remove dereferencing of Box from codegen,DrMeepster,a25b1315ee968146a5b206a8f3c670c5b307ebfe,18,Auto merge of #95576 - DrMeepster:box_erasure r=oli-obk Remove dereferencing of Box from codegen Through #94043 #94414 #94873 and #95328 I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains. Hopefully this is the end of the Box ICEs.,HEART,2022-05-29T17:08:25Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HEART,2022-04-01T23:22:55Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,EYES,2022-04-01T23:31:22Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HOORAY,2022-04-01T23:43:00Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HOORAY,2022-04-02T00:34:46Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HOORAY,2022-04-02T04:27:00Z,pro465,NA https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HOORAY,2022-04-02T09:49:59Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95577,CLOSED,2022-04-01T23:18:59Z,2022-04-03T00:10:54Z,Eliminate borrow checker errors,mark-i-m,NA,NA,NA,HEART,2022-04-02T22:50:20Z,mati865,NA https://github.com/rust-lang/rust/pull/95579,MERGED,2022-04-02T00:44:22Z,2022-04-08T13:22:11Z,Add `<[[T; N]]>::flatten{_mut}`,Cyborus04,d5232c6b93db1d5a95b14838cc2094a000e67b3e,7,Rollup merge of #95579 - Cyborus04:slice_flatten r=scottmcm Add `<[[T; N]]>::flatten{_mut}` Adds `flatten` to convert `&[[T; N]]` to `&[T]` (and `flatten_mut` for `&mut [[T; N]]` to `&mut [T]`),HOORAY,2022-04-14T08:29:31Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95579,MERGED,2022-04-02T00:44:22Z,2022-04-08T13:22:11Z,Add `<[[T; N]]>::flatten{_mut}`,Cyborus04,d5232c6b93db1d5a95b14838cc2094a000e67b3e,7,Rollup merge of #95579 - Cyborus04:slice_flatten r=scottmcm Add `<[[T; N]]>::flatten{_mut}` Adds `flatten` to convert `&[[T; N]]` to `&[T]` (and `flatten_mut` for `&mut [[T; N]]` to `&mut [T]`),HOORAY,2022-04-14T17:17:44Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95579,MERGED,2022-04-02T00:44:22Z,2022-04-08T13:22:11Z,Add `<[[T; N]]>::flatten{_mut}`,Cyborus04,d5232c6b93db1d5a95b14838cc2094a000e67b3e,7,Rollup merge of #95579 - Cyborus04:slice_flatten r=scottmcm Add `<[[T; N]]>::flatten{_mut}` Adds `flatten` to convert `&[[T; N]]` to `&[T]` (and `flatten_mut` for `&mut [[T; N]]` to `&mut [T]`),HOORAY,2022-05-27T17:55:53Z,bluebear94,NA https://github.com/rust-lang/rust/pull/95583,OPEN,2022-04-02T02:03:20Z,NA,Deprecate the unstable `ptr_to_from_bits` feature,scottmcm,NA,NA,NA,THUMBS_UP,2022-04-02T05:08:02Z,MiSawa,NA https://github.com/rust-lang/rust/pull/95583,OPEN,2022-04-02T02:03:20Z,NA,Deprecate the unstable `ptr_to_from_bits` feature,scottmcm,NA,NA,NA,THUMBS_UP,2022-04-02T07:05:11Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/95583,OPEN,2022-04-02T02:03:20Z,NA,Deprecate the unstable `ptr_to_from_bits` feature,scottmcm,NA,NA,NA,THUMBS_UP,2022-04-02T09:01:49Z,Urgau,NA https://github.com/rust-lang/rust/pull/95583,OPEN,2022-04-02T02:03:20Z,NA,Deprecate the unstable `ptr_to_from_bits` feature,scottmcm,NA,NA,NA,THUMBS_UP,2022-04-02T18:57:36Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/95585,MERGED,2022-04-02T07:25:09Z,2022-04-06T01:22:58Z,Explain why `&T` is cloned when `T` is not `Clone`,compiler-errors,42ab448bb443fe792995b4aaf168c5df250a9dac,4,Rollup merge of #95585 - compiler-errors:ref-clone r=estebank Explain why `&T` is cloned when `T` is not `Clone` Fixes #95535,HEART,2022-04-05T16:18:52Z,estebank,NA https://github.com/rust-lang/rust/pull/95588,MERGED,2022-04-02T14:31:49Z,2022-04-05T04:39:29Z,explicitly distinguish pointer::addr and pointer::expose_addr,RalfJung,3bf33b9060065b69f22c50d0ec924eaf51da830a,3,Rollup merge of #95588 - RalfJung:strict-provenance r=scottmcm explicitly distinguish pointer::addr and pointer::expose_addr ``@bgeron`` pointed out that the current docs promise that `ptr.addr()` and `ptr as usize` are equivalent. I don't think that is a promise we want to make. (Conceptually `ptr as usize` might 'escape' the provenance to enable future `usize as ptr` casts but `ptr.addr()` dertainly does not do that.) So I propose we word the docs a bit more carefully here. ``@Gankra`` what do you think?,EYES,2022-04-03T18:27:28Z,EkremDincel,NA https://github.com/rust-lang/rust/pull/95588,MERGED,2022-04-02T14:31:49Z,2022-04-05T04:39:29Z,explicitly distinguish pointer::addr and pointer::expose_addr,RalfJung,3bf33b9060065b69f22c50d0ec924eaf51da830a,3,Rollup merge of #95588 - RalfJung:strict-provenance r=scottmcm explicitly distinguish pointer::addr and pointer::expose_addr ``@bgeron`` pointed out that the current docs promise that `ptr.addr()` and `ptr as usize` are equivalent. I don't think that is a promise we want to make. (Conceptually `ptr as usize` might 'escape' the provenance to enable future `usize as ptr` casts but `ptr.addr()` dertainly does not do that.) So I propose we word the docs a bit more carefully here. ``@Gankra`` what do you think?,EYES,2022-04-03T19:50:55Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/95591,MERGED,2022-04-02T15:40:01Z,2022-04-06T01:22:58Z,Use revisions to track NLL test output (part 1),jackh726,cbf54fad795bc9bce7905b6deb8dfb3bac4f1e2e,111,"Rollup merge of #95591 - jackh726:nll-revisions-1 r=oli-obk Use revisions to track NLL test output (part 1) The idea here is 2 fold: 1) When we eventually do make NLL default on that PR should be systematic in ""delete revisions and corresponding error annotations"" 2) This allows us to look at test NLL outputs in chunks. (Though I've opted here not to ""mark"" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.) The actual review here should be ""easy"" but a bit tedious. I expect we should manually go through each test output and confirm it's okay. The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call rather than just the function name in that call) 2) ""E0308 mismatched types"" -> ""lifetime does not live long enough"" 3) ""E0495 cannot infer an appropriate lifetime for lifetime parameter"" -> ""lifetime does not live long enough"" 4) ""E0312 lifetime of reference outlives lifetime of borrowed content"" -> ""lifetime does not live long enough"" 5) ""E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement"" -> ""lifetime does not live long enough"" 6) ""E0623 lifetime mismatch"" -> ""lifetime does not live long enough"" Other than the now lack of an error code most of these look fine (with most giving more helpful suggestions now). `rfc1623` output isn't great. cc ``@marmeladema`` if you want to look through these Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)",THUMBS_UP,2022-04-02T15:53:51Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/95591,MERGED,2022-04-02T15:40:01Z,2022-04-06T01:22:58Z,Use revisions to track NLL test output (part 1),jackh726,cbf54fad795bc9bce7905b6deb8dfb3bac4f1e2e,111,"Rollup merge of #95591 - jackh726:nll-revisions-1 r=oli-obk Use revisions to track NLL test output (part 1) The idea here is 2 fold: 1) When we eventually do make NLL default on that PR should be systematic in ""delete revisions and corresponding error annotations"" 2) This allows us to look at test NLL outputs in chunks. (Though I've opted here not to ""mark"" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.) The actual review here should be ""easy"" but a bit tedious. I expect we should manually go through each test output and confirm it's okay. The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call rather than just the function name in that call) 2) ""E0308 mismatched types"" -> ""lifetime does not live long enough"" 3) ""E0495 cannot infer an appropriate lifetime for lifetime parameter"" -> ""lifetime does not live long enough"" 4) ""E0312 lifetime of reference outlives lifetime of borrowed content"" -> ""lifetime does not live long enough"" 5) ""E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement"" -> ""lifetime does not live long enough"" 6) ""E0623 lifetime mismatch"" -> ""lifetime does not live long enough"" Other than the now lack of an error code most of these look fine (with most giving more helpful suggestions now). `rfc1623` output isn't great. cc ``@marmeladema`` if you want to look through these Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)",THUMBS_UP,2022-04-02T16:14:34Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/95594,MERGED,2022-04-02T17:32:52Z,2022-06-02T00:55:53Z,Additional `*mut [T]` methods,the8472,3ed9bbe9700f8ea46528dedb9fb242167b01a802,1,Rollup merge of #95594 - the8472:raw_slice_methods r=yaahc Additional `*mut [T]` methods Split out from #94247 This adds the following methods to raw slices that already exist on regular slices * `*mut [T]::is_empty` * `*mut [T]::split_at_mut` * `*mut [T]::split_at_mut_unchecked` These methods reduce the amount of unsafe code needed to migrate `ChunksMut` and related iterators to raw slices (#94247) r? `@m-ou-se`,HEART,2022-04-02T17:45:17Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/95594,MERGED,2022-04-02T17:32:52Z,2022-06-02T00:55:53Z,Additional `*mut [T]` methods,the8472,3ed9bbe9700f8ea46528dedb9fb242167b01a802,1,Rollup merge of #95594 - the8472:raw_slice_methods r=yaahc Additional `*mut [T]` methods Split out from #94247 This adds the following methods to raw slices that already exist on regular slices * `*mut [T]::is_empty` * `*mut [T]::split_at_mut` * `*mut [T]::split_at_mut_unchecked` These methods reduce the amount of unsafe code needed to migrate `ChunksMut` and related iterators to raw slices (#94247) r? `@m-ou-se`,THUMBS_UP,2022-05-11T20:35:38Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/95594,MERGED,2022-04-02T17:32:52Z,2022-06-02T00:55:53Z,Additional `*mut [T]` methods,the8472,3ed9bbe9700f8ea46528dedb9fb242167b01a802,1,Rollup merge of #95594 - the8472:raw_slice_methods r=yaahc Additional `*mut [T]` methods Split out from #94247 This adds the following methods to raw slices that already exist on regular slices * `*mut [T]::is_empty` * `*mut [T]::split_at_mut` * `*mut [T]::split_at_mut_unchecked` These methods reduce the amount of unsafe code needed to migrate `ChunksMut` and related iterators to raw slices (#94247) r? `@m-ou-se`,THUMBS_UP,2022-06-09T08:56:48Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-02T20:16:23Z,LeSeulArtichaut,leseulartichaut@gmail.com https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-03T17:12:13Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-05T22:05:33Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-07T13:49:14Z,ShadowJonathan,jonathandejong02@gmail.com https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-14T09:32:13Z,jplatte,NA https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-14T16:26:40Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-14T20:33:30Z,estebank,NA https://github.com/rust-lang/rust/pull/95599,MERGED,2022-04-02T20:06:01Z,2022-04-09T07:10:37Z,Strict provenance lints,niluxv,525438b6a9161f9c2bf80e495526b8fe10125947,11,Rollup merge of #95599 - niluxv:strict-provenance-lint r=michaelwoerister Strict provenance lints See #95488. This PR introduces two unstable (allow by default) lints to which lint on int2ptr and ptr2int casts as the former is not possible in the strict provenance model and the latter can be written nicer using the `.addr()` API. Based on an initial version of the lint by ```@Gankra``` in #95199.,ROCKET,2022-04-15T08:48:28Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95602,MERGED,2022-04-02T21:30:41Z,2022-05-14T05:53:46Z,Fix `array::IntoIter::fold` to use the optimized `Range::fold`,scottmcm,9fbbe75fd73ed3c202cec3b0ba51eadf506f03fe,4,Auto merge of #95602 - scottmcm:faster-array-intoiter-fold r=the8472 Fix `array::IntoIter::fold` to use the optimized `Range::fold` It was using `Iterator::by_ref` in the implementation which ended up pessimizing it enough that for example it didn't vectorize when we tried it in the conversation. Demonstration that the codegen test doesn't pass on the current nightly: ,THUMBS_UP,2022-04-02T21:33:38Z,miguelraz,miguelraz@ciencias.unam.mx https://github.com/rust-lang/rust/pull/95604,MERGED,2022-04-02T22:03:44Z,2022-04-25T18:59:00Z,Generate synthetic object file to ensure all exported and used symbols participate in the linking,nbdd0121,18b53cefdf7456bf68937b08e377b7e622a115c2,23,Auto merge of #95604 - nbdd0121:used2 r=petrochenkov Generate synthetic object file to ensure all exported and used symbols participate in the linking Fix #50007 and #47384 This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354 allowing all exported and used symbols to be linked while still allowing them to be GCed. Related #93791 #95363 r? `@petrochenkov` cc `@carbotaniuman`,THUMBS_UP,2022-04-20T01:23:44Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/95604,MERGED,2022-04-02T22:03:44Z,2022-04-25T18:59:00Z,Generate synthetic object file to ensure all exported and used symbols participate in the linking,nbdd0121,18b53cefdf7456bf68937b08e377b7e622a115c2,23,Auto merge of #95604 - nbdd0121:used2 r=petrochenkov Generate synthetic object file to ensure all exported and used symbols participate in the linking Fix #50007 and #47384 This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354 allowing all exported and used symbols to be linked while still allowing them to be GCed. Related #93791 #95363 r? `@petrochenkov` cc `@carbotaniuman`,THUMBS_UP,2022-04-26T19:41:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/95604,MERGED,2022-04-02T22:03:44Z,2022-04-25T18:59:00Z,Generate synthetic object file to ensure all exported and used symbols participate in the linking,nbdd0121,18b53cefdf7456bf68937b08e377b7e622a115c2,23,Auto merge of #95604 - nbdd0121:used2 r=petrochenkov Generate synthetic object file to ensure all exported and used symbols participate in the linking Fix #50007 and #47384 This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354 allowing all exported and used symbols to be linked while still allowing them to be GCed. Related #93791 #95363 r? `@petrochenkov` cc `@carbotaniuman`,THUMBS_UP,2022-05-16T20:41:11Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/95604,MERGED,2022-04-02T22:03:44Z,2022-04-25T18:59:00Z,Generate synthetic object file to ensure all exported and used symbols participate in the linking,nbdd0121,18b53cefdf7456bf68937b08e377b7e622a115c2,23,Auto merge of #95604 - nbdd0121:used2 r=petrochenkov Generate synthetic object file to ensure all exported and used symbols participate in the linking Fix #50007 and #47384 This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354 allowing all exported and used symbols to be linked while still allowing them to be GCed. Related #93791 #95363 r? `@petrochenkov` cc `@carbotaniuman`,HOORAY,2022-05-16T20:41:13Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/95604,MERGED,2022-04-02T22:03:44Z,2022-04-25T18:59:00Z,Generate synthetic object file to ensure all exported and used symbols participate in the linking,nbdd0121,18b53cefdf7456bf68937b08e377b7e622a115c2,23,Auto merge of #95604 - nbdd0121:used2 r=petrochenkov Generate synthetic object file to ensure all exported and used symbols participate in the linking Fix #50007 and #47384 This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354 allowing all exported and used symbols to be linked while still allowing them to be GCed. Related #93791 #95363 r? `@petrochenkov` cc `@carbotaniuman`,HOORAY,2022-05-19T08:48:16Z,vallentin,NA https://github.com/rust-lang/rust/pull/95609,MERGED,2022-04-02T23:44:44Z,2022-04-04T22:32:43Z,Suggest borrowing when trying to coerce unsized type into `dyn Trait`,compiler-errors,0c5f8792037e860351ddb7c5cd9e6761d2bba704,5,Rollup merge of #95609 - compiler-errors:borrow-unsized-to-dyn r=nagisa Suggest borrowing when trying to coerce unsized type into `dyn Trait` A helpful error in response to #95598 since we can't coerce e.g. `&str` into `&dyn Display` but we can coerce `&&str` into `&dyn Display` :) Not sure if the suggestion message needs some help. Let me know and I can refine this PR.,THUMBS_UP,2022-04-07T09:00:32Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/95609,MERGED,2022-04-02T23:44:44Z,2022-04-04T22:32:43Z,Suggest borrowing when trying to coerce unsized type into `dyn Trait`,compiler-errors,0c5f8792037e860351ddb7c5cd9e6761d2bba704,5,Rollup merge of #95609 - compiler-errors:borrow-unsized-to-dyn r=nagisa Suggest borrowing when trying to coerce unsized type into `dyn Trait` A helpful error in response to #95598 since we can't coerce e.g. `&str` into `&dyn Display` but we can coerce `&&str` into `&dyn Display` :) Not sure if the suggestion message needs some help. Let me know and I can refine this PR.,HEART,2022-04-23T20:42:10Z,estebank,NA https://github.com/rust-lang/rust/pull/95621,MERGED,2022-04-03T19:57:37Z,2022-04-10T11:16:16Z,Remove ptr-int transmute in std::sync::mpsc,saethlin,7af93292c27cd8b4a14f0f35bcb4c7e7ca9c287a,4,Auto merge of #95621 - saethlin:remove-mpsc-transmute r=RalfJung Remove ptr-int transmute in std::sync::mpsc Since https://github.com/rust-lang/rust/pull/95340 landed Miri with `-Zmiri-check-number-validity` produces an error on the test suites of some crates which implement concurrency tools* because it seems like such crates tend to use `std::sync::mpsc` in their tests. This fixes the problem by storing pointer bytes in a pointer. * I have so far seen errors in the test suites of `once_cell` `parking_lot` and `crossbeam-utils`. (just updating the list for fun idk) Also `threadpool` `async-lock` `futures-timer` `fragile` `scoped_threadpool` `procfs` `slog-async` `scheduled-thread-pool` `tokio-threadpool` `mac` `futures-cpupool` `ntest` `actix` `zbus` `jsonrpc-client-transports` `fail` `libp2p-gossipsub` `parity-send-wrapper` `async-broadcast ` `libp2p-relay` `http-client` `mockito` `simple-mutex` `surf` `pollster` and `pulse`. Then I turned the bot off.,HEART,2022-04-03T20:19:30Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95621,MERGED,2022-04-03T19:57:37Z,2022-04-10T11:16:16Z,Remove ptr-int transmute in std::sync::mpsc,saethlin,7af93292c27cd8b4a14f0f35bcb4c7e7ca9c287a,4,Auto merge of #95621 - saethlin:remove-mpsc-transmute r=RalfJung Remove ptr-int transmute in std::sync::mpsc Since https://github.com/rust-lang/rust/pull/95340 landed Miri with `-Zmiri-check-number-validity` produces an error on the test suites of some crates which implement concurrency tools* because it seems like such crates tend to use `std::sync::mpsc` in their tests. This fixes the problem by storing pointer bytes in a pointer. * I have so far seen errors in the test suites of `once_cell` `parking_lot` and `crossbeam-utils`. (just updating the list for fun idk) Also `threadpool` `async-lock` `futures-timer` `fragile` `scoped_threadpool` `procfs` `slog-async` `scheduled-thread-pool` `tokio-threadpool` `mac` `futures-cpupool` `ntest` `actix` `zbus` `jsonrpc-client-transports` `fail` `libp2p-gossipsub` `parity-send-wrapper` `async-broadcast ` `libp2p-relay` `http-client` `mockito` `simple-mutex` `surf` `pollster` and `pulse`. Then I turned the bot off.,HEART,2022-04-08T13:48:29Z,taiki-e,NA https://github.com/rust-lang/rust/pull/95632,MERGED,2022-04-04T03:47:13Z,2022-06-09T15:39:30Z,impl Read and Write for VecDeque,evanrichter,f14ccdbf6af63a0ee876821f11bd0d982e97818d,1,"Rollup merge of #95632 - evanrichter:master r=joshtriplett impl Read and Write for VecDeque Implementing `Read` and `Write` for `VecDeque` fills in the VecDeque api surface where `Vec` and `Cursor>` already impl Read and Write. Not only for completeness but VecDeque in particular is a very handy mock interface for a TCP echo service if only it supported Read/Write. Since this PR is just an impl trait I don't think there is a way to limit it behind a feature flag so it's ""insta-stable"". Please correct me if I'm wrong here not trying to rush stability.",THUMBS_UP,2022-04-04T22:37:24Z,marmeladema,NA https://github.com/rust-lang/rust/pull/95632,MERGED,2022-04-04T03:47:13Z,2022-06-09T15:39:30Z,impl Read and Write for VecDeque,evanrichter,f14ccdbf6af63a0ee876821f11bd0d982e97818d,1,"Rollup merge of #95632 - evanrichter:master r=joshtriplett impl Read and Write for VecDeque Implementing `Read` and `Write` for `VecDeque` fills in the VecDeque api surface where `Vec` and `Cursor>` already impl Read and Write. Not only for completeness but VecDeque in particular is a very handy mock interface for a TCP echo service if only it supported Read/Write. Since this PR is just an impl trait I don't think there is a way to limit it behind a feature flag so it's ""insta-stable"". Please correct me if I'm wrong here not trying to rush stability.",THUMBS_UP,2022-04-10T22:24:04Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/95632,MERGED,2022-04-04T03:47:13Z,2022-06-09T15:39:30Z,impl Read and Write for VecDeque,evanrichter,f14ccdbf6af63a0ee876821f11bd0d982e97818d,1,"Rollup merge of #95632 - evanrichter:master r=joshtriplett impl Read and Write for VecDeque Implementing `Read` and `Write` for `VecDeque` fills in the VecDeque api surface where `Vec` and `Cursor>` already impl Read and Write. Not only for completeness but VecDeque in particular is a very handy mock interface for a TCP echo service if only it supported Read/Write. Since this PR is just an impl trait I don't think there is a way to limit it behind a feature flag so it's ""insta-stable"". Please correct me if I'm wrong here not trying to rush stability.",THUMBS_UP,2022-05-06T02:03:32Z,alecmocatta,NA https://github.com/rust-lang/rust/pull/95632,MERGED,2022-04-04T03:47:13Z,2022-06-09T15:39:30Z,impl Read and Write for VecDeque,evanrichter,f14ccdbf6af63a0ee876821f11bd0d982e97818d,1,"Rollup merge of #95632 - evanrichter:master r=joshtriplett impl Read and Write for VecDeque Implementing `Read` and `Write` for `VecDeque` fills in the VecDeque api surface where `Vec` and `Cursor>` already impl Read and Write. Not only for completeness but VecDeque in particular is a very handy mock interface for a TCP echo service if only it supported Read/Write. Since this PR is just an impl trait I don't think there is a way to limit it behind a feature flag so it's ""insta-stable"". Please correct me if I'm wrong here not trying to rush stability.",THUMBS_UP,2022-05-06T22:50:40Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/95632,MERGED,2022-04-04T03:47:13Z,2022-06-09T15:39:30Z,impl Read and Write for VecDeque,evanrichter,f14ccdbf6af63a0ee876821f11bd0d982e97818d,1,"Rollup merge of #95632 - evanrichter:master r=joshtriplett impl Read and Write for VecDeque Implementing `Read` and `Write` for `VecDeque` fills in the VecDeque api surface where `Vec` and `Cursor>` already impl Read and Write. Not only for completeness but VecDeque in particular is a very handy mock interface for a TCP echo service if only it supported Read/Write. Since this PR is just an impl trait I don't think there is a way to limit it behind a feature flag so it's ""insta-stable"". Please correct me if I'm wrong here not trying to rush stability.",CONFUSED,2022-05-08T04:58:10Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/95634,MERGED,2022-04-04T04:21:50Z,2022-04-08T13:22:11Z,Mailmap update,dtolnay,7be3084244cf8ad5c924f07a25a87afd4fc04e47,1,"Rollup merge of #95634 - dtolnay:mailmap r=Mark-Simulacrum Mailmap update I noticed there are a lot of contributors who appear multiple times in https://thanks.rust-lang.org/rust/all-time/ which makes their ""rank"" on that page inaccurate. For example Nick Cameron currently appears at rank 21 with 2010 contributions and at rank 27 with 1287 contributions because some of those are from nrc⁠```@ncameron.org``` and some from ncameron⁠```@mozilla.com.``` In reality Nick's rank would be 11 if counted correctly which is a large difference. Solving this in a totally automated way is tricky because it involves figuring out whether Nick is 1 person with multiple emails or is 2 people sharing the same name. This PR addresses a subset of the cases: only where a person has committed under multiple names using the same email. This is still not something that can be totally automated (e.g. by modifying https://github.com/rust-lang/thanks to dedup by email instead of name+email) because: - Some emails are not necessarily unique to one contributor such as `ubuntu@localhost`. - It involves some judgement and mindfulness in picking the ""canonical name"" among the names used with a particular email. This is the name that will appear on thanks.rust-lang.org. Humans change their names sometimes and can be sensitive or picky about the use of names that are no longer preferred. For the purpose of this PR I've tried to stick to the following heuristics which should be unobjectionable: - If one of the names is currently set as the display name on the contributor's GitHub profile prefer that name. - If one of the names is used exclusively over the others in chronologically newer pull requests prefer the newest name. - If one of the names has whitespace and the other doesn't (i.e. is username-like) such as `Foo Bar` vs `FooBar` or `foobar` or `foo-bar123` but otherwise closely resemble one another then prefer the human-like name. - If none of the above suffice in determining a canonical name and the contributor has some other name set on their GitHub profile use the name from the GitHub profile. - If no name on their GitHub profile but the profile links to their personal website which unambiguously identifies their preferred name then use that name. I'm also thinking about how to handle cases like Nick's but that will be a project for a different PR. Basically I'd like to be able to find cases of the same person making commits that differ in name *and* email by looking at all the commits present in pull requests opened by the same GitHub user.
script ```toml [dependencies] anyhow = ""1.0"" git2 = ""0.14"" mailmap = ""0.1"" ``` ```rust use anyhow::{bail Context Result}; use git2::{Commit Oid Repository}; use mailmap::{Author Mailmap}; use std::collections::{BTreeMap as Map BTreeSet as Set}; use std::fmt::{self Debug}; use std::fs; use std::path::Path; const REPO: &str = ""/git/rust""; fn main() -> Result<()> { let repo = Repository::open(REPO)?; let head_oid = repo .head()? .target() .context(""expected head to be a direct reference"")?; let head = repo.find_commit(head_oid)?; let mailmap_path = Path::new(REPO).join("".mailmap""); let mailmap_contents = fs::read_to_string(mailmap_path)?; let mailmap = match Mailmap::from_string(mailmap_contents) { Ok(mailmap) => mailmap Err(box_error) => bail!(""{}"" box_error) }; let mut history = Set::new(); let mut merges = Vec::new(); let mut authors = Set::new(); let mut emails = Map::new(); let mut all_authors = Set::new(); traverse_left(head &mut history &mut merges &mut authors &mailmap)?; while let Some((commit i)) = merges.pop() { let right = commit.parents().nth(i).unwrap(); authors.clear(); traverse_left(right &mut history &mut merges &mut authors &mailmap)?; for author in &authors { all_authors.insert(author.clone()); if !author.email.is_empty() { emails .entry(author.email.clone()) .or_insert_with(Map::new) .entry(author.name.clone()) .or_insert_with(Set::new); } } if let Some(summary) = commit.summary() { if let Some(pr) = parse_summary(summary)? { for author in &authors { if !author.email.is_empty() { emails .get_mut(&author.email) .unwrap() .get_mut(&author.name) .unwrap() .insert(pr); } } } } } for (email names) in emails { if names.len() > 1 { println!(""<{}>"" email); for (name prs) in names { let prs = DebugSet(prs.iter().rev()); println!("" {} {:?}"" name prs); } } } eprintln!(""{} commits"" history.len()); eprintln!(""{} authors"" all_authors.len()); Ok(()) } fn traverse_left<'repo>( mut commit: Commit<'repo> history: &mut Set merges: &mut Vec<(Commit<'repo> usize)> authors: &mut Set mailmap: &Mailmap ) -> Result<()> { loop { let oid = commit.id(); if !history.insert(oid) { return Ok(()); } let author = author(mailmap &commit); let is_bors = author.name == ""bors"" && author.email == ""bors@rust-lang.org""; if !is_bors { authors.insert(author); } let mut parents = commit.parents(); let parent = match parents.next() { Some(parent) => parent None => return Ok(()) }; for i in 1..1 + parents.len() { merges.push((commit.clone() i)); } commit = parent; } } fn parse_summary(summary: &str) -> Result> { let mut rest = None; for prefix in [ ""Auto merge of #"" ""Merge pull request #"" "" Manual merge of #"" ""auto merge of #"" ""auto merge of pull req #"" ""rollup merge of #"" ""Rollup merge of #"" ""Rollup merge of #"" ""Rollup merge of "" ""Merge PR #"" ""Merge #"" ""Merged #"" ] { if summary.starts_with(prefix) { rest = Some(&summary[prefix.len()..]); break; } } let rest = match rest { Some(rest) => rest None => return Ok(None) }; let end = rest.find([' ' ':']).unwrap_or(rest.len()); let number = match rest[..end].parse::() { Ok(number) => number Err(err) => { eprintln!(""{}"" summary); bail!(err); } }; Ok(Some(PullRequest(number))) } fn author(mailmap: &Mailmap commit: &Commit) -> Author { let signature = commit.author(); let name = String::from_utf8_lossy(signature.name_bytes()).into_owned(); let email = String::from_utf8_lossy(signature.email_bytes()).into_owned(); mailmap.canonicalize(&Author { name email }) } #[derive(Copy Clone Ord PartialOrd Eq PartialEq)] struct PullRequest(u32); impl Debug for PullRequest { fn fmt(&self formatter: &mut fmt::Formatter) -> fmt::Result { write!(formatter ""#{}"" self.0) } } struct DebugSet(T); impl Debug for DebugSet where T: Iterator + Clone T::Item: Debug { fn fmt(&self formatter: &mut fmt::Formatter) -> fmt::Result { formatter.debug_set().entries(self.0.clone()).finish() } } ```
",HEART,2022-04-04T15:48:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95635,MERGED,2022-04-04T05:47:50Z,2022-07-08T10:03:40Z,sess: stabilize `-Zterminal-width` as `--diagnostic-width`,davidtwco,b36e58a4589706ff790eb25bbd78f40b1d649431,32,Rollup merge of #95635 - davidtwco:terminal-width-stabilization r=oli-obk sess: stabilize `--terminal-width` as `--diagnostic-width` Formerly `-Zterminal-width` `--terminal-width` allows the user or build tool to inform rustc of the width of the terminal so that diagnostics can be truncated. Pending agreement to stabilize see tracking issue at #84673. r? ```@oli-obk```,HOORAY,2022-07-08T16:04:03Z,estebank,NA https://github.com/rust-lang/rust/pull/95637,CLOSED,2022-04-04T07:40:42Z,2022-04-09T04:58:54Z,EXPERIMENT: derive Debug as a single function call,scottmcm,NA,NA,NA,EYES,2022-04-04T15:24:35Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/95637,CLOSED,2022-04-04T07:40:42Z,2022-04-09T04:58:54Z,EXPERIMENT: derive Debug as a single function call,scottmcm,NA,NA,NA,EYES,2022-04-06T00:04:45Z,Techcable,techcable@techcable.net https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,HOORAY,2022-04-04T13:26:37Z,Gankra,a.beingessner@gmail.com https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,THUMBS_UP,2022-04-04T13:37:50Z,oli-obk,NA https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,HOORAY,2022-04-04T16:05:15Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,THUMBS_UP,2022-04-04T19:45:16Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,HOORAY,2022-04-05T22:16:47Z,arichardson,NA https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,THUMBS_UP,2022-04-05T22:55:16Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,HOORAY,2022-04-09T09:03:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,THUMBS_UP,2022-05-29T00:19:03Z,andylizi,andylizi666@gmail.com https://github.com/rust-lang/rust/pull/95643,MERGED,2022-04-04T11:23:50Z,2022-05-19T01:41:10Z,Add convenience byte offset/check align functions to pointers,WaffleLapkin,d8a3fc4d71bae720cc2534ff5b97164f47622e12,2,Auto merge of #95643 - WaffleLapkin:ptr_convenience r=joshtriplett Add convenience byte offset/check align functions to pointers This PR adds the following APIs: ```rust impl *const T { // feature gates `pointer_byte_offsets` and `const_pointer_byte_offsets pub const unsafe fn byte_offset(self count: isize) -> Self; pub const fn wrapping_byte_offset(self count: isize) -> Self; pub const unsafe fn byte_offset_from(self origin: *const T) -> isize; pub const unsafe fn byte_add(self count: usize) -> Self; pub const unsafe fn byte_sub(self count: usize) -> Self; pub const fn wrapping_byte_add(self count: usize) -> Self; pub const fn wrapping_byte_sub(self count: usize) -> Self; // feature gate `pointer_is_aligned` pub fn is_aligned(self) -> bool where T: Sized; pub fn is_aligned_to(self align: usize) -> bool; } // ... and the same for` *mut T` ``` Note that all functions except `is_aligned` do **not** require `T: Sized` as their pointee-sized-offset counterparts. cc `@oli-obk` (you may want to check that I've correctly placed `const`s) cc `@RalfJung`,THUMBS_UP,2022-06-19T16:40:45Z,Demindiro,david@salt-inc.org https://github.com/rust-lang/rust/pull/95649,MERGED,2022-04-04T16:02:35Z,2022-04-06T23:32:26Z,New mir-opt deref_separator,ouz-a,9fa941c23e18f2e7c838454d95e5526bf15201ed,16,Rollup merge of #95649 - ouz-a:mir-opt r=oli-obk New mir-opt deref_separator This adds a new mir-opt that split certain derefs into this form: `let x = (*a.b).c;` to => `tmp = a.b; let x = (*tmp).c;` Huge thanks to ``@oli-obk`` for his patient mentoring.,HEART,2022-04-04T16:22:46Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95652,CLOSED,2022-04-04T17:53:48Z,2022-05-10T17:49:15Z,AddNicheCases MirPass,mikebenfield,NA,NA,NA,HEART,2022-04-04T19:36:37Z,ogoffart,olivier.goffart@slint-ui.com https://github.com/rust-lang/rust/pull/95652,CLOSED,2022-04-04T17:53:48Z,2022-05-10T17:49:15Z,AddNicheCases MirPass,mikebenfield,NA,NA,NA,HEART,2022-04-19T10:36:35Z,krdln,NA https://github.com/rust-lang/rust/pull/95681,MERGED,2022-04-05T13:57:19Z,2022-04-06T01:22:58Z,resolve: Fix resolution of empty paths passed from rustdoc,petrochenkov,728f2636ac882f8f31130d156278037e941349d7,3,Rollup merge of #95681 - petrochenkov:doclinkregr2 r=Dylan-DPC resolve: Fix resolution of empty paths passed from rustdoc Fixes https://github.com/rust-lang/rust/pull/95337#issuecomment-1088426179,HOORAY,2022-04-05T14:31:31Z,rylev,NA https://github.com/rust-lang/rust/pull/95681,MERGED,2022-04-05T13:57:19Z,2022-04-06T01:22:58Z,resolve: Fix resolution of empty paths passed from rustdoc,petrochenkov,728f2636ac882f8f31130d156278037e941349d7,3,Rollup merge of #95681 - petrochenkov:doclinkregr2 r=Dylan-DPC resolve: Fix resolution of empty paths passed from rustdoc Fixes https://github.com/rust-lang/rust/pull/95337#issuecomment-1088426179,HOORAY,2022-04-05T14:58:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95685,OPEN,2022-04-05T16:30:31Z,NA,"Revert ""Work around invalid DWARF bugs for fat LTO""",cbiffle,NA,NA,NA,THUMBS_UP,2022-04-30T02:16:12Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/95685,OPEN,2022-04-05T16:30:31Z,NA,"Revert ""Work around invalid DWARF bugs for fat LTO""",cbiffle,NA,NA,NA,THUMBS_UP,2022-07-02T19:11:06Z,jmesmon,dev@codyps.com https://github.com/rust-lang/rust/pull/95689,MERGED,2022-04-05T16:47:34Z,2022-04-16T14:24:13Z,Allow self-profiler to only record potentially costly arguments when argument recording is turned on,lqd,febce1fc316f5618d5bb8f05d19e2e3ba868c007,5,Auto merge of #95689 - lqd:self-profiler r=wesleywiser Allow self-profiler to only record potentially costly arguments when argument recording is turned on As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns/near/277304909) with `@wesleywiser ` I'd like to record proc-macro expansions in the self-profiler with some detailed data (per-expansion spans for example to follow #95473). At the same time I'd also like to avoid doing expensive things when tracking a generic activity's arguments if they were not specifically opted into the event filter mask to allow the self-profiler to be used in hotter contexts. This PR tries to offer: - a way to ensure a closure to record arguments will only be called in that situation so that potentially costly arguments can still be recorded when needed. With the additional requirement that if possible it would offer a way to record non-owned data without adding many `generic_activity_with_arg_{...}`-style methods. This lead to the `generic_activity_with_arg_recorder` single entry-point and the closure parameter would offer the new methods able to be executed in a context where costly argument could be created without disturbing the profiled piece of code. - some facilities/patterns allowing to record more rustc specific data in this situation without making `rustc_data_structures` where the self-profiler is defined depend on other rustc crates (causing circular dependencies): in particular spans. They are quite tricky to turn into strings (if the default `Debug` impl output does not match the context one needs them for) and since I'd also like to avoid the allocation there when arg recording is turned off today that has turned into another flexibility requirement for the API in this PR (separating the span-specific recording into an extension trait). **edit**: I've removed this from the PR so that it's easier to review and opened https://github.com/rust-lang/rust/pull/95739. - allow for extensibility in the future: other ways to record arguments or additional data attached to them could be added in the future (e.g. recording the argument's name as well as its data). Some areas where I'd love feedback: - the API and names: the `EventArgRecorder` and its method for example. As well as the verbosity that comes from the increased flexibility. - if I should convert the existing `generic_activity_with_arg{s}` to just forward to `generic_activity_with_arg_recorder` + `recorder.record_arg` (or remove them altogether ? Probably not): I've used the new API in the simple case I could find of allocating for an arg that may not be recorded and the rest don't seem costly. - [x] whether this API should panic if no arguments were recorded by the user-provided closure (like this PR currently does: it seems like an error to use an API dedicated to record arguments but not call the methods to then do so) or if this should just record a generic activity without arguments ? - whether the `record_arg` function should be `#[inline(always)]` like the `generic_activity_*` functions ? As mentioned r? `@wesleywiser` following our recent discussion.,ROCKET,2022-04-05T17:25:26Z,estebank,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-07T19:44:22Z,DianaNites,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-08T03:27:03Z,yerke,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-08T09:53:06Z,mkroening,mkroening@posteo.net https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-08T14:37:33Z,rjzak,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-08T17:06:03Z,npmccallum,nathaniel@mccallum.life https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-08T21:49:35Z,cdmistman,colton@donn.io https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-04-16T13:13:48Z,tema3210,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-06-29T18:02:10Z,a1phyr,NA https://github.com/rust-lang/rust/pull/95705,MERGED,2022-04-05T22:13:18Z,2022-04-08T13:22:11Z,Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts,bstrie,9510d9835550eafff8071c49e08edaac68ca0738,4,Rollup merge of #95705 - bstrie:x86nonetier r=Mark-Simulacrum Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts This implements https://github.com/rust-lang/compiler-team/issues/499 in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.,HOORAY,2022-06-30T21:57:57Z,phip1611,phip1611@gmail.com https://github.com/rust-lang/rust/pull/95723,MERGED,2022-04-06T07:20:53Z,2022-04-06T12:49:18Z,enhance `ConstGoto` mir-opt by moving up `StorageDead` statements,SparrowLii,201cf3dba302cec9b62e9b988858dcad47a88a4f,5,Auto merge of #95723 - SparrowLii:const_goto r=fee1-dead enhance `ConstGoto` mir-opt by moving up `StorageDead` statements From the `FIXME` in the implementation of `ConstGoto` miropt. We can move `StorageDead` statements up to the predecessor. This can expand the scope of application of this opt.,THUMBS_UP,2022-04-07T11:30:37Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/95726,CLOSED,2022-04-06T09:50:50Z,2022-04-13T12:38:18Z,Migrate `symbols` to use declarative macro.,fee1-dead,NA,NA,NA,EYES,2022-04-06T19:10:45Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95727,MERGED,2022-04-06T10:54:00Z,2022-04-13T16:04:10Z,Replace ReentrantMutex by a futex-based one on Linux.,m-ou-se,ab33f71a8be01a93d4d14ee5755beeefe38f1946,4,Auto merge of #95727 - m-ou-se:futex-reentrantmutex r=Amanieu Replace ReentrantMutex by a futex-based one on Linux. Tracking issue: https://github.com/rust-lang/rust/issues/93740 r? `@Amanieu`,HOORAY,2022-04-21T07:22:48Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/95727,MERGED,2022-04-06T10:54:00Z,2022-04-13T16:04:10Z,Replace ReentrantMutex by a futex-based one on Linux.,m-ou-se,ab33f71a8be01a93d4d14ee5755beeefe38f1946,4,Auto merge of #95727 - m-ou-se:futex-reentrantmutex r=Amanieu Replace ReentrantMutex by a futex-based one on Linux. Tracking issue: https://github.com/rust-lang/rust/issues/93740 r? `@Amanieu`,HOORAY,2022-04-24T17:37:51Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95753,MERGED,2022-04-07T04:54:26Z,2022-04-07T12:20:54Z,Correct safety reasoning in `str::make_ascii_{lower upper}case()`,ChayimFriedman2,6639604bd6103107e4d9925332650a360f1f49de,1,Rollup merge of #95753 - ChayimFriedman2:patch-1 r=dtolnay Correct safety reasoning in `str::make_ascii_{lower upper}case()` I don't understand why the previous comment was used (it was inserted in #66564) but it doesn't explain why these functions are safe only why `str::as_bytes{_mut}()` are safe. If someone thinks they make perfect sense I'm fine with closing this PR.,THUMBS_UP,2022-04-07T07:25:32Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/95757,MERGED,2022-04-07T07:54:32Z,2022-04-07T12:20:54Z,Use gender neutral terms,zofrex,d907ab87a08d2cd7f21f9ba1deae6a5e4cc732ff,5,Rollup merge of #95757 - zofrex:gender-neutral-terms r=dtolnay Use gender neutral terms #95508 was not executed well but it did find a couple of legitimate issues: some uses of unnecessarily gendered language and some typos. This PR fixes (properly) the legitimate issues it found.,HEART,2022-04-07T08:41:01Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95757,MERGED,2022-04-07T07:54:32Z,2022-04-07T12:20:54Z,Use gender neutral terms,zofrex,d907ab87a08d2cd7f21f9ba1deae6a5e4cc732ff,5,Rollup merge of #95757 - zofrex:gender-neutral-terms r=dtolnay Use gender neutral terms #95508 was not executed well but it did find a couple of legitimate issues: some uses of unnecessarily gendered language and some typos. This PR fixes (properly) the legitimate issues it found.,HEART,2022-04-07T09:42:53Z,r00ster91,NA https://github.com/rust-lang/rust/pull/95757,MERGED,2022-04-07T07:54:32Z,2022-04-07T12:20:54Z,Use gender neutral terms,zofrex,d907ab87a08d2cd7f21f9ba1deae6a5e4cc732ff,5,Rollup merge of #95757 - zofrex:gender-neutral-terms r=dtolnay Use gender neutral terms #95508 was not executed well but it did find a couple of legitimate issues: some uses of unnecessarily gendered language and some typos. This PR fixes (properly) the legitimate issues it found.,HEART,2022-04-07T09:45:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95757,MERGED,2022-04-07T07:54:32Z,2022-04-07T12:20:54Z,Use gender neutral terms,zofrex,d907ab87a08d2cd7f21f9ba1deae6a5e4cc732ff,5,Rollup merge of #95757 - zofrex:gender-neutral-terms r=dtolnay Use gender neutral terms #95508 was not executed well but it did find a couple of legitimate issues: some uses of unnecessarily gendered language and some typos. This PR fixes (properly) the legitimate issues it found.,HEART,2022-04-07T17:12:56Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/95761,MERGED,2022-04-07T10:16:55Z,2022-04-08T13:22:10Z,Kickstart the inner usage of `macro_metavar_expr`,c410-f3r,1f80881a94f12c457b2e7058047c5c17566e2520,4,Rollup merge of #95761 - c410-f3r:meta-var-stuff r=petrochenkov Kickstart the inner usage of `macro_metavar_expr` There can be more use-cases but I am out of ideas. cc #83527 r? ``@petrochenkov``,THUMBS_UP,2022-04-07T11:47:54Z,fmease,NA https://github.com/rust-lang/rust/pull/95762,CLOSED,2022-04-07T10:38:17Z,2022-04-07T12:52:21Z,Replace RwLock by a futex based one on Linux.,m-ou-se,NA,NA,NA,HEART,2022-04-07T12:43:03Z,the8472,NA https://github.com/rust-lang/rust/pull/95767,MERGED,2022-04-07T13:45:29Z,2022-04-07T21:59:39Z,Report opaque type mismatches directly during borrowck of the function instead of within the `type_of` query.,oli-obk,e745b4ddbd05026c75aae4506aef39fdfe1603c5,5,Auto merge of #95767 - oli-obk:all_your_generics_belong_to_the_definitions r=compiler-errors Report opaque type mismatches directly during borrowck of the function instead of within the `type_of` query. This allows us to only store a single hidden type per opaque type instead of having to store one per set of substitutions. r? `@compiler-errors` This does not affect diagnostics because the diagnostic messages are exactly the same.,HEART,2022-04-07T16:25:43Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95770,MERGED,2022-04-07T15:05:02Z,2022-06-10T06:25:08Z,std::io: Modify some ReadBuf method signatures to return `&mut Self`,nrc,52ee2a2738c957ca6fd54e97b4e090a266ba96ba,1,Auto merge of #95770 - nrc:read-buf-builder r=joshtriplett std::io: Modify some ReadBuf method signatures to return `&mut Self` This allows using `ReadBuf` in a builder-like style and to setup a `ReadBuf` and pass it to `read_buf` in a single expression e.g. ``` // With this PR: reader.read_buf(ReadBuf::uninit(buf).assume_init(init_len))?; // Previously: let mut buf = ReadBuf::uninit(buf); buf.assume_init(init_len); reader.read_buf(&mut buf)?; ``` r? `@sfackler` cc https://github.com/rust-lang/rust/issues/78485 https://github.com/rust-lang/rust/issues/94741,HOORAY,2022-05-03T14:21:29Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/95773,CLOSED,2022-04-07T16:58:16Z,2022-04-28T09:53:00Z,Bubble opaque types into aggregates to produce more precise diagnostics on aggregate constructors,oli-obk,NA,NA,NA,HEART,2022-04-07T18:03:30Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95784,MERGED,2022-04-07T19:55:38Z,2022-04-10T23:26:51Z,Suggest replacing `typeof(...)` with an actual type,WaffleLapkin,54597ba11f73e642797a51f7cdd264613759e693,6,Rollup merge of #95784 - WaffleLapkin:typeof_cool_suggestion r=compiler-errors Suggest replacing `typeof(...)` with an actual type This PR adds suggestion to replace `typeof(...)` with an actual type of `...` for example in case of `typeof(1)` we suggest replacing it with `i32`. If the expression 1. Is not const (`{ let a = 1; let _: typeof(a); }`) 2. Can't be found (`let _: typeof(this_variable_does_not_exist)`) 3. Or has non-suggestable type (closure generator error etc) we don't suggest anything. The 1 one is sad but it's not clear how to support non-consts expressions for `typeof`. _This PR is inspired by [this tweet]._ [this tweet]: https://twitter.com/compiler_errors/status/1511945354752638976,HEART,2022-04-07T20:09:06Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/95784,MERGED,2022-04-07T19:55:38Z,2022-04-10T23:26:51Z,Suggest replacing `typeof(...)` with an actual type,WaffleLapkin,54597ba11f73e642797a51f7cdd264613759e693,6,Rollup merge of #95784 - WaffleLapkin:typeof_cool_suggestion r=compiler-errors Suggest replacing `typeof(...)` with an actual type This PR adds suggestion to replace `typeof(...)` with an actual type of `...` for example in case of `typeof(1)` we suggest replacing it with `i32`. If the expression 1. Is not const (`{ let a = 1; let _: typeof(a); }`) 2. Can't be found (`let _: typeof(this_variable_does_not_exist)`) 3. Or has non-suggestable type (closure generator error etc) we don't suggest anything. The 1 one is sad but it's not clear how to support non-consts expressions for `typeof`. _This PR is inspired by [this tweet]._ [this tweet]: https://twitter.com/compiler_errors/status/1511945354752638976,HEART,2022-04-07T20:17:26Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/95784,MERGED,2022-04-07T19:55:38Z,2022-04-10T23:26:51Z,Suggest replacing `typeof(...)` with an actual type,WaffleLapkin,54597ba11f73e642797a51f7cdd264613759e693,6,Rollup merge of #95784 - WaffleLapkin:typeof_cool_suggestion r=compiler-errors Suggest replacing `typeof(...)` with an actual type This PR adds suggestion to replace `typeof(...)` with an actual type of `...` for example in case of `typeof(1)` we suggest replacing it with `i32`. If the expression 1. Is not const (`{ let a = 1; let _: typeof(a); }`) 2. Can't be found (`let _: typeof(this_variable_does_not_exist)`) 3. Or has non-suggestable type (closure generator error etc) we don't suggest anything. The 1 one is sad but it's not clear how to support non-consts expressions for `typeof`. _This PR is inspired by [this tweet]._ [this tweet]: https://twitter.com/compiler_errors/status/1511945354752638976,HEART,2022-04-08T00:12:49Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/95784,MERGED,2022-04-07T19:55:38Z,2022-04-10T23:26:51Z,Suggest replacing `typeof(...)` with an actual type,WaffleLapkin,54597ba11f73e642797a51f7cdd264613759e693,6,Rollup merge of #95784 - WaffleLapkin:typeof_cool_suggestion r=compiler-errors Suggest replacing `typeof(...)` with an actual type This PR adds suggestion to replace `typeof(...)` with an actual type of `...` for example in case of `typeof(1)` we suggest replacing it with `i32`. If the expression 1. Is not const (`{ let a = 1; let _: typeof(a); }`) 2. Can't be found (`let _: typeof(this_variable_does_not_exist)`) 3. Or has non-suggestable type (closure generator error etc) we don't suggest anything. The 1 one is sad but it's not clear how to support non-consts expressions for `typeof`. _This PR is inspired by [this tweet]._ [this tweet]: https://twitter.com/compiler_errors/status/1511945354752638976,HEART,2022-04-14T08:09:31Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95787,MERGED,2022-04-07T20:46:12Z,2022-04-09T07:10:36Z,reword panic vs result section to remove recoverable vs unrecoverable framing,yaahc,8d7392232cc8e5480c40e5d2789e9172303dfd70,1,Rollup merge of #95787 - yaahc:panic-doc-update-v2 r=dtolnay reword panic vs result section to remove recoverable vs unrecoverable framing Based on feedback from the Error Handling FAQ: https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1090876982 r? ````@dtolnay````,THUMBS_UP,2022-04-07T21:06:42Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/95787,MERGED,2022-04-07T20:46:12Z,2022-04-09T07:10:36Z,reword panic vs result section to remove recoverable vs unrecoverable framing,yaahc,8d7392232cc8e5480c40e5d2789e9172303dfd70,1,Rollup merge of #95787 - yaahc:panic-doc-update-v2 r=dtolnay reword panic vs result section to remove recoverable vs unrecoverable framing Based on feedback from the Error Handling FAQ: https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1090876982 r? ````@dtolnay````,HEART,2022-04-07T21:06:45Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/95787,MERGED,2022-04-07T20:46:12Z,2022-04-09T07:10:36Z,reword panic vs result section to remove recoverable vs unrecoverable framing,yaahc,8d7392232cc8e5480c40e5d2789e9172303dfd70,1,Rollup merge of #95787 - yaahc:panic-doc-update-v2 r=dtolnay reword panic vs result section to remove recoverable vs unrecoverable framing Based on feedback from the Error Handling FAQ: https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1090876982 r? ````@dtolnay````,THUMBS_UP,2022-04-09T16:15:39Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/95788,CLOSED,2022-04-07T21:09:55Z,2022-04-16T01:05:58Z,new companion method to next_code_point() that accepts Iterator,mutantbob,NA,NA,NA,THUMBS_UP,2022-04-11T15:30:16Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,ROCKET,2022-04-09T03:59:24Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,EYES,2022-04-09T03:59:28Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-04-09T08:25:45Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-04-14T22:10:56Z,xd009642,NA https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-04-21T07:26:32Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-04-24T17:37:55Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-04-27T10:10:40Z,gimbles,NA https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-06-30T23:05:07Z,laysakura,lay.sakura@gmail.com https://github.com/rust-lang/rust/pull/95801,MERGED,2022-04-08T12:09:13Z,2022-04-12T00:18:52Z,Replace RwLock by a futex based one on Linux,m-ou-se,a15ac301627b33f87ca6f166b7cdbcc453543ee3,3,Rollup merge of #95801 - m-ou-se:futex-rwlock r=Amanieu Replace RwLock by a futex based one on Linux This replaces the pthread-based RwLock on Linux by a futex based one. This implementation is similar to [the algorithm](https://gist.github.com/kprotty/3042436aa55620d8ebcddf2bf25668bc) suggested by `@kprotty ` but modified to prefer writers and spin before sleeping. It uses two futexes: One for the readers to wait on and one for the writers to wait on. The readers futex contains the state of the RwLock: The number of readers a bit indicating whether writers are waiting and a bit indicating whether readers are waiting. The writers futex is used as a simple condition variable and its contents are meaningless; it just needs to be changed on every notification. Using two futexes rather than one has the obvious advantage of allowing a separate queue for readers and writers but it also means we avoid the problem a single-futex RwLock would have of making it hard for a writer to go to sleep while the number of readers is rapidly changing up and down as the writers futex is only changed when we actually want to wake up a writer. It always prefers writers as we decided [here](https://github.com/rust-lang/rust/issues/93740#issuecomment-1070696128). To be able to prefer writers it relies on futex_wake to return the number of awoken threads to be able to handle write-unlocking while both the readers-waiting and writers-waiting bits are set. Instead of waking both and letting them race it first wakes writers and only continues to wake the readers too if futex_wake reported there were no writers to wake up. r? `@Amanieu`,HOORAY,2022-07-04T01:18:56Z,gallegogt,gallegogt@gmail.com https://github.com/rust-lang/rust/pull/95807,MERGED,2022-04-08T14:19:43Z,2022-04-10T23:26:51Z,Suggest adding a local for vector to fix borrowck errors,TaKO8Ki,c1725448480469fe1cdce0b8d86c85965a91bc90,6,Rollup merge of #95807 - TaKO8Ki:suggest-local-var-for-vector r=fee1-dead Suggest adding a local for vector to fix borrowck errors closes #95574,HEART,2022-04-14T20:41:12Z,estebank,NA https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HOORAY,2022-04-08T19:58:21Z,mati865,NA https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HEART,2022-04-09T03:12:54Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HOORAY,2022-05-13T15:26:33Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HEART,2022-05-31T01:21:55Z,aldanor,NA https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HOORAY,2022-05-31T01:21:55Z,aldanor,NA https://github.com/rust-lang/rust/pull/95818,MERGED,2022-04-08T17:35:31Z,2022-06-10T09:05:58Z,Stabilize the `bundle` native library modifier,petrochenkov,3dea0033f7f40fc3a96b728cb2095da91135f0a4,35,Auto merge of #95818 - petrochenkov:stabundle r=wesleywiser Stabilize the `bundle` native library modifier And remove the legacy `static-nobundle` linking kind. Stabilization report - https://github.com/rust-lang/rust/pull/95818#issuecomment-1120470945. cc #81490 Closes #37403,HOORAY,2022-06-08T18:03:19Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95819,MERGED,2022-04-08T18:10:01Z,2022-04-29T22:27:25Z,Enforce Copy bounds for repeat elements while considering lifetimes,oli-obk,a707f401074bc769bab4efb2bfdde7f6c5a4068d,24,Auto merge of #95819 - oli-obk:mir_can't_hold_all_these_lifetimes r=estebank Enforce Copy bounds for repeat elements while considering lifetimes fixes https://github.com/rust-lang/rust/issues/95477 this is a breaking change in order to fix a soundness bug. Before this PR we only checked whether the repeat element type had an `impl Copy` but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a` then copying any type other than a `'static` one should have been rejected but wasn't. r? `@lcnr`,HOORAY,2022-04-27T01:38:01Z,estebank,NA https://github.com/rust-lang/rust/pull/95819,MERGED,2022-04-08T18:10:01Z,2022-04-29T22:27:25Z,Enforce Copy bounds for repeat elements while considering lifetimes,oli-obk,a707f401074bc769bab4efb2bfdde7f6c5a4068d,24,Auto merge of #95819 - oli-obk:mir_can't_hold_all_these_lifetimes r=estebank Enforce Copy bounds for repeat elements while considering lifetimes fixes https://github.com/rust-lang/rust/issues/95477 this is a breaking change in order to fix a soundness bug. Before this PR we only checked whether the repeat element type had an `impl Copy` but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a` then copying any type other than a `'static` one should have been rejected but wasn't. r? `@lcnr`,HEART,2022-05-05T13:00:37Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T15:38:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T15:56:17Z,ilslv,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T16:20:11Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T16:28:42Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T16:43:34Z,Badel2,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T17:17:18Z,ShadowJonathan,jonathandejong02@gmail.com https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T17:48:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-09T17:56:05Z,adamreichold,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-09T18:37:19Z,jplatte,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-09T19:36:07Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-09T19:36:08Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-10T05:49:23Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-10T06:19:11Z,DianaNites,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-10T06:19:12Z,DianaNites,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-10T11:31:47Z,panstromek,panstromek@seznam.cz https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-10T16:55:52Z,varkor,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-11T06:55:19Z,tema3210,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-11T22:42:11Z,delacian,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,THUMBS_UP,2022-04-12T15:21:03Z,Anders429,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-04-13T02:48:28Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,THUMBS_UP,2022-04-13T02:48:28Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-13T02:48:29Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-17T16:37:11Z,est31,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-04-26T22:39:32Z,estebank,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HOORAY,2022-05-12T17:35:40Z,ruifengx,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-05-12T17:35:42Z,ruifengx,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-05-18T14:45:14Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-06-03T20:44:18Z,bluss,NA https://github.com/rust-lang/rust/pull/95845,CLOSED,2022-04-09T13:21:04Z,2022-07-07T21:31:44Z,TypeId: use a (v0) mangled type to remain sound in the face of hash collisions.,eddyb,NA,NA,NA,HEART,2022-06-05T21:29:31Z,Ltrlg,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-10T05:30:03Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-10T13:58:08Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-10T18:04:59Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-11T02:45:19Z,cynecx,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-11T04:25:35Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-11T08:12:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-11T18:36:14Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-12T19:34:15Z,markbt,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,HOORAY,2022-04-12T19:34:18Z,markbt,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-25T18:53:48Z,megargayu,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,HOORAY,2022-04-25T18:53:49Z,megargayu,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,HOORAY,2022-04-28T20:23:39Z,squili,mia@fig.io https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-04-28T20:23:44Z,squili,mia@fig.io https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-05-06T00:46:17Z,goffrie,goffrie@gmail.com https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_DOWN,2022-06-04T19:48:34Z,fstirlitz,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-06-17T02:21:49Z,MysticalUser,NA https://github.com/rust-lang/rust/pull/95860,MERGED,2022-04-09T18:04:35Z,2022-06-09T15:39:30Z,Stabilize `$$` in Rust 1.63.0,c410-f3r,afa2edbe429467577c98a346323807c3df04a105,4,Rollup merge of #95860 - c410-f3r:stabilize-meta r=joshtriplett Stabilize `$$` in Rust 1.63.0 # Stabilization proposal This PR proposes the stabilization of a subset of `#![feature(macro_metavar_expr)]` or more specifically the stabilization of dollar-dollar (`$$`). Tracking issue: #83527 Version: 1.63 (2022-06-28 => beta 2022-08-11 => stable). ## What is stabilized ```rust macro_rules! foo { () => { macro_rules! bar { ( $$( $$any:tt )* ) => { $$( $$any )* }; } }; } fn main() { foo!(); } ``` ## Motivation For more examples see the [RFC](https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md). Users must currently resort to a tricky and not so well-known hack to declare nested macros with repetitions. ```rust macro_rules! foo { ($dollar:tt) => { macro_rules! bar { ( $dollar ( $any:tt )* ) => { $dollar ( $any )* }; } }; } fn main() { foo!($); } ``` As seen above such hack is fragile and makes work with declarative macros much more unpleasant. Dollar-dollar (`$$`) on the other hand makes nested macros more intuitive. ## What isn't stabilized `count` `ignore` `index` and `length` are not being stabilized due to the lack of consensus. ## History * 2021-02-22 [RFC: Declarative macro metavariable expressions](https://github.com/rust-lang/rfcs/pull/3086) * 2021-03-26 [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) * 2022-02-01 [Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/93545) * 2022-02-25 [[1/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94368) * 2022-03-11 [[2/2] Implement macro meta-variable expressions](https://github.com/rust-lang/rust/pull/94833) * 2022-03-12 [Fix remaining meta-variable expression TODOs](https://github.com/rust-lang/rust/pull/94884) * 2019-03-21 [[macro-metavar-expr] Fix generated tokens hygiene](https://github.com/rust-lang/rust/pull/95188) * 2022-04-07 [Kickstart the inner usage of macro_metavar_expr](https://github.com/rust-lang/rust/pull/95761) * 2022-04-07 [[macro_metavar_expr] Add tests to ensure the feature requirement](https://github.com/rust-lang/rust/pull/95764) ## Non-stabilized expressions https://github.com/rust-lang/rust/issues/83527 lists several concerns about some characteristics of `count` `index` and `length` that effectively make their stabilization unfeasible. `$$` and `ignore` however are not part of any discussion and thus are suitable for stabilization. It is not in the scope of this PR to detail each concern or suggest any possible converging solution. Such thing should be restrained in this tracking issue. ## Tests This list is a subset of https://github.com/rust-lang/rust/tree/master/src/test/ui/macros/rfc-3086-metavar-expr * [Ensures that nested macros have correct behavior](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/dollar-dollar-has-correct-behavior.rs) * [Compares produced tokens to assert expected outputs](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/feature-gate-macro_metavar_expr.rs) * [Checks the declarations of the feature](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/required-feature.rs) * [Verifies all possible errors that can occur due to incorrect user input](https://github.com/rust-lang/rust/blob/master/src/test/ui/macros/rfc-3086-metavar-expr/syntax-errors.rs) ## Possible future work Once consensus is achieved other nightly expressions can be stabilized. Thanks ``@markbt`` for creating the RFC and thanks to ``@petrochenkov`` and ``@mark-i-m`` for reviewing the implementations.,THUMBS_UP,2022-07-08T16:08:20Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-04-10T21:13:18Z,rrbutani,NA https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-04-10T23:03:55Z,ivan,NA https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-04-11T00:41:28Z,funbringer,NA https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-04-11T08:12:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-05-09T06:49:02Z,jorgecarleitao,jorgecarleitao@gmail.com https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-05-19T11:15:14Z,wrazik,wojciech.razik@gmail.com https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-05-19T22:48:32Z,doehyunbaek,NA https://github.com/rust-lang/rust/pull/95864,MERGED,2022-04-09T22:28:49Z,2022-04-12T00:18:51Z,Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction.,luqmana,3f606ceaece4550d3cbf34bb44a9f4372ec9aacb,2,"Rollup merge of #95864 - luqmana:inline-asm-unwind-store-miscompile r=Amanieu Fix miscompilation of inline assembly with outputs in cases where we emit an invoke instead of call instruction. We ran into this bug where rustc would segfault while trying to compile certain uses of inline assembly. Here is a simple repro that demonstrates the issue: ```rust #![feature(asm_unwind)] fn main() { let _x = String::from(""string here just cause we need something with a non-trivial drop""); let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo options(may_unwind) ); } println!(""{}"" foo); } ``` ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7d6641e83370d2536a07234aca2498ff)) But crucially `feature(asm_unwind)` is not actually needed and this can be triggered on stable as a result of the way async functions/generators are handled in the compiler. e.g.: ```rust extern crate futures; // 0.3.21 async fn bar() { let foo: u64; unsafe { std::arch::asm!( ""mov {} 1"" out(reg) foo ); } println!(""{}"" foo); } fn main() { futures::executor::block_on(bar()); } ``` ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1c7781c34dd4a3e80ae4bd936a0c82fc)) An example of the incorrect LLVM generated: ```llvm bb1: ; preds = %start %1 = invoke i64 asm sideeffect alignstack inteldialect unwind ""mov ${0:q} 1"" ""=&r ~{dirflag} ~{fpsr} ~{flags} ~{memory}""() to label %bb2 unwind label %cleanup !srcloc !9 store i64 %1 i64* %foo align 8 bb2: [...snip...] ``` The store should not be placed after the asm invoke but rather should be in the normal control flow basic block (`bb2` in this case). [Here](https://gist.github.com/luqmana/be1af5b64d2cda5a533e3e23a7830b44) is a writeup of the investigation that lead to finding this.",HEART,2022-06-07T11:09:28Z,kaznovac,NA https://github.com/rust-lang/rust/pull/95895,MERGED,2022-04-10T20:05:29Z,2022-04-12T00:18:51Z,Clarify str::from_utf8_unchecked's invariants,CAD97,ae6f75a0c35ae7067015828a6408ccba871ab763,1,"Rollup merge of #95895 - CAD97:patch-2 r=Dylan-DPC Clarify str::from_utf8_unchecked's invariants Specifically make it clear that it is immediately UB to pass ill-formed UTF-8 into the function. The previous wording left space to interpret that the UB only occurred when calling another function which ""assumes that `&str`s are valid UTF-8."" This does not change whether str being UTF-8 is a safety or a validity invariant. (As per previous discussion it is a safety invariant not a validity invariant.) It just makes it clear that valid UTF-8 is a precondition of str::from_utf8_unchecked and that emitting an Abstract Machine fault (e.g. UB or a sanitizer error) on invalid UTF-8 is a valid thing to do. If user code wants to create an unsafe `&str` pointing to ill-formed UTF-8 it must be done via transmutes. Also just don't. Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/str.3A.3Afrom_utf8_unchecked.20Safety.20requirement",THUMBS_UP,2022-04-10T21:09:29Z,RalfJung,NA https://github.com/rust-lang/rust/pull/95895,MERGED,2022-04-10T20:05:29Z,2022-04-12T00:18:51Z,Clarify str::from_utf8_unchecked's invariants,CAD97,ae6f75a0c35ae7067015828a6408ccba871ab763,1,"Rollup merge of #95895 - CAD97:patch-2 r=Dylan-DPC Clarify str::from_utf8_unchecked's invariants Specifically make it clear that it is immediately UB to pass ill-formed UTF-8 into the function. The previous wording left space to interpret that the UB only occurred when calling another function which ""assumes that `&str`s are valid UTF-8."" This does not change whether str being UTF-8 is a safety or a validity invariant. (As per previous discussion it is a safety invariant not a validity invariant.) It just makes it clear that valid UTF-8 is a precondition of str::from_utf8_unchecked and that emitting an Abstract Machine fault (e.g. UB or a sanitizer error) on invalid UTF-8 is a valid thing to do. If user code wants to create an unsafe `&str` pointing to ill-formed UTF-8 it must be done via transmutes. Also just don't. Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/str.3A.3Afrom_utf8_unchecked.20Safety.20requirement",THUMBS_UP,2022-04-11T00:58:58Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95896,MERGED,2022-04-10T20:18:06Z,2022-05-12T17:34:15Z,Note the contacts for the nvptx64 target(s),nagisa,43dabbf485b2aa2bd644580fefcae8a689d2836d,1,Rollup merge of #95896 - nagisa:nvptx-contacts r=Mark-Simulacrum Note the contacts for the nvptx64 target(s) cc `@RDambrosio016` `@kjetilkjeka`,THUMBS_UP,2022-04-10T20:19:47Z,RDambrosio016,rdambrosio016@gmail.com https://github.com/rust-lang/rust/pull/95896,MERGED,2022-04-10T20:18:06Z,2022-05-12T17:34:15Z,Note the contacts for the nvptx64 target(s),nagisa,43dabbf485b2aa2bd644580fefcae8a689d2836d,1,Rollup merge of #95896 - nagisa:nvptx-contacts r=Mark-Simulacrum Note the contacts for the nvptx64 target(s) cc `@RDambrosio016` `@kjetilkjeka`,THUMBS_UP,2022-04-11T14:21:55Z,kjetilkjeka,kjetilkjeka@gmail.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-04-10T23:18:42Z,FenrirWolf,NA https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-04-13T14:21:32Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-04-16T21:13:25Z,ZuseZ4,git@manuel.drehwald.info https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-05-10T18:53:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-05-10T19:44:20Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-05-23T15:16:16Z,Meziu,NA https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-12T12:43:37Z,PotHix,pothix@pothix.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-12T21:23:45Z,ian-h-chamberlain,NA https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-16T00:09:22Z,dasifefe,NA https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-23T06:00:03Z,casey,casey@rodarmor.com https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-23T11:25:44Z,caass,cass@swag.lgbt https://github.com/rust-lang/rust/pull/95897,MERGED,2022-04-10T21:08:17Z,2022-06-15T17:02:21Z,STD support for the Nintendo 3DS,AzureMarker,c3605f8c8020dbbe8f0d1961c7b33c4c4b78ad0d,27,Auto merge of #95897 - AzureMarker:feature/horizon-std r=nagisa STD support for the Nintendo 3DS Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support which will come in a follow-up PR as it requires more complicated changes. This has been a joint effort by `@Meziu ` `@ian-h-chamberlain ` myself and prior work by `@rust3ds` members. ### Background The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA) the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs since they might be considered a trade secret or under NDA. To get around this the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain but in our testing we used the following to fill in the other functions: - [`libctru`] - provides more basic APIs such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys). - [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`]. - [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`]. For more details see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR. ### Notes We've already upstreamed changes to the [`libc`] crate to support this PR as well as the upcoming threading PR. These changes have all been released as of 0.2.121 so we bump the crate version in this PR. Edit: After some rebases the version bump has already been merged so it doesn't appear in this PR. A lot of the changes in this PR are straightforward and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666. The 3DS does not support user space process spawning so these APIs are unimplemented (similar to ESP-IDF). [`libctru`]: https://github.com/devkitPro/libctru [`libc`]: https://github.com/rust-lang/libc,HOORAY,2022-06-24T13:08:39Z,Yuri-M-Dias,NA https://github.com/rust-lang/rust/pull/95904,MERGED,2022-04-10T22:06:47Z,2022-04-28T12:08:31Z,Add VecDeque::extend from vec::IntoIter and slice::Iter specializations,paolobarbolini,3bfeffd55bbc7d653d2df7ad265746bafe595a96,5,Auto merge of #95904 - paolobarbolini:vecdeque-specextend r=the8472 Add VecDeque::extend from vec::IntoIter and slice::Iter specializations Inspired from the [`Vec` `SpecExtend` implementation](https://github.com/rust-lang/rust/blob/027a232755fa9728e9699337267f6675dfd0a8ba/library/alloc/src/vec/spec_extend.rs) but without the specialization for `TrustedLen` which I'll look into in the future. Should help #95632 and https://github.com/KillingSpark/zstd-rs/pull/17 ## Benchmarks Before ``` test vec_deque::bench_extend_bytes ... bench: 862 ns/iter (+/- 10) test vec_deque::bench_extend_vec ... bench: 883 ns/iter (+/- 19) ``` After ``` test vec_deque::bench_extend_bytes ... bench: 8 ns/iter (+/- 0) test vec_deque::bench_extend_vec ... bench: 24 ns/iter (+/- 1) ```,HOORAY,2022-05-05T13:48:23Z,Kerollmops,clement@meilisearch.com https://github.com/rust-lang/rust/pull/95910,MERGED,2022-04-10T23:34:32Z,2022-04-12T13:06:55Z,Fix crate_type attribute to not warn on duplicates,ehuss,1b364ae5d6e09dde5e0cc6b2087d7e8fd64730e1,3,Rollup merge of #95910 - ehuss:fix-crate-type-duplicate r=Dylan-DPC Fix crate_type attribute to not warn on duplicates In #88681 I accidentally marked the `crate_type` attribute as only allowing a single attribute. However multiple attributes are allowed (they are joined together [here](https://github.com/rust-lang/rust/blob/027a232755fa9728e9699337267f6675dfd0a8ba/compiler/rustc_interface/src/util.rs#L530-L542)). This fixes it to not report a warning if duplicates are found. Closes #95902,HEART,2022-04-11T03:36:18Z,gheoan,NA https://github.com/rust-lang/rust/pull/95925,OPEN,2022-04-11T07:22:42Z,NA,Unlimit UNIX `remove_dir_all()` implementation (take 2),hkratz,NA,NA,NA,THUMBS_UP,2022-04-11T10:11:54Z,the8472,NA https://github.com/rust-lang/rust/pull/95925,OPEN,2022-04-11T07:22:42Z,NA,Unlimit UNIX `remove_dir_all()` implementation (take 2),hkratz,NA,NA,NA,THUMBS_UP,2022-04-14T12:20:47Z,ericonr,NA https://github.com/rust-lang/rust/pull/95927,MERGED,2022-04-11T08:05:58Z,2022-04-12T00:18:51Z,CI: do not compile libcore twice when performing LLVM PGO,Kobzol,070e8ed18da9263f3b9aa0950accad7059778ab7,1,Rollup merge of #95927 - Kobzol:ci-pgo-libcore r=lqd CI: do not compile libcore twice when performing LLVM PGO I forgot the delete the first compilation when modifying this file in a previous PR. r? ```@lqd```,HEART,2022-04-11T08:07:53Z,rylev,NA https://github.com/rust-lang/rust/pull/95947,MERGED,2022-04-11T19:17:47Z,2022-04-12T15:33:44Z,`impl const Default for Box<[T]>` and `Box`,cuviper,1d76dd9ee7fd33585f69d8ca799283724725430e,4,Rollup merge of #95947 - cuviper:default-box r=dtolnay `impl const Default for Box<[T]>` and `Box` The unstable `const_default_impls` (#87864) already include empty `Vec` and `String`. Now we extend that concept to `Box<[T]>` and `Box` as well. This obviates a hack in `rustc_ast`'s `P::<[T]>::new`.,HEART,2022-04-12T12:47:05Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/95947,MERGED,2022-04-11T19:17:47Z,2022-04-12T15:33:44Z,`impl const Default for Box<[T]>` and `Box`,cuviper,1d76dd9ee7fd33585f69d8ca799283724725430e,4,Rollup merge of #95947 - cuviper:default-box r=dtolnay `impl const Default for Box<[T]>` and `Box` The unstable `const_default_impls` (#87864) already include empty `Vec` and `String`. Now we extend that concept to `Box<[T]>` and `Box` as well. This obviates a hack in `rustc_ast`'s `P::<[T]>::new`.,HEART,2022-04-21T03:29:05Z,GrayJack,NA https://github.com/rust-lang/rust/pull/95947,MERGED,2022-04-11T19:17:47Z,2022-04-12T15:33:44Z,`impl const Default for Box<[T]>` and `Box`,cuviper,1d76dd9ee7fd33585f69d8ca799283724725430e,4,Rollup merge of #95947 - cuviper:default-box r=dtolnay `impl const Default for Box<[T]>` and `Box` The unstable `const_default_impls` (#87864) already include empty `Vec` and `String`. Now we extend that concept to `Box<[T]>` and `Box` as well. This obviates a hack in `rustc_ast`'s `P::<[T]>::new`.,HEART,2022-04-24T17:50:08Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95960,MERGED,2022-04-12T01:53:32Z,2022-05-09T07:05:21Z,Remove `#[rustc_deprecated]`,jhpratt,8a2fe75d0e6e024aa434e5b9c40adb2567f362b8,98,Auto merge of #95960 - jhpratt:remove-rustc_deprecated r=compiler-errors Remove `#[rustc_deprecated]` This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958 which includes converting `stdarch`. I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics as they're only intended to be short-term.,THUMBS_UP,2022-06-09T13:47:46Z,hellow554,ghpub@cookiesoft.de https://github.com/rust-lang/rust/pull/95962,MERGED,2022-04-12T02:01:54Z,2022-04-13T18:25:24Z,Document that DirEntry holds the directory open,sourcefrog,032358bd30d2eaa31cdec4a40d8a4703fbec22cc,1,Rollup merge of #95962 - sourcefrog:doc-direntry r=Dylan-DPC Document that DirEntry holds the directory open I had a bug where holding onto DirEntry structs caused file descriptor exhaustion and thought it would be good to document this.,THUMBS_UP,2022-04-13T08:59:08Z,hkratz,NA https://github.com/rust-lang/rust/pull/95968,MERGED,2022-04-12T08:49:09Z,2022-04-13T23:18:37Z,errors: lazily load fallback fluent bundle,davidtwco,34a6c9f26e2ce32cad0d71f5e342365b09f4d12c,19,Auto merge of #95968 - davidtwco:translation-lazy-fallback r=oli-obk errors: lazily load fallback fluent bundle Addresses (hopefully) https://github.com/rust-lang/rust/pull/95667#issuecomment-1094794087. Loading the fallback bundle in compilation sessions that won't go on to emit any errors unnecessarily degrades compile time performance so lazily create the Fluent bundle when it is first required. r? `@ghost` (just for perf initially),HEART,2022-04-12T10:29:09Z,lqd,NA https://github.com/rust-lang/rust/pull/95968,MERGED,2022-04-12T08:49:09Z,2022-04-13T23:18:37Z,errors: lazily load fallback fluent bundle,davidtwco,34a6c9f26e2ce32cad0d71f5e342365b09f4d12c,19,Auto merge of #95968 - davidtwco:translation-lazy-fallback r=oli-obk errors: lazily load fallback fluent bundle Addresses (hopefully) https://github.com/rust-lang/rust/pull/95667#issuecomment-1094794087. Loading the fallback bundle in compilation sessions that won't go on to emit any errors unnecessarily degrades compile time performance so lazily create the Fluent bundle when it is first required. r? `@ghost` (just for perf initially),HEART,2022-04-12T21:43:15Z,nnethercote,NA https://github.com/rust-lang/rust/pull/95968,MERGED,2022-04-12T08:49:09Z,2022-04-13T23:18:37Z,errors: lazily load fallback fluent bundle,davidtwco,34a6c9f26e2ce32cad0d71f5e342365b09f4d12c,19,Auto merge of #95968 - davidtwco:translation-lazy-fallback r=oli-obk errors: lazily load fallback fluent bundle Addresses (hopefully) https://github.com/rust-lang/rust/pull/95667#issuecomment-1094794087. Loading the fallback bundle in compilation sessions that won't go on to emit any errors unnecessarily degrades compile time performance so lazily create the Fluent bundle when it is first required. r? `@ghost` (just for perf initially),ROCKET,2022-04-13T22:28:02Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/95970,MERGED,2022-04-12T09:26:28Z,2022-04-13T03:41:13Z,Fix suggestions in case of `T:` bounds,WaffleLapkin,d63a46ad2845683266479ee6e945ac476a85edc6,5,Rollup merge of #95970 - WaffleLapkin:nicer_trait_suggestions r=compiler-errors Fix suggestions in case of `T:` bounds This PR fixes a corner case in `suggest_constraining_type_params` that was causing incorrect suggestions. For the following functions: ```rust fn a(t: T) { [t t]; } fn b(t: T) where T: { [t t]; } ``` We previously suggested the following: ```text ... help: consider restricting type parameter `T` | 1 | fn a(t: T) { [t t]; } | ++++++ ... help: consider further restricting this bound | 2 | fn b(t: T) where T: + Copy { [t t]; } | ++++++ ``` Note that neither `T: Copy:` not `where T: + Copy` is a correct bound. With this commit the suggestions are correct: ```text ... help: consider restricting type parameter `T` | 1 | fn a(t: T) { [t t]; } | ++++ ... help: consider further restricting this bound | 2 | fn b(t: T) where T: Copy { [t t]; } | ++++ ``` r? `@compiler-errors` I've tried fixing #95898 here too but got too confused with how `suggest_traits_to_import` works and what it does :sweat_smile:,HEART,2022-04-22T23:20:04Z,estebank,NA https://github.com/rust-lang/rust/pull/95970,MERGED,2022-04-12T09:26:28Z,2022-04-13T03:41:13Z,Fix suggestions in case of `T:` bounds,WaffleLapkin,d63a46ad2845683266479ee6e945ac476a85edc6,5,Rollup merge of #95970 - WaffleLapkin:nicer_trait_suggestions r=compiler-errors Fix suggestions in case of `T:` bounds This PR fixes a corner case in `suggest_constraining_type_params` that was causing incorrect suggestions. For the following functions: ```rust fn a(t: T) { [t t]; } fn b(t: T) where T: { [t t]; } ``` We previously suggested the following: ```text ... help: consider restricting type parameter `T` | 1 | fn a(t: T) { [t t]; } | ++++++ ... help: consider further restricting this bound | 2 | fn b(t: T) where T: + Copy { [t t]; } | ++++++ ``` Note that neither `T: Copy:` not `where T: + Copy` is a correct bound. With this commit the suggestions are correct: ```text ... help: consider restricting type parameter `T` | 1 | fn a(t: T) { [t t]; } | ++++ ... help: consider further restricting this bound | 2 | fn b(t: T) where T: Copy { [t t]; } | ++++ ``` r? `@compiler-errors` I've tried fixing #95898 here too but got too confused with how `suggest_traits_to_import` works and what it does :sweat_smile:,HEART,2022-04-24T17:35:09Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/95971,MERGED,2022-04-12T09:33:06Z,2022-04-23T15:41:43Z,"No ""weird"" floats in const fn {from to}_bits",workingjubilee,1e9aa8a96b207668799365bf891a459b62410b60,5,"Auto merge of #95971 - workingjubilee:no-weird-fp-in-const r=oli-obk No ""weird"" floats in const fn {from to}_bits I suspect this code is subtly incorrect and that we don't even e.g. use x87-style floats in CTFE so I don't have to guard against that case. A future PR will be hopefully removing them from concern entirely anyways. But at the moment I wanted to get this rolling because small questions like that one seem best answered by review. r? `@oli-obk` cc `@eddyb` `@thomcc`",HEART,2022-04-12T10:17:16Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/95973,MERGED,2022-04-12T12:31:14Z,2022-04-13T03:41:13Z,prevent opaque types from appearing in impl headers,oli-obk,e96304b73d7913ab4bc14358b0d3fee7586ab62a,18,Rollup merge of #95973 - oli-obk:tait_ub3 r=compiler-errors prevent opaque types from appearing in impl headers cc `@lqd` opaque types are not distinguishable from their hidden type at the codegen stage. So we could either end up with cases where the hidden type doesn't implement the trait (which will thus ICE) or where the hidden type does implement the trait (so we'd be using its impl instead of the one written for the opaque type). This can even lead to unsound behaviour without unsafe code. Fixes https://github.com/rust-lang/rust/issues/86411. Fixes https://github.com/rust-lang/rust/issues/84660. rebase of #87382 plus some diagnostic tweaks,HEART,2022-04-12T12:53:15Z,lqd,NA https://github.com/rust-lang/rust/pull/95977,OPEN,2022-04-12T13:50:24Z,NA,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,THUMBS_UP,2022-04-19T06:08:07Z,aceArt-GmbH,NA https://github.com/rust-lang/rust/pull/95977,OPEN,2022-04-12T13:50:24Z,NA,Warn about dead tuple struct fields,FabianWolff,NA,NA,NA,HEART,2022-05-31T17:30:04Z,scottmcm,NA https://github.com/rust-lang/rust/pull/95981,MERGED,2022-04-12T15:31:44Z,2022-04-14T01:59:22Z,Optimize `::decode`,martingms,f387c930ee7c84357f8fa9f4c38903c00404ac46,1,"Auto merge of #95981 - martingms:invert-line-offset-parsing r=nnethercote Optimize `::decode` It showed up as a hot-ish function in a callgrind profile of the `await-call-tree` benchmark crate. Provides some moderate speedups to compilation of some of the smaller benchmarks: #### Primary benchmarks Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- helloworld | check | full | -1.81% | 9.03x helloworld | check | incr-unchanged | -1.80% | 8.99x helloworld | check | incr-full | -1.59% | 7.97x helloworld | check | incr-patched: println | -1.57% | 7.86x #### Secondary benchmarks
Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- unify-linearly | check | incr-unchanged | -1.55% | 7.74x unify-linearly | check | incr-patched: dummy fn | -1.42% | 7.08x await-call-tree | check | incr-unchanged | -1.27% | 6.35x await-call-tree | debug | incr-unchanged | -1.19% | 5.95x await-call-tree | opt | incr-unchanged | -1.19% | 5.94x issue-46449 | check | incr-unchanged | -1.08% | 5.39x issue-46449 | check | incr-patched: u8 3072 | -1.00% | 5.00x structopt-0.3.26 | check | incr-unchanged | -0.94% | 4.72x structopt-0.3.26 | opt | incr-unchanged | -0.92% | 4.60x structopt-0.3.26 | debug | incr-unchanged | -0.92% | 4.59x issue-46449 | check | full | -0.89% | 4.46x structopt-0.3.26 | check | full | -0.83% | 4.17x structopt-0.3.26 | debug | full | -0.78% | 3.88x structopt-0.3.26 | opt | full | -0.76% | 3.81x unify-linearly | check | full | -0.75% | 3.74x projection-caching | check | incr-unchanged | -0.74% | 3.70x issue-46449 | check | incr-patched: u32 3072 | -0.70% | 3.50x issue-46449 | check | incr-patched: empty 3072 | -0.68% | 3.41x structopt-0.3.26 | check | incr-full | -0.68% | 3.40x wf-projection-stress-65510 | check | incr-unchanged | -0.68% | 3.39x issue-46449 | check | incr-patched: static str 6144 | -0.67% | 3.37x wf-projection-stress-65510 | debug | incr-unchanged | -0.67% | 3.33x wf-projection-stress-65510 | opt | incr-unchanged | -0.66% | 3.31x issue-46449 | check | incr-patched: io error 6144 | -0.66% | 3.29x unify-linearly | check | incr-full | -0.65% | 3.26x issue-46449 | check | incr-full | -0.65% | 3.25x structopt-0.3.26 | debug | incr-full | -0.64% | 3.18x structopt-0.3.26 | opt | incr-full | -0.63% | 3.17x issue-46449 | debug | incr-unchanged | -0.61% | 3.06x issue-46449 | opt | incr-unchanged | -0.61% | 3.03x await-call-tree | check | full | -0.60% | 2.99x issue-88862 | check | incr-unchanged | -0.58% | 2.91x deep-vector | debug | full | 0.57% | 2.83x await-call-tree | check | incr-full | -0.52% | 2.59x tt-muncher | opt | full | -0.52% | 2.58x issue-58319 | check | incr-unchanged | -0.50% | 2.52x await-call-tree | debug | full | -0.50% | 2.49x await-call-tree | opt | full | -0.49% | 2.45x deep-vector | debug | incr-patched: println | 0.47% | 2.37x await-call-tree | debug | incr-full | -0.45% | 2.26x await-call-tree | opt | incr-full | -0.44% | 2.18x issue-88862 | check | full | -0.41% | 2.06x mockall-0.11.0 | check | incr-unchanged | -0.38% | 1.90x regression-31157 | check | incr-unchanged | -0.37% | 1.86x wf-projection-stress-65510 | opt | full | -0.36% | 1.80x deunicode-1.3.1 | check | incr-unchanged | -0.35% | 1.76x unify-linearly | debug | incr-patched: dummy fn | -0.35% | 1.74x mockall-0.11.0 | check | full | -0.35% | 1.73x unify-linearly | debug | incr-unchanged | -0.34% | 1.69x deunicode-1.3.1 | check | full | -0.33% | 1.63x token-stream-stress | check | full | -0.32% | 1.62x token-stream-stress | check | incr-full | -0.32% | 1.59x token-stream-stress | check | incr-unchanged | -0.32% | 1.59x regression-31157 | check | incr-patched: println | -0.31% | 1.57x wf-projection-stress-65510 | check | full | -0.31% | 1.54x deeply-nested-multi | check | incr-unchanged | -0.31% | 1.53x mockall-0.11.0 | opt | incr-unchanged | -0.30% | 1.50x r? `@nnethercote`",HEART,2022-04-13T07:18:57Z,nnethercote,NA https://github.com/rust-lang/rust/pull/95981,MERGED,2022-04-12T15:31:44Z,2022-04-14T01:59:22Z,Optimize `::decode`,martingms,f387c930ee7c84357f8fa9f4c38903c00404ac46,1,"Auto merge of #95981 - martingms:invert-line-offset-parsing r=nnethercote Optimize `::decode` It showed up as a hot-ish function in a callgrind profile of the `await-call-tree` benchmark crate. Provides some moderate speedups to compilation of some of the smaller benchmarks: #### Primary benchmarks Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- helloworld | check | full | -1.81% | 9.03x helloworld | check | incr-unchanged | -1.80% | 8.99x helloworld | check | incr-full | -1.59% | 7.97x helloworld | check | incr-patched: println | -1.57% | 7.86x #### Secondary benchmarks
Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- unify-linearly | check | incr-unchanged | -1.55% | 7.74x unify-linearly | check | incr-patched: dummy fn | -1.42% | 7.08x await-call-tree | check | incr-unchanged | -1.27% | 6.35x await-call-tree | debug | incr-unchanged | -1.19% | 5.95x await-call-tree | opt | incr-unchanged | -1.19% | 5.94x issue-46449 | check | incr-unchanged | -1.08% | 5.39x issue-46449 | check | incr-patched: u8 3072 | -1.00% | 5.00x structopt-0.3.26 | check | incr-unchanged | -0.94% | 4.72x structopt-0.3.26 | opt | incr-unchanged | -0.92% | 4.60x structopt-0.3.26 | debug | incr-unchanged | -0.92% | 4.59x issue-46449 | check | full | -0.89% | 4.46x structopt-0.3.26 | check | full | -0.83% | 4.17x structopt-0.3.26 | debug | full | -0.78% | 3.88x structopt-0.3.26 | opt | full | -0.76% | 3.81x unify-linearly | check | full | -0.75% | 3.74x projection-caching | check | incr-unchanged | -0.74% | 3.70x issue-46449 | check | incr-patched: u32 3072 | -0.70% | 3.50x issue-46449 | check | incr-patched: empty 3072 | -0.68% | 3.41x structopt-0.3.26 | check | incr-full | -0.68% | 3.40x wf-projection-stress-65510 | check | incr-unchanged | -0.68% | 3.39x issue-46449 | check | incr-patched: static str 6144 | -0.67% | 3.37x wf-projection-stress-65510 | debug | incr-unchanged | -0.67% | 3.33x wf-projection-stress-65510 | opt | incr-unchanged | -0.66% | 3.31x issue-46449 | check | incr-patched: io error 6144 | -0.66% | 3.29x unify-linearly | check | incr-full | -0.65% | 3.26x issue-46449 | check | incr-full | -0.65% | 3.25x structopt-0.3.26 | debug | incr-full | -0.64% | 3.18x structopt-0.3.26 | opt | incr-full | -0.63% | 3.17x issue-46449 | debug | incr-unchanged | -0.61% | 3.06x issue-46449 | opt | incr-unchanged | -0.61% | 3.03x await-call-tree | check | full | -0.60% | 2.99x issue-88862 | check | incr-unchanged | -0.58% | 2.91x deep-vector | debug | full | 0.57% | 2.83x await-call-tree | check | incr-full | -0.52% | 2.59x tt-muncher | opt | full | -0.52% | 2.58x issue-58319 | check | incr-unchanged | -0.50% | 2.52x await-call-tree | debug | full | -0.50% | 2.49x await-call-tree | opt | full | -0.49% | 2.45x deep-vector | debug | incr-patched: println | 0.47% | 2.37x await-call-tree | debug | incr-full | -0.45% | 2.26x await-call-tree | opt | incr-full | -0.44% | 2.18x issue-88862 | check | full | -0.41% | 2.06x mockall-0.11.0 | check | incr-unchanged | -0.38% | 1.90x regression-31157 | check | incr-unchanged | -0.37% | 1.86x wf-projection-stress-65510 | opt | full | -0.36% | 1.80x deunicode-1.3.1 | check | incr-unchanged | -0.35% | 1.76x unify-linearly | debug | incr-patched: dummy fn | -0.35% | 1.74x mockall-0.11.0 | check | full | -0.35% | 1.73x unify-linearly | debug | incr-unchanged | -0.34% | 1.69x deunicode-1.3.1 | check | full | -0.33% | 1.63x token-stream-stress | check | full | -0.32% | 1.62x token-stream-stress | check | incr-full | -0.32% | 1.59x token-stream-stress | check | incr-unchanged | -0.32% | 1.59x regression-31157 | check | incr-patched: println | -0.31% | 1.57x wf-projection-stress-65510 | check | full | -0.31% | 1.54x deeply-nested-multi | check | incr-unchanged | -0.31% | 1.53x mockall-0.11.0 | opt | incr-unchanged | -0.30% | 1.50x r? `@nnethercote`",HOORAY,2022-04-22T02:31:48Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/95981,MERGED,2022-04-12T15:31:44Z,2022-04-14T01:59:22Z,Optimize `::decode`,martingms,f387c930ee7c84357f8fa9f4c38903c00404ac46,1,"Auto merge of #95981 - martingms:invert-line-offset-parsing r=nnethercote Optimize `::decode` It showed up as a hot-ish function in a callgrind profile of the `await-call-tree` benchmark crate. Provides some moderate speedups to compilation of some of the smaller benchmarks: #### Primary benchmarks Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- helloworld | check | full | -1.81% | 9.03x helloworld | check | incr-unchanged | -1.80% | 8.99x helloworld | check | incr-full | -1.59% | 7.97x helloworld | check | incr-patched: println | -1.57% | 7.86x #### Secondary benchmarks
Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- unify-linearly | check | incr-unchanged | -1.55% | 7.74x unify-linearly | check | incr-patched: dummy fn | -1.42% | 7.08x await-call-tree | check | incr-unchanged | -1.27% | 6.35x await-call-tree | debug | incr-unchanged | -1.19% | 5.95x await-call-tree | opt | incr-unchanged | -1.19% | 5.94x issue-46449 | check | incr-unchanged | -1.08% | 5.39x issue-46449 | check | incr-patched: u8 3072 | -1.00% | 5.00x structopt-0.3.26 | check | incr-unchanged | -0.94% | 4.72x structopt-0.3.26 | opt | incr-unchanged | -0.92% | 4.60x structopt-0.3.26 | debug | incr-unchanged | -0.92% | 4.59x issue-46449 | check | full | -0.89% | 4.46x structopt-0.3.26 | check | full | -0.83% | 4.17x structopt-0.3.26 | debug | full | -0.78% | 3.88x structopt-0.3.26 | opt | full | -0.76% | 3.81x unify-linearly | check | full | -0.75% | 3.74x projection-caching | check | incr-unchanged | -0.74% | 3.70x issue-46449 | check | incr-patched: u32 3072 | -0.70% | 3.50x issue-46449 | check | incr-patched: empty 3072 | -0.68% | 3.41x structopt-0.3.26 | check | incr-full | -0.68% | 3.40x wf-projection-stress-65510 | check | incr-unchanged | -0.68% | 3.39x issue-46449 | check | incr-patched: static str 6144 | -0.67% | 3.37x wf-projection-stress-65510 | debug | incr-unchanged | -0.67% | 3.33x wf-projection-stress-65510 | opt | incr-unchanged | -0.66% | 3.31x issue-46449 | check | incr-patched: io error 6144 | -0.66% | 3.29x unify-linearly | check | incr-full | -0.65% | 3.26x issue-46449 | check | incr-full | -0.65% | 3.25x structopt-0.3.26 | debug | incr-full | -0.64% | 3.18x structopt-0.3.26 | opt | incr-full | -0.63% | 3.17x issue-46449 | debug | incr-unchanged | -0.61% | 3.06x issue-46449 | opt | incr-unchanged | -0.61% | 3.03x await-call-tree | check | full | -0.60% | 2.99x issue-88862 | check | incr-unchanged | -0.58% | 2.91x deep-vector | debug | full | 0.57% | 2.83x await-call-tree | check | incr-full | -0.52% | 2.59x tt-muncher | opt | full | -0.52% | 2.58x issue-58319 | check | incr-unchanged | -0.50% | 2.52x await-call-tree | debug | full | -0.50% | 2.49x await-call-tree | opt | full | -0.49% | 2.45x deep-vector | debug | incr-patched: println | 0.47% | 2.37x await-call-tree | debug | incr-full | -0.45% | 2.26x await-call-tree | opt | incr-full | -0.44% | 2.18x issue-88862 | check | full | -0.41% | 2.06x mockall-0.11.0 | check | incr-unchanged | -0.38% | 1.90x regression-31157 | check | incr-unchanged | -0.37% | 1.86x wf-projection-stress-65510 | opt | full | -0.36% | 1.80x deunicode-1.3.1 | check | incr-unchanged | -0.35% | 1.76x unify-linearly | debug | incr-patched: dummy fn | -0.35% | 1.74x mockall-0.11.0 | check | full | -0.35% | 1.73x unify-linearly | debug | incr-unchanged | -0.34% | 1.69x deunicode-1.3.1 | check | full | -0.33% | 1.63x token-stream-stress | check | full | -0.32% | 1.62x token-stream-stress | check | incr-full | -0.32% | 1.59x token-stream-stress | check | incr-unchanged | -0.32% | 1.59x regression-31157 | check | incr-patched: println | -0.31% | 1.57x wf-projection-stress-65510 | check | full | -0.31% | 1.54x deeply-nested-multi | check | incr-unchanged | -0.31% | 1.53x mockall-0.11.0 | opt | incr-unchanged | -0.30% | 1.50x r? `@nnethercote`",HEART,2022-04-24T17:36:01Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-13T07:15:59Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-13T09:12:31Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-17T05:34:00Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-17T06:21:51Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-21T03:28:47Z,GrayJack,NA https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-22T02:41:14Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/96002,MERGED,2022-04-13T05:41:55Z,2022-04-17T05:26:06Z,Speed up Vec::clear().,nnethercote,43a71dc732af0f7cc5895cca8d001184c252426a,2,Auto merge of #96002 - nnethercote:speed-up-Vec-clear-2 r=m-ou-se Speed up Vec::clear(). Currently it just calls `truncate(0)`. `truncate()` is (a) not marked as `#[inline]` and (b) more general than needed for `clear()`. This commit changes `clear()` to do the work itself. This modest change was first proposed in rust-lang#74172 where the reviewer rejected it because there was insufficient evidence that `Vec::clear()`'s performance mattered enough to justify the change. Recent changes within rustc have made `Vec::clear()` hot within `macro_parser.rs` so the change is now clearly worthwhile. Although it doesn't show wins on CI perf runs this seems to be because they use PGO. But not all platforms currently use PGO. Also local builds don't use PGO and `truncate` sometimes shows up in an over-represented fashion in local profiles. So local profiling will be made easier by this change. Note that this will also benefit `String::clear()` because it just calls `Vec::clear()`. Finally the commit removes the `vec-clear.rs` codegen test. It was added in #52908. From before then until now `Vec::clear()` just called `Vec::truncate()` with a zero length. The body of Vec::truncate() has changed a lot since then. Now that `Vec::clear()` is doing actual work itself and not just calling `Vec::truncate()` it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test. r? `@m-ou-se`,HEART,2022-04-23T05:29:04Z,H2CO3,h2co3@h2co3.org https://github.com/rust-lang/rust/pull/96008,MERGED,2022-04-13T12:24:34Z,2022-05-09T19:53:08Z,Warn on unused `#[doc(hidden)]` attributes on trait impl items,fmease,6c8001b85ce0b318422e44efec1fe67690ab22d3,18,Rollup merge of #96008 - fmease:warn-on-useless-doc-hidden-on-assoc-impl-items r=lcnr Warn on unused `#[doc(hidden)]` attributes on trait impl items [Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60). Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted: ```rust pub trait Tr { fn f(); } pub struct Ty; impl Tr for Ty { #[doc(hidden)] fn f() {} } // ^^^^^^^^^^^^^^ ignored by rustdoc and currently // no error or warning issued ``` This may lead users to the wrong belief that the attribute has an effect. In fact several such cases are found in the standard library (I've removed all of them in this PR). There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page. This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning. `@rustbot` label T-compiler T-rustdoc A-lint,THUMBS_UP,2022-05-12T01:14:03Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/96008,MERGED,2022-04-13T12:24:34Z,2022-05-09T19:53:08Z,Warn on unused `#[doc(hidden)]` attributes on trait impl items,fmease,6c8001b85ce0b318422e44efec1fe67690ab22d3,18,Rollup merge of #96008 - fmease:warn-on-useless-doc-hidden-on-assoc-impl-items r=lcnr Warn on unused `#[doc(hidden)]` attributes on trait impl items [Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60). Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted: ```rust pub trait Tr { fn f(); } pub struct Ty; impl Tr for Ty { #[doc(hidden)] fn f() {} } // ^^^^^^^^^^^^^^ ignored by rustdoc and currently // no error or warning issued ``` This may lead users to the wrong belief that the attribute has an effect. In fact several such cases are found in the standard library (I've removed all of them in this PR). There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page. This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning. `@rustbot` label T-compiler T-rustdoc A-lint,THUMBS_UP,2022-05-12T23:11:10Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96016,MERGED,2022-04-13T16:27:35Z,2022-04-17T12:56:17Z,Remove last vestiges of skippng ident span hashing,Aaron1011,af68f7182e11de7eced78078313e9ba0436db84e,2,Auto merge of #96016 - Aaron1011:hash-name-cleanup r=cjgillot Remove last vestiges of skippng ident span hashing This removes a comment that no longer applies and properly hashes the full ident for path segments.,THUMBS_UP,2022-04-13T16:40:27Z,StunxFS,NA https://github.com/rust-lang/rust/pull/96019,OPEN,2022-04-13T18:42:23Z,NA,modify next_code_point() to accept an Iterator instead of Iterator<&u8>. Old code that calls it invokes .copied(),mutantbob,NA,NA,NA,THUMBS_UP,2022-04-13T19:04:59Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/96020,MERGED,2022-04-13T18:59:38Z,2022-04-19T13:10:17Z,Micro-optimize `ty::relate::relate_substs` by avoiding `match`,martingms,c102c5cfc60203c82460bdde2eecd19ccd8c125b,3,Auto merge of #96020 - martingms:optimize-relate_substs r=nnethercote Micro-optimize `ty::relate::relate_substs` by avoiding `match` Was a top-20 hot function in a callgrind profile of compiling `bitmaps-3.1.0`. Yields some small speedups on that crate and some others according to local benching: Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- bitmaps-3.1.0 | check | full | -1.88% | 9.42x bitmaps-3.1.0 | debug | full | -1.80% | 8.99x bitmaps-3.1.0 | opt | full | -1.70% | 8.49x bitmaps-3.1.0 | check | incr-full | -1.54% | 7.68x deep-vector | debug | full | 1.52% | 7.61x bitmaps-3.1.0 | debug | incr-full | -1.45% | 7.26x bitmaps-3.1.0 | opt | incr-full | -1.39% | 6.95x nalgebra-0.30.1 | check | full | -0.68% | 3.42x nalgebra-0.30.1 | debug | full | -0.64% | 3.22x nalgebra-0.30.1 | opt | full | -0.64% | 3.20x projection-caching | check | full | -0.61% | 3.05x nalgebra-0.30.1 | check | incr-full | -0.56% | 2.78x nalgebra-0.30.1 | opt | incr-full | -0.54% | 2.72x nalgebra-0.30.1 | debug | incr-full | -0.54% | 2.69x projection-caching | check | incr-full | -0.50% | 2.51x tt-muncher | opt | full | -0.48% | 2.42x projection-caching | opt | full | -0.47% | 2.37x projection-caching | debug | full | -0.47% | 2.35x projection-caching | opt | incr-full | -0.44% | 2.21x projection-caching | debug | incr-full | -0.42% | 2.08x deeply-nested-multi | check | incr-full | 0.37% | 1.87x wf-projection-stress-65510 | opt | full | -0.37% | 1.84x deep-vector | debug | incr-patched: add vec item | -0.32% | 1.61x projection-caching | debug | incr-unchanged | -0.32% | 1.60x wf-projection-stress-65510 | check | full | -0.31% | 1.55x projection-caching | opt | incr-unchanged | -0.31% | 1.53x wf-projection-stress-65510 | debug | incr-full | -0.30% | 1.51x wf-projection-stress-65510 | opt | incr-full | -0.30% | 1.51x r? `@nnethercote`,HOORAY,2022-04-13T23:54:17Z,nnethercote,NA https://github.com/rust-lang/rust/pull/96020,MERGED,2022-04-13T18:59:38Z,2022-04-19T13:10:17Z,Micro-optimize `ty::relate::relate_substs` by avoiding `match`,martingms,c102c5cfc60203c82460bdde2eecd19ccd8c125b,3,Auto merge of #96020 - martingms:optimize-relate_substs r=nnethercote Micro-optimize `ty::relate::relate_substs` by avoiding `match` Was a top-20 hot function in a callgrind profile of compiling `bitmaps-3.1.0`. Yields some small speedups on that crate and some others according to local benching: Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- bitmaps-3.1.0 | check | full | -1.88% | 9.42x bitmaps-3.1.0 | debug | full | -1.80% | 8.99x bitmaps-3.1.0 | opt | full | -1.70% | 8.49x bitmaps-3.1.0 | check | incr-full | -1.54% | 7.68x deep-vector | debug | full | 1.52% | 7.61x bitmaps-3.1.0 | debug | incr-full | -1.45% | 7.26x bitmaps-3.1.0 | opt | incr-full | -1.39% | 6.95x nalgebra-0.30.1 | check | full | -0.68% | 3.42x nalgebra-0.30.1 | debug | full | -0.64% | 3.22x nalgebra-0.30.1 | opt | full | -0.64% | 3.20x projection-caching | check | full | -0.61% | 3.05x nalgebra-0.30.1 | check | incr-full | -0.56% | 2.78x nalgebra-0.30.1 | opt | incr-full | -0.54% | 2.72x nalgebra-0.30.1 | debug | incr-full | -0.54% | 2.69x projection-caching | check | incr-full | -0.50% | 2.51x tt-muncher | opt | full | -0.48% | 2.42x projection-caching | opt | full | -0.47% | 2.37x projection-caching | debug | full | -0.47% | 2.35x projection-caching | opt | incr-full | -0.44% | 2.21x projection-caching | debug | incr-full | -0.42% | 2.08x deeply-nested-multi | check | incr-full | 0.37% | 1.87x wf-projection-stress-65510 | opt | full | -0.37% | 1.84x deep-vector | debug | incr-patched: add vec item | -0.32% | 1.61x projection-caching | debug | incr-unchanged | -0.32% | 1.60x wf-projection-stress-65510 | check | full | -0.31% | 1.55x projection-caching | opt | incr-unchanged | -0.31% | 1.53x wf-projection-stress-65510 | debug | incr-full | -0.30% | 1.51x wf-projection-stress-65510 | opt | incr-full | -0.30% | 1.51x r? `@nnethercote`,HOORAY,2022-04-28T06:39:10Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96020,MERGED,2022-04-13T18:59:38Z,2022-04-19T13:10:17Z,Micro-optimize `ty::relate::relate_substs` by avoiding `match`,martingms,c102c5cfc60203c82460bdde2eecd19ccd8c125b,3,Auto merge of #96020 - martingms:optimize-relate_substs r=nnethercote Micro-optimize `ty::relate::relate_substs` by avoiding `match` Was a top-20 hot function in a callgrind profile of compiling `bitmaps-3.1.0`. Yields some small speedups on that crate and some others according to local benching: Benchmark | Profile | Scenario | % Change | Significance Factor? -- | -- | -- | -- | -- bitmaps-3.1.0 | check | full | -1.88% | 9.42x bitmaps-3.1.0 | debug | full | -1.80% | 8.99x bitmaps-3.1.0 | opt | full | -1.70% | 8.49x bitmaps-3.1.0 | check | incr-full | -1.54% | 7.68x deep-vector | debug | full | 1.52% | 7.61x bitmaps-3.1.0 | debug | incr-full | -1.45% | 7.26x bitmaps-3.1.0 | opt | incr-full | -1.39% | 6.95x nalgebra-0.30.1 | check | full | -0.68% | 3.42x nalgebra-0.30.1 | debug | full | -0.64% | 3.22x nalgebra-0.30.1 | opt | full | -0.64% | 3.20x projection-caching | check | full | -0.61% | 3.05x nalgebra-0.30.1 | check | incr-full | -0.56% | 2.78x nalgebra-0.30.1 | opt | incr-full | -0.54% | 2.72x nalgebra-0.30.1 | debug | incr-full | -0.54% | 2.69x projection-caching | check | incr-full | -0.50% | 2.51x tt-muncher | opt | full | -0.48% | 2.42x projection-caching | opt | full | -0.47% | 2.37x projection-caching | debug | full | -0.47% | 2.35x projection-caching | opt | incr-full | -0.44% | 2.21x projection-caching | debug | incr-full | -0.42% | 2.08x deeply-nested-multi | check | incr-full | 0.37% | 1.87x wf-projection-stress-65510 | opt | full | -0.37% | 1.84x deep-vector | debug | incr-patched: add vec item | -0.32% | 1.61x projection-caching | debug | incr-unchanged | -0.32% | 1.60x wf-projection-stress-65510 | check | full | -0.31% | 1.55x projection-caching | opt | incr-unchanged | -0.31% | 1.53x wf-projection-stress-65510 | debug | incr-full | -0.30% | 1.51x wf-projection-stress-65510 | opt | incr-full | -0.30% | 1.51x r? `@nnethercote`,HOORAY,2022-04-28T10:20:16Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96028,CLOSED,2022-04-13T22:07:20Z,2022-04-15T18:10:47Z,rustdoc: add --minimum-supported-rust-version option,GuillaumeGomez,NA,NA,NA,ROCKET,2022-04-13T22:23:36Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96028,CLOSED,2022-04-13T22:07:20Z,2022-04-15T18:10:47Z,rustdoc: add --minimum-supported-rust-version option,GuillaumeGomez,NA,NA,NA,THUMBS_DOWN,2022-04-14T15:05:52Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96033,MERGED,2022-04-14T02:14:02Z,2022-05-26T21:56:35Z,Add section on common message styles for Result::expect,yaahc,82beeabf54b830f9df64c2837e5ab2068633bd5d,3,"Rollup merge of #96033 - yaahc:expect-elaboration r=scottmcm Add section on common message styles for Result::expect Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937 ~~One thing I haven't decided on yet should I duplicate this section on `Option::expect` link to this section or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs. I think this section when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the ""expect as precondition"" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs not expected potential failure modes. The ""expect as error message"" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the ""expect as precondition"" style of expect message.",THUMBS_UP,2022-05-26T03:29:26Z,WindSoilder,WindSoilder@outlook.com https://github.com/rust-lang/rust/pull/96033,MERGED,2022-04-14T02:14:02Z,2022-05-26T21:56:35Z,Add section on common message styles for Result::expect,yaahc,82beeabf54b830f9df64c2837e5ab2068633bd5d,3,"Rollup merge of #96033 - yaahc:expect-elaboration r=scottmcm Add section on common message styles for Result::expect Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937 ~~One thing I haven't decided on yet should I duplicate this section on `Option::expect` link to this section or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs. I think this section when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the ""expect as precondition"" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs not expected potential failure modes. The ""expect as error message"" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the ""expect as precondition"" style of expect message.",THUMBS_UP,2022-05-26T06:27:43Z,Luxter77,NA https://github.com/rust-lang/rust/pull/96042,MERGED,2022-04-14T09:19:42Z,2022-04-18T14:56:31Z,Use a single ReentrantMutex implementation on all platforms.,m-ou-se,6fd7e9010db6be7605241c39eab7c5078ee2d5bd,13,Auto merge of #96042 - m-ou-se:one-reentrant-mutex r=Amanieu Use a single ReentrantMutex implementation on all platforms. This replaces all platform specific ReentrantMutex implementations by the one I added in #95727 for Linux since that one does not depend on any platform specific details. r? `@Amanieu`,HOORAY,2022-06-20T22:09:10Z,tmandry,NA https://github.com/rust-lang/rust/pull/96046,MERGED,2022-04-14T12:09:15Z,2022-05-27T14:12:30Z,Move various checks to typeck so them failing causes the typeck result to get tainted,oli-obk,56fd680cf9226ab424f88d4e3b43c5e088d17f19,57,Auto merge of #96046 - oli-obk:const_typeck r=cjgillot Move various checks to typeck so them failing causes the typeck result to get tainted Fixes #69487 fixes #79047 cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant,HOORAY,2022-04-14T12:24:56Z,RalfJung,NA https://github.com/rust-lang/rust/pull/96046,MERGED,2022-04-14T12:09:15Z,2022-05-27T14:12:30Z,Move various checks to typeck so them failing causes the typeck result to get tainted,oli-obk,56fd680cf9226ab424f88d4e3b43c5e088d17f19,57,Auto merge of #96046 - oli-obk:const_typeck r=cjgillot Move various checks to typeck so them failing causes the typeck result to get tainted Fixes #69487 fixes #79047 cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant,HOORAY,2022-04-14T15:23:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96046,MERGED,2022-04-14T12:09:15Z,2022-05-27T14:12:30Z,Move various checks to typeck so them failing causes the typeck result to get tainted,oli-obk,56fd680cf9226ab424f88d4e3b43c5e088d17f19,57,Auto merge of #96046 - oli-obk:const_typeck r=cjgillot Move various checks to typeck so them failing causes the typeck result to get tainted Fixes #69487 fixes #79047 cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant,HEART,2022-04-18T19:52:44Z,Badel2,NA https://github.com/rust-lang/rust/pull/96069,CLOSED,2022-04-15T06:59:36Z,2022-04-15T10:44:12Z,Rollup of 16 pull requests,fee1-dead,NA,NA,NA,EYES,2022-04-15T09:04:37Z,fmease,NA https://github.com/rust-lang/rust/pull/96071,OPEN,2022-04-15T09:35:11Z,NA,Int parsing optimisations (part 2),gilescope,NA,NA,NA,HEART,2022-04-16T00:45:28Z,LifeIsStrange,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,HEART,2022-04-23T11:30:23Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,HEART,2022-05-27T14:44:57Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,HOORAY,2022-05-27T14:45:17Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,ROCKET,2022-05-27T14:45:20Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,THUMBS_UP,2022-05-27T14:45:25Z,frewsxcv,NA https://github.com/rust-lang/rust/pull/96077,OPEN,2022-04-15T12:23:24Z,NA,[WIP] Rework the entire const trait system,fee1-dead,NA,NA,NA,THUMBS_UP,2022-05-28T04:37:39Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/96089,MERGED,2022-04-15T19:12:37Z,2022-04-19T15:34:28Z,`alloc`: make `vec!` unavailable under `no_global_oom_handling`,ojeda,35188440b5e3d02acdb02f616aad800c9c377dca,1,Rollup merge of #96089 - ojeda:no-vec-no_global_oom_handling r=Mark-Simulacrum `alloc`: make `vec!` unavailable under `no_global_oom_handling` `alloc`: make `vec!` unavailable under `no_global_oom_handling` The `vec!` macro has 3 rules but two are not usable under `no_global_oom_handling` builds of the standard library (even with a zero size): ```rust let _ = vec![42]; // Error: requires `exchange_malloc` lang_item. let _ = vec![42; 0]; // Error: cannot find function `from_elem`. ``` Thus those two rules should not be available to begin with. The remaining one with an empty matcher is just a shorthand for `new()` and may not make as much sense to have alone since the idea behind `vec!` is to enable `Vec`s to be defined with the same syntax as array expressions. Furthermore the documentation can be confusing since it shows the other rules. Thus perhaps it is better and simpler to disable `vec!` entirely under `no_global_oom_handling` environments and let users call `new()` instead: ```rust let _: Vec = vec![]; let _: Vec = Vec::new(); ``` Notwithstanding this a `try_vec!` macro would be useful such as the one introduced in https://github.com/rust-lang/rust/pull/95051. If the shorthand for `new()` is deemed worth keeping on its own then it may be interesting to have a separate `vec!` macro with a single rule and different simpler documentation. Signed-off-by: Miguel Ojeda ,ROCKET,2022-04-16T07:20:22Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/96089,MERGED,2022-04-15T19:12:37Z,2022-04-19T15:34:28Z,`alloc`: make `vec!` unavailable under `no_global_oom_handling`,ojeda,35188440b5e3d02acdb02f616aad800c9c377dca,1,Rollup merge of #96089 - ojeda:no-vec-no_global_oom_handling r=Mark-Simulacrum `alloc`: make `vec!` unavailable under `no_global_oom_handling` `alloc`: make `vec!` unavailable under `no_global_oom_handling` The `vec!` macro has 3 rules but two are not usable under `no_global_oom_handling` builds of the standard library (even with a zero size): ```rust let _ = vec![42]; // Error: requires `exchange_malloc` lang_item. let _ = vec![42; 0]; // Error: cannot find function `from_elem`. ``` Thus those two rules should not be available to begin with. The remaining one with an empty matcher is just a shorthand for `new()` and may not make as much sense to have alone since the idea behind `vec!` is to enable `Vec`s to be defined with the same syntax as array expressions. Furthermore the documentation can be confusing since it shows the other rules. Thus perhaps it is better and simpler to disable `vec!` entirely under `no_global_oom_handling` environments and let users call `new()` instead: ```rust let _: Vec = vec![]; let _: Vec = Vec::new(); ``` Notwithstanding this a `try_vec!` macro would be useful such as the one introduced in https://github.com/rust-lang/rust/pull/95051. If the shorthand for `new()` is deemed worth keeping on its own then it may be interesting to have a separate `vec!` macro with a single rule and different simpler documentation. Signed-off-by: Miguel Ojeda ,THUMBS_UP,2022-04-28T10:25:46Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96094,MERGED,2022-04-15T23:11:49Z,2022-05-07T09:11:15Z,Begin fixing all the broken doctests in `compiler/`,Elliot-Roberts,574830f5730f2cfc3abdb486428d33d541c0abee,116,"Auto merge of #96094 - Elliot-Roberts:fix_doctests r=compiler-errors Begin fixing all the broken doctests in `compiler/` Begins to fix #95994. All of them pass now but 24 of them I've marked with `ignore HELP ()` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are. There are also a few that I marked `ignore` that could maybe be made to work but seem less important. Each `ignore` has a rough ""reason"" for ignoring after it parentheses with - `(pseudo-rust)` meaning ""mostly rust-like but contains foreign syntax"" - `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type) or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy. - `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting like MIR. - `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup. Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful. I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool",HEART,2022-04-16T23:36:05Z,est31,NA https://github.com/rust-lang/rust/pull/96094,MERGED,2022-04-15T23:11:49Z,2022-05-07T09:11:15Z,Begin fixing all the broken doctests in `compiler/`,Elliot-Roberts,574830f5730f2cfc3abdb486428d33d541c0abee,116,"Auto merge of #96094 - Elliot-Roberts:fix_doctests r=compiler-errors Begin fixing all the broken doctests in `compiler/` Begins to fix #95994. All of them pass now but 24 of them I've marked with `ignore HELP ()` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are. There are also a few that I marked `ignore` that could maybe be made to work but seem less important. Each `ignore` has a rough ""reason"" for ignoring after it parentheses with - `(pseudo-rust)` meaning ""mostly rust-like but contains foreign syntax"" - `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type) or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy. - `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting like MIR. - `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup. Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful. I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool",HEART,2022-04-19T01:29:25Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96105,MERGED,2022-04-16T03:43:41Z,2022-04-17T03:08:58Z,Make the debug output for `TargetSelection` less verbose,jyn514,ff91155d0abbe6bbbffdca487cec574c8aa2c2a5,1,"Rollup merge of #96105 - jyn514:less-verbose-logging r=Mark-Simulacrum Make the debug output for `TargetSelection` less verbose In particular this makes the output of `x build -vv` easier to read. Before: ``` c Sysroot { compiler: Compiler { stage: 0 host: TargetSelection { triple: ""x86_64-unknown-linux-gnu"" file: None } } } ``` After: ``` c Sysroot { compiler: Compiler { stage: 0 host: x86_64-unknown-linux-gnu } } ```",THUMBS_UP,2022-04-16T06:40:42Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96110,CLOSED,2022-04-16T05:29:20Z,2022-06-08T04:39:07Z,Add u8::from_ascii_to_digit,gimbles,NA,NA,NA,HEART,2022-04-16T07:51:00Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/96110,CLOSED,2022-04-16T05:29:20Z,2022-06-08T04:39:07Z,Add u8::from_ascii_to_digit,gimbles,NA,NA,NA,THUMBS_UP,2022-04-16T09:33:18Z,hniksic,hniksic@gmail.com https://github.com/rust-lang/rust/pull/96136,MERGED,2022-04-17T04:42:50Z,2022-04-18T20:53:45Z,Reword clarification on lifetime for ptr->ref safety docs,thomcc,a6ad1394f3f7fe1d9d459964a2d4be8d6ba2ea5a,3,Rollup merge of #96136 - thomcc:lifetime-wording r=RalfJung Reword clarification on lifetime for ptr->ref safety docs I believe the current wording of the safety comment is somewhat misleading and that this is more accurate. Suggested by `@CAD97` in this thread on the topic https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Lifetime.20of.20reference.20pointer.20docs.20issue Just to check that this is correct CC `@RalfJung.` I suppose it's open for interpretation as to whether or not this is more clear. I think it is.,THUMBS_UP,2022-04-17T04:51:46Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/96136,MERGED,2022-04-17T04:42:50Z,2022-04-18T20:53:45Z,Reword clarification on lifetime for ptr->ref safety docs,thomcc,a6ad1394f3f7fe1d9d459964a2d4be8d6ba2ea5a,3,Rollup merge of #96136 - thomcc:lifetime-wording r=RalfJung Reword clarification on lifetime for ptr->ref safety docs I believe the current wording of the safety comment is somewhat misleading and that this is more accurate. Suggested by `@CAD97` in this thread on the topic https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Lifetime.20of.20reference.20pointer.20docs.20issue Just to check that this is correct CC `@RalfJung.` I suppose it's open for interpretation as to whether or not this is more clear. I think it is.,THUMBS_UP,2022-04-17T05:32:08Z,CAD97,cad97@cad97.com https://github.com/rust-lang/rust/pull/96145,CLOSED,2022-04-17T11:38:01Z,2022-04-18T05:27:32Z,set has_thread_local=true for android,name1e5s,NA,NA,NA,THUMBS_UP,2022-04-17T14:34:39Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-04-19T06:59:05Z,iago-lito,NA https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-04-23T11:27:21Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-05-12T04:59:19Z,faptc,NA https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-05-14T22:52:50Z,Alexhuszagh,ahuszagh@gmail.com https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-05-25T20:43:06Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/96150,MERGED,2022-04-17T15:27:33Z,2022-05-12T02:49:02Z,Implement a lint to warn about unused macro rules,est31,0cd939e36c0696aad44a213566c9b152f0437020,34,"Auto merge of #96150 - est31:unused_macro_rules r=petrochenkov Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers) similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!(""Hello world!"") }; () => { println!(""empty"") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576",HEART,2022-06-28T09:56:46Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96155,MERGED,2022-04-17T19:45:18Z,2022-05-08T06:22:27Z,Followups for method call error change,jackh726,030c886c29ffbfbb9f9c6495651cb4bee0fc93fe,44,Auto merge of #96155 - jackh726:param-heuristics-followup r=estebank Followups for method call error change Each commit is self-contained. Fixes most of the followup reviews from that PR. r? `@estebank`,HEART,2022-05-04T05:04:33Z,estebank,NA https://github.com/rust-lang/rust/pull/96167,MERGED,2022-04-18T04:25:24Z,2022-04-20T21:06:13Z,Replace sys/unix/weak AtomicUsize with AtomicPtr,CAD97,53f028d79072f9ff37af0315bea9b3c1c9615d5b,1,Rollup merge of #96167 - CAD97:weak-dlsym-less-ptr-crime r=thomcc Replace sys/unix/weak AtomicUsize with AtomicPtr Should fix #96163. Can't easily test on Windows though...,THUMBS_UP,2022-04-18T22:16:02Z,RalfJung,NA https://github.com/rust-lang/rust/pull/96197,MERGED,2022-04-19T01:35:30Z,2022-04-22T13:56:15Z,Mark payload fields of ScalarPair enums as Scalar::Union when they're not always initialized,erikdesjardins,a8272f23cc121cc3e98f3148c8dab532decc7b90,3,Auto merge of #96197 - erikdesjardins:scalarpairenum r=oli-obk Mark payload fields of ScalarPair enums as Scalar::Union when they're not always initialized Fixes #96158 r? `@RalfJung`,HEART,2022-04-19T03:03:36Z,RalfJung,NA https://github.com/rust-lang/rust/pull/96197,MERGED,2022-04-19T01:35:30Z,2022-04-22T13:56:15Z,Mark payload fields of ScalarPair enums as Scalar::Union when they're not always initialized,erikdesjardins,a8272f23cc121cc3e98f3148c8dab532decc7b90,3,Auto merge of #96197 - erikdesjardins:scalarpairenum r=oli-obk Mark payload fields of ScalarPair enums as Scalar::Union when they're not always initialized Fixes #96158 r? `@RalfJung`,HEART,2022-04-19T06:26:48Z,oli-obk,NA https://github.com/rust-lang/rust/pull/96204,CLOSED,2022-04-19T05:46:27Z,2022-04-21T05:49:32Z,fix: index out of bound on empty comment,csmoe,NA,NA,NA,THUMBS_UP,2022-04-19T14:16:13Z,jbr,NA https://github.com/rust-lang/rust/pull/96210,MERGED,2022-04-19T09:45:51Z,2022-04-21T18:32:02Z,Speed up `TokenCursor`,nnethercote,b04c5329e1e145fb2fb46c5a7e775638712b03aa,4,Auto merge of #96210 - nnethercote:speed-up-TokenCursor r=petrochenkov Speed up `TokenCursor` Plus a few related clean-ups. r? `@petrochenkov`,ROCKET,2022-04-19T09:56:13Z,martingms,NA https://github.com/rust-lang/rust/pull/96210,MERGED,2022-04-19T09:45:51Z,2022-04-21T18:32:02Z,Speed up `TokenCursor`,nnethercote,b04c5329e1e145fb2fb46c5a7e775638712b03aa,4,Auto merge of #96210 - nnethercote:speed-up-TokenCursor r=petrochenkov Speed up `TokenCursor` Plus a few related clean-ups. r? `@petrochenkov`,ROCKET,2022-04-19T19:30:39Z,est31,NA https://github.com/rust-lang/rust/pull/96210,MERGED,2022-04-19T09:45:51Z,2022-04-21T18:32:02Z,Speed up `TokenCursor`,nnethercote,b04c5329e1e145fb2fb46c5a7e775638712b03aa,4,Auto merge of #96210 - nnethercote:speed-up-TokenCursor r=petrochenkov Speed up `TokenCursor` Plus a few related clean-ups. r? `@petrochenkov`,ROCKET,2022-04-20T07:48:55Z,lqd,NA https://github.com/rust-lang/rust/pull/96210,MERGED,2022-04-19T09:45:51Z,2022-04-21T18:32:02Z,Speed up `TokenCursor`,nnethercote,b04c5329e1e145fb2fb46c5a7e775638712b03aa,4,Auto merge of #96210 - nnethercote:speed-up-TokenCursor r=petrochenkov Speed up `TokenCursor` Plus a few related clean-ups. r? `@petrochenkov`,ROCKET,2022-04-20T09:44:25Z,mati865,NA https://github.com/rust-lang/rust/pull/96210,MERGED,2022-04-19T09:45:51Z,2022-04-21T18:32:02Z,Speed up `TokenCursor`,nnethercote,b04c5329e1e145fb2fb46c5a7e775638712b03aa,4,Auto merge of #96210 - nnethercote:speed-up-TokenCursor r=petrochenkov Speed up `TokenCursor` Plus a few related clean-ups. r? `@petrochenkov`,ROCKET,2022-04-21T11:56:43Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96215,MERGED,2022-04-19T13:14:31Z,2022-04-25T00:40:30Z,Drop support for legacy PM with LLVM 15,nikic,433f1f425ee100adf2b8c454170bdee31df56670,7,Rollup merge of #96215 - nikic:legacy-pm-removal r=nagisa Drop support for legacy PM with LLVM 15 LLVM 15 already removes some of the legacy PM APIs we're using. This patch forces use of NewPM with LLVM 15 (with `-Z new-llvm-pass-manager=no` throwing a warning) and stubs out various FFI methods with a report_fatal_error on LLVM 15. For LLVMPassManagerBuilderPopulateLTOPassManager() I went with adding our own wrapper as the alternative would be to muck about with weak symbols which seems to be non-trivial as far as cross-platform support is concerned (std has `weak!` for this purpose but only as an internal utility.) Fixes #96072. Fixes #96362.,HOORAY,2022-04-19T18:13:04Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/96215,MERGED,2022-04-19T13:14:31Z,2022-04-25T00:40:30Z,Drop support for legacy PM with LLVM 15,nikic,433f1f425ee100adf2b8c454170bdee31df56670,7,Rollup merge of #96215 - nikic:legacy-pm-removal r=nagisa Drop support for legacy PM with LLVM 15 LLVM 15 already removes some of the legacy PM APIs we're using. This patch forces use of NewPM with LLVM 15 (with `-Z new-llvm-pass-manager=no` throwing a warning) and stubs out various FFI methods with a report_fatal_error on LLVM 15. For LLVMPassManagerBuilderPopulateLTOPassManager() I went with adding our own wrapper as the alternative would be to muck about with weak symbols which seems to be non-trivial as far as cross-platform support is concerned (std has `weak!` for this purpose but only as an internal utility.) Fixes #96072. Fixes #96362.,HOORAY,2022-04-20T08:47:18Z,mati865,NA https://github.com/rust-lang/rust/pull/96215,MERGED,2022-04-19T13:14:31Z,2022-04-25T00:40:30Z,Drop support for legacy PM with LLVM 15,nikic,433f1f425ee100adf2b8c454170bdee31df56670,7,Rollup merge of #96215 - nikic:legacy-pm-removal r=nagisa Drop support for legacy PM with LLVM 15 LLVM 15 already removes some of the legacy PM APIs we're using. This patch forces use of NewPM with LLVM 15 (with `-Z new-llvm-pass-manager=no` throwing a warning) and stubs out various FFI methods with a report_fatal_error on LLVM 15. For LLVMPassManagerBuilderPopulateLTOPassManager() I went with adding our own wrapper as the alternative would be to muck about with weak symbols which seems to be non-trivial as far as cross-platform support is concerned (std has `weak!` for this purpose but only as an internal utility.) Fixes #96072. Fixes #96362.,HOORAY,2022-04-23T23:28:17Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96215,MERGED,2022-04-19T13:14:31Z,2022-04-25T00:40:30Z,Drop support for legacy PM with LLVM 15,nikic,433f1f425ee100adf2b8c454170bdee31df56670,7,Rollup merge of #96215 - nikic:legacy-pm-removal r=nagisa Drop support for legacy PM with LLVM 15 LLVM 15 already removes some of the legacy PM APIs we're using. This patch forces use of NewPM with LLVM 15 (with `-Z new-llvm-pass-manager=no` throwing a warning) and stubs out various FFI methods with a report_fatal_error on LLVM 15. For LLVMPassManagerBuilderPopulateLTOPassManager() I went with adding our own wrapper as the alternative would be to muck about with weak symbols which seems to be non-trivial as far as cross-platform support is concerned (std has `weak!` for this purpose but only as an internal utility.) Fixes #96072. Fixes #96362.,HOORAY,2022-06-27T21:18:00Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/96232,MERGED,2022-04-20T00:26:28Z,2022-05-10T23:44:22Z,Make `BorrowedFd::borrow_raw` a const fn.,sunfishcode,ecd44958e0a21110d09862ee080d95a4ca6c52f8,3,Auto merge of #96232 - sunfishcode:sunfishcode/io-safety-const-fns r=joshtriplett Make `BorrowedFd::borrow_raw` a const fn. Making `BorrowedFd::borrow_raw` a const fn allows it to be used to create a constant `BorrowedFd<'static>` holding constants such as `AT_FDCWD`. This will allow [`rustix::fs::cwd`] to become a const fn. For consistency make similar changes to `BorrowedHandle::borrow_raw` and `BorrowedSocket::borrow_raw`. [`rustix::fs::cwd`]: https://docs.rs/rustix/latest/rustix/fs/fn.cwd.html r? `@joshtriplett`,THUMBS_UP,2022-04-20T03:56:49Z,mbartlett21,NA https://github.com/rust-lang/rust/pull/96237,MERGED,2022-04-20T01:33:42Z,2022-04-24T19:16:24Z,compiletest: combine `--*-python` args,AlecGoncharow,e1935cc1961ffd81a728589158b1ba982010564b,5,Rollup merge of #96237 - AlecGoncharow:issue-96011-fix r=Mark-Simulacrum compiletest: combine `--*-python` args Since these arguments are now always the same combine them into a singular `--python` argument. Fixes #96011,HEART,2022-04-21T01:45:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96240,OPEN,2022-04-20T04:43:52Z,NA,Stabilize `const_ptr_offset_from`.,fee1-dead,NA,NA,NA,HEART,2022-04-21T14:38:52Z,ojeda,NA https://github.com/rust-lang/rust/pull/96240,OPEN,2022-04-20T04:43:52Z,NA,Stabilize `const_ptr_offset_from`.,fee1-dead,NA,NA,NA,HEART,2022-05-20T06:38:22Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/96246,MERGED,2022-04-20T11:11:22Z,2022-04-25T13:27:57Z,Add `BoundKind` in `visit_param_bounds` to check questions in bounds,SparrowLii,7417110cefda899a685a77557ac2bd7d7ee07e54,5,Auto merge of #96246 - SparrowLii:bound_contxet r=compiler-errors Add `BoundKind` in `visit_param_bounds` to check questions in bounds From the FIXME in the impl of `AstValidator`. Better bound checks by adding `BoundCtxt` type parameter to `visit_param_bound` cc `@ecstatic-morse`,THUMBS_UP,2022-04-21T11:24:59Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/96260,MERGED,2022-04-20T22:17:15Z,2022-04-21T21:20:18Z,rustdoc: Optimize IdMap,Kobzol,de1bc0008be096cf7ed67b93402250d3b3e480d0,3,Auto merge of #96260 - Kobzol:rustdoc-idmap r=petrochenkov rustdoc: Optimize IdMap Slightly optimizes `IdMap` which is hot in `markdown_links` (context [here](https://github.com/rust-lang/rust/pull/96135#issuecomment-1103539052)). There are more improvements that can be made near this place but this seemed like an easy win locally (although I tried it on top of https://github.com/rust-lang/rust/pull/94857 so let's see what happens without that PR). r? `@petrochenkov`,ROCKET,2022-04-21T21:27:56Z,lqd,NA https://github.com/rust-lang/rust/pull/96271,MERGED,2022-04-21T06:21:27Z,2022-06-01T20:06:26Z,suggest `?` when method is missing on `Result` but found on `T`,compiler-errors,7d4cf710e2678d31fd899c452e1d4baf48eb8a86,4,Rollup merge of #96271 - compiler-errors:suggest-question-mark r=estebank suggest `?` when method is missing on `Result` but found on `T` The wording needs help I think. Fixes #95729,HEART,2022-04-23T20:39:34Z,estebank,NA https://github.com/rust-lang/rust/pull/96271,MERGED,2022-04-21T06:21:27Z,2022-06-01T20:06:26Z,suggest `?` when method is missing on `Result` but found on `T`,compiler-errors,7d4cf710e2678d31fd899c452e1d4baf48eb8a86,4,Rollup merge of #96271 - compiler-errors:suggest-question-mark r=estebank suggest `?` when method is missing on `Result` but found on `T` The wording needs help I think. Fixes #95729,HEART,2022-06-09T16:08:10Z,kangalioo,NA https://github.com/rust-lang/rust/pull/96272,MERGED,2022-04-21T07:31:58Z,2022-04-22T22:12:53Z,Update `validate_uninhabited_zsts.rs` test after MIR building changes,tmiasko,98346744ac772bbe20163108c751754ebad33ecf,3,Rollup merge of #96272 - tmiasko:validate-uninhabited r=RalfJung Update `validate_uninhabited_zsts.rs` test after MIR building changes to ensure that it still tests validation instead of failing earlier on during evaluation. r? `@RalfJung`,HEART,2022-04-21T13:53:24Z,RalfJung,NA https://github.com/rust-lang/rust/pull/96281,MERGED,2022-04-21T10:33:44Z,2022-04-24T04:04:12Z,Optimize `const_prop` mir-opt by accessing `local_decls` through `ecx`,SparrowLii,b21759f5509477522a208b27bec5822d89f7c6b8,2,Auto merge of #96281 - SparrowLii:const_prop r=wesleywiser Optimize `const_prop` mir-opt by accessing `local_decls` through `ecx` From the FIXME in the impl of `ConstPropagator`. Accessing `local_decls` and `scource_scopes` from `ecx` can reduce `clone` calls and save compile time. Besides according to #96213 the FIXME about writing `layouts` to `ecx` in advance can also be removed.,THUMBS_UP,2022-04-21T11:24:54Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-21T14:57:25Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-21T16:31:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-21T16:50:23Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-21T21:12:09Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-22T00:02:39Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-04-22T11:05:09Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-05-05T07:07:02Z,mohe2015,NA https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-06-04T05:52:38Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-06-15T03:53:00Z,hudson-ayers,NA https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HEART,2022-06-15T08:01:36Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/96285,MERGED,2022-04-21T13:44:08Z,2022-06-15T00:18:11Z,Introduce `-Zvirtual-function-elimination` codegen flag,flip1995,2d1e0750792529248ed6f11061940c7203d668c9,20,Auto merge of #96285 - flip1995:pk-vfe r=nagisa Introduce `-Zvirtual-function-elimination` codegen flag Fixes #68262 This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work additonal information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore instead of just `load`ing functions the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables. For technical details of the changes see the commit messages. I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions. [Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination),HOORAY,2022-06-15T11:54:38Z,ppannuto,pat.pannuto@gmail.com https://github.com/rust-lang/rust/pull/96296,MERGED,2022-04-21T20:51:07Z,2022-06-03T09:56:27Z,Remove label/lifetime shadowing warnings,cjgillot,3a90bedb332d7d7eabfc1e98a1e3d96898579e1d,31,"Auto merge of #96296 - cjgillot:remove-label-lt-shadow r=petrochenkov Remove label/lifetime shadowing warnings This PR removes some pre-1.0 shadowing warnings for labels and lifetimes. The current behaviour of the compiler is to warn * labels that shadow unrelated labels in the same function --> removed ```rust 'a: loop {} 'a: loop {} // STOP WARNING ``` * labels that shadow enclosing labels --> kept but only if shadowing is hygienic ```rust 'a: loop { 'a: loop {} // KEEP WARNING } ``` * labels that shadow lifetime --> removed ```rust fn foo<'a>() { 'a: loop {} // STOP WARNING } ``` * lifetimes that shadow labels --> removed ```rust 'a: loop { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // STOP WARNING } ``` * lifetimes that shadow lifetimes --> kept ```rust fn foo<'a>() { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // KEEP WARNING } ``` Closes https://github.com/rust-lang/rust/issues/31745. ----- From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014 > I think we should remove these silly checks entirely. > They were introduced long time ago in case some new language features appear and require this space. > Now we have another mechanism for such language changes - editions and if ""lifetimes in expressions"" or something like that needs to be introduced it could be introduced as an edition change. > However there was no plans to introduce anything like for years so it's unlikely that even the edition mechanism will be necessary. r? rust-lang/lang",HEART,2022-05-03T20:11:57Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96296,MERGED,2022-04-21T20:51:07Z,2022-06-03T09:56:27Z,Remove label/lifetime shadowing warnings,cjgillot,3a90bedb332d7d7eabfc1e98a1e3d96898579e1d,31,"Auto merge of #96296 - cjgillot:remove-label-lt-shadow r=petrochenkov Remove label/lifetime shadowing warnings This PR removes some pre-1.0 shadowing warnings for labels and lifetimes. The current behaviour of the compiler is to warn * labels that shadow unrelated labels in the same function --> removed ```rust 'a: loop {} 'a: loop {} // STOP WARNING ``` * labels that shadow enclosing labels --> kept but only if shadowing is hygienic ```rust 'a: loop { 'a: loop {} // KEEP WARNING } ``` * labels that shadow lifetime --> removed ```rust fn foo<'a>() { 'a: loop {} // STOP WARNING } ``` * lifetimes that shadow labels --> removed ```rust 'a: loop { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // STOP WARNING } ``` * lifetimes that shadow lifetimes --> kept ```rust fn foo<'a>() { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // KEEP WARNING } ``` Closes https://github.com/rust-lang/rust/issues/31745. ----- From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014 > I think we should remove these silly checks entirely. > They were introduced long time ago in case some new language features appear and require this space. > Now we have another mechanism for such language changes - editions and if ""lifetimes in expressions"" or something like that needs to be introduced it could be introduced as an edition change. > However there was no plans to introduce anything like for years so it's unlikely that even the edition mechanism will be necessary. r? rust-lang/lang",HEART,2022-05-03T21:19:30Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/96296,MERGED,2022-04-21T20:51:07Z,2022-06-03T09:56:27Z,Remove label/lifetime shadowing warnings,cjgillot,3a90bedb332d7d7eabfc1e98a1e3d96898579e1d,31,"Auto merge of #96296 - cjgillot:remove-label-lt-shadow r=petrochenkov Remove label/lifetime shadowing warnings This PR removes some pre-1.0 shadowing warnings for labels and lifetimes. The current behaviour of the compiler is to warn * labels that shadow unrelated labels in the same function --> removed ```rust 'a: loop {} 'a: loop {} // STOP WARNING ``` * labels that shadow enclosing labels --> kept but only if shadowing is hygienic ```rust 'a: loop { 'a: loop {} // KEEP WARNING } ``` * labels that shadow lifetime --> removed ```rust fn foo<'a>() { 'a: loop {} // STOP WARNING } ``` * lifetimes that shadow labels --> removed ```rust 'a: loop { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // STOP WARNING } ``` * lifetimes that shadow lifetimes --> kept ```rust fn foo<'a>() { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // KEEP WARNING } ``` Closes https://github.com/rust-lang/rust/issues/31745. ----- From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014 > I think we should remove these silly checks entirely. > They were introduced long time ago in case some new language features appear and require this space. > Now we have another mechanism for such language changes - editions and if ""lifetimes in expressions"" or something like that needs to be introduced it could be introduced as an edition change. > However there was no plans to introduce anything like for years so it's unlikely that even the edition mechanism will be necessary. r? rust-lang/lang",HEART,2022-05-23T13:11:21Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96296,MERGED,2022-04-21T20:51:07Z,2022-06-03T09:56:27Z,Remove label/lifetime shadowing warnings,cjgillot,3a90bedb332d7d7eabfc1e98a1e3d96898579e1d,31,"Auto merge of #96296 - cjgillot:remove-label-lt-shadow r=petrochenkov Remove label/lifetime shadowing warnings This PR removes some pre-1.0 shadowing warnings for labels and lifetimes. The current behaviour of the compiler is to warn * labels that shadow unrelated labels in the same function --> removed ```rust 'a: loop {} 'a: loop {} // STOP WARNING ``` * labels that shadow enclosing labels --> kept but only if shadowing is hygienic ```rust 'a: loop { 'a: loop {} // KEEP WARNING } ``` * labels that shadow lifetime --> removed ```rust fn foo<'a>() { 'a: loop {} // STOP WARNING } ``` * lifetimes that shadow labels --> removed ```rust 'a: loop { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // STOP WARNING } ``` * lifetimes that shadow lifetimes --> kept ```rust fn foo<'a>() { let b = Box::new(|x: &i8| *x) as Box Fn(&'a i8) -> i8>; // KEEP WARNING } ``` Closes https://github.com/rust-lang/rust/issues/31745. ----- From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014 > I think we should remove these silly checks entirely. > They were introduced long time ago in case some new language features appear and require this space. > Now we have another mechanism for such language changes - editions and if ""lifetimes in expressions"" or something like that needs to be introduced it could be introduced as an edition change. > However there was no plans to introduce anything like for years so it's unlikely that even the edition mechanism will be necessary. r? rust-lang/lang",HEART,2022-05-26T03:01:16Z,GrayJack,NA https://github.com/rust-lang/rust/pull/96298,MERGED,2022-04-21T21:20:01Z,2022-05-27T03:27:05Z,libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions,petrochenkov,4f68efad64f6a54703521d465817b6103813694d,9,Auto merge of #96298 - petrochenkov:fromgen r=estebank libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions An equally useful little helper. I didn't follow any of the async-wg work so I don't know why something like this wasn't added before.,THUMBS_UP,2022-04-21T23:46:14Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96298,MERGED,2022-04-21T21:20:01Z,2022-05-27T03:27:05Z,libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions,petrochenkov,4f68efad64f6a54703521d465817b6103813694d,9,Auto merge of #96298 - petrochenkov:fromgen r=estebank libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions An equally useful little helper. I didn't follow any of the async-wg work so I don't know why something like this wasn't added before.,THUMBS_UP,2022-04-23T03:54:59Z,arniu,NA https://github.com/rust-lang/rust/pull/96298,MERGED,2022-04-21T21:20:01Z,2022-05-27T03:27:05Z,libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions,petrochenkov,4f68efad64f6a54703521d465817b6103813694d,9,Auto merge of #96298 - petrochenkov:fromgen r=estebank libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions An equally useful little helper. I didn't follow any of the async-wg work so I don't know why something like this wasn't added before.,THUMBS_UP,2022-04-23T11:19:44Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/96298,MERGED,2022-04-21T21:20:01Z,2022-05-27T03:27:05Z,libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions,petrochenkov,4f68efad64f6a54703521d465817b6103813694d,9,Auto merge of #96298 - petrochenkov:fromgen r=estebank libcore: Add `iter::from_generator` which is like `iter::from_fn` but for coroutines instead of functions An equally useful little helper. I didn't follow any of the async-wg work so I don't know why something like this wasn't added before.,THUMBS_UP,2022-05-26T15:08:54Z,estebank,NA https://github.com/rust-lang/rust/pull/96301,MERGED,2022-04-22T00:07:06Z,2022-04-22T19:28:07Z,rustdoc: make primitive synthetic impls for correct doc module,notriddle,5ffebc2cb3a089c27a4c7da13d09fd2365c288aa,1,"Auto merge of #96301 - notriddle:notriddle/synthetic-impl-prim r=GuillaumeGomez rustdoc: make primitive synthetic impls for correct doc module This improves the accuracy of libcore primitive docs which was missing the blanket and auto impls for most primitive types. To test this compare nightly [libcore::str] docs which lack auto traits like Send with [std::str] docs which show them. [libcore::str]: https://doc.rust-lang.org/nightly/core/primitive.str.html [libstd::str]: https://doc.rust-lang.org/nightly/std/primitive.str.html It also avoids getting synthetic impls for primitive types on crates that do not actually show them.
Before and After trace logs ## Before [notriddle@deep-thought test-dingus]$ RUSTDOC_LOG=rustdoc=trace rustdoc +nightly test.rs 2>&1 | grep -E 'get_blanket_impls\(' TRACE rustdoc::clean::blanket_impl get_blanket_impls(Whatever) TRACE rustdoc::clean::blanket_impl get_blanket_impls(isize) TRACE rustdoc::clean::blanket_impl get_blanket_impls([T]) TRACE rustdoc::clean::blanket_impl get_blanket_impls([u8]) TRACE rustdoc::clean::blanket_impl get_blanket_impls([T]) TRACE rustdoc::clean::blanket_impl get_blanket_impls([u8]) TRACE rustdoc::clean::blanket_impl get_blanket_impls(char) TRACE rustdoc::clean::blanket_impl get_blanket_impls(u128) TRACE rustdoc::clean::blanket_impl get_blanket_impls(u16) TRACE rustdoc::clean::blanket_impl get_blanket_impls(i128) TRACE rustdoc::clean::blanket_impl get_blanket_impls(i16) TRACE rustdoc::clean::blanket_impl get_blanket_impls(str) TRACE rustdoc::clean::blanket_impl get_blanket_impls(str) TRACE rustdoc::clean::blanket_impl get_blanket_impls(f64) TRACE rustdoc::clean::blanket_impl get_blanket_impls(f64) TRACE rustdoc::clean::blanket_impl get_blanket_impls(u64) TRACE rustdoc::clean::blanket_impl get_blanket_impls(u8) TRACE rustdoc::clean::blanket_impl get_blanket_impls(i64) TRACE rustdoc::clean::blanket_impl get_blanket_impls(i8) TRACE rustdoc::clean::blanket_impl get_blanket_impls(*const T) TRACE rustdoc::clean::blanket_impl get_blanket_impls(*mut T) TRACE rustdoc::clean::blanket_impl get_blanket_impls(*const [T]) TRACE rustdoc::clean::blanket_impl get_blanket_impls(*mut [T]) TRACE rustdoc::clean::blanket_impl get_blanket_impls([T; N]) TRACE rustdoc::clean::blanket_impl get_blanket_impls(bool) TRACE rustdoc::clean::blanket_impl get_blanket_impls(f32) TRACE rustdoc::clean::blanket_impl get_blanket_impls(f32) TRACE rustdoc::clean::blanket_impl get_blanket_impls(u32) TRACE rustdoc::clean::blanket_impl get_blanket_impls(usize) TRACE rustdoc::clean::blanket_impl get_blanket_impls(i32) ## After [notriddle@deep-thought test-dingus]$ RUSTDOC_LOG=rustdoc=trace rustdoc +dev test.rs 2>&1 | grep -E 'get_blanket_impls\(' TRACE rustdoc::clean::blanket_impl get_blanket_impls(Whatever)
",THUMBS_UP,2022-04-22T16:36:49Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/96361,MERGED,2022-04-24T13:38:04Z,2022-04-26T18:48:54Z,Switch JS code to ES6,GuillaumeGomez,52fefb0454405763dc0b8ebe9f1fb927df3ca2d3,3,Rollup merge of #96361 - GuillaumeGomez:es6 r=notriddle Switch JS code to ES6 Considering it's already quite big I'll do the remaining files in another PR. Part of #93058. r? ``@notriddle``,THUMBS_UP,2022-04-24T14:45:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/96361,MERGED,2022-04-24T13:38:04Z,2022-04-26T18:48:54Z,Switch JS code to ES6,GuillaumeGomez,52fefb0454405763dc0b8ebe9f1fb927df3ca2d3,3,Rollup merge of #96361 - GuillaumeGomez:es6 r=notriddle Switch JS code to ES6 Considering it's already quite big I'll do the remaining files in another PR. Part of #93058. r? ``@notriddle``,THUMBS_UP,2022-04-24T16:08:10Z,fmease,NA https://github.com/rust-lang/rust/pull/96361,MERGED,2022-04-24T13:38:04Z,2022-04-26T18:48:54Z,Switch JS code to ES6,GuillaumeGomez,52fefb0454405763dc0b8ebe9f1fb927df3ca2d3,3,Rollup merge of #96361 - GuillaumeGomez:es6 r=notriddle Switch JS code to ES6 Considering it's already quite big I'll do the remaining files in another PR. Part of #93058. r? ``@notriddle``,THUMBS_UP,2022-04-24T17:30:32Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96361,MERGED,2022-04-24T13:38:04Z,2022-04-26T18:48:54Z,Switch JS code to ES6,GuillaumeGomez,52fefb0454405763dc0b8ebe9f1fb927df3ca2d3,3,Rollup merge of #96361 - GuillaumeGomez:es6 r=notriddle Switch JS code to ES6 Considering it's already quite big I'll do the remaining files in another PR. Part of #93058. r? ``@notriddle``,THUMBS_UP,2022-04-24T19:09:56Z,Gumichocopengin8,NA https://github.com/rust-lang/rust/pull/96361,MERGED,2022-04-24T13:38:04Z,2022-04-26T18:48:54Z,Switch JS code to ES6,GuillaumeGomez,52fefb0454405763dc0b8ebe9f1fb927df3ca2d3,3,Rollup merge of #96361 - GuillaumeGomez:es6 r=notriddle Switch JS code to ES6 Considering it's already quite big I'll do the remaining files in another PR. Part of #93058. r? ``@notriddle``,THUMBS_UP,2022-04-25T04:00:16Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-25T01:51:15Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-25T08:14:20Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-25T10:52:45Z,CryZe,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-25T11:16:09Z,darksv,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-26T05:30:42Z,Milo123459,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-26T06:54:11Z,nico-abram,abramlujan@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-04-26T09:53:22Z,pro465,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-01T16:27:39Z,jakevossen5,jake@vossen.dev https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-01T17:00:22Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-05T04:39:09Z,lambda-fairy,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-05T18:43:00Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-05-05T18:43:04Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T00:54:50Z,jtescher,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-05-06T04:20:39Z,fregante,me@fregante.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T04:30:25Z,josephlr,joerichey@google.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T05:00:24Z,null-dev,contact@andybao.me https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T05:25:40Z,alecdwm,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T07:52:18Z,arzg,aramisnoah@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T08:17:09Z,shirshak55,shirshak55@pm.me https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T09:00:38Z,mulholo,james@jmulholland.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T09:14:23Z,cglong,chris@chrislong.dev https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T11:39:29Z,asdrubalini,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T12:08:32Z,WilliamBenEmbarek,william@embar.io https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T12:18:16Z,wongmjane,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T12:42:04Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T14:14:52Z,brooksprumo,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T14:26:10Z,poulad,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T14:28:44Z,LHolten,lhc.holten@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T14:48:08Z,jharrilim,Josephharrisonlim@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-05-06T14:48:12Z,jharrilim,Josephharrisonlim@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-05-06T15:04:43Z,ma-anwar,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T15:14:58Z,chengyuhui,chengyuhui1@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T16:10:02Z,camerondurham,u64.cam@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T16:32:56Z,matthewgrossman,matt@mrgrossman.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T17:56:03Z,kcpru,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T19:04:39Z,vimpostor,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-05-06T20:44:05Z,SawyerHood,sawyerjhood@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T20:44:07Z,SawyerHood,sawyerjhood@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T21:41:22Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T21:46:20Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-06T23:25:37Z,The-Fireplace,github@the-fireplace.dev https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T01:33:43Z,BitPhinix,ericmeier@protonmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T03:04:42Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-05-07T03:04:43Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-05-07T03:04:44Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T13:56:34Z,UgnilJoZ,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T14:33:29Z,uncomfyhalomacro,socvirnyl.estela@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T16:44:12Z,BasixKOR,basix@basix.tech https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-07T21:53:29Z,it-is-wednesday,git@avocadosh.xyz https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-09T03:25:08Z,stoicnerd,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-05-11T21:42:22Z,willdebras,wbonnell123@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-05-11T21:42:23Z,willdebras,wbonnell123@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-12T05:59:34Z,Sid110307,srsfool@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-12T05:59:35Z,Sid110307,srsfool@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-12T19:06:23Z,Pontenerd,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-13T02:36:06Z,camerondurham,u64.cam@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-14T08:03:50Z,neelkarma,nsdj.sharma@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-14T08:03:51Z,neelkarma,nsdj.sharma@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-06-14T08:03:51Z,neelkarma,nsdj.sharma@gmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-14T08:51:39Z,VytskaLT,VytskaLT@protonmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-14T17:43:42Z,osbm,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-14T19:40:30Z,iczero,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-14T19:40:33Z,iczero,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-16T20:23:02Z,Linuxydable,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-06-16T20:23:03Z,Linuxydable,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-16T20:23:04Z,Linuxydable,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-22T11:07:38Z,GD-1z2,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-06-22T11:07:39Z,GD-1z2,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-06-22T11:07:42Z,GD-1z2,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-06-23T01:47:09Z,aromaa,me@joniaromaa.fi https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-07-03T19:27:29Z,SuperchupuDev,NA https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,LAUGH,2022-07-04T17:56:25Z,luccahuguet,luccahuguet@hotmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,ROCKET,2022-07-04T17:56:26Z,luccahuguet,luccahuguet@hotmail.com https://github.com/rust-lang/rust/pull/96376,MERGED,2022-04-25T01:28:55Z,2022-05-01T15:25:15Z,Add `do yeet` expressions to allow experimentation in nightly,scottmcm,508e0584e384556b7e66f57b62e4feeba864b6da,33,Auto merge of #96376 - scottmcm:do-yeet r=oli-obk Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716 Tracking issues - Lang https://github.com/rust-lang/rust/issues/96373 - Libs-api https://github.com/rust-lang/rust/issues/96374,THUMBS_UP,2022-07-04T17:56:27Z,luccahuguet,luccahuguet@hotmail.com https://github.com/rust-lang/rust/pull/96378,MERGED,2022-04-25T04:11:02Z,2022-05-18T09:53:04Z,Mention traits and types involved in unstable trait upcasting,compiler-errors,49048eab47b2bb6cbba518c6477d0054cc3fc780,3,"Rollup merge of #96378 - compiler-errors:trait-upcast-error r=nagisa Mention traits and types involved in unstable trait upcasting Fixes #95972 by printing the traits being upcasted and the types being coerced that cause that upcasting... --- the poor span mentioned in the original issue has nothing to do with trait upcasting diagnostic here... > The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying ""somewhere here trait coercion is used and it's not allowed"". I don't think I can solve that issue in general without fixing the ObligationCauseCode and span that gets passed into Coerce.",HEART,2022-05-18T16:27:18Z,estebank,NA https://github.com/rust-lang/rust/pull/96378,MERGED,2022-04-25T04:11:02Z,2022-05-18T09:53:04Z,Mention traits and types involved in unstable trait upcasting,compiler-errors,49048eab47b2bb6cbba518c6477d0054cc3fc780,3,"Rollup merge of #96378 - compiler-errors:trait-upcast-error r=nagisa Mention traits and types involved in unstable trait upcasting Fixes #95972 by printing the traits being upcasted and the types being coerced that cause that upcasting... --- the poor span mentioned in the original issue has nothing to do with trait upcasting diagnostic here... > The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying ""somewhere here trait coercion is used and it's not allowed"". I don't think I can solve that issue in general without fixing the ObligationCauseCode and span that gets passed into Coerce.",HEART,2022-05-18T19:04:03Z,jonay2000,jonabent@gmail.com https://github.com/rust-lang/rust/pull/96379,MERGED,2022-04-25T04:50:17Z,2022-04-26T04:48:39Z,delay bug when adjusting `NeverToAny` twice during diagnostic code,PrestonFrom,8038a9ece34a24b5722ea11f6918e4329276cdac,3,Rollup merge of #96379 - PrestonFrom:issue_96335 r=compiler-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (https://github.com/rust-lang/rust/issues/96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes #96335,HEART,2022-04-25T05:25:16Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96379,MERGED,2022-04-25T04:50:17Z,2022-04-26T04:48:39Z,delay bug when adjusting `NeverToAny` twice during diagnostic code,PrestonFrom,8038a9ece34a24b5722ea11f6918e4329276cdac,3,Rollup merge of #96379 - PrestonFrom:issue_96335 r=compiler-errors delay bug when adjusting `NeverToAny` twice during diagnostic code Addresses Issue 96335 (https://github.com/rust-lang/rust/issues/96335) by using `delay_span_bug` instead of an assert and returning an error type from `check_expr_meets_expectation_or_error`. Fixes #96335,HEART,2022-04-25T05:55:37Z,PeterWrighten,peterwrighten@gmail.com https://github.com/rust-lang/rust/pull/96385,MERGED,2022-04-25T07:33:02Z,2022-04-27T03:42:49Z,Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL,marmeladema,dc1f98c6558730fa446e05856d28b09b0ca4ebc8,14,Rollup merge of #96385 - marmeladema:nll-fix-trait-lifetime-bound-suggestions r=jackh726 Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL This is done by replacing the duplicated (and very partial) implementation from borrowck with one inspsired from `NiceRegionError::try_report_static_impl_trait` and by re-using `suggest_new_region_bound`. Fixes #96277 r? ```@jackh726```,HEART,2022-04-25T08:07:28Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96385,MERGED,2022-04-25T07:33:02Z,2022-04-27T03:42:49Z,Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL,marmeladema,dc1f98c6558730fa446e05856d28b09b0ca4ebc8,14,Rollup merge of #96385 - marmeladema:nll-fix-trait-lifetime-bound-suggestions r=jackh726 Recover most `impl Trait` and `dyn Trait` lifetime bound suggestions under NLL This is done by replacing the duplicated (and very partial) implementation from borrowck with one inspsired from `NiceRegionError::try_report_static_impl_trait` and by re-using `suggest_new_region_bound`. Fixes #96277 r? ```@jackh726```,HEART,2022-06-10T18:52:53Z,ClementNerma,clement.nerma@gmail.com https://github.com/rust-lang/rust/pull/96393,MERGED,2022-04-25T13:31:00Z,2022-04-29T00:38:53Z,std: directly use pthread in UNIX parker implementation,joboet,baaa3b682986879c7784b5733ecea942e9ae7de3,9,Auto merge of #96393 - joboet:pthread_parker r=thomcc std: directly use pthread in UNIX parker implementation `Mutex` and `Condvar` are being replaced by more efficient implementations which need thread parking themselves (see #93740). Therefore we should use the `pthread` synchronization primitives directly. Also we can avoid allocating the mutex and condition variable because the `Parker` struct is being placed in an `Arc` anyways. This basically is just a copy of the current `Mutex` and `Condvar` code which will however be removed (again see #93740). An alternative implementation could be to use dedicated private `OsMutex` and `OsCondvar` types but all the other platforms supported by std actually have their own thread parking primitives. I used `Pin` to guarantee a stable address for the `Parker` struct while the current implementation does not rather using extra unsafe declaration. Since the thread struct is shared anyways I assumed this would not add too much clutter while being clearer.,HEART,2022-04-25T16:29:39Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/96393,MERGED,2022-04-25T13:31:00Z,2022-04-29T00:38:53Z,std: directly use pthread in UNIX parker implementation,joboet,baaa3b682986879c7784b5733ecea942e9ae7de3,9,Auto merge of #96393 - joboet:pthread_parker r=thomcc std: directly use pthread in UNIX parker implementation `Mutex` and `Condvar` are being replaced by more efficient implementations which need thread parking themselves (see #93740). Therefore we should use the `pthread` synchronization primitives directly. Also we can avoid allocating the mutex and condition variable because the `Parker` struct is being placed in an `Arc` anyways. This basically is just a copy of the current `Mutex` and `Condvar` code which will however be removed (again see #93740). An alternative implementation could be to use dedicated private `OsMutex` and `OsCondvar` types but all the other platforms supported by std actually have their own thread parking primitives. I used `Pin` to guarantee a stable address for the `Parker` struct while the current implementation does not rather using extra unsafe declaration. Since the thread struct is shared anyways I assumed this would not add too much clutter while being clearer.,HEART,2022-04-26T09:56:53Z,pro465,NA https://github.com/rust-lang/rust/pull/96393,MERGED,2022-04-25T13:31:00Z,2022-04-29T00:38:53Z,std: directly use pthread in UNIX parker implementation,joboet,baaa3b682986879c7784b5733ecea942e9ae7de3,9,Auto merge of #96393 - joboet:pthread_parker r=thomcc std: directly use pthread in UNIX parker implementation `Mutex` and `Condvar` are being replaced by more efficient implementations which need thread parking themselves (see #93740). Therefore we should use the `pthread` synchronization primitives directly. Also we can avoid allocating the mutex and condition variable because the `Parker` struct is being placed in an `Arc` anyways. This basically is just a copy of the current `Mutex` and `Condvar` code which will however be removed (again see #93740). An alternative implementation could be to use dedicated private `OsMutex` and `OsCondvar` types but all the other platforms supported by std actually have their own thread parking primitives. I used `Pin` to guarantee a stable address for the `Parker` struct while the current implementation does not rather using extra unsafe declaration. Since the thread struct is shared anyways I assumed this would not add too much clutter while being clearer.,HEART,2022-04-29T17:31:11Z,DesmondWillowbrook,sendtokartavya@gmail.com https://github.com/rust-lang/rust/pull/96405,MERGED,2022-04-25T20:57:33Z,2022-04-28T21:58:15Z,Migrate ambiguous plus diagnostic to the new derive macro,pvdrz,b3329f84f4aa52216f6334ce56608a78ace0a98f,7,Rollup merge of #96405 - pvdrz:ambiguous-plus-diagnostic r=davidtwco Migrate ambiguous plus diagnostic to the new derive macro r? ````@davidtwco```` ````@jyn514````,HEART,2022-04-26T00:35:25Z,estebank,NA https://github.com/rust-lang/rust/pull/96405,MERGED,2022-04-25T20:57:33Z,2022-04-28T21:58:15Z,Migrate ambiguous plus diagnostic to the new derive macro,pvdrz,b3329f84f4aa52216f6334ce56608a78ace0a98f,7,Rollup merge of #96405 - pvdrz:ambiguous-plus-diagnostic r=davidtwco Migrate ambiguous plus diagnostic to the new derive macro r? ````@davidtwco```` ````@jyn514````,HEART,2022-04-26T08:48:59Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-26T21:08:43Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-26T21:49:06Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-27T05:20:09Z,faptc,NA https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-28T10:08:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-29T18:10:05Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-04-30T14:19:32Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-05-06T19:29:46Z,Agrailag,NA https://github.com/rust-lang/rust/pull/96451,OPEN,2022-04-26T20:22:38Z,NA,Fix Dest Prop,JakobDegen,NA,NA,NA,HEART,2022-05-19T07:01:39Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96454,CLOSED,2022-04-26T22:37:40Z,2022-04-27T05:24:03Z,DONOTLAND (perf-only): Disable potentially unsound int2ptr/ptr2int optimizations,thomcc,NA,NA,NA,EYES,2022-04-26T22:40:45Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-04-26T23:44:42Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-04-27T04:46:08Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-04-28T10:30:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-05-06T00:52:21Z,teor2345,teor@riseup.net https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-05-06T22:48:15Z,AaronKutch,aaronkutch@att.net https://github.com/rust-lang/rust/pull/96455,MERGED,2022-04-26T22:55:40Z,2022-05-23T05:31:41Z,Make write/print macros eagerly drop temporaries,dtolnay,c186f7c07912064c352f12d8b0aa9d5e5975450e,4,"Auto merge of #96455 - dtolnay:writetmp r=m-ou-se Make write/print macros eagerly drop temporaries This PR fixes the 2 regressions in #96434 (`println` and `eprintln`) and changes all the other similar macros (`write` `writeln` `print` `eprint`) to match the old pre-#94868 behavior of `println` and `eprintln`. argument position | before #94868 | after #94868 | after this PR --- |:---:|:---:|:---: `write!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `write!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `writeln!($tmp ""…"" …)` | :rage: | :rage: | :smiley_cat: `writeln!(… ""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `print!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `println!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `eprint!(""…"" $tmp)` | :rage: | :rage: | :smiley_cat: `eprintln!(""…"" $tmp)` | :smiley_cat: | :rage: | :smiley_cat: `panic!(""…"" $tmp)` | :smiley_cat: | :smiley_cat: | :smiley_cat: Example of code that is affected by this change: ```rust use std::sync::Mutex; fn main() { let mutex = Mutex::new(0); print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ } ``` You can see several real-world examples like this in the Crater links at the top of #96434. This code failed to compile prior to this PR as follows but works after this PR. ```console error[E0597]: `mutex` does not live long enough --> src/main.rs:5:18 | 5 | print!(""{}"" mutex.lock().unwrap()) /* no semicolon */ | ^^^^^^^^^^^^--------- | | | borrowed value does not live long enough | a temporary with access to the borrow is created here ... 6 | } | - | | | `mutex` dropped here while still borrowed | ... and the borrow might be used here when that temporary is dropped and runs the `Drop` code for type `MutexGuard` ```",HEART,2022-06-14T16:17:02Z,pro465,NA https://github.com/rust-lang/rust/pull/96458,MERGED,2022-04-27T00:36:08Z,2022-05-07T01:11:14Z,Don't cache results of coinductive cycle,Aaron1011,4799baa70d0ff1780ee6dffb743d62c79235ace9,1,Auto merge of #96458 - Aaron1011:no-cycle-caching r=jackh726 cjgillot Don't cache results of coinductive cycle,EYES,2022-04-27T01:31:49Z,estebank,NA https://github.com/rust-lang/rust/pull/96458,MERGED,2022-04-27T00:36:08Z,2022-05-07T01:11:14Z,Don't cache results of coinductive cycle,Aaron1011,4799baa70d0ff1780ee6dffb743d62c79235ace9,1,Auto merge of #96458 - Aaron1011:no-cycle-caching r=jackh726 cjgillot Don't cache results of coinductive cycle,THUMBS_UP,2022-04-27T01:31:54Z,estebank,NA https://github.com/rust-lang/rust/pull/96458,MERGED,2022-04-27T00:36:08Z,2022-05-07T01:11:14Z,Don't cache results of coinductive cycle,Aaron1011,4799baa70d0ff1780ee6dffb743d62c79235ace9,1,Auto merge of #96458 - Aaron1011:no-cycle-caching r=jackh726 cjgillot Don't cache results of coinductive cycle,EYES,2022-04-27T03:03:42Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96458,MERGED,2022-04-27T00:36:08Z,2022-05-07T01:11:14Z,Don't cache results of coinductive cycle,Aaron1011,4799baa70d0ff1780ee6dffb743d62c79235ace9,1,Auto merge of #96458 - Aaron1011:no-cycle-caching r=jackh726 cjgillot Don't cache results of coinductive cycle,EYES,2022-04-27T10:14:37Z,gimbles,NA https://github.com/rust-lang/rust/pull/96468,MERGED,2022-04-27T05:22:45Z,2022-04-29T14:39:20Z,macros: subdiagnostic derive,davidtwco,683c582c1e88c573c454b7fa6f00bc6647421864,32,"Auto merge of #96468 - davidtwco:diagnostic-translation-subdiagnostic r=oli-obk macros: subdiagnostic derive Add a new macro `#[derive(SessionSubdiagnostic)]` which can be applied to structs that represent subdiagnostics such as labels notes helps or suggestions. `#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable and this new derive should make it easier to port existing diagnostics to using these derives. For example consider the following subdiagnostic types... ```rust #[derive(SessionSubdiagnostic)] pub enum ExpectedIdentifierLabel<'tcx> { #[label(slug = ""parser-expected-identifier"")] WithoutFound { #[primary_span] span: Span } #[label(slug = ""parser-expected-identifier-found"")] WithFound { #[primary_span] span: Span found: String } } #[derive(SessionSubdiagnostic)] #[suggestion_verbose(slug = ""parser-raw-identifier"")] pub struct RawIdentifierSuggestion<'tcx> { #[primary_span] span: Span #[applicability] applicability: Applicability ident: Ident } ``` ...and the corresponding Fluent messages: ```fluent parser-expected-identifier = expected identifier parser-expected-identifier-found = expected identifier found {$found} parser-raw-identifier = escape `{$ident}` to use it as an identifier ``` These can be emitted using the new `subdiagnostic` function on `Diagnostic`... ```rust diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span }); diag.subdiagnostic(RawIdentifierSuggestion { span applicability ident }); ``` ...or as part of a larger `#[derive(SessionDiagnostic)]`: ```rust #[derive(SessionDiagnostic)] #[error(slug = ""parser-expected-identifier"")] pub struct ExpectedIdentifier { #[primary_span] span: Span token_descr: String #[subdiagnostic] label: ExpectedIdentifierLabel #[subdiagnostic] raw_identifier_suggestion: Option } ``` ```rust sess.emit_err(ExpectedIdentifier { ... }); ``` r? `@oli-obk` cc `@pvdrz`",HEART,2022-04-27T18:51:48Z,estebank,NA https://github.com/rust-lang/rust/pull/96468,MERGED,2022-04-27T05:22:45Z,2022-04-29T14:39:20Z,macros: subdiagnostic derive,davidtwco,683c582c1e88c573c454b7fa6f00bc6647421864,32,"Auto merge of #96468 - davidtwco:diagnostic-translation-subdiagnostic r=oli-obk macros: subdiagnostic derive Add a new macro `#[derive(SessionSubdiagnostic)]` which can be applied to structs that represent subdiagnostics such as labels notes helps or suggestions. `#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable and this new derive should make it easier to port existing diagnostics to using these derives. For example consider the following subdiagnostic types... ```rust #[derive(SessionSubdiagnostic)] pub enum ExpectedIdentifierLabel<'tcx> { #[label(slug = ""parser-expected-identifier"")] WithoutFound { #[primary_span] span: Span } #[label(slug = ""parser-expected-identifier-found"")] WithFound { #[primary_span] span: Span found: String } } #[derive(SessionSubdiagnostic)] #[suggestion_verbose(slug = ""parser-raw-identifier"")] pub struct RawIdentifierSuggestion<'tcx> { #[primary_span] span: Span #[applicability] applicability: Applicability ident: Ident } ``` ...and the corresponding Fluent messages: ```fluent parser-expected-identifier = expected identifier parser-expected-identifier-found = expected identifier found {$found} parser-raw-identifier = escape `{$ident}` to use it as an identifier ``` These can be emitted using the new `subdiagnostic` function on `Diagnostic`... ```rust diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span }); diag.subdiagnostic(RawIdentifierSuggestion { span applicability ident }); ``` ...or as part of a larger `#[derive(SessionDiagnostic)]`: ```rust #[derive(SessionDiagnostic)] #[error(slug = ""parser-expected-identifier"")] pub struct ExpectedIdentifier { #[primary_span] span: Span token_descr: String #[subdiagnostic] label: ExpectedIdentifierLabel #[subdiagnostic] raw_identifier_suggestion: Option } ``` ```rust sess.emit_err(ExpectedIdentifier { ... }); ``` r? `@oli-obk` cc `@pvdrz`",THUMBS_UP,2022-04-27T20:07:34Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96468,MERGED,2022-04-27T05:22:45Z,2022-04-29T14:39:20Z,macros: subdiagnostic derive,davidtwco,683c582c1e88c573c454b7fa6f00bc6647421864,32,"Auto merge of #96468 - davidtwco:diagnostic-translation-subdiagnostic r=oli-obk macros: subdiagnostic derive Add a new macro `#[derive(SessionSubdiagnostic)]` which can be applied to structs that represent subdiagnostics such as labels notes helps or suggestions. `#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable and this new derive should make it easier to port existing diagnostics to using these derives. For example consider the following subdiagnostic types... ```rust #[derive(SessionSubdiagnostic)] pub enum ExpectedIdentifierLabel<'tcx> { #[label(slug = ""parser-expected-identifier"")] WithoutFound { #[primary_span] span: Span } #[label(slug = ""parser-expected-identifier-found"")] WithFound { #[primary_span] span: Span found: String } } #[derive(SessionSubdiagnostic)] #[suggestion_verbose(slug = ""parser-raw-identifier"")] pub struct RawIdentifierSuggestion<'tcx> { #[primary_span] span: Span #[applicability] applicability: Applicability ident: Ident } ``` ...and the corresponding Fluent messages: ```fluent parser-expected-identifier = expected identifier parser-expected-identifier-found = expected identifier found {$found} parser-raw-identifier = escape `{$ident}` to use it as an identifier ``` These can be emitted using the new `subdiagnostic` function on `Diagnostic`... ```rust diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span }); diag.subdiagnostic(RawIdentifierSuggestion { span applicability ident }); ``` ...or as part of a larger `#[derive(SessionDiagnostic)]`: ```rust #[derive(SessionDiagnostic)] #[error(slug = ""parser-expected-identifier"")] pub struct ExpectedIdentifier { #[primary_span] span: Span token_descr: String #[subdiagnostic] label: ExpectedIdentifierLabel #[subdiagnostic] raw_identifier_suggestion: Option } ``` ```rust sess.emit_err(ExpectedIdentifier { ... }); ``` r? `@oli-obk` cc `@pvdrz`",HEART,2022-04-28T10:36:52Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96468,MERGED,2022-04-27T05:22:45Z,2022-04-29T14:39:20Z,macros: subdiagnostic derive,davidtwco,683c582c1e88c573c454b7fa6f00bc6647421864,32,"Auto merge of #96468 - davidtwco:diagnostic-translation-subdiagnostic r=oli-obk macros: subdiagnostic derive Add a new macro `#[derive(SessionSubdiagnostic)]` which can be applied to structs that represent subdiagnostics such as labels notes helps or suggestions. `#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable and this new derive should make it easier to port existing diagnostics to using these derives. For example consider the following subdiagnostic types... ```rust #[derive(SessionSubdiagnostic)] pub enum ExpectedIdentifierLabel<'tcx> { #[label(slug = ""parser-expected-identifier"")] WithoutFound { #[primary_span] span: Span } #[label(slug = ""parser-expected-identifier-found"")] WithFound { #[primary_span] span: Span found: String } } #[derive(SessionSubdiagnostic)] #[suggestion_verbose(slug = ""parser-raw-identifier"")] pub struct RawIdentifierSuggestion<'tcx> { #[primary_span] span: Span #[applicability] applicability: Applicability ident: Ident } ``` ...and the corresponding Fluent messages: ```fluent parser-expected-identifier = expected identifier parser-expected-identifier-found = expected identifier found {$found} parser-raw-identifier = escape `{$ident}` to use it as an identifier ``` These can be emitted using the new `subdiagnostic` function on `Diagnostic`... ```rust diag.subdiagnostic(ExpectedIdentifierLabel::WithoutFound { span }); diag.subdiagnostic(RawIdentifierSuggestion { span applicability ident }); ``` ...or as part of a larger `#[derive(SessionDiagnostic)]`: ```rust #[derive(SessionDiagnostic)] #[error(slug = ""parser-expected-identifier"")] pub struct ExpectedIdentifier { #[primary_span] span: Span token_descr: String #[subdiagnostic] label: ExpectedIdentifierLabel #[subdiagnostic] raw_identifier_suggestion: Option } ``` ```rust sess.emit_err(ExpectedIdentifier { ... }); ``` r? `@oli-obk` cc `@pvdrz`",HEART,2022-04-28T22:29:39Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/96471,MERGED,2022-04-27T07:54:24Z,2022-04-28T04:17:57Z,replace let else with `?`,BoxyUwU,4c628bbb1c266a8513b364dca5ae7e311a1e0777,8,Rollup merge of #96471 - BoxyUwU:let_else_considered_harmful r=lcnr replace let else with `?` r? `@oli-obk`,THUMBS_UP,2022-04-27T16:10:58Z,est31,NA https://github.com/rust-lang/rust/pull/96478,OPEN,2022-04-27T15:11:33Z,NA,Implement `#[rustc_default_body_unstable]`,WaffleLapkin,NA,NA,NA,HEART,2022-04-27T17:50:11Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96478,OPEN,2022-04-27T15:11:33Z,NA,Implement `#[rustc_default_body_unstable]`,WaffleLapkin,NA,NA,NA,HEART,2022-04-27T20:08:41Z,rrbutani,NA https://github.com/rust-lang/rust/pull/96478,OPEN,2022-04-27T15:11:33Z,NA,Implement `#[rustc_default_body_unstable]`,WaffleLapkin,NA,NA,NA,HEART,2022-05-20T21:01:20Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/96478,OPEN,2022-04-27T15:11:33Z,NA,Implement `#[rustc_default_body_unstable]`,WaffleLapkin,NA,NA,NA,ROCKET,2022-05-20T21:01:24Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/96478,OPEN,2022-04-27T15:11:33Z,NA,Implement `#[rustc_default_body_unstable]`,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T08:13:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96482,OPEN,2022-04-27T17:03:21Z,NA,Add Output = expected type trait obligation for known binary operators,willcrichton,NA,NA,NA,EYES,2022-04-27T17:08:37Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96493,MERGED,2022-04-27T21:23:14Z,2022-05-13T03:40:39Z,"Add compiletest and bootstrap ""--skip"" option forwarded to libtest",chbaker0,925e774edc34969c337bf65bd92bb8a338fc528d,4,"Auto merge of #96493 - chbaker0:issue-96342-fix r=Mark-Simulacrum Add compiletest and bootstrap ""--skip"" option forwarded to libtest With this PR ""x.py test --skip SKIP ..."" will run the specified test suite but forward ""--skip SKIP"" to the test tool. libtest already supports this option. The PR also adds it to compiletest which itself just forwards it to libtest. Adds the functionality requested in https://github.com/rust-lang/rust/issues/96342. This is useful to work around tests broken upstream. https://github.com/rust-lang/rust/issues/96362#issuecomment-1108609893 is the specific test issue my project is trying to work around.",HOORAY,2022-04-28T15:05:20Z,nico,thakis@chromium.org https://github.com/rust-lang/rust/pull/96496,CLOSED,2022-04-28T01:07:22Z,2022-06-15T20:43:13Z,Implement RFC-2011 (Nicer `assert!` messages),c410-f3r,NA,NA,NA,HEART,2022-04-28T06:52:34Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/96496,CLOSED,2022-04-28T01:07:22Z,2022-06-15T20:43:13Z,Implement RFC-2011 (Nicer `assert!` messages),c410-f3r,NA,NA,NA,HEART,2022-05-20T20:01:35Z,scottlamb,slamb@slamb.org https://github.com/rust-lang/rust/pull/96496,CLOSED,2022-04-28T01:07:22Z,2022-06-15T20:43:13Z,Implement RFC-2011 (Nicer `assert!` messages),c410-f3r,NA,NA,NA,THUMBS_UP,2022-05-20T20:32:08Z,Lokathor,NA https://github.com/rust-lang/rust/pull/96496,CLOSED,2022-04-28T01:07:22Z,2022-06-15T20:43:13Z,Implement RFC-2011 (Nicer `assert!` messages),c410-f3r,NA,NA,NA,HEART,2022-05-28T14:03:55Z,mati865,NA https://github.com/rust-lang/rust/pull/96496,CLOSED,2022-04-28T01:07:22Z,2022-06-15T20:43:13Z,Implement RFC-2011 (Nicer `assert!` messages),c410-f3r,NA,NA,NA,HEART,2022-05-30T14:54:14Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96507,MERGED,2022-04-28T07:55:18Z,2022-05-05T19:28:47Z,Suggest calling `Self::associated_function()`,TaKO8Ki,34bf620ac9fba1f5cfb81b09b0c41147b3b97362,5,Rollup merge of #96507 - TaKO8Ki:suggest-calling-associated-function r=lcnr Suggest calling `Self::associated_function()` closes #96453,HEART,2022-04-28T09:30:43Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/96507,MERGED,2022-04-28T07:55:18Z,2022-05-05T19:28:47Z,Suggest calling `Self::associated_function()`,TaKO8Ki,34bf620ac9fba1f5cfb81b09b0c41147b3b97362,5,Rollup merge of #96507 - TaKO8Ki:suggest-calling-associated-function r=lcnr Suggest calling `Self::associated_function()` closes #96453,HEART,2022-04-29T09:38:38Z,gimbles,NA https://github.com/rust-lang/rust/pull/96536,MERGED,2022-04-28T23:49:54Z,2022-04-30T00:45:46Z,rustdoc: fix missing method list for primitive deref target,notriddle,0b96be79de8cc02483d32d4f503d54a91fcc0a4a,2,Rollup merge of #96536 - rust-lang:notriddle/deref-slice-core r=GuillaumeGomez rustdoc: fix missing method list for primitive deref target This change makes it so that local impls count when listing primitives that need retained. Fixes #95325,HEART,2022-04-30T03:35:12Z,marcospb19,marcospb19@hotmail.com https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-29T16:44:47Z,the8472,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-29T17:22:02Z,Pratyush,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-29T21:55:34Z,faptc,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-30T08:05:47Z,oli-obk,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-30T10:17:48Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-30T16:28:56Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-04-30T17:45:19Z,fmease,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-05-01T23:06:36Z,lqd,NA https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-05-03T22:25:46Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/96557,MERGED,2022-04-29T15:46:17Z,2022-05-06T22:41:19Z,Allow inline consts to reference generic params,nbdd0121,66443a185261a04d7098bb465e2338334a3aa7a4,10,"Rollup merge of #96557 - nbdd0121:const r=oli-obk Allow inline consts to reference generic params Tracking issue: #76001 The RFC says that inline consts cannot reference to generic parameters (for now) same as array length expressions. And expresses that it's desirable for it to reference in-scope generics when array length expressions gain that feature as well. However it is possible to implement this for inline consts before doing this for all anon consts because inline consts are only used as values and they won't be used in the type system. So we can have: ```rust fn foo() { let x = [4i32; std::mem::size_of::()]; // NOT ALLOWED (for now) let x = const { std::mem::size_of::() }; // ALLOWED with this PR! let x = [4i32; const { std::mem::size_of::() }]; // NOT ALLOWED (for now) } ``` This would make inline consts super useful for compile-time checks and assertions: ```rust fn assert_zst() { const { assert!(std::mem::size_of::() == 0) }; } ``` This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary but this is exactly what a ""desugared"" inline const would do: ```rust fn assert_zst() { struct F(T); impl F { const V: () = assert!(std::mem::size_of::() == 0); } let _ = F::::V; } ``` It should also be noted that the current inline const implementation can already reference the type params via type inference so this resolver-level restriction is not any useful either: ```rust fn foo() -> usize { let (_ size): (PhantomData usize) = const { const fn my_size_of() -> (PhantomData usize) { (PhantomData std::mem::size_of::()) } my_size_of() }; size } ``` ```@rustbot``` label: F-inline_const",HOORAY,2022-05-11T16:57:28Z,ojeda,NA https://github.com/rust-lang/rust/pull/96558,MERGED,2022-04-29T16:49:45Z,2022-05-03T22:30:02Z,Make rustc_parse_format compile on stable,bjorn3,e1b71feb592ba64805689e2b15b9fa570182c442,9,Auto merge of #96558 - bjorn3:librarify_parse_format r=davidtwco Make rustc_parse_format compile on stable This allows it to be used by lightweight formatting systems and may allow it to be used by rust-analyzer.,THUMBS_UP,2022-04-30T09:15:40Z,Agrailag,NA https://github.com/rust-lang/rust/pull/96558,MERGED,2022-04-29T16:49:45Z,2022-05-03T22:30:02Z,Make rustc_parse_format compile on stable,bjorn3,e1b71feb592ba64805689e2b15b9fa570182c442,9,Auto merge of #96558 - bjorn3:librarify_parse_format r=davidtwco Make rustc_parse_format compile on stable This allows it to be used by lightweight formatting systems and may allow it to be used by rust-analyzer.,HEART,2022-05-04T21:51:08Z,ojeda,NA https://github.com/rust-lang/rust/pull/96567,MERGED,2022-04-29T23:24:33Z,2022-05-02T05:52:07Z,Fix docs for u32 and i32 logs func,alex-semenyuk,f58135449e4bca069d27c98ede871e7a8c0f6a19,2,Rollup merge of #96567 - alex-semenyuk:fix_docs_for_logs_func r=Mark-Simulacrum Fix docs for u32 and i32 logs func Closes #96545,THUMBS_UP,2022-04-30T18:51:35Z,tstj,NA https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T07:56:19Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T08:29:36Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T12:03:36Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T16:28:26Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T17:39:17Z,fmease,NA https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-04-30T23:24:44Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-05-01T18:49:29Z,TimNN,mail@timnn.me https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-05-01T23:53:48Z,BlackHoleFox,blackholefoxdev@gmail.com https://github.com/rust-lang/rust/pull/96571,MERGED,2022-04-30T03:27:25Z,2022-05-02T05:52:07Z,Add a bathroom stall to weird expressions test,thomcc,f6a89ee628ca1676b7e630da5d611942a634402a,1,Rollup merge of #96571 - thomcc:bathroom-stall r=Mark-Simulacrum Add a bathroom stall to weird expressions test,LAUGH,2022-05-02T04:06:37Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96573,OPEN,2022-04-30T04:34:29Z,NA,add `no_compile` doctest attribute,CAD97,NA,NA,NA,HEART,2022-05-04T20:57:33Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/96573,OPEN,2022-04-30T04:34:29Z,NA,add `no_compile` doctest attribute,CAD97,NA,NA,NA,THUMBS_UP,2022-06-06T15:17:55Z,briankung,NA https://github.com/rust-lang/rust/pull/96574,CLOSED,2022-04-30T07:41:12Z,2022-06-22T02:26:33Z,Proof of concept: implement test ignore-by-panic,CAD97,NA,NA,NA,HEART,2022-04-30T14:52:57Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/96574,CLOSED,2022-04-30T07:41:12Z,2022-06-22T02:26:33Z,Proof of concept: implement test ignore-by-panic,CAD97,NA,NA,NA,HEART,2022-05-01T10:29:12Z,yanganto,yanganto@gmail.com https://github.com/rust-lang/rust/pull/96576,MERGED,2022-04-30T09:05:12Z,2022-05-01T13:10:33Z,Also report the call site of PME errors locally.,oli-obk,637b3f68079fc81db9bfd2c0f8f306c892680d25,7,Auto merge of #96576 - oli-obk:post_monomorphization_error_backtrace r=lqd Also report the call site of PME errors locally. Note this does not produce a full stack all the way to the first call that specifies all monomorphic parameters it's just shallowly mentioning the last call site. previous work: https://github.com/rust-lang/rust/pull/85633 tracking issue: https://github.com/rust-lang/rust/issues/85155 r? `@lqd` I figured we could get some improvement for traces in local crates without going into the backtrace hell you landed in last time,THUMBS_UP,2022-04-30T09:10:10Z,Agrailag,NA https://github.com/rust-lang/rust/pull/96576,MERGED,2022-04-30T09:05:12Z,2022-05-01T13:10:33Z,Also report the call site of PME errors locally.,oli-obk,637b3f68079fc81db9bfd2c0f8f306c892680d25,7,Auto merge of #96576 - oli-obk:post_monomorphization_error_backtrace r=lqd Also report the call site of PME errors locally. Note this does not produce a full stack all the way to the first call that specifies all monomorphic parameters it's just shallowly mentioning the last call site. previous work: https://github.com/rust-lang/rust/pull/85633 tracking issue: https://github.com/rust-lang/rust/issues/85155 r? `@lqd` I figured we could get some improvement for traces in local crates without going into the backtrace hell you landed in last time,HEART,2022-05-01T13:12:28Z,faptc,NA https://github.com/rust-lang/rust/pull/96576,MERGED,2022-04-30T09:05:12Z,2022-05-01T13:10:33Z,Also report the call site of PME errors locally.,oli-obk,637b3f68079fc81db9bfd2c0f8f306c892680d25,7,Auto merge of #96576 - oli-obk:post_monomorphization_error_backtrace r=lqd Also report the call site of PME errors locally. Note this does not produce a full stack all the way to the first call that specifies all monomorphic parameters it's just shallowly mentioning the last call site. previous work: https://github.com/rust-lang/rust/pull/85633 tracking issue: https://github.com/rust-lang/rust/issues/85155 r? `@lqd` I figured we could get some improvement for traces in local crates without going into the backtrace hell you landed in last time,HEART,2022-05-03T13:16:58Z,nbdd0121,gary@garyguo.net https://github.com/rust-lang/rust/pull/96576,MERGED,2022-04-30T09:05:12Z,2022-05-01T13:10:33Z,Also report the call site of PME errors locally.,oli-obk,637b3f68079fc81db9bfd2c0f8f306c892680d25,7,Auto merge of #96576 - oli-obk:post_monomorphization_error_backtrace r=lqd Also report the call site of PME errors locally. Note this does not produce a full stack all the way to the first call that specifies all monomorphic parameters it's just shallowly mentioning the last call site. previous work: https://github.com/rust-lang/rust/pull/85633 tracking issue: https://github.com/rust-lang/rust/issues/85155 r? `@lqd` I figured we could get some improvement for traces in local crates without going into the backtrace hell you landed in last time,HEART,2022-05-03T22:07:44Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/96602,MERGED,2022-05-01T15:46:35Z,2022-05-15T07:33:04Z,boostrap.py use curl by default,TApplencourt,0be876832331883a0e9057495dc00d855d53097a,4,Auto merge of #96602 - TApplencourt:patch-1 r=Mark-Simulacrum boostrap.py use curl by default Fixes #61611,THUMBS_UP,2022-05-01T16:14:47Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/96612,OPEN,2022-05-01T19:53:02Z,NA,Add `range_of` to slice/str return a `Range` opposite to `get`,Swatinem,NA,NA,NA,HEART,2022-05-01T21:02:24Z,fmease,NA https://github.com/rust-lang/rust/pull/96628,MERGED,2022-05-02T07:18:32Z,2022-05-05T05:08:36Z,Stabilize `bool::then_some`,joshtriplett,da57b3a8327f615567aecbf6cebd8bb9a1f00585,23,Rollup merge of #96628 - joshtriplett:stabilize-then-some r=m-ou-se Stabilize `bool::then_some` FCP completed in https://github.com/rust-lang/rust/issues/80967,CONFUSED,2022-05-12T10:45:21Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/96628,MERGED,2022-05-02T07:18:32Z,2022-05-05T05:08:36Z,Stabilize `bool::then_some`,joshtriplett,da57b3a8327f615567aecbf6cebd8bb9a1f00585,23,Rollup merge of #96628 - joshtriplett:stabilize-then-some r=m-ou-se Stabilize `bool::then_some` FCP completed in https://github.com/rust-lang/rust/issues/80967,HOORAY,2022-05-13T09:14:25Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/96628,MERGED,2022-05-02T07:18:32Z,2022-05-05T05:08:36Z,Stabilize `bool::then_some`,joshtriplett,da57b3a8327f615567aecbf6cebd8bb9a1f00585,23,Rollup merge of #96628 - joshtriplett:stabilize-then-some r=m-ou-se Stabilize `bool::then_some` FCP completed in https://github.com/rust-lang/rust/issues/80967,HOORAY,2022-05-29T20:25:14Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/96628,MERGED,2022-05-02T07:18:32Z,2022-05-05T05:08:36Z,Stabilize `bool::then_some`,joshtriplett,da57b3a8327f615567aecbf6cebd8bb9a1f00585,23,Rollup merge of #96628 - joshtriplett:stabilize-then-some r=m-ou-se Stabilize `bool::then_some` FCP completed in https://github.com/rust-lang/rust/issues/80967,HOORAY,2022-06-08T03:20:36Z,glatavento,NA https://github.com/rust-lang/rust/pull/96646,MERGED,2022-05-02T19:11:20Z,2022-05-03T08:37:04Z,Mitigate impact of subtle invalid call suggestion logic,estebank,279d80127a01eae0174ca92e695a926284ea9e1a,3,Rollup merge of #96646 - estebank:issue-96638 r=jackh726 Mitigate impact of subtle invalid call suggestion logic There's some subtle interaction between inferred expressions being passed as an argument to fn calls with fewer than expected arguments. To avoid the ICE I'm changing indexing operations with `.get(idx)` but the underlying logic still needs to be audited as it was written with the assumption that `final_arg_types` and `provided_args` have the right length. Address #96638.,HEART,2022-05-03T08:48:57Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/96649,MERGED,2022-05-02T20:19:20Z,2022-05-05T12:26:41Z,Make it clear that `to_ipv4` returns an IPv4 address for the IPv6 loopback,tbu-,322a14919d6cc67af45477b623857b30fae63f9d,1,Auto merge of #96649 - tbu-:pr_to_ipv4_loopback_doc r=m-ou-se Make it clear that `to_ipv4` returns an IPv4 address for the IPv6 loopback,THUMBS_UP,2022-05-02T22:20:46Z,est31,NA https://github.com/rust-lang/rust/pull/96652,MERGED,2022-05-02T21:52:38Z,2022-05-29T05:56:08Z,rustdoc: include impl generics / self in search index,notriddle,0acc4a35853215a6f9388ab61455ced309711003,5,Auto merge of #96652 - notriddle:notriddle/self r=GuillaumeGomez rustdoc: include impl generics / self in search index Fixes #92205,HEART,2022-05-21T19:06:17Z,jder,me@jesserusak.com https://github.com/rust-lang/rust/pull/96657,MERGED,2022-05-02T23:29:34Z,2022-05-07T20:17:32Z,Use 64-bit time on 32-bit linux-gnu,cuviper,24a0eecf035235fa58c0b10bad1d3665947842e4,5,Auto merge of #96657 - cuviper:time64 r=joshtriplett Use 64-bit time on 32-bit linux-gnu The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`: - In `std::time::SystemTime` we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp. - In `std::fs::Metadata` we store a `stat64` which has 64-bit `off_t` but still 32-bit `time_t` and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64` as we already do to support creation time and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support but that's not something Rust can change. There remain a few places that need `timespec` for system call timeouts -- I leave that to future work. [Y2038]: https://en.wikipedia.org/wiki/Year_2038_problem,HOORAY,2022-05-04T01:03:22Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/96657,MERGED,2022-05-02T23:29:34Z,2022-05-07T20:17:32Z,Use 64-bit time on 32-bit linux-gnu,cuviper,24a0eecf035235fa58c0b10bad1d3665947842e4,5,Auto merge of #96657 - cuviper:time64 r=joshtriplett Use 64-bit time on 32-bit linux-gnu The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`: - In `std::time::SystemTime` we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp. - In `std::fs::Metadata` we store a `stat64` which has 64-bit `off_t` but still 32-bit `time_t` and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64` as we already do to support creation time and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support but that's not something Rust can change. There remain a few places that need `timespec` for system call timeouts -- I leave that to future work. [Y2038]: https://en.wikipedia.org/wiki/Year_2038_problem,HOORAY,2022-05-04T05:57:01Z,gimbles,NA https://github.com/rust-lang/rust/pull/96657,MERGED,2022-05-02T23:29:34Z,2022-05-07T20:17:32Z,Use 64-bit time on 32-bit linux-gnu,cuviper,24a0eecf035235fa58c0b10bad1d3665947842e4,5,Auto merge of #96657 - cuviper:time64 r=joshtriplett Use 64-bit time on 32-bit linux-gnu The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`: - In `std::time::SystemTime` we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp. - In `std::fs::Metadata` we store a `stat64` which has 64-bit `off_t` but still 32-bit `time_t` and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64` as we already do to support creation time and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support but that's not something Rust can change. There remain a few places that need `timespec` for system call timeouts -- I leave that to future work. [Y2038]: https://en.wikipedia.org/wiki/Year_2038_problem,HEART,2022-05-04T06:28:27Z,scottmcm,NA https://github.com/rust-lang/rust/pull/96673,MERGED,2022-05-03T13:55:32Z,2022-05-05T19:28:46Z,Report that opaque types are not allowed in impls even in the presence of other errors,oli-obk,5f8a2f608090ba399e623e78662c267508e09ef9,4,Rollup merge of #96673 - oli-obk:tait_impl_diagnostic r=petrochenkov Report that opaque types are not allowed in impls even in the presence of other errors fixes #96569 before this PR those useful errors were hidden because either `unused parameter` or `only traits defined in the current crate can be implemented for arbitrary types` got emitted first.,HEART,2022-05-04T00:20:02Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96677,MERGED,2022-05-03T19:10:01Z,2022-05-05T05:08:35Z,Add more tests for label-break-value,jyn514,e3ada27d7d95cdc4e3c05b91c2cf404546c2d7fd,4,Rollup merge of #96677 - jyn514:label-break-value-tests r=petrochenkov Add more tests for label-break-value Helps with https://github.com/rust-lang/rust/issues/48594. The tests are adapted from https://github.com/rust-lang/rust/issues/48594#issuecomment-421625182.,HEART,2022-05-03T21:10:24Z,est31,NA https://github.com/rust-lang/rust/pull/96683,MERGED,2022-05-03T20:16:35Z,2022-05-04T17:49:55Z,Speed up `Token::{ident lifetime}`,nnethercote,343889b7234bf786e2bc673029467052f22fca08,2,Auto merge of #96683 - nnethercote:speed-up-Token-ident-lifetime r=petrochenkov Speed up `Token::{ident lifetime}` Some speed and cleanliness improvements. r? `@petrochenkov`,THUMBS_UP,2022-05-04T19:34:25Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/96683,MERGED,2022-05-03T20:16:35Z,2022-05-04T17:49:55Z,Speed up `Token::{ident lifetime}`,nnethercote,343889b7234bf786e2bc673029467052f22fca08,2,Auto merge of #96683 - nnethercote:speed-up-Token-ident-lifetime r=petrochenkov Speed up `Token::{ident lifetime}` Some speed and cleanliness improvements. r? `@petrochenkov`,THUMBS_UP,2022-05-05T03:28:56Z,Titaniumtown,Titaniumtown@gmail.com https://github.com/rust-lang/rust/pull/96683,MERGED,2022-05-03T20:16:35Z,2022-05-04T17:49:55Z,Speed up `Token::{ident lifetime}`,nnethercote,343889b7234bf786e2bc673029467052f22fca08,2,Auto merge of #96683 - nnethercote:speed-up-Token-ident-lifetime r=petrochenkov Speed up `Token::{ident lifetime}` Some speed and cleanliness improvements. r? `@petrochenkov`,THUMBS_UP,2022-05-12T09:22:27Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96683,MERGED,2022-05-03T20:16:35Z,2022-05-04T17:49:55Z,Speed up `Token::{ident lifetime}`,nnethercote,343889b7234bf786e2bc673029467052f22fca08,2,Auto merge of #96683 - nnethercote:speed-up-Token-ident-lifetime r=petrochenkov Speed up `Token::{ident lifetime}` Some speed and cleanliness improvements. r? `@petrochenkov`,HOORAY,2022-05-12T23:13:07Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96683,MERGED,2022-05-03T20:16:35Z,2022-05-04T17:49:55Z,Speed up `Token::{ident lifetime}`,nnethercote,343889b7234bf786e2bc673029467052f22fca08,2,Auto merge of #96683 - nnethercote:speed-up-Token-ident-lifetime r=petrochenkov Speed up `Token::{ident lifetime}` Some speed and cleanliness improvements. r? `@petrochenkov`,HOORAY,2022-05-13T13:56:12Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/96686,MERGED,2022-05-04T00:19:08Z,2022-05-04T12:26:08Z,Add some TAIT-related tests,JohnTitor,2ca778fb092f2a37ba17acf64c32ca0ed0877f9e,6,Rollup merge of #96686 - JohnTitor:impl-trait-tests r=oli-obk Add some TAIT-related tests Closes #53398 Closes #58662 Closes #89952 Closes #94429 r? `@oli-obk` as you're familiar with it,HEART,2022-05-04T00:50:13Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96697,MERGED,2022-05-04T08:30:38Z,2022-05-05T05:08:35Z,Enable tracing for all queries,oli-obk,ade123275db92898b13faffea08893f0a6737ff4,4,Rollup merge of #96697 - oli-obk:trace_queries r=michaelwoerister Enable tracing for all queries This allows you to log everything within a specific query e.g. ``` env RUSTC_LOG=[mir_borrowck] ``` dumping all borrowck queries may be a bit verbose so you can also restrict it to just an item of your choice: ``` env RUSTC_LOG=[mir_borrowck{key=\.\*name_of_item\.\*}] ``` the regex `.*` in the key name are because the key is a debug printed DefId so you'd get all kinds of things like hashes in there. The tracing logs will show you the key so you can restrict it further if you want.,THUMBS_UP,2022-05-04T11:27:01Z,Agrailag,NA https://github.com/rust-lang/rust/pull/96697,MERGED,2022-05-04T08:30:38Z,2022-05-05T05:08:35Z,Enable tracing for all queries,oli-obk,ade123275db92898b13faffea08893f0a6737ff4,4,Rollup merge of #96697 - oli-obk:trace_queries r=michaelwoerister Enable tracing for all queries This allows you to log everything within a specific query e.g. ``` env RUSTC_LOG=[mir_borrowck] ``` dumping all borrowck queries may be a bit verbose so you can also restrict it to just an item of your choice: ``` env RUSTC_LOG=[mir_borrowck{key=\.\*name_of_item\.\*}] ``` the regex `.*` in the key name are because the key is a debug printed DefId so you'd get all kinds of things like hashes in there. The tracing logs will show you the key so you can restrict it further if you want.,HEART,2022-05-04T17:39:24Z,estebank,NA https://github.com/rust-lang/rust/pull/96697,MERGED,2022-05-04T08:30:38Z,2022-05-05T05:08:35Z,Enable tracing for all queries,oli-obk,ade123275db92898b13faffea08893f0a6737ff4,4,Rollup merge of #96697 - oli-obk:trace_queries r=michaelwoerister Enable tracing for all queries This allows you to log everything within a specific query e.g. ``` env RUSTC_LOG=[mir_borrowck] ``` dumping all borrowck queries may be a bit verbose so you can also restrict it to just an item of your choice: ``` env RUSTC_LOG=[mir_borrowck{key=\.\*name_of_item\.\*}] ``` the regex `.*` in the key name are because the key is a debug printed DefId so you'd get all kinds of things like hashes in there. The tracing logs will show you the key so you can restrict it further if you want.,HEART,2022-05-05T00:29:43Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/96697,MERGED,2022-05-04T08:30:38Z,2022-05-05T05:08:35Z,Enable tracing for all queries,oli-obk,ade123275db92898b13faffea08893f0a6737ff4,4,Rollup merge of #96697 - oli-obk:trace_queries r=michaelwoerister Enable tracing for all queries This allows you to log everything within a specific query e.g. ``` env RUSTC_LOG=[mir_borrowck] ``` dumping all borrowck queries may be a bit verbose so you can also restrict it to just an item of your choice: ``` env RUSTC_LOG=[mir_borrowck{key=\.\*name_of_item\.\*}] ``` the regex `.*` in the key name are because the key is a debug printed DefId so you'd get all kinds of things like hashes in there. The tracing logs will show you the key so you can restrict it further if you want.,HEART,2022-05-06T21:32:42Z,cjgillot,NA https://github.com/rust-lang/rust/pull/96704,MERGED,2022-05-04T13:41:00Z,2022-05-06T07:20:04Z,Add rotation animation on settings button when loading,GuillaumeGomez,292eefe753a007af30329b6dbb3f1cbc840e4bf2,3,Rollup merge of #96704 - GuillaumeGomez:rotation-animation r=jsha Add rotation animation on settings button when loading As discussed I added an animation when the settings JS file is loading (I voluntarily made the timeout at the end of the `settings.js` super long so we can see what the animation looks like): https://user-images.githubusercontent.com/3050060/166693243-816a08b7-5e39-4142-acd3-686ad9950d8e.mp4 r? ````@jsha````,THUMBS_UP,2022-05-04T18:39:35Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T14:36:28Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T14:36:31Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T14:36:33Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T14:36:35Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T14:44:52Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T14:44:52Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T14:44:53Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T14:44:54Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T14:46:19Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T14:46:20Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T14:46:20Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T14:54:40Z,terrarier2111,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T14:55:47Z,xd009642,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:02:52Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:02:53Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:02:53Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:02:54Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:03:19Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:03:19Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:05:37Z,darksv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:07:06Z,jhpratt,jacob@jhpratt.dev https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:07:18Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:07:19Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:07:20Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:07:20Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:13:26Z,ickk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:17:46Z,jakobhellermann,jakob.hellermann@protonmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:18:27Z,fmease,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:18:28Z,fmease,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:18:28Z,fmease,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:18:28Z,fmease,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:24:07Z,naim94a,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:33:09Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:38:15Z,taiki-e,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:45:39Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:45:48Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:49:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:49:20Z,marmeladema,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:49:21Z,marmeladema,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:49:21Z,marmeladema,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:51:58Z,Stumblinbear,stumblinbear@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:51:59Z,Stumblinbear,stumblinbear@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:51:59Z,Stumblinbear,stumblinbear@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:52:00Z,Stumblinbear,stumblinbear@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:52:05Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:52:06Z,Progdrasil,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:52:07Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:53:18Z,dbofmmbt,eduardocanellas98@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:56:19Z,iiYese,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:56:24Z,iiYese,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T15:56:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T15:56:49Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T15:56:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T15:56:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:05:39Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:07:20Z,crlf0710,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:12:15Z,conradludgate,conradludgate@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T16:14:07Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:14:07Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T16:14:08Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:14:08Z,mental32,mentalfoss@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T16:18:48Z,demurgos,demurgos@demurgos.net https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T16:20:20Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:20:21Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T16:20:22Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:20:23Z,betseg,betulunlu0018@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T16:20:38Z,cjwcommuny,cjwcommuny@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:44:44Z,noslaver,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:47:36Z,rben01,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T16:48:28Z,SteffenSunde,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:48:34Z,SteffenSunde,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T16:48:37Z,SteffenSunde,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:48:38Z,SteffenSunde,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T16:51:27Z,Dengjianping,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T16:52:59Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:00:11Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:00:12Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T17:00:12Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T17:00:13Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:04:08Z,jonahseguin,me@jonahseguin.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:10:52Z,bryanhitc,bryanhitc@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:14:23Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:21:16Z,jdahlstrom,johannes.dahlstrom@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:21:40Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:21:40Z,PonasKovas,mykolas.peteraitis@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T17:22:34Z,DarinM223,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T17:25:09Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:25:10Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:25:10Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T17:25:11Z,zesterer,joshua.s.barretto@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:38:15Z,IsseW,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:40:32Z,deciduously,ben@deciduously.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:40:34Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:40:34Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T17:44:26Z,PolyMeilex,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:44:27Z,PolyMeilex,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T17:44:28Z,PolyMeilex,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:44:30Z,PolyMeilex,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:56:08Z,Imberflur,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:56:11Z,Imberflur,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T17:56:40Z,cdstanford,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T17:56:40Z,cdstanford,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T17:56:44Z,cdstanford,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T17:56:46Z,cdstanford,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T18:21:37Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T18:21:39Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T18:21:40Z,tanakh,tanaka.hideyuki@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T18:22:23Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T18:22:24Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T18:22:24Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T18:22:25Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T18:22:26Z,bugadani,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T18:38:59Z,cynecx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T18:39:00Z,cynecx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T18:39:00Z,cynecx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T18:39:01Z,cynecx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T18:50:27Z,voidc,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T18:50:28Z,voidc,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T18:50:29Z,voidc,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T18:50:30Z,voidc,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T19:19:06Z,phayes,patrick.d.hayes@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:19:10Z,phayes,patrick.d.hayes@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:19:23Z,phayes,patrick.d.hayes@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:26:51Z,davidpdrsn,david.pdrsn@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:27:35Z,bstrie,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:27:42Z,bstrie,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:28:50Z,71,opensource@gregoirege.is https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T19:31:20Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:31:21Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:31:21Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T19:31:23Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-04T19:31:32Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T19:35:27Z,Patix0331,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:35:28Z,Patix0331,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T19:35:29Z,Patix0331,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:35:33Z,Patix0331,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T19:47:38Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:47:40Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:47:40Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T19:47:41Z,eldruin,eldruin@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:48:23Z,samanpa,samanpa@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T19:55:10Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:55:11Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T19:55:11Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T19:55:13Z,Pointerbender,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T19:58:32Z,vokup,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T20:06:10Z,drmason13,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T20:23:28Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T20:23:28Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T20:23:29Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T20:23:30Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-04T20:23:31Z,KarlWithK,cjh16@rice.edu https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T21:29:13Z,audunhalland,audun.halland@pm.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T21:29:13Z,audunhalland,audun.halland@pm.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T21:29:16Z,audunhalland,audun.halland@pm.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T21:29:19Z,audunhalland,audun.halland@pm.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T21:45:30Z,ArekPiekarz,piekarzarkadiusz@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T21:49:51Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T21:49:52Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T21:49:54Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T21:49:57Z,dureuill,ldureuil@tetrane.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T21:59:37Z,zslayton,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T21:59:38Z,zslayton,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T21:59:39Z,zslayton,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T21:59:40Z,zslayton,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T22:13:04Z,Gelbpunkt,adrian@travitia.xyz https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T22:13:04Z,Gelbpunkt,adrian@travitia.xyz https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T22:13:05Z,Gelbpunkt,adrian@travitia.xyz https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T22:13:06Z,Gelbpunkt,adrian@travitia.xyz https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T22:13:25Z,clarkmoody,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T22:20:08Z,Hastaroth1,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T22:43:45Z,AlexEne,alex.ene0x11@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T22:43:46Z,AlexEne,alex.ene0x11@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T23:45:33Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-04T23:51:53Z,d4h0,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-04T23:51:54Z,d4h0,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-04T23:51:55Z,d4h0,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-04T23:51:56Z,d4h0,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T00:13:00Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T00:13:01Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T00:13:03Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T00:13:03Z,pan93412,pan93412@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T00:18:30Z,overlisted,mail@overlisted.net https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T00:26:36Z,weihanglo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T00:26:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T00:26:38Z,weihanglo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T00:26:39Z,weihanglo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T00:26:39Z,weihanglo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T00:31:14Z,zRedShift,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T00:39:18Z,sgrif,sage@sagetheprogrammer.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T00:42:27Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T00:42:28Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T00:42:29Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T00:42:31Z,schungx,schungx@live.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T01:03:35Z,cayv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:03:38Z,cayv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T01:03:40Z,cayv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T01:03:42Z,cayv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T01:10:56Z,Miksel12,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:10:58Z,Miksel12,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T01:10:59Z,Miksel12,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T01:16:46Z,NateLing,magic.ling@live.cn https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:17:58Z,Demonthos,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T01:18:00Z,Demonthos,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:36:28Z,J-Fields,jasonfields4@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:38:37Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T01:38:38Z,WiSaGaN,wisagan@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T01:50:34Z,liam-b,liam@anywhich.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:50:36Z,liam-b,liam@anywhich.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T01:56:50Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T01:56:50Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T01:56:50Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T01:56:52Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T01:56:53Z,Veetaha,veetaha2@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T02:04:55Z,AlephAlpha,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T02:44:56Z,danielg1111,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T03:10:43Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T03:10:47Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T03:10:49Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T03:10:50Z,rwestphal,renato@openbsd.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T03:57:21Z,ratmice,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T04:38:17Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T04:41:50Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T04:41:51Z,kuviman,kuviman@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T04:44:05Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T04:44:06Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T04:44:06Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T04:44:06Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T04:48:16Z,cshuaimin,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T05:12:41Z,biro456,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T05:12:43Z,biro456,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T05:12:45Z,biro456,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T05:16:31Z,InternetUnexplorer,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T05:34:29Z,PieKing1215,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T05:34:30Z,PieKing1215,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T05:34:31Z,PieKing1215,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T06:07:47Z,Ixentus,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T06:22:46Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T06:22:50Z,12101111,w12101111@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T06:46:48Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T06:46:50Z,Stranger6667,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T06:48:19Z,remi-dupre,remi@dupre.io https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T06:52:43Z,Yixuan-Wang,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T07:36:34Z,rubdos,ruben.de.smet@rubdos.be https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T07:48:08Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T07:48:10Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T08:07:58Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T08:08:00Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T08:08:02Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T08:08:06Z,andreytkachenko,andrey@aidev.ru https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T08:17:55Z,TehPers,tehperz@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T08:23:42Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T08:31:44Z,chrysn,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T08:42:09Z,malthesr,malthe.rasmussen@bio.ku.dk https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T08:46:58Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T09:19:48Z,rrbutani,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T09:19:48Z,rrbutani,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T09:19:50Z,rrbutani,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T10:03:54Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T10:03:55Z,runiq,hey@runiq.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T10:48:38Z,liquidev,contact@liquidev.net https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T12:27:43Z,iceghost,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T13:06:41Z,jiangzhe,nju.jiangzhe@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T13:15:24Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T13:15:25Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T13:15:30Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T13:15:31Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T13:21:03Z,robjtede,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T13:21:03Z,robjtede,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T14:03:11Z,ollpu,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T14:10:05Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T14:10:06Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T14:10:08Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T14:10:12Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T14:56:37Z,b-naber,b_naber@gmx.de https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T15:06:06Z,jam1garner,jam@jam1.re https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T15:42:07Z,ilslv,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T16:28:39Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T16:56:53Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T16:56:54Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T16:56:57Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T16:56:59Z,0x7CFE,korvin@deeptown.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T17:39:19Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T18:40:17Z,AngelOnFira,forest@timsle.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T18:40:18Z,AngelOnFira,forest@timsle.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T18:40:19Z,AngelOnFira,forest@timsle.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T18:40:20Z,AngelOnFira,forest@timsle.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-05T18:40:21Z,AngelOnFira,forest@timsle.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T19:48:37Z,alexeden,alexandereden91@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T19:48:38Z,alexeden,alexandereden91@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T19:48:40Z,alexeden,alexandereden91@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T20:10:22Z,janriemer,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T20:10:23Z,janriemer,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-05T21:05:14Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T21:05:16Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-05T21:05:17Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-05T21:05:17Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-05T23:43:01Z,gagbo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T05:44:18Z,MattesWhite,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T06:44:36Z,ilovelll,gradle@qq.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T07:32:28Z,dovahcrow,youngw@sfu.ca https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T08:16:40Z,spaarmann,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T08:16:43Z,spaarmann,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T11:45:49Z,dzvon,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T11:45:49Z,dzvon,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-06T11:45:50Z,dzvon,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T13:53:25Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T13:53:26Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-06T13:55:37Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-06T13:55:37Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T13:55:38Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T13:55:38Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-06T13:55:39Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T14:09:19Z,Julian-Wollersberger,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T14:59:31Z,Drakulix,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-06T15:31:20Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T15:31:20Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T15:31:21Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-06T18:16:30Z,InquisitivePenguin,inquisitivepenguin@protonmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-06T18:16:30Z,InquisitivePenguin,inquisitivepenguin@protonmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-06T18:16:31Z,InquisitivePenguin,inquisitivepenguin@protonmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-06T18:16:32Z,InquisitivePenguin,inquisitivepenguin@protonmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-06T19:42:56Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-07T01:26:05Z,solomatov,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T06:13:25Z,bluebear94,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-07T12:14:04Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-07T12:42:43Z,sivertjoe,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T12:43:53Z,bram209,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-07T15:59:26Z,cberner,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T15:59:27Z,cberner,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-07T15:59:28Z,cberner,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-07T15:59:34Z,cberner,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T16:09:34Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-07T16:09:35Z,Mathspy,mathspy257@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-07T17:09:39Z,EAimTY,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T17:09:40Z,EAimTY,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-07T17:09:41Z,EAimTY,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-07T17:09:42Z,EAimTY,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-07T21:13:43Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-07T21:13:44Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-07T21:13:45Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-07T21:13:45Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-07T21:13:47Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-08T00:31:42Z,EsdrasAmora,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-08T00:31:43Z,EsdrasAmora,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-08T00:31:47Z,EsdrasAmora,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-08T04:33:13Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-08T04:33:17Z,attila-lin,linyiyu1992@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-08T08:02:59Z,najamelan,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-09T02:39:07Z,Evian-Zhang,evianzhang1999@163.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-09T06:58:08Z,VanOvermeire,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-09T15:59:49Z,mohe2015,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-09T15:59:49Z,mohe2015,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-09T18:02:39Z,praveenperera,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-09T18:02:39Z,praveenperera,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-09T18:02:40Z,praveenperera,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-09T18:02:40Z,praveenperera,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-10T03:54:31Z,BeyondToBe,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-10T09:53:44Z,jedel1043,jedel0124@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-10T09:53:44Z,jedel1043,jedel0124@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-10T09:53:46Z,jedel1043,jedel0124@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-10T10:07:47Z,occar421,occar@hotmail.co.jp https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-10T10:07:48Z,occar421,occar@hotmail.co.jp https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-10T10:07:49Z,occar421,occar@hotmail.co.jp https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-10T15:37:32Z,akonradi,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-10T19:35:40Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-10T22:33:55Z,MMukundi,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-10T22:33:58Z,MMukundi,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-10T22:34:02Z,MMukundi,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-11T10:46:31Z,KeenS,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-11T20:40:50Z,robinhundt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-11T20:40:51Z,robinhundt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-11T20:40:52Z,robinhundt,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-12T17:03:13Z,aleksmelnikov,dailyadm@hotmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-13T16:05:37Z,gtsiam,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-13T16:05:38Z,gtsiam,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-13T19:17:43Z,tema3210,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-13T19:17:44Z,tema3210,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-13T19:17:45Z,tema3210,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-13T19:17:47Z,tema3210,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-13T19:17:51Z,tema3210,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-17T21:10:14Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-17T21:10:16Z,JulianKnodt,julianknodt@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-17T21:14:26Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-18T07:33:16Z,dhardy,github1@dhardy.name https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-18T16:05:40Z,lovesegfault,bernardo@meurer.org https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-19T07:28:12Z,Tyestor,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-19T14:32:54Z,umgefahren,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-19T14:32:55Z,umgefahren,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-19T15:19:22Z,mijamo,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-19T18:02:56Z,remoun,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-19T18:02:56Z,remoun,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-19T18:55:31Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-19T20:44:35Z,Lipen,lipen00@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-20T10:32:41Z,LukasKalbertodt,lukas.kalbertodt@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-23T11:04:13Z,ljedrz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-26T02:14:42Z,james7132,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-26T02:14:42Z,james7132,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-26T02:14:43Z,james7132,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-26T02:14:44Z,james7132,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-05-26T02:14:45Z,james7132,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-26T13:42:27Z,levcom,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-26T13:44:23Z,Nekrolm,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-26T13:47:32Z,sirroland,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-27T05:26:29Z,bb010g,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-27T09:40:35Z,ms-jpq,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-27T09:40:36Z,ms-jpq,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-05-28T15:37:58Z,al8n,scygliu1@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-05-28T15:38:00Z,al8n,scygliu1@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-05-28T15:38:02Z,al8n,scygliu1@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-05-28T15:38:04Z,al8n,scygliu1@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-02T07:37:23Z,eggyal,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-02T07:37:24Z,eggyal,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-02T07:37:25Z,eggyal,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-02T07:37:26Z,eggyal,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-02T16:13:13Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-02T16:13:14Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-02T16:13:15Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-02T16:13:15Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-06-02T16:13:16Z,lukechu10,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-03T07:27:06Z,donkeyteethUX,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-03T07:27:06Z,donkeyteethUX,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-03T20:04:11Z,ekzhang,ekzhang1@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-04T07:53:18Z,ranfdev,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-05T15:23:11Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-05T15:23:12Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-05T15:23:13Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-05T15:23:14Z,ikenox,ikenox@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-05T16:01:04Z,ruifengx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-05T16:01:05Z,ruifengx,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-07T11:34:17Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-07T16:35:22Z,LeoVen,leonardo.vencovsky@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-08T11:49:31Z,PatrickShaw,mail@patrickshaw.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-09T07:02:43Z,mahor1221,mahor1221@pm.me https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-13T08:53:46Z,Ariox41,ariox41@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-13T18:20:31Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-13T18:20:32Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-13T18:20:33Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-13T18:20:34Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-06-13T18:20:35Z,ohsayan,nandansayan@outlook.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-15T17:49:09Z,TroyNeubauer,troyneubauer@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-15T17:49:10Z,TroyNeubauer,troyneubauer@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-15T17:49:12Z,TroyNeubauer,troyneubauer@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-18T17:57:46Z,dbstratta,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-19T14:30:56Z,Demonthos,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-19T14:30:56Z,Demonthos,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-19T19:05:46Z,gtsiam,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-19T19:05:46Z,gtsiam,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-06-19T19:05:47Z,gtsiam,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-19T22:04:39Z,Christopher-S-25,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-20T16:54:36Z,kamulos,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-22T08:41:29Z,daleione,guoyunlei@live.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-22T12:41:01Z,jklw,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-23T00:45:16Z,ryzhyk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-23T00:45:17Z,ryzhyk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-23T00:45:20Z,ryzhyk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-23T00:55:45Z,gz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-23T00:55:46Z,gz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-23T00:55:47Z,gz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-23T00:55:48Z,gz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-23T16:18:52Z,ryzhyk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-23T23:47:30Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-23T23:47:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-23T23:47:31Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-23T23:47:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,EYES,2022-06-23T23:47:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-27T16:14:13Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-27T16:14:13Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-27T16:14:14Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-27T16:14:20Z,Eric-Arellano,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-27T19:56:35Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-27T19:56:37Z,adriandelgado,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-28T08:07:09Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-28T08:07:10Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-28T08:07:11Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-28T08:07:12Z,Robbepop,robin.freyler@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-28T08:35:24Z,chenx6,abc82766@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-28T23:57:36Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-28T23:57:37Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-28T23:57:37Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-28T23:57:38Z,totsteps,totsteps.gs@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-29T11:07:42Z,8573,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-29T13:42:06Z,hasali19,hasan@hasali.dev https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-29T16:39:24Z,tuguzT,timurka.tugushev@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-29T22:09:16Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-29T22:09:17Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-29T22:09:18Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-29T22:09:18Z,mcobzarenco,marius@reinfer.io https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-06-29T22:35:03Z,00nktk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-29T22:35:04Z,00nktk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-29T22:35:05Z,00nktk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-29T22:35:05Z,00nktk,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HEART,2022-06-30T14:55:11Z,lain-dono,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,ROCKET,2022-06-30T22:31:12Z,russellmcc,russell.mcclellan@gmail.com https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-06-30T23:46:52Z,JoJoJet,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,THUMBS_UP,2022-07-01T03:03:30Z,Rapptz,NA https://github.com/rust-lang/rust/pull/96709,OPEN,2022-05-04T14:34:48Z,NA,Stabilize generic associated types,jackh726,NA,NA,NA,HOORAY,2022-07-09T11:35:16Z,Philipp-M,philipp@mildenberger.me https://github.com/rust-lang/rust/pull/96717,MERGED,2022-05-04T22:31:46Z,2022-05-10T18:26:30Z,Handle mismatched generic param kinds in trait impls betterly,BoxyUwU,77030b7825796461f10ee5dd774caa46ad09c64a,7,Rollup merge of #96717 - BoxyUwU:gats_const_param_types_mismatch_err r=lcnr Handle mismatched generic param kinds in trait impls betterly - Check that generic params on a generic associated type are the same as in the trait definition - Check that const generics are not used in place of type generics (and the other way round too) r? `@lcnr`,ROCKET,2022-05-04T23:12:51Z,fmease,NA https://github.com/rust-lang/rust/pull/96732,CLOSED,2022-05-05T12:06:55Z,2022-05-24T13:17:24Z,[don't merge] See what happens if we run PGO on Apple,Kobzol,NA,NA,NA,ROCKET,2022-05-05T12:49:52Z,lqd,NA https://github.com/rust-lang/rust/pull/96732,CLOSED,2022-05-05T12:06:55Z,2022-05-24T13:17:24Z,[don't merge] See what happens if we run PGO on Apple,Kobzol,NA,NA,NA,ROCKET,2022-05-13T04:29:03Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/96732,CLOSED,2022-05-05T12:06:55Z,2022-05-24T13:17:24Z,[don't merge] See what happens if we run PGO on Apple,Kobzol,NA,NA,NA,HEART,2022-05-13T04:29:06Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/96772,MERGED,2022-05-06T14:30:20Z,2022-05-06T22:41:19Z,Suggest fully qualified path with appropriate params,TaKO8Ki,6db969ec95010b5e0e9164a5be6ec9d0fc54f9a1,3,Rollup merge of #96772 - TaKO8Ki:suggest-fully-qualified-path-with-appropriate-params r=compiler-errors Suggest fully qualified path with appropriate params closes #96291,HEART,2022-05-06T23:00:39Z,estebank,NA https://github.com/rust-lang/rust/pull/96780,MERGED,2022-05-06T16:26:10Z,2022-05-07T12:42:11Z,Update LLVM version used to build OS X and Windows artifacts to 14.0.2,Kobzol,613920562215286a84dae65e63b7aff7061f7cdd,1,Auto merge of #96780 - Kobzol:ci-llvm-upgrade-osx-windows r=Mark-Simulacrum Update LLVM version used to build OS X and Windows artifacts to 14.0.2 Let's see what breaks. r? `@Mark-Simulacrum`,ROCKET,2022-05-06T19:02:01Z,lqd,NA https://github.com/rust-lang/rust/pull/96806,MERGED,2022-05-07T08:06:02Z,2022-05-12T00:08:09Z,Gracefully fail to resolve associated items instead of `delay_span_bug`.,cjgillot,cb9cb4d4e10366ea2ce13813fff26b90ab3fec1d,12,Auto merge of #96806 - cjgillot:codegen-fulfill-nice r=oli-obk Gracefully fail to resolve associated items instead of `delay_span_bug`. `codegen_fulfill_obligation` is used during instance resolution for trait items. In case of insufficient normalization issues during MIR inlining it caused ICEs. It's better to gracefully refuse to resolve the associated item and let the caller decide what to do with this. Split from https://github.com/rust-lang/rust/pull/91743 Closes #69121 Closes #73021 Closes #88599 Closes #93008 Closes #93248 Closes #94680 Closes #96170 r? `@oli-obk`,HEART,2022-05-12T02:28:38Z,faptc,NA https://github.com/rust-lang/rust/pull/96820,MERGED,2022-05-07T17:29:39Z,2022-06-25T15:19:34Z,Make RwLockReadGuard covariant,r-raymond,00ce47209dfdd8ef8871c6ec804f0e0e04d10702,4,Auto merge of #96820 - r-raymond:master r=cuviper Make RwLockReadGuard covariant Hi first time contributor here if anything is not as expected please let me know. `RwLockReadGoard`'s type constructor is invariant. Since it behaves like a smart pointer to an immutable reference there is no reason that it should not be covariant. Take e.g. ``` fn test_read_guard_covariance() { fn do_stuff<'a>(_: RwLockReadGuard<'_ &'a i32> _: &'a i32) {} let j: i32 = 5; let lock = RwLock::new(&j); { let i = 6; do_stuff(lock.read().unwrap() &i); } drop(lock); } ``` where the compiler complains that &i doesn't live long enough. If `RwLockReadGuard` is covariant then the above code is accepted because the lifetime can be shorter than `'a`. In order for `RwLockReadGuard` to be covariant it can't contain a full reference to the `RwLock` which can never be covariant (because it exposes a mutable reference to the underlying data structure). By reducing the data structure to the required pieces of `RwLock` the rest falls in place. If there is a better way to do a test that tests successful compilation please let me know. Fixes #80392,THUMBS_UP,2022-06-30T04:53:56Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/96823,MERGED,2022-05-07T18:19:24Z,2022-05-10T10:53:57Z,Properly fix #96638,jackh726,9a3f17b34d59329a931c10086d5e98b3dea26ee7,2,Rollup merge of #96823 - jackh726:params-heuristics-fix r=estebank Properly fix #96638 Closes #96638 The main part of this change is `Error::Invalid` now returns both the input and arg indices. However I realized the code here was kind of confusing and not internally consistent (and thus I was having trouble getting the right behavior). So I've also switched `input_indices` and `arg_indices` to more closely match some naming in `checks` (although I think a more thorough cleanup there could be beneficial). I've added comments but essentially `input_indices` refers to *user provided* inputs and `arg_indices` refers to *expected* args.,HEART,2022-05-09T18:38:56Z,estebank,NA https://github.com/rust-lang/rust/pull/96823,MERGED,2022-05-07T18:19:24Z,2022-05-10T10:53:57Z,Properly fix #96638,jackh726,9a3f17b34d59329a931c10086d5e98b3dea26ee7,2,Rollup merge of #96823 - jackh726:params-heuristics-fix r=estebank Properly fix #96638 Closes #96638 The main part of this change is `Error::Invalid` now returns both the input and arg indices. However I realized the code here was kind of confusing and not internally consistent (and thus I was having trouble getting the right behavior). So I've also switched `input_indices` and `arg_indices` to more closely match some naming in `checks` (although I think a more thorough cleanup there could be beneficial). I've added comments but essentially `input_indices` refers to *user provided* inputs and `arg_indices` refers to *expected* args.,HEART,2022-05-10T11:46:04Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/96827,OPEN,2022-05-07T21:31:07Z,NA,Implement unstable `-Clinker-flavor=gcc:*` for MCP 510,lqd,NA,NA,NA,THUMBS_UP,2022-05-08T08:24:17Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96838,MERGED,2022-05-08T14:33:08Z,2022-05-10T00:40:36Z,Optimize switch sources representation and usage,tmiasko,cb390735b03aa44229ff2858be8fedbd7b0ce7cb,3,Auto merge of #96838 - tmiasko:lazy-switch-sources r=oli-obk Optimize switch sources representation and usage * Avoid constructing switch sources unless necessary - switch sources are used by backward analysis with a custom switch int edge effects but are otherwise unnecessarily computed. * Use sparse representation of switch sources to avoid quadratic space overhead.,HEART,2022-05-08T20:05:41Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-08T19:25:04Z,Cryptjar,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-08T20:01:46Z,n8henrie,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-08T20:12:49Z,dalpil,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-08T20:41:08Z,sciguy16,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-08T21:31:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-08T22:01:52Z,stappersg,stappers@stappers.it https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-09T05:21:18Z,timwalls,tim.walls@snowgoons.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-09T06:53:25Z,jkristell,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-09T18:27:16Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-09T18:27:19Z,agausmann,agausmann@fastmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-10T06:18:39Z,abusch,antoine.busch@gmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-10T06:18:39Z,abusch,antoine.busch@gmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-10T08:50:24Z,TerminatorNL,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-10T08:50:25Z,TerminatorNL,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-10T11:06:11Z,luukvanderduim,luukvanderduim@gmail.com https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-10T12:13:46Z,faptc,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-10T13:27:06Z,qthree,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HEART,2022-05-10T13:27:08Z,qthree,NA https://github.com/rust-lang/rust/pull/96845,MERGED,2022-05-08T19:18:45Z,2022-05-09T17:23:33Z,Upgrade llvm-project (rustc + avr = lovelove back again!),Patryk27,0e345b76a5550d82caff5540649ee0ba6e3b4f3f,1,Auto merge of #96845 - Patryk27:upgrade-llvm r=nikic Upgrade llvm-project (rustc + avr = lovelove back again!) See: https://github.com/rust-lang/llvm-project/pull/139 tl;dr: - closes https://github.com/rust-lang/rust/issues/83633 - closes https://github.com/rust-lang/rust/issues/82104 - closes https://github.com/rust-lang/rust/issues/79889 - closes https://github.com/rust-lang/compiler-builtins/issues/400. 🙂,HOORAY,2022-05-11T10:19:48Z,mamins1376,mamins1376@gmail.com https://github.com/rust-lang/rust/pull/96868,MERGED,2022-05-09T14:23:33Z,2022-06-11T08:46:14Z,Stabilize explicit_generic_args_with_impl_trait,nrc,f1f44b9e4d405f9361ee5ade3e0656b34d9bd1b1,23,Rollup merge of #96868 - nrc:turbo-stable r=jhpratt nbdd0121 nagisa Stabilize explicit_generic_args_with_impl_trait This is a stabilisation PR for `explicit_generic_args_with_impl_trait`. * [tracking issue](https://github.com/rust-lang/rust/issues/83701) - [Stabilisation report](https://github.com/rust-lang/rust/issues/83701#issuecomment-1109949897) - [FCP entered](https://github.com/rust-lang/rust/issues/83701#issuecomment-1120285703) * [implementation PR](https://github.com/rust-lang/rust/pull/86176) * [Reference PR](https://github.com/rust-lang/reference/pull/1212) * There is no mention of using the turbofish operator in the book (other than an entry in the operator list in the appendix) so there is no documentation to change/add there unless we felt like we should add a section on using turbofish but that seems orthogonal to `explicit_generic_args_with_impl_trait`,HEART,2022-05-17T05:57:22Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/96869,OPEN,2022-05-09T14:52:21Z,NA,Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8.,sunfishcode,NA,NA,NA,ROCKET,2022-05-09T15:06:13Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/96869,OPEN,2022-05-09T14:52:21Z,NA,Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8.,sunfishcode,NA,NA,NA,ROCKET,2022-05-09T15:12:02Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96869,OPEN,2022-05-09T14:52:21Z,NA,Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8.,sunfishcode,NA,NA,NA,ROCKET,2022-06-24T08:31:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96872,MERGED,2022-05-09T15:34:22Z,2022-05-10T10:53:56Z,make sure ScalarPair enums have ScalarPair variants; add some layout sanity checks,RalfJung,ec53c379ccb79257f4802a883b42789daec00c50,4,Rollup merge of #96872 - RalfJung:layout-sanity r=eddyb make sure ScalarPair enums have ScalarPair variants; add some layout sanity checks `@eddyb` suggested that it might be reasonable for `ScalarPair` enums to simply adjust the ABI of their variants accordingly such that the layout invariant Miri expects actually holds. This PR implements that. I should note though that I don't know much about this layout computation code and what non-Miri consumers expect from it so tread with caution! I also added a function to sanity-check that computed layouts are internally consistent. This helped a lot in figuring out the final shape of this PR though I am also not 100% sure that these sanity checks are the right ones. Cc `@oli-obk` Fixes https://github.com/rust-lang/rust/issues/96221,HOORAY,2022-05-09T15:40:00Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/96875,OPEN,2022-05-09T16:21:53Z,NA,Add `task::Waker::noop`,SabrinaJewson,NA,NA,NA,HEART,2022-05-09T16:51:32Z,Swatinem,swatinem@swatinem.de https://github.com/rust-lang/rust/pull/96875,OPEN,2022-05-09T16:21:53Z,NA,Add `task::Waker::noop`,SabrinaJewson,NA,NA,NA,HEART,2022-06-21T04:15:10Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/96884,OPEN,2022-05-09T20:26:13Z,NA, Implement unstable `-Clink-self-contained` values for MCP 510,lqd,NA,NA,NA,ROCKET,2022-05-18T12:33:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96903,MERGED,2022-05-10T14:54:43Z,2022-05-11T08:47:54Z,Use lifetimes on type-alias-impl-trait used in function signatures to infer output type lifetimes,oli-obk,17a735b69a3e9c59f7755d43a0e4b26867e72852,2,Rollup merge of #96903 - oli-obk:opaque_type_lifetime_constraints r=compiler-errors Use lifetimes on type-alias-impl-trait used in function signatures to infer output type lifetimes fixes https://github.com/rust-lang/rust/issues/96564 TLDR: ```rust fn execute(ty: Ty<'_>) -> &str { todo!() } ``` (`Ty` being a type alias impl trait) used to produce the following error before this PR ``` error[E0581]: return type references an anonymous lifetime which is not constrained by the fn input types --> src/lib.rs:4:27 | 4 | fn execute(ty: Ty<'_>) -> &str { todo!() } | ^^^^ | = note: lifetimes appearing in an associated type are not considered constrained ```,HEART,2022-05-11T09:13:44Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96905,MERGED,2022-05-10T16:00:02Z,2022-05-10T20:50:06Z,"Revert ""Make ""Assemble stage1 compiler"" orders of magnitude faster""",jyn514,fee75fbe11b1fad5d93c723234178b2a329a3c03,1,"Auto merge of #96905 - jyn514:revert-96803-faster-assemble r=Mark-Simulacrum Revert ""Make ""Assemble stage1 compiler"" orders of magnitude faster"" Reverts rust-lang/rust#96803. This caused `llvm-tools-nightly` to fail when installing with `rustup-toolchain-install-master` because of the presence of symlinks. I'm not sure how the symlinks got in there but revert the PR for now while I figure it out. r? `@Mark-Simulacrum` cc `@RalfJung`",HEART,2022-05-10T16:01:17Z,lqd,NA https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,HEART,2022-05-10T17:13:49Z,lqd,NA https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,ROCKET,2022-05-10T17:13:52Z,lqd,NA https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,HOORAY,2022-05-10T17:13:56Z,lqd,NA https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,HOORAY,2022-05-10T17:17:28Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,HEART,2022-05-10T17:17:29Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,ROCKET,2022-05-10T17:17:29Z,GuillaumeGomez,guillaume1.gomez@gmail.com https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,HOORAY,2022-05-10T18:55:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,CONFUSED,2022-05-10T21:12:59Z,CryZe,NA https://github.com/rust-lang/rust/pull/96909,CLOSED,2022-05-10T17:07:15Z,2022-06-07T19:26:16Z,RFC3239: Implement `cfg(target)` - Part 1,Urgau,NA,NA,NA,THUMBS_DOWN,2022-05-10T21:13:05Z,CryZe,NA https://github.com/rust-lang/rust/pull/96912,OPEN,2022-05-10T17:28:24Z,NA,emit `ProjectionPredicate` obligations when relating projections,BoxyUwU,NA,NA,NA,EYES,2022-05-10T18:44:01Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96912,OPEN,2022-05-10T17:28:24Z,NA,emit `ProjectionPredicate` obligations when relating projections,BoxyUwU,NA,NA,NA,EYES,2022-05-11T00:36:20Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96912,OPEN,2022-05-10T17:28:24Z,NA,emit `ProjectionPredicate` obligations when relating projections,BoxyUwU,NA,NA,NA,HEART,2022-06-10T20:51:00Z,Mythra,cynthia@coan.dev https://github.com/rust-lang/rust/pull/96912,OPEN,2022-05-10T17:28:24Z,NA,emit `ProjectionPredicate` obligations when relating projections,BoxyUwU,NA,NA,NA,HEART,2022-07-10T19:15:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/96913,MERGED,2022-05-10T17:33:57Z,2022-05-25T13:58:44Z,RFC3239: Implement `cfg(target)` - Part 2,Urgau,c12a36adc6e36a9d177c5bb608f5d29c512b0717,14,Rollup merge of #96913 - Urgau:rfc3239-part2 r=petrochenkov RFC3239: Implement `cfg(target)` - Part 2 This pull-request implements the compact `cfg(target(..))` part of [RFC 3239](https://github.com/rust-lang/rust/issues/96901). I recommend reviewing this PR on a per commit basics because of some moving parts. cc `@GuillaumeGomez` r? `@petrochenkov`,ROCKET,2022-05-10T19:16:16Z,lqd,NA https://github.com/rust-lang/rust/pull/96922,OPEN,2022-05-10T21:17:55Z,NA,[WIP] Apply latest PGO artifacts to CI dist builds,Kobzol,NA,NA,NA,ROCKET,2022-05-11T07:48:50Z,lqd,NA https://github.com/rust-lang/rust/pull/96923,MERGED,2022-05-10T21:25:41Z,2022-05-21T06:38:48Z,Drop Tracking: Implement `fake_read` callback,eholk,3b64fe953c23b7d56dd5ebf61b6dbd82b345f880,9,Auto merge of #96923 - eholk:fix-fake-read r=nikomatsakis Drop Tracking: Implement `fake_read` callback This PR updates drop tracking's use of `ExprUseVisitor` so that we treat `fake_read` events as borrows. Without doing this we were not handling match expressions correctly which showed up as a breakage in the `addassign-yield.rs` test. We did not previously notice this because we still had rather large temporary scopes that we held borrows for which changed in #94309. This PR also includes a variant of the `addassign-yield.rs` test case to make sure we continue to have correct behavior here with drop tracking. r? `@nikomatsakis`,HEART,2022-05-20T22:30:55Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HOORAY,2022-05-12T02:49:55Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HOORAY,2022-05-13T15:49:35Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HOORAY,2022-05-14T07:39:47Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HEART,2022-05-14T07:39:49Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,ROCKET,2022-05-14T07:39:51Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HOORAY,2022-05-16T14:14:36Z,taiki-e,NA https://github.com/rust-lang/rust/pull/96935,MERGED,2022-05-11T07:48:42Z,2022-07-06T22:50:36Z,Allow arithmetic and certain bitwise ops on AtomicPtr,thomcc,4755173cf61dfd432d8fb96ea3d09da99fe30283,4,Rollup merge of #96935 - thomcc:atomicptr-strict-prov r=dtolnay Allow arithmetic and certain bitwise ops on AtomicPtr This is mainly to support migrating from `AtomicUsize` for the strict provenance experiment. This is a pretty dubious set of APIs but it should be sufficient to allow code that's using `AtomicUsize` to manipulate a tagged pointer atomically. It's under a new feature gate `#![feature(strict_provenance_atomic_ptr)]` but I'm not sure if it needs its own tracking issue. I'm happy to make one but it's not clear that it's needed. I'm unsure if it needs changes in the various non-LLVM backends. Because we just cast things to integers anyway (and were already doing so) I doubt it. API change proposal: https://github.com/rust-lang/libs-team/issues/60 Fixes #95492,HEART,2022-07-02T17:49:53Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/96955,MERGED,2022-05-11T20:37:26Z,2022-06-24T12:58:38Z,Remove (transitive) reliance on sorting by DefId in pretty-printer,Aaron1011,2c6feb51da9dbaa72ea4175ebafe38d78883e47b,3,Rollup merge of #96955 - Aaron1011:pretty-print-sort r=petrochenkov Remove (transitive) reliance on sorting by DefId in pretty-printer This moves us a step closer to removing the `PartialOrd/`Ord` impls for `DefId`. See #90317,HEART,2022-06-22T16:41:07Z,pierwill,NA https://github.com/rust-lang/rust/pull/96955,MERGED,2022-05-11T20:37:26Z,2022-06-24T12:58:38Z,Remove (transitive) reliance on sorting by DefId in pretty-printer,Aaron1011,2c6feb51da9dbaa72ea4175ebafe38d78883e47b,3,Rollup merge of #96955 - Aaron1011:pretty-print-sort r=petrochenkov Remove (transitive) reliance on sorting by DefId in pretty-printer This moves us a step closer to removing the `PartialOrd/`Ord` impls for `DefId`. See #90317,HEART,2022-06-22T18:59:53Z,cjgillot,NA https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,HOORAY,2022-05-11T22:14:43Z,Urgau,NA https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,ROCKET,2022-05-11T22:21:37Z,Eijebong,eijebong@bananium.fr https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,HOORAY,2022-05-12T11:43:02Z,faptc,NA https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,HOORAY,2022-05-12T19:04:34Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,HEART,2022-05-12T19:15:58Z,notriddle,michael@notriddle.com https://github.com/rust-lang/rust/pull/96958,MERGED,2022-05-11T22:03:43Z,2022-05-15T09:46:32Z,Improve settings menu display and remove theme menu,GuillaumeGomez,7bf43c3931cbdde2f2d5bfe3456abde92ea1aa21,16,Rollup merge of #96958 - GuillaumeGomez:settings-menu-display r=jsha Improve settings menu display and remove theme menu We talked about improving the settings menu and we mentioned that firefox pocket was a nice inspiration so I implemented it. The result looks like this: ![Screenshot from 2022-05-11 23-59-53](https://user-images.githubusercontent.com/3050060/167954743-438c0a06-4628-478c-bf0c-d20313c1fdfc.png) You can test it [here](https://rustdoc.crud.net/imperio/settings-menu-display/doc/foo/index.html). Only question I have is: should I re-assign the shortcut `T` to this setting menu now that the theme menu is gone? For now I simply removed it. Important to be noted: the full settings page (at `settings.html`) is still rendered the same as currently. r? ``@jsha``,HOORAY,2022-05-16T00:55:10Z,nasso,NA https://github.com/rust-lang/rust/pull/96964,MERGED,2022-05-12T07:46:47Z,2022-05-30T12:00:11Z,Replace `#[default_method_body_is_const]` with `#[const_trait]`,oli-obk,5c780b98d10f48d6255cf2deb2643194b9221c02,32,Auto merge of #96964 - oli-obk:const_trait_mvp r=compiler-errors Replace `#[default_method_body_is_const]` with `#[const_trait]` pulled out of #96077 related issues: #67792 and #92158 cc `@fee1-dead` This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).,HEART,2022-05-12T23:53:01Z,fee1-dead,ent3rm4n@gmail.com https://github.com/rust-lang/rust/pull/96964,MERGED,2022-05-12T07:46:47Z,2022-05-30T12:00:11Z,Replace `#[default_method_body_is_const]` with `#[const_trait]`,oli-obk,5c780b98d10f48d6255cf2deb2643194b9221c02,32,Auto merge of #96964 - oli-obk:const_trait_mvp r=compiler-errors Replace `#[default_method_body_is_const]` with `#[const_trait]` pulled out of #96077 related issues: #67792 and #92158 cc `@fee1-dead` This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).,HEART,2022-05-30T16:57:41Z,proudmuslim-dev,NA https://github.com/rust-lang/rust/pull/96965,MERGED,2022-05-12T08:24:07Z,2022-05-13T08:48:32Z,Gracefully handle normalization failures in the prospective inliner cycle detector,oli-obk,97d48bec2d2ac7e1aac807e1fe3e8341189db7da,1,Auto merge of #96965 - oli-obk:flaky_inliner_ice r=cjgillot Gracefully handle normalization failures in the prospective inliner cycle detector Preliminary work for adding the regression test in #96950 to our test suite (it was flaky on glacier). If this PR solves the flakiness on glacier we can then merge #96950,HEART,2022-05-12T09:25:42Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/96966,MERGED,2022-05-12T08:28:06Z,2022-05-13T00:54:58Z,Update LLVM submodule,nikic,ebb80ec4e90f8622440f3e33562db0d6e6c66555,1,Auto merge of #96966 - nikic:llvm-update-2 r=cuviper Update LLVM submodule Merge upstream release/14.x branch. Fixes #96672.,THUMBS_UP,2022-05-12T15:35:41Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/96970,CLOSED,2022-05-12T13:37:43Z,2022-05-14T16:25:34Z,Forbid lifetime bounds in nested opaque types in binders,oli-obk,NA,NA,NA,HEART,2022-05-12T14:25:34Z,aliemjay,NA https://github.com/rust-lang/rust/pull/96970,CLOSED,2022-05-12T13:37:43Z,2022-05-14T16:25:34Z,Forbid lifetime bounds in nested opaque types in binders,oli-obk,NA,NA,NA,HEART,2022-05-12T14:36:27Z,lqd,NA https://github.com/rust-lang/rust/pull/96973,CLOSED,2022-05-12T14:13:40Z,2022-05-16T00:42:39Z,optmize grow process of `InitMask`,SparrowLii,NA,NA,NA,HEART,2022-05-12T14:34:48Z,oli-obk,NA https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-05-20T19:28:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-06-14T09:19:26Z,michaelwoerister,NA https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-07-07T00:13:00Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-07-07T16:56:22Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-07-08T05:51:50Z,rgwood,NA https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-07-11T14:30:02Z,ptondereau,NA https://github.com/rust-lang/rust/pull/96978,OPEN,2022-05-12T15:55:02Z,NA,Utilize PGO for windows x64 rustc dist builds,lqd,NA,NA,NA,ROCKET,2022-07-11T14:30:17Z,FilipAndersson245,NA https://github.com/rust-lang/rust/pull/96979,OPEN,2022-05-12T16:05:48Z,NA,Add `Waker::update`,SabrinaJewson,NA,NA,NA,THUMBS_UP,2022-05-14T13:47:53Z,joboet,NA https://github.com/rust-lang/rust/pull/96979,OPEN,2022-05-12T16:05:48Z,NA,Add `Waker::update`,SabrinaJewson,NA,NA,NA,THUMBS_UP,2022-06-20T12:10:49Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/96986,MERGED,2022-05-12T17:54:49Z,2022-05-14T08:14:52Z,[save-analysis] Reference the variant not enum at struct-literal cons…,kdashg,c031413f2897562c97f989266a2c6c95f9a45e71,1,Rollup merge of #96986 - kdashg:save-an-enum-vars r=oli-obk [save-analysis] Reference the variant not enum at struct-literal cons… …truction. Closes #96985,HEART,2022-05-12T20:23:18Z,est31,NA https://github.com/rust-lang/rust/pull/96991,OPEN,2022-05-12T19:27:05Z,NA,Add dataflow analysis of enum variants,JulianKnodt,NA,NA,NA,ROCKET,2022-05-12T20:21:56Z,est31,NA https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-05-13T14:38:12Z,Urgau,NA https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-05-13T15:43:53Z,SmiteWindows,NA https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-05-13T16:30:22Z,DrMeepster,NA https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-05-13T16:56:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-06-09T08:11:55Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,ROCKET,2022-06-09T13:54:21Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/97015,OPEN,2022-05-13T14:07:28Z,NA,std::io: migrate ReadBuf to BorrowBuf/BorrowCursor,nrc,NA,NA,NA,THUMBS_UP,2022-06-10T15:25:51Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97016,MERGED,2022-05-13T14:09:41Z,2022-05-15T04:52:13Z,Bump to 1.63,Mark-Simulacrum,7fb2d0ecef572120c4f2fc9a12a23f9bc9ace3d9,1,Auto merge of #97016 - Mark-Simulacrum:bump-version r=Mark-Simulacrum Bump to 1.63 r? `@Mark-Simulacrum` Posting this now but will only approve later today / early tomorrow to give a little more time for not-yet-approved PRs to land on master (e.g. https://github.com/rust-lang/rust/pull/96970).,HEART,2022-05-13T15:43:43Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97023,MERGED,2022-05-13T17:47:38Z,2022-06-02T13:20:22Z,Diagnose anonymous lifetimes errors more uniformly between async and regular fns,cjgillot,5c041f98fa121a5e8ae61f755ac3776565a7a595,33,Rollup merge of #97023 - cjgillot:uniform-anon r=estebank Diagnose anonymous lifetimes errors more uniformly between async and regular fns Async fns and regular fns are desugared differently. For the former we create a generic parameter at HIR level. For the latter we just create an anonymous region for typeck. I plan to migrate regular fns to the async fn desugaring. Before that this PR attempts to merge the diagnostics for both cases. r? ```@estebank```,THUMBS_UP,2022-05-24T18:05:14Z,estebank,NA https://github.com/rust-lang/rust/pull/97026,MERGED,2022-05-13T19:08:59Z,2022-05-25T08:36:56Z,Change orderings of `Debug` for the Atomic types to `Relaxed`.,Nilstrieb,fbb17777fee8048c3bce9019ef1c1e7e42bb303b,1,Rollup merge of #97026 - Nilstrieb:make-atomic-debug-relaxed r=scottmcm Change orderings of `Debug` for the Atomic types to `Relaxed`. This reduces synchronization between threads when debugging the atomic types. Reducing the synchronization means that executions with and without the debug calls will be more consistent making it easier to debug. We discussed this on the Rust Community Discord with `@ibraheemdev` before.,HEART,2022-05-13T23:02:15Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97027,MERGED,2022-05-13T19:09:32Z,2022-05-20T03:27:06Z,Use pointers in `cell::{Ref RefMut}` to avoid `noalias`,cuviper,4d6992bc18e54522cced4f945f29f186992d5ea4,4,Auto merge of #97027 - cuviper:yesalias-refcell r=thomcc Use pointers in `cell::{Ref RefMut}` to avoid `noalias` When `Ref` and `RefMut` were based on references they would get LLVM `noalias` attributes that were incorrect because that alias guarantee is only true until the guard drops. A `&RefCell` on the same value can get a new borrow that aliases the previous guard possibly leading to miscompilation. Using `NonNull` pointers in `Ref` and `RefCell` avoids `noalias`. Fixes the library side of #63787 but we still might want to explore language solutions there.,HEART,2022-05-14T16:56:02Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/97027,MERGED,2022-05-13T19:09:32Z,2022-05-20T03:27:06Z,Use pointers in `cell::{Ref RefMut}` to avoid `noalias`,cuviper,4d6992bc18e54522cced4f945f29f186992d5ea4,4,Auto merge of #97027 - cuviper:yesalias-refcell r=thomcc Use pointers in `cell::{Ref RefMut}` to avoid `noalias` When `Ref` and `RefMut` were based on references they would get LLVM `noalias` attributes that were incorrect because that alias guarantee is only true until the guard drops. A `&RefCell` on the same value can get a new borrow that aliases the previous guard possibly leading to miscompilation. Using `NonNull` pointers in `Ref` and `RefCell` avoids `noalias`. Fixes the library side of #63787 but we still might want to explore language solutions there.,HEART,2022-05-26T02:58:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/97028,MERGED,2022-05-13T20:27:37Z,2022-05-29T02:59:53Z,Add support for embedding pretty printers via `#[debugger_visualizer]` attribute,ridwanabdillahi,239287f013b21d18c8ddd5bf5419629d43dca484,27,Rollup merge of #97028 - ridwanabdillahi:pretty-printer r=michaelwoerister Add support for embedding pretty printers via `#[debugger_visualizer]` attribute Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above. This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target. RFC: https://github.com/rust-lang/rfcs/pull/3191,THUMBS_UP,2022-05-14T00:17:25Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97033,MERGED,2022-05-14T02:06:55Z,2022-05-19T06:33:55Z,Remove libstd's calls to `C-unwind` foreign functions,nbdd0121,50872bdb99c96716ee50a3b9613c395302b99767,5,"Auto merge of #97033 - nbdd0121:unwind3 r=Amanieu Remove libstd's calls to `C-unwind` foreign functions Remove all libstd and its dependencies' usage of `extern ""C-unwind""`. This is a prerequiste of a WIP PR which will forbid libraries calling `extern ""C-unwind""` functions to be compiled in `-Cpanic=unwind` and linked against `panic_abort` (this restriction is necessary to address soundness bug #96926). Cargo will ensure all crates are compiled with the same `-Cpanic` but the std is only compiled `-Cpanic=unwind` but needs the ability to be linked into `-Cpanic=abort`. Currently there are two places where `C-unwind` is used in libstd: * `__rust_start_panic` is used for interfacing to the panic runtime. This could be `extern ""Rust""` * `_{rdl rg}_oom`: a shim `__rust_alloc_error_handler` will be generated by codegen to call into one of these; they can also be `extern ""Rust""` (in fact the generated shim is used as `extern ""Rust""` so I am not even sure why these are not probably because they used to `extern ""C""` and was changed to `extern ""C-unwind""` when we allow alloc error hooks to unwind but they really should just be using Rust ABI). For dependencies there is only one `extern ""C-unwind""` function call in `unwind` crate. This can be expressed as a re-export. More dicussions can be seen in the Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/soundness.20in.20mixed.20panic.20mode `@rustbot` label: T-libs F-c_unwind",HEART,2022-05-23T08:50:53Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97034,MERGED,2022-05-14T04:32:53Z,2022-05-28T11:49:45Z,Implement `Hash` for `core::alloc::Layout`,fee1-dead,880d3ea3c22dbdfdcaa288ac2b60fb1126bb828d,2,Rollup merge of #97034 - fee1-dead-contrib:layout-hash r=dtolnay Implement `Hash` for `core::alloc::Layout` This was brought up on [reddit](https://www.reddit.com/r/rust/comments/uoypui/the_standard_library_types_are_good_except_when/) and I don't see why Layout shouldn't implement `Hash`. Feel free to comment if I am wrong though :),THUMBS_UP,2022-06-05T06:29:09Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97041,MERGED,2022-05-14T10:11:53Z,2022-05-15T09:46:31Z,Fix `download-ci-llvm` NixOS patching for `.so`s.,eddyb,a37ba96868d67b0631e7e50b75993eba4dadcdf3,1,Rollup merge of #97041 - eddyb:nixos-llvm-ci-patchelf r=Mark-Simulacrum Fix `download-ci-llvm` NixOS patching for `.so`s. See https://github.com/rust-lang/rust/pull/95170#discussion_r872960686 - in short `Path::ends_with` doesn't do the same thing as `str::ends_with` and can only be used to check for whole file names not extensions. With this PR I get the full suite of: ``` extracting /home/eddy/Projects/rust-A/build/cache/llvm-ebb80ec4e90f8622440f3e33562db0d6e6c66555-true/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz to /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-config /nix/store/r4bzq2xilvv8fmqjg626hzwi22ah3hf4-rust-stage0-dependencies info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so ``` (that `libLLVM-14-rust-1.62.0-nightly.so` at the end having been missing before) r? `@Mark-Simulacrum` cc `@jyn514`,HEART,2022-05-14T10:32:11Z,est31,NA https://github.com/rust-lang/rust/pull/97041,MERGED,2022-05-14T10:11:53Z,2022-05-15T09:46:31Z,Fix `download-ci-llvm` NixOS patching for `.so`s.,eddyb,a37ba96868d67b0631e7e50b75993eba4dadcdf3,1,Rollup merge of #97041 - eddyb:nixos-llvm-ci-patchelf r=Mark-Simulacrum Fix `download-ci-llvm` NixOS patching for `.so`s. See https://github.com/rust-lang/rust/pull/95170#discussion_r872960686 - in short `Path::ends_with` doesn't do the same thing as `str::ends_with` and can only be used to check for whole file names not extensions. With this PR I get the full suite of: ``` extracting /home/eddy/Projects/rust-A/build/cache/llvm-ebb80ec4e90f8622440f3e33562db0d6e6c66555-true/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz to /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-config /nix/store/r4bzq2xilvv8fmqjg626hzwi22ah3hf4-rust-stage0-dependencies info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so ``` (that `libLLVM-14-rust-1.62.0-nightly.so` at the end having been missing before) r? `@Mark-Simulacrum` cc `@jyn514`,HEART,2022-05-14T13:43:21Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/97044,MERGED,2022-05-14T14:13:39Z,2022-05-14T22:54:33Z,Fix rustc-perf benchmarks,Urgau,70b3681bf621bc0de91ffab711b2350068b4c466,1,Auto merge of #97044 - Urgau:check-cfg-fix-rustc-perf r=Mark-Simulacrum Fix rustc-perf benchmarks See https://github.com/rust-lang/rust/pull/96984#issuecomment-1126678773 and https://github.com/rust-lang/rust/pull/96984#issuecomment-1126719585 cc `@ehuss` `@lqd`,THUMBS_UP,2022-05-14T17:23:16Z,lqd,NA https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-14T21:43:13Z,est31,NA https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-15T09:15:19Z,lunabunn,iamrabbitmoon@gmail.com https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-15T09:24:19Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-15T10:36:58Z,95ulisse,me@marcocameriero.net https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-15T13:48:52Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/97046,MERGED,2022-05-14T17:52:13Z,2022-05-26T17:58:11Z,improve case conversion happy path,conradludgate,1851f0802e148bb7fa0bfd7dabcb7397bf371b0b,2,Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path r=thomcc improve case conversion happy path Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616). It features a hot path for ascii-only strings (although I assume for reasons specific to go they've opted for a read safe hot loop). I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback. (Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv For the cases where non-ascii is found near the start the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss,HEART,2022-05-15T13:51:18Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-05-15T03:38:14Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-05-15T03:57:23Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-05-15T12:48:50Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-05-15T13:59:21Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-06-22T15:08:23Z,RustyYato,NA https://github.com/rust-lang/rust/pull/97052,OPEN,2022-05-15T03:14:49Z,NA,Implement pointee metadata unsizing via a TypedMetadata container,CAD97,NA,NA,NA,HEART,2022-07-08T18:37:23Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97053,MERGED,2022-05-15T04:25:07Z,2022-05-16T04:54:13Z,Remove potentially misleading realloc parenthetical,CAD97,56d540e0571ac1b0633ce10644224c495aaf42a0,2,Auto merge of #97053 - CAD97:realloc-clarification r=dtolnay Remove potentially misleading realloc parenthetical This parenthetical is problematic because it suggests that the following is sound: ```rust let layout = Layout::new::<[u8; 32]>(); let p1 = alloc(layout); let p2 = realloc(p1 layout 32); if p1 == p2 { p1.write([0; 32]); dealloc(p1 layout); } else { dealloc(p2 layout); } ``` At the very least this isn't the case for [ANSI `realloc`](https://en.cppreference.com/w/c/memory/realloc) > The original pointer `ptr` is invalidated and any access to it is undefined behavior (even if reallocation was in-place). and [Windows `HeapReAlloc`](https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heaprealloc) is unclear at best (`HEAP_REALLOC_IN_PLACE_ONLY`'s description may imply that the old pointer may be used if `HEAP_REALLOC_IN_PLACE_ONLY` is provided). The conservative position is to just remove the parenthetical. cc `@rust-lang/wg-unsafe-code-guidelines` `@rust-lang/wg-allocators`,THUMBS_UP,2022-05-15T07:19:15Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97058,MERGED,2022-05-15T11:48:45Z,2022-06-07T13:51:00Z,Various refactors to the incr comp workproduct handling,bjorn3,ab1027ad0f9d45e47e37a2516b331dd47539b4c5,9,Rollup merge of #97058 - bjorn3:multi_artifact_work_products r=nagisa Various refactors to the incr comp workproduct handling This is the result of me looking into adding support for having multiple object files for a single codegen unit to incr comp. This is necessary to support inline assembly in cg_clif without requiring partial linking which is not supported on Windows and seems to fail on macOS for some reason. Cg_clif uses an external assembler to handle inline asm and thus produces one object file with regular functions and one object file containing compiled inline asm for each codegen unit which uses inline asm. Current incr comp can't handle this. This PR doesn't yet add support for this but it makes it easier to do so.,THUMBS_UP,2022-05-15T12:57:50Z,Agrailag,NA https://github.com/rust-lang/rust/pull/97081,MERGED,2022-05-16T14:25:46Z,2022-06-08T00:26:41Z,Re-use the type op instead of calling the implied_outlives_bounds query directly,oli-obk,b17e9d76f2ad15022e0e69bc33745c4ef9025a8f,6,Auto merge of #97081 - oli-obk:outlives_query_fast_path r=jackh726 Re-use the type op instead of calling the implied_outlives_bounds query directly r? `@ghost`,EYES,2022-05-16T17:16:19Z,lqd,NA https://github.com/rust-lang/rust/pull/97084,MERGED,2022-05-16T16:57:45Z,2022-05-16T22:11:00Z,[stable] Rust 1.61,Mark-Simulacrum,66a356df851ab925a35d01b65d669348b5113fa3,2,Auto merge of #97084 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] Rust 1.61 * Cherry-picking release notes from not yet landed #96539. r? `@Mark-Simulacrum`,HOORAY,2022-05-16T17:43:37Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97084,MERGED,2022-05-16T16:57:45Z,2022-05-16T22:11:00Z,[stable] Rust 1.61,Mark-Simulacrum,66a356df851ab925a35d01b65d669348b5113fa3,2,Auto merge of #97084 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] Rust 1.61 * Cherry-picking release notes from not yet landed #96539. r? `@Mark-Simulacrum`,HOORAY,2022-05-16T17:45:54Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97084,MERGED,2022-05-16T16:57:45Z,2022-05-16T22:11:00Z,[stable] Rust 1.61,Mark-Simulacrum,66a356df851ab925a35d01b65d669348b5113fa3,2,Auto merge of #97084 - Mark-Simulacrum:stable-next r=Mark-Simulacrum [stable] Rust 1.61 * Cherry-picking release notes from not yet landed #96539. r? `@Mark-Simulacrum`,HOORAY,2022-05-16T19:21:56Z,est31,NA https://github.com/rust-lang/rust/pull/97086,MERGED,2022-05-16T17:12:47Z,2022-06-06T13:29:00Z,Report unsafe for overriding link sections,5225225,79b6bad406155cad4481150fc5dfa0da5394e3b6,3,Auto merge of #97086 - 5225225:link-section-is-unsafe r=davidtwco Report unsafe for overriding link sections I'm not too sure about the lint wording here but I couldn't think of anything better.,HEART,2022-05-16T17:35:43Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97086,MERGED,2022-05-16T17:12:47Z,2022-06-06T13:29:00Z,Report unsafe for overriding link sections,5225225,79b6bad406155cad4481150fc5dfa0da5394e3b6,3,Auto merge of #97086 - 5225225:link-section-is-unsafe r=davidtwco Report unsafe for overriding link sections I'm not too sure about the lint wording here but I couldn't think of anything better.,HEART,2022-05-26T09:23:44Z,mejrs,NA https://github.com/rust-lang/rust/pull/97118,OPEN,2022-05-17T16:29:14Z,NA,speed up parsing for short ipv4s in std::net::Ipv4Addr::from_str,nkconnor,NA,NA,NA,THUMBS_UP,2022-06-09T02:20:35Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/97120,MERGED,2022-05-17T17:23:33Z,2022-05-23T23:31:11Z,Update `rustc` PGO benchmark list,Kobzol,ee160f2f5e73b6f5954bc33f059c316d9e8582c4,2,Auto merge of #97120 - Kobzol:rustc-pgo-expansion r=Mark-Simulacrum Update `rustc` PGO benchmark list I noticed that the `rustc` PGO crates do not contain any crate that would stress the trait system. I tried adding and removing various crates to the PGO benchmark list here. Here's what I found: - Removing [`externs` and `match-stress`](https://perf.rust-lang.org/compare.html?start=c0672870491e84362f76ddecd50fa229f9b06dff&end=b056963e0324fa76c721d79f12658a64cfa4cb5e&stat=instructions:u) regresses these two benchmarks by up to 15 % and removing them doesn't improve anything else so we should keep them. - Adding [`keccak`](https://perf.rust-lang.org/compare.html?start=52cc7795245347500ddf6dc959cf58a7abe2d935&end=6fd27b23fd7860c79752479173b4a1b877cba490) regresses `diesel` otherwise it doesn't do much. - Adding [`tt-muncher`](https://perf.rust-lang.org/compare.html?start=c0672870491e84362f76ddecd50fa229f9b06dff&end=2ab5994d9cdfb098344895f7d8d5aee3cf3d6eff&stat=instructions:u) improves it very slightly not worth it to include it IMO. - Adding just [`diesel`](https://perf.rust-lang.org/compare.html?start=00755e4ca68f12ed200e921276788ab19975e85f&end=cd37706ad459ee8ddfda4631be71120cb7eda19d) improves it by up to 1.5 % and others crate slightly but regresses `bitmaps`. - Adding [`bitmaps`](https://perf.rust-lang.org/compare.html?start=67a9bcb31b85e87cc8bb327022632e48a0ca64a8&end=0cd80ba74425e6614cd52c4ea2bf6b0191c6dbc4&stat=instructions:u) improves both it and diesel no other regressions. - Adding [both](https://perf.rust-lang.org/compare.html?start=77972d2d0134fb597249b3b64dcf9510a790c34e&end=f968d7af511d750db96cfdc04f844fb017c079ce) `bitmaps` and `diesel` produces quite nice improvements and almost no regressions. - Adding [ucd](https://perf.rust-lang.org/compare.html?start=b5caa5a8421f84cb7664f999b7635801bcf3f96a&end=327cc09917311f65cf427e6c0bf5f7424af9fd05&stat=instructions:u) did not have a large effect on primary benchmarks. r? `@lqd`,ROCKET,2022-05-17T20:32:14Z,lqd,NA https://github.com/rust-lang/rust/pull/97134,OPEN,2022-05-18T06:18:18Z,NA,add file_suffix method to std::path,EvanCarroll,NA,NA,NA,THUMBS_UP,2022-05-18T06:29:32Z,mbhall88,michael@mbh.sh https://github.com/rust-lang/rust/pull/97134,OPEN,2022-05-18T06:18:18Z,NA,add file_suffix method to std::path,EvanCarroll,NA,NA,NA,THUMBS_UP,2022-05-18T10:08:58Z,fmease,NA https://github.com/rust-lang/rust/pull/97134,OPEN,2022-05-18T06:18:18Z,NA,add file_suffix method to std::path,EvanCarroll,NA,NA,NA,THUMBS_UP,2022-06-07T15:26:27Z,Virgiel,NA https://github.com/rust-lang/rust/pull/97136,CLOSED,2022-05-18T07:47:42Z,2022-05-25T00:53:36Z,Improve fast rejection.,nnethercote,NA,NA,NA,ROCKET,2022-05-18T13:24:08Z,Titaniumtown,Titaniumtown@gmail.com https://github.com/rust-lang/rust/pull/97136,CLOSED,2022-05-18T07:47:42Z,2022-05-25T00:53:36Z,Improve fast rejection.,nnethercote,NA,NA,NA,ROCKET,2022-05-18T18:44:49Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/97136,CLOSED,2022-05-18T07:47:42Z,2022-05-25T00:53:36Z,Improve fast rejection.,nnethercote,NA,NA,NA,ROCKET,2022-05-24T07:25:13Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97140,MERGED,2022-05-18T11:31:48Z,2022-06-26T21:28:33Z,std: use an event-flag-based thread parker on SOLID,joboet,c348beacea13b417f71f2b80534a9afb18a69c3e,5,Rollup merge of #97140 - joboet:solid_parker r=m-ou-se std: use an event-flag-based thread parker on SOLID `Mutex` and `Condvar` are being replaced by more efficient implementations which need thread parking themselves (see #93740). Therefore the generic `Parker` needs to be replaced on all platforms where the new lock implementation will be used which after #96393 are SOLID SGX and Hermit (more PRs coming soon). SOLID conforming to the [μITRON specification](http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf) has event flags which are a thread parking primitive very similar to `Parker`. However they do not make any atomic ordering guarantees (even though those can probably be assumed) and necessitate a system call even when the thread token is already available. Hence this `Parker` like the Windows parker uses an extra atomic state variable. I future-proofed the code by wrapping the event flag in a `WaitFlag` structure as both SGX and Hermit can share the Parker implementation they just have slightly different primitives (SGX uses signals and Hermit has a thread blocking API). `````@kawadakk````` I assume you are the target maintainer? Could you test this for me?,HEART,2022-05-18T13:26:59Z,m-ou-se,m-ou.se@m-ou.se https://github.com/rust-lang/rust/pull/97154,OPEN,2022-05-18T21:25:44Z,NA,[WIP] Use Thin LTO for compiling `rustc` in CI,Kobzol,NA,NA,NA,HOORAY,2022-06-05T07:30:35Z,ivan,NA https://github.com/rust-lang/rust/pull/97159,MERGED,2022-05-18T23:22:46Z,2022-05-19T03:59:16Z,Rollup of 6 pull requests,JohnTitor,e6327bc8b8d437b66ff91d9ce798a9eb45310967,12,"Auto merge of #97159 - JohnTitor:rollup-ibl51vw r=JohnTitor Rollup of 6 pull requests Successful merges: - #96866 (Switch CI bucket uploads to intelligent tiering) - #97062 (Couple of refactorings to cg_ssa::base::codegen_crate) - #97127 (Revert ""Auto merge of #96441 - ChrisDenton:sync-pipes r=m-ou-se"") - #97131 (Improve println! documentation) - #97139 (Move some settings DOM generation out of JS) - #97152 (Update cargo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup",HOORAY,2022-05-19T03:10:03Z,gimbles,NA https://github.com/rust-lang/rust/pull/97166,MERGED,2022-05-19T06:52:56Z,2022-06-02T00:55:50Z,Move conditions out of recover/report functions.,nnethercote,d126de111bdf74cbcd20f043139af4f1e57b3cba,5,Rollup merge of #97166 - nnethercote:move-conditions-out r=estebank Move conditions out of recover/report functions. `Parser` has six recover/report functions that are passed a boolean and nothing is done if the boolean has a particular value. This PR moves the tests outside the functions. This has the following effects. - The number of lines of code goes down. - Some `use` items become shorter. - Avoids the strangeness whereby 11 out of 12 calls to `maybe_recover_from_bad_qpath` pass `true` as the second argument. - Makes it clear at the call site that only one of `maybe_recover_from_bad_type_plus` and `maybe_report_ambiguous_plus` will be run. r? `@estebank`,THUMBS_UP,2022-06-01T17:54:35Z,estebank,NA https://github.com/rust-lang/rust/pull/97178,MERGED,2022-05-19T15:09:44Z,2022-06-15T23:49:15Z,Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation,sunfishcode,b31f9cc22bcd720b37ddf927afe378108a5b9a54,6,Auto merge of #97178 - sunfishcode:ownedfd-and-dup r=joshtriplett Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation Add a `BorrowedFd::try_clone_to_owned` which returns a new `OwnedFd` sharing the underlying file description. And similar for `BorrowedHandle` and `BorrowedSocket` on WIndows. This is similar to the existing `OwnedFd::try_clone` but it's named differently to reflect that it doesn't return `Result`. I'm open to suggestions for better names. Also extend the `unix::io` documentation to mention that `dup` is permitted on `BorrowedFd`. This was originally requsted [here](https://github.com/rust-lang/rust/issues/88564#issuecomment-910786081). At the time I wasn't sure whether it was desirable but it does have uses and it helps clarify the API. The documentation previously didn't rule out using `dup` on a `BorrowedFd` but the API only offered convenient ways to do it from an `OwnedFd`. With this patch the API allows one to do `try_clone` on any type where it's permitted.,THUMBS_UP,2022-06-02T09:23:32Z,chloekek,NA https://github.com/rust-lang/rust/pull/97178,MERGED,2022-05-19T15:09:44Z,2022-06-15T23:49:15Z,Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation,sunfishcode,b31f9cc22bcd720b37ddf927afe378108a5b9a54,6,Auto merge of #97178 - sunfishcode:ownedfd-and-dup r=joshtriplett Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation Add a `BorrowedFd::try_clone_to_owned` which returns a new `OwnedFd` sharing the underlying file description. And similar for `BorrowedHandle` and `BorrowedSocket` on WIndows. This is similar to the existing `OwnedFd::try_clone` but it's named differently to reflect that it doesn't return `Result`. I'm open to suggestions for better names. Also extend the `unix::io` documentation to mention that `dup` is permitted on `BorrowedFd`. This was originally requsted [here](https://github.com/rust-lang/rust/issues/88564#issuecomment-910786081). At the time I wasn't sure whether it was desirable but it does have uses and it helps clarify the API. The documentation previously didn't rule out using `dup` on a `BorrowedFd` but the API only offered convenient ways to do it from an `OwnedFd`. With this patch the API allows one to do `try_clone` on any type where it's permitted.,THUMBS_UP,2022-06-15T03:23:39Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/97178,MERGED,2022-05-19T15:09:44Z,2022-06-15T23:49:15Z,Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation,sunfishcode,b31f9cc22bcd720b37ddf927afe378108a5b9a54,6,Auto merge of #97178 - sunfishcode:ownedfd-and-dup r=joshtriplett Add a `BorrowedFd::try_clone_to_owned` and accompanying documentation Add a `BorrowedFd::try_clone_to_owned` which returns a new `OwnedFd` sharing the underlying file description. And similar for `BorrowedHandle` and `BorrowedSocket` on WIndows. This is similar to the existing `OwnedFd::try_clone` but it's named differently to reflect that it doesn't return `Result`. I'm open to suggestions for better names. Also extend the `unix::io` documentation to mention that `dup` is permitted on `BorrowedFd`. This was originally requsted [here](https://github.com/rust-lang/rust/issues/88564#issuecomment-910786081). At the time I wasn't sure whether it was desirable but it does have uses and it helps clarify the API. The documentation previously didn't rule out using `dup` on a `BorrowedFd` but the API only offered convenient ways to do it from an `OwnedFd`. With this patch the API allows one to do `try_clone` on any type where it's permitted.,THUMBS_UP,2022-06-15T03:48:29Z,JohnAnon9771,njoao97710@gmail.com https://github.com/rust-lang/rust/pull/97202,MERGED,2022-05-20T02:07:24Z,2022-06-16T02:13:09Z,os str capacity documentation,joshtriplett,b37e4e043eaeb74a8cf284bd7fddcce7d370552d,1,Rollup merge of #97202 - joshtriplett:os-str-capacity-documentation r=dtolnay os str capacity documentation This is based on https://github.com/rust-lang/rust/pull/95394 with expansion and consolidation to address comments from `@dtolnay` and other `@rust-lang/libs-api` team members.,HEART,2022-05-20T02:08:43Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/97202,MERGED,2022-05-20T02:07:24Z,2022-06-16T02:13:09Z,os str capacity documentation,joshtriplett,b37e4e043eaeb74a8cf284bd7fddcce7d370552d,1,Rollup merge of #97202 - joshtriplett:os-str-capacity-documentation r=dtolnay os str capacity documentation This is based on https://github.com/rust-lang/rust/pull/95394 with expansion and consolidation to address comments from `@dtolnay` and other `@rust-lang/libs-api` team members.,HEART,2022-05-20T03:19:55Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/97202,MERGED,2022-05-20T02:07:24Z,2022-06-16T02:13:09Z,os str capacity documentation,joshtriplett,b37e4e043eaeb74a8cf284bd7fddcce7d370552d,1,Rollup merge of #97202 - joshtriplett:os-str-capacity-documentation r=dtolnay os str capacity documentation This is based on https://github.com/rust-lang/rust/pull/95394 with expansion and consolidation to address comments from `@dtolnay` and other `@rust-lang/libs-api` team members.,HEART,2022-05-20T12:07:41Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/97202,MERGED,2022-05-20T02:07:24Z,2022-06-16T02:13:09Z,os str capacity documentation,joshtriplett,b37e4e043eaeb74a8cf284bd7fddcce7d370552d,1,Rollup merge of #97202 - joshtriplett:os-str-capacity-documentation r=dtolnay os str capacity documentation This is based on https://github.com/rust-lang/rust/pull/95394 with expansion and consolidation to address comments from `@dtolnay` and other `@rust-lang/libs-api` team members.,HEART,2022-05-21T05:24:08Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/97202,MERGED,2022-05-20T02:07:24Z,2022-06-16T02:13:09Z,os str capacity documentation,joshtriplett,b37e4e043eaeb74a8cf284bd7fddcce7d370552d,1,Rollup merge of #97202 - joshtriplett:os-str-capacity-documentation r=dtolnay os str capacity documentation This is based on https://github.com/rust-lang/rust/pull/95394 with expansion and consolidation to address comments from `@dtolnay` and other `@rust-lang/libs-api` team members.,HEART,2022-06-08T19:13:42Z,Agrailag,NA https://github.com/rust-lang/rust/pull/97235,MERGED,2022-05-20T22:15:12Z,2022-07-02T16:34:56Z,Fix FFI-unwind unsoundness with mixed panic mode,nbdd0121,6a1092056441652fe5fe5c5b422644951e6b99ce,27,"Auto merge of #97235 - nbdd0121:unwind r=Amanieu Fix FFI-unwind unsoundness with mixed panic mode UB maybe introduced when an FFI exception happens in a `C-unwind` foreign function and it propagates through a crate compiled with `-C panic=unwind` into a crate compiled with `-C panic=abort` (#96926). To prevent this unsoundness from happening we will disallow a crate compiled with `-C panic=unwind` to be linked into `panic-abort` *if* it contains a call to `C-unwind` foreign function or function pointer. If no such call exists then we continue to allow such mixed panic mode linking because it's sound (and stable). In fact we still need the ability to do mixed panic mode linking for std because we only compile std once with `-C panic=unwind` and link it regardless panic strategy. For libraries that wish to remain compile-once-and-linkable-to-both-panic-runtimes a `ffi_unwind_calls` lint is added (gated under `c_unwind` feature gate) to flag any FFI unwind calls that will cause the linkable panic runtime be restricted. In summary: ```rust #![warn(ffi_unwind_calls)] mod foo { #[no_mangle] pub extern ""C-unwind"" fn foo() {} } extern ""C-unwind"" { fn foo(); } fn main() { // Call to Rust function is fine regardless ABI. foo::foo(); // Call to foreign function will cause the crate to be unlinkable to panic-abort if compiled with `-Cpanic=unwind`. unsafe { foo(); } //~^ WARNING call to foreign function with FFI-unwind ABI let ptr: extern ""C-unwind"" fn() = foo::foo; // Call to function pointer will cause the crate to be unlinkable to panic-abort if compiled with `-Cpanic=unwind`. ptr(); //~^ WARNING call to function pointer with FFI-unwind ABI } ``` Fix #96926 `@rustbot` label: T-compiler F-c_unwind",THUMBS_UP,2022-05-20T22:42:55Z,BatmanAoD,NA https://github.com/rust-lang/rust/pull/97235,MERGED,2022-05-20T22:15:12Z,2022-07-02T16:34:56Z,Fix FFI-unwind unsoundness with mixed panic mode,nbdd0121,6a1092056441652fe5fe5c5b422644951e6b99ce,27,"Auto merge of #97235 - nbdd0121:unwind r=Amanieu Fix FFI-unwind unsoundness with mixed panic mode UB maybe introduced when an FFI exception happens in a `C-unwind` foreign function and it propagates through a crate compiled with `-C panic=unwind` into a crate compiled with `-C panic=abort` (#96926). To prevent this unsoundness from happening we will disallow a crate compiled with `-C panic=unwind` to be linked into `panic-abort` *if* it contains a call to `C-unwind` foreign function or function pointer. If no such call exists then we continue to allow such mixed panic mode linking because it's sound (and stable). In fact we still need the ability to do mixed panic mode linking for std because we only compile std once with `-C panic=unwind` and link it regardless panic strategy. For libraries that wish to remain compile-once-and-linkable-to-both-panic-runtimes a `ffi_unwind_calls` lint is added (gated under `c_unwind` feature gate) to flag any FFI unwind calls that will cause the linkable panic runtime be restricted. In summary: ```rust #![warn(ffi_unwind_calls)] mod foo { #[no_mangle] pub extern ""C-unwind"" fn foo() {} } extern ""C-unwind"" { fn foo(); } fn main() { // Call to Rust function is fine regardless ABI. foo::foo(); // Call to foreign function will cause the crate to be unlinkable to panic-abort if compiled with `-Cpanic=unwind`. unsafe { foo(); } //~^ WARNING call to foreign function with FFI-unwind ABI let ptr: extern ""C-unwind"" fn() = foo::foo; // Call to function pointer will cause the crate to be unlinkable to panic-abort if compiled with `-Cpanic=unwind`. ptr(); //~^ WARNING call to function pointer with FFI-unwind ABI } ``` Fix #96926 `@rustbot` label: T-compiler F-c_unwind",HOORAY,2022-05-23T08:35:33Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97239,MERGED,2022-05-21T01:10:06Z,2022-05-21T09:03:58Z,Remove `crate` visibility modifier,jhpratt,4f372b14dea58cbff1dd76bb651f9c035d3f6e7b,271,Auto merge of #97239 - jhpratt:remove-crate-vis r=joshtriplett Remove `crate` visibility modifier FCP to remove this syntax is just about complete in #53120. Once it completes this should be merged ASAP to avoid merge conflicts. The first two commits remove usage of the feature in this repository while the last removes the feature itself.,HEART,2022-05-21T02:58:27Z,est31,NA https://github.com/rust-lang/rust/pull/97239,MERGED,2022-05-21T01:10:06Z,2022-05-21T09:03:58Z,Remove `crate` visibility modifier,jhpratt,4f372b14dea58cbff1dd76bb651f9c035d3f6e7b,271,Auto merge of #97239 - jhpratt:remove-crate-vis r=joshtriplett Remove `crate` visibility modifier FCP to remove this syntax is just about complete in #53120. Once it completes this should be merged ASAP to avoid merge conflicts. The first two commits remove usage of the feature in this repository while the last removes the feature itself.,HEART,2022-05-25T12:49:32Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/97254,MERGED,2022-05-21T17:54:09Z,2022-05-23T10:27:28Z,Remove feature: `crate` visibility modifier,jhpratt,b73f1c77a7006d2e6ddebeb1d8adb33720bb33fb,17,Rollup merge of #97254 - jhpratt:remove-crate-vis r=cjgillot Remove feature: `crate` visibility modifier FCP completed in #53120.,HOORAY,2022-05-21T19:14:13Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/97254,MERGED,2022-05-21T17:54:09Z,2022-05-23T10:27:28Z,Remove feature: `crate` visibility modifier,jhpratt,b73f1c77a7006d2e6ddebeb1d8adb33720bb33fb,17,Rollup merge of #97254 - jhpratt:remove-crate-vis r=cjgillot Remove feature: `crate` visibility modifier FCP completed in #53120.,HOORAY,2022-05-21T22:22:46Z,est31,NA https://github.com/rust-lang/rust/pull/97254,MERGED,2022-05-21T17:54:09Z,2022-05-23T10:27:28Z,Remove feature: `crate` visibility modifier,jhpratt,b73f1c77a7006d2e6ddebeb1d8adb33720bb33fb,17,Rollup merge of #97254 - jhpratt:remove-crate-vis r=cjgillot Remove feature: `crate` visibility modifier FCP completed in #53120.,HOORAY,2022-05-22T08:56:05Z,taiki-e,NA https://github.com/rust-lang/rust/pull/97254,MERGED,2022-05-21T17:54:09Z,2022-05-23T10:27:28Z,Remove feature: `crate` visibility modifier,jhpratt,b73f1c77a7006d2e6ddebeb1d8adb33720bb33fb,17,Rollup merge of #97254 - jhpratt:remove-crate-vis r=cjgillot Remove feature: `crate` visibility modifier FCP completed in #53120.,HOORAY,2022-05-22T21:04:27Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97261,CLOSED,2022-05-22T00:06:52Z,2022-07-05T18:02:00Z,Keep valid scalar ranges attached to newtypes when dealing with their inner field.,luqmana,NA,NA,NA,HEART,2022-05-22T16:30:16Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97261,CLOSED,2022-05-22T00:06:52Z,2022-07-05T18:02:00Z,Keep valid scalar ranges attached to newtypes when dealing with their inner field.,luqmana,NA,NA,NA,LAUGH,2022-05-24T19:39:26Z,DrMeepster,NA https://github.com/rust-lang/rust/pull/97262,CLOSED,2022-05-22T02:03:42Z,2022-05-23T04:49:59Z,Improve suggestions for closure parameters,kuecks,NA,NA,NA,HEART,2022-05-22T02:17:27Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97264,MERGED,2022-05-22T02:49:35Z,2022-06-01T20:06:25Z,Suggest `extern crate foo` when failing to resolve `use foo`,TaKO8Ki,daedae7b233fe2e489bed5e586b013c2ce51f546,26,Rollup merge of #97264 - TaKO8Ki:suggest-extern-crate-when-failing-to-resolve-use-crate r=estebank Suggest `extern crate foo` when failing to resolve `use foo` closes #97095 r? ``@estebank``,HEART,2022-05-24T16:45:52Z,estebank,NA https://github.com/rust-lang/rust/pull/97266,MERGED,2022-05-22T02:56:07Z,2022-05-25T00:52:54Z,Make weird name lints trigger behind cfg_attr,est31,896a59d8dbf0387815d1022b4851686b9376ebe7,8,Rollup merge of #97266 - est31:unknown_lints_cfg_attr r=lcnr Make weird name lints trigger behind cfg_attr The weird name lints (`unknown_lints` `renamed_and_removed_lints`) the lints that lint the linting were previously not firing for lint level declarations behind `cfg_attr` as they were only running before expansion. Now this will give a `unknown_lints` warning: ```Rust #[cfg_attr(all() allow(this_lint_does_not_exist))] fn foo() {} ``` Lint level declarations behind a `cfg_attr` whose condition is not applying are still ignored. So this still won't give a warning: ```Rust #[cfg_attr(any() allow(this_lint_does_not_exist))] fn foo() {} ``` Furthermore this PR also makes the weird name lints respect level delcarations for *them* that were hidden by `cfg_attr` making them consistent to other lints. So this will now not issue a warning: ```Rust #[cfg_attr(all() allow(unknown_lints))] mod foo { #[allow(does_not_exist)] fn foo() { } } ``` Fixes #97094,HEART,2022-05-25T22:09:18Z,Xiphoseer,hi@dseiler.eu https://github.com/rust-lang/rust/pull/97271,MERGED,2022-05-22T07:14:44Z,2022-05-23T10:27:28Z,Add regression test for #91949,JohnTitor,6d366f15d4c86553880bca17c038e5a431c103b0,2,Rollup merge of #97271 - JohnTitor:issue-91949 r=compiler-errors Add regression test for #91949 Closes #91949 This needs `build-fail` because the original bug only appeared with `cargo build`. r? `@compiler-errors`,HEART,2022-05-23T13:25:35Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/97276,MERGED,2022-05-22T12:30:48Z,2022-06-08T16:01:37Z,Stabilize `const_intrinsic_copy`,JohnTitor,f6b04ad066c96622c90be20766a568a942075473,10,Rollup merge of #97276 - JohnTitor:stabilize-const-intrinsic-copy r=dtolnay Stabilize `const_intrinsic_copy` FCP has been completed: https://github.com/rust-lang/rust/issues/80697#issuecomment-1059825428 Closes #80697,THUMBS_UP,2022-05-24T15:54:44Z,usbalbin,NA https://github.com/rust-lang/rust/pull/97277,MERGED,2022-05-22T13:32:19Z,2022-05-22T19:16:20Z,Avoid accidentally enabling unstable features in compilers (take 2),jyn514,b4c17d43a684691569bc45e3820d7ffe646fa09d,3,Rollup merge of #97277 - jyn514:no-unstable-for-bootstrap r=Mark-Simulacrum Avoid accidentally enabling unstable features in compilers (take 2) This allows rustbuild to control whether crates can use nightly features or not. It also prevents rustbuild from using nightly features itself. This is #92261 but I fixed the CI error.,HEART,2022-05-22T14:01:49Z,est31,NA https://github.com/rust-lang/rust/pull/97284,MERGED,2022-05-22T18:16:05Z,2022-05-28T06:45:13Z,Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL,b-naber,ed76b773b57cf0aa48ec4e2fc6d6a3f7a9079491,23,Auto merge of #97284 - b-naber:constraint-dyn-impl-suggestion r=estebank Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics. Fixes https://github.com/rust-lang/rust/issues/95701 r? `@estebank`,HEART,2022-05-22T22:59:31Z,jackh726,NA https://github.com/rust-lang/rust/pull/97293,MERGED,2022-05-22T21:53:04Z,2022-06-02T16:04:41Z,Add #[rustc_box] and use it inside alloc,est31,20976bae5c426c738262db376eadbd8859aafc08,8,Auto merge of #97293 - est31:remove_box r=oli-obk Add #[rustc_box] and use it inside alloc This commit adds an alternative content boxing syntax and uses it inside alloc. ```Rust #![feature(box_syntax)] fn foo() { let foo = box bar; } ``` is equivalent to ```Rust #![feature(rustc_attrs)] fn foo() { let foo = #[rustc_box] Box::new(bar); } ``` The usage inside the very performance relevant code in liballoc is the only remaining relevant usage of box syntax in the compiler (outside of tests which are comparatively easy to port). box syntax was originally designed to be used by all Rust developers. This introduces a replacement syntax more tailored to only being used inside the Rust compiler and with it lays the groundwork for eventually removing box syntax. [Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step which is way earlier in the compiler and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully future work can move the lowering further back in the compiler as long as there are no performance regressions.,THUMBS_UP,2022-05-23T00:20:57Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/97293,MERGED,2022-05-22T21:53:04Z,2022-06-02T16:04:41Z,Add #[rustc_box] and use it inside alloc,est31,20976bae5c426c738262db376eadbd8859aafc08,8,Auto merge of #97293 - est31:remove_box r=oli-obk Add #[rustc_box] and use it inside alloc This commit adds an alternative content boxing syntax and uses it inside alloc. ```Rust #![feature(box_syntax)] fn foo() { let foo = box bar; } ``` is equivalent to ```Rust #![feature(rustc_attrs)] fn foo() { let foo = #[rustc_box] Box::new(bar); } ``` The usage inside the very performance relevant code in liballoc is the only remaining relevant usage of box syntax in the compiler (outside of tests which are comparatively easy to port). box syntax was originally designed to be used by all Rust developers. This introduces a replacement syntax more tailored to only being used inside the Rust compiler and with it lays the groundwork for eventually removing box syntax. [Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step which is way earlier in the compiler and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully future work can move the lowering further back in the compiler as long as there are no performance regressions.,THUMBS_UP,2022-05-23T01:10:17Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97293,MERGED,2022-05-22T21:53:04Z,2022-06-02T16:04:41Z,Add #[rustc_box] and use it inside alloc,est31,20976bae5c426c738262db376eadbd8859aafc08,8,Auto merge of #97293 - est31:remove_box r=oli-obk Add #[rustc_box] and use it inside alloc This commit adds an alternative content boxing syntax and uses it inside alloc. ```Rust #![feature(box_syntax)] fn foo() { let foo = box bar; } ``` is equivalent to ```Rust #![feature(rustc_attrs)] fn foo() { let foo = #[rustc_box] Box::new(bar); } ``` The usage inside the very performance relevant code in liballoc is the only remaining relevant usage of box syntax in the compiler (outside of tests which are comparatively easy to port). box syntax was originally designed to be used by all Rust developers. This introduces a replacement syntax more tailored to only being used inside the Rust compiler and with it lays the groundwork for eventually removing box syntax. [Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step which is way earlier in the compiler and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully future work can move the lowering further back in the compiler as long as there are no performance regressions.,THUMBS_UP,2022-05-23T19:46:54Z,fmease,NA https://github.com/rust-lang/rust/pull/97293,MERGED,2022-05-22T21:53:04Z,2022-06-02T16:04:41Z,Add #[rustc_box] and use it inside alloc,est31,20976bae5c426c738262db376eadbd8859aafc08,8,Auto merge of #97293 - est31:remove_box r=oli-obk Add #[rustc_box] and use it inside alloc This commit adds an alternative content boxing syntax and uses it inside alloc. ```Rust #![feature(box_syntax)] fn foo() { let foo = box bar; } ``` is equivalent to ```Rust #![feature(rustc_attrs)] fn foo() { let foo = #[rustc_box] Box::new(bar); } ``` The usage inside the very performance relevant code in liballoc is the only remaining relevant usage of box syntax in the compiler (outside of tests which are comparatively easy to port). box syntax was originally designed to be used by all Rust developers. This introduces a replacement syntax more tailored to only being used inside the Rust compiler and with it lays the groundwork for eventually removing box syntax. [Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step which is way earlier in the compiler and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully future work can move the lowering further back in the compiler as long as there are no performance regressions.,THUMBS_UP,2022-05-25T00:47:32Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97295,MERGED,2022-05-22T22:19:15Z,2022-06-26T21:28:33Z,[rustc_parse] Forbid `let`s in certain places,c410-f3r,5b312710d509e75b5d52b77d56e2d34ec2038696,13,Rollup merge of #97295 - c410-f3r:yet-another-let-chain r=compiler-errors [rustc_parse] Forbid `let`s in certain places Currently only forbids in locals to resolve https://github.com/rust-lang/rust/pull/94927#issuecomment-1099605024 but feel free to point any other places.,HEART,2022-05-22T22:25:27Z,est31,NA https://github.com/rust-lang/rust/pull/97295,MERGED,2022-05-22T22:19:15Z,2022-06-26T21:28:33Z,[rustc_parse] Forbid `let`s in certain places,c410-f3r,5b312710d509e75b5d52b77d56e2d34ec2038696,13,Rollup merge of #97295 - c410-f3r:yet-another-let-chain r=compiler-errors [rustc_parse] Forbid `let`s in certain places Currently only forbids in locals to resolve https://github.com/rust-lang/rust/pull/94927#issuecomment-1099605024 but feel free to point any other places.,HEART,2022-06-15T01:01:01Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/97295,MERGED,2022-05-22T22:19:15Z,2022-06-26T21:28:33Z,[rustc_parse] Forbid `let`s in certain places,c410-f3r,5b312710d509e75b5d52b77d56e2d34ec2038696,13,Rollup merge of #97295 - c410-f3r:yet-another-let-chain r=compiler-errors [rustc_parse] Forbid `let`s in certain places Currently only forbids in locals to resolve https://github.com/rust-lang/rust/pull/94927#issuecomment-1099605024 but feel free to point any other places.,HEART,2022-06-24T13:39:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97298,MERGED,2022-05-22T23:07:59Z,2022-05-24T19:05:21Z,Parse expression after `else` as a condition if followed by `{`,compiler-errors,0531521dbb470f17d2ebd68e558f41f936ec2e24,3,"Rollup merge of #97298 - compiler-errors:if-else-stmt-braces r=davidtwco Parse expression after `else` as a condition if followed by `{` Fixes #49361. Two things: 1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics :sweat_smile: 2. Do we even want to show the ""wrap in braces"" case? I would assume most of the time the ""add an `if`"" case is the right one.",HEART,2022-05-24T20:39:20Z,estebank,NA https://github.com/rust-lang/rust/pull/97298,MERGED,2022-05-22T23:07:59Z,2022-05-24T19:05:21Z,Parse expression after `else` as a condition if followed by `{`,compiler-errors,0531521dbb470f17d2ebd68e558f41f936ec2e24,3,"Rollup merge of #97298 - compiler-errors:if-else-stmt-braces r=davidtwco Parse expression after `else` as a condition if followed by `{` Fixes #49361. Two things: 1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics :sweat_smile: 2. Do we even want to show the ""wrap in braces"" case? I would assume most of the time the ""add an `if`"" case is the right one.",HEART,2022-06-02T04:41:36Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97316,MERGED,2022-05-23T14:26:57Z,2022-06-01T01:49:07Z,Put a bound on collection misbehavior,CAD97,4f4a819fa92fc61778593c74726f76fd08a2b917,5,"Rollup merge of #97316 - CAD97:bound-misbehavior r=dtolnay Put a bound on collection misbehavior As currently written when a logic error occurs in a collection's trait parameters this allows *completely arbitrary* misbehavior so long as it does not cause undefined behavior in std. However because the extent of misbehavior is not specified it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std this makes writing user unsafe code that utilizes std theoretically impossible as it now relies on undocumented QOI (quality of implementation) that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs. In practice this is a nonconcern because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation. To close this hole we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error making it more plausible to prove the soundness of user unsafe code. This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed as well as define what it means to ""observe"" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI. See also [discussion on IRLO][1]. [1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640 r? rust-lang/libs-api ```@rustbot``` label +T-libs-api -T-libs This technically adds a new guarantee to the documentation though I argue as written it's one already implicitly provided.",THUMBS_UP,2022-06-02T07:54:51Z,coolreader18,coolreader18@gmail.com https://github.com/rust-lang/rust/pull/97326,OPEN,2022-05-23T17:35:20Z,NA,rewrite `ensure_drop_predicates_are_implied_by_item_defn`,lcnr,NA,NA,NA,THUMBS_UP,2022-05-26T18:33:54Z,spastorino,spastorino@gmail.com https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-23T17:46:45Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-23T18:10:22Z,pvdrz,NA https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-23T18:14:54Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-23T18:32:20Z,ouz-a,ouz.agz@gmail.com https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-23T18:45:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-24T04:29:32Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-24T07:15:18Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-05-24T09:04:40Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/97327,MERGED,2022-05-23T17:45:35Z,2022-05-28T11:49:45Z,macros: introduce `fluent_messages` macro ,davidtwco,7e7dd1c0698187f54b2c3b36e8e3db1b67d3b2c4,14,"Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation r=oli-obk macros: introduce `fluent_messages` macro Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example given the following invocation of the macro.. ```rust fluent_messages! { typeck => ""./typeck.ftl"" } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource emitting a diagnostic if it fails to do so... ```text error: could not parse Fluent resource --> $DIR/test.rs:35:28 | LL | missing_message => ""./missing-message.ftl"" | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: see additional errors emitted error: expected a message field for ""missing-message"" --> ./missing-message.ftl:1:1 | 1 | missing-message = | ^^^^^^^^^^^^^^^^^^ | ``` ...or generating the following code if it succeeds: ```rust pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!(""./typeck.ftl"") ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent(""typeck-field-multiply-specified-in-initializer""); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( ""typeck-field-multiply-specified-in-initializer"" ""previous-use-label"" ); } } ``` When emitting a diagnostic the generated constants can be used as follows: ```rust let mut err = sess.struct_span_err( span fluent::typeck::field_multiply_specified_in_initializer ); err.span_label( span fluent::typeck::field_multiply_specified_in_initializer_label ); err.span_label( previous_use_span fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before) but I'll leave that for a follow-up. r? `@oli-obk` cc `@pvdrz` `@compiler-errors`",HEART,2022-06-04T10:19:13Z,berkus,NA https://github.com/rust-lang/rust/pull/97346,MERGED,2022-05-24T09:00:18Z,2022-06-28T16:10:37Z,Remove a back-compat hack on lazy TAIT,JohnTitor,c703d11dccb4a895c7aead3b2fcd8cea8c483184,4,Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks r=oli-obk Remove a back-compat hack on lazy TAIT This PR's motivation is here: https://github.com/rust-lang/rust/issues/72614#issuecomment-1134595446 ~~But removing a hack doesn't seem to reject the code on the issue there're some more hacks?~~ r? ``@oli-obk``,HEART,2022-05-24T09:46:24Z,oli-obk,NA https://github.com/rust-lang/rust/pull/97346,MERGED,2022-05-24T09:00:18Z,2022-06-28T16:10:37Z,Remove a back-compat hack on lazy TAIT,JohnTitor,c703d11dccb4a895c7aead3b2fcd8cea8c483184,4,Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks r=oli-obk Remove a back-compat hack on lazy TAIT This PR's motivation is here: https://github.com/rust-lang/rust/issues/72614#issuecomment-1134595446 ~~But removing a hack doesn't seem to reject the code on the issue there're some more hacks?~~ r? ``@oli-obk``,HEART,2022-06-16T16:06:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97366,MERGED,2022-05-24T18:41:04Z,2022-06-03T12:37:19Z,Stabilize `{slice array}::from_ref`,WaffleLapkin,025cf96615f44be6a75f82df50fa0f9e0e569b96,2,Rollup merge of #97366 - WaffleLapkin:stabilize_array_slice_from_ref r=dtolnay Stabilize `{slice array}::from_ref` This PR stabilizes the following APIs as `const` functions in Rust `1.63`: ```rust // core::array pub const fn from_ref(s: &T) -> &[T; 1]; // core::slice pub const fn from_ref(s: &T) -> &[T]; ``` Note that the `mut` versions are not stabilized as unique references (`&mut _`) are [unstable in const context]. FCP: https://github.com/rust-lang/rust/issues/90206#issuecomment-1134586665 r? rust-lang/libs-api `@rustbot` label +T-libs-api -T-libs [unstable in const context]: https://github.com/rust-lang/rust/issues/57349,HEART,2022-05-25T06:08:47Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97366,MERGED,2022-05-24T18:41:04Z,2022-06-03T12:37:19Z,Stabilize `{slice array}::from_ref`,WaffleLapkin,025cf96615f44be6a75f82df50fa0f9e0e569b96,2,Rollup merge of #97366 - WaffleLapkin:stabilize_array_slice_from_ref r=dtolnay Stabilize `{slice array}::from_ref` This PR stabilizes the following APIs as `const` functions in Rust `1.63`: ```rust // core::array pub const fn from_ref(s: &T) -> &[T; 1]; // core::slice pub const fn from_ref(s: &T) -> &[T]; ``` Note that the `mut` versions are not stabilized as unique references (`&mut _`) are [unstable in const context]. FCP: https://github.com/rust-lang/rust/issues/90206#issuecomment-1134586665 r? rust-lang/libs-api `@rustbot` label +T-libs-api -T-libs [unstable in const context]: https://github.com/rust-lang/rust/issues/57349,THUMBS_UP,2022-06-09T09:00:30Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97370,MERGED,2022-05-24T21:16:50Z,2022-05-25T13:58:43Z,Minor improvement on else-no-if diagnostic,compiler-errors,fe727e4dfc560ad5c973d04cd4e98ea943b463de,2,Rollup merge of #97370 - compiler-errors:else-no-if-2 r=Dylan-DPC Minor improvement on else-no-if diagnostic Don't suggest wrapping in block since it's highly likely to be a missing `if` after `else`. Also rework message a bit (open to further suggestions). cc: https://github.com/rust-lang/rust/pull/97298#discussion_r880933431 r? `@estebank`,HEART,2022-05-25T19:57:32Z,estebank,NA https://github.com/rust-lang/rust/pull/97377,MERGED,2022-05-24T23:43:14Z,2022-06-17T02:32:29Z,Do not suggest adding semicolon/changing delimiters for macros in item position that originates in macros,ChayimFriedman2,5cd8679dd2cdc31aec038a44e6c60f5e36db4808,4,Rollup merge of #97377 - ChayimFriedman2:issue-91800 r=estebank Do not suggest adding semicolon/changing delimiters for macros in item position that originates in macros Fixes #91800.,HEART,2022-05-26T22:18:23Z,estebank,NA https://github.com/rust-lang/rust/pull/97385,MERGED,2022-05-25T07:32:25Z,2022-06-14T02:17:40Z,Add WIP stable MIR crate,oli-obk,9688594d0040c7e80e3efe6efa5a0c4d155ba5ce,9,Rollup merge of #97385 - oli-obk:smir-tool-lib r=pnkfelix Add WIP stable MIR crate r? ``@pnkfelix`` Discussion about this happend in the SMIR meeting yesterday. Some info can be found at https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/dev.20plan.20mtg/near/283774691,HOORAY,2022-05-25T19:13:56Z,mati865,NA https://github.com/rust-lang/rust/pull/97385,MERGED,2022-05-25T07:32:25Z,2022-06-14T02:17:40Z,Add WIP stable MIR crate,oli-obk,9688594d0040c7e80e3efe6efa5a0c4d155ba5ce,9,Rollup merge of #97385 - oli-obk:smir-tool-lib r=pnkfelix Add WIP stable MIR crate r? ``@pnkfelix`` Discussion about this happend in the SMIR meeting yesterday. Some info can be found at https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/dev.20plan.20mtg/near/283774691,HOORAY,2022-05-25T20:23:53Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97385,MERGED,2022-05-25T07:32:25Z,2022-06-14T02:17:40Z,Add WIP stable MIR crate,oli-obk,9688594d0040c7e80e3efe6efa5a0c4d155ba5ce,9,Rollup merge of #97385 - oli-obk:smir-tool-lib r=pnkfelix Add WIP stable MIR crate r? ``@pnkfelix`` Discussion about this happend in the SMIR meeting yesterday. Some info can be found at https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/dev.20plan.20mtg/near/283774691,HOORAY,2022-05-25T20:29:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97385,MERGED,2022-05-25T07:32:25Z,2022-06-14T02:17:40Z,Add WIP stable MIR crate,oli-obk,9688594d0040c7e80e3efe6efa5a0c4d155ba5ce,9,Rollup merge of #97385 - oli-obk:smir-tool-lib r=pnkfelix Add WIP stable MIR crate r? ``@pnkfelix`` Discussion about this happend in the SMIR meeting yesterday. Some info can be found at https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/dev.20plan.20mtg/near/283774691,HOORAY,2022-05-26T19:31:07Z,ouz-a,ouz.agz@gmail.com https://github.com/rust-lang/rust/pull/97385,MERGED,2022-05-25T07:32:25Z,2022-06-14T02:17:40Z,Add WIP stable MIR crate,oli-obk,9688594d0040c7e80e3efe6efa5a0c4d155ba5ce,9,Rollup merge of #97385 - oli-obk:smir-tool-lib r=pnkfelix Add WIP stable MIR crate r? ``@pnkfelix`` Discussion about this happend in the SMIR meeting yesterday. Some info can be found at https://rust-lang.zulipchat.com/#narrow/stream/320896-project-stable-mir/topic/dev.20plan.20mtg/near/283774691,HOORAY,2022-06-14T04:53:51Z,xldenis,NA https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-05-25T19:13:28Z,mati865,NA https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-05-25T20:09:56Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-05-25T20:29:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-05-26T22:32:53Z,estebank,NA https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-06-05T12:51:55Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-06-05T12:55:17Z,taiki-e,NA https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-06-22T18:42:37Z,kamulos,NA https://github.com/rust-lang/rust/pull/97389,MERGED,2022-05-25T10:01:43Z,2022-06-27T19:10:00Z,Improve memory ordering diagnostics,m-ou-se,3694e40ffa55d65cb72148570f0fcab311741586,7,Rollup merge of #97389 - m-ou-se:memory-ordering-diagnostics r=estebank Improve memory ordering diagnostics Before: ![image](https://user-images.githubusercontent.com/783247/170234545-891cac30-eaa2-4186-847b-35cd51e00f2b.png) After: ![image](https://user-images.githubusercontent.com/783247/170239684-645f186f-5a02-4eb9-8651-2e5fe9591352.png) --- Before this change the compiler suggests the failure ordering is too strong and suggests choosing a weaker ordering. After this change it instead suggests the success ordering is not strong enough and suggests chosing a stronger one. This is more likely to be correct. Also before this change the compiler suggested downgrading an invalid AcqRel failure ordering to Relaxed without mentioning Acquire as an option.,HEART,2022-06-30T09:24:28Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/97391,MERGED,2022-05-25T11:14:14Z,2022-06-05T06:35:34Z,Handle more cases in cfg_accessible,Urgau,656eec8785e25a7fba568dba83190df2b0981daa,9,"Auto merge of #97391 - Urgau:cfg_accessible r=petrochenkov Handle more cases in cfg_accessible This PR tries to handle more cases in the cfg_accessible implementation by only emitting a ""not sure"" error only if we have partially resolved a path. This PR also adds many tests for the ""not sure"" cases and for private items. r? `@petrochenkov`",HEART,2022-05-25T12:15:50Z,est31,NA https://github.com/rust-lang/rust/pull/97391,MERGED,2022-05-25T11:14:14Z,2022-06-05T06:35:34Z,Handle more cases in cfg_accessible,Urgau,656eec8785e25a7fba568dba83190df2b0981daa,9,"Auto merge of #97391 - Urgau:cfg_accessible r=petrochenkov Handle more cases in cfg_accessible This PR tries to handle more cases in the cfg_accessible implementation by only emitting a ""not sure"" error only if we have partially resolved a path. This PR also adds many tests for the ""not sure"" cases and for private items. r? `@petrochenkov`",HEART,2022-05-25T17:18:09Z,CryZe,NA https://github.com/rust-lang/rust/pull/97391,MERGED,2022-05-25T11:14:14Z,2022-06-05T06:35:34Z,Handle more cases in cfg_accessible,Urgau,656eec8785e25a7fba568dba83190df2b0981daa,9,"Auto merge of #97391 - Urgau:cfg_accessible r=petrochenkov Handle more cases in cfg_accessible This PR tries to handle more cases in the cfg_accessible implementation by only emitting a ""not sure"" error only if we have partially resolved a path. This PR also adds many tests for the ""not sure"" cases and for private items. r? `@petrochenkov`",HEART,2022-05-28T06:08:07Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/97391,MERGED,2022-05-25T11:14:14Z,2022-06-05T06:35:34Z,Handle more cases in cfg_accessible,Urgau,656eec8785e25a7fba568dba83190df2b0981daa,9,"Auto merge of #97391 - Urgau:cfg_accessible r=petrochenkov Handle more cases in cfg_accessible This PR tries to handle more cases in the cfg_accessible implementation by only emitting a ""not sure"" error only if we have partially resolved a path. This PR also adds many tests for the ""not sure"" cases and for private items. r? `@petrochenkov`",HOORAY,2022-05-28T06:08:09Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/97406,OPEN,2022-05-25T18:39:01Z,NA,Make outlives::{components verify} agree,aliemjay,NA,NA,NA,HEART,2022-05-25T18:41:12Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97406,OPEN,2022-05-25T18:39:01Z,NA,Make outlives::{components verify} agree,aliemjay,NA,NA,NA,HEART,2022-05-25T20:36:17Z,fmease,NA https://github.com/rust-lang/rust/pull/97406,OPEN,2022-05-25T18:39:01Z,NA,Make outlives::{components verify} agree,aliemjay,NA,NA,NA,HEART,2022-05-26T00:42:19Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/97406,OPEN,2022-05-25T18:39:01Z,NA,Make outlives::{components verify} agree,aliemjay,NA,NA,NA,HEART,2022-05-26T07:08:39Z,oli-obk,NA https://github.com/rust-lang/rust/pull/97406,OPEN,2022-05-25T18:39:01Z,NA,Make outlives::{components verify} agree,aliemjay,NA,NA,NA,HEART,2022-05-31T11:34:32Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/97414,MERGED,2022-05-26T06:30:00Z,2022-06-02T06:59:33Z,use 128 cache align for aarch64,LYF1999,fb1976011e3df96b5d3eccd6b2f4e51ef7dc8f16,1,Auto merge of #97414 - LYF1999:yf/cachealign r=Mark-Simulacrum use 128 cache align for aarch64 the cache line size of m1 mac is 128. so use `align(128)` for m1 mac here is `sysctl -a hw machdep.cpu` output on m1 mac ``` hw.ncpu: 10 hw.byteorder: 1234 hw.memsize: 68719476736 hw.activecpu: 10 hw.perflevel0.physicalcpu: 8 hw.perflevel0.physicalcpu_max: 8 hw.perflevel0.logicalcpu: 8 hw.perflevel0.logicalcpu_max: 8 hw.perflevel0.l1icachesize: 196608 hw.perflevel0.l1dcachesize: 131072 hw.perflevel0.l2cachesize: 12582912 hw.perflevel0.cpusperl2: 4 hw.perflevel1.physicalcpu: 2 hw.perflevel1.physicalcpu_max: 2 hw.perflevel1.logicalcpu: 2 hw.perflevel1.logicalcpu_max: 2 hw.perflevel1.l1icachesize: 131072 hw.perflevel1.l1dcachesize: 65536 hw.perflevel1.l2cachesize: 4194304 hw.perflevel1.cpusperl2: 2 hw.optional.arm.FEAT_FlagM: 1 hw.optional.arm.FEAT_FlagM2: 1 hw.optional.arm.FEAT_FHM: 1 hw.optional.arm.FEAT_DotProd: 1 hw.optional.arm.FEAT_SHA3: 1 hw.optional.arm.FEAT_RDM: 1 hw.optional.arm.FEAT_LSE: 1 hw.optional.arm.FEAT_SHA256: 1 hw.optional.arm.FEAT_SHA512: 1 hw.optional.arm.FEAT_SHA1: 1 hw.optional.arm.FEAT_AES: 1 hw.optional.arm.FEAT_PMULL: 1 hw.optional.arm.FEAT_SPECRES: 0 hw.optional.arm.FEAT_SB: 1 hw.optional.arm.FEAT_FRINTTS: 1 hw.optional.arm.FEAT_LRCPC: 1 hw.optional.arm.FEAT_LRCPC2: 1 hw.optional.arm.FEAT_FCMA: 1 hw.optional.arm.FEAT_JSCVT: 1 hw.optional.arm.FEAT_PAuth: 1 hw.optional.arm.FEAT_PAuth2: 0 hw.optional.arm.FEAT_FPAC: 0 hw.optional.arm.FEAT_DPB: 1 hw.optional.arm.FEAT_DPB2: 1 hw.optional.arm.FEAT_BF16: 0 hw.optional.arm.FEAT_I8MM: 0 hw.optional.arm.FEAT_ECV: 1 hw.optional.arm.FEAT_LSE2: 1 hw.optional.arm.FEAT_CSV2: 1 hw.optional.arm.FEAT_CSV3: 1 hw.optional.arm.FEAT_FP16: 1 hw.optional.arm.FEAT_SSBS: 1 hw.optional.arm.FEAT_BTI: 0 hw.optional.floatingpoint: 1 hw.optional.neon: 1 hw.optional.neon_hpfp: 1 hw.optional.neon_fp16: 1 hw.optional.armv8_1_atomics: 1 hw.optional.armv8_2_fhm: 1 hw.optional.armv8_2_sha512: 1 hw.optional.armv8_2_sha3: 1 hw.optional.armv8_3_compnum: 1 hw.optional.watchpoint: 4 hw.optional.breakpoint: 6 hw.optional.armv8_crc32: 1 hw.optional.armv8_gpi: 1 hw.optional.AdvSIMD: 1 hw.optional.AdvSIMD_HPFPCvt: 1 hw.optional.ucnormal_mem: 1 hw.optional.arm64: 1 hw.features.allows_security_research: 0 hw.physicalcpu: 10 hw.physicalcpu_max: 10 hw.logicalcpu: 10 hw.logicalcpu_max: 10 hw.cputype: 16777228 hw.cpusubtype: 2 hw.cpu64bit_capable: 1 hw.cpufamily: 458787763 hw.cpusubfamily: 5 hw.cacheconfig: 10 1 2 0 0 0 0 0 0 0 hw.cachesize: 3373957120 65536 4194304 0 0 0 0 0 0 0 hw.pagesize: 16384 hw.pagesize32: 16384 hw.cachelinesize: 128 hw.l1icachesize: 131072 hw.l1dcachesize: 65536 hw.l2cachesize: 4194304 hw.tbfrequency: 24000000 hw.packages: 1 hw.osenvironment: hw.ephemeral_storage: 0 hw.use_recovery_securityd: 0 hw.use_kernelmanagerd: 1 hw.serialdebugmode: 0 hw.nperflevels: 2 hw.targettype: J316c machdep.cpu.cores_per_package: 10 machdep.cpu.core_count: 10 machdep.cpu.logical_per_package: 10 machdep.cpu.thread_count: 10 machdep.cpu.brand_string: Apple M1 Max ```,THUMBS_UP,2022-05-26T08:40:29Z,hkratz,NA https://github.com/rust-lang/rust/pull/97414,MERGED,2022-05-26T06:30:00Z,2022-06-02T06:59:33Z,use 128 cache align for aarch64,LYF1999,fb1976011e3df96b5d3eccd6b2f4e51ef7dc8f16,1,Auto merge of #97414 - LYF1999:yf/cachealign r=Mark-Simulacrum use 128 cache align for aarch64 the cache line size of m1 mac is 128. so use `align(128)` for m1 mac here is `sysctl -a hw machdep.cpu` output on m1 mac ``` hw.ncpu: 10 hw.byteorder: 1234 hw.memsize: 68719476736 hw.activecpu: 10 hw.perflevel0.physicalcpu: 8 hw.perflevel0.physicalcpu_max: 8 hw.perflevel0.logicalcpu: 8 hw.perflevel0.logicalcpu_max: 8 hw.perflevel0.l1icachesize: 196608 hw.perflevel0.l1dcachesize: 131072 hw.perflevel0.l2cachesize: 12582912 hw.perflevel0.cpusperl2: 4 hw.perflevel1.physicalcpu: 2 hw.perflevel1.physicalcpu_max: 2 hw.perflevel1.logicalcpu: 2 hw.perflevel1.logicalcpu_max: 2 hw.perflevel1.l1icachesize: 131072 hw.perflevel1.l1dcachesize: 65536 hw.perflevel1.l2cachesize: 4194304 hw.perflevel1.cpusperl2: 2 hw.optional.arm.FEAT_FlagM: 1 hw.optional.arm.FEAT_FlagM2: 1 hw.optional.arm.FEAT_FHM: 1 hw.optional.arm.FEAT_DotProd: 1 hw.optional.arm.FEAT_SHA3: 1 hw.optional.arm.FEAT_RDM: 1 hw.optional.arm.FEAT_LSE: 1 hw.optional.arm.FEAT_SHA256: 1 hw.optional.arm.FEAT_SHA512: 1 hw.optional.arm.FEAT_SHA1: 1 hw.optional.arm.FEAT_AES: 1 hw.optional.arm.FEAT_PMULL: 1 hw.optional.arm.FEAT_SPECRES: 0 hw.optional.arm.FEAT_SB: 1 hw.optional.arm.FEAT_FRINTTS: 1 hw.optional.arm.FEAT_LRCPC: 1 hw.optional.arm.FEAT_LRCPC2: 1 hw.optional.arm.FEAT_FCMA: 1 hw.optional.arm.FEAT_JSCVT: 1 hw.optional.arm.FEAT_PAuth: 1 hw.optional.arm.FEAT_PAuth2: 0 hw.optional.arm.FEAT_FPAC: 0 hw.optional.arm.FEAT_DPB: 1 hw.optional.arm.FEAT_DPB2: 1 hw.optional.arm.FEAT_BF16: 0 hw.optional.arm.FEAT_I8MM: 0 hw.optional.arm.FEAT_ECV: 1 hw.optional.arm.FEAT_LSE2: 1 hw.optional.arm.FEAT_CSV2: 1 hw.optional.arm.FEAT_CSV3: 1 hw.optional.arm.FEAT_FP16: 1 hw.optional.arm.FEAT_SSBS: 1 hw.optional.arm.FEAT_BTI: 0 hw.optional.floatingpoint: 1 hw.optional.neon: 1 hw.optional.neon_hpfp: 1 hw.optional.neon_fp16: 1 hw.optional.armv8_1_atomics: 1 hw.optional.armv8_2_fhm: 1 hw.optional.armv8_2_sha512: 1 hw.optional.armv8_2_sha3: 1 hw.optional.armv8_3_compnum: 1 hw.optional.watchpoint: 4 hw.optional.breakpoint: 6 hw.optional.armv8_crc32: 1 hw.optional.armv8_gpi: 1 hw.optional.AdvSIMD: 1 hw.optional.AdvSIMD_HPFPCvt: 1 hw.optional.ucnormal_mem: 1 hw.optional.arm64: 1 hw.features.allows_security_research: 0 hw.physicalcpu: 10 hw.physicalcpu_max: 10 hw.logicalcpu: 10 hw.logicalcpu_max: 10 hw.cputype: 16777228 hw.cpusubtype: 2 hw.cpu64bit_capable: 1 hw.cpufamily: 458787763 hw.cpusubfamily: 5 hw.cacheconfig: 10 1 2 0 0 0 0 0 0 0 hw.cachesize: 3373957120 65536 4194304 0 0 0 0 0 0 0 hw.pagesize: 16384 hw.pagesize32: 16384 hw.cachelinesize: 128 hw.l1icachesize: 131072 hw.l1dcachesize: 65536 hw.l2cachesize: 4194304 hw.tbfrequency: 24000000 hw.packages: 1 hw.osenvironment: hw.ephemeral_storage: 0 hw.use_recovery_securityd: 0 hw.use_kernelmanagerd: 1 hw.serialdebugmode: 0 hw.nperflevels: 2 hw.targettype: J316c machdep.cpu.cores_per_package: 10 machdep.cpu.core_count: 10 machdep.cpu.logical_per_package: 10 machdep.cpu.thread_count: 10 machdep.cpu.brand_string: Apple M1 Max ```,THUMBS_UP,2022-05-28T02:01:18Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/97414,MERGED,2022-05-26T06:30:00Z,2022-06-02T06:59:33Z,use 128 cache align for aarch64,LYF1999,fb1976011e3df96b5d3eccd6b2f4e51ef7dc8f16,1,Auto merge of #97414 - LYF1999:yf/cachealign r=Mark-Simulacrum use 128 cache align for aarch64 the cache line size of m1 mac is 128. so use `align(128)` for m1 mac here is `sysctl -a hw machdep.cpu` output on m1 mac ``` hw.ncpu: 10 hw.byteorder: 1234 hw.memsize: 68719476736 hw.activecpu: 10 hw.perflevel0.physicalcpu: 8 hw.perflevel0.physicalcpu_max: 8 hw.perflevel0.logicalcpu: 8 hw.perflevel0.logicalcpu_max: 8 hw.perflevel0.l1icachesize: 196608 hw.perflevel0.l1dcachesize: 131072 hw.perflevel0.l2cachesize: 12582912 hw.perflevel0.cpusperl2: 4 hw.perflevel1.physicalcpu: 2 hw.perflevel1.physicalcpu_max: 2 hw.perflevel1.logicalcpu: 2 hw.perflevel1.logicalcpu_max: 2 hw.perflevel1.l1icachesize: 131072 hw.perflevel1.l1dcachesize: 65536 hw.perflevel1.l2cachesize: 4194304 hw.perflevel1.cpusperl2: 2 hw.optional.arm.FEAT_FlagM: 1 hw.optional.arm.FEAT_FlagM2: 1 hw.optional.arm.FEAT_FHM: 1 hw.optional.arm.FEAT_DotProd: 1 hw.optional.arm.FEAT_SHA3: 1 hw.optional.arm.FEAT_RDM: 1 hw.optional.arm.FEAT_LSE: 1 hw.optional.arm.FEAT_SHA256: 1 hw.optional.arm.FEAT_SHA512: 1 hw.optional.arm.FEAT_SHA1: 1 hw.optional.arm.FEAT_AES: 1 hw.optional.arm.FEAT_PMULL: 1 hw.optional.arm.FEAT_SPECRES: 0 hw.optional.arm.FEAT_SB: 1 hw.optional.arm.FEAT_FRINTTS: 1 hw.optional.arm.FEAT_LRCPC: 1 hw.optional.arm.FEAT_LRCPC2: 1 hw.optional.arm.FEAT_FCMA: 1 hw.optional.arm.FEAT_JSCVT: 1 hw.optional.arm.FEAT_PAuth: 1 hw.optional.arm.FEAT_PAuth2: 0 hw.optional.arm.FEAT_FPAC: 0 hw.optional.arm.FEAT_DPB: 1 hw.optional.arm.FEAT_DPB2: 1 hw.optional.arm.FEAT_BF16: 0 hw.optional.arm.FEAT_I8MM: 0 hw.optional.arm.FEAT_ECV: 1 hw.optional.arm.FEAT_LSE2: 1 hw.optional.arm.FEAT_CSV2: 1 hw.optional.arm.FEAT_CSV3: 1 hw.optional.arm.FEAT_FP16: 1 hw.optional.arm.FEAT_SSBS: 1 hw.optional.arm.FEAT_BTI: 0 hw.optional.floatingpoint: 1 hw.optional.neon: 1 hw.optional.neon_hpfp: 1 hw.optional.neon_fp16: 1 hw.optional.armv8_1_atomics: 1 hw.optional.armv8_2_fhm: 1 hw.optional.armv8_2_sha512: 1 hw.optional.armv8_2_sha3: 1 hw.optional.armv8_3_compnum: 1 hw.optional.watchpoint: 4 hw.optional.breakpoint: 6 hw.optional.armv8_crc32: 1 hw.optional.armv8_gpi: 1 hw.optional.AdvSIMD: 1 hw.optional.AdvSIMD_HPFPCvt: 1 hw.optional.ucnormal_mem: 1 hw.optional.arm64: 1 hw.features.allows_security_research: 0 hw.physicalcpu: 10 hw.physicalcpu_max: 10 hw.logicalcpu: 10 hw.logicalcpu_max: 10 hw.cputype: 16777228 hw.cpusubtype: 2 hw.cpu64bit_capable: 1 hw.cpufamily: 458787763 hw.cpusubfamily: 5 hw.cacheconfig: 10 1 2 0 0 0 0 0 0 0 hw.cachesize: 3373957120 65536 4194304 0 0 0 0 0 0 0 hw.pagesize: 16384 hw.pagesize32: 16384 hw.cachelinesize: 128 hw.l1icachesize: 131072 hw.l1dcachesize: 65536 hw.l2cachesize: 4194304 hw.tbfrequency: 24000000 hw.packages: 1 hw.osenvironment: hw.ephemeral_storage: 0 hw.use_recovery_securityd: 0 hw.use_kernelmanagerd: 1 hw.serialdebugmode: 0 hw.nperflevels: 2 hw.targettype: J316c machdep.cpu.cores_per_package: 10 machdep.cpu.core_count: 10 machdep.cpu.logical_per_package: 10 machdep.cpu.thread_count: 10 machdep.cpu.brand_string: Apple M1 Max ```,THUMBS_UP,2022-06-02T09:36:21Z,dyxushuai,john.xu@bytedance.com https://github.com/rust-lang/rust/pull/97436,MERGED,2022-05-26T19:42:59Z,2022-05-27T06:07:54Z,Update `triagebot.toml` for macos ping group,compiler-errors,036f62badf311de9906a58b547295469ed7a10c1,1,Rollup merge of #97436 - compiler-errors:macos-ping-2 r=Mark-Simulacrum Update `triagebot.toml` for macos ping group idk what i'm doing but i saw https://github.com/rust-lang/rust/pull/96392#issuecomment-1138893845 cc: `@thomcc`,THUMBS_UP,2022-05-26T23:54:18Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/97436,MERGED,2022-05-26T19:42:59Z,2022-05-27T06:07:54Z,Update `triagebot.toml` for macos ping group,compiler-errors,036f62badf311de9906a58b547295469ed7a10c1,1,Rollup merge of #97436 - compiler-errors:macos-ping-2 r=Mark-Simulacrum Update `triagebot.toml` for macos ping group idk what i'm doing but i saw https://github.com/rust-lang/rust/pull/96392#issuecomment-1138893845 cc: `@thomcc`,HOORAY,2022-05-26T23:54:22Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/97443,OPEN,2022-05-26T22:48:43Z,NA,Make x.py clippy download and use beta clippy,asquared31415,NA,NA,NA,HEART,2022-05-26T22:49:47Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/97458,MERGED,2022-05-27T17:58:55Z,2022-05-28T01:37:10Z,Modify `derive(Debug)` to use `Self` in struct literal to avoid redundant error,estebank,0804ef656399d4a31e9aa07c34a64d7628320880,3,Rollup merge of #97458 - estebank:use-self-in-derive-macro r=compiler-errors Modify `derive(Debug)` to use `Self` in struct literal to avoid redundant error Reduce verbosity in #97343.,THUMBS_UP,2022-05-27T18:05:28Z,fmease,NA https://github.com/rust-lang/rust/pull/97461,MERGED,2022-05-27T19:11:17Z,2022-05-28T19:30:55Z,proc_macro: don't pass a client-side function pointer through the server.,eddyb,116201eefebcf45074ae232377e7145f5fbb704b,8,"Auto merge of #97461 - eddyb:proc-macro-less-payload r=bjorn3 proc_macro: don't pass a client-side function pointer through the server. Before this PR `proc_macro::bridge::Client` contained both: * the C ABI entry-point `run` that the server can call to start the client * some ""payload"" `f: F` passed to that entry-point * in practice this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream` In other words the client was passing one of its (Rust) `fn` pointers to the server which was passing it back to the client for the client to call (see later below for why that was ever needed). I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see https://github.com/rust-lang/rust/pull/97004#issuecomment-1139273301) which combined with removing the `f` (""payload"") field could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer (and in the context of e.g. wasm isolation that's *all* you want since you can reason about it from outside the wasm VM as just a 32-bit ""function table index"" that you can pass to the wasm VM to call that function).
So this PR removes that ""payload"". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type because function types don't implement anything like `Default` i.e.: ```rust extern ""C"" fn ffi_wrapper R>(arg: A) -> R { let f: F = ???; // no way to get a value of `F` f(arg) } ``` That could be solved with something like this if it was allowed: ```rust extern ""C"" fn ffi_wrapper< A R F: Fn(A) -> R const f: F // not allowed because the type is a generic param >(arg: A) -> R { f(arg) } ``` Instead this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation).
Hopefully this time we don't have a performance regression and this has a chance to land. cc `@mystor` `@bjorn3`",HEART,2022-05-27T19:50:52Z,lqd,NA https://github.com/rust-lang/rust/pull/97471,MERGED,2022-05-28T02:54:06Z,2022-06-03T17:55:02Z,Provide more context when denying invalid type params ,estebank,6b80b151b9f90166e22164f08e95a5c9e41dda0e,30,Rollup merge of #97471 - estebank:prohibit-generics r=cjgillot Provide more context when denying invalid type params,HEART,2022-05-28T04:44:07Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97471,MERGED,2022-05-28T02:54:06Z,2022-06-03T17:55:02Z,Provide more context when denying invalid type params ,estebank,6b80b151b9f90166e22164f08e95a5c9e41dda0e,30,Rollup merge of #97471 - estebank:prohibit-generics r=cjgillot Provide more context when denying invalid type params,HEART,2022-05-28T06:09:41Z,fmease,NA https://github.com/rust-lang/rust/pull/97472,MERGED,2022-05-28T03:25:55Z,2022-05-29T00:40:48Z,Update to rebased rustc-rayon 0.4,cuviper,14f477e78adb9960f760e9bac812673f993d8dc2,7,Auto merge of #97472 - cuviper:rebase-rustc-rayon r=Mark-Simulacrum Update to rebased rustc-rayon 0.4 In rayon-rs/rayon#938 miri uncovered a race in `rustc-rayon-core` that had already been fixed in the regular `rayon-core`. I have now rebased that fork onto the latest rayon branch and published as 0.4. I also updated `indexmap` to bump the dependency. `Cargo.lock` changes: Updating indexmap v1.8.0 -> v1.8.2 Updating rayon v1.5.1 -> v1.5.3 Updating rayon-core v1.9.1 -> v1.9.3 Updating rustc-rayon v0.3.2 -> v0.4.0 Updating rustc-rayon-core v0.3.2 -> v0.4.1,HOORAY,2022-05-28T06:54:11Z,mati865,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,THUMBS_UP,2022-05-28T16:02:44Z,Agrailag,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-05-28T17:13:46Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-05-28T20:02:30Z,mati865,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-05-28T20:45:38Z,est31,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,THUMBS_UP,2022-05-29T03:36:51Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-05-29T03:36:52Z,messense,messense@icloud.com https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,THUMBS_UP,2022-06-13T16:23:32Z,Virgiel,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-06-13T16:23:33Z,Virgiel,NA https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,THUMBS_UP,2022-06-13T21:39:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97485,OPEN,2022-05-28T13:20:09Z,NA,Rewrite LLVM's archive writer in Rust ,bjorn3,NA,NA,NA,HEART,2022-06-13T21:39:07Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97495,MERGED,2022-05-28T21:28:26Z,2022-06-06T19:40:55Z,Add E0788 for improper #[no_coverage] usage,clarfonthey,cb787bea4613189da9f0b26406e11ee8cb39d422,5,Rollup merge of #97495 - clarfonthey:e0788-no-coverage r=nagisa Add E0788 for improper #[no_coverage] usage Essentially this adds proper checking for the attribute (tracking issue #84605) and throws errors when it's put in obviously-wrong places like on struct or const definitions. Most of the code is taken directly from the checks for the `#[inline]` attribute since it's very similar. Right now the code only checks at the function level but it seems reasonable to allow adding `#[no_coverage]` to individual blocks or expressions so for now those just throw `unused_attributes` warnings. Similarly since there was a lot of desire to eventually allow recursive definitions as well on modules and impl blocks these also throw `unused_attributes` instead of an error. I'm not sure if anything has to be done since this error is technically for an unstable feature but since an error for using unstable features will show up anyway I think it's okay. This is the first big piece needed for stabilising this attribute although I personally would like to explore renaming it to `#[coverage(never)]` on a separate PR which I will offer soon. There's a lot of discussion still to be had about that which is why it will be kept separate. I don't think much is needed besides adding this simple check and a UI test but let me know if there's something else that should be added to make this happen.,HEART,2022-06-06T17:56:57Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/97512,MERGED,2022-05-29T07:26:08Z,2022-06-07T11:09:13Z,Add support for emitting functions with `coldcc` to LLVM,scottmcm,91cacb3faf987805675e39aca41859ec1fcabef3,14,Auto merge of #97512 - scottmcm:add-coldcc r=nagisa lcnr Add support for emitting functions with `coldcc` to LLVM The eventual goal is to try using this for things like the internal panicking stuff to see whether it helps.,HOORAY,2022-05-30T08:59:06Z,thomcc,thom@shift.click https://github.com/rust-lang/rust/pull/97512,MERGED,2022-05-29T07:26:08Z,2022-06-07T11:09:13Z,Add support for emitting functions with `coldcc` to LLVM,scottmcm,91cacb3faf987805675e39aca41859ec1fcabef3,14,Auto merge of #97512 - scottmcm:add-coldcc r=nagisa lcnr Add support for emitting functions with `coldcc` to LLVM The eventual goal is to try using this for things like the internal panicking stuff to see whether it helps.,HOORAY,2022-06-18T02:06:48Z,GrayJack,NA https://github.com/rust-lang/rust/pull/97512,MERGED,2022-05-29T07:26:08Z,2022-06-07T11:09:13Z,Add support for emitting functions with `coldcc` to LLVM,scottmcm,91cacb3faf987805675e39aca41859ec1fcabef3,14,Auto merge of #97512 - scottmcm:add-coldcc r=nagisa lcnr Add support for emitting functions with `coldcc` to LLVM The eventual goal is to try using this for things like the internal panicking stuff to see whether it helps.,HOORAY,2022-06-19T13:02:38Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97513,MERGED,2022-05-29T07:31:54Z,2022-06-25T23:42:06Z,Fully remove submodule handling from bootstrap.py,jyn514,20a6f3a8a8ce5ae18d06b12cd7904bc5294ca753,9,Auto merge of #97513 - jyn514:submodule-handling r=Mark-Simulacrum Fully remove submodule handling from bootstrap.py These submodules were previously updated in python because Cargo gives a hard error if toml files are missing from the workspace: ``` error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls` Caused by: failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml` Caused by: No such file or directory (os error 2) failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml ``` However bootstrap doesn't actually need to be part of the workspace. Remove it so we can move submodule handling fully to Rust avoiding duplicate code between Rust and Python. Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now. Given that we're planning to make the main entrypoint a shell script (or rust binary) I think this is a good tradeoff for reduced complexity in bootstrap.py. To get this working I also had to remove support for vendoring when using the git sources because `cargo vendor` requires all submodules to be checked out. I think this is ok; people who care about this are likely already using the pre-vendored `rustc-src` tarball. Fixes https://github.com/rust-lang/rust/issues/90764. Helps with #94829,HEART,2022-05-29T13:26:58Z,bjorn3,NA https://github.com/rust-lang/rust/pull/97513,MERGED,2022-05-29T07:31:54Z,2022-06-25T23:42:06Z,Fully remove submodule handling from bootstrap.py,jyn514,20a6f3a8a8ce5ae18d06b12cd7904bc5294ca753,9,Auto merge of #97513 - jyn514:submodule-handling r=Mark-Simulacrum Fully remove submodule handling from bootstrap.py These submodules were previously updated in python because Cargo gives a hard error if toml files are missing from the workspace: ``` error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls` Caused by: failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml` Caused by: No such file or directory (os error 2) failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml ``` However bootstrap doesn't actually need to be part of the workspace. Remove it so we can move submodule handling fully to Rust avoiding duplicate code between Rust and Python. Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now. Given that we're planning to make the main entrypoint a shell script (or rust binary) I think this is a good tradeoff for reduced complexity in bootstrap.py. To get this working I also had to remove support for vendoring when using the git sources because `cargo vendor` requires all submodules to be checked out. I think this is ok; people who care about this are likely already using the pre-vendored `rustc-src` tarball. Fixes https://github.com/rust-lang/rust/issues/90764. Helps with #94829,HEART,2022-05-31T17:12:44Z,yerke,NA https://github.com/rust-lang/rust/pull/97513,MERGED,2022-05-29T07:31:54Z,2022-06-25T23:42:06Z,Fully remove submodule handling from bootstrap.py,jyn514,20a6f3a8a8ce5ae18d06b12cd7904bc5294ca753,9,Auto merge of #97513 - jyn514:submodule-handling r=Mark-Simulacrum Fully remove submodule handling from bootstrap.py These submodules were previously updated in python because Cargo gives a hard error if toml files are missing from the workspace: ``` error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls` Caused by: failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml` Caused by: No such file or directory (os error 2) failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml ``` However bootstrap doesn't actually need to be part of the workspace. Remove it so we can move submodule handling fully to Rust avoiding duplicate code between Rust and Python. Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now. Given that we're planning to make the main entrypoint a shell script (or rust binary) I think this is a good tradeoff for reduced complexity in bootstrap.py. To get this working I also had to remove support for vendoring when using the git sources because `cargo vendor` requires all submodules to be checked out. I think this is ok; people who care about this are likely already using the pre-vendored `rustc-src` tarball. Fixes https://github.com/rust-lang/rust/issues/90764. Helps with #94829,HEART,2022-06-26T07:36:53Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97521,MERGED,2022-05-29T15:54:02Z,2022-05-31T14:55:38Z,Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation,SkiFire13,16a0d03698bfc9f93250490797f9a1a870f8bcfe,1,Auto merge of #97521 - SkiFire13:clarify-vec-as-ptr r=Dylan-DPC Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation Currently the documentation says they return a pointer to the vector's buffer which has the implied precondition that the vector allocated some memory. However `Vec`'s documentation also specifies that it won't always allocate so it's unclear whether the pointer returned is valid in that case. Of course you won't be able to read/write actual bytes to/from it since the capacity is 0 but there's an exception: zero sized read/writes. They are still valid as long as the pointer is not null and the memory it points to wasn't deallocated but `Vec::as_ptr` and `Vec::as_mut_ptr` don't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads since `Vec` is implemented to hold a dangling pointer in those cases which is neither null nor was deallocated.,THUMBS_UP,2022-05-29T23:51:56Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97528,CLOSED,2022-05-29T18:46:59Z,2022-06-29T07:27:18Z,clone_from derive macro impl,conradludgate,NA,NA,NA,HEART,2022-05-29T20:12:17Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97545,MERGED,2022-05-30T08:07:57Z,2022-05-30T17:40:00Z,Reword safety comments in core/hash/sip.rs,thomcc,a352ad500de8ba7c8cc71fbbe81da00b44f33ac2,1,Rollup merge of #97545 - thomcc:sip-comment-safety r=Dylan-DPC Reword safety comments in core/hash/sip.rs In https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Is.20there.20any.20way.20to.20soundly.20do.20a.20masked.20out-of-bounds.20read.3F/near/284329248 it came up that this is using an atypical (and somewhat vague) phrasing of the safety requirement so this slightly rewords it.,HEART,2022-05-30T10:58:48Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97570,MERGED,2022-05-30T23:31:08Z,2022-05-31T20:40:32Z,Fix TLS access mir opt test and remove stale files,JakobDegen,0595ea1d12cf745e0a672d05341429ecb0917e66,7,Auto merge of #97570 - JakobDegen:dse-test r=tmiasko Fix TLS access mir opt test and remove stale files Thanks `@pietroalbini` for noticing that the TLS test was not doing what it was supposed to. Switched to `PreCodegen` because `SimplifyCfg` does not run on opt level 0. Also addresses the easy part of #97564 . r? rust-lang/mir-opt,HEART,2022-05-31T07:19:21Z,pietroalbini,pietro@pietroalbini.org https://github.com/rust-lang/rust/pull/97571,OPEN,2022-05-31T00:12:11Z,NA,Add documentation on v0 symbol mangling.,ehuss,NA,NA,NA,HEART,2022-06-03T08:31:33Z,lqd,NA https://github.com/rust-lang/rust/pull/97585,MERGED,2022-05-31T15:36:30Z,2022-07-02T19:46:01Z,CTFE interning: don't walk allocations that don't need it,lqd,750d6f85459356db4838dc06db8b19406e1ed31a,3,Auto merge of #97585 - lqd:const-alloc-intern r=RalfJung CTFE interning: don't walk allocations that don't need it The interning of const allocations visits the mplace looking for references to intern. Walking big aggregates like big static arrays can be costly so we only do it if the allocation we're interning contains references or interior mutability. Walking ZSTs was avoided before and this optimization is now applied to cases where there are no references/relocations either. --- While initially looking at this in the context of #93215 I've been testing with smaller allocations than the 16GB one in that issue and with different init/uninit patterns (esp. via padding). In that example by default `eval_to_allocation_raw` is the heaviest query followed by `incr_comp_serialize_result_cache`. So I'll show numbers when incremental compilation is disabled to focus on the const allocations themselves at 95% of the compilation time at bigger array sizes on these minimal examples like `static ARRAY: [u64; LEN] = [0; LEN];`. That is a close construction to parts of the `ctfe-stress-test-5` benchmark which has const allocations in the megabytes while most crates usually have way smaller ones. This PR will have the most impact in these situations as the walk during the interning starts to dominate the runtime. Unicode crates (some of which are present in our benchmarks) like `ucd` `encoding_rs` etc come to mind as having bigger than usual allocations as well because of big tables of code points (in the hundreds of KB so still an order of magnitude or 2 less than the stress test). In a check build for a single static array shown above from 100 to 10^9 u64s (for lengths in powers of ten) the constant factors are lowered: (log scales for easier comparisons) ![plot_log](https://user-images.githubusercontent.com/247183/171422958-16f1ea19-3ed4-4643-812c-1c7c60a97e19.png) (linear scale for absolute diff at higher Ns) ![plot_linear](https://user-images.githubusercontent.com/247183/171401886-2a869a4d-5cd5-47d3-9a5f-8ce34b7a6917.png) For one of the alternatives of that issue ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[u128; COLS]; ROWS] = [[0; COLS]; ROWS]; ``` we can see a similar reduction of around 3x (from 38s to 12s or so). For the same size the slowest case IIRC is when there are uninitialized bytes e.g. via padding ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[(u64 u8); COLS]; ROWS] = [[(0 0); COLS]; ROWS]; ``` then interning/walking does not dominate anymore (but means there is likely still some interesting work left to do here). Compile times in this case rise up quite a bit and avoiding interning walks has less impact: around 23% from 730s on master to 568s with this PR.,HEART,2022-05-31T15:37:03Z,oli-obk,NA https://github.com/rust-lang/rust/pull/97585,MERGED,2022-05-31T15:36:30Z,2022-07-02T19:46:01Z,CTFE interning: don't walk allocations that don't need it,lqd,750d6f85459356db4838dc06db8b19406e1ed31a,3,Auto merge of #97585 - lqd:const-alloc-intern r=RalfJung CTFE interning: don't walk allocations that don't need it The interning of const allocations visits the mplace looking for references to intern. Walking big aggregates like big static arrays can be costly so we only do it if the allocation we're interning contains references or interior mutability. Walking ZSTs was avoided before and this optimization is now applied to cases where there are no references/relocations either. --- While initially looking at this in the context of #93215 I've been testing with smaller allocations than the 16GB one in that issue and with different init/uninit patterns (esp. via padding). In that example by default `eval_to_allocation_raw` is the heaviest query followed by `incr_comp_serialize_result_cache`. So I'll show numbers when incremental compilation is disabled to focus on the const allocations themselves at 95% of the compilation time at bigger array sizes on these minimal examples like `static ARRAY: [u64; LEN] = [0; LEN];`. That is a close construction to parts of the `ctfe-stress-test-5` benchmark which has const allocations in the megabytes while most crates usually have way smaller ones. This PR will have the most impact in these situations as the walk during the interning starts to dominate the runtime. Unicode crates (some of which are present in our benchmarks) like `ucd` `encoding_rs` etc come to mind as having bigger than usual allocations as well because of big tables of code points (in the hundreds of KB so still an order of magnitude or 2 less than the stress test). In a check build for a single static array shown above from 100 to 10^9 u64s (for lengths in powers of ten) the constant factors are lowered: (log scales for easier comparisons) ![plot_log](https://user-images.githubusercontent.com/247183/171422958-16f1ea19-3ed4-4643-812c-1c7c60a97e19.png) (linear scale for absolute diff at higher Ns) ![plot_linear](https://user-images.githubusercontent.com/247183/171401886-2a869a4d-5cd5-47d3-9a5f-8ce34b7a6917.png) For one of the alternatives of that issue ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[u128; COLS]; ROWS] = [[0; COLS]; ROWS]; ``` we can see a similar reduction of around 3x (from 38s to 12s or so). For the same size the slowest case IIRC is when there are uninitialized bytes e.g. via padding ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[(u64 u8); COLS]; ROWS] = [[(0 0); COLS]; ROWS]; ``` then interning/walking does not dominate anymore (but means there is likely still some interesting work left to do here). Compile times in this case rise up quite a bit and avoiding interning walks has less impact: around 23% from 730s on master to 568s with this PR.,HEART,2022-06-01T17:00:53Z,estebank,NA https://github.com/rust-lang/rust/pull/97585,MERGED,2022-05-31T15:36:30Z,2022-07-02T19:46:01Z,CTFE interning: don't walk allocations that don't need it,lqd,750d6f85459356db4838dc06db8b19406e1ed31a,3,Auto merge of #97585 - lqd:const-alloc-intern r=RalfJung CTFE interning: don't walk allocations that don't need it The interning of const allocations visits the mplace looking for references to intern. Walking big aggregates like big static arrays can be costly so we only do it if the allocation we're interning contains references or interior mutability. Walking ZSTs was avoided before and this optimization is now applied to cases where there are no references/relocations either. --- While initially looking at this in the context of #93215 I've been testing with smaller allocations than the 16GB one in that issue and with different init/uninit patterns (esp. via padding). In that example by default `eval_to_allocation_raw` is the heaviest query followed by `incr_comp_serialize_result_cache`. So I'll show numbers when incremental compilation is disabled to focus on the const allocations themselves at 95% of the compilation time at bigger array sizes on these minimal examples like `static ARRAY: [u64; LEN] = [0; LEN];`. That is a close construction to parts of the `ctfe-stress-test-5` benchmark which has const allocations in the megabytes while most crates usually have way smaller ones. This PR will have the most impact in these situations as the walk during the interning starts to dominate the runtime. Unicode crates (some of which are present in our benchmarks) like `ucd` `encoding_rs` etc come to mind as having bigger than usual allocations as well because of big tables of code points (in the hundreds of KB so still an order of magnitude or 2 less than the stress test). In a check build for a single static array shown above from 100 to 10^9 u64s (for lengths in powers of ten) the constant factors are lowered: (log scales for easier comparisons) ![plot_log](https://user-images.githubusercontent.com/247183/171422958-16f1ea19-3ed4-4643-812c-1c7c60a97e19.png) (linear scale for absolute diff at higher Ns) ![plot_linear](https://user-images.githubusercontent.com/247183/171401886-2a869a4d-5cd5-47d3-9a5f-8ce34b7a6917.png) For one of the alternatives of that issue ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[u128; COLS]; ROWS] = [[0; COLS]; ROWS]; ``` we can see a similar reduction of around 3x (from 38s to 12s or so). For the same size the slowest case IIRC is when there are uninitialized bytes e.g. via padding ```rust const ROWS: usize = 100_000; const COLS: usize = 10_000; static TWODARRAY: [[(u64 u8); COLS]; ROWS] = [[(0 0); COLS]; ROWS]; ``` then interning/walking does not dominate anymore (but means there is likely still some interesting work left to do here). Compile times in this case rise up quite a bit and avoiding interning walks has less impact: around 23% from 730s on master to 568s with this PR.,HEART,2022-06-02T11:28:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97594,OPEN,2022-05-31T18:44:21Z,NA,Implement tuple<->array convertions via `From`,WaffleLapkin,NA,NA,NA,HEART,2022-05-31T19:28:07Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97598,MERGED,2022-05-31T20:41:51Z,2022-06-03T00:21:29Z,Simplify universal impl trait lowering,spastorino,42bcd41d4dfeb44360113ab78bc469e2813af952,3,Auto merge of #97598 - spastorino:simplify-universal-impl-trait-lowering r=cjgillot Simplify universal impl trait lowering Closes #96644 r? `@cjgillot`,HOORAY,2022-06-01T06:58:37Z,lqd,NA https://github.com/rust-lang/rust/pull/97598,MERGED,2022-05-31T20:41:51Z,2022-06-03T00:21:29Z,Simplify universal impl trait lowering,spastorino,42bcd41d4dfeb44360113ab78bc469e2813af952,3,Auto merge of #97598 - spastorino:simplify-universal-impl-trait-lowering r=cjgillot Simplify universal impl trait lowering Closes #96644 r? `@cjgillot`,HOORAY,2022-06-01T11:30:21Z,cjgillot,NA https://github.com/rust-lang/rust/pull/97598,MERGED,2022-05-31T20:41:51Z,2022-06-03T00:21:29Z,Simplify universal impl trait lowering,spastorino,42bcd41d4dfeb44360113ab78bc469e2813af952,3,Auto merge of #97598 - spastorino:simplify-universal-impl-trait-lowering r=cjgillot Simplify universal impl trait lowering Closes #96644 r? `@cjgillot`,HOORAY,2022-06-02T11:33:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97605,MERGED,2022-05-31T23:41:06Z,2022-06-02T00:55:49Z,Mention filename in suggestion when it differs from primary span,estebank,2c1990d0b8b121f79bcbabb810f86be3e9d8d7cc,7,Rollup merge of #97605 - estebank:suggestion-filename r=oli-obk Mention filename in suggestion when it differs from primary span,HEART,2022-06-01T01:13:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_UP,2022-06-01T18:05:18Z,maxliu42,maxliu42@gmail.com https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_UP,2022-06-01T18:31:35Z,manishbhatt,NA https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_DOWN,2022-06-01T19:22:02Z,the8472,NA https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_DOWN,2022-06-02T00:03:01Z,arniu,NA https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_DOWN,2022-06-02T04:50:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/97620,CLOSED,2022-06-01T13:12:26Z,2022-06-02T17:59:52Z,Add `is_even` and `is_odd` methods on `int_impl` and `uint_impl`.,vidhanio,NA,NA,NA,THUMBS_DOWN,2022-06-21T15:37:45Z,Rapptz,NA https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,EYES,2022-06-01T20:09:49Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,EYES,2022-06-01T20:30:42Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,EYES,2022-06-02T04:15:22Z,yvt,i@yvt.jp https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,THUMBS_UP,2022-06-02T10:56:51Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,THUMBS_UP,2022-06-08T13:07:16Z,danielkeller,NA https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,THUMBS_UP,2022-06-15T07:12:30Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/97629,MERGED,2022-06-01T19:23:08Z,2022-07-01T13:55:30Z,[core] add `Exclusive` to sync,guswynn,0e71d1f23766cb78570ce71837e11f25dbd099be,4,Rollup merge of #97629 - guswynn:exclusive_struct r=m-ou-se [core] add `Exclusive` to sync (discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std) `Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex and hold an unconditional `Sync` implementation. ## Justification for inclusion into std - This wrapper unblocks actual problems: - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it you either write really difficult code or wrap the futures in a needless mutex. - Easy to maintain: this struct is as simple as a wrapper can get and its `Sync` implementation has very clear reasoning - Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex` ## Public Api ```rust // core::sync #[derive(Default)] struct Exclusive { ... } impl Sync for Exclusive {} impl Exclusive { pub const fn new(t: T) -> Self; pub const fn into_inner(self) -> T; } impl Exclusive { pub const fn get_mut(&mut self) -> &mut T; pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>; pub const fn from_mut(&mut T) -> &mut Exclusive; pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive>; } impl Future for Exclusive { ... } impl From for Exclusive { ... } impl Debug for Exclusive { ... } ``` ## Naming This is a big bikeshed but I felt that `Exclusive` captured its general purpose quite well. ## Stability and location As this is so simple it can be in `core`. I feel that it can be stabilized quite soon after it is merged if the libs teams feels its reasonable to add. Also I don't really know how unstable feature work in std/core's codebases so I might need help fixing them ## Tips for review The docs probably are the thing that needs to be reviewed! I tried my best but I'm sure people have more experience than me writing docs for `Core` ### Implementation: The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed) and the implementation is trivial: - its an unsafe justification for pinning - its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2) - and forwarding impls starting with derivable ones and `Future`,THUMBS_UP,2022-06-23T11:28:24Z,c410-f3r,c410.f3r@gmail.com https://github.com/rust-lang/rust/pull/97631,MERGED,2022-06-01T20:46:58Z,2022-06-02T04:14:02Z,[beta] Beta backports,ehuss,a5cf77ca62e98a8d7f299a91d3c6c4787fb19988,9,Auto merge of #97631 - ehuss:update-beta-cargo r=ehuss [beta] Beta backports * Allow the unused_macro_rules lint for now #97032 * Fix some typos in arg checking algorithm #97303 * rustc: Fix ICE in native library error reporting #97328 * Cargo: * Fix `cargo publish -p spec` https://github.com/rust-lang/cargo/pull/10707,HEART,2022-06-01T22:51:17Z,est31,NA https://github.com/rust-lang/rust/pull/97640,MERGED,2022-06-02T07:26:49Z,2022-06-03T03:04:56Z,Fix wrong suggestion for adding where clauses,TaKO8Ki,0e33e97fc742315bf8dd6a3bc2f3616935f73e68,3,Rollup merge of #97640 - TaKO8Ki:fix-wrong-suggestion-for-adding-where-clauses r=lcnr Fix wrong suggestion for adding where clauses closes #97576,HEART,2022-06-02T17:16:50Z,estebank,NA https://github.com/rust-lang/rust/pull/97640,MERGED,2022-06-02T07:26:49Z,2022-06-03T03:04:56Z,Fix wrong suggestion for adding where clauses,TaKO8Ki,0e33e97fc742315bf8dd6a3bc2f3616935f73e68,3,Rollup merge of #97640 - TaKO8Ki:fix-wrong-suggestion-for-adding-where-clauses r=lcnr Fix wrong suggestion for adding where clauses closes #97576,HEART,2022-06-03T06:01:49Z,Patryk27,pwychowaniec@pm.me https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-02T14:56:35Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-02T23:28:15Z,wezm,wes@wezm.net https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-04T01:39:20Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-09T08:51:56Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-09T09:51:08Z,matthieu-m,NA https://github.com/rust-lang/rust/pull/97647,MERGED,2022-06-02T10:38:50Z,2022-06-04T13:46:56Z,Lazily allocate and initialize pthread locks.,m-ou-se,e9ec02267a0b84d6a17357c1a0da46093ba5ad1d,29,Rollup merge of #97647 - m-ou-se:lazy-box-locks r=Amanieu Lazily allocate and initialize pthread locks. Lazily allocate and initialize pthread locks. This allows {Mutex Condvar RwLock}::new() to be const while still using the platform's native locks for features like priority inheritance and debug tooling. E.g. on macOS we cannot directly use the (private) APIs that pthread's locks are implemented with making it impossible for us to use anything other than pthread while still preserving priority inheritance etc. This PR doesn't yet make the public APIs const. That's for a separate PR with an FCP. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T21:05:26Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97658,OPEN,2022-06-02T17:49:45Z,NA,Stabilize `format_args_ln!`,joshtriplett,NA,NA,NA,THUMBS_UP,2022-06-03T10:09:21Z,VictorKoenders,github@trangar.com https://github.com/rust-lang/rust/pull/97665,MERGED,2022-06-02T19:41:08Z,2022-06-15T20:28:40Z,[RFC 2011] Minimal initial implementation,c410-f3r,ca983054e19afd74d63c3ed37997f3bf30fe85d0,17,Auto merge of #97665 - c410-f3r:assert-compiler r=oli-obk [RFC 2011] Minimal initial implementation Tracking issue: #44838 Third step of #96496 Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do. r? `@oli-obk`,THUMBS_UP,2022-06-16T08:19:22Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/97665,MERGED,2022-06-02T19:41:08Z,2022-06-15T20:28:40Z,[RFC 2011] Minimal initial implementation,c410-f3r,ca983054e19afd74d63c3ed37997f3bf30fe85d0,17,Auto merge of #97665 - c410-f3r:assert-compiler r=oli-obk [RFC 2011] Minimal initial implementation Tracking issue: #44838 Third step of #96496 Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do. r? `@oli-obk`,HOORAY,2022-07-07T22:48:23Z,sunfishcode,NA https://github.com/rust-lang/rust/pull/97675,MERGED,2022-06-03T07:31:00Z,2022-06-17T02:32:28Z,Make `std::mem::needs_drop` accept `?Sized`,nvzqz,cf68fd7e8d3cf3d075208d9a09aa509eeb87b4ee,6,Rollup merge of #97675 - nvzqz:unsized-needs-drop r=dtolnay Make `std::mem::needs_drop` accept `?Sized` This change attempts to make `needs_drop` work with types like `[u8]` and `str`. This enables code in types like `Arc` that was not possible before such as https://github.com/rust-lang/rust/pull/97676.,THUMBS_UP,2022-06-11T08:09:17Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/97676,CLOSED,2022-06-03T07:34:22Z,2022-06-23T20:22:27Z,Inline `Arc` and `Rc` dealloc for `T: !Drop`,nvzqz,NA,NA,NA,THUMBS_UP,2022-06-11T08:12:29Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/97684,MERGED,2022-06-03T11:47:11Z,2022-06-06T16:09:57Z,interpret: better control over whether we read data with provenance,RalfJung,9d20fd109809f20c049d6895a5be27a1fbd39daa,22,Auto merge of #97684 - RalfJung:better-provenance-control r=oli-obk interpret: better control over whether we read data with provenance The resolution in https://github.com/rust-lang/unsafe-code-guidelines/issues/286 seems to be that when we load data at integer type we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly but so far that does not seem to happen. This does not entirely implement the solution to https://github.com/rust-lang/unsafe-code-guidelines/issues/286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve https://github.com/rust-lang/miri/issues/845 since we can reset padding to `Uninit`). The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer and actually get the desired behavior of stripping provenance without exposing it!,HEART,2022-06-04T11:34:17Z,scottmcm,NA https://github.com/rust-lang/rust/pull/97684,MERGED,2022-06-03T11:47:11Z,2022-06-06T16:09:57Z,interpret: better control over whether we read data with provenance,RalfJung,9d20fd109809f20c049d6895a5be27a1fbd39daa,22,Auto merge of #97684 - RalfJung:better-provenance-control r=oli-obk interpret: better control over whether we read data with provenance The resolution in https://github.com/rust-lang/unsafe-code-guidelines/issues/286 seems to be that when we load data at integer type we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly but so far that does not seem to happen. This does not entirely implement the solution to https://github.com/rust-lang/unsafe-code-guidelines/issues/286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve https://github.com/rust-lang/miri/issues/845 since we can reset padding to `Uninit`). The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer and actually get the desired behavior of stripping provenance without exposing it!,HEART,2022-06-09T21:01:05Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97697,MERGED,2022-06-03T16:47:40Z,2022-06-05T11:53:32Z,Replace `&Vec<_>`s with `&[_]`s,WaffleLapkin,4322a785cc99ea5fc81dd7f5fc8ba7f7a64b08ef,14,Auto merge of #97697 - WaffleLapkin:no_ref_vec r=WaffleLapkin Replace `&Vec<_>`s with `&[_]`s It's generally preferable to use `&[_]` since it's one less indirection and it can be created from types other that `Vec`. I've left `&Vec` in some locals where it doesn't really matter in cases where `TypeFoldable` is expected (`TypeFoldable: Clone` so slice can't implement it) and in cases where it's `&TypeAliasThatIsActiallyVec`. Nothing important really I was just a little annoyed by `visit_generic_param_vec` :D r? `@compiler-errors`,HOORAY,2022-06-04T14:11:13Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/97712,MERGED,2022-06-03T21:19:56Z,2022-07-05T14:58:42Z,ptr::copy and ptr::swap are doing untyped copies,RalfJung,8fa1ed8f123f2714a7796c03d7d634b046bdaed2,3,"Rollup merge of #97712 - RalfJung:untyped r=scottmcm ptr::copy and ptr::swap are doing untyped copies The consensus in https://github.com/rust-lang/rust/issues/63159 seemed to be that these operations should be ""untyped"" i.e. they should treat the data as raw bytes should work when these bytes violate the validity invariant of `T` and should exactly preserve the initialization state of the bytes that are being copied. This is already somewhat implied by the description of ""copying/swapping size*N bytes"" (rather than ""N instances of `T`""). The implementations mostly already work that way (well for LLVM's intrinsics the documentation is not precise enough to say what exactly happens to poison but if this ever gets clarified to something that would *not* perfectly preserve poison then I strongly assume there will be some way to make a copy that *does* perfectly preserve poison). However I had to adjust `swap_nonoverlapping`; after ``@scottmcm's`` [recent changes](https://github.com/rust-lang/rust/pull/94212) that one (sometimes) made a typed copy. (Note that `mem::swap` which works on mutable references is unchanged. It is documented as ""swapping the values at two mutable locations"" which to me strongly indicates that it is indeed typed. It is also safe and can rely on `&mut T` pointing to a valid `T` as part of its safety invariant.) On top of adding a test (that will be run by Miri) this PR then also adjusts the documentation to indeed stably promise the untyped semantics. I assume this means the PR has to go through t-libs (and maybe t-lang?) FCP. Fixes https://github.com/rust-lang/rust/issues/63159",THUMBS_UP,2022-06-03T22:46:54Z,scottmcm,NA https://github.com/rust-lang/rust/pull/97715,MERGED,2022-06-03T22:13:45Z,2022-06-04T13:46:57Z,Support the `#[expect]` attribute on fn parameters (RFC-2383),xFrednet,9c794b46cf56c6617d84fc264dc1784636fa71c3,8,Rollup merge of #97715 - xFrednet:97650-expect-in-fuction-arg r=wesleywiser Support the `#[expect]` attribute on fn parameters (RFC-2383) A small PR to allow the `#[expect]` attribute on function parameters. Nothing more to say I hope everyone reading this has a lovely day. --- r? ``@wesleywiser`` closes: https://github.com/rust-lang/rust/issues/97650 cc: https://github.com/rust-lang/rust/issues/85549,THUMBS_UP,2022-06-09T08:49:14Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97715,MERGED,2022-06-03T22:13:45Z,2022-06-04T13:46:57Z,Support the `#[expect]` attribute on fn parameters (RFC-2383),xFrednet,9c794b46cf56c6617d84fc264dc1784636fa71c3,8,Rollup merge of #97715 - xFrednet:97650-expect-in-fuction-arg r=wesleywiser Support the `#[expect]` attribute on fn parameters (RFC-2383) A small PR to allow the `#[expect]` attribute on function parameters. Nothing more to say I hope everyone reading this has a lovely day. --- r? ``@wesleywiser`` closes: https://github.com/rust-lang/rust/issues/97650 cc: https://github.com/rust-lang/rust/issues/85549,THUMBS_UP,2022-06-09T15:53:41Z,TennyZhuang,zty0826@gmail.com https://github.com/rust-lang/rust/pull/97716,MERGED,2022-06-03T22:25:00Z,2022-06-04T13:46:56Z,Fix reachability analysis for const methods,compiler-errors,9917f3816adce6089c90138eaf7d61213354e5fc,3,Rollup merge of #97716 - compiler-errors:issue-97708 r=wesleywiser Fix reachability analysis for const methods Use `method_might_be_inlined` directly for `ImplItemKind::Fn` instead of duplicating the logic in `def_id_represents_local_inlined_item`. This is parallel to how we use `item_might_be_inlined` for `ItemKind::Fn` in that same body. Fixes #97708,HEART,2022-06-04T11:15:45Z,jamesmunns,james@onevariable.com https://github.com/rust-lang/rust/pull/97716,MERGED,2022-06-03T22:25:00Z,2022-06-04T13:46:56Z,Fix reachability analysis for const methods,compiler-errors,9917f3816adce6089c90138eaf7d61213354e5fc,3,Rollup merge of #97716 - compiler-errors:issue-97708 r=wesleywiser Fix reachability analysis for const methods Use `method_might_be_inlined` directly for `ImplItemKind::Fn` instead of duplicating the logic in `def_id_represents_local_inlined_item`. This is parallel to how we use `item_might_be_inlined` for `ItemKind::Fn` in that same body. Fixes #97708,HEART,2022-06-04T12:16:18Z,CGMossa,NA https://github.com/rust-lang/rust/pull/97716,MERGED,2022-06-03T22:25:00Z,2022-06-04T13:46:56Z,Fix reachability analysis for const methods,compiler-errors,9917f3816adce6089c90138eaf7d61213354e5fc,3,Rollup merge of #97716 - compiler-errors:issue-97708 r=wesleywiser Fix reachability analysis for const methods Use `method_might_be_inlined` directly for `ImplItemKind::Fn` instead of duplicating the logic in `def_id_represents_local_inlined_item`. This is parallel to how we use `item_might_be_inlined` for `ItemKind::Fn` in that same body. Fixes #97708,HEART,2022-06-04T20:25:05Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97720,OPEN,2022-06-03T23:36:04Z,NA,Always create elided lifetime parameters for functions,cjgillot,NA,NA,NA,HEART,2022-06-12T15:17:49Z,est31,NA https://github.com/rust-lang/rust/pull/97720,OPEN,2022-06-03T23:36:04Z,NA,Always create elided lifetime parameters for functions,cjgillot,NA,NA,NA,HEART,2022-06-15T23:03:57Z,estebank,NA https://github.com/rust-lang/rust/pull/97722,MERGED,2022-06-04T02:18:19Z,2022-06-04T13:46:56Z,Tighten spans for bad fields in struct deriving `Copy`,compiler-errors,8c4c698efb7d396d5821c0328366c709461c2fe9,5,Rollup merge of #97722 - compiler-errors:tighten-copy-type-error-spans r=Dylan-DPC Tighten spans for bad fields in struct deriving `Copy` r? `@estebank` Closes #89137 for good I think Not sure if this is what you were looking for in https://github.com/rust-lang/rust/issues/89137#issuecomment-1146201791,THUMBS_UP,2022-06-06T19:22:48Z,estebank,NA https://github.com/rust-lang/rust/pull/97737,MERGED,2022-06-04T18:32:48Z,2022-06-05T01:34:59Z,Fix pretty printing named bound regions under -Zverbose,jackh726,1794309e0aa451e63d74511d4af595a5bcd0f685,1,Rollup merge of #97737 - jackh726:verbose-pretty-printing-fix r=compiler-errors Fix pretty printing named bound regions under -Zverbose Fixed regression introduced in #97023 r? `@compiler-errors` cc `@cjgillot`,HEART,2022-06-04T18:33:44Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97738,MERGED,2022-06-04T18:36:24Z,2022-06-07T13:50:59Z,Fix ICEs from zsts within unsized types with non-zero offsets,Kixiron,62c260de8c621f577d33970613c6b611e2de7d8e,2,Rollup merge of #97738 - Kixiron:zst-panic r=eddyb Fix ICEs from zsts within unsized types with non-zero offsets - Fixes #97732 - Fixes ICEs while compiling `alloc` with `-Z randomize-layout` r? ``@eddyb``,THUMBS_UP,2022-06-05T05:21:27Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97738,MERGED,2022-06-04T18:36:24Z,2022-06-07T13:50:59Z,Fix ICEs from zsts within unsized types with non-zero offsets,Kixiron,62c260de8c621f577d33970613c6b611e2de7d8e,2,Rollup merge of #97738 - Kixiron:zst-panic r=eddyb Fix ICEs from zsts within unsized types with non-zero offsets - Fixes #97732 - Fixes ICEs while compiling `alloc` with `-Z randomize-layout` r? ``@eddyb``,HEART,2022-06-07T13:03:49Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/97739,OPEN,2022-06-04T18:53:36Z,NA,Uplift the `let_underscore` lints from clippy into rustc.,a2aaron,NA,NA,NA,HEART,2022-06-10T17:04:14Z,estebank,NA https://github.com/rust-lang/rust/pull/97739,OPEN,2022-06-04T18:53:36Z,NA,Uplift the `let_underscore` lints from clippy into rustc.,a2aaron,NA,NA,NA,HEART,2022-06-14T05:14:34Z,rrbutani,NA https://github.com/rust-lang/rust/pull/97740,MERGED,2022-06-04T19:54:53Z,2022-06-09T04:33:03Z,use precise spans for recursive const evaluation,RalfJung,282445a288b3c409a998eb72e51827537e81abd3,12,Auto merge of #97740 - RalfJung:ctfe-cycle-spans r=lcnr use precise spans for recursive const evaluation This fixes https://github.com/rust-lang/rust/issues/73283 by using a `TyCtxtAt` with a more precise span when the interpreter recursively calls itself. Hopefully such calls are sufficiently rare that this does not cost us too much performance. (In theory cycles can also arise through layout computation as layout can depend on consts -- but layout computation happens all the time so we'd have to do something to not make this terrible for performance.),HEART,2022-06-04T20:54:08Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97756,MERGED,2022-06-05T10:33:59Z,2022-06-05T15:12:11Z,Remove Azure Pipelines configuration,pietroalbini,fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401,10,Auto merge of #97756 - pietroalbini:pa-remove-azure-pipelines r=Mark-Simulacrum Remove Azure Pipelines configuration This PR removes the remaining Azure Pipelines configuration now that we fully removed all the resources on the Azure side of things.,HOORAY,2022-06-05T13:35:48Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/97759,MERGED,2022-06-05T12:48:07Z,2022-06-06T10:43:38Z,Suggest adding `{}` for `'label: non_block_expr`,WaffleLapkin,554674b98cb5fdf2fd55620775d359b16423817c,5,Rollup merge of #97759 - WaffleLapkin:recover_label_expr r=compiler-errors Suggest adding `{}` for `'label: non_block_expr` Adds suggestions like this: ```text help: consider enclosing expression in a block | 3 | 'l {0}; | + + ``` inspired by https://github.com/rust-lang/rust/issues/48594#issuecomment-1146744400 r? ``@compiler-errors``,HEART,2022-06-08T23:54:18Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/97770,OPEN,2022-06-05T19:51:52Z,NA,Replace `owning_ref` with a safer datastructure,Nilstrieb,NA,NA,NA,THUMBS_UP,2022-06-05T21:09:25Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97778,MERGED,2022-06-06T04:49:32Z,2022-06-12T03:28:39Z,Tidy up miscellaneous bounds suggestions,compiler-errors,37a42258ffe02cfb7107380759e492c64500ab55,33,Auto merge of #97778 - compiler-errors:misc-diagnostics-tidy r=cjgillot Tidy up miscellaneous bounds suggestions Just some small fixes to suggestions - Generalizes `Ty::is_suggestable` into a `TypeVisitor` so that it can be called on things other than `Ty` - Makes `impl Trait` in arg position no longer suggestible (generalizing the fix in #97640) - Fixes `impl Trait` not being replaced with fresh type param when it's deeply nested in function signature (fixes #97760) - Fixes some poor handling of `where` clauses with no predicates (also #97760) - Uses `InferCtxt::resolve_numeric_literals_with_default` so we suggest `i32` instead of `{integer}` (fixes #97677) Sorry there aren't many tests the fixes. Most of them would just be duplicates of other tests with empty `where` clauses or `impl Trait` in arg position instead of generic params. Let me know if you'd want more test coverage.,HEART,2022-06-06T06:24:29Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/97789,MERGED,2022-06-06T09:57:35Z,2022-06-11T17:49:23Z,Fix #71363's test by adding `-Z translate-remapped-path-to-local-path=no`,pietroalbini,b7b5045364ab8835ca7642feb5cb931fc77d7f65,5,Rollup merge of #97789 - ferrocene:pa-fix-issue-71363-test r=cjgillot Fix #71363's test by adding `-Z translate-remapped-path-to-local-path=no` The test relies on `library/std/src/error.rs` not corresponding to a local path but remapping might still find the related local file of a remapped path. To fix the test this PR adds a new `-Z` flag to disable finding the corresponding local path of a remapped path.,HEART,2022-06-06T14:33:58Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T12:03:50Z,taiki-e,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T13:08:59Z,wwylele,wwylele@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T13:09:52Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T13:15:15Z,Folyd,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T13:38:38Z,darksv,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T14:22:16Z,BurntSushi,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T14:49:31Z,lcnr,rust@lcnr.de https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T15:00:20Z,bestgopher,84328409@qq.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:04:45Z,rtzoeller,rtzoeller@rtzoeller.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:24:06Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:24:40Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:33:02Z,xd009642,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:33:12Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-06T18:33:17Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:33:51Z,szbergeron,sawyerbergeron@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T18:57:18Z,ibraheemdev,ibraheem@ibraheem.ca https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T19:01:45Z,Lokathor,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-06T19:01:46Z,Lokathor,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T20:15:15Z,CryZe,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-06T20:15:15Z,CryZe,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T21:25:00Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-06T21:25:01Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-06T23:46:06Z,mati865,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-06T23:46:13Z,mati865,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T01:32:18Z,saiksy,saiksydev@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-07T01:32:19Z,saiksy,saiksydev@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T08:09:50Z,Thomasdezeeuw,thomasdezeeuw@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T08:58:27Z,jplatte,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T14:29:02Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-07T14:58:10Z,akiross,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T15:44:28Z,U007D,b2b@humanenginuity.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T16:17:39Z,fbstj,joe@fbstj.net https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-07T17:49:27Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-08T23:20:15Z,Kogia-sima,orcinus4627@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T06:48:25Z,songzhi,lsongzhi@163.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T07:45:13Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T08:22:15Z,surban,surban@surban.net https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T13:11:00Z,Nadrieril,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T13:14:32Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T15:33:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T16:04:50Z,tux3,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-09T16:04:51Z,tux3,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T19:15:42Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-09T19:15:43Z,IndigoLily,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T21:11:31Z,ChayimFriedman2,chayimfr@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-09T22:34:45Z,sersorrel,ash@sorrel.sh https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-10T01:01:00Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-10T03:11:34Z,rodrimati1992,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-10T09:01:49Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-10T09:01:50Z,kellerkindt,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-11T07:33:33Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-12T10:49:49Z,a1phyr,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-15T06:23:12Z,stepancheg,stepan.koltsov@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-15T07:58:40Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-15T07:58:41Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-15T07:58:41Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-16T16:35:16Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-19T16:11:50Z,Cassy343,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-19T16:11:50Z,Cassy343,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-19T16:11:51Z,Cassy343,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,THUMBS_UP,2022-06-19T17:07:02Z,up-to-you,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-19T17:07:02Z,up-to-you,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-19T17:07:07Z,up-to-you,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-19T18:05:11Z,5225225,5225225@mailbox.org https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HEART,2022-06-23T15:00:06Z,Rexagon,reide740@gmail.com https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-29T06:31:15Z,Amex1048,NA https://github.com/rust-lang/rust/pull/97791,MERGED,2022-06-06T12:02:26Z,2022-06-19T12:28:59Z,Make {Mutex Condvar RwLock}::new() const.,m-ou-se,15fc228d0d0a68b5ba565758fab13ed7f863fcea,15,Auto merge of #97791 - m-ou-se:const-locks r=m-ou-se Make {Mutex Condvar RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035) [on Windows](https://github.com/rust-lang/rust/pull/77380) and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647 the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740,HOORAY,2022-06-30T18:56:01Z,Nemikolh,NA https://github.com/rust-lang/rust/pull/97798,MERGED,2022-06-06T15:37:58Z,2022-06-17T15:10:02Z,Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown,WaffleLapkin,74aa55b3fcae638ce3df9111ef7822474f9a2b61,23,"Rollup merge of #97798 - WaffleLapkin:allow_for_suggestions_that_are_quite_far_away_from_each_other r=estebank Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed ""the problem"" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230. I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so) but I want to at least discuss the result. Here is an example of how this changes the output: Before: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | 5 | 6 | 7 | 8 | ... ``` After: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | ... 31| 32~ } }; | ``` r? `@estebank` `@rustbot` label +A-diagnostics +A-suggestion-diagnostics",HEART,2022-06-06T19:34:00Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97798,MERGED,2022-06-06T15:37:58Z,2022-06-17T15:10:02Z,Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown,WaffleLapkin,74aa55b3fcae638ce3df9111ef7822474f9a2b61,23,"Rollup merge of #97798 - WaffleLapkin:allow_for_suggestions_that_are_quite_far_away_from_each_other r=estebank Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed ""the problem"" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230. I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so) but I want to at least discuss the result. Here is an example of how this changes the output: Before: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | 5 | 6 | 7 | 8 | ... ``` After: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | ... 31| 32~ } }; | ``` r? `@estebank` `@rustbot` label +A-diagnostics +A-suggestion-diagnostics",HEART,2022-06-06T19:38:54Z,estebank,NA https://github.com/rust-lang/rust/pull/97798,MERGED,2022-06-06T15:37:58Z,2022-06-17T15:10:02Z,Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown,WaffleLapkin,74aa55b3fcae638ce3df9111ef7822474f9a2b61,23,"Rollup merge of #97798 - WaffleLapkin:allow_for_suggestions_that_are_quite_far_away_from_each_other r=estebank Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed ""the problem"" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230. I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so) but I want to at least discuss the result. Here is an example of how this changes the output: Before: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | 5 | 6 | 7 | 8 | ... ``` After: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l 4 | ... 31| 32~ } }; | ``` r? `@estebank` `@rustbot` label +A-diagnostics +A-suggestion-diagnostics",HEART,2022-06-20T07:02:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97802,OPEN,2022-06-06T18:22:43Z,NA,"Support `#[unix_sigpipe = ""inherit|sig_dfl""]` on `fn main()` to prevent ignoring `SIGPIPE`",Enselic,NA,NA,NA,THUMBS_UP,2022-06-06T19:00:45Z,HarrisonMc555,NA https://github.com/rust-lang/rust/pull/97802,OPEN,2022-06-06T18:22:43Z,NA,"Support `#[unix_sigpipe = ""inherit|sig_dfl""]` on `fn main()` to prevent ignoring `SIGPIPE`",Enselic,NA,NA,NA,THUMBS_UP,2022-06-07T04:25:25Z,wchargin,NA https://github.com/rust-lang/rust/pull/97802,OPEN,2022-06-06T18:22:43Z,NA,"Support `#[unix_sigpipe = ""inherit|sig_dfl""]` on `fn main()` to prevent ignoring `SIGPIPE`",Enselic,NA,NA,NA,THUMBS_UP,2022-06-12T10:06:24Z,yerke,NA https://github.com/rust-lang/rust/pull/97805,MERGED,2022-06-06T19:51:16Z,2022-06-21T16:24:58Z,Add proper tracing spans to rustc_trait_selection::traits::error_reporting,coolreader18,9c800ec4e97ec92c5b9b2ae2bd3f2aeeb4146df6,2,Rollup merge of #97805 - coolreader18:trace-suggestions r=oli-obk Add proper tracing spans to rustc_trait_selection::traits::error_reporting While I was trying to figure out #97704 I did some of this to make the logs more legible so I figured I'd do the whole module and open a PR with it. afaict this is an ongoing process in the compiler from the log->tracing transition? but lmk if there was a reason for the more verbose forms of logging as they are. Also for some of the functions with only one log in them I put the function name as a message for that log instead of `#[instrument]`-ing the whole function with a span? but maybe the latter would actually be preferable I'm not actually sure.,HEART,2022-06-06T21:51:12Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97816,OPEN,2022-06-07T04:30:07Z,NA,Windows: Run `compat_fn` init before C++ init,ChrisDenton,NA,NA,NA,THUMBS_UP,2022-07-04T19:25:57Z,x87,NA https://github.com/rust-lang/rust/pull/97819,MERGED,2022-06-07T07:21:10Z,2022-06-08T10:24:16Z,Recover `import` instead of `use` in item,compiler-errors,a64a9829c88d7353ff16c4e59835364b70118246,4,Rollup merge of #97819 - compiler-errors:use-import r=wesleywiser Recover `import` instead of `use` in item When we definitely don't have a macro invocation (i.e. when we don't have `import ::`) then it's more productive to parse `import` as if it was incorrectly mistaken for `use`. Not sure if this needs to be a verbose suggestion but it renders strangely when it's not verbose: ``` error: expected item found `import` --> /home/michael/test.rs:1:1 | 1 | import std::{io::{self Write} rc::Rc}; | ^^^^^^ help: items are imported using the `use` keyword: `use` ``` Happy to change it to `span_suggestion` instead of `span_suggestion_verbose` though. Fixes #97788,HEART,2022-06-08T12:39:12Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HEART,2022-06-07T19:18:39Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HEART,2022-06-07T19:54:27Z,evanrichter,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HEART,2022-06-07T20:21:38Z,yerke,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,ROCKET,2022-06-07T20:22:47Z,yerke,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HOORAY,2022-06-07T20:22:49Z,yerke,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-07T20:22:52Z,yerke,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,ROCKET,2022-06-07T20:48:17Z,bnjbvr,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-07T21:47:48Z,CraftSpider,runetynan@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HEART,2022-06-08T15:40:54Z,zohnannor,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HOORAY,2022-06-08T15:40:54Z,zohnannor,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-08T15:40:54Z,zohnannor,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,ROCKET,2022-06-08T15:40:54Z,zohnannor,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-08T18:10:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HOORAY,2022-06-08T18:10:03Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,HEART,2022-06-08T18:10:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,ROCKET,2022-06-08T18:10:04Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-09T04:20:52Z,mfrw,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-09T14:35:14Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-10T14:29:42Z,Bromeon,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-13T03:29:18Z,charlesrocket,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-16T07:42:47Z,clarfonthey,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-16T17:59:05Z,jplatte,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-17T17:45:54Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-20T16:53:10Z,DianaNites,NA https://github.com/rust-lang/rust/pull/97837,MERGED,2022-06-07T16:41:31Z,2022-06-20T17:01:53Z,Document Rust's stance on `/proc/self/mem`,sunfishcode,ce1151c04c8aa529a81d124d41cc900c7da7d4ac,1,Rollup merge of #97837 - sunfishcode:sunfishcode/proc-self-mem r=m-ou-se Document Rust's stance on `/proc/self/mem` Add documentation to `std::os::unix::io` describing Rust's stance on `/proc/self/mem` treating it as an external entity which is outside the scope of Rust's safety guarantees.,THUMBS_UP,2022-06-23T14:00:06Z,flamion,NA https://github.com/rust-lang/rust/pull/97842,MERGED,2022-06-07T19:23:33Z,2022-06-16T13:54:30Z,Improve the tuple and unit trait docs,notriddle,6ec3993ef4a4eb72bc20477fe9a4d92acd53f2c6,22,Auto merge of #97842 - notriddle:notriddle/tuple-docs r=jsha GuillaumeGomez Improve the tuple and unit trait docs * Reduce duplicate impls; show only the `(T )` and include a sentence saying that there exists ones up to twelve of them. * Show `Copy` and `Clone`. * Show auto traits like `Send` and `Sync` and blanket impls like `Any`. Here's the new version: * * ,HEART,2022-06-07T20:34:24Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97853,MERGED,2022-06-08T01:12:54Z,2022-06-22T05:32:41Z,Collapse multiple dead code warnings into a single diagnostic,TaKO8Ki,3d829a0922d865d7a77fb284424fd8ba6afaea3b,76,Auto merge of #97853 - TaKO8Ki:emit-only-one-note-per-unused-struct-field r=estebank Collapse multiple dead code warnings into a single diagnostic closes #97643,HEART,2022-06-15T18:17:32Z,estebank,NA https://github.com/rust-lang/rust/pull/97853,MERGED,2022-06-08T01:12:54Z,2022-06-22T05:32:41Z,Collapse multiple dead code warnings into a single diagnostic,TaKO8Ki,3d829a0922d865d7a77fb284424fd8ba6afaea3b,76,Auto merge of #97853 - TaKO8Ki:emit-only-one-note-per-unused-struct-field r=estebank Collapse multiple dead code warnings into a single diagnostic closes #97643,HEART,2022-06-22T05:54:51Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/97868,MERGED,2022-06-08T10:55:02Z,2022-06-09T12:58:30Z,BTreeSet: avoid intermediate sorting when collecting sorted iterators,ssomers,be16c6166f08f9b26d854783bbd4ce8d006c8f6f,1,Auto merge of #97868 - ssomers:btree_from_sorted_iter r=the8472 BTreeSet: avoid intermediate sorting when collecting sorted iterators As [pointed out by droundy](https://users.rust-lang.org/t/question-about-btreeset-implementation/76427) an obvious optimization is to skip the first step introduced by #88448 (creation of a vector and sorting) and it's easy to do so for btree's own iterators. Also exploit `from` in the examples.,THUMBS_UP,2022-06-09T02:23:28Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/97907,OPEN,2022-06-09T07:36:12Z,NA,impl Neg for NonZeroI*,iago-lito,NA,NA,NA,HEART,2022-06-18T02:21:39Z,GrayJack,NA https://github.com/rust-lang/rust/pull/97908,MERGED,2022-06-09T07:38:32Z,2022-06-26T21:28:32Z,Stabilize NonZero* checked operations constness.,iago-lito,e8a2e265b520e7bf72b4335a7d1185484366f0cf,1,Rollup merge of #97908 - iago-lito:stabilize_nonzero_checked_ops_constness r=scottmcm Stabilize NonZero* checked operations constness. Partial stabilization for #97547 (continued).,HEART,2022-06-18T02:21:45Z,GrayJack,NA https://github.com/rust-lang/rust/pull/97915,OPEN,2022-06-09T12:19:24Z,NA,Implement `fmt::Write` for `OsString`,tbu-,NA,NA,NA,HEART,2022-06-10T20:03:14Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/97915,OPEN,2022-06-09T12:19:24Z,NA,Implement `fmt::Write` for `OsString`,tbu-,NA,NA,NA,HEART,2022-06-12T07:52:32Z,ChrisDenton,NA https://github.com/rust-lang/rust/pull/97915,OPEN,2022-06-09T12:19:24Z,NA,Implement `fmt::Write` for `OsString`,tbu-,NA,NA,NA,HEART,2022-06-20T10:41:21Z,Xanewok,Xanewok@gmail.com https://github.com/rust-lang/rust/pull/97922,MERGED,2022-06-09T17:11:50Z,2022-06-10T11:50:49Z,Remove redundant calls to reserve in impl Write for VecDeque,paolobarbolini,3e5ddb73a8863c5f80243f8a709802cebb4af76f,1,Rollup merge of #97922 - paolobarbolini:no-vecdeque-extra-reserve r=the8472 Remove redundant calls to reserve in impl Write for VecDeque Removes the reserve calls made redundant by #95904 (as discussed in https://github.com/rust-lang/rust/pull/95632#discussion_r846850293),THUMBS_UP,2022-06-10T05:14:36Z,evanrichter,NA https://github.com/rust-lang/rust/pull/97925,OPEN,2022-06-09T19:04:13Z,NA,Add cgroupv1 support to available_parallelism,the8472,NA,NA,NA,HEART,2022-06-09T20:33:46Z,ehuss,NA https://github.com/rust-lang/rust/pull/97925,OPEN,2022-06-09T19:04:13Z,NA,Add cgroupv1 support to available_parallelism,the8472,NA,NA,NA,HEART,2022-06-09T22:41:54Z,weihanglo,NA https://github.com/rust-lang/rust/pull/97925,OPEN,2022-06-09T19:04:13Z,NA,Add cgroupv1 support to available_parallelism,the8472,NA,NA,NA,HEART,2022-06-23T07:54:46Z,inquisitivecrystal,NA https://github.com/rust-lang/rust/pull/97935,MERGED,2022-06-10T02:42:42Z,2022-06-14T13:37:36Z,Rename the `ConstS::val` field as `kind`.,nnethercote,9e5c5c57e97098b4d1e04a1215628ff6eb54986b,74,Rollup merge of #97935 - nnethercote:rename-ConstS-val-as-kind r=lcnr Rename the `ConstS::val` field as `kind`. And likewise for the `Const::val` method. Because its type is called `ConstKind`. Also `val` is a confusing name because `ConstKind` is an enum with seven variants one of which is called `Value`. Also this gives consistency with `TyS` and `PredicateS` which have `kind` fields. The commit also renames a few `Const` variables from `val` to `c` to avoid confusion with the `ConstKind::Value` variant. r? `@BoxyUwU`,THUMBS_UP,2022-06-10T18:45:40Z,RalfJung,NA https://github.com/rust-lang/rust/pull/97936,MERGED,2022-06-10T02:46:42Z,2022-06-16T23:50:21Z,Compile `unicode-normalization` faster,nnethercote,cacc75c82ebe15cf63d31034fcf7f1016cddf0e2,4,Auto merge of #97936 - nnethercote:compile-unicode_normalization-faster r=oli-obk Compile `unicode-normalization` faster Various optimizations and cleanups aimed at improving compilation of `unicode-normalization` which is notable for having several very large `match`es with many char ranges. Best reviewed one commit at a time. r? `@oli-obk`,HOORAY,2022-06-10T10:51:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97936,MERGED,2022-06-10T02:46:42Z,2022-06-16T23:50:21Z,Compile `unicode-normalization` faster,nnethercote,cacc75c82ebe15cf63d31034fcf7f1016cddf0e2,4,Auto merge of #97936 - nnethercote:compile-unicode_normalization-faster r=oli-obk Compile `unicode-normalization` faster Various optimizations and cleanups aimed at improving compilation of `unicode-normalization` which is notable for having several very large `match`es with many char ranges. Best reviewed one commit at a time. r? `@oli-obk`,HOORAY,2022-06-11T06:20:09Z,Titaniumtown,Titaniumtown@gmail.com https://github.com/rust-lang/rust/pull/97936,MERGED,2022-06-10T02:46:42Z,2022-06-16T23:50:21Z,Compile `unicode-normalization` faster,nnethercote,cacc75c82ebe15cf63d31034fcf7f1016cddf0e2,4,Auto merge of #97936 - nnethercote:compile-unicode_normalization-faster r=oli-obk Compile `unicode-normalization` faster Various optimizations and cleanups aimed at improving compilation of `unicode-normalization` which is notable for having several very large `match`es with many char ranges. Best reviewed one commit at a time. r? `@oli-obk`,HOORAY,2022-06-12T06:56:06Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/97936,MERGED,2022-06-10T02:46:42Z,2022-06-16T23:50:21Z,Compile `unicode-normalization` faster,nnethercote,cacc75c82ebe15cf63d31034fcf7f1016cddf0e2,4,Auto merge of #97936 - nnethercote:compile-unicode_normalization-faster r=oli-obk Compile `unicode-normalization` faster Various optimizations and cleanups aimed at improving compilation of `unicode-normalization` which is notable for having several very large `match`es with many char ranges. Best reviewed one commit at a time. r? `@oli-obk`,HOORAY,2022-06-23T15:14:26Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/97940,MERGED,2022-06-10T09:58:46Z,2022-06-11T01:39:43Z,Use relative links instead of linking to doc.rust-lang.org when possible,GuillaumeGomez,30a8903821e35c7c7cee7f393917aecaadc92e93,2,Rollup merge of #97940 - GuillaumeGomez:relative-link r=Dylan-DPC Use relative links instead of linking to doc.rust-lang.org when possible Part of https://github.com/rust-lang/rust/issues/97918.,HEART,2022-06-10T19:39:33Z,est31,NA https://github.com/rust-lang/rust/pull/97950,MERGED,2022-06-10T15:27:12Z,2022-06-13T04:25:59Z,Clarify `#[derive(PartialEq)]` on enums,eggyal,5dccf4e5fcbb49aa8da0d2186c26bbd00eb2a81f,1,Rollup merge of #97950 - eggyal:issue-97945 r=Dylan-DPC Clarify `#[derive(PartialEq)]` on enums Fixes #97945,HEART,2022-06-10T17:39:00Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/97952,OPEN,2022-06-10T16:51:01Z,NA,Use XXH3 hash instead of SIP128 for stable hashing,Kobzol,NA,NA,NA,HOORAY,2022-07-07T10:36:14Z,lqd,NA https://github.com/rust-lang/rust/pull/97953,MERGED,2022-06-10T16:59:09Z,2022-06-11T01:39:43Z,Add regression test for #54378,JohnTitor,dd409dad850c42c2384ac104110ec408f1d9cf86,1,Rollup merge of #97953 - JohnTitor:issue-54378 r=compiler-errors Add regression test for #54378 Closes #54378 r? `@compiler-errors` Signed-off-by: Yuki Okushi ,HEART,2022-06-15T18:49:49Z,estebank,NA https://github.com/rust-lang/rust/pull/97971,OPEN,2022-06-10T20:54:24Z,NA,Enable varargs support for calling conventions other than C or cdecl ,Soveu,NA,NA,NA,HEART,2022-06-12T15:26:26Z,phlopsi,NA https://github.com/rust-lang/rust/pull/97971,OPEN,2022-06-10T20:54:24Z,NA,Enable varargs support for calling conventions other than C or cdecl ,Soveu,NA,NA,NA,HEART,2022-07-01T01:55:00Z,estebank,NA https://github.com/rust-lang/rust/pull/97974,OPEN,2022-06-10T21:10:52Z,NA,Add TyAlias into rustc_type_ir TyKind enum,GuillaumeGomez,NA,NA,NA,HEART,2022-06-28T21:32:41Z,camelid,NA https://github.com/rust-lang/rust/pull/97991,MERGED,2022-06-11T11:44:43Z,2022-06-12T15:05:15Z,Use safer `strip=symbols`-flag for dylibs on macOS,davidkna,265e0f0d4b89038052f80c0332608dda9d87af6b,1,Rollup merge of #97991 - davidkna:fix-macos-strip r=joshtriplett Use safer `strip=symbols`-flag for dylibs on macOS Closes #93988 To safely strip dylibs on macOS the `-x` flag is needed per the manpage (see the discussion here: https://github.com/rust-lang/rust/issues/93988#issuecomment-1042574854). Thus when the current `crate_type` is producing a dylib (I assume this is the case for proc macros) use the `-x` flag instead of bare `strip` for `strip=symbols`.,HOORAY,2022-06-12T14:34:21Z,edmorley,NA https://github.com/rust-lang/rust/pull/97991,MERGED,2022-06-11T11:44:43Z,2022-06-12T15:05:15Z,Use safer `strip=symbols`-flag for dylibs on macOS,davidkna,265e0f0d4b89038052f80c0332608dda9d87af6b,1,Rollup merge of #97991 - davidkna:fix-macos-strip r=joshtriplett Use safer `strip=symbols`-flag for dylibs on macOS Closes #93988 To safely strip dylibs on macOS the `-x` flag is needed per the manpage (see the discussion here: https://github.com/rust-lang/rust/issues/93988#issuecomment-1042574854). Thus when the current `crate_type` is producing a dylib (I assume this is the case for proc macros) use the `-x` flag instead of bare `strip` for `strip=symbols`.,HOORAY,2022-06-12T16:37:07Z,hkratz,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T13:07:42Z,bugadani,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T14:06:46Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T14:40:52Z,bjorn3,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T14:49:40Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T18:26:28Z,darksv,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T19:07:47Z,Soveu,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T20:11:33Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-11T23:32:11Z,MolotovCherry,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-12T04:40:09Z,jeffparsons,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-12T06:40:43Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-12T13:43:04Z,Globidev,guillaume.depardon@gmail.com https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-12T13:49:59Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-12T20:33:28Z,vacuus,rocyu@protonmail.com https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HEART,2022-06-12T22:53:30Z,MolotovCherry,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-14T22:04:15Z,Aloso,ludwig.stecher@gmx.de https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-16T05:26:54Z,Virgiel,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HEART,2022-06-16T05:26:56Z,Virgiel,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-16T17:12:30Z,ilslv,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-17T07:16:47Z,sdroege,slomo@coaxion.net https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-18T02:14:08Z,GrayJack,NA https://github.com/rust-lang/rust/pull/97992,MERGED,2022-06-11T12:36:05Z,2022-06-12T15:05:14Z,Stabilize scoped threads.,m-ou-se,a24ca036601f0bba22cb73fa9e90893f26779b26,3,Rollup merge of #97992 - m-ou-se:stabilize-scoped-threads r=joshtriplett Stabilize scoped threads. Tracking issue: https://github.com/rust-lang/rust/issues/93203 FCP finished here: https://github.com/rust-lang/rust/issues/93203#issuecomment-1152249466,HOORAY,2022-06-20T12:38:18Z,Masterchef365,NA https://github.com/rust-lang/rust/pull/97995,OPEN,2022-06-11T14:54:26Z,NA,allow unions with mutable references and tuples of allowed types,RalfJung,NA,NA,NA,HEART,2022-06-26T12:49:43Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/97999,MERGED,2022-06-11T18:20:25Z,2022-06-13T22:17:25Z,Make `type_changing_struct_update` no longer an incomplete feature,compiler-errors,f758b4f4a064a56a02aee34ca1246d05c4fe8b31,1,Rollup merge of #97999 - compiler-errors:type_changin_struct_update_is_probably_complete r=oli-obk Make `type_changing_struct_update` no longer an incomplete feature After #97705 I don't see what would make it incomplete anymore. `check_expr_struct_fields` seems to now implement the RFC to the letter. r? ``````@nikomatsakis`````` cc ``````@rust-lang/types``````,HOORAY,2022-06-12T07:42:50Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/98004,MERGED,2022-06-11T21:20:50Z,2022-06-18T15:18:50Z,Add VecDeque::extend from TrustedLen specialization,paolobarbolini,2cec6874c086a8fa107115dcca73d93228a3bef6,8,"Auto merge of #98004 - paolobarbolini:vecdeque-extend-trustedlen r=the8472 Add VecDeque::extend from TrustedLen specialization Continuation of #95904 Inspired by how [`VecDeque::copy_slice` works](https://github.com/rust-lang/rust/blob/c08b235a5ce10167632bb0fddcd0c5d67f2d42e3/library/alloc/src/collections/vec_deque/mod.rs#L437-L454). ## Benchmarks Before ``` test vec_deque::bench_extend_chained_bytes ... bench: 1 026 ns/iter (+/- 17) test vec_deque::bench_extend_chained_trustedlen ... bench: 1 024 ns/iter (+/- 40) test vec_deque::bench_extend_trustedlen ... bench: 637 ns/iter (+/- 693) ``` After ``` test vec_deque::bench_extend_chained_bytes ... bench: 828 ns/iter (+/- 24) test vec_deque::bench_extend_chained_trustedlen ... bench: 25 ns/iter (+/- 1) test vec_deque::bench_extend_trustedlen ... bench: 21 ns/iter (+/- 0) ``` ## Why do it this way https://rust.godbolt.org/z/15qY1fMYh The Compiler Explorer example shows how ""just"" removing the capacity check like the [`Vec` `TrustedLen` specialization](https://github.com/rust-lang/rust/blob/c08b235a5ce10167632bb0fddcd0c5d67f2d42e3/library/alloc/src/vec/spec_extend.rs#L22-L58) does wouldn't have been enough for `VecDeque`. `wrap_add` would still have greatly limited what LLVM could do while optimizing. --- r? `@the8472`",ROCKET,2022-06-16T05:37:39Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/98005,MERGED,2022-06-11T21:33:47Z,2022-06-22T10:49:04Z,Add some tests for impossible bounds,compiler-errors,400751d40b59f768dd3e8cf60b2b2f8336174aec,7,Rollup merge of #98005 - compiler-errors:impossible-bounds r=Mark-Simulacrum Add some tests for impossible bounds Adds test for #93008 Adds test for #94680 Closes #94999 Closes #95640,THUMBS_UP,2022-06-12T08:40:05Z,cjgillot,NA https://github.com/rust-lang/rust/pull/98028,OPEN,2022-06-12T15:52:35Z,NA,Add E0789 as more specific variant of E0283,aticu,NA,NA,NA,ROCKET,2022-06-12T18:21:41Z,davidkna,NA https://github.com/rust-lang/rust/pull/98028,OPEN,2022-06-12T15:52:35Z,NA,Add E0789 as more specific variant of E0283,aticu,NA,NA,NA,HEART,2022-06-28T21:16:15Z,estebank,NA https://github.com/rust-lang/rust/pull/98051,OPEN,2022-06-13T11:02:24Z,NA,session: stabilize split debuginfo on linux,davidtwco,NA,NA,NA,HOORAY,2022-06-13T15:18:39Z,est31,NA https://github.com/rust-lang/rust/pull/98051,OPEN,2022-06-13T11:02:24Z,NA,session: stabilize split debuginfo on linux,davidtwco,NA,NA,NA,HOORAY,2022-06-13T18:10:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98051,OPEN,2022-06-13T11:02:24Z,NA,session: stabilize split debuginfo on linux,davidtwco,NA,NA,NA,HOORAY,2022-06-14T02:03:32Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/98053,MERGED,2022-06-13T13:15:13Z,2022-06-16T02:13:07Z,Fix generic impl rustdoc json output,GuillaumeGomez,4ee78a686facf95eb640fc00d5b92d4e9281e81c,2,Rollup merge of #98053 - GuillaumeGomez:fix-generic-impl-json-ice r=notriddle Fix generic impl rustdoc json output Fixes #97986. The problem in case of generic trait impl is that the trait's items are the same for all the types afterward. But since they're the same it's safe for rustdoc-json to just ignore them. A little representation of what's going on: ```rust trait T { fn f(); // <- defid 0 } impl T for Y { fn f() {} // <- defid 1 } struct S; // <- defid 1 (since it matches `impl T for Y` ``` cc ```@Urgau``` r? ```@CraftSpider```,HOORAY,2022-06-13T13:53:04Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98053,MERGED,2022-06-13T13:15:13Z,2022-06-16T02:13:07Z,Fix generic impl rustdoc json output,GuillaumeGomez,4ee78a686facf95eb640fc00d5b92d4e9281e81c,2,Rollup merge of #98053 - GuillaumeGomez:fix-generic-impl-json-ice r=notriddle Fix generic impl rustdoc json output Fixes #97986. The problem in case of generic trait impl is that the trait's items are the same for all the types afterward. But since they're the same it's safe for rustdoc-json to just ignore them. A little representation of what's going on: ```rust trait T { fn f(); // <- defid 0 } impl T for Y { fn f() {} // <- defid 1 } struct S; // <- defid 1 (since it matches `impl T for Y` ``` cc ```@Urgau``` r? ```@CraftSpider```,HEART,2022-06-13T13:53:10Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-13T18:10:19Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-16T13:18:36Z,vidhanio,me@vidhan.io https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T13:58:08Z,shakyShane,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-16T13:58:09Z,shakyShane,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T13:58:49Z,fasterthanlime,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-16T14:04:47Z,alice-i-cecile,alice.i.cecile@gmail.com https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T15:28:23Z,vidhanio,me@vidhan.io https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T16:37:51Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-16T16:37:52Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T19:38:36Z,yerke,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T20:19:18Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-16T20:19:19Z,johnyenter-briars,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-16T23:46:04Z,ruanpetterson,ruan@petterson.eng.br https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-17T01:12:12Z,Xuanwo,github@xuanwo.io https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-17T13:48:13Z,ambeeeeee,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-17T16:38:36Z,grant0417,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-17T16:38:37Z,grant0417,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-18T11:45:35Z,CGMossa,NA https://github.com/rust-lang/rust/pull/98061,OPEN,2022-06-13T15:23:33Z,NA,Add `Option::owned`,WaffleLapkin,NA,NA,NA,EYES,2022-06-18T11:45:35Z,CGMossa,NA https://github.com/rust-lang/rust/pull/98067,MERGED,2022-06-13T19:43:38Z,2022-06-15T08:20:19Z,compiler: remove unused deps,klensy,bb4805118a6274a83e21c78bb96e3cbd9e9dca36,14,Rollup merge of #98067 - klensy:compiler-deps2 r=Dylan-DPC compiler: remove unused deps Removed unused dependencies in compiler crates and moves few `libc` under `target.cfg(unix)` .,THUMBS_UP,2022-06-13T20:14:19Z,est31,NA https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,HEART,2022-06-15T19:01:31Z,shepmaster,jake.goulding@integer32.com https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,HEART,2022-06-17T10:39:03Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,HEART,2022-06-17T23:12:34Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,ROCKET,2022-06-17T23:12:37Z,TimDiekmann,NA https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,HEART,2022-06-20T18:44:00Z,DianaNites,NA https://github.com/rust-lang/rust/pull/98072,OPEN,2022-06-13T21:11:10Z,NA,Add provider API to error trait,yaahc,NA,NA,NA,ROCKET,2022-06-20T18:44:01Z,DianaNites,NA https://github.com/rust-lang/rust/pull/98073,CLOSED,2022-06-13T21:38:35Z,2022-07-09T20:35:55Z,Add runtime validity checks inside MaybeUninit::assume_init,5225225,NA,NA,NA,EYES,2022-06-14T00:06:22Z,est31,NA https://github.com/rust-lang/rust/pull/98079,OPEN,2022-06-14T02:26:46Z,NA,Convert a hard-warning about named static lifetimes into a lint,jeremydavis519,NA,NA,NA,HEART,2022-06-14T04:11:37Z,est31,NA https://github.com/rust-lang/rust/pull/98079,OPEN,2022-06-14T02:26:46Z,NA,Convert a hard-warning about named static lifetimes into a lint,jeremydavis519,NA,NA,NA,HEART,2022-06-14T04:52:48Z,gimbles,NA https://github.com/rust-lang/rust/pull/98079,OPEN,2022-06-14T02:26:46Z,NA,Convert a hard-warning about named static lifetimes into a lint,jeremydavis519,NA,NA,NA,HEART,2022-06-14T17:25:42Z,ritchie46,ritchie46@gmail.com https://github.com/rust-lang/rust/pull/98100,OPEN,2022-06-14T16:47:59Z,NA,Use object instead of LLVM for reading bitcode from rlibs,bjorn3,NA,NA,NA,HOORAY,2022-06-15T21:53:19Z,lqd,NA https://github.com/rust-lang/rust/pull/98100,OPEN,2022-06-14T16:47:59Z,NA,Use object instead of LLVM for reading bitcode from rlibs,bjorn3,NA,NA,NA,HOORAY,2022-06-20T04:15:51Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98100,OPEN,2022-06-14T16:47:59Z,NA,Use object instead of LLVM for reading bitcode from rlibs,bjorn3,NA,NA,NA,HEART,2022-06-28T19:20:58Z,mati865,NA https://github.com/rust-lang/rust/pull/98119,MERGED,2022-06-15T02:00:15Z,2022-06-16T02:13:07Z,Refactor path segment parameter error,EdwinRy,bfc6c90115a84157451b0738f5f56fd8275a9aaa,7,"Rollup merge of #98119 - EdwinRy:path-parenthesized-type-error r=estebank Refactor path segment parameter error This PR attempts to rewrite the error handling for an unexpected parenthesised type parameters to: - Use provided data instead of re-parsing the whole span - Add a multipart suggestion to reflect on the changes with an underline - Remove the unnecessary ""if"" nesting",THUMBS_UP,2022-06-15T02:08:14Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/98119,MERGED,2022-06-15T02:00:15Z,2022-06-16T02:13:07Z,Refactor path segment parameter error,EdwinRy,bfc6c90115a84157451b0738f5f56fd8275a9aaa,7,"Rollup merge of #98119 - EdwinRy:path-parenthesized-type-error r=estebank Refactor path segment parameter error This PR attempts to rewrite the error handling for an unexpected parenthesised type parameters to: - Use provided data instead of re-parsing the whole span - Add a multipart suggestion to reflect on the changes with an underline - Remove the unnecessary ""if"" nesting",THUMBS_UP,2022-06-15T17:34:43Z,estebank,NA https://github.com/rust-lang/rust/pull/98119,MERGED,2022-06-15T02:00:15Z,2022-06-16T02:13:07Z,Refactor path segment parameter error,EdwinRy,bfc6c90115a84157451b0738f5f56fd8275a9aaa,7,"Rollup merge of #98119 - EdwinRy:path-parenthesized-type-error r=estebank Refactor path segment parameter error This PR attempts to rewrite the error handling for an unexpected parenthesised type parameters to: - Use provided data instead of re-parsing the whole span - Add a multipart suggestion to reflect on the changes with an underline - Remove the unnecessary ""if"" nesting",THUMBS_UP,2022-06-15T19:18:57Z,cjgillot,NA https://github.com/rust-lang/rust/pull/98121,CLOSED,2022-06-15T02:43:27Z,2022-06-16T21:05:38Z,Emit `@llvm.lifetime.end` for moved arguments passed indirectly,erikdesjardins,NA,NA,NA,HEART,2022-06-15T07:59:27Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/98140,MERGED,2022-06-15T16:59:30Z,2022-06-26T02:26:55Z,compiletest: strip debuginfo by default for mode=ui,klensy,639a655e11306116e8507d401a1262e87e1b23b7,13,Auto merge of #98140 - klensy:compiletest-strip r=Mark-Simulacrum compiletest: strip debuginfo by default for mode=ui This reduces occupied disk space for example for src/test/ui it drops from 1972mb to 132mb (x86_64-pc-windows-msvc). Individual tests that require debuginfo/symbols should turn this option off (as in fixed tests).,HEART,2022-06-15T17:27:37Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98140,MERGED,2022-06-15T16:59:30Z,2022-06-26T02:26:55Z,compiletest: strip debuginfo by default for mode=ui,klensy,639a655e11306116e8507d401a1262e87e1b23b7,13,Auto merge of #98140 - klensy:compiletest-strip r=Mark-Simulacrum compiletest: strip debuginfo by default for mode=ui This reduces occupied disk space for example for src/test/ui it drops from 1972mb to 132mb (x86_64-pc-windows-msvc). Individual tests that require debuginfo/symbols should turn this option off (as in fixed tests).,HEART,2022-07-05T18:13:06Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98154,OPEN,2022-06-16T01:55:09Z,NA,merge functionality of `io::Sink` into `io::Empty`,vidhanio,NA,NA,NA,EYES,2022-06-16T13:15:29Z,wozeparrot,NA https://github.com/rust-lang/rust/pull/98154,OPEN,2022-06-16T01:55:09Z,NA,merge functionality of `io::Sink` into `io::Empty`,vidhanio,NA,NA,NA,EYES,2022-06-16T13:20:12Z,noisya55616,NA https://github.com/rust-lang/rust/pull/98154,OPEN,2022-06-16T01:55:09Z,NA,merge functionality of `io::Sink` into `io::Empty`,vidhanio,NA,NA,NA,THUMBS_UP,2022-06-16T13:20:26Z,noisya55616,NA https://github.com/rust-lang/rust/pull/98154,OPEN,2022-06-16T01:55:09Z,NA,merge functionality of `io::Sink` into `io::Empty`,vidhanio,NA,NA,NA,THUMBS_UP,2022-06-17T09:19:11Z,nvzqz,github@nikolaivazquez.com https://github.com/rust-lang/rust/pull/98159,MERGED,2022-06-16T04:49:39Z,2022-06-20T17:01:52Z,Include ForeignItem when visiting types for WF check,PrestonFrom,7bde23bb4f0cc74c5566e85501a43426c1be1bef,3,Rollup merge of #98159 - PrestonFrom:issue_95665 r=petrochenkov Include ForeignItem when visiting types for WF check Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid type to visit in `diagnostic_hir_wf_check`. Fixes #95665,THUMBS_UP,2022-06-21T16:40:43Z,ahrens,mahrens@delphix.com https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-16T12:45:01Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-16T12:55:39Z,b01o,NA https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-16T14:00:49Z,usamoi,usamoi@outlook.com https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-16T15:13:49Z,kkocdko,NA https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-18T00:59:44Z,arniu,NA https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-18T10:06:02Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-18T11:08:21Z,rossmacarthur,NA https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-19T04:53:03Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/98165,MERGED,2022-06-16T11:58:53Z,2022-06-19T03:06:10Z,once cell renamings,WaffleLapkin,f351f347b8ab6520f749b0ec10aa33b3ee480614,40,Rollup merge of #98165 - WaffleLapkin:once_things_renamings r=m-ou-se once cell renamings This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128 - Move/rename `lazy::{OnceCell Lazy}` to `cell::{OnceCell LazyCell}` - Move/rename `lazy::{SyncOnceCell SyncLazy}` to `sync::{OnceLock LazyLock}` (I used `Lazy...` instead of `...Lazy` as it seems to be more consistent easier to pronounce etc) ```@rustbot``` label +T-libs-api -T-libs,HEART,2022-06-23T16:32:25Z,knickish,NA https://github.com/rust-lang/rust/pull/98178,MERGED,2022-06-16T19:01:13Z,2022-06-18T07:37:12Z,btree: avoid forcing the allocator to be a reference,RalfJung,ff86b27e7be1ffff9e00d80beb15560d5f301459,10,Auto merge of #98178 - RalfJung:btree-alloc r=thomcc btree: avoid forcing the allocator to be a reference The previous code forces the actual allocator used to be some `&A`. This generalizes the code to allow any `A: Copy`. If people truly want to use a reference they can use `&A` themselves. Fixes https://github.com/rust-lang/rust/issues/98176,THUMBS_UP,2022-06-16T19:06:10Z,exrook,NA https://github.com/rust-lang/rust/pull/98178,MERGED,2022-06-16T19:01:13Z,2022-06-18T07:37:12Z,btree: avoid forcing the allocator to be a reference,RalfJung,ff86b27e7be1ffff9e00d80beb15560d5f301459,10,Auto merge of #98178 - RalfJung:btree-alloc r=thomcc btree: avoid forcing the allocator to be a reference The previous code forces the actual allocator used to be some `&A`. This generalizes the code to allow any `A: Copy`. If people truly want to use a reference they can use `&A` themselves. Fixes https://github.com/rust-lang/rust/issues/98176,THUMBS_UP,2022-06-16T23:25:03Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98178,MERGED,2022-06-16T19:01:13Z,2022-06-18T07:37:12Z,btree: avoid forcing the allocator to be a reference,RalfJung,ff86b27e7be1ffff9e00d80beb15560d5f301459,10,Auto merge of #98178 - RalfJung:btree-alloc r=thomcc btree: avoid forcing the allocator to be a reference The previous code forces the actual allocator used to be some `&A`. This generalizes the code to allow any `A: Copy`. If people truly want to use a reference they can use `&A` themselves. Fixes https://github.com/rust-lang/rust/issues/98176,THUMBS_UP,2022-06-17T08:03:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98190,MERGED,2022-06-17T07:09:50Z,2022-06-26T17:15:47Z,Improve `derive(Debug)`,nnethercote,788ddedb0d88e40db9cd62b6163d5a471813044b,10,Auto merge of #98190 - nnethercote:optimize-derive-Debug-code r=scottmcm Improve `derive(Debug)` r? `@ghost`,HEART,2022-07-07T07:57:52Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/98195,MERGED,2022-06-17T12:42:17Z,2022-06-18T05:12:39Z,Fix rustdoc json primitive handling,GuillaumeGomez,4557ff7bd7652665af636777e3b8ec0d45bd5ff9,2,Rollup merge of #98195 - GuillaumeGomez:rustdoc-json-primitive r=notriddle Fix rustdoc json primitive handling Fixes https://github.com/rust-lang/rust/issues/98006. cc `@matthiaskrgr`,HEART,2022-06-17T13:19:48Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98197,OPEN,2022-06-17T13:15:36Z,NA,Speed up `ptr::replace`,lukas-code,NA,NA,NA,EYES,2022-06-21T06:47:41Z,ryoqun,ryoqun@gmail.com https://github.com/rust-lang/rust/pull/98200,OPEN,2022-06-17T13:46:59Z,NA,Expand potential inner `Or` pattern for THIR,ouz-a,NA,NA,NA,HEART,2022-06-17T18:34:48Z,estebank,NA https://github.com/rust-lang/rust/pull/98200,OPEN,2022-06-17T13:46:59Z,NA,Expand potential inner `Or` pattern for THIR,ouz-a,NA,NA,NA,HEART,2022-06-18T09:37:01Z,StephanvanSchaik,stephan@synkhronix.com https://github.com/rust-lang/rust/pull/98204,OPEN,2022-06-17T16:47:04Z,NA,Stabilize `Option::unzip()`,Kixiron,NA,NA,NA,THUMBS_UP,2022-06-29T22:29:27Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/98212,MERGED,2022-06-17T21:33:52Z,2022-06-27T02:56:08Z,rustc_target: Add convenience functions for adding linker arguments,petrochenkov,221bdb62a23f54a32b56b55a6578646f3594fd3b,76,Auto merge of #98212 - petrochenkov:addlinkargs r=lqd rustc_target: Add convenience functions for adding linker arguments They ensure that lld and non-lld linker flavors get the same set of arguments. The second commit also adds some tests checking for linker argument inconsistencies and tweaks some arguments to fix those inconsistencies.,THUMBS_UP,2022-06-17T21:53:07Z,estebank,NA https://github.com/rust-lang/rust/pull/98212,MERGED,2022-06-17T21:33:52Z,2022-06-27T02:56:08Z,rustc_target: Add convenience functions for adding linker arguments,petrochenkov,221bdb62a23f54a32b56b55a6578646f3594fd3b,76,Auto merge of #98212 - petrochenkov:addlinkargs r=lqd rustc_target: Add convenience functions for adding linker arguments They ensure that lld and non-lld linker flavors get the same set of arguments. The second commit also adds some tests checking for linker argument inconsistencies and tweaks some arguments to fix those inconsistencies.,THUMBS_UP,2022-06-19T19:56:44Z,Urgau,NA https://github.com/rust-lang/rust/pull/98212,MERGED,2022-06-17T21:33:52Z,2022-06-27T02:56:08Z,rustc_target: Add convenience functions for adding linker arguments,petrochenkov,221bdb62a23f54a32b56b55a6578646f3594fd3b,76,Auto merge of #98212 - petrochenkov:addlinkargs r=lqd rustc_target: Add convenience functions for adding linker arguments They ensure that lld and non-lld linker flavors get the same set of arguments. The second commit also adds some tests checking for linker argument inconsistencies and tweaks some arguments to fix those inconsistencies.,THUMBS_UP,2022-06-20T07:05:11Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98225,MERGED,2022-06-18T10:27:32Z,2022-06-20T03:08:41Z,Make debug_triple depend on target json file content rather than file path,bjorn3,bfa6cd9c6802efe3d6cef119bed1f78e596062d2,2,Rollup merge of #98225 - bjorn3:stable_target_json_hash r=nagisa Make debug_triple depend on target json file content rather than file path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation. This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``,HEART,2022-06-18T10:31:58Z,ojeda,NA https://github.com/rust-lang/rust/pull/98225,MERGED,2022-06-18T10:27:32Z,2022-06-20T03:08:41Z,Make debug_triple depend on target json file content rather than file path,bjorn3,bfa6cd9c6802efe3d6cef119bed1f78e596062d2,2,Rollup merge of #98225 - bjorn3:stable_target_json_hash r=nagisa Make debug_triple depend on target json file content rather than file path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation. This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``,HEART,2022-06-19T13:14:54Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/98225,MERGED,2022-06-18T10:27:32Z,2022-06-20T03:08:41Z,Make debug_triple depend on target json file content rather than file path,bjorn3,bfa6cd9c6802efe3d6cef119bed1f78e596062d2,2,Rollup merge of #98225 - bjorn3:stable_target_json_hash r=nagisa Make debug_triple depend on target json file content rather than file path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation. This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``,THUMBS_UP,2022-06-19T13:15:51Z,Leo1003,leo881003@gmail.com https://github.com/rust-lang/rust/pull/98225,MERGED,2022-06-18T10:27:32Z,2022-06-20T03:08:41Z,Make debug_triple depend on target json file content rather than file path,bjorn3,bfa6cd9c6802efe3d6cef119bed1f78e596062d2,2,Rollup merge of #98225 - bjorn3:stable_target_json_hash r=nagisa Make debug_triple depend on target json file content rather than file path This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation. This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``,HEART,2022-06-29T18:38:45Z,YakoYakoYokuYoku,yakoyoku@gmail.com https://github.com/rust-lang/rust/pull/98226,MERGED,2022-06-18T10:27:33Z,2022-06-22T10:49:03Z,Document unstable `--extern` options,ChrisDenton,35597182abe8afd4f272c9832cf7305ec4132bf8,1,Rollup merge of #98226 - ChrisDenton:doc-extern-options r=ehuss Document unstable `--extern` options These are needed for Cargo's `build-std` feature and for anyone who wanted to do a similar thing outside of Cargo.,HEART,2022-06-18T10:29:39Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98235,MERGED,2022-06-18T17:23:14Z,2022-06-21T01:04:09Z,Drop magic value 3 from code,liuw,eac149368b9a681ad80fe642e4205760eb1aa93f,1,Rollup merge of #98235 - liuw:mir-gen-drop-magic-value r=davidtwco Drop magic value 3 from code Magic value 3 is used to create state for a yield point. It is in fact the number of reserved variants. Lift RESERVED_VARIANTS out to module scope and use it instead.,THUMBS_UP,2022-06-20T07:04:02Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98247,MERGED,2022-06-19T04:24:20Z,2022-06-19T22:13:18Z,Move RegionKind to rustc_type_ir,jackh726,bb8c2f41174caceec00c28bc6c5c20ae9f9a175c,12,Auto merge of #98247 - jackh726:regionkind-rustc-type-ir r=compiler-errors Move RegionKind to rustc_type_ir (Also UniverseIndex) r? rust-lang/types,HEART,2022-06-19T04:25:04Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98259,MERGED,2022-06-19T19:37:00Z,2022-06-24T04:37:24Z,Greatly improve error reporting for futures and generators in `note_obligation_cause_code`,jyn514,413e350f87fafeea3da13fc98337c632c4cfcd70,21,Rollup merge of #98259 - jyn514:improve-obligation-errors r=estebank Greatly improve error reporting for futures and generators in `note_obligation_cause_code` Most futures don't go through this code path because they're caught by `maybe_note_obligation_cause_for_async_await`. But all generators do and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses. At some point we may want to consider unifying this with the code for `maybe_note_async_await` so that `async_await` notes all parent constraints and `note_obligation` can point to yield points. But both functions are quite complicated and it's not clear to me how to combine them; this seems like a good incremental improvement. Helps with https://github.com/rust-lang/rust/issues/97332. r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``,HEART,2022-06-19T19:38:11Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98259,MERGED,2022-06-19T19:37:00Z,2022-06-24T04:37:24Z,Greatly improve error reporting for futures and generators in `note_obligation_cause_code`,jyn514,413e350f87fafeea3da13fc98337c632c4cfcd70,21,Rollup merge of #98259 - jyn514:improve-obligation-errors r=estebank Greatly improve error reporting for futures and generators in `note_obligation_cause_code` Most futures don't go through this code path because they're caught by `maybe_note_obligation_cause_for_async_await`. But all generators do and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses. At some point we may want to consider unifying this with the code for `maybe_note_async_await` so that `async_await` notes all parent constraints and `note_obligation` can point to yield points. But both functions are quite complicated and it's not clear to me how to combine them; this seems like a good incremental improvement. Helps with https://github.com/rust-lang/rust/issues/97332. r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``,HEART,2022-06-20T21:47:30Z,eholk,eric@theincredibleholk.org https://github.com/rust-lang/rust/pull/98259,MERGED,2022-06-19T19:37:00Z,2022-06-24T04:37:24Z,Greatly improve error reporting for futures and generators in `note_obligation_cause_code`,jyn514,413e350f87fafeea3da13fc98337c632c4cfcd70,21,Rollup merge of #98259 - jyn514:improve-obligation-errors r=estebank Greatly improve error reporting for futures and generators in `note_obligation_cause_code` Most futures don't go through this code path because they're caught by `maybe_note_obligation_cause_for_async_await`. But all generators do and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses. At some point we may want to consider unifying this with the code for `maybe_note_async_await` so that `async_await` notes all parent constraints and `note_obligation` can point to yield points. But both functions are quite complicated and it's not clear to me how to combine them; this seems like a good incremental improvement. Helps with https://github.com/rust-lang/rust/issues/97332. r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``,HEART,2022-06-22T00:00:15Z,estebank,NA https://github.com/rust-lang/rust/pull/98259,MERGED,2022-06-19T19:37:00Z,2022-06-24T04:37:24Z,Greatly improve error reporting for futures and generators in `note_obligation_cause_code`,jyn514,413e350f87fafeea3da13fc98337c632c4cfcd70,21,Rollup merge of #98259 - jyn514:improve-obligation-errors r=estebank Greatly improve error reporting for futures and generators in `note_obligation_cause_code` Most futures don't go through this code path because they're caught by `maybe_note_obligation_cause_for_async_await`. But all generators do and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses. At some point we may want to consider unifying this with the code for `maybe_note_async_await` so that `async_await` notes all parent constraints and `note_obligation` can point to yield points. But both functions are quite complicated and it's not clear to me how to combine them; this seems like a good incremental improvement. Helps with https://github.com/rust-lang/rust/issues/97332. r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``,HEART,2022-06-24T18:08:37Z,memoryruins,michael@memoryruins.com https://github.com/rust-lang/rust/pull/98259,MERGED,2022-06-19T19:37:00Z,2022-06-24T04:37:24Z,Greatly improve error reporting for futures and generators in `note_obligation_cause_code`,jyn514,413e350f87fafeea3da13fc98337c632c4cfcd70,21,Rollup merge of #98259 - jyn514:improve-obligation-errors r=estebank Greatly improve error reporting for futures and generators in `note_obligation_cause_code` Most futures don't go through this code path because they're caught by `maybe_note_obligation_cause_for_async_await`. But all generators do and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses. At some point we may want to consider unifying this with the code for `maybe_note_async_await` so that `async_await` notes all parent constraints and `note_obligation` can point to yield points. But both functions are quite complicated and it's not clear to me how to combine them; this seems like a good incremental improvement. Helps with https://github.com/rust-lang/rust/issues/97332. r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``,HEART,2022-06-30T10:17:24Z,Agrailag,NA https://github.com/rust-lang/rust/pull/98297,MERGED,2022-06-20T14:39:29Z,2022-06-26T21:28:31Z,Transform help popup into a pocket menu,GuillaumeGomez,df26fdf3e1667e7ea2e442bb554aa9632677c862,11,"Rollup merge of #98297 - GuillaumeGomez:help-pocket-menu r=notriddle Transform help popup into a pocket menu Just like we moved the settings menu into a ""pocket menu"" it's doing the same to the help popup. You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot: ![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png) r? ``````````@jsha``````````",THUMBS_UP,2022-06-20T23:15:23Z,vidhanio,me@vidhan.io https://github.com/rust-lang/rust/pull/98297,MERGED,2022-06-20T14:39:29Z,2022-06-26T21:28:31Z,Transform help popup into a pocket menu,GuillaumeGomez,df26fdf3e1667e7ea2e442bb554aa9632677c862,11,"Rollup merge of #98297 - GuillaumeGomez:help-pocket-menu r=notriddle Transform help popup into a pocket menu Just like we moved the settings menu into a ""pocket menu"" it's doing the same to the help popup. You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot: ![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png) r? ``````````@jsha``````````",EYES,2022-06-20T23:15:25Z,vidhanio,me@vidhan.io https://github.com/rust-lang/rust/pull/98297,MERGED,2022-06-20T14:39:29Z,2022-06-26T21:28:31Z,Transform help popup into a pocket menu,GuillaumeGomez,df26fdf3e1667e7ea2e442bb554aa9632677c862,11,"Rollup merge of #98297 - GuillaumeGomez:help-pocket-menu r=notriddle Transform help popup into a pocket menu Just like we moved the settings menu into a ""pocket menu"" it's doing the same to the help popup. You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot: ![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png) r? ``````````@jsha``````````",THUMBS_UP,2022-06-27T09:30:48Z,faptc,NA https://github.com/rust-lang/rust/pull/98301,OPEN,2022-06-20T17:17:01Z,NA,Add GDB/LLDB pretty-printers for NonZero types,ortem,NA,NA,NA,THUMBS_UP,2022-06-20T18:07:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98301,OPEN,2022-06-20T17:17:01Z,NA,Add GDB/LLDB pretty-printers for NonZero types,ortem,NA,NA,NA,HEART,2022-06-20T18:53:05Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/98301,OPEN,2022-06-20T17:17:01Z,NA,Add GDB/LLDB pretty-printers for NonZero types,ortem,NA,NA,NA,HEART,2022-06-21T01:42:16Z,luqmana,me@luqman.ca https://github.com/rust-lang/rust/pull/98304,OPEN,2022-06-20T17:51:59Z,NA,Add MaybeUninit memset test,SUPERCILEX,NA,NA,NA,THUMBS_UP,2022-06-21T06:48:53Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/98313,MERGED,2022-06-20T21:02:41Z,2022-06-21T16:24:57Z,Remove lies in comments.,m-ou-se,18b01d5ea0684ce082c2f2008a0ff9c7e485a442,2,Rollup merge of #98313 - m-ou-se:fix-comments r=joshtriplett Remove lies in comments. > does not have a const constructor > pub const fn new() -> Self 🤔,LAUGH,2022-06-21T00:26:03Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/98313,MERGED,2022-06-20T21:02:41Z,2022-06-21T16:24:57Z,Remove lies in comments.,m-ou-se,18b01d5ea0684ce082c2f2008a0ff9c7e485a442,2,Rollup merge of #98313 - m-ou-se:fix-comments r=joshtriplett Remove lies in comments. > does not have a const constructor > pub const fn new() -> Self 🤔,LAUGH,2022-06-21T16:06:41Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/98320,OPEN,2022-06-21T03:03:51Z,NA,Mention first and last macro in backtrace,compiler-errors,NA,NA,NA,HEART,2022-06-21T04:08:24Z,MomoLangenstein,NA https://github.com/rust-lang/rust/pull/98320,OPEN,2022-06-21T03:03:51Z,NA,Mention first and last macro in backtrace,compiler-errors,NA,NA,NA,HEART,2022-06-21T04:48:10Z,JohnTitor,jtitor@2k36.org https://github.com/rust-lang/rust/pull/98320,OPEN,2022-06-21T03:03:51Z,NA,Mention first and last macro in backtrace,compiler-errors,NA,NA,NA,HEART,2022-06-27T00:18:17Z,estebank,NA https://github.com/rust-lang/rust/pull/98320,OPEN,2022-06-21T03:03:51Z,NA,Mention first and last macro in backtrace,compiler-errors,NA,NA,NA,HEART,2022-07-04T06:34:15Z,xFrednet,xFrednet@gmail.com https://github.com/rust-lang/rust/pull/98320,OPEN,2022-06-21T03:03:51Z,NA,Mention first and last macro in backtrace,compiler-errors,NA,NA,NA,HEART,2022-07-06T23:59:05Z,camsteffen,NA https://github.com/rust-lang/rust/pull/98325,CLOSED,2022-06-21T05:59:09Z,2022-06-30T11:49:08Z,Add new func `Pin::as_inner_ref`,NobodyXu,NA,NA,NA,HEART,2022-06-22T03:10:12Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/98331,MERGED,2022-06-21T10:08:12Z,2022-06-28T01:03:50Z,Fix rustdoc argument error,GuillaumeGomez,38bfa9c4f83b92c7ece0ff3a78e1ba16e7a9cf80,12,Rollup merge of #98331 - GuillaumeGomez:rustdoc-arg-error r=notriddle Fix rustdoc argument error Fixes #88756. It's a take over of #88831. I cherry-picked the commits fixed the merge conflict and the failing test. cc `@inashivb` `@jyn514` r? `@notriddle`,HEART,2022-06-21T12:09:47Z,inashivb,NA https://github.com/rust-lang/rust/pull/98333,OPEN,2022-06-21T10:40:59Z,NA,Re-enable atomic loads and stores for all RISC-V targets,SimonSapin,NA,NA,NA,THUMBS_UP,2022-06-21T19:02:39Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/98345,OPEN,2022-06-21T16:18:14Z,NA,stabilise mixed_integer_ops,Dylan-DPC,NA,NA,NA,ROCKET,2022-06-21T16:19:18Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98345,OPEN,2022-06-21T16:18:14Z,NA,stabilise mixed_integer_ops,Dylan-DPC,NA,NA,NA,ROCKET,2022-06-29T20:48:41Z,tjallingt,NA https://github.com/rust-lang/rust/pull/98345,OPEN,2022-06-21T16:18:14Z,NA,stabilise mixed_integer_ops,Dylan-DPC,NA,NA,NA,ROCKET,2022-07-07T03:29:21Z,archshift,gh@archshift.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T19:23:48Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T19:45:06Z,mati865,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T19:46:08Z,mucinoab,mucinoab@comunidad.unam.mx https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T19:53:07Z,emilio,emilio@crisal.io https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T19:56:07Z,kornelski,github@pornel.net https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T20:27:39Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T20:31:30Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T22:40:05Z,yerke,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-21T22:40:07Z,yerke,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-21T22:40:14Z,yerke,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-21T22:40:16Z,yerke,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-21T22:44:42Z,ghishadow,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T22:44:43Z,ghishadow,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-21T23:21:36Z,weihanglo,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-21T23:21:36Z,weihanglo,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-21T23:21:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-21T23:21:37Z,weihanglo,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-22T00:06:42Z,rgwood,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T00:06:43Z,rgwood,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T00:23:52Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-22T00:23:54Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-22T00:23:56Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T00:23:57Z,Cypher1,jp10010101010000@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T00:54:25Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T01:10:05Z,infogulch,infogulch@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T03:57:27Z,graydon,graydon@pobox.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-22T06:20:36Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T06:36:58Z,ozkanpakdil,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T07:02:43Z,Patterner,plate@patterner.eu https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T08:00:26Z,dmilith,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T08:00:27Z,dmilith,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T08:30:53Z,drahnr,bernhard@ahoi.io https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T15:46:17Z,peterwmwong,peter.wm.wong@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-22T17:45:46Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-22T17:45:47Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-06-22T17:45:48Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,ROCKET,2022-06-22T17:45:48Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-22T19:12:57Z,mominul,mominul2082@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-06-23T05:51:00Z,sticnarf,sticnarf@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-06-23T15:37:48Z,kakkoyun,NA https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,THUMBS_UP,2022-07-08T21:32:46Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HOORAY,2022-07-08T21:32:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98350,MERGED,2022-06-21T19:13:59Z,2022-07-09T09:56:25Z,Implement support for DWARF version 5.,pcwalton,fd4f11dd768e7de5015b57eef6b18c1f4d31e1e6,13,Rollup merge of #98350 - pcwalton:dwarf5 r=michaelwoerister Implement support for DWARF version 5. DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression > separation of debugging data from executable files improved description of > macros and source files faster searching for symbols improved debugging > optimized code as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux primarily) this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php r? ``@michaelwoerister``,HEART,2022-07-08T21:32:47Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98353,MERGED,2022-06-21T19:37:33Z,2022-06-24T04:37:24Z,Migrate two diagnostics from the `rustc_builtin_macros` crate,beetrees,21085e91204f979495e2dd87161eb0c358743e12,8,Rollup merge of #98353 - beetrees:builtin-macros-cfg-diag r=davidtwco Migrate two diagnostics from the `rustc_builtin_macros` crate Migrate two diagnostics to use the struct derive and be translatable. r? ```@davidtwco```,HEART,2022-06-22T08:17:00Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/98360,MERGED,2022-06-21T22:57:20Z,2022-07-08T02:17:14Z, On partial uninit error point at where we need init,estebank,9b21131278cc38ab8d79444de340015faadd061c,111,Auto merge of #98360 - estebank:uninit-binding r=oli-obk On partial uninit error point at where we need init When a binding is declared without a value borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an uninitialized binding we emit E0381. We now look at all the statements that initialize the binding and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing we display the spans of all the existing initializers to provide some context. Fix https://github.com/rust-lang/rust/issues/97956.,HEART,2022-06-22T00:09:55Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/98360,MERGED,2022-06-21T22:57:20Z,2022-07-08T02:17:14Z, On partial uninit error point at where we need init,estebank,9b21131278cc38ab8d79444de340015faadd061c,111,Auto merge of #98360 - estebank:uninit-binding r=oli-obk On partial uninit error point at where we need init When a binding is declared without a value borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an uninitialized binding we emit E0381. We now look at all the statements that initialize the binding and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing we display the spans of all the existing initializers to provide some context. Fix https://github.com/rust-lang/rust/issues/97956.,HEART,2022-06-22T00:19:36Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98360,MERGED,2022-06-21T22:57:20Z,2022-07-08T02:17:14Z, On partial uninit error point at where we need init,estebank,9b21131278cc38ab8d79444de340015faadd061c,111,Auto merge of #98360 - estebank:uninit-binding r=oli-obk On partial uninit error point at where we need init When a binding is declared without a value borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an uninitialized binding we emit E0381. We now look at all the statements that initialize the binding and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing we display the spans of all the existing initializers to provide some context. Fix https://github.com/rust-lang/rust/issues/97956.,HEART,2022-06-23T18:01:25Z,Finchiedev,developer.finchie@gmail.com https://github.com/rust-lang/rust/pull/98360,MERGED,2022-06-21T22:57:20Z,2022-07-08T02:17:14Z, On partial uninit error point at where we need init,estebank,9b21131278cc38ab8d79444de340015faadd061c,111,Auto merge of #98360 - estebank:uninit-binding r=oli-obk On partial uninit error point at where we need init When a binding is declared without a value borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an uninitialized binding we emit E0381. We now look at all the statements that initialize the binding and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing we display the spans of all the existing initializers to provide some context. Fix https://github.com/rust-lang/rust/issues/97956.,HEART,2022-07-07T08:30:01Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98370,OPEN,2022-06-22T03:31:23Z,NA,[Experiment] set .cargo/registry/src as readonly,weihanglo,NA,NA,NA,EYES,2022-06-22T04:26:28Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98371,MERGED,2022-06-22T04:34:18Z,2022-06-26T09:42:22Z,Fix printing `impl trait` under binders,compiler-errors,645e5c475a238581f6aefe53d416ddcc7aff5fb3,4,Rollup merge of #98371 - compiler-errors:better-opaque-printing r=oli-obk Fix printing `impl trait` under binders Before we would render `impl for<'a> Trait<'a>` like `impl Trait 'a>` lol.,LAUGH,2022-06-22T09:08:12Z,oli-obk,NA https://github.com/rust-lang/rust/pull/98385,MERGED,2022-06-22T12:51:25Z,2022-06-26T09:42:22Z,Work around llvm 12's memory ordering restrictions.,m-ou-se,7c3977669b69cf69bf9ab51ed8bee155fb442448,1,Rollup merge of #98385 - m-ou-se:llvm-12-memory-order r=petrochenkov Work around llvm 12's memory ordering restrictions. Older llvm has the pre-C++17 restriction on success and failure memory ordering requiring the former to be at least as strong as the latter. So for llvm 12 this upgrades the success ordering to a stronger one if necessary. See https://github.com/rust-lang/rust/issues/68464,THUMBS_UP,2022-06-22T18:14:53Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/98390,MERGED,2022-06-22T14:27:33Z,2022-06-24T04:37:23Z,Fixes handling of keywords in rustdoc json output,GuillaumeGomez,56209834a6a92e33c148d9a956b1074054c65994,2,Rollup merge of #98390 - GuillaumeGomez:keyword-rustdoc-json r=notriddle Fixes handling of keywords in rustdoc json output Fixes #98002. Instead of panicking we just filter them out. cc ```@matthiaskrgr``` r? ```@notriddle```,HEART,2022-06-22T14:39:53Z,matthiaskrgr,NA https://github.com/rust-lang/rust/pull/98390,MERGED,2022-06-22T14:27:33Z,2022-06-24T04:37:23Z,Fixes handling of keywords in rustdoc json output,GuillaumeGomez,56209834a6a92e33c148d9a956b1074054c65994,2,Rollup merge of #98390 - GuillaumeGomez:keyword-rustdoc-json r=notriddle Fixes handling of keywords in rustdoc json output Fixes #98002. Instead of panicking we just filter them out. cc ```@matthiaskrgr``` r? ```@notriddle```,HEART,2022-06-24T19:50:44Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98402,MERGED,2022-06-22T18:53:52Z,2022-07-01T17:33:44Z,Rewrite dead-code pass to avoid fetching HIR.,cjgillot,5b9775fe17893cba641a071de7e0a7c8f478c41b,24,Auto merge of #98402 - cjgillot:undead r=michaelwoerister Rewrite dead-code pass to avoid fetching HIR. This allows to get a more uniform handling of spans and to simplify the grouping of diagnostics for variants and fields.,THUMBS_UP,2022-07-06T09:15:47Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/98416,CLOSED,2022-06-23T04:48:16Z,2022-06-23T08:08:49Z,Stable,raman1383,NA,NA,NA,THUMBS_UP,2022-06-23T04:48:38Z,raman1383,NA https://github.com/rust-lang/rust/pull/98416,CLOSED,2022-06-23T04:48:16Z,2022-06-23T08:08:49Z,Stable,raman1383,NA,NA,NA,THUMBS_DOWN,2022-06-23T06:55:20Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98416,CLOSED,2022-06-23T04:48:16Z,2022-06-23T08:08:49Z,Stable,raman1383,NA,NA,NA,THUMBS_DOWN,2022-06-23T07:09:25Z,mati865,NA https://github.com/rust-lang/rust/pull/98419,MERGED,2022-06-23T08:25:30Z,2022-06-24T12:58:35Z,Remove excess rib while resolving closures,WaffleLapkin,5e98e55668f25cd046073bd67dbcfd6b58ec467e,1,Rollup merge of #98419 - WaffleLapkin:remove_excess_rib r=compiler-errors Remove excess rib while resolving closures I've mentioned this on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60ClosureOrAsyncRibKind.60.20weirdness/near/286982959) in `rustc_resolve` while resolving closures we add an excess `ClosureOrAsyncRibKind`. It's excess because we later add another one in `visit_fn`. I couldn't find a way in which removing this will break anything all test seem to pass etc. r? ``@compiler-errors`` cc ``@davidtwco``,THUMBS_UP,2022-06-23T08:26:20Z,davidtwco,hello@davidtw.co https://github.com/rust-lang/rust/pull/98445,OPEN,2022-06-24T07:07:52Z,NA,[Experiment] [WIP] Add clone_from to clone derive,AngelicosPhosphoros,NA,NA,NA,THUMBS_UP,2022-06-24T07:33:25Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98446,MERGED,2022-06-24T07:10:31Z,2022-07-04T03:54:50Z,Don't use match-destructuring for derived ops on structs.,nnethercote,d46c728bcda687b1cf5f3bedca3d501e797b2a0f,6,Auto merge of #98446 - nnethercote:derive-no-match-destructuring r=scottmcm Don't use match-destructuring for derived ops on structs. r? `@scottmcm`,THUMBS_UP,2022-06-24T16:04:09Z,AngelicosPhosphoros,NA https://github.com/rust-lang/rust/pull/98446,MERGED,2022-06-24T07:10:31Z,2022-07-04T03:54:50Z,Don't use match-destructuring for derived ops on structs.,nnethercote,d46c728bcda687b1cf5f3bedca3d501e797b2a0f,6,Auto merge of #98446 - nnethercote:derive-no-match-destructuring r=scottmcm Don't use match-destructuring for derived ops on structs. r? `@scottmcm`,THUMBS_UP,2022-06-24T21:23:50Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98471,OPEN,2022-06-24T23:38:18Z,NA,Update measureme to the latest version,wesleywiser,NA,NA,NA,HEART,2022-06-27T16:58:59Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/98474,MERGED,2022-06-25T01:01:36Z,2022-06-26T09:42:22Z,x.py: Support systems with only `python3` not `python`,dtolnay,e1862ca51ca7ec1a489728989a793436e394eb27,1,Rollup merge of #98474 - dtolnay:python3 r=Mark-Simulacrum x.py: Support systems with only `python3` not `python` Fixes #71818 without the pitfalls so far described in previous attempts.,HEART,2022-06-25T01:03:36Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98474,MERGED,2022-06-25T01:01:36Z,2022-06-26T09:42:22Z,x.py: Support systems with only `python3` not `python`,dtolnay,e1862ca51ca7ec1a489728989a793436e394eb27,1,Rollup merge of #98474 - dtolnay:python3 r=Mark-Simulacrum x.py: Support systems with only `python3` not `python` Fixes #71818 without the pitfalls so far described in previous attempts.,HEART,2022-06-27T20:18:27Z,Walther,veeti.haapsamo@gmail.com https://github.com/rust-lang/rust/pull/98475,MERGED,2022-06-25T01:12:53Z,2022-06-29T00:21:01Z,rustdoc: reference function signature types from the `p` array,notriddle,2953edc7b7a00d14c4ba940ebb46b4e7148a9d71,7,Auto merge of #98475 - notriddle:notriddle/index-fn-signatures r=GuillaumeGomez rustdoc: reference function signature types from the `p` array This reduces the size of the function signature index because it's common to have many functions that operate on the same types. $ wc -c search-index-old.js search-index-new.js 5224374 search-index-old.js 3932314 search-index-new.js By my math this reduces the uncompressed size of the search index by 32%. On compressed signatures the wins are less drastic a mere 8%: $ wc -c search-index-old.js.gz search-index-new.js.gz 404532 search-index-old.js.gz 371635 search-index-new.js.gz,THUMBS_UP,2022-06-27T09:46:42Z,Folyd,NA https://github.com/rust-lang/rust/pull/98482,MERGED,2022-06-25T09:26:36Z,2022-07-08T05:46:14Z,Shorten def_span of closures to just their header,cjgillot,eba361ae36be41e42fb8fdf138455307e0ad407c,175,Auto merge of #98482 - cjgillot:short-struct-span-closure r=estebank Shorten def_span of closures to just their header Continuation of https://github.com/rust-lang/rust/pull/93967.,HEART,2022-06-26T23:58:07Z,estebank,NA https://github.com/rust-lang/rust/pull/98488,MERGED,2022-06-25T14:00:56Z,2022-06-26T09:42:22Z,Bump RLS to latest master on rust-lang/rls,Mark-Simulacrum,d0828a3915b7245fe8cbe6a038853bff3501613d,2,Rollup merge of #98488 - Mark-Simulacrum:bump-rls r=pietroalbini Bump RLS to latest master on rust-lang/rls Of primary interest this merges rust-lang/rls@ece09b88c0365947af79c0ffdeea02bc6c1eec25 into rust-lang/rust which brings in the changes that fix RLS tests broken by #97853. #97853 already introduced that commit's changes (under rust-lang/rls@27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on rust-lang/rls as a branch so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit once merged into rust-lang/rust should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository. cc https://github.com/rust-lang/rust/issues/98451 but not marking as fixed as I believe we need to add verification to prevent future oversights.,THUMBS_UP,2022-06-25T21:32:35Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/98507,MERGED,2022-06-25T22:11:03Z,2022-07-07T17:36:14Z,Finishing touches for `#[expect]` (RFC 2383),xFrednet,c815fef7959930ccdaca64f50910028f06aa74fe,7,Rollup merge of #98507 - xFrednet:rfc-2383-manual-expectation-magic r=wesleywiser Finishing touches for `#[expect]` (RFC 2383) This PR adds documentation and some functionality to rustc's lint passes to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully it should be one of the last things before we can move forward with stabilizing this feature. As part of this PR I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly. --- changelog: [`duplicate_mod`]: Fixed lint attribute interaction r? `@wesleywiser` cc: https://github.com/rust-lang/rust/issues/97660 https://github.com/rust-lang/rust/issues/85549 And I guess that's it. Here have a magical unicorn :unicorn:,HOORAY,2022-06-25T22:21:36Z,est31,NA https://github.com/rust-lang/rust/pull/98507,MERGED,2022-06-25T22:11:03Z,2022-07-07T17:36:14Z,Finishing touches for `#[expect]` (RFC 2383),xFrednet,c815fef7959930ccdaca64f50910028f06aa74fe,7,Rollup merge of #98507 - xFrednet:rfc-2383-manual-expectation-magic r=wesleywiser Finishing touches for `#[expect]` (RFC 2383) This PR adds documentation and some functionality to rustc's lint passes to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully it should be one of the last things before we can move forward with stabilizing this feature. As part of this PR I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly. --- changelog: [`duplicate_mod`]: Fixed lint attribute interaction r? `@wesleywiser` cc: https://github.com/rust-lang/rust/issues/97660 https://github.com/rust-lang/rust/issues/85549 And I guess that's it. Here have a magical unicorn :unicorn:,HOORAY,2022-07-01T02:30:34Z,tamaroning,NA https://github.com/rust-lang/rust/pull/98507,MERGED,2022-06-25T22:11:03Z,2022-07-07T17:36:14Z,Finishing touches for `#[expect]` (RFC 2383),xFrednet,c815fef7959930ccdaca64f50910028f06aa74fe,7,Rollup merge of #98507 - xFrednet:rfc-2383-manual-expectation-magic r=wesleywiser Finishing touches for `#[expect]` (RFC 2383) This PR adds documentation and some functionality to rustc's lint passes to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully it should be one of the last things before we can move forward with stabilizing this feature. As part of this PR I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly. --- changelog: [`duplicate_mod`]: Fixed lint attribute interaction r? `@wesleywiser` cc: https://github.com/rust-lang/rust/issues/97660 https://github.com/rust-lang/rust/issues/85549 And I guess that's it. Here have a magical unicorn :unicorn:,HOORAY,2022-07-07T09:21:54Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98514,OPEN,2022-06-26T00:26:41Z,NA,`std::thread` support for the Nintendo 3DS,AzureMarker,NA,NA,NA,LAUGH,2022-06-26T10:12:07Z,C0RR1T,NA https://github.com/rust-lang/rust/pull/98514,OPEN,2022-06-26T00:26:41Z,NA,`std::thread` support for the Nintendo 3DS,AzureMarker,NA,NA,NA,ROCKET,2022-06-26T11:45:33Z,Meziu,NA https://github.com/rust-lang/rust/pull/98514,OPEN,2022-06-26T00:26:41Z,NA,`std::thread` support for the Nintendo 3DS,AzureMarker,NA,NA,NA,ROCKET,2022-07-07T18:31:58Z,Techie-Pi,NA https://github.com/rust-lang/rust/pull/98526,MERGED,2022-06-26T09:42:01Z,2022-07-11T03:56:41Z,Allow using `download-ci-llvm = true` outside the git checkout,jyn514,adaddb5bab936250535665fe1e7c6982d03352cb,5,"Auto merge of #98526 - jyn514:download-llvm-outside-checkout r=Mark-Simulacrum Allow using `download-ci-llvm = true` outside the git checkout `@bjorn3` noticed that this is already allowed today when download-llvm is disabled but breaks with it enabled: ``` $ ./rust2/x.py build fatal: not a git repository (or any of the parent directories): .git thread 'main' panicked at 'command did not execute successfully: ""git"" ""rev-list"" ""--author=bors@rust-lang.org"" ""-n1"" ""--first-parent"" ""HEAD"" ""--"" ""/home/jnelson/rust-lang/rust2/src/llvm-project"" ""/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp"" ""/home/jnelson/rust-lang/rust2/src/version"" expected success got: exit status: 128' src/bootstrap/native.rs:134:20 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Support it too for consistency. It's unclear to me when anyone would need to use this but `@bjorn3` feels we should support it and it's not much additional effort to get it working.",THUMBS_UP,2022-06-26T09:57:05Z,bjorn3,NA https://github.com/rust-lang/rust/pull/98534,OPEN,2022-06-26T11:46:27Z,NA,std: use `block_current_task` for thread parking on Hermit,joboet,NA,NA,NA,THUMBS_UP,2022-06-26T18:36:57Z,stlankes,NA https://github.com/rust-lang/rust/pull/98534,OPEN,2022-06-26T11:46:27Z,NA,std: use `block_current_task` for thread parking on Hermit,joboet,NA,NA,NA,THUMBS_UP,2022-06-26T19:47:08Z,mkroening,mkroening@posteo.net https://github.com/rust-lang/rust/pull/98536,CLOSED,2022-06-26T12:03:19Z,2022-06-26T20:53:09Z,[�CP] `Option`: add by-{ref mut} variants to the most pervasive adapters,danielhenrymantilla,NA,NA,NA,THUMBS_DOWN,2022-06-26T16:49:05Z,lukaslueg,NA https://github.com/rust-lang/rust/pull/98536,CLOSED,2022-06-26T12:03:19Z,2022-06-26T20:53:09Z,[�CP] `Option`: add by-{ref mut} variants to the most pervasive adapters,danielhenrymantilla,NA,NA,NA,THUMBS_DOWN,2022-06-26T17:04:04Z,veber-alex,alexveber@gmail.com https://github.com/rust-lang/rust/pull/98542,MERGED,2022-06-26T15:10:18Z,2022-06-29T05:47:46Z,Make empty bounds lower to `WellFormed` and make `WellFormed` coinductive,jackh726,116edb6800ea1d6615578e7f65366ae65364b3d8,8,Auto merge of #98542 - jackh726:coinductive-wf r=oli-obk Make empty bounds lower to `WellFormed` and make `WellFormed` coinductive r? rust-lang/types,HEART,2022-06-26T21:00:40Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T20:22:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-26T20:22:06Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-26T20:22:09Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T20:57:33Z,the8472,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-26T21:10:09Z,JohnAnon9771,njoao97710@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T21:14:11Z,Ben-Lichtman,Ben_Lichtman@icloud.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T21:21:52Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,EYES,2022-06-26T21:22:24Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T21:22:25Z,dashed,mailforalberto@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-26T21:23:19Z,Urgau,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T21:23:22Z,Urgau,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T22:13:40Z,paolobarbolini,paolo@paolo565.org https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T22:17:07Z,donkeyteethUX,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-26T22:34:43Z,HanEmile,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T22:34:44Z,HanEmile,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-26T23:10:24Z,wpbirney,wpb@360scada.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T00:37:57Z,Limeth,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T00:56:17Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,EYES,2022-06-27T00:56:18Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T00:56:19Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,HEART,2022-06-27T00:56:21Z,Andy-Python-Programmer,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T01:34:09Z,chrisduerr,contact@christianduerr.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T02:36:51Z,Suitability,suit387@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T02:36:53Z,Suitability,suit387@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T03:26:32Z,kellytk,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T05:31:08Z,RedStone576,inf@outlook.co.id https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T06:18:28Z,ArhanChaudhary,arhan.ch@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T06:48:34Z,oli-obk,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T07:02:58Z,mohe2015,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T07:07:30Z,gimbles,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T08:24:53Z,peterwilli,peter@codebuffet.co https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T08:30:45Z,aleokdev,aleok.inf@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T08:55:49Z,Suyashtnt,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T09:37:16Z,Agrailag,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T09:39:54Z,Milo123459,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T09:57:54Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T09:57:57Z,Virgiel,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T11:40:57Z,mejrs,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T11:40:58Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T11:40:59Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,HEART,2022-06-27T11:40:59Z,leocth,leocth31@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T11:41:56Z,VixieTSQ,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T11:42:50Z,the-emerald,git@anson-cheung.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T14:47:25Z,kiraind,ne.eshte@otso.city https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T14:51:57Z,cdecompilador,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T16:12:26Z,Uriopass,paris.douady@hotmail.fr https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_DOWN,2022-06-27T17:04:50Z,Kefta,collings509@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T19:16:35Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T19:16:35Z,Litarvan,adrien1975@live.fr https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T19:17:08Z,cchudant,cchudant@student.42.fr https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T19:21:03Z,HoloTheDrunk,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T19:21:22Z,HoloTheDrunk,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T19:53:30Z,theCapypara,hello@capypara.de https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,EYES,2022-06-27T19:53:31Z,theCapypara,hello@capypara.de https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-27T19:58:43Z,literal-line,chickenfishbird2@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-27T19:58:46Z,literal-line,chickenfishbird2@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-06-28T16:05:50Z,Nufflee,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-28T16:05:50Z,Nufflee,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-06-30T01:57:11Z,PatchMixolydic,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-01T15:39:18Z,KTibow,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-02T06:08:17Z,necauqua,self@necauqua.dev https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-02T06:23:27Z,retanar,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-07-03T19:38:31Z,SuperchupuDev,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-03T19:38:32Z,SuperchupuDev,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-07-04T11:36:53Z,error56,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-04T11:36:54Z,error56,NA https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-07-06T18:51:27Z,AaronRecord,aaronjrecord@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-06T18:55:23Z,AaronRecord,aaronjrecord@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-07T08:06:18Z,chop0,alecthechop@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,THUMBS_UP,2022-07-10T23:03:07Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,LAUGH,2022-07-10T23:03:08Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/98551,CLOSED,2022-06-26T20:11:19Z,2022-06-27T20:43:03Z,Check if programmer has fallen asleep,Soveu,NA,NA,NA,HEART,2022-07-10T23:03:09Z,OptimisticPeach,patrikbuhring@gmail.com https://github.com/rust-lang/rust/pull/98553,OPEN,2022-06-26T20:58:38Z,NA,Optimized vec::IntoIter::next_chunk impl,the8472,NA,NA,NA,HEART,2022-07-01T00:42:15Z,pinkforest,NA https://github.com/rust-lang/rust/pull/98558,MERGED,2022-06-26T23:32:34Z,2022-06-29T11:54:24Z,Update `smallvec` to 1.8.1.,nnethercote,66c83ffca1512ed76f9445ec7f7280f768ef71c4,32,Auto merge of #98558 - nnethercote:smallvec-1.8.1 r=lqd Update `smallvec` to 1.8.1. This pulls in https://github.com/servo/rust-smallvec/pull/282 which gives some small wins for rustc. r? `@lqd`,THUMBS_UP,2022-06-27T08:17:24Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98558,MERGED,2022-06-26T23:32:34Z,2022-06-29T11:54:24Z,Update `smallvec` to 1.8.1.,nnethercote,66c83ffca1512ed76f9445ec7f7280f768ef71c4,32,Auto merge of #98558 - nnethercote:smallvec-1.8.1 r=lqd Update `smallvec` to 1.8.1. This pulls in https://github.com/servo/rust-smallvec/pull/282 which gives some small wins for rustc. r? `@lqd`,THUMBS_UP,2022-06-28T13:14:03Z,lqd,NA https://github.com/rust-lang/rust/pull/98559,OPEN,2022-06-27T01:28:46Z,NA,Remove ReEmpty,jackh726,NA,NA,NA,HEART,2022-06-27T02:09:15Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98574,OPEN,2022-06-27T09:54:07Z,NA,Lower let-else in MIR,dingxiangfei2009,NA,NA,NA,HEART,2022-07-10T20:06:41Z,est31,NA https://github.com/rust-lang/rust/pull/98574,OPEN,2022-06-27T09:54:07Z,NA,Lower let-else in MIR,dingxiangfei2009,NA,NA,NA,HEART,2022-07-11T07:35:38Z,avl,anders@andersmusikka.se https://github.com/rust-lang/rust/pull/98580,OPEN,2022-06-27T15:48:26Z,NA,Emit error when named arguments are used positionally in format,PrestonFrom,NA,NA,NA,HEART,2022-06-27T16:52:27Z,estebank,NA https://github.com/rust-lang/rust/pull/98580,OPEN,2022-06-27T15:48:26Z,NA,Emit error when named arguments are used positionally in format,PrestonFrom,NA,NA,NA,HEART,2022-07-08T18:09:05Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98582,OPEN,2022-06-27T16:33:59Z,NA,Allow destructuring opaque types in their defining scopes,oli-obk,NA,NA,NA,EYES,2022-06-28T14:09:59Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/98584,MERGED,2022-06-27T17:18:03Z,2022-07-05T17:46:55Z,continue nll transition by removing stuff,lcnr,efb171e2350de2bec6dd1f035b99bc00535c1c15,21,Auto merge of #98584 - lcnr:region-stuff-more-beans r=oli-obk continue nll transition by removing stuff r? `@jackh726` for now building on #98641,HOORAY,2022-06-30T16:38:47Z,mati865,NA https://github.com/rust-lang/rust/pull/98584,MERGED,2022-06-27T17:18:03Z,2022-07-05T17:46:55Z,continue nll transition by removing stuff,lcnr,efb171e2350de2bec6dd1f035b99bc00535c1c15,21,Auto merge of #98584 - lcnr:region-stuff-more-beans r=oli-obk continue nll transition by removing stuff r? `@jackh726` for now building on #98641,HOORAY,2022-07-05T15:45:19Z,RalfJung,NA https://github.com/rust-lang/rust/pull/98584,MERGED,2022-06-27T17:18:03Z,2022-07-05T17:46:55Z,continue nll transition by removing stuff,lcnr,efb171e2350de2bec6dd1f035b99bc00535c1c15,21,Auto merge of #98584 - lcnr:region-stuff-more-beans r=oli-obk continue nll transition by removing stuff r? `@jackh726` for now building on #98641,HOORAY,2022-07-05T18:18:34Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98592,OPEN,2022-06-27T20:51:42Z,NA,Fixed worst-case miri performance with lossy string decoding,Kixiron,NA,NA,NA,HEART,2022-06-27T21:02:44Z,RalfJung,NA https://github.com/rust-lang/rust/pull/98592,OPEN,2022-06-27T20:51:42Z,NA,Fixed worst-case miri performance with lossy string decoding,Kixiron,NA,NA,NA,HEART,2022-06-28T04:19:57Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98592,OPEN,2022-06-27T20:51:42Z,NA,Fixed worst-case miri performance with lossy string decoding,Kixiron,NA,NA,NA,HEART,2022-06-28T20:13:28Z,lqd,NA https://github.com/rust-lang/rust/pull/98611,MERGED,2022-06-28T09:47:16Z,2022-06-28T21:17:29Z,Fix glob import ICE in rustdoc JSON format,GuillaumeGomez,956a9f55c0e1b45605975d565848da089897a853,3,Rollup merge of #98611 - GuillaumeGomez:rustdoc-json-glob-ice r=notriddle Fix glob import ICE in rustdoc JSON format Fixes #98003. r? `@notriddle`,HEART,2022-06-28T19:40:37Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,HOORAY,2022-06-28T10:31:55Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,HOORAY,2022-06-28T10:33:47Z,InvinciblenowYT,NA https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,ROCKET,2022-06-28T10:33:50Z,InvinciblenowYT,NA https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,HOORAY,2022-06-28T11:42:38Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,ROCKET,2022-06-29T14:46:40Z,jharrilim,Josephharrisonlim@gmail.com https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,HOORAY,2022-06-29T18:11:05Z,estebank,NA https://github.com/rust-lang/rust/pull/98614,MERGED,2022-06-28T10:15:37Z,2022-07-08T20:36:36Z,don't succeed `evaluate_obligation` query if new opaque types were registered,oli-obk,052495d0017e2b18b781bcf0469a048e5051f5c0,21,Auto merge of #98614 - oli-obk:take_unsound_opaque_types r=wesleywiser don't succeed `evaluate_obligation` query if new opaque types were registered fixes #98608 fixes #98604 The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field that will only happen if the field is generic as only the generic parameters are checked. I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this. Instead this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes` which says that there were some opaque types that got hidden types bound but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).,HOORAY,2022-06-30T05:30:43Z,rrbutani,NA https://github.com/rust-lang/rust/pull/98627,MERGED,2022-06-28T15:41:39Z,2022-07-04T22:42:22Z,interpret: don't rely on ScalarPair for overflowed arithmetic,RalfJung,27eb6d7018e397cf98d51c205e3576951d766323,1,Auto merge of #98627 - RalfJung:interpret-arith r=lcnr interpret: don't rely on ScalarPair for overflowed arithmetic This is for https://github.com/rust-lang/rust/pull/97861. Cc `@eddyb` I would like to avoid making this depend on `dest.layout.abi` to avoid a branch that we are not usually covering both sides of. Though OTOH this seems like fairly straight-forward code. But let's benchmark this option first to see how bad that extra `force_allocation` really is.,HEART,2022-06-28T19:04:32Z,Kixiron,contact@chasewilson.dev https://github.com/rust-lang/rust/pull/98633,OPEN,2022-06-28T16:44:23Z,NA,Fix last `let_chains` blocker,c410-f3r,NA,NA,NA,ROCKET,2022-06-28T21:58:50Z,camsteffen,NA https://github.com/rust-lang/rust/pull/98633,OPEN,2022-06-28T16:44:23Z,NA,Fix last `let_chains` blocker,c410-f3r,NA,NA,NA,HOORAY,2022-06-29T06:37:44Z,joshtriplett,josh@joshtriplett.org https://github.com/rust-lang/rust/pull/98633,OPEN,2022-06-28T16:44:23Z,NA,Fix last `let_chains` blocker,c410-f3r,NA,NA,NA,HOORAY,2022-06-30T15:11:10Z,mark-i-m,NA https://github.com/rust-lang/rust/pull/98639,MERGED,2022-06-28T19:10:11Z,2022-07-02T11:24:15Z,Factor out `hir::Node::Binding`,camsteffen,d287726aa0ead175b798b0991ba7a49eb9a2ca4c,18,Rollup merge of #98639 - camsteffen:no-node-binding r=compiler-errors Factor out `hir::Node::Binding`,THUMBS_UP,2022-06-28T19:11:20Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98639,MERGED,2022-06-28T19:10:11Z,2022-07-02T11:24:15Z,Factor out `hir::Node::Binding`,camsteffen,d287726aa0ead175b798b0991ba7a49eb9a2ca4c,18,Rollup merge of #98639 - camsteffen:no-node-binding r=compiler-errors Factor out `hir::Node::Binding`,THUMBS_UP,2022-06-28T20:17:07Z,cjgillot,NA https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-06-28T19:42:58Z,lnicola,NA https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-06-28T19:51:16Z,matklad,aleksey.kladov@gmail.com https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-06-28T20:03:09Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-06-29T09:19:08Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-06-30T18:48:00Z,tshepang,tshepang@gmail.com https://github.com/rust-lang/rust/pull/98640,MERGED,2022-06-28T19:37:07Z,2022-07-01T11:09:48Z,Let rust-analyzer ship on stable non-preview,cuviper,41e79910aa106bcc41b26ccc2b4513849d11015e,3,"Rollup merge of #98640 - cuviper:stable-rust-analyzer r=Mark-Simulacrum Let rust-analyzer ship on stable non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method e.g. the VS Code extension will probably still independently update to its weekly releases but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component and removes the ""-preview"" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``",HEART,2022-07-10T13:01:02Z,linuxtim,tim@buttersideup.com https://github.com/rust-lang/rust/pull/98644,MERGED,2022-06-28T20:49:09Z,2022-07-01T20:14:35Z,fix ICE with -Wrust-2021-incompatible-closure-captures,matthiaskrgr,90b296d770d98cc5311fa2642b66d5e9a8503aff,5,Rollup merge of #98644 - matthiaskrgr:drp_loc_span_err__2021_inc_clos_cap r=lcnr fix ICE with -Wrust-2021-incompatible-closure-captures Fixes #93117 Fixes #96258,HEART,2022-06-28T21:16:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98655,OPEN,2022-06-29T04:12:32Z,NA,Don't derive `PartialEq::ne`.,nnethercote,NA,NA,NA,CONFUSED,2022-06-30T08:42:04Z,zirconium-n,NA https://github.com/rust-lang/rust/pull/98655,OPEN,2022-06-29T04:12:32Z,NA,Don't derive `PartialEq::ne`.,nnethercote,NA,NA,NA,THUMBS_UP,2022-07-06T23:41:23Z,workingjubilee,NA https://github.com/rust-lang/rust/pull/98655,OPEN,2022-06-29T04:12:32Z,NA,Don't derive `PartialEq::ne`.,nnethercote,NA,NA,NA,THUMBS_UP,2022-07-08T06:44:14Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98655,OPEN,2022-06-29T04:12:32Z,NA,Don't derive `PartialEq::ne`.,nnethercote,NA,NA,NA,THUMBS_UP,2022-07-11T07:24:10Z,faptc,NA https://github.com/rust-lang/rust/pull/98660,MERGED,2022-06-29T07:43:57Z,2022-06-29T21:23:04Z,Unbreak stage1 tests via ignore-stage1 in `proc-macro/invalid-punct-ident-1.rs`.,eddyb,bba00b58556523b0756611f8abedd3246d8767c8,2,Rollup merge of #98660 - eddyb:invalid-punct-stage1 r=lqd Unbreak stage1 tests via ignore-stage1 in `proc-macro/invalid-punct-ident-1.rs`. #98188 broke `./x.py test --stage 1` (which I thought we ran in PR CI cc `@rust-lang/infra)` i.e. the default `./x.py test` in dev checkouts as the panic in `src/test/ui/proc-macro/invalid-punct-ident-1.rs` moved from the server (`rustc`) to the client (proc macro) and that means it's now affected by #59998. I made the test look like `src/test/ui-fulldeps/issue-76270-panic-in-libproc-macro.rs` tho I'm a bit confused why that one is in `src/test/ui-fulldeps` it should still work in `src/test/ui` no? (cc `@Aaron1011)`,HEART,2022-06-29T21:18:00Z,nnethercote,NA https://github.com/rust-lang/rust/pull/98687,MERGED,2022-06-29T20:30:43Z,2022-06-30T03:50:37Z,add test for 47814,matthiaskrgr,943c6c74440584eb789439e96e3365ba401c0d7c,2,Rollup merge of #98687 - matthiaskrgr:test_47814 r=compiler-errors add test for 47814 not sure if the issue should actually get closed though hm r? ``@compiler-errors``,THUMBS_UP,2022-06-29T20:43:04Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/98687,MERGED,2022-06-29T20:30:43Z,2022-06-30T03:50:37Z,add test for 47814,matthiaskrgr,943c6c74440584eb789439e96e3365ba401c0d7c,2,Rollup merge of #98687 - matthiaskrgr:test_47814 r=compiler-errors add test for 47814 not sure if the issue should actually get closed though hm r? ``@compiler-errors``,THUMBS_UP,2022-06-30T00:36:10Z,vincenzopalazzo,vincenzopalazzodev@gmail.com https://github.com/rust-lang/rust/pull/98695,MERGED,2022-06-30T01:07:22Z,2022-07-01T13:55:27Z,"use ""or pattern""",tshepang,8385d6bee47a839f094e63ff50ea272bb7f209bb,1,"Rollup merge of #98695 - tshepang:or-pattern r=compiler-errors use ""or pattern""",HEART,2022-06-30T01:16:26Z,vincenzopalazzo,vincenzopalazzodev@gmail.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T10:06:37Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T10:53:03Z,slanterns,slanterns.w@gmail.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T11:22:58Z,marmeladema,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T12:08:51Z,ivan770,ivan@ivan770.me https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T12:13:57Z,GoldsteinE,root@goldstein.rs https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T13:45:03Z,flip1995,hello@philkrones.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T14:03:02Z,taiki-e,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T14:41:01Z,Aaron1011,aa1ronham@gmail.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T15:20:22Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T15:20:22Z,yoshuawuyts,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T16:41:55Z,wwylele,wwylele@gmail.com https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T18:44:23Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T18:44:24Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-06-30T19:57:01Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-06-30T19:57:01Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,THUMBS_UP,2022-06-30T20:05:08Z,Agrailag,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-01T13:39:17Z,Alexendoo,alex@macleod.io https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-05T19:54:48Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-07-05T19:55:21Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-07T01:00:42Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-07-07T01:00:43Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-09T20:29:29Z,LegionMammal978,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,ROCKET,2022-07-10T17:23:25Z,fmease,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-10T17:23:26Z,fmease,NA https://github.com/rust-lang/rust/pull/98705,OPEN,2022-06-30T09:36:27Z,NA,Implement `for<>` lifetime binder for closures,WaffleLapkin,NA,NA,NA,HEART,2022-07-11T08:56:50Z,eddyb,eddyb@lyken.rs https://github.com/rust-lang/rust/pull/98707,OPEN,2022-06-30T10:04:47Z,NA,std: use futex-based locks on Fuchsia,joboet,NA,NA,NA,HEART,2022-06-30T22:02:57Z,tmandry,NA https://github.com/rust-lang/rust/pull/98707,OPEN,2022-06-30T10:04:47Z,NA,std: use futex-based locks on Fuchsia,joboet,NA,NA,NA,ROCKET,2022-06-30T22:22:28Z,tmandry,NA https://github.com/rust-lang/rust/pull/98713,MERGED,2022-06-30T14:31:50Z,2022-07-11T01:15:46Z,promote placeholder bounds to 'static obligations,nikomatsakis,2cb7d1c933e0444732b7eee4b3945964e84bbe39,5,Rollup merge of #98713 - nikomatsakis:issue-98693 r=jackh726 promote placeholder bounds to 'static obligations In NLL when we are promoting a bound out from a closure if we have a requirement that `T: 'a` where `'a` is in a higher universe we were previously ignoring that which is totally wrong. We should be promoting those constraints to `'static` since universes are not expressible across closure boundaries. Fixes #98693 ~~(Marking as WIP because I'm still running tests haven't add the new test etc)~~ r? ``@jackh726``,HEART,2022-06-30T15:15:30Z,aliemjay,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-06-30T17:10:04Z,yerke,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-06-30T17:10:06Z,yerke,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-06-30T17:10:08Z,yerke,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,ROCKET,2022-06-30T17:10:10Z,yerke,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-06-30T23:31:37Z,mati865,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-06-30T23:31:37Z,mati865,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-01T08:02:09Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-01T09:29:24Z,EFanZh,efanzh@gmail.com https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-01T15:43:53Z,fd,simon.menke@gmail.com https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-07-01T18:01:45Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-01T18:01:46Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-07-01T18:01:47Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,ROCKET,2022-07-01T18:01:48Z,Ayawen01,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-04T10:41:10Z,Dav1dde,github@dav1d.de https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-08T12:28:04Z,pepoviola,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,ROCKET,2022-07-08T12:28:05Z,pepoviola,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-08T22:38:05Z,CathalMullan,contact@cathal.dev https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-09T12:43:08Z,AltF02,contact@altf2.dev https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-07-09T13:07:11Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-09T13:07:12Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-07-09T13:07:13Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,ROCKET,2022-07-09T13:07:14Z,zohnannor,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-07-09T13:13:19Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HOORAY,2022-07-09T15:40:02Z,janriemer,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-07-09T20:49:04Z,artob,arto@aurora.dev https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-07-10T00:42:47Z,lukechu10,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,THUMBS_UP,2022-07-10T09:06:06Z,geofmureithi,NA https://github.com/rust-lang/rust/pull/98718,MERGED,2022-06-30T14:57:48Z,2022-07-08T10:03:37Z,Stabilize `into_future`,yoshuawuyts,9c6bcb60f30abee7648f8be67c880159db4366ce,3,Rollup merge of #98718 - yoshuawuyts:stabilize-into-future r=yaahc Stabilize `into_future` https://github.com/rust-lang/rust/issues/67644 has been labeled with [S-tracking-ready-to-stabilize](https://github.com/rust-lang/rust/labels/S-tracking-ready-to-stabilize) - which mentions someone needs to file a stabilization PR. So hence this PR! :sparkles: Thanks! Closes https://github.com/rust-lang/rust/issues/67644 r? ``@joshtriplett``,HEART,2022-07-10T09:12:29Z,ThyW,kamo.bavmesa@gmail.com https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HOORAY,2022-07-01T12:14:07Z,alice-i-cecile,alice.i.cecile@gmail.com https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HEART,2022-07-01T12:14:10Z,alice-i-cecile,alice.i.cecile@gmail.com https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HEART,2022-07-01T12:53:11Z,CGMossa,NA https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HOORAY,2022-07-01T12:53:11Z,CGMossa,NA https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HEART,2022-07-01T13:17:55Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HOORAY,2022-07-01T13:18:01Z,devil-ira,JustTheCoolDude@gmail.com https://github.com/rust-lang/rust/pull/98729,MERGED,2022-06-30T17:47:29Z,2022-07-01T11:09:47Z,clarify that ExactSizeIterator::len returns the remaining length,the8472,734f21c9e20fbeea33bf1ab5da9bba1cce39b2a0,2,Rollup merge of #98729 - the8472:exactsize-docs r=thomcc clarify that ExactSizeIterator::len returns the remaining length fixes #98721,HOORAY,2022-07-01T14:31:09Z,harudagondi,NA https://github.com/rust-lang/rust/pull/98734,MERGED,2022-06-30T18:20:00Z,2022-07-01T11:09:47Z,Update RELEASES.md,tmiasko,c4acd06a57f0add28b15a67985ed0d89d00f81d3,1,Rollup merge of #98734 - tmiasko:uninhabited-calls-release-notes r=Mark-Simulacrum Update RELEASES.md Clarify that flow sensitive checks now understand that *visibly* uninhabited call expressions never return. The change influences checks of reachable and unreachable code alike not just dead code like previous wording would imply. cc ``@Kixunil``,HEART,2022-06-30T19:29:30Z,Kixunil,martin.habovstiak@gmail.com https://github.com/rust-lang/rust/pull/98738,MERGED,2022-06-30T19:55:37Z,2022-07-05T01:23:12Z,Clarify MIR semantics of checked binary operations,tmiasko,82660a25250d7922a2d7fb279dfc8a1e7ae0b705,1,Rollup merge of #98738 - tmiasko:checked-binop r=oli-obk Clarify MIR semantics of checked binary operations,THUMBS_UP,2022-07-01T00:24:37Z,JakobDegen,jakob@degen.com https://github.com/rust-lang/rust/pull/98742,OPEN,2022-06-30T20:52:35Z,NA,WIP: Trust parameter env when projecting GATs,nikomatsakis,NA,NA,NA,EYES,2022-06-30T21:23:35Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98749,MERGED,2022-07-01T02:20:40Z,2022-07-01T11:09:47Z,Add macro_rules! rustdoc change to 1.62 relnotes,CAD97,18d4228456a98fd6d8950f74fd117aba7fb45757,1,Rollup merge of #98749 - CAD97:patch-3 r=jyn514 Add macro_rules! rustdoc change to 1.62 relnotes #96630 was tagged relnotes but didn't make it into the notes. Given this is a compatibility issue (https://github.com/rust-lang/rust/issues/97030 https://github.com/rust-lang/rust/issues/98735 https://github.com/rust-lang/rust/issues/98743) it probably *should* be retroactively added.,HEART,2022-07-01T03:14:49Z,jonhoo,jon@thesquareplanet.com https://github.com/rust-lang/rust/pull/98754,OPEN,2022-07-01T05:25:12Z,NA,Fix drop-tracking ICE when a struct containing a field with a significant drop is used across an await,jyn514,NA,NA,NA,EYES,2022-07-01T05:51:08Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98755,MERGED,2022-07-01T05:42:03Z,2022-07-03T12:17:17Z,Optimize `Vec::insert` for the case where `index == len`.,nnethercote,f99f9e48ed77a99747c6d07b42fdfe500f1a7de0,1,Auto merge of #98755 - nnethercote:faster-vec-insert r=cuviper Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in one case. Although I don't have a specific use case in mind it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case the number of conditions checked is unchanged. - In the `index == len` case the number of conditions checked increases by one but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`,THUMBS_UP,2022-07-01T07:40:11Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/98755,MERGED,2022-07-01T05:42:03Z,2022-07-03T12:17:17Z,Optimize `Vec::insert` for the case where `index == len`.,nnethercote,f99f9e48ed77a99747c6d07b42fdfe500f1a7de0,1,Auto merge of #98755 - nnethercote:faster-vec-insert r=cuviper Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in one case. Although I don't have a specific use case in mind it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case the number of conditions checked is unchanged. - In the `index == len` case the number of conditions checked increases by one but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`,EYES,2022-07-01T14:10:52Z,HeroicKatora,NA https://github.com/rust-lang/rust/pull/98755,MERGED,2022-07-01T05:42:03Z,2022-07-03T12:17:17Z,Optimize `Vec::insert` for the case where `index == len`.,nnethercote,f99f9e48ed77a99747c6d07b42fdfe500f1a7de0,1,Auto merge of #98755 - nnethercote:faster-vec-insert r=cuviper Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in one case. Although I don't have a specific use case in mind it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case the number of conditions checked is unchanged. - In the `index == len` case the number of conditions checked increases by one but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`,THUMBS_UP,2022-07-03T07:57:41Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98755,MERGED,2022-07-01T05:42:03Z,2022-07-03T12:17:17Z,Optimize `Vec::insert` for the case where `index == len`.,nnethercote,f99f9e48ed77a99747c6d07b42fdfe500f1a7de0,1,Auto merge of #98755 - nnethercote:faster-vec-insert r=cuviper Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in one case. Although I don't have a specific use case in mind it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case the number of conditions checked is unchanged. - In the `index == len` case the number of conditions checked increases by one but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`,THUMBS_UP,2022-07-07T07:21:50Z,Folyd,NA https://github.com/rust-lang/rust/pull/98755,MERGED,2022-07-01T05:42:03Z,2022-07-03T12:17:17Z,Optimize `Vec::insert` for the case where `index == len`.,nnethercote,f99f9e48ed77a99747c6d07b42fdfe500f1a7de0,1,Auto merge of #98755 - nnethercote:faster-vec-insert r=cuviper Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in one case. Although I don't have a specific use case in mind it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case the number of conditions checked is unchanged. - In the `index == len` case the number of conditions checked increases by one but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`,THUMBS_UP,2022-07-07T07:36:55Z,zjp-CN,jiping_zhou@foxmail.com https://github.com/rust-lang/rust/pull/98761,MERGED,2022-07-01T12:38:05Z,2022-07-05T09:36:33Z,more `need_type_info` improvements,lcnr,6a9db39f6ccf25e97d0017a6921d95c3534bd714,14,Rollup merge of #98761 - lcnr:need_type_info-cont r=estebank more `need_type_info` improvements this now deals with macros in suggestions and the source cost computation does what I want for `channel` :tada: r? ``@estebank``,HEART,2022-07-01T15:48:10Z,estebank,NA https://github.com/rust-lang/rust/pull/98771,OPEN,2022-07-01T16:20:15Z,NA,Add support for link-flavor rust-lld for iOS tvOS and watchOS,Thog,NA,NA,NA,HEART,2022-07-01T16:22:23Z,EliseZeroTwo,mail@elise.moe https://github.com/rust-lang/rust/pull/98771,OPEN,2022-07-01T16:20:15Z,NA,Add support for link-flavor rust-lld for iOS tvOS and watchOS,Thog,NA,NA,NA,HEART,2022-07-01T16:29:46Z,Absolucy,lucy@absolucy.moe https://github.com/rust-lang/rust/pull/98776,MERGED,2022-07-01T19:15:47Z,2022-07-05T14:58:40Z,"rustdoc: improve click behavior of the source code mobile full-screen ""sidebar""",notriddle,c2613a5c7fc1e6582eae12ea24da7bf08c16ad43,4,"Rollup merge of #98776 - notriddle:notriddle/mobile-sidebar-auto-close r=GuillaumeGomez rustdoc: improve click behavior of the source code mobile full-screen ""sidebar"" On desktop if you open the source code sidebar it stays open even when you move from page to page. It used to do the same thing on mobile but I think that's stupid. Since the file list fills the entire screen on mobile and you can't really do anything with the currently selected file other than dismiss the ""sidebar"" to look at it it's safe to assume that anybody who clicks a file in that list probably wants the list to go away so they can see it. Split out separately from #98772",THUMBS_UP,2022-07-06T16:23:02Z,jsha,github@hoffman-andrews.com https://github.com/rust-lang/rust/pull/98785,MERGED,2022-07-01T22:33:57Z,2022-07-10T19:26:04Z,Do not call `check_expr` in `check_compatible` since it has side-effects,compiler-errors,c6ff90b00ec443a73748f99952ba07372dce87ae,4,Auto merge of #98785 - compiler-errors:no-check-expr-in-check-compatible r=estebank Do not call `check_expr` in `check_compatible` since it has side-effects Fixes a weird suggestion in #98784 found later: Fixes #98894 Fixes #98897,HEART,2022-07-04T20:09:18Z,WaffleLapkin,waffle.lapkin@gmail.com https://github.com/rust-lang/rust/pull/98789,OPEN,2022-07-01T23:12:01Z,NA,rustdoc-json-types: Clean up derives.,aDotInTheVoid,NA,NA,NA,THUMBS_UP,2022-07-03T19:02:59Z,Enselic,enselic@gmail.com https://github.com/rust-lang/rust/pull/98793,MERGED,2022-07-02T02:15:34Z,2022-07-05T01:23:12Z,Lint against executable files in the root directory,Mark-Simulacrum,2a4091187a0e9e7d04340ab39053c56832141faa,2,Rollup merge of #98793 - Mark-Simulacrum:fix-tidy-bins r=jyn514 Lint against executable files in the root directory This avoids accidental introduction (such as in #97488) of executable files into the root directory not just under library/ src/ or compiler/. Resolves #98792,HEART,2022-07-02T02:21:08Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98793,MERGED,2022-07-02T02:15:34Z,2022-07-05T01:23:12Z,Lint against executable files in the root directory,Mark-Simulacrum,2a4091187a0e9e7d04340ab39053c56832141faa,2,Rollup merge of #98793 - Mark-Simulacrum:fix-tidy-bins r=jyn514 Lint against executable files in the root directory This avoids accidental introduction (such as in #97488) of executable files into the root directory not just under library/ src/ or compiler/. Resolves #98792,HEART,2022-07-02T10:24:15Z,vincenzopalazzo,vincenzopalazzodev@gmail.com https://github.com/rust-lang/rust/pull/98807,OPEN,2022-07-02T10:51:43Z,NA,"Reword ""Required because of the requirements on the impl of ...""",cbeuw,NA,NA,NA,THUMBS_UP,2022-07-02T11:25:04Z,fmease,NA https://github.com/rust-lang/rust/pull/98807,OPEN,2022-07-02T10:51:43Z,NA,"Reword ""Required because of the requirements on the impl of ...""",cbeuw,NA,NA,NA,HEART,2022-07-02T11:25:06Z,fmease,NA https://github.com/rust-lang/rust/pull/98807,OPEN,2022-07-02T10:51:43Z,NA,"Reword ""Required because of the requirements on the impl of ...""",cbeuw,NA,NA,NA,THUMBS_UP,2022-07-02T12:49:25Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98835,OPEN,2022-07-03T02:24:19Z,NA,relate `closure_substs.parent_substs()` to parent fn in NLL,aliemjay,NA,NA,NA,HOORAY,2022-07-03T02:38:36Z,jackh726,NA https://github.com/rust-lang/rust/pull/98844,MERGED,2022-07-03T13:51:02Z,2022-07-07T23:36:23Z,Reword comments and rename HIR visiting methods.,cjgillot,8cc6bb3d5df18dba0094897e1239bf7507a029f4,18,Rollup merge of #98844 - cjgillot:deep-visit r=jyn514 Reword comments and rename HIR visiting methods. Sparked by this discussion in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Confused.20by.20comment.20on.20.60deep_visit_item_likes_in_module.60) r? ``@jyn514`` ``@camsteffen``,THUMBS_UP,2022-07-03T14:13:06Z,camsteffen,NA https://github.com/rust-lang/rust/pull/98860,MERGED,2022-07-03T19:47:51Z,2022-07-05T20:31:49Z,adjust dangling-int-ptr error message,RalfJung,69195c026e5e38df43c77f0a36c10c230e3adcfe,18,Rollup merge of #98860 - RalfJung:dangling-int-ptr r=davidtwco adjust dangling-int-ptr error message based on suggestions by `@saethlin` in https://github.com/rust-lang/miri/issues/2163 Fixes https://github.com/rust-lang/miri/issues/2163 I also did a bit of refactoring on this so we have a helper method to create a `Pointer` with `None` provenance.,HEART,2022-07-03T20:19:59Z,saethlin,kimockb@gmail.com https://github.com/rust-lang/rust/pull/98866,OPEN,2022-07-03T21:47:18Z,NA,Add a special case for align_offset /w stride != 1,nagisa,NA,NA,NA,HEART,2022-07-04T00:15:35Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98866,OPEN,2022-07-03T21:47:18Z,NA,Add a special case for align_offset /w stride != 1,nagisa,NA,NA,NA,HEART,2022-07-04T06:37:15Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98866,OPEN,2022-07-03T21:47:18Z,NA,Add a special case for align_offset /w stride != 1,nagisa,NA,NA,NA,HEART,2022-07-04T21:57:12Z,Dushistov,dushistov@mail.ru https://github.com/rust-lang/rust/pull/98876,OPEN,2022-07-04T06:44:19Z,NA,Prefer suggestion paths that are not `#[doc(hidden)]`,compiler-errors,NA,NA,NA,HEART,2022-07-05T01:32:53Z,jyn514,github@jyn.dev https://github.com/rust-lang/rust/pull/98879,MERGED,2022-07-04T08:08:20Z,2022-07-05T01:23:11Z,"Fix ""wrap closure in parenthesis"" suggestion for `async` closure",compiler-errors,accb41ef01e23a01357215527600e97649727c6c,3,"Rollup merge of #98879 - compiler-errors:async-closure-wrap-parens r=oli-obk Fix ""wrap closure in parenthesis"" suggestion for `async` closure Fixes #98023",THUMBS_UP,2022-07-05T01:39:20Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,EYES,2022-07-05T07:32:34Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,EYES,2022-07-05T07:52:55Z,BoxyUwU,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,EYES,2022-07-05T08:41:40Z,oli-obk,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-05T09:22:09Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-05T10:22:51Z,leonardo-m,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-05T13:35:37Z,darksv,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,EYES,2022-07-05T13:35:37Z,darksv,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,ROCKET,2022-07-05T13:37:17Z,darksv,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-05T16:20:30Z,Kobzol,berykubik@gmail.com https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,ROCKET,2022-07-05T16:42:36Z,bugadani,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-06T22:50:26Z,est31,NA https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,HEART,2022-07-07T10:51:11Z,Veykril,lukastw97@gmail.com https://github.com/rust-lang/rust/pull/98914,OPEN,2022-07-05T07:30:57Z,NA,Minimal implementation of implicit deref patterns for Strings,fee1-dead,NA,NA,NA,ROCKET,2022-07-07T18:19:26Z,Iron-E,NA https://github.com/rust-lang/rust/pull/98919,OPEN,2022-07-05T09:02:22Z,NA,Strengthen invalid_value lint to forbid uninit primitives adjust docs to say that's UB,5225225,NA,NA,NA,EYES,2022-07-05T09:09:12Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98919,OPEN,2022-07-05T09:02:22Z,NA,Strengthen invalid_value lint to forbid uninit primitives adjust docs to say that's UB,5225225,NA,NA,NA,THUMBS_UP,2022-07-05T09:10:20Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98919,OPEN,2022-07-05T09:02:22Z,NA,Strengthen invalid_value lint to forbid uninit primitives adjust docs to say that's UB,5225225,NA,NA,NA,THUMBS_UP,2022-07-05T20:15:27Z,madsmtm,mads@marquart.dk https://github.com/rust-lang/rust/pull/98933,OPEN,2022-07-05T13:57:44Z,NA,Opaque types' generic params do not imply anything about their hidden type's lifetimes,oli-obk,NA,NA,NA,HOORAY,2022-07-05T16:49:18Z,aliemjay,NA https://github.com/rust-lang/rust/pull/98933,OPEN,2022-07-05T13:57:44Z,NA,Opaque types' generic params do not imply anything about their hidden type's lifetimes,oli-obk,NA,NA,NA,HEART,2022-07-05T17:01:36Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/98933,OPEN,2022-07-05T13:57:44Z,NA,Opaque types' generic params do not imply anything about their hidden type's lifetimes,oli-obk,NA,NA,NA,HEART,2022-07-05T17:08:32Z,aliemjay,NA https://github.com/rust-lang/rust/pull/98939,MERGED,2022-07-05T15:51:22Z,2022-07-06T22:50:33Z,rustdoc: Add more semantic information to impl IDs,GuillaumeGomez,77ec591727adf3c756aecf4907e64518e270c362,29,Rollup merge of #98939 - GuillaumeGomez:rustdoc-disamb-impls r=notriddle rustdoc: Add more semantic information to impl IDs Take over of #92745. I fixed the last remaining issue for the links in the sidebar (mentioned by `@jsha)` and fixed the few links broken in the std/core docs. cc `@camelid` r? `@notriddle`,HEART,2022-07-07T16:46:17Z,pierwill,NA https://github.com/rust-lang/rust/pull/98957,MERGED,2022-07-05T19:43:32Z,2022-07-09T19:57:13Z, don't allow ZST in ScalarInt ,RalfJung,f893495e3da91dc319d37861b803eed9d6c8c7c7,139,"Auto merge of #98957 - RalfJung:zst-are-different r=lcnr oli-obk don't allow ZST in ScalarInt There are several indications that we should not ZST as a ScalarInt: - We had two ways to have ZST valtrees either an empty `Branch` or a `Leaf` with a ZST in it. `ValTree::zst()` used the former but the latter could possibly arise as well. - Likewise the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`. - LLVM codegen already had to special-case ZST ScalarInt. So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead we can add new ZST variants to those types that did not have other variants which could be used for this purpose. Based on https://github.com/rust-lang/rust/pull/98831. Only the commits starting from ""don't allow ZST in ScalarInt"" are new. r? `@oli-obk`",THUMBS_UP,2022-07-06T15:49:48Z,scottmcm,NA https://github.com/rust-lang/rust/pull/98959,MERGED,2022-07-05T19:58:01Z,2022-07-06T20:09:43Z,Return a FxIndexSet in is_late_bound query.,cjgillot,3dcb616888aac50d55160b025266d555dad937d9,4,Auto merge of #98959 - cjgillot:late-bound-order r=michaelwoerister Return a FxIndexSet in is_late_bound query. This return value is iterated upon by borrowck hence the need to preserve a deterministic iteration order. Fixes https://github.com/rust-lang/rust/issues/98890 Affects https://github.com/rust-lang/rust/issues/96655 I don't know if this supersedes https://github.com/rust-lang/rust/pull/98924 or fixes an unrelated bug. r? `@michaelwoerister` This may deserve a backport.,HEART,2022-07-05T22:24:20Z,aliemjay,NA https://github.com/rust-lang/rust/pull/98959,MERGED,2022-07-05T19:58:01Z,2022-07-06T20:09:43Z,Return a FxIndexSet in is_late_bound query.,cjgillot,3dcb616888aac50d55160b025266d555dad937d9,4,Auto merge of #98959 - cjgillot:late-bound-order r=michaelwoerister Return a FxIndexSet in is_late_bound query. This return value is iterated upon by borrowck hence the need to preserve a deterministic iteration order. Fixes https://github.com/rust-lang/rust/issues/98890 Affects https://github.com/rust-lang/rust/issues/96655 I don't know if this supersedes https://github.com/rust-lang/rust/pull/98924 or fixes an unrelated bug. r? `@michaelwoerister` This may deserve a backport.,HEART,2022-07-06T14:15:08Z,wesleywiser,wwiser@gmail.com https://github.com/rust-lang/rust/pull/98959,MERGED,2022-07-05T19:58:01Z,2022-07-06T20:09:43Z,Return a FxIndexSet in is_late_bound query.,cjgillot,3dcb616888aac50d55160b025266d555dad937d9,4,Auto merge of #98959 - cjgillot:late-bound-order r=michaelwoerister Return a FxIndexSet in is_late_bound query. This return value is iterated upon by borrowck hence the need to preserve a deterministic iteration order. Fixes https://github.com/rust-lang/rust/issues/98890 Affects https://github.com/rust-lang/rust/issues/96655 I don't know if this supersedes https://github.com/rust-lang/rust/pull/98924 or fixes an unrelated bug. r? `@michaelwoerister` This may deserve a backport.,HEART,2022-07-06T15:44:25Z,Dirbaio,NA https://github.com/rust-lang/rust/pull/98959,MERGED,2022-07-05T19:58:01Z,2022-07-06T20:09:43Z,Return a FxIndexSet in is_late_bound query.,cjgillot,3dcb616888aac50d55160b025266d555dad937d9,4,Auto merge of #98959 - cjgillot:late-bound-order r=michaelwoerister Return a FxIndexSet in is_late_bound query. This return value is iterated upon by borrowck hence the need to preserve a deterministic iteration order. Fixes https://github.com/rust-lang/rust/issues/98890 Affects https://github.com/rust-lang/rust/issues/96655 I don't know if this supersedes https://github.com/rust-lang/rust/pull/98924 or fixes an unrelated bug. r? `@michaelwoerister` This may deserve a backport.,THUMBS_UP,2022-07-07T01:13:21Z,danielhenrymantilla,daniel.henry-mantilla@polytechnique.org https://github.com/rust-lang/rust/pull/98965,OPEN,2022-07-05T23:47:54Z,NA,Track `derive` attrs for more accurate suggestion,estebank,NA,NA,NA,THUMBS_DOWN,2022-07-06T09:36:47Z,petrochenkov,NA https://github.com/rust-lang/rust/pull/98975,OPEN,2022-07-06T13:02:29Z,NA,Rename `debugging_opts` to `unstable_opts`,jyn514,NA,NA,NA,LAUGH,2022-07-06T13:46:44Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/98989,OPEN,2022-07-06T20:56:06Z,NA,Enable raw-dylib for bin crates,dpaoliello,NA,NA,NA,HOORAY,2022-07-07T18:23:52Z,est31,NA https://github.com/rust-lang/rust/pull/99002,MERGED,2022-07-07T05:03:19Z,2022-07-07T23:36:23Z,suggest adding a derive for #[default] applied to variants,fee1-dead,7fed4fffb6de19d9ba7d7840c91166f91f5e8e4a,3,Rollup merge of #99002 - fee1-dead-contrib:sugg_derive r=michaelwoerister suggest adding a derive for #[default] applied to variants cc ``@TaKO8Ki`` as followup to #98873.,THUMBS_UP,2022-07-07T05:12:54Z,TaKO8Ki,NA https://github.com/rust-lang/rust/pull/99011,OPEN,2022-07-07T10:49:27Z,NA,`UnsafeCell` blocks niches inside its nested type from being available outside,oli-obk,NA,NA,NA,HEART,2022-07-07T11:17:45Z,taiki-e,NA https://github.com/rust-lang/rust/pull/99011,OPEN,2022-07-07T10:49:27Z,NA,`UnsafeCell` blocks niches inside its nested type from being available outside,oli-obk,NA,NA,NA,HEART,2022-07-07T11:36:44Z,Nilstrieb,NA https://github.com/rust-lang/rust/pull/99011,OPEN,2022-07-07T10:49:27Z,NA,`UnsafeCell` blocks niches inside its nested type from being available outside,oli-obk,NA,NA,NA,HEART,2022-07-07T11:45:31Z,RalfJung,NA https://github.com/rust-lang/rust/pull/99011,OPEN,2022-07-07T10:49:27Z,NA,`UnsafeCell` blocks niches inside its nested type from being available outside,oli-obk,NA,NA,NA,HEART,2022-07-07T17:05:40Z,pnkfelix,pnkfelix@pnkfx.org https://github.com/rust-lang/rust/pull/99030,OPEN,2022-07-07T22:25:48Z,NA,diagnostics: error messages when struct literals fail to parse,notriddle,NA,NA,NA,HEART,2022-07-07T23:43:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/99040,OPEN,2022-07-08T02:39:38Z,NA,Run stage 0 std tests in CI,gimbles,NA,NA,NA,HEART,2022-07-08T03:55:32Z,compiler-errors,michael@errs.io https://github.com/rust-lang/rust/pull/99040,OPEN,2022-07-08T02:39:38Z,NA,Run stage 0 std tests in CI,gimbles,NA,NA,NA,ROCKET,2022-07-08T09:47:02Z,thomcc,thom@shift.click